JP2007509428A - ユーザにアイテムをコンテクスト表示（ｃｏｎｔｅｘｔｕａｌｐｒｅｓｅｎｔａｔｉｏｎ）で提示するためのシステムおよび方法 - Google Patents

Abstract

ユーザに複数のアイテムを、文脈的な提示手法（contextual display）で提示するためのシステムおよび方法。データ・ストアを含むコンピュータ・システムが提供される。データ・ストア内のアイテムのうちの少なくとも一部は、１つまたは複数のフィールド・エントリを含む。エクスプローラは、データ・ストアと対話し、１つまたは複数の所望するフィールド・エントリを有するアイテムを選択し、選択されたアイテムをエクスプローラ表示スキーマに従って表示する。アプリケーションは、データ・ストアからアイテムを選択することができ、またシェル・ブラウザと対話して、選択されたアイテムを提示することができる。データ・ストア内のアイテムをユーザに提示するためのエクスプローラを確立するための方法。

Description

本発明は、一般には、コンピュータ・ソフトウェアの分野に関する。より詳細には、本発明は、コンピュータ内に格納されたアイテムをユーザに表示（display）するためのシステムおよび方法に関する。

コンピュータ・ユーザに、情報を迅速に見つけ表示（display）する能力を、情報のフォーマットまたはロケーションに関係なく提供することは、コンピュータ業界が長年取り組んできた課題である。今日、この問題は、ますます多くの個人がその日常業務でコンピュータを使用し、またコンピュータ内に格納される情報のタイプが多様化し続けているので、これまで以上に注目すべき事柄になっている。

マイクロソフト・コーポレーション社のＷＩＮＤＯＷＳ（登録商標）９８（商標）などでは従来、こうした格納された情報は、フォルダ内に格納された情報またはメディアのファイルの状態で、階層的に系統立てられた状態で、コンピュータ上のデータ・ストア内に保持されている。データ格納のこの方法は長年広く使用されてきたが、データによってはファイル階層外に常駐しており、またユーザが所望する情報のそれぞれ（desired pieces of information）を検索するときに限られたフォーマットおよび位置に制約されるという点で、それは制限されたものである。したがって、コンピュータ・ソフトウェアの提供元は、従来のファイル階層に代わるデータ格納の課題に現在取り組んでいる。

こうしたデータ格納の代替方法の一例は、本願の権利者が所有する同時係属出願「SYSTEM AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION」の文献に開示されている。この同時係属出願は、２００３年８月２１日に出願され、記憶装置（storage）を単一のデータベースに統合するデータ・ストアを開示している。このデータベースは、すべてのデータが格納された唯一の場所であり、したがって、データベースにデータを示すやり方は１つしかなく、またデータについて照会するやり方も１つしかない。この現代のデータベース技術が旧式のファイル・システムに取って代わることによって、データ・ストアは、より容易に検索することができ、より信頼性の高い、より利用しやすい、より弾力性のあるものになる。

この統合されたデータ・ストアの環境が整うと、格納されたデータと対話するための適切なツールおよび機能（capabilities）をユーザに提供することが必要になる。マイクロソフト・コーポレーション社のＷＩＮＤＯＷＳ（登録商標）２０００（商標）などの従来のオペレーティング・システムは、コンピュータに関する様々な情報のビューを得るためのユーザ・インターフェースを提供するシェル・ユーティリティを含む。シェルは一般に、ユーザがファイル・システム内をナビゲートし、ファイルおよびフォルダの位置を突き止め、それを開くことを可能にするファイル・システム・ブラウザを含む。例えば、マイクロソフト・コーポレーション社のＷＩＮＤＯＷＳ（登録商標）ＥＸＰＬＯＲＥＲ（商標）は、ＷＩＮＤＯＷＳ（登録商標）２０００（商標）に含まれるファイル・システム・ブラウザのユーティリティである。

このシェルは、また、ユーザがプリンタやフォントなどの非ファイル・アイテムのビューを得られるようにもする。典型的なシェルには、こうした特殊なアイテムをそれがまるでファイル・システム内に位置するように表示（display）するための特定の機能が組み込まれているので、このナビゲーションが可能である。例えば、ＷＩＮＤＯＷＳ（登録商標）２０００（商標）では、ユーザは、スタート・メニューの設定オプション内に位置する「プリンタ」フォルダを開くことができる。プリンタはファイルではなくハードウェアの一部なので、プリンタのこうしたグラフィカル表示（graphical representation）は、プリンタをそれがまるで「プリンタ」フォルダ内に常駐するファイルであるように表示（display）することに向けられたカスタム・コードを使用することによって、実現される。しかし、カスタム・コードおよびカスタム描画の例外の使用は、開発者にとってその実装は複雑なものであり、信頼できないものになり、またシェル・ブラウザの弾力性を減少させる可能性がある。さらに、あるタイプのデータのためのカスタム・コードおよびカスタム描画の例外の環境が整っていない場合、シェルは、そのタイプのアイテムを表示（display）することができないことになる。したがって、従来のシェルは、ユーザに特定のアイテムを表示（display）する際の機能および柔軟性の点において制限されている。

従来のシェル・ブラウザについての別の制限は、リレーショナルな態様で（in a relational manner）アイテムを表示（display）する能力が限定されることである。シェル・ブラウザは、一般に、アイテムが、各フォルダ内に格納された各ファイルで系統立てて格納されている階層的なやり方でしかアイテムの表示（display）を実施できない。例えば、ユーザがコンピュータ上に格納されたすべての画像ファイルのビューを得たいと所望する場合、ユーザはまず、すべてのこうした画像ファイルを同じフォルダ内に置かなければならない。シェルがアイテム間のリレーションシップを決定できる能力は限られているので、ユーザがリレーションシップ・ドリブンの（relationship driven）コンテクストでファイルのビューを得ることは困難である。

さらに、従来のシェル・ブラウザは、関連する情報およびタスクを、表示（display）されるアイテム・セットと対にする、文脈的に規定された環境（contextually tailored environment）内にアイテムのセットを表示（display）する能力に限りがある。開発者は、こうした対（pairings）を提供することによって、アイテムに関連付けられる共通タスクの実施を容易にしながら、アイテム間をナビゲートするのに必要な適切な情報およびツールをユーザに提供することができる。しかし、従来技術では、開発者は、カスタム・コードを使用せずにこうした体験を提供することができない。

カスタム・コードを使用することによって強化された環境内に提示（present）されるファイルの一例は、マイクロソフト・コーポレーション社のＷＩＮＤＯＷＳ（登録商標）ＸＰ（商標）オペレーティング・システム内に含まれるマイ・ピクチャ・フォルダである。画像ファイルがマイ・ピクチャ・フォルダ内に格納されると、ユーザは、様々なサイズで画像のビューを得たり、それを回転したり、スライド・ショーのビューを得たり、画像を印刷したり、またはＣＤに画像をコピーしたりすることができる。ＷＩＮＤＯＷＳ（登録商標）ＸＰ（商標）内のシェルは、ユーザがこの特殊なフォルダ内に画像を格納することを選択すると、容易に画像間をナビゲートしたり、またそれらファイルに関する共有のタスクを実施したりすることができるように、カスタム・コードを使用して、こうした画像関連のタスクをフォルダの表示（display）内に組み込んできた。しかし、この環境では、マイ・ピクチャ・フォルダ内に格納されたファイルしか表示（display）されず、またこの機能性（functionality）を提供するためにカスタム・コードが使用されている。マイ・ピクチャ・フォルダは、従来のアイテムのプレゼンテーションに比べて改善されてはいるが、開発者は、カスタム・コードを使用せずにこうしたコンテンツが豊富な環境（content-rich environments）を定義するためには、未だに限られた能力しか与えられていない。

したがって、それぞれのアイテムを汎用データ・ストア内に表示（display）することができる改良されたシェルが求められており、またさらに、汎用データ・ストア内にリレーションシップ・ドリブンのコンテクストでアイテムを提示（present）するように構成された改良されたシェルが求められている。開発者がカスタム・コードを必要とせずに、適切な文脈的な情報（contextual information）および関連タスクを含むアイテムを表示（display）するカスタム環境を作成するためのシェル内の改良された機能も求められている。

本発明は、データ・ストア内に格納されたアイテムを、ユーザに文脈的な提示手法（contextual presentation）で提示するシステムを提供することによって、上記の必要性を満たし、また従来技術の１つまたは複数の欠点を克服する。本発明の一態様では、データ・ストアを含むコンピュータ・システムが提供される。データ・ストア内のアイテムのうちの少なくとも一部は、１つまたは複数のフィールド・エントリを含む。エクスプローラが含まれ、それは、データ・ストアと対話し、１つまたは複数の所望するフィールド・エントリを含むアイテムを選択し、選択されたアイテムをエクスプローラ表示スキーマに従って表示する。

本発明の別の態様は、ユーザにアイテムを文脈的な提示手法（contextual presentation）で提示するための、コンピュータによって実施される方法を含む。データ・ストア内の少なくとも１つのアイテムに関連付けられるフィールド・エントリに対応する所望のフィールド・エントリが選択される。エクスプローラ表示スキーマが定義される。この方法は、データ・ストアにアクセスして、所望するフィールド・エントリを含む１つまたは複数のアイテムを選択し、１つまたは複数の選択されたアイテムをエクスプローラ表示スキーマに従って表示する。

本発明の別の態様は、複数のアイテムを提示するためのエクスプローラを含む。エクスプローラは、所望のフィールド・エントリを選択するフィールド・エントリ選択コンポーネントを含む。アイテム選択コンポーネントは、データ・ストアにアクセスして、所望するフィールド・エントリを含む１つまたは複数のアイテムを選択し、表示提示（display presentation）コンポーネントは、選択されたアイテムをユーザに提示する。

本発明の別の態様は、ユーザにアイテムを提示するためのアプリケーション・プログラムを提供する。このプログラムは、データ・ストアにアクセスし、所望するフィールド・エントリを含むアイテムを選択するように構成されたアイテム選択モジュールを含む。このプログラムは、シェル・ブラウザと対話して、選択されたアイテムをエクスプローラ表示スキーマに従って提示するように構成されたシェル対話コンポーネントをも含む。

