JP4580390B2 - ハードウェア／ソフトウェアインターフェイスシステムによって管理可能な情報単位の拡張および継承のためのシステムおよび方法 - Google Patents

Description

本発明は概して、情報の記憶および取得の分野に関し、より詳細には、コンピュータシステムにおいて異なる型のデータを組織化し、検索し、共有するアクティブストレージプラットフォームに関する。本発明の様々な実施形態は、データを管理するためにハードウェア／ソフトウェアインターフェイスシステムによって使用される拡張および継承方法の使用を対象とする。

本出願は、その内容が参照により本明細書に組み込まれている、２００３年１０月２４日に出願した米国特許出願第１０／６９３，５７４号（整理番号ＭＳＦＴ２８４７）「SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」、２００３年８月２１日に出願した米国特許出願第１０／６４６,５８０号（整理番号ＭＳＦＴ２７３５）「SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM」、および２００３年８月２１日に出願した国際出願ＰＣＴ／ＵＳ０３／２６１４４号（整理番号ＭＳＦＴ２７７９）「SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM」の優先権を主張する。

本出願は、その内容全体が参照により本出願に組み込まれている（かつ、その一部が便宜上、本明細書において要約される）、本発明の譲受人に譲渡された、２００３年８月２１日に出願した米国特許出願第１０／６４７，０５８号（整理番号ＭＳＦＴ１７４８）「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 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 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 THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」、２００３年１０月２４日に出願した米国特許出願第１０／６９２，５１５号（整理番号ＭＳＦＴ２８４４）「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」の出願において開示される発明に対象が関連する。

個々のディスク容量は、過去１０年間にわたって、毎年約７０％増えている。ムーアの法則は、長年にわたって起こった、中央処理装置（ＣＰＵ）能力の驚異的な進歩を正確に予測した。有線および無線技術により、驚異的な接続性および帯域幅がもたらされた。現在の傾向が続くと仮定すると、数年のうちに、平均的なラップトップコンピュータは、約１テラバイト（ＴＢ）の記憶を有するとともに数百万のファイルを収容するようになり、５００ギガバイト（ＧＢ）のドライブが一般的なものになるであろう。

消費者は、扱う情報が、従来の個人情報マネージャ（ＰＩＭ）スタイルデータであっても、デジタル音楽や写真などのメディアであっても、主に通信および個人情報の編集のためにコンピュータを使う。デジタルコンテンツの量、および未加工のバイトを格納する能力は大幅に上昇したが、消費者が利用することができる、データを組織化し統一する方法は遅れをとった。知識労働者は、情報の管理および共有に膨大な時間を費やし、一部の調査では、知識労働者が、そのうち１５〜２５％の時間を、非生産的な情報関連活動に費やすと推定している。他の調査では、一般的な知識労働者が、情報の検索に１日当たり約２．５時間を費やすと推定している。

開発者および情報技術（ＩＴ）部門は、人々、場所、時間、およびイベントのようなものを表す、共通の記憶抽象化のための独自データストアの構築に、多大な時間および費用を投資する。その結果、作業の重複が起こるだけでなく、共通データを検索し、または共有するための共通機構をもたない、共通データからなるアイランドが作成されることにもなる。今日、どれほど多くのアドレス帳が、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを実行しているコンピュータ上に存在し得るかを考慮されたい。ｅメールクライアントおよび個人向け金融プログラムなど、多くのアプリケーションが、別個のアドレス帳を保持しているが、このような各プログラムが個々に維持するアドレス帳データのアプリケーションの間では、ほとんど共有が行われない。その結果、（マイクロソフトマネーのような）金融プログラムは、払受人のアドレスを、ｅメールの連絡先フォルダ（Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋにあるようなフォルダ）に維持されているアドレスと共有しない。実際、多くのユーザが、複数のデバイスをもっており、複数のデバイスおよびセル電話を含む非常に様々な追加ソースに渡る自分の個人データを、ＭＳＮおよびＡＯＬなどの商用サービスに論理的に同期させるべきである。それにも関わらず、ドキュメントの共有という共同作業は主に、ｅメールメッセージにドキュメントを添付することによって、つまり、手作業により非効率的に遂行される。

共同作業が欠如している理由の１つは、コンピュータシステムにおいて情報を組織化する従来の手法が、ファイルを格納するのに使われる記憶媒体の物理的組織化の抽象化に基づいて、複数のファイルを、フォルダからなるディレクトリ階層に組織化するために、ファイル、フォルダ、およびディレクトリベースのシステム（「ファイルシステム」）の使用に重点をおいていたことである。１９６０年代に開発されたＭｕｌｔｉｃｓオペレーティングシステムは、記憶可能なデータ単位をオペレーティングシステムのレベルで管理するのに、ファイル、フォルダ、およびディレクトリを他に先駆けて使うことによって信頼を得ることができた。具体的には、Ｍｕｌｔｉｃｓは、ファイルの物理アドレスがユーザ（アプリケーションおよびエンドユーザ）に透過でないファイル階層において、記号アドレスを使った（そうすることによって、ファイルパスという考え方を導入した）。このファイルシステムは、個々のどのファイルのファイル形式にも全く無関心であり、ファイルの間の関係は、オペレーティングシステムレベル（つまり、階層中のファイルの場所以外）では重要でないとみなされた。Ｍｕｌｔｉｃｓの登場以来、記憶可能なデータは、オペレーティングシステムのレベルで、ファイル、フォルダ、およびディレクトリに組織化された。こうしたファイルは概して、ファイルシステムによって維持される特別なファイルの形で実現されるファイル階層そのもの（「ディレクトリ」）を含む。このディレクトリは、ディレクトリ中の他のファイルすべてに対応するエントリのリストと、階層中のこのようなファイルのノードの場所（本明細書において、フォルダと呼ばれる）とを維持する。当該分野は、約４０年間、このような状況であった。

しかし、コンピュータの物理的記憶システム内に常駐する情報を表現する妥当な方法がもたらされたにも関わらず、ファイルシステムは、その物理的記憶システムを抽象化したものであり、したがって、ファイルの使用には、ユーザが操作するもの（コンテキスト、特徴、および他の単位との関係を有する単位）と、オペレーティングシステムが提供するもの（ファイル、フォルダ、およびディレクトリ）との間に、ある程度の間接化（翻訳）が必要である。その結果、ユーザ（アプリケーションおよび／またはエンドユーザ）は、そうすることが非効率的であり、矛盾し、あるいは望ましくない場合であっても、情報単位を強制的にファイルシステム構造にするしか選択の余地がない。さらに、既存のファイルシステムは、個々のファイルに格納されるデータ構造についての知識をほとんどもたないので、情報のほとんどが、ファイルを書いたアプリケーションにのみアクセス可能（かつ理解可能）であるファイル中にロックされたままとなる。その結果、情報の概略記述、および情報の管理機構がこのように欠如していることにより、データからなるサイロが作成され、個々のサイロの間でデータの共有がほとんど行われないことになる。たとえば、ファイルの組織化はこうしたＰＣユーザに対して大きな挑戦課題を提示するので、多くのパーソナルコンピュータ（ＰＣ）ユーザは、対話する相手についての情報をある程度含む別個のストア、たとえば、Ｏｕｔｌｏｏｋ Ｃｏｎｔａｃｔｓ、オンラインアカウント受信人、Ｗｉｎｄｏｗｓ（登録商標）アドレス帳、Ｑｕｉｃｋｅｎ Ｐａｙｅｅｓ、およびインスタントメッセージ（ＩＭ）の友人リストを、５個よりも多くもっている。ほとんどの既存ファイルシステムは、ファイルおよびフォルダを組織化するネストされたフォルダメタファを使用するので、ファイル数が増加すると、柔軟かつ効率的な組織化方式を維持するのに必要な作業は、非常に面倒なものになる。このような状況において、１個のファイルを多様に分類することが非常に有用であろう。しかし、既存のファイルシステムにおいてハードまたはソフトリンクを使うことはわずらわしく、維持するのが難しい。

ファイルシステムのこうした欠点に対処する試みが過去に何度か行われたが、成功には至っていない。こうした以前の試みのいくつかは、物理アドレスではなく内容によってデータにアクセスする機構を提供するために、連想記憶の使用を伴った。しかし、連想記憶は、キャッシュおよびメモリ管理単位など、デバイスによる小規模な使用には有用であったが、物理記憶媒体などのデバイスへの大規模な使用は様々な理由により依然として不可能なので、こうした努力は失敗に終わり、したがってこのようなソリューションは全く存在しない。オブジェクト指向データベース（ＯＯＤＢ）システムを使用する他の試みも行われたが、こうした試みは、強力なデータベース特性および優れた非ファイル表現を特徴としたが、ファイル表現の扱いには有効でなく、ファイルおよびフォルダに基づく階層構造の速度、効率、および平易性を、ハードウェア／ソフトウェアインターフェイスシステムレベルで再現することができなかった。他の努力、たとえばＳｍａｌｌＴａｌｋ（および他の派生物）の使用を試みたものも、ファイルおよび非ファイル表現の扱いには非常に効果的であったが、様々なデータファイルの間に存在する関係を効率的に組織化し使用するのに必要なデータベース特徴が欠けていたので、このようなシステム全体としての効率は、許容し得るものではなかった。ＢｅＯＳを使用するさらに他の試み（および他のこのようなオペレーティングシステムの研究）も、いくつかの必要なデータベース特徴を提供するとともにファイルを適切に表すことができるのにもかかわらず、従来のファイルシステムと同じ核心的欠点として、非ファイル表現の扱いに適さなかった。

データベース技術は、同様の挑戦課題が存在する、当該分野のもう１つの領域である。たとえば、リレーショナルデータベースモデルは商業的に非常に成功したが、実際には、独立ソフトウェアベンダ（ＩＳＶ）は概して、リレーショナルデータベースソフトウェア製品（Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバなど）において利用可能な機能のわずか一部を発揮したに過ぎない。むしろ、このような製品とのアプリケーションの対話のほとんどは、単純な「ｇｅｔ」および「ｐｕｔ」の形である。これにはいくつかの明白な理由、たとえばプラットフォームまたはデータベースにとらわれないということがあるが、気づかれないことが多い重大な理由の１つは、データベースは、主要なビジネスアプリケーションベンダが本当に必要とする正確な抽象化を必ずしも実現しないということである。たとえば、現実世界は、「顧客」や「注文」など、「アイテム」という概念を（それ自体がアイテムである、注文の埋込み「ラインアイテム」とともに）もつが、リレーショナルデータベースは、テーブルおよび行「アイテム」という概念でのみ対話する。その結果、アプリケーションは、アイテムレベルでの一貫性、ロック、セキュリティ、および／またはトリガという側面（いくつか例を挙げると）をもつことを望み得るが、概して、データベースは、こうした特徴をテーブル／行レベルでのみ提供する。これは、各アイテムが、データベース中で何らかのテーブルの１つの行にマップされる場合はうまく作用し得るが、複数のラインアイテムを有する注文の場合、アイテムが実際に複数のテーブルにマップされる理由が存在し、この場合、単純なリレーショナルデータベースシステムは、正しい抽象化をもたらすわけではない。その結果、アプリケーションは、こうした基本的な抽象化を提供するために、データベースの上に論理を構築しなければならない。言い換えると、基本的なリレーショナルモデルは、より高度なアプリケーションをその上に容易に開発することができる、データの格納に十分なプラットフォームを提供しない。というのは、基本的なリレーショナルモデルは、アプリケーションと記憶システムの間のある程度の間接化を必要とし、この場合、データの意味構造は、特定の例において、アプリケーション中でのみ可視的となり得るからである。一部のデータベースベンダは、その製品に、たとえばオブジェクトリレーショナル性能、新しい構成モデルを提供するなど、より高度な機能を構築しているが、どのベンダも、必要とされている種類の包括的なソリューションを提供しておらず、真に包括的なソリューションとは、有用なデータモデルの抽象化（たとえば「アイテム」、「拡張」、「関係」など）と、そのための有用なドメインの抽象化（たとえば「人」、「場所」、「イベント」など）との両方を提供するものである。

上述した、既存のデータ記憶およびデータベース技術に不足しているものを鑑みて、コンピュータシステムにおいてあらゆる型のデータを組織化し、検索し、共有するように能力を向上させる新しいストレージプラットフォーム、すなわち既存のファイルシステムおよびデータベースシステムを上回るようにデータプラットフォームを拡張し拡大し、あらゆる型のデータ用のストアとなるように設計されたストレージプラットフォームが必要である。本発明は、上記参照によって本明細書に組み込まれている関連発明とともに、この要求を満たす。具体的には、本発明は、ハードウェア／ソフトウェアインターフェイスシステムによって操作されるオブジェクトの拡張および継承方法を提供する。

以下の要約では、参照によって本明細書に組み込まれている関連発明（「関連発明」）と関連して述べる、本発明の様々な態様の概要を提供する。この要約は、本発明の重要な態様すべての包括的な記述を提供することも、本発明の範囲を定義することも意図していない。そうではなく、この要約は、詳細な説明およびそれに続く図面の序文として働くことを意図している。

本発明、ならびに関連発明は合わせて、データを組織化し、検索し、共有するストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、既存のファイルシステムおよびデータベースシステムを上回るようにデータプラットフォームを拡張し拡大し、構造化、非構造化、または半構造化データを含むあらゆるタイプのデータ用のストアとなるように設計される。

本発明のストレージプラットフォームは、データベースエンジン上に実装されるデータストアを備える。データベースエンジンは、オブジェクトリレーショナル拡張を有するリレーショナルデータベースエンジンを備える。データストアは、データの組織化、検索、共有、同期、およびセキュリティをサポートするデータモデルを実装する。具体的なデータ型は、スキーマ中に記述され、プラットフォームは、新しいデータ型を定義するようにスキーマの組を拡張する機構を提供する（本質的に、基本型のサブ型は、スキーマによって提供する）。同期性能が、ユーザまたはシステムの間のデータ共有を円滑に進める。既存のファイルシステムとのデータストアの相互運用を可能にするが、このような従来のファイルシステムを制限しないファイルシステムのような性能が提供される。変更追跡機構が、データストアに対する変更の追跡を可能にする。ストレージプラットフォームは、アプリケーションが、ストレージプラットフォームの上記の性能すべてを利用するとともにスキーマに記述されているデータにアクセスすることを可能にする１組のアプリケーションプログラムインターフェイスをさらに備える。

データストアによって実装されるデータモデルは、アイテム、要素、および関係に関してデータ記憶単位を定義する。アイテムとは、データストアに格納可能なデータの単位であり、１つまたは複数の要素および関係を含み得る。要素とは、１つまたは複数のフィールド（本明細書において、プロパティとも呼ばれる）を含む型のインスタンスである。関係とは、２つのアイテムの間のリンクである。（本明細書で使用する、こうしたおよび他の具体的な用語は、その近くで使われる他の用語と分けるために大文字で表される場合がある。ただし、大文字で表される用語、たとえば「Ｉｔｅｍ（「アイテム」）」と、大文字でない同じ用語、たとえば「ｉｔｅｍ（アイテム）」とを区別する意図は全くなく、このような区別は、推測されるべきでも含意されるべきでもない）。

コンピュータシステムは、ハードウェア／ソフトウェアインターフェイスシステムによって扱うことができる別個の格納可能な情報単位を各アイテムが構成する複数のアイテムと、前記「アイテム」の組織的構造を構成する複数の「アイテムフォルダ」と、複数の「アイテム」を扱うハードウェア／ソフトウェアインターフェイスシステムとをさらに備え、各「アイテム」は、少なくとも１つの「アイテムフォルダ」に属し、複数のアイテムフォルダにも属し得る。

「アイテム」またはその「アイテム」のプロパティ値の一部は、永続ストアからの派生とは反対に、動的に計算することができる。言い換えると、ハードウェア／ソフトウェアインターフェイスシステムは、「アイテム」が格納されることを要求せず、ストレージプラットフォームの、現在の「アイテム」の組を列挙する能力や、「アイテム」の識別子を与えられるとその「アイテム」を取得する能力（アプリケーションプログラミングインターフェイス、すなわちＡＰＩついて述べるセクションでより詳しく説明する）など、特定の動作がサポートされる。たとえば、「アイテム」は、セル電話の現在の場所や温度センサー上で読み取られる温度でもよい。ハードウェア／ソフトウェアインターフェイスシステムは、複数の「アイテム」を扱うことができ、ハードウェア／ソフトウェアインターフェイスシステムによって管理される複数の「関係」によって相互接続された「アイテム」をさらに備え得る。

コンピュータシステム用のハードウェア／ソフトウェアインターフェイスシステムは、前記ハードウェア／ソフトウェアインターフェイスシステムが理解し、所定の予測可能な方法で直接処理することができる１組のコア「アイテム」を定義するためのコアスキーマをさらに備える。複数の「アイテム」を扱うために、コンピュータシステムは、前記「アイテム」を複数の「関係」に相互接続させ、前記「関係」をハードウェア／ソフトウェアインターフェイスシステムレベルで管理する。

ストレージプラットフォームのＡＰＩは、ストレージプラットフォームスキーマのセットの中で定義される各アイテム、アイテムの拡張、および関係用のデータクラスを提供する。さらに、アプリケーションプログラミングインターフェイスは、データクラスに共通の１組のビヘイビア（ｂｅｈａｖｉｏｒ）を定義し、かつデータクラスとともに、ストレージプラットフォームＡＰＩ用の基本的なプログラミングモデルを提供する１組のフレームワーククラスを提供する。ストレージプラットフォームＡＰＩは、アプリケーションプログラマを基底データベースエンジンの照会言語の詳細に関与させないようなやり方で、データストア中のアイテムの様々なプロパティに基づいてアプリケーションプログラマがクエリを形成することを可能にする、簡略化したクエリモデルを提供する。ストレージプラットフォームＡＰＩはまた、アプリケーションプログラムによって行われたアイテムに対する変更を収集し、次いで、こうした変更を、データストアが実装されるデータベースエンジンによって（またはどの種類の記憶エンジンによっても）要求される正しい更新情報に組織化する。その結果、アプリケーションプログラマは、メモリ中のアイテムに変更を加えることができるようになり、データストアアップデートの複雑さは、ＡＰＩに委ねられる。

共通の記憶基盤およびデータの体系化により、本発明のストレージプラットフォームは、消費者、知識労働者、および企業に対して、より効率的なアプリケーション開発を可能にする。本発明のストレージプラットフォームは、データモデル中で継承される性能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法も包含し拡張する、豊富かつ拡張可能なアプリケーションプログラミングインターフェイスを提供する。

相互関連発明のこの包括的構造（実施形態のセクションＩＩで詳しく説明する）を鑑みて、本発明は、「アイテム」および「プロパティ」型の機能を拡張するための「拡張」の使用、ならびに関連アイテムの間での効率的な検索および組織化を円滑にするための「継承」の使用（実施形態のセクションＩＩＩで詳しく説明する）を特に対象とする。本発明の他の特徴および利点が、本発明の以下の詳細な説明および添付の図面から明らかになるであろう。

添付の図面と併せ読むことによって、上述の要約、ならびに本発明の以下の詳細な説明がよりよく理解されよう。本発明を説明するために、本発明の様々な態様の例示的な実施形態を図面に示す。ただし、本発明は、開示する特定の方法および手段に限定されるものではない。

目次
Ｉ． 序文
Ａ． 例示的な計算機環境
Ｂ． 従来のファイルベースの記憶
ＩＩ． データを組織化し、検索し、共有するＷＩＮＦＳストレージプラットフォーム
Ｃ． 用語解説
Ｄ． ストレージプラットフォームの概観
Ｅ． データモデル
１． アイテム
２． アイテムの識別
３． アイテムフォルダおよびカテゴリ
４． スキーマ
ａ）基本スキーマ
ｂ）コアスキーマ
５． 関係
ａ）関係の宣言
ｂ）保持関係
ｃ）埋込み関係
ｄ）参照関係
ｅ）規則および制約
ｆ）関係の順序づけ
６． 拡張性
ａ）アイテムの拡張
ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔ型の拡張
Ｆ． データベースエンジン
１． ＵＤＴを用いたデータストアの実装
２． アイテムのマッピング
３． 拡張のマッピング
４． ネスト要素のマッピング
５． オブジェクトの識別
６． ＳＱＬオブジェクトの命名
７． 列の命名
８． 検索ビュー
ａ）アイテム
（１）マスタアイテム検索ビュー
（２）型指定アイテム検索ビュー
ｂ）アイテムの拡張
（１）マスタ拡張検索
（２）型指定拡張検索ビュー
ｃ）ネストされた要素
ｄ）関係
（１）マスタ関係検索ビュー
（２）関係インスタンス検索ビュー
ｅ）
９． アップデート
１０． 変更追跡および削除標識
ａ）変更追跡
（１）「マスタ」検索ビューにおける変更追跡
（２）「型指定」検索ビューにおける変更追跡
ｂ）削除標識
（１）アイテム削除標識
（２）拡張削除標識
（３）関係削除標識
（４）削除標識のクリーンアップ
１１． ヘルパＡＰＩおよび関数
ａ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＩｔｅｍ
ｂ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＥｘｔｅｎｔｉｏｎ
ｃ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＲｅｌａｔｉｏｎｓｈｉｐ
１２． メタデータ
ａ）スキーマメタデータ
ｂ）インスタンスメタデータ
Ｇ． セキュリティ
Ｈ． 通知および変更追跡
Ｉ． 同期
１． ストレージプラットフォーム同士の間の同期
ａ）同期（Ｓｙｎｃ）制御アプリケーション
ｂ）スキーマの注釈
ｃ）同期構成
（１）コミュニティフォルダのマッピング
（２）プロファイル
（３）スケジュール
ｄ）競合操作
（１）競合検出
（ａ）知識ベースの競合
（ｂ）制約ベースの競合
（２）競合処理
（ａ）自動競合解決
（ｂ）競合のログ記録
（ｃ）競合検査および解決
（ｄ）レプリカの収束および競合解決の伝播
２． 非ストレージプラットフォームデータストアとの同期
ａ）同期サービス
（１）変更の列挙
（２）変更の適用
（３）競合解決
ｂ）アダプタの実装
３． セキュリティ
４． 管理性
Ｊ． 従来のファイルシステムの相互運用性
Ｋ． ストレージプラットフォームＡＰＩ
ＩＩＩ． 拡張および継承
Ａ． 型システム
Ｂ． 型ファミリ
１． ネスト要素型
２． アイテム型
３． 関係型
ａ）関係のセマンティクス
ｂ）関係の規則および制約
４． 拡張型
Ｃ． 拡張機能
１． 継承
２． 拡張
ＩＶ． 結論

Ｉ． 序文
法的要件を満たすために、本発明の主題を明確に説明する。ただし、この説明自体は、本特許の範囲を限定することを意図していない。そうではなく、本発明者は、特許請求の対象が、本文書において説明されるものと類似した、異なるステップまたはステップの組合せを含むように、現在または将来の他の技術とともに、他の方法でも実施されることを企図している。さらに、「ステップ」という用語は、本明細書において、利用される方法の異なる要素を意味するのに用いることができるが、この用語は、個々のステップの順序が明確に記述されない限り、本明細書において開示される様々なステップの間のいかなる具体的な順序も含意すると解釈されるべきでない。

Ａ． 例示的な計算機環境
本発明の数多くの実施形態は、コンピュータ上で実行することができる。図１および以下の説明は、本発明を実施することができる適切な計算機環境の簡潔かつ全体的な説明の提供を意図している。そうすることが必要なわけではないが、クライアントワークステーションやサーバなどのコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストで、本発明の様々な態様を説明することができる。概して、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家電製品またはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど他のコンピュータシステム構成とともに実施できることが当業者には理解されよう。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによって特定のタスクが実施される分散型計算機環境でも実施することができる。分散型計算機環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置両方に置くことができる。

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

オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８などいくつかのプログラムモジュールを、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に格納することができる。ユーザは、キーボード４０などの入力デバイス、およびポインティングデバイス４２を介して、コマンドおよび情報をパーソナルコンピュータ２０に入力することができる。他の入力デバイス（図示せず）は、マイクロホン、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力デバイスはしばしば、システムバスに結合されるシリアルポートインターフェイス４６を介して処理ユニット２１に接続されるが、他のインターフェイス、たとえば並列ポート、ゲームポート、ＵＳＢ（ユニバーサルシリアルバス）によって接続することもできる。モニタ４７または他のタイプの表示デバイスも、ビデオアダプタ４８などのインターフェイスを介してシステムバス２３に接続される。モニタ４７に加え、パーソナルコンピュータは通常、他の周辺出力デバイス（図示せず）、たとえばスピーカおよびプリンタを含む。図１の例示的なシステムは、ホストアダプタ５５、ＳＣＳＩ（小型計算機システムインターフェイス）バス５６、およびＳＣＳＩバス５６に接続される外部記憶装置６２も含む。

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

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

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

