WO2005048117A1

WO2005048117A1 - コンテンツ配信システム、コンテンツサーバ、コンテンツ受信装置、コンテンツ配信方法、プログラム及び記録媒体

Info

Publication number: WO2005048117A1
Application number: PCT/JP2004/016765
Authority: WO
Inventors: Takumi Tanabe; Kazuhide Sawabe
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2003-11-13
Filing date: 2004-11-11
Publication date: 2005-05-26
Also published as: US7539292B2; JP2005149029A; EP1684183A1; KR20060110866A; CN100570585C; US20070083663A1; CA2542864A1; CN1879093A; EP1684183A4

Abstract

　コンテンツの内部属性に応じた一つ以上の付加情報を加えて送受信を行うネットワークシステムにおいて、コンテンツ受信装置がどのような分割転送を想定しているかに関わらず、コンテンツサーバが送信するデータを決定できる。　コンテンツを一つ以上保持している蓄積手段１０１と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して、要求されている範囲のコンテンツのデータを蓄積手段１０１から取り出すコンテンツデータ取得手段と、取り出されたコンテンツのデータに付加情報を加えて送信する送信手段とを有するコンテンツサーバ１と、送信手段から送信されるコンテンツのデータおよび付加情報を受信する受信手段と、付加情報を考慮しないコンテンツの受信要求範囲を決定する受信データ決定手段と、要求範囲情報を含むデータ要求を送信するデータ要求送信手段とを有するコンテンツ受信装置２とを備える。

Description

明細書

コンテンツ酉 S信システム、コンテンツサーノ、コンテンツ受信装置、コンテンッ配信方法、プログラム及び記録媒体

技術分野

[0001] 本発明は、コンテンツの内部属性に基づく付加情報を付加したコンテンツを配信するコンテンツ酉己信システム、コンテンツサーノコンテンツ受信装置、コンテンツ酉己信方法、プログラム及び記録媒体に関するものである。

背景技術

[0002] コンテンツ受信装置がネットワークを介して、コンテンツサーバに蓄積されているコンテンッを受信しょうとする場合、一般に HTTP等の通信プロトコルを使ってコンテンッサーノにリクエストを送り、コンテンッデータを受信する。

[0003] しかし、単純にコンテンツだけを指定してリクエストを送った場合、一度のリクエストでコンテンツのすべてがコンテンツ受信装置に送られることになる。したがって、コンテンッ受信装置で通信プロトコルを扱うための受信バッファに制限がある場合でも、コンテンッの一部分だけを受信することができない。また、コンテンツ受信装置がすでにコンテンツのある部分を保持している場合でも、コンテンツを最初カゝら最後まで受信しなければならない。

[0004] このようなことを改善するために、いくつかの通信プロトコルでは、コンテンツのある一部分を取得することができるよう、ブロック転送をサポートしている。例えば HTTP であれば、 HTTPリクエストメッセージに Rangeヘッダを含ませることにより、ブロック転送を実現している（例えば、特開 2001— 101091号公報、 R. Fielding他著、 "Hy pertext Transfer Protocol-HTTP/ 1. 1"、 RFC2616参照。なおこれら文献の全ての開示は、そっくりそのまま引用する（参照する）ことにより、ここに一体化する。）。

[0005] コンテンツが AVコンテンツの場合も、上記と同様に AVコンテンツの送受信を行うことができる。特に AVコンテンツの場合には、コンテンツ受信装置は、内部のデコーダに AVコンテンツを送る前に、格納する受信バッファの空き状態を確認しながら、リクエストを送信する。この場合、上記のブロック転送を用いてコンテンツデータの送受信を行う。

[0006] しカゝしながら、コンテンツサーバからコンテンツを伝送する際、コンテンツの各部分の属性にもとづいて、付加情報を一定の規則に従って送信データに付加させることがあり、この場合、上記の従来のブロック転送を用いた伝送方法では、コンテンツ受信装置が受信すべきデータ範囲をコンテンツサーバに正しく要求できないという問題が出てくる。以下、従来のブロック転送を用いた伝送方法におけるこの問題点について説明する。

[0007] コンテンツサーバによって送信データに付加される付加情報としては、例えば、コンテンッのその部分の重要度についての情報や、暗号ィ匕に関する情報等がある。重要度についての付加情報は、例えば、コンテンツサーバとコンテンツ受信装置の間にある中継装置等がそれを見て、ネットワーク負荷が高、場合に重要度の高、ものから伝送するように制御するために利用される。暗号ィ匕に関する情報としては、例えば鍵に関する情報がある。

[0008] 付加情報は、コンテンツ内で対応する属性が変化するたびに付与される。例えば、重要度に関する付加情報であれば、コンテンツ内で重要度が変化するたびに付カロ情報がつけ直される。通信プロトコルの各転送単位 (パケットやメッセージ)毎に、その通信プロトコルのヘッダの後に付加情報が必ず付加される。これは、直前のバケツトゃメッセージがネットワーク上で失われた場合等に対処するためである。

[0009] 図 2 (a)は、コンテンツに対して付加情報が付与され、更に HTTPで伝送される場合の HTTPメッセージの例を示している。図 2 (a)では、コンテンツが重要度によって 3つのブロックに分けられている力図 2 (b) (c)に示す 2つの HTTPメッセージで送信する場合の例を示して!/、る。

[0010] 図 2 (b)に示す 1番目の HTTPメッセージでは、 HTTPヘッダの後に、コンテンツブロック 1のための付カ卩情報、コンテンツブロック 1、コンテンツブロック 2のための付カロ情報、コンテンツブロック 2の一部（前半）と続く。図 2 (c)に示す 2番目の HTTPメッセ一ジでは、 HTTPヘッダの後に、まずコンテンツブロック 2のための付加情報が続く。これは、 HTTPヘッダの後に付加情報を必ず付加するというルールによる。ついで、コンテンッブロック 2の一部（後半）、コンテンツブロック 3のための付カ卩情報、コンテンツブロック 3が続く。

[0011] 図 3 (a)一 (d)は、図 2と同じコンテンツを 3つの HTTPメッセージで送信する場合の例である。図 3 (b)—（d)に示す 3つの HTTPメッセージで、 3つのコンテンツブロックをそれぞれ送信する。

[0012] それぞれの HTTPメッセージのメッセージボディ（データ部）として送られるデータは、付加情報とコンテンツデータを合わせたものになる。 HTTPプロトコル上は付加情報かコンテンツデータかの区別がないので、同じデータとして扱い、 HTTPヘッダに含まれるデータ長（Content— Lengthヘッダの値)も、付加情報とコンテンツデータを合わせた値が書き込まれる。

[0013] コンテンツ受信装置力例えば HTTPの Rangeヘッダを使ってコンテンツサーバに含まれるコンテンツの一部分を取得しょうとする場合、このような付加情報があると問題が生じる。 HTTPで送受信されるデータは、コンテンツデータにいくつかの付加情報を含んだものとなる。従って、コンテンツ受信装置がコンテンツの一部分を取得しようとする場合、コンテンツに付加情報をカ卩えた全データを想定した上で、取得すべき範囲を指定しなければならな、。

[0014] ところ力図 2及び図 3からも分力るように、コンテンツをどのように分割するかによつてトータルで送受信される付加情報の数が変わってしまう。コンテンツ受信装置は、自身が想定する分割方法によって、コンテンツのリクエストを送信する。しかし、コンテンッサーバはコンテンツ受信装置がどのような分割方法を想定して、るか分力もなヽので、コンテンツ受信装置が実際に受信したいコンテンツの範囲を特定することができない。

[0015] また、コンテンツが AVコンテンツの場合、コンテンツ受信装置が、コンテンツサーバに蓄積されている画像や音声を含む AVコンテンツをネットワーク再生しょうとする場合、特に著作権管理に関する情報を付加情報として付加する場合がある。すなわち AVコンテンツのある部分は、コピーしてもかまわないが、他のある部分はコピーしてはならないといった情報である。この場合、コピーしてはならない部分は、ネットワーク上で暗号ィ匕して伝送されなければならない。また、定期的に鍵を更新するような暗号化を行った場合には、復号に関する情報が付加情報として付加される場合がある。

[0016] コンテンツが AVコンテンツの場合は、コンテンツ受信装置は、受信バッファの空き状態を確認しながら、 AVコンテンツの一部分を取得するようなリクエストを送信する。 AVコンテンツの分割方法は、受信バッファがどの程度空、た時にリクエストを送信するかに依存して決まる。この場合、著作権管理に関する情報等の付加情報がコンテンッの途中に付カロされる場合、コンテンツ受信装置が、 AVコンテンツをどのように分割するかによって、 AVコンテンツに付加情報をカ卩えた、 HTTPカゝらみたトータルのデータ長が変わってしまう。従って、コンテンツサーバは、コンテンツ受信装置が実際に再生した!/、AVコンテンツの範囲を特定することができな、。