本発明の別の態様は、アイテムを文脈的な提示手法（contextual presentation）で提示するためのエクスプローラを確立するための、コンピュータによって実施される方法である。この方法は、データ・ストア内の少なくとも１つのアイテムに関連付けられたフィールド・エントリに対応する所望するフィールド・エントリを選択することを含む。エクスプローラ属性が定義され、また所望のフィールド・エントリに関連付けられた１つまたは複数のアイテムが、エクスプローラ属性を含む表示スキーマを用いてユーザに提示される。

本発明について、添付の図面を参照して以下に詳しく述べる。

Ｉ．序論
本発明の主題について、法的要件を満たすように特定する形で（with specificity）説明する。しかし、その説明自体は、本特許の範囲を限定するためのものでない。むしろ、他の現在または将来の技術に関連して、特許請求の範囲に記載された主題を、本ドキュメントに記載されるものに類似のステップまたはステップの組合せを含むようなやり方でも実施することが可能であることが企図されている。さらに、用語「ステップ」は使用される方法の様々な要素を意味するためにここでは用いられているが、個々のステップの順序について明示的に説明されている場合を除いては、この用語は、本明細書で開示される様々なステップ間の特定の順序を示唆するものと解釈されるべきでない。

本発明は、コンピュータ上に格納されたアイテムをユーザに表示するための改良されたシステムおよび方法を提供する。本発明のための例示的なオペレーティング環境について以下に説明する。

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

図１に示すように、例示的な汎用コンピューティング・システムは、処理装置２１、システム・メモリ２２、およびシステム・メモリを含めて様々なシステム構成要素を処理装置２１に結合するシステム・バス２３を含む。システム・バス２３は、メモリ・バスまたはメモリ・コントローラ、周辺バス、および様々なバス・アーキテクチャのいずれかを使用するローカル・バスを含めて、いくつかのタイプのバス構造のうちのいずれかであることができる。システム・メモリは、読出し専用メモリ（ＲＯＭ：read only memory）２４およびランダム・アクセス・メモリ（ＲＡＭ：random access memory）２５を含む。起動時などにパーソナル・コンピュータ２０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：basic input/output system）２６は一般に、ＲＯＭ２４内に格納される。パーソナル・コンピュータ２０はさらに、ハードウェア・ディスク（図示せず）から読み出しまたそこに書き込むためのハードディスク・ドライブ２７、取出し可能な磁気ディスク２９から読み出しまたはそこに書き込むための磁気ディスク・ドライブ２８、およびＣＤ−ＲＯＭや他の光媒体などの取出し可能な光ディスク３１から読み出しまたはそこに書き込むための光ディスク・ドライブ３０を含む。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８および光ディスク・ドライブ３０は、ハードディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３および光ディスク・ドライブ・インターフェース３４によってそれぞれシステム・バス２３に接続される。ドライブおよびその関連のコンピュータ読取り可能媒体は、コンピュータ読取り可能命令、データ構造体、プログラム・モジュール、またはパーソナル・コンピュータ２０の他のデータのための不揮発性の記憶を実現する。本明細書に示される例示的な環境では、ハードディスク、取出し可能磁気ディスク２９および取出し可能光ディスク３１が使用されているが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など、コンピュータによってアクセス可能なデータを格納することができる他のタイプのコンピュータ読取り可能媒体も例示的なオペレーティング・システム環境内で使用されことが可能であることが当業者には理解されたい。同様に、例示的な環境は、ヒート・センサ、およびセキュリティまたは火災の警報システムなどの多くのタイプの監視装置、ならびに他の情報ソースをも含むことができる。

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

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

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

図２Ａのブロック図に示すように、コンピュータ・システム２００は、概して３つの構成要素グループ、すなわちハードウェア構成要素２０２、ハードウェア／ソフトウェア・インターフェース・システム構成要素２０４、およびアプリケーション・プログラム構成要素２０６（本明細書の一部文脈では「ユーザ・コンポーネント」または「ソフトウェア・コンポーネント」とも称される）に分割されることができる。

コンピュータ・システム２００の様々な実施形態において、また図１に戻って参照すると、ハードウェア構成要素２０２は、主なものを挙げると、中央処理装置（ＣＰＵ：central processing unit）２１、メモリ（ＲＯＭ２４とＲＡＭ２５の両方）、基本入出力システム（ＢＩＯＳ）２６、ならびにキーボード４０、マウス４２、モニタ４７および／またはプリンタ（図示せず）などの様々な入出力装置（Ｉ／Ｏ：input/output）装置を含むことができる。ハードウェア構成要素２０２は、コンピュータ・システム２００のための基本の物理的基盤を含む。

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

ハードウェア／ソフトウェア・インターフェース・システム構成要素２０４は、ほとんどの場合においてそれ自体がシェルおよびカーネルを含むオペレーティング・システムを含む（また実施形態によっては、単にそれだけで構成される）。「オペレーティング・システム」（ＯＳ：operating system）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介の働きをする特殊なプログラムである。ハードウェア／ソフトウェア・インターフェース・システム構成要素２０４は、コンピュータ・システム内のオペレーティング・システムの代わりにまたはそれに加えて、仮想マシン・マネージャ（ＶＭＭ：virtual machine manager）、共通言語ランタイム（ＣＲＬ：Common Language Runtime）またはその機能的等価物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ：Ｊａｖａ（登録商標）Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）またはその機能的等価物、あるいは他のこうしたソフトウェア・コンポーネントをも含むことができる。ハードウェア／ソフトウェア・インターフェース・システムの目的は、ユーザがアプリケーション・プログラムを実行することができる環境を提供することである。任意のハードウェア／ソフトウェア・インターフェース・システムの目標は、コンピュータ・システムを利便性の高いものにし、またコンピュータ・ハードウェアを効率的に使用することである。

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

ハードウェア／ソフトウェア・インターフェース・システムは、伝統的に、アプリケーションのための様々なサービスを実施する。複数のプログラムを同時に実行することが可能なマルチタスクのハードウェア／ソフトウェア・インターフェース・システムでは、ハードウェア／ソフトウェア・インターフェース・システムは、どのアプリケーションをどんな順序で実行すべきか、また順番のため別のアプリケーションに切り換える前に各アプリケーションについてどれくらいの時間を見込んでおくべきかを決定する。またハードウェア／ソフトウェア・インターフェース・システムは、複数のアプリケーション間の内部メモリの共有を管理し、ハードディスク、プリンタおよびダイアルアップ・ポートなどの接続されたハードウェア装置への入力およびそこからの出力を処理する。またハードウェア／ソフトウェア・インターフェース・システムは、操作の状況、および発生したかもしれないいずれかのエラーに関して、それぞれのアプリケーションに（また特定の場合にはエンド・ユーザに）メッセージを送信する。ハードウェア／ソフトウェア・インターフェース・システムは、開始側アプリケーションがバッチ・ジョブ（印刷など）の管理から解放され、他の処理および／または操作を再開できるようにバッチ・ジョブ管理の負荷を軽減することもできる。並列処理を提供することが可能なコンピュータでは、ハードウェア／ソフトウェア・インターフェース・システムは、同時に複数のプロセッサを実行できるようにプログラムの分割をも管理する。

ハードウェア／ソフトウェア・インターフェース・システム・シェル（本明細書では簡潔に「シェル」と称される）は、ハードウェア／ソフトウェア・インターフェース・システムとのインタラクティブなエンド・ユーザ・インターフェースである（シェルは、「コマンド・インタプリタ」と称され、またはオペレーティング・システムでは「オペレーティング・システム・シェル」とも称されこともある）。シェルは、アプリケーション・プログラムおよび／またはエンド・ユーザから直接にアクセスすることがきるハードウェア／ソフトウェア・インターフェース・システムの外部層である。「シェル・ブラウザ」は、ユーザがハードウェア／ソフトウェア・インターフェースのビューを得て、それと対話できるようにするユーザ・インターフェースを提供する。シェルとは異なりカーネルは、ハードウェア構成要素と直接に対話するハードウェア／ソフトウェア・インターフェース・システムの最も内側の層である。

本発明の多くの実施形態がコンピュータ化されたシステムに特によく適していると考えられるが、本文書中の記載には、本発明をこうした実施形態に制限するように意図したものはない。本明細書では、用語「コンピュータ・システム」は、情報を格納し処理することができ、かつ／または格納された情報を使用して装置自体の振舞いまたは実行を制御することができるあらゆる装置を、その装置が電子的、機械的、論理的または仮想的な性質のものであるかどうかに関係なく、包含することを表している。

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

ディレクトリ（別名フォルダ・ディレクトリ）は、従来、ツリー・ベースの階層構造であり、そこでは、ファイルがフォルダに分類され、フォルダは、さらに、ディレクトリ・ツリーを含む相対ノード位置に従って配置される。例えば、図２Ｂに示すように、ＤＯＳベースのファイル・システムのベース・フォルダ（すなわち「ルート・ディレクトリ」）２１２は、複数のフォルダ２１４を含むことができ、このフォルダのそれぞれは、（その特定のフォルダの「サブ・フォルダ」として）追加のフォルダ２１６をさらに含むことができ、またそのそれぞれは追加のフォルダ２１８を含むことができ、以下無限に続く。これらのフォルダはそれぞれ、１つまたは複数のファイル２２０を含むことが可能であるが、ハードウェア／ソフトウェア・インターフェース・システムのレベルでは、フォルダ内の個々のファイルには、そのツリー階層上のそれらのロケーション以外の共通点はない。当然ながら、ファイルをフォルダ階層に編成するこの手法には、これらのファイルを格納するために使用される典型的な記憶媒体（例えば、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理編成（physical organization）が間接的に反映されている。

上記内容に加えて、それぞれのフォルダは、そのサブ・フォルダおよびファイルの入れ物（container）であり、すなわちそれぞれのフォルダがサブ・フォルダおよびファイルを所有する。例えば、フォルダがハードウェア／ソフトウェア・インターフェース・システムによって削除される場合、そのフォルダのサブ・フォルダおよびファイルもまた削除される（各サブ・フォルダの場合には、それはさらにそれ自体のサブ・フォルダおよびファイルを再帰的に含む）。同様に、それぞれファイルは一般に、１つのフォルダだけによって所有され、またファイルはコピーされることができ、そのコピーが別のフォルダに置かれるが、ファイルのコピー自体は、オリジナル・ファイルとの直接的なつながりをもたない別個の独立した単位である（例えば、ハードウェア／ソフトウェア・インターフェース・システムのレベルでは、オリジナル・ファイルに対する変更がコピー・ファイル内に反映されない）。この点に関して、フォルダが物理的な入れ物のように扱われ、ファイルがその入れ物内の個々の独立した物理要素として扱われるので、ファイルおよびフォルダは、したがって、特性的には、事実上「物理的」なものである。

