JP4835170B2

JP4835170B2 - コンテンツ共有装置及びコンテンツ共有方法

Info

Publication number: JP4835170B2
Application number: JP2006018366A
Authority: JP
Inventors: 貴之山本; 浩道伊藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-04-08
Filing date: 2006-01-27
Publication date: 2011-12-14
Anticipated expiration: 2026-01-27
Also published as: JP2006314075A; US20060230142A1

Description

本発明は、ネットワークを介してコンテンツを快適に共有するコンテンツ共有システム及びコンテンツ共有装置に関するものである。

家庭を中心に普及したVTR (Video Tape Recorder)やDVD (Digital Versatile Disc)レコーダ、HDD (Hard Disk Drive)レコーダは、主に放送波を記録して再生し、もしくはレンタルビデオ店やビデオ販売店でレンタル／購入したコンテンツを再生し、映像／音声をテレビに出力する使用方法が一般的である。
これらレコーダやテレビは、普及と共に急速に低価格化し、一家庭で複数台保持することが一般的となった。また、特に一般家庭向けに、IEEE1394やベンダー独自の通信規格などによる通信を介して、数メートル以上離れた場所のテレビからレコーダを操作するといった製品が販売されている。
一方、インターネットの普及に伴い、家庭内ＩＰ (Internet Protocol)ネットワークが一般化してきた。

このような中、家庭内のＩＰネットワーク上でAV (Authorized Version)コンテンツを送受信する試みがなされ、特にDLNA (Digital Living Network Alliance)といった規格の登場により家庭内ＩＰネットワークを介した家庭内コンテンツ共有の普及が現実味を帯びてきた。
家庭内コンテンツ共有は、一家庭に複数台存在するHDDレコーダやテレビをネットワークで結び、相互に共有する仕掛けである。本技術により、ＩＰ通信可能なネットワーク環境のみでコンテンツを共有することができ、例えばリビングで寝室のレコーダに記録したコンテンツを再生することが簡単に可能となる。

しかし、ネットワーク対応コンテンツレコーダを用いて、ネットワークを介してコンテンツを再生する場合、送信元のコンテンツを再生するまでに掛かる時間と、ネットワーク伝送に掛かる時間と、受信してから再生までに掛かる時間の総和がユーザにとっての待ち時間となるため、例えばアナログテレビと比較して反応が非常に遅い。
一方、近年の省エネルギー意識の高まりと共に、レコーダに拘らず待機電力が問題となっており、不使用時にはスリープモードとすることが求められている。スリープモードでは録画予約機能のみが起動し、CPU (Central Processing Unit)は必要最小限起動する。

ネットワークを介してスリープモードのWOL (Wake On LAN)対応レコーダからコンテンツを取得するためには、通常マジックパケットと呼ばれる特殊なＩＰパケットを、コンテンツを保持するレコーダへ送信し、レコーダを起動した後、レコーダからコンテンツを取得する必要がある。
レコーダの起動時間は数秒〜数十秒であることが一般的である。ネットワーク機能の起動は特に時間の掛かる処理であり、例えばDHCP (Dynamic Host Configuration Protocol)サーバを利用している場合などは１０秒以上起動に時間が掛かることが普通である。つまり、スリープモードのレコーダからコンテンツを取得するまでには、数十秒以上の時間が必要となる。

このような問題を解決するためには、通常キャッシングもしくはデータの先読みダウンロード(又は受信)という手段が用いられる。
キャッシングとは、一度使用したデータの一部または全部を保持しておき、次に同じデータを使用する場合に、キャッシュから取り出すことにより速度の向上を図る一般的な手法である。
コンテンツの先読み受信の例として特許文献１にコンテンツを先読みして再生する方法が述べられている。

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

キャッシュの仕組みは、CPUやウェブブラウザなどで一般的に用いられている。この方法は、キャッシュのヒット率が高い場合には極めて有効であるが、キャッシュはヒット率を向上させるためには統計的処理が必要であり、少数のコンテンツをキャッシュにヒットさせるには、全てのコンテンツをキャッシュしなければならないという本質的欠点があった。
つまり、キャッシュの方法を用いてスリープ状態のレコーダからコンテンツを高速に取得するためには、再生済みのコンテンツをすべて保持していなければならなくなる。また、未再生のコンテンツはキャッシュが存在しないため、高速に取得することができない。

このような問題を解決するために、データの先読みダウンロードでユーザ操作の前にコンテンツをダウンロードする方法が実現されている。先読みダウンロードとは、次にダウンロード（取得）すると予想されるデータを予めダウンロードする方法である。
例えばウェブブラウザの高速化ソフトウェアの一部は、この先読みを利用してリンク先のコンテンツをユーザ操作の前に取得する手法を採用している。

この先読み手法は、次のユーザ操作を的確に予測することが可能であれば、極めて有効な手段である。本手法においては、ユーザが入力する情報が多いほど次のユーザ操作を予測しやすい。また、ウェブブラウジングといった動作は、一般にコンテンツを取得した後、次の操作までにある程度の時間が存在するため、その間に先読みをしてコンテンツをダウンロードすることは効果的である。

しかし、先読み方法では、ユーザが装置を起動した直後は先読みが行われておらず、先読み方法を適用できないという欠点があった。また、先読みには多くのネットワーク帯域を消費するという欠点があった。つまり、先読みを利用した場合、操作側の端末がスリープ中のレコーダを予め起動しておき、予めコンテンツを取得する必要がある。これは、他の機器を不用意に起動し、コンテンツを取得するため、消費電力が多くなる点、とメモリやハードディスクなど記憶領域の消費が多くなる点で問題となる。

先読みの派生系として、ユーザが操作端末を起動すると、他のレコーダをすべて起動することが挙げられる。すると、起動時間を省略できるためネットワークを介したコンテンツ取得も比較的短時間で可能である。しかし、レコーダの数だけ消費電力が増加する問題がある。
また、スリープモードの際にネットワーク機能だけ起動する方法も考えられるが、殆ど使用しない機能のために常時動作することは望ましくない。

すなわち解決しようとする課題は、コンテンツ共有装置であるネットワーク対応コンテンツレコーダにおいて、ネットワークを介してコンテンツを再生するときに、コンテンツの送信側端末がスリープしていると、コンテンツの再生までに時間がかかる点である。

