JP2010532046A - ハイブリッド資源マネージャー - Google Patents

Abstract

コンピューティング環境で使用するハイブリッド資源マネージャーが提供される。このハイブリッド資源マネージャーは、オペレーティングシステムと協調して、多機能ハードウェアデバイスのさまざまな機能に関連付けられる個別のデバイスドライバーのそれぞれを管理する単一の資源マネージャーとして機能する。一例では、ハイブリッド資源マネージャーは、一貫した管理及びポリシーのフレームワークを実施して、複数の機能がさまざまなアプリケーションによって同時に要求される時に衝突が生じることを防止する。

Description

本発明はハイブリッド資源マネージャーに関する。

オペレーティングシステムは、資源管理スキームを用いて、アプリケーション間の干渉を制限し、資源割り当てを優先順位付け及び別の方法で制御するポリシーを実施し、多くの独立したソフトウェアアプリケーションを実行しているシステムの全体的な振る舞いを一般に管理する。通例、デバイスの各クラスについて資源マネージャーが設けられる。このようなデバイスクラスの例には、キーボード、プリンター、ファクシミリ装置、スキャナー、ＣＤプレイヤー、ＤＶＤプレイヤー、ネットワークインターフェース、スマートカードリーダー、バイオメトリックスキャナー、及びメモリー記憶デバイス（例えば、フラッシュメモリー）等の周辺デバイスが含まれる。異なるクラスのデバイスのそれぞれは、通常、それ自身の資源マネージャーを有する。所与のクラス内の特定のデバイスは、一般に、互いに僅かに異なるので、一般的に、各特定のハードウェアデバイスに、デバイスドライバーとして知られている追加のソフトウェアコンポーネントが提供される。デバイスドライバーは、資源マネージャーと特定のハードウェアデバイスとの間の変換レイヤーとして働く。

デバイスドライバーは、一般的に、ハードウェアデバイスと通信する最下位レベルのソフトウェアコンポーネントとしてコンピューターシステムで使用される。通常、これらのデバイスドライバーは、自身が１対１の関係で制御するデバイスに関連付けられる。例えば、シリアルポートドライバーは、コンピューターのデータ／ファックスシリアルモデムに関連付けられ、統合交換デジタル網（ＩＳＤＮ：Integrated Switched Digital Network）ドライバーは、ＩＳＤＮインターフェースデバイスに関連付けられ、ネットワークドライバーは、広域ネットワーク（ＷＡＮ）データインターフェースデバイスへのインターフェースを提供する。このような構成では、各専用ドライバーが、ハードウェアデバイスのためにスタートアップ、シャットダウン、メンテナンス、及び機能動作を管理する。

技術の進歩によって、複数のハードウェアデバイスを単一の多機能デバイスに統合することが可能になった。例えば、単一のハードウェアデバイスが、データ／ファックスモデム、ＩＳＤＮ、及びＷＡＮインターフェースの機能の１つ又はすべてを実行することが可能な場合がある。別の例は、統合されたスマートカーダリーダー及びバイオメトリックスキャナーを有するキーボードとすることができる。このような多機能デバイスは、コストの削減、サイズの小型化、ホストシステムの負荷の削減、及びインストールの容易化を含めて、複数の単一機能のデバイスに対していくつかの利点を有する。しかしながら、従来のアプリケーションとの互換性を維持するには、これらの多機能デバイスは、依然として、例えば、キーボード、スマートカードリーダー、及びバイオメトリックスキャナー等の機能ごとに専用ドライバーを必要とする。各デバイスドライバーは独立に機能するので、複数のデバイスドライバーが単一のハードウェアデバイスへコマンドを送信する状況が起こる可能性がある。したがって、或るドライバーによって送信されたコマンドが、別のドライバーによって送信されたコマンドと衝突する場合があり、その結果、システムの誤動作となる可能性が存在する。例えば、或るドライバーは、他の独立したドライバーがハードウェアデバイスを使用している間、そのデバイスをシャットダウンするコマンドを送信する場合がある。別の例は、或るドライバーが、有効な結果を確保するために多機能デバイスへの排他的アクセスを必要とする診断テストの実行を試み、別のドライバーが、この診断テスト中、その多機能デバイスへのアクセスを試みる場合である。複数のデバイスドライバーが単一の多機能ハードウェアデバイスにアクセスすることで起こる可能性がある衝突は数多くある。

