JP5178218B2

JP5178218B2 - 機能提供装置

Info

Publication number: JP5178218B2
Application number: JP2008020065A
Authority: JP
Inventors: 智子三木; 文夫齋藤; 純湯川; 悟徳山; 英治松尾
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2008-01-31
Filing date: 2008-01-31
Publication date: 2013-04-10
Anticipated expiration: 2028-01-31
Also published as: JP2009181374A

Description

この発明は、内包するハードウエア又はソフトウエアの構成の変更によって実現し得る機能が変化した際に、自立的に機能実現可否判断を行い、機能を提供可能とする装置に関する。

多数のハードウエアデバイス及びソフトウエアモジュールを内包する装置に於いては、その構造の複雑さの増加によって、装置によって実現しうる操作及び処理を決定論的に導くことが困難になってきている。これに対しては、処理を階層化及びモジュール化することにより決定要因を局所的には単純化したりする装置が提案されており (例えば特許文献２参照。) 、或るいは、機能構成を処理から分離して決定づけた後に、処理を行ったりする装置が提案されている(例えば特許文献１参照。)。

特開２００６−１４２９９４号公報特開平１０−６９４１８号公報

上記の様な複雑なハードウエアデバイス及びソフトウエアモジュール構造を有する装置に於いては、開発工程が長期にわたり、開発人員も増大するという問題点があった。

又、処理を階層化及びモジュール化した装置であっても、装置内のハードウエア構成の変更又は要求される機能仕様の変更に対応するには、システム全体の見直しが必要になることもあり、開発コストがかかるという問題点があった。

又、機能構成を処理から分離しておく様な場合に於いても、実現可能な構成は別途決定づけておく必要性があり、その決定付けは装置の複雑さによって増大するという問題点があった。

この発明は、以上の様な問題点を解決するために成されたものであり、装置のハードウエア構成及び／又は要求仕様がダイナミックに変更になった場合に於いても、自律的にその装置が処理し得る機能を導出することが可能な装置を得ることを、その目的とする。

この発明の主題は、その各々が、機能提供装置の機能を分割して得られる各機能を実現出来る機能実現実体であり、且つ、階層化されて成る、複数のリソースプロバイダを備えて成る機能提供装置であって、前記複数のリソースプロバイダの内で最上位の階層と最下位の階層との間の各階層に属する各リソースプロバイダは、当該リソースプロバイダよりも一つ上位の階層に属するリソースプロバイダから送信されて来る、前記各機能実現要求であるリソースリクエストを受信するリクエスト受信部と、当該リソースプロバイダ内部機能の実現処理を行うと共に、当該内部機能の実現処理が可能であるか否かを判断するファンクションエフェクタと、前記ファンクションエフェクタが当該リソースプロバイダ内部機能を実現するために必要な当該リソースプロバイダよりも一つ下位の階層に属するリソースプロバイダに対して機能提供を要求するリソースリクエストを送信するリクエスト送信部と、当該リソースプロバイダよりも一つ下位の階層に属する前記リソースプロバイダからの、前記リクエスト送信部が送信したリソースリクエストに対する機能提供可否の応答内容と、前記ファンクションエフェクタからの内部機能の実現処理の可否の情報とから、当該リソースプロバイダの前記各機能の実現可否を判断して、その判断結果を前記リクエスト受信部が受信した前記リソースリクエストに対する応答して当該リソースプロバイダよりも一つ上位の階層に属する前記リソースプロバイダに送信するリソースマネージャとを備えており、前記最上位の階層に属する少なくとも一つのリソースプロバイダは、前記機能提供装置のユーザーである外部装置から送信されて来る最上位階層用のリソースリクエストを受信するリクエスト受信部と、前記ファンクションエフェクタと、前記リクエスト送信部と、当該リソースプロバイダよりも一つ下位の階層に属する前記リソースプロバイダからの、前記リクエスト送信部が送信したリソースリクエストに対する機能提供可否の応答内容と、前記ファンクションエフェクタからの内部機能の実現処理の可否の情報とから、当該リソースプロバイダの前記各機能の実現可否を判断して、その判断結果を前記最上位階層用のリソースリクエストに対する応答として前記外部装置に送信するリソースマネージャとを備えており、前記最下位の階層に属する少なくとも一つのリソースプロバイダは、前記リクエスト受信部と、前記ファンクションエフェクタと、前記ファンクションエフェクタからの内部機能の実現処理の可否の情報とから、当該リソースプロバイダの前記各機能の実現可否を判断して、その判断結果を前記リクエスト受信部が受信した前記リソースリクエストに対する応答して当該リソースプロバイダよりも一つ上位の階層に属する前記リソースプロバイダに送信するリソースマネージャとを備えており、前記最下位の階層に属する少なくとも一つのリソースプロバイダを除いた各リソースプロバイダは、そのリソースマネージャが当該リソースプロバイダの前記各機能を実現可であると判断したときには、当該リソースプロバイダよりも一つ下位の階層に属するリソースプロバイダとの間で論理的に結合したものと設定し、前記最下位の階層から前記最上位の階層までの間に存在する全てのリソースプロバイダに関して各リソースプロバイダ間を論理的に結合させたことにより階層化されたリソースプロバイダ群を形成することによって、前記機能提供装置の機能が提供可能な状態であるリソースマップを構成することを特徴とする。

本発明の主題によれば、機能提供装置のハードウエア構成及び／又は要求仕様がダイナミックに変更になった場合に於いても、自律的にその装置が処理し得る機能を導出することが出来る機能提供装置を得ることが出来る。

以下、この発明の主題の様々な具体化を、添付図面を基に、その効果・利点と共に、詳述する。

（実施の形態１）
本実施の形態の特徴点は、機能提供装置を、ハードウエア及びソフトウエアを含めて機能を実現出来る機能実現実体としてのリソースプロバイダに分割して、機能提供装置自体の機能は階層化されたリソースプロバイダ群によって実現する様に機能提供装置を構成し、更に、各リソースプロバイダは、その上位の階層に位置するリソースプロバイダから当該リソースプロバイダへ送信されて来る当該リソースプロバイダ自体の機能の実現要求に対して、当該機能の提供可否を応答する手段を有する点にある。以下、上記の特徴点を、図面を参照して詳述する。

図１〜図３は、本実施の形態に係る機能提供装置（以下「装置」と言う。）の構成を模式的に示した図である。これらの内で、図１は、ある装置全体を、機能実現単位であるリソースプロバイダの集合体として表現したブロック図であり、図２は、単一のリソースプロバイダの構成を示すブロック図であり、図３は、リソースプロバイダのサーバ／クライアントモデル図である。更に、図５は、本装置に於ける機能実現可否判断を行う手順を示すフローチャートである。

