(57)【特許請求の範囲】
【請求項１】
コンテンツデータとしてのストリームデータをダウンロードして蓄積する端末装置において、
前記ストリームデータの少なくとも開始部分のデータを所定のデータ形式で蓄積する蓄積部と、
前記蓄積部に蓄積されたストリームデータを再生させる再生部と、
前記再生部で再生させる際に、所定のデータ形式のストリームデータ以外の区間のストリームデータを、サーバからダウンロードして前記蓄積部に蓄積させ、既に蓄積されたデータと連続して再生させる制御部とを備え、
前記蓄積部が蓄積したストリームデータは、少なくともその開始部分がダウンロード時のデータ形式で蓄積され、前記開始部分以外の部分が、前記開始部分よりも高い圧縮率で圧縮したデータ形式で蓄積され、前記開始部分以外のダウンロードが出来ない場合には、当該開始部分以外のデータとして、前記蓄積部に前記開始部分よりも高い圧縮率で圧縮して蓄積されたデータを再生するようにした
端末装置。
【請求項２】
請求項１記載の端末装置において、
前記開始部分よりも高い圧縮率で圧縮して蓄積されたデータは、前記蓄積部の記憶残量が所定状態となった場合に、前記蓄積部に蓄積されたストリームデータの一部を圧縮して生成させる
端末装置。
【請求項３】
請求項１記載の端末装置において、
前記開始部分以外の部分を前記開始部分よりも高い圧縮率で圧縮したデータ形式は、前記開始部分から離れるに従って複数段階で圧縮率を高くするようにした
端末装置。
【請求項４】
請求項１記載の端末装置において、
前記所定のデータ形式での蓄積部への蓄積は、前記開始部分以外の重要部分についても蓄積させるようにした
端末装置。
【請求項５】
請求項１記載の端末装置において、
前記開始部分以外のダウンロードを行う際には、前記圧縮して蓄積されたデータとの差分のデータだけをダウンロードするようにした
端末装置。
【請求項６】
請求項１記載の端末装置において、
前記蓄積部が蓄積したストリームデータは、少なくとも開始部分と試聴可能部分とをダウンロードしたデータ形式で蓄積させ、そのストリームデータの購入処理が完了するまでは、前記試聴部分のデータの再生だけを許容させ、
前記購入処理が完了した場合に、蓄積された前記開始部分のデータを再生可能にする
端末装置。
【請求項７】
請求項６記載の端末装置において、
前記購入処理が完了した場合に、前記蓄積部に蓄積されていない残りのストリームデータをダウンロードするようにした
端末装置。
【請求項８】
コンテンツデータとしてのストリームデータをサーバから端末装置に配信して、端末装置で蓄積させ、その蓄積されたストリームデータの再生を行うコンテンツ配信システムにおいて、
前記端末装置は、前記ストリームデータの少なくとも開始部分のデータを所定のデータ形式で蓄積する蓄積部と、
前記蓄積部に蓄積されたストリームデータを再生させる再生部と、
前記再生部で再生させる際に、所定のデータ形式のストリームデータに続いた区間のストリームデータを、前記サーバからダウンロードして前記蓄積部に蓄積させ、前記開始部分のデータに続いて再生させる制御部とを備え、
前記蓄積部が蓄積したストリームデータは、少なくともその開始部分がダウンロード時のデータ形式で蓄積され、前記開始部分以外の部分が、前記開始部分よりも高い圧縮率で圧縮したデータ形式で蓄積され、前記開始部分以外のダウンロードが出来ない場合には、当該開始部分以外のデータとして、前記蓄積部に前記開始部分よりも高い圧縮率で圧縮して蓄積されたデータを前記再生部で再生するようにした
コンテンツ配信システム。
【請求項９】
請求項８記載のコンテンツ配信システムにおいて、
前記サーバから配信されて前記端末装置の蓄積部が蓄積するストリームデータは、少なくとも開始部分と試聴可能部分のデータであり、そのストリームデータの購入処理が完了するまでは、前記試聴部分のデータの再生だけを前記端末装置に許容させ、
前記購入処理が完了した場合に、蓄積された前記開始部分のデータを再生可能にする
コンテンツ配信システム。
【請求項１０】
請求項９記載のコンテンツ配信システムにおいて、
前記購入処理が完了した場合に、前記端末装置の蓄積部に蓄積されていない残りのストリームデータを前記サーバから配信するようにした
コンテンツ配信システム。
【請求項１１】
コンテンツデータとしてのストリームデータをサーバから端末装置に配信して、端末装置で蓄積させ、その蓄積されたストリームデータの再生を行うコンテンツ配信方法において、
前記端末装置は、前記ストリームデータの少なくとも開始部分のデータを所定のデータ形式で蓄積し、
その蓄積されたストリームデータを再生させる際に、その蓄積された所定のデータ形式のストリームデータに続いた区間のストリームデータを、前記サーバからダウンロードして蓄積し、前記開始部分のデータに続いて再生させるものであり、
前記端末装置が蓄積したストリームデータは、少なくともその開始部分がダウンロード時のデータ形式で蓄積され、前記開始部分以外の部分が、前記開始部分よりも高い圧縮率で圧縮したデータ形式で蓄積され、前記開始部分以外のダウンロードが出来ない場合には、当該開始部分以外のデータとして、前記端末装置に前記開始部分よりも高い圧縮率で圧縮して蓄積されたデータを再生するようにした
コンテンツ配信方法。
【請求項１２】
コンテンツデータとしてのストリームデータのサーバからの配信を受けて蓄積し、その蓄積されたストリームデータの再生を、コンピュータ装置で実行させるプログラムにおいて、
前記ストリームデータの少なくとも開始部分のデータを所定のデータ形式で蓄積させる処理と、
その蓄積されたストリームデータを再生させる際に、その蓄積された所定のデータ形式のストリームデータに続いた区間のストリームデータを、前記サーバからダウンロードして蓄積し、前記開始部分のデータに続いて再生させる処理とを行うもプログラムであり、
前記蓄積させる処理で蓄積したストリームデータは、少なくともその開始部分をダウンロード時のデータ形式で蓄積させ、前記開始部分以外の部分を、前記開始部分よりも高い圧縮率で圧縮したデータ形式で蓄積させる処理と、
前記開始部分以外のダウンロードが出来ない場合に、当該開始部分以外のデータとして、前記開始部分よりも高い圧縮率で圧縮して蓄積されたデータを再生させる処理とを行う
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリームデータの配信を行うコンテンツ配信システム及び方法と、そのシステムで配信を受ける端末装置、並びにそのコンテンツ配信を行う処理を実行するプログラムに関する。
【背景技術】
【０００２】
通信機能を有する携帯電話などの端末では、通信ができる環境にある間は自由に他の端末やサーバとの間で通信を行うことができる。例えば携帯電話端末であれば、基地局からの電波が届く範囲内にいるときがそうである。
【０００３】
また近年の携帯電話端末は、単なる通信機能にとどまらず、音楽や動画などのコンテンツ再生を幅広くサポートするようになってきている。一方、音楽・動画などのコンテンツはデータの量が比較的多くなる傾向にあるが、端末の携帯性、あるいはコストを重視する観点から、端末にあまり大容量のストレージを備えることは得策ではない。そこで従来では、コストとのバランスを考慮しながらストレージの容量を妥当な範囲内に抑え、それに格納できる以上のコンテンツは入らないよう商品の仕様を制限することに甘んじてきた。
【０００４】
ひとつのアイデアとしては、ストレージの容量を抑えながら多くのコンテンツを格納することを可能にするために、使用頻度の低いコンテンツをストレージから削除しておき、必要に応じてコンテンツを再度サーバからダウンロードしなおすことが考えられる。これは前述した「通信機能を有する」という端末の特長を生かした手法といえる。しかしその場合、サーバに接続し、コンテンツの少なくとも先頭部分をサーバから取り出して再生が可能になるまでの間ユーザを待たせることになってしまう。この待ち時間は実用上無視できない長さになることが予想され、結果としてユーザの快適な視聴体験を損なうこととなる。
【０００５】
さらに、無線通信を利用する携帯型の機器の場合、再度ダウンロードを行っている最中に通信可能な環境の外に出てしまう可能性がある。また有線であっても、トラフィックの混雑度によっては十分な通信帯域幅が確保できなくなることもないとはいえない。これらのケースにおいては、通信不能となる時間の長さにもよるが、最悪の場合途中で再生が途絶えてしまうこととなる。特に使用頻度の低いコンテンツの削除操作が端末内部で自動的に行われる場合には、ユーザには途切れる可能性のあるコンテンツとそうでないコンテンツの区別を意識しづらい。そのような状況で突然再生が途絶えることは、ユーザの機器やサービスに対する不信感や不快感を大きく増大させる元となり、受け入れられない。
【０００６】
特許文献１には、ストレージの容量の削減を目指すという観点からストリームデータの処理についての開示がある。即ち、ストリームデータを削除する際、キャッシュサーバの削除対象となるコンテンツから一定のブロック単位毎にストリームデータを削除することにより、少なくとも映像コンテンツに一定の連続性を保証可能であり、かつ、コンテンツの配信要求に対しても確実な管理の下に適切に所要のコンテンツを配信可能となり、最低限の配信サービスを提供可能とすることについての記載がある。また、特許文献１には、ユーザからの配信要求に対するコンテンツサーバへのアクセス不可時、キャッシュサーバに格納されているコンテンツから一定のブロック単位毎に削除されたストリームデータを早送り再生により配信することにより、自然な状態で映像化可能とすることについての記載がある。
【０００７】
特許文献１には、端末からの信号が正しく基地局で受信できない状態になったことを検出した場合に、警告を発する技術についての開示がある。
【特許文献１】特開２００１−３１３９１９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところが、特許文献１に記載された処理では、削除状態にあるコンテンツは早送り再生されることとなり、やはり快適な視聴体験を損なうと言わざるを得ない。また、コンテンツの再生が通常コンテンツの先頭から行われることが多い事実を考慮すれば、一定のブロックごとにストリームデータを削除する、逆に言えばコンテンツ全体にわたって一定のブロックごとに均一にデータを残すことはあまり効率がいいとは言えない。
【０００９】
本発明はかかる点に鑑みてなされたものであり、配信されたコンテンツの端末装置での蓄積が効率良く行えるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
本発明は、コンテンツデータとしてのストリームデータをサーバから端末装置に配信して、端末装置で蓄積させ、その蓄積されたストリームデータの再生を行う場合において、端末装置は、ストリームデータの少なくとも開始部分のデータを所定のデータ形式で蓄積し、その蓄積されたストリームデータを再生させる際に、所定のデータ形式のストリームデータに続いた区間のストリームデータを、サーバからダウンロードして蓄積させ、開始部分のデータに続いて再生させるようにしたものである。この場合に、端末装置が蓄積したストリームデータは、少なくともその開始部分がダウンロード時のデータ形式で蓄積され、開始部分以外の部分が、前記開始部分よりも高い圧縮率で圧縮したデータ形式で蓄積され、開始部分以外のダウンロードが出来ない場合には、当該開始部分以外のデータとして、端末装置に前記開始部分よりも高い圧縮率で圧縮して蓄積されたデータを再生するようにしたものである。
【００１１】
このようにしたことで、端末装置が蓄積するストリームデータのデータ量を削減させることができると共に、そのストリームデータの再生時には、全ての区間の再生が可能となる。
【発明の効果】
【００１２】
本発明によると、端末装置が蓄積するストリームデータのデータ量を削減させることができると共に、そのストリームデータの再生時には、全ての区間の再生が可能となる。例えば、圧縮して全区間のストリームデータを蓄積させた場合には、サーバからのダウンロードができない場合でも、最低限の品質での再生が確保できる。また、試聴用のデータと先頭部分のデータが蓄積された場合には、購入手続き後に、先頭部分のストリームデータの再生が可能となり、購入手続き後の再生が迅速にできるようになる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の一実施の形態を、添付図面を参照して説明する。
【００１４】
図１は、本例のシステム構成例を示している。図１の構成例では、ユーザ側の端末装置１１０として、通信ネットワーク１００を介してコンテンツサーバ装置などと通信を行うための通信部１１１と、コンテンツエンコード部１１２と、コンテンツデコード部１１３と、デコードしたコンテンツをユーザに提示するためのコンテンツ再生部１１４と、コンテンツなどを格納するための記憶装置１１５と、システム全体を制御する制御部１１６などを備える。端末装置１１０は、例えば携帯電話端末が適用可能である。
【００１５】
また、ユーザ側端末装置１１０へのコンテンツの提供が可能なコンテンツサーバ装置１０１が、通信ネットワーク１００に接続してある。但し、システムの構成はこの例に固定されるものではない。例えば、記憶装置１１５が通信ネットワーク１００を介して別のサーバやユーザ側端末上などに存在してもよい。あるいは、コンテンツエンコード部１１２を持たず、コンテンツの再エンコードが必要になった場合には通信ネットワーク１００を介して別のサーバやユーザ側端末に再エンコードを依頼するようにしてもよい。また図１に記載されていない装置、例えばコンテンツをキャッシュするためのキャッシュサーバなどの存在を否定するものではない。
【００１６】
端末装置１１０が備える制御部１１６は、後述するフローチャートに基づいた処理を実行する構成としてあるが、そのフローチャートで説明する処理以外にも、端末装置１１０全体およびシステム全体を滞りなく動作させるために必要な制御を行う。制御部１１６の実際の実現構成については、いわゆるCPUやRAM、ROMなどからなるシステムを利用することが考えられるが、そうした構成に限定されるわけではない。
【００１７】
コンテンツエンコード部１１２は、例えば、コンテンツデコード部１１３で一旦デコードしたコンテンツを再エンコードする際に利用される。このため、デコード部１１３でデコードしたコンテンツがスムーズにエンコードできるように、エンコード部１１２とデコード部１１３が接続されていることが望ましい。
【００１８】
通信部１１１は、通信ネットワーク１００を通してコンテンツサーバ装置１０１などへの通信を可能にする処理部であるが、無線・有線など具体的な通信の方式を特に問うものではない。例えば、携帯電話端末に適用した場合には、無線電話用の通信処理部に相当する。通信ネットワーク１００は、例えば無線電話回線を経由してアクセスされるインターネットなどが適用可能である。
【００１９】
端末装置１１０が備えるコンテンツ再生部１１４としては、例えばコンテンツが音楽データである場合には、音楽再生用の構成（オーディオ出力部など）を備え、コンテンツが映像データである場合には、映像再生用の構成（表示部など）を備える。
【００２０】
端末装置１１０が備える記憶装置１１５としては、ハードディスクドライブ装置やメモリカードなどの各種記憶手段が適用可能であり、後述するコンテンツデータであるストリームデータを蓄積する。ここでは、コンテンツデータとして、主として音楽データ及び映像データを想定している。
【００２１】
次に、図１に示したシステムで行われるコンテンツデータの配信時、及びその配信されたコンテンツデータの蓄積時のデータ状態について、図２を参照して説明する。
【００２２】
図２は、本例の１つにおいて行われる処理の概念を示している。図２（ａ）に示した元のコンテンツ２０１は、コンテンツサーバ装置１０１側に用意されたストリームデータである。このストリームデータが、通信ネットワークを経由して、端末装置１１０に配信される。配信時には、基本的にそのままのデータ構成で配信され、端末装置１１０側の記憶装置１１５に蓄積される。図２（ａ）に示した元のコンテンツ２０１は、コンテンツ先頭位置２０５からコンテンツ終了位置２０６まで、平均データ量２０４がほぼ一定のデータである。
【００２３】
ここで、記憶装置１１５の利用可能な空き容量が所定量以下に少なくなった時点などの適切なタイミングにおいて、元のコンテンツ２０１からデータ量削減済みコンテンツ２０２に置き換える処理が、端末装置１１０内での処理で行われる。図２（ｂ）は、データ量削減済みコンテンツ２０２を示したものである。図２（ｂ）に示したように、コンテンツ先頭位置２０５から所定の期間の先頭部分２０７については、元のコンテンツのままのデータ量としてあり、その他の区間については、データ圧縮させてデータ量を削減したデータ量削減部分２０９としてある。但し、先頭部分以外の部分で、コンテンツデータの重要な部分２１０については、圧縮しないようにしてもよい。
【００２４】
データ量削減部分２０９の構成について説明すると、先頭部分２０７に続いた所定の期間の準先頭部分２０８については、若干データを圧縮してデータ量を削減した区間としてある。さらに、準先頭部分２０８に続いた区間では、所定期間ごとに順に圧縮率を高くしたデータ量漸減部分２０９としてあり、さらに残りの区間については最も高い圧縮率で圧縮させたデータとしてある。この例では、重要部分２１０に続いた部分については、最も高い圧縮率で圧縮させたデータ区間としてあるが、先頭部分に続いた区間と同様に、徐々に圧縮率を高くしてもよい。
【００２５】
このように圧縮して蓄積されたコンテンツを再生する際には、コンテンツサーバ装置１０１から、再度、圧縮された区間のデータだけを配信させて、コンテンツ補完バッファに蓄積させる。図２(ｃ)は、コンテンツ補完バッファに蓄積されたデータ２０３を示してある。このデータ２０３は、図２（ｂ）に示したデータ量削減済みコンテンツ２０２のデータ量削減部分２０９の区間だけで構成され、それぞれの区間のデータ量としては、圧縮させていない元のコンテンツデータ２０１と同じである。
【００２６】
なお、このようにサーバ装置１０１から配信を受けるコンテンツ補完データ２０３として、図２（ｂ）に示したデータ量削減済みコンテンツ２０２のデータ量削減部分２０９のデータと、図２(ｃ)に示したコンテンツ補完データ２０３との差分のデータとして、端末装置１１０内での演算処理で、図２（ａ）に示した元のコンテンツデータ２０１を復元するようにしてもよい。
【００２７】
このように処理することで、端末装置１１０の記憶装置１１５が蓄積するコンテンツのデータ量を削減することができ、記憶装置１０６の利用可能容量を増加することができる。図２（ａ）に示した元のコンテンツデータ２０１から、図２（ｂ）に示したデータ量削減済みコンテンツ２０２を得る処理を行うタイミングは、記憶装置１１５の記憶残量などに基づいて、端末装置１１０の制御部１１６が自動的に判断する以外にも、ユーザによる操作によって指示するようにしてもよい。
【００２８】
データ量削減済みコンテンツ２０２を再生するときには、サーバからコンテンツ補完バッファ２０３に必要な部分をダウンロードしながら再生を行う。このとき再生ができる限り途切れないよう、また再生品質ができる限り高く保たれるよう、データ量削減コンテンツ２０２とコンテンツ補完バッファ２０３を使い分けながら動作する。さらに、ダウンロード完了後、必要に応じてデータ量削減済みコンテンツ２０２とコンテンツ補完バッファ２０３の内容から元のコンテンツ２０１を復元することもできる。また何らかの原因によりダウンロードを十分行うことができない場合には、主にデータ量削減済みコンテンツ２０２を再生に用いることにより、最低限の再生品質を確保することが可能となる。
【００２９】
なお、図２は処理の概念を説明するためのものであって、本発明の技術的詳細を制限するものではない。例えば、図２では元のコンテンツ２０１の平均データ量が、コンテンツの全範囲に渡って元の平均データ量２０４なる定数値に揃えられているようにも見受けられる。しかし実際には、元のコンテンツ２０１に対し、ある種の可変ビットレート符号化（ＶＢＲ）のようにデータ量が随時変化する方式を採用する可能性の排除を意図しているわけではない。ここではあくまで元のコンテンツ２０１とデータ量削減済みコンテンツ２０２との間の対比によって、コンテンツのデータ量が削減されうることを説明しようとしているに過ぎない。
【００３０】
次に、図３のフローチャートを用いて、元のコンテンツ２０１からデータ量削減済みコンテンツ２０２を生成する処理の一例を説明する。データ量削減済みコンテンツ生成処理が開始されると（ステップ３０１）、ステップ３０２においてデータ量削減の対象となるコンテンツを検出する。対象となるコンテンツの選び方については、単にコンテンツの使用頻度が低いものを選ぶ以外にも、コンテンツの最終使用日時がもっとも古いもの、データ量が比較的大きいもの、コンテンツの価格が比較的安いもの、当該コンテンツを含むプレイリストの数が少ないもの、コンテンツや当該コンテンツに予め設定されている重要度のパラメータが低いもの、ユーザによって直接的・間接的に指定されたもの、使用の頻度が低いジャンルに属するコンテンツ、コンテンツの作成日時が古く、かつニュースなどのように古くなると価値が減損するコンテンツなど、さまざまな選び方が含まれる。さらには上述の例の任意の組み合わせなど、多くのバリエーションがある。
【００３１】
データ量削減の対象となる元のコンテンツ２０１を特定するまでこの処理を行う（ステップ３０３）。特定できたら、ステップ３０４より実際にデータ量削減済みコンテンツ２０２の生成処理に入る。なおこのフローチャートでは、元のコンテンツ２０１とは別にデータ量削減済みコンテンツ２０２生成用の領域を確保した上で順次データ量削減済みコンテンツを生成、最後のステップ３１０においてストレージ上の元のコンテンツ２０１を消去してデータ量削減済みコンテンツ２０２で置き換える、という手順を取っているが、必ずしもこの手順に限るものではない。
【００３２】
まず、ステップ３０４において、データ削減処理後のデータ量削減済みコンテンツ２０２全体での総データ量の目標値を算出している。総データ量の目標値は、元のコンテンツ２０１の総データ容量、記憶装置１０６の残り容量などを元に計算されるが、それらの情報以外に、前述のステップ３０２においてデータ量削減対象となるコンテンツを検出する際に用いたパラメータを使って目標値を調整することもできる。例えば、コンテンツの使用頻度が非常に低いものについては目標値を小さく設定することによって総データ量を大幅に削減する一方、コンテンツの使用頻度が比較的高いものについては総データ量の目標値を大きめに設定する、といったような応用が可能である。目標値を算出すると、ステップ３０５で、処理部分を設定する。
【００３３】
ステップ３０６では、３０４で計算した総データ量の目標値を参考にしながら、コンテンツの各処理部分ごとに割り当てられるデータ量を算出している。この割り当てはコンテンツ内の位置やコンテンツの内容などさまざまな要素に基づいて調整される。
【００３４】
例えば、コンテンツの開始部分２０７には比較的高い平均データ量、具体的には元の平均データ量２０４と同じ値を割り当てることが考えられる。後ほど再生処理についての項でも説明するが、データ量削減済みコンテンツ２０２を再生する際には、データ量削減部分２１１に相当するコンテンツ補完部分２１２が通信ネットワーク１００を通じてコンテンツサーバ装置１０１からダウンロードされる。このとき通信ネットワーク１００やコンテンツサーバ装置１０１の特性に応じて、必要な量のデータがダウンロードされるまでの間にある程度の応答時間が必要となる。この応答時間の間に開始部分２０７の再生を行うことにより、再生が開始するまでユーザを待たせたり、複数コンテンツの連続再生時に再生が途切れたりすることのないように構成することができる。ここで開始部分２０７の平均データ量を大きく設定しておくことにより、コンテンツ再生開始時点での再生品質を確保し、途切れることなくコンテンツ補完部分２１２の再生に移行することにより、ユーザにコンテンツのデータ量が削減されていたことをほとんど意識させることなく再生することが可能となるのである。なお、開始部分２０７がこのような用途であることを考慮すれば、開始部分２０７の長さは通信ネットワーク１００とコンテンツサーバ装置１０１の平均最悪ダウンロード応答時間よりも長く設定されることが望ましい。
【００３５】
なお、図２で説明したように、コンテンツの開始部分２０７に引き続いて準開始部分２０８を設けてもよい。これは通信ネットワーク１００やコンテンツサーバ装置の混雑度によっては応答時間が通常よりも長くなることがあるが、その場合においてもある一定以上の再生品質を保とうとするものである。
【００３６】
また一般に再生の途中で平均データ量を一度に大幅に減少させると、再生品質が急激に悪化してユーザに大きな違和感を持たせる原因となりうる。データ量漸減部分２０９のように平均データ量を段階的に削減する期間を設けることにより再生品質を徐々に悪化させ、ユーザの違和感を軽減することも考えられる。
【００３７】
なお、コンテンツの開始部分２０７はひとつのコンテンツに1箇所と限るものではない。従って、準開始部分２０８、データ量漸減部分２０９なども1箇所に限定されるわけではない。
【００３８】
さらに、コンテンツ中の１つ以上の重要部分２１０に対して比較的高い平均データ量を割り当てることも考えられる。コンテンツの重要部分２１０とは、例えば音楽であればサビの部分、動画であればコンテンツの構成上重要なシーン、あるいは人間の視聴覚特性上データ量を削減すると品質への影響が大きい部分など、コンテンツの他の部分に比べ平均データ量の削減をある程度避けるべき部分である。重要部分２１０であるかどうかはコンテンツのサブ情報などで予め指定されていてもよいし、ユーザによる直接的・間接的な指定を行ってもよいし、コンテンツそのものの情報、例えばコンテンツの音圧、周波数分布、画面の複雑度、動きの大きさなどの情報からある種のアルゴリズムによって導き出すことも可能である。
【００３９】
以上で説明した以外の、コンテンツ内のその他の部分に関しては比較的低い平均データ量が割り当てられる。通信ネットワーク１００やコンテンツサーバ装置１０１が十分に安定しているのであれば平均データ量を０に設定する、すなわちその他の部分についてのデータを完全に削除することもできる。
【００４０】
図３のフローチャートの説明に戻ると、ステップ３０７では、ステップ３０６で計算した部分ごとの目標平均データ量になるように、データ量削減済みコンテンツ２０２の各部分を生成する。データ量削減処理手法のひとつとしては、コンテンツデコード部１０３で一旦デコードを行った後、コンテンツエンコード部１０２で再度エンコードを行う方法がある。この場合、平均データ量を目標平均データ量に近づけるためには、エンコードの際に圧縮率等のパラメータを調整する他、コンテンツそのものに手を加える方法、例えば動画の解像度やフレームレートを落とす、オーディオサンプリング周波数を低減させる、チャネル数を削減するなど、さまざまな手法が考えられる。
【００４１】
また、再エンコードの際に、圧縮効率の高い別の符号化方式を採用することも考えられる。これは例えば、必要な消費電力が大きいが、より圧縮効率の高い符号化方式が利用可能な場合に有効である。なお、ここで説明しているデータ量削減処理は、再エンコードに限定するものではない。例えば、コンテンツ符号化の方式によっては、一旦デコードして再エンコードしなくても平均データ量が削減できる可能性があるが、ここでの記述はそうした可能性を排除するものではない。ステップ３０７で１つの区間の処理が完了すると、ステップ３０８で、次の処理部分を設定する。
【００４２】
そして、ステップ３０９においてデータ量削減処理が終了しかた否か判断し、終了していない場合には、ステップ３０６に戻って次の区間の処理を行う。ステップ３０９において終了したと判定されると、ステップ３１０において元のコンテンツ２０１をデータ量削減済みコンテンツ２０２で置き換える処理を行い、ひとつのコンテンツに対する処理が終了する。なお、フローチャートで示したように、記憶装置１０６の空き容量が十分確保されるまで以上の処理を繰り返し行うように構成することができる。
【００４３】
次に、図４のフローチャートを用いて、端末装置１１０での、データ量削減済みコンテンツ２０２の再生処理の一例を説明する。再生処理が開始されると（ステップ４０１）、ステップ４０２においてコンテンツ補完処理を起動する。コンテンツ補完処理は、例えば後述する図５のフローチャートで表現されるような処理であり、通信部１１１と通信ネットワーク１００を通じてコンテンツサーバ装置１０１からデータ量削減部分２１１に相当するコンテンツ補完部分２１２をダウンロードするものである。詳しくは次の節で説明する。なお、ここではコンテンツ補完処理が再生の処理と平行してバックグラウンドで動作するものと想定している。
【００４４】
補完処理を起動した上で、ステップ４０３においてデータ量削減済みコンテンツ２０２の適切な開始部分からコンテンツ再生を開始する。その後、ステップ４０４もしくはステップ４０８においてコンテンツ終了位置まで再生したと判定されるまで再生は継続される。なお、図４のフローチャートでは示していないが、ユーザの操作によりコンテンツ再生途中であっても再生を中断することは当然あり得る。
【００４５】
ステップ４０５では、データ量削減済みコンテンツ２０２の再生を進めた結果、データ量削減部分２１１に到達したか否かを判定している。もしデータ量削減部分２１１に到達していなければそのままデータ量削減済みコンテンツ２０２の再生が続けられる。
【００４６】
データ量削減部分２１１に到達した場合、ステップ４０６において、コンテンツ補完バッファ２０３内の補完コンテンツ部分２１２に当該データ量削減部分に相当する補完部分がダウンロードされているか否かを判定している。ステップ４０２において起動されたコンテンツ補完処理が何らかの原因によって滞っている場合、例えば通信ネットワーク１００への通信ができる環境外にいるときなどにおいては当該補完部分がまだダウンロードされていないことがある。その場合は引き続きデータ量削減済みコンテンツ２０２の再生を継続することになる。
【００４７】
一方、コンテンツ補完処理が滞りなく実行され、コンテンツ補完バッファ２０３内に当該補完部分が既にダウンロードされているのであれば、ステップ４０７に進み、当該補完部分に切り替えてコンテンツの再生を継続する。その後、補完コンテンツが続く限り補完コンテンツ部分２１２を優先的に再生し続けるが、いずれ補完コンテンツが存在しない箇所に到達する可能性がある。例えば、重要部分２１０のようなデータ量削減部分２１１の範囲外に到達した場合、あるいは通信環境の変動によりコンテンツ補完処理が滞ってしまった場合などである。このため、ステップ４０９では補完コンテンツが現在の再生位置から引き続き存在しているかどうかを確認しており、存在していなければステップ４１０にてデータ量削減済みコンテンツ再生への切り替えを行う。ステップ４１０の切り替えがあると、ステップ４０４に戻る。
【００４８】
次に、図５のフローチャートを用いて、コンテンツ補完処理の一例を説明する。ステップ５０１で補完処理が開始されると、ステップ５０２においてコンテンツサーバ装置１０１への接続を行い、接続が完了したらステップ５０３にてコンテンツ補完部分２１２のダウンロードを開始する。このとき、再生処理での現在の再生位置などを参照のうえ、最も次に再生を行われる可能性の高い箇所からダウンロードを行う。例えば、再生処理がユーザの指示等により、データ削減済みコンテンツ２０２の途中から再生を開始した場合には、現在の再生位置に応答遅延時間を加算した位置からダウンロードを行うことが考えられる。ここでいう応答遅延時間とは、通信ネットワーク１００とコンテンツサーバ装置１０１の特性や混雑度などに起因するもので、通信部１１１からコンテンツサーバ装置１０１に向けてダウンロードのリクエストを出してから実際にデータの受け取りが始まるまでの時間などを元にして算出することができる。
【００４９】
ステップ５０４においてはコンテンツ補完部分２１２のダウンロードがすべて完了したかどうかを判定している。図５のフローチャートには記述されていないが、補完コンテンツのダウンロードがすべて完了した時点で、データ量削減済みコンテンツ２０２とコンテンツ補完バッファ２０３の内容を組み合わせて元のコンテンツ２０１に相当する内容を復元する処理を行うことができる。また、補完コンテンツのすべてがダウンロードされていなくても、必要に応じてデータ量削減部分２１１の一部を該当するコンテンツ補完部分２１２で置き換えることも可能である。
【００５０】
コンテンツのダウンロードが完了していない間は引き続きダウンロードを行うが、通信環境の変化によってダウンロードが滞り、再生がダウンロードしようとしている箇所を追い抜いてしまった場合、あるいはユーザが再生位置を途中で変更したなどのさまざまな要因によって、現在ダウンロードをしようとしている箇所が必ずしも最適でなくなる可能性がある。ステップ５０５においてダウンロードしようとしている箇所が最適でないと判断された場合には、ステップ５０６に進み、コンテンツサーバ装置１０１に対するリクエストを再発行することによってダウンロード位置を調整することができる。
【００５１】
このように本実施の形態による処理を行うことで、以下に示す効果を有する。
１．利用頻度の低いコンテンツの後半部分のデータ量を削減することにより、より効率的に記憶装置を活用することができる。
２．コンテンツの先頭部分のデータを適切な品質で残しておくことにより、データ量を削減した場合でもユーザに意識させないように途切れなく再生を行うことができる。
３．通信環境がよくない場合でも最低限の品質での再生を継続することができる。
４．通信環境が変動している状況であっても、可能な限り最適な品質での再生を行うことができる。
５．一旦データ量が削減されたコンテンツであっても、再生のプロセスと同時に効率よく元のデータ量を復元することができる。
【００５２】
なお、上述した実施の形態では、サーバからダウンロードしたコンテンツの再生についての制限についての処理については特に説明しなかったが、例えば最初にサーバなどから試聴用のデータ(コンテンツの一部だけのデータ)を端末装置に配信して、そのデータを試聴した後に、購入手続きをすることで、全てのデータをダウンロードするようにしてもよい。
【００５３】
図６は、試聴コンテンツの例を示した図である。まず何らかの処理で記憶装置１０６に試聴コンテンツ６００を格納する。ここでいう何らかの処理とは、通信ネットワーク１００を通じてダウンロードをする以外にも、メモリカードのような外部記憶装置から記憶装置１０６に転送するなどさまざまなものが考えられるが、ここでは詳細には触れない。また、ここでは「試聴」コンテンツと呼んでいるが、音楽などのような聴取するコンテンツに限るわけではなく、動画などのような視覚的効果を持つものなども当然含まれる。
【００５４】
試聴コンテンツ６００は、開始部分６０１、ならびにヘッダ部分６０２、試聴部分６０３、トレーラ部分６０４からなっている。なお、試聴コンテンツにはこれらのすべての部分を備える必要はなく、例えばトレーラ部分６０４がないといったような構成、あるいは試聴部分６０３が存在しない構成なども考えられる。それ以外の部分については、データ量削減済みコンテンツ２０２で示したようにデータ量が削減された状態のコンテンツが格納されていてもよいが、図６では仮にそれ以外の部分のコンテンツのデータ量を０、すなわち完全に削除してある場合を記述している。また、ヘッダ部分６０２およびトレーラ部分６０４に関しては必ずしも元の平均データ量６０６と同じ平均データ量を持つ必要はない。
【００５５】
この試聴コンテンツ６００を試聴する場合には、ヘッダ部分６０２から再生が開始され、トレーラ部分６０４の再生が終わった時点で終了となる。購入手続きをしない場合には、開始部分については再生ができないように制限されている。もしユーザがこの試聴コンテンツ６００を購入することを決定した場合には、適切な決済処理などが行われたあと、開始部分６０１から再生できるようになる。
【００５６】
開始部分６０１からの再生は、図４および図５で説明された再生処理、コンテンツ補完処理と同様な手順で実行される。その結果としてユーザは購入したコンテンツの再生を待ち時間なく開始させることができ、コンテンツ補完処理がスムーズに進みさえすれば、開始部分６０１を再生し終わった後でも引き続き切れ目なくコンテンツの再生を楽しむことができる。但し、試聴コンテンツ６００のうちヘッダ部分６０２とトレーラ部分６０４は元のコンテンツとは異なる場合がある。こうした元のコンテンツと異なる部分はダウンロード必要部分６０５と識別され、コンテンツサーバ装置からダウンロードされたコンテンツ補完部分２１２で置き換えられることになる。
【００５７】
このように試聴コンテンツを用意することで、データ容量の比較的小さい試聴コンテンツを試聴した後、購入の処理を行えば待ち時間なくすぐにコンテンツの再生を開始することが可能になる。また、購入手続きが行われた後にも、試聴コンテンツの一部を再利用することにより、コンテンツ購入後のデータ通信量を削減できる。
【００５８】
なお、ここまで説明した実施の形態では、端末装置として、主として携帯電話端末などの機器を想定した場合について説明したが、その他のサーバとデータ転送可能な端末装置に適用可能である。例えば、パーソナルコンピュータ装置に、本発明の処理を行うプログラムをインストールして、同様の端末装置として機能させてもよい。プログラムについては、各種媒体に記憶させて配付させる他に、インターネットなどの伝送手段を使用して配信させるようにしてもよい。
【図面の簡単な説明】
【００５９】
【図１】本発明の一実施の形態によるシステム構成例を示すブロック図である。
【図２】本発明の一実施の形態によるデータ構成例を示す説明図である。
【図３】本発明の一実施の形態によるデータ量削減処理例を示したフローチャートである。
【図４】本発明の一実施の形態による再生処理例を示したフローチャートである。
【図５】本発明の一実施の形態によるコンテンツ補完処理例を示すフローチャートである。
【図６】本発明の一実施の形態による試聴コンテンツの例を示す説明図である。
【符号の説明】
【００６０】
１００…通信ネットワーク、１０１…コンテンツサーバ、１１０…端末装置、１１１…通信部、１１２…コンテンツエンコード部、１１３…コンテンツデコード部、１１４…コンテンツ再生部、１１５…記憶装置、１１６…制御部
【図１】
0004707478.tif 000002
【図２】
0004707478.tif 000003
【図３】
0004707478.tif 000004
【図４】
0004707478.tif 000005
【図５】
0004707478.tif 000006
【図６】
0004707478.tif 000007