JP2011130153A - ストリーム処理装置及び処理方法 - Google Patents

Abstract

【課題】複数の処理を同時に行う際に処理負荷を低減する。
【解決手段】特定の処理を行う命令の入力を受け付けて、当該処理に対応する機能を実現するための機能実現指示を出すアプリケーション部１０１と、アプリケーション部１０１からの機能実現指示を受けて、受けた機能実現指示で特定される機能を実現するドメイン部１０２と、ドメイン部１０２での処理に必要な情報を管理する処理を行うＤＢ部１０３と、ドメイン部１０２が実現する機能の一部をハードウェアで処理するようにハードウェアの制御を行うドライバ部１０４と、を備え、ドメイン部１０２、ＤＢ部１０３及びドライバ部１０４の各々は、少なくとも１つ以上の機能実現指示を受けると、受けた機能実現指示で特定される機能に対応する処理を実行し、実行した処理結果を、受けた機能実現指示の出力元の各々に返す処理を行う機能処理部により構成されている。
【選択図】図１

Description

本発明は、映像や音声等のストリームを処理する技術に関する。

従来から、複数のストリームを同時に処理する機能、例えば、同時に２つのストリームを視聴したり、視聴と同時に録画をしたり、といったように、複数の処理を同時に実行することのできるＴＶやレコーダ等のストリーム処理装置が知られている。

例えば、特許文献１には、実行する処理が主処理及び副処理に分けられ、主たるストリーム処理は高品質を保って処理し、副となるストリーム処理は小さな画像にして処理することで、簡易かつ低コストな構成により、同時にストリーム処理を行う技術が開示されている。

また、例えば、特許文献２には、サーバにおいて複数の動画コンテンツが一つの動画コンテンツにエンコーディングされ、そのエンコーディングされた動画コンテンツが装置に送信され、その動画コンテンツを受信した装置が、複数の動画コンテンツをその画面の所望の位置に出力する技術が開示されている。

特開２００８−１８２４０３号公報 特開２００８−１３６２０５号公報

しかしながら、特許文献１に記載の技術では、同時実行されている処理の画質が異なるため充分な同時実行性は実現されておらず、また、主処理及び副処理ともに同時に独立して放送を受信して表示させる処理手段を必要としており、重複した処理を複数の処理手段で行い、処理負荷が大きい。
また、特許文献２に記載の技術では、複数のストリーム処理を同時に行うデコーダ処理手段が複数あるわけではないが、複数の画面をいったんデコードして、一画面にし、さらにエンコードする処理負荷の大きい処理を行わなければならなかった。

そこで、本発明は、複数の処理を並行して行う際に、処理負荷を低減することを目的とする。

以上の課題を解決するため、本発明は、特定の処理を行う命令の入力を受け付けて、当該処理に対応する機能を実現するために当該機能を特定する情報を含む機能実現指示を出すアプリケーション部と、前記アプリケーション部から前記機能実現指示を受けて、前記アプリケーション部から受けた前記機能実現指示で特定される機能を実現するドメイン部と、前記ドメイン部での処理に必要な情報を管理する処理を行うデータベース部と、前記ドメイン部が実現する機能の少なくとも一部をハードウェアで処理するように当該ハードウェアの制御を行うドライバ部と、を備え、前記ドメイン部は、前記機能実現指示で特定される機能を実現する際に、前記データベース部及び前記ドライバ部の少なくとも何れか一方での処理が必要な場合には、前記データベース部及び前記ドライバ部の少なくとも何れか一方に対して、必要な処理に対応する機能を特定する情報を含む前記機能実現指示を出力し、前記データベース部は、前記ドメイン部又は前記アプリケーション部より前記機能実現指示を受けると、受けた前記機能実現指示で特定される機能を実現する際に、前記ドライバ部での処理が必要な場合には、前記ドライバ部に対して、必要な処理に対応する機能を特定する情報を含む前記機能実現指示を出力し、前記ドライバ部は、前記ドメイン部又は前記データベース部より前記機能実現指示を受けると、受けた前記機能実現指示で特定される機能に対応する処理を行うように前記ハードウェアを制御し、前記ドメイン部、前記データベース部及び前記ドライバ部の各々は、予め定められた機能毎に当該機能に対応する処理を実行する機能処理部を備えることにより構成されており、前記機能処理部は、前記機能実現指示を少なくとも１つ以上受けた場合には、受けた前記機能実現指示で特定される機能に対応する処理を実行し、実行した処理結果を、受けた前記機能実現指示の各々の出力元に返す処理を行うことを特徴とする。

以上のように、本発明によれば、複数の処理を並行して行う際に、処理負荷を低減することができる。

実施の形態１に係るストリーム処理装置のブロック図。 実施の形態１において、ストリーム処理装置でＴＶ放送を視聴する場合の処理の概要を示すブロック図。 実施の形態１において、ストリーム処理装置でＴＶ放送を録画する場合の処理の概要を示すブロック図。 実施の形態１において、ストリーム処理装置でＴＶ放送の視聴とＴＶ放送の録画との２つの機能が同時に実行される場合の処理の概要を示すブロック図。 実施の形態１における機能処理部のブロック図。 実施の形態１において、機能処理部が、機能実現指示に対して上位及び下位に配される場合の一例を示す概略図。 実施の形態１における機能処理部が、機能実現指示を受けた場合の処理を示すフローチャート。 実施の形態２における系処理部のブロック図。 実施の形態２において、系処理部が視聴系処理部である場合の一例を示すブロック図。 実施の形態３における系処理部のブロック図。 実施の形態３における機能順序情報テーブルの概略図。

実施の形態１．
図１は、本発明における実施の形態１に係るストリーム処理装置１００のブロック図である。図示するように、ストリーム処理装置１００は、複数のアプリケーション１０１ａ、１０１ｂ、１０１ｃ、・・・を含むアプリケーション部１０１と、複数の系処理部１０２ａ、１０２ｂ、１０２ｃ、・・・を含むドメイン部１０２と、複数のデータベース（以下、ＤＢという）処理部１０３ａ、１０３ｂ、１０３ｃ、・・・を含むＤＢ部１０３と、複数のドライバ処理部１０４ａ、１０４ｂ、１０４ｃ、・・・を含むドライバ部１０４と、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）５と、複数のハードウェア（以下、ＨＷという）６ａ、６ｂ、６ｃを含むＨＷ部１０６と、を備える。
そして、アプリケーション部１０１はドメイン部１０２及びＤＢ部１０３を利用し、ドメイン部１０２はＤＢ部１０３及びドライバ部１０４を利用し、ドライバ部１０４はＯＳ１０５を利用し、ＯＳ１０５はＨＷ部１０６を利用する。ただし、ＯＳ１０５は必ずしも必要ではなく、これがない場合においてはドライバ部１０４がＨＷ部１０６を直接利用する。

まず、本願における「機能」を定義する。「機能」とは、個々の部分が処理する単位をいい、「機能」の集合体もまた「機能」であるとする。即ち、“１を足す”は「機能」であり、“ＴＶを見る”もまた「機能」である。ただし、「機能」の規模や役割は、アプリケーション部１０１、ドメイン部１０２、ＤＢ部１０３、ドライバ部１０４のような階層によって異なり、また、各階層に含まれる部分、例えば、アプリケーション部１０１に含まれる個々のアプリケーション１０１ａ〜１０１ｃといった部分でも異なる。

ここで、アプリケーション部１０１は、例えば、図示しない入力部を介して、ユーザからの命令を受けて、この命令を実行するようにドメイン部１０２に指示を出す階層である。ドメイン部１０２は、アプリケーション部１０１からの指示を受けて、指示された機能を実現する階層である。ＤＢ部１０３は、ＨＷ部１０６に含まれる記憶装置からデータを取得し、また、ＨＷ部１０６に含まれる記憶装置にデータを格納する機能を持つ階層であって、アプリケーション部１０１、ドメイン部１０２及びドライバ部１０４にデータを提供する機能を持つ階層である。ドライバ部１０４は、システムチップ、周辺機器、入出力デバイス等のハードウェアデバイスに対する抽象化したインタフェースを提供する機能を持つ階層であり、ＨＷ部１０６やＯＳ１０５への依存を隠蔽する階層となる。ＯＳ１０５は、オペレーティングシステムであり、基本ソフトウェア機能を提供する階層である。ＨＷ部６は、物理的な構成要素であり、物理的にデータ等を処理する機能を提供する階層である。