図１に於いて、装置は、すべからく、各リソースプロバイダがその他のリソースプロバイダと結合した集合体として存在している。図１に示すリソースマップ２００は、装置をリソースプロバイダ１００の集合体として表現したものである。即ち、リソースプロバイダ１００の結合状態で以って機能を提供する機能状態が、リソースマップ２００である。以下に、本発明で用いる幾つかの用語の定義について記載し、更に装置の構成について記載する。

先ず、「リソース」を、装置に於ける機能単位と定義する。そして、リソースプロバイダ１００は、リソースを実現することが出来る装置内の１ブロックである（機能実現部分）。このとき、機能単位(リソース)は、例えば、上位の階層で装置の要求仕様の一つとして規定される機能、ミドルウエアの処理として規定される機能、ドライバモジュールのインターフェースとして規定される機能から、ハードウエア仕様として規定される機能までの全てを、総称している。特に、本実施の形態に於いては、ハードウエアデバイス及びソフトウエアモジュールの区別をしない。

図２に於いて、リソースプロバイダ１００は、上述したリソースを提供する装置内の機能実現単位ないしは機能実現部分である。リソースプロバイダ１００は、他のリソースプロバイダ内のリクエスト送信部(図２に於いて図示せず)と接続されたリクエスト受信部１０１を有しており、当該リソースプロバイダ１００の外部から送信されて来る「リソースリクエスト」をリクエスト受信部１０１に於いて受信する。図２に示す様に、当該リソースプロバイダ１００は、その内部に、（１）当該リソースプロバイダ１００自体の機能実行実体であって機能実現処理を行うと共に、その機能（内部機能）を実現出来るか否かの判断を行うことが出来るファンクションエフェクタ１０３と、（２）当該リソースプロバイダ１００に結合された他のリソースプロバイダ(図示せず)が有するリクエスト受信部にリクエストを送信するリクエスト送信部１０４と、（３）ファンクションエフェクタ１０３が判断した内部機能実現可否の判断結果と、後述する様に当該リソースプロバイダ１００に結合された一つ下の下位階層に位置する他のリソースプロバイダからの応答内容とに基づいて、当該リソースプロバイダ１００が自身の機能実行が可能であるか否かを判断するリソースマネージャ１０２とを、備えている。

リソースプロバイダ１００は、装置内の「ある機能」を実現する機能実現部分であるが、外部より要求される機能を実現するに際しては、当該リソースプロバイダ１００よりも下位の階層に位置する他のリソースプロバイダ(図２に於いては図示せず)に対してその機能実現の要求を送信し、その機能の提供可能を上記他のリソースプロバイダから応答内容として受信することによって、当該リソースプロバイダ１００のファンクションエフェクタ１０３の機能を果たすことが出来る。即ち、リソースプロバイダ１００と上記他のリソースプロバイダとは、図３に示す様に、サーバ／クライアント型のコネクションを形成している。このとき、当該リソースプロバイダ１００に結合し且つ当該リソースプロバイダ１００よりも下位の階層に位置するリソースプロバイダ(図２に於いては図示せず)の数が複数である場合もあり、逆に、ある一つのリソースプロバイダが当該リソースプロバイダと結合し且つ当該リソースプロバイダよりも上位の階層に位置する複数のリソースプロバイダ(図２に於いては図示せず)から機能要求される場合もある。

尚、以下の記載に於いては、図２の記載を踏まえて、図１の各リソースプロバイダ１００ａ〜１００ｑが有するリソースマネージャ、ファンクションエフェクタ及びリクエスト送信部を、夫々、リソースマネージャ１０２、ファンクションエフェクタ１０３及びリクエスト送信部１０４と記載することとする。

図１に示す様に、本装置は、階層化された各リソースプロバイダが実現する機能の集合体として構成されている。個々のリソースプロバイダ１００ａ〜１００ｑは、それぞれ自身が担っている機能を実現するが、このとき、装置内の他のリソースプロバイダ１００ａ〜１００ｑによって機能実現を行い、その結果を以って自身の機能とすることが可能であり、各リソースプロバイダは、当該リソースプロバイダよりも一つ下位の階層に属するリソースプロバイダの各々に対して、そのリソースを駆動させるべく、ソースリクエストを行う。あるリソースプロバイダとその一つ上位又は一つ下位の階層に属する他のリソースプロバイダ同士は、上述した図３に示す様に、サーバ／クライアント型のコネクションによって結合されている。

例えば、図４に例示する様な、映像と音声とを出力する装置８００があった場合を考えると、本装置８００は、その映像・音声出力機能を、最上位の階層に属するリソースプロバイダ１００ｒとして有し、その一つ下の階層に、映像出力機能を呈するリソースプロバイダ１００ｓと音声出力を呈するリソースプロバイダ１００ｔとを有する様に構成される場合が、考えられる。

次に、図１に示す装置の動作について記載する。尚、以下の記載に於いては、図１の装置にその外部装置から機能実行命令が与えられてから後に、その機能が実現可能であるかどうかの判断を図１の装置内に於いて行うフローについて説明している。従って、あるリソースプロバイダ１００が自身の機能実現可能と判断してその判断結果を応答したときには、直ちに、あるリソースプロバイダ１００は、当該リソースプロバイダ１００よりも一つ上位の階層にある、リソースリクエストを送信して来たリソースプロバイダ１００が発する機能実行命令に従って、自身の機能の実現処理を実行する。

