JP4251278B2 - 情報処理装置 - Google Patents

Description

本発明は、基本機能をもった複数のコンポーネントを組み合わせて情報の再生や記録等の高機能な処理を実現するとともに、情報処理に必要なリソース（資源）の利用状況を適切に管理するための技術に関する。

情報処理システムにおいて利用可能なリソースには、例えば、ＣＰＵ（中央処理装置）等の演算処理用デバイスに係る動作周波数や、記憶デバイスの記憶域（記憶容量）、供給電圧等が挙げられ、システムの稼動状況に応じた管理が必要とされる。

一般に電子回路システムにおける消費電力は電源電圧やクロック周波数に左右され、例えば、システムの稼動状態や負荷状況が一定ではない場合において、無駄な消費電力が行われないようにするための方策としては、システムが待機状態になったことを検出してクロック周波数を低減させる方法（例えば、特許文献１参照）等が知られている。

特開平１１−２１９２３７号公報

ところで、従来の装置では、指定された情報の処理に必要なリソースについて利用状況を管理してシステム全体の動作設定や制御状態等を動的に変更するといった機能をもたないため、情報処理に必要な性能を充分に発揮させることができなかったり、あるいは消費電力の削減量が充分でない等の問題がある。

例えば、指定された情報の処理に必要なモジュールが事前に明らかである場合には、その稼動状況の予測や把握が容易であるが、指定された情報の処理を行う場合において、複数のコンポーネント（あるいはモジュール）を組み合わせることで該情報の処理機能を実現するような構成形態では、リソースの管理や推定等が困難である（例えば、システム全体の稼動状態を観測しながら各コンポーネントにおいて必要とされる動作周波数やメモリ使用量の割り当て等を変更することが困難であるか、非常に複雑な制御構造等が必要である。）。

そこで、本発明は、基本機能をもった複数のコンポーネントを組み合わせて情報の処理機能を提供することができるように構成された情報処理装置において、システム全体の動作設定等を適切に管理することにより、性能の向上や省電力化等を実現することを課題とする。

本発明は、上記した課題を解決するために、下記に示す構成を備えたものである。

・基本的な処理機能をもった複数のコンポーネントを備え、指定された情報の処理についてアプリケーションから指示を受けた場合に、複数のコンポーネントを組み合わせることで該情報の再生又は記録を含む処理機能を実現すること。

・情報処理に利用可能なリソースの利用状況を管理するシステム管理手段を有すること。

・各コンポーネントは自らが必要とするリソース要求情報を提供する機能を有し、該情報に基いて上記システム管理手段が、上記指定された情報の処理に必要とされるリソースについて設定若しくは変更を行い又は現状を維持すること。
・上記アプリケーションからの要求に従って上記コンポーネントを含む全体の制御を行う制御手段と、利用可能なコンポーネントを管理するとともに、上記制御手段からコンポーネントに係る上記リソース要求情報の問い合わせを受けた場合に、該情報を提供するコンポーネント管理手段を備えること。
・上記リソース要求情報として、演算処理用デバイスの動作周波数又は記憶デバイスのメモリ使用量について各コンポーネントが要求する値又は範囲を示す情報が含まれ、上記複数のコンポーネントの接続関係を記述したグラフ構造データベースを用いて各コンポーネントの結合状態が管理されるとともに、上記リソース要求情報として、上記グラフ構造データベースに基いて各コンポーネント同士が結合されて処理が開始された場合に提供される動的情報と、各コンポーネント同士が結合される前の段階で提供可能な静的情報が使用されること。

従って、本発明によれば、各コンポーネントからのリソース要求情報をシステム管理手段が総合的に判断してシステム全体に係る動作設定等について規定することができ、処理対象とされる情報の種類や仕事の性質等に応じて柔軟なリソース管理を実現することができる。

本発明によれば、コンポーネントのリソース要求情報に基いてシステム全体の動作設定等を適切に管理することで、処理性能の向上や省電力化等を実現することが可能である。そして、アプリケーションからの要求に従ってコンポーネントを含む全体の制御を行う制御手段と、利用可能なコンポーネントを管理して制御手段から上記リソース要求情報の問い合わせに対して該情報を提供するコンポーネント管理手段を設けることによって、コンポーネントに応じたリソース要求情報の提供について詳細な管理が可能である。

また、演算処理用デバイスの動作周波数や記憶デバイスのメモリ使用量をリソース要求情報に含めることで、より正確な要求内容の通知を行える。

各コンポーネント同士が結合されて処理が開始された場合に提供される動的情報及び各コンポーネント同士が結合される前の段階で提供可能な静的情報を導入して、リソース要求情報の利用目的に応じて動的情報と静的情報を使い分けることができる。

そして、各コンポーネントがその動作中に動的情報を決定することで、実際の処理状況に応じて変化する情報をシステム設定に反映させることができる。

複数のコンポーネントの接続関係について管理するための演出処理手段を設け、各コンポーネントの依存関係について管理することで、動作状態等に応じたコンポーネントの制御を詳細に行うことができる。

個々のリソース要求情報を総合した情報に基いて要求内容が許容されるか否かを判断して、システムの設定状態を規定することができ、また、コンポーネントの動作中において動的情報が変更された場合に、該情報をシステムの設定状態に反映させることが可能である。

図１は本発明を適用してＭＰＥＧ（Moving Picture Experts Group）４ファイル等のデータ再生を行う場合の構成例を示したものである。

本発明では、処理目的（本例では動画及び音声の再生）の達成に必要な機能を複数の機能に分離し、それらを個々のコンポーネントとして実装する。つまり、基本的な処理機能をもった複数のコンポーネントを備えており、指定された情報の処理についてアプリケーション（プログラム）から指示を受けた場合に、処理に必要な複数のコンポーネントを組み合わせることで情報の再生や記録等の処理機能を実現するものである。

図１の例は、動画及び音声情報の再生を行う場合の構成例１を示しており（ＭＰＥＧ４プレイヤ）、以下のコンポーネントが用いられている（括弧内の数字は符号を示す。）
・パーサ（２）＝データソースからデータを受けとり、音声データや画像データを弁別して後段の各デコーダに出力する
・ＭＰＥＧ4ビデオデコーダ（３）＝画像データを復号化して後段の色空間コンバータに出力する
・ＡＡＣデコーダ（４）＝音声データを復号化して後段のオーディオレンダラに出力する
・色空間コンバータ（５）＝色空間に係る変換処理を行い、後段のビデオレンダラに出力する
・ビデオレンダラ（６）＝描画処理を行う
・オーディオレンダラ（７）＝音声出力処理を行う。