コンピュータシステム２００の様々な実施形態において、再度図１を参照すると、ハードウェアコンポーネント２０２は、他のものの中でも、中央処理装置（ＣＰＵ）２１と、メモリ（ＲＯＭ２４およびＲＡＭ２５両方）と、基本入出力システム（ＢＩＯＳ）２６と、キーボード４０、マウス４２、モニタ４７、および／またはプリンタ（図示せず）など、様々な入出力（Ｉ／Ｏ）デバイスとを備え得る。ハードウェアコンポーネント２０２は、コンピュータシステム２００用の基本的な物理インフラストラクチャを備える。

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

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

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

ハードウェア／ソフトウェアインターフェイスシステムは従来通り、アプリケーション用に様々なサービスを実施する。複数のプログラムが同時に実行し得るマルチタスクのハードウェア／ソフトウェアインターフェイスシステムにおいて、ハードウェア／ソフトウェアインターフェイスシステムは、どのアプリケーションがどのような順序で実行されるべきか、かつ、別のアプリケーションに切り換えるまでにどれだけの時間が各アプリケーションに許可されるべきか判定する。ハードウェア／ソフトウェアインターフェイスシステムはまた、複数のアプリケーションの間での内部メモリの共有を管理し、ハードディスク、プリンタ、およびダイアルアップポートなど、接続されたハードウェアデバイスとの間での入力および出力を操作する。ハードウェア／ソフトウェアインターフェイスシステムはまた、各アプリケーション（および、特定の場合には、エンドユーザ）に、動作状況および起こり得るどのエラーにも関するメッセージを送る。ハードウェア／ソフトウェアインターフェイスシステムは、アプリケーションの開始がバッチジョブに束縛されないように、バッチジョブ（たとえば印刷）の管理をオフロードし、他の処理および／または動作を再開することができる。並列処理を提供し得るコンピュータにおいて、ハードウェア／ソフトウェアインターフェイスシステムは、プログラムが複数のプロセッサ上で一度に実行されるように、プログラムの分割も管理する。

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

本発明の数多くの実施形態は、コンピュータによるシステムに特に適合すると想像されるが、本文書のどの部分も、本発明をこのような実施形態に限定することを意図していない。反対に、本明細書で使用する「コンピュータシステム」という用語は、デバイスが本質的に電子、機械、論理、または仮想であるかに関わらず、情報を格納し処理することができ、かつ／またはこのようなデバイス自体の動作または実行を制御するのに、格納された情報を使うことができるあらゆるデバイスを包含することを意図する。

Ｂ． 従来のファイルベースの記憶
ほとんどのコンピュータシステムにおいて、今日、「ファイル」は、ハードウェア／ソフトウェアインターフェイスシステムならびにアプリケーションプログラム、データセットなどを含み得る、格納可能な情報単位である。現在のすべてのハードウェア／ソフトウェアインターフェイスシステム（Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ、Ｍａｃ ＯＳ、仮想マシンシステムなど）において、ファイルは、ハードウェア／ソフトウェアインターフェイスシステムによって扱うことができる基本的な個別の（格納可能かつ取得可能な）情報単位（たとえば、データ、プログラムなど）である。ファイルのグループは概して、「フォルダ」に組織化される。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃｉｎｔｏｓｈ ＯＳ、および他のハードウェア／ソフトウェアインターフェイスシステムにおいて、フォルダとは、単一の情報単位として取得し、移動し、扱うことができるファイルのコレクションである。こうしたフォルダは、「ディレクトリ」と呼ばれるツリーベースの階層構成（本明細書において、後でより詳しく論じる）に組織化される。ＤＯＳ、ｚ／ＯＳ、およびほとんどのＵｎｉｘ（登録商標）ベースのオペレーティングシステムなど、他の特定のハードウェア／ソフトウェアインターフェイスシステムにおいて、「ディレクトリ」および／または「フォルダ」という用語は交換可能であり、初期のＡｐｐｌｅコンピュータシステム（たとえば、Ａｐｐｌｅ ＩＩｅ）では、ディレクトリではなく「カタログ」という用語を使っていたが、本明細書で使用するこうした用語はすべて、同義的であり交換可能であるとみなされ、階層情報記憶構造ならびにそのフォルダおよびファイルコンポーネント用の他のすべての等価な用語およびコンポーネントへの参照をさらに含むことを意図している。

従来、ディレクトリ（別名、フォルダからなるディレクトリ）とは、ファイルがフォルダにグループ化され、フォルダが、ディレクトリツリーを含む相対ノードの場所に従って配置される、ツリーベースの階層構造である。たとえば、図２Ａに示すように、ＤＯＳベースのファイルシステムのベースフォルダ（または「ルートディレクトリ」）２１２は、複数のフォルダ２１４を含むことができ、フォルダそれぞれが（その具体的フォルダの「サブフォルダ」として）追加フォルダ２１６をさらに含むことができ、追加フォルダ２１６それぞれも追加フォルダ２１８を無限に含むことができる。こうしたフォルダはそれぞれ、１つまたは複数のファイル２２０をもつことができるが、ハードウェア／ソフトウェアインターフェイスシステムレベルでは、フォルダ中の個々のファイルは、ツリー階層中での場所以外に共通点がない。驚くことではないが、ファイルをフォルダ階層に組織化するこの手法は、こうしたファイルを格納するのに使われる一般的な記憶媒体（たとえば、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理的な組織化を間接的に反映する。

上記に加え、各フォルダは、そのサブフォルダおよびファイルのコンテナである。つまり、各フォルダは、そのサブフォルダおよびファイルを所有する。たとえば、ハードウェア／ソフトウェアインターフェイスシステムによってフォルダが消去されると、そのフォルダのサブフォルダおよびファイルも消去される（各サブフォルダの場合、再帰的にその独自のサブフォルダおよびファイルをさらに含む）。同様に、各ファイルは、概してただ１つのフォルダによって所有され、ファイルはコピーすることができるとともにこのコピーは異なるフォルダ内に配置することができるが、ファイルのコピーは、元のファイルとは直接関係のない全く別の単位である（たとえば、元のファイルへの変更が、ハードウェア／ソフトウェアインターフェイスシステムレベルではコピーファイルに反映されない）。この点に関して、フォルダは、物理的コンテナのように扱われ、ファイルは、こうしたコンテナの中で全く別の物理的要素として扱われるので、ファイルおよびフォルダは、本質的に特性が「物理的」である。

ＩＩ． データを組織化し、検索し、共有するＷＩＮＦＳストレージプラットフォーム
本発明は、本明細書において上述した、参照によって組み込まれている関連発明とともに、データを組織化し、検索し、共有するストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、既存のファイルシステムおよびデータベースシステムを上回るようにデータプラットフォームを拡張し拡大し、「アイテム」と呼ばれる新しい形のデータを含むあらゆるタイプのデータ用のストアとなるように設計される。

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

Ｄ． ストレージプラットフォームの概観
図３を参照すると、ストレージプラットフォーム３００は、データベースエンジン３１４上に実装されるデータストア３０２を備える。一実施形態では、データベースエンジンは、オブジェクトリレーショナル拡張を有するリレーショナルデータベースエンジンを備える。一実施形態では、リレーショナルデータベースエンジン３１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバというリレーショナルデータベースエンジンを備える。データストア３０２は、データの組織化、検索、共有、同期、およびセキュリティをサポートするデータモデル３０４を実装する。後で十分に詳しく説明するように、具体的なデータ型は、スキーマ３４０などのスキーマ中に記述され、ストレージプラットフォーム３００は、そうしたスキーマを展開するとともにそうしたスキーマを拡張するツール３４６を提供する。

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

本発明のストレージプラットフォーム３００は、ユーザまたはシステムの間でのデータの共有を円滑に進める同期サービス３３０を含む様々なサービス３２８を、アプリケーションプログラムに提供し得る。たとえば、同期サービス３３０は、データストア３０２と同じ形式をもつ他のデータストア３４０との相互運用、ならびに他の形式をもつデータストア３４２へのアクセスを可能にし得る。ストレージプラットフォーム３００は、Ｗｉｎｄｏｗｓ（登録商標） ＮＴＦＳファイルシステム３１８などの既存のファイルシステムとの、データストア３０２の相互運用を可能にするファイルシステム性能も提供する。少なくともいくつかの実施形態では、ストレージプラットフォーム３２０は、データに作用を与えることを可能にするとともに他のシステムとの対話を可能にする追加性能アプリケーションプログラムも提供し得る。こうした性能は、情報エージェントサービス３３４および通知サービス３３２など、追加サービス３２８の形、ならびに他のユーティリティ３３６の形で実現することができる。

少なくともいくつかの実施形態では、ストレージプラットフォームは、コンピュータシステムのハードウェア／ソフトウェアインターフェイスシステムの不可欠な部分として実現され、またはそのような不可欠な部分を形成する。限定ではなく例として、本発明のストレージプラットフォームは、オペレーティングシステム、仮想マシンマネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的等価物、あるいはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的等価物の不可欠な部分として実現されてもよく、そのような不可欠な部分を形成してもよい。共通の記憶基盤およびデータの体系化により、本発明のストレージプラットフォームは、消費者、知識労働者、および企業に対して、より効率的なアプリケーション開発を可能にする。本発明のストレージプラットフォームは、データモデル中で継承される性能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法も包含し拡張する、豊富かつ拡張可能なプログラミング表面領域を提供する。

以下の説明および様々な図面において、本発明のストレージプラットフォーム３００は、「ＷｉｎＦＳ」と呼ぶことができる。ただし、ストレージプラットフォームを指すためのこの名称の使用は、記述上の都合に過ぎず、どのような限定も意図していない。

Ｅ． データモデル
本発明のストレージプラットフォーム３００のデータストア３０２は、ストアに常駐するデータの組織化、検索、共有、同期、およびセキュリティをサポートするデータモデルを実装する。本発明のデータモデルにおいて、「アイテム」とは、記憶情報の基本的な単位である。データモデルは、後で十分に詳しく説明するように、「アイテム」および「アイテム」の拡張を宣言し、「アイテム」の間の関係を確立し、「アイテム」を「アイテムフォルダ」および「カテゴリ」に組織化する機構を提供する。

データモデルは、「型」および「関係」という２つの基本要素機構に依拠する。「型」は、「型」のインスタンスの形を支配する形式を提供する構造である。形式は、順序づけられた１組の「プロパティ」として表現される。「プロパティ」とは、値の名称、または所与の「型」の値の組である。たとえば、ＵＳＰｏｓｔａｌＡｄｄｒｅｓｓ型は、街路名、都市、郵便番号、州というプロパティをもつことができ、街路名、都市、および州は「文字列」型であり、「郵便番号」は、Ｉｎｔ３２型である。街路名は、多値（すなわち、１組の値）でよく、住所に「街路名」プロパティ用の複数の値をもたせる。システムは、他の型の構築において使うことができる特定の基本要素型を定義する。基本要素型は、Ｓｔｒｉｎｇ、Ｂｉｎａｒｙ、Ｂｏｏｌｅａｎ、Ｉｎｔ１６、Ｉｎｔ３２、Ｉｎｔ６４、Ｓｉｎｇｌｅ、Ｄｏｕｂｌｅ、Ｂｙｔｅ、ＤａｔｅＴｉｍｅ、Ｄｅｃｉｍａｌ、およびＧＵＩＤを含む。「型」の「プロパティ」は、基本要素型のどれを使っても、（後で言及するいくつかの制限を伴うが）構築された型のどれを使っても定義することができる。たとえば、「座標」および「住所」プロパティを有する「場所型」を定義することができ、「住所プロパティ」は、上述したＵＳＰｏｓｔａｌＡｄｄｒｅｓｓ「型」である。プロパティは、必須でも任意選択でもよい。

関係は、宣言することができ、２つの型のインスタンスからなる組の間のマッピングを表すことができる。たとえば、「人型」と「場所型」の間で宣言される、どの人がどの場所に住んでいるかを定義するＬｉｖｅｓＡｔと呼ばれる「関係」が存在し得る。この「関係」は、名称、２つのエンドポイント、すなわちソースエンドポイントおよびターゲットエンドポイントをもつ。関係は、順序づけられた１組のプロパティをもつこともできる。「ソース」および「ターゲット」エンドポイントは両方とも、「名称」および「型」をもつ。たとえば、ＬｉｖｅｓＡｔ「関係」は、「人」型の、「居住者」と呼ばれる「ソース」、および「場所」型の、「住居」と呼ばれる「ターゲット」をもち、さらに、居住者がその住居に住んだ期間を示すＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅプロパティをもつ。「人」は、長期間の間に、複数の住居に住む場合があり、住居には、複数の居住者が存在し得るので、ＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅ情報をもたせるのに最も適した場所は、関係自体であることに留意されたい。

関係は、エンドポイント型として与えられる型によって制約される、インスタンスの間のマッピングを定義する。たとえば、「自動車」は「人」ではないので、ＬｉｖｅｓＡｔ関係は、「自動車」が「居住者」である関係であってはならない。

データモデルは、型の間のサブ型とスーパー型の間の関係定義を可能にする。ＢａｓｅＴｙｐｅ関係としても知られるサブ型とスーパー型の間の関係は、「型」Ａが「型」ＢのＢａｓｅＴｙｐｅである場合、ＢのすべてのインスタンスがＡのインスタンスでもあることが成り立つように定義される。別の表現をすると、Ｂに準拠するすべてのインスタンスは、Ａにも準拠しなければならない。たとえば、Ａが「文字列」型の「名称」プロパティをもち、Ｂが、「Ｉｎｔ１６」型の「年齢」プロパティをもつ場合、Ｂのどのインスタンスも、「名称」および「年齢」両方をもたなければならないことになる。型の階層は、ルートに１個のスーパー型を有するツリーとして想定することができる。ルートからの分岐は、第１レベルのサブ型を提供し、このレベルでの分岐は、第２レベルのサブ型を提供し、同様に、それ自体はサブ型をもたない最下位（ｌｅａｆ−ｍｏｓｔ）のサブ型まで続く。ツリーは、一様の深さとなる制約を受けないが、サイクルを含むことができない。所与の「型」は、ゼロまたは多くのサブ型およびゼロまたは１個のスーパー型をもつことができる。所与のインスタンスは、多くとも１つの型に準拠し、同時にその型のスーパー型にも準拠し得る。別の言い方をすると、ツリー中のどのレベルの所与のインスタンスの場合も、インスタンスは、そのレベルで多くとも１つのサブ型に準拠し得る。型のインスタンスがその型のサブ型のインスタンスでもなければならない場合、型は「抽象」であると言われる。

１． アイテム
「アイテム」とは、格納可能な情報単位であり、単純なファイルとは異なり、ストレージプラットフォームによってエンドユーザまたはアプリケーションプログラムに公開されるすべてのオブジェクトにわたって一般的にサポートされる基本的な１組のプロパティを有するオブジェクトである。「アイテム」は、後で論じるように、新しいプロパティおよび関係を導入させる特徴を含むすべての「アイテム」型にわたって一般的にサポートされるプロパティおよび関係も有する。

アイテムは、たとえばコピー、消去、移動、オープン、印刷、バックアップ、復元、複製などの共通動作用のオブジェクトである。アイテムは、格納し取得することができる単位であり、ストレージプラットフォームによって操作されるあらゆる形の格納可能な情報は、「アイテム」、「アイテム」のプロパティ、または「アイテム」の間の「関係」として存在し、これらはそれぞれ、本明細書において後でより詳細に説明する。

アイテムは、現実世界および（あらゆる種類の）「連絡先」、「人々」、「サービス」、「場所」、「ドキュメント」などのような、理解しやすいデータ単位を表すことを意図している。図５Ａは、「アイテム」の構造を示すブロック図である。「アイテム」の非限定名は、「Ｌｏｃａｔｉｏｎ」である。「アイテム」の限定名は、この「アイテム」構造が、「コアスキーマ」中で「アイテム」の具体的な型として定義されることを示す「Ｃｏｒｅ．Ｌｏｃａｔｉｏｎ」である。（「コアスキーマ」は、本明細書において後でより詳しく論じる）。

Ｌｏｃａｔｉｏｎ「アイテム」は、ＥＡｄｄｒｅｓｓｅｓ、ＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎ、Ｎｅｉｇｈｂｏｒｈｏｏｄ、およびＰｏｓｔａｌＡｄｄｒｅｓｓｅｓを含む複数のプロパティをもつ。それぞれに対するプロパティの具体的な型は、プロパティ名の直後に示され、コロン（「：」）によってプロパティ名から区切られる。型名の右側に、そのプロパティ型に許可される値の数が、括弧（「［］」）の中に示され、コロン（「：」）の右側のアスタリスク（「*」）は、不特定および／または無限（「多数」）を示す。コロンの右側の「１」は、多くとも１つの値が存在し得ることを示す。コロンの左側のゼロ（「０」）は、プロパティが任意選択である（値がなくてもよい）ことを示す。コロンの左側の「１」は、少なくとも１つの値がなければならない（そのプロパティが要求される）ことを示す。ＮｅｉｇｈｂｏｒｈｏｏｄおよびＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎは両方とも、予め定義されたデータ型または「単純型」（ここでは大文字にせずに示す）である「ｎｖａｒｃｈａｒ」（またはそれと等価な）型である。しかし、ＥＡｄｄｒｅｓｓｅｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓｅｓは、ＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓ型それぞれの、定義された型または「複合型」（本明細書では大文字にして示す）のプロパティである。複合型とは、１つもしくは複数の単純データ型および／または他の複合型から派生される型である。「アイテム」プロパティの複合型は、「ネスト要素」も構成する。というのは、複合型の詳細は、「アイテム」に直接ネストされて、「アイテム」のプロパティを定義し、こうした複合型に付随する情報は、こうしたプロパティをもつ「アイテム」とともに（本明細書において後で論じるように、「アイテム」の境界内に）維持されるからである。こうした型指定の概念は公知であり、当業者には容易に理解されよう。

図５Ｂは、複合プロパティ型ＰｏｓｔａｌＡｄｄｒｅｓｓおよびＥＡｄｄｒｅｓｓを示すブロック図である。ＰｏｓｔａｌＡｄｄｒｅｓｓプロパティ型は、ＰｏｓｔａｌＡｄｄｒｅｓｓ型プロパティの「アイテム」が、ゼロまたは１個のＣｉｔｙ値、ゼロまたは１個のＣｏｕｎｔｒｙＣｏｄｅ値、ゼロまたは１個のＭａｉｌＳｔｏｐ値、および任意の数（ゼロから多数）のＰｏｓｔａｌＡｄｄｒｅｓｓＴｙｐｅなどをもつと予期され得ることを定義する。このように、「アイテム」中のある特定のプロパティのデータ形状が、ここで定義される。ＥＡｄｄｒｅｓｓプロパティ型も同様に、図に示すように定義される。本明細書では任意選択で使われるが、Ｌｏｃｃａｔｉｏｎアイテムにおける複合型の別の表し方は、その中に各複合型の個々のプロパティを列挙した「アイテム」を書くことである。図５Ｃは、Ｌｏｃａｔｉｏｎアイテムを示し、その複合型をさらに記述するブロック図である。ただし、図５ＣのＬｏｃａｔｉｏｎアイテムのこの代替表現は、図５Ａに示すのと全く同じ「アイテム」であることを理解されたい。本発明のストレージプラットフォームは、サブ型指定も可能にし、そうすることによって、あるプロパティ型が、別のプロパティ型のサブ型になり得る（あるプロパティ型が、別の親プロパティ型のプロパティを継承する）。

プロパティおよびそのプロパティ型と類似しているが厳密には異なり、アイテムは、サブ型指定の対象にもなり得る独自の「アイテム型」を本質的に表す。言い換えると、本発明のいくつかの実施形態におけるストレージプラットフォームは、「アイテム」を、別の「アイテム」のサブ型にさせる（そうすることによって、あるアイテムは、他の親「アイテム」のプロパティを継承する）。さらに、本発明の様々な実施形態の場合、すべての「アイテム」は、「基本スキーマ」中に見られる第１の基本的な「アイテム」型である、Ｉｔｅｍという「アイテム」型のサブ型である。（「基本スキーマ」も、本明細書において後で詳しく論じる。）図６Ａは、「基本スキーマ」中で見つかった「Ｉｔｅｍ」という「アイテム」型のサブ型としての「Ｉｔｅｍ」、すなわちこの「インスタンス」ではＬｏｃａｔｉｏｎアイテムを示す図である。図６Ａにおいて、矢印は、Ｌｏｃａｔｉｏｎアイテムが（他のすべての「アイテム」のように）、Ｉｔｅｍという「アイテム」型のサブ型であることを示す。Ｉｔｅｍという「アイテム」型は、すべての他の「アイテム」が派生される元である基本的な「アイテム」として、ＩｔｅｍＩｄおよび様々なタイムスタンプなど、いくつかの重要なプロパティをもち、そうすることによって、オペレーティングシステムにおけるすべてのアイテムの標準プロパティを定義する。この図において、Ｉｔｅｍという「アイテム」型のこうしたプロパティは、Ｌｏｃａｔｉｏｎによって継承され、そうすることによって、Ｌｏｃａｔｉｏｎのプロパティとなる。

Ｉｔｅｍという「アイテム」型から継承される、Ｌｏｃｃａｔｉｏｎアイテムにおけるプロパティの別の表し方は、その中に各プロパティ型の個々のプロパティを列挙したＬｏｃａｔｉｏｎを書くことである。図６Ｂは、Ｌｏｃｃａｔｉｏｎアイテムを示し、その継承型をその直接プロパティに加えて記述したブロック図である。この「アイテム」は、図５Ａに示すのと同じ「アイテム」であるが、図６Ａでは、Ｌｏｃａｔｉｏｎは、そのプロパティすべてを、図６Ａおよび図５Ａ両方に示すように直接有して、かつ図５Ａには示していないが図６Ａに示すように継承によって有して示されている（図５Ａでは、こうしたプロパティは、ＬｏｃａｔｉｏｎアイテムがＩｔｅｍという「アイテム」型のサブ型であることを矢印で示すことによって参照される）ことに留意され理解されたい。

アイテムは、独立オブジェクトである。したがって、「アイテム」を消去すると、その「アイテム」の直接および継承プロパティもすべて消去される。同様に、「アイテム」を取得すると、受け取られるのは、「アイテム」ならびにその直接および継承プロパティすべてである（プロパティ型に付随する情報を含む）。本発明の特定の実施形態では、具体的な「アイテム」を取得するとき、プロパティのサブセットを要求することが可能となり得るが、多くのこのような実施形態のデフォルトは、取得されるときに、「アイテム」を、その直接および継承プロパティのすべてとともに提供することである。さらに、「アイテム」のプロパティは、その「アイテム」の型の既存のプロパティに新しいプロパティを追加することによって拡張することもできる。こうした「拡張」はその後、「アイテム」の正式なプロパティとなり、その「アイテム」型のサブ型は、拡張プロパティを自動的に含み得る。

「アイテム」の「境界」は、そのプロパティ（複合プロパティ型、拡張などを含む）によって表される。「アイテム」の境界とは、「アイテム」に対して実施される操作の限度、たとえば、コピー、消去、移動、作成なども表す。たとえば、本発明のいくつかの実施形態では、「アイテム」がコピーされると、その「アイテム」の境界内のすべてのものもコピーされる。各「アイテム」に対して、境界は、以下のものを包含する。
・「アイテム」の「アイテム型」、ならびに、「アイテム」が別の「アイテム」のサブ型である場合（すべての「アイテム」が、「基本スキーマ」中で単一の「アイテム」および「アイテム型」から派生される本発明のいくつかの実施形態の場合のように）は、適用可能なあらゆるサブ型情報（つまり、親「アイテム型」に付随する情報）。コピーされた元の「アイテム」が、別の「アイテム」のサブ型である場合、コピーも、その同じ「アイテム」のサブ型となり得る。
・存在する場合、「アイテム」の複合型プロパティおよび拡張。元の「アイテム」が、複合型のプロパティ（固有または拡張）を有する場合、コピーも、同じ複合型をもち得る。
・「所有権関係」における「アイテム」のレコード、つまり、他のどのような「アイテム」（「ターゲットアイテム」）が、現在の「アイテム」（「所有側アイテム」）によって所有されるかという、「アイテム」独自のリスト。このリストは、特に、後でより詳しく論じる「アイテムフォルダ」、およびすべての「アイテム」が少なくとも１つの「アイテムフォルダ」に属さなければならないという下に挙げる規則に適している。さらに、後でより詳しく論じる埋込みアイテムに関して、埋込みアイテムは、たとえばコピー、消去などの動作のために埋め込まれる「アイテム」の一部と見なされる。

