JP2010056816A

JP2010056816A - 配信システム

Info

Publication number: JP2010056816A
Application number: JP2008218967A
Authority: JP
Inventors: Hiroyuki Koreeda; 浩行是枝; Satoru Mio; 識三尾
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2008-08-28
Filing date: 2008-08-28
Publication date: 2010-03-11

Abstract

【課題】サーバとダウンロード端末からなる、ネットワークを介したダウンロード配信システムにおいて、サーバに対する不正なダウンロード端末のアクセスを抑止したり、サーバへのアクセス攻撃を防止したりことが、必要である。
【解決手段】そこで、ダウンロード端末が、サーバに対し、コンテンツや関連するメタデータを要求する際、ダウンロード制御情報に記述されたコンテンツ識別情報や、端末識別子を通知し、サーバ側でコンテンツ識別情報や、端末識別子の正当性をチェックし、正当な端末のみに要求されたデータを返すことにより、不正なダウンロード端末のアクセスを抑止することができる。
【選択図】図５

Description

技術分野は、データやプログラム等のコンテンツを配信するサーバと、ネットワークを介し、サーバからコンテンツをダウンロードする端末からなるシステムに関する。

特許文献１には、「ネットワークを介してコンテ
ンツを効率的に配信できるようにする」（特許文献１［００１０］参照）ことを課題とし、その解決手段として例えば「ネットワークを介してコンテンツ配信装置からコンテンツ処理装置にコンテンツを配信するコンテンツ配信システムにおいて、コンテンツ処理装置は、ユーザが指定するコンテンツのダウンロードに必要な情報が記述される制御ファイルを、ネットワークを介してコンテンツ配信装置から取得し、制御ファイルに記述された情報に基づいて、コンテンツ処理装置へのコンテンツのダウンロード可否を表す情報を取得し、制御ファイルに記述された情報に基づいて、コンテンツ配信装置からコンテンツのライセンスを特定する情報を取得し、ライセンスを特定する情報に基づいて、コンテンツ配信装置からコンテンツのライセンスを取得し、制御ファイルに記述された情報に基づいて、コンテンツ配信装置からコンテンツを構成するファイルをダウンロードする」（特許文献１［００１１］参照）ことが記載されている。
特開２００５−１５９７０３号公報

特許文献１の実施例においては、インターネットブラウザが、コンテンツダウンロードの実行内容を記述したダウンロード制御ファイル（本発明では、ダウンロード制御メタファイルと呼ぶ）をサーバから取得し、このファイルを、ダウンロードエージェントが解釈し、ダウンロードを実行する例が示されている。

インターネットブラウザは、サーバとの通信において、SSLやTLSといった規格に基づくセキュア通信の規格が普及しており、これらの技術を用いることで、サーバ、インターネットブラウザ間の通信路のセキュリティを担保することが一般的に行われている。

このように、特許文献１では、ダウンロード端末において、実際にコンテンツをダウンロードしたり、関係するメタデータを取得したりするのは、インターネットブラウザではなく、ダウンロードエージェント（本特許では、ダウンローダと呼ぶものとする）と呼ばれる組み込みプログラムである。

このような組み込みプログラムであるダウンローダが直接インターネットを介してデータ通信を行う場合も、インターネットブラウザと同様、通信路のセキュリティの確保が問題になる。

特に、ダウンロード配信システムにおいて認められていない不正なダウンロード端末から、サーバ上のメタデータやコンテンツを取得されたり、あるいは、配信システムの停止をもくろむ集中的なサーバアクセスによる攻撃などが行われたりするのを、防止する必要がある。

しかし、ダウンローダのような組み込みプログラムにおいて、一般的に、SSLやTLS等のセキュア通信のシステムや、それに用いられるルート証明書の更新、管理機能を組み込むことは実装上の負荷が重い。また、映像などのコンテンツファイル本体のようにファイルサイズが大きなデータの通信に対し、セキュア通信を行うことは、サーバ側、端末側の両方に暗号化、復号化のために重い負荷をかけることになり、システムの実装コストに大きな影響が出る。

前述の課題を解決するために、本発明の一実施の態様は、ダウンロード端末は、ネットワーク上でダウンロード端末を識別する端末識別情報を記憶する端末識別情報記憶部と、コンテンツをネットワーク上で識別するコンテンツ識別情報を含むダウンロード制御情報を前記サーバから取得するダウンロード制御情報取得部と、前記ダウンロード制御情報に基づき前記コンテンツの取得を前記サーバに要求する際、前記端末識別情報及び／又は前記コンテンツ識別情報を通知するデータ取得要求処理部とを有し、サーバは、前記ダウンロード端末からのコンテンツの取得要求に対し、通知された端末識別情報及び／又はコンテンツ識別情報の正当性をチェックし、正当なダウンロード端末からの要求に対して要求された情報を返す配信処理部を有するように構成する。

