JP4580389B2

JP4580389B2 - 仲介ファイルシステム共有または仲介デバイスを介してコンピュータシステムを同期させるためのシステムおよび方法

Info

Publication number: JP4580389B2
Application number: JP2006523868A
Authority: JP
Inventors: シャーダーシャトクマー; ノビクレブ; ダブリュ．トーマスマイケル; エイチ．ペールマンニルス; エケルオオケチュクオ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-08-21
Filing date: 2004-07-29
Publication date: 2010-11-10
Anticipated expiration: 2024-07-29
Also published as: EP1573600A2; CN1781096A; JP2007527053A; WO2005024551A3; WO2005024551A2; EP1573600A4; CN100565505C

Description

本出願は、２００４年４月３０日に出願した米国特許仮出願第６０／５６７１４１号明細書（代理人整理番号ＭＳＦＴ−３９３９／３０６７２７．０１）の恩典を主張する、「仲介ファイルシステム共有または仲介デバイスを介してコンピュータシステムを同期させるためのシステムおよび方法」という名称の、２００４年７月１２日に出願した米国特許出願第（まだ用意されていない）号明細書の優先権を主張し、本出願は、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位のピアツーピア同期に関する競合処理を提供するためのシステムおよび方法」という名称の、２００４年６月３０日に出願した米国特許第出願公開第１０／８８３６２１号明細書（代理人整理番号ＭＳＦＴ−２８５４）の一部継続出願でもあり、米国特許第出願公開第１０／８８３６２１号明細書は、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位に関するリレーショナル階層型の同期サービスを提供するためのシステムおよび方法」という名称の、２００３年１０月２４日に出願した米国特許出願公開第１０／６９２５０８号明細書（代理人整理番号ＭＳＦＴ−２８４５）の一部継続出願であり、米国特許出願公開第１０／６９２５０８号明細書は、「データの編成、探索、および共有を行うためのストレージプラットフォーム」という名称の２００３年８月２１日に出願した米国特許出願公開第１０／６４６６４６号明細書（代理人整理番号ＭＳＦＴ−２７３４）の一部継続出願であり、また、本出願は、参照により開示の全体が本明細書に組み込まれている、２００３年８月２１日に出願した国際特許出願ＰＣＴ／ＵＳ０３／２７４１９（代理人整理番号）の優先権も主張する。

本出願の主題は、内容の全体が本出願に組み込まれている（便宜のため本明細書で一部を要約する）、以下の同一出願人による出願において開示される発明に関係する。すなわち、「ハードウェア／ソフトウェアインターフェースシステムが扱うことができるが、物理的表現とは独立の情報の単位を表すためのシステムおよび方法」という名称の、２００３年８月２１日に出願した米国特許出願公開第１０／６４７０５８号明細書（代理人整理番号ＭＳＦＴ−１７４８）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位をその情報の単位の物理的編成から分離するためのシステムおよび方法」という名称の、２００３年８月２１日に出願した、米国特許出願公開第１０／６４６９４１号明細書、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位を編成するための基礎スキーマを実施するためのシステムおよび方法」という名称の、２００３年８月２１日に出願した米国特許出願公開第１０／６４６９４０号明細書（代理人整理番号ＭＳＦＴ−１７５０）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位を編成するための最上レベル構造を提供するためのコアスキーマを実施するためのシステムおよび方法」という名称の、２００３年８月２１日に出願した、米国特許出願公開第１０／６４６６３２号明細書（代理人整理番号ＭＳＦＴ−１７５１）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位の間の関係を表すためのシステムおよび方法」という名称の、２００３年８月２１日に出願した米国特許出願公開第１０／６４６６４５号明細書（代理人整理番号ＭＳＦＴ−１７５２）、「アプリケーションプログラム群を項目ベースのストレージプラットフォームと結び付けるためのシステムおよび方法」という名称の、２００３年８月２１日に出願した米国特許出願公開第１０／６４６５７５号明細書（代理人整理番号ＭＳＦＴ−２７３３）、「項目ベースのストレージプラットフォームにおけるデータモデル化のためのシステムおよび方法」という名称の、２００３年８月２１日に出願した米国特許出願公開第１０／６４６５８０号明細書（代理人整理番号ＭＳＦＴ−２７３５）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位を編成するためのデジタルイメージスキーマを実施するためのシステムおよび方法」という名称の、２００３年１０月２４日に出願した米国特許出願公開第１０／６９２７７９号明細書（代理人整理番号ＭＳＦＴ−２８２９）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位に関する同期サービスを提供するためのシステムおよび方法」という名称の、２００３年１０月２４日に出願した米国特許出願公開第１０／６９２５１５号明細書（代理人整理番号ＭＳＦＴ−２８４４）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位に関する同期スキーマを実施するためのシステムおよび方法」という名称の、２００３年１０月２４日に出願した米国特許出願公開第１０／６９３３６２号明細書（代理人整理番号ＭＳＦＴ−２８４６）、および「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位に関する拡張および継承のためのシステムおよび方法」という名称の、２００３年１０月２４日に出願した米国特許出願公開第１０／６９３５７４号明細書（代理人整理番号ＭＳＦＴ−２８４７）である。

本発明は、一般に、同期に関し、より詳細には、共通のストレージプラットフォーム（例えば、ＷｉｎＦＳ）を利用するが、異なる仲介ファイルシステムＡＰＩ（アプリケーションプログラミングインターフェース）アクセス可能なファイル共有または他のストレージデバイス（例えば、ＡＰＩアクセス可能なＷｉｎ３２ファイル共有または他のストレージデバイス）を介して同期を行い、データ共有、エンドユーザローミング（ローミングエンドユーザプロファイル、および均等物を含むが、以上には限定されない）、および他の同期目的をサポートする、２つ以上のコンピュータ間の同期に関する。

過去１０年にわたって個々のディスク容量は、およそ毎年７０％（パーセント）で成長してきた。ムーアの法則が、長年にわたって生じたＣＰＵ（中央処理装置）能力の途方もない伸び（ｇａｉｎ）を正確に予測した。有線技術および無線技術が、途方もない接続および帯域幅を提供している。現在の傾向が続くものと想定すると、数年以内に、平均的なラップトップコンピュータは、およそ１ＴＢ（テラバイト）のストレージを有し、数百万のファイルを含み、５００ＧＢ（ギガバイト）のドライブが一般的になる。

消費者は、自分のコンピュータを主に、通信のため、ならびに従来のＰＩＭ（個人情報マネージャ）スタイルデータであるか、デジタル音楽またはデジタル写真などのメディアであるかにかかわらず、個人情報を編成するために使用する。デジタルコンテンツの量、および生のバイトを格納する能力は、途方もなく増大している。しかし、そのデータを編成するため、および統一するために消費者が利用できる方法は、遅れを取っている。知識労働者は、情報を管理すること、および共有することに莫大な時間を費やし、一部の研究は、知識労働者が、自分の時間の１５〜２５％を非生産的な情報関連活動に費やしていると推定している。他の研究は、典型的な知識労働者が、情報を探索することに１日当たり２．５時間を費やすと推定している。

開発者およびＩＴ（情報技術）部門は、人々、場所、時刻、およびイベントなどを表す一般的なストレージ抽象化のための独自のデータストアを構築することに相当な時間と金額を投資している。これにより、重複した作業がもたらされるだけでなく、データの一般的な探索または共有のためのメカニズムをまったく有さない、一般的なデータの島々が作られる。ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムを実行するコンピュータ上に今日、どれだけ数のアドレス帳が存在することが可能であるかを考慮されたい。電子メールクライアントや個人財務（ｐｅｒｓｏｎａｌｆｉｎａｎｃｅ）プログラムなどの多くのアプリケーションが、個々のアドレス帳を保持し、アプリケーション間で、それぞれのそのようなプログラムが個々に保持するアドレス帳の共有は、ほとんど行われない。したがって、財務プログラム（ＭｉｃｒｏｓｏｆｔＭｏｎｅｙのような）は、支払い先のアドレスを電子メール連絡先フォルダ（ＭｉｃｒｏｓｏｆｔＯｕｔｌｏｏｋのような）内に保持されるアドレスと共有しない。実際、多くのユーザは、複数のデバイスを有し、それらのデバイスの間で、また、セル電話機から、ＭＳＮやＡＯＬなどの商業サービスを含む多種態様なさらなるソースにわたって自分の個人データを同期させることを論理上、行わなければならない。それでも、共有されるドキュメントの共同作業（ｃｏｌｌａｂｏｒａｔｉｏｎ）は、大方、ドキュメントを電子メールメッセージに添付することにより、つまり、手動で、非効率な形で達せられる。

共同作業のこの欠如の１つの理由は、コンピュータシステムにおいて情報を編成する従来のアプローチが、ファイル−フォルダ−ディレクトリベースのシステム（「ファイルシステム」）を使用して、ファイルを格納するのに使用される記憶媒体の物理的編成の抽象化に基づくフォルダのディレクトリ階層に、複数のファイルを編成することを中心としてきたことである。１９６０年代に開発されたＭｕｌｔｉｃｓオペレーティングシステムに、ファイル、フォルダ、およびディレクトリを使用して、オペレーティングシステムレベルでデータの格納可能な単位を管理することの草分けとしての功績を認めることができる。具体的には、Ｍｕｌｔｉｃｓは、ファイルの物理アドレスがユーザ（アプリケーションおよびエンドユーザ）にトランスペアレントではないファイルの階層内で記号アドレスを使用した（それにより、ファイルパスの概念を導入した）。このファイルシステムは、いずれの個別ファイルのファイル形式にもまったく関心を払わず、ファイル間の関係は、オペレーティングシステムレベルで（つまり、階層内のファイルの位置以外は）無関係であると考えられた。Ｍｕｌｔｉｃｓの登場以来、格納可能なデータは、オペレーティングシステムレベルでファイル、フォルダ、およびディレクトリに編成されてきた。これらのファイルは、一般に、ファイルシステムによって保持される特別ファイルとして実体化されたファイル階層自体（「ディレクトリ」）を含む。このディレクトリは、このディレクトリ内の他のファイルのすべてに対応するエントリのリスト、および階層（本明細書でフォルダと呼ぶ）内のそのようなファイルのノード位置（ｎｏｄａｌｌｏｃａｔｉｏｎ）を保持する。これが、およそ４０年間、技術の現状であった。

しかし、コンピュータの物理ストレージシステム内に存在する情報の妥当な表現を提供するものの、ファイルシステムは、それでも、物理ストレージシステムの抽象化であり、したがって、ファイルの利用は、ユーザが操作するもの（文脈、特徴、および他の単位に対する関係を有する単位）と、オペレーティングシステムが提供するもの（ファイル、フォルダ、およびディレクトリ）の間である程度の遠回り（ｉｎｄｉｒｅｃｔｉｏｎ）（解釈）を要する。したがって、ユーザ（アプリケーションおよび／またはエンドユーザ）は、ファイルシステム構造に情報の単位を押し込むことを、そうすることが、非効率である、整合性を欠く、あるいはそれ以外で望ましくない場合でも行うより他ない。さらに、既存のファイルシステムは、個々のファイルの中に格納されたデータの構造についてほとんど知らず、このため、情報のほとんどは、ファイルを書き込んだアプリケーションだけがアクセスすることができる（理解可能な）ファイルの中に閉じ込められたままである。したがって、情報の概略の記述、および情報を管理するためのメカニズムのこの欠如により、データのサイロが作られることになり、個々のサイロの間でデータの共有がほとんど行われない。例えば、多くのＰＣ（パーソナルコンピュータ）ユーザは、何らかのレベルでユーザが対話する人々に関する情報を含む、５つを超える別々のストア、例えば、ＯｕｔｌｏｏｋＣｏｎｔａｃｔ、オンラインアカウントアドレス、Ｗｉｎｄｏｗｓ（登録商標）ＡｄｄｒｅｓｓＢｏｏｋ、ＱｕｉｃｋｅｎＰａｙｅｅ、およびＩＭ（インスタントメッセージング）バディ（ｂｕｄｄｙ）リストを有する。というのは、ファイルを編成することは、これらのＰＣユーザに相当な難題となるからである。ほとんどの既存のファイルシステムは、ファイルおよびフォルダを編成することに関して、入れ子型フォルダの喩えを利用するため、ファイルの数が増加するにつれ、柔軟性があり、効率的な編成スキームを維持するのに必要な労力が、怯むほどに大変になる。そのような状況では、単一のファイルの複数の分類を有することが非常に役立つが、既存のファイルシステム内でハードリンクまたはソフトリンクを使用することは、面倒であり、維持するのが困難である。

ファイルシステムの欠点に対処しようとするいくつかの失敗に終わった試みが、過去に行われている。それらの以前の試みの一部には、コンテントアドレッサブル（ｃｏｎｔｅｎｔａｄｄｒｅｓｓａｂｌｅ）メモリを使用して、物理アドレスによってではなく、内容によってデータにアクセスすることが可能なメカニズムを提供することが関与していた。しかし、これらの取り組みは、うまくいかないことが判明した。というのは、コンテントアドレッサブルメモリは、キャッシュやメモリ管理ユニットなどのデバイスによる小規模の使用に役立つことが判明したが、物理記憶媒体などのデバイスのための大規模な使用は、様々な理由で未だに可能ではなく、このため、そのような問題解決法は、単に存在しないからである。ＯＯＤＢ（オブジェクト指向データベース）システムを使用する他の試みが行われているが、それらの試みは、強力なデータベース特性および良好な非ファイル表現を特徴とする一方で、ファイル表現を扱うのに有効ではなく、ハードウェア／ソフトウェアインターフェースシステムレベルでファイル−フォルダベースの階層構造の速度、効率、および単純さを再現することができなかった。ＳｍａｌｌＴａｌｋ（およびその他の派生物）を使用しようと試みたものなどの他の試みは、ファイル表現および非ファイル表現を扱うのに極めて有効であると判明したが、様々なデータファイル間に存在する関係を効率的に編成し、利用するのに必要なデータベース機能を欠いており、このため、そのようなシステムの全体的な効率は、容認できないものであった。ＢｅＯＳ（および他のそのようなオペレーティングシステム研究）を使用しようとするさらに別の試みは、一部の必要なデータベース機能を提供しながらファイルを十分に表現することができるにもかかわらず、非ファイル表現を扱うのに不十分であると判明した。つまり、従来のファイルシステムと同一の基本的な欠点である。

データベース技術は、類似した課題が存在する別の技術分野である。例えば、リレーショナルデータベースモデルは、商業的に大いに成功しているが、実のところ、ＩＳＶ（独立ソフトウェアベンダ）が、一般に、リレーショナルデータベースソフトウェア製品（ＭｉｃｒｏｓｏｆｔＳＱＬサーバなどの）において利用可能な機能の小さな部分を実行している。代わりに、そのような製品とのアプリケーションの対話のほとんどは、単純な「ゲット（ｇｅｔ）」および「プット（ｐｕｔ）」の形態である。プラットフォーム不可知（ａｇｎｏｓｔｉｃ）またはデータベース不可知であるであるなどの、このことのいくつかの容易に明らかな理由が存在するが、しばしば、気付かれない１つの重要な理由は、データベースが、大手のビジネスアプリケーションベンダが本当に必要とするとおりの抽象化を必ずしも提供しないことである。例えば、現実世界は、「顧客」または「注文」（項目それ自体などの注文の組み込まれた「ライン項目」とともに）などの「項目」の概念を有するが、リレーショナルデータベースは、テーブルおよび行に関してだけ語る。したがって、アプリケーションは、項目レベルで整合性、ロック（ｌｏｃｋｉｎｇ）、セキュリティ、および／またはトリガの態様（いくつかを挙げると）を有することを所望する可能性があるが、一般に、データベースは、これらの機能をテーブル／行レベルにおいてだけ提供する。これは、各項目が、データベース内の何らかのテーブル内の単一の行にマップされる場合、順調に機能する可能性があるが、複数のライン項目を有する注文のケースでは、項目が、実際に、複数のテーブルにマップされる理由が存在する可能性があり、それが該当する場合、単純なリレーショナルデータベースシステムは、正しい抽象化を提供するとは言えない。したがって、アプリケーションは、それらの基本的な抽象化を提供する論理をデータベースの上に構築しなければならない。つまり、基本的なリレーショナルモデルは、より高いレベルのアプリケーションをその上で容易に開発できる、データを格納するための十分なプラットフォームを提供しない。というのは、基本的なリレーショナルモデルは、データの意味構造が、一部の場合のアプリケーションにおいてだけ見える可能性がある場合、アプリケーションとストレージシステムの間で、ある程度の遠回りを要するからである。一部のデータベースベンダは、オブジェクトリレーショナル機能、新たな編成モデルなどを提供するなどの、より高いレベルの機能をベンダの製品に組み込んでいるが、いずれも、必要とされる種類の包括的な問題解決法を未だに適用しておらず、真に包括的な問題解決法は、有用なドメイン抽象化（「個人」、「場所」、および「イベント」などの）のために両方の有用なデータモデル抽象化（「項目」、「拡張」、「関係」その他などの）を提供する問題解決法である。

既存のデータストレージ技術およびデータベース技術の以上の欠点に鑑みて、コンピュータシステムにおけるすべてのタイプのデータの編成、探索、および共有を行う向上した能力を提供する新たなストレージプラットフォーム、つまり、既存のファイルシステムおよびデータベースシステムを超えてデータプラットフォームを拡張し、広げ、すべてのタイプのデータ用のストアとなるように設計されたストレージプラットフォームの必要性が存在する。「データの編成、探索、および共有を行うためのストレージプラットフォーム」という名称の、２００３年８月２１日に出願した（特許文献１）（代理人整理番号ＭＳＦＴ−２７３４）において開示される発明が、この必要性を満たす。このストレージプラットフォーム（競合解決方法を含む）のための同期サービスが、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位に関するリレーショナル階層型同期サービスを提供するためのシステムおよび方法」という名称の、２００３年１０月２４日に出願した（特許文献２）（代理人整理番号ＭＳＦＴ−２７４５）、「ハードウェア／ソフトウェアインターフェースシステムが管理可能な情報の単位のピアツーピア同期に関する競合処理を提供するためのシステムおよび方法」という名称の、２００４年６月３０日に出願した（特許文献３）（代理人整理番号ＭＳＦＴ−２８５４／３０６９５５．０１）によって開示される発明においてさらに提供されている。

米国特許出願公開第１０／６４６６４６号明細書米国特許出願公開第１０／６４６６４６号明細書米国特許出願第（未割り当て）号明細書ＷｉｎＦＳ同期アダプタＡＰＩ［ＳＡＤＰ］仕様ＷｉｎＦＳ同期制御ＡＰＩ［ＳＣＴＲＬ］仕様

もちろん、以上の関連特許出願において説明する新たなストレージプラットフォームを最初に利用すると、様々な個々のコンピュータシステムを含む同期ネットワーク群を有する企業は、一部の個々のコンピュータシステムが、新たなストレージプラットフォームを利用する一方で、他の個々のコンピュータシステムは、レガシストレージプラットフォームを利用しつづけるという点で混合を有することになる。したがって、新たなストレージプラットフォームを利用する２つのコンピュータシステム（「クライアント」）が、レガシストレージプラットフォームを利用するコンピュータシステム（「仲介（ｉｎｔｅｒｍｅｄｉａｒｙ）」）を介して同期することが必要である可能性がある。例えば、一部のクライアントが、ＲＵＰ（ローミングユーザプロファイル）またはＣＳＣ（ＦｏｌｄｅｒＲｅｄｉｒｅｃｔｉｏｎｗｉｔｈＣｌｉｎｅｔＳｉｄｅＣａｃｈｉｎｇ）などのソフトウェアを使用して、レガシローミングサービスに登録されることが可能である。これらのレガシストレージプラットフォーム用のレガシローミングソフトウェアは、新たなストレージプラットフォームのためのローミングデータをサポートしないので、新たなストレージプラットフォーム用の新たなローミングサービスが必要である。本発明の様々な実施形態は、仲介を介するクライアント同期のためのシステムおよび方法を対象とする。

以下の概要は、本明細書に上記で参照により組み込まれた関連する発明（「関連する発明」）の文脈で説明される本発明の様々な態様の概要を提供する。この概要は、本発明の重要な態様のすべての網羅的な説明を提供する、または本発明の範囲を定義することは意図していない。むしろ、この概要は、以下の詳細な説明および図の概説の役割をすることを意図している。

関連する発明は、総体として、既存のファイルシステムおよびデータベースシステムを超えてデータストレージの概念を拡張し、広げる、データの編成、探索、および共有を行うためのストレージプラットフォームを対象とする。このストレージプラットフォームは、構造化データ、非構造化データ、または反構造化データを含め、すべてのタイプのデータのためのストアとなるように設計される。

ストレージプラットフォームは、データベースエンジン上に実装されるデータストアを含む。データベースエンジンは、オブジェクトリレーショナル拡張機能（ｅｘｔｅｎｓｉｏｎ）を有するリレーショナルデータベースエンジンを含む。データストアは、データの編成、探索、共有、同期、およびセキュリティをサポートするデータモデルを実施する。特定のタイプのデータが、スキーマの中で記述され、プラットフォームは、新たなタイプのデータ（基本的に、スキーマによって提供される基本タイプのサブタイプ）を定義するようにスキーマのセットを拡張するメカニズムを提供する。同期機能が、ユーザまたはシステムの間におけるデータの共有を容易にする。既存のファイルシステムとのデータストアの相互運用性を可能にするが、そのような従来のファイルシステムの限界を有さないファイルシステム様の諸機能が提供される。変更追跡メカニズムが、データストアに対する変更を追跡する能力を提供する。ストレージプラットフォームは、アプリケーションが、ストレージプラットフォームの以上の機能のすべてにアクセスすることができるようにし、スキーマの中で記述されたデータにアクセスすることができるようにするアプリケーションプログラムインターフェースのセットをさらに含む。

データストアによって実施されるデータモデルは、項目、要素、および関係の点でデータストレージの単位を定義する。項目は、データストアの中に格納可能なデータの単位であり、１つまたは複数の要素および関係を含むことが可能である。要素は、１つまたは複数のフィールド（本明細書でプロパティとも呼ぶ）を含むタイプのインスタンスである。関係は、２つの項目間のリンクである。（本明細書で使用する以上、およびその他の特定の用語は、近接して使用される他の用語からそれらの用語をオフセットする（ｏｆｆｓｅｔ）ために大文字にする可能性があるが、大文字にした用語、例えば、「項目（Ｉｔｅｍ）」と、大文字にされていない同一の用語、例えば、「項目（ｉｔｅｍ）」を区別する意図はまったくなく、そのような区別は想定、または含意されてはならない。）

コンピュータシステムは、ハードウェア／ソフトウェアインターフェースシステムが操作することができる情報の個別の格納可能な単位をそれぞれが構成する複数の項目と、前記項目の編成構造を構成する複数の項目フォルダと、複数の項目を操作するためのハードウェア／ソフトウェアインターフェースシステムとをさらに含み、各項目は、少なくとも１つの項目フォルダに属し、複数のフォルダに属することが可能である。

項目、または項目のプロパティ値の一部は、永続的ストアから導出されるのではなく、動的に計算されることが可能である。つまり、ハードウェア／ソフトウェアインターフェースシステムは、項目が格納されることを要さず、項目の現在のセットを列挙する能力、またはストレージプラットフォームの識別子（アプリケーションプログラミングインターフェース、またはＡＰＩを説明するセクションにおいてより十分に説明する）を所与として項目を取り出す能力などの一部の操作（ｏｐｅｒａｔｉｏｎ）が、サポートされ、例えば、項目は、セル電話機の現在位置、または温度センサ上の温度読み取り値であることが可能である。ハードウェア／ソフトウェアインターフェースシステムは、複数の項目を操作することができ、ハードウェア／ソフトウェアインターフェースシステムによって管理される複数の関係によって互いに結合された項目をさらに含むことが可能である。

コンピュータシステムのためのハードウェア／ソフトウェアインターフェースシステムは、前記ハードウェア／ソフトウェアインターフェースシステムが理解し、所定の予測可能な形で直接に処理することができるコア項目のセットを定義するコアスキーマをさらに含む。複数の項目を操作するのに、コンピュータシステムは、前記項目を複数の関係で互いに結合し、ハードウェア／ソフトウェアインターフェースシステムレベルで前記関係を管理する。

ストレージプラットフォームのＡＰＩは、ストレージプラットフォームスキーマのセットの中で定義された各項目、各項目拡張、および各関係に関してデータクラスを提供する。さらに、アプリケーションプログラミングインターフェースは、そのデータクラスに関する一般的な挙動セットを定義し、データクラスとともに、ストレージプラットフォームＡＰＩに関する基本的なプログラミングモデルを提供するフレームワーククラスのセットを提供する。ストレージプラットフォームＡＰＩは、基礎にあるデータベースエンジンのクエリ言語の詳細からアプリケーションプログラマを隔離する形で、アプリケーションプログラマが、データストア内の項目の様々なプロパティに基づいてクエリを形成することができるようにする単純化されたクエリモデルを提供する。また、ストレージプラットフォームは、アプリケーションプログラムによって項目に対して行われた変更を収集し、それらの変更を、データストアが実装されたデータベースエンジン（または任意の種類のストレージエンジン）によって要求される正しい更新に編成する。これにより、アプリケーションプログラマが、データストア更新の複雑さをＡＰＩに任せながら、メモリ内の項目に対する変更を行うことができるようになる。

共通のストレージ基礎、およびスキーマ化されたデータを介して、本発明のストレージプラットフォームは、消費者、知識労働者、および企業のためのより効率的なアプリケーション開発を可能にする。本発明のストレージプラットフォームは、本発明のストレージプラットフォームのデータモデルに固有の諸機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法を取り入れ、拡張することも行う、豊かで拡張可能なアプリケーションプログラミングインターフェースを提供する。

相互関連する発明（「発明を実施するための最良の形態（ＤｅｔａｉｌｅｄＤｅｃｒｉｐｔｉｏｎ）」のセクションＩＩで詳細に説明する）のこの全体にわたる構造の一部として、関連する発明の一部は、同期ＡＰＩ（「発明を実施するための最良の形態」のセクションＩＩＩで詳細に説明する）と特に対象とし、同期ＡＰＩは、ストレージプラットフォームの広い同期機能を表す。本発明のいくつかの実施形態には、それらの同期機能が組み込まれて、ピアツーピア同期中に競合が生じるにつれ、競合を処理するものと見込まれている。競合を正しく、効率的に処理する能力により、良好な使いやすさを保ちながら、データ損失が最小限に抑えられ、同期中のユーザ介入の必要性が少なくなる。この目的で、「発明を実施するための最良の形態」のセクションＩＩＩは、関連する発明のｏｒストレージプラットフォームの同期システムを含むが、これには限定されないピアツーピア同期システムにおいて競合を処理するためのシステムおよび方法を対象とする、関連する発明の様々な実施形態の詳細な説明も含む。

以上に鑑みて、本発明の様々な実施形態は、共通ストレージプラットフォーム（例えば、関連する発明の新たなストレージプラットフォーム）をともに利用する２つのクライアントが、同一の共通ストレージプラットフォームを使用しない（例えば、その新たなストレージプラットフォームに関する同期をそれ自体サポートしないレガシストレージプラットフォームを代わりに使用する）仲介を介して同期する、同期のシステムおよび方法を対象とする。要するに、本発明の様々な実施形態は、仲介の既存の諸機能を使用してデータが同期されるが、クライアントのデータ構造が保たれる方法を使用する。様々な実施形態は、クライアントが仲介と対話することを可能にする「アダプタ」を利用し、前記アダプタは、クライアントの新たなストレージプラットフォームに固有のデータ構造要素を仲介が保つことができないことを有効な形で補償する。本発明の様々な実施形態は、クライアントから仲介へのアップロード同期データと、仲介からクライアントへのダウンロード同期データのいずれか、または両方を対象とする。さらに、一部の実施形態は、仲介上のデータのコンパクション（ｃｏｍｐａｃｔｉｏｎ）をさらに対象とする。

本発明の具体的な特徴および利点は、単独で、または関連する発明と併せて、本発明の以下の詳細な説明、および添付の説明から明白となろう。

以上の概要、ならびに本発明の以下の詳細な説明は、添付の図面と併せて読むことでよりよく理解される。本発明を例示するため、図面には、本発明の様々な態様の典型的な実施形態が示されているが、本発明は、開示する特定の方法および手段（ｉｎｓｔｒｕｍｅｎｔａｌｉｔｉｅｓ）に限定されない。

本発明の実施形態を法的要件を満たすように具体的に説明する。ただし、説明自体は、本特許の範囲を限定することを意図するものではない。むしろ、発明人らは、請求の対象物が、他の現在の技術、または将来の技術に関連して、本明細書で説明するステップとは異なるステップ、または類似するステップの組合せを含むように、他の形で実施されることも可能であることを企図している。さらに、「ステップ」という用語は、本明細書では、使用される方法の異なる要素を表すように使用される可能性があるが、この用語は、個々のステップの順序が明示的に説明されない限り、また説明される場合を除き、本明細書で開示する様々なステップの間において、何ら特定の順序を暗示するものと解釈してはならない。

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

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

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

パーソナルコンピュータ２０は、リモートコンピュータ４９のような１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードであることが可能であり、通常、パーソナルコンピュータ２０に関連して前述した要素の多く、またはすべてを含むが、メモリ記憶装置５０だけを図１に示している。図１に示す論理接続は、ＬＡＮ（ローカルエリアネットワーク）５１およびＷＡＮ（ワイドエリアネットワーク）５２を含む。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットで一般的である。

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

図２のブロック図に示すとおり、コンピュータシステム２００は、ほぼ３つのコンポーネントグループに分けることができる。すなわち、ハードウェアコンポーネント２０２、ハードウェア／ソフトウェアインターフェースシステムコンポーネント２０４、およびアプリケーションプログラムコンポーネント２０６（本明細書の一部の文脈では、「ユーザコンポーネント」または「ソフトウェアコンポーネント」とも呼ぶ）である。

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

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

ハードウェア／ソフトウェアインターフェースシステムコンポーネント２０４は、シェルとカーネルをそれ自体が含むオペレーティングシステムを含む（一部の実施形態では、オペレーティングシステムだけから成る）。「ＯＳ」（オペレーティングシステム）は、アプリケーションプログラム群とコンピュータハードウェアの仲介として作用する特別なプログラムである。ハードウェア／ソフトウェアインターフェースシステムコンポーネント２０４は、ＶＭＭ（仮想マシンマネージャ）、ＣＬＲ（共通言語ランタイム）または機能的均等物、ＪＶＭ（Ｊａｖａ（登録商標）仮想マシン）または機能的均等物、またはコンピュータシステム内のオペレーティングシステムに代わる、または追加される他のそのようなソフトウェアコンポーネントも含むことが可能である。ハードウェア／ソフトウェアインターフェースシステムの目的は、ユーザが、アプリケーションプログラム群を実行することができる環境を提供することである。いずれのハードウェア／ソフトウェアインターフェースシステムの目標も、コンピュータシステムを使用しやすくするとともに、コンピュータハードウェアを効率的な形で利用することである。

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