図１の装置のユーザーである外部装置（図示せず）が、本装置内の最上位の階層に位置する一方のリソースプロバイダ１００ａに対して、機能実行要求として、リソースリクエストを送信（発行）すると、リソースプロバイダ１００ａに内包されるリクエスト受信部１０１を介して当該リソースリクエストを受信したリソースプロバイダ１００ａは、リソースプロバイダ１００ａが自身の機能を実現するに際して必要となるリソースを、リソースプロバイダ１００ａよりも一つだけ下位の階層に属する(単数若しくは複数の) リソースプロバイダ１００ｂ(図１の場合は単数)に対して、リソースリクエストとして要求する。更に、リソースリクエストを受け取ったリソースプロバイダ１００ｂは、その一つ下位の階層にある(単数若しくは複数の)リソースプロバイダ１００ｃ、１００ｄ(図１の場合は複数)に対して、リソースリクエストを送信（発行）する。この様に、リソースリクエストを受け取ったリソースプロバイダがその一つ下位のリソースプロバイダに対してリソースリクエストを逐次発行していくことで、最終的には、最下層の階層にあるリソースプロバイダ(一般的にはハードウエアデバイスであり、図１に於いてはリソースプロバイダ１００ｇ、１００ｐが相当する)にまで、ソースリクエストが到達する。各リソースプロバイダでは、当該リソースプロバイダの一つ下位の階層に属するリソースプロバイダからのリソースリクエストに対する応答の全てと、当該リソースプロバイダが内包するファンクションエフェクタ１０３からのリソースリクエスト応答内容（内部機能実現可否判断結果）とによって、当該リソースプロバイダが内包するリソースマネージャ１０２が当該リソースプロバイダの機能実現の可否を判断し、当該リソースプロバイダよりも一つ上位の階層に位置するリソースプロバイダに対して、自身の機能実現の可否の判断結果を、リソースリクエストに対する応答として出力する（この点に関しては、図５のフローチャートを用いて後述する）。ここで、機能実現可否の判断材料としては、例えば、自身のファンクションエフェクタ１０３に与えられたメモリ量が機能実現処理に必要な量に満たない場合、或いは、リソースプロバイダの機能処理の同時実行最大数等がある。リソースリクエストに対する応答は、最下層のリソースプロバイダから順次に発行され、最終的には、装置内の最上位の階層にあるリソースプロバイダの機能実現可否判断結果となる。そして、最上位の階層にあるリソースプロバイダは、その機能実現可否判断結果を、その内包するリソースマネージャ１０２を介して、最上位用のリソースリクエストに対する応答として、ユーザーである外部装置（図示せず）に対して、送信する。

次に、あるリソースプロバイダが、その一つ上位の階層に位置するリソースプロバイダからリソースリクエストを受け取ってから、その上位のリソースプロバイダに応答するまでのフローを、図５（ａ）のフローチャートに基づいて、記載する。

あるリソースプロバイダ内で機能実現可否判断を行なうには、先ず、当該リソースプロバイダがリソースリクエスト受信待ち状態となる（ステップ５０１）。その後、リソースリクエストが当該リソースプロバイダのリクエスト受信部１０１で受信されると、当該リソースプロバイダはリソースリクエスト受信と判定し（ステップ５０２）、当該リソースプロバイダの機能実現にとって必要な一つ下位の階層に属するリソースプロバイダが機能実現可能であるか否かの判断を行う（ステップ５０３）。そして、当該リソースプロバイダは、ステップ５０３に於ける上記判断内容と、当該リソースプロバイダが有するファンクションエフェクタ１０３による機能実現可否の判断内容とを加味して、リソースリクエストを受信したリソースプロバイダとしての機能実現可否としての判定を行う（ステップ５０４）。そして、当該リソースプロバイダは、ステップ５０４での判定結果を、リソースリクエスト送信を送って来た一つ上位の階層に属するリソースプロバイダに対して出力することで、上記リソースリクエストに対する応答を実行する（ステップ５０５）。

次に、図５（ａ）に於ける下位リソースプロバイダ機能実現判断ステップ５０３の詳細を、図５（ｂ）のフローチャートを用いて記載する。

先ず、当該リソースプロバイダは、当該リソースプロバイダが自身の機能を実現するために必要とする機能を有するリソースプロバイダが一つ下位の階層にいくつ存在するかの情報を取得する（ステップ５０８）。この情報は、当該リソースプロバイダのリソースマネージャ１０２内に予め知られた数として存在するものとし、この数をＬと定義する。若し、Ｌ＝０、即ち、自身のリソースプロバイダ内で機能実現が閉じて処理されるのであれば、当該リソースプロバイダは、下位リソースプロバイダ機能実現可否判断を直ちに終了する(ステップ５１６)。逆にＬ≠０である場合には、当該リソースプロバイダは、下位リソースプロバイダの数(Ｌ)だけの回数分、下位リソースプロバイダの機能実現可否判断を行う（ステップ５０９〜ステップ５１４）。

下位リソースプロバイダの機能実現可否判断に関しては、先ず、当該リソースプロバイダのリクエスト送信部１０４が、当該リソースプロバイダよりも一つ下位の階層に属するリソースプロバイダに対してリソースリクエストを送信（発行）し(ステップ５１０)、当該リソースプロバイダは、送信したリソースリクエストに対する応答待ち状態となる(ステップ５１１)。その後、当該リソースプロバイダが、リソースリクエストを受信した一つ下位の階層に属する全てのリソースプロバイダからの応答を受け取ると（ステップ５１２）、当該リソースプロバイダは、その応答内容から、一つ下位の階層にある単一リソースプロバイダの機能実現可否判断を行う（ステップ５１３）。

そして、当該リソースプロバイダは、これらの、下位の単一リソースプロバイダの機能実現可否判断を総合して機能実現可否判断を行い（ステップ５１５）、下位リソースプロバイダ機能実現判断を終了する（ステップ５１６）。

あるリソースプロバイダが、一つ下位の階層にあるリソースプロバイダから、リソースリクエストに対する応答として機能実現可能と言う判断結果を受け取った場合には、当該リソースプロバイダ自身のファンクションエフェクタ１０３が機能実現可能であるときには、あるリソースプロバイダは、当該リソースプロバイダとその下位の階層にあるリソースプロバイダとを、機能実現群として、即ち、当該リソースプロバイダは機能実現可能と言う状態にあるとして、論理的に結合する（リソースプロバイダ同士の論理的結合）。そして、あるリソースプロバイダは、そのリソースマネージャ１０２から既述した応答を行うと共に、自身の機能（リソース）の実現処理を実行する。それに対して、一つ下位の階層にあるリソースプロバイダから、リソースリクエストに対する応答として機能実現不可能と言う判断結果を受け取った場合には、或いは、上記応答内容が機能実現可能であっても当該リソースプロバイダ自身のファンクションエフェクタ１０３が機能実現不可能である判断しているときには、あるリソースプロバイダは、当該リソースプロバイダよりも一つ上位の階層にあるリソースプロバイダに対して、機能実現不可能と言う応答を行う。このとき、あるリソースプロバイダは、自身の機能（リソース）の実現処理を実行せず、その代わりに、当該リソースプロバイダよりも下位の階層にある全てのリソースプロバイダ間の論理的結合を解除して非結合状態とする処理を行う。この非結合状態とする処理は、以降、最下位の階層にあるリソースプロバイダとその一つ上位のリソースプロバイダとの論理的結合にまで、実行される。