前記手段によれば、不正な端末によるサーバアクセスや要求を抑止できる。また、不正アクセスの解析に役立てることができる。

以下、実施例について図面を引用しつつ説明する。ただし本発明は本実施例に限定されるものではない。

図１は、ダウンロード端末400と、関係するシステムとの関係を示す。ダウンロード端末400においては、CPU420が、メモリ430やHDD450に格納されたプログラムを実行することで、各種の処理を行う。ダウンロード端末400は、例えばネットワークに接続して記録機能を有するテレビ、レコーダ、パーソナルコンピュータ等である。

ダウンロード端末400は、リアルタイムクロック（RTC）460を持ち、常に実時間を保持し、前記プログラムから参照することができる。そして、設定された日時にCPU420にプログラムを実行させるタイマー機能を持っている。

また、ハードディスクインタフェース(HDD I/F)440を介して、ハードディスクドライブ(HDD)が接続されており、前記プログラムは、大容量のデータの読み書き処理を行うことができる。

また、ネットワークインタフェース(LAN I/F)410を介し、ルータ（ゲートウェイ等であってもよい。総称して中継装置ともいう）310に接続され、インターネット300に接続される。インターネットを介してアクセスするサーバには、Webサーバ100とファイルサーバ200がある。

Webサーバ100は、ダウンロード端末400が持つWebブラウザ機能で表示を行うために参照するWebページ110と、ダウンロード端末400が様々なコンテンツをダウンロードするのに必要な制御情報を記述したダウンロード制御メタファイル120を保持する。ダウンロード端末400のようなハードウェア構成も備えており、例えばCPUが、メモリ上のプログラムを実行することで、各種の処理を行う。

ファイルサーバ200には、ダウンロードするコンテンツ210のデータ本体やコンテンツ210の属性を記述したり、再生に必要な制御情報を記述したメタデータ220が置かれる。ダウンロード端末400のようなハードウェア構成も備えており、例えばCPUが、メモリ上のプログラムを実行することで、各種の処理を行う。

ダウンロード端末400からファイルサーバ200に、コンテンツの取得要求されると、インターネットを介してコンテンツのデータが配信され、それをHDD I/F440を介して、HDDに記録することでダウンロードが完了する。

より詳細な運用例としては例えば、まずサービスプロバイダでダウンロード端末400（又はユーザ）のＩＤの認証が実行された後にWebサーバ100でHTMLのWebページを取得する。そのWebページを用いてパッケージ（コンテンツ）の購入処理を実行するとパッケージ（コンテンツ）のＩＤとダウンロード端末（又はユーザ）のＩＤを顧客管理の課金サーバに送って課金する。課金が完了すると、ダウンロード制御メタファイルをWebサーバ100からダウンロード端末400にダウンロードする。このダウンロード制御メタファイルに従って、ファイルサーバ200からパッケージ（コンテンツ）をダウンロードする。ダウンロードしたパッケージ（コンテンツ）を再生するときには、再生制御メタデータやDRMの鍵データやコンテンツメタデータを必要に応じて取得する。

なお、ダウンロード端末400とサーバ100及び200のようにダウンロードを制御する装置を総称して、ダウンロード制御装置とも呼ぶ。

図2は、ダウンロード制御メタファイル120の構成例を示す。ダウンロード制御メタファイル120は、メタファイル自身の内容を記述したダウンロード制御情報130と、一つ又は複数のコンテンツをダウンロードするのに用いるダウンロード実行情報140を含む。

このダウンロード制御メタファイル120は、例えばRSS（Rich Site Summary、RDF（Resource Description Framework） Site Summary、Really Simple Syndication）で記述される。ダウンロード制御メタファイルは、あるパッケージ内の任意の複数コンテンツに対し作成（用意）可能であるが、複数のパッケージは跨がない。また、あるパッケージに対して複数用意することも可能である。ただし、パッケージ内の全コンテンツがダウンロードできるように用意する。ダウンロード制御メタファイル120は更新されることがあり、受信機は一定周期でチェックし、差分を更新する。なお、RSSの場合にはenclosure urlで各コンテンツを識別する。

