JP2008245226A - サーバ装置、プログラム、及びコンテンツ配信方法 - Google Patents

Abstract

【課題】ホームネットワークにおいて、放送コンテンツのライブ配信を容易に行うことができるようにする。
【解決手段】サーバ装置において、所定の放送局からの放送を受信する受信手段（Ｓ１１）と、受信手段からの受信信号を順次所定形式のデータに変換して所定のバッファに順次書き込む書込み手段（Ｓ１２、ＷＰ）と、書込み手段によりバッファに順次書き込まれるデータを順次読み出す読出し手段（ＲＰ）と、前記放送局に対応する名称のファイルを作成する作成手段（Ｓ１３）とを設け、作成手段により作成されたファイルと同じファイル名を指定した配信要求をクライアント装置から受信したとき、バッファに順次書き込まれるデータを順次読み出し、前記指定されたファイル名のファイルのデータとしてクライアント装置に順次送信する送信手段（Ｓ１４〜Ｓ１７）とを設ける。
【選択図】図２

Description

本発明は、クライアント装置に対し、配信要求に応じ、要求されたコンテンツを配信するサーバ装置、該装置としてコンピュータを機能させるプログラム、及び該サーバ装置におけるコンテンツ配信方法に関する。

近年、有線ＬＡＮや無線ＬＡＮを使用してホームネットワークを安価に構成することが容易になり、パーソナルコンピュータ（以下、「ＰＣ」という。）や、ネットワーク対応ＡＶ機器、ゲーム端末、携帯機器等の非常に多くの製品がホームネットワークに接続され利用されるようになってきている。これに伴い、家電、モバイル端末、ＰＣ等の相互接続を容易にするための業界団体であるＤＬＮＡ（デジタル・リビング・ネットワーク・アライアンス）が結成されるとともに、ＤＬＮＡにより、機器間が通信する際のＵＰｎＰをベースとする手順やユーザインタフェース等を定めたＤＬＮＡガイドラインも作成されている（たとえば非特許文献１参照）。ＤＬＮＡガイドラインでは、コンテンツを提供する機器をサーバと呼び、コンテンツを再生する機器をプレーヤ又はクライアントと呼ぶ。サーバ及びプレーヤはそれぞれ別々の機器の場合もあれば、ＰＣ等のように１つの機器がサーバ及びプレーヤの機能を兼ね備える場合もある。

ホームネットワーク上のサーバやプレーヤは、特に１対１の接続を行うものに限定されることはない。複数のサーバやプレーヤがホームネットワーク上において相互接続が可能な状態で存在することも、もちろん想定されている。車載ＡＶ機器やポータブルＨＤＤプレーヤのような携帯オーディオ端末の場合においても、このようなホームネットワークへの接続は可能である。このような端末は、ユーザが望むときにホームネットワークに接続して利用することができる。また、ポータブル端末同士で直接コンテンツのやり取りを行うこともできる。

"ＤＬＮＡオーバビュー・アンド・ビジョン・ホワイトペーパ２００６"、［ｏｎ ｌｉｎｅ］、平成１８年、デジタル・リビング・ネットワーク・アライアンス、［平成１９年２月２２日検索］、インターネット、＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｄｌｎａ．ｏｒｇ／ｅｎ／ｉｎｄｕｓｔｒｙ／ａｂｏｕｔ／ｄｌｎａ＿ｗｈｉｔｅ＿ｐａｐｅｒ＿２００６．ｐｄｆ＞

しかしながら、上述従来のＤＬＮＡに準拠した機器で構成されるホームネットワークによれば、サーバに蓄積されているコンテンツについては、ストリーミング形式でクライアントに配信するための手順やユーザインタフェースが確立されているものの、受信中の放送をそのまま放送コンテンツとしてライブ配信することは確立されていない。また、ＤＬＮＡに準拠していない現在あるネットワークプレーヤ（サーバにあるＭＰ３形式などの音楽ファイルを再生する機器）においては受信中の放送をそのまま放送コンテンツとしてライブ配信することはできない。

本発明の目的は、このような従来技術の問題点に鑑み、ホームネットワークにおいて、放送コンテンツのライブ配信を容易に行うことができるようにすることにある。