ハードウェア／ソフトウェアインターフェースシステムは、従来、アプリケーション群のための様々なサービスを実行する。複数のプログラムが同時に実行されていることが可能なマルチタスキングハードウェア／ソフトウェアインターフェースシステムでは、ハードウェア／ソフトウェアインターフェースシステムは、どのアプリケーションが、どのような順序で実行されるべきか、各アプリケーションにどれだけの時間が割り当てられてから、別のアプリケーションの順番に切り替えるべきかを決める。また、ハードウェア／ソフトウェアインターフェースシステムは、複数のアプリケーションの間における内部メモリの共有を管理し、ハードディスク、プリンタ、ダイヤルアップポートなどの接続されたハードウェアデバイス群への入力、およびそのようなデバイス群からの出力を扱うことも行う。また、ハードウェア／ソフトウェアインターフェースシステムは、操作のステータス、および生じる可能性があるエラーに関するメッセージを各アプリケーションに（一部のケースでは、エンドユーザにも）送信することも行う。また、ハードウェア／ソフトウェアインターフェースシステムは、バッチジョブ（例えば、印刷）の管理の負担を取り除き（ｏｆｆｌｏａｄ）、開始したアプリケーションが、その作業から解放され、他の処理および／または操作を再開できるようにすることもできる。並行処理を提供することができるコンピュータ上で、ハードウェア／ソフトウェアインターフェースシステムは、プログラムを分割することを管理して、プログラムが、同時に複数のプロセッサ上で実行されるようにすることもできる。

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

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

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

従来、ディレクトリ（別名、フォルダのディレクトリ）は、ツリーベースの階層構造であり、ファイルが、フォルダにグループ化され、フォルダは、ディレクトリツリーを構成する相対的なノード位置に応じて配置される。例えば、図２Ａに示すとおり、ＤＯＳベースのファイルシステム基本フォルダ（または「ルートディレクトリ」）２１２は、複数のフォルダ２１４を含むことが可能であり、フォルダ２１４のそれぞれは、さらなるフォルダ（その特定のフォルダの「サブフォルダ」）２１６をさらに含むことが可能であり、追加のフォルダのそれぞれも、さらなるフォルダ２１８を含むことが可能であり、無限に含むことが可能である（ａｄｉｎｆｉｎｉｔｕｍ）。これらのフォルダのそれぞれは、１つまたは複数のファイル２２０を有することが可能である。ただし、ハードウェア／ソフトウェアインターフェースシステムレベルで、フォルダ内の個々のファイルに、ツリー階層の中の位置以外はまったく共通点がない。当然のことながら、ファイルをフォルダ階層に編成するこのアプローチは、それらのファイルを格納するのに使用される通常の記憶媒体（例えば、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理的編成を間接的に反映している。

以上に加えて、各フォルダは、そのフォルダのサブフォルダ、およびそのフォルダのファイルのコンテナである。つまり、各フォルダは、そのフォルダのサブフォルダおよびファイルを所有する。例えば、あるフォルダが、ハードウェア／ソフトウェアインターフェースシステムによって削除された場合、そのフォルダのサブフォルダおよびファイルも削除される（これには、各サブフォルダのケースで、そのサブフォルダのサブフォルダおよびファイルが再帰的にさらに含まれる）。同様に、各ファイルは、一般に、１つだけのフォルダによって所有され、ファイルが、コピーされ、そのコピーが、異なるフォルダの中に配置されることが可能であるが、ファイルのコピーはそれ自体、オリジナルに対して直接の結合をまったく有さない、異なる別個の単位である（例えば、元のファイルに対する変更は、ハードウェア／ソフトウェアインターフェースシステムレベルで、コピーファイルにミラーリングされない）。したがって、この点でファイルおよびフォルダは、特徴的に「物理的な」性質である。というのは、フォルダは、物理的コンテナのように扱われ、ファイルは、それらのコンテナ内部の異なる別個の物理的要素として扱われるからである。

ＩＩ．データの編成、探索、および共有を行うためのＷＩＮＦＳストレージプラットフォーム
本発明は、上記に説明したとおり参照により本明細書に組み込まれている、関連する発明と一緒に、データの編成、探索、および共有を行うためのストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、前述した種類の既存のファイルシステムおよびデータベースシステムを超えてデータプラットフォームを拡張し、広げ、項目と呼ばれる新たな形態のデータを含め、すべてのタイプのデータのためのストアとなるように設計される。

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

Ｂ．ストレージプラットフォームの概略
図３を参照すると、ストレージプラットフォーム３００が、データベースエンジン３１４上に実装されたデータストア３０２を含む。一実施形態では、データベースエンジンは、オブジェクトリレーショナル拡張機能を有するリレーショナルデータベースエンジンを含む。一実施形態では、リレーショナルデータベースエンジン３１４は、ＭｉｃｒｏｓｏｆｔＳＱＬＳｅｒｖｅｒリレーショナルデータベースエンジンを含む。データストア３０２は、データの編成、探索、共有、同期、およびセキュリティをサポートするデータモデル３０４を実施する。特定のタイプのデータが、スキーマ３４０のようなスキーマの中で記述され、ストレージプラットフォーム３００は、以下により十分に説明するとおり、それらのスキーマを展開するため、およびそれらのスキーマを拡張するためのツール３４６を提供する。

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

本発明のストレージプラットフォーム３００は、ユーザまたはシステムの間におけるデータの共有を円滑にする同期サービス３３０を含め、様々なサービス３２８をアプリケーションプログラム群に提供することができる。例えば、同期サービス３３０は、データストア３０２と同一の形式を有する他のデータストア群３４０との相互運用性、ならびに他の形式を有するデータストア群３４２へのアクセスを可能にすることができる。また、ストレージプラットフォーム３００は、Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイルシステム３１８などの既存のファイルシステムに対するデータストア３０２の相互運用性を可能にするファイルシステム機能も提供する。少なくとも一部の実施形態では、ストレージプラットフォーム３２０は、データに従って動作が行われる（ｂｅａｃｔｅｄｕｐｏｎ）ことを可能にするため、および他のシステム群との対話を可能にするための追加の機能を有するアプリケーションプログラム群も提供することができる。それらの機能は、情報エージェントサービス３３４や通知サービス３３２などの追加のサービス群３２８の形態、ならびに他のユーティリティ３３６の形態で実施されることが可能である。

少なくとも一部の実施形態では、ストレージプラットフォームは、コンピュータシステムのハードウェア／ソフトウェアインターフェースシステムとして実施されるか、またはハードウェア／ソフトウェアインターフェースシステムの不可分な部分を形成する。例えば、限定としてではなく、本発明のストレージプラットフォームは、オペレーティングシステム、ＶＭＭ（仮想マシンマネージャ）、ＣＬＲ（共通言語ランタイム）または機能的均等物、ＪＶＭ（Ｊａｖａ（登録商標）仮想マシン）または機能的均等物として実施されること、またはそれらの不可分な部分を形成することが可能である。共通のストレージの基礎、およびスキーマ化されたデータを介して、本発明のストレージプラットフォームは、消費者、知識労働者、および企業のためのより効率的なアプリケーション開発を可能にする。本発明のストレージプラットフォームは、本発明のストレージプラットフォームのデータモデルに固有の諸機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法を取り入れ、拡張することも行う、豊かで拡張可能なアプリケーションプログラミング表面領域（ｓｕｒｆａｃｅａｒｅａ）を提供する。

以下の説明、および様々な図では、本発明のストレージプラットフォーム３００は、「ＷｉｎＦＳ」と呼ばれることが可能である。ただし、ストレージプラットフォームを指すこの名前の使用は、単に説明の便宜のためであり、まったく限定することを意図するものではない。

Ｃ．データモデル
本発明のストレージプラットフォーム３００のデータストア３０２は、ストア内に存在するデータの編成、探索、共有、同期、およびセキュリティをサポートするデータモデルを実施する。本発明のデータモデルでは、「項目」が、ストレージ情報の基本的な単位である。データモデルは、以下により十分に説明するとおり、項目および項目拡張を宣言するため、項目間の関係を確立するため、および項目フォルダ内およびカテゴリ内に項目を編成するためのメカニズムを提供する。

データモデルは、２つのプリミティブメカニズム、タイプおよび関係に依拠する。タイプは、タイプのインスタンスの形態を支配する形式を提供する構造である。形式は、プロパティの順序付けられたセットとして表現される。プロパティは、所与のタイプの値、または値のセットの名前である。例えば、ＵＳＰｏｓｔａｌＡｄｄｒｅｓｓタイプは、通り、都市、郵便番号、州のプロパティを有することが可能であり、通り、都市、および州は、文字列というタイプであり、郵便番号は、Ｉｎｔ３２というタイプである。通りは、多値（ｍｕｌｔｉ−ｖａｌｕｅｄ）（すなわち、値のセット）であることが可能であり、アドレスが、通りプロパティとして複数の値を有することを可能にする。システムは、他のタイプの構築において使用することができる一部のプリミティブタイプを定義し、それらのタイプには、文字列、バイナリ、ブーリアン（Ｂｏｏｌｅａｎ）、Ｉｎｔ１６、Ｉｎｔ３２、Ｉｎｔ６４、シングル、ダブル、バイト、ＤａｔｅＴｉｍｅ、１０進数、およびＧＵＩＤが含まれる。タイプのプロパティ群は、プリミティブタイプのいずれか、または（以下に記すいくつかの制限を伴って）構築されたタイプのいずれかを使用して定義されることが可能である。例えば、座標およびアドレスというプロパティを有し、ただし、アドレスプロパティは、前述したＵＳＰｏｓｔａｌＡｄｄｒｅｓｓというタイプである場所タイプが、定義されることが可能である。

関係は、宣言され、２つのタイプのインスタンスのセットの間におけるマッピングを表すことが可能である。例えば、どの人々がどの場所に住んでいるかを定義するＬｉｖｅｓＡｔと呼ばれる、個人タイプと場所タイプの間の宣言された関係が存在することが可能である。関係は、プロパティの順序付けられたセットも有することが可能である。ソースエンドポイントと目標エンドポイントはともに、名前およびタイプを有する。例えば、ＬｉｖｅｓＡｔＲｅｌａｔｉｏｎｓｈｉｐは、個人というタイプの居住者と呼ばれるソース、および場所というタイプの住居と呼ばれる目標を有し、さらに、居住者が住居に住んでいた期間を示すＳｔａｒｔＤａｔｅおよびＥｎｄｄａｔｅというプロパティを有する。個人は、時とともに複数の住居に住むことが可能であり、住居は、複数の居住者を有する可能性があり、したがって、ＳｔａｒｔＤａｔｅ情報およびＥｎｄＤａｔｅ情報を置くのに最も見込みのある場所は、関係自体の上である。

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

データモデルは、タイプ間でサブタイプ−スーパータイプ関係の定義を許さない。ＢａｓｅＴｙｐｅ関係としても知られるサブタイプ−スーパータイプ関係は、タイプＡが、タイプＢに関するＢａｓｅＴｙｐｅである場合、Ｂのすべてのインスタンスが、Ａのインスタンスでもなければならないような形で定義される。これを表現する別の仕方は、Ｂに適合するすべてのインスタンスが、Ａにも適合しなければならないことである。例えば、Ａが、文字列というタイプの名前というプロパティを有する一方で、Ｂは、Ｉｎｔ１６というタイプの年齢というプロパティを有する場合、Ｂのいずれのインスタンスも、名前と年齢をともに有さなければならないことになる。階層というタイプは、ルートに単一のスーパータイプを有するツリーとして構想することができる。ルートからのブランチは、第１のレベルのサブタイプを提供し、このレベルにおけるブランチは、第２のレベルのサブタイプを提供し、それ自体、サブタイプをまったく有さない最もリーフである（ｌｅａｆ−ｍｏｓｔ）サブタイプに至るまで、以下同様である。ツリーは、一様な深さであるように制約されないが、循環は、まったく含むことができない。所与のタイプは、０または多くのサブタイプ、ならびに０または１つのスーパータイプを有することが可能である。所与のインスタンスは、せいぜい１つのタイプとともに、そのタイプのスーパータイプに適合することが可能である。つまり、ツリー内のいずれのレベルにおける所与のインスタンスに関しても、インスタンスは、そのレベルにおけるせいぜい１つのサブタイプに適合することが可能である。タイプは、そのタイプのインスタンスが、そのタイプのサブタイプのインスタンスでもなければならない場合、抽象型であると言われる。

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

項目は、コピー、削除、移動、開く、印刷、バックアップ、復元、複製などの一般的な操作のためのオブジェクトである。項目は、格納し、取り出すことができる単位であり、ストレージプラットフォームによって操作されるすべての形態の格納可能な情報が、項目、項目のプロパティ、または項目間の関係として存在し、以上のそれぞれを以下により詳細に説明する。

項目は、連絡先、人々、サービス、場所、ドキュメント（多種多様な）のようなデータの、現実世界の容易に理解できる単位を表すことを意図している。図５Ａは、項目の構造を示すブロック図である。項目の非修飾名（ｕｎｑｕａｌｉｆｅｄｎａｍｅ）は、「場所」である。項目の修飾名は、「Ｃｏｒｅ．Ｌｏｃａｔｉｏｎ」であり、「Ｃｏｒｅ．Ｌｏｃａｔｉｏｎ」は、その項目構造が、コアスキーマ内の特定の項目タイプとして定義されることを示す。（コアスキーマは、後により詳細に説明する。）

場所項目は、ＥＡｄｄｒｅｓｓ、ＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎ、Ｎｅｉｇｈｂｏｒｈｏｏｄ、およびＰｏｓｔａｌＡｄｄｒｅｓｓを含む複数のプロパティを有する。それぞれに関する特定のプロパティタイプは、プロパティ名の直後に示され、コロン（「：」）でプロパティ名と分離されている。タイプ名の右側に、そのプロパティタイプに許される値の数が、ブラケット（「［］」）内に示され、コロン（「：」）の右側のアスタリスク（「^＊」）が、不定で、かつ／または無制限の数（「多数」）を示す。コロンの右側の「１」は、せいぜい１つの値が存在することが可能であることを示す。コロンの左側のゼロ（「０」）は、そのプロパティがオプションである（値がまったく存在しなくてもよい）ことを示す。コロンの左側の「１」は、少なくとも１つの値が存在しなければならない（そのプロパティは、必須である）ことを示す。ＮｅｉｇｈｂｏｒｈｏｏｄおよびＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎはともに、事前定義されたデータタイプまたは「単純タイプ」（本明細書で、大文字が使用されないことで示される）である「ｎｖａｒｃｈａｒ」というタイプ（または均等のタイプ）である。しかし、ＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓは、それぞれ、ＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓというタイプの、定義されたタイプまたは「複雑タイプ」（本明細書で、大文字を使用することで表される）のプロパティである。複雑タイプは、１つまたは複数の単純データタイプ、および／または他の複雑タイプから派生させられたタイプである。項目のプロパティに関する複雑タイプは、「入れ子型要素」も構成する。というのは、複雑タイプの詳細は、直属の（ｉｍｍｅｄｉａｔｅ）項目の中に入れ子にされて項目のプロパティを定義し、それらの複雑タイプに属する情報は、それらのプロパティを有する項目とともに（後述するとおり、項目の境界内に）保持されるからである。タイプ付けのこれらの概念は、当業者には周知であり、容易に理解されよう。

図５Ｂは、ＰｏｓｔａｌＡｄｄｒｅｓｓおよびＥＡｄｄｒｅｓｓという複雑プロパティタイプを示すブロック図である。ＰｏｓｔａｌＡｄｄｒｅｓｓプロパティタイプは、ＰｏｓｔａｌＡｄｄｒｅｓｓというプロパティタイプの項目が、０または１つのＣｉｔｙ値、０または１つのＣｏｕｎｔｒｙＣｏｄｅ値、０または１つのＭａｉｌＳｔｏｐ値、および任意の数（０または多数の）ＰｏｓｔａｌＡｄｄｒｅｓｓタイプなどを有すると見込まれることが可能であることを定義する。このようにして、項目内の特定のプロパティに関するデータの形状が定義される。ＥＡｄｄｒｅｓｓプロパティタイプも同様に、示したとおり定義される。本出願ではオプションとして使用されるが、場所項目内の複雑タイプを表す別の仕方は、項目を、項目内にリストアップされる各複雑タイプの個々のプロパティを使用して描くことである。図５Ｃは、複雑タイプがさらに記述された場所項目を示すブロック図である。ただし、この図５Ｃにおける場所項目のこの代替表現は、図５Ａに示したのとまったく同一の項目に関することを理解されたい。本発明のストレージプラットフォームは、１つのプロパティタイプが、別のプロパティタイプのサブタイプであることが可能な（その１つのプロパティタイプが、別の親プロパティタイプのプロパティを継承する場合）サブタイプ付けも可能にする。

プロパティ、およびプロパティのプロパティタイプに類似するが、これらとは異なり、項目は、サブタイプ付けの対象でもあることが可能な自らの項目タイプを本来的に表す。つまり、本発明のいくつかの実施形態におけるストレージプラットフォームは、項目が、別の項目のサブタイプであることを可能にする（これにより、その１つの項目が、他方の親項目のプロパティを継承する）。さらに、本発明の様々な実施形態に関して、すべての項目は、基礎スキーマの中で見られる最初の基礎的な項目タイプである「項目」項目タイプのサブタイプである。（基礎スキーマについても、後により詳細に説明する。）図６Ａは、項目、この実例では、場所項目が、基礎スキーマの中で見られる項目タイプのサブタイプであるのを示す。この図面で、矢印は、場所項目（他のすべての項目と同様に）が、項目タイプのサブタイプであることを示す。項目タイプは、他のすべての項目が導出される基礎項目として、ＩｔｅｍＩｄおよび様々なタイムスタンプなどのいくつかの重要なプロパティを有して、オペレーティングシステム内のすべての項目の標準のプロパティを定義する。この図では、項目タイプのそれらのプロパティは、場所によって継承され、場所のプロパティになる。

項目タイプから継承された場所項目内のプロパティを表す別のやり方は、場所を、場所の中にリストアップされた親項目からの各プロパティタイプの個々のプロパティを使用して描くことである。図６Ｂは、場所項目の継承されたタイプが、場所項目の直属のプロパティに加えて記述された場所項目を示すブロック図である。この項目は、図５Ａに示したのと同一の項目であることに留意し、そのことを理解されたい。ただし、この図では、場所は、この図と図５Ａの両方で示す直属のプロパティと、この図では示すが、図５Ａでは示さない継承されたプロパティの両方の、場所のプロパティのすべてとともに示されている（これに対して、図５Ａでは、継承されたプロパティは、場所項目が項目タイプのサブタイプであるという矢印を使用して示すことで表されている）。

項目は、スタンドアロンオブジェクトであり、このため、項目を削除した場合、項目の直属のプロパティおよび継承されたプロパティのすべても削除される。同様に、項目を取り出す際、受け取られるのは、項目、および項目の直属のプロパティおよび継承されたプロパティ（項目の複雑プロパティタイプに属する情報を含む）のすべてである。本発明の一部の実施形態は、特定の項目を取り出す際にプロパティのサブセットを要求することができるようにするが、多くのそのような実施形態に関する既定は、取り出される際に、項目を、項目の直属のプロパティおよび継承されたプロパティのすべてとともに提供することである。さらに、項目のプロパティは、その項目のタイプの既存のプロパティに新たなプロパティを追加することにより、拡張することができる。それらの「拡張」は、その後、項目の真正のプロパティであり、その項目タイプのサブタイプは、その拡張プロパティを自動的に含むことが可能である。

項目の「境界」は、項目のプロパティ（複雑プロパティタイプ、拡張などを含む）によって表される。また、項目の境界は、コピー、削除、移動、作成などの、項目に対して実行される操作の限界も表す。例えば、本発明の一実施形態では、項目がコピーされると、その項目の境界内のすべてもコピーされる。各項目に関して、境界は、以下を包含する。すなわち、
・項目の項目タイプ、ならびに項目が、別の項目のサブタイプである場合（すべての項目が、基礎スキーマ内の単一の項目、および項目タイプから導出される本発明のいくつかの実施形態において該当するように）、あらゆる該当するサブタイプ情報。コピーされている元の項目が、別の項目のサブタイプである場合、そのコピーも、その同一の項目のサブタイプであることが可能である
・項目の複雑タイププロパティ、および、存在する場合、拡張。元の項目が、複雑タイプ（ネイティブの、または拡張された）のプロパティを有する場合、コピーも、その同一の複雑タイプを有することが可能である
・「所有権関係」に関する項目のレコード、つまり、他のどのような項目（「目標項目」）が、その項目（「所有側項目」）によって所有されているかという項目の独自のリスト。これは、以下により十分に説明する項目フォルダ、ならびにすべての項目が少なくとも１つの項目フォルダに属さなければならないとう以下に述べる規則に関連して特に重要である。さらに、以下により十分に説明する、組み込まれた項目に関して、組み込まれた項目は、コピー、削除などの操作のために項目が組み込まれる項目の一部と見なされる

２．項目識別
項目は、ＩｔｅｍＩＤを使用してグローバル項目空間内で一意に識別される。Ｂａｓｅ．Ｉｔｅｍタイプが、項目のＩＤを格納するＧＵＩＤというタイプのＩｔｅｍＩＤというフィールドを定義する。項目は、データストア３２０内で厳密に１つのＩＤを有さなければならない。

項目参照は、項目を探し出し、識別する情報を含むデータ構造である。データモデルにおいて、すべての項目参照タイプが導出されるＩｔｅｍＲｅｒｅｎｃｅと名付けられた抽象タイプが定義される。ＩｔｅｍＲｅｆｅｒｅｎｃｅタイプは、Ｒｅｓｏｌｖｅと名付けられた仮想メソッドを定義する。Ｒｅｓｏｌｖｅメソッドは、ＩｔｅｍＲｅｆｅｒｅｎｃｅを解決し、項目を戻す。このメソッドは、参照を所与として、項目を取り出す機能を実施する、ＩｔｅｍＲｅｆｅｒｅｎｃｅの具象サブタイプによって無効にされる。Ｒｅｓｏｌｖｅメソッドは、ストレージプラットフォームＡＰＩ３２２の一部として呼び出される。

ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅは、ＩｔｅｍＲｅｆｅｒｅｎｃｅのサブタイプである。ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅは、ロケータフィールドおよびＩｔｅｍＩＤフィールドを定義する。ロケータフィールドは、項目ドメインを名付ける（すなわち、識別する）。ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅは、ロケータの値を項目ドメインに解決することができるロケータ解決メソッドによって処理される。ＩｔｅｍＩＤフィールドは、ＩｔｅｍＩＤというタイプである。

ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅは、ロケータフィールドおよびパスフィールドを定義するＩｔｅｍＲｅｆｅｒｅｎｃｅの特殊化である。ロケータフィールドは、項目ドメインを識別する。ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅは、ロケータの値を項目ドメインに解決することができるロケータ解決メソッドによって処理される。パスフィールドは、ロケータによって提供される項目ドメインをルートとするストレージプラットフォーム名前空間内の（相対）パスを含む。

このタイプの参照は、集合演算（ｓｅｔｏｐｅｒａｔｉｏｎ）において使用することができない。参照は、一般に、パス解決プロセスを介して解決される。ストレージプラットフォームＡＰＩ３２２のＲｅｓｏｌｖｅメソッドが、この機能を提供する。

前述した参照形態は、図１１に示す参照タイプ階層を介して表される。それらのタイプから継承する追加の参照タイプが、スキーマの中で定義されることが可能である。追加の参照タイプは、関係宣言の中で目標フィールドのタイプとして使用されることが可能である。

３．項目フォルダおよびカテゴリ
以下により十分に説明するとおり、グループの項目は、項目フォルダ（ファイルフォルダと混同されるべきでない）と呼ばれる特別な項目に編成されることが可能である。しかし、ほとんどのファイルシステムにおける場合とは異なり、項目は、複数の項目フォルダに属することが可能であり、したがって、ある項目が、１つの項目フォルダの中でアクセスされ、改訂されると、この改訂された項目には、別の項目フォルダから直接にアクセスが行われることが可能である。基本的に、項目へのアクセスは、異なる項目フォルダから行われることが可能であるが、実際にアクセスされるのは、実際、まったく同一の項目である。ただし、項目フォルダは、項目フォルダのメンバ項目のすべてを必ずしも所有しないか、または他のフォルダと連携して項目を単に共同所有することが可能であり、したがって、項目フォルダの削除は、項目の削除を必ずしももたらさない。それでも、本発明のいくつかの実施形態では、項目は、少なくとも１つの項目フォルダに属さなければならず、したがって、特定の項目に関する唯一の項目フォルダが削除された場合、一部の実施形態の場合、その項目は、自動的に削除されるか、あるいは代替の実施形態において、その項目は、既定の項目フォルダ（例えば、様々なファイル−フォルダベースのシステムにおいて使用される類似した名前のフォルダと概念上、類似する「ごみ箱」項目フォルダ）のメンバに自動的になる。

やはり以下により十分に説明するとおり、項目は、（ａ）項目タイプ（またはタイプ群）、（ｂ）特定の直属の、または継承されたプロパティ（またはプロパティ群）、または（ｃ）項目プロパティに相当する特定の値（または複数の値）などの、共通の記述される特性に基づくカテゴリにも属することが可能である。例えば、個人連絡先情報に関する特定のプロパティを含む項目は、連絡先カテゴリに自動的に属することが可能であり、連絡先情報プロパティを有するいずれの項目も同様に、このカテゴリに自動的に属する。同様に、「ニューヨーク市」という値を有する場所プロパティを有する項目は、ＮｅｗＹｏｒｋＣｉｔｙカテゴリに自動的に属することが可能である。

カテゴリは、項目フォルダが、相互に関連しない（すなわち、共通の記述される特性を有さない）項目を含む可能性があるに対して、カテゴリ内の各項目は、そのカテゴリに関して記述される共通のタイプ、プロパティ、または値（「共通性」）を有し、カテゴリ内のその他の項目に対する各項目の関係、およびそれらの他の項目の間における各項目の関係の基礎を形成するのは、この共通性であるという点で、項目フォルダとは異なる。さらに、特定のフォルダ内の項目のメンバシップは、その項目のいずれの特定の態様に基づいても強制的ではないのに対して、一部の実施形態の場合、あるカテゴリにカテゴリ上、関連する共通性を有するすべての項目は、ハードウェア／ソフトウェアインターフェースシステムレベルで自動的にそのカテゴリのメンバとなる可能性がある。概念上、カテゴリは、メンバシップが、特定のクエリ（データベースの文脈におけるような）の結果に基づき、そのクエリの諸条件（カテゴリの共通点によって定義される）を満たす項目が、カテゴリのメンバシップを構成する仮想項目フォルダとして考えることもできる。

図４は、項目、項目フォルダ、およびカテゴリの間の構造上の関係を示す。複数の項目４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、および４２０が、様々な項目フォルダ４２２、４２４、４２６、４２８、および４３０のメンバである。一部の項目は、複数の項目フォルダに属することが可能であり、例えば、項目４０２は、項目フォルダ４２２および４２４に属する。一部の項目、例えば、項目４０２、４０４、４０６、４０８、４１０、および４１２は、１つまたは複数のカテゴリ４３２、４３４、および４３６のメンバでもあることが可能である一方で、他の時間、例えば、項目４１４、４１６、４１８、および４２０は、いずれのカテゴリにも属さないことが可能である（ただし、いずれのプロパティを有することも、カテゴリにおけるメンバシップを自動的に暗示する一部の実施形態では、これは非常に可能性が低く、このため、そのような実施形態においていずれのカテゴリのメンバでもないためには、項目は、完全に特徴を欠いていなければならない）。フォルダの階層構造とは対照的に、カテゴリと項目フォルダはともに、図示するとおり、有効グラフにより類似した構造を有する。いずれにしても、項目、項目フォルダ、およびカテゴリはすべて、項目である（異なる項目タイプではあるが）。

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

４．スキーマ
ａ）基礎スキーマ
項目の作成および使用の汎用の基礎を提供するため、本発明のストレージプラットフォームの様々な実施形態は、項目およびプロパティを作成し、編成するための概念上のフレームワークを確立する基礎スキーマを含む。基礎スキーマは、ある特別のタイプの項目およびプロパティを定義し、サブタイプをさらに導出することができるそれらの特別な基礎タイプの特徴を定義する。この基礎スキーマの使用により、プログラマが、項目（および項目のそれぞれのタイプ）をプロパティ（およびプロパティのそれぞれのタイプ）から概念上、区別することができるようになる。さらに、基礎スキーマは、すべての項目が有することが可能なプロパティの基礎的なセットを提示する。というのは、すべての項目（および項目の対応する項目タイプ）が、基礎スキーマ内のその基礎的な項目（およびそのような項目の対応する項目タイプ）から導出されるからである。

図７に示すとおり、本発明のいくつかの実施形態に関連して、基礎スキーマは、３つの最上レベルのタイプ、すなわち、項目、拡張、およびＰｒｏｐｅｒｔｙＢａｓｅを定義する。図示するとおり、項目タイプは、その基礎的な「項目」項目タイプのプロパティによって定義される。これに対して、「ＰｒｏｐｅｒｔｙＢａｓｅ」という最上レベルのプロパティタイプは、事前定義されたプロパティをまったく有さず、単にアンカ（ａｎｃｈｏｒ）であり、このアンカから、他のすべてのプロパティタイプが導出され、このアンカを介して、すべての派生させられたプロパティタイプが互いに関連付けられる（単一のプロパティタイプから共通で導出されているので）。拡張タイププロパティは、いずれの項目を拡張が拡張するかを定義するとともに、項目が複数の拡張を有する可能性があるため、１つの拡張を別の拡張から区別する識別を定義する。

ＩｔｅｍＦｏｌｄｅｒは、項目から継承されたプロパティに加え、ＩｔｅｍＦｏｌｄｅｒのメンバ（存在する場合）へのリンクを確立するための関係と特徴とする、項目タイプのサブタイプである一方で、ＩｄｅｎｔｉｔｙＫｅｙとＰｒｏｐｅｒｔｙはともに、ＰｒｏｐｅｒｔｙＢａｓｅのサブタイプである。ＣａｔｅｇｏｒｙＲｅｆは、ＩｄｅｎｔｉｔｙＫｅｙのサブタイプである。

ｂ）コアスキーマ
本発明のストレージプラットフォームの様々な実施形態は、最上レベルの項目タイプ構造の概念上のフレームワークを提供するコアスキーマをさらに含む。図８Ａは、コアスキーマ内の項目を示すブロック図であり、図８Ｂは、コアスキーマ内のプロパティタイプを示すブロック図である。ファイル−フォルダベースのシステムにおいて異なる拡張子（^＊．ｃｏｍ、^＊．ｅｘｅ、^＊．ｂａｔ、^＊．ｓｙｓなど）、および他のそのような基準を使用してファイル間で行われる区別が、コアスキーマの機能と類似している。項目ベースのハードウェア／ソフトウェアインターフェースシステムでは、コアスキーマは、直接に（項目タイプにより）、または間接的に（項目サブタイプにより）すべての項目を特徴付けて、項目ベースのハードウェア／ソフトウェアインターフェースシステムが理解し、所定の、予測できる形で直接に処理することができる１つまたは複数のコアスキーマ項目タイプに入れる、コア項目タイプのセットを定義する。事前定義された項目タイプは、項目ベースのハードウェア／ソフトウェアインターフェースシステム内の最も一般的な項目を反映し、このため、項目ベースのハードウェア／ソフトウェアインターフェースシステムが、コアスキーマを含むそれらの事前定義された項目タイプを理解することで、効率がある程度、向上する。