図１は、複数のデバイスドライバーを有するコンピューターシステム１０を示す。すなわち、デバイスドライバーＡ ２、デバイスドライバーＢ ４、及びデバイスドライバーＣ ６が多機能デバイス８に接続されている。動作中、コンピューターシステム１０に存在するアプリケーションは、第１の機能が多機能デバイス８によって実行されることを要求する場合がある。或る機能が要求されると、コンピューターシステム１０は、多機能デバイス８が要求された機能を実行するようにとのコマンドを多機能デバイス８へ送信するように、要求された機能に対応するドライバーに指示する。例えば、機能Ａが要求される場合、コンピューターシステム１０は、機能Ａを実行するようにとのコマンドを多機能デバイス８へ送信するようにデバイスドライバーＡ ２に指示する。しかしながら、上述したように、いくつかのデバイスドライバーは、衝突するコマンドを多機能デバイスへ発行する場合がある。衝突するコマンドが異なるドライバーから送信される原因は、多機能デバイスを有するシステムの数多くのシナリオに由来する場合がある。例えば、多機能デバイス８が、デバイスドライバーＡ ２によって機能Ａを実行するように指示を受ける一方、コンピューターシステム１０は、機能Ｂを実行するようにとのコマンドを多機能デバイス８へ発行するようにデバイスドライバーＢ ４に指示する場合がある。デバイスドライバーＢ ４によって発行されたコマンドの一部は、デバイスドライバーＡ ２によって発行されているコマンドと衝突するデバイス初期化コマンドの場合がある。このような場合、多機能デバイスは、この衝突のために、要求された機能のいくつか又はすべてを実行することができない。

衝突に加えて、複数のドライバーが多機能デバイスと共に使用される時に生じる別の問題はセキュリティに関係している。例えば、任意の所与の時刻に、或るアプリケーションが多機能デバイス８の１つの特定の機能のみを使用していることを確保し、他のすべてがロックダウンされることを確保することが必要なことが多い。

この問題に対する１つの可能な解決法は、デバイスドライバーを単一の多機能ドライバーに結合し、それによって、プログラムに従った方法を使用して衝突するコマンドを防止することである。しかしながら、この手法は、既存のドライバーのソフトウェアコードの大部分又はすべてを、単一のドライバーとして動作できるように書き換えることを必要とする場合がある。この解決法は、ソフトウェアのモジュール性も低減する。単一の結合されたドライバーは、より大きく且つより複雑となり、したがって、作成、試験、メンテナンス、及びアップグレードがより困難となる。ドライバー及び多機能デバイスのすべての異なる順列及び組み合わせが考慮される場合、複数のドライバーを単一の多機能ドライバーに結合することによって、必要とされるドライバーの総数は増加する可能性がある。したがって、ドライバーを別々に維持することが非常に望ましい。

以下の詳細な説明は、コンピューティング環境で使用するハイブリッド資源マネージャーを提示する。このハイブリッド資源マネージャーは、オペレーティングシステムと協調して、多機能ハードウェアデバイスのさまざまな機能に関連付けられる個別のデバイスドライバーのそれぞれを管理する単一の資源マネージャーとして機能する。一例では、ハイブリッド資源マネージャーは、一貫した管理及びポリシーのフレームワークを実施して、複数の機能がさまざまなアプリケーションによって同時に要求される時に衝突が生じることを防止する。

この概要は、詳細な説明でさらに後述する概念のうちの選択したものを簡略化した形態で紹介するために設けられている。この概要は、請求項に記載の主題の重要な特徴も本質的な特徴も特定することを意図するものではなく、また、請求項に記載の主題の範囲を決定することを助けるものとして使用されることを意図するものでもない。本発明の追加の特徴及び利点は、添付図面を参照して進行する実施形態の以下の詳細な説明から明らかになるであろう。

多機能ハードウェアデバイスと共に使用する複数のデバイスドライバーを有するコンピューターシステムを示す図である。 コンピューティングユニット、及びコンピューティングユニットと接続又は別の方法でインターフェースする複数の周辺コンポーネントを有するコンピューティングシステムを示す図である。 図２のコンピューティングシステムによって実施されて多機能ハードウェアデバイスの資源管理を容易にすることができる資源管理アーキテクチャーの一例を示す図である。 図３に示すハイブリッド資源マネージャーの１つの特定の例を示す図である。 コンピューティングシステムによって使用されるハードウェア資源の管理を容易にする方法の一例を示すフローチャートである。

コンピューティングデバイス上でのアプリケーションの実行を成功させるには、デバイスのオペレーティングシステムは、アプリケーションにさまざまな資源を提供しなければならない。それらの資源を管理する改良された方法を実施してそれら資源の効率的な割り当て及び使用を容易にするのに適したコンピューティングシステムが、以下の記載で詳細に説明される。