各部分に含まれるモジュールは、各部分の中で個別の機能を持っている。例えば、図２に示すようなアプリケーション部１０１に含まれる視聴アプリケーション１０１ａ−１は、視聴に関する指示を出す機能を持ち、図３に示すような録画アプリケーション１０１ｂ−１は録画に関する指示を出す機能を持つ。

アプリケーション部１０１は、図示しない入力部を介してユーザからの命令を受けて、ドメイン部１０２に当該機能に対応する個別の機能を実現するように、当該機能を特定する情報を含む機能実現指示を出す。このとき、指示を出すために必要なデータは、ＤＢ部１０３より取得される。

機能実現指示を受けたドメイン部１０２は、機能実現指示で特定される機能に対応する処理を行い、その処理の結果をアプリケーション部１０１に返送する。ドメイン部１０２は、機能を実現する部分である。このとき、ドメイン部１０２の機能の実現に必要なデータがある場合には、ドメイン部１０２はＤＢ部１０３に機能実現指示を出し、ＤＢ部１０３から必要なデータを取得する。
また、システムやハードウェアに機能の実現をさせたい場合には、ドメイン部１０２がドライバ部１０４に機能実現指示を出す。ドライバ部１０４に実現を指示する機能は、ドメイン部１０２が実現する機能の一部であって、個別のハードウェア等によってなされる機能である。ドライバ部１０４は、ドメイン部１０２から機能の実現を指示された場合には、ＨＷ部１０６に含まれるＨＷ１０６ａ、１０６ｂ、・・・を利用して処理を行い、その処理の結果をドメイン部１０２へ返す。なお、ドライバ部１０４の機能の実現に必要なデータがある場合には、ドライバ部１０４はＤＢ部１０３に機能実現指示を出し、ＤＢ部１０３から必要なデータを取得する。

以上に記載したストリーム処理装置１００は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、メモリと、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置と、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等の可搬性を有する記憶媒体に対して情報を読み書きする読取／書込装置と、リモコンや操作ボタン等の入力装置と、ディスプレイ等の出力装置に情報を出力する出力端子と、を備えることにより実現できる。
例えば、アプリケーション部１０１、ドメイン部１０２、ＤＢ部１０３、ドライバ部１０４及びＯＳ１０５は、ＨＷ部１０６に含まれる記憶装置に記憶されている所定のプログラムをメモリにロードしてＣＰＵで実行することで実現することができ、ＨＷ部１０６は、記憶装置、読取／書込装置、入力装置、出力端子等により実現することができる。

次に、ストリーム処理装置１００で行うストリームデータの処理の一例として、ＴＶ放送を視聴する場合の処理を説明する。図２は、ストリーム処理装置１００で、ＴＶ放送を視聴する場合の処理の概要を示すブロック図である。ここで、図２は、「放送視聴開始」の命令に対応する処理を、アプリケーション部１０１にある視聴アプリケーション１０１ａ−１と、ドメイン部１０２にある視聴系処理部１０２ａ−１と、ＤＢ部１０３にあるＤＢ処理部１０３ａ−１及びＤＢ処理部１０３ｂ−１と、ドライバ部１０４にあるドライバ処理部１０４ａ−１、ドライバ処理部１０４ｂ−１及びドライバ処理部１０４ｃ−１と、ＨＷ部１０６にあるＨＷ１０６ａ−１、ＨＷ１０６ｂ−１及びＨＷ１０６ｃ−１と、を用いて実現する場合を図示したものである。

図示しない入力部（例えば、リモコンや操作ボタン等）を介して、ユーザがストリーム処理装置１００の電源を入れて、放送の視聴を開始できるように命令を送ると、アプリケーション部１０１では、視聴アプリケーション１０１ａ−１が、機能実現指示として「放送視聴開始」を実現するようドメイン部１０２の視聴系処理部１０２ａ−１に機能実現指示を送る。機能実現指示を送る方法については、例えば、メッセージ通信を利用したもの、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）をコールするようなもの、ネットワークを介して通信で送るようなもの等、様々な方法があるが、それらのいずれであってもよい。

このとき、指示を与えるために必要なデータ、例えば、視聴開始時の状態として以前視聴していたチャンネル番号データや、子供による機器の利用を、親が監視して制限するペアレンタルコントロールのためのユーザ情報等のデータ、が必要になるので、視聴アプリケーション１０１ａ−１は、ＤＢ部１０３から必要なデータを取得する。取得したデータについては、アプリケーション部１０１の視聴アプリケーション１０１ａ−１が、例えば、取得したチャンネル番号が以前視聴したデータとして設定されていないことを示すデータであれば、代わりにデフォルトチャンネル番号データに変更する等、データの意味解釈からの処理を行う。即ち、ＤＢ部１０３はデータを格納するが、その意味解釈は行わず、格納されたデータを使用する部分（この場合はアプリケーション部１０１）が意味解釈を行う。

アプリケーション部１０１から機能実現指示である「放送視聴開始」を送られたドメイン部１０２の視聴系処理部１０２ａ−１は、当該機能を実現する。このとき、当該機能の実現にドライバ部１０４やＯＳ１０５の機能を使用する場合、例えば、（１）ストリームデータの入力にＴＶチューナという物理ハードウェアで放送の選局を行う、（２）ストリームデータのデコードにハードウェアデコーダを使用する、といった場合、ドメイン部１０２の視聴系処理部１０２ａ−１は、これらの機能を実現することのできるドライバ部１０４のドライバ処理部やＯＳ１０５に個別に機能実現指示を送る。また、ドメイン部１０２の視聴系処理部１０２ａ−１は、機能を実現するために必要なデータ、例えば、放送番組の構成データ、ストリームに含まれるペアレンタル情報、番組変更情報等をＤＢ部１０３から取得する。

ドライバ部１０４のチューナ制御を行うドライバ処理部１０４ａ−１は、ドメイン部１０２の視聴系処理部１０２ａ−１から機能実現指示である「チューナ選局」指示を受け取り、ＨＷ部１０６に含まれるＴＶチューナに対応するハードウェアデバイスであるＨＷ１０６ａ−１を使って、物理的に選局動作を行う。ドライバ処理部１０４ａ−１は、選局指示されたチャンネルの周波数へのチューニング指示をＨＷ１０６ａ−１に固有の指示コマンド、例えば、特定のレジスタへの周波数値の書き込み等に変換して、ＨＷ１０６ａ−１を使う。

ＨＷ部１０６のＨＷ１０６ａ−１は、ドライバ部１０４のドライバ処理部１０４ａ−１から、（ＯＳ１０５が存在するような場合であればＯＳ１０５を通して）選局コマンドを受け取り、この選局コマンドに基づく処理を行う。システムによっては、ＯＳ１０５が存在しない場合もあるが、この場合においては、ドライバ部１０４からＨＷ部１０６に直接選局コマンドが受け渡される。

次に、ストリーム処理装置１００で行うストリームデータの処理の他の例として、ＴＶ放送を録画する場合の処理を説明する。図３は、ストリーム処理装置１００で、ＴＶ放送を録画する場合の処理の概要を示すブロック図である。ここで、図３は、「放送録画開始」の命令に対応する処理を、アプリケーション部１０１にある録画アプリケーション１０１ｂ−１と、ドメイン部１０２にある録画系処理部１０２ｂ−１と、ＤＢ部１０３にあるＤＢ処理部１０３ａ−１及びＤＢ処理部１０３ｂ−１と、ドライバ部１０４にあるドライバ処理部１０４ａ−１、ドライバ処理部１０４ｂ−１及びドライバ処理部１０４ｃ−１と、ＨＷ部１０６にあるＨＷ１０６ａ−１、ＨＷ１０６ｂ−１及びＨＷ１０６ｃ−１と、を用いて実現する場合を図示したものである。