[0017] 上記のような課題が生じる例として、例えば DTCP— IP (例えば DTCP Volume 1 supplement E Mapping DTし P to IP(Informational Version) Revision 1.0 November24, 2003を参照）がある。 DTCP-IPでは、付加情報として著作権情報と鍵を含む PCP ヘッダが定義されている。 PCPヘッダは、送信するコンテンツの著作権属性が変化するたびに付カ卩される。また、コンテンツを運ぶすべての HTTPレスポンスメッセージの先頭 (HTTPヘッダの直後）にも PCPヘッダが付加される。

発明の開示

[0018] 本発明は、上記従来の課題を解決するもので、コンテンツ受信装置が想定する受信範囲のコンテンツデータを確実にコンテンツサーノくから受信できる、コンテンツ酉己信システム、コンテンツサーノコンテンツ受信装置およびコンテンツ酉己信方法を提供することを目的とする。

[0019] 上述した課題を解決するために、第 1の本発明は、

コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケットィ匕する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システム【しお！、て、

コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されて、る範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを有するコンテンツサーバと、

前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段と、前記付加情報を考慮しな、前記コンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段とを有するコンテンツ受信装置とを備え、

前記コンテンツデータ取得手段は、前記データ要求送信手段が送信した前記データ要求力前記要求されてヽる範囲を特定する、コンテンツ配信システムである。

[0020] 第 2の本発明は、

コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケットィ匕する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツサーバにおいて、

コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されて、る範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを備えたコンテンツサーバである。

[0021] 第 3の本発明は、

前記通信プロトコルは、 HTTPであり、

前記データ要求には、前記付加情報を考慮しな!、前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、第 2の本発明のコンテンツサーバである。

[0022] 第 4の本発明は、

前記コンテンツは、画像および/または音声を含む AVコンテンツである、第 2または第 3の本発明のコンテンツサーバである。

[0023] 第 5の本発明は、前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んで、る

、第 2乃至第 4の、ずれかの本発明のコンテンツサーバである。

[0024] 第 6の本発明は、

前記コンテンツが暗号ィ匕されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、第 2乃至第 5のいずれかの本発明のコンテンツサーバである。

[0025] 第 7の本発明は、

コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケットィ匕する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツ受信装置において、

付加情報を考慮しないコンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を示す要求範囲情報を含むデータ要求を送信するデータ要求送信手段と、前記コンテンツのデータおよび前記付加情報を受信する受信手段とを備えた、コンテンツ受信装置である。

[0026] 第 8の本発明は、

前記受信手段は、受信した前記コンテンツのデータおよび前記付加情報から、前記コンテンッのデータのみを受信バッファに格納する、第 7の本発明のコンテンッ受信装置である。

[0027] 第 9の本発明は、

前記通信プロトコルは、 HTTPであり、

前記データ要求には、前記付加情報を考慮しな!、前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、第 7の本発明のコンテンツ受信装置である。

[0028] 第 10の本発明は、

前記コンテンツは、画像および/または音声を含む AVコンテンツである、第 7の本発明のコンテンツ受信装置である。

[0029] 第 11の本発明は、前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んで、る

、第 7または第 10の本発明のコンテンツ受信装置である。

[0030] 第 12の本発明は、

前記コンテンツが暗号ィ匕されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、第 7または第 10の本発明のコンテンッ受信装置である。

[0031] 第 13の本発明は、

一つ以上のコンテンツを蓄積しているコンテンツサーバと、前記コンテンツサーバから前記コンテンツをネットワークを介して受信するコンテンツ受信装置とを利用して前記コンテンツの送受信を行うコンテンツ配信方法において、

前記コンテンツサーバは、付加情報を考慮しな、コンテンツの要求範囲情報を含むデータ要求を受信して要求されて、る範囲を特定し、前記要求されて、る範囲のコンテンツのデータを前記蓄積手段から取り出すステップと、取り出された前記コンテンッのデータに前記付加情報を加えて送信するステップとを有し、

前記コンテンツ受信装置は、前記付加情報を考慮しな!ヽ前記コンテンツの受信要求範囲を決定するステップと、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するステップと、前記送信手段から送信される前記コンテンッのデータおよび前記付加情報を受信するステップとを有する、コンテンツ配信方法である。

[0032] 第 14の本発明は、

第 1の本発明のコンテンツ配信システムの、

前記コンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されている範囲を特定し、前記要求されている範囲の前記コンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段、取り出された前記コンテンッのデータに前記付加情報を加えて送信する送信手段、

前記コンテンツ受信装置の、前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段、前記付加情報を考慮しな!ヽ前記コンテンッの受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段、としてコンピュータを機能させるためのプログラムである。

[0033] 第 15の本発明は、

第 2の本発明のコンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しな!、前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されて、る範囲を特定し、前記要求されて、る範囲の前記コンテンッのデータを前記蓄積手段力取り出すコンテンツデータ取得手段、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段、としてコンピュータを機能させるためのプログラムである。

[0034] 第 16の本発明は、

第 7の本発明のコンテンツ受信装置の、前記付加情報を考慮しないコンテンツの前記受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を示す前記要求範囲情報を含む前記データ要求を送信するデータ要求送信手段、前記コンテンツのデータおよび前記付加情報を受信する受信手段、としてコンピュータを機能させるためのプログラムである。

[0035] 第 17の本発明は、

第 14一第 16のいずれかの本発明のプログラムを記録した記録媒体であって、コンピュータで利用可能な記録媒体である。

[0036] 本発明により、コンテンツ受信装置が想定する受信範囲のコンテンツデータを確実にコンテンツサーバから受信できる、コンテンツ配信システム、コンテンツサーバ、コンテンッ受信装置、コンテンツ配信方法、プログラムおよび記録媒体を提供できる。図面の簡単な説明

[0037] [図 1(a)]本発明の実施の形態 1のコンテンツ送受信システムにおける、コンテンツサーバとコンテンツ受信装置間のシーケンス図

[図 1(b)]本発明の実施の形態 1のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 1(c)]本発明の実施の形態 1のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 1(d)]本発明の実施の形態 1のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 1(e)]本発明の実施の形態 1のコンテンッ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 1(D]本発明の実施の形態 1のコンテンッ送受信システムにおける、 HTTPメッセ一ジの構成を示す図

[図 1(g)]本発明の実施の形態 1のコンテンッ送受信システムにおける、 HTTPメッセージの構成を示す図

[図 2(a)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 2(b)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 2(c)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 3(a)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 3(b)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 3(c)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 3(d)]コンテンツデータを分割送信する際の HTTPメッセージの構成を示す図

[図 4]本発明の実施の形態 1のコンテンツ配信システムのネットワークの構成を示す図圆 5]本発明の実施の形態 1で説明するコンテンツの構成を示す図

[図 6]本発明の実施の形態 1で説明するコンテンツの属性テーブルを示す図

[図 7]本発明の実施の形態 1のコンテンツサーバの構成を示すブロック図

[図 8]本発明の実施の形態 1のコンテンツサーバの動作を示すフローチャート圆 9]本発明の実施の形態 1のコンテンツ受信装置の構成を示すブロック図圆 10]本発明の実施の形態 1のコンテンツ受信装置の動作を示すフローチャート

[図 11]本発明の実施の形態 2のコンテンツ配信システムのネットワークの構成を示す図

[図 12(a)]本発明の実施の形態 2のコンテンツ送受信システムにおける、 AVサーバと AVコンテンツ再生装置間の送受信を記述したシーケンス図

[図 12(b)]本発明の実施の形態 2のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 12(c)]本発明の実施の形態 2のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 12(d)]本発明の実施の形態 2のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 12(e)]本発明の実施の形態 2のコンテンツ送受信システムにおける、 HTTPメッセージ内容を示す図

[図 12(D]本発明の実施の形態 2のコンテンツ送受信システムにおける、 HTTPメッセージの構成を示す図

[図 12(g)]本発明の実施の形態 2のコンテンツ送受信システムにおける、 HTTPメッセージの構成を示す図

[図 13]本発明の実施の形態 2の AVサーバの構成を示すブロック図

[図 14]本発明の実施の形態 2の AVコンテンツ再生装置の構成を示すブロック図圆 15]本発明の実施の形態 2で説明する AVコンテンツの構成を示す図

[図 16]本発明の実施の形態 2で説明する AVコンテンツの属性テーブルを示す図

[図 17]本発明の実施の形態 2の AVサーバの動作を示すフローチャート

[図 18]本発明の実施の形態 2の AVコンテンツ再生装置の動作を示すフローチャート符号の説明

1 コンテンツサーバ

101 蓄積手段

102 データ要求受信手段

103 コンテンツデータ取得手段

104 送信データ構成手段

105 送信手段

106 属性テーブル保持送信手段

2 コンテンツ受信装置

