(57)【要約】【課題】ネットワークを介して受信したコンテンツを再生し表示するコンテンツ受信装置において、ユーザが視聴していないにも関わらず、コンテンツのプレビュー再生が継続し、ネットワーク帯域が無駄に占有されることを防ぐ。【解決手段】プレビュー再生と全画面再生を含む、複数の再生の形態を持つコンテンツ受信装置において、受信したコンテンツをプレビュー再生の形態で表示する場合には、コンテンツの受信を開始してから一定時間が経過すると、コンテンツの受信を停止する。【選択図】図６
2008263412.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続されたコンテンツ送信装置からコンテンツを受信する受信部と、前記受信したコンテンツの映像を表示するウインドウのサイズが異なる複数の表示形態を有する前記コンテンツの映像を再生し表示する出力部と、前記出力部が表示する複数の表示形態のうち特定の表示形態においては前記コンテンツの受信を停止するように前記受信部に対して指示する再生制御部とを備えることを特徴とするコンテンツ受信装置。
【請求項２】
前記再生制御部は、前記特定の表示形態において前記コンテンツの受信を開始してから所定の時間が経過したことを検出した際に、前記コンテンツの受信を停止するように前記受信部に対して指示することを特徴とする請求項１に記載のコンテンツ受信装置。
【請求項３】
前記再生制御部は、前記特定の表示形態において前記出力部が表示する前記コンテンツが視聴されているか否かを判断し、前記コンテンツが視聴されていないと判断した場合に前記コンテンツの受信を停止するように前記受信部に対して指示することを特徴とする請求項１記載のコンテンツ受信装置。
【請求項４】
前記コンテンツ再生装置は、さらにコンテンツ再生に関する指示を受け付ける入力部を備え、前記再生制御部は、前記特定の表示形態において前記入力部からの入力があるか否かを検出し、所定の時間入力がないことが検出された場合に前記コンテンツが視聴されていないと判断することを特徴とする請求項３記載のコンテンツ受信装置。
【請求項５】
ネットワークを介して接続されたコンテンツ受信装置に対してコンテンツを送信する送信部と、前記コンテンツ受信装置が前記コンテンツを表示しているウインドウのサイズを取得し、前記ウインドウのサイズが特定の表示形態である場合には、前記コンテンツの送信を停止するように前記送信部に対して指示する送信制御部とを備えることを特徴とするコンテンツ送信装置。
【請求項６】
前記送信制御部は、前記特定の表示形態において前記コンテンツの送信を開始してから所定の時間が経過したことを検出した際に、前記コンテンツの送信を停止するように前記送信部に対して指示することを特徴とする請求項５に記載のコンテンツ送信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してＡＶコンテンツの視聴を行うためのコンテンツ受信装置、およびコンテンツ送信装置に関する。
【背景技術】
【０００２】
近年、ネットワークを介したコンテンツの授受が盛んに行われている。宅内ＬＡＮを構築すれば、例えばパソコンやハードディスク（以下、ＨＤＤ）レコーダに蓄積したＡＶコンテンツを、別の部屋にあるテレビやＤＶＤプレーヤからストリーミング再生することが可能になる。以下では、このようにコンテンツを蓄積し送信する機器をサーバ、コンテンツを受信し再生する機器をクライアントと呼ぶ。
【０００３】
ネットワークを介してコンテンツの視聴を行う際の手順は以下のとおりである。
【０００４】
まず、クライアントはネットワークに接続されているサーバを検索する。通信プロトコルとしてＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）を使用する場合には、機器検索にはＭ−ＳＥＡＲＣＨのコマンドを使用する。Ｍ−ＳＥＡＲＣＨ要求を受信したサーバは、Ｍ−ＳＥＡＲＣＨ応答をクライアントに返すので、これによりネットワーク内に接続されているサーバを発見することができる。
【０００５】
サーバが複数台見つかった場合には、発見したサーバの中から、コンテンツを取得する機器を１台選択する。ここでの選択は、クライアントを操作するユーザによって選択されてもよいし、クライアントの機器において自動的に選択してもよい。
【０００６】
次に、選択した機器に対して、コンテンツ一覧情報取得要求を送信し、サーバが保持しているコンテンツに関する属性情報を取得する。コンテンツに関する属性情報としては、例えば録画コンテンツであれば、録画した放送番組の番組名、録画開始時刻、録画終了時刻、録画時間、チャンネル番号、録画モード等の情報がある。通信プロトコルとしてＵＰｎＰを使用する場合には、コンテンツ一覧情報取得要求は、ＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ）のＢｒｏｗｓｅアクション要求に相当する。ＵＰｎＰでは、コンテンツの属性情報はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）の形式で記述され、Ｂｒｏｗｓｅアクション応答としてサーバからクライアントへ通知される。
【０００７】
クライアント側では取得したコンテンツ一覧情報をモニタ画面に表示し、ユーザがその中から見たいコンテンツを選択して通常再生を開始する。ユーザからのコンテンツの再生要求は、クライアントからのコンテンツ取得要求としてサーバへ送信される。通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を使用する場合には、コンテンツ取得要求はＨＴＴＰのＧＥＴリクエストに相当する。コンテンツ取得要求を受信したサーバは、コンテンツの実データをクライアントへと送信する。ＨＴＴＰでは、これらはＧＥＴリクエストに対するレスポンスとして送信される。レスポンスを受信したクライアントがデータの復号を行うことで、クライアントでのコンテンツの視聴が可能となる。
【０００８】
ＨＤＤレコーダのような録画再生機器では、コンテンツ一覧情報を表示する際に、同時に子画面でプレビュー再生を行うなどして、コンテンツの映像を表示することが一般的に行われている。プレビュー画面の一例を図１に示す。図１の例では、右側にＨＤＤに蓄積されているコンテンツを一覧として表示し、その中でフォーカスが当たっている（選択されている）コンテンツの映像を左側のプレビュー画面で再生表示している。これは、タイトル名や録画日時等の情報だけでなく、実際に映像の内容を表示することで、ユーザがコンテンツ一覧の中から視聴したいコンテンツを容易に選択できるようにすることを目的としたものである。
【０００９】
その後、選択しているコンテンツを視聴したい場合には、リモコンの再生開始ボタンを押す等して、プレビュー再生から全画面再生へと切り替える。全画面再生の例を図２に示す。表示される映像の内容は、プレビュー再生の場合と同じであるが、映像が全画面で表示されるなど表示サイズが異なり、番組を視聴するのに適した状態で表示される。
【００１０】
ネットワークを介したプレビュー再生を行う場合には、全画面再生を行う場合と同様に、クライアントからのコンテンツ取得要求の送信と、それを受信したサーバからのコンテンツデータの送信が必要である。これは、クライアントでの表示形態が、プレビュー再生か、全画面再生かに関わらず、同様に行われる処理である。つまり、プレビュー再生の場合に注目して言えば、全画面再生の場合と比べて、表示される画面のサイズが小さいにも関わらず、全画面再生の場合と同じだけのコンテンツのデータがネットワーク上に流れていることになる。これは、ネットワーク資源の観点から見れば非効率的である。
【００１１】
ネットワーク資源の有効利用という点では、送信するコンテンツのビットレートを変換する方法がいくつか提案されている（例えば、特許文献１）。先ほどの例に適用すれば、例えば、全画面再生の場合にはコンテンツのデータをそのまま送信し、プレビュー再生の場合にはコンテンツを低ビットレートへと変換してから送信する。プレビュー再生で表示される画面のサイズは小さいため、レートを下げて映像を粗くしたとしても、ユーザがその変化に気づくことは少ない。つまり、ユーザに違和感を持たせることなく、ネットワークの負荷を低減することができる。
【特許文献１】特開２００５−３１８０５７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、送信するコンテンツのビットレートを変換する等してネットワーク負荷の低減を図った場合であっても、一定のビットレートのコンテンツが送信されていることには変わりはない。つまり、プレビュー再生が行われている間は、多かれ少なかれ、一定の帯域が占有されることになる。
【００１３】
一方、プレビュー再生が行われるのは、図１に示すようなコンテンツ一覧表示画面のときである。例えばユーザが、この画面を表示した状態でその場を離れる等して、そのまま長時間放置されるようなケースは容易に考えられる。そのような場合でも、上記の方法であれば一定のネットワーク帯域は無駄に占有されてしまうことになる。つまり、プレビュー再生状態で放置された場合に、ユーザが実際に視聴している、していないに関わらず、ネットワーク帯域が無駄に占有されるという課題がある。
【００１４】
本発明は、以上のような問題点を鑑みてなされたものであり、その目的とするところは、無駄なネットワーク帯域の占有を防ぐコンテンツ受信装置、およびコンテンツ送信装置を提供することである。
【課題を解決するための手段】
【００１５】
上記課題を解決し上記目的を達成するために、本発明のコンテンツ受信装置は、
ネットワークを介して受信したコンテンツを再生し表示するコンテンツ受信装置であって、
前記コンテンツ受信装置は、前記受信したコンテンツを表示する表示手段を備え、
前記表示手段は、少なくとも前記受信したコンテンツの映像を表示するウインドウのサイズが異なる、複数の表示形態を有し、
前記複数の表示形態のうち、特定の表示形態において映像を表示する場合には、コンテンツの受信を停止することを特徴とする。
【００１６】
また、前記コンテンツ受信装置は、
特定の時間が経過したことを検出するタイマ手段を備え、
前記タイマ手段において、コンテンツの受信を開始してから一定時間経過したことを検出して、コンテンツの受信を停止することを特徴とする。
【００１７】
また、前記コンテンツ受信装置は、
前記表示手段が表示するコンテンツが視聴されているか否かを特定する視聴情報特定手段を備え、
前記視聴情報特定手段において、コンテンツが視聴されていないと特定されたことをもって、コンテンツの受信を停止することを特徴とする。
【００１８】
また、前記コンテンツ受信装置は、
外部からの入力操作を受け付ける入力手段と、
特定の時間が経過したことを検出するタイマ手段と
を備え、
前記視聴情報特定手段は、
前記タイマ手段において、前記入力手段からの入力操作が一定時間行われなかったことをもって、コンテンツが視聴されていないと特定することを特徴とする。
【００１９】
また、本発明のコンテンツ送信装置は、コンテンツ受信装置に対して、ネットワークを介してコンテンツを送信するコンテンツ送信装置であって、
前記コンテンツ受信装置は、少なくとも受信したコンテンツの映像を表示するウインドウのサイズが異なる、複数の表示形態を有し、
前記コンテンツ送信装置は、前記コンテンツ受信装置の表示形態に関する情報を取得する、表示情報取得手段を備え、
前記表示情報取得手段において取得した情報が、特定の表示形態を示す場合には、コンテンツの送信を停止することを特徴とする。
【００２０】
また、前記コンテンツ送信装置は、
特定の時間が経過したことを検出するタイマ手段を備え、
前記タイマ手段において、コンテンツの送信を開始してから一定時間経過したことを検出して、コンテンツの送信を停止することを特徴とする。
【００２１】
上述のように構成することにより、プレビュー再生状態で放置された場合には自動的にコンテンツの伝送が中断されるため、ネットワークの負荷をなくすことができる。
【発明の効果】
【００２２】
本発明は、ネットワークを介したコンテンツの送受信に関して、特にプレビュー再生を行う際に不必要なデータの伝送をなくすことにより、ネットワークの負荷を低減することができる。
【発明を実施するための最良の形態】
【００２３】
以下に、本発明を実施するための最良の形態を、図面を参照して説明する。
【００２４】
（実施の形態）
まず、本発明の実施の形態におけるネットワークの構成図を、図３を用いて説明する。
【００２５】
図３は、本発明の実施の形態におけるコンテンツ送信装置、およびコンテンツ受信装置の接続例を示した図である。Ｅｔｈｅｒｎｅｔ（登録商標）ケーブルを介した宅内ＬＡＮで、通信回線１０を介して、コンテンツ送信装置１００と、コンテンツ受信装置２００とが接続されている。通信回線１０の通信プロトコルにはＴＣＰ／ＩＰを用いる。
【００２６】
コンテンツ送信装置１００は、例えば、基地局からの放送を受信し復調する機能を備えたＳＴＢ（セットトップボックス）、ＨＤＤレコーダ等である。また、コンテンツ送信装置１００は、宅内ＬＡＮを介してパケット通信を行う機能を有している。コンテンツ送信装置１００は、番組を録画するなどして蓄積したコンテンツを、通信回線１０を介して送信することができる。
【００２７】
コンテンツ受信装置２００は、宅内ＬＡＮを介してパケット通信を行う機能を備えたＳＴＢ、テレビ等である。コンテンツ受信装置２００は、通信回線１０を介して受信したコンテンツを、視聴したり蓄積したりすることが可能である。
【００２８】
なお、本発明の実施の形態において、コンテンツデータの伝送には、通信プロトコルとしてＨＴＴＰを使用する。コンテンツ受信装置２００は、コンテンツ取得要求としてＨＴＴＰのＧＥＴリクエストを送信する。リクエストを受信したコンテンツ送信装置１００は、ＨＴＴＰレスポンスとともに、管理情報やコンテンツ等のデータを送信する。また、コンテンツの録画時間やタイトル名など、コンテンツに関する属性情報の送受信にはＵＰｎＰを使用する。
【００２９】
次に、本発明の実施の形態におけるコンテンツ送信装置１００の構成を、図４を用いて説明する。
【００３０】
図４は、本発明の実施の形態におけるコンテンツ送信装置１００の構成を示す図である。コンテンツ送信装置１００は、送信部１０１と、受信部１０２と、送信制御部１０３と、管理情報生成部１０４と、属性情報生成部１０５と、コンテンツ蓄積部１０６とを備える。
【００３１】
コンテンツ蓄積部１０６は、ＨＤＤやＤＶＤ等の読み書き可能な記録媒体である。コンテンツ蓄積部１０６には、録画した放送番組や、ＶＯＤ（ビデオ・オン・デマンド）等によりユーザが購入したコンテンツが蓄積されている。
【００３２】
コンテンツ送信装置１００は、ネットワークを介して、蓄積したコンテンツを送信する機能を備える。ここではＰＵＬＬ型、すなわち、受信側からの要求に基づいて、送信側がコンテンツを送信するモデルを例に説明する。
【００３３】
まず、受信部１０２においてクライアントからの要求を受信する。受信した要求が、コンテンツに関する属性情報を取得する要求（つまり、ＵＰｎＰのＢｒｏｗｓｅアクション要求）であれば、属性情報生成部１０５において、コンテンツの属性情報をリストとして作成し、送信部１０１を介して送信する。属性情報とは、例えばコンテンツのタイトル名、録画開始時刻、録画終了時刻、録画時間、チャンネル番号、録画モード等のように、コンテンツの内容に関する情報を指す。ここではこれらの属性情報がＸＭＬの形式で記述され、Ｂｒｏｗｓｅアクション応答として送信される。
【００３４】
受信した要求が、コンテンツの管理情報を取得する要求（つまり、ＨＴＴＰのＧＥＴリクエスト）であれば、管理情報生成部１０４において、コンテンツの管理情報を作成し、送信部１０１を介して送信する。管理情報とは、コンテンツのデータの構成に関する情報を指す。具体的には、ＭＰＥＧ動画コンテンツの構成情報として、ＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅｓ）やＩフレームのバイト位置の情報のように、コンテンツの内部構成に関して記載されたものである。
【００３５】
受信した要求が、コンテンツ自身のデータを取得する要求（つまり、ＨＴＴＰのＧＥＴリクエスト）であれば、コンテンツ蓄積部１０６からコンテンツのデータを読み出す。要求が管理情報に対するものであるか、コンテンツデータに対するものであるかは、ＧＥＴリクエストに含まれたＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）で識別する。送信部１０１では、コンテンツ蓄積部１０６から読み出したコンテンツデータをＨＴＴＰレスポンスとして送信する。これらの送信の制御は、送信制御部１０３において行う。
【００３６】
次に、本発明の実施の形態におけるコンテンツ受信装置２００の構成を、図５を用いて説明する。
【００３７】
図５は、本発明の実施の形態におけるコンテンツ受信装置２００の構成を示す図である。コンテンツ受信装置２００は、送信部２０１と、受信部２０２と、再生制御部２０３と、管理情報解析部２０４と、属性情報解析部２０５と、復号部２０６と、出力部２０７と、入力部２０８とを備える。
【００３８】
コンテンツを視聴したいユーザがリモコン操作を行うと、入力部２０８を介して命令が入力される。まず、サーバに蓄積されているコンテンツを知るために、コンテンツに関する属性情報を取得する。送信部２０１を介して属性情報取得要求（つまり、Ｂｒｏｗｓｅアクション要求）を送信すると、受信部２０２を介して属性情報（つまり、Ｂｒｏｗｓｅアクション応答）を受信する。受信した属性情報はＸＭＬの形式で記述されているので、属性情報解析部２０５においてこれを解析し、出力部２０７に出力する。出力部２０７は映像を表示するモニタ等である。ここではコンテンツに関するタイトル名や録画時間等の情報が一覧として画面上に表示される。
【００３９】
出力部２０７における画面表示例は図１のようなものである。画面には、サーバに蓄積されているコンテンツの録画日、録画開始時刻、チャンネル番号、タイトル名といった情報が一覧で表示される。また、表示画面にはプレビュー再生用の子画面があり、フォーカスが当たっているコンテンツの映像が表示される。この状態から、ユーザがリモコン操作を行う等してフォーカスを当てるコンテンツを切り替えると、子画面で表示されるコンテンツが切り替わる。また、ユーザがリモコン操作を行う等してコンテンツの通常再生を開始すると、画面が切り替わり、選択したコンテンツの全画面再生が開始する。全画面再生の画面表示例は、図２に示すとおりである。出力部２０７には、受信したコンテンツを表示する領域（ウインドウ）の大きさは、例えば図１、図２に示したように全画面再生やプレビュー画面再生など、またこれらに限られずに複数の形態を有する。
【００４０】
コンテンツの再生は、全画面再生か、子画面でのプレビュー再生かに関わらず、以下の手順により行われる。まず、コンテンツの取得に先立ち、コンテンツに関する管理情報を取得する。管理情報の取得要求（つまり、ＨＴＴＰのＧＥＴリクエスト）は送信部２０１を介して送信し、サーバから送信された管理情報は受信部２０２を介して受信する。受信した管理情報を、管理情報解析部２０４において解析することにより、コンテンツの内部構成に関する情報を知ることができる。
【００４１】
早送りや巻き戻し等の特殊再生は、管理情報解析部２０４において得られた情報に基づいて、取得するデータの範囲を指定することにより実現できる。具体的には、例えばコンテンツのＩピクチャのみを連続で取得して表示することにより早送り再生や巻き戻し再生を実現する。あるいはＩピクチャの取得間隔を切り替えることで、特殊再生の速度を変化させることも可能である。
【００４２】
なお、特殊再生を行わない場合など、コンテンツの内部構成に関する情報を知る必要がない場合には、必ずしも管理情報を取得する必要はない。また、サーバがコンテンツの管理情報を持たない場合や、解析できないフォーマットの管理情報しか持たない場合も、管理情報を取得する必要はない。
【００４３】
次に、選択されたコンテンツの実データをサーバから取得する。サーバに対するコンテンツ取得要求（つまり、ＨＴＴＰのＧＥＴリクエスト）は、送信部２０１を介して送信する。サーバから送信されたコンテンツは、受信部２０２を介して受信する。受信したデータは、復号部２０６で復号したのち、出力部２０７に出力する。これにより、受信したコンテンツを映像や音声として出力することができる。これらの制御は、再生制御部２０３において行われる。ここで、復号部２０６は、データを復号するデコーダ等である。なお、出力部２０７はコンテンツを記録するためのＨＤＤやＤＶＤ等の蓄積メディアであってもよい。
【００４４】
プレビュー再生中の動作について詳細に説明するために、図６を用いる。図６は、プレビュー再生中におけるコンテンツ受信装置２００の動作手順をフローチャートで示したものである。
【００４５】
コンテンツ受信装置２００は、まずサーバとの間でＴＣＰのコネクションを確立する（Ｓ１）。次に、サーバに対して管理情報取得要求を送信し（Ｓ２）、サーバから送信された管理情報を受信する（Ｓ３）。次に、サーバに対してコンテンツ取得要求を送信する（Ｓ４）。コンテンツ受信装置２００は、サーバから送信されるコンテンツを受信する（Ｓ５）。このとき、コンテンツ受信装置２００は、一般的にはコンテンツ受信用のバッファを用意しておき、特定のサイズ単位での受信処理を繰り返し実行する。
【００４６】
一定サイズ分の受信が完了すると、サーバから指定されたサイズ分の受信が終了したかどうかを判断する（Ｓ６）。全コンテンツの受信が完了すれば、ＴＣＰのコネクションを切断し（Ｓ９）、コンテンツの受信を終了する。一方、まだサーバから送信されるコンテンツが残っている場合はＳ７へと移行する。
【００４７】
Ｓ７では、現在受信しているコンテンツの表示形態が、全画面再生か、プレビュー再生かを判定する。全画面再生である場合は、全コンテンツの受信が完了するまで、Ｓ５での受信処理を繰り返し実行する。一方、全画面再生でない場合、一定時間が経過すると自動的にコネクションを切断し、コンテンツの受信を終了する。すなわち、Ｓ７においてＮｏであれば、再生開始から一定時間経過したかどうかを判断し（Ｓ８）、時間が経過していればコネクションを切断してコンテンツの受信を終了し（Ｓ９）、時間が経過していなければ再びＳ５へと移行しコンテンツの受信を継続する。
【００４８】
このように、全画面再生であればコンテンツの受信を継続して行い、プレビュー再生であれば一定時間経った時点でコンテンツの受信を終了する。これにより、無駄なネットワーク帯域の占有を防ぎ、ネットワーク全体で資源を有効利用することが可能になる。
【００４９】
なお、サーバから送信するコンテンツのサイズが指定されない場合もあるが、その場合は、サーバからコネクションが切断された時点ですべてのコンテンツの送信が完了したものと判断することができる。すなわち、Ｓ６における判定では、サーバからコネクションを切断された場合に、全コンテンツの受信が完了したものとして判断すればよい。
【００５０】
コンテンツ伝送中でのコネクションの切断は、クライアント側からの切断に限らず、サーバ側から切断してもよい。以下では、サーバから切断する場合の動作の手順について、図７を用いて説明する。
【００５１】
ここで、前提として、コンテンツ送信装置１００は、コンテンツ受信装置２００が全画面再生でコンテンツを受信しているか、プレビュー再生でコンテンツを受信しているかといった情報をあらかじめ取得しておくものとする。通知の方法としては、ＨＴＴＰのリクエストやレスポンスに独自拡張のヘッダを追加して通知する方法や、ＵＰｎＰのアクション送受信において独自拡張したパラメータフィールドを追加して通知する方法等が考えられる。なお、コンテンツの伝送中にプレビュー再生から全画面再生へ切り替えられたり、またその逆の切り替えが行われたりすることも想定されるが、その場合は切り替えのタイミングでクライアントからサーバに情報が通知されるなどして、コンテンツ送信装置１００は常に最新の情報を保持しているものとする。
【００５２】
まず、コンテンツ送信装置１００はクライアントとの間でＴＣＰのコネクションを確立する（Ｓ１１）。この状態でクライアントからの要求を待ち受ける。
【００５３】
クライアントから管理情報取得要求を受信すると（Ｓ１２においてＹｅｓ）、管理情報を送信し（Ｓ１３）、再び待ち受け状態へと遷移する。
【００５４】
クライアントからコンテンツ取得要求を受信すると（Ｓ１４においてＹｅｓ）、コンテンツを送信する（Ｓ１５）。このとき、コンテンツ送信装置１００は、一般的にはコンテンツ送信用のバッファを用意しておき、特定のサイズ単位での送信処理を繰り返し実行する。
【００５５】
一定サイズ分の送信が完了すると、すべてのコンテンツの送信が終了したかどうかを判断する（Ｓ１６）。全コンテンツの送信が完了すれば、ＴＣＰのコネクションを切断し（Ｓ１９）、コンテンツの送信を終了する。一方、まだサーバから送信されるコンテンツが残っている場合はＳ１７へと移行する。
【００５６】
Ｓ１７では、現在送信しているコンテンツのクライアント側での再生形態が、全画面再生か、プレビュー再生かを判定する。全画面再生である場合は、全コンテンツの送信が完了するまで、Ｓ１５での送信処理を繰り返し実行する。一方、全画面再生でない場合、一定時間が経過すると自動的にコネクションを切断し、コンテンツの受信を終了する。すなわち、Ｓ１７においてＮｏであれば、再生開始から一定時間経過したかどうかを判断し（Ｓ１８）、時間が経過していればコネクションを切断してコンテンツの送信を終了し（Ｓ１９）、時間が経過していなければ再びＳ１５へと移行しコンテンツの送信を継続する。
【００５７】
このように、全画面再生であればコンテンツの送信を継続して行い、プレビュー再生であれば一定時間経った時点でコンテンツの送信を終了する。これにより、無駄なネットワーク帯域の占有を防ぎ、ネットワーク全体で資源を有効利用することが可能になる。
【００５８】
なお、本発明の実施の形態において、プレビュー再生中に、コンテンツ送信装置１００やコンテンツ受信装置２００がコネクションを切断するまでの時間には特に制限を設けないものとする。ただし、この時間が長くなるとネットワークへの負荷が増大し、短すぎるとユーザの利便性を低下させるという問題があるので、これら双方を考慮して最適な値に設定されることが望ましい。
【００５９】
また、プレビュー画面での視聴が実際に必要かどうかは、コンテンツの総数や録画時間といった要因にも関係して変動する可能性があるため、これらの値に応じて、切断までの時間を適応的に変化させるといった使い方を行うことも可能である。具体的には、例えばコンテンツが１つしかないなど、コンテンツの総数が少ない場合には、プレビュー再生の必要性が低いため、切断までの時間を短く設定するといった使い方が可能である。あるいは、コンテンツの録画時間の１０％をプレビュー再生の切断時間に設定するなどすれば、録画時間に応じてプレビュー再生の時間も変動させることができる。
【００６０】
なお、本発明の実施の形態において、コンテンツ受信装置２００がコンテンツの受信の終了を判断する要因は、コンテンツの受信を開始してからの経過時間に限定しない。さらに言えば、ユーザがプレビュー再生の画面を視聴していないことを検出できることが望ましい。例えば、ユーザからのリモコン操作が一定時間行われなかったことをもって、コンテンツの受信を終了してもよい。そのような場合には、コンテンツの受信を終了する前に、プレビュー再生を表示している画面にメッセージを表示するなどして、ユーザのリモコン操作を促すようなメッセージを表示することが望ましい。
【００６１】
また、本発明の実施の形態において、コンテンツ受信装置２００がコンテンツの受信を終了した後のプレビュー再生画面は、ユーザが違和感を持たない形で表示されることが望ましい。例えば、プレビュー再生を停止した旨をメッセージとして表示して、ユーザに通知するなどしてもよい。あるいは、停止するまでの間に受信したコンテンツのデータを一時的に記憶しておき、停止後は一時記憶したコンテンツを再度先頭からプレビュー画面に再生表示し、以降そのコンテンツを繰り返し再生表示するといった方法も考えられる。
【００６２】
また、本発明の実施の形態において、プレビュー再生を停止する際の動作は、ＴＣＰコネクションの切断に限定しない。例えば、コンテンツ受信装置であれば、ＴＣＰのコネクションは維持したままの状態で、コンテンツを受信せずにウインドウサイズ０のＡＣＫパケットを送信するなどしてもよい。そのような場合、ネットワーク上にコンテンツのデータが流れることはないので、ネットワークの負荷を抑えるという、同等の効果は得ることができる。
【産業上の利用可能性】
【００６３】
本発明のコンテンツ送信装置、およびコンテンツ受信装置は、ネットワークを介してＡＶコンテンツの送受信を行うＨＤＤレコーダやＳＴＢ等として有用である。
【図面の簡単な説明】
【００６４】
【図１】プレビュー再生の画面例を表す図
【図２】全画面再生の画面例を表す図
【図３】本発明の実施の形態におけるネットワークの構成図
【図４】本発明の実施の形態におけるコンテンツ送信装置の構成図
【図５】本発明の実施の形態におけるコンテンツ受信装置の構成図
【図６】本発明の実施の形態におけるコンテンツ受信装置の動作手順を示すフローチャート
【図７】本発明の実施の形態におけるコンテンツ送信装置の動作手順を示すフローチャート
【符号の説明】
【００６５】
１０  通信回線
１００  コンテンツ送信装置
１０１  送信部
１０２  受信部
１０３  送信制御部
１０４  管理情報生成部
１０５  属性情報生成部
１０６  コンテンツ蓄積部
２００  コンテンツ受信装置
２０１  送信部
２０２  受信部
２０３  再生制御部
２０４  管理情報解析部
２０５  属性情報解析部
２０６  復号部
２０７  出力部
２０８  入力部
【図１】
2008263412.tif 000003
【図２】
2008263412.tif 000004
【図３】
2008263412.tif 000005
【図４】
2008263412.tif 000006
【図５】
2008263412.tif 000007
【図６】
2008263412.tif 000008
【図７】
2008263412.tif 000009