図示しない入力部を介して、ユーザがストリーム処理装置１００に録画を開始する命令を送ると、アプリケーション部１０１では、録画アプリケーション１０１ｂ−１が、機能実現指示として「放送録画開始」を実現するようドメイン部１０２の録画系処理部１０２ｂ−１に機能実現指示を送る。機能実現指示を送る方法については、例えば、メッセージ通信を利用したもの、ＡＰＩをコールするようなもの、ネットワークを介して通信で送るようなもの等、様々な方法があるが、そのいずれであってもよい。

このとき、機能実現指示を与えるために必要なデータ、例えば放送録画開始時の状態として録画すべきチャンネル番号データや、ペアレンタルコントロールのためのユーザ情報等のデータが必要になるので、録画アプリケーション１０１ｂ−１は、ＤＢ部１０３から必要なデータを取得する。取得したデータについては、アプリケーション部１０１の録画アプリケーション１０１ｂ−１が、例えば、取得したチャンネル番号が現在視聴中のチャンネル番号のデータと同一であるかどうかを判別する等、データの意味解釈からの処理を行う。即ち、ＤＢ部１０３は、データを格納するが、その意味解釈は行わず、格納されたデータを使用する部分（この場合はアプリケーション部１０１）が、その意味解釈を行う。

アプリケーション部１０１から機能実現指示である「放送録画開始」を送られたドメイン部１０２の録画系処理部１０２ｂ−１は、当該機能を実現する。このとき、当該機能の実現にドライバ部１０４やＯＳ１０５の機能を使用する場合、例えば、（１）ストリームデータの入力にＴＶチューナという物理ハードウェアで放送の選局を行う、（２）ストリームデータのデコードにハードウェアデコーダを使用する、といった場合、ドメイン部１０２の録画系処理部１０２ｂ−１は、これらの機能を実現することのできるドライバ部１０４のドライバ処理部やＯＳ１０５に個別に機能実現指示を送る。また、ドメイン部１０２の録画系処理部１０２ｂ−１は、機能を実現するために必要なデータ、例えば、放送番組の構成データ、ストリームに含まれるペアレンタル情報、データ放送情報の有無等を、ＤＢ部１０３から取得する。

ドメイン部１０２から機能実現指示である「チューナ選局」指示を受け取ったドライバ部１０４では、ドライバ部１０４に含まれるチューナ制御を行うドライバ処理部１０４ａ−１によってＨＷ部１０６を使って物理的に選局動作を行う。ドライバ部１０４のドライバ処理部１０４ａ−１は、選局指示されたチャンネルの周波数へのチューニング指示をＨＷに固有の指示コマンド、例えば、特定のレジスタへの周波数値の書き込み等に変換してＨＷ部１０６を使う。

ＨＷ部１０６のＨＷ１０６ａ−１は、ドライバ部１０４から、（ＯＳ１０５が存在するような場合であればＯＳ１０５を通して）選局コマンドを受け取ると、選局コマンドに対応する処理を行う。システムによってはＯＳ１０５が存在しない場合もあるが、この場合においては、ＨＷ部１０６からドライバ部１０４に直接選局コマンドが受け渡される。

図２に示すようなストリーム処理装置１００でＴＶ放送を視聴する場合と、図３に示すようなストリーム処理装置１００でＴＶ放送を録画する場合と、を比べると、「放送視聴開始」命令や、「放送録画開始」命令や、データの流れから分かるように、ある機能が実現されるための機能実現指示やデータの流れは同様である。
また、例示した「放送視聴開始」命令と「放送録画開始」命令とが出力された場合では、ストリーム処理装置１００の各階層で同様の機能として、即ち、ドメイン部１０２ではＴＶチューナへの選局やデコードの指示、ドライバ部１０４では、チューナ制御、デコーダ制御等が行われている。

次に、ストリーム処理装置１００でストリームデータの処理を並行して行う一例として、ＴＶ放送を視聴する処理とＴＶ放送を録画する処理とを並行して行う場合を説明する。図４は、ストリーム処理装置１００で、ＴＶ放送の視聴とＴＶ放送の録画との２つの機能が、並行して実行される場合の処理の概要を示すブロック図である。ここで、図４では、既にユーザがＴＶ放送の視聴を行っている状態からＴＶ放送の録画を開始する場合を例に説明する。

ユーザがＴＶ放送の視聴を開始する動作は、図２に示されている通りである。ここで、さらに、図示しない入力部を介して、ユーザより「放送録画開始」命令が与えられると、アプリケーション部１０１の録画アプリケーション１０１ｂ−１は、ドメイン部１０２の録画系処理部１０２ｂ−１に対して放送録画開始を実現するよう機能実現指示を送る。

このとき、録画アプリケーション１０１ｂ−１はドメイン部１０２の録画系処理部１０２ｂ−１に機能実現指示を与えるために必要なデータをＤＢ部１０３から取得する。所望のデータを持つＤＢ処理部は、視聴アプリケーション１０１ａ−１が使用しているＤＢ処理部と同一である場合がある。ＤＢ処理部は、それぞれ異なるアプリケーションや系処理部等から同じデータの取得要求があっても、要求されたデータを返送することができる。この仕組みについては、後述する。そこで、録画アプリケーション１０１ｂ−１はこれらのデータをＤＢ部１０３から取得して、ドメイン部１０２の録画系処理部１０２ｂ−１に対して機能実現指示を送る。

ドメイン部１０２の録画系処理部１０２ｂ−１は、「放送録画開始」の機能実現指示を受け取ると、当該機能実現指示で特定される機能を実現する。このとき、録画系処理部１０２ｂ−１は、当該機能の実現にドライバ部１０４やＯＳ１０５の機能を使用する場合には、その機能を実現することのできるドライバ部１０４のドライバ処理部やＯＳ１０５に個別に機能実現指示を送る。ドライバ部１０４では、視聴系処理部１０２ａ−１と録画系処理部１０２ｂ−１からドライバ部１０４のドライバ処理部１０４ａ−１、ドライバ処理部１０４ｂ−１及びドライバ処理部１０４ｃ−１が機能実現指示を受けるが、ＤＢ処理部と同様に、複数の指示を受けることができる。この仕組みについては、後述する。
そこで、視聴系処理部１０２ａ−１と録画系処理部１０２ｂ−１は、ドライバ部１０４のドライバ処理部１０４ａ−１、ドライバ処理部１０４ｂ−１及びドライバ処理部１０４ｃ−１の各々に機能実現指示を与えて放送録画開始機能を実現する。放送録画開始機能に必要なデータについても、アプリケーションと同様に、ＤＢ部１０３から取得する。

ドライバ処理部１０４ａ−１は、録画系処理部１０２ｂ−１から個別の機能実現指示である「チューナ選局」の機能実現指示を受け取り、この機能実現指示に基づいて、ＨＷ部１０６のＴＶチューナに対応するハードウェアデバイスであるＨＷ１０６ａ−１を使って物理的に選局動作を行う。

ＨＷ部１０６のＨＷ１０６ａ−１は、ドライバ部１０４から、（ＯＳ１０５が存在するような場合であればＯＳ１０５を通して）選局コマンドを受け取り、選局コマンドに基づいたハードウェアの動作を行う。

次に、図４に示すようなストリーム処理装置１００での機能の同時実行の仕組みを説明する。図５は、ドメイン部１０２、ＤＢ部１０３及びドライバ部１０４での機能を処理する機能処理部１０７のブロック図である。

ここで、ドメイン部１０２、ＤＢ部１０３及びドライバ部１０４の各々は、少なくとも１つ以上の機能処理部１０７で構成されている。例えば、図１の例では、ドメイン部１０２を１つの機能処理部１０７で構成してもよく、また、ドメイン部１０２に含まれる系処理部１０２ａ、１０２ｂ、１０２ｃ、・・・の各々を機能処理部１０７として構成してもよく、さらに、系処理部１０２ａ、１０２ｂ、１０２ｃ、・・・の各々に含まれる機能をさらに細分化して、細分化された各々の機能を機能処理部１０７で構成してもよい。

図示するように、機能処理部１０７は、少なくとも１つの機能提供ＩＦ部１０７ａ−１、１０７ａ−２、１０７ａ−３、・・・と、機能調停部１０７ｂと、機能処理コア部１０７ｃと、機能要求ＩＦ部１０７ｄと、を備える。なお、機能提供ＩＦ部１０７ａ−１、１０７ａ−２、１０７ａ−３、・・・の各々を特に区別する必要のないときは、機能提供ＩＦ部１０７ａという。