201 ユーザ入力手段

202 受信データ決定手段 203 データ要求送信手段

204 受信手段

205 受信バッファ

206 コンテンツ処理手段

207 属性テーブル保持受信手段

3 ネットワーク

13 AVサーバ

1301 再生開始要求受信手段

1302 AVコンテンツデータ取得手段

1303 暗号手段

1304 暗号鍵生成手段

14 AVコンテンツ再生装置

1401 再生開始要求送信手段

1402 再生手段

1403 復号手段

1404 復号鍵生成手段

発明を実施するための最良の形態

[0039] 以下、本発明の実施の形態について、図面を参照しながら説明する。

[0040] (実施の形態 1)

図 4は、本発明の実施の形態 1のコンテンツ配信システムの構成図である。

[0041] コンテンツサーバ 1は、蓄積手段 101に記録されているコンテンツを、コンテンツ受信装置 2からの要求に応じて、ネットワーク 3上に送信する。コンテンツ受信装置 2は、コンテンツサーバ 1からコンテンツを受信し、コンテンツの内容に応じた処理を行う。コンテンッの例としては、テキスト、画像、音声、実行ファイル等である。

[0042] まず、本実施の形態 1のコンテンツ配信システムにおける、コンテンツ受信装置 2からコンテンツサーバ 1に受信データ範囲を指定するプロトコル制御方法にっ、て説明する。

[0043] 図 1 (a)は、コンテンツサーバ 1とコンテンツ受信装置 2間の送受信を記述したシーケンス図である。本実施の形態 1では、この送受信に HTTPを用いている。図 1 (b)— (e)は、 HTTPメッセージの内容を、図 1 (f) (g)は、 HTTPメッセージの構成をそれぞれ示している。ただし、本発明において送受信のプロトコルは問わない。図 1は、コンテンッサーバ 1の蓄積手段 101に記録されているコンテンツとしての実行ファイル ho ge. exeを、コンテンツ受信装置 2がコンテンツの最初から、分割受信する場合の例である。

[0044] 図 5に、 hoge. exeの構成を f列示する。 hoge. exeiま、トータノレサイズ力 ^50000ノィトで、重要度の異なるいくつかのブロックから構成されている。 1番目のブロックは 300 0バイト、 2番目のブロックは 8000バイトである。なお、重要度によるブロック分けは一つの例である。他の属性によるブロック分けでもよぐまたブロック分けがない（全コンテンッが 1ブロックの）コンテンツでもよい。また、トータルサイズやブロックサイズも問わない。図 4に示す蓄積手段 101は、ハードディスクなどの不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。

[0045] 図 1 (a)で、コンテンツ受信装置 2は、最初に、取得したいコンテンツに関する属性テーブルを要求し、コンテンツサーバ 1から属性テーブルを取得する。属性テーブルは、コンテンツの内部でコンテンツの属性（内部属性）がどのように変化しているのかを示す表である。コンテンツを伝送する際に、属性の変わり目に付加情報を付加するため、この表が必要となる。

[0046] 図 6に、 hoge. exeの属性テーブルの例を示す。オフセットはコンテンツの始まり力らのバイト長を示している。この表から、 0バイト目力も 2999バイト目までの重要度が 6 、 3000ノィ卜目力ら 10999ノィ卜目までの重要度力 ^1、 11000ノィ卜目力ら重要度力 S 3に変化するということが分かる。属性テーブルの取得には HTTPを利用してもよいし、また別の通信プロトコルを使ってもよい。

[0047] 図 1 (a)に示すように、コンテンツ受信装置 2は、属性テーブルの取得後、データ要求であるメッセージ 1をコンテンツサーバ 1に向けて送信する。図 1 (b)に示すように、メッセージ 1は Rangeヘッダを含み、 hoge. exeの 0ノイト目力ら 5999ノイト目までの送信を要求している。また、メッセージ 1は、データ範囲情報である「0— 5959」を持つ X— Real— Range拡張ヘッダを含む。これは、付加情報を含まないコンテンツデータの 0バイト目から 5959バイト目までを要求していることを示す。なお、本実施の形態 1 のコンテンツ配信システムで用いられる付加情報の長さは 20バイトとする。

[0048] なお、 X— Real— Range拡張ヘッダは、本発明の要求範囲情報の一例であり、メッセージ 1およびメッセージ 2が、本発明の、要求範囲情報を含むデータ要求の一例である。

[0049] コンテンツサーバ 1はこのメッセージ 1を受信すると、メッセージ 2を送信する。図 1 (c )に示すように、メッセージ 2は、 Content— Rangeヘッダを含み、 0ノイト目力ら 5999 ノイト目までの送信を行うことを示している。そのうち、付加情報を含まないコンテンツデータの送信範囲は、 0バイト目力も 5959バイト目である。これに二つの付加情報をカロえて、 0バイト目力も 5999バイト目までの送信となっている（図 1 (f)参照）。コンテンッ受信装置 2は、受信したメッセージ 2に所定の処理を行った後、受信データに含まれるコンテンツデータの 0バイト目力も 5959バイト目までを取り出して、コンテンツの処理を行う。

[0050] 図 1 (d)、 (e)にそれぞれ示すように、メッセージ 3及びメッセージ 4についても同様である。ただしメッセージ 4では、 HTTPメッセージの途中でコンテンツの属性が変化しないので、付加情報は一つだけカ卩えられる（図 1 (g)参照)。以降、コンテンツの最後まで達する力コンテンツ受信装置 2のユーザによってコンテンツ受信が停止されるまで、上記のメッセージの送受信を繰り返す。

[0051] 次に、本実施の形態 1のコンテンツ配信システムにおけるコンテンツサーバ 1の構成と動作について説明する。

[0052] 図 7は、本実施の形態 1のコンテンツサーバ 1の構成を示すブロック図である。図 7 で、蓄積手段 101には一つ以上のコンテンツが蓄積されている。データ要求受信手段 102は、ネットワーク 3を介してコンテンツ受信装置 2からのデータ要求を受信する。データ要求は、コンテンツを識別する情報であるコンテンツ識別子と、当該コンテンッ識別子で識別されるコンテンツのどの範囲を送信すべき力を指示する情報であるデータ範囲情報を含んで、る。

[0053] コンテンツデータ取得手段 103は、データ要求受信手段 102が受信したデータ要求に含まれるデータ範囲情報から、送信すべき範囲のコンテンツデータを蓄積手段 101から取り出して、送信データ構成手段 104に渡す。

[0054] 送信データ構成手段 104は、渡された範囲のコンテンツデータに、当該コンテンツデータを送信する際に必要な付加情報を加えて、送信データを構成する。どのような付加情報が必要かは、属性テーブル保持送信手段 106に問い合わせて確認する。属性テーブル保持送信手段 106は、各コンテンツ毎の属性テーブルを保持して、る

[0055] そして、送信手段 105は、送信データ構成手段 104から渡された送信データを、ネットワーク 3を介してコンテンツ受信装置 2宛てに、 HTTPに従って送信する。

[0056] また、属性テーブル保持送信手段 106は、ネットワーク 3を介してコンテンツ受信装置 2からの属性テーブル要求を受信して、送信手段 105を介してコンテンツ受信装置 2宛てに、対応する属性テーブルを送信する。

[0057] 図 8は、本実施の形態 1のコンテンツサーバ 1の動作を示すフローチャートである。

以下、図 7および図 8を使い、図 1 (a)を用いて説明したシーケンスにおけるコンテンッサーバ 1の動作を説明する。

[0058] 属性テーブル保持送信手段 106は、コンテンツ受信装置 2から取得したいコンテンッのコンテンツ識別子を含む属性テーブル要求を受信すると (ステップ 1)、当該コンテンッに対応する属性テーブルを、送信手段 105を介してコンテンツ受信装置 2宛てに送信する (ステップ 2)。

[0059] 次!、で、データ要求受信手段 102が、データ要求である HTTPメッセージ（GETメソッドを含む；図 1 (b)のメッセージ 1、図 1 (d)のメッセージ 3)を受信する（ステップ 3) と、この HTTPメッセージがコンテンツデータ取得手段 103に渡される。

[0060] コンテンツデータ取得手段 103は、受信した HTTPメッセージからコンテンツ識別子である URI (本実施の形態 1では Zhoge. exe)を抽出し、また X— Real— Range拡張ヘッダ力もデータ範囲情報を抽出する。コンテンツデータ取得手段 103は、コンテンッ識別子で示された蓄積手段 101に格納されて、るコンテンツから、データ範囲情報で示される範囲のコンテンツデータを取得する（ステップ 4)。コンテンツデータ取得手段 103は、抽出したコンテンツ識別子及びデータ範囲とともに、取得したコンテンツデータを送信データ構成手段 104に渡す。 [0061] 送信データ構成手段 104は、属性テーブル保持送信手段 106に含まれるこのコンテンッ識別子に対応する属性テーブルを参照する。要求されてヽるデータ範囲の属性がどのようになっているかを確認し、そのデータ範囲の開始点力も属性が同一の範囲を確認する。例えば、図 1 (b)のメッセージ 1であれば、まず 0バイト目力 2999ノイト目までが、重要度 6で同一の属性をもっていることを確認する (ステップ 5)。

