JP2012253583A - 配信装置 - Google Patents

Abstract

【課題】コンテンツを配信する装置において、クライアント（外部端末）が複数存在していると、ある外部端末の要求を処理しているときに、別の外部端末からの処理要求を実行できない場合がある。
【解決手段】上記課題を解決するために、本発明の一実施の態様は、記録媒体に記録されたコンテンツを再生する記録再生部と、記録再生部で再生されたコンテンツを変換するコンテンツ変換部と、ネットワークを介して他の機器と情報の送受信を行う通信部とを有する配信装置であって、コンテンツ変換部で変換したコンテンツを第１の機器に配信している際に第１の機器とは異なる第２の機器からコンテンツ変換部で変換したコンテンツの配信要求を受けると、第１の機器へコンテンツの配信に関するメッセージを送信することを特徴とする。
【選択図】 図７

Description

技術分野は、コンテンツの配信に関する。

特許文献１には、「宅内ネットワークにおいて、配信装置および／または受信装置の個別の利用状況に応じて、円滑かつ効率的なシステム運用を行えるようにする」（特許文献１［０００８］参照）ことを課題とし、その解決手段として「１以上の機能（チューナ機能、記録再生機能など）とその機能のリソースを用い、１以上の受信装置からの要求により、該当受信装置へ前記リソースのコンテンツを配信する。この配信装置は、管理情報（機能利用管理テーブルの内容）を格納する情報格納手段（２０）と、コンテンツを配信する手段（ＣＰＵ２１が実行するファームウエアとＬＡＮコントローラ／モデム１１）を持つ。この管理情報により、前記１以上のリソースを利用するための、前記１以上の受信装置（ＮＣ１、ＮＣ２、…ＮＣｍ）からの要求に、応じるか否か（リソースの利用可否）を決めることができる。また、前記情報格納手段（２０）に格納された管理情報（予め管理情報を格納した機能利用管理テーブル）に基づき前記要求に応じると決定された場合（図５の機能搭載が○であり、許可端末に該当し、かつ利用状況ＯＫ）に、前記要求を出した前記１以上の受信装置（例えばＮＣ１だけ、あるいはＮＣ１〜ＮＣｍのうちの２以上もしくは全て）へ、前記管理情報が定めるリソース（１つまたはそれ以上）のコンテンツを、前記コンテンツ配信手段により、配信する。」（特許文献１［０００９］参照）ことが記載されている。

また、特許文献２には、「複数の受信装置で一つのチューナを共用する場合における良好な操作環境を提供することの出来る受信システムを提供すること」特許文献２［００１３を目的とする技術的思想が開示されている。また、「Ｓ３０３で子機Ａ に対して、同時視聴の要求だけでなく、リソース開放要求をすることができる。Ｓ３０８でリソース開放要求を選択した場合、Ｓ３０９に進み、子機Ａ に対して前記実施例で示したように図１０−（Ｄ）のような確認通知画面を、ビープ音など子機Ａ のユーザが気づき易い警告音と共に出力する」（特許文献２［００８３］参照）ことが記載されている。

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

コンテンツを配信する装置において、クライアント（外部端末）が複数存在していると、ある外部端末の要求を処理しているときに、別の外部端末からの処理要求を実行できない場合がある。

特許文献１では、クライアントから要求された処理のリソースが使用不可能な場合については考慮されていない。

また、特許文献２においては、チューナ以外のリソースに関する記載は無い。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、記録媒体に記録されたコンテンツを再生する記録再生部と、記録再生部で再生されたコンテンツを変換するコンテンツ変換部と、ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、コンテンツ変換部で変換したコンテンツを第１の機器に配信している際に第１の機器とは異なる第２の機器からコンテンツ変換部で変換したコンテンツの配信要求を受けると、第１の機器へコンテンツの配信に関するメッセージを送信することを特徴とする。

上記手段によれば、より効率的にコンテンツを配信することが可能となる。

配信システムの構成図の例である。 送受信システムの構成図の例である。 送信装置の構成図の例である。 配信装置、外部端末の構成図の例である。 代替案表示のメニューの例である。 配信処理時の配信装置と外部端末の機器間シーケンス図の例である。 リソース競合時の配信装置と外部端末の機器間シーケンス図の例である。 リソース解放要求メッセージの例である。 処理待ちメッセージの例である。 リソース管理テーブルの例である。 制御部の処理を説明するフローチャートの例である。 配信停止確認メッセージの例である。 簡易的な配信停止確認メッセージの例である。 リソース解放要求メッセージの例である。 コンテンツリストの表示例である。 リソース予約登録を行う際のメッセージの例である。 リソース解放時の通知メッセージの例である。 リソース予約テーブルの例である。 制御部の処理を説明するフローチャートの例である。

以下、本発明に好適な実施形態の例（実施例）を説明する。但し、本発明は本実施例に限定されない。本実施例は、主には配信装置について説明してあり、配信装置での実施に好適であるが、配信装置以外への適用を妨げるものではない。また、実施例の構成すべてが採用される必要はなく取捨選択可能である。
＜配信システム＞
図１は本実施例の配信システム構成例である。１はコンテンツを他の機器に配信する配信装置、２および３は配信されるコンテンツを受信し表示などの処理を行う外部端末、４は前記配信装置および前記外部端末と信号を送受信する通信中継装置、であり、図の例では配信装置が無線通信を行い、外部端末に対して通信中継装置を経由しまたは直接、コンテンツを配信している例を図示している。

コンテンツとは、ここでは映像や音声を含むデジタルコンテンツを示しており、例としては、放送番組を記録した放送コンテンツ、ユーザが作成または撮影したユーザ作成コンテンツ、インターネットなどのネットワークを経由して入手したネットコンテンツ、などがある。

配信装置１の機器の例としては、ＴＶ、ＳＴＢ（Ｓｅｔ Ｔｏｐ Ｂｏｘ）、レコーダ、ＰＣ、ホームサーバ、ネットワークサーバ、などが挙げられる。ここでは表示部を有する配信装置の例を図示しているが、表示部を有さず、配信装置１が有する出力端子から映像や音声を出力する機器の場合もある。

外部端末２および３の機器の例としては、携帯電話、スマートフォン、タブレット端末、モバイル型のＰＣなどが挙げられる。

またそれぞれ、配信装置と外部端末の機器の例に挙げたものは、配信装置と外部端末の両方の機能を有する場合や、配信装置の例に挙げた機器が外部端末となる場合、またはその逆もある。例えばＴＶが配信装置かつ外部端末になる場合や、スマートフォンが配信装置になる場合、などがある。また配信装置や外部端末を総称して端末とも呼ぶ。

通信中継装置４の機器の例としては、家庭内でのＬＡＮルータ、家庭外での携帯電話の中継局、その他家庭内外における無線の中継機器などがある。ここでは無線で通信を行う例を記載しているが、一部もしくは全て、有線での接続となる場合もある。また配信装置と外部端末の通信において、通信中継装置を経由せず直接通信を行う場合もある。

各装置の数に付いては図示の例に拠らず、それぞれ複数存在している場合がある。例えば配信装置１台に対して外部端末は３台以上存在し、それぞれの外部端末にコンテンツを配信する場合がある。

また図１には示していないが、配信装置１は外部のアンテナなどから信号を受信して処理を行う受信部および前記受信信号を記録する記録再生部を有する場合がある。以下では配信装置が受信部を有する場合の例について説明する。
＜送受信システム＞
図２は送受信システムの構成例を示すブロック図である。放送で情報を送受信して記録する場合を例示している。ただし放送に限定されず、通信によるＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）等であってもよい。

５は放送局などの情報提供局に設置される送信装置、６は中継局や放送用衛星などに設置される放送中継装置、７はインターネットなど一般家庭と放送局を繋ぐ公衆回線網、ユーザの宅内などに設置される１は受信部を有する配信装置を表す。

送信装置５は、放送中継装置６を介して変調された信号電波を伝送する。図２のような衛星による伝送以外にも例えばケーブルによる伝送、電話線による伝送、地上波放送による伝送、公衆回線網７を介したインターネットなどのネットワーク経由による伝送などを用いることもできる。

配信装置１で受信されたこの信号電波は、後に述べるように、復調されて情報信号となった後、必要に応じ記録媒体に記録される。または公衆回線網７を介して伝送する場合には、公衆回線網７に適したプロトコル（例えばＴＣＰ／ＩＰ）に準じたデータ形式（例えばＩＰパケット）等の形式に変換され、前記データを受信した配信装置１は、復号して情報信号とし、必要に応じ記録するに適した信号となって記録媒体に記録される。

またユーザは、配信装置１にディスプレイが内蔵されている場合はこのディスプレイで、内蔵されていない場合には配信装置１と図示しないディスプレイとを接続して情報信号が示す映像音声を視聴することができる。
＜送信装置＞
図３は、図２の送受信システムのうち、送信装置５の構成例を示すブロック図である。
１１はソース発生部、１２はＭＰＥＧ２、或いはＨ．２６４方式等で圧縮を行い、番組情報などを付加するエンコード部、１３はスクランブル部、１４は変調部、１５は送信アンテナ、１６は管理情報付与部である。

カメラ、記録再生装置などから成るソース発生部１１で発生した映像音声などの情報は、より少ない占有帯域で伝送できるよう、エンコード部１２でデータ量の圧縮が施される。必要に応じてスクランブル部１３で、特定の視聴者には視聴可能となるように伝送暗号化される。変調部１４でＯＦＤＭ、ＴＣ８ＰＳＫ、ＱＰＳＫ、多値ＱＡＭなど伝送するに適した信号となるよう変調された後、送信アンテナ１５から、中継装置６に向けて電波として送信される。このとき、管理情報付与部１６では、ソース発生部１１で作成されたコンテンツの属性などの番組情報が付与される。

なお、一つの電波には複数の情報が、時分割、スペクトル拡散などの方法で多重されることが多い。簡単のため図３には記していないが、この場合、ソース発生部１１とエンコード部１２の系統が複数個あり、エンコード部１２とスクランブル部１３との間、または／およびエンコード部１２と暗号化部１７との間に、複数の情報を多重するマルチプレクス部（多重化部）が置かれる。

