(57)【要約】  【課題】コンテンツの内部属性に応じた一つ以上の付加情報を加えて送受信を行うネットワークシステムにおいて、コンテンツ受信装置がどのような分割転送を想定しているかに関わらず、コンテンツサーバが送信するデータを決定できる。  【解決手段】コンテンツを一つ以上保持している蓄積手段１０１と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して、要求されている範囲のコンテンツのデータを蓄積手段１０１から取り出すコンテンツデータ取得手段と、取り出されたコンテンツのデータに付加情報を加えて送信する送信手段とを有するコンテンツサーバ１と、送信手段から送信されるコンテンツのデータおよび付加情報を受信する受信手段と、付加情報を考慮しないコンテンツの受信要求範囲を決定する受信データ決定手段と、要求範囲情報を含むデータ要求を送信するデータ要求送信手段とを有するコンテンツ受信装置２とを備える。【選択図】図４
2005149029.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケット化する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムにおいて、
コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されている範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを有するコンテンツサーバと、
前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段と、前記付加情報を考慮しない前記コンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段とを有するコンテンツ受信装置とを備え、
前記コンテンツデータ取得手段は、前記データ要求送信手段が送信した前記データ要求から前記要求されている範囲を特定する、コンテンツ配信システム。
【請求項２】
コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケット化する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツサーバにおいて、
コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されている範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを備えたコンテンツサーバ。
【請求項３】
前記通信プロトコルは、ＨＴＴＰであり、
前記データ要求には、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、請求項２に記載のコンテンツサーバ。
【請求項４】
前記コンテンツは、画像および／または音声を含むＡＶコンテンツである、請求項２または３に記載のコンテンツサーバ。
【請求項５】
前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んでいる、請求項２乃至４のいずれかに記載のコンテンツサーバ。
【請求項６】
前記コンテンツが暗号化されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、請求項２乃至５のいずれかに記載のコンテンツサーバ。
【請求項７】
コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケット化する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツ受信装置において、
付加情報を考慮しないコンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を示す要求範囲情報を含むデータ要求を送信するデータ要求送信手段と、前記コンテンツのデータおよび前記付加情報を受信する受信手段とを備えた、コンテンツ受信装置。
【請求項８】
前記通信プロトコルは、ＨＴＴＰであり、
前記データ要求には、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、請求項７に記載のコンテンツ受信装置。
【請求項９】
前記コンテンツは、画像および／または音声を含むＡＶコンテンツである、請求項７または８に記載のコンテンツ受信装置。
【請求項１０】
前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んでいる、請求項７乃至９のいずれかに記載のコンテンツ受信装置。
【請求項１１】
前記コンテンツが暗号化されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、請求項７乃至１０のいずれかに記載のコンテンツ受信装置。
【請求項１２】
一つ以上のコンテンツを蓄積しているコンテンツサーバと、前記コンテンツサーバから前記コンテンツをネットワークを介して受信するコンテンツ受信装置とを利用して前記コンテンツの送受信を行うコンテンツ配信方法において、
前記コンテンツサーバは、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されている範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すステップと、取り出された前記コンテンツのデータに前記付加情報を加えて送信するステップとを有し、
前記コンテンツ受信装置は、前記付加情報を考慮しない前記コンテンツの受信要求範囲を決定するステップと、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するステップと、前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信するステップとを有する、コンテンツ配信方法。
【請求項１３】
請求項１に記載のコンテンツ配信システムの、
前記コンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されている範囲を特定し、前記要求されている範囲の前記コンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段、
前記コンテンツ受信装置の、前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段、前記付加情報を考慮しない前記コンテンツの受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段、としてコンピュータを機能させるためのプログラム。
【請求項１４】
請求項２に記載のコンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されている範囲を特定し、前記要求されている範囲の前記コンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段、としてコンピュータを機能させるためのプログラム。
【請求項１５】
請求項７に記載のコンテンツ受信装置の、前記付加情報を考慮しないコンテンツの前記受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を示す前記要求範囲情報を含む前記データ要求を送信するデータ要求送信手段、前記コンテンツのデータおよび前記付加情報を受信する受信手段、としてコンピュータを機能させるためのプログラム。
【請求項１６】
請求項１３乃至１５のいずれかに記載のプログラムを担持した記録媒体であって、コンピュータで利用可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツの内部属性に基づく付加情報を付加したコンテンツを配信するコンテンツ配信システム、コンテンツサーバ、コンテンツ受信装置、コンテンツ配信方法、プログラム及び記録媒体に関するものである。
【背景技術】
【０００２】
コンテンツ受信装置がネットワークを介して、コンテンツサーバに蓄積されているコンテンツを受信しようとする場合、一般にＨＴＴＰ等の通信プロトコルを使ってコンテンツサーバにリクエストを送り、コンテンツデータを受信する。
【０００３】
しかし、単純にコンテンツだけを指定してリクエストを送った場合、一度のリクエストでコンテンツのすべてがコンテンツ受信装置に送られることになる。したがって、コンテンツ受信装置で通信プロトコルを扱うための受信バッファに制限がある場合でも、コンテンツの一部分だけを受信することができない。また、コンテンツ受信装置がすでにコンテンツのある部分を保持している場合でも、コンテンツを最初から最後まで受信しなければならない。
【０００４】
このようなことを改善するために、いくつかの通信プロトコルでは、コンテンツのある一部分を取得することができるよう、ブロック転送をサポートしている。例えばＨＴＴＰであれば、ＨＴＴＰリクエストメッセージにＲａｎｇｅヘッダを含ませることにより、ブロック転送を実現している（例えば、特許文献１、非特許文献１参照）。
【０００５】
コンテンツがＡＶコンテンツの場合も、上記と同様にＡＶコンテンツの送受信を行うことができる。特にＡＶコンテンツの場合には、コンテンツ受信装置は、内部のデコーダにＡＶコンテンツを送る前に、格納する受信バッファの空き状態を確認しながら、リクエストを送信する。この場合、上記のブロック転送を用いてコンテンツデータの送受信を行う。
【特許文献１】特開２００１−１０１０９１号公報
【非特許文献１】Ｒ．Ｆｉｅｌｄｉｎｇ他著、”Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１”、ＲＦＣ２６１６
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、コンテンツサーバからコンテンツを伝送する際、コンテンツの各部分の属性にもとづいて、付加情報を一定の規則に従って送信データに付加させることがあり、この場合、上記の従来のブロック転送を用いた伝送方法では、コンテンツ受信装置が受信すべきデータ範囲をコンテンツサーバに正しく要求できないという問題が出てくる。以下、従来のブロック転送を用いた伝送方法におけるこの問題点について説明する。
【０００７】
コンテンツサーバによって送信データに付加される付加情報としては、例えば、コンテンツのその部分の重要度についての情報や、暗号化に関する情報等がある。重要度についての付加情報は、コンテンツサーバとコンテンツ受信装置の間にある中継装置等がそれを見て、ネットワーク負荷が高い場合に重要度の高いものから伝送するように制御するために利用される。暗号化に関する情報としては、例えば鍵に関する情報がある。
【０００８】
付加情報は、コンテンツ内で対応する属性が変化するたびに付与される。例えば、重要度に関する付加情報であれば、コンテンツ内で重要度が変化するたびに付加情報がつけ直される。通信プロトコルの各転送単位（パケットやメッセージ）毎に、その通信プロトコルのヘッダの後に付加情報が必ず付加される。これは、直前のパケットやメッセージがネットワーク上で失われた場合等に対処するためである。
【０００９】
図２は、コンテンツに対して付加情報が付与され、更にＨＴＴＰで伝送される場合のＨＴＴＰメッセージの例を示している。図２では、コンテンツが重要度によって３つのブロックに分けられているが、２つのＨＴＴＰメッセージで送信する場合の例を示している。
【００１０】
１番目のＨＴＴＰメッセージでは、ＨＴＴＰヘッダの後に、コンテンツブロック１のための付加情報、コンテンツブロック１、コンテンツブロック２のための付加情報、コンテンツブロック２の一部（前半）と続く。２番目のＨＴＴＰメッセージでは、ＨＴＴＰヘッダの後に、まずコンテンツブロック２のための付加情報が続く。これは、ＨＴＴＰヘッダの後に付加情報を必ず付加するというルールによる。ついで、コンテンツブロック２の一部（後半）、コンテンツブロック３のための付加情報、コンテンツブロック３が続く。
【００１１】
図３は、図２と同じコンテンツを３つのＨＴＴＰメッセージで送信する場合の例である。３つのＨＴＴＰメッセージで、３つのコンテンツブロックをそれぞれ送信する。
【００１２】
それぞれのＨＴＴＰメッセージのメッセージボディ（データ部）として送られるデータは、付加情報とコンテンツデータを合わせたものになる。ＨＴＴＰプロトコル上は付加情報かコンテンツデータかの区別がないので、同じデータとして扱い、ＨＴＴＰヘッダに含まれるデータ長（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダの値）も、付加情報とコンテンツデータを合わせた値が書き込まれる。
【００１３】
コンテンツ受信装置が、例えばＨＴＴＰのＲａｎｇｅヘッダを使ってコンテンツサーバに含まれるコンテンツの一部分を取得しようとする場合、このような付加情報があると問題が生じる。ＨＴＴＰで送受信されるデータは、コンテンツデータにいくつかの付加情報を含んだものとなる。従って、コンテンツ受信装置がコンテンツの一部分を取得しようとする場合、コンテンツに付加情報を加えた全データを想定した上で、取得すべき範囲を指定しなければならない。
【００１４】
ところが、図２及び図３からも分かるように、コンテンツをどのように分割するかによってトータルで送受信される付加情報の数が変わってしまう。コンテンツ受信装置は、自身が想定する分割方法によって、コンテンツのリクエストを送信する。しかし、コンテンツサーバはコンテンツ受信装置がどのような分割方法を想定しているか分からないので、コンテンツ受信装置が実際に受信したいコンテンツの範囲を特定することができない。
【００１５】
また、コンテンツがＡＶコンテンツの場合、コンテンツ受信装置が、コンテンツサーバに蓄積されている画像や音声を含むＡＶコンテンツをネットワーク再生しようとする場合、特に著作権管理に関する情報を付加情報として付加する場合がある。すなわちＡＶコンテンツのある部分は、コピーしてもかまわないが、他のある部分はコピーしてはならないといった情報である。この場合、コピーしてはならない部分は、ネットワーク上で暗号化して伝送されなければならない。また、定期的に鍵を更新するような暗号化を行った場合には、復号に関する情報が付加情報として付加される場合がある。
【００１６】
コンテンツがＡＶコンテンツの場合は、コンテンツ受信装置は、受信バッファの空き状態を確認しながら、ＡＶコンテンツの一部分を取得するようなリクエストを送信する。ＡＶコンテンツの分割方法は、受信バッファがどの程度空いた時にリクエストを送信するかに依存して決まる。この場合、著作権管理に関する情報等の付加情報がコンテンツの途中に付加される場合、コンテンツ受信装置が、ＡＶコンテンツをどのように分割するかによって、ＡＶコンテンツに付加情報を加えた、ＨＴＴＰからみたトータルのデータ長が変わってしまう。従って、コンテンツサーバは、コンテンツ受信装置が実際に再生したいＡＶコンテンツの範囲を特定することができない。
【００１７】
本発明は、上記従来の課題を解決するもので、コンテンツ受信装置が想定する受信範囲のコンテンツデータを確実にコンテンツサーバから受信できる、コンテンツ配信システム、コンテンツサーバ、コンテンツ受信装置およびコンテンツ配信方法を提供することを目的とする。
【課題を解決するための手段】
【００１８】
上述した課題を解決するために、第１の本発明は、
コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケット化する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムにおいて、
コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されている範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを有するコンテンツサーバと、
前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段と、前記付加情報を考慮しない前記コンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段とを有するコンテンツ受信装置とを備え、
前記コンテンツデータ取得手段は、前記データ要求送信手段が送信した前記データ要求から前記要求されている範囲を特定する、コンテンツ配信システムである。
【００１９】
第２の本発明は、
コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケット化する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツサーバにおいて、
コンテンツを一つ以上保持している蓄積手段と、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されている範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段と、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段とを備えたコンテンツサーバである。
【００２０】
第３の本発明は、
前記通信プロトコルは、ＨＴＴＰであり、
前記データ要求には、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、第２の本発明のコンテンツサーバである。
【００２１】
第４の本発明は、
前記コンテンツは、画像および／または音声を含むＡＶコンテンツである、第２または第３の本発明のコンテンツサーバである。
【００２２】
第５の本発明は、
前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んでいる、第２乃至第４のいずれかの本発明のコンテンツサーバである。
【００２３】
第６の本発明は、
前記コンテンツが暗号化されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、第２乃至第５のいずれかの本発明のコンテンツサーバである。
【００２４】
第７の本発明は、
コンテンツに前記コンテンツの内部属性に応じた一つ以上の付加情報を加え、前記コンテンツと前記付加情報を区別なくデータ部としてパケット化する通信プロトコルに従って、前記コンテンツおよび前記付加情報の送受信を行うコンテンツ配信システムのコンテンツ受信装置において、
付加情報を考慮しないコンテンツの受信要求範囲を決定する受信データ決定手段と、決定した前記受信要求範囲を示す要求範囲情報を含むデータ要求を送信するデータ要求送信手段と、前記コンテンツのデータおよび前記付加情報を受信する受信手段とを備えた、コンテンツ受信装置である。
【００２５】
第８の本発明は、
前記通信プロトコルは、ＨＴＴＰであり、
前記データ要求には、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を書き込むための拡張ヘッダが設けられている、第７の本発明のコンテンツ受信装置である。
【００２６】
第９の本発明は、
前記コンテンツは、画像および／または音声を含むＡＶコンテンツである、第７または第８の本発明のコンテンツ受信装置である。
【００２７】
第１０の本発明は、
前記付加情報は、前記コンテンツの著作権保護の状態に関する情報を含んでいる、第７乃至第９のいずれかの本発明のコンテンツ受信装置である。
【００２８】
第１１の本発明は、
前記コンテンツが暗号化されている場合には、前記付加情報は、前記暗号化された前記コンテンツの復号のための情報を含んでいる、第７乃至第１０のいずれかの本発明のコンテンツ受信装置である。
【００２９】
第１２の本発明は、
一つ以上のコンテンツを蓄積しているコンテンツサーバと、前記コンテンツサーバから前記コンテンツをネットワークを介して受信するコンテンツ受信装置とを利用して前記コンテンツの送受信を行うコンテンツ配信方法において、
前記コンテンツサーバは、付加情報を考慮しないコンテンツの要求範囲情報を含むデータ要求を受信して要求されている範囲を特定し、前記要求されている範囲のコンテンツのデータを前記蓄積手段から取り出すステップと、取り出された前記コンテンツのデータに前記付加情報を加えて送信するステップとを有し、
前記コンテンツ受信装置は、前記付加情報を考慮しない前記コンテンツの受信要求範囲を決定するステップと、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するステップと、前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信するステップとを有する、コンテンツ配信方法である。
【００３０】
第１３の本発明は、
第１の本発明のコンテンツ配信システムの、
前記コンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されている範囲を特定し、前記要求されている範囲の前記コンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段、
前記コンテンツ受信装置の、前記送信手段から送信される前記コンテンツのデータおよび前記付加情報を受信する受信手段、前記付加情報を考慮しない前記コンテンツの受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を前記要求範囲情報として含む前記データ要求を送信するデータ要求送信手段、としてコンピュータを機能させるためのプログラムである。
【００３１】
第１４の本発明は、
第２の本発明のコンテンツサーバの、コンテンツを一つ以上保持している蓄積手段、前記付加情報を考慮しない前記コンテンツの前記要求範囲情報を含む前記データ要求を受信して要求されている範囲を特定し、前記要求されている範囲の前記コンテンツのデータを前記蓄積手段から取り出すコンテンツデータ取得手段、取り出された前記コンテンツのデータに前記付加情報を加えて送信する送信手段、としてコンピュータを機能させるためのプログラムである。
【００３２】
第１５の本発明は、
第７の本発明のコンテンツ受信装置の、前記付加情報を考慮しないコンテンツの前記受信要求範囲を決定する受信データ決定手段、決定した前記受信要求範囲を示す前記要求範囲情報を含む前記データ要求を送信するデータ要求送信手段、前記コンテンツのデータおよび前記付加情報を受信する受信手段、としてコンピュータを機能させるためのプログラムである。
【００３３】
第１６の本発明は、
第１３乃至第１５のいずれかの本発明のプログラムを担持した記録媒体であって、コンピュータで利用可能な記録媒体である。
【発明の効果】
【００３４】
本発明により、コンテンツ受信装置が想定する受信範囲のコンテンツデータを確実にコンテンツサーバから受信できる、コンテンツ配信システム、コンテンツサーバ、コンテンツ受信装置およびコンテンツ配信方法を提供できる。
【発明を実施するための最良の形態】
【００３５】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００３６】
（実施の形態１）
図４は、本発明の実施の形態１のコンテンツ配信システムの構成図である。
【００３７】
コンテンツサーバ１は、蓄積手段１０１に記録されているコンテンツを、コンテンツ受信装置２からの要求に応じて、ネットワーク３上に送信する。コンテンツ受信装置２は、コンテンツサーバ１からコンテンツを受信し、コンテンツの内容に応じた処理を行う。コンテンツの例としては、テキスト、画像、音声、実行ファイル等である。
【００３８】
まず、本実施の形態１のコンテンツ配信システムにおける、コンテンツ受信装置２からコンテンツサーバ１に受信データ範囲を指定するプロトコル制御方法について説明する。
【００３９】
図１（ａ）は、コンテンツサーバ１とコンテンツ受信装置２間の送受信を記述したシーケンス図である。本実施の形態１では、この送受信にＨＴＴＰプロトコルを用いている。
図１（ｂ）は、ＨＴＴＰメッセージの内容を、図１（ｃ）は、ＨＴＴＰメッセージの構成をそれぞれ示している。ただし、本発明において送受信のプロトコルは問わない。図１は、コンテンツサーバ１の蓄積手段１０１に記録されているコンテンツｈｏｇｅ．ｅｘｅを、コンテンツ受信装置２がコンテンツの最初から、分割受信する場合の例である。
【００４０】
図５に、ｈｏｇｅ．ｅｘｅの構成を例示する。ｈｏｇｅ．ｅｘｅは、トータルサイズが５００００バイトで、重要度の異なるいくつかのブロックから構成されている。１番目のブロックは３０００バイト、２番目のブロックは８０００バイトである。なお、重要度によるブロック分けは一つの例である。他の属性によるブロック分けでもよく、またブロック分けがない（全コンテンツが１ブロックの）コンテンツでもよい。また、トータルサイズやブロックサイズも問わない。図４に示す蓄積手段１０１は、ハードディスクなどの不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。
【００４１】
図１（ａ）で、コンテンツ受信装置２は、最初に、取得したいコンテンツに関する属性テーブルを要求し、コンテンツサーバ１から属性テーブルを取得する。属性テーブルは、コンテンツの内部でコンテンツの属性（内部属性）がどのように変化しているのかを示す表である。コンテンツを伝送する際に、属性の変わり目に付加情報を付加するため、この表が必要となる。
【００４２】
図６に、ｈｏｇｅ．ｅｘｅの属性テーブルの例を示す。オフセットはコンテンツの始まりからのバイト長を示している。この表から、０バイト目から２９９９バイト目までの重要度が６、３０００バイト目から１０９９９バイト目までの重要度が１、１１０００バイト目から重要度が３に変化するということが分かる。属性テーブルの取得にはＨＴＴＰを利用してもよいし、また別の通信プロトコルを使ってもよい。
【００４３】
図１（ａ）に示すように、コンテンツ受信装置２は、属性テーブルの取得後、データ要求であるメッセージ１をコンテンツサーバ１に向けて送信する。図１（ｂ）に示すように、メッセージ１はＲａｎｇｅヘッダを含み、ｈｏｇｅ．ｅｘｅの０バイト目から５９９９バイト目までの送信を要求している。また、メッセージ１は、データ範囲情報である「０−５９５９」を持つＸ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダを含む。これは、付加情報を含まないコンテンツデータの０バイト目から５９５９バイト目までを要求していることを示す。なお、本実施の形態１のコンテンツ配信システムで用いられる付加情報の長さは２０バイトとする。
【００４４】
なお、Ｘ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダは、本発明の要求範囲情報の一例であり、メッセージ１およびメッセージ２が、本発明の、要求範囲情報を含むデータ要求の一例である。
【００４５】
コンテンツサーバ１はこのメッセージ１を受信すると、メッセージ２を送信する。メッセージ２は、Ｃｏｎｔｅｎｔ−Ｒａｎｇｅヘッダを含み、０バイト目から５９９９バイト目までの送信を行うことを示している。そのうち、付加情報を含まないコンテンツデータの送信範囲は、０バイト目から５９５９バイト目である。これに二つの付加情報を加えて、０バイト目から５９９９バイト目までの送信となっている（図１（ｃ）参照）。コンテンツ受信装置２は、受信したメッセージ２に所定の処理を行った後、受信データに含まれるコンテンツデータの０バイト目から５９５９バイト目までを取り出して、コンテンツの処理を行う。
【００４６】
メッセージ３及びメッセージ４についても同様である。ただしメッセージ４では、ＨＴＴＰメッセージの途中でコンテンツの属性が変化しないので、付加情報は一つだけ加えられる（図１（ｃ）参照）。以降、コンテンツの最後まで達するか、コンテンツ受信装置２のユーザによってコンテンツ受信が停止されるまで、上記のメッセージの送受信を繰り返す。
【００４７】
次に、本実施の形態１のコンテンツ配信システムにおけるコンテンツサーバ１の構成と動作について説明する。
【００４８】
図７は、本実施の形態１のコンテンツサーバ１の構成を示すブロック図である。図７で、蓄積手段１０１には一つ以上のコンテンツが蓄積されている。データ要求受信手段１０２は、ネットワーク３を介してコンテンツ受信装置２からのデータ要求を受信する。データ要求は、コンテンツを識別する情報であるコンテンツ識別子と、当該コンテンツ識別子で識別されるコンテンツのどの範囲を送信すべきかを指示する情報であるデータ範囲情報を含んでいる。
【００４９】
コンテンツデータ取得手段１０３は、データ要求受信手段１０２が受信したデータ要求に含まれるデータ範囲情報から、送信すべき範囲のコンテンツデータを蓄積手段１０１から取り出して、送信データ構成手段１０４に渡す。
【００５０】
送信データ構成手段１０４は、渡された範囲のコンテンツデータに、当該コンテンツデータを送信する際に必要な付加情報を加えて、送信データを構成する。どのような付加情報が必要かは、属性テーブル保持送信手段１０６に問い合わせて確認する。属性テーブル保持送信手段１０６は、各コンテンツ毎の属性テーブルを保持している。
【００５１】
そして、送信手段１０５は、送信データ構成手段１０４から渡された送信データを、ネットワーク３を介してコンテンツ受信装置２宛てに、ＨＴＴＰに従って送信する。
【００５２】
また、属性テーブル保持送信手段１０６は、ネットワーク３を介してコンテンツ受信装置２からの属性テーブル要求を受信して、送信手段１０５を介してコンテンツ受信装置２宛てに、対応する属性テーブルを送信する。
【００５３】
図８は、本実施の形態１のコンテンツサーバ１の動作を示すフローチャートである。以下、図７および図８を使い、図１（ａ）を用いて説明したシーケンスにおけるコンテンツサーバ１の動作を説明する。
【００５４】
属性テーブル保持送信手段１０６は、コンテンツ受信装置２から取得したいコンテンツのコンテンツ識別子を含む属性テーブル要求を受信すると（ステップ１）、当該コンテンツに対応する属性テーブルを、送信手段１０５を介してコンテンツ受信装置２宛てに送信する（ステップ２）。
【００５５】
次いで、データ要求受信手段１０２が、データ要求であるＨＴＴＰメッセージ（ＧＥＴメソッドを含む；図１（ｂ）のメッセージ１、メッセージ３）を受信する（ステップ３）と、このＨＴＴＰメッセージがコンテンツデータ取得手段１０３に渡される。
【００５６】
コンテンツデータ取得手段１０３は、受信したＨＴＴＰメッセージからコンテンツ識別子であるＵＲＩ（本実施の形態１ではｈｏｇｅ．ｅｘｅ）を抽出し、またＸ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダからデータ範囲情報を抽出する。コンテンツデータ取得手段１０３は、コンテンツ識別子で示された蓄積手段１０１に格納されているコンテンツから、データ範囲情報で示される範囲のコンテンツデータを取得する（ステップ４）。コンテンツデータ取得手段１０３は、抽出したコンテンツ識別子及びデータ範囲とともに、取得したコンテンツデータを送信データ構成手段１０４に渡す。
【００５７】
送信データ構成手段１０４は、属性テーブル保持送信手段１０６に含まれるこのコンテンツ識別子に対応する属性テーブルを参照する。要求されているデータ範囲の属性がどのようになっているかを確認し、そのデータ範囲の開始点から属性が同一の範囲を確認する。例えば、図１（ｂ）のメッセージ１であれば、まず０バイト目から２９９９バイト目までが、重要度６で同一の属性をもっていることを確認する（ステップ５）。
【００５８】
次いで、送信データ構成手段１０４は、属性が同一の範囲にあるコンテンツデータの先頭に付加情報を加える（ステップ６）。付加情報には重要度の情報が含まれる。送信すべきデータが要求されたデータ範囲の最後までに達していなければ（ステップ７）、ステップ５に戻る。図１（ｂ）のメッセージ１の例で言えば、３０００バイト目から、データ範囲の終わりである５９５９バイト目までが重要度１であることが確認され、コンテンツデータの２９９９バイト目と３０００バイト目の間に付加情報が加えられる。
【００５９】
ステップ７でデータ範囲の最後に達したら、送信データ構成手段１０４は、コンテンツデータに付加情報を加えた送信データを送信手段１０５に送り、送信手段１０５はこれをＨＴＴＰに則って送信する（ステップ８）。この際、ＨＴＴＰメッセージのＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダには、付加情報を加えた時のデータ範囲が書き込まれる。そして、送信データを送信後、ステップ３に戻る。
【００６０】
ステップ３で、データ要求を受信していない間に、コンテンツ受信装置２から新たな属性テーブル要求を受信した場合（ステップ９）、ステップ２に戻って対応する属性テーブルを送信する。不正なメッセージを受信すると（ステップ１０）、エラーレスポンスを送信し（ステップ１１）、ステップ１に戻る。データ要求も属性テーブル要求も受信できないうちに所定時間が経過してタイムアウトした場合は（ステップ１２）、ステップ１に戻る。
【００６１】
次に、本実施の形態１のコンテンツ配信システムにおけるコンテンツ受信装置２の構成と動作について説明する。
【００６２】
図９は、本実施の形態１のコンテンツ受信装置２の構成を示すブロック図である。
【００６３】
ユーザ入力手段２０１は、コンテンツサーバ１から受信しようとするコンテンツを識別する情報であるコンテンツ識別子（名前など）などのユーザーからの入力を受け付ける。具体的には、ユーザ入力手段２０１は、コンテンツ識別子と取得したいデータの範囲（１メガバイト目以降等）を受け付ける。なお、ユーザ入力手段２０１は、コンテンツ識別子のみを受け付けてもよい。ユーザ入力手段２０１が受け付ける情報の入力手段は、テンキーやキーボードやマウスやリモコンを使ってメニュー画面を操作するもの等、何でも良い。ユーザ入力手段２０１は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。
【００６４】
受信データ決定手段２０２は、ユーザ入力手段２０１からの通知、受信バッファ２０５の空き容量に関する問い合わせ結果、受信手段２０４からの通知等を受けて、要求するデータ範囲を決定する。データ範囲情報は、ユーザ入力手段２０１が受け付けた情報や、受信バッファ２０５の空き容量に関する問い合わせ結果、受信手段２０４からの通知等に基づいて決定され得る。
【００６５】
データ要求送信手段２０３は、受信を要求するコンテンツのコンテンツ識別子とデータ範囲情報を含むデータ要求を生成し、ネットワーク３を介してコンテンツサーバ１宛てに送信する。この際、属性テーブル保持受信手段２０７を参照して、受信データ決定手段２０２が決定したデータ範囲情報に加え、このデータ範囲情報に付加情報を加味した要求範囲を含むデータ要求を生成する。図１（ｂ）のメッセージ１やメッセージ３では、データ範囲情報はＸ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダに書き込まれ、付加情報を含めた範囲はＲａｎｇｅヘッダに書き込まれる。
【００６６】
受信手段２０４は、ネットワーク３から付加情報が加えられたコンテンツデータを受信し、コンテンツデータを受信バッファ２０５に渡すとともに、受信したコンテンツデータの長さまたは受信したコンテンツデータの終点位置を受信データ決定手段２０２に通知する。受信手段２０４は、コンテンツデータを受信バッファ２０５に送る前または後に付加情報を解析して、処理が必要な場合には適当な処理を行う。例えば、付加情報からコンテンツデータが暗号化されていることが分かれば、復号処理を行う。
【００６７】
コンテンツ処理手段２０６は、受信バッファ２０５からコンテンツデータを順次読み込んで必要な処理を行う。例えば、画面に表示をしたり所定の計算をしたりする。コンテンツ処理手段２０６は、ディスプレイやスピーカー等の出力デバイスを含むと考えても含まないと考えても良い。コンテンツ処理手段２０６は、出力デバイスのドライバーソフトウェアと処理ソフトウェアまたは、出力デバイスのドライバーソフトと出力デバイスと処理ソフトウェアまたは、ＭＰＵ上のアプリケーションプログラム等で実現され得る。
【００６８】
属性テーブル保持受信手段２０７は、コンテンツの受信に必要な属性テーブルを要求する属性テーブル要求を、ネットワーク３を介してコンテンツサーバ１宛てに送信する。そして、その応答としてコンテンツサーバ１から受信手段２０４を介して属性テーブルを受信し、保持する。また、属性テーブルは、データ要求送信手段２０３から参照される。
【００６９】
図１０は、本実施の形態１のコンテンツ受信装置２の動作を示すフローチャートである。以下、図９および図１０を使い、図１を用いて説明したシーケンスにおけるコンテンツ受信装置２の動作を説明する。
【００７０】
ユーザ入力手段２０１は、コンテンツサーバ１にあるコンテンツの受信開始要求を受けると（ステップ１）、要求するコンテンツ識別子（本実施の形態１ではｈｏｇｅ．ｅｘｅ）を受信データ決定手段２０２と属性テーブル保持受信手段２０７に通知する。このとき、ユーザ入力手段２０１に受信したいコンテンツの範囲も入力された場合、そのデータ範囲も受信データ決定手段２０２に通知する。
【００７１】
属性テーブル保持受信手段２０７は、ユーザ入力手段２０１から通知されたコンテンツ識別子に対応するコンテンツの属性テーブルを保持しているかどうかを判定し（ステップ２）、保持していなければ属性テーブル要求をネットワーク３を介してコンテンツサーバ１宛てに送信する（ステップ３）。
【００７２】
そして、受信手段２０４は、属性テーブルを受信すると（ステップ４）、受信した属性テーブルを属性テーブル保持受信手段２０７に渡す。属性テーブル保持受信手段２０７は、属性テーブルを渡されると、対応するコンテンツ識別子に関連づけて属性テーブルを保存し、受信データ決定手段２０２へその旨を通知する。
【００７３】
受信データ決定手段２０２は、ユーザがユーザ入力手段２０１に入力した受信したいデータの範囲と、受信バッファ２０５の空き容量から、コンテンツサーバ１に送信する要求すべきデータ範囲を決定する（ステップ５）。そして、コンテンツ識別子とともに決定したデータ範囲を示すデータ範囲情報を、データ要求送信手段２０３に通知する。
【００７４】
データ要求送信手段２０３は、受信データ決定手段２０２から通知されたコンテンツ識別子とデータ範囲情報、及び属性テーブル保持受信手段２０７を参照することにより、受信するコンテンツデータとともに得られる付加情報まで含めた要求範囲を含むデータ要求（図１（ｂ）のメッセージ１、メッセージ３）を生成し、コンテンツサーバ１宛てに送信する（ステップ６）。
【００７５】
受信手段２０４は、送信したデータ要求に対応する付加情報が加えられたコンテンツデータ（図１（ｂ）、（ｃ）のメッセージ２、メッセージ４）を受信すると（ステップ７）、付加情報を解析する（ステップ８）。付加情報が重要度に関する情報のみから成っている場合は、コンテンツ受信装置２は付加情報について特に何も処理する必要がないので、受信手段２０４は、付加情報を取り除いてコンテンツデータを受信バッファ２０５に格納する。このコンテンツデータは、コンテンツ処理手段２０６に順次読み込まれて処理される（ステップ９）。
【００７６】
受信手段２０４がすべての付加情報を解析し終わっていない（つまり、コンテンツ処理手段２０６に読み込まれていないコンテンツデータがある）ならば（ステップ１０）、ステップ８以降を繰り返す。
【００７７】
ユーザ入力手段２０１に入力されたコンテンツ識別子に対応するコンテンツのすべて（データ範囲も入力された場合はその範囲）を受信するか、ユーザがユーザ入力手段２０１に停止を指示した場合（ステップ１１）は、最初（ステップ１）に戻る。
【００７８】
ステップ２で、以前の通信等により、属性テーブル保持受信手段２０７にすでに当該コンテンツに対応する属性テーブルが保持されている場合は、属性テーブルの交換は行わず、ステップ５に進む。ただし、この場合でも属性テーブルの交換を行ってもよい。
【００７９】
ステップ４またはステップ７で、受信できないままタイムアウトしたり、またはコンテンツサーバ１からエラーレスポンスを受信した場合（ステップ１２、１３）は、エラー処理を行い（ステップ１４）、最初（ステップ１）に戻る。
【００８０】
本実施の形態１のコンテンツ配信システムにより、コンテンツサーバ１が、付加情報を除いた実際に送信すべきコンテンツの範囲を特定することができる。コンテンツ受信装置２は、コンテンツの分割方法に関わらず、付加情報を除いた実際に送信すべきコンテンツデータの範囲を指定できるので、コンテンツサーバ１は、コンテンツ受信装置２がどのように分割受信を想定しているかを知らずとも、コンテンツサーバ１は送るべきコンテンツの範囲が分かる。
【００８１】
また、コンテンツ受信装置２が、コンテンツの途中のデータから受信をしたい場合でも、コンテンツサーバ１に、そのコンテンツデータの受信開始位置を正確に指定できるので、コンテンツ受信装置２は、コンテンツの途中のデータからでも受信することができるようになる。
【００８２】
また、本実施の形態１のコンテンツ配信システムにより、コンテンツサーバ１での効果を、標準プロトコルであるＨＴＴＰで実施できる。
【００８３】
なお、本実施の形態１であげたｈｏｇｅ．ｅｘｅというコンテンツは一例であり、その他のコンテンツ、例えば、画像や音声を含むＡＶコンテンツやその他のフォーマットでもよいことは言うまでもない。
【００８４】
また、本実施の形態１において、コンテンツサーバ１とコンテンツ受信装置２の間に、例えば、中継装置が存在し、コンテンツ受信装置２から中継装置にデータ要求が送信され、中継装置がコンテンツサーバ１をアクセスし、コンテンツを取得して、コンテンツ受信装置２に当該コンテンツを送信してもよい。つまり、コンテンツサーバ１とコンテンツ受信装置２は、直接にネットワークで、データの送受信を行う必要は必ずしもない。
【００８５】
また、本実施の形態１のコンテンツ配信システムでは、コンテンツデータの受信の前に、コンテンツ受信装置２が、属性テーブルをネットワーク３を介してコンテンツサーバ１から予め受信することとしたが、コンテンツ受信装置２は、その他の方法で属性テーブルを取得、保持しておいてもよい。例えば、コンテンツサーバ１とは異なるサーバ等からネットワークを介して属性テーブルを取得するようにしてもよいし、ネットワークを介さず、記録媒体等に記録された属性テーブルを予め読み込み、保持しておくようにしてもよい。
【００８６】
（実施の形態２）
図１１は、本発明の実施の形態２のコンテンツ配信システムの構成図である。実施の形態１と同一の構成要素には同一の符号を付し、説明は省略する。
【００８７】
まず、本実施の形態２のコンテンツ配信システムにおける、ＡＶコンテンツ再生装置１４からＡＶサーバ１３に再生データ範囲を指定するプロトコル制御方法について説明する。
【００８８】
ＡＶサーバ１３は、蓄積手段１０１に記録されている画像または音声またはその両方を含むＡＶコンテンツを、ＡＶコンテンツ再生装置１４からの再生要求に応じて、ネットワーク３上に送信する。ＡＶコンテンツ再生装置１４は、ＡＶサーバ１３からＡＶコンテンツを受信し、再生手段１４０２で再生する。ＡＶコンテンツの例としては、ＭＰＥＧ動画像、ＡＣ３音声、ＪＰＥＧ静止画等である。なお、ＡＶサーバ１３、ＡＶコンテンツ再生装置１４は、それぞれ、本発明のコンテンツサーバ、コンテンツ再生装置の一例である。
【００８９】
図１２（ａ）は、ＡＶサーバ１３とＡＶコンテンツ再生装置１４間の送受信を記述したシーケンス図である。本実施の形態２では、この送受信にＨＴＴＰを用いている。図１２（ｂ）は、ＨＴＴＰメッセージの内容を、図１２（ｃ）は、ＨＴＴＰメッセージの構成をそれぞれ示している。ただし、本実施の形態２において送受信のプロトコルは問わない。図１２は、ＡＶサーバ１３の蓄積手段１０１に記録されているＡＶコンテンツｈｏｇｅｈｏｇｅ．ｍｐｇを、ＡＶコンテンツ再生装置１４がＡＶコンテンツの最初から、ネットワーク再生する場合の例である。ここで、ｈｏｇｅｈｏｇｅ．ｍｐｇは、ＭＰＥＧ動画像である。
【００９０】
図１５に、ｈｏｇｅｈｏｇｅ．ｍｐｇの構成を例示する。ｈｏｇｅｈｏｇｅ．ｍｐｇは、トータルサイズが４０００００００００バイトで、著作権保護についての属性が異なるいくつかのブロックから構成されている。１番目のブロックは１０００００バイト、２番目のブロックは８００００バイトである。なお、著作権保護属性によるブロック分けは一つの例である。他の属性によるブロック分けでもよく、またブロック分けがない（全コンテンツが１ブロックの）ＡＶコンテンツでもよい。また、トータルサイズやブロックサイズも問わない。図１１に示す蓄積手段１０１は、ハードディスクなどの不揮発性の記録媒体が好適であるが、揮発性の記録媒体でも実現可能である。
【００９１】
図１２（ａ）で、ＡＶコンテンツ再生装置１４は、最初に、取得したいＡＶコンテンツに関する属性テーブルを要求し、ＡＶサーバ１３から取得する。属性テーブルは、ＡＶコンテンツの内部でＡＶコンテンツの著作権保護属性（内部属性）がどのように変化しているのかを示す表である。ＡＶコンテンツを伝送する際に、著作権保護属性の変わり目に付加情報を付加するため、この表が必要となる。
【００９２】
図１６に、ｈｏｇｅｈｏｇｅ．ｍｐｇの属性テーブルの例を示す。オフセットはＡＶコンテンツの始まりからのバイト長を示す。この表から、０バイト目から９９９９９バイト目までは著作権保護が必要、１０００００バイト目から１７９９９９バイト目までは著作権フリーでネットワーク３上での暗号化も不要、１８００００バイト目から著作権フリーだがネットワーク３上での暗号化は必要、という属性に変化する。属性テーブルの取得にはＨＴＴＰを利用してもよいし、また別の通信プロトコルを使ってもよい。
【００９３】
図１２（ａ）に示すように、ＡＶコンテンツ再生装置１４は、属性テーブルの取得後、再生開始要求であるメッセージ１をＡＶサーバ１３に向けて送信する。図１２（ｂ）に示すように、メッセージ１はＲａｎｇｅヘッダを含み、ｈｏｇｅｈｏｇｅ．ｍｐｇの０バイト目から８０００９バイト目までの送信を要求している。また、メッセージ１は、再生範囲情報である「０−７９９９９」を持つＸ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダを含む。これは、付加情報を含まないＡＶコンテンツデータの０バイト目から７９９９９バイト目までを要求していることを示す。なお、本実施の形態２のＡＶコンテンツ送受信システムで用いられる付加情報の長さは１０バイトとする。
【００９４】
なお、Ｘ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダは、本発明の要求範囲情報の一例であり、メッセージ１およびメッセージ２が、本発明の、要求範囲情報を含むデータ要求の一例である。
【００９５】
ＡＶサーバ１３はこのメッセージ１を受信すると、メッセージ２を送信する。メッセージ２は、Ｃｏｎｔｅｎｔ−Ｒａｎｇｅヘッダを含み、０バイト目から８０００９バイト目までの送信を行うことを示している。そのうち、付加情報を含まないＡＶコンテンツデータの送信範囲は、０バイト目から７９９９９バイト目である。これに一つの付加情報を加えて０バイト目から８０００９バイト目までの送信となっている（図１２（ｃ）参照）。ＡＶコンテンツ再生装置１４は、受信したメッセージ２に所定の処理を行った後、受信データに含まれるＡＶコンテンツデータの０バイト目から７９９９９バイト目までを取り出して、ＡＶコンテンツの処理を行う。
【００９６】
メッセージ３及びメッセージ４についても同様である。ただしメッセージ４では、ＨＴＴＰメッセージの途中でＡＶコンテンツの属性が変化するので、二つの付加情報が加えられる（図１２（ｃ）参照）。図１２（ｂ）に示すように、その内容がメッセージ３のＲａｎｇｅヘッダ及びメッセージ４のＣｏｎｔｅｎｔ−Ｒａｎｇｅヘッダに反映されている。以降、ＡＶコンテンツの最後まで達するか、ＡＶコンテンツ再生装置１４のユーザによって再生が停止されるまで、上記のメッセージの送受信を繰り返す。
【００９７】
次に、本実施の形態２のコンテンツ配信システムにおけるＡＶサーバ１３の構成と動作について説明する。
【００９８】
図１３は、本実施の形態２のＡＶサーバ１３の構成を示すブロック図である。図１３で、蓄積手段１０１には一つ以上の画像または音声またはその両方を含むＡＶコンテンツが蓄積されている。再生開始要求受信手段１３０１は、ネットワーク３を介してＡＶコンテンツ再生装置１４からの再生開始要求を受信する。再生開始要求は、ＡＶコンテンツを識別する情報であるＡＶコンテンツ識別子と、当該ＡＶコンテンツ識別子で識別されるＡＶコンテンツのどの範囲を送信すべきかを指示する情報である再生範囲情報を含んでいる。
【００９９】
ＡＶコンテンツデータ取得手段１３０２は、再生開始要求受信手段１３０１が受信した再生開始要求に含まれるデータ範囲情報から、送信すべき範囲のＡＶコンテンツデータを蓄積手段１０１から取り出して、送信データ構成手段１０４に渡す。
【０１００】
暗号手段１３０３は、送信データ構成手段１０４から入力されたＡＶコンテンツデータを暗号化して送信手段１０５に渡す。
【０１０１】
暗号化のための鍵は、暗号鍵生成手段１３０４が生成する。ＡＶサーバ１３とＡＶコンテンツ再生装置１４間であらかじめ決められた手順で復号化のための情報を通知する方法を決めておき、送信データ構成手段１０４が生成する付加情報にその方法に則った復号化のための情報を付加する。鍵そのものは暗号手段１３０３に渡され、ＡＶコンテンツデータの暗号化に使用される。本実施の形態２では、ＡＶコンテンツの著作権属性が変化するたびに鍵を変更するものとする。暗号のための鍵と復号のための鍵は同一の鍵（共通鍵）でもよいし、異なる鍵でもよい。
【０１０２】
送信データ構成手段１０４、送信手段１０５、属性テーブル保持送信手段１０６は、それぞれ実施の形態１で説明したものと同じ機能を有するが、本実施の形態２においては、取り扱うコンテンツがＡＶコンテンツになる。また、本実施の形態２では、付加情報の内容が、著作権保護の状態及び復号のための情報である。
【０１０３】
図１７は、本実施の形態２のＡＶサーバ１３の動作を示すフローチャートである。以下、図１３および図１７を使い、図１２を用いて説明したシーケンスにおけるＡＶサーバ１３の動作を説明する。
【０１０４】
属性テーブル保持送信手段１０６は、ＡＶコンテンツ再生装置１４から取得したいＡＶコンテンツのＡＶコンテンツ識別子を含む属性テーブル要求を受信すると（ステップ１）、当該ＡＶコンテンツに対応する属性テーブルを、送信手段１０５を介してＡＶコンテンツ再生装置１４宛てに送信する（ステップ２）。
【０１０５】
次いで、再生開始要求受信手段１３０１が、再生開始要求であるＨＴＴＰメッセージ（ＧＥＴメソッドを含む；図１２（ｂ）のメッセージ１、メッセージ３）を受信すると（ステップ３）、このＨＴＴＰメッセージがＡＶコンテンツデータ取得手段１３０２に渡される。
【０１０６】
ＡＶコンテンツデータ取得手段１３０２は、受信したＨＴＴＰメッセージからＡＶコンテンツ識別子であるＵＲＩ（本実施の形態２ではｈｏｇｅｈｏｇｅ．ｍｐｇ）を抽出し、またＸ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダから再生範囲情報を抽出する。ＡＶコンテンツデータ取得手段１３０２は、ＡＶコンテンツ識別子で示された蓄積手段１０１に格納されているＡＶコンテンツから、再生範囲情報で示される範囲のＡＶコンテンツデータを取得する（ステップ４）。ＡＶコンテンツデータ取得手段１３０２は、抽出したＡＶコンテンツ識別子及び再生範囲とともに、取得したＡＶコンテンツデータを送信データ構成手段１０４に渡す。
【０１０７】
送信データ構成手段１０４は、属性テーブル保持送信手段１０６に含まれるこのＡＶコンテンツ識別子に対応する属性テーブルを参照する。要求されている再生範囲の属性がどのようになっているかを確認し、その再生範囲の開始点から属性が同一の範囲を確認する（ステップ５）。例えば、図１２（ｂ）のメッセージ１であれば、再生範囲がすべて著作権保護が必要という同一の属性をもっていることを確認する。メッセージ３であれば、再生範囲の８００００バイト目から９９９９９バイト目までは著作権保護が必要という同一の属性をもっていることを確認する。
【０１０８】
次いで、送信データ構成手段１０４は、送信すべきＡＶコンテンツデータの著作権属性から、ＡＶコンテンツデータの送信の際に暗号化が必要かどうかを判定し（ステップ６）、必要なら、暗号鍵生成手段１３０４に、鍵の生成と暗号手段１３０３への設定を指示する。暗号鍵生成手段１３０４は、鍵を生成し、暗号手段１３０３へ設定するとともに（ステップ７）、復号のための情報を送信データ構成手段１０４に通知する。
【０１０９】
送信データ構成手段１０４は、属性テーブル保持送信手段１０６を参照し、属性テーブルから著作権保護の状態（この場合、著作権保護必要）と、暗号鍵生成手段１３０４からの復号のための情報を含む付加情報を生成する（ステップ８）。また、送信データ構成手段１０４は、暗号化が必要なＡＶコンテンツデータを暗号手段１３０３に渡し、暗号手段１３０３は暗号処理を実行する（ステップ９）。
【０１１０】
その後、送信データ構成手段１０４は、まず付加情報を送信手段１０５に送り、次いで暗号化したＡＶコンテンツデータを送信手段１０５に渡すよう、暗号手段１３０３に指示する。
【０１１１】
送信手段１０５は、ＨＴＴＰに則り、まずＨＴＴＰヘッダを送信し、ついで付加情報を送信する。その後、暗号化されたＡＶコンテンツデータを送信する（ステップ１０）。
【０１１２】
ステップ６で、送信データ構成手段１０４が属性テーブル保持送信手段１０６を参照して、これから送信するＡＶコンテンツデータに暗号化をする必要がないと判断した場合は、著作権保護の状態（この場合は著作権フリーで暗号化不要）、すなわち平文であるという意味の復号化に関する情報を含む付加情報を生成する（ステップ１２）。その後、付加情報とＡＶコンテンツデータを送信手段１０５に渡し、送信手段１０５は、ＨＴＴＰに則って、付加情報が加えられたＡＶコンテンツデータを送信する（ステップ１０）。
【０１１３】
送信データ構成手段１０４は、要求されている再生範囲の最後まで達したかどうかを判断し（ステップ１１）、達していなければ、未送信の範囲のＡＶコンテンツデータについてステップ５以降の処理を行う。
【０１１４】
ステップ１１で再生範囲の最後まで達したら、ステップ３に戻り、次の再生開始要求を待つ。
【０１１５】
ステップ３で、再生開始要求を受信していない間に、ＡＶコンテンツ再生装置１４から新たな属性テーブル要求を受信した場合（ステップ１３）、ステップ２に戻り、対応する属性テーブルを送信する。不正なメッセージを受信すると（ステップ１４）、エラーレスポンスを送信し（ステップ１５）、ステップ１に戻る。再生開始要求も属性テーブル要求も受信できないうちに所定時間が経過してタイムアウトした場合は（ステップ１６）、ステップ１に戻る。
【０１１６】
次に、本実施の形態２のコンテンツ配信システムにおけるＡＶコンテンツ再生装置１４の構成と動作について説明する。
【０１１７】
図１４は、本実施の形態２のＡＶコンテンツ再生装置１４の構成を示すブロック図である。
【０１１８】
ユーザ入力手段２０１は、再生しようとするＡＶコンテンツを識別する情報であるＡＶコンテンツ識別子（名前など）などのユーザからの入力を受け付ける。具体的には、ユーザ入力手段２０１は、ＡＶコンテンツ識別子と再生したい時間情報（「３０分後以降」等）を受け付ける。なお、ユーザ入力手段２０１はＡＶコンテンツ識別子のみを受け付けてもよい。ユーザ入力手段２０１が受け付ける情報の入力手段は、テンキーやキーボードやマウスやリモコンを使ってメニュー画面を操作するもの等、何でも良い。ユーザ入力手段２０１は、テンキーやキーボード等の入力手段のデバイスドライバーや、メニュー画面の制御ソフトウェア等で実現され得る。
【０１１９】
受信データ決定手段２０２は、ユーザ入力手段２０１からの通知、受信バッファ２０５の空き容量に関する問い合わせ結果、受信手段２０４からの通知等を受けて、要求する再生範囲を決定する。再生範囲情報は、ユーザ入力手段２０１が受け付けた情報や、受信バッファ２０５の空き容量に関する問い合わせ結果、受信手段２０４からの通知等に基づいて決定され得る。再生範囲情報をバイト位置で表し、ユーザが再生したい時間情報を入力した場合は、ユーザが入力した時間情報とＡＶコンテンツ上のバイト位置との変換式や変換テーブルをあらかじめ用意しておく。
【０１２０】
再生開始要求送信手段１４０１は、再生を要求するＡＶコンテンツのＡＶコンテンツ識別子と再生範囲情報を含む再生開始要求を生成し、ネットワーク３を介してＡＶサーバ宛てに送信する。この際、属性テーブル保持受信手段２０７を参照して、受信データ決定手段２０２が決定した再生範囲情報に加え、この再生範囲情報に付加情報を加味した要求範囲を含む再生開始要求を生成する。図１２（ｂ）のメッセージ１やメッセージ３では、再生範囲情報はＸ−Ｒｅａｌ−Ｒａｎｇｅ拡張ヘッダに書き込まれ、付加情報を含めた範囲はＲａｎｇｅヘッダに書き込まれる。
【０１２１】
受信手段２０４は、ネットワーク３から付加情報が加えられたＡＶコンテンツデータを受信し、ＡＶコンテンツデータを受信バッファ２０５に渡すとともに、受信したＡＶコンテンツデータの長さまたは受信したＡＶコンテンツデータの終点位置を受信データ決定手段２０２に通知する。また、受信手段２０４は、付加情報からＡＶコンテンツデータが暗号化されているかどうかを判定し、暗号化されていれば復号に関する情報を復号鍵生成手段１４０４に通知する。
【０１２２】
再生手段１４０２は、受信バッファ２０５からＡＶコンテンツデータを順次読み込んで再生する。再生手段１４０２は、ディスプレイやスピーカ等の出力デバイスを含むと考えても含まないと考えてもよい。再生手段１４０２は、出力デバイスのドライバソフトウェアと再生処理ソフトウェアまたは、出力デバイスと、出力デバイスのドライバソフトウェアと再生処理ソフトウェア等で実現され得る。
【０１２３】
属性テーブル保持受信手段２０７は、ＡＶコンテンツの受信及び再生に必要な属性テーブルを要求する属性テーブル要求を、ネットワーク３を介してＡＶサーバ１３宛てに送信する。そして、その応答としてＡＶサーバ１３から受信手段２０４を介して属性テーブルを受信し、保持する。また、属性テーブルは、再生開始要求送信手段１４０１から参照される。
【０１２４】
復号手段１４０３は、受信手段２０４から暗号化されているＡＶコンテンツデータを受け取り、復号して受信バッファ２０５に格納する。復号のための鍵は、受信手段２０４から渡された復号のための情報をもとに復号鍵生成手段１４０４で生成され、復号手段１４０３に設定される。
【０１２５】
復号鍵生成手段１４０４は、受信手段２０４から通知された復号のための情報から、所定の方法で鍵を生成し、復号手段１４０３に設定する。鍵を生成する方法として、例えば次のような方法がある。あらかじめＡＶサーバ１３とＡＶコンテンツ再生装置１４間で、鍵を暗号／復号するための鍵（鍵暗号鍵）が共有されていて、その鍵暗号鍵で復号のための鍵が暗号化されているものを復号のための情報として付加情報に含ませる。復号鍵生成手段１４０４は、共有している鍵暗号鍵で、復号のための鍵を算出する。
【０１２６】
図１８は、本実施の形態２のＡＶコンテンツ再生装置１４の動作を示すフローチャートである。以下、図１４および図１８を使い、図１２を用いて説明したシーケンスにおけるＡＶコンテンツ再生装置１４の動作を説明する。
【０１２７】
ユーザ入力手段２０１は、ＡＶサーバ１３にあるＡＶコンテンツの再生開始要求を受けると（ステップ１）、要求するＡＶコンテンツ識別子（本実施の形態２ではｈｏｇｅｈｏｇｅ．ｍｐｇ）を受信データ決定手段２０２と属性テーブル保持受信手段２０７に通知する。このとき、ユーザ入力手段２０１に再生したいＡＶコンテンツの範囲も入力された場合、その再生範囲も受信データ決定手段２０２に通知する。
【０１２８】
属性テーブル保持受信手段２０７は、ユーザ入力手段２０１から通知されたＡＶコンテンツ識別子に対応するＡＶコンテンツの属性テーブルを保持しているかどうかを判定し（ステップ２）、保持していなければ属性テーブル要求をネットワーク３を介してＡＶサーバ１３宛てに送信する（ステップ３）。
【０１２９】
そして、受信手段２０４は、属性テーブルを受信すると（ステップ４）、受信した属性テーブルを属性テーブル保持受信手段２０７に渡す。属性テーブル保持受信手段２０７は、属性テーブルを渡されると、対応するＡＶコンテンツ識別子と関連づけて属性テーブルを保存し、受信データ決定手段２０２へその旨を通知する。
【０１３０】
受信データ決定手段２０２は、ユーザがユーザ入力手段２０１に入力した再生したいＡＶコンテンツの範囲と、受信バッファ２０５の空き容量から、ＡＶサーバ１３に送信する要求すべき再生範囲を決定する（ステップ５）。そして、ＡＶコンテンツ識別子とともに決定した再生範囲を示す再生範囲情報を、再生開始要求送信手段１４０１に通知する。
【０１３１】
再生開始要求送信手段１４０１は、受信データ決定手段２０２から通知されたＡＶコンテンツ識別子と再生範囲情報、及び属性テーブル保持受信手段２０７を参照することにより、受信するＡＶコンテンツデータとともに得られる付加情報まで含めた要求範囲を含む再生開始要求（図１２（ｂ）のメッセージ１、メッセージ３）を生成し、ＡＶサーバ１３宛てに送信する（ステップ６）。
【０１３２】
受信手段２０４は、送信した再生開始要求に対応する付加情報が加えられたＡＶコンテンツデータ（図１２（ｂ）、（ｃ）のメッセージ２、メッセージ４）を受信すると（ステップ７）、付加情報を解析し（ステップ８）、著作権保護の状態を確認してＡＶコンテンツデータが暗号化されているかどうかを判定する（ステップ９）。暗号化されていれば、受信手段２０４は、復号鍵生成手段１４０４に、付加情報に含まれている復号のための情報を通知する。
【０１３３】
復号鍵生成手段１４０４は、通知された復号のための情報から鍵を生成し、復号手段１４０３に設定する（ステップ１０）。その後、復号鍵生成手段１４０４は、鍵設定が終わった旨を受信手段２０４に通知する。
【０１３４】
復号鍵生成手段１４０４から鍵設定終了の通知を受けると、受信手段２０４は、受信したＡＶコンテンツデータを復号手段１４０３に渡す。この時、ステップ７で受信したＡＶコンテンツデータに複数の付加情報が付加されていた場合、受信手段２０４は、次の付加情報の直前までのＡＶコンテンツデータを復号手段１４０３に渡す。
【０１３５】
復号手段１４０３は受信手段２０４から渡されたＡＶコンテンツデータを、復号鍵生成手段１４０４が設定した鍵を用いて復号し（ステップ１１）、受信バッファ２０５に格納する。再生手段１４０２は、受信バッファ２０５に格納された復号化されたＡＶコンテンツデータを順次取り出し、出力デバイス等でＡＶコンテンツデータを再生する（ステップ１２）。
【０１３６】
ステップ９で暗号化されていないと判定した場合、受信手段２０４は、受信したＡＶコンテンツデータを直接受信バッファ２０５に格納し、そのＡＶコンテンツデータは再生手段１４０２によって再生される（ステップ１２）。この場合でも、ステップ７で受信したＡＶコンテンツデータに複数の付加情報が付加されていた場合は、受信手段２０４は、次の付加情報の直前までのＡＶコンテンツデータを復号手段１４０３に渡す。
【０１３７】
受信手段２０４がすべての付加情報を解析し終わっていない（つまり、再生手段１４０２に読み込まれていないＡＶコンテンツデータがある）ならば（ステップ１３）、ステップ８以降を繰り返す。
【０１３８】
ユーザ入力手段２０１に入力されたＡＶコンテンツ識別子に対応するＡＶコンテンツのすべて（再生範囲も入力された場合はその範囲）を受信するか、ユーザがユーザ入力手段２０１に停止を指示した場合（ステップ９）は、最初（ステップ１）に戻る。そうでない場合は、ステップ５以降を繰り返す。
【０１３９】
ステップ２で、以前の通信等により、属性テーブル保持受信手段２０７にすでに当該ＡＶコンテンツに対応する属性テーブルが保持されている場合は、属性テーブルの交換は行わず、ステップ５に進む。ただし、この場合でも属性テーブルの交換を行ってもよい。
【０１４０】
ステップ４またはステップ７で、受信できないままタイムアウトしたり、またはＡＶサーバ１３からエラーレスポンスを受信した場合（ステップ１５、１６）は、エラー処理を行い（ステップ１７）、最初（ステップ１）に戻る。
【０１４１】
本実施の形態２のコンテンツ配信システムでは、実施の形態１のコンテンツ配信システムの有する効果に加えて、著作権保護の状態を付加情報に含んでいる場合でも、ＡＶサーバ１３が、付加情報を除いた実際に送信すべきＡＶコンテンツデータの範囲を特定することができる。
【０１４２】
また、本実施の形態２のコンテンツ配信システムでは、付加情報に復号化のための情報を含む場合でも、ＡＶサーバ１３が、付加情報を除いた実際に送信すべきＡＶコンテンツデータの範囲を特定することができる。
【０１４３】
なお、本実施の形態２であげたｈｏｇｅｈｏｇｅ．ｍｐｇというＡＶコンテンツは一例であり、その他のＡＶコンテンツ、例えば、ＪＰＥＧ静止画やＡＣ３音声やその他のフォーマットでもよいことは言うまでもない。また、ＡＶコンテンツに限らず、ＡＶコンテンツ以外のコンテンツデータであってもよい。
【０１４４】
また、本実施の形態２において、ＡＶサーバ１３とＡＶコンテンツ再生装置１４の間に、例えば、中継装置が存在し、ＡＶコンテンツ再生装置１４から中継装置に再生開始要求が送信され、中継装置がＡＶサーバ１３をアクセスし、ＡＶコンテンツを取得して、ＡＶコンテンツ再生装置１４に当該ＡＶコンテンツを送信してもよい。つまり、ＡＶサーバ１３とＡＶコンテンツ再生装置１４は、直接にネットワークで、データの送受信を行う必要は、必ずしもない。
【０１４５】
また、本実施の形態２のコンテンツ配信システムでは、ＡＶコンテンツデータの受信の前に、ＡＶコンテンツ再生装置１４が、属性テーブルをネットワーク３を介してＡＶサーバ１３から予め受信することとしたが、ＡＶコンテンツ再生装置１４は、その他の方法で属性テーブルを取得、保持しておいてもよい。例えば、ＡＶサーバ１３とは異なるサーバ等からネットワークを介して属性テーブルを取得するようにしてもよいし、ネットワークを介さず、記録媒体等に記録された属性テーブルを予め読み込み、保持しておくようにしてもよい。
【０１４６】
なお、本発明のプログラムは、上述した本発明のコンテンツ配信システムの全部又は一部の手段又は装置の機能をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムである。
【０１４７】
また、本発明の記録媒体は、上述した本発明のコンテンツ配信システムの全部又は一部の手段又は装置の全部又は一部の機能をコンピュータにより実行させるためのプログラムを担持した記録媒体であり、コンピュータにより読み取り可能かつ、読み取られた前記プログラムが前記コンピュータと協働して利用される記録媒体である。
【０１４８】
なお、本発明の上記「一部の手段又は装置」とは、それらの複数の手段の内の、一つ又は幾つかの手段又は装置を意味する。
【０１４９】
また、本発明の上記「手段又は装置の機能」とは、前記手段の全部又は一部の機能を意味する。
【０１５０】
また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であっても良い。
【０１５１】
また、記録媒体としては、ＲＯＭ等が含まれ、伝送媒体としては、インターネット等の伝送媒体、光・電波・音波等が含まれる。
【０１５２】
また、上述した本発明のコンピュータは、ＣＰＵ等の純然たるハードウェアに限らず、ファームウェアや、ＯＳ、更に周辺機器を含むものであっても良い。
【０１５３】
なお、以上説明した様に、本発明の構成は、ソフトウェア的に実現しても良いし、ハードウェア的に実現しても良い。
【産業上の利用可能性】
【０１５４】
付加情報にコンテンツデータまたはＡＶコンテンツデータの利用者情報を含ませることによってアクセス制限の用途でも使用できる。またＨＴＴＰ以外の標準または非標準のプロトコルにも使用を拡大できる。
【図面の簡単な説明】
【０１５５】
【図１（ａ）】本発明の実施の形態１のコンテンツ送受信システムにおける、コンテンツサーバとコンテンツ受信装置間のシーケンス図
【図１（ｂ）】本発明の実施の形態１のコンテンツ送受信システムにおける、ＨＴＴＰメッセージ内容を示す図
【図１（ｃ）】本発明の実施の形態１のコンテンツ送受信システムにおける、ＨＴＴＰメッセージの構成を示す図
【図２】コンテンツデータを分割送信する際のＨＴＴＰメッセージの構成を示す図
【図３】コンテンツデータを分割送信する際のＨＴＴＰメッセージの構成を示す図
【図４】本発明の実施の形態１のコンテンツ配信システムのネットワークの構成を示す図
【図５】本発明の実施の形態１で説明するコンテンツの構成を示す図
【図６】本発明の実施の形態１で説明するコンテンツの属性テーブルを示す図
【図７】本発明の実施の形態１のコンテンツサーバの構成を示すブロック図
【図８】本発明の実施の形態１のコンテンツサーバの動作を示すフローチャート
【図９】本発明の実施の形態１のコンテンツ受信装置の構成を示すブロック図
【図１０】本発明の実施の形態１のコンテンツ受信装置の動作を示すフローチャート
【図１１】本発明の実施の形態２のコンテンツ配信システムのネットワークの構成を示す図
【図１２（ａ）】本発明の実施の形態２のコンテンツ配信システムにおける、ＡＶサーバとＡＶコンテンツ再生装置間の送受信を記述したシーケンス図
【図１２（ｂ）】本発明の実施の形態２のコンテンツ配信システムにおける、ＨＴＴＰメッセージ内容を示す図
【図１２（ｃ）】本発明の実施の形態２のコンテンツ配信システムにおける、ＨＴＴＰメッセージの構成を示す図
【図１３】本発明の実施の形態２のＡＶサーバの構成を示すブロック図
【図１４】本発明の実施の形態２のＡＶコンテンツ再生装置の構成を示すブロック図
【図１５】本発明の実施の形態２で説明するＡＶコンテンツの構成を示す図
【図１６】本発明の実施の形態２で説明するＡＶコンテンツの属性テーブルを示す図
【図１７】本発明の実施の形態２のＡＶサーバの動作を示すフローチャート
【図１８】本発明の実施の形態２のＡＶコンテンツ再生装置の動作を示すフローチャート
【符号の説明】
【０１５６】
１  コンテンツサーバ
１０１  蓄積手段
１０２  データ要求受信手段
１０３  コンテンツデータ取得手段
１０４  送信データ構成手段
１０５  送信手段
１０６  属性テーブル保持送信手段
２  コンテンツ受信装置
２０１  ユーザ入力手段
２０２  受信データ決定手段
２０３  データ要求送信手段
２０４  受信手段
２０５  受信バッファ
２０６  コンテンツ処理手段
２０７  属性テーブル保持受信手段
３  ネットワーク
１３  ＡＶサーバ
１３０１  再生開始要求受信手段
１３０２  ＡＶコンテンツデータ取得手段
１３０３  暗号手段
１３０４  暗号鍵生成手段
１４  ＡＶコンテンツ再生装置
１４０１  再生開始要求送信手段
１４０２  再生手段
１４０３  復号手段
１４０４  復号鍵生成手段 
【図１（ａ）】
2005149029.tif 000003
【図１（ｂ）】
2005149029.tif 000004
【図１（ｃ）】
2005149029.tif 000005
【図２】
2005149029.tif 000006
【図３】
2005149029.tif 000007
【図４】
2005149029.tif 000008
【図５】
2005149029.tif 000009
【図６】
2005149029.tif 000010
【図７】
2005149029.tif 000011
【図８】
2005149029.tif 000012
【図９】
2005149029.tif 000013
【図１０】
2005149029.tif 000014
【図１１】
2005149029.tif 000015
【図１２（ａ）】
2005149029.tif 000016
【図１２（ｂ）】
2005149029.tif 000017
【図１２（ｃ）】
2005149029.tif 000018
【図１３】
2005149029.tif 000019
【図１４】
2005149029.tif 000020
【図１５】
2005149029.tif 000021
【図１６】
2005149029.tif 000022
【図１７】
2005149029.tif 000023
【図１８】
2005149029.tif 000024