JPWO2005033957A1 - コンテンツ取得方法 - Google Patents

Abstract

本発明は、コンテンツ取得装置にコンテンツデータの属性情報を確実に受信させる。本発明は、取得使用情報提供サーバ６において、クライアント端末２から送信されたファイル要求情報を受信すると、コンテンツデータのコンテンツ識別情報及び属性情報を、コンテンツ取得側の一部機能を代理する代理サーバ４を経由させた際に取り除かれない部分に格納した取得使用ファイル３５を当該代理サーバ４を介してクライアント端末２に送信することにより、取得使用ファイル３５を送信して代理サーバ４を経由させてもその取得使用ファイル３５内の属性情報が取り除かれることを回避してクライアント端末２に送信でき、クライアント端末２に属性情報を確実に受信させることができる。

Description

本発明はコンテンツ取得方法に関し、例えば楽曲のコンテンツデータをサーバからネットワークを介してクライアント端末で取得する場合に適用して好適なものである。

従来のダウンロードシステムにおいて、ＷＷＷサーバは、ダウンロード対象ファイルのヘッダ部分に、ファイル名、ファイルサイズ（すなわち、ダウンロード対象ファイルのファイルサイズ）、ファイル作成日付等の各種情報を格納したダウンロード用検査データを結合してダウンロード用ファイルを作成する。そしてＷＷＷサーバは、かかるダウンロード用ファイルをクライアントに送信している。
一方、クライアントは、ＷＷＷサーバからダウンロード用ファイルを受信したとき、ヘッダ部分のダウンロード用検査データ内のファイルサイズと、ダウンロード対象ファイルの実際のファイルサイズとを比較する。その結果、クライアントは、比較したファイルサイズ同士が一致すれば、ダウンロードが成功したことをＷＷＷサーバに送信する。これに対してクライアントは、比較したファイルサイズ同士が一致しなければ、ファイルサイズ不一致をＷＷＷサーバに送信していた（例えば、特許文献１参照）。
特開２００３−１５０４８０公報（第５頁、第６頁、図２、図４）。 ところでかかる構成のダウンロードシステムには、クライアントを外部からの不正な侵入から保護する保護機能や、クライアントに対するアクセス管理機能等のように、クライアント側の機能を一部代理して実行する、いわゆるプロキシサーバと呼ばれる代理サーバが設けられる場合がある。
また最近、かかる構成のダウンロードシステムでは、クライアントと、インターネット上のＷＷＷサーバとが、データの転送速度の高速化等に伴い、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルに準じて通信することが一般的になっている。
なおＨＴＴＰでは、送信ファイルの本体部分に対し、提供対象データとして例えばコンテンツデータを格納し得るように規定されている。またかかるＨＴＴＰでは、送信ファイルのヘッダ部分に対し、コンテンツレングス（「Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ」）ヘッダフィールドと呼ばれる項目で、本体部分のコンテンツデータの属性情報でなるファイルサイズを格納し得ると共に、トランスファエンコーディング（「Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ」）ヘッダフィールドと呼ばれる項目で、当該コンテンツデータに対して送信側で施したエンコードの種類を指定するエンコード指定情報を格納し得る等のように、多数の項目により、本体部分に格納しているデータや、ＷＷＷサーバ、クライアント及び代理サーバ等に関する各種情報を格納し得るように規定されている。
ＷＷＷサーバは、このようなＨＴＴＰに準じてクライアントと通信する場合、本体部分をダウンロード対象ファイルとし、かつヘッダ部分にそのダウンロード対象ファイルのファイルサイズを格納したダウンロード用ファイルを作成する。そしてＷＷＷサーバは、かかるダウンロード用ファイルを代理サーバ経由でクライアントに送信する。
ところが代理サーバに対しては、「もし、送信ファイルのヘッダ部分にコンテンツレングスヘッダフィールドがあれば、そのオクテット中の１０進数の値は、エンティティ長さと転送長さを表す。もしそれら２つの長さが違うならばコンテンツレングスヘッダフィールドを送ってはならない（例えば、トランスファエンコーディングヘッダフィールドがある場合）。もし、メッセージがトランスファエンコーディングヘッダフィールドとコンテンツレングスヘッダフィールドとを一緒に送ってきたならば、後者（すなわち、コンテンツレングスヘッダフィールド）を無視しなければならない」（ｈｔｔｐ：／／ｗｗｗ．ｓｔｕｄｙｉｎｇｈｔｔｐ．ｎｅｔ／ｒｆｃ＿ｊａ／２６１６／ｓｅｃ４．ｈｔｍｌ＃ｓｅｃ４．４参照）のように、送信ファイルのヘッダ部分にトランスファエンコーディングヘッダフィールドとコンテンツレングスヘッダフィールドの両方が格納されている場合、コンテンツレングスヘッダフィールドを送らないように規定されている。
このためかかる構成のダウンロードシステムにおいて代理サーバは、当該代理サーバに対する規定に照らし合わせると、ＷＷＷサーバから送信されたダウンロード用ファイルのヘッダ部分からファイルサイズを取り除く場合がある。従ってクライアントは、ＷＷＷサーバからダウンロード用ファイルの一部としてファイルサイズを確実には受信し難いという問題があった。

本発明は以上の点を考慮してなされたもので、コンテンツデータの属性情報を確実に受信し得るコンテンツ取得方法を提案しようとするものである。
かかる課題を解決するため本発明のコンテンツ取得方法においては、コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信ステップと、ファイル要求情報の送信に応じて取得使用情報提供装置から送信された、コンテンツデータのコンテンツ識別情報及び属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された取得使用ファイルを当該代理装置を介して受信する情報受信ステップと、取得使用ファイル内の取得使用情報に従って、コンテンツデータを要求するコンテンツ要求情報をコンテンツ提供装置に送信するコンテンツ要求情報送信ステップと、コンテンツ要求情報の送信に応じてコンテンツ提供装置から送信されたコンテンツデータを受信するコンテンツ受信ステップとを設けるようにした。
従って本発明のコンテンツ取得方法では、取得使用情報提供装置から送信された取得使用ファイルが代理装置を経由しても、当該代理装置でその取得使用ファイルに格納しているコンテンツデータの属性情報が取り除かれずにそのまま送信されることにより、当該コンテンツデータの属性情報を確実に受信することができる。
また本発明の取得使用情報提供方法においては、コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信ステップと、受信したファイル要求情報に応じてコンテンツデータのコンテンツ識別情報及び属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した取得使用ファイルを当該代理装置を介してコンテンツ取得装置に送信する情報送信ステップとを設けるようにした。
従って本発明の取得使用情報提供方法では、取得使用ファイルを送信して代理装置を経由させても、当該代理装置でその取得使用ファイルに格納しているコンテンツデータの属性情報が取り除かれることを回避してそのままコンテンツ取得装置に送信することができる。
さらに本発明のコンテンツ取得装置においては、コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信手段と、ファイル要求情報の送信に応じて取得使用情報提供装置から送信された、コンテンツデータのコンテンツ識別情報及び属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された取得使用ファイルを当該代理装置を介して受信する情報受信手段と、取得使用ファイル内の取得使用情報に従って、コンテンツデータを要求するコンテンツ要求情報をコンテンツ提供装置に送信するコンテンツ要求情報送信手段と、コンテンツ要求情報の送信に応じてコンテンツ提供装置から送信されたコンテンツデータを受信するコンテンツ受信手段とを設けるようにした。
従って本発明のコンテンツ取得方法では、取得使用情報提供装置から送信された取得使用ファイルが代理装置を経由しても、当該代理装置でその取得使用ファイルに格納しているコンテンツデータの属性情報が取り除かれずにそのまま送信されることにより、当該コンテンツデータの属性情報を確実に受信することができる。
さらに本発明の取得使用情報提供装置においては、コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信手段と、要求情報受信手段により受信したファイル要求情報に応じてコンテンツデータのコンテンツ識別情報及び属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した取得使用ファイルを当該代理装置を介してコンテンツ取得装置に送信する情報送信手段とを設けるようにした。
従って本発明の取得使用情報提供方法では、取得使用ファイルを送信して代理装置を経由させても、当該代理装置でその取得使用ファイルに格納しているコンテンツデータの属性情報が取り除かれることを回避してそのままコンテンツ取得装置に送信することができる。
さらに本発明のコンテンツ取得プログラムにおいては、情報処理装置に対して、コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信ステップと、ファイル要求情報の送信に応じて取得使用情報提供装置から送信された、コンテンツデータのコンテンツ識別情報及び属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された取得使用ファイルを当該代理装置を介して受信する情報受信ステップと、取得使用ファイル内の取得使用情報に従って、コンテンツデータを要求するコンテンツ要求情報をコンテンツ提供装置に送信するコンテンツ要求情報送信ステップと、コンテンツ要求情報の送信に応じてコンテンツ提供装置から送信されたコンテンツデータを受信するコンテンツ受信ステップとを実行させるようにした。
従って本発明のコンテンツ取得プログラムでは、情報処理装置に対して、取得使用情報提供装置から送信された取得使用ファイルが代理装置を経由しても、当該代理装置でその取得使用ファイルに格納されているコンテンツデータの属性情報が取り除かれずにそのまま送信されることにより、当該コンテンツデータの属性情報を確実に受信させることができる。
さらに本発明の取得使用情報提供プログラムにおいては、情報処理装置に対して、コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信ステップと、受信したファイル要求情報に応じてコンテンツデータのコンテンツ識別情報及び属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した取得使用ファイルを当該代理装置を介してコンテンツ取得装置に送信する情報送信ステップとを実行させるようにした。
従って本発明の取得使用情報提供プログラムでは、情報処理装置に対して、取得使用ファイルを送信して代理装置を経由させても、当該代理装置でその取得使用ファイルに格納しているコンテンツデータの属性情報が取り除かれることを回避してそのままコンテンツ取得装置に送信させることができる。
本発明によれば、取得使用情報提供装置において、コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信すると、これに応じてコンテンツデータのコンテンツ識別情報及び属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した取得使用ファイルを当該代理装置を介してコンテンツ取得装置に送信するようにしたことにより、取得使用ファイルを送信して代理装置を経由させても、当該代理装置でその取得使用ファイルに格納しているコンテンツデータの属性情報が取り除かれることを回避してそのままコンテンツ取得装置に送信することができ、かくしてコンテンツ取得装置に対してコンテンツデータの属性情報を確実に受信させ得るコンテンツ取得方法、取得使用情報提供装置、コンテンツ取得装置、取得使用情報提供装置、コンテンツ取得プログラム及び取得使用情報提供プログラムを実現することができる。

図１は、本発明によるデータ配信システムの全体構成の一実施の形態を示す略線的斜視図である。
図２は、代理サーバの回路構成を示すブロック図である。
図３は、ポータルサーバの回路構成を示すブロック図である。
図４は、取得使用情報提供サーバの回路構成を示すブロック図である。
図５は、取得使用ファイルの構成を示す略線図である。
図６は、データサイズリストの構成を示す略線図である。
図７は、コンテンツ提供サーバの回路構成を示すブロック図である。
図８は、属性情報提供サーバの回路構成を示すブロック図である。
図９は、コンテンツ属性ファイルの構成を示す略線図である。
図１０は、クライアント端末の回路構成を示すブロック図である。
図１１は、コンテンツデータのディレクトリ管理の説明に供する略線図である。
図１２は、クライアント端末のプログラムモジュールを示す略線図である。
図１３は、楽曲購入処理手順（１）を示すシーケンスチャートである。
図１４は、楽曲購入処理手順（２）を示すシーケンスチャートである。
図１５は、楽曲購入処理手順（１）を示すシーケンスチャートである。
図１６は、楽曲購入処理手順（２）を示すシーケンスチャートである。
図１７は、楽曲購入処理手順（３）を示すシーケンスチャートである。
図１８は、取得使用ファイルの構成を示す略線図である。
図１９は、取得処理の経過状況を示すログの説明に供する略線図である。

符号の説明