この目的を達成するため、第１の発明に係るサーバ装置は、所定の放送局からの放送を受信する受信手段と、前記受信手段からの受信信号を順次所定形式のデータに変換して所定のバッファに順次書き込む書込み手段と、前記書込み手段により前記バッファに順次書き込まれるデータを順次読み出す読出し手段と、前記放送局に対応する名称のファイルを作成する作成手段と、前記作成手段により作成されたファイルと同じファイル名を指定した配信要求をクライアント装置から受信したとき、前記バッファに順次書き込まれるデータを順次読み出し、前記指定されたファイル名のファイルのデータとして前記クライアント装置に順次送信する送信手段とを具備することを特徴とする。

この構成において、所定の放送局からの放送を受信して得られる受信信号を所定の形式に変換しながらバッファへ順次書き込む動作が開始され、前記放送局に対応する名称のファイルが作成されると、前記放送局による放送コンテンツのライブ配信の準備が完了する。この状態において、前記作成したファイルと同じ名称を指定した配信要求をクライアント装置から受信すると、バッファに順次書き込まれるデータを順次読み出して、前記指定された名称に係るファイルのデータとして前記クライアントに順次送信する動作を開始する。クライアント装置はこれを受信し、デコードして、放送コンテンツの再生を行うことができる。これにより、クライアント装置は、蓄積コンテンツに対する配信要求と同様の手順で、サーバ装置からの放送コンテンツのライブ配信を受けることができる。

第２の発明に係るサーバ装置は、第１発明において、前記バッファはリングバッファ構成のものであり、前記順次の書込みにおける各書込み時には、書き込んだデータ量の分だけ書込みポインタのアドレスが進められ、前記順次の読出しにおける各読出し時には読出しポインタのアドレスから書込みポインタのアドレスまでのデータが読み出されるとともに、そのアドレスまで読出しポインタのアドレスが進められることを特徴とする。

第３の発明に係るサーバ装置は、第１又は第２発明において、前記作成手段が作成するファイルの名称は、前記放送局を特定する文字列に対し、前記データ形式を表す拡張子を結合して構成されるものであることを特徴とする。

第４の発明に係るサーバ装置は、第１〜第３のいずれかの発明において、前記放送局に対応する名称を、前記配信要求において指定することができるファイル名として、前記クライアントに通知する手段を有することを特徴とする。

第５の発明に係るプログラムは、第１〜第４のいずれか発明に係るサーバ装置における各手段としてコンピュータを機能させることを特徴とする。

第６の発明は、サーバ装置におけるクライアント装置へのコンテンツ配信方法であって、所定の放送局からの放送を受信し、受信データを所定の形式に変換しながらリングバッファに順次書き込む書込み工程と、前記放送局に対応する名称のコンテンツファイルを作成する作成工程と、前記作成工程の後、前記書込み工程の実施中に、前記作成工程で作成したファイルと同じファイル名を指定した配信要求をクライアントから受信したとき、前記リングバッファに順次書き込まれるデータを順次読み出し、前記指定されたファイル名のファイルのデータとして前記クライアントに順次送信する送信工程とを具備することを特徴とする。

本発明によれば、所定の放送局からの放送を受信して得られる受信信号を所定の形式に変換しながらリングバッファへ順次書き込む動作を開始するとともに、前記放送局に対応する名称のファイルを作成した状態において、前記作成したファイルと同じファイル名を指定した配信要求をクライアント装置から受信したことに応答し、リングバッファに順次書き込まれるデータを順次読み出して、前記指定されたファイル名のファイルのデータとしてクライアント装置に順次送信する動作を開始するようにしたため、クライアント装置は、蓄積コンテンツに対する配信要求と同様の手順で、サーバ装置からの放送コンテンツのライブ配信を受けることができる。

図１は、本発明の一実施形態に係るホームネットワークの構成を示す。このホームネットワークは、レコーダやチューナを備えたサーバ１１、サーバ１１から配信を受けるコンテンツを再生し、スピーカ１２から再生音を出力するクライアント１３及び１４、並びにサーバ１１、クライアント１３、及びクライアント１４間に介在するハブ１５を備える。

