JP4685186B2 - 様々なタイプおよび様々な物理位置からのアイテムを表示するためのファイルシステム - Google Patents

Description

本発明は、ファイルシステムに関し、より詳細には、様々なタイプおよび様々な物理位置からのアイテムを表示するためのファイルシステムに関する。

現在のコンピュータファイルシステムには、いくつかの望ましくない制限がある。１つの制限は、ユーザが一般に、それらが示されている構造を制御できないことである。換言すれば、フォルダが構成されている場合、ユーザは、構造を選択しなければならず、またその構造を変更するのは難しい。具体的な例として、「音楽」のフォルダでは、ユーザは、アーティスト／アルバムの形式で、音楽ファイルを整理することを選択することができ、各アーティストのすべてのアルバムフォルダが、特定のアーティストのフォルダに分類され、ある特定のアルバムのすべての曲が、そのアルバムのフォルダに分類される。アーティスト／アルバムの形式は、あるタイプの音楽を再生し（例えば２人の異なるアーティストによるジャズを２曲再生するなど）、または異なるアーティストによるアルバムの選曲を再生するのには適していない。

別の問題は、ユーザが、整理するのが難しい多数のファイルを有し得ることである。ユーザによっては、柔軟性を欠いた感覚でファイルを配置し、したがって、それに厳格な階層を設けている。使用可能な文書の増加に伴って、こうしたファイルの管理は、ますます複雑にまた難しくなり、検索および取出しをも難しくしている。共有ファイルなど、他の場所から追加のファイルが使用される場合は、この問題がさらに深刻化する。

ユーザはまた、それぞれ異なる装置、他のＰＣ、またはオンライン上など、様々な場所にあるファイルを取り扱わなければならない。例えば、ユーザは、（音楽番組にアクセスし得る）コンピュータ上で音楽を聞くことを選択することができ、またはオンライン接続して、ウェブサイトから音楽を聞くことができるが、しかし、こうした２つのソース間には、厳密な区分がある。様々な場所からもたらされる音楽は、その構成がそれぞれ異なっており、同じやり方または場所では保たれない。別の例として、企業ネットワークに格納されたファイルは、ユーザが現行のマシン上に有しているファイルからは本質的に分離され得る。

ユーザはまた、何のファイルデータが格納されているかだけでなく、それがどこに格納されているかを追跡しなければならない。例えば、音楽ファイルの場合、ユーザは、様々なシステム上でコピーを保存し、どの音楽ファイルがどこに置かれているかを追跡しようとせざるを得ない。これによって、ファイルがローカルに格納されている場合でさえ、それを見つけることが難しくなり得る。

ユーザが所有しているファイルを見つけて、それに戻ることが難しいこともある。ユーザは、あるファイルをどこに、またどのように格納したかを思い出すのが難しいと感じることがある。フォルダのセット、またさらには類似のファイル群があるならば、探しているファイルを迅速に見つけることがしばしば、ユーザには難しく思われる。見つけるのが困難な場所にファイルが格納されている場合は、位置を突き止めるのがなおさら複雑である。さらに、ユーザがフォルダに十分なファイルを格納している場合、特に、内容が類似している場合には、フォルダを迅速に解析するのがますます難しくなる。

ユーザがネットワーク上のファイルを見つけて、それに戻ることが難しいこともある。ファイルを共有しまた公開することはしばしば難しく、こうしたファイルを、それを使用できるようにする誰かから取得することはしばしば、なおさら難しいことがある。ユーザは一般に、ネットワーク上でファイルを見つけるために必要な様々なサイトおよび名前を、記憶またはマッピングしなければならない。

名前空間も変化することがあり、それによって、何が「正しい」かについて、ユーザを混乱させることがある。これは、様々な名前付けの規則や制限などがあるネットワークには、特に当てはまることである。例えば、一部のオペレーティングシステムは、名前が見えるように、スペース無しの短い名前を必要とすることがある。

プログラムもしばしば、それ独自のディレクトリまたは他の名前空間に、ファイルを保存し、それによって、ユーザがそのファイルへの戻り方を見つけるのが難しくなることがある。プログラムはしばしば、文書保存の既定のディレクトリおよび場所を有する。ユーザはしばしば、そのハードディスク全体を検索し、ファイルの格納場所を推測しなければならない。

関連するアイテムもしばしば、別の場所に格納される。ユーザが所有する関連ファイルは、ハードディスクなどの様々な部分に格納され得る。複数のコンテンツタイプ（画像、音楽、動画など）を含むデジタルメディアサービスの発展に伴って、この問題は、ますます一般的になっている。

本発明は、前記他の欠点を克服するシステムおよび方法を提供することを目的とする。より具体的には、本発明は、異なるタイプおよび異なる物理位置からのアイテムを表示するためのファイルシステムを目的とする。

異なるタイプおよび異なる物理位置からのアイテムを表示するためのファイルシステムが提供される。本発明の一態様によれば、幅広いアイテムが使用可能であり得る。換言すれば、このシステムは、ユーザには、すべてのアイテムが１つの位置からの物のように見えるように、複数の物理位置（様々なハードドライブ、様々なコンピュータ、様々なネットワーク位置など）からのアイテムを表示することができる。例えば、ファイルが物理的には、様々なハードドライブ、様々なコンピュータ、様々なネットワーク位置に格納され得るとしても、ユーザには、その音楽ファイルのすべてが単一の画面上に表示され、ユーザは、ファイルをすべて、１つのビューから操作することができる。

本発明の別の態様によれば、ある範囲が、ディスプレイを含むコンピュータシステム内にアイテムを表示するための方法において使用される。この方法は、アイテムの取り出し元の物理メモリ位置の範囲を定義することを含み、この範囲は、現在のコンピュータメモリ、および少なくとも１つの他の物理位置からなる。クエリが受信されると、クエリに応答して、アイテムが、範囲に定義される物理位置から取り出され、次いで、クエリによって取り出されるアイテムが、ディスプレイ上のビュー内に表示される。ある実施形態では、少なくとも１つの他の物理位置は、別のコンピュータ、ネットワーク上の位置、または外部記憶装置であり得る。ある実施形態では、ディスプレイ上のビューを、アイテムが物理的に格納されている物理位置を示す物理フォルダビュー（ｐｈｙｓｉｃａｌ ｆｏｌｄｅｒ ｖｉｅｗ）に、切り換えることができる。

本発明の別の態様によれば、非ファイルアイテムが、仮想フォルダ内に示され得る。換言すれば、メモリに格納されるファイルは、物理ストアに置かれる。仮想フォルダは、物理ストアに現在示されていないアイテムを含むように作成することができる。非ファイルアイテムの例は、電子メールおよび連絡先である。

本発明の別の態様によれば、非ファイルアイテムを表示するための方法が、ディスプレイおよびアイテムを格納するためのメモリを備えるコンピュータシステム内で実行される。この方法は、クエリによって、非ファイルアイテムとファイルアイテムの両方を検索することを可能にするデータベースを提供することを含む。クエリが受信されると、クエリに一致する非ファイルアイテムとファイルアイテムの両方が取り出され、次いで、クエリに一致するアイテムが、ディスプレイ上に表示される。ある実施形態では、ファイルアイテムに関する選択された情報を含み、また特定の非ファイルアイテム全体を保持し得る、リレーショナルデータベースが提供される。

本発明の別の態様によれば、仮想フォルダ内で、アイテムがユーザに提示される。仮想フォルダは、ディスク上での実際の物理的なファイルシステムの基本構造ではなく、そのメタデータ（ｍｅｔａｄａｔａ）に基づく様々なビューで、ユーザにアイテムを公開する（ｅｘｐｏｓｅ）。したがって、このシステムは、データベース内に格納されているプロパティを取り出すことができ、フォルダなどのコンテナ（ｃｏｎｔａｉｎｅｒ）として、それを提示することができる。ユーザは既に、フォルダの取扱いに精通しているので、類似のやり方で、仮想フォルダを提示することによって、ユーザは、新しいシステムにより速やかに適応することができる。

本発明の別の態様によれば、ユーザは、直接操作によって、仮想フォルダを取り扱うことができる。換言すれば、仮想フォルダを操作するために提供される機構は、従来の物理フォルダを操作するために現在使用されている機構（クリックアンドドラッグ（ｃｌｉｃｋ ａｎｄ ｄｒａｇ）、コピー、ペーストなど）に類似している。

本発明の別の態様によれば、仮想フォルダを操作するためのフィルタが提供される。フィルタは基本的には、アイテムのセットを絞り込むためのツールである。ある実施形態では、フィルタは、別個のアイテムのプロパティに基づいて、動的に生成される。例えば、アイテムセットについて、フィルタ機構では、プロパティを調べることができ、アイテムが概して、プロパティとして、「作成者」を有する場合は、このフィルタは、作成者のリストを提供することができる。次いで、特定の作成者をクリックすると、その作成者を有さないアイテムが消える。これによって、ユーザは内容を絞り込むことができる。

本発明の別の態様によれば、クィックリンク（ｑｕｉｃｋ ｌｉｎｋ）が提供される。ある実施形態では、クィックリンクは、事前定義されたリンクのセット（例えば、ディスプレイの左側に置かれる）であり、それをクリックして、アイテムセットの有用なビューを生成することができる。これらは、プログラムによって事前定義することができ、またはユーザによって設定することができる。例えば「すべての作成者」をクリックすると、作成者ごとにスタックされた（ｓｔａｃｋ）ビューが返され得る。「すべてのドキュメント」では、記憶域全体のすべてのドキュメントのフラットビュー（ｆｌａｔ ｖｉｅｗ）が返され得る。ユーザが、自身のクィックリンクを作成することもできる。例えば、ユーザは、フィルタリングして、２００３年１月に修正されたすべてのドキュメントに絞り込むことがあり、次いで、それをクィックリンクとして保存し得る。