１……データ配信システム、２……クライアント端末、３……ネットワーク、４……代理サーバ、５……ポータルサーバ、６……取得使用情報提供サーバ、７……コンテンツ提供サーバ、３０……制御部、３４……データ通信処理部、３５……取得使用ファイル、３６……データサイズリスト、１００……ＣＰＵ、１０２……ＲＯＭ、１０４……ハードディスクドライブ、１０７……ディスプレイ、１１１……表示処理部、１１４……通信処理部、１１５……ネットワークインターフェース、１３０……ＨＴＴＰメッセージプログラム、１３１……コミュニケータプログラム、１１３……著作権保護管理モジュール、１３５……楽曲購入再生モジュール、１３６……ＸＭＬブラウザ、１３７……ハードディスクコンテンツコントローラ、１３８Ａ……認証ライブラリ、１３９……データベースアクセスモジュール、１４０……コンテンツデータアクセスモジュール

以下図面について、本発明の一実施の形態を詳述する。
（１）データ配信システムの全体構成
図１において、１は全体として本発明によるデータ配信システムを示す。クライアント端末２は、コンピュータ構成の代理サーバ４経由で、インターネット等のネットワーク３上の各種サーバと通信する。またクライアント端末２は、かかる各種サーバと、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルに準じて通信する。
クライアント端末２は、ユーザにより、ネットワーク３上で提供されている音楽配信を利用して１又は複数の楽曲を購入するように要求されると、ポータルサイトを運営しているコンピュータ構成のサーバ（以下、これをポータルサーバと呼ぶ）５を介してコンピュータ構成の取得使用情報提供サーバ６にアクセスする。そしてクライアント端末２は、取得使用情報提供サーバ６から、ユーザにより購入要求された楽曲に相当するコンテンツデータ及び当該コンテンツデータの再生等に関する属性を変更するためのコンテンツ属性情報の取得に使用する取得使用ファイルを取得する。
これによりクライアント端末２は、取得使用ファイルの記述内容に従って、コンピュータ構成のコンテンツ提供サーバ７から、購入要求された楽曲毎のコンテンツデータを取得する。またクライアント端末２は、取得使用ファイルの記述内容に従って、コンピュータ構成の属性情報提供サーバ８からそのコンテンツデータに対応するコンテンツ属性情報を格納した楽曲毎のコンテンツ属性ファイルを取得する。
このようにしてクライアント端末２は、楽曲の購入要求に応じてコンテンツデータ及びコンテンツ属性ファイルを揃えて取得する。この後、クライアント端末２は、ユーザにより楽曲の再生が要求されると、コンテンツ属性ファイル内のコンテンツ属性情報に従って、対応するコンテンツデータを再生することにより当該楽曲をユーザに聴かせることができるようになされている。
（１−１）代理サーバ４の構成
図２に示すように、代理サーバ４は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）でなる制御部１０がＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１１及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２を介して起動したＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）等の基本プログラムや各種アプリケーションプログラムに従って全体を統括的に制御して各種処理を実行する。
これにより制御部１０は、例えばクライアント端末２からネットワーク３上の各種サーバに送信する情報や、当該各種サーバからクライアント端末２に送信された情報をデータ通信処理部１３を介して一旦取り込むことで、当該クライアント端末２を外部からの不正な侵入から保護する。また制御部１０は、クライアント端末２の送受信する各種情報を一旦取り込むことで、かかるクライアント端末２に対するアクセス管理を行う。このようにして制御部１０は、クライアント端末２の一部機能を代理している。
また制御部１０は、クライアント端末２により、ネットワーク３上の所望のアクセス先からコンテンツが取得される際、かかるコンテンツをデータ通信処理部１３を介して一旦取り込んで記憶部１４に複写して保持する、いわゆるキャッシュ機能を有している。従って制御部１０は、クライアント端末２や他の端末から再び同じアクセス先から同一のコンテンツを取得するように要求されたとき、そのアクセス先に再度アクセスすることなく、記憶部１４から対応するコンテンツを読み出して取得要求元のクライアント端末２や他の端末に送信する。
（１−２）ポータルサーバ５の構成
図３に示すように、ポータルサーバ５は、ＣＰＵでなる制御部２０がＲＯＭ２１及びＲＡＭ２２を介して起動したＯＳ等の基本プログラムや、コンテンツ配信サービスプログラム等の各種アプリケーションプログラムに従って全体を統括的に制御して各種処理を実行する。
これにより制御部２０は、ユーザデータベース２３に対し、データ配信システム１の利用が許可されたユーザ毎の識別情報（以下、これをユーザＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と呼ぶ）及びパスワード等の個人情報を記憶している。制御部２０は、ユーザによる１又は複数の楽曲の購入要求に応じてクライアント端末２から楽曲購入要求データが送信されると、これをデータ通信処理部２４を介して受信する。そして制御部２０は、このとき楽曲購入要求データに格納されているユーザＩＤ及びパスワードと、ユーザデータベース２３内の個人情報とに基づいてユーザに対する認証処理を実行する。
その結果、制御部２０は、楽曲の購入を要求したユーザを個人認証すると、ユーザに対して楽曲の購入を確認するための購入確認データを生成する。そして制御部２０は、かかる購入確認データを、データ通信処理部２４を介してクライアント端末２に送信することにより当該ユーザに対して楽曲を本当に購入するか否かを確認させる。
その結果、制御部２０は、クライアント端末２を利用するユーザにより楽曲の購入が確認されたことで、かかるクライアント端末２から楽曲購入確認データが送信されると、これをデータ通信処理部２４を介して受信する。制御部２０は、楽曲購入確認データの受信に応じて、先の楽曲購入要求データに格納されていた、購入要求された楽曲のコンテンツデータを識別可能な識別情報（以下、これをコンテンツＩＤと呼ぶ）を取り出し、当該取り出したコンテンツＩＤを格納したファイル要求データを生成する。そして制御部２０は、かかるファイル要求データを、データ通信処理部２４を介して取得使用情報提供サーバ６に送信する。その結果、制御部２０は、取得使用情報提供サーバ６から送信された取得使用ファイルを受信すると、当該受信した取得使用ファイルをデータ通信処理部２４を介して代理サーバ４経由でクライアント端末２に送信する。
（１−３）取得使用情報提供サーバ６の構成
図４に示すように、取得使用情報提供サーバ６は、ＣＰＵでなる制御部３０がＲＯＭ３１及びＲＡＭ３２を介して起動したＯＳ等の基本プログラムや、取得使用情報提供プログラム等の各種アプリケーションプログラムに従って全体を統括的に制御して各種処理を実行する。
ここで制御部３０は、取得使用情報データベース３３に対し、コンテンツデータのコンテンツＩＤと、コンテンツ提供サーバ７がコンテンツデータの提供用に開設しているホームページ（以下、これをコンテンツ提供用ホームページと呼ぶ）のアドレス（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と、属性情報提供サーバ８がコンテンツ属性ファイルの提供用に開設しているホームページ（以下、これを属性ファイル提供用ホームページと呼ぶ）のアドレス（ＵＲＬ）と、コンテンツデータの属性情報でなるデータサイズ情報とを楽曲毎に関連付けて取得使用情報として記憶している。
従って制御部３０は、ポータルサーバ５から送信されたファイル要求データをデータ通信処理部３４を介して受信すると、当該ファイル要求データに格納されたコンテンツＩＤに基づいて取得使用情報データベース３３の中から、購入要求された１又は複数曲分の当該コンテンツＩＤに対応するコンテンツ提供用ホームページのアドレス（以下、これをコンテンツ提供アドレスと呼ぶ）及び属性ファイル提供用ホームページのアドレス（以下、これを属性ファイル提供アドレスと呼ぶ）とコンテンツデータのデータサイズ情報とをそれぞれ探し出す。
そして制御部３０は、図５に示すように、購入要求された楽曲に対応するコンテンツＩＤと、取得使用情報データベース３３の中から探し出したコンテンツ提供アドレス及び属性ファイル提供アドレス並びにデータサイズ情報とからなる取得使用情報を格納した取得使用ファイル３５を生成する。ただし制御部３０は、取得使用ファイル３５に対し取得使用情報を、代理サーバ４を経由した際に取り除かれない本体部分に格納している。これにより制御部３０は、かかる取得使用ファイル３５を、データ通信処理部３４からポータルサーバ５及び代理サーバ４を順次経由させてクライアント端末２に送信する。
ところで制御部３０は、クライアント端末２から複数曲分の楽曲の購入要求に応じて複数のコンテンツＩＤが送信された場合、図６に示すように、複数のコンテンツデータのデータサイズ情報をリスト化してデータサイズリスト３６を生成する。そして制御部３０は、そのデータサイズリスト３６を取得使用ファイル３５の本体部分に格納している。
従って制御部３０は、ユーザにより１曲分の楽曲の購入やアルバムのような複数曲分の楽曲の購入の何れが要求されても、当該購入要求された楽曲に相当するコンテンツデータ全てのデータサイズ情報を取得使用ファイル３５の本体部分に格納してクライアント端末２に提供する。
（１−４）コンテンツ提供サーバ７の構成
図７に示すように、コンテンツ提供サーバ７は、ＣＰＵでなる制御部４０がＲＯＭ４１及びＲＡＭ４２を介して起動したＯＳ等の基本プログラムや、コンテンツ提供プログラム等の各種アプリケーションプログラムに従って全体を統括的に制御して各種処理を実行する。
これにより制御部４０は、コンテンツデータベース４３に対し、多数のコンテンツデータ及びコンテンツＩＤを互いに関連付けて記憶している。制御部４０は、クライアント端末２から取得使用ファイル３５内のコンテンツ提供アドレスに従ってコンテンツ提供用ホームページにアクセスされ、この状態で当該取得使用ファイル３５内のコンテンツＩＤを格納したコンテンツ要求データが送信されると、これをデータ通信処理部４４を介して受信する。
そして制御部４０は、そのコンテンツ要求データに格納されているコンテンツＩＤに基づいてコンデンツデータベース４３の中から対応するコンテンツデータを探し出す。これにより制御部４０は、その探し出したコンテンツデータをデータ通信処理部４４を介してクライアント端末２に送信する。
（１−５）属性情報提供サーバ８の構成
図８に示すように、属性情報提供サーバ８は、ＣＰＵでなる制御部５０がＲＯＭ５１及びＲＡＭ５２を介して起動したＯＳ等の基本プログラムや、属性情報提供プログラム等の各種アプリケーションプログラムに従って全体を統括的に制御して各種処理を実行する。
これにより制御部５０は、属性ファイルデータベース５３に対し、コンテンツ属性ファイルと、当該コンテンツ属性ファイルを提供する属性ファイル提供用ホームページの属性ファイル提供アドレスとを、当該コンテンツ属性ファイル毎に関連付けて記憶している。そして制御部５０は、クライアント端末２により取得使用ファイル３５内の属性ファイル提供アドレスに従って属性ファイル提供用ホームページにアクセスされると、これに応じて属性ファイルデータベース５３の中から当該アクセスされた属性ファイル提供用ホームページで提供するコンテンツ属性ファイルを探し出す。これにより制御部５０は、その探し出したコンテンツ属性ファイルを、データ通信処理部５４を介してクライアント端末２に送信する。
ここで図９に示すように、コンテンツ属性ファイル５７には、対応するコンテンツデータの属性を変更するためのコンテンツ属性情報として、クライアント端末２でそのコンテンツデータの暗号化を解く際に用いるコンテンツキー、当該暗号化を解いたコンテンツデータに対して送信側で施した圧縮符号化を復号する際に参照するコーデック識別値及びコーデック属性、コンテンツデータに対する利用権利として規定した再生可能な回数を示す再生制限情報、当該コンテンツデータの正当性をチェックするための正当性チェックフラグ、クライアント端末２からコンテンツデータを外部の記録媒体に複写して記録する回数を規定した、いわゆるチェックアウト回数、コーデック依存情報、対応するコンテンツデータのコンテンツＩＤ、当該コンテンツデータに対する利用権利として規定した再生可能な期間を示す再生許可開始日時及び再生許可終了日時の情報が格納されている。
従って図９からも明らかなように、クライアント端末２では、コンテンツデータのみを受信しても、そのコンテンツデータとこれに対応するコンテンツ属性ファイル５７とが揃わなければ、当該コンテンツデータに対する暗号化を解いたり、デコードしたりして再生し得ないようになっている。従って制御部５０は、このようにコンテンツデータに対応するコンテンツ属性ファイル５７を用意しておくことで、かかるコンテンツデータのみが第三者に入手されても不正に利用されることを防止している。
（１−６）クライアント端末２の構成
図１０に示すようにクライアント端末２のＣＰＵ１００は、バス１０１を介して接続されたＲＯＭ１０２から読み出してＲＡＭ１０３に展開したＯＳ等の基本プログラム及び各種アプリケーションプログラムに基づき全体の制御や所定の演算処理等を行う。これによりＣＰＵ１００は、ネットワーク３を介した楽曲購入用の通信動作、ユーザからの入出力操作、メディアからのコンテンツデータ再生やラジオ局からダウンロードしたコンテンツデータ、また楽曲の購入によって取得したコンテンツデータ及びコンテンツ属性ファイル５７のハードディスクドライブ（ＨＤＤ）１０４への書き込み及びその管理等を実行する。
操作入力部１０５は、本体部の筐体表面やリモートコントローラ（図示せず）の各種操作子に対するユーザの操作に応じた入力情報を入力処理部１０６へ送出する。入力処理部１０６は、その入力情報を、所定の処理を施した後に操作コマンドとしてＣＰＵ１００へ送出する。これによりＣＰＵ１００は、かかる操作コマンドに応じた処理を実行する。
ディスプレイ１０７は、ＣＰＵ１００による処理結果や各種情報を表示する。因みにディスプレイ１０７は、例えば本体部の筐体表面に直接取り付けられた液晶ディスプレイ等の表示デバイスや、外付けの表示デバイスであってもよい。
メディアドライブ１０８は、例えばＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）プレーヤ及びフラッシュメモリでなるメモリスティック（登録商標）等を再生するドライブである。そしてメディアドライブ１０８は、ＣＤやメモリスティック等の再生結果を、オーディオデータ処理部１０９を介してディジタルアナログ変換処理した後に２ｃｈのスピーカ１１０から出力する。
因みにＣＰＵ１００は、メディアドライブ１０８を介して再生したデータが楽曲のコンテンツデータである場合、オーディオデータファイルとしてハードディスクドライブ１０４に記憶することも可能である。
さらにＣＰＵ１００は、メディアドライブ１０８によってメモリスティックに記憶された複数枚の静止画を読み出し、これらを表示処理部１１１を介してディスプレイ１０７にスライドショーとして表示することもできる。
またＣＰＵ１００は、ハードディスクドライブ１０４に記憶した複数の楽曲をランダムアクセスで読み出し、あたかもジュークボックスのようにユーザ所望の順番で再生して出力することも可能である。
チューナ部１１２は、例えばＡＭ、ＦＭラジオチューナである。そしてチューナ部１１２は、ＣＰＵ１００の制御に基づいて、アンテナ１１３で受信された放送信号を復調し、その結果を放送音声としてオーディオデータ処理部１０９を介してスピーカ１１０から出力する。
通信処理部１１４は、ＣＰＵ１００の制御に基づいて送信データのエンコード処理を行い、ネットワークインターフェース１１５を介してネットワーク３経由で外部のネットワーク対応機器（すなわち、各種サーバ）へ送信する。また通信処理部１１４は、ネットワークインターフェース１１５を介して外部のネットワーク対応機器（すなわち、各種サーバ）から受信したコンテンツデータ等の受信データのデコード処理を行い、ＣＰＵ１００へ転送する。
（１−７）コンテンツデータのディレクトリ管理
クライアント端末２のＣＰＵ１００は、ハードディスクドライブ１０４に対して記憶するコンテンツデータを、図１１に示すディレクトリ構成で管理する。まず「ｒｏｏｔ」ディレクトリの下層に対しては、規定範囲内での任意の数の「ｆｏｌｄｅｒ」ディレクトリが作成される。この「ｆｏｌｄｅｒ」ディレクトリは、例えばコンテンツデータが属するジャンル、又は所有ユーザ等に対応して作成されるようになされている。
この「ｆｏｌｄｅｒ」ディレクトリの下層には、規定範囲内での任意の数の「ａｌｂｕｍ」ディレクトリが作成され、当該「ａｌｂｕｍ」ディレクトリは例えば１つのアルバムタイトル毎に対応するようになされている。この「ａｌｂｕｍ」ディレクトリの下層においては、その「ａｌｂｕｍ」ディレクトリに属するとされる１以上の「ｔｒａｃｋ」ファイルが格納される。この「ｔｒａｃｋ」ファイルは、１つの楽曲すなわちコンテンツデータとなるものである。
このようなコンテンツデータについてのディレクトリ管理は、ハードディスクドライブ１０４に記憶されているデータベースファイルによって行われるようになされている。
（１−８）クライアント端末２のプログラムモジュール構成
図１２に示すようにクライアント端末２のプログラムモジュールとしては、ＯＳ上で動作する。具体的にはＣＤの物販を行うＣＤ販売業者サーバ１２０、インターネットラジオサーバ１２１、上述した取得使用情報提供サーバ６、コンテンツ提供サーバ７及び属性情報提供サーバ８からなる音楽配信運営サーバ１２２、上述したポータルサーバ５からなる総合サービスサーバ１２３、ラジオ局の放送した楽曲に関する楽曲情報を関連情報としてネットワーク３を介してクライアント端末２に提供する関連情報提供サーバ１２４他の各種サーバとの間でやりとりを行う。
ＨＴＴＰメッセージプログラム１３０は、ＣＤ販売業者サーバ１２０、インターネットラジオサーバ１２１、音楽配信運営サーバ１２２、各種総合サービスを行う総合サービスサーバ１２３及び関連情報提供サーバ１２４等の各種サーバとの間のやりとりをＨＴＴＰ通信で行うものである。コミュニケータプログラム１３１は、ＨＴＴＰメッセージプログラム１３０とデータのやりとりを行うプログラムモジュールである。
コミュニケータプログラム１３１の上位には、コンテンツデータのコーデックを解釈して再生するコンテンツ再生モジュール１３２、利用権利等の著作権保護に関する情報を取り扱う著作権保護情報管理モジュール１３３が位置する。そのコンテンツ再生モジュール１３２、著作権保護情報管理モジュール１３３の上位には、インターネットラジオの選局及び再生を行うインターネットラジオ選局再生モジュール１３４、コンテンツ属性ファイル５７の内容に従って楽曲購入及び試聴曲の再生を司る楽曲購入再生モジュール１３５がそれぞれ位置している。
それらインターネットラジオ選局再生モジュール１３４、楽曲購入再生モジュール１３５の上位には、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ブラウザ１３６が位置している。そしてＸＭＬブラウザ１３６は、各種サーバからのＸＭＬファイルを解釈し、ディスプレイ１０７に対する画面表示を行う。
例えば、ＸＭＬブラウザ１３６を介してユーザにより購入用に選択された楽曲は、楽曲購入再生モジュール１３５で取得使用ファイル３５が取得された後、当該楽曲購入再生モジュール１３５及び著作権保護情報管理モジュール１３３でコンテンツデータ及びコンテンツ属性ファイル５７として取得され、ハードディスクコンテンツコントローラ１３７を介してハードディスクドライブ１０４に書き込まれる。
因みにコミュニケータプログラム１３１には、ライブラリ１３８の認証ライブラリ１３８Ａが接続されている。ライブラリ１３８は、認証ライブラリ１３８Ａによって総合サービスサーバ１２３やその他の各種サーバの認証処理を行う。
さらにコミュニケータプログラム１３１の上位には、データベースアクセスモジュール１３９、コンテンツデータアクセスモジュール１４０及びハードディスクコンテンツコントローラ１３７が位置する。
このデータベースアクセスモジュール１３９は、ハードディスクドライブ１０４に構築された各種データベースにアクセスする。コンテンツデータアクセスモジュール１４０はハードディスクドライブ１０４に格納されたコンテンツデータ及びコンテンツ属性ファイル５７にアクセスする。ハードディスクコンテンツコントローラ１３７はハードディスクドライブ１０４に格納されたコンテンツデータ及びコンテンツ属性ファイル５７を管理する。
ハードディスクコンテンツコントローラ１３７の上位には、ラジオ局が放送した楽曲のタイトル及びアーティスト名を表示するための関連情報表示モジュール１４１、及びラジオ局を選局したり、当該ラジオ局から受信した楽曲のコンテンツデータをハードディスクドライブ１０４に録音するチューナ選局再生／録音モジュール１４２が位置している。
例えば、オーディオユーザインターフェース１４３を介して選局されたラジオ局から受信した楽曲は、コンテンツデータアクセスモジュール１４０を介してハードディスクドライブ１０４へ書き込まれる。
関連情報表示モジュール１４１は、チューナ選局再生／録音モジュール１４２によって現在ラジオ局が放送している楽曲のタイトルやアーティスト名を関連情報として関連情報提供サーバ１２４からＨＴＴＰメッセージ１３０経由で受信し、これをオーディオユーザインターフェース（ＵＩ）１４３を介してディスプレイ１０７に表示する。
因みにオーディオユーザインターフェース１４３を介してディスプレイ１０７に表示した関連情報は、ライブラリ１３８のクリップライブラリ１３８Ｂに一時的に記憶することもでき、ユーザからの指示に従って最終的にはデータベースアクセスモジュール１３９を介してハードディスクドライブ１０４へ記憶される。
さらにクライアント端末２のプログラムモジュールとしては、ＣＤを再生するためのＣＤ再生モジュール１４４と、ハードディスクドライブ１０４を再生するためのＨＤＤ再生モジュール１４５とが含まれている。ＣＤ再生モジュール１４４及びＨＤＤ再生モジュール１４５は、ＣＤ及びハードディスクドライブ１０４からの再生結果をオーディオデータ処理部１０９及びスピーカ１１０を介して出力する。
（２）楽曲購入処理
（２−１）楽曲購入処理手順
次に、図１３及び図１４に示すシーケンスチャートを用い、ユーザによる楽曲の購入要求に応じてクライアント端末２及び各種サーバが実行する楽曲購入処理手順について説明する。
図１３及び図１４に示すように、クライアント端末２は、ユーザによる１又は複数の楽曲の購入要求に応じて、取得対象のコンテンツデータ及びコンテンツ属性ファイル５７を取得するための取得処理を開始する。クライアント端末２は、かかる取得処理を開始すると、ステップＳＰ１において、ユーザのユーザＩＤ、パスワード及び購入対象の楽曲に対応するコンテンツＩＤを格納した楽曲購入要求データを生成する。そしてクライアント端末２は、かかる楽曲購入要求データをポータルサーバ５に送信した後、次のステップＳＰ２に移る。
ステップＳＰ２１においてポータルサーバ５は、クライアント端末２から送信された楽曲購入要求データに基づいてユーザを個人認証した後、購入確認データを生成してクライアント端末２に送信し、次のステップＳＰ２２に移る。
ステップＳＰ２においてクライアント端末２は、ポータルサーバ５から送信された購入確認データに応じて、ユーザに対し購入希望の楽曲を所定の画面上で確認させる。その結果、クライアント端末２は、ユーザにより購入希望の楽曲が確認されると、次のステップＳＰ３に移る。
ステップＳＰ３においてクライアント端末２は、ユーザＩＤを格納した取得使用情報要求データを生成し、これをポータルサーバ５に送信して、次のステップＳＰ４に移る。
ステップＳＰ２２においてポータルサーバ５は、クライアント端末２から送信された取得使用情報要求データに応じて、購入対象の楽曲に対応するコンテンツＩＤを格納したファイル要求データを生成する。そしてポータルサーバ５は、かかるファイル要求データを取得使用情報提供サーバ６に送信する。
その結果、ステップＳＰ３１において取得使用情報提供サーバ６は、ポータルサーバ５から送信されたファイル要求データに基づいて、取得使用情報を本体部分に格納した取得使用ファイル３５を生成する。そして取得使用情報提供サーバ６は、その取得使用ファイル３５をポータルサーバ５及び代理サーバ４経由でクライアント端末２に送信する。
これによりステップＳＰ４においてクライアント端末２は、取得使用情報提供サーバ６からポータルサーバ５及び代理サーバ４経由で送信された取得使用ファイル３５を受信する。クライアント端末２は、１曲の購入要求のとき、取得使用ファイル３５からコンテンツデータのデータサイズ情報をその単体で取り出す。またクライアント端末２は、複数曲の購入要求のとき、取得使用ファイル３５からコンテンツデータのデータサイズ情報をデータサイズリストとして取り出す。
そしてクライアント端末２は、取得対象のコンテンツデータに対応する全てのデータサイズ情報の合計値と、ハードディスクの空容量とを比較する。これによりクライアント端末２は、その比較結果に応じてハードディスクに対し、取得対象の全てのコンテンツデータを記憶することができるか否かを判別する。
このステップＳＰ４において否定結果が得られると、このことはハードディスクに対して、取得対象の全てのコンテンツデータを記憶するだけの空容量がないため、このまま取得処理を継続しても取得対象のコンテンツデータのうちいくつか又は全てをハードディスクに記憶することができないことを表している。従ってクライアント端末２は、このときステップＳＰ５に移る。
そしてステップＳＰ５においてクライアント端末２は、例えばディスプレイ１０７に表示した所定の通知画面により、ユーザに対しハードディスクには取得対象のコンテンツデータを全て記憶するだけの空容量が不足していることを通知する。またクライアント端末２は、かかる通知画面により、ユーザに対し、ハードディスクからすでに記憶しているコンテンツデータ等を消去して空容量を確保しなければ、このまま取得処理を継続しても取得対象のコンテンツデータをハードディスクに記憶することができないことを通知する。このようにしてクライアント端末２は、ユーザに対する通知の後に、取得処理を一旦終了する。
これに対してステップＳＰ５において肯定結果が得られると、このことはハードディスクに対して、取得対象の全てのコンテンツデータを記憶し得る分の空容量があるため、このまま取得処理を継続しても当該取得対象のコンテンツデータを全てハードディスクに記憶することができることを表している。このときクライアント端末２は、次のステップＳＰ６に移る。
ステップＳＰ６においてクライアント端末２は、取得使用ファイル３５の中から、コンテンツ提供サーバ７に要求するコンテンツデータのコンテンツＩＤを１つ選択して、次のステップＳＰ７に移る。
ステップＳＰ７においてクライアント端末２は、取得使用ファイル３５の中から、ステップＳＰ６で選択したコンテンツＩＤに対応するコンテンツ提供アドレスを選択する。そしてクライアント端末２は、その選択したコンテンツ提供アドレスに従ってコンテンツ提供用ホームページにアクセスし、その状態でかかるコンテンツＩＤを格納したコンテンツ要求データをコンテンツ提供サーバ７に送信して、次のステップＳＰ８に移る。
ステップＳＰ４１においてコンテンツ提供サーバ７は、クライアント端末２からの要求に応じて、コンテンツＩＤで指定されたコンテンツデータを当該クライアント端末２に送信する。
従ってステップＳＰ８においてクライアント端末２は、コンテンツ提供サーバ７から送信されたコンテンツデータを受信してハードディスクに記憶し、当該コンテンツデータの受信が完了すると、次のステップＳＰ９に移る。
ステップＳＰ９においてクライアント端末２は、実際に取得要求に応じて受信の完了したコンテンツデータのデータサイズ（すなわち、ハードディスクに実際に記憶したコンテンツデータのデータサイズ）と、取得使用ファイル３５により先に通知されていた、当該コンテンツデータに対応するデータサイズ情報とを比較する。これによりクライアント端末２は、その比較結果に応じて、コンテンツデータを正常に受信して取得が成功したか否かを判別する。
このステップＳＰ９において否定結果が得られると、このことはコンテンツデータがコンテンツ提供サーバ７からの送信途中に損傷を受けたことで、当該コンテンツデータに対し、取得使用ファイル３５で通知されていたデータサイズに満たない一部分のみ受信していたことを表している。このときクライアント端末２はステップＳＰ７に戻り、そのコンテンツデータに対する再送をコンテンツ提供サーバ７に要求する。
またステップＳＰ９において肯定結果が得られると、このことはコンテンツデータがコンテンツ提供サーバ７からの送信途中に何ら損傷を受けてはいないことにより、当該コンテンツデータを取得使用ファイル３５で通知されたデータサイズ通りに正常に受信することができたことを表している。このときクライアント端末２は、次のステップＳＰ１０に移る。
ステップＳＰ１０においてクライアント端末２は、取得使用ファイル３５の中から、ステップＳＰ６で選択したコンテンツＩＤに対応する属性ファイル提供アドレスを選択する。そしてクライアント端末２は、その選択した属性ファイル提供アドレスに従って属性ファイル提供用ホームページにアクセスし、次のステップＳＰ１１に移る。
ステップＳＰ５１において属性情報提供サーバ８は、クライアント端末２のアクセスした属性ファイル提供用ホームページに対応するコンテンツ属性ファイル５７を当該クライアント端末２に送信する。
これによりステップＳＰ１１においてクライアント端末２は、属性情報提供サーバ８から送信されたコンテンツ属性ファイル５７を受信してハードディスクに記憶し、当該コンテンツ属性ファイル５７の受信が完了すると、次のステップＳＰ１２に移る。
ステップＳＰ１２においてクライアント端末２は、今回購入要求された楽曲に対応するコンテンツデータ及びコンテンツ属性ファイル５７を全て取得したか否か（すなわち、購入要求された楽曲を全て購入したか否か）を判別する。
このステップＳＰ１２において否定結果が得られると、このことは今回ユーザによりアルバム内の複数の楽曲をまとめて購入するように要求されているために、当該複数の楽曲に対応するコンテンツデータ及びコンテンツ属性ファイル５７を未だ全て取得し終えてはいないことを表している。このときクライアント端末２は、ステップＳＰ６に戻り、この後ステップＳＰ１２において肯定結果を得るまでの間、ステップＳＰ６乃至ステップＳＰ１２の処理を循環的に繰り返す。これによりクライアント端末２は、ユーザによって購入要求された楽曲に対応するコンテンツデータ及びコンテンツ属性ファイル５７を順次交互にコンテンツ提供サーバ７及び属性情報提供サーバ８から取得する。
これに対してステップＳＰ１２において肯定結果が得られると、このことは今回ユーザにより購入要求された１曲のみの楽曲、又はアルバム内の全ての楽曲に対応するコンテンツデータ及びコンテンツ属性ファイル５７を全て取得し終えたことを表している。このときクライアント端末２は取得処理を終了する。
（２−２）他の楽曲購入処理手順
次に、図１５乃至図１７に示すシーケンスチャートを用いて、上述した楽曲購入処理手順とは異なる手法の他の楽曲購入処理手順について説明する。
ただしかかる他の楽曲購入処理手順においてクライアント端末２のＣＰＵ１００は、図１２について上述したプログラムモジュールとしてのＸＭＬブラウザ１３６に相当するユーザインタフェース３１０と、ＨＴＴＰメッセージプログラム１３０、コミュニケータプログラム１３１、著作権保護管理モジュール１３３、楽曲購入再生モジュール１３５、認証ライブラリ１３８Ａ、ハードディスクコンテンツコントローラ１３７、コンテンツデータアクセスモジュール１４０及びデータベースアクセスモジュール１３９に相当するミドルウェア３１１に従って、当該他の楽曲購入処理手順における取得処理を実行している。
しかしながら他の楽曲購入処理手順では、ユーザインタフェース３１０及びミドルウェア３１１をそれぞれ説明の便宜上あたかもハードウェアとして設けられた回路ブロックのように扱って以下に説明する。
また取得使用情報提供サーバ６の制御部３０は、取得使用情報を予め用意していなくても、ユーザにより楽曲が購入要求される毎に生成することも可能である。
さらにコンテンツ提供サーバ７の制御部４０は、コンテンツデータの提供用にコンテンツ提供用ホームページを開設しなくても、クライアント端末２に対しコンテンツデータの取得用にアクセスさせるアドレス（以下、これをコンテンツ取得用アドレスと呼ぶ）を用意するだけで、コンテンツデータを提供可能である。また制御部４０は、コンテンツデータの提供時、コンテンツ取得用アドレスに対し、取得可能なコンテンツデータを対応付けておくことで、クライアント端末２に対してコンテンツＩＤを送信させなくても、かかるコンテンツデータを提供可能である。
これに加えて属性情報提供サーバ８の制御部５０も、コンテンツ属性ファイル５７の提供用に属性ファイル提供用ホームページを開設せずに、クライアント端末２に対しコンテンツ属性ファイル５７の取得用にアクセスさせるアドレス（以下、これを属性ファイル取得用アドレスと呼ぶ）を用意するだけで、コンテンツ属性ファイル５７を提供可能である。
従って、以下の他の楽曲購入処理手順については、取得使用情報提供サーバ６の制御部３０が、ユーザによる楽曲の購入要求毎に取得使用情報を生成すると共に、コンテンツ提供サーバ７及び属性情報提供サーバ８がコンテンツ提供用ホームページ及び属性ファイル提供用ホームページを用いずにコンテンツデータ及びコンテンツ属性ファイル５７を提供する場合を例にとって説明する。
因みに取得使用情報提供サーバ６の制御部３０は、コンテンツ提供サーバ７がクライアント端末２に対してコンテンツＩＤを送信させなくても、コンテンツデータを提供可能であるため、図１８に示すように、コンテンツＩＤを除き、購入要求された楽曲に対応するコンテンツデータ及びコンテンツ属性ファイルの取得用のコンテンツ取得用アドレス及び属性ファイル取得用アドレスを楽曲毎に対応付けて格納した取得使用ファイル３１５を生成する。
またコンテンツ提供サーバ７制御部４０は、ダウンロード可能な複数のコンテンツデータをアルバム単位とシングル曲単位との２種類の配信形態で配信することにより、１又は複数の楽曲をアルバム単位や、シングル曲単位で任意に選択させコンテンツデータとして購入可能にしている。
さらにかかる他の楽曲購入処理手順については、楽曲の購入に、ユーザに対する課金が生じるため、クライアント端末２や、ポータルサーバ５、取得使用情報提供サーバ６、コンテンツ提供サーバ７及び属性情報提供サーバ８と共に、新たに課金サーバ３２０を用いて以下に説明する。
図１５乃至図１７に示すように、クライアント端末２のユーザインタフェース３１０は、他の楽曲購入処理手順における取得処理を開始すると、ユーザにより購入希望の楽曲がアルバム単位又はシングル曲単位で選択された後、その購入希望の楽曲が確認されると、ミドルウェア３１１に対し、その購入希望の楽曲が確認されたことを通知する。
ステップＳＰ２０２において、クライアント端末２のミドルウェア３１１は、ユーザによって購入要求された楽曲に対応するコンテンツデータのコンテンツＩＤと、ユーザＩＤ及びパスワードとを格納した購入楽曲通知データを生成する。そしてミドルウェア３１１は、かかる購入楽曲通知データを通信処理部１１４及びネットワークインターフェース１１５を順次介してポータルサーバ５に送信する。
ステップＳＰ２２１において、ポータルサーバ５の制御部２０は、クライアント端末２から送信された購入楽曲通知データをデータ通信処理部２４を介して受信する。そして制御部２０は、その購入楽曲通知データの受信に応じて、楽曲を購入要求したユーザに対する楽曲購入処理を特定可能な例えば通し番号でなる購入識別情報を発行して、次のステップＳＰ２２２に移る。
ステップＳＰ２２２において、制御部２０は、購入楽曲通知データに格納されたユーザＩＤ及びパスワードに基づいて、ユーザデータベース２３の中から楽曲を購入要求したユーザの個人情報を特定する。そして制御部２０は、その特定した個人情報に対し、購入識別情報と、購入楽曲通知データに格納されている、購入要求された楽曲に対応するコンテンツＩＤとを対応付けて登録して、次のステップＳＰ２２３に移る。
ステップＳＰ２２３において、制御部２０は、クライアント端末２に対し、ユーザによる楽曲の購入要求に応じた取得処理で使用する取得処理使用情報を生成し、これをデータ通信処理部２４を介してクライアント端末２に送信する。
ここで取得処理使用情報には、取得使用ファイル３１５の取得に使用させる取得使用ファイル要求情報や、クライアント端末２で取得処理が中断された後の復帰時、ユーザに対する課金状況の通知を要求するために使用させる課金状況通知要求情報等が含まれている。
かかる取得使用ファイル要求情報には、クライアント端末２に対し、取得使用ファイル３１５を取得するためにアクセスさせるネットワーク３上のアドレス（以下、これをファイル取得アドレスと呼ぶ）等が含まれている。
また課金状況通知要求情報には、クライアント端末２に対し取得処理の中断から復帰してコンテンツデータ及びコンテンツ属性ファイル５７に対するデータ取得を再試行（リトライ）する際に、まずユーザに対する課金状況の通知要求用としてアクセスさせるアドレス（以下、これをリトライアドレスと呼ぶ）と、かかるリトライアドレスへのアクセスの際に通信相手（すなわち、ポータルサーバ５）に提示させる、ステップＳＰ２２１で発行された購入識別情報や、ポストデータ及びリクエストコード（要求の種類を示すコードである）等を含んでいる。
ステップＳＰ２０３において、クライアント端末２のミドルウェア３１１は、ポータルサーバ５から送信された取得処理使用情報をネットワークインターフェース１１５及び通信処理部１１４を順次介して受信する。
そしてミドルウェア３１１は、図１９に示すように、かかる取得処理使用情報に基づいて得られた課金状況通知要求情報を、今回の取得処理の経過状況を示す（すなわち、かかる取得処理の開始を示す）第１の処理経過情報（以下、これを第１のログと呼ぶ）として例えばハードディスクドライブ１０４のハードディスクに一時記憶し、次のステップＳＰ２０４に移る。
ステップＳＰ２０４において、ミドルウェア３１１は、取得処理使用情報に基づいて得られた取得使用ファイル要求情報に含まれるファイル取得アドレスにアクセスし、ポータルサーバ５に対して取得使用ファイル３１５を要求する。
ステップＳＰ２２４において、ポータルサーバ５の制御部２０は、クライアント端末２からの取得使用ファイル３１５の要求に応じて、楽曲を購入要求したユーザに対する課金処理を識別可能な課金ＩＤを発行要求する課金ＩＤ発行要求データを、データ通信処理部２４を介して課金サーバ３２０に送信する。
ステップＳＰ２３１において、課金サーバ３２０の例えばＣＰＵでなる制御部（図示せず）は、ポータルサーバ５から送信された課金ＩＤ発行要求データを、図示しないデータ通信処理部を介して受信する。そして制御部は、その課金ＩＤ発行要求データに応じて、課金ＩＤを発行して、次のステップＳＰ２３２に移る。
ステップＳＰ２３２において、課金サーバ３２０の制御部は、かかる課金ＩＤを課金ＩＤ通知データとしてデータ通信処理部を介してポータルサーバ５に送信する。
ステップＳＰ２２５において、ポータルサーバ５の制御部２０は、課金サーバ３２０から送信された課金ＩＤ通知データをデータ通信処理部２４を介して受信する。そして制御部２０は、ユーザデータベース２３に対し、かかる課金ＩＤ通知データに基づいて得られた課金ＩＤを、ステップＳＰ２２２ですでに登録している購入識別情報に対応付けて追加登録する。
また制御部２０は、このとき、楽曲を購入要求しているユーザに対し現時点ではその楽曲の購入に応じた課金が未課金であることを示す課金状況通知情報も、ステップＳＰ２２２ですでに登録している購入識別情報に対応付けてユーザデータベース２３に登録して、次のステップＳＰ２２６に移る。
ステップＳＰ２２６において、制御部２０は、ユーザによって購入要求された楽曲に対応するコンテンツＩＤを格納し、当該ユーザのクライアント端末２に対して、コンテンツデータ及びコンテンツ属性ファイル５７の取得に使用させる取得使用ファイル３１５を要求するためのファイル要求データを生成する。そして制御部２０は、かかるファイル要求データをデータ通信処理部２４を介して取得使用情報提供サーバ６に送信する。
ステップＳＰ２４１において、取得使用情報提供サーバ６の制御部３０は、ポータルサーバ５から送信されたファイル要求データをデータ通信処理部３４を介して受信する。そして制御部３０は、かかるファイル要求データに応じて、例えばコンテンツ取得用アドレス及び属性ファイル取得用アドレスを発行し、当該発行したコンテンツ取得用アドレス及び属性ファイル取得用アドレスを楽曲毎に対応付けて順番に並べるようにして格納した取得使用ファイル３１５を生成する。
なおステップＳＰ２４１では、取得使用情報提供サーバ６がコンテンツ取得用アドレス及び属性ファイル取得用アドレスを発行するようにしたが、これに限らず、コンテンツ提供サーバ７がコンテンツ取得用アドレスを発行すると共に、属性情報提供サーバ８が属性ファイル取得用アドレスを発行し、これを用いて取得使用情報提供サーバ６が取得使用ファイル３１５を生成するようにしてもよい。
これにより制御部３０は、その取得使用ファイル３１５をデータ通信処理部３４からポータルサーバ５経由でクライアント端末２に送信する。因みに取得使用情報提供サーバ６の制御部３０は、例えば、このとき生成した取得使用ファイル３１５の内容と、ポータルサーバ５から与えられた、ユーザによって購入要求された楽曲に対応するコンテンツＩＤ、及び当該ユーザに対する購入識別情報等とをデータ提供使用情報としてコンテンツ提供サーバ７や属性情報提供サーバ８と共有している。
ステップＳＰ２０５において、クライアント端末２のミドルウェア３１１は、取得使用情報提供サーバ６からポータルサーバ５経由で送信された取得使用ファイル３１５をネットワークインターフェース１１５及び通信処理部１１４を順次介して受信し、当該受信した取得使用ファイル３１５を例えばＲＡＭ１０３に一時記憶する。
そしてミドルウェア３１１は、取得使用ファイル３１５に格納されている例えば１又は複数のコンテンツ取得用アドレスの中からその並びの順番に従って１つのコンテンツ取得用アドレスを選択して、次のステップＳＰ２０６に移る。
ステップＳＰ２０６において、ミドルウェア３１１は、その選択したコンテンツ取得用アドレスにアクセスしてダウンロードするコンテンツデータを、ハードディスクに「ｔｒａｃｋ」ファイルとして記憶する際の当該「ｔｒａｃｋ」ファイルを識別可能なトラックファイル名を生成し、次のステップＳＰ２０７に移る。
ステップＳＰ２０７において、ミドルウェア３１１は、ステップＳＰ２０６で選択したコンテンツ取得用アドレスに対応するコンテンツデータと共にダウンロードするコンテンツ属性ファイル５７に格納されたコンテンツ属性情報を、ハードディスクにファイル（以下、これを属性情報ファイルと呼ぶ）として記憶する際の当該属性情報ファイルを識別可能な属性情報ファイル名を生成して、次のステップＳＰ２０８に移る。
ステップＳＰ２０８において、ミドルウェア３１１は、図１９に示すように、ステップＳＰ２０６及びステップＳＰ２０７で生成したトラックファイル名及び属性情報ファイル名を、取得処理の経過状況を示す第２の処理経過情報（以下、これを第２のログと呼ぶ）として例えばハードディスクドライブ１０４のハードディスクに一時記憶して、次のステップＳＰ２０９に移る。
ステップＳＰ２０９において、ミドルウェア３１１は、取得使用ファイル３１５の中から、ステップＳＰ２０５で選択したコンテンツ取得用アドレスにアクセスし、コンテンツ提供サーバ７に対してコンテンツデータのダウンロードを要求する。
ここでコンテンツ提供サーバ７の制御部４０は、取得使用情報提供サーバ６とデータ提供使用情報を共有した際に、ユーザにより購入要求された楽曲に対応するコンテンツＩＤと、当該ユーザの利用するクライアント端末２に対しすでに提供された取得使用ファイル３１５に記述されているコンテンツ取得用アドレスとを対応付けている。
従ってステップＳＰ２５１において、コンテンツ提供サーバ７の制御部４０は、クライアント端末２からのコンテンツデータに対するダウンロード要求に応じて、コンテンツデータベース４３に記憶している複数のコンテンツデータの中から、当該クライアント端末２がこのときアクセスしたコンテンツ取得用アドレスに対しすでに対応付けていたコンテンツＩＤのコンテンツデータを検索する。
そして制御部４０は、その検索したコンテンツデータをデータ通信処理部４４を介してクライアント端末２に送信する。
ステップＳＰ２１０において、クライアント端末２のミドルウェア３１１は、コンテンツ提供サーバ７から送信されたコンテンツデータをネットワークインターフェース１１５及び通信処理部１１４を順次介して受信しながら、上述のステップＳＰ２０６で生成したトラックファイル名の「ｔｒａｃｋ」ファイルとしてハードディスクに一時記憶し、次のステップＳＰ２１１に移る。
ところでコンテンツ提供サーバ７から提供されるコンテンツデータには、例えばヘッダ部分にかかるコンテンツデータの属性情報として、アルバム単位で購入するように用意されたデータであるか、またシングル曲単位で購入するように用意されたデータであるかを示す購入形態通知情報が格納されている。
従ってステップＳＰ２１１において、ミドルウェア３１１は、ハードディスクに一時記憶したコンテンツデータが今回の取得処理でコンテンツ提供サーバ７から最初にダウンロードしたコンテンツデータであるか否かを判別する。
このステップＳＰ２１１において肯定結果が得られると、このことはユーザにより楽曲がアルバム単位及びシングル曲単位の何れで購入要求されたかにかかわらず、ハードディスクに一時記憶したコンテンツデータがコンテンツ提供サーバ７から最初にダウンロードしたコンテンツデータであることを表しており、このときミドルウェア３１１は、次のステップＳＰ２１２に移る。
ステップＳＰ２１２において、ミドルウェア３１１は、ハードディスクに一時記憶したコンテンツデータに格納されている購入形態通知情報に基づいて、当該コンテンツデータがアルバム単位で購入されるデータであるか否かを判別する。
このステップＳＰ２１２において肯定結果が得られると、このことは今回ユーザにより複数の楽曲がアルバム単位で購入要求された（すなわちアルバムに収録されている複数の楽曲がまとめて購入要求された）ことを表しており、このときミドルウェア３１１は、次のステップＳＰ２１３に移る。
ステップＳＰ２１３において、ミドルウェア３１１は、楽曲に対するアルバム単位の購入要求に応じて現在取得中のコンテンツデータに対する「ｔｒａｃｋ」ファイルと、当該コンテンツデータを利用可能にするコンテンツ属性ファイル５７の属性情報ファイルとを特定可能（例えばパス）で、かつ当該「ｔｒａｃｋ」ファイル及び属性情報ファイル管理用の「ａｌｂｕｍ」ディレクトリを識別可能なアルバム識別情報を生成する。
因みに、かかるアルバム識別情報は、今回クライアント端末２で取得するコンテンツデータ及びコンテンツ属性ファイル５７のみを特定可能なように生成される識別情報である。すなわち、かかるアルバム識別情報は、例えばクライアント端末２内で、今回コンテンツ提供サーバ７から取得されるコンテンツデータと同じコンテンツデータがすでにＣＤ等からハードディスクにリッピングされている場合でも、そのリッピングしたコンテンツデータではなく、コンテンツ提供サーバ７から取得されるコンテンツデータのみを特定し得るものである。
そしてミドルウェア３１１は、図１９に示すように、かかるアルバム識別情報を、取得処理の経過状況を示す第３の処理経過情報（以下、これを第３のログと呼ぶ）として例えばハードディスクドライブ１０４のハードディスクに一時記憶し、次のステップＳＰ２１４に移る。
ステップＳＰ２１４において、ミドルウェア３１１は、ハードディスクに対し、ステップＳＰ２１３で生成したアルバム識別情報の示す「ａｌｂｕｍ」ディレクトリを新規に作成して、次のステップＳＰ２１５に移る。
ところで上述のステップＳＰ２１１において否定結果が得られると、このことはユーザにより楽曲がアルバム単位及びシングル曲単位の何れで購入要求されたかにかかわらず、ハードディスクに一時記憶したコンテンツデータが、コンテンツ提供サーバ７から最初のダウンロード以降にさらにダウンロードされたコンテンツデータであることを表しており、このときミドルウェア３１１は、ステップＳＰ２１５に移る。
また上述のステップＳＰ２１２において否定結果が得られると、このことは今回ユーザにより１又は複数の楽曲がシングル曲単位で購入要求されたことを表している。
ところでミドルウェア３１１は、複数の楽曲がアルバム単位で購入要求される毎に、ステップＳＰ２１３及びステップＳＰ２１４で上述したように、ハードディスクに対し「ａｌｂｕｍ」ディレクトリを新規に作成する。
しかしながらハードディスクには、シングル曲単位の楽曲のコンテンツデータと、当該コンテンツデータを利用可能にするコンテンツ属性ファイル５７とを管理するためのディレクトリが予め作成され用意されている。
因みにミドルウェア３１１は、図１１について上述した階層的なディレクトリ構成の複数の「ａｌｂｕｍ」ディレクトリのうち、予めいずれかの「ａｌｂｕｍ」ディレクトリをシングル曲単位の楽曲の複数のコンテンツデータ及びコンテンツ属性ファイル５７を一括して管理するためのディレクトリとして使用する。
このためミドルウェア３１１は、ユーザにより１又は複数の楽曲がシングル曲単位で購入要求されたことで、ステップＳＰ２１２において否定結果が得られると、これらシングル曲に対応するコンテンツデータ及びコンテンツ属性ファイル５７を管理するためのディレクトリを特には作成せずに、ステップＳＰ２１５に移る。
ステップＳＰ２１５において、ミドルウェア３１１は、取得使用ファイル３１５の中から、上述のステップＳＰ２０５で選択したコンテンツ取得用アドレスに対応する属性ファイル取得用アドレスを選択する。
そしてミドルウェア３１１は、その選択した属性ファイル取得用アドレスにアクセスし、属性情報提供サーバ８に対してコンテンツ属性ファイル５７のダウンロードを要求する。
ここで属性情報提供サーバ８は、取得使用情報提供サーバ６及びコンテンツ提供サーバ７とデータ提供使用情報を共有することで、クライアント端末２に対して提供するコンテンツデータのコンテンツＩＤや、そのコンテンツデータを利用可能にするコンテンツ属性ファイル５７を取得させるための属性ファイル取得用アドレス等のリストを保持している。
そしてかかるリストには、現在、コンテンツデータと共にコンテンツ属性ファイル５７を取得しようとしているユーザに対する楽曲購入処理を特定可能な購入識別情報が付加されている。またかかるリストには、コンテンツＩＤや属性ファイル取得用アドレス等が楽曲毎に対応付けられ、クライアント端末２に対するコンテンツデータのダウンロードの順番に合わせて記述されている。
さらにそのリストには、１又は複数の属性ファイル取得用アドレスのうち、先頭の属性ファイル取得用アドレス（すなわち、クライアント端末２が取得処理を実行した際に、コンテンツ属性ファイル５７の取得のため最初にアクセスする属性ファイル取得用アドレスである）に対してのみ、その属性ファイル取得用アドレスにクライアント端末２がアクセスしたときだけユーザに対する課金を要求することを示すフラグが付されている。
すなわち、かかる楽曲購入処理手順では、ユーザによりアルバム単位及びシングル曲単位の何れの形態で楽曲が購入要求されても、当該ユーザの使用するクライアント端末２により１つ目のコンテンツ属性ファイル５７がダウンロード要求されたとき、かかるユーザに対し、購入要求された全ての楽曲分の課金処理を一括して行うようにしている。
従ってステップＳＰ２６１において、属性情報提供サーバ８の制御部５０は、クライアント端末２からのコンテンツ属性ファイル５７に対するダウンロード要求に応じて、まず、かかるリストにより、当該クライアント端末２のユーザに対する課金を要求するか否かを判別する。
このステップＳＰ２６１において肯定結果が得られると、このことは現在クライアント端末２がアクセスしている属性ファイル取得用アドレスが、そのクライアント端末２により今回の楽曲購入処理手順で１つ目のコンテンツ属性ファイル５７を取得するために最初にアクセスされた属性ファイル取得用アドレスであることを表しており、このとき、制御部５０は、次のステップＳＰ２６２に移る。
ステップＳＰ２６２において、制御部５０は、リストに付加されていた購入識別情報を格納し、かつ現在、コンテンツ属性ファイル５７をダウンロード要求しているクライアント端末２のユーザに対し、楽曲購入に応じた課金を要求する課金要求データをデータ通信処理部５４を介してポータルサーバ５に送信する。
ステップＳＰ２２７において、ポータルサーバ５の制御部２０は、属性情報提供サーバ８から送信された課金要求データをデータ通信処理部２４を介して受信する。制御部２０は、その課金要求データに格納されている購入識別情報に基づいて、ユーザデータベース２３の中から、現在、楽曲を購入要求しているユーザの個人情報を特定する。
そして制御部２０は、その特定した個人情報に含まれる、現在、楽曲を購入要求したユーザに対する課金ＩＤと、当該購入要求された全ての楽曲に対応するコンテンツＩＤとを格納し、かつ課金サーバ３２０に対し課金処理の実行を依頼する課金処理実行依頼データを生成する。これにより制御部２０は、その課金処理実行依頼データをデータ通信処理部２４を介して課金サーバ３２０に送信する。
ステップＳＰ２３３において課金サーバ３２０の制御部は、ポータルサーバ５から送信された課金処理実行依頼データをデータ通信処理部を介して受信する。そして課金サーバ３２０の制御部は、課金処理実行依頼データに格納されている課金ＩＤ及びコンテンツＩＤに基づいて、今回、楽曲を購入要求したユーザの課金処理に使用する課金情報等の各種情報を特定すると共に、当該特定した課金情報等の各種情報を用いて、そのユーザに対する課金処理を実行する。
その結果、課金サーバ３２０の制御部は、かかる課金処理が完了すると、次のステップＳＰ２３４において、課金ＩＤを格納し、かつ課金処理の完了を通知する課金完了通知データをデータ通信処理部を介してポータルサーバ５に返信する。
ステップＳＰ２２８において、ポータルサーバ５の制御部２０は、課金サーバ３２０から送信された課金完了通知データをデータ通信処理部２４を介して受信する。
制御部２０は、課金完了通知データに格納された課金ＩＤに基づいて、ユーザデータベース２３の中から、ユーザに対する購入識別情報を特定すると共に、その購入識別情報に対応付けて登録していた未課金を示す課金状況通知情報を、当該課金完了通知データにより通知された課金処理の完了を示す課金状況通知情報に更新する。そして制御部２０は、ユーザに対する課金処理が完了したことを示す課金完了データをデータ通信処理部２４を介して属性情報提供サーバ８に送信する。
ステップＳＰ２６３において、属性情報提供サーバ８の制御部５０は、ポータルサーバ５から送信された課金完了データをデータ通信処理部５４を介して受信すると、これに応じて、ユーザに対する課金処理が完了したことを認識する。
そして制御部５０は、ステップＳＰ２１５でクライアント端末２によってアクセスされた属性ファイル取得用アドレスとすでに対応付けているコンテンツＩＤ等に基づいてコンテンツ属性ファイル５７を生成する。これにより制御部５０は、そのコンテンツ属性ファイル５７をデータ通信処理部５４を介してクライアント端末２に送信する。
因みに、上述のステップＳＰ２６１において否定結果が得られると、このことは現在クライアント端末２がアクセスしている属性ファイル取得用アドレスが、そのクライアント端末２により今回の楽曲購入処理手順で２つ目以降のコンテンツ属性ファイル５７を取得するためにアクセスされた属性ファイル取得用アドレスであることを表している。
すなわち、かかる否定結果は、ユーザに対する課金処理がすでに完了していることを表している。従って制御部５０は、このときステップＳＰ２６３に移る。
ステップＳＰ２１６においてクライアント端末２のミドルウェア３１１は、属性情報提供サーバ８から送信されたコンテンツ属性ファイル５７をネットワークインターフェース１１５及び通信処理部１１４を順次介して受信しながら、そのコンテンツ属性ファイル５７に格納されたコンテンツ属性情報を、上述のステップＳＰ２０７で生成した属性情報ファイル名の属性情報ファイルとしてハードディスクに一時記憶して、次のステップＳＰ２１７に移る。
ステップＳＰ２１７において、ミドルウェア３１１は、ユーザによりアルバム単位で楽曲が購入要求されているとき、ハードディスク内に予め構築している取得情報データベースに対して、上述のステップＳＰ２１３で生成したアルバム識別情報を登録する。
またミドルウェア３１１は、取得情報データベースに登録したアルバム識別情報に対し、当該アルバム識別情報の下位階層として、上述のステップＳＰ２１０でダウンロードしたコンテンツデータに対するトラックファイル名と、上述のステップＳＰ２１６でダウンロードしたコンテンツ属性ファイル５７の属性情報ファイル名とを対応付けて当該取得情報データベースに登録する。
因みにミドルウェア３１１は、取得情報データベースに対しアルバム識別情報を一度登録すると、その後は、コンテンツデータ及びコンテンツ属性ファイル５７のダウンロード毎に当該ダウンロードしたコンテンツデータ及びコンテンツ属性ファイル５７のトラックファイル名及び属性情報ファイル名のみを、そのアルバム識別情報に対応付けるようにして取得情報データベースに追加登録する。
これに対してステップＳＰ２１７において、ミドルウェア３１１は、ユーザによりシングル曲単位で楽曲が購入要求されているとき、取得情報データベースに対してすでに登録されているシングル曲管理用のディレクトリ固有の識別情報（以下、これを特にシングル識別情報と呼ぶ）に対し、当該シングル識別情報の下位階層として、上述のステップＳＰ２１０でダウンロードしたコンテンツデータに対するトラックファイル名と、上述のステップＳＰ２１６でダウンロードしたコンテンツ属性ファイル５７の属性情報ファイル名とを対応付けて、かかる取得情報データベースに登録する。
これによりミドルウェア３１１は、コンテンツ提供サーバ７及び属性情報提供サーバ８からダウンロードしたコンテンツデータ及びコンテンツ属性ファイル５７の「ｔｒａｃｋ」ファイル及び属性情報ファイルを、図１１について上述したディレクトリ構造と同様に「ａｌｂｕｍ」ディレクトリ、又はシングル曲管理用のディレクトリで管理可能な状態にし、当該コンテンツデータ及びコンテンツ属性ファイル５７を一時記憶から永続的な記憶状態に切り換える。
その結果、ミドルウェア３１１は、コンテンツ提供サーバ７及び属性情報提供サーバ８からダウンロードしたコンテンツデータ及びこれに対応するコンテンツ属性ファイル５７を、アルバム識別情報、又はシングル識別情報によって特定したうえで、そのコンテンツデータをこれに対応するコンテンツ属性ファイル５７の内容に従い利用可能な状態に変更して、次のステップＳＰ２１８に移る。
ステップＳＰ２１８において、ミドルウェア３１１は、今回購入要求された楽曲のコンテンツデータ及びこれに対応するコンテンツ属性ファイル５７を全てダウンロードしたか否か（すなわち、購入要求された楽曲を全て購入したか否か）を判別する。
このステップＳＰ２１８において否定結果が得られると、このことは今回ユーザにより購入要求された楽曲が複数有り、これら楽曲のコンテンツデータ及びこれに対応するコンテンツ属性ファイル５７を未だ全てダウンロードし終えてはいないことを表しており、このときミドルウェア３１１は、ステップＳＰ２０５に戻る。
これによりミドルウェア３１１は、この後ステップＳＰ２１８において肯定結果を得るまでの間、ステップＳＰ２０５乃至ステップＳＰ２１８の処理を循環的に繰り返すことにより、ユーザによって購入要求された楽曲のコンテンツデータ及びこれに対応するコンテンツ属性ファイル５７を、順次取得使用ファイル３１５の記述内容に従いコンテンツ提供サーバ７及び属性情報提供サーバ８からダウンロードする。
これに対してステップＳＰ２１８において肯定結果が得られると、このことは今回ユーザにより購入要求された楽曲のコンテンツデータ及びこれに対応するコンテンツ属性ファイル５７を全てダウンロードして取得情報データベースに対する登録が完了したことを表しており、このときミドルウェア３１１は、次のステップＳＰ２１９に移る。
ステップＳＰ２１９において、ミドルウェア３１１は、取得処理の実行の間、例えばハードディスクに一時記憶していた第１乃至第３のログを全て消去した後、かかる楽曲の購入要求に応じた取得処理を終了する。
ところでこの実施の形態の場合、かかる他の楽曲購入処理手順では、ポータルサーバ５が、取得使用情報提供サーバ６からコンテンツデータのデータサイズ情報が本体部分に格納された取得使用ファイルを受け取り、これを代理サーバ４経由でクライアント端末２に送信することにより、上述の楽曲購入処理手順の場合と同様に、クライアント端末２に対してコンテンツデータのデータサイズ情報を確実に送信することができる。
なおこの実施の形態の場合、上述した第１乃至第３のログは、クライアント端末２に対する電源供給の停止等により取得処理が中断された後、復帰した際に、当該中断された取得処理ですでにコンテンツ提供サーバ７や属性情報提供サーバ８から取得してハードディスクに記憶していたコンテンツデータ及びコンテンツ属性ファイル５７を消去する際に用いられるものである。
すなわち、クライアント端末２は、取得処理が中断された後、復帰したときには、第１乃至第３のログに従って、当該中断された取得処理の間にすでにコンテンツ提供サーバ７や属性情報提供サーバ８から取得してハードディスクに記憶していたコンテンツデータ及びコンテンツ属性ファイル５７を消去することで、ハードディスクを、その中断された取得処理の開始時点の状態に戻して、購入要求された楽曲に対応するコンテンツデータ及びコンテンツ属性ファイル５７に対するデータ取得を再試行するようになされている。
（３）動作及び効果
以上の構成において、データ配信システム１のクライアント端末２は、ネットワーク３上の属性情報提供サーバ６等の各種サーバと、代理サーバ４を介してＨＴＴＰに準じて通信し、楽曲の購入が要求されると、当該購入要求された楽曲に対応するコンテンツデータの取得に使用する取得使用情報を取得使用情報提供サーバ６に要求する。
取得使用情報提供サーバ６は、クライアント端末２から取得使用情報が要求されると、当該クライアント端末２で取得要求しているコンテンツデータのコンテンツＩＤ及び当該コンテンツデータのデータサイズ情報等を、代理サーバ４を経由した際に取り除かれない取得使用ファイル３５の本体部分に格納して、その取得使用ファイル３５をクライアント端末２に送信する。
これによりクライアント端末２は、取得使用情報提供サーバ６から送信された取得使用ファイル３５を受信すると、当該取得使用ファイル３５の本体部分に格納された、取得対象のコンテンツデータに対応するデータサイズ情報と、そのコンテンツデータを記憶するためのハードディスクの空容量とを比較し、その比較結果に応じて、ハードディスクに取得対象のコンテンツデータを全て記憶することができるか否かを判別する。
その結果、クライアント端末２は、ハードディスクに対して取得対象のコンテンツデータを全て記憶するだけの空容量が存在すると、取得使用ファイル３５の記述内容に従って、コンテンツ提供サーバ７に取得対象のコンテンツデータを要求し、その結果コンテンツ提供サーバ７から送信された取得対処のコンテンツデータを受信してハードディスクに記憶する。
またクライアント端末２は、コンテンツ提供サーバ７から送信された取得対象のコンテンツデータの受信が完了すると、実際に受信したコンテンツデータのデータサイズを、取得使用ファイル３５の本体部分に格納された、当該コンテンツデータに対応するデータサイズ情報の値と比較することで、その比較結果に応じて、取得対象のコンテンツデータをデータサイズ情報通りに正常に受信して当該受信が成功したか否かを判別する。
これによりクライアント端末２は、取得対象のコンテンツデータの受信が成功したときには、引き続き当該コンテンツデータに対応するコンテンツ属性ファイル４７を属性情報提供サーバ８に要求し、その結果、属性情報提供サーバ８から送信されたコンテンツ属性ファイル５７を受信する。
またクライアント端末２は、取得対象のコンテンツデータの受信が失敗したときには、当該コンテンツデータをコンテンツ提供サーバ７に再度要求することで再送させ、そのコンテンツデータの受信を成功させるようにする。
以上の構成によれば、クライアント端末２において、要求されたコンテンツデータの取得に使用する取得使用情報を取得使用情報提供サーバ６に要求し、その要求を受けた取得使用情報提供サーバ６において、当該クライアント端末２で取得要求しているコンテンツデータのコンテンツＩＤ及び当該コンテンツデータのデータサイズ情報を、代理サーバ４を経由した際に取り除かれない本体部分に格納した取得使用ファイル３５をクライアント端末２に送信するようにしたことにより、取得使用情報提供サーバ６からコンテンツデータのデータサイズ情報を送信して代理サーバ４を経由させても、当該代理サーバ４でそのデータサイズ情報が取り除かれることを回避してそのままクライアント端末２に送信することができ、かくしてクライアント端末２でコンテンツデータのデータサイズ情報を確実に受信し得るデータ配信システム１を実現することができる。
またクライアント端末２は、取得使用情報提供サーバ６から送信された取得使用ファイル３５を受信すると、取得対象のコンテンツデータの取得に先立って、当該取得使用ファイル３５の本体部分に格納された、当該取得対象のコンテンツデータの全てのデータサイズ情報と、その取得対象のコンテンツデータを記憶するためのハードディスクの空容量とを比較し、その比較結果に応じてハードディスクに取得対象の全てのコンテンツデータを記憶することができるか否かを判別するようにしたことにより、取得対象のコンテンツデータの受信途中でハードディスクの空容量が不足して当該コンテンツデータの取得が失敗することを未然に防止することができる。
そしてこのようにコンテンツデータの取得に先立って、ハードディスクの空容量を確認しておけば、取得処理を開始して比較的速い時点で取得対象のコンテンツデータに対応する課金処理が完了しているような場合に、当該課金処理が完了しているにもかかわらずに、コンテンツデータの受信途中にハードディスクの空容量が不足してコンテンツデータを取得することができず、その結果、ユーザに損失を与えることを確実に回避することができる。
さらにクライアント端末２は、コンテンツ提供サーバ７に要求したコンテンツデータを受信しても、コンテンツデータの実際に受信したデータサイズを取得使用ファイル３５の本体部分に格納された対応するデータサイズ情報の値と比較し、その比較結果に応じて、コンテンツデータの受信が成功したか否かを判別するようにしたことにより、コンテンツデータの受信が失敗したときには、そのコンテンツデータをコンテンツ提供サーバ７に対して再度要求することでコンテンツデータをほぼ確実に取得させることができる。
（４）他の実施の形態
なお上述した実施の形態においては、クライアント端末２が、取得処理時にハードディスクに対して取得対象のコンテンツデータ全てを記憶する分の空容量がないことを検出したとき、その取得処理を一旦終了するようにした場合について述べたが、本発明はこれに限らず、クライアント端末２が、取得処理時にハードディスクに対して取得対象のコンテンツデータ全てを記憶する分の空容量がないことを検出したとき、ユーザに対してハードディスクから消去すべきコンテンツデータを選択させ、又はＣＰＵ１００により例えばすでに取得しているコンテンツデータのうち記憶した順番や再生回数の少ない順番に従ってハードディスクから消去すべきコンテンツデータを自動的に選択して消去することで、その取得処理を終了させずに継続するようにしても良い。
また上述の実施の形態においては、本発明によるコンテンツ取得装置を図１乃至図１９について上述したクライアント端末２に適用するようにした場合について述べたが、本発明はこれに限らず、パーソナルコンピュータや携帯電話機、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）等の情報処理装置のように、コンテンツデータを取得し得れば、この他種々のコンテンツ取得装置に広く適用することができる。
なお上述の実施の形態においては、ハードウェア回路ブロック及びプログラムモジュールをクライアント端末２に実装したが、これらを携帯電話機やパーソナルコンピュータ等、クライアント端末２以外の種々の端末に実装することで、これらハードウェア回路ブロック及びプログラムモジュールを実装した端末であれば、上述したクライアント端末２と同様の処理を実現することができる。
さらに上述の実施の形態においては、本発明による取得使用情報提供装置を図１乃至図１９について上述したコンピュータ構成の取得使用情報提供サーバ６に適用するようにした場合について述べたが、本発明はこれに限らず、パーソナルコンピュータや携帯電話機、ＰＤＡ等の情報処理装置、またコンピュータ構成のコンテンツ提供サーバ７等のように、コンテンツデータの取得に使用する取得使用情報を提供し得れば、この他種々の取得使用情報提供装置に広く適用することができる。
さらに上述の実施の形態においては、本発明によるコンテンツ取得プログラムを、クライアント端末２のＲＯＭ１０２に予め格納しているＨＴＴＰメッセージプログラム１３０、コミュニケータプログラム１３１、著作権保護管理モジュール１３３、楽曲購入再生モジュール１３５、ＸＭＬブラウザ１３６、ハードディスクコンテンツコントローラ１３７、認証ライブラリ１３８Ａ、データベースアクセスモジュール１３９、コンテンツデータアクセスモジュール１４０からなるプログラムモジュール群に適用し、当該クライアント端末２のＣＰＵ１００がそのコンテンツ取得プログラムに従って図１３及び図１７について上述した楽曲購入処理手順の取得処理を実行するようにした場合について述べたが、本発明はこれに限らず、この他種々の構成のコンテンツ取得プログラムを適用し、当該コンテンツ取得プログラムが格納されたプログラム格納媒体をクライアント端末２にインストールすることにより取得処理を実行するようにしても良い。
さらに上述の実施の形態においては、本発明による取得使用情報提供プログラムを、取得使用情報提供サーバ６のＲＯＭ３１に予め格納している取得使用情報提供プログラムに適用し、当該取得使用情報提供サーバ６の制御部３０がその取得使用情報提供プログラムに従って図１３及び図１７について上述した楽曲購入処理手順の取得使用情報提供処理（ステップＳＰ３１）を実行するようにした場合について述べたが、本発明はこれに限らず、この他種々の構成の取得使用情報提供プログラムを適用し、当該取得使用情報提供プログラムが格納されたプログラム格納媒体を取得使用情報提供サーバ６にインストールすることにより取得使用情報提供処理を実行するようにしても良い。
さらに上述の実施の形態においては、コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信手段として、図１乃至図１９について上述したクライアント端末２のＣＰＵ１００、通信処理部１１４及びネットワークインターフェース１１５を適用するようにした場合について述べたが、本発明はこれに限らず、ファイル要求情報を取得使用情報提供装置に送信するハードウェア回路構成のファイル要求情報送信回路や、無線通信インターフェース等のように、この他種々の属性要求情報送信手段を広く適用することができる。
さらに上述の実施の形態においては、ファイル要求情報の送信に応じて取得使用情報提供装置から送信された、コンテンツデータのコンテンツ識別情報及び属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された取得使用ファイルを当該代理装置を介して受信する情報受信手段として、図１乃至図１９について上述したクライアント端末２のＣＰＵ１００、通信処理部１１４及びネットワークインターフェース１１５を適用するようにした場合について述べたが、本発明はこれに限らず、取得使用ファイルを代理装置を介して受信するハードウェア回路構成の情報受信回路や、無線通信インターフェース等のように、この他種々の属性情報受信手段を広く適用することができる。
さらに上述の実施の形態においては、取得使用ファイル内の取得使用情報に従って、コンテンツデータを要求するコンテンツ要求情報をコンテンツ提供装置に送信するコンテンツ要求情報送信手段として、図１乃至図１９について上述したクライアント端末２のＣＰＵ１００、通信処理部１１４及びネットワークインターフェース１１５を適用するようにした場合について述べたが、本発明はこれに限らず、コンテンツ要求情報をコンテンツ提供装置に送信するハードウェア回路構成のコンテンツ要求情報送信回路や、無線通信インターフェース等のように、この他種々の通知要求情報送信手段を広く適用することができる。
さらに上述の実施の形態においては、コンテンツ要求情報の送信に応じてコンテンツ提供装置から送信されたコンテンツデータを受信するコンテンツ受信手段として、図１乃至図１９について上述したクライアント端末２のＣＰＵ１００、通信処理部１１４及びネットワークインターフェース１１５を適用するようにした場合について述べたが、本発明はこれに限らず、コンテンツデータを受信するハードウェア回路構成のコンテンツ受信回路や、無線通信インターフェース等のように、この他種々の通知情報受信手段を広く適用することができる。
さらに上述の実施の形態においては、取得使用ファイル内のコンテンツデータのデータサイズ情報と、当該コンテンツデータを受信した際に記憶する記憶媒体の空容量とを比較する比較手段として、図１乃至図１９について上述したクライアント端末２においてデータサイズ情報と、ハードディスクドライブ１０４のハードディスクの空容量とを比較するＣＰＵ１００を適用するようにした場合について述べたが、本発明はこれに限らず、取得使用ファイル内のコンテンツデータのデータサイズ情報と、当該コンテンツデータを受信した際に記憶する記憶媒体の空容量とを比較するハードウェア回路構成の比較回路等のように、この他種々の比較手段を広く適用することができる。
さらに上述の実施の形態においては、比較手段による比較結果に応じて、記憶媒体に対してコンテンツデータを記憶するための空容量が不足しているとき、当該空容量の不足を通知する通知手段として、図１乃至図１９について上述したクライアント端末２のＣＰＵ１００、表示処理部１１１及びディスプレイ１０７を適用するようにした場合について述べたが、本発明はこれに限らず、当該空容量の不足を通知するハードウェア回路構成の通知回路や、スピーカや発光素子等のように、この他種々の通知手段を広く適用することができる。
さらに上述の実施の形態においては、コンテンツデータの受信が完了したとき、当該受信の完了したコンテンツデータのデータサイズと、取得使用ファイル内のコンテンツデータのデータサイズ情報とを比較して当該コンテンツデータが正常に受信されたか否かを判別する判別手段として、図１乃至図１９について上述したクライアント端末２のＣＰＵ１００を適用するようにした場合について述べたが、本発明はこれに限らず、コンテンツデータの受信が完了したとき、当該受信の完了したコンテンツデータのデータサイズと、取得使用ファイル内のコンテンツデータのデータサイズ情報とを比較して当該コンテンツデータが正常に受信されたか否かを判別するハードウェア回路構成の判別回路等のように、この他種々の判別手段を広く適用することができる。
さらに上述の実施の形態においては、コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信手段として、図１乃至図１９について上述した取得使用情報提供サーバ６の制御部３０及びデータ通信処理部３４を適用するようにした場合について述べたが、本発明はこれに限らず、ファイル要求情報を受信するハードウェア回路構成の要求情報受信回路や、無線通信インターフェース等のように、この他種々の要求情報受信手段を広く適用することができる。
さらに上述の実施の形態においては、要求情報受信手段により受信したファイル要求情報に応じてコンテンツデータのコンテンツ識別情報及び属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した取得使用ファイルを当該代理装置を介してコンテンツ取得装置に送信する情報送信手段として、図１乃至図１９について上述した取得使用情報提供サーバ６の制御部３０及びデータ通信処理部３４を適用するようにした場合について述べたが、本発明はこれに限らず、取得使用ファイルを当該代理装置を介してコンテンツ取得装置に送信するハードウェア回路構成の情報送信回路や、制御部及び無線通信インターフェース等のように、この他種々の情報送信手段を広く適用することができる。