上記の課題を解決するため本発明は、例えば、特許請求の範囲に記載されるように構成すればよい。

本発明のレコーダは、サーバ側レコーダの起動に必要な時間分のコンテンツを予め共有する。このため、サーバ側のレコーダが起動するまでの間はクライアント側のレコーダに蓄積されたコンテンツを使用して再生し、サーバ側のレコーダが起動するとネットワークを介したコンテンツ送信によりコンテンツを再生することができ、クライアント側ではインデックスで指定されたコンテンツの再生の指示により瞬時に再生を開始することができるという効果を有する。
また、他の形態として本発明のレコーダは、サーバ側レコーダの起動に必要な時間分のコンテンツを予め別のレコーダに蓄積する。別のレコーダには、ネットワークを介して接続可能なレコーダのうち、起動している時間の割合が大きいものもしくは、起動時間が早いものを用いる。クライアント側の端末は、コンテンツが蓄積されているサーバ側レコーダが起動するまでの間は、別のレコーダに蓄積されたコンテンツを使用して再生し、サーバ側レコーダが起動するとネットワークを介したコンテンツ送信によりコンテンツを再生することができる。すると、クライアント側ではコンテンツの一部を蓄積しなくても、コンテンツの再生を瞬時に開始することができる利点がある。

以下、本発明の実施の形態について、図面を用いて説明する。

以下、本発明の実施例１を、図面を用いて説明する。
本発明では、ネットワークを介してサーバのコンテンツをクライアントで再生するにあたり、再生するコンテンツのインデックスをクライアントで選択してから映像を再生するまでの時間を短縮するという目的を、最小のクライアント側記憶領域の使用量で実現した。

図１は、本発明装置の実施例１の全体図である。１１０および１２０および１３０はネットワーク１００を介してコンテンツを共有するレコーダである。なお、コンテンツとは録画したテレビ番組や映画、ユーザが撮影した写真、ネットワークを介してダウンロードした音楽や、購入したCD (Compact Disc)からコピーした音楽などを含む。また、コンテンツは番組情報などコンテンツ自らの内容を示すデータなどを含んでもよい。共有のために、記録領域内にインデックス領域１１１とコンテンツ領域１１５を有する。
コンテンツ領域はコンテンツを記録する領域であり、例えばテレビ番組を録画した場合には本領域に記録する。インデックス領域はネットワークを介した共有のために、コンテンツのタイトルや内容、ネットワーク上の所在を示すURL (Uniform Resource Locator)などをインデックスとして保持する領域である。ネットワークに接続する全てのレコーダ間で、インデックスを同期し、同一のインデックスを持つ構成でもよい。
なお、図５はインデックスの例である。

１１２から１１４はコンテンツAAAおよびコンテンツBBBおよびコンテンツCCCの所在であるURLを示すインデックスである。例えばインデックス１１２では、コンテンツAAAはレコーダ１から取得できることがわかる。なお、１１２のURLは簡易的に表記したものであり、一般に使用されているURLのように階層化し、またファイル名やその他の情報などを記載しても良い。
１１６および１１７はコンテンツである。１１８は本発明の特長である即再生用コンテンツである。１１８は特にコンテンツCの先頭部分であり、即再生用コンテンツ長分の長さである。なお即再生用コンテンツとは、クライアント側でユーザが再生を指示した時に直ちに再生を開始するためにクライアント側内に保持するコンテンツである。即再生用コンテンツの長さである即再生用コンテンツ長は、サーバ側のコンテンツ送信準備が完了するまでの時間より長く設定する。

なお、サーバ側とはコンテンツを保持する側であり、クライアント側とはコンテンツを再生する側である。例えば図１において、コンテンツAAAについてはレコーダ１がサーバ側であり、レコーダ２およびレコーダ３がクライアント側である。コンテンツBBBも同様である。コンテンツCCCについてはレコーダ２がサーバ側であり、レコーダ１およびレコーダ３がクライアント側である。

図２および図３は、本発明装置の動作を示すフロー図である。図２は即再生用コンテンツをクライアント側が受信完了するまでを示し、図３は、コンテンツを再生する場合を示している。
まず、図２を用いて即再生用コンテンツを共有するまでのフローについて説明する。
サーバ側では、電源投入などにより処理を開始すると、レコーダが起動するために必要な起動時間を計測する（２０１）。ステップ２０１は図４にて詳しく説明する。また、ステップ２０１は電源投入時などに毎回実行しなくても良い。

次に、サーバ側はコンテンツを録画する（２０２）。本処理は、例えばテレビ番組の録画など、通常のレコーダのコンテンツ録画機能と同様である。次に、サーバ側はコンテンツのインデックスを作成する（２０３）。既にインデックスが存在する場合は、更新でも良い。
図１の１１２や図５はコンテンツのインデックスの例である。インデックスを作成／更新すると、サーバ側はクライアント側とインデックスを同期する（２０４および２１４）。インデックスの同期が生ずるタイミングは必ずしもインデックスを作成した直後でなくてもよく、定期的や、同期すべきインデックスがある程度蓄積された後、また決まった時間などでもよい。

また、クライアント側は別のコンテンツから見るとサーバ側になる場合があるので、その場合は同期のトリガは、クライアント側からかけられることになる。同期では、すべてのレコーダのインデックスが等しくなるようインデックスのコピーを行うが、目的に応じてその他の同期方法を導入しても良い。
例えば、レコーダ３にコンテンツCCCを再生させたくない場合、レコーダ３にコンテンツCCCのインデックスをレコーダ１およびレコーダ２が提供しない構成とする。すると、レコーダ３はコンテンツCCCの存在を知らないため、インデックスから再生できない。

次にクライアント側は、即再生用コンテンツの要求を送信する（２１５）。即再生用コンテンツの要求は、インデックスに即再生用コンテンツのURLが記載されている場合に、クライアント側が実行する。サーバ側が即再生用コンテンツ要求を受信すると（２０５）、サーバ側は起動時間計測から求められた、即再生用コンテンツ長のコンテンツを即再生用コンテンツとして送信する（２０６）。クライアント側は即再生用コンテンツを受信し、コンテンツ領域に保存する（２１６）。