各応答が機能実現可能であるときには、各応答に従って順次にリソースプロバイダ間の論理的結合が行われ、その結果、最上位の階層に到達したリソースリクエストに対する応答が機能実現可能であった場合には、最上位の階層にあるリソースプロバイダに於いては、最上位の階層で意味するところの機能が、即ち、ユーザーの外部装置に対して示される本装置の機能が実現可能となるリソースプロバイダ群が生成されている。この段階に於いて生成されたリソースプロバイダ群が、図１のリソースマップ２００である。例えば、図６は、リソースプロバイダ１００ａの機能を実現するリソースマップ構造を表している。

以上の様に、本実施の形態では、ソフトウエア及びハードウエアの各々が実現する機能をリソースプロバイダとして捉え、個々のリソースプロバイダが機能実現可否判断を行う様に本装置は構成されているので、ハードウエアが変更になった場合及び／又は装置の要求機能が変更になった場合に於いても、変更した個々のリソースプロバイダの機能実現可否判断を局所的に変更するだけで、ダイナミックに装置の機能実現可否判断を行うことが出来、又、装置の機能を実現することが出来る。

（実施の形態２）

表１は、本実施の形態に係るリソースプロバイダ１００の分類をまとめたものである。既述した実施の形態１は、リソースプロバイダ１００の機能実現可否判断に於ける種別分類が無い場合についての形態であるが、本実施の形態は、表１に示す様に、リソースプロバイダ１００に複数の種別分類がある場合の形態である。但し、本実施の形態に於いても、装置の構成については実施の形態１の場合と同様であり、その記載を省略すると共に、図１〜図３を援用する。

先ず、構成について記載する。リソースプロバイダ１００の機能内容及び構成は、実施の形態１の場合と同様である。但し、リソースプロバイダ１００に於けるリソースマネージャ１０２には、自身の分類種別によって機能実現可能か否かを判断する機能が付与されている。

表１に示す様に、一例として、リソースプロバイダ１００を３つの種別に分類する。即ち、Singletonリソースプロバイダ、Exclusiveリソースプロバイダ、及びSharedリソースプロバイダである。

Singletonリソースプロバイダは、有限数の実行権を有しており、あるリソースプロバイダに機能を提供しているときには、その他のリソースプロバイダからのリソースリクエストに従った動作を有限個の実行権の数を超えて認めないものである。

ここで、「実行権」とは、当該リソースプロバイダを駆動させることが出来る権利である。若し、リソースリクエストの数が当該リソースプロバイダの実行権の総数以内であるならば、上位クライアントとなるリソースプロバイダからのリソースリクエストに対する応答は、全て、機能実現可能として処理される。他方、リソースリクエストの数が当該リソースプロバイダの実行権の総数を既に越えてしまっている結果、余分な実行権が無い場合には、当該リソースプロバイダは、実行権の総数を既に越えてしまった後にリソースリクエストを送信して来た一つ上位の階層に属するリソースプロバイダに対して、機能実現不可能として応答するか、或いは、機能実現可能としてリソースリクエストに対して応答を送信（発行）するけれども、当該上位リソースリクエストからの機能実現命令に対しては当該機能の処理を行わないこととする。

Exclusiveリソースプロバイダは、有限数の実行権を有しており、同一条件下でのリソースリクエストであるならば、実行権の総数がリソースプロバイダが保有する実行権の数を超えていても機能実現可能として応答し、機能実現命令に対しても処理を行うものである。

Sharedリソースプロバイダは、論理上無限の実行権を有しており、出来る限り機能を動作させる／動作出来るものとするものである。

次に、リソースプロバイダ１００の種別に応じて、リソースリクエストに対する機能実現可否判断を行う方法を、図７を用いて記載する。

リソースプロバイダ１００は、それ自体の属性値として、表１に記載した上記３つの種別の内の一つを有する。リソースプロバイダ１００がどの種別を有するかは、各リソースプロバイダ自身が有するファンクションエフェクタ１０３の構成及び機能内容、当該リソースプロバイダよりも一つ下位の階層に位置するリソースプロバイダの機能要件に依存する。例えば、１種類の周波数にのみロック可能な機構を備えるチューナをリソースプロバイダとした場合には、当該リソースプロバイダは、１つの実行権のみを有するSingletonリソースプロバイダである。又、１つのＰＩＤフィルタに対して同一のＰＩＤであれば複数からのＰＩＤフィルタリクエストに応じるリソースプロバイダは、Exclusiveリソースプロバイダとすることが出来る。ここで、ＰＩＤフィルタとは、ＭＰＥＧ２ＴＳ（ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ）から特定のＰＩＤ（ＰｒｏｇｒａｍＩＤ）を抽出する機能を指している。又、リモコン受付機能を備えるリソースプロバイダは、Sharedリソースプロバイダとすることが出来る。

各リソースプロバイダ１００は、リソースリクエストを受信すると、自身の保有実行権数(Ｎ)（ステップ７０１）、現在提供しているリソースの数(ｎ)（ステップ７０２）、及び、当該リソースプロバイダの種別(ｋ)を、当該リソースプロバイダ内のリソースマネージャ１０２から取得する。ステップ７０３に於ける判断結果がｋ=Singletonの場合には、ステップ７０４に於ける判断結果がｎ≦Ｎならば当該リソースプロバイダは機能提供可能と判断し（ステップ７０５）、他方、ステップ７０４における判断結果がｎ＞Ｎならば当該リソースプロバイダは機能提供不可能と判断する（ステップ７０６）。又、ステップ７０３に於ける判断結果がｋ=Exclusiveの場合には、ステップ７０７に於ける判断結果がｎ≦Ｎならば当該リソースプロバイダは機能提供可能と判断し（ステップ７０９）、他方、ステップ７０７に於ける判断結果がｎ＞Ｎであって且つステップ７０８に於ける判断結果がリソースリクエストに於いて要求されているリソース内容が既に提供しているものと同一であれば、当該リソースプロバイダは機能提供可能と判断し（ステップ７０９）、それ以外の場合には当該リソースプロバイダは機能提供不可能と判断する（ステップ７１０）。又、ステップ７０３に於ける判断結果がｋ=Sharedの場合には、当該リソースプロバイダは全てのリソースリクエストに対して機能提供可能と判断する（ステップ７１１）。

以上の通り、実施の形態２によれば、各々のリソースプロバイダは、それ自身の持つ機能提供範囲を判断する状態を、リソースプロバイダ種別として有することとしている。そのため、機能提供の可否をより一般的な判断基準で以って簡便に判断することが出来る。