本発明は、インターネットや無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介して通信接続されたパーソナルコンピュータ及びコンピュータ構成の取得使用情報提供サーバ等から構築されたデータ配信システムに利用することができる。

Claims (18)

1. コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信ステップと、
   上記ファイル要求情報の送信に応じて上記取得使用情報提供装置から送信された、上記コンテンツデータのコンテンツ識別情報及び上記属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された上記取得使用ファイルを当該代理装置を介して受信する情報受信ステップと、
   上記取得使用ファイル内の上記取得使用情報に従って、上記コンテンツデータを要求するコンテンツ要求情報をコンテンツ提供装置に送信するコンテンツ要求情報送信ステップと、
   上記コンテンツ要求情報の送信に応じて上記コンテンツ提供装置から送信された上記コンテンツデータを受信するコンテンツ受信ステップと
   を具えることを特徴とするコンテンツ取得方法。
2. 上記コンテンツデータに対応する上記属性情報は、当該コンテンツデータのデータサイズ情報でなる
   ことを特徴とする請求の範囲第１項に記載のコンテンツ取得方法。
3. 上記取得使用ファイル内の上記コンテンツデータの上記データサイズ情報と、当該コンテンツデータを受信した際に記憶する記憶媒体の空容量とを比較する比較ステップと、
   上記比較ステップによる上記比較結果に応じて、上記記憶媒体に対して上記コンテンツデータを記憶するための上記空容量が不足しているとき、当該空容量の不足を通知する通知ステップと
   を具えることを特徴とする請求の範囲第２項に記載のコンテンツ取得方法。
