"記録媒体に記録されたコンテンツを再生する記録再生部と、前記記録再生部で再生されたコンテンツを変換するコンテンツ変換部と、ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、前記コンテンツ変換部で変換したコンテンツを第1の機器に配信している際に当該第1の機器とは異なる第2の機器から前記コンテンツ変換部で変換したコンテンツの配信要求を受けると、前記第1の機器へコンテンツの配信に関するメッセージを送信することを特徴とする配信装置。請求項1の配信装置であって、前記コンテンツの配信に関するメッセージは、前記コンテンツ変換部を利用したコンテンツの配信を前記第1の機器とは異なる他の機器に譲るか否かを問い合わせるメッセージであることを特徴とする配信装置。請求項2の配信装置であって、前記メッセージには、前記コンテンツの配信要求を行った機器を示す情報が含まれることを特徴とする配信装置。請求項2または3のいずれかの配信装置であって、前記第1の機器から前記メッセージに対して前記コンテンツ変換部を利用したコンテンツの配信を前記第1の機器とは異なる他の機器に譲る旨の応答を受信すると、前記コンテンツ変換部で変換したコンテンツの前記第1の機器への配信を停止し、前記コンテンツ変換部で変換したコンテンツの前記第2の機器への配信を開始することを特徴とする配信装置。請求項1~4の配信装置であって、前記コンテンツの配信に関するメッセージには、前記配信要求において要求された処理とは異なる処理である代替案の表示を示すオブジェクトが含まれることを特徴とする配信装置。請求項5の配信装置であって、前記第1の機器のユーザにより前記代替案の表示を示すオブジェクトが選択されると、前記第1の機器へ前記配信要求において要求された処理とは異なる処理の候補に関する情報を送信することを特徴とする配信装置。コンテンツを受信する受信部と、記録媒体にコンテンツを記録し、記録媒体からコンテンツを再生する記録再生部と、コンテンツを変換するコンテンツ変換部と、ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、前記コンテンツ変換部で変換したコンテンツを他の機器に配信している際に、前記受信部で受信し前記コンテンツ変換部で変換したコンテンツの前記記録媒体への記録を開始する場合、前記他の機器にコンテンツの配信に関するメッセージを送信することを特徴とする配信装置。請求項7の配信装置であって、前記コンテンツの配信に関するメッセージは、前記他の機器へのコンテンツの配信の停止を通知するメッセージであることを特徴とする配信装置。請求項7または8の配信装置であって、前記メッセージには、前記コンテンツの記録媒体への記録の予約を行ったユーザを示す情報が含まれることを特徴とする配信装置。コンテンツを受信する受信部と、記録媒体にコンテンツを記録し、記録媒体からコンテンツを再生する記録再生部と、コンテンツを変換するコンテンツ変換部と、ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、前記受信部で受信し、前記コンテンツ変換部で変換したコンテンツを前記記録媒体に記録している際に、他の機器から前記コンテンツ変換部で変換したコンテンツの配信要求を受けると、前記記録媒体へのコンテンツの記録を設定したユーザにコンテンツの記録に関するメッセージを送信することを特徴とする配信装置。請求項10の配信装置であって、前記コンテンツの記録に関するメッセージは、前記コンテンツ変換部を利用したコンテンツの記録を停止して前記他の機器に前記コンテンツ変換部で変換したコンテンツの配信を開始することを許可するか否かを問い合わせるメッセージであることを特徴とする配信装置。請求項11の配信装置であって、前記メッセージには、前記コンテンツの配信要求を行った機器を示す情報が含まれることを特徴とする配信装置。請求項11または12の配信装置であって、前記ユーザから前記メッセージに対して前記コンテンツ変換部を利用したコンテンツの配信を許可する旨の応答を受信すると、前記コンテンツ変換部で変換したコンテンツの前記他の機器への配信を開始することを特徴とする配信装置。コンテンツを配信する装置において、クライアント外部端末が複数存在していると、ある外部端末の要求を処理しているときに、別の外部端末からの処理要求を実行できない場合がある。特許文献1では、クライアントから要求された処理のリソースが使用不可能な場合については考慮されていない。また、特許文献2においては、チューナ以外のリソースに関する記載は無い。上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、記録媒体に記録されたコンテンツを再生する記録再生部と、記録再生部で再生されたコンテンツを変換するコンテンツ変換部と、ネットワークを介して他の機器と情報の送受信を行う通信部とを有し、コンテンツ変換部で変換したコンテンツを第1の機器に配信している際に第1の機器とは異なる第2の機器からコンテンツ変換部で変換したコンテンツの配信要求を受けると、第1の機器へコンテンツの配信に関するメッセージを送信することを特徴とする。上記手段によれば、より効率的にコンテンツを配信することが可能となる。以下、本発明に好適な実施形態の例実施例を説明する。但し、本発明は本実施例に限定されない。本実施例は、主には配信装置について説明してあり、配信装置での実施に好適であるが、配信装置以外への適用を妨げるものではない。また、実施例の構成すべてが採用される必要はなく取捨選択可能である。<配信システム>図1は本実施例の配信システム構成例である。1はコンテンツを他の機器に配信する配信装置、2および3は配信されるコンテンツを受信し表示などの処理を行う外部端末、4は前記配信装置および前記外部端末と信号を送受信する通信中継装置、であり、図の例では配信装置が無線通信を行い、外部端末に対して通信中継装置を経由しまたは直接、コンテンツを配信している例を図示している。コンテンツとは、ここでは映像や音声を含むデジタルコンテンツを示しており、例としては、放送番組を記録した放送コンテンツ、ユーザが作成または撮影したユーザ作成コンテンツ、インターネットなどのネットワークを経由して入手したネットコンテンツ、などがある。配信装置1の機器の例としては、TV、STBSetTopBox、レコーダ、PC、ホームサーバ、ネットワークサーバ、などが挙げられる。ここでは表示部を有する配信装置の例を図示しているが、表示部を有さず、配信装置1が有する出力端子から映像や音声を出力する機器の場合もある。外部端末2および3の機器の例としては、携帯電話、スマートフォン、タブレット端末、モバイル型のPCなどが挙げられる。またそれぞれ、配信装置と外部端末の機器の例に挙げたものは、配信装置と外部端末の両方の機能を有する場合や、配信装置の例に挙げた機器が外部端末となる場合、またはその逆もある。例えばTVが配信装置かつ外部端末になる場合や、スマートフォンが配信装置になる場合、などがある。また配信装置や外部端末を総称して端末とも呼ぶ。通信中継装置4の機器の例としては、家庭内でのLANルータ、家庭外での携帯電話の中継局、その他家庭内外における無線の中継機器などがある。ここでは無線で通信を行う例を記載しているが、一部もしくは全て、有線での接続となる場合もある。また配信装置と外部端末の通信において、通信中継装置を経由せず直接通信を行う場合もある。各装置の数に付いては図示の例に拠らず、それぞれ複数存在している場合がある。例えば配信装置1台に対して外部端末は3台以上存在し、それぞれの外部端末にコンテンツを配信する場合がある。また図1には示していないが、配信装置1は外部のアンテナなどから信号を受信して処理を行う受信部および前記受信信号を記録する記録再生部を有する場合がある。以下では配信装置が受信部を有する場合の例について説明する。<送受信システム>図2は送受信システムの構成例を示すブロック図である。放送で情報を送受信して記録する場合を例示している。ただし放送に限定されず、通信によるVODVideoOnDemand等であってもよい。5は放送局などの情報提供局に設置される送信装置、6は中継局や放送用衛星などに設置される放送中継装置、7はインターネットなど一般家庭と放送局を繋ぐ公衆回線網、ユーザの宅内などに設置される1は受信部を有する配信装置を表す。送信装置5は、放送中継装置6を介して変調された信号電波を伝送する。図2のような衛星による伝送以外にも例えばケーブルによる伝送、電話線による伝送、地上波放送による伝送、公衆回線網7を介したインターネットなどのネットワーク経由による伝送などを用いることもできる。配信装置1で受信されたこの信号電波は、後に述べるように、復調されて情報信号となった後、必要に応じ記録媒体に記録される。または公衆回線網7を介して伝送する場合には、公衆回線網7に適したプロトコル例えばTCP/IPに準じたデータ形式例えばIPパケット等の形式に変換され、前記データを受信した配信装置1は、復号して情報信号とし、必要に応じ記録するに適した信号となって記録媒体に記録される。またユーザは、配信装置1にディスプレイが内蔵されている場合はこのディスプレイで、内蔵されていない場合には配信装置1と図示しないディスプレイとを接続して情報信号が示す映像音声を視聴することができる。<送信装置>図3は、図2の送受信システムのうち、送信装置5の構成例を示すブロック図である。11はソース発生部、12はMPEG2、或いはH.264方式等で圧縮を行い、番組情報などを付加するエンコード部、13はスクランブル部、14は変調部、15は送信アンテナ、16は管理情報付与部である。カメラ、記録再生装置などから成るソース発生部11で発生した映像音声などの情報は、より少ない占有帯域で伝送できるよう、エンコード部12でデータ量の圧縮が施される。必要に応じてスクランブル部13で、特定の視聴者には視聴可能となるように伝送暗号化される。変調部14でOFDM、TC8PSK、QPSK、多値QAMなど伝送するに適した信号となるよう変調された後、送信アンテナ15から、中継装置6に向けて電波として送信される。このとき、管理情報付与部16では、ソース発生部11で作成されたコンテンツの属性などの番組情報が付与される。なお、一つの電波には複数の情報が、時分割、スペクトル拡散などの方法で多重されることが多い。簡単のため図3には記していないが、この場合、ソース発生部11とエンコード部12の系統が複数個あり、エンコード部12とスクランブル部13との間、または/およびエンコード部12と暗号化部17との間に、複数の情報を多重するマルチプレクス部多重化部が置かれる。また、公衆回線網7を経由して送信する信号についても同様に、エンコード部12で作成された信号が必要に応じて暗号化部17で、特定の視聴者には視聴可能となるように暗号化される。通信路符号化部18において公衆回線網7で伝送するに適した信号となるよう符号化された後、ネットワークI/FInterface部19から、公衆回線網7に向けて送信される。<配信装置>図4は、図1の配信システムのうち、配信装置1の構成例を示す図である。21は装置全体を制御する制御部たとえばCPU:CentralProcessingUnitである。22は制御部21と配信装置内各部を接続し、制御指示およびデータを送受信するための汎用バスである。23は無線衛星、地上、ケーブルなどの放送伝送網を介して送信装置5から送信された放送信号を受信し、特定の周波数を選局し復調、誤り訂正処理、などを行い、MPEG2-TransportStream以下、TSなどの多重化パケットを出力する放送受信部である。24はスクランブル部13によるスクランブルを復号するデスクランブラである。25はLANやインターネットなどのネットワークを介したデジタルコンテンツ等の情報の送信、受信を行う通信部である。26は配信装置4に内蔵または接続されている記録媒体HDDHardDiskDriveやフラッシュメモリ等、またはリムーバブルな記録媒体HDD、ディスク型記録媒体、フラッシュメモリ等である。27は記録媒体26への信号の記録や記録媒体26からの信号の再生を行う記録再生部である。28は入力された信号に対して、必要に応じてコンテンツ変換例えば後述するトランスコード、映像音声信号の選択抽出、映像補正、シーンカット、クリッピング、その他映像や音声の加工、などを行い、信号を出力するコンテンツ変換部である。29はMPEG2-TSなどの形式に多重化されている信号を、映像ESElementaryStream、音声ES、番組情報などの信号に分離する多重分離部である。ESとは、圧縮符号化された画像音声データのそれぞれのことである。30は映像ESを映像信号に復号するなど、入力映像信号に応じて適した形式で映像を処理し出力する映像復号部である。31は音声ESを音声信号に復号するなど、入力音声信号に応じて適した形式で音声を処理し出力する音声復号部である。32は、映像復号部30で復号された映像信号を所定のフォーマットに変換する処理や、制御部21が作成したOSDOnScreenDisplayなどの表示を映像信号に重畳する処理などを行い、処理後の映像信号を表示部47または/および外部入出力処理部46に出力する映像処理部である。33は入力された音声信号に対して音響効果や重畳などの加工処理を行い、処理後の音声信号をスピーカ48または/および外部入出力処理部46に出力する音声処理部である。34はユーザ操作入力部45からの操作入力例えばIRInfraredRadiation信号を発信するリモートコントローラーからのキーコード、タッチパネルの接触情報座標、または撮像素子カメラや音声入力装置マイクなどのセンサーからの入力信号、を受信し、前記操作入力を解釈し操作情報とし、制御部21などに前記解釈した操作情報を送信する操作入力部である。35は内部にカウンタを有し、また現在の時刻の保持を行うタイマーである。46は外部入出力端子41を経由して外部機器と通信を行い、映像処理部32または/および音声処理部33の間で映像信号および音声信号を定められたフォーマット例えばHDMI登録商標で入出力し、映像や音声の変換や暗復号処理など必要な処理を行う外部入出力処理部である。47は映像復号部30が復号し映像処理部32により処理された映像を表示する表示部である。48は音声復号部31が復号し音声処理部33により処理された音を出力するスピーカである。49は前記多重分離部29で再構成されたTSに対し暗号化等必要な処理を行い外部にTSを出力、または外部から受信したTSを復号化して多重分離部29に対して入力するシリアルインタフェースやIPインタフェースなどの高速デジタルI/Fである。ここで、HDMI及びHigh-DefinitionMultimediaInterfaceはHDMILicensing,LLCの登録商標であり、映像音声信号のデジタルインタフェースの一つである。また、放送受信部23、デスクランブラ24を合わせて受信部とも呼ぶ。また、トランスコードとは、例えばコンテンツのビットレート、解像度、フレームレート、映像や音声の符号化方式、I/Pインタレース/プログレッシブ等の変換例えばコンテンツに含まれる映像信号のフレームの間引きや補間を示す。またデコードを行ってからエンコードを行う変換処理もトランスコードの一例である。トランスコードを行う処理部のことをトランスコーダとも呼ぶ。図中では、各ブロックを接続する信号の流れについて、概略として単一の信号経路のように記載しているが、複数の信号線や時分割多重等によって同時に複数の信号を送受信する場合もある。例えば、多重分離部29と映像復号部30の間は、同時に複数の映像信号が送信可能であり、映像復号部で複数の映像ESを復号化し、映像の2画面表示や録画と視聴の同時復号などの処理も可能である。また図中の信号の流れに記載した以外でも、汎用バス22および制御部21、または図に記載していない一時記憶領域メモリを介したデータの送受信が可能である。例えば、制御部21で作成したOSDの情報を汎用バス22を介して映像処理部32に送信することも可能である。また、映像処理部32で作成した映像および音声処理部33で作成した音声を、ネットワークに出力するために通信部25に送信する場合や、通信部25が受信した映像/音声データを直接映像処理部32や音声処理部33に出力する場合も、汎用バス22や図に記載していない一時記憶領域メモリ等を介したデータの送受信が可能である。図4の配信装置には記録媒体26が一つのみ搭載される例が開示されているが、複数の種類の記録媒体を搭載したり、記録媒体が着脱可能リムーバブルである場合はリムーバブル記録媒体を接続するインタフェースのみを搭載したりすることも可能である。また、内蔵の記録媒体と、リムーバブル記録媒体を接続可能なインタフェースとを備えるように構成してもよい。それら記録媒体が複数ある場合、記録再生部27は複数の記録媒体と同時に信号の送受信を行う場合がある。また、記録媒体26は、記録媒体と配信装置内部の接続バスの帯域や、記録媒体における処理速度の上限などにより、同時処理可能な入出力信号について制限される場合がある。また、各部は図中では独立した構成で記載されているが、別々のハードウェアにて構成されている必要は無く、同一のハードウェアにて構成することも可能である。例えば、映像復号部30と音声復号部31は同一のハードウェア上で実装されることにより、映像と音声のタイミングの制御が容易になる。また、制御部21は、CPUなどの単一のハードウェアで実施されるだけでなく、独立した制御部以下周辺制御部が連携をして同様の機能を実現することも可能である。例えば、記録再生部27の制御を行う周辺制御部として記録再生制御部を配置し、制御部21と記録再生制御部とが連携することで、制御部21の処理負荷を低減させることも可能である。汎用バス22についても、特に単一のバスである必要は無く、複数のバスを連結して実現する構成でも良い。その場合はそれぞれのバスの負荷が低減し、特定のバスの通信が別のバスの通信に影響を与えないが、バス間の通信が追加で必要になる。リソースとは、特定の処理に用いる資源を表し、配信装置1が有するリソースとしては、放送受信部23が有するチューナ、コンテンツ変換部28、記録媒体26などに保管されているコンテンツを再生、配信するためのライセンス例えば鍵情報や契約情報、前記記録媒体が同時に処理可能なコンテンツの数、などがある。コンテンツ変換部28については、内部の構成により例えばトランスコーダ、デコーダ、エンコーダ、などがさらに詳細なリソースとなる。制御部21は、データの保持や演算の高速化のために、図示していないメモリを管理している。後述するテーブルのデータについては、主に制御部21が管理し前記メモリに保持している。なお、配信装置は必ずしも図4に示す構成要件全てを備える必要は無く、配信装置が行う処理に応じて必要な構成要件のみを備えるようにしてもよい。<ユーザインターフェース>ユーザに情報を提示して、その情報に対するユーザの応答を受信するユーザインターフェースの例について説明する。ユーザに情報を提示する方法としては、例えば制御部21が文字や図形、映像を含む情報以下、メッセージを作成し、映像処理部32に対して映像として出力するように制御する方法がある。前記メッセージには音声例えば効果音や説明音声を含む場合があり、その場合には音声処理部33に対して音声を出力するように制御する。そして前記メッセージには、ユーザの応答を確認するオブジェクト以下、ユーザ応答確認オブジェクトを含む場合がある。ユーザ応答確認オブジェクトの例としては、例えば図8の806のような映像上のボタン、またはスライダ、テキストボックス、選択リスト、などがある。ユーザ応答確認オブジェクトが表示されている状態で、ユーザは操作機器たとえばリモコン、タッチパネル、などを操作し、前記操作機器はユーザ操作入力部45に対して操作情報例えば、リモコンのカーソル押下、タッチパネルの接触座標を送信し、操作入力部34が操作情報を取得する。操作情報を操作入力部34が制御部21に通知することにより、制御部21はどのような出力に対して、ユーザがどのような操作情報を返したか応答動作を知ることが可能になる。図8の場合を例に挙げると、画面にOK、NGというボタンが図のように配置され、現在はOKがハイライト表示されている画面を制御部21が出力しているとする。この状態で、ユーザがリモコンの決定ボタンを押下した場合、ユーザの応答はOKであると確認できる。また、ユーザがリモコンのカーソルボタンの右を押下してから決定ボタンを押下した場合、ユーザの応答はNGであると判定できる。このようにして装置の出力に対するユーザの応答動作を確認する。またユーザの操作入力およびユーザへの情報通知の方法としては、ネットワークを経由した方法もある。ユーザの操作機器がネットワーク等に接続されている場合、前記操作機器がネットワークを介して通信部25に対して予め定められたコマンドを送信することにより、ユーザの操作内容を配信装置1に伝えることが可能になる。また、操作機器に対して、通信部25からネットワークを介して予め定められたコマンドを送信することにより、ユーザに対して情報を通知することも可能となる。<外部端末>図4は、図1のシステムのうち、外部端末2および3の構成例も示す。ただし、例えば外部端末においては携行を容易化するために、機能を削減して端末の重量を軽量化する場合などがある。例えば放送コンテンツを受信する機能が不要であれば、放送受信部23やデスクランブラ24は不要となる。また、コンテンツ変換部28を有さない場合などがある。そのような場合に、必要な機能例えば放送受信機能、コンテンツ変換機能を配信装置が代替することにより、外部端末使用時のユーザの利便性を高めることが可能になる。<コンテンツ配信時の機器間シーケンス>ここでは配信装置から外部端末に対してコンテンツを配信する場合の機器間シーケンスについて説明する。図6は、配信処理を行う際の、配信装置1と外部端末2の機器間シーケンス図である。ここではユーザが外部端末2を操作し、配信装置1から外部端末2に対してコンテンツを配信させる際の動作を例に説明する。まず初めに、外部端末2は通信部を介してネットワーク例えば家庭内LAN上の配信装置を検索するS601。具体的には、例えばUPnPで用いられるSSDPSimpleServiceDiscoverProtocolなどのプロトコルを用いて、メッセージをネットワーク上にマルチキャストするなどの方法がある。上記の検索に対して、配信装置1は応答のメッセージを返すS602。前記メッセージには配信装置1の位置情報例えばIPアドレスが含まれている。このようにして外部端末2はネットワーク上に存在する配信装置1の位置情報を取得する。次に、外部端末2は配信装置1に対して前記位置情報を基に通信を行い、機器の情報を要求しS603、配信装置1は機器情報を返すS603。これにより外部端末2は配信装置1がどのような機器例えば配信処理が可能な機器か否かかを把握する。次に外部端末2は、配信装置1に対して、配信装置1のコンテンツのリストコンテンツリストを要求以下、コンテンツリスト要求しS605、配信装置1は前記コンテンツリストを返すS606。コンテンツリストに含まれる情報としては、コンテンツごとのタイトル、ID、フォルダ位置、著作者、URI、サイズ、時間、コピー制御情報、ビットレート、解像度、色ビット、有効期限、記録品質、アーティスト、アクター、ジャンル、日時情報、チャンネル情報CH情報、などがある。ここで、例えば外部端末2は、前記コンテンツリストの情報を、ユーザインターフェースを介してユーザに提示する。一例としては、表示部47などへの提示である。具体的な処理手順は、制御部21が通信部25から前記コンテンツリストを取得してコンテンツリストを含むOSD情報を作成し、映像処理部32に送信する。前記OSD情報を取得した映像処理部32が前記OSD情報を表示部47に出力する。前記コンテンツリストを含むOSD情報の提示を受けたユーザは、例えばタッチパネルなどの操作により、前記ユーザ操作入力端子45を経由し操作入力部34に対してコンテンツ選択の操作を入力する。前記操作入力部34は入力された操作情報を制御部21に送信する。これにより、前記操作情報を受信した制御部21は、ユーザが選択したコンテンツを把握することが可能になる。ユーザが選択したコンテンツについて、外部端末2は前記コンテンツのIDまたはURIなどを指定し、配信装置1に対してコンテンツの配信を要求するS607。この後の説明では、URI指定で配信が要求されるものとして説明する。前記要求を受信した配信装置1は、前記コンテンツを外部端末2に対して配信するS608。具体的な配信処理の内容については後述する。このようにして配信装置1から外部端末2へのコンテンツの配信を行う。上記ステップS601の配信機器検索、S603の機器情報要求、およびS605のコンテンツリスト要求については、すでに外部端末2が配信装置1の情報を把握している場合には実施する必要は無い。その場合には上記S601、S603、S605の処理が不要となり、処理が高速化される。また、ネットワーク上の情報提供サービス例えばディレクトリサービスを使用して、配信装置1に上記情報の問い合わせをせずに、同様の情報を取得することも可能である。その場合には複数の配信装置配信装置1以外の配信装置を含むの情報について、まとめてディレクトリサービスから情報を取得することが可能になる。またここでは配信装置と外部端末が1対1の構成で説明したが、それぞれが複数存在している場合もある。その場合には上記の処理を、複数台の端末間で実施する。<コンテンツ配信時の、配信装置の処理>コンテンツ配信時の配信装置1の処理内容について以下に説明する。まず配信装置1は、記録媒体26に記録されているコンテンツリストを作成する。具体的には、制御部21が、記録再生部27から記録媒体26などに記録するコンテンツの情報を順次取得し、それぞれのコンテンツの情報からコンテンツリストを作成し、それぞれのコンテンツにユニークなURIを割り当てる。その後、通信部25からネットワーク経由で上記コンテンツリスト要求を受信した場合は、制御部21が前記方法で作成したコンテンツリストを返信する。その後、配信装置1が外部端末からURI指定でコンテンツの配信要求を受信した場合、前記要求を受信した通信部25は、前記URIが示すコンテンツの配信処理を、制御部21に対して要求する。前記要求を受信した制御部21は、記録再生部27に対して記録媒体26から前記コンテンツを読み出し、コンテンツ変換部28に出力するように指示する。前記指示を受信した記録再生部27は、記録媒体26から前記URIのコンテンツを読み出し、暗号の復号など必要な処理を行った後に、コンテンツをコンテンツ変換部28に出力する。前記コンテンツを受信したコンテンツ変換部28はトランスコードなど配信に必要なコンテンツ変換処理を行った後に、コンテンツを通信部25に出力する。前記コンテンツが入力された通信部25は、前記コンテンツに対して、ネットワークに出力するために必要な処理例えば通信路暗号化などを行った後に、前記外部端末からの配信要求に対する応答としてコンテンツを出力する。このようにして配信処理を行う。配信時にコンテンツ変換を行う理由としては、配信するコンテンツのビットレートを下げることにより、通信路の負荷を低下させる、受信する端末での処理負荷を低減させる、などのメリットがあるためである。また、受信する端末の画面サイズ縦横の画素数、などや、対応ビットレート、符号化方式に合わせて配信側で変換を行うことにより、受信する端末で負荷の高い画面サイズの変換を行うことなく最適な映像表示を行うことも可能になる。ここではコンテンツリストを記録媒体26に記録しているコンテンツから作成する例を挙げて説明したが、コンテンツリストには、記録媒体26に含まれるコンテンツ以外も記載することが可能である。例えば、ネットワークを経由して前記配信装置1が受信可能なコンテンツ以下、外部コンテンツもコンテンツリストに記載しておき、前記外部コンテンツの配信要求を受信した場合に、ネットワークを経由して前記外部コンテンツを取得して配信を行うことも可能である。記録再生部27における暗号の復号においては、コンテンツによってはライセンスが必要になる場合がある。ライセンスの取得方法については記録媒体26の耐タンパ領域に記録されているライセンス情報を取得、またはネットワークから必要なときに取得、などを行った上で再生や配信の処理を行う。特に配信については再生と別のライセンスを用いる場合もある。このように、配信装置1での配信処理においては、コンテンツ変換部28における処理や、コンテンツのライセンスによる使用の制限がある。そのため、コンテンツ変換部28で同時に処理できるコンテンツの数や、ライセンスの条件状況等により、複数の外部端末への配信が実行できなくなる場合がある。また、配信処理に使用しているリソース例えばトランスコーダ、ライセンス、チューナについては、後述するリソース管理テーブルに、必要な情報例えば使用している端末、ユーザを含めてリソースの使用状況を記録しておき、登録に必要な情報については、適宜外部端末から取得する。<放送受信>放送受信を行う場合の制御手順と信号の流れについて説明する。まず特定チャンネルCHの放送受信を要求するユーザの指示例えばリモコンのCHボタン押下を、操作入力部34から受信した制御部21は、放送受信部23に対しては指定CHの受信制御指定周波数帯への選局、放送信号復調処理、誤り訂正処理等の処理を指示し、TSをデスクランブラ24に出力させる。同様に制御部21は、デスクランブラ24に対して前記TSをデスクランブルし多重分離部29に出力するように制御し、多重分離部29に対しては、入力されたTSの多重分離、および多重分離した映像ESの映像復号部30への出力と、音声ESの音声復号部31への出力、を指示する。また、制御部21は、映像復号部30に対して復号した映像信号を映像処理部32に出力するように制御し、音声復号部31に対して復号した音声信号を音声処理部33に出力するように制御を行う。その後、制御部21は、映像処理部32および音声処理部33に、入力信号に対して必要な処理と出力を行うように制御を行う。このようにして、ユーザが指定したCHの放送を受信し、映像および音声を出力する制御を行う。<放送番組の配信>記録媒体26に記録済みのコンテンツや外部コンテンツ以外に、例えば放送されているコンテンツを配信することも可能である。その場合の処理について下記に示す。まず、コンテンツリストの配信時に、放送信号の種類地デジ、BS、CSとCH番号以下放送CHを含むURIを作成し、コンテンツリストに記載する例えば地デジの8CH、など。放送CHのURIを指定して外部端末が配信要求を行った場合に、配信要求を受信した通信部25は、放送CHの配信を制御部21に対して要求する。要求を受信した制御部21は、前述した放送受信時の処理と同様に、各部が放送信号を受信するように制御し、さらに多重分離部29に対しては、入力されたTSに対して必要な処理例えば番組情報の書き換えなどと、TSをコンテンツ変換部28へ出力するように指示する、さらに制御部21は、コンテンツ変換部28および通信部25に対して、記録媒体からの配信処理と同様にコンテンツを配信するように指示を行う。このようにして放送番組の配信を行う。<放送信号の記録>次に放送信号の記録時の制御と信号の流れについて説明する。特定のCHの記録を行う場合に、制御部21は、前述した放送受信の処理と同様に、放送受信部23に対して特定CHの受信制御を指示し、デスクランブラ24に対して、放送受信部23から受信したTSのデスクランブル、多重分離部29に対してデスクランブラ24からの入力をコンテンツ変換部28に出力するように制御する。また制御部21は、コンテンツ変換部28に対して、入力された信号コンテンツについて必要に応じて前記コンテンツ変換トランスコード等を行い記録再生部27に出力するように指示を行う。次に制御部21は、記録再生部27に対して、入力される信号コンテンツについて、暗号化などの必要な処理を行い、また記録再生時に必要な付加情報記録CHの番組情報、ビットレート等のコンテンツ情報の作成、また管理データ記録コンテンツのID、記録媒体26上の記録位置、記録形式、暗号化情報などの記録を行った後に、コンテンツ、付加情報、管理データを記録媒体26へ書き込む処理を行うように指示を行う。このようにして放送信号の記録を行う。放送信号やインターネットで配信されるコンテンツの記録を行うことを録画とも呼ぶ。放送信号の記録方式の種類としては、トランスコード等のコンテンツ変換を行わない記録方式以下TS録画、やトランスコード等のコンテンツ変換を行う記録方式以下コンテンツ変換録画、がある。<予約録画>ユーザが予約録画の登録を行う方法、そして登録された予約録画が実行される際の制御について説明する。まずユーザが予約録画を登録する例について説明する。ユーザは例えば番組表や予約メニュー表示などを確認しながら、予約したい番組を決定する操作を行う。ユーザの操作情報が操作入力部34を介して入力されることにより、予約録画の対象となる番組がユーザにより指定される。制御部21は、番組の放送スケジュール例えば、放送CH、開始時刻、放送期間等の情報を番組情報等から取得する。その後、番組開始時刻の一定時間前予約動作開始時刻:録画の準備が可能な時間だけ前に、制御部21に対して予約録画実行の通知が行われるようにタイマー34にアラームを設定し、管理のために予約登録データとして記録する。このようにして予約の登録を行う。予約録画の実行時の制御を以下に説明する。予約動作開始時刻が到来し、タイマー34から前記アラームを受信した制御部21は、予約登録データを読み出して必要な動作を開始する。記録準備動作として、記録媒体26の準備例えばHDDのスピンアップ、記録媒体26の取付け、空き容量確保などの準備指示、その他ユーザに対して予約録画が開始される旨の通知、などを実施した後に、放送信号の記録に記載の方法で録画を開始する。このようにして予約録画を実行する。ユーザによる予約登録の方法としては、ユーザによる番組の指定以外にも、放送スケジュールを直接操作入力部から入力する、または別の機器からネットワークを経由して、配信装置1に対して放送スケジュールを送信する場合もある。その場合も、通信部25が放送スケジュールを制御部21に通知し、制御部21が放送スケジュールに応じて前述した予約登録の動作を行うことにより、予約を登録することが可能となる。予約登録を行ったユーザを何らかの方法例えば端末操作時のユーザ認証、予約録画登録時にユーザインターフェースの選択肢によるユーザ選択、などで判定し、予約登録データにユーザ情報を登録しておくと、以後のリソース使用ユーザの提示を行う場合や、優先度の判定を行う場合などにユーザの情報の提示や、ユーザを判定して処理を行うことが可能になる。また、録画予約については、ユーザにより登録されるものだけではなく、例えばキーワードに一致する番組を自動的に録画するなど、装置により自動的に録画されるものもある。その場合の予約登録の処理は、録画する番組をユーザが指定した場合の処理と同様である。また、その場合の登録ユーザ名については、システムまたは自動録画として扱い後述の通り判定することにより、ユーザが登録した予約と区別を行う判定が可能になる。予約登録の際には、前記記録方式TS録画またはコンテンツ変換録画をユーザが指定し、ユーザが望む記録方式を予約登録データに設定する。自動録画の際にも予め、前記記録方式を選択しておく、または記録媒体の残量などを考慮し、配信装置1が自動的に記録方式を選択しておくといった動作が行われる。<リソース競合時の動作>次に配信に用いるリソースが競合している場合の配信装置と外部端末の動作について、機器間シーケンスを図7に示す。リソースの競合とは、同一のリソースに対して複数の使用要求があり、リソースが不足している状態のことを示す。図7の例では、配信装置1から外部端末2に対する配信以後配信Aが行われているときに、外部端末3から配信装置1に対して、前記配信Aが使用しているリソースを使用する配信要求を行った場合の例について示している。以下図7の機器間シーケンスを用いて説明を行う。まず、外部端末2が配信装置1からコンテンツの配信を受ける動作については、前記のコンテンツの配信時機器間シーケンスの場合と同様であるS701。次に配信A実行中に、配信装置1が外部端末3からも同様に配信以下、配信Bの要求を受信するS703。以下、このように配信装置1のリソースを使用する処理要求をリソース使用処理要求と呼ぶ。この場合に、配信装置1は外部端末3に対して配信が可能か、リソース使用処理要求の内容と処理に必要なリソースを判断し、その後リソースについて、後述のリソース管理テーブルにより使用状況などを確認する。確認の結果、現在の例では配信Aがリソース例えばトランスコーダを使用しているため、リソースが一つしか無い場合などには、配信装置1は外部端末3に対して、現在配信ができない旨の通知処理待ち通知をするS704。この際に送信する情報については後述する。情報を送信後、配信装置1は必要に応じて配信Bに必要なリソースを獲得するために、外部端末2に対してリソース解放要求を行うS705。この要求に際しては、後述するメッセージ表示に必要な情報なども送信する。要求を受信した外部端末2は、ユーザに対して、図8に示すようなメッセージ以下、リソース解放要求メッセージ805を表示部47などに表示する。メッセージの詳しい内容については後述する。メッセージには、ユーザ応答確認オブジェクト806が含まれており、ユーザはオブジェクトの提示に対して、応答動作を行う。これにより上記メッセージに対するユーザの応答OK、NG、それ以外の動作が確認可能となる。ユーザ応答確認オブジェクトの確認結果を受信した外部端末は、確認結果を配信装置1に送信するS706。確認結果がOKであった場合図のaltの応答OK、S707からS709までのステップが実行される。まず配信装置1は必要に応じてリソースの解放に必要な処理例えば配信Aの中止処理を行いS707、リソースの確保ができた後に、外部端末3に対して、先ほどの配信要求のOK応答を返すS708。その後必要に応じて外部端末3から配信要求を受けるなど通信を行った後、外部端末3に対して、要求コンテンツの配信処理を行うS709。確認結果がNGであった場合図のaltの応答NG、S710が実行され、配信装置1は外部端末3に対して配信NGの応答を返すS710。この際には必要に応じて、後述する図16のように配信が不可能な理由を提示するメッセージが外部端末3において表示される。このように、配信装置1で使用中のリソースに対して配信要求を受けた場合、リソース解放の要求をリソース使用中の外部端末に対して行った後に、要求の応答に応じた処理を行う。これにより、現在リソースが使用中で配信などの動作ができない場合にも、リソース使用者の許可を受けた場合には、現在のリソースの使用を停止し、要求された処理を行うことが可能になる。図8のリソース解放要求メッセージの例では、800は配信装置または外部端末の有する表示部47または外部入出力端子41を経由して出力される映像出力全体。表示される情報としては、端末名801、ユーザ名802、要求リソース803、できなくなる操作804、などを記載している。それぞれの意味は、端末名は競合するリソースを使用する処理を要求している他の端末、ユーザ名は競合するリソースを要求するユーザ、要求リソースは競合しているリソース、できなくなる操作は、リソースを譲ることにより当該端末図7における外部端末2でできなくなる処理を表している。リソース解放要求メッセージの表示に必要な情報は、配信装置1が配信要求を外部端末3から受信する際に受信するか、または必要に応じて配信装置1が外部端末3に要求を行って取得した情報と、配信装置1が保持している情報とを合わせて外部端末2に通知する。これらの情報をリソース解放要求メッセージとして表示し、リソースを使用しているユーザにリソース解放要求への応答を行わせることにより、リソースを使用しているユーザが、どの端末およびユーザからリソース解放要求を受けているかを確認することが可能となり、相手や状況に応じたリソースの有効活用が可能になる。また、必要な情報を必要な場合にのみ取得するようにすることにより、通信時のデータ量を削減可能となる。ここで、ユーザ応答確認オブジェクトとして、二度と表示しないという選択肢がある。ユーザがこの選択肢を選択した場合は、後述するリソースロックの状態をするに変更する。リソースロックの判定処理については後述する。なお、二度と表示しないという選択肢は一例で、他の文言を使用してもよい。またS704にて前記処理待ち通知を受け、外部端末3にて表示されるメッセージ以下処理待ちメッセージの例を図9示す。端末名901は競合するリソースを現在使用している端末名、ユーザ名902は競合するリソースを現在使用しているユーザ名、要求リソース903は要求しているリソース、相手の操作904は、現在外部端末2が競合するリソースを使用して行っている処理の内容を表示している。このようにして、リソースを使用した処理を要求しているユーザが、リソースを使用しているユーザと、端末、その操作内容を知ることが可能になる。処理待ちメッセージ表示に必要な情報についても上記リソース解放要求メッセージの例と同様に、配信装置1が配信要求を外部端末2から受信する際に同時に受信するか、または必要に応じて配信装置1が外部端末2に要求を行って取得した情報と、配信装置1が保持している情報とを合わせて外部端末3に通知する。上記例においては、それぞれのメッセージ表示について、それぞれの機器が作成したメッセージを表示するように記載しているが、機器が作成したメッセージの表示のみでなく、相互の通信による表示などの出力を行っても良い。例えば、処理待ちメッセージ905のユーザ応答確認オブジェクト906に表示されているチャットに移行をユーザが選択した場合、またはリソース解放要求メッセージ805に同様の表示を行い、それをユーザが選択した場合、などには、それぞれの外部端末のユーザが作成したテキスト情報や、それぞれの外部端末が撮影した映像情報および/または音声情報、をユーザが操作入力部34に入力し、その情報を外部端末間で送受信を行い表示するなどにより、リソース競合をしているユーザ間または端末間での相互情報通信状態チャットモードに移行しても良い。これにより、それぞれのユーザが、リソース競合時にメッセージや機器情報以外の情報を送受信することが可能になる。また前記の通りユーザ応答確認オブジェクトにチャットに移行のオブジェクトを配置することにより、リソースが競合している場合に容易にチャットモードに移行し、リソースの使用について交渉や話し合いをすることが可能となる。上記チャットの経路としては、配信装置1をそれぞれの端末のサーバとして情報を経由させる方法と、外部端末同士で相互の位置情報例えばIPアドレスを交換し、直接情報を送受信する方法の両方がある。また上記チャットモードへの移行は、上記ユーザがチャットに移行を選択した場合以外にも、メッセージ表示時に自動的に移行しても良い。この場合、メッセージの一部に上記外部端末のユーザが作成したテキスト情報や、それぞれの外部端末が撮影した映像情報が表示されることになる。これにより、ユーザが操作を行わない場合にも、リソース競合時に自動的にメッセージや機器情報以外の情報を送受信することが可能になる。リソース解放要求メッセージや処理待ちメッセージについては、配信装置1から外部端末にメッセージ作成に必要な情報のみを送信する方法と、配信装置1がメッセージを含む画像情報を作成して送信する方法との両方がある。配信装置1が画像情報を作成して外部端末に送信する場合は、画像情報が送信されるため、配信装置1および通信路の負荷が高くなるが、外部端末側での処理が簡略化され、また外部端末側では情報の内容を解釈せず画像情報を表示するだけであり、汎用性の高い処理が可能になるなどのメリットがある。図7のS707の処理については必ずしも実行する必要は無く、例えば前記リソース解放要求S705を受信した時点で、外部端末2で配信停止に関する処理を実行しても良い。そのようにすることにより、配信装置1と外部端末2の通信量を削減可能となる。またS704およびS705の処理順序については交換可能である。また、S705において、リソースの解放要求を行う外部端末は一つとは限らない。例えば前記配信要求S703を配信装置1が受信した場合に、前記要求された配信を実行するためには、トランスコーダ、ライセンス、記録媒体の同時処理数、の3つのリソースが必要な場合がある。その場合には、3つのリソースそれぞれの使用状況を確認し、前記リソースを使用しているそれぞれの端末に対して、リソース解放要求を行う必要がある。この場合、S706における確認結果は、当該3つのリソースを利用している全ての外部端末の確認結果がOKの場合に、応答OKとして処理を進める。このようにすることで、複数のリソースを使用する処理であっても、上記の場合と同様に処理を進めることが可能となる。また別の例として、処理に用いるリソースについて、リソースを使用しているいずれかの端末ユーザが解放すれば使用可能な場合もある。例えば、S703の配信要求を実行するためにトランスコーダを使用する必要があり、外部端末4と外部端末5への配信に、それぞれトランスコーダを使用している場合、外部端末4と外部端末5のいずれかがリソースの解放を行えば、配信が可能となる。このような場合には、前記リソースを使用している全ての端末にリソース解放要求を行い、いずれかの端末から解放OKを受信した場合に、前記応答OKの場合の処理を実行する。また別の例としては、前記リソースを使用している端末にリソース解放要求を順次実施し、何れかの端末から解放OKを受信した場合に、前記順次実施するリソース解放要求を終了して、応答OKの場合の処理を実行する。このようにすることにより、各リソースの同時処理可能数が制限されている場合に、それぞれ排他を行いながら処理を行うことが可能となる。<リソース管理テーブル>配信装置1でリソースを管理するために用いる、リソース管理テーブルの例を図10に示す。ここではリソースの例として、トランスコーダ、ライセンスが存在し、リソースごとに下記記載の項目について管理している例を示している。項目の内容について下記それぞれ説明する。使用状況1002は、リソースが現在処理に使用されているか否かを表している。使用操作1003は、リソースを使用している動作の内容について示している。図10の例においては、例えばトランスコーダ1は番組Aの配信に使用されており、トランスコーダ2は番組Bの録画に使用されている例を示している。使用端末1004は、リソースを使用している端末を示している。図10の例では、トランスコーダ1の配信は携帯端末1が使用していることを表している。これにより、トランスコーダ1を他の処理で使用したい場合には、携帯端末1に対して、リソース解放の要求を行えば良いとわかる。使用者1005は、リソースを使用しているユーザに関する情報を示している。図10ではトランスコーダ1はお父さんが使用しており、トランスコーダ2はサーバ配信装置1が前記自動録画を行っている例が示されている。外部端末でのリソース使用ユーザの判定方法としては、例えばユーザ認証パスワード認証、生体認証などがあり、その情報を配信装置1が外部端末から取得し、リソース管理テーブルに登録する。使用予定時間1006は、リソースの使用予定時間を示しており、例えば配信動作であればコンテンツの残り再生時間、録画動作であれば録画番組の終了予定時刻までの時間、記録媒体に記録されているコンテンツのトランスコード動作であれば終了時間例えばコンテンツの長さが30分の番組を、6倍速トランスコードした場合には5分などがある。配信動作については、コンテンツの再生速度は一定ではないため、再生速度に応じて値は変化する。リソースロック1007とは、上記説明のリソースロックをするにした場合に有効となるフラグである。優先度1008は前記リソース使用の優先度である。リソースロックと優先度による具体的な判定方法は後述する。以上のようにリソースの使用状況を管理する。上記の項目については一例であり、不要な項目を削除する場合や、別の値を使用する場合があっても構わない。例えば、リソースロックの項目の代わりに優先度を使用する場合もある。具体的な方法は後述する。項目を削減することにより、管理テーブルのデータ量の削減や、判定処理の容易化が可能となる。制御部21は、使用しているリソースの状況が変化した場合には、前記リソース管理テーブルの情報を適宜更新する。例えば、リソースの使用状況が変化し、リソースを使用する処理が終了した場合には、リソースの使用状況を未使用とする。リソースの使用状況を未使用とすることを、リソースの解放とも言う。また更新に必要な情報については、通信部25を介して外部端末から情報を適宜取得する。リソースについて、図10のリソース管理テーブルの例においては、トランスコーダが2つあるような表記としているが、実際にトランスコーダが2つ存在していなくても良い。例えば、トランスコーダの処理性能処理速度や記憶領域のサイズ等により、同時に実行できるトランスコード処理が2つまでの場合には、図に示すようにトランスコーダ1とトランスコーダ2という管理をすると、処理が容易になる。このようにリソースの数は処理可能な要求の個数で管理することが望ましい。ただし、トランスコーダによっては、ある処理例えばMPEG-2のトランスコードは3つ同時に処理可能だが、ある処理たとえばH.264のトランスコードは同時に2つまで、という制限がある場合がある。このような場合については、トランスコーダの数によって管理せず、それぞれのトランスコーダがどういった処理を同時に処理が可能か、現在行っている処理は何か、特定の処理を行いたい場合にどの処理を停止してリソースを解放すれば良いかを別で管理する必要がある。ここで使用者と使用端末の関連については、処理によっては例えば配信処理リソースの使用中は変化が起きないが、録画処理など、実行時に外部端末を利用せずにリソースを使用している場合には、録画を行っている使用者の使用端末が無い、または使用端末が変更になるという場合がある。その場合には、使用端末のデータは、前記ユーザが現在使用している端末を登録するように更新する、または使用端末の部分にデータを登録せず、制御部21などで管理する別のテーブル以下端末使用者管理テーブルで使用者と使用端末の関連を管理する、といった方法がある。<リソース競合時の配信装置の動作>配信装置1がリソースを必要とする処理を行う場合に、制御部21で実行される処理フロー例について、図11を用いて説明する。制御部21は、処理要求を受信した場合などに、現在実行する処理に必要なリソースを確認するS1101。必要なリソースとは例えば配信時のトランスコーダなどである。そこで、必要なリソースの使用状況を、リソース管理テーブルなどから判断する。リソースの使用状況を確認した結果、必要なリソースが未使用の場合はS1102のyes、リソースを必要とする処理を開始するS1103。必要なリソースがすでに使用されている場合S1102のnoには、リソースを使用している外部端末または配信装置以下、リソース使用機器をリソース管理テーブルから判定し、リソース使用機器に対してリソースの解放要求を行うS1104。解放要求を行った後に、制御部21はリソース使用機器からの応答を待つS1105。この際に、必要に応じて処理要求を行った外部端末に対して、処理待ち通知を送信する。この通知により、外部端末は処理待ちメッセージを表示する。リソース使用機器からの応答を受信後、応答の内容がリソース解放NGであった場合S1106のno、リソースを必要とする処理の要求を行っている端末に対して、現在リソースの使用が不可能な旨を通知するS1107。応答の内容が、リソース解放OKであった場合S1106のyesは、リソースの解放処理を行うS1108。リソース解放処理の内容としては、リソースを使用する処理を停止し、内部のリソース管理テーブルの内容を、前記リソースについて使用中から未使用に変える処理を行う場合や、前記リソース使用機器に対して、別途リソースの解放処理を要求する場合がある。リソース解放処理が終了した後に、前記リソースを使用する処理を実行するS1103。このようにして、受信した配信要求についてリソースの使用状況が競合している場合に、リソースを現在使用している端末の応答を確認し、処理を実行することが可能となる。上記リソースを使用する処理としては、配信、録画、視聴、再生などが挙げられる。また、S1103などにて、リソースを使用する処理を新たに開始した場合には、適宜リソース管理テーブルに必要な情報を登録しておく。S1105の、処理待ち通知送信時に、リソース管理テーブルの情報を適宜送信することにより、外部端末を使用しているユーザが必要な情報を取得することが可能になる。例えば、使用操作使用端末使用者を送信することにより、それぞれどのような処理に、どの端末で、誰が、リソースを使用しているかをユーザが知ることが可能になる。また、使用予定時間が提示されることにより、いつ頃にリソースが解放される予定かを知ることが可能になる。またS1102において、リソース管理テーブルの優先度を用いた判定を行っても良い。具体的には、優先度の値に応じて、例えば低優先度の処理が高優先度の処理のリソースを要求して競合する状況においては、確認を行わずに無条件で低優先度の処理側のリソース使用をNGと判定する、またはその逆に、高優先度の処理が低優先度の処理のリソースを使用する状況においては、確認を行わずに無条件で高優先度側のリソース使用をOKと判定する、または同一優先度のときにのみリソース解放確認を行う、といった処理が可能となる。処理の判定方法としては、例えばS1102において、重複するリソースの低優先度の処理を解放し、S1103の処理を行う、または低優先度の処理要求を却下して処理を終了するなどである。優先度の決定の方法としては、ユーザが明示的に設定を行う、またはユーザに対して予め優先度を割り当てておく例えばユーザ1は優先度3、ユーザ2は優先度1など、またはリソースを使用する端末ごとに優先度を割り当てておく例えば配信装置1は優先度2、外部端末2は優先度1など、または処理ごとに優先度を割り当てる例えば配信優先度1、録画は優先度3、視聴は優先度2、など、または宅外からの要求を優先宅外からの処理は優先度3、宅内からの処理は優先度1といった方法がある。このように優先度を割り当てて判定処理を行うことにより、不要なリソース解放確認を行わずに、それぞれ優先したい処理にリソースを自動的に割り当てることが可能となる。また同じくS1102において、リソースロックを用いた判定を行っても良い。処理で必要となるリソースについて、前述または後述の処理によりリソースロックがするになっている場合は、上記優先度判定の場合と同様に、確認を行わずに無条件でリソース使用をNGと判定し、処理要求を却下する。リソースロックがしないになっている場合には、通常通り判定処理を行う。このように処理することにより、重要な処理は優先的にリソースを使用する、または、ユーザがリソースを解放する意図が無い場合に、再度リソース解放要求メッセージが表示されることを防ぐことが可能になる。前記リソースロックについては、リソースロックの項目の代わりに優先度を使用し、リソースロックをするに変更する代わりに、優先度を最高、またはそれ以上とすることによりリソースのロックを実現する方法もある。そのように項目を削減することにより、管理テーブルのデータ量の削減や、判定処理の容易化が可能となる。優先度に関する処理については、上記の例以外にも、処理が遅延しても問題無い処理たとえばスケジュールで実行されるコンテンツ変換。以降、非リアルタイム処理については、スケジュール実行時刻を遅延させ、リアルタイム性の高い処理例えば配信や録画を優先させることが好ましい。そのため、上記の優先度について、リアルタイム性が高い内容を高い優先度、非リアルタイム処理を低い優先度、とすることにより実現可能である。その場合には、リソースが解放されると再度非リアルタイム処理を実行するようにすることが望ましい。そのような場合には、非リアルタイム処理について後述するリソース予約を行うことが有効である。また、例えば配信装置において受信した放送コンテンツのTSをトランスコーダで処理して記録している場合に、そのトランスコーダの使用を希望するリソース解放要求を受信すると、放送コンテンツをTSのまま記録するように切り替え、リソース解放要求の送信元が要求した処理が終了した後に、記録したTSをトランスコーダで処理するように構成してもよい。またリソースロックや優先度の判定については、配信装置1で必ず実施する必要は無く、処理待ち通知やリソース解放通知に上記情報を追加し、外部端末側で判定を実施しても良い。そのようにすることにより、配信装置1での処理が容易になり、また外部端末で値を基に判定を行う処理が可能になる。S1104におけるリソース使用機器の判定方法としては、リソース管理テーブルから判定を行う方法の他に、リソース管理テーブルから登録されている使用者を判定した後に、その使用者が使用している機器を端末使用者管理テーブルから検索し、その機器をリソース使用機器として処理を行うことも可能である。このようにすることにより、例えばユーザが配信装置を使ってリソースの使用を予約し例えば放送コンテンツの録画予約、そのリソースを使用する際にはそのユーザがその配信装置から離れている場合であっても、そのユーザが持ち歩いている他の端末例えば携帯電話、タブレット端末等にメッセージを送信することが可能となり、より確実にリソースを利用しているユーザにリソース解放要求を伝えることが可能となる。<録画開始時の配信停止処理>次に予約等による録画開始時に、現在のリソース使用者に確認を行う例について説明する。制御部21の動作は、図11の例と同様であるが、実行開始のトリガとしては、例えば予約録画開始の一定時間前などとなる。まず予約録画に必要なリソース例えばトランスコーダの確認を行いS1101、前記リソースが使用中であった場合S1102のno、リソース管理テーブルを確認し、リソースを使用している端末にリソース解放要求を行うS1104。この際に、解放要求を受信した端末で表示されるメッセージ例について図12に示す。1204は表示されるメッセージ以下、配信停止確認メッセージ全体を示している。ここで表示される内容の例としては、予約録画の対象である番組の情報1203放送局情報、番組名、CH情報、放送時間など、以下予約録画番組情報、競合しているリソースである要求リソース1202、予約録画を登録しているユーザ名である予約登録ユーザ名1201もしくは自動録画である旨の表示、予約録画が開始される時刻、または/および予約録画が開始されるまでの時間、などがある。これらの情報を外部端末で表示するために、配信装置1はこれらの情報もしくは関連する情報をリソース解放要求と共に、もしくは別途外部端末に送信する。また前記の例と同様に、メッセージにユーザ応答確認オブジェクトも表示し、ユーザの応答を確認する。ユーザ応答確認オブジェクトの例を1205に記載する。ユーザ応答確認オブジェクトのユーザによる応答を受信した後に、外部端末は配信装置1に対して、リソース使用OKかNGかの応答を返す。前記リソース使用の応答を受信した制御部21は、前記応答がリソース使用OKであった場合S1106のyesは、リソースを解放する処理を行いS1108、前記番組の予約録画を開始S1103する。前記応答がNG例えば図のユーザ応答確認オブジェクトの録画を中止するを押下であった場合S1106のno、制御部21は予約録画の実行を中止するなどの処理を行うS1107。このようにして、予約録画の実行時に、競合するリソースを使用している端末に対して必要な情報を提供し、ユーザの応答に応じてその後の動作を決定することが可能になる。ここで、S1105の応答待ちにおいて、一定時間例えば予約録画開始までの時間、または予約準備時間を減算した予約録画開始までの時間、または固定時間5分など経過するまで前記端末からの応答が無かった場合には、自動的にリソース使用OKとしてその後の処理を実行することが好ましい。これはリソースを使用しているユーザがメッセージを確認できる状況に無かった場合に、予約録画が失敗することを防ぐためである。または、リソース管理テーブルのリソースロックや優先度に応じて、リソースの使用可否を判断するようにしてもよい。これにより、ユーザにとって優先度の高い処理に対してリソースを使用することが可能となる。または、現在配信中のコンテンツについて、前記の通りトランスコードを行ってから配信を行っている場合には、すでにトランスコード済みのコンテンツなどトランスコード不要で配信可能なコンテンツがある場合には、そちらを配信する、または配信を受信する側が対応している場合にはTS録画したコンテンツをトランスコードを行わずに配信するように変更することにより配信を継続するようにしてもよい。この場合には切り替え時の再生位置から、視聴を継続できるようにコンテンツを切り替えることが望ましい。次に、ユーザが応答確認オブジェクト1205の代替案の表示を押下した場合に、表示されるメニューの例を図5に示す。このメニューの表示は、配信装置~送信された情報に基づいて表示してもよいし、外部端末が当該外部端末内の情報を用いて表示するように構成してもよい。ユーザ応答確認オブジェクト2006の選択肢に記載したそれぞれの操作ボタン図5の2001、2002、2003、2004、2005をユーザが選択した場合の動作について以下に記載する。録画レートの変更2001をユーザが選択した場合、競合している録画処理のレートについて、例えばトランスコーダを使用しない記録方式TS記録に変更する。配信レートの変更2002をユーザが選択した場合、配信コンテンツについて、例えば上記記載の通りトランスコーダを使用しない配信に変更する。別コンテンツの再生2003をユーザが選択した場合、例えば後述する、現在のリソースで配信可能なコンテンツのリスト、または配信可不可が記載されたコンテンツリストを表示する。機器操作画面の表示2004をユーザが選択した場合、例えば前記録画が開始される機器の操作パネルを操作端末に表示し、録画や予約の操作を行えるようにする。チャットに移行2005をユーザが選択した場合、前述のチャットモードへの移行を行う。このようにしてリソース競合時の代替案を提示し、その操作をユーザが選択可能とすことにより、限られたリソースを有効活用することが可能となる。これら操作ボタンについては、全てを表示する必要は無く、適宜取捨選択しても良い。また対象の動作が行えない場合については、操作ボタンを表示しない、またはグレーアウトオブジェクトをグレーで表示するなどすると、ユーザに理解しやすい表示にすればよい。例としては、異なる配信レートで配信するコンテンツが無い場合に配信レートの変更を表示しない、チャットを実行する対象ユーザがいない場合にチャットに移行をグレーで表示する、などである。1205の代替案の表示を押下した場合に、図5のメニューを表示せずに、上記いずれかの動作について、予め定められた動作を実行する、または別の設定画面で設定した内容に基づいて動作する、というようにしても良い。そのようにすることにより、ユーザの操作を簡略化することが可能となる。また、メッセージの表示例としては、図13に示すような。配信停止までの時間と簡易なユーザ応答確認オブジェクト1301の表示のみの構成としても良い。この場合は配信されているコンテンツを視聴しつつ、リソース競合に関する処理が可能となる。また、1302の詳細を押下することにより、上記図12のようなメッセージを表示する構成にしてもよい。これにより、ユーザの視聴を妨げずに、段階的に情報を提示することが可能になる。ここで時間の単位については、図のように分単位ではなく、秒単位であっても良い。その場合にはより詳細に配信停止までの時間を確認できる。また、1205の代替案の表示のオブジェクトは、図8や図9に示すメッセージに含めることも可能である。この場合、代替案の表示が選択されると、図5これにより、配信装置において配信の要求が重複した場合であっても、代替案を利用して効率よく外部端末にコンテンツを配信することが可能となる。<録画中の配信開始処理>次に、録画などの処理で配信装置1のリソースを使用している場合に、前記リソースを使用する配信要求が行われた場合の配信装置1における制御部21の処理について説明する。上記状況での制御部21の処理フローは、図11の場合と同様である。まず配信処理に必要なリソースを確認しS1101、必要なリソースが使用可能な場合はS1102のyes、リソースを使用した処理を開始するS1103。必要なリソースが使用可能でない場合はS1102のno、そのリソースを使用した録画を登録しているユーザが使用している端末に対してリソースの解放要求を行うS1104。例えば、リソースを使用した録画を登録しているユーザの使用している端末が外部端末2の場合には、外部端末2に図8のようなリソース解放要求メッセージが表示される。以後の動作は前記リソース競合時の動作の場合と同様である。前記リソース解放要求メッセージにおいては、図8の804に記載の通り、録画予約されている番組の情報が記載されている。このようにどの番組の録画が中止されるかの確認をした上で、リソースの可否を検討することが可能となる。前記リソースを使用しているユーザの検索方法としては、まず録画処理を行っているユーザを、前記リソース管理テーブルの使用者や、予約情報から判定し、その後、前記ユーザが使用している端末を、別途端末使用者管理テーブルなどから確認し、前記端末に対して、配信装置1が前記リソース解放要求を送信する。録画処理を行っているユーザが、どの端末を使用しているかの情報が無い場合には、例えば配信処理を行わず、図11のS1105の応答待ちも行わず、S1106においてリソース解放NGと判定し、処理を終了させても良い。その場合には、録画処理を実行しているユーザに対しての確認待ちで不要に待つことが無くなり、さらに許可無く録画を中止させることが無くなる。このような状況においては、リソース要求側に、その状況を通知例えばS1107において、録画処理を使用しているユーザが見つからないため、配信が実行できない旨を通知することが望ましい。これにより、ユーザがなぜ配信ができないかという状況を把握することが可能になる。また逆に、同様の状況において、図11のS1105の応答待ちも行わず、S1106においてリソース解放OKと判定し、録画処理を中止させても良い。この場合には録画処理が予約ユーザ対して許可無く中止される恐れがあるが、一方で配信処理が録画している間常に禁止になる状況を防ぐことが可能になる。このような状況においては、例えば予約録画の履歴に、前記配信処理により録画が中止されたことを記載しておくことが望ましい。これにより、後ほどなぜ予約が中止されたかを把握することが可能となる。ここで、リソースを使用しているユーザと、予約を登録しているユーザが同一の場合、または上記例のように録画処理を行っているユーザが不明の場合に、要求を行った外部端末に表示されるリソース解放要求メッセージの例を図14に示す。メッセージには、録画予約を行ったユーザ、要求しているリソース、録画処理を行っている番組が表示されている。この画面で、ユーザ応答確認オブジェクトでOKを押下された場合には、前記S1106でリソース解放をOKとして判定を行う。このように、現在の録画処理の状況を確認しながら、操作の内容を停止するか否かの判定を行うことが可能になる。図14のユーザ応答確認オブジェクトにおいて、ユーザが代替案の表示を押下した場合の動作は、上記録画開始時の配信停止処理の場合と同様である。<リソース使用時のコンテンツリスト表示>外部端末にて表示されるコンテンツリストの例を図15に示す。ここでは項目として、タイトル時間記録品質記録CH現在配信可利用者端末配信用番組が表示される例を記載している。タイトルとは、コンテンツのタイトルであり、放送記録コンテンツの場合は番組名などになる。時間はコンテンツの再生時間である。記録品質は記録を行った際の映像のビットレートの目安などを示しており、例えば図中のTSはTS録画したコンテンツであることを示しており、SPは標準画質で記録されてことを示している。記録CHは放送記録時の記録した番組の放送CHを示している。現在配信可とは、配信装置1が現在のリソース管理テーブルから判断した状況において、それぞれのコンテンツが配信可能か否かを示しており、○は現在のリソース状況で配信可能、×は現在のリソース状況で配信不可能なことを表している。利用者は、前記リソース状況が配信不可能な場合、そのリソースを誰が使用しているか、つまりどの利用者がリソースを解放した場合に配信が可能になるかを表している。端末は、同じくそのリソースを使用している処理を実行している端末を表している。配信用番組については、例えば配信を行うために、事前にコンテンツに対してトランスコード等の処理を行う、または同様の番組を別経路例えばワンセグ放送、またはネットワーク経由で同様コンテンツを取得で記録する、等の処理が行われたコンテンツの有無を表している。このようにしてユーザに対して、それぞれの番組が配信可能か否か、配信ができない場合にはどのような状況かという情報を提示することが可能になる。また、外部端末の処理としては、現在配信可の情報について判定を行い、配信不可であるコンテンツをリストに表示しないということも可能である。その場合にはユーザが現在配信可能なコンテンツのみを確認することができ、操作が容易になる。また、配信装置から外部端末に対して、配信可能なコンテンツのリストの情報のみを送信するという方法もある。その場合ユーザにとってのメリットは外部端末で処理する場合と同様であるが、機器としても、例えば外部端末については、上記フラグを判断しての表示や非表示の処理が不要となり、また情報を送受信する際のデータ量の削減も可能となる。上記コンテンツリストを表示する際に、現在のリソース状況で配信が不可能なコンテンツが存在する場合などにおいて、前記リソース管理テーブルのデータをそのまま表示することも可能である。例えば配信装置1が外部端末に対してリソース管理テーブルのデータを送信し、外部端末にて前記リソース管理テーブルの情報を表示することにより、ユーザはリソースの使用状況を確認することが可能となる。<リソースの予約>次にリソースの競合の結果、要求した処理が実行できなかった場合などに、ユーザがリソースの予約を行う場合の例を以下に説明する。例えば図7のS710のNGの通知、またはS704の処理待ち通知を受信した場合に、外部端末3にて表示するメッセージの例を図16に示す。メッセージに表示される情報としては主に図9の、端末名ユーザ名使用要求リソースと同様の記載である。ここでは終了予定時刻として、上記使用予定時間と同様の値を記載している。またユーザ応答確認オブジェクト1607に予約するという項目が追加されている。前記ユーザ応答確認オブジェクト1607のユーザの応答が予約するの選択であった場合には、リソース予約テーブルに情報を追加する。リソース予約テーブルの例を図18に示す。1801がテーブル全体である。項目としては、ここでは予約ID1802、予約リソース1803、予約操作1804、使用端末1805、予約者1806、優先度1807、通知方法1808、などがある。予約ID1802は、リソースの予約登録ごとに割り振られるユニークなIDを示す。予約リソース1803は、予約の対象となるリソースを示す。予約操作1804は、予約操作時に行った操作の内容で、予約ID1802が1の例では、番組Aの配信に関してリソースであるトランスコーダ1の予約を行った例を示している。使用端末1805はリソースの予約を行っている端末を示す。予約者1806はリソースを予約した予約者を示す。優先度1807は、リソース予約の優先度を表し、例えば同一リソースに対して予約が重複している場合、優先度が高い予約について先にリソースを割り当てるなどを行う。優先度は予約者や使用端末により決定する場合や、また予約登録順での優先度、といった場合がある。通知方法1808については、リソースが解放されたことを通知する手段の種類について示している。通知方法の例としては、メッセージによる表示、電子メールなどによる通知、または電話通信の着信による通知、などが挙げられる。通知方法の登録手段としては、例えば予約登録時に、ユーザがユーザインターフェースを介して前記通知方法を選択する、またはリソースを予約した機器により、配信装置1が自動的に選択する例えば携帯電話であればメール、メッセージ表示に対応していればメッセージ、など。通知方法1808が予約テーブルに存在しない場合には、例えばネットワークでの固定プロトコルによる通知としても良い。リソースが解放された場合の、制御部21の処理について図19を用いて説明する。リソースが何らかの理由例えば配信停止、録画終了で解放された場合、まず制御部21はリソース予約テーブルを確認するS1901。リソース予約テーブルに対象リソースの予約が存在していない場合S1902のno、リソースの使用状況を未使用にしてS1903処理を終了する。リソース予約テーブルに対象リソースの予約が存在している場合S1902のyes、リソース予約テーブルに記載されている使用端末もしくは予約者が使用している端末に対して、通知方法に示された手段でリソースが解放されたことを通知するS1904。通知メッセージの例を図17に記載する。図17のメッセージでは、解放されたリソースと、リソース予約時に行っていた操作などが表示される。通知を行った制御部21は、通知に対する応答を待つS1905。その後図17のユーザ応答確認オブジェクト1703でOKが押下されたことの通知を制御部21が受信した場合S1906のyes、前記リソース予約時の操作例えば番組の配信などを実行するS1907。図17のユーザ応答確認オブジェクト1703でキャンセルが押下されたことの通知を制御部21が受信した場合、リソースの状態を未使用としS1903、処理を終了する。これらの処理を、前記解放されたリソースに関する予約がなくなるまで処理を繰り返す。このようにして、リソースの競合が発生した場合などに、リソースの予約をしておき、リソースが解放された場合には通知を受け、リソース競合発生時の処理を再開することが可能になる。上記リソース解放の通知は、たとえばユーザが使用端末を変更していた場合には、予約を実行した使用端末ではなくユーザに対してメッセージを通知することが望ましい。そのためには、別途使用端末と使用者の関連付けを管理するテーブルを用いて、前記使用者と予約者が一致している端末に対して、前記通知を行うようにする。これにより、予約を行ったユーザが予約を行った端末とは別の端末を使用している場合にも、前記ユーザに対して通知を行うことが可能になる。前記リソース予約テーブルの予約操作については、配信装置1ではなく、使用端末側で保持する場合もある。その場合には、配信装置1からリソース解放の通知を受けた場合に、リソースを使用する操作について、使用端末側で判断を行い、処理を行う必要がある。またテーブルに登録する情報は上記に記載した以外にも、予約を行った時間やタイムアウトといった情報を登録しておく場合も考えられる。その場合にはその時間を基に、一定時間を経過した予約は削除するなどすると、不要な予約が多く登録されることを防ぐことも可能になる。ユーザが、ユーザ応答確認オブジェクト1703で別の操作をするを選択した場合の動作としては、例えば配信要求の予約を行っていた場合などは、前記解放されたリソースを使用して配信が可能なコンテンツリストを表示しても良い。これにより、ユーザの状況が変わっている場合に異なるコンテンツを配信することも可能となる。メッセージにおけるリソースの名前や端末名は、IDのような数字や記号での表示でも良いが、それぞれの機器に登録されたユーザにとってわかりやすい名称を用いることにより、ユーザにとっての使い勝手が向上するため、配信装置や外部端末でそれらのIDをユーザにとってわかりやすい名称に変換する処理を行うことが好ましい。また、テーブルについても、実施例においては文字で説明を行っているが、数値または文字列など管理しやすいデータ形式としてもよい。また、データの形式としてテーブルのような記載を行っているが、XMLのような形式で記載し、データ量を削減することも可能である。また、実施例におけるメッセージの構成要素については、実施例の記載に限定したものではなく、メッセージごとにそれぞれ記載の内容について追加で情報を記載しても良い。例えば、代替案の表示を図8や図9のユーザ応答確認オブジェクトの選択肢に追加しても良い。これにより、リソース競合時のユーザが入手可能な情報とその後の操作の選択肢が広がることになる。以上説明した実施例によれば、ユーザは希望する処理に使用する配信装置のリソースが競合していた場合に、競合しているリソースを使用しているユーザ、端末、競合しているリソース、使用している処理、リソースの使用予定時間、などを知ることが可能になり、さらにリソースを使用しているユーザに対して、リソースの解放要求を簡易な手段で要求することが可能となる。結果として、リソースが競合している場合でも、リソースを使用しているユーザが許可をすれば、リソースを使用した処理例えば配信処理が可能となる。また配信処理と録画処理が重複している場合にも、ユーザに対してメッセージ表示を行い、リソースの競合に関する情報の提示と、その際の操作を選択することが可能となる。また、上記競合の結果リソースが使用できない場合には、リソースの予約を行い、リソースが解放された場合に、リソースを使用した操作が可能となる。またリソースの競合時において、ユーザに対して代替案の提示を行うことにより、例えば現在のリソースで配信可能なコンテンツリストの確認や、録画や配信のレートを変更を容易に実行することが可能となる。"