ダウンロード制御情報130には、対応するダウンロード制御メタファイル１２０の名称（例えばダウンロード予約の名称、ファイル名、ID等）を示すダウンロード制御メタファイルの名称131、対応するダウンロード制御メタファイル１２０の所在（例えば、ダウンロード予約を提供するウェブサイトのインターネット上のURL。URLに限らないアドレスであってもよい、以下所在について同様。）を示すダウンロード制御メタファイルの所在132、対応するダウンロード制御メタファイル１２０の説明（例えばダウンロード予約についての説明や言語タイプ等）を示すダウンロード制御メタファイルの説明文133、更新チェックフラグ134、更新期限日時135などの情報を持つ。

更新チェックフラグ134は、Webサーバ100上のダウンロード制御メタファイル120の内容が変更されていないか、周期的にチェックを行うかどうかを判別するフラグであり、チェックを行う「更新」と、最初に取得した後は、周期的にチェックを行わない「単発」の値をとる。更新期限日時135は、更新チェックフラグ134が「更新」の場合に有効で、ダウンロード制御メタファイル120の更新をチェックし続ける期限の日時を記載する。

更新期限日時135は、コンテンツの更新を監視する期限を示す。期限の単位（日単位、時単位、分単位等）は任意である。「期限なし」すなわち半永久的にチェックをし続けることを示す値を取ることも可能である。

また、別の実施例として、更新期限日時135の特殊な値（例えばすべて0）を更新チェックフラグ134の「単発」を示す値として扱うことにより、更新チェックフラグ134を省略する構成も実現可能である。

ダウンロード実行情報140は、ダウンロード制御メタファイル120に複数記述可能である。ダウンロードする各々のコンテンツについて、そのコンテンツのタイトル（番組名等であってもよいし、ファイル名やＩＤであってもよい）を示す配信コンテンツのタイトル141、そのコンテンツの説明（特徴や備考等）を示す配信コンテンツの説明文142、そのコンテンツを配信する日時（日単位、分単位であっても良い）を示す配信日時143、そのコンテンツをインターネット上で一意に識別する配信コンテンツのコンテンツ識別子(CRID)144、配信コンテンツの種別145、そのコンテンツに対応するメタデータの所在を示す配信コンテンツ用メタデータの所在146、配信コンテンツのサイズ147などの情報を格納する。

コンテンツ識別子144は、例えばCRID://というスキーマで規定される文字列で記述され、authorityの部分がコンテンツの配信者をネットワーク上で唯一に識別するキーワードで、本実施例では、インターネット上で唯一の名称として管理されるドメインネームをauthorityとして運用する。authority/の後のcontent_idは、authority内でコンテンツを一意に識別するIDで、文字列の形式はauthorityで自由に運用してよい。このような運用により、インターネット上のコンテンツを、コンテンツ識別子144で一意に識別することが可能になり、コンテンツ識別子144をインターネット上のURLとしてアクセスすることにより、対象のコンテンツや関係するメタデータを取得することが可能になる。

配信日時143は、通常、コンテンツがファイルサーバ200に格納され、公開された日時を記載するが、ダウンロード制御メタファイル120が配信されたときには、コンテンツがまだ公開されず、配信日時143には配信予定の未来の日時が記載される場合もある。また、一度、配信されたコンテンツの内容が更新された場合、配信日時143には、更新された日時を記載する場合もある。

配信コンテンツのファイル種別145は、例えばサーバから配信される映像、写真、音楽、プログラム、マルチメディアデータなどの種別を記載する。映像の中で更に細分化して、映画、ニュース、スポーツ等、音楽の中で更に細分化してクラシック、ロック、ジャズ等の種別を記載してもよい。

配信コンテンツ用メタデータとは、コンテンツの再生や実行に必要な付属情報のことで、一例としてはコンテンツ検索用のジャンルやキーワード情報、コンテンツが映像情報であれば、そのサムネイルやチャプタ情報などがある。

なお、ダウンロード制御メタファイル120、ダウンロード制御情報130、ダウンロード実行情報140の全部又は一部をダウンロード制御データとも呼ぶ。

図3は、ダウンロード制御メタファイル120を、ダウンロード端末400が取得する手順の例を示す。