[0062] 次いで、送信データ構成手段 104は、属性が同一の範囲にあるコンテンツデータの先頭に付加情報を加える (ステップ 6)。付加情報には重要度の情報が含まれる。送信すべきデータが要求されたデータ範囲の最後までに達して、なければ (ステップ 7)、ステップ 5に戻る。図 1 (b)のメッセージ 1の例で言えば、 3000ノイト目から、データ範囲の終わりである 5959バイト目までが重要度 1であることが確認され、コンテンツデータの 2999バイト目と 3000バイト目の間に付加情報が加えられる。

[0063] ステップ 7でデータ範囲の最後に達したら、送信データ構成手段 104は、コンテンッデータに付加情報を加えた送信データを送信手段 105に送り、送信手段 105はこれを HTTPに則って送信する（ステップ 8)。この際、 HTTPメッセージの Content— R angeヘッダには、付加情報を加えた時のデータ範囲が書き込まれる。そして、送信データを送信後、ステップ 3に戻る。

[0064] ステップ 3で、データ要求を受信して!/、ない間に、コンテンツ受信装置 2から新たな属性テーブル要求を受信した場合 (ステップ 9)、ステップ 2に戻って対応する属性テ一ブルを送信する。不正なメッセージを受信すると（ステップ 10)、エラーレスポンスを送信し (ステップ 11)、ステップ 1に戻る。データ要求も属性テーブル要求も受信できないうちに所定時間が経過してタイムアウトした場合は (ステップ 12)、ステップ 1に戻る。

[0065] 次に、本実施の形態 1のコンテンツ配信システムにおけるコンテンツ受信装置 2の構成と動作につ!、て説明する。

[0066] 図 9は、本実施の形態 1のコンテンツ受信装置 2の構成を示すブロック図である。

[0067] ユーザ入力手段 201は、コンテンツサーバ 1から受信しょうとするコンテンツを識別する情報であるコンテンツ識別子 (名前など)などのユーザー力もの入力を受け付ける。具体的には、ユーザ入力手段 201は、コンテンツ識別子と取得したいデータの範囲（1メガノイト目以降等)を受け付ける。なお、ユーザ入力手段 201は、コンテンツ識別子のみを受け付けてもよい。ユーザ入力手段 201が受け付ける情報の入力手段は、テンキーやキーボードやマウスやリモコンを使ってメニュー画面を操作するもの等、何でも良い。ユーザ入力手段 201は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。

[0068] 受信データ決定手段 202は、ユーザ入力手段 201からの通知、受信バッファ 205 の空き容量に関する問い合わせ結果、受信手段 204からの通知等を受けて、要求するデータ範囲を決定する。データ範囲情報は、ユーザ入力手段 201が受け付けた情報や、受信バッファ 205の空き容量に関する問い合わせ結果、受信手段 204からの通知等に基づ！/ヽて決定され得る。

[0069] データ要求送信手段 203は、受信を要求するコンテンツのコンテンツ識別子とデータ範囲情報を含むデータ要求を生成し、ネットワーク 3を介してコンテンツサーノ 1宛てに送信する。この際、属性テーブル保持受信手段 207を参照して、受信データ決定手段 202が決定したデータ範囲情報に加え、このデータ範囲情報に付加情報を加味した要求範囲を含むデータ要求を生成する。図 1 (b)のメッセージ 1や図 1 (d)のメッセージ 3では、データ範囲情報は X— Real— Range拡張ヘッダに書き込まれ、付加情報を含めた範囲は Rangeヘッダに書き込まれる。

[0070] 受信手段 204は、ネットワーク 3から付加情報が加えられたコンテンツデータを受信し、コンテンツデータを受信バッファ 205に渡すとともに、受信したコンテンツデータの長さまたは受信したコンテンツデータの終点位置を受信データ決定手段 202に通知する。受信手段 204は、コンテンツデータを受信バッファ 205に送る前または後に付加情報を解析して、処理が必要な場合には適当な処理を行う。例えば、付加情報からコンテンツデータが暗号ィ匕されていることが分かれば、復号処理を行う。

[0071] コンテンツ処理手段 206は、受信バッファ 205からコンテンツデータを順次読み込んで必要な処理を行う。例えば、画面に表示をしたり所定の計算をしたりする。コンテンッ処理手段 206は、ディスプレイやスピーカ一等の出力デバイスを含むと考えても含まないと考えても良い。コンテンツ処理手段 206は、出力デバイスのドライバーソフトウエアと処理ソフトウェアまたは、出力デバイスのドライバーソフトと出力デバイスと処理ソフトウェアまたは、 MPU上のアプリケーションプログラム等で実現され得る。

[0072] 属性テーブル保持受信手段 207は、コンテンツの受信に必要な属性テーブルを要求する属性テーブル要求を、ネットワーク 3を介してコンテンツサーバ 1宛てに送信する。そして、その応答としてコンテンツサーバ 1から受信手段 204を介して属性テープルを受信し、保持する。また、属性テーブルは、データ要求送信手段 203から参照される。

[0073] 図 10は、本実施の形態 1のコンテンツ受信装置 2の動作を示すフローチャートである。以下、図 9および図 10を使い、図 1 (a)を用いて説明したシーケンスにおけるコンテンッ受信装置 2の動作を説明する。

[0074] ユーザ入力手段 201は、コンテンツサーバ 1にあるコンテンツの受信開始要求を受けると (ステップ 1)、要求するコンテンツ識別子 (本実施の形態 1では Zhoge. exe) を受信データ決定手段 202と属性テーブル保持受信手段 207に通知する。このとき、ユーザ入力手段 201に受信したいコンテンツの範囲も入力された場合、そのデータ範囲も受信データ決定手段 202に通知する。

[0075] 属性テーブル保持受信手段 207は、ユーザ入力手段 201から通知されたコンテンッ識別子に対応するコンテンツの属性テーブルを保持してヽるかどうかを判定し (ステツプ 2)、保持していなければ属性テーブル要求をネットワーク 3を介してコンテンツサーバ 1宛てに送信する (ステップ 3)。

[0076] そして、受信手段 204は、属性テーブルを受信すると (ステップ 4)、受信した属性テ一ブルを属性テーブル保持受信手段 207に渡す。属性テーブル保持受信手段 207 は、属性テーブルを渡されると、対応するコンテンツ識別子に関連づけて属性テープルを保存し、受信データ決定手段 202へその旨を通知する。

[0077] 受信データ決定手段 202は、ユーザがユーザ入力手段 201に入力した受信したいデータの範囲と、受信バッファ 205の空き容量から、コンテンツサーバ 1に送信する要求すべきデータ範囲を決定する (ステップ 5)。そして、コンテンツ識別子とともに決定したデータ範囲を示すデータ範囲情報を、データ要求送信手段 203に通知する。

[0078] データ要求送信手段 203は、受信データ決定手段 202から通知されたコンテンツ識別子とデータ範囲情報、及び属性テーブル保持受信手段 207を参照することにより、受信するコンテンツデータとともに得られる付加情報まで含めた要求範囲を含むデータ要求（図 1 (b)のメッセージ 1、図 1 (d)のメッセージ 3)を生成し、コンテンツサーバ 1宛てに送信する (ステップ 6)。

[0079] 受信手段 204は、送信したデータ要求に対応する付加情報が加えられたコンテンッデータ（図 1 (c)および (f)に示すメッセージ 2、図 1 (e)および (g)に示すメッセージ 4)を受信すると (ステップ 7)、付加情報を解析する (ステップ 8)。付加情報が重要度に関する情報のみ力成っている場合は、コンテンツ受信装置 2は付加情報について特に何も処理する必要がないので、受信手段 204は、付加情報を取り除いてコンテンッデータを受信バッファ 205に格納する。このコンテンツデータは、コンテンツ処理手段 206に順次読み込まれて処理される (ステップ 9)。

[0080] 受信手段 204がすべての付加情報を解析し終わっていない（つまり、コンテンツ処理手段 206に読み込まれていないコンテンツデータがある）ならば (ステップ 10)、ステツプ 8以降を繰り返す。