本発明の別の態様によれば、ライブラリが提供される。ライブラリは、互いに関連付けることができる、使用可能なファイルタイプの大きなグループからなる。例えば、写真を１つのライブラリにすることができ、音楽を別のライブラリにすることができ、またドキュメントを別のライブラリにすることができる。ライブラリは、特定のタイプのアイテムに関連するツールおよび動作を提供する。例えば、写真ライブラリには、スライドショー（ｓｌｉｄｅ ｓｈｏｗ）の作成や写真の共有など、写真の操作に関連するツールおよびフィルタがある。

添付の図面と併せて、以下の詳細な説明を参照することによって、本発明がよりよく理解されるようになるので、前述の態様および付随する本発明の利点の多くが、さらに容易に評価されるようになろう。

本発明を実施するのに適した汎用コンピュータシステムのブロック図である。 本発明による仮想フォルダシステムのブロック図である。 ユーザがクエリを提供し、クエリが選択されたファイルとフォルダを取り出して返す、ルーチンを例示するフローチャートである。 仮想フォルダが作成され、既定のクエリ、またはユーザからのクエリに従って画面上に表示される、ルーチンを例示するフローチャートである。 ハードドライブ上の物理的なフォルダ構成によるフォルダ構造のツリー図である。 仮想フォルダ構造のツリー図である。 顧客スタックがさらに、契約および年度でフィルタリングされる、図６の仮想フォルダ構造のツリー図である。 顧客スタックの契約がさらに、年度でフィルタリングされる、図７の仮想フォルダ構造のツリー図である。 契約スタックがさらに、顧客および年度でフィルタリングされ、その顧客がさらに、年度でフィルタリングされる、図６の仮想フォルダ構造のツリー図である。 ドキュメントライブラリのスタックを示す、画面表示を例示する図である。 図１０の「ＡＢＣ社」スタック内のドキュメントを示す画面表示を例示する図である。 図１１のドキュメントについて、スタック機能が選択される画面表示を例示する図である、 図１２のスタック機能について、「作成者でスタック」パラメータが選択される画面表示を例示する図である。 図１３のファイルが作成者でスタックされた画面表示を例示する図である。 スタック機能が選択され、図１４のファイルを再びスタックするために、「カテゴリでスタック」オプションがさらに選択される画面表示を例示する図である。 図１４のファイルがカテゴリで再びスタックされた画面表示を例示する図である。 物理フォルダを表示するためのクィックリンクが選択される画面表示を例示する図である。 図１７の仮想フォルダスタックのファイルを含む物理フォルダが示される画面表示を例示する図である。 ユーザが仮想フォルダを直接に操作することができるルーチンを例示するフローチャートである。 新しい「ウエストコースト」スタックが図１０のスタックに追加された画面表示を例示する図である。 図２０の「ＡＢＣ社」スタックから「ウエストコースト」スタックに、ファイルをコピーするために直接操作が使用される画面表示を例示する図である。 新しいフィルタ条件を動的に生成するためのルーチンを例示するフローチャートである。 フィルタ条件の選択に基づいて、システムがアイテムをフィルタリングするためのルーチンを例示するフローチャートである。 図１０のスタックが、条件「ＡＢ」でフィルタリングされた画面表示を例示する図である。 図１０のスタックが、条件「ＡＢＣ」でフィルタリングされた画面表示を例示する図である。 図１０のスタックについて、フィルタ条件「２００２年」が選択される画面表示を例示する図である。 図１０のスタックが「２００２年」でフィルタリングされた画面表示、およびフィルタ条件「月」の追加の選択を例示する図である。 フィルタリング対象の月を選択するためのリストが提示される画面表示を例示する図である。 図１０のスタックが１月でさらにフィルタリングされており、またフィルタ条件「日付」をさらに示している画面表示を例示する図である。 新しいクィックリンクを作成するためのルーチンを例示するフローチャートである。 図２９のフィルタリングに基づいて、「１月の作業」と称される新しいクィックリンクを作成するための画面表示を例示する図である。 「すべての作成者」クィックリンクが選択される画面表示を例示する図である。 図３２のすべての作成者のリストが提示される画面表示を例示する図である。 図３３のリストから、「作成者１」が選択されており、また作成者１のすべてのドキュメントが表示される、画面表示を例示する図である。 新しいライブラリを作成するためのルーチンを例示するフローチャートである。 使用可能な様々なライブラリのコレクションが示される画面表示を例示する図である。 仮想フォルダコレクションの範囲を定義するためのルーチンを例示するフローチャートである。 仮想フォルダコレクションの範囲を形成し得る、様々なソースを例示するブロック図である。 仮想フォルダコレクション内に、非ファイルアイテムを含めるためのルーチンを例示するフローチャートである。 仮想フォルダ内に含まれる様々な非ファイルアイテムを示す画面表示を例示する図である。

本発明は、仮想フォルダを対象とする。仮想フォルダは、ファイルシステムで、現在使用されているのと同じまたは類似のユーザインターフェースを使用する。仮想フォルダは、通常のファイルおよびフォルダ（ディレクトリとも称される）を、ディスク上での実際の物理的なファイルシステムの基本構造ではなく、そのメタデータに基づく様々なビューで、ユーザに公開する。位置に依存しないビューが作成され、このビューによって、ユーザは、ファイルシステムを管理するために現在使用されているのと類似のコントロールを使用して、ファイルおよびフォルダを操作することができる。一般に、これは、管理および構成がシステムの別個の部分として行われるのではなく、ファイル自体内の固有のプロパティに基づいて、ユーザがファイルを構成し再配置できることを意味する。仮想フォルダは、ファイルまたはアイテムの１つのビューが、様々な物理位置にあるファイルまたはアイテムを公開し得るように、同じコンピュータ内の複数のドライブ、複数のコンピュータ間、あるいは様々なネットワーク位置からなど、様々な物理位置からのファイルまたはアイテムを示すことができる。

仮想フォルダのモデリングは、従来の非ファイルのエンティティにも使用することができる。この１つの応用は、ファイルおよびフォルダ（すなわちオブジェクトおよびコンテナ）に従来の非ファイルエンティティを示す類似の１組のユーザインターフェースをもつことである。こうした非ファイルエンティティの一例は、電子メールであり、別の例は、連絡先データベースからの連絡先情報である。このようにして、仮想フォルダによって表示されるデータがファイルからのデータか、それとも非ファイルエンティティからのデータであるかに関係なく機能する、場所に依存しない、メタデータベースのビューシステムが提供される。一般に、こうした態様では、通常のユーザインターフェース技術（ドラッグアンドドロップ、ダブルクリックなど）と、様々なデータタイプの充実した統合の活用の両方を用いて、ユーザにファイルおよびデータを操作させる点で、より多くの柔軟性がもたらされる。

図１および以下の議論は、本発明を実施することができる適切なコンピューティング環境について、簡潔で一般的な説明を提供することを意図している。必須ではないが、本発明について、パーソナルコンピュータによって実行されるプログラムモジュールなどの、コンピュータ実行可能命令の一般的な文脈で説明する。一般に、プログラムモジュールは、特定のタスクを実行し、特定の抽象データ型を実装するルーチン、プログラム、キャラクタ（ｃｈａｒａｃｔｅｒ）、コンポーネント、データ構造体などを含む。当業者が理解するように、本発明は、ハンドヘルド（ｈａｎｄ−ｈｅｌｄ）装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含めて、他のコンピュータシステム構成で実施することができる。本発明は、タスクが通信ネットワークを介してリンクされるリモート処理装置によって実施される、分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリ記憶装置に置くことができる。

図１を参照すると、本発明を実施するための例示的なシステムが、処理装置２１、システムメモリ２２およびシステムバス２３を含む、従来のパーソナルコンピュータ２０の形態の汎用コンピューティング装置を含んでおり、このシステムバスは、システムメモリ２２を含めて様々なシステムコンポーネントを処理装置２１に結合する。システムバス２３は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチュアのいずれかを使用するローカルバスを含めて、いくつかのタイプのバス構造のいずれかであり得る。システムメモリは、読取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）２４、ランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）２５を含む。起動時などに、パーソナルコンピュータ２０内の要素間で情報を転送する助けをする基本ルーチンを含む、基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）が、ＲＯＭ２４に格納される。パーソナルコンピュータ２０はさらに、ハードディスク３９から読み出しまたはそこに書き込むためのハードディスクドライブ２７、取出し可能磁気ディスク２９から読み出しまたはそこに書き込むための磁気ディスクドライブ２８、およびＣＤ−ＲＯＭや他の光媒体など、取出し可能光ディスク３１から読み出しまたはそこに書き込むための光ディスクドライブ３０を含む。ハードディスクドライブ２７、磁気ディスクドライブ２８および光ディスクドライブ３０は、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ドライブインターフェース３４によって、それぞれシステムバス２３に接続される。ドライブおよびそれに関連するコンピュータ読取り可能媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュール、およびパーソナルコンピュータ２０の他のデータの不揮発性ストレージを提供する。本明細書で説明する例示的な環境は、ハードディスク３９、取出し可能磁気ディスク２９および取出し可能光ディスク３１を用いるが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイ（Ｂｅｒｎｏｕｌｌｉ）カートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など、コンピュータによってアクセス可能なデータを格納することができる他のタイプのコンピュータ読取り可能媒体を、例示的なオペレーティング環境で使用することもできることを当業者には理解されたい。

オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含めて、複数のプログラムモジュールを、ハードディスク３９、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納することができる。ユーザは、キーボード４０およびポインティング装置４２などの入力装置を介して、コマンドおよび情報を、パーソナルコンピュータ２０に入力することができる。他の入力装置（図示せず）は、マイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力装置はしばしば、システムバス２３に結合されるシリアルポートインターフェース４６を介して、処理装置２１に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）などの他のインターフェースによって接続することもできる。モニタ４７の形態のディスプレイもまた、ビデオカードやアダプタ４８などのインターフェースを介して、システムバス２３に接続される。１つまたは複数のスピーカ５７を、オーディオアダプタ５６などのインターフェースを介して、システムバス２３に接続することもできる。ディスプレイおよびスピーカに加えて、パーソナルコンピュータは一般に、プリンタなど他の周辺出力装置（図示せず）を含む。

パーソナルコンピュータ２０は、リモートコンピュータ４９など、１つまたは複数のパーソナルコンピュータとの論理接続を用いる、ネットワーク化された環境で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス（ｐｅｅｒ ｄｅｖｉｃｅ）または他の一般的なネットワークノードとすることができ、一般に、パーソナルコンピュータ２０に関して上述した要素の多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）５１および広域エリアネットワーク（ＷＡＮ）５２を含む。こうしたネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネットおよびインターネットでは一般的である。

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

図１に示すタイプのシステムで実行される際に、本発明は、仮想フォルダを使用し、この仮想フォルダによって、ユーザがファイル操作およびフォルダナビゲーション（ｆｏｌｄｅｒ ｎａｖｉｇａｔｉｏｎ）（ブラウズ）についての基本的なタスクを実施し、また新しい特徴において活用され得るさらに高いレベルのストレージ機能を提供することが、一層容易になる。仮想フォルダは、ディスク上での実際の物理的なファイルシステムの基本構造ではなく、そのメタデータに基づく様々なビューで、ユーザにファイルおよびアイテムを公開する。

図２は、本発明による仮想フォルダシステム２００のブロック図である。以下で詳述するように、仮想フォルダでは、ユーザは、データをどのように表示するかを制御する「ピボット」を変更することができる。例として、ユーザは、アルバムごとに分類され得るすべての曲のフラットリストで、その音楽を見ることができる。あるいは、ユーザは、ジャンル、アーティストまたは年度だけを示すビューに切り換えることができる。ユーザは、当面の仕事に適したオブジェクトだけが見えるように、ビューを調整することができる。これによって、ブラウズ体験が向上し、フォルダをさらにナビゲートする（進むと戻るの両方とも（ｂｏｔｈ ｄｏｗｎ ａｎｄ ｂａｃｋ ｕｐ））必要がなくなる。同じ教訓および機能が、ファイルとして格納されていない他のデータ型のモデリングにも適用される。例えば、連絡先を、このようにして、ユーザに公開することができ、単調なアドレス帳によって提供されるのよりもそれらの操作が親しみやすいインターフェース機能および充実した基盤が、ユーザに提供される。

図２に示すように、仮想フォルダシステム２００は、フォルダプロセッサ２１０、リレーショナルデータベース２３０、仮想フォルダ記述データベース２３２、他のシェルフォルダコンポーネント（ｏｔｈｅｒ ｓｈｅｌｌ ｆｏｌｄｅｒｓ ｃｏｍｐｏｎｅｎｔ）２３４、フォルダハンドラコンポーネント（ｆｏｌｄｅｒ ｈａｎｄｌｅｒ’ｓ ｃｏｍｐｏｎｅｎｔ）２３６、およびシェルブラウザ／ビューコンポーネント（ｓｈｅｌｌ ｂｒｏｗｓｅｒ ａｎｄ ｖｉｅｗ ｃｏｍｐｏｎｅｎｔ）２４０を含む。フォルダプロセッサ２１０は、ネーティブ処理コードコンポーネント（ｎａｔｉｖｅ ｈａｎｄｌｉｎｇ ｃｏｄｅ ｃｏｍｐｏｎｅｎｔ）２１２、ハンドラファクトリコンポーネント（ｈａｎｄｌｅｒ ｆａｃｔｏｒｙ ｃｏｍｐｏｎｅｎｔ）２１４、プロパティ作成コンポーネント２１６、行セット解析コンポーネント２１８、クエリビルダコンポーネント（ｑｕｅｒｙ ｂｕｉｌｄｅｒ ｃｏｍｐｏｎｅｎｔ）２２０、列挙子コンポーネント２２２、およびプロパティファクトリコンポーネント（ｐｒｏｐｅｒｔｙ ｆａｃｔｏｒｙ ｃｏｍｐｏｎｅｎｔ）２２４を含む。

リレーショナルデータベース２３０は、システム内のすべてのファイルに関するプロパティを格納する。それは、連絡先などのいくつかのアイテム（すなわち非ファイルアイテム）をも、完全に格納する。一般に、それは、それが含むファイルおよびアイテムのタイプに関するメタデータを格納する。リレーショナルデータベース２３０は、クエリビルダ２２０から、ＳＱＬクエリを受信する。またリレーショナルデータベース２３０は、行セット解析コンポーネント２１８に、アイテムコラムごとに１行、列がアイテムプロパティである、ＳＱＬ行セットを送信する。

仮想フォルダ記述データベース２３２は、仮想フォルダの記述を含む。仮想フォルダ記述データベース２３２は、クエリビルダコンポーネント２２０に、フォルダ内に表示するタイプのリスト、初期フィルタ、および（範囲からの）結果表示の物理位置を含めて、データを送信する。

他のシェルフォルダコンポーネント２３４に関して、フォルダプロセッサ２１０は、ハンドラまたはプロパティのために、すべてのファイルを含めてアイテムの多くのタイプからの既存のシェルフォルダに委任する。他のシェルフォルダコンポーネント２３４は、他のフォルダからプロパティファクトリ２２４に、プロパティを送る。他のシェルフォルダコンポーネントはまた、ハンドラファクトリ２１４に、ハンドラを送る。

フォルダハンドラコンポーネント２３６は、連絡先など、データベース内だけに存在するアイテムに関するコードの振る舞いを提供する。これによって、非ファイルアイテムがファイルのように動作することが可能になる。フォルダハンドラコンポーネント２３６は、ハンドラファクトリ２１４に、ハンドラを送る。

ネーティブ処理コードコンポーネント２１２では、フォルダプロセッサ２１０は、アイテムのプロパティに基づいて、特定のハンドラを直接実行する。ネーティブ処理コードコンポーネント２１２は、ハンドラファクトリ２１４に、ハンドラを送る。ネーティブ処理コードコンポーネント２１２およびフォルダハンドラコンポーネント２３６では、すべての名前空間と同様に、仮想フォルダは、そのアイテムに関する１組のハンドラ（コンテキストメニュー（ｃｏｎｔｅｘｔ ｍｅｎｕ）、アイコン、サムネイル（ｔｈｕｍｂｎａｉｌ）、ヒント）を提供しなければならない。これら（ヒント、データオブジェクト、ドラッグ−ドロップハンドラ（ｄｒａｇ−ｄｒｏｐ ｈａｎｄｌｅｒ）、背景コンテキストメニューなど）のほとんどについて、仮想フォルダは、それが保持するすべてのタイプに共通の（ネーティブ）ハンドラを提供する。しかし、タイプの作成者が提供しなければならないその他（アイテム自体に関するコンテキストメニュー、書込み可能プロパティストア（ｐｒｏｐｅｒｔｙ ｓｔｏｒｅ）など）がある。また既定のハンドラは、無効にすることができる。仮想フォルダは、ファイルに、これを再利用することができ、非ファイルアイテムがそれを行えるようにする。

ハンドラファクトリ２１４は、ＩＤリストを取り出し、コンテキストメニュー、アイコンなどを提供する、コードの振る舞いを生成する。一般に、フォルダプロセッサ２１０は、ネイティブハンドラ、外部ハンドラを使用し、あるいはネーティブ処理コードコンポーネント２１２、他のシェルフォルダコンポーネント２３４、およびフォルダハンドラコンポーネント２３６に関して上述したように、ハンドラを取得するため、他のシェルフォルダに委任する。ハンドラファクトリコンポーネント２１４は、ビューで要求されたように、ビュー２４０のシェルブラウザにハンドラを送る。ハンドラファクトリコンポーネント２１４は、プロパティ作成２１４に、プロパティハンドラを送る。

プロパティ作成２１６は、カット、コピーおよびペーストなどユーザの意図を、ファイルまたはアイテムのプロパティ権に変換する。シェルブラウザ／ビューコンポーネント２４０は、プロパティ作成２１６に、直接操作（カット／コピー／ペースト）またはメタデータの編集を含めたデータを送る。一般に、仮想フォルダでは、アイテムのプロパティに基づく構成が表示されるので、移動およびコピー（ドラッグ−ドロップ）などの操作が、こうしたプロパティに対する編集になる。例えば、作成者でスタックされたビュー内で、作成者１から作成者２に、あるドキュメントを移動することは、作成者の変更を意味する。プロパティ作成コンポーネント２１６は、この機能を実行する。

行セット解析２１８は、データベースの行セットを取り出し、すべてのアイテムプロパティを、シェルＩＤリスト構造体に格納する。行セットは、仮想フォルダの区分的な定義を取り出して、ＳＱＬ列を作成し、次いで、このＳＱＬ列が、データベースに発行される。行セット解析コンポーネント２１８は、列挙子コンポーネント２２２に、ＩＤリストを送信する。また行セット解析２１８は、上述のように、リレーショナルデータベース２３０から、アイテムにつき１行、列がアイテムプロパティである、ＳＱＬ行セットを含めてデータを受信する。

クエリビルダコンポーネント２２０は、ＳＱＬクエリを作成する。クエリビルダコンポーネント２２０は、列挙子コンポーネント２２２から、ナビゲーションによる新しいファイルを含めて、データを受信する。クエリビルダコンポーネント２２０は、仮想フォルダ記述データベース２３２からも、フォルダ内に表示するタイプのリスト、初期フィルタ、および（範囲からの）結果表示の物理位置を含めてデータを受信する。クエリビルダコンポーネント２２０はリレーショナルデータベース２３０にＳＱＬクエリを送る。