また、公衆回線網７を経由して送信する信号についても同様に、エンコード部１２で作成された信号が必要に応じて暗号化部１７で、特定の視聴者には視聴可能となるように暗号化される。通信路符号化部１８において公衆回線網７で伝送するに適した信号となるよう符号化された後、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）部１９から、公衆回線網７に向けて送信される。
＜配信装置＞
図４は、図１の配信システムのうち、配信装置１の構成例を示す図である。
２１は装置全体を制御する制御部（たとえばＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。２２は制御部２１と配信装置内各部を接続し、制御指示およびデータを送受信するための汎用バスである。２３は無線（衛星、地上）、ケーブルなどの放送伝送網を介して送信装置５から送信された放送信号を受信し、特定の周波数を選局し復調、誤り訂正処理、などを行い、ＭＰＥＧ２−Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ（以下、ＴＳ）などの多重化パケットを出力する放送受信部である。２４はスクランブル部１３によるスクランブルを復号するデスクランブラである。２５はＬＡＮやインターネットなどのネットワークを介したデジタルコンテンツ等の情報の送信、受信を行う通信部である。２６は配信装置４に内蔵または接続されている記録媒体（ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やフラッシュメモリ等）、またはリムーバブルな記録媒体（ＨＤＤ、ディスク型記録媒体、フラッシュメモリ等）である。２７は記録媒体２６への信号の記録や記録媒体２６からの信号の再生を行う記録再生部である。２８は入力された信号に対して、必要に応じてコンテンツ変換（例えば後述するトランスコード、映像音声信号の選択抽出、映像補正、シーンカット、クリッピング、その他映像や音声の加工、など）を行い、信号を出力するコンテンツ変換部である。２９はＭＰＥＧ２−ＴＳなどの形式に多重化されている信号を、映像ＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）、音声ＥＳ、番組情報などの信号に分離する多重分離部である。ＥＳとは、圧縮・符号化された画像・音声データのそれぞれのことである。

３０は映像ＥＳを映像信号に復号するなど、入力映像信号に応じて適した形式で映像を処理し出力する映像復号部である。３１は音声ＥＳを音声信号に復号するなど、入力音声信号に応じて適した形式で音声を処理し出力する音声復号部である。３２は、映像復号部３０で復号された映像信号を所定のフォーマットに変換する処理や、制御部２１が作成したＯＳＤ（Ｏｎ Ｓｃｒｅｅｎ Ｄｉｓｐｌａｙ）などの表示を映像信号に重畳する処理などを行い、処理後の映像信号を表示部４７または／および外部入出力処理部４６に出力する映像処理部である。３３は入力された音声信号に対して音響効果や重畳などの加工処理を行い、処理後の音声信号をスピーカ４８または／および外部入出力処理部４６に出力する音声処理部である。３４はユーザ操作入力部４５からの操作入力（例えばＩＲ（Ｉｎｆｒａｒｅｄ Ｒａｄｉａｔｉｏｎ）信号を発信するリモートコントローラーからのキーコード、タッチパネルの接触情報（座標））、または撮像素子（カメラ）や音声入力装置（マイク）などのセンサーからの入力信号、を受信し、前記操作入力を解釈し操作情報とし、制御部２１などに前記解釈した操作情報を送信する操作入力部である。３５は内部にカウンタを有し、また現在の時刻の保持を行うタイマーである。４６は外部入出力端子４１を経由して外部機器と通信を行い、映像処理部３２または／および音声処理部３３の間で映像信号および音声信号を定められたフォーマット（例えばＨＤＭＩ（登録商標））で入出力し、映像や音声の変換や暗復号処理など必要な処理を行う外部入出力処理部である。４７は映像復号部３０が復号し映像処理部３２により処理された映像を表示する表示部である。４８は音声復号部３１が復号し音声処理部３３により処理された音を出力するスピーカである。４９は前記多重分離部２９で再構成されたＴＳに対し暗号化等必要な処理を行い外部にＴＳを出力、または外部から受信したＴＳを復号化して多重分離部２９に対して入力するシリアルインタフェースやＩＰインタフェースなどの高速デジタルＩ／Ｆである。

ここで、ＨＤＭＩ及びＨｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ ＩｎｔｅｒｆａｃｅはＨＤＭＩ Ｌｉｃｅｎｓｉｎｇ，ＬＬＣの登録商標であり、映像・音声信号のデジタルインタフェースの一つである。

また、放送受信部２３、デスクランブラ２４を合わせて受信部とも呼ぶ。

また、トランスコードとは、例えばコンテンツのビットレート、解像度、フレームレート、映像や音声の符号化方式、Ｉ／Ｐ（インタレース／プログレッシブ）等の変換（例えばコンテンツに含まれる映像信号のフレームの間引きや補間）を示す。またデコードを行ってからエンコードを行う変換処理もトランスコードの一例である。トランスコードを行う処理部のことをトランスコーダとも呼ぶ。

図中では、各ブロックを接続する信号の流れについて、概略として単一の信号経路のように記載しているが、複数の信号線や時分割多重等によって同時に複数の信号を送受信する場合もある。例えば、多重分離部２９と映像復号部３０の間は、同時に複数の映像信号が送信可能であり、映像復号部で複数の映像ＥＳを復号化し、映像の２画面表示や録画と視聴の同時復号などの処理も可能である。

また図中の「信号の流れ」に記載した以外でも、汎用バス２２および制御部２１、または図に記載していない一時記憶領域（メモリ）を介したデータの送受信が可能である。例えば、制御部２１で作成したＯＳＤの情報を汎用バス２２を介して映像処理部３２に送信することも可能である。また、映像処理部３２で作成した映像および音声処理部３３で作成した音声を、ネットワークに出力するために通信部２５に送信する場合や、通信部２５が受信した映像／音声データを直接映像処理部３２や音声処理部３３に出力する場合も、汎用バス２２や図に記載していない一時記憶領域（メモリ）等を介したデータの送受信が可能である。

図４の配信装置には記録媒体２６が一つのみ搭載される例が開示されているが、複数の種類の記録媒体を搭載したり、記録媒体が着脱可能（リムーバブル）である場合はリムーバブル記録媒体を接続するインタフェースのみを搭載したりすることも可能である。また、内蔵の記録媒体と、リムーバブル記録媒体を接続可能なインタフェースとを備えるように構成してもよい。それら記録媒体が複数ある場合、記録再生部２７は複数の記録媒体と同時に信号の送受信を行う場合がある。また、記録媒体２６は、記録媒体と配信装置内部の接続バスの帯域や、記録媒体における処理速度の上限などにより、同時処理可能な入出力信号について制限される場合がある。

また、各部は図中では独立した構成で記載されているが、別々のハードウェアにて構成されている必要は無く、同一のハードウェアにて構成することも可能である。例えば、映像復号部３０と音声復号部３１は同一のハードウェア上で実装されることにより、映像と音声のタイミングの制御が容易になる。

また、制御部２１は、ＣＰＵなどの単一のハードウェアで実施されるだけでなく、独立した制御部（以下周辺制御部）が連携をして同様の機能を実現することも可能である。例えば、記録再生部２７の制御を行う周辺制御部として記録再生制御部を配置し、制御部２１と記録再生制御部とが連携することで、制御部２１の処理負荷を低減させることも可能である。

汎用バス２２についても、特に単一のバスである必要は無く、複数のバスを連結して実現する構成でも良い。その場合はそれぞれのバスの負荷が低減し、特定のバスの通信が別のバスの通信に影響を与えないが、バス間の通信が追加で必要になる。

リソースとは、特定の処理に用いる資源を表し、配信装置１が有するリソースとしては、放送受信部２３が有するチューナ、コンテンツ変換部２８、記録媒体２６などに保管されているコンテンツを再生、配信するためのライセンス（例えば鍵情報や契約情報）、前記記録媒体が同時に処理可能なコンテンツの数、などがある。コンテンツ変換部２８については、内部の構成により例えばトランスコーダ、デコーダ、エンコーダ、などがさらに詳細なリソースとなる。

制御部２１は、データの保持や演算の高速化のために、図示していないメモリを管理している。後述するテーブルのデータについては、主に制御部２１が管理し前記メモリに保持している。

なお、配信装置は必ずしも図４に示す構成要件全てを備える必要は無く、配信装置が行う処理に応じて必要な構成要件のみを備えるようにしてもよい。
＜ユーザインターフェース＞
ユーザに情報を提示して、その情報に対するユーザの応答を受信するユーザインターフェースの例について説明する。ユーザに情報を提示する方法としては、例えば制御部２１が文字や図形、映像を含む情報（以下、メッセージ）を作成し、映像処理部３２に対して映像として出力するように制御する方法がある。前記メッセージには音声（例えば効果音や説明音声）を含む場合があり、その場合には音声処理部３３に対して音声を出力するように制御する。

そして前記メッセージには、ユーザの応答を確認するオブジェクト（以下、ユーザ応答確認オブジェクト）を含む場合がある。ユーザ応答確認オブジェクトの例としては、例えば図８の８０６のような映像上のボタン、またはスライダ、テキストボックス、選択リスト、などがある。ユーザ応答確認オブジェクトが表示されている状態で、ユーザは操作機器（たとえばリモコン、タッチパネル、など）を操作し、前記操作機器はユーザ操作入力部４５に対して操作情報（例えば、リモコンのカーソル押下、タッチパネルの接触座標）を送信し、操作入力部３４が操作情報を取得する。操作情報を操作入力部３４が制御部２１に通知することにより、制御部２１はどのような出力に対して、ユーザがどのような操作情報を返したか（応答動作）を知ることが可能になる。

図８の場合を例に挙げると、画面に「ＯＫ」、「ＮＧ」というボタンが図のように配置され、現在は「ＯＫ」がハイライト表示されている画面を制御部２１が出力しているとする。この状態で、ユーザがリモコンの「決定」ボタンを押下した場合、ユーザの応答はＯＫであると確認できる。また、ユーザがリモコンのカーソルボタンの右を押下してから決定ボタンを押下した場合、ユーザの応答はＮＧであると判定できる。このようにして装置の出力に対するユーザの応答動作を確認する。