[0081] ユーザ入力手段 201に入力されたコンテンッ識別子に対応するコンテンッのすベて (データ範囲も入力された場合はその範囲）を受信するか、ユーザがユーザ入力手段 201に停止を指示した場合 (ステップ 11)は、最初 (ステップ 1)に戻る。

[0082] ステップ 2で、以前の通信等により、属性テーブル保持受信手段 207にすでに当該コンテンツに対応する属性テーブルが保持されて、る場合は、属性テーブルの交換は行わず、ステップ 5に進む。ただし、この場合でも属性テーブルの交換を行ってもよい。

[0083] ステップ 4またはステップ 7で、受信できないままタイムアウトしたり、またはコンテンツサーバ 1からエラーレスポンスを受信した場合 (ステップ 12、 13)は、エラー処理を行い (ステップ 14)、最初 (ステップ 1)に戻る。

[0084] 本実施の形態 1のコンテンツ配信システムにより、コンテンツサーバ 1が、付加情報を除いた実際に送信すべきコンテンツの範囲を特定することができる。コンテンツ受信装置 2は、コンテンツの分割方法に関わらず、付加情報を除いた実際に送信すベきコンテンツデータの範囲を旨定できるので、コンテンツサーノ 1は、コンテンツ受信装置 2がどのように分割受信を想定しているかを知らずとも、コンテンツサーバ 1は送るべきコンテンツの範囲が分かる。

[0085] また、コンテンツ受信装置 2が、コンテンツの途中のデータ力も受信をしたい場合でも、コンテンツサーバ 1に、そのコンテンツデータの受信開始位置を正確に指定できるので、コンテンツ受信装置 2は、コンテンツの途中のデータ力でも受信することがでさるよう〖こなる。

[0086] また、本実施の形態 1のコンテンツ配信システムにより、コンテンツサーバ 1での効果を、標準プロトコルである HTTPで実施できる。

[0087] なお、本実施の形態 1であげた実行ファイル hoge. exeというコンテンツは一例であり、その他のコンテンツ、例えば、画像や音声を含む AVコンテンツやその他のフォーマットでもよ、ことは言うまでもな、。

[0088] また、本実施の形態 1において、コンテンツサーバ 1とコンテンツ受信装置 2の間に、例えば、中継装置が存在し、コンテンツ受信装置 2から中継装置にデータ要求が送信され、中継装置がコンテンツサーバ 1をアクセスし、コンテンツを取得して、コンテンッ受信装置 2に当該コンテンツを送信してもよい。つまり、コンテンツサーバ 1とコンテンッ受信装置 2は、直接にネットワークで、データの送受信を行う必要は必ずしもない

[0089] また、本実施の形態 1のコンテンツ配信システムでは、コンテンツデータの受信の前に、コンテンツ受信装置 2が、属性テーブルをネットワーク 3を介してコンテンツサーバ 1から予め受信することとした力コンテンツ受信装置 2は、その他の方法で属性テーブルを取得、保持しておいてもよい。例えば、コンテンツサーバ 1とは異なるサーバ等力もネットワークを介して属性テーブルを取得するようにしてもょ、し、ネットワークを介さず、記録媒体等に記録された属性テーブルを予め読み込み、保持しておくようにしてもよい。

[0090] (実施の形態 2)

図 11は、本発明の実施の形態 2のコンテンツ配信システムの構成図である。実施の形態 1と同一の構成要素には同一の符号を付し、説明は省略する。

[0091] まず、本実施の形態 2のコンテンツ配信システムにおける、 AVコンテンツ再生装置 14から AVサーバ 13に再生データ範囲を指定するプロトコル制御方法について説明する。

[0092] AVサーバ 13は、蓄積手段 101に記録されている画像または音声またはその両方を含む AVコンテンツを、 AVコンテンツ再生装置 14からの再生要求に応じて、ネットワーク 3上に送信する。 AVコンテンツ再生装置 14は、 AVサーバ 13から AVコンテンッを受信し、再生手段 1402で再生する。 AVコンテンツの例としては、 MPEG動画像、 AC3音声、 JPEG静止画等である。なお、 AVサーバ 13、 AVコンテンツ再生装置 14は、それぞれ、本発明のコンテンツサーノ、コンテンツ再生装置の一例である。

[0093] 図 12 (a)は、 AVサーバ 13と AVコンテンツ再生装置 14間の送受信を記述したシ一ケンス図である。本実施の形態 2では、この送受信に HTTPを用いている。図 12 ( b)—（e)は、 HTTPメッセージの内容を、図 12 (f)および（g)は、 HTTPメッセージの構成をそれぞれ示している。ただし、本実施の形態 2において送受信のプロトコルは問わない。図 12 (a)—（g)は、 AVサーバ 13の蓄積手段 101に記録されている AVコンテンッ hogehoge. mpgを、 AVコンテンツ再生装置 14が AVコンテンツの最初から、ネットワーク再生する場合の例である。ここで、 hogehoge. mpgは、 MPEG動画像フアイノレである。

[0094] 図 15に、 hogehoge. mpgの構成を例示する。 hogehoge. mpgは、トータルサイズ力 S4000000000バイトで、著作権保護についての属性が異なるいくつかのブロック力ら構成されている。 1番目のブロックは 100000ノイト、 2番目のブロックは 80000 ノ《イトである。なお、著作権保護属性によるブロック分けは一つの例である。他の属性によるブロック分けでもよぐまたブロック分けがない（全コンテンツが 1ブロックの） A Vコンテンツでもよい。また、トータルサイズやブロックサイズも問わない。図 11に示す蓄積手段 101は、ハードディスクなどの不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。

[0095] 図 12 (a)で、 AVコンテンツ再生装置 14は、最初に、取得したい AVコンテンツに関する属性テーブルを要求し、 AVサーバ 13から取得する。属性テーブルは、 AVコンテンッの内部で AVコンテンツの著作権保護属性（内部属性）がどのように変化しているのかを示す表である。 AVコンテンツを伝送する際に、著作権保護属性の変わり目に付加情報を付加するため、この表が必要となる。 [0096] 図 16に、 hogehoge. mpgの属性テーブルの例を示す。オフセットは AVコンテンツの始まりからのバイト長を示す。この表から、 0バイト目から 99999バイト目までは著作権保護が必要、 100000バイト目から 179999バイト目までは著作権フリーでネットヮーク 3上での暗号化も不要、 180000バイト目力も著作権フリーだがネットワーク 3上での暗号化は必要、という属性に変化する。属性テーブルの取得には HTTPを利用してもょ、し、また別の通信プロトコルを使ってもょ、。

[0097] 図 12 (a)に示すように、 AVコンテンツ再生装置 14は、属性テーブルの取得後、再生開始要求であるメッセージ 1を AVサーバ 13に向けて送信する。図 12 (b)に示すように、メッセージ 1ίま Rangeヘッダを含み、 hogehoge. mpgの 0ノィ卜目力ら 80009 バイト目までの送信を要求している。また、メッセージ 1は、再生範囲情報である「0— 7 9999」を持つ X— Real— Range拡張ヘッダを含む。これは、付カ卩情報を含まない AV コンテンツデータの 0バイト目力ら 79999ノイト目までを要求して!/、ることを示す。なお、本実施の形態 2の AVコンテンツ送受信システムで用いられる付加情報の長さは 10バイトとする。

[0098] なお、 X— Real— Range拡張ヘッダは、本発明の要求範囲情報の一例であり、メッセージ 1およびメッセージ 2が、本発明の、要求範囲情報を含むデータ要求の一例である。

[0099] AVサーバ 13はこのメッセージ 1を受信すると、メッセージ 2を送信する。図 12 (c)に示すメッセージ 2は、 Content— Rangeヘッダを含み、 0ノイト目力ら 80009ノイト目までの送信を行うことを示している。そのうち、付加情報を含まない AVコンテンツデータの送信範囲は、 0バイト目力ら 79999バイト目である。これに一つの付加情報を加えて 0バイト目力も 80009バイト目までの送信となって、る（図 12 (f)参照）。 AVコンテンッ再生装置 14は、受信したメッセージ 2に所定の処理を行った後、受信データに含まれる AVコンテンツデータの 0バイト目力ら 79999ノイト目までを取り出して、 A Vコンテンツの処理を行う。

[0100] 図 12 (d)、 (e)にそれぞれ示すように、メッセージ 3及びメッセージ 4についても同様である。ただしメッセージ 4では、 HTTPメッセージの途中で AVコンテンツの属性が変化するので、二つの付加情報が加えられる（図 12 (g)参照)。図 12 (c)、（e)にそれぞれ示すように、その内容がメッセージ 3の Rangeヘッダ及びメッセージ 4の Conte nt— Rangeヘッダに反映されている。以降、 AVコンテンツの最後に達する力 AVコンテンッ再生装置 14のユーザによって再生が停止されるまで、上記のメッセージの送受信を繰り返す。

[0101] 次に、本実施の形態 2のコンテンツ配信システムにおける AVサーバ 13の構成と動作について説明する。