ＩＩ．汎用データ・ストア
本発明によって使用されるストレージ・プラットフォームは、上記で論じた既存のファイル・システムの類を超えて、データプラットフォームを拡張し拡大し、またすべてのタイプのデータを格納するように設計される。すべてのタイプのデータを格納するように設計されたデータ・ストアは、汎用データ・ストアと称することができる。本発明の使用に適した汎用データ・ストアの一例は、２００３年８月２１日に出願された、本願の権利者が所有する同時係属出願「SYSTEM AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION」の文献に記載されている。この文献は、本明細書に参照により組み込まれている。

Ａ．ストレージ・プラットフォームの概要
図３を参照すると、本発明によるストレージ・プラットフォーム３００は、データベース・エンジン３１４上で実装された汎用データ・ストア３０２を含んでいる。ある実施形態では、データベース・エンジン３１４は、オブジェクト関係拡張機能（object relational extensions）を備えたリレーショナル・データベース・エンジンを含む。ある実施形態では、リレーショナル・データベース・エンジン３１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバ・リレーショナル・データベース・エンジンを含む。

汎用データ・ストア３０２は、データの編成、検索、共有、同期およびセキュリティをサポートするデータ・モデル３０４を実装する。特定のタイプのデータがスキーマ３４０などのスキーマに記述され、また以下でより十分に述べるように、ストレージ・プラットフォーム３００は、そのスキーマの展開および拡張のためのツール３４６を提供する。

汎用データ・ストア３０２内に実装された変更トラッキング機構３０６は、データ・ストアに対する変更をトラッキングする能力を提供する。汎用データ・ストア３０２は、セキュリティ機能３０８およびｐｒｏｍｏｔｉｏｎ／ｄｅｍｏｔｉｏｎ機能３１０をも提供する。汎用データ・ストア３０２は、また、ストレージ・プラットフォームの他のコンポーネントおよび、ストレージ・プラットフォームを使用するアプリケーション・プログラム（アプリケーション・プログラム３５０Ａ、３５０Ｂおよび３５０Ｃなど）に汎用データ・ストア３０２の機能を公開するための１組のアプリケーション・プログラミング・インターフェース３１２を提供する。

本発明のストレージ・プラットフォームはさらに、アプリケーション・プログラム３５０Ａ、３５０Ｂおよび３５０Ｃなどのアプリケーション・プログラムが、ストレージ・プラットフォームのすべての上記機能にアクセスし、またスキーマに記述されたデータにアクセスできるようにするアプリケーション・プログラミング・インターフェース（ＡＰＩ）３２２を含む。ストレージ・プラットフォームＡＰＩ３２２は、アプリケーション・プログラムによって、ＯＬＥ ＤＢ ＡＰＩ３２４およびＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎ３２ ＡＰＩ３２６などの他のＡＰＩと組み合わせて、使用されることができる。

本発明のストレージ・プラットフォーム３００は、ユーザまたはシステム間のデータ共有を容易にする同期サービス３３０を含めて、アプリケーション・プログラムに様々なサービス３２８を提供することができる。例えば同期サービス３３０は、データ・ストア３０２と同じフォーマットを有する他のデータ・ストア３４０との相互運用、および他のフォーマットを有するデータ・ストア３４２へのアクセスを可能にすることができる。ストレージ・プラットフォーム３００は、汎用データ・ストア３０２がＷｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイル・システム３１８などの既存のファイル・システムと相互運用できるようにするファイル・システム機能をも提供する。

少なくとも一部の実施形態では、ストレージ・プラットフォーム３２０は、データが操作を受けることを可能にし、また他のシステムとの対話を可能にするための追加の機能をアプリケーション・プログラムに提供することもできる。こうした機能は、Ｉｎｆｏエージェント・サービス３３４および通知サービス３３２などの、追加のサービス３２８の形で、また他のユーティリティ３３６の形で実装されることができる。

少なくとも一部の実施形態では、ストレージ・プラットフォームは、コンピュータ・システムのハードウェア／ソフトウェア・インターフェース・システム内に実装され、またはその不可欠な部分を形成する。限定せずに、例を挙げると、本発明のストレージ・プラットフォームは、オペレーティング・システム、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的等価物、あるいはＪａｖａ（登録商標）仮想マシン（ＪＭＶ）またはその機能的等価物に実装され、またはその不可欠な部分を形成することができる。

本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータによって、消費者、知識労働者および事業体向けのより効率的なアプリケーション開発を可能にする。それは、そのデータ・モデルに固有の機能を使用可能にするだけでなく、既存のファイル・システムおよびデータベース・アクセス方法を受け入れ拡張する、豊富で拡張可能なプログラミング表面積を提供する。

Ｂ．データ・モデル
本発明のストレージ・プラットフォーム３００の汎用データ・ストア３０２は、ストア内に常駐するデータの編成（organization）、検索、共有、同期およびセキュリティをサポートするデータ・モデルを実装する。本発明のデータ・モデルでは、格納情報の基本の単位は、アイテムとして参照することができる。データ・モデルは、アイテムおよびアイテム拡張を宣言し、アイテム間のリレーションシップを確立し、フォルダおよびカテゴリ内にアイテムを編成するための機構を提供する。

本発明の一実施形態では、データ・モデルは、２つのプリミティブな機構、タイプ（type）およびリレーションシップに依存する。タイプは、そのタイプのインスタンスのタイプを決定するフォーマットを提供する構造である。フォーマットは、順序付けられた１組のプロパティとして表現される。プロパティは、値の名前または所与のタイプの１組の値である、例えばＵＳＰｏｓｔａｌＡｄｄｒｅｓｓ型は、通り、市、郵便番号、州というプロパティを有することができる。プロパティは、必須のことも、任意選択であることもある。

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

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

１．アイテム
上述したように、本発明による汎用データ・ストア内の格納情報の基本単位は、アイテムとして参照することができる。アイテムは、格納可能な情報の単位であり、単純なファイルとは異なり、エンド・ユーザまたはアプリケーション・プログラムに公開されるすべてのオブジェクトにわたってストレージ・プラットフォームが共通にサポートする１組の基本のプロパティを含むオブジェクトである。データ・ストア内の各アイテムが、それに対して一定であるデータ・スキーマに従って格納されたこうした基本プロパティを示すデータを含んでいるという理由などから、汎用データ・ストアの一般性（universality）が実現されることを当業者には理解されたい。

汎用データ・スキーマは、アイテムおよびプロパティを作成し編成するための概念的フレームワークを確立する普遍的な基礎を提供する。汎用データ・スキーマは、アイテムおよびプロパティの特定の特殊なタイプを定義し、その特殊な基礎となるタイプの特徴を定義し、この基礎となるタイプからサブタイプをさらに派生させることができる。この汎用データ・スキーマを使用することによって、プログラマは、アイテム（およびそのそれぞれのタイプ）をプロパティ（およびそのそれぞれのタイプ）と概念的に区別することができる。さらに、汎用データ・スキーマは、すべてのアイテムが有することができる１組の基礎となるプロパティを示し、またすべてのアイテム（およびその対応するアイテムのタイプ）が汎用データ・スキーマ内のこの基礎となるアイテム（およびその対応するアイテムのタイプ）から派生する。汎用データ・スキーマに従って各アイテムを格納することによって、シェル・ブラウザは、データ・ストア内の各アイテムを、その基本のプロパティと併せて解釈し、ユーザに提示することができる。本発明の使用に適した汎用データ・ストアの一例は、２００３年８月２１日に出願された、本願の権利者が所有する同時係属出願「SYSTEM AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATIONに記載されている。この文献は、本明細書に参照により組み込まれている。

アイテムは、新しいプロパティおよびリレーションシップを取り入れることを可能にする特徴（features）を含めて、すべてのアイテムのタイプにわたって共通にサポートされるプロパティおよびリレーションシップを有する。このプロパティおよびリレーションシップのデータは、アイテムに関連付けられたメタデータとして参照することができることが当業者には理解されよう。後述するように、このメタデータは、アイテム装飾スキーマ（item decoration schema）に従って格納することができる。このアイテム装飾スキーマは、アイテムをユーザに提示するのに適切なやり方を指示することができる。

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

アイテムは、連絡先、人、サービス、場所（location）、（すべての様々な種類の）ドキュメントなど、実世界の、容易に理解できるデータ単位を示すよう意図されている。

アイテムは独立型のオブジェクト（stand-alone objects）であり、したがって、アイテムが削除されると、そのアイテムのすべてのプロパティも同様に削除される。同様に、アイテムを取り出すと、取り出されたものは、アイテムおよびそのアイテムのメタデータ内に含まれるそのすべてのプロパティである。本発明の特定の実施形態では、特定のアイテムを取り出すときにプロパティのサブセットを要求することが可能であるが、こうした多くの実施形態の初期設定では、取り出される際に、その直接の、および継承されたプロパティ（immediate and inherited properties）の全てを備えたアイテムを提供する。さらに、アイテムのプロパティは、そのアイテムのタイプの既存のプロパティに新しいプロパティを追加することによって拡張することができる。以下ではこうした「拡張」は、アイテムの真正のプロパティ（bona fide properties）であり、そのアイテムのタイプのサブタイプは、拡張プロパティを自動的に含むことができる。その拡張は、ファイルに関連付けられたメタデータとして参照される。

２．アイテム・フォルダおよびカタログ
アイテムのグループは、（ファイル・フォルダと混同されるべきでない）アイテム・フォルダと呼ばれる特殊なアイテムに編成することができる。ほどんどのファイル・システムの場合と異なるが、アイテムは、複数のアイテム・フォルダに属すことができ、この結果、あるアイテム・フォルダ内でアイテムがアクセスされ変更された場合に、この変更されたアイテムが別のアイテム・フォルダから直接にアクセスすることができるようになる。要するに、それぞれ異なるアイテム・フォルダからアイテムへのアクセスが有ったとしても、実際にアクセスされているアイテムは、実際には、まさに同じアイテムである。しかし、アイテム・フォルダは、そのメンバ・アイテムのすべてを必ずしも所有しておらず、また、他のフォルダとともにアイテムを単に共同で所有するだけであり、その結果、アイテム・フォルダの削除によってそのアイテムが必ずしも削除されない。