次に、図３を用いてコンテンツを再生する場合のフローについて説明する。
クライアント側でユーザが、例えば図６のような操作画面を用いてインデックスを選択する（３１１）。すると、クライアント側は起動要求をサーバ側に送信する（３１２）。起動要求は起動の確認を兼ねても良い。例えば、サーバ側が起動要求を受信した時点で既に起動済みであった場合には、直ちにコンテンツを送信可能である。
この場合には、起動完了通知もしくは起動済みの通知をクライアント側に直ちに送信する。すると、クライアント側は即再生用コンテンツを再生せずに、サーバから送信されたコンテンツを直ちに再生することができる。この場合、クライアント側は３１３を実行せずに、３１５でコンテンツを先頭から要求する。

サーバ側は３０２において起動していなかった場合に、起動を開始する（３０３）。これは、WOLを用いた起動でもよい。WOLではネットワークインタフェースが他の機器からマジックパケットと呼ばれる特殊なパケットを送信されることにより、ネットワークインタフェース経由で本体を起動する仕組みである。

次に、起動完了すると本サーバを起動したクライアント側に起動完了通知を送信する（３０４）。３１２においてクライアント側は起動要求をサーバ側に送信すると、クライアント側内に記録された即再生用コンテンツを再生する（３１３）。即再生用コンテンツの所在はURLとしてインデックスに記載する。URLは自レコーダ内であるので、ネットワークアドレスはローカルホストとしてよい。起動完了通知を受信すると（３１４）、即再生用コンテンツとネットワークを介して取得する続きコンテンツを、つなぎ目無く再生（シームレス再生）するための処理を３１５以降で行う。

まず、即再生用コンテンツの続きを要求する続きコンテンツ要求を作成する（３１５）。ステップ３１５の詳細は図７で説明する。次に続きコンテンツ要求をサーバ側に送信する（３１６）。サーバ側は続きコンテンツ要求を受信し（３０６）、即再生用コンテンツの続きをコンテンツから作成し、続きコンテンツとして送信する（３０７）。続きコンテンツは、コンテンツの先頭からのバイト長もしくは相当する時間でコンテンツを切り出すことにより作成する。

クライアント側は続きコンテンツを受信すると（３１７）、即再生用コンテンツと続きコンテンツを連結し、シームレス再生を行う（３１８）。シームレス再生は、２つに分けた元々１つのコンテンツを、１つのコンテンツとして再生する処理である。コンテンツの再生では、特に映像データにおいてはすべてのデータを主メモリに展開する必要は無い。再生に必要な数秒程度のデータを逐次読み出して再生することが一般的であるため、シームレス再生のためには読み出し元を変更するだけでよい。

図４は２０１の起動時間測定のフローを示している。レコーダに電源を投入すると、ハードウェアが起動する（４０１）。次にオペレーティングシステムが起動する（４０２）。オペレーティングシステムが起動するもしくはある程度起動すると、アプリケーションもしくはそれに類似するソフトウェアが起動可能となるため、起動時間の測定アプリケーションを起動し、起動時間の測定を開始する（４０３）。
次に、各種アプリケーションを起動する（４０４）。必要なソフトウェアがすべて起動すると起動が完了し（４０５）、この時点で測定アプリケーションは測定を終了する（４０６）。なお、ステップ４０５においてはネットワークを介してコンテンツを送信する準備が整っている必要がある。

次に、起動時間を計算する（４０７）。起動時間の計算では、測定した起動時間にハードウェアおよびオペレーティングシステムが起動するための時間を加算する。ハードウェアおよびオペレーティングシステムが起動するための時間は測定できない場合があるので、予め出荷時に設定しておいても良い。
ハードウェアもしくはオペレーティングシステムの起動時間が測定可能であれば、測定した値を前述の値として用いても良い。また、起動時間の代わりに共通の値を用いる構成でもよい。例えば、レベル１の装置は５秒、レベル２の装置は１０秒とし、出荷時に設定したレベル値を起動時間として用いてもよい。

図５はインデックスの説明図である。本例では５つのコンテンツをレコーダ間で共有している。それぞれのコンテンツにはコンテンツ番号５０１が付与されており、５０２にコンテンツ名が示されている。５０３はコンテンツのURLであり、５０４は対応する即再生用コンテンツのURLである。本例ではネットワークアドレスがlocalhostとなっているが、これはインデックスを保持するレコーダ内に存在することを示している。５０５は即再生用コンテンツの長さである。

図６はインデックス選択（３１１）の表示例である。６０１はテレビなどの画面であり、６０２はコンテンツ名、６０３はコンテンツの記録時間、６０４はコンテンツを記録した日時、６０５はコンテンツのジャンルを示している。６０６はコンテンツの詳細情報を表示させるためのボタン領域であり、６０６を選択中には６０８のようなボタンが表示される。このとき、６０９の決定ボタンも表示され、６０９の決定ボタンを押下すると詳細情報が表示される。６０７は上下に移動してコンテンツを選択可能にするフォーカスである。フォーカス中にリモコンの再生ボタンを押下すると、該当するコンテンツが再生される。

図７は、続きコンテンツ要求作成３１５の詳細なフローである。まず、レコーダの設定などにより、即再生用コンテンツを全て再生するかどうかを判断する（７０１）。全て再生する場合は、その続きからコンテンツを要求するため、即再生用コンテンツの長さから、コンテンツの開始位置を算出する（７０２）。コンテンツの開始位置とは、例えばコンテンツのすべての長さが１００である場合に即再生用コンテンツの長さが５であるとすると、コンテンツの開始位置は６となる。

一方、即再生用コンテンツの再生を途中で止める場合は、即再生用コンテンツの再生停止位置を決定する（７０３）。再生停止位置は、サーバ側からコンテンツを取得するために必要な時間より長い箇所に設定する。次に、再生停止位置から開始位置を算出する（７０４）。開始位置は、７０２と同様に再生停止位置の直後とする。次に、算出した開始位置から続きコンテンツ要求を作成する（７０５）。作成する続きコンテンツ要求については、図８を用いて詳細に説明する。