[0102] 図 13は、本実施の形態 2の AVサーバ 13の構成を示すブロック図である。図 13で、蓄積手段 101には一つ以上の画像または音声またはその両方を含む AVコンテンツが蓄積されている。再生開始要求受信手段 1301は、ネットワーク 3を介して AVコンテンッ再生装置 14からの再生開始要求を受信する。再生開始要求は、 AVコンテンッを識別する情報である AVコンテンツ識別子と、当該 AVコンテンツ識別子で識別される AVコンテンツのどの範囲を送信すべき力を指示する情報である再生範囲情報を含んでいる。

[0103] AVコンテンツデータ取得手段 1302は、再生開始要求受信手段 1301が受信した再生開始要求に含まれるデータ範囲情報から、送信すべき範囲の AVコンテンツデータを蓄積手段 101から取り出して、送信データ構成手段 104に渡す。

[0104] 暗号手段 1303は、送信データ構成手段 104から入力された AVコンテンツデータを暗号化して送信手段 105に渡す。

[0105] 暗号化のための鍵は、暗号鍵生成手段 1304が生成する。 AVサーバ 13と AVコンテンッ再生装置 14間であら力じめ決められた手順で復号ィ匕のための情報を通知する方法を決めておき、送信データ構成手段 104が生成する付加情報にその方法に則った復号ィ匕のための情報を付加する。鍵そのものは暗号手段 1303に渡され、 AV コンテンツデータの暗号ィ匕に使用される。本実施の形態 2では、 AVコンテンツの著作権属性が変化するたびに鍵を変更するものとする。暗号のための鍵と復号のための鍵は同一の鍵 (共通鍵)でもよ、し、異なる鍵でもよ、。

[0106] 送信データ構成手段 104、送信手段 105、属性テーブル保持送信手段 106は、それぞれ実施の形態 1で説明したものと同じ機能を有するが、本実施の形態 2においては、取り扱うコンテンツが AVコンテンツになる。また、本実施の形態 2では、付加情報の内容が、著作権保護の状態及び復号のための情報である。

[0107] 図 17は、本実施の形態 2の AVサーバ 13の動作を示すフローチャートである。以下、図 13および図 17を使い、図 12を用いて説明したシーケンスにおける AVサーバ 13 の動作を説明する。

[0108] 属性テーブル保持送信手段 106は、 AVコンテンツ再生装置 14から取得したい A Vコンテンツの AVコンテンツ識別子を含む属性テーブル要求を受信すると (ステップ 1)、当該 AVコンテンツに対応する属性テーブルを、送信手段 105を介して AVコンテンッ再生装置 14宛てに送信する (ステップ 2)。

[0109] 次いで、再生開始要求受信手段 1301が、再生開始要求である HTTPメッセージ（ GETメソッドを含む；図 12 (b)のメッセージ 1、図 12 (d)のメッセージ 3)を受信すると（ステップ 3)、この HTTPメッセージが AVコンテンツデータ取得手段 1302に渡される

[0110] AVコンテンツデータ取得手段 1302は、受信した HTTPメッセージから AVコンテンッ識別子である URI (本実施の形態 2では/ hogehoge. mpg)を抽出し、また X— Real— Range拡張ヘッダ力再生範囲情報を抽出する。 AVコンテンツデータ取得手段 1302は、 AVコンテンツ識別子で示された蓄積手段 101に格納されている AV コンテンツから、再生範囲情報で示される範囲の AVコンテンツデータを取得する（ステツプ 4)。 AVコンテンツデータ取得手段 1302は、抽出した AVコンテンツ識別子及び再生範囲とともに、取得した AVコンテンツデータを送信データ構成手段 104に渡す。

[0111] 送信データ構成手段 104は、属性テーブル保持送信手段 106に含まれるこの AV コンテンツ識別子に対応する属性テーブルを参照する。要求されている再生範囲の属性がどのようになっているかを確認し、その再生範囲の開始点から属性が同一の範囲を確認する（ステップ 5)。例えば、図 12 (b)のメッセージ 1であれば、再生範囲がすべて著作権保護が必要とヽぅ同一の属性をもってヽることを確認する。図 12 (b)のメッセージ 3であれば、再生範囲の 80000バイト目力ら 99999ノイト目までは著作権保護が必要とヽぅ同一の属性をもってヽることを確認する。

[0112] 次いで、送信データ構成手段 104は、送信すべき AVコンテンツデータの著作権属性から、 AVコンテンツデータの送信の際に暗号ィ匕が必要かどうかを判定し (ステップ 6)、必要なら、暗号鍵生成手段 1304に、鍵の生成と暗号手段 1303への設定を指示する。暗号鍵生成手段 1304は、鍵を生成し、暗号手段 1303へ設定するとともに（ステップ 7)、復号のための情報を送信データ構成手段 104に通知する。

[0113] 送信データ構成手段 104は、属性テーブル保持送信手段 106を参照し、属性テーブルから著作権保護の状態 (この場合、著作権保護必要)と、暗号鍵生成手段 1304 力もの復号のための情報を含む付加情報を生成する (ステップ 8)。また、送信データ構成手段 104は、暗号ィ匕が必要な AVコンテンツデータを暗号手段 1303に渡し、暗号手段 1303は暗号処理を実行する (ステップ 9)。

[0114] その後、送信データ構成手段 104は、まず付加情報を送信手段 105に送り、次いで暗号ィ匕した AVコンテンッデータを送信手段 105に渡すよう、暗号手段 1303に指示する。

[0115] 送信手段 105は、 HTTPに則り、まず HTTPヘッダを送信し、ついで付加情報を送信する。その後、暗号ィ匕された AVコンテンツデータを送信する (ステップ 10)。

[0116] ステップ 6で、送信データ構成手段 104が属性テーブル保持送信手段 106を参照して、これカゝら送信する AVコンテンツデータに暗号ィ匕をする必要がなヽと判断した場合は、著作権保護の状態 (この場合は著作権フリーで暗号ィ匕不要)を含む付加情報を生成する (ステップ 12)。その後、付加情報と AVコンテンツデータを送信手段 10 5に渡し、送信手段 105は、 HTTPに則って、付加情報が加えられた AVコンテンツデータを送信する (ステップ 10)。

[0117] 送信データ構成手段 104は、要求されている再生範囲の最後まで達した力どうかを判断し (ステップ 11)、達していなければ、未送信の範囲の AVコンテンツデータにつ V、てステップ 5以降の処理を行う。

[0118] ステップ 11で再生範囲の最後まで達したら、ステップ 3に戻り、次の再生開始要求を待つ。

[0119] ステップ 3で、再生開始要求を受信していない間に、 AVコンテンツ再生装置 14から新たな属性テーブル要求を受信した場合 (ステップ 13)、ステップ 2に戻り、対応する属性テーブルを送信する。不正なメッセージを受信すると (ステップ 14)、エラーレスポンスを送信し (ステップ 15)、ステップ 1に戻る。再生開始要求も属性テーブル要求も受信できないうちに所定時間が経過してタイムアウトした場合は (ステップ 16)、ステツプ 1に戻る。

[0120] 次に、本実施の形態 2のコンテンツ配信システムにおける AVコンテンツ再生装置 1

4の構成と動作につ、て説明する。

[0121] 図 14は、本実施の形態 2の AVコンテンツ再生装置 14の構成を示すブロック図である。

[0122] ユーザ入力手段 201は、再生しょうとする AVコンテンツを識別する情報である AV コンテンツ識別子 (名前など)などのユーザからの入力を受け付ける。具体的には、ュ一ザ入力手段 201は、 AVコンテンツ識別子と再生したい時間情報（「30分後以降」等）を受け付ける。なお、ユーザ入力手段 201は AVコンテンツ識別子のみを受け付けてもよい。ユーザ入力手段 201が受け付ける情報の入力手段は、テンキーやキーボードやマウスやリモコンを使ってメニュー画面を操作するもの等、何でも良い。ユーザ入力手段 201は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。

[0123] 受信データ決定手段 202は、ユーザ入力手段 201からの通知、受信バッファ 205 の空き容量に関する問い合わせ結果、受信手段 204からの通知等を受けて、要求する再生範囲を決定する。再生範囲情報は、ユーザ入力手段 201が受け付けた情報や、受信バッファ 205の空き容量に関する問い合わせ結果、受信手段 204からの通知等に基づいて決定され得る。再生範囲情報をバイト位置で表し、ユーザが再生した!、時間情報を入力した場合は、ユーザが入力した時間情報と AVコンテンツ上のノイト位置との変換式や変換テーブルをあら力じめ用意しておく。

[0124] 再生開始要求送信手段 1401は、再生を要求する AVコンテンツの AVコンテンツ識別子と再生範囲情報を含む再生開始要求を生成し、ネットワーク 3を介して AVサーバ宛てに送信する。この際、属性テーブル保持受信手段 207を参照して、受信データ決定手段 202が決定した再生範囲情報に加え、この再生範囲情報に付加情報を加味した要求範囲を含む再生開始要求を生成する。図 12 (b)のメッセージ 1や図 1 2 (d)のメッセージ 3では、再生範囲情報は X— Real— Range拡張ヘッダに書き込まれ、付加情報を含めた範囲は Rangeヘッダに書き込まれる。