一般に、クエリビルダコンポーネント２２０は、１組の行（すなわちテーブル）を含む。これは、クエリの実行によってもたらされる。行セット解析コンポーネント２１８は、それぞれの行を取り出し、列の名前を用いることによって、その行をＩＤリストに変換する。ＩＤリストは、名前空間内のアイテムを参照するために使用される周知のシェル構造体である。こうすることによって、仮想フォルダは、残りのシェルの他のいずれの名前空間のようにもなることができる。またこのデータをキャッシュすることによって、データベースアクセスの保持に役立ち、それによって、コストが最小限に抑えられ得る。

列挙子コンポーネント２２２は、仮想フォルダのナビゲーションに応答して動作する。上述のように、列挙子コンポーネント２２２は、行セット解析２１８から、ＩＤリストを受信し、ナビゲーションによる新しいファイルを、クエリビルダコンポーネント２２０に送る。列挙子２２２は、ナビゲーション後にビューに戻され、または挿入されるＩＤリストを含めてデータを、シェルブラウザ／ビューコンポーネント２４０に送る。

プロパティファクトリコンポーネント２２４は、ＩＤリストおよびプロパティ識別子を取り出し、こうしたプロパティの値を返す。プロパティファクトリコンポーネント２２４は、ハンドラファクトリコンポーネント２１４から、プロパティハンドラを含めてデータを受信する。上述のように、プロパティファクトリコンポーネント２２４は、他のシェルフォルダコンポーネント２３４からも、他のフォルダからのプロパティを含めてデータを受信する。プロパティファクトリコンポーネント２２４はまた、ビューによる要求に応じて、アイテムプロパティを含めてデータを、シェルブラウザ／ビューコンポーネント２４０に送る。

シェルブラウザ／ビューコンポーネント２４０は、ウィンドウ内に、フォルダの内容を表示し、クリック、ドラッグ、ナビゲーションなど、表示されたファイルまたはアイテムとのすべてのユーザ対話を処理する。したがって、シェルブラウザ／ビューコンポーネント２４０は、ユーザ操作を受信する。またシェルブラウザ／ビューコンポーネント２４０は、フォルダから、この場合はフォルダプロセッサ２１０から、それが必要とするコードの振る舞いに関するデータを取得する。

上述のように、仮想フォルダは、ディスク上での実際の物理的なファイルシステムの基本構造ではなく、そのメタデータに基づく様々なビューで、ユーザに、通常のファイルおよびフォルダ（ディレクトリとも称される）を公開する。したがって、そのシステムはデータベースに格納されているプロパティを取り出し、フォルダのようなコンテナとして、それを表示することができる。ユーザは、フォルダの取扱いに精通しているので、同じようなやり方で、仮想フォルダを提示することによって、ユーザは、新しいシステムにより速やかに適応することができる。

図３は、ユーザがクエリを提供し、クエリが選択されたアイテムを取り出して返す、ルーチン３００を例示するフローチャートである。ブロック３０２で、フォルダプロセッサは、ユーザからクエリを取得する。ブロック３０４で、フォルダプロセッサは、リレーショナルデータベースにクエリを渡す。ブロック３０６で、リレーショナルデータベースは、フォルダプロセッサに結果を返す。ブロック３０８で、フォルダプロセッサは、仮想フォルダおよびアイテムの形で、ユーザに結果を提供する。

図４は、仮想フォルダが作成され、既定クエリ、またはユーザからのクエリに従って画面上に表示される、ルーチン３２０を例示するフローチャートである。ブロック３２２で、まずユーザが仮想フォルダを開く場合に、既定クエリが使用される。この既定クエリは、レジストリから取得される。例えば、音楽ライブラリのための既定クエリは、アルバムごとに分類されたすべての曲を示すためのクエリであり得る。ブロック３２４で、フォルダプロセッサは、このクエリのためのクエリオブジェクト（ｑｕｅｒｙ ｏｂｊｅｃｔ）を作成し、次いで、リレーショナルデータベースに、このクエリを渡す。ブロック３２６で、リレーショナルデータベースは、クエリの結果を生成し、データベースの行と列として、フォルダプロセッサにそれを渡す。

ブロック３２８で、フォルダプロセッサは、こうした結果を取得し、データ行と列から、列挙子構造体に、それを変換し、この列挙子構造体が、フォルダビューによって使用され、ユーザが対話できるように、結果として得られた仮想フォルダおよびアイテムが、画面上に並べられる（ｐｏｐｕｌａｔｅ）。判断ブロック３３０で、ユーザは、（別のクエリまたは「ピボット」を発行することによって）ビューを変更するかどうかを判断する。例えば、ユーザは、「すべてのアーティストを表示」ピボットを発行し得る。ユーザがビューの変更を望む場合は、このルーチンは、ブロック３２４に戻り、フォルダプロセッサは、リレーショナルデータベースに、この新しいクエリを渡し、結果の新しい行と列を受信し、新しい列挙子構造体を作成する。次いで、このプロセスは、前述のように続き、「アーティスト」オブジェクトを画面に取り出すための列挙子を使用して、フォルダビューがクリアされ更新される。

ある例では、ユーザが中をナビゲートできるコンテナを表す、アルバムオブジェクトが提供される。例えば、「ビートルズ」アルバムをダブルクリックすると、ビートルズのすべての曲が見えるように、ビューが移動する。フォルダプロセッサは、「すべてのビートルズ曲を表示」クエリを、リレーショナルデータベースに発行し、このクエリは、それらの曲についてのデータ行と列を返す。フォルダプロセッサは、こうしたすべての曲の列挙子を作成し、次いで、この列挙子が、画面上に取り出される。

ユーザはまた、仮想フォルダをブラウズする間、どの時点でも、ビューを選択することができる。上記の例では、ビートルズの曲だけの表示に絞り込んだ後で、ユーザは、単にアルバムによって曲を表示するビューに変更することができる。アイテムのビューを別の表示に変更するプロセスは、「スタッキング（ｓｔａｋｉｎｇ）」と称される。これは、アイテムが概念的に、その表示に基づく「スタック」に分類されるからである。この場合、曲が、様々なアルバムのそれぞれのスタックに並べ換えられる。次いで、ユーザは、こうしたスタックのうちの１つ内にナビゲートし、その特定のアルバムからの曲だけを見ることができる。再度、ユーザは、こうした残りの曲のビューを、あるプロパティ（例えば格付けなど）に基づくスタックに並べ換えることができる。格付けプロパティが選択された場合、そのビートルズアルバムからの曲が、１、２または３星の格付けのスタックで表示される。

それぞれのクエリの結果は、どの物理位置が範囲内に含まれるかに依存する。例えば、ユーザの「マイドキュメント」フォルダ内のフォルダだけを含むように、範囲を設けることができる。あるいは、範囲は、コンピュータ上のすべてのフォルダ、さらにはネットワークで接続された複数のコンピュータ上のすべてのフォルダを含み得る。ユーザは、範囲プロパティシート（ｓｃｏｐｅ ｐｒｏｐｅｒｔｙ ｓｈｅｅｔ）を用いて、範囲を見て変更することができる。ある例では、範囲プロパティシートは、仮想フォルダを右クリックし、「プロパティ」を選択することによって、公開することができる。ユーザは、新しいフォルダを、範囲に追加し、または以前に追加されたフォルダを削除することができる。

仮想フォルダが特に有用であるユーザ群は、知識労働者である。仮想フォルダによって、知識労働者は、ファイルタイプ、プロジェクト、ケース番号、作成者などで、ドキュメントの表示を容易に切り換えることができる。知識労働者はそれぞれ、異なる方法で、ドキュメントを整理する傾向があるので、仮想フォルダを使用して、こうした様々な嗜好に対処することができる。

図５は、ハードドライブ上の物理的なフォルダ構成によるフォルダ構造のツリー図である。この物理フォルダの構成は、従来のフォルダの実施例に基づいており、この従来のフォルダ実施例は、ＮＴＦＳまたは他の既存のファイルシステムに基づくことができる。こうしたフォルダは、その構造が、ディスク上の実際の物理的なファイルシステムの基本構造に基づいているので、物理フォルダと称される。以下で詳述するように、これは、仮想フォルダとは対照的であり、仮想フォルダでは、物理フォルダを操作するために現在使用されているのと類似のやり方で、ユーザがファイルおよびフォルダを操作できるようにする、位置に依存しないビューが作成される。

図５に示すように、フォルダ４００は、「マイドキュメント」フォルダである。第１のレベルでは、フォルダ４００は、顧客１、２、３にそれぞれ対応する、フォルダ４１０、４２０、４３０を含む。第２のレベルでは、フォルダ４１０、４２０、４３０は、フォルダ４１１、４２１、４３１を各々含み、そのそれぞれが、選択された顧客の契約に対応する。第３レベルでは、フォルダ４１１、４２１、４３１はそれぞれ、フォルダ４１２、４２２、４３２を各々含み、そのそれぞれが、２００１年に対応する。第３のレベルでは、フォルダ４１１、４２１、４３１のそれぞれは、フォルダ４１３、４２３、４３３をも各々含み、そのそれぞれが２００２年に対応する。