4. 上記コンテンツデータの受信が完了したとき、当該受信の完了した上記コンテンツデータのデータサイズと、上記取得使用ファイル内の上記コンテンツデータの上記データサイズ情報とを比較して当該コンテンツデータが正常に受信されたか否かを判別する判別ステップ
   を具えることを特徴とする請求の範囲第２項に記載のコンテンツ取得方法。
5. 上記情報受信ステップでは、
   上記取得使用情報提供装置から、上記コンテンツ識別情報及び上記コンテンツデータの上記データサイズ情報とが上記取得使用ファイルの本体部分に格納され、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準じて送信された当該取得使用ファイルを受信する
   ことを特徴とする請求の範囲第２項に記載のコンテンツ取得方法。
6. コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信ステップと、
   上記受信した上記ファイル要求情報に応じて上記コンテンツデータのコンテンツ識別情報及び上記属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した上記取得使用ファイルを当該代理装置を介して上記コンテンツ取得装置に送信する情報送信ステップと
   を具えることを特徴とする取得使用情報提供方法。
7. 上記コンテンツデータに対応する上記属性情報は、当該コンテンツデータのデータサイズ情報でなる
   ことを特徴とする請求の範囲第６項に記載の取得使用情報提供方法。
8. 上記情報送信ステップでは、
   上記コンテンツ識別情報及び上記コンテンツデータの上記データサイズ情報とを本体部分に格納した上記取得使用ファイルをＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準じて送信する
   ことを特徴とする請求の範囲第７項に記載の取得使用情報提供方法。