またユーザの操作入力およびユーザへの情報通知の方法としては、ネットワークを経由した方法もある。ユーザの操作機器がネットワーク等に接続されている場合、前記操作機器がネットワークを介して通信部２５に対して予め定められたコマンドを送信することにより、ユーザの操作内容を配信装置１に伝えることが可能になる。また、操作機器に対して、通信部２５からネットワークを介して予め定められたコマンドを送信することにより、ユーザに対して情報を通知することも可能となる。
＜外部端末＞
図４は、図１のシステムのうち、外部端末２および３の構成例も示す。ただし、例えば外部端末においては携行を容易化するために、機能を削減して端末の重量を軽量化する場合などがある。例えば放送コンテンツを受信する機能が不要であれば、放送受信部２３やデスクランブラ２４は不要となる。また、コンテンツ変換部２８を有さない場合などがある。そのような場合に、必要な機能（例えば放送受信機能、コンテンツ変換機能）を配信装置が代替することにより、外部端末使用時のユーザの利便性を高めることが可能になる。
＜コンテンツ配信時の機器間シーケンス＞
ここでは配信装置から外部端末に対してコンテンツを配信する場合の機器間シーケンスについて説明する。

図６は、配信処理を行う際の、配信装置１と外部端末２の機器間シーケンス図である。ここではユーザが外部端末２を操作し、配信装置１から外部端末２に対してコンテンツを配信させる際の動作を例に説明する。

まず初めに、外部端末２は通信部を介してネットワーク（例えば家庭内ＬＡＮ）上の配信装置を検索する（Ｓ６０１）。具体的には、例えばＵＰｎＰで用いられるＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒ Ｐｒｏｔｏｃｏｌ）などのプロトコルを用いて、メッセージをネットワーク上にマルチキャストするなどの方法がある。上記の検索に対して、配信装置１は応答のメッセージを返す（Ｓ６０２）。前記メッセージには配信装置１の位置情報（例えばＩＰアドレス）が含まれている。このようにして外部端末２はネットワーク上に存在する配信装置１の位置情報を取得する。

次に、外部端末２は配信装置１に対して前記位置情報を基に通信を行い、機器の情報を要求し（Ｓ６０３）、配信装置１は機器情報を返す（Ｓ６０３）。これにより外部端末２は配信装置１がどのような機器（例えば配信処理が可能な機器か否か）かを把握する。

次に外部端末２は、配信装置１に対して、配信装置１のコンテンツのリスト（コンテンツリスト）を要求（以下、コンテンツリスト要求）し（Ｓ６０５）、配信装置１は前記コンテンツリストを返す（Ｓ６０６）。コンテンツリストに含まれる情報としては、コンテンツごとのタイトル、ＩＤ、フォルダ位置、著作者、ＵＲＩ、サイズ、時間、コピー制御情報、ビットレート、解像度、色ビット、有効期限、記録品質、アーティスト、アクター、ジャンル、日時情報、チャンネル情報（ＣＨ情報）、などがある。

ここで、例えば外部端末２は、前記コンテンツリストの情報を、ユーザインターフェースを介してユーザに提示する。一例としては、表示部４７などへの提示である。具体的な処理手順は、制御部２１が通信部２５から前記コンテンツリストを取得してコンテンツリストを含むＯＳＤ情報を作成し、映像処理部３２に送信する。前記ＯＳＤ情報を取得した映像処理部３２が前記ＯＳＤ情報を表示部４７に出力する。

前記コンテンツリストを含むＯＳＤ情報の提示を受けたユーザは、例えばタッチパネルなどの操作により、前記ユーザ操作入力端子４５を経由し操作入力部３４に対してコンテンツ選択の操作を入力する。前記操作入力部３４は入力された操作情報を制御部２１に送信する。これにより、前記操作情報を受信した制御部２１は、ユーザが選択したコンテンツを把握することが可能になる。

ユーザが選択したコンテンツについて、外部端末２は前記コンテンツのＩＤまたはＵＲＩなどを指定し、配信装置１に対してコンテンツの配信を要求する（Ｓ６０７）。この後の説明では、ＵＲＩ指定で配信が要求されるものとして説明する。前記要求を受信した配信装置１は、前記コンテンツを外部端末２に対して配信する（Ｓ６０８）。具体的な配信処理の内容については後述する。このようにして配信装置１から外部端末２へのコンテンツの配信を行う。

上記ステップＳ６０１の配信機器検索、Ｓ６０３の機器情報要求、およびＳ６０５のコンテンツリスト要求については、すでに外部端末２が配信装置１の情報を把握している場合には実施する必要は無い。その場合には上記Ｓ６０１、Ｓ６０３、Ｓ６０５の処理が不要となり、処理が高速化される。また、ネットワーク上の情報提供サービス（例えばディレクトリサービス）を使用して、配信装置１に上記情報の問い合わせをせずに、同様の情報を取得することも可能である。その場合には複数の配信装置（配信装置１以外の配信装置を含む）の情報について、まとめてディレクトリサービスから情報を取得することが可能になる。

またここでは配信装置と外部端末が１対１の構成で説明したが、それぞれが複数存在している場合もある。その場合には上記の処理を、複数台の端末間で実施する。
＜コンテンツ配信時の、配信装置の処理＞
コンテンツ配信時の配信装置１の処理内容について以下に説明する。まず配信装置１は、記録媒体２６に記録されているコンテンツリストを作成する。具体的には、制御部２１が、記録再生部２７から記録媒体２６などに記録するコンテンツの情報を順次取得し、それぞれのコンテンツの情報からコンテンツリストを作成し、それぞれのコンテンツにユニークなＵＲＩを割り当てる。その後、通信部２５からネットワーク経由で上記コンテンツリスト要求を受信した場合は、制御部２１が前記方法で作成したコンテンツリストを返信する。

その後、配信装置１が外部端末からＵＲＩ指定でコンテンツの配信要求を受信した場合、前記要求を受信した通信部２５は、前記ＵＲＩが示すコンテンツの配信処理を、制御部２１に対して要求する。前記要求を受信した制御部２１は、記録再生部２７に対して記録媒体２６から前記コンテンツを読み出し、コンテンツ変換部２８に出力するように指示する。

前記指示を受信した記録再生部２７は、記録媒体２６から前記ＵＲＩのコンテンツを読み出し、暗号の復号など必要な処理を行った後に、コンテンツをコンテンツ変換部２８に出力する。前記コンテンツを受信したコンテンツ変換部２８はトランスコードなど配信に必要なコンテンツ変換処理を行った後に、コンテンツを通信部２５に出力する。

前記コンテンツが入力された通信部２５は、前記コンテンツに対して、ネットワークに出力するために必要な処理（例えば通信路暗号化など）を行った後に、前記外部端末からの配信要求に対する応答としてコンテンツを出力する。このようにして配信処理を行う。

配信時にコンテンツ変換を行う理由としては、配信するコンテンツのビットレートを下げることにより、通信路の負荷を低下させる、受信する端末での処理負荷を低減させる、などのメリットがあるためである。また、受信する端末の画面サイズ（縦横の画素数、など）や、対応ビットレート、符号化方式に合わせて配信側で変換を行うことにより、受信する端末で負荷の高い画面サイズの変換を行うことなく最適な映像表示を行うことも可能になる。

ここではコンテンツリストを記録媒体２６に記録しているコンテンツから作成する例を挙げて説明したが、コンテンツリストには、記録媒体２６に含まれるコンテンツ以外も記載することが可能である。例えば、ネットワークを経由して前記配信装置１が受信可能なコンテンツ（以下、外部コンテンツ）もコンテンツリストに記載しておき、前記外部コンテンツの配信要求を受信した場合に、ネットワークを経由して前記外部コンテンツを取得して配信を行うことも可能である。

記録再生部２７における暗号の復号においては、コンテンツによってはライセンスが必要になる場合がある。ライセンスの取得方法については記録媒体２６の耐タンパ領域に記録されているライセンス情報を取得、またはネットワークから必要なときに取得、などを行った上で再生や配信の処理を行う。特に配信については再生と別のライセンスを用いる場合もある。

このように、配信装置１での配信処理においては、コンテンツ変換部２８における処理や、コンテンツのライセンスによる使用の制限がある。そのため、コンテンツ変換部２８で同時に処理できるコンテンツの数や、ライセンスの条件状況等により、複数の外部端末への配信が実行できなくなる場合がある。

また、配信処理に使用しているリソース（例えばトランスコーダ、ライセンス、チューナ）については、後述するリソース管理テーブルに、必要な情報（例えば使用している端末、ユーザ）を含めてリソースの使用状況を記録しておき、登録に必要な情報については、適宜外部端末から取得する。
＜放送受信＞
放送受信を行う場合の制御手順と信号の流れについて説明する。まず特定チャンネル（ＣＨ）の放送受信を要求するユーザの指示（例えばリモコンのＣＨボタン押下）を、操作入力部３４から受信した制御部２１は、放送受信部２３に対しては指定ＣＨの受信制御（指定周波数帯への選局、放送信号復調処理、誤り訂正処理等の処理）を指示し、ＴＳをデスクランブラ２４に出力させる。

同様に制御部２１は、デスクランブラ２４に対して前記ＴＳをデスクランブルし多重分離部２９に出力するように制御し、多重分離部２９に対しては、入力されたＴＳの多重分離、および多重分離した映像ＥＳの映像復号部３０への出力と、音声ＥＳの音声復号部３１への出力、を指示する。

また、制御部２１は、映像復号部３０に対して復号した映像信号を映像処理部３２に出力するように制御し、音声復号部３１に対して復号した音声信号を音声処理部３３に出力するように制御を行う。その後、制御部２１は、映像処理部３２および音声処理部３３に、入力信号に対して必要な処理と出力を行うように制御を行う。このようにして、ユーザが指定したＣＨの放送を受信し、映像および音声を出力する制御を行う。
＜放送番組の配信＞
記録媒体２６に記録済みのコンテンツや外部コンテンツ以外に、例えば放送されているコンテンツを配信することも可能である。その場合の処理について下記に示す。

まず、コンテンツリストの配信時に、放送信号の種類（地デジ、ＢＳ、ＣＳ）とＣＨ番号（以下放送ＣＨ）を含むＵＲＩを作成し、コンテンツリストに記載する（例えば地デジの８ＣＨ、など）。

