Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system

The present invention generally relates to the field of information storage and retrieval, and more specifically, an active storage platform for organizing, retrieving, and sharing various types of data, especially image data, in computerized systems. Regarding.

This application claims the priority of US Patent Application No. 10 / 692,779 (reference number MSFT-2829) filed on October 24, 2003, and is incorporated herein by reference in its entirety. US Patent Application No. 10 / 646,632 filed on August 21, 2003 under the name METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM It claims the benefit of reference number MSFT-1751) and International Application No. PCT / US03 / 26144 filed on August 21, 2003.

The application is further related by subject to the invention disclosed in the application transferred to the assignee of the present application below, the contents of which are also incorporated herein by reference. US Patent Application No. 10 / 647,058 (reference number MSFT 1748), filed on August 21, 2003, entitled "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION", "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL" filed on August 21, 2003 US patent application No. 10 / 646,941 (reference number MSFT-1749) named "ORGANIZATION", "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE" filed on August 21, 2003. US patent application No. 10 / 646,940 (reference number MSFT-1750) named "/ SOFTWARE INTERFACE SYSTEM", "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE" filed on August 21, 2003 US patent application No. 10 / 646,645 (reference number MSFT-1752) named "INTERFACE SYSTEM", "SYSTEMS AND METHODS FOR INTERFACING" filed on August 21, 2003 APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM, US Patent Application No. 10 / 646,575 (reference number MSFT-2733), filed August 21, 2003, "STORAGE PLATFORM FOR ORGANIZING, SEARCHING," US patent application No. 10 / 646,646 (reference number MSFT-2734) named "AND SHARING DATA", filed on August 21, 2003, named "SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM" U.S. patent application No. 10 / 646,580 (reference number MSFT-2735), filed on October 24, 2003, in the United States named "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" Patent application No. 10 / 692,515 (reference number MSFT-2844), "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF" filed on October 24, 2003 INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM "US patent application No. 10 / 692,508 (reference number MSFT-2845), filed on October 24, 2003," SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM "US patent application No. 10 / 693,362 (reference number MSFT-2846) and" SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR "filed on October 24, 2003 UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM "US Patent Application No. 10 / 693,574 (reference number MSFT-2847).

Individual disk capacity has increased by about 70 percent each year over the last decade. Moore's Law accurately predicted the tremendous advances in central processing units (CPUs) that have occurred over the years. Wired and wireless technologies have provided incredible connectivity and bandwidth. Assuming that the current trend continues, in a few years the average laptop computer will be equipped with nearly 1 terabyte (TB) of storage to accommodate millions of files, 500 gigabytes (500 gigabytes). GB) drives will become widespread.

Consumers, whether traditional Personal Information Manager (PIM) style data or media such as digital music or digital photography, use computers primarily for communication and organization of personal information. The amount of digital content and the ability to store raw bytes has grown tremendously. However, the methods available to consumers to organize and centrally manage this data are lagging behind (not following). Knowledge workers spend a great deal of time managing and sharing information, and one study found that knowledge workers spend 15-25% of their time on unproductive information-related work. It is estimated. Other studies estimate that common knowledge workers spend about 2.5 hours a day searching for information.

Developers and information technology (IT) departments have invested considerable time and money in building their own data stores for a common storage abstraction that represents things such as people, places, times, and events. Not only is this a duplicate task, it also creates isolated islands of common data that do not have a mechanism for common retrieval or sharing of data. Consider how many address books can currently exist on a computer running the Microsoft Windows® operating system. Many applications, such as email clients and asset management programs, maintain an address book here, and the address book data that each such program holds individually is rarely shared between applications. Therefore, asset management programs (like Microsoft Money) are (Microsoft). Do not share the address stored in the email contacts folder (as in Outlook) with the payee's address. In fact, many users own multiple devices and logically need to synchronize their personal data between them, as well as across a wide variety of additional sources, including mobile phones and commercial services such as MSN and AOL. There is. Nonetheless, collaboration of shared documents is mostly done manually, inefficiently, by attaching the document to an email message.

One reason for this lack of collaboration is that traditional approaches to organizing information in computer systems have focused on the use of file folder and directory-based systems (file systems). Is. It organizes multiple files into a folder directory hierarchy based on the abstraction of the physical organization of the storage medium used to store the files. Developed in the 1960s, the Multics operating system is believed to have pioneered the use of files, folders, and directories to manage units of data that can be stored at the operating system level. In particular, Multics used symbolic addresses within the file hierarchy where the physical address of the file was not transparent to the user (application and end user) (which introduced the concept of file paths). This file system uses the file format of individual files (file) It was completely indifferent to format), and relationships between files were considered irrelevant at the operating system level (that is, other than the location of files in the hierarchy). Since the advent of Multics, storable data has been organized into files, folders and directories at the operating system level. These files generally contain the file hierarchy itself (the "directory") embedded in special files held by the file system. This directory holds a list of entries for all other files in the directory and the location of such files on the node in the hierarchy (referred to herein as folders). The above situation has been the state of this field for almost 40 years.

However, as long as it provides a rational representation of the information contained in the computer's physical storage system and the file system is an abstraction of that physical storage system, therefore, the use of files by the user Off-the-shelf processing (a) at a level between what you operate (units that have contexts, features, and relationships with other units) and what your operating system provides (files, folders, and directories). level of Indirection (interpretation) is required, inevitably for users (applications and / or end users), even if it is inefficient, inconsistent, or undesirable. Even so, they had no choice but to push units of information into the file system structure. In addition, existing file systems identify most of the structure of the data stored in individual files. Because of this, most of the information remains confined in a file that can only be accessed (and understood) by the application from which it was created. Therefore, a brief description of this information and information management. Lack of mechanics has led to the creation of data silos where little data is shared between individual silos. For example, many personal computer (PC) users have some information about who they interact with. 5 or more separate storage locations, such as Outlook Contacts, online account address, Windows® Address He has Books, Quicken Payees, and an instant messaging (IM) companion list. The reason is that organizing files is a serious challenge for these PC users. Most existing file systems use a nested folder metaphor for organizing files and folders, so as the number of files grows, the effort needed to maintain a flexible and efficient organization schema is exactly what it takes. It will be a trial. In such situations, it would be very useful to have multiple classifications for a single file. However, using hard or soft links with existing file systems can be cumbersome and difficult to maintain.

In the past, some attempts to address the shortcomings of the file system have been unsuccessful. Some of these previous attempts are content addressable memory. ) Was also included to provide a mechanism for accessing data by content rather than by physical address. However, these efforts were unsuccessful. On the other hand, however, associative storage devices have been found to be effective for small-scale use by devices such as cache and memory management devices, but large-scale use of devices such as physical storage media is still not possible for various reasons. None, and therefore, such a solution simply does not exist. Other attempts have been made to use object-oriented database (OODB) systems, but these attempts are not effective and fast at processing file representations, despite their powerful database characteristics and good non-file representations. It was not possible to reproduce the efficiency, and the simplicity of the file and folder-based hierarchy at the hardware / software interface system level. Other efforts, such as those attempting to use SmallTalk (and other derivatives), have proven to be very effective in handling file and non-file representations, but exist between various data files. The database functionality required to effectively organize and use relationships was inadequate. Therefore, the overall efficiency of such a system was unacceptable. In addition, another attempt to use BeOS (and other such operating system studies) is of non-file representation, even though it can represent the file well while providing some required database functionality. It turned out to be inadequate for processing (similar core drawbacks of traditional file systems).

Database technology is another area of technology that presents similar challenges. For example, the relational database model has had huge commercial success, but in reality it is a relational database software product (such as Microsoft SQL Server) commonly practiced by independent software vendors (ISVs). Only a few features are available for. Rather, most application interactions with such products take the form of simple "gets" and "puts." There are many easy-to-understand reasons for this, such as lack of a clear view of the platform or database, but one of the many important reasons that will not be noticed is by major business application vendors. The point is that it does not necessarily have to provide the exact abstraction that is actually needed. For example, the real world is a "customer" or "order" (an item in an order and a "line" embedded in the order as an item in the order. Although it has the concept of "items" (along with "items"), relational databases only discuss in terms of tables and rows. Therefore, even if you want your application to have integrity, locking, security, and / or trigger aspects (to give a few examples) at the item level, databases generally feature these features. Is provided only at the table / rows level. This may work well if each item is mapped to a single row in some table in the database, but for orders with multiple item names, the item is actually It must be mapped to multiple tables, in which case a simple relational database system does not provide the correct abstraction. Therefore, the application needs to build logic at the top of the database to provide these basic abstractions. That is, the basic relational model does not provide a sufficient platform for data storage that facilitates the development of higher level applications. This is because the basic relational model is a level of processing between the application and the storage system. This is because it requires indirection). Here, the semantic structure of the data is only visible within the application in a particular case. Some database vendors are incorporating a higher level of functionality into their products that offer object-relational capabilities, new organizational models, etc., but none of them still provide the kind of comprehensive solution they need. Has not been reached. A truly comprehensive solution here is a data model abstraction ("Items", "Extensions", "Relationships") that is useful for useful domain abstractions ("Persons", "Locations", "Events", etc.). "Etc.) is provided.

<p> Given the aforementioned deficiencies in existing data storage and database technology, a new storage platform, or data platform, that provides improved capabilities for organizing, retrieving, and sharing data for all types of computer systems. Is a storage platform that extends beyond existing file and database systems to data platforms, and there is a need for a storage platform designed to be a storage device for all types of data. .. Related inventions incorporated herein by reference meet this need.</p><p> However, storage of images (photos, digital images, etc.) is not standardized and is not generalized across platforms and applications. Applications can include APIs tailored to a particular image format (such as JPEG), but the developers of such applications are aware of the format and tailored the application programming interface (API). In addition, all conversions necessary to interoperate with the format need to be performed. What is lacking in the art is a common schema (or set of schemas) for all image objects in a computer system, the invention of which is incorporated herein by reference. Together, it meets this particular need.</p>

<p> The following is an overview of various aspects of the invention described earlier in the context of related inventions incorporated herein by reference (related inventions). This overview does not comprehensively describe all of the important aspects of the invention and does not define the scope of the invention. Rather, this overview is intended to serve as an introduction to the detailed description and accompanying diagrams.</p><p> The present invention and related inventions as a whole are intended for storage platforms for organizing, searching, and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file and database systems for all types of data, including structured, unstructured, or semi-structured data. Designed to be a store.</p><p> The storage platform of the present invention includes a data store implemented on a database engine. The database engine is an object relational It has a relational database engine with extensions). The data store implements a data model that supports data organization, retrieval, sharing, synchronization, and security. Specific types of data are described within the schema, and the platform provides a mechanism to extend the set of schemas to define new types of data (in principle, subtypes of basic types are provided on a per-schema basis). ). The synchronization feature facilitates the sharing of data between users or systems. It provides file system-like functionality that enables data store interoperability with existing file systems without the limitations of such traditional file systems. The change tracking mechanism provides the ability to track changes to the data store. The storage platform further includes a set of application program interfaces that allow applications to access all of the aforementioned features of the storage platform and access the data described in the schema.</p><p> The data model implemented by the data store defines the units of data storage in terms of items, elements, and relationships. An item is a unit of data that can be stored in a data store and can have one or more elements and relationships. An element is an instance of a type that has one or more fields (also referred to herein as properties). A relationship is a link between two items. (As used herein, these particular terms may be capitalized (may be translated in the original language) to separate them from other terms used in close proximity. However, there is no intention to distinguish between capitalized terms (eg "Item") and the same non-capitalized terms (eg "item" (translated as "item" in Japanese)). No distinction should be presumed or implied.) A computer system constitutes an organizational structure of a plurality of items that constitute a unit of individual storable information in which each item can be operated by a hardware / software interface system. A hardware / software interface system that operates multiple items in a manner that allows multiple item folders and each item to belong to at least one item folder and to multiple item folders. It has.</p><p> Property values for an item or some items may be calculated dynamically rather than being derived from a persistent store. That is, the hardware / software interface system does not require that the item be stored, and has the ability to enumerate the current set of items, or retrieve an item given a storage platform identifier, etc. Certain operations are supported (more on this in the application programming interface, or section describing the API). For example, the item may be the current location of the mobile phone or the temperature measured by the temperature sensor. The hardware / software interface system can manipulate multiple items and further includes items interconnected by multiple relationships managed by the hardware / software interface system.</p><p> A hardware / software interface system for a computer system further comprises a core schema that defines a set of core items, which the hardware / software interface system understands and predefines. It can be processed directly in a predictable way. To manipulate multiple items, the computer system interconnects the items with multiple relationships and manages the relationships at the hardware / software interface system level.</p><p> The Storage Platform API provides a data class for each item, item extension, and relationship defined in the set of storage platform schemas. In addition, the application programming interface provides a set of framework classes that define a common set of behaviors for the data classes and, along with the data classes, provide the basic programming model for the storage platform API. .. The Storage Platform API allows application programmers to form queries based on various properties of items in the data store in a way that isolates the application programmer from the details of the underlying database engine query language. Provide a simple query model to do so. The Storage Platform API also collects changes to items made by the application program and requires them to the database engine (or any type of storage engine) in which the data store is implemented. Organize into the correct update. This allows application programmers to make changes to items in memory and leave complex data store updates to the API.</p><p> Through its common storage infrastructure and systematic data, the storage platform of the present invention can enable more efficient application development for consumers, knowledge workers and businesses. This storage platform provides a feature-rich and extensible application interface that not only allows you to take advantage of features specific to its data model, but also existing file system and database access methods. Is also incorporated and expanded.</p><p> In light of this comprehensive structure of interrelated inventions (discussed in detail in Section II of the "Detailed Description"), the present invention is specifically for all image objects (image items) in computer systems. Targets the common schema of. Other features and advantages of the invention will become apparent with reference to the following detailed description of the invention and the accompanying figures.</p><p> The above outline and the above detailed description of the present invention may be better understood by reading with reference to the accompanying figures. Illustrative examples of various aspects of the invention are shown in the figure for purposes of exemplifying the invention. However, the present invention is not limited to the specific methods and means disclosed.</p>

table of contents I. Overview -0024- A. Illustrative computing environment -0025- B. Traditional file-based storage -0038- II. WINFS Storage Platform for Data Organization, Retrieval, and Sharing -0041- A. Glossary -0042- B. Storage Platform Overview -0043- C. Data model -0048- 1. Item -0053- 2. Item identification -0060- 3. Item Folders and Categories -0066- 4. Schema -0071- a) Basic schema -0071- b) Core schema -0074- Five. Relationship -0078- a) Declaration of relationship -0083- b) Retention Relationship -0087- c) Embedded Relationships -0098- d) Reference Relationship -0105- e) Rules and constraints -0110- f) Ordering relationships -0111- 6. Extensibility -0124- a) Item extensions -0128- b) Extension of NestedElement type -0149- D. Database Engine -0157- 1. Implementation of a data store using UDT -0161- 2. Item mapping -0165- 3. Extended mapping -0169- 4. Nested element mapping -0170- Five. Object ID -0171- 6. SQL object naming -0172- 7. Column naming -0174- 8. 8. Search view -0175- a) Item -0178- (1) Master item search view -0179- (2) Type-defined item search view -0181- b) Item expansion -0183- (1) Master extended search view -0184- (2) Type-defined extended search view -0186- c) Nesting element -0188- d) Relationship -0189- (1) Master Relationship Search View -0190- (2) Relationship Instance Extended Search View -0192- e) 9. Update -0194- Ten. Change Tracking and Toomstone -0196- a) Change tracking -0197- (1) Tracking changes in the "master" search view -0199- (2) Change tracking for "type-defined" search views -0203- b) Toomstone -0205- (1) Item Toomstone -0206- (2) Expansion tombstone -0208- (3) Relationship Toomstone -0210- (4) Toomstone cleanup -0212- 11. Helper APIs and functions -0213- a) Function [System.Storage] .Getltem -0224- b) Function [System.Storage] .GetExtension -0226- c) Function [System.Storage] .GetRelationship-0218- 12. Metadata -0220- a) Schema metadata -0221- b) Instance metadata -0222- E. Security -0224- F. Notification and change tracking -0227- G. Synchronization -0230- 1. Synchronization between storage platforms -0234- a) Sync control application -0227- b) Schema annotation -0240- c) Synchronous configuration -0245- (1) Community Folder-Mapping -0249- (2) Profile -0250- (3) Schedule -0252- d) Conflict handling -0253- (1) Conflict detection -0254- (a) Knowledge-based competition -0255- (b) Constraint-based contention -0257- (2) Conflict handling -0260- (a) Automatic conflict resolution -0263- (b) Conflict logging -0267- (c) Conflict inspection and resolution -0268- (d) Replica focusing and conflict resolution propagation -0269- 2. Synchronization to non-storage platform data store -0273- a) Sync Service -0276- (1) Change Enumeration -0277- (2) Change Application -0282- (3) Conflict resolution -0284- b) Adapter implementation -0285- 3. Security -0286- 4. Ease of management -0289- H. Traditional file system interoperability -0291- I. Storage Platform API -0294- III. Image Schema and Dependent Schema (Image Schema Set) -0312- A. Image Schema -0315- B. Photo Schema -0327- C. Analysis Property Schema -0329- IV. Conclusion -0332-