9. 上記コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信手段と、
   上記ファイル要求情報の送信に応じて上記取得使用情報提供装置から送信された、上記コンテンツデータのコンテンツ識別情報及び上記属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された上記取得使用ファイルを当該代理装置を介して受信する情報受信手段と、
   上記取得使用ファイル内の上記取得使用情報に従って、上記コンテンツデータを要求するコンテンツ要求情報を上記コンテンツ提供装置に送信するコンテンツ要求情報送信手段と、
   上記コンテンツ要求情報の送信に応じて上記コンテンツ提供装置から送信された上記コンテンツデータを受信するコンテンツ受信手段と
   を具えることを特徴とするコンテンツ取得装置。
10. 上記コンテンツデータに対応する上記属性情報は、当該コンテンツデータのデータサイズ情報でなる
    ことを特徴とする請求の範囲第９項に記載のコンテンツ取得装置。
11. 上記取得使用ファイル内の上記コンテンツデータの上記データサイズ情報と、当該コンテンツデータを受信した際に記憶する記憶媒体の空容量とを比較する比較手段と、
    上記比較手段による上記比較結果に応じて、上記記憶媒体に対して上記コンテンツデータを記憶するための上記空容量が不足しているとき、当該空容量の不足を通知する通知手段と
    を具えることを特徴とする請求の範囲第１０項に記載のコンテンツ取得装置。