アイテムは、アイテム・プロパティに対応する（ａ）アイテムのタイプ（あるいはタイプ）、（ｂ）特定の直接的なまたは継承されたプロパティ（あるいはプロパティ）、あるいは（ｃ）特定の値など、記述された共通の特性（characteristic）に基づくカテゴリに属することもできる。例えば、個人連絡先情報についての特定のプロパティを含むアイテムは、連絡先カテゴリに自動的に属し、連絡先情報プロパティを有するいずれのアイテムも同様に、このカテゴリに自動的に属すことになる。同様に、「Ｎｅｗ Ｙｏｒｋ Ｃｉｔｙ」の値を備えたロケーション・プロパティを有するいずれのアイテムも、ＮｅｗＹｏｒｋＣｉｔｙカテゴリに自動的に属すことになる。

カテゴリは、アイテム・フォルダとは概念的に異なる（すなわち記述された共通の特性をもたない）アイテムを含むことができるが、カテゴリ内の各アイテムはカテゴリについて記述された共通のタイプ、プロパティまたは値（共通性）を有し、またこの共通性がカテゴリ内の他のアイテムとのリレーションシップ、およびその間のリレーションシップの基礎を形成するという点で、アイテム・フォルダとは概念的に異なっている。さらに、アイテムの特定のフォルダへの帰属はアイテムのいずれかの特定の諸相（aspect）に基づくことが必須ではないが、特定の実施形態では、ハードウェア／ソフトウェア・システムのレベルで、カテゴリに断定的に関連する共通性を有するすべてのアイテムがそのカテゴリのメンバになる。概念的にカテゴリは、帰属が特定のクエリ（データベースのコンテクストなど）の結果に基づいている仮想アイテム・フォルダと見なすこともでき、したがって、（カテゴリの共通性によって定義される）このクエリの条件を満たすアイテムは、カテゴリへの帰属を含む。

図４に、本発明の様々な実施形態におけるアイテム、アイテム・フォルダおよびカテゴリ間の構造的リレーションシップを示す。複数のアイテム４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８および４２０は、様々なアイテム・フォルダ４２２、４２４、４２６、４２８および４３０のメンバである。アイテムによっては、複数のアイテム・フォルダに属することがあり、例えばアイテム４０２は、アイテム・フォルダ４２２および４２４に属する。一部のアイテム、例えばアイテム４０２、４０４、４０６、４０８、４１０および４１２は１つまたは複数のカテゴリ４３２、４３４および４３６のカテゴリのメンバでもあるが、一方、他のアイテム、例えばアイテム４１４、４１６、４１８、および４２０はカテゴリに属さないことがある（しかし、いずれかのプロパティを所有していることがカテゴリ内のメンバーシップであることを含意する特定の実施形態では、そうである可能性は非常に低く、したがってこうした実施形態では、アイテムは、いずれのカテゴリにも属さないためには、まったく特徴（feature）のないものでなければならない）。フォルダの階層的構造とは異なり、カテゴリとアイテム・フォルダの両方は、図示するグラフに類似の構造を有する。いずれにせよ、アイテム、アイテム・フォルダおよびカテゴリはすべて、（アイテムのタイプはそれぞれ異なるけれども）アイテムである。

ファイル、ファイル・フォルダおよびディレクトリとは異なり、本発明のアイテム、アイテム・フォルダおよびカテゴリは、物理的な入れ物に概念的に相当するものを有さないので、特性的には、「物理的」なものではなく、したがって、アイテムは、複数のこうしたロケーションに存在することができる。複数のアイテム・フォルダ位置に存在し、また複数のカテゴリに編成される、アイテムに対する能力によって、ハードウェア／ソフトウェア・インターフェース・レベルに、当技術分野で現在得られるもの以上の、強化され、豊富にされたデータ操作および格納構造の可能性（capabilities）がもたらされる。

３．関係（リレーションシップ）
アイテムは、２つ以上のアイテム間のリレーションシップが決定されることを可能にするリレーショナル情報（relational information）も含むことができる。リレーションシップは、１つのアイテムがソースと指定され、他方のアイテムがターゲットと指定されるバイナリー・リレーションシップである。ソース・アイテムとターゲット・アイテムは、リレーションシップによって関連付けられる。リレーションシップは、包含（containment）および参照（reference）リレーションシップに分類することができる。包含リレーションシップはターゲート・アイテムのライフタイム（life time）を制御し、参照リレーションシップは、ライフタイム管理のセマンティックスを提供しない。

包含リレーションシップのタイプはさらに、ホールディング（保留）リレーションシップおよびエンベッディング（組み込み）リレーションシップに分類される。保留リレーションシップは、参照カウント機構によってターゲットのライフタイムを制御する。保留リレーションシップは、そのターゲットを含まないが、ターゲットのライフタイムを制御する。アイテムとのすべての保留リレーションシップが削除されると、そのアイテムは削除される。組込みリレーションシップは、複合アイテム（compound item）のモデル化を可能にし、また排他的な保留リレーションシップであると見なすことができる。アイテムは、１つまたは複数の保留リレーションシップのターゲットでありことが可能であるが、厳密に１つの組込みリレーションシップのターゲットである。組込みリレーションシップのターゲットであるアイテムは、他の保留または組込みリレーションシップのターゲットとすることはできない。組込みリレーションシップはそのターゲットを含み、またターゲットのライフタイムを制御する。当業者には、単一のターゲットは、多くても１つの組込みリレーションシップ内にしか存在し得ないが、複数の保留リレーションシップ内に存在することができる。

参照リレーションシップは、ターゲット・アイテムのライフタイムを制御しない。それは、ぶら下がっている（dangling）かも知れない−ターゲット・アイテムが存在しないかも知れない。参照リレーションシップを使用して、グローバル・アイテムの名前空間内の（すなわちリモート・データ・ストアを含む）どこかのアイテムへの参照をモデル化することができる。

アイテムの取出しによって、そのリレーションシップは自動的に取り出されない。アプリケーションまたはシェルは、アイテムのリレーションシップを明示的に要求しなければならない。さらに、リレーションシップの修正によって、ソースまたはターゲット・アイテムは修正されず、同様に、リレーションシップの追加は、ソース／ターゲット・アイテムに影響を及ぼさない。２つのアイテム間のリレーションシップは宣言され、アイテムともに格納されることができ、あるいはシェルまたはアプリケーションは、リレーショナル情報を使用して、２つのアイテムが関連していることを決定することができる。

参照リレーションシップによって、それが参照するアイテムのライフタイム期間は制御されない。さらに、参照リレーションシップによって、ターゲットの存在は保証されず、またリレーションシップ宣言に指定されたターゲットのタイプも保証されない。これは、参照リレーションシップが、ぶら下がっていることを意味する。参照リレーションシップは、他のデータ・ストア内のアイテムを参照することもできる。参照リレーションシップは、ウェブ・ページのリンクの概念に類似の概念として考えることができる。

少なくとも１つの実施形態では、本発明のストレージ・プラットフォームは、リレーションシップの順序付けをサポートする。順序付けは、「Ｏｒｄｅｒ」と称されるプロパティを用いて実現される。Ｏｒｄｅｒフィールドに対する固有の制約はない。同じ「Ｏｒｄｅｒ」プロパティ値を有するリレーションシップの順序は保証されないが、より低い「Ｏｒｄｅｒ」値を有するリレーションシップの後に、またより高い「Ｏｒｄｅｒ」フィールド値を有するリレーションシップの前に、それが順序付けられることが保証される。プロパティ「Ｏｒｄｅｒ」は、基本のリレーションシップ定義内に存在しないことに留意されたい。そうではなく、これは、ソースとターゲットの間のリレーションシップの一部として格納される外因性（extrinsic）のプロパティである。

上述のように、アイテムは、アイテム・フォルダのメンバであることができる。リレーションシップの観点からは、アイテムは、アイテム・フォルダとのリレーションシップを有することができる。本発明のいくつかの実施形態では、特定のリレーションシップは、アイテム間に存在するリレーションシップによって表すことができる。

４．拡張性
図３を参照すると、上述したように、ストレージ・プラットフォームにスキーマ３４０の初期セットが設けられている。しかし、少なくとも一部の実施形態では、ストレージ・プラットフォームはさらに、独立系ソフトウェア・ベンダ（ＩＳＶ：independent software vendor）を含めて顧客が新しいスキーマ３４４を作成できるようにする。

Ｃ．データベース・エンジン
上述したように、データ・ストアは、データベース・エンジン内に実装される。ある実施形態では、データベース・エンジンは、オブジェクト関係拡張機能を備えた、Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバエンジンなどの、ＳＱＬクエリ言語を実装するリレーショナル・データベース・エンジンを備える。しかし、様々なデータベース・エンジンを使用することができることが理解されよう。実際に、リレーショナル・データベース・エンジン上でストレージ・プラットフォームの概念データ・モデルを実装することに加えて、それは、他のタイプのデータベース、例えばオブジェクト指向およびＸＭＬデータベース上に実装することもできる。

ＩＩＩ．ユーザへのアイテムの提示（presentment）
汎用データ・ストア内のアイテムは、シェル・ブラウザによってユーザに提示される。こうしたブラウザは当技術分野ではよく知られており、上記で説明したように、シェル・ブラウザは、ユーザがハードウェア／ソフトウェア・インターフェースのビューを得て、それと対話できるようにするユーザ・インターフェースを提供する。

Ａ．既定の表示ビュー（display view）
上述のように、汎用データ・ストア内の各アイテムは、汎用データ・スキーマに従って格納される。このスキーマは、タイプ関連付け（type association）と称されるアイテムを記述するための機構を含む。それぞれのタイプ関連付けは、シェル内での基本表現（basic representation）を含み、したがって、タイプの関連付けに従ってアイテムを格納することによって、シェルは、少なくとも基本のまたは既定の表示ビューに従ってアイテムを表示することができる。