図５に示すような物理フォルダファイル構造をナビゲートしたいユーザに、いくつかの障壁が提示されることが理解されよう。例えば、作成したすべての契約を取り扱いたい場合、ユーザは、顧客１の契約を取り扱うために、まずフォルダ４１１に移動する必要があり、次いで、顧客２の契約に達するには、フォルダ４２１に再び移動する必要があり、また顧客３の契約のために、再び、フォルダ４３１に再移動しなければならない。こうした構造によって、ユーザがすべての契約にアクセスするのが難しくなり、一般に、すべての契約を同時に見て操作することができなくなる。同様に、２００１年に作成されたすべての契約を見たい場合は、ユーザは、フォルダ４１２、４２２、４３３にそれぞれ、移動および再移動しなければならない。以下に詳述するように、本発明の仮想フォルダによって、改良型のファイルシステム構造がもたらされる。

図６は、仮想フォルダ構造のツリー図である。以下で詳述するように、仮想フォルダでは、都合がよいやり方で、ユーザがファイルおよびフォルダを操作できるようにする、位置に依存しないビューが作成される。図６に示すように、仮想フォルダは、スタックで表示される。仮想フォルダ５００は、「すべてのアイテム」フォルダである。第１のレベルでは、仮想フォルダ５００は、顧客、契約、年度にそれぞれ対応する、仮想フォルダ５１０、５２０および５３０を含む。以下で詳述するように、この構造では、ユーザは、所望のパラメータに従って、ファイルにアクセスすることができる。

図７は、図６の仮想フォルダ構造のツリー図であり、第２のレベルで、仮想フォルダ５１０はさらに、契約および年度にそれぞれ対応する、仮想フォルダ５１１および５１２を含む。換言すれば、仮想フォルダ５１０の顧客スタックがさらに、契約および年度でフィルタリングされる。どのファイルおよびアイテムがそれぞれの仮想フォルダに含まれるかを判断するためのプロセスについて、以下に詳述する。

図８は、図７の仮想フォルダ構造のツリー図であり、第３のレベルで、仮想フォルダ５１１は、ある年度に対応する仮想フォルダ５１３を含む。換言すれば、仮想フォルダ５１１の契約スタックがさらに、年度でフィルタリングされる。仮想フォルダ５１０、５１１および５１３の仮想フォルダ構造は、顧客、契約および年度によって構造化されているが、図９を参照して以下で詳述するように、仮想フォルダによって、他の構造化順序が生じるようにできることが理解されよう。

図９は、図６の仮想フォルダ構造のツリー図であり、第２のレベルでは、仮想フォルダ５２０はさらにフィルタリングされて、顧客および年度に対応する仮想フォルダ５２１および５２２になっている。第３のレベルでは、仮想フォルダ５２１がさらにフィルタリングされて、年度に対応する仮想フォルダ５２３になっている。図８と９の組織構造の相違は、仮想フォルダシステムの柔軟性を示すのに役立つ。換言すれば、図５に示すような物理ファイル構造は、位置に依存したビューによる依存型であるのに対して、仮想フォルダシステムでは、ユーザは、所望のパラメータに従って仮想フォルダをナビゲートすることができる。

図１０は、ドキュメントライブラリのスタックを表示する、画面表示６００を例示する図である。上述のように、スタックを使用して、あるタイプの仮想フォルダを示すことができる。以下で詳述するように、画面表示６００は、クィックリンク要素６１０〜６１３、フィルタ要素６２０〜６２６、動作要素６３０〜６３３、情報および制御要素６４０〜６４５、ならびに仮想フォルダスタック６５１〜６５５を含む。

クィックリンク要素は、「すべてのカテゴリ」クィックリンク６１０、「すべての作成者」クィックリンク６１１、「１月の作業」クィックリンク６１２、および追加のクィックリンク６１３を表示するための選択を含む。以下で詳述するように、クィックリンクは、仮想フォルダの所望のナビゲーションを実施するために、ユーザによって選択される。クィックリンクは、システムによって提供することができ、また、あるクィックリンクによって、ユーザによって作成され保存される。

フィルタ要素は、「フィルタ」インジケータ６２０、空欄入力６２１、「日付順」インジケータ６２２、「年度」セレクタ６２３、「作成者を選択」セレクタ６２４、６２５「カテゴリを選択」セレクタ６２５、および「フィルタの追加」セレクタ６２６を含む。「フィルタ」インジケータ６２０は、ユーザに、以下のアイテムを使用して、仮想フォルダまたはアイテムをフィルタリングできることを指示する。空欄入力６２１は、ユーザが所望の新しいフィルタ条件を入力できる領域を提供する。「日付順」インジケータ６２２は、ユーザに、「年度」セレクタ６２３から日付を選択することよって、仮想フォルダおよびアイテムを、その選択された年度でフィルタリングできることを指示する。「作成者を選択」セレクタ６２４は、ユーザが特定の作成者によってフィルタリングすることを可能にする。「カテゴリを選択」セレクタ６２５は、ユーザが、選択されたカテゴリに従ってフィルタリングすることを可能にする。「フィルタの追加」セレクタ６２６は、ユーザが、追加のフィルタを画面上に引き出せるようにする。

動作セレクタは、「新しいカテゴリを作成」セレクタ６３０、「動作」セレクタ６３１、６３２、および「追加の動作」セレクタ６３３を含む。以下で詳述するように、提示される動作は、一般に望まれる機能とすることができ、または、より具体的には、現在表示されている仮想フォルダのタイプに有用な動作を目的とする。例えば、「新しいカテゴリを作成」セレクタ６３０は、新しいスタックで表示される新しいカテゴリを作成するために、ユーザによって選択することができる。

上述のように、「動作」セレクタ６３１、６３２は、より具体的には、表示されているフォルダまたはアイテムのタイプを対象とすることができる。例えば、現在の表示が、ドキュメントライブラリであれば、このドキュメントライブラリ用に、「動作」セレクタ６３１、６３２は、編集または添付作成など、特に文書向けの動作を対象とすることができる。現在のライブラリが写真ライブラリであれば、「動作」セレクタ６３１、６３２は、写真アルバムの形成や他のユーザとの写真の共有など、具体的に、写真を対象とする動作向けとすることができる。

情報および制御要素は、情報行６４０、６４１、コントロール行６４２、バックスペースコントロール（ｂａｃｋｓｐａｃｅ ｃｏｎｔｒｏｌ）６４３および情報行６４４、６４５を含む。情報行６４０、６４１は、仮想フォルダまたはアイテムの現在のナビゲーションに関する情報を提供する。この例では、情報行６４０は、現在のナビゲーションがドキュメントライブラリに対して行われていること示し、情報行６４１は、より完全なナビゲーションを示し、ドキュメントライブラリが、ストレージ領域にあることを表示する。コントロール行６４２は、いくつかの標準のコントロールを提供し、バックスペースボタン６４３は、ユーザがナビゲーションを逆行できるようにする。情報行６４４は、現在のナビゲーションのコンテンツに関する数値情報を提供する。この例では、情報行６４４は、ドキュメントライブラリのスタック内に、１００ＭＢを占める４１個のアイテムが存在することを示す。情報行６４５は、選択されたファイルに関する追加情報など、追加の情報を提供するために使用可能である。

ドキュメントライブラリのスタックは、「ＡＢＣ社」スタック６５１、「バックアップスタック」６５２、「事業計画」スタック６５３、「ＸＹＺ社」スタック６５４、および「マーケティングレポート」スタック６５５を含む。それぞれのスタック上の数字は、いくつのアイテムが、各スタックに含まれるかを示す。例えば、「ＡＢＣ社」スタック６５１は、８個のアイテムを含むように示されている。スタックのアイテム総数は、情報行６４４に示されるアイテム数になり、上述のように、この例では、４１である。所望のアイテムを選択するために、ユーザが使用できる選択ボックスＳＢが提供される。図１１に関して以下で説明するように、「ＡＢＣ社」スタック６５１を選択することによって、そのスタックのアイテムのビューがもたらされる。

図１１は、図１０の「ＡＢＣ社」スタック６５１内のアイテムを示す画面表示を例示する図である。情報ライン６４０、６４１がここでは、現在のナビゲーションが「ＡＢＣ社」スタックを表示していることを示すことに留意されたい。「ＡＢＣ社」スタック６５１が、ドキュメント１〜８にそれぞれ対応する、８つのドキュメント７５１〜７５８を含むように示されている。それに対応して、情報ライン６４４は、２０ＭＢのメモリを占める８個のアイテムが存在することを示す。図１１のドキュメントは、ＡＢＣ社スタック内のスタックに、さらに分類することができる。換言すれば、図１２〜１６を参照して以下で説明するように、ＡＢＣ社スタック６５１によって示される仮想フォルダ内に、追加の仮想フォルダを構成して、文書を保持することができる。

図１２は、図１１のドキュメントについて、スタック機能が選択される、画面表示を例示する図である、図１２に図示するように、ユーザは、機能ボックス７６０を引き出すことができる。機能ボックス７６０は、「ビュー」選択７６１、「アイコンの整列」選択７６２、「スタック」選択７６３、「リフレッシュ」選択７６４、「１つ上のフォルダを開く」選択７６５、「カット」選択７６６、「コピー」選択７６７、「元に戻す」選択７６８、「新しい」選択７６９、および「プロパティ」選択７７０を含む。「スタック」選択７６３を囲むように、選択ボックスＳＢが示されている。

図１３は、図２のスタック機能について、「作成者でスタック」パラメータが選択される画面表示を例示する図である。図１３に示すように、様々なスタックオプションを提示するボックス７８０が表示されている。スタックオプションは、「スタックを元に戻す」オプション７８１、「カテゴリでスタック」オプション７８２、「作成者でスタック」オプション７８３、および「ユーザでスタック」オプション７８４を含む。「作成者でスタック」オプション７８３を囲む、選択ボックスＳＢが示されている。