（実施の形態３）
本実施の形態では、図８に示す様に、機能実現実体としてのリソースプロバイダのリンク状態としてのリソースマップとは別に、リソースファクトリ４００が、その内部にリソースマップを有する様に構成されている。リソースファクトリ４００は、既述した実施の形態１，２では各リソースプロバイダ１００に内包されていたリソースマネージャ１０２の機能の各々を、全てのリソースプロバイダ分だけ含む様に構成されている。以下、リソースファクトリ４００内に含まれるリソースマネージャ機能部分を、「仮想リソースマネージャ４０１」と言う。

上述の実施の形態１，２では、リソースマップ２００の生成タイミングは、装置の外部装置（ユーザー）から機能実行命令の発行後に新たなリソースリクエストが発行される時をトリガにして開始され、リソースマップ２００の生成は、リソースプロバイダのリンク生成でもあった。そして、実施の形態１，２では、機能実現の可能判断と機能実現可能状態の生成（機能実現処理の実行）とが同時に行われ、リソースプロバイダ１００のリンク状態がそのまま装置内のリソースマップ２００と成っていた。これに対して、本実施の形態では、リソースマップ２００の生成が、外部装置から本装置に対して機能実行命令が発行されて本装置が機能実現処理を行う前の段階に於いて生成する。

以下、動作順序を箇条書きにて記載する。

１．リソース要求
機能提供のための最上位のリソースリクエストを何れのリソースプロバイダに送信するか（図８の例では、最上位の階層に位置するリソースプロバイダ１００ａ，１００ｈの何れにリソースリクエストを送信（発行）するか）が、ユーザーである外部装置によって決定付けられると、そのリソースリクエストが発行される最上位のリソースプロバイダ１００に対応した仮想リソースマネージャ４０１を起点に、順に下位の仮想リソースマネージャ４０１を決定付けていく。各階層での決定付けには、仮想リソースマネージャ４０１に対応したリソースプロバイダ１００が有する下位に必要とするリソースプロバイダ１００の種別情報を用いる。

２．リソースマップ作成
仮想リソースマネージャ４０１は、最上位のリソースリクエスト（例えば予想される最上位のリソースリクエスト）に対応する仮想リソースマネージャ４０１から各階層を経て最下層の仮想リソースマネージャ４０１までの繋がり（論理的結合）を、仮想のリソースマップとして表現する。表現方法としては、例えば、上位から下位へのリンクポインタを用いる。

３．リソースマップ比較
システム内で１つの機能が動作していれば、この動作機能に対応したリソースマップ２００が存在する。複数の機能が動作していれば、動作機能の数に等しい数のリソースマップ２００がシステム内に存在する。即ち、リソース要求前にシステム内で稼働している機能に従ったリソースマップ２００の集合が、システム内部のリソースプロバイダ使用状況と成っている。このシステムリソースマップの集合と上記の２.で作成した要求されるだろう仮想のリソースマップとを合成／合算して、新たなリソースマップを構成する。ここで、「合成／合算する」とは、リソースマップ２００をノードにリソースを持つ木構造としたときのノードの挿入に相当する。

４．機能提供判断
システムリソースマップの集合と要求リソースマップとの合成／合算結果に於いて、同一のリソースプロバイダに繋がるリソースプロバイダの数が、当該リソースプロバイダが提供することが出来る数(リソースの実行権による分類種別、及び、機能インスタンス最大数属性の数（保有実行権数Ｎに相当）から算出)を超えていた場合には、当該リソースプロバイダがSingletonリソースプロバイダの場合には、当該リソースプロバイダは機能実現不可能状態であると判断する。当該リソースプロバイダがExclusiveリソースプロバイダの場合には、更にリソースリクエストの内容に鑑み、同時に実行可能な種別のリソースリクエストの数を超えていた場合には、当該リソースプロバイダは機能実現不可能状態であると判断する。当該リソースプロバイダがSharedリソースプロバイダの場合には、数に拘わらず、当該リソースプロバイダは機能実現可能状態であると判断する。

以上の通り、実施の形態３によれば、リソースマップの生成を機能の実現に先駆けて行うことが出来るので、機能実現を開始した後には、機能実現不可能状態が判明して一度結合したリソースプロバイダの状態を外すという場合が存在しない。従って、機能生成と機能破棄、即ち、リソースプロバイダ１００の生成と破棄とが短い時間に多数行われる様なケースが減るため、システムの安定性を増すことが出来る。

図８では、木構造を有するリソースマップを想定して記載しているが、システム構成及び装置の仕様によっては、アプリケーションソフト（以下「アプリ」と言う。）と特定リソースとのセットとして、リソースマップを１次元的に表現する様にしても良い。

又、リソースマップを生成するタイミングは、装置設計時であっても良く、この場合には、装置が機能実現する時には、リソースマップが装置内のリソースファクトリ４００内に固定的に備えられていると言う様な構成にすることも可能である。

（実施の形態４）
上述の実施の形態１〜３では、装置が有する機能及びリソースプロバイダの有する機能(リソース)が実現する具体的な機能及び処理は記載されてはいなかったが、本実施の形態に於いては、装置としてデジタルテレビ装置とし、リソースプロバイダを具体的な実現機能責務を持ったものとしている。

以下、図９を参照して、本実施の形態に係る機能提供装置を記載する。