尚、各コンポーネントについては、例えば、ソフトウェアで構成される場合と、専用のハードウェアで構成される場合が挙げられるが、基本的には下記の３種類に分類される。

（Ｉ）ソースコンポーネント＝他のコンポーネントへの送付機能のみをもつコンポーネントであり、例えば、ディスクからデータを読み出すディスクソースコンポーネントや、ネットワークを通じてデータを受信するネットワークソースコンポーネント等が挙げられる。

（ＩＩ）シンクコンポーネント＝他のコンポーネントからデータを受け取る機能のみをもつコンポーネントであり、例えば、受け取った映像データを画像として表示させるビデオレンダラコンポーネントや、受け取った音声データを音声出力するオーディオレンダラコンポーネント、受け取ったデータをディスク等の記録媒体に書き出して保存するダンプコンポーネント等が挙げられる。

（ＩＩＩ）それ以外のコンポーネント＝他のコンポーネントからデータを受け取り、該データを加工した後で、別のコンポーネントに送付するコンポーネント。

パーサ（Parser）２は、データソース（ディスクソース等を含む。）からのＭＰＥＧ４ファイルを先ず読み、予め決められたフォーマットに従ってデータを読み出して、オーディオ及びビデオのそれぞれのフレーム（Frame）データに仕分けして後段のコンポーネント（３、４）に送付する。尚、その際、各データには最終的に当該フレームのもつ情報が再生されるべき時間データ（時刻）が付与される。また、ＭＰＥＧ４ファイルについては、ディスクソースやネットワークソース等からコンテンツデータを取得する。

動画情報の再生系統については、ＭＰＥＧ4ビデオデコーダ３、色空間コンバータ５、ビデオレンダラ（VideoRenderer）６の各コンポーネントを組み合わせて処理が行われる。尚、これらのうち、表色系の変換処理を行う色空間コンバータ５がハードウェアを用いて構成され、それ以外のコンポーネントについてはソフトウェアにより構成される（色空間コンバータ５についてソフトウェア処理で実現することも可能である。）。

ＭＰＥＧ4ビデオデコーダ３は、パーサ２と色空間コンバータ５との間に位置され、ＭＰＥＧ４形式でエンコードされたデータをパーサ２から受け取ってデコード処理を行い、出力データ（ＹＵＶ４２０のフレームデータ）を色空間コンバータ５に送付する。

色空間コンバータ５は、ＭＰＥＧ4ビデオデコーダ３とビデオレンダラ６との間に位置され、ＭＰＥＧ4ビデオデコーダ３からのＹＵＶ４２０のフレームデータをＲＧＢ５６５のフレームデータに変換した上でビデオレンダラ６に送付する。

ビデオレンダラ６は色空間コンバータ５からのＲＧＢ５６５のフレームデータを受けとって、これに付与された再生時刻情報に合わせてフレームバッファに対してデータを書き込む（描画処理）。尚、その際、基準とする時間は、オーディオレンダラ７が提供する時間情報を基本とする（オーディオレンダラ７のクロック（時計）をマスタークロックとして時刻情報を提供してもらえるように事前に依頼している。）。

音声情報の再生系統については、ＡＡＣ（Advanced Audio Coding）デコーダ４とオーディオレンダラ（AudioRenderer）７の各コンポーネントを組み合わせて処理が行われ、これらはいずれもソフトウェアとして構成される。

ＡＡＣデコーダ４は、パーサ２とオーディオレンダラ７との間に位置され、ＡＡＣエンコードされたデータをパーサ２から受けとってデコード処理を行い、ＰＣＭ（Pulse Code Modulation）音声データを後段のオーディオレンダラ７に送付する。

オーディオレンダラ７は、ＡＡＣデコーダ４からのＰＣＭ音声データを図示しないＤＡＣ（Digital-Analogue Converter）に出力することでディジタル／アナログ変換して、音声出力手段（スピーカやヘッドホン等）を通して音声を出力する。そして、音声と画像とを同期させるために音声情報の出力に合わせて、ビデオレンダラ６に時刻情報を提供する。

このように、各コンポーネントが互に接続されるとともに、ソースコンポーネントから出力されるデータを各コンポーネントが順次に受け取って処理していき、最後にシンクコンポーネントに送付することで動画や音声の再生が行われる。つまり、本例では、２系列のデータに従って各コンポーネントがそれぞれ結合されたグラフ構造を有しており、データソースからパーサ２を経て２系統に分かれ、その一方が動画処理系統とされ、他方が音声処理系統とされる（あるいは、木構造を用いて説明すると、データソースを親木とするパーサ２の下に２つの子木ＭＰＥＧ4ビデオデコーダ３及びＡＡＣデコーダ４が存在し、ＭＰＥＧ4ビデオデコーダ３の子木に色空間コンバータ５、さらにその子木にビデオレンダラ６が存在するとともに、ＡＡＣデコーダ４の子木にオーディオレンダラ７が存在することになる。）。尚、本例では動画及び音声の再生を示したが、例えば、音声の再生だけを行いたい場合には、勿論音声処理系統だけが形成されるようにアプリケーションから指示すれば良い。

次に、本発明に係るシステム構成について説明する。

図２は情報処理装置８の構成を概念的に示したものであり、アプリケーション９からシステムの本体部（コア）に対して指定された情報の処理要求が行われる。尚、アプリケーション９は、ユーザ操作等に応じて処理を行うが、処理に必要なライブラリ等も含まれる。

本体部は、システム管理手段、演出処理手段、コンポーネント管理手段を備えている。

システム管理手段（以下、「システムマネージャ」という。）は、システムクロック周波数やメモリ量、使用デバイス、電源電圧といった、利用可能なリソースについて管理するものであり、また、演出処理手段（以下、「プレイヤ」という。）は、複数のコンポーネントの接続関係をグラフ構造に従って管理する。そして、コンポーネント管理手段（以下、「コンポーネントマネージャ」という。）は、各コンポーネントに係る情報（リソース要求情報）を提供する役目をもっている。尚、リソース要求情報については後で詳述するように、固定的な情報に限らず、状況に応じて動的に設定可能な情報が含まれる（例えば、図１のＭＰＥＧ4ビデオデコーダ３は、画像サイズやフレームレート等に基いてリソース要求情報を決定することが可能である。）。

また、図２に示すグラフ構造は、図１の構成に対応したものであり、「Ｃｉ」（ｉ＝２乃至７）を○印で囲んで示すものが各コンポーネントを表し、「ｉ」がその符号を示している。

