JP4901472B2 - ハードウェア／ソフトウェア・インターフェース・システムにより管理可能な情報の単位を編成するデジタル・イメージ・スキーマの実装のためのシステムおよび方法 - Google Patents

Description

本発明は一般に、情報の格納と取出しの分野に関し、より詳細には、コンピュータ化されたシステムにおけるさまざまなタイプのデータ、特にイメージ・データを編成、検索、および共有するためのアクティブなストレージ・プラットフォームに関する。

本出願は、２００３年１０月２４日に出願した米国特許出願第１０／６９２，７７９号（整理番号ＭＳＦＴ−２８２９）の優先権を主張し、全体として参照により本明細書に組み込まれている「SYSTEMS AND 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」という名称の２００３年８月２１日に出願した米国特許出願第１０／６４６，６３２号（整理番号ＭＳＦＴ−１７５１）、および２００３年８月２１日に出願した国際出願第ＰＣＴ／ＵＳ０３／２６１４４号の利益を主張するものである。

本出願はさらに、以下の本願の譲受人に譲渡された出願において開示された発明にその主題によって関連しており、その内容も参照により本明細書に組み込まれている。２００３年８月２１日に出願した「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 ORGANIZATION」という名称の米国特許出願第１０／６４６，９４１号（整理番号ＭＳＦＴ−１７４９）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６４６，９４０号（整理番号ＭＳＦＴ−１７５０）、２００３年８月２１日に出願した「SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６４６，６４５号（整理番号ＭＳＦＴ−１７５２）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM」という名称の米国特許出願第１０／６４６，５７５号（整理番号ＭＳＦＴ−２７３３）、２００３年８月２１日に出願した「STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA」という名称の米国特許出願第１０／６４６，６４６号（整理番号ＭＳＦＴ−２７３４）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM」という名称の米国特許出願第１０／６４６，５８０号（整理番号ＭＳＦＴ−２７３５）、２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９２，５１５号（整理番号ＭＳＦＴ−２８４４）、２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９２，５０８号（整理番号ＭＳＦＴ−２８４５）、２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９３，３６２号（整理番号ＭＳＦＴ−２８４６）、および２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９３，５７４号（整理番号ＭＳＦＴ−２８４７）。

個々のディスク容量は、過去１０年間にわたり毎年約７０パーセント増大している。ムーアの法則は、数年にわたって生じてきた中央演算処理装置（ＣＰＵ）の驚異的進歩を正確に予測していた。有線およびワイヤレスの技術（Wired and wireless technologies ）は、驚異的な接続性と帯域幅をもたらしてきた。現在の傾向がこのまま続くと仮定すれば、数年のうちには平均的なラップトップ・コンピュータがほぼ１テラバイト（ＴＢ）のストレージを装備して数百万のファイルを収容するようになり、５００ギガバイト（ＧＢ）のドライブが普及することであろう。

消費者は、従来のパーソナル・インフォメーション・マネージャ（ＰＩＭ）スタイルのデータであろうとデジタル音楽やデジタル写真などの媒体であろうと、主に通信と個人情報の編成のために、コンピュータを使用する。デジタル・コンテンツの量、および未加工・バイト（raw bytes）を格納する機能は、すさまじい成長を遂げた。しかし、このデータを編成し一元管理するために消費者が利用できる方法は、後れをとっている（追随していない）。知識労働者は、情報の管理および共有に膨大な時間を費やしており、ある調査によれば、知識労働者はその時間の１５〜２５％を非生産的な情報関連の業務に費やしていると推定されている。また、一般的な知識労働者が情報の検索に１日当たり約２．５時間を費やしていると推定する調査もある。

開発者および情報テクノロジー（ＩＴ）部門は、人、場所、時間、イベントなどの事項を表す共通のストレージ抽象化のための独自のデータ・ストアの構築にかなりの時間および資金を投資している。これは、重複した作業になるばかりでなく、データを共通に検索したりまたは共有したりするためのメカニズムを備えていない共通データの孤島も作り出してしまう。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムを稼動しているコンピュータ上に、現在どれほど多くのアドレス帳が存在できるかを考えてみる。電子メール・クライアントおよび資産管理プログラムなど多くのアプリケーションはここのアドレス帳を保持しており、そのような各プログラムが個別に保持しているアドレス帳データはアプリケーション間でほとんど共有されていない。したがって、（Microsoft Moneyのような）資産管理プログラムは、（Microsoft Outlookにあるような）電子メールの連絡先フォルダに保持されるアドレスと支払い先のアドレスを共有しない。実際に、多くのユーザが複数の装置を所有しており、論理的にはそれらの間で、さらに携帯電話からＭＳＮおよびＡＯＬなど商業サービスを含む多種多様な追加ソースにわたって個人データの同期をとる必要がある。それにもかかわらず、共有ドキュメントのコラボレーションは、大部分が電子メール・メッセージにドキュメントを添付することにより、つまり手作業で非効率的に行われている。

このコラボレーションが欠けている１つの原因は、コンピュータ・システムにおいて情報を編成する従来型のアプローチが、ファイル・フォルダおよびディレクトリ・ベースのシステム（「ファイル・システム」）の使用に重点を置いてきたことである。これは、複数のファイルを、ファイルを格納するために使用される記憶媒体の物理編成の抽象化に基づいてフォルダのディレクトリ階層に複数のファイルを編成するものである。１９６０年代に開発されたＭｕｌｔｉｃｓオペレーティング・システムは、ファイル、フォルダ、ディレクトリを使用してオペレーティング・システム・レベルで格納可能なデータの単位を管理することを開拓したと信じられている。特に、Ｍｕｌｔｉｃｓでは、ファイルの物理アドレスがユーザ（アプリケーションおよびエンド・ユーザ）に透過的ではなかったファイルの階層内にシンボリック・アドレスを使用した（これによりファイル・パスの概念を導入した）。このファイル・システムは個々のファイルのファイル形式（file format）に完全に無関心であり、ファイル間のリレーションシップはオペレーティング・システム・レベル（つまり、階層内のファイルの場所以外）では無関係であると見なされていた。Ｍｕｌｔｉｃｓの出現以来、格納可能なデータは、オペレーティング・システム・レベルでファイル、フォルダおよびディレクトリに編成されてきた。これらのファイルは一般に、ファイル・システムによって保持される特殊ファイルに組み込まれたファイル階層自体（「ディレクトリ」）を含んでいる。このディレクトリが、ディレクトリ内の他のすべてのファイルに対応するエントリのリストと、階層内のそのようなファイルのノード上の場所（本明細書においてフォルダと呼ぶ）を保持する。以上のような状態が、ほぼ４０年間にわたるこの分野の状態であった。