図２はサーバ１１の構成の一例を示すブロック図である。このサーバは、同図に示すように、サーバの各部を制御し、必要な情報処理を行う処理部２１、処理部２１に対して受信データを供給するチューナ部２２、処理部２１における処理に際して必要なプログラムやデータの記憶を行うＥＥＰＲＯＭ２３、フラッシュメモリ２４、及びＳＤＲＡＭ２５、チューナ部２２から処理部２１に供給される受信データについて必要な信号処理を行うＤＳＰ２６、処理部２１をホームネットワークに接続するためのネットワークコントローラ２７及びコネクタ２８、処理部２１に対する指示操作を行うための操作部２９、並びに処理部２１が必要な情報の表示を行うための表示部３０を備える。

チューナ部２２はＦＭ放送、ＡＭ放送、ＴＶ放送等を受信し、その受信データを処理部２１に対して供給することができる。処理部２１は、クライアント１３や１４からの要求に基づき、放送コンテンツの配信等を行う。放送コンテンツの配信は、チューナ部２２からの受信データに基づき、ライブストリーミング方式により行うことができる。

図３はクライアント１３や１４の構成の一例を示すブロック図である。このクライアントは同図に示すように、図２における構成要素２１及び２３〜３０と同様の処理部３１、ＥＥＰＲＯＭ３３、フラッシュメモリ３４、ＳＤＲＡＭ３５、ＤＳＰ３６、ネットワークコントローラ３７、コネクタ３８、操作部３９、及び表示部４０を備える。またさらに、ＤＳＰ３６により処理したデジタル信号をアナログ信号に変換して外部に出力するＤＡコンバータ４１、並びに処理部３１にＵＳＢ機器を接続するためのＵＳＢコントローラ４２及びＵＳＢ端子４３を備える。操作部３９及び表示部４０により、後述するようなユーザインタフェースが構成される。処理部３１は操作部３９による操作指示に基づき、各サーバに対する配信要求や、配信要求に応じて配信されるコンテンツの受信、再生等を行う。

図４はクライアント１３や１４の構成の別の例を示すブロック図である。このクライアントは、同図に示すように、図３の構成に対し、ディスクドライブ４４及びハードディスクドライブ４５を追加したものである。すなわち、一般的なハードディスクレコーダとしての構成を備える。

図５〜図９は、クライアント１３や１４の表示部４０において表示されるコンテンツ再生用操作画面の一例を示す。図５においては、ユーザにより音楽コンテンツを再生する操作が行われる場合の操作画面の変化が、同図（ａ）〜（ｇ）の画面により示されている。同図（ａ）の画面を表示している状態において、クライアントはサーバに接続し、サーバが配信可能なコンテンツに関する情報を取得する。同（ａ）の画面では、コンテンツの種類に関する選択項目として、「ＭＵＳＩＣ」（音楽）、「ＰＨＯＴＯ」（静止画）、「ＭＯＶＩＥ」（動画）が表示されている。

この画面において、同図（ｂ）のように、ユーザが「ＭＵＳＩＣ」を選択すると、クライアントは、サーバから取得した上述のコンテンツ情報に基づき、音楽コンテンツの範疇に属する各フォルダ等の名称を選択項目として表示した同図（ｃ）の画面を表示する。この画面において、同図（ｄ）のように、たとえば「ＲＯＣＫ」が選択されると、「ＲＯＣＫ」フォルダ中の各音楽ファイルの名称を選択項目として表示した同図（ｅ）の画面を表示する。

この画面において、同図（ｆ）のように、たとえば「Ｆａｌｌ Ｔｏｇｅｔｈｅｒ．ｍｐ３」が選択されると、クライアントは、「Ｆａｌｌ Ｔｏｇｅｔｈｅｒ．ｍｐ３」についての配信要求をサーバに送信する。サーバがこの要求に応じて配信を開始すると、クライアントはこれを受信し、同図（ｇ）の画面を表示して、「Ｆａｌｌ Ｔｏｇｅｔｈｅｒ．ｍｐ３」の再生を開始する。