図１４は、図１３のファイルが作成者でスタックされた画面表示を例示する図である。図１４に示すように、スタック７９１および７９２は、作成者ボブおよびリサにそれぞれ対応する。それぞれのスタック上の数字で示されるように、ボブのスタック７９１は、２つのアイテムを含み、リサのスタック７９２は、５つのアイテムを含む。アイテム７５８（ドキュメント８に対応する）は、作成者を有していなかったので、したがって、「作成者」スタックには含まれない。スタック７９１および７９２は、スタックが、「ＡＢＣ社」スタック６５１内など、複数レベルで構成されることを示す。したがって、例えば、「リサ」スタック７９２が、ドキュメントライブラリ内の「ＡＢＣ社」スタック６５１内に存在しているなど、仮想フォルダは、複数のレベルで形成することができる。

図１５は、図１４のファイルを再びスタックするために、「カテゴリでスタック」オプションがさらに選択される、画面表示を例示する図である。図１５に示すように、選択ボックスＳＢが、「カテゴリでスタック」オプション７８２を囲んでいる。アイテムの一部は既に、スタック７９１および７９２でスタックされているので、図１６を参照して以下で詳述するように、「カテゴリでスタック」オプション７８２の選択によって、アイテムが再びスタックされる。

図１６は、図１４のファイルがカテゴリで再びスタックされる画面表示を例示する図である。図１６に示すように、スタック７９３および７９４は、「ＸＹＺ社」および「マーケティングレポート」カテゴリにそれぞれ対応する。ドキュメント１および２に対応する、アイテム７５１および７５２は、追加のカテゴリが指定されていないので、したがって、他のカテゴリスタックのいずれにも分類されていない。

図１７は、物理フォルダを求めてクィックリンクが選択される画面表示を例示する図である。選択ボックスＳＢが、「すべてのフォルダ」クィックリンク６１６を囲むように示されている。図１８を参照して以下で詳述するように、「すべてのフォルダ」クィックリンク６１６によって、物理フォルダのビューへの切換えが提供される。

図１８は、物理フォルダを示す画面表示を例示する図である。物理フォルダが、図１７の仮想フォルダスタックのファイルを含むように示されている。換言すれば、スタック６５１〜６５５内に含まれるアイテムは、システム内の特定の物理フォルダ内にも含まれる。図１８で、これらは、現在のコンピュータ上に置かれている「マイドキュメント」フォルダ８５１、現在のコンピュータ上に置かれている「デスクトップ」フォルダ８５２、ハードドライブＣ上に置かれている「Ｆｏｏ」フォルダ８５３、サーバ上に置かれている「マイファイル」フォルダ８５４、外部ドライブに置かれている「外部ドライブ」フォルダ８５５、別のコンピュータ上に置かれている「マイドキュメント」フォルダ８５６、および別のコンピュータ上に置かれている「デスクトップ」フォルダ８５７として示されている。

図１８で示すように、ユーザは、図１７の仮想ファイル表示から、図１８の物理ファイル表示に切り換えることができる。これによって、ユーザは、現在の作業では、どちらが望まれるかによって、仮想ファイル表示と物理ファイル表示の間で切り換えることができる。また、以下で詳述するように、物理フォルダ８５１〜８５７の位置が様々であることで、仮想ファイルシステムの範囲が比較的に広範であることを示している。

図１９は、ユーザが仮想フォルダを直接に操作することができる、ルーチン８８０を例示するフローチャートである。以下で詳述するように、仮想フォルダを操作するために提供される機構は、通常のフォルダを操作するために現在使用されている機構（クリックアンドドラッグ、コピー、ペーストなど）に類似する。図１９に示すように、ブロック８８２で、このシステムは、表示オブジェクトとして表示される仮想フォルダを直接操作するために、ユーザが実施することができる定義された動作を提供する。ブロック８８４で、ユーザは、定義された動作を実施する。上述のように、この１つの例は、ユーザが仮想フォルダをクリックしドラッグして、その内容を、別の仮想フォルダにコピーすることである。ブロック８８６で、ユーザが実施する動作によって指示されるとおりに、仮想フォルダおよび／または内容が操作される。

図２０は、新しいウエストコーストスタック（Ｗｅｓｔ Ｃｏａｓｔ ｓｔａｃｋ）６５６が、図１０のスタックに追加されている、画面表示を例示する図である。ウエストコーストスタック６５６は、ユーザが新しいカテゴリ「ウエストコースト」を作成することによって、形成されている。最初に作成されたとき、新しいウエストコーストスタック６５６は、空であり、アイテムを含まない。図２０の実施形態では、２つのアイテムが、ウエストコーストスタック６５６に追加されている。アイテムをスタックに追加するための１つの方法は、特定のアイテムを選択し、および修正しまたは追加のカテゴリをアイテムのカテゴリメタデータに追加し、例えば、図２０の実施形態で行われた様に、カテゴリ「ウエストコースト」を、２つのアイテムに追加する。このプロセスは、カテゴリデータがあるタイプの特別な（ａｄ−ｈｏｃ）プロパティである、アイテムのメタデータプロパティであることを示している。換言すれば、このタイプのプロパティは、どんな暗黙の意味をももたず、ユーザがそれに、任意の値を割り当てることができる。例えば、カテゴリ「プロパティ」は、どんな値をももち得るが、「作成者」プロパティは、人物の名前でなければならない。図２１を参照して以下で詳述するように、アイテムは、クリックしドラッグして、他のスタックからウエストコーストスタック６５６にコピーすることもできる（この場合、アイテムのカテゴリが「ウエストコースト」を含むように、自動的に更新される）。これに関して、図２０には、コンテンツのコピーに備えて、選択ボックスＳＢが、ＡＢＣ社スタック６５１を囲んでいるのが示されている。

図２１は、ＡＢＣ社スタック６５１からウエストコーストスタック６５６に、ファイルをコピーするために直接操作が使用される、画面表示を例示する図である。換言すれば、図２０に示すように、ユーザは、ＡＢＣ社スタック６５１を選択し、次いで、図２１に示すように、そのスタックをクリックしドラッグして、ウエストコーストスタック６５６にコピーしている。したがって、図２０では、２つのアイテムを含んでいたウエストコーストスタック６５６が、ＡＢＣ社スタック６５１からの追加の８つのアイテムを含めて、合計１０個のアイテムを含むようにここでは示されている。ＡＢＣ社スタック６５１からのアイテムが、ウエストコーストスタック６５６にコピーされた場合に、これは、８つのアイテムのカテゴリ記述を、元の「ＡＢＣ社」カテゴリを含むことに加えて、「ウエストコースト」カテゴリをも含むように修正することによって遂行されている。これは、実施することができる、あるタイプの直接操作を示している。

直接操作の別の例は、アイテムを右クリックし、削除を選択することである。ある実施形態では、ユーザによって、削除機能が選択される場合、ユーザは、アイテムをすべて一緒に削除するか、それとも単に現在の仮想フォルダから削除すべきかどうかを質問される。アイテムを、単に現在の仮想フォルダのカテゴリスタックから削除する場合は、上述のように、アイテムのメタデータから、所望のカテゴリを削除することによって遂行することができる。換言すれば、ＡＢＣ社スタック６５１からウエストコーストスタック６５６にコピーされたアイテムの１つが、次いでウエストコーストスタック６５６から削除される場合は、特定のファイルのカテゴリデータを、「ウエストコースト」カテゴリをもはや含まず修正することによって遂行することができる。

図２２は、システムが動的に新しいフィルタ条件を生成するための、ルーチン９００を例示するフローチャートである。仮想フォルダを操作するために、フィルタ条件が使用される。フィルタ条件は基本的に、アイテムのセットを絞り込むための１組のツールとして使用される。ある実施形態では、フィルタは、メタデータカテゴリおよびその値（ユーザインターフェースでは、クリック可能なリンクまたはドロップダウンメニュー（ｄｒｏｐ−ｄｏｗｎ ｍｅｎｕ）としてユーザに表示される）からなる。ユーザは、画面上のアイテムセットの現在結果を絞り込むために、フィルタ条件をクリックする。

図２２に、フィルタがどのようにして動的に生成されるかを示す。図２２に示すように、ブロック９０２で、現在の画面上のコレクション（ｃｏｌｌｅｃｔｉｏｎ）内のアイテムの（メタデータからの）プロパティが調べられる。ブロック９０４で、アイテムの共通のプロパティに基づいて、提案されるフィルタ条件が動的に生成される。ブロック９０６で、提案されるフィルタ条件が、フィルタ条件の可能な選択項目として、ユーザに表示される。このプロセスの例として、このシステムは、アイテムセットのプロパティを調べることができ、アイテムが概して、「作成者」をプロパティとして有している場合には、このフィルタは、フィルタリングのための作成者のリストを提供することができる。次いで、特定の作成者をクリックすることによって、その作成者を含まないアイテムが、画面上のセットから削除される。このフィルタリングプロセスによって、画面上のアイテムセットを絞り込むための機構が、ユーザに提供される。

図２３は、フィルタ条件の選択に基づいて、システムがアイテムをフィルタリングするためのルーチン９２０を例示する図である。ブロック９２２で、ユーザが新しいフィルタ条件を入力し、あるいはシステムによって提案されたフィルタ条件の１つを選択する。上述のように、フィルタ条件は、システムによって、動的に生成することができ、または事前に設定することができる。ブロック９２４で、選択されたプロパティがフィルタ条件に一致するかどうかに関して、画面上のコレクションからのアイテムが評価される。例えば、フィルタ条件が、「ボブ」によって作成されたアイテムである場合、アイテムは、作成者プロパティが「ボブ」を含むかどうかによって評価される。ブロック９２６で、選択されたプロパティがフィルタ条件に一致しないアイテムは、画面上のコレクションから削除される。