放送ＣＨのＵＲＩを指定して外部端末が配信要求を行った場合に、配信要求を受信した通信部２５は、放送ＣＨの配信を制御部２１に対して要求する。要求を受信した制御部２１は、前述した放送受信時の処理と同様に、各部が放送信号を受信するように制御し、さらに多重分離部２９に対しては、入力されたＴＳに対して必要な処理（例えば番組情報の書き換えなど）と、ＴＳをコンテンツ変換部２８へ出力するように指示する、
さらに制御部２１は、コンテンツ変換部２８および通信部２５に対して、記録媒体からの配信処理と同様にコンテンツを配信するように指示を行う。このようにして放送番組の配信を行う。
＜放送信号の記録＞
次に放送信号の記録時の制御と信号の流れについて説明する。特定のＣＨの記録を行う場合に、制御部２１は、前述した放送受信の処理と同様に、放送受信部２３に対して特定ＣＨの受信制御を指示し、デスクランブラ２４に対して、放送受信部２３から受信したＴＳのデスクランブル、多重分離部２９に対してデスクランブラ２４からの入力をコンテンツ変換部２８に出力するように制御する。

また制御部２１は、コンテンツ変換部２８に対して、入力された信号（コンテンツ）について必要に応じて前記コンテンツ変換（トランスコード等）を行い記録再生部２７に出力するように指示を行う。

次に制御部２１は、記録再生部２７に対して、入力される信号（コンテンツ）について、暗号化などの必要な処理を行い、また記録再生時に必要な付加情報（記録ＣＨの番組情報、ビットレート等のコンテンツ情報）の作成、また管理データ（記録コンテンツのＩＤ、記録媒体２６上の記録位置、記録形式、暗号化情報など）の記録を行った後に、コンテンツ、付加情報、管理データを記録媒体２６へ書き込む処理を行うように指示を行う。このようにして放送信号の記録を行う。放送信号やインターネットで配信されるコンテンツの記録を行うことを録画とも呼ぶ。

放送信号の記録方式の種類としては、トランスコード等のコンテンツ変換を行わない記録方式（以下ＴＳ録画）、やトランスコード等のコンテンツ変換を行う記録方式（以下コンテンツ変換録画）、がある。
＜予約録画＞
ユーザが予約録画の登録を行う方法、そして登録された予約録画が実行される際の制御について説明する。
まずユーザが予約録画を登録する例について説明する。ユーザは例えば番組表や予約メニュー表示などを確認しながら、予約したい番組を決定する操作を行う。ユーザの操作情報が操作入力部３４を介して入力されることにより、予約録画の対象となる番組がユーザにより指定される。

制御部２１は、番組の放送スケジュール（例えば、放送ＣＨ、開始時刻、放送期間等の情報）を番組情報等から取得する。その後、番組開始時刻の一定時間前（予約動作開始時刻：録画の準備が可能な時間だけ前）に、制御部２１に対して予約録画実行の通知が行われるようにタイマー３４にアラームを設定し、管理のために予約登録データとして記録する。このようにして予約の登録を行う。

予約録画の実行時の制御を以下に説明する。予約動作開始時刻が到来し、タイマー３４から前記アラームを受信した制御部２１は、予約登録データを読み出して必要な動作を開始する。記録準備動作として、記録媒体２６の準備（例えばＨＤＤのスピンアップ、記録媒体２６の取付け、空き容量確保などの準備指示）、その他ユーザに対して予約録画が開始される旨の通知、などを実施した後に、放送信号の記録に記載の方法で録画を開始する。このようにして予約録画を実行する。

ユーザによる予約登録の方法としては、ユーザによる番組の指定以外にも、放送スケジュールを直接操作入力部から入力する、または別の機器からネットワークを経由して、配信装置１に対して放送スケジュールを送信する場合もある。その場合も、通信部２５が放送スケジュールを制御部２１に通知し、制御部２１が放送スケジュールに応じて前述した予約登録の動作を行うことにより、予約を登録することが可能となる。

予約登録を行ったユーザを何らかの方法（例えば端末操作時のユーザ認証、予約録画登録時にユーザインターフェースの選択肢によるユーザ選択、など）で判定し、予約登録データにユーザ情報を登録しておくと、以後のリソース使用ユーザの提示を行う場合や、優先度の判定を行う場合などにユーザの情報の提示や、ユーザを判定して処理を行うことが可能になる。

また、録画予約については、ユーザにより登録されるものだけではなく、例えばキーワードに一致する番組を自動的に録画するなど、装置により自動的に録画されるものもある。その場合の予約登録の処理は、録画する番組をユーザが指定した場合の処理と同様である。また、その場合の登録ユーザ名については、「システム」または「自動録画」として扱い後述の通り判定することにより、ユーザが登録した予約と区別を行う判定が可能になる。

予約登録の際には、前記記録方式（ＴＳ録画またはコンテンツ変換録画）をユーザが指定し、ユーザが望む記録方式を予約登録データに設定する。自動録画の際にも予め、前記記録方式を選択しておく、または記録媒体の残量などを考慮し、配信装置１が自動的に記録方式を選択しておくといった動作が行われる。
＜リソース競合時の動作＞
次に配信に用いるリソースが競合している場合の配信装置と外部端末の動作について、機器間シーケンスを図７に示す。リソースの競合とは、同一のリソースに対して複数の使用要求があり、リソースが不足している状態のことを示す。図７の例では、配信装置１から外部端末２に対する配信（以後配信Ａ）が行われているときに、外部端末３から配信装置１に対して、前記配信Ａが使用しているリソースを使用する配信要求を行った場合の例について示している。以下図７の機器間シーケンスを用いて説明を行う。

まず、外部端末２が配信装置１からコンテンツの配信を受ける動作については、前記のコンテンツの配信時機器間シーケンスの場合と同様である（Ｓ７０１）。次に配信Ａ実行中に、配信装置１が外部端末３からも同様に配信（以下、配信Ｂ）の要求を受信する（Ｓ７０３）。以下、このように配信装置１のリソースを使用する処理要求をリソース使用処理要求と呼ぶ。この場合に、配信装置１は外部端末３に対して配信が可能か、リソース使用処理要求の内容と処理に必要なリソースを判断し、その後リソースについて、後述のリソース管理テーブルにより使用状況などを確認する。

確認の結果、現在の例では配信Ａがリソース（例えばトランスコーダ）を使用しているため、リソースが一つしか無い場合などには、配信装置１は外部端末３に対して、現在配信ができない旨の通知（処理待ち通知）をする（Ｓ７０４）。この際に送信する情報については後述する。

情報を送信後、配信装置１は必要に応じて配信Ｂに必要なリソースを獲得するために、外部端末２に対してリソース解放要求を行う（Ｓ７０５）。この要求に際しては、後述するメッセージ表示に必要な情報なども送信する。要求を受信した外部端末２は、ユーザに対して、図８に示すようなメッセージ（以下、リソース解放要求メッセージ）８０５を表示部４７などに表示する。メッセージの詳しい内容については後述する。

メッセージには、ユーザ応答確認オブジェクト８０６が含まれており、ユーザはオブジェクトの提示に対して、応答動作を行う。これにより上記メッセージに対するユーザの応答（ＯＫ、ＮＧ、それ以外の動作）が確認可能となる。ユーザ応答確認オブジェクトの確認結果を受信した外部端末は、確認結果を配信装置１に送信する（Ｓ７０６）。

確認結果がＯＫであった場合（図のａｌｔの応答ＯＫ）、Ｓ７０７からＳ７０９までのステップが実行される。まず配信装置１は必要に応じてリソースの解放に必要な処理（例えば配信Ａの中止処理）を行い（Ｓ７０７）、リソースの確保ができた後に、外部端末３に対して、先ほどの配信要求のＯＫ応答を返す（Ｓ７０８）。その後必要に応じて外部端末３から配信要求を受けるなど通信を行った後、外部端末３に対して、要求コンテンツの配信処理を行う（Ｓ７０９）。

確認結果がＮＧであった場合（図のａｌｔの応答ＮＧ）、Ｓ７１０が実行され、配信装置１は外部端末３に対して配信ＮＧの応答を返す（Ｓ７１０）。この際には必要に応じて、後述する図１６のように配信が不可能な理由を提示するメッセージが外部端末３において表示される。

このように、配信装置１で使用中のリソースに対して配信要求を受けた場合、リソース解放の要求をリソース使用中の外部端末に対して行った後に、要求の応答に応じた処理を行う。これにより、現在リソースが使用中で配信などの動作ができない場合にも、リソース使用者の許可を受けた場合には、現在のリソースの使用を停止し、要求された処理を行うことが可能になる。

図８のリソース解放要求メッセージの例では、８００は配信装置または外部端末の有する表示部４７または外部入出力端子４１を経由して出力される映像出力全体。表示される情報としては、「端末名」８０１、「ユーザ名」８０２、「要求リソース」８０３、「できなくなる操作」８０４、などを記載している。

それぞれの意味は、「端末名」は競合するリソースを使用する処理を要求している他の端末、「ユーザ名」は競合するリソースを要求するユーザ、「要求リソース」は競合しているリソース、「できなくなる操作」は、リソースを譲ることにより当該端末（図７における外部端末２）でできなくなる処理を表している。

リソース解放要求メッセージの表示に必要な情報は、配信装置１が配信要求を外部端末３から受信する際に受信するか、または必要に応じて配信装置１が外部端末３に要求を行って取得した情報と、配信装置１が保持している情報とを合わせて外部端末２に通知する。

これらの情報をリソース解放要求メッセージとして表示し、リソースを使用しているユーザにリソース解放要求への応答を行わせることにより、リソースを使用しているユーザが、どの端末およびユーザからリソース解放要求を受けているかを確認することが可能となり、相手や状況に応じたリソースの有効活用が可能になる。また、必要な情報を必要な場合にのみ取得するようにすることにより、通信時のデータ量を削減可能となる。

ここで、ユーザ応答確認オブジェクトとして、「二度と表示しない」という選択肢がある。ユーザがこの選択肢を選択した場合は、後述する「リソースロック」の状態を「する」に変更する。「リソースロック」の判定処理については後述する。なお、「二度と表示しない」という選択肢は一例で、他の文言を使用してもよい。

またＳ７０４にて前記処理待ち通知を受け、外部端末３にて表示されるメッセージ（以下処理待ちメッセージ）の例を図９示す。「端末名」９０１は競合するリソースを現在使用している端末名、「ユーザ名」９０２は競合するリソースを現在使用しているユーザ名、「要求リソース」９０３は要求しているリソース、「相手の操作」９０４は、現在外部端末２が競合するリソースを使用して行っている処理の内容を表示している。このようにして、リソースを使用した処理を要求しているユーザが、リソースを使用しているユーザと、端末、その操作内容を知ることが可能になる。