図６においては、ユーザによりＦＭ放送を受信する操作が行われる場合の操作画面の変化が、同図（ａ）〜（ｇ）の画面により示されている。同図（ａ）から同図（ｃ）までの画面での操作並びにサーバ及びクライアントの動作は、図５（ａ）から図５（ｃ）までの場合と同様である。図６（ｃ）の画面において、同図（ｄ）のように「ＦＭ」が選択されると、同図（ｅ）のように、「ＦＭ」フォルダに含まれる音楽ファイルの名称の形式で、選択項目が表示される。

このファイル名は、サーバにおいて、放送を受信して得られるデータを、仮想的にファイル化した擬似ファイルとして取り扱うことができるようにするために、その擬似ファイルの名称として付与されたものである。サーバは、この擬似ファイルの名称を、コンテンツ情報中に提供可能なコンテンツとして含めてクライアントに提供し、クライアントはこの擬似ファイルの名称を、同図（ｅ）の画面において表示することができる。擬似ファイルの名称としては、たとえば放送局名に、擬似ファイルに係るデータのファイル形式を表す拡張子を結合したものが採用される。

同図（ｅ）の画面において、同図（ｆ）のように、たとえば「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）．ｍｐ３」が選択されると、クライアントは、「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）．ｍｐ３」の配信要求をサーバに送信する。これに応じて、サーバはファイル名「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）．ｍｐ３」の擬似ファイルのデータ、すなわち「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）」を受信して得られるデータをクライアントにライブ配信する動作を開始する。クライアントはこれを受信し、ファイル形式「ｍｐ３」に従った再生動作を開始する。再生時間を表示するタイムカウンタやタイムバーは動作させても、させなくてもよい。これにより、クライアントは、サーバに蓄積された音楽コンテンツの配信を受けて再生する図５の場合と同様の手順で、放送局「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）」からの放送コンテンツのライブ配信を享受することができる。

図７においては、ユーザにより動画を再生する操作が行われる場合の操作画面の変化が同図（ａ）〜（ｇ）により示されている。同図（ａ）の内容及びその表示中の動作は図５（ａ）の場合と同じである。図７（ａ）の画面において、同図（ｂ）のように、「ＭＯＶＩＥ」が選択されると、クライアントは、取得したコンテンツ情報に基づき、動画（ＭＯＶＩＥ）の範疇に属するフォルダ等の名称を選択項目として表示した同図（ｃ）の画面を表示する。

この画面において、同図（ｄ）のように、たとえば「ＳＰＯＲＴＳ」が選択されると、「ＳＰＯＲＴＳ」フォルダ中の動画ファイルの名称を選択項目として含む同図（ｅ）の画面を表示する。同図（ｅ）の画面において、同図（ｆ）に示すように、たとえば「Ｂａｓｅｂａｌｌ．ｍｐｇ」が選択されると、クライアントは、「Ｂａｓｅｂａｌｌ．ｍｐｇ」の配信要求をサーバに送信する。これに応じ、サーバがその配信を開始すると、プレーヤはこれを受信し、同図（ｇ）の画面を表示して、「Ｂａｓｅｂａｌｌ．ｍｐｇ」再生を開始する。

図８においては、ユーザによりＴＶ放送を受信する操作が行われる場合の操作画面の変化が、同図（ａ）〜（ｇ）により示されている。同図（ａ）から同図（ｃ）までの操作並びにサーバ及びクライアントにける動作は、図７（ａ）から同図（ｃ）までの場合と同様である。図８（ｃ）の画面において、同図（ｄ）のように「ＴＶ」フォルダが選択されると、同図（ｅ）のように、「ＴＶ」フォルダに含まれる動画ファイルの名称の形式で、択項目が表示される。このファイル名は上述の図６（ｅ）の場合と同様の擬似ファイルの名称である。