本明細書で説明する資源管理アーキテクチャーは、多くの多様な環境及びコンピューティングコンテキストで実施することができる。議論の目的で、このアーキテクチャーは、パーソナルコンピューター用のコンピューティングシステムのコンテキストで説明されるが、ゲームコンソール、携帯電話、ＰＤＡ、セットトップボックス（ＳＴＢ）等の多種多様な電子デバイスを含む他のコンピューティング環境にも等しく適用可能である。

後述するように、多機能ハードウェアデバイスをサポートするのに使用される単一の多機能ドライバーを提供する代わりに、ハイブリッド資源マネージャーが提供される。このハイブリッド資源マネージャーは、多機能ハードウェアデバイスの個別のデバイスドライバーと共に使用することができるが、ハードウェアデバイスにアクセスするすべてのアプリケーションが使用できる一貫した管理及びポリシーのフレームワークを提供することができる。

図２は、コンピューティングユニット２２及びコンピューティングユニット２２と接続又は別の方法でインターフェースする複数の周辺コンポーネントを有するコンピューティングシステム２０を示す。コンピューティングユニット２２は、１つ又は複数のプロセッサ２４（１）、２４（２）、…、２４（Ｐ）、揮発性メモリー２６（例えば、ＲＡＭ）、及び不揮発性メモリー２８（例えば、ＲＯＭ、フラッシュ、ハードディスク、ＣＤ ＲＯＭ等）を有する。

オペレーティングシステム３０が、不揮発性メモリー２８に記憶されている。オペレーティングシステム３０は、揮発性メモリー２６内にロードされて、１つ又は複数のプロセッサ２４上で実行されると、複数のアプリケーション３２（１）、３２（２）、…、３２（Ａ）の同時実行をサポートする、マルチタスクオペレーティングシステムである。１つの好ましいオペレーティングシステムは、Microsoft Corporationによって販売されているWindows（登録商標）ブランドのオペレーティングシステムである。しかしながら、他のオペレーティングシステムも用いることができることに留意されたい。

アプリケーション３２（１）、３２（２）、…、３２（Ａ）は、システムにロードして実行でき、ハードウェア資源へのアクセスを必要とする異なる資源コンシューマの例である。資源コンシューマには、ワードプロセッシングアプリケーション、スプレッドシートアプリケーション、データベースアプリケーション、スケジューリングアプリケーション、金融アプリケーション、教育アプリケーション、エンターテインメントアプリケーション等のアプリケーションを含むことができる。

オペレーティングシステム３０は、アプリケーション３２（１）〜３２（Ａ）への割り当てのためにコンピューティングシステム２０の資源を管理する資源管理システム４０を有する。資源管理システム４０は、オペレーティングシステム３０とは別個に実施することができるが、この例では、オペレーティングシステム内に統合されたものとして示されている。資源管理システム４０は、図３を参照してより詳細に後述される。

オペレーティングシステム３０は、コンピューティングシステム２０内のさまざまな関連付けられる周辺コンポーネント用の複数のソフトウェアドライバー４２（１）、…、４２（Ｄ）も有する。１つ又は複数のＣＯＭ（通信）ポート４４も、オペレーティングシステム３０の一部であるとして示されている。周辺コンポーネントの代表的な集合体が、コンピューティングユニット２２を取り囲んで示されている。

ＵＳＢバス５４は、コンピューティングシステム２２に接続されて、多くの異なる種類のＵＳＢ互換周辺コンポーネントをインターフェースする。このようなコンポーネントの例には、モデム５６、スピーカー５８、キーボード６０、及び他のＵＳＢデバイス６２が含まれる。コンピューティングユニット２２はまた、ネットワーク６６に結合されて、他のコンピューターとインターフェースする。ネットワーク６６は、ＬＡＮ、ＷＡＮ、インターネット、イントラネット、及び無線ネットワークを含む多くの多様なタイプのネットワークを表す。

１３９４シリアルバス６８は、コンピューティングユニット２２に接続されて、多くの異なる種類の１３９４互換周辺コンポーネントをインターフェースする。このようなコンポーネントの例には、メモリードライブ７０（例えば、ディスクドライブ、テープドライブ、ＣＤ ＲＯＭドライブ等）、モデム７２、スピーカー７４、ＣＰＵ（中央処理装置）７６、及び他の１３９４デバイス７８が含まれる。この例示のシステムには、ＵＳＢバス及び１３９４バスが示されているが、これに加えて又は代替的に、ＳＣＳＩバス、ＩＳＡ（業界標準アーキテクチャー）バス、及びＰＣＩ（周辺コンポーネント相互接続）バス等の他のバスアーキテクチャーを使用できることに留意されたい。