I. Overview The subject matter of the present invention will be described with limitation in order to satisfy statutory requirements. However, the description itself is not intended to limit the scope of the invention. Rather, the inventor may implement the alleged subject matter in other ways, similar to the various steps or combinations of steps described herein, along with other current or future techniques. It is intended to be able to include what you have done. In addition, the term "step" is used herein to indicate the various elements of the method adopted, unless the order of the individual steps is explicitly stated. It should not be construed as implying a particular sequence between the various steps disclosed herein.

A. An exemplary computing environment Many examples of the present invention can be performed on a computer. FIG. 1 and the following description are intended to give a brief overview of the appropriate computing environment in which the present invention is implemented. Although not required, various aspects of the invention are described in line with the general context of computer executable instructions, such as program modules executed by a computer such as a client workstation or server. Program modules generally include routines, programs, objects, components, data structures, etc. that perform a particular task or implement a particular abstract data type. Further, the present invention shall be implemented in the configuration of other computer systems such as handheld devices, multi-processor systems, microprocessor-based or programmable home appliances, network PCs, minicomputers, mainframe computers and the like. Can be done. The present invention can also be performed in a distributed computing environment where tasks are performed by remote processing devices linked through communication networks. In a distributed computing environment, program modules can be located in local and remote computer storage.

As shown in FIG. 1, an exemplary general purpose computing system includes a processor 21, system memory 22, and system bus 23 that connects various system components, including system memory, to processor 21. Includes the conventional personal computer 20 and so on. The system bus 23 may be of any type of bus structure, including a memory bus or memory controller, a peripheral bus, and a local bus that uses any of the various bus architectures. System memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. The basic input / output system 26 (BIOS), which includes basic routines that help transfer information between elements in the personal computer 20 at boot time and the like, is stored in ROM 24. The personal computer 20 further includes a hard disk drive 27 that reads or writes to and from a hard disk (not shown), a magnetic disk dry 28 that reads or writes to and from a removable magnetic disk 29, and a CD-. It can include an optical disk drive 31 that reads or writes to and from a removable optical disk 30, such as a ROM or other optical medium. The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are connected to the system bus 23 by the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical drive interface 34, respectively. .. The drive and its associated computer-readable media provide a non-volatile storage device for computer-readable instructions, data structures, program modules, and other data for the personal computer 20. The exemplary environment described herein employs a hard disk, a removable magnetic disk 29, and a removable optical disk 731, but a magnetic cassette, a flash memory card, Other types of computer-readable media that can store computer-accessible data, such as digital video discs, Bernoulli cartridges, random access memory (RAM), and read-only memory (ROM), are also exemplary operating. Those skilled in the art will understand that it can be used in the environment. Similarly, exemplary environments can include many types of monitoring devices, such as heat detectors and security or fire alarm systems, and other sources of information.

A hard disk, magnetic disk 29, optical disk 31, RAM 24 or ROM 25 may contain a number of programs, including, for example, operating system 35, one or more application programs 36, other program modules 37, and program data 38. Modules can be stored. The user can enter commands and information into the personal computer 20 via input devices such as the keyboard 40 and the pointing device 42. Other input devices (not shown) can include microphones, joysticks, gamepads, satellite dishes, scanners, and the like. The above and other input devices are often connected to the processing device 21 via a serial port interface 46 connected to the system bus, but a parallel port, game port, or universal serial bus ( It can also be connected by other interfaces such as USB). A monitor 47 or other type of display device can also be connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system in Figure 1 also includes a host adapter 55, a Small Computer System Interface (SCSI) bus 56, and an external containment device 62 connected to the SCSI bus 56.

The personal computer 20 can operate in a networked environment that uses a logical connection to one or more remote computers, such as the remote computer 49. The remote computer 49 may be a personal computer, server, router, network PC, peer device or other common network node, and is usually the element described above in relation to the personal computer 20. Contains many or all of. The logical connection shown in Figure 1 includes a local area network (LAN) 51 and a wide area network (WAN) 52. Such network environments are common in offices, enterprise-scale computer networks, intranets, and the Internet.

When used in a LAN network environment, the personal computer 20 is connected to the LAN 51 via a network interface or adapter 53. When implemented in a WAN network environment, the personal computer 20 typically includes a modem 54 or other means for establishing communication over a wide area network 52, such as the Internet. The modem 54 may be internal or external and can be connected to system bus 23 via the serial port interface 46. In a networked environment, the program modules shown in connection with the personal computer 20, or parts thereof, can also be stored in remote storage. It should be understood that the network connections shown are exemplary and other means of establishing communication links between computers can also be used.

As shown in the block diagram of FIG. 2, the computer system 200 includes hardware component 202, hardware / software interface system component 204, and application program component 206 (specific herein. In the context, it can be broadly divided into three component groups (also called "user components" or "software components").

In various embodiments of the computer system 200, with reference back to FIG. 1, the hardware component 202 includes a central processing unit (CPU) 21, memory (ROM24 and RAM25), and basic input / output system (BIOS) 26. , And in particular various input / output (I / O) devices such as a keyboard 40, a mouse 42, a monitor 47, and / or a printer (not shown). Hardware component 202 provides the basic physical infrastructure of computer system 200.

Application program component 206 includes, but is not limited to, a variety of software programs including, but is not limited to, compilers, database systems, word processors, business programs, video games, and the like. Application programs utilize computer resources to solve problems, provide solutions, and process data for a variety of users (machines, other computer systems and / or end users). Provide means.

The hardware / software interface system component 204 most often comprises an operating system with a shell and kernel (in some embodiments, it consists only of the operating system). An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. Hardware / Software Interface System Component 204 is a Virtual Machine Manager (VMM), Common Language Runtime (CLR) or its functional equivalent, Java® Virtual Machine (JVM) or its functional equivalents. It also has an equivalent, or other such software component that replaces or adds to the operating system of the computer system. The purpose of a hardware / software interface system is to provide an environment in which users can execute application programs. The goal of a hardware / software interface system is to make the computer system easier to use and to use the computer hardware efficiently.

A hardware / software interface system is typically loaded into a computer system at boot time and then manages all application programs within the computer system. Application programs interact with hardware / software interfaces by requesting services through application program interfaces (APIs). Some application programs allow end users to interact with hardware / software interfaces through user interfaces such as command languages or graphical user interfaces (GUIs).

Hardware / software interface systems have traditionally performed a variety of services for applications. In a multi-tasking hardware / software interface system where multiple programs can run simultaneously, the hardware / software interface system switches which application should run in what order and switches to another application. Decide how much time to give each application by. The hardware / software interface system also manages the sharing of internal memory between multiple applications and handles inputs and outputs to and from connected hardware devices such as hard disks, printers, and dial-up ports. .. The hardware / software interface system also sends a message to each application (and, in certain cases, the end user) about the state of operation and possible errors. The hardware / software interface system can also offload management of batch jobs (such as printing), and application initialization frees you from this task and resumes other processing and / or operations. It has become like. In a computer that can provide parallel processing, the hardware / software interface system also manages the division of the program so that it runs on multiple processors at the same time.

A hardware / software interface system shell (referred to herein simply as a "shell") is an interactive end user interface to a hardware / software interface system. (The shell is also called the "command interpreter" and is sometimes called the "operating system shell" in the operating system). The shell is the outer layer of the hardware / software interface system that is directly accessible to application programs and / or end users. In contrast to the shell, the kernel is the innermost layer of the hardware / software interface system that interacts directly with the hardware components.

Although it is assumed that many examples of the invention are particularly suitable for computerized systems, there is no intention herein to limit the invention to such examples. In contrast, the term "computer system" as used herein refers to whether such a device is electronic, mechanical, logical, or virtual in nature. It is intended to include any device that can store and process information and / or any device that can use the stored information to control the behavior or execution of the device itself.

B. Traditional file-based storage In most modern computers, a "file" is a unit of storable information that can include not only application programs, datasets, etc., but also hardware / software interface systems. In all modern hardware / software interface systems (Windows®, Unix®, Linux, Mac OS, virtual machine systems, etc.), a file is a hardware / software interface system. An individual (storable and retrievable) basic unit of information that can be manipulated by (eg, data, programs, etc.). Groups of files are generally organized into "folders". Microsoft Windows®, Macintosh In an operating system and other hardware / software systems, a folder is a collection of files that can be retrieved, moved, or otherwise manipulated as a unit of information. These folders are organized in a tree-based hierarchical array called "directories" (discussed in more detail below). In certain other hardware / software interface systems, such as DOS, z / OS, and most Unix®-based operating systems, "directory" and / or "folder" replace each other. It is possible, and early Apple computer systems (eg Apple IIe) used the term "catalog" instead of directories. However, as used herein, all of these terms are synonymous, interchangeable, and all other equivalents to the hierarchical information storage structure and its folders and file components. Intended to include more references.

Traditionally, directories (also called folders' directories) are a tree-based hierarchy in which files are grouped into folders, where folders are organized according to the relative positions of the nodes that make up the directory tree. .. For example, as shown in Figure 2A, the base folder (ie, "root directory") 212 of a DOS-based file system has multiple folders 214, each with an additional ("sub" of that particular folder. It has an additional folder 216 (as a "folder"), each with an additional folder 218, and so on. Each of these folders can have one or more files 220 at the hardware / software interface system level, but the individual files in the folder have nothing in common except for their location in the tree hierarchy. Absent. Not surprisingly, this method of organizing files into a folder hierarchy is the physical physical of the usual storage media (eg, hard disks, floppy disks, CD-ROMs, etc.) used to store these files. It indirectly reflects the organization.

In addition to the above, each folder is a container for its subfolders and its files. That is, each folder owns its subfolders and files. For example, if a folder is deleted by the hardware / software interface system, the subfolders and files of that folder are also deleted (in the case of each subfolder, the subfolders and files it owns are also cycled). Included). Similarly, each file is generally owned by only one folder, the file can be copied, and even if the copy is placed in a different folder, the copy of the file is itself separate and independent. It is a unit and has no direct relationship to the original (for example, changes made to the original file are not reflected in the copy file at the hardware / software interface system level). Therefore, in this respect, folders are treated like physical containers, and files are treated as separate and independent physical elements inside these containers, effectively making files and folders have "physical" characteristics. ..

II. WINFS storage platform for organizing, retrieving, and sharing data The present invention is directed to a storage platform for organizing, retrieving, and sharing data, along with related inventions incorporated herein by reference as described above. The storage platform of the present invention extends / extends the data platform beyond the existing file system and database system types described above, including any new form of data called "items". Designed to be a store of type data.

A. Glossary The following terms, as used herein and in the claims, have the following meanings: An "item" is a unit of information that can be stored in a hardware / software interface system, and is an object that has a basic set of properties, unlike a simple file. Commonly supported by the hardware / software interface system shell across all objects visible to the end user. Items also feature properties and relationships, which include the ability to introduce new properties and relationships and are commonly supported across all item types (as described herein). Will be explained in detail later in). An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. Most operating systems have a shell and kernel. A "hardware / software interface system" is software, or a combination of hardware and software, as an interface between the hardware components that underlie a computer system and the applications that run on it. Play the role of. A hardware / software interface system usually comprises an operating system (in some embodiments, it consists only of an operating system). Hardware / software interface systems are also virtual machine managers (VMMs), common language runtimes (CLRs) or their functional equivalents, Java® virtual machines (JVMs) or their functional equivalents. , Or other such software components that replace or add to the operating system of the computer system. The purpose of a hardware / software interface system is to provide an environment in which users can execute application programs. The goal of a hardware / software interface system is to make the computer system easier to use and to use the computer hardware efficiently.

B. Storage Platform Overview Referring to FIG. 3, the storage platform 300 includes a data store 302 implemented on the database engine 314. In one embodiment, the database engine comprises a relational database engine with object relational extensions. In one embodiment, the relational database engine 314 comprises a Microsoft SQL Server relational database engine. Data store 302 implements data model 304, which supports data organization, retrieval, sharing, synchronization, and security. Specific types of data are described in schemas such as Schema 340. Storage Platform 300 provides tools 346 for deploying and extending these schemas, as described in detail below.

The change tracking mechanism 306 implemented within the data store 302 provides the ability to track changes to the data store. Data Store 302 also offers security feature 308 and promotion / demomotion feature 310, which are described in detail below. The data store 302 also provides a set of application programming interfaces 312 to bring the functionality of the data store 302 to other storage platform components and application programs that utilize the storage platform (eg, application programs 350a, 350b, etc.). And publish to 350c). The storage platform of the present invention further comprises an application program interface (API) 322, which allows application programs such as application programs 350a, 350b, and 350c to access all of the aforementioned functions of the storage platform. Allow access to the data described in the schema. Storage platform API322 is OLE It can be used by application programs in combination with other APIs such as DB API 324 and Microsoft Windows® Win32 API 326.

The storage platform 300 of the present invention can provide application programs with a variety of services 328, including a synchronization service 330 that facilitates the sharing of data between users or systems. For example, synchronization service 330 allows interoperability with other data stores 340 that have the same format as data store 302, and access to data stores 342 that have other formats. Storage Platform 300 also provides file system capabilities that allow data store 302 to interoperate with existing file systems, such as Windows® NTFS File System 318. In at least some embodiments, the storage platform 320 further provides application programs with additional functionality that allows data to act on the basis of other systems and to interact with other systems. can do. These features are Info It can be implemented in the form of additional services 328 such as Agent service 334 and notification service 332, and in the form of other utilities 336.

In at least some embodiments, the storage platform is incorporated into or forms an integral part of the hardware / software interface system of the computer system. For example, without limitation, the storage platform of the present invention can be an operating system, a virtual machine manager (VMM), a common language runtime (CLR) or its functional equivalent, or a Java® virtual machine (JVM). Or it can be incorporated into or form an integral part of its functional equivalent. The storage platform of the present invention can realize more efficient application development for consumers, knowledge workers and enterprises through its common storage infrastructure and systematic data. This storage platform provides a feature-rich and extensible programming look, which not only makes available features specific to its data model, but also existing file systems and databases. It also incorporates access methods.

In the following description, and in various figures, the storage platform 300 of the present invention can be referred to as "WinFS". However, the use of this name to refer to this storage platform is solely for descriptive convenience and is by no means intended to be limiting.

C. Data model The data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data residing in the store. In the data model of the present invention, an "item" is a basic unit of storage information. The data model declares items and item extensions, establishes relationships between items, and provides a mechanism for organizing items in item folders and categories, as described in more detail below. ..

The data model has two basic mechanisms: type and relationship. depends on mechanisms). A type is a structure that provides a format that defines the form of an instance of the type. The format is represented as an ordered set of properties. A property is the name of a given type of value or set of values. For example, the USPostalAddress type assumes that Street and City are of type String, Zip is of type Int32, and have the properties Street, City, Zip, and State. Street can be a multi-value (that is, a set of values) that allows an address to have multiple values for the Street property. The system defines certain basic types that can be used for other types of structures. These include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUID. A type of property can be defined using any base type or any structure type (with some constraints shown below). For example, the Location type can be defined so that the Address property has the types of USPostalAddress, Coordinate and Address, as described above. Properties can be mandatory or optional.

Relationships can be declared and represent a mapping between two sets of instances. For example, there is a relationship declared between the Person and Location types called LivesAt that defines which people live in which place. This relationship has a name and two endpoints: the source endpoint and the target endpoint. Relationships can also have an ordered set of properties. Both the source and target endpoints have names and types. For example, a LivesAt relationship has a source named Occupant of type Person and a target named Dwelling of type Location, and also has properties StartDate and EndDate that indicate how long the resident has lived in the dwelling. Have. A person may live in multiple dwellings for a period of time, and the dwellings may have multiple inhabitants, so the most likely place to put StartDate and EndDate information is on the relationship itself.