図２４は、図１０のスタックが条件「ＡＢ」でフィルタリングされた画面表示を例示する図である。図示するように、フィルタ領域６２１に、条件「ＡＢ」が、ユーザによって入力されている。情報行６４０および６４１は、画面内のアイテムがこの場合は、条件「ＡＢ」でフィルタリングされたアイテムであることを示している。図示するように、ＡＢＣ社スタック６５１は、やはり８つのアイテムを含んでおり、バックアップスタック６５２はここでは、３つのアイテムを含み、ＸＹＺ社スタック６５４もまた、３つのアイテムを含んでいる。したがって、情報行６４４は、合計で１４個のアイテムがあり、合計で３５ＭＢのメモリを占めていることを示している。

図２５は、図１０のスタックが、条件「ＡＢＣ」でフィルタリングされた画面表示を例示する図である。図２４のフィルタ条件「ＡＢ」に関して、ユーザは単に追加の文字「Ｃ」を入力して、全体のフィルタ条件「ＡＢＣ」にしている。図２５に示すように、情報行６４０、６４１はこの場合、画面内のアイテムがここでは、条件「ＡＢＣ」を含むアイテムであることを示している。ＡＢＣ社スタック６５１は、やはり８つのアイテムを含むように示されており、バックアップスタック６５２はここでは、２つのアイテムしか含んでいない。情報行６４４はこの場合、画面上のスタックに、合計１０個のアイテムがあり、合計２５ＭＢのメモリを占めていることを示している。したがって、図２４および２５は、ユーザがどのようにして新しいフィルタ条件を入力することができ、次いで、画面上に表示されるアイテムをフィルタリングするため、こうしたフィルタ条件がどのように使用されるかについての例を提供している。

図２６は、システムによって提供されたフィルタ条件「２００２年」が選択される画面表示を例示する図である。上述のように、日付順インジケータ６２２では、年度選択６２３が、２０００、２００１または２００２年を含む。選択ボックスＳＢは、２００２年を囲むように示されており、ユーザがそれを、所望のフィルタ条件として選択していることを示している。

図２７は、フィルタ条件「２００２」が適用された、画面表示を例示する図である。また、別の選択「月を選択」セレクタ６２３Ａが示されている。図２７に示すように、フィルタ条件「２００２」を適用した後に、スタック内のアイテムの数が減らされている。より具体的には、ＡＢＣ社スタック６５１は現在、６つのアイテムを含み、バックアップスタック６５２は現在、８つのアイテムを含み、事業計画スタック６５３は現在、３つのアイテムを含み、ＸＹＺ社スタック６５４は現在、５つのアイテムを含んでいる。情報行６４４は現在、合計で２２個のアイテムがあり、合計で５０ＭＢのメモリを占めていることを示している。情報行６４０、６４１は現在、画面上に表示されているアイテムが、フィルタ条件「２００２」を含むようにフィルタリングされたアイテムであることを示している。

図２８は、フィルタリング対象の月を選択するためのリストが提示される画面表示を例示する図である。月のリストを含むボックス９５０が提供される。ユーザが「月を選択」セレクタ６２３Ａを選択したため、ボックス９５０が、画面上に提供されている。選択ボックスＳＢが、１月を囲むように示されている。

図２９は、図２８のスタックが１月でさらにフィルタリングされ、またフィルタ条件「日付」をさらに表示している画面表示を例示する図である。図２９に示すように、情報行６４０、６４１はここでは、画面上のアイテムは、条件「１月」でフィルタリングされたアイテムであることを示している。バックアップスタック６５２はここでは、２つのアイテムを含むように示され、事業計画スタック６５３もまた、２つのアイテムを含むように示されている。情報行６４４は、画面上には、合計で４つのアイテムがあり、合計で１０ＭＢのメモリを占めていることを示している。ユーザがその結果をさらに、特定の日付でフィルタリングしたい場合は、「日付で選択」セレクタ６２３Ｂが提供される。

図３０は、新しいクィックリンクを作成するためのルーチン９４０を例示するフローチャートである。以下で詳述するように、クィックリンクは、ユーザ選択によるアイテムセットのビューを作成するために、ユーザがクリックすることができる事前定義されたリンクである。ある実施形態では、クィックリンクは、あるタイプのピボットであると見なされる。クィックリンクは、仮想フォルダを検索するための機構を提供する。クィックリンクをクリックすると、ユーザは、（「お気に入り」をクリックすると、ユーザがウェブサイトに移動できるのと同じように）所望のフォルダに移動することができる。クィックリンクは、システムによって事前定義することができ、またはユーザによって設定することができる。例えば、「すべての作成者」をクリックすれば、作成者でスタックされたビューに戻ることができる。「すべてのドキュメント」をクリックすれば、全ストレージ領域の全ドキュメントのためのフラットビューに戻すことができる。ユーザは、自身のクィックリンクを作成することもできる。

図３０に示すように、ブロック９４２で、現在のフィルタ条件またはナビゲーションから、新しいクィックリンクが形成されるように指示するために、ユーザは、画面上で選択を行う。ブロック９４４で、ユーザは、新しいクィックリンクの新しい名前を付ける。ブロック９４６で、新しいクィックリンクが保存され、新しいクィックリンクの名前が、画面上のクィックリンクセクション（ｑｕｉｃｋ ｌｉｎｋ ｓｅｃｔｉｏｎ）内に提供される。

図３１は、図２９のフィルタリングに基づいて、「１月の作業」と称される新しいクィックリンクを作成するための画面表示を例示する図である。上述のように、図２９では、スタックが１月でフィルタリングされている。図３１では、ユーザが、図２９のフィルタリングを、新しいクィックリンクとして保存するように指示しており、新しいクィックリンクを、「１月の作業」と名付けている。したがって、新しい１月の作業クィックリンク６１２が、画面のクィックリンクセクション内に示されている。新しいクィックリンクを形成することに関して、ユーザには一般に、「このコレクションをクィックリンクとして保存」などのオプションが提供される。

図３２は、「すべての作成者」クィックリンクが選択される画面表示を例示する図である。図３２に示すように。選択ボックスＳＢは、すべての作成者選択６１１を囲むように示されている。クィックリンクによってアクセス可能である他のコレクションの例は、「すべての作成者」、「最近のドキュメント」、「共有したすべてのドキュメント」、「作成したすべてのドキュメント」、「他が作成したすべてのドキュメント」、「デスクトップ」および「すべてのタイプ」を含む。

図３３は、図３２のアイテムのすべての作成者のリストが表示される、画面表示を例示する図である。図３３に示すように、情報行９５０が提供され、アイテム名、作成者、修正日、タイプ、サイズおよびアイテムの位置を表示するための列を示している。作成者１〜４にそれぞれ対応する、作成者９５１〜９５４のリストが示されている。

図３４は、図３３のリストから、「作成者１」が選択された画面表示を例示する図である。作成者１のドキュメントは、ドキュメント１および２にそれぞれ対応する、ドキュメント９５１Ａおよび９５１Ｂを含む。ドキュメント９５１Ａは、作成者１によって作成され、２００１年７月１１日に修正され、マイクロソフトのエクセルファイルであり、２８２Ｋｂのメモリを占め、＼＼ｓｅｒｖｅｒ１＼ｆｏｌｄｅｒ２の位置から取得されたように示されている。ドキュメント９５１Ｂは、作成者１によって作成され、２００２年１２月２２日に修正され、マイクロソフトのワードファイルであり、２０６Ｋｂのメモリを占め、Ｍｙ Ｄｏｃｕｍｅｎｔｓ＼ｆｏｌｄｅｒ１の位置に物理的に格納されているように示されている。またドキュメント９５１Ａおよび９５１Ｂの位置は、本発明の仮想フォルダが、以下で詳述するように、様々な物理位置からのアイテムを含むことができることを示している。

図３５は、新しいライブラリを作成するためのルーチン９６０を例示するフローチャートである。ライブラリの一例は、図１０を参照して上述したドキュメントライブラリである。一般に、ライブラリは、互いに関連付けることができる使用可能なファイルタイプの大きなグループからなる。例えば、写真を１つのライブラリとすることができ、音楽を別のライブラリにすることができ、ドキュメントを別のライブラリにすることができる。ライブラリは、アイテムの特定のタイプに関連するツールおよび動作を提供することができる。例えば、写真ライブラリには、スライドショーの作成または写真の共有など、写真の操作に関連するツールおよびフィルタがある。図３５に示すように、ブロック９６２で、選択された特性を有するアイテムを含む、新しいライブラリが作成される。ブロック９６４で、選択されたアイテムが、ライブラリに分類される。ブロック９６６で、アイテムの選択された特性、または他の所望の機能に関連するツールおよび／または動作が提供される。

図３６は、使用可能なライブラリのコレクションが示されている画面表示を例示する図である。図３６に示すように、ライブラリは、ドキュメントライブラリ９７１、写真／ビデオライブラリ９７２、音楽ライブラリ９７３、メッセージライブラリ９７４、連絡先ライブラリ９７５、およびテレビ／映画ライブラリ９７６、ならびにすべてのアイテムライブラリ９７７を含む。すべてのアイテムライブラリ９７７は、２７５個のアイテムを含むように示されており、これは、他のライブラリをすべて合わせたアイテムの総数を示す。情報行６４４は、合計が２７５個のアイテムであり、合計７００ＭＢのメモリを占めていることを示している。ドキュメントライブラリ９７１は、図１０に関して上述したライブラリであることに留意されたい。

図３７は、仮想フォルダコレクションの範囲を定義するためのルーチン９９０を例示するフローチャートである。以下で詳述するように、仮想フォルダシステムは、ユーザがすべてのアイテムを容易にアクセスできるように、複数の物理位置（様々なハードドライブ、様々なコンピュータ、様々なネットワーク位置など）からアイテムを表示することができる。例えば、ユーザに、複数の物理位置からの音楽ファイルを、単一の画面上で表示し、ユーザは、ファイルをすべて同時に操作することができる。