一部の実施形態では、コアスキーマは、拡張可能ではない。つまり、コアスキーマの一部である特定の事前定義された、派生させられた項目タイプを除き、基礎スキーマ内の項目タイプから直接にサブタイプ付けされることが可能なさらなる項目タイプは存在しない。コアスキーマの拡張を防止することにより（つまり、コアスキーマに新たな項目を追加するのを防止することにより）、ストレージプラットフォームは、コアスキーマ項目の使用を義務付ける。というのは、すべてのその後の項目タイプは、必然的にコアスキーマ項目タイプのサブタイプだからである。この構造により、追加の項目タイプを定義する際に妥当な度合いの柔軟性が可能になる一方で、コア項目タイプの事前定義されたセットを有することの利点も保たれる。

本発明の様々な実施形態に関して、図８Ａを参照すると、コアスキーマによってサポートされる特定の項目タイプが、以下の１つまたは複数を含むことが可能である。すなわち、
・カテゴリ：その項目タイプの項目（およびその項目から派生させられたサブタイプ）が、項目ベースのハードウェア／ソフトウェアインターフェースシステムにおける有効なカテゴリを表す
・商品：識別可能な価値ある事物（ｔｈｉｎｇｓｏｆｖａｌｕｅ）
・デバイス：情報処理能力をサポートする論理的構造を有する項目
・ドキュメント：項目ベースのハードウェア／ソフトウェアインターフェースシステムによって解釈されないが、代わりに、ドキュメントタイプに対応するアプリケーションプログラムによって解釈される内容を有する項目
・イベント：環境におけるある出現（ｏｃｃｕｒｅｎｃｅ）を記録する項目
・場所：物理的場所（例えば、地理的場所）を表す項目
・メッセージ：２つ以上のプリンシパル（以下に定義する）間における通信の項目
・プリンシパル：ＩｔｅｍＩｄ以外に少なくとも１つの確実に証明可能なＩＤ（例えば、個人、組織、グループ、世帯、機関（ａｕｔｈｏｒｉｔｙ）、サービスなどの識別）を有する項目
・ステートメント：限定としてではなく、ポリシー、サブスクリプション、資格情報などを含む、環境に関する特別な情報を有する項目

同様に、図８Ｂを参照すると、コアスキーマによってサポートされる特定のプロパティは、以下の１つまたは複数を含むことが可能である。
・証明書（基礎スキーマ内の基礎的なＰｒｏｐｅｒｔｙＢａｓｅタイプから派生させられた）
・プリンシパルＩＤキー（基礎スキーマ内のＩｄｅｎｔｉｔｙＫｅｙから派生させられた）
・郵便アドレス（基礎スキーマ内のプロパティタイプから派生させられた）
・リッチテキスト（基礎スキーマ内のプロパティタイプから派生させられた）
・ＥＡｄｄｒｅｓｓ（基礎スキーマ内のプロパティタイプから派生させられた）
・ＩｄｅｎｔｉｔｙＳｅｃｕｒｉｔｙＰａｃｋａｇｅ（基礎スキーマ内の関係タイプから派生させられた）
・ＲｏｌｅＯｃｃｕｐａｎｃｙ（基礎スキーマ内の関係タイプから派生させられた）
・ＢａｓｉｃＰｒｅｓｅｎｃｅ（基礎スキーマ内の関係タイプから派生させられた）
以上の項目およびプロパティは、図８Ａおよび図８Ｂに記載されたそれぞれののプロパティによってさらに記述される。

５．関係
関係は、１つの項目が、ソースとして指定され、他方の項目が目標として指定されるバイナリ関係である。ソース項目および目標項目は、関係によって関連付けられる。ソース項目は、一般に、関係の有効期間（ｌｉｆｅ−ｔｉｍｅ）を支配する。つまり、ソース項目が削除されると、項目間の関係も削除される。

関係は、包含関係と参照関係に分類される。包含関係は、目標項目の有効期間を支配し、他方、参照関係は、有効期間管理セマンティクス（ｓｅｍａｎｔｉｃｓ）をまったく提供しない。図１２は、関係が分類される仕方を示す。

包含関係タイプは、保持関係と組み込み関係にさらに分類される。項目に対するすべての保持関係が除去されると、その項目は、削除される。保持関係は、参照カウントメカニズムを介して目標の有効期間を支配する。組み込み関係は、複合項目のモデル化を可能にし、排他的な保持関係として考えることができる。項目は、１つまたは複数の保持関係の目標であることが可能であるが、項目は、厳密に１つの組み込み関係の目標であることが可能である。組み込み関係の目標である項目は、他のいずれの保持関係または組み込み関係の目標であることも可能でない。

参照関係は、目標項目の有効期間を支配しない。参照関係は、ぶら下がり（ｄａｎｎｇｌｉｎｇ）であることが可能である。つまり、目標項目が存在しないことが可能である。参照関係は、グローバル項目名前空間のどこでも（すなわち、リモートデータストアを含め）項目への参照をモデル化するのに使用することができる。

項目をフェッチすることにより、項目の関係が自動的にフェッチされることはない。アプリケーションは、項目の関係を明示的に要求しなければならない。さらに、関係を変更することにより、ソース項目または目標項目は変更されず、同様に、関係を追加することにより、ソース／目標項目は影響を受けない。

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

ソース項目は、関係の所有者である。所有者として指定された項目が、関係の有効期間を支配するが、関係自体は、その関係が関連付ける項目とは別個である。ストレージプラットフォームＡＰＩ３２２は、項目に関連する関係を公開するためのメカニズムを提供する。

以下は、関係宣言の実施例である。

これは、参照関係の実施例である。関係は、ソース参照によって参照される個人項目が存在しない場合、作成することができない。また、個人項目が削除された場合、個人と組織の間の関係インスタンスも削除される。ただし、組織項目が削除された場合、関係は、削除されず、関係は、ぶら下がりになる。

ｂ）保持関係
保持関係は、目標項目の参照カウントベースの有効期間管理をモデル化するのに使用される。

項目は、項目群に対する０以上の関係のソースエンドポイントであることが可能である。組み込まれた項目でない項目は、１つまたは複数の保持関係にある目標であることが可能である。

目標エンドポイント参照タイプは、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅでなければならず、関係インスタンスと同一のストア内の項目を参照しなければならない。

保持関係は、目標エンドポイントの有効期間管理を実施する。保持関係インスタンス、および保持関係インスタンスが目標とする項目の作成は、アトミック（ａｔｏｍｉｃ）操作である。同一の項目を目標とする追加の保持関係インスタンスを作成することができる。目標エンドポイントとして所与の項目を有する最後の保持関係インスタンスが削除されると、その目標項目も削除される。

関係宣言の中で指定されたエンドポイント項目のタイプは、一般に、関係のインスタンスが作成されると実施される。エンドポイント項目のタイプは、関係が確立された後、変更することができない。

保持関係は、項目名前空間を形成する際に重要な役割をする。保持関係は、ソース項目に相対する目標項目の名前を定義する「名前」プロパティを含む。この相対的な名前は、所与の項目をソースとするすべての保持関係に固有である。ルート項目から始まり、所与の項目に至るこの相対的な名前の順序付けられたリストは、項目に対する完全な名前を形成する。

保持関係は、ＤＡＧ（有向非循環グラフ）を形成する。保持関係が作成されると、システムは、循環が作成されないことを確実にして、項目名前空間がＤＡＧを形成することを確実にする。

保持関係は、目標項目の有効期間を支配するが、目標エンドポイント項目の操作上の整合性は支配しない。目標項目は、保持関係を介してその目標項目を所有する項目とは、操作上、独立している。保持関係のソースである項目に対するコピー、移動、バックアップ、およびその他の操作は、同一の関係の目標である項目に影響を与えない。つまり、例えば、フォルダ項目をバックアップすることにより、そのフォルダ内のすべての項目（ＦｏｌｄｅｒＭｅｍｂｅｒ関係の目標）が自動的にバックアップされることはない。

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

ＦｏｌｄｅｒＭｅｍｂｅｒｓ関係は、項目の一般的な集合としてのフォルダの概念を可能にする。

ｃ）組み込み関係
組み込み関係は、目標項目の有効期間の排他的支配の概念をモデル化する。組み込み関係は、複合項目の概念を可能にする。

組み込み関係インスタンス、および組み込み関係インスタンスが目標とする項目の作成は、アトミック操作である。項目は、０以上の組み込み関係のソースであることが可能である。ただし、項目は、１つ限りの組み込み関係の目標であることしかできない。組み込み関係の目標である項目は、保持関係の目標であることはできない。

目標エンドポイント参照タイプは、ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅでなければならず、関係インスタンスと同一のデータストア内の項目を参照しなければならない。

組み込み関係は、目標エンドポイントの操作上の整合性を支配する。例えば、項目のシリアル化の操作は、その項目をソースとするすべての組み込み関係、およびそれらの組み込み関係の目標のすべてのシリアル化を含むことが可能であり、ある項目をコピーすることにより、その項目のすべての組み込まれた項目もコピーされる。

以下は、典型的な宣言である。

ｄ）参照関係
参照関係は、その関係が参照する項目の有効期間を支配しない。さらに、参照関係は、目標の存在を保証せず、関係宣言の中で指定された目標のタイプを保証することもしない。これは、参照関係がぶら下がりであることが可能であることを意味する。また、参照関係は、他のデータストア内の項目を参照することもできる。参照関係は、Ｗｅｂページ内のリンクに類似した概念として考えることができる。

参照関係宣言の実施例は、以下のとおりである。

いずれの参照タイプも目標エンドポイントの中で許される。参照関係に参加する項目は、任意の項目タイプであることが可能である。

参照関係は、項目間におけるほとんどの有効期間管理でない関係をモデル化するのに使用される。目標の存在は、強制（ｅｎｆｏｒｃｅ）されないので、参照関係は、疎結合の関係をモデル化するのに便利である。参照関係は、他のコンピュータ上のストアを含む、他のデータストア内の項目を目標とするのに使用することができる。

ｅ）規則および制約
以下の追加の規則および制約が、関係に適用される。すなわち、
・項目は、（厳密に１つの組み込み関係）または（１つまたは複数の保持関係）の目標でなければならない。１つの例外は、ルート項目である。項目は、０以上の参照関係の目標であることが可能である
・組み込み関係の目標である項目は、保持関係のソースであることはできない。そのような項目は、参照関係のソースであることが可能である
・項目は、その項目がファイルから昇格された場合、保持関係のソースであることができない。そのような項目は、組み込み関係および参照関係のソースであることが可能である
・ファイルから昇格された項目は、組み込み関係の目標であることができない

ｆ）関係の順序付け
少なくとも１つの実施形態において、本発明のストレージプラットフォームは、関係の順序付けをサポートする。順序付けは、基礎関係定義における「順序」と名付けられたプロパティを介して達せられる。順序フィールドに対する一意性制約（ｕｎｉｑｕｅｎｅｓｓｃｏｎｓｔｒａｉｎｔ）は、存在しない。同一の「順序」プロパティ値を有する関係群の順序は、保証されないが、それらの関係が、より低い「順序」値を有する関係群より後、より高い「順序」フィールド値を有する関係群より前に順序付けられることが可能であることは保証される。

アプリケーションは、組合せ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ、順序）に関して順序付けることにより、既定の順序で関係を獲得することができる。所与の項目をソースとするすべての関係インスタンスは、集合の中の関係のタイプにかかわらず、単一の集合として順序付けられる。ただし、これは、所与のタイプ（例えば、ＦｏｌｄｅｒＭｅｍｂｅｒｓ）のすべての関係が、所与の項目に関する関係集合の順序付けられたサブセットであることを保証する。

関係を操作するためのデータストアＡＰＩ３２１は、関係の順序付けをサポートする操作のセットを実施する。以下の用語を、それらの操作を説明するのに役立つように概説する。
・ＲｅｌＦｉｓｒｔは、ＯｒｄＦｉｓｒｔという順序値を有する順序付けられた集合内の最初の関係である
・ＲｅｌＬａｓｔは、ＯｒｄＬａｓｔという順序値を有する順序付けられた集合内の最後の関係である
・ＲｅｌＸは、ＯｒｄＸという順序値を有する集合内の所与の関係である
・ＲｅｌＰｒｅｖは、ＯｒｄＸより小さいＯｒｄＰｒｅｖという順序値を有する、ＲｅｌＸに対する集合の中の最も近い関係である
・ＲｅｌＮｅｘｔは、ＯｒｄＸより大きいＯｒｄＮｅｘｔという順序値を有するＲｅｌＸに対する、集合内の最も近い関係である

操作には、以下が含まれるが、以下には限定されない。すなわち、
・ＩｎｓｅｒｔＢｅｆｏｒｅＦｉｒｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ，Ｒｅｌａｓｈｉｎｓｈｉｐ）は、関係を集合内の最初の関係として挿入する。その新たな関係の「順序」プロパティの値は、ＯｒｄＦｉｒｓｔより小さいことが可能である
・ＩｎｓｅｒｔＡｆｔｅｒＬａｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ，Ｒｅｌａｓｈｉｎｓｈｉｐ）は、関係を集合内の最後の関係として挿入する。その新たな関係の「順序」プロパティの値は、ＯｒｄＬａｓｔより大きいことが可能である
・ＩｎｓｅｒｔＡｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，Ｒｅｌａｓｈｉｎｓｈｉｐ）は、「順序」プロパティとして指定された値を有する関係を挿入する
・ＩｎｓｅｒｔＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，Ｒｅｌａｓｈｉｎｓｈｉｐ）は、所与の順序値を有する関係より前に関係を挿入する。その新たな関係には、ＯｒｄＰｒｅｖとｏｒｄの中間の「順序」値が割り当てられることが可能である
・ＩｎｓｅｒｔＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，Ｒｅｌａｓｈｉｎｓｈｉｐ）は、所与の順序値を有する関係より後に関係を挿入する。その新たな関係には、ｏｒｄとＯｒｄＮｅｘｔの中間の「順序」値が割り当てられることが可能である
・ＭｏｖｅＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，ＲｅｌａｓｈｉｎｓｈｉｐＩＤ）は、所与の関係ＩＤを有する関係を、指定された「順序」値を有する関係より前に移動する。その関係には、ＯｒｄＰｒｅｖとｏｒｄの中間の新たな「順序」値が割り当てられることが可能である
・ＭｏｖｅＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ，ｏｒｄ，ＲｅｌａｓｈｉｎｓｈｉｐＩＤ）は、所与の関係ＩＤを有する関係を、指定された「順序」値を有する関係より後に移動する。その関係には、ｏｒｄとＯｒｄＮｅｘｔの中間の新たな「順序」値が割り当てられることが可能である

前述したとおり、すべての項目は、項目フォルダのメンバでなければならない。関係に関して、すべての項目は、項目フォルダとの関係を有さなければならない。本発明のいくつかの実施形態では、一部の関係は、項目間に存在する関係によって表される。

本発明の様々な実施形態に関して実施されるとおり、関係は、１つの項目（ソース）から別の項目（目標）へ「伸びる」有向のバイナリ関係をもたらす。関係は、ソース項目（関係を伸ばした項目）によって所有され、このため、関係は、そのソースが除去された場合、除去される（例えば、関係は、ソース項目が削除されると、削除される）。さらに、一部の実例では、関係は、目標項目の所有権を共有する（共同所有する）ことができ、そのような所有権は、その関係のＩｓＯｗｎｅｄプロパティ（または均等のプロパティ）の中で反映されることが可能である（関係プロパティタイプに関して図７に示すとおり）。それらの実施形態では、新たなＩｓＯｗｎｅｄ関係の作成により、目標項目に関する参照カウントが自動的に増分され、そのような関係の削除により、目標項目に関する参照カウントが減分されることが可能である。それらの特定の実施形態の場合、項目は、項目が０より大きい参照カウントを有する場合、存在しつづけ、カウントが０に達した場合、その時点で自動的に削除される。この場合も、項目フォルダは、他の項目群に対する関係のセットを有する（または有することができる）項目であり、それらの他の項目群は、項目フォルダのメンバシップを構成する。本明細書で説明する機能を実現する関係のその他の実際の実施形態も可能であり、本発明によって企図されている。

実際の実施形態にかかわらず、関係は、１つのオブジェクトから別のオブジェクトへの選択可能な接続である。項目が１つまたは複数の項目フォルダ、ならびに１つまたは複数のカテゴリに属することができること、ならびにそれらの項目、フォルダ、およびカテゴリが公開であるか、または秘密であるかは、項目ベースの構造ないの存在に与えられた意味（または意味の欠如）によって決まる。それらの論理的関係は、本明細書で説明する機能を達するために具体的に使用される物理的な実施形態にかかわらず、関係のセットに割り当てられた意味である。論理的関係は、項目と、項目の項目フォルダまたはカテゴリの間で確立される（その逆も同様である）。というのは、基本的に、項目フォルダおよびカテゴリはそれぞれ、特別なタイプの項目だからである。したがって、項目フォルダおよびカテゴリは、他のいずれの項目とも同一の仕方で操作されること、すなわち、限定としてではなく、コピーされること、電子メールメッセージに追加されること、ドキュメントに組み込まれることなどが可能であり、項目フォルダおよびカテゴリは、他の項目の場合と同一のメカニズムを使用して、シリアル化されること、およびシリアル化解除されること（インポートされること、およびエクスポートされること）が可能である。（例えば、ＸＭＬでは、すべての項目は、シリアル化形式を有することが可能であり、その形式が、項目フォルダ、カテゴリ、および項目に等しく適用される。）

項目と、項目の項目フォルダの間の関係を表す前述した関係は、項目から項目フォルダへ、項目フォルダから項目へ、またはその両方で論理的に伸びることが可能である。項目から項目フォルダへ論理的に伸びる関係は、項目フォルダが、その項目に公開であり、その項目と項目フォルダのメンバシップ情報を共有することを表し、反対に、項目から項目フォルダへの論理的関係の欠如は、その項目フォルダがその項目に秘密であり、その項目と項目フォルダのメンバシップ情報を共有しないことを表す。同様に、項目フォルダから項目に論理的に伸びる関係は、項目が、その項目フォルダに対して公開であり、共有可能であることを表すのに対して、項目フォルダから項目への論理的関係の欠如は、その項目が秘密であり、共有可能ではないことを表す。したがって、項目フォルダが別のシステムにエクスポートされた場合、新たなコンテキストにおいて共有されるのは、「公開の」項目であり、ある項目が、他の共有可能な項目に関して自らの項目フォルダを探索した場合、その項目に、項目フォルダに属する共有可能な項目に関する情報を提供するのは、「公開の」項目フォルダである。

図９は、項目フォルダ（やはり、それ自体項目である）、その項目フォルダのメンバ項目、ならびにその項目フォルダとその項目フォルダのメンバ項目の間の互いに結合する関係を示すブロック図である。項目フォルダ９００は、メンバとして複数の項目９０２、９０４、および９０６を有する。項目フォルダ９００は、項目フォルダ９００から項目９０２への関係９１２を有し、関係９１２は、項目９０２が、項目フォルダ９００、項目フォルダ９００のメンバ９０４および９０６、ならびに項目フォルダ９００にアクセスすることが可能な他のあらゆる項目フォルダ、カテゴリ、または項目（図示せず）に公開であり、共有可能であることを表す。しかし、項目９０２から項目フォルダ９００へは、まったく関係が存在せず、これは、項目フォルダ９００が、項目９０２に秘密であり、項目フォルダ９００のメンバシップ情報を項目９０２と共有しないことを表す。他方、項目９０４は、項目９０４から項目フォルダ９００への関係９２４を有し、関係９２４は、項目フォルダ９００が、項目９０４に公開であり、項目フォルダ９００のメンバシップ情報を項目９０４と共有することを表す。しかし、項目フォルダ９００から項目９０４への関係はまったく存在せず、これは、項目９０４が、項目フォルダ９００、項目フォルダの他のメンバ９０２および９０６、ならびに項目フォルダ９００にアクセスする可能性がある他のあらゆる項目フォルダ、カテゴリ、または項目（図示せず）に秘密であり、共有可能ではないことを表す。項目９０２および９０４に対する関係（または関係の欠如）とは対照的に、項目フォルダ９００は、項目フォルダ９００から項目９０６への関係９１６を有し、項目９０６は、項目フォルダ９００に戻る関係９２６を有し、関係９１６と関係９２６は一緒に、項目９０６が項目フォルダ９００、項目フォルダのメンバ９０２および９０４、ならびに項目フォルダ９００にアクセスする可能性がある他のあらゆるフォルダ、カテゴリ、または項目（図示せず）に公開で、共有可能であること、および項目フォルダ９００が、項目９０６に公開であり、項目９０６と項目フォルダ９００のメンバシップ情報を共有することを表す。

前述したとおり、項目フォルダ内の項目群は、項目フォルダが「記述」されていないため、共通性を共有する必要はない。他方、カテゴリは、カテゴリのメンバ項目のすべてに共通の共通性によって記述される。したがって、カテゴリのメンバシップは、記述された共通性を有する項目群に本質的に限定され、一部の実施形態では、カテゴリの記述を満たすすべての項目が、自動的にそのカテゴリのメンバにされる。このため、項目フォルダは、トリビアルな（ｔｒｉｖｉａｌ）タイプ構造が、メンバシップによって表現されることを可能にするのに対して、カテゴリは、定義された共通性に基づくメンバシップを可能にする。

もちろん、カテゴリ記述の性質は、論理的であり、したがって、カテゴリは、タイプ、プロパティ、および／または値の任意の論理的表現によって記述されることが可能である。例えば、カテゴリの論理的表現は、カテゴリのメンバシップが、２つのプロパティの１つ、または両方を有する項目を含むべきことであることが可能である。カテゴリに関するそれらの記述されたプロパティが、「Ａ」および「Ｂ」である場合、カテゴリメンバシップは、プロパティＡを有するが、プロパティＢは有さない項目群、プロパティＢを有するが、プロパティＡは有さない項目群、およびプロパティＡとプロパティＢをともに有する項目群を含むことが可能である。プロパティのこの論理的表現は、論理演算子「ＯＲ」で記述され、カテゴリによって記述されるメンバのセットは、プロパティＡＯＲＢを有する項目群である。当業者には理解されるとおり、同様の論理オペランド（限定としてではなく、「ＡＮＤ」、「ＸＯＲ」、および「ＮＯＴ」を単独で、または組合せで含む）も、カテゴリを記述するのに使用することができる。

項目フォルダ（記述されない）とカテゴリ（記述される）の間の区別にもかかわらず、項目に対するカテゴリの関係、およびカテゴリに対する項目の関係は、本発明の多数の実施形態における項目フォルダおよび項目に関して本明細書で上記に開示したのと基本的に同一の形である。

図１０は、カテゴリ（やはり、それ自体、項目である）、カテゴリのメンバ項目群、ならびにカテゴリとカテゴリのメンバ項目群の間の互いに結合する関係を示すブロック図である。カテゴリ１０００は、メンバとして複数の項目１００２、１００４、および１１０６を有し、これらのすべては、カテゴリ１０００によって記述される共通のプロパティ、値、またはタイプ１１０８の何らかの組合せ（共通性記述１００８’）を共有する。カテゴリ１０００は、カテゴリ１０００から項目１００２への関係１０１２を有し、関係１０１２は、項目１００２が、カテゴリ１０００、カテゴリ１０００のメンバ１００４および１００６、ならびにカテゴリ１０００にアクセスすることが可能な他のあらゆるカテゴリ、項目フォルダ、または項目（図示せず）に公開であり、共有可能であることを表す。しかし、項目１００２からカテゴリ１０００への関係はまったく存在せず、これは、カテゴリ１０００が、項目１００２に秘密であり、カテゴリ１０００のメンバシップ情報を項目１００２と共有しないことを表す。他方、項目１００４は、項目１００４からカテゴリ１０００への関係１０２４を有し、この関係１０２４は、カテゴリ１０００が、項目１００４に公開であり、カテゴリ１０００のメンバシップ情報を項目１００４と共有することを表す。しかし、カテゴリ１０００から項目１００４に伸ばされた関係はまったく存在せず、これは、項目１００４が、カテゴリ１０００、カテゴリ１０００の他のメンバ１００２および１００６、ならびにカテゴリ１０００にアクセスすることが可能な他のあらゆるカテゴリ、項目フォルダ、または項目（図示せず）に秘密であり、共有可能でないことを表す。項目１００２および１００４に対する関係（または関係の欠如）とは対照的に、カテゴリ１０００は、カテゴリ１０００から項目１００６への関係１０１６を有し、項目１００６は、カテゴリ１０００に戻る関係１０２６を有し、関係１０１６と関係１０２６は一緒に、項目１００６が、カテゴリ１０００、カテゴリ１０００の項目メンバ１００２および１００４、ならびにカテゴリ１０００にアクセスすることが可能な他のあらゆるカテゴリ、項目フォルダ、または項目（図示せず）に公開であり、共有可能であること、およびカテゴリ１０００が、項目１００６に公開であり、カテゴリ１０００のメンバシップ情報を項目１００６と共有することを表す。

最後に、カテゴリおよび項目フォルダはそれ自体、項目であり、項目は、互いに関係する（Ｒｅｌａｔｉｏｎｓｈｉｐ）ことが可能であるため、一部の代替の実施形態では、カテゴリは、項目フォルダに関係することが可能であり（また、その逆も同様であり）、項目は、他のカテゴリ、項目フォルダ、および項目にそれぞれ関係することが可能である。ただし、様々な実施形態では、項目フォルダ構造および／またはカテゴリ構造は、ハードウェア／ソフトウェアインターフェースシステムレベルで、循環を含むことが禁止される。項目フォルダ構造およびカテゴリ構造が有向グラフに類似する場合、循環を禁止する諸実施形態は、ＤＡＧ（有向非循環グラフ）に類似し、ＤＡＧは、グラフ理論の分野における数学的定義上、同一の頂点で始まり、終わるパスが存在しない有向グラフである。

６．拡張性
ストレージプラットフォームは、前述したとおり、スキーマ３４０の初期セットを備えるものとされる。ただし、加えて、少なくとも一部の実施形態では、ストレージプラットフォームは、ＩＳＶ（独立ソフトウェアベンダ）を含む顧客が、新たなスキーマ３４４（すなわち、新たな項目タイプおよび入れ子型要素タイプ）を作成することもできるようにする。このセクションは、スキーマ３４０の初期セットの中で定義された項目タイプおよび入れ子型要素タイプ（または単に「要素」タイプ）を拡張することにより、そのようなスキーマを作成するためのメカニズムを対象とする。

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

ストレージプラットフォームスキーマの初期セットによって定義された項目タイプまたは入れ子型要素タイプは、ＩＳＶアプリケーションのニーズに正確に合致しない可能性があるので、ＩＳＶが、タイプをカスタマイズすることができるようにすることが必要である。これが、拡張の概念で可能になる。拡張は、厳密にタイプ付けされたインスタンスであるが、（ａ）独立には存在することができず、（ｂ）項目または入れ子型要素に付加されなければならない。

スキーマ拡張性の必要性に対処することに加えて、拡張は、「マルチタイプ付け（ｍｕｌｔｉ−ｔｙｐｉｎｇ）」問題に対処することも目的とする。一部の実施形態では、ストレージプラットフォームは、複数の継承、または重なり合うサブタイプをサポートすることができないため、アプリケーションは、重なり合うタイプインスタンス（例えば、ドキュメントが、法的ドキュメントであるとともにセキュリティで保護されたドキュメントである）をモデル化する手段として拡張を使用することができる。

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

Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎタイプは、以下のとおり基礎スキーマの中で定義される。すなわち、

ＩｔｅｍＩＤフィールドは、拡張が関連付けられる項目のＩｔｅｍＩＤを含む。このＩｔｅｍＩＤを有する項目が存在しなければならない。拡張は、所与のＩｔｅｍＩＤを有する項目が存在しない場合、作成することができない。その項目が削除されると、同一のＩｔｅｍＩＤを有するすべての拡張も削除される。タプル（ｔｕｐｌｅ）（ＩｔｅｍＩＤ、ＥｘｔｅｎｓｉｏｎＩＤ）により、拡張インスタンスが一意に識別される。

拡張タイプの構造は、項目タイプの構造に類似する。すなわち、
・拡張タイプは、フィールドを有し、
・フィールドは、プリミティブ要素タイプまたは入れ子型要素タイプであることが可能であり、
・拡張タイプは、サブタイプ付けされることが可能である。

以下の制約が、拡張タイプに適用される。すなわち、
・拡張は、関係のソースおよび目標であることはできず、
・拡張タイプインスタンスは、項目とは独立に存在することができず、
・拡張タイプは、ストレージプラットフォームタイプ定義の中でフィールドタイプとして使用することができない。

所与の項目タイプに関連付けられることが可能な拡張のタイプに対する制限は、まったく存在しない。任意の拡張タイプが、任意の項目タイプを拡張することが許される。複数の拡張インスタンスが項目に付加された場合、それらのインスタンスは、構造と挙動の両方において互いに独立である。

拡張インスタンスは、格納され、項目から別々にアクセスされる。すべての拡張タイプインスタンスは、グローバル拡張ビュー（ｖｉｅｗ）からアクセス可能である。所与のタイプの拡張のすべてのインスタンスを、それらのインスタンスがどのようなタイプの項目に関連付けられているかにかかわらず戻す、効率的なクエリを作成することができる。ストレージプラットフォームＡＰＩは、項目上の拡張の格納、取り出し、および変更を行うことができるプログラミングモデルを提供する。

拡張タイプは、ストレージプラットフォーム単一継承モデルを使用してサブタイプ付けされたタイプであることが可能である。拡張タイプから導出することにより、新たな拡張タイプが作成される。拡張の構造または挙動により、項目タイプ階層の構造または挙動が取り消される、または取って代わられることが可能である。項目タイプと同様に、拡張タイプインスタンスも、その拡張タイプに関連するビューを介して直接にアクセスすることができる。拡張のＩｔｅｍＩＤは、拡張がいずれの項目に属するかを示し、グローバル項目ビューから対応する項目オブジェクトを取り出すのに使用することができる。拡張は、操作上の整合性のため、項目の一部であると考えられる。コピー／移動、バックアップ／復元、またはストレージプラットフォームが定義するその他の一般的な操作が、項目の一部としての拡張に対して行われることが可能である。

以下の実施例を考慮されたい。連絡先タイプが、Ｗｉｎｄｏｗｓ（登録商標）タイプセットの中で定義される。

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

ＨＲアプリケーション開発者が、追加のデータも連絡先に付加することを所望する可能性がある。このデータは、ＣＲＭアプリケーションデータとは独立である。この場合も、アプリケーション開発者は、拡張を作成することができる。

ＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは、連絡先項目に付加することができる２つの独立した拡張である。ＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは、互いに独立に作成され、アクセスされる。

前述した実施例では、ＣＲＭＥｘｔｅｎｓｉｏｎタイプのフィールドおよびメソッドは、連絡先階層のフィールドまたはメソッドを取り消すことができない。ＣＲＭＥｘｔｅｎｓｉｏｎタイプのインスタンスは、連絡先以外の項目タイプにも付加することができることに留意されたい。

連絡先項目が取り出された場合、連絡先項目の項目拡張は、自動的には取り出されない。連絡先項目を所与として、連絡先項目の関連する項目拡張には、同一のＩｔｅｍＩｄを有する拡張に関してグローバル拡張ビューにクエリを行うことによってアクセスすることができる。

システム内のすべてのＣＲＭＥｘｔｅｎｓｉｏｎ拡張には、ＣＲＭＥｘｔｅｎｓｉｏｎ拡張がいずれの項目に属するかにかかわらず、ＣＲＭＥｘｔｅｎｓｉｏｎタイプビューを介してアクセスすることができる。項目のすべての項目拡張が、同一の項目ｉｄを共有する。前述した実施例では、連絡先項目インスタンスと、付加されたＣＲＭＥｘｔｅｎｓｉｏｎインスタンスおよびＨＲＥｘｔｅｎｓｉｏｎインスタンス、同一のＩｔｅｍＩＤ。

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

ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプを拡張すること
入れ子型要素タイプは、項目タイプと同一のメカニズムを使用して拡張されない。入れ子型要素の拡張は、入れ子型要素タイプのフィールドと同一のメカニズムを使用して格納され、アクセスされる。