コンピューティングシステム２０は、ディスプレイ８０を有する。ディスプレイ８０は、テレビ又はコンピューターモニターとすることができる。ディスプレイは、１つ又は複数のディスプレイインターフェース８２（１）、８２（２）、…、８２（Ｃ）を介してコンピューティングユニット２２とインターフェースされる。これらディスプレイインターフェースは、ビデオポート、オーバーレイ、及びビデオメモリーを表す。コンピューティングユニット２２に結合された他の例示の周辺デバイスには、ＤＶＤプレイヤー８４、バイオメトリックスキャナー８６、及びスマートカードリーダー８８が含まれ得る。

図２に示すコンポーネントの集合体は、資源管理システム４０によって管理される例示の種類の資源を示す。それらの中には、キーボード、モデム、ＵＳＢデバイス、バイオメトリックスキャナー、スマートカードリーダー、１３９４デバイス、ディスプレイインターフェース、レコーダー、メモリードライブ等のさまざまなハードウェアデバイス資源がある。他の多くのコンポーネントをシステムに追加することができ、図示したコンポーネントの１つ又は複数を取り除くことができる。前述したように、これらのデバイスの２つ以上のものの機能を単一の多機能ハードウェアデバイスに結合することがますます一般的になってきている。

図３は、図２のコンピューティングシステム２０によって実施されて多機能ハードウェアデバイスの資源管理を容易にすることができる資源管理アーキテクチャー３００の一例を示す。アーキテクチャー３００は、ソフトウェアで実施され、この例では、カーネルレベルのコンポーネントだけでなくユーザレベルのコンポーネントも含む。アーキテクチャー３００は、ハイブリッド資源マネージャー３０２及びデバイスドライバー３０４（１）、３０４（２）、３０４（３）、…、３０４（Ｐ）を有する。これらは、１つ又は複数の資源コンシューマをサポートする。資源コンシューマの例には、アプリケーション３３２（１）、３３２（２）、３３２（３）、…、３３２（Ｎ）等のユーザレベル資源コンシューマが含まれる。図示するように、設けることができる１つのアプリケーションレベル資源コンシューマは、アプリケーションレベルの認証及びセキュリティを提供して、例えば、トロイ又は他のマルウェアが、パスワード、公開鍵等のユーザの証明書（credentials）のスプーフィングも、別の方法でのユーザの証明書へのアクセスもしないことを確保するための認証ユーザインターフェース３３２（１）である。図示しないが、カーネルレベル資源コンシューマも設けることができる。

各デバイスドライバー３０４（１）〜３０４（４）は、ハードウェアデバイスに関連付けられ、ハードウェアデバイスの可用性を追跡する。すなわち、上述したように、デバイスドライバーは、ハードウェアデバイスとインターフェースする任意のソフトウェアコンポーネント又はソフトウェアモジュールとすることができる。デバイスドライバー３０４（１）は、例えば、シリアルデータをモデムに渡すことを多機能デバイス３４０に可能にするシリアルドライバーとすることができる。デバイスドライバー３０４（２）は、例えば、呼の発信及び受信を多機能デバイス３４０に可能にするＩＳＤＮインターフェースドライバーとすることができ、デバイスドライバー３０４（３）は、例えば、ＷＡＮネットワークインターフェースデバイスへのデータの送信及び受信を多機能デバイス３４０に可能にするＷＡＮドライバーとすることができる。多機能デバイスの別の例は、フラッシュメモリーを有するスマートカードリーダー及びバイオメトリックリーダーを統合するキーボードとすることができる。この場合、デバイスドライバー３０４（１）はキーボードとすることができ、デバイスドライバー３０４（２）はスマートカードドライバーとすることができ、デバイスドライバー３０４（３）はバイオメトリックスキャナードライバーとすることができ、デバイスドライバー３０４（４）はフラッシュメモリードライバーとすることができる。さらに別の多機能デバイスは、ＷＡＮデータインターフェース、Ｘ．２５データインターフェース、及びデータ暗号化プロセッサを結合する仮想プライベートネットワーク（ＶＰＮ）カードとすることができる。これらのデバイスドライバーは、非常に複雑な場合があり、前述したように、一般に、独立したドライバーとして実施するのが最も良いとされる。もちろん、上述した多機能デバイス及びデバイスドライバーは例示にすぎず、本明細書で説明する原理は、任意の多機能ハードウェアデバイス及びこれらのデバイスとインターフェースするのに使用されるドライバーにも適用することができる。当業者は、技術が進歩するにつれて、より多くのハードウェア機能が利用可能になり、数多くのハードウェア機能を単一のデバイスに結合することが可能になること、並びに本明細書で説明する原理が、これら後に開発される多機能デバイス及びデバイスドライバーに等しく適用できることを理解するであろう。デバイスドライバーは、カーネルレベルで示されているが、１つ又は複数のデバイスドライバーは、ユーザレベルでも実施することができる。