機能提供ＩＦ部１０７ａは、機能実現指示を送出してきた他の機能処理部１０７ａやアプリケーション部１０１のアプリケーションとの間の情報のやりとりを行うインタフェースとして機能する部分である。なお、機能提供ＩＦ部１０７ａは、受け取った機能実現指示より、他の機能処理部１０７やアプリケーション部１０１のアプリケーションとの間の情報のやりとりを行うために必要な通信情報、例えば、他の機能処理部１０７やアプリケーション部１０１のアプリケーションを識別するための識別情報等を取得して、保持する。
さらに、このような通信情報については、ＤＢ部１０３を介して保持しておき、機能提供ＩＦ部１０７ａで処理を行う際に、機能要求ＩＦ部１０７ｄを介して、ＤＢ部１０３より取得するようにしてもよい。

機能処理部１０７は、機能実現指示が与えられると、各々の機能実現指示毎に異なる機能提供ＩＦ部１０７ａを生成する。機能実現指示を与えられた機能提供ＩＦ部１０７ａは、それぞれ機能調停部１０７ｂに当該機能実現指示を送る。

機能調停部１０７ｂでは、機能処理ＩＦ部１０７ａより送られてきた機能実現指示で特定される機能を機能処理部１０７で実現ができるかどうか、を判断する。例えば、機能調停部１０７ｂは、受け取った機能実現指示で特定される機能をすぐに機能処理コア部１０７ｃで処理できるかどうか、かつ、受け取った機能実現指示で特定される機能の一部又は全部の機能を実現する機能実現指示を機能要求ＩＦ部１０７ｄから他の機能処理部１０７に送信することができ、他の機能処理部１０７で実現できるかどうか、を判断する。

例えば、機能調停部１０７ｂは、機能処理コア部１０７ｃで処理することのできる機能の一覧を特定する実行可能機能一覧情報と、機能処理コア部１０７ｃで処理することのできる機能において同時に処理することのできる同時実行可能数を特定する同時実行可能数情報と、機能処理コア部１０７ｃにおいて処理実行中の機能及び当該機能の処理実行数を特定する処理中機能情報と、機能要求ＩＦ部１０７ｄで機能実現指示を送信することのできる機能の一覧を特定する依頼機能一覧情報と、を保持している。
そして、機能調停部１０７ｂは、機能提供ＩＦ部１０７ａより与えられた機能実現指示で特定される機能が機能処理コア部１０７ｃで処理することのできる機能であるか否か、当該機能実現指示で特定される機能の処理実行数が同時実行可能数以下であるか否か、当該機能実現指示で特定される機能の一部又は全部が機能要求ＩＦ部１０７ｄで機能実現指示を送信することのできる機能であるか否か、を判断する。
さらに、機能調停部１０７ｂは、当該機能実現指示で特定される機能の一部又は全部が機能要求ＩＦ部１０７ｄで他の機能処理部１０７に機能実現指示を送信することのできる機能である場合には、機能処理コア部１０７ｃ及び機能要求ＩＦ部１０７ｄを介して、当該他の機能処理部１０７に機能実現指示を出力し、出力した機能実現指示への返信を受けることにより、出力した機能実現指示で特定する機能の実現の可又は不可を判断する。

そして、機能調停部１０７ｂは、機能処理ＩＦ部１０７ａより送られてきた機能実現指示で特定される機能を機能処理部１０７で実現できる場合には、実現可であることを特定する通知を、当該機能実現指示を送ってきた機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う。また、機能調停部１０７ｂは、当該機能実現指示で特定される機能を機能処理部１０７で実現できない場合には、実現不可であることを特定する通知を、当該機能実現指示を送ってきた機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う。

なお、機能調停部１０７ｂは、機能実現指示が複数きた場合に、指示を常に受け付け順序化して処理するか、又は、同時並行的に機能を実現するか、を機能処理コア部１０７ｃで処理することのできる機能毎に特定する処理状況情報を保持している。そして、機能調停部１０７ｂは、機能処理ＩＦ部１０７ａより送られてきた機能実現指示で特定される機能を機能処理部１０７で実現ができる場合には、実現可であること特定する通知とともに、指示を常に受け付け順序化して処理するか、又は、同時並行的に機能を実現するか、を特定する情報を、当該機能実現指示を送ってきた機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う。
ここで、機能調停部１０７ｂは、指示を常に受け付け順序化して処理することを特定する情報を返信する場合には、処理実行数も併せて通知する。

即ち、機能処理部１０７では、上位やシステム全体としての機能実現の要否判断は行わず、自身の機能の実現可否判断及び実現処理のみを行う。機能処理部１０７から実現不可であることを特定する情報が通知された当該モジュール（機能処理部１０７又はアプリケーション部１０１のアプリケーション）は、時間をおいてリトライするか、機能が実現できないものとするか等の判断と処理を行う。なお、この判断は、機能処理部１０７においては、機能処理コア部１０７ｃが行う。

機能調停部１０７ｂで機能の実現が可とされた指示は、機能処理コア部１０７ｃで処理する。従って、機能処理部１０７の機能を実現する主体は、この機能処理コア部１０７ｃである。ここで、機能処理コア部１０７ｃが実現する機能毎に、１つの機能処理部１０７が設けられることが望ましい。さらに、機能調停部１０７ｂは、他の機能処理部１０７、ＯＳ１０５又はＨＷ部１０６より、機能の実現不可であることを特定する情報が通知された場合、及び、機能の実現可であることを特定する情報及び指示を常に受け付け順序化して処理することを特定する情報が通知された場合には、機能処理コア部１０７ｃの判断に応じて、実現不可であることを特定する通知を、機能調停部１０７ｂ及び当該機能実現指示を送ってきた機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う。

機能処理コア部１０７ｃは、機能毎に、当該機能の一部又は全部が、他の機能処理部１０７又はＨＷ部１０６での処理が必要であるか否か、を特定する指示機能情報を保持している。そして、機能処理コア部１０７ｃは、機能調停部１０７ｂで機能の実現が可能とされた指示のうち、他の機能処理部１０７での処理が必要であると判断された機能（処理）がある場合には、機能要求ＩＦ部１０７ｄに対して、他の機能処理部１０７に機能実現指示を出力させる命令を行う。

また、機能処理コア部１０７ｃは、他の機能処理部１０７、ＯＳ１０５又はＨＷ部１０６より、機能の実現不可であることを特定する情報が通知された場合には、時間をおいてリトライするか、機能が実現できないものとするか等の判断と処理を行い、当該機能が実現できないと判断した場合には、実現不可であることを特定する通知を出すように、機能調停部１０７ｂに命令する。

さらに、機能処理コア部１０７ｃは、機能の実現不可であることを特定する情報が通知された場合、及び、機能の実現可であることを特定する情報及び指示を常に受け付け順序化して処理することを特定する情報が通知された場合には、これらの通知に含まれている処理実行数を参照して、この処理実行数が機能毎に予め定められている閾値を超えているときには、機能を実現できないものと判断し、実現不可であることを特定する通知を出すように、機能調停部１０７ｂに命令する。

機能要求ＩＦ部１０７ｄは、機能処理コア部１０７ｃより、他の機能処理部１０７又はＨＷ部１０６での機能処理をさせる命令を受けた場合には、当該機能処理の対象となっている機能を担当する他の機能処理部１０７又はＨＷ部１０６のＨＷに対して、機能実現指示を与える。
ここで、機能要求ＩＦ部１０７ｄは、機能毎に、当該機能を実現するための機能実現指示を出力する指示先を特定する情報、例えば、機能実現指示を出力先である他の機能処理部１０７又はＨＷ部１０６のＨＷを識別するための識別情報等を有する指示先情報を保持しているものとする。

ここで、上述した、通信情報、実行可能機能一覧情報、同時実行可能数情報、処理中機能情報、依頼機能一覧情報、処理状況情報、指示機能情報及び指示先情報については、機能処理部１０７に記憶部を設けておき、この記憶部に記憶しておいてもよい。また、ＤＢ部１０３を介して、又は、ＤＢ部１０３を構成する機能処理部１０７では直接、これらの情報をＨＷ部１０６の記憶装置に保持するようにしてもよい。なお、これらの情報をＨＷ部１０６の記憶装置に保持するようにした場合には、機能処理部１０７での処理を開始するタイミング等、予め定められたタイミングでＨＷ部１０６の記憶装置より取得すればよい。