２． アイテムの識別
アイテムは、グローバルなアイテム空間において、ＩｔｅｍＩＤを用いて一意に識別される。Ｂａｓｅ．Ｉｔｅｍ型は、「アイテム」の識別を格納するＧＵＩＤ型のＩｔｅｍＩＤフィールドを定義する。「アイテム」は、データストア３０２中でただ１つの識別をもたなければならない。

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

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

ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅは、ＬｏｃａｔｏｒおよびＰａｔｈフィールドを定義する、ＩｔｅｍＲｅｆｅｒｅｎｃｅを限定したものである。Ｌｏｃａｔｏｒフィールドは、アイテムドメインを識別する。Ｌｏｃａｔｏｒフィールドは、アイテムドメインへのＬｏｃａｔｏｒの値を解決することができるロケータ解決メソッドによって処理される。Ｐａｔｈフィールドは、Ｌｏｃａｔｏｒによって与えられるアイテムドメインをルートとする、ストレージプラットフォームの名前空間内の（相対）パスを含む。

この参照型は、セット動作において使うことができない。この参照は概して、パス解決プロセスを介して解決されなければならない。ストレージプラットフォームＡＰＩ３２２のＲｅｓｏｌｖｅメソッドは、この機能を提供する。

上述した参照の形は、図１１に示す参照型階層により表される。こうした型から継承される追加参照型は、スキーマ中で定義することができる。こうした追加参照型は、関係宣言においてターゲットフィールドの型として使うことができる。

３． アイテムフォルダおよびカテゴリ
後でより詳しく論じるように、「アイテム」のグループは、「アイテムフォルダ」（ファイルフォルダと混同しないようにされたい）と呼ばれる特殊な「アイテム」に組織化することができる。ただし、ほとんどのファイルシステムの場合とは異なり、「アイテム」は、複数の「アイテムフォルダ」に属すことができ、そうすることによって、「アイテム」が、ある「アイテムフォルダ」中でアクセスされ見直されると、この見直された「アイテム」は次いで、別の「アイテム」フォルダから直接アクセスすることができる。本質的に、「アイテム」へのアクセスは、異なる「アイテムフォルダ」から起こり得るが、実際にアクセスされているものは、まさに同じ「アイテム」である。ただし、「アイテムフォルダ」は、必ずしもそのメンバー「アイテム」をすべて所有するわけではなく、あるいは、他のフォルダとともに「アイテム」を共同所有し得るに過ぎず、そうすることによって、「アイテムフォルダ」を消去しても、必ずしも「アイテム」を消去することにはならない。それにも関わらず、本発明のいくつかの実施形態では、「アイテム」は、少なくとも１つの「アイテムフォルダ」に属さなければならず、そうすることによって、ある特定の「アイテム」の唯一の「アイテムフォルダ」が消去されると、いくつかの実施形態では、「アイテム」が自動的に消去され、あるいは代替実施形態では、「アイテム」は、自動的にデフォルト「アイテムフォルダ」のメンバー（たとえば、様々なファイルおよびフォルダベースのシステムで使われる同じような名前のフォルダと概念的に類似している「ゴミ箱」という「アイテムフォルダ」）となる。

やはり後でより詳しく論じるように、「アイテム」は、（ａ）「アイテム型」（または複数の「型」）、（ｂ）具体的な直接または継承プロパティ（または複数のプロパティ）、あるいは（ｃ）「アイテム」プロパティに対応する具体的な値（または複数の値）などの共通記述特性に基づいて、「カテゴリ」にも属し得る。たとえば、個人の連絡先情報用の具体的なプロパティを含む「アイテム」は、自動的に「連絡先カテゴリ」に属すことができ、連絡先情報プロパティをもつどの「アイテム」も、同様にこの「カテゴリ」に自動的に属すことになる。同様に、「Ｎｅｗ Ｙｏｒｋ Ｃｉｔｙ」という値の場所プロパティをもつどの「アイテム」も、自動的にＮｅｗＹｏｒｋＣｉｔｙカテゴリに属し得る。

「アイテムフォルダ」は、相互関係のない（すなわち、共通記述特性をもたない）「アイテム」を含むことができ、「カテゴリ」中の各「アイテム」は、その「カテゴリ」用に記述される共通の型、プロパティ、または値（「共通性」）をもつという点で、カテゴリは、概念的に異なる形の「アイテムフォルダ」であり、「カテゴリ」中の他の「アイテム」との、およびその間での関係の基礎を形成するのは、この共通性である。さらに、ある特定の「フォルダ」における「アイテム」の帰属関係は、その「アイテム」の具体的などの側面にも基づいて、強制ではないが、特定の実施形態の場合、ある「カテゴリ」に絶対的に関連する共通性を有するすべての「アイテム」は、ハードウェア／ソフトウェアインターフェイスシステムレベルで、自動的にその「カテゴリ」のメンバーとなり得る。概念的に、「カテゴリ」は、（データベースのコンテキストでのような）具体的なクエリ結果にその帰属関係が基づく仮想「アイテムフォルダ」とも考えることができ、このクエリ条件（「カテゴリ」の共通性によって定義される）を満たす「アイテム」はしたがって、「カテゴリ」の帰属関係を含むことになる。

図４は、「アイテム」、「アイテムフォルダ」、および「カテゴリ」の間の構造関係を示す。複数のアイテム４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、および４２０は、様々な「アイテムフォルダ」４２２、４２４、４２６、４２８、および４３０のメンバーである。いくつかのアイテムは、複数の「アイテムフォルダ」に属すことができ、たとえば、「アイテム」４０２は、「アイテムフォルダ」４２２および４２４に属す。いくつかの「アイテム」、たとえば、「アイテム」４０２、４０４、４０６、４０８、４１０、および４１２は、１つまたは複数の「カテゴリ」４３２、４３４、および４３６のメンバーでもあり、ときには、たとえば「アイテム」４１４、４１６、４１８、および４２０が、どの「カテゴリ」にも属さない場合がある（ただし、これは、どのプロパティの所有も、自動的に「カテゴリ」における帰属関係を含意する特定の実施形態ではほとんど起こることがないので、「アイテム」は、このような実施形態では、どのカテゴリのメンバーにもならないように全く特色がないものとならなくてはならない）。フォルダの階層構造とは対照的に、「カテゴリ」および「アイテムフォルダ」は両方とも、図に示すように、有向グラフと比較的類似した構造を有する。いずれの場合でも、「アイテム」、「アイテムフォルダ」、および「カテゴリ」はすべて、（異なる「アイテム型」であっても）「アイテム」である。

ファイル、フォルダ、およびディレクトリとは対照的に、本発明の「アイテム」、「アイテムフォルダ」、および「カテゴリ」は、本質的に特性が「物理的」でない。というのは、物理的コンテナと概念的に等価なものをもたないので、「アイテム」は、複数のこのような場所に存在し得るからである。「アイテム」が複数の「アイテムフォルダ」の場所に存在し得ること、ならびに「カテゴリ」に組織化されることによって、データ処理および記憶構造性能が、ハードウェア／ソフトウェアインターフェイスレベルにおいて、当該分野において現在利用可能であるものよりも優れた、豊かなものとなる。

４． スキーマ
ａ）「基本スキーマ」
「アイテム」の作成および使用のための普遍的な基盤を提供するために、本発明のストレージプラットフォームの様々な実施形態は、「アイテム」およびプロパティを作成し組織化する概念的なフレームワークを確立する「基本スキーマ」を備える。「基本スキーマ」は、「アイテム」およびプロパティの特定の特殊型、およびサブ型をそこからさらに派生することができるこうした基本的な特殊型の特徴を定義する。この「基本スキーマ」を使うことにより、プログラマは、「アイテム」（および「アイテム」それぞれの型）をプロパティ（およびプロパティそれぞれの型）と概念的に区別することが可能になる。さらに、すべての「アイテム」（および対応する「アイテム型」）が、「基本スキーマ」（および対応する「アイテム型」）においてこの基本的な「アイテム」から派生されるので、「基本スキーマ」は、すべてのアイテムが所有し得るプロパティの基本的な組を明らかにする。

図７に示すように、本発明のいくつかの実施形態に関連して、「基本スキーマ」は、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＰｒｏｐｅｒｔｙＢａｓｅという３つの最上位レベル型を定義する。説明したように、「アイテム」型は、この基本的なＩｔｅｍという「アイテム」型のプロパティによって定義される。対照的に、最上位レベルのプロパティ型である「ＰｒｏｐｅｒｔｙＢａｓｅ」は、予め定義されたプロパティをもたず、すべての他のプロパティ型がそこから派生されるとともに、すべての派生プロパティ型がそれを介して相互に関係付けられるアンカに過ぎない（一般に、単一のプロパティ型から派生される）。「アイテム」が複数の拡張をもち得るので、「拡張」型プロパティは、拡張が拡張する「アイテム」ならびにある拡張を別の拡張と区別するための識別を定義する。

ＩｔｅｍＦｏｌｄｅｒは、Ｉｔｅｍから継承されるプロパティに加えて、そのメンバー（存在する場合）へのリンクを確立する「関係」を特徴づける、Ｉｔｅｍという「アイテム」型のサブ型であり、ＩｄｅｎｔｉｔｙＫｅｙおよびＰｒｏｐｅｒｔｙは両方とも、ＰｒｏｐｅｒｔｙＢａｓｅのサブ型である。ＣａｔｅｇｏｒｙＲｅｆは、ＩｄｅｎｔｉｔｙＫｅｙのサブ型である。

ｂ）「コアスキーマ」
本発明のストレージプラットフォームの様々な実施形態は、最上位レベルの「アイテム」型構造のための概念的なフレームワークを提供する「コアスキーマ」をさらに備える。図８Ａは、「コアスキーマ」中の「アイテム」を示すブロック図であり、図８Ｂは、「コアスキーマ」中のプロパティ型を示すブロック図である。ファイルは、異なる拡張子（*．ｃｏｍ、*．ｅｘｅ、*．ｂａｔ、*．ｓｙｓなど）で区別され、ファイルおよびフォルダベースのシステムにおける、他のこのような基準は、「コアスキーマ」の関数と類似している。「アイテム」ベースのハードウェア／ソフトウェアインターフェイスシステムにおいて、「コアスキーマ」は、直接（「アイテム」型によって）または間接的に（「アイテム」サブ型によって）、すべての「アイテム」を、「アイテム」ベースのハードウェア／ソフトウェアインターフェイスシステムが理解し、所定の予測可能なやり方で直接処理することができる１つまたは複数の「コアスキーマ」という「アイテム」型に特徴づける、１組のコア「アイテム」型を定義する。予め定義された「アイテム」型は、「アイテム」ベースのハードウェア／ソフトウェアインターフェイスシステムにおけるほとんどの共通「アイテム」を反映し、したがって、「コアスキーマ」を含む、こうした予め定義された「アイテム」型を理解する「アイテム」ベースのハードウェア／ソフトウェアインターフェイスシステムによってある程度の効果が得られる。

特定の実施形態では、「コアスキーマ」は拡張可能でない。つまり、どの追加「アイテム」型も、「コアスキーマ」の一部である予め定義された具体的な派生「アイテム」型を除いて、「基本スキーマ」中の「アイテム」型から直接サブ型指定することができない。すべての後続「アイテム」型は、必ず「コアスキーマアイテム」型のサブ型なので、「コアスキーマ」への拡張を妨げることによって（つまり、「コアスキーマ」への新しい「アイテム」の追加を妨げることによって）、ストレージプラットフォームは、「コアスキーマアイテム」型の使用を義務づける。この構造により、追加「アイテム」型の定義において妥当な程度の柔軟性が得られるとともに、予め定義された一組のコア「アイテム」型をもつという利点も保たれる。

本発明の様々な実施形態の場合、図８Ａを参照すると、「コアスキーマ」によってサポートされる具体的な「アイテム」型は、以下の１つまたは複数を含み得る。
・Ｃａｔｅｇｏｒｙ：この「アイテム型」の「アイテム」（およびそこから派生されるサブ型）は、「アイテム」ベースのハードウェア／ソフトウェアインターフェイスシステムにおける有効な「カテゴリ」を表す。
・Ｃｏｍｍｏｄｉｔｙ：値の識別可能なものであるアイテム。
・Ｄｅｖｉｃｅ：情報処理能力をサポートする論理構造をもつアイテム。
・Ｄｏｃｕｍｅｎｔ：「アイテム」ベースのハードウェア／ソフトウェアインターフェイスシステムによって翻訳されないが、ドキュメント型に対応するアプリケーションプログラムによって翻訳される内容をもつアイテム。
・Ｅｖｅｎｔ：環境における特定の出来事を記録するアイテム。
・Ｌｏｃａｔｉｏｎ：物理的な位置（たとえば、地理的な場所）を表すアイテム。
・Ｍｅｓｓａｇｅ：２つ以上のプリンシパル（下で定義する）の間の通信のアイテム。
・Ｐｒｉｎｃｉｐａｌ：ＩｔｅｍＩｄ（たとえば、人、編集、グループ、家族、権限、サービスなどの識別）に加えて、断定的に証明可能な少なくとも１つの識別をもつアイテム。
・Ｓｔａｔｅｍｅｎｔ：限定ではなく、ポリシー、登録内容、認定資格などを含む環境に関する特殊な情報をもつアイテム。
同様に、図８Ｂを参照すると、「コアスキーマ」によってサポートされる具体的なプロパティ型は、以下の１つまたは複数を含み得る。
・Ｃｅｒｔｉｆｉｃａｔｅ（「基本スキーマ」中で、基本的なＰｒｏｐｅｒｔｙＢａｓｅ型から派生される）
・Ｐｒｉｎｃｉｐａｌ Ｉｄｅｎｔｉｔｙ Ｋｅｙ（「基本スキーマ」中で、ＩｄｅｎｔｉｔｙＫｅｙ型から派生される）
・Ｐｏｓｔａｌ Ａｄｄｒｅｓｓ（「基本スキーマ」中で、Ｐｒｏｐｅｒｔｙ型から派生される）
・Ｒｉｃｈ Ｔｅｘｔ（「基本スキーマ」中で、Ｐｒｏｐｅｒｔｙ型から派生される）
・ＥＡｄｄｒｅｓｓ（「基本スキーマ」中で、Ｐｒｏｐｅｒｔｙ型から派生される）
・ＩｄｅｎｔｉｔｙＳｅｃｕｒｉｔｙＰａｃｋａｇｅ（「基本スキーマ」中で、Ｒｅｌａｔｉｏｎ型から派生される）
・ＲｏｌｅＯｃｃｕｐａｎｃｙ（「基本スキーマ」中で、Ｒｅｌａｔｉｏｎ型から派生される）
・ＢａｓｉｃＰｒｅｓｅｎｃｅ（「基本スキーマ」中で、Ｒｅｌａｔｉｏｎ型から派生される）
こうした「アイテム」および「プロパティ」は、図８Ａおよび図８Ｂに示されるそれぞれのプロパティによってさらに記述される。

５． 関係
ある「アイテム」がソースとして指定され、他の「アイテム」がターゲットとして指定される場合、関係は、バイナリ関係である。ソース「アイテム」およびターゲット「アイテム」は、関係によって関係づけられる。ソース「アイテム」は概して、関係の存続期間を制御する。つまり、ソース「アイテム」が消去されると、「アイテム」の間の関係も消去される。

関係は、「包含」および「参照」関係に分類される。包含関係は、ターゲット「アイテム」の存続期間を制御するが、参照関係は、いかなる存続期間管理セマンティクスも提供しない。図１２は、関係の分類方法を示す図である。

「包含」関係型は、「保持」および「埋込み」関係にさらに分類される。「アイテム」とのすべての保持関係が削除されると、「アイテム」が消去される。保持関係は、参照カウント機構によりターゲットの存続期間を制御する。埋込み関係は、合成「アイテム」のモデリングを可能にし、排他的保持関係と見なすことができる。「アイテム」は、１つまたは複数の保持関係のターゲットでよいが、「アイテム」は、ただ１つの埋込み関係のターゲットとなり得る。埋込み関係のターゲットである「アイテム」は、他のどの保持または埋込み関係のターゲットになることもできない。

参照関係は、ターゲット「アイテム」の存続期間を制御しない。参照関係は、ダングリング（ｄａｎｇｌｉｎｇ）であってよく、すなわちターゲット「アイテム」が存在しなくてもよい。参照関係は、グローバルな「アイテム」名前空間のどこでも（すなわち、リモートデータストアを含む）、「アイテム」への参照をモデル化するのに使うことができる。

「アイテム」を取り出しても、自動的にその関係を取り出すことにはならない。アプリケーションは、「アイテム」の関係を明示的に要求しなければならない。さらに、関係を修正しても、ソースもターゲット「アイテム」も修正することにはならない。同様に、関係の追加は、ソース／ターゲット「アイテム」に影響を与えない。

ａ）関係の宣言
以下の要素を用いて、明示的な関係型が定義される。
・関係名が、「名称」属性中で指定される。
・「保持」、「埋込み」、「参照」の１つである関係型。「型」属性中で指定される。
・ソースおよびターゲットエンドポイント。各エンドポイントは、参照「アイテム」の名称および型を指定する。
・ソースエンドポイントフィールドは、概してＩｔｅｍＩＤ型（宣言されない）であり、同じデータストア中の「アイテム」を関係インスタンスとして参照しなければならない。
・「保持」および「埋込み」関係に対して、ターゲットエンドポイントフィールドは、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅ型でなければならず、同じストア中の「アイテム」を関係インスタンスとして参照しなければならない。「参照」関係に対して、ターゲットエンドポイントは、どのＩｔｅｍＲｅｆｅｒｅｎｃｅ型でもよく、他のストレージプラットフォームデータストア中の「アイテム」を参照することができる。
・任意選択で、スカラーまたはＰｒｏｐｅｒｔｙＢａｓｅ型の１つまたは複数のフィールドを宣言することができる。こうしたフィールドは、関係に関連づけられたデータを含み得る。
・関係インスタンスは、グローバルな関係テーブルに格納される。
・すべての関係インスタンスは、組合せ（ソースＩｔｅｍＩＤ、関係ＩＤ）によって一意に識別される。関係ＩＤは、所与の「アイテム」をソースとするすべての関係に対して、関係の型に関わらず、所与のソースＩｔｅｍＩＤにおいて一意である。

ソース「アイテム」は、関係の所有者である。所有者として指定された「アイテム」は、関係の存続期間を制御するが、関係自体は、関係によって関係づけられるアイテムから分離している。ストレージプラットフォームＡＰＩ３２２は、「アイテム」に関連づけられた関係を公開する機構を提供する。

以下に関係宣言の例を示す。

この例は、「参照」関係の例である。この関係は、ソース参照によって参照される人という「アイテム」が存在しない場合、作成することができない。また、人という「アイテム」が消去された場合、人と組織の間の関係インスタンスが消去される。しかし、「組織アイテム」が消去された場合、関係は消去されず、不安定な状態である。

ｂ）保持関係
保持関係は、参照カウントに基づく、ターゲット「アイテム」の存続期間管理をモデル化するのに使われる。

「アイテム」は、「アイテム」へのゼロ以上の関係に対するソースエンドポイントになり得る。「埋込み」アイテムでない「アイテム」は、１つまたは複数の保持関係のターゲットになり得る。

ターゲットエンドポイント参照型は、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅでなければならず、同じストア中の「アイテム」を関係インスタンスとして参照しなければならない。

保持関係は、ターゲットエンドポイントの存続期間管理を強制する。保持関係インスタンス、およびこのインスタンスがターゲットとしている「アイテム」の作成は、アトミック動作である。同じ「アイテム」をターゲットとしている追加保持関係インスタンスを作成することができる。所与の「アイテム」をターゲットエンドポイントとしてもっている最後の保持関係インスタンスが消去されると、ターゲット「アイテム」も消去される。

関係宣言において指定されたエンドポイント「アイテム」の型は概して、その関係のインスタンスが作成されると強制される。エンドポイント「アイテム」の型は、関係が確立された後は変えることができない。

保持関係は、「アイテム」名前空間の形成において重要な役割を果たす。保持関係は、ソース「アイテム」に相対したターゲット「アイテム」の名称を定義する「名称」プロパティを含む。この相対名は、所与の「アイテム」から発生した保持関係すべてに対して一意である。ルート「アイテム」から始まり、所与の「アイテム」までの、この相対名の順序つきリストは、「アイテム」に対する完全な名称（ｆｕｌｌ ｎａｍｅ）を形成する。

保持関係は、有向非循環グラフ（ＤＡＧ）を形成する。保持関係が作成されると、システムは、確実にサイクルが作成されないようにし、したがって、「アイテム」名前空間がＤＡＧを確実に形成するようにする。

保持関係は、ターゲット「アイテム」の存続期間を制御するが、ターゲットエンドポイント「アイテム」の動作の一貫性は制御しない。ターゲット「アイテム」は動作上、保持関係を通して所有している「アイテム」から独立している。保持関係のソースである「アイテム」に対するコピー、移動、バックアップ、および他の操作は、同じ関係のターゲットである「アイテム」に影響を与えない。つまり、たとえば、「フォルダアイテム」のバックアップをとっても、自動的にフォルダ中の「アイテム」すべて（ＦｏｌｄｅｒＭｅｍｂｅｒ関係のターゲット）のバックアップをとることにはならない。

以下は、保持関係の例である。

ＦｏｌｄｅｒＭｅｍｂｅｒｓ関係は、「アイテム」の汎用コレクションとしての「フォルダ」の概念を可能にする。

ｃ）埋込み関係
埋込み関係は、ターゲット「アイテム」の存続期間の、排他的制御の概念をモデル化する。埋込み関係は、合成「アイテム」の概念を可能にする。

埋込み関係インスタンス、およびこのインスタンスがターゲットとしている「アイテム」の作成は、アトミック動作である。「アイテム」は、ゼロ以上の埋込み関係のソースとなり得る。ただし、「アイテム」は、唯一の埋込み関係のターゲットとなり得る。埋込み関係のターゲットである「アイテム」は、保持関係のターゲットになることができない。

ターゲットエンドポイント参照型は、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅでなければならず、同じストア中の「アイテム」を関係インスタンスとして参照しなければならない。

関係宣言において指定されたエンドポイント「アイテム」の型は概して、その関係のインスタンスが作成されると強制される。エンドポイント「アイテム」の型は、関係が確立された後は変えることができない。

埋込み関係は、ターゲットエンドポイントの動作の一貫性を制御する。たとえば、「アイテム」を並べ替える動作は、その「アイテム」ならびに関係のターゲットすべてから発生する埋込み関係すべてのシリアライゼーションを含み得る。「アイテム」をコピーすると、そのすべての埋込み「アイテム」もコピーされる。

以下は、宣言の例である。

ｄ）参照関係
参照関係は、それが参照する「アイテム」の存続期間を制御しない。さらに、参照関係は、ターゲットの存在も保証せず、関係宣言において指定されたターゲットの型も保証しない。このことは、参照関係が不安定な状態となり得ることを意味する。また、参照関係は、他のデータストア中の「アイテム」を参照することができる。参照関係は、ウェブページにおけるリンクに似た概念と見なすことができる。

参照関係宣言の例は、以下のようになる。

どの参照型も、ターゲットエンドポイントにおいて認められる。参照関係に関与する「アイテム」は、どの「アイテム」型でもよい。

参照関係は、「アイテム」の間のほとんどの非存続期間管理関係をモデル化するのに使われる。ターゲットの存在は強制ではないので、参照関係は、疎結合関係をモデル化するのに好都合である。参照関係は、他のコンピュータ上のストアを含む他のデータストア中の「アイテム」をターゲットにするのに使うことができる。

ｅ）規則および制約
以下の追加規則および制約が、関係に適用される。
・「アイテム」は、（ただ１つの埋込み関係）あるいは（１つまたは複数の保持関係）のターゲットでなければならない。ただ１つの例外は、ルート「アイテム」である。「アイテム」は、ゼロ以上の参照関係のターゲットとなり得る。
・埋込み関係のターゲットである「アイテム」は、保持関係のソースになることができない。参照関係のソースにはなり得る。
・「アイテム」は、ファイルからプロモートされる場合、保持関係のソースになることができない。埋込み関係および参照関係のソースにはなり得る。
・ファイルからプロモートされる「アイテム」は、埋込み関係のターゲットになることができない。