12. 上記コンテンツデータの受信が完了したとき、当該受信の完了した上記コンテンツデータのデータサイズと、上記取得使用ファイル内の上記コンテンツデータの上記データサイズ情報とを比較して当該コンテンツデータが正常に受信されたか否かを判別する判別手段
    を具えることを特徴とする請求の範囲第１０項に記載のコンテンツ取得装置。
13. 上記情報受信手段は、
    上記取得使用情報提供装置から、上記コンテンツ識別情報及び上記コンテンツデータの上記データサイズ情報とが上記取得使用ファイルの本体部分に格納され、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準じて送信された当該取得使用ファイルを受信する
    ことを特徴とする請求の範囲第１０項に記載のコンテンツ取得装置。
14. コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信手段と、
    上記要求情報受信手段により受信された上記ファイル要求情報に応じて上記コンテンツデータのコンテンツ識別情報及び上記属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した上記取得使用ファイルを当該代理装置を介して上記コンテンツ取得装置に送信する情報送信手段と
    を具えることを特徴とする取得使用情報提供装置。
15. 上記コンテンツデータに対応する上記属性情報は、当該コンテンツデータのデータサイズ情報でなる
    ことを特徴とする請求の範囲第１４項に記載の取得使用情報提供装置。
16. 上記情報送信手段は、
    上記コンテンツ識別情報及び上記コンテンツデータの上記データサイズ情報とを本体部分に格納した上記取得使用ファイルをＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準じて送信する
    ことを特徴とする請求の範囲第１４項に記載の取得使用情報提供装置。