機能処理部１０７は、機能実現指示に対して、上位及び下位に配されることがある。機能実現指示の内容に応じて、例えば、図６に示すように、機能処理部１０７−４は、上位に配置された３つの機能処理部１０７−１、１０７−２、１０７−３からの機能実現指示を受け、当該機能実現指示で特定される機能を実現する。このとき、機能処理部１０７−４は、必要に応じて、下位に配置された他の２つの機能処理部１０７−５、１０７−６に機能の実現を行わせるように、機能実現指示を出力するような構成を取ることがある。

ここで、ＤＢ部１０３に設けられる機能処理部１０７の場合には、例えば、機能処理コア部１０７ｃが提供するデータを１つだけ持ち、どの機能提供ＩＦ部１０７ａやアプリケーション部１０１からの機能実現指示に対しても、同じデータの返送指示であれば同じデータを返送するように動作する。

図７は、以上のように構成される機能処理部１０７で、機能実現指示を受けた場合の処理を示すフローチャートである。

まず、機能処理部１０７は、他の機能処理部１０７ａ又はアプリケーション部１０１のアプリケーションより、機能実現指示を受信すると（Ｓ１０でＹｅｓ）、当該機能実現指示に対応する機能提供ＩＦ部１０７ａを生成する（Ｓ１１）。ここで、機能提供ＩＦ部１０７ａは、ステップＳ１０で受信した機能実現指示より、当該機能実現指示を送出してきた他の機能処理部１０７やアプリケーション部１０１のアプリケーションとの間の情報のやりとりを行うために必要な通信情報を取得して、保持する。

次に、機能提供ＩＦ部１０７ａは、機能調停部１０７ｂにステップＳ１０で受信した機能実現指示を与える（Ｓ１２）。
そして、機能調停部１０７ｂは、機能処理ＩＦ部１０７ａより与えられた機能実現指示で特定される機能を機能処理部１０７で実現ができるかどうかを判断する（Ｓ１３）。そして、機能調停部１０７ｂは、実現できると判断した場合（ステップＳ１３でＹｅｓ）にはステップＳ１４の処理に進み、実現できないと判断した場合（ステップＳ１３でＮｏ）にはステップＳ２５の処理に進む。

なお、ステップＳ１３での処理の具体例としては、例えば、機能調停部１０７ｂは、実行可能機能一覧情報に、機能処理ＩＦ部１０７ａより与えられた機能実現指示で特定される機能が含まれるか否かを判断し、含まれない場合には、機能実現指示で特定される機能は実現不可であると判断する。一方、機能調停部１０７ｂは、実行可能機能一覧情報に、機能実現指示で特定される機能が含まれる場合には、処理中機能情報より、このような機能が実行中であるか否かを特定し、実行中である場合には、処理中機能情報より、このような機能の処理実行数を取得する。
そして、機能調停部１０７ｂは、処理中機能情報より取得した処理実行数が、同時実行可能数情報より同時に実行することができる同時実行可能数未満であるか否かを確認し、同時実行可能数未満ではない場合には実現不可であると判断し、同時実行可能数未満である場合には実現可能であると判断する。
なお、機能調停部１０７ｂは、実行可能機能一覧情報に、機能処理ＩＦ部１０７ａより与えられた機能実現指示で特定される機能が含まれる場合であって、処理中機能情報より、このような機能が実行中ではないときには、機能処理ＩＦ部１０７ａより与えられた機能実現指示で特定される機能を実行可能であると判断する。

ステップＳ１４では、機能調停部１０７ｂは、機能提供ＩＦ部１０７ａより与えられた機能実現指示で特定される機能を機能処理コア部１０７ｃに実行するように指示を出す。
このような指示を受けた機能処理コア部１０７ｃは、指示機能情報より、機能実現指示で特定される機能を実行する際に、当該機能の一部又は全部に、他の機能処理部１０７での処理が必要であるか否かを判断する（Ｓ１５）。そして、機能処理コア部１０７ｃは、機能実現指示で特定される機能の一部又は全部が、他の機能処理部１０７での処理が必要ない場合（ステップＳ１５でＮｏ）には、ステップＳ１６の処理に進み、機能実現指示で特定される機能の一部又は全部が、他の機能処理部１０７での処理が必要である場合（ステップＳ１５でＹｅｓ）には、ステップＳ１７の処理に進む。

ステップＳ１６では、機能処理コア部１０７ｃは、機能調停部１０７ｂに対して、指示された機能を実現することができる旨の通知を行い、機能調停部１０７ｂは、実現可であることを特定する通知を、ステップＳ１１で生成された機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う。
なお、機能調停部１０７ｂは、処理中機能情報より、ステップＳ１０で受信した機能実現指示以外の機能実現指示に応じて、既に機能処理コア部１０７ｃで処理を行っている場合には、ステップＳ１０で受信した機能実現指示に対して、指示を常に受け付け順序化して処理するか、又は、同時並行的に機能を実現するか、を特定する情報と、指示を常に受け付け順序化して処理する場合には処理実行数を特定する情報を含めて、実現可であることを特定する通知とともに、返信する処理を行う。
このとき、機能処理コア部１０７ｃは、処理中機能情報の処理実行数に「１」をインクリメントして、処理実行数を更新する。

一方、ステップＳ１７では、機能要求ＩＦ部１０７ｄが、指示先情報に基づいて、他の機能処理部１０７に対して、機能実現指示を出力する。

そして、機能処理コア部１０７ｃは、機能要求ＩＦ部１０７ｄから機能実現指示を出力した他の機能処理部１０７より、実現不可の通知を受信したか否かを確認する（Ｓ１８）。そして、機能処理コア部１０７ｃは、実現不可の通知を受信した場合（ステップＳ１８でＹｅｓ）にはステップＳ２０の処理に進み、実現不可の通知を受信していない場合（ステップＳ１８でＮｏ）にはステップＳ１９の処理に進む。

ステップＳ１９では、機能処理コア部１０７ｃは、機能要求ＩＦ部１０７ｄから機能実現指示を出力した他の機能処理部１０７の全てより、実現可の通知を受信したか否かを確認する。そして、機能処理コア部１０７ｃは、機能実現指示を出力した他の機能処理部１０７の全てより実現可の通知を受信した場合（ステップＳ１９でＹｅｓ）にはステップＳ２０の処理に進み、機能実現指示を出力した他の機能処理部１０７の全てより実現可の通知を受信していない場合（ステップＳ１９でＮｏ）にはステップＳ１８の処理に戻る。

ステップＳ２０では、機能処理コア部１０７ｃは、ステップＳ１４で指示された機能を実現することができるか否かを判断する。そして、実現することができる場合（ステップＳ２０でＹｅｓ）にはステップＳ２１に進み、実現することができない場合（ステップＳ２０でＮｏ）にはステップＳ２５に進む。
例えば、機能処理コア部１０７ｃは、ステップＳ１８で実現不可の通知を受けた場合には、ステップＳ１４で指示された機能の属性に応じて、リトライ等の処理を行い、それでも実現可の通知を受けることができない場合には、ステップＳ１４で指示された機能を実現することができないと判断する。
また、機能処理コア部１０７ｃは、ステップＳ１９で実現可の通知を受信した場合でも、指示を常に受け付け順序化して処理する旨の通知を伴っている場合には、ステップＳ１４で指示された機能の属性に応じて、処理実行数が予め定められている閾値を超えている場合には、ステップＳ１４で指示された機能を実現することができないと判断する。
一方、機能処理コア部１０７ｃは、ステップＳ１９で実現可の通知を受信した場合であって、指示を常に受け付け順序化して処理する旨の通知及び同時並行的に機能を実現する旨の通知を伴っていないときには、ステップＳ１４で指示された機能を実現することができると判断する。
例えば、処理を指示する先の機能処理部１０７が未だ機能実現指示を受けていないとき、同時並行的に機能を実現する旨の通知を伴っているとき、又は、指示を常に受け付け順序化して処理する旨の通知を伴っていても、ステップＳ１４で指示された機能の属性に応じて、処理実行数が予め定められている閾値を超えていないとき、には、指示を常に受け付け順序化して処理する旨の通知及び同時並行的に機能を実現する旨の通知を伴っていないことになる。