処理待ちメッセージ表示に必要な情報についても上記リソース解放要求メッセージの例と同様に、配信装置１が配信要求を外部端末２から受信する際に同時に受信するか、または必要に応じて配信装置１が外部端末２に要求を行って取得した情報と、配信装置１が保持している情報とを合わせて外部端末３に通知する。

上記例においては、それぞれのメッセージ表示について、それぞれの機器が作成したメッセージを表示するように記載しているが、機器が作成したメッセージの表示のみでなく、相互の通信による表示などの出力を行っても良い。

例えば、処理待ちメッセージ９０５のユーザ応答確認オブジェクト９０６に表示されている「チャットに移行」をユーザが選択した場合、またはリソース解放要求メッセージ８０５に同様の表示を行い、それをユーザが選択した場合、などには、それぞれの外部端末のユーザが作成したテキスト情報や、それぞれの外部端末が撮影した映像情報および／または音声情報、をユーザが操作入力部３４に入力し、その情報を外部端末間で送受信を行い表示するなどにより、リソース競合をしているユーザ間または端末間での相互情報通信状態（チャットモード）に移行しても良い。

これにより、それぞれのユーザが、リソース競合時にメッセージや機器情報以外の情報を送受信することが可能になる。また前記の通りユーザ応答確認オブジェクトに「チャットに移行」のオブジェクトを配置することにより、リソースが競合している場合に容易にチャットモードに移行し、リソースの使用について交渉や話し合いをすることが可能となる。

上記チャットの経路としては、配信装置１をそれぞれの端末のサーバとして情報を経由させる方法と、外部端末同士で相互の位置情報（例えばＩＰアドレス）を交換し、直接情報を送受信する方法の両方がある。

また上記チャットモードへの移行は、上記ユーザが「チャットに移行」を選択した場合以外にも、メッセージ表示時に自動的に移行しても良い。この場合、メッセージの一部に上記外部端末のユーザが作成したテキスト情報や、それぞれの外部端末が撮影した映像情報が表示されることになる。これにより、ユーザが操作を行わない場合にも、リソース競合時に自動的にメッセージや機器情報以外の情報を送受信することが可能になる。

リソース解放要求メッセージや処理待ちメッセージについては、配信装置１から外部端末にメッセージ作成に必要な情報のみを送信する方法と、配信装置１がメッセージを含む画像情報を作成して送信する方法との両方がある。

配信装置１が画像情報を作成して外部端末に送信する場合は、画像情報が送信されるため、配信装置１および通信路の負荷が高くなるが、外部端末側での処理が簡略化され、また外部端末側では情報の内容を解釈せず画像情報を表示するだけであり、汎用性の高い処理が可能になるなどのメリットがある。

図７のＳ７０７の処理については必ずしも実行する必要は無く、例えば前記リソース解放要求Ｓ７０５を受信した時点で、外部端末２で配信停止に関する処理を実行しても良い。そのようにすることにより、配信装置１と外部端末２の通信量を削減可能となる。またＳ７０４およびＳ７０５の処理順序については交換可能である。

また、Ｓ７０５において、リソースの解放要求を行う外部端末は一つとは限らない。例えば前記配信要求Ｓ７０３を配信装置１が受信した場合に、前記要求された配信を実行するためには、トランスコーダ、ライセンス、記録媒体の同時処理数、の３つのリソースが必要な場合がある。その場合には、３つのリソースそれぞれの使用状況を確認し、前記リソースを使用しているそれぞれの端末に対して、リソース解放要求を行う必要がある。

この場合、Ｓ７０６における確認結果は、当該３つのリソースを利用している全ての外部端末の確認結果がＯＫの場合に、応答ＯＫとして処理を進める。このようにすることで、複数のリソースを使用する処理であっても、上記の場合と同様に処理を進めることが可能となる。

また別の例として、処理に用いるリソースについて、リソースを使用しているいずれかの端末（ユーザ）が解放すれば使用可能な場合もある。例えば、Ｓ７０３の配信要求を実行するためにトランスコーダを使用する必要があり、外部端末４と外部端末５への配信に、それぞれトランスコーダを使用している場合、外部端末４と外部端末５のいずれかがリソースの解放を行えば、配信が可能となる。このような場合には、前記リソースを使用している全ての端末にリソース解放要求を行い、いずれかの端末から解放ＯＫを受信した場合に、前記応答ＯＫの場合の処理を実行する。

また別の例としては、前記リソースを使用している端末にリソース解放要求を順次実施し、何れかの端末から解放ＯＫを受信した場合に、前記順次実施するリソース解放要求を終了して、応答ＯＫの場合の処理を実行する。このようにすることにより、各リソースの同時処理可能数が制限されている場合に、それぞれ排他を行いながら処理を行うことが可能となる。
＜リソース管理テーブル＞
配信装置１でリソースを管理するために用いる、リソース管理テーブルの例を図１０に示す。ここではリソースの例として、トランスコーダ、ライセンスが存在し、リソースごとに下記記載の項目について管理している例を示している。項目の内容について下記それぞれ説明する。

「使用状況」１００２は、リソースが現在処理に使用されているか否かを表している。「使用操作」１００３は、リソースを使用している動作の内容について示している。図１０の例においては、例えばトランスコーダ１は番組Ａの配信に使用されており、トランスコーダ２は番組Ｂの録画に使用されている例を示している。

「使用端末」１００４は、リソースを使用している端末を示している。図１０の例では、トランスコーダ１の配信は携帯端末１が使用していることを表している。これにより、トランスコーダ１を他の処理で使用したい場合には、携帯端末１に対して、リソース解放の要求を行えば良いとわかる。

「使用者」１００５は、リソースを使用しているユーザに関する情報を示している。図１０ではトランスコーダ１は「お父さん」が使用しており、トランスコーダ２は「サーバ」（配信装置１）が前記自動録画を行っている例が示されている。外部端末でのリソース使用ユーザの判定方法としては、例えばユーザ認証（パスワード認証、生体認証）などがあり、その情報を配信装置１が外部端末から取得し、リソース管理テーブルに登録する。

「使用予定時間」１００６は、リソースの使用予定時間を示しており、例えば配信動作であればコンテンツの残り再生時間、録画動作であれば録画番組の終了予定時刻までの時間、記録媒体に記録されているコンテンツのトランスコード動作であれば終了時間（例えばコンテンツの長さが３０分の番組を、６倍速トランスコードした場合には５分）などがある。

配信動作については、コンテンツの再生速度は一定ではないため、再生速度に応じて値は変化する。「リソースロック」１００７とは、上記説明のリソースロックを「する」にした場合に有効となるフラグである。「優先度」１００８は前記リソース使用の優先度である。「リソースロック」と「優先度」による具体的な判定方法は後述する。以上のようにリソースの使用状況を管理する。

上記の項目については一例であり、不要な項目を削除する場合や、別の値を使用する場合があっても構わない。例えば、「リソースロック」の項目の代わりに「優先度」を使用する場合もある。具体的な方法は後述する。項目を削減することにより、管理テーブルのデータ量の削減や、判定処理の容易化が可能となる。

制御部２１は、使用しているリソースの状況が変化した場合には、前記リソース管理テーブルの情報を適宜更新する。例えば、リソースの使用状況が変化し、リソースを使用する処理が終了した場合には、リソースの使用状況を「未使用」とする。リソースの使用状況を未使用とすることを、リソースの解放とも言う。また更新に必要な情報については、通信部２５を介して外部端末から情報を適宜取得する。

リソースについて、図１０のリソース管理テーブルの例においては、トランスコーダが２つあるような表記としているが、実際にトランスコーダが２つ存在していなくても良い。例えば、トランスコーダの処理性能（処理速度や記憶領域のサイズ等）により、同時に実行できるトランスコード処理が２つまでの場合には、図に示すようにトランスコーダ１とトランスコーダ２という管理をすると、処理が容易になる。このようにリソースの数は処理可能な要求の個数で管理することが望ましい。

ただし、トランスコーダによっては、ある処理（例えばＭＰＥＧ−２のトランスコード）は３つ同時に処理可能だが、ある処理（たとえばＨ．２６４のトランスコード）は同時に２つまで、という制限がある場合がある。このような場合については、トランスコーダの数によって管理せず、それぞれのトランスコーダがどういった処理を同時に処理が可能か、現在行っている処理は何か、特定の処理を行いたい場合にどの処理を停止してリソースを解放すれば良いかを別で管理する必要がある。

ここで使用者と使用端末の関連については、処理によっては（例えば配信処理）リソースの使用中は変化が起きないが、録画処理など、実行時に外部端末を利用せずにリソースを使用している場合には、録画を行っている使用者の使用端末が無い、または使用端末が変更になるという場合がある。その場合には、「使用端末」のデータは、前記ユーザが現在使用している端末を登録するように更新する、または使用端末の部分にデータを登録せず、制御部21などで管理する別のテーブル（以下端末使用者管理テーブル）で使用者と使用端末の関連を管理する、といった方法がある。
＜リソース競合時の配信装置の動作＞
配信装置１がリソースを必要とする処理を行う場合に、制御部２１で実行される処理フロー例について、図１１を用いて説明する。

制御部２１は、処理要求を受信した場合などに、現在実行する処理に必要なリソースを確認する（Ｓ１１０１）。必要なリソースとは例えば配信時のトランスコーダなどである。そこで、必要なリソースの使用状況を、リソース管理テーブルなどから判断する。

リソースの使用状況を確認した結果、必要なリソースが未使用の場合は（Ｓ１１０２のｙｅｓ）、リソースを必要とする処理を開始する（Ｓ１１０３）。必要なリソースがすでに使用されている場合（Ｓ１１０２のｎｏ）には、リソースを使用している外部端末または配信装置（以下、リソース使用機器）をリソース管理テーブルから判定し、リソース使用機器に対してリソースの解放要求を行う（Ｓ１１０４）。

解放要求を行った後に、制御部２１はリソース使用機器からの応答を待つ（Ｓ１１０５）。この際に、必要に応じて処理要求を行った外部端末に対して、処理待ち通知を送信する。この通知により、外部端末は処理待ちメッセージを表示する。

リソース使用機器からの応答を受信後、応答の内容がリソース解放ＮＧであった場合（Ｓ１１０６のｎｏ）、リソースを必要とする処理の要求を行っている端末に対して、現在リソースの使用が不可能な旨を通知する（Ｓ１１０７）。