Relationships define mappings between instances that are constrained by the type given as the type of endpoint. For example, in the LivesAt relationship, Automobile is not a Person, so there can be no relationship that Automobile is an Occupant (resident).

The data model allows you to define a subtype-supertype relationship between types. Subtype-supertype relationships, also known as BaseType relationships, are defined in such a way that if Type A is a BaseType of type B, then all instances of B must also be instances of A. .. In other words, every instance that fits B must also fit A. For example, if A has a property Name of type String and B has a property Age of type Int16, then any instance of B will have both Name and Age. This type of hierarchy can be thought of as a tree with a single supertype at the root. Branches from the root provide first-level subtypes, branches at this level provide second-level subtypes, and so on, to the end leaf with no subtypes. This tree is not constrained to have a uniform depth, but it cannot contain cycles. A given type can have zero or many subtypes and zero or one supertype. A given instance can fit into that one type along with that type of supertype. In other words, for a given instance of any level in the tree, the instance can fit into at most one subtype of that level. This type is said to be abstract if an instance of that type must also be an instance of a subtype of that type.

1. Item An item is a unit of information that can be stored, and unlike a simple file, it is an object that has a basic set of properties that the storage platform commonly supports across all objects exposed to end users or application programs. is there. Items also have properties and relationships that are commonly supported across all item types, including the ability to introduce new properties and relationships, as described below.

Items are objects for common operations such as copy, delete, move, open, print, backup, restore, and duplicate. An item is a unit that can be stored and retrieved, and any form of storable information manipulated by the storage platform exists as an item, an item property, or a relationship between items. Each is described in detail below herein.

Items are intended to represent easily understandable units of data in the real world, such as contacts, people, services, locations, documents (of any kind), and so on. FIG. 5A is a block diagram showing the structure of the item. The unqualified name of the item is "Location". The qualified name of the item is "Core.Location", which indicates that the structure of this item is defined as a particular type of item in the core schema. (The core schema will be discussed in more detail later in this specification.) The location item has multiple properties, including EAddresses, MetropolitanRegion, Neighborhood, and PostalAddresses. The unique type of each property is shown immediately after the property name and is separated from the property name by a colon (":"). To the right of the type name, the number of values allowed for that property type is shown in square brackets. Here, the asterisk ("*") to the right of the colon (":") indicates an unspecified and / or unlimited number ("majority"). The "1" to the right of the colon indicates that there is at most one value. A zero ("0") to the left of the colon indicates that the property is optional (may have no value at all). The "1" to the left of the colon indicates that there must be at least one value (property required). Both Neighborhood and Metropolitan Region are predefined data types or "simple types". type) (shown without capital letters herein) of type nvarchar . However, EAddress and PostalAddress are properties of the predefined types or "complex types" (indicated in uppercase letters herein) of the types EAddress and PostalAddress, respectively. Complex types are types that derive from one or more simple data types and / or other complex types. A compound type of an item's properties constitutes a "nested element" (hereinafter referred to as a nested element) because the details of that compound type are nested in the item that reports directly to it and defines that property. Type-related information is retained in items with these properties (within the boundaries of the item, as described later in this specification). The concepts of these type definitions are well known and will be easily understood by those skilled in the art.

FIG. 5B is a block diagram showing the composite property types PostalAddress and EAddress. The PostalAddress property type includes items of property type PostalAddress, such as zero or one City value, zero or one CountryCode value, zero or one MailStop value, and any number of (zero to many) PostalAddressTypes (below). Define so that you can expect to have (similar). In this way, the shape of the data for a particular property within the item is defined. The EAddress property type is defined as shown. Although this application is used as an option herein, another way to represent a complex type of Location item is to draw the item with the individual properties of each complex type listed therein. FIG. 5C is a block diagram showing a Location item for which the composite type is further described. However, this alternative representation of the Location item in Figure 5C represents the exact same item shown in Figure 5A. The storage platform of the present invention also allows subtype definition, whereby one property type inherits the properties of another property subtype (one property type inherits the properties of the other parent property type). ) Becomes possible.

Because the property and its property type are similar but different, the item essentially represents its own item type that can also be the subject of a subtype definition. In other words, the storage platform in some embodiments of the invention allows an item to be a subtype of another item (one item inherits the properties of the other parent item). Moreover, for the various embodiments of the invention, all items are subtypes of the "Item" item type, which is the first basic item type found in the base schema, which is a connection. (The base schema will be discussed in more detail later in this specification.) Figure 6A shows the item, Location item, for this instance as a subtype of the Item item type found in the base schema. .. In this figure, the arrows indicate that the Location item is a subtype of the Item item type (like all other items). The Item item type has some important properties such as ItemId and various timestamps as the basic item from which all other items are derived, thereby for all items in the operating system. Define standard properties. In this figure, the Item item type property inherits the location, which makes it a property of the location. Another way to represent the properties of a Location item inherited from an Item item type is to draw a location with the individual properties of each property type from the parent item listed there. FIG. 6B is a block diagram showing the Location item in which the inherited type is described, in addition to its direct properties. This item is the same as the item shown in Figure 5A, but in the current figure the Location is direct (shown in this figure and Figure 5A) and inherited (shown in this figure but Figure 5A). Both properties are shown (but not shown in) (but in Figure 5A, these properties are referenced by an arrow indicating that the Location item is a subtype of the Item item type. Please note and understand.

Items are stand-alone objects. Therefore, when an item is deleted, all direct and inherited properties of the item are also deleted. Similarly, when retrieving an item, it retrieves the item and all of its direct and inherited properties (including information related to its composite property type). In certain embodiments of the invention, it is possible to request a subset of properties when retrieving a particular item. However, the default in many such embodiments is to provide the item with all of its direct and inherited properties as it is retrieved. In addition, item properties can be extended by adding new properties to existing properties of that item type. These "extensions" then become genuine properties of the item, and subtypes of that item type can automatically include extended properties.

The "boundary" of an item is represented by that property (including compound property types, extensions, etc.). Item boundaries also represent restrictions on the operations that can be performed on an item, such as copy, delete, move, and create. For example, in some embodiments of the invention, when an item is copied, everything within the boundaries of that item is also copied. For each item, the boundaries include: The item type of the item, and another item (as in some embodiments of the invention, where all items are derived from a single item and item type in the base schema). If it is a subtype of, the applicable subtype information (that is, information related to the parent item type). If the original item being copied is a subtype of another item, the copy will also be a subtype of that same item. · Item composite type properties and extensions (if any). If the original item has a composite type property (native or extended), the copy can also have the same composite type. "Oownership Ownership of an item that lists the record of the item on relationships, that is, which other item (the "target item") is owned by the current item ("Owning Item"). list. This is particularly relevant for the item folders described in more detail below, and for the rules stated below that all items must belong to at least one item folder. In addition, for embedded items (discussed in more detail below), embedded items are considered part of the embedded item for operations such as copy, delete, and so on.

2. Item identification Items are uniquely identified by ItemID within the global item space. The Base.Item type defines the field ItemID of the type GUID that stores the item's ID. The item must have exactly one ID in data store 302.

An item reference is a data structure that contains information for finding and identifying the location of an item. In the data model, the abstract type is defined by the name ItemReference, from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves the ItemReference and returns the item. This method is overridden by a concrete subtype of ItemReference, which implements a function that retrieves a given item. The Resolve method is called as part of Storage Platform API322.

ItemIDReference is a subtype of ItemReference. It defines the locator and ItemID fields. The Locator field gives the item domain a name (that is, identifies it). This is handled by a locator resolution method that can resolve the value of the locator to the item domain. The ItemID field is the type of ItemID.

ItemPathReference is a specialization of ItemReference that defines locators and Path fields. The Locator field identifies the item domain. This is handled by a locator resolution method that can resolve the value of the locator to the item domain. The Path field contains the (relative) path to the namespace of the storage platform that is rooted in the item domain provided by the locator.

This type of reference cannot be used for set operations. References generally need to be resolved through the path resolution process. Storage platform API322 provides this functionality.

The form of reference described above is represented through the reference type hierarchy shown in FIG. Additional reference types inherited from these types can be defined in the schema. These can be used to declare relationships as the type of target field.

3. Item folders and categories As described in more detail below, groups of items can be organized into special items called item folders (not to be confused with field folders). However, unlike most file systems, an item can belong to multiple item folders, and as a result, when an item is accessed and modified in one item folder, this modified item is different. It can be accessed directly from the item folder of. In essence, even if an item is accessed from different item folders, it is the exact same item that is actually being accessed. However, an item folder does not necessarily have to own all of its member items, or it can simply co-own an item in conjunction with another folder, which does not necessarily result in the deletion of the item folder. Is not deleted. Nevertheless, in some embodiments of the invention, if only one item folder for a particular item is deleted, in some embodiments the item is automatically deleted, or In an alternative example, the item is automatically the default item folder (for example, the "trash can" item folder is conceptually a folder with similar names used in various file and folder-based systems. Items must belong to at least one item folder to be a member of).

As described in more detail below, an item can be (a) an item type (s), (b) a specific direct or inherited property (s), or (c) an item property. It can also belong to a category based on common described characteristics, such as the corresponding specific value (s). For example, an item that contains a particular property of personal contact information will automatically belong to the contact category, and any item that has the contact information property will automatically belong to this category as well. Similarly, any item with a location property with a value of "New York City" will automatically belong to the New York City category.

Item folders can contain items that are not related to each other (that is, they do not have common described characteristics), but each item in a category has a common type, property, or value that is described in that category. Categories are conceptually different from item folders in that they have (commonality) and this commonality forms the basis of their relationships with and between other items within the category. There is. Moreover, while membership of an item in a particular folder is not required to be based on a particular aspect of that item, in certain embodiments all items have a commonality that is clearly associated with the category. Can automatically become a member of a category at the hardware / software interface system level. Conceptually, a category can also be considered as a virtual item folder whose membership is based on the results of a particular query (as in the case of database context), and this query (defined by category commonality). Items that meet the conditions of will include category membership.

FIG. 4 is a diagram showing the structural relationships between items, item folders, and categories. The plurality of items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of the various item folders 422, 424, 426, 428, and 430. Some items can also belong to multiple item folders, for example item 402 belongs to item folders 422 and 424. Some items, such as 402, 404, 406, 408, 410, and 412, are also members of multiple categories 432, 434, and 436, but which other items, such as items 414, 416, 418, and 420. It does not belong to any category (although this is unlikely to be the case in certain embodiments where ownership of any property automatically implies membership within the category, and in such embodiments any category The item must be completely featureless in order to be a member of). In contrast to the hierarchical structure of folders, both categories and item folders have a structure that is much more similar to directed graphs, as shown. In any case, items, item folders, and categories are all items (even if they have different item types).

In contrast to files, folders, and directories, the items, item folders, and categories of the invention are essentially "physical" in nature because the items do not have the conceptual isotopes of physical containers. Therefore, the item can exist in multiple such locations. The ability to work with items in multiple item folder locations and organized into multiple categories enhances the hardware / software interface level beyond what is currently available in the art. Brings a wealth of high data manipulation and storage structure capabilities.

4. Schema a) Basic schema To provide a universal foundation for the creation and use of items, various examples of storage platforms of the present invention provide a basic schema that establishes a conceptual framework for creating and organizing items and properties. I have. The base schema defines certain specific types of items and properties, and the characteristics of these specific, basic types from which subtypes can be further derived. The use of this basic schema allows programmers to conceptually distinguish items (and their respective types) from properties (and their respective types). In addition, the base schema derives from this base item (and its corresponding item type) in the base schema for all items (and their corresponding item types), so a basic set of properties that every item can own. Is shown.

As shown in FIG. 7, for some embodiments of the invention, the base schema defines three top-level types: Item, Extension, and PropertyBase. As shown, the item type is defined by the properties of this underlying "Item" item type. The top-level property type "PropertyBase", on the other hand, has no predefined properties, is just an anchor, from which all other property types are derived, and through which all derived property types are derived. Are related to each other (commonly derived from a single property type). The Extention type property defines the item that the extension extends, and the ID that distinguishes each extension because the item can have multiple extensions.

ItemFolder is a subtype of Item item type that characterizes properties inherited from an item as well as relationships to establish links to its members (if any), while IdentityKey and Property are both. A subtype of PropertyBase. CategoryRef is a subtype of IdentityKey.

b) Core schema Various embodiments of the storage platform of the present invention further include a core schema that provides a conceptual framework for the top-level Item type structure. FIG. 8A is a block diagram showing the items in the core schema, and FIG. 8B is a block diagram showing the property types in the core schema. The distinction made between files with different extensions (* .com, * .exe, * .bat, * .sys), other such criteria in file and folder-based systems, is the function of the core schema. Is similar to. In an item-based hardware / software interface system, the core schema can be processed directly in a predefined and predictable way that the item-based hardware / software interface system understands. Defines a set of core item types that characterize all items directly (by item type) or indirectly (by item subtype) into one or more core schema item types that can be. The predefined item types reflect the most common items in item-based hardware / software interface systems, and as a result, these pre-defined items make up the core schema with an efficient level. Obtained by an item-based hardware / software interface system that understands the predefined item types.

In certain embodiments, the core schema is not extensible. That is, additional item types cannot be subtyped directly from the base schema item types, except for unique predefined derived item types that are part of the core schema. Storage because by preventing extensions to the core schema (that is, preventing the addition of new items to the core schema), all subsequent item types will necessarily be subtypes of the core system item type. The platform mandates the use of item types in the core schema. This structure provides moderate flexibility in defining additional item types, yet retains the advantage of having a predefined set of core item types.

For various embodiments of the invention, with reference to FIG. 8A, the particular item type supported by the core schema can include one or more of the following: Categories: Items of this item type (and subtypes derived from them) represent valid categories in item-based hardware / software interface systems. · Commodities: Items that are identifiable values. -Devices: Items with a logical structure that supports information processing functions. Documents: Items that are not interpreted by the item-based hardware / software interface system, but instead have content that is interpreted by the application program corresponding to the document type. · Events: An item that records a particular occurrence in your environment. -Locations: Items that represent physical locations (such as geographical locations). · Messages: An item of communication between two or more principals (as defined below). Principals: Items with at least one definitive certifiable ID except ItemId (for example, person, organization, group, household, authority, service, etc.). · Statements: Items that have special information about the environment, including, but not limited to, policies, subscriptions, certificates, and so on.

Similarly, referring to Figure 8B, a particular property type supported by the core schema can include one or more of the following: · Certificates (derived from the basic PropertyBase type of the base schema) · Principal Identity Keys (derived from the Identity Key type in the base schema) · Postal Address (derived from the Property type of the base schema) Rich Text (derived from the Property type of the base schema) EAddress (derived from the Property type of the base schema) · IdentitySecurityPackage (derived from Relationship type in base schema) · RoleOccupancy (derived from the relationship type in the base schema) -BasicPresence (derived from the relationship type of the basic schema) These items and properties are further described by their respective properties shown in Figures 8A and 8B.

5. Relationship Relationships are binary relationships in which one item is designated as the source and the other item is designated as the target. Source and target items are related by relationship. Source items generally control the life of a relationship. That is, when a source item is deleted, so is the relationship between the items.

Relationships are categorized as inclusion and reference relationships. Inclusion relationships control the lifetime of the target item, but reference relationships do not provide lifetime management semantics. FIG. 12 is a diagram showing how relationships are classified.

Containment relationship types are further categorized into Holding and Embedding relationships. The item is deleted when all retention relationships to the item have been removed. Retention relationships control the lifetime of a target through a reference counting mechanism. Embedded relationships allow modeling of composite items and can be thought of as exclusive retention relationships. Items can be the target of one or more retention relationships. However, an item can be the target of exactly one embedded relationship. Items that are the target of an embedded relationship cannot be the target of any other retention or embedded relationship.

Reference relationships do not control the lifetime of the target item. These may be dangling (pending). That is, the target item may not exist. You can use reference relationships to model references to items (including remote datastores) anywhere in the global item namespace.

Fetching an item does not automatically fetch that relationship. The application must explicitly request the item's relationship. In addition, changing the relationship does not change the source or target item. Similarly, adding a relationship does not affect the source or target item.

