(57)【要約】【課題】各コンポーネントの再利用性を高めたコンポーネントプログラム制御装置を提供する。【解決手段】情報処理装置１は、コンポーネントの登録情報を記憶するレジストリ６２と、アプリケーションに含まれるコンポーネント情報及びコンポーネントの接続関係情報を記憶するコンフィグレーション情報記憶部６１と、アプリケーションのコマンドとコンポーネントの状態とを対応付けるコマンド／状態対応情報を記憶するコマンド／状態対応情報記憶部７２と、アプリケーションが起動されると、コンフィグレーション情報記憶部６１とレジストリ６２を参照して、起動されたアプリケーションに含まれるコンポーネントを生成し、コマンド／状態対応情報記憶部７２を参照して、アプリケーションのコマンドと、生成された各コンポーネントの状態との対応付けを行うコンポーネント制御層１３と、を含む。【選択図】図４
2010039860.tif 000002
【特許請求の範囲】
【請求項１】
それぞれが所定の処理を実行する複数のコンポーネントプログラムの登録情報を記憶するコンポーネント登録情報記憶部と、
１以上のコンポーネントプログラムを組み合わせて構成されるアプリケーションプログラムに含まれるコンポーネント情報、及び前記１以上のコンポーネントプログラムの接続関係情報を記憶するアプリケーションコンポーネント情報記憶部と、
前記アプリケーションプログラムの実行時に指定される１以上のコマンドと、前記１以上のコンポーネントプログラムの状態とを対応付けるコマンド／状態対応情報を記憶するコマンド／状態対応情報記憶部と、
前記アプリケーションプログラムが起動されると、前記アプリケーションコンポーネント情報記憶部と前記コンポーネント登録情報記憶部を参照して、起動されたアプリケーションプログラムに含まれるコンポーネントプログラムを生成し、前記コマンド／状態対応情報記憶部を参照して、前記アプリケーションプログラムの前記１以上のコマンドのそれぞれと、生成された各コンポーネントプログラムの状態との対応付けを行うコンポーネント制御部と、
を有することを特徴とするコンポーネントプログラム制御装置。
【請求項２】
前記コンポーネント制御部は、複数のアプリケーションプログラムが起動された場合に、前記複数のアプリケーションプログラム間で共通のコンポーネントプログラムの生成の要否に関するポリシー情報に基づいて、前記コンポーネントの生成を行うことを特徴とする請求項１に記載のコンポーネントプログラム制御装置。
【請求項３】
前記コンポーネント情報及び前記接続関係情報は、グラフ情報として、前記アプリケーションコンポーネント情報記憶部に記憶され、
前記グラフ情報は、サブグラフ情報を含み得る情報であることを特徴とする請求項1又は２に記載のコンポーネントプログラム制御装置。
【請求項４】
それぞれが所定の処理を実行する１以上のコンポーネントプログラムを組み合わせて構成されるアプリケーションプログラムに含まれる前記１以上のコンポーネントプログラムを制御する方法であって、
前記アプリケーションプログラムが起動されると、  前記１以上のコンポーネントプログラムの登録情報を記憶するコンポーネント登録情報記憶部と、前記アプリケーションプログラムに含まれるコンポーネント情報、及び前記１以上のコンポーネントの接続関係情報を記憶するアプリケーションコンポーネント情報記憶部とを参照して、起動されたアプリケーションプログラムに含まれるコンポーネントプログラムを生成し、
前記アプリケーションプログラムが起動されると、前記アプリケーションプログラムの実行時に指定される１以上のコマンドと、前記１以上のコンポーネントプログラムの状態とを対応付けるコマンド／状態対応情報を記憶するコマンド／対応情報記憶部を参照して、前記アプリケーションプログラムの前記１以上のコマンドのそれぞれと、生成された各コンポーネントプログラムの状態との対応付けを行うことを特徴とするコンポーネントプログラムを制御する方法。
【請求項５】
それぞれが所定の処理を実行する１以上のコンポーネントプログラムを組み合わせて構成されるアプリケーションプログラムに含まれる前記１以上のコンポーネントプログラムを制御するコンポーネントプログラムを制御する方法を、コンピュータに実行させるプログラムであって、
前記アプリケーションプログラムが起動されると、  前記１以上のコンポーネントプログラムの登録情報を記憶するコンポーネント登録情報記憶部と、前記アプリケーションプログラムに含まれるコンポーネント情報、及び前記１以上のコンポーネントの接続関係情報を記憶するアプリケーションコンポーネント情報記憶部とを参照して、起動されたアプリケーションプログラムに含まれるコンポーネントプログラムを生成する第１のコード部と、
前記アプリケーションプログラムが起動されると、前記アプリケーションプログラムの実行時に指定される１以上のコマンドと、前記１以上のコンポーネントプログラムの状態とを対応付けるコマンド／状態対応情報を記憶するコマンド／対応情報記憶部を参照して、前記アプリケーションプログラムの前記１以上のコマンドのそれぞれと、生成された各コンポーネントプログラムの状態との対応付けを行うことを特徴とするコンポーネントプログラムを制御する第２のコード部と、
を有するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンポーネントプログラム制御装置、コンポーネントプログラムを制御する方法及びプログラムに関する。
【背景技術】
【０００２】
従来より、例えば画像処理技術の分野において、各種ソフトウエア部品、すなわち各種コンポーネントプログラム（以下、コンポーネントともいう）を複数利用して所望の機能を実現するアプリケーション装置あるいはアプリケーションプログラムがある。各コンポーネントの機能を利用して、全体として一つの装置、例えばDVDプレーヤ、DTV（デジタルテレビジョン）等の装置のアプリケーションプログラム（以下、アプリケーションともいう）が、パーソナルコンピュータ（以下、PCとう）等の情報処理装置上で実現される。
【０００３】
例えば、マイクロソフト（株）が提供するダイレクトショー（DirectShow）は、メディアコンポーネントの制御をフィルタグラフマネジャ（Filter Graph Manager）を経由することによって抽象度の高いAPI（Application Programming Interface）をアプリケーションに提供するものである。  
しかし、メディアコンポーネントのグラフ構成は、フィルタグラフマネジャの実装に依存するため、異なるグラフ間では構成要素の再利用性が低い。また、C++言語によるCOM（Component Object Model）技術が前提となっており、その動作は特定のOS上に限定されている。
【０００４】
さらに、必要なソフトウェアモジュールを組み合わせて、所定のマルチメディアコンテンツを実行させるDSPコードを生成する技術が提案されている（例えば、特許文献１参照）。  
しかし、その技術によれば、ソフトウェアモジュールはコーデックライブラリ、OS、メディアフレームワーク、及びハードウェアライブラリを前提とし、コーデックに応じたソフトウェアモジュール構成に限定されている。
【０００５】
また、コンポーネントの実行に関連するプラグインの制御に応じたコンポーネントスケジューリングと、プラグインに送出するコンポーネントの実行に関するイベントの通知とによって、コンポーネントに関してアプリケーションにサービス品質を提供する技術の提案もある（例えば、特許文献２参照）。  
しかし、その提案の技術によれば、サービス品質の保証にはアプリケーションの介在が前提となっている。
【０００６】
さらにまた、異なるソースから提供されるストリームを均一に取り扱うことができないQoS適応化問題に関して、サービス品質契約及びサービス品質適応化パスを記述するデータモデルを含むAPIを提供する技術の提案もある（例えば、特許文献３参照）。  
しかし、その提案の技術によれば、特定顧客のQoS及びポリシー仕様に基づいて、メディアコンポーネントを生成・接続することが前提となっている。
【特許文献１】特開2007-300613号公報
【特許文献２】特開2002-312331号公報
【特許文献３】特開2002-259125号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
そこで、本発明は、以上の問題に鑑みてなされたものであり、各コンポーネントの再利用性を高めたコンポーネントプログラム制御装置、コンポーネントプログラムを制御する方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一態様によれば、それぞれが所定の処理を実行する複数のコンポーネントプログラムの登録情報を記憶するコンポーネント登録情報記憶部と、１以上のコンポーネントプログラムを組み合わせて構成されるアプリケーションプログラムに含まれるコンポーネント情報、及び前記１以上のコンポーネントプログラムの接続関係情報を記憶するアプリケーションコンポーネント情報記憶部と、前記アプリケーションプログラムの実行時に指定される１以上のコマンドと、前記１以上のコンポーネントプログラムの状態とを対応付けるコマンド／状態対応情報を記憶するコマンド／状態対応情報記憶部と、前記アプリケーションプログラムが起動されると、前記アプリケーションコンポーネント情報記憶部と前記コンポーネント登録情報記憶部を参照して、起動されたアプリケーションプログラムに含まれるコンポーネントプログラムを生成し、前記コマンド／状態対応情報記憶部を参照して、前記アプリケーションプログラムの前記１以上のコマンドのそれぞれと、生成された各コンポーネントプログラムの状態との対応付けを行うコンポーネント制御部と、を有するコンポーネントプログラム制御装置を提供することができる。
【発明の効果】
【０００９】
本発明のコンポーネントプログラム制御装置、コンポーネントプログラムを制御する方法及びプログラムによれば、各コンポーネント、アプリケーション固有のユースケースの再利用性を高めることができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明の実施の形態を説明する。  
まず図１に基づき、本実施の形態に係わる情報処理装置の構成を説明する。図１は、本実施の形態に係わる情報処理装置のソフトウェアとハードウェアの構成を示す構成図である。
【００１１】
情報処理装置１は、例えばPC、サーバ、携帯情報端末（PDA）等である。情報処理装置１は、CPU、ROM、RAM、大容量記憶装置等のハードウェア装置であるハードウェア層１１と、図示しないオペレーティングシステム上のソフトウェア部品としての複数の（図１ではｎ個の）コンポーネントC1、C2、・・・Cnを含むコンポーネント層１２と、コンポーネント層１２の各コンポーネントを制御するコンポーネント制御プログラムであるコンポーネント制御層１３と、複数の（図１ではｍ個の）アプリケーション（以下、APと略す）を含むアプリケーション層１４と、さらに上位のアプリケーション制御プログラムを含むアプリケーション制御層１５とを含んで構成されている。
【００１２】
複数のAPは、AP1からAPｍがあるが、例えば、DTVライブ再生AP、DTV録画AP、DTVファイル再生AP等であり、PC等の情報処理装置１において、ユーザの指示に応じて、DTVライブ再生AP、DTV録画AP等が実行可能となっている。
【００１３】
各APのコンフィグレーション情報は、ユースケースとして記述される情報も含み、再生、録画、一時停止等のコマンドの情報も含んでいる。例えば、DTVライブ再生APを情報処理装置１上で実行している場合、ユーザは、そのAPの実行中に指定するコマンドとしては、「チャネル選択」、「開始」、「停止」等のコマンドが、ユースケースとして記述される。また、DTV録画APを情報処理装置１上で実行している場合、ユーザは、そのAPの実行中に指定するコマンドとしては、「開始」、「停止」等のコマンドが、ユースケースとして記述される。さらにまた、DTVファイル再生APを情報処理装置１上で実行している場合、ユーザは、そのAPの実行中に指定するコマンドとしては、「開始」、「停止」、「一時停止」、「早送り」、「巻き戻し」等のコマンドが、ユースケースとして記述される。これらのコマンドは、ユーザが、情報処理装置１において、各APを種々操作するときに使用するコマンドである。
【００１４】
また、ここでは、複数のコンポーネントのそれぞれは、映像データ、音声データ等のメディアデータに対して、映像処理、音声処理等を行うメディアコンポーネントであり、メディア処理を実行する制御単位のプログラムである。複数のコンポーネントは、C1からCnのｎ個あり、例えば、デマルチプレクサ（Demuxer）、ファイルライタ（Fwriter）、Vデコーダ（VDecoder）、Aデコーダ（ADecoder）、Vコンポジタ（VCompositor）、Aミキサ（AMixer）、Vレンダラ（VRenderer）、Aレンダラ（ARenderer）等である。すなわち、各コンポーネントプログラムは、所定の処理を実行するプログラムである。  
なお、ハードウェア層１１は、後述する各種データを記憶する記憶装置１６を含む。
【００１５】
そして、情報処理装置１は、ユーザの指示に応じて、各APを実行可能であり、各APに含まれる複数のコンポーネントは、APからのコマンドに応じて実行される。各APの実行が指示されると、後述するように、コンポーネント制御部であるコンポーネント制御層１３は、共通処理と、AP毎の処理とを実行し、各コンポーネントの制御を行う。
【００１６】
図２は、各APと複数のコンポーネントの利用関係を説明するための図である。  
例えば、AP1が、DTVライブ再生アプリケーションであり、AP2がDTV録画アプリケーションであり、AP3が、DTVファイル再生アプリケーションである、３つのアプリケーションがあるとする。
【００１７】
図２は、各APについてのグラフ理論におけるグラフを示す。AP1のグラフは、DTVライブ再生アプリケーションのグラフとして、二点鎖線G1で囲まれた部分である。AP2のグラフは、DTV録画アプリケーションのグラフとして、二点鎖線G2で囲まれた部分である。AP3のグラフは、DTVファイル再生アプリケーションのグラフとして、二点鎖線G3で囲まれた部分である。
【００１８】
図２に示すように、本実施の形態では、AP1のグラフは、例えば、Vデコーダ１（VDecoder1）２１、Vコンポジタ（VCompositor）２２及びVレンダラ（VRenderer）２３で構成されるビデオ・サブグラフSG1と、Aデコーダ１（ADecoder1）２４、Aミキサ（AMixer）２５及びAレンダラ（ARenderer）２６で構成されるオーディオ・サブグラフSG2、そして、これらをデマルチプレクサ（Demuxer）２７に接続する構成を有している。
【００１９】
同様に、AP2のグラフは、例えば、デマルチプレクサ（Demuxer）２７とファイルライタ（Fwriter）２８が接続された構成を有している。  
さらに、AP3のグラフは、例えば、Vデコーダ２（VDecoder2）２９、Vコンポジタ（VCompositor）２２及びVレンダラ（VRenderer）２３で構成されるビデオ・サブグラフSG3と、Aデコーダ２（ADecoder2）３０、Aミキサ（AMixer）２５及びAレンダラ（ARenderer）２６で構成されるオーディオ・サブグラフSG4、そして、これらをデマルチプレクサ（Demuxer）２７に接続する構成を有している。  
以上のように、各APは、１以上のコンポーネントを組み合わせて構成されるプログラムであり、図２に示すように、各APのグラフは、コンポーネントの接続関係情報を含む。各グラフ及び各コンポーネントは、再利用可能である。
【００２０】
ここで、サブグラフについて説明する。図３は、グラフ構造の例を説明するための図である。あるAPは、１以上のコンポーネントがグラフ（ノード）とコネクト（エッジ）で表現されるグラフ構造Gを有しているが、階層的に、内部にサブグラフSGを有することができる。サブグラフSGも、１以上のコンポーネントがグラフとコネクトで表現されるグラフ構造を有している。
【００２１】
このようなグラフ情報を利用するメリットは、異なるAP間でグラフ構成を再利用することができることである。すなわち、コンポーネント制御層１３は、各APのコンポーネントのグラフ情報を利用して、異なるAP間でグラフ構成を再利用することができる。上述したDTVライブ記録AP2のグラフとして、ファイルライタ（FWriter）２８とでマルチプレクサ（Demuxer）２７の構成が考えられる。この場合、DTVライブ再生AP1と同じコンテンツを記録する場合と、異なるコンテンツを記録する場合とでグラフ構成に変わりはないので、デマルチプレクサ（Demuxer）２７の属性を変更することで、同じグラフを異なるユースケースに対応させて利用することができる。
【００２２】
また、コンポーネントとサブグラフというエレメントによってグラフ構成を表現することにより、グラフ構成情報を構造化することができ、グラフだけではなくサブグラフの単位での再利用が可能となる。
【００２３】
なお、異なるコンテンツを記録する場合、異なるデマルチプレクサ（Demuxer）２７を生成して、完全に独立したグラフとすることも可能である。これらシステムに依存する選択は、メディアフレームワークとしてのコンポーネント制御層１３内のシステム制約情報に基づいて、コンポーネント制御層１３において決定できるため、APには影響しない。
【００２４】
各APに含まれるコンポーネントは、上述したように、画像処理、音声処理等のメディア処理等の所定の処理を実行する制御単位と定義される。図３に示すように、あるAPは、コンポーネントA,B,Cを含む。各コンポーネントにおけるデータのエントリポイントは、ポートPと定義される。コンポーネント間のデータ通信チャネルは、コネクトCNと定義される。コネクトCNにより接続された複数のコンポーネントの制御単位は、グラフGと定義される。グラフG内のコンポーネントのグループは、サブグラフSGと定義される。サブグラフSGとコンポーネントを接続する仕組みとして、サブグラフSGの仮想ポートVPが定義される。コンポーネント、グラフおよびサブグラフのそれぞれをエレメントとして、グラフ構成情報（以下、グラフ情報という）が、ポート、仮想ポート及びコネクトを用いて表現することができる。すなわち、グラフ情報は、そのグラフに含まれるコンポーネントの構成情報と、その含まれる１以上のコンポーネントの接続情報とを含む。なお、グラフGは、サブグラフSGを含まなくてもよい。
【００２５】
次に、コンポーネント制御部としてのコンポーネント制御層１３の構成について説明する。図４は、コンポーネント制御層１３の構成を示すブロック図である。  
コンポーネント制御層１３は、ソフトウエアプログラムにより構成されている。コンポーネント制御層１３は、コマンド受信部４１、グラフマネジャ４２、レジストリマネジャ４３、フレームワークマネジャ４４、イベントマネジャ４５、OASLインターフェース（以下、I/Fと略す）部４６、CCローダI/F部４７、及びCCI/F部４８の複数の機能モジュールを含んで構成されるコンポーネント制御部である。コンポーネント制御層１３は、図示しないインターフェース部を介して、コンポーネント層１２と接続される。コンポーネント層１２とのインターフェース部は、各コンポーネントを制御するための低レベルインタフェースであり、各コンポーネントの生成（含むイベント設定）、消滅、各種コマンド送信（コネクト要求や状態遷移要求など）、パラメータ／属性設定、データ処理要求、などのAPIを含む。
【００２６】
コマンド受信部４１は、APからのコマンドの受信と、APへのイベント情報の送信を行うプログラムである。  
具体的には、コマンド受信部４１は、コンポーネント制御層１３とのインターフェースをAP層１４に提供する処理部である。各APから受信した要求（API／コマンド）を解析し、コンポーネント制御層１３内の適切な機能モジュールへ送信する。各APが起動されると、予め設定されたグラフ名称を用いて所望のグラフの生成が行われる。各APは、グラフが生成された時にコンポーネント制御層１３から取得したグラフ・ハンドル情報を用いて、コマンド処理対象のグラフを指定することができる。同一のグラフ名称でグラフ生成要求を行うと同じグラフのインスタンスが生成され、APは、異なるグラフ・ハンドル情報を取得し、グラフを識別することができる。
【００２７】
グラフマネジャ４２は、複数のコンポーネントを組み合わせて構築される各APのグラフ情報に基づいてコンポーネントのグラフを構築するプログラムである。  
具体的には、グラフマネジャ４２は、エレメント情報（グラフ／サブグラフ／コンポーネント、名称、グラフ情報へのポインタ）、コネクト情報（エレメントIDと接続ポートID）、グラフ情報（エレメント数、コネクト数、仮想ポート数、エレメント情報へのポインタ、コネクト情報へのポインタ、仮想ポートへのポインタ）からなる情報を、記憶装置１６のコンフィグレーション情報記憶部６１から、取得する。  
すなわち、コンフィグレーション情報記憶部６１には、各APのユースケース情報と、図２に示すような各APのグラフ情報とを含むコンフィグレーション情報が含まれている。特に、各APのグラフ情報は、含まれる１以上のコンポーネント情報と、コンポーネント間の接続関係を定義する接続関係情報とを含み、アプリケーションコンポーネント情報として、記憶装置１６に記憶される。記憶装置１６において、アプリケーションコンポーネント情報が記憶された記憶領域が、アプリケーションコンポーネント情報記憶部を構成する。
【００２８】
そして、グラフマネジャ４２は、APが起動されると、そのAPのグラフ情報から、そのグラフの接続情報テーブルをメモリ上に生成し、コンポーネント層１２とのインターフェースを用いて、必要なコンポーネントの生成、コンポーネント間の接続、グラフ（コンポーネント群）の状態遷移情報を生成し、その状態を管理する。  
グラフマネジャ４２は、以上の処理を各グラフに対して行うだけでなく、さらに加えて、各コンポーネントの状態の管理も行う。
【００２９】
同時に、グラフマネジャ４２は、起動されたAPのグラフに対応するコマンド処理コントローラ（CC）６３をメモリへロードすべく、CCローダI/F４７を介してCCローダ６４へ依頼する。グラフマネジャ４２は、コマンド処理コントローラ（CC）６３からのグラフ状態遷移要求やコンポーネント制御要求（生成や消滅、状態遷移、など）を受信したとき、レジストリマネジャ４３が管理するコンポーネントの状況（共有状況や生成状況など）とポリシー情報に応じて、グラフやコンポーネントを適切に制御する。
【００３０】
ポリシー情報は、例えば、複数のAPが起動された場合に、複数のAP間で共通のコンポーネントの生成の要否に関する情報である。よって、グラフマネジャ４２は、そのポリシー情報に基づいて、既に起動された別のAPがあるときは、その別のAPに関わるコンポーネントの生成しない、というような処理を行うことができる。
【００３１】
また、グラフマネジャ４２は、APからのグラフの状態遷移要求に応じて、そのグラフの構成要素であるコンポーネントへ状態遷移コマンドを送信する。そして、グラフマネジャ４２は、各コンポーネントから状態遷移完了イベントを受信したとき、メディアフレームワークとしてのコンポーネント制御層１３内で管理するグラフ状態を変更する。
【００３２】
レジストリマネジャ４３は、複数のコンポーネントの登録情報を管理するプログラムである。  
具体的には、レジストリマネジャ４３は、コンポーネント数、各コンポーネントの名称とその各コンポーネントに付属するポート数、および、各ポート属性からなる情報を、記憶装置１６のレジストリ情報記憶部６２から取得し、メモリ上にコンポーネント登録情報テーブルを生成する。レジストリ情報記憶部６２は、コンポーネントの登録情報を記憶するコンポーネント登録情報記憶部を構成する。
【００３３】
さらに、レジストリマネジャ４３は、グラフマネジャ４２によって制御されるコンポーネントの情報、例えば共有状況、生成状況などの情報、も管理する。また、レジストリマネジャ４３は、生成可能なグラフ数及びコンポーネント数、生成可能なインスタンス数の情報に加えて、競合時の対処方針、例えば、待つ、諦める、プリエンプションする、などの上述したポリシー情報も、管理する。
【００３４】
フレームワークマネジャ４４は、各種ヘルパー機能を提供するプログラムである。  
具体的には、フレームワークマネジャ４４は、内部における各種要求の送受信、フック関数等を管理する。フレームワークマネジャ４４は、例えば、コマンド受信部４１、もしくは、コマンド処理コントローラ（CC）６３から受信した要求を解析し、その要求を適切な機能モジュールへ送信する。また、フレームワークマネジャ４４は、予め定義されたフック関数（コマンド処理コントローラ（CC）６３の初期化時に、システムが提供するフック関数の中から必要に応じて設定される）を経由して、コマンド処理コントローラ（CC）６３へ各種処理を依頼する。
【００３５】
また、フレームワークマネジャ４４は、APからのグラフの属性変更要求に対しては、共通機能として要求解析を行い、コマンド処理コントローラ（CC）６３を呼び出す。そして、フレームワークマネジャ４４は、コマンド処理コントローラ（CC）６３に、ユースケース固有の機能として特定のコンポーネントに対して属性変更要求コマンドを送信させる。
【００３６】
イベントマネジャ４５は、コンポーネントから受信したイベント情報を制御するプログラムである。  
具体的には、イベントマネジャ４５は、生成された各コンポーネントに登録されたイベント処理ルーチンを管理する。各コンポーネントから発生する共通イベントは、内部で処理され、必要に応じてAPへ通知される。また、イベントマネジャ４５は、ユースケース固有のイベントに関しては、共通機能としてイベント解析までを行った後、予め登録されたフック関数によってコマンド処理コントローラ（CC）６３へ処理を依頼する。そして、イベントマネジャ４５は、コマンド処理コントローラ（CC）６３からの戻り値に応じて、適切なイベントをAPへ通知する。
【００３７】
また、イベントマネジャ４５は、コンポーネントからユースケース固有のイベントを受信した場合、共通機能としてイベント解析を行い、その後、コマンド処理コントローラ（CC）６３を呼び出す。そして、イベントマネジャ４５は、コマンド処理コントローラ（CC）６３に、ユースケース固有の機能として特定のイベント処理を実行させる。
【００３８】
OASLI/F部４６は、OS及びハードウェア層とのI/Fであり、OS及びハードウェア層の処理プログラム６５へ各種コマンドを出力する。
【００３９】
CCローダI/F部４７は、コマンド処理コントローラ（CC）６３をメモリへロードするためのコマンド処理プログラムローダ（CCローダ）６４への指示を送信するためのプログラムである。
【００４０】
コマンド処理プログラムローダ（CCローダ）６４は、プラットフォーム（OSやハードウェア）に応じた手段によって、コマンド処理コントローラ（CC）６３をメモリへロードする。グラフマネジャ４２から、コマンド処理コントローラ（CC）６３のロード要求が行われる。コマンド処理コントローラ（CC）６３のロードは複数可能である。すなわち、複数のユースケースが同時に動作することが可能である。コマンド処理プログラムローダ（CCローダ）６４がコマンド処理コントローラ（CC）６３をメモリロードすることにより、様々なプラットフォームでのコマンド処理コントローラ（CC）６３の再利用が可能となる。
【００４１】
CCI/F部４８は、コマンド処理コントローラ（CC）６３との通信を行うためのプログラムである。
【００４２】
コマンド処理コントローラ（CC）６３は、各ユースケース固有のコマンド処理やイベント処理の実行を制御するプログラムである。  
具体的には、コマンド処理コントローラ（CC）６３は、各ユースケース固有のコマンド及びパラメータの処理、および、イベント処理を行う。コマンド処理コントローラ（CC）６３は、フレームワークマネジャ４４からのユースケース固有のコマンドあるいはパラメータ処理要求を受信したとき、解析結果に応じて、生成したグラフの状態遷移や属性情報の設定を行うべく、予め登録されたフック関数を経由してフレームワークマネジャ４４へ依頼する。また、イベントマネジャ４５から、あるユースケースのイベント処理要求を受信したとき、解析結果に応じてグラフの状態遷移や属性情報の設定やAPへのイベント要求を行うべく、予め登録されたフック関数を経由してフレームワークマネジャ４４へ依頼する。
【００４３】
なお、ユースケース固有のコマンドやイベントを処理するコマンド処理コントローラ（CC）６３には、予め標準的な機能が提供されているため、上述した処理を行うための、例えばフック関数等によって規定された処理を実装するだけでよい。
【００４４】
また、コマンド処理コントローラ（CC）６３は、各ユースケースに使用されるコマンドセットの情報を、コマンドセット情報記憶部７１から取得することができる。上述した例であれば、DTVライブ再生APのユースケースのコマンドセットとしては、「チャネル選択」、「開始」、「停止」のコマンドが、コマンドセット情報記憶部７１に予め記憶されている。
【００４５】
さらに、コマンド処理コントローラ（CC）６３は、各APの実行時に指定される各コマンドと、各コンポーネントの状態あるいはコマンドとを対応付けるコマンド／状態対応情報を、コマンド／状態対応情報記憶部７２から取得することができる。コマンドセット情報記憶部７１とコマンド／状態対応情報記憶部７２は、記憶装置１６に予め設定されて記憶されている。
【００４６】
あるAPが起動されると、そのAPのユースケースに使用されるコマンドセットの情報を、コマンドセット情報記憶部７１から取得し、さらに、コマンド／状態対応情報記憶部７２のコマンド／状態対応情報に基づいて各コマンドと各コンポーネントの状態あるいはコマンドとの対応付けが行われる。その結果、ユーザが、起動したAPの実行時に、あるコマンドがユーザによって指定されると、そのコマンドに対応する１以上のコンポーネントの状態が、そのユーザのコマンドに対応した状態に変更され得る。
【００４７】
（動作）
次に、情報処理装置１のコンポーネント制御層１３の動作について説明する。以下の動作は、ハードウェア層１１のCPUによって実行される。図５は、APの起動時におけるコンポーネント制御層１３の動作の例を示すフローチャートである。  
あるAPが起動されると、まず、そのAPの起動情報あるいはそのAPからグラフの生成要求コマンドが、コマンド受信部４１で受信され、フレームワークマネジャ４４に渡される。フレームワークマネジャ４４は、グラフマネジャ４２に、そのAPに対応するコンポーネントの構成情報と、その含まれる１以上のコンポーネントの接続情報とを読み込ませる（ステップS1）。
【００４８】
フレームワークマネジャ４４は、コマンド処理プログラムローダ（CCローダ）６４に、グラフに応じたコマンド処理コントローラ（CC）６３を読みこませる。コマンド処理コントローラ（CC）６３の初期化時に、システムが提供するフック関数の中から必要に応じて設定される（ステップS2）。
【００４９】
次に、フレームワークマネジャ４４は、そのAPに含まれる各コンポーネントの登録情報を、レジストリマネジャ４３に取得させ、そのAPに関わる各コンポーネントをメモリ上に生成する（ステップS3）。
【００５０】
次に、各コンポーネントの接続情報から、そのAPの各コンポーネントの接続関係を構築する（ステップS4）。
【００５１】
以上により、そのAPのグラフがメモリ上に生成あるいは構築される。  
なお、このとき、グラフマネジャ４２は、生成されていないコンポーネントは生成され、ポリシー情報に基づいて、別のAPのために生成済みのコンポーネントは生成されない。また、グラフマネジャ４２は、APからのグラフ消去要求に対して、コンポーネントの登録情報とコンポーネントの接続情報に基づいて、グラフを消去する。このとき、他のグラフと共有されていないコンポーネントは消去され、ポリシー情報に基づいて、他のAPと共有されているコンポーネントは消去されない。これは、他のAPが使用されるコンポーネントが既に起動されている場合もあるからである。
【００５２】
そして、グラフマネジャ４２は、初期化を行う（ステップS5）。この初期化は、そのAPを動作可能状態にする必要があるため、そのAP内の各コンポーネントの状態が初期化される。
【００５３】
次に、コマンドセットの生成が行われる（ステップS6）。コマンドセットの生成は、上述したコマンドセット情報記憶部７１に記憶されたコマンドセットの情報を、コマンド処理コントローラ６３を介して読み出すことによって、行われる。
【００５４】
例えば、DTVライブ再生アプリケーションであるAP1では、ユーザの操作コマンドとして、「チャンネル選択」、「開始」及び「停止」のコマンドが入力可能である。TV録画アプリケーションであるAP2では、ユーザの操作コマンドとして、「開始」と「停止」のコマンドが入力可能である。DTVファイル再生アプリケーションであるAP3では、ユーザの操作コマンドとして、「開始」、「停止」、「一時停止」、「早送り」、「巻き戻し」のコマンドが入力可能である。このように、複数のAP間では、それぞれのユースケースとして記述されたこれらの入力コマンドは、異なっている。
【００５５】
このような各AP毎のコマンドのセットの情報は、記憶装置１６のコマンドセット情報記憶部７１にコマンドセット情報として記憶されている。よって、コマンドセットの生成処理は、起動されたAPのコマンドセットを、コマンドセット情報記憶部７１から読み出すことによって、行われる。
【００５６】
次に、コマンドの実行処理が行われる（ステップS7）。コマンドの実行処理は、上述したコマンド／状態対応情報記憶部７２に記憶されたコマンド／状態対応情報を、コマンド処理コントローラ６３を介して読み出すことによって、行われる。  
コマンドの実行処理は、上述したように、APのコマンドと、各コンポーネントの状態とを対応付ける処理である。  
例えば、AP3の場合、「開始」コマンド（すなわち「再生」コマンド）は、７つのコンポーネント、Vデコーダ２（VDecoder2）２９、Vコンポジタ（VCompositor）２２、Vレンダラ（VRenderer）２３、Aデコーダ２（ADecoder2）３０、Aミキサ（AMixer）２５、Aレンダラ（ARenderer）２６、デマルチプレクサ（Demuxer）２７のそれぞれを、「開始」（すなわち「再生」）の状態に対応付けられる。すなわち、AP3の実行時に、「開始」コマンド」がユーザから入力されると、これらの対応する各コンポーネントを、その「開始」コマンドに対応する状態に移行させることによって、AP3の「開始」コマンドが実行されることになる。  
また、AP2の場合、「開始」コマンドは、デマルチプレクサ（Demuxer）２７とファイルライタ（Fwriter）２８を、「開始」すなわち「再生」の状態に対応付けられる。
【００５７】
同様に、各APの各コマンドについても、対応するコンポーネントの状態を、その各APの各コマンドに対応する状態に移行させる対応付け処理を行うことによって、その各APの各コマンドの処理が実行される。  
このような対応付けは、例えば、フック関数を利用して行うことができる。すなわち、フック関数のポインタによりコマンド処理コントローラ（CC）６３のプログラム中の関数等を指定することによって、そのコンポーネントの状態が、APのコマンドに対応した処理となるようにすることができる。
【００５８】
このような各APの各コマンドと、各コンポーネントの状態との対応関係は、記憶装置１６のコマンド／状態対応情報記憶部７２に予め記憶されている。よって、コマンドの実行処理は、起動されたAPの各コマンドと、各コンポーネントの状態との対応関係の情報を、コマンド／状態対応情報記憶部７２から読み出すことによって、行われる。
【００５９】
以上のようにして、各APは起動されると、図５の処理が実行されることによって、各APは実行可能となる。  
各APの実行中は、コマンド処理コントローラ６３が、各コンポーネントに対するコマンドの処理を行うことによって、各APの動作は行われる。
【００６０】
以上のように、上述した構成を有するメディアフレームワークとしてのコンポーネント制御層１３が、AP層１４とコンポーネント層１２との間に設けられた。コンポーネント制御層１３は、APが起動されると、グラフ情報、コマンドセット情報およびコマンド／状態対応情報とを利用して、そのAPに対応する各コンポーネントを実行可能状態にする。よって、上述したフレームワークとしてのコンポーネント制御層によれば、そのAPが各コンポーネントを直接制御する必要はなく、コンポーネント制御層１３が、多様なコンポーネントの接続及び制御を行うので、APに対して、抽象度の高いインターフェースを提供することができる。
【００６１】
特に、グラフマネジャ４２は、コンポーネントの生成条件、共有条件などのシステム制約情報に基づいて、グラフ間のコンポーネント競合を解決するため、APはシステム制約に関与することなくグラフを制御することが可能である。
【００６２】
さらに詳細に言うならば、上述した実施の形態に係るメディアフレームワークでは、グラフ情報を利用しているので、複数のコンポーネントによって構成されるより複雑なグラフに対応することができる。その結果、上述した実施の形態に係るメディアフレームワークは、各コンポーネントの再利用性を高めることが可能で、かつOS非依存のメディアフレームワークとなる。
【００６３】
従って、上述した構成を有するメディアフレームワークとしてのコンポーネント制御層１３を利用することにより、APが介在することなく、グラフのサービス品質の保証、各APのQoS及びポリシー仕様で開発されたグラフ毎のサービス品質の保証を、より容易に行うことが可能となる。  
その結果、APのシステム全体の品質を高めることができ、かつ各AP及び各コンポーネントの開発工数を減らすことも可能となる。
【００６４】
なお、以上の例では、APは、固定的であるが、APを複数のユースケースを適切に組み合わせて、動的に制御することによって、より複雑なサービスの構築が可能である。例えば、DTV追っかけ再生のAPは、最初にDTV録画APとDTVファイル再生APの組み合わせで、ハードディスク装置等に記録されたDTVのデータを再生し、再生タイミングがライブ放送に追いついた時点で、予め生成しておいたDTVライブ再生APへ切り替える、というように動的に制御することによって、実現することができる。
【００６５】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウェアやソフトウェア・ルーチンに１対１には対応しない。従って、本明細書では、以上、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明した。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【００６６】
なお、以上説明した動作を実行するプログラムは、コンピュータプログラム製品として、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶媒体に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムコードがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムコードの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のフレームワークを実現することができる。
【００６７】
以上のように、上述したコンポーネント制御層のフレームワークを用いることによって、各コンポーネントの接続制御を行い、かつAPに対して抽象度の高いインターフェースを提供することができる。  
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【図面の簡単な説明】
【００６８】
【図１】本発明の実施の形態に係わる情報処理装置のソフトウェアとハードウェアの構成を示す構成図である。
【図２】本発明の実施の形態に係わる、各APと複数のコンポーネントの利用関係を説明するための図である。
【図３】本発明の実施の形態に係わるグラフ構造の例を説明するための図である。
【図４】本発明の実施の形態に係わるコンポーネント制御層の構成を示すブロック図である。
【図５】本発明の実施の形態に係わる、APの起動時におけるコンポーネント制御層１３の動作の例を示すフローチャートである。
【符号の説明】
【００６９】
１  情報処理装置、１１  ハードウェア層、１２  コンポーネント層、１３    コンポーネント制御層、１４、１５  アプリケーション層
【図１】
2010039860.tif 000003
【図２】
2010039860.tif 000004
【図３】
2010039860.tif 000005
【図４】
2010039860.tif 000006
【図５】
2010039860.tif 000007