応答の内容が、リソース解放ＯＫであった場合（Ｓ１１０６のｙｅｓ）は、リソースの解放処理を行う（Ｓ１１０８）。リソース解放処理の内容としては、リソースを使用する処理を停止し、内部のリソース管理テーブルの内容を、前記リソースについて「使用中」から「未使用」に変える処理を行う場合や、前記リソース使用機器に対して、別途リソースの解放処理を要求する場合がある。

リソース解放処理が終了した後に、前記リソースを使用する処理を実行する（Ｓ１１０３）。このようにして、受信した配信要求についてリソースの使用状況が競合している場合に、リソースを現在使用している端末の応答を確認し、処理を実行することが可能となる。

上記リソースを使用する処理としては、配信、録画、視聴、再生などが挙げられる。また、Ｓ１１０３などにて、リソースを使用する処理を新たに開始した場合には、適宜リソース管理テーブルに必要な情報を登録しておく。

Ｓ１１０５の、処理待ち通知送信時に、リソース管理テーブルの情報を適宜送信することにより、外部端末を使用しているユーザが必要な情報を取得することが可能になる。例えば、「使用操作」「使用端末」「使用者」を送信することにより、それぞれどのような処理に、どの端末で、誰が、リソースを使用しているかをユーザが知ることが可能になる。また、「使用予定時間」が提示されることにより、いつ頃にリソースが解放される予定かを知ることが可能になる。

またＳ１１０２において、リソース管理テーブルの「優先度」を用いた判定を行っても良い。具体的には、優先度の値に応じて、例えば低優先度の処理が高優先度の処理のリソースを要求して競合する状況においては、確認を行わずに無条件で低優先度の処理側のリソース使用をＮＧと判定する、またはその逆に、高優先度の処理が低優先度の処理のリソースを使用する状況においては、確認を行わずに無条件で高優先度側のリソース使用をＯＫと判定する、
または同一優先度のときにのみリソース解放確認を行う、といった処理が可能となる。処理の判定方法としては、例えばＳ１１０２において、重複するリソースの低優先度の処理を解放し、Ｓ１１０３の処理を行う、または低優先度の処理要求を却下して処理を終了するなどである。

優先度の決定の方法としては、ユーザが明示的に設定を行う、またはユーザに対して予め優先度を割り当てておく（例えばユーザ１は優先度３、ユーザ２は優先度１など）、またはリソースを使用する端末ごとに優先度を割り当てておく（例えば配信装置１は優先度２、外部端末２は優先度１など）、または処理ごとに優先度を割り当てる（例えば配信優先度１、録画は優先度３、視聴は優先度２、など）、または宅外からの要求を優先（宅外からの処理は優先度３、宅内からの処理は優先度１）といった方法がある。このように優先度を割り当てて判定処理を行うことにより、不要なリソース解放確認を行わずに、それぞれ優先したい処理にリソースを自動的に割り当てることが可能となる。

また同じくＳ１１０２において、「リソースロック」を用いた判定を行っても良い。処理で必要となるリソースについて、前述または後述の処理により「リソースロック」が「する」になっている場合は、上記優先度判定の場合と同様に、確認を行わずに無条件でリソース使用をＮＧと判定し、処理要求を却下する。「リソースロック」が「しない」になっている場合には、通常通り判定処理を行う。このように処理することにより、重要な処理は優先的にリソースを使用する、または、ユーザがリソースを解放する意図が無い場合に、再度リソース解放要求メッセージが表示されることを防ぐことが可能になる。

前記リソースロックについては、「リソースロック」の項目の代わりに「優先度」を使用し、リソースロックを「する」に変更する代わりに、優先度を最高、またはそれ以上とすることによりリソースのロックを実現する方法もある。そのように項目を削減することにより、管理テーブルのデータ量の削減や、判定処理の容易化が可能となる。

優先度に関する処理については、上記の例以外にも、処理が遅延しても問題無い処理（たとえばスケジュールで実行されるコンテンツ変換。以降、非リアルタイム処理）については、スケジュール実行時刻を遅延させ、リアルタイム性の高い処理（例えば配信や録画）を優先させることが好ましい。そのため、上記の優先度について、リアルタイム性が高い内容を高い優先度、非リアルタイム処理を低い優先度、とすることにより実現可能である。その場合には、リソースが解放されると再度非リアルタイム処理を実行するようにすることが望ましい。そのような場合には、非リアルタイム処理について後述するリソース予約を行うことが有効である。

また、例えば配信装置において受信した放送コンテンツのＴＳをトランスコーダで処理して記録している場合に、そのトランスコーダの使用を希望するリソース解放要求を受信すると、放送コンテンツをＴＳのまま記録するように切り替え、リソース解放要求の送信元が要求した処理が終了した後に、記録したＴＳをトランスコーダで処理するように構成してもよい。

また「リソースロック」や「優先度」の判定については、配信装置１で必ず実施する必要は無く、処理待ち通知やリソース解放通知に上記情報を追加し、外部端末側で判定を実施しても良い。そのようにすることにより、配信装置１での処理が容易になり、また外部端末で値を基に判定を行う処理が可能になる。

Ｓ１１０４におけるリソース使用機器の判定方法としては、リソース管理テーブルから判定を行う方法の他に、リソース管理テーブルから登録されている使用者を判定した後に、その使用者が使用している機器を端末使用者管理テーブルから検索し、その機器をリソース使用機器として処理を行うことも可能である。

このようにすることにより、例えばユーザが配信装置を使ってリソースの使用を予約し（例えば放送コンテンツの録画予約）、そのリソースを使用する際にはそのユーザがその配信装置から離れている場合であっても、そのユーザが持ち歩いている他の端末（例えば携帯電話、タブレット端末等）にメッセージを送信することが可能となり、より確実にリソースを利用しているユーザにリソース解放要求を伝えることが可能となる。
＜録画開始時の配信停止処理＞
次に予約等による録画開始時に、現在のリソース使用者に確認を行う例について説明する。制御部２１の動作は、図１１の例と同様であるが、実行開始のトリガとしては、例えば予約録画開始の一定時間前などとなる。

まず予約録画に必要なリソース（例えばトランスコーダ）の確認を行い（Ｓ１１０１）、前記リソースが使用中であった場合（Ｓ１１０２のｎｏ）、リソース管理テーブルを確認し、リソースを使用している端末にリソース解放要求を行う（Ｓ１１０４）。この際に、解放要求を受信した端末で表示されるメッセージ例について図１２に示す。

１２０４は表示されるメッセージ（以下、配信停止確認メッセージ）全体を示している。ここで表示される内容の例としては、予約録画の対象である番組の情報１２０３（放送局情報、番組名、ＣＨ情報、放送時間など、以下予約録画番組情報）、競合しているリソースである要求リソース１２０２、予約録画を登録しているユーザ名である予約登録ユーザ名１２０１（もしくは自動録画である旨の表示）、予約録画が開始される時刻、または／および予約録画が開始されるまでの時間、などがある。これらの情報を外部端末で表示するために、配信装置１はこれらの情報もしくは関連する情報をリソース解放要求と共に、もしくは別途外部端末に送信する。

また前記の例と同様に、メッセージにユーザ応答確認オブジェクトも表示し、ユーザの応答を確認する。ユーザ応答確認オブジェクトの例を１２０５に記載する。ユーザ応答確認オブジェクトのユーザによる応答を受信した後に、外部端末は配信装置１に対して、リソース使用ＯＫかＮＧかの応答を返す。前記リソース使用の応答を受信した制御部２１は、前記応答がリソース使用ＯＫであった場合（Ｓ１１０６のｙｅｓ）は、リソースを解放する処理を行い（Ｓ１１０８）、前記番組の予約録画を開始（Ｓ１１０３）する。

前記応答がＮＧ（例えば図のユーザ応答確認オブジェクトの「録画を中止する」を押下）であった場合（Ｓ１１０６のｎｏ）、制御部２１は予約録画の実行を中止するなどの処理を行う（Ｓ１１０７）。このようにして、予約録画の実行時に、競合するリソースを使用している端末に対して必要な情報を提供し、ユーザの応答に応じてその後の動作を決定することが可能になる。

ここで、Ｓ１１０５の応答待ちにおいて、一定時間（例えば予約録画開始までの時間、または予約準備時間を減算した予約録画開始までの時間、または固定時間（５分など））経過するまで前記端末からの応答が無かった場合には、自動的にリソース使用ＯＫとしてその後の処理を実行することが好ましい。これはリソースを使用しているユーザがメッセージを確認できる状況に無かった場合に、予約録画が失敗することを防ぐためである。

または、リソース管理テーブルのリソースロックや優先度に応じて、リソースの使用可否を判断するようにしてもよい。これにより、ユーザにとって優先度の高い処理に対してリソースを使用することが可能となる。

または、現在配信中のコンテンツについて、前記の通りトランスコードを行ってから配信を行っている場合には、すでにトランスコード済みのコンテンツなどトランスコード不要で配信可能なコンテンツがある場合には、そちらを配信する、または配信を受信する側が対応している場合にはＴＳ録画したコンテンツをトランスコードを行わずに配信するように変更することにより配信を継続するようにしてもよい。この場合には切り替え時の再生位置から、視聴を継続できるようにコンテンツを切り替えることが望ましい。

次に、ユーザが応答確認オブジェクト１２０５の「代替案の表示」を押下した場合に、表示されるメニューの例を図５に示す。このメニューの表示は、配信装置〜送信された情報に基づいて表示してもよいし、外部端末が当該外部端末内の情報を用いて表示するように構成してもよい。ユーザ応答確認オブジェクト２００６の選択肢に記載したそれぞれの操作ボタン（図５の２００１、２００２、２００３、２００４、２００５）をユーザが選択した場合の動作について以下に記載する。

「録画レートの変更」２００１をユーザが選択した場合、競合している録画処理のレートについて、例えばトランスコーダを使用しない記録方式（ＴＳ記録）に変更する。

「配信レートの変更」２００２をユーザが選択した場合、配信コンテンツについて、例えば上記記載の通りトランスコーダを使用しない配信に変更する。

「別コンテンツの再生」２００３をユーザが選択した場合、例えば後述する、現在のリソースで配信可能なコンテンツのリスト、または配信可不可が記載されたコンテンツリストを表示する。