続きコンテンツ要求は少なくともコンテンツのURL８０１と、コンテンツのバイト単位の開始位置（８０２）もしくは、コンテンツの時間単位の開始位置（８０３）から構成される。８０２と８０３は同一の位置を示しているのであれば、２つとも記載してもよい。コンテンツのURLは５０３のURLに等しい。コンテンツの開始位置は、即再生用コンテンツの再生を終了するバイト位置もしくは時間の位置の直後を指定する。図８においては、即再生用コンテンツは48325949バイトもしくは15.5秒の直前で再生を終了する。なお、続きコンテンツ要求はコンテンツ開始位置を0バイトもしくは0秒とすれば先頭から再生を開始する通常のコンテンツ要求となる。

図９は、コンテンツおよび即再生用コンテンツを再生する際のデータの流れを示した図である。９００はクライアント側レコーダを、９１０はサーバ側レコーダを示している。コンテンツの再生が指示されると、まず即再生用コンテンツがクライアント側の記録領域９０３から主メモリ９０２に読み込まれ、映像／音声再生部９０１で再生する。即再生用コンテンツの終端もしくは停止位置に到達すると、読み出し先を続きコンテンツにスイッチする。続きコンテンツはサーバ側の記録領域９１２からネットワークインタフェース９１１およびネットワークインタフェース９０４を介して主メモリ９０２に読み込まれ、主メモリ上で即再生用コンテンツの終端に接続されて、即再生用コンテンツに続いて映像／音声再生部で再生する。

図１０は、コンテンツ全体と即再生用コンテンツ、続きコンテンツの関係を長さの観点から示した図である。なお、長さはバイト長もしくは時間であり、どちらの場合でも同様の図となる。１００１はコンテンツ全体であり、長さはt1である。１００２は即再生用コンテンツであり、長さはt2である。１００３は続きコンテンツであり、長さはt4である。ここで、１００２と１００３には重なりt3が存在する。t3は続きコンテンツを取得するまでの時間的ゆとりとして用いられる。
例えば、即再生用コンテンツの再生が終了する時点で続きコンテンツがクライアント側レコーダに到着するのであれば、t3は0に近い値でも良い。しかし、ネットワークを介してコンテンツを送受信する場合、通常ネットワークの通信速度のゆらぎを吸収するためにバッファを設ける。このバッファがt3に相当する。なお、バッファはその他の目的のバッファでもよい。

図１１は、コピー制限のあるコンテンツの場合に、図１０と同様にコンテンツ全体と即再生用コンテンツ、続きコンテンツの関係を長さの観点から示した図である。なお、コンテンツ１１０１は先頭部分がコピーフリーとなっており、t2時間経過後はコピー制限がかけられている。
このような場合、即再生用コンテンツ１１０２は、t2>t4としなければならない。t2<t4では、コピー制限によりクライアント側に即再生用コンテンツを送信することができない場合がある。また、t2はコンテンツの作成元が決定する時間であるため、t5に多少のゆとりを持たせることができる値であればよい。例えばt2 = 120秒であれば、通常の機器の起動時間はすべてカバーできる可能性が高い。t6およびt7は図１０のt3およびt4にそれぞれ相当する。

図１２は、サーバ側でコンテンツを削除した場合のフローである。サーバ側でコンテンツを削除すると（１２０１）、コンテンツ領域からコンテンツが削除される。次にサーバ側でインデックスを更新する（１２０２）。インデックスには削除したコンテンツのURLを削除するか、削除したという情報を追加する。
次に、サーバ側とクライアント側でインデックスを同期する（１２０３および１２１３）。クライアント側はインデックスと即再生用コンテンツを比較し、インデックスに記載されていない即再生用コンテンツが存在するもしくは、インデックスに削除した旨が記載されているコンテンツが存在することを確認すると（１２１４）、該当する即再生用コンテンツを記録領域から削除する（１２１５）。

このように即再生用コンテンツを各レコーダ上で保持することにより、サーバ側レコーダの起動完了を待たずに、クライアント側レコーダ上で直ちにコンテンツを再生することができるという効果がある。また、即再生用コンテンツの長さをサーバ側レコーダの起動時間程度とすることで、クライアント側レコーダ上の記録領域を節約する効果がある。

次に、図１３から図２０を用いて、本発明の第二の実施例である実施例２について説明する。なお、実施例１との違いは、即再生用コンテンツを他のレコーダに保持する点と、再生を停止した場合に停止位置付近のコンテンツを即再生用コンテンツとして用いる点である。なお、以降即再生用コンテンツを保持するレコーダを即再生用コンテンツ保持レコーダとする。

図１３は、本発明の実施例２の全体図である。図１との違いは、コンテンツを保持する領域を持たない機器１３７０がネットワーク１３００に接続されている点である。１３１０および１３３０および１３５０はネットワーク１３００を介してコンテンツを共有するレコーダである。１３７０はネットワーク１３００を介してコンテンツを共有するテレビであり、１３１０や１３３０、１３５０との差異はコンテンツを保持する領域を持たない点である。なお、本説明におけるテレビ・レコーダは基本的に同等の端末である。１３７０に即再生用コンテンツを保持する領域を有する場合は、１３１０のレコーダと同様の構成であり、差異はコンテンツ本体を保持しない点である。また、本構成において１３５０は起動時間の早いもしくは常時起動しているレコーダであるため、即再生用コンテンツを有する即再生用コンテンツ保持レコーダとして、即再生用コンテンツを他のレコーダに比較して多く持つ。

１３１１はコンテンツのURLを保存する記録領域である。１３１２から１３１４はコンテンツAAAおよびコンテンツBBBおよびコンテンツCCCの所在であるURLを示すインデックスである。例えばインデックス１３１２では、コンテンツAAAはレコーダ１から取得できることがわかる。なお、１３１２のURLは簡易的に表記したものであり、一般に使用されているURLのように階層化し、またファイル名やその他の情報などを記載しても良い。１３１５から１３１７はそれぞれコンテンツAAAおよびコンテンツBBBおよびコンテンツCCCの即再生用コンテンツを再生するためのURLである。１３１８はコンテンツ本体を記録するコンテンツ領域である。１３１９および１３２０はコンテンツである。