データモデルは、要素と名付けられた入れ子型要素タイプのルートを以下のとおり定義する。すなわち、

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

ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張は、項目拡張とは以下の形で異なる。すなわち、
・入れ子型要素拡張は、拡張タイプではない。入れ子型要素拡張は、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎタイプをルートとする拡張タイプ階層に属さない
・入れ子型要素拡張は、項目の他のフィールドとともに格納され、グローバルにアクセス可能ではない、つまり、所与の拡張タイプのすべてのインスタンスを取り出すクエリを作成することはできない
・これらの拡張は、他の入れ子型要素（項目の）が格納されるのと同一の形で格納される。他の入れ子型セットと同様に、ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張も、ＵＤＴの中に格納される。ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張は、入れ子型要素タイプの拡張フィールドを介してアクセス可能である
・複数の値を有するプロパティにアクセスするのに使用される収集インターフェース群も、タイプ拡張のセットにアクセスし、そのセットを対象に繰り返す（ｉｔｅｒａｔｅｏｖｅｒ）ために使用される

以下のテーブルは、項目拡張とＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張を要約し、比較する。

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

ＯＯ（オブジェクト指向）データベースシステムは、プログラミング言語オブジェクト（例えば、Ｃ＋＋、Ｊａｖａ（登録商標））のための永続性およびトランザクションを提供する。「項目」というストレージプラットフォーム概念は、オブジェクト指向システムにおける「オブジェクト」にうまくマップされる。ただし、組み込まれた集合が、オブジェクトに追加されなければならない。継承タイプおよび入れ子型要素タイプのような他のストレージプラットフォームタイプの概念も、オブジェクト指向タイプのシステムにマップされる。オブジェクト指向システムは、通常、オブジェクトＩＤを既にサポートしており、このため、項目ＩＤは、オブジェクトＩＤにマップされることが可能である。項目挙動（操作）は、オブジェクトメソッドにうまくマップされる。しかし、オブジェクト指向システムは、通常、編成上の諸機能を欠き、探索することに劣っている。また、オブジェクト指向システムは、非構造化データ、および半構造化データのサポートを提供しない。本明細書で説明する完全なストレージプラットフォームデータモデルをサポートするため、関係、フォルダ、および拡張などの概念が、オブジェクトデータモデルに追加される必要がある。さらに、昇格、同期、通知、セキュリティなどのメカニズムが、実施される必要がある。

オブジェクト指向システムと同様に、ＸＳＤ（ＸＭＬスキーマ定義）に基づくＸＭＬデータベースも、単一継承ベースのタイプシステムをサポートする。本発明の項目タイプシステムは、ＸＳＤタイプモデルにマップされることが可能である。また、ＸＳＤは、挙動のサポートも提供しない。項目に関するＸＳＤは、項目挙動で強化されなければならない。ＸＭＬデータベースは、単独のＸＳＤドキュメントを扱い、編成機能、および広域探索（ｂｒｏａｄｓｅａｒｃｈ）機能を欠いている。オブジェクト指向データベースの場合と同様に、本明細書で説明するデータモデルをサポートするのに、関係およびフォルダのような他の概念がそのようなＸＭＬデータベースに組み込まれる必要があり、また、同期メカニズム、通知メカニズム、およびセキュリティメカニズムのようなメカニズムも実施される必要がある。

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

１．ＵＤＴを使用するデータストア実装
この実施形態では、一実施形態では、ＭｉｃｒｏｓｏｆｔＳＱＬＳｅｒｖｅｒエンジンを含むリレーショナルデータベースエンジン３１４が、ビルトイン（ｂｕｉｌｔ−ｉｎ）スカラータイプをサポートする。ビルトインスカラータイプは、「ネイティブ」であり、「単純」である。ビルトインスカラータイプは、ユーザが、ユーザの独自のタイプを定義することができないという意味でネイティブであり、複雑な構造をカプセル化することができないという点で単純である。ユーザ定義タイプ（以降、ＵＤＴ）が、ユーザが、複雑な構造化されたタイプを定義することによってタイプシステムを拡張することができるようにすることにより、ネイティブスカラータイプシステムを超えたタイプ拡張性のための機能を提供する。ユーザによって定義されると、ＵＤＴは、ビルトインスカラータイプが使用されることが可能なタイプシステム内のあらゆる場所で使用されることが可能である。

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

ＵＤＴは、ＣＬＲクラスである。すなわち、ＵＤＴは、状態（すなわち、データフィールド）および挙動（すなわち、ルーチン）を有する。ＵＤＴは、管理される言語、すなわち、Ｃ＃、ＶＢ．ＮＥＴなどのいずれかを使用して定義される。ＵＤＴメソッドおよびＵＤＴオペレータは、そのタイプのインスタンスに対するＴ−ＳＱＬの中で呼び出されることが可能である。ＵＤＴは、行の中の列のタイプ、Ｔ−ＳＱＬ内のルーチンのパラメータのタイプ、またはＴ−ＳＱＬ内の変数のタイプであることが可能である。

ストレージプラットフォームスキーマのＵＤＴクラスへのマッピングは、高いレベルで相当に単純明快である。一般に、ストレージプラットフォームスキーマは、ＣＬＲ名前空間にマップされる。ストレージプラットフォームタイプは、ＣＬＲクラスにマップされる。ＣＬＲクラス継承は、ストレージプラットフォームタイプ継承をミラーリングし、ストレージプラットフォームプロパティは、ＣＬＲクラスプロパティにマップされる。

２．項目マッピング
項目がグローバルに探索可能であること、およびこの実施形態のリレーショナルデータベースにおいて、継承およびタイプの代替可能性（ｓｕｂｓｔｉｔｕｔａｂｉｌｉｔｙ）のサポートが望ましいことから、データベースストア内の項目ストレージに関する１つの可能な実施形態は、すべての項目をＢａｓｅ．Ｉｔｅｍというタイプの列を有する単一のテーブルの中に格納することである。タイプ代替可能性を使用して、すべてのタイプの項目が格納されることが可能であり、探索が、Ｙｕｋｏｎの「ｉｓｏｆ（タイプ）」演算子を使用して、項目タイプおよび項目サブタイプに従ってフィルタリングされることが可能である。

ただし、そのようなアプローチに関連するオーバーヘッドに関する懸念により、この実施形態では、項目は、最上レベルタイプに従って分けられ、各タイプ「ファミリ」の項目が、別個のテーブルの中に格納されるようにする。この分割スキームの下では、Ｂａｓｅ．Ｉｔｅｍから直接に継承する各項目タイプに関して、テーブルが作成される。これらの項目タイプより下で継承するタイプは、前述したとおり、タイプ代替可能性を使用して、適切なタイプファミリテーブルの中に格納される。Ｂａｓｅ．Ｉｔｅｍからの最初の継承レベルだけが、特別に扱われる。

すべての項目に関するグローバルに探索可能プロパティのコピーを格納するのに、「シャドー（ｓｈａｄｏｗ）」テーブルが使用される。このテーブルは、すべてのデータ変更が行われるストレージプラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドによって維持されることが可能である。タイプファミリテーブルとは異なり、このグローバル項目テーブルは、項目の最上レベルスカラープロパティだけを含み、完全なＵＤＴ項目オブジェクトは含まない。グローバル項目テーブルは、ＩｔｅｍＩＤおよびＴｙｐｅＩＤを公開することにより、タイプファミリテーブルの中に格納された項目オブジェクトへのナビゲーション（ｎａｖｉｇａｔｉｏｎ）を可能にする。ＩｔｅｍＩＤにより、一般に、データストア内で項目が一意に識別される。ＴｙｐｅＩＤは、本明細書で説明しないメタデータを使用して、タイプ名、ならびに項目を含むビューにマップされることが可能である。項目のＩｔｅｍＩＤで項目を探し出すことは、グローバル項目のコンテキストにおいても、それ以外でも一般的な操作であることが可能であるので、項目のＩｔｅｍＩＤを所与として、項目オブジェクトを取り出すＧｅｔＩｔｅｍ（）関数が提供される。

好都合なアクセスのため、および可能な限り実施の詳細を隠すため、項目のすべてのクエリは、前述した項目テーブル上に構築されたビューに対して行われることが可能である。具体的には、適切なタイプファミリテーブルに照らして、各項目タイプに関してビューが作成されることが可能である。それらのタイプビューは、サブタイプを含め、関連するタイプのすべての項目を選択することが可能である。便宜のため、ＵＤＴオブジェクトに加え、ビューは、継承されたフィールドを含め、そのタイプの最上レベルフィールドのすべてに関する列を公開することが可能である。

３．拡張マッピング
拡張は、項目によく類似しており、同一の要件のいくつかを有する。継承をサポートする別のルートタイプとして、拡張は、ストレージにおける同一の考慮事項およびトレードオフの多くの対象となる。このため、単一テーブルアプローチではなく、類似したタイプファミリマッピングが、拡張にも適用される。もちろん、他の諸実施形態では、単一テーブルアプローチを使用することもできる。この実施形態では、拡張は、ＩｔｅｍＩＤで厳密に１つだけの項目に関連付けられ、項目のコンテキストにおいて一意であるＥｘｔｅｎｓｉｏｎＩＤを含む。項目の場合と同様に、ＩｔｅｍＩＤとＥｘｔｅｎｓｉｏｎＩＤのペアから成る拡張のＩＤを所与として、拡張を取り出す関数が提供されることが可能である。各拡張タイプに関して、項目タイプビューに類似したビューが作成される。

４．入れ子型要素マッピング
入れ子型要素は、項目、拡張、関係、または他の入れ子型要素に組み込み、深く入れ子になった構造を形成することができるタイプである。項目および拡張と同様に、入れ子型要素は、ＵＤＴとして実施されるが、項目および拡張の中に格納される。したがって、入れ子型要素は、入れ子型要素の項目コンテナおよび拡張コンテナのマッピングを超えたストレージマッピングは有さない。つまり、ＮｅｓｔｅｄＥｌｅｍｅｎｔのインスタンスを直接に格納するシステム内のテーブルは存在せず、入れ子型要素に専用のビューは存在しない。

５．オブジェクトＩＤ
データモデル内の各エンティティ、すなわち、各項目、各拡張、および各関係は、固有キー値を有する。項目は、項目のＩｔｅｍＩｄで一意に識別される。拡張は、（ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ）という合成キーで一意に識別される。関係は、（ＩｔｅｍＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄ）という合成キーで識別される。ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ、およびＲｅｌａｔｉｏｎＩｄは、ＧＵＩＤ値である。

６．ＳＱＬオブジェクト名前付け
データストア内で作成されたすべてのオブジェクトは、ストレージプラットフォームスキーマ名から派生させられたＳＱＬスキーマ名の中に格納されることが可能である。例えば、ストレージプラットフォーム基礎スキーマ（しばしば、「基礎」と呼ぶ）は、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．Ｉｔｅｍ」などの「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］」ＳＱＬスキーマの中でタイプを生成することができる。生成された名前には、修飾子が前置されて、名前付けの競合をなくす。適宜、感嘆文字（！）を、名前の各論理的部分に関する区切り記号（ｓｅｐａｒａｔｏｒ）として使用する。以下のテーブルが、データストア内のオブジェクトに関して使用される名前付け規約の概略を示す。各スキーマ要素（項目、拡張、関係、およびビュー）が、データストア内のインスタンスにアクセスするのに使用される修飾された（ｄｅｃｏｒａｔｅｄ）名前付けの規約とともにリストアップされている。

７．列名前付け
任意のオブジェクトモデルをストア内にマッピングする際、名前付け競合の可能性が、アプリケーションオブジェクトとともに格納される追加の情報に起因して生じる。名前付け競合を回避するため、すべてのタイプ固有でない列（タイプ宣言の中の名前付きプロパティに直接にマップされない列）に、下線（＿）文字が前置されることになる。この実施形態では、下線（＿）文字は、いずれの識別子プロパティの開始文字としては許されない。さらに、ＣＬＲとデータストアの間で名前付けを統一するため、ストレージプラットフォームのタイプまたはスキーマ要素（関係など）のすべてのプロパティは、大文字を使用した最初の文字を有さなければならない。

８．探索ビュー
格納されたコンテンツを探索するためのビューが、ストレージプラットフォームによって提供される。各項目および各拡張タイプに関してＳＱＬビューが提供される。さらに、関係およびビュー（データモデルによって定義される）をサポートするビューが提供される。ストレージプラットフォーム内のすべてのＳＱＬビューおよび基礎にあるテーブルは、読み取り専用である。データは、以下により十分に説明するとおり、ストレージプラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドを使用して、格納する、または変更することができる。

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

ストレージプラットフォームデータストア内のすべてのＳＱＬ探索ビューは、列に関する以下の順序付け規約を使用する。すなわち、
・ＩｔｅｍＩｄ、ＥｌｅｍｅｎｔＩｄなどのビュー結果の論理的「キー」列
・ＴｙｐｅＩｄなどの結果のタイプに関するメタデータ情報
・ＣｒｅａｔｅＶｅｒｓｉｏｎ、ＵｐｄａｔｅＶｅｒｓｉｏｎなどの変更追跡列
・タイプ固有の列（宣言されたタイプのプロパティ）
・タイプ固有のビュー（ファミリビュー）は、オブジェクトを戻すオブジェクト列も含む。

各タイプファミリのメンバは、一連の項目ビューを使用して探索可能であり、データストア内の項目タイプ当たり１つのビューが存在する。図２８は、項目探索ビューの概念を示す図である。

ａ）項目
各項目探索ビューは、特定のタイプ、またはそのタイプのサブタイプの項目の各インスタンスに関する行を含む。例えば、ドキュメントに関するビューは、ドキュメント、ＬｅｇａｌＤｏｃｕｍｅｎｔ、およびＲｅｖｉｅｗＤｏｃｕｍｅｎｔのインスタンスを戻すことが可能である。この例を所与として、項目ビューを図２９に示すとおり概念化することができる。

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

（２）タイプ付き項目探索ビュー
各項目タイプは、探索ビューも有する。ルート項目ビューに類似するが、このビューは、「＿Ｉｔｅｍ」列を介して項目オブジェクトへのアクセスも提供する。各タイプ付き項目探索ビューは、［ｓｃｈｅｍａＮａｍｅ］．［ｉｔｅｍＴｙｐｅＮａｍｅ］という名前を使用してデータストア内で識別される。例えば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［ＯｆｆｉｃｅＤｏｃ］。

ａ）項目拡張
ＷｉｎＦＳストア内のすべての項目拡張も、探索ビューを使用してアクセス可能である。

（１）マスタ拡張探索ビュー
データストアの各インスタンスは、マスタ拡張ビューと呼ばれる特別な拡張ビューを定義する。このビューは、データストア内の各拡張に関する概要情報を提供する。ビューは、拡張のタイプを記述する列、ならびに変更追跡情報および同期情報を提供するのに使用されるいくつかの列である、拡張プロパティ当たり１つの列を提供する。マスタ項目ビューは、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［マスタ！拡張］」という名前を使用してデータストア内で識別される。

（１）タイプ付き拡張探索ビュー
各拡張タイプは、探索ビューも有する。マスタ拡張ビューに類似するが、このビューは、＿Ｅｘｔｅｎｓｉｏｎ列を介して項目オブジェクトへのアクセスも提供する。各タイプ付き拡張探索ビューは、［ｓｃｈｅｍａＮａｍｅ］．［拡張！ｅｘｔｅｎｓｉｏｎＴｙｐｅＮａｍｅ］という名前を使用してデータストア内で識別される。例えば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［拡張！ＯｆｆｉｃｅＤｏｃＥｘｔ］。

入れ子型要素
すべての入れ子型要素は、項目インスタンス、拡張インスタンス、または関係インスタンスの中に格納される。このため、すべての入れ子型要素は、適切な項目探索ビュー、拡張探索ビュー、または関係探索ビューにクエリを行うことによってアクセスされる。

ｃ）関係
前述したとおり、関係は、ストレージプラットフォームデータストア内の項目間をリンクする基本的な単位を形成する。

（１）マスタ関係探索ビュー
各データストアは、マスタ関係ビューを提供する。このビューは、データストア内のすべての関係インスタンスに関する情報を提供する。マスタ関係ビューは、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［マスタ！関係］」という名前を使用してデータストア内で識別される。

（２）関係インスタンス探索ビュー
それぞれの宣言された関係は、特定の関係のすべてのインスタンスを戻す探索ビューも有する。マスタ関係ビューに類似するが、このビューは、関係データの各プロパティに関する名前付き列も提供する。各関係インスタンス探索ビューは、［ｓｃｈｅｍａＮａｍｅ］．［関係！ｒｅｌａｔｉｏｎｓｈｉｐＮａｍｅ］という名前を使用してデータストア内で識別される。例えば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［関係！ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ］。

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

操作形式は、拡張可能であり、スキーマ要素に対する様々な操作を提供する。いくつかの一般的な操作には、以下が含まれる。すなわち、
１．項目操作：
ａ．ＣｒｅａｔｅＩｔｅｍ（組み込み関係または保持関係のコンテキストにおいて新たな項目を作成する）
ｂ．ＵｐｄａｔｅＩｔｅｍ（既存の項目を更新する）
２．関係操作：
ａ．ＣｒｅａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（参照関係または保持関係のインスタンスを作成する）
ｂ．ＵｐｄａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（関係インスタンスを更新する）
ｃ．ＤｅｌｅｔｅＲｅｌａｔｉｏｎｓｈｉｐ（関係インスタンスを除去する）
３．拡張操作：
ａ．ＣｒｅａｔｅＥｘｔｅｎｓｉｏｎ（既存の項目に拡張を追加する）
ｂ．ＵｐｄａｔｅＥｘｔｅｎｓｉｏｎ（既存の拡張を更新する）
ｃ．ＤｅｌｅｔｅＥｘｔｅｎｓｉｏｎ（拡張を削除する）

１２．変更追跡および削除標識（Ｔｏｍｂｓｔｏｎｅ）
変更追跡サービスおよび削除標識サービスが、以下により完全に説明するとおり、データストアによって提供される。このセクションは、データストア内で開示される変更追跡情報の概略を提供する。

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

データストア内の各要素に関して、変更追跡情報は、２つの場所、すなわち、「マスタ」要素ビューおよび「タイプ付き」要素ビューから入手可能である。例えば、ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ．Ｄｏｃｕｍｅｎｔ項目タイプに関する変更追跡情報は、「［Ｓｙｓｔｅｍ］．［Ｓｔｏｒａｇｅ］．［マスタ！項目］」というマスタ項目ビュー、および［ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ］．［ドキュメント］というタイプ付き項目探索ビューから入手可能である。

（１）「マスタ」探索ビュー内の変更追跡
マスタ探索ビュー内の変更追跡情報は、要素の作成バージョンおよび更新バージョンに関する情報、いずれの同期パートナが要素を作成したか、いずれの同期パートナが、作成および更新のために各パートナからの要素およびバージョン番号を最後に更新したかに関する情報を提供する。同期関係（以下に説明する）におけるパートナは、パートナキーで識別される。［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓｔｏｒｅ］．ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏというタイプの＿ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏと名付けられた単一のＵＤＴが、以上の情報すべてを含む。タイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅスキーマの中で定義される。＿ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏが、項目、拡張、および関係に関するすべてのグローバル探索ビューの中で入手可能である。ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏのタイプ定義は、以下のとおりである。すなわち、

これらのプロパティは、以下の情報を含む。すなわち、

（２）「タイプ付き」探索ビュー内の変更追跡
グローバル探索ビューと同一の情報を提供することに加え、各タイプ付き探索ビューは、同期トポロジにおける各要素の同期状態を記録する追加の情報を提供する。

ｂ）削除標識
データストアは、項目、拡張、および関係に関する削除標識情報を提供する。削除標識ビューは、１つの場所でライブ（ｌｉｖｅ）エンティティと削除標識付き（ｔｏｍｂｓｔｏｎｅｄ）エンティティ（項目、拡張、および関係）の両方に関する情報を提供する。項目削除標識ビューおよび拡張削除標識ビューは、対応するオブジェクトへのアクセスを提供せず、他方、関係削除標識ビューは、関係オブジェクトへのアクセスを提供する（関係オブジェクトは、削除標識付き関係のケースではＮＵＬＬである）。

（１）項目削除標識
項目削除標識は、［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［削除標識！項目］というビューを介してシステムから取り出される。

（２）拡張削除標識
拡張削除標識は、［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［削除標識！拡張］というビューを使用してシステムから取り出される。拡張変更追跡情報は、項目に関して提供されるものに類似し、ＥｘｔｅｎｓｉｏｎＩｄプロパティが追加されている。

（３）関係削除標識
関係削除標識は、［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［削除標識！関係］というビューを介してシステムから取り出される。関係削除標識情報は、拡張に関して提供されるものに類似する。ただし、関係インスタンスのＩｔｅｍＲｅｆという目標上で追加の情報が提供される。さらに、関係オブジェクトも選択される。

（４）削除標識クリーンアップ
削除標識情報の限りない成長を防止するため、データストアは、削除標識クリーンアップタスクを提供する。このタスクは、いつ削除標識情報が破棄されるかを決める。タスクは、ローカル作成／更新バージョンの限界を計算し、すべてのより早期の削除標識バージョンを破棄することにより、削除標識情報を切り捨てる。

（１３）ヘルパＡＰＩおよび関数
基礎マッピングは、いくつかのヘルパ関数も提供する。それらの関数は、データモデルに対する共通の操作を支援するように供給される。

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

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

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

１４．メタデータ
ストア内で表される次の２つのタイプのメタデータが存在する。すなわち、インスタンスメタデータ（項目のタイプなど）、およびタイプメタデータである。

ａ）スキーマメタデータ
スキーマメタデータは、メタスキーマからの項目タイプのインスタンスとしてデータストアの中に格納される。

ｂ）インスタンスメタデータ
インスタンスメタデータは、アプリケーションによって、項目のタイプに関してクエリを行うのに使用され、項目に関連する拡張を探し出す。項目のＩｔｅｍＩｄを所与として、アプリケーションは、項目のタイプを戻すクエリをグローバル項目ビューに行い、その値を使用して、項目の宣言されたタイプに関する情報を戻すクエリをＭｅｔａ．Ｔｙｐｅに行うことができる。例えば、

Ｅ．セキュリティ
一般に、すべてのセキュリティで保護することが可能な（ｓｅｃｕｒａｂｌｅ）オブジェクトは、図２６に示したアクセスマスク形式を使用してオブジェクトのアクセス権を取り決める（ａｒｒａｎｇｅ）。この形式では、下位の１６ビットが、オブジェクト固有のアクセス権に関し、次の７ビットが、ほとんどのタイプのオブジェクトに適用される標準のアクセス権に関し、４つの上位ビットは、各オブジェクトタイプが、標準の権利、およびオブジェクト固有の権利のセットにマップすることができる汎用のアクセス権を指定する。ＡＣＣＥＳＳ＿ＳＹＳＴＥＭ＿ＳＥＣＵＲＩＴＹビットが、オブジェクトのＳＡＣＬにアクセスする権利に対応する。

図２６のアクセスマスク構造では、項目固有の権利は、オブジェクト固有権利セクション（下位の１６ビット）に入れられる。この実施形態では、ストレージプラットフォームは、セキュリティを管理する２つのＡＰＩセット、すなわち、Ｗｉｎ３２およびストレージプラットフォームＡＰＩを公開するので、ストレージプラットフォームオブジェクト固有の権利の設計を動機付けるため、システムオブジェクト固有の権利を考慮しなければならない。

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

Ｆ．通知および変更追跡
本発明の別の態様によれば、ストレージプラットフォームは、アプリケーションがデータ変更を追跡することを可能にする通知機能を提供する。この機能は、データ変更イベント時に、揮発性の状態を保持する、またはビジネス論理を実行するアプリケーションに主に向けられている。アプリケーションは、項目、拡張、および項目関係に関する通知のために登録する。通知は、データ変更がコミットされた後、非同期で配信される。アプリケーションは、項目、拡張、および関係タイプ、ならびに操作のタイプに従って通知をフィルタリングすることができる。

一実施形態によれば、ストレージプラットフォームＡＰＩ３２２は、通知に関して２種類のインターフェースを提供する。第１に、アプリケーションは、項目、項目拡張、および項目関係に対する変更によってトリガされる単純なデータ変更イベントに関して登録する。第２に、アプリケーションは、項目、項目拡張、および項目間の関係のセットを関しする「ウォッチャ（ｗａｔｃｈｅｒ）」オブジェクトを作成する。ウォッチャオブジェクトの状態は、システム障害の後、またはシステムが、長期間にわたってオフラインになった後、保存される、または再現されることが可能である。単一の通知が、複数の更新を反映することが可能である。

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

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

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

Ｈ．ストレージプラットフォームＡＰＩ
ストレージプラットフォームは、アプリケーションプログラム群が、前述したストレージプラットフォームのメカニズムおよび機能にアクセスすること、およびデータストアの中に格納された項目にアクセスすることができるようにするＡＰＩを含む。このセクションは、本発明のストレージプラットフォームのストレージプラットフォームＡＰＩの一実施形態を説明する。この機能に関する詳細は、本明細書で上記に参照により組み込まれた関連出願において見ることができ、その情報の一部を便宜のために以下に要約する。

図１８を参照すると、含有フォルダは、他の項目に対する保持関係を含む項目であり、ファイルシステムフォルダの一般的な概念の均等物である。各項目は、少なくとも１つの含有フォルダ内に「含有」される。

図１９は、本発明の実施形態によるストレージプラットフォームＡＰＩの基本的なアーキテクチャを示す。ストレージプラットフォームＡＰＩは、ＳＱＬＣｌｉｅｎｔ１９００を使用してローカルデータストア３０２と通信し（ｔａｌｋｔｏ）、ＳＱＬＣｌｉｅｎｔ１９００を使用してリモートデータストア（例えば、データストア３４０）と対話することもできる。また、ローカルストア３０２は、ＤＱＰ（分散クエリプロセッサ）を使用して、または以下に説明するストレージプラットフォーム同期サービス（「同期」）を介して、リモートデータストア３４０と対話することもできる。また、ストレージプラットフォームＡＰＩ３２２は、データストア通知のためのブリッジＡＰＩとしても作用し、前述したとおり、アプリケーションのサブスクリプションを通知エンジン３３２に送り、通知をアプリケーション（例えば、アプリケーション３５０ａ、３５０ｂ、または３５０ｃ）にルーティングする。一実施形態では、ストレージプラットフォームＡＰＩ３２２は、ＭｉｃｒｏｓｏｆｔＥｘｈａｎｇｅおよびＡＤの中のデータにアクセスすることができるように、限られた「プロバイダ」アーキテクチャを定義することもできる。

図２０は、ストレージプラットフォームＡＰＩの様々なコンポーネントを概略で示す。ストレージプラットフォームＡＰＩは、以下のコンポーネントから成る。すなわち、（１）ストレージプラットフォームの要素タイプおよび項目タイプを表すデータクラス２００２、オブジェクト永続性を管理し、サポートクラス２００６を提供するランタイムフレームワーク２００４、およびストレージプラットフォームスキーマからＣＬＲクラスを生成するのに使用されるツール群２００８である。

所与のスキーマからもたらされるクラスの階層は、そのスキーマ内のタイプの階層を直接に反映する。例として、図２１Ａおよび図２１Ｂの中に示される連絡先スキーマの中で定義された項目タイプを考慮されたい。

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

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

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

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

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

概念上、プログラミングインターフェースは、図３０Ａまたは図３０Ｂに示すとおり、一般的に考えることができる。図３０Ａは、第１のコアセグメントと第２のコアセグメントが通信するコンジット（ｃｏｎｄｕｉｔ）としてインターフェース、Ｉｎｔｅｒｆａｃｅ１を示す。図３０Ｂは、インターフェースが、インターフェースオブジェクトＩ１およびＩ２（第１のコードセグメントおよび第２のコードセグメントの一部であることも、そうでないことも可能な）を含むのを示し、オブジェクトＩ１およびＩ２は、システムの第１のコードセグメントと第２のコードセグメントが、媒体Ｍを介して通信することを可能にする。図３０Ｂに鑑みて、インターフェースオブジェクトＩ１およびＩ２を同一のシステムの別々のインターフェースと見なすことができ、また、オブジェクトＩ１およびＩ２に媒体Ｍを加えたものが、インターフェースを構成すると見なすこともできる。図３０Ａおよび図３０Ｂは、双方向の流れを示し、流れのそれぞれの側でインターフェースを示しているが、一部の実施形態は、１方向でだけ情報の流れを有すること（または、以下に説明するとおり、まったく情報の流れを有さないこと）、または一方の側でだけインターフェースオブジェクトを有することも可能である。例として、限定としてではなく、ＡＰＩ（アプリケーションプログラミングインターフェース）、エントリポイント、メソッド、関数、サブルーチン、リモートプロシージャコール、およびＣＯＭ（コンポーネントオブジェクトモデル）インターフェースなどの用語は、プログラミングインターフェースの定義の範囲内に包含される。

そのようなプログラミングインターフェースの諸態様は、第１のコードセグメントが第２のコードセグメントに情報（ここで、「情報」は、最も広い意味で使用され、データ、コマンド、要求などが含まれる）を伝送するメソッド、第２のコードセグメントが情報を受け取るメソッド、ならびに情報の構造、シーケンス、構文、編成、スキーマ、タイミング、および内容を含むことが可能である。これに関して、基礎にあるトランスポート媒体自体は、情報が、インターフェースによって定義された形でトランスポートされる限り、媒体が有線であるか、無線であるか、あるいはその両方の組合せであるかにかかわらず、インターフェースの動作に重要ではない可能性がある。一部の状況では、情報は、慣例的な意味で１方向、または両方向で送られない可能性がある。というのは、情報転送は、別のメカニズム（例えば、バッファ、ファイルなどに入れられた情報が、コードセグメント間の情報フローとは別個である場合）を介すること、あるいは１つのコードセグメントが、第２のコードセグメントによって実行される機能に単にアクセスする場合のように、存在しないことも可能である。これらの態様のいずれか、またはすべてが、例えば、コードセグメントが疎結合の構成のシステムの一部であるか、緊密結合の構成のシステムの一部であるかに依存して、所与の状況において重要である可能性があり、したがって、以上のリストは、例示的であり、限定的ではないと考えられなければならない。

プログラミングインターフェースの以上の概念は、当業者には周知であり、本発明の以上の詳細な説明から明白である。しかし、プログラミングインターフェースを実施する他のやり方も存在し、明確に排除されない限り、それらのやり方も、本明細書の終りに記載する特許請求の範囲によって包含されるものとする。そのような他のやり方は、図３０Ａおよび図３０Ｂの過度に単純化された図より高度である、またはより複雑であるように見える可能性があるが、それでも、それらのやり方は、類似した機能を実行して、同一の全体的な結果を実現する。次に、プログラミングインターフェースの一部の例示的な代替の実施形態を簡単に説明する。