ダウンロード端末400で実行されるWebブラウザ500のプログラム（以下、単にWebブラウザ500ともいう）は、Webサーバ100に対し、Webページの取得要求を行い、取得したWebページを表示する。図3では、まずWebページa 111（例えばパック、映画、番組、楽曲等のコンテンツのタイトルを表示する画面データや、HTMLを含む）を表示し、このコンテンツをユーザがリモコン等の操作デバイスで操作し、「購入する」のボタンを選択すると、Webページa 111において、「購入する」ボタンにリンク記述されたWebページb 112を取得し、表示する。図３の例では、Webページa 111として、パックのタイトル「柏ＦＣ’０６パック」と、金額「3000円」と、メッセージ「柏FCの06年度全試合をご覧いただけます」と、条件「期限なし」「コピー３回」と、ボタン「購入する」「戻る」とを表示する画面を示している。また、Webページb 112として、番組のタイトル「柏ＦＣ’０６パック」と、このパックのうちダウンロードするコンテンツを選択するボタン（例えば「全部」を選択するとパックに含まれる全てのコンテンツがダウンロードされ、「６月」を選択すると６月分のコンテンツがダウンロードされる）を標示する画面を示している。このＷｅｂページにおいて、一つ一つのダウンロードボタンに対して、それぞれダウンロードするコンテンツについて記述したダウンロード制御メタファイル120が用意され、リンクされている。

このWebページb 112において、ユーザが「ダウンロード」ボタンを選択すると、Ｗｅｂブラウザ500は、「ダウンロード」ボタンにリンク記述されたダウンロード制御メタファイル120を、Ｗｅｂサーバ100に取得要求する。Webブラウザ500は、ダウンロード制御メタファイル120を取得すると、そのデータをダウンローダ550（ダウンロード端末400で実行されるダウンローダ550のプログラム）に渡す。

ダウンローダ550は、ブラウザとは独立したコンテキストで、ダウンロード処理を実行する(560)。

図4は、ダウンローダ550が管理するデータベースの構成例を示す。

ダウンローダ管理情報800は、ダウンローダ550が、ダウンロード制御メタファイル120の更新をチェックするタイミングを管理する情報である。チェック周期情報810は例えばユーザが設定する所定のチェック周期時間である。前回チェック日時820は、周期的にチェックする際、前回チェックを行った日時情報である。次回チェック予定日時830は、前回チェック日時820に、チェック周期情報810を加算して求めた日時であり、この値をRTC460のタイマーに設定することで、次回チェック予定日時830にダウンロード制御メタファイル120の更新をチェックすることができる。

ダウンロード予約管理テーブル850は、図3のWebページb 112で指示したダウンロード制御メタファイル120に対応するダウンロード予約を管理するテーブルである。ダウンロード予約の名称851、ダウンロード予約の所在852、ダウンロード予約の説明文853、更新チェックフラグ854、更新期限日時855にはそれぞれ、インポートされた図2のダウンロード制御情報130のダウンロード制御メタファイルの名称131、ダウンロード制御メタファイルの所在132、ダウンロード制御メタファイルの説明文133、更新チェックフラグ134、更新期限日時135を格納する。

ダウンロード実行管理テーブル870は、各々のコンテンツについて、ダウンロードの実行状況を管理するテーブルである。配信コンテンツのタイトル871、配信コンテンツの説明文872、配信日時873、コンテンツ識別子874、配信コンテンツの種別875、配信コンテンツ用メタデータの所在876、配信コンテンツのサイズ877にはそれぞれ、インポートされた図2のダウンロード制御メタファイル120のダウンロード実行情報140の配信コンテンツのタイトル141、配信コンテンツの説明文142、配信日時143、コンテンツ識別子144、配信コンテンツの種別145、配信コンテンツ用メタデータの所在146、配信コンテンツのサイズ147を格納する。

ダウンロード実行状態878は、「未実行」「ダウンロード中」「ダウンロード済」「中断状態」などの値を持ち、ダウンローダ550が、ダウンロードの実行状態を管理するために利用する。ダウンロード進捗情報879は、ダウンロードの進捗度合いを管理するために利用するための情報で、例としてダウンロードが済んだコンテンツのサイズを逐次格納する。この場合、配信コンテンツのサイズ877との比を求めることで、ダウンロードの進捗度合いをユーザに例えば％で表示することができる。このとき、ダウンロード実行状態878が「未実行」の場合、ダウンロード進捗情報879の値は0であり、「ダウンロード済」の場合は、ダウンロード進捗情報879の値＝配信コンテンツのサイズ877に設定するものとする。

このダウンロード実行管理テーブル870は、ダウンロードの管理が可能なコンテンツ数（M個）用意される。