図３はシステム構成を例示したブロック図であり、下記に示すモジュールを用いて構成される。

・（マルチメディア）アプリケーション
ソフトウェア階層の最上位に位置するアプリケーション９は、ユーザインターフェイス（ＵＩ）を担当するが、自らはマルチメディアに関する処理（描画処理や音声処理等）を行う機能をもたず、後述するコントローラに対して要求内容を指示する。また、アプリケーション９は、例えば、ライブラリ等を通じてコンテンツデータの指定、再生、停止等の操作について指示するが、上記したコンポーネントには何ら関知しない。尚、ライブラリはアプリケーション９からの要求に従ってコンポーネントの選択、ロード、接続等を行うものであり、その上位レイヤに対して固有の機能を隠蔽する役目をもつ。また、コンテンツ再生や記録等に先だって１つ以上のプレイヤを生成させる必要がある。

・コントローラ（制御手段）
コントローラ１０は、アプリケーション９からの要求に従ってコンポーネントを含むシステム全体の制御を行うものであり、他のモジュールを用いて所望の動作制御を行うが、データ処理は行わない。また、アプリケーションが複数存在する場合でも１つのコントローラ１０によって制御処理が行われる（尚、図には、説明の簡単化を考慮してアプリケーション、プレイヤの数を単数として示している。）。

・システムマネージャ
システムマネージャ１１は、コンテンツデータ等の情報処理において利用可能なリソースについて利用状況を管理するものである。つまり、システムリソース（システムの稼動に必要な環境において利用可能な資源）に関して、現在の利用状況を管理する。尚、リソースには、例えば、ＣＰＵ等の演算処理デバイスの動作周波数、メモリ使用量、使用デバイス等が挙げられ、それらのリソース要求情報については、値又は範囲で記述される（後で詳述する。）。

システムマネージャ１１は、複数のコンポーネントの接続関係を表すグラフ構造データベースの生成、削除、変更、更新等がコントローラ１０を経由して通知されると、関連情報を更新したり、必要に応じてハードウェアの設定変更（動作周波数等）を行う。また、上記した各コンポーネントは自らが必要とするリソース要求情報（後述する。）を提供する機能を有しており、該情報に基いてシステムマネージャ１１は、指定された情報処理に必要とされるリソースについて設定若しくは変更を行うか、あるいはその必要がない場合には現状の設定を維持する。例えば、装置の消費電力を削減する場合等に、ハードウェアの設定を変更して、システムクロックの周波数を低くする等の処理が行われる。

管理項目を例示すると、下記のようになる。

・使用デバイス
色空間コンバータ ＝＞Id:1234 Status:free or in use
フレームバッファ ＝＞Id:3456 Status:free or in use
ＤＡＣ(D/A Converter)＝＞Id:4567 Status:free or in use
ＡＤＣ(A/D Converter)＝＞Id:5678 Status:free or in use
・メモリ
全容量：Ｓバイト Status: min ＳLバイト max ＳHバイト
・ＣＰＵ
最高許容周波数：ｆsヘルツ Status: min ｆLヘルツ max ｆHヘルツ。

尚、上記「Id」はデバイスに付与された識別番号を示し、「Status」の値はfree （使用可）、in use（使用中）を示す。また、メモリ使用量については、下限値ＳL及び上限ＳHに示す範囲内で設定され（例えば、Ｓ＝１６Ｍ（メガ）バイトにおいて、ある状態での「Status」の示す範囲が１Ｍ〜１．５Ｍバイト等）、ＣＰＵの周波数については下限値ｆL及び上限ｆHに示す範囲内で設定される（例えば、ｆｓ＝２００Ｍ（メガ）ヘルツにおいて、ある状態での「Status」の示す範囲が１００Ｍ〜１５０Ｍヘルツ等）。

・グラフ構造ＤＢ（データベース）
複数のコンポーネントを組み合わせて、特定の機能を実現するためには、例えば、図１に例示したような各コンポーネントの接続関係が正しく確立されることが必要である。つまり、複数のコンポーネントの接続関係や依存関係を記述したグラフ構造ＤＢ１２を用いて各コンポーネントの結合状態を管理することが好ましい。

図１に示したコンポーネントのグラフ構造について、データベースエントリを記述言語によるタグ・フォーマットで例示すると下記のようになる（各記述子の左端に行番号を付して示す。尚、「＊」部は説明用のコメントである。）。
1：<GRAPH "MP4Player" > ＊グラフ構造定義の開始＊
2： <COMPONENTS> ＊コンポーネント定義の開始＊
（ここに各コンポーネントについて記述する）
3： </COMPONENTS> ＊コンポーネント定義の終了＊
4： <CONNECTIONS> ＊コンポーネントの接続関係に係る定義開始＊
（ここにコンポーネント同士の接続関係について記述する）
5： </CONNECTIONS> ＊コンポーネントの接続関係に係る定義終了＊
6：</GRAPH> ＊グラフ構造定義の終了＊
コンポーネント定義例を以下に示す。
<COMPONENTS> ＊コンポーネント定義開始の記述子＊
<COMPONENT> ＊パーサについて＊
<NAME> Parser </NAME>
<ID> 123 </ID>
</COMPONENT>
<COMPONENT> ＊ＭＰＥＧ4ビデオデコーダについて＊
<NAME> MPEG4VideoDecoder </NAME>
<ID> 234 </ID>
</COMPONENT>
<COMPONENT> ＊ＡＡＣデコーダについて＊
<NAME> AACDecoder </NAME>
<ID> 345 </ID>
</COMPONENT>
(途中省略)
<COMPONENT> ＊オーディオレンダラについて＊
<NAME> AudioRenderer </NAME>
<ID> 789 </ID>
</COMPONENT>
</COMPONENTS>
尚、タグ<NAME>と </NAME>との間にコンポーネントの名称が記述され、タグ<ID>と </ID>との間にコンポーネントに付与される識別番号が記述される。