ファクタリング（Ｆａｃｔｏｒｉｎｇ）：１つのコードセグメントから別のコードセグメントへの通信は、通信を複数の別々の通信に分解することによって間接的に達することもできる。これを図３１Ａおよび図３１Ｂに概略で示す。図示するとおり、一部のインターフェースは、分割可能な機能セットとして説明することができる。このため、図３０Ａおよび図３０Ｂのインターフェース機能をファクタリングして、２４、または２掛ける２掛ける３掛ける２を数学的にもたらすことができるのと同様に、同一の結果を実現することができる。したがって、図３１Ａに示すとおり、インターフェース、Ｉｎｔｅｒｆａｃｅ１によって提供される関数を細分して、同一の結果を実現しながら、このインターフェースの通信を複数のインターフェース、Ｉｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃなどに変換することができる。同様に、第１のコードセグメントから情報を受け取る第２のコードセグメントのインターフェースＩ２も、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどにファクタリングすることができる。ファクタリングを行う際、第１のコードセグメントに含められるインターフェースの数は、第２のコードセグメントに含められるインターフェースの数と一致する必要はない。図３１Ａおよび図３１Ｂのいずれにおいても、インターフェース、Ｉｎｔｅｒｆａｃｅ１とＩ１の機能上の趣旨はそれぞれ、図３０Ａおよび図３０Ｂの場合と変わらない。インターフェースのファクタリングは、結合特性、交換特性、およびその他の数学的特性にも従うことが可能であり、したがって、ファクタリングは、認識するのが困難である可能性がある。例えば、演算の順序が重要でない可能性があり、したがって、インターフェースによって実行される関数は、インターフェースに達するかなり前に、別のコードまたはインターフェースによって実行されること、またはシステムの別個のコンポーネントによって実行されることが可能である。さらに、プログラミング分野の業者は、同一の結果を実現する、異なる関数呼び出しを作成する様々なやり方が存在することを認めることができよう。

再定義：一部のケースでは、目的の結果を実現しながらも、プログラミングインターフェースの一部の態様（例えば、パラメータ）を無視する、追加する、または再定義することができる可能性がある。これを図３２Ａおよび図３２Ｂに示す。例えば、図３０Ａのインターフェース、Ｉｎｔｅｒｆａｃｅ１が、入力、精度、および出力という３つのパラメータを含み、第１のコードセグメントから第２のコードセグメントに発行される呼び出しである、Ｓｑｕａｒｅ（入力，精度，出力）という関数呼び出しを含むものと想定されたい。中間のパラメータ、精度は、図３２Ａに示すとおり、所与のシナリオにおいて関係ない場合、無視されても構わない可能性があり、あるいは、無意味な（この状況では）パラメータで置き換えられることさえ可能である。また、関係のない追加のパラメータを加えることもできる。いずれにしても、入力が、第２のコードセグメントによって２乗にされた後、出力が戻される限り、２乗（ｓｑｕａｒｅ）の機能が達せられることが可能である。精度は、コンピューティングシステムのいくらか下流の部分に、または他の部分に有意義なパラメータである可能性があるが、２乗を計算するという狭い目的で精度が必要ないと認識されると、精度は、置き換えられる、または無視されることが可能である。例えば、結果に悪影響を与えることなしに、有効な精度値を送る代わりに、誕生日などの無意味な値を送ることもできる。同様に、図３２Ｂに示すとおり、インターフェースＩ１が、インターフェースに対するパラメータを無視する、または追加するように再定義されたインターフェースＩ１’で置き換えられる。インターフェースＩ２も同様に、不必要なパラメータ、または別の場所で処理される可能性があるパラメータを無視するように再定義されたインターフェースＩ２’として再定義されることが可能である。ここでの要点は、一部のケースにおいて、プログラミングインターフェースは、何らかの目的で必要とされない、パラメータなどの態様を含む可能性があることであり、したがって、そのような態様は、無視される、または再定義される、あるいは他の目的で別の場所で処理されることが可能である。

インライン（Ｉｎｌｉｎｅ）コーディング：２つの別々のコードモジュールの機能の一部、またはすべてをマージして、それらのモジュール間の「インターフェース」が形態を変えるようにすることも実行可能である。例えば、図３０Ａおよび図３０Ｂの機能をそれぞれ、図３３Ａおよび図３３Ｂの機能に変換することができる。図３３Ａでは、図３０Ａの以前の第１のコードセグメントと第２のコードセグメントがマージされて、その両方を含むモジュールになる。この場合、それらのコードセグメントは、依然として互いに通信していることが可能であるが、インターフェースは、単一のモジュールにより適した形態に適合されていることが可能である。このため、例えば、正式のＣａｌｌステートメントおよびＲｅｔｕｒｎステートメントはもはや必要ない可能性があるが、インターフェース、Ｉｎｔｅｒｆａｃｅ１に準拠した類似の処理または応答が、依然として実施されていることが可能である。同様に、図３３Ｂに示すとおり、図３０ＢからのインターフェースＩ２の一部（またはすべて）が、インターフェースＩ１にインラインで書き込まれて、インターフェースＩ１”を形成することも可能である。図示するとおり、インターフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａは、インターフェースＩ１とインラインでコーディングされて、インターフェースＩ１”を形成している。具体例として、図３０ＢからのインターフェースＩ１が、関数呼び出し、２乗（入力，出力）を実行することを考慮されたい。２乗（入力，出力）は、インターフェースＩ２によって受け取られ、インターフェースＩ２は、第２のコードセグメントによって、入力とともに送られた値を処理した（その値を２乗した）後、２乗にされた結果を出力とともに送り返す。そのようなケースで、第２のコードセグメントによって実行される処理（入力を２乗にすること）は、インターフェースに対する呼び出しなしに、第１のコードセグメントによって実行されることが可能である。

離縁（Ｄｉｖｏｒｃｅ）：１つのコードセグメントから別のコードセグメントへの通信は、通信を複数の別々な通信に分解することによって間接的に達せられることが可能である。これを図３４Ａおよび図３４Ｂに概略で示す。図３４Ａに示すとおり、１つまたは複数のミドルウェア（機能および／またはインターフェース機能を元のインターフェースから離縁するため、離縁インターフェース）が提供されて、第１のインターフェース、Ｉｎｔｅｒｆａｃｅ１上の通信を変換して、異なるインターフェースに、このケースでは、Ｉｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃというインターフェース群に適合させる。これは、例えば、例えば、インターフェースプロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーション群のインストール済みの基礎が存在するが、そのオペレーティングシステムが、異なるインターフェースを使用するように、このケースでは、Ｉｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃというインターフェース群を使用するように変更された場合、行われることが可能である。要点は、第２のコードセグメントによって使用される元のインターフェースが変更され、したがって、そのインターフェースが、第１のコードセグメントによって使用されるインターフェースともはや相容れず、したがって、古いインターフェースと新しいインターフェースが適合するようにするために仲介が使用されることである。同様に、図３４Ｂに示すとおり、インターフェースＩ１から通信を受け取る離縁インターフェースＤＩ１と、ＤＩ２に対して機能するように再設計されているが、同一の機能上の結果をもたらす、例えば、インターフェースＩ２ａおよびＩ２ｂに、インターフェース機能を送る離縁インターフェースＤＩ２とを有する第３のコードセグメントが導入されることが可能である。同様に、ＤＩ１とＤＩ２は、同一の、または同様の機能上の結果をもたらしながら、協働して、図３０ＢのインターフェースＩ１およびＩ２の機能を新たなオペレーティングシステムに対して翻訳することが可能である。

書き換え：さらに別の可能な変種は、コードを動的に書き換えて、何か別の、ただし、同一の全体的な結果を実現する物で、インターフェース機能を置き換えることである。例えば、中間言語（例えば、ＭｉｃｒｏｓｏｆｔＩＬ、Ｊａｖａ（登録商標）ＢｙｔｅＣｏｄｅなど）で与えられたコードセグメントが、実行環境（．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の類似したランタイムタイプの環境によって提供されるような）におけるＪＩＴ（ジャストインタイム（Ｊｕｓｔ−ｉｎ−Ｔｉｍｅ））コンパイラまたはインタプリタに与えられるシステムが、存在することが可能である。ＪＩＴコンパイラは、第１のコードセグメントから第２のコードセグメントへの通信を動的に変換するように、すなわち、第２のコードセグメント（元の第２のコードセグメント、または異なる第２のコードセグメント）が要する可能性がある異なるインターフェースに通信を適合させるように書かれることが可能である。これを図３５Ａおよび図３５Ｂに示す。図３５Ａで見ることができるとおり、このアプローチは、前述した離縁シナリオに類似する。このアプローチは、例えば、アプリケーション群のインストール済みの基礎が、インターフェース１プロトコルに従ってオペレーティングシステムと通信するように設計されているが、そのオペレーティングシステムが、異なるインターフェースを使用するように変更された場合に行われる可能性がある。ＪＩＴコンパイラを使用して、インストール済み基礎アプリケーションからの通信をオンザフライ（ｏｎｔｈｅｆｌｙ）で、オペレーティングシステムの新たなインターフェースに適合させることができる。図３５Ｂに示すとおり、インターフェースを動的に書き換えるこのアプローチは、インターフェースを動的にファクタリングする（ｆａｃｔｏｒ）する、または別の形で変更するように適用することもできる。

また、代替の諸実施形態を介してインターフェースと同一の、または類似の結果を実現するための前述したシナリオは、様々な形で、逐次に（ｓｅｒｉａｌｌｙ）かつ／または並行に（ｉｎｐａｒａｌｌｅｌ）、あるいは他の介在するコードと一緒に、組み合わせることができることにも留意されたい。このため、以上に提示した代替の諸実施形態は、相互排他的ではなく、混成され、合わせられ、組み合わされて、図３０Ａおよび図３０Ｂに提示した一般的なシナリオと同一の、または均等のシナリオをもたらすことも可能である。また、ほとんどのプログラミング構造（ｃｏｎｓｔｒｕｃｔ）の場合と同様に、本明細書で説明されない可能性があるが、それでも、本発明の趣旨および範囲によって表されるインターフェースと同一、または同様の機能を実現する、他のやり方が存在することにも留意されたい。つまり、インターフェースの価値の基礎にあるのは、少なくともある程度は、インターフェースによって代表される機能、およびインターフェースが可能にする有利な結果であることに留意されたい。

ＩＩＩ．同期ＡＰＩ
同期のいくつかのアプローチが、項目ベースのハードウェア／ソフトウェアインターフェースシステムにおいて可能である。

Ａ．同期の概略
本発明のいくつかの実施形態に関し、図３に関連して、ストレージプラットフォームは、（ｉ）ストレージプラットフォームの複数のインスタンス（それぞれが独自のデータストア３０２を有する）が、柔軟な規則セットに従って自らの内容の諸部分を同期させることを可能にし、（ｉｉ）サードパーティが、本発明のストレージプラットフォームのデータストアを、独自のプロトコルを実施する他のデータソースと同期させるインフラストラクチャを提供する、同期サービス３３０を提供する。

ストレージプラットフォーム対ストレージプラットフォームの同期は、グループの参加する「レプリカ（ｒｅｐｌｉｃａ）」間で行われる。例えば、図３を参照すると、ストレージプラットフォーム３００のデータストア３０２と、おそらく、異なるコンピュータシステム上で実行されているストレージプラットフォームの別のインスタンスの制御下にある、別のリモートデータストア２２８の間で、同期を提供することが望ましい可能性がある。このグループの全体的なメンバシップは、任意の所与の時点において、任意の所与のレプリカに必ずしも知られていない。

異なるレプリカが、変更を独立に（すなわち、同時に）行う可能性がある。同期のプロセスは、すべてのレプリカに、他のレプリカによって行われた変更を認識させることとして定義される。同期機能は、本来的にマルチマスタ（ｍｕｌｔｉ−ｍａｓｔｅｒ）（つまり、ピアツーピア）である。

本発明の同期機能は、レプリカが、以下を行うことを可能にする。すなわち、
・別のレプリカがいずれの変更を認識しているかを判定する
・そのレプリカが認識している変更についての情報を要求する
・その他のレプリカが認識していない変更についての情報を伝える
・２つの変更が互いに競合している場合を判定する
・変更をローカルで適用する
・他のレプリカに競合解決を伝えて、収束を確実にする
・競合解決のための指定されたポリシーに基づいて競合を解決する。

１．ストレージプラットフォーム対ストレージプラットフォームの同期
本発明のストレージプラットフォームの同期サービス３３０の主要な用途は、ストレージプラットフォームの複数のインスタンス（それぞれが独自のデータストアを有する）を同期させることである。同期サービスは、ストレージプラットフォームスキーマ（データベースエンジン３１４の基礎にあるテーブルではなく）のレベルで機能する。このため、例えば、以下に説明するとおり、「範囲」を使用して同期セットを定義する。

同期サービスは、「正味の（ｎｅｔ）変更」の原理で機能する。個々の操作を記録し、送る（トランザクションのレプリケーション（ｔｒａｎｓａｃｔｉｏｎａｌｒｅｐｌｉｃａｔｉｏｎ）などを使用して）のではなく、同期サービスは、それらの操作の最終結果を送り、このため、しばしば、複数の操作の結果をまとめて、単一の結果としての変更にする。

同期サービスは、一般に、トランザクション境界を守らない。つまり、２つの変更が、単一のトランザクションの中でストレージプラットフォームデータストアに対して行われた場合、それらの変更が、他のすべてのレプリカにアトムとして（ａｔｏｍｉｃａｌｌｙ）適用されるという保証は、まったく存在しない。つまり、１つの変更が、他方の変更を伴わずに現れる可能性がある。この原理に対する例外は、２つの変更が、同一のトランザクションの中で同一の項目に対して行われた場合は、それらの変更が、他のレプリカにアトムとして送られ、適用されることが保証されることである。このため、項目は、同期サービスの整合性単位である。

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

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

同期を可能にするため、２つのステップが行われる必要がある。第１に、スキーマ設計者が、適切な同期セマンティクス（以下に説明するとおり、変更単位を指定する）でストレージプラットフォームスキーマに注釈を付けなければならない。第２に、同期が、同期に参加すべきストレージプラットフォームのインスタンスを有するマシン群のすべてのマシン上で適切に構成されなければならない（以下に説明する）。

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

スキーマの中で変更単位を指定することは、いくつかの目的を果たす。第１に、スキーマの中で変更単位を指定することにより、線（ｗｉｒｅ）上でどれだけ同期サービスが「おしゃべり」（ｃｈａｔｔｙ）であるかが決まる。変更単位の内部で変更が行われた場合、その変更単位全体が、その他のレプリカに送られる。というのは、同期サービスには、変更単位のいずれの部分が変更されているかが分からないからである。第２に、スキーマの中で変更単位を指定することにより、競合検出の粒状度が決まる。２つの同時の変更（これらの用語は、以下のセクションで詳細に定義する）が同一の変更単位に対して行われた場合、同期サービスは、競合を生じさせる。他方、同時の変更が異なる変更単位に対して行われた場合、競合は生じず、変更は自動的にマージされる。第３に、スキーマの中で変更単位を指定することにより、システムによって保持されるメタデータの量が大きく影響を受ける。同期サービスメタデータの多くは、変更単位ごとに保持され、このため、変更単位をより小さくすることは、同期のオーバーヘッドを増加させる。

変更単位を定義することは、正しいトレードオフを見出すことを要する。この理由で、同期サービスは、スキーマ設計者がそのプロセスに参加することを許す。

一実施形態では、同期サービスは、要素より大きい変更単位をサポートしない。しかし、同期サービスは、スキーマ設計者が、要素より小さい変更単位を指定する能力、すなわち、要素の複数の属性をグループ化して別個の変更単位にすることをサポートする。その実施形態では、これは、以下の構文を使用して達せられる。すなわち、

ｃ）同期構成
自らのデータのある部分を同期させておくことを所望するストレージプラットフォームパートナのグループは、同期コミュニティと呼ばれる。コミュニティのメンバは、同期されたままであることを所望するが、必ずしもデータを完全に同一の形で表現することはしない。つまり、同期パートナは、同期させているデータを変換する（ｔｒａｎｓｆｏｒｍ）可能性がある。

ピアツーピアシナリオでは、ピアが、ピアのパートナのすべてに関する変換（ｔｒａｎｓｆｏｒｍａｔｏｎ）マッピングを保持することは現実的ではない。代わりに、同期サービスは、「コミュニティフォルダ」を定義するアプローチをとる。コミュニティフォルダは、すべてのコミュニティメンバが同期する仮定的な（ｈｙｐｏｔｈｅｔｉｃａｌ）「共有フォルダ」を表す抽象化である。

この概念は、実施例によってよく示される。Ｊｏｅが、ＪｏｅのいくつかのコンピュータのＭｙＤｏｃｕｍｅｎｔｓフォルダを同期させていることを所望する場合、Ｊｏｅは、例えば、ＪｏｅｓＤｏｃｕｍｅｎｔｓと呼ばれるコミュニティフォルダを定義する。次に、すべてのコンピュータ上で、Ｊｏｅは、仮定的なＪｏｅｓＤｏｃｕｍｅｎｔｓフォルダとローカルのＭｙＤｏｃｕｍｅｎｔｓフォルダの間のマッピングを構成する。その時点以降、Ｊｏｅのコンピュータが互いに同期する場合、コンピュータは、コンピュータのローカル項目についてではなく、ＪｏｅｓＤｏｃｕｍｅｎｔｓ内のドキュメントについて通信する（ｔａｌｋ）。このようにして、すべてのＪｏｅのコンピュータは、相手が誰であるかを知る必要なしに、互いを理解する。つまり、コミュニティフォルダが、同期コミュニティの共通語（ｌｉｎｇｕａｆｒａｎｃａ）となる。

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

（１）コミュニティフォルダ−マッピング
通信フォルダマッピングは、ＸＭＬ構成ファイルとして個々のマシン上に格納される。各マッピングは、以下のスキーマを有する。すなわち、
/mappings/communityFolder
この要素は、そのマッピングが関わるコミュニティフォルダを名付ける。名前は、フォルダの構文規則に従う。

/mappings/localFolder
この要素は、マッピングが変換する先のローカルフォルダを名付ける。フォルダは、マッピングが有効であるには、既に存在していなければならない。このフォルダ内の項目は、このマッピングに従って同期されるように考慮される。

/mappings/transformations
この要素は、どのように項目をコミュニティフォルダからローカルフォルダに変換し、またローカルフォルダからコミュニティフォルダに変換して戻すかを定義する。詳細には、これは、ＩＤがまったくマッピングされないことを意味する。この構成は、主にフォルダのキャッシュを作成するのに役立つ。

/mappings/transformations/mapIDs
この要素は、コミュニティＩＤを再使用するのではなく、新たに生成されたローカルＩＤが、コミュニティフォルダからマップされた項目のすべてに割り当てられることを要求する。同期ランタイムが、項目を変換したり、戻したりする（ｃｏｎｖｅｒｔｂａｃｋａｎｄｆｏｒｔｈ）ＩＤマッピングを保持する。

/mappings/transformations/localRoot
この要素は、コミュニティフォルダ内のすべてのルート項目が、指定されたルートの子にされることを要求する。

/mappings/runAs
この要素は、誰の権限の元でこのマッピングに対する要求が処理されるかを支配する。存在しない場合、送信者と見なされる。

/mappings/runAs/sender
この要素の存在は、このマッピングへのメッセージの送信者が偽装（ｉｍｐｅｒｓｏｎａｔｅ）され、要求が、送信者の資格情報の下で処理されなければならないことを示す。

（２）プロファイル
同期プロファイルは、同期を開始するのに必要とされるパラメータの全セットである。同期プロファイルは、ＳＣＡによって同期ランタイムに供給されて、同期が開始される。ストレージプラットフォーム−ストレージプラットフォーム同期に関する同期プロファイルは、以下の情報を含む。すなわち、
・ローカルフォルダ、変更の送信元および宛先の役割をする
・同期する相手のリモートフォルダ名−このフォルダは、上記に定義したマッピングを使用してリモートパートナによって公開されなければならない
・方向−同期サービスは、送信専用同期、受信専用同期、および送受信同期をサポートする
・ローカルフィルタ−リモートパートナのどのようなローカル情報を送信すべきかを選択する
・リモートフィルタ−リモートパートナからどのようなリモート情報を取り出すべきかを選択する−コミュニティフォルダを対象とするストレージプラットフォームクエリとして表現される
・変換−ローカル形式へ、およびローカル形式からどのように項目を変換するかを定義する
・ローカルセキュリティ−リモートエンドポイントから取り出された変更が、ローカルエンドポイント（偽装された）の許可の下で適用されるべきか、または、ユーザが同期をローカルで開始するかを指定する
・競合解決ポリシー−競合が、拒否されるべきか、ログ記録されるべきか、または自動的に解決されるべきかを指定する−自動的に解決されるべき場合、競合解決ポリシーは、いずれの競合リゾルバ（ｒｅｓｏｌｖｅｒ）が使用されるべきか、ならびにリゾルバのための構成パラメータを指定する。

同期サービスは、同期プロファイルの単純な構築を可能にするランタイムＣＬＲクラスを提供する。プロファイルは、容易な格納のために（しばしば、スケジュールとともに）ＸＭＬファイルにシリアル化され、またＸＭＬファイルからシリアル化されることも可能である。ただし、すべてのプロファイルが格納されるストレージプラットフォーム内の標準の場所は存在せず、ＳＣＡが、プロファイルをまったく永続させることなしに、その場でプロファイルを作成することが歓迎される。同期を開始するのにローカルマッピングを有する必要はまったくないことに留意されたい。すべての同期情報が、プロファイルの中で指定されることが可能である。ただし、マッピングは、リモート側によって開始された同期要求に応答するために必須である。

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

ｄ）競合処理
同期サービスにおける競合処理は、次の３つの段階に分けられる。すなわち、（１）変更適用時に行われる競合検出−このステップは、変更を安全に適用することができるかどうかを判定する、（２）自動競合解決およびログ記録−このステップ（競合が検出された直後に行われる）中、自動競合リゾルバ（または「競合ハンドラ」）に問い合わせが行われて、競合を解決することができるかどうかが確かめられる−解決することができない場合、競合は、オプションとしてログ記録されることが可能である、および（３）競合検査および競合解決−このステップは、いくつかの競合がログ記録されている場合に行われ、同期セッションのコンテキスト外で行われる−その時点で、ログ記録された競合が解決され、ログから削除されることが可能である。競合処理を対象とする本発明の様々な実施形態は、セクションＩＩＩで以下にはるかに詳細に説明する。

２．非ストレージプラットフォームのデータストアに同期すること
本発明のストレージプラットフォームの別の態様によれば、セクションＩＶで以下に説明する本発明の様々な実施形態により密接に関連して、ストレージプラットフォームは、ストレージプラットフォームが、ＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅ、ＡＤ、Ｈｏｔｍａｉｌなどのレガシシステムに同期することを可能にする同期アダプタを実装するＩＳＶのためのアーキテクチャを提供する。同期アダプタは、以下に説明するとおり、同期サービスによって提供される多くの同期サービスの恩恵を受ける。

その名前にもかかわらず、同期アダプタは、何らかのストレージプラットフォームアーキテクチャへのプラグインとして実装される必要がない。所望される場合、「同期アダプタ」は、単に、同期サービスランタイムインターフェース群を利用して、変更列挙や変更適用などのサービスを獲得する任意のアプリケーションであることが可能である。

他者が、所与のバックエンドに対する同期を構成し、実行するのをより簡単にするため、同期アダプタライタ（ｗｒｉｔｅｒ）は、前述した同期プロファイルが与えられて同期を実行する標準の同期アダプタインターフェースを公開するように奨励される。プロファイルは、アダプタに構成情報を提供し、その情報の一部をアダプタは、同期ランタイムに送ってランタイムサービス（例えば、同期されるべきフォルダ）を制御させる。

ａ）同期サービス
同期サービスは、いくつかのサービスをアダプタライタに提供する。このセクションの残りの部分に関して、ストレージプラットフォームが同期を行っているマシンを「クライアント」と呼び、アダプタが通信している（ｔａｌｋｉｎｇｔｏ）非ストレージプラットフォームバックエンドを「サーバ」と呼ぶことが好都合である。

（１）変更列挙
同期サービスによって保持される変更追跡データに基づき、変更列挙は、そのパートナとの前回の同期が試みられて以来、データストアフォルダに対して行われた変更を同期アダプタが容易に列挙することを可能にする。

変更は、最後の同期についての情報を表す不透明な構造である「アンカ」の概念に基づいて列挙される。アンカは、続く（ｐｒｏｃｅｅｄｉｎｇ）セクションで説明する、知識というストレージプラットフォームの形態をとる。変更列挙サービスを利用する同期アダプタは、次の２つの広いカテゴリに入る。すなわち、「格納されたアンカ」を使用する同期アダプタ対「供給されたアンカ」を使用する同期アダプタである。

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

ストレージプラットフォームがアンカを保持する（ローカルストレージのため、またはリモートストレージのために）には、ストレージプラットフォームは、サーバにおいて適用されることに成功した変更を認識していなければならない。それらの変更だけに限り、アンカに含められることが可能である。変更列挙中、同期アダプタは、確認応答（Ａｃｋｏｗｌｅｄｇｅｍｅｎｔ）インターフェースを使用して、いずれの変更が適用されることに成功したかを報告する。同期の終りに、供給されたアンカを使用するアダプタは、新たなアンカ（適用されることに成功した変更のすべてを組み込んだ）を読み取り、そのアンカをアダプタのバックエンドに送信しなければならない。

しばしば、アダプタは、アダプタがストレージプラットフォームデータストアの中に挿入する項目とともに、アダプタ固有のデータも格納する必要がある。そのようなデータの一般的な例が、リモートＩＤおよびリモートバージョン（タイムスタンプ）である。同期サービスは、そのデータを格納するためのメカニズムを提供し、変更列挙は、その追加データを戻される変更とともに受け取るメカニズムを提供する。これにより、ほとんどのケースで、アダプタが、データベースに再クエリを行う必要性がなくなる。

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

変更適用の主要な機能は、競合を自動的に検出することである。ストレージプラットフォーム−ストレージプラットフォーム同期の場合と同様に、競合は、２つの重なり合う変更が、互いの知識なしに行われることと定義される。アダプタは、変更適用を使用する場合、アンカを指定しなければならず、指定されたアンカに関して、競合検出が実行される。変更適用は、アダプタの知識によってカバーされない、重なり合うローカルの変更が検出された場合に、競合を生じさせる。変更列挙と同様に、アダプタは、格納されたアンカ、または供給されたアンカを使用することができる。変更適用は、アダプタ固有のメタデータの効率的な格納をサポートする。そのようなデータは、アダプタによって、適用される変更に付加されることが可能であり、同期サービスによって格納されることが可能である。データは、次の変更列挙時に戻されることが可能である。

（３）競合解決
以下に説明する競合解決メカニズム（ログ記録オプションおよび自動解決オプションを含む）も、同期アダプタに利用可能である。同期アダプタは、変更を適用する際、競合解決のためのポリシーを指定することができる。指定された場合、競合は、指定された競合ハンドラに送られ、解決される（可能な場合）ことが可能である。競合は、ログ記録されることも可能である。アダプタが、ローカルの変更をバックエンドに適用しようと試みている際、競合を検出する可能性があることが可能である。そのようなケースでは、アダプタは、ポリシーによって解決されるように、やはり同期ランタイムに転送することができる。加えて、同期アダプタは、同期サービスによって検出されたあらゆる競合が、処理のために同期アダプタに送り返されることを要求することができる。これは、バックエンドが競合を格納する、または解決することができる場合、特に好都合である。

ｂ）アダプタ実施形態
一部の「アダプタ」は、単にランタイムインターフェースを利用するアプリケーションであるが、アダプタは、標準のアダプタインターフェースを実装するように奨励される。それらのインターフェースにより、同期制御アプリケーションは、アダプタが、所与の同期プロファイルに従って同期を実行するように要求すること、進行中の同期をキャンセルすること、および進行中の同期に関する進行状況レポート（完了パーセンテージ）を受け取ることができるようになる。

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

同期サービスは、セキュリティで保護された作成者（ａｕｔｈｏｒｓｈｉｐ）情報を保持しない。レプリカＡにおいてユーザＵによって変更が行われ、レプリカＢに転送された場合、その変更が最初、Ａにおいて（またはＵによって）行われたという事実が失われる。Ｂが、その変更をレプリカＣに転送する場合、これは、Ａの権限ではなく、Ｂの権限の下で行われる。これは、次の制限をもたらす。すなわち、あるレプリカが、項目に対して独自の変更を行うことが信頼されない場合、そのレプリカは、他のレプリカによって行われた変更を転送することができない。

同期サービスが開始される場合、この開始は、同期制御アプリケーションによって行われる。同期サービスは、ＳＣＡのＩＤを偽装し、そのＩＤの下ですべての操作を実行する（ローカルとリモートの両方で）。例示すると、ユーザＵは、ユーザＵが読み取りアクセスを有さない項目に関して、ローカル同期サービスにリモートストレージプラットフォームから変更を取り出すようにさせることができないことに注目されたい。

４．管理しやすさ（Ｍａｎａｇｅａｂｉｌｉｔｙ）
レプリカの分散コミュニティを監視することは、複雑な問題である。同期サービスは、「掃引（ｓｗｅｅｐ）」アルゴリズムを使用して、レプリカに関する情報を収集し、分配することができる。掃引アルゴリズムの特性は、すべての構成されたレプリカに関する情報が、最終的に収集されること、および障害が生じた（応答しない）レプリカが検出されることを確実にする。

このコミュニティ全体の監視情報は、すべてのレプリカにおいて提供される。監視ツールは、任意に選択されたレプリカにおいて実行されて、その監視情報を検査し、管理上の決定を行うことが可能である。あらゆる構成変更は、影響を受けるレプリカにおいて直接に行われなければならない。

Ｂ．同期ＡＰＩの概略
ますます分散するデジタル世界において、個人およびワークグループは、しばしば、情報およびデータを様々な異なるデバイスおよび場所に格納する。これにより、それらの別々の、しばしば、異種のデータストアの中の情報を最小限のユーザ介入で常時、同期させておくことができるデータ同期サービスの開発が活発化している。

本明細書のセクションＩＩで説明する豊かなプラットフォーム（別名、「ＷｉｎＦＳ」）の一部である、本発明の同期プラットフォームは、以下の３つの主な目的に取り組む。すなわち、
・アプリケーションおよびサービスが、異なる「ＷｉｎＦＳ」ストア間でデータを効率的に同期させることを可能にする
・開発者が、「ＷｉｎＦＳ」ストアと非「ＷｉｎＦＳ」ストアの間でデータを同期させるための豊かなソリューションを構築することができるようにする
・同期ユーザ体験をカスタマイズする適切なインターフェース群を開発者に提供する
１．一般的な用語

以下は、このセクションＩＩＩ．Ｂの後の説明に関係のある、いくつかのさらに改良された定義および重要な概念である。

同期レプリカ：ほとんどのアプリケーションは、ＷｉｎＦＳストア内の項目の所与のサブセットに関する変更を追跡すること、列挙すること、および同期させることだけにしか関心がない。同期操作に参加する項目のセットは、同期レプリカと呼ばれる。レプリカは、所与のＷｉｎＦＳ含有階層（通常、フォルダ項目にルートを有する）内に含まれる項目に関して定義される。すべての同期サービスは、所与のレプリカのコンテキスト内で実行される。ＷｉｎＦＳ同期は、レプリカを定義し、管理し、クリーンアップするメカニズムを提供する。すべてのレプリカは、所与のＷｉｎＦＳストア内部でそのレプリカを一意に識別するＧＵＩＤ識別子を有する。

