(57)【要約】【課題】デバイス上の共有リソースの動的調停用システム【解決手段】デバイス上の共有リソースの動的調停のためのシステム。デバイス上のデバイスリソースの割り当てを調停するための方法が提供されている。該方法は、該デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信することと、該デバイスリソースは所有アプリケーションによって所有されていると判断することとを備えている。該方法はまた、所有者情報をリクエスト者情報に関連付けて、調停リクエストを形成することを備え、該所有者情報は該所有アプリケーションに関する情報を備え、該リクエスト者情報は該リクエストアプリケーションに関する情報を備えている。該方法はまた、該調停リクエストを調停して、該デバイスリソースが該リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成することと、該調停決定に基づいて該デバイスリソースを割り当てることとを備えている。【選択図】      図３
2008500648.tif 000002
【特許請求の範囲】
【請求項１】
デバイス上のデバイスリソースの割り当てを調停するための方法であって、
前記デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信することと、
前記デバイスリソースは所有アプリケーションによって所有されていると判断することと、
所有者情報をリクエスト者情報に関連付けて調停リクエストを形成することであって、前記所有者情報は前記所有アプリケーションに関する情報を備え、前記リクエスト者情報は前記リクエストアプリケーションに関する情報を備えることと、
前記調停リクエストを調停して、前記デバイスリソースが前記リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成することと、
前記調停決定に基づいて前記デバイスリソースを割り当てることと、
を備える、方法。
【請求項２】
前記調停ステップはリソースアービタによって実行され、前記方法は、前記リソースアービタを前記デバイスにダウンロードすることを備える、請求項１に記載の方法。
【請求項３】
前記所有者情報は前記所有アプリケーションの特権ステータスを備え、前記調停ステップは、前記所有アプリケーションの前記特権ステータスに基づいて前記調停決定を判断することを備える、請求項１に記載の方法。
【請求項４】
前記所有者情報は放棄リストを備え、前記調停ステップは、前記放棄リストに基づいて前記調停決定を判断することを備える、請求項１に記載の方法。
【請求項５】
前記リクエスト者情報はリクエスト者識別子を備え、前記調停ステップは、前記調停決定を判断することを備え、前記リクエスト者識別子が前記放棄リストに含まれていれば前記リクエストアプリケーションは前記デバイスリソースを割り当てられる、請求項４に記載の方法。
【請求項６】
前記調停ステップは、前記所有者情報、前記リクエスト者情報、デバイスステータス情報、デバイス動作モード情報、ユーザの好み情報、および第三者の好み情報を備える１セットの情報アイテムから選択される任意の情報に基づいて前記調停決定を判断することを備える、請求項１に記載の方法。
【請求項７】
前記デバイスは無線デバイスである、請求項１に記載の方法。
【請求項８】
デバイス上のデバイスリソースの割り当てを動的に調停するための装置であって、この装置は、
前記デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信する論理と、
前記デバイスリソースは所有アプリケーションによって所有されていると判断する論理と、
所有者情報をリクエスト者情報に関連付けて調停リクエストを形成する論理であって、前記所有者情報は前記所有アプリケーションに関する情報を備え、前記リクエスト者情報は前記リクエストアプリケーションに関する情報を備える論理とを備える、リソースマネージャと、
前記調停リクエストを調停して、前記デバイスリソースが前記リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成するように動作するリソースアービタと、
を備える、装置。
【請求項９】
前記リソースアービタは、前記デバイスにダウンロードされるソフトウェアモジュールを備える、請求項８に記載の装置。
【請求項１０】
前記所有者情報は前記所有アプリケーションの特権ステータスを備え、前記リソースアービタは、前記所有アプリケーションの前記特権ステータスに基づいて前記調停決定を判断するように動作する、請求項８に記載の装置。
【請求項１１】
前記所有者情報は放棄リストを備え、前記リソースアービタは前記放棄リストに基づいて前記調停決定を判断するように動作する、請求項８に記載の装置。
【請求項１２】
前記リクエスト者情報はリクエスト者識別子を備え、前記リソースアービタは前記調停決定を判断するように動作して、前記リクエスト者識別子が前記放棄リストに含まれていれば前記リクエストアプリケーションは前記デバイスリソースを割り当てられる、請求項１１に記載の装置。
【請求項１３】
前記リソースアービタは、前記所有者情報と、前記リクエスト者情報と、デバイスステータス情報と、デバイス動作モード情報と、ユーザの好み情報と、第三者の好み情報とを備える１セットの情報アイテムから選択される任意の情報に基づいて、前記調停決定を判断するように動作する、請求項８に記載の装置。
【請求項１４】
前記デバイスは無線デバイスである、請求項８に記載の装置。
【請求項１５】
前記デバイス上のデバイスリソースの割り当てを調停するための装置であって、
前記デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信する手段と、
前記デバイスリソースは所有アプリケーションによって所有されていると判断する手段と、
所有者情報をリクエスト者情報に関連付けて調停リクエストを形成する手段であって、前記所有者情報は前記所有アプリケーションに関する情報を備え、前記リクエスト者情報は前記リクエストアプリケーションに関する情報を備える手段と、
前記調停リクエストを調停して、前記デバイスリソースが前記リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成する手段と、
前記調停決定に基づいて前記デバイスリソースを割り当てる手段と、
を備える、装置。
【請求項１６】
前記調停手段はリソースアービタによって実行され、前記装置は、前記リソースアービタを前記デバイスにダウンロードする手段を備える、請求項１５に記載の装置。
【請求項１７】
前記所有者情報は前記所有アプリケーションの特権ステータスを備え、前記調停手段は、前記所有アプリケーションの前記特権ステータスに基づいて前記調停決定を判断する手段を備える、請求項１５に記載の装置。
【請求項１８】
前記所有者情報は放棄リストを備え、前記調停手段は、前記放棄リストに基づいて前記調停決定を判断する手段を備える、請求項１５に記載の装置。
【請求項１９】
前記リクエスト者情報はリクエスト者識別子を備え、前記調停手段は前記調停決定を判断する手段を備え、前記リクエスト者識別子が前記放棄リストに含まれていれば前記リクエストアプリケーションは前記デバイスリソースを割り当てられる、請求項１８に記載の装置。
【請求項２０】
前記調停手段は、前記所有者情報と、前記リクエスト者情報と、デバイスステータス情報と、デバイス動作モード情報と、ユーザの好み情報と、第三者の好み情報とを備える１セットの情報アイテムから選択される任意の情報に基づいて、前記調停決定を判断する手段を備える、請求項１５に記載の装置。
【請求項２１】
前記デバイスは無線デバイスである、請求項１５に記載の装置。
【請求項２２】
デバイスのプロセッサによって実行される場合に、デバイスのデバイスリソースの割り当てを動的に調停するように動作する命令を備える、コンピュータ読み取り可能な媒体であって、
前記デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信する命令と、
前記デバイスリソースは所有アプリケーションによって所有されていると判断する命令と、
所有者情報をリクエスト者情報に関連付けて調停リクエストを形成する命令であって、前記所有者情報は前記所有アプリケーションに関する情報を備え、前記リクエスト者情報は前記リクエストアプリケーションに関する情報を備える命令と、
前記調停リクエストを調停して、前記デバイスリソースが前記リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成する命令と、
前記調停決定に基づいて前記デバイスリソースを割り当てる命令と、
を備える、コンピュータ読み取り可能な媒体。
【請求項２３】
前記調停命令はリソースアービタによって実行され、前記方法は、前記リソースアービタをデバイスにダウンロードする命令を備える、請求項２２に記載のコンピュータ読み取り可能な媒体。
【請求項２４】
前記所有者情報は前記所有アプリケーションの特権ステータスを備え、前記調停命令は、前記所有アプリケーションの前記特権ステータスに基づいて前記調停決定を判断する命令を備える、請求項２２に記載のコンピュータ読み取り可能な媒体。
【請求項２５】
前記所有者情報は放棄リストを備え、前記調停命令は、前記放棄リストに基づいて前記調停決定を判断する命令を備える、請求項２２に記載のコンピュータ読み取り可能な媒体。
【請求項２６】
前記リクエスト者情報はリクエスト者識別子を備え、前記調停命令は、前記調停決定を判断する命令を備え、前記リクエスト者識別子が前記放棄リストに含まれていれば前記リクエストアプリケーションは前記デバイスリソースを割り当てられる、請求項２５に記載のコンピュータ読み取り可能な媒体。
【請求項２７】
前記調停命令は、前記所有者情報と、前記リクエスト者情報と、デバイスステータス情報と、デバイス動作モード情報と、ユーザの好み情報と、第三者の好み情報とを備える１セットの情報アイテムから選択される任意の情報に基づいて、前記調停決定を判断する命令を備える、請求項２２に記載のコンピュータ読み取り可能な媒体。
【請求項２８】
前記デバイスは無線デバイスである、請求項２２に記載のコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概してデバイスの動作に関し、より具体的にはデバイス上の共有リソースの動的調停用システムに関する。
【背景技術】
【０００２】
技術の進歩は広範なデータネットワークの開発および展開をもたらした。これらのネットワークは、インターネットなどの公共のデータネットワークと、無線通信ネットワークなどの特殊ネットワークの両方を含む。これらのネットワークのユーザは、使用可能な広範な情報およびサービスにアクセス可能である。例えば、無線デバイスの所有者は、これらのデバイス上で実行するために様々なアプリケーションをダウンロードしてもよい。
【０００３】
技術的な他の利点は、より小型かつより強力なパソコンデバイスをもたらした。例えば、小型、軽量かつユーザによって容易に携帯可能な多様な携帯無線電話、携帯情報端末（ＰＤＡ）およびページングデバイスが現存している。通常、これらのデバイスは厳格にリソース制限されている。例えば、スクリーンサイズ、使用可能なメモリおよびファイルシステムスペースの量、入力および出力性能と処理性能の量は、各々デバイスの小型さによって制限されることがある。
【０００４】
厳格にリソース制限されたパソコンデバイスを含む多様なコンピュータデバイス上へのダウンロード可能なアプリケーションの増加の結果として、リソース割り当てがますます重要になってきた。デバイスリソースは、ディスプレイ、キーパッド、サウンドプロセッサ、モデム、記憶デバイス、通信チャネルおよび他のタイプのデバイスリソースを含む。とりわけ厳格にリソース制限されたデバイスの各デバイスは限られた数のリソースを有しているため、デバイスリソースの競合アプリケーションへの割り当てはデバイスが動作する様子を判断する。例えば、無線電話は音声コール、データコール、アプリケーションの実行、ＳＭＳメッセージの取扱いなどであってもよい。これらの種々の状態を考えると、これらの種々の状態時にいずれのアプリケーションがデバイス上のデバイスリソースをコントロールするかを判断するための動的、簡単かつ効率的な機構は現存しない。例えば音楽プログラムが演奏中に電話が着信すると、リンガー／音声アプリケーションはサウンドリソースを採るべきである。これと同時に、カレンダーアラームやＳＭＳ通知もまたサウンドリソースにアクセスすべきであろうか？従って、いずれのアプリケーションが特定のデータリソースにアクセスするかを判断するために、デバイス上で実行する競合アプリケーションを効率的に調停する必要性がある。
【０００５】
現在のシステムでは、リソース調停は通常、単純な先着順（Ｆｉｒｓｔ−ｃｏｍｅ−ｆｉｒｓｔ−ｓｅｒｖｅ）プロセスを使用するか、１セットの厳格な優先順位に基づいた決定によって実行される。いずれの場合も、調停アルゴリズムはハードコード化されており、現在のデバイスが動作する動的環境を考慮していない。加えて、ネットワーク通信事業者、デバイス製造業者およびアプリケーション開発者は、デバイスリソースがデバイス上に割り当てられる様子に関して何らかの動的コントロールをするであろう。残念ながら、静的調停技術を使用する現在の調停システムは、このニーズを満たすことができない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、デバイス上のデバイスリソースがデバイス上で実行する競合アプリケーションに動的に割り当てられるようにする、動的調停システムが必要とされる。このシステムはまた、ネットワーク通信事業者などの第三者が、デバイス上のデバイスリソースが割り当てられる様子に関して入力できるようにする機構を提供すべきである。
【課題を解決するための手段】
【０００７】
１つ以上の実施形態では、デバイス上のデバイスリソースが動的に割り当てられるようにする方法および装置を備える、動的調停システムが提供される。一実施形態では、デバイス上のデバイスリソースの割り当てを調停するための方法が提供される。該方法は、該デバイスリソースの割り当てをリクエストするリクエストアプリケーションからのリクエストを受信することと、該デバイスリソースが所有アプリケーションによって所有されていることを判断することとを備える。該方法はまた、所有者情報をリクエスト者情報に関連付けて調停リクエストを形成することを備え、該所有者情報は該所有アプリケーションに関する情報を備え、該リクエスト者情報は該リクエストアプリケーションに関する情報を備えている。該方法はまた、該調停リクエストを調停して、該デバイスリソースが該リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成することと、該調停決定に基づいて該デバイスリソースを割り当てることとを備える。
【０００８】
一実施形態では、デバイス上のデバイスリソースの割り当てを動的に調停するための装置が提供される。該装置は、該デバイスリソースの割り当てをリクエストするリクエストアプリケーションからのリクエストを受信する論理と、該デバイスリソースが所有アプリケーションによって所有されていると判断する論理と、所有者情報をリクエスト者情報に関連付けて調停リクエストを形成する論理とを備えるリソースマネージャを備え、該所有者情報は該所有アプリケーションに関する情報を備え、該リクエスト者情報は該リクエストアプリケーションに関する情報を備えている。該装置はまた、該調停リクエストを調停して、該デバイスリソースが該リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成するように動作する、リソースアービタを備える。
【０００９】
一実施形態では、デバイス上のデバイスリソースの割り当てを調停するための装置が提供される。該装置は、該デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信する手段と、該デバイスリソースが所有アプリケーションによって所有されていると判断する手段とを備える。該装置はまた、所有者情報をリクエスト者情報に関連付けて調停リクエストを形成する手段を備え、該所有者情報は該所有アプリケーションに関する情報を備え、該リクエスト者情報は該リクエストアプリケーションに関する情報を備えている。該装置はまた、該調停リクエストを調停して、該デバイスリソースが該リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成する手段と、該調停決定に基づいて該デバイスリソースを割り当てる手段とを備える。
【００１０】
一実施形態では、デバイスのプロセッサによって実行される場合に、該デバイスのデバイスリソースの割り当てを動的に調停するように動作する命令を備える、コンピュータ読み取り可能な媒体が提供される。該コンピュータ読み取り可能な媒体は、該デバイスリソースの割り当てをリクエストするリクエストアプリケーションからリクエストを受信する命令と、該デバイスリソースが所有アプリケーションによって所有されていると判断する命令とを備える。該コンピュータ読み取り可能な媒体はまた、所有者情報をリクエスト者情報に関連付けて調停リクエストを形成する命令を備え、該所有者情報は該所有アプリケーションに関する情報を備え、該リクエスト者情報は該リクエストアプリケーションに関する情報を備えている。該コンピュータ読み取り可能な媒体はまた、該調停リクエストを調停して、該デバイスリソースが該リクエストアプリケーションに割り当てられるか否かを示す調停決定を生成する命令と、該調停決定に基づいて該デバイスリソースを割り当てる命令とを備えている。
【００１１】
本発明の他の態様、利点および特徴は、以下になされる図面の簡単な説明、発明を実施するための最良の形態および特許請求の範囲を閲覧した後に明らかになる。
【００１２】
ここに説明されている実施形態の上記態様および付随する利点は、添付の図面と関連してなされた以下の詳細な説明を参照することによって、より容易に明らかになるであろう。
【発明を実施するための最良の形態】
【００１３】
以下の詳細な説明は、デバイスのデバイスリソースを動的に割り当てるように動作する動的割り当てシステムの１つ以上の実施形態について説明している。一実施形態では、アプリケーションは、割り当てリクエストをリソースマネージャに送信することによって、デバイスリソースの割り当てをリクエストする。一実施形態では、割り当てリクエストは、リクエストアプリケーションについて説明するリクエスト者情報を備えている。デバイスリソースがアプリケーション（所有者アプリケーション）によって現在所有されていれば、リクエスト者情報は所有者情報と結合されて、調停リクエストを形成する。一実施形態では、所有者情報はデバイスリソースの所有者アプリケーションおよびステータスについて説明する。リソースアービタは調停ルールに従って調停リクエストを処理して、デバイスリソースが割り当てられる様子を示す調停決定を生成する。そして調停決定はデバイスリソースを割り当てるために使用される。システムは、デスクトップコンピュータ、ノートブックコンピュータ、無線電話、ポケットベル、ＰＤＡ、電子メールデバイス、タブレットコンピュータ、あるいは他のタイプの有線または無線デバイスを含むが、これらに制限されない任意のタイプの有線または無線デバイスと併用するのに適している。
【００１４】
１つ以上の実施形態では、割り当てシステムは、例えばデバイス固有のリソースの汎用コールを提供するなど、デバイスの動作を簡略化するために使用される、デバイス上で実行するランタイム環境と相互作用する。このようなランタイム環境の１つは、カリフォルニア州サンディエゴのクアルコム社（ＱＵＡＬＣＯＭＭ，Ｉｎｃ．，ｏｆ  Ｓａｎ  Ｄｉｅｇｏ，Ｃａｌｉｆｏｒｎｉａ）によって開発された、Ｗｉｒｅｌｅｓｓ（登録商標）（ＢＲＥＷ（商標））ソフトウェアプラットフォーム用のバイナリランタイム環境（Ｂｉｎａｒｙ  Ｒｕｎｔｉｍｅ  Ｅｎｖｉｒｏｎｍｅｎｔ）である。以下の説明において、動的割り当てシステムの一実施形態は、ＢＲＥＷソフトウェアプラットフォームなどのランタイム環境を実行する無線デバイスを使用して実施されるとする。しかしながら、動的割り当てシステムの１つ以上の実施形態は、有線および無線デバイス上のデバイスリソースを動的に割り当てるための他のタイプのランタイム環境と併用するのに適している。さらに、用語「デバイスリソース」は、ディスプレイ、サウンドプロセッサ、スピーカー、キーパッド、モデム、ネットワークインタフェース、ファイルシステム、記憶デバイス、あるいはデバイスの一部であってもよい任意の他のタイプのデバイスリソースを含むが、これらに制限されないデバイス上の、任意のタイプのハードウェアまたはソフトウェアリソースについて説明するためにここでは使用される。
【００１５】
図１は、デバイス上のデバイスリソースを割り当てるように動作する動的割り当てシステム１００の一実施形態を示している。システム１００はデバイス１０２を備え、ここでは、無線通信チャネル１０６を介してデータネットワーク１０４と通信する無線端末である。データネットワーク１０４は、有線、無線、プライベートまたはパブリックデータネットワークあるいはこれらの任意の組み合わせを含むが、これらに制限されない任意のタイプのデータネットワークを備える。
【００１６】
システム１００はまた、データネットワーク１０４と通信しているデバイスにサービスを提供するために、通信チャネル１２０を介してデータネットワーク１０４に接続されているサーバ１０８を備えている。例えば、デバイス１０２は無線電話であってもよく、またサーバ１０８は、電気通信サービスを電話に提供する全国的な電気通信ネットワークの一部であってもよい。通信チャネル１２０は任意のタイプの有線または無線通信チャネルであってもよい。
【００１７】
第２のサーバ１１０もまたデータネットワーク１０４と通信している。第２のサーバ１１０はまた無線通信チャネル１２２を介してデータネットワーク１０４と通信している。第２のサーバ１１０は、データネットワーク１０４と通信しているネットワークエンティティにサービスを提供するように動作する、任意のタイプのサーバであってもよい。
【００１８】
一実施形態では、デバイス１０２はリソースアービタ１１２および調停ルール１１４を備える。リソースアービタ１１２は、調停ルール１１４に基づいてデバイス１０２上のデバイスリソースに対するリクエストを調停するように動作する。例えば、デバイス１０２は、デバイスユーザにとって望ましい特徴および機能を提供するためにデバイス１０２上で実行するアプリケーション１１６を含む。例えば、アプリケーション１１６は１２４に示されるように、第２のサーバ１１０からデバイス１０２にダウンロードされてもよい。これらの実行時に、アプリケーション１１６はデバイス１０２上の１つ以上のデバイスリソース１１８のコントロールを試みる。例えば、図１において、デバイスリソース１１８はデバイスディスプレイと、サウンドプロセッサと、モデムとキーパッドとを備えているが、デバイスリソース１１８は上記のような任意の他のデバイスリソースを備えてもよい。リソースアービタ１１２は調停リクエストを受信して、アプリケーション１１６のうちのいずれがデバイスリソース１１８へのアクセスを割り当てられるかを調停するように動作する。リソースアービタ１１２は調停ルール１１４に従って調停リクエストを処理して、アプリケーション１１６へのデバイスリソース１１８の割り当て方法を示す調停決定を生成する。
【００１９】
一実施形態では、リソースアービタ１１２および調停ルール１１４は１２６で示されるように、サーバ１０８からデバイス１０２にダウンロードされる。従って、特定のバージョンのリソースアービタ１１２および／または特定のセットの調停ルール１１４をダウンロードすることによって、サーバ１０８は、デバイスリソース１１８がデバイス１０２に割り当てられる様子を動的にコントロールすることができる。
【００２０】
１つ以上の実施形態では、サーバ１０８、デバイス１０２および第２のサーバ１１０は任意のタイプのコンピュータデバイスであってもよく、データネットワーク１０４へのこれらの関連接続は無線、有線またはこれらの任意の組み合わせであってもよい。従って、動的調停システムの実施形態は、デバイスリソースがデバイス１０２に割り当てられる様子をサーバにコントロールさせるように動作し、これらの実施形態は、様々なサーバおよび端末を有する事実上任意のネットワーク構成を使用して実施されてもよい。
【００２１】
図２は、デバイス、例えば図１に示されるようなデバイス１０２のデバイスリソースを割り当てるための動的調停システム２００の一実施形態の機能図を示している。動的調停システム２００はリソースマネージャ２０２と、リソースステータス２０４と、リソースアービタ２０６と、調停ルール２０８とを備える。デバイスリソース２１０、およびデバイス上で実行し、かつ概して２１２と示されるアプリケーション（１から４）もまた示される。
【００２２】
リソースマネージャ２０２はＣＰＵ、プロセッサ、ゲートアレイ、個別論理、あるいは他のハードウェアまたはソフトウェア、あるいはこれらの任意の組み合わせを備え、デバイスリソース２１０を管理するように動作する。デバイスリソース２１０は上記のように任意のタイプのデバイスリソースを備えてもよい。
【００２３】
リソースステータス２０４はハードウェア、ソフトウェアまたはこれらの任意の組み合わせを備える。一実施形態では、リソースステータス２０４は、デバイスリソース２１０に関する情報および／または現在のリソース所有者に関する情報（所有者情報）を備える。例えば、現在デバイスリソース２０１を割り当てられているアプリケーションは、リソース所有者、現在の所有者または所有アプリケーションとみなされる。例えば、一実施形態では、リソースステータス２０４は、現在の所有者識別子（ＩＤ）、１つ以上のグループＩＤ、特権ステータス、リソースの取得理由、放棄（ｒｅｌｉｎｑｕｉｓｈ）リスト、および／または現在の所有者やデバイスリソース２１０に関する任意の他の情報を備える、現在の所有者に関する情報を備えている。一実施形態では、放棄リストは、現在の所有者がデバイスリソース２１０のリリース先として望んでいるアプリケーションやグループ（つまり特権クラス）を識別する。一実施形態では、このリストは、リソースアービタ２０６によって実行される調停プロセス中にコントロールしている。別の実施形態では、この放棄リストは、調停が決定される様子に関する、リソースアービタ２０６への推奨にすぎないとみなされる。リソースマネージャ２０２は、リソースステータス２０４に含まれる情報を維持、更新、変更、追加、削除あるいは他の方法によって処理するように動作する。
【００２４】
リソースアービタ２０６はハードウェア、ソフトウェアまたはこれらの任意の組み合わせを備え、調停ルール２０８を使用してデバイスリソース２１０へのアクセスを調停するように動作する。例えば、一実施形態では、リソースアービタ２０６はプログラムモジュールであってもよく、また調停ルール２０８は、リソースアービタ２０６によって検索され、かつデバイスリソース２１０を動的に割り当てるように処理される、メモリに記憶されるパラメータであってもよい。１つ以上の実施形態では、リソースマネージャ２０２およびリソースアービタ２０６は、デバイス上で実行するランタイム環境に対するダウンロード可能な拡張子として実施されてもよく、例えばこれらはダウンロード可能なＢＲＥＷ拡張子であってもよい。
【００２５】
動的調停システム２００の一実施形態の動作時に、アプリケーション２１２のうちの１つ以上が、リソースマネージャ２０２からデバイスリソース２１０へのアクセスをリクエストする。デバイスリソース２１０が現在別のアプリケーションによって所有されていれば、リソースマネージャ２０２は、リクエストアプリケーションに関する情報（リクエスト者情報）と、リソースステータス２０４から導かれるデバイスリソース２１０の現在の所有者に関する情報（所有者情報）とを備える調停リクエストをアセンブルすることによって応答する。調停リクエストは２１４に示されるようにリソースアービタ２０６に送られる。リソースアービタ２０６は調停ルール２０８を使用して調停リクエストを処理して、２１６に示されるように、リソースマネージャ２０２に送り返される調停決定を生成する。そしてリソースマネージャは、調停決定に従ってデバイスリソース２１０を割り当てるように動作する。
【００２６】
一実施形態では、アプリケーション２１２は１セットのグループＩＤを有していてもよく、これらのうちの１つは、特定のアプリケーションがデバイスリソース２１０に対して特権的であるか否かを判断する。例えば、グループＩＤは、このグループＩＤを有する全アプリケーションに適用する１セットの権利と関連付けられる。権利のうちの１つは、デバイスリソース２１０に対してアプリケーションの特権ステータスを定義する。アプリケーションがまずデバイスリソース２１０へのアクセスを取得すると、この１セットのグループＩＤと、デバイスリソース２１０へのアクセス所望理由とを含む情報を、リソースマネージャ２０２に（割り当てリクエストを介して）提供する。デバイスリソース２１０へのアクセス所望理由は複数の列挙タイプのうちの１つから選択される。アプリケーションが特権的であれば、このグループＩＤから判断されるように、デバイスリソース２１０を取り除くことが可能なアプリケーションを制限することがある。例えば、アプリケーションは、デバイスリソース２１０の放棄先となるアプリケーションを識別する放棄リストを特定してもよい。例えば、放棄リストのアプリケーションはこれらのグループＩＤによって識別されてもよい。
【００２７】
別のアプリケーションがデバイスリソース２１０へのアクセスをリクエストする場合、リソースマネージャは、現在のリソース所有者に関する情報（所有者情報）と、リクエストアプリケーションに関する情報（リクエスト者情報）とを含む、調停リクエストを生成する。調停リクエストの一部として、特権ステータスまたはリソース所有者およびリクエスト者は、関連するリソース所望理由および任意の放棄リストに沿ってリソースアービタ２０６に譲渡される。リソースアービタ２０６に譲渡された情報はまた、任意の他のパラメータや基準を備えてもよい。例えば、リソースアービタ２０６に譲渡された情報はユーザの好みや、現在のデバイス動作モードや、通信事業者の好みや、リクエストを調停するのに使用可能な任意の他のタイプの情報を含んでもよい。そしてリソースアービタ２０６はこの情報を使用して、デバイスリソース２１０が割り当てられる様子を判断する。
【００２８】
一実施形態では、現在のリソース所有者は、デバイスリソース２１０に対するこの優先順位を動的に変更してもよい。例えば、アプリケーションは特権を提供するグループＩＤを有しており、これによってデバイスリソース２１０を取得する優先順位を高くすることができる。デバイスリソース２１０への初期アクセス後、他のアプリケーションがデバイスリソース２１０の取得を制限される場合、アプリケーションはこの優先順位を変更してもよく、これによって他のアプリケーションはデバイスリソース２１０へのアクセスを取得することができる。例えば、アプリケーションはデバイスリソースを必要とする理由を変更してもよく、あるいはこの放棄リストを変更して、他のアプリケーションがデバイスリソースを取得できるようにしてもよい。従って、動的調停システム２００は、デバイスリソース２１０をリリースするか、他のアプリケーションがより容易にデバイスリソース２１０にアクセスできるようにする柔軟性を、リソース所有アプリケーションに提供するように動作する。
【００２９】
別の実施形態では、動的調停システム２００は、アプリケーションにコールバック機能を登録させるコールバック機構を提供する。コールバック機能は動的調停システム２００に、デバイスリソース２１０のステータスの変化がある場合にアプリケーションに通知させる。例えば、コールバック機能は、デバイスリソース２１０がフリーの場合や、デバイスリソース２１０が別のアプリケーションに割り当てられるために使用中である場合に、任意のアプリケーションに通知するのに使用可能である。
【００３０】
従って、動的調停システム２００は、デバイス１０２上の１つ以上のデバイスリソース２１０へのアクセスを動的に割り当てるように動作する。例えば、一実施形態では、デバイス１０２は、デバイス上のデバイスリソース２１０ごとにリソースマネージャを備えてもよい。リソースアービタ２０６は各リソースマネージャと通信して、各デバイスリソース２１０に関する調停リクエストをそれぞれ処理する。さらに、リソースアービタ２０６はデバイスリソース２１０ごとに同一または異なる調停ルール２０８を使用してもよい。動的動作を提供するために、リソースアービタ２０６および調停ルール２０８はネットワークエンティティからデバイス１０２にダウンロードされてもよく、これによって第三者が、デバイスリソース２１０がデバイス１０２に割り当てられる様子に関して入力することができる。例えば、一実施形態では、デバイス１０２は無線電話であり、リソースアービタ２０６および調停ルール２０８は、全国的な電気通信事業者ネットワークの一部であるネットワークサーバからデバイス１０２にダウンロードされる。このように、電気通信事業者は、デバイスリソース２１０がデバイス１０２に割り当てられる様子に関する入力を提供される。
【００３１】
図３は、動的調停システムの一実施形態を含むデバイス３００の一実施形態を示している。デバイス３００は、すべてが内部データバス３１２に接続されている処理論理３０２と、メモリ３０４と、サウンド論理３０６と、カメラ論理３０８と、Ｉ／Ｏインタフェース３１０とを備えている。明確にするために、サウンド論理３０６およびカメラ論理３０８は、デバイス３００上で実行するアプリケーションに割り当て可能なデバイス３００の唯一のデバイスリソースであるとする。しかしながら、動的調停システムの１つ以上の実施形態は、多少のリソースおよび／または異なる機能的要素を有する他のデバイスとの併用に適している点に留意されたい。
【００３２】
処理論理３０２はＣＰＵ、プロセッサ、ゲートアレイ、個別論理、あるいは他のハードウェアまたはソフトウェア、あるいはこれらの任意の組み合わせを備えている。従って、処理論理３０２は概して、ここに説明されている機能を実行する機械読み取り可能な命令を実行する論理を備えている。例えば、命令は、フロッピー（登録商標）ディスク、ＣＤＲＯＭ、フラッシュメモリ、あるいはインタフェース３１０を介してデバイス３００とインタフェース接続する他のコンピュータ読み取り可能な媒体などのコンピュータ読み取り可能な媒体から、デバイス３００にロードされてもよい。別の実施形態では、命令は、ネットワークサーバや任意の他のタイプのネットワークリソースなどのネットワークリソースから、デバイス３００にインタフェース３１０を介してダウンロードされてもよい。命令は、処理論理３０２によって実行されると、ここに説明されているような動的調停システムの１つ以上の実施形態を提供する。
【００３３】
メモリ３０４は任意のタイプのＲＡＭ、ＲＯＭ、ハードディスク、フロッピーディスク、フラッシュメモリ、あるいは任意の他のタイプのメモリデバイスを備えている。サウンド論理３０６は、スピーカー、アンプ、サウンドプロセッサなどのサウンドデバイスや、任意の他のタイプのサウンドデバイスをコントロールする論理を備えている。カメラ論理３０８は、ＣＣＤカメラなどのカメラデバイスや、任意の他のタイプのカメラデバイスをコントロールする論理を備えている。Ｉ／Ｏインタフェース３１０は、デバイス３００を外部デバイスやシステムとインタフェース接続させるハードウェアおよび／またはソフトウェアあるいはこれらの任意の組み合わせを備えている。例えば、Ｉ／Ｏインタフェース３１０は、ディスクドライバや他のメモリデバイスなどの外部記憶システムにインタフェース接続する論理を備える。インタフェース３１０はまた、ローカルコンピュータシステムなどの外部システムにインタフェース接続する論理を備えている。加えて、インタフェースはまた、遠隔コンピュータおよびサーバとの通信を可能にするデータネットワークとインタフェース接続する論理を備えている。
【００３４】
デバイス３００の一実施形態の動作時に、処理論理３０２によって実行されるプログラム命令はランタイム環境３１４を起動させる。例えば、ランタイム環境はＢＲＥＷランタイム環境３１４であってもよい。一実施形態では、プログラム命令の実行はまたサウンドマネージャ３２０およびカメラマネージャ３１８を起動させる。サウンドマネージャ３２０は、サウンドリソース３０６をコントロールして、デバイス３００で実行するアプリケーションにデバイス３００から出力されるサウンドをコントロールさせるように動作する。カメラマネージャ３１８は、カメラリソース３０８をコントロールして、デバイス３００で実行するアプリケーションに、カメラデバイスから画像および映像を取得させるように動作する。別の実施形態では、サウンドマネージャ３２０および／またはカメラマネージャ３１８はＣＰＵ、プロセッサ、ゲートアレイ、個別論理、あるいは他のハードウェアまたはソフトウェア、あるいはこれらの任意の組み合わせを備えてもよい。
【００３５】
サウンドマネージャ３１８およびカメラマネージャ３２０は、デバイス上で実行するアプリケーション（３２２、３２４、３２６）から、これらがコントロールするデバイスリソースへのアクセスリクエストを受信する。アプリケーション（３２２、３２４、３２６）はデバイス３００での実行に適した任意のタイプのアプリケーションであってもよい。例えば、アプリケーションはマルチメディアアプリケーション、カレンダーアプリケーション、電子メールアプリケーション、あるいはデバイス上で実行されると有用な特徴および／または機能を提供する任意の他のタイプのアプリケーションであってもよい。デバイスリソースの割り当てを容易にするために、サウンドマネージャ３２０およびカメラマネージャ３１８は、それぞれのデバイスリソースごとのステータス情報をメモリ３０４に維持する。例えば、サウンドマネージャ３２０はサウンドステータス情報３２８をメモリ３０４に維持する。サウンドステータス３２８は、サウンドリソース３０６の割り当ておよび使用と関連した種々のパラメータを識別する。同様に、カメラマネージャ３１８はカメラステータス情報３３０をメモリ３０４に維持する。カメラステータス３３０は、カメラリソース３０８の割り当ておよび使用と関連した種々のパラメータを識別する。デバイスステータス３３４はデバイスの現在の動作モードを識別し、例えば、デバイス動作モードはアイドル中、アプリケーションを実行、メッセージを受信、ボイスコールを処理、ゲームをプレイ、あるいは任意の他のタイプのデバイス動作モードであってもよい。
【００３６】
アプリケーション（３２２、３２４、３２６）がデバイス３００上で実行すると、これらは、関連デバイスリソースにアクセスするリクエストをサウンドマネージャ３１８およびカメラマネージャ３２０に呈示する。リクエストは処理されて、サウンドリソース３０６およびカメラリソース３０８の各々を選択されたアプリケーションに割り当てる。デバイスリソースが現在割り当てられていない場合には、このデバイスリソースはリクエストアプリケーションに容易に割り当て可能である。しかしながら、デバイスリソースが現在あるアプリケーションに割り当てられていると、別のアプリケーションからそのデバイスリソースへのアクセスリクエストは、いずれのアプリケーションがデバイスリソースを割り当てられるかを判断するために調停を必要とする。
【００３７】
１つ以上の実施形態では、動的調停システムは、デバイス３００上で実行するアプリケーションのうちの１つへのデバイスリソースの割り当てを調停するように動作する。例えば、アプリケーションは、デバイスリソースに対するリクエストを適切なリソースマネージャに提示する。デバイスリソースが現在別のアプリケーションに割り当てられていれば、リソースマネージャは調停リクエストをリソースアービタ３１６に呈示する。調停リクエストはリクエストアプリケーションに関する情報（リクエスト者情報）と、デバイスリソースの現在の所有者に関する情報（所有者情報）とを含んでいる。例えば、デバイスリソースの現在の所有者に関する情報は対応するリソースステータス情報に維持される。
【００３８】
一実施形態では、リソースアービタ３１６はメモリ３０４に記憶されている調停ルール３３２に従って調停リクエストを処理する。例えば、一実施形態では、調停ルール３３２はネットワークサーバからデバイス３００にダウンロードされて、ネットワークサーバは、リソースリクエストがデバイス３００で調停される様子についての入力を提供することができる。調停プロセスのより詳細な説明が本書の別のセクションで提供される。調停リクエストはリソースアービタ３１６によって処理されて、調停決定を生成し、これは、調停リクエストを呈示したリソースマネージャに返送される。そしてリソースマネージャは調停決定に基づいてデバイスリソースを割り当てる。
【００３９】
デバイス３００に示されている動的調停システムの説明は一実施形態のみを図示しているが、ここに説明されている機能を提供する他の構成も可能であることに留意されたい。例えば、デバイス３００の機能的要素は、説明されている実施形態の範囲内で結合、再配列、変更、追加または削除されることが可能である。
【００４０】
リソースアービタ
１つ以上の実施形態では、デバイスリソースがリクエストアプリケーション（またはオブジェクト）にハンドオーバ可能か否かを判断するために、中央決定メーカーとして動作するリソースアービタ３１６が提供される。一実施形態では、リソースアービタ３１６は製造中にデバイス３００にインストールされる。別の実施形態では、リソースアービタ３１６はネットワークサーバによってカスタマイズ可能であり、所望ならば更新または交換できるダウンロード可能なモジュールとして実施される。例えば、デバイス３００が無線電話である実施において、リソースアービタ３１６はカスタマイズされて、通信ＯＥＭ／ｃａｒｒｉｅｒによって操作されるネットワークサーバから電話にダウンロードされてもよい。好ましくは、単一のリソースアービタ３１６がデバイス３００の全デバイスリソースに対するリクエストを調停するのに使用されるが、説明されている実施形態の範囲内でデバイス３００上の複数のアービタを使用可能である。
【００４１】
一実施形態では、リソースアービタ３１６は多様な情報をリソースマネージャから譲渡され、この情報は調停決定を生成するのに使用される。一実施形態では、リソースアービタ３１６に譲渡された情報は、リクエストアプリケーションに関する情報（リクエスト者情報）と、デバイスリソースの現在の所有者に関する情報（所有者情報）とを備えている。しかしながら、他の実施形態では、さらなるタイプの情報がリソースアービタに譲渡されて、この追加情報はデバイスステータス情報３３４と、ユーザの好み情報と、第三者の好み情報と、調停決定を生成するためにリソースアービタによる使用に適している任意の他のタイプの情報とを備えている。
【００４２】
加えて、一実施形態では、リソースアービタは拡張可能であるため、調停プロセスは、異なる期間中の異なる情報アイテムや動作条件を使用して調停決定を提供するように修正されてもよい。以下は、調停決定を生成するためにリソースアービタ３１６に譲渡されてもよいリクエスト者および所有者情報の簡潔な説明を表しているが、リソースアービタに譲渡されてもよい情報は示されているリストに制限されない。
【００４３】
Ａ．リソース所有者情報
１．所有者クラス識別子（ＣＬＳＩＤ）およびインスタンスポインター
２．リソース取得理由
３．放棄コントロール情報
ａ．放棄識別子リスト
ｂ．リストカウント（−１＝すべて、０＝なし、これ以外はカウント）
Ｂ．リクエスト者情報
１．リクエスト者クラス識別子（ＣＬＳＩＤ）およびインスタンスポインター
２．リソース取得理由
３．放棄コントロール情報
ａ．放棄識別子リスト
ｂ．リストカウント＝（−１＝すべて、０＝なし、これ以外はカウント）
図４は、デバイス３００で使用するために動的調停システムの一実施形態を提供するための方法４００の一実施形態を示している。明確にするために、方法４００の動作は図３に示されているデバイス３００を参照して説明される。例えば、方法４００は、一実施形態で、サウンドリソース３０６がアプリケーション３２２、３２４、３２６に動的に割り当てられる様子を示している。
【００４４】
ブロック４０２では、第１のアプリケーションはリソース割り当てリクエストを、デバイスリソースと関連したリソースマネージャに送る。例えば、アプリケーション３２２はリソース割り当てリクエストをサウンドリソースマネージャ３２０に送って、サウンドリソース３０６の割り当てをリクエストする。割り当てリクエストはアプリケーション３２２に関する情報を含んでおり、例えばリクエストは上記のようなリクエスト者情報を含んでいる。
【００４５】
ブロック４０４では、リソースマネージャはデバイスリソースを第１のアプリケーションに割り当てる。例えば、サウンドリソース３０６は現在使用可能であるため、サウンドリソースマネージャ３２０はサウンドリソース３０６をアプリケーション３２２に割り当てる。加えて、サウンドリソースマネージャ３２０は割り当てリクエストに提供されているリクエスト者情報を使用して、上記のリソース所有者情報を更新する。そしてリソース所有者情報はサウンドステータス３２８に記憶される。
【００４６】
ブロック４０６では、第２のアプリケーションがリソース割り当てリクエストを、デバイスリソースと関連したリソースマネージャに送る。例えば、アプリケーション３２４はリソース割り当てリクエストをサウンドリソースマネージャ３２０に送り、サウンドリソース３０６の割り当てをリクエストする。割り当てリクエストはアプリケーション３２４に関する情報を含んでおり、例えば、割り当てリクエストは上記のようなリクエスト者情報を含んでいる。
【００４７】
ブロック４０８では、リソースマネージャは調停リクエストをリソースアービタ３１６に送る。例えば、サウンドリソースマネージャ３２０は調停リクエストをリソースアービタ３１６に送る。調停リクエストはサウンドステータス３２８からのリソース所有者情報と、割り当てリクエストからのリソースリクエスト者情報とを含んでいる。従って、調停リクエストはリソースアービタ３１６に、サウンドリソース３０６の現在の所有者および現在のリクエスト者に関する情報を提供する。
【００４８】
ブロック４１０では、リソースアービタ３１６は、いずれのアプリケーションがデバイスリソースを割り当てられるかを示す調停決定を生成する。例えば、リソースアービタ３１６は調停決定を生成して、この決定をサウンドリソースマネージャ３２０に送信する。リソースアービタ３１６は、メモリ３０４に記憶されている調停ルール３３２に基づいて調停決定を生成する。一実施形態では、リソースアービタ３１６および調停ルール３３２は、ＯＥＭ／Ｃａｒｒｉｅｒなどの第三者からダウンロードされ、これによって更新が可能になり、デバイスリソースがデバイス３００に割り当てられる様子を決定する機構を第三者に提供する。リソースアービタ３１６が調停決定を生成する様子に関するより詳細な説明が、本書の別のセクションに提供される。
【００４９】
ブロック４１２では、リソースマネージャは調停決定に基づいてデバイスリソースを割り当てる。例えば、サウンドリソースマネージャ３２０はサウンドリソース３０６を、調停決定に基づいて第１のアプリケーション３２２または第２のアプリケーション３２４のいずれかに割り当てる。サウンドリソースマネージャ３２０はまた、任意の新たなリソース所有者情報によってサウンドステータス３２８を更新する。
【００５０】
従って、方法４００は、デバイス３００で使用するための動的調停システムの一実施形態を提供するように動作する。方法４００は一実施形態を図示しているに過ぎず、かつ説明されている実施形態の範囲内で、方法ステップを再配列、変更、結合、追加または削除可能であることに留意されたい。例えば、アプリケーションはリソースマネージャによってコールバック機能を登録することができるため、デバイスリソースのステータスおよび／または使用可能性が所望ならばアプリケーションに提供可能である。従って、追加の補助機能が調停システムによって提供され、かつこれらの補助機能がここに説明されている実施形態の範囲内にあることが可能である。
【００５１】
実施例
以下は、デバイスのデバイスリソースを割り当てるように動作する、動的調停システムの一実施形態の実施例について説明している。管理されるデバイスリソースの例は、オーディオ（デバイスまたはボリューム）デバイスリソースまたはビジュアル（ディスプレイ）デバイスリソースである。一実施形態では、システムは、デバイスリソースアクセスをコントロールするために、ＢＲＥＷアプリケーションを含むアプリケーション（オブジェクト）の一般的手段を提供するリソースマネージャを備える。リソースマネージャはまた、オブジェクトによってデバイスリソースの取得および供給を調整および管理し、またデバイスリソースの状態が変化する場合、登録されているオブジェクトに通知するように動作する。
【００５２】
あるタイプのデバイスリソースは一度に１つのアプリケーションによって使用可能である。例えば、サウンドインタフェースリソースは１個のアプリケーションのみにサウンド出力を使用させる。システムは、いずれのアプリケーションがデバイスリソースのコントロールを許容されるかを判断する調停（つまりリソースアービタ３１６）を提供する。
【００５３】
図５は、動的調停システムの一実施形態を提供するリソースアービタを操作するための方法５００の一実施形態を示している。明確にするために、方法５００の動作は、図３に示されているデバイス３００を参照して説明される。従って、一実施形態では、方法５００は図３に示されているリソースアービタ３１６によって実施される。
【００５４】
ブロック５０２では、調停リクエストがアービタで受信される。例えば、カメラマネージャ３１８は調停リクエストをアービタ３１６に呈示する。調停リクエストは、カメラリソース３０８の現在の所有者に関する情報と、カメラリソース３０８へのアクセスをリクエストするアプリケーションに関する情報とを備えている。
【００５５】
ブロック５０４では、カメラリソース３０８の現在の所有者によって提供された放棄リストにテストが実行されて、いずれのアプリケーションへ、現在の所有者はカメラリソース３０８のコントロールを放棄するかを判断する。放棄リストは、調停リクエストに提供されている現在の所有者情報の一部である。放棄リストが、いずれのアプリケーションもカメラリソース３０８のコントロールを取得可能であると特定すれば、本方法はブロック５１０に進む。放棄リストが、いずれのアプリケーションもカメラリソース３０８のコントロールを取得できないか、あるいは特定のアプリケーションのみが取得可能であると特定すれば、本方法はブロック５０６に進む。
【００５６】
ブロック５０６では、リクエストアプリケーションが放棄リストに識別されているアプリケーションのうちの１つであるか否かを判断するためのテストが実行される。例えば、放棄リストは、選択されたアプリケーションを識別するために使用可能なグループＩＤやアプリケーションＩＤを特定する。リクエストアプリケーションを識別するＩＤが放棄リストにおいて特定されれば、本方法はブロック５１０に進む。リクエストアプリケーションが放棄リストにおいて特定されなければ、本方法はブロック５０８に進む。
【００５７】
ブロック５０８では、カメラリソース３０８の現在の所有者を維持するために調停決定がなされる。現在の所有者は特権的であり、かつリクエストアプリケーションは放棄リストにないため、リクエストアプリケーションによるカメラリソース３０８の割り当てのリクエストは否定される。次いで本方法はブロック５１２に進み、ここでは調停決定がカメラマネージャ３１８に返送される。
【００５８】
ブロック５１０では、リクエストアプリケーションからの調停リクエストが選択された基準に基づいて調停される。例えば、一実施形態では、リクエストは調停ルール３３０に基づいて調停される。事実上、いずれのアプリケーションがカメラリソース３０８を割り当てられるかを判断するには、いずれの基準も使用可能である。例えば、調停は、各アプリケーションがカメラリソース３０８を望む理由、デバイスの動作モード、ユーザの好み、通信事業者の好み、あるいは他の任意の基準に基づいてもよい。調停決定がなされた後、本方法はブロック５１２に進み、ここで調停決定はカメラマネージャ３１８に返送される。
【００５９】
図６は、動的調停システムの１つ以上の実施形態と併用するのに適したリソースコントロールアーキテクチャ６００の一実施形態を示している。管理されているデバイスリソース６０２ごとに、オブジェクトと、アクセスコントロール用のＩＲｅｓｏｕｒｃｅＣｔｌインタフェース６０６と、リソースマネージャ６０８とをコントロールする、リソースインタフェース６０４がある。加えて、リソースアービタ６１０は全デバイスリソース間で共有される。
【００６０】
リソースインタフェース６０４のインスタンスが作成される場合、これはＩＲｅｓｏｕｒｃｅＣｔｌインスタンス６１２を含む。ＩＲｅｓｏｕｒｃｅＣｔｌインスタンス６１２はリソースマネージャ６０８と相互作用して、下部デバイスリソース６０２を取得および除去する。１個のアプリケーションがデバイスリソース６０２をコントロールしていても、別のアプリケーションが既存の調停ルールに基づいて常時同一のデバイスリソース６０２をコントロールすることができる点に留意されたい。
【００６１】
図７は、動的調停システムの１つ以上の実施形態に従って、デバイスリソースが２つのアプリケーション間に割り当てられる様子を説明する割り当て例を図示する、図７００を示している。例えば、図７００は、リソースアービタ７０２と、リソースマネージャ７０４と、アプリケーションＡ７０６と、リソースインスタンスＡ７０８と、アプリケーションＢ７１２とリソースインスタンスＢ７１４とを備える、種々のデバイスエンティティ間の相互作用を示している。
【００６２】
割り当て例の開始において、アプリケーションＡ７０６はリソースリクエスト７１４をリソースインスタンスＡ７０８に発行して、リソースマネージャ７０４によって管理されているデバイスリソースを取得する。リソースリクエストは、７１６によって示されるように、リソースインスタンスＡ７０８からリソースマネージャ７０４に転送される。この時点でデバイスリソースは割り当てられていないと仮定されるため、リソースマネージャ７０４はデバイスリソースをアプリケーションＡ７０６に割り当て、アプリケーションＡ７０８に戻る「ｓｕｃｃｅｓｓ」インジケータを発行し、これは７１８および７２０に示されている。この時点で、デバイスリソースはアプリケーションＡ７０８によって取得されている。加えて、アプリケーションＡ７０６はコールバック機能をリソースインスタンスＡ７０８によって登録して、７２２に示されるように、デバイスリソースについての任意のステータス変化に関する情報を受信する。
【００６３】
後に、アプリケーションＢ７１０はリソースリクエスト７２４をリソースインスタンスＢ７１２に発行して、リソースマネージャ７０４によって管理されているデバイスリソースを取得する。リソースリクエストは、７２６によって示されているように、リソースインスタンスＢ７１２からリソースマネージャ７０４に転送される。アプリケーションＢ７１０からのリクエストによって、７２８に示されているように、リソースマネージャ７０４はリソースアービタ７０２からの調停をリクエストする。リソースアービタ７０２はここに説明されている実施形態に従って調停リクエスト７３０を処理する。リソースアービタ７０２は、７３０、７３２および７３４によって示されるように、デバイスリソースがアプリケーションＢ７１０に首尾よく割り当てられたことを示す調停結果を提供する。従って、この時点で、アプリケーションＢ７１０はデバイスリソースを取得している。アプリケーションＡ７０６はステータス変化通知（７２２）について登録したため、デバイスリソースのステータスは変更されているためアプリケーションＡ７０６はコールバック機能７３６を介して警告される。従って、コールバックに応答して、アプリケーションＡ７０６は、デバイスリソースが別のアプリケーションに割り当てられており、かつ現在は使用中であるという通知を返送する「ステータス取得（ｇｅｔ  ｓｔａｔｕｓ）」コマンド７３８を発行する。
【００６４】
リソースアービタのカスタマイズ
リソースアービタは、デバイスリソースがリクエストオブジェクトにハンドオーバ可能であるか否かを判断する中央決定メーカーである。リソースアービタモジュールはＯＥＭ／Ｃａｒｒｉｅｒによってカスタマイズ可能であり、クラス識別子（ＣＬＳＩＤ）を使用してダウンロード可能なモジュールとして実施可能である。全デバイスリソースについて単一のリソースアービタ（ＩＲｅｓＡｒｂｉｔｅｒ）実施がある。一実施形態では、リソースアービタ方法ＩＲｅｓＡｒｂｉｔｅｒ＿ＣｏｎｆｉｒｍＡｃｑｕｉｒｅは、調停決定を生成するために、上記のようなリソース所有者情報およびリクエスト者情報を譲渡される。
【００６５】
現在の所有者が放棄ＣＬＳＩＤリストを特定していれば、リクエスト者は、特定されているアプリケーションＩＤまたはグループＩＤのリストにおいて識別され、あるいは所有者が（非特権的所有者の場合のように）任意のＩＤを許容する場合には、アービタは、提供されている情報の残りに基づいて所有権を転送することを決定する（最も簡単な実施がリクエストを許諾する）。リクエスト者が放棄ＣＬＳＩＤリストで識別されない場合、アービタはリクエストを拒絶する。以下は、ＢＲＥＷランタイム環境を実行するデバイスでの使用に適したリソースアービタのＣｏｎｆｉｒｍＡｃｑｕｉｒｅ方法のサンプル実施である。
【００６６】
ｉｎｔ  ＯＥＭＲｅｓＡｒｂｉｔｅｒ＿ＣｏｎｆｉｒｍＡｃｑｕｉｒｅ（ＩＲｅｓＡｒｂｉｔｅｒ＊ｐｏ，ＡＥＥＣＬＳＩＤ  ｃｌｓＲｅｑ，ＡＥＥＲｅｓＣｔｌＩｎｆｏ＊ｐＯｗｎｅｒ，ＡＥＥＲｅｓＣｔｌＩｎｆｏ＊ｐＲｅｑｕｅｓｔｅｒ）
｛
ＣＲｅｓＡｒｂｉｔｅｒ＊ｐＭｅ＝（ＣＲｅｓＡｒｂｉｔｅｒ＊）ｐｏ；
ｉｎｔ  ｓｔａｔｕｓ＝ＥＩＴＥＭＢＵＳＹ；
ｉｎｔ  ｉ；
／／
／／所有者がこれを許容するかを調べるための第１のチェッククラスリスト
／／
ｓｗｉｔｃｈ（ｐＯｗｎｅｒ−＞ｎＣｌｓＣｏｕｎｔ）
｛
ｃａｓｅ−１：  ／／リソース取得可能
ｓｔａｔｕｓ＝ＳＵＣＣＥＳＳ；
ｂｒｅａｋ；
ｃａｓｅ  ０：  ／／リソース取得不可能
ｓｔａｔｕｓ＝ＥＩＴＥＭＢＵＳＹ；
ｂｒｅａｋ
ｄｅｆａｕｌｔ：  ／／チェックアクセス（放棄）リスト
ｆｏｒ（ｉ＝０；ｉ＜ｐＯｗｎｅｒ−＞ｎＣｌｓＣｏｕｎｔ；ｉ＋＋）
｛
ｕｎｉｔ３２ｐｒｉｖＩｄ＝ｐＯｗｎｅｒ−＞ｐＣｌｓＬｉｓｔ［ｉ］；
（ｐｒｉｖＩｄ＜ＱＶＥＲＳＩＯＮ）ならば
｛
／／理由は許容可能か？
（ｐｒｉｖＩｄ＝＝ｐＲｅｑｕｅｓｔｅｒ−＞ｄｗＲｅａｓｏｎ）ならば
｛
ｓｔａｔｕｓ＝ＳＵＣＣＥＳＳ；
ｂｒｅａｋ；
｝
｛
また
｛
／／リクエスト者のクラスｉｄはマッチするか、グループ特権を有するか？
（ＩＳＨＥＬＬ＿ＣｈｅｃｋＰｒｉｖＬｅｖｅｌ（ｐＭｅ−＞ｍ＿ｐＩＳｈｅｌｌ、ｐｒｉｖＩｄ、ＴＲＵＥ））ならば
｛
ｓｔａｔｕｓ＝ＳＵＣＣＥＳＳ；
ｂｒｅａｋ；
｝
｝
｝
ｂｒｅａｋ；
｝
／／この時点で、ＯＥＭはアクセスリスト許可チェックを受容し、および／または現在のアクセス理由を検証することや、所有者のアクセスリストに関係なく特定のリクエスト者のＣＬＳＩＤの返送（ステータス）を許容するなどの追加決定アルゴリズムを追加することを選択できる；
｝
従って、デバイスで使用するための動的調停システムの１つ以上の実施形態がここに図示および説明されてきたが、これらの主旨や本質的特徴を逸脱することなく種々の変更が実施形態に対してなされてもよいことが理解されるであろう。従って、ここでの開示および説明は例示的であり、以下の特許請求の範囲で説明される本発明の範囲を限定する意図はない。
【図面の簡単な説明】
【００６７】
【図１】デバイスのデバイスリソースを割り当てるように動作する動的割り当てシステムの一実施形態を示している。
【図２】デバイスのデバイスリソースを割り当てるための動的割り当てシステムの一実施形態の機能図を示している。
【図３】動的調停システムの一実施形態を含むデバイスの一実施形態を示している。
【図４】デバイスで使用する動的調停システムの一実施形態を提供する方法の一実施形態を示している。
【図５】リソースアービタを操作して動的調停システムの一実施形態を提供する方法の一実施形態を示している。
【図６】動的調停システムの１つ以上の実施形態と併用するのに適したリソースコントロールアーキテクチャの一実施形態を示している。
【図７】動的調停システムの１つ以上の実施形態に従って、デバイスリソースが２つのアプリケーション間に割り当てられる様子の一例を示している。
【図１】
2008500648.tif 000003
【図２】
2008500648.tif 000004
【図３】
2008500648.tif 000005
【図４】
2008500648.tif 000006
【図５】
2008500648.tif 000007
【図６】
2008500648.tif 000008
【図７】
2008500648.tif 000009
【国際調査報告】
2008500648.tif 000010