１３３０はレコーダ２を示し、レコーダ１（１３１０）と同様の構成である。１３５０はレコーダ３を示し、レコーダ１（１３１０）と同様の構成であるが、本例ではコンテンツ領域１３５８に即再生コンテンツが保存されている。例えば、レコーダ３の起動速度がレコーダ１やレコーダ２に比較して早い場合や、レコーダ３の起動している時間がレコーダ１やレコーダ２に比較して通常長い場合は、テレビ１３７０がコンテンツの取得を要求してから実際にコンテンツを取得するまでの時間は、レコーダ３（１３５０）が最も短い可能性が高い。このため、レコーダ３を即再生用コンテンツ保持レコーダとして選出し、即再生用コンテンツを保持するようにすれば、ユーザの再生要求後にまずレコーダ３から再生し、続いて他のレコーダから再生することができる。なお。コンテンツ領域１３５８にコンテンツ本体を保存しても良い。即再生用コンテンツ保持レコーダの選出については、図１４の１４１１で説明する。

１３７０はコンテンツを記録する領域を持たないテレビである。メモリ１３７１上には、各コンテンツのURL１３７２から１３７４と、先頭URL１３７５から１３７７が保持されている。なお、１３７１はメモリ以外にHDDなどでも良い。

以上のような構成において、例えばレコーダ１（１３１０）上でコンテンツCCCを初めて再生しようとした場合、コンテンツ本体はコンテンツ領域１３１８上に存在しないので、他の機器から取得する必要がある。インデックス１３１４を参照すると、コンテンツCCCのURLはレコーダ２（１３３０）となっており、ネットワークを介してコンテンツの送信を要求する。同時にコンテンツCCCの先頭部分のURL（１３１７）は、レコーダ３であるため、レコーダ３にコンテンツCCCの先頭部分（１３６１）を要求する。レコーダ３はコンテンツ先頭部分CCC（１３６１）をレコーダ１に送信し、レコーダ１は受信後に再生を行う。また、レコーダ１はレコーダ２に要求したコンテンツを受信すると、コンテンツ先頭部分（１３６１）とコンテンツ本体（１３３９）を継ぎ目無く再生する。なお、後述の途中再開を実施する場合は、上記コンテンツ先頭部分に加え、コンテンツの途中部分を即再生用コンテンツとして保持する。このとき、即再生用コンテンツは１コンテンツにつき複数となる場合がある。

次に、図１４を用いて実施例２の基本フローについて説明する。基本フローは大きく３つに分けることができる。まず即再生用コンテンツ保持レコーダの選出過程１４１０である。本過程は一度だけ実行すればよいが、ユーザの指示や定期的なタイミングで複数回実行しても良い。次は、コンテンツの事前共有過程１４２０である。本過程はコンテンツを新たに録画したタイミングや、定期的なタイミングで実行する。次は、コンテンツの再生過程１４３０である。本過程では、コンテンツの再生を実行する。

以下、基本フローを詳細に説明する。まず、即再生用コンテンツ保持レコーダの選出過程では、複数存在するコンテンツを記録可能なレコーダの中から、即再生用コンテンツを保持すべきレコーダを選出する（１４１１）。選出の基準としては、起動速度が速いことや、一日の中で起動している時間の割合が長いこと、消費電力が低いことなどが挙げられる。これらのパラメータにより少なくとも１台を即再生用コンテンツ保持レコーダとして選出する。次に、選出した結果を他のレコーダに通知する（１４１２）。選出結果を受信したレコーダは、図１５に示すようなテーブルとして保存する。次に、レコーダが録画動作を行うなどしてコンテンツが更新されると、レコーダはコンテンツリストを更新する（１４２１）。コンテンツリストは他のレコーダやテレビと共有される。

次に、即再生用コンテンツ保持レコーダが即再生用コンテンツを取得する（１４２２）。取得する方法は以下の２つとなる。第一の方法は、コンテンツを録画するなどしてコンテンツリストを更新したレコーダが１５０２で説明する更新通知用URLを用いてコンテンツの更新を即再生用コンテンツ保持レコーダに通知する。即再生用コンテンツ保持レコーダは、通知を元に即再生用コンテンツを取得する。第二の方法は、即再生用コンテンツ保持レコーダが、コンテンツリストの更新によりコンテンツの追加を検知すると、対応する即再生用コンテンツを取得する方法である。なお、コンテンツと即再生用コンテンツの対応は、図５で示した対応付けと同様であるが、５０４のlocalhostがコンテンツを保持するレコーダのネットワークアドレスに変更される。また、１４２１においてコンテンツの削除を検知すると、１４２２において該当する即再生用コンテンツを廃棄する。

次に、テレビもしくはレコーダがネットワークを介してコンテンツを再生しようとすると、ネットワークを介して即再生用コンテンツを再生する（１４３１）。ステップ１４３１においては、同時に他のレコーダに対してコンテンツの送信を要求する。次に、コンテンツ本体を保持するレコーダからコンテンツが到着すると、１４３１で再生中のコンテンツに続いて再生を実行する（１４３２）。以上で処理を終了する。なお、１４３１で再生中のコンテンツは途中で中断しても良い。また、１４３１で再生中に続きのコンテンツを取得してもよく、一時的に即再生用コンテンツとコンテンツ本体を同時に取得しても良い。
また、１４１０、１４２０、１４３０は必ずしもこの順番で実行される必要は無く、それぞれのブロックが独立して繰り返されても良い。

次に、図１５を用いて各レコーダが保持する選出結果のテーブルを説明する。１５０１は本テーブル上の端末番号であり、本テーブル中では１および２のみである。１５０２は即再生用コンテンツ保持レコーダへのコンテンツ更新通知用URLであり、このURLを用いてコンテンツ更新を通知することができる。１５０３は即再生用コンテンツ保持レコーダの優先順位を示し、例えば１つのみコンテンツ更新を通知する設定であれば優先順位の高い１５１１を、２つコンテンツ更新を通知する設定であれば１５１１および１５１２に対してコンテンツ更新を通知する。１５０４は即再生用コンテンツ保持レコーダの起動時間である。

本時間と、コンテンツ本体を保持するレコーダの起動時間の差分が、コンテンツを即再生用コンテンツとして保持すべきコンテンツの長さとなる。例えば、１５１１は起動時間が１．５秒であり、あるコンテンツEEEを保持するレコーダの起動時間が２０秒だとすると、即再生用コンテンツ保持レコーダが起動してからコンテンツEEEを保持するレコーダが起動するまで１８．５秒存在する。このため、即再生用コンテンツが１８．５秒以上あれば、即再生用コンテンツの再生中にコンテンツを保持するレコーダが起動完了し、コンテンツを送信することができる。