同期パートナ：同期パートナは、ＷｉｎＦＳ項目、ＷｉｎＦＳ拡張、およびＷｉｎＦＳ関係の変更に影響を与えることができるエンティティとして定義される。このため、すべてのＷｉｎＦＳストアは、同期パートナと呼ぶことができる。非ＷｉｎＦＳストアと同期する場合、ＥＤＳ（外部データソース）も、同期パートナと呼ばれる。すべてのパートナは、そのパートナを一意に識別するＧＵＩＤ識別子を有する。

同期コミュニティ：同期コミュニティは、ピアツーピア同期操作を使用して同期しているように保たれるレプリカの集合として定義される。それらのレプリカはすべて、同一のＷｉｎＦＳストアの中にあること、異なるＷｉｎＦＳストアの中にあること、または非ＷｉｎＦＳストア上の仮想レプリカとして現れることさえ可能である。ＷｉｎＦＳ同期は、特に、コミュニティにおける同期操作だけがＷｉｎＦＳ同期サービス（ＷｉｎＦＳアダプタ）を介する場合、コミュニティに関して特定のトポロジを規定する、または義務付けることはまったくない。同期アダプタ（以下に説明する）は、独自のトポロジ制限を導入することが可能である。

変更追跡、変更単位、およびバージョン：すべてのＷｉｎＦＳストアは、すべてのローカルのＷｉｎＦＳ項目、ＷｉｎＦＳ拡張、およびＷｉｎＦＳ関係に対する変更を追跡する。変更は、スキーマの中で定義された変更単位粒状度のレベルで追跡される。いずれの項目タイプ、拡張タイプ、および関係タイプの最上レベルのフィールドも、スキーマ設計者が、最小粒状度の１つの最上レベルフィールドとして、変更単位に細分することができる。変更追跡の目的で、すべての変更単位には、バージョンが割り当てられ、バージョンは、同期パートナＩＤとバージョン番号（バージョン番号は、パートナ固有の単調に増加する番号である）のペアである。バージョンは、ストアの中で変更がローカルで生じると、または変更が他のレプリカから獲得されると、更新される。

同期知識：知識は、任意の時点における所与の同期レプリカの状態を表す。すなわち、知識は、所与のレプリカが認識している、ローカルの、または他のレプリカからのすべての変更に関するメタデータをカプセル化する。ＷｉｎＦＳ同期は、同期操作にわたって同期レプリカに関する知識を保持し、更新する。留意すべき重要なことは、知識表現は、知識が格納される特定のレプリカに関してだけでなく、コミュニティ全体に関して知識が解釈されることを可能にすることである。

同期アダプタ：同期アダプタは、同期ランタイムＡＰＩを介してＷｉｎＦＳ同期サービスにアクセスし、非ＷｉｎＦＳデータストアに対するＷｉｎＦＳデータの同期を可能にするマネージコードアプリケーションである。シナリオの要件に依存して、ＷｉｎＦＳデータのいずれのサブセットが、また、どのようなＷｉｎＦＳデータタイプが同期されるかは、アダプタ開発者に任されている。アダプタは、ＥＤＳとの通信を担い、ＷｉｎＦＳスキーマをＥＤＳがサポートするスキーマとの間で変換し、アダプタ独自の構成およびメタデータを定義し、管理する。アダプタは、ＷｉｎＦＳ同期アダプタＡＰＩを実装して、ＷｉｎＦＳ同期チームによって提供される、アダプタに関する共通の構成および制御のインフラストラクチャを活用することが強く推奨される。さらなる詳細については、ＷｉｎＦＳ同期アダプタＡＰＩ仕様［ＳＡＤＰ］およびＷｉｎＦＳ同期制御ＡＰＩ［ＳＣＴＲＬ］仕様を参照されたい。

ＷｉｎＦＳデータを外部の非ＷｉｎＦＳストアに同期させ、ＷｉｎＦＳ形式で知識を作成する、または保持することができないアダプタに関して、ＷｉｎＦＳ同期は、後の変更列挙操作または変更適用操作のために使用することができるリモート知識を獲得するサービスを提供する。バックエンドストアの能力に依存して、アダプタは、そのリモート知識をバックエンド上、またはローカルのＷｉｎＦＳストア上に格納することを所望することが可能である。

簡明にするため、同期「レプリカ」は、単一の論理的場所に存在する「ＷｉｎＦＳ」ストアの中のデータのセットを表す構造であるのに対して、非「ＷｉｎＦＳ」上のデータは、「データソース」と呼ばれ、一般にアダプタの使用を要する。

リモート知識：所与の同期レプリカが別のレプリカから変更を獲得することを所望する場合、そのレプリカは、そのレプリカ独自の知識をベースラインとして提供し、そのベースラインに対して、他方のレプリカが変更を列挙する。同様に、所与のレプリカが別のレプリカに変更を送信することを所望する場合、そのレプリカは、そのレプリカ独自の知識をベースラインとして提供し、そのベースラインを、リモートレプリカが、競合を検出するために使用することができる。同期変更の列挙および的様の最中に提供される他方のレプリカに関するこの知識を、リモート知識と呼ぶ。

２．同期ＡＰＩプリンシパル
一部の実施形態に関して、同期ＡＰＩは、次の２つの部分に分けられる。すなわち、同期構成ＡＰＩおよび同期コントローラＡＰＩである。同期構成ＡＰＩは、アプリケーションが、同期を構成し、２つのレプリカ間の特定の同期セッションに関するパラメータを指定することを可能にする。所与の同期セッションに関して、構成パラメータには、同期されるべき項目のセット、同期のタイプ（一方向または双方向）、リモートデータソースに関する情報、および競合解決ポリシーが含まれる。同期コントローラＡＰＩは、同期セッションを開始し、同期をキャンセルし、進行中の同期に関する進行状況情報およびエラー情報を受け取る。さらに、同期が所定のスケジュールに従って実行される必要がある特定の実施形態に関して、そのようなシステムは、スケジュールをカスタマイズするスケジュールメカニズムを含むことが可能である。

本発明のいくつかの実施形態は、「ＷｉｎＦＳ」データソースと非「ＷｉｎＦＳ」データソースの間で情報を同期するために同期アダプタを使用する。アダプタの実施例には、「ＷｉｎＦＳ」連絡先フォルダと非ＷｉｎＦＳメールボックスの間でアドレス帳情報を同期させるアダプタが含まれる。これらの実例では、アダプタ開発者は、「ＷｉｎＦＳ」スキーマと非「ＷｉｎＦＳ」データソーススキーマの間でスキーマ変換コードを開発するために、「ＷｉｎＦＳ」同期プラットフォームによって提供されるサービスにアクセスするための、本明細書で説明する「ＷｉｎＦＳ」同期コアサービスＡＰＩを使用することが可能である。さらに、アダプタ開発者は、非「ＷｉｎＦＳ」データソースを相手に変更を通信するためのプロトコルサポートを提供する。同期アダプタは、同期コントローラＡＰＩを使用することによって呼び出され、制御されて、このＡＰＩを使用して進行状況およびエラーを報告する。

しかし、本発明の一部の実施形態に関して、「ＷｉｎＦＳ」データストアを別の「ＷｉｎＦＳ」データストアと同期させる際、「ＷｉｎＦＳ」−「ＷｉｎＦＳ」同期サービスがハードウェア／ソフトウェアインターフェースシステム内部に組み込まれている場合、同期アダプタは、不必要である可能性がある。いずれにしても、いくつかのそのような実施形態は、以下を含む、「ＷｉｎＦＳ」−「ＷｉｎＦＳ」ソリューションと同期アダプタソリューションの両方のための同期サービスのセットを提供する。すなわち、
・「ＷｉｎＦＳ」項目、「ＷｉｎＦＳ」拡張、および「ＷｉｎＦＳ」関係に対する変更の追跡
・所与の過去の状態からの効率的な増分変更列挙のサポート
・「ＷｉｎＦＳ」への外部の変更の適用
・変更適用中の競合処理。

一般的なデータストアの３つのインスタンス、およびそれらのインスタンスを同期させるためのコンポーネントを示す図３６を参照すると。第１のシステム３６０２が、利用のために同期ＡＰＩ３６５２を公開する３６４６、ＷｉｎＦＳ−ＷｉｎＦＳ同期サービス３６２２と、コア同期サービス３６２４とを含むＷｉｎＦＳデータストア３６１２を有する。ファイルシステム３６０２と同様に、第２のシステム３６０４は、利用のために同期ＡＰＩ３６５２を公開する３６４６、ＷｉｎＦＳ−ＷｉｎＦＳ同期サービス３６３２と、コア同期サービス３６３４とを含むＷｉｎＦＳデータストア３６１４を有する。第１のシステム３６０２および第２のシステム３６０４は、それぞれのＷｉｎＦＳ−ＷｉｎＦＳサービス３６２２および３６３２を介して同期を行う３６４２。ＷｉｎＦＳシステムではない第３のシステム３６０６は、ＷｉｎＦＳ同期３６６６を使用して、データソースをＷｉｎＦＳレプリカと一緒に同期コミュニティの中に保つためのアプリケーションを有する。このアプリケーションは、ＷｉｎＦＳ同期構成／制御サービス３６６４を利用して、ＷｉｎＦＳ−ＷｉｎＦＳ同期サービス３６２２を介して（アプリケーションが、自らをＷｉｎＦＳデータストアとしてそのように仮想化することができる場合）、または同期ＡＰＩ３６５２とインターフェースをとる３６４８同期アダプタ３６６２を介して、ＷｉｎＦＳデータストア３６１２と直接にインターフェースをとる３６４４ことができる。

この図に示すとおり、第１のシステム３６０２は、第２のシステム３６０４と第３のシステム３６０６をともに認識しており、第２のシステム３６０４と第３のシステム３６０６の両方と直接に同期をとる。しかし、第２のシステム３６０４も、第３のシステム３６０６も、互いを認識しておらず、このため、自らの変更を互いと直接に同期させず、代わりに、一方のシステム上で行われた変更が、第１のシステム３６０２を介して伝播しなければならない。

Ｃ．同期ＡＰＩサービス
本発明のいくつかの実施形態は、２つの基礎的なサービス、すなわち、変更列挙および変更適用を含む同期サービスと目的とする。

１．変更列挙
本明細書で前述したとおり、変更列挙は、同期サービスによって保持される変更追跡データに基づき、そのパートナとの同期が前回に試みられて以来、データストアフォルダに対して行われた変更を、同期アダプタが容易に列挙することを可能にする。変更列挙に関して、本発明のいくつかの実施形態は、以下を目的とする。
・指定された知識インスタンスに関連して、所与のレプリカ内の項目、拡張、および関係に対する変更の効率的な列挙
・ＷｉｎＦＳスキーマの中で指定された変更単位粒状度のレベルにおける変更の列挙
・複合項目に関する列挙された変更のグループ化。複合項目は、項目、その項目のすべての拡張、その項目に対するすべての保持関係、およびその項目の組み込まれた項目に対応するすべての複合項目から成る。項目間の参照関係に対する変更は、別個に列挙される
・変更列挙のバッチ処理。バッチの粒状度は、複合項目または関係変更（参照関係に関する）である
・変更列挙中のレプリカ内の項目に対するフィルタの指定。例えば、レプリカは、所与のフォルダ内のすべての項目から成るが、その特定の変更列挙に関して、アプリケーションは、ファーストネームが「Ａ」で始まるすべての連絡先項目に対する変更だけを列挙することを所望する（このサポートは、ポストＢマイルストーン（ｍｉｌｅｓｔｏｎｅ）に追加される）
・知識の中で個々の変更単位（または項目全部、拡張全部、または関係全部）を同期に失敗したものとして記録して、それらの変更単位が、次回に再び列挙されるようにすることができることを伴う、列挙された変更に関するリモート知識の使用
・変更列挙中に変更とともにメタデータを戻すことにより、ＷｉｎＦＳ同期メタデータを理解できる可能性がある高度なアダプタの使用

２．変更適用
本明細書で前述したとおり、変更適用は、同期アダプタが、同期アダプタのバックエンドから受け取られた変更をローカルストレージプラットフォームに適用することを可能にする。というのは、アダプタは、ストレージプラットフォームスキーマに対する変更を変換するものと予期されているからである。変更適用に関して、本発明のいくつかの実施形態は、以下を目的とする。
・ＷｉｎＦＳ変更メタデータに対する対応する更新を伴う、他のレプリカ（または非ＷｉｎＦＳストア）からの増分変更の適用
・変更単位粒状度における変更適用に関する競合の検出
・変更適用に関して、個々の変更単位レベルで成功、失敗、および競合を報告して、アプリケーション（アダプタおよび同期制御アプリケーションを含む）が、進行状況報告、エラー報告、およびステータス報告のため、ならびに、存在する場合、バックエンド状態を更新ために情報を使用できるようにすること
・変更適用中にリモート知識を更新して、次の変更列挙操作中に、適用がもたらした変更（ａｐｐｌｉｃａｔｉｏｎｓｕｐｐｌｉｅｄｃｈａｎｇｅｓ）の「反映」を防止するようにすること
・変更とともに、ＷｉｎＦＳ同期メタデータを理解し、提供することができる高度なアダプタの使用

３．サンプルコード
以下は、ＦＯＯ同期アダプタがどのように同期ランタイムと対話することが可能かに関するコードサンプルである（ただし、すべてのアダプタ固有の機能には、ＦＯＯを前置している）。

４．ＡＰＩ同期のメソッド
本発明の一実施形態では、ＷｉｎＦＳストアと非ＷｉｎＦＳストアの間の同期は、ＷｉｎＦＳベースのハードウェア／ソフトウェアインターフェースシステムによって公開される同期ＡＰＩを介して達せられる、可能である。

一実施形態では、すべての同期アダプタは、同期アダプタＡＰＩ、ＣＬＲ（共通言語ランタイム）マネージＡＰＩを実装して、整合性のある形で展開され、初期化され、制御されることが可能であるようにすることを要する。アダプタＡＰＩは、以下を提供する。
・アダプタをハードウェア／ソフトウェアインターフェースシステム同期フレームワークに登録する標準のメカニズム
・アダプタが、アダプタの機能、ならびにアダプタを初期化するのに必要とされる構成情報のタイプを宣言する標準のメカニズム
・初期化情報をアダプタに送るための標準のメカニズム
・アダプタが、進行ステータスを、同期を呼び出したアプリケーションに報告するメカニズム
・同期中に生じたエラーを報告するメカニズム
・進行中の同期操作のキャンセルを要求するメカニズム

シナリオの要件に依存して、２つの可能なプロセスモデルが存在する。アダプタは、アダプタを呼び出したアプリケーションと同一のプロセス空間内で実行されること、あるいはアダプタ単独の別個のプロセスにおいて実行されることが可能である。アダプタ独自の別個のプロセスを実行するのに、アダプタは、アダプタのインスタンスを作成するのに使用されるアダプタ独自のファクトリクラスを定義する。ファクトリは、呼び出し側アプリケーションと同一のプロセスの中でアダプタのインスタンスを戻すこと、あるいは異なるＭｉｃｒｏｓｏｆｔ共通言語ランタイムアプリケーションのドメインまたはプロセスの中でアダプタのリモートインスタンスを戻すことができる。アダプタのインスタンスを同一のプロセスの中で作成する既定のファクトリ実施形態が提供される。実際には、多くのアダプタは、呼び出し側アプリケーションと同一のプロセスの中で実行される。プロセス外（ｏｕｔｏｆｐｒｏｃｅｓｓ）モデルは、通常、以下の理由の１つまたは複数のために要求される。
・セキュリティ目的。アダプタが、あるプロセスまたはサービスのプロセス空間の中で実行されなければならない
・アダプタが、呼び出し側アプリケーションからの要求を処理することに加え、他のソースからの要求、例えば、着信するネットワーク要求を処理しなければならない

図３７を参照すると、本発明の一実施形態は、どのように状態が計算されるか、またはどのように関連するメタデータが交換されるかを認識していない単純なアダプタを想定する。この実施形態では、同期は、レプリカが同期することを所望するデータソースに関して、まず、ステップ３７０２で、レプリカが前記データソースと前回に同期して以来、いずれの変更が行われたかを判定することによってレプリカによって達せられ、レプリカは、次に、レプリカの現在の状態情報に基づき、その前回の同期以来、行われている増分変更を送信し、その現在の状態情報および増分変更は、アダプタを介してデータソースに対してである。ステップ３７０４で、アダプタは、前のステップでレプリカから変更データを受け取ると、可能な限り多くの変更をデータソースに実施し、いずれの変更が成功し、いずれの変更が失敗したかを追跡し、成功および失敗の情報をＷｉｎＦＳ（レプリカの）に送り返す。レプリカ（ＷｉｎＦＳ）のハードウェア／ソフトウェアインターフェースシステムは、ステップ３７０６で、レプリカから成功および失敗の情報を受信すると、データソースに関する新たな状態情報を計算し、レプリカによる将来の使用のためにその情報を格納し、その新たな状態情報をデータソースに、つまり、アダプタに、アダプタによる格納および後の使用のために送り返す。

Ｄ．同期階層
本明細書で前述したとおり、各レプリカ（およびデータソースおよび／またはアダプタ）は、レプリカの変更の増分の、順次の変更を保持し、それぞれのそのような変更には、対応する増分の、順次の変更番号（すなわち、第１の変更は１であり、第２の変更は２であり、第３の変更は３であり、以下同様である）が割り当てられる。さらに、各レプリカは、レプリカの同期コミュニティ内のその他の既知のレプリカ（同期パートナ）に関する状態情報も、いずれの変更をレプリカが、それらの他のレプリカから受信したかを追跡するために保持する。第２のレプリカから来た、第１のレプリカに適用された最後の変更番号を知ることにより、第１のレプリカは、以降、その番号を使用して、その最後に適用された変更の番号より大きい変更だけを要求する、受信する、または処理することができる。図３８Ａ〜Ｄは、その順次の変更列挙方法を使用して、どのように変更が追跡され、列挙され、同期されるかを示す。

図３８Ａにおいて、同期パートナＡおよびＢは、共通の同期コミュニティ内のレプリカであり、現在の状態で示されており、まだまったく変更が行われていないので、現在の状態は、各レプリカに関して０の変更番号に、例えば、それぞれ、各レプリカに関してＡ０およびＢ０に等しい。（この実施形態では、固有の変更番号が、初期状態を反映するように使用される。）各レプリカは、自らの状態を認識し、レプリカの同期パートナの状態を追跡しており、その情報を図に示すレプリカの「ベクトル」に反映させる（ベクトルは、図示するとおり、レプリカ自体の状態をまずリストアップし、その後に、最後の同期に基づく、または、このケースでは、初期化に基づくレプリカのパートナのそれぞれの最後の既知の状態を示す）。レプリカＡに関する初期ベクトルは、「［Ａ０，Ｂ０］」であり、レプリカＢに関する初期ベクトルは、「［Ｂ０，Ａ０］」であり、この２つのレプリカは、現在、完全に同期している。

図３８Ｂにおいて、レプリカＡが、変更を行い、その変更に固有の増分変更番号Ａ１を割り当てる（変更番号は、レプリカ自体に関する固有ＩＤ、「Ａ」、およびそのレプリカ上の変更に関する固有の増分される番号、「１」を含む）。他方、レプリカＢは、２つの変更を行い、それらの変更に、それぞれＢ１およびＢ２という固有の増分変更番号を割り当てる。その時点で、次の同期に先立って、レプリカは、現在、同期しておらず、レプリカＡに関するベクトルは、現在、［Ａ１，Ｂ０］であり、レプリカＢに関するベクトルは、［Ｂ２，Ａ０］である（この場合も、既知の最後の変更を反映する）。

図３８Ｃにおいて、レプリカＡは、レプリカＡの現在のベクトルをレプリカＢに送信して変更を要求することにより（ステップ１）、レプリカＢと同期する。レプリカＢは、レプリカＡのベクトルを受信すると、変更Ｂ１とＢ２をともにレプリカＡに送信する必要があることを計算し、このため、そうすることに取りかかる（ステップ２）。レプリカＡは、Ｂ１およびＢ２として識別されるレプリカＢの変更（つまり、変更単位）を受信し、それらの変更を適用し、レプリカＡ自体のベクトルを更新して［Ａ１，Ｂ２］にする（ステップ３）。

図３８Ｄに示す代替の実施形態では、レプリカＢは、レプリカＡに対して正しい変更を計算し、送信する（ステップ２）とともに、レプリカＡのベクトルに基づき、レプリカＢが有さない変更が、レプリカＡに行われていると判定し、このため、レプリカＢは、レプリカＢ自体のベクトル、および変更を求める要求をレプリカＡに送信する（ステップ２’）。次に、レプリカＡが、レプリカＢの変更を受信し、変更を適用し、レプリカＡ自体のベクトルを更新して［Ａ１，Ｂ２］にし（ステップ３中に）、レプリカＡの変更のいずれがレプリカＢに送られるべきかを計算し、それらの変更を送信することも行う（ステップ３’）。レプリカＢは、その情報を受信すると、それらの変更を行い、レプリカＢのベクトルを更新して［Ｂ２，Ａ１］にする（ステップ４）。

以上の実施例に関して、いくつかの状況で競合が生じる可能性があることが可能である。例えば、Ａ１およびＢ２が、同一の変更単位に対して行われた変更であること、あるいはＡ１が、Ｂ２が変更していたのと同一の変更単位に対する削除であることが可能である。これらの競合の一部は、本明細書で前述した競合解決オプションを使用して解決することができるが、一部の競合は、特に困難な問題をもたらし、それらの問題、およびそれらの問題の問題解決法を、本発明の実施例に照らして以下に説明する。

１．以前に「範囲外（ＯｕｔｏｆＳｃｏｐｅ）」であった変更を同期させること
本発明の一部の実施形態では、レプリカの範囲は、静的ではない可能性がある。したがって、レプリカＡは、レプリカＡの範囲内の項目とレプリカＡの範囲内にない項目の間で新たな関係を作成する変更で、レプリカＡの範囲を事実上、増大させる可能性がある。しかし、範囲外の項目に関する変更単位が、レプリカＡとレプリカＢの間で同期されていないものと想定すると（その項目が、それらのレプリカに関する同期の範囲外にあったため）、その特定の項目に関するバージョンパスに関して同期の不整合が生じる可能性がある。この問題に対する問題解決法は、レプリカＡが、レプリカＢに、範囲外の項目に対して行われたすべての変更を、レプリカＡ内で範囲内の項目と範囲外の項目の間で関係を作成する特定の変更とともに送信することである。

２．親−子の順序の乱れ（ｄｉｓｏｒｄｅｒｉｎｇ）を同期させること
本発明の一部の実施形態では、同期に関して、親項目が、子項目より常に前に送られることが一般的なプリンシパルである（例えば、子である項目Ｋが、親である項目Ｊに組み込まれている場合、項目Ｋは、項目Ｊが伝送される前に伝送されることが不可能である）。しかし、レプリカＡに関して、同期の合間に、項目Ｊと項目Ｋがともに変更されるが、子の項目Ｋが、子の項目Ｊより低い並べ替え（ｓｏｒｔｉｎｇ）番号を有し（例えば、項目ＫのＩＤ番号の順序上の優先順位（ｓｅｑｕｅｎｔｉａｌｐｒｅｃｅｄｅｎｃｅ）に基づき）、このため、通常、先に伝送されることが可能である。本発明の様々な実施形態における同期に関するこの問題に対する１つの問題解決法は、項目Ｋに対して行われた変更だけを反映するグループと、項目Ｊに対して行われた変更だけを反映する第２のグループという２のグループに変更を分割し、それらのグループを正しい順序で送信することである（つまり、子の項目Ｋに関する変更のグループを、親の項目Ｊに関する変更のグループを送信した後に送信する）。

３．削除標識伝播
本明細書で前述したとおり、削除標識が、同期の目的で削除された変更単位にマークを付けるのに使用される。しかし、同期は、同期コミュニティ内の複数のベクトルに関して非同期であるため、それらの削除標識は、データプラットフォーム全体にわたって伝播しなければならない。問題は、削除標識伝播を考慮に入れずに、レプリカＡが、項目を作成し、レプリカＢとの同期中に、その項目をレプリカＢに送信する可能性があることである。その後、レプリカＡは、その項目を削除する可能性があり、レプリカＣとの同期中、その項目に関して何も送信しない。というのは、送信する物が何もないからである（その項目が削除されているため）。その後、レプリカＢとレプリカＣが同期しようと試みると、レプリカＣｈａ，レプリカＢからその項目を受け取り、Ｂ上で存続する。

本発明の様々な実施形態に関するこの問題に対する問題解決法は、レプリカＡが、削除された項目に削除標識でマークを付けることである。すると、レプリカＡは、項目を削除した場合、レプリカＣとの同期中、削除標識をレプリカＢに送信する。レプリカＢとレプリカＣが同期しようと試みた場合、レプリカＢは、削除標識も受け取り、項目は、その時点で、同期コミュニティから完全に削除される。

４．ルート削除標識伝播
Ｐ１内で、項目Ｘが、複数の組み込まれた項目Ａ、Ｂ、Ｃ、Ｄ、およびＥを有する場合、同期の合間に、Ｐ１が第１に、それらの子の項目を削除し、第２に、親の項目Ｘを削除すると（すなわち、６つの変更として、ｄｅｌＡ、ｄｅｌＢ、ｄｅｌＣ、ｄｅｌＤ、ｄｅｌＥ、およびｄｅｌＸ）、興味深いシナリオが生じる。というのは、Ｐ１が、親のＸを単に削除したとしても（１つの変更）、同一の正味の結果が生じたことになるからであり、その場合、組み込まれた項目も、自動的に削除される。これに関して、本発明のいくつかの実施形態は、同期後、Ｘを削除することが、実際、６つの別々の削除イベントと均等であることを認識することによって効率を獲得し、このため、Ｐ１は、Ｘの削除に相当する変更単位だけをＰ２に送り、その削除が、Ｐ２内のＸの組み込まれた項目に自然に伝播することを可能にする。

５．関係名スワップ
前述したとおり、関係は、名前を有し、このため、１つのレプリカ（Ｐ１）が、一時的名前要素（Ｘ）の使用を介して２つの関係（Ｒ１およびＲ２）の名前をスワップする（ｓｗａｐ）ことが可能である。つまり、Ｒ１の名前がＸにコピーされ、次に、Ｒ２の名前がＲ１にコピーされ、次に、ＸがＲ２にコピーされ、最後にＸが削除される。しかし、パートナレプリカ（Ｐ２）は、一時的名前要素Ｘについて知らないため、同期中にエラーが生じる。というのは、Ｒ１が新たな名前を有することを認識して、その名前を変更しようとするＰ２の試みは、Ｒ１とＲ２がともに同一の名前を使用しているためにエラーとなるからである。本発明の様々な実施形態に関するこの問題に対する１つの問題解決法は、Ｐ２が、その同一名エラーを受け取る、または認識すると、可能な名前スワップシナリオを推定し、Ｐ２独自の一時的名前要素（Ｙ）を自動的に作成することであり、後の変更に、実際、Ｒ２の名前をＸ内の名前に変更することが関わる場合、Ｐ２は、スワップを完了する（それ以外の場合、Ｐ２は、シナリオを通常の競合イベントとして生成する）。

６．参照関係
レプリカＰ１（ＷｉｎＦＳシステム上で実行される）とデータソースＰ２（非ＷｉｎＦＳシステム上で実行される）の間の同期に関して、ぶら下がり関係（ＷｉｎＦＳによってサポートされる）のコンテキストにおいて問題が生じる、非ＷｉｎＦＳシステムによってサポートされない。この問題は、２つの項目ＡおよびＢが、Ｐ１上で関係Ｒを有し、Ｐ１が、それらをＡ（変更単位Ｐ１−２１として）、次にＲ（変更単位Ｐ１−２２として）、次にＢ（変更単位Ｐ１−２３として）の順に作成した場合に生じる。Ｒが作成されると（Ｐ１−２２）、Ｒは、ぶら下がり関係であり、したがって、Ｐ２がそれらの変更を順に適用すると、許されないぶら下がり関係のエラーがもたらされる。本発明のこの問題に対する問題解決法は、代わりに変更を並べ替え、すべての参照関係（例えば、Ｒ）が、他のすべての変更がＰ１からＰ２に送信された後に送信されるようにすることであり、これにより、問題は、まず項目Ａおよび項目Ｂを作成し、次に項目Ａと項目Ｂを関係Ｒで互いに関係付けることによって完全に回避される。

Ｅ．同期−競合処理
本明細書で前述したとおり、同期サービスにおける競合処理は、次の３つの段階に分割される。すなわち、（１）変更適用時に行われる競合検出−このステップは、変更を安全に適用することができるかどうかを判定する、（２）自動競合解決およびログ記録−このステップ（競合が検出された直後に行われる）中、自動競合ハンドラに問い合わせが行われて、競合を解決することができるかどうかが確かめられる−解決することができない場合、競合は、オプションとしてログ記録されることが可能である、および（３）競合検査および競合解決−このステップは、いくつかの競合がログ記録されている場合に行われ、同期セッションのコンテキスト外で行われる−その時点で、ログ記録された競合が解決され、ログから削除されることが可能である。

本発明の様々な実施形態は、具体的には、ピアツーピア同期システム（本明細書で前述した同期システムなどのための）において生じる競合に関する競合処理を目的とする。競合を正しく、効率的に扱うことができることにより、良好な使いやすさを保ちながら、データ損失が最小限に抑えられ、同期中のユーザ介入の必要性が小さくなる。本発明のいくつかの実施形態は、以下の競合処理要素の１つまたは複数を含む競合処理スキーマを目的とする。すなわち、（ａ）競合のスキーマ化された表現、（ｂ）競合の検出、（ｃ）競合を永続性のあるストアにログ記録すること、（ｄ）柔軟性があり、構成可能な競合解決ポリシーに従った競合の自動解決、（ｅ）競合をフィルタリングし、解決する、構築可能で（ｃｏｍｐｏｓａｂｌｅ）拡張可能な競合ハンドラ、（ｆ）古い競合の自動的な検出および除去、および（ｇ）プログラマティック（ｐｒｏｇｒａｍｍａｔｉｃ）競合解決である。さらに、競合処理スキーマとは別に、これらの競合処理要素のそれぞれは、それ自体、本発明のさらなる実施形態を表す。

１．競合タイプ
一般に、競合は、同期操作中にデータを同期させることができない場合にはいつでも生じる（「変更適用障害」）。それらの障害は、様々な理由で生じることが可能であるが、一般に、競合は、次の２つのカテゴリに分けることができる。すなわち、制約競合および知識競合である。

ａ）知識ベースの競合
知識ベースの競合は、２つのレプリカが、同一の変更単位に対して独立の変更を行った場合に生じる。２つの変更は、互いの知識なしに行われる場合に、つまり、第１の変更のバージョンが、第２の変更の知識の範囲に含まれず、その逆も同様である場合に、独立と呼ばれる。同期サービスは、前述したとおり、レプリカの知識に基づいてすべてのそのような競合を自動的に検出し、以下に説明するとおり、それらの競合に対処する。一部の特定のタイプの知識競合には、更新−削除競合、削除−更新競合、および更新−更新競合（それぞれの名前は、順にローカルアクションとリモートアクションを指し、例えば、更新−削除競合は、同一のデータに対するローカル更新とリモート削除に起因する）が含まれる。

ときとして、競合を変更単位のバージョン履歴における分岐として考えることが役立つ。変更単位の有効期間（ｌｉｆｅ）中に競合がまったく生じなかった場合、変更単位のバージョン履歴は、単純なチェーンである、すなわち、各変更は、前の変更の後に生じる。知識ベースの競合のケースでは、２つの変更は、並行に生じ、チェーンが分かれ、バージョンツリーになるようにさせる。