先ず、視聴アプリ６０１は、リソースプロバイダ１００の一つであって、ＴＶ視聴に関わるユーザーからのリクエストを受信すると共に、視聴の開始・停止等を実現する機能を有している。視聴系６１１は、視聴アプリ６０１の下位リソースプロバイダであって、ＴＶ視聴を行う一連のストリーム制御を実現する機能を有している。フロントエンドエフェクタ６２１は、視聴系６１１の下位リソースプロバイダの一つであって、視聴系６１１が制御するストリームの入力を選択し、開始/停止する機能を有している。セレクタエフェクタ６２２は、視聴系６１１の下位リソースプロバイダの一つであって、視聴系６１１が制御するストリームに含まれる複数もしくは単数の映像及び音声からどのストリームデータを制御するのかを選択し、格納する機能を有する。著作権管理エフェクタ６２３は、視聴系６１１の下位リソースプロバイダの一つであって、視聴系６１１が制御するストリームの著作権に拘わる情報の収集と、格納及び著作権情報に従ったデータ処理とを行う機能を有している。映像音声プレイヤエフェクタ６２４は、視聴系６１１の下位リソースプロバイダの一つであって、視聴系６１１が制御するストリームの内で指定された映像及び音声等のデコード開始/停止を行う機能を有している。出力ユニットエフェクタ６２５は、視聴系６１１の下位リソースプロバイダの一つであって、映像、音声及びグラフィック等のデータを装置の外部に提示及び出力する機能を有している。チューナドライバ６３１は、フロントエンドエフェクタ６２１の下位リソースプロバイダの一つであって、放送波のチャンネルに応じた周波数選択機能を有する。ＣＡＳドライバ６３２は、著作権管理エフェクタ６２３の下位リソースプロバイダの一つであって、ストリームの視聴制御(ＣＡＳ:Conditional Access System)の情報取得及びデータ処理を行う機能を有している。ＤＥＭＵＸドライバ６３３は、セレクタエフェクタ６２２と著作権管理エフェクタ６２３および映像音声プレイヤエフェクタ６２４の下位リソースプロバイダの一つであって、ストリームのＤＥＭＵＸ(DEMUltpleX)やＭＰＥＧレイヤーでの情報取得およびＰＩＤフィルタリング等を行う機能を有している。ＡＶドライバ６３４は、映像音声プレイヤエフェクタ６２４の下位リソースプロバイダの一つであって、映像及び音声のデコードの開始/停止等を行う機能を有している。グラフィックスドライバ６３５は、出力ユニットエフェクタ６２５の下位リソースプロバイダの一つであって、グラフィックス描画の処理を行う機能を有している。チューナ６４１は、チューナドライバ６３１の下位リソースプロバイダの一つであって、放送波等を受信して指定の周波数にロックし、あるチャンネルに含まれるデータを取得する機能を有しているハードウエアである。ＩＣカードはＣＡＳドライバ６３２の下位リソースプロバイダの一つであって、視聴制御方式に従ったデータ処理を行う機能を有しているハードウエアである。デジタルテレビ用バックエンドＳｏＣ（System on Chip）６４３は、ＤＥＭＵＸドライバ６３３とＡＶドライバ６３４およびグラフィックスドライバ６３５の下位リソースプロバイダの一つであって、デジタルテレビシステムに於けるストリームのＤＥＭＵＸ処理や指定された映像音声のデコード処理映像やグラフィックスのプレーンを提供する機能を有しているハードウエアである。メモリ６４４は、ここでは、グラフィックスドライバ６３５の下位リソースプロバイダの一つであって、グラフィックスに必要なメモリを提供する機能を有しているハードウエアである。デジタルテレビ装置６００は、上記のリソースプロバイダ６０１〜６４４を含む装置である。

次に、デジタルテレビ装置６００の動作について記載する。

装置に加えられた機能提供要求が、各リソースプロバイダ６０１〜６４４の機能提供可否判断とリソースプロバイダ間の結合とで機能実現されるフロー、各リソースプロバイダ６０１〜６４４並びにリソースプロバイダ１００に含まれるリソースマネージャ１０２、リクエスト受信部１０１、ファンクションエフェクタ１０３、及びリクエスト送信部１０４の動作については、上述の実施の形態１〜３と同じである。

ここでは、例えば電源オン等のユーザー動作によってデジタルテレビ装置６００に対してＴＶ視聴という機能要求が成された場合について、各リソースプロバイダ６０１〜６４４の動作と共に、詳しく記載する。

先ず、デジタルテレビ装置６００に要求されたＴＶ視聴要求は、視聴アプリ６０１に送信される。視聴アプリ６０１は、自身が視聴機能を実現させるために必要となる視聴系６１１に対して、リソースリクエストを送信する。このとき、リクエストを受信するのは、視聴アプリ６０１と言うリソースリクエストに於けるリソース受信部１０１であり、リクエスト送信を行うのは視聴アプリ６０１のリソース送信部１０４である点は、上述の実施の形態１〜３と同じであり、以下に記載する様々なリソースプロバイダ６０１〜６４４がリクエストの送受信及び応答を行う場合に於いても、上述の実施の形態１〜３と同様である。視聴系６１１は、視聴アプリ６０１からのリソースリクエストを受信すると、自身の機能であるストリームの視聴を制御し、視聴の開始を行うのに必要なリソースプロバイダである下位のフロントエンドエフェクタ６２１、セレクタエフェクタ６２２、著作権管理エフェクタ６２３、映像音声エフェクタ６２４、出力ユニットエフェクタ６２５に、リソースリクエストを送信する。但し、このとき、視聴系６１１は、自身の下位の階層に位置するリソースプロバイダ６２１〜６２５へのリソースリクエストを送信するタイミングを、視聴系６１１内部にあるファンクションエフェクタ１０３の処理と連携して、フロントエンドエフェクタ６２１から順に送信する。上記に記載した様に、あるリソースプロバイダの機能実現可否は全ての下位リソースプロバイダの機能実現可否取得をループして判断されるが、視聴系６１１が機能実現、即ち、ストリームを視聴状態にする様な場合には、下位リソースプロバイダ６２１〜６２５を順次機能させていく過程で途中のリソースプロバイダが機能実現不可であった場合には、視聴系６１１としての機能が実現できないため、全ての下位リソースプロバイダの可否判断を待たずに、自身の機能実現可否判断とすることも出来る。視聴系６１１からリソースリクエストを受信したフロントエンドエフェクタ６２１は、自身の機能であるストリームの入力を選択し、その入力を開始する機能を実現するために、入力の選択として、下位リソースプロバイダを選定し、選定したリソースプロバイダへ、機能実現のためのリソースリクエストを送信する。例えば、視聴アプリ６０１からのリソースリクエストが地上波デジタル放送視聴であった場合には、フロントエンドエフェクタ６２１は、地上デジタル放送受信用のチューナドライバ６３１を下位リソースプロバイダとして選定し、チューナドライバ６３１へ、指定のチャンネルにチューンすると言うリソースリクエストを送信する。このリソースリクエストを受けたチューナドライバ６３１は、チューナ６４１に対して、ある周波数へのロック機能を支持するためのリソースリクエストを送信する。チューナ６４１は、指定の周波数へのチューニング処理を行うと共に、その機能が実現可能か否かの判断を行い、上位リソースプロバイダであるチューナドライバ６３１に対して、実現可否判断結果を、リソースリクエストの応答として、返送する。応答を受信したチューナドライバ６３１は、応答内容と自身のファンクションエフェクタ１０３の処理実現可否判断内容とから、チューナドライバ６３１としてのフロントエンドエフェクタ６２１に返送する。すると、フロントエンドエフェクタ６２１は、チューナドライバ６３１と同様、自身のファンクションエフェクタ１０３の処理実現可否判断内容からフロントエンドエフェクタ６２１としての機能実現可否判断を行い、この結果を上位リソースプロバイダである視聴系６１１へ返送する。視聴系６１１は、前述の様に得られたフロントエンドエフェクタ６２１からの応答から、次の要求を行うか否かの判断を行い、次の要求を行うと判断した場合には、セレクタエフェクタ６２２へのある番組の視聴情報取得という機能を、リソースリクエストとして送信する。セレクタエフェクタ６２２は、自身の機能である指定されたストリームデータを制御するための情報を取得するために、ＤＥＭＵＸドライバ６３３へ、ストリーム中のデータ情報取得機能としてのリソースリクエストを送信する。このリソースリクエストを受信したＤＥＭＵＸドライバ６３３は、自身が取得すべき番組の情報がストリーム中のどの情報であるか否かを決定し、取得すべきデータをデジタルテレビ用バックエンドＳｏＣ６４３（ＳｏＣ:System On Chip）に取得要求する。デジタルテレビ用バックエンドＳｏＣ６４３は、指定されたデータをストリーム中から取得する処理を行うと共に、そのデータの取得やデータ状態の監視機能が実現可能であるか否かの判断を行い、上位リソースプロバイダに、リソースリクエストの応答として返送する。この返送内容が、上位のリソースプロバイダの内部機能実現可否判断と共に、順次に上位リソースプロバイダに返送されていくのは、チューナ６４１、チューナドライバ６３１、フロントエンドエフェクタ６２１から視聴系６１１に至る動作と同じである。この後、視聴系６１１は、順次に、著作権管理エフェクタ６２３、映像音声エフェクタ６２４、出力ユニットエフェクタ６２５へ、リソースリクエストを送信し、送信された各エフェクタ６２３〜６２５が、そのリクエスト内容に応じて、更に下位のリソースプロバイダを選定し、リソースリクエストを送信し、その応答に応じて自身の機能実現可否判断としていく動作は、前述のフローと同じである。視聴系６１１が視聴アプリ６０１から受信した機能要求が、下位のリソースプロバイダ群の機能実現可否判断と実現処理実行とによって実現可能/不可能と判断した場合には、視聴アプリ６０１へ、応答として、その内容を返送する。