各デバイスドライバー３０４は、自身をハイブリッド資源マネージャー３０２に登録し、ハイブリッド資源マネージャー３０２によって使用される一組のコールバックを供給して情報を得る。例えば、或るコールバックは、資源計算を行うのに使用され、別のコールバックは、予約に成功したことをプロバイダーに通知するのに使用される。ハイブリッド資源マネージャー３０２は、同じコンテキストがハイブリッドハードウェアデバイスに使用されることを可能にし、ハードウェアデバイスによって実行されるその機能について特定のデバイス資源マネージャーによって使用される対応するデバイスクラスハンドルを得ることを可能にする。

ハイブリッド資源マネージャー３０２は、アーキテクチャー内の他のモジュールとインタラクトするパブリックインターフェース３２０を公開する。パブリックインターフェース３２０は、デバイスドライバー３０４によって使用されるプロバイダーＡＰＩコールのセット及びアプリケーション３３２（１）〜３３２（Ｎ）又は他の資源コンシューマから資源の要求を受け付けるコンシューマＡＰＩコールのセットを有する定義されたＡＰＩ（アプリケーションプログラムインターフェース）を含む。ＡＰＩは、プログラムが所望のタスクを実行するために受け付ける入力の種類及びプログラムが所望のタスクの実行後に返す出力の種類を定義するプログラムに対するインターフェースである。アプリケーション３３２がタスクを実行したい時、アプリケーション３３２は、パブリックインターフェース３２０を使用して、ハイブリッド資源マネージャー３０２にアクティビティを作成し、そのアクティビティを実行するのに必要とされるさまざまな資源のセットを記述する１つ又は複数の設定を構築する。アクティビティは、システムで実行されているタスクに関連付けられるデータ構造である。ハイブリッド資源マネージャー３０２は、限られた資源のプールからどのアクティビティを完全に満たすことができるのかを決定し、満たすことができるアクティビティを有するアプリケーションが、要求された資源にアクセスすることを可能にする。

図４は、既存のアプリケーションとの後方互換性をサポートする目的で複数のパブリックインターフェースが設けられる図３に示すハイブリッド資源マネージャー３０２の１つの特定の例を示す。ハイブリッド資源マネージャー３０２には、適切なＡＰＩ標準規格に準拠した一連のインターフェースを備えるパブリックインターフェース（例えば、図３のパブリックインターフェース３２０）を通じてアクセスされる。この例では、例えば、それぞれバイオメトリックリーダー用及びスマートカードリーダー用の標準的なＡＰＩ４０４及び４０６が示されている。機能インターフェース４０２も示されている。機能インターフェース４０２は、信頼される第三者から入手可能な場合がある他の任意のハードウェアデバイス機能（例えば、フラッシュストレージ）を表す。これらのインターフェースは、ハードウェアデバイスに直接アクセスしない。これらのインターフェース４０２、４０４、及び４０６は、資源マネージャーにアクセスするのに現在用いられているものと同じであるので、後方互換性が維持されている。パブリックインターフェース３２０を通じて開放されるコンテキストは、ポリシーモジュールが確立できるポリシーのために、すべての基礎と成るシステムハードウェアに完全にアクセスできない場合がある。これについては、以下でより詳細に論述する。いくつかの場合に、ハイブリッド資源マネージャー３０２は、ハードウェアデバイス及び対応するコンテキストによってサポートされるすべてのデバイスクラスＩＤのリストを保持するコンテキスト構造を有する。

パブリックインターフェースは、ハイブリッド資源マネージャー３０２の高度化された機能の実施を容易にするのに使用される汎用ハイブリッド資源マネージャーインターフェース４０８も含む。すなわち、汎用ハイブリッド資源マネージャーインターフェース４０８は、ＡＰＩとして実施することもでき、ハイブリッド資源マネージャー３０２の特徴を活用することができるアプリケーションによって使用される。汎用ハイブリッド資源マネージャーインターフェース４０８は、ハードウェアデバイスによって提供される異なる機能の個数及びタイプを識別する、ハイブリッドデバイス内のデバイスのためのハイブリッドデバイス列挙（enumeration）；検証及び認証の目的のためのコンピューティングシステム及びハードウェアデバイスによって使用されるデバイス獲得；並びに多機能ハードウェアデバイスが獲得された後に、アプリケーション（例えば、アプリケーション３３２）が特定のオペレーションについて多機能ハードウェアデバイスに対する適切且つおそらく排他的なアクセスを与えられることを確保するデバイスロック、のような機能を提供する。