ｆ）関係の順序づけ
少なくとも一実施形態において、本発明のストレージプラットフォームは、関係の順序づけをサポートする。順序づけは、基本関係定義において、「Ｏｒｄｅｒ」という名前のプロパティにより遂行される。Ｏｒｄｅｒフィールドに対して、一意性に関する制約はない。同じ「順序」プロパティ値をもつ関係の順序は保証されないが、より低い「順序」値の関係の後、かつより高い「順序」フィールド値の関係の前に順序づけることができることが保証される。

アプリケーションは、組合せ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ、Ｏｒｄｅｒ）に基づいて順序づけることによって、関係をデフォルトの順序に並べることができる。所与の「アイテム」から発生したすべての関係インスタンスは、コレクション中の関係の型に関わらず、単一のコレクションとして順序づけられる。ただし、この順序づけは、所与のタイプのすべての関係（たとえば、ＦｏｌｄｅｒＭｅｍｂｅｒｓ）が、所与の「アイテム」に対する関係コレクションの順序つきサブセットであることを保証する。

関係を扱うデータストアＡＰＩ３１２は、関係の順序づけをサポートする１組の動作を実装する。動作の説明を助けるために、以下の用語が導入される。
・ＲｅｌＦｉｒｓｔは、順序値ＯｒｄＦｉｒｓｔをもつ、番号つきコレクション中の第１の関係である。
・ＲｅｌＬａｓｔは、順序値ＯｒｄＬａｓｔをもつ、番号つきコレクション中の最後の関係である。
・ＲｅｌＸは、順序値ＯｒｄＸをもつ、コレクション中の所与の関係である。
・ＲｅｌＰｒｅｖは、ＯｒｄＸより小さい順序値ＯｒｄＰｒｅｖをもつ、ＲｅｌＸに最も近いコレクション中の関係である。
・ＲｅｌＮｅｘｔは、ＯｒｄＸより大きい順序値ＯｒｄＮｅｘｔをもつ、ＲｅｌＸに最も近いコレクション中の関係である。

操作は、以下のものを含むが、それに限定されない。
・ＩｎｓｅｒｔＢｅｆｏｒｅＦｉｒｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ，Ｒｅｌａｔｉｏｎ）は、関係を、コレクション中の第１の関係として挿入する。新しい関係の「Ｏｒｄｅｒ」プロパティ値は、ＯｒｄＦｉｒｓｔより小さくてよい。
・ＩｎｓｅｒｔＡｆｔｅｒＬａｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ，Ｒｅｌａｔｉｏｎ）は、関係を、コレクション中の最後の関係として挿入する。新しい関係の「Ｏｒｄｅｒ」プロパティ値は、ＯｒｄＬａｓｔより大きくてよい。
・ＩｎｓｅｒｔＡｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，Ｒｅｌａｔｉｏｎ）は、「Ｏｒｄｅｒ」プロパティの指定された値をもつ関係を挿入する。
・ＩｎｓｅｒｔＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，Ｒｅｌａｔｉｏｎ）は、与えられた順序値をもつ関係の前に関係を挿入する。新しい関係には、ＯｒｄＰｒｅｖとｏｒｄの間であり、境界を含まない「Ｏｒｄｅｒ」値を割り当てることができる。
・ＩｎｓｅｒｔＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，Ｒｅｌａｔｉｏｎ）は、与えられた順序値をもつ関係の後に関係を挿入する。新しい関係には、ｏｒｄとＯｒｄＮｅｘｔの間であり、境界を含まない「Ｏｒｄｅｒ」値を割り当てることができる。
・ＭｏｖｅＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，ＲｅｌａｔｉｏｎｓｈｉｐＩＤ）は、与えられた関係ＩＤをもつ関係を、指定された「Ｏｒｄｅｒ」値をもつ関係の前に移動する。関係には、ＯｒｄＰｒｅｖとｏｒｄの間であり、境界を含まない新しい「Ｏｒｄｅｒ」値を割り当てることができる。
・ＭｏｖｅＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，ＲｅｌａｔｉｏｎｓｈｉｐＩＤ）は、与えられた関係ＩＤをもつ関係を、指定された「Ｏｒｄｅｒ」値をもつ関係の後に移動する。関係には、ｏｒｄとＯｒｄＮｅｘｔの間であり、境界を含まない新しい順序値を割り当てることができる。

上述したように、すべての「アイテム」は、「アイテムフォルダ」のメンバーでなければならない。「関係」に関して、すべての「アイテム」は、「アイテムフォルダ」との関係をもたなければならない。本発明のいくつかの実施形態では、特定の関係が、「アイテム」の間に存在する「関係」によって表される。

本発明の様々な実施形態のために実装されるように、「関係」は、ある「アイテム」（ソース）によって別の「アイテム」（ターゲット）に「拡張される」有向バイナリ関係を提供する。「関係」は、ソース「アイテム」（関係を拡張した「アイテム」）によって所有され、したがって、ソースが削除されると「関係」は削除される（たとえば、ソース「アイテム」が消去されると、「関係」は消去される）。さらに、特定の例において、「関係」は、ターゲット「アイテム」の所有権を共有する（共同所有する）ことができ、このような所有権は、「関係」のＩｓＯｗｎｅｄプロパティ（またはその等価物）に反映することができる（「関係」プロパティ型を示す図７に示すように）。こうした実施形態において、新しいＩｓＯｗｎｅｄ「関係」を作成すると、ターゲット「アイテム」に対する参照カウントが自動的に増分し、このような「関係」を消去すると、ターゲット「アイテム」に対する参照カウントが減分し得る。こうした具体的な実施形態の場合、「アイテム」は、参照カウントがゼロより大きい場合は存在し続け、カウントがゼロになると自動的に消去される。繰り返しになるが、「アイテムフォルダ」とは、他の「アイテム」との１組の「関係」をもつ（またはもつことができる）「アイテム」であり、こうした他の「アイテム」は、「アイテムフォルダ」の帰属関係を含む。「関係」の他の実際の実装形態も可能であり、本発明によって、本明細書において述べる機能を実現するものと予想される。

実際の実装形態に関わらず、「関係」とは、あるオブジェクトから別のオブジェクトへの、選択可能な接続である。「アイテム」が、複数の「アイテムフォルダ」、ならびに１つまたは複数の「カテゴリ」に属し得ること、ならびにこうした「アイテム」、「フォルダ」、および「カテゴリ」がパブリックであるか、それともプライベートであるかは、「アイテム」ベースの構造における、存在（または存在しないこと）に与えられた意味によって判定される。こうした論理「関係」は、物理的実装に関わらず、１組の「関係」に割り当てられる意味であり、特に本明細書において述べる機能を実現するために利用される。本質的に、「アイテムフォルダ」および「カテゴリ」は、それぞれ特殊な型の「アイテム」なので、論理関係は、「アイテム」とその「アイテムフォルダ（群）」または「カテゴリ」との間（かつその反対）に確立される。その結果、「アイテムフォルダ」および「カテゴリ」は、他のどの「アイテム」とも同じような作用を受けることができる。すなわち、コピーされ、ｅメールメッセージに追加され、ドキュメントに組み込まれるが、それに限らない。また、「アイテムフォルダ」および「カテゴリ」は、他の「アイテム」の場合と同じ機構を用いて、シリアライズしデシリアライズする（インポートしエクスポートする）ことができる。（たとえば、ＸＭＬでは、すべての「アイテム」は、シリアライゼーション形式をもつことができ、この形式は、「アイテムフォルダ」、「カテゴリ」、および「アイテム」に等しく適用される）。

「アイテム」とその「アイテムフォルダ（群）」の間の関係を表す、上述した「関係」は、「アイテム」から「アイテムフォルダ」に、「アイテムフォルダ」から「アイテム」に、またはその両方向に論理的に拡張することができる。「アイテム」から「アイテムフォルダ」に論理的に拡張する「関係」は、「アイテムフォルダ」が、その「アイテム」にとってパブリックであり、その帰属関係情報をその「アイテム」と共有することを示す。逆に、「アイテム」から「アイテムフォルダ」への論理「関係」がないことは、「アイテムフォルダ」が、その「アイテム」にとってプライベートであり、その帰属関係情報をその「アイテム」と共有しないことを示す。同様に、「アイテムフォルダ」から「アイテム」に論理的に拡張する「関係」は、「アイテム」がパブリックであり、「そのアイテムフォルダ」にとって共有可能であることを示し、「アイテムフォルダ」から「アイテム」への論理「関係」がないことは、「アイテム」がプライベートであり、共有不可能であることを示す。その結果、「アイテムフォルダ」は、別のシステムにエクスポートされると、新しいコンテキストにおいて共有される「パブリック」な「アイテム」になり、「アイテム」は、他の共有可能「アイテム」を求めてその「アイテムフォルダ」を検索するとき、そこに属す共有可能「アイテム」に関する情報を「アイテム」に提供する、「パブリック」な「アイテムフォルダ」である。

図９は、「アイテムフォルダ」（これ自体もアイテムである）、そのメンバー「アイテム」、および「アイテムフォルダ」とそのメンバー「アイテム」の間の相互接続の「関係」を示すブロック図である。「アイテムフォルダ」９００は、メンバーとして、複数の「アイテム」９０２、９０４、および９０６をもつ。「アイテムフォルダ」９００は、「アイテム」９０２がパブリックであるとともに「アイテムフォルダ」９００、そのメンバー９０４および９０６、ならびに「アイテムフォルダ」９００にアクセスし得る他のその「アイテムフォルダ」、「カテゴリ」、または「アイテム」（図示せず）にとっても共有可能であることを示す、「アイテムフォルダ」９００から「アイテム」９０２への「関係」９１２を有する。しかし、「アイテム」９０２から「アイテムフォルダ」９００への「関係」は存在せず、このことは、「アイテムフォルダ」９００が「アイテム」９０２にとってプライベートであるとともにその帰属関係情報を「アイテム」９０２と共有しないことを示す。一方、「アイテム」９０４は、「アイテムフォルダ」９００がパブリックであるとともにその帰属関係情報を「アイテム」９０４と共有することを示す、「アイテム」９０４から「アイテムフォルダ」９００への「関係」９２４を有する。しかし、「アイテムフォルダ」９００から「アイテム」９０４への関係が存在せず、このことは、「アイテム」９０４がプライベートであるとともに「アイテムフォルダ」９００、フォルダの他のメンバー９０２および９０６、ならびに「アイテムフォルダ」９００にアクセスし得る他のどのアイテムフォルダ、カテゴリ、またはアイテム（図示せず）にとっても共有可能でないことを示す。「アイテム」９０２および９０４への関係（または関係が存在しないこと）とは対照的に、「アイテムフォルダ」９００は、「アイテムフォルダ」９００から「アイテム」９０６への「関係」９１６をもち、「アイテム」９０６は、逆に「アイテムフォルダ」９００への「関係」９２６をもち、この２つの関係は共同で、「アイテム」９０６がパブリックであるとともに「アイテムフォルダ」９００、フォルダのメンバー９０２および９０４、ならびに「アイテムフォルダ」９００にアクセスし得る他のどのアイテムフォルダ、カテゴリ、またはアイテム（図示せず）にとっても共有可能であること、また、「アイテムフォルダ」９００がパブリックであるとともにその帰属関係情報を「アイテム」９０６と共有することを示す。

上述したように、「アイテムフォルダ」が「記述されない」ので、「アイテムフォルダ」中の「アイテム」は、共通性を共有する必要がない。一方、カテゴリは、そのメンバー「アイテム」すべてに共通する共通性によって記述される。その結果、「カテゴリ」の帰属関係は、本質的に、記述された共通性をもつ「アイテム」に限定され、特定の実施形態では、「カテゴリ」の記述を満たすすべての「アイテム」が、自動的に「カテゴリ」のメンバーにされる。したがって、「アイテムフォルダ」は、単純な型構造がその帰属関係によって表されることを可能にし、「カテゴリ」は、定義された共通性に基づく帰属関係を可能にする。

当然ながら、「カテゴリ」記述は本質的に論理的であり、したがって、「カテゴリ」は、型、プロパティ、および／または値のどの論理表現によっても記述することができる。たとえば、「カテゴリ」の論理表現は、２つのプロパティの一方または両方をもつ「アイテム」を備えるように、その帰属関係でよい。「カテゴリ」のこうした記述プロパティが、「Ａ」および「Ｂ」の場合、「カテゴリ」帰属関係は、プロパティＡをもつがＢをもたない「アイテム」、プロパティＢをもつがＡをもたない「アイテム」、ならびプロパティＡおよびＢ両方をもつ「アイテム」を含み得る。プロパティのこの論理表現は、論理演算子「ＯＲ」によって記述され、この場合、「カテゴリ」によって記述されるメンバーの組は、プロパティＡ ＯＲ Ｂをもつ「アイテム」である。同様の論理素子（限定ではなく、「ＡＮＤ」、「ＸＯＲ」、および「ＮＯＴ」のみ、またはこれらの組合せを含む）も、カテゴリを記述するのに使うことができることが、当業者には理解されよう。

「アイテムフォルダ」（記述されない）とカテゴリ（記述される）の間の区別に関わらず、「アイテム」との「カテゴリ関係」および「カテゴリ」との「アイテム関係」は、本発明の多くの実施形態において、「アイテムフォルダ」および「アイテム」に対して本明細書において開示したものと本質的に同じである。

図１０は、「カテゴリ」（これ自体も「アイテム」である）、そのメンバー「アイテム」、および「カテゴリ」とそのメンバー「アイテム」の間の相互接続の「関係」を示すブロック図である。「カテゴリ」１０００は、メンバーとして、複数の「アイテム」１００２、１００４、および１００６をもち、こうしたアイテムはすべて、「カテゴリ」１０００によって記述されるように（共通性記述１００８’）、共通プロパティ、値、または型１００８の何らかの組合せを共有する。「カテゴリ」１０００は、「アイテム」１００２がパブリックであるとともに「カテゴリ」１０００、そのメンバー１００４および１００６、ならびに「カテゴリ」１０００にアクセスし得る他のその「カテゴリ」、「アイテムフォルダ」、または「アイテム」（図示せず）にとっても共有可能であることを示す、「カテゴリ」１０００から「アイテム」１００２への「関係」１０１２を有する。しかし、「アイテム」１００２から「カテゴリ」１０００への「関係」は存在せず、このことは、「カテゴリ」１０００が「アイテム」１００２にとってプライベートであるとともにその帰属関係情報を「アイテム」１００２と共有しないことを示す。一方、「アイテム」１００４は、「カテゴリ」１０００がパブリックであるとともにその帰属関係情報を「アイテム」１００４と共有することを示す、「アイテム」１００４から「カテゴリ」１０００への「関係」１０２４を有する。しかし、「カテゴリ」１０００から「アイテム」１００４に拡張された関係が存在せず、このことは、「アイテム」１００４がプライベートであるとともに「カテゴリ」１０００、フォルダの他のメンバー１００２および１００６、ならびに「カテゴリ」１０００にアクセスし得る他のどのカテゴリ、アイテムフォルダ、またはアイテム（図示せず）にとっても共有可能でないことを示す。「アイテム」１００２および１００４への関係（または関係が存在しないこと）とは対照的に、「カテゴリ」１０００は、「カテゴリ」１０００から「アイテム」１００６への「関係」１０１６をもち、「アイテム」１００６は、逆に「カテゴリ」１０００への「関係」１０２６をもち、この２つの関係は共同で、「アイテム」１００６がパブリックであるとともに「カテゴリ」１０００、フォルダの「項目」メンバー１００２および１００４、ならびに「カテゴリ」１０００にアクセスし得る他のどのカテゴリ、アイテムフォルダ、またはアイテム（図示せず）にとっても共有可能であること、また、「カテゴリ」１０００がパブリックであるとともにその帰属関係情報を「アイテム」１００６と共有することを示す。

最後に、「カテゴリ」および「アイテムフォルダ」は、それ自体が「アイテム」であり、「アイテム」同士は、互いとの「関係」をもつことができ、「カテゴリ」は、「アイテムフォルダ」との、かつその反対の「関係」をもつことができるので、「カテゴリ」、「アイテムフォルダ」、および「アイテム」は、特定の代替実施形態において、それぞれ他の「カテゴリ」、「アイテムフォルダ」、および「アイテム」との「関係」をもつことができる。しかし、様々な実施形態において、「アイテムフォルダ」構造および／または「カテゴリ」構造は、ハードウェア／ソフトウェアインターフェイスシステムレベルにおいて、サイクルを含むことを禁止される。「アイテムフォルダ」および「カテゴリ」構造が有向グラフと類似している場合、サイクルを禁止する実施形態は、グラフ理論分野での数学的定義によって、どのパスも同じ頂点で開始し終了しない有向グラフである有向非循環グラフ（ＤＡＧ）と類似している。

６． 拡張性
ストレージプラットフォームは、上述したように、スキーマ３４０の初期セットとともに提供されることを意図している。ただし、少なくともいくつかの実施形態では、ストレージプラットフォームはさらに、独立ソフトウェアベンダ（ＩＳＶ）を含む顧客が、新しいスキーマ３４４（すなわち新しい「アイテム」および「ネスト要素」型）を作成することを可能にする。このセクションでは、スキーマ３４０の初期セット中で定義される「アイテム」型および「ネスト要素」型（または単に「要素」型）を拡張することによって、このようなスキーマを作成する機構を扱う。

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

ストレージプラットフォームスキーマの初期セットによって定義される「アイテム」型または「ネスト要素」型は、ＩＳＶアプリケーションの要求と正確には合致し得ないので、ＩＳＶに、型をカスタマイズさせることが必要である。カスタマイズは、「拡張」概念を用いて認められる。拡張は、厳密に型指定されたインスタンスであるが、（ａ）それぞれ独立に存在することができず、（ｂ）「アイテム」または「ネスト要素」に付加されなければならない。

スキーマ拡張性の必要性への対処に加えて、拡張は、「多重型指定」問題への対処も意図している。いくつかの実施形態では、ストレージプラットフォームは、多数の継承も重複するサブ型もサポートすることができないので、アプリケーションは、重複型のインスタンス（たとえば「ドキュメント」は、法的文書ならびに保管文書である）をモデル化する方法として、「拡張」を使うことができる。

ａ）アイテムの拡張
「アイテム」の拡張性をもたらすために、データモデルは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎという名前の抽象型をさらに定義する。この抽象型は、拡張型の階層に対するルート型である。アプリケーションは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎをサブ型指定して、具体的な拡張型を作成することができる。

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

ＩｔｅｍＩＤフィールドは、拡張が関連づけられるアイテムのＩｔｅｍＩＤを含む。このＩｔｅｍＩＤをもつ「アイテム」が存在しなければならない。与えられたＩｔｅｍＩＤをもつアイテムが存在しない場合、拡張を作成することができない。「アイテム」が消去されると、同じＩｔｅｍＩＤをもつ拡張すべてが消去される。タプル（ＩｔｅｍＩＤ，ＥｘｔｅｎｓｉｏｎＩＤ）は、拡張インスタンスを一意に識別する。

拡張型の構造は、アイテム型の構造に類似している。
・拡張型は、フィールドを有する
・フィールドは、基本要素でも、ネスト要素型でもよい
・拡張型は、サブ型指定することができる。

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

所与の「アイテム」型に関連づけることができる拡張の型に対する制約はない。どの拡張型も、あらゆるアイテム型を拡張することができる。複数の拡張インスタンスがアイテムに付加されるとき、こうしたインスタンスは、構造およびビヘイビア両方において互いに独立している。

拡張インスタンスは、アイテムとは別々に格納されアクセスされる。すべての拡張型インスタンスは、グローバル拡張ビューからアクセス可能である。どのような型のアイテムにインスタンスが関連づけられているかに関わらず、拡張の所与の型のインスタンスすべてを返す効率的なクエリを組み立てることができる。ストレージプラットフォームＡＰＩは、アイテムに対する拡張を格納し、取得し、修正することができるプログラミングモデルを提供する。

拡張型は、ストレージプラットフォームの単一の継承モデルを使ってサブ型指定された型でよい。拡張型からの派生によって、新しい拡張型が作成される。拡張の構造またはビヘイビアは、アイテム型階層の構造またはビヘイビアをオーバーライドすることも置き換えることもできない。「アイテム」型と同様、「拡張」型インスタンスは、拡張型に関連づけられたビューを通して直接アクセスすることができる。拡張のＩｔｅｍＩＤは、どのアイテムに属すのかを示し、グローバル「アイテム」ビューから、対応する「アイテム」オブジェクトを取得するのに使うことができる。拡張は、動作の一貫性のためにアイテムの一部と見なされる。ストレージプラットフォームが定義するコピー／移動、バックアップ／復元、および他の共通操作は、アイテムの一部として拡張に作用し得る。

以下の例を考えてみる。Ｃｏｎｔａｃｔ型は、Ｗｉｎｄｏｗｓ（登録商標）型セットにおいて定義される。

ＣＲＭアプリケーション開発者は、ストレージプラットフォームに格納されている連絡先にＣＲＭアプリケーション拡張を付加することを望む。アプリケーション開発者は、アプリケーションが操作し得る追加データ構造を含むＣＲＭ拡張を定義する。

ＨＲアプリケーション開発者は、Ｃｏｎｔａｃｔを使って追加データを付加することも望む場合がある。このデータは、ＣＲＭアプリケーションデータから独立している。やはり、アプリケーション開発者は、拡張を作成することができる。

ＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは、Ｃｏｎｔａｃｔアイテムに付加することができる独立した２つの拡張である。こうした拡張は、それぞれ独立に作成されアクセスされる。

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

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

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

以下のテーブルは、「アイテム」、「拡張」、およびＮｅｓｔｅｄＥｌｅｍｅｎｔ型の間の類似点および相違点を要約する。

ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔ型の拡張
「ネスト要素」型は、「アイテム」型と同じ機構を使って拡張されない。ネスト要素の拡張は、ネスト要素型のフィールドと同じ機構を使って格納されアクセスされる。

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

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

ＮｅｓｔｅｄＥｌｅｍｅｎｔの拡張は、アイテムの拡張と以下の点で異なる。
・ネスト要素の拡張は、拡張型ではない。Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎ型をルートとする拡張型階層に属さない。
・ネスト要素の拡張は、アイテムの他のフィールドとともに格納され、全域的にはアクセス可能でない。すなわち、所与の拡張型のすべてのインスタンスを取得するクエリを組み立てることができない。
・ネスト要素の拡張は、（アイテムの）他のネスト要素の格納と同じやり方で格納される。他のネストされた組のように、ＮｅｓｔｅｄＥｌｅｍｅｎｔの拡張は、ＵＤＴに格納される。ネスト要素型の「拡張」フィールドを通してアクセス可能である。
・多値プロパティにアクセスするのに使われるコレクションインターフェイスは、拡張型の組のアクセスおよび反復にも使われる。

以下のテーブルは、「アイテムの拡張」およびＮｅｓｔｅｄＥｌｅｍｅｎｔの拡張を要約し比較する。

Ｆ． データベースエンジン
上述したように、データストアは、データベースエンジン上に実装される。本実施形態において、データベースエンジンは、オブジェクトリレーショナル拡張を有するＭｉｃｒｏｓｏｆｔ ＳＱＬサーバエンジンなどのＳＱＬ照会言語を実装するリレーショナルデータベースエンジンを備える。このセクションでは、本実施形態に従って、データストアがリレーショナルストアに対して実装し、ストレージプラットフォームクライアントによって消費される論理的ＡＰＩについての情報を提供する、データモデルのマッピングについて述べる。ただし、異なるデータベースエンジンが利用される場合は、異なるマッピングを利用できることが理解されよう。実際、ストレージプラットフォームの概念的なデータモデルをリレーショナルデータベースエンジン上に実装することに加えて、データモデルは、他の型のデータベース、たとえばオブジェクト指向およびＸＭＬデータベースに実装することもできる。

オブジェクト指向（ＯＯ）データベースシステムは、プログラミング言語オブジェクト（たとえばＣ＋＋、Ｊａｖａ（登録商標））に対して永続性およびトランザクションを提供する。「アイテム」というストレージプラットフォーム概念は、オブジェクト指向システムにおける「オブジェクト」に対応するが、「オブジェクト」には埋込みコレクションが追加されなければならない。他のストレージプラットフォーム型概念は、継承およびネスト要素型のように、オブジェクト指向型システムもマップする。オブジェクト指向システムは一般に、オブジェクトの識別を既にサポートしている。したがって、アイテム識別は、オブジェクト識別にマップすることができる。アイテムのビヘイビア（動作）は、オブジェクトメソッドに対応する。ただし、オブジェクト指向システムは一般に、組織化性能が欠けており、検索性能が乏しい。また、オブジェクト指向システムは、未構造および半構造のデータをサポートしない。本明細書において述べる完全なストレージプラットフォームデータモデルをサポートするために、関係、フォルダ、および拡張のような概念を、オブジェクトデータモデルに追加することが必要になる。さらに、昇格、同期、通知、およびセキュリティのような機構を実装することが必要になる。