しかし、コンピュータの物理ストレージ・システムに収められた情報の合理的な表現を提供し、ファイル・システムが、その物理ストレージ・システムの抽象化である限り、それゆえ、ファイルの利用には、ユーザが操作するもの（コンテクスト、機能、および他の単位とのリレーションシップを備える単位）とオペレーティング・システムが提供するもの（ファイル、フォルダ、およびディレクトリ）との間であるレベルの本筋からはずれた処理（a level of indirection）（判断（(interpretation））が必要となる。必然的に、ユーザ（アプリケーションおよび／またはエンド・ユーザ）は、たとえそうすることが非効率であり、整合性に欠ける、あるいは望ましくない場合であっても、選択の余地がなく、情報の単位をファイル・システム構造に押し込まざるを得なかった。さらに、既存のファイル・システムは個々のファイルに格納されているデータの構造についてほとんど識別することがない。このために、ほとんどの情報は、その作成元のアプリケーションにしかアクセス（および理解）することができないファイル内に閉じこめられたままである。したがって、こうした情報の概略的な記述と情報管理のメカニズムの不足により、個々のサイロ（貯蔵庫）間でほとんどデータが共有されないデータのサイロの作成につながっている。たとえば、多くのパーソナル・コンピュータ（ＰＣ）ユーザは、ある程度やり取りする相手に関する情報を収めた５つ以上の別個の格納場所、たとえば、Ｏｕｔｌｏｏｋ Ｃｏｎｔａｃｔｓ、オンライン・アカウント・アドレス、Ｗｉｎｄｏｗｓ（登録商標）Ａｄｄｒｅｓｓ Ｂｏｏｋ、Ｑｕｉｃｋｅｎ Ｐａｙｅｅｓ、およびインスタント・メッセージング（ＩＭ）仲間リストなど、を持っている。その理由は、こうしたＰＣユーザにとってファイルを整理することは重大な課題となるからである。ほとんどの既存のファイル・システムはファイルおよびフォルダの整理にネストされたフォルダのメタファーを使用するので、ファイルの数が増加するにつれて、柔軟かつ効率的な編成スキーマを維持するために必要な取り組みはまさに試練となってしまう。そのような状況において、単一ファイルについて複数の分類を備えることは非常に有用であろう。ただし、既存のファイル・システムでハードまたはソフト・リンクを使用することは煩わしく、保守も困難になる。

過去において、ファイル・システムの欠点に対処する試みがいくつか失敗に終わっている。こうしたこれまでの試みの中には、連想記憶装置（content addressable memory ）」を使用して、物理アドレスによってではなくコンテンツによってデータにアクセスできるようなメカニズムを提供するものも含まれていた。しかし、こうした取り組みは不成功に終わった。しかし一方、連想記憶装置はキャッシュおよびメモリ管理装置などの装置による小規模な利用に有効であることが判明したが、物理記憶媒体のような装置の大規模な利用は種々の理由からまだ可能ではなく、したがって、そのような解決策が単に存在していない。オブジェクト指向データベース（ＯＯＤＢ）システムを使用する他の試みも行われたが、こうした試みは、強力なデータベース特性と優れた非ファイル表現にもかかわらず、ファイル表現の処理には効果的ではなく、速度、効率、およびハードウェア／ソフトウェア・インターフェース・システム・レベルにおけるファイルおよびフォルダ・ベースの階層構造の簡易さを再現することはできなかった。ＳｍａｌｌＴａｌｋ（および他の派生）を使用しようと試みたものなど、他の取り組みは、ファイルおよび非ファイル表現を処理する上では非常に効果的であると判明したが、各種データ・ファイル間に存在するリレーションシップを効果的に編成して利用するために必要なデータベース機能が不十分であった。そのため、そのようなシステムの全体的効率は許容できないものであった。さらに、ＢｅＯＳ（および他のそのようなオペレーティング・システムの研究）を使用する別の試みも、一部の必要なデータベース機能を提供しながら十分にファイルを表現できるにもかかわらず、非ファイル表現の処理には不十分である（従来のファイル・システムの同様の中心的な短所）ことが判明した。

データベース・テクノロジは、同様の挑戦課題が存在するもう１つの技術分野である。たとえば、リレーショナル・データベース・モデルは巨大な商業的成功を収めてきたが、実際には、独立系ソフトウェア・ベンダ（ＩＳＶ）が一般に実施している、リレーショナル・データベース・ソフトウェア製品（Microsoft SQL Serverなど）に使用可能な機能はほんの一部である。と言うよりも、そのような製品とのほとんどのアプリケーションのやりとりは、簡単な「得る（gets）」および「入れる（puts）」の形態をとる。これには、プラットフォームまたはデータベースについて明確な見解がないなど、多くの簡単に明らかになる理由があるけれども、注目されないことになる多くの重要な理由の一つは、主要なビジネス・アプリケーション・ベンダが実際に必要とする厳密な抽象化を必ずしも提供しなくてもよいという点があげられる。たとえば、現実世界は「顧客」または「注文」（注文内のアイテムおよび注文のアイテムとしての注文に組み込まれた「line items（品目名）」と共に）のような「アイテム」の概念を備えているが、リレーショナル・データベースはテーブルおよび行（rows）の観点から論じるのみである。したがって、アプリケーションに、アイテム・レベルで（２〜３の例をあげると）整合性、ロッキング、セキュリティ、および／またはトリガの諸相（aspect）を備えたいとしても、一般にデータベースがこれらの機能（features）をテーブル／行（rows）レベルでのみ提供する。これは、各アイテムがデータベース内の一部のテーブルの単一行（rows）にマップされる場合は良好に機能するかもしれないが、複数の品目名のある注文の場合には、アイテムが実際に複数のテーブルにマップされなければならず、その場合には、簡単なリレーショナル・データベース・システムは正しい抽象化を提供しない。したがって、アプリケーションは、データベースの上部に論理を構築して、これらの基本抽象化を提供する必要がある。すなわち、基本リレーショナル・モデルは、より上位レベルのアプリケーションを容易に開発できる、データのストレージのための、十分なプラットフォームを提供しない。というのは基本リレーショナル・モデルがアプリケーションおよびストレージ・システムとの間に、あるレベルの本筋からはずれた処理（a level of indirection）を必要とするからである。ここでは、データの意味構造は、特定の事例におけるアプリケーション内で見えるだけである。いくつかのデータベースベンダは、オブジェクト・リレーショナル機能、新しい組織モデルなどを提供する自社製品により高レベルの機能性を組み込んでいるが、いずれも、まだ、必要な一種の包括的解決策を提供するには至っていない。ここで真に包括的な解決策とは、有用なドメイン抽象化（「Ｐｅｒｓｏｎｓ」、「Ｌｏｃａｔｉｏｎｓ」、「Ｅｖｅｎｔｓ」など）に有用なデータ・モデル抽象化（「Ｉｔｅｍｓ」、「Ｅｘｔｅｎｓｉｏｎｓ」、「Ｒｅｌａｔｉｏｎｓｈｉｐｓ」など）を提供するものである。

既存のデータ・ストレージとデータベース・テクノロジにおける前述の不備を考慮すると、コンピュータ・システムのすべてのタイプのデータを編成、検索、共有する改良された能力を提供する新しいストレージ・プラットフォーム、すなわち、データ・プラットフォームを既存のファイル・システムおよびデータベース・システムを超えたデータ・プラットフォームに拡張して広げるストレージ・プラットフォームであり、あらゆるタイプのデータの格納装置となるように設計されたストレージ・プラットフォームの必要性が存在する。先に参照により本明細書に組み込まれている関連発明は、この必要性を満たす。

しかし、イメージ（写真、デジタル画像など）のストレージは標準化されておらず、プラットフォームおよびアプリケーションにわたって汎用化されていない。アプリケーションは、特定の画像フォーマット（ＪＰＥＧなど）に合わせて調整されたＡＰＩを含むことができるが、そのようなアプリケーションの開発者は、フォーマットを認識し、調整されたアプリケーション・プログラミング・インターフェース（ＡＰＩ）を含め、さらに前記フォーマットと相互運用するために必要なあらゆる変換を行う必要がある。当技術分野において不足しているのは、コンピュータ・システムのすべての画像オブジェクトに対する共通のスキーマ（あるいはスキーマのセット）であり、本発明は、先に参照により本明細書に組み込まれている関連発明と共に、この特定の必要性を満たす。

以下では、先に本明細書（「関連発明」）に参照により組み込まれている関連発明との関連で説明されている本発明のさまざまな態様の概要を述べる。本概要は、本発明の重要な態様のすべてを包括的に説明するものではなく、また本発明の範囲を定義するものでもない。むしろ、本概要は、詳細な説明およびそれに付随する図への導入部としての役割を果たすことを目的としている。

本発明および関連発明は全体として、データを編成し（organizing）、検索し（searching）、共有する（sharing）ためのストレージ・プラットフォームを対象としている。本発明のストレージ・プラットフォームは、既存のファイル・システムおよびデータベース・システムを超えてデータ・ストレージの概念を拡張して広げ、構造化、非構造化、または半構造化データを含むあらゆるタイプのデータの格納装置（store）となるように設計される。

本発明のストレージ・プラットフォームは、データベース・エンジン上に実装されたデータ・ストアを備えている。データベース・エンジンは、オブジェクト・リレーショナル拡張（relational extensions）を備えるリレーショナル・データベース・エンジンを備えている。データ・ストアは、データの編成、検索、共有、同期化、およびセキュリティをサポートするデータ・モデルを実装する。データの特定のタイプについてはスキーマ内に記述され、プラットフォームは、新しいデータのタイプを定義するようにスキーマのセットを拡張するメカニズムを提供する（原則的に基本タイプのサブタイプはスキーマごとに提供する）。同期化機能により、ユーザまたはシステム間のデータの共有が容易になる。既存のファイル・システムとのデータ・ストアの相互運用を、そのような従来型のファイル・システムの制限を受けることなく、可能にするファイル・システムと同様の機能が提供される。変更追跡メカニズムは、データ・ストアへの変更を追跡する機能を提供する。ストレージ・プラットフォームは、アプリケーションがストレージ・プラットフォームの前述のすべての機能にアクセスできるようにし、スキーマに記述されているデータにアクセスできるようにする一連のアプリケーションプログラム・インターフェースをさらに備えている。

データ・ストアによって実装されるデータ・モデルは、アイテム（items）、要素（elements）、およびリレーションシップ（relationships）の観点からデータ・ストレージの単位（units of data storage）を定義する。アイテムは、データ・ストア内に格納可能なデータの単位であり、１つまたは複数の要素およびリレーションシップを備えることができる。要素は、１つまたは複数のフィールド（本明細書においてプロパティとも呼ぶ）を備えるタイプのインスタンスである。リレーションシップは２つのアイテムの間のリンクである。（本明細書において使用されているように、これらの特定の用語は近接して使用される他の用語と分けるために最初を大文字表記（翻訳上では原語表記する場合がある）にすることがある。ただし、大文字表記の用語（たとえば「Ｉｔｅｍ」）と大文字表記しない同じ用語（たとえば「ｉｔｅｍ」（翻訳上では、日本語表記の「アイテム」））とを区別する意図はなく、そのような区別が推定されたり、または暗示されたりされるべきではない。）
コンピュータ・システムは、各アイテムをハードウェア／ソフトウェア・インターフェース・システムにより操作することができる個々の格納可能な情報の単位を構成する複数のアイテムと、前記アイテムの組織構造（organizational structure）を構成する複数のアイテム・フォルダと、各アイテムが少なくとも１つのアイテム・フォルダに属し、且つ複数のアイテム・フォルダに属すことが可能な態様で、複数のアイテムを操作するハードウェア／ソフトウェア・インターフェース・システムと、を備えている。

アイテムまたは一部のアイテムのプロパティ値は、永続ストア（persistent store）から導出されるのではなく、動的に計算されることがある。つまり、ハードウェア／ソフトウェア・インターフェース・システムは、アイテムが格納されていることを要求せず、アイテムの現行セットを列挙する機能、またはストレージ・プラットフォームの識別子を与えられたアイテムを取り出す機能、などの特定の操作がサポートされる（これについては、アプリケーション・プログラミング・インターフェース、すなわちＡＰＩを説明するセクションでさらに詳細に説明する）。たとえば、アイテムは携帯電話の現在位置であることも、温度センサの計測温度であることもある。ハードウェア／ソフトウェア・インターフェース・システムは、複数のアイテムを操作することができ、ハードウェア／ソフトウェア・インターフェース・システムによって管理される複数のリレーションシップによって相互接続されているアイテムをさらに備えている。

コンピュータ・システム用のハードウェア／ソフトウェア・インターフェース・システムは、コア・アイテムのセットを定義するコア・スキーマをさらに備え、それを、前記ハードウェア／ソフトウェア・インターフェース・システムが理解して、あらかじめ定義された予測可能な方法で直接処理することができる。複数のアイテムを操作するために、コンピュータ・システムは、前記アイテムを複数のリレーションシップと相互接続し、前記リレーションシップをハードウェア／ソフトウェア・インターフェース・システム・レベルで管理する。

ストレージ・プラットフォームのＡＰＩは、ストレージ・プラットフォーム・スキーマのセットで定義されている各アイテム、アイテム拡張機能、およびリレーションシップに対するデータ・クラスを提供する。さらに、アプリケーション・プログラミング・インターフェースは、データ・クラスに対して振る舞いの共通セットを定義し、データ・クラスと共に、ストレージ・プラットフォームＡＰＩの基本プログラミング・モデルを提供する、フレームワーク・クラスのセットを提供する。ストレージ・プラットフォームＡＰＩは、基礎をなすデータベース・エンジンのクエリ言語の詳細からアプリケーション・プログラマを隔離するような方法で、アプリケーション・プログラマがデータ・ストア内のアイテムのさまざまなプロパティに基づいてクエリを形成できるようにする簡易クエリ・モデルを提供する。ストレージ・プラットフォームＡＰＩはさらに、アプリケーション・プログラムによって行われたアイテムへの変更を収集し、それらをデータ・ストアが実装されているデータベース・エンジン（または任意の種類のストレージ・エンジン）に必要とされる正しい更新に編成する。これにより、アプリケーション・プログラマは、メモリ内のアイテムに変更を行うことができ、しかも複雑なデータ・ストア・アップデートをＡＰＩに任せることができる。

本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業のさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なアプリケーション・インターフェースを提供するが、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れて拡張している。

相互に関連する発明のこの包括的な構造（「詳細な説明」のセクションＩＩにおいて詳しく説明する）に照らして、本発明は特に、コンピュータ・システムにおけるすべてのイメージ・オブジェクト（イメージ・アイテム）のための共通のスキーマを対象としている。本発明の他の特徴および利点は、本発明の以下の詳細な説明および付属の図を参照すれば明らかになろう。

上記の概要および上記の本発明の詳細な説明は、付属の図を参照しながら読めばよりよく理解できよう。本発明を例示する目的で、本発明のさまざまな態様の例示的な実施例が図に示されている。ただし、本発明は、開示されている特定の方法および手段に限定されることはない。

目次
Ｉ． 概要 −００２４−
Ａ． 例示的なコンピューティング環境 −００２５−
Ｂ． 従来型ファイル・ベースのストレージ −００３８−
ＩＩ． データの編成、検索、および共有のためのＷＩＮＦＳストレージ・プラットフォーム −００４１−
Ａ． 用語解説 −００４２−
Ｂ． ストレージ・プラットフォームの概要 −００４３−
Ｃ． データ・モデル −００４８−
１． アイテム −００５３−
２． アイテムの識別 −００６０−
３． アイテム・フォルダおよびカテゴリ −００６６−
４． スキーマ −００７１−
ａ） 基本スキーマ −００７１−
ｂ） コア・スキーマ −００７４−
５． リレーションシップ −００７８−
ａ） リレーションシップの宣言 −００８３−
ｂ） 保持のリレーションシップ −００８７−
ｃ） 埋め込みのリレーションシップ −００９８−
ｄ） 参照のリレーションシップ −０１０５−
ｅ） 規則および制約 −０１１０−
ｆ） リレーションシップの順序付け −０１１１−
６． 拡張性 −０１２４−
ａ） アイテムの拡張（Item extensions） −０１２８−
ｂ） ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプの拡張 −０１４９−
Ｄ． データベース・エンジン −０１５７−
１． ＵＤＴを使用するデータ・ストアの実装 −０１６１−
２． アイテムのマッピング −０１６５−
３． 拡張のマッピング −０１６９−
４． ネスト化要素のマッピング −０１７０−
５． オブジェクトのＩＤ −０１７１−
６． ＳＱＬオブジェクトの命名 −０１７２−
７． カラムの命名 −０１７４−
８． 検索ビュー −０１７５−
ａ） アイテム −０１７８−
（１） マスタ・アイテム検索ビュー −０１７９−
（２） タイプ定義済みアイテム検索ビュー −０１８１−
ｂ） アイテムの拡張 −０１８３−
（１） マスタ拡張検索ビュー −０１８４−
（２） タイプ定義済み拡張検索ビュー −０１８６−
ｃ） ネスト化要素 −０１８８−
ｄ） リレーションシップ −０１８９−
（１） マスタ・リレーションシップ検索ビュー −０１９０−
（２） リレーションシップ・インスタンス拡張検索ビュー −０１９２−
ｅ）
９． 更新 −０１９４−
１０． 変更追跡およびトゥームストーン −０１９６−
ａ） 変更追跡 −０１９７−
（１） 「マスタ」検索ビューの変更追跡 −０１９９−
（２） 「タイプ定義済み」検索ビューの変更追跡 −０２０３−
ｂ） トゥームストーン −０２０５−
（１） アイテムのトゥームストーン −０２０６−
（２） 拡張のトゥームストーン −０２０８−
（３） リレーションシップのトゥームストーン −０２１０−
（４） トゥームストーンのクリーンアップ −０２１２−
１１． ヘルパーＡＰＩおよび関数 −０２１３−
ａ） 関数[System.Storage].Getltem −０２２４−
ｂ） 関数[System.Storage].GetExtension −０２２６−
ｃ） 関数[System.Storage].GetRelationship −０２１８−
１２． メタデータ −０２２０−
ａ） スキーマ・メタデータ −０２２１−
ｂ） インスタンス・メタデータ −０２２２−
Ｅ． セキュリティ −０２２４−
Ｆ． 通知および変更追跡 −０２２７−
Ｇ． 同期化 −０２３０−
１． ストレージ・プラットフォーム間の同期化 −０２３４−
ａ） 同期（Sync）制御アプリケーション −０２２７−
ｂ） スキーマの注釈 −０２４０−
ｃ） 同期の構成 −０２４５−
（１） コミュニティ・フォルダ−マッピング −０２４９−
（２） プロファイル −０２５０−
（３） スケジュール −０２５２−
ｄ） 競合の処理 −０２５３−
（１） 競合の検出 −０２５４−
（ａ） 知識ベースの競合 −０２５５−
（ｂ） 制約ベースの競合 −０２５７−
（２） 競合の処理 −０２６０−
（ａ） 自動競合解決 −０２６３−
（ｂ） 競合のロギング −０２６７−
（ｃ） 競合の検査および解決 −０２６８−
（ｄ） レプリカの集束および競合解決の伝搬 −０２６９−
２． 非ストレージ・プラットフォーム・データ・ストアへの同期化 −０２７３−
ａ） 同期サービス（Sync Service） −０２７６−
（１） 変更の列挙（Change Enumeration） −０２７７−
（２） 変更適用（Change Application） −０２８２−
（３） 競合の解決 −０２８４−
ｂ） アダプタの実装 −０２８５−
３． セキュリティ −０２８６−
４． 管理容易性 −０２８９−
Ｈ． 従来型ファイル・システムの相互運用性 −０２９１−
Ｉ． ストレージ・プラットフォームＡＰＩ −０２９４−
ＩＩＩ．イメージ・スキーマおよび従属スキーマ（イメージ・スキーマ・セット） −０３１２−
Ａ． イメージ・スキーマ −０３１５−
Ｂ． フォト・スキーマ −０３２７−
Ｃ． 分析プロパティ・スキーマ −０３２９−
ＩＶ． 結論 −０３３２−

Ｉ．概要
本発明の主題について、法定要件を満たすために限定性を持って説明する。ただし、説明自体は、本発明の範囲を限定することを意図していない。むしろ、発明者は、主張されている主題が他の方法で実施することもでき、他の現在または将来の技術と併せて、本明細書に説明されているさまざまなステップまたはステップの組み合わせと類似したものを含めることができることを意図している。さらに、採用された方法のさまざまな要素を示すために本明細書において「ステップ」という用語が使用されるが、この用語は、個々のステップの順序が明示的に記述されている場合を除き、本明細書に開示されているさまざまなステップの間の特定の順序を暗示するものとして解釈すべきではない。

Ａ．例示的なコンピューティング環境
本発明の多数の実施例は、コンピュータ上で実行することができる。図１および以下の説明は、本発明が実施される適切なコンピューティング環境について簡単に概要を説明することを意図している。必須ではないが、本発明のさまざまな態様は、クライアント・ワークステーションまたはサーバのようなコンピュータによって実行されるプログラム・モジュールなど、コンピュータ実行可能命令の一般的なコンテクストに即して説明される。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明は、ハンドヘルド機器、マルチ・プロセッサ・システム、マイクロ・プロセッサベースまたはプログラマブル家庭用電化製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータなど、他のコンピュータ・システムの構成により実施することができる。本発明はさらに、タスクが通信ネットワークを通じてリンクされたリモート処理装置によって実行される分散コンピューティング環境においても実施することができる。分散コンピューティング環境において、プログラム・モジュールは、ローカルおよびリモートのコンピュータ記憶装置に配置することができる。

図１に示すように、例示的な汎用コンピューティング・システムは、処理装置２１、システム・メモリ２２、およびシステム・メモリを含むさまざまなシステム・コンポーネントを処理装置２１に接続するシステム・バス２３を含む、従来型のパーソナル・コンピュータ２０などを含んでいる。システム・バス２３は、メモリ・バスまたはメモリ・コントローラ、周辺バス、およびさまざまなバス・アーキテクチャのいずれかを使用するローカル・バスを含む、任意のタイプのバス構造であってもよい。システム・メモリは、読み取り専用メモリ（ＲＯＭ）２４およびランダム・アクセス・メモリ（ＲＡＭ）２５を含んでいる。起動時などにパーソナル・コンピュータ２０内の要素間の情報の転送を助ける基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４に格納される。パーソナル・コンピュータ２０はさらに、ハードディスク（図示せず）との間の読み取りまたは書き込みを行うハードディスク・ドライブ２７、取り外し可能の磁気ディスク２９との間の読み取りまたは書き込みを行う磁気ディスクドライ２８、およびＣＤ−ＲＯＭその他の光媒体など、取り外し可能の光ディスク３０との間の読み取りまたは書き込みを行う光ディスク・ドライブ３１を含むことができる。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０は、それぞれハードディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３、および光ドライブ・インターフェース３４によってシステム・バス２３に接続されている。ドライブおよびその関連するコンピュータ可読媒体は、パーソナル・コンピュータ２０のコンピュータ可読命令、データ構造、プログラム・モジュール、およびその他のデータの不揮発性記憶装置を提供する。本明細書に記載の例示的な環境では、ハードディスク、取り外し可能磁気ディスク２９、および取り外し可能光ディスク７３１を採用しているが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などの、コンピュータによりアクセス可能なデータを格納できる他の種類のコンピュータ可読媒体も、例示的なオペレーティング環境に使用できることは当業者であれば理解するであろう。同様に、例示的な環境には、熱感知器および警備または火災報知システム、およびその他の情報源など、多くの種類の監視装置を含めることもできる。

ハードディスク、磁気ディスク２９、光ディスク３１、ＲＡＭ２４またはＲＯＭ２５には、たとえばオペレーティング・システム３５、１つまたは複数のアプリケーション・プログラム３６、その他のプログラム・モジュール３７、およびプログラム・データ３８を含む、多数のプログラム・モジュールを格納することができる。ユーザは、キーボード４０およびポインティング・デバイス４２などの入力装置を介してパーソナル・コンピュータ２０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナなどを含むことができる。上記およびその他の入力装置は、システム・バスに接続されているシリアル・ポート・インターフェース４６を介して処理装置２１に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサル・シリアル・バス（ＵＳＢ）など他のインターフェースによって接続することもできる。モニタ４７またはその他の種類の表示装置も、ビデオ・アダプタ４８などのインターフェースを介してシステム・バス２３に接続することができる。モニタ４７に加えて、パーソナル・コンピュータは通常、スピーカおよびプリンタなど、他の周辺出力装置（図示せず）を含んでいる。図１の例示的なシステムはさらに、ホスト・アダプタ５５、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）バス５６、およびＳＣＳＩバス５６に接続されている外部格納装置６２も含んでいる。

パーソナル・コンピュータ２０は、リモート・コンピュータ４９など、１つまたは複数のリモート・コンピュータへの論理接続を使用するネットワーク化された環境において動作することができる。リモート・コンピュータ４９は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイスまたはその他の共通ネットワーク・ノードであってもよく、通常は上記でパーソナル・コンピュータ２０に関連して説明されている要素の多くまたはすべてを含んでいる。図１に示される論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）５１およびワイド・エリア・ネットワーク（ＷＡＮ）５２を含んでいる。そのようなネットワーク環境は、オフィス、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットで一般化している。

ＬＡＮネットワーク環境に使用される場合、パーソナル・コンピュータ２０はネットワーク・インターフェースまたはアダプタ５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーク環境に実装される場合、パーソナル・コンピュータ２０は通常、モデム５４または、インターネットなどのワイド・エリア・ネットワーク５２にわたる通信を確立するための他の手段、を含んでいる。モデム５４は、内蔵または外付けであってもよく、シリアル・ポート・インターフェース４６を介してシステム・バス２３に接続することができる。ネットワーク化された環境において、パーソナル・コンピュータ２０に関連して示されるプログラム・モジュール、またはその部分は、リモート記憶装置に格納することもできる。示されているネットワーク接続が例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されたい。

図２のブロック図に示されているように、コンピュータ・システム２００は、ハードウェア・コンポーネント２０２、ハードウェア／ソフトウェア・インターフェース・システムコンポーネント２０４、およびアプリケーション・プログラム・コンポーネント２０６（本明細書の特定のコンテクストにおいて「ユーザ・コンポーネント」または「ソフトウェア・コンポーネント」とも呼ばれる）という、３つのコンポーネント・グループに大きく分割することができる。

コンピュータ・システム２００のさまざまな実施例において、図１に戻って参照すると、ハードウェア・コンポーネント２０２は、中央演算処理装置（ＣＰＵ）２１、メモリ（ＲＯＭ２４およびＲＡＭ２５）、基本入出力システム（ＢＩＯＳ）２６、および特にキーボード４０、マウス４２、モニタ４７、および／またはプリンタ（図示せず）などのさまざまな入出力（Ｉ／Ｏ）装置を備えることができる。ハードウェア・コンポーネント２０２は、コンピュータ・システム２００の基本物理インフラストラクチャを備えている。

アプリケーション・プログラム・コンポーネント２０６は、コンパイラ、データベース・システム、ワード・プロセッサ、ビジネス・プログラム、ビデオ・ゲームなどを含むさまざまなソフトウェア・プログラムを備えているが、これらに限定されることはない。アプリケーション・プログラムは、さまざまなユーザ（マシン、他のコンピュータ・システムおよび／またはエンド・ユーザ）に対して問題の解決、解決策の提供、およびデータの処理を行うためにコンピュータ・リソースが利用される手段を提供する。

ハードウェア／ソフトウェア・インターフェース・システム・コンポーネント２０４は、ほとんどの場合シェルおよびカーネルを備えるオペレーティング・システムを備えている（一部の実施例においてはオペレーティング・システムのみで構成される）。「オペレーティング・システム」（ＯＳ）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介としての役割を果たす特殊なプログラムである。ハードウェア／ソフトウェア・インターフェース・システム・コンポーネント２０４は、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的な相当物、またはコンピュータ・システムのオペレーティング・システムに代わるかまたはこれに追加する他のそのようなソフトウェア・コンポーネントも備えている。ハードウェア／ソフトウェア・インターフェース・システムの目的は、ユーザがアプリケーション・プログラムを実行できる環境を提供することにある。ハードウェア／ソフトウェア・インターフェース・システムの目標は、コンピュータ・システムを使いやすくし、効率的よくコンピュータ・ハードウェアを利用することである。

ハードウェア／ソフトウェア・インターフェース・システムは一般に、起動時にコンピュータ・システムにロードされ、その後コンピュータ・システム内のすべてのアプリケーション・プログラムを管理する。アプリケーション・プログラムは、アプリケーション・プログラム・インターフェース（ＡＰＩ）を介してサービスを要求することによってハードウェア／ソフトウェア・インターフェースと対話する。一部のアプリケーション・プログラムは、コマンド言語またはグラフィカル・ユーザ・インターフェース（ＧＵＩ）などのユーザ・インターフェースを介してエンド・ユーザがハードウェア／ソフトウェア・インターフェースと対話できるようにする。

ハードウェア／ソフトウェア・インターフェース・システムは従来より、アプリケーション向けのさまざまなサービスを実行している。複数のプログラムが同時に実行することができるマルチ・タスキング・ハードウェア／ソフトウェア・インターフェース・システムにおいて、ハードウェア／ソフトウェア・インターフェース・システムは、どのアプリケーションをどの順序で実行すべきか、また別のアプリケーションに切り替えるまでに各アプリケーションにどのくらいの時間を与えるかを決定する。ハードウェア／ソフトウェア・インターフェース・システムはさらに、複数のアプリケーション間の内部メモリの共有も管理し、ハードディスク、プリンタ、およびダイヤルアップ・ポートなどの接続されたハードウェア装置との間の入出力も処理する。ハードウェア／ソフトウェア・インターフェース・システムはまた、オペレーションの状態および発生した可能性のあるエラーについて各アプリケーション（および特定の場合にはエンド・ユーザ）にメッセージを送信する。ハードウェア／ソフトウェア・インターフェース・システムはさらに、バッチ・ジョブ（たとえば印刷など）の管理をオフロードすることもでき、アプリケーションの初期化によりこの作業から解放されて他の処理および／またはオペレーションを再開できるようになっている。並列処理を提供できるコンピュータにおいて、ハードウェア／ソフトウェア・インターフェース・システムは、同時に複数のプロセッサ上で実行するようにプログラムの分割も管理する。

ハードウェア／ソフトウェア・インターフェース・システム・シェル（本明細書では単に「シェル」と呼ぶ）は、ハードウェア／ソフトウェア・インターフェース・システムへのインタラクティブ・エンド・ユーザ・インターフェースである。（シェルはまた、「コマンド・インタープリタ」と呼ばれ、またオペレーティング・システムでは「オペレーティング・システム・シェル」とも呼ばれることがある）。シェルは、アプリケーション・プログラムおよび／またはエンド・ユーザによって直接アクセス可能なハードウェア／ソフトウェア・インターフェース・システムの外側のレイヤである。シェルとは対照的に、カーネルは、ハードウェア・コンポーネントと直接対話するハードウェア／ソフトウェア・インターフェース・システムの最も内側のレイヤである。

本発明の多数の実施例がコンピュータ化されたシステムに特に適切であることが想定されるが、本明細書においては本発明をそのような実施例に限定する意図はない。これに対して、本明細書において使用されている「コンピュータ・システム」という用語は、こうした装置が、電子的、機械的、論理的、あるいは性質上において仮想的であるか否かにかかわらず、情報を格納および処理できるあらゆる装置および／または格納された情報を使用して装置自体の振る舞いまたは実行を制御できるあらゆる装置を包含することを意図している。

Ｂ．従来型ファイル・ベースのストレージ
現在のほとんどのコンピュータにおいて、「ファイル」とは、アプリケーション・プログラム、データセットなどだけでなく、ハードウェア／ソフトウェア・インターフェース・システムを含むことのできる格納可能な情報の単位である。すべての現代のハードウェア／ソフトウェア・インターフェース・システム（Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ、Ｍａｃ ＯＳ、仮想マシン・システムなど）において、ファイルとは、ハードウェア／ソフトウェア・インターフェース・システムによって操作できる情報（たとえばデータ、プログラムなど）の個々の（格納可能および取り出し可能な）基本単位である。ファイルのグループは一般に、「フォルダ」に編成される。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃｉｎｔｏｓｈ ＯＳ、および他のハードウェア／ソフトウェアシステムにおいて、フォルダとは、１つの情報の単位として取り出し、移動、その他操作を行うことができるファイルの集合である。これらのフォルダは、「ディレクトリ」（本明細書において以下でさらに詳細に説明する）と呼ばれるツリー・ベースの階層的配列に編成される。ＤＯＳ、ｚ／ＯＳ、およびほとんどのＵｎｉｘ（登録商標）ベースのオペレーティング・システムのような、他の特定のハードウェア／ソフトウェア・インターフェース・システムにおいて、「ディレクトリ」および／または「フォルダ」は相互に置き換え可能であり、初期のＡｐｐｌｅコンピュータ・システム（たとえばＡｐｐｌｅ ＩＩｅ）ではディレクトリの代わりに「カタログ」という用語を使用していた。ただし、本明細書で使用するように、これらの用語の全ては、同義語であり、相互置き換え可能であって、階層情報ストレージ構造とそのフォルダおよびファイル・コンポーネントに対する、他のすべての等価語および参照とをさらに含むことを意図している。

従来、ディレクトリ（フォルダのディレクトリとも呼ばれる）は、ファイルがフォルダにグループ化されるツリー・ベースの階層構造であり、そこにおいてフォルダは、ディレクトリ・ツリーを構成する相対的なノードの位置に従って編成される。たとえば、図２Ａに示すように、ＤＯＳベースのファイル・システムのベース・フォルダ（つまり「ルート・ディレクトリ」）２１２は、複数のフォルダ２１４を備え、各フォルダがさらに（その特定のフォルダの「サブ・フォルダ」として）追加フォルダ２１６を備え、その各々がさらに追加フォルダ２１８を備えるというように際限なく続く。これらのフォルダはそれぞれ、ハードウェア／ソフトウェア・インターフェース・システムのレベルで１つまたは複数のファイル２２０を持つことができるが、フォルダ内の個々のファイルはツリー階層におけるその位置以外は何も共通点がない。当然のことながら、ファイルをフォルダ階層に編成するこの方法は、これらのファイルを格納するために使用される通常の記憶媒体（たとえばハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理的編成を間接的に反映している。

前述のことに加えて、各フォルダは、そのサブ・フォルダおよびそのファイルのためのコンテナである。つまり、各フォルダはそのサブ・フォルダとファイルを所有している。たとえば、フォルダがハードウェア／ソフトウェア・インターフェース・システムによって削除された場合、そのフォルダのサブ・フォルダおよびファイルも削除される（各サブ・フォルダの場合は、さらにその所有するサブ・フォルダおよびファイルも循環的に含まれる）。同様に、各ファイルは、一般に１つのフォルダのみに所有されており、ファイルはコピーすることができ、そのコピーは異なるフォルダに配置される場合でも、ファイルのコピーは、それ自体が別個の独立した単位であり、オリジナルに直接のリレーションシップはない（たとえば、オリジナル・ファイルに加えられた変更は、ハードウェア／ソフトウェア・インターフェース・システム・レベルでコピー・ファイルに反映されない）。したがって、この点で、フォルダは物理コンテナのように扱われ、ファイルはこれらのコンテナ内部の別個の独立した物理要素として扱われるので、事実上、ファイルおよびフォルダは、「物理的」な特徴を有する。

ＩＩ．データの編成、検索、および共有のためのＷＩＮＦＳストレージ・プラットフォーム
本発明は、先に説明したように参照により本明細書に組み込まれる関連発明と共に、データを編成し、検索し、共有するためのストレージ・プラットフォームを目的としている。本発明のストレージ・プラットフォームは、データ・プラットフォームを、前述の既存ファイル・システムおよびデータベース・システムの種類を超えて拡張／拡大し、「アイテム」と呼ばれる新しいデータの形態（form of data）を含むあらゆるタイプのデータの記憶装置（store）となるように設計される。

Ａ．用語解説
本明細書および特許請求の範囲において使用されている以下の用語は、以下のとおりの意味を表している。
・ 「アイテム」は、ハードウェア／ソフトウェア・インターフェース・システムに利用可能な、格納可能な情報の単位であり、単なるファイルとは異なり、プロパティの基本セットを備えるオブジェクトであり、プロパティの基本セットは、ハードウェア／ソフトウェア・インターフェース・システム・シェルによってエンド・ユーザに見えるすべてのオブジェクトにわたって共通にサポートされる。アイテムはさらに、プロパティおよびリレーションシップ（relationships）も備え、これらは、新しいプロパティとリレーションシップを導入できるようにする機能を含み、すべてのアイテム・タイプにわたって共通にサポートされる、ている（本明細書の後半で詳細に説明する）。
・ 「オペレーティング・システム」（ＯＳ）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介としての役割を果たす特殊なプログラムである。オペレーティング・システムはほとんどの場合、シェルおよびカーネルを備えている。
・ 「ハードウェア／ソフトウェア・インターフェース・システム」は、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせであり、コンピュータ・システムの基礎を成すハードウェア・コンポーネントとコンピュータ・システム上で実行するアプリケーションとの間のインターフェースとしての役割を果たす。ハードウェア／ソフトウェア・インターフェース・システムは通常、オペレーティング・システムを備えている（一部の実施例においてはオペレーティング・システムのみで構成される）。ハードウェア／ソフトウェア・インターフェース・システムはさらに、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的な相当物、またはコンピュータ・システムのオペレーティング・システムに代わるかまたはこれに追加する他のそのようなソフトウェア・コンポーネントも備えている。ハードウェア／ソフトウェア・インターフェース・システムの目的は、ユーザがアプリケーション・プログラムを実行できる環境を提供することにある。ハードウェア／ソフトウェア・インターフェース・システムの目標は、コンピュータ・システムを使いやすくし、効率的よくコンピュータ・ハードウェアを利用することである。

Ｂ．ストレージ・プラットフォームの概要
図３を参照すると、ストレージ・プラットフォーム３００は、データベース・エンジン３１４上に実装されたデータ・ストア３０２を備えている。１つの実施例において、データベース・エンジンは、オブジェクト・リレーションシップ拡張（object relational extensions）を備えるリレーショナル・データベース・エンジンを備えている。１つの実施例において、リレーショナル・データベース・エンジン３１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒリレーショナル・データベース・エンジンを備えている。データ・ストア３０２は、データの編成、検索、共有、同期化、およびセキュリティをサポートするデータ・モデル３０４を実装する。データの特定のタイプについては、スキーマ３４０などのスキーマに記述される。ストレージ・プラットフォーム３００は、以下に詳細に説明するように、これらのスキーマを展開するため、およびこれらのスキーマを拡張するためのツール３４６を提供する。

データ・ストア３０２内に実装されている変更追跡メカニズム３０６は、データ・ストアへの変更を追跡する機能を提供する。データ・ストア３０２はさらに、セキュリティ機能３０８およびプロモーション／デモーション機能３１０も提供するが、これらについては以下で詳細に説明する。データ・ストア３０２はまた、アプリケーションプログラミングインターフェース３１２のセットを提供し、データ・ストア３０２の機能を、ストレージ・プラットフォームを利用する他のストレージプラットフォームコンポーネントおよびアプリケーション・プログラム（たとえば、アプリケーション・プログラム３５０ａ、３５０ｂ、および３５０ｃ）に公開する。本発明のストレージ・プラットフォームは、アプリケーション・プログラム・インターフェース（ＡＰＩ）３２２をさらに備え、これは、アプリケーション・プログラム３５０ａ、３５０ｂ、および３５０ｃなどのアプリケーション・プログラムがストレージ・プラットフォームの前述のすべての機能にアクセスできるようにし、スキーマに記述されているデータにアクセスできるようにする。ストレージ・プラットフォームＡＰＩ３２２は、ＯＬＥ ＤＢ ＡＰＩ３２４およびＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎ３２ ＡＰＩ ３２６など他のＡＰＩと組み合わせてアプリケーション・プログラムが使用することができる。

本発明のストレージ・プラットフォーム３００は、ユーザまたはシステム間のデータの共有を容易にする同期化サービス３３０を含む、さまざまなサービス３２８をアプリケーション・プログラムに提供することができる。たとえば、同期化サービス３３０により、データ・ストア３０２と同じフォーマットを持つ他のデータ・ストア３４０との相互運用性、および他のフォーマットを持つデータ・ストア３４２へのアクセスが可能になる。ストレージ・プラットフォーム３００はさらに、Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイル・システム３１８など、既存のファイル・システムとのデータ・ストア３０２の相互運用を可能にするファイル・システム機能も提供する。少なくとも一部の実施例において、ストレージ・プラットフォーム３２０はさらに、データが他のシステムに基づいて作用することを可能にしし、他のシステムとの対話を可能にする追加の機能をアプリケーション・プログラムに提供することができる。これらの機能は、Ｉｎｆｏ Ａｇｅｎｔサービス３３４および通知サービス３３２などの追加サービス３２８の形態で、また他のユーティリティ３３６の形態で実施することができる。

少なくとも一部の実施例において、ストレージ・プラットフォームは、コンピュータ・システムのハードウェア／ソフトウェア・インターフェース・システムに組み入れられるか、またはその不可欠部分（integral part）を形成する。たとえば、制限なく、本発明のストレージ・プラットフォームは、オペレーティング・システム、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、あるいはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）またはまたはその機能的な相当物に、組み入れられるか、またはその不可欠部分を形成することができる。本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業に対するさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なプログラミングの外見上の面を提供し、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れている。

以下の説明、およびさまざまな図において、本発明のストレージ・プラットフォーム３００は、「ＷｉｎＦＳ」と呼ぶことができる。ただし、このストレージ・プラットフォームを参照するこの名称の使用は、もっぱら説明上の便宜のためであり、決して限定することを意図するものではない。

Ｃ．データ・モデル
本発明のストレージ・プラットフォーム３００のデータ・ストア３０２は、ストア内に常駐するデータの編成（organization）、検索、共有、同期化、およびセキュリティをサポートするデータ・モデルを実装する。本発明のデータ・モデルにおいて、「アイテム」とはストレージ情報の基本単位である。データ・モデルは、以下でさらに詳細に説明するように、アイテムおよびアイテム拡張機能を宣言し、アイテム間のリレーションシップを確立し、アイテム・フォルダおよびカテゴリ内のアイテムを編成するためのメカニズムを提供する。

データ・モデルは、タイプおよびリレーションシップという２つの基本的メカニズム（primitive mechanisms）に依存している。タイプは、タイプのインスタンスの形式（form）を規定するフォーマットを提供する構造である。フォーマットは、プロパティの順序付きセットとして表される。プロパティは、所定のタイプの値または値のセットの名前である。たとえば、ＵＳＰｏｓｔａｌＡｄｄｒｅｓｓタイプは、ＳｔｒｅｅｔおよびＣｉｔｙがＳｔｒｉｎｇタイプで、ＺｉｐがＩｎｔ３２のタイプで、プロパティＳｔｒｅｅｔ、Ｃｉｔｙ、Ｚｉｐ、Ｓｔａｔｅを持つものとする。Ｓｔｒｅｅｔは、アドレスがＳｔｒｅｅｔプロパティの複数の値を持てるようにする多値（つまり値のセット）にすることができる。システムは、他のタイプの構造に使用できる特定の基本タイプを定義する。これらには、Ｓｔｒｉｎｇ、Ｂｉｎａｒｙ、Ｂｏｏｌｅａｎ、Ｉｎｔ１６、Ｉｎｔ３２、Ｉｎｔ６４、Ｓｉｎｇｌｅ、Ｄｏｕｂｌｅ、Ｂｙｔｅ、ＤａｔｅＴｉｍｅ、ＤｅｃｉｍａｌおよびＧＵＩＤが含まれる。あるタイプのプロパティは、任意の基本タイプまたは（以下に示す何らかの制約を伴う）任意の構造タイプを使用して定義することができる。たとえばＬｏｃａｔｉｏｎタイプは、Ａｄｄｒｅｓｓプロパティが前述のようにＵＳＰｏｓｔａｌＡｄｄｒｅｓｓのタイプであるＣｏｏｒｄｉｎａｔｅおよびＡｄｄｒｅｓｓを持つように定義することができる。プロパティは、必須またはオプションにすることもできる。

リレーションシップは、宣言することができ、２つのタイプのインスタンスのセットの間のマッピングを表す。たとえば、どの人々がどの場所に住むかを定義するＬｉｖｅｓＡｔと呼ばれる、ＰｅｒｓｏｎタイプおよびＬｏｃａｔｉｏｎタイプの間で宣言されるリレーションシップがある。このリレーションシップは、名前と、２つのエンドポイント、つまりソース・エンド・ポイントおよびターゲット・エンド・ポイントを持つ。リレーションシップは、プロパティの順序付きセットを持つこともできる。ソース・エンド・ポイントおよびターゲット・エンド・ポイントはいずれも、名前とタイプを持つ。たとえば、ＬｉｖｅｓＡｔのリレーションシップは、ＰｅｒｓｏｎのタイプのＯｃｃｕｐａｎｔという名前のソースと、ＬｏｃａｔｉｏｎのタイプのＤｗｅｌｌｉｎｇという名前のターゲットを持ち、さらにその居住者がその住居に住んでいた期間を示すプロパティＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅを持つ。あるＰｅｒｓｏｎが、ある期間複数の住居に住む場合もあり、住居に複数の居住者がある場合もあるので、ＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅ情報を置く場所としては、リレーションシップ自体の上が最も可能性が高い。

リレーションシップは、エンドポイントのタイプとして与えられたタイプによって制約されるインスタンス間のマッピングを定義する。たとえば、ＬｉｖｅｓＡｔのリレーションシップは、ＡｕｔｏｍｏｂｉｌｅはＰｅｒｓｏｎではないので、ＡｕｔｏｍｏｂｉｌｅがＯｃｃｕｐａｎｔ（居住者）であるというリレーションシップはあり得ない。

データ・モデルは、タイプの間のサブタイプ−スーパー・タイプというリレーションシップを定義できるようにする。ＢａｓｅＴｙｐｅリレーションシップとしても知られるサブタイプ−スーパー・タイプのリレーションシップは、タイプＡがタイプＢのＢａｓｅＴｙｐｅであればＢのすべてのインスタンスもＡのインスタンスでなければならい、というような方法で定義される。これを言い換えると、Ｂに適合するすべてのインスタンスはＡにも適合する必要があるということである。たとえば、ＡがタイプＳｔｒｉｎｇのプロパティＮａｍｅを持ち、ＢがタイプＩｎｔ１６のプロパティＡｇｅを持つ場合、Ｂの任意のインスタンスはＮａｍｅおよびＡｇｅの両方を持つことになる。このタイプの階層は、ルートにおいて単一のスーパー・タイプを持つツリーとして考えることができる。ルートからの分岐は第１レベルのサブタイプを提供し、このレベルにおける分岐は第２レベルのサブタイプを提供する、というように続き、サブタイプを持たない末端のリーフまで至る。このツリーは、均一の深さとなるように制約されていないが、循環（cycles）を含むことはできない。所定のタイプは、ゼロまたは多数のサブタイプおよびゼロまたは１つのスーパー・タイプを持つことができる。所定のインスタンスは、そのタイプのスーパー・タイプと併せてその１つのタイプに適合することができる。言い換えれば、ツリー内の任意のレベルの所定のインスタンスの場合、インスタンスはそのレベルの多くとも１つのサブタイプに適合することができる。そのタイプのインスタンスがそのタイプのサブタイプのインスタンスでもある必要がある場合に、このタイプは抽象であると言われる。

１．アイテム
アイテムは、格納可能な情報の単位であり、単純なファイルとは異なり、エンド・ユーザまたはアプリケーション・プログラムに公開されるすべてのオブジェクトにわたってストレージ・プラットフォームが共通にサポートするプロパティの基本セットを備えるオブジェクトである。アイテムはさらに、以下で説明するように、新しいプロパティとリレーションシップを導入できるようにする機能を含むすべてのアイテム・タイプにわたって共通にサポートされるプロパティおよびリレーションシップも備えている。

アイテムは、コピー、削除、移動、開く、印刷、バックアップ、復元、複製など共通の操作のためのオブジェクトである。アイテムは、格納したり取り出したりすることのできる単位であり、ストレージ・プラットフォームによって操作されるあらゆる形式の格納可能な情報は、アイテム、アイテムのプロパティ、またはアイテム間のリレーションシップとして存在する。それぞれについては、本明細書において以下で詳細に説明する。

アイテムは、連絡先、人々、サービス、場所、（あらゆる種類の）ドキュメントなどのように、現実世界の容易に理解できるデータの単位を表すよう意図されている。図５Ａは、アイテムの構造を示すブロック図である。アイテムの非修飾名（unqualified name）は、「Ｌｏｃａｔｉｏｎ」である。アイテムの修飾名（qualified name）は「Ｃｏｒｅ．Ｌｏｃａｔｉｏｎ」であり、これはこのアイテムの構造がコア・スキーマ内で特定のタイプのアイテムとして定義されることを示している。（コア・スキーマについては、本明細書の後半でさらに詳細に説明する。）
場所（location）のアイテムは、ＥＡｄｄｒｅｓｓｅｓ、ＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎ、Ｎｅｉｇｈｂｏｒｈｏｏｄ、およびＰｏｓｔａｌＡｄｄｒｅｓｓｅｓを含む複数のプロパティを備えている。各々のプロパティの特有のタイプは、プロパティ名のすぐ後に示されており、コロン（「：」）によってプロパティ名と区切られている。タイプ名の右側には、そのプロパティ・タイプに許可されている値の数が角括弧に囲まれて示されている。ここで、コロン（「：」）の右側のアスタリスク（「＊」）は不特定および／または無制限の数（「多数」）を示している。コロンの右側の「１」は、多くとも１つの値があることを示している。コロンの左側のゼロ（「０」）は、プロパティがオプションである（値が全くない場合もある）ことを示している。コロンの左側の「１」は、少なくとも１つの値（プロパティは必須）がなければならないことを示している。Ｎｅｉｇｈｂｏｒｈｏｏｄ およびＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎはいずれも、定義済みのデータ・タイプまたは「単純タイプ（simple type）」である（本明細書において大文字なしで示される）タイプ「ｎｖａｒｃｈａｒ」である。ただし、ＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓは、それぞれタイプＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓの事前定義済みのタイプまたは「複合タイプ（complex types）」（本明細書において大文字を使用して示される）のプロパティである。複合タイプは、１つまたは複数の単純データ・タイプおよび／または他の複合タイプから派生するタイプである。アイテムのプロパティの複合タイプは、その複合タイプの詳細が直属のアイテムにネストされてそのプロパティを定義するので、「ネストされた要素」（以下、ネスト化要素と記す）を構成し、これらの複合タイプに関連する情報はこれらのプロパティを持つアイテムで（本明細書の後半で説明するように、アイテムの境界内で）保持される。これらのタイプ定義の概念は周知のものであり、当業者には容易に理解されよう。

図５Ｂは、複合プロパティ・タイプＰｏｓｔａｌＡｄｄｒｅｓｓおよびＥＡｄｄｒｅｓｓを示すブロック図である。ＰｏｓｔａｌＡｄｄｒｅｓｓプロパティ・タイプは、プロパティ・タイプＰｏｓｔａｌＡｄｄｒｅｓｓのアイテムが、ゼロまたは１つのＣｉｔｙ値、ゼロまたは１つのＣｏｕｎｔｒｙＣｏｄｅ値、ゼロまたは１つのＭａｉｌＳｔｏｐ値、および任意の数の（ゼロから多数）のＰｏｓｔａｌＡｄｄｒｅｓｓＴｙｐｅなど（以下同様）を持つことを期待できるように定義する。このようにして、アイテム内の特定のプロパティのデータの形状が定義される。ＥＡｄｄｒｅｓｓプロパティ・タイプは、示されているように同様に定義される。本明細書においてオプションとしてこの応用例を使用したが、Ｌｏｃａｔｉｏｎアイテムの複合タイプを表すもう１つの方法は、そこに一覧されている各複合タイプの個々のプロパティでアイテムを描くことである。図５Ｃは、複合タイプがさらに説明されるＬｏｃａｔｉｏｎアイテムを示すブロック図である。ただし、図５ＣにおけるＬｏｃａｔｉｏｎアイテムのこの代替表現は、図５Ａに示されている全く同じアイテムを表すものである。本発明のストレージ・プラットフォームは、サブタイプ定義も可能にし、それにより、１つのプロパティ・タイプがもう１つのプロパティのサブタイプ（１つのプロパティ・タイプがもう一方の親プロパティ・タイプのプロパティを継承する）となることが可能になる。

プロパティおよびそのプロパティ・タイプとは類似しているが異なっているため、アイテムは、本質的に、サブタイプ定義の対象にもなりうる各自のアイテム・タイプを表している。言い換えれば、本発明のいくつかの実施例におけるストレージ・プラットフォームにより、アイテムは別のアイテムのサブタイプになることができる（１つのアイテムがもう一方の親アイテムのプロパティを継承する）。さらに、本発明のさまざまな実施例について、すべてのアイテムは、基本スキーマ内に見い出される最初の基本アイテム・タイプである「Ｉｔｅｍ」アイテム・タイプのサブタイプであるが、これはのつながりである。（基本スキーマについては、本明細書の後半でさらに詳細に説明する。）図６Ａは、基本スキーマ内に見い出されたＩｔｅｍアイテム・タイプのサブタイプとして、このインスタンスのアイテム、Ｌｏｃａｔｉｏｎアイテムを示している。この図において、矢印は、Ｌｏｃａｔｉｏｎアイテムが（他のすべてのアイテムと同様に）Ｉｔｅｍアイテム・タイプのサブタイプであることを示している。Ｉｔｅｍアイテム・タイプは、すべての他のアイテムがそこから派生する基本のアイテムとして、ＩｔｅｍＩｄなどのいくつかの重要なプロパティおよびさまざまなタイム・スタンプを持ち、これによりオペレーティング・システム内のすべてのアイテムの標準プロパティを定義する。この図において、Ｉｔｅｍアイテム・タイプのプロパティはロケーションが継承され、これにより、ロケーションのプロパティとなる。 Ｉｔｅｍアイテム・タイプから継承されたＬｏｃａｔｉｏｎアイテムのプロパティを表すもう１つの方法は、そこに一覧されている親アイテムからの各プロパティ・タイプの個々のプロパティでロケーションを描くことである。図６Ｂは、継承されたタイプが、その直接のプロパティに加えて、記述されるＬｏｃａｔｉｏｎアイテムを示すブロック図である。このアイテムは図５Ａに示されているアイテムと同じものであるが、現在の図においてＬｏｃａｔｉｏｎは、直接（この図および図５Ａに示されている）および継承（この図には示されるが図５Ａには示されていない）の両方のすべてのプロパティで示されている（しかし、図５Ａでは、これらのプロパティはＬｏｃａｔｉｏｎアイテムがＩｔｅｍアイテム・タイプのサブタイプであることを示す矢印で示すことにより参照される）ことに留意され、理解されたい。

アイテムは、スタンド・アローンのオブジェクトである。従って、アイテムを削除した場合、アイテムの直接および継承された全てのプロパティも削除される。同様に、アイテムを取り出す場合、取り出されるものはアイテムとその直接および継承されたプロパティすべてである（その複合プロパティ・タイプに関連する情報を含む）。本発明の特定の実施例では、特定のアイテムを取り出すときにプロパティのサブセットを要求できるようにすることができる。ただし、そのような多くの実施例のデフォルトは、取り出される際のその直接および継承されたプロパティのすべてをアイテムに提供することである。さらに、アイテムのプロパティは、そのアイテムのタイプの既存のプロパティに新しいプロパティを追加することによって拡張することもできる。これらの「拡張」は、その後アイテムの真正のプロパティとなり、そのアイテム・タイプのサブタイプは自動的に拡張プロパティを含むことができる。

アイテムの「境界」は、（複合プロパティ・タイプ、拡張などを含む）そのプロパティによって表される。アイテムの境界はさらに、コピー、削除、移動、作成など、アイテムに対して実行される操作の制限も表す。たとえば、本発明のいくつかの実施例において、アイテムがコピーされるとき、そのアイテムの境界内にあるすべてのものもコピーされる。各アイテムに対して、境界は次のものを含む。
・ アイテムのアイテム・タイプ、および、アイテムが（すべてのアイテムが基本スキーマの単一のアイテムおよびアイテム・タイプから派生している、本発明のいくつかの実施例の場合のように）別のアイテムのサブタイプである場合、該当するサブタイプ情報（つまり、親アイテム・タイプに関連する情報）。コピーされる元のアイテムが別のアイテムのサブタイプである場合、コピーもその同じアイテムのサブタイプになる。
・ アイテムの複合タイプ・プロパティおよび拡張（ある場合）。元のアイテムが複合タイプのプロパティ（ネイティブまたは拡張）を持つ場合、コピーも同じ複合タイプを持つことができる。
・ 「Oownership relationships（所有権関係）」上のアイテムのレコード、つまり他のどのアイテム（「ターゲット・アイテム」）が現在のアイテムによって所有されるか（「Owning Item（所有アイテム）」）を一覧するアイテムの所有リスト。これは、以下でさらに詳細に説明するアイテム・フォルダについて、およびすべてのアイテムが少なくとも１つのアイテム・フォルダに属す必要があるという以下に述べられた規則、に特に関連する。さらに、組み込まれたアイテム（以下でさらに詳細に説明する）については、組み込まれたアイテムは、コピー、削除などの操作のために組み込まれているアイテムの一部と見なされている。

２．アイテムの識別
アイテムはグローバルアイテム・スペース内でＩｔｅｍＩＤにより一意に識別される。Ｂａｓｅ．Ｉｔｅｍタイプは、アイテムのＩＤを格納するタイプＧＵＩＤのフィールドＩｔｅｍＩＤを定義する。アイテムは、データ・ストア３０２に厳密に１つのＩＤを持つ必要がある。

アイテム参照は、アイテムの場所を見つけて識別するための情報を含むデータ構造である。データ・モデルにおいて、抽象タイプは、すべてのアイテム参照タイプが派生するＩｔｅｍＲｅｆｅｒｅｎｃｅという名前で定義される。ＩｔｅｍＲｅｆｅｒｅｎｃｅタイプは、Ｒｅｓｏｌｖｅという名前の仮想メソッドを定義する。Ｒｅｓｏｌｖｅメソッドは、ＩｔｅｍＲｅｆｅｒｅｎｃｅを解決してアイテムを返す。このメソッドは、ＩｔｅｍＲｅｆｅｒｅｎｃｅの具象サブタイプによってオーバーライドされるが、これは参照を与えられたアイテムを取り出す関数を実装する。Ｒｅｓｏｌｖｅメソッドは、ストレージ・プラットフォームＡＰＩ３２２の一部として呼び出される。

ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅは、ＩｔｅｍＲｅｆｅｒｅｎｃｅのサブタイプである。これは、ロケータおよびＩｔｅｍＩＤフィールドを定義する。Ｌｏｃａｔｏｒフィールドは、アイテム・ドメインに名前をつける（つまり識別する）。これは、アイテム・ドメインへのロケータの値を解決できるロケータ・レゾリューション・メソッドによって処理される。ＩｔｅｍＩＤフィールドはＩｔｅｍＩＤのタイプである。

ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅは、ロケータおよびＰａｔｈフィールドを定義するＩｔｅｍＲｅｆｅｒｅｎｃｅの特殊化である。Ｌｏｃａｔｏｒフィールドは、アイテム・ドメインを識別する。これは、アイテム・ドメインへのロケータの値を解決できるロケータ・レゾリューション・メソッドによって処理される。Ｐａｔｈフィールドは、ロケータによって提供されたアイテム・ドメインにルートを置くストレージ・プラットフォームのネーム・スペースに（相対）パスを含んでいる。

このタイプの参照は、セットオペレーションには使用することができない。参照は一般にパス解決プロセスを通じて解決される必要がある。ストレージ・プラットフォームＡＰＩ３２２は、この機能を提供する。

前述の参照の形式は、図１１に示す参照タイプ階層を通じて表される。これらのタイプから継承される追加の参照タイプは、スキーマにおいて定義することができる。これらは、ターゲット・フィールドのタイプとしてリレーションシップの宣言に使用することができる。

３．アイテム・フォルダおよびカテゴリ
以下でさらに詳細に説明するように、アイテムのグループは、（フィールド・フォルダと混同しないように）アイテム・フォルダと呼ばれる特殊なアイテムに編成することができる。しかし、ほとんどのファイル・システムの場合と異なり、アイテムは複数のアイテム・フォルダに属すことができ、この結果、アイテムが１つのアイテム・フォルダでアクセスされて修正されるとき、この修正済みアイテムは別のアイテム・フォルダから直接アクセスすることができるようになっている。本質的には、アイテムへのアクセスがさまざまなアイテム・フォルダから行われても、実際にアクセスされているのはまったく同一のアイテムなのである。しかし、アイテム・フォルダは必ずしもそのメンバ・アイテムのすべてを所有する必要はないか、または、他のフォルダと連動して単にアイテムを共同所有することができ、これによりアイテム・フォルダの削除が必ずしもアイテムを削除したことにはならない。それにもかかわらず、本発明のいくつかの実施例においては、特定のアイテムのたった１つのアイテム・フォルダが削除された場合に、一部の実施例ではアイテムが自動的に削除されるか、あるいは代替実施例においてはアイテムが自動的にデフォルトのアイテム・フォルダ（たとえば、「ゴミ箱」アイテム・フォルダは概念的には、さまざまなファイルおよびフォルダ・ベースのシステムで使用される類似した名前の付いたフォルダと似ている）のメンバになるように、アイテムは少なくとも１つのアイテム・フォルダに属す必要がある。

以下でさらに詳細に説明するように、アイテムは、（ａ）アイテム・タイプ（複数もあり）、（ｂ）特定の直接または継承されたプロパティ（複数もあり）、または（ｃ）アイテム・プロパティに対応する特定の値（複数もあり）などの、共通の記述された特性に基づくカテゴリに属すこともできる。たとえば、個人連絡先情報の特定のプロパティを含むアイテムは、自動的に連絡先カテゴリに帰属し、連絡先情報プロパティを持つ任意のアイテムは同様にこのカテゴリに自動的に帰属するようになる。同様に、「Ｎｅｗ Ｙｏｒｋ Ｃｉｔｙ」の値を持つ場所プロパティを持つ任意のアイテムは、ＮｅｗＹｏｒｋＣｉｔｙカテゴリに自動的に帰属する。

アイテム・フォルダは、相互に関連しない（つまり共通の記述された特性を持たない）アイテムを含むことができるが、カテゴリ内の各アイテムはそのカテゴリに記述されている共通のタイプ、プロパティ、または値（「共通性」）を持ち、この共通性がカテゴリ内の他のアイテム間およびアイテムとのそのリレーションシップの基盤を形成しているという点で、カテゴリはアイテム・フォルダとは概念的に異なっている。さらに、特定のフォルダ内のアイテムのメンバーシップがそのアイテムの特定の局面に基づくことを義務付けられてはいないのに対して、特定の実施例ではカテゴリに明確に関連する共通性を持つすべてのアイテムは、ハードウェア／ソフトウェア・インターフェース・システムレベルにおいて自動的にカテゴリのメンバとなることができる。概念的に、カテゴリは、（データベースのコンテクストの場合のように）メンバーシップが特定のクエリの結果に基づく仮想アイテム・フォルダとして見なすこともでき、（カテゴリの共通性によって定義されている）このクエリの条件を満たすアイテムはカテゴリのメンバーシップを含むことになる。

図４は、アイテム、アイテム・フォルダ、およびカテゴリの間の構造的リレーションシップを示す図である。複数のアイテム４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、および４２０は、さまざまなアイテム・フォルダ４２２、４２４、４２６、４２８、および４３０のメンバである。一部のアイテムは、たとえばアイテム４０２がアイテム・フォルダ４２２および４２４に属す、というように複数のアイテム・フォルダに属することもできる。一部のアイテム、たとえば４０２、４０４、４０６、４０８、４１０、および４１２は複数のカテゴリ４３２、４３４、および４３６のメンバでもあるが、他のアイテム、たとえばアイテム４１４、４１６、４１８、および４２０はどのカテゴリにも属さない（ただしこれは、任意のプロパティの所有が自動的にカテゴリ内のメンバーシップを含意する特定の実施例においては、そうである見込みはなく、そのような実施例においていずれのカテゴリのメンバとならないためには、アイテムは完全に特徴のないものになる必要がある）。フォルダの階層的構造とは対照的に、カテゴリおよびアイテム・フォルダはいずれも、図のように有方グラフ（directed graphs）とさらによく似た構造を備えている。いずれにせよ、アイテム、アイテム・フォルダ、およびカテゴリは（たとえアイテム・タイプは異なっていても）すべてアイテムである。

ファイル、フォルダ、およびディレクトリとは対照的に、本発明のアイテム、アイテム・フォルダ、およびカテゴリは、アイテムが、物理コンテナの概念的な等化物を有さないので、本質的に特質上「物理的」ではなく、そのためアイテムは複数のそのような場所に存在できる。複数のアイテム・フォルダの場所に存在し、複数のカテゴリ（複数）に編成されるアイテム対する能力によって、ハードウェア／ソフトウェア・インターフェース・レベルにおいて、当技術分野で現在利用可能なレベルを上回る、強化され、豊富にされた高いデータ操作およびストレージ構造の可能性（capabilities）がもたらされる。

４．スキーマ
ａ）基本スキーマ
アイテムの作成および使用に普遍的な基盤を提供するため、本発明のストレージ・プラットフォームのさまざまな実施例は、アイテムおよびプロパティを作成して編成するための概念上のフレームワークを確立する基本スキーマを備えている。基本スキーマはアイテムおよびプロパティのある種の特定のタイプと、サブタイプがさらに派生できるこれらの特定の、基礎的タイプの特徴を定義する。この基本スキーマの使用により、プログラマは、アイテム（およびそれぞれのタイプ）をプロパティ（およびそれぞれのタイプ）と概念的に区別することができる。さらに、基本スキーマは、すべてのアイテム（およびその対応するアイテムタイプ）が基本スキーマのこの基礎的アイテム（およびその対応するアイテム・タイプ）から派生するので、すべてのアイテムが所有できるプロパティの基礎的セットを示している。

図７に示すように、本発明のいくつかの実施例に関して、基本スキーマは、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＰｒｏｐｅｒｔｙＢａｓｅという３つの最上位のタイプを定義する。図のように、アイテム・タイプは、この基礎的「Ｉｔｅｍ」アイテム・タイプのプロパティによって定義される。一方、最上位プロパティ・タイプ「ＰｒｏｐｅｒｔｙＢａｓｅ」は、事前定義済みのプロパティを持たず、単にアンカーに過ぎず、そこから他のすべてのプロパティ・タイプが派生し、およびそこを通してすべての派生したプロパティ・タイプが（単一のプロパティ・タイプから共通に派生して）相互に関連付けられる。Ｅｘｔｅｎｔｉｏｎタイプ・プロパティは、その拡張（extention）が拡張するアイテムを定義し、またアイテムが複数の拡張を持つことができるので拡張をそれぞれ区別するためのＩＤを定義する。

ＩｔｅｍＦｏｌｄｅｒは、Ｉｔｅｍアイテム・タイプのサブタイプであり、アイテムから継承されたプロパティに加えて、そのメンバ（ある場合）へのリンクを確立するためのリレーションシップを特徴づけ、一方、ＩｄｅｎｔｉｔｙＫｅｙおよびＰｒｏｐｅｒｔｙは共にＰｒｏｐｅｒｔｙＢａｓｅのサブタイプである。ＣａｔｅｇｏｒｙＲｅｆは、ＩｄｅｎｔｉｔｙＫｅｙのサブタイプである。

ｂ）コア・スキーマ
本発明のストレージ・プラットフォームのさまざまな実施例はさらに、最上位のＩｔｅｍタイプ構造のための概念上のフレームワークを提供するコア・スキーマを備えている。図８Ａは、コア・スキーマ内のアイテムを示すブロック図であり、図８Ｂはコア・スキーマ内のプロパティ・タイプを示すブロック図である。異なる拡張子（＊．ｃｏｍ、＊．ｅｘｅ、＊．ｂａｔ、＊．ｓｙｓ）を持つファイル間で行われる区別、ファイルおよびフォルダ・ベースのシステムにおける他のそのような基準は、コア・スキーマの機能と類似している。アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムにおいて、コア・スキーマは、アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムが理解して、あらかじめ定義された予測可能な方法で直接処理することができる１つまたは複数のコア・スキーマアイテム・タイプにすべてのアイテムを、直接に（アイテム・タイプにより）または間接（アイテム・サブタイプにより）に、特徴付けるコア・アイテム・タイプのセットを定義する。事前定義済みアイテム・タイプは、アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムにおいて最も一般的なアイテムを反映し、この結果で、効率性のあるレベルが、コア・スキーマを構成するこれらの事前定義済みアイテム・タイプを理解するアイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムによって得られる。

特定の実施例において、コア・スキーマは拡張可能ではない。つまり、コア・スキーマの一部である固有の事前定義済み派生アイテム・タイプの場合を除いて、追加のアイテム・タイプは、基本スキーマのアイテム・タイプから直接サブタイプ定義することができない。コア・スキーマへの拡張を防ぐ（つまりコア・スキーマへの新しいアイテムの追加を防ぐ）ことにより、すべての後続のアイテム・タイプが必然的にコアシステムアイテム・タイプのサブタイプになるため、ストレージ・プラットフォームはコア・スキーマのアイテム・タイプの使用を義務付ける。この構造により、追加のアイテム・タイプを定義する際の柔軟性の度合いが適度に高まり、しかもコア・アイテム・タイプの事前定義済みセットを備える利点も保持することができる。

本発明のさまざまな実施例について、図８Ａを参照すると、コア・スキーマによってサポートされる特定のアイテム・タイプは１つまたは複数の以下の事項を含むことができる。
・ Ｃａｔｅｇｏｒｉｅｓ：このアイテム・タイプのアイテム（およびそこから派生したサブタイプ）は、アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムにおける有効なカテゴリを表す。
・ Ｃｏｍｍｏｄｉｔｉｅｓ：識別可能な値であるアイテム。
・ Ｄｅｖｉｃｅｓ：情報処理機能をサポートする論理構造を持つアイテム。
・ Ｄｏｃｕｍｅｎｔｓ：アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムによって解釈されないが、代わりにドキュメントタイプに対応するアプリケーション・プログラムによって解釈されるコンテンツを持つアイテム。
・ Ｅｖｅｎｔｓ：環境内の特定のオカレンスを記録するアイテム。
・ Ｌｏｃａｔｉｏｎｓ：物理的位置（地理的位置など）を表すアイテム。
・ Ｍｅｓｓａｇｅｓ：２つ以上のプリンシパル（以下で定義される）間の通信のアイテム。
・ Ｐｒｉｎｃｉｐａｌｓ：ＩｔｅｍＩｄを除いて少なくとも１つの決定的に証明可能なＩＤを持つアイテム（たとえば、人物、組織、グループ、世帯、当局、サービスなど）。
・ Ｓｔａｔｅｍｅｎｔｓ：ポリシー、サブスクリプション、証明書など（これらに限定されないが）を含む環境に関する特殊情報を持つアイテム。

同様に、図８Ｂを参照すると、コア・スキーマによってサポートされる特定のプロパティ・タイプは１つまたは複数の以下の事項を含むことができる。
・ Ｃｅｒｔｉｆｉｃａｔｅｓ（基本スキーマの基礎的ＰｒｏｐｅｒｔｙＢａｓｅタイプから派生）
・ Ｐｒｉｎｃｉｐａｌ Ｉｄｅｎｔｉｔｙ Ｋｅｙｓ（基本スキーマのＩｄｅｎｔｉｔｙＫｅｙタイプから派生）
・ Ｐｏｓｔａｌ Ａｄｄｒｅｓｓ（基本スキーマのＰｒｏｐｅｒｔｙタイプから派生）
・ Ｒｉｃｈ Ｔｅｘｔ（基本スキーマのＰｒｏｐｅｒｔｙタイプから派生）
・ ＥＡｄｄｒｅｓｓ（基本スキーマのＰｒｏｐｅｒｔｙタイプから派生）
・ ＩｄｅｎｔｉｔｙＳｅｃｕｒｉｔｙＰａｃｋａｇｅ（基本スキーマのＲｅｌａｔｉｏｎｓｈｉｐタイプから派生）
・ ＲｏｌｅＯｃｃｕｐａｎｃｙ（基本スキーマのＲｅｌａｔｉｏｎｓｈｉｐタイプから派生）
・ ＢａｓｉｃＰｒｅｓｅｎｃｅ（基本スキーマのＲｅｌａｔｉｏｎｓｈｉｐタイプから派生）
これらのアイテムおよびプロパティはさらに、図８Ａおよび図８Ｂに示されているそれぞれのプロパティによって説明される。

５．リレーションシップ（Relationship）
リレーションシップは、一方のアイテムがソースとして指定され、もう一方のアイテムがターゲットとして指定される２項関係（binary relationships）である。ソース・アイテムおよびターゲット・アイテムは、リレーションシップによって関連している。ソース・アイテムは一般に、リレーションシップの存続期間を制御する。つまり、ソース・アイテムが削除されると、アイテム間のリレーションシップも削除される。

リレーションシップは、包含および参照のリレーションシップに分類される。包含リレーションシップはターゲット・アイテムの存続期間を制御するが、参照リレーションシップは存続期間管理セマンティクスを提供しない。図１２は、リレーションシップ（Relationship）が分類される方法を示す図である。

包含（Containment）リレーションシップ・タイプはさらに、保持（Holding）および埋め込み（Embedding）のリレーションシップに分類される。アイテムへのすべての保持リレーションシップが除去されると、アイテムは削除される。保持リレーションシップは、参照カウント・メカニズム（reference counting mechanism）を通じてターゲットの存続期間を制御する。埋め込みリレーションシップは、複合アイテムのモデリングを可能にし、排他的な保持リレーションシップと考えることができる。アイテムは、１つまたは複数の保持リレーションシップのターゲットになりうる。しかし、アイテムは厳密に１つの埋め込みリレーションシップのターゲットとなることができる。埋め込みリレーションシップのターゲットであるアイテムは、他の保持または埋め込みリレーションシップのターゲットになることはできない。

参照リレーションシップは、ターゲット・アイテムのライフタイムを制御しない。これらは、ｄａｎｇｌｉｎｇ（未決）の場合もある。つまり、ターゲット・アイテムが存在しない場合もある。参照リレーションシップを使用して、グローバル・アイテム・ネーム・スペースのどこにでも（リモート・データストアを含む）アイテムへの参照をモデル化することができる。

アイテムのフェッチ（取り出し）は、自動的にそのリレーションシップをフェッチしない。アプリケーションは、アイテムのリレーションシップを明示的に要求する必要がある。さらに、リレーションシップを変更することでは、ソースまたはターゲット・アイテムは変更されない。同様に、リレーションシップを追加しても、ソースまたはターゲット・アイテムには影響を与えない。

ａ）リレーションシップ（Relationship）の宣言
明示的なリレーションシップ・タイプは、以下の要素により定義される。
・ リレーションシップ名は、名前属性で指定される。
・ リレーションシップ・タイプは、保持、埋め込み、参照のいずれかである。これは、タイプ属性で指定される。
・ ソースおよびターゲット・エンド・ポイント。各エンドポイントは、参照先アイテムの名前およびターゲットを指定する。
・ ソース・エンド・ポイント・フィールドは、一般にＩｔｅｍＩＤ（宣言されていない）のタイプであり、リレーションシップ・インスタンスと同じデータ・ストアにあるアイテムを参照する必要がある。
・ 保持および埋め込みのリレーションシップでは、ターゲット・エンド・ポイント・フィールドはＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅのタイプである必要があり、リレーションシップ・インスタンスと同じストアにあるアイテムを参照する必要がある。参照のリレーションシップでは、ターゲット・エンド・ポイントは任意のＩｔｅｍＲｅｆｅｒｅｎｃｅタイプにすることができ、他のストレージ・プラットフォームのデータ・ストア内のアイテムを参照することができる。
・ オプションで、スカラの１つまたは複数のフィールド、またはＰｒｏｐｅｒｔｙＢａｓｅタイプを宣言することができる。これらのフィールドは、リレーションシップに関連付けられているデータを含むことができる。
・ リレーションシップ・インスタンスは、グローバル・リレーションシップ・テーブルに格納される。
・ すべてのリレーションシップ・インスタンスは、組み合わせ（ソースＩｔｅｍＩＤ、リレーションシップＩＤ）により一意に識別される。リレーションシップＩＤは、そのタイプにはかかわりなく所定のアイテムに供給されたすべてのリレーションシップに対して所定のソースＩｔｅｍＩＤ内で一意である。

ソース・アイテムは、リレーションシップの所有者である。所有者として指定されたアイテムは、リレーションシップの存続期間を制御するが、リレーションシップ自体はその関連するアイテムからは分離されている。ストレージ・プラットフォームＡＰＩ３２２は、アイテムに関連付けられているリレーションシップを公開するメカニズムを提供する。
以下にリレーションシップの宣言の例を示す。

これは、参照のリレーションシップの例である。ソース参照によって参照されている人物アイテムが存在しない場合、リレーションシップは作成することはできない。さらに、人物アイテムが削除された場合、人物と組織の間のリレーションシップ・インスタンスが削除される。ただし、組織アイテムが削除された場合、リレーションシップは削除されず、ｄａｎｇｌｉｎｇ（未決）となる。

ｂ）保持のリレーションシップ
保持リレーションシップは、ターゲット・アイテムの参照カウントベースの存続期間管理をモデル化するために使用される。

アイテムは、アイテムとのゼロ以上のリレーションシップに対するソース・エンド・ポイントになることができる。埋め込みアイテムではないアイテムは、１つまたは複数の保持リレーションシップのターゲットになることができる。

ターゲット・エンド・ポイント参照タイプはＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅである必要があり、リレーションシップ・インスタンスと同じストアにあるアイテムを参照する必要がある。

保持リレーションシップは、ターゲット・エンド・ポイントのライフタイム管理を強制する。保持リレーションシップ・インスタンスの作成、およびそれがターゲットにするアイテムの作成は、アトミック・オペレーションである。同じアイテムをターゲットにする追加の保持リレーションシップ・インスタンスを作成することができる。所定のアイテムをターゲット・エンド・ポイントとして持つ最後の保持リレーションシップ・インスタンスが削除された場合、ターゲット・アイテムも削除される。

リレーションシップ宣言で指定されているエンドポイント・アイテムのタイプは一般に、リレーションシップのインスタンスが作成されるときに、強制される。エンドポイント・アイテムのタイプは、リレーションシップが確立された後は変更することができない。

保持リレーションシップは、アイテム・ネーム・スペースを形成する際に重要な役割を果たす。保持リレーションシップは、ソース・アイテムに関連してターゲット・アイテムの名前を定義する「Ｎａｍｅ」プロパティを含んでいる。この相対名は、所定のアイテムから供給されるすべての保持リレーションシップに対して一意である。ルート・アイテムから始まり所定のアイテムまで至るこの相対名の順序付きリストは、アイテムに対するフルネームを形成する。

保持リレーションシップは、有向非周期グラフ（ＤＡＧ；directed acyclic graph）を形成する。保持リレーションシップが作成されるとき、システムはサイクルが作成されないようにして、アイテム・ネーム・スペースがＤＡＧを形成するようにする。

保持リレーションシップはターゲット・アイテムの存続期間を制御するが、これはターゲット・エンド・ポイントアイテムの操作上の整合性は制御しない。ターゲット・アイテムは、保持リレーションシップを通じてこれを所有するアイテムから操作上独立している。保持リレーションシップのソースであるアイテムに対するコピー、移動、バックアップその他の操作は、同じリレーションシップのターゲットであるアイテムには影響を与えない。たとえば、フォルダ・アイテムをバックアップしても、フォルダ内のすべてのアイテム（ＦｏｌｄｅｒＭｅｍｂｅｒリレーションシップのターゲット）が自動的にバックアップされることはない。

保持リレーションシップの例を以下に示す。

ＦｏｌｄｅｒＭｅｍｂｅｒｓリレーションシップにより、アイテムの汎用コレクションとしてのフォルダの概念が可能になる。

ｃ）埋め込みのリレーションシップ
埋め込みリレーションシップは、ターゲット・アイテムのライフタイムの排他制御の概念をモデル化する。埋め込みリレーションシップは、複合アイテムの概念を可能にする。

埋め込みリレーションシップ・インスタンスおよびそれがターゲットにするアイテムの作成は、アトミック・オペレーションである。アイテムは、ゼロ以上の埋め込みリレーションシップのソースになることができる。ただし、アイテムは、１つだけの埋め込みリレーションシップのターゲットになることができる。埋め込みリレーションシップのターゲットであるアイテムは、保持リレーションシップのターゲットになることはできない。

ターゲット・エンド・ポイント参照タイプはＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅである必要があり、リレーションシップ・インスタンスと同じデータ・ストアにあるアイテムを参照する必要がある。

リレーションシップ宣言で指定されているエンドポイント・アイテムのタイプは一般に、リレーションシップのインスタンスが作成されるときに強制される。エンドポイント・アイテムのタイプは、リレーションシップが確立された後は変更することができない。

埋め込みリレーションシップは、ターゲット・エンド・ポイントの操作上の整合性を制御する。たとえば、アイテムをシリアル化する操作は、そのアイテムから供給されるすべての埋め込みリレーションシップおよびそのすべてのターゲットのシリアル化を含むことができる。アイテムをコピーすると、その埋め込みアイテムもすべてコピーされる。

宣言の例を以下に示す。

ｄ）参照のリレーションシップ
参照リレーションシップは、それが参照するアイテムの存続期間を制御しない。さらに、参照リレーションシップは、ターゲットの存在を保証することも、リレーションシップ宣言で指定されているターゲットのタイプを保証することもない。つまり、参照リレーションシップは、ｄａｎｇｌｉｎｇであることができるということである。さらに、参照リレーションシップは、他のデータ・ストアにあるアイテムを参照することができる。参照リレーションシップは、Ｗｅｂページにおけるリンクと類似した概念と考えることができる。

参照リレーションシップの宣言の例を以下に示す。

ターゲット・エンド・ポイントでは任意の参照タイプが許可される。参照リレーションシップに加わるアイテムは、任意のアイテム・タイプであってもよい。

参照リレーションシップは、アイテム間の、多くの非ライフタイム管理リレーションシップをモデル化するために使用される。ターゲットの存在が強制されないので、参照リレーションシップは、疎結合のリレーションシップをモデル化する際に便利である。参照リレーションシップを使用して、他のコンピュータ上のストアを含む他のデータ・ストアにあるアイテムをターゲットにすることができる。

ｅ）規則および制約事項
以下の追加の規則および制約事項がリレーションシップに適用される。
・ アイテムは「厳密に１つの埋め込みリレーションシップ」または「１つまたは複数の保持リレーションシップ」のターゲットでなければならない。１つの例外は、ルート・アイテムである。アイテムは、ゼロ以上の参照リレーションシップのターゲットになることができる。
・ 埋め込みリレーションシップのターゲットであるアイテムは、保持リレーションシップのソースになることはできない。これは、参照のリレーションシップのソースであることができる。
・ アイテムは、ファイルから格上げされる場合には保持リレーションシップのソースになることはできない。これは、埋め込みリレーションシップおよび参照リレーションシップのソースになることができる。
・ ファイルから格上げされるアイテムは、埋め込みリレーションシップのターゲットになることはできない。

ｆ）リレーションシップの順序付け
少なくとも１つの実施例において、本発明のストレージ・プラットフォームはリレーションシップの順序付けをサポートする。順序付けは、基本リレーションシップ定義中の「Ｏｒｄｅｒ」という名前のプロパティを通じて行われる。Ｏｒｄｅｒフィールドには一意性の制約はない。同じ「順序」プロパティ値とのリレーションシップの順序は保証されない。ただし、下位の「順序」値を有するリレーションシップの後および上位の「順序」フィールド値を有するリレーションシップの前に順序付けられることは保証される。

アプリケーションは、組み合わせ（ＳｏｕｒｄｅＩｔｅｍＩＤ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ、Ｏｒｄｅｒ）の順序付けによりデフォルトの順序でリレーションシップを取得することができる。所定のアイテムから供給されるすべてのリレーションシップ・インスタンスは、コレクション内のリレーションシップのタイプにはかかわりなく、単一のコレクションとして順序付けされる。ただし、これは所定のタイプ（たとえばＦｏｌｄｅｒＭｅｍｂｅｒｓ）のすべてのリレーションシップが、所定のアイテムに対するリレーションシップのコレクションの順序付きサブセットであることを保証する。

リレーションシップを操作するためのデータ・ストアＡＰＩ３１２は、リレーションシップの順序付けをサポートするオペレーション・セットを実装する。オペレーションについて説明する上で役立つように、以下の用語を紹介しておく。
・ ＲｅｌＦｉｒｓｔは、順序値ＯｒｄＦｉｒｓｔを持つ順序付きコレクションにおける最初のリレーションシップである。
・ ＲｅｌＬａｓｔは、順序値ＯｒｄＬａｓｔを持つ順序付きコレクションにおける最後のリレーションシップである。
・ ＲｅｌＸは、順序値ＯｒｄＸを持つコレクションにおける所定のリレーションシップである。
・ ＲｅｌＰｒｅｖは、ＲｅｌＸにコレクション内で最も近い、ＯｒｄＸよりも小さい順序値ＯｒｄＰｒｅｖを持つリレーションシップである。
・ ＲｅｌＮｅｘｔは、ＲｅｌＸにコレクション内で最も近い、ＯｒｄＸよりも大きい順序値ＯｒｄＮｅｘｔを持つリレーションシップである。

オペレーションは、以下のものを含むが、これらに限定されることはない。
・ ＩｎｓｅｒｔＢｅｆｏｒｅＦｉｒｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、コレクション内の最初のリレーションシップとしてリレーションシップを挿入する。新しいリレーションシップの「Ｏｒｄｅｒ」プロパティの値は、ＯｒｄＦｉｒｓｔよりも小さくなる。
・ ＩｎｓｅｒｔＡｆｔｅｒＬａｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、コレクション内の最後のリレーションシップとしてリレーションシップを挿入する。新しいリレーションシップの「Ｏｒｄｅｒ」プロパティの値は、ＯｒｄＬａｓｔよりも大きくなる。
・ ＩｎｓｅｒｔＡｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、「Ｏｒｄｅｒ」プロパティに指定されている値を持つリレーションシップを挿入する。
・ ＩｎｓｅｒｔＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、所定の順序値を持つリレーションシップの前にリレーションシップを挿入する。新しいリレーションシップは、非包含的なＯｒｄＰｒｅｖとｏｒｄの間の「Ｏｒｄｅｒ」値を割り当てられる。
・ ＩｎｓｅｒｔＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、所定の順序値を持つリレーションシップの後にリレーションシップを挿入する。新しいリレーションシップは、非包含的なｏｒｄとＯｒｄＮｅｘｔの間の「Ｏｒｄｅｒ」値を割り当てられる。
・ ＭｏｖｅＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ）は、指定されている「Ｏｒｄｅｒ」値を持つリレーションシップの前に所定のリレーションシップＩＤを持つリレーションシップを移動する。リレーションシップは、非包含的なＯｒｄＰｒｅｖとｏｒｄの間の新しい「Ｏｒｄｅｒ」値を割り当てられる。
・ ＭｏｖｅＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ）は、指定されている「Ｏｒｄｅｒ」値を持つリレーションシップの後に所定のリレーションシップＩＤを持つリレーションシップを移動する。リレーションシップは、非包含的なｏｒｄとＯｒｄＮｅｘｔの間の新しい順序値を割り当てられる。

前述のように、すべてのアイテムはアイテム・フォルダのメンバでなければならない。リレーションシップに関して、すべてのアイテムはアイテム・フォルダとのリレーションシップを有する必要がある。本発明のいくつかの実施例において、特定のリレーションシップはアイテム間に存在するリレーションシップによって表される。

本発明のさまざまな実施例に対して実装されると、リレーションシップは、１つのアイテム（ソース）によってもう１つのアイテム（ターゲット）に「拡張される」有向２項リレーションシップを提供する。リレーションシップは、ソース・アイテム（拡張したアイテム）によって所有されているので、ソースが除去された場合にリレーションシップが除去される（たとえばソース・アイテムが削除されるとそのリレーションシップが削除される）。さらに、特定のインスタンスにおいて、リレーションシップはターゲット・アイテムの所有を共有（共同所有）することができ、そのような所有はリレーションシップ（リレーションシップ・プロパティ・タイプに関する図７を参照）のＩｓＯｗｎｅｄプロパティ（またはその相当物）に反映されることがある。これらの実施例において、新しいＩｓＯｗｎｅｄリレーションシップの作成は、自動的にターゲット・アイテムの参照カウントを増分し、そのようなリレーションシップの削除はターゲット・アイテムの参照カウントを減分することになる。これらの特定の実施例の場合、アイテムは、ゼロよりも大きい参照カウントを持つ場合に引き続き存在し、カウントがゼロに達するときは自動的に削除される。この場合も、アイテム・フォルダは、他のアイテムへのリレーションシップのセットを持つ（または持つことができる）アイテムであり、これらの他のアイテムはアイテム・フォルダのメンバーシップを備えている。リレーションについての他の実際の実装も可能であり、本明細書に説明されている機能を達成することが、本発明によって可能であり、また期待されている。

実際の実施態様にはかかわりなく、リレーションシップは１つのオブジェクトから別のオブジェクトへの選択可能な接続である。アイテムが複数のアイテム・フォルダおよび複数のカテゴリに属すことができる機能と、これらのアイテム、フォルダ、およびカテゴリがパブリックまたはプライベートであるかどうかは、アイテム・ベースの構造におけるその存在（またはその不足）に与えられる意味によって決められる。これらの論理リレーションシップは、物理的実装にかかわりなく、本明細書に説明されている機能を達成するために具体的に採用される、リレーションシップのセットに割り当てられた意味である。論理リレーションシップは、アイテム・フォルダおよびカテゴリが本質的には、それぞれアイテムの特殊なタイプであるので、あるアイテムとそのアイテム・フォルダまたはカテゴリ（その逆もあり）の間に確立される。したがって、アイテム・フォルダおよびカテゴリは、コピー、電子メール・メッセージへの追加、ドキュメントへの埋め込みなど、制限なく、他のアイテムと同じように制限なく処理することができる。アイテム・フォルダおよびカテゴリは、他のアイテムと同じメカニズムを使用してシリアル化およびデシリアル化することができる。（たとえば、ＸＭＬにおいて、すべてのアイテムはシリアル化フォーマットを持つ場合があり、このフォーマットはアイテム・フォルダ、カテゴリ、およびアイテムに同等に適用される。）
アイテムとそのアイテム・フォルダの間のリレーションシップを表す前述のリレーションシップは、アイテムからアイテム・フォルダへ、アイテム・フォルダからアイテムへ、またはその両方へ論理的に拡張することができる。アイテムからアイテム・フォルダに論理的に拡張するリレーションシップは、アイテム・フォルダがそのアイテムにパブリックでありそのメンバーシップ情報をそのアイテムと共有することを示している。逆に、アイテムからアイテム・フォルダへの論理リレーションシップの不足は、アイテム・フォルダがそのアイテムにプライベートであり、そのメンバーシップ情報をそのアイテムと共有しないことを示している。同様に、アイテム・フォルダからアイテムに論理的に拡張するリレーションシップは、アイテムがパブリックでありそのアイテム・フォルダに共有可能であることを示しているが、これに反して、アイテム・フォルダからアイテムへの論理リレーションシップの不足は、アイテムがプライベートであり共有可能ではないことを示している。したがって、アイテム・フォルダが他のシステムにエクスポートされるとき、これは新しいコンテクストで共有される「パブリック」アイテムであり、アイテムが他の共有可能なアイテムのそのアイテム・フォルダを検索するとき、これはそこに属する共有可能なアイテムに関する情報をアイテムに提供する「パブリック」アイテム・フォルダである。

図９は、アイテム・フォルダ（この場合も、これは１つのアイテム自体である）、そのメンバ・アイテム、およびアイテム・フォルダとそのメンバ・アイテムとの相互接続リレーションシップを示すブロック図である。アイテム・フォルダ９００は、複数のアイテム９０２、９０４、および９０６をメンバとして備えている。アイテム・フォルダ９００は、それ自身からアイテム９０２へのリレーションシップ９１２を備えているが、これはアイテム９０２が、アイテム・フォルダ９００、そのメンバ９０４および９０６、およびアイテム・フォルダ９００にアクセスする可能性のあるその他のアイテム・フォルダ、カテゴリ、またはアイテム（図示せず）に対してパブリックであり共有可能であることを示している。ただし、アイテム９０２からアイテム・フォルダ９００へのリレーションシップはなく、このことは、アイテム・フォルダ９００がアイテム９０２にプライベートであり、そのメンバーシップ情報をアイテム９０２と共有しないことを示している。一方、アイテム９０４は、それ自身からアイテム・フォルダ９００へのリレーションシップを備え、このことは、アイテム・フォルダ９００がパブリックであり、そのメンバーシップ情報をアイテム９０４と共有することを示している。ただし、アイテム・フォルダ９００からアイテム９０４へのリレーションシップはなく、これはアイテム９０４が、アイテム・フォルダ９００、その他のメンバ９０２および９０６、およびアイテム・フォルダ９００にアクセスする可能性のあるその他のアイテム・フォルダ、カテゴリ、またはアイテム（図示せず）に対してプライベートであり共有可能ではないことを示している。アイテム９０２および９０４へのそのリレーションシップとは対照的に、アイテム・フォルダ９００は、それ自身からアイテム９０６へのリレーションシップ９１６を備え、アイテム９０６はアイテム９００に戻るリレーションシップ９２６を備えているが、これは共に、アイテム９０６が、アイテム・フォルダ９００、そのメンバ９０２および９０４、およびアイテム・フォルダ９００にアクセスする可能性のあるその他のアイテム・フォルダ、カテゴリ、またはアイテム（図示せず）に対してパブリックであり共有可能であり、アイテム・フォルダ９００がパブリックであってそのメンバーシップ情報をアイテム９０６と共有することを示している。

前述のように、アイテム・フォルダは「記述されない」ので、アイテム・フォルダ内のアイテムは共通性を共有する必要はない。一方、カテゴリは、そのメンバ・アイテムすべてに共通する共通性によって記述される。したがって、カテゴリのメンバーシップは本質的に、記述された共通性を備えるアイテムに制限され、特定の実施例において、カテゴリの記述に適合するすべてのアイテムは自動的にカテゴリのメンバとされる。この結果、アイテム・フォルダは単純タイプ（trivial type）の構造がそのメンバーシップによって表されことを可能にし、カテゴリは、メンバーシップが定義済みの共通性に基づくこと可能にする。

もちろん、カテゴリの記述は本来論理的であり、そのためカテゴリはタイプ、プロパティ、および／または値の任意の論理表現によって記述することができる。たとえば、カテゴリの論理表現は、２つのプロパティのいずれか、または両方を持つアイテムを備えるようなメンバーシップにすることができる。カテゴリのこれらの記述されたプロパティが「Ａ」および「Ｂ」である場合、カテゴリのメンバーシップは、プロパティＡを有しプロパティＢを有しないアイテム、プロパティＢを有しプロパティＡを有しないアイテム、およびプロパティＡおよびＢを共に有するアイテムを備えることができる。プロパティのこの論理表現は、ここでカテゴリによって記述されるメンバのセットはプロパティＡまたはＢを有するアイテムである場合に論理演算子「ＯＲ」によって記述することができる。当業者であれば、同様の論理オペランド（「ＡＮＤ」、「ＸＯＲ」、および「ＮＯＴ」の単独または組み合わせ、ただしこれらに限定されない）を使用してもカテゴリを記述できることが理解されよう。

アイテム・フォルダ（記述されない）およびカテゴリ（記述される）の相違にもかかわらず、アイテムへのカテゴリのリレーションシップおよびカテゴリへのアイテムのリレーションシップは本質的に、本発明の多くの実施例におけるアイテム・フォルダおよびアイテムについて本明細書で先に開示されている方法と同様である。

図１０は、カテゴリ（この場合も、これは１つのアイテム自体である）、そのメンバ・アイテム、およびカテゴリとそのメンバ・アイテムとの相互接続リレーションシップを示すブロック図である。カテゴリ１０００は、複数のアイテム１００２、１００４、および１００６をメンバとして備えており、そのすべてが、カテゴリ１０００によって記述されているように（共通性記述１００８）共通のプロパティ、値、またはタイプの組み合わせ１００８を共有している。カテゴリ１０００は、それ自身からアイテム１００２へのリレーションシップ１０１２を備えているが、これはアイテム１００２が、カテゴリ１０００、そのメンバ１００４および１００６、およびカテゴリ１０００にアクセスする可能性のあるその他のカテゴリ、アイテム・フォルダ、またはアイテム（図示せず）に対してパブリックであり共有可能であることを示している。ただし、アイテム１００２からカテゴリ１０００へのリレーションシップはなく、このことは、カテゴリ１０００がアイテム１００２にプライベートであり、そのメンバーシップ情報をアイテム１００２と共有しないことを示している。一方、アイテム１００４は、それ自身からカテゴリ１０００へのリレーションシップを備え、このことは、カテゴリ１０００がパブリックであり、そのメンバーシップ情報をアイテム１００４と共有することを示している。ただし、カテゴリ１０００からアイテム１００４へ拡張されたリレーションシップはなく、これはアイテム１００４が、カテゴリ１０００、その他のメンバ１００２および１００６、およびカテゴリ１０００にアクセスする可能性のあるその他のカテゴリ、アイテム・フォルダ、またはアイテム（図示せず）に対してプライベートであり共有可能ではないことを示している。アイテム１００２および１００４とのそのリレーションシップ（またはその不在）とは対照的に、カテゴリ１０００は、それ自身からアイテム１００６へのリレーションシップ１０１６を備え、アイテム１００６はカテゴリ１０００に戻るリレーションシップ１０２６を備えているが、これは共に、アイテム１００６が、カテゴリ１０００、そのアイテム・メンバ１００２および１００４、およびカテゴリ１０００にアクセスする可能性のあるその他のカテゴリ、アイテム・フォルダ、またはアイテム（図示せず）に対してパブリックであり共有可能であり、カテゴリ１０００がパブリックであってそのメンバーシップ情報をアイテム１００６と共有することを示している。

最後に、カテゴリおよびアイテム・フォルダは、それ自体がアイテムであり、アイテムは相互にリレーションシップすることができるので、カテゴリはアイテム・フォルダとの間のリレーションシップを備えることができ、特定の代替実施例において、カテゴリ、アイテム・フォルダ、およびアイテムは、それぞれ他のカテゴリ、アイテム・フォルダ、およびアイテムにリレーションシップを備えることができる。ただし、さまざまな実施例において、アイテム・フォルダ構造および／またはカテゴリ構造は、ハードウェア／ソフトウェア・インターフェース・システム・レベルにおいて、サイクル（循環）を含むことが禁止されている。アイテム・フォルダおよびカテゴリ構造は、有向グラフと似ており、サイクルを禁止するこの実施例は、グラフ理論の分野における数学的定義によって、同一の頂点で開始および終了するパスがない有向グラフである有向非周期グラフ（ＤＡＧ：directed acyclic graphs）と類似したものになる。

６．拡張性
ストレージ・プラットフォームは、前述したように、スキーマ３４０の初期セットが提供されるように設計される。しかしさらに、少なくとも一部の実施例において、ストレージ・プラットフォームは、独立系ソフトウェアベンダ（ＩＳＶ）を含む顧客が新しいスキーマ３４４（新しいアイテムおよびネスト化要素のタイプなど）を作成できるようにする。このセクションでは、スキーマ３４０の初期セットにおいて定義されるアイテム・タイプおよびネスト化要素タイプ（または単に「要素」タイプ）を拡張することによってそのようなスキーマを作成するためのメカニズムについて説明する。

アイテムおよびネスト化要素タイプの初期セットの拡張は、以下のように制約されることが好ましい。
・ ＩＳＶは、新しいタイプ、つまりＢａｓｅ．Ｉｔｅｍのサブタイプを導入することができる。
・ ＩＳＶは、新しいネスト化要素タイプ、つまりＢａｓｅ．ＮｅｓｔｅｄＥｌｅｍｅｎｔのサブタイプを導入することができる。
・ ＩＳＶは、新しい拡張、つまりＢａｓｅ．ＮｅｓｔｅｄＥｌｅｍｅｎｔのサブタイプを導入することができる。しかし、
・ ＩＳＶはストレージ・プラットフォーム・スキーマ３４０の初期セットによって定義されるいかなるタイプ（アイテム、ネスト化要素、またはＥｘｔｅｎｓｉｏｎタイプ）もサブタイプ定義することはできない。

ストレージ・プラットフォーム・スキーマの初期セットによって定義されるアイテム・タイプまたはネスト化要素タイプはＩＳＶアプリケーションのニーズとは厳密には一致しないので、ＩＳＶがタイプをカスタマイズできるようにする必要がある。これは、Ｅｘｔｅｎｓｉｏｎの概念により可能になる。Ｅｘｔｅｎｓｉｏｎは、強く型付けされたインスタンス（strongly typed instances）であるが、（ａ）独立して存在することはできず、（ｂ）アイテムまたはネスト化要素に添付される必要がある。

スキーマ拡張性のニーズに対処することに加えて、Ｅｘｔｅｎｓｉｏｎは「マルチタイピング（multi-typing）」の問題に対処することも目的としている。一部の実施例において、ストレージ・プラットフォームは、複数の継承（multiple inheritance）または重複サブタイプ（overlapping subtypes）をサポートすることができないため、アプリケーションは重複タイプ・インスタンス（たとえば、ドキュメントは法律関係書類であり、その上機密保護文書である）をモデル化する方法として、Ｅｘｔｅｎｓｉｏｎを使用することができる。

ａ）アイテムの拡張
アイテムの拡張性を提供するため、データ・モデルはさらに、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎという名前の抽象タイプを定義する。これは、拡張タイプ（extension types）の階層に対するルート・タイプである。アプリケーションは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎをサブタイプ定義して特定の拡張タイプを作成することができる。

Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎタイプは、以下のように基本スキーマで定義される。

ＩｔｅｍＩＤフィールドは、拡張が関連付けられているアイテムのＩｔｅｍＩＤを含んでいる。このＩｔｅｍＩＤを持つアイテムは、存在する必要がある。所定のＩｔｅｍＩＤを持つアイテムが存在しない場合には、拡張は作成することができない。アイテムが削除されると、同じＩｔｅｍＩＤを持つすべての拡張は削除される。このタプル（ＩｔｅｍＩＤ、ＥｘｔｅｎｓｉｏｎＩＤ）は、拡張インスタンスを一意に定義する。

拡張タイプの構造は、アイテム・タイプの構造と類似している。
・ 拡張タイプはフィールドを持つ。
・ フィールドは、基本またはネスト化要素タイプにすることができる。
・ 拡張タイプはサブタイプ定義することができる。

拡張タイプには以下の制約が適用される。
・ 拡張は、リレーションシップのソースおよびターゲットにすることができない。
・ 拡張タイプ・インスタンスは、アイテムから独立して存在することができない。また、
・拡張タイプはストレージ・プラットフォーム・タイプ定義でフィールドタイプとして使用することができない。

所定のアイテム・タイプに関連付けることのできる拡張のタイプには、何の制約も課されない。任意の拡張タイプが、任意のアイテム・タイプを拡張することができる。複数の拡張インスタンスが１つのアイテムに添付される場合、これらは構造および振る舞いのいずれにおいても相互に独立したものになる。

拡張インスタンスは、アイテムとは個別に格納され、アクセスされる。すべての拡張タイプ・インスタンスは、グローバル拡張ビューからアクセス可能である。関連付けられているアイテムのタイプにはかかわりなく、拡張の所定のタイプのインスタンスをすべて返す効率的なクエリを作成することができる。ストレージ・プラットフォームＡＰＩは、アイテムの拡張を格納し、取り出し、変更することができるプログラミング・モデルを提供する。

拡張タイプは、ストレージ・プラットフォームの単一継承モデルを使用してサブタイプ定義されたタイプにすることができる。拡張タイプからの派生は、新しい拡張タイプを作成する。拡張の構造または振る舞いは、アイテム・タイプ階層の構造または振る舞いをオーバーライドまたは置き換えることはできない。アイテム・タイプと同様に、Ｅｘｔｅｎｓｉｏｎタイプ・インスタンスは、拡張タイプに関連付けられているビューを通じて直接アクセスすることができる。拡張のＩｔｅｍＩＤは、属しているアイテムを示し、グローバル・アイテム・ビューから対応するアイテム・オブジェクトを取り出すために使用することができる。拡張は、オペレーション上の整合性を保つ目的で、アイテムの一部と見なされる。ストレージ・プラットフォームが定義するコピー／移動、バックアップ／復元、および他の共通の操作は、アイテムの一部として拡張に関して操作することもできる。

次のような例を考察する。Ｃｏｎｔａｃｔタイプは、Ｗｉｎｄｏｗｓ（登録商標）タイプセットで定義される。

ＣＲＭアプリケーション開発者は、ストレージ・プラットフォームに格納されている連絡先にＣＲＭアプリケーション拡張を添付したいと考えるであろう。アプリケーション開発者は、アプリケーションが操作できる追加のデータ構造を含むようなＣＲＭ拡張を定義するであろう。

ＨＲアプリケーション開発者は、連絡先を持つ追加データも添付したいと考えるであろう。このデータは、ＣＲＭアプリケーションデータからは独立している。この場合も、アプリケーション開発者は拡張を作成することができる。

ＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは、Ｃｏｎｔａｃｔアイテムに添付できる２つの独立した拡張である。これらは、相互に独立して、作成され、アクセスされる。

上記の例において、ＣＲＭＥｘｔｅｎｓｉｏｎタイプのフィールドおよびメソッドは、Ｃｏｎｔａｃｔ階層のフィールドまたはメソッドをオーバーライドすることはできない。ＣＲＭＥｘｔｅｎｓｉｏｎタイプのインスタンスは、Ｃｏｎｔａｃｔ以外のアイテム・タイプに添付できることに留意されたい。

Ｃｏｎｔａｃｔアイテムが取り出されるとき、そのアイテム拡張が自動的に取り出されることはない。Ｃｏｎｔａｃｔアイテムを与えられて、その関連するアイテム拡張は、同じＩｔｅｍＩｄを持つ拡張に対してグローバル拡張ビューにクエリを行うことによってアクセスすることができる。

システム内のすべてのＣＲＭＥｘｔｅｎｓｉｏｎ拡張は、属しているアイテムにはかかわりなく、ＣＲＭＥｘｔｅｎｓｉｏｎタイプ・ビューを通じてアクセスすることができる。アイテムのすべてのアイテム拡張は、同じアイテムＩＤを共有する。上記の例において、Ｃｏｎｔａｃｔアイテム・インスタンスと、添付されたＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎインスタンスは、同じＩｔｅｍＩＤを共有する。

以下の表に、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＮｅｓｔｅｄＥｌｅｍｅｎｔタイプの類似点および相違点を概要して示す。

ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプの拡張
ネスト化要素タイプは、アイテム・タイプと同じメカニズムでは拡張されない。ネスト化要素の拡張は、ネスト化要素タイプのフィールドと同じメカニズムで格納され、アクセスされる。

データ・モデルは、Ｅｌｅｍｅｎｔという名前のネスト化要素タイプのルートを定義する。

ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプは、このタイプから継承する。ＮｅｓｔｅｄＥｌｅｍｅｎｔ要素タイプはさらに、要素のマルチセットであるフィールドを定義する。

ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張は、以下の点でアイテム拡張とは異なっている。
・ ネスト化要素拡張は、拡張タイプではない。これらは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎタイプにルートされる拡張タイプ階層に属していない。
・ ネスト化要素拡張は、アイテムの他のフィールドと共に格納され、グローバルにアクセス可能ではない。所定の拡張タイプのすべてのインスタンスを取り出すクエリは作成することができない。
・ これらの拡張は、（アイテムの）他のネスト化要素が格納される方法と同じ方法で格納される。他のネスト化セットと同様に、ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張はＵＤＴに格納される。これらは、ネスト化要素タイプのＥｘｔｅｎｓｉｏｎ・フィールドを通じてアクセス可能である。
・ 多値のプロパティ（multi-valued properties）にアクセスするために使用されるコレクション・インターフェースは、タイプ拡張のセットにアクセスして繰り返すためにも使用される。

以下の表で、Ｉｔｅｍ拡張およびＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張を概要して比較する。

Ｄ．データベース・エンジン
前述のように、データ・ストアはデータベース・エンジン上に実装される。本発明の実施例において、データベース・エンジンは、オブジェクト・リレーションシップ拡張を備える、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンなどの、ＳＱＬクエリ言語を実装するリレーショナル・データベース・エンジンを備えている。このセクションでは、データ・ストアが実装するデータ・モデルのリレーショナル・ストアへのマッピングについて説明し、本発明の実施例に従って、ストレージ・プラットフォーム・クライアントによって消費される論理ＡＰＩに関する情報を提供する。ただし、異なるデータベース・エンジンが採用される場合に異なるマッピングを採用できることを理解されたい。実際、リレーショナル・データベース・エンジンにストレージ・プラットフォームの概念データ・モデルを実装することに加えて、オブジェクト指向およびＸＭＬデータベースなど、他の種類のデータベースに実装することも可能である。

オブジェクト指向（ＯＯ）データベース・システムは、プログラミング言語オブジェクト（たとえばＣ＋＋、Ｊａｖａ（登録商標）など）の永続性（persistence）およびトランザクションを提供する。ストレージ・プラットフォームの「アイテム」の概念は、埋め込みコレクションをオブジェクトに追加する必要があるけれども、オブジェクト指向システムにおける「オブジェクト」に適切に対応する。他のストレージ・プラットフォームの概念は、継承およびネスト化要素タイプと同様に、オブジェクト指向タイプのシステムにも対応する。オブジェクト指向システムは通常、既にオブジェクトＩＤをサポートしており、したがって、アイテムＩＤはオブジェクトＩＤにマップすることができる。アイテムの振る舞い（operations）は、オブジェクト・メソッドに適切に対応する。しかし、オブジェクト指向システムは通常、組織的な能力に欠けており、検索機能も劣っている。また、オブジェクト指向システムは、構造化されていない半構造のデータにサポートを提供しない。本明細書に説明する完全なストレージ・プラットフォーム・データ・モデルをサポートするために、リレーションシップ、フォルダ、および拡張などの概念をオブジェクト・データ・モデルに追加する必要がある。さらに、格上げ（promotions）、同期化、通知、およびセキュリティなどのメカニズムも実装する必要がある。

オブジェクト指向システムと同様に、ＸＳＤ（ＸＭＬスキーマ定義）に基づくＸＭＬデータベースは、単一継承ベースのタイプ・システム（single-inheritance based type system）をサポートする。本発明のアイテム・タイプ・システムは、ＸＳＤタイプモデルにマップすることもできる。ＸＳＤもまた、振る舞いへのサポートを提供しない。アイテム用のＸＳＤは、アイテムの振る舞いに対して増強される必要がある。ＸＭＬデータベースは単一のＸＳＤドキュメントを扱い、組織化および広範な検索能力が不足している。オブジェクト指向データベースの場合と同様に、本明細書に説明するデータ・モデルをサポートするため、リレーションシップなどの他の概念、およびフォルダはそのようなＸＭＬデータベースに組み込まれる必要がある。さらに、同期化、通知およびセキュリティのようなメカニズムも実装される必要がある。

以下のサブセクションに関して、一般情報の開示を容易にするためにいくつかの図が示される。図１３は、通知メカニズムを示す図である。図１４は、２つのトランザクションが共に新しいレコードを同じＢツリーに挿入する例を示す図である。図１５は、データ変更検出プロセスを示す図である。図１６は、例示的なディレクトリ・ツリーを示す図である。図１７は、ディレクトリ・ベースのファイル・システムの既存フォルダがストレージ・プラットフォームのデータ・ストアに移動される例を示す図である。

１．ＵＤＴ（ユーザ定義タイプ）を使用するデータ・ストアの実装
本発明の実施例において、リレーショナル・データベース・エンジン３１４は、１つの実施例でＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンを備えており、組み込みスカラ・タイプをサポートする。組み込みスカラ・タイプは、「ネイティブ」でしかも「単純（simple）」である。これは、ユーザが独自のタイプを定義できないという意味でネイティブであり、複雑な構造をカプセル化できないという点で単純である。ユーザ定義タイプ（User-defined types）（以下ＵＤＴと呼ぶ）は、複雑な構造化タイプを定義してユーザがタイプ・システムを拡張できるようにすることによって、ネイティブのスカラ・タイプ・システムを超えるタイプ拡張性のメカニズムを提供する。ユーザによって定義されると、ＵＤＴは、組み込みスカラ・タイプが使用されるタイプ・システム内のどこでも使用することができる。

本発明の態様によれば、ストレージ・プラットフォーム・スキーマは、データベース・エンジン・ストア内のＵＤＴクラスにマップされる。データ・ストア・アイテムは、Ｂａｓｅ．Ｉｔｅｍタイプから派生するＵＤＴクラスにマップされる。アイテムと同様に、ＥｘｔｅｎｓｉｏｎはＵＤＴクラスにもマップされ、継承を利用する。ルートＥｘｔｅｎｓｉｏｎタイプはＢａｓｅ．Ｅｘｔｅｎｓｉｏｎであり、これからすべてのＥｘｔｅｎｓｉｏｎタイプが派生する。

ＵＤＴはＣＬＲクラスである。これは状態（データ・フィールドなど）および振る舞い（ルーチンなど）を備えている。ＵＤＴは、Ｃ＃、ＶＢ．ＮＥＴなど、管理下の言語を使用して定義される。ＵＤＴメソッドおよび演算子は、そのタイプのインスタンスに対してＴ−ＳＱＬで呼び出すことができる。ＵＤＴは、行（rows）内のカラムのタイプ、Ｔ−ＳＱＬ内のルーチンのパラメータのタイプ、またはＴ−ＳＱＬ内の変数のタイプのいずれかにできる。

ストレージ・プラットフォームのスキーマのＵＤＴクラスへのマッピングは、高レベルにおいてかなり直接的である。一般に、ストレージ・プラットフォーム・スキーマはＣＬＲネーム・スペースにマップされる。ストレージ・プラットフォーム・タイプは、ＣＬＲクラスにマップされる。ＣＬＲクラス継承は、ストレージ・プラットフォーム・タイプ継承をミラーリングし、ストレージ・プラットフォーム・プロパティはＣＬＲクラス・プロパティにマップされる。

２．アイテムのマッピング
アイテムがグローバルに検索可能であることの望ましさ、および本発明の実施例のリレーショナル・データベースにおける継承およびタイプ代替性のサポートを考慮すれば、データベース・ストアにおけるアイテムストレージの１つの可能な実施態様は、すべてのアイテムをタイプＢａｓｅ．Ｉｔｅｍのカラムを持つ単一のテーブルに格納することになる。タイプ代替性を使用して、すべてのタイプのアイテムは格納することができ、検索はＹｕｋｏｎの「ｉｓ ｏｆ（Ｔｙｐｅ）」演算子を使用して、アイテム・タイプおよびサブタイプによってフィルタすることができる。

しかし、そのような方法に関連付けられるオーバーヘッドの懸念のために、本発明の実施例においては、アイテムは、各タイプのアイテム「ｆａｍｉｌｙ」が別々のテーブルに格納されるように、最上位タイプによって分割される。この区分化方式のもとで、テーブルはＢａｓｅ．Ｉｔｅｍから直接に継承するアイテム・タイプごとに作成される。これらより下位で継承するタイプは、前述のタイプ代替性を使用して適切なタイプ・ファミリ・テーブルに格納される。Ｂａｓｅ．Ｉｔｅｍからの継承の第１レベルのみが、特別に処理される。

「シャドー」テーブルは、すべてのアイテムのグローバルに検索可能なプロパティのコピーを格納するために使用される。このテーブルは、ストレージ・プラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドによって保持され、これを通じてすべてのデータ変更が行われる。タイプ・ファミリ・テーブルとは異なり、このグローバルなアイテム・テーブルは、完全なＵＤＴアイテム・オブジェクトではなく、アイテムの最上位スカラ・プロパティのみを含んでいる。このグローバルなアイテム・テーブルは、ＩｔｅｍＩＤおよびＴｙｐｅＩＤを公開することによってタイプ・ファミリ・テーブルに格納されているアイテム・オブジェクトへのナビゲーションを可能にする。ＩｔｅｍＩＤは一般に、データ・ストア内のアイテムを一意に識別する。ＴｙｐｅＩＤはメタデータを使用してタイプ名、およびアイテムを含むビューにマップすることができるが、このことについては本明細書では説明しない。アイテムをそのＩｔｅｍＩＤによって見つけることは、グローバルなアイテム・テーブルおよびその他のコンテクストにおいて、一般的なオペレーションであるため、ＧｅｔＩｔｅｍ（）関数が、アイテムのＩｔｅｍＩＤを与えられたアイテム・オブジェクトを取り出すために提供される。

アクセスを便利にするため、また実施態様の詳細を可能な範囲内で秘匿するため、アイテムのすべてのクエリは前述のアイテム・テーブルを基に構築したビューに対するものにできる。特に、ビューは、適切なタイプ・ファミリ・テーブルに対してアイテム・タイプごとに作成することができる。これらのタイプ・ビューは、サブタイプを含む関連するタイプのすべてのアイテムを選択することができる。便宜上、ＵＤＴオブジェクトに加えて、ビューは、継承されたフィールドを含むそのタイプの最上位のフィールドすべてのカラムを公開する（見えるようにする）ことができる。

３．拡張のマッピング
Ｅｘｔｅｎｓｉｏｎは、アイテムと非常によく似ており、同じ要件をいくつか備えている。継承をサポートするもう１つのルート・タイプとして、Ｅｘｔｅｎｓｉｏｎは、ストレージにおける多くの同じ考慮事項およびトレードオフの影響を受けやすい。そのため、単一テーブルの方法ではなく、類似するファミリ・マッピングのタイプが、Ｅｘｔｅｎｓｉｏｎに適用される。もちろん、他の実施例において、単一テーブルの方法を使用することもできる。本発明の実施例において、ＥｘｔｅｎｓｉｏｎはＩｔｅｍＩＤにより厳密に１つのアイテムに関連付けられており、アイテムのコンテクストで一意のＥｘｔｅｎｓｉｏｎＩＤを含んでいる。アイテムの場合と同様に、その識別を与えられたＥｘｔｅｎｓｉｏｎを取り出すために関数が提供される。これはＩｔｅｍＩＤおよびＥｘｔｅｎｓｉｏｎＩＤのペアで構成される。ビューは、Ｅｘｔｅｎｓｉｏｎタイプごとに作成される。これはアイテム・タイプ・ビューと類似している。

４．ネスト化要素（Nested Element）のマッピング
ネスト化要素は、アイテム、Ｅｘｔｅｎｓｉｏｎ、リレーションシップ、または深くネストされた構造を形成するために他のネスト化要素に埋め込まれることができるタイプである。アイテムおよびＥｘｔｅｎｓｉｏｎと同様に、ネスト化要素はＵＤＴとして実装されるが、これらはアイテムおよびＥｘｔｅｎｓｉｏｎ内に格納される。したがってネスト化要素は、そのアイテムおよびＥｘｔｅｎｓｉｏｎのコンテナを超えるストレージ・マッピングは備えていない。つまり、ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプのインスタンスを直接格納する、システム内のテーブルはなく、ネスト化要素に特に専用化されたビューもない。

５．オブジェクトのＩＤ｝（identity）
データ・モデル内の各エンティティ、つまり各アイテム、Ｅｘｔｅｎｓｉｏｎ、およびリレーションシップは、一意のキー値（key value）を持っている。アイテムは、そのＩｔｅｍＩｄによって一意に識別される。Ｅｘｔｅｎｓｉｏｎは、（ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ）の複合キーによって一意に識別される。リレーションシップは、（ＩｔｅｍＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄ）の複合キーによって一意に識別される。ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ、およびＲｅｌａｔｉｏｎｓｈｉｐＩｄは、ＧＵＩＤ値である。

６．ＳＱＬオブジェクトの命名
データ・ストアで作成されたすべてのオブジェクトは、ストレージ・プラットフォーム・スキーマ名から派生したＳＱＬスキーマ名で格納することができる。たとえば、ストレージ・プラットフォーム基本スキーマ（多くは「Ｂａｓｅ」と呼ばれる）は、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．Ｉｔｅｍ」などの「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］」ＳＱＬスキーマでタイプを生成することができる。生成される名前には、命名上の競合をなくすために先頭に修飾子が付けられる。必要に応じて、名前の各論理部分の区切り記号として感嘆符文字（！）が使用される。以下の表は、データ・ストア内のオブジェクトに使用される命名規則の概要を示している。各スキーマ要素（アイテム、Ｅｘｔｅｎｓｉｏｎ、リレーションシップおよびビュー）は、データ・ストア内のインスタンスにアクセスするために使用される装飾された命名規則と共に一覧されている。

７．カラムの命名
オブジェクト・モデルをストア内にマッピングするとき、アプリケーション・オブジェクトと共に格納される追加情報が原因となり、命名の衝突が発生する可能性がある。命名の衝突を防ぐために、すべての非タイプの特定のカラム（non-type specific columns）（タイプ宣言における名前付きプロパティに直接マップされないカラム）には、下線（＿）文字が先頭に付けられる。本発明の実施例において、下線（＿）文字は、識別子プロパティの開始文字としては許可されない。さらに、ＣＬＲおよびデータ・ストアの間の命名を統一するため、ストレージ・プラットフォーム・タイプまたはスキーマ要素（リレーションシップなど）のすべてのプロパティは、最初の文字を大文字にする必要がある。

８．検索ビュー
ビューは、格納されているコンテンツを検索するためにストレージ・プラットフォームによって提供される。ＳＱＬビューは、アイテムおよびＥｘｔｅｎｓｉｏｎタイプごとに提供される。さらに、ビューは、リレーションシップおよび（データ・モデルによって定義される）Ｖｉｅｗをサポートするために提供される。ストレージ・プラットフォーム内のすべてのＳＱＬビューと基礎をなすテーブルは、読み取り専用である。データは、以下でさらに詳細に説明するように、ストレージ・プラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドを使用して格納または変更することができる。

ストレージ・プラットフォーム・スキーマ（スキーマ設計者によって定義されるもので、ストレージ・プラットフォームによって自動的に生成されない）で明示的に定義された各ビューは、名前付きＳＱＬビュー［＜ｓｃｈｅｍａ−ｎａｍｅ＞］．［Ｖｉｅｗ！＜ｖｉｅｗ−ｎａｍｅ＞］によってアクセスすることができる。たとえば、スキーマ「ＡｃｍｅＰｕｂｌｉｓｈｅｒ．Ｂｏｏｋｓ」内の「ＢｏｏｋＳａｌｅｓ」という名前のビューは、「［ＡｃｍｅＰｕｂｌｉｓｈｅｒ．Ｂｏｏｋｓ］．［Ｖｉｅｗ！ＢｏｏｋＳａｌｅｓ］」という名前を使用してアクセス可能である。ビューの出力フォーマットはビュー単位ベースのカスタムである（ビューを定義する当事者が提供する任意のクエリによって定義される）ため、カラムはスキーマ・ビュー定義に基づいて直接マップされる。

ストレージ・プラットフォーム・データ・ストア内のすべてのＳＱＬ検索ビューは、カラムに対して以下の順序付けの規則を使用する。
・ ＩｔｅｍＩｄ、ＥｌｅｍｅｎｔＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄなどのビュー結果の論理「Ｋｅｙ」カラム
・ ＴｙｐｅＩｄなどの結果のタイプに関するメタデータ情報
・ Ｃｒｅａｔｅ Ｖｅｒｓｉｏｎ、Ｕｐｄａｔｅ Ｖｅｒｓｉｏｎなどの変更追跡カラム
・ タイプ固有のカラム（宣言済みタイプのプロパティ）
・ タイプ固有のビュー（ファミリ・ビュー）はオブジェクトを返すオブジェクト・カラムも含む
各タイプ・ファミリのメンバは、一連のアイテム・ビューを使用して検索可能であり、データ・ストア内のアイテム・タイプごとに１つのビューがある。図２８は、アイテム検索ビューの概念を示す図である。

ａ）アイテム
各アイテム検索ビューは、固有のタイプまたはそのサブタイプのアイテムのインスタンスごとに行（row）を含んでいる。たとえば、Ｄｏｃｕｍｅｎｔのビューは、Ｄｏｃｕｍｅｎｔ、ＬｅｇａｌＤｏｃｕｍｅｎｔおよびＲｅｖｉｅｗＤｏｃｕｍｅｎｔのインスタンスを返すことができる。この例を上げると、アイテム・ビューは図２９に示されているように概念的に説明することができる。

（１）マスタ・アイテム検索ビュー
ストレージ・プラットフォーム・データ・ストアの各インスタンスは、マスタ・アイテム・ビューと呼ばれる特殊なアイテム・ビューを定義する。このビューは、データ・ストア内の各アイテムに関する概要情報を提供する。ビューは、アイテム・タイプ・プロパティごとに１つのカラム、アイテムのタイプを記述するカラム、および変更追跡と同期化情報を提供するために使用される複数のカラムを提供する。マスタ・アイテム・ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」を使用してデータ・ストア内で識別される。

（２）タイプ定義済みアイテム検索ビュー
各アイテム・タイプも検索ビューを備えている。ルート・アイテム・ビューと類似しているが、このビューは「＿Ｉｔｅｍ」カラムを介してアイテム・オブジェクトへのアクセスも提供する。各タイプ定義済みアイテム検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［ｉｔｅｍＴｙｐｅＮａｍｅ］を使用してデータ・ストア内で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［ＯｆｆｉｃｅＤｏｃ］である。

ｂ）アイテムＥｘｔｅｎｓｉｏｎ
ＷｉｎＦＳ ＳｔｏｒｅにおけるすべてのアイテムＥｘｔｅｎｓｉｏｎは、検索ビューを使用してもアクセス可能である。

（１）マスタＥｘｔｅｎｓｉｏｎ検索ビュー
データ・ストアの各インスタンスは、「マスタＥｘｔｅｎｓｉｏｎビュー」と呼ばれる特殊Ｅｘｔｅｎｓｉｏｎビューを定義する。このビューは、データ・ストア内の各Ｅｘｔｅｎｓｉｏｎに関する概要情報を提供する。ビューは、Ｅｘｔｅｎｓｉｏｎプロパティごとに１つのカラム、Ｅｘｔｅｎｓｉｏｎのタイプを記述するカラム、および変更追跡と同期化情報を提供するために使用される複数のカラムを備えている。マスタ拡張ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｅｘｔｅｎｓｉｏｎ］」を使用してデータ・ストア内で識別される。

（２）タイプ定義済みＥｘｔｅｎｓｉｏｎ検索ビュー
各Ｅｘｔｅｎｓｉｏｎタイプも検索ビューを備えている。マスタ拡張ビューと類似しているが、このビューはＥｘｔｅｎｓｉｏｎカラムを介してアイテム・オブジェクトへのアクセスも提供する。各タイプ定義済み拡張検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［Ｅｘｔｅｎｓｉｏｎ！ｅｘｔｅｎｓｉｏｎＴｙｐｅＮａｍｅ］を使用してデータ・ストア内で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｅｘｔｅｎｓｉｏｎ！ＯｆｆｉｃｅＤｏｃＥｘｔ］である。

ｃ）ネスト化要素
すべてのネスト化要素は、アイテム、Ｅｘｔｅｎｓｉｏｎまたはリレーションシップ・インスタンス内に格納される。したがって、これらは、適切なアイテム、Ｅｘｔｅｎｓｉｏｎ、またはリレーションシップ検索ビューにクエリを行うことによりアクセスできる。

ｄ）リレーションシップ
前述のように、リレーションシップはストレージ・プラットフォーム・データ・ストア内のアイテム間をリンクする基本単位を形成する。

（１）マスタ・リレーションシップ検索ビュー
各データ・ストアは、マスタ・リレーションシップ・ビューを提供する。このビューは、データ・ストア内のすべてのリレーションシップ・インスタンスに関する情報を提供する。マスタ・リレーションシップ・ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｒｅｌａｔｉｏｎｓｈｉｐ］」を使用してデータ・ストア内で識別される。

（２）リレーションシップ・インスタンス拡張検索ビュー
各宣言済みリレーションシップは、特定のリレーションシップのすべてのインスタンスを返す検索ビューも備えている。マスタ・リレーションシップ・ビューと類似しているが、このビューはリレーションシップ・データのプロパティごとに名前付きカラムも提供する。各リレーションシップ・インスタンス検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ｒｅｌａｔｉｏｎｓｈｉｐＮａｍｅ］を使用してデータ・ストア内で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ］である。

ｅ）
９．更新
ストレージ・プラットフォーム・データ・ストア内のすべてのビューは、読み取り専用である。データ・モデル要素（アイテム、Ｅｘｔｅｎｓｉｏｎまたはリレーションシップ）の新しいインスタンスを作成するため、または既存のインスタンスを更新するため、ストレージ・プラットフォームＡＰＩのＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎまたはＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドを使用する必要がある。ＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎメソッドは、データ・ストアによって定義される単一のストアド・プロシージャであり、これは、実行すべきアクションを詳述する「ｏｐｅｒａｔｉｏｎ」を消費する。ＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドは、「ｕｐｄａｔｅｇｒａｍ」として知られるオペレーションの順序付きセットを取り込むストアド・プロシージャであり、これは、実行すべきアクションのセットを一括して詳述する。

オペレーション・フォーマットは、拡張可能であり、スキーマ要素に対してさまざまなオペレーションを提供する。共通のオペレーションには次のようなものがある。
１．アイテムのオペレーション：
ａ．ＣｒｅａｔｅＩｔｅｍ（埋め込みまたは保持リレーションシップのコンテクストで新しいアイテムを作成する）
ｂ．ＵｐｄａｔｅＩｔｅｍ（既存のアイテムを更新する）
２．リレーションシップのオペレーション：
ａ．ＣｒｅａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（参照または保持リレーションシップのインスタンスを作成する）
ｂ．ＵｐｄａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（リレーションシップ・インスタンスを更新する）
ｃ．ＤｅｌｅｔｅＲｅｌａｔｉｏｎｓｈｉｐ（リレーションシップ・インスタンスを削除する）
３．Ｅｘｔｅｎｓｉｏｎのオペレーション：
ａ．ＣｒｅａｔｅＥｘｔｅｎｓｉｏｎ（既存のアイテムに拡張を追加する）
ｂ．ＵｐｄａｔｅＥｘｔｅｎｓｉｏｎ（既存の拡張を更新する）
ｃ．ＤｅｌｅｔｅＥｘｔｅｎｓｉｏｎ（拡張を削除する）

１０．変更追跡およびトゥームストーン
変更追跡およびトゥームストーン・サービスは、データ・ストアによって提供されるが、これについては以下でさらに詳細に説明する。このセクションでは、データ・ストア内で公開される変更追跡情報の概要について説明する。

ａ）変更追跡
データ・ストアが提供す各検索ビューは、変更追跡情報を提供するために使用されるカラムを含んでいる。このカラムは、すべてのアイテム、Ｅｘｔｅｎｓｉｏｎおよびリレーションシップ・ビューにわたり共通である。スキーマ設計者によって明示的に定義されるストレージ・プラットフォーム・スキーマ・ビューは、変更追跡情報を自動的には提供しない。そのような情報は、ビューそのものが構築される検索ビューを通じて間接的に提供される。

データ・ストア内の要素ごとに、変更追跡情報は、「マスタ」要素ビューおよび「タイプ定義済み」要素ビューという２つの場所から提供される。たとえば、ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ．Ｄｏｃｕｍｅｎｔ Ｉｔｅｍタイプに関する変更追跡情報は、マスタ・アイテム・ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」およびタイプ定義済みアイテム検索ビュー［ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ］．［Ｄｏｃｕｍｅｎｔ］から利用可能である。

（１）「マスタ」検索ビューの変更追跡
マスタ検索ビューの変更追跡情報は、要素の作成および更新バージョンに関する情報、要素を作成した同期パートナ、要素を最終更新した同期パートナに関する情報、および作成と更新に対する各パートナからのバージョン番号を提供する。同期リレーションシップ（以下で説明）のパートナは、パートナキーによって識別される。タイプ［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓｔｏｒｅ］．ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏのＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏという名前の単一のＵＤＴオブジェクトは、この情報をすべて含んでいる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅスキーマで定義される。ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏは、アイテム、Ｅｘｔｅｎｓｉｏｎおよびリレーションシップのすべてのグローバル検索ビューで使用することができる。ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏのタイプ定義は以下のとおりである。

これらのプロパティは、以下の情報を含んでいる。

（２）「タイプ定義済み」検索ビューの変更追跡
グローバル検索ビューと同じ情報を提供することに加えて、各タイプ定義済み検索ビューは、同期トポロジの各要素の同期状態を記録する追加情報を提供する。

ｂ）トゥームストーン
データ・ストアは、アイテム、Ｅｘｔｅｎｓｉｏｎ、およびリレーションシップのトゥームストーン情報を提供する。トゥームストーン・ビューは、１つの場所で、生のエンティティ（live entity）およびトゥームストーンに入れられたエンティティ（アイテム、拡張およびリレーションシップ）に関する情報を提供する。アイテムおよび拡張のトゥームストーン・ビューは対応するオブジェクトへのアクセスを提供しないが、リレーションシップ・トゥームストーン・ビューはリレーションシップ・オブジェクトへのアクセスを提供する（トゥームストーンにあるリレーションシップの場合、そのリレーションシップ・オブジェクトはＮＵＬＬである）。

（１）アイテムのトゥームストーン
アイテム・トゥームストーンは、ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｉｔｅｍ］」を介してシステムから取り出される。

（２）拡張のトゥームストーン
拡張トゥームストーンは、ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｅｘｔｅｎｓｉｏｎ］」を介してシステムから取り出される。Ｅｘｔｅｎｓｉｏｎ変更追跡情報は、アイテムに提供される情報と類似しているが、さらにＥｘｔｅｎｓｉｏｎＩｄプロパティが加わっている。

（３）リレーションシップのトゥームストーン
リレーションシップ・トゥームストーンは、ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｒｅｌａｔｉｏｎｓｈｉｐ］」を介してシステムから取り出される。リレーションシップ・トゥームストーン情報は、Ｅｘｔｅｎｓｉｏｎで提供されるものと同様である。ただし、追加情報は、リレーションシップ・インスタンスのターゲットＩｔｅｍＲｅｆで提供される。さらに、リレーションシップ・オブジェクトも選択される。

（４）トゥームストーンのクリーンアップ
トゥームストーン情報の際限のない増大を防ぐために、データ・ストアはトゥームストーン・クリーンアップ・タスクを提供する。このタスクは、トゥームストーン情報をいつ廃棄できるか決める。このタスクは、ローカルの作成／更新バージョンのバウンドを計算してから、以前のトゥームストーン・バージョンをすべて廃棄することによりトゥームストーン情報を切り捨てる。

１１．ヘルパーＡＰＩおよび関数
基本マッピングは、いくつかのヘルパー関数も提供する。これらの関数は、データ・モデルに対する共通のオペレーションを補助するために供給される。

ａ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＩｔｅｍ

ｂ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＥｘｔｅｎｓｉｏｎ

ｃ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＲｅｌａｔｉｏｎｓｈｉｐ

１２．メタデータ
ストアで表されるメタデータのタイプには、インスタンス・メタデータ（アイテムのタイプなど）およびタイプ・メタデータの２つがある。

ａ）スキーマ・メタデータ
スキーマ・メタデータは、Ｍｅｔａスキーマからのアイテム・タイプのインスタンスとしてデータ・ストアに格納される。

ｂ）インスタンス・メタデータ
インスタンス・メタデータは、アイテムのタイプのクエリを行いう、アイテムに関連付けられているＥｘｔｅｎｓｉｏｎを見つけるためにアプリケーションによって使用される。アイテムのＩｔｅｍＩｄを与えられると、アプリケーションは、アイテムのタイプを返すようにグローバル・アイテム・ビューにクエリを行って、その値を使用してアイテムの宣言済みタイプに関する情報を返すように、Ｍｅｔａ．Ｔｙｐｅビューにクエリを行うことができる。たとえば、以下のようになる。

Ｅ．セキュリティ
一般に、すべての確保できるオブジェクトは、図２６に示すアクセス・マスク・フォーマットを使用してそのアクセス権を調整する。このフォーマットにおいて、下位の１６ビットはオブジェクト固有のアクセス権用であり、次の７ビットは標準アクセス権用であり（ほとんどのオブジェクトのタイプに適用する）、上位の４ビットは、汎用アクセス権を指定するために使用され、ここで、各オブジェクト・タイプは標準およびオブジェクト固有のアクセス権の設定にマップできる。ＡＣＣＥＳＳ−ＳＹＳＴＥＭ−ＳＥＣＵＲＩＴＹビットは、オブジェクトのＳＡＣＬにアクセスする権利に対応する。

図２６のアクセス・マスク構造において、アイテム固有のアクセス権は、オブジェクト固有アクセス権セクション（下位１６ビット）に配置される。本発明の実施例において、ストレージ・プラットフォームは、セキュリティを管理するために、Ｗｉｎ３２およびストレージ・プラットフォームＡＰＩという２つのＡＰＩのセットを公開するので、ストレージプラットフォーム・オブジェクト固有アクセス権の設計を動機付けるためにファイル・システム・オブジェクト固有アクセス権を考慮する必要がある。

本発明のストレージ・プラットフォームのセキュリティ・モデルについては、先に本明細書に参照により組み込まれている関連出願において詳細に説明されている。この関連で、図２７（ａ、ｂ、およびｃ部分）は、セキュリティ・モデルの１つの実施例による、既存のセキュリティ領域から切り取られる、新しい、同様に保護されるセキュリティ領域を示している。

Ｆ．通知および変更追跡
本発明のもう１つの態様によれば、ストレージ・プラットフォームは、アプリケーションがデータ変更を追跡できる通知機能を提供する。この機能は主に、揮発性状態を維持するか、またはデータ変更イベントに関してビジネス・ロジックを実行するかするアプリケーションを対象としている。アプリケーションは、アイテム、アイテムＥｘｔｅｎｓｉｏｎおよびアイテム・リレーションシップに関する通知を登録する。通知は、データ変更が確定された後に非同期的に配信される。アプリケーションは、アイテム、Ｅｘｔｅｎｓｉｏｎおよびリレーションシップ・タイプ、さらにオペレーションのタイプによって通知をフィルタリングすることができる。

１つの実施例に拠れば、ストレージ・プラットフォームＡＰＩ３２２は、通知のための２種類のインターフェースを提供する。第１に、アプリケーションは、アイテム、アイテムＥｘｔｅｎｓｉｏｎおよびアイテム・リレーションシップに対する変更によりトリガされる単純データ変更イベントを登録する。第２に、アプリケーションは、アイテムのセット、アイテムＥｘｔｅｎｓｉｏｎおよびアイテムの間のリレーションシップを監視する「ウォッチャ」オブジェクトを作成する。ウォッチャ・オブジェクトの状態は、保存することができ、システム障害の後、または長期間にわたりシステムがオフラインになった後に再作成することができる。単一の通知は、複数の更新を反映することができる。

この機能に関する詳細については、先に参照により本明細書に組み込まれている関連出願において説明されている。

Ｇ．同期化
本発明のもう１つの態様によれば、ストレージ・プラットフォームは、同期化サービス３３０を提供し、これは、（ｉ）ストレージ・プラットフォームの複数のインスタンス（各々独自のデータ・ストア３０２を備える）が柔軟な規則のセットに従ってそのコンテンツの部分を同期化することができるようにし、（ｉｉ）本発明のストレージ・プラットフォームのデータ・ストアを、独自仕様のプロトコルを実装する他のデータ・ソースと同期させるサード・パーティのためのインフラストラクチャを提供する。

ストレージ・プラットフォーム間の同期化は、関与するレプリカのグループ間で発生する。たとえば、図３を参照すると、おそらくは別のコンピュータ・システム上で稼動するストレージ・プラットフォームのもう１つのインスタンスの制御のもとで、ストレージ・プラットフォーム３００のデータ・ストア３０２ともう１つのリモート・データストア３３８との間の同期化を提供することが望ましい場合がある。このグループの合計メンバーシップ数は必ずしも、所定の時間において所定のレプリカに認識されている必要はない。

異なるレプリカは、単独で（つまり並行して）変更を行うことができる。同期化のプロセスは、他のレプリカによって行われた変更をすべてのレプリカに認識させるように定義される。この同期化機能は、本質的にマルチ・マスタである。

本発明の同期化機能により、レプリカは以下のことを行うことができる。
・ もう１つのレプリカが認識する変更を判断する
・ このレプリカが認識しない変更に関する情報を要求する
・ 他のレプリカが認識しない変更に関する情報を伝達する
・ ２つの変更が相互に競合しているときを判断する
・ ローカルに変更を適用する
・ 集束を確実にするように他のレプリカに競合の解決を伝達する
・ 指定されている競合解決のポリシーに基づいて競合を解決する
１．ストレージ・プラットフォーム間の同期化
ストレージ・プラットフォームの同期化サービス３３０の主な用途は、ストレージ・プラットフォームの複数のインスタンスを（それぞれのデータ・ストアと）同期化することにある。同期化サービスは、（データベース・エンジン３１４の基礎をなすテーブルではなく）ストレージ・プラットフォーム・スキーマのレベルにおいて機能する。したがって、たとえば「Ｓｃｏｐｅｓ」は、以下で説明するように同期化セットを定義するために使用される。

同期化サービスは、「ｎｅｔ ｃｈａｎｇｅｓ」の原則に基づいて稼動する。同期化サービスでは、（トランザクションの複製の場合のように）個々のオペレーションを記録して送信するのではなく、これらのオペレーションの最終結果を送信して、複数のオペレーションの結果を単一の結果の変更に統合する。

同期化サービスは一般に、トランザクションの境界を考慮しない。つまり、単一トランザクションで一つのストレージ・プラットフォーム・データ・ストアに２つの変更が行われた場合、これらの変更が他のすべてのレプリカでアトミックに適用される保証はなく、一方が、他方なしで反映される可能性がある。この原則の例外は、同じトランザクション内で同じアイテムに２つの変更が行われた場合、これらの変更は他のレプリカにアトミックに送信されて適用されることが保証される点にある。従って、アイテムは、同期化サービスの整合性の単位である。

ａ）同期（Sync）制御アプリケーション
任意のアプリケーションを同期化サービスに接続し、同期化オペレーションを開始することができる。そのようなアプリケーションは、同期化を実行するために必要なパラメータをすべて提供する（以下の同期プロファイルを参照）。そのようなアプリケーションは、本明細書において同期制御アプリケーション（ＳＣＡ）と呼ぶ。

２つのプラットフォームインスタンスを同期化するとき、ＳＣＡによって同期化は一方の側で初期化される。そのＳＣＡは、リモート・パートナと同期化するようローカルの同期化サービスに通知する。もう一方の側では、同期化サービスが、発信元マシンからの同期化サービスによって送信されたメッセージにより起動される。これは、宛先マシンにある永続的構成情報（以下のマッピングを参照）に基づいて応答する。同期化サービスは、スケジュール通りに、またはイベントに応答して稼動することができる。そのような場合、スケジュールを実装する同期化サービスはＳＣＡになる。

同期化を可能にするには、２つの手順が取られる必要がある。第１に、スキーマ設計者が、ストレージ・プラットフォーム・スキーマに適切な同期化セマンティクスで（以下に説明するように変更単位を指定して）注釈を付ける必要がある。第２に、同期化は、（以下に説明するように）同期化に参与するストレージ・プラットフォームのインスタンスを持つすべてのマシンに関して適正に構成される必要がある。

ｂ）スキーマの注釈
同期化サービスの基本概念は、変更単位の基本概念である。変更単位は、ストレージ・プラットフォームによって個々に追跡されるスキーマの最小部分である。すべての変更単位について、同期化サービスはそれが変更されたか、または前回の同期化以来変更されていないかを決定することができる。

スキーマ内で変更単位を指定することは、いくつかの目的に適っている。第１に、これは同期化サービスが電線上でどの程度のやり取りをするかを決める。変更単位内部で変更が行われた場合、変更単位のどの部分が変更されたのか同期化サービスには分からないので、変更単位全体が他のレプリカに送信される。第２に、これは競合検出の細分性を決める。２つの同時変更（これらの用語は以下のセクションで詳細に定義される）が同じ変更単位に行われた場合、同期化サービスは競合を発生する。一方、同時変更が異なる変更単位に行われた場合、競合は発生せず、変更は自動的に統合される。第３に、これはシステムによって保持されるメタデータの量に大きな影響を及ぼす。同期化サービスのメタデータの多くは、変更単位ごとに保持される。したがって、変更単位を小さくすることで同期化のオーバーヘッドが増大する。

変更単位を定義するには、適正なトレードオフを見い出す必要がある。そうした理由から、同期化サービスではスキーマ設計者がこのプロセスに参加できるようになっている。

１つの実施例において、同期化サービスは、ある要素よりも大きい変更単位をサポートしない。ただし、同期化サービスは、スキーマ設計者がある要素よりも小さい変更単位を指定する能力、つまり、ある要素の複数の属性を別個の変更単位にグループ化する能力をサポートする。その実施例において、このことは、以下の構文を使用して行われる。

ｃ）同期の構成
ストレージ・プラットフォーム・パートナのグループで、彼らのデータの特定部分の同期をとりたいと望むグループは、同期コミュニティと呼ばれる。コミュニティのメンバは同期を保ちたいと考えているが、必ずしもまったく同じ方法でデータを表す必要はない。つまり、同期パートナは、同期化しようとしているデータを変換することができる。

ピア・ツー・ピアのシナリオにおいて、ピアがそのパートナすべてに対して変換マッピングを保持することは実際的ではない。その代わり、同期化サービスが「コミュニティ・フォルダ」を定義する方法をとる。コミュニティ・フォルダは、すべてのコミュニティ・メンバが同期化している仮想の「共有フォルダ」を表す抽象である。

この概念は、例示によって分かりやすく説明することができる。ジョーが数台のコンピュータにあるＭｙ Ｄｏｃｕｍｅｎｔｓフォルダの同期をとりたい場合、ジョーは、たとえばＪｏｅｓＤｏｃｕｍｅｎｔｓという名前のコミュニティ・フォルダを定義する。次に、ジョーは、すべてのコンピュータで、仮想のＪｏｅｓＤｏｃｕｍｅｎｔｓフォルダとローカルのＭｙ Ｄｏｃｕｍｅｎｔｓフォルダ間のマッピングを構成する。それ以降は、ジョーのコンピュータが相互に同期化するとき、ローカル・アイテムではなく、ＪｏｅｓＤｏｃｕｍｅｎｔｓのドキュメントに関してやりとりするようになる。このようにして、ジョーのすべてのコンピュータは、他のコンピュータが何であるか認識する必要もなく互いを理解しあい、コミュニティ・フォルダは同期コミュニティの共通言語となる。

同期化サービスの構成は、次の３つのステップから成り、（１）ローカル・フォルダおよびコミュニティ・フォルダ間のマッピングを定義するステップ、（２）何が同期化されるか（たとえば、何と同期するか、またどのサブセットを送信すべきか、またどれを受信したか）を決める同期プロファイルを定義するステップ、および（３）さまざまな同期プロファイルが稼動する、またはこれらを手動で実行するスケジュールを定義するステップである。

（１）コミュニティ・フォルダ−マッピング
コミュニティ・フォルダのマッピングは、個々のマシン上にＸＭＬ構成ファイルとして格納される。各マッピングは、以下のようなスキーマを備えている。
／ｍａｐｐｉｎｇｓ／ｃｏｍｍｕｎｉｔｙＦｏｌｄｅｒ
この要素は、このマッピングの対象となるコミュニティ・フォルダに名前を付ける。名前は、フォルダの構文規則に従う。
／ｍａｐｐｉｎｇｓ／ｌｏｃａｌＦｏｌｄｅｒ
この要素は、このマッピングが変換されるローカル・フォルダに名前を付ける。名前は、フォルダの構文規則に従う。フォルダは、マッピングが有効になるように常に存在する必要がある。このフォルダ内のアイテムは、このマッピングごとの同期化のために考慮される。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ
この要素は、コミュニティ・フォルダからローカル・フォルダ、およびその逆にアイテムを変換する方法を定義する。これが欠けているかまたは空の場合、変換は行われない。特に、これはＩＤがマップされないということである。この構成は主として、フォルダのキャッシュを作成する場合に有用である。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ／ｍａｐＩＤｓ
この要素は、コミュニティＩＤを再使用するのではなく、新しく生成されたローカルＩＤが、コミュニティ・フォルダからマップされたすべてのアイテムに割り当てられるよう要求する。同期ランタイムはＩＤマッピングを保持し、アイテムを前後に往復して変換する。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ／ｌｏｃａｌＲｏｏｔ
この要素は、コミュニティ・フォルダ内のすべてのルート・アイテムが指定されたルートの子にされるよう要求する。
／ｍａｐｐｉｎｇｓ／ｒｕｎＡｓ
この要素は、このマッピングに対する要求が処理される権限を制御する。ない場合には、送信者が想定される。
／ｍａｐｐｉｎｇｓ／ｒｕｎＡｓ／ｓｅｎｄｅｒ
この要素の存在は、このマッピングへのメッセージの送信者が偽名を使用しているはずなので、その結果、その証明書のもとに要求が処理される必要があることを示している。

（２）プロファイル
同期プロファイルは、同期化を開始するために必要なパラメータの全セットである。これは、ＳＣＡによって同期ランタイムに供給され、同期化を開始する。ストレージ・プラットフォーム間の同期化のための同期化プロパティは、以下の情報を含んでいる。
・ ローカル・フォルダ、変更の送信元および宛先としての役割を果たす。
・ 同期化するリモートフォルダ名 −− このフォルダは上記で定義されているマッピングの方法によりリモート・パートナからパブリッシュされる必要がある。
・ 方向−同期化サービスは、送信専用、受信専用、および送受信の同期をサポートする。
・ ローカル・フィルタ −− リモート・パートナに送信するローカル情報を選択する。ローカル・フォルダへのストレージ・プラットフォーム・クエリとして表される。
・ リモート・フィルタ −− リモート・パートナから取り出すリモート情報を選択する。− コミュニティ・フォルダへのストレージ・プラットフォーム・クエリとして表される。
・ 変換 −− アイテムとローカル・フォーマットとの間で変換する方法を定義する。
・ ローカル・セキュリティ −− リモート・エンドポイントから取り出された変更が、（impersonated：偽装された）リモート・エンドポイントの許可のもと、または同期化をローカルに開始したユーザの許可のもとに適用されるのかを指定する
・ 競合解決ポリシー −− 競合が拒否されるか、ログに記録されるか、または自動的に解決されるかを指定する − 後者の場合は、使用する競合リゾルバ、その構成パラメータを指定する。

同期化サービスは、同期プロファイルを簡単に構築できるようにするランタイムＣＬＲクラスを提供する。プロファイルはさらに、（多くの場合スケジュールと共に）容易に格納できるようにＸＭＬファイルにシリアル化し、およびそこからシリアル化することもできる。ただし、ストレージ・プラットフォームにはすべてのプロファイルが格納される標準的な場所はない。ＳＣＡでは、固執することなくその場でプロファイルを自由に構築できるようにしている。同期化を開始するためにローカル・マッピングを備える必要はないことに留意されたい。すべての同期化情報は、プロファイルに指定することができる。ただし、マッピングは、リモート側によって開始された同期化要求に応答するために必要になる。

（３）スケジュール
１つの実施例において、同期化サービスはその独自のスケジュール・インフラストラクチャを提供しない。その代わり、このタスクを実行する他のコンポーネントに依存している。それは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムに付属のＷｉｎｄｏｗｓ（登録商標）Ｓｃｈｅｄｕｌｅｒである。同期化サービスには、ＳＣＡとしての役割を果たし、ＸＭＬファイルに保存されている同期プロファイルに基づいて同期化をトリガする、コマンド・ライン・ユーティリティが含まれている。このユーティリティにより、Ｗｉｎｄｏｗｓ（登録商標）Ｓｃｈｅｄｕｌｅｒがスケジュールどおり、あるいはユーザのログオンまたはログオフなどのイベントに応じて同期化を実行するように構成することが非常に簡単になる。

ｄ）競合の処理
同期化サービスにおける競合処理は、次の３つの段階で構成される。（１）変更適用の時点で発生する競合検出−このステップでは変更が安全に適用できるかどうかを決定する、（２）自動競合解決およびログ記録−このステップ（競合が検出された直後に行われる）中に、競合を解決できるかどうか確認するために自動競合リゾルバが相談にあづかり−解決できない場合、競合はオプションでログに記録される、および（３）競合検査および解決 − このステップは、競合がログに記録されている場合に行われ、同期化セッションのコンテクストの外部で発生する−この時点で、ログに記録された競合は解決されてログから削除することができる。

（１）競合の検出
１つの実施例において、同期化サービスは、知識ベースおよび制約ベースという２つの種類の競合を検出する。

（ａ）知識ベース（knowledge-based）の競合
知識ベースの競合は、２つのレプリカが同じ変更単位に独立した変更を行った場合に発生する。２つの変更は、相互を認識（knowledge）することなく行われる場合、言い替えれば、第１のバージョンが第２のバージョンによって認識されていない場合、またはその逆の場合に、独立した変更と呼ばれる。同期化サービスは、前述のようにレプリカの認識（knowledge）に基づいてそのような競合をすべて自動的に検出する。

競合を変更単位のバージョン履歴におけるフォーク（分岐）と考えると参考になる場合もある。変更単位の寿命（life）内に競合が発生しない場合、そのバージョン履歴は単純なチェーンである。各変更は、それぞれ以前の（一つの）変更の後に発生する。知識ベースの競合の場合は、２つの変更が並行して発生し、チェーンが分割してバージョン・ツリーになる。

（ｂ）制約ベースの競合
独立した変更は、一緒に適用される場合、整合性の制約に違反する場合もある。たとえば、同じディレクトリに同じ名前を持つファイルを作成する２つのレプリカは、そのような競合が発生する原因となる可能性がある。

制約ベースの競合は、２つの独立した変更に伴って生ずる（知識ベースの競合と同様）が、同じ変更単位に影響を与えることはない。むしろ、これらは、間に制約が存在する場合にのみ、異なる変更単位に影響を与える。

同期化サービスは、変更適用の時点で制約違反を検出し、制約ベースの競合を自動的に提起する。制約ベースの競合を解決するには通常、制約に違反しないような方法で変更を修正するカスタム・コードが必要である。同期化サービスは、これを行うための汎用メカニズムを提供しない。

（２）競合の処理
競合が検出されると、同期化サービスは、（同期プロファイルの同期化イニシエータによって選択される）次の３つのうち１つの処置をとることができる。（１）変更を拒否し、これを送信側に戻す、（２）競合を競合ログに記録する、または（３）競合を自動的に解決する。

変更が拒否される場合、同期化サービスは、変更がレプリカに到達しなかったかのうように動作する。否定応答は、発信元に送り返される。この解決ポリシーは主に、競合をログ記録することが可能ではないヘッドレス・レプリカ（ファイル・サーバなど）では有用である。その代わり、そのようなレプリカは、他のレプリカが変更を拒否することによって競合を処理するように強要する。

同期イニシエータは、その同期プロファイルに競合解決を構成する。同期化サービスは、次の方法で、単一のプロファイルの複数の競合リゾルバの組み合わせをサポートしている。第１は、競合リゾルバのリストの１つが成功するまで、リストを次々と試験するよう指定すること。第２は、競合リゾルバを競合タイプと関連付けること、たとえば、更新−更新の知識ベースの競合を１つのリゾルバに振り向け、他のすべての競合はログに振り向ける。

（ａ）自動競合解決
同期化サービスは、いくつかのデフォルトの競合リゾルバを提供する。以下のものがあげられる。
・ｌｏｃａｌ−ｗｉｎｓ：ローカルに格納されているデータと競合している場合は着信変更を無視する
・ｒｅｍｏｔｅ−ｗｉｎｓ：着信変更と競合している場合はローカルデータを無視する
・ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ：変更のタイム・スタンプに基づいて変更単位ごとにｌｏｃａｌ−ｗｉｎｓまたはｒｅｍｏｔｅ−ｗｉｎｓのいずれかを選ぶ（一般に同期化サービスはクロック値に依存しないことに留意されたい。この競合リゾルバはその規則の唯一の例外である）
・Ｄｅｔｅｒｍｉｎｉｓｔｉｃ：すべてのレプリカで同じになるよう保証されるような（そうでなければ意味をなさない）方法で勝者を選ぶ − この同期化サービスの１つの実施例では、パートナＩＤの辞書式比較を使用してこの機能を実装する
さらに、ＩＳＶは独自の競合リゾルバを実装してインストールすることができる。カスタムの競合リゾルバは、構成パラメータを受け入れることになる。そのようなパラメータは、同期プロファイルの競合解決セクションでＳＣＡによって指定される必要がある。

競合リゾルバが競合を処理するとき、実行する必要のあるオペレーションのリストを（変更が競合することの変わりに）ランタイムに返す。次に、同期化サービスは、競合ハンドラが考慮したことを含めるようリモートの知識を適切に調整させて、これらのオペレーションを適用する。

解決を適用している間に別の競合が検出される可能性もある。そのような場合、新しい競合は、元の処理が再開する前に解決する必要がある。

競合をアイテムのバージョン履歴における分岐として考えると、競合解決は、２つの分岐を組み合わせて単一ポイントを形成する、結合と見なすことができる。したがって、競合解決はバージョン履歴をＤＡＧに変える。

（ｂ）競合のロギング
非常に特殊な種類の競合リゾルバは、ＣｏｎｆｌｉｃｔＬｏｇｇｅｒである。同期化サービスは、競合を、タイプＣｏｎｆｌｉｃｔＲｅｃｏｒｄのアイテムとしてログに記録する。これらの記録は、（アイテム自体が削除されていない限り）競合している元のアイテムに関連している。各競合レコードは、競合を引き起こした着信変更、競合の種類（更新−更新、更新−削除、削除−更新、挿入−挿入、または制約）、および着信変更のバージョンとそれを送信するレプリカの知識を含んでいる。ログに記録された競合は、以下に説明するように検査および解決に使用することができる。

（ｃ）競合の検査および解決
同期化サービスは、アプリケーションのＡＰＩを提供して、競合ログを調べ、その中の競合の解決を提案する。ＡＰＩにより、アプリケーションは、すべての競合、または所定のアイテムに関連する競合を列挙することができる。さらにこれにより、そのようなアプリケーションは、次のうちの１つの方法でログに記録された競合を解決することもできるようになる。（１）リモートの勝利 −− ログに記録された変更を受け入れ、競合するローカルの変更を上書きする、（２）ローカルの勝利 −− ログに記録された変更の競合部分を無視する、および（３）新しい変更を提案 −− アプリケーションが自身の判断で競合を解決するマージを提案する。アプリケーションによって競合が解決されると、同期化サービスはこれらをログから削除する。

（ｄ）レプリカの集束および競合解決の伝搬
複雑な同期化のシナリオにおいて、同じ競合が複数のレプリカで検出されることがある。これが発生した場合、次のようなことが起こる可能性がある。（１）競合は１つのレプリカ上で解決することができ、解決はもう一方のレプリカに送信される、（２）競合は両方のレプリカで自動的に解決される、または（３）競合は両方のレプリカで（競合検査ＡＰＩを通じて）手動で解決される。

集束を確実にするために、同期化サービスは競合解決を他のレプリカに転送する。競合を解決する変更がレプリカに到達すると、同期化サービスは、この更新によって解決されるログ内の競合レコードを自動的に見つけ出し、これらを除去する。その意味では、１つのレプリカにおける競合解決は他のすべてのレプリカを結合している。

同じ競合に対して異なる勝者が異なるレプリカによって選択された場合、同期化サービスは競合解決を結合する原則を適用して、２つの解決のうちの一方を選んで自動的に他方に勝つようにする。勝者は、常に同じ結果を生成するよう保証されている決定論的な方法で選ばれる（１つの実施例ではレプリカＩＤ辞書式比較を使用する）。

同じ競合に対して異なるレプリカによって異なる「新しい変更」が提案された場合、同期化サービスは、この新しい競合を特殊競合として処理し、ＣｏｎｆｌｉｃｔＬｏｇｇｅｒを使用してこれが他のレプリカに伝搬しないように防ぐ。そのような状況は一般に手動の競合解決で発生する。

２．非ストレージ・プラットフォーム・データ・ストアへの同期化
本発明のストレージ・プラットフォームのもう１つの態様によれば、ストレージ・プラットフォームはＩＳＶ向けアーキテクチャを提供して、ストレージ・プラットフォームがＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ＡＤ、Ｈｏｔｍａｉｌなどの既存のシステムに同期化することができる同期アダプタを実装する。同期アダプタは、以下に説明するように同期化サービスによって提供される多くのＳｙｎｃサービスからの恩恵を受ける。

その名前にもかかわらず、同期アダプタは、一部のストレージ・プラットフォーム・アーキテクチャにプラグインとして実装される必要はない。必要に応じて、「同期アダプタ」は単に、変更列挙などのサービスおよびアプリケーションを取得するために同期化サービス・ランタイム・インターフェースを利用するアプリケーションであってもよい。

他の人々がもっと簡単に同期化を所定のバックエンドに構成して同期化を実行できるようにするため、同期アダプタの作成者は、前述のように同期プロファイルを与えられて同期を実行する、標準同期アダプタ・インターフェースを公開するよう推奨される。このプロファイルは、アダプタに構成情報を提供し、その一部をアダプタは同期ランタイムに渡し、ランタイム・サービスを制御する（たとえば同期化するフォルダなど）。

ａ）Ｓｙｎｃサービス（Sync Service）
同期化サービスは、いくつかのＳｙｎｃサービスをアダプタ作成者に提供する。これ以降このセクションでは、ストレージ・プラットフォームが同期化を行っているマシンを「クライアント」と呼び、アダプタが通信する非ストレージ・プラットフォーム・バックエンドを「サーバ」と呼ぶことが好都合である。

（１）変更の列挙（Change Enumeration）
同期化サービスによって保持される変更追跡データに基づいて、変更列挙は、このパートナが試行した前回の同期化以来データ・ストア・フォルダに発生した変更を同期アダプタが容易に列挙できるようにする。

変更は、「アンカー」の概念に基づいて列挙される。これは前回の同期化に関する情報を表す不透明な構造である。アンカーは、先のセクションで説明されているように、ストレージ・プラットフォーム知識の形態をとる。変更列挙サービスを利用する同期アダプタは、「格納されたアンカー」を使用するものと、「供給されたアンカー」を使用するものという、２つの広義のカテゴリに分類される。

この区別は、前回の同期についての情報がクライアント上に格納されるの、またはサーバ上に格納されるのかを基にしている。多くの場合、アダプタがこの情報をクライアントに格納するほうが容易であり、バックエンドはこの情報を都合よく格納することができない場合が多い。一方、複数のクライアントが同じバックエンドに同期化する場合、この情報をクライアントに格納することは非効率的であり、場合によっては正しくなく、これは１つのクライアントが、既にサーバまで他のクライアントが押し上げた変更に気づかなくしてしまう場合がある。アダプタがサーバに格納されたアンカーを使用する場合は、アダプタは変更列挙の時点でこれをストレージ・プラットフォームに戻して供給する必要がある。

ストレージ・プラットフォームが（ローカルまたはリモート・ストレージの）アンカーを保持するためには、ストレージ・プラットフォームはサーバで正常に適用された変更を認識している必要がある。これら、且つこれらのみの変更が、アンカーに含むことができる。変更の列挙中、同期アダプタは、どの変更が正常に適用されたかをレポートするために肯定応答インターフェースを使用する。同期化の終わりに、供給されたアンカーを使用しているアダプタは（すべての正常に適用された変更を取り込む）新しいアンカーを読み取り、これをそのバックエンドに送信する必要がある。

多くの場合、アダプタは、ストレージ・プラットフォームに挿入するアイテムと共にアダプタ固有のデータを格納する必要がある。そのようなデータの一般的な例には、リモートＩＤおよびリモート・バージョン（タイム・スタンプ）がある。同期化サービスは、このデータを格納するメカニズムを提供し、変更列挙は、この特別なデータを返された変更と共に受け取るメカニズムを提供する。これにより、ほとんどの場合、アダプタがデータベースに再度クエリを行う必要がなくなる。

（２）変更適用（Change Application）
変更適用は、同期アダプタが、そのバックエンドから受け取った変更をローカル・ストレージ・プラットフォームに適用することを可能にする。アダプタは、ストレージ・プラットフォーム・スキーマに変更を変換することが期待される。図２４は、ストレージ・プラットフォーム・スキーマからストレージ・プラットフォームＡＰＩクラスが生成されるプロセスを示す図である。

変更適用（Change Application）の主な機能は、自動的に競合を検出することである。ストレージ・プラットフォーム間の同期の場合のように、競合は、２つの重複する変更が相互を認識することなく行われるものとして定義される。アダプタは変更適用を使用するとき、競合検出が実行されたアンカーを指定する必要がある。変更適用は、アダプタの知識にカバーされていない重複するローカルの変更が検出された場合に、競合を提起する。変更列挙と同様に、アダプタは格納されたアンカーまたは供給されたアンカーを使用することができる。変更適用は、アダプタ固有のメタデータの効率的な格納をサポートする。そのようなデータは、アダプタによって適用される変更に接続することができ、同期化サービスによって格納することもできる。このデータは、次の変更列挙で戻されることになる。

（３）競合の解決
前述の競合解決メカニズム（ロギングおよび自動解決のオプション）は、同期アダプタでも使用することができる。同期アダプタは、変更を適用するときに競合解決のポリシーを指定することができる。指定した場合、競合は指定された競合ハンドラに渡されて（可能であれば）解決される。競合はログに記録することもできる。アダプタが、ローカルの変更をバックエンドに適用しようとしたときに、競合を検出する可能性もある。そのような場合、アダプタは、さらに、その競合を同期ランタイムに渡して、ポリシーに従って解決されるようにすることができる。さらに、同期アダプタは、同期化サービスによって検出された競合を処理のために、送り戻すように要求することもできる。これは、バックエンドが競合を格納または解決できるような場合に、特に便利である。

ｂ）アダプタの実装
一部の「アダプタ」は、単に、ランタイム・インターフェースを使用するアプリケーションであるが、アダプタは標準アダプタ・インターフェースを実装するよう推奨される。これらのインターフェースにより、同期制御アプリケーションは、アダプタが所定の同期プロファイルに従って同期化を実行するよう要求すること、実行中の同期化を取り消すこと、実行中の同期化に関する進行状況レポート（完了したパーセント）を受け取ること、が可能になる。

３．セキュリティ
同期化サービスは、ストレージ・プラットフォームによって実装されるセキュリティ・モデルに持ち込むものを、できるだけ少なくしようと努める。同期のための新しい権限を定義するのではなく、既存の権限が使用される。具体的には、次のようになっている。
・ データ・ストア・アイテムを読み取りできる者は誰でもそのアイテムへの変更を列挙することができる。
・ データ・ストア・アイテムに書き込みできる者は誰でもそのアイテムへの変更を適用することができる。
・ データ・ストア・アイテムを拡張できる者は誰でも同期メタデータをそのアイテムに関連付けることができる。

同期化サービスは、セキュリティ保護された作成者情報（secure authorship information）を保持しない。ユーザＵによって変更がレプリカＡに行われ、レプリカＢに転送された場合、最初にＡ（またはＵによって）変更が行われたという事実は失われる。Ｂがこの変更をレプリカＣに転送する場合、これはＡの権限ではなく、Ｂの権限のもとで行われる。このことは、レプリカがアイテムに独自の変更を行うことを任されていない場合、これは他のレプリカによって行われた変更を転送することができないという制約をもたらす。

同期化サービスが開始されると、これは同期制御アプリケーションによって行われる。同期化サービスは、ＳＣＡのＩＤを偽装し、そのＩＤのもとですべてのオペレーションを（ローカルならびにリモートに）実行する。たとえば、ユーザＵは、ユーザＵが読み取りアクセス権を持たないアイテムのリモート・ストレージ・プラットフォームから変更を取り出すことをローカルの同期化サービスにさせることはできないことに注目されたい。

４．管理容易性（Manageability）
レプリカについての分散コミュニティを監視することは、複雑な問題である。同期化サービスは、「スイープ」アルゴリズムを使用して、レプリカの状態に関する情報を収集して配信することができる。スイープ・アルゴリズムのプロパティは、すべての構成済みのレプリカに関する情報が最終的には収集されること、および失敗した（非応答）レプリカが検出されることを、確実にする。

このコミュニティ全体の監視情報は、すべてのレプリカで使用できるようになっている。監視ツールは、任意に選択されたレプリカで実行し、この監視情報を検査して管理上の意思決定を行うことができる。構成の変更は、影響を受けるレプリカで直接行う必要がある。

Ｈ．従来型ファイル・システムの相互運用性
前述のように、本発明のストレージ・プラットフォームは、少なくとも一部の実施例において、コンピュータ・システムのハードウェア／ソフトウェア・インターフェース・システムの不可欠部分として組み入れられることを目的としている。たとえば、本発明のストレージ・プラットフォームは、オペレーティング・システムのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ファミリなど、オペレーティング・システムの不可欠部分として組み入れることもできる。その能力において、ストレージ・プラットフォームＡＰＩは、アプリケーション・プログラムがそれを通してオペレーティング・システムと対話するオペレーティング・システムＡＰＩの一部となる。したがって、ストレージ・プラットフォームは、それを通してアプリケーション・プログラムがオペレーティング・システムに情報を格納する手段となり、そのためストレージ・プラットフォームのアイテム・ベースのデータ・モデルはそのようなオペレーティング・システムの従来型ファイル・システムに取って代わるものになる。たとえば、オペレーティングのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ファミリに組み入れられると、ストレージ・プラットフォームは、そのオペレーティング・システムに実装されているＮＴＦＳファイル・システムに取って代わることもできる。現在、アプリケーション・プログラムは、オペレーティング・システムのＷｉｎｄｏｗｓ（登録商標）ファミリによって公開されているＷｉｎ３２ ＡＰＩを通じてＮＴＦＳファイル・システムのサービスにアクセスしている。

しかし、本発明のストレージ・プラットフォームがＮＴＦＳファイル・システムに完全に取って代わるには、既存のＷｉｎ３２ベースのアプリケーション・プログラムの再コード化が必要になることになり、そのような再コード化は望ましくない場合もあることを認識すると、本発明のストレージ・プラットフォームがＮＴＦＳなどの既存のファイル・システムとの何らかの相互運用性を提供することは有益であると考えられる。したがって、本発明の１つの実施例において、このストレージ・プラットフォームは、Ｗｉｎ３２プログラミング・モデルに依存するアプリケーション・プログラムがこのストレージ・プラットフォームのデータ・ストアおよび従来型ＮＴＦＳファイル・システムの両方のコンテンツにアクセスできるようにする。この目的のために、このストレージ・プラットフォームでは、Ｗｉｎ３２命名規則のスーパーセットである命名規則を使用して相互運用を容易にする。さらに、このストレージ・プラットフォームは、Ｗｉｎ３２ ＡＰＩを通じてストレージ・プラットフォーム・ボリューム内に格納されているファイルおよびディレクトリへのアクセスをサポートする。

この機能性に関する詳細については、先に参照により本明細書に組み込まれている関連出願において説明されている。

Ｉ．ストレージ・プラットフォームＡＰＩ
ストレージ・プラットフォームは、アプリケーションが前述のストレージ・プラットフォームの特徴および機能にアクセスして、データ・ストアに格納されているアイテムにアクセスできるようにするＡＰＩを備えている。このセクションでは、本発明によるストレージ・プラットフォームのストレージ・プラットフォームＡＰＩの１つの実施例について説明する。この機能性に関する詳細については、先に参照により本明細書に組み込まれている関連出願において説明されているが、以下に便宜のためその情報の一部をまとめておく。

図１８を参照すると、包含フォルダは他のアイテムへの保持リレーションシップを収容するアイテムであり、ファイル・システム・フォルダの一般的な概念に相当するものである。各アイテムは、少なくとも１つの包含フォルダ内に「含まれて」いる。

図１９は、本発明の実施例によるストレージ・プラットフォームＡＰＩの基本アーキテクチャを示している。ストレージ・プラットフォームＡＰＩは、ＳＱＬクライアント１９００を使用してローカル・データ・ストア３０２と通信し、さらにＳＱＬクライアント１９００を使用してリモート・データ・ストア（たとえばデータ・ストア３４０）と通信することもできる。ローカル・ストア３０２は、ＤＱＰ（分散クエリ・プロセッサ）を使用するかまたは前述のストレージ・プラットフォーム同期化サービス（「Ｓｙｎｃ」）を通じてリモート・データストア３４０とも通信することができる。ストレージ・プラットフォームＡＰＩ３２２は、データ・ストア通知のためのブリッジＡＰＩとしての役割も果たして、前述のように、アプリケーションのサブスクリプションを通知エンジン３３２に渡し、ルーティング通知をアプリケーション（たとえばアプリケーション３５０ａ、３５０ｂ、３５０ｃ）に渡す。１つの実施例において、ストレージ・プラットフォームＡＰＩ３２２は、Ｍｉｃｒｏｓｏｆｔ ＥｘｃｈａｎｇｅおよびＡＤ内のデータにアクセスできるように限定「プロバイダ」アーキテクチャを定義することもできる。

図２０は、ストレージ・プラットフォームＡＰＩのさまざまなコンポーネントを概略的に表している。ストレージ・プラットフォームＡＰＩは、以下のコンポーネントを備えている。（１）ストレージ・プラットフォーム要素およびアイテム・タイプを表すデータ・クラス２００２、（２）オブジェクト永続性を管理してクラス２００６にサポートを提供するランタイム・フレームワーク２００４、および（３）ストレージ・プラットフォーム・スキーマからＣＬＲクラスを生成するために使用されるツール２００８。

所定のスキーマにより生じるクラスの階層は、そのスキーマ内のタイプの階層に直接反映する。一例として、図２１Ａおよび図２１Ｂに示すような連絡先スキーマで定義されているアイテム・タイプを考察する。

図２２は、オペレーションにおけるランタイム・フレームワークを示している。ランタイム・フレームワークは、以下のように機能する。
１．アプリケーション３５０ａ、３５０ｂ、または３５０ｃは、ストレージ・プラットフォーム内のアイテムにバインドする。
２．フレームワーク２００４は、バインドされるアイテムに対応するＩｔｅｍＣｏｎｔｅｘｔオブジェクト２２０２を作成して、それをアプリケーションに返す。
３．アプリケーションはこのＩｔｅｍＣｏｎｔｅｘｔにＦｉｎｄをサブミットしてアイテムのコレクションを取得する。返されたコレクションは概念上は（リレーションシップにより）オブジェクト・グラフ２２０４である。
４．アプリケーションは、データを変更、削除、および挿入する。
５．アプリケーションは、Ｕｐｄａｔｅ（）メソッドを呼び出すことにより変更を保存する。

図２３は、「ＦｉｎｄＡｌｌ」オペレーションの実行を示している。

図２４は、ストレージ・プラットフォーム・スキーマからストレージ・プラットフォームＡＰＩクラスが生成されるプロセスを示している。

図２５は、ファイルＡＰＩが基にするスキーマを示す図である。ストレージ・プラットフォームＡＰＩは、ファイル・オブジェクトを処理するネーム・スペースを備えている。このネーム・スペースは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓと呼ばれる。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓのクラスのデータ・メンバは、ストレージ・プラットフォーム・ストアに格納されている情報に直接反映する。この情報は、ファイル・システム・オブジェクトから「プロモート」されるか、またはＷｉｎ３２ ＡＰＩを使用してネイティブに作成される。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓには、ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍという２つのクラスがある。これらのクラスおよびそのメソッドのメンバは、図２５のスキーマ図を見ることによって容易に予測することができる。ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍは、ストレージ・プラットフォームＡＰＩから読み取り専用である。これらを変更するためには、Ｗｉｎ３２ ＡＰＩまたはＳｙｓｔｅｍ．ＩＯのクラスを使用する必要がある。

ＡＰＩに関して、プログラミング・インターフェース（あるいは単にインターフェース）は、コードの１つまたは複数のセグメントがコードの１つまたは複数の他のセグメントによって提供される機能と通信またはアクセスできるようにする任意のメカニズム、プロセス、プロトコルと考えることができる。あるいは、プログラミング・インターフェースは、他のコンポーネントの１つまたは複数のメカニズム、メソッド、関数呼び出し、モジュールなどに通信の接続が可能なシステムのコンポーネントの１つまたは複数のメカニズム、メソッド、関数呼び出し、モジュール、オブジェクトなどとして考えることができる。前の文章において「コードのセグメント」という用語は、１つまたは複数の命令またはコードの行（lines）を含むことを意図しており、適用される用語、コード・セグメントが別個にコンパイルされるかどうか、あるいはコード・セグメントがソース、中間、またはオブジェクトコードとして提供されるかどうか、コード・セグメントがランタイム・システムまたはプロセスで使用されるかどうか、これらが同じまたは異なるマシンに位置するかまたは複数のマシンにわたり分散されるか、あるいはコードのセグメントによって現される機能性が全体としてソフトウェアに、全体としてハードウェアに、またはハードウェアとソフトウェアの組み合わせに実装されるかどうかにかかわりなく、たとえばコード・モジュール、オブジェクト、サブルーチン、関数などを含んでいる。

概念的には、プログラミング・インターフェースは、図３０Ａまたは図３０Ｂに示すように一般的に表すことができる。図３０Ａでは、インターフェースＩｎｔｅｒｆａｃｅ１を、第１のコード・セグメントおよび第２のコード・セグメントとの間の通信で使用するコンジットとして示している。図３０Ｂでは、システムの第１および第２のコード・セグメントが媒体Ｍを介して通信できるようにするインターフェース・オブジェクトＩ１およびＩ２（これらは、第１および第２のコードの一部であっても一部でなくてもよい）を備えるインターフェースを示している。図３０Ｂの視点として、インターフェース・オブジェクトＩ１およびＩ２を同じシステムの別個のインターフェースと見なすこともでき、またはオブジェクトＩ１およびＩ２と媒体Ｍがインターフェースを構成していると見なすこともできる。図３０Ａおよび３０Ｂは、双方向フローおよびそのフローの両側のインターフェースを示しているが、特定の実施態様では、単方向の情報フロー（または以下に説明するように情報フローなし）しか持つことができない、または一方の側にインターフェース・オブジェクトを持つことしかできない。一例として、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、エントリポイント、メソッド、関数、サブルーチン、リモート・プロシージャ呼び出し、およびコンポーネント・オブジェクト・モデル（ＣＯＭ）インターフェースは、プログラミング・インターフェースの定義の範囲内に包含されるが、これらに限定されることはない。

そのようなプログラミング・インターフェースの態様は、第１のコード・セグメントが情報（ここで「情報」は、その最も広い意味で使用され、データ、コマンド、要求などを含んでいる）を第２のコード・セグメントに伝送する方法、第２のコード・セグメントが情報を受け取る方法、および情報の構造、シーケンス、構文、編成、スキーマ、タイミング、コンテンツを含むことができる。この点において、情報がインターフェースによって定義された方法でトランスポートされる限り、媒体が有線または無線あるいは両方の組み合わせであっても、基礎を成すトランスポート媒体自体はインターフェースのオペレーションにとって重要ではない。特定の状況において、情報の転送が他のメカニズム（たとえば、コード・セグメント間の情報フローから分離したバッファ、ファイルなどに置かれた情報）を介するかまたは存在しない場合もあり、１つのコード・セグメントが単に第２のコード・セグメントによって実行される機能にアクセスする場合のように、情報が従来の意味では単方向または双方向に渡されないこともある。それらの任意の態様またはすべての態様は、たとえばコード・セグメントが疎結合または密結合の構成のシステムの一部であるかどうかに応じてなど、所定の状況において重要となる場合がある。そのため、このリストは例示的なものであって、限定的ではないと考えるべきである。

このプログラミング・インターフェースの概念は、当業者には周知であり、本発明の前述の詳細な説明から明瞭である。ただし、プログラミング・インターフェースを実装する他の方法もあり、明示的に除外されていない限り、これらも本明細書の特許請求の範囲に含まれるものとする。そのような他の方法は、単純化した図３０Ａおよび図３０Ｂに比べて精巧または複雑なものに見えることもあるが、これらはそれでもなお同様の機能を実行して同じ全体的な結果を達成する。ここでプログラミング・インターフェースの例示的な代替実施態様について簡単に説明する。

ファクタリング（Factoring；要素への分解）：１つのコード・セグメントからもう１つのコード・セグメントへの通信は、通信を複数の別個の通信に分割することにより間接的に達成できる。このことについては、図３１Ａおよび図３１Ｂに概略が示されている。図示されているように、一部のインターフェースは機能の分割可能なセットの観点から説明することができる。したがって、図３０Ａおよび図３０Ｂのインターフェース機能は、ちょうど数学的に、２４を、あるいは２×２×３×２を提供するように、同じ結果を達成するために要素に分解することができる。その結果、図３１Ａに示すように、インターフェース１によって提供される機能が分割されて、インターフェースの通信をインターフェース１Ａ、インターフェース１Ｂ、インターフェース１Ｃなどの複数のインターフェースに変換され、しかも同じ結果を達成することができる。図３１Ｂに示すように、インターフェースＩ１によって提供される機能は、インターフェースＩ１ａ、インターフェースＩ１ｂ、インターフェースＩ１ｃなどの複数のインターフェースに分割され、しかも同じ結果を達成することができる。同様に、第１のコード・セグメントから情報を受け取る第２のコード・セグメントのインターフェースＩ２は、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどにファクタリングすることができる。ファクタリングするとき、第１のコード・セグメントに含まれるインターフェースの数は、第２のコード・セグメントに含まれるインターフェースの数と一致する必要はない。図３１Ａおよび図３１Ｂのいずれの場合でも、インターフェースＩおよびＩ１の機能上の意図は、それぞれ図３０Ａおよび図３０Ｂの場合と同じ状態のままである。インターフェースのファクタリングはさらに、連想（associative）、可換（commutative）、その他の数学的プロパティにも従うことができ、それによって、そのファクタリングをわかりにくくすることができる。たとえば、オペレーションの順序付けは重要ではないこともあり、その場合、インターフェースによって実行される関数は、インターフェースに到達する相当前に実行したり、他のコードまたはインターフェースによって実行したり、またはシステムの別のコンポーネントによって実行したりすることができる。さらに、プログラミングの技術分野の当業者であれば、同じ結果を達成する異なる関数呼び出しを行うさまざまな方法があることを理解できよう。

再定義（Redefinition）：場合によっては、意図した結果を達成しながらも、プログラミング・インターフェースの特定の態様（たとえばパラメータ）を無視、追加、または再定義することが可能である。これは、図３２Ａおよび図３２Ｂに示されている。たとえば、図３０Ａのインターフェース１が、３つのパラメータｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎおよびｏｕｔｐｕｔを含む呼び出しである、関数呼び出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、ｏｕｔｐｕｔ）を含んでおり、これが第１のコード・セグメントから第２のコード・セグメントに発行されると想定する。中央のパラメータｐｒｅｃｉｓｉｏｎが、図３２Ａに示すように所定のシナリオにおいて無用の場合、これを単に無視したり、または意味のない（この状況において）パラメータに置き換えられることもできる。さらに、関係のない追加パラメータを加えることもできる。いずれの場合にも、ｉｎｐｕｔが第２のコード・セグメントによって二乗された後にｏｕｔｐｕｔが返される限り、Ｓｑｕａｒｅの機能は達成することができる。ｐｒｅｃｉｓｉｏｎは、コンピューティング・システムの一部の下流や他の部分にとって十分に意味のあるパラメータである。しかし、ｐｒｅｃｉｓｉｏｎが二乗を計算する狭義の目的には必要ないと認識されると、これは置き換えられるかまたは無視される可能性がある。たとえば、有効なｐｒｅｃｉｓｉｏｎ値を渡す代わりに、誕生日などの意味のない値を結果に悪影響を及ぼすことなく渡すこともできる。同様に、図３２Ｂに示すように、インターフェースＩ１はインターフェースＩ１’に置き換えられ、パラメータを無視するかまたはインターフェースにパラメータを追加するように再定義される。インターフェースＩ２は、インターフェースＩ２’と同様に再定義され、不必要なパラメータまたは他の場所で処理されるパラメータを無視するように再定義される。ここで重要なことは、場合によってはプログラミング・インターフェースが、一部の目的には必要のないパラメータなどの態様（aspect）を含むこともでき、そのためこれらは無視したり、再定義したり、または他の目的のために他の場所で処理したりすることができるということである。

インライン・コーディング：２つの別個のコード・モジュールの機能の一部または全体を、それらの間の「インターフェース」形状を変えるように、マージすることも実現可能である。たとえば、図３０Ａおよび図３０Ｂの機能は、それぞれ図３３Ａおよび図３３Ｂの機能に変換することができる。図３３Ａにおいて、図３０Ａの以前の第１および第２のコード・セグメントは、その両方を含む１つのモジュールにマージされる。この場合、コード・セグメントは引き続き相互に通信しているが、インターフェースは単一モジュールにより適した形態に適合することができる。したがって、たとえば、正式なＣａｌｌおよびＲｅｔｕｒｎステートメントはもはや必要なくなるが、インターフェース１に準じた同様の処理または応答は引き続き有効である場合がある。同様に、図３３Ｂに示されているように、図３０ＢからのインターフェースＩ２の一部または全体がインターフェースＩ１にインラインで書き込まれてインターフェースＩ１”を形成することができる。図に示すように、インターフェースＩ２はＩ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａはインターフェースＩ１によりインラインでコーディングされてインターフェースＩ１”を形成する。具体的な例として、図３０ＢのインターフェースＩ１が、関数呼び出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｏｕｔｐｕｔ）を実行し、これがインターフェースＩ２によって受け取られ、第２のコード・セグメントによって（二乗すべき）ｉｎｐｕｔで渡された値の処理した後に、二乗の結果がｏｕｔｐｕｔとして戻されるとする。そのような場合には、第２のコード・セグメントによって実行される処理（ｉｎｐｕｔを二乗する）は、インターフェースへの呼び出しを行わずに第１のコード・セグメントによって実行することができる。

ディボース（Divorce：分離）：１つのコード・セグメントからもう１つのコード・セグメントへの通信は、通信を複数の別個の通信に分割（breaking）することにより間接的に達成できる。このことについては、図３４Ａおよび図３４Ｂに概略が示されている。図３４Ａに示すように、第１のインターフェースであるインターフェース１上の通信を異なるインターフェース（この場合はインターフェース２Ａ、インターフェース２Ｂおよびインターフェース２Ｃ）に適合するように変換するために、１つまたは複数のミドルウェア（分離インターフェース、機能および／またはインターフェース機能を元のインターフェースから分離するので）が提供される。こうしたことを行うのは、たとえば、インターフェース１プロトコルに従ってオペレーティング・システムと通信するように設計されているアプリケーションのインストールされたベースがある場合であり、しかし、この場合、オペレーティング・システムは異なるインターフェース（この場合はインターフェース２Ａ、インターフェース２Ｂおよびインターフェース２Ｃ）を使用するように変更される。このポイントは、第２のコード・セグメントで使用されていた元のインターフェースがもはや、第１のコード・セグメントによって使用されるインターフェースとの互換性を保たなくなり、そこで、以前のインターフェースと新しいインターフェースの互換をとるように仲介物が使用される。同様に、図３４Ｂに示すように、第３のコード・セグメントを導入して、インターフェースＩ１からの通信を分離インターフェースＤＩ１で受け取り、分離インターフェースＤＩ２からインターフェース機能を、たとえば、ＤＩ２と動作するように再設計されたインターフェースＩ２ａおよびＩ２ｂに送信して、機能的に同じ結果を得ることができる。同様に、ＤＩ１およびＤＩ２は連携して、図３０ＢのインターフェースＩ１およびＩ２の機能を新しいオペレーティング・システム向けに変換し、しかも同じまたは同等の機能的結果を提供することができる。

再書き込み（Rewriting）：さらにもう１つの可能な変形は、コードを動的に再書き込みして、インターフェース機能を同じ全体的結果を達成する他のものと置き換えることである。たとえば、中間言語（Ｍｉｃｒｏｓｏｆｔ ＩＬ、Ｊａｖａ（登録商標）ＢｙｔｅＣｏｄｅなど）で提示されたコード・セグメントが実行環境（Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様のランタイムタイプの環境によって提供される実行環境）においてＪｕｓｔ−Ｉｎ−Ｔｉｍｅ（ＪＩＴ）コンパイラまたはインタープリタに提供されるシステムもある。ＪＩＴコンパイラは、第１のコード・セグメントから第２のコード・セグメントへの通信を動的に変換するように、すなわち、これらを第２のコード・セグメント（元のまたは異なる第２のコード・セグメントのいずれでも）に要求される可能性のある異なるインターフェースに適合させるように、再書き込みされる。これは、図３５Ａおよび図３５Ｂに示されている。図３５Ａに示すように、この手法は、前述のディボースのシナリオと類似している。これは、たとえば、複数のアプリケーションがインストールされたベースが、インターフェース１プロトコルに従ってオペレーティング・システムと通信するように設計されている場合であり、そのためにオペレーティング・システムが異なるインターフェースを使用するように変更される場合に行われる。ＪＩＴコンパイラは、インストール・ベースのアプリケーションからの通信をオペレーティング・システムの新しいインターフェースに、直ちに（on the fly）に準拠させるために使用することができる。図３５Ｂに示すように、インターフェースを動的に再書き込みするこの手法は、インターフェースの動的なファクタリングや改変に適用することができる。

代替実施例を介して同じまたは類似したインターフェースとして結果を達成する前述のシナリオは、著くれるおよび／または並列式にさまざまな方法で組み合わせることも、あるいは他の介在コードと組み合わせることもできることに留意されたい。したがって、上記で提示されている代替実施例は相互に排他的なものではなく、図３０Ａおよび図３０Ｂに提示されている汎用のシナリオと同じまたは同様のシナリオを生成するために、混在させ、整合させ、よび結合させることも可能である。さらに、多くのプログラミング構成体の場合と同様に、本明細書において説明されていないが、それでもなお本発明の精神および範囲によって表される、同じまたは同等のインターフェースの機能を達成する同様の方法が他にもあることにも留意されたい。すなわち、それは少なくとも部分的に、インターフェースの価値の基礎をなすインターフェースによって表される機能、およびそれによって実現される有利な結果であることに留意されたい。

ＩＩＩ．イメージ・スキーマおよび従属スキーマ（イメージ・スキーマ・セット）
本明細書に開示する本発明のさまざまな実施例において、イメージ（たとえばＪＰＥＧ、ＴＩＦＦ、ビットマップなど）はコア・プラットフォーム・オブジェクト（「イメージ・アイテム」あるいは簡単に「イメージ」）として処理され、本発明は、システムにおけるイメージの拡張可能な表現、つまりイメージの特性、およびどのようにイメージがシステムにおける他のアイテムに関連しているか、を提供する「イメージ・スキーマ」を備えている。このために、イメージ・スキーマは、システムにおけるイメージのプロパティ、振る舞い、およびリレーションシップを定義し、さらにスキーマは、たとえばデータ固有のイメージが何を含むべきか、データ固有のイメージがオプションで何を含むべきか、固有のイメージがどのように拡張できるかなど、イメージに関する規則も強制する。イメージ・スキーマは、イメージの意味内容を表すプロパティだけでなく、イメージを表すためのファイル・フォーマットのプロパティ（ＧＩＦ、ＴＩＦＦ、ＪＰＥＧその他周知のイメージ・オブジェクト・タイプなど）を含む、さまざまな種類のイメージを表すために必要なタイプ情報を含んでいる。本発明のさまざまな実施例のイメージ・スキーマは、すべてのイメージ関連の機能性が構築される基盤である。

イメージ・スキーマに加えて、「フォト」、「分析プロパティ」、「場所（location）」アイテムの関連従属スキーマも本明細書において提供されて説明されており（全体で「イメージ・スキーマ・セット」）、本発明の特定の実施例は１つまたは複数のこれらの従属スキーマを備えている。フォト・スキーマは、写真オブジェクト（「フォト・アイテム」または簡単に「フォト」）の拡張可能表現であり、ここでフォト・アイテム・タイプはイメージ・アイテム・タイプのサブタイプである。分析プロパティ・スキーマ（ＡＰスキーマ）は、自動顔認識、イメージ類似など写真用の高機能比較機能を実現するフォト・アイテムの分析プロパティ（ＡＰ）の拡張可能表現である。場所（location）スキーマは、フォト・アイテムの物理的（地理的）場所プロパティの拡張可能表現である。

図３６Ａおよび図３６Ｂは、本発明のさまざまな実施例のイメージ・スキーマ（アイテムおよびプロパティ）を、（図７の）基本スキーマおよび（図８Ａおよび図８Ｂの）コア・スキーマの選択された要素と共に示して、各スキーマ間の相互リレーションシップを示している。（便宜上、個々のプロパティは図では省略してある。）

Ａ．イメージ・スキーマ
前述のように、イメージ・スキーマは、さまざまな種類のイメージ・アイテムを表すために必要なアイテム、プロパティ、およびリレーションシップを含んでいる。これは、特定のイメージ・タイプ（ＧＩＦ、ＴＩＦＦ、ＪＰＥＧなど）を表すネイティブのファイル・フォーマットのプロパティの他にイメージの意味内容を表すプロパティを含んでいる。このために、任意のイメージ・アイテムに対して、Ｉｍａｇｅ Ｔｙｐｅは、すべてのイメージによって共有される基本アイテム・タイプであり、図３６に示すようにＣｏｒｅ．Ｄｏｃｕｍｅｎｔアイテム・タイプ（つまり「コア」スキーマの「ドキュメント」タイプ）から分かれた直接の拡張である。（Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔタイプは、図８Ａに示されるコア・スキーマの一部にすることもできる。）イメージ・タイプは、一般的なイメージを記述し、フォーマットにはかかわりなくすべてのイメージに適用可能なフィールドを含んでいる。イメージ・スキーマの主要なアイテム・タイプはイメージ・タイプであり、以下にイメージ・タイプの一部のフィールドを示す。

イメージ・スキーマはさらに、以下のようなＢａｓｅ．ＰｒｏｐｅｒｔｙＢａｓｅから拡張する追加のプロパティ（ネスト化要素）も備えている。 ・ 「Ｒｅｇｉｏｎ」：Ｒｅｇｉｏｎプロパティは、イメージ内の領域を表し、以下のフィールドを備えている。

・ 「ＲｅｇｉｏｎＯｆＩｎｔｅｒｅｓｔ」：このプロパティは、イメージ内の特定の注目の情報を表し、以下のフィールドを備えている。

さらに、イメージ・スキーマは、以下に示すように、図３６Ａに示すイメージ・アイテムおよび他のアイテムとの間の一連のリレーションシップを備えることもできる。 ・ 「ＰｅｒｓｏｎＲｅｆｅｒｅｎｃｅ」：イメージは、連絡先またはプリンシパル・アイテム（図８ＡのＣｏｒｅ．Ｐｒｉｎｃｉｐａｌ）への１つまたは複数のＰｅｒｓｏｎＲｅｆｅｒｅｎｃｅリンクを持ち、特定のフォト内の人物を示すことができ、以下のフィールドを備えている。

・ 「ＥｖｅｎｔＲｅｆｅｒｅｎｃｅ」：イメージはさらに、イベント・アイテム（図８ＡのＣｏｒｅ．Ｅｖｅｎｔ）へのＥｖｅｎｔＲｅｆｅｒｅｎｃｅリンクを持って特定のフォトのイベントを示すこともでき、以下のフィールドを備えている。

・ 「ＬｏｃａｔｉｏｎＲｅｆｅｒｅｎｃｅ」：イメージはさらに、場所アイテム（図８ＡのＣｏｒｅ．Ｌｏｃａｔｉｏｎ）へのＬｏｃａｔｉｏｎＲｅｆｅｒｅｎｃｅリンクを持って特定のフォトの場所（location）を示すこともでき、以下のフィールドを備えている。

Ｂ．フォト・スキーマ
イメージ・スキーマの従属スキーマであるフォト・スキーマは、実際に何らかの写真であるイメージに適用される。任意のフォト・アイテムに対して、フォト・タイプはイメージ・フォーマットに関わりなくフォトを記述するプロパティのセットを表し、フォト・タイプは図３６に示すようにＩｍａｇｅ．Ｉｍａｇｅタイプ（つまり「イメージ」スキーマ内の「イメージ」タイプ）を拡張する。以下にフォト・タイプの一部のフィールドを示す。

Ｃ．分析プロパティ・スキーマ
デジタル写真の場合、プロパティのセットは分析アプリケーションによってその写真に関して算出することができる。ただし、これらのプロパティは、算出に高くつき、時間およびプロセッサ・リソースの観点から再計算される。さらに、これらのフィールドはアプリケーションに固有であり、他のアプリケーションはこれらのフィールドの内部フォーマットを理解することができない。

フォト・アイテムの場合、その代わりに分析プロパティの標準セットが使用前にこれらのアプリケーションによって計算され、フォト・アイテム・タイプの拡張の形式でフォト・アイテムに追加される。分析プロパティ・スキーマ（ＡＰスキーマ）は、図７に示すように、自身が基本スキーマのＢａｓｅ．Ｅｘｔｅｎｓｉｏｎ拡張タイプの拡張であるＡＰ拡張のＡＰタイプを提供することによってこれを行っている。ＡＰタイプ拡張は、次のフィールドを備えている。

ＩＶ．結論
以上説明してきたように、本発明は、データを編成、検索、共有するためのストレージ・プラットフォームを目的としている。本発明のストレージ・プラットフォームは、既存のファイル・システムおよびデータベース・システムを超えてデータ・ストレージの概念を拡張して広げ、リレーショナル（表）データ、ＸＭＬ、およびアイテムと呼ばれる新しいデータの形態など、構造化、非構造化、または半構造化データを含むあらゆるタイプのデータの記憶装置（data store）となるように設計される。本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業のさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なアプリケーション・インターフェースを提供し、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れて、拡張している。その広範な発明の概念から逸脱することなく前述の実施例には変更を加えることができることが理解されよう。したがって、本発明は、開示される特定の実施例に限定されることはないが、添付の特許請求の範囲によって定義されている発明の精神および範囲の中のすべての変更を網羅することを意図している。

以上の説明から明らかなように、本発明のさまざまなシステム、方法、および態様の全体または部分は、プログラム・コード（つまり命令）の形態で組み入れることができる。このプログラム・コードは、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ，磁気テープ、フラッシュ・メモリ、ハードディスク・ドライブ、または他の機械可読ストレージ媒体を含む、磁気、電気、または光ストレージ媒体などのコンピュータ可読媒体上に格納することができ、プログラム・コードが、コンピュータまたはサーバなどのマシンによってロードされ実行されるときに、マシンは本発明を実施するための装置となることを特徴としている。本発明はさらに、電気配線またはケーブリング経由、光ファイバ経由、インターネットまたはイントラネットを含むネットワーク経由、あるいは他の伝送形態経由など、一部の伝送媒体上を伝送されるプログラム・コードの形態で組み入れることもでき、プログラム・コードがコンピュータなどのマシンによってロードされ実行されるときに、マシンは本発明を実施するための装置となることを特徴としている。汎用プロセッサ上で実装される場合、プログラム・コードはプロセッサと結合して、特定の論理回路に同じように機能する一意の装置を提供する。
［以下余白］

本発明の態様を組み込むことができるコンピュータ・システムを示すブロック図である。 ハードウェア・コンポーネント、ハードウェア／ソフトウェア・インターフェース・システム・コンポーネント、およびアプリケーション・プログラム・コンポーネントという、３つのコンポーネント・グループに分割されるコンピュータ・システムを示すブロック図である。 ファイル・ベースのオペレーティング・システムのディレクトリにあるフォルダにグループ化されたファイルの従来型ツリー・ベースの階層構造を表す図である。 ストレージ・プラットフォームを示すブロック図である。 アイテム、アイテム・フォルダ、およびカテゴリの間の構造的リレーションシップを示す図である。 アイテムの構造を示すブロック図である。 図５Ａのアイテムの複合プロパティ・タイプを示すブロック図である。 複合タイプがさらに記述される（明示的に一覧される）「場所」アイテムを示すブロック図である。 基本スキーマで見い出されたアイテムのサブタイプとしてアイテムを示すブロック図である。 継承されたタイプが（その直接のプロパティに加えて）明示的に一覧される図６Ａのサブタイプ・アイテムを示すブロック図である。 ＩｔｅｍおよびＰｒｏｐｅｒｔｙＢａｓｅという２つの最上位のクラス・タイプ、およびそこから派生した追加の基本スキーマ・タイプを含む基本スキーマを示すブロック図である。 コア・スキーマのアイテムを示すブロック図である。 コア・スキーマのプロパティ・タイプを示すブロック図である。 アイテム・フォルダ、そのメンバ・アイテム、およびアイテム・フォルダとそのメンバ・アイテムとの相互接続リレーションシップを示すブロック図である。 カテゴリ（この場合もアイテム自体）、そのメンバ・アイテム、およびカテゴリとそのメンバ・アイテムとの相互接続リレーションシップを示すブロック図である。 ストレージ・プラットフォームのデータ・モデルの参照タイプの階層を示す図である。 リレーションシップが分類される方法を示す図である。 通知メカニズムを示す図である。 ２つのトランザクションが共に新しいレコードを同じＢツリーに挿入する例を示す図である。 データ変更検出プロセスを示す図である。 例示的なディレクトリ・ツリーを示す図である。 ディレクトリ・ベースのファイル・システムの既存フォルダがストレージ・プラットフォームのデータ・ストアに移動される例を示す図である。 包含フォルダの概念を示す図である。 ストレージ・プラットフォームＡＰＩの基本アーキテクチャを示す図である。 ストレージ・プラットフォームＡＰＩスタックのさまざまなコンポーネントを表す概略図である。 例示的な連絡先アイテム・スキーマを表す概略図である。 図２１Ａの例示的な連絡先アイテム・スキーマの要素を表す概略図である。 ストレージ・プラットフォームＡＰＩのランタイム・フレームワークを示す図である。 「ＦｉｎｄＡｌｌ」オペレーションの実行を示す図である。 ストレージ・プラットフォーム・スキーマからストレージ・プラットフォームＡＰＩクラスが生成されるプロセスを示す図である。 ファイルＡＰＩが基にするスキーマを示す図である。 データ・セキュリティの目的で使用されるアクセス・マスク・フォーマットを示す図である。 （ａ、ｂ、およびｃ部分）既存のセキュリティ領域から切り取られる新しい同様に保護されるセキュリティ領域を示す図である。 アイテム検索ビューの概念を示す図である。 例示的なアイテム階層を示す図である。 第１および第２のコード・セグメントが通信するコンジットとしてのインターフェース１を示す図である。 システムの第１および第２のコード・セグメントが媒体Ｍを介して通信できるようにするインターフェース・オブジェクトＩ１およびＩ２を備えるインターフェースを示す図である。 インターフェース１によって提供される機能が再分割されて、インターフェースの通信をインターフェース１Ａ、インターフェース１Ｂ、インターフェース１Ｃという複数のインターフェースに変換する方法を示す図である。 インターフェースＩ１によって提供される機能が複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃに再分割される方法を示す図である。 無意味なパラメータ精度が無視されるか、または任意のパラメータに置き換えられるシナリオを示す図である。 インターフェースが、無視するように定義されている代替インターフェースに置き換えられるか、またはインターフェースにパラメータを追加するシナリオを示す図である。 第１および第２のコード・セグメントが、その両方を含むモジュールにマージされるシナリオを示す図である。 インターフェースの一部または全体が別のインターフェースにインラインで書き込まれて組み合わせインターフェースを形成するシナリオを示す図である。 ミドルウェアの１つまたは複数の部分が、１つまたは複数の異なるインターフェースに適合するように第１のインターフェース上の通信を変換する方法を示す図である。 １つのインターフェースからの通信を受け取るが、第２および第３のインターフェースに機能を伝送するようにコード・セグメントをインターフェースで導入できる方法を示す図である。 Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅ（ＪＩＴ）コンパイラが１つのコード・セグメントからもう１つのコード・セグメントに通信を変換する方法を示す図である。 １つまたは複数のインターフェースを動的に再書き込みするＪＩＴ方式が動的に属性分配に適用されるか、あるいは前記インターフェースを変更する方法を示す図である。 イメージ・スキーマを（図７の）基本スキーマおよび（図８Ａの）コア・スキーマの選択された要素と共に示して、各スキーマ内のさまざまなアイテムの相互リレーションシップを示す図である。 イメージ・スキーマを（図７の）基本スキーマおよび（図８Ａの）コア・スキーマの選択された要素と共に示して、各スキーマ内のさまざまなアイテムの相互リレーションシップを示す図である。

Claims (12)

1. 記憶デバイスに記憶された複数のイメージデータを処理するためのシステムであって、前記複数のイメージデータは、イメージに関連する個々の情報単位を含み、該システムは、
   前記複数のイメージデータに基づき、少なくとも１つのイメージ・アイテムおよび少なくとも１つのイメージ・プロパティを定義するための手段と、
   アイテムを、前記イメージ・アイテムが全てそこから派生する基礎アイテム・タイプを構成する基礎アイテムとして確立するための手段と、
   前記基礎アイテムによって定義される写真のデジタル・イメージ・アイテムと前記写真のデジタル・イメージ・アイテムの領域において表された少なくとも１人の人物に関連するアイテムとの間のリンクを確立するための手段と、
   を備え、
   前記基礎アイテム・タイプは、前記写真のデジタル・イメージ・アイテムの中の１つにおける注目の領域の属性を含む属性を定義し、前記注目の領域の属性は、前記写真のデジタル・イメージ・アイテムの中の１つの、第１の領域内で、少なくとも１人の人物を確認するフィールドと、前記写真のデジタル・イメージ・アイテムの中の１つの、第２の領域内で、少なくとも１つの注目の領域を確認する第２のフィールドとを含むことを特徴とするシステム。
2. 前記基礎アイテム・タイプは、フォトが撮影された日付、フォトが取得された日付、前記フォトの獲得セッションの一意の識別、オリエンテーション、場所、イベント、カメラのメーカー、カメラの型式、露光時間、絞り、ＩＳＯスピード、前記フォトにフラッシュが使用されたかどうかの指示、前記フォトに赤目モードが使用されたかどうかの指示、露光モード、および前記フォトの被写体の距離、の属性グループの中からの少なくとも１つの属性を更に備えることを特徴とする請求項１に記載のシステム。
3. 前記注目の領域の属性は、前記注目の領域の左、上部、右および下部の座標のフィールドを備えていることを特徴とする請求項１に記載のシステム。
4. 前記写真のデジタル・イメージ・アイテムの中の１つの、前記注目の領域の属性は、信頼性のフィールドをさらに備えることを特徴とする請求項１に記載のシステム。
5. 前記写真のデジタル・イメージ・アイテムの中の１つの少なくとも１つの分析プロパティ（ＡＰ）を定義する分析プロパティ・スキーマ手段を備えることを特徴とする請求項１に記載のシステム。
6. 前記少なくとも１つの分析プロパティ（ＡＰ）は、カラー・ヒストグラム、グレー・ヒストグラム、および類似のインデックス、のプロパティ・グループの中からの少なくとも１つを備えることを特徴とする請求項５に記載のシステム。
7. 写真のデジタル・イメージ・アイテムが撮影された地理的場所を表すために、前記写真のデジタル・イメージ・アイテムと前記地理的場所に対応する場所アイテムとの間のリンクを確立し、前記写真のデジタル・イメージ・アイテムは前記場所アイテムに基づいてクエリされることが可能になることを特徴とする請求項１に記載のシステム。
8. 前記写真のデジタル・イメージ・アイテムが撮影された地理的場所を表すために、前記地理的場所に対応する前記リンクに場所プロパティを設定することを特徴とする請求項７に記載のシステム。
9. 前記写真のデジタル・イメージ・アイテム内に表された少なくとも１つのイベントを表すために、前記写真のデジタル・イメージ・アイテムと前記イベントに関連するアイテムとの間のリンクを確立し、前記前記写真のデジタル・イメージ・アイテムは、前記イベントに関連するアイテムに基づいてクエリされることが可能になることを特徴とする請求項１に記載のシステム。
10. 第１のデジタル・イメージ・アイテムから、（ａ）前記第１のデジタル・イメージ・アイテムが派生した親デジタル・イメージ・アイテムまたは（ｂ）前記第１のデジタル・イメージ・アイテムから派生した子デジタル・イメージ・アイテムのいずれかである第２のデジタル・イメージ・アイテムへのリンクを確立することを特徴とする請求項１に記載のシステム。
11. コンピュータを請求項１〜１０の何れか１項に記載されたシステムの手段として機能させるための１つ又は複数のプログラム。
12. コンピュータを請求項１〜１０の何れか１項に記載されたシステムの手段として機能させるための１つは複数のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images