汎用ハイブリッド資源マネージャーインターフェース４０８は、異なるデバイス資源マネージャー間の通信を可能にすることを助け、したがって、（デバイスドライバー（例えば、デバイスドライバー３０４）を介した）デバイス間の通信を可能にすることを助ける。汎用ハイブリッド資源マネージャーインターフェース４０８は、制限されたビュー（view）でコンテキストを開放することも可能にし、これは、コンテキストが、開放された場合に、実際のパブリックＡＰＩを通じて利用可能な機能のサブセットとなり得ることを意味する。

ハイブリッド資源マネージャー３０２は、インターフェースを通じてアクセスされる専用資源マネージャーも含む。図３に示す例では、機能マネージャー４１２、バイオメトリックマネージャー４１４、及びスマートカード資源マネージャー４１６が、それぞれ、機能インターフェース４０２、バイオメトリックインターフェース４０４、及びスマートカードインターフェース４０６を通じてアクセスされる。これらのインターフェースのそれぞれは、拡張可能であるが、後述するポリシーモジュールによって確立されたセキュリティ手順に従って完全性が検証される。専用資源マネージャー４１２、４１４、及び４１６は、後方互換性を可能にし、現在の資源マネージャーと同じ機能ではあるが、コンテキスト割り当て、外部資源ロック、及びハードウェア管理等の一定の重要な領域では改良（変更、retrofit）された機能を主として提供する。

コアハイブリッド資源マネージャー４１８は、異なる資源マネージャー間のアクセスの管理を担当し、したがって、多機能ハードウェアデバイスによって使用されるデバイス間及びハイブリッド資源マネージャーキテクチャを使用できるアプリケーション間のアクセスの管理を担当する。専用資源マネージャー４１２、４１４、及び４１６のそれぞれは、コアハイブリッド資源マネージャー４１８へのそれらのそれぞれの接続を担当する。追加の機能の制作を容易にし、開発され得る新しいタイプのハイブリッドハードウェアデバイスを扱うために、コアハイブリッド資源マネージャー４１８は拡張可能にされる。コアハイブリッド資源マネージャー４１８は、デバイスドライバーによって提供される資源（ローカル又はリモート）へのアクセスを調停（仲裁）する。図３のアプリケーション３３２等の資源コンシューマは、ドライバーによって提供される１つ又は複数の資源のセットを要求し、コアハイブリッド資源マネージャー４１８は、どのアプリケーションがデバイスドライバーのどの資源を使用するようになるのかを判断する。コアハイブリッド資源マネージャー４１８は、所定の衝突解決メカニズムに基づいて資源割り当て判定を行うことができる。

コアハイブリッド資源マネージャー４１８は、ポリシーモジュール４２０によって確立されたセキュリティ及び他のポリシーを施行する。ポリシーモジュール４２０は、デバイスレベル又はシステムレベルから確立されることになるポリシー（例えば、グループマシンポリシー又はローカルマシンポリシー）を受信することができる。実施できるポリシーの一例は次の通りである。例えば、スマートカードリーダー及びバイオメトリックスキャナーを含む多機能デバイスの場合、統合されたバイオメトリックスキャナーを有するスマートカードリーダーの排他的使用を必要とするポリシーを確立することができる。ユーザが、専用のスマートカードリーダー及び物理的に分離したバイオメトリックスキャナーの使用を試みる場合、ポリシーモジュール４２０は、これら２つのデバイスが獲得されることを防止する。もちろん、ポリシーモジュール４２０は、ハイブリッドハードウェアデバイスが、衝突等なしに適切に動作することを確保する他の多くのポリシーを確立することができる。例えば、衝突解決に関して、ハイブリッド資源マネージャー３０２が、優先度ベースの解決法を用いている場合、すべてのタスクにその資源を割り当てることができるとは限らないような衝突がある時は、ポリシーモジュール４２０は、コアハイブリッド資源マネージャー３０２がどのタスクが資源にアクセスすべきかを判断できるように、ユーザ又はシステムに基づくそれらの相対的な重要性に従ってアプリオリにタスクをランク付けする。他の実行可能なポリシーには、ファーストリザベーションウィン（first reservations win）、最近時リザベーションウィン（most recent reservations win）、資源の「公平（fair）」共有、何が何に勝つかについてのユーザ選択（user picks what wins over what）等が含まれる。多くの異なるポリシーが可能である。システム又はユーザは、ポリシーを設定し、ポリシーマネージャーモジュールは、それらポリシーを絶対的な優先度に変換する。