この一連のリソースリクエストの伝搬と機能実現可否判断及び機能実現処理の実行とによって、デジタルテレビ装置に於いて、ＴＶ視聴と言う機能が実現される。更に、機能が実現されている状態では、デジタルテレビ装置には、図９に示す様なリソースマップが生成されていることになる。

更に、上記構成にあるデジタルテレビ装置６００に於いて、単数又は複数のリソースプロバイダが変更になった場合の動作について、記載する。リソースプロバイダが変更となる要因としては、ハードウエアモジュールが変更された場合(ケースＡ)、装置内部で実行可能なソフトウエアモジュール数が変更になった様な場合(ケースＢ)、又、上位リソースプロバイダの要求機能が変更になったために新たな種類、即ち、新たな機能を実現する責務を有することとなる場合、ソースプロバイダが新規追加される様な場合(ケースＣ)がある。

例えば、ケースＡは、使用するデジタルテレビ用バックエンドＳｏＣ６４３を変更したために使用可能なＰＩＤフィルタの数が変更になる様な場合であり、このとき、リソースプロバイダであるデジタルテレビ用バックエンドＳｏＣ６４３が実現可能なＰＩＤのフィルタリング数が異なるため、ある状況での当該リソースプロバイダの実現可能判断の限界値が変更になる。しかし、変更前に於いても、当該リソースプロバイダの上位にあるリソースプロバイダＤＥＭＵＸドライバ６３３は、デジタルテレビ用バックエンドＳｏＣ６４３に内包されるＰＩＤフィルタの数によって自身の機能実現判断を行っている訳ではなく、下位の階層に属するリソースプロバイダの可否判断が可であったか否かであったかによって自身の実現可否判断をしているため、この変更によって上位リソースプロバイダの判断ロジックが変更になることは無い。

又、ケースＢでは、例えば、装置のシステムメモリの量に変更があったために装置内で同時実行可能な視聴系６１１等のソフトウエアモジュール数が変更になった様な場合であり、この場合には、視聴アプリ６０１から下位へと送信されていくリソースリクエストが、モジュールが使用するメモリ不足によって、機能実現不可能となるタイミングが変更になるが、それぞれのリソースプロバイダが判断するロジックが変更になることは無い。

更に、ケースＣとは、例えば、映像のエンコードがＭＰＥＧ２に加えてＨ.２６４によって成されている様なストリームが受信される様に変更された場合であり、この場合、ＡＶドライバ６３４はＭＰＥＧ２デコードを行うことの出来る機能を有したリソースプロバイダの他に、Ｈ.２６４デコードが可能な別のリソースプロバイダを用意する必要がある。しかし、この場合に於いても、ＡＶドライバ６３４の上位リソースリクエストである映像音声エフェクタ６２４では、どちらの下位リソースプロバイダに対してリソースリクエストを送信するかの判断は必要なものの、下位リソースリクエストの機能提供可否応答から自身の機能提供可否判断を行うロジックについては変更の必要性が無い。

この様に、デジタルテレビ装置６００をリソースプロバイダ１００単位に機能分割し、リソースプロバイダ１００の論理的結合によってデジタルテレビ装置６００が構成される様にしているため、デジタルテレビ装置６００としての機能実現可否が自律的に判断でき、しかも、装置の内部構成に変更があった場合に於いても、リソースプロバイダ１００の局所的な変更で以って装置全体の構成を変更することが出来る。

尚、図９では、ＴＶ視聴機能を視聴アプリ６０１と視聴系６１１とによって実現したが、図１０に示す様に、録画アプリ６０２と録画系６１２とを設け、録画系６１２から視聴系と同様のエフェクタ群を配置することで、録画機能を実現することが出来る。又、図１１に示す様に、前述の録画系を視聴系と同時実行することによって、視聴しながらの録画機能をデジタルテレビ装置に付加することも可能である。

（付記）
以上、本発明の実施の形態を詳細に開示し記述したが、以上の記述は本発明の適用可能な局面を例示したものであって、本発明はこれに限定されるものではない。即ち、記述した局面に対する様々な修正や変形例を、この発明の範囲から逸脱することの無い範囲内で考えることが可能である。