17. 情報処理装置に対して、
    コンテンツデータの要求に応じて、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を取得使用情報提供装置に送信するファイル要求情報送信ステップと、
    上記ファイル要求情報の送信に応じて上記取得使用情報提供装置から送信された、上記コンテンツデータのコンテンツ識別情報及び上記属性情報が、コンテンツ取得側の一部機能を代理する代理装置を経由した際に取り除かれない部分に格納された上記取得使用ファイルを当該代理装置を介して受信する情報受信ステップと、
    上記取得使用ファイル内の上記取得使用情報に従って、上記コンテンツデータを要求するコンテンツ要求情報をコンテンツ提供装置に送信するコンテンツ要求情報送信ステップと、
    上記コンテンツ要求情報の送信に応じて上記コンテンツ提供装置から送信された上記コンテンツデータを受信するコンテンツ受信ステップと
    を実行させるためのコンテンツ取得プログラム。
18. 情報処理装置に対して、
    コンテンツ取得装置からコンテンツデータの要求に応じて送信された、当該コンテンツデータの属性情報を含む取得使用情報を格納した取得使用ファイルを要求するファイル要求情報を受信する要求情報受信ステップと、
    上記受信した上記ファイル要求情報に応じて上記コンテンツデータのコンテンツ識別情報及び上記属性情報を、コンテンツ取得側の一部機能を代理する代理装置を経由させた際に取り除かれない部分に格納した上記取得使用ファイルを当該代理装置を介して上記コンテンツ取得装置に送信する情報送信ステップと
    を実行させるための取得使用情報提供プログラム。

Images