ステップＳ２１では、機能処理コア部１０７ｃは、機能調停部１０７ｂに対して、指示された機能を実現することができる旨の通知を行い、機能調停部１０７ｂは、実現可であることを特定する通知を、ステップＳ１１で生成された機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う。
なお、このとき、機能調停部１０７ｂは、処理中機能情報より、ステップＳ１０で受信した機能実現指示以外の機能実現指示に応じて、既に機能処理コア部１０７ｃで処理を行っている場合には、ステップＳ１０で受信した機能実現指示に対して、指示を常に受け付け順序化して処理するか、又は、同時並行的に機能を実現するか、を特定する情報と、指示を常に受け付け順序化して処理する場合には処理実行数を特定する情報を含めて、実現可であることを特定する通知とともに、返信する処理を行う。
このとき、機能処理コア部１０７ｃは、処理中機能情報の処理実行数に「１」をインクリメントして、処理実行数を更新する。

次に、機能処理コア部１０７ｃは、機能要求ＩＦ部１０７ｄから機能実現指示を出力した他の機能処理部１０７の全てより、指示した機能の処理結果を受信したか否かを確認する（Ｓ２２）。そして、指示した機能の処理結果を全て受信した場合には（ステップＳ２２）、ステップＳ２３に進む。

ステップＳ２３では、ステップＳ２２で受信した処理結果に基づき、機能処理コア部１０７ｃが必要な処理を実行する（Ｓ２３）。ここで、機能処理コア部１０７ｃは、機能調停部１０７ｂより複数の機能に対応する処理の指示を受けている場合には、機能処理コア部１０７ｃが処理を行う機能の属性に応じて、複数の処理を順番に行うか、又は、複数の処理を同時に並行して行う。
そして、機能処理コア部１０７ｃは、ステップＳ２３で実行した機能の結果である処理結果を機能調停部１０７ｂに出力し、機能調停部１０７ｂは、受け取った処理結果を、ステップＳ１１で生成された機能処理ＩＦ部１０７ａを介して、機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに返信する処理を行う（Ｓ２４）。

一方、ステップＳ２５では、機能調停部１０７ｂは、機能処理ＩＦ部１０７ａより送られてきた機能実現指示に対して、実現不可であることを特定する通知を、当該機能実現指示を送ってきた機能処理ＩＦ部１０７ａを介して、当該機能実現指示を送ってきた機能処理部１０７又はアプリケーション部１０１のアプリケーションに対して返信する処理を行う。

そして、機能調停部１０７ｂは、ステップＳ１１で作成した機能提供ＩＦ部１０７ａを削除する（Ｓ２６）。

以上のように本実施の形態では、ユーザからの命令に相応する機能を動かす機能実現指示を出す階層、機能実現指示を受けて指示された機能を実現する階層、データを取得又は格納する階層、ハードウェアデバイスに対して抽象化したインタフェースを提供する機能を持つ階層、基本ソフトウェア機能を提供する階層、を構成し、また、ドメイン部１０２、ＤＢ部１０３、ドライバ部１０４が機能処理部１０７として複数の機能の処理を同時に受け付けて処理することができるようにされているため、機能を同時実行させるために必要な構成部分を減少させることができる。これによって、装置に必要となるメモリや構成部品を減少させることができる。

また、本実施の形態では、ＴＶ放送を視聴する場合においても録画する場合においても、同じのＤＢ部１０３からデータを取得すればよく、例えば、ペアレンタルコントロール情報等、装置内に持つデータを１種類につき１つにしておくことができるため、データ格納領域を少なくすることができる。

また、各機能の実現が各階層の個々の機能処理部１０７で実現されており、同一機能は同じ機能処理部１０７で実現できる。また、機能を拡張する必要があっても拡張する機能に必要な階層で、必要な機能処理部１０７を増やせばよいだけなので、構成部品、特にメモリ量等を低減することができる。また、追加する部分が少なく済むため、機能の拡張にかかる部分を減少させることができる。

実施の形態２．
次に、本発明における実施の形態２について説明する。本実施の形態２ではドメイン部１０２内での処理の一例の詳細について説明する。

図８は、実施の形態２における系処理部２０２ａのブロック図である。ここで、系処理部２０２ａはある個別の機能を実現する。図示するように、系処理部２０２ａは、系制御部２０２ａ−１と、少なくとも１つのエフェクタ２０２ａ−２、２０２ａ−３、２０２ａ−４、２０２ａ−５、・・・と、少なくとも１つの下位機能部２０２ａ−６、２０２ａ−７、２０２ａ−８、２０２ａ−９、２０２ａ−１０、２０２ａ−１１、２０２ａ−１２、２０２ａ−１３、２０２ａ−１４、２０２ａ−１５、・・・と、を有する。

系制御部２０２ａ−１は、系処理部２０２ａの個別の機能を実現するシーケンス制御を行う。ここでシーケンス制御とは、系処理部２０２ａの個別の機能を実現するための過程に従って当該個別の機能を分割した分割機能を順に達成することで、当該個別の機能を実現する制御である。そして、シーケンス制御においては、系制御部２０２ａ−１は、このような分割機能の実現状態（機能実現状態）を確認することで、次の分割機能に対応する処理を実行させるように制御する。

ここで、本実施の形態においては、分けられた分割機能の各々を実現する制御を行うものをエフェクタとし、系制御部２０２ａ−１は、エフェクタからの応答もしくは通知によって機能実現状態を遷移させ、遷移後の機能実現状態に対応する分割機能を実現する別のエフェクタを順に動作させるようにしている。

そして、各エフェクタ２０２ａ−２、２０２ａ−３、２０２ａ−４、２０２ａ−５、・・・は、系制御部２０２ａ−１からの制御によって、各エフェクタ２０２ａ−２、２０２ａ−３、２０２ａ−４、２０２ａ−５、・・・の下位機能部２０２ａ−６、２０２ａ−７、２０２ａ−８、２０２ａ−９、２０２ａ−１０、２０２ａ−１１、２０２ａ−１２、２０２ａ−１３、２０２ａ−１４、２０２ａ−１５、・・・を制御して、各機能実現状態に対応する分割機能を実現する。系制御部２０２ａ−１から制御されるエフェクタの数は個別の機能を実現するための過程（状態）数と同一であり、例えば、１つであってもよく、また、複数であってもよい。

下位機能部２０２ａ−６、２０２ａ−７、２０２ａ−８、２０２ａ−９、２０２ａ−１０、２０２ａ−１１、２０２ａ−１２、２０２ａ−１３、２０２ａ−１４、２０２ａ−１５、・・・は、エフェクタの下位にあり、上位にあるエフェクタが実現する分割機能の全部又は一部に対応する下位機能を実現する。系処理部２０２ａが実現する個別の機能に含まれる分割機能の種別によって１つのエフェクタが選択され、動作する。分割機能の種別は、エフェクタの付帯状況であって、個別の機能を実現のための各々の処理（分割機能）で異なるものである。

それぞれのエフェクタから制御される下位機能部の数は当該エフェクタが持つ種別の数により、例えば、１つであってもよく、また、複数であってもよい。

そして、系制御部２０２ａ−１、少なくとも１つのエフェクタ２０２ａ−２、２０２ａ−３、２０２ａ−４、２０２ａ−５、・・・、及び、少なくとも１つの下位機能部２０２ａ−６、２０２ａ−７、２０２ａ−８、２０２ａ−９、２０２ａ−１０、２０２ａ−１１、２０２ａ−１２、２０２ａ−１３、２０２ａ−１４、２０２ａ−１５、・・・、のそれぞれを図５に記載した機能処理部１０７で構成することにより、複数の機能の処理を同時に受け付けて実行することができるようになる。

図９は、実施の形態２において、系処理部２０２ａが視聴系処理部３０２ａである場合の一例を示すブロック図である。