ダウンロード予約管理テーブル850のダウンロード実行管理テーブルポインタ（856〜857）には、ダウンロード実行管理テーブル870の所在（HDD450内でのアドレス又はメモリ430のアドレス等）を格納する。Nは、インポート可能なダウンロード実行情報140の数であり、システム設計により異なる。

ダウンロード実行順序テーブル900は、ダウンローダ550が、ダウンロードを実行する優先度を管理するテーブルである。ダウンロード実行管理テーブル870へのM個のポインタ910の配列を含む。配列は、例えば実行順とする。

端末ID840は、ネットワーク上で、ダウンロード端末を一意に識別可能なIDであり、製品出荷時にダウンロード端末400に書き込まれ、端末内のWebブラウザ500やダウンローダ550等のアプリケーションプログラムで参照し、処理に利用することができる。
なお、端末ID840は、本実施例のダウンロード配信システムで利用できる正当な端末であることを保障する識別子であり、そのため、ユーザはその値を参照したり、改変することはできない。また、ダウンロード端末400では、万が一、端末ID840が不正に書き換えられた場合、不正な書き換えを検出する機能を設け、端末ID840を使用不可にする。

図5は、ダウンローダ550において実行される図3のダウンロード処理560の例を詳細に示したものである。

ダウンロード処理は、サーバから取得したダウンロード制御メタファイル120を解析して(570)、記述内容に従い処理を行う。

まずコンテンツに関わるメタデータ220を、ファイルサーバ200に取得要求する。この際、要求パラメータの一実施例として、コンテンツ識別子（CRID）144や、端末ID840をファイルサーバ200に通知することが考えられる。また、コンテンツ識別子（CRID）144や、端末ID840は、そのままの値を通知するのではなく、あらかじめ定めた方式に基づいてダウンロード端末400が暗号化して通知し、ファイルサーバ200は、そのデータを復号化した上で処理をする実施例も考えられる。

ファイルサーバ200では、メタファイルの取得要求を受け取ると、パラメータで渡されたコンテンツ識別子（CRID）144が、ダウンロード制御メタファイル120に記述された値であるかどうかをチェックし、端末ID840が、規定された書式に従い、しかも、サーバ側で管理している不正なIDリストに記録されているIDでないかどうかをチェックする(1400)。

コンテンツ識別子（CRID）144、又は、端末ID840に異常があれば、メタデータをダウンロード端末400に返さず、エラーコードを返す(1410)。これに対し、ダウンロード端末400は、エラー処理575を実行して、ダウンロードを中断する(575)。コンテンツ識別子（CRID）144、又は、端末ID840に異常がなければ(1410)、要求されたメタデータをダウンロード端末400に返し、ダウンロード端末400は、そのメタデータをHDD450に格納する(580)。

続いて、ダウンロード端末400は、コンテンツ210の取得要求をファイルサーバ200に行う。この際も、コンテンツ識別子（CRID）144や、端末ID840をファイルサーバ200に通知する。また、コンテンツ識別子（CRID）144や、端末ID840は、そのままの値を通知するのではなく、あらかじめ定めた方式に基づいてダウンロード端末4400が暗号化して通知し、ファイルサーバ200は、そのデータを復号化した上で処理をする実施例も考えられる。

ファイルサーバ200では、コンテンツの取得要求を受け取ると、パラメータで渡されたコンテンツ識別子（CRID）144が、ダウンロード制御メタファイル120に記述された値であるかどうかをチェックし、端末ID840が、規定された書式に従い、しかも、サーバ側で管理している不正なIDリストに記録されているIDでないかどうかをチェックする(1420)。

コンテンツ識別子（CRID）144、又は、端末ID840に異常があれば、コンテンツをダウンロード端末400に返さず、エラーコードを返す(1430)。これに対し、ダウンロード端末400は、エラー処理575を実行して、ダウンロードを中断する(585)。コンテンツ識別子（CRID）144、又は、端末ID840に異常がなければ(1430)、要求されたメタデータをダウンロード端末400に返し、ダウンロード端末400は、そのメタデータをHDD450に格納し終えると(590)、ダウンロード処理(560)は完了する。

別の実施例として、Webブラウザ500上で、コンテンツのダウンロードを指示した際、Webサーバ100側で、ダウンロードを指示した端末の端末ID840とその端末がダウンロード指示したコンテンツのコンテンツ識別子144との関係を記憶しておき、ステップ1400、1420において、ダウンロード端末400から通知された端末ID840とコンテンツ識別子144が、Webブラウザ500で支持された関係と一致しているかどうかをチェックする手段が考えられる。この実施例の場合、ダウンロード端末400の正当性を、さらに強固にチェックすることができる。

