JP2008515048A

JP2008515048A - ファイルシステムのシェル

Info

Publication number: JP2008515048A
Application number: JP2007533464A
Authority: JP
Inventors: エフ．ムーアジェイソン; エム．シエラジアンピエロ; エム．バンクスリチャード; キン−フックウォンリヨン; ビー．イワノビックリリャ; エー．ガスモリノポール; ケイ．ビームタイラー; ピー．マッキーティモシー; シー．ベルトジェフリー; ジー．デボルチクデビッド; ジェイ．ガザククリス; ロウエイダン; エム．タブスケニス; アール．アンソニーコリン; シー．チャリベンドラササンカ; イウェマワトソンマリケ; ポールジョイスジェラルド; ディー．ウェイドアレックス; エー．ベッツベンジャミン; エス．カビールアーサン
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2004-09-24
Filing date: 2005-08-01
Publication date: 2008-05-08
Anticipated expiration: 2025-08-01
Also published as: CN101124572A; JP4861988B2

Abstract

本発明に係るファイルシステムシェルは、ディスク上の物理的なファイルシステム構造の代わりにメタデータに基づき異なるビューでファイルおよびフォルダを公開する仮想フォルダ（６５１〜６５５）を備える。ユーザは、直接操作により仮想フォルダを操作することができ、アイテムの集合を絞り込むためのフィルタ（６２０〜６２６）が用意される。クイックリンク（６１０〜６１３）により、ユーザは、アイテムの集合のビューを生成することができる。アイテム（６３０〜６３３）に関係する関数およびツールとともに、一緒に関連付けることができるタイプのアイテム（６４４、６４５）からなるライブラリ（６４０、６４１）が実現される。複数のセグメントを含み、それぞれが内容を選択するためのフィルタに対応する、仮想アドレスバーが提供される。シェルブラウザが提供され、ユーザは、アイテムをメタデータに基づいて容易に識別することができる。

Description

本発明は一般に、ファイルシステムに関し、より具体的には、ファイルシステムのシェルに関する。

現在のコンピュータファイルシステムは、様々な望ましくない制限を含んでいる。制限の１つに、ユーザは一般に、ユーザに対し示される構造を制御することができないということが挙げられる。言い換えると、フォルダが編成されるときに、ユーザは、構造を選択しなければならず、その後、その構造は、変更が困難であるということである。具体的な例として、「ｍｕｓｉｃ」フォルダでは、ユーザは、音楽ファイルをアーティスト／アルバム形式で編成することを選択でき、その場合、それぞれのアーティストに対するアルバムフォルダは、その特定のアーティストのフォルダ内にグループ化され、特定のアルバムの楽曲はすべて、そのアルバムのフォルダ内にグループ化される。アーティスト／アルバム形式は、ある種の音楽を再生する（例えば、２人の異なるアーティストによる２つのジャズ曲を再生する）または、異なるアーティストの選択されたアルバムを再生することの助けにならない。

他の問題としては、ユーザが編成しにくい多数のファイルを保有している可能性が挙げられる。一部のユーザは、ファイルに対しある種の厳格な配置を実装し、それらについて厳密な階層を形成する。このようなファイルの管理は、利用可能なドキュメント数が増えるにつれ次第に複雑に、また困難になり、探索および検索も難しくなる。この問題は、共有ファイルなど、他の場所から利用されるファイルが加わると、さらに悪化する。

ユーザは、さらに、異なるデバイス、他のＰＣ、ネットワーク上などの異なる場所にあるファイルも取り扱わなければならない。例えば、ユーザは、（音楽プログラムからアクセスできるような）コンピュータ上で音楽を聴くことを選択するか、またはオンライン接続してＷｅｂサイト上で音楽を聴くことができるが、これら２つのソースは厳密に分けられる。異なる場所から送られてくる音楽は、異なる場所に編成され、同じ方法でまたは同じ場所に保持されることはない。他の実施例として、企業ネットワーク上に格納されているファイルは、本質的に、ユーザが現在のマシン上に持つファイルから分離することができる。

ユーザは、どのようなファイルデータが格納されているかを追跡するだけでなく、どこに格納されているかをも追跡しなければならない。例えば、音楽ファイルの場合、ユーザは、様々なシステム上にコピーを保持し、どの音楽ファイルがどこに置かれているかを追跡することを試みることを強制される。このため、ファイルを特定することは困難であり、ファイルがローカルに格納されている場合であっても難しい。

また、ユーザが保有しているファイルを見つけ、それらのファイルに戻ることもときには困難である。特定のファイルをどこにどのように格納したかを思い出すことはユーザにとっては難しい場合がある。一組のフォルダ、さらには類似のファイル群が与えられた場合、ユーザは、探しているものを素早く見つけるのが難しいことに気づくことがよくある。ファイルが見つけにくい場所に格納されている場合、特定する作業はかなり複雑である。それに加えて、ユーザが１つのフォルダ内に多くのファイルを置いた後、特にそれらのコンテンツが類似する場合、フォルダを素早く解析することはさらに難しい。

また、ユーザがネットワーク上のファイルを見つけるか、またはそれらのファイルに戻ることもときには困難である。ファイルを共有し公開することは、多くの場合難しい作業であり、そのようなファイルを、そのファイルを利用可能にする誰かから受け取ることはなおいっそう困難なことが多い。ユーザは、典型的には、ネットワーク上でファイルを見つけるのに必要な様々なサイトおよび名称を記憶またはマップしなければならない。

名前空間は異なることがあり、そのため、何が「正しい」かについてユーザに混乱を引き起こす原因となりうる。これは、特に、異なる命名規則、制限などがあるネットワーク上でありうることである。例えば、いくつかのオペレーティングシステムでは、表示可能なように空白を含まない短い名前を要求する場合がある。

プログラムは、ファイルをそのプログラム専用のディレクトリまたは他の名前空間に保存することも多く、ユーザがそれらのファイルにたどり着くことは困難な場合がある。プログラムは、既定のディレクトリとドキュメントを保存する場所とを持つことが多い。ユーザは、ハードディスク内を探索し、ファイルが格納されている場所を推測しなければならない場合も多い。

また、関連するアイテムが、別の場所に格納されることも多い。ユーザが保有する関連ファイルは、ハードディスクなどの別の部分に格納されることもある。この問題は、複数のコンテンツタイプ（例えば、画像、音楽、ビデオ）を持つデジタルメディアサービスの開発につきものである。

ファイルシステムの他の問題は、アドレスバーに関係する。ユーザがコンピュータのファイルシステム内をナビゲートするときに、アドレスバーと呼ばれる、従来のグラフィカルインターフェースコントロールは、ユーザがファイルシステム階層内のどこにいるかをユーザに示す。従来のアドレスバーは、フォルダ、サブフォルダ、およびファイルからなるファイルシステムの階層構造に関する現在位置を示す。従来のアドレスバーに表示されるユーザの場所を変更するには、典型的には、以下の２つの方法のうちの１つが実行される。１つは、アドレスバー内のアドレスを手作業で編集することである。アドレスバー内のアドレスを手作業で編集すれば、ユーザは、ファイルシステム階層内の場所に何カ所でも移動できるが、ユーザは、コンピュータ上のファイルシステムの編成に関する特定の情報を保有している、つまり、ファイルシステムの特定の場所を知っている必要がある。第２の方法は、操作時に、新しいアドレスまたは場所を反映するようにアドレスバーを更新する外部ナビゲーションツールを使用することを伴う。外部ナビゲーションツールを操作する場合、アドレスバー内のアドレスを手作業で編集しなくて済むが、それでも、ユーザは、ファイルシステムの編成に関する特定の情報を保有し、階層構造をトラバースする必要がある。しかし、従来のアドレスバーでは、アドレスバー内のアドレスとファイルシステム階層内の特定の場所との間に一対一の関係があるため、フォルダまたはドライブなどの、ファイルシステムの複数の場所にまたがって格納されているファイルまたはデータを参照することはできない。

従来技術には、ファイルシステムの複数の場所にまたがって格納されているか、または様々な特性のどれかを持つファイルを表示するアドレスをユーザ側で指定できるようにするアドレスバーが欠如している。従来技術には、さらに、手作業でアドレスを編集することなく、または根幹のファイルシステムの編成に関する具体的な知識がなくても、アドレスバーのアドレスをユーザ側で容易に修正できるようにするアドレスバーも欠如している。さらに、従来技術には、ファイルの選択へナビゲートすることをユーザが選べるファイルの二者択一選択をユーザに表示するアドレスバーが欠如している。このようなアドレスバーは、さらに、ユーザに対し従来のアドレスバーインターフェースを選択的に表示し、ユーザ設定に基づく前回操作履歴に従ってユーザがアドレスバーを対話操作できるようにすることも可能である。

ファイルシステムの他の問題は、コンピュータ上に格納されているアイテムの識別に関係する。毎日のルーチン作業にコンピュータを利用する個人が増え、画像、音楽、ドキュメントなど様々な種類の情報が格納されるようになるにつれ、パーソナルコンピュータ（ＰＣ）などのコンピューティング環境に格納されているアイテムを容易に識別できる必要性が劇的に高まってきている。ドキュメントおよびメディアは、典型的には、階層方式でコンピュータ上に格納され、フォルダ内に格納されている情報またはメディアとともに編成される。ファイルシステムブラウザを使用することで、ユーザは、ファイルシステム内をナビゲートし、ファイルおよびフォルダを特定して開くことができる。例えば、本件特許出願人による、ＷＩＮＤＯＷＳ（登録商標）ＥＸＰＬＯＲＥＲ（商標）は、ユーザがファイルシステムをブラウズするためのオペレーティングシステムユーティリティである。

多くのユーザにとって、従来のファイルシステムブラウザで現在利用可能な情報に基づいてファイルを正しく識別するのは困難である。もちろん、ファイルのコンテンツは、アプリケーションプログラムで開くことにより確認することができるが、ファイルを閲覧するこの方法は、きわめて不効率である。ファイルシステムブラウザ内にファイルに関するメタデータを表示する機能があるので、ユーザは、特定のファイルを識別するのに、ファイルをわざわざ開かなくて済み、非常に都合がよい。例えば、本件特許出願人による、ＷＩＮＤＯＷＳ（登録商標）９Ｘオペレーティングシステムでは、ユーザは、特定のオブジェクトに対するプロパティシートにアクセスすることによりオブジェクトメタデータを表示することができる。プロパティシートには、オブジェクトの属性または設定の一覧がタブ付きインデックスカード風のプロパティページ選択形式でユーザに対して表示され、それぞれのページは、パラメータをカスタマイズするための標準のダイアログスタイルのコントロールを備えている。しかし、プロパティシートを使用してアイテムを特定する作業は時間がかかり、面倒であり、ユーザによっては、プロパティシート内の関連するメタデータを特定するのが難しい場合がある。同様に、インフォチップを使用してアイテムを特定する作業も時間がかかり、面倒であるが、それは、ユーザが、インフォチップに表示される制限付きメタデータを見るためにそれぞれのファイル上でマウスをホバリングさせなければならないからである。

従来のファイルシステムブラウザでは、ユーザは、ファイルおよびフォルダに関係するメタデータの入力および編集を行うことができず、もしそれができるとすれば、ユーザがファイルを後から特定することができ、著しく使い勝手が増すであろう。今日まで、ユーザによるメタデータの入力および編集の機能は、専用ソフトウェアプログラムに制限されていた。例えば、電子音楽ファイル用のメディアプレーヤーでは、音楽アルバムおよびアーティストに関連付けられているメタデータをユーザ側で編集することができる。このようなプログラムの他の実施例として、電子画像ファイルのアプリケーションプログラムがある。しかし、メディアプレーヤーおよびその他のこのようなプログラムの有用性は、複数のファイルタイプをサポートする汎用ファイルシステムブラウザとは反対に、プログラムによりサポートされているファイルの特定のタイプに制限される。

本件特許出願人による、ＷＩＮＤＯＷＳ（登録商標）ＸＰオペレーティングシステムは、「ＭｙＰｉｃｔｕｒｅｓ」フォルダで使用するためのイメージブラウザを備えている。「ＭｙＰｉｃｔｕｒｅｓ」フォルダは、ユーザが画像を単にドキュメントアイコンとしてではなく写真として表示できる特別な機能を備える。「ＭｙＰｉｃｔｕｒｅ」の画像閲覧機能は、サムネイルサイズの写真および大きいサイズの写真の表示、横向きの写真の回転、およびスライドショーの作成を行う機能を含む。ユーザは、さらに、写真の詳細、例えば、その寸法、撮った日時、およびその写真を撮ったカメラの名前などを表示することもできる。「ＭｙＰｉｃｔｕｒｅ」フォルダ内のプレビューコントロール領域には、ユーザによって選択された画像の拡大されたプレビュー画像、ユーザによる一連の画像の繰り返し表示を補助するイテレータボタン、画像を時計回りまたは反時計回りに回転するためのコントロールが含まれる。ＷＩＮＤＯＷＳ（登録商標）ＸＰの画像閲覧機能は、画像の表示および操作のためアプリケーションプログラムを呼び出す必要性を緩和することにより最先端技術に進歩しているが、ユーザは、それでも、画像に関連付けられたメタデータを入力し編集することはできない。

そこで、シェルまたはファイルシステムブラウザ内でのユーザエクスペリエンスを改善し、ユーザが、アイテムに関連付けられているメタデータに基づいてアイテムを容易に特定できるようにする必要がある。さらに、アプリケーションプログラムを呼び出さなくても、シェルブラウザ内で様々なタイプのアイテムに関連付けられているメタデータをユーザが入力し編集するためのシステムおよび方法も必要である。さらに、ユーザがユーザファイルを容易に特定できるように、ユーザに改善されたファイルコンテンツ認識機能を提供するファイルシステムまたはシェルブラウザも必要である。また、複数の利用可能なプレビューアから特定のファイルタイプについてプレビューアの選択を可能にするシェルブラウザ用の改善されたグラフィカルユーザインターフェースも必要である。ソフトウェア開発者がファイルタイプに基づいて追加の情報および機能性をユーザに提供することを可能にする拡張可能シェルブラウザも必要である。さらに、アイテムの異なる複数のコレクション間で類似のＵＩエクスペリエンスを提供する必要もある。

本発明の一態様では、仮想フォルダを使用するシステムおよび方法が提供される。仮想フォルダでは、通常のファイルおよびフォルダ（ディレクトリとも呼ばれる）を、ディスク上の実際の物理的基礎ファイルシステム構造の代わりに、メタデータに基づく異なるビューでユーザに公開する。そのため、システムは、データベースに格納されているプロパティを受け取り、それをフォルダのようなコンテナとして表すことができる。ユーザは、すでに、フォルダの操作に慣れているので、仮想フォルダを類似の方法で表示することにより、ユーザは、新しいシステムに素早く適応できる。

本発明の他の態様によれば、仮想フォルダは、ディスプレイと、アイテムを格納するためのメモリとを備えるコンピュータシステムで使用される方法に従って実現される。この方法では、メタデータプロパティが選択される。次いで、システムは、選択されたメタデータプロパティを持つアイテムを探し、メタデータプロパティを持つアイテムのコレクションを表す仮想フォルダ表示オブジェクトが与えられる。

本発明の他の態様によれば、システムは、ユーザからクエリを取得するためのフォルダプロセッサ、およびアイテムに関する情報を格納するためのリレーショナルデータベースを備える。フォルダプロセッサは、まず、ユーザからクエリを取得し、そのクエリをリレーショナルデータベースに受け渡す。リレーショナルデータベースは、結果をフォルダプロセッサに送り返し、そのリレーショナルデータベースから得られた結果に基づき、フォルダプロセッサは、それらの結果を仮想フォルダとしてユーザに与える。一実施形態では、フォルダプロセッサに送り返された結果は、データベースの行および列を含む。データベースの行および列は、フォルダプロセッサにより、列挙子構造（enumerator structure）に変換され、次いで、結果として得られる仮想フォルダをディスプレイに初期値として配置するために使用される。

本発明の他の態様によれば、ユーザは、直接操作により仮想フォルダを操作することができる。言い換えると、仮想フォルダを操作するために用意されているメカニズムは、従来の物理フォルダを操作（例えば、クリック＆ドラッグ、コピー、貼り付けなど）するために現在使用されているメカニズムと類似している。

本発明の他の態様によれば、仮想フォルダの直接操作を実行する方法は、ディスプレイと、アイテムを格納するためのメモリとを備えるコンピュータシステム内に実現される。この方法によれば、アイテムのグループが、仮想フォルダとして表される。仮想フォルダを直接操作のため実行することができる定義済みアクションが用意されており、定義済みアクションが実行されると、仮想フォルダは、定義済みアクションにより指令されている通りに操作される。定義済みアクションの一実施例は、仮想フォルダをクリック＆ドラッグすることである。一実施形態では、第１の仮想フォルダを第２の仮想フォルダにクリック＆ドラッグするアクションは、第１の仮想フォルダから第２の仮想フォルダにアイテムをコピーする機能を実行する。アイテムを仮想フォルダにコピーすることは、アイテムに関連付けられている選択されたメタデータプロパティを加えるか、または他の何らかの方法により変更することを伴うことがある。

本発明の他の態様では、仮想フォルダを操作するためのフィルタが提供される。これらのフィルタは、本質的に、アイテムの集合を絞り込むためのツールである。一実施形態では、これらのフィルタは、別々のアイテムのプロパティに基づき動的に生成される。例えば、アイテムの集合について、フィルタメカニズムは、プロパティを調べ直して、アイテムが一般的に「ａｕｔｈｏｒｓ」をプロパティとして持つ場合、フィルタは作成者の一覧を与えることができる。次いで、特定の作成者をクリックすることにより、作成者を持たないアイテムが非表示になる。これにより、ユーザはコンテンツを絞り込むことができる。

本発明の他の態様によれば、アイテムをフィルタ処理する方法が、ディスプレイと、メタデータプロパティを持つアイテムを格納するためのメモリとを備えるコンピュータシステム内に実現される。それぞれが１つまたは複数のアイテムを表す表示オブジェクトがディスプレイ上に用意される。表示オブジェクトにより表されるアイテムのメタデータプロパティは、評価される。複数のアイテムにより共有されるメタデータプロパティに対応するフィルタ条件がディスプレイ上に示され、そこで、フィルタ条件が選択されると、ディスプレイ上に表されているアイテムが、指定されたメタデータプロパティを共有するアイテムに絞り込まれる。

本発明の他の態様によれば、複数のアイテムがディスプレイ上に表され、フィルタ条件は、それらのアイテムのメタデータプロパティに基づき動的に生成される。フィルタ条件が選択されると、その条件により、ディスプレイ上に表されるアイテムは、そのフィルタ条件に対応するメタデータプロパティを持つアイテムに絞り込まれる。

本発明の他の態様によれば、複数のアイテムがディスプレイ上に表され、ユーザがチェックボックスコントロールを選択することによりフィルタを選択できるフィルタ領域が用意される。チェックボックスコントロールがユーザにより選択されると、ディスプレイ上に表されているアイテムは、そのフィルタ条件を含むアイテムに絞り込まれる。ユーザがフィルタ条件を入力すると、新たな文字がフィルタ条件に加えられる毎にアイテムが次々にフィルタ処理されてゆく。

他の態様によれば、それぞれの表示オブジェクトが１つまたは複数のアイテムと複数のアイテムにより共有されるプロパティに対応するプロパティコントロールを表す複数の表示オブジェクトを含むグラフィカルユーザインターフェースが実現される。プロパティコントロールを選択することで、フィルタ条件の一覧がディスプレイに表示される。一態様では、フィルタ条件は、それぞれのフィルタが対応するチェックボックスコントロールを持つドロップダウンメニューに表示されるようにすることができる。

本発明の他の態様では、第１のチェックボックスコントロールを選択することにより、ディスプレイ上に表されるアイテムが、第１のチェックボックスコントロールに対応するフィルタ条件を満たすアイテムのみを含むようにすることができる。第１のチェックボックスコントロールが選択されている場合に第２のチェックボックスコントロールを選択すると、ディスプレイ上に表されるアイテムは、第１のチェックボックスコントロールに対応する第１のそれぞれのフィルタ条件、または第２のチェックボックスコントロールに対応する第２のそれぞれのフィルタ条件を満たすアイテムを含む。つまり、フィルタ条件により、論理和演算がビュー内のアイテムに対し実行される。

さらに他の態様では、第２のチェックボックスコントロールの選択を解除し、ディスプレイ上に表されるアイテムが、現在選択されているチェックボックスコントロールに対応する少なくとも１つのそれぞれのフィルタ条件を満たすアイテムのみを含むようにすることができる。

他の態様では、プロパティコントロールを選択すると、フィルタ条件の一覧と別に、整列コマンドの一覧をディスプレイ上に表示することができる。整列コマンドを選択すると、アイテムはディスプレイ上で再整列される。例示的な整列コマンドは、選択されたプロパティコントロールに関連付けられているプロパティによる並べ替え、スタッキング、またはグループ化を含む。

さらに他の態様では、プロパティコントロールはスプリットボタンとすることができる。この態様によれば、第１のボタン部分を選択することにより、フィルタ条件の一覧をディスプレイ上に表示することができ、第２のボタン部分を選択することにより、表示オブジェクトをプロパティにより並べ替えることができる。

本発明の他の態様によれば、ディスプレイを備えるコンピュータシステムでアイテムを表示する方法においてスコープが使用される。本発明は、アイテムが引き出される物理メモリロケーションのスコープを定義することを伴い、スコープは、現在のコンピュータメモリおよび少なくとも１つの他の物理的な場所を含む。クエリが受け取られると、そのクエリに対する応答として、スコープ内で定義されているとおりに物理的な場所からアイテムが引き出され、クエリから引き出されたアイテムは、次いで、ディスプレイ上のビュー内に表示される。一実施形態では、少なくとも１つの他の物理的な場所は、他のコンピュータ、ネットワーク上の位置、または外部記憶装置とすることができる。一実施形態では、ディスプレイ上のビューは、アイテムが物理的に格納される物理的な場所を示す物理フォルダビューに切り換えることができる。

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

本発明の他の態様によれば、非ファイルアイテムを表示する方法は、ディスプレイと、アイテムを格納するためのメモリとを備えるコンピュータシステム内に実装される。この方法は、非ファイルアイテムとファイルアイテムの両方をクエリにより検索できるデータベースを提供することを含む。クエリを受け取ると、そのクエリと一致する非ファイルアイテムとファイルアイテムの両方が引き出され、次いでそのクエリと一致するアイテムが、ディスプレイ上に表示される。一実施形態では、ファイルアイテムに関する選択された情報を含み、特定の非ファイルアイテムを丸ごと保持できるリレーショナルデータベースが提供される。

本発明の他の態様によれば、物理的または仮想的な場所に格納されているコンテンツを選択するためのアドレスバーが備えられる。アドレスバーは、複数のセグメントを含むことができる。それぞれのセグメントは、格納されているコンテンツを選択するためのフィルタまたは選択基準に対応することができる。１つのセグメントには、複数のフィルタまたは選択基準が含まれ、１つのセグメント内のフィルタまたは選択基準のそれぞれに対応するコンテンツを表すことができる。この場合、「ＯＲ」フィルタ処理と呼ばれる論理「和」演算が実行され、仮想的であろうと、物理的であろうと、２つまたはそれ以上の異なる場所からの別々の選択基準に対応するコンテンツにアクセスすることができる。まとめて、アドレスバー内のセグメントの対応するフィルタは、コンピュータファイルシステム上に格納されているコンテンツを選択するためのアドレスを表す。

それぞれのセグメントは、アドレスバーのアドレスを修正するユーザによる対話操作に応答することができるインタラクティブセグメントである。アドレスバー内で１つのセグメントを選択すると、選択されたセグメントに続くセグメントがアドレスバーから削除される。

一態様によれば、アドレスバー内の１つのセグメントに関連付けられている子コントロールを選択すると、選択可能な子フィルタまたは選択基準の一覧がユーザに対し表示される。子フィルタまたは選択基準は、セグメントとともに含まれる（複数の）フィルタまたは選択基準の子である。子フィルタまたは選択基準の一覧から子フィルタまたは選択基準のうちの１つを選択すると、アドレスバー内に表示されるセグメントの現在の（子）フィルタまたは選択基準は、もし選択された子フィルタまたは選択基準と異なる場合、選択された子フィルタまたは選択基準で置き換えられる。それに加えて、置き換えられた子フィルタまたは選択基準のセグメントの後のセグメントが、アドレスバーから削除される。

本発明の他の態様によれば、ウィンドウおよびエディットコントロールを含むシェルブラウザが提供される。ウィンドウには、アイテムのグループが表示され、表示されるアイテムのうちの１つまたは複数に関連付けられているメタデータ値も表示される。エディットコントロールを使用することで、ユーザは、ウィンドウ内に表示されているメタデータ値の少なくとも一部を修正することができる。

本発明の他の態様によれば、グラフィカルユーザインターフェースが、コンピュータ可読媒体上に具現化され、コンピュータ上で実行可能である。グラフィカルユーザインターフェースは、シェルブラウザ内にアイテムの集合を表示する第１の画面領域、および表示されているアイテムのうちの１つまたは複数に関連付けられているメタデータを表示する第２の画面領域を含む。グラフィカルユーザインターフェースはさらに、表示されているメタデータを修正するための手段をシェルブラウザ内においてユーザにもたらす。

本発明のさらに他の態様によれば、ユーザがシェルブラウザ内のデータを修正することを可能にするコンピュータ実装方法が提供される。このような方法の１つは、複数のアイテムを表示することと、少なくとも１つの表示されているアイテムの選択を表す第１の入力をユーザから受け取ることと、選択された（複数の）アイテムに関連付けられているメタデータを表示することと、表示されているメタデータをユーザ側で修正する場合に使用されるエディットコントロールを提供することとを含む。他のこのような方法は、ウェルカムペイン（welcome pane）に関連付けられているウェルカムペインおよびメタデータを表示することと、表示されているメタデータをユーザ側で修正するために使用するエディットコントロールを提供することとを含む。

本発明の他の態様によれば、１つまたは複数のアイテムに関連付けられているメタデータを含むデータ構造がシェルブラウザ内に表示される。１つまたは複数のコンピュータ可読媒体上に格納されるデータ構造体は、１つまたは複数の表示されているアイテムに関連付けられているユーザ修正可能メタデータを含むフィールドを含み、データ構造体に含まれるユーザ修正可能メタデータも、シェルブラウザ内に表示される。

本発明の他の態様によれば、既定のプレビューアおよび拡張性メカニズムを含むシェルブラウザが提供される。既定のプレビューアは、複数のアイテムタイプについて標準レベルの機能を備える。拡張性メカニズムを使用することにより、複数のアイテムタイプのうちの１つまたは複数について既定のプレビューアが与える標準レベルを超える機能が使用可能になる。

本発明の他の態様によれば、第１のプレビューアおよび第２のプレビューアを含むシェルブラウザが提供される。第１のプレビューアは、複数のアイテムタイプに対する標準レベルの機能を備え、第２のプレビューアは、複数のアイテムタイプのうちの１つまたは複数に対する代替えまたは拡張レベルの機能を備える。シェルブラウザは、１つまたは複数のアイテムタイプに対し第１のプレビューアまたは第２のプレビューアのいずれかを選択的に配置するように構成される。

本発明の他の態様によれば、複数のアイテムタイプをサポートするシェルブラウザ用のグラフィカルユーザインターフェースが提供される。グラフィカルユーザインターフェースは、シェルブラウザにアイテムの集合を表示するための第１の画面領域および複数の使用可能なプレビューアから表示されるアイテムについてプレビューアを選択するための手段を備える。

本発明の他の態様によれば、複数のアイテムタイプをサポートするシェルブラウザ内のプレビューアを選択するためのコンピュータ実装方法が提供される。この方法は、特定のアイテムタイプについてシェルブラウザ内に複数のプレビューアを用意することと、特定のアイテムタイプに対するプレビューアのうちから１つを選択することとを含む。次いで、この方法は、選択されたプレビューアを特定のアイテムタイプに関連付ける。

本発明の他の態様によれば、複数のアイテムタイプをサポートするサードパーティ製プレビューアをシェルブラウザ内で使用することを可能にするコンピュータ実装方法が提供される。この方法は、複数のアイテムタイプに対する既定のプレビューアを備えるシェルブラウザを提供することと、複数のアイテムタイプのうちの少なくとも１つについてサードパーティが代替えプレビューアを開発できるようにする拡張性メカニズムを提供することとを含む。

本発明の他の態様によれば、シェルブラウザ内の複数のプレビューアを示す情報を含むデータ構造体が用意される。１つまたは複数のコンピュータ可読媒体上に格納される、データ構造体は、複数のアイテムタイプをサポートする既定のプレビューアを示す情報を含む第１のフィールドを備える。第２のフィールドは、第１のアイテムタイプに対する代替えプレビューアを示す情報を含み、第３のフィールドは、第１のアイテムタイプのアイテムがシェルブラウザ内に表示されたときに既定のプレビューアを呼び出すか、または代替えのプレビューアを呼び出すかを示す情報を含む。

本発明の他の態様によれば、異なるタイプのアイテムは、類似の一組の基本ＵＩ機能を備えるライブラリにグループ化される。言い換えると、ドキュメントライブラリ、写真ライブラリ、および音楽ライブラリなどの異なるタイプのライブラリに対し一組の類似の基本ＵＩ機能が用意されるということである。この一組の基本ＵＩ機能は、フィルタ処理、新しいカテゴリの作成、アイテムのメタデータの編集、ピボットの変更などの機能を含むことができる。ライブラリに対するこの類似の一組の基本ＵＩ機能を使用することで、ユーザは、すでに馴染んでいる属性および機能を使用して異なるタイプのアイテムを処理し、編成することができる。

本発明の他の態様は、複数の階層的に整列されたアイテムのツリー状表示を含む第１のコンポーネントを表示することにより、グラフィカルユーザインターフェースのデュアルコンポーネントコントロールを介してコンピュータシステム上にまたはネットワーク上でアイテムのスコープを指定する方法を提供し、それぞれのアイテムは、そのスコープへの包含および／またはスコープからの除外を行うようにユーザ側で明示的に選択することができる。ＧＵＩは、さらに、バスケット、つまりスコープに明示的に含まれる、および／または明示的に除外されるアイテムを識別する一覧を含む第２のコンポーネントも表示する。ユーザが特定のアイテムを明示的に選択する場合、コントロールは、特定のアイテムの状態を前の状態から新しい状態へ変化させ、また特定のアイテムの、系列的に後のそれぞれの要素の状態を特定のアイテムの新しい状態に基づいて新しい暗黙の状態に変化させる。

例示的な一実施形態では、複数の階層的に整列されたアイテムのそれぞれの状態は、選択解除された状態、明示的に含まれる状態、暗黙のうちに含まれる状態、明示的に除外された状態、暗黙のうちに除外された状態のうちのどれかを示すことができる。アイテムの一覧により、それぞれの明示的に除外されたアイテムに対応する、明示的に含まれるアイテムを識別することができる。

本発明の一態様によれば、１つまたは複数のコンピュータ可読媒体は、除外された場合にビデオディスプレイ上にユーザ定義スコープを指定するためのグラフィカルユーザインターフェースコントロールを表示するように、コンピュータシステムに指令するコンピュータ実行可能命令を格納する。ＧＵＩコントロールは、複数の階層的に整列されたアイテムを、例えば、展開／折り畳み可能なツリー状方式で表示することを含む、特定のビヘイビアを示し、複数の階層的に整列されているアイテムのそれぞれは、スコープへの包含および／またはスコープからの除外を行うようにユーザにより明示的に選択することができる。ユーザがスコープに含める、またはスコープから除外するアイテムを明示的に選択した場合、このコントロールは、それぞれスコープに含める、またはスコープから除外するために明示的に選択されたアイテムのすべての子孫を暗黙のうちに選択する。コントロールは、さらに、複数の階層的に整列されているアイテムと別に、スコープに明示的に含まれるアイテムの第１の一覧、およびスコープから明示的に除外されたアイテムの第２の一覧も表示し、第２の一覧内のそれぞれのアイテムは、第１の一覧内のアイテムに対応する。

本発明の他の態様によれば、ユーザが、選択解除されたまたは暗黙のうちに除外されたアイテムを明示的に選択すると、コントロールは、スコープ内に明示的に含まれるべき明示的に選択されたアイテムの状態を変更し、スコープ内に暗黙のうちに含まれるべき明示的に選択されたアイテムのそれぞれの子孫の状態を変更する。ユーザが暗黙のうちに含まれるアイテムを明示的に選択すると、コントロールは、スコープから明示的に除外されるべき明示的に選択されたアイテムの状態を変更し、スコープから暗黙のうちに除外されるべき明示的に選択されたアイテムのそれぞれの子孫の状態を変更する。

いくつかの例示的な実施形態では、コントロールは、それぞれの表示されている明示的に含まれるアイテムに対応する第１の包含インジケータ、それぞれの表示されている暗黙のうちに含まれるアイテムに対応する、それぞれの包含インジケータよりも目立たない、第２の包含インジケータ、およびそれぞれの表示されている明示的に除外されたアイテムに対応する除外インジケータを表示することができる。

さらに、本発明の様々な実施例は、統合されたコレクションを作成するためのツールを備える。本発明のいくつかの実装では、ツールは、コレクションに入れるべきオブジェクトを受け取る「バスケット」コントロールを備えることができる。バスケットコントロールは、リストペイン（list pane）とも呼ばれる、例えば、コレクション内に含めるようにユーザによって選択されたデータオブジェクトを受け取って表示するためのインターフェースを備える。ユーザは、そのため、単にデータオブジェクトをバスケットコントロールに送ることによりデータオブジェクトのコレクションを作成することができる。次いで、コレクション作成コンポーネントは、１つまたは複数のデータアイテムがバスケットコントロールにサブミットされるオブジェクトに対応するコレクションを提供する。本発明の様々な態様により、コレクションは、離散データ（テキストなど）、データファイル、データファイルへのポインタ、指定された基準に基づいてデータファイルを識別することに関するクエリまたは除外、１つまたは複数のデータオブジェクトを格納する仮想フォルダおよび物理フォルダの両方、さらにデータオブジェクトの他のコレクションをも含む、所望のデータオブジェクトとともにコンパイルすることができる。

バスケットコントロールは、コレクションを作成するために単独で使用されるか、または他のソフトウェアオブジェクトによりホスティングされることが可能である。例えば、本発明の様々な実装は、さらに、バスケットコントロールと、データオブジェクトをバスケットコントロールに供給するためにユーザが使用することができる１つまたは複数のユーザインターフェースとを両方とも含む「リストメーカー」コントロールを備えることができる。例えば、リストメーカーコントロールは、データオブジェクトを表示するための表示用グラフィカルユーザインターフェース（ファイルブラウザなど）および表示用グラフィカルユーザインターフェースをナビゲートするためのナビゲーションツールバーを備えることができる。次いで、リストメーカーコントロールは、様々なソフトウェアアプリケーションにおいてソフトウェア開発者の望み通りにホスティングされることができる。

本発明の１つまたは複数の態様は、コンピュータシステム、格納されているソフトウェア、および／またはコンピュータシステム上に格納されているデータオブジェクトの静的な一覧を作成する方法を対象とすることができる。本発明のいくつかの態様では、コンピュータディスプレイデバイス上に、一次ビューペインおよびリストペインを含む、グラフィカルユーザインターフェース（ＧＵＩ）フレーム、例えば、エクスプローラフレームを表示することができる。一次ビューペインは、コンピュータシステム上の第１の定義済みの場所、例えば、ユーザにより識別された仮想フォルダまたは物理フォルダ内に格納されているデータオブジェクトを表示し、リストペインは、そのリストペインに関連付けられている静的一覧内のアイテムに対応する情報を表示する。静的一覧内のそれぞれのアイテムは、１つのデータオブジェクトに対応し、そのデータオブジェクトに関係する情報、例えば、そのデータオブジェクトへのポインタ、一覧内のアイテムの順序、そのアイテムに関する注釈などを含む。ユーザは、静的一覧に追加されるべき一次ビューペイン内に表示される第１のデータオブジェクトを識別し、第１のデータオブジェクトに対応するアイテムが静的一覧に追加されるように入力を与えることができる。第１のアイテムに関する情報、例えば、アイコン、名前、注釈などが、リストペイン内に表示することができる。ユーザは、第２の定義済みの場所を指定し、それにより、リストペインが関連付けられている静的一覧を変更することなく第２の定義済みの場所に格納されているデータオブジェクトを一次ビューペインに表示させることができる。

本発明の様々な例示的な態様によれば、それぞれの静的一覧は、永続性モデルを有し、そこでは、ユーザが静的一覧を保存する明示的なまたは暗黙の意図を述べていない限り、静的一覧のコンテンツは無視される。暗黙の意図は、ユーザが静的一覧の名前を既定の名前からユーザ定義名に変更することにより示される。

本発明のいくつかの態様では、作成しようとしているファイルのプレビュー表現がユーザに対し示されるシステムおよび方法を実現する。プレビューは、「ｓａｖｅｆｉｌｅ」ダイアログの一部として表示され、新しく作成すべきファイルに対応するしるしを示し、保存の実行後に新しいファイルをＧＵＩで視覚的にどのように表すかを示すことができる。プレビューは、ユーザが気づきやすいように、独自の外観を持つ、常に最初の要素として表示されるなどの特定のビヘイビアを示すことができる。また、ユーザは、ファイルが保存される前であっても、このプレビューを対話操作して、ファイルを管理し、および／またはそのプロパティを編集することができる。また、このプレビューでは、ユーザによる保存プロセスを、高度な判断を行う機能により、例えば、ユーザがファイルを無効な場所に保存することを拒絶したり、またはＧＵＩによるユーザナビゲーションに基づいてメタデータフィールドに初期値を自動入力したりすることにより、ガイドすることができる。

本発明の他の態様では、エクスプローラまたはシェルブラウザビューを専用ビューにすることにより、改善されたファイル閲覧インターフェースをユーザに提供するシステムおよび方法を実現する。閲覧インターフェースは、表示されるコンテンツにより異なっていてもよい。場合によっては、閲覧インターフェースは、表示されるコンテンツに基づいてブラウザパネル内に表示されるユーザインターフェースオプションをカスタマイズすることができる。ブラウザは、コンテンツに従って、表示されているプロパティを再整列、削除、および／または追加することができる。ブラウザの機能、外観、および／または編成などの他の態様は、コンテンツに基づいてカスタマイズすることができる。１つまたは複数のテンプレートを用意するか、および／または作成して、ブラウザパネルを生成するための所定の一組の基準を規定することができる。ユーザおよび／またはアプリケーションによる追加のブラウザパネルの作成を可能にするソフトウェアインターフェースを備えることもできる。ユーザがこのようなブラウザを対話操作することにより、ブラウザの外観および／または機能をさらに変えることができる。

本発明の他の態様によれば、統合されたページ空間コントロールを持つシェルブラウザは、コンピュータの記憶システム、オペレーティングシステム、ネットワークなどのためのナビゲーションを行うツールとなる。本発明の少なくともいくつかの実施例によれば、複数の異なるウィンドウ、アプリケーションプログラムなどにおいて、ナビゲーションツールおよび／またはその対応するユーザインターフェースおよびディスプレイを用意することができる。本発明の少なくともいくつかの実施例では、ナビゲーションツールおよび／または対応するユーザインターフェースおよび（複数の）表示パネルは、様々な異なるファイル、一覧、フォルダ、ページ、および／または他の記憶要素への「リンク」を含むウィンドウまたはペインを含むことができる。必要に応じて、本発明の少なくともいくつかの態様によるナビゲーションツールに対し、異なるアプリケーションプログラム向けのカスタマイズ、アプリケーションプログラムの一部分向けのカスタマイズ、オペレーティングシステムの一部分向けのカスタマイズ、異なるユーザによるカスタマイズなど（例えば、コンピュータオペレーティングシステムの供給者とは独立しているソフトウェア提供者によるカスタマイズ）を行い、そのナビゲーションツールをそのようなファイル群などに関係する、および／またはそのユーザに関係する情報をナビゲートすることに適したものにする、またはそのような情報をナビゲートすることをターゲットにするようにできる。本発明の少なくともいくつかの実施例によるナビゲーションツールは、さらに、ユーザのファイルに関する情報を、例えば、階層プロパティ、リスト、自動リスト、フォルダなどにより編成および／または表示する有用な手段ともなりうる。また、本発明の少なくともいくつかの実施例によるシステムおよび方法を使用すると、ユーザは、プロパティをファイルに割り当てる、ファイルに関連付けられている割り当てられたプロパティを変更するなどの操作を、階層プロパティを適宜使用して、容易に行うことができる。それに加えて、本発明の少なくともいくつかの実施例によれば、例えば、クエリベースのファイルおよび／または検索システムにおいて格納されたまたはアクセス可能ファイルに関する情報を探索し、特定し、表示するためのナビゲーションツールを実現することができる。

本発明の他の態様は、上述のように（および以下でさらに詳しく説明するように）コンピュータ記憶装置システム内に配置されているファイルおよび／またはコンピュータシステムを通じてアクセス可能なファイルに関係する情報を編成し、探索し、特定し、および／または表示するためのナビゲーションツールを備えるシステムおよび方法を含む、様々な方法を実行し、および／または様々なシステムを動作させるために格納されているコンピュータ実行可能命令を含むコンピュータ可読媒体に関係する。

本発明の１つまたは複数の例示的な態様では、ナビゲーションペインまたはパネルまたはページ空間コントロール内に複数のルートを作成し、カスタマイズする方法およびシステムを実現する。このようなシステムを使用することで、ユーザは、そのような代替えルートを通じて関連するドキュメント、アプリケーション、およびその他のデータに直接アクセスできるようにすることにより不必要なナビゲーションを回避することができる。ユーザは、所望のルートまたは構造をナビゲーションペイン内の特定の位置にドラッグすることによりナビゲーションペインをカスタマイズすることができる。ユーザは、そのペイン上の他のルートに相対的な特定の位置にルートをクリック＆ドラッグすることにより、ナビゲーションペイン内のルートの編成および再編成を行うことができる。ルートをデスクトップにドラッグすることにより、さらに、そのルートへのショートカットを作成することができる。ユーザは、さらに、それぞれのルートのプロパティを調整するオプションを利用することができ、それにより、さらにカスタマイズすることが可能になる。

本発明の一態様によれば、複数ルートシステムでは、ルートが現在のシステムで使用されている典型的な物理的な場所（つまり、物理フォルダ）を超える他の種類のノードを含むことができる。より具体的には、複数ルートシステムを使用すると、ユーザは、ナビゲーションペイン内でリストおよび自動リストをルートとして定義することができる。これらのリストおよび自動リストは、指定された一組の規則またはフィルタの条件を満たすファイルまたは他のデータを含むことができる。それに加えて、ルートは、ユーザの電子メールに対応するカスタム拡張機能（例えば、ＭＳＮ（登録商標）ＨｏｔｍａｉｌＤｒｉｖｅ）を含むことができる。ナビゲーションシステムに対するこれらの機能強化により、ユーザは、様々なアプリケーションにおいて好ましい一組のナビゲーションコントロールをカスタマイズする自由度を大幅に高めることができる。

本発明のいくつかの態様では、プロパティ（またはメタデータ）のユーザによる修正を可能にするシステムおよび方法を実現することができる。一態様では、多値プロパティを含むことができるファイルプロパティの表示を含むシェルブラウザが備えられる。ユーザは、多値プロパティを編集することができ、システムは、高度な判断を行う機能により、ユーザによる多値プロパティの編集を補助することができる。システムは、多値プロパティ値をトークン化することができ、フィールドのオプションをユーザに喚起する手段として多値プロパティフィールド内に永続的なプロンプトテキストを備えることができる。

システムは、集約されたプロパティ値を表示することができ、視覚的な差を組み込んで、集約された値を適用先のファイルに関連付けることができる。集約された値の編集は可能であり、集約された多値プロパティを編集する場合に、システムは、高度な判断を行う機能により、ユーザが、すでに使用されているエントリおよびプロパティ値が使用されているコンテキストなどの様々な因子に基づいてエントリを選択（または回避）するのを補助することができる。複数の選択されたファイルについて多値プロパティを集約する場合に、システムでは、特定の値が様々なファイル内に出現した順序を保存しやすくする措置を講じることもできる。ファイルの多値プロパティの先頭に比較的頻繁に出現する傾向を有していた値は、対応する集約された多値プロパティの先頭の方に向かって出現する傾向を有する。

本発明の他の態様では、ユーザナビゲーションに基づいてデータの動的ナビゲーションを行うための方法およびシステムを実現する。この方法は、ユーザが第１の次元で手動ナビゲートを行っている間に第２の次元でデータの動的スクロールを自動的に行うものである。この方法は、ウィンドウペイン内の所定の表示可能領域にコンテンツの１つのビューを表示することを含む。この方法は、さらに、ユーザ入力により関連するノードが少なくとも部分的に隠される結果になるかどうかを決定することを含む。この方法は、さらに、関連するノードが完全に見えるか、または可視性を増すように所定の距離についてコンテンツの１つのビューの動的水平スクロールを自動的に行うことも含む。本発明の様々な実施形態において、関連するノードは、入力またはビューフォーカスを持つツリーコントロール（例えば、ナビゲーションペイン、ナビゲーションパネル、ページ空間コントロールなど）の中のノードまたはユーザのマウスポインタもしくは他の入力のしるし（indicia）に最も近い位置にあるノードとすることができる。本発明は、方法として実装できることは理解されるが、本明細書で説明されているように、フォルダツリーコントロールにおけるユーザナビゲーションまたは他のデータのナビゲーション用のシステムとして実装することもできる。

本発明の様々な態様は、１つまたは複数のプログラミングインターフェース、またはデータファイルにアクセスするための他のインターフェースを介して他のコードモジュールと通信することができる。例えば、本発明の一態様では、１つまたは複数のユーザインターフェース（ＵＩ）コントロールを含む専用拡張性領域を持つファイルダイアログを備える。拡張性領域内に入れることができるコントロールは、ＵＩコントロールタイプの所定のコレクションから選択可能である。アプリケーションからＯＳに対しファイルダイアログを表示するよう要求があった場合、アプリケーションは、所定のコレクション内のタイプの１つまたは複数のコントロールを含めるように要求することができる。次いで、ＯＳは、表示されたダイアログの拡張性領域内に要求されたコントロールを配置する。アプリケーションは、識別されたコントロールのダイアログ内の位置を明示的に示すデータを供給する必要はない。アプリケーションは、さらに、コントロールをグループ内に配置すること、および／またはセパレータをグループとグループの間に入れることも要求することができる。

本発明の前述の態様およびその結果の利点の多くは、添付の図面と共に、以下の詳細な説明を参照することにより容易に理解できるため明白となろう。

本発明は、多数の望ましい機能を組み込んだファイルシステムシェルを対象とする。本質的に、シェルは、コンピュータ上に格納されているファイルおよび他のアイテムを表示し、操作する機能をユーザに提供するものである。以下の説明では、まず最初に、図１〜６６に示されている機能の要約を述べ、次いで、詳細な説明を行う。

図１〜９は、一般的に、仮想フォルダのシステム全体を対象とする。仮想フォルダは、従来のユーザインターフェースで通常のファイルおよびフォルダ（ディレクトリとも呼ばれる）を、ディスク上の実際の物理的基礎ファイルシステム構造の代わりに、メタデータに基づく異なるビューでユーザに公開するための方法を提供するものである。図１０〜１８は、仮想フォルダがデータベース内に格納されているプロパティを取り、それをフォルダに似たコンテナとして表すことができることに関係する、スタックを一般的に対象とする。図１９〜２１は、一般的に、標準フォルダを操作するために現在使用されているメカニズムに類似している仮想フォルダを操作するためのメカニズムを実現することに関係する、仮想フォルダの直接操作を対象とする（例えば、コピー、貼り付け、クリック＆ドラッグなど）。図２２〜２９は、一般的に、ファイル／アイテムの集合を絞り込むためのツール群を備える、フィルタを対象とする。図３０〜３４は、一般的に、ファイル／アイテムの集合の有用なビューを生成するためにクリックすることができる一組の所定のリンクである、クイックリンクを対象とする。図３５〜３６は、一般的に、使用可能なタイプのファイルのグループを１つに関連付け、特定のタイプのアイテムに関係するツールおよびアクティビティを提供することができるという概念に関係する、ライブラリを対象とする。図３７〜３８は、一般的に、ユーザがすべてのファイル／アイテムを、それらが１つの場所にある場合と何ら変わることなく利用できるように、複数の物理的な場所（例えば、異なるハードドライブ、異なるコンピュータ、ネットワークロケーション上のコンピュータなど）からファイル／アイテムを取り出すことができるという概念に関係するスコープを対象とする。図３９〜４０は、一般的に、ファイルとともにデータベースに格納することができ、電子メールおよび連絡先などのアイテムを含むことができる、非ファイルアイテムを対象とする。図４１〜５０は、一般的に、複数のセグメントを含み、それぞれのセグメントがコンテンツを選択するためのフィルタに対応する、仮想アドレスバーを対象とする。図５１〜５７は、一般的に、シェルブラウザを対象とし、このシェルブラウザを使用して、ユーザはアイテムを、そのアイテムに関連付けられているメタデータに基づいて容易に識別することができる。図５８〜６６は、一般的に、複数のアイテムタイプを表す複数のアイテムを表示するように構成されているシェルブラウザ内のオブジェクトプレビューアの機能を拡張することを対象とする。以下では、本発明のこれらの態様のそれぞれについて詳しく説明する。

上述のように、図１〜９は、一般的に、仮想フォルダを実装するためのシステムを対象とする。仮想フォルダでは、ファイルシステムに現在使用されているものと同じまたは類似のユーザインターフェースを使用する。仮想フォルダでは、通常のファイルおよびフォルダ（ディレクトリとも呼ばれる）を、ディスク上の実際の物理的基礎ファイルシステム構造の代わりに、メタデータに基づく異なるビューでユーザに公開する。場所に依存しないビューが作成され、これにより、ユーザは、ファイルシステムを管理するために現在使用されているものと類似のコントロールを使用してファイルおよびフォルダを操作することができる。一般に、このことは、ユーザが、管理および編成作業をシステムの独立した部分として実行するのではなく、ファイルそれ自体の固有のプロパティに基づいてファイルを編成し、再整列することができることを意味する。仮想フォルダは、いくつかのファイルまたはいくつかのアイテムの１つのビューで異なる物理的な場所に置かれているファイルまたはアイテムを公開することができるように、同じコンピュータ内、または複数のコンピュータ間、または異なるネットワークロケーション上の複数のディスクドライブなどの異なる仮想的または物理的な場所からのファイルまたはアイテムを表すことができる。一実施形態では、異なるアイテムまたはファイルは、含められるために、ＩＰネットワークを介して接続すればよい。

仮想フォルダモデリングも、従来の非ファイルエンティティに使用することができる。これの応用は、従来の非ファイルエンティティを示すためにファイルおよびフォルダ（つまり、オブジェクトおよびコンテナ）に類似した一組のユーザインターフェースを持つことである。このような非ファイルエンティティの一実施例は電子メールであるが、他には、連絡先データベースからの連絡先情報などがある。このようにして、仮想フォルダは、表示されるデータがファイル由来であろうが、非ファイルエンティティ由来であろうが関係なく、機能する場所に依存しないメタデータベースビューシステムを実現する。一般に、これらの態様では、ユーザにファイルおよびデータを操作させること、共通ユーザインターフェース技術（ドラッグ＆ドロップ、ダブルクリックなど）を使用すること、さらには様々なデータタイプのリッチインテグレーションを活用することに関する柔軟性を高めることができる。

図１および以下の説明は、本発明を実施できる適当なコンピューティング環境について簡潔に述べた一般的な説明である。必要というわけではないが、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的文脈において本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、キャラクタ、コンポーネント、データ構造体などを含む。当業者であれば理解できるように、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、他のコンピュータシステム構成を使用して実施できる。また、本発明は、通信ネットワークを通じてリンクされているリモート処理装置によりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方の記憶装置内に配置されうる。

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

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

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

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

図１に例示されているタイプのシステム上に実装されているため、本発明では、ユーザがファイル操作およびフォルダナビゲーション（閲覧）周辺の基本タスクを簡単に実行し、新しい機能において利用することができる、より高水準の記憶装置機能を容易に実現できる仮想フォルダを使用する。仮想フォルダでは、ファイルおよびアイテムを、ディスク上の実際の物理的基礎ファイルシステム構造の代わりに、メタデータに基づく異なるビューでユーザに公開する。

図２は、本発明による仮想フォルダシステム２００のブロック図である。以下で詳しく説明するように、仮想フォルダを使用すると、ユーザは、データの見え方を制御する「ピボット」を変更することができる。例えば、ユーザは、アルバム別にグループ化することができる、すべての楽曲のフラットリストとして音楽を表示することができる。それとは別に、ユーザは、ジャンルまたはアーティストまたは年などのみを示すようにビューを切り換えることも可能である。ユーザは、目先のタスクに適するオブジェクトのみを示すようにこのビューを修正することができる。これにより、閲覧エクスペリエンスが改善され、フォルダをさらに（上へ下へと）ナビゲートする必要がなくなる。同じ教訓と可能性が、ファイルとして格納されない他のデータ型をモデル化することにも当てはまる。例えば、連絡先は、この方法でユーザに公開することができ、これにより、おなじみのインターフェース機能が得られるとともに、フラットな電話帳により与えられる以上にリッチな操作のためのインフラストラクチャが得られる。

図２に例示されるように、仮想フォルダシステム２００は、フォルダプロセッサ２１０、リレーショナルデータベース２３０、仮想フォルダ記述データベース２３２、他のシェルフォルダコンポーネント２３４、フォルダハンドラコンポーネント２３６、およびシェルブラウザとビューコンポーネント２４０を含む。フォルダプロセッサ２１０は、ネイティブハンドリングコードコンポーネント２１２、ハンドラファクトリコンポーネント２１４、プロパティライターコンポーネント２１６、行セットパーサーコンポーネント２１８、クエリビルダーコンポーネント２２０、列挙子コンポーネント２２２、およびプロパティファクトリコンポーネント２２４を含む。

リレーショナルデータベース２３０は、システム内のすべてのファイルに関するプロパティを格納する。また、連絡先のようないくつかのアイテム（つまり、非ファイルアイテム）を丸ごと格納する。一般に、これは、ファイルのタイプに関するメタデータおよびメタデータが含むアイテムを格納する。リレーショナルデータベース２３０は、クエリビルダー２２０からＳＱＬクエリを受け取る。リレーショナルデータベース２３０は、さらに、ＳＱＬ行セットを行セットパーサーコンポーネント２１８に、アイテム列毎に１行ずつ送る。ただし、列は、アイテムプロパティである。

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

他のシェルフォルダコンポーネント２３４に関して、フォルダプロセッサ２１０は、ハンドラまたはプロパティについて、すべてのファイルを含む様々なタイプのアイテムから既存のシェルフォルダにデリゲート（delegate）する。他のシェルフォルダコンポーネント２３４は、他のフォルダからのプロパティをプロパティファクトリ２２４に送る。他のシェルフォルダコンポーネントも、ハンドラをハンドラファクトリ２１４に送る。

フォルダハンドラコンポーネント２３６は、連絡先などのデータベースにのみ存在するアイテムに対するコードビヘイビアを規定する。これは、非ファイルアイテムに、ファイルに似たビヘイビアを行わせることができる機能である。フォルダハンドラコンポーネント２３６は、ハンドラをハンドラファクトリ２１４に送る。

ネイティブハンドリングコードコンポーネント２１２については、フォルダプロセッサ２１０は、アイテムのプロパティに基づいていくつかのハンドラを直接実装する。ネイティブハンドリングコードコンポーネント２１２は、ハンドラをハンドラファクトリ２１４に送る。ネイティブハンドリングコードコンポーネント２１２およびフォルダハンドラコンポーネント２３６では、すべての名前空間と同様に、仮想フォルダが、それらのアイテム用の一組のハンドラ（コンテキストメニュー、アイコン、サムネイル、インフォチップ、．．．）を備えていなければならない。これらの大半（インフォチップ、データオブジェクト、ドラッグ＆ドロップハンドラ、バックグラウンドコンテキストメニュー、．．．）について、仮想フォルダは、保持されるすべてのタイプについて共通の（ネイティブ）ハンドラを備える。しかし、そのタイプの作成者が提供すべき他のもの（アイテムそれ自体のコンテキストメニュー、書き込み可能プロパティストア、．．．）がある。既定のハンドラも、上書きすることができる。仮想フォルダでは、ファイルについてこれを再利用し、非ファイルアイテムに同じことを実行させる。

ハンドラファクトリ２１４は、ＩＤリストを取り、コンテキストメニュー、アイコンなどを提供するコードビヘイビアを生み出す。一般に、フォルダプロセッサ２１０は、ネイティブハンドリングコードコンポーネント２１２、他のシェルフォルダコンポーネント２３４、およびフォルダハンドラコンポーネント２３６に関して上述のように、ハンドラを取得するために、ネイティブハンドラ、外部ハンドラ、または他のシェルフォルダへのデリゲートを使用することができる。ハンドラファクトリコンポーネント２１４は、ビューにより要求されたとおりに、ハンドラをビュー２４０内のシェルブラウザに送る。ハンドラファクトリコンポーネント２１４は、プロパティハンドラをプロパティライター２１６に送る。

プロパティライター２１６は、切り取り、コピー、および貼り付けなどのユーザの意図をファイルまたはアイテムに対する所有権に変換する。シェルブラウザおよびビューコンポーネント２４０は、直接操作（切り取り／コピー／貼り付け）またはメタデータの編集を含めて、プロパティライター２１６にデータを送る。一般に、仮想フォルダはアイテムのプロパティに基づいて編成を行うので、移動およびコピー（ドラッグ＆ドロップ）などのオペレーションは、それらのプロパティに対する編集となる。例えば、作成者別にスタッキングされたビュー内でドキュメントをＡｕｔｈｏｒ１からＡｕｔｈｏｒ２へ移動することは、作成者を変更することを意味する。プロパティライターコンポーネント２１６は、この機能を実装する。

行セットパーサー２１８は、データベース行セットを取り、すべてのアイテムプロパティをシェルＩＤリスト構造内に格納する。行セットは、仮想フォルダの区分的定義を取り、次いでデータベースに発行できるＳＱＬ文字列を構築する。行セットパーサーコンポーネント２１８は、ＩＤリストを列挙子コンポーネント２２２に送る。上述のように、行セットパーサーコンポーネント２１８は、さらに、ＳＱＬ行セットを含むリレーショナルデータベース２３０からデータをアイテム毎に１行ずつ受け取る。ただし、列はアイテムプロパティである。

クエリビルダーコンポーネント２２０は、ＳＱＬクエリを構築する。クエリビルダーコンポーネント２２０は、列挙子コンポーネント２２２から、ナビゲーションからの新しいフィルタを含むデータを受け取る。クエリビルダーコンポーネント２２０は、さらに、フォルダ内に表示するタイプ、初期フィルタ、および（スコープ）からの結果を表示するための物理的な場所のリストを含むデータを、仮想フォルダ記述データベース２３２から受け取る。クエリビルダーコンポーネント２２０は、リレーショナルデータベース２３０にＳＱＬクエリを送る。

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

列挙子コンポーネント２２２は、仮想フォルダへのナビゲーションに応じて動作する。上述のように、列挙子コンポーネント２２２は、行セットパーサーコンポーネント２１８からＩＤリストを受け取り、ナビゲーションから新しいフィルタをクエリビルダーコンポーネント２２０に送る。列挙子コンポーネント２２２は、さらに、ナビゲーションの後にビュー内に挿入するため返されるＩＤリストを含むデータを、シェルブラウザおよびビューコンポーネント２４０に送る。

プロパティファクトリコンポーネント２２４は、ＩＤリストおよびプロパティ識別子を取り、それらのプロパティに対する値を返す。プロパティファクトリコンポーネント２２４は、プロパティハンドラを含むハンドラファクトリコンポーネント２１４からデータを受け取る。上述のように、プロパティファクトリコンポーネント２２４は、さらに、他のフォルダからのプロパティを含むデータを、他のシェルフォルダコンポーネント２３４から受け取る。プロパティファクトリコンポーネント２２４は、さらに、ビューにより要求されたとおりに、アイテムプロパティを含むデータをシェルブラウザおよびビューコンポーネント２４０に送る。

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

上述のように、仮想フォルダでは、通常のファイルおよびフォルダ（ディレクトリとも呼ばれる）を、ディスク上の実際の物理的基礎ファイルシステム構造の代わりに、メタデータに基づく異なるビューでユーザに公開する。そのため、システムは、データベースに格納されているプロパティを受け取り、それをフォルダのようなコンテナとして表すことができる。ユーザは、すでに、フォルダの操作に慣れているので、仮想フォルダを類似の方法で表示することにより、ユーザは、新しいシステムに素早く適応できる。

図３は、選択されたアイテムを引き戻すクエリをユーザが与えるために使用される、ルーチン３００を例示する流れ図である。ブロック３０２で、フォルダプロセッサは、ユーザからクエリを取得する。ブロック３０４で、フォルダプロセッサは、リレーショナルデータベースにクエリを受け渡す。ブロック３０６で、リレーショナルデータベースから結果がフォルダプロセッサに送り返される。ブロック３０８で、フォルダプロセッサは、結果を仮想フォルダおよびアイテムの形でユーザに与える。

図４は、既定のクエリ、またはユーザからのクエリのいずれかに従って仮想フォルダが作成され、画面上に表示される際に使用されるルーチン３２０を例示する流れ図である。ブロック３２２で、ユーザがまず最初に仮想フォルダを開くと、既定のクエリが使用される。この既定のクエリは、レジストリから取り出される。例えば、音楽ライブラリの既定のクエリは、アルバム別にグループ化されたすべての楽曲を示すようにすることが可能である。ブロック３２４で、フォルダプロセッサは、このクエリに対するクエリオブジェクトを構築し、このクエリをリレーショナルデータベースに受け渡す。ブロック３２６で、リレーショナルデータベースは、クエリの結果を生成し、それらの結果をデータベースの行および列としてフォルダプロセッサに返す。

ブロック３２８で、フォルダプロセッサは、これらの結果を取り出し、データの行および列から列挙子構造体（enumerator structure）に変換し、フォルダビューでは、それを使用し、ユーザが対話操作する結果のフォルダおよびアイテムを画面に初期値として表示する。決定ブロック３３０で、ユーザは、（異なるクエリまたは「ピボット」を発行することにより）ビューを変更するかどうかを決定する。例えば、ユーザは、「ｓｈｏｗａｌｌａｒｔｉｓｔｓ」ピボットを発行することが可能である。ユーザ側でビューを変更したい場合、ルーチンは、ブロック３２４に戻り、そこで、フォルダプロセッサは、この新しいクエリをリレーショナルデータベースに受け渡し、返される結果の新しい行および列を受け取り、新しい列挙子構造体を構築する。次いで、このプロセスは、上述のように続くが、その際にフォルダビューがクリアされ更新され、そのときに列挙子を使用して画面に「ａｒｔｉｓｔ」オブジェクトを描画する。

一実施例では、ユーザが中へナビゲートできるコンテナを表すアルバムオブジェクトが実現される。例えば、「Ｂｅａｔｌｅｓ」アルバムをダブルクリックすると、ビューのナビゲートが行われ、Ｂｅａｔｌｅｓの全楽曲が表示される。フォルダプロセッサは、「ｓｈｏｗａｌｌＢｅａｔｌｅｓ’ ｓｏｎｇｓ」クエリをリレーショナルデータベースに発行し、それらの楽曲に対するデータの行および列を返してよこす。フォルダプロセッサは、それらすべての楽曲の列挙子を作成し、次いで、それらを画面に描画する。

ユーザは、さらに、仮想フォルダを閲覧しつつ任意の時点でビューを選択することもできる。上記の実施例から、絞り込みを行ってＢｅａｔｌｅｓの楽曲だけを表示するようにした後、ユーザは、楽曲をアルバムとしてのみ表示するようにビューを変更することができる。アイテムのビューを他の表現に変更するプロセスのことを、「スタッキング」と呼ぶ。これは、アイテムがその表現に基づいて概念的に複数の「スタック」に整列されるからである。この場合、楽曲は、様々なアルバムのそれぞれについて複数のスタックに再整列される。次いで、ユーザは、これらのスタックのうちの１つにナビゲートし、その特定のアルバムからの楽曲のみを表示するようにできる。ここでもまた、ユーザは、プロパティ（例えば、評価）に基づいてこれらの残りの楽曲のビューをスタックに再整列することができる。評価プロパティが選択された場合、そのＢｅａｔｌｅｓアルバムからの楽曲は、１つ星、２つ星、または３つ星の評価でスタック内に表示される。

それぞれのクエリの結果は、どの物理的または仮想的な場所がスコープ内に含まれるかにより決まる。例えば、スコープは、ユーザの「ｍｙｄｏｃｕｍｅｎｔｓ」フォルダ内のいくつかのフォルダのみを含むようにすることができる。それとは別に、スコープは、コンピュータ上のすべてのフォルダ、さらには、複数のネットワーク接続コンピュータ上のすべてのフォルダを含むことが可能である。ユーザは、スコーププロパティシートを通じてスコープを表示し変更することができる。一実施例では、スコーププロパティシートは、仮想フォルダを右クリックし、「ｐｒｏｐｅｒｔｉｅｓ」を選択することにより公開することが可能である。ユーザは、新しいフォルダをスコープに追加したり、またはすでに追加されているフォルダを削除したりすることが可能である。

仮想フォルダが特に役立つユーザ群として、知識労働者がある。仮想フォルダを使用することで、知識労働者は、ドキュメントの表示をファイルタイプ別、プロジェクト別、ケース番号別、作成者別などに容易に切り替えることができる。知識労働者はそれぞれ、ドキュメントを編成するための異なる方法を持っている傾向があるため、仮想フォルダを使用することで、そうした様々なユーザ設定に対応することができる。

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

図５に例示されているように、フォルダ４００は、「ｍｙｄｏｃｕｍｅｎｔｓ」フォルダである。第１のレベルでは、フォルダ４００は、フォルダ４１０、４２０、および４３０を含み、これらは、それぞれ、Ｃｌｉｅｎｔ１、２、および３に対応する。第２のレベルでは、フォルダ４１０、４２０、および４３０のそれぞれは、フォルダ４１１、４２１、および４３１をそれぞれ含み、これらは、それぞれ、選択されたクライアントのコントラクトに対応する。第３のレベルでは、フォルダ４１１、４２１、および４３１のそれぞれは、フォルダ４１２、４２２、および４３２をそれぞれ含み、これらは、それぞれ、２００１年に対応する。第３のレベルでは、フォルダ４１１、４２１、および４３１のそれぞれは、さらに、フォルダ４１３、４２３、および４３３をそれぞれ含み、これらは、それぞれ、２００２年に対応する。

図５に例示されているような物理フォルダファイル構造をナビゲートすることを望んでいるユーザに対し、多数の障害が出現することは理解されるであろう。例えば、ユーザが、自分の生成したすべてのコントラクトを扱いたい場合、ユーザはまず最初に、Ｃｌｉｅｎｔ１に対するコントラクトを扱うためにフォルダ４１１にナビゲートする必要があり、次いで、フォルダ４２１に再ナビゲートして、Ｃｌｉｅｎｔ２に対するコントラクトに到達しなければならず、再び、フォルダ４３１に再ナビゲートして、Ｃｌｉｅｎｔ３に対するコントラクトを得なければならない。この整列では、ユーザがすべてのコントラクトにアクセスするのは困難であり、一般に、すべてのコントラクトの表示および操作を同時に行うことができない。同様に、ユーザが２００１年に作成したコントラクトのすべてを表示したい場合、ユーザは、それぞれ、フォルダ４１２、４２２、および４３２へのナビゲートおよび再ナビゲートを行わなければならない。以下でさらに詳しく説明するように、本発明の仮想フォルダは、改善されたファイルシステム構造をもたらす。

図６は、仮想フォルダ構造のツリー図である。以下で詳しく説明するように、仮想フォルダは、ユーザがファイルおよびフォルダを使いやすく操作できるようにする、場所に依存しないビューを作成する。図６に示されるように、仮想フォルダは、スタックとして表される。仮想フォルダ５００は、「ａｌｌｉｔｅｍｓ」フォルダである。第１のレベルでは、仮想フォルダ５００は、仮想フォルダ５１０、５２０、および５３０を含み、これらは、それぞれ、クライアント、コントラクト、および年に対応する。以下でさらに詳しく説明するように、この構造を使用すると、ユーザは、所望のパラメータに応じてファイルにアクセスすることができる。

図７は、図６の仮想フォルダ構造のツリー図であり、第２のレベルでは、仮想フォルダ５１０が、さらに、仮想フォルダ５１１および５１２を含み、これらは、それぞれ、コントラクトおよび年に対応している。つまり、仮想フォルダ５１０のクライアントスタックは、さらに、コントラクトおよび年によりフィルタ処理されるということである。どのファイルおよびアイテムが仮想フォルダのそれぞれに含まれるかを決定するプロセスは、以下でさらに詳しく説明する。

図８は、図７の仮想フォルダ構造のツリー図であり、第３のレベルでは、仮想フォルダ５１１が、仮想フォルダ５１３を含み、これは、年に対応している。言い換えると、仮想フォルダ５１１のコントラクトスタックは、さらに、年によりフィルタ処理される。仮想フォルダ５１０、５１１、および５１３に対する仮想フォルダ構造は、クライアント、コントラクト、および年に応じて構造化されているが、仮想フォルダでは、図９を参照しつつ以下でさらに詳しく説明するように、他の構造化シーケンスが生じうる。

図９は、図６の仮想フォルダ構造のツリー図であり、第２のレベルでは、仮想フォルダ５２０が、さらに、仮想フォルダ５２１および５２２にフィルタ処理されており、これらは、クライアントおよび年に対応している。第３のレベルでは、仮想フォルダ５２１は仮想フォルダ５２３にフィルタ処理されており、これは年に対応する。図８および９の組織構造を対比することで、仮想フォルダシステムの柔軟性を例示することができる。つまり、仮想フォルダシステムでは、ユーザは、図５に例示されているような物理ファイル構造の場所に依存するビューに依存するのとは反対に、所望のパラメータに応じて仮想フォルダをナビゲートすることができる。

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

クイックリンク要素は、「ａｌｌｃａｔｅｇｏｒｉｅｓ」クイックリンク６１０、「ａｌｌａｕｔｈｏｒｓ」クイックリンク６１１、「Ｊａｎｕａｒｙｗｏｒｋ」クイックリンク６１２、および追加のクイックリンク６１３を表示するための選択を含む。以下でさらに詳しく説明するように、クイックリンクは、仮想フォルダの所望のナビゲーションを実行するためにユーザが選択することができる。クイックリンクは、システム側で実現され、いくつかのクイックリンクは、ユーザ側で作成し、保存することができる。

フィルタ要素は、「ｆｉｌｔｅｒｂｙ」インジケータ６２０、エントリブランク６２１、「ｂｙｄａｔｅ」インジケータ６２２、「ｙｅａｒ」セレクタ６２３、「ｐｉｃｋａｎａｕｔｈｏｒ」セレクタ６２４、「ｐｉｃｋａｃａｔｅｇｏｒｙ」セレクタ６２５、および「ｍｏｒｅｆｉｌｔｅｒｓ」セレクタ６２６を含む。「ｆｉｌｔｅｒｂｙ」インジケータ６２０は、以下のアイテムが仮想フォルダまたはアイテムをフィルタ処理するために使用できるという事実をユーザに教える。エントリブランク６２１は、ユーザが所望の新しいフィルタ条件を入力できる領域を提供する。「ｂｙｄａｔｅ」インジケータ６２２は、「ｙｅａｒ」セレクタ６２３から日付を選択することにより、選択された年で仮想フォルダまたはアイテムをフィルタ処理することができるという事実をユーザに教える。「ｐｉｃｋａｎａｕｔｈｏｒ」セレクタ６２４を使用すると、ユーザは特定の作成者に応じてフィルタ処理することができる。「ｐｉｃｋａｃａｔｅｇｏｒｙ」セレクタ６２５を使用すると、ユーザは選択されたカテゴリに応じてフィルタ処理することができる。「ｍｏｒｅｆｉｌｔｅｒｓ」セレクタ６２６を使用すると、ユーザは、ディスプレイ上に追加のフィルタを引き出すことができる。

アクティビティセレクタは、「ｃｒｅａｔｅａｎｅｗｃａｔｅｇｏｒｙ」セレクタ６３０、「ａｃｔｉｖｉｔｙ」セレクタ６３１および６３２、および「ｍｏｒｅａｃｔｉｖｉｔｉｅｓ」セレクタ６３３を含む。以下でさらに詳しく説明するように、提示されるアクティビティは、一般的に望ましい機能用とすることができるか、またはより具体的には、現在表示されている仮想フォルダのタイプに有用なアクティビティを対象とすることができる。例えば、「ｃｒｅａｔｅａｎｅｗｃａｔｅｇｏｒｙ」セレクタ６３０は、新しいスタックにより表される新しいカテゴリを作成するために、ユーザにより選択されることができる。

上述のように、アクティビティセレクタ６３１および６３２は、表示されているフォルダまたはアイテムのタイプをより明確に対象とすることができる。例えば、本発明の表示は、ドキュメントライブラリのものであり、「ａｃｔｉｖｉｔｙ」セレクタ６３１および６３２は、添付の編集または作成などのドキュメントのように特に手直しされたアクティビティを対象とすることができる。本発明のライブラリが写真ライブラリであった場合、「ａｃｔｉｖｉｔｙ」セレクタ６３１および６３２は、写真アルバムを形成するまたは写真を他のユーザと共有するなどの、写真を特に対象とするアクティビティに対するものとすることが可能である。

情報およびコントロール要素は、情報行６４０および情報行（アドレスバー）６４１、コントロール行６４２、バックスペースコントロール６４３、および情報行６４４および６４５を含む。情報行６４０およびアドレスバー６４１は、仮想フォルダまたはアイテムの現在のナビゲーションに関する情報を与える。本発明の実施例では、情報行６４０は、現在のナビゲーションがドキュメントライブラリへのナビゲーションであることを示すが、アドレスバー６４１は、より完全なナビゲーションを示し、ドキュメントライブラリが記憶領域内にあることを示している。コントロール行６４２は、多数の標準コントロールを備え、バックスペースボタン６４３を使用することにより、ユーザは、ナビゲーションを遡ることができる。情報行６４４は、現在のナビゲーションの内容に関する数値情報を与える。本発明の実施例では、情報行６４４は、ドキュメントライブラリのスタック内に１００ＭＢを占有する４１個のアイテムがあることを示している。情報行６４５は、選択されたファイルに関する追加の情報などを与えるために使用することができる。

ドキュメントライブラリのスタックは、「ＡＢＣＣｏｒｐ．」スタック６５１、「ｂａｃｋｕｐｓ」スタック６５２、「ｂｕｓｉｎｅｓｓｐｌａｎｓ」スタック６５３、「ＸＹＺＣｏｒｐ．」スタック６５４、および「ｍａｒｋｅｔｉｎｇｒｅｐｏｒｔｓ」スタック６５５を含む。それぞれのスタックの上の数字は、スタック内にいくつアイテムが入っているかを示す。例えば、「ＡＢＣＣｏｒｐ．」スタック６５１は、８個のアイテムを含むことが示されている。スタックのアイテムの総数は、結局、情報行６４４内に示されているアイテムの個数になるが、これは、上述のように、本発明の実施例では４１である。所望のアイテムを選択するためにユーザが使用することができる選択ボックスＳＢが用意されている。「ＡＢＣＣｏｒｐ．」スタック６５１を選択することにより、図１１に関して以下で説明するように、そのスタックのアイテムのビューが得られる。

図１１は、図１０の「ＡＢＣＣｏｒｐ．」スタック６５１内のアイテムを示す画面表示を例示する図である。情報行６４０およびアドレスバー６４１は、ここで、現在のナビゲーションが「ＡＢＣＣｏｒｐ．」スタックを示していること示すことに留意されたい。「ＡＢＣＣｏｒｐ．」スタック６５１は、８個のドキュメント７５１〜７５８を含むことが示されており、これは、それぞれドキュメント１〜８に対応する。情報行６４４は、それに対応して、２０ＭＢのメモリを占有する８個のアイテムがあることを示している。図１１のドキュメントは、さらに、「ＡＢＣＣｏｒｐ．」スタック内にスタックとして整列することができる。つまり、「ＡＢＣＣｏｒｐ．」スタック６５１により表されている仮想フォルダ内では、追加の仮想フォルダは、図１２〜１６に関して以下で説明するように、ドキュメントを保持するように編成することができる。

図１２は、図１１のドキュメントについてスタック機能が選択されている画面表示を例示する図である。図１２に示されているように、ユーザは、機能ボックス７６０を引き出すことができる。機能ボックス７６０は、「ｖｉｅｗ」選択７６１、「ａｒｒａｎｇｅｉｃｏｎｓｂｙ」選択７６２、「ｓｔａｃｋｓ」選択７６３、「ｒｅｆｒｅｓｈ」選択７６４、「ｏｐｅｎｃｏｎｔａｉｎｉｎｇｆｏｌｄｅｒｓ」選択７６５、「ｃｕｔ」選択７６６、「ｃｏｐｙ」選択７６７、「ｕｎｄｏ」選択７６８、「ｎｅｗ」選択７６９、および「ｐｒｏｐｅｒｔｉｅｓ」選択７７０を含む。選択ボックスＳＢは、「ｓｔａｃｋｓ」選択７６３の周りにあるように示されている。

図１３は、図１２のスタッキング機能について「ｓｔａｃｋｂｙａｕｔｈｏｒ」パラメータが選択されている画面表示を例示する図である。図１３に示されているように、様々なスタッキングオプションを備えるボックス７８０が表示される。スタッキングオプションは、「ｕｎｓｔａｃｋ」オプション７８１、「ｓｔａｃｋｂｙｃａｔｅｇｏｒｙ」オプション７８２、「ｓｔａｃｋｂｙａｕｔｈｏｒ」オプション７８３、および「ｓｔａｃｋｂｙａｕｓｅｒ」オプション７８４を含む。選択ボックスＳＢは、「ｓｔａｃｋｂｙａｕｔｈｏｒ」オプション７８３の周りにあるように示されている。

図１４は、図１３のファイルが作成者別にスタッキングされている画面表示を例示する図である。図１４に示されているように、スタック７９１および７９２は、それぞれ、作成者ＢｏｂおよびＬｉｓａに対応する。スタックそれぞれの上にある数字により示されているように、Ｂｏｂスタック７９１は、２つのアイテムを含み、Ｌｉｓａスタック７９２は、５個のアイテムを含んでいる。アイテム７５８（ドキュメント８に対応する）は、作成者を持っていなかったので、「ａｕｔｈｏｒ」スタックには含まれない。スタック７９１および７９２は、「ＡＢＣＣｏｒｐ．」スタック６５１内など、複数のレベルで編成することができることを例示している。したがって、仮想フォルダは、「Ｌｉｓａ」スタック７９２がドキュメントライブラリ内にある「ＡＢＣＣｏｒｐ．」スタック６５１内に入っているなど、複数レベルで形成することができる。

図１５は、図１４の再スタッキング機能について「ｓｔａｃｋｂｙｃａｔｅｇｏｒｙ」オプションがさらに選択されている画面表示を例示する図である。図１５に示されているように、選択ボックスＳＢは、「ｓｔａｃｋｂｙｃａｔｅｇｏｒｙ」オプション７８２の周りにある。アイテムのいくつかは、スタック７９１および７９２内にすでにスタッキングされているため、図１６を参照しつつ以下で詳しく説明するように、「ｓｔａｃｋｂｙｃａｔｅｇｏｒｙ」オプション７８２の選択で、アイテムが再スタッキングされる。

図１６は、図１４のファイルがカテゴリ別に再スタッキングされている画面表示を例示する図である。図１６に示されているように、スタック７９３および７９４は、それぞれ、「ＸＹＺＣｏｒｐ．」および「ｍａｒｋｅｔｉｎｇｒｅｐｏｒｔｓ」カテゴリに対応する。ドキュメント１および２に対応している、アイテム７５１および７５２は、追加のカテゴリに対して指定されていなかったため、他のカテゴリスタックのどれにも入らなかった。

図１７は、物理フォルダのクイックリンクが選択されている画面表示を例示する図である。選択ボックスＳＢは、「ａｌｌｆｏｌｄｅｒｓ」クイックリンク６１６の周りにあるように示されている。図１８に関して以下でさらに詳しく説明するように、「ａｌｌｆｏｌｄｅｒｓ」クイックリンク６１６は、物理フォルダのビューへの切り換え機能を備える。

図１８は、物理フォルダを示す画面表示を例示する図である。示されている物理フォルダは、図１７の仮想フォルダスタックのファイルを含む。つまり、図１７のスタック６５１〜６５５内に含まれるアイテムは、さらに、システム内のいくつかの物理フォルダ内にも含まれる。これらは図１８において、本発明のコンピュータ上に配置されている「ＭｙＤｏｃｕｍｅｎｔｓ」フォルダ８５１、本発明のコンピュータ上に配置されている「Ｄｅｓｋｔｏｐ」フォルダ８５２、ハードドライブＣ：上に配置されている「Ｆｏｏ」フォルダ８５３、サーバー上に配置されている「ＭｙＦｉｌｅｓ」フォルダ８５４、外部ドライブ上に配置されている「ＥｘｔｅｒｎａｌＤｒｉｖｅ」フォルダ８５５、他のコンピュータ上に配置されている「ＭｙＤｏｃｕｍｅｎｔｓ」フォルダ８５６、および他のコンピュータ上に配置されている「Ｄｅｓｋｔｏｐ」フォルダ８５７として示されている。

図１８に示されているように、ユーザは、図１７の仮想ファイル表現から図１８の物理ファイル表現に切り換えることができる。これにより、ユーザは、仮想ファイル表現と物理ファイル表現とを、そのどちらが現在のタスクに望ましいかに応じて、切り換えることができる。物理フォルダ８５１〜８５７についての様々な場所も、以下でさらに詳しく説明するように、仮想ファイルシステムのスコープが比較的広い場合があることを例示している。

図１９は、ユーザが仮想フォルダを直接操作するために使用されるルーチン８８０を例示する流れ図である。以下でさらに詳しく説明するように、仮想フォルダを操作するために用意されるメカニズムは、通常のフォルダを操作（例えば、クリック＆ドラッグ、コピー、貼り付けなど）するために現在使用されているメカニズムと類似している。図１９に示されているように、ブロック８８２では、システムは、表示オブジェクトとして表される仮想フォルダの直接操作にユーザが実行することができる定義済みアクションを備える。ブロック８８４では、ユーザは、定義済みアクションを実行する。上述のように、この一実施例は、ユーザが仮想フォルダをクリック＆ドラッグして、その内容を他の仮想フォルダにコピーすることであってもよいであろう。ブロック８８６では、仮想フォルダおよび／または内容は、ユーザにより実行されるアクションで指示された通りに操作される。

図２０は、新しい「ＷｅｓｔＣｏａｓｔ」スタック６５６が図１０のスタックに追加された画面表示を例示する図である。「ＷｅｓｔＣｏａｓｔ」スタック６５６は、「ＷｅｓｔＣｏａｓｔ」の新しいカテゴリを作成するユーザにより形成された。最初の作成の後、新しい「ＷｅｓｔＣｏａｓｔ」スタック６５６は、空であり、アイテムの個数は０である。図２０の実施形態では、２つのアイテムが「ＷｅｓｔＣｏａｓｔ」スタック６５６に追加されている。アイテムをスタックに追加する一方法では、特定のアイテムを選択し、図２０の実施形態で実行されたようにカテゴリ「ＷｅｓｔＣｏａｓｔ」を２つのアイテムに追加するなど、追加のカテゴリを修正するか、またはそのアイテムのカテゴリメタデータに追加する。このプロセスは、カテゴリデータが、あるタイプのアドホックプロパティであるアイテムに対するメタデータプロパティであることを例示している。つまり、このタイプのプロパティは、暗黙の意味を持たず、ユーザが任意の値を割り当てることができる。例えば、カテゴリ「ｐｒｏｐｅｒｔｙ」は、任意の値を取りうるが、「ａｕｔｈｏｒ」プロパティは、人の名前でなければならない。図２１を参照しつつ以下でさらに詳しく説明するように、アイテムは、クリック＆ドラッグで、他のスタックから「ＷｅｓｔＣｏａｓｔ」スタック６５６にコピーすることもできる（この場合、アイテムのカテゴリは、「ＷｅｓｔＣｏａｓｔ」を含むように自動的に更新される）。この点に関して、図２０は、選択ボックスＳＢが、その内容のコピーに備えて、「ＡＢＣＣｏｒｐ．」スタック６５１の周りにあることを示している。

図２１は、「ＡＢＣＣｏｒｐ．」スタック６５１からファイルを「ＷｅｓｔＣｏａｓｔ」スタック６５６にコピーするために直接操作が使用されている画面表示を例示する図である。つまり、図２０に示されているように、ユーザは「ＡＢＣＣｏｒｐ．」スタック６５１を選択し、次いで、図２１に示されているように、ユーザは、スタックをクリック＆ドラッグして「ＷｅｓｔＣｏａｓｔ」スタック６５６にコピーしたということである。こうして、図２０で２つのアイテムを持っていた「ＷｅｓｔＣｏａｓｔ」スタック６５６は、現在は、「ＡＢＣＣｏｒｐ．」スタック６５１からのさらに８個のアイテムを含む、合計１０個のアイテムを含むことが示されている。「ＡＢＣＣｏｒｐ．」スタック６５１からのアイテムが「ＷｅｓｔＣｏａｓｔ」スタック６５６にコピーされた場合、これは、８個のアイテムのカテゴリ記述を修正し、元の「ＡＢＣＣｏｒｐ．」カテゴリを含むことに加えて、「ＷｅｓｔＣｏａｓｔ」カテゴリも含むように修正することにより実行された。これは、実行できるある種の直接操作を例示している。

直接操作の他の実施例は、アイテムを右クリックして、削除を選択することである。一実施形態では、ユーザにより削除機能が選択された場合、アイテムをすべていっしょに削除するか、または単純に現在の仮想フォルダから削除するだけかをユーザに問い合わせる。上述のように現在の仮想フォルダカテゴリスタックからアイテムを削除するだけの場合、これは、そのアイテムについてメタデータから所望のカテゴリを削除することにより行うことができる。つまり、「ＡＢＣＣｏｒｐ．」スタック６５１から「ＷｅｓｔＣｏａｓｔ」スタック６５６にコピーされたアイテムの１つが次いで「ＷｅｓｔＣｏａｓｔ」スタック６５６から削除されるのであれば、これは、もはや「ＷｅｓｔＣｏａｓｔ」カテゴリを含むことのないように特定のファイルに対するカテゴリデータを修正することにより行うことが可能であるということである。

図２２は、システムが新しいフィルタ条件を動的に生成するためのルーチン９００を例示する流れ図である。フィルタ条件は、仮想フォルダの操作に使用される。フィルタ処理条件は、本質的に、一組のアイテムを絞り込むための一組のツールとして使用される。一実施形態では、フィルタは、メタデータカテゴリとその値とからなる（クリック可能なリンクまたはドロップダウンメニューとしてユーザインターフェース内でユーザに対し示される）。このような例示的な実施形態は、以下の図１４１および１４２を参照して説明する。ユーザは、フィルタ条件をクリックして、ディスプレイ上のアイテムの現在の結果セットを絞り込む。

図２２は、フィルタを動的に生成する方法を例示している。図２２に示されているように、ブロック９０２では、現在のディスプレイに表示されているコレクション内のアイテムのプロパティ（メタデータからの）がレビューされる。ブロック９０４では、提案されたフィルタ条件が、ディスプレイ内のアイテムの共通プロパティに基づいて動的に生成される。ブロック９０６で、提案されたフィルタ条件がユーザに対し表示され、それにより、アイテムをフィルタ処理するための選択を行うことが可能になる。このプロセスの一実施例として、システムでは、一組のアイテムのプロパティを調べて、アイテムが一般的に「ａｕｔｈｏｒｓ」をプロパティとして持つ場合、フィルタはフィルタ処理の条件となる作成者の一覧を表示することができる。次いで、特定のＡｕｔｈｏｒをクリックすることにより、Ａｕｔｈｏｒを持たないアイテムがディスプレイ上のその集まりから削除される。このフィルタ処理プロセスは、ユーザにとって、ディスプレイ上のアイテムの集まりを絞り込むためのメカニズムとなる。

図２３は、システムがフィルタ条件の選択に基づいてアイテムをフィルタ処理するためのルーチン９２０を例示する流れ図である。ブロック９２２で、ユーザは、新しいフィルタ条件を入力するか、さもなければ、システムにより提示されているフィルタ条件のうちの１つを選択する。上述のように、フィルタ条件は、システムにより動的に生成されるか、またはプリセットしておくことができる。ブロック９２４では、ディスプレイ上に表示されているコレクションからのアイテムは、選択されたプロパティがフィルタ条件に一致するかどうかに関して評価される。例えば、そのフィルタ条件が「Ｂｏｂ」が作成者であったアイテムに対するものである場合、アイテムは、その作成者プロパティが「Ｂｏｂ」を含むかどうかに応じて評価される。ブロック９２６で、選択されたプロパティがフィルタ条件に一致しないアイテムは、ディスプレイ上に表示されているコレクションから削除される。

図２４〜２９は、フィルタ処理プロセスが画面表示にどのように現れるかを一般的に例示している。図２４〜２９を参照しつつ以下で説明するように、一実施形態では、フィルタ処理は、一般に、以下のプロセスに従って動作しうる。ユーザがフィルタ値をクリックした後、フィルタ範囲を外れているアイテムは、アニメーション表示で画面から去って行く。アニメーションは、一般に、アイテムが削除されつつあること、および追加される新しいアイテムがないことを明らかにするようにデザインされる。戻るボタン６４３がユーザによって選択されると、フィルタオペレーションの結果が元に戻される。一実施形態では、順次フィルタアクションを含むナビゲーションスタックが作成され、戻るボタン６４３が選択されたときにフィルタアクションのそれぞれを元に戻すために使用される。フィルタ値が選択される毎に、現在のフィルタ値を示すように情報領域６４０およびアドレスバー６４１が更新される。一実施形態では、フィルタ値が選択された後、図３０に関して以下でさらに詳しく説明するように現在のフィルタナビゲーションへの新しいクイックリンクを保存する、または自動リストを作成するオプションがユーザに与えられる。フィルタ値が選択されると、ビュー内に残っているアイテムに適切なものとなるようにフィルタコントロールを更新できる。

図２４は、図１０のスタックが条件「ＡＢ」によりフィルタ処理された画面表示を例示する図である。図に示されているように、フィルタ領域６２１では、条件「ＡＢ」が、ユーザによって入力された。情報行６４０およびアドレスバー６４１は、ディスプレイ内のアイテムが現在、条件「ＡＢ」によりフィルタ処理されたアイテムであることを示す。図に示されているように、「ＡＢＣＣｏｒｐ．」スタック６５１は、それでも、８個のアイテムを含んでいるが、「Ｂａｃｋｕｐｓ」スタック６５２は、現在、３個のアイテムを含み、「ＸＹＺＣｏｒｐ．」スタック６５４も、３個のアイテムを含む。そのため、情報行６４４は、合計３５ＭＢのメモリを占有する合計１４個のアイテムがあることを示している。

図２５は、図１０のスタックが条件「ＡＢＣ」によりフィルタ処理された画面表示を例示する図である。図２４のフィルタ条件「ＡＢ」に関しては、ユーザはただ単に、追加の文字「Ｃ」を入力して、完全なフィルタ条件「ＡＢＣ」にするだけである。図２５に示されているように、情報行６４０およびアドレスバー６４１は、現在、ディスプレイ上のアイテムが、条件「ＡＢＣ」を含むアイテムであることを示す。「ＡＢＣＣｏｒｐ．」スタック６５１は、それでも、８個のアイテムを含むように示されているが、「Ｂａｃｋｕｐｓ」スタック６５２は、現在、アイテムを２個のみ含んでいる。「ＸＹＺＣｏｒｐ．」スタック６５４は、その内容がどれも「ＡＢＣ」フィルタと一致していないため消えてしまった。そこで、情報行６４４は、合計２５ＭＢのメモリを占有する合計１０個のアイテムがディスプレイ上のスタック内にあることを示している。図２４および２５は、したがって、ユーザが新しいフィルタ条件を入力する実施例およびディスプレイ上に表示されるアイテムをフィルタ処理するためにそれらのフィルタ条件が使用される実施例を示している。

戻るボタン６４３は、フィルタ処理プロセスを逆に辿るためにユーザが使用することができる。図１０に関して上述されているように、戻るボタン６４３を使用すると、ユーザは、ナビゲーションを遡ることができる。図２４および２５のいくつかの実施例に関して、図２５の条件「ＡＢＣ」によるフィルタ処理の後、ユーザは、戻るボタン６４３を選択することにより、フィルタ処理プロセスを１ステップ遡ることが可能であり、図２４の状態に戻る。それとは別に、他の実施形態では、戻るボタン６４３は、全フィルタ条件を消去することができ、そのため、フィルタ処理が実行される前の状態に戻ることができる。この場合、図２５の戻るボタン６４３を押すと、ユーザは図１０の状態に戻ることになる。

一実施形態では、戻るボタンに加えて、ユーザがフィルタ処理ナビゲーションを遡る、または他の何らかの手段で修正するための追加の手段が用意されている。この追加の手段は、ユーザがアドレスバー６４１に直接アクセスして修正できるようにすることを伴い、その修正により、フィルタナビゲーションが変更される。つまり、アドレスバー６４１に直接アクセスして修正することにより、ユーザは、適用されるフィルタのうちの１つまたは複数を削除するか、または適用されるフィルタのどれかに対する値を修正することができる。この機能は、参照により本明細書に組み込まれている、同一出願人による、２００３年４月１７日に出願した米国仮特許出願第１０／４２０，０４０号でさらに詳細に説明されている。

図２４および２５に示されているようなフィルタ条件をユーザが入力することに関連してタイマーも使用することができる。タイマーは、ユーザによる入力の休止を監視するために使用される。選択された無入力間隔の経過後、フィルタが適用される。例えば、図２４の状態において、ユーザは、フィルタ条件「ＡＢ」をすでに入力しており、「Ａ」と「Ｂ」との間に著しい時間的遅れはない。条件「ＡＢ」を入力した後、ユーザは休止し、図２４に示されている状態とし、そこでフィルタ条件「ＡＢ」が適用される。少ししてから、ユーザが文字「Ｃ」を追加して、フィルタ条件「ＡＢＣ」を完成し、次いで、再び休止し、その時点で、フィルタ条件「ＡＢＣ」が図２５に例示されているように適用される。

一実施形態では、ユーザがフィルタ領域６２１にフィルタ条件を入力し、次いで他のフィルタまたはナビゲーションを選択した後、ナビゲーション状態が更新され、フィルタ領域６２１内のフィルタ条件は再び空にされる。それに加えて、図２６〜２９を参照しつつ以下でさらに詳しく説明するように、他のフィルタコントロールは、いくつかのフィルタ条件の選択に基づいて更新することができる。

図２６は、システム側で用意したフィルタ条件「ｙｅａｒ２００２」が選択された画面表示を例示する図である。上記のように、「ｂｙｄａｔｅ」インジケータ６２２の下で、年選択６２３は２０００年、２００１年、または２００２年を含んでいる。選択ボックスＳＢは、２００２年の周りにあるように示されており、これは、ユーザがそれを所望のフィルタ条件として選択していることを示している。

図２７は、フィルタ条件「２００２」が適用された画面表示を例示する図である。さらに示されているのは、「ｐｉｃｋａｍｏｎｔｈ」セレクタ６２３Ａの他の選択である。図２７に示されているように、フィルタ条件「２００２」を適用した後に、スタック内のアイテムの個数が減らされる。より具体的には、「ＡＢＣＣｏｒｐ．」スタック６５１は、現在、６個のアイテムを含んでおり、「Ｂａｃｋｕｐｓ」スタック６５２は、現在、８個のアイテムを含んでおり、「ＢｕｓｉｎｅｓｓＰｌａｎｓ」スタック６５３は、現在３個のアイテムを含んでおり、「ＸＹＺＣｏｒｐ．」スタック６５４は、現在、５個のアイテムを含んでいる。情報行６４４は、現在、合計５０ＭＢのメモリを占有する合計２２個のアイテムがあることを示している。情報行６４０およびアドレスバー６４１は、現在、ディスプレイ上に表示されているアイテムが、フィルタ条件「２００２」を含むようにフィルタ処理されたアイテムであることを示す。

図２８は、フィルタ処理対象の月を選択するにあたって一覧が表示されている画面表示を例示する図である。月の一覧を含むボックス９５０が用意される。ユーザが「ｐｉｃｋａｍｏｎｔｈ」セレクタ６２３Ａを選択したことにより、ボックス９５０がディスプレイ上に表示されている。選択ボックスＳＢは、「Ｊａｎｕａｒｙ」の月名の周りにあるように示されている。

図２９は、図２８のスタックが、１月でフィルタ処理され、さらにフィルタ条件「ｄａｙ」を示すことによりフィルタ処理されている画面表示を例示する図である。図２９に示されているように、情報行６４０およびアドレスバー６４１は、現在、ディスプレイ上のアイテムが、条件「Ｊａｎｕａｒｙ」によりフィルタ処理されたアイテムであることを示す。「Ｂａｃｋｕｐｓ」スタック６５２は、現在、２つのアイテムを含むように示されているが、「ＢｕｓｉｎｅｓｓＰｌａｎｓ」スタック６５３も、２つのアイテムを含むように示されている。情報行６４４は、合計１０ＭＢのメモリを占有する合計４個のアイテムがディスプレイ上に表示されていることを示している。ユーザがさらに特定の日で結果をフィルタ処理したい場合には、「ｐｉｃｋａｄａｙ」セレクタ６２３Ｂが用意される。日付または日付の範囲が選択できる例示的なカレンダーコントロール１４４００が、図１４４に示されている。

図２４〜２９に関して上で説明されているように、フィルタ条件は、システムにより提示されるか、またはユーザ側で入力することができる。フィルタ条件が選択されると、提示される残りのフィルタ条件は更新することができる（例えば、図２６で年「２００２」が選択された後、図２７において、年を選択するオプションは、もはや提示されず、その代わりに、「ｐｉｃｋａｍｏｎｔｈ」オプションが与えられる）。上記のように、戻るボタン６４３は、フィルタ処理プロセスを遡るためにユーザが選択することができる。例えば、図２９で月「Ｊａｎｕａｒｙ」が選択された後、ユーザは、図２７に例示されているように、戻るボタン６４３を選択して、フィルタ処理プロセスを年「２００２」に戻すことができる。フィルタメニューは、さらに、「ｓｔａｃｋｂｙ」機能を備えることもでき、これは、図１５および１６に関して上で説明されている「ｓｔａｃｋｂｙ」機能と同様に動作する。例えば、「ｆｉｌｅｔｙｐｅ」フィルタは、「Ｅｘｃｅｌ」、「ＰｏｗｅｒＰｏｉｎｔ」、「Ｗｏｒｄ」、およびさらに「Ｓｔａｃｋｂｙｆｉｌｅｔｙｐｅ」に対する選択肢を持つことが可能である。「ｓｔａｃｋｂｙ」機能を選択すると、ビューは様々なファイルタイプに対するスタックを表示するように切り替わる。

一般に、フィルタは、ファイルまたはアイテムの異なる特性に適用されるように構成することができる。一実施形態では、フィルタは、アルファベットのインデックス、離散値、日付、および数値範囲などの異なるタイプに応じて分類することができる。アルファベットのインデックスに対する例示的なプロパティは、「ｆｉｌｅｎａｍｅ」、「ａｕｔｈｏｒ」、「ａｒｔｉｓｔ」、「ｃｏｎｔａｃｔｆｒｉｅｎｄｌｙｎａｍｅ」、「ｏｗｎｅｒ」、「ｄｏｃｕｍｅｎｔａｕｔｈｏｒ」、「ｄｏｃｕｍｅｎｔｔｉｔｌｅ」、「ｄｏｃｕｍｅｎｔｓｕｂｊｅｃｔ」、および「ｄｅｓｃｒｉｐｔｉｏｎ」を含むことができる。これらの離散値に対する例示的なプロパティは、「ｌｏｃａｔｉｏｎ」、「ｆｉｌｅｔｙｐｅ」（アプリケーション名）、「ｇｅｎｒｅ」、「ｔｒａｃｋ」、「ｄｅｃａｄｅ」（音楽の）、「ｒａｔｉｎｇ」（音楽の）、「ｂｉｔｒａｔｅ」、「ｐｒｏｔｅｃｔｅｄ」、「ｄｏｃｕｍｅｎｔｃａｔｅｇｏｒｙ」、「ｄｏｃｕｍｅｎｔｐａｇｅｃｏｕｎｔ」、「ｄｏｃｕｍｅｎｔｃｏｍｍｅｎｔｓ」、「ｃａｍｅｒａｍｏｄｅｌ」、「ｄｉｍｅｎｓｉｏｎｓ」、「ｐｒｏｄｕｃｔｎａｍｅ」、「ｐｒｏｄｕｃｔｖｅｒｓｉｏｎ」、「ｉｍａｇｅＸ」、「ｉｍａｇｅＹ」、「ｄｏｃｕｍｅｎｔｃｒｅａｔｅｄｔｉｍｅ」を含むことができる。日付に対する例示的なプロパティは、「ｌａｓｔａｃｃｅｓｓｅｄ」、「ｌａｓｔｍｏｄｉｆｉｅｄ」、「ｃｒｅａｔｅｄｏｎ」、「ｔａｋｅｎｏｎ」（画像の）を含むことができる。数値範囲に対する例示的なプロパティは、「ｆｉｌｅｓｉｚｅ」であってよい。

ユーザは、図２４〜２９に関して上で説明されているフィルタを使用することで、注目する特定のアイテムを見つけるためにアイテムの一覧を絞り込むことができることは理解されるであろう。具体的な実施例として、上述のプロセスにより、ユーザは、特定の人が作成者であり、先週編集された、ＭｉｃｒｏｓｏｆｔＷｏｒｄファイルのみを表示するようにドキュメントの現在の一覧を絞り込むことが可能である。この機能は、ユーザが多数のアイテムの一覧内で特定のアイテムを見つけることを可能にし、ユーザが一覧内のそれぞれのアイテムを手動でスキャンしなくて済む。

図３０は、新しいクイックリンクを作成するためのルーチン９４０を例示する流れ図である。以下でさらに詳しく説明するように、クイックリンクは、アイテムの集合のユーザ選択ビューを作成するためにユーザがクリックすることができる定義済みリンクである。一実施形態では、クイックリンクは、一種のピボットと考えられる。クイックリンクは、仮想フォルダを検索するためのメカニズムを実現する。クイックリンクをクリックすることで、ユーザは所望のフォルダへ移動することができる（ユーザが「ｆａｖｏｒｉｔｅｓ」をクリックしてＷｅｂサイトへ移動するのと同じようにして）。クイックリンクは、システムにより予め定義しておくか、またはユーザ側で設定することができる。例えば、「ａｌｌａｕｔｈｏｒｓ」をクリックすると、作成者によりスタッキングされたビューに戻ることが可能である。「ａｌｌｄｏｃｕｍｅｎｔｓ」をクリックすると、すべての記憶域に対しすべてのドキュメントのフラットビューが返される。ユーザは、自分だけのクイックリンクを作成することもできる。

図３０に示されているように、ブロック９４２で、ユーザは、ディスプレイ上で選択を行い、現在のフィルタ条件またはナビゲーションから新しいクイックリンクを形成すべきであることを指示する。ブロック９４４で、ユーザは、新しいクイックリンクに新しい名前を付ける。ブロック９４６で、その新しいクイックリンクが保存され、新しいクイックリンク名が、ディスプレイ上のクイックリンクセクションに表示される。

図３１は、図２９のフィルタ処理に基づいて新しい「ＪａｎｕａｒｙＷｏｒｋ」という名前の新しいクイックリンクを作成する画面表示を例示する図である。上述のように、図２９では、スタックは、「Ｊａｎｕａｒｙ」の月でフィルタ処理されている。図３１では、ユーザは、図２９のフィルタ処理を新しいクイックリンクとして保存すべきであることを指示しており、新しいクイックリンクに「Ｊａｎｕａｒｙｗｏｒｋ」という名前を付けている。そのため、新しい「Ｊａｎｕａｒｙｗｏｒｋ」クイックリンク６１２は、ディスプレイのクイックリンク内に示される。新しいクイックリンクを形成するにあたって、ユーザは、一般に、「ｓａｖｅｔｈｉｓｃｏｌｌｅｃｔｉｏｎａｓａｑｕｉｃｋｌｉｎｋ」などのオプションを与えられる。

図３２は、「ＡｌｌＡｕｔｈｏｒｓ」のクイックリンクが選択されている画面表示を例示する図である。図３２に示されているように、選択ボックスＳＢは、「ＡｌｌＡｕｔｈｏｒｓ」選択６１１の周りに表示される。クイックリンクによりアクセス可能なコレクションの他の実施例には、「ａｌｌａｕｔｈｏｒｓ」、「ｒｅｃｅｎｔｄｏｃｕｍｅｎｔｓ」、「ａｌｌｄｏｃｕｍｅｎｔｓＩ’ｖｅｓｈａｒｅｄ」、「ａｌｌｄｏｃｕｍｅｎｔｓＩ’ｖｅａｕｔｈｏｒｅｄ」、「ａｌｌｄｏｃｕｍｅｎｔｓｎｏｔａｕｔｈｏｒｅｄｂｙｍｅ」、「ｄｅｓｋｔｏｐ」、および「ａｌｌｔｙｐｅｓ」がある。

図３３は、図３２のアイテムの全作成者の一覧が表示されている画面表示を例示する図である。図３３に示されているように、情報行９５０が用意され、そこに、アイテムの名前、作成者、修正日、タイプ、サイズ、およびアイテムの場所を示すカラムが表示される。Ａｕｔｈｏｒ９５１〜９５４の一覧が示され、これらはそれぞれ、Ａｕｔｈｏｒ１〜４に対応する。

図３４は、「Ａｕｔｈｏｒ１」が図３３の一覧から選択されている画面表示を例示する図である。Ａｕｔｈｏｒ１のドキュメントは、ドキュメント９５１Ａおよび９５１Ｂを含み、それぞれドキュメント１および２に対応する。ドキュメント９５１Ａは、Ａｕｔｈｏｒ１を作成者とすることが示されており、２００１年７月１１日に修正され、ＭｉｃｒｏｓｏｆｔＥｘｃｅｌファイルであり、２８２Ｋｂのメモリを占有し、＼＼ｓｅｒｖｅｒ１＼ｆｏｌｄｅｒ２の場所から取得された。ドキュメント９５１Ｂは、Ａｕｔｈｏｒ１を作成者とすることが示されており、２００２年１２月２２日に修正され、ＭｉｃｒｏｓｏｆｔＷｏｒｄファイルであり、２０６Ｋｂのメモリを占有し、ＭｙＤｏｃｕｍｅｎｔｓ＼ｆｏｌｄｅｒ１の場所に物理的に格納されている。ドキュメント９５１Ａおよび９５１Ｂの場所も、以下でさらに詳しく説明するように、本発明の仮想フォルダが、異なる物理的な場所からのアイテムを含むことができることを示している。

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

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

図３７は、仮想フォルダコレクションまたは自動リストコレクションのスコープを定義するルーチン９９０を例示する流れ図である。以下でさらに詳しく説明するように、仮想フォルダシステムは、ユーザからすべてのアイテムに容易にアクセス可能なように複数の物理的な場所（例えば、異なるハードドライブ、異なるコンピュータ、異なるネットワークロケーションなど）から複数のアイテムを表現することができる。例えば、ユーザは、単一ディスプレイ上で複数の物理的な場所からの音楽ファイルを与えられ、それらのファイルをすべて一度に操作することができる。

図３７に示されているように、ブロック９９２では、アイテムが引き出される物理的な場所に対しスコープが定義される。ブロック９９４で、クエリに対する応答として、スコープで定義されているような物理的な場所からアイテムが引き出される。ブロック９９６で、クエリにより引き出されたすべてのアイテムが単一表示で表示される。

図３８は、仮想フォルダコレクションのスコープを形成しうる様々なソースを例示するブロック図である。図３８に示されているように、システム１０００は、現在のコンピュータ１０１０、追加のコンピュータ１０２０、外付けおよび取り外し可能記憶装置１０３０、およびネットワーク上の場所１０４０を含むことができる。スコープ１００１全体は、コレクションを作成するためにユーザのアイテムが引き出される物理的な場所すべてを含むように記述される。スコープは、ユーザによる設定および修正が可能である。上述のように、他の図では、異なるドキュメントがサーバーと現在のコンピュータ上のＭｙＤｏｃｕｍｅｎｔｓフォルダからのものであることを示す図３４および複数の場所に物理的に配置されている物理フォルダを示す図１８などのように、アイテムが異なる物理的な場所に由来しうるものとして例示している。

図３９は、仮想フォルダコレクション内に非ファイルアイテムを含めるためのルーチン１０８０を例示する流れ図である。非ファイルアイテムは、物理的ファイル記憶装置に典型的に配置されているファイルアイテムと対比される。非ファイルアイテムの例としては、電子メールおよび連絡先などがある。図３９に示されているように、ブロック１０８２では、データベースを使用して、クエリにより検索されうるファイルアイテムとともに非ファイルアイテムを含める。ブロック１０８４で、クエリに対する応答として、クエリに一致する非ファイルアイテムとファイルアイテムの両方が引き出される。ブロック１０８６で、クエリに一致した非ファイルアイテムとファイルアイテムが両方ともディスプレイ上に表示される。

図４０は、様々な非ファイルアイテムを示す画面表示を例示する図である。図４０に示されているように、複数のアイテムがフィルタ処理され「Ｊｏｈｎ」を含むものに絞られている。これらのアイテムは、連絡先アイテム１１０１、電子メールアイテム１１０２、およびドキュメントアイテム１１０３および１１０４を含むことが示されている。連絡先アイテム１１０１および電子メールアイテム１１０２は非ファイルアイテムである。本発明のシステムでは、このような非ファイルアイテムを通常のファイルアイテムとともに含めることができ、そのため、ユーザの望む通りに編成し、操作することができる。図２に関して上で説明されたように、このような非ファイルは、他の何らかの方法でファイルのプロパティに関する情報を含むリレーショナルデータベース２３０に完全に格納することができる。

本発明の他の態様では、異なる種類のフィルタコントロールが実装されているグラフィカルユーザインターフェースが実現される。この態様によれば、複数のアイテムに共有されるプロパティに対応するメタデータプロパティコントロールは、リストビューモードで与えられる。上記の説明は、該当する限り、また具体的に参照しなくても、以下の説明に当てはまることは理解されるであろう。

ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎ（ワシントン州レドモンド）のＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）ＸＰブランドのオペレーティングシステムでは、ユーザは、ツリー構造で現在識別されているフォルダおよびファイルの一覧をディスプレイに表示する異なるビューを与えられる。これらのビューは、詳細ビュー、アイコンビュー、サムネイルビュー、リストビュー、およびタイルビューを含む。これらのビューで識別されるオブジェクトは、多数の異なるメタデータプロパティにより並べ替えたり、グループ化することができる。図１４０は、Ｗｉｎｄｏｗｓ（登録商標）ＸＰブランドのオペレーティングシステムにおける詳細ビューの例示的なスクリーンショットを示している。詳細ビューでは、それぞれの行は、特定の１つのオブジェクトに対応し、それぞれの列は、オブジェクトの特定のプロパティに対応している。プロパティは、所望の順序で一覧表示することができる。この実施例では、左から右へ識別されているプロパティは、Ｎａｍｅ、Ｓｉｚｅ、ＤａｔｅＭｏｄｉｆｉｅｄ、ＤａｔｅＣｒｅａｔｅｄ、ＤａｔｅＡｃｃｅｓｓｅｄ、Ａｕｔｈｏｒ、およびＴｙｐｅを含む。オブジェクトおよびその関連する情報は、Ｔｙｐｅ−ＨＴＭＬドキュメントおよびＭｉｃｒｏｓｏｆｔＷｏｒｄドキュメント−に応じて２つの別々のグループに分けられている。「ＳｈｏｗｉｎＧｒｏｕｐｓ」コマンドは、画面の一番上にある「Ｖｉｅｗ」ドロップダウンメニューを介して、「ＡｒｒａｎｇｅＩｃｏｎｓＢｙ」ドロップダウンメニューにドリルダウンすることによりアクセス可能である。ａｕｔｈｏｒなどのプロパティを選択すると、ａｕｔｈｏｒによりオブジェクトのグループ化がやり直される。グループ化がアクティブ化されていなかった場合、プロパティを選択すると、選択されたプロパティによりオブジェクトの並べ替えが行われる。

本発明のいくつかの態様は、Ｗｉｎｄｏｗｓ（登録商標）ＸＰブランドのオペレーティングシステムのユーザインターフェースのコア機能に一部に基づいて構築される。本発明のいくつかの態様では、複数のアイテムにより共有されるプロパティを使用してユーザがビューのフィルタ処理を行うことができる「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」コントロールを備える。ユーザは、いくつかの態様におけるフィルタコントロールを使用することで、例えば、図２４にすでに示されているアドレスバー６４１などのアドレスバーからフィルタ条件の追加、変更、または削除を容易に行うことができる。フィルタコントロールを適用する一実装では、ユーザは、単一プロパティの複数の値を「ＯＲｉｎｇ」する離接により表示オブジェクトのビューをフィルタ処理することができる（例えば、ａｕｔｈｏｒ＝「Ｂｉｌｌ」または「Ｂｏｂ」）。フィルタコントロールを適用する他の態様では、ユーザは、プロパティにより表示オブジェクトのビューの並べ替え、グループ化、またはスタッキングを行うことができる。

本発明のいくつかの態様によれば、プロパティヘッダは、ビューモードのそれぞれにおけるリストビューの最上部にそって一組のラベルとして出現する。このビューモードは、アイコンビュー、詳細ビュー、リストビュー、タイルビュー、およびサムネイルビューを含む物理ファイルまたは仮想ファイルの任意のビューを含むことができる。プロパティヘッダ内のプロパティのそれぞれは、プロパティコントロールとして機能し、関連付けられているコントロール機能にアクセスするためにプロパティコントロールをクリックする、などのユーザ選択により呼び出すことができる。ユーザが利用することができるプロパティは多数ありうる。そのようなものとして、ユーザに最も役立つプロパティの関連する部分集合を表示することは実用的であると考えられる。この点に関して、表示ヘッダに表示されるプロパティの集合は、ユーザによりカスタマイズ可能であるか、既定のテンプレートの一部とすることができるか、またはアドレスバー上のクエリの機能とすることができる。表示されるプロパティの集合を選択する一方法は、個々のシェルフォルダ（つまり、ページ）に基づいており、それぞれの仮想フォルダ（自動リスト）、リスト、ファイルフォルダなどについて、プロパティの集合を既定でカスタマイズ可能である。例えば、最近表示されたすべてのドキュメントを示す「ＲｅｃｅｎｔＤｏｃｕｍｅｎｔｓ」という名前の仮想フォルダに対し、「ＤａｔｅＬａｓｔＡｃｃｅｓｓｅｄ」プロパティが有用であるが、他の仮想フォルダでは、これは有用ではない場合がある。また、プロパティは、プロパティヘッダ内で順序を変更するか、または例えば、ドラッグ＆ドロップにより削除することができる。

図１４１Ａは、本発明の例示的な実装による詳細ビューのプロパティヘッダ１４１００を示しており、図１４２Ａは、タイルビューまたはサムネイルビューなどの他のリストビューモードのプロパティヘッダ１４２００を示している。図からわかるように、図１４１Ａおよび１４２Ａのプロパティヘッダの主な違いは、詳細ビュー内のヘッダ１４１００の個々のプロパティコントロールは詳細ビュー内の列サイズに合わせてマップされるが、ヘッダ１４２００内の個々のプロパティコントロールはプロパティ名を収めるのに必要な領域のみを占有するという点である。プロパティヘッダの下に、表示オブジェクト（例えば、物理ファイルおよびフォルダ、仮想ファイルおよびフォルダ）が表示されるリストビューモード（図に示されていない）の一領域がある。

それぞれのヘッダ内のそれぞれのプロパティコントロールは、図１４１Ｂの詳細ビューおよび図１４２Ｂの他のリストビューモードに示されているように主要部１４１１０および分割部分１４１１２に分けられる分割ボタンを備えることができる。分割ボタン状態は、カーソル１４１２０をプロパティコントロールの一部の上に、またはプロパティヘッダ１４１００内に配置するとユーザから見えるようにするか、またはプロパティコントロールが最初に表示されるときに見えるようにすることができる。

カーソル１４１２０をプロパティコントロールの主要部１４１１０の上に配置し、選択（例えば、クリック）すると、表示オブジェクトは、プロパティコントロールに関連するプロパティに従って並べ替えられる。図１４１Ｂに示されている実施例では、プロパティは、「Ｔｙｐｅ」であり、プロパティコントロールの主要部１４１１０を選択すると、表示オブジェクトは、アルファベット順に並べ替えられる。それとは別に、すべての物理フォルダ、その後にすべてのＭｉｃｒｏｓｏｆｔＥｘｃｅｌドキュメント、その後にすべてのＭｉｃｒｏｓｏｆｔＰｏｗｅｒＰｏｉｎｔドキュメント、その後にすべてのＭｉｃｒｏｓｏｆｔＷｏｒｄドキュメント、その後にすべての仮想フォルダ（自動リスト）などを表示することができる。表示オブジェクトがプロパティにより並べ替えられる場合、プロパティコントロールは、表示オブジェクトがプロパティにより並べ替えられたことを視覚的に示すことができる。例えば、プロパティコントロールは、他のプロパティコントロールから区別できる押下されたボタンのような視覚的外観または他の外観を示すことができる。「Ｔｙｐｅ」で並べ替える前に、表示オブジェクトが「Ｄａｔｅ」などの他のプロパティにより並べ替えられた場合、そのプロパティは、２番目の並べ替え条件となり、ドキュメントタイプの範囲内で表示オブジェクトは日付により２番目に並べ替えられる。

図１４１Ｃおよび１４２Ｂに示されているように、カーソル１４１２０をプロパティコントロールの分割部分１４１１２の上に配置し、選択すると、プロパティコントロールに対応するプロパティの「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューが表示される。「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューは、ユーザがプロパティコントロールに対応するプロパティにより表示オブジェクトのビューのグループ化、スタッキング、またはフィルタ処理を行うために使用できる様々なコントロールを備えている。「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューは、整列コマンドの一覧を含む整列部分１４１３０およびフィルタ条件の一覧を含むフィルタ部分１４１３５を備える。２つの一覧は、図１４１Ｃおよび１４２Ｂに示されているように視覚的仕切りにより分離することができる。

図１４１Ｃおよび１４２Ｂの実施例では、フィルタ条件は、アイテムの「Ｔｙｐｅ」プロパティに対応する。フィルタ部分１４１３５で与えられる特定のフィルタの集合は、ビュー内の少なくとも１つのアイテムがフィルタ条件を満たす可能なフィルタ条件の部分集合である。例えば、ビュー内の表示オブジェクトのうちの１つが「ｖａｃａｔｉｏｎ」をキーワードとして持つ写真であった場合、「ｖａｃａｔｉｏｎ」は、キーワードプロパティに対応するキーワードプロパティコントロールに対する「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニュー内に出現する。すべてのフィルタ条件が「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューに収まるわけではないことは理解されるであろう。図１４１Ｃおよび１４２Ｂに示されているように、スクロールバーコントロールが用意され、これにより、ユーザは他の使用可能なフィルタ条件を見ることができる。ドラッグ＆ドロップなどのオペレーションによりアイテムをビュー内に入れたり出したりできることは理解されるであろう。アイテムがビューに追加またはビューから削除される毎に、フィルタ部分１４１３５内に用意される特定のフィルタの集合は、追加または削除されたアイテムを説明するものとなるように更新される。

フィルタ条件は、プリセットされるか、またはプロパティコントロールおよびビュー内に表示されるアイテムに対応するプロパティの評価に基づいて動的に生成することができる。上述の図２２およびその随伴する説明は、新しいフィルタ条件を動的に生成するための例示的ルーチンを示している。可能なフィルタの集合およびその表示順序は、特定のプロパティによりアイテムがどのように分類されるかによって決まる。キーワークなどの多値プロパティでは、それぞれの個別の値は、それ専用のバケットを持つことができる。したがって、アイテムがキーワード「ｖａｃａｔｉｏｎ；Ｈａｗａｉｉ；ｂｅａｃｈ」を持つ場合、「ｖａｃａｔｉｏｎ」に対し１つ、「Ｈａｗａｉｉ」に対し１つ、および「ｂｅａｃｈ」に対し１つ、合計３つの独立のバケットがフィルタ処理のため作成される。同じプロセスが、グループ化およびスタッキングオペレーションに適用されるが、これについては以下でさらに詳しく説明する。

プロパティ日付については、今日の日付が２００４年１１月１９日金曜であると仮定すると、日付は、ＬｏｎｇＴｉｍｅＡｇｏ、ＴｗｏＹｅａｒｓＡｇｏ、ＬａｓｔＹｅａｒ、２００４Ｊａｎｕａｒｙ、２００４Ｆｅｂｒｕａｒｙ、．．．、２００４Ａｕｇｕｓｔ、２００４Ｓｅｐｔｅｍｂｅｒ、ＬａｓｔＭｏｎｔｈ、ＴｈｒｅｅＷｅｅｋｓＡｇｏ、ＴｗｏＷｅｅｋｓＡｇｏ、ＬａｓｔＷｅｅｋ、Ｓｕｎｄａｙ、Ｍｏｎｄａｙ、Ｔｕｅｓｄａｙ、Ｗｅｄｎｅｓｄａｙ、Ｙｅｓｔｅｒｄａｙ、Ｔｏｄａｙ、Ｔｏｍｏｒｒｏｗ、ＴｗｏＤａｙｓＦｒｏｍＮｏｗ、ＬａｔｅｒＴｈｉｓＷｅｅｋ、ＬａｔｅｒＴｈｉｓＭｏｎｔｈ、ＮｅｘｔＹｅａｒ、ＳｏｍｅＦｕｔｕｒｅＤａｔｅのカテゴリに分類されうる。「Ｓｉｚｅ」および「Ｔｙｐｅ」などの他のプロパティは、Ｗｉｎｄｏｗｓ（登録商標）ＸＰブランドのオペレーティングシステムに見られるのと同じバケット化を持つことができる。

一態様によれば、日付に関係するプロパティ（例えば、ｄａｔｅｃｒｅａｔｅｄ、ｄａｔｅｍｏｄｉｆｉｅｄなど）のフィルタ部分におけるフィルタ条件の一覧は、追加のフィルタ処理オプションを含み、これは、「ＰｉｃｋａＤａｔｅ」と呼ばれるフィルタ条件の一覧の最上位に置くことができる。このフィルタ条件を選択すると、「ｃａｌｅｎｄａｒｐｉｃｋｅｒ」コントロール１４４００が表示され、そこから、ユーザは、特定の日付または日付範囲を選択することができる。図１４４００は、日付「Ａｐｒｉｌ２０」が選択されているそのようなコントロールの一実施例を示している。

Ｆｉｌｅｎａｍｅ、Ｃｏｍｍｅｎｔ、Ｄｅｓｃｒｉｐｔｉｏｎなどのいくつかのプロパティは、分割またはバケット化できない。これらのプロパティについて、グループ化、スタッキング、およびフィルタ処理の目的のために、プロパティを複数の別々のバケットに分ける有用な細分はありえない。この場合、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニュー内に表示される唯一のオプションは、「ｓｏｒｔ」だけである。

「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニュー内のそれぞれのフィルタ条件は、それぞれのフィルタ条件を満たすアイテムの個数に関する指示を与える対応するインジケータを含むことができる。図１４１Ｃおよび１４２Ｂに示されているように、アイコン１４１３８は、フィルタ条件「ＰｏｗｅｒＰｏｉｎｔ」に隣接して与えられており、用紙の束を表現している。他のフィルタ条件に隣接して配置されている他のアイコンを調べると、それらも用紙の束を表現していることがわかる。しかし。用紙の束のアイコンは、外観が変わり、また動的に生成され、アイコン内に積み重ねられている用紙の枚数は、相対的に、対応するフィルタ条件を満たすアイテムの個数を表現している。例えば、アイコン１４１３８は、フィルタ条件「ＥｍａｉｌＭｅｓｓａｇｅ」に対応するアイコンよりも多くの用紙が積み重ねられていることを示しており、これは、フィルタ条件「ＯｕｔｌｏｏｋＤｏｃｕｍｅｎｔ」に対応するアイコンよりも多くの用紙が積み重ねられていることを示している。そのため、フィルタ条件「ＰｏｗｅｒＰｏｉｎｔ」を満たすアイテムは、フィルタ条件「ＥｍａｉｌＭｅｓｓａｇｅ」を満たすアイテムよりも多く、フィルタ条件「ＥｍａｉｌＭｅｓｓａｇｅ」を満たすアイテムは、フィルタ条件「ＯｕｔｌｏｏｋＤｏｃｕｍｅｎｔ」を満たすアイテムよりも多い。

フィルタ部分１４１３５は、さらに、フィルタ条件の一覧内のそれぞれのフィルタ条件に対応するチェックボックスコントロールを含むことができる。例えば、チェックボックスコントロール１４１４０は、フィルタ条件「ＩｌｌｕｓｔｒａｔｏｒＡｒｔｗｏｒｋ」に対応する。フィルタ条件の隣のチェックボックスコントロールを選択すると、選択されたチェックボックスコントロールにチェックマークが入ることによりフィルタ条件が現在の選択に追加され、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューのフィルタ部分１４１３５内の他のフィルタ条件に対応するチェックボックスコントロールは選択または選択解除の前の状態のままである。さらに、チェックボックスコントロールを選択することで、表示オブジェクトを含む領域内にフィルタオペレーションのライブプレビューを表示することができる。そこで、チェックボックスコントロールを選択すると、ディスプレイ上に表されるアイテムは、チェックボックスコントロールに対応するフィルタ条件を満たすアイテムを含むようになる。他のチェックボックスコントロールが選択されていない場合、選択されたチェックボックスコントロールの条件を満たす表示オブジェクトのみが、ディスプレイ上に表現される。チェックボックスコントロールの選択または選択解除は、ポインティングデバイス、キーボード入力、音声入力、およびそれらの組合せを使用することを含む様々な方法により実行できることは理解されるであろう。例えば、ユーザが＜ＳＨＩＦＴ＞キーを押し下げたままにした場合、Ｗｉｎｄｏｗｓ（登録商標）ＸＰブランドのオペレーティングシステムで複数選択を実現しているのと似た方法でフィルタ条件の範囲を選択することができる。

図１４１Ｃおよび１４２Ｂを参照すると、表示領域（図に示されていない）内のそれぞれの表示オブジェクトは、例えば、図２１に関して、上で説明されているのと同様にして、アドレスバー（図に示されていない）内の現在のクエリの条件を満たす。チェックボックスコントロール１４１４０を選択することで、図１４１Ｄに示されているように、チェックボックスコントロール１４１４０はチェックされているチェックボックスコントロール１４１４０Ａとして表示され、また、フィルタ条件「ＩｌｌｕｓｔｒａｔｏｒＡｒｔｗｏｒｋ」を満たすアイテムのみがディスプレイ上に表示される。図２３で説明されているルーチンに似たルーチンは、他のチェックボックスコントロールが選択されていない場合チェックボックスコントロールの選択のために使用することができ、この場合、このシナリオのステップ９２２は、フィルタ条件の１つに対応するチェックボックスコントロールのユーザによる選択に対応する。

チェックボックスコントロールを選択した後、＜ｅｎｔｅｒ＞コマンドを選択するか、または他の何らかの方法により「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューの外でコマンドを発行する（例えば、グラフィカルユーザインターフェース上のどこかほかの場所をクリックする）ことで、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューが閉じ、現在選択されている（複数の）フィルタが適用される。また、フィルタ条件またはフィルタ条件に関連するアイコンを選択することにより、他のチェックボックスコントロールの選択が解除され、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューが閉じ、フィルタ条件が適用される。これらの場合、アドレスバー（図２４などの他の図に示されているアドレスバー６４１に類似の）が更新され、クエリ内にフィルタ条件を含むようになる。

チェックボックスコントロールが選択されている（チェックされている）場合、第２のフィルタ条件に対応する他のチェックボックスコントロールの選択により、そのフィルタ条件は現在の選択に追加される。追加のチェックボックスコントロールを選択すると、追加のチェックボックスコントロールはチェックされているチェックボックスコントロールとして表示され、またチェックされたチェックボックスコントロールに対応するフィルタ条件のそれぞれを満たすアイテムのみがディスプレイ上に表示される。図１４３を参照すると、フィルタ条件「ＰＤＦｄｏｃｕｍｅｎｔ」に対応するチェックボックスコントロールがすでに選択されている場合にフィルタ条件「ＥｘｃｅｌＷｏｒｋｓｈｅｅｔ」に対応するチェックボックスコントロールを選択することで、アドレスバー内のクエリの条件を満たし、フィルタ条件「ＥｘｃｅｌＷｏｒｋｓｈｅｅｔ」または「ＰＤＦｄｏｃｕｍｅｎｔ」のいずれかを満たすアイテムを含むように表示が更新される。したがって、本発明のこの態様によれば、それぞれがそれぞれのフィルタ条件に対応する複数のチェックボックスコントロールが単一の「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューから選択される場合に、論理ＯＲ演算が実行される。説明されているように、＜ｅｎｔｅｒ＞コマンドを選択するか、または他の何らかの方法により「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューの外でコマンドを発行することで、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューが閉じ、現在選択されているフィルタが適用される。これらの場合、アドレスバー内に表示されているクエリは、フィルタ条件の論理ＯＲによる結合を含む単一フィルタを含むように更新される。説明されている実施例では、アドレスバー内の次のセグメントに追加されるフィルタは「ＥｘｃｅｌＷｏｒｋｓｈｅｅｔ，ＰＤＦｄｏｃｕｍｅｎｔ」とすることができる。

チェックボックスコントロールを選択解除すると、チェックボックスコントロールはチェックが外されているものとして表示され、また残りのチェックされているチェックボックスコントロールに対応するフィルタ条件を満たすアイテムがディスプレイ上に表示される。「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューにおいてチェックボックスコントロールが選択されている（チェックされている）場合、それぞれのチェックされたチェックボックスは、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューの整列部分でコマンド「Ｄｏｎ’ｔｆｉｌｔｅｒｂｙ＜プロパティ名＞」を選択することによりチェックを外すことができる。図１４３を参照すると、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューの整列部分１４３３０は、コマンド「Ｄｏｎ’ｔｆｉｌｔｅｒｂｙＴｙｐｅ」を含んでおり、これを選択すると、フィルタ部分１４３３５内の選択されたチェックボックスコントロールは、選択解除され、チェックが外される。フィルタ部分に選択された（チェックされた）チェックボックスコントロールがない場合、「Ｄｏｎ’ｔｆｉｌｔｅｒｂｙ＜プロパティ＞」コマンドは無効にされ、図１４１Ｃおよび１４２Ｂの整列部分１４１３０で表されているように淡色表示になる。

ユーザが少なくとも１つのチェックボックスコントロールが選択されている場合に第１のプロパティに対応する「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューを閉じると、第１のプロパティコントロールは、ディスプレイ上の表示オブジェクトのビューがフィルタ処理されたことを示すインジケータを表示することができる。図１４２Ｃを参照すると、記号１４２５０は、プロパティ「Ｔｙｐｅ」に対応するプロパティコントロール内に表示され、表示オブジェクトのビューがプロパティ「Ｔｙｐｅ」によりフィルタ処理されたことを示している。

ユーザがプロパティヘッダから第２のプロパティコントロールを選択することによりそれぞれのフィルタ条件に対応する少なくとも１つのチェックボックスコントロールが選択されている場合に第１のプロパティに対応する「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューを閉じると、第２のプロパティコントロールに対応する「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューが与えられる。この場合、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニュー内の一組のフィルタ条件は、ビュー内の少なくとも１つのアイテムが第２のプロパティコントロールに対するフィルタ条件とともに第１のプロパティコントロールに対するフィルタ条件を満たす可能なフィルタ条件の部分集合である。また、この一組のフィルタ条件は、第１のプロパティコントロールに関連する「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューからすでに選択されているフィルタを含むことができる。例えば、ユーザが、第１のプロパティコントロール「Ｔｙｐｅ」に関連付けられた「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューからフィルタ条件「ＰｏｗｅｒＰｏｉｎｔ」に対するチェックボックスコントロールを選択し、次いで、第２のプロパティ「Ａｕｔｈｏｒ」に対する第２のプロパティコントロールを選択して、「Ａｕｔｈｏｒ」に対する「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューを表示させる場合、フィルタ条件「Ｈａｍｌｅｔ」および「Ｈｏｒａｔｉｏ」は両方とも、「Ｈａｍｌｅｔ」および「Ｈｏｒａｔｉｏ」がそれぞれ１つまたは複数の「ＰｏｗｅｒＰｏｉｎｔ」ファイルに関する作成者であれば現れる。しかし、「Ｈｏｒａｔｉｏ」が「ＰｏｗｅｒＰｏｉｎｔ」ファイルの作成者でなかった場合、「Ｈｏｒａｔｉｏ」は「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニュー内に現れない。それぞれに対するチェックボックスコントロールがそれぞれ選択されている場合に「Ｈｏｒａｔｉｏ」および「Ｈａｍｌｅｔ」が両方とも、適切なフィルタ条件であった場合、ビューは、論理演算Ｔｙｐｅ＝ＰｏｗｅｒＰｏｉｎｔＡＮＤ（Ａｕｔｈｏｒ＝ＨａｍｌｅｔＯＲＡｕｔｈｏｒ＝Ｈｏｒａｔｉｏ）を満たすアイテムとともに更新される。＜ｅｎｔｅｒ＞コマンドが選択された場合、前述の論理演算が適用され、アドレスバーは、セグメント「ＰｏｗｅｒＰｏｉｎｔ」とそれに続くセグメント「Ｈａｍｌｅｔ，Ｈｏｒａｔｉｏ」を含むように修正され、ビューは、クエリの条件を満たすアイテムを反映するように更新される。一般的に言うと、異なるプロパティからの値は、アドレスバー内のクエリに追加されると論理ＡＮＤ演算と組み合わされる。

他の態様によれば、プロパティヘッダ内のすべてのプロパティ列が見えない場合、プロパティヘッダ上に収まらない列は、切り詰められ、ツールバーに共通の、シェブロンなどのオーバーフローコントロールを通じてアクセスできる。シェブロンボタンを選択すると、切り詰められたプロパティコントロールを備えるメニューが表示される。図１４３は、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューがオーバーフロープロパティコントロールからアクティブ化される実施例を示している。特に、図１４３は、シェブロン１４３５０は追加のプロパティがアクセス可能であることを表すプロパティヘッダの右端を示している。シェブロン１４３５０を選択すると、プロパティ「Ａｕｔｈｏｒ」および「Ｔｙｐｅ」に対応する２つの追加のプロパティコントロールが表示される。カーソルは、「Ｔｙｐｅ」プロパティコントロール上に置かれ、「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューに対応するコントロールが選択され、整列部分１４３３０およびフィルタ部分１４３３５を含む「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューが表示される。

「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニュー内に存在する整列コマンドは、「Ｓｔａｃｋｂｙ＜プロパティ＞」および「Ｇｒｏｕｐｂｙ＜プロパティ＞」さらには上で説明されている「Ｄｏｎ’ｔＦｉｌｔｅｒｂｙ＜プロパティ＞」を含む。図１４１Ｃ、１４２Ｂ、および１４３に示されている「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューの実施例では、プロパティは「Ｔｙｐｅ」である。したがって、整列コマンドは、「ＳｔａｃｋｂｙＴｙｐｅ」および「ＧｒｏｕｐｂｙＴｙｐｅ」を含む。

ビュー内のアイテムが「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューに関連付けられているプロパティによりスタッキングされていない場合、「Ｓｔａｃｋｂｙ＜プロパティ＞」コマンドは有効にされる。「Ｓｔａｃｋｂｙ＜プロパティ＞」コマンドを選択すると、フィルタ条件を生成するために適用される分類に応じてアイテムのスタックがビュー内に作成される。したがって、プロパティ「Ｔｙｐｅ」に関して、スタックは、「ＭｉｃｒｏｓｏｆｔＷｏｒｄＤｏｃｕｍｅｎｔｓ」、「ＰｏｗｅｒＰｏｉｎｔ」、「ＥｘｃｅｌＷｏｒｋｓｈｅｅｔ」、および「ａｒｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューのフィルタ部分１４１３５内のフィルタ条件の一覧に含まれる他のフィルタ条件を含むことができる。例示的なスタックは、例えば、図に示され、図１０において上で説明されているアイテム６５１〜６５５に類似の外観を呈することができる。

さらに、「ＳｔｏｐＳｔａｃｋｉｎｇｂｙ＜プロパティ＞」コマンドは、アイテムが現在アクティブ化されているプロパティコントロールのプロパティによりスタッキングされている場合に使用可能である。このコマンドを選択すると、現在のプロパティによるスタッキングは停止する。

ビュー内のアイテムが「ａｒｒａｎｇｅａｎｄｆｉｌｔｅｒ」ドロップダウンメニューに関連付けられているプロパティによりグループ化されていない場合、「Ｇｒｏｕｐｂｙ＜プロパティ＞」コマンドは有効にされる。「Ｇｒｏｕｐｂｙ＜プロパティ＞」コマンドを選択すると、フィルタ条件を生成するために適用される分類に応じてアイテムのグループがビュー内に作成される。グループ化されたアイテムの外観は、Ｗｉｎｄｏｗｓ（登録商標）ＸＰブランドのオペレーティングシステムにおけるグループ化に類似していてもよい。さらに、「ＳｔｏｐＧｒｏｕｐｉｎｇｂｙ＜プロパティ＞」コマンドは、アイテムが現在アクティブ化されているプロパティコントロールのプロパティによりグループ化されている場合に使用可能である。このコマンドを選択すると、現在のプロパティによるグループ化は停止する。

図４１〜５０および図１３４〜１３５は、図１０の情報行６４１に対応する、また本発明により形成される、仮想アドレスバーに関係する図である。以下でさらに詳しく説明するように、仮想アドレスバーは、複数のセグメントを含み、それぞれのセグメントは、コンテンツを選択するためのフィルタに対応する。まとめると、それぞれのセグメントの対応するフィルタは、コンテンツを選択するための仮想アドレスを表すことになる。

図４１は、本発明を動作させるのに好適な例示的なネットワークコンピューティング環境１２００のブロック図である。例示的なネットワークコンピューティング環境１２００は、ユーザと対話するための、図１に関して説明されているパーソナルコンピュータ１２０２などのコンピューティングデバイスを備え、ユーザは、コンピューティングデバイスのローカルまたはリモートに格納されているファイルを表示することができる。以下の説明では、パーソナルコンピュータに関して本発明を説明しているが、コンピューティングデバイス１２０２は、限定はしないが、ミニおよびメインフレームコンピュータ、ＰＤＡ、タブレットコンピュータ、およびユーザと対話し、コンピューティングデバイスおよび他の場所に格納されているファイルおよびコンテンツを表示することができる他のデバイスを含む、様々な種類の物理デバイスを備える。

例示的なネットワークコンピューティング環境１２００は、さらに、図４１に示されているように、コンピューティングデバイス１２０２からアクセス可能なファイルを格納し、インターネット１２０６などの通信ネットワークを介してコンピューティングデバイスに接続されているサーバー１２０４などの１つまたは複数のリモートサーバーを備えることができる。それに加えて、コンピューティングデバイス１２０２は、さらに、リモートデータベース１２０８などのファイルまたは他のコンテンツを格納する他の情報源に接続することもできる。当業者であれば、リモートサーバー２０４とリモートデータベース１２０８の両方に、さらにはハードディスクドライブ１６６（図１）などのローカル記憶装置デバイスに格納されているファイルおよび情報は、コンピューティングデバイス上の統合ファイルシステムの一部としてコンピューティングデバイス１２０２からアクセス可能であり、またコンピューティングデバイス１２０２に表示することが可能であることを理解するであろう。さらに、リモートサーバー１２０４およびリモートデータベース１２０８の特定の構成が図４１に示されているが、当業者であれば、この特定の構成は例示のみを目的としており、本発明に対する制限として解釈すべきではないことを容易に理解するであろう。

図４２は、従来技術に見られるような、コンピュータファイルシステム内のファイルを表示することに関連付けられている従来のアドレスバー１３０２を持つ例示的なファイルビューア１３００を示している。この説明の目的に関して、ファイルビューアは、ファイルまたは他のコンテンツをユーザに対して表示するためのディスプレイデバイス１５８（図１）などのディスプレイデバイス上のビューまたはウィンドウである。ファイルビューアは、特にファイルをユーザに対し表示するための実行可能プログラムに対応するウィンドウであってよい。それとは別に、ファイルビューアは、コンピュータシステムにローカルまたはリモートで接続されている記憶装置デバイスにデータを保存したり、またはデータを取り出したりしなければならない実行可能プログラム上で開または閉ダイアログボックス内のビューとすることができる。ファイルビューアの上記の実施例は、例示的であり、本発明に対する制限として解釈すべきではないことに留意されたい。

従来のアドレスバー１３０２内のアドレスは、ファイルシステム内の特定の場所に対応している。すでに説明されているように、従来のアドレスバー１３０２内に表示されるアドレスを編集するために、ユーザは、ファイルシステムについて具体的に知っている内容に基づいてアドレスを修正しなければならない。それとは別に、ユーザは、ツリービュー１３０４で１つのエントリを選択して代替えの場所にナビゲートすることができる。当業者であれば、例示的なファイルビュー１３００に示されていないアドレスバー１３０２の外部にある他のコントロールも利用可能であることは理解するであろう。従来のアドレスバー１３０２に表示されるアドレスは、ファイルシステム内の特定の場所に対応しているが、ファイルシステム内の複数のフォルダにまたがって分散されている関係するファイルは、従来のアドレスバー１３０２と連動して表示することはできない。

図４３は、コンピュータファイルシステム内のファイルを表示することに関連付けられている仮想アドレスバー１４０２を持つ例示的なファイルビューア１４００を示している。仮想アドレス１４０４を持つ、仮想アドレスバー１４０２は、図４２の従来技術のファイルビューア１３００の従来のアドレス１３０４により表示されるものと類似の情報を表示するように構成される。仮想パスとも呼ばれる、仮想アドレスは、選択基準に従ってコンピュータファイルシステムに格納されているファイルを参照する。

図４２のアドレス１３０４などの従来のアドレスと同様に、仮想アドレスの選択基準において、ファイルシステム階層内の特定の場所に格納されているファイルを参照することができる。しかし、従来のアドレスとは対照的に、仮想アドレスの選択基準では、さらに、それらの特定のファイルシステムの場所とは無関係にファイルを参照することもできる。そのため、仮想アドレスでは、物理的な場所および仮想的な場所を含むコンピュータファイルシステム内の複数の場所に格納されているファイルを参照することができる。図４３に示されているように、ファイルビューア１４００は、仮想アドレスバー１４０２内の仮想アドレス１４０４に従って、図４１のファイルビューア１３００では見つからない、ファイル１４０６および１４０８などの追加のファイルを表示することができる。さらに、仮想アドレスバー１４０２は、さらに、コンピュータファイルシステム内のファイル以外のコンテンツを表示するために使用することができる。例えば、仮想アドレスバー１４０２は、システムデバイス、システムサービス、またはインターネットロケーションを含むコンテンツを参照するために使用することができる。

図４４Ａは、仮想アドレス１４０４のセグメントを操作してコンピュータファイルシステム内をナビゲートすることを例示している。仮想アドレスバー１４０２などのそれぞれの仮想アドレスバーは、セグメント１５０２、１５０４、１５０６、および１５０８などの１つまたは複数のインタラクティブセグメントからなる。仮想アドレスバー内のそれぞれのセグメントは、コンピュータファイルシステムからアクセス可能な入手できるコンテンツまたはファイルすべてに対する１つまたは複数の所定のフィルタまたは選択基準に対応することができる。まとめると、仮想アドレスバー１４０２内のすべてのセグメントのフィルタは、仮想アドレスバーの仮想アドレスを表す。

セグメント１５０２などの仮想アドレスバー内の第１のセグメントは、ルートセグメント、またはルートフィルタと呼ばれる。ルートセグメントは、仮想アドレスバー１４０２による選択に使用できるコンテンツの最も広範なカテゴリを表す。例えば、セグメント１５０２「Ｆｉｌｅｓ」は、コンピュータファイルシステムからアクセス可能なすべてのファイルを参照するフィルタを表す可能性がある。それとは別に、ルートセグメントは、コンピュータシステム上でユーザが利用可能なすべてのシステムサービスを参照するフィルタ、またはコンピュータシステム内にインストールされているすべてのハードウェアデバイスを参照するフィルタを表すことができる。当業者であれば、本発明により多数の他の代替えルートフィルタが使用可能であることを理解するであろう。そのため、上述の実施例は、例示を目的として与えられており、本発明に対する制限として解釈すべきではない。それに加えて、ルートセグメント１５０２上の「Ｆｉｌｅｓ」などのそれぞれのセグメントについて表示されるラベルは、例示的であり、本発明に対する制限として解釈すべきではない。例示的な一実施形態によれば、セグメント上に表示されるラベルは、ユーザ構成可能である。

セグメント１５０４、１５０６、および１５０８などの仮想アドレスバー１４０２内のそれぞれの追加のセグメントは、ファイルビューア１４００でファイルまたはコンテンツを選択して表示するときに適用されるべき追加のフィルタを表す。例えば、ルートセグメント１５０２「Ｆｉｌｅｓ」は、コンピュータシステムに利用可能なすべてのファイルを参照する。セグメント１５０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」では、ワードプロセッサ、スプレッドシート、または他の何らかのドキュメント生成アプリケーションなどを通じて、ユーザによりドキュメントとして生成されたファイルを選択することにより、ルートセグメント１５０２により選択されたファイルをフィルタ処理する。セグメント１５０６「ＷｏｒｄＤｏｃｕｍｅｎｔｓ」は、ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎのＷｏｒｄアプリケーションなどのワードプロセッサを使用して生成されたドキュメントに従ってセグメント１５０４により選択されたファイルをフィルタ処理する。最後に、セグメント１５０８「ＡｕｔｈｏｒＡ」は、「ＡｕｔｈｏｒＡ」が作成者であったかどうかに応じてセグメント１５０６により選択されたワードプロセッシングドキュメントをフィルタ処理する。そのため、仮想アドレスバー１４０２内に表される仮想アドレスに従って選択されたコンテンツは、仮想アドレスバー内のすべてのセグメントに対応するフィルタ条件を満たさなければならない。

仮想アドレスバー１４０２内のセグメントは、一般に、最も包含的なフィルタから最も包含的でないフィルタまで、順序付けられる。例えば、すでに説明されているように、セグメント１５０２「Ｆｉｌｅｓ」は、最も広範で、最も包含的である。セグメント１５０６「ＷｏｒｄＤｏｃｕｍｅｎｔｓ」およびセグメント１５０８「ＡｕｔｈｏｒＡ」は、最も包含的でない。仮想アドレスバー１４０２は、左から右へのセグメントの順序付けを例示しており、本発明の説明のために、セグメント１５０４、１５０６、および１５０８は、ルートセグメント１５０２の後に続く。しかし、本発明の範囲から逸脱することなく、上から下への整列などの他の向きも可能であることは理解されるであろう。そのため、左から右への向きは、例示的としてみなされるべきであり、本発明に対する制限として解釈すべきではない。

すでに述べたように、セグメント１５０２、１５０４、１５０６、および１５０８などの、仮想アドレスバー１４０２内のセグメントは、フォルダ、ドライブ、およびディレクトリなどのコンピュータファイルシステム内の特定の場所に必ずしも対応しない。そのため、セグメント１５０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」では、複数のサーバー、ドライブ、またはフォルダ／ディレクトリ上に分散されたファイルまたはコンテンツを参照することができる。しかし、仮想アドレスバー１４０２内のいくつかのセグメントでは、コンピュータファイルシステム階層を持つ特定の場所を参照することができる。特定のファイルシステムロケーションを参照する仮想アドレスセグメントの詳細な説明は、図４８Ａおよび４８Ｂに関して以下で与えられる。

従来のアドレスバーとは対象的に、仮想アドレスバー１４０２内のそれぞれのセグメントは、アクション可能なインタラクティブユーザインターフェース要素を表す。例えば、仮想アドレス１４０２内のセグメントは、ユーザ選択に応答し、カーソルが特定の期間にそのセグメント上に置かれているかどうかを監視し、ユーザ対話操作であるドラッグにより仮想アドレスバーから削除することができる。したがって、図４４Ａに示されているように、ユーザは、セグメント１５０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」などの仮想アドレスバー１４０２内のセグメント上にカーソル１５１０を置き、そのセグメントを選択するかクリックして、そのレベルへナビゲートする、つまり、図４４Ｂに関して説明されているように、そのセグメントで仮想アドレスを切り詰めることができる。

図４８Ｂは、仮想アドレスバー１４０２内のセグメント１５０４を選択した結果を例示している。ユーザは、仮想アドレスバー１４０２内のセグメント５０４をクリックすることにより、仮想アドレスにおけるそのレベルにナビゲートするのを望んでいることを示している。実際、ユーザは、選択されたセグメントの後のフィルタを切り落とす。例えば、セグメント１５０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」（図４４Ａ）をクリックすることにより、結果として得られる仮想アドレス１４０４は、もはや、セグメント１５０６「ＷｏｒｄＤｏｃｕｍｅｎｔｓ」および１５０８「ＡｕｔｈｏｒＡ」（図４４Ａ）を含まなくなる。それに加えて、ユーザは制限の少ない一組のフィルタにすでにナビゲートしているので、仮想アドレスバー１４０２内のその結果の仮想アドレス１４０４は、より包含的である。これは、ドキュメント１５１２、ドキュメント１５１４、およびドキュメント１５１６を含む、図４４Ａのファイルビューア１４００ではまだ見えていない図４４Ｂのファイルビューア１４００内のドキュメントを加えることにより、また領域の制約上ファイルビューア１４００（図４４Ｂ）内に表示できない追加のファイルが見えることを示すスクロールボタン１５１８の存在により示される。

図４４Ｃは、図４４Ａに似ているが、セグメント１５０８をセグメント１５２０で置き換えている。セグメント１５２０は、２個のフィルタまたは選択基準「２００２」および「２００３」を含み、これらは論理的に結合され、その結果はファイルビューア１４００内に表示される。２つのフィルタまたは選択基準の間の「，」は、論理オペランドとして使用される。ＡＮＤ、ＯＲ、ＮＯＴ、ＮＡＮＤ、ＮＯＲ、ＸＯＲなどのブール演算子を適用できることは理解されるであろう。本発明の実装では、「，」は「ＯＲ」演算子として使用され、前にあるすべてのフィルタまたは選択基準（Ｆｉｌｅｓ、ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ、ＷｏｒｄＤｏｃｕｍｅｎｔｓ）の条件を満たし、「２００２」年に作成されるか、または「２００３」年に作成されたアイテムは、論理式を満たし、ファイルビューア１４００内に表示される。２つのフィルタまたは選択基準は、仮想的または物理的な場所にあるアイテムを識別することができる。例えば、一方のフィルタまたは選択基準では、物理的な場所にあるアイテムを識別することができるが、他方のフィルタまたは選択基準では、仮想的な場所にあるアイテムを識別することができる。フィルタまたは選択基準はいくつでも、論理的に結合して単一セグメントにすることができるが、実用目的に関しては、ユーザの混乱を最小限に抑えるために結合される数をアドレスバー上に一緒に表示できる数に制限するのがよいであろう。複数のプロパティにまたがってフィルタまたは選択基準を論理的に結合することは、本発明の範囲内にあるが、編成上の目的のために同じプロパティ内のフィルタまたは選択基準を論理的に結合し、発生しうるユーザの当惑を回避することが好ましい。

フィルタまたは選択基準の論理結合は、アドレスバー内の１つまたは複数のセグメント内で出現しうることは理解されるであろう。例えば「ＡｕｔｈｏｒＡ」を使用してセグメントを追加し図４４Ｃ内のセグメント１５２０の後に続けた場合、ファイルビューアに表示されるアイテムは、「２００２」年または「２００３」年に作成され、Ａが作成者であるワードドキュメントにさらに絞り込まれる。セグメント「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」を図４４Ｃから選択すると、図４４Ｂに示されているファイルビューア４００が出現し、セグメント「ＷｏｒｄＤｏｃｕｍｅｎｔｓ」および「２００２，２００３」は削除され、フィルタ「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」の条件を満たすファイルが表示される。

より制限の少ないセグメントにナビゲートするために仮想アドレスバー内のセグメントを選択することに加えて、ユーザは、さらに、仮想アドレス内の現在のセグメントのピアフィルタにナビゲートするか、または選択したい場合もある。ピアフィルタは、選択されることができ、仮想アドレスバー内の与えられたセグメントに適用される代替えフィルタである。例えば、図４４Ａを参照すると、セグメント１５０６「ＷｏｒｄＤｏｃｕｍｅｎｔｓ」に対するピアフィルタは、「ＥｘｃｅｌＤｏｃｕｍｅｎｔｓ」、「Ｊｏｕｒｎａｌｓ」などのフィルタを含むことができる。特定のファイルシステムロケーション、ハードウェアデバイス、またはコンピュータサービスを含む他の種類のフィルタも、仮想アドレスバー内の与えられたセグメントに適用することができる。ピアフィルタは、与えられたセグメントの現在のフィルタに論理的に関係する場合もしない場合もある。仮想アドレスバー内のそれぞれのセグメントは、ピアフィルタを持つことができる。仮想アドレスバー内のセグメントのピアフィルタを選択することは、ときには、「横方向にナビゲートする」という場合もある。仮想アドレスバー内のセグメントのピアフィルタを選択することは、図４５Ａ〜４５Ｄに関して、また図４９に関しても、以下で説明されている。

図４５Ａ〜４５Ｄは、仮想アドレスバー１６００内の仮想アドレスのセグメントに関連付けられているピアフィルタを選択することを例示する絵図である。図４５Ａに示されているように、仮想アドレスバー１６００は、複数のセグメント、セグメント１６０２〜１６０８を含む仮想アドレスを持つ。仮想アドレスバー１６００内の与えられたインタラクティブセグメントに対しピアフィルタを選択するために、ユーザは、そのインタラクティブセグメントの二者択一選択、または二者択一操作を行わなければならない。二者択一選択を行う方法の１つは、与えられたセグメントを右クリックすることである。右クリックは、当技術分野で知られており、マウスのセカンダリボタン、または他の入力デバイスを使用することを意味するが、ただし、セカンダリボタンは、典型的にはマウスの右側にある。それとは別に、インタラクティブセグメントは、カーソルがいつその上に置かれるかを監視できるため、カーソルをインタラクティブセグメントの上に置き、ホバリングとも呼ばれる所定の期間カーソルを適所に置いたままにすることにより二者択一選択を行うことができる。しかし、本明細書ではピアフィルタを表示させる代替え手段を説明しているが、これらは例示のためであり、本発明に対する制限として解釈すべきではない。当業者であれば、二者択一選択を生成するための代替え手段が多数あることを理解するであろう。

図４５Ａを参照すると、セグメントを二者択一選択することを例示するために、ユーザはまず、カーソル１６１０を所定の時間の間セグメント１６０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」上に置く、つまり、そのセグメント上でホバリングして、そのセグメントを選択する。図４５Ｂは、仮想アドレスバー１６００内のセグメント１６０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」を二者択一選択した結果を示している。図４５Ｂに示されているように、セグメント１６０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」を二者択一選択した後、ピアフィルタ１６１２が表示され、ピアフィルタが選択されたセグメントに対応することを示す。ピアフィルタビュー１６１２に表示されるピアフィルタは、例示することのみを目的としており、本発明に対する制限として解釈すべきではないことは理解されるであろう。

図４５Ｃに示されているように、代替えピアフィルタを選択するために、ユーザは、カーソル１６１０を、ピアフィルタ１６１４などのピアフィルタビュー１６１２に表示されるフィルタのうちの１つに置き、ピアフィルタを選択する。図４５Ｄに示されているように、代替えピアフィルタ１６１４を選択した後、すでに選択されているセグメント１６０４（図４５Ａ）は、選択された代替えピアフィルタ１６１４を表す新しいセグメント１６１６で置き換えられる。それに加えて、図４５Ａの仮想アドレスバー１６００内で二者択一選択されたセグメント１６０４に続くセグメント、特にセグメント１６０６「Ｊｏｕｒｎａｌｓ」および１６０８「ＡｌｌＤｏｃｕｍｅｎｔｓｉｎ２００２」は、図４５Ｄにおける仮想アドレスバー１６００から削除される。したがって、図に示されていないが、セグメント１６０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」、１６０６「Ｊｏｕｒｎａｌｓ」、および１６０８「ＡｌｌＤｏｃｕｍｅｎｔｓＩｎ２００２」に従ってすでに選択されているファイルまたはコンテンツは、対応するファイルビューア内に表示されなくなり、セグメント１６０２「Ｆｉｌｅｓ」および１６１６「ＰｉｃｔｕｒｅＬｉｂｒａｒｙ」に従って選択されたファイルまたはコンテンツのみが表示されるということになる。

本発明の他の態様によれば、ユーザは、仮想アドレス内の現在のセグメントの子フィルタまたは選択基準にナビゲートするか、または選択することを望む場合もある。ファイルツリー構造において、親ノード（または親フィルタ）は、子ノードにより表される子を持つ。それぞれの子ノードは、子フィルタまたは選択基準であり、さらに親ノードまたは親フィルタまたは選択基準を絞り込む。仮想アドレスバー内のそれぞれのセグメントは、子フィルタまたは選択基準を持つことができる。図４４Ａでは、セグメント１５０４は、セグメント１５０２の子である。仮想アドレスバー内のセグメントの子フィルタまたは選択基準を選択することは、図１３５Ａ〜１３５Ｄに関して、また図１３４に関しても、以下で説明されている。

図１３５Ａ〜１３５Ｄは、仮想アドレスバー１３５００内の仮想アドレスのセグメントに関連付けられている子フィルタまたは選択基準を選択することを例示する絵図である。図１３５Ａに示されているように、仮想アドレスバー１３５００は、複数のセグメント、セグメント１３５０２〜１３５０８を含む仮想アドレスを持つ。仮想アドレスバー１３５００内の与えられたインタラクティブセグメントに対し子フィルタまたは選択基準を選択するために、ユーザは、その与えられたインタラクティブセグメントに関連付けられている子コントロールを選択することができる。子コントロール１３５０３、１３５０５、１３５０７、および１３５０９は、それぞれ、インタラクティブセグメント１３５０２、１３５０４、１３５０６、および１３５０８に関連付けられている。それぞれのセグメントおよびその関連付けられた子コントロールは、分割ボタンを形成できることは理解されるであろう。

子フィルタまたは選択基準を選択する一実施例は、図１３５Ｂ〜１３５Ｄに関して説明される。図１３５Ａを参照すると、子フィルタまたは選択基準を選択するために、ユーザはまず、カーソル１３５１０を所定の時間の間子コントロール１３５０５の上に置く、つまり、そのコントロール上でホバリングして、その子コントロールを選択する。子コントロール１３５０５上で左クリックオペレーションを実行することによりコントロールを選択するなどの他の選択オペレーションも可能である。図１３５Ｂは、仮想アドレスバー１３５００内のセグメント「Ｆｉｌｅｓ」に関連付けられている子コントロール１３５０５を選択した結果を示している。図１３５Ｂに示されているように、子コントロール１３０５を選択した後、対応するインタラクティブセグメント１３５０２に対する子フィルタまたは選択基準の一覧、および子フィルタまたは選択基準に対する対応するアイコンを含む子ビュー１３５１２が表示される。このアイコンにより、仮想的な場所を表すのか、または物理的な場所を表すのか、さらに仮想的または物理的な場所の特定のタイプなど、子フィルタまたは選択基準に対する特定のタイプを識別することができる。子ビューのこの実施例では、分割メニューが表示され、アイコンは子ビューの左列に、子フィルタまたは選択基準は子ビューの右列にある。子ビュー１３５１２に表示される子フィルタまたは選択基準、およびアイコンは、例示することのみを目的としており、本発明に対する制限として解釈すべきではないことは理解されるであろう。また、アイコンは、子ビュー、ピアビュー、または他の何らかのものの一部であるかどうかに関係なくアドレスタイプに隣接して表示することができることは理解されるであろう。

図１３５Ｃに示されているように、子フィルタまたは選択基準を選択するために、ユーザは、カーソル１３５１０を、子フィルタまたは選択基準１３５１４などの、子フィルタビュー１３５１２に表示される、子フィルタまたは選択基準のうちの１つに置き、子フィルタまたは選択基準１３５１４を選択する。図１３５Ｄに示されているように、子フィルタまたは選択基準１３５１４を選択した後、子コントロール１３５０５（図１３５Ａ）に関連付けられている親セグメント１３５０２の後に続くセグメント１３５０４は、選択された子フィルタまたは選択基準１３５１４を表す新しいセグメント１３５１６で置き換えられる。それに加えて、図１３５Ａの仮想アドレスバー１３５００内でセグメント１３５０４に続くセグメント、特にセグメント１３５０６「Ｊｏｕｒｎａｌｓ」および１３５０８「ＡｌｌＤｏｃｕｍｅｎｔｓｉｎ２００２」は、図１３５Ｄにおける仮想アドレスバー１３５００から削除される。したがって、図に示されていないが、セグメント１３５０４「ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ」、１３５０６「Ｊｏｕｒｎａｌｓ」、および１３５０８「ＡｌｌＤｏｃｕｍｅｎｔｓＩｎ２００２」に従ってすでに選択されているファイルまたはコンテンツは、対応するファイルビューア内に表示されなくなり、セグメント１３５０２「Ｆｉｌｅｓ」および１３５１６「ＰｉｃｔｕｒｅＬｉｂｒａｒｙ」に従って選択されたファイルまたはコンテンツのみが表示されるということになる。

セグメントは、既存のセグメントの終わりに様々なユーザ対話操作を通じて仮想アドレスバー内の仮想アドレスに加えることができる。フィルタを仮想アドレスバー内の仮想アドレスに追加するために、ユーザは、ウィンドウ上に見られる特定のフィルタに関連付けられているアクション可能なコントロール、または仮想アドレスバーを持つファイルビューアを操作することができる。例えば、図４３のファイルビューア１４００を参照すると、ユーザは、アクション可能なコントロール１４１２「２００３」をクリックして、仮想アドレスバー１４０２内の仮想アドレス１４０４に対応するフィルタを追加することができる。それとは別に（図には示されていない）、ユーザは、フィルタの名前を入力することにより仮想アドレスの末尾に知られているフィルタを入れることができる。フィルタを仮想アドレスに追加する他の多数の方法が、存在し、すべて、本発明の範囲内にあるものと考えられる。そのため、上記の実施例は、例示することを目的としており、本発明に対する制限として解釈すべきではないことは理解されるであろう。

フィルタが仮想アドレスバーの仮想アドレスに追加されると、新たに追加されたフィルタが仮想アドレスの一部として現在存在するフィルタとコンフリクトしないようにするプロセスが実行される。新たに追加されたフィルタが既存のフィルタとコンフリクトする場合、既存のフィルタが削除される。新たに追加されたフィルタは、新たに追加されたフィルタが既存のフィルタの範囲と異なる場合に仮想アドレス内の既存のフィルタとコンフリクトし、既存のフィルタよりも広いか広くないかのいずれかである。さらに、新たに追加されたフィルタは、新たに追加されたフィルタと既存のフィルタとが相互排他的である場合に既存のフィルタとコンフリクトする。しかし、既存のフィルタに相当する新たに追加されたフィルタは、何ら効果を有しないため追加されない。上記のコンフリクトの説明は、例示することを目的として与えられており、本発明に対する制限として解釈すべきではないことは理解されるであろう。当業者であれば、本発明の範囲内に収まると考えられるフィルタ間の他のコンフリクトも存在しうることを理解するであろう。

図４６Ａ〜４６Ｄは、フィルタを仮想アドレスバー１７００内の仮想アドレス１７０２に加えること、およびコンフリクトしている既存のフィルタを削除することを例示する絵図である。図４６Ａは、仮想アドレスバー１７００内に表示されている例示的な仮想アドレス１７０２を例示している。図４６Ｂに示されているように、セグメント１７０６「２００２」により表されている新しいフィルタが、仮想アドレス１７０２に追加される。前述のように、新しいフィルタは仮想アドレスの末尾に追加されるが、これは、図４６Ｂの仮想アドレスバー１７００内のセグメントの末尾にセグメント１７０６「２００２」を配置することにより示されている。これ以降、セグメント１７０６「２００２」を追加するために実行されるプロセスは、追加されたフィルタが仮想アドレス１７０２内の現在のフィルタとコンフリクトすると判定する。したがって、既存のフィルタは、仮想アドレス１７０２から削除されない。

図４６Ｃに示されているように、他のフィルタは、仮想アドレス１７０２に追加され、これはセグメント１７０８「ＡｕｔｈｏｒＡ」により表されている。この新しいフィルタを追加するために実行されるプロセスは、新しいフィルタ「ＡｕｔｈｏｒＡ」は、既存のフィルタよりも狭いためセグメント１７０４「ＡｕｔｈｏｒＡ−Ｆ」により表されるフィルタとコンフリクトするであろうと判定する。したがって、セグメント１７０４「ＡｕｔｈｏｒＡ−Ｆ」は、仮想アドレスバー１７００から削除され、セグメント１７０８「ＡｕｔｈｏｒＡ」が、仮想アドレスバー内のセグメントの末尾に追加される。

図４６Ｄは、図４６Ｃの仮想アドレスバー１７００にセグメント１７１０「２００３」を追加した結果を例示している。仮想アドレス１７０２内のフィルタは、制限的であり、累積的ではない。それぞれのフィルタは、さらに、選択されたコンテンツを制限する。それにより、相互排他的なフィルタは、仮想アドレス１７０２で、ファイルまたはコンテンツを選択すること、したがってコンフリクトを生じることを防ぐ。図４６Ｄに例示されているように、セグメント１７０６「２００２」（図４６Ｃ）は、新たに追加されたセグメント１７１０「２００３」と相互排他的であるためコンフリクトを生じるので仮想アドレスバー１７００から削除される。

仮想アドレスバー１８００（図４７Ａ）などの仮想アドレスバーが仮想アドレスバーのサイズが制限されているため仮想アドレス全体を表示できない場合、仮想アドレスバーのサイズに応じて仮想アドレスの一部が表示される。しかし、仮想アドレスの未表示の部分は、それでも、ユーザからアクセスできる。より具体的には、仮想アドレスバーは、仮想アドレスバー内の仮想パスをスクロールさせるアクション可能な視覚的インジケータを表示する。図４７Ａおよび４７Ｂは、仮想アドレスが仮想アドレスバーの表示限度を超えている仮想アドレスを表示する例示的な仮想アドレスバー１８００を例示している。図４７Ａおよび４７Ｂに示されているように、スクロールアイコン１８０２および１８０４は、仮想アドレスのこれまで未表示であった部分を表示するために仮想アドレスバー１８００がスクロールする方向を示す。しかし、例示的な図は、スクロールアイコンの使用を示しているが、これは、例示することのみを目的としており、本発明に対する制限として解釈すべきではない。当業者であれば、すべて本発明の範囲内に収まると考えられる、仮想アドレスバー内の仮想アドレスをスクロールする方法はほかにも多数あることを理解するであろう。

他の態様によれば、アドレスバーが小さすぎてアドレスを含むインタラクティブセグメント全部が入りきらないようなオーバーフロー条件が発生した場合、表示されているインタラクティブセグメントは、固有性の最も高いものである。例えば、図４７Ｃを参照すると、より広いインタラクティブセグメントＦＩＬＥＳは含まれないが、最も固有性の高いインタラクティブセグメントが仮想アドレスバー１８００上に表示される。シェブロン１８０６は、隣接するインタラクティブセグメントＤＯＣＵＭＥＮＴＬＩＢＲＡＲＹが表示されない先祖を有することを示すオーバーフローインジケータとして使用される。シェブロン１８０６は、オーバーフローインジケータだけでなく子コントロールとしても使用されるという点で二重の役割を持つ。図４７Ｃに示されているように、シェブロン１８０６の選択により、インタラクティブセグメントＤＯＣＵＭＥＮＴＬＩＢＲＡＲＹ用のフィルタＰＯＷＥＲＰＯＩＮＴＤＯＣＵＭＥＮＴＳ、ＷＯＲＤＤＯＣＵＭＥＮＴＳ、ＶＩＳＩＯＤＯＣＵＭＥＮＴＳ、およびＥＸＣＥＬＤＯＣＵＭＥＮＴＳを含む子フィルタまたは選択基準リスト１８１２が得られ、また、先祖ＦＩＬＥＳを含むインタラクティブセグメントＤＯＣＵＭＥＮＴＬＩＢＲＡＲＹの先祖リスト１８０８も表示される。先祖または子フィルタリストから先祖フィルタまたは子フィルタを選択することで、アドレスバーは、そのフィルタを表示し、その後のすべてのフィルタを削除するように修正される。シェブロン１８０６は、先祖リストを表示するためのコントロールとして使用することができ、また独立の子コントロールも存在しうることは理解されるであろう。

図４８Ａは、ファイルシステム内の仮想的な場所と実際の場所の両方を参照するセグメントを有する仮想アドレスバー１９００を例示するブロック図である。すでに説明されているように、仮想アドレスバー１９００内の仮想アドレスは、コンピュータファイルシステム階層内の特定の場所を参照するセグメントを含むことができ、さらに、コンピュータファイルシステム内の仮想的または論理的な場所を参照するセグメントも含むことができる。仮想セグメントにより参照されるファイルまたはコンテンツは、多数の物理的な場所に分散させることができる。仮想アドレスバー１９００は、物理的な場所を参照するセグメントおよび仮想的な場所を参照するセグメントを含むことができる。例えば、仮想アドレスバー１９００は、特定のドライブ「Ｃ」におけるコンピュータファイルシステム内の特定の領域に含まれるファイルまたはコンテンツを参照するセグメント１９０２「ＬｏｃａｌＤｉｓｋ（Ｃ：）」を含む。それとは別に、セグメント１９０４「ＣａｓｅＦｉｌｅｓ」はそれ自体、ケースファイルに関連付けられているコンピュータファイルシステム階層内の複数のフォルダに格納されるファイルまたはコンテンツを参照する。しかし、セグメント１９０２「ＬｏｃａｌＤｉｓｋ（Ｃ：）」と組み合わせたセグメント１９０４「ＣａｓｅＦｉｌｅｓ」は、ローカルドライブ「Ｃ」上にあるケースファイルのみを参照する。それに加えて、セグメント１９０６「Ｃｏｎｔａｉｎｓ‘Ｆａｘ’」では、さらに、ローカルディスクＣ：上にあり、単語「Ｆａｘ」を含むかどうかに応じてケースファイルに関連付けられているファイルをフィルタ処理する。

図４８Ｂに示されているように、仮想アドレスバー１９００は、従来の仮想アドレスバーとして機能するように構成することができる。例えば、図４８Ａを参照すると、カーソル１９０８を仮想アドレスバー１９００の空領域内に置いて、そこをクリックすることにより、仮想アドレスバー１９００は、図４８Ｂに示されているように、仮想アドレスを表すセグメント表示することから、従来のアドレス１９１０を表示する従来のアドレスバーとして機能することに切り替える。図４８Ｂの仮想アドレスバー１９００内の従来のアドレス１９１０は、図４８Ａの仮想アドレスバー１９００に表示されている仮想アドレスに近似している。しかし、コンピュータファイルシステム内の物理的な場所に対応しない図４８Ａの仮想アドレスバー１９００内のフィルタは、表示することができず、従来のアドレス１９１０から削除される。特に、セグメント１９０４「ＣａｓｅＦｉｌｅｓ」およびセグメント１９０６「Ｃｏｎｔａｉｎｓ‘Ｆａｘ’」は、従来のアドレス１９１０（図４８Ｂ）の一部ではない。

従来のアドレスバーとして機能する仮想アドレスバー１９００を通常では仮想アドレスバーとして機能するように再構成するには、ユーザは、バーの空領域をクリックする以外の方法でそうであることを示さなければならない。従来のアドレスバーとして機能するように構成された場合、仮想アドレスバーでは、アドレス編集を目的とする場合にユーザが空領域をクリックすることを許可しなければならない。従来のアドレスバーの空領域をクリックすると、編集カーソルは、編集を目的としてアドレス／パスの末尾に配置される。したがって、仮想アドレスを上述のように通常の方法で再び機能するように再構成するには、ユーザは、ＥｓｃまたはＴａｂキーなどの定義済みキーまたはキーシーケンスを押すか、またはウィンドウまたはビューの他の領域をクリックすることによりフォーカスをウィンドウまたはビューの他の領域に置かなければならない。当業者であれば、他のユーザアクションも使用して、上述のように通常モードで再び機能するように仮想アドレスバー１９００を再構成しなければならないことを理解するであろうし、すべて、本発明の範囲内にあると考えられる。

図４９は、仮想アドレスバー内の識別されたセグメントについてピアフィルタを選択するためのピアフィルタ選択ルーチン２０００を示す流れ図である。ブロック２００２から始まる、ルーチン２０００は、ピアフィルタ選択のアクティブ化を検出する。ピアフィルタ選択プロセスをアクティブ化することについては、図４５Ａ〜４５Ｄに関して上で説明されている。ブロック２００４では、ピアフィルタ選択が要求されたセグメントが識別される。ブロック２００６で、識別されたセグメントに対するピアフィルタは、ピアフィルタの所定一覧から決定される。ブロック２００８で、ピアフィルタはユーザに対し表示される。ブロック２０１０で、表示されたピアフィルタからのユーザのピアフィルタ選択が得られる。ブロック２０１２で、仮想アドレスは、仮想アドレスバーからの識別されたセグメントおよび識別されたセグメントに続く追加のセグメントを削除することにより切り詰められる。ブロック２０１４で、選択されたピアフィルタを表すセグメントが、仮想アドレスバー内の残りのセグメントに付加される。その後、ルーチン２０００は終了する。

図５０は、フィルタを仮想アドレスバー内の仮想アドレスに追加するための例示的なフィルタ追加ルーチン２１００を示す流れ図である。ブロック２１０２から始まる、例示的なルーチン２１００は、仮想アドレスに追加されるフィルタを取得する。例えば、図４３に関してすでに説明されているように、フィルタは、仮想アドレスバーの外部のユーザアクションに応じて仮想アドレスに追加することができるか、またはそれとは別に、定義済みフィルタの名前を入力することにより仮想アドレスバーに直接追加することができる。

ブロック２１０４で、新しいフィルタが仮想アドレス前にすでにある既存のフィルタとコンフリクトするかどうかの決定が行われる。図４６Ａ〜４６Ｄに関してすでに説明されているように、新しいフィルタは、既存のフィルタのスコープを実質的に狭めるか、または広げることにより既存のフィルタとコンフリクトする場合がある。それとは別に、新しいフィルタは、新しいフィルタと既存のフィルタとが相互排他的であるため既存のフィルタとコンフリクトすることがある。決定ブロック２１０４において、新しいフィルタが既存のフィルタとコンフリクトする場合、ブロック２１０６で、既存のフィルタは仮想アドレスから削除される。それとは別に、２１０４で、新しいフィルタが既存のフィルタコンフリクトしていない場合、またはブロック２１０６で既存のコンフリクトしているフィルタを削除した後、ブロック２１０８で、新しいフィルタが仮想アドレスの末尾に追加される。その後、例示的なルーチン２１００は終了する。

図１３４は、仮想アドレスバー内の関連付けられているセグメントについて子フィルタまたは選択基準を選択するための選択ルーチン２２００を示す流れ図である。ブロック２２０２から始まる、ルーチン２２００は、子コントロールの選択を検出する。子フィルタ選択プロセスは、図１３５Ａ〜１３５Ｄに関して上で説明されている。ブロック２２０４で、選択された子コントロールに関連付けられている親セグメントが識別される。ブロック２２０６で、識別された親セグメントに対する子フィルタは、子フィルタの所定の一覧から決定される。ブロック２２０８で、子フィルタはユーザに対し表示される。ブロック２２１０で、表示された子フィルタからの子フィルタ選択をユーザから受け取る。ブロック２２１２で、仮想アドレスは、親セグメントに続くセグメントを削除することにより切り詰められる。ブロック２２１４で、選択された子フィルタを表すセグメントが、仮想アドレスバー内の残りのセグメントに付加される。その後、ルーチン２３００は終了する。

図５１〜５７は、シェルブラウザ内のユーザエクスペリエンスを改善する本発明の他の態様によるシステムおよび方法に関係する図である。より具体的には、ユーザがアイテムを、そのアイテムに関連付けられているメタデータに基づいて比較的容易に識別できるシステムおよび方法が実現される。

図５１Ａを参照すると、ウィンドウ２２００は、シェルブラウザのグラフィカルユーザインターフェース用の画面サイズの表示領域を表す。ウィンドウ２２００は、プレビューペイン領域２２０２およびビュー領域２２０４を含む。プレビューペイン２２０２は、プレビューコントロール２２０６、ユーザインターフェース（ＵＩ）またはエディットコントロール２２０８、およびタスクコントロール２２１０を含むことができる。典型的には、プレビューコントロール２２０６を使用すると、ユーザは、プレビューされるアイテム（例えば、選択されたファイル）の画像または他の視覚的表示を得ることができる。プレビューコントロール２２０６は、さらに、ユーザがマウスボタンをクリックすることにより一方のアイテムから次のアイテムへフォーカスをシフトすることができるイテレータボタンなどのコントロールもユーザに提示することもできる。１つまたは複数のアイテムに対応するメタデータおよび／またはアイテムコンテナに対応するメタデータは、ウィンドウ２２００内の様々な場所に表示することができる。例えば、エディットコントロールおよびメタデータは、エディットコントロール領域２２０８内に同時配置することができ、それにより、エディットコントロール領域は、プレビュー済みアイテムのキープロパティの表示を含むだけでなく、メタデータに対し編集を行うオプションをユーザに提示する。タスクコントロール２２１０は、名前空間および／または選択に関係するタスクを含む。

本発明の目的に関して、用語「メタデータ」および「ユーザ修正可能メタデータ」は、シェルアイテム名を除外する。用語「シェルアイテム名」は、シェルブラウザ内のアイテムの並べ替えおよび表示を目的として使用されるプロパティを指す。上述のように、本発明の独自の一態様は、シェルブラウザ内でユーザがメタデータを編集できることである。

当業者であれば、本発明では、ウィンドウ２２００内のオプション機能の存在が考えられることを理解するであろう。例えば、プレビューコントロール２２０６およびタスクコントロール２２１０は、本発明の目的に関して本質的な特徴ではない。さらに、ユーザがプレビューペインを開く／閉じることができるようなイテレータボタンまたは表示／非表示ボタンを含むツールバーなどの、図５１Ａに示されていない他の非本質的機能も、本発明の範囲内にある。しかしながら、これらの機能および他のオプション機能を使用することで、ユーザは、シェルブラウザ内で特定のアイテムを簡単に見つけられる。

ビュー領域２２０４は、ファイルシステムファイルまたはフォルダなどの、１つまたは複数のアイテム２２１２のリストビューを備える。「リストビュー」という用語は、コンテナ内のアイテムの列挙またはリストを意味する。「アイテム」および「シェルアイテム」は、本明細書では入れ換えて使用することができ、ファイル、フォルダ、および他のそのようなコンテナ、およびリストビューで表すことができる他の非ファイルオブジェクトを指す。非ファイルオブジェクトの実施例は、限定はしないが、連絡先、お気に入り、および電子メールメッセージを含むことができる。「シェルブラウザ」および「ファイルシステムブラウザ」という用語は、本明細書では入れ換えて使用することができ、ファイルおよび他の非ファイルアイテムを含む様々な名前空間内をユーザがナビゲートするために使用できるブラウザを指す。

当業者であれば、本発明では、ウィンドウ２２００に対し多数の可能な設計およびレイアウトが考えられることを理解するであろう。例えば、プレビューペイン２２０２は、図５１Ａのビュー領域２２０４の上に示されている。しかし、プレビューペイン２２０２およびビュー領域２２０４を並べて配置するなどの他のレイアウトは、明らかに本発明の範囲内にある。エディットコントロール２２０８の配置は、さらに、表示されているメタデータの配置から独立しており、また他のどのコントロールの配置からも独立している。詳細、スライドショー、フィルムストリップ、サムネイル、タイル、アイコンなどのリストビュー領域２２０４に示されるアイテムについても多数の可能なビュータイプがある。

図５１Ｂは、ビュー領域２２０４が、詳細モードでアイテム２２１２を表示するビュー領域２２１４で置き換えられることを除き、図５１Ａに類似している。詳細モードで表示されているシェルアイテムに対しては典型的であるように、アイテム２２１２は、ビュー領域２２１４の左側の列内で揃えられ、１つまたは複数の見出し２２１６は、同じ行内に配置されている対応するアイテムに関係するメタデータ２２１８を含む列の集まりの最上行を形成する。重要なのは、本発明では、ユーザがウィンドウ２２００内のどこかで１つまたは複数のエディットコントロール２２０８のインスタンス化を通じてメタデータ値を他の値に明示的に変更できることが考えられることである。例えば、エディットコントロールは、プレビューペイン２２０２および／またはビュー領域２２１４内に用意することができる。例えば、最初はユーザに対し非表示になっているエディットコントロールをビュー領域２２１４内に用意することができる。このようなコントロールは、例えば、ユーザがメタデータ２２１８上でホバリングし、次いで、それをクリックして、編集モードに入ったときにインスタンス化することができる。

次に図５２を参照すると、シェルブラウザ内のウェルカムペイン２３００の概略図が示されている。ウェルカムペインは、「空選択」ペインとも呼ばれるが、それは、選択と対立するものとして、名前空間またはコンテナを表すからである。ユーザがまだ選択を行っていない場合、プレビューペイン２３０２は、メタデータ２３０４およびフォルダまたはシェルライブラリに関係するキータスクを表示する。望むのであれば、タスクは、プレミアタスク２３０６および他の関連するタスク２３０８に分けることができる。ウェルカムペイン２３００は、さらに、複数のファイルまたは他のアイテム２３１２を表示することができるビュー領域２３１０も含む。ウェルカムペインメタデータ２３０４は、コンテナ（例えば、ＭｙＰｉｃｔｕｒｅｓ）のプロパティなどの情報を含むことができ、その場合、メタデータ表示は静的である。それとは別に、ウェルカムペインメタデータ２３０４は、コンテナ内アイテムのそれぞれからメタデータのサンプリングなどの情報を含むことができ、その場合、メタデータ表示は頻繁に変化しうる。例えば、メタデータ表示は、３０秒毎のアイテムの循環表示により、一度に１つのアイテムのプロパティに制限することができる。

図５３は、シェルブラウザ内の選択済みペイン２４００の概略図である。ウェルカムペインとは反対に、選択されたペインは、ユーザによる選択を表す。ユーザがコンテナまたはフォルダを選択した場合、選択されたペインは、そのコンテナまたはフォルダに対するウェルカムペインと同一である必要はない。図５３では、選択されたペイン２４００は、プレビューコントロール２４０４、メタデータ表示２４０６、およびタスク表示２４０８を含む、プレビューペイン２４０２を含む。ウェルカムペイン２３００（図５２）のように、選択されたペイン２４００は、さらに、ビュー領域２４１０も含み、そこでは、複数のファイルまたは他のアイテム２４１２を表示することができる。しかし、図５３では、ユーザは、これらのファイルのうちの１つを選択している。したがって、プレビューコントロール２４０４は、選択されたファイルのプレビュー画像を表示し、メタデータ表示２４０６は、選択されたファイルのプロパティを表示し、タスク表示２４０８は、選択されたファイル上での動作に関する関連するタスクのメニューを表示する。

図５４は、図５３の選択済みペインの概略図であるが、本発明の一実施形態によりシェルブラウザ内でユーザがメタデータを修正できるようにするコンテキストメニュー２５００も含む。図５４のコンテキストメニュー２５００では、ユーザ向けに、選択されたメタデータを変更するためのいくつかのオプションを表示する。メニュー２５００内に示されているジェネリックテキストは、もちろん、表示されているメタデータを編集するためユーザに対し表示することができるタイプのオプションの一実施例にすぎない。コンテキストメニューは、ウェルカムペインを含む、任意のウィンドウ内に表示することができ、これによりユーザエクスペリエンスが向上する。当業者であれば理解するように、本発明では、多数の様々なコンテキストメニューをサポートすることが可能である。本発明の目的に関して、シェルブラウザ内に表示されているメタデータに対するユーザ修正を可能にする一手段は、編集可能メタデータコンテキストメニュー２５００などのコンテキストメニューを表示することである。ユーザは、例えば、プレビューペイン内の対応するテキストまたオブジェクトをクリックすることにより、コンテキストメニューを呼び出すことができる。

当業者であれば、本発明では、シェルブラウザ内の表示されているメタデータに対するユーザ修正を可能にするコンテキストメニュー以外の手段が考えられることは理解するであろう。そのような他の手段としては、ユーザがメタデータ上をクリックして編集モードに入る方法がある。対照的に、ユーザは、プレビューペイン内の関連するテキストまたオブジェクト上をホバリングすることにより編集モードに入ることが可能である。多数の代替え手段が利用可能であり、本発明の範囲内にある。

図５５は、本発明の一実施形態によりシェルブラウザ内でユーザがウェルカムペインに表示されているメタデータを修正できるようにする方法２６００を例示する流れ図である。方法２６００は、ウェルカムペインおよび２６０２でウェルカムペインに関連付けられているメタデータを表示することを含む。次いで、２６０４で、この方法は、表示されているメタデータのユーザ修正のためのコントロールを与える。ユーザが２６０６で表示されているメタデータを修正するコントロールを操作する場合、この方法では、修正されたメタデータを２６０８でウェルカムペインに関連付けて、修正されたメタデータが次回ウェルカムペインが表示されたときに表示されるようにする。

図５６は、本発明の一実施形態によりシェルブラウザ内でユーザが選択済みペインに表示されているメタデータを修正できるようにする方法２７００を例示する流れ図である。２７０２で、方法２７００では、最初に、ウェルカムペイン内のアイテムまたは選択されたコンテナ内のアイテムなどの多数のアイテムを表示する。ユーザが２７０４でアイテムのうちの１つまたは複数のを選択した場合、この方法は、２７０６で選択された（複数の）アイテムに関連付けられているメタデータを表示する。２７０８で、この方法は、表示されているメタデータのユーザ修正のためのコントロールを表示する。ユーザが２７１０で表示されているメタデータを修正するコントロールを操作する場合、この方法では、２７１２で、修正されたメタデータを選択された（複数の）アイテムに関連付けて、修正されたメタデータが次回選択された（複数の）アイテムが表示されたときに表示されるようにする。

２７０４でユーザが複数のアイテムを選択した場合、表示されるメタデータは、選択されたアイテムのプロパティの積集合、プロパティの和集合、またはおそらくは選択されたアイテムに関連する新しいプロパティを含むことができる。それとは別に、表示されたメタデータは、選択されたアイテムのそれぞれからのメタデータの回転サンプルを含むことができる（例えば、１つの選択されたアイテムのメタデータから次の選択されたアイテムのメタデータへ３０秒毎に循環する）。すべてのアイテムの選択から生じるメタデータの表示は、空選択から生じるメタデータの表示と同一である可能性がある。

図５７は、シェルブラウザ内に表示されるアイテムに関連付けられているユーザ修正可能メタデータを格納するデータ構造体２８００のブロック図である。データ構造体２８００は、アイテムの名前を示すタイトルフィールド２８０２を含む。非ファイルアイテムの場合、タイトルフィールド２８０２は、リストビュー内でそのアイテムをアルファベット順に並べるために使用されるプロパティの名前を含むことができる。データ構造体２８００は、表示されているアイテムに関連付けられている１つまたは複数のプロパティを含むユーザ編集可能プロパティフィールド２８０４を含み、ユーザの編集可能な特性は、表示された項目とともにシェルブラウザ中に表示される。データ構造体２８００は、表示されているアイテムに関連付けられている、シェルブラウザ内に表示するのに値する読み取り専用プロパティを格納する読み取り専用プロパティフィールド２８０６を適宜含むことができる。シェルブラウザ内でメタデータ表示のサイズ制約条件が与えられた場合、フィールド２８０４および２８０６内のプロパティの数を制限することができる。したがって、データ構造体２８００は、適宜、「すべてのプロパティ」フィールド２８０８を含むことができ、これは、表示されているアイテムに関連付けられているプロパティまたはメタデータすべてを含む場所（例えば、プロパティページ）へのリンクまたはポインタを格納する。もちろん、「すべてのプロパティ」フィールド２８０８は、フィールド２８０４および２８０６が表示されているアイテムに関連付けられているプロパティすべてを含む場合には、必要ないであろう。データ構造体２８００は、ファイルシステムまたはシェルなどにおいて１つまたは複数のコンピュータ可読媒体上に格納され、これによりシェルブラウザ内に、リッチストレージビューを表示し、ユーザエクスペリエンスを向上させることができる。

本発明では、従来のシェルブラウザでは可能でなかった多くのシナリオを実現することができる。第１の実施例では、学生は、プレビューペインを使用してプロジェクトを管理することができる。学生が取り組んでいるプロジェクトの一部として新しいドキュメントを取得した場合、学生は、それらのドキュメントを自分のドキュメントライブラリ内で選択し、エディットコントロールを使用することによりドキュメント作成者の名前およびプロジェクトの名前をキーワードフィールドに入力することができる。すると、新しいドキュメントがお気に入りビュー「ＤｏｃｕｍｅｎｔｓＧｒｏｕｐｅｄｂｙＫｅｙｗｏｒｄａｎｄＬｉｓｔｅｄｂｙＡｕｔｈｏｒ」内に出現する。本発明により使用できるようになる新しいシナリオの第２の実施例は、従業員が来たる広告キャンペーン用の資料を探すことを伴う。従業員は、シェルブラウザを使用して自分の雇い主の写真のストックコレクションにざっと目を通すときに、２、３の画像を選択し、プレビューペインから、新しいキーワード「Ｓｕｍｍｅｒ２００３Ｃａｍｐａｉｇｎ」を追加する。複数選択についてメタデータを更新している場合、従業員は、次いで、キーワードでピボットし、１つのグループにまとめられた「Ｓｕｍｍｅｒ２００３Ｃａｍｐａｉｇｎ」ファイルのすべてを表示することができる。本発明を利用する他のシナリオの多くは、当業者にとっては明白なことであろう。

図５８〜６６は、複数のアイテムタイプを表す複数のアイテムを表示するように構成されているシェルブラウザ内のオブジェクトプレビューアの機能を拡張するシステムおよび方法に関係する図である。以下でさらに詳しく説明されるが、既定のプレビューアおよび拡張性メカニズムを備えるシェルブラウザが提供される。既定のプレビューアは、複数のアイテムタイプについて標準レベルの機能を備える。拡張性メカニズムを使用することにより、複数のアイテムタイプのうちの１つまたは複数について既定のプレビューアが与える標準レベルを超える機能が使用可能になる。

図５８は、他の非画像ファイルおよびフォルダを見るために使用されるシェルブラウザ環境内でフォルダに格納されている画像を閲覧するための従来技術のグラフィカルユーザインターフェースの概略図である。上述のように、ＰＣなどのコンピューティング環境に格納されているアイテムを容易に識別できる必要性が、劇的に増大する。デジタル画像に関しては、ユーザは、従来、ＰＣ上の特定のファイルを表示するためにサードパーティ製ソフトウェアプログラムを呼び出さなければならなかった。図５８は、従来の解決策である、フィルムストリップを例示しており、これを使用することにより、ユーザは、グラフィカルオペレーティング環境内で与えられたファイルに関連付けられている画像をさらに簡単に表示し識別することができる。フィルムストリップビューの目標は、ユーザがフォルダ内の１つまたは複数の画像ファイルのサイズ変更可能画像をプレビューできるようにする手っ取り早い反復プロセスを与えることにより画像のフォルダを閲覧するときに他のソフトウェアプログラムを使用する必要性を軽減することであった。

図５８は、フォルダ内に格納されている画像を閲覧するためのシステムに関係しており、そこでは、一連のフォルダ画像は、他の非画像ファイルおよびフォルダを表示するために使用される環境（つまり、シェルブラウザ）内でサムネイルの単一の行として表示される。さらに、これにより、ユーザは、選択的にカーソルでサムネイル上をなぞって行くと、ユーザ選択サムネイルの拡大プレビュー画像が表示される。図５８は、ユーザの画面上の代表的なウィンドウの図である。図に示されているように、ウィンドウ３２００は、ヘッダ領域、タスクオプション領域３２０６、プレビューコントロール領域３２０２、キャプションまたはコメント領域、およびフィルムストリップ領域３２０４を含む複数の領域に分けられる。タスクオプション領域３２０６は、他のシステム選択肢とともに、ファイルおよびフォルダの管理に関係する様々なオペレーションを実行するためにユーザにより選択することが可能なタスクの一覧を含む。これらのオペレーションのいくつかは、フィルムストリップ領域３２０４およびプレビューコントロール領域３２０２内の画像に特有である。プレビューコントロール領域３２０２は、ユーザ選択画像の拡大されたプレビュー画像が表示される空間である。この空間は、さらに、ユーザが一連の画像を繰り返すのを手助けするためのナビゲーションアイコンを含むこともきる。プレビューコントロール領域の真下に、様々なテキスト情報を表示するために使用することができるコメント領域のキャプションがある。フィルムストリップ領域３２０４は、与えられたフォルダ内に格納されている画像ファイルのサムネイル画像Ｐ１、Ｐ２、Ｐ３、およびＰ４の単一行を表示するための空間を備える。それに加えて、フィルムストリップ３２０４も、画像ファイル用のフォルダをユーザがスクロールするためのカーソルを含む。フィルムストリップ領域３２０４は、サムネイル画像を混合された向きで含み、表示することができることに留意されたい。例えば、図５８に示されているように、Ｐ１、Ｐ２、およびＰ４は横長であるが、Ｐ３は縦長である。

ユーザは、サムネイル画像の１つを選択することができ、これにより、ユーザサムネイル選択画像のより大きなプレビュー画像をプレビューコントロール領域内に表示することができる。それに加えて、サムネイル画像のユーザ選択でも、ユーザは、選択された画像に関して、タスクオプション領域３２０６に一覧表示されているタスクのうちの１つを選択して実行することができる。第１のコントロールボタンを使用することにより、ユーザは、一方向に繰り返すことで、与えられたフォルダ内のサムネイル画像のそれぞれの拡大された画像をすばやく、連続してプレビューすることができる。つまり、ユーザは、画像をプレビューするためにそれぞれの、およびすべての連続するサムネイル画像を特に「クリック」する必要がないということである。その代わりに、ユーザは、第１のコントロールボタンをただ単に繰り返しクリックするだけでフォルダを通ることができる。第２のコントロールボタンは、類似の反復機能を実行するが、ただし反対方向にのみ実行する。

図５９を参照すると、ウィンドウ３３００は、シェルブラウザのグラフィカルユーザインターフェース用の画面サイズの表示領域を表す。ウィンドウ３３００は、プレビューペイン領域３３０２およびビュー領域３３０４を含む。プレビューペイン３３０２は、プレビューコントロール３３０６、エディットまたはメタデータコントロール３３０８、およびタスクコントロール３３１０を含むことができる。典型的には、プレビューコントロール３３０６を使用すると、ユーザは、プレビューされるアイテム（例えば、選択されたファイル）の画像または他の視覚的表示を得ることができる。プレビューコントロール３３０６は、さらに、ユーザがマウスボタンをクリックすることにより一方のアイテムから次のアイテムへフォーカスをシフトすることができるイテレータボタンなどのコントロールもユーザに提示することもできる。エディットコントロール３３０８は、プレビューされるアイテムのキープロパティの表示を含むだけでなく、さらに、メタデータに対し編集を行うためのコントロールをユーザ向けに表示する。タスクコントロール３３１０は、名前空間および／または選択に関係するタスクを含む。

当業者であれば、本発明では、ウィンドウ３３００内のオプション機能の存在が考えられることを理解するであろう。例えば、メタデータコントロール３２０８およびタスクコントロール３２１０は、本発明の目的に関して本質的な特徴ではない。さらに、ユーザがプレビューペインを開く／閉じることができるようにイテレータボタンまたは表示／非表示ボタンを含むツールバーなどの、図５９に示されていない他の非本質的機能も、本発明の範囲内にある。しかしながら、これらの機能および他のオプション機能を使用することで、ユーザは、シェルブラウザ内で特定のアイテムを簡単に見つけられる。

ビュー領域３３０４は、ファイルシステムファイルまたはフォルダなどの、１つまたは複数のアイテム３３１２のリストビューを備える。「リストビュー」という用語は、コンテナ内のアイテムの列挙またはリストを意味する。「アイテム」および「シェルアイテム」は、本明細書では入れ換えて使用することができ、ファイル、フォルダ、および他のそのようなコンテナ、およびリストビューで表すことができる他の非ファイルオブジェクトを指す。同様に、「シェルアイテム」は、シェルライブラリ内の一アイテムを指す。非ファイルオブジェクトの実施例は、限定はしないが、連絡先、お気に入り、および電子メールメッセージを含むことができる。「シェルブラウザ」および「ファイルシステムブラウザ」という用語は、本明細書では入れ換えて使用することができ、ファイルおよび他の非ファイルアイテムを含む様々な名前空間内をユーザがナビゲートするために使用できるブラウザを指す。

当業者であれば、本発明では、ウィンドウ３３００に対し多数の可能な設計およびレイアウトが考えられることを理解するであろう。例えば、プレビューペイン３３０２は、図５９のビュー領域３３０４の上に示されている。しかし、プレビューペイン３３０２およびビュー領域３３０４を並べて配置するなどの他のレイアウトは、明らかに本発明の範囲内にある。詳細、スライドショー、フィルムストリップ、サムネイル、タイル、アイコンなどのビュー領域３３０４に示されるアイテムについても多数の可能なビューがある。

次に図６０を参照すると、シェルブラウザ内のウェルカムペイン３４００の概略図が示されている。ウェルカムペインは、「空選択」ペインとも呼ばれるが、それは、選択と対立するものとして、名前空間またはコンテナを表すからである。ユーザがまだ選択を行っていない場合、プレビューペイン３４０２は、メタデータ３４０４およびフォルダまたはシェルライブラリに関係するキータスクを表示する。望むのであれば、タスクは、プレミアタスク３４０６および他の関連するタスク３４０８に分けることができる。ウェルカムペイン３４００は、さらに、複数のファイルまたは他のアイテム３４１２を表示することができるビュー領域３４１０も含む。ウェルカムペインメタデータ３４０４は、コンテナ（例えば、ＭｙＰｉｃｔｕｒｅｓ）のプロパティなどの情報を含むことができ、その場合、メタデータ表示は静的である。それとは別に、ウェルカムペインメタデータ３４０４は、コンテナ内アイテムのそれぞれからメタデータのサンプリングなどの情報を含むことができ、その場合、メタデータ表示は頻繁に変化しうる。例えば、メタデータ表示は、３０秒毎のアイテムの循環表示により、一度に１つのアイテムのプロパティに制限することができる。

図６１は、シェルブラウザ内の選択済みペイン３５００の概略図である。ウェルカムペインとは反対に、選択されたペインは、ユーザによる選択を表す。ユーザがコンテナまたはフォルダを選択した場合、選択されたペインは、そのコンテナまたはフォルダに対するウェルカムペインと同一である必要はない。図６１では、選択されたペイン３５００は、プレビューコントロール３５０４、メタデータ表示３５０６、およびタスク表示３５０８を含む、プレビューペイン３５０２を含む。ウェルカムペイン３４００（図６０）のように、選択されたペイン３５００は、さらに、ビュー領域３５１０も含み、そこでは、複数のファイルまたは他のアイテム３５１２を表示することができる。しかし、図６１では、ユーザは、これらのファイルのうちの１つを選択している。したがって、プレビューコントロール３５０４は、選択されたファイルのプレビュー画像を表示し、メタデータ表示３５０６は、選択されたファイルのプロパティを表示し、タスク表示３５０８は、選択されたファイル上での動作に関する関連するタスクのメニューを表示する。

図６２は、本発明の一態様による、図６１の３５００の選択されたペインに類似しているが、拡張コントロールを備える選択されたペインの概略図である。選択されたペイン３６００は、拡張コントロール３６１４を持つプレビューコントロール３６０４、メタデータ表示３６０６、およびタスク表示３６０８を含む、プレビューペイン３６０２を含む。選択されたペイン３６００は、さらに、複数のファイルまたは他のアイテム３６１２を表示することができるビュー領域３６１０も含む。ユーザは、ファイル３６１２の１つを選択しており、それにより、プレビューコントロール３６０４は、選択されたファイルのプレビュー画像を表示し、メタデータ表示３６０６は、選択されたファイルのプロパティを表示し、タスク表示３６０８は、選択されたファイル上での動作に関する関連するタスクのメニューを表示する。

拡張コントロール３６１４は、典型的にはシェルブラウザから得られるものを超える機能のレベルを表す。例えば、図５８および６１に示されているような既定のプレビューペインまたはプレビューコントロールは、ただ単に、選択されたアイテムのプレビューを表示するだけである。アイテムがワードプロセッシングドキュメントまたはスライドプレゼンテーションである場合、既定のプレビュー画像をそのドキュメントまたはスライドデッキの第１ページとすることができる。しかし、プレビュー画像の機能を拡張し、対話性を高めることにより、ユーザは、拡張されたコントロール３６１４をきわめて容易に操作することができ、ドキュメントまたはスライドプレゼンテーションを１ページずつ見て行くことができる。機能レベルをこのように高めることで、ユーザエクスペリエンスが向上するが、それは、開かなくてもプレビューされたアイテムをより包括的に閲覧することができ、１ページ目だけでは容易に識別できないファイルに対し特に有用であるからである。

拡張コントロール３６１４は、シェルブラウザ内の代替えプレビューアの一部としてユーザが利用できるようにすることが可能である。「プレビューア」という用語は、プレビューコントロールまたはプレビューコントロールを含むプレビューペインを指す。本発明では、複数のアイテムタイプ用に標準レベルの機能を備える既定のプレビューアおよびユーザエクスペリエンスを高めるため特定のアイテムタイプ用に異なるレベルの機能を備える１つまたは複数の代替えプレビューアをユーザに提供するシェルブラウザが考えられる。独立系ソフト開発会社（ＩＳＶ）および他のサードパーティ開発会社向けの代替えプレビューアの開発を始めることで、ファイルの関連する態様を容易に識別可能な形で示すことによりファイル閲覧エクスペリエンスに付加価値を付ける。本発明では、限定はしないが、画像ファイル、ビデオファイル、連絡先、ゲーム、スキャナ、ビデオカメラ、ドキュメントファイル、スプレッドシートファイル、スライドプレゼンテーションファイル、図形ファイル、およびタブレットインクファイルを含む、多数のファイルタイプおよび非ファイルアイテムタイプのカスタムプレビューアを考える。

本発明では、従来のシェルブラウザでは可能でなかった多くのシナリオを実現することができ、そのうちの一部が、上で説明されている。サードパーティは、ファイルタイプをのぞき見て、ユーザが理解する意味のある画像を与えることができるコードを用意することによりそのファイルタイプを説明し、実証することが許される。例えば、Ａｐｐｌｅ社では、ＱｕｉｃｋＴｉｍｅ（商標）プレビューコントロールを実装し、ユーザがＱｕｉｃｋＴｉｍｅ（商標）ファイルをシェルブラウザ内で選択した場合に表示されるようにすることが可能である。このプレビューコントロールは、ＱｕｉｃｋＴｉｍｅ（商標）ムービーの最初の５秒分を表示すること、および／またはＱｕｉｃｋＴｉｍｅ（商標）プレーヤーをユーザが起動するためのボタンおよびコントロールを表示することなどの機能を含む、オペレーティングシステムのシェル内の既定のプレビューアを超える代替えまたは拡張機能レベルを備えることが可能である。音楽ファイル用の代替えプレビューアは、類似の拡張機能を備えることが可能である。当業者であれば、代替えプレビューアの拡張機能の可能性に限りがないことを理解するであろう。

図６３は、図６１に類似している選択されたペインの概略図であるが、本発明の一実施形態によりシェルブラウザ内でユーザがメタデータを修正できるようにするコンテキストメニュー３７１４も含む。選択されたペイン３７００は、プレビューコントロール３７０４、メタデータ表示３７０６、およびタスクコントロール３７０８を含む、プレビューペイン３７０２を含む。選択されたペイン３７００は、さらに、複数のファイルまたは他のアイテム３７１２を表示することができるビュー領域３７１０も含む。当業者であれば、本発明の目的に関して、メタデータコントロール３７０６およびタスクコントロール３７０８が本質的な特徴ではないことを理解するであろう。本発明では、ユーザがシェルブラウザ内で特定のアイテムを簡単に見つけられるか、または他の何らかの方法でユーザエクスペリエンスを高めることを手助けする、これらの機能および／または他のオプション機能の存在が考えられる。

図６３のコンテキストメニュー３７１４は、選択されたアイテムについて既定のプレビューアまたは代替えプレビューアのいずれかを選択する選択肢を含む、複数のオプションをユーザに表示する。メニュー３７１４内に示されているジェネリックテキストは、もちろん、プレビューアを選択するためユーザに対し表示することができるタイプのオプションの一実施例にすぎない。コンテキストメニューは、ウェルカムペインを含む、任意のウィンドウ内に表示することができ、これによりユーザエクスペリエンスが向上する。当業者であれば理解するように、本発明では、多数の様々なコンテキストメニューをサポートすることが可能である。本発明の目的に関して、シェルブラウザ内でプレビューアのユーザ選択を可能にする一手段は、コンテキストメニュー３７１４などのコンテキストメニューを表示することである。ユーザは、例えば、プレビューペイン内の対応するテキストまたはオブジェクトをクリックすることにより、コンテキストメニューを呼び出すことができる。

当業者であれば、本発明では、シェルブラウザ内の複数の利用可能なプレビューアから表示されているアイテムについてプレビューアを選択するコンテキストメニュー以外の手段が考えられることは理解するであろう。そのような他の手段としては、ユーザがプレビューコントロールをクリックして選択モードに入る方法がある。同様に、ユーザは、プレビューペイン内で右クリックすることによりプレビューアを選択するよう求められる場合がある。対照的に、ユーザは、プレビューペイン内の関連するテキストまた関連するオブジェクト上をホバリングすることにより選択モードに入ることが可能である。多数の代替え手段が利用可能であり、本発明の範囲内にある。

図６４Ａは、本発明の一実施形態により複数のアイテムタイプをサポートするシェルブラウザ内でユーザがプレビューアを選択できるようにする方法３８００を例示する流れ図である。この方法３８００は、３８０２においてシェルブラウザ内に複数のプレビューアを表示する。これら複数のプレビューアは、複数のアイテムタイプに対する既定のプレビューアおよび特定のアイテムタイプに対する１つまたは複数の代替えプレビューアを含むことができる。これら代替えプレビューアは、サードパーティにより開発されたインストール済みアプリケーションを含むことができる。３８０４で、この方法３８００は、特定のアイテムタイプに対する２つまたはそれ以上のプレビューアの選択肢をユーザに表示する。プレビューアを選択するプロンプトは、シェルブラウザにより（例えば、新しいアイテムタイプを表示した後）、および／またはユーザにより（例えば、何かのオブジェクトをクリックしてコンテキストメニューを表示することにより）起動することができる。特定のアイテムタイプに対するプレビューアの１つを選択することを指示する入力を、３８０６でユーザから受け取った後、この方法３８００は、３８０８で、選択されたプレビューアを特定のアイテムタイプに関連付ける。選択されたプレビューアは、ユーザが別のを選択するまで、使用されたままとなる。しかし、選択されたプレビューアがインストール済みアプリケーションの場合、そのアプリケーションをアンインストールすることでも、選択されたプレビューアの使用が終了する。

図６４Ｂは、本発明の一実施形態により複数のアイテムタイプをサポートするシェルブラウザ内でプレビューアを自動的に選択する方法３８１０を例示する流れ図である。この方法３８１０は、３８１２においてシェルブラウザ内に複数のプレビューアを表示する。これら複数のプレビューアは、複数のアイテムタイプに対する既定のプレビューアおよび特定のアイテムタイプに対する１つまたは複数の代替えプレビューアを含むことができる。これら代替えプレビューアは、サードパーティにより開発されたインストール済みアプリケーションを含むことができる。

３８１４で、システム（ユーザではなく）は、特定のアイテムタイプに対する２つまたはそれ以上のプレビューアから既定のプレビューアを自動的に、また透過的に選択する。システムは、新しいアイテムタイプの表示または代替えプレビューアの存在などのイベントに応答してプレビューアを選択することができる。システムは、論理的規則に基づいて既定のプレビューアを選択するように構成される。例外的な状況の下では、システムは、３８１６で、それらの規則をオーバーライドし、適用可能規則に従って選択されていないであろうプレビューアを選択する決定を下すことができる。例えば、現在の既定のプレビューアよりも新たに使用可能なプレビューアを選択するのが規則である場合、インストール済みアプリケーションは、一般に、既定のプレビューアをインストール済みアプリケーションから現在利用可能なプレビューアに変更する権限を持つことができる。しかし、例えば、シェルブラウザは、新しくインストールされたアプリケーションにより提案された変更をオーバーライドする権利を留保することができる。例えば、新しくインストールされたアプリケーションが問題となっているアイテムタイプの適切な所有者として認証できない場合にオーバーライドが適切なものと考えられる。

いかなる場合も、方法３８１０は、３８１８で選択されたプレビューアを特定のアイテムタイプに関連付ける。選択されたプレビューアは、別のが選択されるまで、使用されたままとなる。しかし、選択されたプレビューアがインストール済みアプリケーションの場合、そのアプリケーションをアンインストールすることでも、選択されたプレビューアの使用が終了する。

次に図６５を参照すると、流れ図は、本発明の一実施形態により複数のアイテムタイプをサポートするシェルブラウザ内でサードパーティプレビューアを使用できるようにする方法３９００を例示している。方法３９００は、３９０２で複数のアイテムタイプに対する既定のプレビューアを持つシェルブラウザを実現することを含む。方法３９００は、さらに、３９０４で複数のアイテムタイプのうちの少なくとも１つに対する代替えプレビューアのサードパーティによる開発のための拡張性メカニズムを実現することを含む。代替えプレビューアは、３９０６でシェルブラウザに登録することができる。インストール済みアプリケーションの場合、登録は、実質的にインストール時に実行されうる。例えば、アプリケーションがＯＥＭによりインストールされている場合、代替えプレビューアは、ユーザがコンピュータを購入する前に登録できる。それとは別に、ユーザは、アプリケーションをローカルまたはリモートにインストールすることができる。

３９０４において、上で参照されている拡張性メカニズムの可能なアプローチが多数ある。このような１つのアプローチは、独立系ソフト開発会社（ＩＳＶ）および他のサードパーティ開発会社が代替えプレビューアを開発できるように一組のアプリケーションプログラムインターフェース（ＡＰＩ）を公開することを伴う。ＡＰＩアプローチでは、ＩＳＶがプレビューコントロールをＩＳＶにより所有されるアイテムタイプに関連付けることができる登録メカニズムが存在する。そのタイプのアイテムまたはファイルがシェルブラウザ内で選択された場合、ＩＳＶのプレビューコントロールは、この登録メカニズムおよび拡張性ＡＰＩを介してインスタンス化される。ＡＰＩは、ビュー内の選択された（複数の）アイテムを表すデータおよびビュー内のアイテムの親コンテナを表すデータをプレビューコントロールに送る。プレビューコントロールは、このデータ上で動作し、ＡＰＩを通じて、シェルブラウザに表示されるユーザインターフェースを実現する。ユーザは、シェルブラウザによりユーザ入力イベント上で動作することができるプレビューコントロールに渡されるキーストロークおよびマウスイベントで入力を行うことができる。

当業者であれば、本発明の拡張性メカニズムを背景として可能なアプローチは多数あることを理解するであろう。ＡＰＩアプローチに加えて、類似の機能は、ユーザ構成、ＨＴＭＬへのポインタ、またはフラッシュのホスティングを介して実現することができる。さらに、拡張性モデルは、選択されたアイテムタイプを所有するただ１つのアプリケーションがただ１つの代替えプレビューアを備えることを必要とする場合がある。つまり、複数の登録された拡張プレビューアが互いに競合するユーザエクスペリエンスの低下を回避するために、利用可能なプレビューアの数を、１つの既定のプレビューアおよび１つの代替えプレビューアに制限することができるということである。しかし、他のモデルだと、選択されたアイテムタイプを取り扱うことができるアプリケーションはもう１つのプレビューアを備えることができる。代替えモデルだと、実行コードで任意のアイテムタイプに対しもう１つプレビューアを用意することができる。また、いくつかの状況では、既定のプレビューアの交換または削除が可能であることが望ましい場合がある。他の多くのモデルが可能であり、本発明により考えられる。

図６６は、１つまたは複数のコンピュータ可読媒体に格納され、シェルブラウザ内の複数のプレビューアを示す情報を含むデータ構造体４０００のブロック図である。データ構造体４０００は、複数のアイテムタイプをサポートする既定のプレビューアを示す情報を含む既定のプレビューアフィールド４００２を含む。代替えプレビューアフィールド４００４は、第１のアイテムタイプに対する代替えプレビューアを示す情報を含む。他の代替えプレビューアフィールド４００６は、その第１のアイテムタイプに対する第２の代替えプレビューアを示す情報を含むことができるか、または第２のアイテムタイプに対する代替えプレビューアを示す情報を含むことができる。当業者であれば、ある場合には、代替えプレビューアフィールドが１つしかなく、他の場合には、２つまたはそれ以上の代替えプレビューアフィールドがありうることを理解するであろう。選択されたプレビューアフィールド４００８は、特定のアイテムタイプのアイテムがシェルブラウザ内に表示された場合に既定のプレビューアを呼び出すか、または代替えプレビューアを呼び出すかを示す情報を含む。フィールド４００６が、第２のアイテムタイプに対する代替えプレビューアを示す情報を含む場合、選択されたプレビューアフィールド４０１０は、第２のアイテムタイプの１つまたは複数のアイテムがシェルブラウザ内に表示されたときに既定のプレビューアを呼び出すか、または代替えのプレビューアを呼び出すかを示す情報を含むことができる。フィールド４００２、４００４、および／または４００６に格納されている情報は、ユーザがそのタイプのオブジェクトを選択した場合に実行するように構成されているプレビューアコードを含むことができる。

^**明示的除外を含むスコープの定義：図３７〜３８を参照しつつ上で説明されているように、ユーザまたはアプリケーションでは、複数の物理的な場所にまたがる１つのスコープを定義することができる。本発明の例示的な態様によれば、ユーザまたはアプリケーションは、さらに、トライステート選択コントロールに関連する曖昧さを除去する高度なユーザインターフェースを使用し、スコープに含まれない特定の場所を識別して、スコープからの除外を定義することができる。したがって、本発明の１つまたは複数の態様を、ユーザがアイテムのスコープ、つまり範囲を、その後のコンピュータオペレーションの影響を受けるものとして定義しているソフトウェア入力コントロールにおいて使用することができる。実施例は、インストールすべきソフトウェア機能のスコープ、または探索すべき記憶場所のスコープを定義することを含む。これらは、例示する目的でたった２つの実施例しか示されておらず、本発明の範囲を制限することを意図していない。

本発明の例示的な態様によれば、図６７を参照すると、スコープ選択コントロール６７０１は、階層的選択ツリー６７０３を用意することに加えて、明示的に包含されるアイテム６７０７および明示的に除外されるアイテム６７０９を識別するバスケット６７０５を含むことができる。スコープ選択コントロール６７０１を使用することにより、ユーザは、バスケットを調べることによりどちらがスコープに含まれ、どちらがスコープから除外されるのかを素早く見て取れる。コントロール６７０１は、さらに、ツリー６７０３との相互作用を通じてスコープに何が含まれるか、または何が除外されるかを指定するユーザ詳細コントロールをそれぞれのフォルダレベルで用意する。以下でさらに詳しく説明する、本発明の様々な態様では、スコープ選択コントロール６７０１は、異なる視覚的指示を使用して、結果のスコープへの包含の異なる状態を示すことができる。バスケット６７０５とツリー６７０３との同期を維持することにより、スコープ選択コントロール６７０１を使用するユーザは、スコープ検査の階層ツリーモードと除外バスケットモードとを素早く切り換えることができ、スコープ作成および修正のための既存のコントロールを大幅に最適化することができる。

スコープ選択コントロール６７０１の動作は、図６８をさらに参照することで説明される。スコープは、ユーザによる除外対象として明示的にまたは暗黙のうちに選択されたアイテムを除いた、スコープ選択コントロール６７０１を介して、明示的に、または暗黙のうちに、ユーザによる包含対象として選択された結果として得られるアイテムの集まりとして定義することができる。明示的な選択は、ユーザが包含または除外対象の特定のアイテムを肯定的に選択することを意味する。暗黙の選択は、明示的に選択された先祖の包含／除外ステータスを継承する肯定的に選択されたアイテムの子孫を指す。アイテムは、ユーザが包含または除外対象としてアイテムを明示的にも暗黙のうちにも選択していない場合に、選択解除されているという。

階層的選択ツリー６７０３は、当技術分野で知られているように、少なくとも１つのサブフォルダを持つそれぞれのフォルダの隣に展開／折り畳みウィジェット６８０３を含むことができる。展開／折り畳みウィジェット６８０３をクリックするか、または他の何らかの方法で選択することにより、ツリーの対応するノードが展開されるか、または折り畳まれる。本明細書で説明されているように、１つの行の他の場所をクリックするか、他の何らかの方法で選択して、その場所の選択を現在のスコープから切り換えることができる。１つの行をダブルクリックすると、包含／除外対象のノードの選択と、１つまたは複数のレベルによる子の展開の両方を実行することができる。ユーザは、選択されたアイテムに対応するチェックボックス６８０５ａ〜６８０５ｋを選択して、アイテムのステータスを切り換えることもできる。

ユーザが、包含対象の行を明示的に選択した場合、スコープ選択コントロール６７０１は、例えば、ディスプレイ画面にインジケータまたはグラフィックを描画またはレンダリングすることにより、アイテムが明示的に含まれることを示す第１の包含インジケータを表示することにより階層内の選択を示すことができる。例えば、図６８において、ユーザは、求められているデジタル写真を探索する探索場所のスコープを定義していることもありうる。チェックボックス６８０５ｂは、「２００３」を明示的に選択していることを示し、これは２００３年に写真を撮ったことを指している。チェックボックス６８０５ｂはチェックされており、対応する行は、ハイライト表示にできる。そのため、チェックされたフォルダ内に含まれるすべてのファイルおよびフォルダは、現在スコープ内に含まれている。明示的に選択されたフォルダがサブフォルダを含む場合、コントロール６７０１は、ユーザに表示するサブフォルダを１つまたは複数のレベルだけ自動的に展開することができる。

「２００３」を明示的に選択した結果、「２００３」のすべての子および子孫が暗黙のうちに選択される。包含対象の暗黙のうちの選択は、アイテムが暗黙のうちに含まれることを示す第２の包含インジケータを提示することにより表すことができる。例えば、図６８では、「２００３」のすべての子孫に対応するチェックボックス６８０５ｃ〜６８０５ｉは、薄いチェックマークを含むように表示され、それぞれの対応する行は、薄いハイライト表示で表示することができる。

ユーザがアイテムを明示的に選択した場合、そのアイテムは、適切な場所のバスケット６７０５にも追加されることができる、つまり含まれるアイテム６７０７（包含）または除外されるアイテム６７０９（除外）のいずれかである。コントロールは、好ましくは、明示的に選択されたアイテムとバスケット内のエントリとの間の１対１の比を維持することができる。例えば、図６８において、ユーザはスコープへの包含対象としてフォルダ「２００３」を明示的に選択している。コントロール６７０１は、階層６７０３で明示的に選択されているようにフォルダ「２００３」をマークすることに加えて、さらに、包含６７０７で明示的に選択されているアイテムの一覧を表示する。ユーザは、包含または除外対象の他の場所をまだ選択していないため、現在、図６８のバスケット６７０５内に他のエントリはない。

本発明の一態様によれば、フォルダは、ユーザが元々ある状況の下で包含または除外の対象として明示的にそのフォルダを選択している場合であっても暗黙のうちに選択されるようにできる。例えば、ユーザは、最初に、フォルダＶａｃａｔｉｏｎを明示的に選択すると仮定する。Ｖａｃａｔｉｏｎフォルダは、明示的に選択され、ＦｉｊｉおよびＥｕｒｏｐｅサブフォルダは、暗黙のうちに選択される。その後、ユーザは、２００３フォルダを明示的に選択すると仮定する。２００３フォルダは、明示的に選択されたというマークが付けられ、Ｖａｃａｔｉｏｎサブフォルダを含むすべてのサブフォルダは、暗黙のうちに選択されたというマークが付けられる。つまり、ユーザがアイテムを明示的に選択するといつでも、サブアイテムはすべて、それの前の選択状態に関係なく、暗黙のうちに選択されたというマークを付けることができる。しかし、本発明の一態様によれば、ユーザがすでにアイテムを明示的に選択しているという事実は、後から利用できるように記憶できる。例えば、ユーザは、２００３フォルダは、第１の場所で誤って選択されたということを認識して、２００３フォルダを後で選択解除する。２００３フォルダのサブアイテムはそれぞれ、前の状態に戻り、したがって、Ｖａｃａｔｉｏｎフォルダは、明示的に選択されている状態に戻る。ユーザがスコープの編集を完了し、後で使用できるようにスコープを保存しておきたい場合、それぞれの選択を含むスコープを保存するか、または最終的な保存済みスコープに関係のない選択についての情報を含まないスコープを保存することができる。例えば、上記の例では、ユーザがＶａｃｔｉｏｎフォルダを最初に選択したという事実は、スコープが保存されると破棄される場合があるが、それは、Ｖａｃｔｉｏｎフォルダの前の選択が最終的な保存済みスコープに関係しない場合があるからである。

さらに図６９を参照すると、ユーザにより、フォルダが除外対象として選択された場合、そのフォルダおよびすべての子孫は、スコープから削除される。ユーザは、フォルダを除外対象として選択するには、そのフォルダを包含対象として暗黙のうちに選択した後明示的に選択する、つまり、ユーザがそのフォルダを選択解除する。ユーザが、除外対象の行を明示的に選択した場合、スコープ選択コントロール６７０１は、アイテムが明示的に除外されることを示す第１の除外インジケータを表示することにより階層内の選択を示すことができる。例えば、図６９では、チェックボックス６８０５ｆは、「Ｅｘ−Ｇｉｒｌｆｒｉｅｎｄｓ」フォルダをスコープから明示的に除外したことを示すが、例えば、ユーザが元の恋人の写真を検索結果に含めたくない場合である。チェックボックス６８０５ｆは、薄くないＸのマークが付けられ、対応する行のハイライト表示が削除される。したがって、明示的に除外されたフォルダ内に含まれるすべてのファイルおよびフォルダは、スコープから除外される。明示的に除外されたフォルダがサブフォルダを含む場合、コントロール６７０１は、サブフォルダを自動的に折り畳み、そのため、明示的に除外されたフォルダのみをユーザに表示することができる（子孫なしで）。ユーザが、その後、明示的に除外されたフォルダに対応するウィジェットを展開した場合、子孫を第２の除外インジケータとともに表示し、暗黙の除外を示すことができる。

除外対象として「２００３」を明示的に選択した結果、「２００３」のすべての子および子孫が暗黙のうちにスコープから除外される。除外対象の暗黙のうちの選択は、アイテムが暗黙のうちに除外されることを示す第２の除外インジケータを提示することにより表すことができる。例えば、図６９では、「Ｅｘ−Ｇｉｒｌｆｒｉｅｎｄｓ」のすべての子孫に対応するチェックボックス６８０５ｇ〜６８０５ｉは、薄いＸマークを含むように表示され、それぞれの対応する行のハイライト表示は削除することができる。

ユーザが明示的にアイテムを除外した場合、アイテムは、バスケット６７０５の除外６７０９に追加され、それぞれの明示的な除外を明示的に含まれるアイテムのプロパティとして示すことができる（それぞれの除外は、さらに、適宜、包含のプロパティとして格納することができる）。例えば、図６９において、ユーザは、スコープからの除外対象としてフォルダ「Ｅｘ−Ｇｉｒｌｆｒｉｅｎｄｓ」を明示的に除外した。コントロール６７０１は、階層６７０３で明示的に除外されているようにフォルダ「Ｅｘ−Ｇｉｒｌｆｒｉｅｎｄｓ」をマークすることに加えて、さらに、包含６７０７で明示的に含まれるフォルダ２００３に対応する除外リスト６７０９内の明示的に除外されたアイテムの一覧を表示することができる。

ユーザが明示的に含まれているアイテムを明示的に選択した場合、コントロール６７０１は、アイテムの明示的な再選択を解釈し、そのアイテムがスコープ内に含まれることに関してユーザの考えが変わったことを示すことができる。しかし、再選択されたアイテムを明示的に除外する代わりに、コントロール６７０１は、単純に、再選択されたアイテムから明示的包含ステータスを削除するとともに、任意の子孫の暗黙の包含をも削除することができるが、ただしその際に、再選択されたアイテムまたはその子孫のどれかを明示的にまたは暗黙のうちに除外されたものとしてマークすることを行わない。これらのアイテムは、未選択状態に戻る。それに対応して、アイテムは、バスケット６７０５から削除され、ツリー６７０３内のアイテムに対応するチェックボックスは、その最初のブランク状態に戻ることができ、ハイライト表示は、削除することができる。そのため、本発明の例示的な一態様によれば、前に暗黙のうちに含まれたアイテムのみが、スコープから明示的に除外できる。

さらに図７０を参照すると、ユーザは、前に暗黙のうちに除外された場所からのアイテムを明示的に含むことができる。図７０では、ユーザは、例えばユーザが自分の元の恋人であるＣｉｎｄｙとまだ友達であるが、他の元の恋人の写真をスコープ内に含めたくないため、スコープ内にフォルダ「Ｃｙｎｄｙ」を含める決定を下した。包含対象としてフォルダ「Ｃｉｎｄｙ」を明示的に選択した後、スコープ選択コントロール６７０１は、最初に、チェックボックス６８０５ｇ内の包含インジケータを示し、対応する行をハイライト表示する。フォルダＥｘ−Ｇｉｒｌｆｒｉｅｎｄｓ、Ｊａｎｅｔ、およびＫａｒｅｎの暗黙の除外ステータスは、それらのフォルダはＣｉｎｄｙの子孫ではなく、むしろそれぞれ先祖および同格要素であるため、変更されない。フォルダＣｉｎｄｙの明示的な包含により、スコープ選択コントロール６７０１では、対応するアイテムを包含６７０７内のバスケット６７０５に追加する。

ツリー６７０３との対話操作に加えて、ユーザは、スコープを表示または修正するためにバスケット６７０５を同様に対話操作することができる。バスケットは、好ましくは、それぞれの明示的に選択されたアイテムのアイテム名、場所、およびアイコンを表示する（必要に応じて異なる情報を表示することもできるが）。バスケットの物理的な表示サイズのせいで、アイテムのパス全体を表示できない場合には切り詰めることができ、例えば、図６９に表示されているように「．．．」となる（αブレンディングを代わりに使用することもできる）。それとは別に、切り詰めは、図７０のパスの真ん中で省略記号により例示されているように、パスの真ん中で行うことができる。コントロール６７０１では、所望のアルゴリズムに従って切り詰めるパスの部分を決定することができる。例示的な一実施形態では、コントロール６７０１は、直近の親を最初に表示し、ルート（例えば、Ｃ：＼、Ｄ：＼など）を２番目に表示し、最後にフルパスが表示されるか、または割り当てられた空間が満杯になるまで、パスに親の順番どおりの先祖を書き込んでゆくという優先度で切り詰めを決定することができる。

例えば、ツリー６７０３の現在のビューにまだ見えていなければ、バスケット６７０５内のフォルダの選択により、ツリー６７０３は自動的に展開および／またはスクロールし、選択されたフォルダを表示するようにできる。ツリーは、さらに、選択されたフォルダを自動的に展開して、選択されたフォルダのサブフォルダを表示することもできる。明示的な除外は、明示的に含まれるアイテムの多値プロパティ（ＭＶＰ）として定義することができ、その場合、同じ明示的に含まれるアイテムに対応する複数の除外があっても、バスケットに追加の行が入るのではなく、むしろ、明示的に含まれるアイテムに対応する除外に他の値が加えられる。例えば、図７１のビューは、ユーザがフォルダ「２００３」を明示的に包含し、次いで、フォルダ「Ｆｉｊｉ」を明示的に除外し、最後に、フォルダ「Ｊａｎｅｔ」を明示的に除外することで生じる。ユーザが、バスケット６７０５内の「２００３」からの除外の上でマウスポインタ７１０１をホバリングすると、コントロール６７０１は、ユーザがそれらの除外を調べられるように、省略されていないＭＰＶ７１０３を表示することができる。包含の場合のように、ユーザがバスケット６７０５から除外を選択した場合、コントロール６７０１は、ツリー６７０３を選択されたアイテムに自動的にナビゲートすることができる。

ユーザは、スコープの定義または修正を完了すると、後から使用するためスコープを、例えば記憶媒体２２、２４、３９、３０などに保存することができる。スコープを保存することは、ユーザが一致基準を変えながら同じスコープ上で繰り返し検索を実行する場合に有用である。スコープは、保存されるときに、明示的包含の順序付きリストとして保存することができ、明示的除外のリスト中のそれぞれのエントリは０個またはそれ以上の明示的除外をＭＶＰとして持つ。したがって、リストは、ユーザによるすべての明示的な選択を格納することができる。しかし、ユーザが最初にアイテムを明示的に選択し、その後、その同じアイテムを明示的に選択解除した場合には、アイテムはリストに含まれないことがある（例えば、第１の場所で間違って選択されたことを認識する）。この方法で、適切なスコープは、順序付きリストに基づいて再作成することができ、スコープの使用毎に追加される明示的に含まれるか、または除外されたアイテムの子孫である、新しいフォルダは、スコープの再利用時に適宜考慮される。

例えば、本発明の例示的な態様により、スコープは、拡張マークアップ言語（ＸＭＬ）ファイルとして格納することができる。以下のＸＭＬは、明示的包含および明示的除外を識別するスコープを例示しており、それぞれの除外は、包含のプロパティとして格納され、順序は、ＸＭＬファイルないにデータが格納される順序により本質的に保持される。

図７２は、上述のスコープ選択コントロール６７０１を使用してスコープを生成する方法を例示している。ステップ７２０１において、ユーザは、ツリー６７０３内のアイテムを明示的に選択する。ステップ７２０３で、スコープ選択コントロール６７０１は、明示的に選択されたアイテムがスコープ内に含まれるようにすでに設定されているかどうかを判定する。そうであれば、方法は、ステップ７２０９に進む。そうでなければ、ステップ７２０５のスコープ選択コントロール６７０１は、明示的に選択されたアイテムがスコープから明示的に除外されたものとして現在設定されているかどうかを判定する。もしそうであれば、このステップ７２０６で、スコープ選択コントロールは明示的に選択されているアイテムのそのステータスを明示的に選択されているアイテムの親のステータスに戻す。ステップ７２０５で、明示的に選択されたアイテムが現在明示的に除外されていない場合（アイテムが暗黙のうちに除外されるか、または選択されていることを意味する）、ステップ７２０７のスコープ選択コントロールは、明示的に選択されたアイテムをスコープに含め、明示的に選択されたアイテムのすべての子孫を暗黙のうちにスコープ内に含める。次に、ステップ７２０８において、スコープ選択コントロール６７０１は、明示的に選択されたアイテムをバスケット６７０５の包含６７０７に追加する。

ステップ７２０９において、スコープ選択コントロール６７０１は、すでに含まれているアイテムがすでに明示的に含まれているか、またはすでに暗黙のうちに含まれているかを判定する。アイテムがすでに暗黙のうちに含まれていた場合、ステップ７２１１で、スコープ選択コントロール６７０１は、明示的に選択されたアイテムを明示的に除外し、明示的に選択されたアイテムのすべての子孫を暗黙のうちに除外する。次に、ステップ７２１３において、スコープ選択コントロール６７０１は、明示的に選択されたアイテムを、明示的に選択されたアイテムの最も近い明示的に含まれている先祖に対応するバスケット６７０５の包含６７０９に追加する。

ステップ７２０９において、明示的に選択されたアイテムがすでに明示的に含まれていた場合、ステップ７２１５において、スコープ選択コントロール６７０１は、明示的に選択されたアイテムに対する包含ステータスを削除し、明示的に選択されたアイテムのすべての子孫をそれの前の状態に戻す。ステップ７２１７において、スコープ選択コントロールは、明示的に選択されたアイテムを、対応する除外６７０９とともに、包含６７０７から削除する。当業者であれば、アイテムが選択解除されたときの挙動は、変化しうることを理解するであろう。例えば、明示的に含まれるか、または除外されたアイテムは、先祖が選択解除された場合に選択解除状態に戻らないこともある。

ステップ７２０６、７２０８、７２１３、または７２１７の後に、ステップ７２１９において、スコープ選択コントロールは、まだ修正が望まれているかどうかを判定する。この判定は、ユーザがさらに多くの修正を行うことを特に要求せず、その代わりに、単にステップ７２０１に進んで別の修正を行うか、他方、ユーザがステップ７２２１で「Ｓａｖｅ」または「Ｓｅａｒｃｈ」ボタンを選択して、ユーザがスコープの定義を完了したこと、およびコンピュータ２０はユーザがスコープを定義した目的が何であれスコープを使用することができることをコンピュータ２０に示すという点で、暗黙のうちに行うことができる。スコープは、バスケットにより定義された、対応する明示的除外を含む、明示的に含まれるアイテムの結果として得られる順序付きリストであるということができる。

当業者であれば、１つまたは複数のステップは任意に選べること、およびステップは、類似の結果が得られるように再配列することができることを理解するであろう。さらに、上述の説明は、スコープ選択コントロール６７０１が何らかのアクションを実行するか、または何らかの決定を下すことを示している場合、スコープ選択コントロール６７０１は、コンピューティングデバイス２０に格納され、プロセッサ２１により実行される、ソフトウェアまたはハードウェア命令などの、制御ロジックの制御に従って、またはその制御の下で、動作している可能性がある。

^**静的リストの操作のためのリストペイン：図５１〜６６を参照しつつ上で説明されているように、シェルブラウザ（ファイルエクスプローラ、エクスプローラ、またはファイルブラウザとも呼ばれる）は、ファイルおよび非ファイルアイテム間をナビゲートするために使用することができる。追加の例示的な実施形態は、図７３〜７６に関して説明される。図７３は、リストペイン７３０３、主ビューペイン７３０５、およびナビゲーションペイン７３０７を持つエクスプローラフレーム７３０１を例示している。エクスプローラフレーム７３０１は、さらに、ブレッドクラムバー７３０９（それとは別に仮想アドレスバーとも呼ばれる）、メニューバー７３１１、検索ウィンドウ７３１３、および情報またはプレビューペイン７３１５などの他の特徴も含むことができる。リストペイン７３０３は、上述のバスケットコントロール２０１と類似の挙動を示しうる。したがって、リストペインは、主エクスプローラウィンドウのコンテキスト内のコレクション、例えば静的リストをユーザが操作するため使用可能な単純なインフレームモジュールである。

したがって、例えば、ユーザは、ｔｏ−ｄｏリストを作成し、リストペイン７３０３内のｔｏ−ｄｏリストを開き、主ビューペイン７３０５を介してシステムシェルを閲覧しつつ複数のアイテムをｔｏ−ｄｏリストに追加し、その後、リストペイン７３０３を閉じ、改訂されたｔｏ−ｄｏリストを適宜保存することができる。他の実施例として、ユーザは、主ビューペイン７３０５内に順に表示される複数のフォルダにまたがって格納されているいくつかの写真を選択し、選択された写真をリストペイン７３０３内に入れ、コンテキストメニューまたはメニューバー７３１１から「ｐｒｉｎｔ」を選択することによりリストペイン７３０３内のすべての写真を選択することにより写真のコレクションを印刷することができる。ユーザは、望むとおりに写真の新しいコレクションを保存するか、または保存せずに、リストペインを閉じることができる。

ユーザは、メニューバー７３１１内の「Ｗｉｎｄｏｗ」メニューを選択し、次いで、「Ｗｉｎｄｏｗ」メニュー（図に示されていない）から「ＬｉｓｔＰａｎｅ」を選択することによりリストペインを開くことができる。「Ｗｉｎｄｏｗ」＞「ＬｉｓｔＰａｎｅ」を再び選択して、リストペイン７３０３の表示ステータスを切り替えることができるが、これは、「Ｗｉｎｄｏｗ」＞「ＬｉｓｔＰａｎｅ」と同等である。いくつかの実施形態では、キーボードショートカット、例えば、Ｃｔｒｌ−Ｋを使用して、リストペイン７３０３を切り替えることができる。ユーザがメニューバー７３１１から「Ｗｉｎｄｏｗ」＞「ＬｉｓｔＰａｎｅ」を選択するか、またはキーボードを介してＣｔｒｌ−Ｋを入力する行為は、ユーザが新しい永続的静的リストを作成したいのかどうか、またはユーザが間近の当面のタスクについて少数のアイテムを集めて、次いでリストを保存せずにリストペインを閉じるのかどうかに関して曖昧な場合がある。そのため、本発明の一実施形態によれば、ユーザがリストペイン７３０３を開いたときに、リストペイン７３０３内のオブジェクトは、少なくとも一時的に格納される。ユーザが静的リストを明示的に保存せずにリストペイン７３０３を閉じると、静的リストの内容は破棄される。しかし、ユーザは、静的リストを保存して、静的リストを永続的にし、例えば、静的リストを後で再利用するか、他のユーザとその静的リストを共有することなどを行うことができる。一実施形態では、一時記憶域は、ＬｏｃａｌＡｐｐＤａｔａ＼Ｗｉｎｄｏｗｓ（登録商標）＼ＴｅｍｐｏｒａｒｙＬｉｓｔ．ｗｐｌとすることができる。ユーザによって開かれたそれぞれのエクスプローラウィンドウは、ユーザが適宜肯定的に静的リストを保存するまで一時静的リストを格納することを目的としてそのウィンドウに関連付けられている一意的な一時記憶域を持つことができる。

ユーザは、バスケット内の他のリストが使用されるのと同じ方法で一時リストを使用することができる。アイテムは、追加、削除、順序変更などを行うことができる。リストペイン７３０３が開いている場合、ユーザは、主ビュー７３０５内の任意のアイテムを右クリックし、コンテキストメニュー（図に示されていない）「ＡｄｄｔｏＬｉｓｔＰａｎｅ」を選択するか、またはメニューバー７３１１を表示することができ、これにより、そのアイテムがリストペイン７３０３内のリストに新しい最後のアイテムとして挿入される。ユーザは、さらに、アイテムをリストペイン７３０３内にドラッグ＆ドロップすることもできる。しかし、これは一時リスト（Ｗｉｎｄｏｗｓ（登録商標）（著作権）ＭｅｄｉａＰｌａｙｅｒ内の「ｎｏｗｐｌａｙｉｎｇ」と似ている）なので、このリストの内容は、ユーザがフレーム７３０１を閉じるか、またはリストペイン７３０３を閉じると破棄される。リストペイン７３０３またはフレーム７３０１を閉じる前にリストペイン内に保存されていない内容がある場合、システムは、ユーザにそのことを適宜通知することができる。

ユーザは、一時リストを保存することを望んでいる場合、タイトルテキストボックス７３１７を選択して、リストペイン７３０３内の内容により識別されるリストに対し名前を入力し、「Ｓａｖｅ」アイコン７３１９を選択することができる。「Ｓａｖｅ」アイコン７３１９を選択すると、共通ファイルダイアログが呼び出され、これにより、ユーザは、静的リストを格納する場所を選択することができる。それとは別に、ユーザは、リストバックグラウンドにおいてコンテキスト選択（例えば、右クリック）し、コンテキストメニューから「Ｓａｖｅ．．．」を選択して、共通ファイルダイアログを呼び出すことができる。

ユーザは、さらに、メニューバー７３１１から「Ｆｉｌｅ」＞「Ｎｅｗ」＞「Ｌｉｓｔ」と選択することによりリストペイン７３０３を開くこともでき、これにより、リストペイン７３０３は、すでに閉じられている場合に開く。リストペインがすでに開いている場合、「Ｆｉｌｅ」＞「Ｎｅｗ」＞「Ｌｉｓｔ」と選択すると、システムは、現在リストペイン７３０３内にあるアイテムを破棄し、新しい一時リストを作成する。新しい一時リストは、ユーザが「Ｖｉｅｗ」＞「ＬｉｓｔＰａｎｅ」を選択することにより作成されたリストとして振る舞い、同じ永続性モデルを持つ（つまり、ユーザが最初に保存しない限り、閉じるときに破棄される）。

ナビゲーションペイン７３０７は、リストノード７３２１を含むことができ、これは、ユーザにより作成されたすべての静的リスト、またはユーザにより作成され特定の場所に格納されているすべての静的リストを表すことができる。ユーザは、リストノード７３２１をコンテキスト選択し、コンテキストメニューから「ＮｅｗＬｉｓｔ」を選択することにより新しいリストを作成することもでき、その結果、フレーム７３０１では、既定のタイトルが、例えば、複数の既定の名前付き新規リストが作成されている「ＮｅｗＬｉｓｔ」または「ＮｅｗＬｉｓｔ（ｎ）」である空のリストを含むリストペイン７３０３を開く。適宜、ナビゲーションペイン７３０７では、新しく作成されたリストのリスト名は、自動的に編集モードに入るか、および／またはユーザは、リストペイン７３０３内のタイトルテキストボックス７３１７内のリスト名を編集することができる。新しいリストは、与えられたエクスプローラフレーム７３０１の既定の保存場所に作成される。

本発明のいくつかの態様によれば、リストタイトルは、常に、編集可能としてよく、リストペイン７３０３内のリスト用の新しい名前を入力することができ、その結果、システムでは記憶装置デバイス上のリストの名前を変更する。ユーザが、すでに永続化されているリスト（つまり、リストはすでに保存されている）に対する「ｓａｖｅ」ボタン７３１９を選択した場合、システムは、ユーザが「Ｓａｖｅａｓ．．．」オプションを選択したかのように実行することができる。それに加えて、ユーザがメニューバー７３１１から「Ｆｉｌｅ」＞「ＮｅｗＬｉｓｔ」と選択した場合、ナビゲーションペインの外観状態にいっさい変化がない場合がある。つまり、リストノード７３２１が、現在展開されている場合、新しいリストが、リストノード７３２１の下に階層的に表示されるが、ただし、空き領域があるか、またはアルファベット順挿入で表示することができると想定する。しかし、リストノード７３２１が現在展開されていない場合、ナビゲーションペイン７３０７に、目立った変化はない。リストペイン７３０３内のリストが空の場合、リストペイン７３０３は、リストを作成する方法をユーザに指示するメッセージ、例えば、「Ａｄｄｆｉｌｅｓｔｏｔｈｉｓｌｉｓｔｂｙｄｒａｇｇｉｎｇｔｈｅｍｉｎｈｅｒｅ」を表示することができる。

ユーザは、リストペインヘッダ７３２０をダブルクリックするか、または他の何らかの方法で選択して、リストペイン７３０３を閉じて、主ビュー７３０５内にリスト内容を表示することができる。ユーザは、それとは別に、Ｓｈｉｆｔキーを押しながらダブルクリックすることで、リストペイン７３０３内に表示されている一覧をルートとする新しいエクスプローラウィンドウを開くことができる。ユーザは、リストペイン７３０３（図に示されていない）の一番上の右隅の「Ｘ」（または相当物）を選択すると、主ビュー７３０５内でナビゲートすることなく、リストペイン７３０３を閉じることができる。永続的なリストがバスケット内で編集される場合、明示的な保存モデルがあり得、その場合、ユーザがリストペイン７３０３またはエクスプローラフレーム７３０１を閉じるか、またはリストペインを他のリストにナビゲートすると、システムは、ユーザに対し、変更を保存したいかどうかを問い合わせる明示的なダイアログボックスを表示する。

リストペイン７３０３内のアイテムは、主ビュー７３０５内のアイテムと同様の挙動を示すことができる。例えば、リストペイン７３０３内の与えられたアイテムをクリックするかまたは選択することで、そのアイテムが選択される。フォーカスが主ビュー７３０５とリストペイン７３０３との間を移動する場合、主ビュー７３０５とリストペイン７３０３は両方とも、引き続き、それの選択状態を反映する（どちらのペインに入力フォーカスが当たっていてもソフト選択状態を使用して）。しかし、正確には１つのペインにしかフォーカスがなく、これは、矢印キーがどのような作用をするのかに関するユーザに対する視覚的な手掛かりとしてビュー内に反映される。フォーカスがリストペイン７３０３内にある場合、同じ選択およびキーは、主ビュー７３０５内と同様に動作し、Ｃｔｒｌ＋Ａですべて選択、矢印キーで移動などの動作となる。

上述のシステムを使用することで、ユーザは、リストペイン７３０３に、またその中で、ドラッグ＆ドロップすることができ、それにより、ユーザは、静的リスト内のオブジェクトの追加、削除、順序変更、および他の何らかの形の操作を行うことができる。バスケットにドラッグした場合、システムは、ユーザに対し、様々な視覚的手掛かりを表示することができる。第１に、エクスプローラフレームは、リストペイン７３０３の外縁をハイライト表示し、リストペイン７３０３がアクティブなドロップ先であることを示すことができる。リストペインは、さらに、一覧内に複数のアイテムがある場合に挿入バー（図に示されていな）を表示することもできる。ユーザが主ビュー７３０５をナビゲートすると、リストペイン７３０３は、与えられた一覧をルートにしたままであり、ユーザは、ウィンドウ間を行き来する何回もの単調なドラッグ＆ドロップ作業に従事せずに、主ビュー７３０５内でファイルシステムをナビゲートすることにより、コレクションの内容を増やすことができる効率のよい、単純なメカニズムを提供される。

さらに図７４を参照すると、ユーザがリスト７４０１を作成し、保存した後、ユーザは、永続化されたリスト７４０１をコンテキスト選択してコンテキストメニュー７４０５を表示し、コンテキストオプション７４０３を選択してリストペイン７３０３内のリストを開くことにより、リストペイン７３０３内の永続化されたリスト７４０１を開き直すことができる。ユーザは、リストペインヘッダ７３２０内のリストアイコン６２３を選択し、リストペイン７３０３内で現在編集されているリストの内容全体を選択することができる。ユーザは、リストアイコン６２３をコンテキスト選択（例えば、右クリック）して、コンテキストメニュー７４０５を表示することができる。適宜、ユーザは、アイコン６２３を右クリックして、新しい場所にドラッグし、リストの格納場所を移動するか、または新しい場所にリストのコピーを作成することができる。

本発明の一態様によれば、静的リストは、例えば、「Ｐｒｉｎｔｐｈｏｔｏｓ」、「ＢｕｒｎＣＤ」、「Ｍａｋｅｍｏｖｉｅｆｒｏｍｖｉｄｅｏｃｌｉｐｓ」などの、その静的リストに関連付けられているタスクを持つことができる。このような実施形態では、タスクの選択により、タスク特有のコントロールを含むブランクリストを開くことができる。それとは別に、ユーザがタスクをすでに関連付けられている静的リストを開く場合、リストペイン７３０３は、特定のタスクに応じてタスク特有のコントロールを自動的に表示することができる。リストペイン７３０３のユーザ対話操作は、同じであるが、ただし、タスクベースモードに入っている間ユーザが突き進むことになる総合的な最適化されたタスクがある。

そこで、例えば、図７５は、ユーザがリストペインを開く前のエクスプローラフレーム７５０１の一部を例示している。エクスプローラフレーム７５０１は、タスクオプション７５０５ａ、７５０５ｂ、および７５０５ｃを持つメニューバー７５０３を備える。タスク７５０５ｃは、特に、ＣＤを焼くことを指す。タスク７５０５ｃおよび７５０５ｂは、例えば、写真を印刷すること、およびビデオクリップから動画を作製することを、それぞれ意味していてもよい。タスク７５０５ｃを選択した後、エクスプローラフレームは、図７６にさらに例示されているように、統合されたタスク特有のコントロール７６０１を含むリストペイン７３０３を開く。この実施例では、タスク特有のコントロール７６０１は、ユーザが静的リストの内容をＣＤまたは他の光媒体もしくは記憶デバイスに書き込むオプションを備えている。このようなシナリオでは、システムは、識別されたオブジェクトの実際のコピーがＣＤまたは他の媒体に書き込まれ、コレクションが静的リストである場合には単純なショートカット、またはポインタがオブジェクトに書き込まれないことを知るロジックを備えることができる。リストペイン７３０３内のリストにより識別されるオブジェクトは、静的リストにより指定された順序で、該当する場合には注釈とともに、書き込まれることができる。

タスクベースリストは、さらに、一時的であってよく、ユーザが最初に上述のようにコレクションを保存していない限り、ペイン７３０３またはフレーム７５０１が閉じたときに破棄されてかまわない。ユーザがメインタスク（ｂｕｒｎ、ｐｒｉｎｔなど）を完了した後、タスクコントロール７６０１は、「Ｓａｖｅ」ボタンに自動的に切り替わり、ユーザがリストペイン７３０３またはフレーム７５０１を閉じたときに保存しないとタスクベースリストを失うことになることを再度強調することができる。

リストペイン７３０３は、数え切れないほどの方法で、上述の機能をそのまま備えつつ、詳細、書式、などを表示する無数に存在する変更形態により表示することができる。当業者であれば、例示的なビューの以下の説明は、単に一実施例を示すものであり、請求項で定められているような本発明の範囲を限定しないことを理解するであろう。芸術的なデザイン、割り当て領域などに応じて、様々な変更形態が可能である。例示的な一実施形態では、リストペインのビュー状態は、対応するメタデータの２つの行とともに３２×３２の点アイコンを含むタイルを表示することができる。アイコンサイズは、システムおよび／またはユーザにより、適宜ロックされるか（したがってＣｔｒｌを押しながらマウスをクリックする操作は無効にできる）、または可変とすることができる。リストペイン７３０３は、適宜、タイルが決して並べて表示されることのないように水平方向サイズ変更を制限することができ、これにより、ユーザは垂直順序を表示することによりコレクション内のアイテムの順序を認知しやすく保持することができる。また、リストペインは、好ましくは、静的リスト内の順序についてのみアイテムを並べ替え、表示する。

様々な追加のオプション機能を、本発明の１つまたは複数の例示的な実施形態に含めることができる。例えば、ユーザがエクスプローラフレームを閉じ、リストペインが名前付きリスト（例えば、明示的な名前を持ち、一時的既定の名前を持たないリスト）上で開いている場合、ユーザが次回類似のエクスプローラフレームを再び開いたときも、リストペインは、そのユーザが前に見ていた一覧を表示したままにできる。フレームが閉じられたときに一時的な破棄すべき一覧がリストペイン内にある場合、エクスプローラフレームが再び開かれたときに、その一覧は破棄されているが、リストペインは開いたまま（空）にできる。

リストペインは、好ましくは、一番右のペインとして開かれ、既定では、幅２００ピクセルとなるように開くことができる。カーソルは、リストペイン７３０３と主ビュー７３０５との間の境界上をホバリングすると、サイズ変更グラバに変わることができる。リストペインには、最小幅、例えば３３ピクセルにサイズ変更することができ、リストペインサイズは、好ましくは、エクスプローラフレーム毎に永続する。リストペインは、さらに、最大サイズ、例えば、主ビュー７３０５でリストペインの成長を許す程度の大きさにサイズ変更することができる（例えば、リストペインは、主ビュー７３０５の最小サイズよりも大きくできない）。当業者であれば、既定のサイズは、２００ピクセル以外とすることができ、またリストペインを一番右のペイン以外の位置に表示できることも理解するであろう。例えば、右から左へ読む言語（大半の西欧諸国のような左から右へではなく）のシステムでは、リストペインは、一番右のペインではなく一番左のペインとして表示することができる。

^**保存ファイルのプレビュー表現：本発明の一態様は、システム上にこれから作成されようとしているファイルのプレビュー表現をユーザに提供することによりファイルの作成時のユーザエクスペリエンスを改善するためのシステムおよび方法に関する。図７７は、ファイルを保存するときにＧＵＩに見られる例示的なビュー７７０１を示している。ビュー７７０１では、ビュー７７０１を生成するために使用される基準に従って存在するファイルを表す、様々な印７７０２が表示されている。このような基準は、ユーザ設定に応じて異なる場合がある。例えば、ビュー７７０１は、システム上の与えられたフォルダの内容を表示するように生成することができる。それとは別に、ビュー７７０１は、与えられたファイルタイプのすべてのファイルを表示することができる（例えば、ＭＩＣＲＯＳＯＦＴＥＸＣＥＬ（商標）Ｗｏｒｋｓｈｅｅｔは図７７の実施例に示されている）。ビュー７７０１は、基準の組合せからも得られる。例えば、ビュー７７０１は、特定のユーザ、または特定のプロジェクトに属す、あるいは特定のフォルダに格納されているすべてのワークシートのビューであってよい。可能な基準は、無限に近く、上ですでに列挙されているものに加えて、ファイルサイズ、作成日、編集日、プロジェクト、所有者、記憶場所、ユーザ、ファイル名などを含む。

ビュー７７０１は、プレビュー表現７７０３、つまりゴーストを表しており、これは、システム上に保存されようとしているファイルを表し、ゴーストは、保存オペレーションは実行された場合に新しいファイルが表示されるＧＵＩの場所をユーザに示し、新しいファイルが保存された場合に見つかる場所またはビューを識別する。図７７の実施例では、ファイルは、名前をつけられておらず、したがって「Ｕｎｔｉｔｌｅｄ」というラベルが付属している。ゴースト７７０３は、まだ技術的にはシステム上の格納されているファイルではないファイルを表していることを示す異なる外観を持つことができる。外観の区別は、透明度または不透明度の設定、色、フォント、ハイライト、または異なる外観を与える他の手段とすることができる。ユーザが、異なるビューをナビゲートするときに（ファイルの格納先の異なるフォルダを選択する）ゴースト７７０３の追跡を失わないようにするために、ゴースト７７０３は、ビュー内の所定の場所に常に表示されるように構成することができる。例えば、図７７に示されているように、ゴースト７７０３は、示されている第１の印として表示されるように構成することができる。外観の違いは、ファイルが選択されたときに生じる変化に対応することができる。例えば、ゴースト７７０３は、既定で選択するようにすることができ、その印は、選択されたオブジェクトを示すためにシステム内で使用される外観を持つことができる（例えば、上述の同じ区別とすることができる）。

ゴースト７７０３は、ビュー７７０１内の他の印として扱うことができる。ユーザは、他の印の場合のように、ゴースト７７０３の選択、ハイライト表示、修正、ドラッグ＆ドロップなどを行うことができる。図７８は、図７７のビュー７７０１の一実施例を示しており、システム上の既存のファイルを表す印７８０１は、ユーザにより選択されている。つまり、印７８０１は、区別できる外観も与えられ、ゴースト７７０３と異なる外観が与えられることができる。しかし、ゴーストは、すでに存在しているファイルに対する印７８０１と関連付けられていないような追加の機能を含むことができる。例えば、ゴースト７７０３は、すでに保存されてはいないファイルに適用可能な機能およびオプションの一意的なコンテキストメニューに関連付けることができる。

ゴーストは、大きな印が使用されるＧＵＩおよびビューに限られない。それとは反対に、これらは、図７９に示されているような一覧表示などの他のタイプのビューにも表示することができる。図７９では、ゴースト７９０１は、保存されようとしているファイルのプレビュー表現をユーザに与える（この実施例では、ファイルは、「ＡｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅ」という名前を付けられている）。

ゴーストは、システム上の複数のアプリケーションにより共有されうる、図８０に示されている、「ＳａｖｅＦｉｌｅ」ダイアログ８００１などのシステムファイルパネルまたは共通ファイルダイアログのＧＵＩに組み込むことができる。ダイアログ／パネル８００１では、ゴースト８００２が出現し、新しいファイルが保存された後にどのように表示されるかを示すプレビュー表現を表示することができる。この実施例では、３つのビュー８００３、８００４、８００５が示されており、１つのビュー８００３はＭＩＣＲＯＳＯＦＴＥＸＣＥＬ（登録商標）ワークシートファイルの印を含み、１つのビュー８００４はＭＩＣＲＯＳＯＦＴＰＯＷＥＲＰＯＩＮＴ（登録商標）プレゼンテーションファイルの印を含み、１つのビュー８００５は、ＭＩＣＲＯＳＯＦＴＷＯＲＤ（登録商標）文書の印を含む。ファイルは、ＭＩＣＲＯＳＯＦＴＥＸＣＥＬ（登録商標）ワークシートとして保存されるように現在設定されているため、ゴースト８００２は第１のビュー８００３内に表示される。この設定は、保存されようとしているファイルの一組のメタデータ（例えば、作成者、ファイルタイプなど）を表示することができる、表示のメタデータ部分８００６に示される。

ユーザは、ゴースト８００２と対話して、保存されようとしているファイルのメタデータを変更することができる。ユーザは、ゴースト８００２を異なるビュー上にドラッグ＆ドロップして、ゴースト８００２のドロップ先の新しいビューのプロパティと一致するように新しいファイルのプロパティを変更することができる。例えば、ゴースト８００２をワークシートビュー８００３からプレゼンテーションビュー８００４にクリックしてドラッグすることにより、ファイルタイプが変更される場合、システムは、メタデータ８００６を自動的に更新して、新しいファイルがタイプ「ｗｏｒｋｓｈｅｅｔ」の代わりにタイプ「ｐｒｅｓｅｎｔａｔｉｏｎ」となることを反映することができる。同様に、メタデータの他の変更も、その印を移動することにより行うことができる。例えば、１つのビューが第１の優先度を持つアイテムに対応し、第２のビューが第２の優先度を持つアイテムに対応する場合、印を第１から第２に移動することで、第２のビューに一致するようにドキュメントの優先度レベルを変更することができる。

メタデータに加えた変更は、さらに、ゴースト８００２内に自動的に反映されるようにもできる。例えば、ユーザがメタデータ８００６に異なるファイル名またはタイプを入力する場合、ゴースト８００２は、新しいメタデータを反映するように、自動的に変化し、および／または再配置して、タイトルを新しい名前に変更し、新しいファイルタイプに基づいて正しいビューになるように自動再配置することができる（例えば、ユーザがタイプをプレゼンテーションに変更した場合にビュー８００４にする）。他の実施例のように、ビューが第１の優先度を示し、優先度がメタデータ内で変更された場合、印は、新しい優先度を持つドキュメントを示す異なるビューに移動されるようにできる。いくつかの場合において、これにより、ゴーストは、ゴースト８００２が画面に現在表示されていないビューまたは場所に再配置された場合に、ユーザの現在の画面から完全に消える。

「ＳａｖｅＦｉｌｅ」ダイアログは、保存プロセスを実行または中止するための「Ｓａｖｅ」ボタン８００７および「Ｃａｎｃｅｌ」ボタン８００８も備えることができる。

図８１Ａおよび８１Ｂは、コンピューティングシステム上でファイルが作成される場合に実行されうる例示的なプロセスを示している。ステップ８１０１で、新しいファイルの保存を開始する要求を受け取り、上述のようにゴーストプレビューを生成して、現在のメタデータを使用してファイルが保存された場合に現在の保存されているファイルの表示のされ方を反映するようにすることができる。新しいファイルには、保存を要求するアプリケーションによりメタデータを初期値として自動的に書き込むことができる。表示は、さらに、編集可能メタデータの表示を含むこともでき、またファイルのプレビューサムネイル画像を含むこともできる。

ステップ８１０２で、システムは、ユーザが現在のビューを変更して、新しいファイルを新しいビューのプロパティに適合させたかどうかをチェックして調べることができる。ビューを変更することは、単純に、表示空間内をナビゲートすること、または与えられた表示の基準を変更することを指す場合があり、また異なる基準を入力することにより（例えば、タイプ＊．ｗａｖのファイルを表示する要求）、および／またはＧＵＩ（例えば、ゴーストを新しいビュー内にドラッグ＆ドロップするか、またはフォルダの印をただクリックしてフォルダに入る）。例えば、ユーザが、上述のように、異なるタイプ、異なる場所、異なるプロジェクトのファイルなど、ファイルの異なるビューを表示することを要求した場合、プロセスは、ステップ８１０３に進み、新しいビューがファイルの有効な保存場所（物理的な場所または論理的な場所）を表しているかどうかを判定することができる。例えば、ユーザがファイルを特定の場所、または特定のビューに保存する特権を有していない可能性があるか、または保存すべきファイルは、新しいビュー内の他のファイルと非互換である（例えば、ユーザがビューをスプレッドシートビューに変更してしまい、新しいファイルは非互換の画像ファイルである）。他の例として、共通ファイルダイアログからのゴーストは、ダイアログの外の場所に移動されることを禁じられている場合がある。ビューを変更することは、必ずしも、新しいファイルのプロパティの変更につながらない。いくつかの場合において、ユーザは、変更されたビューのプロパティと一致するように新しいファイルのプロパティを更新することを望まずに、ビューを異なるファイルを表示するように単純に変更してしまっていることがある。例えば、ユーザは、保存されているファイルの優先度を必ずしも変更することなく、特定の優先度についてどのようなドキュメントがほかに存在するかを調べたいだけの場合もある。ビューが変更されるときにプロパティのそのような更新が望まれていない場合、プロセスは、ステップ８１０２からステップ８１０６に移動することができる。

新しい場所が無効である場合、システムは、ステップ８１０４に移動し、無効な場所が選択されたことをユーザに警告する措置を講じることができる。例えば、プレビューゴーストは、単純にビューから消えることができる。さらに、メッセージを、ユーザに与えることもできる。このようなことが生じた場合、システムは、ユーザがファイルの有効な場所を表す異なるビューを選択するまで、この状態に単純にとどまることができる。それとは別に、ユーザは、例えば、「Ｃａｎｃｅｌ」ボタン８００８を押すことにより、プロセスを中止することができる。

新しいビューが有効な場所である場合、システムは、ステップ８１０５に進み、変更を完遂することができる。これは、新しいビューに表示されるようにプレビューゴーストを再配置するステップを伴うことができる。ファイルのメタデータも、新しく選択されたビューの必要なメタデータ（もしあれば）を反映するように自動的に更新することができる。例えば、ユーザが与えられたプロジェクトのすべてのファイルの新しいビューを選択した場合、「Ｐｒｏｊｅｃｔ」メタデータプロパティは、新しいプロジェクトを反映するように改訂することができる。

ステップ８１０６で、システムは、ユーザが新しいファイルで既存のファイルを置き換えることを要求したかどうかをチェックして調べることができる。これは、例えば、ゴーストプレビューの印を既存のファイルの印の上にドラッグ＆ドロップすることにより実行することができる。これが生じた場合、ステップ８１０７で、例えば、メモリに保存することにより元の一組のメタデータプロパティを保持する処置を講じることができる。表示されるメタデータプロパティは、置き換えるファイルのプロパティにより置き換えられ、新しいファイルが、それが置き換えるファイルと同じプロパティを持つという事実を反映することができる。元のプロパティを保存することは、置き換えについてユーザの気が変わった場合に有用である。もちろん、既存のファイル上にドラッグ＆ドロップすることは、必ずしも必要ではなく、そのような機能が望まれていない場合には、ステップ８１０６をスキップすることができる。

ステップ８１０８で、システムは、ユーザが保存プロセスを実行するかどうかを調べるために待つ（例えば、「Ｓａｖｅ」ボタン８００７を押すことにより）。ユーザが保存プロセスを実行する場合、ステップ８１０９で、古いファイルは、新しいファイルで置き換えられる。ステップ８１０７で保持された前のプロパティは、破棄することができる。

ユーザが、ゴーストを再び選択することなどにより、置換プロセスを実行しないことに決めた場合、プロセスは、ステップ８１１０に戻り、そこで、ゴーストは前の状態で表示されうる。ステップ８１０７で保存された元のメタデータプロパティは、ゴーストプレビューのメタデータフィールドへの初期値入力をやり直すために使用することができる。それとは別に、新しいファイルは、前に上書きされるべきであったファイルのプロパティを保持することができる。この代替え手段により、ユーザが、個別に入力することなく一組のメタデータプロパティ全体を複製することが簡単に行えるようになる。例えば、置き換えるべきであった（もはや置き換えられない）アイテムのプロパティは、「スタンプ」または将来新しい保存ファイルに適用することができる新しい既定の一組のプロパティとして保持することができる。

ステップ８１１１で、ユーザが、例えば、メタデータ表示領域８００６を使用してメタデータプロパティ値を編集したかどうかを判定するチェックを行うことができる。ユーザがメタデータを編集している場合、システムは、ステップ８１１２のゴーストプレビューを新しいプロパティにふさわしい新しい場所に自動的に移動し、必要ならば、ゴーストプレビューの外観を更新して、新しいメタデータプロパティを反映するようにできる（例えば、ファイルタイプが変わった場合には異なる印を選択するか、またはその印の下でファイル名を改訂する）。

ステップ８１１３で、システムは、ユーザが、「Ｓａｖｅ」ボタン８００７を押すことなどにより、保存を実行することを要求したかどうかをチェックして調べることができる。ユーザが保存オペレーションを要求している場合、新しいファイルは、ステップ８１１４で保存され、ゴーストプレビューは、消える（今度は、新しいファイルが通常の印として表示される）。

ユーザが、まだ保存をファイナライズしていなかった場合、ステップ８１１５で、ユーザが、例えば、「Ｃａｎｃｅｌ」ボタン８００８を押すことにより、保存オペレーションを中止したかどうかを判定するチェックを行うことができる。ユーザが、保存オペレーションを取り消した場合、ゴーストは、ステップ８１１６で削除されることができる。ゴーストのプロパティデータも、システムから削除することができる。

^**エクスプローラビューの特殊化：本発明の一態様によれば、エクスプローラ（シェルブラウザ）ウィンドウ（例えば、図５１〜５７に関して上で説明されているようなもの）は、使用する状況またはナビゲートされるデータ／ファイルに基づいて特殊化され、それにより、システム上でファイルを閲覧する際のユーザエクスペリエンスを向上させることができる。図８２は、エクスプローラウィンドウ内の表示領域などの異なるパネルが概念上どのように関係しているかを例示する関係図を示している。いくつかの場合において、システムを通じて使用可能なファイルの閲覧を開始するためにユーザに与えられる初期表示領域として使用できる「Ｓｔａｒｔ」パネル８２０１があり得る。「Ｓｔａｒｔ」パネル８２０１は、Ｍｕｓｉｃブラウザ８２０２、Ｄｏｃｕｍｅｎｔｓブラウザ８２０３、Ｐｉｃｔｕｒｅｓブラウザ８２０４、Ｃｏｍｐｕｔｅｒブラウザ８２０５、またはシステムおよび／またはユーザが望んでいる他のブラウザ８２０６など、ファイルを閲覧するための異なるパネルを表示する機能を用意することができる。これらのブラウザは、それぞれ、特定の基準を満たすファイルを閲覧するための最上位パネルであってよい。例えば、Ｍｕｓｉｃブラウザ８２０２は、オーディオ音楽ファイルタイプなどの特定の音楽基準を満たすシステム上のファイルの一覧表示を表示することができる。ブラウザは、さらに、１つまたは複数のジャンル基準を満たすファイルを表示するＧｅｎｒｅ８２０２ａブラウザパネルまたは楽曲の１つまたは複数のプレイリストに関係するファイルを表示するＰｌａｙｌｉｓｔ８２０２ｂブラウザパネルなど、異なる基準を使用して作成されたサブブラウザを備えることもできる。これらのパネルは、さらに、他の基準を満たすファイルの表示を行うこともできる。例えば、Ｇｅｎｒｅ８２０２ａパネルは、ジャンル情報を含む楽曲である音楽ファイルの部分集合を表示することができ、またロックンロールのジャンルを含む音楽ファイルの他の部分集合を表示するＲｏｃｋ８２０２ｃサブパネルを備えることができる。ファイルデータを表示する所望の関係および方法に対応できるパネルをいくつでも作成することができる。Ｄｏｃｕｍｅｎｔｓブラウザ８２０３は、特定の種類のドキュメント（例えば、スプレッドシート）、または与えられたプロジェクトに関係するドキュメント（例えば、ＸＹＺプロジェクト）用に別々のブラウザを備えることができる。

それぞれの使用可能なブラウザは、コンピュータシステムのメモリに格納されているテンプレートにより定義することができる。テンプレートは、単純に、ビューの内容、組織、および表示する特徴などを識別するファイルとすることが可能である。また、テンプレートは、ブラウザビュー内に表示される実際のファイルを指定することもできる。

図８３は、ブラウザ表示８３０１の一実施例を示している。この表示８３０１は、ユーザに提供される１つまたは複数のコマンド８３０２を含むことができる。これらのコマンドは、メニュー、リンク、ボタン、アイコン、または他の印などのコマンド入力の形態とすることができ、ブラウザビューを定めるテンプレートに基づいてカスタム選択することができる。例えば、ブラウザ８３０１が音楽ファイルの表示である場合、コマンド８３０２は、「ＣｏｐｙｔｏＣＤ」、「Ｐｌａｙ」、および／または「ＳｈｏｐｆｏｒＭｕｓｉｃＯｎｌｉｎｅ」などの音楽ファイルに対して意味のある特定のコマンドを含むことができる。もちろん、コマンド８３０２は、ファイル操作（例えば、ファイルを保存する、開く）用の「Ｆｉｌｅ」コマンドおよび現在のパネルを編集する（例えば、複製パネルを作成する、または複数の既存のパネルを並べ替える）ためのコマンドなどの、様々なブラウザに関連付けられ、様々なブラウザにより共有されるコマンドも含むことができ、またコマンドのメニューを含むことができる。コマンドの有無に加えて、コマンド表示８３０２では、さらに、色、ユーザインターフェース要素の詳細（色、サイズ、位置決めなど）、選択可能な要素の順序付けなど、表示の見え方をカスタマイズすることもできる。

表示８３０１は、使用可能なブラウザパネルを示すリストパネル８３０３を含むことができる。このリストは、システム上のすべての使用可能なビューの一覧表示を含み、表示領域を節約するため入れ子になったメニュー／サブメニュー形式で表示できる。このビュー範囲は、ページ空間と呼ぶことができる。それとは別に、一覧８３０３に、現在のパネルに関連付けられているブラウザパネルの部分集合を表示することができ、ページ空間が小さくなる。例えば、現在の表示８３０１が音楽パネルである場合、一覧８３０３には、ＰｌａｙｌｉｓｔおよびＧｅｎｒｅビューオプション、または専用のパネルを持つ特定のプレイリストおよび／またはジャンルを表示することができる。

表示８３０１は、現在のブラウザパネルに対し設定されている基準を満たすファイルの一覧表示を格納することができる、ファイルパネル８３０４を含むことができる。ファイルパネル８３０４は、データファイルを表す印（アイコンおよび／またはテキストなど）およびファイルの１つまたは複数のプロパティ（例えば、名前、作成者、ファイルサイズ、ファイルタイプ、プロジェクト所属、作成／修正日など）を含むことができる。これらのプロパティは、列などに配列することができ、また選択された表示８３０１に使用される基準が与えられた場合に何が適しているかに応じて再配列および／または修正することができる。例えば、音楽ブラウザは、「ＳｏｎｇＴｉｔｌｅ」を第１のプロパティとして一覧に表示し、「Ａｒｔｉｓｔ」および「Ａｌｂｕｍ」を次のプロパティとして一覧に表示することを選択できるが、プロジェクトＸＹＺに対するブラウザでは、「ＥｄｉｔＤａｔｅ」を第１のプロパティとして一覧に表示し、「ＦｉｌｅＳｉｚｅ」および「ＦｉｌｅＴｙｐｅ」を次のプロパティとして一覧に表示することができる。いくつかのブラウザタイプでは、不要なプロパティを省きたい場合がある（例えば、「Ａｌｂｕｍ」プロパティは、スプレッドシートドキュメントにはあまり有用であるとはいえない）。それぞれのブラウザ表示８３０１は、ファイルおよび関連プロパティのカスタマイズされた配列を持つことができる。列幅、行サイズ、印の見え方（例えば、サイズ、色など）、グルーピング、スタッキング、および他の表示プロパティは、このカスタマイズに含めることができる。例えば、いくつかのブラウザでは、ファイルをサムネイルとして表示することができるが（例えば、画像ブラウザがこれを行う）、他のブラウザは、単に、ファイルをファイルおよびそのプロパティのテキスト形式の一覧で表示するだけである。

表示８３０１は、さらに、ファイルパネル８３０４から１つまたは複数の選択されたファイルの内容のプレビューを表示するプレビューパネル８３０５を含むことができる。また、リストビューデータ８３０４からの１つまたは複数の選択されたファイルのプロパティを表示するプロパティパネル８３０６であってもよい。プロパティパネル８３０６に表示されるプロパティの詳細および／または量は、リストビュー８３０４に表示されているのよりも多い。表示８３０１は、ナビゲーションコマンド、パネルサイズ設定コマンドなどの他の種類の表示およびユーザインターフェース要素も含むことができる。

表示８３０１の様々な部分はそれぞれ、異なるソフトウェアモジュールとして実装することができる。例えば、Ｃｏｍｍａｎｄｓ表示８３０２に入るユーザインターフェース要素を定義する役割を持つＣｏｍｍａｎｄｓモジュール、ファイルパネル８３０４内の表示要素を処理するためのＬｉｓｔｖｉｅｗモジュール、プレビューパネル８３０５の内容を生成するためのＰｒｅｖｉｅｗモジュールなどが考えられる。これらのモジュールは、他のアプリケーションとの相互運用性を高めるためのアプリケーションプログラムインターフェース（ＡＰＩ）を公開することができ、様々なモジュールに対し、与えられたビュー、その位置、そのサイズに対する基準などのパラメータを付与することができる。モジュールを別々にすることで、異なるレイアウトおよび配列を持つ新しいパネルを定義するプロセスを簡素化することができる。

また、それぞれのブラウザ表示８３０１には、上述の表示領域内に異なる内容を単に入れる以上の違いも生じうる。例えば、それぞれのブラウザは、表示領域のそれ専用のカスタマイズされた配列を持つことができ、それにより特定の領域に対し特定のブラウザの基準および／または内容に基づいてサイズ変更／追加／削除を行うことができる。例えば、音楽ブラウザでは、プレビューパネル８３０５を捨てて、音楽コマンド（例えば、ｐｌａｙ、ｐａｕｓｅ、ｃｕｅ、ａｄｄｔｏｐｌａｙｌｉｓｔ、ｂｕｒｎｔｏＣＤなど）をコマンド領域８３０２に用意したい場合もある。他の表示領域は、プレビューパネルによりすでに占有されている空間を利用するため再配列および／またはサイズ変更することができる。ブラウザの特定のレイアウトは、例えば、ブラウザビューを定義するテンプレートで設定することができる。例えば、図８４は、異なる方法で配列された要素を持つ異なるブラウザ８４０１の一実施例を示している。その実施例では、利用可能なブラウザビューの一覧８４０２は、プレビューパネルにより放棄された空間を占有するように拡大されている。他の違いとしては、それぞれのブラウザビューは、透かしパターン、カラーテーマ、フォントなどの独自の表示テーマを持つことができ、それにより、そのビューをシステム上の他のビューからさらに区別しやすくなる。コンテキストメニュー（例えば、使用可能なコマンド、テキストなど）、ユーザインターフェースの挙動、左／右マウスクリック時の既定のコマンド、および他の表示／対話操作属性も、ブラウザごとに異なっていてよい。

図８５は、様々なブラウザを表示する例示的なプロセスを示している。ステップ８５０１で、システムは、表示するビューを定義する１または複数の基準を受け取ることができる。これらの基準の出所は、様々である。例えば、ユーザは、表示用の定義済みテンプレートを選択している場合があるが、システムは、単純にその選択（またはテンプレートに関連付けられている基準）を受け取るだけである。それとは別に、システムは、ユーザによって与えられたキーワードを使用するキーワード検索に基づく新しいビューなど、新しいビューの基準を受け取ることができる。

ステップ８５０２では、基準は、その基準を満足する、または一致する、ブラウザ表示に含めるべき、システム上の様々なファイルを識別するために使用することができる。これらのファイルは、システムのメモリの検索を通じて識別されるか、またはテンプレートで一覧表示すべきファイルをすでに識別している場合にはテンプレート情報から単純に識別することができる。

ファイルが示されると、システムは、ステップ８５０３において特定のブラウザビューまたはパネルを組み立てることができる。パネルを組み立てることは、定義済みテンプレートを参照してパネル内で必要な様々な要素／モジュールを決定することを含むことができる。いくつかの場合において、パネルは、表示用に識別されたファイルがテンプレートに対して設定されているのと異なる一組の基準を満たした場合、または識別されたファイルがより絞り込まれて基準を持つ異なるテンプレートで表示するのに適している場合に、さらにカスタマイズおよび／または修正することができる。例えば、ユーザがＸＹＺＰｒｏｊｅｃｔなどの与えられたプロジェクトに関連付けられたすべてのファイルに対するブラウザを要求した場合、システムがプロジェクトブラウザパネルを表示することが期待できる。このようなパネルは、プロジェクトが複数のタイプのファイルを含み、ファイルタイプに基づいてファイルを分けるための独立した複数の表示領域を持つという可能性とともに定義されている場合がある。しかし、特定のプロジェクトがたまたまあるタイプのファイルを用意したにすぎない場合、システムは、現在の表示に合わせてブラウザパネルを動的にカスタマイズすることができる。さらにカスタマイズされたパネルは、そのファイルタイプに適用可能な拡張コマンドオプションを備えるか、または通常であれば他のタイプのファイルを表示するために使用されている表示領域および／または要素を削除することができる。ブラウザビューは、パネルを設定するために使用される基準を満たすファイルの素性に基づいて動的に修正されることができる。他の種類のカスタムの組み立ても実行できる。ブラウザは、表示されるファイルの数に応じてパネルを調整し、第１の表示領域の画面空間の一部を異なる表示領域に転送することができる（例えば、表示されるリストビューは小さいが、表示されるプロパティ領域は大きくなる）。ブラウザは、表示するファイルを識別するために使用される検索基準に基づいてパネルを調整することができる（例えば、基準を表示の所定の部分に組み込むか、または結果を、その基準、およびファイルの一致度に基づいて配列することができる）。

ステップ８５０４で、コンピュータシステムに関連付けられている表示デバイス上にブラウザビューを生成することができる。次いで、ステップ８５０５で、システムは、ユーザがブラウザビューに対する対話操作を実行したか、またはブラウザビューに入力を供給したかをチェックして調べることができる。ユーザ対話操作は、テキストの編集、異なるビューを選択することによるページ空間内のナビゲート、および／またはブラウザ上の表示されている要素の対話操作を含むことができる。ユーザが入力を与えた場合、ステップ８５０６で、システムはそれに応じてブラウザを改訂することができる。ブラウザに対する改訂は、ブラウザビュー内の表示された要素の１つまたは複数の削除、追加、または修正を含むことができ、その結果、劇的に異なる表示が生じることがある。例えば、ユーザがＭｕｓｉｃブラウザビューを表示することで、音楽ファイルのうちの１つが選択され、選択された音楽ファイルに関連付けられているプロジェクトに関してＰｒｏｊｅｃｔブラウザを表示する要求が行われる−Ｐｒｏｊｅｃｔブラウザは、完全に異なる表示形式を持つことができる。ブラウザ表示は、上述の機能を追加および／または削除するように動的に修正することができ、その結果、ブラウザインターフェースは、状況に応じた高レベルの情報をユーザに提供することができる。

特定のブラウザを変更または改訂する場合、システムは、遷移が滑らかに見える視覚的効果を与えることができる。例えば、アニメーションを使用して表示要素の位置変更を示す、フェーディングを使用して要素の追加／削除を示す、およびモーフィング効果を使用して一方の要素が他方の要素に変化する様子を示すことができる。異なるビューが可能であるが、ユーザ（またはシステムもしくはアプリケーション）は、ユーザの混乱を最小限に抑えるため特定の機能（例えば、表示要素、使用可能なコマンド、メニューなど）または書式が複数のブラウザビューにおいて変わらないように指定することもできる。

ステップ８５０６の後、またはステップ８５０５でユーザからの入力がなかった場合に実行されるステップ８５０７では、システムは、ブラウザが閉じられるか、終了するかをチェックして調べ、もしそうならば、このブラウザに対するブラウザプロセスは終了することができる。もしそうでなければ、プロセスはステップ８５０５に戻って、さらにユーザ入力を待つことができる。

図８６は、上述の様々なブラウザビューを生成するためにシステム内に存在しうる論理関係を示す例示的な図である。ブラウザビューは、一般に、基盤のオペレーティングシステム（例えば、図８６の左にあるＭａｎａｇｅｄ８６０１グループ）により管理されるマネージドであるか、または個々のインストール後アプリケーションがビューを制御できるようにオペレーティングシステムによる管理がなされないアンマネージドとすることができる（例えば、図８６の右にあるＵｎｍａｎａｇｅｄ８６０２グループ）。システムは、基本的な全体的ビューフレーム８６０３を定義することができ、これは、複数のビューに共通の態様を定義することができる。例えば、システムの基本的なビューフレーム８６０３は、プレビューペイン、左ペイン、およびタスクペインを含むことができる。基本構成は、アンマネージドブラウザアプリケーション８６０４に渡すことができ（例えば、データ構造体として）、これにより、既定のビュールーチン８６０５が呼び出され、ブラウザアプリケーション８６０４の所望の既定のブラウザビューを生成することができる。アプリケーションは、ブラウザビューを起動するために使用されるサブルーチン８６０６を含むことができ、そのルーチン８６０６は、その特定のブラウザアプリケーション８６０４に対し生成されるべきビューを定義するページ記述８６０７を格納するマネージドデータ構造体にアクセスすることができる。

ページ記述８６０７は、ブラウザページ構造体８６０８への参照を含むことができる。ブラウザページ８６０８構造体は、最終的にビューを定義する様々なプロパティを含むことができる。例えば、このビューに含めるべき基本属性を定義するビュープロパティ８６０９があり得る（これらの属性は、基本ビューフレーム８６０３内の同じプレビューペイン、左ペイン、およびタスクペインであってよい）。ページ８６０８は、特定のビューに初期値として入るデータの取得先である場所を識別できる、データソースプロパティ８６１０を持つこともできる。例えば、ソース８６１０は、データの静的リストを含むことができる。ページ８６０８は、さらに、コマンドプロパティ８６１１を含むこともでき、これは、ビューによりサポートされる様々なコマンドを識別することができる。それぞれのコマンドは、別々のアプリケーションおよび／またはルーチンにより実装することができ、プレビューペインタスク、コンテキストメニューオプションなどを取り扱うためのコマンドを含むことができる。もちろん、上記は、様々なブラウザビューを管理し実装する一実施例にすぎない。

上の説明では、「ブラウザ」と呼んでいるが、本明細書で説明されている機能は、システムシェルブラウザに限る必要はない。データファイルのカスタマイズされたビューを表示したいアプリケーションでは、本明細書で説明されている機能を利用することができる。

本発明の他の実施形態および実装は、関係する当業者にとっては、図面を含む、明細書を読んだ後であれば明白なことであろう。例えば、説明されているプロセスの様々なステップは、本明細書で説明されている機能の選択された部分集合を実装するのに必要に応じて再配列、修正、および／または削除することができる。それに加えて、上記において、「本発明」の１つまたは複数の「態様」または「実施形態」に見られるいくつかの機能への参照は、単に、単独でまたは他の概念と組み合わせて都合よく使用できる様々な概念を例示するために行われており、本明細書には１つの発明概念しかないこと、または説明されている機能をすべてが請求項のいずれかで要求されていることを暗示していると解釈すべきではない。むしろ、請求項のそれぞれは、個々の異なる発明として存在し、参照されている以上の制限を有するものと解釈すべきではない。

^**ページ空間コントロール：膨大な量の情報が、コンピュータシステムおよびネットワーク上に格納され、および／またはコンピュータシステムおよびネットワークを通じて利用可能であり、この情報は、様々な異なる目的にそってコンピュータユーザが利用することができる。コンピュータはこのような膨大な情報をユーザに提供することができるが、情報は、ユーザがシステムまたはネットワークから所望の情報を確実に特定して取り出せる場合に限り、ユーザにとって貴重であり有用である。格納されている情報は、実質的な検索の時間、労力、および／またはフラストレーションをもたらすことなく容易に特定し、および／または取り出せることができなければ、ユーザにとっては価値がないも同然である。そこで、本発明の様々な態様は、コンピューティングシステムおよび／またはネットワーク内にあり、コンピューティングシステムおよびまたはネットワークを通じて利用可能な電子的情報を格納し、検索し、ナビゲートし、および／または取り出すためのシステム、方法、およびコンピュータ可読媒体に関する。この節は、読者の助けとなるようにいくつかの節に分けられている。これらの節は、用語、本発明の様々な態様の概要説明、本発明によるシステム、方法、およびコンピュータ可読媒体の実施例、および結論からなる。

ページ空間コントロール：用語：以下の用語は、この節で、また本明細書を全体を通して使用することができ、断りのない限りまたは文脈上明らかでない限り、これらの用語は、以下に与えた意味を持つ。

「階層プロパティ」−一意的な文字列を分類する順序付きコレクションを含むことができる値を持つタイプのプロパティ。それぞれの文字列は、例えば、それが指定されるパスにより一意にすることができ、このパスは、さらに、それぞれのプロパティ値が属するカテゴリを定義するために使用することができる。

「親プロパティ値」−１つまたは複数の可能な子プロパティ値を持つプロパティ値。

「子プロパティ値」−他のプロパティ値の子であるプロパティ値。

「自動リスト」−事前に選択されている一組のフィルタ条件と一致する固定スコープに渡る情報のクエリから結果として得られるファイルまたは他のデータの一覧。「自動リスト」の実施例は、限定はしないが、ｆｉｌｅｃｒｅａｔｉｏｎｄａｔｅｓ、ｆｉｌｅｃｒｅａｔｉｏｎｔｉｍｅ、ｌａｓｔｅｄｉｔｄａｔｅ、ｌａｓｔｅｄｉｔｔｉｍｅ、ｆｉｌｅｒａｔｉｎｇｄａｔａ、ｆｉｌｅａｕｔｈｏｒｌｉｓｔ、ｌａｓｔｕｓｅ＝ｙｅｓｔｅｒｄａｙ、ｌａｓｔｕｓｅ＝ｌａｓｔｗｅｅｋなどを含む。以下で説明されているような「ナビゲーションパネル」は、１つまたは複数の「自動リスト」を含むことができる。

「リスト」−自動リスト、ファイル、ファイルコレクション、フォルダなどへのショートカットまたは「リンク」。以下で説明されているような「ナビゲーションパネル」は、１つまたは複数の「リスト」を含むことができる。

「ページ」−特定のフォルダ、仮想フォルダ、リスト、自動リストなど。「ページ」は、例えば、メニュー、本発明によるナビゲーションツールなどからアイテムを選択することにより、ユーザがナビゲートすることができる移動先の階層型テーブル内の１つのノードを構成することができる。記憶装置システム内の様々なレベルにある、および／またはコンピュータシステムもしくはネットワークを通じて利用可能な個々の「ページ」または「ページ」の一覧表示は、以下でさらに詳しく説明するように、ナビゲーションパネルおよび／または表示パネル内に表示することができる。

「コンピュータ可読媒体」−コンピュータシステム上でユーザがアクセスできる使用可能な媒体。例えば、限定はしないが、「コンピュータ可読媒体」は、コンピュータ記憶媒体および通信媒体を含むことができる。「コンピュータ記憶媒体」は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。「コンピュータ記憶媒体」は、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光記憶デバイス、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または所望の情報を格納するために使用することができコンピュータによりアクセスできるその他の媒体を含む。「通信媒体」は、典型的には、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号内に情報を符号化するような方法で特性のうちの１つまたは複数が設定または変更された信号を意味する。例えば、限定はしないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。上記のいずれの組合せも「コンピュータ可読媒体」の範囲に収まらなければならない。

ページ空間コントロール：本発明の様々な態様の概要説明
ページ空間コントロール：本発明の様々な態様の概要説明：階層関係へのプロパティの格納
本発明のいくつかの態様は、格納されるデータ構造体を持つコンピュータ可読媒体に関する。本発明の少なくともいくつかの実施例によるデータ構造体は、（ａ）電子ファイルの内容の少なくとも一部を含む第１のデータセットと、（ｂ）電子ファイルに関連付けられているプロパティデータを含む第２のデータセットとを含むことができる。この第２のデータセットは、電子ファイルに関連付けられている第１のプロパティを示す第１のフラットなパス文字列を含み、第１のフラットなパス文字列は、プロパティデータの階層構造を示す。適宜、そうしたければ、第２のデータセットは、例えば階層構造の電子ファイルに関連付けられている複数のプロパティを示すデータの複数のフラットなパス文字列を含むことができる。第２のデータセットは、所望の方法で、例えば、第１のデータセットに含まれ、および／または第１のデータセットに関連付けられているメタデータとして与えることができる。もちろん、必要ならば、追加のプロパティデータを含む第３のデータセット（またはさらに多くのデータセット）を電子ファイルに格納し、および／または関連付けることができ、その場合、第３のデータセット（または追加のデータセット）は、その電子ファイルに関連付けられている他のプロパティを示す他のフラットなパス文字列を含み、追加のフラットなパス文字列は、第３の（または追加の）データセット内のプロパティデータの階層構造を示す。

本発明の追加の例示的な態様は、階層プロパティ情報を含む電子データを格納するためのシステムおよび方法に関する。このようなシステムおよび方法は、（ａ）コンピュータ可読媒体に格納するための電子データを含む電子ファイルを作成することと（例えば、１つまたは複数のコンピュータ処理システムを使用して）、（ｂ）電子ファイルの一部として含まれる、または電子ファイルに関連付けられる第１のプロパティ値を示す入力データを受け取り（例えば、マウス、ペン、デジタイザ、キーボード、ネットワーク接続、ディスクドライブなどを介して）、第１のプロパティ値は、第１のプロパティ値を示す第１のフラットなパス文字列を含む第１のデータセットを含み、第１のフラットなパス文字列は、第１のプロパティ値の階層構造を示すことと、（ｃ）電子ファイルをその中に含まれる、またはそれに関連付けられた第１のパス文字列とともに格納し、第１のフラットなパス文字列は、例えば、リンク情報を通じて、ファイルの一部として、メタデータとしてなど、所望の方法で電子ファイルに格納されるか、または関連付けられることとを含むことができる。適宜、本発明の少なくともいくつかの実施例によるシステムおよび方法は、さらに、電子ファイルの一部として含まれる、または電子ファイルに関連付けられる第２のプロパティ値を示す入力データを受け取ることができ、その場合、第２のプロパティ値は、第２のプロパティ値を示す第２のフラットなパス文字列を含む第２のデータセットを含み、第２のフラットなパス文字列は、第２のプロパティ値の階層構造を示し、電子ファイルの格納は、その中に含まれる、またはそれに関連付けられた第２のフラットなパス文字列とともに電子ファイルを格納することを含む。本発明によるこの方法では、プロパティ値は、いくつでも、電子ファイルに格納できる、および／または関連付けることができる。

本発明のさらに追加の例示的な態様は、関連付けられている階層プロパティ情報を含む電子データを処理するためのシステムおよび方法に関する。本発明の少なくともいくつかの実施例によるシステムおよび方法は、（ａ）コンピュータシステムまたはネットワーク上で複数の定義済みプロパティ値の階層構造を示すデータを受け取り（コンピュータシステムまたはネットワークのメモリに格納し）、それぞれの定義済みプロパティ値は、階層構造内の他のすべての定義済みプロパティ値と比較したときに関連付けられた一意のフラットなパスデータ文字列を持つことと、（ｂ）階層構造内のユーザが望む場所に含める新しいプロパティ値を示すユーザ入力を受け取ることと（例えば、マウス、ペン、デジタイザ、キーボード、ネットワーク接続、ディスクドライブなどを介して）、（ｃ）階層構造内のユーザが望む場所に基づき、新しいプロパティ値が、階層構造内に存在する他のすべてのフラットなパスデータ文字列と異なるフラットなパスデータ文字列を持つかどうかを決定することとを含むことができる。新しいプロパティ値に対するフラットなパスデータ文字列は、例えば、少なくとも第１の親プロパティ部分および第１の子プロパティ部分を含むことができる（適宜、第１の親プロパティ部分または第１の子プロパティ部分のうちの少なくとも１つは、階層構造内で少なくとも１つの他の定義済みプロパティ値の一部と同じであってよい）。この方法は、さらに、新しいプロパティ値に対するフラットなパスデータ文字列が階層構造内に存在するプロパティに対する他のすべてのフラットなパスデータ文字列と異なると判定された場合に、新しいプロパティ値をユーザの望む場所の階層構造に追加することを含むことができる。

本発明による実施例による様々なシステムおよび方法の使用において、ユーザは、検索クエリを示す入力をシステム内に入れることができ、そこで、検索クエリは、階層プロパティ構造内でプロパティ値を含む検索プロパティの選択を含む。検索クエリが入力されると、本発明の少なくともいくつかの実施例によるシステムおよび方法では、コンピュータシステムまたはネットワーク上に格納された、またはコンピュータシステムまたはネットワークを通じて利用することができる（適宜、検索対象のファイルのスコープを制限する検索スコープを使用して）どの電子ファイルが検索クエリの条件を満たすかを調べることができ、検索クエリの条件を満たすと判定された電子ファイルは、それに格納されている、またはそれに関連付けられている第１の検索プロパティを含む。他の実施例として、検索クエリは、階層構造内で複数のプロパティをユーザが選択することを含み、コンピュータシステムまたはネットワーク上に格納されるか、またはコンピュータシステムまたはネットワークを通じて利用可能な（適宜、制限された検索スコープの範囲内で）どの電子ファイルが検索クエリの条件を満たすかの判定は、選択されたプロパティのうちの少なくとも１つを含む電子ファイルの識別を含むことができる。

本発明のいくつかの実施例によるコンピュータ可読媒体、システム、および方法に含まれるプロパティ値は、本発明から逸脱することなく好適なまたは所望の方法で、例えば、プロパティデータセット内のプロパティデータの階層構造を示す方法で、格納することができる。例えば、プロパティデータ構造体は、親プロパティ値−区切り文字−子プロパティ値、親プロパティ値−区切り文字−子プロパティ値−区切り文字−孫プロパティ値、子プロパティ値−区切り文字−親プロパティ値、および／または子プロパティ値−区切り文字−親プロパティ値−区切り文字−孫プロパティ値という形式のうちの１つをとりうる。もちろん、本発明から逸脱することなく、プロパティ階層構造およびフラットなパスデータ文字列におけるデータ構造のレベルはいくつでも用意できる。

本発明の追加の態様は、階層プロパティデータを提供しおよび／または階層プロパティデータを使用する、例えば、様々な方法を実行し、および／または上述の様々なシステムを運用するためのコンピュータ可読媒体を含む、電子ファイルおよび関係する情報の格納、検索、ナビゲート、および／または取り出しを行うため格納されるそこに格納されるコンピュータ実行可能命令を含むコンピュータ可読媒体に関する。

ページ空間コントロール：本発明の様々な態様の概要説明：複数プロパティ選択：本発明の他の態様は、電子ファイルプロパティデータの複数の選択を含む、複数のユーザ選択を含む入力データを処理するための方法およびシステムに関する。このようなシステムおよび方法は、例えば、（ａ）複数の検索要素を含む階層構造から第１の検索パラメータを選択することと（例えば、マウス、ペン、デジタイザ、キーボード、ネットワーク接続、ハードディスクなどのユーザ入力デバイスを通じて）、（ｂ）階層構造から第２の検索パラメータを選択することと（例えば、マウス、ペン、デジタイザ、キーボード、ネットワーク接続、ハードディスクなどのユーザ入力デバイスを通じて）、（ｃ）第１の検索パラメータが階層構造内の、第２の検索パラメータと同じ要素集合内に配置されているかどうかを判定する（例えば、コンピュータ処理システムを使用して）こととを含むことができる。第１の検索パラメータが、第２の検索パラメータと同じ要素集合内に配置されていると判定されたかどうかに応じてコンピュータ処理システムにより、様々な表示が生成可能である（例えば、コンピュータ表示デバイス上に）。本発明の少なくともいくつかの実施例によれば、第１の検索パラメータまたは第２の検索パラメータの条件を満たす電子ファイルの和集合を示す検索結果は、第１の検索パラメータが、階層構造内の、第２の検索パラメータと同じ要素集合内に配置されると判定された場合に表示できる。それに加えて、またはそれとは別に、第１の検索パラメータと第２の検索パラメータの両方の条件を満たす電子ファイルの積集合を示す検索結果は、第１の検索パラメータが、第２の検索パラメータの階層構造内の要素集合の外に配置されていると判定された場合に表示できる。

本発明の少なくともいくつかの実施例によれば、様々な検索要素の（複数の）階層構造は、階層状に配列された複数のプロパティを含むことができる。検索パラメータの少なくとも１つは、これら定義されたプロパティ値のうちの１つを含むことができる。適宜、少なくともいくつかの実施例において、検索要素のうちの少なくとも１つは、フォルダ要素、リスト要素、自動リスト要素、または階層構造内の他の望ましい要素を構成する。本発明の少なくともいくつかの実施例のなおも追加の機能は、少なくとも一部は検索要素の階層構造および／または検索スコープに対する階層構造の一部を選択するユーザ入力に適宜基づいて、検索活動に対するスコープを決定または定義することを含むことができる。

本発明の他の態様は、上述のようなシステムおよび方法を含む、様々な検索方法を実行し、および／または様々な検索システムを操作するために格納されているコンピュータ実行可能命令を収めたコンピュータ可読媒体に関する。

ページ空間コントロール：本発明の様々な態様の概要説明：表示パネル内のグルーピングおよびスタッキング：本発明のさらに他の例示的な態様は、コンピュータシステムまたはネットワークに格納されている、またはコンピュータシステムまたはネットワークを通じて利用可能な電子ファイルを検索するためのユーザインターフェースを備えるコンピュータ表示に関する。本発明の少なくともいくつかの実施例によるユーザインターフェースは、（ａ）検索要素の階層構造（ページ空間）を表示するナビゲーションパネル（ページ空間コントロールとも呼ばれる）であって、階層構造内の少なくともいくつかの個別の検索要素は、適宜ユーザ入力に応じて展開され、階層構造内の１つまたは複数の子検索要素を表示することができる、１つまたは複数の検索要素に向けられたユーザ入力を受け取るナビゲーションパネルと、（ｂ）電子ファイルを検索することから得られた検索結果に少なくとも一部は関係する情報を表示し、検索結果は、ナビゲーションパネルを通じて受け取ったユーザ入力に少なくとも一部は基づいて決定される、表示パネルとを備えることができる。展開された後、ナビゲーションパネルの階層構造内の個別の検索要素は、検索結果が表示パネル内に表示される仕方に関係なく階層構造内の子要素を表示するように展開状態を保つことができる（例えば、スタッキング、グルーピング、グルーピングとスタッキングの組合せなど）。階層構造内の様々な検索要素は、例えば、プロパティ値、リスト要素、自動リスト要素、フォルダ要素などを含むことができ、階層構造は、少なくとも一部は、個々のユーザ入力により定義することができる。

本発明によるユーザインターフェースの少なくともいくつかの実施例によれば、ナビゲーションパネルの階層構造内の子検索要素を選択するか、または他の何らかの方法により検索要素を変更するユーザ入力により、ユーザインターフェースの表示パネル内に表示される検索結果の対応する変化が生み出され、および／または推進される。

本発明のさらに他の例示的な態様は、コンピュータシステムまたはネットワークに格納されている、またはコンピュータシステムまたはネットワークを通じて利用可能な電子データをナビゲートするためのシステムおよび方法に関する。このようなシステムおよび方法は、（ａ）ナビゲーション要素の階層構造を表示するナビゲーションパネルを提供し（例えば、コンピュータ処理システムを使用して）、階層構造内の少なくともいくつかの個別のナビゲーション要素は、適宜ユーザ入力に応じて展開され、階層構造内の子ナビゲーション要素を表示することができることと、（ｂ）ナビゲーションパネルを通じてユーザ入力を受け取り、ナビゲーション要素の１つまたは複数を選択することと（例えば、マウス、ペン、デジタイザ、キーボード、ネットワーク接続、ディスクドライブなどを通じて）、（ｃ）電子データを検索することから得られた検索結果に少なくとも一部は関係する情報を、例えば、表示デバイス上に表示し、検索結果は、ナビゲーションパネルを通じて受け取ったユーザ入力に少なくとも一部は基づいて決定され、情報は、ナビゲーションパネルの表示と同時に表示デバイス上に表示されることとを含むことができる。それに加えて、本発明の少なくともいくつかの実施例によるシステムおよび方法は、さらに、ナビゲーションパネルを通じて、新しいユーザ入力を受け取り、階層構造から１つまたは複数の新しいナビゲーション要素を選択することと（例えば、上述のような入力システムを介して）、新しいナビゲーション要素または選択された要素に少なくとも一部は基づいて、表示されている情報を変更し（例えば、コンピュータ処理システムを使用して）、変更された情報は、ナビゲーションパネルと同時に表示デバイスに表示されることとを含むことができる。新しいユーザ入力は、少なくともいくつかの実施例では、最初に選択され、それにより表示される情報を絞り込むナビゲーション要素から階層構造内の子ナビゲーション要素を構成することができる。ここでもまた、階層構造内の様々な検索要素は、例えば、プロパティ値、リスト要素、自動リスト要素、フォルダ要素などを含むことができ、階層構造は、少なくとも一部は、個々のユーザ入力により定義することができる。

本発明の少なくともいくつかの実施例によるさらに追加のシステムおよび方法は、コンピュータシステムまたはネットワーク上に格納されているか、またはコンピュータシステムまたはネットワークを通じて利用可能な電子データに関する情報を表示するためのシステムおよび方法を含むことができる。このようなシステムおよび方法は、例えば、（ａ）ナビゲーション要素の階層構造を、例えば表示デバイス上に表示するナビゲーションパネルを提供し（コンピュータ処理システムを使用して生成される）、階層構造内の個別のナビゲーション要素のうちの少なくともいくつかは、フォルダ要素を含むことと、（ｂ）ナビゲーションパネルを通じて、ユーザ入力を受け取り、少なくとも１つの新しいフォルダ要素を選択することと（例えば、上述のようなユーザ入力デバイスを使用して）、（ｃ）電子データを検索することから得られた検索結果に少なくとも一部は関係する情報を表示デバイス上に表示し、検索結果は、ナビゲーションパネルを通じて受け取ったユーザ入力に少なくとも一部は基づいて決定され（例えば、コンピュータ処理システムを使用して）、情報は、選択されたフォルダ要素の下に用意されるサブフォルダがスタックとして表示される形で表示されることとを含むことができる。本発明のいくつかの実施例による少なくともいくつかのシステムおよび方法の追加の機能は、ナビゲーションパネルを通じて、新しいユーザ入力を受け取り（例えば、ユーザ入力デバイスを介して）、階層構造から１つまたは複数の新しいナビゲーション要素を選択することと、新しいナビゲーション要素または選択された要素に少なくとも一部は基づいて、表示されている情報を変更する（例えば、コンピュータ処理システムを使用して表示を生成する）こととを含むことができる。新しいユーザ入力は、階層構造内のプロパティ値を選択するために使用することができ、表示される情報は、少なくとも一部は、すでに関連付けられている選択されたプロパティ値を持つ電子データに対応することができる。

本発明のさらに追加の態様は、ユーザインターフェースを実現することと、様々な方法を実行することと、および／または上述のような様々なシステムを操作することとを含む、ユーザインターフェースを実現し、様々な検索および／または表示方法を実行し、および／または階層的検索およびナビゲーション要素を使用することを含む様々な検索および／または表示システムを操作する、コンピュータ可読媒体上に格納されたコンピュータ実行可能命令を含むコンピュータ可読媒体に関する。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：現代のコンピュータオペレーティングシステムおよびその上で稼働するアプリケーションプログラムにおいて、多くのファイルナビゲーション、検索、一覧表示、および／または取り出しオペレーションは、クエリオペレーションを介して実行され、その際に、システムは、様々なクエリパラメータの条件を満たすアイテム（格納されている電子ファイルまたは他のデータなど）を特定することを試みる。本発明のいくつかの態様では、少なくともいくつかの場合に、アイテム配置およびファイル格納に使用することができ、ユーザによるこれらのファイルナビゲーション、検索、一覧表示、および／または取り出し作業を支援する、ナビゲーションツールを備える。

本発明の例示的な態様によれば、ユーザは、本発明によるナビゲーションツールを使用し、例えば、ナビゲーションコントロールメニュー内の任意のページに関係する情報にナビゲートし、および／または特定すること、ページをナビゲーションコントロールメニューまたは一覧表示に追加すること、アイテムを任意の集合（プロパティ集合、自動リスト集合、フォルダ集合など）に追加すること、既存のおよび／またはシステムフォルダ（例えば、「ＭｙＤｏｃｕｍｅｎｔｓ」フォルダなど）の内容を表示すること、フォルダ内の展開されたサブフォルダを表示すること、プロパティまたは他のデータをファイルまたは他のアイテムに追加する（例えば、適宜階層方式で）、さらには自動リストまたはシステム生成リストに格納されているファイルまたはアイテムに追加することなどを行うことができる。さらに、本発明の少なくともいくつかの例示的な態様によれば、ユーザおよび／または独立系ソフト開発会社は、異なるアプリケーションプログラム、異なるビュー、異なる動作モードなどで使用するようにシステムナビゲーションツールをカスタマイズすることができる。必要ならば、ナビゲーションパネルを前の状態、または最初の状態に戻す様々なのツールをユーザに用意することができる。

必要ならば、より具体的な実施例として、本発明による実施例によるナビゲーションツールを、ユーザが注目するページに関係する情報を素早く特定し、表示できるようにするリストおよび／または自動リストを備えるように設計またはカスタマイズすることができる。例えば、必要ならば、システムは、「ＤｏｃｕｍｅｎｔｓＳｔａｃｋｅｄｂｙＡｕｔｈｏｒ」（または類似のもの）という名前のリストまたは自動リストを持ち、これにより、ユーザは、様々なドキュメントについて名前が付けられている基になる作成者に基づいて（ユーザは、さらに、必要ならば、スタック内にドリルダウンし、例えば、特定の作成者による特定のドキュメントを特定することができる）、および／または作成、格納、編集、ダウンロード、修正などが行われたときにファイルに関連付けられているプロパティに基づいて、集められたファイルの「スタック」を示すビューに素早くジャンプすることができる。スタックの他の潜在的なグルーピングまたは一覧表示は、「ｉｍｐｏｒｔａｎｔｄｏｃｕｍｅｎｔｓ」、「ｒｅｃｅｎｔｄｏｃｕｍｅｎｔｓ」、「ｇｏｏｄｍｕｓｉｃ」、「ｒｅｃｅｎｔｌｙｕｓｅｄ」、「ｒｅｃｅｎｔｌｙｏｂｔａｉｎｅｄ」などの一覧表示を含むことができる。

本発明の様々な態様のさらに詳しい説明を以下で行う。当業者であれば、この説明は、単に、本発明の様々な態様の実施例を含むだけであり、本発明を限定しないことを理解するであろう。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：階層関係へのプロパティの格納：上述のように、本発明のいくつかの例示的な態様は、一般に、コンピュータシステムまたはネットワーク上の、および／またはコンピュータシステムまたはネットワークを通じて利用可能な個々の格納されているファイルまたはデータとともに「プロパティ」を格納し、使用するシステムおよび方法に関する。一般に、新しいファイルを、ＰＣ、ＰＣのネットワーク、サーバーなどのコンピュータシステムまたはネットワークに保存するときに、ユーザは、典型的には、「プロパティ」をファイルに割り当てることができる。このような「プロパティ」の実施例は、Ｃｏｍｍｅｎｔｓ、ＡｕｔｈｏｒＩＤ、Ｋｅｙｗｏｒｄｓなどを含む。この機能は有用であり、場合によっては適切な場合もあるが（例えば、ごく小さなプロパティ集合が関与する場合）、この従来から利用可能な「フラットな」プロパティ構造は、時間の経過とともに管理および／または使用が難しくなる可能性がある（例えば、利用可能なプロパティの総数が増える）。また、このフラットなプロパティデータ構造体を使用する場合、ユーザは、それぞれの所望のプロパティを入力し、および／または個別のファイルに関連付けることを別々に行わなければならない。これは、時間のかかる作業である。それに加えて、プロパティをそれぞれのファイルに正確に、および／または完全に関連付けることができないため、ユーザが後から所望のデータを検索し、特定し、および／または取り出すことが制限される可能性がある。例えば、異なる個々の利用可能なプロパティの数が増えるにつれ、検索クエリにおいて、ファイルに関連付けられている個々のプロパティの１つまたは複数を正確に指定しなければならない場合に、ユーザが確実にアイテムを取り出すことがますます困難になる。

本発明による少なくともいくつかの例示的な態様では、ユーザは、電子ファイルとともに少なくともいくつかのファイル「プロパティ」データを、例えば、メタデータとして割り当てて、格納することができ、その場合、割り当てられたプロパティデータは、階層構造の一部である。ユーザが利用できるプロパティが増えてきても（例えば、新しいプロパティのユーザ指定および／またはユーザ定義を通じて）、本発明のいくつかの実施例による階層構造のプロパティを備えることにより、ユーザは、単純な１つのプロパティ割り当てアクションを通じてファイルに複数のプロパティを素早く割り当てることができる。また、本発明のいくつかの実施例による階層プロパティの可用性と使用により、ユーザは、プロパティ値の順序付けに対する制御を高めることができ（例えば、階層の表示では、階層内で高い最もふつうの、または重要な要素を用意するなど）、さらに、ユーザは、プロパティの値同士の関係を表現し、アイテムを取り出すか、または値をアイテムに割り当てるときにそれらの関係を反映させることができる。また、本発明のいくつかの実施例による階層プロパティの可用性および使用により、ユーザは、プロパティ内で生成される値を編成し、この編成を使用してアイテムを閲覧し取り出すやむを得ない手段を与えられる。以下でさらに詳しく説明するように、本発明のいくつかの実施例による階層プロパティの使用により、ユーザは、単一プロパティを使用して、異なるプロパティ間でファイルを容易にナビゲートし、所望のファイルを特定し、および／またはファイルを取り出すことができる（少なくともいくつかの場合において、検索されるプロパティが、ユーザによりファイルに明示的に割り当てられず、単に、ユーザにより割り当てられたプロパティの階層の一部であった場合でも）。

図８７Ａは、デジタル画像、音楽、ビデオ、電子ドキュメントなどの様々な電子ファイルに関連して使用することができる「ｋｅｙｗｏｒｄ」プロパティに対する例示的なプロパティ階層構造２００を示している。この実施例では、ユーザは、ファイルが最初に格納され、作成され、ダウンロードされたとき、修正され、編集され、移動されたときなどに、プロパティをファイルに割り当てる際に使用することができる階層構造２００を定義している。この階層構造２００において、「Ｐｅｏｐｌｅ」ノードは、階層２００内の親レベルノードを構成する。「Ｐｅｏｐｌｅ」ノードは、３つの直接の子ノード（つまり、「Ｆｒｉｅｎｄｓ」、「Ｆａｍｉｌｙ」、および「Ｃｏ−Ｗｏｒｋｅｒｓ」）を含み、これらの子ノードのはそれぞれ、図に示されているように、さらに個別の子ノードを含む。使用時に、キーワードをファイルに割り当てる（例えば、キーワードを電子ファイルに関連付けられているメタデータに含める）と、その特定のキーワードがファイルに関連付けられるだけでなく、階層内の関連付けられているキーワードの上位の親キーワードがそのファイルに関連付けられる。図８７Ａに基づくより詳細な実施例として、この例示的なシステムおよび方法では、これらのキーワードは、割り当てられたキーワード「Ｄａｄ」に関連付けられている階層パス内に存在するため（つまり、この実施例で適用される階層キーワードデータ全体は、Ｄａｄ＞Ｆａｍｉｌｙ＞Ｐｅｏｐｌｅである）、キーワード「Ｄａｄ」を電子ファイルに割り当てた場合も、キーワード「Ｆａｍｉｌｙ」および「Ｐｅｏｐｌｅ」がそのファイルに自動的に関連付けられる。したがって、３つの用語「Ｄａｄ」、「Ｆａｍｉｌｙ」、および／または「Ｐｅｏｐｌｅ」のうちのどれか１つを含む検索クエリは、このファイルに対するヒットを返す。本発明のこの実施例による階層がないと、それぞれのキーワードをファイルに関連付けたい場合、および／またはこれらのキーワードのどれかに基づいてファイルに関係する情報を取り出せるようにしたい場合に、ユーザは、これらのキーワードすべてを別々にファイルに適用しなければならない（例えば、「Ｄａｄ」、「Ｆａｍｉｌｙ」、および「Ｐｅｏｐｌｅ」のそれぞれ）。

本発明の追加の態様は、プロパティ間に存在しうる階層（例えば、ユーザ定義階層、自動生成階層など）を入力する、または取り込むシステムおよび方法に関する。必要ならば、この階層プロパティ情報は、例えば、電子ファイル自体に含まれる、および／または関連付けられているメタデータとして、フラットなパスとして、階層フォルダを様々な市販のシステムおよび方法（ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎが市販する様々なオペレーティングシステムおよびアプリケーションプログラムで利用できるフォルダを持つシステムおよび方法など）において格納する方法と似た方法で、格納することができる。より具体的には、本発明の少なくともいくつかの実施例によるシステムおよび方法では、電子ファイルの１つまたは複数の階層プロパティをフラットなパス文字列（知られているフラットなフォルダパス文字列に似ている）として格納するが、このため、シェルオペレーティングシステムでは、フォルダ階層を今日フォルダ構造を使用する様々な従来のシステムおよび方法でナビゲートし、および／または処理することができる同じまたは類似の方法で階層プロパティを使用して格納されているファイルに関係する情報を正しくスタッキングし、フィルタ処理し、グルーピングし、および／または他の何らかの方法でナビゲートまたは処理することができる。同様に、プロパティに対し階層データ構造を実現することにより、ユーザは、知られている、および従来のフォルダシステム内のサブフォルダに入ることができる方法と似た方法で、サブプロパティ内に入り込み、階層内の下位子プロパティレベルに到達することができる。

データ構造（例えば、ファイルに関連付けられているメタデータなど、データセットまたはフィールドの）では、様々なプロパティ値を、上述のフラットなパス文字列などのパスにより区別することができる。この方法で、個々の値（例えば、個々のノード名）は、階層内に複数回出現する可能性があるが、ただし、同一ノード名または値へのパスが、その名前が出現するそれぞれの場所で異なるものとする。図８７Ａは、一実施例を示している。特に、図８７Ａに示されているように、値「Ｊｉｍ」は、「Ｆａｍｉｌｙ」ノードと「Ｃｏ−Ｗｏｒｋｅｒｓ」ノードの両方の下に表示される。これら２つの「Ｊｉｍ」値へのパスは、互いに異なるので（つまり、Ｐｅｏｐｌｅ＞Ｆａｍｉｌｙ＞ＪｉｍとＰｅｏｐｌｅ＞Ｃｏ−Ｗｏｒｋｅｒｓ＞Ｊｉｍ）、同じ最終的な終端名（適宜図８７Ａに示されているのと同じ階層レベル上の）を含む、これら２つの値は、階層内で問題なく共存することができる。特定のノード名または値は、それぞれのインスタンスにおけるそのノード名または値へのパスが、同じ名前または値への他のすべてのパスと異なる場合に、階層内に何回も出現しうる。

本発明の追加の例示的な態様は、同じ名前またはノード値を使用する階層構造の異なる分岐内のプロパティ同士を明確にするプロセスに関する。図８７Ａとともに上で説明されている実施例では、名前「Ｊｉｍ」は、家族の一員および同僚の両方に関連付けられている。これら２つの場合を区別するために、本発明の少なくともいくつかの実施例によるシステムおよび方法では、注目する２つの場合について階層の上位レベルの値を比較して、注目する値がまれな親プロパティ、ノード、またはパスを持つかどうかを判定するだけでよい。上の実施例を使用して、本発明の少なくともいくつかの実施例によるシステムおよび方法では、それぞれの「Ｊｉｍ」ノードの親ノードを見て階層内の２つの共通ノード名を区別することができる。この調査の結果、１つの「Ｊｉｍ」ノードは親ノードとして「Ｆａｍｉｌｙ」を持つが、他の「Ｊｉｍ」ノードはその親ノードとして「Ｃｏ−Ｗｏｒｋｅｒｓ」を持つことがわかった。その直接の親ノードは異なり、区別可能であるため、これら２つの「Ｊｉｍ」ノードは、プロパティ階層構造２００内で共存することができる。もちろん、異なる親ノード名は、考察されている（複数の）ノードの直接の親ノードに配置される必要はない（例えば、異なる名前が付けられている親ノードは、祖父母ノードレベル、さらに上位のノードレベル、および／または階層構造内の異なるノードレベルに配置することが可能である）。

しかし、図８７Ｂに例示されている階層構造８７５０は、典型的には、本発明による少なくともいくつかの例示的なシステムおよび方法において、許されないであろう。より具体的には、図に示されているように、図８７Ｂの階層構造８７５０は、最低レベルのいくつかのノードを除いて、図８７Ａの階層構造８７００に類似している。図８７Ｂでは、「Ｆａｍｉｌｙ」ノードは、同じ名前を持つ同じ階層レベルにある２つの子ノードを含む（つまり、２つの「Ｊｉｍ」ノード）。これらの「Ｊｉｍ」ノードのそれぞれへのフラットなパス文字列は、同じであるため（つまり、Ｐｅｏｐｌｅ＞Ｆａｍｉｌｙ＞Ｊｉｍ）、オペレーティングシステムおよび／またはアプリケーションプログラム側で、一方のノードを他方のノードから区別することはできず、したがって、フラットなパス文字列「Ｐｅｏｐｌｅ＞Ｆａｍｉｌｙ＞Ｊｉｍ」が使用されたときにはいつでも曖昧さが残るであろう。図８７Ｂの実施例に示されているようにユーザが２つの同一のプロパティパスを設定しようとした場合、本発明の少なくともいくつかの実施例によるシステムおよび方法では、エラーメッセージを表示し、ダイアログボックスを表示し、新しい名前の入力を要求し、および／またはこの名前または値がこの場所の階層構造内において許されないことをユーザに何らかの方法で指示する。

プロパティ値は、本発明から逸脱することなく、望む方法で、および／または好きなときに、個別のファイルに割り当て、および／または関連付けることができる。例えば、新しいファイルがユーザのコンピュータシステムまたはネットワークにダウンロードされ、および／または保存される場合に、プロパティ値をファイルに割り当てる機会をユーザに与えることができる。図８８は、ユーザがファイルを自分のコンピュータシステムまたはネットワークに保存する場合に使用でき、必要ならば、１つまたは複数のプロパティをファイルに割り当てる場合に使用できる、例示的なユーザインターフェース８８００を示している。図に示されているように、ユーザインターフェース８８００は、ナビゲーションパネル８８０２を備え、これは、ファイルに関連付けられる、および／または割り当てることができるプロパティまたは他の情報の少なくとも一部を表示する（例えば、新しいファイルに関係する情報が入力パネル８８０４に入力されるとき、「ｅｄｉｔｐｒｏｆｉｌｅ」プロシージャで、および／または他の好きなときに）。特に、ナビゲーションパネル８８０２内のプロパティは、階層状に配列される。様々なプロパティは、所望の方法で、例えば、入力パネル８８０４（例えば、「ｋｅｙｗｏｒｄ」入力ボックス内の）の適切な場所にノード名を入力または書き込む、ナビゲーションパネル８８０２からプロパティ名を「ドラッグ＆ドロップ」で入力パネル８８０４内の適切な場所に落とすなどにより、ファイルに割り当て、および／または関連付けることができる。他の実施例として、必要ならば、ファイルのアイコンまたは他の表現を（例えば、ファイル一覧から）ナビゲーションパネル８８０２内の所望の値またはノード名上にドラッグし、そのアイコンまたは他の表現をその場所にドロップすることにより、プロパティを割り当てることができる（必要ならば、ナビゲーションパネル８８０２内の階層は、アイコンまたは他のファイル表現を親プロパティ値上にドラッグしてそのプロパティ値の上に留めておく（ドロップしない）と、親プロパティ値（可能な場合）が階層の少なくとも次のレベルに展開する（例えば、いくつかのフォルダが現在利用可能なシステムおよびプログラム内で「自動展開」するのと同じ方法で））。図８８に示されているように、ナビゲーションパネル８８０２を通じてプロパティ値をファイルに割り当てることに加えて、本発明の少なくともいくつかの実施例による階層プロパティシステムのユーザは、以下でさらに詳しく説明するように、その階層をナビゲートまたは検索し、その階層を管理および／または編集し、および／または他のアクションを実行することができる。

本発明の少なくともいくつかの実施例により、ファイルまたは他のアイテムが他のプロパティ値の子であるプロパティ値（例えば、図８８の値「Ｐｌａｙｏｆｆｓ」）に割り当てられる場合、そのファイルまたは他のアイテムも、自動的に、割り当てられたプロパティ値に関連付けられているあらゆる親プロパティ値を自動的に継承する（例えば、この具体的な実施例における「ＳｐｏｒｔｓＰｉｃｓ＞Ｂａｓｋｅｔｂａｌｌ」）。さらに、必要ならば、親プロパティ値を、そのプロパティ値がその下に１つまたは複数の子プロパティ値を持つ場合であってもファイルまたはアイテムに割り当てることができる（例えば、「Ｂａｓｋｅｔｂａｌｌ」プロパティをファイルに割り当てることができる）。このよう場合、本発明による少なくともいくつかの例示的なシステムおよび方法において、親プロパティはファイルに割り当てられるが、その子プロパティ値（つまり、この実施例の「Ｐｒａｃｔｉｃｅ」または「Ｐｌａｙｏｆｆｓ」）はいずれも、ファイルまたはアイテムに自動的に割り当てられない（その親プロパティは割り当てられるが）。もちろん、必要ならば、システムおよび方法も、本発明から逸脱することなくこのような状況において子プロパティをファイルに自動的に割り当てるか、または関連付けるために設定することが可能である。

以下でさらに詳しく説明するように、本発明の少なくともいくつかの実施例により、親プロパティ値を検索要素またはパラメータとして含むリストファイル、検索、または他のクエリは、指定された親プロパティ値とその子プロパティ値のどれかの両方のタグが付いているすべてのアイテムを返す。この方法では、本発明のいくつかの実施例によるストレージシステムおよび方法を使用することで、ユーザは、比較的少ない非常に具体的な説明的プロパティをタグとしてアイテムに簡単に付けることができるが（例えば、階層内の低位レベルで）、階層構造内で次第に広くなる親ノードの下でプロパティを配列することにより、これらのタグ付きアイテムは、比較的広い検索クエリへの応答であっても直ちに出現させることができる。必要ならば、本発明の少なくともいくつかの実施例により、検索結果、リストファイル結果、またはファイルプレビュー結果が検索クエリへの応答として表示される場合、ファイルに割り当てられた主値（例えば、ユーザにより割り当てられた実際の値）は、ハイライト表示され、および／または何らかの方法でユーザに知らされるか、または利用できるようにされる。

利用可能な（例えば、ユーザ、システム、または他のものによりすでに定義されている）、および／または格納されている階層プロパティは、本発明から逸脱することなく、好きなときに、および／または所望の場所に、本発明のいくつかの実施例によるシステムおよび方法により表示することができる。例えば、図８８に示されているように、プロパティは、「Ｓａｖｅ」または「ＳａｖｅＡｓ」オペレーション（例えば、ナビゲーションパネル８８０２内の）の実行時に表示することができる。これらは、ファイルの「ｓｅａｒｃｈ」、「ｌｉｓｔ」、または「ｖｉｅｗｉｎｇ」オペレーション実行時に、例えば図８８のナビゲーションパネル８８０２に例示されているのと同じ階層ツリーレイアウト内で表示することもできる。さらに、必要ならば、本発明のいくつかの実施例による階層プロパティは、今日アプリケーションプログラムおよび／またはオペレーティングシステムにより従来のプロパティが表示されるどれかおよび／またはすべての場所に表示することができる（例えば、「ｌｉｓｔｖｉｅｗ」表示に示されているプロパティとして、「ｉｔｅｍｄｅｔａｉｌｓ」表示に示されているプロパティとして、ファイル「ｐｒｅｖｉｅｗ」表示に示されているプロパティとしてなど）。さらに、必要ならば、本発明によりいくつかの実施例による階層プロパティは、プロパティをサポートするツリーコントロールなどで、プロパティをナビゲートするために使用されるコントロールに表示することができる。

図８８は、ツリーコントロール画面内の階層プロパティの表示の一実施例を示している（例えば、ナビゲーションパネル８８０２）。その一方で、図８９は、アイテムまたはファイル「ｐｒｅｖｉｅｗ」画面８９００内のプロパティ情報の表示の一実施例を示している。図８９に示されているように、この例示的なアイテムまたはファイル「ｐｒｅｖｉｅｗ」画面８９００は、アイテムのサムネイルまたはアイコン表示８９０２（例えば、この実施例では、ファイルに含まれる画像の縮小版）だけでなく、ファイル名、保存日時、ファイルサイズ、およびユーザ入力「ｃａｐｔｉｏｎ」情報などのファイルに関係する特定のシステムおよび／または他の事実情報をも含む。それに加えて、このアイテムまたはファイル「ｐｒｅｖｉｅｗ」画面８９００には、割り当てられたキーワード（フラットなパス文字列形式で表示される）、画像件名ＩＤ、ユーザ入力評価情報などを含む、ユーザにより入力された何らかの「ｐｒｏｐｅｒｔｙ」情報が表示される。もちろん、プロパティは、本発明から逸脱することなく、そのような画面にいくつでも一覧表示することができる（適宜、非表示プロパティに関する情報を表示する機能とともに）。

プロパティ情報は、本発明から逸脱することなく、好きなときに、望む方法で、個別のファイルに入力、および／または関連付けることができる。ファイルが最初にコンピュータシステムまたはネットワーク上に保存されるときにファイルとともにプロパティ情報を含むことに加えて、「ｅｄｉｔｐｒｏｆｉｌｅ」または「ｅｄｉｔｐｒｏｐｅｒｔｉｅｓ」コマンドに応答して、ファイルが開かれるとき、編集されるとき、編集されるとき、または使用されるときなど、他の好きなときに、個々のファイルに関連付けられているプロパティに追加するか、そこから削除するか、および／または修正することができる。プロパティは、キー入力（適宜階層内の任意のレベルから、適宜一致する文字列の「オートコンプリート」を使用して）、ドラッグ＆ドロップオペレーション、「右クリック」オペレーション、ペン「プレス＆ホールド」オペレーションなどにより入力することができる。特定のファイルに関連付けられているプロパティの設定、編集、および／または削除に使用できるツールも、本発明から逸脱することなく、プレビュー画面８９００においてアクセスし、使用することができる。

さらに、階層配列になっているプロパティの実際の内容は、本発明から逸脱することなく、好きなときに、および／または所望の方法で、例えば、従来のアプリケーションプログラムおよびオペレーティングシステムにおいて従来の「フォルダ」構造に追加する、そこから削除する、および／または他の何らかの方法で編集する方法で、ユーザが変更することができる。例えば、新しいプロパティは、既存のプロパティの下で追加することができ、および／または既存のプロパティは、マウスボタンを「右クリック」するアクション（適切なユーザインターフェース、例えば、「ｉｎｓｅｒｔｎｅｗｐｒｏｐｅｒｔｙ」、「ｄｅｌｅｔｅｅｘｉｓｔｉｎｇｐｒｏｐｅｒｔｙ」、「ｃｈａｎｇｅｎｏｄｅｌｅｖｅｌｏｒｐｏｓｉｔｉｏｎ」、切り取り、コピー、貼り付け、または他の適切なアクションを含むメニューを表示できる）を介して削除することができる。他の実施例として、必要ならば、階層構造内の既存のプロパティの場所は、変更することができ、例えば、図９０に例示されているように、「ドラッグ＆ドロップ」オペレーションを介して移動することができる。より具体的には、図９０は、例えば、デジタル写真の並べ替えおよび編集用のアプリケーションプログラムの階層プロパティの一覧を表示するナビゲーションパネル８８０２を例示している。図９０の左側は、ユーザが「Ｃａｍｐｉｎｇ」親ノードの下から「Ｋｅｙｗｏｒｄ」ノードの直下の階層レベルへドラッグ＆ドロップオペレーション（矢印９００２により例示されている）でキーワード「Ｏｃｅａｎ」に対するアイコンを移動することを示している。ドラッグオペレーションを介して（例えば、左マウスボタンを押し下げたまま）所望の場所に位置が決まった後（例えば、この実施例では「Ｋｅｙｗｏｒｄ」ノードの真上）、「Ｏｃｅａｎ」ノードは、その場所にドロップすることにより（例えば、マウスの左ボタンを離すことにより）階層内の位置を変更できる。このアクションは、図９０の右側に示されているようにノード「Ｏｃｅａｎ」の位置を変更する。必要ならば、さらにドラッグ＆ドロップオペレーションを通じて前の子ノード「Ｐａｃｉｆｉｃ」および「Ａｔｌａｎｔｉｃ」を移動し、「Ｏｃｅａｎ」ノードを随伴させることができる。それとは別に、必要ならば、本発明の少なくともいくつかの実施例によるシステムおよび方法は、ノードの位置を変更すると子ノード（もしあれば）の位置が自動的に変更されるように動作することができる。必要ならば、本発明の少なくともいくつかの実施例によれば、ユーザは、この方法でプロパティ値をドラッグしながら「Ｃｏｎｔｒｏｌ」ボタンを押す（または他の所定のアクションを実行する）ことで、プロパティ値（適宜その子プロパティ値）のもう１つのコピーを異なるプロパティ値の下に表示させることができる（例えば、貼り付けコマンド使用して）。もちろん、ノードおよび／またはそのそれぞれの子ノードの切り取り、コピー、および／または位置変更を行う他の方法およびプロトコルは、本発明から逸脱することなく使用することができる（例えば、折り畳まれた子を持つノードの位置変更は、ノードおよびその子のすべての位置を１アクションで変更するために使用することができるが、その子が完全に展開され、表示されているノードの位置変更は、その子なしで、親ノードの位置を変更するだけのために使用することができる）。ノードを移動する他の既定の方法および手段は、本発明から逸脱することなくシステムおよび方法で使用することができる。

少なくともいくつかの場合において、本発明によるシステムおよび方法の具体的特性に応じて、位置変更アクション実行時に、例えば、同じプロパティ名が移動されるプロパティに対する新しいパスまたは位置に複数回出現した場合に、エラーが発生しうる。本発明のいくつかの実施例によるシステムおよび方法では、所望の方法で、例えば、所望の移動を完了しないこと、ユーザがパス内で名前を変更することができるインターフェースを備えること、問題を是正するため様々なオプションのある問題をユーザに知らせるためのダイアログボックスを表示することなどにより、そのような状況を扱うことができる。他の実施例では、必要ならば、パス（例えば、Ｌｏｃａｔｉｏｎ＞ＮｅｗＹｏｒｋ＞ＮｅｗＹｏｒｋ）内で単一名を複数回使用できるシステムおよび方法を開発することができ、このようなエラーは、同じ全体的にフラットなパス文字列名を持つ複数のノードを生成しようと試みない限り、出現することはない。

本発明のいくつかの実施例による階層プロパティ特性を利用するユーザは、プロパティに対し比較的大きな階層構造を構成し、階層構造全体が、全展開されときに、ナビゲーションパネル８８０２内の利用可能な空間および／またはその表示画面の高さを超えて広がるようにできる。このような状況は、本発明から逸脱しない所望の方法で、例えば、ナビゲーションパネル内にスクロールバーを用意する、子ノードを親ノードの下に折り畳めるようにする（そして例えば従来利用可能なシステムおよび方法で階層フォルダ構造が展開され、折り畳まれるのと類似の方法で、ユーザ入力に基づいて完全展開または折り畳めるようにする）などにより対処することができる。図８８および９０に例示されている種類のナビゲーションパネル８８０２は、開かれると、例えば、常に階層構造の場所の最上位、階層構造内の最も頻繁に使用される場所、階層構造内の一番最近に使用された場所、開いているドキュメント（もしあれば）を含む階層構造内の場所、完全展開状態、完全折り畳み状態、もっとも最近に使用された状態など、階層構造内の所望の場所で、および／または所望の展開／収縮状態で、開くことができる。また、ナビゲーションパネル８８０２は、例えば、ユーザ設定、既定値などに基づいて、左側または右側などの、表示画面上の所望の場所に表示することができる。

必要ならば、本発明の少なくともいくつかの実施例によるシステムおよび方法は、出荷時に基本階層構造を含むことができ、この基本構造は、より完全で、よりリッチな階層、例えば、それ独自の用途を対象とするようにより絞り込まれ、それに合わせてカスタマイズされた階層を構築する出発点としてユーザにより使用されうる。例えば、デジタル画像、オーディオ、ビデオ、または他のユーザデータを格納するためのこのような所定の基本階層構造の実施例は、Ｋｅｙｗｏｒｄｓ、Ｅｖｅｎｔｓ、Ｐｌａｃｅｓ、Ｐｅｏｐｌｅ（例えば、潜在的に、Ａｕｔｈｏｒ、Ｐｈｏｔｏｇｒａｐｈｅｒ、ＳｕｂｊｅｃｔＰｅｏｐｌｅなどの子ノードを含む）、Ｄａｔｅｓ、ＭｙＰｉｃｔｕｒｅｓ、ＭｙＭｕｓｉｃ、ＭｙＤｏｃｕｍｅｎｔｓ、ＭｙＶｉｄｅｏｓなどの基本ノードを含むことができる。本発明から逸脱することなく、所望の情報をこの基本階層内に含めることができる。

図９１は、例えば、「ＬｉｓｔＦｉｌｅｓ」、ｓｅａｒｃｈ、ｑｕｅｒｙ、ｎａｖｉｇａｔｅ、または他の適切なコマンドへの応答として表示される場合の例示的な表示画面９１００を示している。特に、この例示的な表示画面９１００の左側は、階層プロパティ用のナビゲーションパネル９１０２を含み、その下に、このユーザのファイルのうちの少なくともいくつかが格納される（例えば、この実施例のデジタル写真格納／編集システムに関係する）。本発明によるシステムおよび方法の少なくともいくつかの実施例において、ナビゲーションパネル９１０２を備える表示画面９１００は、ユーザの階層プロパティ用の一次エントリおよび対話操作点であってよい。このような画面９１００から、ユーザは、ファイルを表示し、検索クエリを表示し、および／またはそれらのファイルに関連付けられている他の格納されているデータとともにすでに作成されている様々な階層カテゴリに基づいてファイルをフィルタ処理することができる。図９１に示されているように、階層内のノード「Ｋｅｙｗｏｒｄ」をハイライト表示にすると（例えば、左マウスボタンのクリックアクションにより）、キーワードが割り当てられているか、または関連付けられているユーザファイルの完全な一覧がプルアップされる。この例示的なシステムおよび方法では、このアクションにより、画面９１００の表示部分９１０６内の個別のファイルを例示するサムネイルアイコンまたは画像９１０４を含むデジタル写真ファイルの一覧がプルアップされる。この実施例の個々のファイルは、ハイライト表示されている検索条件の直下にある階層の個々の子レベルに基づいてグルーピングされる（つまり、この例示されている実施例において「ＳｐｏｒｔｓＰｉｃｓ」、「Ｓｕｍｍｅｒ」、および「Ｃａｍｐｉｎｇ」グループとしてグルーピングされるが、階層の他のレベル（つまり、「Ｆｌｏｗｅｒｓ」および「Ｏｃｅａｎ」）は表示部分９１０６のサイズのせいで表示されない）。もちろん、検索またはリストビュー結果を表示する多くの方法が、本発明から逸脱することなく可能である。

本発明から逸脱することなく個別のファイルとともに階層プロパティを格納または表現するために、所望の任意の形式または書式を使用することができる。例えば、子プロパティ値がファイルに割り当てられる場合、階層構造を通るそのプロパティ値へのパスは、実際のファイルの一部として格納され、および／またはそれに関連付けられることができる（例えば、そのファイルに含まれ、および／または関連付けられているメタデータとして）。例えば、階層構造の表現またはデータ構造体は、少なくとも、（親プロパティ値）［区切り文字］（子プロパティ１）［区切り文字］（子プロパティ２）．．．を含むことができる。図９１に示されているより具体的な実施例に戻ると、関連付けられている個々のプロパティ「Ｆｏｏｔｂａｌｌ」および「ＧａｍｅｓＡｔｔｅｎｄｅｄ」とともに保存されるファイルは、少なくともいくつかの場合において、例えば、「Ｋｅｙｗｏｒｄ／ＳｐｏｒｔｓＰｉｃｓ／Ｆｏｏｔｂａｌｌ；」および「Ｋｅｙｗｏｒｄ／ＳｐｏｒｔｓＰｉｃｓ／ＧａｍｅｓＡｔｔｅｎｄｅｄ」の形式で、ファイルに関する情報とともに表示されるファイルに関連付けられたメタデータを持つことができる（例えば、図８９に示されているように）。これらの実施例では、親プロパティ値は、「Ｋｅｙｗｏｒｄ」であり、それぞれのインスタンス内の第１の子プロパティ値は、「ＳｐｏｒｔｓＰｉｃｓ」であり、第２のプロパティ値は、それぞれ「Ｆｏｏｔｂａｌｌ」および「ＧａｍｅｓＡｔｔｅｎｄｅｄ」であり、区切り文字は、スラッシュ「／」である（区切り文字は、プロパティ名を区切るために使用される特殊文字であってよく、またこの区切り文字は、システムにおける混乱を避けるために、プロパティ名に含めることができない）。もちろん、本発明から逸脱することなく、子プロパティレベルは、フラットなパスデータ文字列にいくつでも含めることができる。

ナビゲーションパネル、例えば、パネル９１０２に一覧表示されているプロパティは、少なくとも一部は、様々な知られているオペレーティングシステムおよびアプリケーションプログラムにおける従来のフォルダの挙動と似た挙動を示すことができる。例えば、ナビゲーションパネル９１０２内の階層プロパティの展開および／または折り畳みの仕方は、類似のフォルダナビゲーションパネルまたはコントロールでフォルダを展開および／または折り畳み仕方と類似している。より具体的な実施例では、親プロパティの下に子プロパティ値を見て表示するために、ユーザは、プロパティの左に用意されている「ウィジェット」をクリックすることができる（例えば、図９１の「Ｓｕｍｍｅｒ」キーワードについて中に「＋」記号が含まれるウィジェットに注意されたい（ウィジェット内の「＋」記号は、１つまたは複数の追加の非表示子プロパティが存在することを示し、ウィジェット内の「−」記号は、この例示的なシステムにおいて特定のプロパティがすでに展開されていることを示す））。少なくともいくつかの実施例では、プロパティまたはノードが子を持たない場合、左のウィジェットは、省略することができるか、または追加のインジケータ（例えば、「＋」または「−」記号など）を含むことができないか、または他のインジケータを含むことができるか、または子ノードの欠如を他の所望の方法で示すことができる。図９１に示されているように、インデント方式も、階層構造をわかりやすく示すために使用することができる。特に、個々のファイルは、複数のプロパティが関連付けられているため、同じファイルまたはアイテムが、表示パネル９１０６内の複数のグループに出現する可能性がある（例えば、Ｐｉｃｔｕｒｅｓ１３および４４は、図９１の「ＳｐｏｒｔｓＰｉｃ」グループと「Ｓｕｍｍｅｒ」グループに出現することに注意されたい）。

本発明の少なくともいくつかの実施例によるシステムおよび方法は、ユーザが階層プロパティ構造を変更し、修正し、および／または使用するさらに他の方法もサポートすることができる。一実施例では、表示パネル９１０６内のどのアイテムも選択されていない場合に右クリックアクションによりナビゲーションパネル９１０２内のプロパティ値が選択される状況において、ユーザは、その後、新しい階層プロパティを子として右クリックで選択されたノードの下に追加するオプションを与えられる（例えば、インターフェースを介して）ことができる（例えば、編集可能テキストボックスを持つ新しいノードが、階層構造内の新しいプロパティ値の場所に表示され、それにより、ユーザは、新しいプロパティ値をキー入力（または他の何らかの方法により入力）することができる）。「削除」機能またはオプションは、例えば、右マウスボタンクリックを介して与えることができ、これにより、ユーザは、個別のノード、１つのノード、およびその子ノードのすべてなど、階層の所望の部分を削除することができる。「格上げ」および「格下げ」機能を備えることができ、これにより、例えば、ユーザは、プロパティ値を選択し、それをそれぞれ（適宜、その子の値すべてとともに）階層内で１レベル上げ下げすることができる（例えば、格上げでは、選択されたノードは、前の直接の親ノードのピアとして表示されるようなレベルに移動する）。さらに他の実施例では、例えば、右マウスボタンクリックを介して「名前変更」機能を備えることができ、これにより、ユーザは、任意のプロパティ値またはノードに異なる名前を付けることができる（上述のように、適宜、同じ名前がパス内で二度使用される場合、および／または２つの同一のフラットなパス名が表示される場合に制限が付く）。ファイルが表示パネル９１０６内で選択されたときに、例えば、右マウスボタンをクリックを介して、本発明のいくつかの実施例により実現できる潜在的機能は、「ｒｅｍｏｖｅｐｒｏｐｅｒｔｙ」機能および「ａｄｄｐｒｏｐｅｒｔｙ」機能を含み、これは、１つまたは複数のプロパティを、そのファイルとともに格納されている、および／またはそのファイルに関連付けられているメタデータまたは他のデータから削除し、および／またはそれに追加するために使用することができる。もちろん、上記の機能を実行する他の機能および／または他の方法も、本発明から逸脱することなく提供することができる。必要ならば、上述の様々な機能を介して変更される与えられたプロパティおよび／またはパスでタグ付けされたすべてのファイルまたはアイテムは、ユーザがパスおよび／またはプロパティへの変更を行ったことを反映するように更新された対応するプロパティデータおよび／またはパス情報を持つことができる。

本発明の少なくともいくつかの実施例による追加の機能は、例えば、階層プロパティデータを含む既存のファイルが階層プロパティデータをサポートするが、必ずしも、新しく受け取った（複数の）ファイルに対応する同じ使用可能な階層プロパティ構造を持たないシステムまたはネットワークを有する他のユーザに送信される場合に、階層プロパティを共有することに関する。本発明の少なくともいくつかの実施例によるシステムおよび方法は、フラットなプロパティ値を持つファイル（または他のアイテム）が共有される方法と類似の方法でファイル（または他のアイテム）を階層プロパティ値と共有できるように構成することができる。本発明によるシステムおよび方法の少なくともいくつかの実施例によれば、ファイルまたは他のアイテムが階層プロパティ値とともにシステム内に入る場合の既定の挙動は、（ａ）新しいファイルの階層は、階層キーワードが、典型的には、システムまたはネットワークにより、例えば、新しく受け取ったファイルが元々対象のシステムまたはネットワーク上で作成された場合と同じ方法で表示されるすべての領域に、表示される、（ｂ）新しいファイルに必要なものと同じ階層がすでに新しい受け取り側のシステムまたはネットワーク上に存在する場合に、新しいファイルアイテムは、システムまたはネットワーク上にすでにある階層に関連付けられる、（ｃ）新しいファイルに必要なパスの一部のみが受け取り側のシステムまたはネットワーク上に存在する場合に、新しいファイルを受け入れる階層の残りの部分は、受け取り側のシステムまたはネットワーク上に作成される、（ｄ）新しいファイルに必要なパスはどれも、受け取り側のシステムまたはネットワーク上に存在しない場合に、新しいファイルを受け入れる新しい階層は、受け取り側のシステムまたはネットワークに追加される、という挙動である。

以下では、ファイルを受け取り、新しいユーザのシステムまたはネットワークに保存する状況におけるプロパティ階層共有のさらに詳しい実施例を示す。この実施例では、受け取り側のユーザは、パス／プロパティ値「Ｆａｍｉｌｙ／Ｂｒｏｔｈｅｒｓ／Ｔｏｂｙ」を含む既存のプロパティ階層を持つ。新しいファイルは、受け取り側のユーザにより受け取られ（例えば、電子メール添付）、受け取り側のシステムに保存される、この新しいファイルは、ファイル送り側の階層構成からのメタデータを含む。ファイル送り側とファイル受け取り側は、両方とも、本発明の一実施例による階層データ構造を伴うプログラム、システム、および／または方法を操作する。以下の表は、受け取り側ユーザのシステムが様々な異なるシナリオにより新しいファイルの受け取りを処理することができる方法を説明している。

ファイルに関連付けられている様々なプロパティ値は、本発明から逸脱することなく、適切な時期に、適切な方法で、表示することができる。例えば、図８９にとともに上で説明されているように、プロパティ情報は、ファイルに関連付けられている「ｐｒｅｖｉｅｗ」パネル内に表示することができる。さらに例えば、必要ならば、与えられたファイルに関連付けられているプロパティは、「ｐｒｏｐｅｒｔｙ」ページとともに、またはファイルに関連付けられている「ｄｉｓｐｌａｙｐｒｏｐｅｒｔｉｅｓ」コマンドとともに含めることができる。既存のプロパティも、例えば、ｓａｖｅ、ｓａｖｅａｓ、ｅｄｉｔｐｒｏｆｉｌｅ、ｏｐｅｎｆｉｌｅ、または他の類似のオペレーションの実行時に表示することができる。必要ならば、ファイルに関連付けられている格納されたプロパティも、ファイルを開く、および／または開いている間に、例えば、ツールバーで表示することもでき、また、ユーザは、例えば、ファイルをプロパティを能動的に操作している間、保存した後、開く前などに、編集に利用できるインターフェースを持つことができる。本発明から逸脱することなく与えられたファイルに関連付けられている保存されたプロパティデータを表示するために他の多くのオプションが利用可能である。もちろん、プロパティは、本発明から逸脱することなく、いくつでも、与えられたファイルに関連付けることができる。

また、ファイルに関連付けられているプロパティは、本発明から逸脱することなく、様々な場所に、好きなだけ表示することができる。例えば、必要ならば、階層パス全体を、それぞれのプロパティ（または少なくともいくつかのプロパティ）について、ファイルに関連付けられたプロパティのうちの１つまたは複数が表示される（例えば、図８９に示されているような「ｐｒｅｖｉｅｗ」または「ｐｒｏｐｅｒｔｙ」パネル）場所に表示することができる。他の実施例として、必要ならば、割り当てられたプロパティ値自体のみを、様々な場所に表示することができる（さらに、階層の残り部分は、例えば、ナビゲーションパネルを介して、カーソルの「ホバリング」アクションなどのときに、さらに、以下でさらに詳しく説明されるファイル情報のスタッキングおよびグルーピング機能を介して表示することができる）。より具体的な実施例としては、個々のファイル（デジタル画像など）が、階層キーワード「ＳｐｏｒｔｓＰｉｃｓ＞Ｂａｓｅｂａｌｌ＞Ｐｒａｃｔｉｃｅｓ＞ＣａｒｄｉｏＤｒｉｌｌｓ」を割り当てられている場合、この長いフラットなパス文字列は、パス内の最低位の子ノード、つまり「ＣａｒｄｉｏＤｒｉｌｌｓ」を単に与えることにより少なくともいくつかの場所で表すことができる。しかし、この切り詰められたプロパティ一覧表示書式には、名前衝突を生じたり、および／またはユーザに対しいくぶん不明瞭であるという危険性がある（例えば、ノード「ＣａｒｄｉｏＤｒｉｌｌｓ」が階層内の複数の場所に存在する場合）。そのような状況では、必要ならば、追加の階層情報を最低レベルのキーワードとともに表示し、衝突情報を区別することができる。例えば、図８７Ａと併せて上で説明されているように、本発明の少なくともいくつかの実施例によるシステムおよび方法におけるそれぞれの階層ノードは、異なる、一意的なパスを持つ。この情報は、上で説明されている衝突を解決するために使用することができる。特に、例えば、上述の種類の衝突がある場合（２つの階層プロパティ値が同じ方法で視覚的に表されるものとして定義されている）、本発明の少なくともいくつかの実施例によるシステムおよび方法では、異なる親プロパティ値が見つかり、その値が表示される（適宜、衝突している最低レベルのノード情報とともに）まで衝突しているパスをトラバースする。例えば、「ＳｐｏｒｔｓＰｉｃｓ＞Ｂａｓｅｂａｌｌ＞Ｐｒａｃｔｉｃｅｓ＞ＣａｒｄｉｏＤｒｉｌｌｓ」および「ＳｐｏｒｔｓＰｉｃｓ＞Ｂａｓｋｅｔｂａｌｌ＞Ｐｒａｃｔｉｃｅｓ＞ＣａｒｄｉｏＤｒｉｌｌｓ」の両方を階層が含み、および／または個別のファイルがそれらによりタグ付けされていた場合、例えば、「ｐｒｅｖｉｅｗ」または「ｐｒｏｐｅｒｔｙ」表示における表示プロパティ情報は、例えば、「ＣａｒｄｉｏＤｒｉｌｌｓ．．．Ｂａｓｅｂａｌｌ」および／または「ＣａｒｄｉｏＤｒｉｌｌｓ．．．Ｂａｓｋｅｔｂａｌｌ」として、および／または他の何らかの適切な方法で表現され、これにより正しい階層を区別して示すことができる。

階層プロパティ情報の実用的な使い方の他の実施例として、多くの企業は少なくともある程度の階層構造をなしている（例えば、部門、事業部、場所など）という事実が挙げられる。本発明のいくつかの実施例による対象となるようにより絞り込まれているオペレーティングシステム、方法、および／またはアプリケーションプログラムは、個々の企業の構造の階層に関する性質を利用するそのような企業向けに開発することができる。例えば、企業向けに格納されているデータのプロパティに対する定義済み階層構造を含む企業の従業員により使用されるコンピュータシステム、ネットワーク、および／またはアプリケーションプログラムに対する所定の階層を実現することができる。このようなシステムおよび方法を使用することにより、データが編成され、格納される企業のシステムおよびネットワーク内に少なくともある程度総合的な実用にかなった階層構造を実現できる。

本発明のいくつかの態様は、さらに、階層プロパティデータが格納されるコンピュータ可読媒体およびコンピュータ実行可能命令が格納されるコンピュータ可読媒体に関するものであり、これにより、上述のシステムおよび方法を含む、様々なオペレーティングシステム、アプリケーションプログラム環境、および／または様々な他のシステムおよび方法において階層プロパティデータを入力し、および／または使用することができる。コンピュータ可読媒体は、上述のコンピュータ可読媒体の様々な特定の実施例において格納されるコンピュータ実行可能命令を構成することができる。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：上述のように、本発明の追加の態様は、一般に、コンピュータシステムまたはネットワーク上に格納される情報を検索し、適宜上述の階層プロパティ構造を利用することに関する。

Ｗｉｎｄｏｗｓ（登録商標）コンピュータオペレーティングシステムの場合、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎは、コンピュータシステムまたはネットワークに電子情報を保存し、編成し、そこから取り出すことに関して、現実世界のアナロジー、つまりフォルダを導入した。このフォルダシステムは、厳密には、コンピュータ上に格納され、コンピュータを通じて利用可能な電子データおよび情報に現実世界の雰囲気を付与するために導入されたエンドユーザ概念であった。コンピュータユーザは、典型的には、そのコンピュータのハードドライブを、ファイルが編成されている大きなファイリングキャビネットと考える。しかし、コンピュータシステム自体に対しては、電子ファイルは、磁気を使用して符号化され、ハードドライブに収められる（または他の何らかの方法による）単なる一連のビットにすぎず、また「フォルダ」は、それらのファイル群を参照するためのコンピュータシステム向けの単なる一手段にすぎない。

ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎのＮＴＦｉｌｅＳｙｓｔｅｍ（「ＮＴＦＳ」）では、ハードリンクをサポートする機能が導入された。この機能があるため、ユーザは、電子ファイルを複数のフォルダに配置することができるようになった。もちろん、物理的に、この機能では、それらの電子ファイルを表すビットを、コンピュータのハードドライブ（または他のストレージシステム）上に何回も複製する必要がなく、例えば、ファイルが置かれているそれぞれのフォルダに１回複製するだけでよい。むしろ、異なるフォルダで、同じファイルを逆に参照する。しかし、当初リリースされたときには、この機能は、エンドユーザに公開されなかったが、それは、単一ファイルを複数のフォルダに入れることは、ユーザの現実の物理的世界の概念とマッチしなかったからである（つまり、同じ物理的用紙は、同時に２つの別々の物理的なフォルダに配置できないということである）。

本発明の少なくともいくつかの態様を実施できる少なくともいくつかのオペレーティングシステムでは、「リスト」という新しいエンドユーザ概念が導入されつつある。物理的にアナロジーとして、「リスト」は、アイテムの集合（例えば、電子ファイル）を参照する１つのコンテナと考えられる。「リスト」をさらによく理解するために、「フォルダ」についてさらに詳しく説明する。「フォルダ」は、何らかの方法で互いに関係しているものと考えられるアイテムの「集合」またはグループと考えられる（例えば、同じ「フォルダ」内に存在することは、集合内のアイテムが「関係している」と考えられる一方法であろう）。集合またはフォルダ内のそれぞれのアイテムまたはファイルは、「ＰＡＲＥＮＴＦＯＬＤＥＲ」と呼ばれるプロパティを含むことができる（例えば、「ｃ：＼ｕｓｅｒｓ＼ｕｓｅｒａ＼ｄｏｃｕｍｅｎｔｓ＼」などのパスの形式で）。特に、このパスは、エンドユーザメタファーでもあり、必ずしも、コンピュータの物理的構造を反映するわけではない。実際、ドライブという概念自体も、メタファーと考えられるが、それというのも、単一の物理ハードドライブは、ｃドライブ、ｄドライブなど、複数の「ドライブ」にパーティション分割することができるからである。

ユーザが「集合」を定義できる他の方法は、「リスト」によるものである。「リスト」は、それぞれがアイテムの集合を定義するものとして考えることができるため「フォルダ」に関係していると考えることができる。しかし、「フォルダ」とは異なり、本発明の少なくともいくつかの実施例による「リスト」では、上述のような「ＰＡＲＥＮＴＦＯＬＤＥＲ」プロパティを使用してこの関係を定義しない。むしろ、「リスト」では、同じアイテム（例えば、電子ファイル）が複数の場所に存在していてもよい（例えば、複数の独立した「リスト」内に）。「フォルダ」のように、「リスト」は、エンドユーザ概念である。電子ファイルまたは他のアイテムを複数の「リスト」に入れても、基礎となるデータを表す実際の物理的ビットが複製されるわけではなく、むしろ、基礎の電子ファイルまたはアイテムは、その「リスト」に参照される（または何らかの方法で「リンク」される）。この説明を逆に現実世界の実施例に結び付けるために、「ＳｈｏｐｐｉｎｇＬｉｓｔ」および「Ｕｒｇｅｎｔ ‘ＴｏＤｏ’ Ｌｉｓｔ」を用意し、購入する必要なある品目と実行する必要のあることを追跡することができる。これらの「リスト」は両方とも、「ｂｉｒｔｈｄａｙｐｒｅｓｅｎｔｆｏｒｗｉｆｅ」などのアイテムを含むことができる。ユーザは、ギフトを購入することは、買い物中に行わなければならない何かおよびかなり緊急に行わなければならない何かの両方であると理解する。しかし、ユーザは、さらに、このアイテムはユーザのリストのうちの２つに入力されるため、これは、２つのギフトを購入する必要があることを意味しないことを理解している。むしろ、ギフトを購入する単一の行為により、ユーザは、それぞれのリストからそれぞれのアイテムを削除することができる。

本発明の少なくともいくつかの態様が実施できるオペレーティングシステムは、さらに、「自動リスト」を含むことができる。「自動リスト」は、「リスト」および「フォルダ」のように、アイテムの集合を定義する。これらのアイテムの集合は、コンピュータシステム上に格納されるか、またはコンピュータシステムを通じて利用可能なアイテムに関連付けられている共通プロパティ値に基づいて自動的に生成されることができる。例えば、必要ならば、ユーザは、プロパティ値ｒａｔｉｎｇ＝５ｓｔａｒに基づいて自動リストを持つことができる。この「自動リスト」機能を使用することで、ユーザは、ファイルが出現しうる特定のフォルダまたは「リスト」に関係なく星５つと評価されたファイルすべてに関係する情報を容易に特定し、確認することができる。ファイルまたはアイテムが星５つの評価を関連付けられている限り、本発明の少なくともいくつかの実施例によるシステムおよび方法は、例えばユーザのクエリで５つ星自動リストを見ることを要求したときに、このファイルまたはアイテムをこの動的に、また自動的に生成された集合の要素として自動的に含むことになる。「自動リスト」の他の実施例は、例えば、最近作成されたファイル、最近編集されたファイル、よく使用されるファイル、ＡｕｔｈｏｒＩＤ、作成日時、編集日時、ファイルタイプ、アプリケーション名などを含むことができる。

「自動リスト」の内容に関係する一態様は、リストのスコープ（つまり、「自動リスト」を生成するために検索されるファイルおよび／または場所の集合）に関する。「自動リスト」のスコープに対する様々な制限は、例えば、コンピュータが配置されている環境、ユーザ設定、コンピュータまたはネットワークが使用される方法などに応じて設定することができる。例えば、「自動リスト」のスコープは、特定のマシン、マシン上の特定のユーザのファイル、またはマシンのネットワークに、および／または本発明の範囲から逸脱しない他の所望の方法で、制限することができる。より具体的な実施例として、「５ｓｔａｒ」自動リストのスコープを、与えられた物理的コンピュータ上のファイルまたはフォルダ、および／または指定されたユーザにより作成されたファイルまたはフォルダなど、横断検索する特定のファイルまたはフォルダの集合に制限することができる。しかし、必要ならば、ユーザは、ユーザのデスクトップまたはラップトップコンピュータのいずれかに格納されているすべての「５ｓｔａｒ」ファイルを特定するなどのために、コンピュータおよび／またはそのコンピュータを含むネットワーク上のすべてを横断検索するように自動リストスコープ（または他の検索スコープ）を設定することができる。

ユーザがＰＣ上に保存するファイルがますます増え（例えば、ドキュメント、音楽、ビデオ、および画像ファイルなど）、ネットワークに接続されているコンピュータシステムがますます使用されるようになるにつれ、ユーザが絞り込んだ検索スコープ（例えば、自動リストまたは他の検索のため）を選択できることが、重要になってくると考えられる（例えば、過剰な無関係のデータ（他のユーザまたは場所からのデータ）の特定および表示を回避する、検索時間が長くなるのを回避するなどのため）。より具体的な実施例として、グラフィックスデザイナーは、検索および返される内容をＰｈｏｔｏｓ（または、適宜、特定のユーザの写真）のみを含むハードドライブ部分（例えば、ディレクトリなど）に制限するように「自動リスト」検索のスコープを設定したい場合がある。このユーザは、ＰＣ上のすべて、および／またはＰＣを接続できるネットワーク上のすべてを必ずしも検索したいわけではない。このようなユーザは、「自動リスト」用に設定された検索パラメータの条件も満たすことができる他のユーザのファイルを表示したくない場合がある。

したがって、本発明の少なくともいくつかの実施例によるシステムおよび方法では、ユーザは、「サブアイテムドメイン」を検索スコープの一部として選択し、定義することができる。「サブアイテムドメイン」は、横断検索するコンピュータシステムに対する絞り込んだスコープを定義するフォルダの集合である。このサブアイテムドメインは、ユーザがそのデータ、特定のプロパティによりマークされているアイテムなどを格納するフォルダおよび／またはサブフォルダの集合を含むことができる。

図９２Ａおよび９２Ｂは、サブアイテムドメインスコープ設定の態様のいくつかの実施例を示している。例えば、図９２Ａは、複数のユーザ（例えば、ＵｓｅｒｓＡ、Ｂ、およびＣ）により共有されている個々のコンピュータまたはネットワーク９２００を例示しており、図のそれぞれのノードは、様々なユーザにより、および／または様々なユーザ向けに作成されたフォルダまたは他のファイル「コンテナ」集合を示している。上で説明されているように、「自動リスト」の生成に関係する活動を含む、検索活動において、ユーザは、これらの利用可能な「フォルダ」または他の要素の一部のみを検索するようにシステムを設定することができる。例えば、特定の検索または自動リストに対し「サブアイテムドメインスコープ」を設定することにより、ユーザは、自分の検索をファイルのいくつかのフォルダにのみ制限することができる。図９２Ａは、三角形９２０２により表され、フォルダ「ＵｓｅｒＢ」を含み、その下にある、フォルダのみを検索するように設定されている「サブアイテムドメイン」を示している。もちろん、「サブアイテムドメイン」は、本発明から逸脱することなく、ネットワーク９２００の一部を包含するように設定することができる。それに加えて、必要ならば、スコープは、本発明から逸脱することなく、与えられたコンピュータシステムにより生成された様々な異なる自動リストについて異なっていてもよい。図９２Ａに示されていいるようなサブアイテムドメインスコープを使用することにより、検索がいくつかの指定されたソースデータ（例えば、この実施例におけるＵｓｅｒＢのデータ）のみを対象とするようにより絞り込こまれているため、「自動リスト」または他の検索活動の結果はかなり関連性のあるものにできる。また、実行速度は、検査すべきアイテムの集合が小さいので、高めることができる。もちろん、ユーザインターフェースは、自動リスト検索を含む、検索活動についてサブアイテムドメインを容易に調節し変更することができるように用意することができる。

この設定可能な「サブアイテムドメイン」の内容は、単一のフォルダ、またはさらには、フォルダ層の単一の共通分岐に限る必要はない。むしろ、必要ならば、本発明によるシステムおよび方法の少なくともいくつかの実施例によれば、ユーザは、複数のフォルダ内、適宜ネットワークまたはコンピュータメモリの複数の分岐内に配置されているファイルを考慮するように検索スコープ（「自動リスト」生成検索スコープなど）を設定することができる。図９２Ｂは、図９２Ａの例示的な個別のコンピュータまたはネットワーク９２００を示しているが、この実施例では、検索「サブアイテムドメイン」は、サブアイテムドメイン三角形９２０４および９２０６により表されているような２人の独立のユーザから利用可能なフォルダ内にのみ含まれているデータを検索するように設定される（図９２Ｂの例示されている実施例におけるＵｓｅｒｓＢおよびＣからの写真データ）。ここでもまた、このサブアイテムドメインスコープを使用すると、「自動リスト」または他の検索活動の結果は、検索は、この実施例における所望のユーザのデータのみを対象とするようにより絞り込まれているため、かなり関連性のあるものにでき、実行速度は、検査すべきアイテムの集合が小さいため、高められる。

本発明の追加の態様は、さらに、上述の態様から広がる。本発明による少なくともいくつかの例示的なシステムおよび方法において、複数のフォルダおよび／またはプロパティは、ユーザにより、コンピュータ上に格納されている情報の検索および／または表示用のスコープとして選択されることができる。このようなシステムおよび方法では、例えば、図８７〜９１に関して、上で説明されているように、プロパティおよび／またはフォルダを階層形式で表示するナビゲーションパネルを使用することができる。

コンピュータ上に格納されているアイテムのフォルダを表示する従来の、または現在利用可能な「フォルダツリー」では、ユーザは、一度に複数のフォルダを選択することはできない。ユーザは、複数のフォルダの内容を表示したい場合、複数のウィンドウを開き（例えば、見たいフォルダ毎に１つずつ）、および／または所望のフォルダを連続的に開いて検査する操作をしなければならない。したがって、ユーザは、共通画面内の複数のフォルダからすべての情報を表示することはできず、そのため、コンピュータシステムまたはネットワーク上に格納されている利用可能な情報の全体を正確に見渡すことが困難である。

「リスト」および「自動リスト」が利用可能だと、この問題はさらに悪化する。上述のように、リストおよび自動リストは、コンピュータシステムまたはネットワーク上に格納されているファイルおよび／または他のアイテムを定義または分類するのを助けるプロパティ値の集合を含むことができる。多くの場合、ユーザは、さらに、表示されている情報はそれに関連付けられている複数のプロパティを含まなければならないという要求条件に基づいてリストまたは自動リストプロシージャを介して提示される情報（つまり、検索基準に位置していると識別された関連ファイル）をさらに絞り込みたい。例えば、ユーザは、特定の旅行場面から特定の人（例えば、配偶者）も含む格納されているすべての画像を見たい場合がある。複数プロパティ選択技術を使用できない場合、ユーザは、これら２つの独立したプロパティ基準を満たすファイルの部分集合を非常に見つけにくい。

本発明のいくつかの態様は、例えばナビゲーションパネル内に用意されている、または他の何らかの方法でユーザから利用できるようにされたプロパティの階層を一覧表示から、検索基準の一部として複数のプロパティが選択された場合に、検索を実行すること、検索結果を解釈すること、および／または検索結果を表示することを可能にするシステムおよび方法に関する。このようなシステムおよび方法は、例えば、様々なリスト、自動リスト、および／またはフォルダのナビゲート、検索、表示、および／または他の何らかの方法による対話操作を行うときに使用することができる。

本発明のこの態様に関係する一機能は、情報またはファイルが、複数のプロパティおよび／または他の検索パラメータを含む、検索の条件を満たすと決定される方法に関するものである。より具体的には、いくつかの場合には、ユーザは、複数プロパティ検索クエリのいずれかの機能の条件を満たすすべての情報の和集合を見ることを好み（プロパティＡ「ＯＲ」プロパティＢを満たした情報を表示する）、他の場合には、ユーザは、複数プロパティ検索クエリの両方の機能の条件を満たす情報のみの積集合を見ることを好む（つまり、プロパティＡ「ＡＮＤ」プロパティＢを満たした情報を表示する）。いくつかのより具体的な実施例として、ユーザが中に含まれる家族の一員と撮った「Ｍａｕｉｐｉｃｔｕｒｅｓ」を含むすべてのファイルを識別する情報の取り出しを要求した場合、ユーザは、検索システムおよび方法により、家族ＡＮＤ「Ｍａｕｉで撮った」を含む画像が取り出されることを期待する。このようなクエリでは、ユーザは、典型的に、すべてのＭａｕｉ画像（家族が含まれていないすべての画像を含む）およびすべての家族の画像（Ｍａｕｉのではない画像を含む）を見ることを望んでいない。他方、ユーザが３つ星または４つ星のいずれかと評価されたファイルを識別する情報の取り出しを要求した場合、検索システムおよび方法により、それらの評価のいずれかであるファイルが取り出されることが期待される（少なくともほとんどのファイルは、ユーザにより、３つ星および４つ星として同時に評価されることはないからである）。

したがって、本発明の少なくともいくつかの態様は、ユーザが、例えば階層状に配列された、例えばプロパティおよび／またはフォルダのナビゲーションパネルから、選択された情報または複数の検索パラメータに基づいて「和集合」または「積集合」情報を受け取ることを望む可能性が高いかどうかを自動的に判定するアルゴリズムに関する。一般に、以下でさらに詳しく説明するように、本発明の少なくともいくつかの実施例によるシステムおよび方法は、検索された複数のプロパティ、リスト、フォルダ、アイテム、および／または他のパラメータが階層内の同じ「プロパティ」に属している場合に選択された複数のパラメータの和集合（論理ＯＲ演算）に基づいてファイルに関する情報を（例えば、「ｓｅａｒｃｈ」、「ｌｉｓｔｆｉｌｅｓ」、または他のナビゲーションタスクの実行時に）返す。他方、本発明の少なくともいくつかの実施例によるシステムおよび方法は、検索された複数のプロパティ、リスト、フォルダ、アイテム、および／または他のパラメータが異なるプロパティに属しているか、異なるプロパティにまたがっている場合に選択された複数のパラメータの積集合（論理ＡＮＤ演算）に基づいてファイルに関する情報を（例えば、「ｓｅａｒｃｈ」、「ｌｉｓｔｆｉｌｅｓ」、または他のナビゲーションタスクの実行時に）返す。このアルゴリズムのオペレーションのより詳しい実施例は、図９３から１０３に関して以下で説明される。もちろん、必要ならば、与えられた検索クエリに対して自動選択されたＡＮＤまたはＯＲ演算をオーバーライドして、その特定のクエリに合わせて結果をカスタマイズし対象とするオプションおよび／または機会を（例えば、インターフェース画面、右マウスボタンクリックなどを介して）ユーザに与えることができる。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：単一の多値プロパティ内の複数選択：図９３は、プロパティ、フォルダなど（示されている実施例のパネル９３０２内の様々なノード）の階層的一覧を含むことができる、ナビゲーションパネル９３０２を含む例示的な表示画面９３００を示している。ノードの下に格納されている、および／またはノードに関連付けられている情報は、適宜、そのノードに関連付けられている（例えば、自動的に、ユーザ入力により、他のものの入力により、ファイルが他のソースからダウンロードされたときなどに）情報の個別の電子ファイルまたはアイテム（例えば、電子メールファイル、音楽ファイル、デジタル写真ファイル、電子ドキュメント、オーディオ、および／またはビデオファイルなど）を識別する情報を含むことができる。検索クエリまたはリストファイル活動に対し指定された１つまたは複数の基準に対応するファイルのうちの少なくともいくつかを識別する情報が、表示パネル９３０４内のこの例示的な表示画面９３００に表示される。ナビゲーションパネル９３０２を使用することで、ユーザは、ファイルに関連付けられている割り当てられたプロパティを表す階層ノードのうちの１つまたは複数を選択することができ、表示パネル９３０４は、ユーザ指定プロパティ基準を満たす情報のファイルまたは他のコレクションを識別する情報を含む。

図９３に示されているように、この実施例では、ユーザは、Ｐｅｒｓｏｎ＿ＡおよびＰｅｒｓｏｎ＿Ｄを示す画像を含むファイルを識別する情報をシステムに取り出せたいことを指示している（図のハイライト表示により示されているように）。より一般的な説明として、この実施例では、ユーザは、階層から単一の多値プロパティ内の複数の値を選択している（つまり、Ｐｅｒｓｏｎ＿Ａを表す階層アイコンの選択および単一のプロパティ（「Ｐｅｏｐｌｅ」）からＰｅｒｓｏｎ＿Ｄを表すアイコンの選択）。「Ｐｅｏｐｌｅ」プロパティは、「多値」プロパティと呼ばれるが、それは、「Ｐｅｏｐｌｅ」プロパティに基づくファイルは、複数の個別のプロパティエントリを持つことができるからである（例えば、与えられた画像は、複数の識別された人を含むことができ、したがって、関連付けられた複数の「Ｐｅｏｐｌｅ」子プロパティを持つことができる）。このｑｕｅｒｙ、ｓｅａｒｃｈ、または「ｌｉｓｔｆｉｌｅｓ」コマンドに対する応答として、本発明のこの実施例によるシステムおよび方法では、Ｐｅｒｓｏｎ＿ＡまたはＰｅｒｓｏｎ＿Ｄのいずれかを含む画像を取り出す（取り出すために、システムは自動的に、または人は、そのうちに、「Ｐｅｒｓｏｎ＿Ａ」もしくは「Ｐｅｒｓｏｎ＿Ｄ」プロパティまたはキーワードを様々な画像ファイルに（例えば、上述のように、メタデータとして）関連付け、それにより、画像の中に（複数の）人が含まれていることを指示する必要がある）。特に、この例示的な検索クエリでは、本発明のこの実施例によるシステムおよび方法は、和集合情報、つまり、Ｐｅｒｓｏｎ＿ＡおよびＰｅｒｓｏｎ＿Ｄの両方を含む画像（つまり、この実施例の中の画像ＡＢＤ１、ＡＢＤ２、ＡＣＤ１、ＡＤ１、およびＡＢＤ３）を含む、Ｐｅｒｓｏｎ＿ＡＯＲＰｅｒｓｏｎ＿Ｄ（英字「Ａ」および「Ｄ」により、それぞれ、図９３のアイコンに含まれる名前の中で表されている）を含むファイルを識別する情報を自動的に取り出す。本質的に、本発明のこの実施例によるシステムおよび方法は、ナビゲーションパネル９３０２でユーザにより指定された入力パラメータに基づき論理ＯＲ演算を実行したということである。

したがって、この実施例から、本発明による少なくともいくつかの例示的なシステムおよび方法による選択アルゴリズムの第１のルールを導くことができる。このルールにより、単一の多値プロパティ集合内の複数の集合がユーザにより選択されることで返される情報は、自動的に、「合併された」または論理「ＯＲ」問い合わせ言語方式で返される。もちろん、必要ならば、本発明の少なくともいくつかの実施例によるシステムおよび方法により、ユーザは、このルールおよび／またはこの自動選択アクションをオーバーライドすることができる（それにより、「ＡＮＤ」演算を実行する）。

特に、例示されている表示パネル９３０４では、２つの選択されたデータセットが全体として示されるか、または利用することができ、互いに離して保持される（つまり、この実施例ではＰｅｒｓｏｎ＿Ａ画像に対し１つのサブパネル９３０６およびＰｅｒｓｏｎ＿Ｄ画像に対し１つのサブパネル９３０８）。特に、単一のリストアイテムは、それぞれのサブパネル９３０６および９３０８内に（または他のものの中に）、適切であれば、出現しうる（つまり、この実施例では、画像ＡＢＤ１、ＡＢＤ２、ＡＣＤ１、ＡＤ１、およびＡＢＤ３を表すアイコンが、それぞれのサブパネル９３０６および９３０８内に出現する）。もちろん、例えば、ソースプロパティの指示なしで、および／または同じファイルまたはアイテムの反復表現を与えることなく、コンパイルされたファイルまたはアイテムの一覧を表示することを含む、取り出された情報を表示する他の多くの方法（例えば、表示パネル９３０４内で）を、本発明から逸脱することなく使用することができる。他の実施例として、必要ならば、表示部分９３０４は、さらに、論理ＡＮＤ演算が望ましい場合に、この方法をユーザに利用しやすくするために、論理ＡＮＤ演算の結果（この実施例ではＰｅｒｓｏｎ＿ＡおよびＰｅｒｓｏｎ＿Ｄの両方を含む画像）を含む表示サブパネルなどを含むことも可能である。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：単一値プロパティ内の複数選択：上述のように、図９３の実施例では、「Ｐｅｏｐｌｅ」プロパティは、多値プロパティである（つまり、そのプロパティの下の情報のアイテム（例えば、ファイル）は、それに関連付けられている基礎となる子プロパティの複数を持つことができる）。しかし、いくつかのプロパティは、「単一値プロパティ」と考えることができ、これは、そのプロパティの下に格納される情報のそれぞれのアイテム（例えば、ファイル）は、このプロパティの基礎となる子の単一インスタンスのみを含むことを意味する。単一値プロパティの実施例は、限定はしないが、サイズ、評価などを含むことができる。図９４は、ユーザがプロパティの階層配列（またはフォルダなど）を含むナビゲーションパネル９４０２から複数のプロパティ（例えば、リストファイル、検索クエリ、または他のアクションの）を選択している例示的な表示画面９４００を示しており、選択されたプロパティは、単一値プロパティ「Ｒａｔｉｎｇ」の下にある（つまり、ユーザは、典型的には、ただ１つの評価をファイルに付ける）。特に、この実施例では、ユーザは、ナビゲーションパネル９４０２内のハイライト表示から明らかなように、３または４つ星評価を持つすべての画像の取り出しを要求している。

このｑｕｅｒｙ、ｓｅａｒｃｈ、または「ｌｉｓｔｆｉｌｅｓ」コマンドに対する応答として、本発明のこの実施例によるシステムおよび方法では、３ｓｔａｒｓＯＲ４ｓｔａｒｓと評価された画像を取り出す（取り出すには、システムは自動的にまたは人が、ある時点に、評価プロパティを様々なファイルに（例えば、上述のようにメタデータとして）割り当てていなければならない）。特に、この例示的な検索では、本発明のこの実施例によるシステムおよび方法は、和集合情報、つまり、３ｓｔａｒｓＯＲ４ｓｔａｒｓと評価されたファイルを識別する情報を取り出す。本質的に、本発明のこの実施例によるシステムおよび方法は、ナビゲーションパネル９４０２でユーザにより指定された入力パラメータに基づき論理ＯＲ演算を実行したということである。実際、この実施例では、「Ｒａｔｉｎｇ」プロパティは単一値プロパティであるため、論理「ＡＮＤ」演算を実行することは無意味であるが、それは、「ＡＮＤ」演算がそれぞれの場合において空集合を返すからである（つまり、それぞれのファイルは、唯一の評価を含むため、３ｓｔａｒＡＮＤ４ｓｔａｒ評価を含む検索実行時にファイルは特定されない）。

したがって、この実施例から、本発明による少なくともいくつかの例示的なシステムおよび方法による選択アルゴリズムの他のルールを導くことができる。このルールにより、単一値プロパティ集合内の複数の集合がユーザにより選択されることで返される情報は、自動的に、「合併」方式または論理「ＯＲ」問い合わせ言語方式で返される。もちろん、必要ならば、本発明の少なくともいくつかの実施例によるシステムおよび方法により、ユーザは、このルールおよび／またはこの自動選択アクションをオーバーライドすることができる。

特に、例示されている表示パネル９４０４では、２つの選択されたデータセットが全体として示されるか、または利用することができ、互いに離して保持される（つまり、この実施例では、３つ星評価画像に対し１つのサブパネル９４０６および４つ星評価画像に対し１つのサブパネル９４０８）。特に、この場合、サブパネル９４０６および９４０８の両方（または他のもの）に単一リストアイテムは出現しないが、それは、それぞれのファイルが、この実施例における定義により、単一の評価値を含むからである。もちろん、例えば、ソースプロパティの指示なしで、コンパイルされたファイルまたはアイテムの一覧を表示することを含む、取り出された情報を表示する他の多くの方法（例えば、表示パネル９４０４内で）を、本発明から逸脱することなく使用することができる。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：追加の論理「ＯＲ」の実施例：上述のように、上のルールは、フォルダ構造および／または階層プロパティ構造内のアイテムに適用することができる。図９５および９６は、ユーザ選択がナビゲーションパネル内の階層プロパティに適用される場合のいくつかの追加の実施例を示している。

図９５の表示画面９５００に示されているように、ユーザは、ナビゲーションパネル９５０２内に存在する階層プロパティテーブル内の２つの独立のエントリ、つまり、Ｃａｒｓ＞Ｉｍｐｏｒｔ＞ＧｅｒｍａｎプロパティおよびＣａｒｓ＞Ａｍｅｒｉｃａｎプロパティを選択している。選択されたプロパティは、まだ、共通の多値親プロパティ（この実施例では「Ｃａｒｓ」）の下に配置されているため、上のルールが適用され、表示パネル９５０４は、このｑｕｅｒｙ、ｓｅａｒｃｈ、またはｌｉｓｔｆｉｌｅｓオペレーションに対する応答として２つの選択されたプロパティの和集合を表示する。より具体的には、図９５に示されているように、表示パネル９５０４は、論理ＯＲ演算に対応する格納されているすべてのファイルを識別する情報、つまり、いずれかの検索基準、すなわちドイツ製輸入車に対応する格納されているデジタル画像ＯＲ米国車に対応する格納されているデジタル画像を満たす情報を含む。論理ＡＮＤ演算は、このような特定の事実状況では、典型的な自動車は、“ｉｍｐｏｒｔｓ”ＡＮＤ“Ａｍｅｒｉｃａｎ”と考えられないため、あまり意味がないか、または可能性が小さい（しかし、ＡＮＤ演算は、例えば、複数の自動車が与えられた画像に含まれ、プロパティが画像内の両方の自動車についてファイルに関連付けられていた場合にヒットを返すことができる）。

特に、この実施例では、階層構造内の２つの選択されたアイテム（つまり、プロパティ）は、同じ階層レベル内に配置されていなかった。しかしながら、論理ＯＲ演算は、この場合に実行されたが、それは、上述のように、アルゴリズムのルールでは、選択されたプロパティが共通の親プロパティの下に配置されている場合にＯＲ演算の実行を必要としているからである（しかし、この共通の親プロパティは、選択されたノードの両方またはいずれかの直接の親である必要はない）。

特に、例示されている表示パネル９５０４では、２つの選択されたデータセットが全体として示されるか、または利用することができ、互いに離して保持される（つまり、この実施例ではドイツ車の画像に対し１つのサブパネル９５０６および米国車の画像に対し１つのサブパネル９５０８）。ここでもまた、この場合に、サブパネル９５０６と９５０８の両方に（または他のものに）単一のリストアイテムが出現しないが、単一の画像に複数の自動車が含まれているため、サブパネル９５０６および９５０８内に重なり合う画像が可能である。もちろん、例えば、ソースプロパティの指示なし、複製された写真一覧なしなど、コンパイルされたファイルまたはアイテムの一覧を表示することを含む、取り出された情報を表示する他の多くの方法（例えば、表示パネル９５０４内で）を、本発明から逸脱することなく使用することができる。また、必要ならば、論理ＡＮＤ演算の結果も、適宜、論理ＯＲ演算の結果とともに、表示パネル９５０４に表示することができる。

図９６は、ナビゲーションパネル９６０２内の複数の階層プロパティノードがユーザにより選択される他の例示的な表示画面９６００を示している。この実施例では、ノードおよび対応する孫ノードの１つが、ユーザにより選択される（つまり、ＣａｒｓノードおよびＣａｒｓ＞Ｉｍｐｏｒｔ＞ＵＫノードが選択された）。この場合、論理ＡＮＤ演算はほとんどまたはまったく意味をなさないが、それは、ユーザがＵＫ輸入車のみに対応するファイルを一覧表示することを意図している場合に、ユーザは、ＵＫノードを単に選択してこの一覧表示を作成することができるからである（複数選択は必要なかった）。したがって、上記選択ルールがそれでも適用される、つまり、選択されたプロパティは、共通の親プロパティ（この実施例では「Ｃａｒｓ」）内に配置されているため、システムは、このｑｕｅｒｙ、ｓｅａｒｃｈ、またはｌｉｓｔｆｉｌｅｓオペレーションに対する応答として２つの選択されたプロパティの和集合を自動的に取り出し、表示パネル９６０４は、それを自動的に表示する。より具体的には、図９６に示されているように、表示パネル９６０４は、論理ＯＲ演算に対応する格納されているすべてのファイルを識別する情報、つまり、いずれかの検索基準、すなわちすべての自動車に対応する格納されているデジタル画像ＯＲＵＫ車に対応する格納されているデジタル画像を満たす情報を含む。

上述の様々な表示パネルの場合と同様に、表示パネル９６０４では、２つの選択されたデータセットを全体として利用可能にし、互いに離して保持されるようにする（つまり、この実施例ではすべての自動車の画像に対し１つのサブパネル９６０６およびＵＫ車の画像に対し１つのサブパネル９６０８）。この例示的なシステムおよび方法では、サブパネル９６０８内のＵＫ車の画像すべてが、さらに、より包括的なＣａｒｓサブパネル９６０６内に含まれるが、それは、すべてのＵＫ車の画像はＣａｒｓ親ノード内に収まらなければならないからである（例えば、階層プロパティに関して上で説明されているように、子プロパティがファイルに割り当てられた場合、そのファイルは、さらに、自動的に、割り当てられている子プロパティへのすべての親プロパティを割り当てられる）。もちろん、例えば、ソースプロパティの指示なし、重なり合う写真が表示されないなどで、コンパイルされたファイルまたはアイテムの一覧を表示することを含む、取り出された情報を表示する他の多くの方法（例えば、表示パネル９６０４内で）を、本発明から逸脱することなく使用することができる。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：論理「ＡＮＤ」の実施例：図９３〜９６に対する上の実施例は、フォルダ、階層プロパティなどの与えられた階層グルーピング内の複数のユーザ選択に関する。階層フォルダまたはプロパティ構造内の複数のユーザ選択への応答として表示すべきデータを決定するための例示的なアルゴリズムの他のルールは、図９７から９９までに関して例示されている。

一般に、アルゴリズムのこの「ルール」は、異なる親プロパティ集合にわたって複数ユーザ選択がなされる場合に、検索結果の「積集合」が表示される（または論理ＡＮＤ演算が実行され、結果が表示される）ことを要求する。図９７に例示されている実施例では、表示画面９７００に、多値階層プロパティが表示されるナビゲーションパネル９７０２が示される。ユーザは、最も高いレベルの親プロパティ集合の２つにまたがる２つのプロパティ、つまりＬｏｃａｔｉｏｎｓ＞ＴｏｒｏｎｔｏおよびＰｅｏｐｌｅ＞Ｐｅｒｓｏｎ＿Ｄを選択した。この種類の状況では、ユーザは、典型的には、論理ＡＮＤ演算が実行され、表示された結果がＰｅｒｓｏｎ＿Ｄも含むトロントで撮った画像のみを含むことを期待する（例えば、典型的には、この種類の検索クエリでは、ユーザは、すべてのトロントの画像またはＰｅｒｓｏｎ＿Ｄを含むすべての画像を見ることを望まない）。したがって、この実施例の表示パネル９７０４に示されているように、その結果表示される結果は、中にＰｅｒｓｏｎ＿Ｄを含むトロントへの旅行の際の画像のみを含む。選択された両方の集合の積集合が表示されるため、図９３〜９６で上に示されているように、それぞれのユーザ選択集合からの結果を別々に表示する理由はないが（つまり、表示パネル９７０４内のそれぞれのアイテムは、Ｌｏｃａｔｉｏｎｓ＞Ｔｏｒｏｎｔｏ一覧表示およびＰｅｏｐｌｅ＞Ｐｅｒｓｏｎ＿Ｄ一覧表示内に存在する）、これらの個別の選択された集合は、必要ならば、さらに表示することもできる（例えば、ユーザが個別の両方の集合を見たかった可能性に対応するため）。

もちろん、例えば、表示パネル９７０４に検索結果を表示する方法は、どのようなものでも、本発明から逸脱することなく使用できる。それに加えて、必要ならば、本発明のこの実施例によるシステムおよび方法により生成される自動ＡＮＤ演算をユーザ側でオーバーライドできるようにすることもできる。

論理ＡＮＤ演算の適用は、多値階層プロパティとの併用に限定されない。例えば、図９７のユーザ選択の一方または両方が単一値プロパティ（ナビゲーションパネル９７０２に示されている星「Ｒａｔｉｎｇ」プロパティのうちの１つなど）を構成し、他の選択が異なる親プロパティ集合（「Ｐｅｏｐｌｅ」または「Ｌｏｃａｔｉｏｎｓ」プロパティ集合などの）内に配置されている場合、選択された星Ｒａｔｉｎｇプロパティと選択されたＰｅｏｐｌｅまたはＬｏｃａｔｉｏｎｓプロパティの「積集合」が表示されていることであろう（つまり、選択は異なるプロパティ集合にまたがっているため、論理ＡＮＤ演算は、そのまま、実行され、結果が表示されている）。

論理ＡＮＤ演算を適用するアルゴリズムのルールも、異なる階層プロパティにまたがって選択がなされる場合、さらにはそれらの選択が、階層構造内の異なる深さに配置されている場合でも、適用される。図９８は、一実施例を示している。図９８の表示画面９８００に示されているように、ユーザは、ナビゲーションパネル９８０２内のプロパティＫｅｙｗｏｒｄ＞Ｃａｒｓ＞ＩｍｐｏｒｔおよびＤａｔｅ＞２００４を選択している。最上位レベルの親プロパティは異なっているため、論理ＡＮＤ演算が実行され、表示パネル９８０４に、それら２つのプロパティの積集合が表示される（つまり、選択された両方のプロパティを持つファイル、すなわち年「２００４」からの「Ｉｍｐｏｒｔｃａｒｓ」の画像を表示する）。このＡＮＤ演算は、選択されたノードの１つが、他の選択されたノードと比べて、有している親ノードの数が異なるという事実があっても実行される（したがって、階層内の全体的異なるレベルに存在する）。

この同じアルゴリズムのルールが適用され、類似の積集合結果が、ユーザ選択プロパティの一方または両方が単一値プロパティであるか、または多値プロパティであるかに関係なく得られる。

それに加えて、論理ＡＮＤ演算を適用するアルゴリズムのルールは、さらに、異なる階層プロパティにまたがって選択がなされる場合、さらにはそれらの選択のうちの少なくとも１つが、階層構造内の低レベルのアイテムを含まない場合でも、適用される。図９９は、一実施例を示している。図９９の表示画面９９００に示されているように、この実施例のユーザは、ナビゲーションパネル９９０２内のプロパティＲａｔｉｎｇ＞４＿ＳｔａｒおよびＰｅｏｐｌｅを選択している（Ｐｅｏｐｌｅノードの下の特定の人は選択されなかった）。最上位レベルの親プロパティは異なっているため、論理ＡＮＤ演算が実行され、表示パネル９９０４に、それら２つのプロパティの積集合が表示される（つまり、４つ星と評価されている中に含まれる「Ｐｅｏｐｌｅ」プロパティ（例えば、人）を持つファイルに関係する情報を表示する）。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：フォルダ、リスト、または他の構造を持つ階層内の複数選択の使用：上述のように、階層内の複数ユーザ選択の使用のいくつかの態様は、さらに、従来のフォルダを含む階層に適用することもできる（例えば、ＯＲ／ＡＮＤ機能の実行は、ユーザ選択要素の一方または両方がフォルダ構造を含む場合であっても、上のルールを使用して決定することができる）。概念上、本発明の少なくともいくつかの例示的な態様によれば、「フォルダ」は、単一値プロパティとして取り扱うことができる。より具体的には、個々のファイルは、上述のように単一の従来のフォルダにのみ置かれているため、フォルダは、本発明のこれらの態様により単一値プロパティとして取り扱うことができる。適宜、必要ならば、複数ユーザ選択は、階層構造内のフォルダ要素およびプロパティ要素の選択の混合を含むことができる。様々な実施例を以下に示す。

図１００は、階層プロパティおよびフォルダ構造の両方が存在するナビゲーションパネル１０００２を含む表示画面９００００を示している。図１００に示されている実施例では、ユーザは、２つの個々のフォルダ、つまりＭｙＰｉｃｔｕｒｅｓ＞ＴｒｉｐｓフォルダおよびＭｙＰｉｃｔｕｒｅｓ＞Ｏｌｄフォルダを選択している。２つの選択が階層内の同じ最上位レベルの親要素の下に配置されているため（つまり、この実施例では「ＭｙＰｉｃｔｕｒｅｓ」要素）、上述の様々なアルゴリズムのルールの適用を通じて論理ＯＲ演算が適用され、表示パネル１０００４に示されているように、表示される結果には、２つの選択された集合の和集合が表示される。これが選択された集合の内容は、好きな方法で表示パネル１０００４内に表示することができるが、示されているこの実施例では、表示されるファイルは、例えば図９３〜９６において上で概要が説明されているように、別の、異なるサブパネル内で識別される。

上述のように、ユーザファイルは、従来のフォルダ階層内の単一の場所に存在する（つまり、単一のファイルまたは他のアイテムは、同時に２つの独立した、別のフォルダに存在しえない）。したがって、論理ＡＮＤ演算は、結果として空集合返すため、論理ＯＲ演算は、図１００に例示されている状況において最も意味がある。

図１０１は、ＯＲ／ＡＮＤ論理演算選択ルールおよびアルゴリズムが、ユーザの選択に少なくとも１つのフォルダ集合が含まれ、選択が階層の独立した、異なる部分（つまり、異なる最終的な最上位レベルの親ノードを持つ部分）にまたがる状況において適用される一実施例の表示画面１０１００を示している。図１０１の階層ナビゲーションパネル１０１０２に示されているように、ユーザは、評価ノード（この実施例では４＿Ｓｔａｒ）およびフォルダノード（この実施例ではＭｙＰｉｃｔｕｒｅｓ＞Ｏｌｄフォルダノード）を選択している。上述の様々なルールおよびアルゴリズムを適用すると、選択は、階層構造内の異なる最上位レベルの親ノードを持つため、論理ＡＮＤ演算が適用され、これら２つの階層要素の積集合に関する情報は、表示パネル１０１０４に表示される。より具体的には、この実施例では、「４つ星」評価を持つ格納されている「古い」画像すべてが、表示パネル１０１０４に表示される。もちろん、ｑｕｅｒｙ、ｓｅａｒｃｈ、またはｌｉｓｔｆｉｌｅｓの結果を表示する方法は、どれも、本発明から逸脱することなく使用できる。また、必要ならば、表示パネル１０１０４は、論理ＯＲ演算からの結果をさらに示すように設計することも可能であり、および／またはユーザは、論理ＯＲ演算が望まれていることを何らかの方法でシステムに通知することができる。

本発明の少なくともいくつかの実施例により、同じＯＲ／ＡＮＤ論理演算選択機能を階層構造内のリスト要素に適用することができる。「Ｌｉｓｔｓ」（リスト）は、概念上、ファイルなどの、アイテムの集合を単純に構成するものとして考えられる。図１０２は、様々なリスト要素がナビゲーションパネル１０２０２に示されている階層構造内に含まれる例示的な表示画面１０２００を示している。「ＡｌｌＬｉｓｔｓ」ノードの下の複数の要素、つまり「ＴｏｐＩｓｓｕｅｓ」ノードおよび「ＰｒｏｊｅｃｔＹ」ノードは、ユーザにより選択される。表示パネル１０２０４では、生成された表示は、これらの検索基準のいずれか、つまり、「ＴｏｐＩｓｓｕｅｓ」として指定されたリスト要素ＯＲ「ＰｒｏｊｅｃｔＹ」に対応するように指定されたリスト要素を満たしたリストアイテムに関する情報を与える。特に、リストアイテムのうちのいくつかは、両方のモードに対するグルーピングの下に含まれることができる（例えば、アイテム２および４）。これが選択された集合の内容は、好きな方法で表示パネル１０２０４内に表示することができるが、示されているこの実施例では、表示されるリスト要素は、例えば図９３〜９６において上で概要が説明されているように、別の、異なるサブパネル内で識別される。また、必要ならば、表示パネル１０２０４は、論理ＡＮＤ演算からの結果をさらに示すように設計することも可能であり、このＡＮＤ結果がユーザに望まれているという可能性に対応することが可能である。さらに、上述のように、必要ならば、ユーザ側で自動ＯＲ演算選択をオーバーライドできるようにすることもできる。

上述のＯＲ／ＡＮＤ論理演算選択決定アルゴリズムおよびルールは、さらに、ユーザが２つよりも多い階層要素（例えば、３つまたはそれ以上のフォルダ、リスト要素、プロパティなど）を選択する状況において適用することができる。一般に、このような状況では、論理ＯＲ演算（つまり、和集合演算）は、同じ階層親要素集合の下で行われる選択に関して実行され、論理ＡＮＤ演算（つまり、積集合演算）は、異なる階層親要素集合をまたがって行われる選択に関して実行される。適宜、与えられた階層親要素集合内の演算（つまり、ＯＲ演算）は、もしあれば、最初に実行することができる。図１０３は、この種類の演算の一実施例を示している。

特に、図１０３の表示画面１０３００に示されているように、ユーザは、ナビゲーションパネル１０３０２から３つの要素、つまり、Ｄａｔｅｓ＞２００４プロパティ、Ｋｅｙｗｏｒｄ＞Ｃａｒｓ＞Ｉｍｐｏｒｔプロパティ、およびＫｅｙｗｏｒｄ＞Ｃａｒｓ＞Ａｍｅｒｉｃａｎプロパティを選択している。それに対する応答として、本発明の少なくともいくつかの実施例によるシステムおよび方法では、最初に、選択されたＫｅｙｗｏｒｄプロパティに関してＯＲ演算を実行して、これらの基準のいずれかを満たす格納されているキーワードプロパティを含む保存されているすべてのファイルを特定する。次いで、Ｋｅｙｗｏｒｄ基準のいずれかを満たす識別されたファイルから、どのファイルが日付基準も満たすかの判定が（論理ＡＮＤ演算を適用することにより）行われる。次いで、表示パネル１０３４０内に表示される結果は、輸入車画像および「２００４」からのＡｍｅｒｉｃａｎＣａｒ画像を示す。これら選択された集合の内容は、好きな方法で表示パネル１０３０４内に表示することができるが、示されているこの実施例では、ファイルに関する表示される情報は、例えば図９３〜９６において上で概要が説明されているように、異なる「ＯＲ」選択を対象とする別の、異なるサブパネル内に表示される。

ユーザがコンピュータシステムまたはネットワークに情報を格納し、検索し、そこから取り出すために階層プロパティ、フォルダ、リスト、または他の構造を使用する場合に予測可能な、論理的結果が得られるため、複数ユーザ選択に論理ＯＲ演算または論理ＡＮＤ演算を実行することは有益かどうかを判定する際に上記のルールおよびこれらのルールの適用が行われる。もちろん、必要ならば、上述のように、例えば、これらのルールで、個別の場合において望ましくない結果が生じる場合に、ユーザに対し、いつでもこれらの自動取り出しルールをオーバーライドすることを許すインターフェースを用意することができる。新しい情報がコンピュータシステムまたはネットワーク内に導入されるときに、新しい情報を既存の階層に組み込むことができるか、または新しい／追加の階層を必要とするかに関係なく、上記のルールを引き続き、新しく追加された情報などにも適用することができる。何らかの方法で階層構造内に配置された後、様々な選択が与えられたプロパティまたは他の階層要素レベル内に配置されるかどうか、および／またはそれらが異なる最上位レベルの親プロパティまたは他の階層要素レベルにまたがっているかどうかを判定することにより、上記のＯＲ／ＡＮＤ論理演算選択プロシージャを実行することができる。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：複数プロパティ選択：コンピュータ可読媒体：本発明の追加の態様は、さらに、上述のシステムおよび方法を含む、様々な複数のプロパティまたは他の値選択方法を実行するために、および／または複数のプロパティまたは他の値選択方法を含む様々なシステムで使用するために、中に格納されているコンピュータ実行可能命令を含むコンピュータ可読媒体にも関する。コンピュータ可読媒体は、上述のコンピュータ可読媒体の様々な特定の実施例において格納されるコンピュータ実行可能命令を構成することができる。

ページ空間コントロール：本発明のいくつかの態様によるシステム、方法、およびコンピュータ可読媒体の実施例：表示パネル内のグルーピングおよびスタッキング：今日、Ｗｉｎｄｏｗｓ（登録商標）ベースのコンピュータオペレーティングシステム（例えば、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎが市販している）では、ファイルの集合を（例えば、検索クエリまたはｌｉｓｔｆｉｌｅｓコマンドから）複数のグループに編成することが可能である。例えば、ファイル「タイプ」別のグルーピングを使用して、検索ドメイン内のすべてのＰｏｗｅｒＰｏｉｎｔ（登録商標）プレゼンテーション（ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎが市販しているプレゼンテーションソフトウェア）を１つのグループに入れ、および／またはすべてのデジタル画像を他のグループに入れることができる。しかし、さらに考察したいファイルを最終的に特定するために正しいグルーピングを特定しなければならないので、ユーザが、大きなアイテム集合を効率よく、また効果的に扱うことは困難な場合がある。例えば、ユーザが中に１００，０００個のファイルが含まれるフォルダを持っている場合、それらのファイルをグルーピングすると、並べ替えがいくぶんやりやすくなるが、それでも、特定の所望のファイルを見つけることはユーザにとって困難な場合がある（例えば、特に、キーワード検索または他の検索技術が、グルーピングされたファイルの絞り込みに効果的でない場合）。

本発明の少なくともいくつかの実施例によるアプリケーションプログラムおよび／またはオペレーティングシステムでは、ユーザは、ファイルを複数の集合に視覚的に編成するための新しい／追加の手段として「スタッキング」することを利用することができる。例えば、システムおよび方法において「ファイルタイプ」でスタッキングする場合、ユーザは、個々の集合、例えば、ＰｏｗｅｒＰｏｉｎｔプレゼンテーションファイル用の集合、スプレッドシート用の集合、デジタル画像用の集合などにスタッキングされたファイルすべてを見ることができる。これらの集合はそれぞれ、例えば、コンピュータ生成表示内で、そのアイテムの集合用の仮想的コンテナとして概念的に動作するスタックアイコンにより表現することができる。スタッキングは、ユーザが気を付けているアイテムの集合上でユーザが絞り込みを行うのを補助する非常に有用な手段であるが、それは、スタッキングにより様々な利用可能なスタックオプションが明確に列挙され、ユーザにとってわかりやすいからである。

より具体的な現実世界の実施例に適用する場合、スタッキングは、概念上、レンタカー店に行き、どのような色の車が店にあるか尋ねることであると考えられる。レンタカー店では、今日は青色と赤色の車を用意できる、と応じる。概念的には、これは、ユーザがファイルをプロパティでスタッキングする場合に生じることである、つまり、ユーザは、そのプロパティのそれぞれの一意的な値に対するスタックを得られるということである。

このスタッキング機能は（他の表示機能とともに）、例えば、図９１および９３〜１０３に関して上で説明されているようなユーザインターフェースに適用することができる。このようなユーザインターフェースでは、本発明の少なくともいくつかの実施例によるシステムおよび方法は、Ｌｉｓｔｓ、ＡｕｔｏＬｉｓｔｓ、Ｆｏｌｄｅｒｓ、および例えば、ユーザ定義プロパティを含む、プロパティなどを含む情報を表示することができる。それぞれのＡｕｔｏＬｉｓｔは、様々な方法で、例えば、特定のプロパティにより、ファイルを識別する情報をユーザが表示する一手段となるように設計することができる。より具体的な実施例では、音楽ＡｕｔｏＬｉｓｔは、例えばアーティストによりスタッキングすることができ、このアーティストプロパティによる検索により、ユーザは、音楽コレクションに含まれるすべてのアーティスト、例えば、Ｂｊｏｒｋ、Ｍａｄｏｎｎａなどで識別されたスタックを見ることができる。しかし、このＡｕｔｏｌｉｓｔへのショートカットを単純に示すことには１つ問題があり、コンピュータシステムに多くの異なるアーティストに由来する音楽が格納され、ビュー内で使用できる場合でも、やはり、所望の個々のアーティストおよび／または所望の個々のアルバム、ＣＤ、または（複数の）楽曲を特定することはユーザにとって困難な場合があるのである。

本発明のいくつかの実施例によるシステムおよび方法の一態様は、利用可能なＡｕｔｏＬｉｓｔｓのスタッキング構造をナビゲーションパネルおよび／またはそれに関連付けられている表示パネル内にサブノードとして公開することに関する。より具体的な一実施例として、上述の「Ａｒｔｉｓｔｓ」ＡｕｔｏＬｉｓｔの状況について、本発明の少なくともいくつかの実施例によるシステムおよび方法を使用することで、ユーザは、ナビゲーションパネルおよび／または表示パネル内で「Ａｒｔｉｓｔｓ」（または他の）ノードを展開し、それにより、コンピュータ、ネットワーク、またはシステム上に保存されているすべての一意的なＡｒｔｉｓｔｓ（または他のノード）を制御し、および／または表示することができる。

本発明の他の態様は、情報のグループおよびスタッフに関係する情報は、例えば、ナビゲーションパネルおよび／またはそのような情報を提示するユーザインターフェースの表示部分で、処理され、および／または操作される方法に関する。より具体的には、本発明の態様では、同じ方法で「グルーピングされた」および「スタッキングされた」情報を取り扱い、これにより、グルーピングされるＡｕｔｏＬｉｓｔｓは、ナビゲーションパネル内に階層を表現することができる。つまり、ユーザが表示パネル内に「Ａｒｔｉｓｔ」別にグルーピングされた音楽ファイルのビューを持っている場合、本発明のいくつかの実施例によるシステムおよび方法を使用して、ナビゲーションパネル内に様々なアーティストに対するサブノードを生成することができる。少なくともいくつかの場合において、サブノードは、実際に、他のスタックを構成することができ、したがって、ユーザがこれらのサブノードのうちの１つをクリックすると、ビュー内のアイテムの集合は、フィルタ処理によりそれらの結果のみに絞り込まれる。これにより、ユーザは、ビュー内に存在するアイテムのクイックインデックスを利用できるようになり、ただ視覚的にまたは心の中で編成する代わりにファイルの集合に実際に絞り込むことができる。

本発明によるさらに他の例示的な態様は、本発明の少なくともいくつかの実施例によるシステムおよび方法のユーザが、親フォルダ内でスタッキングし、そのフォルダ階層をフラットにできることに関する。例えば、ユーザがデータのハードドライブディレクトリまたは他のコレクション（例えば、「Ｄ：＼Ｄａｔａ」グループ化）にファイルタイプ別にスタッキングする場合、本発明による少なくともいくつかの実施例によるシステムおよび方法は、すべてのサブフォルダを検索し、それらのアイテムを取り出してスタックに入れる。これにより、ユーザは、任意のフォルダにナビゲートし、その内容をフォルダ階層ではなく所望のプロパティ値により編成して表示することができる。

一般に、本発明の態様は、本発明の少なくともいくつかの実施例によるシステムおよび方法において、グルーピングおよびスタッキングを使用して、ナビゲーションパネル内に動的組織構造を作成することができるため有用であり、またナビゲーションパネルまたは表示パネル内でグループを選択し、その集合のみを表示するようにビュー内のアイテムを絞り込むことができる。本発明のさらに追加の一般的態様は、グルーピングおよびスタッキングをＡｕｔｏＬｉｓｔへのサブノードとして取り扱うこと、およびナビゲーションパネルおよび／または表示パネル内のグループを選択できることに関するものであり、この選択を通じて、さらに、表示されるビューを絞り込むことができる。本発明のこれらの態様のより具体的な実施例について以下で説明する。

上述のように、「グルーピング」および「スタッキング」は、アイテムの集合を視覚化するための２つの異なる方法である。図１０４は、ナビゲーションパネル１０４０２および表示パネル１０４０４を含む表示画面１０４００を例示している（これは、ナビゲーションパネル１０４０２内に受け取った入力に基づいて様々な格納されているファイルまたはアイテムに関係する情報を示す）。特に、図１０４では、ナビゲーションパネル１０４０２は、プロパティまたはキーワード「Ｃａｒｎｉｖｏｒａ」が選択されたことを示し、対応する表示パネル１０４０４は、Ｃａｒｎｉｖｏｒａ親ノードの真下のレベルの階層内の個々の子ノードに対するスタックを示す。より具体的には、図１０４の実施例に示されているように、表示パネル１０４０４は、イヌ（Ｃａｎｄｉａｅ）に対する画像のスタックおよびネコ（Ｆｅｌｉｄａｅ）に対する画像のスタックを含む。特に、ナビゲーションパネル１０４０２では、ＣａｎｄｉａｅおよびＦｅｌｉｄａｅノードの下の子ノードは、これらの集合が表示パネル１０４０４内にスタッキングされているものとして示されているという事実があるにもかかわらず、完全に（最低レベルまで）表示されている。

少なくともいくつかの場合において、スタックは、表示パネル１０４０４内に情報を表示する最も好ましい方法を構成しない場合がある。例えば、図１０４に示されているように、スタッキングは、ユーザがスタック内の内容に関する情報を容易に見ることができないため、少なくともいくつかの場合においては望ましくないことがある（例えば、ユーザは、図１０４に示されているように、スタックの内容に関するサムネイルアイコンまたはたくさんの他の表示されている情報を見ることができない）。「アンスタッキング」方式（“ｕｎｓｔａｃｋｅｄ”ｍａｎｎｅｒ）で情報を表示しない場合、ユーザは、少なくともいくつかの場合において、階層の最も深いレベルまで「ドリルダウン」して最終的に画像（または特定のファイルに関係するより具体的な他の情報）表示しなければならない。この要求条件は、特に階層が多くのレベルに分かれている場合、多くのファイルが階層に含まれている場合、および／または所望のファイルがその階層内のどこに配置されているかユーザが確信を持てない場合に、不便である。

図１０５は、表示パネル１０５０４のスタッキングとは反対に、グルーピングを使用する他の例示的な表示画面１０５００を示している。特に、同じノードがナビゲーションパネル１０５０２内でハイライト表示のままになっているが（つまり、この特定の実施例では、「Ｃａｒｎｉｖｏｒａ」ノード）、表示パネル１０５０４は、別のサブパネル１０５０６および１０５０８として選択されている親ノードの下のそれぞれの子ノードの下にグルーピングされた検索結果を示している。さらに、サブパネル１０５０６および１０５０８の中で、この例示的な表示画面１０５００内の基礎となるファイル情報は、ユーザが階層内の基礎となる内容に関係する情報を速やかに、容易に見られるようにアンスタッキング方式で示されている。

特に、図１０５に示されている実施例では、特定のノード（例えば、Ｃａｎｄｉａｅノード）の下に含まれるアイテムすべてに関係する情報は、その情報が配置されている階層内のレベルに関係なく、それぞれのサブパネル（例えば、サブパネル１０５０６）内に示される（例えば、特定の画像が、関連付けられている「Ｃａｎｄｉａｅ」プロパティ、「Ｃａｍｓ」プロパティ、「Ｌｕｐｕｓ」プロパティ、または「Ｌａｔｒａｎｓ」プロパティとともに格納されているかどうかに関係なく）。この機能により、所望の情報へのユーザアクセスおよび認識が素早く、簡単に行えるようになる。特に、この同じ表示パネル１０５０４は、例えば、ユーザがナビゲーションパネル１０５０２内でＣａｎｄｉａｅおよびＦｅｌｉｄａｅの両方のノードをハイライト表示にした場合に、他のｓｅａｒｃｈまたはｌｉｓｔｆｉｌｅｓコマンドの結果として表示することができる。

ユーザは、さらに、ナビゲーションパネル１０５０２の階層構造内を素早くナビゲートして、情報の異なるグルーピングを見ることもできる。考えられる変更の一例は、図１０５と図１０６とを比較するとわかる。特に、図１０５では、上述のように、Ｃａｒｎｉｖｏｒａプロパティは、選択されたプロパティの子ノードに基づいてグルーピングされている、そのプロパティとともに格納されている情報の表示を与える、ナビゲーションパネル１０５０２内でユーザにより選択された（つまり、この実施例ではＣａｎｄｉａｅおよびＦｅｌｉｄａｅ子ノードに基づいてグルーピングされている）。図１０６の表示画面１０６００では、ユーザは、ナビゲーションパネル１０６０２内のハイライト表示されている選択をより具体的Ｐａｎｔｈｅｒａプロパティに変更した（Ｃａｒｎｉｖｏｒａプロパティの下の孫ノード）。図１０６に示されているように、この変更により、表示パネル１０６０４では、Ｐａｎｔｈｅｒａプロパティノードの下の子に対するグルーピング、つまり、ＬｅｏおよびＴｉｇｒｉｓプロパティによりラベル付けされている画像のグループを示す（それぞれ、サブパネル１０６０６および１０６０８を参照）。図１０５および１０６から明らかなように、ナビゲーションパネル１０５０２および１０６０２ならびに表示パネル１０５０４および１０６０４を、これらのパネルに関して使用される階層プロパティとともにしようすることで、ユーザは、意味のある方法で格納されているデータを格納し、検索し、ナビゲートし、階層全体にわたって利用可能なデータの有用なサムネイルまたは他の「プレビュー」情報を取得することができる。特に、ナビゲーションパネル内の内容およびユーザ入力は、表示パネル内に与えられる内容の推進力となるが、ユーザ入力は、さらに、必要ならば、表示パネルを通じて使用することもできる。

図１０６および１０７の表示画面１０６００と１０７００とのそれぞれの比較は、本発明の少なくともいくつかの実施例により存在しうる追加の機能を示す。ナビゲーションパネル１０７０２内で様々な異なる自動リストを変更すると（例えば、図１０６のＫｅｙｗｏｒｄ＞Ｍａｍｍａｌｉａ＞Ｃａｒｎｉｖｏｒａ＞Ｆｅｌｉｄａｅ＞Ｐａｎｔｈｅｒａから図１０７のＤａｔｅＴａｋｅｎに）、ナビゲーションパネル１０７０２内の階層構造は、折り畳まれず、むしろ、ユーザがそれを終了したときのままである（例えば、示されている実施例では、Ｍａｍｍａｌｉａプロパティおよびその子の完全な階層は公開されたままである）。一般に、本発明の少なくともいくつかの実施例によれば、ナビゲーションパネル１０７０２は、表示パネル１０７０４（例えば、サブパネル１０７０６および１０７０８内の）に表示される内容を反映または反映するように変更されず、むしろ、ナビゲーションパネル１０７０２は、表示パネル１０７０４に示されている内容の推進力となる。

ナビゲーションパネル１０７０２の「非折り畳み」機能は、様々な理由で有用な場合がある。例えば、一般に、ユーザは、この階層が、例えば、従来の電子ファイルおよび／またはフォルダシステムの対話操作から、この方法で公開されたままであることを期待する。他の実施例では、この方法で、階層を開いたままにする、展開されたままにする、および使用可能な状態のままにする機能は（例えば、ユーザによって閉じられるまで）、例えば、ユーザが、例えば追加の検索、ナビゲーション、またはプレビューを目的として、階層に戻ることを決定した場合に、比較的便利である。さらに、ナビゲーションパネル１０７０２を、ユーザがナビゲートし、潜在的に手動によりそれを変更するときに、変更されない状態に残すと、ユーザが訪れた過去の場所は、容易に利用可能な状態にあり、そのため、必要ならば、元いた場所にすぐに戻ることができる。

必要ならば、本発明の少なくともいくつかの実施例により、グルーピングおよびスタッキングの組合せを表示パネル内で使用することができる。グルーピングおよびスタッキングのこのような組み合わせた使い方の一実施例は、例えば、図１０８に示されているユーザインターフェース表示画面１０８００の表示パネル１０８０４に見ることができる。より具体的には、図１０８は、格納されている音楽に関係する情報の少なくとも一部が階層プロパティを含む、格納されているデジタル音楽のコレクションに関係する情報を含むナビゲーションパネル１０８０２を備える表示画面１０８００を示している。この例示的な表示１０８００では、ユーザは、含まれている音楽データは様々な異なるジャンルの音楽を含むプロパティとともに格納されている「ＳｕｐｅｒＭｕｓｉｃＶｉｅｗ」というタイトルが付いている自動リストをハイライト表示にした（例えば、「Ｃｌａｓｓｉｃａｌ」音楽に１つの子ノード、「Ｊａｚｚ」に１つの子ノード、「Ｐｏｐ」に１つの子ノード、「Ｒａｐ」に１つの子ノードなど）。もちろん、本発明から逸脱することなく、ジャンルをいくつでも階層構造内に含めることができる。

親「ＳｕｐｅｒＭｕｓｉｃＶｉｅｗ」ノードを選択することにより、本発明のこの実施例によるシステムおよび方法は、様々なジャンルによりグルーピングされたシステム上に格納されている音楽に関係する情報を表示パネル１０８０４に表示する（例えば、ジャンル「Ｃｌａｓｓｉｃａｌ、「Ｊａｚｚ」および「Ｐｏｐ」に対しそれぞれサブパネル１０８０６、１０８０８、および１０８１０）。それぞれの個別のジャンルグルーピング内で、この実施例では、情報は、例えば、アルバムまたは音楽の選択がリリースされた１０年の期間分だけスタッキングされる。必要ならば、ユーザは、さらに、例えば、表示パネル１０８０４またはナビゲーションパネル１０８０２内で階層構造の中へ「ドリルダウン」し、スタック内に格納されている情報に関係するさらに詳細な情報を見ることができる（例えば、個々のＣＤ中はアルバムタイトル、この示されている実施例では、個々のアルバムを含むスタックとともに演奏グループまたはアーティストでスタックされた情報など）。さらに、個々のＣＤまたはアルバムタイトルに絞り込むことを、必要ならば、本発明のシステムおよび方法の少なくともいくつかの実施例において、使用し、アルバムまたはＣＤ上に含まれる個々の楽曲またはトラックのタイトルに関する情報を表示することができる。もちろん、本発明から逸脱することなく、スタック、グルーピング、および／または所望の種類の情報をいくつでも階層プロパティ構造内に含めることができる。

特に、図１０８に示されているこの例示的なナビゲーションパネル１０８０２および表示パネル１０８０４では、ＡｕｔｏＬｉｓｔの階層の少なくとも一部分が、グルーピングまたはスタッキングが表示パネル１０８０４内に表示されるかどうかに関係なく、ナビゲーションパネル１０８０２内に表示される。実際、この例示的な構造では、表示パネル１０８０４は、グルーピングされた情報とスタッキングされた情報の両方を含む。一般に、グルーピングされた情報は、「透過的コンテナ」として存在するが、これは、グルーピング内の内容がビュー内で、ユーザから容易に利用することができ、ユーザに見えることを意味する。他方、「スタック」に含まれる情報は、「不透明コンテナ」内にあるものと考えることができ、これは、個別の内容の少なくとも一部は、スタッキング表示のためユーザから隠すことができることを意味する（しかし、非表示の内容は、必要ならば、ナビゲーションパネル１０８０２および／または表示パネル１０８０４を介して個々のスタック内にハイライト表示するか、または「ドリルダウン」することにより表示または利用可能にすることができる）。

本発明のいくつかの実施例によるシステムおよび方法に含まれるウィンドウ、表示パネル、サブパネルなどの場合と同様に、利用可能な情報が多く利用可能な表示領域に収まらない場合、ユーザが未表示情報にアクセスするため、所望の方法、例えば、表示パネル１０８０４に示されているようなスクロールバーの使用、「ｎｅｘｔｐａｇｅ」／「ｐｒｅｖｉｏｕｓｐａｇｅ」ボタンまたはアイコン、および／または他の何らかの望む方法を使用することができる。

本発明のいくつかの実施例による階層プロパティおよび他の要素、情報のグループおよび／またはスタックのナビゲーションパネル、および表示を、本発明から逸脱することなく、従来のフォルダ構造と併用することができる。一般に、スタッキングフォルダ（例えば、表示パネル内の）は、ユーザにとっては有用ではないが、それは、階層構造内の個々のフォルダは、非常に異なる、独立した対象を持つことがあり、またフォルダ内の情報を編成するユーザは、そのフォルダ階層の与えられたレベルで多くのファイルを格納することをしないことが多いためである。したがって、本発明の少なくともいくつかの実施例によれば、フォルダ内のスタッキングにより、フォルダ階層はフラットにされ、そのプロパティに基づいて、フォルダ内に含まれるアイテムが集合に再編成される。図１０９は、中に含まれるフォルダ階層構造とともにナビゲーションパネル１０９０２を含む表示画面１０９００を示している。「Ｖａｃａｔｉｏｎ」フォルダがナビゲーションパネル１０９０２においてユーザにより選択された場合、表示画面１０９０４には、基礎となるフォルダ構造が表示されるとともに（つまり、この実施例では「Ｖａｃａｔｉｏｎ」フォルダ内の「ＬｕｎａｒＥｃｌｉｐｓｅ」および「Ａｕｒｏｒａ」フォルダ）、それらのフォルダ内に含まれる個々のファイルが表示される（それにより、フォルダ構造が「フラット」にされ、基礎となる情報がユーザに見やすくなり、また利用しやすくなる）。これは、例えば、選択されたフォルダおよびそのサブフォルダすべてが見えるようにスコープが設定された「ＡｕｔｏＬｉｓｔ」要素またはノードを作成することにより実現することができる。

もちろん、表示パネル１０９００内のフォルダから情報を表示する他の方法も、本発明から逸脱することなく可能である。例えば、必要ならば、図１０９に示されている階層構造をフラットにする代わりに、特にハイライト表示されているフォルダ自体が複数の階層レベルを含んでいる状況では、表示パネル１０９０４内にフォルダ構造を維持することができる。例えば、必要ならば、ナビゲーションパネル１０９０２内でフォルダが選択された場合、サブフォルダから個々のアイテムを削除し、サブフォルダにちなんで名付けられたスタック内のアイテムを表示することにより、表示パネル１０９０４内に情報を表示することができる。もちろん、他の表示技術も、本発明から逸脱することなく可能である。

また、ナビゲーションパネル内でハイライト表示または選択された後、データに対し様々な操作を行うことができ、および／またはそれに関係する情報は、表示パネルに表示される。図１１０は、本発明の少なくともいくつかの実施例により使用することができ、および／または表示することができる例示的な表示画面１１０００を示している。この実施例では、ユーザインターフェース表示画面１１０００は、階層フォルダ構造が表示されるナビゲーションパネル１１００２、および表示パネル１１００４を含む。この実施例ではフォルダ構造の階層が深いため、ナビゲーションパネル１１００２においてフォルダがハイライト表示された場合（例えば、この実施例では「Ｖａｃａｔｉｏｎｓ」フォルダ）、表示パネル１１００４内の情報は、基礎となるサブフォルダ構造（つまり、「Ｖａｃａｔｉｏｎｓ」フォルダの下のフォルダ）から削除され、個々のスタック内に配置される。次いで、もしユーザが情報の再編成を行うとすれば（例えば、ナビゲーションパネル１１００２内の「Ｌｏｃａｔｉｏｎ」アイコンまたは他のプロパティアイコンをクリックする、右クリックまたはドロップダウンメニューからプロパティを選択するなどにより）、データは、図１１０に示されているように、場所で再編成とスタッキングを行えることであろう。図１１０のデータのこのような改訂されたスタッキング（「Ｖａｃａｔｉｏｎｓ」および「Ｌｏｃａｔｉｏｎ」によりスタッキングされる）はそのフォルダに用意されている方法では「Ｖａｃａｔｉｏｎｓ」フォルダの内容に対応しないため、ハイライト表示は、図１１０のナビゲーションパネル１１００２には表示されない。実際、このアクションは、選択されたフォルダ（つまり、この実施例の「Ｖａｃａｔｉｏｎｓ」フォルダ）に含まれているすべての情報のフラット化に似ており、次いで、選択されたプロパティの下に含まれる子プロパティに基づいてスタックへのこの情報の再編成に類似している。

もちろん、例えば、上述の種類のナビゲーションパネル内でのユーザコマンドに対する応答として行われるグルーピングおよび／またはスタッキングの多くのオプション、およびユーザコマンドへの応答として実行される他のシステムアクションは、本発明から逸脱することなくシステムおよび方法において実現することができる。以下は、本発明の少なくともいくつかの実施例に含めることができるオプションの少なくともいくつかの追加の実施例を含む。

一実施例として、多値であるプロパティによりグルーピングまたはスタッキングを行う場合、本発明の少なくともいくつかの実施例によるシステムおよび方法では、プロパティの下のそれぞれの最上位レベルの値について１つのグループまたはスタックを用意することができ、さらに、子プロパティ値は、表示パネルには公開することができない（ただし、必要ならば、低位の子プロパティ値における基礎となる情報は、表示することができ、および／または表示するために利用可能にできる）。このようなシステムでは、必要ならば、ユーザは、様々な階層レベルグループにナビゲートする、例えば、階層ナビゲーションパネルを使用する、表示パネル内に用意されたスタックにドリルダウンするなどにより、子プロパティ値を公開することができる。

必要ならば、本発明の少なくともいくつかの実施例によれば、すべてのキーワード（グルーピングまたはスタッキングされた）をフラットリストとして表示する方法を用意する必要はなく、ナビゲーションパネル内でハイライト表示されている情報が、表示パネル内に表示される内容を制御する。必要ならば、本発明の少なくともいくつかの実施例によるシステムおよび方法により、ユーザは、例えば、ユーザが「ｅｘｐａｎｄａｌｌｓｔａｃｋｓ」、「ｅｘｐａｎｄｔｈｉｓｓｔａｃｋ」などを実行できるメニューアイテム（例えば、ボタン、右クリックメニュー、ツールバーメニューなど）を用意することにより、任意のレベルで「アンスタック」することができる。

情報のグルーピングおよび／またはスタッキングが行われている間に他のアクション、例えば、グループおよび／またはスタックに含まれる階層プロパティに関係するオペレーションを実行することもできる。一実施例は、ドラッグおよび／またはドロップオペレーションに関する。本発明の少なくともいくつかの実施例では、一方のグループから他方のグループへアイテムをドラッグするときに、アイテムは、新たに適用されるグループおよび／またはスタックの（複数の）プロパティ値がそのアイテムに適用されるように変更することができる（つまり、ドラッグおよび／またはドロップオペレーションから「デスティネーション」グループおよび／またはスタックの（複数の）プロパティ値を含むように、また適宜、必要ならば、また望ましければ、元のソースグループおよび／またはスタックの（複数の）プロパティ値を削除するように変更することができる。他の例示的なオペレーションは、「貼り付け」オペレーションに関する。貼り付けオペレーションによりアイテムが新しいグループおよび／またはスタティック内に置かれた場合、デスティネーションプロパティおよびその（複数の）親プロパティ値を、新しく配置されたアイテムに適用することができる。

さらに、グループおよび／またはスタック内へのナビゲートへの応答として、多くの異なる種類の表示または表示内容を与えることができる。しかし、上述のように、本発明の少なくともいくつかの実施例によれば、グループタイトルプロパティ値を持つすべてのアイテムは、このグループの子プロパティ値／親プロパティ値（もしあれば）でタグ付けされたすべてのアイテムとともに、初期表示に示すことができる。必要ならば、ある種のインジケータをナビゲーションパネルおよび／または表示パネル内に用意し、階層内のアイテムをさらに展開して、子プロパティ値を表示できることを示すことができる（例えば、本明細書の図に示されている実施例のいくつかにおいて、アイコンまたはウィジェットとともに「＋」記号が使用されている）。この同じ規約は、本発明から逸脱することなくフィルタ処理メニュー内で使用することができる。図１１１は、表示画面１１１００の表示パネル１１１０４に含まれる情報をユーザ側でさらにフィルタ処理できるようにする例示的なメニュー１１１０２がプルアップされている（例えば、右クリックアクションを介してまたは他の適切な方法で）例示的な表示画面１１１００を示している。より具体的には、この実施例では、フィルタ処理に使用される所望のメニューアイテムをクリックすることにより、表示パネル１１１０４上に存在する情報に変更を加えることができる。この実施例では、それぞれのメニューアイテムの一番右側にあるキャレット構造「＞」は、さらに低い階層レベルが、必要ならばフィルタ処理に使用できることを示すために使用される。

本発明の追加の態様は、さらに、上述のシステムおよび方法を含む、様々なグルーピングおよび／またはスタッキング方法を実行するために、および／またはグルーピング、および／またはスタッキング方式でプロパティ、フォルダ、リストなどの情報を表示する様々なシステムにおいて使用するために中に格納されているコンピュータ実行可能命令を含むコンピュータ可読媒体にも関する。コンピュータ可読媒体は、上述のコンピュータ可読媒体の様々な特定の実施例において格納されるコンピュータ実行可能命令を構成することができる。

^**ページ空間コントロールにおける複数のルート：知られているナビゲーションシステムは、単一ルートノードしか組み込まないので、ナビゲーションツリーは、ユーザのフォルダおよび他の構造の編成を単一の表現に制限する。このような制限は、比較可能な関連性を有するフォルダを効率よく表示しナビゲートするうえで実質的な障害となりうる。一実施例では、ユーザのそれぞれの記憶装置ドライブ上でユーザが利用できる領域が制限されている場合があり、したがって写真を２つの別々のドライブ上に格納せざるを得ない。知られている単一ルートによる解決方法では、ユーザは、ナビゲーションツリーを大幅に２つの異なる格納ポイントに展開することにより両方の格納領域にアクセスせざるを得ない。このようなナビゲーション方法では、両方の写真集合を同時に見ることが妨げられる。そのため、本発明のいくつかの態様によれば、アプリケーションまたはユーザ側で、ページ空間コントロールにおいて複数のルート、例えば、上述のナビゲーションパネルを設定することができる。

図１１２は、本発明の例示的な実施形態による多重ルートナビゲーションペインを実装するシェルブラウザウィンドウの部分スクリーンショット１１２００を示す。シェルブラウザウィンドウ１１２０１は、ウィンドウの一番上に指し渡されているメニューバー１１２０５、右側にあるシェルブラウザペイン１１２１０、シェルブラウザウィンドウ１１２０１の左側にそって置かれている多重ルートナビゲーションペイン１１２１５からなる。シェルブラウザウィンドウ１１２０１内の多重ルートナビゲーションペインの実装により、本明細書で説明されているように、ユーザがナビゲートする自由度が大幅に高まる。ユーザは、シェルブラウザペイン１１２１０内のページビューを介して個々のフォルダまたはページにアクセスすることによりファイルおよび／またはデータを閲覧するか、またはページビューに対応するドキュメントまたはファイルを表す所望のノードに直接ジャンプすることによりナビゲーションペイン１１２１５を使用してナビゲートすることができる。本明細書で使用されているように、１つのページは関係するドキュメントの１コレクションを参照し、１つのページビューは特定のページ内のデータアイテムのグラフィック表示を参照し、１つのページノードは特定のページのアイコンまたはグラフィック表現を参照する。それぞれのページは、静的リスト、自動リスト、物理フォルダ、仮想フォルダ、および関係するファイル、データ、またはページの他の何らかの構造またはデータコレクションを含み、および／または表すことができ、シェルブラウザペイン１１２１０内に表示されるそれぞれのページは、以下でさらに説明するように、ナビゲーションペイン１１２１５内に表示される対応するノードを持つことができる。シェルブラウザペイン１１２１０およびナビゲーションペイン１１２１５の両方を同時に表示する機能により、多重ルートナビゲーションペイン１１２１５に関連付けられているカスタマイズオプションの多くが使いやすくなる。例えば、フォルダまたはリストを、シェルブラウザペイン１１２１０からナビゲーションペイン１１２１５にドラッグして、ナビゲーションペイン１１２１５内に追加のルートを定義することができる。ナビゲーションペイン中の、ルートノードは、一般に、親ページノードを欠いているページノードに関係する。本発明の一態様によれば、ナビゲーションページ内のそれぞれのルートノードは、親ノードを持ちうるが、ナビゲーションペインは、ルートノードとして識別されているノードの親を表示しない。そのため、ユーザは、ルートノードの親には、親が存在しているのに、そのルートノード自体を介してナビゲートすることができない。

図１１３は、本発明の例示的な実施形態による多重ルートナビゲーションペインを示す図である。多重ルートナビゲーションペイン１１２１５は、複数のルートノード１１３１１、１１３１２、および１１３１３を含むことができる。ルートノードは、一般に、ハードディスクなどデバイス上に格納されているデータをナビゲートする際の出発点として使用できる。ナビゲーションペイン１１２１５は、ルートノード１１３１１、１１３１２、および１１３１３を展開されている子孫ノードと組み合わせて、データの編成をグラフィックで表示する。一階層表現では、ルートノード１１３１１、１１３１２、および１１３１３は、ナビゲーションペイン１１２１５内の単一縦軸にそって揃えられ、これにより、そのステータスをルートノードとして伝達できる。したがって、ルートノード１１３１１、１１３１２、および１１３１３の子ページ１１３２１、１１３２２、および１１３２３は、それぞれ、それぞれのルートノードの下に配置され、ルートノード１１３１１、１１３１２、および１１３１３の縦軸の右に配置された第２の縦軸上に揃えることができる。第１のページまたはノードは、第１のページが直接、第２のページに依存する場合に第２のページまたはノードの子孫であると言われる。ルートノード１１３１１、１１３１２、および１１３１３と子孫ページノード１１３２１、１１３２２、および１１３２３の相対的位置決めにより、その階層的関係がグラフィックで描かれる。格納階層の他のレベル（例えば、ルートノードの子孫の子孫）は、向きに関して親ページノードの位置を使用して上述の方式に従ってナビゲーションペイン１１２１５上に表すことができる。当業者であれば、当技術分野で知られているように、ルートノードとその子孫の階層的関係を表すために、多数の先祖／子孫の向き付け方式を使用することができることを理解するであろう。

それぞれのルートノード１１３１１、１１３１２、および１１３１３ならびに子孫ページノード１１３２１、１１３２２、１１３２３は、さらに、展開制御ウィジェット１１３２０、識別するアイコン１１３２６、および識別テキスト１１３２５を含むことができる。一般に、識別テキスト１１３２５は、中に格納されているページまたはファイルの一般カテゴリまたは記述を伝えるものである。例えば、ルートノード１１３１１には、「Ｌｙｏｎ’ｓＤｏｃＦｏｌｄｅｒ」というラベルを付けて、ユーザＬｙｏｎに属しているドキュメントとしてそのページの内容を識別することができる。識別するアイコン１１３２６は、識別テキスト１１３２５に隣接して配置することで、ユーザは１つまたは複数のルートノード１１３１１、１１３１２、および１１３１３またはページノード１１３２１、１１３２２、および１１３２３をグラフィックで区別するようにできる。例えば、ユーザは、独自のアイコンを作成して、特定のページを自分が所有していることを示すマークとしたり、表されている場所に格納されているファイルのタイプを示すことができる。同様に、ユーザは、異なるアイコンを使用して、異なる種類のページ（つまり、フォルダ、リスト、自動リスト）を表すことができる。ページノードにアクセスしその内容を表示するために、ユーザは、識別テキスト１１３２５をダブルクリックするか、またはその特定のノードに関連付けられている展開制御ウィジェット１１３２０を切り替えることができる。これらの方法のいずれかを使用することにより、ユーザは、親ページノードを展開して、その子孫ノードを表示状態にすることができる。展開制御ウィジェット１１３２０がない場合は、ページノードが子孫を持たず、そのため、展開できないことを意味しうる。展開制御ウィジェット１１３２０が存在する場合、制御ウィジェット１１３２０は、対応するページノードの現在状態（つまり、展開されているか、または折り畳まれている）。例えば、展開制御ウィジェット１１３２０は、ページノードが折り畳まれている（つまり、子孫ノードを非表示にしている）場合、識別テキスト１１３２５を起点とする透明矢印１１３５０を含むことができる。逆に、ページノードが展開状態にある場合、展開制御ウィジェット１１３２０は、そのページノードの表示されている子孫に向かう暗い色の矢印１１３５１を含むことができる。展開制御ウィジェット１１３２０は、当技術分野で知られているように、様々な方法で、また「＋」および「−」などの、様々な記号、色、および／またはアニメーションを使用して実装することができる。

図１１４Ａは、本発明の例示的な一実施形態によりナビゲーションペインをカスタマイズする方法を示している。ユーザは、新しいルートノードを追加すること、既存のルートノードを削除すること、ページノードの順序をペイン内に出現する通りに修正すること、およびページまたはルートノードヘのショートカットを作成することを含む様々な方法でナビゲーションペイン１１２１５をカスタマイズすることができる。この実施形態では、ナビゲーションペインをカスタマイズする方法を使用することで、ユーザは、指定されたページを表すノードをそのペイン１１２１５にルートノードとして追加することができる。新しいルートノードの追加により、関係のない親ページを回避することにより頻繁に使用されるページにナビゲートしやすくなる。新しいルートノードを追加するために、ユーザは、最初に、当技術分野で一般に知られているシェル閲覧方法を使用して所望のページ１１４５７を特定することができる。例えば、ユーザは、図１１２のシェルブラウザペイン１１２１０を使用して所望のページ１１４５７を特定することができる。所望のページ１１４５７を特定した後、ユーザは、次いで、図に示されているようにページ１１４５７を選択してシェルブラウザペイン１１２１０（図１１２）からナビゲーションペイン１１２１５にドラッグすることができる。

新しいルートノードを作成するユーザ要求を受け取った後、ナビゲーションペイン１１２１５では、ページタイプを識別し、そのページの物理的な場所を取得し、そのページの子孫を決定し、そのページの物理的な場所を指すポインタおよび子孫の展開可能／折り畳み可能リストを含むルートノードを作成することができる。単純なポインタまたはショートカットとは対照的に、ルートノードは、ユーザがノードを選択することにより対応するページを表示することができるだけでなく、子孫の関連するリストの表示または非表示（つまり、展開または折り畳み）を行うこともできる動的ツールである。例えば、ユーザが、ナビゲーションペイン１１２１５内でフォルダ「Ｌｏｕｉｅ’ｓＤｏｃｕｍｅｎｔｓ」をルートノードにしたい場合、ナビゲーションペイン１１２１５では、フォルダページタイプであることを識別する。その後、ナビゲーションペイン１１２１５では、ペイン１１２１５内に「Ｌｏｕｉｅ’ｓＤｏｃｕｍｅｎｔｓ」の物理的または仮想的な場所を指す「Ｌｏｕｉｅ’ｓＤｏｃｕｍｅｎｔｓ」という名前でノード構造を作成する。ルートノードが静的または動的リストを表す場合、ルートノードは、参照先のリストの定義の配置を識別する情報を格納することができる。追加のページ／ルートノードは、ナビゲーションペイン１１２１５に同様に追加することができる。本発明の一実施形態では、ルートノードのリストは、システムオプション、ハードウェアなどに対応するデータおよび設定を収めることができるレジストリ内に格納される。レジストリなどの媒体内の記憶域により、ナビゲーションペイン内のルートノードのカスタムリストを、閲覧セッションから閲覧セッションまで永続させることができる。当業者であれば、ノードのリストは、他の多数の方法を使用し、様々な他の媒体に格納することができることを理解するであろう。

ユーザは、コンテキストメニュー内に用意されている削除オプションを使用することによりナビゲーションペイン１１２１５から既存のルートノード１１３１２を削除することができる。本発明の一実施形態では、ユーザは、ルートノード１１３１２を選択し、および／または右クリックする（つまり、マウスを使用する）ことにより、特定のノード１１３１２のコンテキストメニューにアクセスすることができる。ユーザがコンテキストメニューから削除オプションを選択すると、ナビゲーションペイン１１２１５は、選択されたルートノード１１３１２および子孫１１４１２のその関連するリストを削除する。

図１１４Ｂを参照すると、ユーザは、さらに、ルートノード１１３１１、１１３１２、および１１３１３を選択して、ナビゲーションペイン１１２１５内の好ましい場所にドラッグすることにより、ルートノード１１３１１、１１３１２、および１１３１３の順序を調整することができる。ユーザは、同様に、共通の親を持つ兄弟ノードの順序付けを変更することができる。デスティネーションの場所は、位置インジケータ１１４７０により識別することができ、このため、ルートノードの正確な再配置が可能になる。例えば、ユーザは、Ｌｙｏｎ’ｓＤｏｃＦｏｌｄｅｒ１１３１２を再編成するのに、Ｗｏｒｋページ１１４９０を位置インジケータ１１４７０により識別された場所にドラッグする。それとは別に、ユーザは、ナビゲーションペイン１１２１５上の既存のページをデスクトップにドラッグすることもできる。そうするために、ユーザは、ナビゲーションペイン１１２１５からページノードを削除することなく、デスクトップ上のショートカットを選択されたページに作成することができる。そのような場合、ナビゲーションペイン１１２１５は、ノードポインタのコピーを作成し、そのコピーをデスクトップ上に置くことができる。さらに他の形態（図に示されていない）では、ユーザは、同じ階層レベル上に出現するように、親および子ノードを固定することができる。例えば、ユーザは、「Ｌｙｏｎ’ｓＤｏｃＦｏｌｄｅｒ」１１３１２および子フォルダ「Ｗｏｒｋ」１１４９０をピンで固定することができる。親および子フォルダをピンで固定することにより、「Ｌｙｏｎ’ｓＤｏｃＦｏｌｄｅｒ」１１３１２および「Ｗｏｒｋ」１１４９０は、ナビゲーションペイン内の同じ階層レベルに出現し、しかも基礎の構造を実際に修正する必要がない。このような機能により、ユーザは、恒久的な変更を加えることなく、ナビゲーションペインの階層ビューを一時的に修正することができる。

ユーザは、さらに、本発明の例示的な実施形態による図１１５に例示されているのと類似の構成ダイアログを使用してルートノードを追加し、削除し、名前変更し、および／または順序変更することもできる。構成ダイアログ１１５００は、ｄｉｓｐｌａｙｅｄｐａｇｅｓペイン１１５０５、ａｖａｉｌａｂｌｅｐａｇｅｓペイン１１５１０、ａｄｄボタン１１５１５、ｒｅｍｏｖｅボタン１１５２０、順序変更ボタン１１５２５および１１５２６、ｒｅｓｅｔボタン１１５３０、ｒｅｎａｍｅボタン１１５３５、およびｓｅｔａｓｈｏｍｅｐａｇｅオプション１１５４０を含むことができる。構成ダイアログ１１５００では、ユーザは、ｄｉｓｐｌａｙｅｄｐａｇｅｓペイン１１５０５内でナビゲーションペインの内容を修正しつつ、１つのペイン１１５１０内に利用可能なページの一覧を表示させることができる。ａｖａｉｌａｂｌｅｐａｇｅｓペイン１１５１０には、選択された場所に対応する選択可能なページの一覧が表示される。ユーザは、ドロップダウンメニュー１１５５０を使用することにより、選択された場所を変更することができる。ユーザに、利用可能なページの一覧が表示された後、ユーザは、利用可能なページを選択し、ａｄｄオプション１１５１５を選択して、選択されたページに対応する新しいルートノードを作成することができる。Ｄｉｓｐｌａｙｅｄｐａｇｅｓペイン１１５０５では、新しいルートノードの追加を反映するように、その内容を自動的に更新することができる。つまり、変更が削除されると、構成ダイアログ１１５００は、最新情報を反映するようにペイン１１５０５および１１５１０を更新することができる。

ユーザが現在のルートノードを削除することを望んでいる場合、ユーザは、ｄｉｓｐｌａｙｅｄｐａｇｅｓペイン１１５０５内のルートノードを選択し、ｒｅｍｏｖｅオプション１１５２０を選択することができる。ルートノードを削除した後、ナビゲーションペインは、そのノードと対応するページとの関連を解除し、そのペインからノードを削除する。他のオプションでは、ユーザは、現在のルートノードの名前変更を行ったり、ルートノードをホームページとして設定したりすることができる。ユーザは、ノードを選択し、矢印ボタン１１５２５および１１５２６を使用して相対的位置を調整することにより、ｄｉｓｐｌａｙｅｄｐａｇｅｓペイン１１５０５内のルートノードの順序を変更することができる。ユーザが、１つまたは複数のルートノードの追加、削除、順序変更、または名前変更で誤りを犯した場合のために、ナビゲーションペインに加えた変更をリセットするｒｅｓｅｔオプション１１５３０が用意されている。ｒｅｓｅｔボタン１１５３０を選択することにより、ウィンドウ１１５００が最後に開かれてからユーザが加えた変更を元に戻すことができるか、またはユーザが加えた変更を元に戻すことで、既定の状態に戻ることができる。

図１１６Ａは、本発明の例示的な一実施形態によりページノードをカスタマイズするためのｐａｇｅｐｒｏｐｅｒｔｙダイアログを例示している。ユーザは、プロパティダイアログ１１６００を通じて指定ページノードの前述のプロパティを構成することができる。プロパティダイアログ１１６００は、展開制御選択ツール１１６０３、アイコン選択ツール１１５０５、および識別テキスト変更ツール１１６１０、サイズ選択バー１１６１５、および非表示オプション１１６２０を備えることができる。展開制御選択ツール１１６０３およびアイコン選択ツール１１６０５を使用すると、ユーザは、自由に、展開制御アイコン（例えば、以前のオペレーティングシステムにおける「＋」および「−」に）および識別テキストの隣の代表するアイコンを変更することができる。展開制御選択ツール１１６０３およびアイコン選択ツール１１６０５は、ドロップダウンリストを通じて、またはユーザが画像およびアイコンのデータベースを検索し、そこから選択できるシェルブラウザユーティリティを通じて、実装することができる。展開制御選択ツール１１６０３に関して、ユーザは、折り畳まれた状態と展開された状態のそれぞれを表す２つの画像を選択するよう求められる。それとは別に、選択ツール１１６０３および１１６０５は、利用可能なアイコンまたは画像の定義済みメニューを含むことができる。ユーザがアイコンを選択した後、ページノードに適用するのに先立って変更をプレビューするオプションをユーザに与えることができる。

それに加えて、ユーザは、ページノードおよび基礎になっているページの識別テキストの内容と外観を変更することができる。これは、ナビゲーションペイン内のテキスト編集をするか、またはそれとは別に、プロパティダイアログ１１６００を使用して、実行することができる。プロパティダイアログ１１６００は、フォント、フォントサイズ、スタイル（斜体、太字、小文字など）、および色を調整するためのオプションを備えることができる。例えば、ユーザは、フォントサイズを大きくし、特定の意味または重要性を持つページならびにその代表するノードのフォント色を変更することができる。このような機能により、ユーザは、ページが高い重要度または関連度を持つことを他のユーザに識別させることができる。

ページプロパティ構成ダイアログ１１６００の他のオプションを使用すると、ユーザは、ナビゲーションペイン内のページノードを非表示にし、ナビゲーションペインを表示するときにページノードが見えないようにすることができる。本発明の一実施形態では、ページノードが非表示の場合、ナビゲーションペイン内でその子孫ノードをルートノードステータスに格上げすることができる。そのため、非表示オプションにより、ユーザは、複数のルートノードを同時に作成することができる。非表示にされたページノードを含むナビゲーションペインは、図１１６Ｂに例示されている。グループ１１６１０は、非表示にされた自動リストルートノードの子孫ページノードを含むが、非表示にされているノードに関係しないＦｏｌｄｅｒｓページノード１１６１５も見える。特定のルートノードを非表示にすることも、ユーザが非表示のルートノードに依存しているページを包括的に操作するときに都合がよい場合がある。ノードを非表示にすることにより、ユーザは、子ノードを対話操作するためにルートノードを連続的に展開し、折り畳む必要がなくなる。

^**多値プロパティ：さらに図５１〜６６に関して上の説明をさらに進めると、本発明の追加の態様では、プロパティ（またはメタデータ）のユーザによる修正を可能にするシステムおよび方法を実現することができる。一態様では、多値プロパティを含むことができるファイルプロパティの表示を含むシェルブラウザが備えられる。ユーザは、多値プロパティを編集することができ、システムは、高度な判断を行う機能により、ユーザによる多値プロパティの編集を補助することができる。システムは、多値プロパティ値をトークン化することができ、フィールドのオプションをユーザに喚起する手段として多値プロパティフィールド内に永続的なプロンプトテキストを備えることができる。

システムは、集約されたプロパティ値を表示することができ、視覚的な差を組み込んで、集約された値を適用先のファイルに関連付けることができる。集約された値の編集は、可能であり、集約された多値プロパティを編集するときに、システムは、高度な判断を行う機能により、ユーザがすでに使用されているエントリおよびプロパティ値が使用されているコンテキストなどの様々な因子に基づいてエントリを選択（または回避）するのを補助することができる。複数の選択されたファイルについて多値プロパティを集約するときに、システムでは、特定の値が様々なファイル内に出現した順序を保存しやすくする措置を講じることもできる。ファイルの多値プロパティの先頭に比較的頻繁に出現する傾向を有していた値は、対応する集約された多値プロパティの先頭の方に向かって出現する傾向を有する。

図１１７Ａ〜Ｂは、上で説明され、またここで説明されている機能とともに使用することができるプレビュープロセスの例示的な流れ図を示している。このプロセスの初期ステップとして、ステップ１１７０１で、システム上に１つまたは複数のプレビューアをインストールすることができる。プレビューアは、基礎になっているオペレーティングシステムソフトウェアの一部として出荷されるソフトウェアであってよい。プレビューアは、さらに、出荷後にコンピュータシステム上にロードされる追加のソフトウェアとすることもできる。例えば、基礎のオペレーティングシステムは、プレビューアを将来開発し、および／または追加することができるように一連のアプリケーションプログラムインターフェース（ＡＰＩ）を公開することができる。

ステップ１１７０２では、新しい関連付けが１つまたは複数のプレビューアに対して作成されるかどうかを判定するチェックを実行することができる。関連付けは、使用されるプレビューアの回数およびタイプを決定する基準および／または要求とすることができる。与えられたユーザ識別に対し（または特定のユーザがプレビューを完全に無効にしたい場合）、および／またはシステム条件（例えば、利用可能なリソース、メモリ、現在実行中のアプリケーション、生成される、または生成されるべきプレビューの数、利用可能なパワー、時刻、他のアプリケーションのステータスなど）およびファイルタイプ（例えば、ユーザは、ホームビデオに一方のタイプのプレビューアを使用し、圧縮された楽曲に対しては異なるプレビューアを使用することを好む場合がある）に基づくいくつかの定義済み状況に対し、使用すべき（複数の）プレビューアのタイプを定義する関連付けを作成することができ、したがってシステムにより使用される既定のプレビューアは、ユーザ側で定義することができる。ユーザは、いくつかのファイルタイプには基本／非対話的プレビューアしか設定されないことを指示することができるか、または障害、クラッシュ、ハングが定義済みの回数だけ発生した場合にシステム側でプレビューを自動的に無効にすることができる。アプリケーションは、そのアプリケーションから開かれたプレビュー、またはそのアプリケーションにより作成されたファイルのプレビューが、常に、同じプレビューアを使用してプレビューできるように、１つまたは複数のプレビューアに関連付けることができる。これらの関連付けは、本質的に階層的であり、したがって、複数のプレビューを優先順に順位付けすることができる。新しい関連付け１１７０２を要求するステップは、始動時、アプリケーションのインストール後、所定のアプリケーションの実行後、および／またはユーザ要求により実行可能である。

新しい関連付けを作成する要求が受け取られると、その関連付けがステップ１１７０３で作成される。関連付けを作成する作業は、いくつかのプレビューアが使用される場合に満たすべき特定の基準についてユーザに問い合わせるか、またはアプリケーションおよび／またはシステム自体からそのような基準情報を自動的に取り出すことにより実行することができる。実際の関連付けは、作成されるときに、（複数の）プレビューアを上で識別された基準に関連付けるコンピュータシステムのメモリ内に格納されているデータの形態を取りうる。

ステップ１１７０４では、プレビューアを開く必要があるかどうかを判定するチェックを実行することができる。プレビューアを開くことをトリガすることができるイベントは多数ある。例えば、ユーザがシステム上のシェルブラウザを開き、ファイルおよび／またはフォルダの詳細を調べ始めると、ブラウザは、プレビューアを起動し、１つまたは複数の選択されたファイル（または何も選択されていない場合には既定のファイル）のプレビューを表示することができる。それとは別に、他のアプリケーションの要求があったときにプレビューアをトリガすることができる。プレビューアは、さらに、複数のアプリケーションにより共有される共通ファイルダイアログが作成されるときにトリガすることもできる。共通ファイルダイアログプレビューについて、以下でさらに詳しく説明する。

プレビューアが開かれる場合、システムは、ステップ１１７０５でプレビューされる、選択または複数の選択を受け取ることができる。これは、プレビューされるファイル（または複数のファイル）の識別を受け取ることを伴う場合がある。このような選択は、マウスポインタを一覧表示されているファイルに移動し、左マウスボタンを押すか、または選択ボックスを複数のファイル一覧の回りにクリック＆ドラッグすることにより１つまたは複数のファイルを選択するなどにより、ユーザが行うことができる。それとは別に、選択を自動的に行うようにすることもできる。例えば、いくつかのアプリケーションは、既定で所定のファイルに設定することができ、最初に開いたときにプレビューするそのファイルを自動的に選択するようにできる。ＭＩＣＲＯＳＯＦＴＷＯＲＤ（商標）などの文書処理プログラムは、既定で、テキスト編集機能を備えるプレビューアに設定することができる。システムでは、検索を実行した結果としてプレビューするファイルを自動的に選択することができる。ユーザは、キーワードなどの検索基準を入力することが可能であり、システムまたはアプリケーション側では、検索結果のうちの１つを自動的にプレビュー用に選択することができる。例えば、ユーザが、キーワードとして「ｐｅａｎｕｔ」とシステム検索ツールに入力すると、「ｐｅａｎｕｔ」を含むファイルの一覧が結果として表示され、最初の一覧表示されているファイルのプレビューが実行されるようにできる。

プレビューすべき（複数の）ファイルが選択された後、システムは、ステップ１１７０６で、適切なプレビューを選択し、生成する。適切なプレビューを選択することは、すでに作成されている１つまたは複数の関連付けに基づくことができるか（例えば、ユーザが特定のタイプのすべてのファイルをプレビューするために、またはいくつかのファイルをプレビューするために特定のプレビューアを選択した）、またさらに、利用可能な（または消費された）システムリソースに基づくこともできる。それとは別に、ユーザは、例えば、プレビューすべき選択に適していると思われる所定のプレビューアの表示されている一覧から選択することにより、現在のプレビューに使用すべきプレビューアを識別するように要求されることがある。

いくつかの状況において、よりリッチな対話的プレビューが開始されている間に表示することができる初期基本プレビューを生成することが望ましい場合がある。例えば、テキストドキュメントのリッチなプレビューがロードおよび生成に数秒を要する場合、ユーザに対し、しばらくの間、間もなく生成できるより基本的なプレビューを表示することができる。より基本的なプレビューは、リッチプレビューに備えられている対話的機能の一部を有するか、またはまったく有せず、少なくとも、ユーザによる（複数の）選択のプレビューを開始できる。

プレビューを選択することは、使用できるプレビューアの事前に格納されているシーケンスを含むことができる。例えば、特定のアプリケーションまたはビューは、完全リッチプレビューア、機能縮小プレビューア、基本サムネイルプレビュー（対話操作を必要としない）、およびＭＩＣＲＯＳＯＦＴＷＩＮＤＯＷＳ（登録商標）（商標）オペレーティングシステムで現在使用されているデスクトップアイコンに類似している基本アイコンなどの利用可能なプレビューアの階層シーケンスを持つことができる。プレビューアが開かれると、システムは、完全リッチプレビューアなどの１つのプレビューアを起動し、プレビューアのシーケンスを通じて後退し、最も適しているものを見つけることができる。例えば、完全リッチプレビューは、ユーザがプレビューからドキュメントを修正できるページング、拡大縮小、およびテキスト編集機能を備えるプレビューアを、既定として特定のビュー用に設定し、システムリソースが不十分な場合（例えば、メモリ制限、他のアプリケーション、他のプレビューアなどのせいで）そのプレビューを適切に行わせるために、システムは、リスト上の次のプレビューア（例えば、縮小機能版）をチェックすることができる。次のプレビューアは、少し少ない機能を有し、例えば、ドキュメントのナビゲート機能（例えば、ページング図を読み拡大縮小）のみを備えるが、編集機能を有しない。このようなプレビューアは、実行に必要なシステムリソースは少なくて済み、リソースが利用できない場合には好ましいと考えられる。その第２のプレビューアに用意するリソースがまだ不十分な場合、システムは、利用可能なリソースが与えられた場合に好適なプレビューアが見つかるまで、次のプレビューア（例えば、対話性がほとんどまたはまったくない基本サムネイルビュー）などをチェックすることができる。

プレビューが生成されると、プレビューは、プレビューを要求するアプリケーションから別の、異なるプロセスとして起動することができる。例えば、プレビューアがシステムシェルブラウザに用意されている場合、プレビューアは、シェルブラウザとは独立したプロセスとし実行することができる。プレビューを別のプロセスとした場合、気づくとシェルブラウザはプレビューアプリケーションからの応答を待たなければならない位置にあるということがないため、プレビューアで問題が生じた場合にクラッシュまたはハングを回避することができる。このような問題の発生源は様々である。選択されたファイルが、破損したデータを含み、プレビューアプリケーションではそれを処理できない、プレビューアプリケーション自体にエラーまたはバグがあり、円滑な動作が妨げられる、ファイルのラベルまたは識別が間違っており、誤ったプレビューアプリケーションが選択される（例えば、ファイルはそれがオーディオファイルであることを示しているのに、実際にはテキストファイルである）、またはシステムリソースに、不良メモリセクタなどの問題が生じている可能性がある。プレビューアを異なるプロセスとして用意し、クラッシュ／ハングに対しある程度抵抗を持たせる。プレビューアにエラー、クラッシュ、またはハングが発生した場合、問題は、プレビューパネル自体に限定され、シェルブラウザは、引き続き機能する。場合によっては、システムは、特定のプレビューアプリケーションに問題、クラッシュ、および／またはハングが発生した回数を記録することができ、所定の回数を超えると（例えば３）、システムは、その特定のプレビューアが使用される頻度を下げる対策を講じることができる。例えば、システムでは、そのプレビューアの優先度を低くするか、または異なるプレビューアを呼び出す関連付けを作成することができる。

ステップ１１７０７では、表示されているプレビューをユーザが対話操作していたかどうかを判定するチェックを実行することができる。対話操作は、知られているコンピュータ対話操作の形態を取りうる。例えば、対話操作は、プレビューパネル内でのマウスクリックであってもよい。対話操作は、ページングボタン、カーソル矢印などのプレビューパネル内の１つまたは複数のグラフィカルインターフェース要素の選択であってもよい。対話操作は、テキストドキュメントのプレビュー内でカーソルを移動するためのカーソル移動キーなどのキーボードキーの形態を取りうる。

対話操作が実行される場合、適切な処理がステップ１１７０８で実行される。対話操作の処理は、ユーザ入力に対する応答の形態を取りうる。例えば、この処理では、プレビューパネル内でユーザがマウスまたは他のポインタをクリックすることに対する応答として編集プロセスを起動することができる。編集プロセスでは、ユーザは、プレビューパネルを持つビューを終わらせなくても、プレビューパネルから直接、プレビューされたファイルを表示および／または編集することができる。

ステップ１１７０９で、プレビューパネルがサイズ変更されたかどうかを判定するチェックが実行される。パネルは、例えば、ユーザがコマンド入力し、および／またはプレビューパネルの境界またはサイズ変更ツールをクリック＆ドラッグすることによりサイズ変更することができる。パネルのサイズ変更がされた場合、ステップ１１７１０で、新しいサイズ変更されたパネルが表示される。必要ならば、サイズ変更されたパネルは、オリジナルパネルに見られるのと同じアスペクト比を自動的に保つように構成することができる。いくつかのファイルタイプは、関連付けなどを通じて、常に同じアスペクト比を持つように構成することができる（例えば、ビデオは、常に、４：３とすることができる）。プレビューを伴うプロパティまたはメタデータが表示された場合、プロパティおよび／またはメタデータ表示領域も、新しいプレビューパネルサイズに対応するようにサイズ変更することができる。例えば、プロパティまたはメタデータ表示領域は、プレビューパネルと同じ高さ、または幅を常に持つように構成することができる。逆に、プレビューアは、プロパティ／メタデータ表示領域のサイズ変更に対する応答としてサイズ変更することができる。必要ならば、新しいサイズは、特定のファイルタイプ、現在のビュー、アプリケーション、および／またはユーザに関連付けられた新しい既定のサイズとしてシステムに記憶しておき、次回プレビューが必要になったときに使用することができる。

ステップ１１７１１では、プレビューパネルの新しいサイズがプレビューに対する１つまたは複数の所定の閾値を通ったかどうかを調べるチェックを実行することができる。上述のように、プレビューアは、その使用に関して１つまたは複数の基準を有する場合がある。このような基準の１つは、プレビューアで使用できる表示領域の量に関係することがある。例えば、異なるレベルの対話性および／または機能を異なるサイズのプレビューに与えることができる。一実施例として、ＭＥＣＲＯＳＯＦＴＷＯＲＤ（商標）などのワードプロセッサを使用する場合、大きなプレビューは、ドキュメント内のナビゲート／ページングおよび拡大縮小、フォントサイズの変更、またはプレビュー内でカーソルを使用するテキストの編集などのさらなる詳細な機能性備えることができるが、ＭＥＣＲＯＳＯＦＴＷＯＲＤ（商標）ドキュメントの小さなプレビューは、ナビゲーションおよび拡大縮小機能を備えるが、表示が小さすぎてテキストの編集にカーソルを満足に使用できない場合、カーソルテキスト編集を省くことができる。プレビューアは、関連付けられた１つまたは複数のサイズ閾値を持ち、これは、関連付け実行時に作成され、コンピュータシステムのメモリ内に格納され、また閾値の条件を満たすか、過ぎた場合に使用する交換プレビューアを識別することができる。例えば、プレビューアは、特定のいくつかの機能を実装するために最低でも２５６ピクセルの幅を必要とするが、５１２個のピクセルがありさえすれば、他の機能を含めることができる。

新しいサイズが、最小または最大の閾値を過ぎた場合、ステップ１１７１２で、交換プレビューを選択し、生成することができる。交換プレビューの生成は、ステップ１１７０６のプレビューの生成と同一であってよい。したがって、例えば、プレビューパネルが特定の最小サイズを超えるサイズに縮小された場合、小さなサイズでそのまま使用できる対話的機能のより小さなサブセットを備える交換プレビューを使用することができる。それとは別に、プレビューパネルが特定の最大サイズを超えて拡大された場合、さらに多くのユーザインターフェースコントロールを備えるか、またはプレビュー内で詳細編集を行えるプレビューアなど、大きなサイズが与えられた場合に有用なさらに多くの機能を備える交換プレビューを使用することができる。

ステップ１１７１３では、表示されているプロパティ、またはメタデータの断片を編集するのかどうかを判定するチェックが行われる。このようなデータは、例えば、表示されているメタデータの断片上でマウスまたはポインタをクリックし、テキスト入力またはメニューユーザインターフェースを使用して値を入力することにより、編集することができる。ステップ１１７１４では、特定のプロパティを編集するために適切なステップが実行される。実際のステップは、編集されるデータのタイプに依存しうる。データフィールドは、カレンダーユーザインターフェース要素を表示し、これにより、ユーザは、入力に対する日付（および／または時刻）値を表示し選択することができる。他のタイプのデータは、テキスト入力ボックスを通じて入力することができ、他のタイプは、プルダウンメニューなどのメニューから選択することができる。

ステップ１１７１５で、システムがリッチプレビューアのロードを待っているかどうかを判定するチェックが実行される。上述のように、リッチプレビューがシステム上で初期化されている間により基本的なまたは一般的なプレビューを用意できる。システムがリッチプレビューアを待っている場合、ステップ１１７１６で、リッチプレビューアを使用できる状態になったかどうかを判定するチェックが行われる。使用できる状態にあれば、ステップ１１７１７で、システムは、既存のプレビューをリッチプレビューで置き換える。ステップ１１７１７は、さらに、リッチプレビューがまだ望まれているかどうかを判定するためのユーザへのクエリも含むことができる。このステップは２つのプレビューアを示すが、２つよりも多いプレビューも使用できる。例えば、システムは、サムネイルプレビューを待っている間にアイコンを表示し、次いで、リッチプレビューを待っている間にサムネイルを表示し、というようにすることもできる。

ステップ１１７１８で、プレビューが閉じられるかどうかを判定するチェックが実行され、閉じられるのであれば、プレビューアは、ステップ１１７１９で、閉じられる。次いで、プロセスは、ステップ１１７０２に戻り、再び開始する。もちろん、図１１７ａ〜ｂに示されているプロセスは、多数のステップを配列する一方法を示す一実施例にすぎず、これらのステップはどれも、本明細書で説明されている機能を実装（または削除）するために必要に応じて、順序変更、繰り返し、削除、または修正を加えることができる。

図１１８は、本発明の１つまたは複数の態様を組み込んだ他のシェルブラウザインターフェース１１８００（またはシステムブラウザ）の一実施例である。ブラウザ１１８００は、１つまたは複数のディレクトリ、ネットワーク、ドライブ、フォルダなどの内容を表示するためオペレーティングシステムの一部として提供することができ、また汎用、またはアプリケーション固有でない場合もある。ブラウザ１１８００では、多数のアイテム１１８０１が一覧表示され、ファイル名、ファイルタイプ、および他のデータは、様々なアイテムについて一覧表示される。この実施例に示されているように、複数の異なるタイプのファイル（例えば、文書処理アプリケーションなどの既存のアプリケーション用のテキストファイル、画像ファイル、オーディオファイル、および／またはカスタムデータファイル）はすべて、シェルブラウザ内に表示することができる。アイテム１１８０１は、日付別編成で表示されるが（例えば、今日のファイルおよび昨日のファイル）、並べ替えまたは編成を使用することができる（例えば、ファイルサイズ、ファイル名、プロジェクト名、ファイルタイプ、アーティスト、アルバム、作成日、編集日など）。ユーザは、一覧表示１１８０１ａ（第１のパターンで視覚的に区別されて示され、赤色とすることができる）などの一覧表示の１つを選択することができ、シェルブラウザ１１８００は、選択されたアイテム１１８０１ａに対応するインタラクティブプレビューパネル１１８０２を表示することができる。

インタラクティブプレビューパネル１１８０２は、例えば、アイテム１１８０１ａがＭＩＣＲＯＳＯＦＴＷＯＲＤ（商標）ファイルなどのテキストデータ、または他の文書処理プログラムを含むファイルである場合に選択されたアイテム１１８０１ａ内に現れるテキストの１つまたは複数のページを表示することができる。インタラクティブプレビュー１１８０２を使用すると、ユーザは、プレビューパネルで直接、表示されているテキストを編集および／または操作することができる。例えば、ユーザは、インタラクティブプレビュー１１８０２内でマウスポインタをクリックして、カーソルをパネル内に表示させることが許され、ユーザは、このカーソルを操作するか、またはキーボード入力を行って、表示されているテキストへの追加、削除、および／または他の何らかの方法による修正を加えることができる。ページングコントロール、フォント／書式コントロール、スクロールコントロール、ファイル管理コントロール、入出力コントロールなどの他のタイプのコントロールも、プレビューパネル１１８０２内に表示することができる。

異なるタイプのデータファイルは、異なるタイプのインタラクティブプレビューを持つことができる。例えば、オーディオファイル用のインタラクティブプレビューは、コンピュータシステムの１つまたは複数のスピーカー（スピーカー１９７など）で選択されたオーディオファイルのオーディオプレビューの再生を制御するコントロールを備えることが可能である。．ｗａｖファイルまたは．ｍｐ３ファイルのプレビューは、そのようなオーディオコマンドを含むことができる。オーディオファイルの再生、再生の一時停止、または頭出しを行うコントロールがありうる。画像のプレビューなどのいくつかのプレビューは、表示された画像の操作を行うことができる拡大縮小／パニングコントロールを含むことができる。ビデオプレビューは、コンピュータシステムのディスプレイ上のビデオおよびスピーカー上のオーディオの再生、再生の一時停止、または頭出しを行うコントロールを備えることができる。

インタラクティブプレビュー１１８０２は、さらに、ラベル１１８０３ａおよび対応する値１１８０３ｂを持つような図１１８に示されている、複数のプロパティ１１８０３（メタデータを含む）とともに表示することができる。ラベルとともに、任意のタイプのファイルプロパティを表示することができる。例示的なプロパティは、ファイルサイズ、フォルダの場所、ファイル名、プロジェクト名、編集者／作成日、アプリケーションタイプなどを含むことができる。表示される様々なラベルおよびプロパティ１１８０３は、選択されたファイルのタイプに応じてカスタマイズすることができ、それにより、異なる一連のプロパティが、選択されたファイルのタイプに何が適しているかに応じて、異なるタイプのファイルについて出現することができる。例えば、楽曲を含む選択されたオーディオファイルは、アルバム名、アーティスト、楽曲の名前、およびリリース日に対するプロパティを持つことができるが、選択されたスプレッドシートファイルは、それらのプロパティをグループ名、プロジェクト名、プロジェクトリーダー、およびプロジェクト開始日などの異なるプロパティで置き換えることが可能である。どのプロパティを表示すべきかの判定は、自動的に構成することができるか、またはそれとは別に、ユーザ側に、特定のファイルタイプについてプロパティ領域に出現するプロパティを選択（および／または選択解除）するオプションを与えることができる。プロパティは、タイプで優先順位付けされ（例えば、「ａｌｂｕｍｎａｍｅ」プロパティタイプは、画像ファイルよりも楽曲ファイルにとって重要である）、この表示を円滑に行えるようにすることができる。

表示される情報に関する他の変更形態も可能である。例えば、いくつかのラベル（ファイル名およびファイルタイプなど）は、オプションと考えることができるか、または表示からまとめて省くこともできる。図１１８の一実施例は、ファイル名およびファイルタイプとすることができ、これはすでに、画面上のどこかに表示されており、プレビューアによりプロパティ領域に再び表示されると、冗長であろう。このような非表示ラベルに対する利用可能な空間は、追加のプロパティ情報を表示するために使用することが可能である。値を持たないプロパティは、既定では省くことができるか、またはフラグを立てて、空であるにもかかわらず表示されることを示すことができる。他の変更形態として、いくつかのプロパティに、より長いプロパティを受け入れられるように異なる量の空間を用意することができる。

これらのプロパティは、プロパティ表示領域から編集可能である。例えば、ユーザは、単純に、表示されているプロパティ値をクリックするか、またはその上でホバリングし、データを入力／編集するプロセスを開始することができる。データを入力／編集するインターフェースは、関与する特定のプロパティまたはタイプに依存しうる。日付などのいくつかのプロパティは、値を選択できるカレンダー表示および／またはプルダウンメニューを備えることができる。例えば、ユーザは、単純に、日付フィールド上にマウスポインタを移動することができ、ユーザが日付を入力するのにカレンダーから選択すればよいようにカレンダーの表示が現れるようにすることができる。簡単に入力できるように候補のプルダウンメニューまたはリストを表示することができる。例えば、ｍｏｎｔｈフィールド上でマウスポインタをクリックすると、システムは、ユーザがそのフィールドに入力するために選択できる月の一覧を表示することができる。単純なテキストボックスが表示されるので、ユーザは、データ用に別のダイアログボックスを用意しなくても、カーソルを使用して、プレビュー表示からプロパティ値を直接入力し、および／または編集することができる。テキストボックスは、空所を埋める式のボックスでよく、ユーザは、カーソルおよびキーボードを使用して入力することができる。他の形態のデータ入力も使用できる。ユーザが編集可能なプロパティを識別するのを助けるために、それらのプロパティは、表示内で何らかの形で視覚的に区別するか、または強調できる。例えば、異なる色（例えば、黄色）、フォント（例えば、太字、またはＡＬＬＣＡＰＳフォント）、外観、および／または記号を使用して、ユーザにより編集可能な値およびユーザにより編集可能でない値を示すことができる。ハイライト表示も、いくつかのフィールドを区別または強調するために使用することができる。例えば、編集可能フィールドは、その中を、および／またはその周りを、特定の色（例えば、カナリア色）で表示することができ、黄色のハイライトマーカーが印刷文書で使用される場合に生み出される効果と似た効果を出す。

いくつかのファイルタイプは、与えられたプレビュー表示内に収まる以上のプロパティを持つ場合がある。いくつかの実施形態では、ユーザが与えられたファイルについてすべてのプロパティを、または少なくとも追加のビュープロパティを表示できるようにするＡＬＬボタン１１８０４などのオプションがありうる。

ステップ１１７０９において上で説明されているように、ユーザに、ブラウザ１１８００内で使用されるプレビューおよび／またはプロパティ表示をサイズ変更するオプションを与えることができる。例えば、サイズ変更ツール１１８０５は、プレビューパネル１１８０２内で使用することができ、このツールを選択して移動することにより、ユーザは、プレビューアおよび／またはプロパティ領域により占有されている表示領域をブラウザ１１８００に自動調整させることができる。

図１１９は、ユーザがインタラクティブプレビュー１１８０２のサイズを変更して、大きなサイズにし、その結果インタラクティブプレビュー１１９０１が大きくなっている例示的なユーザインターフェースを示す。新しいプレビュー１１９０１は、古いプレビュー１１８０２と同じアスペクト比を持つように構成することができるか、またはユーザがサイズ変更プロセスの一部としてアスペクト比を修正することを許すことができる。大きなプレビュー１１９０１では、ブラウザ１１８００は、プロパティの表示に割り当てられる空間も増大させ、プロパティおよびプレビューがサイズの面で一致するようにすることができる。例えば、プロパティ領域１１９０２は、サイズ変更されたプレビューと同じ高さを持つように構成することができ、また新しいサイズに合うように表示されるデータを自動的に再配列することができる。追加のプロパティは、この大きくなった領域に表示することができる。

上述のように、プレビューのサイズが変わると、いくつかの場合において、提供されるプレビューのタイプも変わり、プレビューパネルのサイズが異なることで、インタラクティブプレビューのタイプも異なることになる。したがって、プレビュー１１９０１は、対話性のレベルおよび／または提供される機能の種類に関してプレビュー１１８０２と異なる場合がある。一実施例として、いくつかのグラフィック編集機能は、プレビューの幅が２５６ピクセル未満だと、意味をなさないことがある。同じタイプのサイズ変更は、ユーザがプロパティを表示するために使用した領域のサイズを変更した場合に発生しうる。例えば、ユーザは、プロパティ領域１１９０２の境界上でマウスポインタをクリック＆ドラッグしてサイズを変更し、プレビュー領域１１９０１のサイズを変更させて、新しいプロパティ領域１１９０２のサイズと一致するようにすることが可能である。

図１２０は、プレビューのサイズを変更してさらに小さなプレビュー１２００１になるようにした一実施例を示している。小さなプレビューパネル１２００１では、サイズが小さくなった分、機能セットも縮小されている場合がある。プロパティ領域１２００２は、さらに、プレビューパネル１２００１に応じて縮小することもでき、利用可能な空間の縮小に合わせて表示されるプロパティまたはメタデータを再配列および／または削除することができる。いくつかのプレビューでは、ＭｉｃｒｏｓｏｆｔＷＩＮＤＯＷＳ（登録商標）（商標）オペレーティングシステムに見られるアイコン挙動を示すことができるため、右クリック、左クリック、ドラッグなどは、同じ効果を持つことができる。例えば、１つのアイコンを他方のアイコンにドラッグ＆ドロップすることで、第１のファイルを第２のファイルに貼り付けることができる。

プレビューパネルおよび／またはプロパティ表示領域のサイズ変更に加えて、これらの要素は、自動的に、またはユーザの要求により、再配列することができる。例えば、ユーザは、プレビュー１２１０１（図１２１）を異なる向きと外観が与えられるように（例えば、ユーザ設定を選択することにより、プレビューをクリック＆ドラッグすることにより、または他の何らかのユーザ入力により）移動することを望んでいる場合がある。異なる向きは、ある種のファイルをプレビューするときに好ましい場合がある。例えば、「横置き」形式で撮った写真またはビデオ画像のプレビューは、高さよりも幅が長い向き（例えば、「横置き」）に適している場合があり、他の種類のファイル（例えば、テキストドキュメント、または「縦置き」画像）は、幅よりも高さが長い向きに適している場合がある。これらの形式間の選択は、さらに、例えば、ファイルタイプに基づいて自動的に行うこともできる。例えば、システムは、ステップ１１７０６におけるプレビュー選択またはステップ１１７０３における関連付けの一部として、ファイルタイプ、プロパティ、および／またはメタデータを調べて、プレビューの向きがプレビューされる選択に対し最も適しているかどうかを判定することができる。

再配列、およびプレビューパネルに対する上述のクラッシュ／ハング耐性を促進するために、プレビューパネルおよびプロパティ／メタデータ領域は、別のソフトウェアモジュールとして実装することができる。それぞれのモジュールは、システムの（複数の）処理ユニット１２０上で異なるプロセスとして実行することができる。それとは別に、プレビューおよびプロパティ／メタデータパネルは、システム内の異なるソフトウェアまたはソフトウェアモジュールとして実装する必要はなく、その代わりに、共通モジュールとして実装することができる。統合レベルは、望ましい拡張性、ソフトウェアメモリ専有面積、およびその他の要因に基づく設計選択とすることができる。

前記のように、プレビューパネルは、コンピュータシステムの共通ファイルダイアログに組み込むことができる。共通ファイルダイアログは、システム上で実行される様々なアプリケーションにより共有されるためにコンピュータシステムにより提供されるユーザインターフェース要素および／またはプログラムとすることができる。例えば、オペレーティングシステムは、システム上でファイルを作成することを望んでいるアプリケーションにより使用することができる「ＯｐｅｎＦｉｌｅ」または「ＳａｖｅＦｉｌｅ」共通ダイアログを備えることが可能である。そのような共通ファイルダイアログ内にプレビューアを含めることで、複数の異なるタイプのアプリケーションは、プレビューを持つことを活かすことができ、またアプリケーションは、アプリケーション開発者が専用のプレビューアを開発しなくても本来的にサポートされていないファイルのリッチインタラクティブプレビューを効果的に提供することができる。また、共通ファイルダイアログにプレビューを組み込むことにより、複数のアプリケーションにわたって一貫したインターフェースが得られ、ユーザ設定および関連付けは、様々なアプリケーションにまたがって一貫して使用することができる。さらに、共通ファイルダイアログ内にプレビューアを用意することにより、アプリケーションは、多様なファイルタイプ−アプリケーションが本来サポートしていないファイルタイプであっても−のリッチインタラクティブプレビューを与えることができる。例えば、スプレッドシートアプリケーションは、データ集約的スプレッドシートのプレビューを扱うためにそれ専用のリッチインタラクティブプレビューアをインストールしてある場合がある。スプレッドシートアプリケーションのデータファイルを編集する機能を持ち合わせていない、別の文書処理アプリケーションは、しかしながら、共通ファイルダイアログを使用することによりそのようなプレビューを備えることができる。図１２２は、「ＯｐｅｎＦｉｌｅ」共通ダイアログの一部であるプレビューアの一実施例を示している。これらの共通ファイルダイアログは、そのプレビューとともに、いくつかのＡＰＩを通じて他のアプリケーションに拡張可能なように備えることができる。

いくつかの場合において、ユーザは、一度に複数のファイルを選択するか、または同時にアクティブに選択された複数のファイルを用意したいことがある。これらの場合、プレビューアは、上述のように動作し、それぞれの選択されたファイル用に別々のプレビューを与えることができる。それとは別に、システムはその挙動を変更することもできる。例えば、ステップ１１７０５において、複数のファイルが選択されたとシステムが判定した場合、プレビュー１１７０６を生成するステップは、選択されたどのファイルがプレビューされるか、そしてどれがプレビューされないかを判定するプロセスを伴うことができる。この判定は、上述の関連付けおよびユーザ設定などの、様々な基準（例えば、最初の選択、最後の選択、最も新しい選択、最大の選択、最も単純なプレビュー、ユーザプレビューア設定など）に基づいて行うことができる。

システムは、さらに、複数の選択に対応する同時プレビューを生成するステップを実行することもできる。図１２３に示されているように、複数のプレビューパネル１２３０１に対し、複数の選択がプレビューされていることを示すスタッキング表示を与えることができる。主プレビュー１２３０１ａは、一番上に表示され、他のプレビューとともに上述の同じリッチな対話性のすべてを持つことができる。他の選択に対する追加のプレビュー１２３０１ｂ、１２３０１ｃ、および２００ｄは、主プレビュー１２３０１ａの背後にスタッキング状態で表示することができ、水平オフセットＸおよび垂直オフセットＹを持つことができる。オフセットは、一様な外観を示すように一定とすることができる。それとは別に、それぞれの連続するプレビューに対するオフセットは、より多くのプレビューが背景に配置されるにつれ小さくなっていくようにできる。所定の最大数のスタッキングプレビューが可能であり、これを超えて、異なる外観を使用することができる。例えば、プレビューの所定の最大数が６に設定されている場合（システムまたはユーザにより設定することができる）、および６つよりも多いファイルが選択されている場合、スタッキングされたプレビューは、図１２４に示されているように、異なる外観を持つことができる。そこで、最初の６個を超えるプレビュー１２４０１ａ、１２４０１ｂ、および１２４０１ｃは、小さなオフセットでスタッキングされているように示される。これらの追加のプレビューは、所定のパターン、および／またはある程度の透明度または不透明度を持ち、プレビューされていないさらに多くの選択ファイルがあることをユーザに示す、単にブランクのプレビューとしてレンダリングすることができる。

複数のプレビューの代替え表示も使用することができる。例えば、図１２５に示されているようなプレビューの回転３Ｄカルーセルを使用することができる。６面カルーセル１２５０１は、異なる面１２５０２ａ、１２５０２ｂ、１２５０２ｃ（後ろから示されている）、１２５０２ｄ（後ろから示されている）、１２５０２ｅ（後ろから示されている）、および１２５０２ｆに６つの別々のプレビューを表示することができる。ユーザインターフェース要素１２５０３を用意し、回転または拡大縮小など、カルーセルを通した手動ナビゲーションを行うことができるか、またはカルーセルを自動的に回転させることができる（またはまったくできない）。他のアプローチは、扇形に広がった表示で複数のプレビューを表示すること、複数のプレビュー（必要ならばサイズ変更する）を並べて表示すること、スタックの３Ｄ等角図法で表示すること（用紙の束に似ている）、および自動もしくは手動ナビゲーションで順次表示することを含む。

複数の選択されたファイルのプレビュー（例えば、複数のファイル上でマウスカーソルをクリックし、ＳＨＩＦＴまたはＣＴＲＬキーを押したままクリックする、または複数のファイルの周りで選択領域をクリック＆ドラッグすることにより選択される）は、さらに、選択されたファイルのタイプにより異なることがあり、また選択されたファイルの異なる組合せに対して異なるプレビューシーケンスを使用することができる。例えば、システム（例えば、オペレーティングシステム、ハードウェア、アプリケーションなどを介して）では、複数の画像ファイルが選択されている場合にスタッキングされた表示を使用し、複数のビデオファイルが選択されている場合に順次ビデオプレビューを使用することができる。システムは、さらに、リソースを節約するために、複数のファイルが選択された場合に与えられるプレビューを縮小するか、または簡素化することもできる。

上記の様々な機能は、単一の統合されたコード断片として、またはサブルーチンもしくはモジュールのコレクションとして実装することができる。例えば、複数のファイルのプレビューを取り扱うためのイテレータモジュール、プレビューに用意されているユーザインターフェースコマンドに関わるコマンドモジュール、プレビュー自体を生成するためのプレビューモジュール、プレビュー表示のプロパティ／メタデータ部分を取り扱うためのプロパティモジュールなどがありうる。

上述のように、これらのプレビュー機能は、システム上のファイルまたは他のデータの一覧をユーザに対して表示するときにはいつでも備えることができる。表示がユーザ要求キーワード検索の結果である場合など、１つまたは複数の基準を使用して特定の一覧表示が生成される場合、プレビューアでは、この検索基準を使用してプレビューを組み立てることができる。例えば、アプリケーション側で、検索に使用されるキーワードをプレビューアに通知することが望まれており、プレビューアは、複数のプレビューが使用される場合にどのプレビューを使用するか、またはプレビューを順番にどのように並べるかを決定することができる。これは、拡張機能とすることができ、プレビューアは検索基準を備える。

上述のように、複数選択を実行することができ、表示されたプレビュー画像は、その結果、変化しうる。これらの複数選択は、さらに、プロパティおよび／またはメタデータの表示に変化を引き起こすこともある。例えば、図１２６は、２つのファイル１２６０１および１２６０２が選択されている例示的なビューを示している。選択されたファイルは、目立つ色、フォント、形状、テクスチャ、スタイル、サイズ、背景色、パターンなどを用意するなど、一意的な方法で、または一意的な外観を使って、区別および／または強調することができる。選択されたファイルに対するプロパティおよびメタデータでは、両方のファイル（それぞれについてプロジェクト名など）１２６０３、１２６０４について同じプロパティを表示することができ、ユーザがプロパティを対応するファイルと容易に照合できるような対応する外観を持つことができる。例えば、プロパティは、それらが属している選択されたファイルを識別するため色分けすることができる。ファイル１２６０１について示されているパターンは、色（例えば、赤色）、ハイライト表示（例えば、書類にハイライトマーカーを付けた場合のようにテキストを囲む異なる色）、フォント（例えば、太字、下線、ＡＬＬＣＡＰＳ、ＴｉｍｅｓＮｅｗＲｏｍａｎなど）、サイズ（例えば、大きなテキスト）などにより、ファイルを強調および／または区別することができる。ファイル１２６０１のプロパティを表示することができる、プロパティ１２６０３は、プロパティおよびそれぞれのファイルを相関させるため、そのファイルに使用されるのと同じ強調および／または区別を設定することができる。

複数の選択されたファイルに対する多くのプロパティおよび／またはメタデータを集約し、編集または合計として一緒に表示することができる。例えば、一方の表示されるプロパティがファイルサイズ（例えば、何キロバイト（ｋｂ）または何メガバイト（Ｍｂ）使用されるか）であり、複数のファイルが選択されている場合、ファイルサイズプロパティでは、選択されたファイルのファイルサイズを合計した、集約されたファイルサイズ値（例えば、４．３Ｍｂ）を表示することができる。他の実施例として、１つの表示されるプロパティがキーワードを持つ場合、複数の選択されたファイルに対するキーワードを集約してまとめ、単一キーワードプロパティとして表示することができる。いくつかの集約の結果、より大きなプロパティ表示が得られ、上述の同じ外観強調／区別を使用して、集約されたプロパティと対応するファイルとの相関を与えることができる。それとは別に、プロパティは、選択されたファイルからさらに区別することができ（例えば、異なる色、フォント、ハイライト表示、外観、サイズなど）、それにより、そのプロパティが選択されたすべてのファイルの集約であることを示すことができる。図１２７は、集約されたプロパティ値１２７０１が、個別に選択されたファイル１２６０１、１２６０２上のパターンと異なる陰影により表されている異なる外観とともに表示される一実施例を示している。この陰影は、例えば、赤色を表すことができるが、ファイル１２６０１および１２６０２上のパターンは、緑色と黄色にすることができる。

集約された値の強調および／または区別は、場合によっては、値の出所を示すような方法で行うことができる。例えば、図１２８は、図１２７に示されているビューの拡大されたプロパティ／メタデータ表示を示している。キーワードなどの、いくつかの集約されたプロパティにより、結果として、複数選択から集約された複数のプロパティ値の一覧表示１２８０１が得られる。これらの集約されたプロパティに、どの値が選択されたどのファイルからのものであったかを示す目立つ外観を与えることができる。図１２８の実施例では、値１２８０２および１２８０３は、陰影の一形態で示されており、これにより、それらの特定の値（例えば、キーワード）が両方の選択されたファイル１２６０１および１２６０２に共通であることを示す。その陰影は、上述のタイプのどれかの区別および／または強調（例えば、赤色）を反映することができる。値１２８０４および１２８０５は、これは、同じパターン（例えば、ファイルおよびその値は両方とも青色）を共有する、選択された１つのファイル１２６０１に関連付けられていることを示す第１のパターンとともに示され、値１２８０６は、同じパターンを共有する、他方の選択されたファイル１２６０２に関連付けられていることを示す異なるパターンを持つ（例えば、このファイルおよびその値は緑色）。離線１２８０７は、選択されたすべてのファイルに共通であった値をそうでなかった値と区別するために使用することができる。もちろん、異なる外観に、さらに多くのファイルが選択された場合の異なる意味を与えることができる。ラベル１２８０８も、それが集約されたプロパティであることを示すため視覚的に区別されるおよび／または強調されることができる。例えば、ラベル１２８０８も、赤色にすることができる。

強調および／または区別は、さらに、集約された値のうちのいくつかの値のユーザ選択から始めることができる。例えば、ユーザは、集約された一覧内の値の１つを選択し、どのファイルが選択された値を共有するかを示すその後の表示を見せることができる。この指示は、共通の外観の形態で現れることが可能であり、選択された値およびその対応するファイルは、共通の方法で表示される。例えば、値１２８０６をクリックすると、システムは、そのプロパティ値のフォントを太字フォントに自動的に変更し、ファイル一覧１２６０２にも同じことを行い、プロパティが選択されたファイルを識別することができる。

上述の説明では、シェルブラウザ内のプレビューで表示されるプロパティおよびメタデータを取り上げているが、これらの機能は、他の状況でも使用することができる。複数のプロパティおよび／またはメタデータの表示を伴う状況であれば、本明細書で説明されている機能を利用することができる。

ある種のプロパティは、数値を含むので集約が容易であるが（例えば、ファイルサイズは、単に、個々のサイズの合計である）、他のタイプのプロパティは、集約が難しい場合がある。例えば、いくつかのプロパティでは、テキストワードを値として持つ（例えば、キーワード）。さらに、いくつかの個々のプロパティおよび／またはメタデータは、それ自体複数の値を取ることができ、多値プロパティと呼ばれる。例えば、与えられたファイルの「ｋｅｙｗｏｒｄｓ」プロパティは、異なるキーワードを値として０個、１個、２個、３個、または任意の個数持つことができる（例えば、１つのファイルは、「ｐｅａｎｕｔ」、「ｆｏｏｄ」、および「ｃａｎｄｙ」をそのファイルに関係するキーワードとして一覧表示することができる）。これらの複数の値は、それぞれのファイルについて意味のある方法で一覧に現れる第１の値がほかより重要であるように順序付けることができる（例えば、主にピーナツを取り扱い、最も重要であるため「ｐｅａｎｕｔ」を第１のキーワードとして一覧表示することができ、「ｆｏｏｄ」および「ｃａｎｄｙ」を重要度の下がる順序で第２および第３として一覧表示することができること）。それぞれ複数のキーワードを持つ、複数のファイルが選択された場合、それらのプロパティを集約するプロセスは、ただ数値を加えることほど単純ではない。その場合、システムは、個々の選択されたファイルについて出現した順序に基づく何らかの形態の順位に並ぶ値の一覧を表示することができる。集約された値の結果として得られる一覧が様々な選択されたファイルについて出現するときの値の相対的重要度に確実に対応するようにするステップを実行することができる。例えば、５つの新聞記事には、それらの記事中で説明され、以下の順序で順位付けられている市を識別するキーワードを持つことができる。
Ｆｉｌｅ１：Ａｕｓｔｉｎ、Ｃｈｉｃａｇｏ、Ｂｏｓｔｏｎ、Ｄｅｔｒｏｉｔ
Ｆｉｌｅ２：Ｃｈｉｃａｇｏ、Ｄｅｔｒｏｉｔ、Ｂｏｓｔｏｎ
Ｆｉｌｅ３：Ｃｈｉｃａｇｏ、Ｂｏｓｔｏｎ
Ｆｉｌｅ４：Ｄｅｔｒｏｉｔ、Ｃｈｉｃａｇｏ
Ｆｉｌｅ５：Ｂｏｓｔｏｎ、Ａｕｓｔｉｎ

この実施例では、Ｃｈｉｃａｇｏは、「ｆｉｒｓｔｐｌａｃｅ」を２回（例えば、Ｆｉｌｅｓ２および３では、Ｃｈｉｃａｇｏを多く説明している）、「ｓｅｃｏｎｄｐｌａｃｅ」を２回（例えば、Ｆｉｌｅｓ１および４では、Ｃｈｉｃａｇｏに集中していないが、言及している）与えられた。これらのプロパティの結果として得られる集約では、冗長性を排し、ファイルの「Ｃｈｉｃａｇｏ」の相対的重要度（および他の値）を表す順序でプロパティを表示することができ、また特定の値がとにかくファイルのプロパティ「Ｃｈｉｃａｇｏ、Ｂｏｓｔｏｎ、Ｄｅｔｒｏｉｔ、Ａｕｓｔｉｎ」中に出現した回数を考慮する。したがって、この実施例では、複数の選択されたファイルは、全体として、ほとんどＣｈｉｃａｇｏを取り扱い、次いでＢｏｓｔｏｎを、次いでＤｅｔｒｏｉｔを、最後にＡｕｓｔｉｎを取り扱う。

図１２９Ａ〜Ｂは、多値プロパティに対する集約された値を表示することができ、そのような集約された表示が必要な場合にはいつでも、および／または多値プロパティが変更された場合にはいつでも実行できる順序を決定するための例示的なプロセスを示している。このプロセスは、単記移譲式投票アルゴリズムの修正形態である。このプロセスでは、特定の値がファイルのプロパティ内に最初にリストされたときに、それは、１位に対する「投票」と考えられる。値が２番目にリストされた場合、それは、２位の投票であり、というように続く。このプロセスは、それぞれの特定の値が選択されたファイル内に出現する回数および選択されたファイルのそれぞれにより値に付けられた相対的重要度の両方に基づく非冗長順位付けを出力する。

ステップ１２９０１で、大域整数定数Ｃは、自動的に（例えば、コンピュータシステムがシステムリソースの可用性を検出し、システムが完全停止を回避するように定数を調整することができる）、または手動で（例えば、ユーザに、多値プロパティの集約でどれだけの詳細さを望んでいるかに応じて、Ｃを好きなだけ高くまたは低く設定できるオプションを与えることができる）設定される。この定数は、プロセスが実行される序列または順位を表し、例えば、Ｃは１０にすることができる。定数Ｃを高くすると、順位の粒度は大きくなるが、より大きな処理能力と長い時間を要する。この値は、ユーザ設定、システム設定、利用可能なリソース、システム負荷などに応じて、動的に設定することができる。

ステップ１２９０２では、選択されたファイル間に存在するそれぞれの値についてループが開始する。ステップ１２９０３では、投票の最初のＣ個の位について入れ子のループが実行される。ステップ１２９０４で、それぞれの位について、システムは、現在値がその位について受け取った票数を集計する。これら２つのループの結果、システムは、値毎に、最初のＣ個の「位」のそれぞれについて何「票」受け取ったかを決定する。次いで、ステップ１２９０５では、首位（１位）から始まりＣ位まで続く、Ｃ個の位のそれぞれを処理するもう１つのループが開始される。

ステップ１２９０６で、単一値が考察対象の位について最多票を受け取ったかどうかを判定するチェックが実行される。ある値が、この位について最多票を受け取った場合、その値はこの位を与えられ、ステップ１２９０７で、その値は、投票一覧表作成プロセスにおける計算の残り部分から取り除かれる。したがって、上の実施例では、Ｃｈｉｃａｇｏは、１位について最多票を受けた（２票）。

ステップ１２９０６で、この位に対する最多票を得た単一値がなかった場合、現在の位について同順位があり（２つまたはそれ以上の値が、この位について同じ票数を得ていたか、またはすべての値が、この位についてゼロ票であったかのいずれか）、プロセスは、ステップ１２９０８に移り、そこで、チェックされている現在の位が、チェックすべき最後の位であるかどうかを判定するチェックが行われる（Ｃ位）。最後の位でなければ、プロセスは、ステップ１２９０９に進む。ステップ１２９０９で、システムは、位１つ先を「ちらっと見て」、現在同順位である値が次位について受け取った票数を識別する。ステップ１２９１０において、同順位の値の１つが、次位について最多票を得た場合、ステップ１２９１１で、その値に現在の位が与えられ、他の同順位の値により保持されている現在の位に対する票は、次の位に、移動、つまり移譲される。つまり、ステップ１２９１１における「敗者」では、現在の位に対する票が次位に対する投票合計に加えられ、そのため、考察対象の位において票を受け取ったが、その位に与えられなかったすべての値について、現在のラウンドにおける票は、そのラウンドの勝利者を計算するときに、次のラウンドに繰り越され、その票に加えられる。

ステップ１２９１０において、同順位の値はどれも、次位について最多票を受けなかった場合、同順位の値はすべて、ステップ１２９１３において現在の位についてアルファベット順に順位付けられ（同順位の値すべてに位が与えられるまで次の数個の位）、プロセスは、ステップ１２９０５に戻る。同様に、ステップ１２９０８において、プロセスがたまたま、同順位が生じたときに最後の位（Ｃ位）を調べていた場合、プロセスは、ステップ１２９１３に移動し、同順位の値をアルファベット順に順位付けし、ステップ１２９０５に進む。

ステップ１２９０５から、最後の位（Ｃ位）が処理された場合、プロセスは、ステップ１２９１４に移動し、残りの順位付けされていない値に対するすべての残りの票は、Ｃ位の票として処理され、残りの値は、Ｃ位について最多票を持つかどうかの順序で順位付けられ、同順位はアルファベット順を使用して分けられる。

図１２９Ａ〜Ｂに示されているアルゴリズムは、様々票数および値を表形式にした要約テーブルをメモリに保持することができる。このテーブルは、プロセスの実行とともにシステムが稼働中のＲＡＭにテーブルを徐々にロードすることができること、もはや必要なくなった部分をＲＡＭから削除すること、それにより、プロセスを実行するのに必要なランタイムメモリの量を減らすことの面で有利である。

いくつかの場合において、様々なマルチプロパティ値は、正規化プロセスを受けることができる。正規化プロセスでは、ファイルのマルチプロパティフィールド内の値の冗長な出現を削除することができる。例えば、ファイルは、キーワード（Ｄｏｇ、Ｃａｔ、Ｄｏｇ）を持つことができ、正規化プロセスは、これらの値の第１の出現を保持し、同じ値の後続の出現を削除することができる（例えば、その結果、「Ｄｏｇ，Ｃａｔ」となる）。正規化されていないデータは、システムのメモリ内に格納することができ、正規化されたバージョンは、そのデータを上書きするか、または正規化データが、単に、メモリ内に別々に格納されるだけである。いくつかの場合において、正規化は、ユーザが多値プロパティを修正する場合に実行することができる。

いくつかの場合において、ユーザが、集約された表示の対話操作を通じて多値プロパティを編集することを望んでいることがある。その場合、システムは、集約された多値プロパティ表示に加えられた変更に対する応答としてそれぞれのファイルについて多値プロパティを改訂することができる。例えば、集約された表示の末尾に新しいプロパティを追加するだけで、新しいプロパティをファイルのそれぞれについて多値プロパティに付加することができる。新しいプロパティが、集約された多値プロパティ表示の先頭に挿入されるか、または他の挿入で、同じことが発生しうる。集約されたプロパティ表示内のプロパティの順序変更などの、いくつかの変更により、ファイルのそれぞれについて多値プロパティの対応する順序変更が引き起こされる。

多値プロパティは、データを編集する独自のアプローチを用意することができる。例えば、このようなプロパティに対するフィールドは、図１３０に示されているのと同様に、一覧内に表示できる。フィールド１３００１は、ユーザがデータを入力するためキー入力することができるアクティブなテキストエディットボックスとし、多数の値１３００２をそのフィールドに、セミコロンなどの文字で区切って入れることができる。値１３００２はアトミック挙動、またはトークン挙動を示し、値全体を単一の選択として選択できる。したがって、いくつかの場合に、データを編集するため挿入点がフィールド１３００１内に置かれた場合、アトミック値１３００２は、複数の文字ではなく、単一のユニットとして振る舞い（例えば、「Ｎ」「Ｙ」「Ｃ」ではなく、「ＮＹＣ」）、挿入点をアトミック値内に置くことは、禁じられ、挿入点をアトミック値内に置こうとすると（例えば、その中でマウスをクリックすることにより）、挿入点はアトミック値の前または後に入れられる。矢印キーを押してアトミック値の周りをナビゲートすることでも、値の一方の側から他方の側に１回キー押下で移動できる。さらに、選択領域が可能な場合、このような領域ではアトミック値の一部のみを選択することが禁じられ、値の所定の部分（例えば、半分）を選択しても、値全体が選択される。アトミック値の上をホバリングすると、値はホバリング状態に入り、アトミック値であることを示すことができる。例えば、ホバリング状態は、アトミック値全体の周りのボックスまたはハイライト表示、または他の視覚的区別もしくは強調を含むことができる。アトミック値では、ドラッグ＆ドロップ操作により値を再配列することもできる。

トークン挙動は、単語全体を一度に単に選択することに限られない。単語は、代替えユーザインターフェース要素により置き換えられる。例えば、時刻は、時計のグラフィック画像により置き換えることが可能であり、日付は、カレンダーの画像により置き換えることが可能である。アトミック値は、アイコン挙動を示すことができ、その上でクリック（または右クリック）すると、コマンドメニュー、オプション一覧、他のポップアップが現れるなどの対話機能の追加レベルがもたらされる。また、値を他のファイルおよび／またはプロパティ上にドラッグすることができ、それらの値を他のファイルおよび／またはプロパティに追加することができる。

フィールドの一覧の末尾に、そのフィールドがどのようなデータを含んでいるかをユーザに思い出させるプロンプト文字列１３００３を置くことができる。いくつかの場合に、プロンプト文字列１３００３は、データの入力用にキーボードフォーカスが与えられている場合など、フィールド１３００１が編集状態にある場合のみ表示され、プロンプト文字列１３００３は、多値フィールド内の実際の値として扱われない（例えば、これは、フィールド内の値としてメモリに保存されず、むしろ、ユーザインターフェースの一部として生成される）。

プロンプト文字列１３００３は、すでに説明されているタイプのものを使用して視覚的に区別および／または強調されている場合があり（例えば、文字の周りの領域を特定の色でハイライト表示することができる）、ある種の既定の挙動を示すことができる。例えば、プロンプト文字列１３００３は、フィールド１３００１が編集状態にあり、挿入点が値の文字列の末尾にある場合にはいつも自動的に表示するようにできる。ユーザが新しい値をこの挿入点のところに挿入するために入力を開始し（例えば、テキストボックス内へのキー入力を開始することにより）、新しい文字が追加されると、プロンプト文字列１３００３を自動的に消すことができる。プロンプト文字列は、ユーザが新しい値の入力を完了するか、または中止した場合に自動的に再表示させることができる。

編集状態では、フィールドには、さらに、ドロップダウンメニュー１３００４が表示され、多値フィールド１３００１に追加することができる値のリストがユーザに表示され、ユーザは、そのメニューから入力を選択することができる。ドロップダウンメニュー１３００４は、図１３１に示されているプロセスに従って実装することができる、オートサジェスト機能を備えることができる。最初に、プロセスは、所定のプロパティについてすでに使用されている、および／または所定のユーザにより使用されるすべての値を集めることによりステップ１３１０１から開始することができる。ステップ１３１０２では、メニュー１３００４は、選択された（複数の）ファイルについて多値プロパティ内にすでに存在している値を省略することができるが、それは、ユーザが複製を加えることを望むことはまれであるからである。ステップ１３１０３において、一覧を人気度、アルファベット順、または他の所望の方法により並べ替えることができる。次いで、ステップ１３１０４で、メニューをオートサジェストとともに表示することができる。一覧にある値の一部が選択されたファイルのすべてではないとしても一部についてはすでに存在している場合、それらの値に異なる外観を与え（例えば、上述のようにハイライト表示、着色、パターン、フォントなど）、その事実を示すことができる。選択されたファイルのどれでも使用されていない値も、異なる外観を与えられ、その事実を示すようにすることができる。

フィールドは、さらに、図１３２に示されているように、オートコンプリート機能を持つことができる。オートコンプリート機能を使用すると、ユーザが多値プロパティに加える新しい値を入力し始めると（図１３２の例で、「Ｄ」と入力するなど）、システムは、予想される値で入力を完成させることを自動的に試みることができる。オートコンプリート機能は、図１３３に示されているプロセスを使用して実装することができる。予想される値は、ステップ１３３０１で与えられたプロパティについて使用されている値すべてを取り、ステップ１３３０２で選択された（複数の）ファイルにすでに適用されている値を除去することにより選択することができる。さらに、ステップ１３３０３でフィルタ処理を実行して、ユーザがすでに入力している文字から始まる値を識別し、ユーザがすでに入力した（複数の）文字で始まる第１の（アルファベット順で）値を選択することができる。ステップ１３３０４において、残りの可能な値を人気度、アルファベット順、または他の所望の方法により並べ替えることができ、ステップ１３３０４で、残りの一覧を表示することができる。一覧内の第１のエントリは、既定により選択され、ハイライト表示され、残りの文字は、ユーザの入力したデータに続いてフィールド内に自動的入り、必要ならばハイライト表示を加えることができる。

上述のオートサジェストおよびオートコンプリート機能は、他の種類のフィルタ処理ステップも含むことができる。例えば、フィルタにより、ユーザにより選択された、および／または入力された一番最近の値を選択するか、またはプロパティの一覧を作成した状況に基づいて可能な値をフィルタ処理することができる。例えば、選択されたファイルが、プロジェクトビューの一部として表示するように選択された場合（例えば、与えられたプロジェクトに関係するファイルを表示する）、システムは、特定の可能な値がそのプロジェクト内で使用される可能性が高い（または低い）と自動的に判定し、一覧をそれに応じてフィルタ処理することができる。

ユーザがフィールド内にデータを入力する場合、入力の妥当性を検証するチェックを行うことができる。例えば、いくつかのフィールドは、可能な値の指定された範囲またはリスト（例えば、曜日）のみを持つように事前に決定することができ、ユーザがマルチプロパティフィールド内に無効なエントリを入力しようとすると、システムは、その入力を単に拒絶し、そのエントリが無効であったことを示すメッセージをユーザに送ることができる。

本発明の他の実施形態および実装は、関係する当業者にとっては、図面を含む、明細書を読んだ後であれば明白なことであろう。例えば、説明されているプロセスの様々なステップは、本明細書で説明されている機能の選択された部分集合を実装するのに必要に応じて再配列、修正、および／または削除することができる。それに加えて、上記において、「本発明」の１つまたは複数の「態様」または「実施形態」に見られるいくつかの機能への参照は、単に、単独でまたは他の概念と組み合わせて都合よく使用できる様々な概念を例示するために行われており、本明細書には１つの発明概念しかないこと、または説明されている機能すべてが請求項のいずれかで要求されていることを暗示していると解釈すべきではない。むしろ、請求項のそれぞれは、個々の異なる発明として存在し、参照されている以上の制限を有するものと解釈すべきではない。

^**動的スクロール：本発明の様々な態様を使用して、従来のフォルダツリーコントロール（例えば、ナビゲーションペイン、ナビゲーションパネル、ページ空間コントロールなど）によるナビゲーションまたは他のデータのナビゲーションの機能を高めることができる。図１３６の従来のフォルダツリーコントロール１３６００を使用することで、ユーザは、データの表示、編成、および取り出しを行うことができる。典型的には、縦スクロールバー１３６０２および横スクロールバー１３６０４は、ユーザがフォルダツリー構造をナビゲートできるようにする１つのメカニズムとしてフォルダツリーコントロールを伴う。ユーザがフォルダツリー構造の階層内を垂直にナビゲートしていくと、関連するノードが、狭い表示可能ウィンドウペイン内にもはや完全には表示されなくなる場合がある。例えば、図１３６において、図１３６で「Ｉｎｓｔａｌｌｅｒ」というラベルが付いているノード１３６０６に最初にフォーカスが置かれたときにユーザが「下矢印」キーを繰り返し押したことに対する応答として、「Ｉｎｓｔａｌｌｅｒ」ノードの下の非表示の、または隠されているノード１３６０８は、それぞれ、順に、ハイライト表示され、フォーカスが当たる。しかし、これらのノードは、狭いウィンドウペイン内で完全に見えるというわけではない。ユーザは、その後、狭い表示可能ウィンドウペインを右に横スクロールして、ノード１３６０８を完全に見えるようにしなければならない。

図１３７では、本発明の様々な態様によるフォルダツリーが表示されている。当業者であれば、図１３７は、本発明の様々な態様によるフォルダツリーの単なる一実施例にすぎないことを理解するであろう。本発明のいくつかの態様は、様々なツリーコントロールまたは他のデータナビゲーションにより実装することができる。一実施例では、フォルダツリーは、ユーザによりナビゲートされる階層レベル内のツリーの枝を公開するユーザインターフェースコントロールの階層的ツリー形状の集合体であってよい。フォルダツリーコントロールのユーザが、ツリーコントロールにより公開されているノードをクリックすると、ノードは適所で展開され、すでに展開されていればノードは折り畳まれる。「＋」または「−」を表示するウィジェットなどの小さなウィジェットは、当技術分野で知られているように、ノードが折り畳まれているか、展開されているかを示すために使用することができる。ノードの展開は、現在選択されているノードの下に、入れ子になったノードが階層的に存在することを示している。ユーザは、例えば、ボタンをクリックする、ノードをクリックする、または表示されているウィジェットをクリックするなどにより、ノードを展開／折り畳むことができる。

フォルダツリーコントロールを使用することにより、ユーザは、当技術分野で知られているように、階層的に配列されたデータ間をナビゲートすることができる。図１３７では、縦スクロールバー１３７０２は、ユーザがフォルダツリー構造をナビゲートできるようにする１つのメカニズムとしてフォルダツリーコントロールを伴う。例えば、図１３７において、ユーザが浮動状態の縦スクロールバーコントロール１３７０８をウィンドウペインの底の方にドラッグすることに対する応答として、フォルダツリーコントロールは、見えている内容を上にスクロールし、それにより、すでに表示されていないノードをウィンドウ１３７００の下から表示させる。

本発明の例示的な態様によれば、ユーザが１つの次元（例えば、垂直方向）にそってナビゲートする場合、フォルダツリーコントロールは、他方の次元（例えば、水平方向）に自動的にスクロールし、ユーザに関係するノードが、ウィンドウ１３７００の見えている領域内に必ず入るようにすることができる。関連するノードは、現在のノード、入力フォーカスが置かれているノード、または他の何らかの方法で選択されたノードとすることができる。関連するノードは、例えば、マウスポインタの位置に水平方向にそって配置されるツリー構造内のノードであってよい。ユーザが、フォルダツリーコントロールの任意のノードをスクロール、展開、または折り畳み、それにより、関連するノードがもはや完全におよび／または部分的に表示されなくなった場合、フォルダツリーコントロールは、関連するノードがウィンドウ１３７００内に見えるようにフォルダツリーを自動的に横スクロールすることができる。

当業者であれば、本発明の例示的な実施形態では自動横スクロールを実行するが、他の実施形態では、例えば、ユーザが垂直方向よりも水平方向に適している他のタイプのデータをナビゲートしている場合に、ユーザによる横スクロールに対する応答として動的に縦スクロールすることができることを理解するであろう。例えば、本発明の様々な態様は、ナビゲーションを示すユーザ入力の実質的な割合が横方向にあるシステムにおいて実装することができる。その場合、当業者であれば、自動動的縦スクロールがあるように本発明の様々な態様を実装することができる。

例えば、図１３７の場合、マウスポインタがそのときに関連していたノード１３７０４のすぐ右の場所１３７０５にある場合、表示されるツリーは、ノード１３７０４のフォルダ名が完全に表示されているため横スクロールする必要はない。しかし、ユーザが、マウスポインタ１３７０５がノード１３７０６にそって横方向に配置されるようにマウスポインタ１３７０５を使用して浮動状態の縦スクロールバーコントロール１３７０８をドラッグした場合、表示されるツリービューを、以下でさらに詳しく説明するように、自動的に横スクロールさせることができる。この実施例では、マウスポインタ１３７０５は、横方向でノード１３７０６に近い位置にある。さらに、この実施例では、表示されるツリービューは、右に横スクロールし、その結果、ツリーは所定の距離だけ左に移動し、フォルダ名が完全に見えるようになるか、または所定の表示可能領域１３７００の幅が与えられた場合にできる限り完全に見えるようになる。フォルダ名が何らかの理由により切り詰められた場合、動的横スクロールで切り詰められたフォルダ名全体が完全に表示されるような所定の距離にすることができる。

当業者であれば、本明細書で開示されている教示を与えられた後、ナビゲーションコントロール（例えば、フォルダツリーコントロール）を自動スクロールする所定の距離は、本発明のいくつかの実施形態により異なることがあることを理解するであろう。一実施例では、自動スクロールする所定の距離は、関連するノード１３７０６を所定の表示可能領域１３７００の右辺に揃える必要のある距離に等しい。第２の実施例では、関連するノードは、所定の表示可能領域１３７００よりも広く、自動スクロールする所定の距離は、関連するノード１３７０６を所定の表示可能領域１３７００の左辺に揃える必要のある距離に等しくできる。第３の実施例では、自動スクロールする所定の距離は、関連するノード１３７０６を所定の表示可能領域１３７００の中心に揃える必要のある距離に等しくできる。これらの実施例は、所定の表示可能領域１３７００内の関連するノード１３７０６を近似的に揃えるために使用される適切な所定の距離を例示しているにすぎず、請求項の範囲を限定するものと狭く解釈すべきではない。

本発明の様々な態様によれば、説明されている動的横スクロールは、適切な期間だけ遅らせることができる。例えば、横スクロールは、即座に生じるように設定するか、またはユーザが最初に関連するノードにそってマウスポインタを配置してから１００ｍｓ後に生じるように設定することができる。時間遅延を実装する少なくとも１つの利点は、滑らかに移動している外観を生成またはもたらすことである。当業者であれば、設定された時間遅延の量は、適宜変えられることを理解するであろう。

図１３８Ａおよび１３８Ｂは、本発明の様々な態様により格納されているデータを表示し、編成するための例示的なユーザインターフェースのスクリーンショットを示している。当業者であれば、類似のナビゲーションコントロールインターフェースをドキュメント、メッセージ、ビデオファイル、および連絡先で使用することができ、それぞれの場合のナビゲーションコントロールインターフェースは、表示されるデータアイテムの種類に合わせて特に適合される。このような内容指向のインターフェースは、ユーザインターフェースの一コンポーネント、つまりシェルとしてオペレーティングシステム製品に付属させることができる。

図１３８Ａでは、ノード１３８０２は、現在、ユーザ入力に応答するフォーカスを持っている。一例にすぎないが、このようなユーザ入力は、ユーザがマウスポインタをノード１３８０２の近くまたはその上に移動することを含むことができる。関連するノード（ノード１３８０２）上にフォーカスが当てられると、ツリーコントロールは、横スクロールが適切かどうかを判定する。この場合、フォルダ名（つまり、記述子）が完全に表示されている。したがって、自動横スクロールは実行されない。しかし、ユーザがマウスポインタをノード１３８０４の近くまたはその上に移動すると、ノード１３８０４にフォーカスが置かれる。図１３８Ｂは、本発明の様々な態様によるそのようなフォルダツリーコントロールだけを示している。そのときに関連していたノード１３８０８は、現在は、図１３８Ｂにおいてフォーカスを持つ。ノード１３８０８は、ノード１３８０４と同じデータアイテムであるが、ノード１３８０８は、図１３８Ｂではフォーカスが当てられており、ノード１３８０４は、図１３８Ａではフォーカスが当てられていない。さらに、図１３８Ｂでは、フォルダツリーは、所定の距離だけ右に自動的に、動的に横スクロールし、ノード１３８０８の名前全体が表示されている。この場合、ノード名は、「ＦｏｌｄｅｒＮａｍｅ」であり、切り詰められない。フォルダツリーコントロールが横スクロールされる所定の距離は、ノード名の末尾を内部ウィンドウペインの辺にまたはその近くに近似的に揃える必要がある距離の量を計算することにより決定することができる。それまでの間、すでにフォーカスが当たっているノード１３８０６は、もはやハイライト表示されず、完全表示されない場合がある。

ナビゲーションコントロールのビューは、スクロール（例えば、横スクロール）が望ましいと判定された後、適切な距離だけ動的に横スクロールされる。当業者であれば、本発明の少なくとも１つの利点は、横スクロールバーを表示する必要がなく、それにより、フォルダツリーのデータを表示するために限られた表示画面上に追加の表示可能領域を設けられるという点であることを理解するであろう。横スクロールバーは必要ないが、本発明では、横スクロールバーを含める、および／または使用することを禁じない。例えば、横スクロールバーは、フォルダツリーに関して表示されるビューの現在の水平位置を視覚的に示すためにユーザにとって都合のよいものであると考えられる。

本発明の様々な態様によれば、図１３９は、一方の次元方向で内容を自動的に、動的にスクロールすることを、他の次元方向で内容のユーザ制御されたスクロールまたはナビゲーションに対する応答として行うコンピュータ実装方法を説明する流れ図を示している。当業者であれば、図１３９に例示されているステップは、参照されている順序以外の順序で実行することができ、図１３９に例示されている１つまたは複数のステップは、任意選択とすることができることを理解するであろう。

ステップ１３９０２で、ユーザに対し、内容の初期ビューが表示される。内容は、複数レベルのノードを持つ階層フォルダツリーコントロールの形態で表示することができる。図１３８Ａは、階層フォルダツリーの第１のビューの一実施例にすぎない。図１３６は、階層フォルダツリーの第１のビューのもう１つの実施例である。

ステップ１３９０６で、ユーザは、第１の次元方向に内容をスクロールし、および／または内容を対話操作する。これらの動作は、内容のナビゲーションを示すユーザ入力のいくつかの実施例に過ぎない。様々なユーザ入力では、その位置を所定の表示可能領域に移動することにより関連する内容をスクロールする。例えば、内容の縦スクロールを生じるユーザナビゲーションの一形態は、ユーザがフォルダツリーコントロールを含むウィンドウペイン１３６００の上または下に向かって浮動状態の縦スクロールバーコントロール１３６０６をドラッグする場合のものである。しばらくの間、様々な非スクロールユーザ入力では、どの内容がユーザに関連しているかの指定を更新することにより関連する内容を対話操作する。一実施例は、フォルダツリーコントロールウィンドウがアクティブ状態にある間に、ユーザが入力デバイス１１５上の「ｕｐａｒｒｏｗ」、「ｄｏｗｎａｒｒｏｗ」、「ｐａｇｅｕｐ」、または「ｐａｇｅｄｏｗｎ」ボタンを押す場合である。さらに、非スクロールユーザ入力の一実施例は、図１３８Ａに示すことができる。図１３８Ａに例示されている内容のビューを表示されたユーザが、マウスポインタをノード１３８０８の上またはその近くに移動した場合、ノード１３８０８はフォーカスを受ける。この実施例では、ユーザは、第１の次元方向に内容をスクロールする代わりに、内容を対話操作する。他の実施例では、ユーザは、内容を対話操作することと、第１の次元方向に内容をスクロールすることとを同時に行うことができる。さらに他の実施例では、図１３６に関して、ユーザは、展開ウィジェットを押すことによりフォルダツリーを対話操作することができ、その結果、ウィジェットが対応するノード１３６１０のサブノード１３６０８はフォルダツリーコントロールの表示可能領域内に部分的にのみ表示される。

ステップ１３９０８で、関連する内容が完全に表示される場合、自動スクロールは必要ない。関連する内容が所定の表示可能領域内に完全には表示されない（または、少なくとも部分的に隠されている）場合、関連する内容を第２の次元方向にスクロールして、関連する内容が可視性を高めている状態にすることができる。単なる一実施例に過ぎないが、図１３８Ａの関連する内容はノード１３８０２であり、例示ではフォーカスが当たっている。ユーザがマウスポインタをノード１３８０４の上または近くに移動することにより図１３８Ａに表示されている内容を対話操作した後（例えば、ステップ１３９０６で）、ノード１３８０４は、フォーカスを受け、関連する内容になる。ノード１３８０４は所定の表示可能領域内で少なくとも部分的に非表示（隠されている）ので、関連する内容は、以下で詳しく説明するように、水平次元方向に自動的にスクロールさせることができる。他の実施例では、図１３６に関して、ユーザがノード１３６１０に対応する展開ウィジェットを選択し、サブノード１３６０８を表示可能領域内に部分的にのみ表示させた場合、関連する内容は、ノード１３６１０とサブノード１３６０８の両方を含むことができる。

ステップ１３９１０では、ステップ１３９１２の実行が、所定の時間だけ遅らされる。本発明の様々な実施形態において、所定の遅延期間の長さは、０または０よりも大きい他の値とすることができる。例えば、図１３８Ａでは、所定の遅延期間である１００ｍｓが経過してから、フォルダツリーコントロールが所定の距離だけ動的に横スクロールされ、その結果、図１３８Ｂに例示されているビューが得られる。当業者であれば、設定された時間遅延の量は、適宜変えられることを理解するであろう。

ステップ１３９１２では、内容は、所定の距離について第２の次元方向に自動的に、動的にスクロールされる。例えば、図１３７のフォルダツリーコントロールの場合、関連するノード１３７０６が完全には表示されていないことがわかると、フォルダツリーコントロールを所定の距離だけ横スクロールさせて、ノード記述子（例えば、フォルダ名）の末尾が所定の表示可能領域の右辺に近似的に揃うようにすることができる。当業者であれば、様々な場合において、関連するノードを所定の表示可能領域の左辺に近似的にそろえるか、または関連するノードを所定の表示可能領域の中心に、またはその近くに近似的に揃えることが望ましい場合があることを理解するであろう。これらの場合のそれぞれにおいて、ノードは、表示可能領域の所定の辺に近似的に揃えられるものと解釈するものとする。それぞれの場合の所定の距離も、それに応じて変化しうる。例えば、図１３６に関して、ノード１３６１０に対応する展開ウィジェットをユーザが選択したことに応答して、関連する内容を所定の表示可能領域の左辺に近似的に揃え、サブノード１３６０８の可視性が増すようにすることができる。

さらに、修飾子「第２の」を使用することは、第１の次元が必要または要求されることを意味するものと解説すべきではないことを理解するであろう。例えば、ステップ１３９０６において、ユーザが、フォーカスをノード１３８０２からノード１３８０４に変えるようにマウスポインタを移動することにより、図１３８Ａに表示されている内容を対話操作する場合、ステップ１３９１２では、内容を水平次元方向に自動的に、動的にスクロールすることができる。その場合、垂直次元方向に初期スクロールがなかった場合でも、「第２の次元」は、水平次元方向となるであろう。

最後に、ステップ１３９１４で、ユーザに対し、所定の表示可能領域内の内容の更新されたビューが表示される。例えば、図１３８Ｂは、ステップ１３９１４の後生じるフォルダツリーのスクロールされた内容ビューである。更新されたビューでは、図１３８Ｂの狭い表示可能領域内の関連する内容（ノード１３８０８）のユーザ向けの可視性が高まる。

^**共通ファイルダイアログ：本発明の様々な態様は、１つまたは複数のプログラミングインターフェースを介して他のプログラム、システム、モジュールなどと通信することができる。プログラミングインターフェース（またはより単純に、インターフェース）は、１つまたは複数のコードセグメントが、１つまたは複数の他のコードセグメントにより実現される機能と通信するか、または機能にアクセスすることができるようにする何らかのメカニズム、プロセス、またはプロトコルとしてみなすことができる。それとは別に、プログラミングインターフェースは、他の（複数の）コンポーネントの１つまたは複数のメカニズム、メソッド、関数呼び出し、モジュールに通信可能なように結合することができるシステムのコンポーネントの１つまたは複数のメカニズム、メソッド、関数呼び出し、モジュール、オブジェクトなどとみなすことができる。前の文中の「コードセグメント」という用語は、１つまたは複数の命令またはコード行を含むことが意図されており、適用される用語、またはコードセグメントが別々にコンパイルされるかどうかに関係なく、コードセグメントがソースコード、中間コード、またはオブジェクトコードとして用意されるかどうかに関係なく、コードセグメントがランタイムシステムまたはプロセス内で使用されるかどうかに関係なく、同じもしくは異なるマシン上に配置されるか、または複数のマシンにまたがって分散されるかどうかに関係なく、およびコードセグメントにより表される機能が、全部ソフトウェアにより実装されるのか、全部ハードウェアにより実装されるのか、またはハードウェアとソフトウェアの組合せにより実装されるのかに関係なく、例えば、コードモジュール、オブジェクト、サブルーチン、関数などを含む。例えば、限定はしないが、アプリケーションプログラミングインターフェース（ＡＰＩ）、入力点、メソッド、関数、サブルーチン、リモートプロシージャコール、およびコンポーネントオブジェクトモデル（ＣＯＭ）インターフェースなどの用語は、プログラミングインターフェースの定義に包含される。

プログラミングインターフェースは、図１４５Ａ、図１４５Ｂ、または図１４５Ｃに示されているように一般的に表示することができる。図１４５Ａは、２台のコンピュータ間のインターフェースを例示している。図１４５Ｂは、インターフェースＩｎｔｅｒｆａｃｅ１を第１および第２のコードセグメントが通信する際に通る導管として例示している。図１４５Ｃは、インターフェースオブジェクトＩ１およびＩ２（第１および第２のコードセグメントの一部である場合も一部でない場合もある）を含むものとしてインターフェースを例示しており、これにより、システムの第１および第２のコードセグメントは媒体Ｍを介して通信することができる。図１４５Ｃのビューでは、インターフェースオブジェクトＩ１およびＩ２を同じシステムの別々のインターフェースとしてみなすことができ、またオブジェクトＩ１およびＩ２、それに加えて媒体Ｍは、インターフェースを含むものと考えることができる。図１４５Ａ、１４５Ｂ、および１４５Ｃは、双方向の流れ、およびその流れのそれぞれの側のインターフェースを示しているが、いくつかの実装では、一方向の情報の流れのみがあり、および／または一方の側にインターフェースオブジェクトのみがありうる。

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

プログラミングインターフェースの概念は、当業者に知られている。プログラミングインターフェースを実装する方法はほかにも多数ある。このような他の方法は、図１４５Ｂおよび１４５Ｃの単純化したビューに比べて高度であるか複雑であるかのように見えるが、それにもかかわらず、類似の機能を実行して同じ全体的な結果が得られる。プログラミングインターフェースのいくつかの例示的な代替え実装は、図１４５Ｄ〜１４５Ｍに関して説明されている。

因数分解。一方のコードセグメントから他方のコードセグメントへの通信は、その通信を複数の個別の通信に分けることにより間接的に実行できる。これは、図１４５Ｄおよび１４５Ｅに概略が示されている。図に示されているように、いくつかのインターフェースは、分割可能な機能群に関して説明することができる。したがって、図１４５Ｂおよび１４５Ｃのインターフェース機能は因数分解され、ちょうど数学的に２４、つまり２×２×３×２となるのと同様に、同じ結果が得られる。したがって、図１４５Ｄに例示されているように、インターフェースＩｎｔｅｒｆａｃｅ１により与えられる機能は、インターフェースの通信を変換するために、同じ結果が得られるようにしつつ、複数のインターフェースＩｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃに細分することができる。図１４５Ｅに例示されているように、インターフェースＩ１により与えられる機能は、同じ結果を得られるようにしつつ、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに細分することができる。同様に、第１のコードセグメントから情報を受け取る第２のコードセグメントのインターフェースＩ２は、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに因数分解することができる。因数分解の際に、第１のコードセグメントとともに含まれるインターフェースの個数は、第２のコードセグメントとともに含まれるインターフェースの個数と一致している必要はない。図１４５Ｄおよび１４５Ｅの場合のいずれかにおいて、インターフェースＩｎｔｅｒｆａｃｅ１およびＩ１の機能に関する精神は、図１４５Ｂおよび１４５Ｃのとそれぞれ同じである。インターフェースの因数分解は、さらに、結合法則、交換法則、および他の数学的法則に従い、因数分解は理解しにくい場合がある。例えば、演算の順序は、重要ではなく、その結果、インターフェースにより実行される関数は、そのインターフェースに到達する十分前に、他のコードまたはインターフェース断片により実行されるか、またはシステムの別のコンポーネントにより実行されることができる。さらに、プログラミング技術の当業者であれば、同じ結果が得られる異なる関数呼び出しを実行する様々な方法があることを理解できるであろう。

再定義。場合によっては、意図した結果をそれでも得られるようにしつつ、プログラミングインターフェースのいくつかの態様（例えば、パラメータ）を無視するか、追加するか、または再定義することが可能なことがある。これは、図１４５Ｆおよび図１４５Ｇに例示されている。例えば、図１４５ＢのインターフェースＩｎｔｅｒｆａｃｅ１は、関数呼び出しＳｑｕａｒｅ（ｉｎｐｕｔ，ｐｒｅｃｉｓｉｏｎ，ｏｕｔｐｕｔ）を含むが、この呼び出しは３つのパラメータ（「ｉｎｐｕｔ」、「ｐｒｅｃｉｓｉｏｎ」、および「ｏｕｔｐｕｔ」）を含み、１ｓｔＣｏｄｅＳｅｇｍｅｎｔから２ｎｄＣｏｄｅＳｅｇｍｅｎｔに発行されるとする。真ん中のパラメータ（「ｐｒｅｃｉｓｉｏｎ」）が与えられたシナリオにおいて重要でない場合、図１４５Ｆに示されているように、無視するか、または他のパラメータで置き換えることが可能である。いずれの場合も、第２のコードセグメントにより入力が平方された後、出力が返される限り、Ｓｑｕａｒｅの機能は、実現することができる。精度は、コンピューティングシステムの何らかの下流または他の部分にとって意味のあるパラメータであることは確かであるが、平方を計算する狭い目的について必要でないことが分かった後、置き換えるか、または無視することができる。例えば、有効な精度値を渡す代わりに、誕生日などの意味のない値を渡しても、結果に悪影響を及ぼすことはない。同様に、図１４５Ｇに示されているように、インターフェースＩ１は、インターフェースＩ１’で置き換えられ、パラメータを無視するか、またはインターフェースにパラメータを追加するように再定義される。インターフェースＩ２も、不要なパラメータ、またはどこか他のところで処理することができるパラメータを無視するように同様に再定義することもできる（インターフェースＩ２’として）。前記から明らかなように、プログラミングインターフェースは、場合によっては、ある目的には必要のない、他の目的には別のところで処理するために無視するか、再定義するか、または見送ることができるパラメータなどの態様を含むことができる。

インラインコーディング：２つの別々のコードモジュールの機能の一部または全部をマージして、それらの間の「インターフェース」が形を変えるようにすることが可能である。例えば、図１４５Ｂおよび１４５Ｃの機能は、それぞれ、図１４５Ｈおよび１４５Ｉの機能に変換することができる。図１４５Ｈでは、図１４５Ｂの前の第１および第２コードセグメントは、両方含む１つのモジュールにマージされる。この場合、コードセグメントは、それでも、互いに通信し合うことができるが、インターフェースは、単一モジュールにより適している形態に適合させることができる。そのため、例えば、正式のＣａｌｌおよびＲｅｔｕｒｎ文は、もはや必要ないが、インターフェースＩｎｔｅｒｆａｃｅ１による類似の処理または（複数の）応答は、そのまま効果がある場合がある。同様に、図１４５Ｉでは、図１４５ＣからのインターフェースＩ２の一部（または全部）をインターフェースＩ１にインラインで書き込み、インターフェースＩ１”を形成することができる。例示されているように、インターフェースＩ２は、Ｉ２ａとＩ２ｂに分割され、インターフェース部分Ｉ２ａは、インターフェースＩ１とともにインラインコーディングされており、インターフェースＩ１”を形成する。

分離。一方のコードセグメントから他方のコードセグメントへの通信は、その通信を複数の個別の通信に分けることにより間接的に実行できる。これは、図１４５Ｊおよび１４５Ｋに概略が示されている。図１４５Ｊに示されているように、ミドルウェア（機能および／またはインターフェース機能を元のインターフェースから分離させるので、（複数の）ＤｉｖｏｒｃｅＩｎｔｅｒｆａｃｅ）の１つまたは複数の断片を用意し、第１のインターフェースＩｎｔｅｒｆａｃｅ１上の通信を変換し、それらが異なるインターフェース、この場合、インターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃに適合するようにする。これは、例えば、つまり、Ｉｎｔｅｒｆａｃｅ１プロトコルによりオペレーティングシステムと通信するように設計されているアプリケーションのインストールベースがある場合に、実行することが可能であるが、その後、オペレーティングシステムは、異なるインターフェース、この場合、インターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃを使用するように変更される。２ｎｄＣｏｄｅＳｅｇｍｅｎｔにより使用される元のインターフェースは、１ｓｔＣｏｄｅＳｅｇｍｅｎｔにより使用されるインターフェースともはや互換性を有しなくなるように変更され、そのため、中間段階を使用して、新旧のインターフェースの互換性をとる。同様に、図１４５Ｋに示されているように、第３のコードセグメントは、インターフェースＩ１からの通信を受け取るために分離インターフェースＤＩ１と、例えば、ＤＩ２と連携するように再設計されたインターフェースＩ２ａおよびＩ２ｂにインターフェース機能を伝送するが、機能的に同じ結果が得られる分離インターフェースＤＩ２とともに導入することができる。同様に、ＤＩ１およびＤＩ２は連携し、機能的に同じまたは類似の結果を得られるようにしつつ、図１４５ＣのインターフェースＩ１およびＩ２の機能を新しいオペレーティングシステムに移し替えることができる。

書き換え。さらに他の可能な変更形態は、インターフェース機能を何かほかの、ただし、同じ全体的結果が得られるもので置き換えるコードを動的に書き換えることである。例えば、中間言語（例えば、ＭｉｃｒｏｓｏｆｔＩＬ、Ｊａｖａ（登録商標）ＢｙｔｅＣｏｄｅなど）で表されるコードセグメントを実行環境内でＪｕｓｔ−ｉｎ−Ｔｉｍｅ（ＪＩＴ）コンパイラまたはインタプリタに供給するシステムが考えられる（．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）実行時環境、または他の類似の実行時タイプの環境により用意されるものなど）。ＪＩＴコンパイラは、１ｓｔＣｏｄｅＳｅｇｍｅｎｔから２ｎｄＣｏｄｅＳｅｇｍｅｎｔに通信を動的に変換する、つまり２ｎｄＣｏｄｅＳｅｇｍｅｎｔ（元の、または異なる２ｎｄＣｏｄｅＳｅｇｍｅｎｔのいずれか）による要求に従って異なるインターフェースに適合させるように書くことができる。これは、図１４５Ｌおよび１４５Ｍに示されている。図１４５Ｌに示されているように、このアプローチは、上述のＤｉｖｏｒｃｅシナリオに類似している。これは、例えば、アプリケーションのインストールベースがＩｎｔｅｒｆａｃｅ１プロトコルによりオペレーティングシステムと通信するように設計されているが、オペレーティングシステムは、異なるインターフェースを使用するように変更されている場合に実行することが可能である。ＪＩＴコンパイラは、インストールベースのアプリケーションからオペレーティングシステムの新しいインターフェースにオンザフライで通信を適合させるために使用することが可能である。図１４５Ｍに示されているように、（複数の）インターフェースを動的に書き換えるこのアプローチは、さらに、（複数の）インターフェースを動的に因数分解するか、または他の何らかの方法で変更するために適用することができる。

他の実施形態を介したインターフェースと同じまたは類似の結果を得られる上述のシナリオは、様々な方法で、直列に、および／または並行して、または他の介入コードとともに組み合わせることもできることに留意されたい。そのため、上に示されている他の実施形態は、相互排他的ではなく、図１４５Ｂおよび１４５Ｃに示されている汎用のシナリオと同じまたは同等のシナリオを生成するように混合し、一致させ、組み合わせることができる。また、ほとんどのプログラミング構文と同様に、本明細書で説明していないかもしれないインターフェースの同じまたは類似の機能を実現する他の類似の方法があるが、それにもかかわらず、本発明の精神および範囲により代表されることに留意されたい。

「ファイルダイアログ」は、ファイルを開く、保存する、またはファイルが処理されること、および／またはファイルの処理方法を他の何らかの形で示すことを目的として形成されるダイアログを指すことができる。本発明のいくつかの実施形態は、ファイルを開く、およびファイルを保存するためのダイアログのいくつかの実施例を参照することにより説明されるが、本発明はこのことに限定されない。ファイルダイアログの他の実施例は、ファイル添付を挿入する、ファイルをインポートする、などのためのダイアログを含む。本明細書で使用されているように、単語「ファイル」は、広い意味が与えられており、一般的に、コンピュータによりアクセス可能な情報のコレクションを指す。ファイルは、テキスト、プログラミング命令、および／または様々な他のタイプのデータを含むことができる。ファイルは、ユーザがわかるように、ドキュメント、写真、またはファイルがデータを含む場合の他の何らかのタイプのアイテムとして識別できる。ファイルは、さらに、ディスクまたは他の記憶媒体上の１つまたは複数の物理的な場所に断片化するか、または他の何らかの方法で格納することもできる。

本発明は、従来の階層型ファイルツリー構造に格納されるファイルに限定されない。少なくともいくつかの実施形態では、ファイルは、上述のように複数のメタデータ属性（それとは別に「プロパティ」とも呼ばれる）を持つことができる。これらの属性に対する値を使用して、ファイルをユーザが注目するコレクションにグルーピングすることができる。例えば、１つのコンピュータ上のファイルは、ファイル作成者、ファイルが関係する顧客、およびファイルタイプなどのメタデータ属性を持つことができる。次いで、ユーザＡは、スプレッドシート、顧客Ｘ、Ｙ、およびＺに関する文書処理およびスライドショープレゼンテーションファイルを作成し、それらのファイルすべてをディレクトリサブフォルダ「Ｃ：＼Ｕｓｅｒｓ＼Ｕｓｅｒ＿Ａ＼」に格納する。ユーザＢは、スプレッドシート、文書処理およびｊｐｅｇ画像ファイルを同じ顧客のために作成する。ユーザＢは、スプレッドシートおよび文書処理ファイルを「Ｃ：＼Ｕｓｅｒｓ＼Ｕｓｅｒ＿Ｂ＼」に格納するが、画像ファイルは、「Ｃ：＼Ｍｅｄｉａ＼Ｐｈｏｔｏｓ＼」に格納する。その後、これらのファイルはすべて、リストに基づいてアクセス可能である。例えば、「ＣｌｉｅｎｔＸ」リストは、すべてのスプレッドシート、文書処理、スライドショーおよびｊｐｅｇファイルを、作成者に関係なく、クライアントＸのためにグルーピングする。ＣｌｉｅｎｔＸリストを指定することにより、ユーザは、複数のサブディレクトリを別々にナビゲートしなくても、それらのファイルのグルーピングを確認することができる。これらの「ａｕｔｈｏｒ」、「ｃｕｓｔｏｍｅｒ」、および「ｆｉｌｅｔｙｐｅ」メタデータ属性は、例示を目的として取り上げられている。他の実施例は、評価、コメント、プロジェクトなどのプロパティを含む。非常に多数のメタデータ属性タイプを実装することができ、本発明は、メタデータ属性のタイプにより限定されない。

図１４６には、本発明の少なくともいくつかの実施形態による「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００が示されている。図面中の例示的なダイアログは、ＯＳ（ＷＩＮＤＯＷＳ（登録商標）ＯＳの様々なバージョンなど）により生成されるグラフィカルユーザインターフェース（ＧＵＩ）内に独立のウィンドウとして示されるが、本発明は、このことに限定されない。例えば、本発明によるファイルダイアログは、さらに、既存のウィンドウのペイン（または既存のウィンドウ内のフレーム）として生成することが可能である。「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００は、ダイアログウィンドウのフレーム１４６０１内に含まれ、タイトル１４６０２を持つ。コントロール１４６０３のそれぞれにより、ユーザはダイアログ１４６００を最小化する、最大化する、または閉じることができる。矢印１４６０４は、「戻る」コントロールであり、ユーザは、すでに表示されているファイルグルーピングに戻るためにこれを選択することができる。タイトル１４６０２に隣接しているのは、ナビゲーションバー１４６０５および検索バー１４６０６であり、両方とも以下で説明する。

「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００は、４つの領域１４６０７〜１４６１０に分割される。ブラウザ領域１４６０７は、プレースバー部分領域１４６１１およびページ空間部分領域１４６１２を含む。プレースバー１４６１１内のエントリは、ファイルの一覧、ディレクトリの場所、または他のグルーピングに対応し、ユーザがファイルを特定するためにナビゲートすることができる「場所」を表す。プレースバー１４６１１内のエントリの１つを選択すると、対応する表示がページ空間領域１４６１２内に現れる。いくつかの場合において、その表示は、選択されたプレース内のファイルに対応するアイコンのコレクションとすることができる（例えば、選択された一覧または他のグルーピング）。いくつかの場合において、ＷＩＮＤＯＷＳ（登録商標）ＸＰＯＳのＷＩＮＤＯＷＳ（登録商標）ＥＸＰＬＯＲＥＲコンポーネントと同様に、特定のプレースバーエントリを選択することで、１つまたは複数のフォルダ、ディレクトリ、またはユーザがナビゲートできる他の場所に対するアイコンとともにファイルアイコンのコレクションを表示することができる。プレースバー１４６１１内の１つまたは複数のエントリは、展開可能であり、ドキュメントの部分一覧または他のサブグルーピングを表示することができる。例えば、図１４６の「Ｐｅｏｐｌｅ」エントリは、異なる個人に関係する（つまり、異なる個人に対応する適切なメタデータ属性値を持つ）ファイルの一覧が見えるように展開可能とすることができる。

図１４６の実施例では、ユーザは、「ＲｅｃｅｎｔＰｈｏｔｏｓ」一覧に対応するプレースバーエントリを選択しており、そのため、その一覧内のファイルに対応するサムネイル画像のコレクションとともにページ空間１４６１２内に表示される。次いで、ユーザは、ページ空間１４６１２の最上部にある「Ｎａｍｅ」、「Ｓｉｚｅ」、「Ｌｏｃａｔｉｏｎ」、「Ｅｖｅｎｔ」、「Ｄａｔｅ」を選択することにより、ファイル名、ファイルサイズ、場所、イベント、またはファイル作成日に対するプロパティ値に基づいてこれらのファイルを並べ替えることができる。ページ空間１４６１２内のファイルを並べ替える基準となるカテゴリは、プレースバー１４６１１上の選択されたエントリに基づいて変更できる。同様に、ファイルがページ空間１４６１２内に示される方法は、ファイルタイプに基づいて変わる場合がある。テキストファイルは、そのファイルに保存されているドキュメントの先頭ページのサムネイル画像として表すことができる。いくつかの場合において、ファイルは、ファイルを作成した（またはファイルが他の何らかの方法で関連付けられている）アプリケーションプログラムに対応するアイコンにより表すことが可能である。スクロールバー１４６１３を使用することで、ユーザはさらにファイルを見ることができる。

ページ空間１４６１２内に表示されているファイルの１つを選択した後、そのファイルに関するさらに詳細な情報が、インフォペイン領域１４６０８に表示される。インフォペイン領域１４６０８には、選択されたファイルのより大きなプレビュー（または「ゴースト」）１４６１４が、様々なメタデータ属性に対する値１４６１５とともに表示される。図１４６の実施例は、画像ファイルの選択を示しているが、本発明はそのことに限定されない。例えば、ページ空間１４６１２に表示されているファイルの１つまたは複数は、テキストファイルである場合がある。このようなファイルを選択した後、そのテキストファイルの先頭ページの画像は、ゴースト１４６１４として示される。もちろん、選択されたファイルに対するインフォペイン領域１４６０８に示されているプロパティおよび値は、異なることがある。ＵｓｅｒＡおよびＵｓｅｒＢの前の方の実施例を使用すると、「ＣｌｉｅｎｔＸ」一覧内のファイルの選択により、インフォペイン領域１４６０８内に作成者およびクライアントに対する値を表示することが可能である。

ナビゲーションバー１４６０５に戻ると、ユーザは、現在のページ空間表示に到達するまでにユーザが辿った「跡」を示す情報を与えられる。図１４６の実施例では、ユーザは、最初に、「Ｐｈｏｔｏｓ＆Ｖｉｄｅｏｓ」一覧にナビゲートし、次いで、「ＲｅｃｅｎｔＰｈｏｔｏｓ」部分一覧にナビゲートした。ユーザは、次いで、タイトルまたはキーワード値に基づいて、現在のページ空間内で、検索バー１４６０６を使用して、ファイルを特定することができる。

ブラウザ領域１４６０７およびインフォペイン領域１４６０８の下に、拡張性領域１４６０９がある。以下でさらに詳細に説明するように、ファイルダイアログの拡張性領域は、ダイアログ１４６００をインスタンス化するソフトウェアプログラムの開発者が指定することができる様々なユーザインターフェース（ＵＩ）コントロールを含むことができる。本明細書で使用されているように、「ＵＩコントロール」は、ユーザがダイアログをインスタンス化したアプリケーション（または他のコンピュータプログラム）を対話操作するために選択することができる（例えば、コントロール上でカーソルをホバリングし、マウスボタンを押すことにより）様々なタイプのグラフィック要素を含む。ＵＩコントロールは、限定はしないが、プッシュ（または「コマンド」）ボタン、「ラジオ」ボタン、チェックボックス、テキスト入力（または「エディット」）ボックスなどを含む。ＵＩコントロールは、さらに、情報をユーザに与えるためだけの（つまり、何かを選択するか、または他の何らかの方法で入力を行う機会をユーザに与えない）グラフィック要素も含む。このような情報のみのＵＩコントロールの実施例は、テキストのブロックまたは他のＵＩコントロールを分割するスペーサを含む。図１４６は、一組のラジオボタンコントロールおよびこれらのラジオボタンに対するテキストラベル（「Ｏｐｔｉｏｎｓ」）のみを示している。他のタイプのコントロールの実施例を以下で説明する。少なくともいくつかの実施形態では、拡張性領域１４６０９は、オプションであり、開発者は、それを完全に省くことが可能である。

拡張性領域１４６０９の下にコマンド領域１４６１０がある。コマンド領域１４６１０は、ユーザが開くことを望んでいるファイルの名前を入力することができるテキスト入力コントロール１４６１６を含む。図には示されていないが、コマンド領域１４６１０は、さらに、ユーザが開くことを望んでいるファイルのタイプを入力する（またはドロップダウンリストから選択する）ことができるコントロールを含むことが可能である。このコントロールは、例えば、異なるタイプの２つのファイルが同じタイトルを持つ（例えば、「ｒｅｐｏｒｔ．ＤＯＣ」および「ｒｅｐｏｒｔ．ＰＤＦ」）場合に有用である。ビューコントロール１４６１７を使用すると、ユーザは、ページ空間１４６１２内へのファイルの表示のされ方を変更することができる。アイコンのコレクションの代わりに、例えば、ユーザは、ファイル名、タイプ、サイズなどのテーブルを表示する「詳細」モード（図には示されていない）で識別されたファイルを表示したい場合がある。少なくともいくつかの実施形態では、ビューモードは、その一覧またはユーザがブラウザ領域１４６０７内でナビゲートした他の場所に関連付けられている既定のビューに基づく。開発者は、任意の場所に対し既定ビューモードを設定することができ、ユーザは、そのビューモード設定をオーバーライドすることが許される。「詳細」モードの場合、表示される列は、さらに、ユーザがナビゲートした場所に基づいているが、開発者は、どの列を見せるかを指定することができる（ユーザはそれをオーバーライドすることができる）。

コントロール１４６１８を使用すると、ユーザは、ダイアログ１４６００の外観を変更することができ、それによりインフォペイン領域１４６０８は表示されないか（図１４７を参照）、またはインフォペイン領域１４６０８がすでに非表示であれば、インフォペイン領域１４６０８が表示される。コマンドボタン１４６１９を使用すると、ユーザは、ページ空間１４６０７内で選択されたか、またはコントロール１４６１６において識別されているファイルを開くことができる。コマンドボタン１４６２０で、ユーザはダイアログ１４６００を取り消すことができる。開発者は、さらに、既定のボタンラベルをオーバーライドし、他のテキストを指定することもできる（例えば、「Ｏｐｅｎ」ボタンを「ＣｈｅｃｋＯｕｔ」に変更する）。

図１４８には、本発明の少なくともいくつかの実施形態による「ＳａｖｅＦｉｌｅ」ダイアログ１４８００が示されている。「ＳａｖｅＦｉｌｅ」ダイアログ１４８００は、ダイアログウィンドウのフレーム１４８０１内に含まれ、タイトル１４８０２を持つ。コントロール１４８０３および戻る矢印１４８０４は、図１４６の「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００のコントロール１４６０３および１４６０４に似た動作をする。ナビゲーションバー１４８０５および検索バー１４８０６は、「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００のナビゲーションバー１４６０５および検索バー１４６０６と似た機能を持つ。「ＳａｖｅＦｉｌｅ」ダイアログ１４８００は、さらに、プレースバー１４８１１およびページ空間１４８１２を持つブラウザ領域１４８０７も含む。「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００（図１４６）と同様に、プレースバー１４８１１内のエントリを選択すると、一覧、ディレクトリフォルダ、または他のファイルグルーピングに関連付けられているファイルに関する情報がページ空間１４８１２内に表示され、および／または他の場所へのナビゲーションを可能にするアイコンが表示される。ページ空間１４８１２内に表示されるファイルは、ページ空間１４８１２の一番上にあるコントロール（「Ｎａｍｅ」、「Ｔｙｐｅ」など）を使用して、同様に並べ替えを行うことができる。

「ＳａｖｅＦｉｌｅ」ダイアログ１４８００は、さらに、インフォペイン領域１４８０８を含む。少なくともいくつかの実施形態では、図１４８に示されているように、「ＳａｖｅＦｉｌｅ」ダイアログのインフォペイン領域は、ブラウザ領域の下に配置されている。インフォペイン領域１４８０８は、保存すべきファイルのゴースト１４８１４を含む。保存されるファイルのタイプに応じて、ゴースト１４８１４は、ファイル内に格納されているドキュメント、映像、または他のアイテムのサムネイル画像であるか、ファイルに関連付けられたアプリケーションに対応するアイコンであるか、または他の何らかのタイプのグラフィック表現とすることができる。ファイル名コントロール１４８１６を使用すると、ユーザは、保存されるファイルの名前を入力することができる。このフィールドには、「ＦｉｌｅＳａｖｅ」ダイアログをインスタンス化したアプリケーションプログラムにより提案されたファイル名が入るようにできる（例えば、保存されるファイルの最初の単語）。いくつかの場合では、ユーザは、ページ空間１４８１２からファイルを１つ選択することにより既存のファイルを置き換えることができ、その場合、置き換えられるファイルのファイル名は、自動的に、コントロール１４８１６に追加されるようにできる。他の場合には、ユーザは、ファイルをどこに格納すべきか判然としていないことがある。プレースバー１４８１１（ページ空間コントロール）を使用することで、ユーザは、１つまたは複数の一覧または他のファイルグルーピングにナビゲートし、適切な場所を見つけることができる。ユーザは、このようなグルーピングをナビゲートするときに、それらのグルーピングの中の他のファイルに関する情報をページ空間１４８１２内に見ることができ、その情報を使用して、現在のファイルは、それらのグルーピングのうちの１つに保存すべきかどうかを判定することができる。いくつかの場合において、保存されるファイルのゴースト１４８２６は、さらに、ユーザがそのファイルにとって可能な様々な場所をナビゲートするときにページ空間１４８１２内に表示される。この方法で、ユーザは、自分が後でファイルを見つける場所の視覚的指示を得る。ページ空間１４８１２内のゴースト１４８２６が存在することも、現在の一覧または他のグルーピングが有効な保存場所であることの証である。

また、インフォペイン領域１４８０８には、保存されるファイルに関する様々なメタデータ用のフィールド１４８１５が表示される。いくつかの場合において、ユーザは、メタデータ値を追加するこれらのフィールドのうちの１つまたは複数を選択することができる。例えば、ユーザは、「ｋｅｙｗｏｒｄ」フィールドを選択し、今後のキーワード検索でファイルを見つけやすくできる単語を追加することができる。他の場合には、メタデータフィールドの１つに対する値を、アプリケーションインスタンス化ダイアログ１４８００により初期値として埋めることができる（少なくとも最初に）。さらに他の場合には、メタデータフィールドの値は、そのファイルの選択された格納場所に基づいて自動的に初期値として埋めることが可能である。例えば、ユーザがファイルを「ｐｒｏｊｅｃｔＸ」一覧内で保存する場合、「ｐｒｏｊｅｃｔ」（図には示されていない）に対するメタデータフィールドに、自動的に初期値として「Ｘ」が入る。「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００の場合と同様に、ファイルに対するインフォペイン領域１４６０８に示されているメタデータカテゴリおよび値は、異なることがある。

インフォペイン領域１４８０８の下に拡張性領域１４８０９がある。「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００の拡張性領域１４６０９と同様に、「ＳａｖｅＦｉｌｅ」ダイアログの拡張性領域は、ソフトウェア開発者が指定することができる様々なユーザインターフェース（ＵＩ）コントロールを含むことができる。チェックボックスのペアが図１４８に示されているが、他のＵＩコントロールを含めることが可能である。拡張性領域１４８０９は、少なくともいくつかの実施形態ではオプションである。別の言い方をすれば、開発者は、「ＳａｖｅＦｉｌｅ」ダイアログを拡張性領域なしで自由に作成できるということである。

拡張性領域１４８０９の下にコマンド領域１４８１０がある。コマンド領域１４８１０は、ファイルを選択された場所に保存するためのコマンドボタン１４８１９、さらに「ＳａｖｅＦｉｌｅ」ダイアログ１４８００を取り消すためのコマンドボタン１４８２０を含んでいる。これらのボタンに対するテキストは、開発者側で変更することができる（例えば、「Ｓａｖｅ」を「ＣｈｅｃｋＩｎ」に変更する）。さらに、コマンド領域１４８１０には、ブラウザ領域１４８０７を非表示にするためのコントロール１４８２１が含まれる。このコントロールを選択することにより、図１４９に示されているように、ブラウザ領域１４８０７は、もはや表示されない。この方法で、よりコンパクトな「ＳａｖｅＦｉｌｅ」ダイアログを用意することができる。ナビゲーションバー１４８０５および検索バー１４８０６、および／またはコントロール１４８０３の最小化および最大化矢印も、コンパクト化された「ＳａｖｅＦｉｌｅ」ダイアログ中で削除することができる。コントロール１４８２１を選択し直すことにより（図１４９で「ＳｈｏｗＢｒｏｗｓｅｒ」に変更されたラベル）、ブラウザ領域１４８０７は、再び表示される。ビュー選択コントロール１４８１７（図１４４）は、ブラウザ領域１４８０７が表示された場合に表示可能であり、「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００（図１４６）のビュー選択コントロール１４６１７に類似の機能を持つ。「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００の場合のように、「ＳａｖｅＦｉｌｅ」ブラウザが表示されるときに既定のビューモード（例えば、アイコン対詳細）は、ユーザがナビゲートした一覧または他の場所に基づいている。開発者は、同様に、ビューモード設定、および詳細ビューモードのときに表示される列を同様に設定することができる（ユーザは、それをオーバーライドすることができる）。

図１４６および１４８を比較すると分かるように、「ＯｐｅｎＦｉｌｅ」ダイアログ１４６００内のインフォペイン領域１４６０８の場所は、「ＳａｖｅＦｉｌｅ」ダイアログ１４８００のインフォペイン領域１４８０８の場所と異なる。この位置変更は、これら２つのタイプのダイアログの目的が異なることに対応している。ユーザは、典型的には、「ＯｐｅｎＦｉｌｅ」ダイアログで特定のファイルを探す。ファイル内容のグラフィック表示は、詳細なメタデータよりも役立つ場合が多い。したがって、「ＯｐｅｎＦｉｌｅ」ダイアログ内のインフォペイン領域のフォーカスは、典型的には、ファイルプレビュー上にあり、インフォペインは、より大きなゴースト画像に対応できるような位置にある。「ＳａｖｅＦｉｌｅ」ダイアログ内のインフォペイン領域のフォーカスは、編集および将来の取り出しのためファイルの適切な格納場所に置かれる。したがって、「ＳａｖｅＦｉｌｅ」ダイアログのインフォペイン領域は、メタデータの入力および／または修正を奨励する位置にある。

少なくともいくつかの実施形態では、メタデータフィールドは、所定の順序に基づいて「ＯｐｅｎＦｉｌｅ」および「ＳａｖｅＦｉｌｅ」の両方のダイアログのインフォペイン領域に表示される。特に、システム要求メタデータ属性（例えば、ファイル名、ファイルタイプ、保存場所）が最初に表示される。次に表示されるのは、ダイアログをインスタンス化するアプリケーションによって必要とされるが、すべてのアプリケーションで必ずしも必要ではないメタデータ属性である（例えば、圧縮比、ファイル保護）。次いで、残りのプロパティが表示される。インフォペイン領域（および必要ならば、ダイアログ全体）は、すべてのシステムおよびアプリケーションにより要求されるプロパティを表示するように自動的にサイズ変更される。少なくともいくつかの実施形態では、アプリケーションプログラムは、どのようなメタデータが必要かを指定することはできないが、アプリケーションは、対応するフィールドが既定のサイズのダイアログ内に表示されるような優先度を持つようにメタデータタイプを「格上げ」することができる。

図１４６および１４８には、開発者が「ＯｐｅｎＦｉｌｅ」または「ＳａｖｅＦｉｌｅ」ダイアログの拡張性領域内に置くことができる様々なタイプのＵＩコントロールのうちの２つが示されている。開発者は、同じタイプの複数のコントロールを含め、および／または異なるタイプのコントロールを組み合わせることができる。図１４８は、検証（または「チェックボックス」）ＵＩコントロールのペアを示している。このようなＵＩコントロールは、テキスト（「Ｏｐｔｉｏｎ１」および「Ｏｐｔｉｏｎ２」）を含むことができ、複数のチェックボックスに適用可能なラベルを含むことができる（「ＳａｖｅＯｐｔｉｏｎｓ」）。ユーザは、マウスでチェックをチェックボックスに入れる（またはチェックボックスからチェックを削除する）ことができる。次いで、コントロールのチェック／チェック解除状態がプログラムに返される。ＬＴＲ（左から右）言語で実装されている少なくともいくつかの実施形態では、チェックボックスコントロールのテキストは、左寄せであり、コントロールが配置されている列にラップする。拡張性領域内のラベルは、インフォペイン領域内のメタデータフィールドラベルに自動的に揃えられる。図１４８に示されているように、拡張性領域１４８０９内の「ＳａｖｅＯｐｔｉｏｎｓ」ラベルは、インフォペイン領域１４８０８内の「ＳａｖｅＩｎ」および「ＦｉｌｅＴｙｐｅ」に揃えられる。以下でさらに詳しく説明するように、拡張性領域内のＵＩコントロールは、さらに、１つまたは複数のグループに編成することができ、複数の列内に表示することができる。

図１４６は、ラジオボタンＵＩコントロールのコレクションを示している。それぞれのラジオボタンコントロールは、典型的には、可能な入力オプションについて１つまたは複数のテキスト行を表示する（例えば、「ＯｐｅｎＯｒｉｇｉｎａｌＦｉｌｅ」）。それぞれのオプションのテキストの隣に、ユーザがマウスで選択できる小さな円または他の領域がある。いったん選択されると、この領域は、黒色の点または選択の他の指示で埋められる。典型的には、複数のオプションのうちの１つだけが選択できる。ユーザが、オプションを１つ選択し、次いで、複数のオプションのうちの他のオプションを選択した場合、第１の選択に対する黒色の点が削除される。ラジオボタンコントロールも、ラベル（「Ｏｐｔｉｏｎｓ」）を含むことができる。ＬＴＲ言語で実装されている少なくともいくつかの実施形態では、ラジオボタンコントロールのテキストは、左寄せであり、コントロールが配置されている列にラップする。

図１５０〜１５４Ｂには、ソフトウェア開発者が拡張性領域に含めるように指定することができる様々な他のタイプのＵＩコントロールが示されている。図１５０〜１５４Ｂは、「ＳａｖｅＦｉｌｅ」ダイアログの拡張性領域内の他のタイプのＵＩコントロールを示しているが、これらのＵＩコントロールは、さらに、「ＯｐｅｎＦｉｌｅ」ダイアログ（または他のタイプのファイルダイアログ）拡張性領域に含めることができる。図１５０は、ドロップダウンボックスコントロールを示している。図１５０から分かるように、ドロップダウンボックスにより、ユーザは可能な選択の一覧を表示するようにボックスを展開することができる。ドロップダウンリストから選択されたオプションは、自動的にボックス内に配置される。図１５１は、コンボボックスコントロールを示している。このＵＩコントロールにより、ユーザは、ボックスを可能な選択の一覧（ドロップダウンボックスに類似している）に展開することができるが、さらに、ユーザは、ボックス内にテキストを入力することができる（図１５１に、「ｔｙｐｅｈｅｒｅ」と示されている）。

図１５２は、プッシュボタンＵＩコントロール１５２０１および１５２０２、さらにエディットボックスコントロール１５２０３を示している。さらに図１５２には、ＵＩコントロールのグルーピングが例示されている。少なくともいくつかの実施形態では、コントロールグループは、１つまたは複数のコントロールおよびグループ内のコントロールに適用可能なラベルを含むことができる。図１５２の実施例では、４つのグループが示されている。グループ１５２１１は、１つのグループラベルと３つのチェックボックスＵＩコントロールを含んでいる。グループ１５２１２は、グループラベルを持たないが、２つのラジオボタンＵＩコントロールを含む。グループ１５２１３は、グループラベル、エディットボックスＵＩコントロール１５２０３、および２つのプッシュボタンＵＩコントロール１５２０１および１５２０２を含む。グループ１５２１４は、普通のテキスト、例えば、ラベルまたは特定のコントロールによる関連付けがないテキストを含む。グループ１５２１１〜１５２１４は、図１５２に説明のために輪郭が示されているが、そのような輪郭は、実際のダイアログに必ずしも表示されない。セパレータ１５２０４は、コントロールグループ間に配置するように指定することができる。少なくともいくつかの実施形態では、セパレータは、単一の列にまたがるだけであり、グループの最後の要素として追加される。最初または最後の列要素として出現するセパレータは、非表示である。少なくともいくつかの実施形態では、図１５２に示されているように、グループ内のコントロールは、ダイアログが表示されたときに拡張性領域の同じ列内にまとめられている。いくつかの実施形態では、これもまた図１５２に示されているように、「ＳａｖｅＦｉｌｅ」ダイアログ拡張性領域内のＵＩコントロールグループラベルの右辺は、インフォペイン領域内のメタデータラベル（「ＦｉｌｅＴｙｐｅ」および「Ｋｅｙｗｏｒｄｓ」）の右辺に自動的に揃えられる。「ＳａｖｅＦｉｌｅ」ダイアログ拡張性領域内のＵＩコントロールの左辺は、インフォペイン領域内のメタデータ値フィールドの左辺に同様に自動的に揃えられる。普通のテキストは、自動的に左寄せされ、テキストが含まれる列にラップする。

いくつかの実施形態では、ドロップダウンメニューＵＩコントロールは、図１５３Ａおよび１５３Ｂに示されているように、コマンドの領域内に含めることができる。メニューを選択すると、選択可能なオプションの一覧が表示される。いくつかのオプションを選択すると、サブメニューおよび／または他のダイアログが表示される。いくつかの場合において、ドロップダウンメニューおよびコマンドボタンは、「分割ボタン」ＵＩコントロールに組み合わせることができ、これはさらに、コマンド領域内に配置することができる。分割ボタンＵＩにより、ユーザは、ドロップダウンメニュー内のオプションを選択することができる。次に、この分割ボタンは、選択されたオプションで再ラベル付けされ、ユーザは、そのボタンを押して、選択されたオプションに作用することができる。他のコントロールも、図１５４Ａ（プッシュボタンＵＩコントロール「＜テキスト＞」）および１５４Ｂ（チェックボックスＵＩコントロール）に示されているように、コマンド領域に追加することができる。これは、開発者が、単一の専用コントロールを含めることのみを必要とし、拡張性領域の表示領域を消費することを避ける場合に望ましいと考えられる。少なくともいくつかの実施形態では、開発者は、ラジオボタングループおよびラベルをコマンド領域に追加できない。コマンド領域内にコントロールを含めると、さらに、開発者は、そのコントロールを強調し、および／または拡張性領域内のコントロールからそのコントロールを分離することができる。そのため、開発者は、拡張性領域に対しいくつかのコントロールを、コマンド領域に対し１つのコントロールを指定することができる。しかし、他の実施形態では、メニューＵＩコントロールを除き、拡張性領域が表示される場合（例えば、２つまたはそれ以上のＵＩコントロールが追加される場合）に、追加のコントロールは、コマンド領域内に置かれない。メニューは、アプリケーションによりインスタンス化された複数のダイアログに適用可能な選択肢を含むことが多く、コマンド領域内でメニューを使用できるようにすると、場合によっては効率的である。いくつかの実施形態では、メニューは、常に、コマンド領域内に配置されている。

少なくともいくつかの実施形態では、拡張性領域へのＵＩコントロールの配列および外観表示は、自動的である。ダイアログをインスタンス化するアプリケーションは、単純に、ＯＳ（１つまたは複数のプログラミングインターフェースを介して）、ＵＩコントロール、および／または所望のグループを識別する。次いで、ＯＳは、その配列および外観を制御する。グループに明示的に追加されないコントロールは、それ専用のグループとして取り扱われる。ＯＳは、ＵＩコントロールまたはグループがプログラミングインターフェースで最初に識別される順序に基づいてそれぞれのグループを拡張性領域内に置く。図１５５は、「ＳａｖｅＦｉｌｅ」ダイアログ内のコントロールグループの自動レイアウトを示している。図１５５に示されているように、「ＳａｖｅＤｉａｌｏｇ」インフォペイン領域内のメタデータフィールドラベル／値のペアは、２つの列を形成する。次いで、コントロールグループは、拡張性領域に追加され、それらの列に揃えられ、それにより拡張性領域の高さを最小にする。グループ間の間隔は、グループ内の個別のコントロールの間の間隔とともに、自動的である。つまり、アプリケーション開発者は、それぞれのＵＩコントロールの位置を正確に指定する必要はない。同様に、ＵＩコントロール、グループラベル、普通のテキストに対するテキストの外観も、１つまたは複数のＯＳテーマファイルにより自動的に制御される。

図１５６には、少なくともいくつかの実施形態による「ＯｐｅｎＦｉｌｅ」ダイアログ内のＵＩコントロールの自動レイアウトが示されている。図１４６に示されているように、「ＯｐｅｎＦｉｌｅ」ダイアログのインフォペイン領域は、「ＳａｖｅＦｉｌｅ」ダイアログのインフォペイン領域と違った形で配列されている。したがって、「ＯｐｅｎＦｉｌｅ」ダイアログ拡張性領域内のＵＩコントロールおよびＵＩコントロールグルーピングは、コマンド領域内の「ＦｉｌｅＮａｍｅ」ラベルおよび対応するテキストボックスコントロールに揃えられる。複数のコントロールグルーピングが「ＯｐｅｎＦｉｌｅ」ダイアログ拡張性領域に対して指定されている場合、第２の列が使用される。少なくともいくつかの実施形態では、「ＳａｖｅＦｉｌｅ」ダイアログと同様に、「ＯｐｅｎＦｉｌｅ」ダイアログをインスタンス化したアプリケーションが、単純に、１つまたは複数のプログラミングインターフェースを介して、ＵＩコントロールおよび／またはグループをＯＳに対し識別させる。次いで、ＯＳは、ＵＩコントロールの配列および外観を制御する。コントロールグループは、それらのコントロールグループが開発者により指定された順序で「ＯｐｅｎＦｉｌｅ」ダイアログに追加され、拡張性領域の高さが最小になるように自動的にレイアウトされる。間隔、テキストフォントなどは、１つまたは複数のＯＳテーマファイルにより制御される。

拡張性領域（および、場合によってはコマンド領域）内に含めるようにＵＩコントロールを指定することに加えて、アプリケーション開発者は、様々な他の方法でファイルダイアログをカスタマイズすることができる。適切なプログラミングインターフェース（後述）を使用することにより、開発者は、ダイアログタイトル（例えば、図１４６の「ＯｐｅｎＦｉｌｅ」タイトル１４６０４、図１４８の「ＳａｖｅＦｉｌｅ」タイトル１４８０４）をオーバーライドし、他の何らかのタイトルを表示させることができる。開発者は、ダイアログが開かれたときにダイアログのナビゲート先となる場所に影響を及ぼす選択を行うこともできる。特に、図１４６または図１４８に示されているようなダイアログが最初に開かれた場合、ダイアログは、特定の一覧または他のファイルグルーピングをファイルの保存先（またはファイルを開く）推奨場所として表示することが多い。いくつかの実施形態では、ファイルダイアログは、最初に、（１）インスタンス化するアプリケーションが指定する場所（例えば、アプリケーションが訪れた最後の場所）、（２）そのアプリケーションによりファイルが開かれたまたは保存された最後の場所（ＯＳにより追跡）、（３）アプリケーションにより指定された既定の場所、または（４）ＯＳ指定の既定の場所（例えば、ルートディレクトリ、ＷＩＮＤＯＷＳＯＳのデスクトップなど）のうちの１つ（優先順位順に表示される）にナビゲートすることを試みる。

アプリケーション開発者は、さらに、初期ブラウザモードを指定することもできる。いくつかの実施形態では、例えば、「ＳａｖｅＦｉｌｅ」ダイアログは、アプリケーション側で別のことを要求していない限りブラウザ領域を非表示にしたまま自動的に開く。いくつかの実施形態では、「ＯｐｅｎＦｉｌｅ」ダイアログは、常に、ブラウザ領域とともに表示される。アプリケーション要求に応じてファイルダイアログを生成するＯＳは、さらに、ダイアログを既定のサイズで画面上の既定の場所に描画することができる。例えば、ＯＳは、表示の中心にダイアログを自動的に配置し、ダイアログおよび／またはダイアログの様々な領域を特定のサイズに制限することができる。アプリケーション開発者は、ダイアログのサイズおよび／または場所を指定することにより既定の値をオーバーライドすることができる。これは、サイズおよび／または場所に対する値を明確に供給することにより行うことができる。これは暗黙のうちに実行することもできる。例えば、アプリケーションは、既定のサイズ内に収まることができる以上のコントロールを拡張領域について指定することができる。

表示内の他のウィンドウと同様に、ユーザは、ダイアログを移動し、および／またはサイズ変更することもできる。同様に、ユーザは、ブラウザ領域（示されている場合）およびインフォペイン領域のサイズを変更することができる。インフォペイン領域が展開されると（例えば、マウスでインフォペイン領域の辺を選択して、その辺を画面上で引っ張ることにより）、追加のメタデータプロパティ／値のペアが表示されるようになる。インフォペイン領域が縮小すると、表示されるプロパティ／値のペアも少なくなる。ダイアログまたはダイアログ領域のサイズまたは位置に対するユーザ変更（さらには、ビューモードへの変更、詳細ビューモードでの列表示など）は、ユーザがダイアログを完了するか、または取り消すまで持続することができる。いくつかの実施形態では、そのようなユーザ変更の一部または全部は、後のダイアログでも永続させることができる。

図１５７および１５８は、アプリケーション側が本発明のいくつかの実施形態によるファイルダイアログの生成を要求する方法とファイルダイアログが従来の技術で要求される方法との違いを示すブロック図である。図１５７は、アプリケーションプログラムがＷＩＮＤＯＷＳＯＳの様々なバージョンのファイルダイアログの表示を要求する既存の方法を示すブロック図である。図１５７では、アプリケーションは、まず最初に、表示するダイアログに対応するデータ構造体（「ＤｉａｌｇＳｔｒ」）を作成する。この構造体は、ダイアログの挙動を制御する多数の変数およびフラグに対する値を含む。ＷＩＮＤＯＷＳＯＳの様々なバージョンにおいて、この構造体は、「ＯＰＥＮＦＩＬＥＮＡＭＥ」構造体である。ダイアログをインスタンス化するために、アプリケーションは、次に、ＤｉａｌｇＳｔｒ構造体へのポインタを引数として持つＯＳ関数を呼び出す。特に、アプリケーションは、「ＧｅｔＯｐｅｎＦｉｌｅＮａｍｅ」関数を呼び出してファイルを開くダイアログをインスタンス化し、「ＧｅｔＳａｖｅＦｉｌｅＮａｍｅ」関数を呼び出して、ファイルを保存するダイアログをインスタンス化する。簡単にいうと、これらの関数は、図１５７で、「ＧｅｔＦＮ（ｐＤｉａｌｇＳｔｒ）」と一般的に示されている。この関数呼び出しに対する応答として、ＯＳは、次に、既定のダイアログを含むウィンドウを生成する。

アプリケーション開発者がカスタムＵＩコントロールを含むように既定のダイアログをカスタマイズすることを望んでいる場合、追加のステップが必要である。特に、開発者は、カスタマイズされたＵＩコントロールを保持するための（複数の）領域を定義する、既定のダイアログの（複数の）部分に対しカスタムテンプレートを作成しなければならない。そこで、そのテンプレートへのポインタが、ＤｉａｌｇＳｔｒ構造体に含まれる。ＯＳは、カスタムテンプレートからデータを取り出し、そのデータを使用して、既定のダイアログの子ウィンドウ内にカスタマイズされたコントロールを作成する。

一見したところでは、図１５７のプロシージャは、簡単なように見える。しかし、カスタムテンプレートでは、所望のカスタムＵＩコントロールおよびその位置、コントロールの表示の仕方などをすべて指定しなければならない。カスタムテンプレートを作成することは、アプリケーション開発者にとっては大変な労力になりうる。さらに、開発者は、カスタムＵＩコントロールが受け取るユーザ入力を処理するコールバック関数も作成しなければならない。

図１５７のプロシージャも、ＯＳ開発者にとっては問題となる。アプリケーション開発者が既定のダイアログのカスタマイズされた領域に入れることができるものについていくつかの制限が課されている。同様に、アプリケーション開発者が既定のダイアログ内にカスタマイズされた領域を置くことができる場所についてもいくつかの制限が課されている。図１５７は、単一の連続するブロック内にあるすべてのカスタマイズされたコントロールを示しているが、これは常にそうであるわけではない。カスタムテンプレートでは、既定のダイアログの複数の子ウィンドウ内に置く多数のカスタムコントロールを指定することができ、カスタマイズされた（複数の）領域は、様々な形状を取りうる。これらすべての要因を考慮して、ＯＳ開発者が、様々なアプリケーションにおいて既定のダイアログをカスタマイズする方法をすべて知ることは、（不可能でないとしても）困難である。さらに、これにより、ＯＳをアップグレードする際の問題も悪化する。例えば、新しい要素を特定の場所に追加する既定のダイアログ形式への変更は、カスタマイズが同じ場所にあるダイアログをインスタンス化するアプリケーションと非互換となる可能性がある。

図１５８は、本発明のいくつかの実施形態によるファイルダイアログの作成を例示するブロック図である。アプリケーション開発者は、表示するダイアログに対応するオブジェクトを作成する。オブジェクトは、ＯＳにより利用可能にされるオブジェクトクラスのインスタンス化である。いったん作成されると、オブジェクトは、アプリケーションがダイアログを表示する、コントロールをダイアログに追加する、およびダイアログの挙動を何らかの形で設定するために呼び出すことができるメソッドを自動的に含む。これは、図１５８に概略が示されており、アプリケーションは、いくつかのコントロールをダイアログに追加するためにインスタンス化されたダイアログオブジェクトの様々なメソッドを呼び出している（例えば「ＡｄｄＣｏｎｔｒｏｌｌ（）」）。他のメソッドは、ダイアログの外観および挙動の他の態様を制御するために呼び出される（および／または指定された変数値および／またはフラグがこれらの呼び出しに含まれる）。以下では、これらのメソッドへの呼び出しを介して開発者が実行できるアクションの実施例を説明する。

・ドロップダウンボックスを追加する。
・ドロップダウンメニューを開くことを有効にする。
・メニューを追加する。
・コマンドボタンを追加する。
・コンボボックスを追加する。
・ラジオボタンを追加する。
・チェックボックスを追加する。
・テキスト入力ボックスを追加する。
・セパレータを追加する。
・テキストを追加する。
・コントロールをグループ化する。
・コントロールのラベルを設定する。
・コントロール状態を参照する。
・コントロール状態を設定する。
・テキスト入力ボックス内のテキストを参照する。
・テキスト入力ボックス内にテキストを設定する。
・コントロールを追加する（例えば、常に表示されているダイアログ）。
・コントロールを目立たせる。
・コントロールアイテムを削除する。
・ダイアログが開くまたは保存できるファイルタイプを設定する（「ＯｐｅｎＦｉｌｅ」ダイアログでは、ファイルタイプを使用して、ユーザ用のビューをフィルタ処理することができ、「ＳａｖｅＦｉｌｅ」ダイアログでは、ファイルタイプにより、ユーザ指定ファイル名に付加する拡張子を決定することができる）。
・現在選択されているファイルタイプを設定する。
・現在選択されているファイルタイプを参照する。
・ダイアログからイベントを監視するイベントハンドラをアタッチする。
・以下のようなダイアログ挙動を制御するフラグを立てる。
○ ファイルを上書きする前に確認をユーザに求めるかどうか（「ＳａｖｅＦｉｌｅ」ダイアログ）、
○ ユーザにより返されたファイル名に対するファイル拡張子が現在選択されているファイルタイプのものと一致することを要求するかどうか（「ＳａｖｅＦｉｌｅ」ダイアログ）、
○ ユーザにより返されたアイテム名がファイルシステムアイテムであることを要求するかどうか、
○ ユーザが開くファイルを複数選択できるかどうか、
○ ユーザが、既存のフォルダ内のファイルを指定する必要があるかどうか、
○ 開くべきファイルがすでに存在していなければならないかどうか、
○ ユーザが、すでには存在していないユーザにより識別されたアイテム（例えば、フォルダまたは一覧）を作成するようユーザに求めるかどうか、
○ 共有違反を検出した後の挙動。
・様々なフラグの現在設定を参照する。
・ダイアログが開くフォルダまたは他の場所を設定する。
・ダイアログ内のユーザの（複数の）現在選択を参照する。
・ダイアログが示している、またはダイアログの開く先（ダイアログが現在表示されていない場合）の現在のフォルダを参照する。
・ファイル名テキストボックスＵＩコントロール内の現在テキストを参照する。
・ダイアログのタイトルを設定する。
・「Ｏｐｅｎ」または「Ｓａｖｅ」ボタンのテキストを設定する。
・ファイル名テキストボックスＵＩコントロール内の隣にあるラベルのテキストを設定する。
・ユーザが表示されているダイアログ内で行った選択を参照する。
・プレースをプレースバーに追加する。
・ユーザにより入力されたファイル名に対する既定の拡張子を設定する。
・ダイアログを閉じる。
・状態が永続するように識別子をダイアログの状態に関連付ける（例えば、最後に訪れたフォルダ、位置、サイズ）。
・ダイアログに対する永続状態をクリアする。
・最初にファイル名フィールドに出現する名前を設定する。
・保存ダイアログ内に集められるメタデータ属性値を指定する。
・保存されるファイルに対するプロパティストアを設定する。
・アプリケーションが、インフォペイン領域内で現在のメタデータ値を参照することができるか、またはダイアログが閉じられた後最後の値の集合を待って、受け取らなければならないかどうかを指定する。
・プロパティの集合を１つのファイルに適用する。
・ダイアログが閉じないようにする（例えば、ユーザが無効な選択を入力した場合）。

呼び出されたメソッドに基づき（図１５８のダイアログオブジェクトからの矢印として示されている）、ＯＳは要求されたダイアログを作成する。すでに説明されているように、ＵＩコントロールの配列は、ＯＳにより設定される。したがって、ＵＩコントロールに対する詳細な配置情報（例えば、参照場所からピクセルｘおよびｙのオフセット指定する）は、アプリケーション開発者が提供する必要はない。ダイアログカスタマイズは、ダイアログオブジェクト内のメソッドの呼び出しにより容易になるため、またこれらのメソッドでファイルダイアログをカスタマイズする方法は、ＯＳ開発者に知られているため、ＯＳ開発者は、ＯＳ修正がアプリケーションにどのような影響を及ぼすかを知りやすい立場にある。特に、カスタマイズされたコントロールは、メソッド呼び出しのうちの１つを介して指定することができるものに限定される。これらのＵＩコントロールは、ダイアログの知られている領域内に配置されるため、ＯＳは、後で、ダイアログの他の部分を変更するように修正されることができる。

さらに、ＯＳでは多数のダイアログオブジェクトメソッドを呼び出して、様々なイベントのアプリケーションを通知することができる。次いで、アプリケーションは、応答として所望のアクションを実行することができる。例えば、指定されたファイルのパスワード保護に対応するコントロールのユーザ選択により、アプリケーションは、そのファイルを保護する適切なステップを実行することができる（直接的に、またはＯＳへの、もしくは他のアプリケーションへのプログラミングインターフェースを介して）。以下では、ＯＳがこのようなメソッドへの呼び出しを介してアプリケーションを通知できるイベントの実施例を説明する。

・ダイアログは閉じようとしている。
・ユーザが、新しいフォルダにナビゲートした（または、ナビゲートしつつある）。
・ヘルプボタンが押された。
・ユーザビュー選択がなされた。
・ファイル共有違反が発生した。
・ファイルタイプ選択が変更された。
・ユーザが、ファイルの上書き指示した。
・コンボボックス、ラジオボタンのコレクション、またはメニュー内で新しい選択が行われた。
・コマンドボタンが押された。
・チェックボックス状態が変更された。
・ボタン上のドロップダウンメニューが開こうとしている。

本発明を実施する特定の実施例に関して説明されているが、当業者であれば、上述のシステムおよび技術の様々な多くの変更形態および置換があることを理解するであろう。そのような変更形態の１つにすぎないが、ダイアログ内の拡張性領域または他の場所のＵＩコントロールの一部または全部は、キーボードを使用して選択可能である。例えば、ユーザは、タブキーを押して特定のコントロールをハイライト表示し、次いで、「Ｅｎｔｅｒ」キーを押すことによりそのコントロールをアクティブ化することが可能である。他の実施例として、特定のコントロールは、対応するキーの組合せ（例えば、「Ａｌｔ＋Ｓ」）を持つことができる。少なくともいくつかの実施形態では、アプリケーション開発者は、キーボードを介してユーザがダイアログにアクセスする態様を修正することができる。また、与えられたアプリケーションに対するファイルダイアログの複数の同時インスタンスもありうる。本発明のいくつかの実施形態は、さらに、プロセッサにより実行された場合に、メソッドのステップを実行する、および／またはソフトウェアアーキテクチャを実装する命令が記録されているコンピュータ可読媒体も含む。請求項で使用されているように、「を示すデータ」という語句は、他の場所に配置されているデータ、さらには実際のデータそれ自体へのポインタまたは他の参照を含む。

本発明の好ましい実施形態が例示され説明されているが、本発明の趣旨および範囲から逸脱することなく、様々な変更を加えられることは理解されるであろう。例えば、本明細書で示されている様々なＵＩ機能の場所は、例示的であり、変更することができ、また様々なＵＩ機能の異なる配置は、本発明の趣旨および範囲のうちにあることは理解されるであろう。さらに、本明細書で説明されている本発明の異なる態様は、本発明の趣旨および範囲から逸脱することなく、様々な組合せで形成することができる。それに加えて、説明されているプロセスの様々なステップは、本明細書で説明されている機能の選択された部分集合を実装するのに必要に応じて再配列、修正、および／または削除することができる。また、上記において、「本発明」の１つまたは複数の「態様」または「実施形態」に見られるいくつかの機能への参照は、単に、単独でまたは他の概念と組み合わせて使用できる様々な概念を例示するために行われており、本明細書には１つの発明概念しかないこと、または説明されている機能すべてが請求項のいずれかで要求されていることを暗示していると解釈すべきではない。むしろ、請求項のそれぞれは、個々の異なる発明として存在し、記載されている以上の制限を有するものと解釈すべきではない。

なお、本出願は、２００３年５月１６日に出願した同表題の同時係属米国出願第１０／４４０，４３１号の一部継続出願である。

本出願は、２００４年４月２９日に出願した「Metadata Editing Control」という表題の米国仮特許出願第６０／５６６，５０２号の優先権を主張するものであり、参照により本明細書に組み込まれる、２００４年９月２４日に出願した「Metadata Editing Control」という表題の米国特許出願第１０／９５０，０７５号の一部継続出願である。

本出願は、２００３年１０月１２日に出願した「Extensible Creation and Editing of Integrated Collections」という表題の同時係属出願第１０／６８４，２６３号の一部継続出願であり、またその優先権を主張するものである。

本出願は、参照により本明細書に組み込まれる、２００３年３月２４日に出願した「System and Method for User Modification of MetaData in a Shell Browser」という表題の同時係属米国特許出願第１０／３９５，５３３号、および２００３年３月２４日に出願した「Extensible Object Previewer in a Shell Browser」という表題の米国特許出願第１０／３９５，５６０号の一部継続出願である。

本出願は、２００３年５月１６日に出願した米国特許出願第１０／４４０，０３５号の一部継続出願であり、さらにこれは、２００３年３月２７日に出願した米国特許出願第１０／４０３，３４１号の一部継続出願である。

本出願は、２００３年４月１７日に出願した先行米国出願第１０／４２０，０４０号の一部継続出願であり、その内容全体は参照により本明細書に組み込まれる。

本発明を実装するのに好適な汎用コンピュータシステムのブロック図である。本発明による仮想フォルダシステムのブロック図である。選択されたファイルおよびフォルダを引き戻すクエリをユーザが与えるために使用するルーチンを例示する流れ図である。既定のクエリまたはユーザからのクエリのいずれかに従って仮想フォルダが作成され、画面上に表示される際に使用されるルーチンを例示する流れ図である。ハードドライブ上の物理フォルダの整列によるフォルダ構造のツリー図である。仮想フォルダ構造のツリー図である。図６の仮想フォルダ構造のツリー図であり、クライアントスタックは、さらに、コントラクトと年でフィルタ処理されている。図７の仮想フォルダ構造のツリー図であり、クライアントスタックのコントラクトは、さらに、年でフィルタ処理されている。図６の仮想フォルダ構造のツリー図であり、コントラクトスタックは、さらに、クライアントと年でフィルタ処理され、クライアントはその上さらに年でフィルタ処理されている。ドキュメントライブラリのスタックを示す画面表示を例示する図である。図１０のＡＢＣＣｏｒｐ．スタック内のドキュメントを示す画面表示を例示する図である。図１１のドキュメントについてスタック機能が選択されている画面表示を例示する図である。図１２のスタッキング機能について「ｓｔａｃｋｂｙａｕｔｈｏｒ」パラメータが選択されている画面表示を例示する図である。図１３のファイルが作成者別にスタッキングされている画面表示を例示する図である。スタッキング機能が選択され、さらに「ｓｔａｃｋｂｙｃａｔｅｇｏｒｙ」オプションが図１４のファイルの再スタッキングのため選択されている画面表示を例示する図である。図１４のファイルがカテゴリ別に再スタッキングされている画面表示を例示する図である。物理フォルダを示すためのクイックリンクが選択されている画面表示を例示する図である。図１７の仮想フォルダスタックのファイルが格納されている物理フォルダが示されている画面表示を例示する図である。ユーザが仮想フォルダを直接操作するために使用されるルーチンを例示する流れ図である。新しい「ＷｅｓｔＣｏａｓｔ」スタックが図１０のスタックに追加された画面表示を例示する図である。「ＡＢＣＣｏｒｐ．」スタックからファイルを図２０の「ＷｅｓｔＣｏａｓｔ」スタックにコピーするために直接操作が使用されている画面表示を例示する図である。システムが新しいフィルタ条件を動的に生成するためのルーチンを例示する流れ図である。システムがフィルタ条件の選択に基づいてアイテムをフィルタ処理するためのルーチンを例示する流れ図である。図１０のスタックが条件「ＡＢ」によりフィルタ処理された画面表示を例示する図である。図１０のスタックが条件「ＡＢＣ」によりフィルタ処理された画面表示を例示する図である。フィルタ条件「ｙｅａｒ２００２」が図１０のスタックについて選択されている画面表示を例示する図である。図１０のスタックが「ｙｅａｒ２００２」とフィルタ条件「ｍｏｎｔｈ」のさらなる選択とによりフィルタ処理された画面表示を例示する図である。フィルタ処理対象の月を選択するにあたって一覧が表示されている画面表示を例示する図である。図１０のスタックが、１月でフィルタ処理され、さらにフィルタ条件「ｄａｙ」を示すことによりフィルタ処理されている画面表示を例示する図である。新しいクイックリンクを作成するためのルーチンを例示する流れ図である。図２９のフィルタ処理に基づいて「ＪａｎｕａｒｙＷｏｒｋ」という名前の新しいクイックリンクを作成する画面表示を例示する図である。「ＡｌｌＡｕｔｈｏｒｓ」のクイックリンクが選択されている画面表示を例示する図である。図３２の全作成者の一覧が表示されている画面表示を例示する図である。「Ａｕｔｈｏｒ１」が図３３の一覧から選択され、Ａｕｔｈｏｒ１のすべてのドキュメントが表示されている画面表示を例示する図である。新しいライブラリを作成するためのルーチンを例示する流れ図である。様々な使用可能なライブラリのコレクションが表示されている画面表示を例示する図である。仮想フォルダコレクションのスコープを定義するルーチンを例示する流れ図である。仮想フォルダコレクションのスコープを形成しうる様々なソースを例示するブロック図である。仮想フォルダコレクション内に非ファイルアイテムを含めるためのルーチンを例示する流れ図である。仮想フォルダに含まれる様々な非ファイルアイテムを示す画面表示を例示する図である。本発明を実装するのに好適な例示的なネットワークコンピュータ環境の絵図である。従来技術に見られるような、コンピュータファイルシステム内のファイルを表示することに関連付けられている従来のアドレスバーを持つ例示的なファイルビューアを示す絵図である。本発明により形成された仮想アドレスバー内の仮想アドレスに従ってコンピュータファイルシステム内のファイルを表示するための例示的なファイルビューアを示す絵図である。ファイルシステム内をナビゲートするために仮想アドレスバー内の仮想アドレスのセグメントを選択することを示す図５の例示的なファイルビューアの絵図である。仮想アドレスバー内の仮想アドレスのセグメントを選択した結果を示す図４５Ａの例示的なファイルビューアの絵図である。仮想アドレスの１つのセグメントが複数のフィルタを含むコンピュータファイルシステム内のファイルを表示するための明示的なファイルビューアを示す絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられているピアフィルタを選択することを例示する絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられているピアフィルタを選択することを例示する絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられているピアフィルタを選択することを例示する絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられているピアフィルタを選択することを例示する絵図である。追加のフィルタを仮想アドレスバー内の仮想アドレスに加えることを例示する絵図である。追加のフィルタを仮想アドレスバー内の仮想アドレスに加えることを例示する絵図である。追加のフィルタを仮想アドレスバー内の仮想アドレスに加えることを例示する絵図である。追加のフィルタを仮想アドレスバー内の仮想アドレスに加えることを例示する絵図である。仮想アドレスが仮想アドレスバーの表示限度を超えている仮想アドレスを表示する例示的な仮想アドレスバーを示す絵図である。仮想アドレスが仮想アドレスバーの表示限度を超えている仮想アドレスを表示する例示的な仮想アドレスバーを示す絵図である。本発明の一態様によりオーバーフロー状態にある仮想アドレスを表示する例示的な仮想アドレスバーを示す絵図である。フィルタがファイルシステム内の仮想的な場所と実際の場所の両方を参照している仮想アドレスを持つ例示的な仮想アドレスバーを示す絵図である。従来のアドレスバーを表示するように構成されている図４８Ａの例示的な仮想アドレスバーを示す絵図である。仮想アドレスバーにおいて交互フィルタを選択するための交互フィルタ選択ルーチンを示す流れ図である。フィルタを仮想アドレスバー内の仮想アドレスに追加するための例示的なフィルタ追加ルーチンを示す流れ図である。本発明の一実施形態によるエディットコントロールを持つシェルブラウザ用の例示的なグラフィカルユーザインターフェースのブロック図である。本発明の一実施形態による１つまたは複数のエディットコントロールを持つシェルブラウザ用の例示的なグラフィカルユーザインターフェースのブロック図である。シェルブラウザ内のウェルカムペインの概略図である。シェルブラウザ内の選択済みペインの概略図である。本発明の一実施形態によりシェルブラウザ内でユーザがメタデータを修正できるようにするコンテキストメニューを含む図５３の選択済みペインの概略図である。本発明の一実施形態によりシェルブラウザ内でユーザがウェルカムペインに表示されているメタデータを修正できるようにする方法を例示する流れ図である。本発明の一実施形態によりシェルブラウザ内でユーザが選択済みペインに表示されているメタデータを修正できるようにする方法を例示する流れ図である。シェルブラウザ内に表示されるアイテムに関連付けられているユーザ修正可能メタデータを格納するデータ構造体のブロック図である。他の非画像ファイルおよびフォルダを見るために使用されるシェルブラウザ環境内でフォルダに格納されている画像を閲覧するための従来技術のグラフィカルユーザインターフェースの概略図である。シェルブラウザの例示的なグラフィカルユーザインターフェースのブロック図である。シェルブラウザ内のウェルカムペインの概略図である。シェルブラウザ内の選択済みペインの概略図である。本発明の好ましい一態様による、拡張コントロールを備えるシェルブラウザ内の選択済みペインの概略図である。図６１に類似しているが、本発明の一実施形態によりシェルブラウザ内でユーザがプレビューアを選択できるようにするコンテキストメニューを含む、選択済みペインの概略図である。本発明の一実施形態によりシェルブラウザ内でユーザがプレビューアを選択できるようにする方法を例示する流れ図である。本発明の一実施形態によりシェルブラウザ内でシステムがプレビューアを選択できるようにする方法を例示する流れ図である。本発明の一実施形態によりシェルブラウザ内でサードパーティのプレビューアを使用できるようにする方法を例示する流れ図である。シェルブラウザ内の複数のプレビューアを示す情報を格納するデータ構造体のブロック図である。本発明の１つまたは複数の例示的な態様によるスコープ入力コントロールを示す図である。本発明の１つまたは複数の例示的な態様によるスコープ入力コントロールを示す図である。本発明の１つまたは複数の例示的な態様によるスコープ入力コントロールを示す図である。本発明の１つまたは複数の例示的な態様によるスコープ入力コントロールを示す図である。本発明の１つまたは複数の例示的な態様によるスコープ入力コントロールを示す図である。本発明の１つまたは複数の例示的な態様によりスコープを指定する方法を示す図である。本発明の例示的な一実施形態による統合リストペインを備えるエクスプローラフレームを示す図である。本発明の例示的な実施形態によるリストオブジェクトのコンテキストメニューを示す図である。本発明の例示的な一態様によるタスクベースコントロールを持つエクスプローラフレームを示す図である。本発明の例示的な一実施形態による統合タスクベースリストペインを備えるエクスプローラフレームを示す図である。システム上に作成されようとしているファイルのプレビュー表現を含む例示的なＧＵＩビューを表す図である。システム上に作成されようとしているファイルのプレビュー表現を含む他の例示的なＧＵＩビューを表す図である。システム上に作成されようとしているファイルのプレビュー表現を含むＧＵＩビューのさらに２つの実施例を表す図である。システム上に作成されようとしているファイルのプレビュー表現を与える例示的なＳａｖｅＦｉｌｅダイアログを表す図である。システム上に作成されようとしているファイルのプレビュー表現を実装する例示的なプロセスを表す図である。システム上に作成されようとしているファイルのプレビュー表現を実装する例示的なプロセスを表す図である。ブラウザのビュー同士の間の関係を例示する図である。本発明のいくつかの態様による例示的なブラウザインターフェースレイアウトを示す図である。本発明のいくつかの態様による他の例示的なブラウザインターフェースレイアウトを示す図である。本発明のいくつかの態様によるファイルを閲覧するための例示的なプロセスを示す図である。本発明のいくつかの態様を実装するために使用することができるデータ構造体、アプリケーション、および／またはサブルーチンの間の例示的な論理的関係を示す図である。本発明の少なくともいくつかの実施例による、許可される、および許可されない階層的プロパティ経路のいくつかの実施例を示す図である。本発明の少なくともいくつかの実施例による、許可される、および許可されない階層的プロパティ経路のいくつかの実施例を示す図である。本発明のいくつかの実施例による、関連する階層的プロパティを持つ新しいアイテム（例えば、ファイル）を保存するためのユーザインターフェースの一実施例を示す図である。本発明のいくつかの実施例による、格納されているアイテム（例えば、デジタル画像ファイル）に関係する情報を含む例示的な「プレビューパネル」を示す図である。本発明の一実施例による階層的プロパティの階層的整列を変更する操作の一実施例を示す図である。本発明のいくつかの実施例による、ナビゲーションパネルを備える例示的なユーザインターフェースを示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作中に使用することができる異なるスコープのいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作中に使用することができる異なるスコープのいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作における複数のプロパティまたは他の情報の選択時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明のいくつかの実施例によるナビゲーションおよび表示操作におけるいくつかのアイテム（例えば、電子ファイル）のグループ化、スタッキング、およびフィルタ処理時のユーザインターフェース、ディスプレイ、および操作のいくつかの実施例を示す図である。本発明の例示的な実施形態による多重ルートナビゲーションペインを実装するシェルブラウザウィンドウの部分スクリーンショットを示す図である。本発明の例示的な実施形態による多重ルートナビゲーションペインを示す図である。本発明の例示的な一実施形態によりナビゲーションペインをカスタマイズする方法を示す図である。本発明の例示的な一実施形態により多重ルートナビゲーションペイン内のページノードを並べ替える方法を示す図である。本発明の例示的な一実施形態によりナビゲーションペインをカスタマイズするための構成ダイアログを示す図である。本発明の一実施形態によるページノードプロパティ構成ダイアログを示す図である。本発明の例示的な一実施形態による不可視ルートを持つ多重ルートナビゲーションペインを示す図である。本明細書で説明されている機能を使用することができるプロセスの例示的な流れ図である。本明細書で説明されている機能を使用することができるプロセスの例示的な流れ図である。例示的なファイルブラウザのユーザインターフェースおよび様々なユーザインターフェース要素を示す図である。プレビュー領域のサイズが変更されている、図１１８のインターフェースの修正版を示す図である。プレビュー領域のサイズが変更されている、図１１８のインターフェースの他の修正版を示す図である。プレビュー要素の向きが異なる代替えのブラウザインターフェースを示す図である。プレビューインターフェースを含む共通ファイルダイアログの一実施例を示す図である。スタッキングされたプレビュー表示の一実施例を示す図である。図１２３に示されている実施例よりも多いスタッキングされたプレビューを持つ、スタッキングされたプレビュー表示の他の実施例を示す図である。複数のファイルが選択された場合に出現するプレビューの一実施例を示す図である。複数のファイルが選択され、対応するプロパティおよびファイルを視覚的に区別できる、例示的なブラウザを示す図である。複数のファイルが選択され、集約されたプロパティフィールドを持つ、例示的なブラウザを示す図である。プロパティを１つまたは複数の選択されたファイルと相関させる視覚的に区別できる、集約されたプロパティフィールドの一実施例を示す図である。複数の選択された多値プロパティにおいて値を集計することができる例示的なプロセスを示す図である。複数の選択された多値プロパティにおいて値を集計することができる例示的なプロセスを示す図である。多値プロパティフィールドの一実施例を示す図である。自動選択機能の例示的なプロセスを示す図である。オートコンプリート機能を持つ多値プロパティフィールドの一実施例を示す図である。オートコンプリート機能の例示的なプロセスを示す図である。本発明のいくつかの態様により仮想アドレスバーにおいて子フィルタを選択するための子フィルタ選択ルーチンを示す流れ図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられている子フィルタを選択することを例示する絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられている子フィルタを選択することを例示する絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられている子フィルタを選択することを例示する絵図である。仮想アドレスバー内の仮想アドレスのセグメントに関連付けられている子フィルタを選択することを例示する絵図である。ウィンドウペインに表示されている従来の技術のフォルダツリーコントロールを示す図である。本発明の様々な例示的な態様により実装された階層的ツリーコントロール構造のビューを示す図である。本発明の様々な例示的な態様により実装されたフォルダツリーコントロールのスクリーンショットを示す図である。本発明の様々な例示的な態様により実装されたフォルダツリーコントロールのスクリーンショットを示す図である。本発明の様々な例示的な実施形態によりコンテンツ内をナビゲートするユーザに対し表示するコンテンツを提供する方法を説明する流れ図である。従来のオペレーティングシステムにおけるグループ化を持つ詳細ビューを示す図である。本発明のいくつかの態様により詳細ビュー内にプロパティコントロールを含むプロパティヘッダを示す図である。本発明のいくつかの態様による詳細ビュー内のプロパティヘッダの分割ボタンプロパティコントロールを示す図である。本発明のいくつかの態様による詳細ビュー内のプロパティヘッダのプロパティコントロールのａｒｒａｎｇｅａｎｄｆｉｌｔｅｒドロップダウンメニューを示す図である。本発明のいくつかの態様によるａｒｒａｎｇｅａｎｄｆｉｌｔｅｒドロップダウンメニューのフィルタ部分の一部を示す図である。本発明のいくつかの態様により詳細ビュー以外のビュー内にプロパティコントロールを含むプロパティヘッダを示す図である。本発明のいくつかの態様による詳細ビュー以外のビュー内のプロパティヘッダのプロパティコントロールのａｒｒａｎｇｅａｎｄｆｉｌｔｅｒドロップダウンメニューを示す図である。本発明のいくつかの態様により詳細ビュー以外のビュー内にプロパティヘッダの複数のプロパティコントロールのうちの１つによりビューがフィルタ処理されたプロパティヘッダを示す図である。本発明のいくつかの態様によるビュー内のオーバーフロープロパティコントロールのａｒｒａｎｇｅａｎｄｆｉｌｔｅｒドロップダウンメニューを示す図である。本発明のいくつかの態様によるカレンダーコントロールを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の１つまたは複数の実施形態を実装することができる、汎用コンピュータ環境における、プログラミングインターフェースを示す図である。本発明の少なくともいくつかの実施形態による「ＯｐｅｎＦｉｌｅ」ダイアログの実施例の図である。本発明の少なくともいくつかの実施形態による「ＯｐｅｎＦｉｌｅ」ダイアログの実施例の図である。本発明の少なくともいくつかの実施形態による「ＳａｖｅＦｉｌｅ」ダイアログの実施例の図である。本発明の少なくともいくつかの実施形態による「ＳａｖｅＦｉｌｅ」ダイアログの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によりファイルダイアログに追加することができる追加のユーザインターフェース（ＵＩ）コントロールの実施例の図である。本発明の少なくともいくつかの実施形態によるＵＩコントロールの自動整列を示す図である。本発明の少なくともいくつかの実施形態によるＵＩコントロールの自動整列を示す図である。アプリケーション側が本発明のいくつかの実施形態によるファイルダイアログの生成を要求する方法とファイルダイアログが従来の技術で要求される方法との違いの概略を示すブロック図である。アプリケーション側が本発明のいくつかの実施形態によるファイルダイアログの生成を要求する方法とファイルダイアログが従来の技術で要求される方法との違いの概略を示すブロック図である。

Claims

１つまたは複数のコンピュータ可読媒体上に格納されたコンピュータ実行可能命令により定められたファイルシステムシェルブラウザであって、複数のデータアイテムを管理するためにユーザによりナビゲート可能であり、
共通メタデータを持つデータアイテムの第１の集合を識別するために前記ユーザによりナビゲート可能なページ空間コントロールと、
データアイテムの前記第１の集合の仮想的な場所を識別する仮想アドレスバーと、
データアイテムの前記第１の集合の第１の表示を示すリストペインと、
データアイテムの前記第１の集合の、ユーザ選択されたアイテムに対応する情報を表示するプレビューペインと
を備えることを特徴とするファイルシステムシェルブラウザ。
前記ページ空間コントロールは、メタデータ値の階層ツリーを含むことを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
前記仮想アドレスバーは、複数の階層要素を含み、それぞれの要素は、ユーザによって選択された場合、ユーザにより選択可能な、階層的に同等のメタデータ値のリストを表示することを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
前記ユーザが前記階層的に同等のメタデータ値のうちの１つを選択する場合に、前記リストペインは、前記階層的に同等のメタデータ値のうちの前記１つに対応するデータアイテムの第２の集合の第２の表示を与えることを特徴とする請求項３に記載のファイルシステムシェルブラウザ。
前記リストペインは、前記１つのデータアイテムに対応する多数の他のデータアイテムを示すアイコン形式でデータアイテムの前記第１の集合のうちの１つのデータアイテムを表示することを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
前記アイコン形式は、高さが前記１つのデータアイテムに対応する他のデータアイテムの個数に基づくスタックを含むことを特徴とする請求項５に記載のファイルシステムシェルブラウザ。
前記階層ツリーの１つのノードは、自動リストを表し、前記自動リストは記憶場所のスコープとメタデータ値の１つまたは複数の基準により定められることを特徴とする請求項２に記載のファイルシステムシェルブラウザ。
前記リストペイン内のデータアイテムの前記第１の集合のプレゼンテーションスタイルを選択するために、前記ユーザにより選択的に変更可能なリストビュースライダーをさらに備えることを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
前記リストビュースライダーは、アイコンプレゼンテーションスタイルおよびリストプレゼンテーションスタイルを含む、プリセットされたプレゼンテーションスタイルを含むことを特徴とする請求項８に記載のファイルシステムシェルブラウザ。
自動リストビルダーをさらに備え、ユーザは、１つまたは複数の明示的な包含および１つまたは複数の明示的な除外を含む自動リストスコープを定義することを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
ユーザが静的リストを構築できるようにする機能を公開するリストビルダーをさらに備えることを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
前記ページ空間コントロールは、前記ページ空間コントロールをユーザが縦スクロールすることに基づき、動的に横スクロールするように構成されていることを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
ユーザがデータアイテムの前記第１の集合内の前記アイテムのどれかを選択した場合に、前記ファイルシステムシェルブラウザが前記選択されたアイテムに対応する起動活動を実行することを特徴とする請求項１に記載のファイルシステムシェルブラウザ。
データ処理デバイスのオペレーティングシステム内で実行可能なユーザナビゲート可能ファイルシステムシェルブラウザを実現するコンピュータ実行可能命令を格納する１つまたは複数のコンピュータ可読媒体であって、前記ファイルシステムシェルブラウザは、
メタデータプロパティとプロパティ値の階層ツリーを表示する第１のペインと、
仮想的な記憶場所を識別するメタデータ値の順序リストを表示する、前記第１のペインから選択されたプロパティ値を反映する、第２のペインと、
前記仮想的な記憶場所に対応するデータアイテムの第１の集合の表示を与える第３のペインと
を備えることを特徴とするコンピュータ可読媒体。
前記ファイルシステムシェルブラウザは、データアイテムの前記第１の集合のユーザ選択されたアイテムに対応する情報を表示するプレビューペインをさらに備えることを特徴とする請求項１４に記載のコンピュータ可読媒体。
前記第２のペイン内のそれぞれのメタデータ値は、ユーザにより選択可能な、階層的に同等のメタデータ値のリストに対応し、前記ユーザが前記階層的に同等のメタデータ値のうちの１つを選択した場合に、前記第３のペインは、前記選択された仮想的な記憶場所に対応するデータアイテムの第２の集合の表示を与えることを特徴とする請求項１４に記載のコンピュータ可読媒体。
前記階層ツリーのノードは、仮想フォルダを表し、前記仮想フォルダは記憶場所のスコープおよびメタデータ値の１つまたは複数の基準により定義され、前記仮想フォルダは、前記スコープ内で格納され、前記１つまたは複数の基準に一致する全アイテムに対応することを特徴とする請求項１４に記載のコンピュータ可読媒体。
前記ファイルシステムシェルブラウザは、前記リストペイン内のデータアイテムの前記第１の集合のプレゼンテーションスタイルを選択するために、前記ユーザにより選択的に変更可能なリストビュースライダーをさらに備えることを特徴とする請求項１４に記載のコンピュータ可読媒体。
前記ファイルシステムシェルブラウザは、仮想フォルダビルダーをさらに備え、ユーザは、１つまたは複数の明示的な包含および１つまたは複数の明示的な除外を含む仮想フォルダスコープを定義することを特徴とする請求項１４に記載のコンピュータ可読媒体。
前記ファイルシステムシェルブラウザは、ユーザが静的リストを構築できるようにする機能を公開するリストビルダーをさらに備えることを特徴とする請求項１４に記載のコンピュータ可読媒体。
前記第１のペインは、ユーザが前記階層ツリーを縦スクロールすることに基づき、動的に横スクロールするように構成されていることを特徴とする請求項１４に記載のコンピュータ可読媒体。
ユーザがデータアイテムの前記第１の集合内の前記アイテムのどれかを選択した場合に、前記ファイルシステムシェルブラウザは、前記選択されたアイテムに対応する起動活動を実行することを特徴とする請求項１４に記載のコンピュータ可読媒体。
１つまたは複数のコンピュータ可読媒体上にコンピュータ実行可能命令として格納されるユーザインターフェースであって、前記ユーザインターフェースはファイルシステムシェルブラウザに対応し、前記ユーザインターフェースは、
互いに対応して表示される３つまたはそれ以上の機能モジュールを備え、前記機能モジュールは、
選択されたメタデータ値を識別するためにユーザによりナビゲート可能なメタデータプロパティの階層ツリーを備えるページ空間コントロールモジュールと、
前記選択されたメタデータ値に対応するデータアイテムの第１の集合の仮想的な場所を識別する仮想アドレスバーモジュールと、
ユーザがリストペインモジュール内のデータアイテムの前記第１の集合のプレゼンテーションスタイルを選択できるように、選択的に変更可能な表示要素を備えるリストビュースライダーモジュールと、
１つまたは複数の明示的に包含される記憶場所および１つまたは複数の明示的に除外された記憶場所を含む自動リストスコープをユーザが定義するための機能を公開する自動リストビルダーモジュールと、
前記ユーザが静的リストを構築するための機能を公開するリストビルダーモジュールと
の集合から選択されることを特徴とするユーザインターフェース。
前記３つまたはそれ以上の機能モジュールのうちの１つは、前記仮想アドレスバーモジュールであり、前記仮想的な場所は、メタデータ値の順序リストとして表示されることを特徴とする請求項２３に記載のユーザインターフェース。
前記順序リスト内のそれぞれのメタデータ値は、前記リストペインモジュール内の要素の表示を変更するために、ユーザにより選択可能な階層的に同等のメタデータ値のリストに対応することを特徴とする請求項２４に記載のユーザインターフェース。
前記３つまたはそれ以上の機能モジュールのうちの１つは、前記ページ空間コントロールモジュールであり、
前記３つまたはそれ以上の機能モジュールのうちのもう１つは、前記自動リストビルダーモジュールであり、
前記階層ツリーの第１のノードは、自動リストを表し、前記自動リストは前記自動リストスコープ内に格納されているすべてのアイテムに対応し、１つまたは複数のユーザ指定メタデータ基準に一致することを特徴とする請求項２３に記載のユーザインターフェース。
前記３つまたはそれ以上の機能モジュールのうちの１つは、前記ページ空間コントロールモジュールであり、前記ページ空間コントロールモジュールは、ユーザが前記階層ツリーを縦スクロールすることに基づき、動的に横スクロールするように構成されることを特徴とする請求項２３に記載のユーザインターフェース。
前記リストペインモジュールは、前記１つのデータアイテムに対応する多数の他のデータアイテムを示すアイコン形式で、データアイテムの前記第１の集合のうちの１つのデータアイテムを表示することを特徴とする請求項２３に記載のユーザインターフェース。
前記アイコン形式は、高さが前記１つのデータアイテムに対応する他のデータアイテムの個数に基づくスタックを含むことを特徴とする請求項２８に記載のユーザインターフェース。
前記３つまたはそれ以上の機能モジュールのうちの１つは、前記リストビュースライダーモジュールであり、前記選択的に変更可能な表示要素は、アイコンプレゼンテーションスタイルおよびリストプレゼンテーションスタイルを含む、プリセットされたプレゼンテーションスタイルを含むことを特徴とする請求項２３に記載のユーザインターフェース。
ユーザが前記リストペインモジュールに表示されているアイテムを選択した場合に、前記ファイルシステムシェルブラウザは、前記選択されたアイテムに対応する起動活動を実行することを特徴とする請求項２３に記載のユーザインターフェース。