タイプ関連付けは、アイテムに関連付けられるプロパティであり、データを汎用データ・ストア内に置くときは、それがどのタイプのアイテムかを決定できるように、データに関連付けられた１つまたは複数のプロパティが宣言されなければならない。こうしたプロパティは、データに関連付けられるメタデータとして含めることができる。シェルは、アイテムについて宣言されなければならない最も基本の最小限のプロパティを示す１組の既定のタイプ関連付けを有する。

図５に、アイテム５００を示す。アイテム５００は、汎用データ・スキーマに従って格納されており、１組のアイテム・データ５０２、およびプロパティ宣言を含めて１組のメタデータ５０４を含んでいる。アイテム・データ５０２は、データ・ストア内に含むのに適した任意のデータセットであることができる。例えばアイテム・データ５０２は、ワード・プロセッシング文書に関連付けることができる。プロパティ宣言メタデータ５０４は、アイテム５００についての少なくとも基本タイプの宣言を含む。例えば、既定のタイプ関連付けはＤｏｃｕｍｅｎｔタイプとすることができ、メタデータ５０４は、アイテム５００がＤｏｃｕｍｅｎｔタイプ・のアイテムであると示すことができる。シェルは、それぞれの既定のタイプ関連付けについて、既定の表示ビューを含んでいるので、Ｄｏｃｕｍｅｎｔタイプの既定の表示ビューに従ってアイテム５００を表示することができる。Ｄｏｃｕｍｅｎｔタイプの既定の表示ビューは、例えばＤｏｃｕｍｅｎｔタイプ・アイテムよってのみ使用されるアイコンを含む。ワード処理アイテムをこのアイコンとともに提示することによって、ユーザは、アイテム５００がドキュメントであることを迅速に認識することができる。任意の様々な既定のタイプ関連付けおよび既定の表示属性（display attributes）を本発明が許容できることが当業者には理解されよう。

Ｂ．アイテム装飾ビュー
アイテムに関連付けられるメタデータは、プロパティ宣言を超えて、シェルがどのようにアイテムのプレゼンテーションを装飾すべきかを示すデータを含むことができる。この場合の装飾は、アイテムをどのようにユーザに提示するかに関する「ヒント」として考えることができる。このメタデータは、アイテム装飾スキーマに従って格納することができる。アイテム装飾スキーマは、シェルがアイテムを提示するために使用することができるアイテム装飾ビューを定義する。例えば、アイテム装飾データは、アイテムにとって最も重要な宣言プロパティを表すことが可能である。こうした「高価値（high value）」プロパティは、シェル内のプレゼンテーションにとって最も望ましいものである可能性がある。

アイテム５００は、アイテム装飾スキーマに従って格納されたアイテム装飾データ５０６を任意選択で含むことができる。アイテム５００を提示するために、アイテム装飾データ５０６は、アイテム５００のプレゼンテーションに適した１組のビュー・フィールドを指示することができる。ビュー・フィールドは宣言されたプロパティの投影であり、共通のビュー・フィールドは、「タイトル」、「作成者」、「作成日付」または「最終編集」を含むことができる。シェルは、１組の標準のビュー・フィールドを含み、独立系ソフトウェア・ベンダ（ＩＳＶ）は、そのデータのプレゼンテーションに適したビュー・フィールドを定義することができる。新しいアイテムのタイプを開発する場合、ＩＳＶは、それらを定義するアイテム・プロパティをシェルのビュー・フィールドにマッピングすることができし、または彼ら自身のビュー・フィールドを提供することができる。

例えば、アイテム・データ５０２は、歌のデータを含むことができる。１組の宣言プロパティ５０６は、歌のタイトル、アーティスト、記録された日付、アルバム、歌の長さおよびこうした歌アイテムに適した他の宣言を含むことができる。アイテム装飾データ５０６は、シェル内でアイテム５００を提示するときには「タイトル」、「アーティスト」および「アルバム」のビュー・フィールドがユーザに表示されなければならないことを示すことができる。

アイテム装飾データ５０６は、宣言されたプロパティとともに提示されるテキストなど、アイテム・データ５０２に関するより真に装飾的なアイテムを表すことができる。例えば、プロパティ宣言５０４のうちの１つは、記録の品質を表すビット・レート値を示すことができる。このプロパティは、格納された整数ＢＩＴＲＡＴＥであることができる。アイテム装飾データ５０６は、ビット・レートの表示を要求することができ、またこのフィールドを「〔ＢＩＴＲＡＴＥ〕キロ・バイト／秒」と装飾することもできる。この方法では、ビット・レート・フィールドは、ユーザがビュー・フィールド内のビット・レート値の意味を容易に理解し得るように適切に装飾される。

アイテム装飾データ５０６およびその対応するアイテム装飾ビューは、多種多様なプレゼンテーション属性を指示することができることが、当業者には理解されよう。アイテム装飾は、シェルによってサポートされるディスプレイについての諸相（aspect）であることができる。他の一般的ないくつかの装飾には、例えばデータ・フォーマット設定、既定のソート順および既定のアイコン・サイズがある。さらに、アイテム装飾データ５０６は、所与のアイテムのディスプレイに使用する共通のコントロールを記述することができる。例えば格付けフィールドは、一連の星として格付けを表す格付けコントロールを使用することができる。アイテム装飾データ５０６は、アイテムでの使用に適したタスクおよび動詞を記述することができる。用語「タスク」および「動詞」は、アイテムに関して始められるべき何らかの動作（action）を表し、またこうした用語が互いに置き換え可能（interchangeable）であることが当業者には理解されよう。例えば「編集」または「プレビュー」は、アイテムに関連付けられる適切なタスク／動詞であることができる。シェルは、アイテムに関連する動作を実施するためのユーザ選択に基づいて、こうしたタスクをサポートするためにアプリケーションを起動するようにさらに構成することができる。

アイテム装飾は、時間とともに変化し発展することが当業者には理解されよう。本発明では、新しいアイテム装飾が実装されると、新しいアイテムはその装飾を使用することができるが、旧アイテムは、シェルによって提供される旧表示属性を使用して適切に表示し続けることが企図されている。

図６に、本発明による、ユーザにアイテムを提示するための方法６００を図示するフローチャートを示す。６０２で、方法６００は、ユーザに１つまたは複数のアイテムを表示することを求める要求に応答して、汎用データ・ストアにアクセスする。ステップ６０４で、この方法は、プレゼンテーションのために選択された１つまたは複数のアイテムについて考慮する。ステップ６０６に示すように、アイテム装飾スキーマに従って格納されたメタデータを含むアイテムが、アイテム装飾ビューに従ってユーザに提示される。ステップ６０８に示すように、こうしたメタデータを含まないアイテムは、既定の表示ビューに従って提示される。上記で論じたように、こうしたスキーマおよびプレゼンテーション・ビューは、データ・ストア内の各アイテムのプレゼンテーションに使用することができる様々な表示属性を含むことができる。

Ｃ．シェル・ビュー
上記で論じたように、アイテム装飾ビューは、所与のアイテム、あるいは同様のアイテム修飾ビューをもつアイテムからなる１組の同種のアイテムを完全に提示するのに十分である。それぞれ異なるアイテム装飾スキーマをもつアイテムを表示するために、シェルは、シェル装飾ビューに従ってアイテムを提示するシェル・ビュー・スキーマを提供する。シェル・ビュー・スキーマによって、シェルまたはＩＳＶは、異種なデータの所与の各組に適したビューを宣言することができる。

シェル装飾ビュー内の表示（representation）のために選択されたアイテムは、共通の特性を含むことができる。シェル装飾ビューが多種多様な共通の特性を許容できることが当業者には理解されよう。例えば、シェル・ビュー・スキーマは、すべての知られている画像タイプ（．ＧＩＦ、．ＪＰＥＧ、．ＢＭＰ、．ＴＩＦＦなど）に共通の適したフィールドおよびメタデータを表示するために使用される「画像」ビューを定義することができる。シェル・ビュー・スキーマは、所与のアイテム装飾ビューについて、競合する表示属性に優先し、シェル・ビュー・スキーマに従ってそれぞれの画像アイテムを提示する。別の例では、シェルは、「ドキュメント」シェル・ビューを提供し、このビューは、各アイテムのアイテム装飾が互いに大きく異なるとしても、ワード処理文書、スプレッド・シートまたはデータベースなどの典型的な生産性アプリケーションによって作成されるアイテムに適したカラムおよびメタデータに基づいて、最適化される。こうしたビューは、その各ドキュメントに共通のプロパティを提供することによって価値を有する。後にドキュメント・タイプがインストールされる場合、そのシェル・ビューは、そのビューが最初に作成されたときにはその新しいタイプが考慮されていなかった可能性があるとしても、一貫したシェル・ビュー（consistent shell view）に従ってその新しいアイテムを堤示できることが当業者には理解されよう。

所与の１組の異種のアイテムに適したビュー・フィールドを形成することに加えて、シェル・ビュー・スキーマは、さらなる表示属性を定義することができる。例えば、アイコン・プロパティ、プレビュー・ペイン（pane）のサイズ、および既定のソート順を含めて、ビュー状態が、シェル・ビュー・スキーマによって定義することができる。ビュー・スキーマは、様々なカラムに適用される、データ・フォーマットなどのプロパティ装飾も含む。

シェル・ビュー・スキーマとアイテム装飾スキーマが競合する場合、シェル・ビュー・スキーマが優先して動作する。表示要素（display element）がシェル・ビュー・スキーマから欠落している場合、シェル・ビューは、適切に表示するためにアイテム装飾ビューに頼る。このように、シェル・ビューは、当初は予期していなかったデータを表示するときに適切なビューを作ることができる。さらに、本発明の一実施形態では、シェル・ビューは、競合しない装飾要素（decorative element）を提供するためにアイテム装飾ビューに従う（defer：譲る）ことが可能である。例えば、シェル・ビューは、それが含む１組のアイテムからの「高価値（high value）」メタデータを利用して、アイテム表示のために適切な１組のカラムおよびメタデータを作成することができる。

シェル・ビュー・スキーマは多種多様な表示属性を提供することができ、またＩＳＶがこうしたシェル・ビューの提供を希望する可能性があることが当業者には理解されよう。表示属性には、それに限定されないが、プレビュー・ペイン、プレビュー・ペイン内に表示するメタデータ、使用されるカスタム・コントロール、ならびに提示されるアイテムに適したタスクおよび動詞を含むことができる。