本実施例によれば、コンテンツ識別子144は、ネットワーク上で一意に識別される情報であり、これに基づきコンテンツやメタデータを要求することにより、コンテンツやメタデータの配信サーバは、正当なダウンロード端末の要求に対し、コンテンツやメタデータを配信することができ、不正なダウンロード端末からのアクセスを抑止することができる。

また、不正なダウンロード端末によるサーバ攻撃を抑止し、サーバのシステムダウン等の問題を防止できる。さらに、サーバ側でアクセスログを保持することにより、不正アクセスの可能性についての検証の際、検証の一助とすることができる。

ダウンロード端末及びシステムの構成例を示すブロック図ダウンロード制御メタデータの構成例を示すデータ図 Webサーバとダウンロード端末との処理シーケンスの例を示すフロー図ダウンローダ管理情報の構成例を示すデータ図ダウンロード処理の例を示すフロー図

符号の説明

１２０：ダウンロード制御メタファイル
１３４：更新チェックフラグ
１３５：更新期限日時
２１０：コンテンツ
４００：ダウンロード端末
４５０：ハードディスクドライブ
４６０：リアルタイムクロック
５００：Ｗｅｂブラウザ
５５０：ダウンローダ
５６０：ダウンロード処理

Claims

コンテンツのダウンロードを制御するダウンロード端末と、
コンテンツ及び当該コンテンツのダウンロードの実行を制御するダウンロード制御情報を配信するサーバからなる配信システムであって、
前記ダウンロード端末は、ネットワーク上でダウンロード端末を識別する端末識別情報を記憶する端末識別情報記憶部と、コンテンツをネットワーク上で識別するコンテンツ識別情報を含むダウンロード制御情報を前記サーバから取得するダウンロード制御情報取得部と、前記ダウンロード制御情報に基づき前記コンテンツの取得を前記サーバに要求する際、前記端末識別情報及び／又は前記コンテンツ識別情報を通知するデータ取得要求処理部とを有し、
前記サーバは、前記ダウンロード端末からのコンテンツの取得要求に対し、通知された端末識別情報及び／又はコンテンツ識別情報の正当性をチェックし、正当なダウンロード端末からの要求に対して要求された情報を返す配信処理部を有する配信システム。
請求項１の配信システムにおいて、
前記データ取得要求処理部は、前記端末識別情報、前記コンテンツ識別情報を暗号化して通知し、
前記サーバは前記暗号化された端末識別情報、前記コンテンツ識別情報を復号化してからコンテンツ識別情報の正当性をチェックする配信システム。
請求項１又は請求項２の配信システムにおいて、
前期配信処理部は、前記端末識別情報が正当な書式に従ったデータであるかどうかをチェックする配信システム。
請求項１又は請求項２の配信システムにおいて、
前期配信処理部は、前記端末識別情報が既に発行された端末識別情報かどうかをチェックする配信システム。
請求項１又は請求項２の配信システムにおいて
前期配信処理部において、前記端末識別情報が既に不正使用が判別した端末識別情報のリストに含まれているかどうかをチェックし、含まれていない場合に、要求された情報を返すダウンロード端末の認証方式。
請求項１又は請求項２の配信システムにおいて、
前期配信処理部は、前記コンテンツ識別情報が正当な書式に従ったデータであるかどうかをチェックする配信システム。
請求項１又は請求項２の配信システムにおいて、
前期配信処理部は、前記コンテンツ識別情報が既に発行されたデータであるかどうかをチェックする配信システム。
請求項１又は請求項２の配信システムにおいて、
前期配信処理部は、前記コンテンツ識別情報が既に不正アクセスが発生しているコンテンツのコンテンツ識別情報リストに含まれているかどうかをチェックし、含まれていない場合に、要求された情報を返す配信システム。
請求項１又は請求項２の配信システムにおいて、
前期ダウンロード制御情報取得部は、ダウンロード制御情報取得要求時に前記サーバに対し前記端末識別情報を通知し、
前期配信処理部は、ダウンロード制御情報取得要求に対し、取得要求されたコンテンツのコンテンツ識別情報と要求元の端末識別情報の関連情報を記憶し、コンテンツの取得要求に対し、通知された端末識別情報、コンテンツ識別情報が、前記関係情報と一致することをチェックし、一致した場合のみ、要求された情報を返す配信システム。