オブジェクト指向システムと同様、ＸＭＬデータベースは、ＸＳＤ（ＸＭＬスキーマ定義）に基づいて、単一継承に基づく型システムをサポートする。本発明のアイテム型システムは、ＸＳＤ型モデルにマップすることができよう。ＸＳＤも、ビヘイビアをサポートしない。アイテム用のＸＳＤは、アイテムのビヘイビアで補われなければならない。ＸＭＬデータベースは、単一のＸＳＤドキュメントを扱い、編集および広範な検索性能をもっていない。本明細書において記述されるデータモデルをサポートするためのオブジェクト指向データベースと同様に、関係およびフォルダのような他の概念を、このようなＸＭＬデータベースに組み込むことが必要になる。また、同期、通知、およびセキュリティのような機構は、実装する必要がなくなる。

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

１． ＵＤＴを用いたデータストアの実装
一実施形態ではＭｉｃｒｏｓｏｆｔ ＳＱＬサーバエンジンを備えるリレーショナルデータベースエンジン３１４は、本実施形態において、内蔵スカラー型をサポートする。内蔵スカラー型は、「固有」かつ「単純」である。内蔵スカラー型は、ユーザが独自の型を定義することができないという意味で固有であり、複合構造をカプセル化することができないという点で単純である。ユーザ定義型（以下、ＵＤＴ）は、ユーザが複合構造型を定義することによって型システムを拡張できるようにすることによって、固有スカラー型システムを超えた、型の拡張性のための機構を提供する。ユーザによって定義されると、ＵＤＴは、内蔵スカラー型を使うことができる型システムのどこでも使うことができる。

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

ＵＤＴは、ＣＬＲクラスであり、状態（すなわち、データフィールド）およびビヘイビア（すなわち、ルーチン）をもつ。ＵＤＴは、管理言語、すなわち、Ｃ#、ＶＢ．ＮＥＴなどのどれを使っても定義される。ＵＤＴメソッドおよび演算子は、Ｔ−ＳＱＬにおいて、その型のインスタンスに対して呼び出すことができる。ＵＤＴは、行の中の列の型、Ｔ−ＳＱＬにおけるルーチンのパラメータの型、またはＴ−ＳＱＬにおける変数の型でよい。

ＵＤＴクラスへのストレージプラットフォームスキーマのマッピングは、高度なレベルでかなり明快である。概して、ストレージプラットフォームスキーマは、ＣＬＲ名前空間にマップされる。ストレージプラットフォーム型は、ＣＬＲクラスにマップされる。ＣＬＲクラスの継承は、ストレージプラットフォーム型継承を反映し、ストレージプラットフォームプロパティは、ＣＬＲクラスプロパティにマップされる。

２． アイテムのマッピング
「アイテム」が全域的に検索可能であること、および本実施形態のリレーショナルデータベースにおける継承および型の代用可能性のサポートが望ましいので、データベースストアでの「アイテム」記憶の可能な一実装形態は、Ｂａｓｅ．Ｉｔｅｍ型の列をもつ１個のテーブルにすべての「アイテム」を格納することであろう。型の代用可能性を用いると、すべての型の「アイテム」を格納することができ、Ｙｕｋｏｎの「ｉｓ ｏｆ（Ｔｙｐｅ）」演算子を使って、「アイテム」型およびサブ型によって検索をフィルタリングすることができよう。

ただし、オーバーヘッドに関連づけられたこのような手法に関わる問題のせいで、本実施形態において、「アイテム」は、各型「ファミリ」の「アイテム」が別々のテーブルに格納されるように、最上位レベル型によって分けられる。この分割方式の下で、Ｂａｓｅ．Ｉｔｅｍから直接継承を行う各「アイテム」型ごとにテーブルが作成される。下位型から継承を行う型は、上述したように型の代用可能性を使って、適切な型ファミリテーブルに格納される。Ｂａｓｅ．Ｉｔｅｍからの第１レベルの継承のみが特別な扱いを受ける。

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

好都合なアクセスと、実装の詳細を可能な限り隠すために、「アイテム」のすべてのクエリは、上述した「アイテム」テーブルの上に構築されたビューに対するものでよい。具体的には、ビューは、各「アイテム」型ごとに、適切な型ファミリテーブルに対して作成することができる。こうした型のビューは、サブ型を含む、関連づけられた型のすべての「アイテム」を選択することができる。便宜上、ＵＤＴオブジェクトに加えて、ビューは、継承フィールドを含む、その型の最上位レベルフィールドすべてに対して、列を公開することができる。

３． 拡張のマッピング
拡張は、「アイテム」と非常に似ており、同じ要件をいくつか有する。継承をサポートする別のルート型として、「拡張」は、記憶における同じ検討事項およびトレードオフの多くの対象である。このため、単一テーブル手法ではなく、型の同様のファミリマッピングが、「拡張」に適用される。当然ながら、他の実施形態では、単一テーブル手法を使うことができる。本実施形態において、「拡張」は、ＩｔｅｍＩＤによってただ１つの「アイテム」に関連づけられ、「アイテム」というコンテキストにおいて一意である拡張ＩＤを含む。「アイテム」の場合と同様、ＩｔｅｍＩＤおよび拡張ＩＤのペアからなる識別を与えられると、「拡張」を取得するための関数を提供することができる。「アイテム」型ビューと同様、各「拡張」型ごとにビューが作成される。

４． ネスト要素のマッピング
ネスト要素は、「アイテム」、「拡張」、「関係」、または他の「ネスト要素」に組み込まれて、深くネストされた構造を形成することができる型である。「ネスト要素」は、「アイテム」および「拡張」のように、ＵＤＴとして実装されるが、「アイテム」および「拡張」に格納される。したがって、「ネスト要素」は、要素の「アイテム」および「拡張」コンテナのマッピングを超える記憶マッピングをもたない。言い換えると、ＮｅｓｔｅｄＥｌｅｍｅｎｔ型のインスタンスを直接格納するテーブルがシステムにはなく、特に「ネスト要素」に専用のビューもない。

５． オブジェクトの識別
データモデルにおける各エンティティ、すなわち、各「アイテム」、「拡張」、および「関係」は、一意なキーの値をもつ。「アイテム」は、そのＩｔｅｍＩｄによって一意に識別される。「拡張」は、（ＩｔｅｍＩｄ，ＥｘｔｅｎｓｉｏｎＩｄ）からなる複合キーによって一意に識別される。「関係」は、複合キー（Ｉｔｅｍｌｄ，ＲｅｌａｔｉｏｎｓｈｉｐＩｄ）によって識別される。ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ、およびＲｅｌａｔｉｏｎｓｈｉｐＩｄは、ＧＵＩＤ値である。

６． ＳＱＬオブジェクトの命名
データストア中で作成されるすべてのオブジェクトは、ストレージプラットフォームのスキーマ名から派生されるＳＱＬスキーマ名に格納することができる。たとえば、ストレージプラットフォームの「基本」スキーマ（しばしば、「Ｂａｓｅ」と呼ばれる）は、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．Ｉｔｅｍ」などの「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］」ＳＱＬスキーマ中で型を生じることができる。生成された名称は、命名の競合を排除するために、先頭に限定子をつけられる。そうすることが適切な場合、感嘆符（！）が、名称の論理的な各部分の区切り文字として使われる。以下のテーブルは、データストア中のオブジェクト用に使われる命名規則をまとめたものである。各スキーマ要素（「アイテム」、「拡張」、「関係」、および「ビュー」）、が、データストア中のインスタンスにアクセスするのに使われる装飾つき命名規則とともに列挙されている。

７． 列の命名
どのオブジェクトモデルをストア中にマッピングするときも、アプリケーションオブジェクトとともに格納される付加情報に起因する命名衝突が起こる可能性がある。命名衝突を避けるために、型固有でないすべての列（型宣言において、名前つきプロパティに直接マップしない列）は、先頭に下線（＿）文字をつけられる。本実施形態において、下線（＿）文字は、どの識別子プロパティの先頭文字としても認められない。さらに、ＣＬＲとデータストアの間で命名を統一するために、ストレージプラットフォーム型またはスキーマ要素（関係など）のすべてのプロパティは、先頭の文字を大文字にするべきである。

８． 検索ビュー
格納されている内容を検索するビューが、ストレージプラットフォームによって提供される。各「アイテム」および「拡張」型ごとに、ＳＱＬビューが提供される。さらに、ビューは、（データモデルによって定義される）「関係」および「ビュー」をサポートするように提供される。ストレージプラットフォーム中のすべてのＳＱＬビューおよび基底テーブルは、読取り専用である。データは、後で詳細に説明するように、ストレージプラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドを使って格納することも変更することもできる。

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

ストレージプラットフォームデータストア中のすべてのＳＱＬ検索ビューは、列に対して以下の順序づけ規則を使う。

・ＩｔｅｍＩｄ、ＥｌｅｍｅｎｔＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄなど、ビュー結果の論理的「キー」列（群）
・ＴｙｐｅＩｄなどの結果の型についてのメタデータ情報
・ＣｒｅａｔｅＶｅｒｓｉｏｎ、ＵｐｄａｔｅＶｅｒｓｉｏｎなどの変更追跡列
・型特有の列（群）（宣言される型のプロパティ）
・型特有のビュー（ファミリビュー）は、オブジェクトを返すオブジェクト列も含む
各型ファミリのメンバーは、一連の「アイテム」ビューを使って検索可能であり、データストアには、「アイテム」型ごとに１つのビューがある。図２８は、「アイテム」検索ビューの概念を示す図である。

ａ）アイテム
各「アイテム」検索ビューは、具体的な型またはそのサブ型の「アイテム」の各インスタンス用の行を含む。たとえば、「ドキュメント」用ビューは、ドキュメント、ＬｅｇａｌＤｏｃｕｍｅｎｔおよびＲｅｖｉｅｗＤｏｃｕｍｅｎｔのインスタンスを返し得る。この例を前提として、「アイテム」ビューは、図２９に示すように概念化することができる。

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

（２）型指定アイテム検索ビュー
各「アイテム」型は、検索ビューも有する。ルート「アイテム」ビューと似ているが、このビューは、「＿Ｉｔｅｍ」列を通して、「アイテム」オブジェクトへのアクセスも提供する。各型指定アイテム検索ビューは、［ｓｃｈｅｍａＮａｍｅ］．［ｉｔｅｍＴｙｐｅＮａｍｅ］という名称を使って、データストア中で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［ＯｆｆｉｃｅＤｏｃ］である。

ｂ）アイテムの拡張
ＷｉｎＦＳストアにおけるすべてのアイテムの拡張は、検索ビューを使ってもアクセス可能である。

（１）マスタ拡張検索ビュー
データストアの各インスタンスは、「マスタ拡張ビュー」と呼ばれる特殊な「拡張」ビューを定義する。このビューは、データストア中の各「拡張」についての要約情報を提供する。このビューは、「拡張」プロパティごとに、「拡張」の型を記述する列を一列と、変更追跡および同期情報の提供に使われるいくつかの列とを有する。マスタ拡張ビューは、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｅｘｔｅｎｓｉｏｎ］」という名称を使って、データストア中で識別される。

（２）型指定拡張検索ビュー
各「拡張」型は、検索ビューも有する。マスタ拡張ビューと似ているが、このビューは、「＿Ｅｘｔｅｎｓｉｏｎ」列を通して、「アイテム」オブジェクトへのアクセスも提供する。各型指定拡張検索ビューは、［ｓｃｈｅｍａＮａｍｅ］．［Ｅｘｔｅｎｓｉｏｎ！ｅｘｔｅｎｓｉｏｎＴｙｐｅＮａｍｅ］という名称を使って、データストア中で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｅｘｔｅｎｓｉｏｎ！ＯｆｆｉｃｅＤｏｃＥｘｔ］である。

ｃ）ネスト要素
すべてのネスト要素は、「アイテム」、「拡張」、または「関係」インスタンスに格納される。このようなものとして、ネスト要素は、適切な「アイテム」、「拡張」、または「関係」検索ビューを照会することによってアクセスされる。

ｄ）関係
上述したように、「関係」は、ストレージプラットフォームデータストア中で「アイテム」の間をリンクする基本的な単位を形成する。

（１）マスタ関係検索ビュー
各データストアは、「マスタ関係ビュー」を提供する。このビューは、データストア中のすべての関係インスタンスについての情報を提供する。マスタ関係ビューは、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｒｅｌａｔｉｏｎｓｈｉｐ］」という名称を使って、データストア中で識別される。

（２）関係インスタンス検索ビュー
各宣言「関係」は、具体的な関係のすべてのインスタンスを返す検索ビューも有する。マスタ関係ビューと似ているが、このビューは、関係データの各プロパティごとに、名前付きの列も提供する。各関係インスタンス検索ビューは、［ｓｃｈｅｍａＮａｍｅ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ｒｅｌａｔｉｏｎｓｈｉｐＮａｍｅ］という名称を使って、データストア中で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ］である。

ｅ）
９． アップデート
ストレージプラットフォームデータストア中のすべてのビューは、読取り専用である。データモデル要素の（アイテム、拡張、または関係）の新しいインスタンスを作成し、あるいは既存のインスタンスをアップデートするために、ストレージプラットフォームＡＰＩのＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎまたはＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドを使わなければならない。ＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎメソッドは、実施されるアクションを詳述する「動作」を消費するデータストアによって定義される、格納されている単一の手順である。ＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドは、実施される１組のアクションを全体として詳述する「ｕｐｄａｔｅｇｒａｍ」として知られる、順序づけられた１組の動作を行う、格納されている手順である。

動作形式は、拡張可能であり、スキーマ要素に対する様々な動作を提供する。いくつかの共通動作は、以下のものを含む。

１． アイテム動作
ａ． ＣｒｅａｔｅＩｔｅｍ（埋込みまたは保持関係のコンテキストにおいて、新しいアイテムを作成する）
ｂ． ＵｐｄａｔｅＩｔｅｍ（既存の「アイテム」をアップデートする）
２． 関係動作：
ａ． ＣｒｅａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（参照または保持関係のインスタンスを作成する）
ｂ． ＵｐｄａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（関係インスタンスをアップデートする）
ｃ． ＤｅｌｅｔｅＲｅｌａｔｉｏｎｓｈｉｐ（関係インスタンスを削除する）
３． 拡張動作：
ａ． ＣｒｅａｔｅＥｘｔｅｎｓｉｏｎ（既存の「アイテム」に拡張を追加する）
ｂ． ＵｐｄａｔｅＥｘｔｅｎｓｉｏｎ（既存の拡張をアップデートする）
ｃ． ＤｅｌｅｔｅＥｘｔｅｎｓｉｏｎ（拡張を消去する）
１０． 変更追跡および削除標識
変更追跡および削除標識サービスは、後でより詳しく論じるように、データストアによって提供される。このセクションでは、データストア中で公開される変更追跡情報の概要を述べる。

ａ）変更追跡
データストアによって提供される各検索ビューは、変更追跡情報を提供するのに使われる列を含む。こうした列は、すべての「アイテム」、「拡張」、および「関係」ビューにわたって共通である。スキーマ設計者によって明示的に定義されるストレージプラットフォーム「スキーマビュー」は、変更追跡情報を自動的には提供しない。このような情報は、ビュー自体が構築されている検索ビューを介して間接的に提供される。

データストア中の各要素に対して、変更追跡情報は、「マスタ」要素ビューおよび「型指定」要素ビューという２つの場所から利用可能である。たとえば、ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ．Ｄｏｃｕｍｅｎｔという「アイテム」型についての変更追跡情報は、「マスタアイテムビュー」「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」および型指定「アイテム」検索ビュー［ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ］．［Ｄｏｃｕｍｅｎｔ］から利用可能である。

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

こうしたプロパティは、以下の情報を含む。

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

ｂ）削除標識
データストアは、「アイテム」、「拡張」、および「関係」を提供する。削除標識ビューは、活きている、および削除標識を立てられたエンティティ（アイテム、拡張、および関係）両方に対する削除標識情報を一箇所で提供する。アイテムおよび拡張削除標識ビューは、対応するオブジェクトへのアクセスを提供しないが、関係削除標識ビューは、関係オブジェクト（関係オブジェクトは、削除標識を立てられた関係の場合はＮＵＬＬである）へのアクセスを提供する。

（１）アイテム削除標識
アイテム削除標識は、ビュー［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｉｔｅｍ］を通してシステムから取得される。

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

（３）関係削除標識
関係削除標識は、ビュー［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｒｅｌａｔｉｏｎｓｈｉｐ］を介してシステムから取得される。関係削除標識情報は、「拡張」に提供されるものと似ている。ただし、関係インスタンスのターゲットＩｔｅｍＲｅｆについての付加情報が提供される。さらに、関係オブジェクトも選択される。

（４）削除標識のクリーンアップ
削除標識情報が際限なく増加するのを防止するために、データストアは、削除標識クリーンアップタスクを提供する。このタスクは、削除標識情報を破棄してもよいときを判定する。タスクは、ローカルな作成／アップデートバージョンに対する限界を計算し、次いで、すべての以前の削除標識バージョンを破棄することによって、削除標識情報を切り捨てる。

１１． ヘルパＡＰＩおよび関数
基底マッピングは、いくつかのヘルパ関数も提供する。こうした関数は、データモデルに対する共通動作を補助するために供給される。

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

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

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

１２． メタデータ
インスタンスメタデータ（「アイテム」の型など）、および型メタデータという２つの型のメタデータが、「ストア」中で表される。

ａ）スキーマメタデータ
スキーマメタデータは、「メタ」スキーマからの「アイテム」型のインスタンスとしてデータストアに格納される。

ｂ）インスタンスメタデータ
インスタンスメタデータは、アプリケーションによって、「アイテム」の型を照会するのに使われ、「アイテム」に関連づけられた拡張を見つける。「アイテム」に対するＩｔｅｍＩｄを与えられると、アプリケーションは、グローバルアイテムビューを照会して「アイテム」の型を返し、この値を使ってＭｅｔａ．Ｔｙｐｅビューを照会して、「アイテム」の宣言された型についての情報を返すことができる。以下に例を挙げる。

Ｇ． セキュリティ
概して、すべての安全であり得るオブジェクトは、そのアクセス権を、図２６に示すアクセスマスク形式を使って配列する。この形式において、下位１６ビットは、オブジェクト固有のアクセス権用であり、次の７ビットは、ほとんどの型のオブジェクトに適用される標準アクセス権であり、４上位ビットは、各オブジェクト型が１組の標準およびオブジェクト固有の権利にマップし得る汎用アクセス権を指定するのに使われる。ＡＣＣＥＳＳ＿ＳＹＳＴＥＭ＿Ｓｅｃｕｒｉｔｙビットは、オブジェクトのＳＡＣＬにアクセスするための権利に対応する。

図２６のアクセスマスク構造において、アイテム特有の権利は、「オブジェクト固有の権利」セクション（下位１６ビット）に置かれる。本実施形態において、ストレージプラットフォームは、セキュリティを管理するための２組のＡＰＩ、すなわちＷｉｎ３２およびストレージプラットフォームＡＰＩを公開するので、ストレージプラットフォームオブジェクト固有の権利の設計を促すために、ファイルシステムオブジェクト固有の権利が考慮されなければならない。

本発明のストレージプラットフォーム用のセキュリティモデルは、上記参照によって本明細書に組み込まれている関連出願において詳しく述べてある。この点に関して、図２７（パートａ、ｂ、およびｃ）は、セキュリティモデルの一実施形態による、既存のセキュリティ領域から切り離された、独立して保護されている新しいセキュリティ領域を示すを示す。

Ｈ． 通知および変更追跡
本発明の別の態様によると、ストレージプラットフォームは、アプリケーションにデータ変更を追跡させる通知性能を提供する。この特徴は、揮発状態を維持し、またはデータ変更イベントに対してビジネス論理を実行するアプリケーションを主に対象としている。アプリケーションは、アイテム、アイテムの拡張、およびアイテムの関係に関する通知に登録を行う。通知は、データ変更が確定した後、非同期で配信される。アプリケーションは、アイテム、拡張、および関係型ならびに動作の型によって通知をフィルタリングすることができる。

一実施形態によると、ストレージプラットフォームＡＰＩ３２２は、通知用に２種類のインターフェイスを提供する。第１に、アプリケーションは、変更によってアイテム、アイテムの拡張、およびアイテムの関係にトリガされる単純なデータ変更イベントに登録を行う。第２に、アプリケーションは、アイテムの組、アイテムの拡張、およびアイテムの間の関係を監視するための「ウォッチャー」オブジェクトを作成する。ウォッチャーオブジェクトの状態は、システム故障の後でも、システムが長期間オフラインになった後でも、保存し作成し直すことができる。一通の通知は、複数のアップデートを反映し得る。

この機能に関するこれ以上の詳細は、上記参照によって本明細書に組み込まれている関連出願において見ることができる。

Ｉ． 同期
本発明の別の態様によると、ストレージプラットフォームは、同期サービス３３０を提供し、このサービスは、（ｉ）ストレージプラットフォームの複数のインスタンス（それぞれが独自のデータストア３０２を有する）に、１組の柔軟な規則に従ってその内容の一部を同期させ、（ｉｉ）サードパーティが、本発明のストレージプラットフォームのデータストアを、独自のプロトコルを実装する他のデータソースと同期させるためのインフラストラクチャを提供する。

ストレージプラットフォーム同士の間の同期は、関与しているレプリカのグループの間で起こる。たとえば、図３を参照すると、おそらく異なるコンピュータシステム上で実行中である、ストレージプラットフォームの別のインスタンスの制御下で、ストレージプラットフォーム３００のデータストア３０２と、別のリモートデータストア３３８の間の同期をもたらすことが望ましいであろう。このグループの全体の帰属関係は、必ずしもあらゆるレプリカに常に知られているわけではない。

異なるレプリカが、それぞれ単独に（すなわち、同時に）変更を行うことができる。同期プロセスは、すべてのレプリカに、他のレプリカによって行われた変更を気づかせるものとして定義される。この同期性能は、本質的にマルチマスタである。

本発明の同期性能により、レプリカは以下のことが可能となる。
・別のレプリカがどの変更に気づいているか判定する。
・このレプリカが気づいていない変更についての情報を要求する。
・この別のレプリカが気づいていない変更についての情報を伝える。
・２つの変更が競合しているときを判定する。
・変更をローカルに適用する。
・収束させるために、他のレプリカに競合解決を伝える。
・競合解決用に指定されたポリシーに基づいて競合を解決する。

１． ストレージプラットフォーム同士の間の同期
本発明のストレージプラットフォームの同期サービス３３０の主アプリケーションは、ストレージプラットフォームの複数のインスタンス（それぞれが独自のデータストアを有する）を同期させる。同期サービスは、（データベースエンジン３１４の基底テーブルではなく）ストレージプラットフォームスキーマのレベルで動作する。したがって、たとえば、「スコープ」が、後で論じるように同期セットを定義するのに使われる。

同期サービスは、「純変更」原理に基づいて動作する。個々の動作（たとえばトランザクションの複製を伴う）を記録し送るのではなく、同期サービスは、そうした動作の最終結果を送り、したがって、しばしば複数の動作の結果を集約して、１個の変更を生じる。

同期サービスは概して、トランザクション境界を重要視しない。言い換えると、単一のトランザクションにおいて、ストレージプラットフォームデータストアに対して２つの変更が行われる場合、こうした変更が他のすべてのレプリカでアトミックに適用される保証はない。すなわち、一方の変更が、他方の変更なしで現れ得る。この原理に対する例外として、２つの変更が、同じトランザクションにおいて同じ「アイテム」に対して行われた場合、こうした変更は、他のレプリカにアトミックに送られ適用されることが保証される。したがって、「アイテム」は、同期サービスの一貫性単位である。

ａ）同期（Ｓｙｎｃ）制御アプリケーション
どのアプリケーションも、同期サービスに接続し、同期動作を開始することができる。このようなアプリケーションは、同期を実施するのに必要とされるパラメータをすべて提供する（以降の同期プロファイルを参照）。このようなアプリケーションは、本明細書において、同期制御アプリケーション（ＳＣＡ）と呼ばれる。

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