図７に、本発明による、ユーザにアイテムを提示するための方法７００を図示するフローチャートを示す。７０２で、方法７００は、ユーザに１つまたは複数のアイテムを提示するように求める要求に応答してデータ・ストアにアクセスする。７０４で、プレゼンテーションのために選択された各アイテムが同じアイテム装飾スキーマを含むかどうかが決定される。すべてのアイテムがこうした共有スキーマを有する場合、７０６に示すように、そのスキーマに従ってアイテムが提示される。提示されるアイテムが、異なるアイテム表示スキーマを含みまたはそれを含まないアイテムを含む場合は、７０８で、そのアイテム・セットがシェル装飾ビューに従って提示される。上記で論じたように、こうしたシェル・ビューは、アイテムの異種のセットのプレゼンテーションに適切である可能性がある。７１０に、選択されたアイテムのうちの１つまたは複数をアイテム装飾ビューからの表示要素を付けて提示する任意選択のステップが含まれている。こうした表示要素はシェル装飾ビューと競合しない可能性があり、その要素によって、シェルによるアイテムのプレゼンテーションを向上させることができる。

図８に移ると、例示的なビュー・スキーマ階層８００が提示されている。階層の最下部は、アイテム・ビュー・スキーマ８０２である。アイテム・ビュー・スキーマ８０２は、アイテムを表すのに必要な基本の表示を提供し、またはビュー・スキーマが提供されない場合に既定の表示を提供する。アイテム・ビュー・スキーマ８０２より上位のスキーマは、必要時に、その表示要素に従い、またはその表示要素に頼ることができる。

シェル・ビュー・スキーマ８０４は、アイテム・ビュー・スキーマ８０２より上位に存在する。上記で論じたように、シェル・ビュー・スキーマを使用して、多種多様なアイテム・ビューを有する１組のアイテムを表示することができる。シェル・ビュー・スキーマは、シェル・ビュー８０４に従ってアイテムを表示するのに使用されるタスク８０６、プレビュー・ペイン特性８０８、カラム８１０および装飾８１２を定義する。このシェル・ビューは、シェル・ビュー８０４で使用するアイテム装飾と競合しないアイテム提供するために、例えばアイテム・ビュー・スキーマ８０２に頼ることができる。さらに、ユーザ・ビュー設定８１４が、このシェル・ビュー内に存在することができる。こうした設定は、シェル・アイテムについてユーザが所望するプレゼンテーション・フォーマット（desired presentation format）を提示する。表示スキーマ内に任意の数の表示属性を定義することができ、また表示設定に関する多くのオプションおよびコントロールをユーザに提示することができることが当業者には理解されよう。

Ｄ．エクスプローラ表示ビュー
シェルは、エクスプローラ表示ビューに従ってアイテムを提示するように構成することもできる。「エクスプローラ」は、ストレージ・アプリケーションと称されることができ、またシェルまたはＩＳＶによって提供することができる。本発明の一実施形態では、ユーザがアイテムの大規模な組（set）を管理するのを支援する全体観的な体験を提供するエクスプローラを作成することができる。例えば、エクスプローラによって、ユーザがデータ・ストア内の選択されたアイテムのビューを取得したり、照会したり、ナビゲートしたり、タスクを開始したり、または編成したりすることを可能にすることができる。用語「エクスプローラ」は、表示アイテムが常駐する場所を示唆するものではなく、また「アクティビティ・センタ（activity center）」、「ビューア」および「ライブラリ」は、本発明によるストレージ・アプリケーションを表すために「エクスプローラ」と同義的に使用することができる。

図９にエクスプローラの例示的なエクスプローラ・スキーマ階層９００を示す。階層の最下層は、アイテム・ビュー・スキーマ９０２である。アイテム・ビュー・スキーマ９０２は、アイテムを表すのに必要な基本の表示を提供し、エクスプローラ・ビュー９０４は、必要時にその表示要素に従いまたは頼ることができる。

エクスプローラ・ビュー・スキーマは、シェル・ビュー・スキーマ９０６およびエクスプローラ装飾９０８を含む。エクスプローラ装飾９０８は、エクスプローラを全体的に装飾し、また特徴的な色（distinctive colors）およびブランド要素（branding elements）などの表示要素を提供する。こうしたエクスプローラ装飾９０８は、エクスプローラが提供する様々なビューの中で持続する。多種多様な表示属性がエクスプローラ装飾９０８に適切であることが当業者には理解されよう。例えば、エクスプローラ・アイテムに関連付けられたデータ・クエリまたはタスク／動詞を、エクスプローラでの表示に適切である可能性がある。表示されるタスクは、そのタスクを実施することができるアプリケーションに結合されることが好ましい。

エクスプローラ・ビュー・スキーマは、１つまたは複数のシェル・ビュー・スキーマ９０６を任意選択で含むことができる。シェル・ビュー・スキーマ９０６は、エクスプローラ・アイテムのサブセットのためのシェル・ビューを提供するように構成することができる。例えば、エクスプローラは、ユーザに歌アイテムを表示するように構成することができる。第１のシェル・ビュー・スキーマをアルバムの表示を提供するために含めることができ、第２のシェル・ビュー・スキーマを、曲のトラックの表示を提供するために含めることができる。このように、両方のタイプのアイテムが、エクスプローラ内に適切なビューを含むことができる。上記で論じたように、シェル・ビューを使用することは、共通の特性を任意選択で共有することができる１組のアイテムのプレゼンテーションに関連する。

エクスプローラは、シェル内に含まれるシェル・ビューに依存することもできる。エクスプローラ内でのプレゼンテーションのために選択されたアイテムが、エクスプローラに含まれるどのシェル・ビューによってもサポートされていない場合、シェルは、エクスプローラ内で使用するのに適したシェル・ビューを提供することができる。同様にまた上記で論じたように、エクスプローラは、シェルが提供するアイテム表示ビューまたは既定の表示ビューに頼ることもできる。この機能によって、シェルによって表示することができる任意のアイテムをエクスプローラ内でも表示できるようになる。エクスプローラは、こうしたシェルが提供する表示スキーマ（display schemas）に従うように構成されることができ、または例えば予期しないデータの表示を提供するためにそれに依存することができる。

図１０に、本発明による、エクスプローラ表示内にアイテムを提示するための方法１０００を示す。１００２で、方法１０００は、データ・ストアにアクセスし、１００４で、エクスプローラ内に表示されるアイテムを選択する。エクスプローラ・アイテムの選択は、フィールド・エントリとも称されるアイテム装飾を考慮することに依存することもできる。上記で論じたように、データ・ストア内のアイテムは、プロパティ情報を含むことができる。この情報は、アイテムがデータ・ストア内に置かれるときに宣言され、またアイテムのライフタイムを通して更新することができる。こうした宣言は、１組のプロパティ・フィールドに対応するフィールド・エントリと見なすことが可能である。例えばプロパティ・フィールド「作成者」内のエントリは、所与のアイテムについての著作者情報を含むことができる。

１つまたは複数のフィールド・エントリを共有するアイテムを提示することが望ましいことがある。例えば、特定の人物によって書かれた各アイテムを含むエクスプローラが所望されることがある。作成者フィールドのフィールド・エントリを考慮することによって、エクスプローラは、特定の人物によって書かれたこうしたエクスプローラ・アイテムをデータ・ストアから選択することができる。こうしたデータベース・クエリの機構はよく知られていることが当業者には理解されよう。

１００６で、エクスプローラがエクスプローラ・アイテムのプレゼンテーションに適したシェル・ビューを含んでいるかどうかが決定される。エクスプローラ内にこうした適切なシェル・ビューが見つからない場合、１００８に示すように、方法１００８は、シェル内に含まれるビューを使用する。エクスプローラ内に適切なシェル・ビューが含まれている場合、１０１０で、方法１０００は、このシェル・ビューを使用してアイテムを提示する。１０１２で、アイテム表示スキーマからの装飾要素を使用する任意選択のステップが実施される。上述したように、エクスプローラは、アイテム・ビュー・スキーマからの競合しない装飾を使用して、アイテムのプレゼンテーションを向上させることができる。１０１４で、シェルおよびアイテム・ビューに従ってユーザにエクスプローラ・アイテムが提示される。１０１６で、エクスプローラ装飾プロパティが提示される。こうしたプロパティは、多種多様な表示属性とすることができ、またエクスプローラ・アイテムに関連付けられるデータ・クエリまたはタスクを含むことができる。

Ｅ．エクスプローラ開発（EXPLORER DEVELOPMENT）
エクスプローラは、多種多様なアイテムのタイプについて作成することができる。本発明の一実施形態では、エクスプローラは、プログラミングをほとんどまたはまったく行わないで定義することができる。エクスプローラをデータ・ドリブンのやり方で作成できるようにすることで、開発をより行いやすくし、またすべてのエクスプローラにわたって一貫性のあるルック・アンド・フィールが提供される。

特定の実施形態では、エクスプローラは、（アイテム拡張およびファイル拡張を含めて）それが提示することができるアイテムのタイプについて制約を課すことを可能にすることができ、またはすべてのタイプのアイテムを許容することを選択することがでる。また、エクスプローラは、特定な１組のアイテム拡張を含むアイテムのタイプを許容することを選択することができる。例えば、法律アイテム・エクスプローラは、「ＬｅｇａｌＩｔｅｍＥｘｔｅｎｓｉｏｎ」が付加されたすべてのアイテムを表示することができる。エクスプローラは、特定のタイプのアイテム、およびそのタイプにマッピングするどのファイル拡張子をも許容することを選択することができる。例えば、音楽アイテム・エクスプローラは、ｍｐ３やｗｍａなどのすべての音楽ファイル拡張子を示すことができる。さらに、エクスプローラは、特定の１組のファイル拡張子のアイテムだけを許容することを選択することができる。エクスプローラが１組の特定のタイプに制限される場合、他のタイプのアイテムは、このエクスプローラ内に保存されたり、またはドロップされたりすることはない。エクスプローラは、それが許容するタイプについてのタイプ関連付けを再定義することができ、選択的にオーバーライドを許容しないことを選択することができ、または新しいコマンドの追加を許容しないことを選択することができる。さらに、エクスプローラは、エクスプローラ内でエンド・ユーザにタイプ関連付けをオーバーライドさせるかどうかを決定することができる。