同図（ｅ）の画面において、同図（ｆ）のように、たとえば「日本ＴＶ．ｍｐｇ」が選択されると、クライアントは、「日本ＴＶ．ｍｐｇ」の配信要求をサーバに送信する。これに応じて、サーバは擬似ファイル「日本ＴＶ．ｍｐｇ」のデータ、すなわち放送局「日本ＴＶ」を受信して得られるデータをクライアントにライブ配信する動作を開始する。クライアントはこれを受信し、ファイル形式「ｍｐｇ」に従った再生動作を開始する。この場合も、タイムカウンタやタイムバーは動作させても、させなくてもよい。これにより、クライアントは、サーバに蓄積された動画コンテンツの配信を受けて再生する図７の場合と同様の手順で、放送局「日本ＴＶ」からの放送コンテンツのライブ配信を享受することができる。

図９は、他のクライアントのためにサーバが既に放送を受信中の場合における図６（ｅ）及び図８（ｅ）に対応する画面の一例を示す。図９（ａ）は図６（ｅ）に対応する画面であり、図９（ｂ）は図８（ｅ）に対応する画面である。図９（ａ）の画面では、「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）」が受信中であり、他の放送局が受信できない旨が表示されている。この場合、受信中の「ＴＯＫＹＯ−ＦＭ（８０．０ＭＨｚ）」のみが選択対象となり、その配信を受けることができる。図９（ｂ）の画面では、「日本ＴＶ」が受信中であり、他の放送局が受信できない旨が表示されている。この場合、受信中の「日本ＴＶ」のみが選択対象となり、その配信を受けることができる。

図１０はサーバにおける処理の一部を示すフローチャートである。この処理は、上述の図６（ｆ）や図８（ｆ）の画面で選択される放送コンテンツのライブ配信を可能とするための処理である。処理を開始すると、まず、ステップＳ１において、所定の放送局について受信を行っているチューナ部２２からの受信信号をエンコードし、仮想的にファイル化する処理を行う。

すなわち、エンコードによって順次得られるデータをメモリ上にのみ存在させるとともに、このデータを擬似的にファイルとして扱うことができるように、ファイル名を付与する。この擬似ファイルのファイル名は、たとえば放送局名に拡張子「．ｍｐ３」を付加したものとされる。このファイル名は内容のないヌルファイルを作成し、そのファイル名として付与される。つまり、このファイル名のファイルに対する読出し要求があった場合には、上記メモリ上のデータが読み出されるように構成される。

ヌルファイルのサイズは無限大とするのが望ましいが、現実的には不可能であるため、圧縮レートを考慮した２４時間分、又はそれ以上のファイルサイズとする。クライアントにおいて実質的にエンドレスで再生することができるようにするためである。

ステップＳ２においては、上記擬似ファイルのファイル名を指定したクライアントからの配信要求を待機しており、この間、ステップＳ１における受信信号のエンコードは、チューナ部２２が放送を受信中である限り、常に行われている。これにより、上記擬似ファイルのファイル名を指定したクライアントからの配信要求があった場合にはいつでもエンコードされたデータの供給を開始することができる状態となっている。

上述の図６（ｆ）や図８（ｆ）の画面において、上記擬似ファイルのファイル名が選択されたことに応じてクライアントがそのファイル名を指定した配信要求をサーバに送信すると、サーバはこの配信要求をステップＳ２において検出する。これに応じ、サーバは、ステップＳ３において、擬似ファイルのデータとして上述のエンコードにより順次生成する圧縮データをクライアントに順次転送する動作を開始する。このエンコードデータの転送は、ステップＳ４において、配信要求がクライアントによってキャンセルされない限り継続される。キャンセルされた場合には、ステップＳ１に戻り、再度、配信要求の待ち状態へ移行する。

図１１は、図１０の処理をより詳細に示す。図中の１１１はＳＤＲＡＭ２５上において予め確保されたバッファ領域であり、上述の擬似ファイルを形成するためのものである。バッファ領域１１１はリングバッファ構成となっている。つまり、書込み又は読出しは、それぞれ書込みポインタＷＰ又は読出しポインタＲＰが示すアドレスから行われ、書込み又は読出し量に応じてポインタのアドレスは進められる。読出しに際しては、読出しポインタＲＰのアドレスから書込みポインタＷＰのアドレスまでのデータが読み出される。アドレスは、バッファ領域１１１の最後に達すると、最初に戻る。バッファ領域１１１の容量は、機能上必要な分だけ確保すればよく、たとえば数キロバイト程度でよい。図１１中の（ａ）〜（ｅ）はサーバにおける処理Ｓ１１〜Ｓ１７に応じてバッファ領域１１１が変化する様子を示している。