同期を可能にするためには、２つのステップを踏む必要がある。第１に、スキーマ設計者は、（後で説明するように、変更単位を指定する）適切な同期セマンティクスを用いて、ストレージプラットフォームスキーマに注釈をつけなければならない。第２に、同期は、同期に関与するストレージプラットフォームのインスタンスを有するマシンすべてにおいて正しく構成されなければならない（後で説明する）。

ｂ）スキーマの注釈
同期サービスの基本的な概念は、変更単位という概念である。変更単位とは、ストレージプラットフォームによって個々に追跡されるスキーマの最小部分である。すべての変更単位に対して、同期サービスは、最後の同期以降、変更単位が変更されたか、それとも変更されなかったか判定することが可能であり得る。

スキーマ中で変更単位を指定することは、いくつかの目的に役立つ。第１に、変更単位の指定により、同期サービスが有線上でどれだけ会話をするか判定される。変更単位において変更が行われると、同期サービスは、変更単位のどの部分が変更されたかわからないので、変更単位全体が他のレプリカに送られる。第２に、変更単位の指定により、競合検出の精度が判定される。２つの同時変更（こうした用語は、以降のセクションで詳しく定義される）が、同じ変更単位に対して行われると、同期サービスは競合を起こす。一方、同時変更が、異なる変更単位に対して行われた場合、競合は起こらず、変更は自動的にマージされる。第３に、変更単位の指定により、システムによって保たれるメタデータの量が強く影響を受ける。同期サービスメタデータの多くは、変更単位ごとに保たれる。したがって、変更単位を小さくすると、同期のオーバーヘッドが増大する。

変更単位を定義するには、適正なトレードオフを見極める必要がある。この理由ため、同期サービスは、スキーマ設計者をプロセスに関与させる。

一実施形態では、同期サービスは、要素より大きい変更単位をサポートしない。ただし、同期サービスは、スキーマ設計者が要素より小さい変更単位を指定する能力、すなわち、要素の複数の属性を別個の変更単位にグループ化する能力をサポートする。この能力は、本実施形態では、以下のシンタクスを用いて遂行される。

ｃ）同期構成
データの特定の一部を同期させたままにしておくことを望むストレージプラットフォームパートナーのグループは、同期コミュニティと呼ばれる。コミュニティのメンバーは、同期している状態を望むが、必ずしも、データを全く同じように表すわけではない。言い換えると、同期パートナーは、同期しているデータを変換することができる。

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

この概念は、一例によって最もよく説明される。Ｊｏｅが、自分の複数のコンピュータのマイドキュメントフォルダを同期させたままにしておきたい場合、Ｊｏｅは、たとえばＪｏｅｓＤｏｃｕｍｅｎｔｓと呼ばれるコミュニティフォルダを定義する。次いで、すべてのコンピュータ上で、Ｊｏｅは、仮定上のＪｏｅｓＤｏｃｕｍｅｎｔｓとローカルのマイドキュメントフォルダとの間のマッピングを構成する。これ以降、Ｊｏｅのコンピュータは、互いに同期すると、それぞれのローカルアイテムではなく、ＪｏｅｓＤｏｃｕｍｅｎｔｓ中のドキュメントによって会話する。このようにして、すべてのＪｏｅのコンピュータは、相手が誰であるかを知らずに、相互に理解する。つまり、「コミュニティフォルダ」が、同期コミュニティの共通語になるのである。

同期サービスの構成は、次の３つのステップからなる。（１）ローカルフォルダとコミュニティフォルダの間にマッピングを定義し、（２）何が同期されたか（たとえば、誰と同期したか、どのサブセットを送るべきか、どのサブセットを受け取るべきか）判定する同期プロファイルを定義し、（３）どの同期プロファイルを実行するべきかについてのスケジュールを定義し、または同期プロファイルを手作業で実行する。

（１）コミュニティフォルダのマッピング
コミュニティフォルダのマッピングは、ＸＭＬ構成ファイルとして個々のマシンで格納される。各マッピングは、以下のスキーマを有する。
／ｍａｐｐｉｎｇｓ／ｃｏｒｎｍｕｎｉｔｙＦｏｌｄｅｒ
この要素は、このマッピングの対象であるコミュニティフォルダに名前をつける。名称は、フォルダの構文規則に従う。
／ｍａｐｐｉｎｇｓ／ｌｏｃａｌＦｏｌｄｅｒ
この要素は、マッピングによる変換後のローカルフォルダに名前をつける。名称は、フォルダの構文規則に従う。ローカルフォルダは、マッピングが有効となるように存在していなければならない。このフォルダ中のアイテムは、このマッピングごとに同期が検討される。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ
この要素は、アイテムを、コミュニティフォルダからローカルフォルダに、かつその反対に変換する方法を定義する。この要素が存在しない、または空の場合、変換は実施されない。具体的には、どのＩＤもマップされないことを意味する。この構成は主に、フォルダのキャッシュ作成に有用である。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ／ｍａｐＩＤｓ
この要素は、コミュニティＩＤを再利用するのではなく、コミュニティフォルダからマップされるアイテムすべてに、新しく生成されたローカルＩＤが割り当てられることを要求する。同期ランタイムは、アイテムをコンバートし、戻すためのＩＤマッピングを維持する。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ／ｌｏｃａｌＲｏｏｔ
この要素は、コミュニティフォルダ内のすべてのルートアイテムが、指定されたルートの子供にされることを要求する。
／ｍａｐｐｉｎｇｓ／ｒｕｎＡｓ
この要素は、誰の権限の下で、このマッピングに対する要求が処理されるかを制御する。存在しない場合、送信者が想定される。
／ｍａｐｐｉｎｇｓ／ｒｕｎＡｓ／ｓｅｎｄｅｒ
この要素の存在は、このマッピングへのメッセージの送信者が、なりすましを受けなければならないことを示し、送信者の認定資格の下で処理されることを要求する。

（２）プロファイル
「同期プロファイル」とは、同期を開始するのに必要とされる、パラメータの全体集合である。同期プロファイルは、同期を開始するために、ＳＣＡによって「同期ランタイム」に供給される。ストレージプラットフォーム同士の間の同期用の同期プロファイルは、以下の情報を含む。
・変更のソースおよび宛先として働くローカルフォルダ。
・同期するためのリモートフォルダ名：このフォルダは、上で定義したマッピングによって、リモートパートナーから公表されなければならない。
・方向：同期サービスは、送信専用、受信専用、および送受信同期をサポートする。
・ローカルフィルタ：どのようなローカル情報をリモートパートナーに送るかを選択する。ローカルフォルダに対するストレージプラットフォームクエリとして表現される。
・リモートフィルタ：どのようなリモート情報をリモートパートナーから取得するかを選択する。コミュニティフォルダに対するストレージプラットフォームクエリとして表現される。
・変換：アイテムとローカル形式の間で、どのようにして変換を行うかを定義する。
・ローカルセキュリティ：リモートエンドポイントから取得された変更が、リモートエンドポイントの許可（なりすまされる）の下で適用されるべきか、それともユーザが同期をローカルに開始するか指定する。
・競合解決ポリシー：競合が拒絶され、ログに記録され、または自動的に解決されるべきか指定する。自動的に解決される場合、どの競合リゾルバを使うか、ならびにリゾルバ用の構成パラメータを指定する。

同期サービスは、「同期プロファイル」の単純な構築を可能にするランタイムＣＬＲクラスを提供する。プロファイルは、容易な記憶のために（しばしばスケジュールに沿って）、ＸＭＬファイルとの間でシリアライズすることもできる。しかし、ストレージプラットフォームには、プロファイルすべてが格納される標準的な場所がない。ＳＣＡは、プロファイルを持続することなく、即座に自由に構成してよい。ローカルマッピングに、同期を開始させる必要はないことに留意されたい。すべての同期情報は、プロファイル中で指定することができる。ただし、リモート側によって開始される同期要求に応答するために、マッピングが必要とされる。

（３）スケジュール
一実施形態では、同期サービスは、その独自のスケジューリングインフラストラクチャを提供しない。そうではなく、同期サービスは、別のコンポーネント、すなわちＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを有する、市販のＷｉｎｄｏｗｓ（登録商標）スケジューラに依拠して、このタスクを実施する。同期サービスは、ＳＣＡとして働くとともにＸＭＬファイルに保存されている同期プロファイルに基づいて同期をトリガするコマンドラインユーティリティを含む。このユーティリティにより、スケジュール通りに、またはユーザのログオンやログオフなどのイベントに応答して同期を実行するようにＷｉｎｄｏｗｓ（登録商標）スケジューラを構成することが非常に容易になる。

ｄ）競合操作
同期サービスにおける競合操作は、次の３つの段階に分けられる。（１）変更適用時に起こる競合検出：このステップは、変更を安全に適用することができるかどうか判定する。（２）自動競合解決およびログ記録：このステップ（競合が検出された直後に起こる）の間、自動競合リゾルバは、競合を解決することができるかどうか調べるために問合せを受ける。解決できない場合、競合は、任意選択でログに記録することができる。（３）競合検査および解決：このステップは、いくつかの競合がログに記録されている場合に起こり、同期セッションのコンテキスト外で起こる。この時点で、ログに記録された競合は、解決しログから削除することができる。

（１）競合検出
本実施形態において、同期サービスは、知識ベースおよび制約ベースの２つのタイプの競合を検出する。

（ａ）知識ベースの競合
２つのレプリカが、同じ変更単位に対してそれぞれ独立した変更を行うと、知識ベースの競合が起こる。２つの変更は、互いを知らずに行われた場合、独立していると言われる。言い換えると、第１の変更のバージョンは、第２の変更の知識に含まれず、その逆も同様である。同期サービスは、上述したレプリカの知識に基づいて、すべてのこのような競合を自動的に検出する。

競合を、変更単位のバージョン履歴中の分岐点と見なすことが有用な場合がある。変更単位が存続している間に競合が起こらない場合、変更単位のバージョン履歴は、単純なチェーンであり、各変更が、１つ前の変更の後に起こる。知識ベースの競合の場合、２つの変更は並行して起こり、チェーンが分割されてバージョンツリーとなる。

（ｂ）制約ベースの競合
独立変更は、一緒に適用されると、統合性制約に違反する場合がある。たとえば、同じディレクトリ中に同じ名称のファイルを作成する２つのレプリカが、このような競合を起こさせ得る。

制約ベースの競合は、（知識ベースの競合と同様に）２つの独立変更を伴うが、同じ変更単位に影響を与えない。そうではなく、その間に制約が存在するが異なる変更単位に影響を与える。

同期サービスは、変更適用時に制約違反を検出し、自動的に制約ベースの競合を起こす。制約ベースの競合の解決には通常、制約に違反しないようにして変更を修正するカスタムコードが必要となる。同期サービスは、そうするための汎用機構を提供しない。

（２）競合処理
競合が検出されると、同期サービスは、３つのアクションの１つを行い得る（「同期プロファイル」において同期イニシエータによって選択される）。（１）変更を拒絶し、変更を送信者に戻す、（２）競合を競合ログに記録する、または（３）競合を自動的に解決する。

変更が拒絶された場合、同期サービスは、変更がレプリカに届かなかったかのように振る舞う。否定応答が発信元に返送される。この解決ポリシーは、ログ記録の競合が起こりそうにない、先頭のないレプリカ（ファイルサーバなど）に対して主に有用である。そうではなく、このようなレプリカは、競合を拒絶することによって、他のレプリカに競合を扱わせる。

同期イニシエータは、「同期プロファイル」中に競合解決を構成する。同期サービスは、以下のようにして、多数の競合リゾルバを単一のプロファイルの中に結合することをサポートする。第１に、１つが成功するまで、試すべき競合リゾルバのリストを次々と指定し、第２に、競合リゾルバを競合型に関連づける。たとえば、アップデート対アップデートの、知識ベースの競合をあるリゾルバに向けるが、他の競合はすべてログに向ける。

（ａ）自動競合解決
同期サービスは、いくつかのデフォルト競合リゾルバを提供する。このリストは、以下のものを含む。
・ローカル優先：ローカルに格納されているデータと競合する場合、受信した変更を無視する。
・リモート優先：受信した変更と競合する場合、ローカルデータを無視する。
・最新版を優先：変更単位ごとに、変更のタイムスタンプに基づいて、ローカル優先か、それともリモート優先かを選ぶ（同期サービスは概して、クロック値に依拠しないことに留意されたい。この競合リゾルバは、その規則のただ１つの例外である）。
・決定論：重要なものを除くすべてのレプリカに対して同じであることが保証されるやり方で勝者を選ぶ。同期サービスの一実施形態では、パートナーＩＤを辞書方式で比較して、この特徴を実装する。

さらに、ＩＳＶは、独自の競合リゾルバを実装しインストールすることができる。カスタム競合リゾルバは、構成パラメータを受諾することができる。このようなパラメータは、「同期プロファイル」の競合解決セクションでＳＣＡによって指定されなければならない。

競合リゾルバは、競合を処理すると、（競合する変更の代わりに）ランタイムに対して実施される必要がある動作のリストを返す。同期サービスは次いで、こうした動作を適用し、競合ハンドラが何を考慮したかを含むようにリモート知識を適切に調整する。

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

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

（ｂ）競合のログ記録
特殊な種類の競合リゾルバが、「競合ロガー」である。同期サービスは、競合をＣｏｎｆｌｉｃｔＲｅｃｏｒｄ型の「アイテム」としてログに記録する。こうしたレコードは、競合しているアイテムに逆に関係づけられる（アイテム自体が消去されていない限り）。各競合レコードは、競合を引き起こした着信変更と、アップデート対アップデート、アップデート対消去、消去対アップデート、挿入対挿入、または制約という競合の型と、着信変更のバージョンおよびこの着信を送ったレプリカの関する知識とを含む。ログに記録された競合は、後で説明するように、検査および解決に利用可能である。

（ｃ）競合検査および解決
同期サービスは、アプリケーションが競合ログを調べ、ログの中の競合の解決を提起するためのＡＰＩを提供する。このＡＰＩは、アプリケーションに、すべての競合、または所与の「アイテム」に関連する競合を列挙させる。また、このようなアプリケーションに、以下の３通りのやり方の１つで、ログに記録された競合を解決させる。（１）リモート優先：ログに記録された変更を受諾し、競合しているローカル変更を上書きする。（２）ローカル優先：ログに記録されている変更の競合部を無視する。（３）新しい変更の提起：アプリケーションが、その意見として、競合を解決するマージを提案する。競合がアプリケーションによって解決されると、同期サービスは、ログから競合を削除する。

（ｄ）レプリカの収束および競合解決の伝播
複合同期シナリオにおいて、複数のレプリカで同じ競合が検出される場合がある。同じ競合が検出されると、以下のことが起こり得る。（１）一方のレプリカにおいて競合を解決することができ、他方に解決を送ることができる。（２）競合が、両方のレプリカにおいて自動的に解決される。または（３）競合が、両方のレプリカにおいて手作業で（競合検査ＡＰＩを介して）解決される。

収束を保証するために、同期サービスは、他のレプリカに競合解決を転送する。競合を解決する変更がレプリカに届くと、同期サービスは、このアップデートによって解決されるどの競合レコードも、ログ中で自動的に見つけ、レコードを排除する。この意味において、１つのレプリカにおける競合解決は、他のレプリカすべてに結びつけられる。

同じ競合に対して、異なるレプリカによって異なる勝者が選ばれた場合、同期サービスは、束縛競合解決の原理を適用し、他方に対して勝つ、２つの解決の一方を自動的に選ぶ。勝者は、いつでも同じ結果を生じることが保証される決定論的方式で選ばれる（一実施形態では、レプリカＩＤの辞書方式比較を用いる）。

同じ競合に対して、異なるレプリカによって異なる「新しい変更」が提起された場合、同期サービスは、この新しい競合を、特殊な競合として扱い、「競合ロガー」を使って、競合が他のレプリカに伝播するのを防止する。このような状況は一般に、手作業による競合解決を用いることによって起こる。

２． 非ストレージプラットフォームデータストアとの同期
本発明のストレージプラットフォームの別の態様によると、ストレージプラットフォームは、ＩＳＶが、たとえばＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ＡＤ、Ｈｏｔｍａｉｌなどのレガシーシステムにストレージプラットフォームを同期させるための「同期アダプタ」を実装するアーキテクチャを提供する。「同期アダプタ」は、後で説明するように、同期サービスによって提供される多くの「同期サービス」から利益を受ける。

名称に関わらず、「同期アダプタ」は、プラグインとしていくつかのストレージプラットフォームアーキテクチャに実装される必要がない。そうすることが望まれる場合、「同期アダプタ」は単に、変更の列挙および適用などのサービスを入手するのに同期サービスランタイムインターフェイスを使用する、どのアプリケーションでもよい。

他者が所与のバックエンドへの同期を構成し実行するのをより容易にするために、「同期アダプタ」の書き手は、上述したように「同期プロファイル」を与えられると同期を実行する、標準「同期アダプタ」インターフェイスを公開することを推奨される。プロファイルは、アダプタに構成情報を提供し、こうした情報の一部（たとえば同期するべき「フォルダ」）は、「同期ランタイム」に移って、ランタイムサービスを制御する。

ａ）同期サービス
同期サービスは、アダプタの書き手にいくつかの同期サービスを提供する。このセクションの残りの部分では、ストレージプラットフォームが「クライアント」として同期しているマシン、およびアダプタが「サーバ」として会話している非ストレージプラットフォームバックエンドに言及するのが好都合である。

（１）変更の列挙
同期サービスによって維持される変更追跡データに基づいて、同期アダプタは、「変更列挙」により、このパートナーとの最後の同期が試みられてからデータストア「フォルダ」に対して起こった変更を容易に列挙することが可能になる。

変更は、最後の同期についての情報を表す不透明な構造である「アンカ」概念に基づいて列挙される。アンカは、これまでのセクションで述べたように、ストレージプラットフォームの「知識」という形をとる。変更列挙サービスを使用する「同期アダプタ」は、次の２つの広範囲のカテゴリに分けられる。すなわち、「格納されているアンカ」を使うものと、「与えられたアンカ」を使うものである。

区別は、最後の同期についての情報が格納される場所に基づく。格納される場所は、クライアント上、またはサーバ上である。しばしば、アダプタにとって、この情報をクライアント上に格納する方がより容易であり、バックエンドはしばしば、この情報を好都合に格納することができない。一方、複数のクライアントが同じバックエンドに同期する場合、この情報をクライアント上に格納することは非効率であり、いくつかの場合では、他のクライアントが既にサーバにプッシュアップしている変更に、あるクライアントが気づかない場合があるので、適正でない。アダプタは、サーバに格納されているアンカを使いたい場合、変更を列挙するときにそのアンカをストレージプラットフォームに戻す必要がある。

ストレージプラットフォームは、アンカを（ローカルまたはリモート記憶用に）維持するために、サーバで問題なく適用された変更に気づく必要がある。こうした変更のみを、アンカに含めることができる。変更列挙の間、「同期アダプタ」は、「確認応答」インターフェイスを使って、どの変更が問題なく適用されたかを報告する。同期が終わると、供給されたアンカを使うアダプタは、新しいアンカ（問題なく適用された変更をすべて組み込んでいる）を読み、このアンカをバックエンドに送らなければならない。

しばしば、アダプタは、アダプタ特有のデータを、ストレージプラットフォームデータストアに挿入するアイテムとともに格納する必要がある。このようなデータに共通の例が、リモートＩＤおよびリモートバージョン（タイムスタンプ）である。同期サービスは、このデータを格納する機構を提供し、「変更列挙」は、返される変更とともにこの特別なデータを受け取る機構を提供する。こうすることによって、ほとんどの場合、アダプタがデータベースを照会し直す必要がなくなる。

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

変更適用の主たる機能は、競合を自動的に検出することである。ストレージプラットフォーム同士の間の同期の場合のように、競合が、互いを知らずに行われる、重複する２つの変更として定義される。アダプタは、「変更適用」を使うとき、どの競合検出が実施されるかに関して、アンカを指定しなければならない。アダプタの知識に含まれない、重複するローカル変更が検出された場合、「変更適用」は競合を起こす。「変更列挙」と同様、アダプタは、格納されているアンカか、または供給されたアンカを使うことができる。「変更適用」は、アダプタ特有のメタデータの効率的な記憶をサポートする。このようなデータは、アダプタによって、適用される変更に付加することができ、同期サービスによって格納することができよう。データは、次の変更列挙において返すことができる。

（３）競合解決
上述した競合解決機構（ログ記録および自動解決オプション）は、同期アダプタにも利用可能である。「同期アダプタ」は、変更を適用するとき、競合解決のためのポリシーを指定することができる。指定された場合、競合は、指定された競合ハンドラに渡され、解決することができる（可能な場合）。競合は、ログに記録することもできる。アダプタは、バックエンドへのローカル変更の適用を試みるとき、競合を検出し得ることが可能である。このような場合、アダプタはさらに、「同期ランタイム」に、ポリシーに従って解決されるべき競合を渡すことができる。さらに、「同期アダプタ」は、同期サービスによって検出されたどの競合も、処理のためにアダプタに返送されるよう、要求することができる。これは、バックエンドが競合を格納することも解決することもできる場合に特に好都合である。

ｂ）アダプタの実装
いくつかの「アダプタ」は、ランタイムインターフェイスを使用する単なるアプリケーションであるが、アダプタは、標準アダプタインターフェイスを実装することを推奨される。こうしたインターフェイスにより、「同期制御アプリケーション」は、所与の「同期プロファイル」に従ってアダプタが同期を実施するよう要求し、継続中の同期をキャンセルし、継続中の同期についての進捗報告（完了パーセント数）を受け取ることが可能になる。

３． セキュリティ
同期サービスは、ストレージプラットフォームによって実装されるセキュリティモデルへの導入を、できるだけ少なくすることを目指す。同期に対して新しい権利を定義するのではなく、既存の権利が用いられる。具体的には、以下のようにする。
・データストアアイテムを読むことができる人は誰でも、そのアイテムへの変更を列挙することができる。
・データストアアイテムに書き込むことができる人は誰でも、そのアイテムに変更を適用することができる。
・データストアアイテムを拡張することができる人は誰でも、同期メタデータをそのアイテムに関連づけることができる。

同期サービスは、安全な作者情報を維持しない。変更が、ユーザＵによってレプリカＡで行われ、レプリカＢに転送されると、変更が、元々Ａで（またはＵによって）行われたという事実が失われる。Ｂが、この変更をレプリカＣに転送する場合、この転送は、Ａの権限ではなくＢの権限の下で行われる。その結果、以下のように限定される。レプリカは、アイテムへの独自の変更を行うことが信頼されない場合、他のレプリカによって行われた変更を転送することができない。

同期サービスが開始されるとき、同期サービスは、「同期制御アプリケーション」によって行われる。同期サービスは、ＳＣＡの識別になりすまし、その識別の下ですべての動作を（両方ローカルかつリモートに）実施する。たとえば、ユーザＵが、リモートストレージプラットフォームから、ユーザＵが読取りアクセスをもたないアイテムに対する変更を取得するためのローカル同期サービス起こすことができない場合を検討されたい。

４． 管理性
レプリカの分散コミュニティの監視は、複雑な問題である。同期サービスは、「スイープ」アルゴリズムを使って、レプリカの状況についての情報を収集し分散することができる。スイープアルゴリズムのプロパティにより、確実に、すべての構成レプリカについての情報が最終的に集められ、不合格な（応答のない）レプリカが検出されるようになる。

このコミュニティ規模の監視情報は、すべてのレプリカで利用可能である。監視ツールは、この監視情報を調べるとともに管理上の決定を行うために、任意に選ばれたレプリカで実行することができる。どの構成変更も、影響を受けるレプリカで直接行われなければならない。

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

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

この機能に関するこれ以上の詳細は、上記参照によって本明細書に組み込まれている関連出願において見ることができる。

Ｋ． ストレージプラットフォームＡＰＩ
ストレージプラットフォームは、アプリケーションプログラムが、上述したストレージプラットフォームの特徴および性能を利用するとともにデータストアに格納されているアイテムにアクセスすることを可能にするＡＰＩを備える。このセクションでは、本発明のストレージプラットフォームのストレージプラットフォームＡＰＩの一実施形態について述べる。この機能に関する詳細は、上記参照によって本明細書に組み込まれている関連出願において見ることができ、便宜上、この情報の一部を後で要約する。

図１８を参照すると、「コンテナフォルダ（Ｃｏｎｔａｉｍｅｎｔ Ｆｏｌｄｅｒ）」とは、他の「アイテム」への保持関係を含むとともにファイルシステムフォルダという共通概念と等価なアイテムである。各「アイテム」は、少なくとも１つのコンテナフォルダに「含まれる」。