図３７に示すように、ブロック９９２で、アイテムの取り出し元の物理位置の範囲が定義される。ブロック９９４で、クエリに応答して、範囲で定義される物理位置から、アイテムが取り出される。ブロック９９６で、クエリによって取り出されるすべてのアイテムが、単一の画面上で、表示される。

図３８は、仮想フォルダコレクションの範囲を形成することができる様々なソースを例示するブロック図である。図３８に示すように、システム１０００は、現在のコンピュータ１０１０、追加のコンピュータ１０２０、外部および取出し可能記憶装置１０３０、およびネットワーク１０４０上の位置を含む。全体範囲１００１は、コレクション作成のため、ユーザアイテムが取り出されるすべての物理位置を含むように説明されている。範囲は、ユーザによって設定され修正されることができる。上述のように、他の図面では、アイテムが様々な物理位置からもたらされることが示されており、例えば図３４は、サーバおよび現在のコンピュータ上のマイドキュメントフォルダからもたらされる、それぞれ異なるドキュメントを示しており、図１８は、複数の位置に物理的に格納されている物理フォルダを示している。

図３９は、非ファイルアイテムを、仮想フォルダコレクション内に含めるための、ルーチン１０８０を例示するフローチャートである。非ファイルアイテムは、物理ファイルストレージに一般に置かれるファイルアイテムとは対照的である。非ファイルアイテムの例は、電子メールや連絡先などの物である。図３９に示すように、ブロック１０８２で、データベースを使用して、クエリによって検索される、非ファイルアイテムをファイルアイテムとともに含める。ブロック１０８４で、クエリに応答して、クエリに一致する非ファイルアイテムとファイルアイテムの両方が取り出される。ブロック１０８６で、クエリに一致する非ファイルアイテムとファイルアイテムの両方が、画面上に表示される。

図４０は、様々な非ファイルアイテムを示す画面表示を例示する図である。図４０に示すように、アイテムが、「ジョン」を含むアイテムになるようにフィルタリングされている。アイテムが、コンタクトアイテム１１０１、電子メールアイテム１１０２、およびドキュメントアイテム１１０３、１１０４を含むように示されている。コンタクトアイテム１１０１および電子メールアイテム１１０２は、非ファイルアイテムである。ユーザによって、要望どおりに、ファイルが構成され操作されるように、このシステムは、こうした非ファイルアイテムが、通常のファイルアイテムとともに含められることを可能にする。図２を参照して、上述したように、こうした非ファイルアイテムを完全に、リレーショナルデータベース２３０内に含めることができ、このデータベースは別に、ファイルのプロパティに関する情報を含む。

本発明の好ましい実施形態について、図示し説明したが、本発明の精神および範囲から逸脱せずに、それに対して様々な変更可能であることが理解されよう。

Claims (5)

1. プロセッサおよびディスプレイを有するコンピュータシステムにおいて複数のアイテムを表示する方法であって、前記プロセッサにより、
   前記複数のアイテムを格納するコンピュータメモリの複数の物理位置の範囲を定義するステップであって、前記範囲は前記コンピュータメモリの物理位置および少なくとも１つの他の物理位置を含み、前記複数のアイテムは、当該アイテムをカテゴリ別にグループ化するためのメタデータのプロパティを含む、定義するステップと、
   メタデータのプロパティを示すクエリを受け取り、１つまたは複数の仮想フォルダの中の、ディスプレイ上に表示するアイテムのタイプのリストおよび当該複数のアイテムの物理位置を有するデータを、仮想フォルダ記述データベースから、前記クエリに応答して、抽出するステップと、
   前記メモリの複数の物理位置から、前記クエリの示すメタデータのプロパティを有する複数のアイテムを取り出すステップであって、前記プロセッサにより、
   （ａ）前記複数のメタデータのプロパティを格納するリレーショナルデータベースを参照
   するステップと、
   （ｂ）前記クエリのメタデータのプロパティと、前記範囲内の複数のアイテムのメタデータのプロパティとを比較するステップと、
   （ｃ）比較結果に基づいて前記メタデータのプロパティが合致する複数のアイテムを取り出すステップと
   を有する、取り出すステップと、
   当該取り出されたアイテムのメタデータのプロパティに基づいて、実際の物理的ファイルシステムの代わりに、前記ディスプレイ上の表示において１つまたは複数の仮想フォルダ中で前記合致する複数のアイテムを表示するステップであって、前記仮想フォルダは、前記実際の物理的ファイルシステム上で前記合致のアイテムが格納されている物理フォルダではない仮想のフォルダである、表示するステップと
   を実行し、
   前記ディスプレイ上の表示は１つまたは複数の仮想フォルダの前記物理的位置に依存しないビューの表示から、プロパティが合致し取り出された前記複数のアイテムが前記実際の物理的ファイルシステムに格納されている物理フォルダを示す、前記物理的位置に依存するビューの表示に、前記１つまたは複数の仮想フォルダが表示されている間は切り替え可能であり、
   前記クエリにより取り出される複数のアイテムはファイルアイテムおよび非ファイルアイテムの双方を含み、
   前記非ファイルアイテムは前記リレーショナルデータベースに格納されるアイテムであり、前記メモリの複数の物理位置には格納されていないことを特徴とする方法。
2. 複数のアイテムをディスプレイに表示するためのプログラムを記録した記録媒体であって、前記プログラムは、コンピュータに、
   前記複数のアイテムを格納するコンピュータメモリの複数の物理位置の範囲を定義する手段であって、前記範囲は前記コンピュータメモリの物理位置および少なくとも１つの他の物理位置を含む、定義する手段と、
   メタデータのプロパティを示すクエリを受け取り、該クエリに応答して仮想フォルダの記述を有する仮想フォルダ記述データベースからデータを受け取る手段であって、前記仮想フォルダ記述データベースから受け取るデータは、１つまたは複数の仮想フォルダ記述、１つまたは複数の仮想フォルダの中で表示する複数のアイテムのタイプのリストおよび複数のアイテムの物理位置を有している、受け取る手段と、
   前記データに基づき前記クエリのメタデータのプロパティにより示される複数のアイテムを前記複数の物理位置から取り出し、当該取り出されたアイテムのメタデータのプロパティに基づいて、実際の物理的ファイルシステムの代わりに、１つまたは複数の仮想フォルダ内の前記クエリにより定まる複数のアイテムを前記ディスプレイ上に、表示する手段であって、前記仮想フォルダは前記仮想フォルダは、前記実際の物理的ファイルシステム上で前記クエリにより定まるアイテムが格納されている物理フォルダではない仮想のフォルダである、表示する手段と
   して機能させ、
   前記ディスプレイ上の表示は１つまたは複数の仮想フォルダの表示から、前記複数のアイテムが存在する実際のファイルシステムにアイテムが格納されている物理位置を示す物理フォルダの表示に、前記実際のファイルシステムの代わりに前記複数のアイテムのメタデータに基づいて前記１つまたは複数の仮想フォルダの形態で、前記複数のアイテムを表示している間切り替え可能であり、
   前記１つまたは複数の仮想フォルダは仮想的に前記合致する非ファイルアイテムおよびファイルアイテムを含み、前記合致する非ファイルアイテムおよびファイルアイテム異なる複数の前記物理フォルダに常駐しており、
   前記クエリにより取り出される複数のアイテムはファイルアイテムおよび非ファイルアイテムの双方を含むことを特徴とする記録媒体。
3. 複数のアイテムをディスプレイに表示するためのプログラムを記録した記録媒体であって、前記プログラムは、コンピュータに、
   クエリにより非ファイルアイテムおよびファイルアイテムを検索可能となすデータベースであって、前記ファイルアイテムについての情報を保持し、複数の非ファイルアイテムエンティティをも保持するリレーショナルデータベース内でファイルアイテムを検索可能となすデータベースを提供する手段と、
   クエリを受け取り、該クエリに応答して１つまたは複数の仮想フォルダ記述を有する仮想フォルダ記述データベースからデータを受け取る手段であって、前記仮想記述データベースから受け取るデータは１つまたは複数の仮想フォルダ記述、１つまたは複数の仮想フォルダの中で表示するための複数のアイテムのタイプのリストおよび複数のアイテムの物理位置を有する、受け取る手段と、
   前記データベース内の非ファイルアイテムおよびファイルアイテムとクエリを比較し、合致するか否かを判定し、前記データに基づき前記クエリに合致する非ファイルアイテムおよびファイルアイテムを取り出す手段と、
   仮想フォルダの形態で、当該取り出された非ファイルアイテムおよびファイルアイテムを前記ディスプレイ上に表示させる手段であって、１つまたは複数の仮想フォルダは、実際の物理的ファイルシステムの位置の代わりに、取り出された非ファイルアイテムおよびファイルアイテムのメタデータのプロパティに基づいており、前記仮想フォルダは、前記実際の物理的ファイルシステム上に前記合致の非ファイルアイテムおよびファイルアイテムが格納されている物理フォルダではない仮想のフォルダであ表示させる手段と、
   前記ディスプレイ上の表示は１つまたは複数の仮想フォルダの表示から、前記複数のアイテムが存在する実際のファイルシステムにアイテムが格納されている物理位置を示す物理フォルダの表示に切り替える手段と
   して機能させ、
   前記１つまたは複数の仮想フォルダは前記合致する非ファイルアイテムおよびファイルアイテムを仮想的に格納することを特徴とする記録媒体。
4. 請求項３に記載の記録媒体において、前記非ファイルアイテムは連絡先および電子メールのうちの少なくとも１つであることを特徴とする記録媒体。
5. 請求項３に記載の記録媒体において前記クエリに合致して取り出される複数のアイテムは異なる物理フォルダに格納されていることを特徴とする記録媒体。

Images