視聴系処理部３０２ａは、映像音声ストリームの入力を受け、その映像音声ストリームの内容をユーザに提示又は出力する視聴機能を個別の機能として実現する。そして、視聴系処理部３０２ａでは、視聴系制御部３０２ａ−１が、個別の機能としての視聴機能を実現するための分割機能として、フロントエンド３０２ａ−２、セレクタ３０２ａ−３、著作権管理３０２ａ−４、プレイヤ３０２ａ−５及び出力ユニット３０２ａ−６に対応するエフェクタを生成する。

ここで、フロントエンド３０２ａ−２のエフェクタは、映像音声ストリームの入力を行う分割機能を実現する。
セレクタ３０２ａ−３のエフェクタは、映像音声ストリームから視聴する番組やコンテンツを選択する分割機能を実現する。
著作権管理３０２ａ−４のエフェクタは、番組やコンテンツに施された著作権に従って番組やコンテンツをデスクランブルしたり又はデクリプトしたりといった出力の制限を行う分割機能を実現する。
プレイヤ３０２ａ−５のエフェクタは、ストリームデータのデコード等の再生を行う分割機能を実現する。
出力ユニット３０２ａ−６のエフェクタは、番組やコンテンツをユーザに提示するよう外部に出力する分割機能を実現する。

そして、視聴系制御部３０２ａ−１は、個別の機能である視聴機能を実現するために、映像音声ストリームを入力し（フロントエンド３０２ａ−２）、映像音声ストリームから番組やコンテンツを選択し（セレクタ３０２ａ−３）、著作権に従ってデスクランブル等を行い（著作権管理３０２ａ−４）、エンコードされた映像音声ストリームであればデコードを行って映像データを生成し（プレイヤ３０２ａ−５）、生成した映像データを外部へ出力する（出力ユニット３０２ａ−６）、といった一連の処理（分割機能）を順序立てて行う。
なお、視聴機能の場合には、基本的にはそれぞれのエフェクタが持つ状態遷移はフロントエンド３０２ａ−２から順に遷移が行われ、各エフェクタが担当する分割機能の実現の成功によって、次のエフェクタの処理（分割機能）に遷移する。また、視聴系制御部３０２ａ−１は、任意のエフェクタでの分割機能の実現が失敗した場合は、何も処理を行っていない状態にまで戻るような状態遷移となるように制御する。

各エフェクタは、分割機能の種別に対して、分割機能を実現するために使用する下位機能部を選択することのできる付帯状況情報を保持する。例えば、フロントエンド３０２ａ−２は、フロントエンド３０２ａ−２が実現する分割機能の種別に対応して、地上波の放送を視聴する場合は放送入力３０２ａ−７で処理を実行し、インターネットの動画サイトを視聴するような場合はネットワーク入力３０２ａ−８で処理を実行し、蓄積された録画コンテンツを視聴する場合は蓄積媒体入力３０２ａ−９で処理を実行する、といった付帯状況情報を保持する。
セレクタ３０２ａ−３は、セレクタ３０２ａ−３が実現する分割機能の種別に対応して、テレビ番組を試聴する場合は放送番組３０２ａ−１０で処理を実行し、ＤＶＤを視聴するために必要になる機能はＤＶＤコンテンツ３０２ａ−１１で処理を実行する、といった付帯状況情報を保持する。
また、著作権管理３０２ａ−４は、著作権管理３０２ａ−４が実現する分割機能の種別に対応して、ＡＲＩＢ規格の著作権管理機構であればＢ−ＣＡＳ３０２ａ−１２で処理を実行し、Ｍａｒｌｉｎの規格によるＩＰ映像配信であればＭａｒｌｉｎ３０２ａ−１３で処理を実行する、といった付帯状況情報を保持する。
さらに、プレイヤ３０２ａ−５は、プレイヤ３０２ａ−５が実現する分割機能の種別に対応して、再生するコンテンツがデジタル放送やＤＶＤコンテンツではＭＰＥＧ３０２ａ−１４で処理を実行し、再生するコンテンツがＨ．２６４の圧縮符号化を用いたＩＰ映像配信であればＨ．２６４ ３０２ａ−１５で処理を実行する、といった付帯状況情報を保持する。
また、出力ユニット３０２ａ−６は、出力ユニット３０２ａ−６が実現する分割機能の種別に対応して、ストリーム処理装置１００がＴＶセットであればモニタ３０２ａ−１６で処理を実行し、レコーダであれば外部出力端子３０２ａ−１７で処理を実行する、といった付帯状況情報を保持する。

なお、以上のような付帯状況情報についても、ＤＢ部１０３を介してＨＷ部１０６に含まれる記憶装置に保持しておき、各エフェクタは、各エフェクタが生成されたタイミング等の予め定められたタイミングで、ＤＢ部１０３を介して取得するようにすることもできる。

以上のように本実施の形態では、ドメイン部１０２に含まれる系処理部を、系制御部、エフェクタ、下位機能部により構成したので、同一種別の機能を実現する際に、系制御部やエフェクタは共通的に使用することができ、装置内のモジュールを減少させることができる。また、これにより、モジュール格納メモリやモジュールロードメモリ等のメモリ量を減少させることができる。

また、本実施の形態では、シーケンス制御を行う系制御部と、分割機能の実現を制御するエフェクタと、を分離したので、各々の個別の機能に含まれる分割機能が部分的に同一の機能である場合には、個別の機能が異なる場合においても同一のエフェクタを用いることができる。このため、モジュール格納メモリやモジュールロードメモリ等のメモリ量を減少させることができる。

また、下位機能部を付帯状況別に設けたので、異なる付帯状況の下位機能を実現する場合でも同一の構成を取ることができるため、追加の状況に対応する場合においても付帯状況に対応した下位機能部を追加するだけで下位機能部を系処理部に、即ち、ストリーム処理装置に追加することができ、追加した下位機能部に対する追加モジュールを小さくすることができる。従って、各モジュールの開発に要する工数等の開発負荷を低減することができる。

実施の形態３．
次に、本発明における実施の形態３を説明する。図１０は、実施の形態３における系処理部４０２ａのブロック図である。上述した実施の形態２では、系制御部２０２ａ−１は、１つの個別の機能に対応する１つのシーケンス制御を行っていた。これに対して、実施の形態３では、系制御部４０２ａ−１においてシーケンス制御に用いる分割機能及び当該分割機能の順序を特定する機能順序情報を、機能順序情報記憶部４０２ａ−２に記憶し、系制御部４０２ａ−１の外に持つことで、１つの系制御部４０２ａ−１で、複数の個別の機能に対応する複数のシーケンス制御を行うことができるようにされている。

例えば、機能順序情報記憶部４０２ａ−２には、機能順序情報として、図１１に示すような機能順序情報テーブル１０８が、系制御部２０２ａ−１で実行する個別の機能毎に記憶される。図示するように、機能順序情報テーブル１０８は、順序番号欄１０８ａと、エフェクタ欄１０８ｂと、分割機能欄１０８ｃと、を有する。

順序番号欄１０８ａには、分割機能欄１０８ｃで特定される分割機能を実行する順番を特定する情報が格納される。ここで、本実施の形態においては、分割機能を実行する順番を特定する情報として、「１」から連番となる自然数が格納されるが、このような態様に限定されるものではない。
エフェクタ欄１０８ｂには、分割機能欄１０８ｃで特定される順番で実行される分割機能を実行するエフェクタを識別する情報が格納される。ここで、本実施の形態においては、エフェクタを識別する情報として、各エフェクタに与えられたエフェクタ名が格納されるが、このような態様に限定されるものではない。
分割機能欄１０８ｃには、順序番号欄１０８ａで特定される順番で実行される各々の分割機能の内容を特定する情報が格納される。この分割機能の内容に応じて、付帯状況情報より、下位機能部が選択される。すなわち、付帯状況情報は、分割機能の内容と、当該分割機能の内容に対応する下位機能部と、を特定する情報を有する。

なお、このような機能順序情報についても、ＤＢ部１０３を介してＨＷ部１０６に含まれる記憶装置に保持しておき、系制御部４０２ａ−１での処理を開始するタイミング等の予め定められたタイミングで、ＤＢ部１０３を介して取得するようにすることもできる。