また、コンポーネントの接続関係についての定義例を以下に示す。
<CONNECTIONS>
<CONNECTION> ＊パーサからＭＰＥＧ4ビデオデコーダへ＊
<FROM> Parser :0 </FROM>
<TO> MPEG4VideoDecoder:0 </TO>
</CONNECTION>
<CONNECTION> ＊ＭＰＥＧ4ビデオデコーダから色空間コンバータへ＊
<FROM> MPEG4VideoDecoder:0</FROM>
<TO> ColorSpaceConverter:0 </TO>
</CONNECTION>
<CONNECTION> ＊色空間コンバータからビデオレンダラへ＊
<FROM> ColorSpaceConverter:0 </FROM>
<TO> VideoRenderer:0 </TO>
</CONNECTION>
<CONNECTION> ＊パーサからＡＡＣデコーダへ＊
<FROM> Parser :1 </FROM>
<TO> AACDecoder:0 </TO>
</CONNECTION>
<CONNECTION> ＊ＡＡＣデコーダからオーディオレンダラへ＊
<FROM> AACDecoder:0</FROM>
<TO> AudioRenderer:0 </TO>
</CONNECTION>
</CONNECTIONS>
尚、タグ<FROM> と</FROM>の間に出力側となるコンポーネント名称が記述され、タグ <TO> と</TO>との間に入力側となるコンポーネント名称が記述される。また、本例では動画の画像処理系統と音声処理系統の２系統が存在し、パーサの出力段で各系統に分岐するので、パーサには「：０」、「：１」を付けることで系統の違いを区別している（図２参照。各コンポーネントを示すノードに付した「０」や「１」の数字はポート番号を示す。）。また、本例ではグラフ構造の記述に係るデータ構造について、階層的構造を記述し易い方法をとっているが、これに限らず各種のデータ構造（連結リスト構造や木構造等）を用いることが可能である。

・コンポーネントマネージャ
コンポーネントマネージャ１３は、システムが利用可能なコンポーネントを管理するものであり、コントローラ１０が、対象となるコンポーネントのリソース要求情報を取得したい場合に、その問い合わせに答えて必要とする情報を提供する。

・コンポーネント
各コンポーネント１４は、コンテンツデータの再生や記録等のために、メディアやネットワークからのロード、データ変換、デバイスへの出力といった特定の機能を有する。具体例については図１で説明した通りであるが、ここでさらに説明を加えると、システムには予め複数のコンポーネントが登録されていて、取り扱うコンテンツデータ等に合わせて必要なコンポーネントを組み合わせることで目的の機能を実現することができる。また、コンポーネントはシステムに初めから実装される場合に他、プラグインモジュールとして追加が可能であり、これによってシステムを拡張することが可能である。

各コンポーネント１４は、他のモジュールからの要求、あるいは自分自身の状態が変化した場合に、自らが必要とするリソース要求情報を提供する機能をもつ。ここで、「リソース要求情報」とは、モジュールがリソースについて要求する情報を意味し、「静的リソース要求情報」と「動的リソース要求情報」が挙げられる。後者は、グラフ構造ＤＢ１２に基いて各コンポーネント同士が結合されて処理が開始された場合に提供される動的情報であり、前者は各コンポーネント同士が結合される前の段階で提供可能な静的情報である。

例えば、コンポーネントが提供する「静的リソース要求情報」とは、稼動状況の如何に関係なくコンポーネントがとり得るリソースの情報（値や範囲）を意味する。また、コンポーネントが提供する「動的リソース要求情報」とは、コンポーネントが特定の環境下で稼動している場合にとり得るリソースの情報（値や範囲）を意味し、動作中のコンポーネントが現在の処理状況に応じてリソース要求情報を決定する。

「静的」又は「動的」に如何に関わらず、リソース要求情報にはシステムリソースに係る各種の要求を含めることができるが、以下の説明では、使用デバイス（色空間コンバータやフレームメモリ、ＤＡＣ等）、必要なメモリ使用量（値又は範囲）、ＣＰＵに与える負荷（クロックの周波数範囲）を用いることにする。

図１に示した各コンポ−ネントについて、それぞれの静的リソース要求情報及び動的リソース要求情報を例示すると下記のようになる。
＜ＭＰＥＧ4ビデオデコーダ＞
［静的リソース要求情報］
使用デバイス：なし
メモリ量 ：min＝３００ｋバイト max＝９００ｋバイト
ＣＰＵ ：min＝ ３０Ｍヘルツ max＝ ６０Ｍヘルツ
［動的リソース要求情報］
メモリ量 ：９００ｋバイト
ＣＰＵ ：min＝５５Ｍヘルツ max＝６０Ｍヘルツ

＜ＡＡＣデコーダ＞
［静的リソース要求情報］
使用デバイス：なし
メモリ量 ：min＝８０ｋバイト max＝１００ｋバイト
ＣＰＵ ：min＝１０Ｍヘルツ max＝ ３０Ｍヘルツ
［動的リソース要求情報］
メモリ量 ：８０ｋバイト
ＣＰＵ ：min＝５Ｍヘルツ max＝１０Ｍヘルツ

＜パーサ＞
［静的リソース要求情報］
使用デバイス：なし
メモリ量 ：min＝８０ｋバイト max＝８０ｋバイト
ＣＰＵ ：min＝ ５Ｍヘルツ max＝１０Ｍヘルツ
［動的リソース要求情報］
メモリ量 ：min＝８０ｋバイト max＝８０ｋバイト
ＣＰＵ ：min＝１０Ｍヘルツ max＝１０Ｍヘルツ

＜色空間コンバータ＞
［静的リソース要求情報］
使用デバイス：ID=1234（色空間変換用回路）
メモリ量 ：min＝８０ｋバイト max＝１００ｋバイト
ＣＰＵ ：min＝１０Ｍヘルツ max＝ ３０Ｍヘルツ
［動的リソース要求情報］
メモリ量 ：８０ｋバイト
ＣＰＵ ：min＝５Ｍヘルツ max＝２０Ｍヘルツ

＜ビデオレンダラ＞
［静的リソース要求情報］
使用デバイス：ID=3456（フレームバッファ）
メモリ量 ：min＝３００ｋバイト max＝６００ｋバイト
ＣＰＵ ：min＝ ５Ｍヘルツ max＝ ２０Ｍヘルツ
［動的リソース要求情報］
メモリ量 ：min＝６００ｋバイト max＝６００ｋバイト
ＣＰＵ ：min＝１０Ｍヘルツ max＝ ２０Ｍヘルツ

＜オーディオレンダラ＞
［静的リソース要求情報］
使用デバイス：ID=4567（ＤＡＣ）
メモリ量 ：min＝１００ｋバイト max＝２００ｋバイト
ＣＰＵ ：min＝ ５Ｍヘルツ max＝ ２０Ｍヘルツ
［動的リソース要求情報］
メモリ量 ：min＝１００ｋバイト max＝１００ｋバイト
ＣＰＵ ：min＝ １０Ｍヘルツ max＝１５Ｍヘルツ。