上記内容を考慮すると、アイテム−タイプの環境内で使用するエクスプローラ作成のためのデータ・ドリブンな開発技術を提供することによって、エクスプローラが、宣言的なやり方（declarative manner）で、カスタム・コードを使用しないで、定義することができることが当業者には理解されよう。

図１１に、エクスプローラ表示スキーマ（explorer display schema）に従ってアイテムを提示するための方法１１００を示す。１１０２で、方法１１００は、所望するフィールド・エントリ（desired field entry）を選択する。上記で論じたように、この所望するフィールド・エントリは、アイテムに関連付けられた、宣言されたプロパティに対応することができる。例えば、「写真アルバム」エクスプローラは、画像データを含むアイテムの包含を必要とする所望するフィールド・エントリを含むことができる。

１１０４で、エクスプローラ表示スキーマが定義される。この表示スキーマは、シェル・ビュー・スキーマおよびエクスプローラ装飾を含むことができる。エクスプローラ装飾は、エクスプローラを全体的に装飾し、特徴的な色およびブランド要素などの表示要素を提供する。こうしたエクスプローラ装飾は、エクスプローラが提供する様々なビューの中で持続する。多種多様な表示属性がエクスプローラ装飾に適切である可能性がある。例えば、エクスプローラ・アイテムに関連付けられるデータ・クエリまたはタスク／動詞が、エクスプローラでの表示に適切である可能性がある。表示されるタスクは、そのタスクを実施することができるアプリケーションに結合されることが望ましい。エクスプローラ・ビュー・スキーマは、１つまたは複数のシェル・ビュー・スキーマを含むことができる。シェル・ビュー・スキーマは、エクスプローラ・アイテムのサブセットについてのシェル・ビューを提供するように構成することができる。

１１０６で、方法１１００は、データ・ストアにアクセスしてエクスプローラ・アイテムを選択する。エクスプローラ・アイテムは、所望するフィールド・エントリに関連付けられる。データベース内のこうしたアイテムの選択は、当技術分野ではよく知られていることが当業者には理解されよう。開発者がこうした対話を行うように構成されたエクスプローラを作成することができることが当業者にはさらに理解されよう。本発明では、データ・ストアにアクセスすることができるエクスプローラの開発が企図されている。

１１０８で、エクスプローラ表示スキーマに従ってエクスプローラ・アイテムが表示される。エクスプローラ表示スキーマについては上記で述べられており、またこの表示は、シェル・ブラウザとの対話をも含むことができる。例えばシェルは、１つまたは複数のシェル・ビューを提供することができる。さらに、アイテム装飾スキーマからのアイテム装飾要素を使用して、エクスプローラ・アイテムのプレゼンテーションを向上させることができる。

エクスプローラ・ストレージ・アプリケーションは、アプリケーションおよび／またはシェル・ブラウザの拡張機能であると見なすことができることが当業者には理解されよう。したがって、上記説明は、本発明についての両方の描写に適している。アプリケーションとしては、エクスプローラ・プログラムは、シェル・ブラウザと対話するように構成されたシェル対話モジュールを含むことができる。こうした対話によって、プログラムはシェルと情報を通信し、またソフトウェアは、アイテムを提示するために連携して働くことができる。シェル対話モジュールは、データ・ストアへのアクセスが円滑に行われるようにすることができ、また表示属性を提供することができる。アプリケーションとシェルの間のこうした対話は、当技術分野ではよく知られている。

Ｆ．関連アイテムのプレゼンテーション
本発明は、ユーザにデータ・ストア内の関連アイテムを提示することもできる。上記で論じたように、データ・ストア内のアイテムは、１つまたは複数の宣言プロパティを有するアイテムを含むことができる。アイテムは、リレーションシップを共有するデータ・ストア内の他のアイテムを明らかにする宣言されたリレーションシップを有することができる。例えば、電子メール・アドレスを含むアイテムは、その電子メール・アドレスの所有者についての他の連絡先情報を含むアイテムとのリレーションシップを宣言することができる。シェルは、この宣言されたリレーションシップを使用して、ユーザの要求に応じて他の連絡先情報を提示することができる。シェルは、アイテムの宣言されたプロパティを考慮することによってリレーションシップを決定することもできる。例えば、１組のドキュメントは、それが共通のプロパティを共有している場合に関連付けられることができる、すなわち、拡張子「ＬｅｇａｌＩｔｅｍＥｘｔｅｎｓｉｏｎ」を有するアイテムは、また拡張子の一部として共通の値が格納されている場合に、関連付けられことができる。こうしたリレーションシップは、当技術分野ではよく知られているデータ・クエリによって決定されることになる。

図１２に、本発明に従って関連アイテムを提示するための方法１２００を示す。１２０２で、方法１２００は、データ・ストアにアクセスし、１２０４で、データ・ストア内のアイテム間のリレーションシップが決定される。上述したように、こうした決定には、アイテムに含まれる宣言されたプロパティを使用する。その決定は、ユーザ入力に応答するもので有ることが可能である。例えば、宣言された１組のアイテム特性を含むアイテムを、ユーザに提示することができる。アイテム特性およびリレーショナル情報は、アイテムとともに提示することができる。ユーザは、特性のうちの１つを選択し、そのアイテム特性を共有する他のアイテムを見ることを求める要求を入力することができる。１２０６で、方法１２００は、ユーザに関連アイテムを提示する。こうしたプレゼンテーションは、当技術分野で周知の任意の表示スキーマを含むことができる。

本発明の代替実施形態および実装は、図面を含めて本明細書を検討すると、それが関係する技術分野の技術者に明らかになろう。したがって、本発明の範囲は、上記説明ではなく特許請求の範囲によって定義される。

本発明の実施において使用するのに適したコンピューティング・システム環境のブロック図である。 ３つの構成要素グループ、すなわちハードウェア構成要素、ハードウェア／ソフトウェア・インターフェース・システム構成要素およびアプリケーション・プログラム構成要素に分割されたコンピュータ・システムを示すブロック図である。 ファイル・ベースのオペレーティング・システム上でディレクトリ内のフォルダに分類されたファイルの従来型ツリー・ベース階層構造を示す図である。 本発明によるストレージ・プラットフォームを示すブロック図である。 本発明の様々な実施形態における、アイテムと、アイテム・フォルダと、カテゴリとの間の構造上のリレーションシップを示す図である。 本発明の一実施形態による、アイテム内に含まれるデータの図である。 本発明の一実施形態による、ユーザに１つまたは複数のアイテムを提示するための方法を示すフローチャートである。 本発明の一実施形態による、ユーザに１つまたは複数のアイテムを提示するための方法を示すフローチャートである。 本発明の一実施形態によるビュー・スキーマ階層を示す図である。 本発明の一実施形態による、エクスプローラ・ビュー・スキーマを含むビュー・スキーマ階層を示す図である。 本発明の一実施形態による、ユーザにアイテムを提示するための方法を示すフローチャートである。 本発明の一実施形態による、ユーザに関連アイテムを提示するための方法を示すフローチャートである。 本発明の一実施形態による、ユーザに関連アイテムを提示するための方法を示すフローチャートである。

Claims (44)

1. 格納されたデータを提示するためコンピュータ・システムであって、
   複数のアイテムを含むデータ・ストアであって、前記アイテムの少なくとも一部は１つまたは複数のフィールド・エントリを含むデータ・ストアと、
   前記データ・ストアと対話して、１つまたは複数の所望するフィールド・エントリを有するアイテムを選択し、前記エクスプローラに関連するエクスプローラ表示スキーマに従って前記選択されたアイテムを表示するエクスプローラと
   を備えることを特徴とするコンピュータ・システム。
2. 前記エクスプローラ表示スキーマは、前記選択されたアイテムで提示される１つまたは複数の装飾要素を含むことを特徴とする請求項１に記載のコンピュータ・システム。
3. 前記エクスプローラ表示スキーマは、１つまたは複数のシェル・ビュー・スキーマを含み、前記選択されたアイテムのサブセットを表示するために、前記シェル・ビュー・スキーマの１つが使用されることを特徴とする請求項１に記載のコンピュータ・システム。
4. 前記シェル・ビュー・スキーマのうちの１つまたは複数は、前記選択されたアイテムのサブセットを前記ユーザに表示するのに適した１つまたは複数の表示諸相を含むことを特徴とする請求項３に記載のコンピュータ・システム。
5. 前記エクスプローラは、シェル・ブラウザに関連付けられたシェル表示スキーマを使用して、前記選択されたアイテムのうちの１つまたは複数を表示することを特徴とする請求項１に記載のコンピュータ・システム。
6. 前記エクスプローラは、シェル・ブラウザに関連付けられた１つまたは複数のアイテム表示スキーマを使用して、１つまたは複数の選択されたアイテムの表示内に含まれる１つまたは複数の表示要素を提供することを特徴とする請求項１に記載のコンピュータ・システム。
7. 前記エクスプローラ表示スキーマは、前記選択されたアイテムに関連する動詞を含むことを特徴とする請求項１に記載のコンピュータ・システム。
8. 前記動詞は、前記選択されたアイテムのうちの１つまたは複数に対して前記動詞を実施することができるアプリケーションに関連付けられることを特徴とする請求項７に記載のコンピュータ・システム。
9. 前記エクスプローラ表示スキーマは、前記選択されたアイテムに関連付けられる１つまたは複数のデータ・クエリを含むことを特徴とする請求項１に記載のコンピュータ・システム。
10. 前記エクスプローラは、前記データ・クエリのうちの１つまたは複数の結果を表示するように構成されることを特徴とする請求項９に記載のコンピュータ・システム。
11. データ・ストア内の１つまたは複数のアイテムをユーザに提示するための、コンピュータによって実施される方法であって、
    前記データ・ストア内の前記アイテムのうちの少なくとも一部は１つまたは複数のフィールド・エントリを含む、前記データ・ストア内の少なくとも１つの前記アイテムに関連付けられたフィールド・エントリに対応する所望するフィールド・エントリを選択すること、
    エクスプローラ表示スキーマを定義すること、
    前記データ・ストアにアクセスして、前記所望するフィールド・エントリを含む１つまたは複数のアイテムを選択すること、および
    前記選択されたアイテムのうちの１つまたは複数を、前記エクスプローラ表示スキーマに従って前記ユーザに表示すること
    を備えることを特徴とする方法。