要するに、知識競合は、知識およびバージョンの処理の結果として生じる。それらは、データベースの中に格納された情報に対する競合するバージョンを有する変更が適用された場合に、ＷｉｎＦＳ同期によって生じさせられる。競合は、競合する変更情報、およびバージョン情報を含む必要がある。知識競合に関するほとんどの要件は、制約競合に関する要件でもある。ただし、知識競合は、同期バージョンおよび知識に基づいてだけ検出されることが可能である。

ｂ）制約ベースの競合
独立した変更が、一緒に適用された場合、整合性（ｉｎｔｅｇｒｉｔｙ）制約に違反するケースが存在する。例えば、２つのレプリカが、同一のディレクトリ内で同一名を有するファイルを作成することにより、システム内の制約（フォルダ内における固有項目名の実施などの）が、このタイプの制約ベースの競合を生じさせるそのような競合が生じさせられる可能性がある。

一般に、制約ベースの競合には、知識ベースの競合の場合とまったく同様に、２つの独立した変更が関わる。ただし、制約ベースの競合は、同一の変更単位には影響を与えず、代わりに、間に制約が存在する、相異なる変更単位に影響を与える変更を含む。制約ベースの競合は、１つのシステムが制約を有し、他方のシステムが制約を有さない２つの異なるタイプのシステムの間で同期を行う際などに、単一の変更からもたらされることが可能である。例えば、システムが、最大のファイル名の長さが８文字長であるという制約を有し、そのシステムが、そのような制約を有さない別のシステムからファイルに対する変更を受信し、その変更が、ファイル名に対するものであり、ファイル名を８文字長より長くする場合、制約競合がもたらされる（単一の変更から生じた、１、単一のマシン）。

具体的なタイプの制約競合には、以下が含まれるが、以下には限定されない。すなわち、
・挿入−挿入競合：これは、２つの同期パートナがそれぞれ、同一の名前を有するファイルなどの、同一の論理識別子を有するオブジェクトを作成した場合に生じる
・親なし競合：これは、作成されるべき着信オブジェクトの親が存在しない場合に生じる。例は、ファイルが、そのファイルの親フォルダより前に受信された場合である
・未定義タイプ競合：これは、着信オブジェクトのスキーマがインストールされておらず、オブジェクトが作成されるのを妨げる場合に生じる

要するに、制約競合は、様々な理由で変更を適用することに失敗したことによって生じさせられる。そのような失敗は、最終的な収束をもたらす解決の形態で有意義に対処が行われることが可能である場合、またはユーザ対話を介する最終的な解決のためにログ記録されることが可能である場合、制約競合と呼ばれる。報告される以外、有意義に対処されることが不可能な失敗は、単に変更適用エラーと呼ばれる。一部の実施形態に関して、すべての変更適用の失敗は、エラーとして扱われる。つまり、認識される制約競合はまったく存在しない。一部の実施形態の場合、同期送信（Ｓｅｎｄｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）中に生じるすべての競合は、無視される。というのは、知識競合は、次の同期受信時に再提示（ｒｅ−ｐｒｅｓｅｎｔ）されることが予期されるからである。（非収束をもたらす他の失敗も無視されることが可能である。）

２．競合検出
競合サービスは、変更適用時に制約違反を検出し、制約ベースの競合を自動的に生じさせる。制約ベースの競合を解決することは、通常、制約に違反しないような形に変更を変えるカスタムコードを要し、同期サービスは、これを行うための汎用のメカニズムを提供することも、提供しないことも可能である。

本発明の様々な実施形態に関して、競合は、ローカルの知識がリモートバージョンを認識しているかどうか、またその逆を調べることにより、変更単位ごとに検出される。知識ベースの競合に関して、以下の４つの競合検出シナリオが存在する。すなわち、
１．ローカル知識が、リモートバージョンを認識しており、リモート知識が、ローカルバージョンを認識していない：これは、着信する変更が古く、したがって、破棄されることを意味する。
２．ローカル知識が、リモートバージョンを認識しておらず、リモート知識が、ローカルバージョンを認識している：これは、着信する変更がローカルバージョンより新しく、したがって、受け入れられることを意味する。
３．ローカル知識が、リモートバージョンを認識しており、リモート知識が、ローカルバージョンを認識している。これは、両方のバージョンが均等であり、したがって、変更がまったく適用されない場合にだけ生じる可能性がある。
４．ローカル知識が、リモートバージョンを認識しておらず、リモート知識が、ローカルバージョンを認識していない。これは、ローカルバージョンとリモートバージョンが競合しており、したがって、競合が生じさせられることを意味する。

３．競合処理
競合は、同期送信中、または同期受信中に生じる可能性があるが、一方向同期操作における両方のパートナが類似している（２つの類似した形で構成されたＷｉｎＦＳストアのように）場合、シナリオは、対称的であり、同期で競合を自動的に解決することにより、または非同期の解決（自動または手動の）ために競合をログ記録することにより、受信側で最も容易に対処されることが可能である。

もちろん、ＷｉｎＦＳ−非ＷｉｎＦＳ同期の場合のように、送信側パートナが競合に対処する必要がある可能性がある状況も存在する。そのようなケースでは、後の同期受信において送信側パートナに戻るように伝達されない可能性がある制約競合。さらに、受信側パートナは、競合ログを有さない、または管理の容易さのために送信側の競合ログを使用する必要がある可能性がある。そのようなケースでは、変更は、完全に拒否されて、送信側が競合を解決するように強制されることが可能である（以下に説明する）。

同期開始側（ｉｎｉｔｉａｔｏｒ）は、自らの同期プロファイルの中で競合解決を構成する。同期サービスは、複数の競合ハンドラを単一のプロファイルに結合することをサポートする。競合処理メカニズムは拡張可能であるため、複数の競合ハンドラを結合するいくつかのやり方が存在する。１つの特定の方法は、競合ハンドラの１つが成功するまで、次々に試みられるべき競合ハンドラのリストを指定することに関わる（以下に説明する）。別の方法は、例えば、更新−更新の知識ベースの競合を１つの競合ハンドラに向かわせ、他のすべての競合をログに向かわせるなど、競合ハンドラを競合タイプに関連付けることに関わる。

競合が検出されると、同期サービスは、次の３つのアクションの１つ（同期プロファイルの中で同期開始側によって選択される）を行うことができる。すなわち、（１）変更を拒否する、（２）競合を自動的に解決する、または（３）競合を競合ログにログ記録する、である。

ａ）変更を拒否する
変更が拒否される場合、同期サービスは、あたかも変更がレプリカに着信しなかったかのように動作し、否定応答（ｎｅｇａｔｉｖｅａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）が送信元に送り返される。この解決ポリシーは、競合をログ記録することが実行可能でないヘッドレス（ｈｅａｄ−ｌｅｓｓ）レプリカ（ファイルサーバなどの）上で主に役立つ。代わりに、そのようなレプリカは、その他のレプリカが、競合を拒否することによって競合に対処することを強制する。

ｂ）自動的競合解決
自動的競合解決は、指定されたポリシーに従って競合を同期で解決するプロセスである。ＷｉｎＦＳ同期操作において、ポリシーは、送信操作と受信動作に関して独立に指定されることが可能である。自動競合解決ポリシーは、同期プロファイルを介して指定される。生じさせられた競合は、プロファイルの中で指定された最上レベルの競合ハンドラに送られる。その競合ハンドラは、競合を解決すること、競合をログ記録すること、または競合処理パイプラインに沿ったさらなる処理のために別の競合ハンドラに競合を送ることができる。

図３９Ａは、本発明のいくつかの実施形態に関する競合処理パイプラインを示す。図では、競合が生じた場合、競合ハンドラリスト（または「リスト」）３９１０が、競合項目３９０２を受け取り、その競合を、このケースではフィルタである、パイプラインの第１のパス上の第１のハンドラ３９１２に送る。フィルタ３９１２は、競合３９０２を評価するゲートキーパー（ｇａｔｅｋｅｅｐｅｒ）であり、競合を次のハンドラ３９１４まで通過させるか、またはその競合を拒否して、リスト３９１０に戻し、リスト３９１０は、その競合をリスト３９１２に送り返し、リスト３９１２は、その競合をパイプライン内の次のパス上の第１のハンドラ３９２２に送る。競合３９０２が、第１のフィルタ３９１２によって、このケースではリゾルバである第２のハンドラ３９１４まで通過させられた場合、競合は、可能な場合、リゾルバ３９１４によって解決されるか、あるいは可能でない場合、拒否されて第１のハンドラ３９２２に戻され、リスト３９１０に戻され、次に、パイプライン内の次のパス上でリゾルバ３９２２に送られる。その後、競合は、（ａ）パイプライン内のハンドラの１つによって解決されるか、（ｂ）「ロガー（ｌｏｇｇｅｒ）」として知られる特別の競合ハンドラ、例えば、ロガー３９３６（つまり、競合がフィルタ３９３４を通過した場合）によって競合ログに明示的にログ記録されるか、または（ｃ）完全にパイプラインの外に出るように送り返され、既定で、競合ログ（ロガー３９４４として論理的に破線で示す）に送られるまで、パイプラインの中を進みつづける。

図３９Ｂは、図３９Ａに示したパイプラインの論理的に通ること（ｔｒａｖｅｒｓａｌ）を示す流れ図である。図３９Ｂで、図３９Ａも参照すると、競合３９０２が、ステップ３９５０で、競合ハンドラリスト３９１０においてパイプラインに入り、ステップ３９５２で、フィルタ３９１２に最初に送られる。競合３９０２は、次にステップ３９５４で、そのフィルタ３９１２を通過した場合、ステップ３９５６で、リゾルバ３９１４に進み、リゾルバ３９１４は、ステップ３９５８で、競合３９０２を解決しようと試みる。成功した場合、ステップ３９９８で、プロセスは戻り、成功しなかった場合、競合は、ステップ３９６０で、リゾルバ３９２２に進み、リゾルバ３９２２は、ステップ３９６２で、競合３９０２を解決しようと試みる。成功した場合、ステップ３９９８で、プロセスは戻り、成功しなかった場合、競合は、ステップ３９６４で、リスト３９３２に進み、そこから、ステップ３９６６で、フィルタ３９３４に進み、競合３９０２は、ステップ３９６８で、そのフィルタ３９３４を通過した場合、ステップ３９７２で、ステップ３９７０でロガー３９３６によって競合ログ（図示せず）の中にログ記録され、プロセスは、ステップ３９９８で戻り、通過しなかった場合、競合３９０２は、ステップ３９７２で、フィルタ３９３８に送られ、競合３９０２は、ステップ３９７４でそのフィルタ３９３８を通過した場合、ステップ３９７６で、リゾルバ３４０に進み、リゾルバ３４０は、ステップ３９７８で、競合３９０２を解決しようと試みる。成功した場合、ステップ３９９８で、プロセスは戻り、成功しなかった場合、競合は、ステップ３９８０で、リゾルバ３９４２に進み、リゾルバ３９４２は、ステップ３９８２で、競合３９０２を解決しようと試みる。成功した場合、ステップ３９９８で、プロセスは戻り、成功しなかった場合、競合３９０２は、ステップ３９８４で、リゾルバ３９３６によって競合ログ（図示せず）の中にログ記録され、プロセスは、ステップ３９９８で戻る。

図３９Ａおよび図３９Ｂには示していないが、競合が１つのリゾルバによって解決されることが不可能な場合、その競合が、次のリゾルバに転送され、次のリゾルバが、競合を解決しようと試み、以下同様である、連続する競合リゾルバのパスを構築することもできることに留意されたい。競合が未解決のままである場合、その競合が、次のパスに進むためにリストまでパスを逆に送られるのは、パスの終りにおいてだけである。同様に、リストに関するパスのすべてが尽き、競合が未解決のままであると、リストは、競合が次のリストに到達するまで、経路を戻るように競合を送り、以下同様である。

また、パイプラインは、必ずしもリストから始まる必要はなく、逆に、パイプラインは、例えば、フィルタなどの任意のタイプの競合ハンドラから始まってもよいことに留意することも重要である。しかし、それでも、競合が、パイプライン内の最初の競合ハンドラまでパスを送り戻され、その競合ハンドラが、試みられるべきさらなるパスを有さない場合（これは、パスのすべてが試みられてはいない競合ハンドラリストに関してだけ該当する）、競合は、パイプラインの外に出て、既定により、競合ログに自動的にログ記録される。

ＣｏｎｆｌｉｃｔＨａｎｄｌｅｒタイプは、競合ハンドラリスト、競合ログ、および競合フィルタ、ならびにその他のタイプの競合ハンドラを含む、競合ハンドラの基礎タイプである。さらに、同期サービスは、以下を含むが、以下には限定されない、いくつかの既定の競合ハンドラも提供することができる。すなわち、
・ローカル勝利（ｗｉｎｓ）：着信するデータに対して、ローカルで格納されているデータを勝者として選択することにより、競合を解決する
・リモート勝利：ローカルで格納されているデータに対して、着信するデータを勝者として選択することにより、競合を解決する
・最終書き込み側勝利（ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ）：変更単位のタイムスタンプに基づき、変更単位ごとにローカル勝利またはリモート勝利（同期サービスは、一般に、クロック値に依拠しないことに留意されたい。この競合リゾルバは、その規則に対する唯一の例外である）
・決定論的：すべてのレプリカ上で同一であることが保証されるが、それ以外では意味のない形で勝者を選ぶ−同期サービスの一実施形態は、パートナＩＤの辞書式比較を使用して、この機能を実施することが可能である。

例えば、競合ハンドラは、以下のとおり、更新−削除競合に関して、ローカル勝利解決が適用されるべきであり、他のすべての競合に関して、最終書き込み側勝利解決が適用されるべきことを指定することができる。

もちろん、競合ハンドラがまったく指定されない場合、または競合が、指定された競合ハンドラのいずれによっても処理されない場合、競合は、競合ログに入れられる。一部の実施形態の場合、競合ログも競合ハンドラである。

本発明の様々な実施形態に関して、ＩＳＶは、独自の競合ハンドラを実施し、インストールすることができる。カスタム競合ハンドラは、構成パラメータを受け入れることができる。ただし、そのようなパラメータは、ＳＣＡによって、同期プロファイルの競合解決セクションの中で指定されなければならない。

競合リゾルバは、競合を処理する場合、実行される必要がある操作のリストを（競合する変更の代わりに）ランタイムに戻す。すると、競合サービスが、競合ハンドラが考慮したことを含むようにリモート知識を適切に調整して、それらの操作を適用する。

解決を適用している最中に別の競合が検出されることが可能である。そのようなケースでは、新たな競合は、最初の処理が再開される前に解決されるか、またはログ記録されなければならない。

競合を項目のバージョン履歴における分岐と考える場合、競合解決は、単一のポイントを形成するように２つの分岐を結合する結合（ｊｏｉｎ）と見なすことができる。このため、競合解決は、バージョン履歴をＤＡＧ（有向非循環グラフ）にする。

ｃ）競合ログ記録
一部の報告された競合は、自動競合解決を使用して同期で解決されることが可能であるが、他の競合は、後のプログラマティック解決のためにログ記録されることが可能である。競合ログ記録により、競合解決プロセスが非同期で行われることが可能になる。つまり、競合は、検出された時点で解決される必要がなく、将来の解決のためにログ記録されることが可能である。例えば、競合ビューア（Ｖｉｅｗｅｒ）アプリケーションが、ユーザが、事後にログ記録された競合を点検し、手動で解決することができるようにすることが可能である。

本発明のいくつかの実施形態に関して、非常に特別な競合ハンドラが、競合ロガー（または、より単純に「ロガー」）である。同期サービスは、ＣｏｎｆｌｉｃｔＲｅｃｏｒｄというタイプ（または、代替の実施形態では、単にＣｏｎｆｌｉｃｔというタイプ）の項目として、競合を競合ログの中にログ記録する。それらのレコードは、反対に、競合している項目に関連付けられる（項目自体が削除されていない限り）。一部の実施形態に関して、各競合レコードは、以下を含む。すなわち、競合を生じさせた着信の変更、競合のタイプ（例えば、更新−更新、更新−削除、削除−更新、挿入−挿入、または制約）、ならびに着信する変更のバージョン、および変更を送信するレプリカの知識である。本発明の一部の実施形態に関して、それぞれのそのような競合項目は、競合する変更のデータおよびメタデータ、競合の記述、ならびに変更適用側（ａｐｐｌｉｅｒ）情報、登録（ｅｎｌｉｓｔｍｅｎｔ）データ、およびリモートパートナ名などの他のコンテキスト情報を含む。さらに、変更データは、変更を適用するのに使用することができる形式で格納される。さらに、本発明の様々な実施形態に関して、Ｃｏｎｆｌｉｃｔから派生させられた各タイプは、競合のそのタイプに関係のある新たなフィールドを追加することができる。例えば、ＩｎｓｅｒｔＩｎｓｅｒｔＣｏｎｆｌｉｃｔタイプは、一意性制約に違反することを生じさせた項目の項目ＩＤを追加する。

本発明のいくつかの実施形態に関して、ログ記録されるべき競合項目には、競合項目の拡張として、または、単に、競合ログの中にやはり格納され、その項目と競合項目自体の間の関係が定義された別個の項目として、あるいは代替として、競合項目自体の一部（プロパティ値ペアのセットなどの）としての、目標項目のコピーも含まれる。競合ログ（永続するデータストア上に保持される）の中に競合項目の一部として、または競合項目と併せて格納されるこの目標項目は、最初に競合を生じさせた特定の変更を反映する。図４０は、典型的な連絡先項目を使用するこのアプローチを示すブロック図である。この実施例では、連絡先項目４００２（「目標項目」）は、最後の成功した同期の時点で、「ジョン」に最初に設定された名前フィールド４００４を含む。このフィールド４００４は、次に、ローカルシステムによってローカルで「ボブ」に変更される。後の同期中、この同一のフィールド４００４を「ジェーン」に変更しようとする試みにより、ローカルシステムが、「ボブ」または「ジェーン」のいずれの名前変更が適用されるべきか確認できないために、競合がもたらされた場合、ローカル変更（「ボブ」）が保持され、競合をもたらした変更（「ジェーン」）の適用を反映する連絡先項目４００２’のコピーとともに、競合４００６が競合ログ４００８の中にログ記録される。このようにして、競合ログは、競合を生じさせた完全な目標項目を含み、この特定の目標項目が、競合をもたらした、その項目に行われるように試みられた変更を反映するように更新される。

競合ログに競合を追加するのに、ログがまず、探索されて、同一の変更単位上に他の競合が存在するかどうかが判定される。同一の変更単位上に何らかの既存の競合が存在する場合、それらの競合が、除去の可能性に関して調べられる。既存の競合は、その競合の変更認識が、新たな競合の変更認識によって包含される場合、除去される。他方、新たな競合の変更認識が、既存のログ記録された競合の変更認識によって包含される場合、その新たな競合が破棄され、その逆も同様である（つまり、競合は、ストアが、変更を受け取り、その変更を適用することに成功して、その変更の認識が、その競合の認識を包含している場合のように、ストアの認識によってその競合の認識が包含される場合、陳腐化する（ｒｅｎｄｅｒｅｄｏｂｓｏｌｅｔｅ））。その２つの変更認識のいずれも他方を包含しない第３のケースでは、新たな競合は、ログに追加され、同一の変更単位に対応する両方の競合が、後に手動で、または自動的に解決されるまでログの中に存在する。

ｄ）競合の検査および解決
同期サービスは、競合ログを検査し、ログの中の競合の解決を示唆するＡＰＩをアプリケーションに提供する。ＡＰＩにより、アプリケーションが、すべての競合を列挙すること、または所与の項目に関連する競合を列挙することができるようになる。また、ＡＰＩにより、そのようなアプリケーションが、ログ記録された競合を次の３つの形の１つで解決することもできるようになる。すなわち、（１）リモート勝利−ログ記録された変更を受け入れ、競合するローカル変更に上書きすること、（２）ローカル勝利−ログ記録された変更の競合する部分を無視すること、および（３）新たな変更を示唆する−アプリケーションが、アプリケーションの見解において、競合を解決するマージを提案することである。競合がアプリケーションによって解決されると、同期サービスは、競合をログから除去する。

ｅ）レプリカの収束、および競合解決の伝播
複雑な同期シナリオにおいて、同一の競合が、複数のレプリカにおいて検出されることが可能である。これが生じた場合、次のとおり、いくつかのことが行われることが可能である。すなわち、（１）競合が、１つのレプリカ上で解決されることが可能であり、解決が、他のレプリカに送信される、（２）競合が、両方のレプリカ上で自動的に解決される、または（３）競合が、両方のレプリカ上で手動で解決される（競合検査ＡＰＩを介して）。

収束を確実にするため、同期サービスは、競合解決を他のレプリカに転送する。競合を解決する変更がレプリカに着信すると、同期サービスは、その更新によって解決されたログの中の競合レコードを自動的に探し出し、そのレコードを削除する。この意味で、１つのレプリカにおける競合解決は、他のすべてのレプリカにおいて拘束力を有する。

同一の競合に関して異なる勝者が異なるレプリカによって選択された場合、同期サービスは、拘束力を有する競合解決の原理を適用し、２つの解決の１つが、他方の解決に勝利するように自動的に選択する。勝者は、常時、同一の結果をもたらすことが保証されるように決定論的な形で選択される（１つの実施形態は、レプリカＩＤの辞書式比較を使用する）。

同一の競合に関して異なる「新たな変更」が異なるレプリカによって示唆された場合、同期サービスは、その新たな競合を特別な競合として扱い、競合ロガーを使用して、その競合が他のレプリカに伝播するのを防止する。そのような状況は、一般に手動の競合解決で生じる。

Ｆ．同期スキーマおよび競合処理スキーマのさらなる態様
以下は、本発明の様々な実施形態に関する同期スキーマのさらなる（または、より詳細な）態様である。
・各レプリカは、複数のインスタンスを有するデータのスライスである、データストア全体からのデータの定義された同期サブセットである
・同期スキーマのルートには、固有ＩＤを有するルートフォルダ（実際には、ルート項目）を定義する基礎タイプ、レプリカがメンバである同期コミュニティのＩＤ、ならびにどのようなものであれ、その特定のレプリカに必要な、または望ましいフィルタおよびその他の要素を有するレプリカが存在する
・各レプリカの「マッピング」は、そのレプリカ内に保持され、このため、いずれの特定のレプリカに関するマッピングも、そのレプリカが知っているその他のレプリカに限定される。このマッピングは、同期コミュニティ全体のサブセットだけしか含まない可能性があるが、前記レプリカに対する変更は、それでも、共通で共有されるレプリカを介して同期コミュニティ全体に伝播する（ただし、いずれの特定のレプリカも、未知のレプリカと他のいずれのレプリカを共通で共有しているのかを認識していない）
・レプリカの同期スキーマおよび使用により、真の分散型ピアツーピアマルチマスタ同期コミュニティが可能になる。さらに、同期コミュニティタイプは存在しないが、同期コミュニティは、単に、レプリカ自体のコミュニティフィールドの中の値として存在する
・すべてのレプリカは、増分変更列挙を追跡するため、および同期コミュニティ内で知られているその他のレプリカに関する状態情報を格納するための独自のメタデータを有する
・変更ユニットは、以下を含む独自のメタデータを有する。すなわち、パートナキーに加えて、パートナ変更番号を含むバージョン、各変更単位に関する項目／拡張／関係バージョニング（ｖｅｒｓｉｏｎｉｎｇ）、レプリカが経験した、同期コミュニティから受信した変更に関する知識、ＧＵＩＤおよびローカルＩＤの構成、およびクリーンアップのために参照関係上に格納されたＧＵＩＤである

以下は、本発明の様々な実施形態に関する競合処理スキーマのさらなる（またはより詳細な）態様である。
・競合解決ポリシーが、各レプリカ（およびアダプタ／データソースの組合せ）によって扱われる−つまり、各レプリカは、独自の基準および競合解決スキーマに基づいて競合を解決することができる。さらに、データストアの各インスタンスの相違は、さらなる将来の競合をもたらし、導く可能性があるが、更新された状態情報に反映された競合の増分の、順次の列挙は、その更新された状態情報を受信する他のレプリカには見えない
・同期スキーマは、すべてのレプリカが利用できる複数の事前定義された同期ハンドラと、ユーザ／開発者が定義したカスタム競合ハンドラの能力をともに含む。スキーマは、次の３つの特別な「競合ハンドラ」も含むことが可能である。すなわち、（ａ）例えば、（ｉ）同一の変更単位が２つの場所で変更された場合にどのように対処するか、（ｉｉ）変更単位が、１つの場所で変更されたが、別の場所で削除された場合にどのように対処するか、および（ｉｉｉ）２つの異なる変更単位が、２つの異なる場所で同一の名前を有する場合にどのように対処するかに基づき、異なる形で異なる競合を解決する競合「フィルタ」、（ｂ）競合がうまく解決されるまで、リストの各要素が、順に試みられるべき一連のアクションを指定する競合「ハンドラリスト」、および（ｃ）競合を追跡するが、ユーザの介入なしにさらなるアクションを行うことはしない「何もしない（ｄｏ−ｎｏｔｈｉｎｇ）」ログである

ＩＶ．仲介を介する同期
本明細書で説明する新たなストレージプラットフォームを最初に利用すると、様々な個々のコンピュータシステムを含む同期ネットワーク群を有する企業は、一部の個々のコンピュータシステムが、新たなストレージプラットフォームを利用する一方で、他の個々のコンピュータシステムは、レガシストレージプラットフォームを利用しつづけるという点で混合を有する可能性がある。これは、２つのクライアントが、新たなストレージプラットフォームを含むが、サーバは、レガシストレージプラットフォームを含むあらゆるクライアント−サーバ同期構造において、特に重要である。したがって、そのような状況では、新たなストレージプラットフォームを利用する２つのコンピュータシステム（「クライアント」）が、レガシストレージプラットフォーム（「仲介」）を利用するコンピュータシステムを介して同期することが必要である可能性がある。例えば、一部のクライアントは、ＲＵＰ（ローミングユーザプロファイル）またはＣＳＣ（ＦｏｌｄｅｒＲｅｄｉｒｅｃｔｉｏｎｗｉｔｈＣｌｉｎｅｔＳｉｄｅＣａｃｈｉｎｇ）などのソフトウェアを使用してレガシローミングサービスに登録される可能性がある。これらのレガシストレージプラットフォーム用のレガシローミングソフトウェアは、新たなストレージプラットフォームに関するローミングデータをサポートしないので、新たなストレージプラットフォーム用の新たなローミングサービスが必要である。本発明の様々な実施形態は、同一の共通ストレージプラットフォームを使用していない（例えば、代わりに、新たなストレージプラットフォームに関する同期をそれ自体、サポートしないレガシストレージプラットフォームを使用する）仲介を介して、共通のストレージプラットフォーム（例えば、関連する発明の新たなストレージプラットフォーム）をともに利用する２つのクライアントの同期のためのシステムおよび方法を対象とする。

Ａ．仲介に関するデータの構造
本発明のいくつかの実施形態は、レプリカクライアントと非レプリカの仲介の間に存在し、動作するＳＴＩ（「仲介を介する同期」）アダプタを対象とする。それらの実施形態に関して、ＳＴＩアダプタは、レプリカクライアントから非レプリカの仲介へ、変更列挙の結果をシリアル化するとともに、非レプリカの仲介からレプリカクライアントへ、それらの変更結果をシリアル化解除するように設計される。

図４１は、２つのクライアントが仲介を介して同期しなければならないシナリオを示すブロック図である。この図では、レガシストレージプラットフォーム（例えば、Ｗｉｎ３２）を利用する仲介コンピュータシステム４１０２が、新たなストレージプラットフォーム（例えば、以降、便宜上、「ＷｉｎＬＨ」と呼ぶ、本明細書で説明する関連する発明の実施形態、ＷｉｎＬＨは、図示するとおり、本明細書でＷｉｎＦＳファイルシステムと呼ぶ物を含む）をともに利用するクライアントＡ４１１２とクライアントＢ４１１４の両方に接続される。仲介４１０２は、クライアントＡ４１１２からクライアントＢ４１１４に同期され、またその逆にも同期される変更に関する単なる「パススルー（ｐａｓｓ−ｔｈｒｏｕｇｈ）」と考えることができる。このため、仲介４１０２は、独自の目的で自らをクライアントＡ４１１２またはクライアントＢ４１１４と「同期させる」ことはなく、このため、仲介４１０２は、仲介４１０２がクライアントＡ４１１２またはクライアントＢ４１１４から受信するデータを直接に利用することも、変更することもしない。この理由で、本明細書で上記に利用した用語を利用すると、仲介４１０２は、レプリカではない。ただし、レプリカであるクライアントＡ４１１２とクライアントＢ４１１４はともに、ＳＴＩ（仲介を介する同期）アダプタを介して、あたかも仲介４１０２がレプリカであるかのように、仲介４１０２と対話する。

クライアントＡ４１１２およびクライアントＢ４１１４は、それぞれＳＴＩアダプタ４１２２およびＳＴＩアダプタ４１２４を介して仲介４１０２とインターフェースをとり、前記ＳＴＩアダプタは、クライアント４１１２および４１１４の新たなストレージプラットフォームと、仲介４１０２の特定のレガシプラットフォームの間でインターフェースをとるように特に仕立てられている。本発明のいくつかの代替の実施形態は、仲介が同期する必要がある可能性があるいくつかのレガシストレージプラットフォームに対応するいくつかの特定のＳＴＩアダプタを対象とする。これは、クライアント４１１２および４１１４が、それでも、あたかも仲介４１０２が真のレプリカであるかのように、仲介４１０２と（ＳＴＩアダプタ４１２２および４１４４を介して）論理的に同期することを可能にする。ただし、現実には、同期を成功させるのは、クライアントにローカルなアダプタである。

レプリカクライアントから非レプリカの仲介へ、変更列挙の結果をシリアル化することに関して、それぞれのシリアル化は、仲介に書き込まれるべきファイルのトリプレットにシリアル化される変更のバッチに相当する。一部の実施形態に関して、それらのファイルは、特定の同期コミュニティに対応する特定のフォルダ（「コミュニティフォルダ」）に書き込まれ、異なる同期コミュニティは、異なるコミュニティフォルダを有する。ファイルの前述したトリプレットには、ＣＤＦ（変更データファイル）、ＰＫＦ（前提条件知識ファイル）、およびＬＫＦ（学習された知識ファイル）が含まれる。ＣＤＦは、変更単位レベルにおけるＷｉｎＦＳ項目に対する特定の変更に関係する情報を含む。ＰＫＦは、関連する変更を適用するために、同期ピアが何を既に知っていなければならないかを指定する。他方、ＬＫＦは、同期ピアが、関連する変更を適用した場合、何を学習することになるかを指定する。効率のため、ピアツーピア同期と同様に、ＳＴＩアダプタは、変更単位情報（「変更された部分」、および関連するメタデータ）だけをシリアル化し、いくつかの実施形態に関して、このデータは、項目タイプ、項目バージョン番号、変更単位バージョン、および変更されたプロパティの値だけを含む（項目に対する特定の変更に関して）ことが可能である。様々な実施形態に関して、ファイルのトリプレットは、（本明細書で後に説明する理由で）シリアル化のメッセージシーケンスに基づく順次名前付け規約を使用して仲介に書き込まれる。例えば、第１のシリアル化は、仲介上に１．ＰＫＦ（ＰＫＦファイル）、１．ＣＤＦ（ＣＤＦファイル）、および１．ＬＦＫ（ＬＫＦファイル）として格納された３つのファイルを含むことが可能であり、第２のシリアル化は、２．ＰＫＦ、２．ＣＤＦ、および２ＬＫＦを含むことが可能であり、以下同様である。