a) Declaration of relationship The explicit relationship type is defined by the following elements: -The relationship name is specified by the name attribute. The relationship type is either retained, embedded, or referenced. This is specified by the type attribute. · Source and target endpoints. Each endpoint specifies the name and target of the referenced item. The source endpoint field is typically of type ItemID (undeclared) and must refer to an item in the same data store as the relationship instance. For retained and embedded relationships, the target endpoint field must be of type ItemIDReference and must reference an item in the same store as the relationship instance. In a reference relationship, the target endpoint can be of any ItemReference type and can reference items in data stores on other storage platforms. -Optionally, you can declare one or more fields in the scalar, or the PropertyBase type. These fields can contain data associated with the relationship. -Relationship instances are stored in the global relationship table. All relationship instances are uniquely identified by the combination (source ItemID, relationship ID). The relationship ID is unique within a given source ItemID for all relationships supplied to a given item, regardless of its type.

The source item is the owner of the relationship. The item designated as the owner controls the life of the relationship, but the relationship itself is separate from its associated item. Storage platform API322 provides a mechanism for exposing relationships associated with items. An example of a relationship declaration is shown below.

<maths num="1"><img file="JP4901472B2_D0001.tif" /></maths>

This is an example of a reference relationship. A relationship cannot be created if the person item referenced by the source reference does not exist. In addition, if the person item is deleted, the relationship instance between the person and the organization is deleted. However, if the organization item is deleted, the relationship will not be deleted and will be dangling.

b) Retention relationship Retention relationships are used to model reference-count-based lifetime management for target items.

An item can be a source endpoint for a zero or more relationship with the item. Items that are not embedded items can be the target of one or more retention relationships.

The target endpoint reference type must be ItemIDReference and must reference an item in the same store as the relationship instance.

Retention relationships enforce lifetime management of target endpoints. Creating a retention relationship instance, and creating the items it targets, is an atomic operation. You can create additional retention relationship instances that target the same item. If the last retained relationship instance with a given item as the target endpoint is deleted, the target item is also deleted.

The endpoint item type specified in the relationship declaration is generally enforced when the relationship is instantiated. The type of endpoint item cannot be changed after the relationship has been established.

Retention relationships play an important role in forming item namespaces. The retention relationship contains a "Name" property that defines the name of the target item in relation to the source item. This relative name is unique for all retention relationships sourced from a given item. This ordered list of relative names, starting from the root item to a given item, forms the full name for the item.

Retention relationships form a directed acyclic graph (DAG). When a retention relationship is created, the system prevents cycles from being created so that the item namespace forms a DAG.

The retention relationship controls the lifetime of the target item, but it does not control the operational integrity of the target endpoint item. The target item is operationally independent of the item that owns it through the retention relationship. Copying, moving, backing up, or any other operation on an item that is the source of a retention relationship does not affect the item that is the target of the same relationship. For example, backing up a folder item does not automatically back up all the items in the folder (the target of the FolderMember relationship).

An example of a retention relationship is shown below.

<maths num="2"><img file="JP4901472B2_D0002.tif" /></maths>

The FolderMembers relationship enables the concept of folders as a generic collection of items.

c) Embedded relationships Embedded relationships model the concept of exclusive control of the target item's lifetime. Embedded relationships enable the concept of composite items.

Creating an embedded relationship instance and the items it targets is an atomic operation. Items can be the source of zero or more embedded relationships. However, an item can be the target of only one embedded relationship. Items that are the target of embedded relationships cannot be the target of retention relationships.

The target endpoint reference type must be ItemIDReference and must reference an item in the same data store as the relationship instance.

The endpoint item type specified in the relationship declaration is generally enforced when the relationship is instantiated. The type of endpoint item cannot be changed after the relationship has been established.

Embedded relationships control the operational integrity of target endpoints. For example, an operation to serialize an item can include serialization of all embedded relationships and all its targets supplied by that item. When you copy an item, all of its embedded items are also copied.

An example of the declaration is shown below.

<maths num="3"><img file="JP4901472B2_D0003.tif" /></maths>

d) Reference relationship A reference relationship does not control the lifetime of the item it references. Moreover, the reference relationship does not guarantee the existence of the target, nor does it guarantee the type of target specified in the relationship declaration. That is, the reference relationship can be dangling. In addition, reference relationships can refer to items in other data stores. Reference relationships can be thought of as similar concepts to links in web pages.

An example of declaring a reference relationship is shown below.

<maths num="4"><img file="JP4901472B2_D0004.tif" /></maths>

Any reference type is allowed on the target endpoint. The item that joins the reference relationship may be of any item type.

Reference relationships are used to model many non-lifetime management relationships between items. Reference relationships are useful when modeling loosely coupled relationships because the existence of targets is not enforced. You can use reference relationships to target items in other data stores, including stores on other computers.

e) Rules and restrictions The following additional rules and restrictions apply to relationships. -Items must be targeted for "exactly one embedded relationship" or "one or more retention relationships". One exception is the root item. Items can be the target of zero or more reference relationships. -Items that are the target of an embedded relationship cannot be the source of a retention relationship. It can be the source of the reference relationship. -Items cannot be the source of retention relationships if they are upgraded from a file. It can be the source of embedded and reference relationships. -Items that are upgraded from a file cannot be targeted for embedded relationships.

f) Ordering relationships In at least one embodiment, the storage platform of the present invention supports relationship ordering. Ordering is done through a property named "Order" in the basic relationship definition. The Order field has no uniqueness restrictions. The order of relationships with the same "order" property value is not guaranteed. However, it is guaranteed to be ordered after the relationship with the lower "order" value and before the relationship with the higher "order" field value.

The application can get the relationships in the default order by ordering the combinations (SourdeItemID, RelationshipID, Order). All relationship instances supplied by a given item are ordered as a single collection, regardless of the type of relationship in the collection. However, this ensures that all relationships of a given type (eg FolderMembers) are an ordered subset of a collection of relationships for a given item.

The data store API312 for manipulating relationships implements a set of operations that supports ordering of relationships. The following terms are introduced to help explain the operation. RelFirst is the first relationship in an ordered collection with the ordered value OrdFirst. RelLast is the last relationship in an ordered collection with the ordered value OrdLast. RelX is a given relationship in a collection that has an ordX sequence value. RelPrev is a relationship that is closest to RelX in the collection and has an order value OrdPrev that is smaller than OrdX. RelNext is a relationship that is closest to RelX in the collection and has an order value OrdNext that is larger than OrdX.

Operations include, but are not limited to: -InsertBeforeFirst (SourceItemID, Relationship) inserts a relationship as the first relationship in the collection. The value of the "Order" property of the new relationship will be smaller than OrdFirst. -InsertAfterLast (SourceItemID, Relationship) inserts a relationship as the last relationship in the collection. The value of the "Order" property of the new relationship will be higher than OrdLast. -InsertAt (SourceItemID, ord, Relationship) inserts a relationship with the value specified in the "Order" property. InsertBefore (SourceItemID, ord, Relationship) inserts a relationship before a relationship that has a given sequence value. The new relationship will be assigned an "Order" value between the non-inclusive OrdPrev and ord. -InsertAfter (SourceItemID, ord, Relationship) inserts a relationship after a relationship that has a predetermined order value. The new relationship is assigned an "Order" value between the non-inclusive ord and OrdNext. -MoveBefore (SourceItemID, ord, RelationshipID) moves a relationship with a given relationship ID before a relationship with a specified "Order" value. Relationships are assigned a new "Order" value between the non-inclusive OrdPrev and ord. MoveAfter (SourceItemID, ord, RelationshipID) moves a relationship with a given relationship ID after a relationship with the specified "Order" value. Relationships are assigned new sequence values between non-inclusive ord and OrdNext.

As mentioned above, all items must be members of the item folder. For relationships, all items must have a relationship with the item folder. In some embodiments of the invention, a particular relationship is represented by a relationship that exists between items.

Implemented for various embodiments of the invention, a relationship provides a directed binary relationship that is "extended" by one item (source) to another item (target). The relationship is owned by the source item (extended item), so the relationship is removed when the source is removed (for example, when the source item is deleted, the relationship is deleted). .. In addition, in certain instances, relationships can share (co-own) ownership of the target item, and such ownership is the IsOwned property of the relationship (see Figure 7 for relationship property types). Or its equivalent). In these examples, creating a new IsOwned relationship will automatically increment the reference count of the target item, and deleting such a relationship will decrement the reference count of the target item. For these particular embodiments, the item will continue to exist if it has a reference count greater than zero and will be automatically deleted when the count reaches zero. Again, the item folder is an item that has (or can have) a set of relationships to other items, and these other items have membership in the item folder. Other practical implementations of relations are also possible, and it is possible and expected by the present invention to achieve the functionality described herein.

Regardless of the actual embodiment, a relationship is a selectable connection from one object to another. The ability of an item to belong to multiple item folders and multiple categories and whether these items, folders, and categories are public or private is their presence (or lack) in the item-based structure. It is determined by the meaning given to. These logical relationships are the meanings assigned to a set of relationships that are specifically adopted to achieve the functionality described herein, regardless of their physical implementation. Logical relationships are established between an item and its item folder or category (and vice versa), because each item folder and category is essentially a special type of item. Therefore, item folders and categories can be processed like any other item without any restrictions, such as copying, adding to e-mail messages, embedding in documents, and so on. Item folders and categories can be serialized and deserialized using the same mechanism as other items. (For example, in XML, all items may have a serialization format, which applies equally to item folders, categories, and items.) The aforementioned relationships that represent the relationships between an item and its item folder can be logically extended from item to item folder, from item folder to item, or both. A relationship that logically extends from an item to an item folder indicates that the item folder is public to that item and shares its membership information with that item. Conversely, a lack of logical relationships from an item to an item folder indicates that the item folder is private to that item and does not share its membership information with that item. Similarly, a relationship that logically extends from an item folder to an item indicates that the item is public and sharable to that item folder, but on the contrary, from an item folder to an item. The lack of logical relationships in the item indicates that the item is private and not sharable. Therefore, when an item folder is exported to another system, it is a "public" item shared in the new context, and when the item searches that item folder for other shareable items, this is A "public" item folder that provides an item with information about the shareable item that belongs to it.

FIG. 9 is a block diagram showing an item folder (again, this is an item itself), its member items, and the interconnection relationship between the item folder and its member items. Item folder 900 includes a plurality of items 902, 904, and 906 as members. Item folder 900 comprises a relationship 912 from itself to item 902, which allows item 902 to access item folder 900, its members 904 and 906, and item folder 900. Indicates that it is public and sharable to some other item folder, category, or item (not shown). However, there is no relationship from item 902 to item folder 900, which indicates that item folder 900 is private to item 902 and does not share its membership information with item 902. Item 904, on the other hand, has a relationship from itself to item folder 900, which indicates that item folder 900 is public and shares its membership information with item 904. However, there is no relationship from item folder 900 to item 904, which means that item 904 may access item folder 900, other members 902 and 906, and item folder 900. Indicates that the folder, category, or item (not shown) is private and not shareable. In contrast to its relationship to items 902 and 904, item folder 900 has a relationship 916 from itself to item 906, and item 906 has a relationship 926 back to item 900, Both of these are item 906, item folder 900, and its mail.

As mentioned earlier, the item folder is "not described", so the items in the item folder do not need to share commonality. Categories, on the other hand, are described by commonalities that are common to all of their member items. Therefore, category membership is essentially limited to items with the described commonality, and in certain embodiments, all items that fit the category description are automatically made members of the category. As a result, item folders allow trivial type structures to be represented by their membership, and categories allow membership to be based on defined commonality.

Of course, the description of categories is logical in nature, so categories can be described by any logical representation of types, properties, and / or values. For example, a logical representation of a category can be a membership that includes an item that has one or both of the two properties. If these described properties of a category are "A" and "B", then the membership of the category is an item with property A and no property B, an item with property B and no property A, And can have items with both properties A and B. This logical representation of a property can be described by the logical operator "OR" where the set of members described by the category is an item with properties A or B. Those skilled in the art will appreciate that similar logical operands ("AND", "XOR", and "NOT" alone or in combination, but not limited to them) can be used to describe a category.

Despite the differences between item folders (not described) and categories (described), category relationships to items and item relationships to categories are essentially items in many embodiments of the invention. Folders and items are similar to the methods previously disclosed herein.

FIG. 10 is a block diagram showing a category (again, this is an item itself), its member items, and the interconnection relationship between the category and its member items. Category 1000 includes multiple items 1002, 1004, and 1006 as members, all of which are a combination of common properties, values, or types 1008 as described by category 1000 (commonality description 1008). Sharing. Category 1000 has a relationship 1012 from itself to item 1002, which means that item 1002 may access category 1000, its members 1004 and 1006, and other categories, items that may access category 1000. Indicates that the folder or item (not shown) is public and sharable. However, there is no relationship from item 1002 to category 1000, which indicates that category 1000 is private to item 1002 and does not share its membership information with item 1002. Item 1004, on the other hand, has a relationship from itself to 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 means that item 1004 has access to category 1000, other members 1002 and 1006, and other categories, item folders, which may access category 1000. Or it indicates that the item (not shown) is private and not shareable. In contrast to its relationship (or its absence) with items 1002 and 1004, category 1000 has a relationship 1016 from itself to item 1006, and item 1006 is category 1000.

Finally, categories and item folders are items in their own right, and items can be related to each other, so categories can have relationships with item folders and certain alternative implementations. In the example, a category, an item folder, and an item can have relationships with other categories, item folders, and items, respectively. However, in various embodiments, the item folder structure and / or category structure is prohibited from including cycles at the hardware / software interface system level. The item folder and category structure is similar to a directed graph, and this example, which prohibits cycles, is a directed acyclic graph that has no path to start and end at the same vertex, by mathematical definition in the field of graph theory. It is similar to directed acyclic graphs (DAG).

6. Extensibility The storage platform is designed to provide an initial set of schema 340, as described above. But in addition, in at least some embodiments, the storage platform allows customers, including independent software vendors (ISVs), to create new schemas 344, such as new items and types of nested elements. This section describes the mechanism for creating such schemas by extending the item types and nested element types (or simply "elements" types) defined in the initial set of schema 340.

The extension of the initial set of item and nested element types is preferably constrained as follows: ISVs can introduce new types, that is, subtypes of Base.Item. ISVs can introduce new nested element types, that is, subtypes of Base.NestedElement. ISVs can introduce new extensions, subtypes of Base.NestedElement. But, ISVs cannot subtype any type (item, nested element, or extension type) defined by the initial set of storage platform schema 340.

The item types or nested element types defined by the initial set of storage platform schemas do not exactly match the needs of ISV applications, so ISVs need to be able to customize the types. This is made possible by the concept of Extension. Extensions are strongly typed instances, but (a) cannot exist independently and must (b) be attached to an item or nested element.

In addition to addressing the need for schema extensibility, Extension also aims to address the issue of "multi-typing". In some embodiments, the storage platform cannot support multiple inheritance or overlapping subtypes, so the application is an overlapping type instance (for example, the document is a legal document). Extensions can be used as a way to model (and, moreover, confidential documents).

a) Item expansion To provide item extensibility, the data model also defines an abstract type named Base.Extension. This is the root type for the extension types hierarchy. Applications can subtype Base.Extension to create specific extension types.

The Base.Extension type is defined in the base schema as follows:

<maths num="5"><img file="JP4901472B2_D0005.tif" /></maths>

The ItemID field contains the ItemID of the item with which the extension is associated. The item with this ItemID must exist. If the item with the specified ItemID does not exist, the extension cannot be created. When an item is deleted, all extensions with the same ItemID are deleted. This tuple (ItemID, ExtensionID) uniquely defines an extension instance.

The structure of the extended type is similar to the structure of the item type. -The extended type has a field. -Fields can be basic or nested element types. -Extended types can be subtyped.

The following restrictions apply to extended types: · Extensions cannot be the source and target of relationships. -Extended type instances cannot exist independently of an item. Also, -The extended type cannot be used as a field type in the storage platform type definition.

No restrictions are placed on the types of extensions that can be associated with a given item type. Any extension type can extend any item type. When multiple extension instances are attached to an item, they are independent of each other in both structure and behavior.

Extended instances are stored and accessed separately from items. All extension type instances are accessible from the global extension view. You can create efficient queries that return all instances of a given type of extension, regardless of the type of item associated with it. The Storage Platform API provides a programming model that allows you to store, retrieve, and modify item extensions.