図１９は、本実施形態による、ストレージプラットフォームＡＰＩの基本アーキテクチャを示す。ストレージプラットフォームＡＰＩは、ＳＱＬＣｌｉｅｎｔ１９００を使って、ローカルデータストア３０２と通信し、さらにＳＱＬＣｌｉｅｎｔ１９００を使って、リモートデータストア（たとえば、データストア３４０）と通信することもできる。ローカルストア３０２は、ＤＱＰ（「分散クエリプロセッサ」）を使って、または上述したストレージプラットフォーム同期サービス（「同期」）を介して、リモートデータストア３４０と通信することもできる。ストレージプラットフォームＡＰＩ３２２は、やはり上述したように、データストア通知用のブリッジＡＰＩとしても働き、アプリケーションの登録内容を通知エンジン３３２に渡し、通知をアプリケーション（たとえば、アプリケーション３５０ａ、３５０ｂ、または３５０ｃ）に経路指定する。一実施形態では、ストレージプラットフォームＡＰＩ３２２は、Ｍｉｃｒｏｓｏｆｔ ＥｘｃｈａｎｇｅおよびＡＤ中のデータにアクセスし得るように、限定された「提供元」アーキテクチャを定義することもできる。

図２０は、ストレージプラットフォームＡＰＩの様々なコンポーネントを概略的に表す。ストレージプラットフォームＡＰＩは、（１）ストレージプラットフォーム要素およびアイテム型を表すデータクラス２００２、（２）オブジェクトの一貫性を管理し、サポートクラス２００６を提供するランタイムフレームワーク２００４、ならびに（３）ストレージプラットフォームスキーマからＣＬＲクラスを生成するのに使われるツール２００８というコンポーネントからなる。

所与のスキーマから生じるクラス階層は、そのスキーマ中の型の階層を直接反映する。一例として、図２１Ａおよび図２１Ｂに示す、「連絡先」スキーマにおいて定義される「アイテム」型を考えてみる。

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

図２３は、「ＦｉｎｄＡｌｌ」動作の実行を示す。

図２４は、ストレージプラットフォーム「スキーマ」からストレージプラットフォームＡＰＩクラスを生成するためのプロセスを示す。

図２５は、「ファイル」ＡＰＩが基礎としているスキーマを示す。ストレージプラットフォームＡＰＩは、ファイルオブジェクトを扱う名前空間を含む。この名前空間は、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓと呼ばれる。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓ中のクラスのデータメンバーは、ストレージプラットフォームストアに格納される情報を直接反映する。この情報は、ファイルシステムオブジェクトから「昇格」され、または、Ｗｉｎ３２ＡＰＩを使って生得的に作成することもできる。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓ名前空間は、ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍという２つのクラスをもつ。こうしたクラスのメンバーおよびそのメソッドは、図２５のスキーマ図を見ることによって容易に見抜くことができる。ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍは、ストレージプラットフォームＡＰＩからは読取り専用である。こうしたアイテムを修正するためには、Ｗｉｎ３２ＡＰＩまたはＳｙｓｔｅｍ．ＩＯ中のクラスを使わなければならない。

ＡＰＩに関して、プログラミングインターフェイス（またはより簡単には、インターフェイス）は、コードの１つまたは複数のセグメント（群）が、コードの１つまたは複数の他のセグメント（群）によって提供される機能と通信しまたは機能にアクセスすることを可能にする、どの機構、処理、プロトコルとも見なすことができる。あるいは、プログラミングインターフェイスは、他のコンポーネント（群）の、１つまたは複数の機構（群）、方法（群）、関数呼出し（群）、モジュール（群）などと通信結合することができる、システムのあるコンポーネントの、１つまたは複数の機構（群）、方法（群）、関数呼出し（群）、モジュール（群）、オブジェクト（群）などと見なすことができる。上記の文における「コードのセグメント」という用語は、適用される専門範囲に関わらず、かつコードセグメントが個別にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードとして提供されるのか、コードセグメントがランタイムシステムまたは処理において使用されるのか、コードセグメントが同じマシンもしくは異なるマシンに置かれるか、それとも複数のマシンに分散されるか、あるいはコードのセグメントによって表される機能が、完全にソフトウェアとして、完全にハードウェアとして、またはハードウェアおよびソフトウェアの組合せとして実装されるのかに関わらず、１つまたは複数の命令またはコードの行を含み、たとえば、コードモジュール、オブジェクト、サブルーチン、関数などを含むことを意図していることに留意されたい。

概念的に、プログラミングインターフェイスは、図３０Ａまたは図３０Ｂに示すように、包括的に見ることができる。図３０Ａは、第１および第２コードセグメントが通信するための導管としてのインターフェイス１というインターフェイスを示す。図３０Ｂは、インターフェイスを、インターフェイスオブジェクトＩ１およびＩ２（第１および第２コードセグメントの一部であっても、そうでなくてもよい）を備えるものとして示し、こうしたインターフェイスオブジェクトは、システムの第１および第２コードセグメントが、媒体Ｍを介して通信することを可能にする。図３０Ｂを見て、インターフェイスオブジェクトＩ１およびＩ２を、同一のシステムの別個のインターフェイスと見なす人、オブジェクトＩ１およびＩ２と媒体Ｍとがインターフェイスを構成すると見なす人がいるかもしれない。図３０Ａおよび３０Ｂは、双方向の流れ、およびその流れの両端でのインターフェイスを示すが、特定の実装形態は、一方向での情報の流れしかもたない（または後で説明されるように情報の流れをもたない）場合もあり、一端でのインターフェイスオブジェクトしかもたない場合もある。限定ではなく例として、ＡＰＩ（アプリケーションプログラミングインターフェイス）、エントリポイント、メソッド、関数、サブルーチン、リモートプロシージャコール、およびＣＯＭ（コンポーネントオブジェクトモデル）インターフェイスなどの用語は、プログラミングインターフェイスの定義範囲に包含される。

このようなプログラミングインターフェイスの特徴は、第１コードセグメントが、第２コードセグメントに情報（この場合、「情報」は、広い意味で使われており、データ、コマンド、要求などを含む）を送る方法と、第２コードセグメントが、その情報を受け取る方法と、その情報の構造、シーケンス、シンタクス、組織化、スキーマ、計時、および内容とを含み得る。これに関して、情報が、インターフェイスによって定義されたやり方で移送される限り、基底の移送媒体自体は、有線でも無線でも、あるいは有線および無線の組合せであっても、インターフェイスの動作にとって重要でなくてよい。特定の状況では、情報は、従来の意味での一方向または両方向で渡すことはできない。というのは、情報の転送は、あるコードセグメントが、第２コードセグメントによって実施される機能に単にアクセスするときのように、別の機構（たとえば、コードセグメントの間の情報の流れとは別に、情報が、バッファ、ファイルなどに置かれる）を介するか、または存在しなくてもよいからである。こうした特徴のいずれかまたは全部は、所与の状況、たとえば、コードセグメントが、疎結合構成または密結合構成のシステムの一部であるかに応じて重要となる場合があり、したがて、このリストは、例示であって限定のためではないと見なされるべきである。

このプログラミングインターフェイス概念は、公知であり、本発明の上記の詳細な説明から明らかである。しかし、プログラミングインターフェイスを実装する他の方法もあり、明示的に除外されない限り、こうした方法も、本明細書に添付され定義される特許請求の範囲に包含されることを意図している。このような他の方法は、図３０Ａおよび３０Ｂの単純化された概観より高度または複雑に見え得るが、それにもかかわらず、全体として同じ結果を達成する類似した機能を実施する。ここで、プログラミングインターフェイスのいくつかの例示的な代替実装形態を簡潔に説明する。

因数分解：あるコードセグメントから別のコードセグメントへの通信は、その通信を、複数の別々の通信に分けることによって、間接的に達成することができる。このことは、図３１Ａおよび３１Ｂに概略的に示してある。図に示すように、いくつかのインターフェイスは、機能の分割可能な組として説明することができる。したがって、図３０Ａおよび３０Ｂのインターフェイス機能は、２４または２×２×３×２を数学的にもたらすことができるように、同じ結果を得るように因数分解することができる。したがって、図３１Ａに示されるように、インターフェイス１というインターフェイスによって提供される機能は、インターフェイスの通信をインターフェイス１Ａ、インターフェイス１Ｂ、インターフェイス１Ｃなどの複数のインターフェイスにコンバートするように下位分割され、同じ結果を得ることができる。図３１Ｂに示されるように、インターフェイスＩ１によって提供される機能は、複数のインターフェイスＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに下位分割され、同じ結果を得ることができる。同様に、第１コードセグメントから情報を受け取る、第２コードセグメントのインターフェイスＩ２は、複数のインターフェイスＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに因数分解することができる。因数分解するとき、第１コードセグメントに含まれるインターフェイスの数は、第２コードセグメントに含まれるインターフェイスの数と一致しなくてもよい。図３１Ａおよび３１Ｂのいずれの場合でも、インターフェイス１およびＩ１というインターフェイスの機能上の意図は、それぞれ図３０Ａおよび３０Ｂの場合と同じままである。インターフェイスの因数分解は、因数分解が認識困難になり得るように、結合的な、可換な、および他の数学的なプロパティの後に起こることもできる。たとえば、動作の順序は重要でなくてよく、したがって、インターフェイスによって実現される機能は、インターフェイスの遂行に先立って、別のコード部分またはインターフェイスによって実現されても、システムの別のコンポーネントによって実施されてもよい。さらに、同じ結果を得る異なる関数呼出しを行う様々な方法があることが、プログラミング分野の当業者には理解できよう。

再定義：いくつかの場合において、プログラミングインターフェイスの特定の特徴（たとえばパラメータ）を無視し、追加し、または再定義し、意図した結果を依然として得ることが可能であり得る。このことは、図３２Ａおよび３２Ｂに示してある。たとえば、図３０Ａのインターフェイス１というインターフェイスが、Ｓｑｕａｒｅ（ｉｎｐｕｔ，ｐｒｅｃｉｓｉｏｎ，ｏｕｔｐｕｔ）の関数呼出しを含み、この呼出しは、３つのパラメータ、すなわちｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、およびｏｕｔｐｕｔを含み、第１コードセグメントから第２コードセグメントに発行されると仮定する。中央のパラメータｐｒｅｃｉｓｉｏｎは、図３２Ａに示すように、所与のシナリオに関係しない場合、適切に無視されることも、（この状況において）ｍｅａｎｉｎｇｌｅｓｓパラメータで置き換えられることもできよう。無関係なａｄｄｉｔｉｏｎａｌパラメータを追加することもできる。いずれの場合でも、第２コードセグメントによって入力が二乗された後で出力が返される限り、二乗機能を達成することができる。ｐｒｅｃｉｓｉｏｎは、計算機システムの何らかの下流部分または他の部分にとって有意なパラメータでもよい。ただし、ｐｒｅｃｉｓｉｏｎは、二乗計算という狭い目的にとって必要ないと認識されると、置き換えられまたは無視することができる。たとえば、有効なｐｒｅｃｉｓｉｏｎ値を渡すのではなく、誕生日などの無意味な値が、結果に悪影響を与えることなく渡されることができよう。同様に、図３２Ｂに示すように、インターフェイスＩ１は、インターフェイスＩ１’で置き換えられ、インターフェイスへのパラメータを無視しまたは追加するように再定義される。インターフェイスＩ２は、同様にインターフェイスＩ２’として再定義されることができ、不必要なパラメータまたは他の所で処理することができるパラメータを無視するように再定義される。ここでのポイントは、いくつかの場合において、プログラミングインターフェイスは、何らかの目的には必要とされないパラメータなどの特徴を含む場合があるので、こうした特徴は、無視されまたは再定義され、あるいは他の目的のために他の所で処理されてもよいことである。

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

分離：一方のコードセグメントから別のコードセグメントへの通信は、その通信を複数の別々の通信に分けることによって間接的に遂行することができる。このことは、図３４Ａおよび３４Ｂに概略的に示してある。図３４Ａに示すように、ミドルウェアの１つまたは複数の断片（群）（元のインターフェイスから全機能および／またはインターフェイス機能を分離するので、分離インターフェイス（群））が、第１のインターフェイス、すなわちインターフェイス１上での通信をコンバートして、異なるインターフェイス、この場合インターフェイス２Ａ、インターフェイス２Ｂ、およびインターフェイス２Ｃというインターフェイスに通信を準拠させるように提供される。これは、たとえば、インターフェイス１のプロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのベースがインストールされているが、次いで、オペレーティングシステムが、異なるインターフェイス、この場合インターフェイス２Ａ、インターフェイス２Ｂ、およびインターフェイス２Ｃというインターフェイスを用いるように変更される場合に行うことができるであろう。重要なのは、第２コードセグメントに使われていた元のインターフェイスは、第１コードセグメントによって使われるインターフェイスとの互換性がなくなるように変更され、したがって、古いおよび新しいインターフェイスを互換可能にするのに媒介が用いられる点である。同様に、図３４Ｂに示すように、ＤＩ２と共同で作用するように設計し直されているが同じ機能的結果をもたらす、インターフェイスＩ１からの通信を受けるための分離インターフェイスＤＩ１、およびたとえばインターフェイスＩ２ａおよびＩ２ｂにインターフェイス機能を送るための分離インターフェイスＤＩ２を有する、第３のコードセグメントが導入することができる。同様に、ＤＩ１およびＤＩ２は、図３０ＢのインターフェイスＩ１およびＩ２の機能を、新しいオペレーティングシステムに翻訳するように共同作用し、同じまたは類似した機能的結果をもたらすことができる。

書換え：インターフェイス機能を他のもので置き換えるが全体として同じ結果を達成するようにコードを動的に書き換える、さらに別の変形体が可能である。たとえば、実行環境（．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様のランタイム型の環境によって提供されるような）実行環境において、中間言語（たとえば、マイクロソフトＩＬ、Ｊａｖａ（登録商標）バイトコードなど）の形で示されるコードセグメントが、ＪＩＴ（ジャストインタイム）コンパイラまたはインタープリタに与えられるシステムがあり得る。ＪＩＴコンパイラは、第１コードセグメントから第２コードセグメントへの通信を動的にコンバートするように、すなわち、第２コードセグメント（元のまたは異なる第２コードセグメントのどちらか）によって要求することができる異なるインターフェイスに通信を準拠させるように書くことができる。このことは、図３５Ａおよび３５Ｂに示してある。図３５Ａに見ることができるように、この手法は、上述された分離構成と似ている。これは、たとえば、インターフェイス１のプロトコルに従ってオペレーティングシステムと通信するように設計されたインストール済のアプリケーションのベースが、次いで、オペレーティングシステムが、異なるインターフェイスを用いるように変更される場合に行うことができるであろう。ＪＩＴコンパイラは、インストールベースのアプリケーションからのオンザフライでの通信を、オペレーティングシステムの新しいインターフェイスに準拠させるのに用いることができよう。図３５Ｂに示されるように、インターフェイス（群）を動的に書き換えるこの手法は、インターフェイス（群）を動的に因数分解し、あるいは作り変えるのにも適用することができる。

代替実施形態によって、インターフェイスと同じまたは類似の結果を得る上述したシナリオは、様々な方法、すなわち直列および／または並列で、あるいは他の介在コードと組み合わされてもよいことにも留意されたい。したがって、上で提示された代替実施形態は、互いに排他的でなく、図３０Ａおよび３０Ｂに示される汎用的なシナリオと同じまたは等価なシナリオを作り出すように、混合され、調和され、組み合わされてもよい。ほとんどのプログラミング構成の場合のように、本明細書では説明しないが、それにもかかわらず本発明の精神および範囲によって表されるインターフェイスの同じまたは類似の機能を達成する他の同様の方法があることにも留意されたい。すなわち、インターフェイスの価値を決定するのは、少なくとも部分的には、インターフェイスによって表される機能、およびインターフェイスによって可能にされる有利な結果であることに留意されたい。

ＩＩＩ． 拡張および継承
本発明の基本的な概念は、スキーマによって記述され、ハードウェア／ソフトウェアインターフェイスシステムによって強制される複合構造、ビヘイビア、および動作を用いて、現実世界のアプリケーションオブジェクトをある程度モデル化する「アイテム」の使用である。豊富なサブ型指定機能を提供するために、本発明の様々な実施形態では、ハードウェア／ソフトウェアインターフェイスシステム（便宜上、これ以降は単に「ＷｉｎＦＳ」と呼ぶこととする）は、「拡張」を使って「アイテム」（および「アイテム」型）を拡張することを可能にするための機構を提供することができる。拡張は、既存の「アイテム」型構造に、追加データ構造（プロパティ、関係など）を提供する。

本明細書において上述した（かつセクションＩＩ．Ｅ．６．（ａ）およびＩＩ．Ｆ．３で具体的に論じた）ように、ストレージプラットフォームは、スキーマの初期セットとともに提供されることを意図しているが、少なくともいくつかの実施形態では、ストレージプラットフォームは、独立ソフトウェアベンダ（ＩＳＶ）を含む顧客が、新しいスキーマ（すなわち、新しい「アイテム」および「ネスト要素」型）を作成することを可能にする。ストレージプラットフォームスキーマの初期セットによって定義される「アイテム」型または「ネスト要素」型は、ＩＳＶアプリケーションの要求と正確には合致し得ないので、ＩＳＶに、型をカスタマイズさせることが必要である。カスタマイズは、「拡張」概念を用いて認められる。拡張は、厳密に型指定されたインスタンスであるが、（ａ）それぞれ独立に存在することができず、（ｂ）「アイテム」または「ネスト要素」に付加されなければならない。また、スキーマ拡張性の必要性への対処に加えて、拡張は、「多重型指定」問題への対処も意図している。いくつかの実施形態では、ストレージプラットフォームは、多数の継承も重複するサブ型もサポートすることができないので、アプリケーションは、重複型のインスタンス（たとえば「ドキュメント」は、法的文書ならびに保管文書であり得る）をモデル化する方法として、「拡張」を使うことができる。

Ａ． 型システム
本発明の様々な実施形態において、ＷｉｎＦＳ型システムは、データの構造を定義する機構を提供する。型システムは、ＷｉｎＦＳに格納されるデータを表すのに使われる。ＷｉｎＦＳ型は、ＷｉｎＦＳスキーマにおいて宣言される。ＷｉｎＦＳスキーマは、１組の型および他のＷｉｎＦＳスキーマ要素用の論理的グループ化として働く名前空間を定義する。ＷｉｎＦＳスキーマは、ＸＭＬ形式を使い得るＷｉｎＦＳスキーマ定義言語（ＳＤＬ）を使って宣言することができる。以下は、可能なスキーマ宣言の例である。

ＷｉｎＦＳスキーマは、型のバージョニング用の単位としても働く。ＷｉｎＦＳは、システムをブートするいくつかのシステムスキーマを定義する。こうしたスキーマは、システムにおいてルート型の型宣言を含むＳｙｓｔｅｍ．Ｓｔｏｒａｇｅスキーマ名前空間、およびシステムにおいてすべての基本要素スカラー型を宣言するＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＷｉｎＦＳスキーマ名前空間である。

ＷｉｎＦＳ型システムは、１組の単純スカラー型を宣言する。こうした型は、ＷｉｎＦＳ型システムにおいて、他のすべての型に対する最も基本的な要素ビルディングブロックとして使われる。こうした型は、スキーマ名前空間Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．ＷｉｎＦＳ中で宣言される。以下のテーブルは、基本要素型の組を定義する。

ＷｉｎＦＳ列挙とは、値リストと呼ばれる１組の名前つき定数を宣言するスカラー型である。列挙型は、スカラー型を使うことができるどの場所でも使うことができる。以下に、列挙宣言の例を挙げる。

列挙の値は、ゼロを基準とする。上の例において、Ｇｅｎｄｅｒ．Ｍａｌｅは、値０を表し、Ｇｅｎｄｅｒ．Ｆｅｍａｌｅは、値１を表す。

複合型は、名称および１組のプロパティによって定義される。「プロパティ」とは、型のメンバーフィールドであり、名称および型によって定義される。「プロパティ」の型は、スカラー（列挙型を含む）、または他の複合型でよい。「プロパティ」の型として使うことができるＷｉｎＦＳ型は、ネスト型と呼ばれる。ネスト型のインスタンスは、複合ＷｉｎＦＳ型の「プロパティ」の値としてのみ存在することができ、インスタンスは、複合型のインスタンスにネストされる。ネスト型は、ＮｅｓｔｅｄＴｙｐｅスキーマ要素を使って宣言される。以下に、有効な型宣言のいくつかの例を挙げる。

「文字列」および「バイナリ」型のプロパティに対して、「サイズ」属性が指定されなければならない。この属性は、「プロパティ」に含まれる値の最大サイズを指定する。「プロパティ」は、ヌルでよいという制約を、「Ｎｕｌｌａｂｌｅ」属性を使って任意選択で宣言することができる。この属性に対する値「ｆａｌｓｅ」は、型のインスタンスを作成するときに、アプリケーションが値を提供しなければならないことを示す。別の任意選択の「プロパティ」属性は、「プロパティ」のデフォルト値を指定する「デフォルト」属性である。この値は、アプリケーションが値を提供しない場合、インスタンス作成時に「プロパティ」に割り当てられる。

上の例のＡｄｄｒｅｓｓプロパティは、ＭｕｌｔｉＳｅｔ型である。ＭｕｌｔｉＳｅｔ型のプロパティは、多値プロパティとも呼ばれる。この例において、ＭｕｌｔｉＳｅｔは、Ａｄｄｒｅｓｓ型の１組のインスタンスを含む。ＭｕｌｔｉＳｅｔは、コレクションに類似している。ＭｕｌｔｉＳｅｔは、複合型のゼロ以上のインスタンスを含み得る。ＭｕｌｔｉＳｅｔ中のインスタンスの型は、複合ネスト型でなければならない。ＭｕｌｔｉＳｅｔ型は、ＷｉｎＦＳスカラー型（列挙型を含む）のインスタンスをサポートしない。ＭｕｌｔｉＳｅｔ型の「プロパティ」は、ヌルになることはできず、デフォルト値をもつことができない。

ＷｉｎＦＳは、型の単一継承をサポートする。ＷｉｎＦＳにおけるすべての型は、唯一のＷｉｎＦＳ型から継承しなければならない。継承型は、派生型と呼ばれ、この型を派生した型は、基本型と呼ばれる。ＢａｓｅＴｙｐｅ中の基本型は、ＷｉｎＦＳ型宣言要素によって作成される。型Ａは、基本型Ｂから派生し、型Ｂは、型Ｃから派生すると仮定する。型Ｃは、型ＡおよびＢの祖先型である。型Ａは、型ＢおよびＣの子孫型である。ＷｉｎＦＳに格納されるデータインスタンスは、常に単一の型のインスタンスである。しかし、そのデータインスタンスを、型およびそのすべての祖先型を含む１組の型のインスタンスとして扱うことができる。このような１組の型のインスタンスであるデータインスタンスに対して、組の中の他のどの型の祖先でもない型を、最終派生型と呼ぶ。単一型指定データインスタンスとは、ただ１つの最終派生型のインスタンスである。概して、単一型指定要素の最終派生型を、その要素の型と呼ぶ。派生型は、その基本型において宣言されるプロパティをすべて継承する。派生型は、新しいプロパティを宣言することができるが、基本型において定義されるプロパティをオーバーライドすることができない。派生型において宣言されるプロパティは、基本型のプロパティと同じ名称を使ってはならない。

データモデルにおける継承の主な利点は、継承型の代用可能性に由来する。以下の例を検討してみる。

上記の例において、Ｐｅｒｓｏｎ型は、Ｎａｍｅ型の「プロパティ」ＲｅａｌＮａｍｅおよび１組のＮａｍｅ型である「プロパティ」ＯｔｈｅｒＮａｍｅｓをもつ。通常、ＲｅａｌＮａｍｅという「プロパティ」は、名称型であるインスタンスのみをもつことが要求される。ただし、継承を用いると、Ｎａｍｅ型が、その要素の最終派生型の祖先の１つである限り、単一値インスタンスは、ＲｅａｌＮａｍｅの値をもつことが可能になる。したがって、ＮａｍｅＷｉｔｈＭｉｄｄｌｅＩｎｉｔｉａｌのインスタンスは、ＲｅａｌＮａｍｅ「プロパティ」の値となることが可能になる。