チューナ部２２が、たとえば放送局「ＦＭ８０．００ＭＨｚ」の受信を開始すると（Ｓ１１）、サーバは受信データをｍｐ３形式のデータへ圧縮するエンコードを開始する（Ｓ１２）。エンコードにより得られるデータについては、図１１（ａ）及び（ｂ）のように、バッファ領域１１１に対し、書込みポインタＷＰのアドレスから書込みを行い、書込み量に応じてポインタＷＰを進める。読出しポインタＲＰのアドレスはそのままである。このときサーバは、放送局名「ＦＭ８０．００ＭＨｚ」に対し、圧縮後のファイル形式を示す拡張子「ｍｐ３」を結合して構成した名称「ＦＭ８０．００ＭＨｚ．ｍｐ３」のファイルを作成する（Ｓ１３）。内容のないヌルファイルでよい。これにより、ファイル名「ＦＭ８０．００ＭＨｚ．ｍｐ３」を指定したクライアントからの配信要求に対し、直ちにこれに応じるための準備が完了したことになる。

この状態において、クライアントが、図６（ｆ）のような画面においてファイル「ＦＭ８０．００ＭＨｚ．ｍｐ３」の再生指示がなされた（Ｃ１１）ことに応じて、ファイル「ＦＭ８０．００ＭＨｚ．ｍｐ３」についてのＧＥＴコマンドによる転送要求をサーバに対して送信すると（Ｃ１２）、これを受信した（Ｓ１４）サーバは、図１１（ｃ）のように、読出しポインタＲＰのアドレスを書込みポインタＷＰのアドレスまで進める。これにより、擬似ファイル「ＦＭ８０．００ＭＨｚ．ｍｐ３」についてのデータ転送の準備を完了し、データ転送を開始する（Ｓ１５）。

すなわち、図１１（ｄ）のように、所定のタイミングで、それまでバッファ領域１１１に書き込んだ、読出しポインタＲＰから書込みポインタＷＰまでのエンコード済みデータ９１をクライアントに転送し、読出しポインタＲＰを書込みポインタＷＰまで進める（Ｓ１６）。クライアントは、これに応じ、ファイル「ＦＭ８０．００ＭＨｚ．ｍｐ３」の受信を開始するとともに（Ｃ１３）、受信データをデコードし、再生する動作を開始する（Ｃ１４）。

以後、サーバは、図１１（ｅ）のように、同様にしてバッファ領域１１１に書き込んだエンコード済みデータ９１を転送する動作（Ｓ１７）を繰り返し、クライアントはこれを受信し、再生する動作（Ｃ１５）を繰り返す。

これによれば、クライアントは、通常の蓄積コンテンツについて配信を受ける場合と同様の手順（Ｃ１１〜Ｃ１５）により、放送コンテンツについてのライブ配信を受けることができる。

なお、本発明は上述した形態に限定されることなく、適宜変形して実施することができる。たとえば、上述においては言及しなかったが、クライアントが図１１中の処理Ｃ１５により再生を行っているときに、サーバが「ＦＭ８０．００ＭＨｚ」の受信を停止した場合には、クライアントに対してデータエラーコードを送信し、ファイル「ＦＭ８０．００ＭＨｚ．ｍｐ３」を削除するようにしてもよい。

また、上述においては、ユーザによる再生指示（図１１のＣ１１）の前に、再生の指示がなされる放送コンテンツについての放送の受信が開始される必要がある（図１１のＳ１１）。そこで、クライアントは、再生指示があった場合には、予め再生指示があった放送コンテンツをサーバに通知しておき、サーバにおいてその放送コンテンツの配信の準備が完了した後（図１１のＳ１３）、放送コンテンツの転送要求（図１１のＣ１２）を行うようにしてもよい。