「機器操作画面の表示」２００４をユーザが選択した場合、例えば前記録画が開始される機器の操作パネルを操作端末に表示し、録画や予約の操作を行えるようにする。

「チャットに移行」２００５をユーザが選択した場合、前述のチャットモードへの移行を行う。

このようにしてリソース競合時の代替案を提示し、その操作をユーザが選択可能とすことにより、限られたリソースを有効活用することが可能となる。

これら操作ボタンについては、全てを表示する必要は無く、適宜取捨選択しても良い。また対象の動作が行えない場合については、操作ボタンを表示しない、またはグレーアウト（オブジェクトをグレーで表示）するなどすると、ユーザに理解しやすい表示にすればよい。例としては、異なる配信レートで配信するコンテンツが無い場合に「配信レートの変更」を表示しない、チャットを実行する対象ユーザがいない場合に「チャットに移行」をグレーで表示する、などである。

１２０５の「代替案の表示」を押下した場合に、図５のメニューを表示せずに、上記いずれかの動作について、予め定められた動作を実行する、または別の設定画面で設定した内容に基づいて動作する、というようにしても良い。そのようにすることにより、ユーザの操作を簡略化することが可能となる。

また、メッセージの表示例としては、図１３に示すような。配信停止までの時間と簡易なユーザ応答確認オブジェクト１３０１の表示のみの構成としても良い。この場合は配信されているコンテンツを視聴しつつ、リソース競合に関する処理が可能となる。また、１３０２の「詳細」を押下することにより、上記図１２のようなメッセージを表示する構成にしてもよい。これにより、ユーザの視聴を妨げずに、段階的に情報を提示することが可能になる。

ここで時間の単位については、図のように分単位ではなく、秒単位であっても良い。その場合にはより詳細に配信停止までの時間を確認できる。

また、１２０５の「代替案の表示」のオブジェクトは、図８や図９に示すメッセージに含めることも可能である。この場合、「代替案の表示」が選択されると、図５これにより、配信装置において配信の要求が重複した場合であっても、代替案を利用して効率よく外部端末にコンテンツを配信することが可能となる。
＜録画中の配信開始処理＞
次に、録画などの処理で配信装置１のリソースを使用している場合に、前記リソースを使用する配信要求が行われた場合の配信装置１における制御部２１の処理について説明する。

上記状況での制御部２１の処理フローは、図１１の場合と同様である。まず配信処理に必要なリソースを確認し（Ｓ１１０１）、必要なリソースが使用可能な場合は（Ｓ１１０２のｙｅｓ）、リソースを使用した処理を開始する（Ｓ１１０３）。

必要なリソースが使用可能でない場合は（Ｓ１１０２のｎｏ）、そのリソースを使用した録画を登録しているユーザが使用している端末に対してリソースの解放要求を行う（Ｓ１１０４）。

例えば、リソースを使用した録画を登録しているユーザの使用している端末が外部端末２の場合には、外部端末２に図８のようなリソース解放要求メッセージが表示される。以後の動作は前記リソース競合時の動作の場合と同様である。

前記リソース解放要求メッセージにおいては、図８の８０４に記載の通り、録画予約されている番組の情報が記載されている。このようにどの番組の録画が中止されるかの確認をした上で、リソースの可否を検討することが可能となる。

前記リソースを使用しているユーザの検索方法としては、まず録画処理を行っているユーザを、前記リソース管理テーブルの使用者や、予約情報から判定し、その後、前記ユーザが使用している端末を、別途端末使用者管理テーブルなどから確認し、前記端末に対して、配信装置１が前記リソース解放要求を送信する。

録画処理を行っているユーザが、どの端末を使用しているかの情報が無い場合には、例えば配信処理を行わず、図１１のＳ１１０５の応答待ちも行わず、Ｓ１１０６においてリソース解放ＮＧと判定し、処理を終了させても良い。その場合には、録画処理を実行しているユーザに対しての確認待ちで不要に待つことが無くなり、さらに許可無く録画を中止させることが無くなる。

このような状況においては、リソース要求側に、その状況を通知（例えばＳ１１０７において、録画処理を使用しているユーザが見つからないため、配信が実行できない旨を通知）することが望ましい。これにより、ユーザがなぜ配信ができないかという状況を把握することが可能になる。

また逆に、同様の状況において、図１１のＳ１１０５の応答待ちも行わず、Ｓ１１０６においてリソース解放ＯＫと判定し、録画処理を中止させても良い。この場合には録画処理が予約ユーザ対して許可無く中止される恐れがあるが、一方で配信処理が録画している間常に禁止になる状況を防ぐことが可能になる。このような状況においては、例えば予約録画の履歴に、前記配信処理により録画が中止されたことを記載しておくことが望ましい。これにより、後ほどなぜ予約が中止されたかを把握することが可能となる。

ここで、リソースを使用しているユーザと、予約を登録しているユーザが同一の場合、または上記例のように録画処理を行っているユーザが不明の場合に、要求を行った外部端末に表示されるリソース解放要求メッセージの例を図１４に示す。

メッセージには、録画予約を行ったユーザ、要求しているリソース、録画処理を行っている番組が表示されている。この画面で、ユーザ応答確認オブジェクトでＯＫを押下された場合には、前記Ｓ１１０６でリソース解放をＯＫとして判定を行う。このように、現在の録画処理の状況を確認しながら、操作の内容を停止するか否かの判定を行うことが可能になる。

図１４のユーザ応答確認オブジェクトにおいて、ユーザが「代替案の表示」を押下した場合の動作は、上記録画開始時の配信停止処理の場合と同様である。
＜リソース使用時のコンテンツリスト表示＞
外部端末にて表示されるコンテンツリストの例を図１５に示す。ここでは項目として、「タイトル」「時間」「記録品質」「記録ＣＨ」「現在配信可」「利用者」「端末」「配信用番組」が表示される例を記載している。

「タイトル」とは、コンテンツのタイトルであり、放送記録コンテンツの場合は番組名などになる。「時間」はコンテンツの再生時間である。「記録品質」は記録を行った際の映像のビットレートの目安などを示しており、例えば図中のＴＳはＴＳ録画したコンテンツであることを示しており、「ＳＰ」は標準画質で記録されてことを示している。「記録ＣＨ」は放送記録時の記録した番組の放送ＣＨを示している。

「現在配信可」とは、配信装置１が現在のリソース管理テーブルから判断した状況において、それぞれのコンテンツが配信可能か否かを示しており、「○」は現在のリソース状況で配信可能、「×」は現在のリソース状況で配信不可能なことを表している。「利用者」は、前記リソース状況が配信不可能な場合、そのリソースを誰が使用しているか、つまりどの利用者がリソースを解放した場合に配信が可能になるかを表している。「端末」は、同じくそのリソースを使用している処理を実行している端末を表している。「配信用番組」については、例えば配信を行うために、事前にコンテンツに対してトランスコード等の処理を行う、または同様の番組を別経路（例えばワンセグ放送、またはネットワーク経由で同様コンテンツを取得）で記録する、等の処理が行われたコンテンツの有無を表している。

このようにしてユーザに対して、それぞれの番組が配信可能か否か、配信ができない場合にはどのような状況かという情報を提示することが可能になる。

また、外部端末の処理としては、「現在配信可」の情報について判定を行い、配信不可であるコンテンツをリストに表示しないということも可能である。その場合にはユーザが現在配信可能なコンテンツのみを確認することができ、操作が容易になる。

また、配信装置から外部端末に対して、配信可能なコンテンツのリストの情報のみを送信するという方法もある。その場合ユーザにとってのメリットは外部端末で処理する場合と同様であるが、機器としても、例えば外部端末については、上記フラグを判断しての表示や非表示の処理が不要となり、また情報を送受信する際のデータ量の削減も可能となる。

上記コンテンツリストを表示する際に、現在のリソース状況で配信が不可能なコンテンツが存在する場合などにおいて、前記リソース管理テーブルのデータをそのまま表示することも可能である。例えば配信装置１が外部端末に対してリソース管理テーブルのデータを送信し、外部端末にて前記リソース管理テーブルの情報を表示することにより、ユーザはリソースの使用状況を確認することが可能となる。
＜リソースの予約＞
次にリソースの競合の結果、要求した処理が実行できなかった場合などに、ユーザがリソースの予約を行う場合の例を以下に説明する。

例えば図７のＳ７１０のＮＧの通知、またはＳ７０４の処理待ち通知を受信した場合に、外部端末３にて表示するメッセージの例を図１６に示す。メッセージに表示される情報としては主に図９の、「端末名」「ユーザ名」「使用（要求）リソース」と同様の記載である。ここでは「終了予定時刻」として、上記「使用予定時間」と同様の値を記載している。またユーザ応答確認オブジェクト１６０７に「予約する」という項目が追加されている。

前記ユーザ応答確認オブジェクト１６０７のユーザの応答が「予約する」の選択であった場合には、リソース予約テーブルに情報を追加する。リソース予約テーブルの例を図１８に示す。１８０１がテーブル全体である。項目としては、ここでは「予約ＩＤ」１８０２、「予約リソース」１８０３、「予約操作」１８０４、「使用端末」１８０５、「予約者」１８０６、「優先度」１８０７、「通知方法」１８０８、などがある。

「予約ＩＤ」１８０２は、リソースの予約登録ごとに割り振られるユニークなＩＤを示す。「予約リソース」１８０３は、予約の対象となるリソースを示す。「予約操作」１８０４は、予約操作時に行った操作の内容で、「予約ＩＤ」１８０２が１の例では、番組Ａの配信に関してリソースであるトランスコーダ１の予約を行った例を示している。「使用端末」１８０５はリソースの予約を行っている端末を示す。「予約者」１８０６はリソースを予約した予約者を示す。「優先度」１８０７は、リソース予約の優先度を表し、例えば同一リソースに対して予約が重複している場合、優先度が高い予約について先にリソースを割り当てるなどを行う。優先度は予約者や使用端末により決定する場合や、また予約登録順での優先度、といった場合がある。「通知方法」１８０８については、リソースが解放されたことを通知する手段の種類について示している。通知方法の例としては、メッセージによる表示、電子メールなどによる通知、または電話通信の着信による通知、などが挙げられる。通知方法の登録手段としては、例えば予約登録時に、ユーザがユーザインターフェースを介して前記通知方法を選択する、またはリソースを予約した機器により、配信装置１が自動的に選択する（例えば携帯電話であればメール、メッセージ表示に対応していればメッセージ、など）。「通知方法」１８０８が予約テーブルに存在しない場合には、例えばネットワークでの固定プロトコルによる通知としても良い。