上記リソース要求情報として、使用デバイスについてはその使用の要求情報が含まれ、「ID」は使用デバイスに付与された識別番号を表している。また、ＣＰＵ等の演算処理用デバイスの動作周波数や、記憶デバイスのメモリ容量（使用量）については、コンポーネント毎にそれらの値又は範囲（上下限）を示す要求情報が含まれ、「min」が最低値（下限）を示し、「max」が最高値（上限）を示している。尚、動的リソース要求情報の内容については、コンポーネントの実際の動作状況に応じて変化する。

コンポーネント１４は、上記したグラフ構造ＤＢ１２に従って実際のグラフとして接続関係が確立される前、つまり、各コンポーネントを実際に組み合わせた構成以前において、コンポーネントマネージャ１３を介して静的リソース要求情報を提供することができるが、動的リソース要求情報については、各コンポーネントを実際に組み合わせてその動作を開始した後にはじめて提供が可能となる。

尚、コンポーネントは後述のプレイヤに登録する必要がある。

コンポーネント間のデータの受け渡しについて、簡単に説明すると、コンポーネントの内部には、ポート（バッファ送受のための窓口となるオブジェクト）が存在し、例えば、バッファを他のコンポーネントに送るためには、１つ以上のポートをもつ必要がある。尚、「バッファ」とは、ポート間で送受されるデータのコンテナ（入れ物）となるオブジェクトを意味し、ポートを介してあるコンポーネントから別のコンポーネントに送付される（具体的には、バッファオブジェクトのアドレスが対応するポートに通知される。）。コンポーネントの種類については前記したが、ソースコンポーネントとは、バッファを送付する機能のみをもち、シンクコンポーネントとはバッファを受け取る機能のみをもつコンポーネントである。また、それら以外のコンポーネントとは、他のコンポーネントからバッファを受け取り、そのデータを加工した後、バッファを別のコンポーネントに送付することができるコンポーネントである。

この他、コンポーネントによっては、計時用のクロック（時計）をもつことで、該クロックをマスタークロックとして他のコンポーネントとの間で同期取りが可能である。つまり、クロック（複数のコンポーネント間で処理を同期させるためのオブジェクト）を内部にもつコンポーネントでは、コンテンツの再生状況等に応じてクロックの時間を進めることができる。マスタークロックと同期をとる必要がある場合に、クロックに対して特定の時刻になった時点、あるいは一定時間が経過する度に、時刻や時間情報を通知するように依頼することができる。例えば、オーディオシンクコンポーネント（図１のオーディオレンダラ７）がマスタークロックを提供する場合に、ビデオシンクコンポーネント（図１のビデオレンダラ６）は特定の時刻に表示すべき映像データを受け取ると、その時刻になったことを知らせてもらえるようにオーディオシンクコンポーネントに依頼をしておくことができ（図１の破線矢印を参照。）、これによって、音声データの再生と同期して映像データの再生を行うことができる。

・プレイヤ
プレイヤ１５はコンポーネント１４の演出について処理を行うものであり、コンテンツデータ等の再生を行う場合には字義通りデータ再生処理を統括するが、グラフ構造ＤＢ１２に従ったコンポーネントの組み合わせに応じて、データ記録やデータ変換等、各種機能に対応したプレイヤが生成される。

プレイヤ１５は、例えば、コンテンツデータの再生や記録等の機能を実現するため、グラフ構造ＤＢ１２に従って構築される複数のコンポーネントの接続関係について管理しており、各コンポーネント１４はプレイヤに登録されることで管理される。

アプリケーション９は、コントローラ１０を経由してプレイヤ１５にリクエスト（コマンド）を発行することにより、コンポーネント１４を制御することができる。例えば、コンテンツ再生中にアプリケーション９がプレイヤ１５に対して停止（Ｓｔｏｐ）要求を出した場合、プレイヤは事前に解析されているコンポーネント間の依存関係に従って、適切な順番で各コンポーネントの動作を終了させる。

プレイヤ１５に関連するリソース要求情報については、静的、初期化時、動的の３種類に区分され、「静的プレイヤリソース要求情報」は、コンポーネントマネージャ１３が生成し、「初期化時プレイヤリソース要求情報」及び「動的プレイヤリソース要求情報」をプレイヤ１５が生成する。

各リソース要求情報の意味は下記に示す通りである。

（ａ）静的プレイヤリソース要求情報
グラフ構造ＤＢに従うコンポーネントの接続関係が確立される以前のリソース要求情報、つまり、複数のコンポーネントがグラフ構造をもって構成される前に得ることができる、プレイヤの稼動に必要なリソースの要求情報である。例えば、既に幾つかのアプリケーションが起動されてそれらが動作している場合に、指定されたプレイヤを新たに動作させることができるか否かを、実際にプレイヤを構成することなく、本リソース要求情報に基いて判定することができる。尚、静的プレイヤリソース要求情報は、コンポーネント１４が提供する静的リソース要求情報に基いて決定される。

（ｂ）初期化時プレイヤリソース要求情報
複数のコンポーネントがグラフ構造をもって実際に構成され、処理すべきコンテンツデータ等が指定された後に得ることが可能なリソース要求情報（プレイヤの稼動に必要な条件に関する情報）である。例えば、コンテンツが指定されることにより、プレイヤに登録された各コンポーネントについて当該コンテンツの処理（再生等）に必要な情報が、静的プレイヤリソース要求情報に比して、より詳細に得られる。本リソース要求情報はシステムマネージャ１１に通知され、これによってシステムが現在稼動中のアプリケーション等を動作させるのに必要とされる情報を管理するために用いられる。尚、初期化時プレイヤリソース要求情報は、登録されているコンポーネントの初期化が終了した直後の状態において該コンポーネントが提供する動的リソース要求情報に基いて決定される。

（ｃ）動的プレイヤリソース要求情報
複数のコンポーネントがグラフ構造をもって実際に構成され、処理すべきコンテンツデータ等が指定された後で該データの処理（再生等）が行われている場合に得ることが可能なリソース要求情報（プレイヤの実稼動に必要な条件に関する情報）である。尚、動的プレイヤリソース要求情報は、各コンポーネントの稼動中に提供される動的リソース要求情報に基いて決定される。つまり、動作中のコンポーネントは現在の処理状況に応じて動的リソース要求情報を決定するので、該情報に応じて動的プレイヤリソース要求情報の内容が変化する。

上記したリソース要求情報の関係について、下記に示す記号を用いて説明する。