Ｂ．ＳＴＩアダプタプロセス
本発明のいくつかの実施形態に関して、ＳＴＩアダプタは、次の３つのコア操作を含む。すなわち、同期送信、同期受信、およびデータコンパクションである。

１．同期送信操作
図４２は、クライアントが、ＳＴＩアダプタを介して、変更データを仲介に送信するステップ（「同期送信」操作）を示す流れ図である。ステップ４２０２で、ＳＴＩアダプタはまず、クライアントの同期コミュニティに対応する仲介上にコミュニティフォルダが存在するかどうかを確かめる。存在する場合、ステップ４２０４で、ＳＴＩアダプタは、仲介のコミュニティフォルダ内のＬＫＦの内容のすべてをスキャンし、シリアル化解除して、その同期コミュニティに関するＩＬＫ（仲介のローカル知識）の現在の状態を確かめる。他方、コミュニティフォルダが存在しない場合、ＩＬＫは、ステップ４２０６でＮＵＬＬであると考えられ、仲介上でコミュニティフォルダが作成される。

ステップ４２０８で、ＳＴＩアダプタは、他のクライアント（または他のピアもしくは他のプロセス）が、同期送信操作の期間中にコミュニティフォルダに対して読み取りまたは書き込みを行うのを防止することにより、データ整合性を保つために仲介のコミュニティフォルダに対する「書き込みモード」プロセスロックを（仲介のファイルシステムを介して）同時に獲得する。次に、ステップ４２１０で、ＳＴＩアダプタは、ＩＬＫをクライアントに通信する。ＩＬＫ、および独自のＣＬＫ（クライアントローカル知識）に基づき、ステップ４２１２で、クライアントは、ＩＬＫの範囲に含まれない変更が存在するかどうかを判定し、存在しない場合、プロセスは、ステップ４２２０に飛ぶ。他方、クライアントが、ＩＬＫの範囲に含まれない変更が存在すると判定した場合、ステップ４２１４で、ＩＬＫの範囲に含まれない列挙された変更を準備し、それらの変更をＳＴＩアダプタに送る。ステップ４２１６で、ＳＴＩアダプタは、変更情報（変更データおよび知識）の各バッチをシリアル化し、次に、ステップ４２１８で、ＳＴＩアダプタは、シリアル化された変更バッチを、前述したとおり、順次に増加するファイルのトリプレットとして仲介のコミュニティフォルダに書き込む。シリアル化された変更済みバッチのすべてが仲介に書き込まれると、次に、ステップ４２２０で、ＳＴＩアダプタは、「書き込みモード」プロセスロックを解放して、他のクライアント（または他のピアもしくは他のプロセス）が、仲介上の更新された内容を検査することができるようにする。

同期送信操作は完了したが、ＳＴＩアダプタは、後の参照（以下に説明する）のために、仲介に書き込まれた最後のＨＣＴ（最高の順次に増加する変更トリプレット）のＩＤ（参照番号）を格納することに留意されたい。また、同期送信操作の一環として、競合処理はまったく実行されないことにも留意されたい。最後に、クライアントが、データを「プル（ｐｕｌｌ）」するだけの（したがって、クライアントは、同期送信操作を開始しない）ピアツーピア実施形態に関して、仲介が、同期送信操作を開始するための機能を有さないものと想定すると、ＳＴＩアダプタが、仲介に代行して自発的に（ｏｎｉｔ’ｓｏｗｎａｃｃｏｒｄ）同期送信操作を開始することができる。

２．同期受信操作
反対方向の同期に関して、図４３は、クライアントが、ＳＴＩアダプタを介して、仲介から変更データを受信するステップ（「同期受信」操作）を示す流れ図である。ステップ４３０２で、ＳＴＩアダプタはまず、ＣＬＫ（クライアントローカル知識）を受け取り、これは、本発明のいくつかの実施形態に関して、クライアントがＳＴＩアダプタを介して同期要求を仲介に送信した際に行われ、前記同期要求は、本来的に、本明細書で前述したピアツーピア同期スキーム別のＣＬＫを含む。次に、ステップ４３０４で、ＳＴＩアダプタは、他のクライアント（または他のピアもしくは他のプロセス）が、同期受信操作の期間中にコミュニティフォルダに対して書き込みを行うのを防止する（ただし、一部の実施形態に関して、読み取りを行うのは防止しない）ことにより、データ整合性を保つために仲介のコミュニティフォルダに対する「読み取りモード」プロセスロックを（仲介のファイルシステムを介して）獲得する。一部の実施形態に関して、この「読み取りモード」は、より良好な同時性（ｃｏｎｃｕｒｒｅｎｃｙ）のためにディレクトリ全体ではなく、各トリプレットをロックするように最適化されることも可能である。

ステップ４３０６で、その仲介に関してＳＴＩアダプタによって格納されたＨＣＴ（例えば、前述したとおり、同期送信操作によってもたらされたことが可能な）に関して、ＳＴＩアダプタは、（ａ）ＨＣＴより高い順序であり、（ｂ）ＣＬＫ（クライアントローカル知識）が、その変更トリプレットに関する前提条件知識（ＰＫＦからの）より多く、（ｃ）ＣＬＫが、その変更トリプレットに関する学習された知識（ＬＫＦからの）より少ない次に高い変更トリプレットを求めて、仲介上のコミュニティフォルダをスキャンする。（そのような変更トリプレットは、本明細書で「適用可能な変更トリプレット」または「ＡＣＴ」と呼ばれる。）ステップ４３０８で、そのような変更トリプレット（ＡＣＴ）が存在する場合、ステップ４３１０で、同期アダプタは、その変更トリプレット（ＡＣＴ）の内容をシリアル化解除して、レプリカが理解可能な列挙された変更にし、ステップ４３１２で、その変更を処理のためにクライアントに送信する。次に、プロセスは、次のＡＣＴを求めてステップ４３０６に戻り、プロセスは、残りがまったくなくなるまで続けられ、まったくなくなった時点で、ＳＴＩアダプタは、ステップ４３１４で読み取りモードをロック解除し、プロセスは、終了する。

３．仲介ファイルデータ圧縮／コンパクション（ｃｏｍｐａｃｔｉｏｎ）
本発明の様々な実施形態に関して、ＳＴＩアダプタによって作成されるシリアル化されたデータファイル、および知識ファイルを定常的に（ｒｏｕｔｉｎｅｌｙ）圧縮することが必要である。そうでなければ、増えつづける変更トリプレットが、仲介上のすべての利用可能なストレージスペースを一杯にする。これに関して、データコンパクションの目標は、データファイルおよび知識ファイルの成長が、仲介上で適切な形で限られることを確実にすることである。本発明のいくつかの実施形態によって使用される１つの方法は、共有ファイルシステム上に存在することが許される変更パケットの数に「上限（ｕｐｐｅｒ−ｔｈｒｅｓｈｏｌｄ）」を設定することであり、その閾値を超えると、そうすることができる次のＳＴＩアダプタが、コンパクション操作を介して仲介上の共有ファイルシステム（コミュニティフォルダ内のファイル群）を圧縮するように要求される。コンパクション操作は、（ａ）既存の個々のオブジェクトに関する変更履歴を圧縮すること、および（ｂ）削除されたオブジェクトに関してブロードキャストされた変更を除去すること（明示的に、競合解決を介して、または削除標識クリーンアップの結果として）によって共有ファイルシステムの中に格納されるデータの量を減らす。しかし、コンパクションは、同期受信を実行したばかりであり、「完全な」同期送信（つまり、あたかも仲介上にまったくコミュニティフォルダが存在しないかのように、０のベースラインを有する完全な変更列挙）を即時に実行することができるクライアントに関してだけしか、ＳＴＩアダプタによって実行されることが可能でない。このため、コンパクションは、仲介を使用して同期を送信するだけ、または同期を受信するだけのクライアントによっては実行されることが不可能である。

図４４は、ＳＴＩアダプタ（つまり、同期を送信することと、同期を受信することがともにできるクライアントに関連するＳＴＩアダプタ）が、仲介上のコミュニティフォルダ内のデータに関する圧縮操作（「コンパクション」操作）を実行するステップを示す流れ図である。この図では、ステップ４４０２におけるＳＴＩアダプタのクライアントに関する同期受信の成功の直後に、ただし、「読み取りモード」プロセスロックを解放する前に（すなわち、図４３のステップ４３１２直後、ただし、ステップ４３１４の前に）、ステップ４４０４で、ＳＴＩアダプタが、仲介上のコミュニティフォルダを調べて、上限を超えていないかどうかを確かめる。超えていない場合、プロセスは、終了する（また、同期受信プロセスが、ロックを解放することなどによって完了する）。しかし、上限を超えている場合は、ステップ４４０６で、ＳＴＩアダプタが、仲介のコミュニティフォルダ内の変更トリプレットファイルのすべてを削除し、次に、ステップ４４０８で、ＳＴＩアダプタは、仲介の知識がクライアントに対してＮＵＬＬである（これは、削除後、実際に該当する）と示すことにより、クライアントと仲介の間の完全な同期読み取り操作（書き込みモードプロセスロックを含む）を開始することに取りかかる。この結果、クライアントの状態全体に対応するトリプレットファイルの最小セットが仲介にアップロードされ、仲介上に存在する。

より良好な同時性のためにディレクトリ全体ではなく、各トリプレットをロックするように「読み取りモード」が最適化されている諸実施形態、および標準の「読み取りモード」を使用する本発明の他の代替の諸実施形態に関して、ＳＴＩアダプタが、仲介のコミュニティフォルダに対する「読み取りモード」プロセスロックを獲得する（仲介のファイルシステムを介して）（図４３のステップ４３０４で）前に、コンパクションが必要とされているかどうかを確認し、コンパクションが必要とされている場合、他のクライアント（または他のピアもしくは他のプロセス）が、同期受信操作の期間中にコミュニティフォルダに対して書き込むのを防止する（ただし、一部の実施形態に関して、読み取りを行うことは防止しない）ことにより、データ完全性を保つために標準の（最適化されていない）「読み取りモード」を使用するという点で、プロセスは、わずかに異なる。

一部の代替の実施形態に関して、仲介上のデータは、既存の変更トリプレットに、最初のトリプレットから始めて、上書きを行うことにより、クライアントがすべての変更トリプレットをアップロードするまで、削除されず、すべての変更トリプレットがアップロードされ（また、古いトリプレットが書き換えられる）ると、完全な同期読み取り中にアップロードされた最後のトリプレットより高いシーケンス番号の、すべての残っている変更トリプレットが削除される。

最後に、一部の代替の実施形態は、完全な同期受信操作が完了した（読み取りモードプロセスロックの解除を含む）後にも、コンパクションを開始する。そのような実施形態の場合、プロセスは、書き込みモードプロセスブロックから始め、次に、前述したステップのすべてを実行することに取りかかる。

Ｃ．ＳＴＩおよびダウンレベルクライアントサポート
以上に加えて、本発明のいくつかのさらなる実施形態は、本明細書で前述した仲介を介する同期技術の変種を対象とする。一部の実施形態は、レガシストレージプラットフォームも実行しているクライアントをさらに含むシステムを対象とし、前記「レガシクライアント」は、すべてのデータファイルにアクセスすることもできる。一部のレガシクライアント、およびその他のアプリケーションおよびプロセスが、他の目的で、それらのデータファイルにアクセスできることも見込まれている。例えば、作成の日付、または他の何らかの本来的なファイル特性に基づいてファイルを同期させるレガシクライアントに関して。別の例は、ファイルのいずれか、またはすべて（例えば、^＊．ＣＤＫファイル）に直接にアクセスし、そのファイルをコピーするレガシクライアントである。多くの点で、レガシクライアントは、第１の仲介と直接に通信する（おそらく、レガシ同期技術を使用して）第２の仲介と同じように考えることができる。

Ｖ．結論
以上に示すとおり、本発明は、データの編成、探索、および共有を行うためのストレージプラットフォームを対象とする。本発明のストレージプラットフォームは、既存のファイルシステムおよびデータベースシステムを超えてデータストレージの概念を拡張し、広げ、リレーショナル（表形式の（ｔａｂｕｌａｒ））データ、ＸＭＬ、および項目と呼ばれる新たな形態のデータなどの、構造化データ、非構造化データ、または半構造化データを含むすべてのタイプのデータ用のストアとなるように設計される。共通のストレージの基礎、およびスキーマ化されたデータを介して、本発明のストレージプラットフォームは、消費者、知識労働者、および企業のためのより効率的なアプリケーション開発を可能にする。本発明のストレージプラットフォームは、本発明のストレージプラットフォームのデータモデルに固有の諸機能を利用可能にするだけでなく、既存のファイルシステムおよびデータベースアクセス方法を取り入れ、拡張することも行う、豊かで拡張可能なアプリケーションプログラミングインターフェースを提供する。諸実施形態の広い発明上の概念を逸脱することなく、前述した諸実施形態に様々な変更を行うことができることを理解されたい。したがって、本発明は、開示した特定の実施形態に限定されず、添付の特許請求の範囲によって定義される本発明の趣旨および範囲に含まれるすべての変更形態を範囲に含むものとする。

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

本発明の諸態様を組み込むことができるコンピュータシステムを表すブロック図である。３つのコンポーネントグルＩープ、すなわち、ハードウェアコンポーネント、ハードウェア／ソフトウェアインターフェースシステムコンポーネント、およびアプリケーションプログラムコンポーネントに分けられたコンピュータシステムを示すブロック図である。ファイルベースのオペレーティングシステムにおけるディレクトリ内のフォルダの中でグループ化されたファイルの、従来のツリーベースの階層構造を示す図である。ストレージプラットフォームを示すブロック図である。項目、項目フォルダ、およびカテゴリの間の構造上の関係を示す図である。項目の構造を示すブロック図である。図５Ａの項目の複雑プロパティタイプを示すブロック図である。「場所」項目を示し、「場所」項目の複雑タイプがさらに表された（明示的にリストアップされた）ブロック図である。基礎スキーマの中で見られる項目のサブタイプとして項目を示す図である。図６Ａのサブタイプ項目を示し、サブタイプ項目の継承されたタイプが明示的にリストアップされた（サブタイプ項目の直属のプロパティに加えて）ブロック図である。２つの最上レベルクラスタイプ、項目およびＰｒｏｐｅｒｔｙＢａｓｅ、ならびにそれらから同期されたさらなる基礎スキーマタイプを含む基礎スキーマを示すブロック図である。コアスキーマの中の項目を示すブロック図である。コアスキーマの中のプロパティタイプを示すブロック図である。項目フォルダ、項目フォルダのメンバ項目、ならびに項目フォルダと項目フォルダのメンバ項目の間における互いに結合する関係を示すブロック図である。カテゴリ（やはり、項目自体である）、カテゴリのメンバ項目、ならびにカテゴリとカテゴリのメンバ項目の間における互いに結合する関係を示すブロック図である。ストレージプラットフォームのデータモデルの参照タイプ階層を示すブロック図である。どのように関係が分類されるかを示す図である。通知メカニズムを示す図である。２つのトランザクションがともに、新たなレコードを同一のＢツリーの中に挿入する実施例を示す図である。データ変更検出プロセスを示す図である。典型的なディレクトリツリーを示す図である。ディレクトリベースのファイルシステムの既存のフォルダがストレージプラットフォームデータストアの中に移動される実施例を示す図である。含有フォルダの概念を示す図である。ストレージプラットフォームＡＰＩの基本的なアーキテクチャを示す図である。ストレージプラットフォームＡＰＩスタックの様々なコンポーネントを概略で表す図である。典型的な連絡先項目スキーマを示す図である。図２１Ａの典型的な連絡先項目スキーマに関する要素を示す図である。ストレージプラットフォームＡＰＩのランタイムフレームワークを示す図である。「ＦｉｎｄＡＬＬ」操作の実行を示す図である。ストレージプラットフォームＡＰＩクラスがストレージプラットフォームスキーマから生成されるプロセスを示す図である。ファイルＡＰＩが基づくスキーマを示す図である。データセキュリティ目的のために使用されるアクセスマスク形式を示す図である。新たな同一の保護されたセキュリティ領域が既存のセキュリティ領域から切り出されているのを示す図（パートａ、パートｂ、およびパートｃ）である。項目探索ビューの概念を示す図である。典型的な項目階層を示す図である。第１のコードセグメントと第２のコードセグメントが通信するコンジット（ｃｏｎｄｕｉｔ）としてインターフェース、Ｉｎｔｅｒｆａｃｅ１を示す図である。システムの第１のコードセグメントと第２のコードセグメントが媒体Ｍを介して通信することを可能にするインターフェースオブジェクトＩ１およびＩ２を含むものとしてインターフェースを示す図である。インターフェース、Ｉｎｔｅｒｆａｃｅ１によって提供される機能をどのように細分して、インターフェースの通信を複数のインターフェース、Ｉｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃにすることができるかを示す図である。インターフェースＩ１によって提供される機能をどのように細分して、複数のインターフェース、Ｉ１ａ、Ｉ１ｂ、Ｉ１ｃにすることができるかを示す図である。有意なパラメータプレシジョン（ｐｒｅｃｉｓｉｏｎ）を無視する、または任意のパラメータで置き換えることができるシナリオを示す図である。インターフェースが、パラメータを無視する、またはパラメータをインターフェースに追加するように定義された代用インターフェースで置き換えられるシナリオを示す図である。第１のコードセグメントと第２のコードセグメントがマージされて、両方を含むモジュールになるシナリオを示す図である。インターフェースの一部または全部が、別のインターフェースにインライン（ｉｎｌｉｎｅ）で書き込まれて、マージされたインターフェースを形成することが可能なシナリオを示す図である。１つまたは複数のミドルウェアが、どのように第１のインターフェース上の通信を変換して、１つまたは複数の異なるインターフェースに適合させることができるかを示す図である。１つのインターフェースからの通信を受け取るが、機能を第２のインターフェースおよび第３のインターフェースに送るコードセグメントを、インターフェースを使用してどのように導入することができるかを示す図である。ＪＩＴ（ジャストインタイムコンパイラ）が、どのように１つのコードセグメントからの通信を別のコードセグメントに変換することができるかを示す図である。１つまたは複数のインターフェースを動的に書き換えるＪＩＴメソッドを適用して、前記インターフェースを動的にファクタする、またはそれ以外で変更できることを示す図である。一般的なデータストアの３つのインスタンス、およびそれらのインスタンスを同期させるためのコンポーネントを示す図である。状態がどのように計算されるか、または関連するメタデータがどのように交換されるかを知らない単純なアダプタを想定する、関連する発明を含むシステムである。例外を強調、および例外に対する解決を強調するのに逐次変更列挙方法を使用して、どのように変更が追跡され、列挙され、同期されるかを示す図である。例外を強調、および例外に対する解決を強調するのに逐次変更列挙方法を使用して、どのように変更が追跡され、列挙され、同期されるかを示す図である。例外を強調、および例外に対する解決を強調するのに逐次変更列挙方法を使用して、どのように変更が追跡され、列挙され、同期されるかを示す図である。例外を強調、および例外に対する解決を強調するのに逐次変更列挙方法を使用して、どのように変更が追跡され、列挙され、同期されるかを示す図である。競合処理パイプラインを示す図である。図３９Ａに示したパイプラインの論理的トラバース（ｔｒａｖｅｒｓａｌ）を示す流れ図である。競合項目が、目標項目のコピーとともにログ記録される実施例を示すブロック図である。２つのクライアントが、仲介を介して同期しなければならないシナリオを示すブロック図である。クライアントが、ＳＴＩアダプタを介して、変更データを仲介に送信する（「同期送信」操作）ステップを示す流れ図である。クライアントが、ＳＴＩアダプタを介して、仲介からデータを受信する（「同期受信」操作）ステップを示す流れ図である。ＳＴＩアダプタ（つまり、同期送信と同期受信をともに行うことができるクライアントに関連するＳＴＩアダプタ）が、仲介上のコミュニティフォルダ内のデータに関するコンパクション操作（「コンパクション」操作）を実行するステップを示す流れ図である。

Claims

第１のストレージプラットフォームを利用する少なくとも２つのクライアントコンピュータシステムを、第２のストレージプラットフォームを利用する仲介コンピュータシステムを介して同期させるための方法であって、前記第２のストレージプラットフォームは、前記第１のストレージプラットフォームに関する同期をサポートせず、
第１のクライアントコンピュータシステム上に存在する第１の同期アダプタが、変更情報を前記仲介コンピュータシステムに送信するステップと、
第２のクライアントコンピュータシステム上に存在する第２の同期アダプタアダプタが、前記仲介コンピュータシステムから前記変更情報を受信して、前記第２のクライアントコンピュータシステムに送信するステップと
を含み、前記変更情報を前記仲介コンピュータシステムに送信するステップは、
前記第１の同期アダプタが、前記少なくとも２つのコンピュータシステムが同期するコミュニティフォルダが前記仲介コンピュータシステムに存在するかどうか判定するステップと、
前記コミュニティフォルダが存在する場合、前記第１の同期アダプタが、前記コミュニティフォルダをスキャンして、前記仲介コンピュータシステムのローカル知識を確認するステップと、
前記コミュニティフォルダが存在しない場合、前記第１の同期アダプタが、前記仲介コンピュータシステム上にコミュニティフォルダを作成するステップと、
前記第１の同期アダプタが、前記仲介コンピュータシステムのローカル知識を前記第１のクライアントコンピュータシステムに送信するステップと、
前記第１のクライアントコンピュータシステムが、前記仲介コンピュータシステムのローカル知識に含まれない変更を有する場合、前記仲介コンピュータシステムのローカル知識に含まれない変更のセットを準備して、前記第１の同期アダプタに送信するステップと、
前記第１の同期アダプタが、前記変更のセットをファイルにシリアル化して、前記コミュニティフォルダに書き込むステップと
を含むことを特徴とする方法。
前記同期は、データ共有操作をサポートするのに利用されることを特徴とする請求項１に記載の方法。
前記同期は、エンドユーザローミングをサポートするのに利用されることを特徴とする請求項１に記載の方法。
前記第１のストレージプラットフォームは、項目ベースのストレージプラットフォームであることを特徴とする請求項１に記載の方法。
前記ファイルは、変更データに関するファイル、前提条件知識に関するファイル、および学習された知識に関するファイルの少なくとも１つまたは複数を含むことを特徴とする請求項１に記載の方法。
前記変更情報を前記仲介コンピュータシステムに送信するステップは、
前記第１の同期アダプタが、前記コミュニティフォルダに対する書き込みモードプロセスロックを獲得するステップと、
前記第１の同期アダプタが、書き込みモードプロセスロックを解放するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
前記変更情報を前記第２のクライアントコンピュータシステムに送信するステップは、
前記第２の同期アダプタが、前記第２のクライアントコンピュータシステムのローカル知識を受信するステップと、
前記第２の同期アダプタが、前記第２のクライアントコンピュータシステムのローカル知識に適用可能なファイルを求めて、前記コミュニティフォルダをスキャンするステップと、
前記適用可能なファイルが存在する場合、前記第２の同期アダプタが、前記適用可能なファイルをシリアル化解除して、変更のセットに変更するステップと
を含むことを特徴とする請求項１に記載の方法。
前記変更情報を前記第２のクライアントコンピュータシステムに送信するステップは、
前記第２の同期アダプタが、前記コミュニティフォルダに対する読み取りモードプロセスロックを獲得するステップと、
前記第２の同期アダプタが、読み取りモードプロセスロックを解放するステップと
をさらに含むことを特徴とする請求項７に記載の方法。
前記変更情報を前記第２のクライアントコンピュータシステムに送信するステップは、読み取りモードプロセスロックを解放する前に、
前記第２の同期アダプタが、前記コミュニティフォルダ内のすべてのファイルを削除するステップと、
前記第２の同期アダプタが、変更情報を前記仲介コンピュータシステムに送信するステップを実行するステップと
をさらに含むことを特徴とする請求項８に記載の方法。
第１のストレージプラットフォームを利用する少なくとも２つのクライアントコンピュータシステムを、第２のストレージプラットフォームを利用する仲介コンピュータシステムを介して同期させるためのシステムであって、前記第２のストレージプラットフォームは、前記第１のストレージプラットフォームに関する同期をサポートせず、
変更情報を前記仲介コンピュータシステムに送信する第１の同期アダプタを有する第１のクライアントコンピュータシステムと、
前記仲介コンピュータシステムから前記変更情報を受信する第２の同期アダプタを有する第２のクライアントコンピュータシステムと
を含み、
前記第１の同期アダプタは、
前記少なくとも２つのコンピュータシステムが同期するコミュニティフォルダが前記仲介コンピュータシステムに存在するかどうか判定し、
前記コミュニティフォルダが存在する場合、前記コミュニティフォルダをスキャンして、前記仲介コンピュータシステムのローカル知識を確認し、
前記コミュニティフォルダが存在しない場合、前記仲介コンピュータシステム上にコミュニティフォルダを作成し、
前記仲介コンピュータシステムのローカル知識を前記第１のクライアントコンピュータシステムに送信し、
前記第１のクライアントコンピュータシステムから受信した変更のセットをファイルにシリアル化して、前記コミュニティフォルダに書き込み、
前記第１のクライアントコンピュータシステムは、
前記仲介コンピュータシステムのローカル知識に含まれない変更を有する場合、前記仲介コンピュータシステムのローカル知識に含まれない変更のセットを準備して、前記第１の同期アダプタに送信することを特徴とするシステム。
前記同期は、データ共有操作をサポートするのに利用されることを特徴とする請求項１０に記載のシステム。
前記同期は、エンドユーザローミングをサポートするのに利用されることを特徴とする請求項１０に記載のシステム。
前記第１のストレージプラットフォームは、項目ベースのストレージプラットフォームとなることを特徴とする請求項１０に記載のシステム。
前記ファイルは、変更データに関するファイル、前提条件知識に関するファイル、および学習された知識に関するファイルの少なくとも１つまたは複数を含むことを特徴とする請求項１０に記載のシステム。
前記第１の同期アダプタは、前記コミュニティフォルダに対する書き込みモードプロセスロックを獲得または解放することを特徴とする１０に記載のシステム。
前記第２の同期アダプタは、
前記第２のクライアントコンピュータシステムのローカル知識を受信し、
前記第２のクライアントコンピュータシステムのローカル知識に適用可能なファイルを求めて、前記コミュニティフォルダをスキャンし、
前記適用可能なファイルが存在する場合、前記適用可能なファイルをシリアル化解除して、変更のセットに変更することを特徴とする請求項１０に記載のシステム。
前記第２の同期アダプタは、前記コミュニティフォルダに対する読み取りモードプロセスロックを獲得または解放することを特徴とする請求項１６に記載のシステム。
前記第２の同期アダプタは、読み取りモードプロセスロックを解放する前に、
前記コミュニティフォルダ内のすべてのファイルを削除し、変更情報を前記仲介コンピュータシステムに送信することを特徴とする請求項１７に記載のシステム。
第１のストレージプラットフォームを利用する少なくとも２つのクライアントコンピュータシステムを、第２のストレージプラットフォームを利用する仲介コンピュータシステムを介して同期させるための方法を実施するプログラムを記録したコンピュータ可読記録媒体であって、前記第２のストレージプラットフォームは、前記第１のストレージプラットフォームに関する同期をサポートせず、前記方法は、
第１のクライアントコンピュータシステム上に存在する第１の同期アダプタが、変更情報を前記仲介コンピュータシステムに送信するステップと、
第２のクライアントコンピュータシステム上に存在する第２の同期アダプタアダプタが、前記仲介コンピュータシステムから前記変更情報を受信して、前記第２のクライアントコンピュータシステムに送信するステップと
を含み、前記変更情報を前記仲介コンピュータシステムに送信するステップは、
前記第１の同期アダプタが、前記少なくとも２つのコンピュータシステムが同期するコミュニティフォルダが前記仲介コンピュータシステムに存在するかどうか判定するステップと、
前記コミュニティフォルダが存在する場合、前記第１の同期アダプタが、前記コミュニティフォルダをスキャンして、前記仲介コンピュータシステムのローカル知識を確認するステップと、
前記コミュニティフォルダが存在しない場合、前記第１の同期アダプタが、前記仲介コンピュータシステム上にコミュニティフォルダを作成するステップと、
前記第１の同期アダプタが、前記仲介コンピュータシステムのローカル知識を前記第１のクライアントコンピュータシステムに送信するステップと、
前記第１のクライアントコンピュータシステムが、前記仲介コンピュータシステムのローカル知識に含まれない変更を有する場合、前記仲介コンピュータシステムのローカル知識に含まれない変更のセットを準備して、前記第１の同期アダプタに送信するステップと、
前記第１の同期アダプタが、前記変更のセットをファイルにシリアル化して、前記コミュニティフォルダに書き込むステップと
を含むことを特徴とするコンピュータ可読記録媒体。
前記同期が、データ共有操作をサポートするのに利用されることを特徴とする請求項１９に記載のコンピュータ可読記録媒体。
前記同期が、エンドユーザローミングをサポートするのに利用されることを特徴とする請求項１９に記載のコンピュータ可読記録媒体。
前記第１のストレージプラットフォームが、項目ベースのストレージプラットフォームであることを特徴とする請求項１９に記載のコンピュータ可読記録媒体。
前記ファイルは、変更データに関するファイル、前提条件知識に関するファイル、および学習された知識に関するファイルの少なくとも１つまたは複数を含むことを特徴とする請求項１９に記載のコンピュータ可読記録媒体。
前記変更情報を前記仲介コンピュータシステムに送信するステップは、
前記第１の同期アダプタが、前記コミュニティフォルダに対する書き込みモードプロセスロックを獲得するステップと、
前記第１の同期アダプタが、書き込みモードプロセスロックを解放するステップと
をさらに含むことを特徴とする請求項１９に記載のコンピュータ可読記録媒体。
前記変更情報を前記第２のクライアントコンピュータシステムに送信するステップは、
前記第２の同期アダプタが、前記第２のクライアントコンピュータシステムのローカル知識を受信するステップと、
前記第２の同期アダプタが、前記第２のクライアントコンピュータシステムのローカル知識に適用可能なファイルを求めて、前記コミュニティフォルダをスキャンするステップと、
前記適用可能なファイルが存在する場合、前記第２の同期アダプタが、前記適用可能なファイルをシリアル化解除して、変更のセットに変更するステップと
を含むことを特徴とする請求項１９に記載のコンピュータ可読記録媒体。
前記変更情報を前記第２のクライアントコンピュータシステムに送信するステップは、
前記第２の同期アダプタが、前記コミュニティフォルダに対する読み取りモードプロセスロックを獲得するステップと、
前記第２の同期アダプタが、読み取りモードプロセスロックを解放するステップと
をさらに含むことを特徴とする請求項２５に記載のコンピュータ可読記録媒体。
前記変更情報を前記第２のクライアントコンピュータシステムに送信するステップは、読み取りモードプロセスロックを解放する前に、
前記第２の同期アダプタが、前記コミュニティフォルダ内のすべてのファイルを削除するステップと、
前記第２の同期アダプタが、変更情報を前記仲介コンピュータシステムに送信するステップを実行するステップと
をさらに含むことを特徴とする請求項２６に記載のコンピュータ可読記録媒体。