リソースが解放された場合の、制御部２１の処理について図１９を用いて説明する。リソースが何らかの理由（例えば配信停止、録画終了）で解放された場合、まず制御部２１はリソース予約テーブルを確認する（Ｓ１９０１）。リソース予約テーブルに対象リソースの予約が存在していない場合（Ｓ１９０２のｎｏ）、リソースの使用状況を「未使用」にして（Ｓ１９０３）処理を終了する。

リソース予約テーブルに対象リソースの予約が存在している場合（Ｓ１９０２のｙｅｓ）、リソース予約テーブルに記載されている「使用端末」（もしくは「予約者」が使用している端末）に対して、「通知方法」に示された手段でリソースが解放されたことを通知する（Ｓ１９０４）。通知メッセージの例を図１７に記載する。図１７のメッセージでは、解放されたリソースと、リソース予約時に行っていた操作などが表示される。

通知を行った制御部２１は、通知に対する応答を待つ（Ｓ１９０５）。その後図１７のユーザ応答確認オブジェクト１７０３で「ＯＫ」が押下されたことの通知を制御部２１が受信した場合（Ｓ１９０６のｙｅｓ）、前記リソース予約時の操作（例えば番組の配信）などを実行する（Ｓ１９０７）。

図１７のユーザ応答確認オブジェクト１７０３で「キャンセル」が押下されたことの通知を制御部２１が受信した場合、リソースの状態を「未使用」とし（Ｓ１９０３）、処理を終了する。これらの処理を、前記解放されたリソースに関する予約がなくなるまで処理を繰り返す。このようにして、リソースの競合が発生した場合などに、リソースの予約をしておき、リソースが解放された場合には通知を受け、リソース競合発生時の処理を再開することが可能になる。

上記リソース解放の通知は、たとえばユーザが使用端末を変更していた場合には、予約を実行した使用端末ではなくユーザに対してメッセージを通知することが望ましい。そのためには、別途使用端末と使用者の関連付けを管理するテーブルを用いて、前記使用者と予約者が一致している端末に対して、前記通知を行うようにする。これにより、予約を行ったユーザが予約を行った端末とは別の端末を使用している場合にも、前記ユーザに対して通知を行うことが可能になる。

前記リソース予約テーブルの「予約操作」については、配信装置１ではなく、「使用端末」側で保持する場合もある。その場合には、配信装置１からリソース解放の通知を受けた場合に、リソースを使用する操作について、使用端末側で判断を行い、処理を行う必要がある。

またテーブルに登録する情報は上記に記載した以外にも、「予約を行った時間」や「タイムアウト」といった情報を登録しておく場合も考えられる。その場合にはその時間を基に、一定時間を経過した予約は削除するなどすると、不要な予約が多く登録されることを防ぐことも可能になる。

ユーザが、ユーザ応答確認オブジェクト１７０３で「別の操作をする」を選択した場合の動作としては、例えば配信要求の予約を行っていた場合などは、前記解放されたリソースを使用して配信が可能なコンテンツリストを表示しても良い。これにより、ユーザの状況が変わっている場合に異なるコンテンツを配信することも可能となる。

メッセージにおけるリソースの名前や端末名は、ＩＤのような数字や記号での表示でも良いが、それぞれの機器に登録されたユーザにとってわかりやすい名称を用いることにより、ユーザにとっての使い勝手が向上するため、配信装置や外部端末でそれらのＩＤをユーザにとってわかりやすい名称に変換する処理を行うことが好ましい。

また、テーブルについても、実施例においては文字で説明を行っているが、数値または文字列など管理しやすいデータ形式としてもよい。また、データの形式としてテーブルのような記載を行っているが、ＸＭＬのような形式で記載し、データ量を削減することも可能である。

また、実施例におけるメッセージの構成要素については、実施例の記載に限定したものではなく、メッセージごとにそれぞれ記載の内容について追加で情報を記載しても良い。例えば、「代替案の表示」を図８や図９のユーザ応答確認オブジェクトの選択肢に追加しても良い。これにより、リソース競合時のユーザが入手可能な情報とその後の操作の選択肢が広がることになる。

以上説明した実施例によれば、ユーザは希望する処理に使用する配信装置のリソースが競合していた場合に、競合しているリソースを使用しているユーザ、端末、競合しているリソース、使用している処理、リソースの使用予定時間、などを知ることが可能になり、さらにリソースを使用しているユーザに対して、リソースの解放要求を簡易な手段で要求することが可能となる。結果として、リソースが競合している場合でも、リソースを使用しているユーザが許可をすれば、リソースを使用した処理（例えば配信処理）が可能となる。

また配信処理と録画処理が重複している場合にも、ユーザに対してメッセージ表示を行い、リソースの競合に関する情報の提示と、その際の操作を選択することが可能となる。

また、上記競合の結果リソースが使用できない場合には、リソースの予約を行い、リソースが解放された場合に、リソースを使用した操作が可能となる。

またリソースの競合時において、ユーザに対して代替案の提示を行うことにより、例えば現在のリソースで配信可能なコンテンツリストの確認や、録画や配信のレートを変更を容易に実行することが可能となる。

１ 配信装置
２ 外部端末
３ 外部端末
４ 通信中継装置
５ 送信装置
６ 放送中継装置
７ 公衆回線網
１１ ソース発生部
１２ エンコード部
１３ スクランブル部
１４ 変調部
１５ 送信アンテナ部
１６ 管理情報付与部
１７ 暗号化部
１８ 通信路符号化部
１９ ネットワークＩ／Ｆ部
２１ 制御部
２２ 汎用バス
２３ 放送受信部
２４ デスクランブラ
２５ 通信部
２６ 記録媒体
２７ 記録再生部
２８ コンテンツ変換部
２９ 多重分離部
３０ 映像復号部
３１ 音声復号部
３２ 映像処理部
３３ 音声処理部
３４ 操作入力部
３５ タイマー
４１ 外部入出力端子
４２ ネットワーク端子
４５ ユーザ操作入力
４６ 外部入出力処理部
４７ 表示部
４８ スピーカ
４９ 高速デジタルＩ／Ｆ

Claims (13)

1. 記録媒体に記録されたコンテンツを再生する記録再生部と、
   前記記録再生部で再生されたコンテンツを変換するコンテンツ変換部と、
   ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、
   前記コンテンツ変換部で変換したコンテンツを第１の機器に配信している際に当該第１の機器とは異なる第２の機器から前記コンテンツ変換部で変換したコンテンツの配信要求を受けると、前記第１の機器へコンテンツの配信に関するメッセージを送信することを特徴とする配信装置。
2. 請求項１の配信装置であって、
   前記コンテンツの配信に関するメッセージは、前記コンテンツ変換部を利用したコンテンツの配信を前記第１の機器とは異なる他の機器に譲るか否かを問い合わせるメッセージであることを特徴とする配信装置。
3. 請求項２の配信装置であって、
   前記メッセージには、前記コンテンツの配信要求を行った機器を示す情報が含まれることを特徴とする配信装置。
4. 請求項２または３のいずれかの配信装置であって、
   前記第１の機器から前記メッセージに対して前記コンテンツ変換部を利用したコンテンツの配信を前記第１の機器とは異なる他の機器に譲る旨の応答を受信すると、前記コンテンツ変換部で変換したコンテンツの前記第１の機器への配信を停止し、前記コンテンツ変換部で変換したコンテンツの前記第２の機器への配信を開始することを特徴とする配信装置。
5. 請求項１〜４の配信装置であって、
   前記コンテンツの配信に関するメッセージには、前記配信要求において要求された処理とは異なる処理である代替案の表示を示すオブジェクトが含まれることを特徴とする配信装置。
6. 請求項５の配信装置であって、
   前記第１の機器のユーザにより前記代替案の表示を示すオブジェクトが選択されると、前記第１の機器へ前記配信要求において要求された処理とは異なる処理の候補に関する情報を送信することを特徴とする配信装置。
7. コンテンツを受信する受信部と、
   記録媒体にコンテンツを記録し、記録媒体からコンテンツを再生する記録再生部と、
   コンテンツを変換するコンテンツ変換部と、
   ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、
   前記コンテンツ変換部で変換したコンテンツを他の機器に配信している際に、前記受信部で受信し前記コンテンツ変換部で変換したコンテンツの前記記録媒体への記録を開始する場合、前記他の機器にコンテンツの配信に関するメッセージを送信することを特徴とする配信装置。
8. 請求項７の配信装置であって、
   前記コンテンツの配信に関するメッセージは、前記他の機器へのコンテンツの配信の停止を通知するメッセージであることを特徴とする配信装置。
9. 請求項７または８の配信装置であって、
   前記メッセージには、前記コンテンツの記録媒体への記録の予約を行ったユーザを示す情報が含まれることを特徴とする配信装置。
10. コンテンツを受信する受信部と、
    記録媒体にコンテンツを記録し、記録媒体からコンテンツを再生する記録再生部と、
    コンテンツを変換するコンテンツ変換部と、
    ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、
    前記受信部で受信し、前記コンテンツ変換部で変換したコンテンツを前記記録媒体に記録している際に、他の機器から前記コンテンツ変換部で変換したコンテンツの配信要求を受けると、前記記録媒体へのコンテンツの記録を設定したユーザにコンテンツの記録に関するメッセージを送信することを特徴とする配信装置。
11. 請求項１０の配信装置であって、
    前記コンテンツの記録に関するメッセージは、前記コンテンツ変換部を利用したコンテンツの記録を停止して前記他の機器に前記コンテンツ変換部で変換したコンテンツの配信を開始することを許可するか否かを問い合わせるメッセージであることを特徴とする配信装置。
12. 請求項１１の配信装置であって、
    前記メッセージには、前記コンテンツの配信要求を行った機器を示す情報が含まれることを特徴とする配信装置。
13. 請求項１１または１２の配信装置であって、
    前記ユーザから前記メッセージに対して前記コンテンツ変換部を利用したコンテンツの配信を許可する旨の応答を受信すると、前記コンテンツ変換部で変換したコンテンツの前記他の機器への配信を開始することを特徴とする配信装置。

Images