コンピュータプラットフォームのプログラミングインターフェース
【課題】．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋの効率および／または性能を高める形を提供する。
【解決手段】コンピュータプラットフォームのプログラミングインターフェースに、さまざまな機能性を含めることができる。ある実施形態で、プログラミングインターフェースに、再利用可能なユーザインターフェースコントロールに関連するサービスの第１群と、ユーザインターフェースダイアログおよびユーザインターフェースウィザードに関連するサービスの第２群と、ユーザインターフェース機能性の拡張に関連するサービスの第３群と、ユーザインターフェースのデスクトップの機能性の拡張に関連するサービスの第４群との１つまたは複数が含まれる。
【解決手段】コンピュータプラットフォームのプログラミングインターフェースに、さまざまな機能性を含めることができる。ある実施形態で、プログラミングインターフェースに、再利用可能なユーザインターフェースコントロールに関連するサービスの第１群と、ユーザインターフェースダイアログおよびユーザインターフェースウィザードに関連するサービスの第２群と、ユーザインターフェース機能性の拡張に関連するサービスの第３群と、ユーザインターフェースのデスクトップの機能性の拡張に関連するサービスの第４群との１つまたは複数が含まれる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアおよびそのようなソフトウェアの開発に関する。より詳細には、アプリケーションプログラムおよびコンピュータハードウェアによる、ソフトウェアプラットフォームの使用を容易にするプログラミングインターフェースに関する。
【背景技術】
【０００２】
非常に早くから、コンピュータソフトウェアは、「オペレーティングシステム」ソフトウェアまたは「アプリケーション」ソフトウェアとして分類されるようになった。おおまかにいって、アプリケーションは、数学の方程式を解くか、またはワードプロセッシングをサポートするなど、コンピュータユーザのために特定のタスクを実行することを意図されたソフトウェアである。オペレーティングシステムは、コンピュータハードウェアを管理し、制御するソフトウェアである。オペレーティングシステムの目標は、コンピュータリソースをアプリケーションプログラマが使用可能にすると同時に、ハードウェアを実際に制御するのに必要な複雑さを隠蔽することである。
【０００３】
オペレーティングシステムは、アプリケーションプログラムインターフェースまたはＡＰＩとして周知の機能または関数を介してリソースを使用可能にする。用語ＡＰＩは、これらの機能のうちの単一の関数を指すのにも使用される。関数は、多くの場合、アプリケーションプログラマに提供するリソースまたはサービスに関してグループ化される。アプリケーションソフトウェアは、個々のＡＰＩ関数を呼び出すことによってリソースを要求する。ＡＰＩ関数は、オペレーティングシステムによって提供されるメッセージおよび情報をアプリケーションソフトウェアに中継する手段としても働く。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願第０９／５９８，１０５号明細書
【特許文献２】米国特許出願第０９／６１３，２８９号明細書
【特許文献３】米国特許出願第１０／０６３，２９６号明細書
【特許文献４】米国特許出願第１０／４０２，１７９号明細書
【特許文献５】米国特許出願第１０／３２４，７４６号明細書
【非特許文献】
【０００５】
【非特許文献１】［online］、ＥＣＭＡ、〈URL:www.ecma.ch〉
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ハードウェアの変更のほかに、オペレーティングシステムソフトウェアの進化を駆り立てるもう１つの要因が、アプリケーションソフトウェア開発を単純化し、加速する要望である。アプリケーションソフトウェア開発は、困難な作業になる場合があり、時折、数百万行のコードによって高度化されたプログラムを作成するために数年の開発者の時間を必要とする。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのさまざまなバージョンなどの広く使用されているオペレーティングシステムに関して、アプリケーションソフトウェア開発者は、そのオペレーティングシステムを利用する数千本の異なるアプリケーションを毎年記述している。そのように多くの異なるアプリケーション開発者をサポートするために、一貫性のある（coherent）、利便性の高いオペレーティングシステムベースが必要である。
【０００７】
多くの場合、オペレーティングシステムをより複雑にすることによって、アプリケーションソフトウェアの開発を単純にすることができる。すなわち、ある機能が、複数の異なるアプリケーションプログラムに有用であり得る場合に、その機能をオペレーティングシステムに含めるために一度記述することが、数十人のソフトウェア開発者が数十本の異なるアプリケーションに含めるために数十回記述することを要求するよりよい場合がある。このように、オペレーティングシステムが、複数のアプリケーションによって要求される広範囲の共通の機能性をサポートする場合、アプリケーションソフトウェア開発のコストおよび時間においてかなりの節約を達成することができる。
【０００８】
オペレーティングシステムとアプリケーションソフトウェアの間のどこに線が引かれるかに関係なく、有用なオペレーティングシステムについて、オペレーティングシステムおよびコンピュータハードウェアとアプリケーションソフトウェアとの間のＡＰＩは、オペレーティングシステム自体の効率的な内部動作と同様に重要であることは明白である。
【０００９】
過去数年間に、インターネットおよびネットワーク技術全般の万国での採用によって、コンピュータソフトウェア開発者の情景が変化した。従来、ソフトウェア開発者は、独立型デスクトップコンピュータまたはローカルエリアネットワーク（ＬＡＮ）を介して、限られた数の他のコンピュータに接続されたＬＡＮベースコンピュータの単一サイトソフトウェアアプリケーションに焦点を合わせていた。ソフトウェアが、シュリンクラップパッケージでマーケティングされ、販売されたので、そのようなソフトウェアアプリケーションを、通常は、「シュリンクラップ」製品と称する。これらのアプリケーションは、明確に定義されたＡＰＩを使用して、コンピュータの基礎になるオペレーティングシステムにアクセスした。
【００１０】
インターネットが進化し、広く受け入れられたので、産業界は、ワールドワイドウェブ（または単に「ウェブ」）のさまざまなサイトでのアプリケーションのホスティングの威力を理解し始めた。ネットワーク化された世界では、あらゆる場所のクライアントが、個別の位置でホスティングされるサーバベースのアプリケーションに要求をサブミットし、数分の１秒で応答を受信することができる。しかし、これらのウェブアプリケーションは、通常は、元々は独立型コンピューティングマシンまたはローカルにネットワーク化されたコンピュータのために開発されたものと同一のオペレーティングシステムプラットフォームを使用して開発された。残念ながら、いくつかの場合に、これらのアプリケーションは、分散コンピューティング管理様式に適切に移行されていない。基礎になるプラットフォームは、単純に、無制限の数の相互接続されたコンピュータをサポートするという観念を用いて構成されていなかった。
【００１１】
インターネットによって導入された分散コンピューティング環境へのシフトに対処するために、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎは、「．ＮＥＴ」Ｆｒａｍｅｗｏｒｋ（「ドットネット」と読む）またはＭｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴと称するネットワークソフトウェアプラットフォームを開発した。Ｍｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴは、人、情報、システム、および装置を接続するソフトウェアである。このプラットフォームを用いると、開発者が、インターネットを介して実行されるウェブサービス（Ｗｅｂ ｓｅｒｖｉｃｅ）を作成できるようになる。この動的なシフトは、Ｍｉｃｒｏｓｏｆｔの．ＮＥＴ（商標）ＦｒａｍｅｗｏｒｋのＡＰＩ関数のセットによって達成された。
【００１２】
．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋの使用がますます一般的になるにつれて、このプラットフォームの効率および／または性能を高める形が特定された。本発明人は、そのような高められた効率および／または性能を可能にするプログラミングインターフェース関数の独自のセットを開発した。
【課題を解決するための手段】
【００１３】
コンピュータプラットフォームのプログラミングインターフェースを本明細書で説明する。
【００１４】
ある態様によれば、プログラミングインターフェースに、再利用可能なユーザインターフェースコントロールに関連するサービスの第１群と、ユーザインターフェースダイアログおよびユーザインターフェースウィザードに関連するサービスの第２群と、ユーザインターフェース機能性の拡張に関連するサービスの第３群と、ユーザインターフェースのデスクトップの機能性の拡張に関連するサービスの第４群との１つまたは複数を含めることができる。
【００１５】
同一の符号は、複数の図面を通じて同一の特徴を指すのに使用される。
【図面の簡単な説明】
【００１６】
【図１】クライアントが、従来のプロトコルを使用するインターネットを介してウェブサービスにアクセスする、ネットワークアーキテクチャを示す図である。
【図２】アプリケーションプログラムインターフェース（ＡＰＩ）を含むネットワークプラットフォームのソフトウェアアーキテクチャを示すブロック図である。
【図３】ＡＰＩによってサポートされる独自の名前空間ならびにさまざまなＡＰＩ関数の機能クラスを示すブロック図である。
【図４】ソフトウェアアーキテクチャのすべてまたは一部を実行することができる例示的コンピュータを示すブロック図である。
【図５】プログラミングインターフェースの例の実施形態を示す図である。
【図６】プログラミングインターフェースの例の実施形態を示す図である。
【図７】プログラミングインターフェースの例の実施形態を示す図である。
【図８】プログラミングインターフェースの例の実施形態を示す図である。
【図９】プログラミングインターフェースの例の実施形態を示す図である。
【図１０】プログラミングインターフェースの例の実施形態を示す図である。
【図１１】プログラミングインターフェースの例の実施形態を示す図である。
【図１２】プログラミングインターフェースの例の実施形態を示す図である。
【図１３】プログラミングインターフェースの例の実施形態を示す図である。
【図１４】プログラミングインターフェースの例の実施形態を示す図である。
【図１５】プログラミングインターフェースの例の実施形態を示す図である。
【図１６】プログラミングインターフェースの例の実施形態を示す図である。
【発明を実施するための形態】
【００１７】
この開示は、開発者がウェブアプリケーションおよびウェブサービスを構築できるネットワークプラットフォームのアプリケーションプログラムインターフェース（ＡＰＩ）などのプログラミングインターフェースを扱う。具体的に言うと、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって作成された．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋなどのネットワークプラットフォームを利用するオペレーティングシステムの例示的ＡＰＩを説明する。．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋは、分散コンピューティング環境で実施されるウェブサービスおよびウェブアプリケーションのソフトウェアプラットフォームである。．ＮＥＴ Ｆｒａｍｅｗｏｒｋは、特定のタスクを実行するために協力している疎結合ウェブサービスの間の通信にオープン通信標準規格（open communication standards）を使用する、次世代のインターネットコンピューティングを表す。
【００１８】
説明する実施形態で、ネットワークプラットフォームは、ＸＭＬ（extensible markup language）すなわちデータを記述するオープン標準規格を使用する。ＸＭＬは、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって管理される。ＸＭＬは、ウェブページおよび企業間文書のデータ要素を定義するのに使用される。ＸＭＬでは、ＨＴＭＬに類似するタグ構造が使用されるが、ＨＴＭＬは、要素をどのように表示するかを定義し、ＸＭＬは、それらの要素に何が含まれるかを定義する。ＨＴＭＬでは、予め定義されたタグを使用するが、ＸＭＬでは、ページの開発者がタグを定義することができる。したがって、事実上任意のデータアイテムを識別することができ、ウェブページが、データベースレコードのように機能することができる。ＸＭＬおよびシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）などの他のオープンプロトコルの使用を介して、ネットワークプラットフォームが、ユーザの必要に合わせて調整できる広範囲のサービスの統合を可能にする。本明細書に記載の実施形態を、ＸＭＬおよび他のオープン標準規格と共に説明するが、これは、請求される発明の動作に必要ではない。他の同等に実行可能な技術が、本明細書に記載の発明を実施するのに十分である。
【００１９】
本明細書で使用される句、アプリケーションプログラムインターフェースまたはＡＰＩには、メソッド呼出しまたは関数呼出しを使用する従来のインターフェースならびに、リモート呼出し（たとえばプロキシ、スタブ関係）およびＳＯＡＰ／ＸＭＬ呼出しが含まれる。
【００２０】
（例示的ネットワーク環境）
図１に、．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋなどのネットワークプラットフォームを実装できるネットワーク環境１００を示す。ネットワーク環境１００には、ネットワーク１０４（たとえばインターネット）上でアクセスできるサービスを提供する、代表的なウェブサーバ１０２（１）、…、１０２（Ｎ）が含まれる。一般に符号１０２として参照されるウェブサービスは、リモートプロシージャコール（ＲＰＣ）またはオブジェクトブローカ型技術などの、ネットワークを介してウェブサービスと相互作用する他の手段も使用することができるが、通常は、ＸＭＬ、ＳＯＡＰ、ＷＡＰ（wireless application protocol）、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、およびＳＭＴＰ（シンプルメール転送プロトコル）などの産業界標準ウェブプロトコルを介してネットワーク１０４上でプログラム的に相互作用する、再利用可能なプログラマブルアプリケーションコンポーネントである。ウェブサービスは、自己記述的とすることができ、しばしば、メッセージのフォーマットおよび順序に関して定義される。
【００２１】
ウェブサービス１０２は、他のサービス（通信リンク１０６によって表されるように）、またはウェブアプリケーション１１０などのソフトウェアアプリケーション（通信リンク１１２および１１４によって表されるように）によって直接にアクセス可能である。各ウェブサービス１０２は、特定のサービスに関する要求を処理するソフトウェアを実行する１つまたは複数のサーバを含むものとして示されている。そのようなサービスは、しばしば、要求元にサービスされる情報を保管するデータベースを維持する。ウェブサービスを構成して、さまざまな異なるサービスの任意の１つを実行することができる。ウェブサービスの例に、ログイン検証、通知、データベース保管、株式市況、ディレクトリの突き止め、地図作成、音楽、電子ウォレット、カレンダ／スケジューラ、電話リスティング、ニュースおよび情報、ゲーム、発券業務などが含まれる。ウェブサービスを、互いにおよび他のアプリケーションと組み合わせて、インテリジェント対話経験を構築することができる。
【００２２】
ネットワーク環境１００には、ウェブサービス１０２（通信リンク１２２によって表される）および／またはウェブアプリケーション１１０（通信リンク１２４、１２６、および１２８によって表される）を使用する代表的なクライアント装置１２０（１）、１２０（２）、１２０（３）、１２０（４）、…、１２０（Ｍ）も含まれる。クライアントは、クライアント１２０（３）と１２０（４）の間の例示的なＸＭＬリンク１２９によって表されるように、標準プロトコルを使用して互いに通信することもできる。
【００２３】
全般的に符号１２０として参照されるクライアント装置は、多数の異なる形で実施することができる。可能なクライアント実施形態の例に、制限なしに、ポータブルコンピュータ、ステーショナリコンピュータ、タブレットＰＣ、テレビジョン／セットトップボックス、無線通信装置、携帯情報端末、ゲーム機、プリンタ、コピー機、および他のスマート装置が含まれる。
【００２４】
ウェブアプリケーション１１０は、ネットワークプラットフォームで動作するように設計されたアプリケーションであり、クライアント１２０からの要求を処理し、サービスするときに、ウェブサービス１０２を使用することができる。ウェブアプリケーション１１０は、プログラミングフレームワーク１３２上で稼動する１つまたは複数のソフトウェアアプリケーション１３０からなり、ソフトウェアアプリケーション１３０は、１つまたは複数のサーバ１３４または他のコンピュータシステムで実行されている。ウェブアプリケーション１１０の一部が、実際には１つまたは複数のクライアント１２０に常駐する場合があることに留意されたい。その代わりに、ウェブアプリケーション１１０が、実際にタスクを達成するクライアント１２０上の他のソフトウェアを調整することができる。
【００２５】
プログラミングフレームワーク１３２は、アプリケーション開発者によって開発されるアプリケーションおよびサービスをサポートする構造である。プログラミングフレームワーク１３２は、複数の言語をサポートすることによって、マルチ言語開発およびシームレス統合を可能にする。プログラミングフレームワーク１３２は、ＳＯＡＰなどのオープンプロトコルをサポートし、基礎になるオペレーティングシステムサービスおよびオブジェクトモデルサービスをカプセル化する。このフレームワークは、複数のプログラミング言語の堅牢で保護された実行環境を提供し、保護され、統合されたクラスライブラリを提供する。
【００２６】
フレームワーク１３２は、アプリケーションプログラムインターフェース（ＡＰＩ）レイヤ１４２、共通言語ランタイム（ＣＬＲ）レイヤ１４４、およびオペレーティングシステム／サービスレイヤ１４６を含むマルチティアアーキテクチャである。この階層アーキテクチャを用いると、フレームワークの他の部分に影響せずに、さまざまなレイヤに対する更新および修正が可能になる。共通言語仕様（ＣＬＳ）１４０を用いると、さまざまな言語の設計者が、基礎になるライブラリ機能性にアクセスできるコードを記述できるようになる。共通言語仕様１４０は、言語設計者とライブラリ設計者の間の、言語インターオペラビリティを促進するのに使用できるコントラクトとして機能する。ＣＬＳを厳守することによって、ある言語で記述されたライブラリは、別の言語で記述されたコードモジュールから直接にアクセスでき、ある言語で記述されたコードモジュールと別の言語で記述されたコードモジュールの間のシームレスな統合を達成することができる。ＣＬＳの１つの例示的な詳細な実施形態が、ＥＣＭＡ ＴＣ３９／ＴＧ３の参加者によって作成されたＥＣＭＡ標準規格である。非特許文献１を参照されたい。
【００２７】
ＡＰＩレイヤ１４２は、アプリケーション１３０が、レイヤ１４６によって提供されるリソースおよびサービスにアクセスするために呼び出す関数のグループを提供する。ネットワークプラットフォームに対するＡＰＩ関数を公開することによって、アプリケーション開発者は、ネットワークリソースが実際にどのように動作するかまたは使用可能にされるかの複雑な相互作用を理解する必要なしに、ネットワークリソースおよび他のウェブサービスを完全に利用する分散コンピューティングシステム用のウェブアプリケーションを作成することができる。さらに、ウェブアプリケーションを、任意の数のプログラミング言語で記述でき、共通言語ランタイムレイヤ１４４によってサポートされ、共通言語仕様１４０の一部として含まれる中間言語に変換することができる。この形で、ＡＰＩレイヤ１４２が、広範囲のさまざまなアプリケーションにメソッドを提供することができる。
【００２８】
さらに、フレームワーク１３２を、フレームワークをホスティングするサーバ１３４からリモートに実行されるリモートアプリケーションによって設定される、ＡＰＩ呼出しをサポートするように構成することができる。それぞれクライアント１２０（３）および１２０（Ｍ）に常駐する代表的なアプリケーション１４８（１）および１４８（２）は、直接的にまたは間接的に、ネットワーク１０４上でＡＰＩレイヤ１４２への呼出しを行うことによって、ＡＰＩ関数を使用することができる。
【００２９】
このフレームワークを、クライアントで実施することもできる。クライアント１２０（３）は、フレームワーク１５０がクライアントで実施される情況を表す。このフレームワークは、サーバベースのフレームワーク１３２と同一とするか、クライアント用に修正することができる。その代わりに、クライアントが、携帯電話、携帯情報端末、ハンドヘルドコンピュータ、または他の通信／コンピューティング装置などの制限付きまたは専用機能の装置である場合に、クライアントベースフレームワークを圧縮することができる。
【００３０】
（開発者のプログラミングフレームワーク）
図２に、プログラミングフレームワーク１３２を詳細に示す。共通言語仕様（ＣＬＳ）レイヤ１４０は、さまざまな言語１３０（１）、１３０（２）、１３０（３）、１３０（４）、…、１３０（Ｋ）で記述されたアプリケーションをサポートする。そのようなアプリケーション言語に、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ＋＋、Ｃ＃、ＣＯＢＯＬ、Ｊｓｃｒｉｐｔ、Ｐｅｒｌ、Ｅｉｆｆｅｌ、Ｐｙｔｈｏｎなどが含まれる。共通言語仕様１４０は、それに従う場合にさまざまな言語が通信できるようなる特徴のまたは特徴に関するルールのサブセットを指定する。たとえば、いくつかの言語は、共通言語ランタイム１４４によってサポートされる可能性がある所与の型（たとえば、「ｉｎｔ＊」型）をサポートしない。この場合に、共通言語仕様１４０に、その型が含まれない。その一方で、すべてまたはほとんどの言語によってサポートされる型（たとえば、「ｉｎｔ［］」型）は、共通言語仕様１４０に含まれ、したがって、ライブラリ開発者は、それを使用することができ、言語がそれを処理できることが保証される。この通信の能力は、ある言語で記述されたコードモジュールと別の言語で記述されたコードモジュールの間のシームレスな統合をもたらす。異なる言語が、特定のタスクに特によく適するので、言語の間のシームレスな統合によって、開発者が、特定のコードモジュールに対し特定の言語を選択でき、そのコードモジュールを異なる言語で記述されたモジュールと共に使用する能力が与えられる。共通言語ランタイム１４４を用いると、クロス言語継承と共にシームレスなマルチ言語開発が可能になり、複数プログラミング言語の堅牢で保護された実行環境が提供される。共通言語仕様１４０および共通言語ランタイム１４４に関するさらなる情報については、特許文献１、表題「Method and System for Compiling Multiple Languages」および特許文献２、表題「Unified Data Type System and Method」を参照されたい。
【００３１】
フレームワーク１３２によって、オペレーティングシステム１４６（１）（たとえば、Ｗｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステム）およびオブジェクトモデルサービス１４６（２）（たとえば、コンポーネントオブジェクトモデル（ＣＯＭ）または分散ＣＯＭ）がカプセル化される。オペレーティングシステム１４６（１）は、ファイル管理、通知、イベント処理、ユーザインターフェース（たとえば、ウィンドウイング（windowing）、メニュー、ダイアログなど）、セキュリティ、認証、検証、プロセスおよびスレッド、メモリ管理などの従来の機能を提供する。オブジェクトモデルサービス１４６（２）は、さまざまなタスクを実行するために、他のオブジェクトとのインターフェースを提供する。ＡＰＩレイヤ１４２に対して行われる呼出しは、オペレーティングシステム１４６（１）および／またはオブジェクトモデルサービス１４６（２）によるローカル実行のために共通言語ランタイムレイヤ１４４に渡される。
【００３２】
ＡＰＩ１４２は、ＡＰＩ関数を複数の名前空間にグループ化する。名前空間によって、本質的に、セットとして「型」と呼ばれる、関連する機能性の特定のセットを提供する、クラス、インターフェース、委任（delegate）、列挙、および構造体のセットが定義される。クラスは、参照割り当てセマンティックス（semantics）を有する、管理されるヒープから割り当てられるデータを表す。委任は、オブジェクト指向関数ポインタである。列挙は、名前付き定数を表す特殊な種類の値型である。構造体は、値割り当てセマンティックスを有する、静的に割り当てられたデータを表す。インターフェースは、他の型を実施できるコントラクトを定義する。
【００３３】
名前空間を使用することによって、設計者が、型のセットを階層名前空間に編成することができる。設計者は、型のセットから複数のグループを作成することができ、各グループに、論理的に関連する機能性を公開する少なくとも１つの型が含まれる。例示的な実施形態では、ＡＰＩ１４２が、３つのルート名前空間を含むように編成される。図２には３つのルート名前空間だけが示されているが、追加のルート名前空間をＡＰＩ１４２に含めることもできることに留意されたい。ＡＰＩ１４２に示された３つのルート名前空間は、プレゼンテーションサブシステムの第１名前空間２００（ユーザインターフェースシェルの名前空間２０２を含む）、ウェブサービスの第２名前空間２０４、およびファイルシステムの第３名前空間２０６である。各グループに名前を割り当てることができる。たとえば、プレゼンテーションサブシステム名前空間２００に、名前「Ｗｉｎｄｏｗｓ」を割り当てることができ、ファイルシステム名前空間２０６の型に、名前「Ｓｔｏｒａｇｅ」を割り当てることができる。名前付きグループを、Ｓｙｓｔｅｍ名前空間全体などのシステムレベルＡＰＩの単一の「グローバルルート」名前空間の下で編成することができる。トップレベル識別子を選択し、プレフィックシングすることによって、各グループの型を、型を含むグループの名前の前に置かれた選択されたトップレベル識別子を含む階層名によって簡単に参照することができる。たとえば、ファイルシステム名前空間２０６の型を、階層名「Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ」を使用して参照することができる。このようにして、個々の名前空間２００、２０４、および２０６が、Ｓｙｓｔｅｍ名前空間からの主要な分岐になり、および個々の名前空間が「Ｓｙｓｔｅｍ．」プレフィックスなどの指示子（designator）を前に付けられる指定を伝える。
【００３４】
プレゼンテーションサブシステム名前空間２００は、プログラミングおよびコンテンツ開発に関する。この名前空間は、アプリケーション、文書、媒体プレゼンテーション、および他のコンテンツの生成を可能にする型を供給する。たとえば、プレゼンテーションサブシステム名前空間２００は、開発者がオペレーティングシステム１４６（１）および／またはオブジェクトモデルサービス１４６（２）からサービスを得られるようにするプログラミングモデルを提供する。
【００３５】
シェル名前空間２０２は、ユーザインターフェース機能性に関する。この名前空間は、開発者が自分のアプリケーションにユーザインターフェース機能性を埋め込めるようにし、さらに、開発者がユーザインターフェース機能性を拡張できるようにする型を供給する。
【００３６】
ウェブサービス名前空間２０４は、たとえば、イントラネット上の２つのピアの間で動作するチャットアプリケーションのように単純なアプリケーションおよび／または数百万のユーザに関するスケーラブルウェブサービスなどの複雑なアプリケーションなど、さまざまなウェブアプリケーションの作成を可能にするインフラストラクチャに関する。本明細書で説明するインフラストラクチャは、有利なことに、特定のソリューションの複雑さに適当なパーツだけを使用する必要があるという点で、非常に可変である。このインフラストラクチャは、さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供する。このインフラストラクチャまたはフレームワークは、基本的メッセージング、セキュアメッセージング、信頼されるメッセージング、およびトランザクション処理されるメッセージングのＡＰＩを提供する。下で説明する実施形態では、関連するＡＰＩが、有用性、使い易さ、拡張性、およびバージョナビリティ（versionability）のバランスをとるように注意深く作成された形で名前空間の階層に分解される。
【００３７】
ファイルシステム名前空間２０６は、ストレージに関する。この名前空間は、情報の保管および検索を可能にする型を供給する。
【００３８】
フレームワーク１３２のほかに、プログラミングツール２２０が、開発者がウェブサービスおよび／またはアプリケーションを構築するのを支援するために設けられている。プログラミングツール２２０の１つの例が、Ｍｉｃｒｏｓｏｆｔ社によって提供されるプログラミングツールのマルチ言語スイートであるＶｉｓｕａｌ Ｓｔｕｄｉｏ（商標）である。
【００３９】
（ルートＡＰＩ名前空間）
図３に、プレゼンテーションサブシステム名前空間２００を詳細に示す。一実施形態において、名前空間が、名前のストリングがピリオドによって連結される階層命名規約に従って識別される。たとえば、プレゼンテーションサブシステム名前空間２００は、ルート名「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ」によって識別される。「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ」名前空間内に、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ」として識別されるもう１つの名前空間があり、さらに、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ」と称する、コントロールに関するもう１つの名前空間が識別される。この命名規約を念頭において、以下では、プレゼンテーションサブシステム名前空間２００の全般的な概要を提供するが、他の命名規約を使用して同等の効果を得ることができる。
【００４０】
Ｓｈｅｌｌ名前空間２０２（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ」）に、ストレージシステム内のアイテム、ＦＴＰロケーションまたはＤＡＶ（Distributed authoring and Versioning）ロケーションのファイル、コントロールパネル内のコントロールパネルアプレット、アプリケーションなど、エンドポイントのセットをエンドユーザが調査でき、ナビゲートできるようにするユーザインターフェース機能性をサポートするクラスおよびＡＰＩが含まれる。このナビゲーションに、１つまたは複数のフォルダを開くこと、ならびにフォルダ内のフォルダを開くことを含めることができる。Ｓｈｅｌｌ名前空間２０２を用いると、開発者が、そのような機能性を自分のアプリケーションに組み込めるようになり、さらに、開発者が、この調査およびナビゲーションの機能性を拡張できるようになる。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの諸バージョンで、このユーザインターフェースを、通常は「エクスプローラ」と称する。
【００４１】
ある実施形態で、Ｓｈｅｌｌ名前空間２０２のユーザインターフェース機能性を用いてユーザがそれを調査でき、ナビゲートできるようになるストレージシステムは、すべての種類の情報の編成、検索、および共有のためのアクティブストレージプラットフォームである。このプラットフォームは、リッチデータモデルを定義し、リレーショナルストレージエンジンに基づき、柔軟なプログラミングモデルをサポートし、データの監視、管理、および操作のためのデータサービスのセットを提供する。データは、ファイルベースデータまたは非ファイルベースデータとすることができ、データを、通常は「アイテム」と称する。このファイルシステムでは、通常、ファイルシステムによって提供される機能性が拡張される。というのは、このファイルシステムが、個人連絡先、イベントカレンダ、電子メールメッセージなどの非ファイルデータであるアイテムも扱うからである。そのようなファイルシステムの一例が、「ＷｉｎＦＳ」ファイルシステムである。
【００４２】
Ｓｈｅｌｌ名前空間２０２のユーザインターフェース機能性を用いてユーザがそれを調査でき、ナビゲートできるようになるストレージシステムのユニバーサルデータストアは、そのストアに常駐するデータの編成、検索、共有、同期化、およびセキュリティをサポートするデータモデルを実施する。このデータストアのストレージ情報の基礎的な単位を、アイテムと称する。データモデルは、アイテムおよびアイテム拡張を宣言し、アイテムの間の関係を確立し、アイテムをフォルダおよびカテゴリに編成する機構を提供する。
【００４３】
アイテムは、単純なファイルと異なって、ストレージシステムによってユーザまたはアプリケーションプログラムに公開されるすべてのオブジェクトにまたがって一般的にサポートされるプロパティの基本セットを有するオブジェクトである、保管可能な情報の単位である。アイテムは、新しいプロパティおよび関係を導入できるようにする特徴を含む、すべてのアイテムタイプにまたがって一般的にサポートされるプロパティおよび関係も有する。このプロパティおよび関係のデータを、アイテムに関連するメタデータとも称する。下で詳細に述べるように、メタデータは、アイテム装飾スキーマに従って保管することができる。このアイテム装飾スキーマによって、アイテムをユーザに提示するのに適当な形を示すことができる。
【００４４】
アイテムは、コピー、削除、移動、開く、印刷、バックアップ、レストア、複製などの共通の動作の対象である。アイテムは、保管でき検索できる単位であり、ストレージプラットフォームによって操作される保管可能な情報のすべての形が、アイテム、アイテムのプロパティ、またはアイテムの間の関係として存在し、これらのそれぞれを、下で詳細に説明する。アイテムは、（すべてのさまざまな種類の）Ｃｏｎｔａｃｔｓ（連絡先）、Ｐｅｏｐｌｅ（人）、Ｓｅｒｖｉｃｅｓ（サービス）、Ｌｏｃａｔｉｏｎｓ（ロケーション）、Ｄｏｃｕｍｅｎｔｓ（文書）などのデータの、実世界の簡単に理解できる単位である。
【００４５】
アイテムは、独立のオブジェクトである。したがって、アイテムを削除する場合に、アイテムのプロパティのすべても削除される。同様に、アイテムを検索するときに、受け取られるものは、アイテムと、そのアイテムのメタデータに含まれるそのプロパティのすべてである。ある実施形態では、特定のアイテムを検索するときに、プロパティのサブセットを要求できるようにすることができるが、そのような実施形態の多くに関するデフォルトは、検索されるときに、アイテムを、直接のおよび継承されたプロパティのすべてと共に提供することである。さらに、アイテムの型の既存のプロパティに新しいプロパティを追加することによって、アイテムのプロパティを拡張することもできる。これらの「拡張」は、その後、そのアイテムの真正のプロパティになり、そのアイテム型のサブタイプに、自動的に拡張プロパティを含めることができる。拡張を、ファイルに関連するメタデータとも称する場合がある。
【００４６】
アイテムのグループを、アイテムフォルダ（ｉｔｅｍ Ｆｏｌｄｅｒ）と称する特殊なアイテム（ファイルフォルダと混同してはならない）に編成することができる。しかし、ほとんどのファイルシステムと異なって、アイテムは、複数のアイテムフォルダに属することができ、アイテムが、あるアイテムフォルダでアクセスされ、改訂されるときに、この改訂されたアイテムに、別のアイテムフォルダから直接にアクセスすることができる。要するに、アイテムへのアクセスを、異なるアイテムフォルダから行うことができるが、実際にアクセスされるものは、実際にはまったく同一のアイテムである。しかし、アイテムフォルダは、必ずしもそのメンバアイテムのすべてを所有せず、あるいは他のアイテムフォルダと共にアイテムを単純に協同所有することができ、アイテムフォルダの削除が、必ずしもアイテムの削除をもたらさない。
【００４７】
アイテムのグループを、カテゴリ（Ｃａｔｅｇｏｒｙ）に編成することもできる。アイテムフォルダが、相互関係（すなわち、共通の記述された特性）を有しないアイテムを含むことができるが、カテゴリの各アイテムは、そのカテゴリについて記述された共通の型、プロパティ、または値（「共通性」）を有し、カテゴリへの関係およびカテゴリ内の他のアイテムとの間の関係の基礎を形成するのがこの共通性であるという点で、カテゴリは、概念的にアイテムフォルダと異なる。さらに、特定のフォルダへのアイテムのメンバシップは、そのアイテムの特定の態様に基づく必須のものではないが、ある実施形態について、あるカテゴリに断定的に関連する共通性を有するすべてのアイテムを、ハードウェア／ソフトウェアインターフェースシステムレベルで、自動的にそのカテゴリのメンバにすることができる。概念的に、カテゴリは、メンバシップが特定の照会の結果に基づく（データベースのコンテキストで、など）仮想アイテムフォルダと考えることもでき、この照会の条件（カテゴリの共通性によって定義される）を満たすアイテムは、したがって、カテゴリのメンバシップを備える。
【００４８】
ファイル、フォルダ、およびディレクトリと異なって、本発明のアイテム、アイテムフォルダ、およびカテゴリは、特徴として性質において「物理的」ではない。というのは、これらが、概念的に物理コンテナの同等物を有しておらず、したがって、アイテムが、複数のそのようなロケーションに存在することができるからである。アイテムが、複数のアイテムフォルダロケーションに存在し、カテゴリに編成される能力によって、当技術分野で現在使用可能なものを超える、ハードウェア／ソフトウェアインターフェースレベルでのデータ操作およびストレージ構造能力の機能強化および質の高さがもたらされる。
【００４９】
アイテムに、複数のアイテムの間の関係を判定できるようにする関係情報も含めることができる。関係は、バイナリ関係であり、一方のアイテムがソースとして指定され、他方のアイテムがターゲットとして指定される。ソースアイテムおよびターゲットアイテムは、関係によって関連する。
【００５０】
ユニバーサルデータストア内のアイテムは、シェルブラウザによってユーザに提示され、このシェルブラウザは、ユーザがハードウェア／ソフトウェアインターフェースを用いて見ることができる、および対話することができるようにする（Ｓｈｅｌｌ名前空間２０２のクラスおよびＡＰＩを使用して）ユーザインターフェースを提供する。ユニバーサルデータストア内の各アイテムは、ユニバーサルデータスキーマに従って保管される。このスキーマには、型関連付け（type association）と称する、アイテムを記述する機構が含まれる。各型関連付けは、シェル内の基本的表現を有し、型関連付けに従ってアイテムを保管することによって、シェルは、少なくとも基本表示ビューまたはデフォルト表示ビューに従ってアイテムを表示することができる。
【００５１】
型関連付けは、アイテムに関連するプロパティであり、データをユニバーサルデータストアに置くときに、そのデータに関連する１つまたは複数のプロパティを宣言して、そのアイテムの型を決定しなければならない。このプロパティは、データに関連するメタデータとして含めることができる。シェルは、デフォルト型関連付けのセットを有し、これによって、アイテムについて宣言しなければならない最も基本的な最小限のプロパティが表される。
【００５２】
プロパティ宣言を越えて、アイテムに関連するメタデータに、シェルがアイテムのプレゼンテーションをどのように装飾するかを示すデータを含めることができる。装飾は、この場合に、アイテムをどのようにユーザに提示するかに関する「ヒント」と考えることができる。このメタデータは、アイテム装飾スキーマに従って保管することができる。アイテム装飾スキーマでは、シェルがアイテムを提示するのに使用できるアイテム装飾ビューが定義される。たとえば、アイテム装飾データによって、アイテムの最も重要な宣言されたプロパティを記述することができる。これらの「高価値」プロパティは、シェルでの提示に関して最も望ましいものとすることができる。
【００５３】
アイテムを提示するために、アイテム装飾データによって、アイテムのプレゼンテーションに適当なビューフィールドのセットを示すことができる。ビューフィールドは、宣言されたプロパティの射影であり、共通のビューフィールドに、「タイトル」、「作成者」、「作成日」、または「最終編集日」を含めることができる。シェルには、標準的なビューフィールドのセットが含まれ、独立ソフトウェアベンダ（ＩＳＶ）は、自分のデータのプレゼンテーションに適当なビューフィールドを定義することができる。新しいアイテム型を開発するときに、ＩＳＶは、ＩＳＶが定義するアイテムプロパティをシェルのビューフィールドにマッピングするか、ＩＳＶ自身のビューフィールドを提供することができる。
【００５４】
たとえば、特定のアイテムデータに、ソングデータを含めることができる。宣言されるプロパティのセットに、歌の題名、アーティスト、レコーディング日付、アルバム、曲の長さ、およびそのようなソングアイテムに適当な他の宣言を含めることができる。アイテム装飾データによって、シェルでアイテムを提示するときに、ビューフィールド「Ｔｉｔｌｅ」、「Ａｒｔｉｓｔ」、および「Ａｌｂｕｍ」をユーザに表示しなければならないことを指示することができる。
【００５５】
アイテム装飾は、シェルによってサポートされる表示の任意の態様にすることができる。ある共通の他のアイテム装飾は、たとえば、データフォーマッティング、デフォルトソート順序、およびデフォルトアイコンサイズである。さらに、アイテム装飾データによって、所与のアイテムを表示する際に使用されるコモンコントロールを記述することができる。たとえば、Ｒａｔｉｎｇｓフィールドで、一連の星印としてレーティングを表示するレーティングコントロールを使用することができる。アイテム装飾データによって、アイテムと共に使用するのに適するタスクまたはバーブ（ｖｅｒｂ）を記述することができる。「タスク」および「バーブ」という用語は、アイテムに関して行われるあるアクションを記述するものであり、この用語は、交換可能に使用することができる。たとえば、「編集」または「プレビュー」を、アイテムに関連する適当なタスク／バーブとすることができる。シェルをさらに構成して、アイテムに関するアクションを実行するために、ユーザ選択時にこれらのタスクをサポートするアプリケーションを起動することができる。
【００５６】
アイテム装飾ビューは、所与のアイテムまたはアイテムの同種のセット（類似するアイテム装飾ビューを有するアイテムからなる）を完全に提示するのに十分である。異なるアイテム装飾スキーマを有するアイテムを表示するために、シェルは、シェル装飾ビューに従ってアイテムを提示するシェルビュースキーマを備える。シェルビュースキーマによって、シェルまたはＩＳＶが、異種データの所与のセットに適当なビューを宣言できるようになる。
【００５７】
シェル装飾ビュー内での表現について選択されるアイテムに、共通の特性を含めることができる。さまざまな共通の特性を、シェル装飾ビューについて受入可能とすることができる。たとえば、シェルビュースキーマで、すべての既知のピクチャ型（たとえば、．ＧＩＦ、．ＪＰＥＧ、．ＢＭＰ、．ＴＩＦＦなど）に対する共通のおよび適当な、フィールドおよびメタデータを表示するのに使用される「Ｐｉｃｔｕｒｅ」ビューを定義することができる。シェルビュースキーマは、所与のアイテム装飾ビューの衝突するディスプレイ属性をオーバーライドし、シェルビュースキーマに従って各ピクチャアイテムを提示する。もう１つの例として、シェルは、ワードプロセッシング文書、スプレッドシート、またはデータベースなどの通常のプロダクティビティアプリケーションによって作られるアイテムの適当なカラムおよびメタデータに関して最適化された「Ｄｏｃｕｍｅｎｔ」シェルビューを提供することができるが、これらのアイテムのそれぞれのアイテム装飾は互いに大きく異なる可能性がある。そのようなビューは、これらの文書のそれぞれの間で共通のプロパティを提供することによって価値を有する。後者の文書型がインストールされるときに、シェルビューは、ビューが最初に作成されたときに新しい型が考慮されていない可能性がある場合でも、一貫性のあるシェルビューに従って新しいアイテムを提示することができる。
【００５８】
シェルビュースキーマは、多岐にわたるディスプレイ属性を提供することができ、ＩＳＶは、そのようなシェルビューを提供することを望む場合がある。ディスプレイ属性に、制限なしに、プレビューペインのサイズ、プレビューペイン内に表示されるメタデータ、使用されるカスタムコントロール、ならびに提示されるアイテムに適当なタスクおよびバーブを含めることができる。
【００５９】
シェルは、エクスプローラディスプレイビューに従ってアイテムを提示することができる。「エクスプローラ」を、ストレージアプリケーションと呼ぶことができ、シェルまたはＩＳＶによって提供されることができる。エクスプローラは、たとえば、ユーザが、データストア内の選択されたアイテムの表示、照会、ナビゲーション、タスクへの起動、または編成を行えるようにすることができる。「エクスプローラ」という用語は、表示されるアイテムが存在するロケーションを暗示するのではなく、「アクティビティセンタ」、「ビューワ」、および「ライブラリ」などの用語を、ストレージアプリケーションを表現するために「エクスプローラ」と交換可能に使用することができる。
【００６０】
例のエクスプローラスキーマ階層に、アイテムビュースキーマであるボトムレイヤが含まれる。アイテムビュースキーマは、アイテムを表すのに必要な基本ディスプレイを提供し、エクスプローラビュースキーマは、そのディスプレイ要素を据え置くか、必要なときにそれに頼ることができる。
【００６１】
エクスプローラビュースキーマには、シェルビュースキーマおよびエクスプローラ装飾も含まれる。エクスプローラ装飾は、エクスプローラ全体を装飾し、特有の色およびブランド設定（branding）要素などのディスプレイ要素を提供する。これらのエクスプローラ装飾は、エクスプローラが提供するさまざまなビューの間で存続する。多岐にわたるさまざまなディスプレイ属性を、エクスプローラ装飾に適用できる。たとえば、エクスプローラに関連するデータ照会またはタスク／バーブを、エクスプローラを用いる表示に適用できる。表示されるタスクは、多くの場合、そのタスクを実行できるアプリケーションと結合される。
【００６２】
エクスプローラビュースキーマに、任意選択として、１つのシェルビュースキーマまたは複数のシェルビュースキーマを含めることができる。シェルビュースキーマは、エクスプローラアイテムのサブセットに対するシェルビューを提供するように構成することができる。たとえば、エクスプローラを、ユーザにソングアイテムを表示するように構成することができる。第１のシェルビュースキーマを含めて、アルバムの表示を提供することができ、第２のシェルビュースキーマを含めて、ソングトラックの表示を提供することができる。この方法で、両方のタイプのアイテムは、エクスプローラ内の適当なビューを有する。上述のように、シェルビューの利用は、任意選択として共通の特性を共有することができるアイテムのセットの提示に関連する。
【００６３】
エクスプローラは、シェルに含まれるシェルビューにも頼ることができる。エクスプローラ内での提示のために選択されたアイテムが、エクスプローラに含まれるシェルビューのどれによってもサポートされない場合に、シェルが、エクスプローラ内での使用のために適当なシェルビューを提供することができる。同様に、上述のように、エクスプローラは、シェルによって提供されるアイテムディスプレイビューまたはデフォルトディスプレイビューに頼ることもできる。この機能性によって、シェルによって表示できる任意のアイテムを、エクスプローラ内でも表示できることが保証される。エクスプローラは、これらのシェルが提供するディスプレイスキーマを据え置くように構成することができ、あるいは、たとえば予期せぬデータの表示を提供するために、それに頼ることができる。
【００６４】
Ｓｈｅｌｌ名前空間２０２は、アイテムのための基礎になるデータ（たとえば、ファイル内容、画像データ、連絡先情報データなど）が保管されるロケーションにかかわりなく、一貫性のある方法でアイテムを操作でき、対話できるようにするユーザインターフェース機能性をサポートする。アプリケーション設計者の観点から、Ｓｈｅｌｌ名前空間２０２によってサポートされる機能性は、よりよい開発体験をもたらすが、これは、少なくとも部分的に、異なるロケーションに保管される基礎になるデータにかかわらず、そのようなアイテムを一貫性のある方法で扱うことができるからである。Ｓｈｅｌｌ名前空間２０２を使用するときに、そのような異なるデータストレージロケーションの潜在的な存在にかかわらず、コヒーレントな経験を設計者に提供する。
【００６５】
Ｓｈｅｌｌ名前空間２０２では、Ｃｏｎｔｒｏｌｓ名前空間３０２、Ｄｉａｌｏｇｓ名前空間３０４、Ａｄｄｉｎ名前空間３０６、およびＤｅｓｋｔｏｐ名前空間３０８を含む追加の名前空間が定義される。Ｓｈｅｌｌ名前空間内のこれらの追加名前空間３０２、３０４、３０６、および３０８のそれぞれは、コントロール、ダイアログ、および／またはハンドラなど、以下で詳細に述べるさまざまな機能性を提供する１つまたは複数のサービスまたはコンポーネントが含まれる。
【００６６】
Ｓｈｅｌｌ名前空間２０２は、追加名前空間３０２、３０４、３０６、および３０８のそれぞれによって使用できるオブジェクトモデルを定義する。このオブジェクトモデルには、下記のオブジェクトが含まれる。
・ファイルフォルダ、スタック、個々のファイル、個々のＷｉｎＦＳアイテム（たとえば、アルバム、歌、写真など）など、Ｓｈｅｌｌを介してユーザに提示できるアイテムを記述するのに使用されるＥｘｐｌｏｒｅｒＩｔｅｍオブジェクト（Ｉｔｅｍオブジェクトとも称する）。
・ＥｘｐｌｏｒｅｒＩｔｅｍｓに対する照会を記述するのに使用されるＬｉｂｒａｒｉｅｓオブジェクト。
・ユーザへの表示のためにアイテム（たとえばＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトによって表される）からデータを射影するのに使用されるＶｉｅｗＦｉｅｌｄｓオブジェクト（Ｐｒｏｐｅｒｔｉｅｓオブジェクトとも称する）。ストレージシステムのプロパティとＶｉｅｗＦｉｅｌｄｓオブジェクトの間で定義される射影は、ＥｘｐｌｏｒｅｒＩｔｅｍｓに基づく追加計算または処理を実行することができる。たとえば、記憶装置を表すフォルダが表示されており、設計者がそのフォルダにその記憶装置の空き容量を含めることを望む場合に、射影によって記憶装置の総容量とその記憶装置に保管されたファイルのサイズ（ＥｘｐｌｏｒｅｒＩｔｅｍｓによって表される）に基づいて、空き容量が計算される。
・Ｌｉｂｒａｒｙオブジェクトの永続的な形である、ダイナミックリストへのリンクを記述するのに使用されるＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクト。ＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクトは、照会と、照会の結果をユーザに提示するビューの組合せである。
【００６７】
このオブジェクトモデルは、２００３年１０月２３日出願の米国特許出願第＿＿＿号、弁理士整理番号ＭＦＣＰ．１０９８３４（ＭＳ＃３０６９２３．０１）、表題「System and method for presenting items to a user with a contextual presentation」に詳細に記載されている。
【００６８】
Ｃｏｎｔｒｏｌｓ名前空間３０２（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ」）では、アプリケーションによって使用できる、再利用可能なユーザインターフェースコントロールのコレクションが定義される。複数の異なるアプリケーションが、これらのコントロールを利用することができるので、これらのコントロールは、再利用可能とみなすことができる。この再利用可能なコントロールのコレクションによって、アプリケーションの設計を単純化することができる。というのは、アプリケーション設計者が、コントロールの彼ら自身のバージョンを設計することを要求されるのではなく、これらのコントロールに頼ることができるからである。さらに、この再利用可能なコントロールのコレクションを使用することによって、複数のアプリケーションにまたがる一貫性のあるルックアンドフィールを達成することができる。
【００６９】
Ｃｏｎｔｒｏｌｓ名前空間３０２によって定義されるコントロールは、ユーザインターフェース内のアイテムの操作および／または表示を含む、ユーザインターフェースのシェルの操作および／または表示を可能にする。上で述べたように、ユーザインターフェースのシェル内で表示できるこれらのアイテムは、多岐にわたる種類のデータのいずれをも表し、ファイルシステムに保管される単に伝統的な「ファイル」ではない。さらに、Ｃｏｎｔｒｏｌｓ名前空間３０２によって定義されるコントロールを用いると、アプリケーション設計者が、多岐にわたるロケーションからのデータを扱うときに同一のコントロールを使用できるようになり、一貫性がありコヒーレントな設計経験がもたらされる。
【００７０】
Ｃｏｎｔｒｏｌｓ名前空間３０２では、下記の再利用可能なコントロールが定義される。
・ＥｘｐｌｏｒｅｒＶｉｅｗコントロールは、ストレージユーザ経験をカプセル化するのに使用される。ストレージユーザ経験は、関係、照会などを用いてアイテムにまたがって作業するために定義される。このストレージユーザ経験を用いると、エンドユーザが、たとえば、プロパティ値に基づく照会を発行し、共通プロパティ値を用いてＷｉｎＦＳアイテムをスタックし、スタックされていないアイテムからスタックへのドラッグアンドドロップを可能にする（たとえば、プロパティ述部のプロパティの値に、スタックに存在するものをセットすることによって）などが可能になる。ＥｘｐｌｏｒｅｒＶｉｅｗコントロールを使用して、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの以前のバージョン（たとえば、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのＷｉｎｄｏｗｓ（登録商標）ＸＰバージョンまたはＷｉｎｄｏｗｓ（登録商標）９８バージョン）など、以前のオペレーティングシステム（レガシシステムとも称する）で見られるものと同一の外見を有するディスプレイ用のフォルダを記述することができる。
・ＥｘｐｌｏｒｅｒＩｔｅｍｓの表示に使用されるＥｘｐｌｏｒｅｒＩｔｅｍＶｉｅｗ。ＥｘｐｌｏｒｅｒＩｔｅｍｓのレイアウトおよび設計は、アプリケーション設計者が定義することができる。オペレーティングシステムは、アプリケーション設計者が定義できるレイアウトおよび設計にある制約を課すユーザ経験を定義することもでき、したがって、アプリケーション設計者によって定義されるレイアウトおよび設計が、オペレーティングシステムによって定義されるユーザ経験と一貫性を持つようになる。したがって、ＥｘｐｌｏｒｅｒＩｔｅｍＶｉｅｗコントロールを用いると、設計者が、ＥｘｐｌｏｒｅｒＩｔｅｍｓからのデータをユーザに表示する方法（たとえば、列で、行で、または他の構成で）ならびにどのデータをユーザに表示するかを決定できるようになる。
・アイテムをサイドバーに追加できるようにするのに使用されるＢａｓｋｅｔＣｏｎｔｒｏｌコントロール（サイドバーは、以下で詳細に説明する）。カーソル制御装置を使用してアイテムを選択し、それをサイドバーにドラッグし、そこでドロップ（たとえば、カーソル制御ボタンを離すことによって）することによって、「ドラッグアンドドロップ」でサイドバーにアイテムを追加することができる。ＢａｓｋｅｔＣｏｎｔｒｏｌコントロールは、２００３年１０月１３日出願の米国特許出願第＿＿＿号、弁理士整理番号００３７９７．００６９５（ＭＳ＃３０４６３１．１）、表題「Extensible Creation And Editing Of Integrated Collections」に詳細に記載されている。
・アイテムをリストまたはグループに追加できるようにするのに使用されるＬｉｓｔＭａｋｅｒコントロール。カーソル制御装置を使用してアイテムを選択し、適当なリストまたはグループの上にドラッグし、そこでドロップ（たとえば、カーソル制御ボタンを離すことによって）することによって、「ドラッグアンドドロップ」の形でアイテムのリストまたはグループを作成することができる。たとえば、アイテムを歌とし、リストをプレイリストとすることができ、アイテムを画像とし、リストを写真アルバムとすることができる。
・アイテムのプレビューイメージをユーザに提示できるようにするのに使用されるＰｒｅｖｉｅｗＩｍａｇｅＣｏｎｔｒｏｌコンポーネント。アイテムが選択されるときに、プレビューイメージをユーザに提示することができ、このプレビューイメージは、通常、イメージのサムネイルより大きいが、ユーザインターフェースのディスプレイ領域全体より小さい。
【００７１】
Ｄｉａｌｏｇｓ名前空間３０４（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓ」）では、アプリケーションによって使用できるユーザインターフェースダイアログおよびウィザードのコレクションが定義される。Ｃｏｎｔｒｏｌｓ名前空間３０２のコントロールに似て、Ｄｉａｌｏｇｓ名前空間３０４のダイアログおよびウィザードは、再利用することができ、その結果、複数の異なるアプリケーションが、これらのダイアログおよびウィザードを利用することができる。この再利用可能なダイアログおよびウィザードのコレクションは、複数のアプリケーションにまたがる一貫性のあるルックアンドフィールを維持するのを助ける。
【００７２】
Ｄｉａｌｏｇｓ名前空間３０４によって定義されるダイアログおよびウィザードは、ユーザインターフェースのシェル内でアクションを実行できるようにする。上述のように、これらのシェルは、多岐にわたるさまざまな種類のデータのいずれをも表すことができるアイテムに基づき、ファイルシステムに保管される単に伝統的な「ファイル」ではない。さらに、Ｄｉａｌｏｇｓ名前空間３０４によって定義されるダイアログおよびウィザードを用いると、アプリケーション設計者が、さまざまなロケーションからのデータを扱うときに同一のダイアログおよびウィザードを使用できるようになり、一貫性のあるコヒーレントな設計経験がもたらされる。
【００７３】
Ｄｉａｌｏｇｓ名前空間３０４では、下記のダイアログおよびウィザードが定義される。
・ファイルおよびフォルダを開き、保存できるようにするのに使用されるＯｐｅｎ／Ｓａｖｅダイアログ。これらのダイアログは、拡張可能でもあり、アプリケーション設計者が、ダイアログの機能性を拡張することができる。たとえば、これらのダイアログを拡張して、アプリケーション設計者が使用を望むファイルおよび／またはフォルダに関するさまざまな追加のメタデータを利用することができる。
・ＣＤおよび／またはＤＶＤなどの光ディスクに書き込めるようにするために使用されるＣＤ／ＤＶＤ Ｂｕｒｎウィザード。ハードウェア設計者は、ＣＤおよび／またはＤＶＤに書き込めるようにする彼ら自身のハードウェア固有のステップを含む彼ら自身のウィザードを提供することができる。
・電子メールによってイメージを送信する際にユーザを支援するのに使用されるＳｅｎｄ Ｐｈｏｔｏｓウィザード。このウィザードを用いると、ユーザが、イメージを特定のサイズに変更できるようになる。このウィザードは、電子メール送信に適すると思われる特定のサイズにイメージのサイズを変更することができ、あるいは、その代わりに、ユーザが複数の異なるサイズから選択できるようにすることができる。
【００７４】
Ａｄｄｉｎ名前空間３０６（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ａｄｄｉｎ」）では、ユーザインターフェース機能性を拡張する基本クラスおよびインターフェースのコレクションが定義される。Ａｄｄｉｎ名前空間３０６を用いると、アプリケーション設計者が、ユーザインターフェースの機能性を拡張する管理されたコードを追加できるようになる。この拡張を用いると、たとえば、アプリケーション設計者が、適当と思われるようにユーザインターフェースの諸部分をカスタマイズできるようになる。
【００７５】
Ａｄｄｉｎ名前空間３０６を用いると、多岐にわたるさまざまな種類のデータのいずれをも表し、ファイルシステムに保管される単に伝統的な「ファイル」ではないアイテムを表示するのに使用されるユーザインターフェースのシェルの拡張が可能になる。さらに、Ａｄｄｉｎ名前空間３０６を用いると、アプリケーション設計者が、コヒーレントな形でユーザインターフェースのシェルを拡張できるようになり、より管理され改善された設計経験がもたらされる。
【００７６】
下記などのさまざまな機能性に関する管理されたコードが、Ａｄｄｉｎ名前空間３０６によってサポートされる。
・コンテキストメニューハンドラ。コンテキストメニューには、たとえば表示されているアイテムを右クリックすることによって、アクセスすることができる。コンテキストメニューハンドラは、アプリケーション設計者が、コンテキストメニューに追加される彼ら自身のエントリを定義できるようにする。
・サムネイルエクストラクタ（extractor）。サムネイルエクストラクタを用いると、アプリケーション設計者が、彼ら自身のサムネイル（たとえば、ファイル、フォルダ、および／または表示される他のアイテムに関する）を開発でき、ユーザへの表示のためにオペレーティングシステムに対してこれらのサムネイルを識別できるようになる。
・ＷｉｎＦＳからエクスプローラへの射影の合成／分解するためのハンドラ。これらのハンドラは、アプリケーション設計者が、ファイルおよび／またはフォルダに関する情報をユーザに表示するときにさまざまな計算を実行できるようにする（たとえば、記憶装置の空き容量を計算できるようにする）。
【００７７】
Ｄｅｓｋｔｏｐ名前空間３０８（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｅｓｋｔｏｐ」）は、アプリケーション設計者がユーザに表示されるデスクトップの機能性を拡張できるようにする機能性のコレクションを定義する。Ｄｅｓｋｔｏｐ名前空間は、Ｓｈｅｌｌ名前空間２０２の一部とすることができ（たとえば、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｅｓｋｔｏｐ」）、その代わりに、プレゼンテーションサブシステム名前空間２００の一部であるがＳｈｅｌｌ名前空間２０２の一部でないものとすることができる（たとえば、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｄｅｓｋｔｏｐ」）。Ｄｅｓｋｔｏｐ名前空間には、サイドバーおよび通知にかかわる要素が含まれる。サイドバー要素および通知要素をＤｅｓｋｔｏｐ名前空間に含めることによって、ユーザに、サイドバーおよび通知の集中化されたコントロールが与えられる。たとえば、すべてのアプリケーションからの通知に関するルールを、通知を使用するアプリケーションごとのルール定義にアクセスすることを介するユーザによるナビゲーションを必要とせずに、ユーザが１回でセットすることができる。
【００７８】
一般に、サイドバーは、統合された対話型周辺認識ディスプレイ内のダイナミック通信アクセスおよび情報認識を提供し、この対話型周辺認識ディスプレイ内では、指定された通信連絡先および情報要素が、ダイナミックに追跡または受信され、進行中の基礎でユーザに提供される。ある実施形態で、この機能が、従来のディスプレイ装置の１つの辺に沿った継続ディスプレイストリップ内の１つまたは複数の列に表示される少なくとも１つのカスタマイズ可能なダイナミックサムネイルを介して提供される。さらに、追加の実施形態で、サムネイルが、ディスプレイ全体を含むディスプレイの１つまたは複数の部分のいずれにも表示される。ディスプレイ全体がカバーされる実施形態は、たとえばハンドヘルドまたはパームトップコンピューティング装置、携帯電話、または他の限られたディスプレイ領域を有する電子装置など、比較的小さいディスプレイ領域を有する装置でサイドバーが使用される場合に特に有用である。
【００７９】
カスタマイズ可能なダイナミックサムネイル各々は、たとえば、特定の通信連絡先（特定の個人、会社、組織、または他のエンティティなど）またはユーザが興味を持つ可能性がある情報の特定の要素を表す。そのような情報要素に、たとえば、共有ファイルまたは共有フォルダが修正されるとき、共有データベースまたは共有ワークスペースの情報が変更されるとき、電子メール状況、カレンダ、インターネットウェブページ、気象条件、面会予約、スケジュール、統計的情報、株式市況、交通情報、またはユーザが興味を持つ可能性がある他のインターネットアクセス可能情報またはネットワークアクセス可能情報が含まれる。
【００８０】
前述のダイナミックサムネイルに、一般に、興味のある連絡先または情報を記述する「タイル」（「チケット」とも称する）と、どの通信連絡先または情報がタイルによって表されるかを表示するのに特化した「ビューワ」の組合せが含まれる。各タイルおよびビューワは、たとえば、Ｓｈｅｌｌ名前空間２０２によって提供されるユーザインターフェース機能性によってアクセスできるストレージシステム内のアイテムとすることができる。１つまたは複数の「サービス」を使用して、各タイルによって記述される情報の現況および／または通信連絡先の状況と自動的に相互作用をし、これを追跡し、または受け取る。情報の現況および通信連絡先の状況が、アイテムをグラフィカルにかつ／またはテキストによって表示するために、対話型周辺認識インターフェース内に常駐する「コンテナ」内で各タイルをホスティングすることによって、動的に提供される。周辺認識インターフェースは、潜在的な注意散漫またはユーザへの妨害を減らす方法で情報および／または通信連絡先を表示する。
【００８１】
一般に、タイルは、ＸＭＬデータファイルなどのデータ構造によって表される。各タイルに、どの情報または通信連絡先がそのタイルによって表されるかに関する命令、ならびにその情報または通信連絡先にアクセスし、かつ／またはこれと対話する複数の従来の手段のいずれかを表す特定のサービスへのポインタが含まれる。これらのサービスは、自動的にまたは手動で、事前に定義された、またはユーザ定義可能なサービスのライブラリから選択される。具体的に言うと、異なるサービスは、アクセス、受取、検索、および／または別に、従来の情報、情報のソース、もしくは通信連絡先との相互作用の機能を提供する共有コードまたは共有機能を表す。これらのサービスは、これらが単独でまたは組み合わされてのいずれかで使用され、１つまたは複数のタイルによって並列に使用することができるという意味で、共有される。その結果、ある実施形態で、複数のサービスが、従来の情報、情報のソース、または通信連絡先との複雑な相互作用を提供するために組み合わせて使用されることに留意されたい。
【００８２】
サービスの一例は、従来のＭＡＰＩサーバに接続することによって電子メールフォルダを監視するのに必要な機能性である。サービスのもう１つの例は、電子メールメッセージを送信または受信する機能性である。関連するサービスが、たとえばインスタントメッセージングまたはピアツーピア通信方式など、複数の従来の方法を介する連絡先との通信または情報転送の機能性を提供する。サービスのもう１つの例が、テキストファイルをある言語から別の言語に変換する機能性である。サービスのもう１つの例が、データベースを監視するのに必要な機能性である。サービスのもう１つの例に、ウェブサイトまたはリモートサーバからデータを受信するか検索する機能性が含まれる。明らかに、情報、情報のソース、または通信連絡先と相互作用する方法のどれをも、１つまたは複数のタイルにより使用される共有サービスとして実施することができる。
【００８３】
さらに、上記のように、各タイルの命令に、どのタイプの情報または通信連絡先がタイルによって表されていても、それを表示する能力を有する複数の専用ビューワの１つへのポインタが含まれる。言い換えると、各タイルは、ユーザが特定の情報または連絡先をどのように表示することを望むかの定義と共に、ユーザが経過を追うことを望む情報または連絡先、ならびに情報または連絡先へのアクセスおよび相互作用に関する複数のサービスのいずれをも使用する能力の組合せを表す。そのようなアクセスまたは相互作用は、ローカルに、またはローカルイントラネット、エクストラネット、有線または無線ネットワーク、インターネットなどにわたって従来の通信プロトコルを介して達成することができる。
【００８４】
ビューワは、１つまたは複数のサービスを介して検索された情報または連絡先データを有するサイズ変更可能なサムネイルまたはアイコンサイズのウィンドウとしてタイルをグラフィカルに表示する。具体的に言うと、ビューワは、テキスト情報、可聴情報、あるいは静止画像または生画像を含むグラフィカル情報、あるいはテキスト情報、可聴情報、またはグラフィカル情報の組合せを有するタイルをダイナミックに表示することができる。たとえば、あるビューワタイプは、連絡先情報を表示できるすなわち「パーソンタイル」であり、別のタイプは、たとえば受信したメッセージの数または特定のソースからのメッセージの数などの特定の電子メール情報を表示することができ、もう１つのビューワは、データベースからの特定の情報のサマリをサムネイル内で提供するためにデータベースと対話するように設計される。ビューワタイプのさらなる例に、静止画像、ビデオ画像、通信状況のサマリ、データベース照会の結果などを表示できるビューワが含まれる。明らかに、任意のタイプのビューワを任意の対応するタイプの情報に関連付け、任意の可能な情報を表示できることを保証するように設計することができる。
【００８５】
サイドバーは、特許文献３、表題「A system and process for providing dynamic communication access and information awareness」に詳細に記載されている。
【００８６】
名前空間３０８のサイドバー機能性は、アプリケーション設計者が、サイドバーにタイルを追加できるようにする。
【００８７】
通知（たとえば、可聴通知または視覚的通知）は、ユーザコンテキストシステムの一部であり、このユーザコンテキストシステムには、ある実施形態によれば、通知を処理する方法に関する判断のために比較される３つの要素が含まれる。第１の要素は、ユーザのコンテキスト（オペレーティングシステムおよびそのコンテキストを拡張した任意のプログラムによって提供することができる）である。第２の要素は、ユーザのルールおよびプリファレンスである。第３の要素は、通知自体（ユーザのルールと一致する可能性があるデータおよびプロパティなどの要素を含む）である。
【００８８】
ユーザコンテキストシステムは、オペレーティングシステムおよびユーザのコンテキストを宣言する他のプログラムによって、システムがユーザのコンテキストおよびルールを仲介した後に動作する。通知は、システムへの呼出しを行う他のプログラムによって手前に上げられる。ユーザのコンテキスト、ルール、および通知の要素が、比較され、その後、通知に関して何を行うべきかに関する判定が行われる。通知に関して行うことができるものに関するさまざまなオプションの例に、拒否（たとえば、通知が人目を引くか騒ぐことを許可されない場合に、通知は絶対にユーザによって見られない）、据置き（たとえば、ユーザのコンテキストが変化する、または配送が後に適するようになることがユーザのルールから示されるまで通知が保持される）、配送（たとえば、ユーザのコンテキストおよびルールに従って通知を配送することが許可される）、ルーティング（たとえば、通知が現在のシステムで配送を許可されるかどうかにかかわらず、通知を別のシステムに渡さなければならないことがユーザのルールによって示される）が含まれる。
【００８９】
一般に、ユーザは、「求めに応じられない」とみなされる状態にある場合があり、その場合には、通知は、配送されないか、ユーザが「求めに応じられる」ようになるまで保持されるのいずれかになる。たとえば、ユーザが、フルスクリーンアプリケーションを実行している場合に、そのユーザを、求めに応じられないと見なすことができる。あるいは、ユーザは、「求めに応じることができる」が、ユーザに適するように通知を修正する必要がある状態である場合がある。たとえば、ユーザが、音楽を聴いているか会議中である場合に、そのユーザが、通知をユーザの画面に配送しなければならないが、通知が鳴らすサウンドを、音量を下げるか全く再生しないようにしなければならないことを指示することができる。
【００９０】
上記のように、ユーザコンテキストは、通知をユーザの画面に表示するかどうかを部分的に決定することができる。通知を表示するときに、その通知をユーザコンテキスト内で、ある勾配（gradient）に基づいて表示することができる。言い換えると、指定できる、描かれる通知の形態の異なるレベルの侵襲性（invasiveness）がある。たとえば、従来の通知は、自由にクライアント領域にポップアウトし、短い間だけウィンドウを隠す。ユーザがわずかに制限的なコンテキストにいる場合、この通知は自由に表示できるが、別のウィンドウの上への描画を許可されないなど、より侵襲性でない形でのみ表示できるものとすることができる。もう１つの例として、一実施形態で、ユーザが最大化されたアプリケーションを実行している場合に、デフォルト設定は、コンテキストがわずかに制限的であること、およびユーザが、このアプリケーションがクライアント領域全体を得ることを望むと明確に述べていることを意味するものとすることができる。この設定では、通知はまだ描画することを許可されるが、サイドバー内に現れるだけにされることができる。言い換えると、通知描画形式におけるこのタイプの侵襲性の減少は、通知の影響を減らし、認識の負荷を全体的に減らす。
【００９１】
ユーザコンテキストシステムは、特許文献４、表題「System and Method Utilizing Test Notifications」に詳細に記載されている。
【００９２】
名前空間３０８の通知機能性は、アプリケーション設計者が、彼ら自身の通知を作成し、それらをデスクトップに表示させて、ユーザにとって重要である可能性がある何か（たとえば、電子メールメッセージが受信された、インスタントメッセージが受信されたなど）が発生したときにユーザに通知できるようにする。名前空間３０８の通知機能性によって、さらに、ユーザが複数のアプリケーションからの通知に関する自身のルールおよびプリファレンスを定義する中央ロケーションが提供され、ユーザが、同一のルールおよびプリファレンスを複数回（複数のアプリケーションのそれぞれに１回）セットするという煩わしさから解放される。
【００９３】
さらに、Ｃｏｎｔａｃｔｓ名前空間で、連絡先情報に関するコントロールおよびダイアログのコレクションが定義される。この連絡先情報は、アイテムとしてストレージシステムに保管することができる。「連絡先」は、一般に、人、グループ、組織、会社、世帯、または他のタイプの識別可能なエンティティを指す。「連絡先情報」は、一般に、連絡先に対応する、連絡先の識別、接触、アクセス、対応、または通信に関係すると考えることができる情報を指す。連絡先情報は、アプリケーションによって、たとえば電子メール送信、電話の発呼、ウェブサイトへのアクセス、ゲーミングセッションの開始、金融トランザクションの実行など、所望の機能を実行するのに使用される。連絡先情報の非制限的な例に、名前、別名、電話番号、電子メールアドレス、家の住所、インスタントメッセージング（ＩＭ）アドレス、およびウェブアドレスが含まれる。連絡先情報は、連絡先の状況など、他のタイプの情報を指すこともできる。たとえば、連絡先が現在オンラインであるか電話に出ていることを示す情報を、広義に連絡先情報と考えることもできる。
【００９４】
Ｃｏｎｔａｃｔｓ名前空間は、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔａｃｔｓ」、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔｒｏｌｓ」（図３のコントロール３１０）、または「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｌｌａｂｏｒａｔｉｏｎ」など、プレゼンテーションサブシステム名前空間２００の一部であるが、Ｓｈｅｌｌ名前空間２０２の一部でないものとすることができる。その代わりに、Ｃｏｎｔａｃｔｓ名前空間を、Ｓｈｅｌｌ名前空間２０２の一部とすることができる。Ｃｏｎｔａｃｔｓ名前空間は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ名前空間の機能性を拡張するが、Ｓｈｅｌｌの一部として実装する必要はない（すなわち、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ名前空間３０２の一部である必要はない）。
【００９５】
Ｃｏｎｔａｃｔｓ名前空間を用いると、連絡先情報を、ユーザが１回だけ入力し、複数の異なるアプリケーションによってアクセスできるようになる。したがって、ユーザは、同一の連絡先情報を複数回（複数のアプリケーションのそれぞれについて１回）入力するという煩わしさから解放される。
【００９６】
Ｃｏｎｔａｃｔｓ名前空間のコントロールおよびダイアログには、下記が含まれる。
・ユーザがその保管された連絡先から連絡先を選択またはピックできるようにするのに使用されるＣｏｎｔａｃｔ Ｐｉｃｋｅｒダイアログ。たとえば、ユーザが、電子メールメッセージが送信される連絡先またはインスタントメッセージングに関する連絡先を選択できるようにする。ユーザは、たとえば、システムストレージ内にアイテムとして保管されたユーザの連絡先のすべてのリストをブラウズでき、これらの連絡先の１つまたは複数を選択することができる。Ｃｏｎｔａｃｔ Ｐｉｃｋｅｒダイアログは、特許文献５、表題「Ｃｏｎｔａｃｔ Ｐｉｃｋｅｒ」に詳細に記載されている。
・自由形式の名前などの連絡先情報をユーザが入力できるようにする（たとえば名前をタイプすることによって）のに使用され、連絡先情報が入力されるときに、その情報をユーザの保管された連絡先からの１つまたは複数の連絡先に解決するＣｏｎｔａｃｔ Ｔｅｘｔｂｏｘコントロール。解決された情報は、たとえば、ドロップダウンメニューに表示することができ、あるいは、ユーザが自由形式で名前を入力した場合にタイプイン行に自動的に挿入することができる。
・連絡先情報をユーザに表示するのに使用されるＣｏｎｔａｃｔコントロール。連絡先情報の編集または自由形式入力は、このコントロールによってサポートされない。
【００９７】
（名前空間メンバの例）
このセクションには、例の名前空間（たとえば、図３のプレゼンテーションサブシステム名前空間２００内の名前空間）によって公開できるメンバの例を記述した複数のテーブルが含まれる。これらの公開されるメンバに、たとえば、クラス、インターフェース、列挙、および委任を含めることができる。これらの例に記載されたメンバが、例にすぎず、代替の他のメンバを名前空間によって公開できることを理解されたい。
【００９８】
下記の名前空間の一部で、あるクラス、インターフェース、列挙、および委任の記述が空白のままにされていることを理解されたい。
【００９９】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ＞＞
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ名前空間によって公開されるメンバの例を示す。
【０１００】
＜クラス＞
DefaultCommandEventArgs − ＤｅｆａｕｌｔＣｏｍｍａｎｄＥｖｅｎｔイベントに関するイベントデータを含む。
ExplorerView − フォルダの内容に関する情報をユーザが見られるようにする。
FolderSelectionChangedEventArgs − ＦｏｌｄｅｒＳｅｌｅｃｔｉｏｎＣｈａｎｇｅｄＥｖｅｎｔイベントに関するイベントデータを含む。
IncludeItemEventArgs − ＩｎｃｌｕｄｅＩｔｅｍＥｖｅｎｔイベントに関するイベントデータを含む。
ItemVerbModifyEventArgs − ＩｔｅｍＶｅｒｂＭｏｄｉｆｙＥｖｅｎｔＡｒｇｓクラスの新しいインスタンスを初期化する。
NavigationCompleteEventArgs − ＮａｖｉｇａｔｉｏｎＣｏｍｐｌｅｔｅＥｖｅｎｔイベントのイベントデータを含む。
NavigationFailedEventArgs − ＮａｖｉｇａｔｉｏｎＦａｉｌｅｄＥｖｅｎｔイベントのイベントデータを含む。
NavigationPendingEventArgs − ＮａｖｉｇａｔｉｏｎＰｅｎｄｉｎｇＥｖｅｎｔイベントのイベントデータを含む。
【０１０１】
＜列挙＞
FolderViewFlags − ＥｘｐｌｏｒｅｒＶｉｅｗのビュープロパティを示す。
FolderViewMode − ＥｘｐｌｏｒｅｒＶｉｅｗのビューモードを示す。
【０１０２】
＜委任＞
DefaultCommandEventHandler − ＤｅｆａｕｌｔＣｏｍｍａｎｄＥｖｅｎｔを処理するメソッドを表す。
FolderSelectionChangedEventHandler − ＦｏｌｄｅｒＳｅｌｅｃｔｉｏｎＣｈａｎｇｅｄＥｖｅｎｔを処理するメソッドを表す。
IncludeItemEventHandler − ＩｎｃｌｕｄｅＩｔｅｍＥｖｅｎｔを処理するメソッドを表す。
ItemVerbModifyEventHandler − ＩｔｅｍＶｅｒｂＭｏｄｉｆｙＥｖｅｎｔを処理するメソッドを表す。
NavigationCompleteEventHandler − ＮａｖｉｇａｔｉｏｎＣｏｍｐｌｅｔｅＥｖｅｎｔを処理するメソッドを表す。
NavigationFailedEventHandler − ＮａｖｉｇａｔｉｏｎＦａｉｌｅｄＥｖｅｎｔを処理するメソッドを表す。
NavigationPendingEventHandler − ＮａｖｉｇａｔｉｏｎＰｅｎｄｉｎｇＥｖｅｎｔを処理するメソッドを表す。
【０１０３】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓ＞＞
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓ名前空間によって公開されるメンバの例を示す。
【０１０４】
＜クラス＞
ColorDialog
CommonDialog
DialogControlItemSelectedEventArgs
FileDialog − ＯｐｅｎＦｉｌｅＤｉａｌｏｇおよびＳａｖｅＦｉｌｅＤｉａｌｏｇＢａｓｅの親クラスとして使用される抽象クラス。
FileDialogCheckButton − ＦｉｌｅＤｉａｌｏｇに配置できるチェックボックスコントロールを表す
FileDialogComboBox
FileDialogContainerControlBase −ＦｉｌｅＤｉａｌｏｇＣｏｍｂｏＢｏｘ、ＦｉｌｅＤｉａｌｏｇＯｐｅｎＤｒｏｐＤｏｗｎ、ＦｉｌｅＤｉａｌｏｇＲａｄｉｏＢｕｔｔｏｎＧｒｏｕｐ、およびＦｉｌｅＤｉａｌｏｇＴｏｏｌｂａｒＭｅｎｕの親クラスとして使用される抽象クラス。
FileDialogControlBase − ＦｉｌｅＤｉａｌｏｇＣｈｅｃｋＢｕｔｔｏｎ、ＦｉｌｅＤｉａｌｏｇＥｄｉｔＢｏｘ、ＦｉｌｅＤｉａｌｏｇＰｕｓｈＢｕｔｔｏｎ、およびＦｉｌｅＤｉａｌｏｇＣｏｎｔａｉｎｅｒＣｏｎｔｒｏｌＢａｓｅの親クラスとして使用される抽象クラス。
FileDialogControlItem
FileDialogEditBox − ＦｉｌｅＤｉａｌｏｇに配置できるテキストボックスコントロールを表す。
FileDialogOpenDropDown
FileDialogPushButton − ＦｉｌｅＤｉａｌｏｇに配置できるボタンコントロールを表す。
FileDialogRadioButtonGroup
FileDialogToolbarMenu
FileOkEventArgs
FileType
OpenFileDialog − ユーザが１つまたは複数のファイルを開けるようにする。このクラスを継承することはできない。
SaveAsFileDialog − ユーザが、ファイルが保存されるロケーションを選択でき、ファイル名を指定できるようにする。このクラスを継承することはできない。
SaveFileDialog − ユーザが、ファイルを保存するロケーションを選択できるようにする。このクラスを継承することはできない。
SaveFileDialogBase − ＳａｖｅＡｓＦｉｌｅＤｉａｌｏｇおよびＳａｖｅＦｉｌｅＤｉａｌｏｇの親クラスとして使用される抽象クラス。
【０１０５】
＜列挙＞
FileDialogLayout
TileAttributes
【０１０６】
＜委任＞
DialogControlItemSelectedEventHandler
FileOkEventHandler
【０１０７】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｄｅｓｋｔｏｐ＞＞
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｄｅｓｋｔｏｐ名前空間によって公開されるメンバの例を示す。この名前空間には、サイドバーおよび通知にかかわる要素が含まれる。
【０１０８】
＜クラス＞
AnalogClockPanel
Appbar
AreaButton
BaseComTile
BaseSidebarClockSettings
BaseTile − カスタムサイドバータイル実装の親クラスとして使用される抽象クラス。
BasketControl
CalendarElement
CalendarImages
ChildrenWontFitArgs
ClockHacks
ClockPanel
DataSourceEventArgs − データソースから渡されるイベントデータを表す。
DigitalDateTimeElement
DragButton
DragControlWindow
DraggableButton
DragWindow
DropArgs
DropEventArgs
ExtraSpaceArgs
FillAlphaPresenter
FillImageResourcePresenter
FillPanel
FillPresenter
Flyout
FlyoutLinkClickEventArgs − サイドバータイルのフライアウト（flyout）ビューの最下部にあるオプションのリンクから発するイベントに応答してＲＭＡＡｃｔｉｏｎＥｖｅｎｔＨａｎｄｌｅｒに渡されるイベントデータを表す。
FlyoutPresenter
FlyoutStuff
FocusableButton
FocusWithinWorkaroundHelper
FolderContentsChangedEventArgs − フォルダの内容の変化に応答してＦｏｌｄｅｒＣｏｎｔｅｎｔｓＣｈａｎｇｅｄＥｖｅｎｔＨａｎｄｌｅｒに渡されるイベントデータを表す。
GlobalSetting
HackBorder
HackImage
ImageButton
ImageResource
ImageResourcePresenter
ItemControl
ItemToolbarControl
ListMakerControl
MenuStuff
NativeResource
NativeResourceHelper
NativeResources
NativeResourceTypeConverter
NormalButton
Notification − システムが１つのユーザインターフェースにおいてユーザに送るメッセージおよびそれに関連するデータを表す。
NotificationArea
NotificationButton − 通知に表示されるボタンを定義する。
NotificationClickedEventArgs − 通知ウィンドウ内でのクリックイベントに関連するデータを含む。
NotificationContext − アプリケーションが現在特定の状態であるか否かを宣言する。この状態は、ユーザのコンテキストの定義の一部として使用される。
NotificationTimerPresenter
NotifyCompleteEventArgs
NotifyWindow
OptionsButton
OuterTile
OverflowableCollection
OverflowableControlCollection
OverflowPanel
OverflowPresenter
OverFlowWrapper
PanelInfo
ProgressBar
QuickLaunchTile
RMAActionEventArgs − リッチミニマイズドアプリケーション（Rich Minimized Application、ＲＭＡ）によって生成されるイベントデータを表す。ＲＭＡＡｃｔｉｏｎＥｖｅｎｔＨａｎｄｌｅｒによって消費される。
RMAData
SetDataArrayEventArgs − データアレイによって生成され、ＳｅｔＤａｔａＡｒｒａｙＥｖｅｎｔＨａｎｄｌｅｒに送られるイベントデータを表す。
Sidebar
SidebarAlarmClock
SideBarClock
SidebarClockSettings
SlideShowTile
StackAlphaPresenter
StackImageResourcePresenter
StartButton
SyncHelper
SyncItemBar
SyncTile
Taskbar
TaskChevron
TaskGroup
TaskItem
TaskList
TaskOverflow
TaskOverflowableControlCollection
TaskPresenter
TestTile
TestTimeZone
TextElementFontInfo
Theme
ThemeHelper
ThemeHelperOld
ThemeImage
ThemeImageTypeConverter
ThemeResources
Tile
TileCollection
TileOverflow
TileThumb
TileThumbDotNet
Timer
TimerStuff
TimeZone
ViewStatusControl
WebHostEventArgs
WindowOrigin
WindowOriginOld
WindowStuff
【０１０９】
＜インターフェース＞
ICOMDataSourceHandler − 管理されないコードで実施されるデータソースを作成し、これと通信するのに使用される。
IOverflow
IOverflowList
ISidebar − 個々のタイルをホスティングするサイドバーへのアクセスを提供する。サイドバーホストは、フライアウトのオープンおよびクローズ、ショートカットメニューの表示、および個々のタイルに関連するイベントへの応答の責任を負う。
ISidebarAlarm
【０１１０】
＜列挙＞
AlarmState
BasketFlags
DragWindowPos
InvokeFolderActionEnum − ユーザがフォルダのＩｔｅｍＣｏｎｔｒｏｌを呼び出すときに行うことを決定するための列挙。ＩｎｖｏｋｅＦｏｌｄｅｒＡｃｔｉｏｎおよびＩｔｅｍＣｏｎｔｒｏｌＩｎｖｏｋｅＦｏｌｄｅｒＡｃｔｉｏｎと共に使用される。
RMAAction − イベントアクションを定義するためにＡｃｔｉｏｎプロパティと共に使用される定数。
SelectionModeEnum
【０１１１】
＜委任＞
ChildrenWontFitHandler
DocumentCompleteEventHandler
DropEventHandler
DropHandler
DummyDelegateToSetupAppDomainProperly
ExtraSpaceHandler
FlyoutClosingEventHandler
FlyoutLinkClickEventHandler − ＦｌｙｏｕｔＬｉｎｋＣｌｉｃｋＥｖｅｎｔイベントを処理するメソッドを表す。
FolderContentsChangedEventHandler
NavigateErrorEventHandler
NotificationClickedEventHandler − ＮｏｔｉｆｉｃａｔｉｏｎＣｌｉｃｋｅｄＥｖｅｎｔイベントを処理するメソッドを表す。
NotifyCompleteEventHandler − ＮｏｔｉｆｙＣｏｍｐｌｅｔｅＥｖｅｎｔイベントを処理するメソッドを表す。
RMAActionEventHandler − ＲＭＡＡｃｔｉｏｎＥｖｅｎｔイベントを処理するメソッドを表す。
SetDataArrayEventHandler − ＳｅｔＤａｔａＡｒｒａｙＥｖｅｎｔイベントを処理するメソッドを表す。
【０１１２】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔｒｏｌｓ＞＞
シェルコンポーネントによって使用されるクラスおよびインターフェースを提供する。
【０１１３】
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔｒｏｌｓ名前空間によって公開されるメンバの例を示す。
【０１１４】
＜クラス＞
ContactControl
ContactPickerDialog
ContactPropertyRequest
ContactPropertyRequestCollection
ContactSelection
ContactSelectionCollection
ContactTextBox
ContactTextBoxSelectionChangedEventArgs
ContactTextBoxTextChangedEventArgs
ContactTextBoxTextResolvedEventArgs
IncludeContactEventArgs
IteratedEventArgs
Iterator
OKCancelApplyEventArgs
OKCancelApplyStrip
【０１１５】
＜列挙＞
ContactControlPropertyPosition
ContactPickerDialogLayout
ContactPropertyCategory
ContactPropertyType
ContactType
OKCancelApplyType
【０１１６】
＜委任＞
ContactTextBoxSelectionChangedEventHandler
ContactTextBoxTextChangedEventHandler
ContactTextBoxTextResolvedEventHandler
IncludeContactEventHandler
IteratedEventHandler
OKCancelApplyEventHandler
OpenedEventHandler
【０１１７】
（例示的なコンピューティングシステムおよび環境）
図４に、プログラミングフレームワーク１３２を（完全にまたは部分的にのいずれかで）実施できる、適するコンピューティング環境４００の例を示す。コンピューティング環境４００は、本明細書に記載のコンピュータアーキテクチャおよびネットワークアーキテクチャで使用することができる。
【０１１８】
例示的なコンピューティング環境４００は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用の範囲または機能性に関する制限を示唆することを意図されたものではない。また、コンピューティング環境４００を、例示的なコンピューティング環境４００に示された、構成要素のいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。
【０１１９】
フレームワーク１３２を、多数の他の汎用または専用コンピューティングシステム環境または構成と共に実施することができる。使用に適する可能性がある衆知のコンピューティングシステム、コンピューティング環境、および／または構成の例に、パーソナルコンピュータ、サーバコンピュータ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれるが、これに制限されない。このフレームワークのコンパクト版またはサブセット版を、携帯電話、携帯情報端末、ハンドヘルドコンピュータ、または他の通信／コンピューティング装置などの限られたリソースのクライアントで実施することもできる。
【０１２０】
フレームワーク１３２を、１つまたは複数のコンピュータまたは他の装置によって実行される、プログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。フレームワーク１３２は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージ装置を含むローカルおよびリモートの両方のコンピュータストレージ媒体に配置することができる。
【０１２１】
コンピューティング環境４００に、コンピュータ４０２の形の汎用コンピューティング装置が含まれる。コンピュータ４０２のコンポーネントには、１つまたは複数のプロセッサまたは処理装置４０４、システムメモリ４０６、および処理装置４０４を含むさまざまなシステムコンポーネントをシステムメモリ４０６に接続するシステムバス４０８を含めることができるが、これに制限はされない。
【０１２２】
システムバス４０８は、メモリバスまたはメモリコントローラ、周辺バス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）、およびさまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む、複数の可能なタイプのバス構造の１つまたは複数を表す。たとえば、そのようなアーキテクチャに、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称するＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含めることができる。
【０１２３】
コンピュータ４０２に、通常は、さまざまなコンピュータ可読媒体が含まれる。そのような媒体は、揮発性媒体および不揮発性媒体、リムーバブル媒体および固定の媒体の両方を含む、コンピュータ４０２によってアクセス可能である任意の使用可能な媒体とすることができる。
【０１２４】
システムメモリ４０６には、ランダムアクセスメモリ（ＲＡＭ）４１０などの揮発性メモリおよび／または読取専用メモリ（ＲＯＭ）４１２などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。起動中などにコンピュータ４０２内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）４１４が、ＲＯＭ４１２に保管される。ＲＡＭ４１０には、通常は、処理装置４０４によって即座にアクセス可能および／または処理装置４０４によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。
【０１２５】
コンピュータ４０２に、他のリムーバブル／固定の、揮発性／不揮発性コンピュータストレージを含めることもできる。たとえば、図４に、固定の不揮発性磁気媒体（図示せず）から読み取り、これに書き込むハードディスクドライブ４１６、リムーバブル不揮発性磁気ディスク４２０（たとえば「フロッピ(登録商標)ディスク」）から読み取り、これに書き込む磁気ディスクドライブ４１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などのリムーバブル不揮発性光ディスク４２４から読み取り、かつ／またはこれに書き込む光ディスクドライブ４２２が含まれる。ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２は、それぞれ、１つまたは複数のデータメディアインターフェース４２３によってシステムバス４０８に接続される。その代わりに、ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２を、１つまたは複数のインターフェース（図示せず）によってシステムバス４０８に接続することができる。
【０１２６】
ディスクドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ４０２のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージを提供する。この例では、ハードディスク４１６、リムーバブル磁気ディスク４２０、およびリムーバブル光ディスク４２４が示されているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ）、および類似物などのコンピュータによってアクセス可能なデータを保管できる他のタイプのコンピュータ可読媒体を使用して、例示的なコンピューティングシステムおよび環境を実施することもできることを理解されたい。
【０１２７】
たとえば、オペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２を含む、任意の個数のプログラムモジュールを、ハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ４１２、および／またはＲＡＭ４１０に保管することができる。オペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２（またはその組合せ）に、プログラミングフレームワーク１３２の要素を含めることができる。
【０１２８】
ユーザは、キーボード４３４およびポインティング装置４３６（たとえば「マウス」）などの入力装置を介してコンピュータ４０２にコマンドおよび情報を入力することができる。他の入力装置４３８（具体的には図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、シリアルポート、スキャナ、および／または類似物を含めることができる。上記および他の入力装置は、システムバス４０８に接続された入出力インターフェース４４０を介して処理装置４０４に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などの他のインターフェースおよびバス構造によって接続することができる。
【０１２９】
モニタ４４２または他のタイプの表示装置を、ビデオアダプタ４４４などのインターフェースを介してシステムバス４０８に接続することもできる。モニタ４４２のほかに、他の出力周辺装置に、スピーカ（図示せず）およびプリンタ４４６など、入出力インターフェース４４０を介してコンピュータ４０２に接続できるコンポーネントを含めることができる。
【０１３０】
コンピュータ４０２は、リモートコンピューティング装置４４８などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。たとえば、リモートコンピューティング装置４４８を、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の一般的なネットワークノード、などとすることができる。リモートコンピューティング装置４４８は、コンピュータ４０２に関して本明細書で説明した要素および特徴の多くまたはすべてを含めることができるポータブルコンピュータとして図示されている。
【０１３１】
コンピュータ４０２とリモートコンピュータ４４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５０および一般的な広域ネットワーク（ＷＡＮ）４５２として図示されている。そのようなネットワーキング環境は、オフィス、会社規模のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【０１３２】
ＬＡＮネットワーキング環境において実施されるときに、コンピュータ４０２は、ネットワークインターフェースまたはネットワークアダプタ４５４を介してローカルネットワーク４５０に接続される。ＷＡＮネットワーキング環境において実施されるときに、コンピュータ４０２に、通常は、広域ネットワーク４５２を介する通信を確立する、モデム４５６または他の手段が含まれる。モデム４５６は、コンピュータ４０２の内蔵または外付けとすることができるが、入出力インターフェース４４０または他の適当な機構を介してシステムバス４０８に接続することができる。図示のネットワーク接続が、例示的であり、コンピュータ４０２と４４８の間の通信リンクを確立する他の手段を使用できることを理解されたい。
【０１３３】
コンピューティング環境４００と共に図示されたものなどのネットワーク化された環境において、コンピュータ４０２に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置に保管することができる。たとえば、リモートアプリケーションプログラム４５８が、リモートコンピュータ４４８の記憶装置に常駐している。例示のために、アプリケーションプログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントが、本明細書では別個のブロックに図示されているが、そのようなプログラムおよびコンポーネントが、さまざまなときにコンピューティング装置４０２の異なるストレージコンポーネントに常駐することができ、コンピュータのデータプロセッサによって実行されることを理解されたい。
【０１３４】
フレームワーク１３２、具体的にはＡＰＩ１４２またはＡＰＩ１４２に対して行われる呼出しの実装を、ある形のコンピュータ可読媒体を介して保管または伝送することができる。コンピュータ可読媒体は、コンピュータによってアクセスできる任意の使用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体に、「コンピュータストレージ媒体」および「通信媒体」を含めることができる。「コンピュータストレージ媒体」には、揮発性および不揮発性、取外し可能および取外し不能の、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージに関する方法またはテクノロジで実施される媒体が含まれる。コンピュータストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気記憶装置、あるいは、所望の情報を保管するのに使用でき、コンピュータによってアクセスできる他のすべての媒体が含まれるが、これに制限はされない。
【０１３５】
「通信媒体」によって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが実施される。通信媒体には、すべての情報配信媒体も含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形で、その特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれる。
【０１３６】
その代わりに、フレームワークの諸部分を、ハードウェアで、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組合せで実施することができる。たとえば、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）またはプログラマブルロジックデバイス（ＰＬＤ）を設計またはプログラムして、本フレームワークの１つまたは複数の部分を実施することができる。
【０１３７】
プログラミングインターフェース（または単にインターフェース）は、コードの１つまたは複数のセグメントが、コードの１つまたは複数の他のセグメントと通信するかそのセグメントによって提供される機能性にアクセスできるようにする機構、処理、プロトコルとみなすことができる。その代わりに、プログラミングインターフェースを、他のコンポーネントの１つまたは複数の機構、メソッド、関数呼出し、モジュールなどとの通信接続が可能なシステムのコンポーネントの１つまたは複数の機構、メソッド、関数呼出し、モジュール、オブジェクトなどとみなすことができる。前の文の用語「コードのセグメント」は、コードの１つまたは複数の命令または行を含むことが意図されており、これには、使用される用語、コードセグメントが別々にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードのどれとして提供されるか、コードセグメントがランタイムシステム内またはプロセス内で使用されるかどうか、コードセグメントが同一のマシンまたは異なるマシンに配置されるか、あるいはマシンにまたがって分散されるかどうか、コードのセグメントによって表される機能性が、完全にソフトウェアで、完全にハードウェアで、あるいはハードウェアとソフトウェアの組合せのどれで実施されるかに無関係に、たとえば、コードモジュール、オブジェクト、サブルーチン、関数などが含まれる。
【０１３８】
概念上、プログラミングインターフェースは、一般的に、図５または図６に示されているように見ることができる。図５に、第１コードセグメントと第２コードセグメントがそれを介して通信する導管としてのインターフェースＩｎｔｅｒｆａｃｅ１を示す。図６に、システムの第１コードセグメントおよび第２コードセグメントが媒体Ｍを介して通信できるようにする、インターフェースオブジェクトＩ１およびＩ２（第１および第２コードセグメントの一部とすることも、そうしないこともできる）を含むものとしてインターフェースを示す。図６に鑑みて、インターフェースオブジェクトＩ１およびＩ２を、同一のシステムの別々のインターフェースと考えることができ、オブジェクトＩ１およびＩ２と媒体Ｍにインターフェースが含まれると考えることもできる。図５および７に、両方向のフローおよびフローの両側のインターフェースを示したが、ある実施形態では、一方向の情報フローだけを有する（または、下で示すように情報フローなし）ことができ、あるいは、片側だけにインターフェースオブジェクトを有することができる。制限ではなく例として、アプリケーションプログラミングまたはプログラムインターフェース（ＡＰＩ）、エントリポイント、メソッド、関数、サブルーチン、リモートプロシージャコール、およびコンポーネントオブジェクトモデル（ＣＯＭ）インターフェースなどの用語が、プログラミングインターフェースの定義に含まれる。
【０１３９】
そのようなプログラミングインターフェースの態様に、第１コードセグメントが情報（ここで、「情報」は、その最も広い意味で使用され、「情報」には、データ、コマンド、要求などが含まれる）を第２コードセグメントに送る方法と、第２コードセグメントがその情報を受け取る方法と、情報の構造、シーケンス、構文、編成、スキーマ、タイミング、および内容とを含めることができる。これに関して、基礎になるトランスポート媒体自体は、媒体が有線、無線またはその両方の組合せのどれであれ、インターフェースによって定義される形で情報がトランスポートされる限り、インターフェースの動作に重要でない可能性がある。ある状況では、情報転送が別の機構を介する（たとえば、情報が、コードセグメントの間で流れる情報と別に、バッファ、ファイルなどに置かれる）ので、従来の意味で一方向または両方向に渡されないか、あるコードセグメントが第２コードセグメントによって実行される機能性に単純にアクセスするので情報が存在しない場合がある。これらの態様のいずれかまたはすべてが、所与の状況で、たとえば、コードセグメントが疎結合された構成または密結合された構成のどちらの一部であるかに応じて、重要になる可能性があり、したがって、このリストは、例示的であり、非限定的とみなされなければならない。
【０１４０】
プログラミングインターフェースのこの概念は、当業者に既知であり、本発明の前述の詳細な説明から明白である。しかし、プログラミングインターフェースを実施する他の形があり、明示的に除外されない限り、これらも、本明細書に記載の請求項に含まれることが意図されている。そのような他の形は、図５および７の極度に単純化された図よりも洗練されて見える、または複雑に見える可能性があるが、それでも、そのような他の形によって、同一の全体的な結果を達成する類似する機能が実行される。これから、プログラミングインターフェースの例示的な代替実施形態を短く説明する。
【０１４１】
Ａ．因数分解
あるコードセグメントから別のコードセグメントへの通信は、通信を複数の個別の通信に分解することによって、間接的に達成することができる。これを、図７および９に概略的に示す。図からわかるように、いくつかのインターフェースを、機能性の分割可能なセットとして記述することができる。したがって、数学的に２４または２×２×３×２を提供するように、図５および７のインターフェースの機能性を因数分解して、同一の結果を達成することができる。したがって、図７からわかるように、インターフェースＩｎｔｅｒｆａｃｅ１によって提供される機能を再分割して、このインターフェースの通信を複数のインターフェース、Ｉｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃなどに変換し、同一の結果を達成することができる。図８からわかるように、インターフェースＩ１によって提供される機能性を、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに再分割し、それと同時に同一の結果を達成することができる。同様に、第１コードセグメントから情報を受け取る第２コードセグメントのインターフェースＩ２を、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに因数分解することができる。因数分解するときに、第１コードセグメントに含まれるインターフェースの数が、第２コードセグメントに含まれるインターフェースの数と一致する必要はない。図７および９のどちらの場合でも、インターフェースＩｎｔｅｒｆａｃｅ１およびＩ１の機能的趣旨は、それぞれ図５および７と同一のままである。インターフェースの因数分解は、関連するプロパティ、累算的プロパティ、および他の数学的プロパティに従う場合もあり、因数分解の理解が困難な場合がある。たとえば、動作の順序付けは、重要でない場合があり、その結果、あるインターフェースによって実行される機能を、別のコードまたはインターフェースによって、インターフェースに達するよりかなり前に実行することができ、あるいは、システムの別々の構成要素によって実行することができる。さらに、プログラミング技術の当業者は、同一の結果を達成する異なる関数呼出しを行うさまざまな形があることを理解することができる。
【０１４２】
Ｂ．再定義
いくつかの場合に、初期の結果を達成しながら、プログラミングインターフェースのある態様（たとえばパラメータ）を無視し、追加し、または再定義することが可能である場合がある。これを、図９および１１に示す。たとえば、図５のインターフェースＩｎｔｅｒｆａｃｅ１に、関数呼出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、ｏｕｔｐｕｔ）すなわち、３つのパラメータｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、およびｏｕｔｐｕｔを含む呼出しであって、第１コードセグメントから第２コードセグメントに発行される関数呼出しが含まれると仮定する。真ん中のパラメータｐｒｅｃｉｓｉｏｎが、図９に示されているように、所与のシナリオで関係がない場合に、無視することができ、意味のない（この状況）パラメータと置換することができる。関係のない追加のパラメータを追加することもできる。どちらの場合でも、ｉｎｐｕｔが第２コードセグメントによって二乗された後にｏｕｔｐｕｔが返される限り、ｓｑｕａｒｅ（二乗）の機能性を達成することができる。ｐｒｅｃｉｓｉｏｎ（精度）は、コンピューティングシステムの下流または他の部分に意味のあるパラメータとすることもできるが、二乗計算の狭い目的について精度が必要でないことが理解されたならば、置換するか無視することができる。たとえば、結果に悪影響を及ぼさずに、有効な精度値を渡すのではなく、誕生日などの意味のある値を渡すことができる。同様に、図１０に示されているように、インターフェースＩ１が、インターフェースへのパラメータを無視するか追加するために再定義されたインターフェースＩ１’に置換される。インターフェースＩ２は、同様に、不要なパラメータを無視するか、ほかで処理できるパラメータについて再定義されたインターフェースＩ２’として再定義することができる。ここでのポイントは、いくつかの場合に、プログラミングインターフェースに、パラメータなど、ある目的に不要な態様が含まれる場合があり、したがって、それらを無視するか再定義することができ、あるいは、他の目的のために他の形で処理できるということである。
【０１４３】
Ｃ．インラインコーディング
２つの別々のコードモジュールの機能性の一部またはすべてをマージし、これらの間の「インターフェース」の形を変えることが実行可能である場合もある。たとえば、図５および７の機能性を、それぞれ図１１および１３の機能性に変換することができる。図１１では、図５の前の第１コードセグメントおよび第２コードセグメントが、その両方を含む１つのモジュールにマージされている。この場合に、コードセグメントは、まだ互いに通信することができるが、インターフェースは、単一モジュールにより適する形に適合させることができる。したがって、たとえば、前のＣａｌｌステートメントおよびＲｅｔｕｒｎステートメントは、もはや不要とすることができるが、インターフェースＩｎｔｅｒｆａｃｅ１に準ずる類似する処理または応答を、まだ有効とすることができる。同様に、図１２では、図６のインターフェースＩ２の一部（またはすべて）を、インターフェースＩ１にインラインで記述して、インターフェースＩ１”を形成することができる。図からわかるように、インターフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａは、インターフェースＩ１とインラインにコーディングされて、インターフェースＩ１”を形成する。具体的な例として、図６のインターフェースＩ１が、関数呼出しｓｑｕａｒｅ（ｉｎｐｕｔ、ｏｕｔｐｕｔ）を実行し、これがインターフェースＩ２によって受け取られ、インターフェースＩ２は、第２コードセグメントによるｉｎｐｕｔを用いて渡された値の処理（二乗）の後に、二乗された結果にｏｕｔｐｕｔを用いて返すことを検討されたい。その場合に、第２コードセグメントによって実行される処理（ｉｎｐｕｔの二乗）を、インターフェースへの呼出しなしで、第１コードセグメントによって実行することができる。
【０１４４】
Ｄ．分離（ｄｉｖｏｒｃｅ）
あるコードセグメントから別のコードセグメントへの通信は、通信を複数の個別の通信に分解することによって、間接的に達成することができる。これを、図１３および１５に示す。図１３からわかるように、１または複数のミドルウェア（機能性および／またはインターフェース機能を元のインターフェースから分離するので、分離インターフェース）を設けて、第１インターフェースＩｎｔｅｒｆａｃｅ１の通信を、異なるインターフェース、この例ではインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃに従うように変換する。たとえば、これは、たとえばＩｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのインストールベースがあるが、そのオペレーティングシステムが、異なるインターフェース、この例ではインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃを使用するように変更される場合に行うことができる。ポイントは、第２コードセグメントによって使用された元のインターフェースが、もはや第１コードセグメントによって使用されるインターフェースと互換でなくなるように変更され、したがって、古いインターフェースと新しいインターフェースとに互換性を持たせるため、仲介物が使用されることである。同様に、図１４からわかるように、インターフェースＩ１からの通信を受け取る分離インターフェースＤＩ１を有し、インターフェース機能性を、たとえば、ＤＩ２と共に働くが同一の機能的結果を提供するように再設計されているインターフェースＩ２ａおよびＩ２ｂに送る、分離インターフェースＤＩ２を有する第３コードセグメントを導入することができる。同様に、ＤＩ１およびＤＩ２は、同一のまたは類似する機能的結果を提供しながら、図６のインターフェースＩ１およびＩ２の機能性を変換するように一緒に働くことができる。
【０１４５】
Ｅ．再記述
もう１つの可能な変形形態が、コードを動的に再記述して、インターフェース機能性を、同一の総合的な結果を達成する別のものに置換することである。たとえば、中間言語（たとえば、Ｍｉｃｒｏｓｏｆｔ（登録商標） ＩＬ、Ｊａｖａ（登録商標） ＢｙｔｅＣｏｄｅなど）で提示されるコードセグメントを、実行環境（．ＮＥＴ ｆｒａｍｅｗｏｒｋ（登録商標）、Ｊａｖａ（登録商標）ランタイム環境、または類似するランタイムタイプ環境によって提供されるものなど）内のジャストインタイム（ＪＩＴ）コンパイラまたはインタープリタに供給するシステムがある。ＪＩＴコンパイラは、第１コードセグメントから第２コードセグメントへの通信を動的に変換する、すなわち、それらを、第２コードセグメント（元のまたは異なる第２コードセグメント）が必要とする可能性がある異なるインターフェースに合わせることができる。これを、図１５および１７に示す。図１５からわかるように、この手法は、上で説明した分離シナリオに似ている。これは、たとえば、アプリケーションのインストールベースが、Ｉｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティングシステムと通信するように設計されているが、オペレーティングシステムが、異なるインターフェースを使用するように変更される場合に行うことができる。ＪＩＴコンパイラを使用して、通信を、オンザフライでインストールベースアプリケーションからオペレーティングシステムの新しいインターフェースに合わせることができる。図１６からわかるように、インターフェースを動的に再記述するこの手法は、動的因数分解、または他の形のインターフェースの変更にも適用することができる。
【０１４６】
代替実施形態を介してインターフェースとして同一のまたは類似する結果を達成する、上で説明したシナリオを、さまざまな形で、順次および／または並列で、または他の介在コードと共に、組みわせることもできることにも留意されたい。したがって、上で提示した代替実施形態は、相互に排他的ではなく、混合され、マッチングされ、かつ組み合わされて、図５および７で提示された包括的なシナリオと同一のまたは同等のシナリオを作ることができる。また、ほとんどのプログラミング構造と同様に、本明細書に記載されていないが、それでも本発明の趣旨および範囲によって表されるインターフェースの同一のまたは類似する機能性を達成する他の類似する形があることに留意されたい、すなわち、インターフェースの価値の基礎になるのは、少なくとも部分的に、インターフェースによって表される機能性と、インターフェースによって使用可能にされる有益な結果である。
【０１４７】
（結論）
本発明を、構造的特徴および／または方法論的動作に固有の言葉で説明したが、請求項で定義される本発明は、説明した特定の特徴または動作に必ずしも制限されないことを理解されたい。そうではなく、特定の特徴および動作は、請求される発明を実施する例示的な形として開示されたものである。
【符号の説明】
【０１４８】
１００ ネットワーク環境
１０４ ネットワーク
１０６，１１２，１１４，１２２〜１２９ 通信リンク
１３２ プログラミングフレームワーク
１４２ ＡＰＩレイヤ
４００ コンピューティング環境
４１６ ハードディスクドライブ
４１８ 磁気ディスクドライブ
４２２ 光ディスクドライブ
４２０ リムーバブル不揮発性磁気ディスク
４２４ リムーバブル不揮発性光ディスク
４３８ 入力装置
【技術分野】
【０００１】
本発明は、ソフトウェアおよびそのようなソフトウェアの開発に関する。より詳細には、アプリケーションプログラムおよびコンピュータハードウェアによる、ソフトウェアプラットフォームの使用を容易にするプログラミングインターフェースに関する。
【背景技術】
【０００２】
非常に早くから、コンピュータソフトウェアは、「オペレーティングシステム」ソフトウェアまたは「アプリケーション」ソフトウェアとして分類されるようになった。おおまかにいって、アプリケーションは、数学の方程式を解くか、またはワードプロセッシングをサポートするなど、コンピュータユーザのために特定のタスクを実行することを意図されたソフトウェアである。オペレーティングシステムは、コンピュータハードウェアを管理し、制御するソフトウェアである。オペレーティングシステムの目標は、コンピュータリソースをアプリケーションプログラマが使用可能にすると同時に、ハードウェアを実際に制御するのに必要な複雑さを隠蔽することである。
【０００３】
オペレーティングシステムは、アプリケーションプログラムインターフェースまたはＡＰＩとして周知の機能または関数を介してリソースを使用可能にする。用語ＡＰＩは、これらの機能のうちの単一の関数を指すのにも使用される。関数は、多くの場合、アプリケーションプログラマに提供するリソースまたはサービスに関してグループ化される。アプリケーションソフトウェアは、個々のＡＰＩ関数を呼び出すことによってリソースを要求する。ＡＰＩ関数は、オペレーティングシステムによって提供されるメッセージおよび情報をアプリケーションソフトウェアに中継する手段としても働く。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願第０９／５９８，１０５号明細書
【特許文献２】米国特許出願第０９／６１３，２８９号明細書
【特許文献３】米国特許出願第１０／０６３，２９６号明細書
【特許文献４】米国特許出願第１０／４０２，１７９号明細書
【特許文献５】米国特許出願第１０／３２４，７４６号明細書
【非特許文献】
【０００５】
【非特許文献１】［online］、ＥＣＭＡ、〈URL:www.ecma.ch〉
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ハードウェアの変更のほかに、オペレーティングシステムソフトウェアの進化を駆り立てるもう１つの要因が、アプリケーションソフトウェア開発を単純化し、加速する要望である。アプリケーションソフトウェア開発は、困難な作業になる場合があり、時折、数百万行のコードによって高度化されたプログラムを作成するために数年の開発者の時間を必要とする。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのさまざまなバージョンなどの広く使用されているオペレーティングシステムに関して、アプリケーションソフトウェア開発者は、そのオペレーティングシステムを利用する数千本の異なるアプリケーションを毎年記述している。そのように多くの異なるアプリケーション開発者をサポートするために、一貫性のある（coherent）、利便性の高いオペレーティングシステムベースが必要である。
【０００７】
多くの場合、オペレーティングシステムをより複雑にすることによって、アプリケーションソフトウェアの開発を単純にすることができる。すなわち、ある機能が、複数の異なるアプリケーションプログラムに有用であり得る場合に、その機能をオペレーティングシステムに含めるために一度記述することが、数十人のソフトウェア開発者が数十本の異なるアプリケーションに含めるために数十回記述することを要求するよりよい場合がある。このように、オペレーティングシステムが、複数のアプリケーションによって要求される広範囲の共通の機能性をサポートする場合、アプリケーションソフトウェア開発のコストおよび時間においてかなりの節約を達成することができる。
【０００８】
オペレーティングシステムとアプリケーションソフトウェアの間のどこに線が引かれるかに関係なく、有用なオペレーティングシステムについて、オペレーティングシステムおよびコンピュータハードウェアとアプリケーションソフトウェアとの間のＡＰＩは、オペレーティングシステム自体の効率的な内部動作と同様に重要であることは明白である。
【０００９】
過去数年間に、インターネットおよびネットワーク技術全般の万国での採用によって、コンピュータソフトウェア開発者の情景が変化した。従来、ソフトウェア開発者は、独立型デスクトップコンピュータまたはローカルエリアネットワーク（ＬＡＮ）を介して、限られた数の他のコンピュータに接続されたＬＡＮベースコンピュータの単一サイトソフトウェアアプリケーションに焦点を合わせていた。ソフトウェアが、シュリンクラップパッケージでマーケティングされ、販売されたので、そのようなソフトウェアアプリケーションを、通常は、「シュリンクラップ」製品と称する。これらのアプリケーションは、明確に定義されたＡＰＩを使用して、コンピュータの基礎になるオペレーティングシステムにアクセスした。
【００１０】
インターネットが進化し、広く受け入れられたので、産業界は、ワールドワイドウェブ（または単に「ウェブ」）のさまざまなサイトでのアプリケーションのホスティングの威力を理解し始めた。ネットワーク化された世界では、あらゆる場所のクライアントが、個別の位置でホスティングされるサーバベースのアプリケーションに要求をサブミットし、数分の１秒で応答を受信することができる。しかし、これらのウェブアプリケーションは、通常は、元々は独立型コンピューティングマシンまたはローカルにネットワーク化されたコンピュータのために開発されたものと同一のオペレーティングシステムプラットフォームを使用して開発された。残念ながら、いくつかの場合に、これらのアプリケーションは、分散コンピューティング管理様式に適切に移行されていない。基礎になるプラットフォームは、単純に、無制限の数の相互接続されたコンピュータをサポートするという観念を用いて構成されていなかった。
【００１１】
インターネットによって導入された分散コンピューティング環境へのシフトに対処するために、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎは、「．ＮＥＴ」Ｆｒａｍｅｗｏｒｋ（「ドットネット」と読む）またはＭｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴと称するネットワークソフトウェアプラットフォームを開発した。Ｍｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴは、人、情報、システム、および装置を接続するソフトウェアである。このプラットフォームを用いると、開発者が、インターネットを介して実行されるウェブサービス（Ｗｅｂ ｓｅｒｖｉｃｅ）を作成できるようになる。この動的なシフトは、Ｍｉｃｒｏｓｏｆｔの．ＮＥＴ（商標）ＦｒａｍｅｗｏｒｋのＡＰＩ関数のセットによって達成された。
【００１２】
．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋの使用がますます一般的になるにつれて、このプラットフォームの効率および／または性能を高める形が特定された。本発明人は、そのような高められた効率および／または性能を可能にするプログラミングインターフェース関数の独自のセットを開発した。
【課題を解決するための手段】
【００１３】
コンピュータプラットフォームのプログラミングインターフェースを本明細書で説明する。
【００１４】
ある態様によれば、プログラミングインターフェースに、再利用可能なユーザインターフェースコントロールに関連するサービスの第１群と、ユーザインターフェースダイアログおよびユーザインターフェースウィザードに関連するサービスの第２群と、ユーザインターフェース機能性の拡張に関連するサービスの第３群と、ユーザインターフェースのデスクトップの機能性の拡張に関連するサービスの第４群との１つまたは複数を含めることができる。
【００１５】
同一の符号は、複数の図面を通じて同一の特徴を指すのに使用される。
【図面の簡単な説明】
【００１６】
【図１】クライアントが、従来のプロトコルを使用するインターネットを介してウェブサービスにアクセスする、ネットワークアーキテクチャを示す図である。
【図２】アプリケーションプログラムインターフェース（ＡＰＩ）を含むネットワークプラットフォームのソフトウェアアーキテクチャを示すブロック図である。
【図３】ＡＰＩによってサポートされる独自の名前空間ならびにさまざまなＡＰＩ関数の機能クラスを示すブロック図である。
【図４】ソフトウェアアーキテクチャのすべてまたは一部を実行することができる例示的コンピュータを示すブロック図である。
【図５】プログラミングインターフェースの例の実施形態を示す図である。
【図６】プログラミングインターフェースの例の実施形態を示す図である。
【図７】プログラミングインターフェースの例の実施形態を示す図である。
【図８】プログラミングインターフェースの例の実施形態を示す図である。
【図９】プログラミングインターフェースの例の実施形態を示す図である。
【図１０】プログラミングインターフェースの例の実施形態を示す図である。
【図１１】プログラミングインターフェースの例の実施形態を示す図である。
【図１２】プログラミングインターフェースの例の実施形態を示す図である。
【図１３】プログラミングインターフェースの例の実施形態を示す図である。
【図１４】プログラミングインターフェースの例の実施形態を示す図である。
【図１５】プログラミングインターフェースの例の実施形態を示す図である。
【図１６】プログラミングインターフェースの例の実施形態を示す図である。
【発明を実施するための形態】
【００１７】
この開示は、開発者がウェブアプリケーションおよびウェブサービスを構築できるネットワークプラットフォームのアプリケーションプログラムインターフェース（ＡＰＩ）などのプログラミングインターフェースを扱う。具体的に言うと、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって作成された．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋなどのネットワークプラットフォームを利用するオペレーティングシステムの例示的ＡＰＩを説明する。．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋは、分散コンピューティング環境で実施されるウェブサービスおよびウェブアプリケーションのソフトウェアプラットフォームである。．ＮＥＴ Ｆｒａｍｅｗｏｒｋは、特定のタスクを実行するために協力している疎結合ウェブサービスの間の通信にオープン通信標準規格（open communication standards）を使用する、次世代のインターネットコンピューティングを表す。
【００１８】
説明する実施形態で、ネットワークプラットフォームは、ＸＭＬ（extensible markup language）すなわちデータを記述するオープン標準規格を使用する。ＸＭＬは、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって管理される。ＸＭＬは、ウェブページおよび企業間文書のデータ要素を定義するのに使用される。ＸＭＬでは、ＨＴＭＬに類似するタグ構造が使用されるが、ＨＴＭＬは、要素をどのように表示するかを定義し、ＸＭＬは、それらの要素に何が含まれるかを定義する。ＨＴＭＬでは、予め定義されたタグを使用するが、ＸＭＬでは、ページの開発者がタグを定義することができる。したがって、事実上任意のデータアイテムを識別することができ、ウェブページが、データベースレコードのように機能することができる。ＸＭＬおよびシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）などの他のオープンプロトコルの使用を介して、ネットワークプラットフォームが、ユーザの必要に合わせて調整できる広範囲のサービスの統合を可能にする。本明細書に記載の実施形態を、ＸＭＬおよび他のオープン標準規格と共に説明するが、これは、請求される発明の動作に必要ではない。他の同等に実行可能な技術が、本明細書に記載の発明を実施するのに十分である。
【００１９】
本明細書で使用される句、アプリケーションプログラムインターフェースまたはＡＰＩには、メソッド呼出しまたは関数呼出しを使用する従来のインターフェースならびに、リモート呼出し（たとえばプロキシ、スタブ関係）およびＳＯＡＰ／ＸＭＬ呼出しが含まれる。
【００２０】
（例示的ネットワーク環境）
図１に、．ＮＥＴ（商標）Ｆｒａｍｅｗｏｒｋなどのネットワークプラットフォームを実装できるネットワーク環境１００を示す。ネットワーク環境１００には、ネットワーク１０４（たとえばインターネット）上でアクセスできるサービスを提供する、代表的なウェブサーバ１０２（１）、…、１０２（Ｎ）が含まれる。一般に符号１０２として参照されるウェブサービスは、リモートプロシージャコール（ＲＰＣ）またはオブジェクトブローカ型技術などの、ネットワークを介してウェブサービスと相互作用する他の手段も使用することができるが、通常は、ＸＭＬ、ＳＯＡＰ、ＷＡＰ（wireless application protocol）、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、およびＳＭＴＰ（シンプルメール転送プロトコル）などの産業界標準ウェブプロトコルを介してネットワーク１０４上でプログラム的に相互作用する、再利用可能なプログラマブルアプリケーションコンポーネントである。ウェブサービスは、自己記述的とすることができ、しばしば、メッセージのフォーマットおよび順序に関して定義される。
【００２１】
ウェブサービス１０２は、他のサービス（通信リンク１０６によって表されるように）、またはウェブアプリケーション１１０などのソフトウェアアプリケーション（通信リンク１１２および１１４によって表されるように）によって直接にアクセス可能である。各ウェブサービス１０２は、特定のサービスに関する要求を処理するソフトウェアを実行する１つまたは複数のサーバを含むものとして示されている。そのようなサービスは、しばしば、要求元にサービスされる情報を保管するデータベースを維持する。ウェブサービスを構成して、さまざまな異なるサービスの任意の１つを実行することができる。ウェブサービスの例に、ログイン検証、通知、データベース保管、株式市況、ディレクトリの突き止め、地図作成、音楽、電子ウォレット、カレンダ／スケジューラ、電話リスティング、ニュースおよび情報、ゲーム、発券業務などが含まれる。ウェブサービスを、互いにおよび他のアプリケーションと組み合わせて、インテリジェント対話経験を構築することができる。
【００２２】
ネットワーク環境１００には、ウェブサービス１０２（通信リンク１２２によって表される）および／またはウェブアプリケーション１１０（通信リンク１２４、１２６、および１２８によって表される）を使用する代表的なクライアント装置１２０（１）、１２０（２）、１２０（３）、１２０（４）、…、１２０（Ｍ）も含まれる。クライアントは、クライアント１２０（３）と１２０（４）の間の例示的なＸＭＬリンク１２９によって表されるように、標準プロトコルを使用して互いに通信することもできる。
【００２３】
全般的に符号１２０として参照されるクライアント装置は、多数の異なる形で実施することができる。可能なクライアント実施形態の例に、制限なしに、ポータブルコンピュータ、ステーショナリコンピュータ、タブレットＰＣ、テレビジョン／セットトップボックス、無線通信装置、携帯情報端末、ゲーム機、プリンタ、コピー機、および他のスマート装置が含まれる。
【００２４】
ウェブアプリケーション１１０は、ネットワークプラットフォームで動作するように設計されたアプリケーションであり、クライアント１２０からの要求を処理し、サービスするときに、ウェブサービス１０２を使用することができる。ウェブアプリケーション１１０は、プログラミングフレームワーク１３２上で稼動する１つまたは複数のソフトウェアアプリケーション１３０からなり、ソフトウェアアプリケーション１３０は、１つまたは複数のサーバ１３４または他のコンピュータシステムで実行されている。ウェブアプリケーション１１０の一部が、実際には１つまたは複数のクライアント１２０に常駐する場合があることに留意されたい。その代わりに、ウェブアプリケーション１１０が、実際にタスクを達成するクライアント１２０上の他のソフトウェアを調整することができる。
【００２５】
プログラミングフレームワーク１３２は、アプリケーション開発者によって開発されるアプリケーションおよびサービスをサポートする構造である。プログラミングフレームワーク１３２は、複数の言語をサポートすることによって、マルチ言語開発およびシームレス統合を可能にする。プログラミングフレームワーク１３２は、ＳＯＡＰなどのオープンプロトコルをサポートし、基礎になるオペレーティングシステムサービスおよびオブジェクトモデルサービスをカプセル化する。このフレームワークは、複数のプログラミング言語の堅牢で保護された実行環境を提供し、保護され、統合されたクラスライブラリを提供する。
【００２６】
フレームワーク１３２は、アプリケーションプログラムインターフェース（ＡＰＩ）レイヤ１４２、共通言語ランタイム（ＣＬＲ）レイヤ１４４、およびオペレーティングシステム／サービスレイヤ１４６を含むマルチティアアーキテクチャである。この階層アーキテクチャを用いると、フレームワークの他の部分に影響せずに、さまざまなレイヤに対する更新および修正が可能になる。共通言語仕様（ＣＬＳ）１４０を用いると、さまざまな言語の設計者が、基礎になるライブラリ機能性にアクセスできるコードを記述できるようになる。共通言語仕様１４０は、言語設計者とライブラリ設計者の間の、言語インターオペラビリティを促進するのに使用できるコントラクトとして機能する。ＣＬＳを厳守することによって、ある言語で記述されたライブラリは、別の言語で記述されたコードモジュールから直接にアクセスでき、ある言語で記述されたコードモジュールと別の言語で記述されたコードモジュールの間のシームレスな統合を達成することができる。ＣＬＳの１つの例示的な詳細な実施形態が、ＥＣＭＡ ＴＣ３９／ＴＧ３の参加者によって作成されたＥＣＭＡ標準規格である。非特許文献１を参照されたい。
【００２７】
ＡＰＩレイヤ１４２は、アプリケーション１３０が、レイヤ１４６によって提供されるリソースおよびサービスにアクセスするために呼び出す関数のグループを提供する。ネットワークプラットフォームに対するＡＰＩ関数を公開することによって、アプリケーション開発者は、ネットワークリソースが実際にどのように動作するかまたは使用可能にされるかの複雑な相互作用を理解する必要なしに、ネットワークリソースおよび他のウェブサービスを完全に利用する分散コンピューティングシステム用のウェブアプリケーションを作成することができる。さらに、ウェブアプリケーションを、任意の数のプログラミング言語で記述でき、共通言語ランタイムレイヤ１４４によってサポートされ、共通言語仕様１４０の一部として含まれる中間言語に変換することができる。この形で、ＡＰＩレイヤ１４２が、広範囲のさまざまなアプリケーションにメソッドを提供することができる。
【００２８】
さらに、フレームワーク１３２を、フレームワークをホスティングするサーバ１３４からリモートに実行されるリモートアプリケーションによって設定される、ＡＰＩ呼出しをサポートするように構成することができる。それぞれクライアント１２０（３）および１２０（Ｍ）に常駐する代表的なアプリケーション１４８（１）および１４８（２）は、直接的にまたは間接的に、ネットワーク１０４上でＡＰＩレイヤ１４２への呼出しを行うことによって、ＡＰＩ関数を使用することができる。
【００２９】
このフレームワークを、クライアントで実施することもできる。クライアント１２０（３）は、フレームワーク１５０がクライアントで実施される情況を表す。このフレームワークは、サーバベースのフレームワーク１３２と同一とするか、クライアント用に修正することができる。その代わりに、クライアントが、携帯電話、携帯情報端末、ハンドヘルドコンピュータ、または他の通信／コンピューティング装置などの制限付きまたは専用機能の装置である場合に、クライアントベースフレームワークを圧縮することができる。
【００３０】
（開発者のプログラミングフレームワーク）
図２に、プログラミングフレームワーク１３２を詳細に示す。共通言語仕様（ＣＬＳ）レイヤ１４０は、さまざまな言語１３０（１）、１３０（２）、１３０（３）、１３０（４）、…、１３０（Ｋ）で記述されたアプリケーションをサポートする。そのようなアプリケーション言語に、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ＋＋、Ｃ＃、ＣＯＢＯＬ、Ｊｓｃｒｉｐｔ、Ｐｅｒｌ、Ｅｉｆｆｅｌ、Ｐｙｔｈｏｎなどが含まれる。共通言語仕様１４０は、それに従う場合にさまざまな言語が通信できるようなる特徴のまたは特徴に関するルールのサブセットを指定する。たとえば、いくつかの言語は、共通言語ランタイム１４４によってサポートされる可能性がある所与の型（たとえば、「ｉｎｔ＊」型）をサポートしない。この場合に、共通言語仕様１４０に、その型が含まれない。その一方で、すべてまたはほとんどの言語によってサポートされる型（たとえば、「ｉｎｔ［］」型）は、共通言語仕様１４０に含まれ、したがって、ライブラリ開発者は、それを使用することができ、言語がそれを処理できることが保証される。この通信の能力は、ある言語で記述されたコードモジュールと別の言語で記述されたコードモジュールの間のシームレスな統合をもたらす。異なる言語が、特定のタスクに特によく適するので、言語の間のシームレスな統合によって、開発者が、特定のコードモジュールに対し特定の言語を選択でき、そのコードモジュールを異なる言語で記述されたモジュールと共に使用する能力が与えられる。共通言語ランタイム１４４を用いると、クロス言語継承と共にシームレスなマルチ言語開発が可能になり、複数プログラミング言語の堅牢で保護された実行環境が提供される。共通言語仕様１４０および共通言語ランタイム１４４に関するさらなる情報については、特許文献１、表題「Method and System for Compiling Multiple Languages」および特許文献２、表題「Unified Data Type System and Method」を参照されたい。
【００３１】
フレームワーク１３２によって、オペレーティングシステム１４６（１）（たとえば、Ｗｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステム）およびオブジェクトモデルサービス１４６（２）（たとえば、コンポーネントオブジェクトモデル（ＣＯＭ）または分散ＣＯＭ）がカプセル化される。オペレーティングシステム１４６（１）は、ファイル管理、通知、イベント処理、ユーザインターフェース（たとえば、ウィンドウイング（windowing）、メニュー、ダイアログなど）、セキュリティ、認証、検証、プロセスおよびスレッド、メモリ管理などの従来の機能を提供する。オブジェクトモデルサービス１４６（２）は、さまざまなタスクを実行するために、他のオブジェクトとのインターフェースを提供する。ＡＰＩレイヤ１４２に対して行われる呼出しは、オペレーティングシステム１４６（１）および／またはオブジェクトモデルサービス１４６（２）によるローカル実行のために共通言語ランタイムレイヤ１４４に渡される。
【００３２】
ＡＰＩ１４２は、ＡＰＩ関数を複数の名前空間にグループ化する。名前空間によって、本質的に、セットとして「型」と呼ばれる、関連する機能性の特定のセットを提供する、クラス、インターフェース、委任（delegate）、列挙、および構造体のセットが定義される。クラスは、参照割り当てセマンティックス（semantics）を有する、管理されるヒープから割り当てられるデータを表す。委任は、オブジェクト指向関数ポインタである。列挙は、名前付き定数を表す特殊な種類の値型である。構造体は、値割り当てセマンティックスを有する、静的に割り当てられたデータを表す。インターフェースは、他の型を実施できるコントラクトを定義する。
【００３３】
名前空間を使用することによって、設計者が、型のセットを階層名前空間に編成することができる。設計者は、型のセットから複数のグループを作成することができ、各グループに、論理的に関連する機能性を公開する少なくとも１つの型が含まれる。例示的な実施形態では、ＡＰＩ１４２が、３つのルート名前空間を含むように編成される。図２には３つのルート名前空間だけが示されているが、追加のルート名前空間をＡＰＩ１４２に含めることもできることに留意されたい。ＡＰＩ１４２に示された３つのルート名前空間は、プレゼンテーションサブシステムの第１名前空間２００（ユーザインターフェースシェルの名前空間２０２を含む）、ウェブサービスの第２名前空間２０４、およびファイルシステムの第３名前空間２０６である。各グループに名前を割り当てることができる。たとえば、プレゼンテーションサブシステム名前空間２００に、名前「Ｗｉｎｄｏｗｓ」を割り当てることができ、ファイルシステム名前空間２０６の型に、名前「Ｓｔｏｒａｇｅ」を割り当てることができる。名前付きグループを、Ｓｙｓｔｅｍ名前空間全体などのシステムレベルＡＰＩの単一の「グローバルルート」名前空間の下で編成することができる。トップレベル識別子を選択し、プレフィックシングすることによって、各グループの型を、型を含むグループの名前の前に置かれた選択されたトップレベル識別子を含む階層名によって簡単に参照することができる。たとえば、ファイルシステム名前空間２０６の型を、階層名「Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ」を使用して参照することができる。このようにして、個々の名前空間２００、２０４、および２０６が、Ｓｙｓｔｅｍ名前空間からの主要な分岐になり、および個々の名前空間が「Ｓｙｓｔｅｍ．」プレフィックスなどの指示子（designator）を前に付けられる指定を伝える。
【００３４】
プレゼンテーションサブシステム名前空間２００は、プログラミングおよびコンテンツ開発に関する。この名前空間は、アプリケーション、文書、媒体プレゼンテーション、および他のコンテンツの生成を可能にする型を供給する。たとえば、プレゼンテーションサブシステム名前空間２００は、開発者がオペレーティングシステム１４６（１）および／またはオブジェクトモデルサービス１４６（２）からサービスを得られるようにするプログラミングモデルを提供する。
【００３５】
シェル名前空間２０２は、ユーザインターフェース機能性に関する。この名前空間は、開発者が自分のアプリケーションにユーザインターフェース機能性を埋め込めるようにし、さらに、開発者がユーザインターフェース機能性を拡張できるようにする型を供給する。
【００３６】
ウェブサービス名前空間２０４は、たとえば、イントラネット上の２つのピアの間で動作するチャットアプリケーションのように単純なアプリケーションおよび／または数百万のユーザに関するスケーラブルウェブサービスなどの複雑なアプリケーションなど、さまざまなウェブアプリケーションの作成を可能にするインフラストラクチャに関する。本明細書で説明するインフラストラクチャは、有利なことに、特定のソリューションの複雑さに適当なパーツだけを使用する必要があるという点で、非常に可変である。このインフラストラクチャは、さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供する。このインフラストラクチャまたはフレームワークは、基本的メッセージング、セキュアメッセージング、信頼されるメッセージング、およびトランザクション処理されるメッセージングのＡＰＩを提供する。下で説明する実施形態では、関連するＡＰＩが、有用性、使い易さ、拡張性、およびバージョナビリティ（versionability）のバランスをとるように注意深く作成された形で名前空間の階層に分解される。
【００３７】
ファイルシステム名前空間２０６は、ストレージに関する。この名前空間は、情報の保管および検索を可能にする型を供給する。
【００３８】
フレームワーク１３２のほかに、プログラミングツール２２０が、開発者がウェブサービスおよび／またはアプリケーションを構築するのを支援するために設けられている。プログラミングツール２２０の１つの例が、Ｍｉｃｒｏｓｏｆｔ社によって提供されるプログラミングツールのマルチ言語スイートであるＶｉｓｕａｌ Ｓｔｕｄｉｏ（商標）である。
【００３９】
（ルートＡＰＩ名前空間）
図３に、プレゼンテーションサブシステム名前空間２００を詳細に示す。一実施形態において、名前空間が、名前のストリングがピリオドによって連結される階層命名規約に従って識別される。たとえば、プレゼンテーションサブシステム名前空間２００は、ルート名「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ」によって識別される。「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ」名前空間内に、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ」として識別されるもう１つの名前空間があり、さらに、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ」と称する、コントロールに関するもう１つの名前空間が識別される。この命名規約を念頭において、以下では、プレゼンテーションサブシステム名前空間２００の全般的な概要を提供するが、他の命名規約を使用して同等の効果を得ることができる。
【００４０】
Ｓｈｅｌｌ名前空間２０２（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ」）に、ストレージシステム内のアイテム、ＦＴＰロケーションまたはＤＡＶ（Distributed authoring and Versioning）ロケーションのファイル、コントロールパネル内のコントロールパネルアプレット、アプリケーションなど、エンドポイントのセットをエンドユーザが調査でき、ナビゲートできるようにするユーザインターフェース機能性をサポートするクラスおよびＡＰＩが含まれる。このナビゲーションに、１つまたは複数のフォルダを開くこと、ならびにフォルダ内のフォルダを開くことを含めることができる。Ｓｈｅｌｌ名前空間２０２を用いると、開発者が、そのような機能性を自分のアプリケーションに組み込めるようになり、さらに、開発者が、この調査およびナビゲーションの機能性を拡張できるようになる。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの諸バージョンで、このユーザインターフェースを、通常は「エクスプローラ」と称する。
【００４１】
ある実施形態で、Ｓｈｅｌｌ名前空間２０２のユーザインターフェース機能性を用いてユーザがそれを調査でき、ナビゲートできるようになるストレージシステムは、すべての種類の情報の編成、検索、および共有のためのアクティブストレージプラットフォームである。このプラットフォームは、リッチデータモデルを定義し、リレーショナルストレージエンジンに基づき、柔軟なプログラミングモデルをサポートし、データの監視、管理、および操作のためのデータサービスのセットを提供する。データは、ファイルベースデータまたは非ファイルベースデータとすることができ、データを、通常は「アイテム」と称する。このファイルシステムでは、通常、ファイルシステムによって提供される機能性が拡張される。というのは、このファイルシステムが、個人連絡先、イベントカレンダ、電子メールメッセージなどの非ファイルデータであるアイテムも扱うからである。そのようなファイルシステムの一例が、「ＷｉｎＦＳ」ファイルシステムである。
【００４２】
Ｓｈｅｌｌ名前空間２０２のユーザインターフェース機能性を用いてユーザがそれを調査でき、ナビゲートできるようになるストレージシステムのユニバーサルデータストアは、そのストアに常駐するデータの編成、検索、共有、同期化、およびセキュリティをサポートするデータモデルを実施する。このデータストアのストレージ情報の基礎的な単位を、アイテムと称する。データモデルは、アイテムおよびアイテム拡張を宣言し、アイテムの間の関係を確立し、アイテムをフォルダおよびカテゴリに編成する機構を提供する。
【００４３】
アイテムは、単純なファイルと異なって、ストレージシステムによってユーザまたはアプリケーションプログラムに公開されるすべてのオブジェクトにまたがって一般的にサポートされるプロパティの基本セットを有するオブジェクトである、保管可能な情報の単位である。アイテムは、新しいプロパティおよび関係を導入できるようにする特徴を含む、すべてのアイテムタイプにまたがって一般的にサポートされるプロパティおよび関係も有する。このプロパティおよび関係のデータを、アイテムに関連するメタデータとも称する。下で詳細に述べるように、メタデータは、アイテム装飾スキーマに従って保管することができる。このアイテム装飾スキーマによって、アイテムをユーザに提示するのに適当な形を示すことができる。
【００４４】
アイテムは、コピー、削除、移動、開く、印刷、バックアップ、レストア、複製などの共通の動作の対象である。アイテムは、保管でき検索できる単位であり、ストレージプラットフォームによって操作される保管可能な情報のすべての形が、アイテム、アイテムのプロパティ、またはアイテムの間の関係として存在し、これらのそれぞれを、下で詳細に説明する。アイテムは、（すべてのさまざまな種類の）Ｃｏｎｔａｃｔｓ（連絡先）、Ｐｅｏｐｌｅ（人）、Ｓｅｒｖｉｃｅｓ（サービス）、Ｌｏｃａｔｉｏｎｓ（ロケーション）、Ｄｏｃｕｍｅｎｔｓ（文書）などのデータの、実世界の簡単に理解できる単位である。
【００４５】
アイテムは、独立のオブジェクトである。したがって、アイテムを削除する場合に、アイテムのプロパティのすべても削除される。同様に、アイテムを検索するときに、受け取られるものは、アイテムと、そのアイテムのメタデータに含まれるそのプロパティのすべてである。ある実施形態では、特定のアイテムを検索するときに、プロパティのサブセットを要求できるようにすることができるが、そのような実施形態の多くに関するデフォルトは、検索されるときに、アイテムを、直接のおよび継承されたプロパティのすべてと共に提供することである。さらに、アイテムの型の既存のプロパティに新しいプロパティを追加することによって、アイテムのプロパティを拡張することもできる。これらの「拡張」は、その後、そのアイテムの真正のプロパティになり、そのアイテム型のサブタイプに、自動的に拡張プロパティを含めることができる。拡張を、ファイルに関連するメタデータとも称する場合がある。
【００４６】
アイテムのグループを、アイテムフォルダ（ｉｔｅｍ Ｆｏｌｄｅｒ）と称する特殊なアイテム（ファイルフォルダと混同してはならない）に編成することができる。しかし、ほとんどのファイルシステムと異なって、アイテムは、複数のアイテムフォルダに属することができ、アイテムが、あるアイテムフォルダでアクセスされ、改訂されるときに、この改訂されたアイテムに、別のアイテムフォルダから直接にアクセスすることができる。要するに、アイテムへのアクセスを、異なるアイテムフォルダから行うことができるが、実際にアクセスされるものは、実際にはまったく同一のアイテムである。しかし、アイテムフォルダは、必ずしもそのメンバアイテムのすべてを所有せず、あるいは他のアイテムフォルダと共にアイテムを単純に協同所有することができ、アイテムフォルダの削除が、必ずしもアイテムの削除をもたらさない。
【００４７】
アイテムのグループを、カテゴリ（Ｃａｔｅｇｏｒｙ）に編成することもできる。アイテムフォルダが、相互関係（すなわち、共通の記述された特性）を有しないアイテムを含むことができるが、カテゴリの各アイテムは、そのカテゴリについて記述された共通の型、プロパティ、または値（「共通性」）を有し、カテゴリへの関係およびカテゴリ内の他のアイテムとの間の関係の基礎を形成するのがこの共通性であるという点で、カテゴリは、概念的にアイテムフォルダと異なる。さらに、特定のフォルダへのアイテムのメンバシップは、そのアイテムの特定の態様に基づく必須のものではないが、ある実施形態について、あるカテゴリに断定的に関連する共通性を有するすべてのアイテムを、ハードウェア／ソフトウェアインターフェースシステムレベルで、自動的にそのカテゴリのメンバにすることができる。概念的に、カテゴリは、メンバシップが特定の照会の結果に基づく（データベースのコンテキストで、など）仮想アイテムフォルダと考えることもでき、この照会の条件（カテゴリの共通性によって定義される）を満たすアイテムは、したがって、カテゴリのメンバシップを備える。
【００４８】
ファイル、フォルダ、およびディレクトリと異なって、本発明のアイテム、アイテムフォルダ、およびカテゴリは、特徴として性質において「物理的」ではない。というのは、これらが、概念的に物理コンテナの同等物を有しておらず、したがって、アイテムが、複数のそのようなロケーションに存在することができるからである。アイテムが、複数のアイテムフォルダロケーションに存在し、カテゴリに編成される能力によって、当技術分野で現在使用可能なものを超える、ハードウェア／ソフトウェアインターフェースレベルでのデータ操作およびストレージ構造能力の機能強化および質の高さがもたらされる。
【００４９】
アイテムに、複数のアイテムの間の関係を判定できるようにする関係情報も含めることができる。関係は、バイナリ関係であり、一方のアイテムがソースとして指定され、他方のアイテムがターゲットとして指定される。ソースアイテムおよびターゲットアイテムは、関係によって関連する。
【００５０】
ユニバーサルデータストア内のアイテムは、シェルブラウザによってユーザに提示され、このシェルブラウザは、ユーザがハードウェア／ソフトウェアインターフェースを用いて見ることができる、および対話することができるようにする（Ｓｈｅｌｌ名前空間２０２のクラスおよびＡＰＩを使用して）ユーザインターフェースを提供する。ユニバーサルデータストア内の各アイテムは、ユニバーサルデータスキーマに従って保管される。このスキーマには、型関連付け（type association）と称する、アイテムを記述する機構が含まれる。各型関連付けは、シェル内の基本的表現を有し、型関連付けに従ってアイテムを保管することによって、シェルは、少なくとも基本表示ビューまたはデフォルト表示ビューに従ってアイテムを表示することができる。
【００５１】
型関連付けは、アイテムに関連するプロパティであり、データをユニバーサルデータストアに置くときに、そのデータに関連する１つまたは複数のプロパティを宣言して、そのアイテムの型を決定しなければならない。このプロパティは、データに関連するメタデータとして含めることができる。シェルは、デフォルト型関連付けのセットを有し、これによって、アイテムについて宣言しなければならない最も基本的な最小限のプロパティが表される。
【００５２】
プロパティ宣言を越えて、アイテムに関連するメタデータに、シェルがアイテムのプレゼンテーションをどのように装飾するかを示すデータを含めることができる。装飾は、この場合に、アイテムをどのようにユーザに提示するかに関する「ヒント」と考えることができる。このメタデータは、アイテム装飾スキーマに従って保管することができる。アイテム装飾スキーマでは、シェルがアイテムを提示するのに使用できるアイテム装飾ビューが定義される。たとえば、アイテム装飾データによって、アイテムの最も重要な宣言されたプロパティを記述することができる。これらの「高価値」プロパティは、シェルでの提示に関して最も望ましいものとすることができる。
【００５３】
アイテムを提示するために、アイテム装飾データによって、アイテムのプレゼンテーションに適当なビューフィールドのセットを示すことができる。ビューフィールドは、宣言されたプロパティの射影であり、共通のビューフィールドに、「タイトル」、「作成者」、「作成日」、または「最終編集日」を含めることができる。シェルには、標準的なビューフィールドのセットが含まれ、独立ソフトウェアベンダ（ＩＳＶ）は、自分のデータのプレゼンテーションに適当なビューフィールドを定義することができる。新しいアイテム型を開発するときに、ＩＳＶは、ＩＳＶが定義するアイテムプロパティをシェルのビューフィールドにマッピングするか、ＩＳＶ自身のビューフィールドを提供することができる。
【００５４】
たとえば、特定のアイテムデータに、ソングデータを含めることができる。宣言されるプロパティのセットに、歌の題名、アーティスト、レコーディング日付、アルバム、曲の長さ、およびそのようなソングアイテムに適当な他の宣言を含めることができる。アイテム装飾データによって、シェルでアイテムを提示するときに、ビューフィールド「Ｔｉｔｌｅ」、「Ａｒｔｉｓｔ」、および「Ａｌｂｕｍ」をユーザに表示しなければならないことを指示することができる。
【００５５】
アイテム装飾は、シェルによってサポートされる表示の任意の態様にすることができる。ある共通の他のアイテム装飾は、たとえば、データフォーマッティング、デフォルトソート順序、およびデフォルトアイコンサイズである。さらに、アイテム装飾データによって、所与のアイテムを表示する際に使用されるコモンコントロールを記述することができる。たとえば、Ｒａｔｉｎｇｓフィールドで、一連の星印としてレーティングを表示するレーティングコントロールを使用することができる。アイテム装飾データによって、アイテムと共に使用するのに適するタスクまたはバーブ（ｖｅｒｂ）を記述することができる。「タスク」および「バーブ」という用語は、アイテムに関して行われるあるアクションを記述するものであり、この用語は、交換可能に使用することができる。たとえば、「編集」または「プレビュー」を、アイテムに関連する適当なタスク／バーブとすることができる。シェルをさらに構成して、アイテムに関するアクションを実行するために、ユーザ選択時にこれらのタスクをサポートするアプリケーションを起動することができる。
【００５６】
アイテム装飾ビューは、所与のアイテムまたはアイテムの同種のセット（類似するアイテム装飾ビューを有するアイテムからなる）を完全に提示するのに十分である。異なるアイテム装飾スキーマを有するアイテムを表示するために、シェルは、シェル装飾ビューに従ってアイテムを提示するシェルビュースキーマを備える。シェルビュースキーマによって、シェルまたはＩＳＶが、異種データの所与のセットに適当なビューを宣言できるようになる。
【００５７】
シェル装飾ビュー内での表現について選択されるアイテムに、共通の特性を含めることができる。さまざまな共通の特性を、シェル装飾ビューについて受入可能とすることができる。たとえば、シェルビュースキーマで、すべての既知のピクチャ型（たとえば、．ＧＩＦ、．ＪＰＥＧ、．ＢＭＰ、．ＴＩＦＦなど）に対する共通のおよび適当な、フィールドおよびメタデータを表示するのに使用される「Ｐｉｃｔｕｒｅ」ビューを定義することができる。シェルビュースキーマは、所与のアイテム装飾ビューの衝突するディスプレイ属性をオーバーライドし、シェルビュースキーマに従って各ピクチャアイテムを提示する。もう１つの例として、シェルは、ワードプロセッシング文書、スプレッドシート、またはデータベースなどの通常のプロダクティビティアプリケーションによって作られるアイテムの適当なカラムおよびメタデータに関して最適化された「Ｄｏｃｕｍｅｎｔ」シェルビューを提供することができるが、これらのアイテムのそれぞれのアイテム装飾は互いに大きく異なる可能性がある。そのようなビューは、これらの文書のそれぞれの間で共通のプロパティを提供することによって価値を有する。後者の文書型がインストールされるときに、シェルビューは、ビューが最初に作成されたときに新しい型が考慮されていない可能性がある場合でも、一貫性のあるシェルビューに従って新しいアイテムを提示することができる。
【００５８】
シェルビュースキーマは、多岐にわたるディスプレイ属性を提供することができ、ＩＳＶは、そのようなシェルビューを提供することを望む場合がある。ディスプレイ属性に、制限なしに、プレビューペインのサイズ、プレビューペイン内に表示されるメタデータ、使用されるカスタムコントロール、ならびに提示されるアイテムに適当なタスクおよびバーブを含めることができる。
【００５９】
シェルは、エクスプローラディスプレイビューに従ってアイテムを提示することができる。「エクスプローラ」を、ストレージアプリケーションと呼ぶことができ、シェルまたはＩＳＶによって提供されることができる。エクスプローラは、たとえば、ユーザが、データストア内の選択されたアイテムの表示、照会、ナビゲーション、タスクへの起動、または編成を行えるようにすることができる。「エクスプローラ」という用語は、表示されるアイテムが存在するロケーションを暗示するのではなく、「アクティビティセンタ」、「ビューワ」、および「ライブラリ」などの用語を、ストレージアプリケーションを表現するために「エクスプローラ」と交換可能に使用することができる。
【００６０】
例のエクスプローラスキーマ階層に、アイテムビュースキーマであるボトムレイヤが含まれる。アイテムビュースキーマは、アイテムを表すのに必要な基本ディスプレイを提供し、エクスプローラビュースキーマは、そのディスプレイ要素を据え置くか、必要なときにそれに頼ることができる。
【００６１】
エクスプローラビュースキーマには、シェルビュースキーマおよびエクスプローラ装飾も含まれる。エクスプローラ装飾は、エクスプローラ全体を装飾し、特有の色およびブランド設定（branding）要素などのディスプレイ要素を提供する。これらのエクスプローラ装飾は、エクスプローラが提供するさまざまなビューの間で存続する。多岐にわたるさまざまなディスプレイ属性を、エクスプローラ装飾に適用できる。たとえば、エクスプローラに関連するデータ照会またはタスク／バーブを、エクスプローラを用いる表示に適用できる。表示されるタスクは、多くの場合、そのタスクを実行できるアプリケーションと結合される。
【００６２】
エクスプローラビュースキーマに、任意選択として、１つのシェルビュースキーマまたは複数のシェルビュースキーマを含めることができる。シェルビュースキーマは、エクスプローラアイテムのサブセットに対するシェルビューを提供するように構成することができる。たとえば、エクスプローラを、ユーザにソングアイテムを表示するように構成することができる。第１のシェルビュースキーマを含めて、アルバムの表示を提供することができ、第２のシェルビュースキーマを含めて、ソングトラックの表示を提供することができる。この方法で、両方のタイプのアイテムは、エクスプローラ内の適当なビューを有する。上述のように、シェルビューの利用は、任意選択として共通の特性を共有することができるアイテムのセットの提示に関連する。
【００６３】
エクスプローラは、シェルに含まれるシェルビューにも頼ることができる。エクスプローラ内での提示のために選択されたアイテムが、エクスプローラに含まれるシェルビューのどれによってもサポートされない場合に、シェルが、エクスプローラ内での使用のために適当なシェルビューを提供することができる。同様に、上述のように、エクスプローラは、シェルによって提供されるアイテムディスプレイビューまたはデフォルトディスプレイビューに頼ることもできる。この機能性によって、シェルによって表示できる任意のアイテムを、エクスプローラ内でも表示できることが保証される。エクスプローラは、これらのシェルが提供するディスプレイスキーマを据え置くように構成することができ、あるいは、たとえば予期せぬデータの表示を提供するために、それに頼ることができる。
【００６４】
Ｓｈｅｌｌ名前空間２０２は、アイテムのための基礎になるデータ（たとえば、ファイル内容、画像データ、連絡先情報データなど）が保管されるロケーションにかかわりなく、一貫性のある方法でアイテムを操作でき、対話できるようにするユーザインターフェース機能性をサポートする。アプリケーション設計者の観点から、Ｓｈｅｌｌ名前空間２０２によってサポートされる機能性は、よりよい開発体験をもたらすが、これは、少なくとも部分的に、異なるロケーションに保管される基礎になるデータにかかわらず、そのようなアイテムを一貫性のある方法で扱うことができるからである。Ｓｈｅｌｌ名前空間２０２を使用するときに、そのような異なるデータストレージロケーションの潜在的な存在にかかわらず、コヒーレントな経験を設計者に提供する。
【００６５】
Ｓｈｅｌｌ名前空間２０２では、Ｃｏｎｔｒｏｌｓ名前空間３０２、Ｄｉａｌｏｇｓ名前空間３０４、Ａｄｄｉｎ名前空間３０６、およびＤｅｓｋｔｏｐ名前空間３０８を含む追加の名前空間が定義される。Ｓｈｅｌｌ名前空間内のこれらの追加名前空間３０２、３０４、３０６、および３０８のそれぞれは、コントロール、ダイアログ、および／またはハンドラなど、以下で詳細に述べるさまざまな機能性を提供する１つまたは複数のサービスまたはコンポーネントが含まれる。
【００６６】
Ｓｈｅｌｌ名前空間２０２は、追加名前空間３０２、３０４、３０６、および３０８のそれぞれによって使用できるオブジェクトモデルを定義する。このオブジェクトモデルには、下記のオブジェクトが含まれる。
・ファイルフォルダ、スタック、個々のファイル、個々のＷｉｎＦＳアイテム（たとえば、アルバム、歌、写真など）など、Ｓｈｅｌｌを介してユーザに提示できるアイテムを記述するのに使用されるＥｘｐｌｏｒｅｒＩｔｅｍオブジェクト（Ｉｔｅｍオブジェクトとも称する）。
・ＥｘｐｌｏｒｅｒＩｔｅｍｓに対する照会を記述するのに使用されるＬｉｂｒａｒｉｅｓオブジェクト。
・ユーザへの表示のためにアイテム（たとえばＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトによって表される）からデータを射影するのに使用されるＶｉｅｗＦｉｅｌｄｓオブジェクト（Ｐｒｏｐｅｒｔｉｅｓオブジェクトとも称する）。ストレージシステムのプロパティとＶｉｅｗＦｉｅｌｄｓオブジェクトの間で定義される射影は、ＥｘｐｌｏｒｅｒＩｔｅｍｓに基づく追加計算または処理を実行することができる。たとえば、記憶装置を表すフォルダが表示されており、設計者がそのフォルダにその記憶装置の空き容量を含めることを望む場合に、射影によって記憶装置の総容量とその記憶装置に保管されたファイルのサイズ（ＥｘｐｌｏｒｅｒＩｔｅｍｓによって表される）に基づいて、空き容量が計算される。
・Ｌｉｂｒａｒｙオブジェクトの永続的な形である、ダイナミックリストへのリンクを記述するのに使用されるＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクト。ＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクトは、照会と、照会の結果をユーザに提示するビューの組合せである。
【００６７】
このオブジェクトモデルは、２００３年１０月２３日出願の米国特許出願第＿＿＿号、弁理士整理番号ＭＦＣＰ．１０９８３４（ＭＳ＃３０６９２３．０１）、表題「System and method for presenting items to a user with a contextual presentation」に詳細に記載されている。
【００６８】
Ｃｏｎｔｒｏｌｓ名前空間３０２（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ」）では、アプリケーションによって使用できる、再利用可能なユーザインターフェースコントロールのコレクションが定義される。複数の異なるアプリケーションが、これらのコントロールを利用することができるので、これらのコントロールは、再利用可能とみなすことができる。この再利用可能なコントロールのコレクションによって、アプリケーションの設計を単純化することができる。というのは、アプリケーション設計者が、コントロールの彼ら自身のバージョンを設計することを要求されるのではなく、これらのコントロールに頼ることができるからである。さらに、この再利用可能なコントロールのコレクションを使用することによって、複数のアプリケーションにまたがる一貫性のあるルックアンドフィールを達成することができる。
【００６９】
Ｃｏｎｔｒｏｌｓ名前空間３０２によって定義されるコントロールは、ユーザインターフェース内のアイテムの操作および／または表示を含む、ユーザインターフェースのシェルの操作および／または表示を可能にする。上で述べたように、ユーザインターフェースのシェル内で表示できるこれらのアイテムは、多岐にわたる種類のデータのいずれをも表し、ファイルシステムに保管される単に伝統的な「ファイル」ではない。さらに、Ｃｏｎｔｒｏｌｓ名前空間３０２によって定義されるコントロールを用いると、アプリケーション設計者が、多岐にわたるロケーションからのデータを扱うときに同一のコントロールを使用できるようになり、一貫性がありコヒーレントな設計経験がもたらされる。
【００７０】
Ｃｏｎｔｒｏｌｓ名前空間３０２では、下記の再利用可能なコントロールが定義される。
・ＥｘｐｌｏｒｅｒＶｉｅｗコントロールは、ストレージユーザ経験をカプセル化するのに使用される。ストレージユーザ経験は、関係、照会などを用いてアイテムにまたがって作業するために定義される。このストレージユーザ経験を用いると、エンドユーザが、たとえば、プロパティ値に基づく照会を発行し、共通プロパティ値を用いてＷｉｎＦＳアイテムをスタックし、スタックされていないアイテムからスタックへのドラッグアンドドロップを可能にする（たとえば、プロパティ述部のプロパティの値に、スタックに存在するものをセットすることによって）などが可能になる。ＥｘｐｌｏｒｅｒＶｉｅｗコントロールを使用して、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの以前のバージョン（たとえば、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのＷｉｎｄｏｗｓ（登録商標）ＸＰバージョンまたはＷｉｎｄｏｗｓ（登録商標）９８バージョン）など、以前のオペレーティングシステム（レガシシステムとも称する）で見られるものと同一の外見を有するディスプレイ用のフォルダを記述することができる。
・ＥｘｐｌｏｒｅｒＩｔｅｍｓの表示に使用されるＥｘｐｌｏｒｅｒＩｔｅｍＶｉｅｗ。ＥｘｐｌｏｒｅｒＩｔｅｍｓのレイアウトおよび設計は、アプリケーション設計者が定義することができる。オペレーティングシステムは、アプリケーション設計者が定義できるレイアウトおよび設計にある制約を課すユーザ経験を定義することもでき、したがって、アプリケーション設計者によって定義されるレイアウトおよび設計が、オペレーティングシステムによって定義されるユーザ経験と一貫性を持つようになる。したがって、ＥｘｐｌｏｒｅｒＩｔｅｍＶｉｅｗコントロールを用いると、設計者が、ＥｘｐｌｏｒｅｒＩｔｅｍｓからのデータをユーザに表示する方法（たとえば、列で、行で、または他の構成で）ならびにどのデータをユーザに表示するかを決定できるようになる。
・アイテムをサイドバーに追加できるようにするのに使用されるＢａｓｋｅｔＣｏｎｔｒｏｌコントロール（サイドバーは、以下で詳細に説明する）。カーソル制御装置を使用してアイテムを選択し、それをサイドバーにドラッグし、そこでドロップ（たとえば、カーソル制御ボタンを離すことによって）することによって、「ドラッグアンドドロップ」でサイドバーにアイテムを追加することができる。ＢａｓｋｅｔＣｏｎｔｒｏｌコントロールは、２００３年１０月１３日出願の米国特許出願第＿＿＿号、弁理士整理番号００３７９７．００６９５（ＭＳ＃３０４６３１．１）、表題「Extensible Creation And Editing Of Integrated Collections」に詳細に記載されている。
・アイテムをリストまたはグループに追加できるようにするのに使用されるＬｉｓｔＭａｋｅｒコントロール。カーソル制御装置を使用してアイテムを選択し、適当なリストまたはグループの上にドラッグし、そこでドロップ（たとえば、カーソル制御ボタンを離すことによって）することによって、「ドラッグアンドドロップ」の形でアイテムのリストまたはグループを作成することができる。たとえば、アイテムを歌とし、リストをプレイリストとすることができ、アイテムを画像とし、リストを写真アルバムとすることができる。
・アイテムのプレビューイメージをユーザに提示できるようにするのに使用されるＰｒｅｖｉｅｗＩｍａｇｅＣｏｎｔｒｏｌコンポーネント。アイテムが選択されるときに、プレビューイメージをユーザに提示することができ、このプレビューイメージは、通常、イメージのサムネイルより大きいが、ユーザインターフェースのディスプレイ領域全体より小さい。
【００７１】
Ｄｉａｌｏｇｓ名前空間３０４（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓ」）では、アプリケーションによって使用できるユーザインターフェースダイアログおよびウィザードのコレクションが定義される。Ｃｏｎｔｒｏｌｓ名前空間３０２のコントロールに似て、Ｄｉａｌｏｇｓ名前空間３０４のダイアログおよびウィザードは、再利用することができ、その結果、複数の異なるアプリケーションが、これらのダイアログおよびウィザードを利用することができる。この再利用可能なダイアログおよびウィザードのコレクションは、複数のアプリケーションにまたがる一貫性のあるルックアンドフィールを維持するのを助ける。
【００７２】
Ｄｉａｌｏｇｓ名前空間３０４によって定義されるダイアログおよびウィザードは、ユーザインターフェースのシェル内でアクションを実行できるようにする。上述のように、これらのシェルは、多岐にわたるさまざまな種類のデータのいずれをも表すことができるアイテムに基づき、ファイルシステムに保管される単に伝統的な「ファイル」ではない。さらに、Ｄｉａｌｏｇｓ名前空間３０４によって定義されるダイアログおよびウィザードを用いると、アプリケーション設計者が、さまざまなロケーションからのデータを扱うときに同一のダイアログおよびウィザードを使用できるようになり、一貫性のあるコヒーレントな設計経験がもたらされる。
【００７３】
Ｄｉａｌｏｇｓ名前空間３０４では、下記のダイアログおよびウィザードが定義される。
・ファイルおよびフォルダを開き、保存できるようにするのに使用されるＯｐｅｎ／Ｓａｖｅダイアログ。これらのダイアログは、拡張可能でもあり、アプリケーション設計者が、ダイアログの機能性を拡張することができる。たとえば、これらのダイアログを拡張して、アプリケーション設計者が使用を望むファイルおよび／またはフォルダに関するさまざまな追加のメタデータを利用することができる。
・ＣＤおよび／またはＤＶＤなどの光ディスクに書き込めるようにするために使用されるＣＤ／ＤＶＤ Ｂｕｒｎウィザード。ハードウェア設計者は、ＣＤおよび／またはＤＶＤに書き込めるようにする彼ら自身のハードウェア固有のステップを含む彼ら自身のウィザードを提供することができる。
・電子メールによってイメージを送信する際にユーザを支援するのに使用されるＳｅｎｄ Ｐｈｏｔｏｓウィザード。このウィザードを用いると、ユーザが、イメージを特定のサイズに変更できるようになる。このウィザードは、電子メール送信に適すると思われる特定のサイズにイメージのサイズを変更することができ、あるいは、その代わりに、ユーザが複数の異なるサイズから選択できるようにすることができる。
【００７４】
Ａｄｄｉｎ名前空間３０６（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ａｄｄｉｎ」）では、ユーザインターフェース機能性を拡張する基本クラスおよびインターフェースのコレクションが定義される。Ａｄｄｉｎ名前空間３０６を用いると、アプリケーション設計者が、ユーザインターフェースの機能性を拡張する管理されたコードを追加できるようになる。この拡張を用いると、たとえば、アプリケーション設計者が、適当と思われるようにユーザインターフェースの諸部分をカスタマイズできるようになる。
【００７５】
Ａｄｄｉｎ名前空間３０６を用いると、多岐にわたるさまざまな種類のデータのいずれをも表し、ファイルシステムに保管される単に伝統的な「ファイル」ではないアイテムを表示するのに使用されるユーザインターフェースのシェルの拡張が可能になる。さらに、Ａｄｄｉｎ名前空間３０６を用いると、アプリケーション設計者が、コヒーレントな形でユーザインターフェースのシェルを拡張できるようになり、より管理され改善された設計経験がもたらされる。
【００７６】
下記などのさまざまな機能性に関する管理されたコードが、Ａｄｄｉｎ名前空間３０６によってサポートされる。
・コンテキストメニューハンドラ。コンテキストメニューには、たとえば表示されているアイテムを右クリックすることによって、アクセスすることができる。コンテキストメニューハンドラは、アプリケーション設計者が、コンテキストメニューに追加される彼ら自身のエントリを定義できるようにする。
・サムネイルエクストラクタ（extractor）。サムネイルエクストラクタを用いると、アプリケーション設計者が、彼ら自身のサムネイル（たとえば、ファイル、フォルダ、および／または表示される他のアイテムに関する）を開発でき、ユーザへの表示のためにオペレーティングシステムに対してこれらのサムネイルを識別できるようになる。
・ＷｉｎＦＳからエクスプローラへの射影の合成／分解するためのハンドラ。これらのハンドラは、アプリケーション設計者が、ファイルおよび／またはフォルダに関する情報をユーザに表示するときにさまざまな計算を実行できるようにする（たとえば、記憶装置の空き容量を計算できるようにする）。
【００７７】
Ｄｅｓｋｔｏｐ名前空間３０８（「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｅｓｋｔｏｐ」）は、アプリケーション設計者がユーザに表示されるデスクトップの機能性を拡張できるようにする機能性のコレクションを定義する。Ｄｅｓｋｔｏｐ名前空間は、Ｓｈｅｌｌ名前空間２０２の一部とすることができ（たとえば、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｅｓｋｔｏｐ」）、その代わりに、プレゼンテーションサブシステム名前空間２００の一部であるがＳｈｅｌｌ名前空間２０２の一部でないものとすることができる（たとえば、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｄｅｓｋｔｏｐ」）。Ｄｅｓｋｔｏｐ名前空間には、サイドバーおよび通知にかかわる要素が含まれる。サイドバー要素および通知要素をＤｅｓｋｔｏｐ名前空間に含めることによって、ユーザに、サイドバーおよび通知の集中化されたコントロールが与えられる。たとえば、すべてのアプリケーションからの通知に関するルールを、通知を使用するアプリケーションごとのルール定義にアクセスすることを介するユーザによるナビゲーションを必要とせずに、ユーザが１回でセットすることができる。
【００７８】
一般に、サイドバーは、統合された対話型周辺認識ディスプレイ内のダイナミック通信アクセスおよび情報認識を提供し、この対話型周辺認識ディスプレイ内では、指定された通信連絡先および情報要素が、ダイナミックに追跡または受信され、進行中の基礎でユーザに提供される。ある実施形態で、この機能が、従来のディスプレイ装置の１つの辺に沿った継続ディスプレイストリップ内の１つまたは複数の列に表示される少なくとも１つのカスタマイズ可能なダイナミックサムネイルを介して提供される。さらに、追加の実施形態で、サムネイルが、ディスプレイ全体を含むディスプレイの１つまたは複数の部分のいずれにも表示される。ディスプレイ全体がカバーされる実施形態は、たとえばハンドヘルドまたはパームトップコンピューティング装置、携帯電話、または他の限られたディスプレイ領域を有する電子装置など、比較的小さいディスプレイ領域を有する装置でサイドバーが使用される場合に特に有用である。
【００７９】
カスタマイズ可能なダイナミックサムネイル各々は、たとえば、特定の通信連絡先（特定の個人、会社、組織、または他のエンティティなど）またはユーザが興味を持つ可能性がある情報の特定の要素を表す。そのような情報要素に、たとえば、共有ファイルまたは共有フォルダが修正されるとき、共有データベースまたは共有ワークスペースの情報が変更されるとき、電子メール状況、カレンダ、インターネットウェブページ、気象条件、面会予約、スケジュール、統計的情報、株式市況、交通情報、またはユーザが興味を持つ可能性がある他のインターネットアクセス可能情報またはネットワークアクセス可能情報が含まれる。
【００８０】
前述のダイナミックサムネイルに、一般に、興味のある連絡先または情報を記述する「タイル」（「チケット」とも称する）と、どの通信連絡先または情報がタイルによって表されるかを表示するのに特化した「ビューワ」の組合せが含まれる。各タイルおよびビューワは、たとえば、Ｓｈｅｌｌ名前空間２０２によって提供されるユーザインターフェース機能性によってアクセスできるストレージシステム内のアイテムとすることができる。１つまたは複数の「サービス」を使用して、各タイルによって記述される情報の現況および／または通信連絡先の状況と自動的に相互作用をし、これを追跡し、または受け取る。情報の現況および通信連絡先の状況が、アイテムをグラフィカルにかつ／またはテキストによって表示するために、対話型周辺認識インターフェース内に常駐する「コンテナ」内で各タイルをホスティングすることによって、動的に提供される。周辺認識インターフェースは、潜在的な注意散漫またはユーザへの妨害を減らす方法で情報および／または通信連絡先を表示する。
【００８１】
一般に、タイルは、ＸＭＬデータファイルなどのデータ構造によって表される。各タイルに、どの情報または通信連絡先がそのタイルによって表されるかに関する命令、ならびにその情報または通信連絡先にアクセスし、かつ／またはこれと対話する複数の従来の手段のいずれかを表す特定のサービスへのポインタが含まれる。これらのサービスは、自動的にまたは手動で、事前に定義された、またはユーザ定義可能なサービスのライブラリから選択される。具体的に言うと、異なるサービスは、アクセス、受取、検索、および／または別に、従来の情報、情報のソース、もしくは通信連絡先との相互作用の機能を提供する共有コードまたは共有機能を表す。これらのサービスは、これらが単独でまたは組み合わされてのいずれかで使用され、１つまたは複数のタイルによって並列に使用することができるという意味で、共有される。その結果、ある実施形態で、複数のサービスが、従来の情報、情報のソース、または通信連絡先との複雑な相互作用を提供するために組み合わせて使用されることに留意されたい。
【００８２】
サービスの一例は、従来のＭＡＰＩサーバに接続することによって電子メールフォルダを監視するのに必要な機能性である。サービスのもう１つの例は、電子メールメッセージを送信または受信する機能性である。関連するサービスが、たとえばインスタントメッセージングまたはピアツーピア通信方式など、複数の従来の方法を介する連絡先との通信または情報転送の機能性を提供する。サービスのもう１つの例が、テキストファイルをある言語から別の言語に変換する機能性である。サービスのもう１つの例が、データベースを監視するのに必要な機能性である。サービスのもう１つの例に、ウェブサイトまたはリモートサーバからデータを受信するか検索する機能性が含まれる。明らかに、情報、情報のソース、または通信連絡先と相互作用する方法のどれをも、１つまたは複数のタイルにより使用される共有サービスとして実施することができる。
【００８３】
さらに、上記のように、各タイルの命令に、どのタイプの情報または通信連絡先がタイルによって表されていても、それを表示する能力を有する複数の専用ビューワの１つへのポインタが含まれる。言い換えると、各タイルは、ユーザが特定の情報または連絡先をどのように表示することを望むかの定義と共に、ユーザが経過を追うことを望む情報または連絡先、ならびに情報または連絡先へのアクセスおよび相互作用に関する複数のサービスのいずれをも使用する能力の組合せを表す。そのようなアクセスまたは相互作用は、ローカルに、またはローカルイントラネット、エクストラネット、有線または無線ネットワーク、インターネットなどにわたって従来の通信プロトコルを介して達成することができる。
【００８４】
ビューワは、１つまたは複数のサービスを介して検索された情報または連絡先データを有するサイズ変更可能なサムネイルまたはアイコンサイズのウィンドウとしてタイルをグラフィカルに表示する。具体的に言うと、ビューワは、テキスト情報、可聴情報、あるいは静止画像または生画像を含むグラフィカル情報、あるいはテキスト情報、可聴情報、またはグラフィカル情報の組合せを有するタイルをダイナミックに表示することができる。たとえば、あるビューワタイプは、連絡先情報を表示できるすなわち「パーソンタイル」であり、別のタイプは、たとえば受信したメッセージの数または特定のソースからのメッセージの数などの特定の電子メール情報を表示することができ、もう１つのビューワは、データベースからの特定の情報のサマリをサムネイル内で提供するためにデータベースと対話するように設計される。ビューワタイプのさらなる例に、静止画像、ビデオ画像、通信状況のサマリ、データベース照会の結果などを表示できるビューワが含まれる。明らかに、任意のタイプのビューワを任意の対応するタイプの情報に関連付け、任意の可能な情報を表示できることを保証するように設計することができる。
【００８５】
サイドバーは、特許文献３、表題「A system and process for providing dynamic communication access and information awareness」に詳細に記載されている。
【００８６】
名前空間３０８のサイドバー機能性は、アプリケーション設計者が、サイドバーにタイルを追加できるようにする。
【００８７】
通知（たとえば、可聴通知または視覚的通知）は、ユーザコンテキストシステムの一部であり、このユーザコンテキストシステムには、ある実施形態によれば、通知を処理する方法に関する判断のために比較される３つの要素が含まれる。第１の要素は、ユーザのコンテキスト（オペレーティングシステムおよびそのコンテキストを拡張した任意のプログラムによって提供することができる）である。第２の要素は、ユーザのルールおよびプリファレンスである。第３の要素は、通知自体（ユーザのルールと一致する可能性があるデータおよびプロパティなどの要素を含む）である。
【００８８】
ユーザコンテキストシステムは、オペレーティングシステムおよびユーザのコンテキストを宣言する他のプログラムによって、システムがユーザのコンテキストおよびルールを仲介した後に動作する。通知は、システムへの呼出しを行う他のプログラムによって手前に上げられる。ユーザのコンテキスト、ルール、および通知の要素が、比較され、その後、通知に関して何を行うべきかに関する判定が行われる。通知に関して行うことができるものに関するさまざまなオプションの例に、拒否（たとえば、通知が人目を引くか騒ぐことを許可されない場合に、通知は絶対にユーザによって見られない）、据置き（たとえば、ユーザのコンテキストが変化する、または配送が後に適するようになることがユーザのルールから示されるまで通知が保持される）、配送（たとえば、ユーザのコンテキストおよびルールに従って通知を配送することが許可される）、ルーティング（たとえば、通知が現在のシステムで配送を許可されるかどうかにかかわらず、通知を別のシステムに渡さなければならないことがユーザのルールによって示される）が含まれる。
【００８９】
一般に、ユーザは、「求めに応じられない」とみなされる状態にある場合があり、その場合には、通知は、配送されないか、ユーザが「求めに応じられる」ようになるまで保持されるのいずれかになる。たとえば、ユーザが、フルスクリーンアプリケーションを実行している場合に、そのユーザを、求めに応じられないと見なすことができる。あるいは、ユーザは、「求めに応じることができる」が、ユーザに適するように通知を修正する必要がある状態である場合がある。たとえば、ユーザが、音楽を聴いているか会議中である場合に、そのユーザが、通知をユーザの画面に配送しなければならないが、通知が鳴らすサウンドを、音量を下げるか全く再生しないようにしなければならないことを指示することができる。
【００９０】
上記のように、ユーザコンテキストは、通知をユーザの画面に表示するかどうかを部分的に決定することができる。通知を表示するときに、その通知をユーザコンテキスト内で、ある勾配（gradient）に基づいて表示することができる。言い換えると、指定できる、描かれる通知の形態の異なるレベルの侵襲性（invasiveness）がある。たとえば、従来の通知は、自由にクライアント領域にポップアウトし、短い間だけウィンドウを隠す。ユーザがわずかに制限的なコンテキストにいる場合、この通知は自由に表示できるが、別のウィンドウの上への描画を許可されないなど、より侵襲性でない形でのみ表示できるものとすることができる。もう１つの例として、一実施形態で、ユーザが最大化されたアプリケーションを実行している場合に、デフォルト設定は、コンテキストがわずかに制限的であること、およびユーザが、このアプリケーションがクライアント領域全体を得ることを望むと明確に述べていることを意味するものとすることができる。この設定では、通知はまだ描画することを許可されるが、サイドバー内に現れるだけにされることができる。言い換えると、通知描画形式におけるこのタイプの侵襲性の減少は、通知の影響を減らし、認識の負荷を全体的に減らす。
【００９１】
ユーザコンテキストシステムは、特許文献４、表題「System and Method Utilizing Test Notifications」に詳細に記載されている。
【００９２】
名前空間３０８の通知機能性は、アプリケーション設計者が、彼ら自身の通知を作成し、それらをデスクトップに表示させて、ユーザにとって重要である可能性がある何か（たとえば、電子メールメッセージが受信された、インスタントメッセージが受信されたなど）が発生したときにユーザに通知できるようにする。名前空間３０８の通知機能性によって、さらに、ユーザが複数のアプリケーションからの通知に関する自身のルールおよびプリファレンスを定義する中央ロケーションが提供され、ユーザが、同一のルールおよびプリファレンスを複数回（複数のアプリケーションのそれぞれに１回）セットするという煩わしさから解放される。
【００９３】
さらに、Ｃｏｎｔａｃｔｓ名前空間で、連絡先情報に関するコントロールおよびダイアログのコレクションが定義される。この連絡先情報は、アイテムとしてストレージシステムに保管することができる。「連絡先」は、一般に、人、グループ、組織、会社、世帯、または他のタイプの識別可能なエンティティを指す。「連絡先情報」は、一般に、連絡先に対応する、連絡先の識別、接触、アクセス、対応、または通信に関係すると考えることができる情報を指す。連絡先情報は、アプリケーションによって、たとえば電子メール送信、電話の発呼、ウェブサイトへのアクセス、ゲーミングセッションの開始、金融トランザクションの実行など、所望の機能を実行するのに使用される。連絡先情報の非制限的な例に、名前、別名、電話番号、電子メールアドレス、家の住所、インスタントメッセージング（ＩＭ）アドレス、およびウェブアドレスが含まれる。連絡先情報は、連絡先の状況など、他のタイプの情報を指すこともできる。たとえば、連絡先が現在オンラインであるか電話に出ていることを示す情報を、広義に連絡先情報と考えることもできる。
【００９４】
Ｃｏｎｔａｃｔｓ名前空間は、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔａｃｔｓ」、「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔｒｏｌｓ」（図３のコントロール３１０）、または「Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｌｌａｂｏｒａｔｉｏｎ」など、プレゼンテーションサブシステム名前空間２００の一部であるが、Ｓｈｅｌｌ名前空間２０２の一部でないものとすることができる。その代わりに、Ｃｏｎｔａｃｔｓ名前空間を、Ｓｈｅｌｌ名前空間２０２の一部とすることができる。Ｃｏｎｔａｃｔｓ名前空間は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ名前空間の機能性を拡張するが、Ｓｈｅｌｌの一部として実装する必要はない（すなわち、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ名前空間３０２の一部である必要はない）。
【００９５】
Ｃｏｎｔａｃｔｓ名前空間を用いると、連絡先情報を、ユーザが１回だけ入力し、複数の異なるアプリケーションによってアクセスできるようになる。したがって、ユーザは、同一の連絡先情報を複数回（複数のアプリケーションのそれぞれについて１回）入力するという煩わしさから解放される。
【００９６】
Ｃｏｎｔａｃｔｓ名前空間のコントロールおよびダイアログには、下記が含まれる。
・ユーザがその保管された連絡先から連絡先を選択またはピックできるようにするのに使用されるＣｏｎｔａｃｔ Ｐｉｃｋｅｒダイアログ。たとえば、ユーザが、電子メールメッセージが送信される連絡先またはインスタントメッセージングに関する連絡先を選択できるようにする。ユーザは、たとえば、システムストレージ内にアイテムとして保管されたユーザの連絡先のすべてのリストをブラウズでき、これらの連絡先の１つまたは複数を選択することができる。Ｃｏｎｔａｃｔ Ｐｉｃｋｅｒダイアログは、特許文献５、表題「Ｃｏｎｔａｃｔ Ｐｉｃｋｅｒ」に詳細に記載されている。
・自由形式の名前などの連絡先情報をユーザが入力できるようにする（たとえば名前をタイプすることによって）のに使用され、連絡先情報が入力されるときに、その情報をユーザの保管された連絡先からの１つまたは複数の連絡先に解決するＣｏｎｔａｃｔ Ｔｅｘｔｂｏｘコントロール。解決された情報は、たとえば、ドロップダウンメニューに表示することができ、あるいは、ユーザが自由形式で名前を入力した場合にタイプイン行に自動的に挿入することができる。
・連絡先情報をユーザに表示するのに使用されるＣｏｎｔａｃｔコントロール。連絡先情報の編集または自由形式入力は、このコントロールによってサポートされない。
【００９７】
（名前空間メンバの例）
このセクションには、例の名前空間（たとえば、図３のプレゼンテーションサブシステム名前空間２００内の名前空間）によって公開できるメンバの例を記述した複数のテーブルが含まれる。これらの公開されるメンバに、たとえば、クラス、インターフェース、列挙、および委任を含めることができる。これらの例に記載されたメンバが、例にすぎず、代替の他のメンバを名前空間によって公開できることを理解されたい。
【００９８】
下記の名前空間の一部で、あるクラス、インターフェース、列挙、および委任の記述が空白のままにされていることを理解されたい。
【００９９】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ＞＞
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓ名前空間によって公開されるメンバの例を示す。
【０１００】
＜クラス＞
DefaultCommandEventArgs − ＤｅｆａｕｌｔＣｏｍｍａｎｄＥｖｅｎｔイベントに関するイベントデータを含む。
ExplorerView − フォルダの内容に関する情報をユーザが見られるようにする。
FolderSelectionChangedEventArgs − ＦｏｌｄｅｒＳｅｌｅｃｔｉｏｎＣｈａｎｇｅｄＥｖｅｎｔイベントに関するイベントデータを含む。
IncludeItemEventArgs − ＩｎｃｌｕｄｅＩｔｅｍＥｖｅｎｔイベントに関するイベントデータを含む。
ItemVerbModifyEventArgs − ＩｔｅｍＶｅｒｂＭｏｄｉｆｙＥｖｅｎｔＡｒｇｓクラスの新しいインスタンスを初期化する。
NavigationCompleteEventArgs − ＮａｖｉｇａｔｉｏｎＣｏｍｐｌｅｔｅＥｖｅｎｔイベントのイベントデータを含む。
NavigationFailedEventArgs − ＮａｖｉｇａｔｉｏｎＦａｉｌｅｄＥｖｅｎｔイベントのイベントデータを含む。
NavigationPendingEventArgs − ＮａｖｉｇａｔｉｏｎＰｅｎｄｉｎｇＥｖｅｎｔイベントのイベントデータを含む。
【０１０１】
＜列挙＞
FolderViewFlags − ＥｘｐｌｏｒｅｒＶｉｅｗのビュープロパティを示す。
FolderViewMode − ＥｘｐｌｏｒｅｒＶｉｅｗのビューモードを示す。
【０１０２】
＜委任＞
DefaultCommandEventHandler − ＤｅｆａｕｌｔＣｏｍｍａｎｄＥｖｅｎｔを処理するメソッドを表す。
FolderSelectionChangedEventHandler − ＦｏｌｄｅｒＳｅｌｅｃｔｉｏｎＣｈａｎｇｅｄＥｖｅｎｔを処理するメソッドを表す。
IncludeItemEventHandler − ＩｎｃｌｕｄｅＩｔｅｍＥｖｅｎｔを処理するメソッドを表す。
ItemVerbModifyEventHandler − ＩｔｅｍＶｅｒｂＭｏｄｉｆｙＥｖｅｎｔを処理するメソッドを表す。
NavigationCompleteEventHandler − ＮａｖｉｇａｔｉｏｎＣｏｍｐｌｅｔｅＥｖｅｎｔを処理するメソッドを表す。
NavigationFailedEventHandler − ＮａｖｉｇａｔｉｏｎＦａｉｌｅｄＥｖｅｎｔを処理するメソッドを表す。
NavigationPendingEventHandler − ＮａｖｉｇａｔｉｏｎＰｅｎｄｉｎｇＥｖｅｎｔを処理するメソッドを表す。
【０１０３】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓ＞＞
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓ名前空間によって公開されるメンバの例を示す。
【０１０４】
＜クラス＞
ColorDialog
CommonDialog
DialogControlItemSelectedEventArgs
FileDialog − ＯｐｅｎＦｉｌｅＤｉａｌｏｇおよびＳａｖｅＦｉｌｅＤｉａｌｏｇＢａｓｅの親クラスとして使用される抽象クラス。
FileDialogCheckButton − ＦｉｌｅＤｉａｌｏｇに配置できるチェックボックスコントロールを表す
FileDialogComboBox
FileDialogContainerControlBase −ＦｉｌｅＤｉａｌｏｇＣｏｍｂｏＢｏｘ、ＦｉｌｅＤｉａｌｏｇＯｐｅｎＤｒｏｐＤｏｗｎ、ＦｉｌｅＤｉａｌｏｇＲａｄｉｏＢｕｔｔｏｎＧｒｏｕｐ、およびＦｉｌｅＤｉａｌｏｇＴｏｏｌｂａｒＭｅｎｕの親クラスとして使用される抽象クラス。
FileDialogControlBase − ＦｉｌｅＤｉａｌｏｇＣｈｅｃｋＢｕｔｔｏｎ、ＦｉｌｅＤｉａｌｏｇＥｄｉｔＢｏｘ、ＦｉｌｅＤｉａｌｏｇＰｕｓｈＢｕｔｔｏｎ、およびＦｉｌｅＤｉａｌｏｇＣｏｎｔａｉｎｅｒＣｏｎｔｒｏｌＢａｓｅの親クラスとして使用される抽象クラス。
FileDialogControlItem
FileDialogEditBox − ＦｉｌｅＤｉａｌｏｇに配置できるテキストボックスコントロールを表す。
FileDialogOpenDropDown
FileDialogPushButton − ＦｉｌｅＤｉａｌｏｇに配置できるボタンコントロールを表す。
FileDialogRadioButtonGroup
FileDialogToolbarMenu
FileOkEventArgs
FileType
OpenFileDialog − ユーザが１つまたは複数のファイルを開けるようにする。このクラスを継承することはできない。
SaveAsFileDialog − ユーザが、ファイルが保存されるロケーションを選択でき、ファイル名を指定できるようにする。このクラスを継承することはできない。
SaveFileDialog − ユーザが、ファイルを保存するロケーションを選択できるようにする。このクラスを継承することはできない。
SaveFileDialogBase − ＳａｖｅＡｓＦｉｌｅＤｉａｌｏｇおよびＳａｖｅＦｉｌｅＤｉａｌｏｇの親クラスとして使用される抽象クラス。
【０１０５】
＜列挙＞
FileDialogLayout
TileAttributes
【０１０６】
＜委任＞
DialogControlItemSelectedEventHandler
FileOkEventHandler
【０１０７】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｄｅｓｋｔｏｐ＞＞
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｄｅｓｋｔｏｐ名前空間によって公開されるメンバの例を示す。この名前空間には、サイドバーおよび通知にかかわる要素が含まれる。
【０１０８】
＜クラス＞
AnalogClockPanel
Appbar
AreaButton
BaseComTile
BaseSidebarClockSettings
BaseTile − カスタムサイドバータイル実装の親クラスとして使用される抽象クラス。
BasketControl
CalendarElement
CalendarImages
ChildrenWontFitArgs
ClockHacks
ClockPanel
DataSourceEventArgs − データソースから渡されるイベントデータを表す。
DigitalDateTimeElement
DragButton
DragControlWindow
DraggableButton
DragWindow
DropArgs
DropEventArgs
ExtraSpaceArgs
FillAlphaPresenter
FillImageResourcePresenter
FillPanel
FillPresenter
Flyout
FlyoutLinkClickEventArgs − サイドバータイルのフライアウト（flyout）ビューの最下部にあるオプションのリンクから発するイベントに応答してＲＭＡＡｃｔｉｏｎＥｖｅｎｔＨａｎｄｌｅｒに渡されるイベントデータを表す。
FlyoutPresenter
FlyoutStuff
FocusableButton
FocusWithinWorkaroundHelper
FolderContentsChangedEventArgs − フォルダの内容の変化に応答してＦｏｌｄｅｒＣｏｎｔｅｎｔｓＣｈａｎｇｅｄＥｖｅｎｔＨａｎｄｌｅｒに渡されるイベントデータを表す。
GlobalSetting
HackBorder
HackImage
ImageButton
ImageResource
ImageResourcePresenter
ItemControl
ItemToolbarControl
ListMakerControl
MenuStuff
NativeResource
NativeResourceHelper
NativeResources
NativeResourceTypeConverter
NormalButton
Notification − システムが１つのユーザインターフェースにおいてユーザに送るメッセージおよびそれに関連するデータを表す。
NotificationArea
NotificationButton − 通知に表示されるボタンを定義する。
NotificationClickedEventArgs − 通知ウィンドウ内でのクリックイベントに関連するデータを含む。
NotificationContext − アプリケーションが現在特定の状態であるか否かを宣言する。この状態は、ユーザのコンテキストの定義の一部として使用される。
NotificationTimerPresenter
NotifyCompleteEventArgs
NotifyWindow
OptionsButton
OuterTile
OverflowableCollection
OverflowableControlCollection
OverflowPanel
OverflowPresenter
OverFlowWrapper
PanelInfo
ProgressBar
QuickLaunchTile
RMAActionEventArgs − リッチミニマイズドアプリケーション（Rich Minimized Application、ＲＭＡ）によって生成されるイベントデータを表す。ＲＭＡＡｃｔｉｏｎＥｖｅｎｔＨａｎｄｌｅｒによって消費される。
RMAData
SetDataArrayEventArgs − データアレイによって生成され、ＳｅｔＤａｔａＡｒｒａｙＥｖｅｎｔＨａｎｄｌｅｒに送られるイベントデータを表す。
Sidebar
SidebarAlarmClock
SideBarClock
SidebarClockSettings
SlideShowTile
StackAlphaPresenter
StackImageResourcePresenter
StartButton
SyncHelper
SyncItemBar
SyncTile
Taskbar
TaskChevron
TaskGroup
TaskItem
TaskList
TaskOverflow
TaskOverflowableControlCollection
TaskPresenter
TestTile
TestTimeZone
TextElementFontInfo
Theme
ThemeHelper
ThemeHelperOld
ThemeImage
ThemeImageTypeConverter
ThemeResources
Tile
TileCollection
TileOverflow
TileThumb
TileThumbDotNet
Timer
TimerStuff
TimeZone
ViewStatusControl
WebHostEventArgs
WindowOrigin
WindowOriginOld
WindowStuff
【０１０９】
＜インターフェース＞
ICOMDataSourceHandler − 管理されないコードで実施されるデータソースを作成し、これと通信するのに使用される。
IOverflow
IOverflowList
ISidebar − 個々のタイルをホスティングするサイドバーへのアクセスを提供する。サイドバーホストは、フライアウトのオープンおよびクローズ、ショートカットメニューの表示、および個々のタイルに関連するイベントへの応答の責任を負う。
ISidebarAlarm
【０１１０】
＜列挙＞
AlarmState
BasketFlags
DragWindowPos
InvokeFolderActionEnum − ユーザがフォルダのＩｔｅｍＣｏｎｔｒｏｌを呼び出すときに行うことを決定するための列挙。ＩｎｖｏｋｅＦｏｌｄｅｒＡｃｔｉｏｎおよびＩｔｅｍＣｏｎｔｒｏｌＩｎｖｏｋｅＦｏｌｄｅｒＡｃｔｉｏｎと共に使用される。
RMAAction − イベントアクションを定義するためにＡｃｔｉｏｎプロパティと共に使用される定数。
SelectionModeEnum
【０１１１】
＜委任＞
ChildrenWontFitHandler
DocumentCompleteEventHandler
DropEventHandler
DropHandler
DummyDelegateToSetupAppDomainProperly
ExtraSpaceHandler
FlyoutClosingEventHandler
FlyoutLinkClickEventHandler − ＦｌｙｏｕｔＬｉｎｋＣｌｉｃｋＥｖｅｎｔイベントを処理するメソッドを表す。
FolderContentsChangedEventHandler
NavigateErrorEventHandler
NotificationClickedEventHandler − ＮｏｔｉｆｉｃａｔｉｏｎＣｌｉｃｋｅｄＥｖｅｎｔイベントを処理するメソッドを表す。
NotifyCompleteEventHandler − ＮｏｔｉｆｙＣｏｍｐｌｅｔｅＥｖｅｎｔイベントを処理するメソッドを表す。
RMAActionEventHandler − ＲＭＡＡｃｔｉｏｎＥｖｅｎｔイベントを処理するメソッドを表す。
SetDataArrayEventHandler − ＳｅｔＤａｔａＡｒｒａｙＥｖｅｎｔイベントを処理するメソッドを表す。
【０１１２】
＜＜Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔｒｏｌｓ＞＞
シェルコンポーネントによって使用されるクラスおよびインターフェースを提供する。
【０１１３】
以下に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｃｏｎｔｒｏｌｓ名前空間によって公開されるメンバの例を示す。
【０１１４】
＜クラス＞
ContactControl
ContactPickerDialog
ContactPropertyRequest
ContactPropertyRequestCollection
ContactSelection
ContactSelectionCollection
ContactTextBox
ContactTextBoxSelectionChangedEventArgs
ContactTextBoxTextChangedEventArgs
ContactTextBoxTextResolvedEventArgs
IncludeContactEventArgs
IteratedEventArgs
Iterator
OKCancelApplyEventArgs
OKCancelApplyStrip
【０１１５】
＜列挙＞
ContactControlPropertyPosition
ContactPickerDialogLayout
ContactPropertyCategory
ContactPropertyType
ContactType
OKCancelApplyType
【０１１６】
＜委任＞
ContactTextBoxSelectionChangedEventHandler
ContactTextBoxTextChangedEventHandler
ContactTextBoxTextResolvedEventHandler
IncludeContactEventHandler
IteratedEventHandler
OKCancelApplyEventHandler
OpenedEventHandler
【０１１７】
（例示的なコンピューティングシステムおよび環境）
図４に、プログラミングフレームワーク１３２を（完全にまたは部分的にのいずれかで）実施できる、適するコンピューティング環境４００の例を示す。コンピューティング環境４００は、本明細書に記載のコンピュータアーキテクチャおよびネットワークアーキテクチャで使用することができる。
【０１１８】
例示的なコンピューティング環境４００は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用の範囲または機能性に関する制限を示唆することを意図されたものではない。また、コンピューティング環境４００を、例示的なコンピューティング環境４００に示された、構成要素のいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。
【０１１９】
フレームワーク１３２を、多数の他の汎用または専用コンピューティングシステム環境または構成と共に実施することができる。使用に適する可能性がある衆知のコンピューティングシステム、コンピューティング環境、および／または構成の例に、パーソナルコンピュータ、サーバコンピュータ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれるが、これに制限されない。このフレームワークのコンパクト版またはサブセット版を、携帯電話、携帯情報端末、ハンドヘルドコンピュータ、または他の通信／コンピューティング装置などの限られたリソースのクライアントで実施することもできる。
【０１２０】
フレームワーク１３２を、１つまたは複数のコンピュータまたは他の装置によって実行される、プログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。フレームワーク１３２は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージ装置を含むローカルおよびリモートの両方のコンピュータストレージ媒体に配置することができる。
【０１２１】
コンピューティング環境４００に、コンピュータ４０２の形の汎用コンピューティング装置が含まれる。コンピュータ４０２のコンポーネントには、１つまたは複数のプロセッサまたは処理装置４０４、システムメモリ４０６、および処理装置４０４を含むさまざまなシステムコンポーネントをシステムメモリ４０６に接続するシステムバス４０８を含めることができるが、これに制限はされない。
【０１２２】
システムバス４０８は、メモリバスまたはメモリコントローラ、周辺バス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）、およびさまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む、複数の可能なタイプのバス構造の１つまたは複数を表す。たとえば、そのようなアーキテクチャに、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称するＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含めることができる。
【０１２３】
コンピュータ４０２に、通常は、さまざまなコンピュータ可読媒体が含まれる。そのような媒体は、揮発性媒体および不揮発性媒体、リムーバブル媒体および固定の媒体の両方を含む、コンピュータ４０２によってアクセス可能である任意の使用可能な媒体とすることができる。
【０１２４】
システムメモリ４０６には、ランダムアクセスメモリ（ＲＡＭ）４１０などの揮発性メモリおよび／または読取専用メモリ（ＲＯＭ）４１２などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。起動中などにコンピュータ４０２内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）４１４が、ＲＯＭ４１２に保管される。ＲＡＭ４１０には、通常は、処理装置４０４によって即座にアクセス可能および／または処理装置４０４によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。
【０１２５】
コンピュータ４０２に、他のリムーバブル／固定の、揮発性／不揮発性コンピュータストレージを含めることもできる。たとえば、図４に、固定の不揮発性磁気媒体（図示せず）から読み取り、これに書き込むハードディスクドライブ４１６、リムーバブル不揮発性磁気ディスク４２０（たとえば「フロッピ(登録商標)ディスク」）から読み取り、これに書き込む磁気ディスクドライブ４１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などのリムーバブル不揮発性光ディスク４２４から読み取り、かつ／またはこれに書き込む光ディスクドライブ４２２が含まれる。ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２は、それぞれ、１つまたは複数のデータメディアインターフェース４２３によってシステムバス４０８に接続される。その代わりに、ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２を、１つまたは複数のインターフェース（図示せず）によってシステムバス４０８に接続することができる。
【０１２６】
ディスクドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ４０２のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージを提供する。この例では、ハードディスク４１６、リムーバブル磁気ディスク４２０、およびリムーバブル光ディスク４２４が示されているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ）、および類似物などのコンピュータによってアクセス可能なデータを保管できる他のタイプのコンピュータ可読媒体を使用して、例示的なコンピューティングシステムおよび環境を実施することもできることを理解されたい。
【０１２７】
たとえば、オペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２を含む、任意の個数のプログラムモジュールを、ハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ４１２、および／またはＲＡＭ４１０に保管することができる。オペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２（またはその組合せ）に、プログラミングフレームワーク１３２の要素を含めることができる。
【０１２８】
ユーザは、キーボード４３４およびポインティング装置４３６（たとえば「マウス」）などの入力装置を介してコンピュータ４０２にコマンドおよび情報を入力することができる。他の入力装置４３８（具体的には図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、シリアルポート、スキャナ、および／または類似物を含めることができる。上記および他の入力装置は、システムバス４０８に接続された入出力インターフェース４４０を介して処理装置４０４に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などの他のインターフェースおよびバス構造によって接続することができる。
【０１２９】
モニタ４４２または他のタイプの表示装置を、ビデオアダプタ４４４などのインターフェースを介してシステムバス４０８に接続することもできる。モニタ４４２のほかに、他の出力周辺装置に、スピーカ（図示せず）およびプリンタ４４６など、入出力インターフェース４４０を介してコンピュータ４０２に接続できるコンポーネントを含めることができる。
【０１３０】
コンピュータ４０２は、リモートコンピューティング装置４４８などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。たとえば、リモートコンピューティング装置４４８を、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の一般的なネットワークノード、などとすることができる。リモートコンピューティング装置４４８は、コンピュータ４０２に関して本明細書で説明した要素および特徴の多くまたはすべてを含めることができるポータブルコンピュータとして図示されている。
【０１３１】
コンピュータ４０２とリモートコンピュータ４４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５０および一般的な広域ネットワーク（ＷＡＮ）４５２として図示されている。そのようなネットワーキング環境は、オフィス、会社規模のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【０１３２】
ＬＡＮネットワーキング環境において実施されるときに、コンピュータ４０２は、ネットワークインターフェースまたはネットワークアダプタ４５４を介してローカルネットワーク４５０に接続される。ＷＡＮネットワーキング環境において実施されるときに、コンピュータ４０２に、通常は、広域ネットワーク４５２を介する通信を確立する、モデム４５６または他の手段が含まれる。モデム４５６は、コンピュータ４０２の内蔵または外付けとすることができるが、入出力インターフェース４４０または他の適当な機構を介してシステムバス４０８に接続することができる。図示のネットワーク接続が、例示的であり、コンピュータ４０２と４４８の間の通信リンクを確立する他の手段を使用できることを理解されたい。
【０１３３】
コンピューティング環境４００と共に図示されたものなどのネットワーク化された環境において、コンピュータ４０２に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置に保管することができる。たとえば、リモートアプリケーションプログラム４５８が、リモートコンピュータ４４８の記憶装置に常駐している。例示のために、アプリケーションプログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントが、本明細書では別個のブロックに図示されているが、そのようなプログラムおよびコンポーネントが、さまざまなときにコンピューティング装置４０２の異なるストレージコンポーネントに常駐することができ、コンピュータのデータプロセッサによって実行されることを理解されたい。
【０１３４】
フレームワーク１３２、具体的にはＡＰＩ１４２またはＡＰＩ１４２に対して行われる呼出しの実装を、ある形のコンピュータ可読媒体を介して保管または伝送することができる。コンピュータ可読媒体は、コンピュータによってアクセスできる任意の使用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体に、「コンピュータストレージ媒体」および「通信媒体」を含めることができる。「コンピュータストレージ媒体」には、揮発性および不揮発性、取外し可能および取外し不能の、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージに関する方法またはテクノロジで実施される媒体が含まれる。コンピュータストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気記憶装置、あるいは、所望の情報を保管するのに使用でき、コンピュータによってアクセスできる他のすべての媒体が含まれるが、これに制限はされない。
【０１３５】
「通信媒体」によって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが実施される。通信媒体には、すべての情報配信媒体も含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形で、その特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれる。
【０１３６】
その代わりに、フレームワークの諸部分を、ハードウェアで、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組合せで実施することができる。たとえば、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）またはプログラマブルロジックデバイス（ＰＬＤ）を設計またはプログラムして、本フレームワークの１つまたは複数の部分を実施することができる。
【０１３７】
プログラミングインターフェース（または単にインターフェース）は、コードの１つまたは複数のセグメントが、コードの１つまたは複数の他のセグメントと通信するかそのセグメントによって提供される機能性にアクセスできるようにする機構、処理、プロトコルとみなすことができる。その代わりに、プログラミングインターフェースを、他のコンポーネントの１つまたは複数の機構、メソッド、関数呼出し、モジュールなどとの通信接続が可能なシステムのコンポーネントの１つまたは複数の機構、メソッド、関数呼出し、モジュール、オブジェクトなどとみなすことができる。前の文の用語「コードのセグメント」は、コードの１つまたは複数の命令または行を含むことが意図されており、これには、使用される用語、コードセグメントが別々にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードのどれとして提供されるか、コードセグメントがランタイムシステム内またはプロセス内で使用されるかどうか、コードセグメントが同一のマシンまたは異なるマシンに配置されるか、あるいはマシンにまたがって分散されるかどうか、コードのセグメントによって表される機能性が、完全にソフトウェアで、完全にハードウェアで、あるいはハードウェアとソフトウェアの組合せのどれで実施されるかに無関係に、たとえば、コードモジュール、オブジェクト、サブルーチン、関数などが含まれる。
【０１３８】
概念上、プログラミングインターフェースは、一般的に、図５または図６に示されているように見ることができる。図５に、第１コードセグメントと第２コードセグメントがそれを介して通信する導管としてのインターフェースＩｎｔｅｒｆａｃｅ１を示す。図６に、システムの第１コードセグメントおよび第２コードセグメントが媒体Ｍを介して通信できるようにする、インターフェースオブジェクトＩ１およびＩ２（第１および第２コードセグメントの一部とすることも、そうしないこともできる）を含むものとしてインターフェースを示す。図６に鑑みて、インターフェースオブジェクトＩ１およびＩ２を、同一のシステムの別々のインターフェースと考えることができ、オブジェクトＩ１およびＩ２と媒体Ｍにインターフェースが含まれると考えることもできる。図５および７に、両方向のフローおよびフローの両側のインターフェースを示したが、ある実施形態では、一方向の情報フローだけを有する（または、下で示すように情報フローなし）ことができ、あるいは、片側だけにインターフェースオブジェクトを有することができる。制限ではなく例として、アプリケーションプログラミングまたはプログラムインターフェース（ＡＰＩ）、エントリポイント、メソッド、関数、サブルーチン、リモートプロシージャコール、およびコンポーネントオブジェクトモデル（ＣＯＭ）インターフェースなどの用語が、プログラミングインターフェースの定義に含まれる。
【０１３９】
そのようなプログラミングインターフェースの態様に、第１コードセグメントが情報（ここで、「情報」は、その最も広い意味で使用され、「情報」には、データ、コマンド、要求などが含まれる）を第２コードセグメントに送る方法と、第２コードセグメントがその情報を受け取る方法と、情報の構造、シーケンス、構文、編成、スキーマ、タイミング、および内容とを含めることができる。これに関して、基礎になるトランスポート媒体自体は、媒体が有線、無線またはその両方の組合せのどれであれ、インターフェースによって定義される形で情報がトランスポートされる限り、インターフェースの動作に重要でない可能性がある。ある状況では、情報転送が別の機構を介する（たとえば、情報が、コードセグメントの間で流れる情報と別に、バッファ、ファイルなどに置かれる）ので、従来の意味で一方向または両方向に渡されないか、あるコードセグメントが第２コードセグメントによって実行される機能性に単純にアクセスするので情報が存在しない場合がある。これらの態様のいずれかまたはすべてが、所与の状況で、たとえば、コードセグメントが疎結合された構成または密結合された構成のどちらの一部であるかに応じて、重要になる可能性があり、したがって、このリストは、例示的であり、非限定的とみなされなければならない。
【０１４０】
プログラミングインターフェースのこの概念は、当業者に既知であり、本発明の前述の詳細な説明から明白である。しかし、プログラミングインターフェースを実施する他の形があり、明示的に除外されない限り、これらも、本明細書に記載の請求項に含まれることが意図されている。そのような他の形は、図５および７の極度に単純化された図よりも洗練されて見える、または複雑に見える可能性があるが、それでも、そのような他の形によって、同一の全体的な結果を達成する類似する機能が実行される。これから、プログラミングインターフェースの例示的な代替実施形態を短く説明する。
【０１４１】
Ａ．因数分解
あるコードセグメントから別のコードセグメントへの通信は、通信を複数の個別の通信に分解することによって、間接的に達成することができる。これを、図７および９に概略的に示す。図からわかるように、いくつかのインターフェースを、機能性の分割可能なセットとして記述することができる。したがって、数学的に２４または２×２×３×２を提供するように、図５および７のインターフェースの機能性を因数分解して、同一の結果を達成することができる。したがって、図７からわかるように、インターフェースＩｎｔｅｒｆａｃｅ１によって提供される機能を再分割して、このインターフェースの通信を複数のインターフェース、Ｉｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃなどに変換し、同一の結果を達成することができる。図８からわかるように、インターフェースＩ１によって提供される機能性を、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに再分割し、それと同時に同一の結果を達成することができる。同様に、第１コードセグメントから情報を受け取る第２コードセグメントのインターフェースＩ２を、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに因数分解することができる。因数分解するときに、第１コードセグメントに含まれるインターフェースの数が、第２コードセグメントに含まれるインターフェースの数と一致する必要はない。図７および９のどちらの場合でも、インターフェースＩｎｔｅｒｆａｃｅ１およびＩ１の機能的趣旨は、それぞれ図５および７と同一のままである。インターフェースの因数分解は、関連するプロパティ、累算的プロパティ、および他の数学的プロパティに従う場合もあり、因数分解の理解が困難な場合がある。たとえば、動作の順序付けは、重要でない場合があり、その結果、あるインターフェースによって実行される機能を、別のコードまたはインターフェースによって、インターフェースに達するよりかなり前に実行することができ、あるいは、システムの別々の構成要素によって実行することができる。さらに、プログラミング技術の当業者は、同一の結果を達成する異なる関数呼出しを行うさまざまな形があることを理解することができる。
【０１４２】
Ｂ．再定義
いくつかの場合に、初期の結果を達成しながら、プログラミングインターフェースのある態様（たとえばパラメータ）を無視し、追加し、または再定義することが可能である場合がある。これを、図９および１１に示す。たとえば、図５のインターフェースＩｎｔｅｒｆａｃｅ１に、関数呼出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、ｏｕｔｐｕｔ）すなわち、３つのパラメータｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、およびｏｕｔｐｕｔを含む呼出しであって、第１コードセグメントから第２コードセグメントに発行される関数呼出しが含まれると仮定する。真ん中のパラメータｐｒｅｃｉｓｉｏｎが、図９に示されているように、所与のシナリオで関係がない場合に、無視することができ、意味のない（この状況）パラメータと置換することができる。関係のない追加のパラメータを追加することもできる。どちらの場合でも、ｉｎｐｕｔが第２コードセグメントによって二乗された後にｏｕｔｐｕｔが返される限り、ｓｑｕａｒｅ（二乗）の機能性を達成することができる。ｐｒｅｃｉｓｉｏｎ（精度）は、コンピューティングシステムの下流または他の部分に意味のあるパラメータとすることもできるが、二乗計算の狭い目的について精度が必要でないことが理解されたならば、置換するか無視することができる。たとえば、結果に悪影響を及ぼさずに、有効な精度値を渡すのではなく、誕生日などの意味のある値を渡すことができる。同様に、図１０に示されているように、インターフェースＩ１が、インターフェースへのパラメータを無視するか追加するために再定義されたインターフェースＩ１’に置換される。インターフェースＩ２は、同様に、不要なパラメータを無視するか、ほかで処理できるパラメータについて再定義されたインターフェースＩ２’として再定義することができる。ここでのポイントは、いくつかの場合に、プログラミングインターフェースに、パラメータなど、ある目的に不要な態様が含まれる場合があり、したがって、それらを無視するか再定義することができ、あるいは、他の目的のために他の形で処理できるということである。
【０１４３】
Ｃ．インラインコーディング
２つの別々のコードモジュールの機能性の一部またはすべてをマージし、これらの間の「インターフェース」の形を変えることが実行可能である場合もある。たとえば、図５および７の機能性を、それぞれ図１１および１３の機能性に変換することができる。図１１では、図５の前の第１コードセグメントおよび第２コードセグメントが、その両方を含む１つのモジュールにマージされている。この場合に、コードセグメントは、まだ互いに通信することができるが、インターフェースは、単一モジュールにより適する形に適合させることができる。したがって、たとえば、前のＣａｌｌステートメントおよびＲｅｔｕｒｎステートメントは、もはや不要とすることができるが、インターフェースＩｎｔｅｒｆａｃｅ１に準ずる類似する処理または応答を、まだ有効とすることができる。同様に、図１２では、図６のインターフェースＩ２の一部（またはすべて）を、インターフェースＩ１にインラインで記述して、インターフェースＩ１”を形成することができる。図からわかるように、インターフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａは、インターフェースＩ１とインラインにコーディングされて、インターフェースＩ１”を形成する。具体的な例として、図６のインターフェースＩ１が、関数呼出しｓｑｕａｒｅ（ｉｎｐｕｔ、ｏｕｔｐｕｔ）を実行し、これがインターフェースＩ２によって受け取られ、インターフェースＩ２は、第２コードセグメントによるｉｎｐｕｔを用いて渡された値の処理（二乗）の後に、二乗された結果にｏｕｔｐｕｔを用いて返すことを検討されたい。その場合に、第２コードセグメントによって実行される処理（ｉｎｐｕｔの二乗）を、インターフェースへの呼出しなしで、第１コードセグメントによって実行することができる。
【０１４４】
Ｄ．分離（ｄｉｖｏｒｃｅ）
あるコードセグメントから別のコードセグメントへの通信は、通信を複数の個別の通信に分解することによって、間接的に達成することができる。これを、図１３および１５に示す。図１３からわかるように、１または複数のミドルウェア（機能性および／またはインターフェース機能を元のインターフェースから分離するので、分離インターフェース）を設けて、第１インターフェースＩｎｔｅｒｆａｃｅ１の通信を、異なるインターフェース、この例ではインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃに従うように変換する。たとえば、これは、たとえばＩｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのインストールベースがあるが、そのオペレーティングシステムが、異なるインターフェース、この例ではインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃを使用するように変更される場合に行うことができる。ポイントは、第２コードセグメントによって使用された元のインターフェースが、もはや第１コードセグメントによって使用されるインターフェースと互換でなくなるように変更され、したがって、古いインターフェースと新しいインターフェースとに互換性を持たせるため、仲介物が使用されることである。同様に、図１４からわかるように、インターフェースＩ１からの通信を受け取る分離インターフェースＤＩ１を有し、インターフェース機能性を、たとえば、ＤＩ２と共に働くが同一の機能的結果を提供するように再設計されているインターフェースＩ２ａおよびＩ２ｂに送る、分離インターフェースＤＩ２を有する第３コードセグメントを導入することができる。同様に、ＤＩ１およびＤＩ２は、同一のまたは類似する機能的結果を提供しながら、図６のインターフェースＩ１およびＩ２の機能性を変換するように一緒に働くことができる。
【０１４５】
Ｅ．再記述
もう１つの可能な変形形態が、コードを動的に再記述して、インターフェース機能性を、同一の総合的な結果を達成する別のものに置換することである。たとえば、中間言語（たとえば、Ｍｉｃｒｏｓｏｆｔ（登録商標） ＩＬ、Ｊａｖａ（登録商標） ＢｙｔｅＣｏｄｅなど）で提示されるコードセグメントを、実行環境（．ＮＥＴ ｆｒａｍｅｗｏｒｋ（登録商標）、Ｊａｖａ（登録商標）ランタイム環境、または類似するランタイムタイプ環境によって提供されるものなど）内のジャストインタイム（ＪＩＴ）コンパイラまたはインタープリタに供給するシステムがある。ＪＩＴコンパイラは、第１コードセグメントから第２コードセグメントへの通信を動的に変換する、すなわち、それらを、第２コードセグメント（元のまたは異なる第２コードセグメント）が必要とする可能性がある異なるインターフェースに合わせることができる。これを、図１５および１７に示す。図１５からわかるように、この手法は、上で説明した分離シナリオに似ている。これは、たとえば、アプリケーションのインストールベースが、Ｉｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティングシステムと通信するように設計されているが、オペレーティングシステムが、異なるインターフェースを使用するように変更される場合に行うことができる。ＪＩＴコンパイラを使用して、通信を、オンザフライでインストールベースアプリケーションからオペレーティングシステムの新しいインターフェースに合わせることができる。図１６からわかるように、インターフェースを動的に再記述するこの手法は、動的因数分解、または他の形のインターフェースの変更にも適用することができる。
【０１４６】
代替実施形態を介してインターフェースとして同一のまたは類似する結果を達成する、上で説明したシナリオを、さまざまな形で、順次および／または並列で、または他の介在コードと共に、組みわせることもできることにも留意されたい。したがって、上で提示した代替実施形態は、相互に排他的ではなく、混合され、マッチングされ、かつ組み合わされて、図５および７で提示された包括的なシナリオと同一のまたは同等のシナリオを作ることができる。また、ほとんどのプログラミング構造と同様に、本明細書に記載されていないが、それでも本発明の趣旨および範囲によって表されるインターフェースの同一のまたは類似する機能性を達成する他の類似する形があることに留意されたい、すなわち、インターフェースの価値の基礎になるのは、少なくとも部分的に、インターフェースによって表される機能性と、インターフェースによって使用可能にされる有益な結果である。
【０１４７】
（結論）
本発明を、構造的特徴および／または方法論的動作に固有の言葉で説明したが、請求項で定義される本発明は、説明した特定の特徴または動作に必ずしも制限されないことを理解されたい。そうではなく、特定の特徴および動作は、請求される発明を実施する例示的な形として開示されたものである。
【符号の説明】
【０１４８】
１００ ネットワーク環境
１０４ ネットワーク
１０６，１１２，１１４，１２２〜１２９ 通信リンク
１３２ プログラミングフレームワーク
１４２ ＡＰＩレイヤ
４００ コンピューティング環境
４１６ ハードディスクドライブ
４１８ 磁気ディスクドライブ
４２２ 光ディスクドライブ
４２０ リムーバブル不揮発性磁気ディスク
４２４ リムーバブル不揮発性光ディスク
４３８ 入力装置
【特許請求の範囲】
【請求項１】
型のセットをプログラミングインターフェースの単一の階層名前空間に編成する方法であって、
前記型のセットから複数の群を作成するステップであって、各群が、論理的に関連する機能性を公開する少なくとも１つの型を含むステップと、
前記複数の群の各群に名前を割り当てるステップであって、前記複数の群の第１群は、再利用可能なユーザインターフェースコントロールに関連する機能性を含み、サービスの前記第１群は、アイテムのプレビューイメージを表示できるようにするコントロールを含み、前記複数の群の第２群は、再利用可能なユーザインターフェースダイアログおよび再利用可能なユーザインターフェースウィザードに関連する機能性を含み、サービスの前記第２群は、ファイルおよびフォルダを開き、および保存できるようにする第１ダイアログを含み、前記複数の群の第３群は、ユーザインターフェース機能性の拡張に関連する機能性を含み、サービスの前記第３群は、アプリケーション定義のサムネイルの識別を可能にする機能性を含み、前記複数の群の第４群は、ユーザインターフェースデスクトップの機能性の拡張に関連する機能性を含み、サービスの前記第４群は、前記デスクトップにサイドバーを表示できるようにする機能性を含む、ステップと、
各群の前記型を、前記型を含む前記群の名前にプレフィックスとして付けられた選択されたトップレベル識別子を含む階層名によって参照するために、トップレベル識別子を選択し、前記トップレベル識別子を用いて各群の前記名前にプレフィックスを付けるステップと、
サービスの群のそれぞれによって使用されるオブジェクトモデルを定義するステップであって、前記オブジェクトモデルは、ユーザに提示できるアイテムを記述するＥｘｐｌｏｒｅｒＩｔｅｍオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトに対する照会を記述するＬｉｂｒａｒｉｅｓオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトからのデータを前記ユーザに射影するＶｉｅｗＦｉｅｌｄｓオブジェクト、および前記ｉｂｒａｒｉｅｓオブジェクトから生成されるダイナミックリストへのリンクを記述するＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクトを含む、ステップと
を備えたことを特徴とする方法。
【請求項２】
ユーザインターフェース機能性の拡張に関連する前記機能性は、
コンテキストメニューへの追加を可能にする第１機能性と、
１つまたは複数のファイルまたはフォルダに関する情報を表示するときに計算を実行できるようにする第２機能性と
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記割り当てるステップは、前記第３群にＡｄｄｉｎという名前を割り当てるステップを含み、前記第３群の前記階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ａｄｄｉｎになることを特徴とする請求項１に記載の方法。
【請求項４】
ユーザインターフェースデスクトップの機能性の拡張に関連する前記機能性は、
前記デスクトップにサイドバーを表示できるようにする第１機能性と、
アプリケーション定義の通知を前記デスクトップに表示できるようにする第２機能性と
を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記割り当てるステップは、前記第４群にＤｅｓｋｔｏｐという名前を割り当てるステップを含み、前記第４群の階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｅｓｋｔｏｐになることを特徴とする請求項１に記載の方法。
【請求項６】
前記割り当てるステップは、前記第１群にＣｏｎｔｒｏｌｓという名前を割り当てるステップと、前記第２群にＤｉａｌｏｇｓという名前を割り当てるステップとを含み、前記第１群の階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓになり、前記第２群の階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓになることを特徴とする請求項１に記載の方法。
【請求項７】
再利用可能なユーザインターフェースコントロールに関連する前記機能性は、
フォルダの内容に関する情報をユーザが見られるようにする第１コントロールと、
アプリケーション定義の方法でアイテムを表示できるようにする第２コントロールと、
アイテムをリストに追加できるようにする第３コントロールと
を含むことを特徴とする請求項１に記載の方法。
【請求項８】
再利用可能なユーザインターフェースダイアログおよび再利用可能なユーザインターフェースウィザードに関連する前記機能性は、
光ディスクに書き込めるようにする第１ウィザードと、
電子メールによってイメージを送信するのを容易にする第２ウィザードと
を含むことを特徴とする請求項１に記載の方法。
【請求項９】
機能のセットをプログラミングインターフェースの単一の階層名前空間に編成するためのシステムであって、
ユーザインターフェースの型のセットを階層名前空間に編成する手段と、
ユーザインターフェースの再利用可能なコントロールを可能にする機能の第１セットを公開する手段であって、前記機能の第１セットは、アイテムのプレビューイメージを表示できるようにするコントロールを含む、手段と、
前記ユーザインターフェースの再利用可能なダイアログおよび前記ユーザインターフェースの再利用可能なウィザードを可能にする機能の第２セットを公開する手段であって、前記機能の第２セットは、ファイルおよびフォルダを開き、および保存できるようにする第１ダイアログを含む、手段と、
前記ユーザインターフェースの機能性の拡張を可能にする機能の第３セットを公開する手段であって、前記機能の第３セットは、アプリケーション定義のサムネイルの識別を可能にする機能性を含む、手段と、
前記ユーザインターフェースのデスクトップの機能性の拡張を可能にする機能の第４セットを公開する手段であって、前記機能の第４セットは、前記デスクトップにサイドバーを表示できるようにする機能性を含む、手段と、
各群の前記型を、前記型を含む前記群の名前にプレフィックスとして付けられた選択されたトップレベル識別子を含む階層名によって参照するために、トップレベル識別子を選択し、前記トップレベル識別子を用いて各群の前記名前にプレフィックスを付ける手段と、
機能のセットのそれぞれによって使用されるオブジェクトモデルを公開する手段であって、前記オブジェクトモデルは、ユーザに提示できるアイテムを記述するＥｘｐｌｏｒｅｒＩｔｅｍオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトに対する照会を記述するＬｉｂｒａｒｉｅｓオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトからのデータを前記ユーザに射影するＶｉｅｗＦｉｅｌｄｓオブジェクト、および前記ｉｂｒａｒｉｅｓオブジェクトから生成されるダイナミックリストへのリンクを記述するＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクトを含む、手段と
を備えたことを特徴とするシステム。
【請求項１０】
前記機能の第３セットを公開する前記手段は、
コンテキストメニューへの追加を可能にする１つまたは複数の機能を公開する手段と、
１つまたは複数のファイルまたはフォルダに関する情報を表示するときに計算を実行できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１１】
前記機能の第１セットを公開する前記手段は、
フォルダの内容に関する情報をユーザが見られるようにする１つまたは複数の機能を公開する手段と、
アプリケーション定義の方法でアイテムを表示できるようにする１つまたは複数の機能を公開する手段と、
前記デスクトップのサイドバーにアイテムを追加できるようにする１つまたは複数の機能を公開する手段と、
リストにアイテムを追加できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１２】
前記機能の第２セットを公開する前記手段は、
光ディスクに書き込めるようにする１つまたは複数の機能を公開する手段と、
電子メールによって送信されるイメージのサイズを変更できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１３】
前記機能の第３セットを公開する前記手段は、
アプリケーション定義の通知を前記デスクトップに表示できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１】
型のセットをプログラミングインターフェースの単一の階層名前空間に編成する方法であって、
前記型のセットから複数の群を作成するステップであって、各群が、論理的に関連する機能性を公開する少なくとも１つの型を含むステップと、
前記複数の群の各群に名前を割り当てるステップであって、前記複数の群の第１群は、再利用可能なユーザインターフェースコントロールに関連する機能性を含み、サービスの前記第１群は、アイテムのプレビューイメージを表示できるようにするコントロールを含み、前記複数の群の第２群は、再利用可能なユーザインターフェースダイアログおよび再利用可能なユーザインターフェースウィザードに関連する機能性を含み、サービスの前記第２群は、ファイルおよびフォルダを開き、および保存できるようにする第１ダイアログを含み、前記複数の群の第３群は、ユーザインターフェース機能性の拡張に関連する機能性を含み、サービスの前記第３群は、アプリケーション定義のサムネイルの識別を可能にする機能性を含み、前記複数の群の第４群は、ユーザインターフェースデスクトップの機能性の拡張に関連する機能性を含み、サービスの前記第４群は、前記デスクトップにサイドバーを表示できるようにする機能性を含む、ステップと、
各群の前記型を、前記型を含む前記群の名前にプレフィックスとして付けられた選択されたトップレベル識別子を含む階層名によって参照するために、トップレベル識別子を選択し、前記トップレベル識別子を用いて各群の前記名前にプレフィックスを付けるステップと、
サービスの群のそれぞれによって使用されるオブジェクトモデルを定義するステップであって、前記オブジェクトモデルは、ユーザに提示できるアイテムを記述するＥｘｐｌｏｒｅｒＩｔｅｍオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトに対する照会を記述するＬｉｂｒａｒｉｅｓオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトからのデータを前記ユーザに射影するＶｉｅｗＦｉｅｌｄｓオブジェクト、および前記ｉｂｒａｒｉｅｓオブジェクトから生成されるダイナミックリストへのリンクを記述するＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクトを含む、ステップと
を備えたことを特徴とする方法。
【請求項２】
ユーザインターフェース機能性の拡張に関連する前記機能性は、
コンテキストメニューへの追加を可能にする第１機能性と、
１つまたは複数のファイルまたはフォルダに関する情報を表示するときに計算を実行できるようにする第２機能性と
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記割り当てるステップは、前記第３群にＡｄｄｉｎという名前を割り当てるステップを含み、前記第３群の前記階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ａｄｄｉｎになることを特徴とする請求項１に記載の方法。
【請求項４】
ユーザインターフェースデスクトップの機能性の拡張に関連する前記機能性は、
前記デスクトップにサイドバーを表示できるようにする第１機能性と、
アプリケーション定義の通知を前記デスクトップに表示できるようにする第２機能性と
を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記割り当てるステップは、前記第４群にＤｅｓｋｔｏｐという名前を割り当てるステップを含み、前記第４群の階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｅｓｋｔｏｐになることを特徴とする請求項１に記載の方法。
【請求項６】
前記割り当てるステップは、前記第１群にＣｏｎｔｒｏｌｓという名前を割り当てるステップと、前記第２群にＤｉａｌｏｇｓという名前を割り当てるステップとを含み、前記第１群の階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｃｏｎｔｒｏｌｓになり、前記第２群の階層名は、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｅｘｐｌｏｒｅｒ．Ｄｉａｌｏｇｓになることを特徴とする請求項１に記載の方法。
【請求項７】
再利用可能なユーザインターフェースコントロールに関連する前記機能性は、
フォルダの内容に関する情報をユーザが見られるようにする第１コントロールと、
アプリケーション定義の方法でアイテムを表示できるようにする第２コントロールと、
アイテムをリストに追加できるようにする第３コントロールと
を含むことを特徴とする請求項１に記載の方法。
【請求項８】
再利用可能なユーザインターフェースダイアログおよび再利用可能なユーザインターフェースウィザードに関連する前記機能性は、
光ディスクに書き込めるようにする第１ウィザードと、
電子メールによってイメージを送信するのを容易にする第２ウィザードと
を含むことを特徴とする請求項１に記載の方法。
【請求項９】
機能のセットをプログラミングインターフェースの単一の階層名前空間に編成するためのシステムであって、
ユーザインターフェースの型のセットを階層名前空間に編成する手段と、
ユーザインターフェースの再利用可能なコントロールを可能にする機能の第１セットを公開する手段であって、前記機能の第１セットは、アイテムのプレビューイメージを表示できるようにするコントロールを含む、手段と、
前記ユーザインターフェースの再利用可能なダイアログおよび前記ユーザインターフェースの再利用可能なウィザードを可能にする機能の第２セットを公開する手段であって、前記機能の第２セットは、ファイルおよびフォルダを開き、および保存できるようにする第１ダイアログを含む、手段と、
前記ユーザインターフェースの機能性の拡張を可能にする機能の第３セットを公開する手段であって、前記機能の第３セットは、アプリケーション定義のサムネイルの識別を可能にする機能性を含む、手段と、
前記ユーザインターフェースのデスクトップの機能性の拡張を可能にする機能の第４セットを公開する手段であって、前記機能の第４セットは、前記デスクトップにサイドバーを表示できるようにする機能性を含む、手段と、
各群の前記型を、前記型を含む前記群の名前にプレフィックスとして付けられた選択されたトップレベル識別子を含む階層名によって参照するために、トップレベル識別子を選択し、前記トップレベル識別子を用いて各群の前記名前にプレフィックスを付ける手段と、
機能のセットのそれぞれによって使用されるオブジェクトモデルを公開する手段であって、前記オブジェクトモデルは、ユーザに提示できるアイテムを記述するＥｘｐｌｏｒｅｒＩｔｅｍオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトに対する照会を記述するＬｉｂｒａｒｉｅｓオブジェクト、前記ＥｘｐｌｏｒｅｒＩｔｅｍオブジェクトからのデータを前記ユーザに射影するＶｉｅｗＦｉｅｌｄｓオブジェクト、および前記ｉｂｒａｒｉｅｓオブジェクトから生成されるダイナミックリストへのリンクを記述するＳｔｏｒａｇｅＦａｖｏｒｉｔｅｓオブジェクトを含む、手段と
を備えたことを特徴とするシステム。
【請求項１０】
前記機能の第３セットを公開する前記手段は、
コンテキストメニューへの追加を可能にする１つまたは複数の機能を公開する手段と、
１つまたは複数のファイルまたはフォルダに関する情報を表示するときに計算を実行できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１１】
前記機能の第１セットを公開する前記手段は、
フォルダの内容に関する情報をユーザが見られるようにする１つまたは複数の機能を公開する手段と、
アプリケーション定義の方法でアイテムを表示できるようにする１つまたは複数の機能を公開する手段と、
前記デスクトップのサイドバーにアイテムを追加できるようにする１つまたは複数の機能を公開する手段と、
リストにアイテムを追加できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１２】
前記機能の第２セットを公開する前記手段は、
光ディスクに書き込めるようにする１つまたは複数の機能を公開する手段と、
電子メールによって送信されるイメージのサイズを変更できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【請求項１３】
前記機能の第３セットを公開する前記手段は、
アプリケーション定義の通知を前記デスクトップに表示できるようにする１つまたは複数の機能を公開する手段と
を含むことを特徴とする請求項９に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１２−１２８８７８（Ｐ２０１２−１２８８７８Ａ）
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願番号】特願２０１２−６２４５６（Ｐ２０１２−６２４５６）
【出願日】平成２４年３月１９日（２０１２．３．１９）
【分割の表示】特願２００４−２６４６２７（Ｐ２００４−２６４６２７）の分割
【原出願日】平成１６年９月１０日（２００４．９．１０）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願日】平成２４年３月１９日（２０１２．３．１９）
【分割の表示】特願２００４−２６４６２７（Ｐ２００４−２６４６２７）の分割
【原出願日】平成１６年９月１０日（２００４．９．１０）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]