本発明の一実施形態に係るホームネットワークの構成を示すブロック図である。 図１のホームネットワークにおけるサーバの構成の一例を示すブロック図である。 図１のホームネットワークにおけるクライアントの構成の一例を示すブロック図である。 図１のホームネットワークにおけるクライアントの構成の他の例を示すブロック図である。 図１のホームネットワークにおけるクライアントにおいて音楽コンテンツを再生する操作が行われる場合の操作画面の変化を示す図である。 図１のホームネットワークにおけるクライアントにおいてＦＭ放送を受信する操作が行われる場合の操作画面の変化を示す図である。 図１のホームネットワークにおけるクライアントにおいて動画を再生する操作が行われる場合の操作画面の変化を示す図である。 図１のホームネットワークにおけるクライアントにおいてＴＶ放送を受信する操作が行われる場合の操作画面の変化を示す図である。 他のクライアントのためにサーバが既に放送を受信中の場合における図６（ｅ）及び図８（ｅ）に対応する画面の一例を示す図である。 図１のホームネットワークにおけるサーバにおける処理の一部を示すフローチャートである。 図１０の処理をより詳細に示す図である。

符号の説明

１１：サーバ、１２：スピーカ、１３：クライアント、１４：クライアント、１５：ハブ、２１：処理部、２２：チューナ部、２３：ＥＥＰＲＯＭ、２４：フラッシュメモリ、２５：ＳＤＲＡＭ、２６：ＤＳＰ、２７：ネットワークコントローラ、２８：コネクタ、２９：操作部、３０：表示部、３１：処理部、３３：ＥＥＰＲＯＭ、３４：フラッシュメモリ、３５：ＳＤＲＡＭ、３６：ＤＳＰ、３７：ネットワークコントローラ、３８：コネクタ、３９：操作部、４０：表示部、４１：ＤＡコンバータ、４２：ＵＳＢコントローラ、４３：ＵＳＢ端子、４４：ディスクドライブ、４５：ハードディスクドライブ、９１：エンコード済みデータ、１１１：バッファ領域。

Claims (6)

1. 所定の放送局からの放送を受信する受信手段と、
   前記受信手段からの受信信号を順次所定形式のデータに変換して所定のバッファに順次書き込む書込み手段と、
   前記書込み手段により前記バッファに順次書き込まれるデータを順次読み出す読出し手段と、
   前記放送局に対応する名称のファイルを作成する作成手段と、
   前記作成手段により作成されたファイルと同じファイル名を指定した配信要求をクライアント装置から受信したとき、前記バッファに順次書き込まれるデータを順次読み出し、前記指定されたファイル名のファイルのデータとして前記クライアント装置に順次送信する送信手段とを具備することを特徴とするサーバ装置。
2. 前記バッファはリングバッファ構成のものであり、前記順次の書込みにおける各書込み時には、書き込んだデータ量の分だけ書込みポインタのアドレスが進められ、前記順次の読出しにおける各読出し時には読出しポインタのアドレスから書込みポインタのアドレスまでのデータが読み出されるとともに、そのアドレスまで読出しポインタのアドレスが進められることを特徴とする請求項１に記載のサーバ装置。
3. 前記作成手段が作成するファイルの名称は、前記放送局を特定する文字列に対し、前記データ形式を表す拡張子を結合して構成されるものであることを特徴とする請求項１又は２に記載のサーバ装置。
4. 前記放送局に対応する名称を、前記配信要求において指定することができるファイル名として、前記クライアントに通知する手段を有することを特徴とする請求項１〜３のいずれか１項に記載のサーバ装置。
5. 請求項１〜４のいずれかのサーバ装置における各手段としてコンピュータを機能させることを特徴とするプログラム。
6. サーバ装置におけるクライアント装置へのコンテンツ配信方法であって、
   所定の放送局からの放送を受信し、受信データを所定の形式に変換しながらリングバッファに順次書き込む書込み工程と、
   前記放送局に対応する名称のファイルを作成する作成工程と、
   前記作成工程の後、前記書込み工程の実施中に、前記作成工程で作成したファイルと同じファイル名を指定した配信要求をクライアント装置から受信したとき、前記リングバッファに順次書き込まれるデータを順次読み出し、前記指定されたファイル名のファイルのデータとして前記クライアント装置に順次送信する送信工程とを具備することを特徴とするコンテンツ配信方法。

Images