HTTPクライアントにライブストリームを送信する装置であって、前記ライブストリームの入力コンテンツを複数のセグメントファイルにセグメント化するセグメンタと、前記複数のセグメントファイルの少なくとも1つが利用可能であるとき、前記複数のセグメントファイルを前記HTTPクライアントに送信するコントローラと、を含む、前記装置。前記コントローラは、前記複数のセグメントファイルを仮想ファイルにマッピングするセグメントリストを保持する、請求項1記載の装置。前記複数のセグメントファイルを、その利用可能性について監視するイベントモニタをさらに含む、請求項1記載の装置。前記複数のセグメントファイルを記憶する記憶装置をさらに含み、前記イベントモニタは、前記記憶装置を監視することによって前記複数のセグメントファイルを監視する、請求項3記載の装置。前記記憶装置から前記複数のセグメントファイルの少なくとも1つを除去するセグメントリムーバをさらに含む、請求項4記載の装置。前記セグメントリムーバは、前記複数のセグメントファイルの全長がしきい値を超える場合、前記記憶装置から古いセグメントファイルを除去する、請求項5記載の装置。前記コントローラは、HTTPチャンク形式転送エンコーディングを介して前記複数のセグメントファイルを送信する、請求項1記載の装置。前記HTTPチャンク形式転送エンコードにおけるチャンクは、前記複数のセグメントファイルの少なくとも1つから得たコンテンツを含む、請求項1記載の装置。前記複数のセグメントファイルの各々は少なくとも1つのサブセグメントを含み、前記セグメンタは前記少なくとも1つのサブセグメントを生成することによって前記複数のセグメントファイルの各々を生成する、請求項1記載の装置。前記コントローラは、前記複数のセグメントファイルの各々の前記少なくとも1つのサブセグメントを送信することによって前記複数のセグメントファイルを送信する、請求項9記載の装置。HTTPクライアントへライブストリームを送信する方法であって、前記ライブストリームの入力コンテンツを複数のセグメントファイルにセグメント化するステップと、前記複数のセグメントファイルの少なくとも1つが利用可能であるとき、前記複数のセグメントファイルを前記HTTPクライアントへ送信するステップと、を含む、前記方法。前記複数のセグメントファイルを仮想ファイルにマッピングするセグメントリストを保持するステップをさらに含むことを特徴とする請求項11記載の方法。前記複数のセグメントファイルを、その利用可能性について監視するステップをさらに含む、請求項11記載の方法。前記複数のセグメントファイルを記憶装置に記憶するステップをさらに含み、前記監視するステップは、前記記憶装置を監視することによって実行される、請求項13記載の方法。前記複数のセグメントファイルの少なくとも1つを前記記憶装置から除去するステップをさらに含む、請求項14記載の方法。前記除去するステップは、前記複数のセグメントファイルの全長がしきい値を超える場合に、前記記憶装置から古いセグメントファイルを除去する、請求項15記載の方法。前記複数のセグメントファイルがHTTPチャンク形式転送エンコーディングを介して送信される、請求項11記載の方法。前記HTTPチャンク形式転送エンコーディングにおけるチャンクが、前記複数のセグメントファイルの少なくとも1つから得たコンテンツを含む、請求項17記載の方法。前記複数のセグメントファイルの各々は少なくとも1つのサブセグメントを含み、前記複数のセグメントファイルの各々は前記少なくとも1つのサブセグメントを生成することによって生成される、請求項11記載の方法。前記複数のセグメントファイルは、前記複数のセグメントファイルの各々の前記少なくとも1つのサブセグメントを送信することにより送信される、請求項19記載の方法。図1は、本発明に係るライブストリームを送るためのメディアストリーミングサーバ100のブロック図を示す。当該メディアストリーミングサーバは、例えば、MPEGトランスポートストリーム等の入力ライブストリームのコンテンツを複数のセグメントファイルにセグメント化するセグメンタ110を有する。当該セグメント化は、当業者に知られている既存のセグメンタプラグインsegmenterplug-insまたは他の方法を用いて行うことができる。メディアストリームサーバはコントローラ130をさらに有する。コントローラは、通常のHTTPクライアントからのライブストリームのリクエストを受け取り、当該リクエストを処理し、リクエストされたライブストリームをクライアントに送る。ライブストリームは複数のセグメントファイルにセグメント化されているので、コントローラは、ライブストリームの1つ以上のセグメントファイルが利用可能な場合すなわちライブストリームの1つ以上のセグメントファイルがメディアストリーミングサーバによって受信され処理される場合、ストリームを送る。コントローラの1つの実装例は、HTTPシンクsinkを使用してなされる。HTTPシンクは、当業者にはGStreamerコンポーネントとして知られているものであり、基本的にはHTTPクライアント複数可にメディアセグメントを送るHTTPサーバである。本発明の1つの実施形態では、図4に示されるように、セグメントファイルが仮想ファイル内にマッピングされるので、クライアントにはライブストリームが1つの連続したファイルのように見える。図4では、セグメントSpts_rec001、Spts_rec002、Spts_rec003等の各々が、セグメントファイルであり、約10秒の長さを有する。マッピングは、仮想ファイル内における各セグメントファイルの先頭のオフセットを記録することによって行うことができる。例えば、Spts_rec002の場合、仮想ファイル内におけるオフセットは934361バイトであり、これは、セグメントファイルSpts_rec002が仮想ファイル内のセグメントファイルSpts_rec001の直後にあることを示している。このような仮想ファイルを使用すると、セグメント化は、クライアントに透過的である。クライアントは、ストリームが1つの連続したファイルであるかのように、ライブストリームを受信し、または当該ライブストリームに検索等の他の操作を行う。1つの実装例では、仮想マッピングは、各要素が下記のような好ましい構造を有しているリンクリストlinkedlistなどのデータ構造により実現される。structsegmentfilesegmentfilenamefilenameofthesegmentfilesegmentstarttheoffsetwithinthevirtualfilesegmentlengthlengthofthesegmentfileこの構造を使用することによって、セグメントリストを構築して、マッピング処理を実現することができる。本発明の1つの実施形態では、セグメントリストは、コントローラ130によって保持される。1つの実施形態では、コントローラ130は、イベントモニタ140からセグメントファイルの利用可能性を通知される。イベントモニタ140は、セグメントファイルを監視する。1つ以上のセグメントファイルがセグメンタ110によって生成されているなら、イベントモニタ140はコントローラ130に通知を送る。その後、コントローラ130はセグメントリストを更新し、生成されたセグメントファイルを取り出して、クライアントからのリクエストに応じてクライアントに当該セグメントファイルを送る。非限定的な例においては、セグメントファイルは、セグメンタ110により生成された後、記憶装置120に格納される。イベントモニタ140は、セグメントファイルにおける全ての変化を監視するために記憶装置120を監視する。1つの実装例では、非同期ファイルシステムのイベントシステム例えば、アイノティファイinotifyがイベントモニタとして使用される。アイノティファイは、ファイルシステムへ変更を通知するためにファイルシステムを拡張し、アプリケーションに当該変更を報告するように動作するリナックスカーネルサブシステムである。本実施形態の利点は、メディアストリームからの古いセグメントファイルを記憶媒体から除去/削除して、当該記憶媒体が時間経過に伴い一杯になるのを防ぐことができることである。例えば、2GBのファイルサイズ制限をサポートする任意のタイプのファイルシステムは、このサーバで使用することができる。従って、図1に示されたメディアストリーミングサーバ100は、記憶媒体からセグメントファイルを除去/削除するセグメントリムーバ図示せずをさらに含むことができる。セグメントを除去するアルゴリズムは以下のように動作する。現在のセグメントリストLsegment_listのコンテンツの全長が計算される長さLsegment_most_recentの最も新しいセグメントを含む。セグメントリストコンテンツの所望の長さLdesiredはユーザによって設定される。もし最も新しいセグメントの長さを引いたセグメントリストの全長が所望の長さの特定の部分を超えるなら、セグメントリスト内の最も古いセグメントは1度に1つずつ除去される。1つの実施形態では、3Lsegment_list-Lsegment_most_recent>Ldesiredならば、最も古いセグメントが除去される。セグメントリストの所望の長さは、ユーザによって指定することができるパラメータである。Ldesiredの値の例は、240秒のコンテンツである。Ldesiredの値の他の例は130MBである。図2は、本発明の1つの実施形態に係るライブストリーム送信プロセスのフローチャートである。ステップ210において、クライアントからのライブメディアストリームのリクエストが受信される。その後、ライブメディアストリームは、ステップ220においてセグメント化される。一方で、セグメント化のためのイベントのウォッチングが設定され、セグメントファイルの生成をモニタリングする。長さ変更またはファイル名変更などのセグメントファイルにおける変更があると、セグメントファイルのセット全体を記録して当該セグメントファイルを1つの仮想連続ファイルにマッピングするセグメントリストが、ステップ230で更新/保持される。セグメントリストが空であるかどうかを、判定ステップ250で判断する。イエスである空であるなら、プロセスはステップ230に戻り、セグメントファイルからの更新を待つ。セグメントリスト内に少なくとも1つのエントリがあれば、プロセスはステップ260に移行してセグメントリスト内の次のセグメントファイルを送出する。HTTPチャンク形式転送エンコーディングは、1つのセグメントファイルを送出するために使用することができる。次いで、セグメントリストへのポインタは、ステップ270において次のセグメントファイルに移動される。プロセスはステップ250に戻り、送信のために利用できるセグメントファイルがさらに存在するかを判断する。本出願のどこかで説明されているように、記憶媒体内のスペースを節約するために、古いセグメントファイルはステップ240で除去されても良く、セグメントリストはステップ230でそれに応じて更新される。以下の記載は、本発明に係るライブメディア送信システムを含むメディアストリーミングサーバを動作させるための好適で詳細なプロセスをまとめたものである。このプロセスによれば、通常のHTTP1.1クライアントがネットワークからのライブメディアストリームの再生をサポートすることができる。当該プロセスは、ライブメディアストリームをセグメント化する能力を備えており、複数のセグメントファイルが実際に1つの連続したデータバッファの如く見えるように当該複数のセグメントファイルを提供するステップを含み、もし古いセグメントファイルがプロセス内の削除アルゴリズムによって削除対象としてマークされると、セグメントファイルを提供するステップの後に古いセグメントファイルの削除が行われる。このプロセスは、図1に示すメディアストリーミングサーバによって、または同じ機能を実現する他のシステムのセットアップによって、実行することができる。当該プロセスはさらに下記のステップによって定義される。1.クライアントはセグメンタ110メディアストリーミングサーバ100内にあるを起動するライブストリームを指す公知のURLに接続して、当該ライブメディアストリームを所定時間長のセグメントファイルに分解することをトリガする。セグメントファイルのサイズ即ち、時間長は、送信遅延とセグメント管理オーバーヘッドとの間の所望のトレードオフに応じて変えることができ、例えば10秒とすることができる。2.非同期ファイルシステムイベントシステムまたはイベントモニタ例えば、アイノティファイを使用して、セグメントファイルが書き込まれるディレクトリに対して、イベントウォッチングを設定する。これにより、いつ各セグメントファイルが修正されたかをウォッチングする。3.セグメントファイルが変更されたときにイベントシステムまたはイベントモニタは信号を送信する。尚、セグメントファイルについて設定された長さや時間に到達するまで、セグメンタは当該セグメントファイル用の複数のサブセグメントを書き込むことにより、セグメントファイルを生成する。複数のサブセグメントの集合がセグメントファイルを形成する。従って、セグメントファイルの修正は、新しいセグメントファイルの作成または1つセグメントファイル内における1つ以上のサブセグメントの追加/更新によって行われる可能性がある。この時点で、セグメントファイルの名称とフルファイルパスfullfilepathが、当該セグメントファイルの始点及び長さと共に記録される。これが当該ストリームからの最初のセグメントファイルである場合、始点はゼロになり、長さはセグメントファイルの現在のサイズになる。同一セグメントファイル内の連続する各修正イベントについては、開始オフセットが1前回のセグメントファイルの始点前のセグメントファイルの長さとなる。このセグメントファイルは、セグメントリストの最後に追加される。もしセグメントのファイル名が変わるならそれは新しいセグメントファイルが作成されていることを意味する、セグメントリストに追加された前のエントリは、その時点における全体のセグメントリストについては最後のセグメントファイルであるとしてフラグが立てられなければならない。セグメンタの実装例において、セグメントの長さは、セグメントファイルの全長に達するまでこの時点で新しいセグメントファイルが開始するxkbpsすなわち、1つのサブセグメント毎に更新される。尚、xが小さい場合つまり、サブセグメントがより小さい場合、より多くのオーバーヘッドを要するが、セグメントファイルに対するよりタイムリーなアップデートを提供する。極端な場合には、xはセグメントファイルの全長に等しい。つまり、セグメントファイルは1つのサブセグメントのみから構成される。4.次のステップは、セグメントリストが少なくとも1つのエントリを有するまで待つことである。1つの実装例では、メディアストリーミングサーバ内の他のスレッドが生成されて、1つのセグメントファイルがセグメンタから作成されるのを待つ。このスレッドがセグメントファイルの利用可能状態を認識すると、当該スレッドはメインスレッドに信号を送り、当該セグメントファイルがHTTPクライアントに送信されるように処理する。5.セグメントリストの最初のエントリが検査される。1つのエントリがセグメントリストに追加されていると、セグメントファイルは、ローカル記憶媒体からの読み込みのために開かれる必要がある。リスト内にセグメントファイルがない場合、プロセスは、少なくとも1つの生成されかつ検査に利用できるセグメントファイルができるまで、待機しなければならない。6.その後、検査対象の検査中のセグメントファイルが読み出され、サーバが、HTTPチャンク形式転送エンコーディングを介して、事前定義されたチャンクサイズScでセグメントファイルを送出する。チャンクサイズScはオーバーヘッドと送信遅延との間のトレードオフに基づいて決定される。例として、Scとして128キロバイトが、クライアントに送られる適切なチャンクサイズである。7.セグメントファイルの長さがチャンクサイズScより大きい場合、サーバは再度ファイルのScを記憶媒体から読み出し、当該Scをクライアントに送信する。8.セグメントリスト内の現在のセグメントファイルの位置を示すポインタが1だけインクリメントされ、次のセグメントファイルが検査される。9.現在のセグメントファイルの一部がクライアントに送られると、論理ストリームまたは仮想ファイル内の位置インジケータは、以前の位置の値と、現在のセグメントファイルのためにクライアントに送られたバイトの総数との合計値に設定される必要がある。10.セッションが終了するまでプロセスを繰り返す。メディアソースが配信を終了したとき、または、クライアントがHTTPサーバから切断したとき、セッションを終了することができる。別の実施形態では、ステップ6~9は、セグメントファイル内の各サブセグメントに対して実行される。つまり、セグメントファイルの1つのサブセグメントが読み出され、HTTPチャンク形式転送エンコーディングを介して送出される。論理ストリームまたは仮想ファイル内の位置インジケータは、各サブセグメント毎に更新される。セグメントファイル内の全てのサブセグメントが処理されるまで、上記のステップが繰り返される。上述したプロセスは、例示的な一実施形態であることに留意することが重要である。異なるプロセスを採用する場合は、上記ステップのうちの1つ以上を省略することができるし、上記していない追加のステップをさらに含んでもよい。また、上記のステップのうちの1つ以上は、上記プロセスの重要で有利な特徴を基本的に変更せずに、組み合わせたり並列的に実行されてもよい。図3は図2に示された実施形態の実装例を示している。この実装例は、メモリ制御、管理、セグメントファイルのマッピング及びセグメントリスト管理の特徴を含む。1.HTTPチャンキングモードでウェブサーバを起動するステップ310。2.ウェブルートディレクトリのIN_CLOSE_WRITEのアイノティファイファイルシステムイベントをリッスンするステップ320。書き込み用に開いたファイルが閉じられたときにIN_CLOSE_WRITEのイベントが送られる。3.セグメントファイル名及びセグメントファイル長のマップがセグメント化ツールから生成されると、当該セグメントファイル名及びセグメントファイル長のマップをセグメントリストとして保持するステップ330。4.クライアントから範囲:バイト=0-のような範囲ヘッダ付きのリクエストを待ちステップ340。クライアントは、この範囲ヘッダを指定することにより、ウェブサーバがセグメントの配信のためにHTTP1.1チャンク形式モードを使用することを指定する、第1のセグメントファイルの設定可能なチャンクサイズScをHTTPクライアントに提供するステップ350。Scの例示的な値は128Kバイトである。5.範囲:バイト=12389098-のような範囲ヘッダ付きのリクエストをクライアントから待ちステップ340、当該範囲ヘッダで指定したバイトオフセットから開始する設定可能なチャンクサイズをクライアントに提供するステップ350。当該オフセットは、この例では、12389098である。尚、1つのチャンクは、2つの異なるセグメントファイルにまたがることができ、ステップ3で述べたマップ内のルックアップが必要になる。6.いくつのセグメントがセグメントリストに保持されるべきかを設定するプロパティを定義する。本明細書において説明した方法で、ハードディスク及びセグメントリストから残りのセグメントファイルを除去するステップ360。同じライブストリームを要求する複数のクライアントが存在する場合、異なるクライアントに対して異なるポインタが採用されて、ストリーム内に各クライアントのバージョンの現在位置を記録する。複数のプログラム入力があるすなわち、複数のライブストリームがある場合、複数のセグメントが使用され得る各プログラムに1つのセグメントが使用される。異なる実施形態では、1つ以上のセグメントが複数のライブストリームの間で共有される。1つの記憶装置を複数のライブストリームの間で共有することができるが、異なるプログラムのために異なるディレクトリを設定する必要がある。ファイルシステムイベントモニタは、各ディレクトリをウォッチングするように設定されなければならない。コントローラは異なるライブストリームに対する複数のリクエストに対応するため、複数のスレッド/プログラムを取り扱うように構成される。実施形態は、既存の技術と同様な方法で、例えば、所望の表示時間等に関して、コンテンツ内を検索するクライアントをサポートする但し、検索の実行の仕方は異なる。本実施形態では、ライブメディアストリームは記憶媒体上でセグメントファイルに分割される。開示されたプロセスは、各セグメントファイルのバイト境界の知識を用いて検索機能を使用することにより、クライアントにメディアストリームの論理表示を示すことができる。メディアストリームは異なるファイルに分割されているが、クライアント装置は実質的に当該メディアストリームが連続的であると知覚する。換言すると、ストリームが公知の数の既存セグメントファイルにセグメント化されかつ未知の数のセグメントファイルにその後セグメント化されるとしても、サーバに実装されるアルゴリズムを使用すると、各クライアントには、ストリームが1つの連続したファイルであるかのように見える。図5は受信装置の実施形態のブロック図を示す。当該受信装置は、ゲートウェイ装置、モデム、セットトップボックス、または他の類似の通信装置の一部として含めることができる。図示された装置は、音響装置または表示装置等の他のシステムに組み込むこともできる。いずれの場合も、システムを完全に動作させるために必要ないくつかのコンポーネントは、当業者には周知であるので、簡潔さのために示していない。図5に示された装置においては、コンテンツは入力信号受信部510によって受信される。入力信号受信部は、数個の可能性のあるネットワーク例えば、無線、有線ケーブル、衛星、イーサネット登録商標、ファイバ、電話回線網の1つを介して提供される信号を受信、復調及び復号するために用いられる数個の公知の受信回路の1つであってよい。所望の入力信号は、制御インタフェースまたはタッチパネルインタフェースを介して提供されるユーザ入力に基づいて、入力信号受信部により選択され取得することができる。タッチパネルインタフェースは、タッチスクリーンデバイスのためのインタフェースを含むことができる。タッチパネルインタフェースは、携帯電話、タブレット、マウス、ハイエンドリモートデバイス等にインタフェースするように採用することができる。復号された出力信号は、入力ストリーム処理部520に提供される。入力ストリーム処理部は最終信号選択及び処理を行い、これはコンテンツストリームの音声コンテンツから映像コンテンツを分離することを含む。音声コンテンツは音声処理部530に提供されて、受信されたフォーマット例えば、圧縮デジタル信号をアナログ波形信号に変換する。アナログ波形信号は、音声インタフェース540に供給され、さらに表示装置若しくは音声アンプに供給される。代替構成では、音声インタフェースは、高品位マルチメディアインタフェースHDMI登録商標ケーブルまたはその代わりとなる音声インタフェース例えば、ソニー/フィリップスデジタルインタコネクトフォーマットSPDIFを介して、音声出力装置または表示装置にデジタル信号を提供することができる。音声インタフェースは、もう1つのスピーカセットを駆動するための増幅器を含んでもよい。さらに、音声処理部は、音声信号を記憶するために必要な任意の変換を行う。入力ストリーム処理部からの映像出力が映像処理部550に提供される。映像信号は複数のフォーマットの1つであってよい。映像処理部は、入力信号フォーマットに基づいて映像コンテンツの必要な変換を提供する。また、映像処理部は、映像信号を記憶するための必要な変換を行う。記憶装置560は入力部で受信された音声及び映像コンテンツを記憶する。記憶装置は、その後、コントローラの制御の下に、ユーザインタフェース及びまたはタッチパネルインタフェース585から受け取ったコマンド例えば、早送りFF及び巻き戻しREW等のナビゲーション命令に基づき、コンテンツの取り出し検索と再生を行うことができる。記憶装置は、ハードディスクドライブ、1つ以上の大容量集積電子メモリ例えば、スタティックRAMSRAMまたはダイナミックRAMDRAMであってもよいし、交換可能な光学ディスク記憶システム例えば、コンパクトディスクCDドライブまたはデジタルビデオディスクDVDドライブであってもよい。映像処理部からの変換された映像信号入力部から供給された映像信号または記憶装置から供給された映像信号は、ディスプレイインタフェース570に提供される。また、当該ディスプレイインタフェースは、テレビ、コンピュータまたはディスプレイモニタ等の表示装置に表示信号を提供する。ディスプレイインタフェースは、例えば赤-緑-青RGB等のアナログ信号インタフェースでもよいし、HDMI等のデジタルインタフェースでもよい。コントローラ580は、入力ストリーム処理部520、音声処理部530、映像処理部550、記憶装置560、及びユーザインタフェース590を含む、受信装置のコンポーネントのいくつかにバスを介して相互接続される。コントローラは、入力ストリーム信号を記憶装置に記憶できる信号にまたは表示用の信号に変換する変換処理を管理する。また、コントローラは、記憶されたコンテンツの取り出し及び再生を管理する。さらに、コントローラは、コントローラ用の情報及び命令コードを記憶するために、制御メモリ595例えば、RAM、SRAM、DRAM、ROM、プログラマブルROMPROM、フラッシュメモリ、電子的プログラマブルROMEPROM、電子的消去可能プログラマブルROMEEPROM等の揮発性メモリまたは不揮発性メモリに接続されている。制御メモリは、受信装置を動作させる制御装置により実行される命令を記憶すると共に、メイン装置例えば、ゲートウェイ、セットトップボックスにより実行される命令も記憶することができる。操作に使用されるソフトウェアコンポーネント及びソフトウェアインタフェースは、コントローラによって実行されてもよい。さらに、いくつかの操作は、通信インタフェースを介してソフトウェアコードの通信により転送され、例えば、後述するタッチパネル装置等の外部装置によって実行されてもよい。また、制御メモリは、コンテンツを含むグラフィック要素等の要素のデータベースを格納することができる。さらに、制御メモリの実装は、単一のメモリ装置、または、代替例として、通信可能に接続または相互に結合して1つの共有メモリまたは共通メモリを形成する複数のメモリ回路等の、いくつかの可能な実施形態を含んでもよい。加えて、メモリは、バス通信回路の部分等の、より大きな回路内の他の回路構成に含めることができる。本発明の開示に係るユーザインタフェースプロセスは、早送り、巻き戻し等の機能を表現するために用いることができる入力装置を採用している。これを可能にするために、図6に示されているタッチパネル装置またはリモートタブレットは、ユーザインタフェース及びまたは図5に示されている受信装置のタッチパネルインタフェースを介して、インタフェースすることができる。タッチパネル装置は、手の動き、又はジェスチャ、及び動作に基づくセットトップボックスまたは受信装置の操作を、当該パネルを介して当該セットトップボックスまたは他の制御装置のための命令に翻訳することができる。図5の受信装置に関して説明された回路及び機能の幾つかは、タッチパネル装置に存在してもよいことに留意することが重要である。1つの実施形態では、タッチパネルは、単にディスプレイをナビゲートするためのナビゲーションツールとして機能してもよい。他の実施形態では、タッチパネルは、さらに、ユーザがコンテンツの表示を介してナビゲーションとより直接的に対話できるようにする表示装置として機能する。タッチパネル装置は、例えば、フロントパネルディスプレイ又はアレイの一部として、セットトップボックス自体に統合されてもよい。また、タッチパネル装置は、起動ボタン等のより従来の制御機能を含むリモート制御装置の一部として含まれてもよい。セットトップボックスまたはゲートウェイの一部として図5で説明した受信装置と、図6で説明したリモートタブレットもしくはタッチパネルディスプレイとの間の通信インタフェースは、ローカルエリアネットワーク内で動作するクライアントサーバ型のプロトコルを含むことができる。例えば、メディアコンテンツ例えば、映像、音声はHTTP1.1標準を介してクライアント例えば、タッチパネル装置とサーバ例えば、セットトップボックスまたはゲートウェイとの間で転送することができる。また、サーバは、上述したように、2つ以上のクライアント例えば、第2のセットトップボックス、シンthinクライアント装置等へのメディア配信を同時にサポートすることができる。上記の実施形態は、非常に手軽なものであり、ローカルサーバ例えば、セットトップボックス、ゲートウェイ等とローカルクライアント例えば、リモート装置、タブレット等との間で上記のようなローカルエリアネットワークで動作させることができる。本発明の技術思想は広域ネットワークにおいても使用できるように、拡張することができる。例えば、プロセスは、ユーザの家庭内の複数のクライアント装置クライアント装置のセットとウェブサービスを利用したインターネットサービスで使用できるように適合させることが容易にできる。本明細書において本発明の好適な実施形態を詳細に説明してきたが、本発明はこれら実施形態に限定されるものではなく、その他の変更及び変形が特許請求の範囲によって定義された本発明の範囲から逸脱することなく当業者によってなされ得る。