Extended types can be subtype-defined types using the storage platform's single inheritance model. Derivation from an extension type creates a new extension type. The structure or behavior of an extension cannot override or replace the structure or behavior of an item type hierarchy. Like item types, Extension type instances can be accessed directly through the view associated with the extension type. The extension's ItemID indicates which item it belongs to and can be used to retrieve the corresponding item object from the global item view. Extensions are considered part of an item for operational integrity purposes. Copy / move, backup / restore, and other common operations defined by the storage platform can also be performed on extensions as part of an item.

Consider the following example. The Contact type is defined in the Windows® typeset.

<maths num="6"><img file="JP4901472B2_D0006.tif" /></maths>

CRM application developers will want to attach CRM application extensions to contacts stored on the storage platform. The application developer will define a CRM extension that contains additional data structures that the application can manipulate.

<maths num="7"><img file="JP4901472B2_D0007.tif" /></maths>

HR application developers will also want to attach additional data with contacts. This data is independent of CRM application data. Again, the application developer can create extensions.

<maths num="8"><img file="JP4901472B2_D0008.tif" /></maths>

CRMExtension and HRExtension are two independent extensions that can be attached to a Contact item. These are created and accessed independently of each other.

In the above example, fields and methods of type CRMExtension cannot override fields or methods in the Contact hierarchy. Note that instances of the CRMExtension type can be attached to item types other than Contact.

When a Contact item is retrieved, the item extension is not automatically retrieved. Given a Contact item, its associated item extensions can be accessed by querying the Global Extensions view for extensions with the same ItemId.

All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of the item to which they belong. All item extensions of an item share the same item ID. In the above example, the Contact item instance and the attached CRMExtension and HRExtension instances share the same ItemID.

The table below outlines the similarities and differences between the Item, Extension, and NestedElement types.

<tables num="1"><img file="JP4901472B2_D0009.tif" /></tables>

b) Extension of NestedElement type Nested element types are not extended by the same mechanism as item types. Nested element extensions are stored and accessed using the same mechanism as nested element type fields.

The data model defines a root for a nested element type named Element.

<maths num="9"><img file="JP4901472B2_D0010.tif" /></maths>

The NestedElement type inherits from this type. The NestedElement element type also defines a field that is a multiset of elements.

<maths num="10"><img file="JP4901472B2_D0011.tif" /></maths>

The NestedElement extension differs from the item extension in the following ways: -Nested element extension is not an extension type. They do not belong to the extension type hierarchy that is rooted in the Base.Extension type. · Nested element extensions are stored with other fields in the item and are not globally accessible. You cannot create a query that retrieves all instances of a given extension type. These extensions are stored in the same way that other nested elements (of the item) are stored. Like other nested sets, NestedElement extensions are stored in UDT. These are accessible through Extension fields of the nested element type. The collection interface used to access multi-valued properties is also used to access and repeat a set of type extensions.

The following table outlines and compares the Item and NestedElement extensions.

<tables num="2"><img file="JP4901472B2_D0012.tif" /></tables>

D. Database engine As mentioned above, the data store is implemented on the database engine. In an embodiment of the invention, the database engine comprises a relational database engine that implements a SQL query language, such as the Microsoft SQL Server engine, which includes object relationship extensions. This section describes the mapping of data models implemented by data stores to relational stores and provides information about the logical APIs consumed by storage platform clients according to the embodiments of the present invention. However, it should be understood that different mappings can be adopted when different database engines are adopted. In fact, in addition to implementing the storage platform's conceptual data model in the relational database engine, it can also be implemented in other types of databases, such as object-oriented and XML databases.

Object-oriented (OO) database systems provide persistence and transactions for programming language objects (eg C ++, Java®, etc.). The concept of "items" in the storage platform corresponds appropriately to "objects" in object-oriented systems, although embedded collections need to be added to objects. Other storage platform concepts support object-oriented systems as well as inheritance and nesting element types. Object-oriented systems usually already support object IDs, so item IDs can be mapped to object IDs. Item behaviors correspond appropriately to object methods. However, object-oriented systems usually lack organizational capabilities and poor search capabilities. Also, object-oriented systems do not provide support for unstructured semi-structured data. Concepts such as relationships, folders, and extensions need to be added to the object data model to support the full storage platform data model described herein. In addition, mechanisms such as promotion, synchronization, notification, and security need to be implemented.

Similar to object-oriented systems, XML databases based on XSD (XML Schema Definition) support a single-inheritance based type system. The item type system of the present invention can also be mapped to an XSD type model. XSD also does not provide support for behavior. The XSD for the item needs to be augmented with respect to the behavior of the item. XML databases handle a single XSD document and lack organizational and extensive search capabilities. As with object-oriented databases, other concepts, such as relationships, and folders need to be incorporated into such XML databases to support the data models described herein. In addition, mechanisms such as synchronization, notification and security need to be implemented.

For the following subsections, some figures are shown to facilitate disclosure of general information. FIG. 13 is a diagram showing a notification mechanism. FIG. 14 shows an example in which two transactions both insert new records into the same B-tree. FIG. 15 is a diagram showing a data change detection process. FIG. 16 is a diagram showing an exemplary directory tree. Figure 17 shows an example where an existing folder in a directory-based file system is moved to a data store on a storage platform.

1. Implementation of a data store using UDT (User Defined Type) In an embodiment of the invention, the relational database engine 314 comprises a Microsoft SQL Server engine in one embodiment and supports embedded scalar types. Built-in scalar types are "native" and "simple". It's native in the sense that users can't define their own types, and it's simple in that it can't encapsulate complex structures. User-defined types (hereafter referred to as UDTs) go beyond the native scalar type system by defining complex structured types that allow the user to extend the type system. Provides a mechanism of extensibility. As defined by the user, UDT can be used anywhere in the type system where the built-in scalar type is used.

According to aspects of the invention, the storage platform schema is mapped to UDT classes in the database engine store. Data store items are mapped to UDT classes that derive from the Base.Item type. Like items, Extensions are also mapped to UDT classes and take advantage of inheritance. The root Extension type is Base.Extension, from which all Extension types are derived.

UDT is a CLR class. It has states (such as data fields) and behaviors (such as routines). UDT is defined using a managed language such as C # or VB.NET. UDT methods and operators can be called in T-SQL for instances of that type. UDT can be either a column type in rows, a routine parameter type in T-SQL, or a variable type in T-SQL.

The mapping of the storage platform schema to the UDT class is fairly straightforward at a high level. Generally, the storage platform schema maps to the CLR namespace. Storage platform types are mapped to CLR classes. CLR class inheritance mirrors storage platform type inheritance, and storage platform properties are mapped to CLR class properties.

2. Item mapping Given the desire for items to be globally searchable, and the support for inheritance and type substitutability in relational databases of the embodiments of the present invention, one possible embodiment of item storage in a database store is , All items will be stored in a single table with columns of type Base.Item. All types of items can be stored using type substitutability, and searches can be filtered by item type and subtype using Yukon's "is of (Type)" operator. ..

However, due to overhead concerns associated with such methods, in the embodiments of the present invention, the items are divided by the top-level type so that each type of item "family" is stored in a separate table. Will be done. Under this partitioning scheme, tables are created for each item type that inherits directly from Base.Item. Types inherited below these are stored in the appropriate type family table using the type substitutability described above. Only the first level of inheritance from Base.Item is treated specially.

The "shadow" table is used to store a copy of the globally searchable properties of all items. This table is maintained by the Update () method of the Storage Platform API, through which all data changes are made. Unlike the type family table, this global item table is not a complete UDT item object, but contains only the top-level scalar property of the item. This global item table allows navigation to the item objects stored in the type family table by exposing the ItemID and TypeID. ItemID generally uniquely identifies an item in a data store. TypeIDs can be mapped to views containing type names and items using metadata, which is not described herein. Finding an item by its ItemID is a common operation in global item tables and other contexts, so the GetItem () function is provided to retrieve an item object given the item's ItemID. To.

For convenience of access and to conceal the details of the embodiment to the extent possible, all queries for items can be for views built on the item table described above. In particular, views can be created for each item type against the appropriate type family table. These type views allow you to select all items of related types, including subtypes. For convenience, in addition to UDT objects, views can expose (make visible) columns for all top-level fields of that type, including inherited fields.

3. Extended mapping Extensions are very similar to items and have some of the same requirements. As another route type that supports inheritance, Extensions are susceptible to many of the same considerations and trade-offs in storage. Therefore, a similar type of family mapping applies to the extension rather than the single-table method. Of course, in other embodiments, the single table method can also be used. In an embodiment of the invention, the Extension is strictly associated with an item by ItemID and includes an ExtensionID that is unique in the context of the item. As with the item, a function is provided to retrieve the extension given that identification. It consists of an ItemID and ExtensionID pair. Views are created for each Extension type. This is similar to the item type view.

4. Nested Element mapping Nested elements are types that can be embedded in items, extensions, relationships, or other nested elements to form deeply nested structures. Like items and extensions, nested elements are implemented as UDTs, but they are stored within items and extensions. Therefore, the nested element does not have a storage mapping beyond the container for that item and extension. That is, there are no tables in the system that directly store instances of type NestedElement, and no views specifically dedicated to nested elements.

5. Object ID} (identity) Each entity in the data model, that is, each item, extension, and relationship, has a unique key value. An item is uniquely identified by its ItemId. Extension is uniquely identified by the composite key of (ItemId, ExtensionId). Relationships are uniquely identified by the composite key of (ItemId, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.

6. Naming SQL objects All objects created in the data store can be stored with a SQL schema name derived from the storage platform schema name. For example, a storage platform base schema (often referred to as "Base") can be typed with a "[System.Storage]" SQL schema, such as "[System.Storage] .Item". The generated name is prefixed with a qualifier to eliminate naming conflicts. If necessary, the exclamation point character (!) Is used as a delimiter for each logical part of the name. The following table outlines the naming conventions used for objects in the data store. Each schema element (item, extension, relationship and view) is listed with a decorated naming convention used to access the instances in the data store.

<tables num="3"><img file="JP4901472B2_D0013.tif" /></tables>

7. Column naming When mapping an object model into a store, additional information stored with the application object can cause naming conflicts. To prevent naming conflicts, all non-type specific columns (columns that do not map directly to named properties in the type declaration) are prefixed with an underlined (_) character. In the embodiments of the present invention, the underlined (_) character is not allowed as the starting character of the identifier property. In addition, all properties of the storage platform type or schema element (such as relationships) must have the first letter capitalized to unify the naming between the CLR and the data store.

8. Search view Views are provided by storage platforms to search for stored content. SQL views are provided for each item and extension type. In addition, views are provided to support relationships and views (as defined by the data model). All SQL views and underlying tables in the storage platform are read-only. Data can be stored or modified using the Update () method of the Storage Platform API, as described in more detail below.

Each view explicitly defined in the Storage Platform Schema (defined by the schema designer and not automatically generated by the Storage Platform) is a named SQL view [&lt;schema-name&gt;]. [ It can be accessed by View! &lt;View-name&gt;]. For example, a view named "BookSales" in the schema "AcmePublisher.Books" is accessible using the name "[AcmePublisher.Books]. [View! BookSales]". The output format of a view is per-view-based custom (defined by any query provided by the party defining the view), so columns are mapped directly based on the schema view definition.

All SQL search views in the storage platform data store use the following ordering rules for columns. -Logical "Key" column of view results such as ItemId, ElementId, RelationshipId · Metadata information about the type of result, such as TypeId · Change tracking columns such as Create Version, Update Version, etc. · Type-specific columns (declared type properties) · Type-specific views (family views) also include object columns that return objects Members of each type family can be searched using a set of item views, with one view for each item type in the data store. FIG. 28 is a diagram illustrating the concept of the item search view.

a) Item Each item search view contains a row for each instance of an item of its own type or its subtypes. For example, a View of Document can return instances of Document, LegalDocument, and ReviewDocument. Taking this example, the item view can be conceptually explained as shown in Figure 29.

(1) Master item search view Each instance of the storage platform data store defines a special item view called the master item view. This view provides summary information about each item in the data store. The view provides one column for each item type property, a column that describes the type of item, and multiple columns that are used to provide change tracking and synchronization information. The master item view is identified in the data store using the name "[System.Storage]. [Master! Item]".

<tables num="4"><img file="JP4901472B2_D0014.tif" /></tables>

(2) Type-defined item search view Each item type also has a search view. Similar to the root item view, but this view also provides access to the item object via the "_Item" column. Each type-defined item search view is identified within the data store by using the name [schemaName]. [ItemTypeName]. For example, [AcmeCorp.Doc]. [OfficeDoc].

<tables num="5"><img file="JP4901472B2_D0015.tif" /></tables>

b) Item Extension All item extensions in the WinFS Store are also accessible using the search view.

(1) Master Extension search view Each instance of the data store defines a special extension view called the "master extension view". This view provides summary information about each Extension in the data store. The view has one column for each Extension property, a column that describes the type of Extension, and multiple columns that are used to provide change tracking and synchronization information. The master extension view is identified within the data store using the name "[System.Storage]. [Master! Extension]".

<tables num="6"><img file="JP4901472B2_D0016.tif" /></tables>

(2) Type-defined Extension search view Each Extension type also has a search view. Similar to the master extension view, but this view also provides access to the item object via the Extension column. Each type-defined extended search view is identified within the data store using the name [schemaName]. [Extension! ExtensionTypeName]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt].

<tables num="7"><img file="JP4901472B2_D0017.tif" /></tables>

c) Nested element All nested elements are stored within an item, extension or relationship instance. Therefore, they can be accessed by querying the appropriate item, extension, or relationship search view.

d) Relationship As mentioned earlier, relationships form the basic unit that links items within a storage platform data store.

(1) Master relationship search view Each data store provides a master relationship view. This view provides information about all relationship instances in the data store. The master relationship view is identified within the data store using the name "[System.Storage]. [Master! Relationship]".

<tables num="8"><img file="JP4901472B2_D0018.tif" /></tables>

(2) Relationship instance extended search view Each declared relationship also has a search view that returns all instances of a particular relationship. Similar to the master relationship view, but this view also provides named columns for each property of the relationship data. Each relationship instance search view is identified within the data store using the name [schemaName]. [Relationship! RelationshipName]. For example, [AcmeCorp.Doc]. [Relationship! Document Author].

<tables num="9"><img file="JP4901472B2_D0019.tif" /></tables>

e) 9. Update All views in the storage platform data store are read-only. You must use the ProcessOperation or ProcessUpdategram methods of the Storage Platform API to create a new instance of a data model element (item, extension or relationship), or to update an existing instance. The ProcessOperation method is a single stored procedure defined by the data store, which consumes an "operation" detailing the action to be taken. The ProcessUpdategram method is a stored procedure that populates an ordered set of operations known as "updategram", which collectively details the set of actions to be performed.

The operation format is extensible and provides a variety of operations on schema elements. Common operations include: 1. Item operation: a.CreateItem (create a new item in the context of an embedded or retained relationship) b. UpdateItem 2. Relationship operations: a.CreateRelationship (creates an instance of a reference or retention relationship) b. Update Relationship c.DeleteRelationship 3. Extension operations: a.CreateExtension b. Update Extension c.DeleteExtension

10. Change tracking and toomstone Change tracking and toomstone services are provided by the data store, which will be described in more detail below. This section provides an overview of change tracking information published within the data store.

a) Change tracking Each search view provided by the data store contains columns used to provide change tracking information. This column is common across all items, extensions and relationship views. Storage platform schema views, explicitly defined by the schema designer, do not automatically provide change tracking information. Such information is provided indirectly through the search view on which the view itself is constructed.

For each element in the data store, change tracking information is provided from two locations: the "master" element view and the "type-defined" element view. For example, change tracking information for the AcmeCorp.Document.Document Item type can be found in the master item view "[System.Storage]. [Master! Item]" and the type-defined item search view [AcmeCorp.Document]. [Document]. It is available.

(1) Tracking changes in the "master" search view The change tracking information in the master search view provides information about the creation and update version of the element, the synchronization partner who created the element, the synchronization partner who last updated the element, and the version number from each partner for creation and update. Partners in a synchronous relationship (discussed below) are identified by a partner key. A single UDT object named ChangeTrackingInfo of type [System.Storage.Store] .ChangeTrackingInfo contains all this information. This type is defined in the System.Storage schema. ChangeTrackingInfo is available in all global search views for items, extensions and relationships. The type definition of ChangeTrackingInfo is as follows.

<maths num="11"><img file="JP4901472B2_D0020.tif" /></maths>

These properties contain the following information:

<tables num="10"><img file="JP4901472B2_D0021.tif" /></tables>

(2) Change tracking for "type-defined" search views In addition to providing the same information as the global search view, each type-defined search view provides additional information that records the synchronization state of each element of the synchronization topology.

<tables num="11"><img file="JP4901472B2_D0022.tif" /></tables>

b) Toomstone The data store provides toomstone information for items, extensions, and relationships. Toomstone views provide information about live entities and entities contained in toomstones (items, extensions and relationships) in one place. Item and extension toomstone views do not provide access to the corresponding objects, but relationship toomstone views provide access to relationship objects (for relationships in toomstone, that relationship). Ship object is NULL).

(1) Item tombstone Item toomstones are retrieved from the system via the view "[System.Storage]. [Tombstone! Item]".

<tables num="12"><img file="JP4901472B2_D0023.tif" /></tables>

(2) Expansion tombstone The extended tombstone is retrieved from the system via the view "[System.Storage]. [Tombstone! Extension]". The Extension change tracking information is similar to the information provided for the item, but with the addition of the ExtensionId property.

<tables num="13"><img file="JP4901472B2_D0024.tif" /></tables>

(3) Relationship Tombstone Relationship tombstones are retrieved from the system via the view "[System.Storage]. [Tombstone! Relationship]". The relationship tombstone information is similar to that provided by the Extension. However, additional information is provided in the target ItemRef of the relationship instance. In addition, the relationship object is selected.

<tables num="14"><img file="JP4901472B2_D0025.tif" /></tables>

(4) Toomstone cleanup To prevent the endless growth of toomstone information, the data store provides a toomstone cleanup task. This task determines when the tombstone information can be discarded. This task calculates the bounds of the local create / update version and then truncates the tombstone information by discarding all previous tombstone versions.

11. Helper API and functions Basic mapping also provides some helper functions. These functions are provided to assist in common operations on the data model.

a) Function [System.Storage] .GetItem

<maths num="12"><img file="JP4901472B2_D0026.tif" /></maths>

b) Function [System.Storage] .GetExtension

<maths num="13"><img file="JP4901472B2_D0027.tif" /></maths>

c) Function [System.Storage] .GetRelationship

<maths num="14"><img file="JP4901472B2_D0028.tif" /></maths>

12. Metadata There are two types of metadata represented by the store: instance metadata (such as the type of item) and type metadata.

a) Schema metadata Schema metadata is stored in the data store as an instance of the item type from the Meta schema.

b) Instance metadata Instance metadata is used by the application to query the type of item and find the Extension associated with the item. Given the ItemId of an item, the application queries the global item view to return the type of the item and uses that value to return information about the declared type of the item. You can query the view. For example:

<maths num="15"><img file="JP4901472B2_D0029.tif" /></maths>

E. Security In general, all available objects adjust their access rights using the access mask format shown in Figure 26. In this format, the lower 16 bits are for object-specific permissions, the next 7 bits are for standard permissions (applies to most object types), and the upper 4 bits are for generic permissions. Used to specify, where each object type can be mapped to standard and object-specific permission settings. The ACCESS-SYSTEM-SECURITY bit corresponds to the right to access the object's SACL.

In the access mask structure of FIG. 26, item-specific access rights are placed in the object-specific access rights section (lower 16 bits). In an embodiment of the invention, the storage platform exposes two sets of APIs, Win32 and the storage platform API, to manage security, and thus files to motivate the design of storage platform object-specific permissions. -It is necessary to consider system object-specific access rights.

The security model of the storage platform of the present invention is described in detail in the related application previously incorporated by reference herein. In this regard, Figure 27 (parts a, b, and c) shows a new, similarly protected area of security cut from an existing area of security by one embodiment of the security model.

F. Notification and change tracking According to another aspect of the invention, the storage platform provides a notification feature that allows an application to track data changes. This feature is primarily intended for applications that maintain a volatile state or execute business logic with respect to data change events. The application registers notifications about items, item extensions and item relationships. Notifications are delivered asynchronously after the data change is confirmed. Applications can filter notifications by item, extension and relationship type, as well as the type of operation.

According to one embodiment, the storage platform API322 provides two types of interfaces for notification. First, the application registers simple data change events triggered by changes to items, item extensions and item relationships. Second, the application creates a "watcher" object that monitors the set of items, the item extension, and the relationships between the items. The state of the watcher object can be saved and recreated after a system failure or after the system goes offline for an extended period of time. A single notification can reflect multiple updates.

Details regarding this function are described in the relevant applications incorporated herein by reference above.

G. Synchronization According to another aspect of the invention, the storage platform provides a synchronization service 330, which is (i) flexible for multiple instances of the storage platform, each with its own data store 302. A third that allows parts of its content to be synchronized according to a set of rules, and (ii) synchronizes the data store of the storage platform of the present invention with other data sources that implement proprietary protocols. -Provide infrastructure for parties.

Synchronization between storage platforms occurs between the groups of replicas involved. For example, see Figure 3, where data store 302 and another remote data store on storage platform 300, probably under the control of another instance of the storage platform running on another computer system. It may be desirable to provide synchronization with and from 338. The total number of memberships in this group does not necessarily have to be known to a given replica at a given time.

Different replicas can make changes independently (ie, in parallel). The synchronization process is defined to make all replicas aware of changes made by other replicas. This synchronization feature is essentially multi-master.

The synchronization function of the present invention allows the replica to: · Determine the changes that another replica recognizes · Request information about changes that this replica does not recognize · Communicate information about changes that other replicas do not recognize · Determine when two changes are in conflict with each other · Apply changes locally · Communicate conflict resolution to other replicas to ensure focusing · Resolve conflicts based on the specified conflict resolution policy 1. Synchronization between storage platforms Storage Platform Synchronization Service 330's primary use is to synchronize multiple instances of a storage platform (with their respective data stores). The synchronization service works at the level of the storage platform schema (rather than the tables underlying Database Engine 314). So, for example, "Scopes" are used to define synchronization sets as described below.

The synchronization service operates on the principle of "net changes". The synchronization service sends the final results of these operations, rather than recording and sending individual operations (as in transaction replication), to deliver the results of multiple operations to a single result. Integrate into changes.

Synchronization services generally do not consider transaction boundaries. That is, if two changes are made to one storage platform data store in a single transaction, there is no guarantee that these changes will be applied atomically to all other replicas, one without the other. May be reflected. The exception to this principle is that if two changes are made to the same item within the same transaction, these changes are guaranteed to be atomically transmitted to and applied to other replicas. Therefore, an item is a unit of integrity for a synchronization service.

a) Sync control application Any application can connect to the synchronization service and initiate a synchronization operation. Such an application provides all the parameters needed to perform synchronization (see synchronization profile below). Such an application is referred to herein as a Synchronous Control Application (SCA).

When synchronizing two platform instances, SCA initializes the synchronization on one side. The SCA notifies the local synchronization service to synchronize with the remote partner. On the other side, the synchronization service is invoked by a message sent by the synchronization service from the source machine. It responds based on the persistent configuration information on the destination machine (see mapping below). The synchronization service can run on schedule or in response to events. In such cases, the synchronization service that implements the schedule would be SCA.

Two steps need to be taken to enable synchronization. First, the schema designer needs to annotate the storage platform schema with the appropriate synchronization semantics (with change units as described below). Second, synchronization needs to be properly configured for all machines that have an instance of the storage platform that participates in the synchronization (as described below).

b) Schema annotation The basic concept of synchronization services is the basic concept of change units. The unit of change is the smallest part of the schema that is individually tracked by the storage platform. For every change unit, the synchronization service can determine whether it has changed or has not changed since the last synchronization.

Specifying change units in the schema serves several purposes. First, it determines how much the synchronization service interacts on the wire. If changes are made inside the change unit, the entire change unit is sent to other replicas because the synchronization service does not know which part of the change unit has changed. Second, this determines the subdivision of conflict detection. If two simultaneous changes (these terms are defined in detail in the sections below) are made in the same change unit, the synchronization service will conflict. On the other hand, if simultaneous changes are made to different units of change, conflicts do not occur and the changes are automatically merged. Third, this has a significant impact on the amount of metadata held by the system. Much of the synchronization service metadata is retained for each change unit. Therefore, reducing the change unit increases the synchronization overhead.

To define the units of change, we need to find the right trade-offs. For that reason, synchronization services allow schema designers to participate in this process.

In one embodiment, the synchronization service does not support change units larger than an element. However, synchronization services support the ability of schema designers to specify units of change that are smaller than an element, that is, the ability to group multiple attributes of an element into separate units of change. In that example, this is done using the following syntax:

<maths num="16"><img file="JP4901472B2_D0030.tif" /></maths>

c) Synchronous configuration A group of storage platform partners who want to synchronize certain parts of their data is called the synchronization community. Community members want to stay in sync, but they don't necessarily have to represent the data in exactly the same way. That is, the synchronization partner can transform the data that is being synchronized.

In a peer-to-peer scenario, it is impractical for a peer to maintain a transformation mapping for all of its partners. Instead, the synchronization service defines a "community folder". A community folder is an abstraction that represents a virtual "shared folder" that all community members are in sync with.

This concept can be explained in an easy-to-understand manner by illustration. If Joe wants to synchronize the My Documents folders on several computers, Joe defines a community folder named, for example, Joes Documents. Joe then configures the mapping between the virtual Joes Documents folder and the local My Documents folder on all computers. From then on, when Joe's computers synchronize with each other, they'll be talking about Joes Documents documents instead of local items. In this way, Joe's all computers understand each other without having to know what the other computers are, and the community folder becomes the common language of the sync community.

Configuring the synchronization service consists of three steps: (1) defining the mapping between local and community folders, and (2) what is synchronized (for example, what is synchronized): In the step of defining a synchronization profile that determines which subset should be sent and which one was received, and (3) in the step of defining a schedule for various synchronization profiles to run or be run manually. is there.

(1) Community folder-mapping Community folder mappings are stored as XML configuration files on individual machines. Each mapping has the following schema. / mappings / communityFolder This element names the community folder that is the target of this mapping. The name follows the syntax rules for folders. / mappings / localFolder This element names the local folder to which this mapping is translated. The name follows the syntax rules for folders. The folder must always exist for the mapping to take effect. Items in this folder are considered for this per-mapping synchronization. / mappings / transformations This element defines how to convert items from community folders to local folders and vice versa. If it is missing or empty, no conversion will occur. In particular, this means that the IDs are not mapped. This configuration is primarily useful when creating a cache of folders. / mappings / transformations / mapIDs This element requires that a newly generated local ID be assigned to all mapped items from the community folder, rather than reusing the community ID. The synchronous runtime maintains the ID mapping and translates the item back and forth. / mappings / transformations / localRoot This element requires all root items in the community folder to be children of the specified root. / mappings / runAs This element controls the authority to process requests for this mapping. If not, the sender is assumed. / mappings / runAs / sender The presence of this element indicates that the sender of the message to this mapping must be using a pseudonym, and as a result, the request must be processed under that certificate.

(2) Profile A synchronization profile is the complete set of parameters required to initiate synchronization. It is supplied by the SCA to the synchronization runtime to initiate synchronization. The synchronization properties for synchronization between storage platforms include the following information: · Serves as a local folder, source and destination for changes. · Remote folder name to synchronize --This folder must be published by the remote partner by the mapping method defined above. Direction-The synchronization service supports send-only, receive-only, and send / receive synchronization. · Local filter --Select local information to send to remote partners. Represented as a storage platform query to a local folder. · Remote filter--Select remote information to retrieve from a remote partner. --Represented as a storage platform query to the community folder. · conversion -- Defines how to convert between items and local formats. · Local security--Changes retrieved from a remote endpoint apply with the permission of the (impersonated) remote endpoint or with the permission of the user who initiated the synchronization locally. Specify whether it will be done · Conflict resolution policy --Specifies whether the conflict is rejected, logged, or resolved automatically--In the latter case, specify the conflict resolver to use and its configuration parameters.

The synchronization service provides a runtime CLR class that makes it easy to build synchronization profiles. Profiles can also be serialized into and from XML files for easy storage (often with a schedule). However, there is no standard location on the storage platform for all profiles to be stored. SCA allows you to freely build profiles on the fly without sticking. Note that it is not necessary to have a local mapping to initiate the synchronization. All synchronization information can be specified in the profile. However, mapping is required to respond to synchronization requests initiated by the remote side.

(3) Schedule In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it relies on other components to perform this task. It is the Windows® Scheduler that comes with the Microsoft Windows® operating system. The synchronization service includes a command line utility that acts as an SCA and triggers synchronization based on the synchronization profile stored in the XML file. This utility makes it very easy to configure the Windows Scheduler to perform synchronization on schedule or in response to events such as user logon or logoff.

d) Handling conflicts Conflict handling in the synchronization service consists of the following three stages. (1) Conflict detection at the time of change application-This step determines if the change can be safely applied, (2) Automatic conflict resolution and logging-This step (performed immediately after a conflict is detected) ) During the automatic conflict resolver consults to see if the conflict can be resolved-if it cannot be resolved, the conflict is optionally logged, and (3) conflict checking and resolution-this step is a conflict. Occurs when is logged and occurs outside the context of the synchronization session-at this point, the logged conflicts can be resolved and removed from the log.

(1) Conflict detection In one embodiment, the synchronization service detects two types of conflicts: knowledge-based and constraint-based.

(a) Knowledge-based contention Knowledge base conflicts occur when two replicas make independent changes to the same change unit. Two changes are called independent changes if they are made without mutual knowledge, in other words, if the first version is not recognized by the second version, or vice versa. The synchronization service automatically detects all such conflicts based on replica knowledge, as described above.

It may be helpful to think of the conflict as a fork (branch) in the version history of the change unit. If there is no conflict within the life of the change unit, then the version history is a simple chain. Each change occurs after each previous (one) change. In the case of knowledge-based contention, the two changes occur in parallel, splitting the chain into a version tree.

(b) Constraint-based contention Independent changes, when applied together, may violate consistency constraints. For example, two replicas that create files with the same name in the same directory can cause such conflicts.

Constraint-based contention occurs with two independent changes (similar to knowledge-based contention), but does not affect the same unit of change. Rather, they affect different units of change only if there are constraints in between.

The synchronization service detects constraint violations at the time of applying changes and automatically raises constraint-based conflicts. Resolving constraint-based conflicts usually requires custom code that modifies changes in a way that does not violate the constraints. The synchronization service does not provide a generic mechanism for doing this.

(2) Conflict handling When a conflict is detected, the synchronization service can take one of three actions (selected by the synchronization initiator of the synchronization profile): (1) Reject the change and send it back to the sender, (2) Log the conflict in the conflict log, or (3) Resolve the conflict automatically.

If the change is rejected, the synchronization service behaves as if the change did not reach the replica. Negative responses are sent back to the source. This resolution policy is primarily useful for headless replicas (such as file servers) where it is not possible to log conflicts. Instead, such replicas force other replicas to handle the conflict by rejecting the change.

The synchronization initiator configures conflict resolution in its synchronization profile. The synchronization service supports a combination of multiple conflicting resolvers in a single profile in the following ways: The first is to specify that the list be tested one after another until one of the list of competing resolvers succeeds. The second is to associate conflict resolvers with conflict types, for example, direct update-update knowledge base conflicts to one resolver, and all other conflicts to the log.