この発明は、例えば映像情報システムに適用して好適である。

この発明の実施の形態１に係る装置の構成を示すブロック図である。この発明の実施の形態１に係るリソースプロバイダのブロック図である。この発明の実施の形態１に係るリソースプロバイダ間の結合ブロック図である。この発明の実施の形態１の一例に係る映像・音声出力装置を示すブロック図である。この発明の実施の形態１に係る機能実現可否判断のフローチャートである。この発明の実施の形態１の一例に係るリソースマップの例を示す図である。この発明の実施の形態２に係るリソースプロバイダの機能実現可否判断のフローチャートである。この発明の実施の形態３に係る装置の構成を示すブロック図である。この発明の実施の形態４に係る視聴機能を有するリソースプロバイダの結合状況及びリソースマップを示すブロック図である。この発明の実施の形態４に係る録画機能を有する場合のリソースプロバイダの結合状況及びリソースマップを示すブロック図である。この発明の実施の形態４に係る視聴中録画機能を有する場合のリソースプロバイダの結合状況及びリソースマップを示すブロック図である。

符号の説明

１００リソースプロバイダ、１０１リクエスト受信部、１０２リソースマネージャ、１０３ファンクションエフェクタ、１０４リクエスト送信部、２００リソースマップ、３００クライアントリソースプロバイダ、３０１サーバーリソースプロバイダ、４００リソースファクトリ、６００デジタルテレビ装置、６０１視聴アプリ、６０２録画アプリ、６１１視聴系、６１２録画系、６２１フロントエンドエフェクタ、６２２セレクタエフェクタ、６２３著作権管理エフェクタ、６２４映像音声プレイヤエフェクタ、６２５出力ユニットエフェクタ、６２６録画データプレイヤエフェクタ、６３１チューナドライバ、６３２ＣＡＳドライバ、６３３ＤＥＭＵＸドライバ、６３４ＡＶドライバ、６３５グラフィックスドライバ、６３６ＰＴＳ生成ドライバ、６３７記録媒体ドライバ、６４１チューナ、６４２ＩＣカード、６４３デジタルテレビ用バックエンドＳｏＣ、６４４メモリ、６４５記録媒体駆動部、８００映像・音声出力装置。

Claims

その各々が、機能提供装置の機能を分割して得られる各機能を実現出来る機能実現実体であり、且つ、階層化されて成る、複数のリソースプロバイダを備えて成る機能提供装置であって、
前記複数のリソースプロバイダの内で最上位の階層と最下位の階層との間の各階層に属する各リソースプロバイダは、
当該リソースプロバイダよりも一つ上位の階層に属するリソースプロバイダから送信されて来る、前記各機能実現要求であるリソースリクエストを受信するリクエスト受信部と、
当該リソースプロバイダ内部機能の実現処理を行うと共に、当該内部機能の実現処理が可能であるか否かを判断するファンクションエフェクタと、
前記ファンクションエフェクタが当該リソースプロバイダ内部機能を実現するために必要な当該リソースプロバイダよりも一つ下位の階層に属するリソースプロバイダに対して機能提供を要求するリソースリクエストを送信するリクエスト送信部と、
当該リソースプロバイダよりも一つ下位の階層に属する前記リソースプロバイダからの、前記リクエスト送信部が送信したリソースリクエストに対する機能提供可否の応答内容と、前記ファンクションエフェクタからの内部機能の実現処理の可否の情報とから、当該リソースプロバイダの前記各機能の実現可否を判断して、その判断結果を前記リクエスト受信部が受信した前記リソースリクエストに対する応答して当該リソースプロバイダよりも一つ上位の階層に属する前記リソースプロバイダに送信するリソースマネージャとを備えており、
前記最上位の階層に属する少なくとも一つのリソースプロバイダは、
前記機能提供装置のユーザーである外部装置から送信されて来る最上位階層用のリソースリクエストを受信するリクエスト受信部と、
前記ファンクションエフェクタと、
前記リクエスト送信部と、
当該リソースプロバイダよりも一つ下位の階層に属する前記リソースプロバイダからの、前記リクエスト送信部が送信したリソースリクエストに対する機能提供可否の応答内容と、前記ファンクションエフェクタからの内部機能の実現処理の可否の情報とから、当該リソースプロバイダの前記各機能の実現可否を判断して、その判断結果を前記最上位階層用のリソースリクエストに対する応答として前記外部装置に送信するリソースマネージャとを備えており、
前記最下位の階層に属する少なくとも一つのリソースプロバイダは、
前記リクエスト受信部と、
前記ファンクションエフェクタと、
前記ファンクションエフェクタからの内部機能の実現処理の可否の情報とから、当該リソースプロバイダの前記各機能の実現可否を判断して、その判断結果を前記リクエスト受信部が受信した前記リソースリクエストに対する応答して当該リソースプロバイダよりも一つ上位の階層に属する前記リソースプロバイダに送信するリソースマネージャとを備えており、
前記最下位の階層に属する少なくとも一つのリソースプロバイダを除いた各リソースプロバイダは、そのリソースマネージャが当該リソースプロバイダの前記各機能を実現可であると判断したときには、当該リソースプロバイダよりも一つ下位の階層に属するリソースプロバイダとの間で論理的に結合したものと設定し、前記最下位の階層から前記最上位の階層までの間に存在する全てのリソースプロバイダに関して各リソースプロバイダ間を論理的に結合させたことにより階層化されたリソースプロバイダ群を形成することによって、前記機能提供装置の機能が提供可能な状態であるリソースマップを構成することを特徴とする、
機能提供装置。
請求項１記載の機能提供装置であって、
各リソースプロバイダは、機能要求に対する機能提供種別の情報を有する手段を更に備えることを特徴とする、
機能提供装置。
請求項１記載の機能提供装置であって、
前記複数のリソースプロバイダが備えるリソースマネージャの機能の各々を含む仮想リソースマネージャを備え、
前記仮想リソースマネージャは、最上位の階層のリソースプロバイダにて受信するリソースリクエストに対応して前記最上位の階層のリソースプロバイダから最下位の階層のリソースプロバイダまで繋がった仮想リソースマップを作成し、
前記仮想のリソースマップと、前記複数のリソースプロバイダによって形成された前記リソースマップとを合成／合算することで、新たなリソースマップを構成する合成／合算手段を更に備えることを特徴とする、
機能提供装置。
請求項１乃至３の何れかに記載の機能提供装置であって、
前記機能提供装置はデジタルテレビ装置であることを特徴とする、
機能提供装置。