コンテンツを保持するレコーダが続きのコンテンツを送信すれば、ユーザにとっては１．５秒後からコンテンツを視聴することができる。なお、上記起動時間にはネットワークの設定時間も含む。また、コンテンツの送受信やエンコード／デコードに必要なバッファは考慮していないため、上記計算の時間は、それらを考慮した時間とする必要がある。なお、コンテンツ更新を通知する仕掛けは、コンテンツ本体もしくはコンテンツリストを共有するための仕掛けを利用しても良い。例えば、コンテンツリストの更新によりコンテンツ更新を検知し、即再生コンテンツを取得しても良い。

次に、図１６を用いてコンテンツを再生する際のフローについて説明する。なお初期状態としてコンテンツのインデックスは共有されているものとする。また、サーバ側とはコンテンツを保持するレコーダなどの端末、クライアント側とはコンテンツを視聴するテレビなどの端末を指す。

処理が開始されると、クライアント側は再生するコンテンツのインデックスを選択する（１６３１）。インデックスの詳細は図１７で説明する。次に、サーバ側および即再生用コンテンツ保持レコーダに対して、ネットワークを介して起動要求を送信する（１６３２）。即再生用コンテンツ保持レコーダおよびサーバ側は、それぞれ起動要求を受信する（１６２１および１６１１）。なお、サーバ側が既に起動している場合は、即再生用コンテンツを再生する必要が無いため、サーバ側は直ちに起動完了通知を送信し、クライアント側はサーバ側から直接コンテンツを取得する。

次に、即再生用コンテンツ保持レコーダは、起動して（１６２２）、起動完了通知をクライアント側に送信する（１６２３）。クライアント側は、起動完了通知を受信すると（１６３３）、まず即再生用コンテンツ保持レコーダからコンテンツを取得するために、即再生用コンテンツ要求を即再生用コンテンツ保持レコーダに送信する（１６３４）。即再生用コンテンツ保持レコーダは、即再生用コンテンツ要求を受信すると（１６２４）、即再生用コンテンツの送信を開始する（１６２５）。クライアント側は即再生用コンテンツを受信すると（１６３５）、即再生用コンテンツの再生を開始する（１６３６）。なお、ステップ１６３４、１６２４、１６２５、１６３５は、即再生用コンテンツの再生中に繰り返し実行しても良い。

次に、サーバ側が起動すると（１６１２）、サーバ側はクライアント側に起動完了通知を送信する（１６１３）。クライアント側は、起動完了通知を受信すると（１６３７）、続きコンテンツの要求を作成する（１６３８）。続きコンテンツとは、即再生用コンテンツの続きから再生するコンテンツであり、例えば即再生用コンテンツが先頭からｋバイトまでであった場合、ｋ＋１バイト目からを続きコンテンツとして要求する。なお、続きコンテンツは必ずしも即再生用コンテンツの終わり以降からである必要は無く、即再生用コンテンツと続きコンテンツが部分的に重複しても良い。

次に、クライアント側は続きコンテンツ要求を送信する（１６３９）。サーバ側は続きコンテンツ要求を受信すると（１６１４）、続きコンテンツを送信する（１６１５）。クライアント側は続きコンテンツを受信すると（１６４０）、即再生用コンテンツの送信停止要求を送信する（１６４１）。１６４１は、必ずしも停止要求の送信である必要は無く、例えばネットワークのコネクションを切断するなどにより停止要求の送信に代えても良い。即再生用コンテンツ保持レコーダは即再生用コンテンツ送信停止要求を受信すると（１６２６）、即再生用コンテンツの送信を停止する（１６２７）。クライアント側は、１６４０で受信した続きコンテンツを、即再生用コンテンツに続けて再生する（１６４２）。なお、１６４２は１６４１の前に実行しても良い。以上で処理を終了する。

次に、図１７を用いてインデックステーブルを説明する。
１７０１はリスト上のコンテンツ番号であり、本リスト中では１から５まで存在する。１７０２はコンテンツ名である。１７０３はコンテンツを取得するためのサーバ側のURLである。１７０４は即再生用コンテンツを取得するためのURLである。１７０５は即再生用コンテンツの時間であり、例えばコンテンツAAAであれば即再生用コンテンツは最大３０秒分取得することができる。

次に図１８を用いてコンテンツの再生停止と再開をサポートした即再生用コンテンツについてのフローを説明する。まず、クライアント側で再生を停止する（１８３１）。次に、クライアント側は、送信停止要求をサーバ側に送信する（１８３２）。サーバ側は送信停止要求を受信すると（１８１１）、送信を停止する（１８１２）。また、クライアント側は再生を停止した位置を即再生用コンテンツ保持レコーダに送信する（１８３３）。即再生用コンテンツ保持レコーダは停止位置を受信すると（１８２１）、サーバ側に即再生用コンテンツ要求を送信する（１８２２）。

即再生用コンテンツ要求は、停止位置からサーバ側の起動時間分のコンテンツもしくは、停止位置前後のサーバ側起動時間分コンテンツの要求である。即再生用コンテンツ要求を受信すると（１８１３）、サーバ側は即再生用コンテンツとして、要求された長さのコンテンツを即再生用コンテンツ保持レコーダに送信し（１８１４）、即再生用コンテンツ保持レコーダでは受信した即再生用コンテンツを受信する（１８２３）。受信したコンテンツは、コンテンツ領域に保存するとともに、保持する即再生用コンテンツのリストを更新する（１８２４）。なお、１８３３で停止位置を送信する先はサーバ側でも良い。この場合、サーバ側は停止位置を即再生用コンテンツ保持レコーダに送信する。即再生用コンテンツ保持レコーダは、継続して１８２２以降を実行する。

