それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置であって、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する処理リソース割当パターン保持部と、受け付けた処理要求の処理要求種別と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンに基づいて、前記処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する処理リソース割当部と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する電力状態決定部とを有することを特徴とする情報処理装置。前記電力状態決定部は、前記処理リソース割当パターンと前記割当可能処理リソース情報とから、現在受け付け可能な処理要求の処理要求種別を判定し、前記受け付け可能な処理要求のいずれかが実行された場合に利用される処理リソースを、前記次の処理要求にて利用される可能性があると判定することを特徴とする請求項1に記載の情報処理装置。前記電力状態決定部は、前記複数のモジュールの内、前記次の処理要求にて利用される可能性があると判定された前記割り当て可能処理リソースを有するモジュールの電力状態を通常状態に遷移させ、前記次の処理要求にて利用される可能性がないと判定された前記割り当て可能処理リソースを有するモジュールの電力状態を前記通常状態に比べ消費電力の少ない省電力状態に遷移させることを特徴とする請求項1または2に記載の情報処理装置。前記電力状態決定部は、前記処理リソース割当部が保持する前記割当可能処理リソース情報の更新に合わせて、前記複数のモジュールの各モジュールの電力状態を更新することを特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。前記処理リソース割当部は、モジュールから機能の停止を受け付けた場合には、前記割当可能処理リソース情報を更新し、前記電力状態決定部は、前記処理リソース割当部が保持する前記割当可能処理リソース情報の更新に合わせて、前記複数のモジュールの各モジュールの電力状態を更新することを特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。前記処理リソース割当部は、処理リソースの追加を受け付けた場合には、前記割当可能処理リソース情報を更新し、前記電力状態決定部は、前記処理リソース割当部が保持する前記割当可能処理リソース情報の更新に合わせて、前記複数のモジュールの各モジュールの電力状態を更新することを特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置の制御方法であって、処理リソース割当パターン保持部が、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを記憶媒体に保持する保持工程と、処理リソース割当部が、受け付けた処理要求の処理要求種別と、前記記憶媒体に保持されている前記処理リソース割当パターンに基づいて、前記受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する更新工程と、電力状態決定部が、前記記憶媒体に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する決定工程とを有することを特徴とする情報処理装置の制御方法。それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置の制御をコンピュータに機能させるためのプログラムであって、前記コンピュータを、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する処理リソース割当パターン保持部と、受け付けた処理要求の処理要求種別と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンに基づいて、前記受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する処理リソース割当部と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する電力状態決定部として機能させることを特徴とするプログラム。しかしながら、従来の方法では、モジュール毎の近い将来の利用可能性を正確に予測していなかったため、以下の課題が存在する。すなわち、通常状態から省電力状態に遷移するタイミングは、例えば、一定時間の連続した停止状態が検出された場合であり、すぐに利用される可能性のないモジュールもある一定期間通常状態で動作するため、省電力効果が十分に得られない。その一方で、省電力状態を持つモジュールは、通常動作を担保するために省電力状態から通常状態への復帰メカニズムを持たなければならない。ここで、省電力状態時に新たな処理要求を受け取った場合に、その処理要求の内容と自装置の状態とに基づいて、モジュール毎に通常状態に遷移させるか否かを判断する方法がある。しかしながら、この方法では省電力状態から通常状態へ遷移させるか否かを判断するタイミングは、例えば、システムが次の処理要求を受け取ったタイミングである。そのため、次の処理要求を受け取った後でないと通常状態への復帰動作を開始できないため、一旦省電力状態へ遷移した場合のシステムの応答性が低下する。特に、多岐にわたる機能を提供するために多くのモジュールを備え、なおかつ多くのユーザによって共用されるシステムの場合、外部より受け付け可能な処理要求の種別以降、これを処理要求種別と称すや組み合わせが多い。そのため、モジュール単位での省電力制御を適切なタイミングで実施することが、省電力及びシステムの応答性の向上を実現する上で重要となる。本発明は上記の課題を解決するためになされたものであり、モジュール毎に近い将来の利用可能性を判定し、その結果をもとに通常状態、省電力状態を切替えて動作させることにより、システムの応答性と省電力を両立させることである。上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。即ち、それぞれ処理リソースを有する複数のモジュールを連携動作させることにより処理要求を実行する情報処理装置であって、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する処理リソース割当パターン保持部と、受け付けた処理要求の処理要求種別と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンに基づいて、前記受け付けた処理要求に必要な処理リソースを割り当てるとともに、その割り当て後に更に残っている割り当て可能な処理リソースを示す割当可能処理リソース情報を更新する処理リソース割当部と、前記処理リソース割当パターン保持部に保持されている前記処理リソース割当パターンと前記割当可能処理リソース情報とに基づいて、前記割り当て可能な処理リソースが次の処理要求にて利用される可能性があるか否かを判定し、その判定結果に基づいて、前記複数のモジュールの各モジュールの電力状態を決定する電力状態決定部とを有する。本発明によれば、モジュール毎に近い将来の利用可能性を判定し、その結果をもとに通常状態、省電力状態を切替えて動作させることにより、システムの応答性と省電力を両立させることができる。より具体的には、次の処理要求で利用される可能性のないモジュールを省電力状態で動作させることにより、システムの応答性を確保しつつも省電力を実現することができる。以下、本発明の実施の形態について図面を用いて詳細に説明する。<実施形態1>以下、本発明の実施形態1について図面及びフローチャートを用いて説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。図1は実施形態1の情報処理装置の構成を示すブロック図である。図中、101は処理要求実行部であり、アプリケーションからの処理要求を受け付け、該当処理を実現するための複数の内部命令に変換した後、各モジュールに命令を送信する。ここで、処理要求とは、該当システムにて処理可能な制御命令を示しており、デジタルテレビの例ではユーザのリモコン操作等に伴い生じるストリーム処理開始要求やパラメータ変更要求等を想定する。また、これらの処理要求を実行するためには、あらかじめ利用する処理リソースを確保しておかなければならない。この処理リソースの確保処理については、処理リソース割当部103に説明を加える際に補足する。102は処理リソース割当パターン保持部であり、処理要求種別情報と、その処理要求種別情報が示す処理の実行に必要な処理リソース情報とからなる処理リソース割当パターンを保持する。ここで、処理リソースとは、各モジュールが提供する単位機能を実行するために占有すべきリソースの総称であり、ハードウェア/ソフトウェアの動作やデータの1次記憶に必要なメモリ領域、モジュール間でデータや制御信号を授受する通信帯域等を含んでいる。この処理リソースは、論理的な単位であり、必ずしもハードウェアと1対1に対応する必要はなく、単一のモジュールに複数の処理リソースが入っていても良い。例えば、ダブルチューナのように単一のモジュールで複数の単位機能を提供するモジュールは、1つのモジュールの内部に2つの処理リソースを包含する構造となる。103は処理リソース割当部であり、割当可能処理リソース情報を持ち、処理要求実行部101が受け付けた処理要求の処理要求種別と処理リソース割当パターン保持部102に保持されている処理リソース割当パターンを用いて処理リソースを割り当てる。必要な処理リソースが利用可能であり、割当に成功した場合は割当可能処理リソース情報を更新する。一方で、必要な処理リソースの一部もしくは全部が現在利用不可能であり、割当に失敗した場合はその旨を処理要求実行部101に伝え、該当処理を中断する。この場合、処理要求実行部101は該当処理を中止する。この処理リソースの割当及び割当可能処理リソース情報の更新は、例えば、新たなストリームに対する最初の処理要求を受け付けたタイミングで実行され、以降、該当ストリームに対する処理が続く限り、この割当可能処理リソース情報が保持される。104はモジュール制御部であり、各モジュールにそれぞれ存在し、処理要求実行部101から命令を受け付けてモジュール固有の処理を実行する。尚、図1では、N個のモジュール1~Nが存在する。105は電力状態決定部であり、処理リソース割当パターン保持部102に保持されている処理リソース割当パターンと、処理リソース割当部103に保持されている割当可能処理リソース情報とから、各モジュールの電力状態を決定する。106はモジュール状態管理部であり、各モジュールにそれぞれ存在する。モジュール状態管理部106は、少なくとも通常状態と、通常状態に比べ消費電力の少ない省電力状態とを持ち、電力状態決定部105が決定した各モジュールの電力状態情報を受け付けて各モジュールの電力状態を遷移させる。尚、図1の情報処理装置は、汎用コンピュータに搭載される標準的な構成要素例えば、CPU、RAM、ROM、ハードディスク、外部記憶装置、ネットワークインタフェース、ディスプレイ、キーボード、マウス等を有している。図2は本発明の実施形態1の処理リソース割当パターン保持部102が保持する処理要求種別情報及び処理の実行に必要な処理リソース情報の具体例の概念図である。この具体例は、デジタルテレビのような映像ストリーム処理システムを想定しており、対象とするシステムが5つの処理要求種別を受け付け可能なシステムであることを表している。特に、図2では、処理要求種別情報として、デジタル放送視聴A、デジタル放送視聴B、デジタル放送をIEEE1394出力、デジタル放送をHDD録画及びNetTVを視聴が示されている。また、201~205はそれぞれの処理要求種別情報が示す処理要求を実行するために必要な処理リソース群を表している。例えば、デジタル放送視聴A処理要求は、チューナ入力リソース206をはじめ、計6つの処理リソースを利用することにより実現される処理となる。図3は本発明の実施形態1の処理リソース割当パターン保持部102が保持する処理要求種別情報及び処理の実行に必要な処理リソース情報の保持例を表しており、図2の概念図で表される情報と等価である。図中、表300は保持する処理要求種別情報及び処理の実行に必要な処理リソース情報全体を表している。行301~行305はそれぞれの処理要求種別である。各行301~行305における処理要求種別では、処理要求種別が示す処理要求を実行するために必要な処理リソースの種類とその数が列単位で管理されており、それぞれ図2の処理リソース群201~205に対応する。また、例えば、列306は処理リソース1つであり、図2のチューナ入力リソースに対応する。図4は本発明の実施形態1の処理リソース割当部103が保持するモジュール毎の割当可能処理リソース情報に関する具体例の概念図である。この具体例では、デジタルテレビのような映像ストリーム処理システムを想定しており、入力ストリームに対するチューナ入力、Demux、AVデコード、画像処理等のフィルタ処理をくり返すことによって出力ストリームに変換する処理系を想定している。図中、表400はシステム全体のモジュール構成を表しており、この例では全12モジュールが連携動作することによりシステムが所定の機能を提供する。401はモジュール1を表し、このモジュールが2つのチューナ入力リソースを提供していることを表している。このように、モジュールと処理リソースが1対多の関係であって良いし、1つのモジュールが処理内容の大きく異なる2つ以上の処理リソースを包含していても良い。図5は本発明の実施形態1の処理リソース割当部103が保持するモジュール毎の割当可能処理リソース情報の保持例を表しており、図4の概念図で表される情報と等価である。図中、表500はモジュール毎の割当可能処理リソース情報を表している。行501はモジュール1が2つのチューナ入力リソースを提供していることを表しており、これはシステム400を構成するモジュール401の情報を表している。列502~列504は、それぞれ処理リソース種別を表している。この具体例では、本システム内に全12種の処理リソース種別が存在している。図6は本発明の実施形態1の処理リソース割当部103が保持する割当可能処理リソース数の保持例を表している。図中、表600は割当可能な処理リソースの総数を表している。この具体例では、特にシステムが何ら処理要求を受け付けていない状態での割当可能処理リソース数が保持されている。この時点では、表600が示す割当可能な処理リソースの総数は、モジュール毎の割当可能処理リソース情報500より得られるシステム内に存在する処理リソースの総数と等価である。図7は本発明の実施形態1の処理リソース割当部103が保持する割当可能処理リソース数の異なる一例を表している。図中、表700は割当可能な処理リソースの総数を表している。この具体例では、システムが特定の処理要求を受け付けた結果として、割当済の処理リソース数が、表600が示す割当可能な処理リソースの総数から差し引かれた一例を示している。図8aは本発明の実施形態1のモジュール状態管理部106が保持する各モジュールの状態図の一例を表している。図中、801は通常状態を表し、該当モジュールが相当量の電力を消費しながら動作している状態を表している。より具体的には、例えば、該当モジュールが利用されている、もしくは利用されていないがソフトウェアのロードパラメータの初期化が終了し、ポーリング処理等の必要な処理を実行中の状態を想定する。また、ハードウェアは通常稼動している。802は省電力状態であり、該当モジュールの消費電力が通常状態801に比べて少ない状態を表している。より具体的には、例えば、ソフトウェア面ではアンロードされている状態、もしくはロードされているがパラメータの初期化が終了していない状態や、タイマ起動による定期監視処理等のCPUリソースを消費する処理を実施していない状態を想定する。また、ハードウェア面では、例えば、クロック周波数を低下させている状態を想定する。803~805は、状態間の遷移可能性を表している。803は、該当モジュールの起動処理が終了後すぐに、該当モジュールが通常状態801に遷移することを表している。804は、該当モジュールが通常状態801にある時にevSuspendイベントを受け付けると、省電力状態802に遷移することを表している。このevSuspendイベントは、電力状態決定部105から各モジュール状態管理部106に送信されることを想定するが、その送信タイミングの詳細については後述する。805は、該当モジュールが省電力状態802にある時にevResumeイベントを受け付けると、通常状態801に遷移することを表している。このevResumeイベントについても、電力状態管理部106から各モジュール状態管理部106に送信されることを想定するが、その送信タイミングについては後述する。図8bは本発明の実施形態1のモジュール状態管理部106が保持する各モジュールの状態図の異なる一例を表している。図中、806は801と同様に通常状態を表し、807は802と同様に省電力状態を表している。ここで、通常状態806は、内部にさらに実行準備状態808と実行中状態809を持ち、該当モジュールの状態をより詳細に管理する。実行準備状態808は、例えば、処理を受け付け可能であるが実処理を実行していない状態、実行中状態809は、例えば、実処理を実行している状態を表している。このように、各モジュールが保持する状態は、通常状態801及び省電力状態802がそれぞれ内部にさらに状態を持ち、拡張されていても良い。また、システムを構成する各モジュールが、図8aに対してそれぞれ異なる拡張を適用することにより、それぞれ異なる状態図を持っていても良い。図9は本発明の実施形態1の実現手順を示すフローチャートである。以下では、本フローチャートに沿って、図2~図8の具体例を交えながら説明を加える。ステップS901で、システムが起動される。ここでは、モジュール制御部104がシステム処理要求実行部101からの起動命令を受けて、各モジュールの初期化処理を実施する。その結果、モジュール状態管理部106が保持するモジュール状態が通常状態801に遷移する等の処理が実行される。また、初期化処理の一環として処理リソース割当部103対して各モジュールが保持する割当可能処理リソース情報500を通知する等の操作が想定される。図5の具体例では、モジュール1より行501の情報が処理リソース割当部103に対して伝達され、処理リソース割当部103はこの情報を保持する。尚、各モジュールが保持する割当可能処理リソース情報500は、上記のごとくシステムの初期化時に各モジュールから伝達されても良いし、構成モジュールの変更がないシステムでは、あらかじめ処理リソース割当部103が静的に保持しておいても良い。ステップS902で、以降のステップS903からステップS908までの処理を、システムが起動している間くり返す。ステップS903で、処理要求実行部101は、実行中の処理要求の増減を監視する。処理要求が増加する具体例としては、ユーザからの処理開始命令やシステム内部のタイマの発火によって新たな処理要求が発生し、処理要求実行部101が処理を受け付けた場合がある。一方で、処理要求が減少する具体例としては、ユーザからの処理終了命令や実行中の処理が完了した場合等がある。ここでは、処理が何ら発生していない状態から、行304で示されるデジタル放送をHDD録画処理要求が投入された場合、すなわち、処理要求が増加した場合を具体例として、以降の説明を進める。上記処理要求を受け付けた場合は、処理リソース割当部103が保持する受け付け前の割当可能処理リソース数600が、デジタル放送をHDD録画処理要求に割り当てた処理リソース分だけ減少し、割当可能処理リソース数700に変化する。ステップS904で、電力状態決定部105は、現在実行中の処理要求と並行し、次の処理要求として各処理要求種別を受け付け可能か否かを判定する。この判定は、各処理要求を実行するために必要な処理リソース情報300と、現在の割当可能処理リソース数700とを用いて実行される。尚、ここでの判定処理については後述する。ステップS905で、電力状態決定部105は、次の処理要求で各処理リソースが利用される可能性があるか否かを判定する。この判定は、ステップS904の処理結果と、各処理要求を実行するために必要な処理リソース情報300とを用いて実行される。尚、ここでの判定処理については後述する。ステップS906で、電力状態決定部105は、次の処理要求で各モジュールが利用される可能性があるか否かを判定する。この判定は、ステップS905の処理結果と、モジュール毎の割当可能処理リソース情報500とを用いて実行される。尚、ここでの判定処理については後述する。ステップS907で、各モジュールのモジュール状態管理部106は、電力状態決定部105からの命令を受けて電力状態を更新する。この更新は、ステップS906の処理結果を用いて実行され、該モジュールが次の処理要求で利用される可能性があると判定された場合は通常状態に、次の処理要求で利用される可能性がないと判定された場合は省電力状態に遷移する。この状態遷移は、例えば、電力状態決定部105からモジュール状態管理部106に対してイベントを送信することによって実現される。図8aの具体例では、電力状態決定部105が省電力状態に遷移させたいと判定した場合には、電力状態決定部105はモジュール状態管理部106に対してevSuspendを発行する。これを受け付けたモジュール状態管理部106は、通常状態であった場合には省電力状態に遷移し、例えば、CPUのクロックを低下させる等の電力消費を抑える動作を実施する。一方、モジュール状態管理部106で管理する状態が既に省電力状態であった場合には、送信されたイベントであるevSuspendを無視し、何もしない。図10は電力状態決定部105により現在、次の処理要求として各処理要求種別の処理要求を受け付け可能か否かを判定する処理の詳細を示すフローチャートであり、これは図9のステップS904に対応する。図中、ステップS1001で、電力状態決定部105は、以降のステップS1002からステップS1010までの処理を、図3の行301~305それぞれが示す処理要求種別のそれぞれについて実施する。ステップS1002で、電力状態決定部105は、新たに1つの処理要求種別を取り出し、処理要求種別Jaとする。図2~図8の具体例では、デジタル放送をIEEE1394出力処理要求が選択されたとして、以降の処理を説明する。ステップS1003で、電力状態決定部105は、以降のステップS1004からステップS1007までの処理を、図5の列502~504それぞれが示す処理リソース種別のそれぞれについて実施する。ステップS1004で、電力状態決定部105は、新たに1つの処理リソース種別を取り出し、処理リソース種別Raとする。図2~図8の具体例では、Remaxリソースが選択されたとして、以降の処理を説明する。ステップS1005で、電力状態決定部105は、処理要求種別Jaの処理要求を実行するために、処理リソース種別Raの処理リソースが必要であるか否かを判定する。ここで、必要であると判定した場合ステップS1005でYES、ステップS1006に進む。一方、必要でないと判定した場合ステップS1005でNO、ステップS1007に進む。上記具体例では、処理要求種別毎の必要な処理リソース情報303よりデジタル放送をIEEE1394出力処理要求を実行するためにRemuxリソースが1以上で必要であると判定されるため、ステップS1006に進む。ステップS1006で、電力状態決定部105は、現在、処理リソース種別Raの処理リソースが利用可能か否かを判定する。ここで、利用可能と判定した場合ステップS1006でYES、ステップS1007に進む。一方、利用不可能と判定した場合ステップS1006でNO、ステップS1008に進む。上記具体例では、現在の割当可能処理リソース数700よりRemuxリソースの残数が0であり利用不可能と判定されるため、ステップS1008に進む。ステップS1008で、電力状態決定部105は、利用不可能な処理リソースが存在するために、現在、処理要求種別Jaの処理要求を受け付け不可能と判定する。上記具体例では、現在、デジタル放送をIEEE1394出力処理要求は受け付け不可能と判定される。ステップS1009に到達する場合は、必要な処理リソースがすべて利用可能なため、現在、処理要求種別Jaの処理要求を受け付け可能と判定する。以上の処理をもって、すべての処理要求種別に対して現在受け付け可能か否かが判定される。図11はステップS904によって次の処理要求として各処理要求種別の処理要求を受け付け可能か否かを判定した結果の保持例を示しており、図2~図8の具体例においてデジタル放送をHDD録画処理要求を実行中の場合の判定結果である。この例では、現在、デジタル放送をIEEE1394出力処理要求及びデジタル放送をHDD録画処理要求が受け付けられないことを表している。図12は電力状態決定部105により次の処理要求を受け付け時に各処理リソース種別の処理リソースを利用する可能性があるか否かを判定する処理の詳細を示すフローチャートであり、これは図9のステップS905に対応する。図中、ステップS1201で、電力状態決定部105は、以降のステップS1202からステップS1209までの処理を、処理リソース種別502~504のそれぞれについて実施する。ステップS1202で、電力状態決定部105は、新たに1つの処理リソース種別を取り出し、処理リソース種別Rbとする。図2~図8の具体例では、IEEE1394出力リソースが選択されたとして、以降の処理を説明する。ステップS1203で、電力状態決定部105は、以降のステップS1204からステップS1206までの処理を、現在受け付け可能な処理要求種別のそれぞれについて実施する。図11の具体例では、デジタル放送をIEEE1394出力処理要求及びデジタル放送をHDD録画処理要求以外の3つの処理要求について、以降の処理を実施する。ステップS1204で、電力状態決定部105は、新たに、現在受け付け可能な処理要求種別を1つ取り出し、処理要求種別Jbとする。図2~図8の具体例では、デジタル放送視聴A処理要求が選択されたとして、以降の処理を説明する。ステップS1205で、電力状態決定部105は、処理要求種別Jbの処理要求を実行するために処理リソース種別Rbの処理リソースが必要であるか否かを判定する。ここで、必要であると判定した場合ステップS1205でYES、ステップS1207に進む。一方、必要でないと判定した場合ステップS1205でNO、ステップS1206に進む。上記具体例では、デジタル放送視聴A処理要求の実行にあたりIEEE1394出力リソースを必要としないため、ステップS1206に進む。ステップS1207に到達した場合は、処理要求種別Jbの次の処理要求を実行する際に処理リソース種別Rbの処理リソースを利用する可能性があると判定する。ここで、一度でもこの処理ステップに到達した処理要求種別Jbは、次の処理要求を実行する際に利用される可能性がある。ステップS1208に到達した場合は、処理要求種別Jbの次の処理要求を実行する際に処理リソース種別Rbの処理リソースを利用する可能性がないと判定する。図13はステップS905によって次の処理要求で、各処理リソースが利用される可能性があるか否かを判定した結果の保持例を示しており、図2~図8の具体例においてデジタル放送をHDD録画処理要求が実行中の場合の判定結果である。この例では、現在、Remaxリソース、HDD出力リソース、及びIEEE1394出力リソースが次の処理要求で利用される可能性がないことを表している。図14は電力状態決定部105により次の処理要求で、各モジュールが利用される可能性があるか否かを判定する処理の詳細を示すフローチャートであり、これは図9のステップS906に対応する。図中、ステップS1401で、電力状態決定部105は、以降のステップS1402からステップS1410までの処理を、システムに存在するモジュールのそれぞれについて実施する。ステップS1402で、電力状態決定部105は、新たに1つのモジュールを取り出し、モジュールMとする。図2~図8の具体例では、モジュール12が選択されたとして、以降の処理を説明する。ステップS1403で、電力状態決定部105は、現在モジュールMに含まれる処理リソースが利用されているか否かを判定する。ここで、利用されていると判定した場合ステップS1403でYES、ステップS1408に進む。一方、利用されていないと判定した場合ステップS1403でNO、ステップS1404に進む。この処理ステップは、現在利用されているモジュールは、次の処理要求を受け付けても引き続き利用されつづける可能性があることを鑑み、実行される。上記具体例では、モジュール12は現在利用されていないと判定されるため、ステップS1404に進む。ステップS1404で、電力状態決定部105は、以降のステップS1405からステップS1407までの処理を、次の処理要求で利用する可能性のある処理リソース種別のそれぞれについて実施する。ステップS1405で、電力状態決定部105は、新たに1つの次の処理要求で利用する可能性のある処理リソース種別を取り出し、処理リソース種別Rcとする。上記具体例では、表1300よりチューナ入力リソースが選択されたとして、以降の説明を続ける。ステップS1406で、電力状態決定部105は、モジュールMが処理リソース種別Rcの処理リソースを提供しているか否かを判定する。ここで、提供していると判定した場合ステップS1406でYES、ステップS1408に進む。一方、提供していないと判定した場合ステップS1406でNO、ステップS1407に進む。上記具体例では、モジュール12はチューナ入力リソースを提供していないと判定されるため、ステップS1407に進む。ステップS1408に到達した場合は、次の処理要求でモジュールMを利用する可能性があると判定される。ステップS1409に到達した場合は、次の処理要求でモジュールMを利用する可能性がないと判定される。図15はステップS906によって次の処理要求で、各モジュールが利用される可能性があるか否かを判定した結果の保持例を示しており、図2~図8の具体例においてデジタル放送をHDD録画処理要求が実行中の場合の判定結果である。この例では、現在、モジュール12が次の処理要求で利用される可能性がないことを表している。また、図16は、各モジュールが利用される可能性があるか否かを判定した結果の概念図を表している。図中、1601のように太線で囲まれたモジュールが現在利用中のモジュールを表している。また、1602のように通常線で囲まれたモジュールが次の処理要求で利用される可能性のあるモジュールを表している。また、1603のように破線で囲まれたモジュールは上記の処理によって次の処理要求で利用される可能性がないと判定されたため、省電力状態に遷移可能なモジュールを表している。上記例では、モジュール12が省電力状態に遷移可能なモジュールとなる。以上説明したように、実施形態1によれば、モジュール毎に近い将来の利用可能性を判定し、その判定結果をもとに通常状態/省電力状態を切り替えて動作させることにより、システムの応答性と省電力を両立させる。より具体的には、次回の処理ステップ命令で使用される可能性のあるモジュールのみを動作させ、次回の処理ステップで利用される可能性のないモジュールは省電力状態で動作させる。これにより、システムの応答性を確保しつつも省電力を実現することが可能となる。上記具体例では、デジタル放送をHDD録画処理要求が実行中の場合は、この処理要求が実行されている間は次の処理要求にてモジュール12が利用されないと判別でき、モジュール12を省電力状態に遷移させる。これにより、システムの応答性に影響を与えないでシステムの消費電力を抑制することが可能となる。また、実施形態1では、図4に示したシステム内のモジュール構成を例に処理の詳細を説明しているが、実施形態1は、他の構成を有する情報システムにも適用可能である。<実施形態2>以下、本発明の実施形態2について、実施形態1との差異を中心に説明する。但し、本発明の技術的範囲がこの実施形態に限定されるものではない。図17は、図4のシステム400に、新たに1701で示されるモジュール13が追加された場合を想定し、モジュール毎の割当可能処理リソース情報の一例を表している。ここで、モジュールの追加はシステム起動前に発生しても良いし、システム起動中に動的に発生しても良い。図18は本発明の実施形態2の実現手順を示すフローチャートである。以下では、本フローチャートに沿って、図2~図8の具体例を交えながら説明を加える。ステップS1801で、以降のステップS1802からS807までの処理を、システムが起動している間くり返す。ステップS1802で、処理要求実行部101は、利用可能な処理モジュールが増減を監視する。ここでは、図17に示した通り新たにモジュール13としてRemaxリソースが追加されたとする。ステップS1803で、電力状態決定部105は、現在実行中の処理要求と並行し、次の処理要求として各処理要求種別を受け付け可能か否かを判定する。この判定は、各処理要求を実行するために必要な処理リソース情報と、現在の割当可能処理リソース数とを用いて実行される。尚、この処理の詳細は実施形態1に準ずる。ステップS1804で、電力状態決定部105は、次の処理要求で各処理リソースが利用される可能性があるか否かを判定する。この判定は、ステップS1803の処理結果と、各処理要求を実行するために必要な処理リソース情報とを用いて実行される。尚、この処理の詳細は実施形態1に準ずる。ステップS1805で、電力状態決定部105は、次の処理要求で各モジュールが利用される可能性があるか否かを判定する。この判定は、ステップS1804の処理結果と、モジュール毎の割当可能処理リソース情報とを用いて実行される。尚、この処理の詳細は実施形態1に準ずる。ステップS1806で、各モジュールのモジュール状態管理部106が、電力状態決定部105からの命令を受けて電力状態を変更する。この変更は、ステップS1805の処理結果を用いて実行され、該モジュールが次の処理要求で利用される可能性があると判定された場合は通常状態に、次の処理要求で利用される可能性がないと判定された場合は省電力状態に遷移する。尚、この処理の詳細は実施形態1に準ずる。以上の処理を経ることにより、例えば、デジタル放送をHDD録画処理要求が投入された場合でもRemaxリソースが枯渇しない。そのため、IEEE1394出力処理要求が実行される可能性が残り、その結果モジュール12は省電力状態に遷移しない。また、特定のモジュールの機能が停止した場合も、同様の処理フローを経ることにより各モジュールの電力状態を判定可能である。以上説明したように、実施形態2によれば、モジュール構成の変更例えば、追加を検知した場合でも、各モジュールの電力状態を再判定する構成をとることで、モジュール構成の変更に柔軟に対応した省電力制御が可能となる。尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。