12. 前記エクスプローラ表示スキーマを定義することは、前記エクスプローラ表示スキーマによる表示内に含まれる１つまたは複数の装飾要素を定義することを含むことを特徴とする請求項１１に記載の方法。
13. 前記エクスプローラ表示スキーマを定義することは、１つまたは複数のシェル・ビュー・スキーマを定義することを含み、前記シェル・ビュー・スキーマのうちの１つを使用して、前記選択されたアイテムのサブセットを表示することを特徴とする請求項１１に記載の方法。
14. 前記アイテムのうちの１つまたは複数を表示することは、シェル・ブラウザに関連付けられたシェル表示スキーマを使用して、１つまたは複数の選択されたアイテムを表示することを含むことを特徴とする請求項１１に記載の方法。
15. 前記選択されたアイテムのうちの１つを表示することは、シェル・ブラウザに関連付けられたアイテム表示スキーマを使用して、１つまたは複数の選択されたアイテムの表示内に含まれる１つまたは複数の表示属性を提供することを含むことを特徴とする請求項１１に記載の方法。
16. 前記選択されたアイテムを表示することは、前記選択されたアイテムに関する動詞を表示することを含むことを特徴とする請求項１１に記載の方法。
17. 前記動詞は、前記１組の選択されたアイテムのうちの１つまたは複数のセットに対して前記動詞を実施することができるアプリケーションに関連付けられることを特徴とする請求項１６に記載の方法。
18. 前記選択されたアイテムを表示することは、前記選択されたアイテムに関連付けられる１つまたは複数のデータ・クエリを提供することを含むことを特徴とする請求項１１に記載の方法。
19. 前記エクスプローラは、前記データ・クエリのうちの１つまたは複数の結果を表示するように構成されることを特徴とする請求項１８に記載の方法。
20. データ・ストア内の複数のアイテムをユーザに提示するためのエクスプローラであって、
    前記データ・ストア内の前記アイテムのうちの少なくとも一部は１つまたは複数のフィールド・エントリを含み、前記データ・ストア内の前記アイテムのうちの少なくとも１つに関連するフィールド・エントリに対応する所望のフィールド・エントリを選択するためのフィールド・エントリ選択コンポーネントと、
    前記データ・ストアにアクセスして、前記所望のフィールド・エントリを含む１つまたは複数のアイテムを選択するように構成されたアイテム選択コンポーネントと、
    前記選択されたアイテムのうちの１つまたは複数を、エクスプローラ表示スキーマに従ってユーザに提示するように構成された表示提示コンポーネントと
    を備えることを特徴とするエクスプローラ。
21. データ・ストアからの１つまたは複数のアイテムをユーザに提示するためのコンピュータ実行可能アプリケーション・プログラムであって、
    前記データ・ストア内の前記アイテムのうちの少なくとも一部は１つまたは複数のフィールド・エントリを含み、前記データ・ストアにアクセスし、前記フィールド・エントリから選択される所望のフィールド・エントリを含む前記データ・ストアからの１つまたは複数のアイテムを選択するように構成されたアイテム選択モジュールと、
    シェル・ブラウザと対話して、前記選択されたアイテムのうちの１つまたは複数をエクスプローラ表示スキーマに従ってユーザに提示するように構成されたシェル対話モジュールと
    を備えることを特徴とするアプリケーション・プログラム。
22. 前記エクスプローラ表示スキーマは、前記エクスプローラ表示スキーマによる表示内に含まれるべき１つまたは複数の装飾要素を含むことを特徴とする請求項２１に記載のアプリケーション。
23. 前記シェル対話モジュールは１つまたは複数のシェル・ビュー・スキーマを提供するように構成され、選択されたアイテムのサブセットを表示するために、前記シェル・ビュー・スキーマのうちの１つが使用されることを特徴とする請求項２１に記載のアプリケーション。
24. 前記シェル対話モジュールは、シェル・ブラウザに関連付けられた１つまたは複数のシェル表示スキーマを使用して、１つまたは複数の選択されたアイテムを表示するように構成されることを特徴とする請求項２１に記載のアプリケーション。
25. 前記シェル対話モジュールは、シェル・ブラウザに関連付けられたアイテム表示スキーマを使用して、１つまたは複数の選択されたアイテムの表示内に含まれるべき１つまたは複数の表示属性を提供するように構成されることを特徴とする請求項２１に記載のアプリケーション。
26. 前記エクスプローラ表示スキーマは、前記選択されたアイテムに関連する動詞を含むことを特徴とする請求項２１に記載のアプリケーション。
27. 前記動詞は、前記選択されたアイテムのうちの１つまたは複数に対して前記動詞を実行することができるアプリケーションに関連付けられることを特徴とする請求項２６に記載のアプリケーション。
28. 前記エクスプローラ表示スキーマは、前記選択されたアイテムに関連付けられる１つまたは複数のデータ・クエリを含むことを特徴とする請求項２１に記載のアプリケーション。
29. データ・ストア内の複数のアイテムをユーザに提示するためのコンピュータ化された方法であって、
    前記複数のアイテムのうちの少なくとも一部は１つまたは複数のフィールド・エントリに関連付けられ、前記複数のアイテムのうちの少なくとも１つに関連付けられるフィールド・エントリに対応する所望のフィールド・エントリを選択すること、
    エクスプローラ表示スキーマを定義すること、
    前記データ・ストアにアクセスして、前記所望のフィールド・エントリを有する１つまたは複数のアイテムを選択すること、および
    シェル・ブラウザと対話して、前記選択されたアイテムのうちの１つまたは複数を前記エクスプローラ表示スキーマに従って前記ユーザに提示すること
    を備えることを特徴とする方法。
30. 前記エクスプローラ表示スキーマは、
    １つまたは複数の装飾要素、
    前記選択されたアイテムに関連する１つまたは複数の動詞、および／または
    前記選択されたアイテムに関連する１つまたは複数のデータ・クエリ
    を含むことを特徴とする請求項２９に記載の方法。
31. 前記シェル・ブラウザと対話することは、１つまたは複数のシェル・ビュー・スキーマを提供することを含み、前記選択されたアイテムのサブセットを表示するために、前記シェル・ビュー・スキーマのうちの１つが使用されることを特徴とする請求項２９に記載の方法。
32. 前記シェル・ブラウザと対話することは、前記シェル・ブラウザに関連する１つまたは複数のシェル表示スキーマを使用して、１つまたは複数の選択されたアイテムを表示することを含むことを特徴とする請求項２９に記載の方法。
33. 前記シェル・ブラウザと対話することは、前記シェル・ブラウザに関連するアイテム表示スキーマを使用して、１つまたは複数の選択されたアイテムの表示内に含まれるべき１つまたは複数の表示属性を提供することを含むことを特徴とする請求項２９に記載の方法。
34. データ・ストア内のアイテムをユーザに提示するためのエクスプローラを確立するためのコンピュータ化された方法であって、
    前記データ・ストア内の前記アイテムであって、少なくとも一部は１つまたは複数のフィールド・エントリに関連する前記アイテムのうちの少なくとも１つに関連するフィールド・エントリに対応する所望するフィールド・エントリを選択すること、
    前記エクスプローラに関連付けられるエクスプローラ属性を定義すること、および
    前記エクスプローラ属性を含む表示スキーマを用いて、前記所望するフィールド・エントリに関連付けられた前記データ・ストア内の１つまたは複数のアイテムを前記ユーザに提示すること
    を備えることを特徴とする方法。
35. 前記所望するフィールド・エントリは、前記エクスプローラ内に表示される各アイテムに所望されるアイテム・プロパティに関連付けられることを特徴とする請求項３４に記載の方法。
36. 前記エクスプローラ属性は、装飾要素、前記提示されたアイテムに関連付けられた１つまたは複数の動詞、および／または前記提示されたアイテムに関連付けられた１つまたは複数のデータ・クエリを含むことを特徴とする請求項３４に記載の方法。
37. 前記エクスプローラ属性は１つまたは複数のシェル・ビュー・スキーマを含み、前記提示されたアイテムのサブセットを表示するために、前記シェル・ビュー・スキーマのうちの１つが使用されることを特徴とする請求項３４に記載の方法。
38. 前記表示スキーマは、１つまたは複数の提示されたアイテムを表示するために、シェル・ブラウザに関連付けられた１つまたは複数のシェル表示スキーマを含むことを特徴とする請求項３４に記載の方法。
39. 前記表示スキーマは、１つまたは複数の提示されたアイテムの表示内に含まれるべき１つまたは複数の表示属性を提供するために、前記シェル・ブラウザに関連するアイテム表示スキーマを使用することを含むことを特徴とする請求項３４に記載の方法。
40. データ・ストア内の複数のアイテムをユーザに提示するためのエクスプローラを確立するためのコンピュータ化された方法であって、
    前記複数のアイテムであって、少なくとも一部は１つまたは複数のフィールド・エントリに関連付けられる前記複数のアイテムのうちの少なくとも１つに関連するフィールド・エントリに対応する所望するフィールド・エントリを選択すること、
    前記エクスプローラに関連付けられるエクスプローラ属性を定義すること、および
    シェル・ブラウザと対話して、前記エクスプローラ属性を含む表示スキーマを用いて前記所望するフィールド・エントリに関連付けられる前記データ・ストア内の１つまたは複数のアイテムを前記ユーザに提示すること
    を備えることを特徴とする方法。
41. 前記エクスプローラ属性は、装飾要素、前記提示されたアイテムに関連する１つまたは複数の動詞、および／または前記提示されたアイテムに関連する１つまたは複数のデータ・クエリを含むことを特徴とする請求項４０に記載の方法。
42. 前記エクスプローラ属性は１つまたは複数のシェル・ビュー・スキーマを含み、前記シェル・ビュー・スキーマのうちの１つを使用して、前記提示されたアイテムのサブセットを表示することを特徴とする請求項４０に記載の方法。
43. 前記シェル・ブラウザと対話することは、前記シェル・ブラウザによって提供されたシェル表示スキーマを使用して、１つまたは複数の提示されたアイテムを前記ユーザに表示すること含むことを特徴とする請求項４０に記載の方法。
44. 前記シェル・ブラウザと対話することは、前記シェル・ブラウザによって提供されたアイテム表示スキーマからの１つまたは複数の表示属性を使用して、１つまたは複数の提示されたアイテムを前記ユーザに表示することを含むことを特徴とする請求項４０に記載の方法。
    

Images