・「Ｒｃ（ｉ）」＝コンポーネントのリソース要求情報（括弧内の自然数変数「ｉ」はコンポーネントを区別するための番号を示す。）
・「Ｒｐ（ｊ）」＝プレイヤのリソース要求情報（括弧内の自然数変数「ｊ」はプレイヤを区別するための番号を示す。）
・「Ｒｓ」＝システムリソース要求情報（全てのリソース要求情報を総合した情報であり、例えば、システムマネージャ１１が該情報の算出、設定を行う。）。尚、リソース要求情報について静的、動的の違いを区別する場合には、例えば、記号の前に「Ｓ＿」（Static）、「Ｄ＿」（Dynamic）を付ければ良い。

先ず、プレイヤ番号ｊのリソース要求情報Ｒｐ（ｊ）については、関数「Ｆｐ（）」を用いて、下式のように表すことができる。

Ｒｐ（ｊ）＝Ｆｐ（Ｒｃ（１）,Ｒｃ（２）,…,Ｒｃ（ｎ）） −（１）式
関数「Ｆｐ（）」は、コンポーネントのリソース要求情報に基いてプレイヤのリソース要求情報を導出するための算出関数であり、ｎ個のＲｃに基いてＲｐが算出される。

また、Ｒｓについては、関数「Ｆｓ（）」を用いて、下式のように表すことができる。

Ｒｓ＝Ｆｓ（Ｒｐ（１）,Ｒｐ（２）,…,Ｒｐ（ｍ）） −（２）式
関数「Ｆｓ（）」は、プレイヤのリソース要求情報に基いてシステム全体のリソース要求情報を導出するための算出関数であり、ｍ個のＲｐに基いてＲｓが算出される。

このように、各コンポーネントのリソース要求情報を総合することによってシステム全体のリソースに関する要求情報が算定される。尚、実際のリソース要求情報は、上記した関係式に基いて、リソースの種類や、範囲（下限値および上限値）、設定値等の算出対象について個別に定義された複雑な式から算出されるので、以下ではその要点だけを簡単に説明する。

先ず、使用デバイスについてはその使用の有無が区別され、下式のように、必要とされるデバイス「Ｒｉ」（ｉ＝１、２、…）について和集合（∪）をとることで算定できる。

Ｆｐ（Ｒ１,Ｒ２,…,Ｒｎ）＝Ｒ１ ∪ Ｒ２ ∪…∪ Ｒｎ
Ｆｓ（Ｒ１,Ｒ２,…,Ｒｍ）＝Ｒ１ ∪ Ｒ２ ∪…∪ Ｒｍ
例えば、使用デバイスが３つある場合に、１番目と３番目のデバイスを使用する場合には、「Ｒ１ ∪ Ｒ３」である。

次にＣＰＵのクロック周波数については、上記「Ｒｉ」を要求される周波数とみなして、下式のように算出すれば良い。

・Ｒ１〜Ｒｎに「undef」(未定義)が含まれる場合
Ｆｐ（Ｒ１,Ｒ２,…,Ｒｎ）＝ undef
・Ｒ１〜Ｒｎに「undef」が含まれない場合
Ｆｐ（Ｒ１,Ｒ２,…,Ｒｎ）＝ Ｋｐ・（Ｒ１＋Ｒ２＋… ＋Ｒｎ）

・Ｒ１〜Ｒｍに「undef」が含まれる場合
Ｆｓ（Ｒ１,Ｒ２,…,Ｒｍ）＝ undef
・Ｒ１〜Ｒｍに「undef」が含まれない場合
Ｆｓ（Ｒ１,Ｒ２,…,Ｒｍ）＝ Ｋｓ・（Ｒ１＋Ｒ２＋… ＋Ｒｍ）
尚、「Ｋｐ」はプレイヤのＣＰＵ負荷算出係数を示しており、プレイヤが複数のコンポーネントを動作させる場合のキャッシュメモリに対する影響等を考慮して係数値を調整して規定する。また、「Ｋｓ」は、システムのＣＰＵ負荷算出係数を示しており、システムが複数のプレイヤを動作させる場合のキャッシュメモリに対する影響等を考慮して係数値を調整して規定する（ＫｐとＫｓの値は一般に異なるが、同じ値でも良い。）。

このような計算は、クロック周波数の最小値及び最大値についてそれぞれに行われ、各リソース要求情報の示す周波数が未定義でない限り、各周波数の加算値に対してＣＰＵ負荷算出係数を乗じた値が算出される。

尚、動的及び静的の相違については、下位の静的情報から上位の静的情報が算出されること及び下位の動的情報から上位の動的情報が算出されることに注意して、両者を区別する場合には、上記したＦｐ、Ｆｓの前に「Ｓ＿」又は「Ｄ＿」を付ければ良い。また、静的情報及び動的情報のそれぞれについてＫｐ、Ｋｓの値を規定することが必要である。

次にメモリ使用量については、上記の説明において形式的に「Ｒｉ」を使用量（必要なメモリサイズ）とみなし、かつＫｐ＝Ｋｓ＝１とした下式を用いて算出すれば良い。

・Ｒ１〜Ｒｎに「undef」が含まれる場合
Ｆｐ（Ｒ１,Ｒ２,…,Ｒｎ）＝ undef
・Ｒ１〜Ｒｎに「undef」が含まれない場合
Ｆｐ（Ｒ１,Ｒ２,…,Ｒｎ）＝ Ｒ１＋Ｒ２＋… ＋Ｒｎ

・Ｒ１〜Ｒｍに「undef」が含まれる場合
Ｆｓ（Ｒ１,Ｒ２,…,Ｒｍ）＝ undef
・Ｒ１〜Ｒｍに「undef」が含まれない場合
Ｆｓ（Ｒ１,Ｒ２,…,Ｒｍ）＝ Ｒ１＋Ｒ２＋… ＋Ｒｍ
このような計算は、メモリの最小使用量及び最大使用量についてそれぞれに行われ、各リソース要求情報の示す使用量が未定義でない限り、加算値（総和）が算出される。尚、動的及び静的を区別する場合には、上記と同様にＦｐ、Ｆｓの前に「Ｓ＿」又は「Ｄ＿」を付ければ良い。