(a) Automatic conflict resolution The synchronization service provides some default conflict resolvers. The following can be mentioned. · Local-wins: Ignore incoming changes if there is a conflict with locally stored data · Remote-wins: Ignore local data if there is a conflict with incoming changes · Last-writer-wins: Choose either local-wins or remote-wins for each change unit based on the change timestamp (note that synchronization services are generally clock value independent. This conflict. Resolver is the only exception to that rule) Deterministic: Choose the winner in a way that is guaranteed to be the same for all replicas (otherwise it doesn't make sense)-one example of this synchronization service is a lexicographic comparison of partner IDs. Use to implement this feature In addition, ISVs can implement and install their own competing resolvers. The custom conflict resolver will accept the configuration parameters. Such parameters must be specified by the SCA in the conflict resolution section of the synchronization profile.

When a conflict resolver handles a conflict, it returns to the runtime a list of operations that need to be performed (instead of conflicting changes). The synchronization service then applies these operations by properly adjusting the remote knowledge to include what the conflict handler has considered.

Another conflict may be detected while applying the resolution. In such cases, the new conflict must be resolved before the original processing resumes.

If you think of a conflict as a branch in the version history of an item, conflict resolution can be thought of as a join that combines the two branches to form a single point. Therefore, conflict resolution turns the version history into a DAG.

(b) Conflict logging A very special kind of competing resolver is the Conflict Logger. The synchronization service logs the conflict as an item of type ConflictRecord. These records are related to the original conflicting item (unless the item itself has been deleted). Each conflict record has knowledge of the incoming change that caused the conflict, the type of conflict (update-update, update-delete, delete-update, insert-insert, or constraint), and the version of the incoming change and the replica that sends it. Includes. Logged conflicts can be used for inspection and resolution as described below.

(c) Conflict inspection and resolution The synchronization service provides the application's API to examine the conflict log and suggest resolution of conflicts in it. The API allows an application to enumerate all conflicts, or conflicts related to a given item. It also allows such applications to resolve logged conflicts in one of the following ways: (1) Remote win--accepts logged changes and overwrites conflicting local changes, (2) local win--ignores the conflicting part of the logged changes, and (3) ) Propose new changes--Propose merges where the application resolves conflicts at its own discretion. When the application resolves the conflict, the synchronization service removes them from the log.

(d) Replica focusing and conflict resolution propagation In complex synchronization scenarios, the same conflict may be detected in multiple replicas. When this happens, the following things can happen: (1) Conflicts can be resolved on one replica and resolutions are sent to the other replica, (2) Conflicts are automatically resolved on both replicas, or (3) Conflicts are both Manually resolved (through the conflict checking API) on a replica of.

To ensure focus, the synchronization service forwards conflict resolution to other replicas. When a conflict-resolving change reaches the replica, the synchronization service automatically finds and eliminates conflicting records in the log that are resolved by this update. In that sense, conflict resolution in one replica combines all other replicas.

If different winners are selected by different replicas for the same conflict, the synchronization service applies the principle of combining conflict resolutions to choose one of the two solutions to automatically win the other. .. Winners are chosen in a deterministic way that is guaranteed to always produce the same results (one example uses replica ID lexicographic comparison).

If different replicas propose different "new changes" to the same conflict, the synchronization service treats this new conflict as a special conflict and uses ConflictLogger to prevent it from propagating to other replicas. Such situations generally occur with manual conflict resolution.

2. Synchronization to non-storage platform data store According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for ISVs that allows the storage platform to synchronize with existing systems such as Microsoft Exchange, AD, Hotmail, etc. Implement the adapter. The sync adapter benefits from the many Sync services provided by the sync service as described below.

Despite its name, the sync adapter does not need to be implemented as a plug-in on some storage platform architectures. If desired, the "synchronization adapter" may simply be an application that utilizes the synchronization service runtime interface to obtain services and applications such as change enumeration.

To make it easier for others to configure synchronization to a given backend and perform synchronization, the creator of the synchronization adapter is given a synchronization profile as described above to perform synchronization. It is recommended to expose the standard sync adapter interface. This profile provides configuration information to the adapter, which passes some of it to the synchronization runtime to control runtime services (for example, folders to synchronize).

a) Sync Service The synchronization service provides some Sync services to adapter creators. From now on, in this section, it is convenient to refer to the machine with which the storage platform is synchronizing as the "client" and the non-storage platform backend with which the adapter communicates as the "server".

(1) Change Enumeration Based on the change tracking data held by the synchronization service, the change enumeration makes it easy for the synchronization adapter to enumerate the changes that have occurred in the data store folder since the last synchronization attempted by this partner.

The changes are listed based on the concept of "anchors". This is an opaque structure that represents information about the previous synchronization. Anchors take the form of storage platform knowledge, as described in the previous section. Sync adapters that use the change enumeration service fall into two broad categories: those that use "stored anchors" and those that use "supplied anchors."

This distinction is based on whether information about the previous synchronization is stored on the client or on the server. In many cases, it is easier for the adapter to store this information on the client, and the backend is often unable to store this information conveniently. On the other hand, if multiple clients synchronize to the same backend, storing this information in the client is inefficient and in some cases incorrect, because one client is already up to the server and the other client Sometimes you go unnoticed by the changes you've pushed up. If the adapter uses an anchor stored on the server, the adapter must supply it back to the storage platform at the time of the change enumeration.

In order for the storage platform to hold anchors (local or remote storage), the storage platform must be aware of the changes successfully applied on the server. These, and only these, changes can be included in the anchor. During the change enumeration, the sync adapter uses the acknowledgment interface to report which changes were successfully applied. At the end of synchronization, the adapter using the supplied anchor must read the new anchor (which captures all successfully applied changes) and send it to its backend.

Adapters often need to store adapter-specific data along with items to insert into the storage platform. Common examples of such data are remote IDs and remote versions (timestamps). The synchronization service provides a mechanism to store this data, and the change enumeration provides a mechanism to receive this special data with the returned changes. This eliminates the need for the adapter to query the database again in most cases.

(2) Change Application Change application allows a synchronization adapter to apply the changes received from its backend to the local storage platform. The adapter is expected to translate the changes into the storage platform schema. FIG. 24 is a diagram showing the process by which the storage platform API class is generated from the storage platform schema.

The main function of Change Application is to detect conflicts automatically. As in the case of synchronization between storage platforms, contention is defined as two duplicate changes being made unaware of each other. When using change apply, the adapter must specify the anchor on which the conflict detection was performed. Applying changes raises conflicts when duplicate local changes that are not covered by the knowledge of the adapter are detected. As with the change enumeration, the adapter can use a stored anchor or a supplied anchor. Modify application supports efficient storage of adapter-specific metadata. Such data can be connected to changes applied by the adapter and can also be stored by the synchronization service. This data will be returned in the next change enumeration.

(3) Conflict resolution The conflict resolution mechanism described above (logging and automatic resolution options) can also be used with synchronization adapters. The synchronization adapter can specify a conflict resolution policy when applying changes. If specified, the conflict is passed to the specified conflict handler and resolved (if possible). Conflicts can also be logged. It is also possible for the adapter to detect conflicts when trying to apply local changes to the backend. In such cases, the adapter can also pass the conflict to the synchronization runtime so that it can be resolved according to the policy. In addition, the synchronization adapter can request that conflicts detected by the synchronization service be sent back for processing. This is especially useful when the backend can store or resolve conflicts.

b) Adapter mounting Some "adapter" is simply an application that uses the runtime interface, but it is recommended that the adapter implement the standard adapter interface. With these interfaces, synchronization control applications require the adapter to perform synchronization according to a given synchronization profile, cancel running synchronization, and progress reports on running synchronization (percentage completed). Will be able to receive.

3. Security Synchronization services strive to bring as little as possible into the security model implemented by the storage platform. Existing permissions are used instead of defining new permissions for synchronization. Specifically, it is as follows. Anyone who can read a data store item can enumerate changes to that item. Anyone who can write to a data store item can apply changes to that item. Anyone who can extend a data store item can associate synchronous metadata with that item.

The synchronization service does not retain secure authorship information. If the changes were made to Replica A by User U and transferred to Replica B, the fact that the changes were made first by A (or by U) is lost. If B forwards this change to Replica C, it is done under B's privileges, not A's. This introduces the constraint that changes made by other replicas cannot be transferred if the replica is not entrusted with making its own changes to the item.

When the synchronization service is started, this is done by the synchronization control application. The synchronization service impersonates the SCA's ID and performs all operations (locally and remotely) under that ID. Note, for example, User U cannot force a local synchronization service to retrieve changes from the remote storage platform for items for which User U does not have read access.

4. Manageability Monitoring a distributed community for replicas is a complex issue. The synchronization service can use a "sweep" algorithm to collect and distribute information about the state of the replica. The properties of the sweep algorithm ensure that information about all configured replicas is ultimately collected and that failed (non-responsive) replicas are detected.

This community-wide monitoring information is available to all replicas. The monitoring tool can be run on an arbitrarily selected replica and inspect this monitoring information to make administrative decisions. Configuration changes must be made directly on the affected replica.

H. Traditional file system interoperability As mentioned above, the storage platform of the present invention is intended to be incorporated as an integral part of a hardware / software interface system of a computer system, at least in some embodiments. For example, the storage platform of the present invention is the operating system Microsoft. It can also be incorporated as an integral part of an operating system, such as the Windows® family. In its capacity, the storage platform API becomes part of the operating system API through which application programs interact with the operating system. Therefore, the storage platform is through which application programs store information in the operating system, so that the storage platform's item-based data model becomes the traditional file system of such operating systems. It will replace it. For example, when incorporated into the Microsoft Windows® family of operating systems, the storage platform can also replace the NTFS file system implemented in that operating system. Currently, the application program is Win32 published by the Windows® family of operating systems. You are accessing the NTFS file system services through the API.

However, in order for the storage platform of the present invention to completely replace the NTFS file system, it will be necessary to recode existing Win32-based application programs, and such recoding is desirable. Recognizing that it may not be, it would be beneficial for the storage platform of the present invention to provide some interoperability with existing file systems such as NTFS. Therefore, in one embodiment of the invention, the storage platform allows application programs that rely on the Win32 programming model to access the contents of both the storage platform's data store and the traditional NTFS file system. To do so. To this end, the storage platform uses a naming convention that is a superset of the Win32 naming convention to facilitate interoperability. In addition, the storage platform supports access to files and directories stored within storage platform volumes through the Win32 API.

Details regarding this functionality are described in the relevant applications incorporated herein by reference above.

I. Storage Platform API The storage platform provides APIs that allow applications to access the aforementioned storage platform features and features to access items stored in the data store. This section describes one embodiment of the storage platform API for storage platforms according to the present invention. Details regarding this functionality have been described earlier in the relevant applications incorporated herein by reference, but some of that information is summarized below for convenience.

With reference to FIG. 18, the containing folder is an item that houses a retention relationship to another item and corresponds to the general concept of a file system folder. Each item is "contained" in at least one containing folder.

FIG. 19 shows the basic architecture of the storage platform API according to the embodiment of the present invention. The Storage Platform API can also use SQL Client 1900 to communicate with the local data store 302, and SQL Client 1900 to communicate with a remote data store (for example, Data Store 340). The local store 302 can also communicate with the remote data store 340 using DQP (Distributed Query Processor) or through the storage platform synchronization service (Sync) described above. The storage platform API 322 also acts as a bridge API for data store notifications, passing application subscriptions to the notification engine 332 and delivering routing notifications to applications (eg applications 350a, 350b, 350c), as described above. Pass to. In one embodiment, the storage platform API322 is Microsoft You can also define a limited "provider" architecture to access the data in Exchange and AD.

Figure 20 outlines the various components of the Storage Platform API. The storage platform API has the following components: (1) Data class 2002 representing storage platform elements and item types, (2) Runtime framework 2004 that manages object persistence and provides support for class 2006, and (3) Storage platform schema Tools used to generate CLR classes from 2008.

The hierarchy of classes generated by a given schema is directly reflected in the hierarchy of types within that schema. As an example, consider the item types defined in the contact schema as shown in Figures 21A and 21B.

Figure 22 shows the runtime framework for operations. The runtime framework works as follows: 1. Application 350a, 350b, or 350c binds to an item in the storage platform. 2. Framework 2004 creates an ItemContext object 2202 corresponding to the bound item and returns it to the application. 3. The application submits Find to this ItemContext to get a collection of items. The returned collection is conceptually an object graph 2204 (by relationship). 4. The application modifies, deletes, and inserts data. 5. The application saves the changes by calling the Update () method.

Figure 23 shows the execution of the "Find All" operation.

Figure 24 shows the process by which the storage platform API class is generated from the storage platform schema.

FIG. 25 is a diagram showing the schema on which the File API is based. The Storage Platform API has a namespace to handle file objects. This namespace is called System.Storage.Files. The data members of the System.Storage.Files class reflect directly on the information stored in the storage platform store. This information is either "promoted" from a file system object or created natively using the Win32 API. System.Storage.Files has two classes, FileItem and DirectoryItem. The members of these classes and their methods can be easily predicted by looking at the schema diagram in Figure 25. FileItem and DirectoryItem are read-only from the Storage Platform API. To change these, you need to use the Win32 API or System.IO classes.

With respect to APIs, a programming interface (or simply an interface) is any mechanism, process that allows one or more segments of code to communicate or access the functionality provided by one or more other segments of code. , Can be thought of as a protocol. Alternatively, the programming interface is one or more mechanisms, methods, function calls, modules, of a system component that can connect to one or more mechanisms, methods, function calls, modules, etc. of other components. You can think of it as an object. In the previous sentence, the term "code segment" is intended to include one or more instructions or lines of code, and the applicable term, whether the code segment is compiled separately. Whether or whether the code segment is provided as source, intermediate, or object code, whether the code segment is used by a runtime system or process, whether they are located on the same or different machines, or more than one. Whether the functionality that is distributed across machines or that is manifested by segments of code is implemented in software as a whole, in hardware as a whole, or in a combination of hardware and software, for example, a code module. , Objects, subroutines, functions, etc.

Conceptually, a programming interface can be generally represented as shown in Figure 30A or Figure 30B. In Figure 30A, interface Interface1 is shown as the conduit used for communication between the first code segment and the second code segment. In Figure 30B, interface objects I1 and I2 that allow the first and second code segments of the system to communicate over medium M (even if they are part of the first and second code). Indicates an interface with (not necessarily part). From the perspective of Figure 30B, interface objects I1 and I2 can be considered as separate interfaces of the same system, or objects I1 and I2 and medium M can be considered as forming an interface. Figures 30A and 30B show a bidirectional flow and interfaces on both sides of that flow, but in certain embodiments, it can only have a unidirectional information flow (or no information flow as described below). , Or you can only have an interface object on one side. As an example, application programming interface (API), entry points, methods, functions, subroutines, remote procedure calls, and Component Object Model (COM) interfaces are included within the definition of the programming interface. However, it is not limited to these.

In such a programming interface aspect, the first code segment contains information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) in the second code. It can include how the information is transmitted to the segment, how the second code segment receives the information, and the structure, sequence, syntax, organization, schema, timing, and content of the information. In this regard, the underlying transport medium itself is not important to the operation of the interface, whether the medium is wired, wireless, or a combination of both, as long as the information is transported in the manner defined by the interface. In certain situations, the transfer of information may or may not exist through other mechanisms (for example, information placed in buffers, files, etc. that are separate from the information flow between code segments), and one code segment. Information may not be passed unidirectionally or bidirectionally in the traditional sense, as if one simply accesses a function performed by a second code segment. Any or all of these aspects may be important in certain circumstances, for example, depending on whether the code segment is part of a system of loosely coupled or tightly coupled configurations. Therefore, this list should be considered exemplary and not restrictive.

The concept of this programming interface is well known to those of skill in the art and is clear from the above detailed description of the present invention. However, there are other ways to implement programming interfaces, which are also included in the claims herein, unless expressly excluded. Such other methods may appear more elaborate or complex than the simplified Figures 30A and 30B, but they still perform similar functions and achieve the same overall result. .. Here, an exemplary alternative embodiment of the programming interface will be briefly described.

Communication from one code segment to another can be indirectly achieved by splitting the communication into multiple separate communications. This is outlined in FIGS. 31A and 31B. As illustrated, some interfaces can be described in terms of a divisible set of features. Thus, the interface features of FIGS. 30A and 30B can be decomposed into elements to achieve the same result, just mathematically, as providing 24, or 2x2x3x2. As a result, as shown in FIG. 31A, the functionality provided by interface 1 is divided and the communication of the interface is transformed into multiple interfaces such as interface 1A, interface 1B, interface 1C, and the same result is achieved. Can be done. As shown in FIG. 31B, the functionality provided by interface I1 is divided into multiple interfaces such as interface I1a, interface I1b, interface I1c, and the same result can be achieved. Similarly, interface I2 in the second code segment, which receives information from the first code segment, can be factored into multiple interfaces I2a, I2b, I2c, and so on. When factoring, the number of interfaces contained in the first code segment does not have to match the number of interfaces contained in the second code segment. In both cases of FIGS. 31A and 31B, the functional intent of interfaces I and I1 remains the same as in FIGS. 30A and 30B, respectively. Interface factoring can also follow associative, commutative, and other mathematical properties, which can obscure the factoring. For example, the ordering of operations may not be important, in which case the inter Functions executed by a face can be executed long before they reach an interface, by other code or an interface, or by another component of the system. In addition, those skilled in the art of programming will understand that there are different ways to make different function calls to achieve the same result.