ハイブリッド資源マネージャー３０２は、図３に示すそれら追加のモジュール等、さまざまな他のモジュールを含むことができる。例えば、異なるアプリケーションがハイブリッドハードウェアデバイスへのアクセスを試みるごとに別々の認証プロセスを実行する必要がないように、ハードウェアデバイスの認証を集中化させる目的で認証モジュール４２４を設けることができる。この認証モジュールは、（コンテキストコールの結果として）アプリケーションのために起動することもできるし、デバイスマネージャーモジュール４２２がハイブリッドハードウェアデバイスのために起動することもできる。加えて、デバイスマネージャーモジュール４２２は、ハイブリッドハードウェアデバイスを監視して管理する。デバイスマネージャーモジュール４２２は、ハイブリッドハードウェアデバイス及び機能のレベルで資源をロックダウンすることもできる。

ハンドラー４３０、４３２、及び４３４等のデバイス機能ハンドラーは、入出力制御コードを使用して、ハイブリッド資源マネージャー３０２とハイブリッドハードウェアデバイスとの間の詳細な通信プロトコルを管理する。認証ユーザインターフェース又はユーザ経験モジュールを設けて、必要とされ得るさまざまなレベルのユーザ認証を統合し、一貫したインターフェースをユーザに提供することもできる。このような認証は、例えば、ユーザレベル、システムレベル、及び／又はハードウェアデバイスレベルで提供することができる。

図５は、コンピューティングシステムによって使用されるハードウェア資源の管理を容易にする方法の一例を示すフローチャートである。この方法は、ステップ５１０において、汎用ハイブリッド資源マネージャーインターフェースが、多機能ハードウェア資源によって実行される任意の個別の機能にアクセスするための資源獲得要求を受け付けた時に開始する。判定ステップ５２０において、資源獲得要求が、多機能ハードウェア資源によって提供される機能について確立されたポリシーに準拠するか否かの判断が行われる。準拠しない場合、アクセスは、ステップ５３０において拒否される。資源獲得要求がポリシーに準拠する場合、ステップ５４０において、ハイブリッド資源マネージャーは、多機能ハードウェア資源に関連付けられ且つ要求された個別の機能に専用のデバイスドライバーと通信する。デバイスドライバーとの通信に応答して、ステップ５５０において、ハイブリッド資源マネージャーは、資源獲得要求に従って多機能ハードウェアデバイスへのアクセスを可能にする目的で多機能ハードウェアデバイスを獲得する。

主題は、構造的な特徴及び／又は方法論的な動作に特有の文言で説明されているが、添付の特許請求の範囲で規定される主題は、必ずしも、上述した特定の特徴にも動作にも限定されないことが理解されるべきである。それどころか、上述した特定の特徴及び動作は、特許請求の範囲を実施する例示の形態として開示されている。

Claims (20)

1. コンピューティングシステムによって使用されるハードウェア資源の管理を容易にする方法であって、
   多機能ハードウェア資源によって実行される任意の個別の機能にアクセスするための資源獲得要求を受け付けるステップと、
   前記多機能ハードウェア資源に関連付けられ且つ前記要求された個別の機能に専用に設けられたデバイスドライバーと通信するステップと、
   前記デバイスドライバーとの通信に応答して、前記資源獲得要求に従い前記多機能ハードウェアデバイスへのアクセスを可能にする目的で前記多機能ハードウェアデバイスを獲得するステップと
   を含む方法。
2. 前記資源獲得要求が、前記多機能ハードウェア資源によって提供される機能について確立されるポリシーに準拠するか否かを判断するステップをさらに含む、請求項１に記載の方法。
3. 前記多機能ハードウェアデバイスによって実行される第１の機能を要求する第１の資源コンシューマと前記多機能ハードウェアデバイスによって実行される第２の機能を要求する第２の資源コンシューマとの間にポリシーの衝突が生じる場合には、前記多機能ハードウェアデバイスの獲得を拒否するステップをさらに含む、請求項２に記載の方法。
4. 前記資源獲得要求は、多機能ＡＰＩを通じて資源コンシューマから受け付けられる、請求項１に記載の方法。
5. 前記資源獲得要求は、アプリケーションレベル資源コンシューマから受信される、請求項１に記載の方法。
6. コンピューティングデバイスによって使用されるハードウェア資源を管理するシステムであって、
   多機能ハードウェアデバイスによって実行される各機能について資源コンシューマからコンシューマ機能コールを受け付ける多機能インターフェースと、
   前記多機能ハードウェアデバイスによって実行される前記機能のそれぞれに専用の異なるデバイスドライバーを管理することによって、前記コンシューマ機能コールに応答して、前記多機能ハードウェアデバイスの異なる機能資源を割り当てるハイブリッド資源マネージャーと、
   前記コンシューマ機能コールに従い前記多機能ハードウェアデバイスへのアクセスを許可する目的で、前記ハイブリッド資源マネージャーによって実施されて前記多機能ハードウェアデバイスの獲得を可能にする少なくとも１つの所定のポリシーを確立するポリシーモジュールと
   を備えるシステム。