[0125] 受信手段 204は、ネットワーク 3から付加情報が加えられた AVコンテンツデータを受信し、 AVコンテンツデータを受信バッファ 205に渡すとともに、受信した AVコンテンッデータの長さまたは受信した AVコンテンツデータの終点位置を受信データ決定手段 202に通知する。また、受信手段 204は、付加情報から AVコンテンツデータが暗号ィ匕されているかどうかを判定し、暗号ィ匕されていれば復号に関する情報を復号鍵生成手段 1404に通知する。

[0126] 再生手段 1402は、受信バッファ 205から AVコンテンツデータを順次読み込んで再生する。再生手段 1402は、ディスプレイやスピーカ等の出力デバイスを含むと考えても含まないと考えてもよい。再生手段 1402は、出力デバイスのドライバソフトゥェァと再生処理ソフトウェアまたは、出力デバイスと、出力デバイスのドライバソフトゥェァと再生処理ソフトウェア等で実現され得る。

[0127] 属性テーブル保持受信手段 207は、 AVコンテンツの受信及び再生に必要な属性テーブルを要求する属性テーブル要求を、ネットワーク 3を介して AVサーバ 13宛てに送信する。そして、その応答として AVサーバ 13から受信手段 204を介して属性テ一ブルを受信し、保持する。また、属性テーブルは、再生開始要求送信手段 1401から参照される。

[0128] 復号手段 1403は、受信手段 204から暗号化されている AVコンテンツデータを受け取り、復号して受信バッファ 205に格納する。復号のための鍵は、受信手段 204から渡された復号のための情報をもとに復号鍵生成手段 1404で生成され、復号手段 1 403〖こ設定される。

[0129] 復号鍵生成手段 1404は、受信手段 204から通知された復号のための情報から、所定の方法で鍵を生成し、復号手段 1403に設定する。鍵を生成する方法として、例えば次のような方法がある。あらかじめ AVサーバ 13と AVコンテンツ再生装置 14間で、鍵を暗号 Z復号するための鍵 (鍵暗号鍵)が共有されていて、その鍵暗号鍵で復号のための鍵が暗号ィ匕されているものを復号のための情報として付加情報に含ませる。復号鍵生成手段 1404は、共有している鍵暗号鍵で、復号のための鍵を算出する。 [0130] 図 18は、本実施の形態 2の AVコンテンツ再生装置 14の動作を示すフローチャートである。以下、図 14および図 18を使い、図 12 (a)を用いて説明したシーケンスにおける AVコンテンツ再生装置 14の動作を説明する。

[0131] ユーザ入力手段 201は、 AVサーバ 13にある AVコンテンツの再生開始要求を受けると (ステップ 1)、要求する AVコンテンツ識別子 (本実施の形態 2では Zhogehog e. mpg)を受信データ決定手段 202と属性テーブル保持受信手段 207に通知する。このとき、ユーザ入力手段 201に再生したい AVコンテンツの範囲も入力された場合、その再生範囲も受信データ決定手段 202に通知する。

[0132] 属性テーブル保持受信手段 207は、ユーザ入力手段 201から通知された AVコンテンッ識別子に対応する AVコンテンツの属性テーブルを保持しているかどうかを判定し (ステップ 2)、保持していなければ属性テーブル要求をネットワーク 3を介して A Vサーバ 13宛てに送信する（ステップ 3)。

[0133] そして、受信手段 204は、属性テーブルを受信すると (ステップ 4)、受信した属性テ一ブルを属性テーブル保持受信手段 207に渡す。属性テーブル保持受信手段 207 は、属性テーブルを渡されると、対応する AVコンテンツ識別子と関連づけて属性テ一ブルを保存し、受信データ決定手段 202へその旨を通知する。

[0134] 受信データ決定手段 202は、ユーザがユーザ入力手段 201に入力した再生したい AVコンテンツの範囲と、受信バッファ 205の空き容量から、 AVサーバ 13に送信する要求すべき再生範囲を決定する (ステップ 5)。そして、 AVコンテンツ識別子とともに決定した再生範囲を示す再生範囲情報を、再生開始要求送信手段 1401に通知する。

[0135] 再生開始要求送信手段 1401は、受信データ決定手段 202から通知された AVコンテンッ識別子と再生範囲情報、及び属性テーブル保持受信手段 207を参照することにより、受信する AVコンテンツデータとともに得られる付加情報まで含めた要求範囲を含む再生開始要求（図 12 (b)のメッセージ 1、図 12 (d)のメッセージ 3)を生成し、 AVサーバ 13宛てに送信する (ステップ 6)。

[0136] 受信手段 204は、送信した再生開始要求に対応する付加情報が加えられた AVコンテンッデータ（図 12 (c)および (f)に示すメッセージ 2、図 12 (e)および (g)に示すメッセージ 4)を受信すると (ステップ 7)、付加情報を解析し (ステップ 8)、著作権保護の状態を確認して AVコンテンツデータが暗号ィ匕されてヽるかどうかを判定する (ステップ 9)。暗号化されていれば、受信手段 204は、復号鍵生成手段 1404に、付加情報に含まれて!/、る復号のための情報を通知する。

[0137] 復号鍵生成手段 1404は、通知された復号のための情報力も鍵を生成し、復号手段 1403に設定する (ステップ 10)。その後、復号鍵生成手段 1404は、鍵設定が終わった旨を受信手段 204に通知する。

[0138] 復号鍵生成手段 1404から鍵設定終了の通知を受けると、受信手段 204は、受信した AVコンテンツデータを復号手段 1403に渡す。この時、ステップ 7で受信した AV コンテンツデータに複数の付加情報が付加されていた場合、受信手段 204は、次の付加情報の直前までの AVコンテンツデータを復号手段 1403に渡す。

[0139] 復号手段 1403は受信手段 204から渡された AVコンテンツデータを、復号鍵生成手段 1404が設定した鍵を用いて復号し (ステップ 11)、受信バッファ 205に格納する。再生手段 1402は、受信バッファ 205に格納された復号化された AVコンテンッデータを順次取り出し、出力デバイス等で AVコンテンツデータを再生する (ステツプ 12)。

[0140] ステップ 9で暗号ィ匕されてヽな、と判定した場合、受信手段 204は、受信した AVコンテンッデータを直接受信バッファ 205に格納し、その AVコンテンツデータは再生手段 1402によって再生される (ステップ 12)。この場合でも、ステップ 7で受信した A Vコンテンツデータに複数の付加情報が付加されて、た場合は、受信手段 204は、次の付加情報の直前までの AVコンテンツデータを復号手段 1403に渡す。

[0141] 受信手段 204がすべての付加情報を解析し終わっていない（つまり、再生手段 14 02に読み込まれて!/ヽな、AVコンテンツデータがある）ならば (ステップ 13)、ステップ 8以降を繰り返す。

[0142] ユーザ入力手段 201に入力された AVコンテンッ識別子に対応する AVコンテンッのすベて (再生範囲も入力された場合はその範囲）を受信するか、ユーザがユーザ入力手段 201に停止を指示した場合 (ステップ 9)は、最初 (ステップ 1)に戻る。そうでない場合は、ステップ 5以降を繰り返す。 [0143] ステップ 2で、以前の通信等により、属性テーブル保持受信手段 207にすでに当該 AVコンテンツに対応する属性テーブルが保持されて、る場合は、属性テーブルの交換は行わず、ステップ 5に進む。ただし、この場合でも属性テーブルの交換を行つてもよい。

[0144] ステップ 4またはステップ 7で、受信できないままタイムアウトしたり、または AVサーノ 13からエラーレスポンスを受信した場合 (ステップ 15、 16)は、エラー処理を行い（ステップ 17)、最初 (ステップ 1)に戻る。

[0145] 本実施の形態 2のコンテンツ配信システムでは、実施の形態 1のコンテンツ配信システムの有する効果に加えて、著作権保護の状態を付加情報に含んで、る場合でも、 AVサーバ 13が、付加情報を除いた実際に送信すべき AVコンテンツデータの範囲を特定することができる。

[0146] また、本実施の形態 2のコンテンツ配信システムでは、付加情報に復号ィ匕のための情報を含む場合でも、 AVサーバ 13が、付加情報を除いた実際に送信すべき AVコンテンッデータの範囲を特定することができる。

[0147] なお、本実施の形態 2であげた hogehoge. mpgという AVコンテンツは一例であり、その他の AVコンテンツ、例えば、 JPEG静止画や AC3音声やその他のフォーマツトでもよいことは言うまでもない。また、 AVコンテンツに限らず、 AVコンテンツ以外のコンテンツデータであってもよ、。