In some cases, it is possible to ignore, add, or redefine certain aspects of the programming interface (eg, parameters) while achieving the intended result. This is shown in Figures 32A and 32B. For example, interface 1 in Figure 30A contains a function call Square (input, precision, output), which is a call containing three parameters input, precision and output, which is the first code segment to the second code. -Assuming that it will be issued to a segment. If the central parameter precision is useless in a given scenario, as shown in Figure 32A, it can simply be ignored or replaced with a meaningless (in this situation) parameter. In addition, irrelevant additional parameters can be added. In either case, Square's functionality can be achieved as long as the input is squared by the second code segment and then the output is returned. precision is a sufficiently meaningful parameter for some downstream and other parts of a computing system. However, if precision is recognized as unnecessary for the narrow purpose of calculating the square, it can be replaced or ignored. For example, instead of passing a valid precision value, you can pass a nonsensical value such as a birthday without adversely affecting the result. Similarly, as shown in Figure 32B, interface I1 is replaced by interface I1'and redefined to either ignore the parameter or add it to the interface. Interface I2 is redefined like Interface I2'and is redefined to ignore unnecessary parameters or parameters that are processed elsewhere. What is important here is that in some cases the programming interface presents parameters and other aspects that are not needed for some purposes.

Inline coding: It is also feasible to merge some or all of the functionality of two separate code modules in a way that changes the "interface" shape between them. For example, the functions of FIGS. 30A and 30B can be transformed into the functions of FIGS. 33A and 33B, respectively. In Figure 33A, the previous first and second code segments of Figure 30A are merged into one module that contains both. In this case, the code segments continue to communicate with each other, but the interface can fit into a more suitable form in a single module. So, for example, formal Call and Return statements are no longer needed, but similar processing or response according to Interface 1 may still be valid. Similarly, as shown in FIG. 33B, part or all of interface I2 from FIG. 30B can be written inline to interface I1 to form interface I1 . I2 is divided into I2a and I2b, and the interface part I2a is coded inline by interface I1 to form interface I1 . As a concrete example, interface I1 in Figure 30B makes a function call Square (input, output), which is received by interface I2 and passed in input (which should be squared) by the second code segment. After processing, the squared result is returned as output. In such cases, the processing performed by the second code segment (squared input) can be performed by the first code segment without making a call to the interface.

Communication from one code segment to another can be indirectly achieved by breaking the communication into multiple separate communications. This is outlined in Figures 34A and 34B. As shown in Figure 34A, one or more middleware to transform communication on interface 1, the first interface, to fit different interfaces (in this case interface 2A, interface 2B and interface 2C). (Because it separates the isolation interface, functionality and / or interface functionality from the original interface) is provided. This is done, for example, if you have an installed base of applications that are designed to communicate with the operating system according to the Interface 1 protocol, but in this case the operating system has a different interface (this). If so, it will be changed to use interface 2A, interface 2B and interface 2C). The point is that the original interface used by the second code segment is no longer compatible with the interface used by the first code segment, where the old and new interfaces An intermediary is used for compatibility. Similarly, as shown in Figure 34B, a third code segment is introduced to receive communication from interface I1 at separate interface DI1 and re-interface functionality from separate interface DI2 to work with, for example, DI2. You can send to the designed interfaces I2a and I2b to get the same functional results. Similarly, DI1 and DI2 can work together to transform the functionality of interfaces I1 and I2 in Figure 30B for new operating systems, yet provide the same or equivalent functional results.

Rewriting: Yet another possible variant is to dynamically rewrite the code and replace the interface functionality with something else that achieves the same overall result. For example, an intermediate language (Microsoft The code segment presented in IL, Java® ByteCode, etc.) is in the execution environment (the execution environment provided by the Net framework, Java® runtime environment, or other similar runtime type environment). Some systems are provided to just-in-time (JIT) compilers or interpreters. The JIT compiler dynamically translates the communication from the first code segment to the second code segment, i.e., they are the second code segment (original or different second code segment). Will be rewritten to fit the different interfaces that may be required for (any of). This is shown in Figures 35A and 35B. As shown in Figure 35A, this approach is similar to the Divorce scenario described above. This is the case, for example, if the base on which multiple applications are installed is designed to communicate with the operating system according to the Interface 1 protocol, which is why the operating system is modified to use a different interface. It is done when The JIT compiler can be used to make communications from installation-based applications immediately (on the fly) compliant with the new interface of the operating system. As shown in Figure 35B, this technique of dynamically rewriting an interface can be applied to dynamic factoring and modification of interfaces.

It should be noted that the aforementioned scenarios, which achieve results as the same or similar interface through alternative examples, can be combined in various ways in writing and / or in parallel, or in combination with other intervening code. I want to. Therefore, the alternative embodiments presented above are not mutually exclusive and are mixed and aligned to generate the same or similar scenarios as the generic scenarios presented in FIGS. 30A and 30B. It is also possible to make them and combine them. Moreover, as with many programming constructs, similar methods not described herein, but still achieving the same or equivalent interface functionality as represented by the spirit and scope of the invention. Also note that there are others. That is, it should be noted that it is, at least in part, the functionality represented by the interface that underlies the value of the interface, and the favorable consequences achieved by it .

III. Image Schema and Dependent Schema (Image Schema Set) In various embodiments of the invention disclosed herein, images (eg, JPEG, TIFF, bitmaps, etc.) are treated as core platform objects (image items or simply images) and are described in the present invention. The invention comprises an extensible representation of an image in the system, an "image schema" that provides the characteristics of the image and how the image relates to other items in the system. To this end, the image schema defines the properties, behaviors, and relationships of the image in the system, and the schema also contains, for example, what the data-specific image should contain, and what the data-specific image optionally contains. It also enforces image rules, such as what should be and how a unique image can be extended. Image schemas are of various types of images, including properties that represent the meaning of the image, as well as file format properties that represent the image (such as GIF, TIFF, JPEG, and other well-known image object types). Contains the type information needed to represent. The image schemas of the various embodiments of the present invention are the basis on which all image-related functionality is built.

In addition to the image schema, the associated dependent schemas for the Photo, Analysis Properties, and location items are also provided and described herein (collectively, the "Image Schema Set"). , A particular embodiment of the invention comprises one or more of these dependent schemas. A photo schema is an extensible representation of a photo object ("photo item" or simply "photo"), where the photo item type is a subtype of the image item type. The analytic property schema (AP schema) is an extensible representation of the analytic property (AP) of a photo item that implements advanced comparison functions for photographs such as automatic face recognition and image similarity. A location schema is an extensible representation of a photo item's physical (geographical) location property.

36A and 36B show the image schemas (items and properties) of the various embodiments of the invention, along with selected elements of the base schema (Figure 7) and the core schema (Figures 8A and 8B). It shows the mutual relationships between each schema. (For convenience, individual properties are omitted in the figure.)

A. Image schema As mentioned earlier, the image schema contains the items, properties, and relationships needed to represent different types of image items. It contains properties that represent the meaning of the image, as well as properties of the native file format that represent a particular image type (GIF, TIFF, JPEG, etc.). To this end, for any image item, the Image Type is the base item type shared by all images and is of the Core.Document item type (that is, the "core" schema, as shown in Figure 36). A direct extension separate from the "document" type). (The Core.Document type can also be part of the core schema shown in Figure 8A.) The image type describes a generic image and is applicable to all images regardless of format. Contains fields. The main item type in the image schema is the image type, and some fields of the image type are shown below.

<tables num="15"><img file="JP4901472B2_D0031.tif" /></tables>

The image schema also has additional properties (nesting elements) that extend from Base.PropertyBase, such as: -Region: The Region property represents the area in the image and has the following fields.

<tables num="16"><img file="JP4901472B2_D0032.tif" /></tables>

· RegionOfInterest: This property represents specific attention information in the image and has the following fields:

<tables num="17"><img file="JP4901472B2_D0033.tif" /></tables>

In addition, the image schema can also include a set of relationships between the image item shown in Figure 36A and other items, as shown below. · "Person Reference": The image has one or more Person Reference links to a contact or principal item (Core.Principal in Figure 8A) and can show a person in a particular photo, with the following fields: I have.

<tables num="18"><img file="JP4901472B2_D0034.tif" /></tables>

EventReference: The image can also have an EventReference link to an event item (Core.Event in Figure 8A) to indicate an event for a particular photo, with the following fields:

<tables num="19"><img file="JP4901472B2_D0035.tif" /></tables>

Location Reference: The image can also have a Location Reference link to a location item (Core.Location in Figure 8A) to indicate the location of a particular photo, with the following fields:

<tables num="20"><img file="JP4901472B2_D0036.tif" /></tables>

B. Photo schema The photo schema, which is a subordinate schema of the image schema, applies to images that are actually some kind of photo. For any photo item, the photo type represents a set of properties that describe the photo regardless of the image format, and the photo type is the Image.Image type (that is, in the "image" schema, as shown in Figure 36. Extends the "image" type). Some fields of photo type are shown below.

<tables num="21"><img file="JP4901472B2_D0037.tif" /></tables>

C. Analysis Property Schema For digital photos, a set of properties can be calculated for the photo by an analytical application. However, these properties are computationally expensive and are recalculated in terms of time and processor resources. Moreover, these fields are application-specific and no other application can understand the internal format of these fields.

For photo items, instead a standard set of analysis properties is calculated by these applications before use and added to the photo item in the form of an extension of the photo item type. The analytic property schema (AP schema) does this by providing the AP type of the AP extension, which itself is an extension of the Base.Extension extension type of the base schema, as shown in Figure 7. The AP type extension has the following fields:

<tables num="22"><img file="JP4901472B2_D0038.tif" /></tables>

IV. Conclusion As described above, the present invention aims at a storage platform for organizing, retrieving, and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file and database systems, including structures such as relational (table) data, XML, and new forms of data called items. Data storage of any type of data, including structured, unstructured, or semi-structured data It is designed to be a store). Through its common storage infrastructure and systematic data, the storage platform of the present invention can enable more efficient application development for consumers, knowledge workers and businesses. This storage platform provides a feature-rich and extensible application interface that not only allows you to take advantage of features specific to its data model, but also existing file system and database access methods. Incorporated and expanded. It will be appreciated that modifications can be made to the above embodiments without departing from the broad concept of the invention. Accordingly, the invention is not limited to the particular embodiments disclosed, but is intended to cover all modifications within the spirit and scope of the invention as defined by the appended claims. doing.

As will be apparent from the above description, all or parts of the various systems, methods, and embodiments of the invention can be incorporated in the form of program code (ie, instructions). This program code includes floppy (registered trademark) diskettes, CD-ROMs, CD-RWs, DVD-ROMs, DVD-RAMs, magnetic tapes, flash memory, hard disk drives, or other machine-readable storage media. It can be stored on a computer-readable medium such as a magnetic, electrical, or optical storage medium, and when the program code is loaded and executed by a machine such as a computer or server, the machine is for implementing the invention. It is characterized by being a device. The present invention is further incorporated in the form of program code transmitted over some transmission media, such as via electrical wiring or cabling, via fiber optics, via networks including the Internet or intranet, or via other modes of transmission. It can also be characterized in that when the program code is loaded and executed by a machine such as a computer, the machine becomes a device for carrying out the present invention. When implemented on a general purpose processor, the program code combines with the processor to provide a unique device that functions in the same way for a particular logic circuit. [Margins below]

<figref num="1">It is a block diagram which shows the computer system which can incorporate the aspect of this invention.</figref><figref num="2">It is a block diagram showing a computer system divided into three component groups: a hardware component, a hardware / software interface system component, and an application program component.</figref><figref num="2A">FIG. 5 represents a traditional tree-based hierarchy of files grouped into folders in a file-based operating system directory.</figref><figref num="3">It is a block diagram which shows a storage platform.</figref><figref num="4">It is a figure which shows the structural relationship between an item, an item folder, and a category.</figref><figref num="5A">It is a block diagram which shows the structure of an item.</figref><figref num="5B">FIG. 5 is a block diagram showing the composite property types of the items in Figure 5A.</figref><figref num="5C">It is a block diagram showing a "location" item in which a compound type is further described (explicitly listed).</figref><figref num="6A">It is a block diagram showing an item as a subtype of the item found in the base schema.</figref><figref num="6B">A block diagram showing the subtype items in Figure 6A where the inherited types are explicitly listed (in addition to their direct properties).</figref><figref num="7">A block diagram showing a base schema containing two top-level class types, Item and PropertyBase, and additional base schema types derived from them.</figref><figref num="8A">It is a block diagram which shows the item of the core schema.</figref><figref num="8B">It is a block diagram which shows the property type of a core schema.</figref><figref num="9">FIG. 5 is a block diagram showing an item folder, its member items, and an interconnection relationship between the item folder and its member items.</figref><figref num="10">It is a block diagram showing a category (again, the item itself), its member items, and the interconnection relationship between the category and its member items.</figref><figref num="11">It is a figure which shows the reference type hierarchy of the data model of a storage platform.</figref><figref num="12">It is a figure which shows the method which relationships are classified.</figref><figref num="13">It is a figure which shows the notification mechanism.</figref><figref num="14">The figure shows an example in which two transactions both insert a new record into the same B-tree.</figref><figref num="15">It is a figure which shows the data change detection process.</figref><figref num="16">It is a figure which shows an exemplary directory tree.</figref><figref num="17">The figure shows an example in which an existing folder of a directory-based file system is moved to a data store of a storage platform.</figref><figref num="18">It is a figure which shows the concept of a containing folder.</figref><figref num="19">It is a figure which shows the basic architecture of a storage platform API.</figref><figref num="20">Schematic representation of the various components of the storage platform API stack.</figref><figref num="21A">FIG. 6 is a schematic representation of an exemplary contact item schema.</figref><figref num="21B">FIG. 21A is a schematic representation of the elements of the exemplary contact item schema in Figure 21A.</figref><figref num="22">It is a figure which shows the runtime framework of a storage platform API.</figref><figref num="23">It is a figure which shows execution of "Find All" operation.</figref><figref num="24">It is a figure which shows the process which a storage platform API class is generated from a storage platform schema.</figref><figref num="25">It is a figure which shows the schema which the file API is based on.</figref><figref num="26">It is a figure which shows the access mask format used for the purpose of data security.</figref><figref num="27">(Parts a, b, and c) A diagram showing a new similarly protected security area cut from an existing security area.</figref><figref num="28">It is a figure which shows the concept of the item search view.</figref><figref num="29">It is a figure which shows an exemplary item hierarchy.</figref><figref num="30A">It is a figure which shows the interface 1 as a conduit through which the 1st and 2nd code segments communicate.</figref><figref num="30B">FIG. 5 shows an interface with interface objects I1 and I2 that allow the first and second code segments of the system to communicate over medium M.</figref><figref num="31A">It is a figure which shows the method of subdividing the function provided by the interface 1 and converting the communication of an interface into a plurality of interfaces of interface 1A, interface 1B, and interface 1C.</figref><figref num="31B">It is a figure which shows the method which the function provided by the interface I1 is subdivided into a plurality of interfaces I1a, I1b, I1c.</figref><figref num="32A">It is a figure which shows the scenario which a meaningless parameter accuracy is ignored or is replaced by an arbitrary parameter.</figref><figref num="32B">FIG. 5 illustrates a scenario in which an interface is replaced with an alternate interface that is defined to be ignored, or parameters are added to the interface.</figref><figref num="33A">FIG. 5 illustrates a scenario in which the first and second code segments are merged into a module that contains both.</figref><figref num="33B">FIG. 5 shows a scenario in which part or all of an interface is written inline to another interface to form a combined interface.</figref><figref num="34A">It is a figure which shows how one or more parts of middleware transform communication on a first interface to fit one or more different interfaces.</figref><figref num="34B">It is a diagram showing how a code segment can be introduced in an interface to receive communication from one interface but transmit functionality to the second and third interfaces.</figref><figref num="35A">It is a diagram showing how the Just-In-Time (JIT) compiler translates communication from one code segment to another.</figref><figref num="35B">It is a figure which shows the method which the JIT method which dynamically rewrites one or a plurality of interfaces is dynamically applied to attribute distribution, or how to change the interface.</figref><figref num="36A">The image schema is shown with selected elements of the base schema (Figure 7) and the core schema (Figure 8A), showing the interrelationships of the various items within each schema.</figref><figref num="36B">The image schema is shown with selected elements of the base schema (Figure 7) and the core schema (Figure 8A), showing the interrelationships of the various items within each schema.</figref>