7. 前記多機能デバイスによって実行される１つの特定の機能について、選択された資源コンシューマからの要求を受け付ける少なくとも１つの専用インターフェースであって、前記選択された資源コンシューマは、そのコンシューマ機能コールが前記多機能インターフェースによって受け付けられない資源コンシューマである、少なくとも１つの専用インターフェースと、
   前記特定の機能に専用のデバイスドライバーを管理することによって前記特定の機能に対する資源を割り当てる少なくとも１つの専用資源マネージャーと
   をさらに備える請求項６に記載のシステム。
8. 前記専用インターフェースは、前記多機能ハイブリッドデバイスによって実行される前記特定の機能に関連付けられるＡＰＩ標準規格に準拠する、請求項７に記載のシステム。
9. 前記多機能インターフェースは、（ｉ）前記多機能ハードウェアデバイスによって実行される前記機能のデバイス列挙と、（ｉｉ）認証及び検証の目的のためのデバイス獲得と、（ｉｉｉ）前記多機能ハードウェアデバイスの獲得後の該多機能ハードウェアデバイスのロックとを容易にするように構成される、請求項６に記載のシステム。
10. 前記ポリシーモジュールは、資源割り当てを実施するための所定の衝突解決ポリシーを確立するように構成される、請求項６に記載のシステム。
11. 前記所定の衝突解決ポリシーは、優先度ベースの衝突解決モジュールを含む、請求項１０に記載のシステム。
12. 前記多機能ハードウェアデバイス及び割り当てられる前記機能資源から独立した前記コンシューマ資源の認証を集中化させる認証モジュールをさらに備える、請求項６に記載のシステム。
13. 前記多機能ハードウェアデバイスのためにコンテンツコールを受け付けて前記認証モジュールを起動するデバイスマネージャーモジュールをさらに備える、請求項１２に記載のシステム。
14. 前記ハイブリッド資源マネージャーは、オペレーティングシステム内のシステムレベルに存在する、請求項６に記載のシステム。
15. 前記認証モジュールは、割り当てられる前記機能資源から独立した共通の認証ユーザインターフェースを提示するように構成される、請求項１２に記載のシステム。
16. 前記ハイブリッド資源マネージャーと前記デバイスドライバーとの間で通信プロトコルを実施する複数のデバイスハンドラーをさらに備え、前記デバイスハンドラーのそれぞれは、前記多機能ハードウェアデバイスの異なる機能資源に専用である、請求項６に記載のシステム。
17. 前記コンピューティングデバイスは、パーソナルコンピューター、ゲームコンソール、携帯電話、ＰＤＡ、及びセットトップボックス（ＳＴＢ）から成る群から選択される電子デバイスである、請求項６に記載のシステム。
18. コンピューター可読記憶媒体であって、電子デバイスに配置される１つ又は複数のプロセッサによって実行されると、
    多機能ハードウェア資源によって実行される任意の個別の機能にアクセスするための資源獲得要求を受け付けるステップと、
    前記多機能ハードウェア資源に関連付けられ且つ前記要求された個別の機能に専用のデバイスドライバーと通信するステップと、
    前記デバイスドライバーとの通信に応答して、前記資源獲得要求に従い前記多機能ハードウェアデバイスへのアクセスを可能にする目的で前記多機能ハードウェアデバイスを獲得するステップと
    を含む方法を実行する資源マネージャーを有するオペレーティングシステムを実施する命令を含む、コンピューター可読記憶媒体。
19. 前記資源獲得要求が、前記多機能ハードウェア資源によって提供される機能について確立されるポリシーに準拠するか否かを判断するステップをさらに含む、請求項１８に記載のコンピューター可読媒体。
20. 前記多機能ハードウェアデバイスによって実行される第１の機能を要求する第１の資源コンシューマと前記多機能ハードウェアデバイスによって実行される第２の機能を要求する第２の資源コンシューマとの間にポリシーの衝突が生じる場合には、前記多機能ハードウェアデバイスの獲得を拒否するステップをさらに含む、請求項１９に記載のコンピューター可読媒体。

Images