そして、本実施の形態における系制御部４０２ａ−１は、シーケンス制御を行う場合、機能順序情報を参照する。系制御部４０２ａ−１は機能順序情報に従って遷移動作をエフェクタに命令するフレームを持つだけであり個別の機能毎の特定のシーケンスに限定されずに動作処理を行う。なお、系制御部４０２ａ−１が参照する機能順序情報は、アプリケーション部１０１より受けた機能実現指示で特定される個別の機能に対応するものである。

以上のように本実施の形態では、系制御部４０２ａ−１を全く変更することなしに機能順序情報の変更のみによって系処理部の機能を実現する順序を変更することができる。

１００：ストリーム処理装置、 １０１：アプリケーション部、 １０１ａ，１０１ｂ，１０１ｃ：アプリケーション、 １０２：ドメイン部、 １０２ａ，１０２ｂ，１０２ｃ，２０２ａ：系処理部、 ２０２ａ−１，４０２ａ−１：系制御部、 ２０２ａ−２〜２０２ａ−５，４０２ａ−３〜４０２ａ−６：エフェクタ、 ２０２ａ−６〜２０２ａ−１５，４０２ａ−７〜４０２ａ−１６：下位機能部、 １０３：ＤＢ部、 １０３ａ，１０３ｂ，１０３ｃ：ＤＢ処理部、 １０４：ドライバ部、 １０４ａ，１０４ｂ，１０４ｃ：ドライバ処理部、 １０５：ＯＳ、 １０６：ＨＷ部、 １０６ａ，１０６ｂ，１０６ｃ：ＨＷ、 １０７：機能処理部、 １０７ａ：機能提供ＩＦ部、 １０７ｂ：機能調停部、 １０７ｃ：機能処理コア部、 １０７ｄ：機能要求ＩＦ部、 ４０２ａ−２：機能順序情報記憶部。

Claims (8)

1. 特定の処理を行う命令の入力を受け付けて、当該処理に対応する機能を実現するために当該機能を特定する情報を含む機能実現指示を出すアプリケーション部と、
   前記アプリケーション部から前記機能実現指示を受けて、前記アプリケーション部から受けた前記機能実現指示で特定される機能を実現するドメイン部と、
   前記ドメイン部での処理に必要な情報を管理する処理を行うデータベース部と、
   前記ドメイン部が実現する機能の少なくとも一部をハードウェアで処理するように当該ハードウェアの制御を行うドライバ部と、を備え、
   前記ドメイン部は、前記機能実現指示で特定される機能を実現する際に、前記データベース部及び前記ドライバ部の少なくとも何れか一方での処理が必要な場合には、前記データベース部及び前記ドライバ部の少なくとも何れか一方に対して、必要な処理に対応する機能を特定する情報を含む前記機能実現指示を出力し、
   前記データベース部は、前記ドメイン部又は前記アプリケーション部より前記機能実現指示を受けると、受けた前記機能実現指示で特定される機能を実現する際に、前記ドライバ部での処理が必要な場合には、前記ドライバ部に対して、必要な処理に対応する機能を特定する情報を含む前記機能実現指示を出力し、
   前記ドライバ部は、前記ドメイン部又は前記データベース部より前記機能実現指示を受けると、受けた前記機能実現指示で特定される機能に対応する処理を行うように前記ハードウェアを制御し、
   前記ドメイン部、前記データベース部及び前記ドライバ部の各々は、予め定められた機能毎に、当該機能に対応する処理を実行する機能処理部を備えることにより構成されており、
   前記機能処理部は、前記機能実現指示を少なくとも１つ受けた場合には、受けた前記機能実現指示で特定される機能に対応する処理を実行し、実行した処理結果を、受けた前記機能実現指示の各々の出力元に返す処理を行うこと
   を特徴とするストリーム処理装置。
2. 前記機能処理部は、
   前記機能実現指示の出力元との間のインタフェースである機能提供ＩＦ部と、
   前記機能実現指示で特定される機能が実行可能か否かを判断する機能調停部と、
   前記機能調停部で実行可能と判断された機能を実現する機能処理コア部と、
   前記機能調停部で実行可能と判断された機能の一部又は全部が他の前記機能処理部で処理する必要がある場合に、当該一部又は全部の機能を特定する情報を含む前記機能実現指示を、他の前記機能処理部に出力する機能要求ＩＦ部と、を有すること
   を特徴とする請求項１に記載のストリーム処理装置。
3. 前記機能処理部は、前記機能実現指示を複数受けた場合には、受けた前記機能実現指示毎に前記機能提供ＩＦ部を設けること
   を特徴とする請求項２に記載のストリーム処理装置。
4. 前記機能処理コア部は、前記機能実現指示を複数受けた場合には、受けた複数の前記機能実現指示で特定される機能に対応する各々の処理を、同時又は順番に実行すること
   を特徴とする請求項２又は３に記載のストリーム処理装置。
5. 前記機能処理コア部は、受けた複数の前記機能実現指示で特定される機能に対応する処理を実行した処理結果を、実行した処理に対応する機能を特定する情報を含む前記機能実現指示に対して設けられた前記機能提供ＩＦ部を介して、前記出力元に返す処理を行うこと
   を特徴とする請求項４に記載のストリーム処理装置。
6. 前記ドメイン部は、
   前記アプリケーション部より受けた前記機能実現指示で特定される機能を分割した分割機能の処理順序を制御する系制御部と、
   前記系制御部より制御された処理順序で前記分割機能の実行を制御するエフェクタと、
   前記エフェクタが制御する前記分割機能に対応する処理を実行する下位機能部と、
   を有する系処理部を備え、
   前記系制御部、前記エフェクタ及び前記下位機能部は、前記機能処理部で構成されていること
   を特徴とする請求項１から５の何れか一項に記載のストリーム処理装置。
7. 前記系処理部は、前記ドメイン部で実現する機能毎に、当該機能に含まれる分割機能、及び、当該分割機能の順序、を特定する機能順序情報を記憶する機能順序情報記憶部を備えており、
   前記系制御部は、前記アプリケーション部より受けた前記機能実現指示で特定される機能に対応する前記機能順序情報を前記機能順序情報記憶部より取得し、取得した前記機能順序情報に従って、前記分割機能の処理順序を制御すること
   を特徴とする請求項６に記載のストリーム処理装置。
8. 特定の処理を行う命令の入力を受け付けて、当該処理に対応する機能を実現するために当該機能を特定する情報を含む機能実現指示を出すアプリケーション部と、
   前記アプリケーション部から前記機能実現指示を受けて、前記アプリケーション部から受けた前記機能実現指示で特定される機能を実現するドメイン部と、
   前記ドメイン部での処理に必要な情報を管理する処理を行うデータベース部と、
   前記ドメイン部が実現する機能の少なくとも一部をハードウェアで処理するように当該ハードウェアの制御を行うドライバ部と、を備え、
   前記ドメイン部は、前記機能実現指示で特定される機能を実現する際に、前記データベース部及び前記ドライバ部の少なくとも何れか一方での処理が必要な場合には、前記データベース部及び前記ドライバ部の少なくとも何れか一方に対して、必要な処理に対応する機能を特定する情報を含む前記機能実現指示を出力し、
   前記データベース部は、前記ドメイン部又は前記アプリケーション部より前記機能実現指示を受けると、受けた前記機能実現指示で特定される機能を実現する際に、前記ドライバ部での処理が必要な場合には、前記ドライバ部に対して、必要な処理に対応する機能を特定する情報を含む前記機能実現指示を出力し、
   前記ドライバ部は、前記ドメイン部又は前記データベース部より前記機能実現指示を受けると、受けた前記機能実現指示で特定される機能に対応する処理を行うように前記ハードウェアを制御し、
   前記ドメイン部、前記データベース部及び前記ドライバ部の各々は、予め定められた機能毎に当該機能に対応する処理を実行する機能処理部を備えることにより構成されているストリーム処理装置が行う処理方法であって、
   前記機能処理部が、前記機能実現指示を少なくとも１つ受ける過程と、
   前記機能処理部が、受けた前記機能実現指示で特定される機能に対応する処理を実行する過程と、
   前記機能処理部が、実行した処理結果を、受けた前記機能実現指示の各々の出力元に返す処理を行う過程と、を有すること
   を特徴とする処理方法。

Images