[0148] また、本実施の形態 2において、 AVサーバ 13と AVコンテンツ再生装置 14の間に、例えば、中継装置が存在し、 AVコンテンツ再生装置 14から中継装置に再生開始要求が送信され、中継装置が AVサーバ 13をアクセスし、 AVコンテンツを取得して、 AVコンテンツ再生装置 14に当該 AVコンテンツを送信してもよい。つまり、 AVサーバ 13と AVコンテンツ再生装置 14は、直接にネットワークで、データの送受信を行う必要は、必ずしもない。

[0149] また、本実施の形態 2のコンテンツ配信システムでは、 AVコンテンツデータの受信の前に、 AVコンテンツ再生装置 14力属性テーブルをネットワーク 3を介して AVサーバ 13から予め受信することとした力 AVコンテンツ再生装置 14は、その他の方法で属性テーブルを取得、保持しておいてもよい。例えば、 AVサーバ 13とは異なるサーバ等カもネットワークを介して属性テーブルを取得するようにしてもよいし、ネットヮークを介さず、記録媒体等に記録された属性テーブルを予め読み込み、保持しておくようにしてもよい。

[0150] 本実施の形態のような AVコンテンツをネットワーク再生する場合の付加情報の例として、 DTCP— IP (DTCP Volume 1 Supplement E Mapping DTCP to

IP(InformationalVersion)Revision 1.0 November 24, 2003を参照）の PCPヘッダがある。 PCPヘッダは、 AVコンテンツの著作権保護情報が変化するたびに付加されるとともに、 HTTPヘッダとそのメッセージボディである AVコンテンツデータと間にも常に付加される。

[0151] また、 AVコンテンツが DVD— VRフォーマットの動画像である場合、 AVコンテンツを構成する各 VOBUの先頭に (AVコンテンツデータの一部として)著作権保護情報が含まれている。 AVサーバが、このような AVコンテンツを DTCP— IPを用いて送信しょうとする場合、 AVサーバは、各 VOBUの先頭にあるこの著作権情報を参照して、付加情報である PCPヘッダを付加し、ネットワーク上に送信する。

[0152] このような場合、 AVコンテンツ再生装置からの要求範囲を各 VOBUの先頭から始まると制限してもよい。このような制限をかけない場合、要求された範囲がどのような著作権保護情報をもって、るかを、 VOBUの先頭まで遡って確認して力も PCPへッダを付加することになる。結果として AVサーバの処理負荷が増加する。

[0153] なお、本発明の第一および第二の実施の形態では、 HTTPリクエストメッセージに X— Real— Range拡張ヘッダの他に、 Rangeヘッダを含ませている力 X— Real— Ran geヘッダのみだけを指定してもよ、。また HTTPレスポンスメッセージに含まれる Con tent— Rangeヘッダの替わりに別のヘッダを用いて、付加情報を除、た送信する AV コンテンツのデータ範囲を指定してもよい。実際、どのように分割するかはコンテンツ受信装置 (AVコンテンツ再生装置）しか知らな!/、ので、コンテンツサーバ（AVサーバ )は、受信した Rangeヘッダの値を単に Content— Rangeヘッダの値として使うことになり、意味のない動作をしている。ただし、 HTTPでは、ブロック伝送の方法として Ra ngeヘッダおよび Content— Rangeヘッダを使う方法のみをサポートして、るため、このような変更をカ卩えると正確には HTTPに準拠しているとはいえなくなり、別に定義が必要となる。

[0154] なお、本発明のプログラムは、上述した本発明のコンテンツ配信システムの全部又は一部の手段又は装置の機能をコンピュータにより実行させるためのプログラムであつて、コンピュータと協働して動作するプログラムである。

[0155] また、本発明の記録媒体は、上述した本発明のコンテンツ配信システムの全部又は一部の手段又は装置の全部又は一部の機能をコンピュータにより実行させるためのプログラムを記録した記録媒体であり、コンピュータにより読み取り可能かつ、読み取られた前記プログラムが前記コンピュータと協働して利用される記録媒体である。

[0156] なお、本発明の上記「一部の手段又は装置」とは、それらの複数の手段の内の、一つ又は幾つかの手段又は装置を意味する。

[0157] また、本発明の上記「手段又は装置の機能」とは、前記手段の全部又は一部の機能を意味する。

[0158] また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であっても良い。

[0159] また、記録媒体としては、 ROM等が含まれ、伝送媒体としては、インターネット等の伝送媒体、光 ·電波 ·音波等が含まれる。

[0160] また、上述した本発明のコンピュータは、 CPU等の純然たるハードウェアに限らず、ファームウェアや、 OS、更に周辺機器を含むものであっても良い。

[0161] なお、以上説明した様に、本発明の構成は、ソフトウェア的に実現しても良いし、ハ一ドウエア的に実現しても良、。

産業上の利用可能性

[0162] 本発明に力かるコンテンツ配信システム、コンテンツサーノ、コンテンツ受信装置、コンテンツ配信方法、プログラム及び記録媒体は、コンテンツ受信装置が想定する受信範囲のコンテンツデータを確実にコンテンツサーノくから受信できるを有し、コンテンッの内部属性に基づく付加情報を付加したコンテンツを配信するコンテンツ配信システム等として有用である。例えば、付加情報にコンテンツデータまたは AVコンテンツデータの利用者情報を含ませることによってアクセス制限の用途でも使用できる。また HTTP以外の標準または非標準のプロトコルにも使用を拡大できる。

Claims

請求の範囲

[1] コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケットィ匕する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システム【しお！、て、

前記コンテンツデータ取得手段は、前記データ要求送信手段が送信した前記データ要求力前記要求されてヽる範囲を特定する、コンテンツ配信システム。

[2] コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケットィ匕する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツサーバにおいて、

コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されて、る範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを備えたコンテンツサーバ。

[3] 前記通信プロトコルは、 HTTPであり、

前記データ要求には、前記付加情報を考慮しな!、前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、請求の範囲第 2項記載のコンテンッサーバ。

[4] 前記コンテンツは、画像および Zまたは音声を含む AVコンテンツである、請求の範囲第 2項記載のコンテンツサーバ。

[5] 前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んで!/、る

、請求の範囲第 2項記載のコンテンツサーバ。

[6] 前記コンテンツが暗号化されて!/ヽる場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んで、る、請求の範囲第 2項記載のコンテンッサーバ。

[7] コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケットィ匕する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツ受信装置において、

付加情報を考慮しないコンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を示す要求範囲情報を含むデータ要求を送信するデータ要求送信手段と、前記コンテンツのデータおよび前記付加情報を受信する受信手段とを備えた、コンテンツ受信装置。

[8] 前記受信手段は、受信した前記コンテンツのデータおよび前記付加情報から、前記コンテンツのデータのみを受信バッファに格納する、請求の範囲第 7項記載のコンテンッ装置。

[9] 前記通信プロトコルは、 HTTPであり、

前記データ要求には、前記付加情報を考慮しな!、前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、請求の範囲第 7項記載のコンテンッ受信装置。

[10] 前記コンテンツは、画像および Zまたは音声を含む AVコンテンツである、請求の範囲第 7項記載のコンテンツ受信装置。

[11] 前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んでいる

、請求の範囲第 7または第 10項記載のコンテンツ受信装置。

[12] 前記コンテンツが暗号ィ匕されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、請求の範囲第 7または第 10項記載のコンテンツ受信装置。

[13] 一つ以上のコンテンツを蓄積しているコンテンツサーバと、前記コンテンツサーバから前記コンテンツをネットワークを介して受信するコンテンツ受信装置とを利用して前記コンテンツの送受信を行うコンテンツ配信方法において、

前記コンテンツ受信装置は、前記付加情報を考慮しな!ヽ前記コンテンツの受信要求範囲を決定するステップと、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するステップと、前記送信手段から送信される前記コンテンッのデータおよび前記付加情報を受信するステップとを有する、コンテンツ配信方法。

[14] 請求の範囲第 1項記載のコンテンツ配信システムの、

前記コンテンツ受信装置の、前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段、前記付加情報を考慮しな!ヽ前記コンテンッの受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段、としてコンピュータを機能させるためのプログラム。

[15] 請求の範囲第 2項記載のコンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しな!ヽ前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されて、る範囲を特定し、前記要求されて、る範囲の前記コンテンツのデータを前記蓄積手段力取り出すコンテンツデータ取得手段、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段、としてコンピュータを機能させるためのプログラム。

[16] 請求の範囲第 7項記載のコンテンツ受信装置の、前記付加情報を考慮しないコンテンッの前記受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を示す前記要求範囲情報を含む前記データ要求を送信するデータ要求送信手段、前記コンテンツのデータおよび前記付加情報を受信する受信手段、としてコンピュータを機能させるためのプログラム。

[17] 請求の範囲第 14一 16項のいずれかに記載のプログラムを記録した記録媒体であつて、コンピュータで利用可能な記録媒体。