次に、１８２４で更新する即再生用コンテンツのリストについて、図１９を用いて説明する。１９０１から１９０３はそれぞれ１７０１から１７０３と同様である。１９０４は即再生用コンテンツURLであり、クライアント側が本URLにアクセスすると、クライアント側のアドレス１９０５と比較して対応する即再生用コンテンツの実体１９０６を取得できる。例えば、ある機器が即再生用URL１９０４にアクセスしたとき、即再生用コンテンツが１つのみであれば、URLに対応してコンテンツを送信することができるが、即再生用コンテンツが複数存在する場合、停止機器１９０５に対応して即再生コンテンツを送信する。また、停止機器のリストに載っていない機器からの取得要求に対しては、先頭からのコンテンツを送信する。

次に、図２０を用いてコンテンツ全体と即再生用コンテンツの関係を説明する。２０００はコンテンツ全体を示している。２００１から２００４は即再生用コンテンツを示しており、特に２００１は即再生用コンテンツ、２００２から２００４は途中再開コンテンツである。また、各コンテンツが重ならない場合は、コンテンツを同時に２つ録画し、一方のコンテンツを図２０のように分ければ、即再生用コンテンツを作成できる。この場合、同時に使用するチューナは２つでよい。

このように即再生用コンテンツを、コンテンツ本体を保持するレコーダとは異なるレコーダに保持することにより、クライアント側で再生を指示してから実際に再生が開始されるまでの時間を短縮する効果がある。また、停止場所を即再生用コンテンツ保持レコーダに通知し、停止場所付近のコンテンツをサーバ側から取得することにより、停止したコンテンツを高速に再生再開する効果がある。
また、本発明の実施形態の開示内容には、以下の例も含まれる。
本発明は、レコーダの起動時間を計測し、該レコーダにコンテンツを記録すると起動時間分のコンテンツは他のレコーダにもコピーして共有するようにしたものであって、ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置において、コンテンツ共有装置の起動にかかる時間を保持する手段と、起動にかかる時間に相当するコンテンツを予め他の装置に送信する手段と、コンテンツ共有装置内に保持するコンテンツのインデックスを作成および更新する手段と、インデックスを他のコンテンツ共有装置と共有する手段とを有し、起動にかかる時間に相当するコンテンツを予め他のコンテンツ共有装置へ送信するようにしてコンテンツを共し、高速再生機能を実現するようにしたものである。
また本発明では、コンテンツ共有装置の起動にかかる時間を測定する手段と、起動にかかる時間に相当するコンテンツのインデックスを作成および更新する手段を有し、インデックスにコンテンツのネットワークアドレスを保持するようにしたものである。
また本発明では、起動にかかる時間に相当するコンテンツのインデックスを、前記コンテンツ共有装置内に保持するコンテンツのインデックスを拡張した領域に含めて管理するようにしたものである。
また本発明では、起動にかかる時間に相当するコンテンツを予め他の装置と共有するために、インデックスに起動時間を含め、他の装置が起動時間に相当するコンテンツを要求することにより予め共有するようにしたものである。
また本発明では、ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置において、インデックスを他のコンテンツ共有装置から取得する手段と、コンテンツの一部を他のコンテンツ共有装置から予め取得する手段と、コンテンツを有する他のコンテンツ共有装置から予め取得したコンテンツの続きを取得する手段とを有志、インデックスで指定されたコンテンツの再生時に予め取得したコンテンツを再生し、予め取得したコンテンツに続いてコンテンツの続きを再生するようにしたものである。
また本発明では、予め取得するコンテンツの一部は、コンテンツ共有装置で共有するコンテンツのインデックスに予め取得すべきコンテンツとして示されたコンテンツであるようにし、またコンテンツ共有装置から取得したコンテンツ起動時間に相当する長さは、コンテンツを取得する際に指定してコンテンツの一部を予め取得するようにしたものである。
また本発明では、コンテンツの再生時に他のコンテンツ共有装置の起動を指令し、予め取得したコンテンツを再生し、予め取得したコンテンツに続いてコンテンツの続きを再生するようにしたものである。
また本発明によるコンテンツ共有方法では、コンテンツのインデックスを他のコンテンツ共有装置と共有するために、コンテンツ共有装置内に保持するコンテンツのインデックスを作成または更新するステップと、コンテンツ共有装置の起動時間に相当するコンテンツを予め送信するステップを有し、インデックスで指定したコンテンツに対応するコンテンツ共有装置の起動時間に相当するコンテンツを予め送信するようにしたものである。
また本発明によるコンテンツ共有方法では、コンテンツの一部を他のコンテンツ共有装置から予め取得するステップと、再生すべきコンテンツをコンテンツ共有装置内に保持するコンテンツのインデックスで指定してコンテンツの再生を指令するステップと、再生の指令により予め取得したコンテンツを再生するステップと、再生すべきコンテンツを有する他のコンテンツ共有装置から予め取得したコンテンツの続きを取得するステップとを有し、予め取得したコンテンツに続いてコンテンツの続きを再生するようにしたものである。

本発明装置の全体図である。即再生用コンテンツを共有するまでのフローである。コンテンツを再生する場合のフローである。起動時間測定のフローである。インデックスの説明図である。インデックス選択の表示例である。続きコンテンツ要求作成の詳細なフローである。続きコンテンツ要求の説明図である。コンテンツおよび即再生用コンテンツを再生する際のデータの流れを示した図である。コンテンツ全体と即再生用コンテンツ、続きコンテンツの関係を示した図である。コピー制限のある場合の、コンテンツ全体と即再生用コンテンツ、続きコンテンツの関係を示した図である。サーバ側でコンテンツを削除した場合のフローである。本発明の実施例２の全体図である。本発明の実施例２の基本フローである。即再生用コンテンツ保持レコーダの選出結果のテーブル例である。コンテンツを再生する場合のフローである。インデックスの説明図である。再生停止と再開に対応した基本フローである。停止機器に対応した即再生用コンテンツのリストの説明図である。コンテンツ全体と即再生用コンテンツの関係を示した図である。

符号の説明

１００ネットワーク
１１０レコーダ１
１１１インデックス領域
１１２コンテンツAAAのインデックス
１１３コンテンツBBBのインデックス
１１４コンテンツCCCのインデックス
１１５コンテンツ領域
１１６コンテンツAAA
１１７コンテンツBBB
１１８コンテンツCCC
１２０レコーダ２
１２１インデックス領域
１２５コンテンツ領域
１３０レコーダ３
１３１インデックス領域
１３５コンテンツ領域