上記のように、コンポーネント１４のリソース要求情報Ｒｃからプレイヤ１５のリソース要求情報Ｒｐが算出され、さらにシステムのリソース要求情報Ｒｓが算出される。そして、該情報Ｒｓに示されるリソースの要求内容が許容される場合には、該要求内容に従ってシステムマネージャ１１はリソースについてのシステム設定や変更を行うが、リソースの要求内容が許容されない場合には、その旨をコントローラ１０に通知する。例えば、対象となるコンテンツデータの種類によっては、その処理が比較的に簡単で負担の少ない場合と、処理が重くて時間がかかる場合があるため、現在の状況や各種の要因を充分に見極めた上でリソース要求情報Ｒｓを算定し、システムの設定状況を定期的に又は一定の条件下で見直すことが好ましい。

本発明の適用に際し、リソース要求情報Ｒｃの決定については如何なる方法を用いても良いが、コンポーネントの実装形態を充分に考慮することが好ましい。例えば、ＣＰＵのクロック周波数を決定する場合に、テスト用のコンテンツデータを用意し、最もＣＰＵ負荷が軽いと想定されるコンテンツ及び最もＣＰＵ負荷が重いと想定されるコンテンツについて、データを実際に再生し又は記録して、所定時間毎のプロファイル情報を取得してクロック周波数の最小値及び最大値を決定することができる。

尚、上記した算出関数はあくまで一例にすぎないものであって、本発明の適用において特定の算出関数や計算方法に限定されないことは勿論である。

次に、図３のシステム構成の動作について、アプリケーションによる動画や音声の再生処理を例にして説明する。

（１）アプリケーションの起動及び動作
（２）初期化処理
（３）再生処理
（４）終了処理。

先ず、（１）において、ユーザ操作によりアプリケーション９が起動され、動画や音声の再生処理について指示されると、（２）では、アプリケーション９からの指令をコントローラ１０が受けて初期化処理（プレイヤの生成を含む。）が行われる。

実際にプレイヤが動作されるまでの手順は、下記ステップ（Ｓ１）乃至（Ｓ１４）に示す通りである。

（Ｓ１）アプリケーション９がコントローラ１０に対してプレイヤの種類（ＭＰＥＧ４ファイルの動画再生等）を指定して、プレイヤ１５の生成を指示する
（Ｓ２）コントローラ１０が、グラフ構造ＤＢ１２からプレイヤ１５の情報を取得する
（Ｓ３）コントローラ１０が、コンポーネントマネージャ１３に対してプレイヤ１５の情報を指定し、静的プレイヤリソース要求情報の生成を依頼する
（Ｓ４）コンポーネントマネージャ１３は、プレイヤ１５に登録された各コンポーネントから静的リソース要求情報を取得し、上記算出関数を用いて静的プレイヤリソース要求情報を計算して、その計算結果をコントローラ１０に送る
（Ｓ５）コントローラ１０は、コンポーネントマネージャ１３から受け取った静的プレイヤリソース要求情報にて要求されるリソースが現在の状況下で取得可能であるか否かをシステムマネージャ１１に問い合わせる
（Ｓ６）システムマネージャ１１はリソース要求が許容されるか否かを判断して、その結果をコントローラ１０に返答する
（Ｓ７）システムマネージャ１１からの返答を受けて、リソース要求が許容されない（リソース取得不可能）と判断された場合に、コントローラ１０はアプリケーション９にその旨をエラー情報として返送して（Ｓ１）に戻る
（Ｓ８）システムマネージャ１１からの返答を受けて、リソース要求が許容される（リソース取得可能）と判断された場合には、コントローラ１０が、コンポーネントマネージャ１３に対して実際にプレイヤ１５の生成を依頼する
（Ｓ９）プレイヤ１５が生成されると、コントローラ１０は該プレイヤに対して、コンテンツデータ等、プレイヤ１５の動作に必要とされる情報を供与する
（Ｓ１０）プレイヤ１５は、与えられた情報に基いて各コンポーネント１４を初期化する
（Ｓ１１）プレイヤ１５は、各コンポーネントから動的リソース要求情報を取得し、収集された情報に基いて初期化時プレイヤリソース要求情報を算出する
（Ｓ１２）コントローラ１０は、プレイヤ１５から初期化時プレイヤリソース要求情報を取得して、該情報をシステムマネージャ１１に通知する
（Ｓ１３）システムマネージャ１１は、初期化時プレイヤリソース要求情報に基いてシステムリソース要求情報（Ｒｓ）を更新するとともに、必要に応じてシステムリソースについて設定変更を行う
（Ｓ１４）コントローラ１０は、アプリケーション９に対してプレイヤ１５が正常に生成されたことを通知する。

尚、（Ｓ１１）の初期化時プレイヤリソース要求情報は、登録されているコンポーネントの初期化が終了した直後の状態における該コンポーネントの動的リソース要求情報に基いて決定されるので、この場合には、上記した算出関数Ｆｐ（Ｒｃ（１）,Ｒｃ（２）,…,Ｒｃ（ｎ））において、Ｒｃ（１）乃至Ｒｃ（ｎ）は初期化直後の動的リソース要求情報を表す。

また、（Ｓ１３）においては、例えば、ＣＰＵのクロック周波数がシステムの負荷状態に応じて動的に変更され、その変更範囲についてはシステムマネージャ１１により制御することができる。従って、クロック周波数の下限値及び上限値の設定変更を適時に行うことにより、動画や音声等のコンテンツデータの再生や記録の機能について実行環境を保証したり、あるいは、クロック周波数を抑えて消費電力を低減することができる。

プレイヤ１５が生成されると、上記（３）の再生処理に必要な情報が該プレイヤに与えられて動画や音声の再生を行うことができる。

再生、一時停止、停止等の操作については、以下のステップ（Ｓ２１）乃至（Ｓ２４）のように処理される。

（Ｓ２１）アプリケーション９がユーザからの要求に従って、コントローラ１０に再生等の操作を指示する
（Ｓ２２）コントローラ１０がプレイヤ１５に対して、再生等の指示を出す
（Ｓ２３）プレイヤ１５が、登録されている各コンポーネント１４に対して操作指令を出す
（Ｓ２４）各コンポーネントが指定された操作に対応した処理を開始する。

尚、プレイヤ１５の状態には、例えば、動作中（Running）、一時停止（Paused）、停止（Stopped）、検索中（seeking）、早送り（FF）、戻し（REW）等が挙げられ、登録されているコンポーネントの状態はプレイヤの状態と常に一致する。また、プレイヤやコンポーネントの状態についてアプリケーション等の上位レイヤからの指示無しに状態遷移が行われることはない。

（Ｓ２４）では、プレイヤに登録された各コンポーネントの依存関係に従って処理が行われ、例えば、再生処理については、各コンポーネントが協働して動作することで実現される。また、動作中（Running）のコンポーネントが停止（Stopped）状態等に遷移する際には、適切な順番でプレイヤから各コンポーネントに指示を出すことにより、デッドロック等の発生を排除する。