同じ規則が、セットプロパティに拡張される。ＯｔｈｅｒＮａｍｅｓ「プロパティ」は、１組の要素を含む。その組のメンバーである単一型の各インスタンスごとに、そのインスタンスの最終派生型は、その祖先の１つとしてＮａｍｅをもたなければならない。したがって、ＯｔｈｅｒＮａｍｅｓ組の中のインスタンスの一部は、Ｎａｍｅ型のインスタンスでよく、他のインスタンスは、ＮａｍｅＷｉｔｈＭｉｄｄｌｅＩｎｉｔｉａｌ型のインスタンスでよい。

継承は、ＷｉｎＦＳシステムにおいて、ある特定の型のすべてのインスタンスを見つけることが可能であるという点で、好都合な照会も可能にする。ある型のすべてのインスタンスを探すとき、クエリエンジンは、最終派生型がこの型の子孫であるすべてのインスタンスも返す。ただし、こうした動作は、（「プロパティ」型ではなく）「アイテム」、「拡張」、および「関係」型に対してのみサポートされる。ネスト型（別名、「ネスト要素」、「プロパティ」、または複合プロパティ型）の場合は、単一のマルチセット「プロパティ」に含まれるインスタンスに対してのみ、動作がサポートされる。

Ｂ． 型ファミリ
要するに、ＷｉｎＦＳ型システムは、４つの特殊型ファミリを定義する。
・「ネスト要素」型（別名、「ネストされた」型または「プロパティ」型）
・「アイテム」型
・「関係」型
・「拡張」型
各型ファミリは、ＷｉｎＦＳ型システムにおいて、異なる１組のプロパティおよび使用法を有する。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅスキーマ名前空間は、型ファミリそれぞれのルート型として働く４つの型を宣言する。以下のセクションでは、型ファミリを詳しく記述する。

１． ネスト要素型
他のＷｉｎＦＳ型ファミリとは異なり、ネスト型は、複合ＷｉｎＦＳ型のプロパティの型として使うことができる。ネスト型のインスタンスは、別の複合型のインスタンス内部でのみネストすることができる。ただし、ネスト型のインスタンスは、全域的に照会することができない。つまり、アプリケーションは、ＷｉｎＦＳストア中の所与のネスト型のすべてのインスタンスを返す単純クエリを組み立てることができない。

２． アイテム型
ＷｉｎＦＳ「アイテム」とは、祖先がＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍ型である型のインスタンスである。この型は、「アイテム」型ファミリのルートである複合型である。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｉｔｅｍは、Ｇｕｉｄ型の名称ＩｔｅｍＩｄの「プロパティ」を宣言する。このプロパティは、「アイテム」の一次キーとして働く、「アイテム」の特殊なプロパティである。この「プロパティ」の値は、所与のＷｉｎＦＳストア中で、「アイテム」に対して一意であることが保証される。このプロパティは、ヌルになることはなく、「アイテム」型のインスタンスを作成するときにアプリケーションによって割り当てられなければならない。ＩｔｅｍＩｄ「プロパティ」は、不変でもあり、絶対に変えることはできず、再利用してはならない。

クエリエンジンは、ＷｉｎＦＳストア中の所与の「アイテム」型のインスタンスを返すことができる。このクエリは、その型のすべてのインスタンスおよびすべてのその型の子孫型を返すことができる。後で本明細書において、「アイテム」がＷｉｎＦＳシステム動作セマンティクス中でもつ中心的役割が記述される。

３． 関係型
関係型により、「関係」は、「アイテム」の間に存在することが可能になる。ＷｉｎＦＳ「関係」型は、ある「アイテム」がソースとして指定され、他の「アイテム」がターゲットとして指定されるバイナリ「関係」を記述する。「関係」とは、祖先がＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐ型である型のインスタンスである。この型は、「関係」型階層のルートである。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｅｌａｔｉｏｎｓｈｉｐ型は、以下のプロパティを宣言する。
・ＳｏｕｒｃｅＩｔｅｍＩｄ：「関係」インスタンスのソースである「アイテム」のＩｔｅｍＩｄ
・ＲｅｌａｔｉｏｎｓｈｉｐＩｄ：ソース「アイテム」に相対的。ペア（ＳｏｕｒｃｅＩｔｅｍＩｄ，ＲｅｌａｔｉｏｎｓｈｉｐＩｄ）が、ＷｉｎＦＳにおいて「関係」型用の一次キーを形成する
・ＴａｒｇｅｔＩｔｅｍＩｄ：「関係」のターゲットのＩｔｅｍＩｄ
・Ｍｏｄｅ：３つの起こり得る「関係」インスタンスモード、すなわち「保持」、「埋込み」、または「参照」の１つ
・Ｎａｍｅ：保持「関係」用の「関係」の名称を含む
・ＩｓＨｉｄｄｅｎ：アプリケーションが、表示する必要がない「関係」をフィルタリングするのに任意選択で使うことができるブール値属性
ＳｏｕｒｃｅＩｔｅｍＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄ、ＴａｒｇｅｔＩｔｅｍＩｄ、およびＭｏｄｅ「プロパティ」値は不変である。こうした値は、「関係」インスタンス作成時に割り当てられ、変えることができない。

「関係」型は、以下の追加制約を有する複合型として宣言される。
・ソースおよびターゲットエンドポイントの指定：各エンドポイントが、参照「アイテム」の名称および型を指定する。
・「関係」型のインスタンスの許可されるモード：「関係」インスタンスは、「関係」宣言において許可されないＭｏｄｅ「プロパティ」の値をもつことができない
以下は、「関係」宣言の例である。

ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ「関係」は、インスタンスを「保持」または「参照」モードに制限して宣言される。この宣言は、ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ「関係」のインスタンスが、Ｍｏｄｅ＝「Ｒｅｆｅｒｅｎｃｅ」またはＭｏｄｅ＝「Ｈｏｌｄｉｎｇ」という値のインスタンスをもち得ることを意味する。Ｍｏｄｅ＝「Ｅｍｂｅｄｄｉｎｇ」という値をもつインスタンスは、許可されない。

「関係」は、「アイテム」型「Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔ」の「ドキュメント」という名前のソースエンドポイントおよび「Ｃｏｒｅ．Ｃｏｎｔａｃｔ」型のターゲットエンドポイントを宣言する。関係は、２つの追加プロパティも宣言する。「関係」インスタンスは、アイテムとは別々に格納されアクセスされる。すべての「関係」型インスタンスは、グローバル「関係」ビューからアクセス可能である。「関係」の所与の型のインスタンスすべてを返すクエリを組み立てることができる。

「アイテム」を与えられると、「関係」のＳｏｕｒｃｅＩｔｅｍＩｄ「プロパティ」に基づいて、「アイテム」がソースとなっている「関係」をすべて列挙することができる。同様に、所与の「アイテム」に対して、「関係」のＴａｒｇｅｔＩｔｅｍＩｄ「プロパティ」に基づいて、「アイテム」がターゲットとなっている、同じストア中の「関係」をすべて列挙することができる。

ａ）関係のセマンティクス
以下のセクションでは、様々な「関係」インスタンスモードのセマンティクスについて述べる。

保持関係：保持関係は、参照カウントに基づく、ターゲット「アイテム」の存続期間管理をモデル化するのに使われる。「アイテム」は、「アイテム」へのゼロ以上の関係に対するソースエンドポイントになり得る。「埋込み」アイテムでない「アイテム」は、１つまたは複数の保持関係のターゲットになり得る。ターゲット「アイテム」は、「関係」インスタンスと同じストア中になければならない。

保持関係は、ターゲットエンドポイントの存続期間管理を強制する。保持関係インスタンス、およびこのインスタンスがターゲットとしている「アイテム」の作成は、アトミック動作である。同じ「アイテム」をターゲットとしている追加保持関係インスタンスを作成することができる。所与の「アイテム」をターゲットエンドポイントとしてもっている最後の保持関係インスタンスが消去されると、ターゲット「アイテム」も消去される。

「関係」宣言において指定されたエンドポイント「アイテム」の型は、その「関係」のインスタンスが作成されると強制される。エンドポイント「アイテム」の型は、「関係」が確立された後は変えることができない。

保持「関係」は、ＷｉｎＦＳ「アイテム」名前空間の形成において重要な役割を果たす。すべての保持「関係」が、名前空間宣言中にある。「関係」宣言における「名称」プロパティは、ソース「アイテム」に相対したターゲット「アイテム」の名称を定義する。この相対名は、所与の「アイテム」から発生した保持関係すべてに対して一意であり、ヌルになることはできない。ルート「アイテム」から始まり、所与の「アイテム」までの、この相対名の順序つきリストは、「アイテム」に対する完全な名称を形成する。

保持関係は、有向非循環グラフ（ＤＡＧ）を形成する。保持関係が作成されると、システムは、確実にサイクルが作成されないようにし、したがって、ＷｉｎＦＳ「アイテム」名前空間がＤＡＧを確実に形成するようにする。ＷｉｎＦＳ名前空間および「アイテム」パスのこれ以上の情報については、「ＷｉｎＦＳ名前空間」仕様を参照されたい。

埋込み「関係」：埋込み「関係」は、ターゲット「アイテム」の存続期間の、排他的制御の概念をモデル化する。埋込み関係は、合成「アイテム」の概念を可能にする。埋込み「関係」インスタンス、およびこのインスタンスがターゲットとしている「アイテム」の作成は、アトミック動作である。「アイテム」は、ゼロ以上の埋込み「関係」のソースとなり得る。ただし、「アイテム」は、唯一の埋込み「関係」のターゲットとなり得る。埋込み「関係」のターゲットである「アイテム」は、保持「関係」のターゲットになることができない。ターゲット「アイテム」は、「関係」インスタンスと同じストア中になければならない。

「関係」宣言において指定されたエンドポイント「アイテム」の型は、その「関係」のインスタンスが作成されると強制される。エンドポイント「アイテム」の型は、「関係」が確立された後は変えることができない。埋込み「関係」は、ＷｉｎＦＳ名前空間中にない。埋込み「関係」の「名称プロパティ」の値は、ヌルでなければならない。

参照「関係」：参照「関係」は、それが参照する「アイテム」の存続期間を制御しない。さらに、参照「関係」は、ターゲットの存在も保証せず、「関係」宣言において指定されたターゲットの型も保証しない。このことは、参照「関係」が不安定な状態となり得ることを意味する。また、参照「関係」は、他のＷｉｎＦＳストア中の「アイテム」を参照することができる。

ＷｉｎＦＳにおいて、参照「関係」は、「アイテム」の間のほとんどの非存続期間管理「関係」をモデル化するのに使われる。ターゲットの存在は強制ではないので、参照「関係」は、疎結合「関係」をモデル化するのに好都合である。参照「関係」は、他のマシン上のストアを含む他のＷｉｎＦＳストア中の「アイテム」をターゲットにするのに使うことができる。埋込み「関係」は、ＷｉｎＦＳ名前空間中にない。埋込み「関係」の「名称プロパティ」の値は、ヌルでなければならない。

ｂ）関係の規則および制約
以下の追加規則および制約が、「関係」に適用される。
・「アイテム」は、（ただ１つの埋込み「関係」）あるいは（１つまたは複数の保持「関係」）のターゲットでなければならない。ただ１つの例外は、ルート「アイテム」である。「アイテム」は、ゼロ以上の参照「関係」のターゲットとなり得る。
・埋込み「関係」のターゲットである「アイテム」は、保持「関係」のソースになることができない。参照「関係」のソースにはなり得る。
・「アイテム」は、ファイルからプロモートされる場合、保持「関係」のソースになることができない。埋込み「関係」および参照「関係」のソースにはなり得る。
・ファイルからプロモートされる「アイテム」は、埋込み「関係」のターゲットになることができない。

「関係」型Ａが基本「関係」型Ｂから派生されるとき、以下の規則が適用される。
・「関係」型Ａは、エンドポイント型をさらに制限することができる。エンドポイント型は、基本「関係」Ｂ中の、対応するエンドポイント型のサブ型でなければならない。エンドポイントがさらに制限される場合、エンドポイント用の新しい名称が宣言されなければならない。エンドポイントが制限されない場合、エンドポイントの指定は任意選択である。
・「関係」型Ａは、基本「関係」において宣言される許可されるインスタンスモードをさらに制限することができる。インスタンスモードの制限された組は、許可されるインスタンス型の基本型セットのサブセットでなければならない。
・エンドポイントの名称は、「プロパティ」名として扱われる。すなわち、「プロパティ」の名称と同じものにも、型またはその基本型のエンドポイントの名称と同じものにもなることができない。
・「ソース」および「ターゲット」要素は、対応するエンドポイント型が、派生「関係」によってそれ以上制限されない場合、任意選択である。
本明細書において上で定義されたＤｏｃｕｍｅｎｔＡｕｔｈｏｒ「関係」から派生する「関係」型の宣言例を以下に挙げる。

ＬｅｇａｌＤｏｃｕｍｅｎｔＡｕｔｈｏｒ「関係」は、ソースエンドポイントをさらに制限するが、ターゲットエンドポイントは制限しない。ソースエンドポイント型は、Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔから派生するＬｅｇａｌ．Ｄｏｃｕｍｅｎｔである。ターゲットエンドポイントは、この場合はそれ以上制限を受けないので、ターゲット要素は省略される。「関係」はまた、許可されるインスタンスモードをさらに制限する。「関係」は、「保持」モードを許可せず、残る唯一の許可されるモードは、「参照」である。

４． 拡張型
ＷｉｎＦＳ「拡張」とは、祖先がＳｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｅｘｔｅｎｓｉｏｎ型である型のインスタンスである。この型は、「拡張」型ファミリのルートである複合型である。
・Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｅｘｔｅｎｓｉｏｎは、以下の２つのプロパティを定義する。
・ＩｔｅｍＩｄ：「拡張」と関連づけられる「アイテム」のＩｔｅｍＩｄ
・ＥｘｔｅｎｓｉｏｎＩｄ：ＩｔｅｍＩｄに相対する、「拡張」の一意な識別子。ペア（ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ）は、「拡張」インスタンスを一意に識別する。

以下の制限が、「拡張」型に適用される。
・拡張型インスタンスは、「アイテム」から独立して存在することができない。「拡張」ＩｔｅｍＩｄと同じＩｔｅｍＩｄをもつ「アイテム」型インスタンスは、「拡張」型インスタンスが作成される前にストアに存在しなければならない。所与のＩｔｅｍＩｄをもつ「アイテム」が存在しない場合、「拡張」は、作成することができない。「アイテム」が消去されると、同じＩｔｅｍＩＤをもつ「拡張」がすべて消去される。
・所与の最終派生「拡張」型の多くとも１つのインスタンスを、個々の「アイテム」に関連づけることができる。
・拡張は、「関係」のソースおよびターゲットになることができない。

所与の「アイテム」型に関連づけることができる「拡張」の型に対する制約はない。どの「拡張」型も、あらゆる「アイテム」型を拡張することができる。異なる「拡張」型の複数のインスタンスが「アイテム」に付加されるとき、こうしたインスタンスは、構造およびビヘイビア両方において互いに独立している。「拡張」インスタンスは、「アイテム」とは別々に格納されアクセスされる。すべての「拡張」型インスタンスは、グローバル「拡張」ビューからアクセス可能である。どのような型の「アイテム」にインスタンスが関連づけられているかに関わらず、「拡張」の所与の型のインスタンスすべてを返すクエリを組み立てることができる。「拡張」のＩｔｅｍＩｄは、拡張がどのアイテムに属すかを示し、グローバル「アイテム」ビューから、対応する「アイテム」オブジェクトを取得するのに使うことができる。また、「アイテム」を与えられると、「拡張」のＩｔｅｍＩｄ「プロパティ」を使って、「アイテム」に関連づけられたすべての「拡張」インスタンスを列挙することができる。

Ｃ． 拡張機能
本発明のいくつかの実施形態では、ハードウェア／ソフトウェアインターフェイスシステムは、様々な「アイテム」の間の関係を明確な形にするとともにそうすることによって複数の「アイテム」を照会する能力を向上させるために、「拡張」および「継承」を使用する。

１． 継承
図３６は、一連の相互に関係付けられた「アイテム」と、その「関係」サブセットとを示す。「ドキュメントアイテム」３６０２および「連絡先アイテム」３６０４は、指定された関係３６０６によって直接関係づけられ、関係３６０６は、この場合、「作者関係」である。つまり、「連絡先」３６０４は、「ドキュメント」３６０２の「作者」である。この例では、各「アイテム」の型が「ドキュメントアイテム」型のサブ型なので、「ピクチャアイテム」３６２２、「ミュージックアイテム」３６２４、および「スペシャルアイテム」３６２６はすべて、「ドキュメントアイテム」３６０４から継承を行う。同様に、「人」という「アイテム」３６４２および「組織アイテム」３６４４は、「連絡先アイテム」３６０４から継承を行う。本発明のいくつかの実施形態では、「アイテム」（「ピクチャ」３６２２、「ミュージック」３６２４、「スペシャル」３６２６、「人」３６４２、および「組織」３６４４）のこうした継承は、それぞれの親「アイテム」（「ドキュメント」３６０２および「連絡先」３６０４）の「プロパティ」を継承するだけでなく、こうした２つの親「アイテム」の間の指定された「関係」も継承する。たとえば、「ピクチャ」３６２２は、「連絡先」３６０４への関係３６６２、「人」３６４２への関係３６６４、および「組織」３６４４への関係３６６６を継承する。同様の１組の「関係」も、図に示す他の「アイテム」それぞれによって継承される。

ただし、関係の継承は自動的でなく、すべてのコンテキストにおいて起こるわけではないことに留意されたい。たとえば、型を継承することができるときを記述する属性（すなわち、継承制御）自体は継承可能でない。継承パラメータは、ハードウェア／ソフトウェアインターフェイスシステムによって維持され規制される。

２． 拡張
図３７Ａは、アプリケーション特有の目的のための、「アイテム」の標準的なサブ型指定の欠点を示す。この図において、「連絡先」は、４つのアプリケーション、ＡＰＰ１、ＡＰＰ２、ＡＰＰＸ、およびＡＰＰＹによってアクセス可能である。ＡＰＰ１およびＡＰＰ２は、標準「連絡先」にアクセスするが、ＡＰＰＸおよびＡＰＰＹそれぞれは、拡張連絡先オブジェクトを必要とする（追加フィールドを追加する）ので、「連絡先」からそれぞれ継承する「連絡先’」および「連絡先”」を派生する。しかし、問題は、この時点で、基本的な「連絡先アイテム」の３つの異なるインスタンスが、１つは「連絡先」として、１つは「連絡先’」として、１つは「連絡先”」として存在することである。

図３７Ｂに示す、この問題に対する部分的なソリューションは、「連絡先」のプロパティを、このようなプロパティを要求するアプリケーションに必要なフィールドを含むように拡張することである。この場合、「連絡先」は、ＡＰＰＸによって要求される追加フィールドを含むように拡張される。ただし、「連絡先」などの「アイテム」のフィールドの直接拡張は、一度しか行うことができないので、ＡＰＰＹは、この方法を利用することができない。

本発明の一実施形態において、より包括的なソリューションは、図３７Ｃに示すように、「連絡先」自体とは別個の「拡張」を用いて「連絡先」を拡張することである。この方法において、ＡＰＰＸは、ＡＰＰＸ「追加フィールド」を含むように「連絡先」を拡張することができ、ＡＰＰＹも、ＡＰＰＹ「追加フィールド」を含むように「連絡先」を別個に拡張することができる。こうした「拡張」は次いで、それ自体が検索可能かつ照会可能になるので、こうした「拡張」により、ハードウェア／ソフトウェアインターフェイスシステム用に多重型指定という形が可能になる。

ＩＶ． 結論
上記の説明のように、本発明は、データを組織化し、検索し、共有するストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、既存のファイルシステムおよびデータベースシステムを上回るようにデータプラットフォームを拡張し拡大し、リレーショナル（テーブル形式）データ、ＸＭＬ、およびアイテムと呼ばれる新しい形のデータなど、構造化、非構造化、または半構造化データを含むあらゆるタイプのデータ用のストアとなるように設計される。共通の記憶基盤およびデータの体系化により、本発明のストレージプラットフォームは、消費者、知識労働者、および企業に対して、より効率的なアプリケーション開発を可能にする。本発明のストレージプラットフォームは、データモデル中で継承される性能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法も包含し拡張する、豊富かつ拡張可能なアプリケーションプログラミングインターフェイスを提供する。本発明の広範な概念から逸脱することなく、上述した実施形態に変更を加えることができることを理解されたい。したがって、本発明は、開示した具体的な実施形態に限定されず、添付の特許請求の範囲によって定義される本発明の精神および範囲内であるすべての修正形態を包含することを意図している。

上記の内容から明らかなように、本発明の様々なシステム、方法、および態様は、プログラムコード（すなわち、命令）の形で実装することができる。このプログラムコードは、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ハードディスクドライブ、または他のどのマシン可読記憶媒体も含むがそれに限定されない磁気、電気、または光学記憶媒体などのコンピュータ可読媒体に格納することができ、プログラムコードがコンピュータやサーバなどのマシンにロードされるとともにそれによって実行されると、マシンは本発明を実施する装置となる。本発明は、たとえば、電気的接続またはケーブル布線、光ファイバ、インターネットやイントラネットを含むネットワーク、あるいは他のどの伝送の形でもよい何らかの伝送媒体を介して伝送されるプログラムコードの形で実現することもでき、プログラムコードが受信され、コンピュータなどのマシンにロードされるとともにそれによって実行されると、マシンは、本発明を実施する装置となる。汎用プロセッサ上で実装されると、プログラムコードは、プロセッサと結合して、具体的な論理回路と同様に動作する独自の装置を提供する。

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

Claims (7)

1. プロセッサと、
   前記プロセッサと通信するメモリと
   を備えるハードウェア／ソフトウェアインターフェイスシステムによって実行され、前記ハードウェア／ソフトウェアインターフェイスシステムが格納可能及びアクセス可能な情報単位をカスタマイズする方法であって、前記ハードウェア／ソフトウェアインターフェイスシステムは、
   型構造を有する情報単位を作成するステップであって、前記情報単位は、前記情報単位を一意に識別するための第１の識別子を有する、ステップと、
   アプリケーションによって要求される追加のデータ構造の拡張を表す拡張型を定義するステップと、
   前記拡張型に基づいて拡張インスタンスを作成するステップであって、前記拡張インスタンスは、前記第１の識別子と前記拡張型を一意に識別するための第２の識別子とを含み、前記第１の識別子を含むことによって前記情報単位と関連付けられ、前記第１の識別子及び前記第２の識別子によって前記拡張インスタンスが一意に識別される、ステップと、
   前記拡張インスタンスを前記情報単位に付加して前記情報単位を拡張するステップと
   を含む方法を実行することを特徴とする方法。
2. 前記拡張型は、拡張された情報単位の前記型構造とは別個に存在することができないことを特徴とする請求項１に記載の方法。
3. 前記拡張型を定義するステップは、複数の拡張型を定義し、前記複数の拡張型の各々は追加のデータ構造を表すステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
4. 前記拡張型は、重複する型インスタンスをモデル化するのに使われることを特徴とする請求項３に記載の方法。
5. 複数の別個の格納可能な情報単位を扱うハードウェア／ソフトウェアインターフェイスシステムであって、前記ハードウェア／ソフトウェアインターフェイスシステムは、
   プロセッサ実行可能命令を実行するように設定されたプロセッサと、
   前記プロセッサと通信するメモリであって、前記プロセッサ実行可能命令を格納する、メモリとを備え、前記プロセッサは、
   型構造を有する情報単位を作成し、前記情報単位は、前記情報単位を一意に識別するための第１の識別子を有し、
   アプリケーションによって要求される追加のデータ構造の拡張を表す拡張型を定義し、
   前記拡張型に基づいて拡張インスタンスを定義し、前記拡張インスタンスは、前記第１の識別子と前記拡張型を一意に識別するための第２の識別子とを含み、前記第１の識別子を含むことによって前記情報単位と関連付けられ、前記第１の識別子及び前記第２の識別子によって前記拡張インスタンスが一意に識別され、
   前記拡張インスタンスを前記情報単位に付加して前記情報単位を拡張する、
   ための前記プロセッサ実行可能命令を実行することを特徴とするハードウェア／ソフトウェアインターフェイスシステム。
6. 前記拡張型は、拡張された情報単位の前記型構造とは別個に存在することができないことを特徴とする請求項５に記載のハードウェア／ソフトウェアインターフェイスシステム。
7. 複数の拡張型を定義し、複数の前記拡張型の各々は、追加のデータ構造を表す、
   前記プロセッサ実行可能命令をさらに備えることを特徴とする請求項５に記載のハードウェア／ソフトウェアインターフェイスシステム。

Images