Claims

ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置であって、
コンテンツ共有装置の起動にかかる時間を保持する手段と、
起動にかかる時間に相当するコンテンツを予め他の装置に送信する手段と、
コンテンツ共有装置内に保持するコンテンツのインデックスを作成および更新する手段と、
インデックスを他のコンテンツ共有装置と共有する手段とを有し、
前記起動にかかる時間に相当するコンテンツを予め他のコンテンツ共有装置へ送信することを特徴とするコンテンツ共有装置。
前記コンテンツ共有装置の起動にかかる時間を測定する手段を有することを特徴とする請求項１に記載のコンテンツ共有装置。
起動にかかる時間に相当するコンテンツのインデックスを作成および更新する手段を有することを特徴とする請求項１に記載のコンテンツ共有装置。
前記インデックスにコンテンツのネットワークアドレスを保持する手段を有することを特徴とする請求項３に記載のコンテンツ共有装置。
前記起動にかかる時間に相当するコンテンツのインデックスを、前記コンテンツ共有装置内に保持するコンテンツのインデックスを拡張した領域に含めて管理することを特徴とする請求項３に記載のコンテンツ共有装置。
前記起動にかかる時間に相当するコンテンツを予め他の装置と共有するために、インデックスに起動時間を含め、他の装置が起動時間に相当するコンテンツを要求することにより予め共有すること特徴とする請求項１に記載のコンテンツ共有装置。
ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置であって、
インデックスを他のコンテンツ共有装置から取得する手段と、
他のコンテンツ共有装置の起動にかかる時間に相当するコンテンツを他のコンテンツ共有装置から予め取得する手段と、
コンテンツを有する他のコンテンツ共有装置から、予め取得したコンテンツの続きを取得する手段と、を有し、
前記インデックスで指定されたコンテンツの再生時に、予め取得したコンテンツを再生し、予め取得したコンテンツに続いてコンテンツの続きを再生することを特徴とするコンテンツ共有装置。
前記起動にかかる時間に相当するコンテンツは、コンテンツ共有装置で共有するコンテンツのインデックスに予め取得すべきコンテンツとして示されたコンテンツであることを特徴とする請求項７に記載のコンテンツ共有装置。
他のコンテンツ共有装置の起動にかかる時間に相当する長さを、コンテンツを取得する際に指定することにより、前記起動にかかる時間に相当するコンテンツを予め取得することを特徴とする請求項７に記載のコンテンツ共有装置。
コンテンツの再生時に他のコンテンツ共有装置の起動を指令し、予め取得したコンテンツを再生し、予め取得したコンテンツに続いてコンテンツの続きを再生することを特徴とする請求項７に記載のコンテンツ共有装置。
ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置におけるコンテンツ共有方法であって、
コンテンツのインデックスを他のコンテンツ共有装置と共有するために、コンテンツ共有装置内に保持するコンテンツのインデックスを作成または更新するステップと、
コンテンツ共有装置の起動時間に相当するコンテンツを予め送信するステップを有し、
インデックスに対応したコンテンツを送信することを特徴とするコンテンツ共有方法。
ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置におけるコンテンツ共有方法であって、
他のコンテンツ共有装置の起動にかかる時間に相当するコンテンツを他のコンテンツ共有装置から予め取得するステップと、
再生すべきコンテンツをコンテンツ共有装置内に保持するコンテンツのインデックスで指定してコンテンツの再生を指令するステップと、
再生の指令により予め取得したコンテンツを再生するステップと、
再生すべきコンテンツを有する他のコンテンツ共有装置から、予め取得したコンテンツの続きを取得するステップとを有し、
予め取得したコンテンツに続いてコンテンツの続きを再生することを特徴とするコンテンツ共有方法。
前記他のコンテンツ共有装置のうち、特定のコンテンツ共有装置をコンテンツの一部である起動にかかる時間に相当するコンテンツを保持する共有装置として選出する手段を有することを特徴とする請求項１に記載のコンテンツ共有装置。
前記特定のコンテンツ共有装置の選出手段は、他のコンテンツ共有装置に比較して１日当たりの起動時間が長い装置を選出する方法であることを特徴とする請求項１３に記載のコンテンツ共有装置。
前記特定のコンテンツ共有装置の選出手段は、起動速度が他のコンテンツ共有装置に比較して速い装置を選出する方法であることを特徴とする請求項１３に記載のコンテンツ共有装置。
前記特定のコンテンツ共有装置の選出手段において、選出したコンテンツ共有装置を他のコンテンツ共有装置に通知する手段を有することを特徴とする請求項１３に記載のコンテンツ共有装置。
コンテンツを取得すると、選出したコンテンツ共有装置にコンテンツの取得を通知する手段を有することを特徴とする請求項１３に記載のコンテンツ共有装置。
前記インデックスにコンテンツが追加されたことを検知する手段と、検知したコンテンツの先頭部分を予め取得する手段を有することを特徴とする請求項１に記載のコンテンツ共有装置。
前記選出されたコンテンツ共有装置の通知を受信する手段と、選出されたコンテンツ共有装置から予め取得したコンテンツの一部を取得するネットワークアドレスを前記インデックスに記載する手段を有することを特徴とする請求項１３に記載のコンテンツ共有装置。
ネットワークを介してコンテンツを共有する機能を有するコンテンツ共有装置であって、
インデックスを他のコンテンツ共有装置から取得する手段と、
他のコンテンツ共有装置の起動にかかる時間に相当するコンテンツを他のコンテンツ共有装置から取得し再生する手段と、
コンテンツを他のコンテンツ共有装置から取得し前記起動にかかる時間に相当するコンテンツに続いて再生する手段を有することを特徴とするコンテンツ共有装置。
前記コンテンツの再生を中断する手段と、中断した箇所の情報を他のコンテンツ共有装置に送信する手段を有することを特徴とする請求項２０に記載のコンテンツ共有装置。
中断した箇所の情報を他のコンテンツ共有装置から受信する手段と、中断した箇所付近のコンテンツを他のコンテンツ共有装置から取得する手段を有することを特徴とする請求項１に記載のコンテンツ共有装置。
コンテンツの送信の中断を検出する手段と、検出した箇所付近のコンテンツを取得する指示を他のコンテンツ共有装置に送信する手段を有することを特徴とする請求項１に記載のコンテンツ共有装置。