プレイヤ１５の動作状態において、コントローラ１０は、現在のシステム設定状態が実際の稼動状態に合致し又は適合しているか否かを確認するため、一定時間毎に、例えば、下記のステップ（Ｓ３１）乃至（Ｓ３４）を実行し、システムの動的情報（動的プレイヤリソース要求情報、動的システムリソース要求情報）を更新する。

（Ｓ３１）コントローラ１０は、各プレイヤ１５に対して動的プレイヤリソース要求情報を要求する
（Ｓ３２）プレイヤ１５は各コンポーネント１４から動的リソース要求情報を取得し、動的プレイヤリソース要求情報を算出する
（Ｓ３３）コントローラ１０は、各プレイヤから動的プレイヤリソース要求情報を取得して、それらをシステムマネージャ１１に通知する
（Ｓ３４）システムマネージャ１１は、動的プレイヤリソース要求情報に基いてシステムリソース要求情報を更新し、かつ、必要であればシステム設定を変更する。

各コンポーネント１４は、自身の持つリソース要求情報が更新されたことをプレイヤに対して自主的に通知することができ、この場合には、動的リソース要求情報に伴って動的プレイヤリソース要求情報が更新されるので、プレイヤは自身の情報が更新されたことをコントローラ１０に通知する。コントローラ１０はこの通知を受けて上記（Ｓ３１）乃至（Ｓ３４）の処理を実行する。

このように、コンポーネントからプレイヤに対して、その動作中に動的リソース要求情報が変更されたことが通知されたときには、該情報に応じて動的プレイヤリソース要求情報Ｒｐが更新され、さらに動的プレイヤリソース要求情報を総合することによってシステム全体のリソース要求情報Ｒｓが算定される。そして、該情報Ｒｓの示す要求内容が許容される場合には、該要求内容に従ってシステムマネージャ１１がリソースについての設定又は変更を行うが、該情報Ｒｓの示す要求内容が許容されない場合には、現在の設定状態が維持される。

コンテンツデータの再生処理が終ると、上記（４）の終了処理において、プレイヤ１５からコントローラ１０を介してアプリケーション９にその旨が通知される。

上記に説明した構成によれば、例えば、下記に示す利点が得られる。

・動画像や音声の記録や再生といったマルチメディア機能の実現において、アプリケーションが、特定のフォーマットやデバイス等に依存した個々的な処理を行う必要がないこと
・複数のコンポーネントを組み合わせることでコンテンツデータ等について各種の処理機能を提供することができ、また、コンポーネントをプラグインモジュールとして追加することにより、新たなデバイスやフォーマット等のサポートにおいてシステムの拡張性に優れており、設計上の柔軟性が高いこと。

・大掛かりなシステム構成を要しないので、例えば、小型コンピュータや、ＰＤＡ（Personal Digital Assistance）、移動体通信端末装置、映像機器をはじめとする携帯型機器（小規模な装置）に組み込んで利用するのに適していること、そして、必要なメモリ容量が小さくて済み、システムやオペレーティングシステムへの要求事項が少ないこと
・コンポーネントの動的リソース要求情報を反映したシステム設定の変更により、動作中のアプリケーションの実行環境を保証したり、必要に応じて消費電力を低下させて省電力効果を得ることができること（特にバッテリ駆動の装置において有効である。）
・コンポーネントの静的リソース要求情報に基いて、コンポーネントを実際に動作させる前に必要なリソースの要求内容を把握できること（例えば、要求内容が通らない場合には、その旨を、コンポーネントの接続関係を確立させる以前にアプリケーションに通知できる。）。

本発明に係る動画及び音声情報の再生に係る構成例を示すブロック図である。 本発明に係るシステム構成の概念図である。 本発明のシステム構成を例示したブロック図である。

符号の説明

８…情報処理装置、９…アプリケーション、１０…制御手段、１１…システム管理手段、１３…コンポーネント管理手段、１４…コンポーネント、１５…演出処理手段

Claims (4)

1. 基本的な処理機能をもった複数のコンポーネントを備え、指定された情報の処理についてアプリケーションから指示を受けた場合に、複数のコンポーネントを組み合わせることで該情報の再生又は記録を含む処理機能を実現するとともに、情報処理に利用可能なリソースについて利用状況を管理するシステム管理手段を有する情報処理装置であって、
   上記した各コンポーネントは自らが必要とするリソース要求情報を提供する機能を有し、
   該情報に基いて上記システム管理手段が、上記指定された情報の処理に必要とされるリソースについて設定若しくは変更を行い又は現状を維持し、
   上記アプリケーションからの要求に従って上記コンポーネントを含む全体の制御を行う制御手段と、
   利用可能なコンポーネントを管理するとともに、上記制御手段からコンポーネントに係る上記リソース要求情報の問い合わせを受けた場合に、該情報を提供するコンポーネント管理手段を備え、
   上記リソース要求情報として、演算処理用デバイスの動作周波数又は記憶デバイスのメモリ使用量について各コンポーネントが要求する値又は範囲を示す情報が含まれ、
   上記複数のコンポーネントの接続関係を記述したグラフ構造データベースを用いて各コンポーネントの結合状態が管理されるとともに、
   上記リソース要求情報として、上記グラフ構造データベースに基いて各コンポーネント同士が結合されて処理が開始された場合に提供される動的情報と、各コンポーネント同士が結合される前の段階で提供可能な静的情報が使用される
   ことを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置において、
   動作中の上記コンポーネントが現在の処理状況に応じて上記動的情報を決定する
   ことを特徴とする情報処理装置。
3. 請求項２に記載の情報処理装置において、
   上記グラフ構造データベースに従って構築される複数のコンポーネントの接続関係について管理するための演出処理手段を備え、各コンポーネントが該演出処理手段に登録されることで管理される
   ことを特徴とする情報処理装置。
4. 請求項３に記載の情報処理装置において、
   上記コンポーネントから、上記演出処理手段に対して動作中に上記動的情報が変更されたことが通知された場合には、上記リソース要求情報を総合することによってシステム全体のリソースに関する要求情報を算定し、該情報の示す要求内容が許容される場合には、該要求内容に従って上記システム管理手段がリソースについての設定又は変更を行い、また、該情報の示す要求内容が許容されない場合には上記システム管理手段が現在の設定状態を維持する
   ことを特徴とする情報処理装置。

Images