JP2007228558A - ファイル配信システム及びファイル配信方法 - Google Patents

Abstract

【課題】ファイル配信者が利益を損なわず安価にファイルを配信することが可能なファイル配信システム及びファイル配信方法を提供する。
【解決手段】Ｐ２Ｐ通信方式によるファイル配信システムにおいて、サーバが、クライアント装置からファイルの要求を受けると、要求先のクライアント装置以外のクライアント装置へファイルを配信する。このとき、サーバより転送経路を設定された、ファイルの要求先以外のクライアント装置が、要求先のクライアント装置へとファイルを暗号化して順次転送する。ファイルを受信した要求先のクライアント装置は、サーバに対してファイルの到着を通知してファイルの対価を支払い、復号化鍵を受け取る。そしてこの時点で、ファイルの転送に加わった各クライアント装置は、報酬を受け取る権利を得る。
【選択図】図１

Description

本発明は、デジタルファイルの流通に係るファイル配信システム及びファイル配信方法に関し、さらに詳しくは、ピアトゥーピア（Ｐ２Ｐ）通信を用いたファイル売買に係るファイル配信システム及びファイル配信方法に関する。

現在、ファイルをウェッブ（Ｗｅｂ）で配信する方法として、ファイルを特定のサーバへ転送し、そこへ閲覧者がアクセスして閲覧者のクライアントＰＣへダウンロードする、所謂クライアントサーバ方式が主流となっている。かつて、ウェッブへ公開するファイルが文字と少量の低画質画像、および、小さなサイズの動画、およびフリーソフトウェアと言った小さなファイルのみであった時代には、多くのクライアントＰＣが特定のサーバにアクセスしてもそれほど問題なく通信が可能であった。

しかし、近年、ＦＴＴＨ（Fiber to the Home）やｘＤＳＬ（xDigital Subscriber Line）などの広帯域の通信網が整備されるにつれ、動画や音楽、高画質な画像などといった大容量のファイル、いわゆるブロードバンドコンテンツが拡充されてくると、クライアントサーバ方式にとっての大きな問題点が露呈してきた。

つまり、ファイルサイズが大きくなることで各ユーザが一つのサーバへアクセスしている時間が長くなると、一つのサーバにアクセスしているユーザの数が増加する。一方、サーバが一度に通信できる帯域は限られており、その帯域を、アクセスしているユーザで頭割りにするため、ユーザ一人に割り当てられる帯域は非常に小さなものとなってしまう。

一般に、ユーザの満足度を得るためには、ユーザが欲しいと思ったコンテンツが、即時に配信される必要があるので、ブロードバンドコンテンツの普及のためには、このような帯域の狭さは好ましくない。クライアントサーバ方式の通信方式において配信者がこのような問題を解決するためには、サーバの数を増やし、また、サーバ周辺のネットワーク帯域を広げる必要がある。

しかし、勿論ながらこのような配信環境の拡充は、配信者にとって大きな負担となり、新規にブロードバンドコンテンツビジネスに参入する障壁となる。
さらに、配信設備の拡充はコンテンツの価格上昇という形でユーザの負担となってしまう。このように、クライアントサーバ方式の通信ではブロードバンドコンテンツの浸透を促せない。

ここで、近年注目されているのが、ピアトゥーピア（Peer to Peer：以下、Ｐ２Ｐと省略する）方式と呼ばれる通信方式である。Ｐ２Ｐ通信方式は、その名の通り、通信に加わるクライアントＰＣが対等（Peer）に接続されているのが特徴であり、サーバ上に存在するファイルを参照するのではなく、他のクライアントＰＣ上にあるファイルを参照する通信方式である。

このＰ２Ｐ通信方式を用いると、配信者が一次的に配ったファイルを保持するクライアントＰＣがサーバのような役割を果たし、さらにそこからファイルを得た別のクライアントＰＣがサーバの役割をするため、配信サーバの負荷を分散させることができる。これにより配信者は低コストでコンテンツの配信を行うことができ、その結果ユーザがコンテンツを得るために必要な対価も小さなものとなる。

しかし、このＰ２Ｐを用いたファイル配信には様々な問題点がある。まず、転送に加わることに対するユーザのメリットが少ないことである。Ｐ２Ｐを用いてファイルを配信しても、配信者にしかメリットが無いというのでは、ユーザが転送に参加してくれない。

また、次に問題となるのがファイルの違法な共有である。Ｐ２Ｐ通信方式では、情報が特定の経路を経由するとは限らないため、その流通を管理するのは非常に困難である。そのため、Ｐ２Ｐ通信方式の通信では、ファイルがどれだけ出回ったかが分からず、また、どの受信者にファイルが転送されたかも分からない。したがって、コンテンツに対して課金する術はなく、また著作権のあるファイルをユーザ同士で勝手に共有されても、そのことを配信者が知る術がない。

この対策として、ファイル自体はＰ２Ｐで転送しながらも、その通信記録に関してはサーバで管理する、ハイブリッドＰ２Ｐという方式を利用する方法がある。なお、純粋にユーザ同士がやりとりをする通信方式をピュアＰ２Ｐ方式と呼ぶ。

しかし、ハイブリッドＰ２Ｐ方式によりユーザ同士のファイルのやりとりを監視した場合であっても、ユーザが取得したファイルを他の通信手段によって違法に交換されることも考えられる。これに対応するためには、ファイル自体は暗号化して、その復号化キーのみをクライアントサーバ方式で配信するという方法も考えられる。

しかし、全ての暗号化ファイルが同じ暗号化を施されている場合、あるユーザが取得したキーも一緒に流通されてしまうおそれがある。また、個別のユーザに配信するファイルに対して、個別の暗号化を施すようにしてしまうと、Ｐ２Ｐ通信のメリットが享受できない。

さらに、ファイルを利用する度に毎回認証を行うといった方法も考えられるが、使用の度に認証することは、ユーザがファイルを買ったという感覚にはそぐわず、また認証サーバにアクセスが集中すると認証に時間がかかるなど、ユーザの利便性を著しく損なうという問題点がある。

このような問題に対し、ファイル転送によって報酬を支払うシステムとしては、特許文献１に開示された発明が公知である。特許文献１に記載の方式では、ファイルの作成者とファイル配布者とを別にし、ファイル配布者が配布したファイル数に応じて、ファイル作成者がファイル配布者に報酬を支払うシステムである。ファイル作成者が直接ファイルを配布した場合、用意した配信サーバの帯域と実際に必要な帯域とが異なる場合がある。そこに、販売機会の消失というリスク、若しくは不必要に大きな帯域を用意し、無駄なコストが生じるというリスクが生じる。
一方、ファイル配布者が様々なファイル作成者から、配信を一手に請け負うことにより、予測した帯域と実際に必要な帯域とのずれが打ち消し合い、前述のようなリスクが低減する。
特開２００２−３１４５２５号公報

しかし、特許文献１に開示された発明では、クライアントサーバ方式による配信を背景としているため、転送者と受信者、つまり、ファイルの購入者が入れ替わることがない。つまり、ユーザから見れば、特許文献１の発明では仲介事業者が介入するだけに過ぎず、ファイルの購入者からすれば価格が増加することを意味する。

以上を鑑みて、本発明では、Ｐ２Ｐ通信方式によるファイル配信システムにおいて、ファイル配信者が利益を損なわず安価にファイルを配信することが可能なファイル配信システム及びファイル配信方法を提供することを目的としている。

上記の目的を達成するため、請求項１に記載の発明は、ファイルの配信を管理するサーバと、少なくとも２以上のクライアント装置とが、ネットワークを介して相互に接続可能であり、ファイルを要求するクライアント装置へ、転送にてファイルを配信するファイル配信システムであって、クライアント装置は、サーバが配信するファイルを保持する保持手段と、他のクライアント装置へファイルを転送する転送手段とを有し、サーバは、ファイルを管理する管理手段と、クライアント装置からの要求に基づいてファイルを配信する配信手段と、ファイルの転送に加わったクライアント装置の、転送に対して支払われる報酬を管理する報酬管理手段を有することを特徴とする。

請求項２に記載の発明は、請求項１に記載のファイル配信システムにおいて、サーバは、要求に基づいてファイルを転送するクライアント装置に対して、それぞれのクライアント装置毎に異なる暗号鍵を生成して送信する暗号鍵送信手段を有することを特徴とする。

請求項３に記載の発明は、請求項２に記載のファイル配信システムにおいて、サーバから配信された、若しくは、クライアント装置から転送されたファイルは、サーバ若しくは転送元のクライアント装置が有する個別の暗号鍵に基づいて暗号化されたことを特徴とする。

請求項４に記載の発明は、請求項２または３に記載のファイル配信システムにおいて、暗号化されたファイルは、復号化せずに再度暗号化が可能であることを特徴とする。

請求項５に記載の発明は、請求項４に記載のファイル配信システムにおいて、ファイルの暗号化は、ヴィジュネル暗号化方式を用いて暗号化することを特徴とする。

請求項６に記載の発明は、請求項１に記載のファイル配信システムにおいて、配信されるファイルの発信元は、ファイルの転送に加わるクライアント装置のクライアント数を予め設定することを特徴とする。

請求項７に記載の発明は、請求項６に記載のファイル配信システムにおいて、ファイルを転送するクライアント数は、配信元が設定したクライアント数の範囲内でランダムに決定される数であることを特徴とする。

請求項８に記載の発明は、請求項１に記載のファイル配信システムにおいて、サーバは、報酬が支払われる場合に、報酬を受給するクライアント装置に対して通知を行う支払い通知手段を有することを特徴とする。

請求項９に記載の発明は、請求項２または３に記載のファイル配信システムにおいて、クライアント装置は、暗号化されたファイルを復号化するときに、クライアント装置固有の情報を復号化後のファイルに付加することを特徴とする。

請求項１０に記載の発明は、ファイルを配信するサーバからネットワークを介して、ファイルの要求先のクライアント装置へ、転送にてファイルを配信するファイル配信方法であって、サーバが、クライアント装置からファイルの要求を受けると、要求先のクライアント装置以外のクライアント装置へファイルを配信する工程と、ファイルの要求先以外のクライアント装置が、要求先のクライアント装置へとファイルを転送する工程とを有し、サーバは、ファイルの転送に加わったクライアント装置に対して報酬を支払うことを特徴とする。

請求項１１に記載の発明は、請求項１０に記載のファイル配信方法において、サーバは、ファイルを転送するクライアント装置に対して、それぞれのクライアント装置毎に異なる暗号鍵を生成して送信する暗号鍵送信工程を有することを特徴とする。

請求項１２に記載の発明は、請求項１１に記載のファイル配信方法において、サーバから配信された、若しくは、クライアント装置から転送されたファイルは、サーバ若しくは転送元のクライアント装置が有する個別の暗号鍵に基づいて暗号化されることを特徴とする。

請求項１３に記載の発明は、請求項１１または１２に記載のファイル配信方法において、暗号化されたファイルは、復号化せずに再度暗号化が可能であることを特徴とする。

請求項１４に記載の発明は、請求項１３に記載のファイル配信方法において、ファイルは、ヴィジュネル暗号化方式を用いて暗号化することを特徴とする。

請求項１５に記載の発明は、請求項１０に記載のファイル配信方法において、配信されるファイルの発信元は、ファイルの転送に加わるクライアント装置のクライアント数を予め設定することを特徴とする。

請求項１６に記載の発明は、請求項１５に記載のファイル配信方法において、ファイルを転送するクライアント数が、配信元が設定したクライアント数の範囲内でランダムに決定されることを特徴とする。

請求項１７に記載の発明は、請求項１０に記載のファイル配信方法において、サーバは、報酬が支払われる場合に、報酬を受給するクライアント装置に対して通知を行う支払い通知工程を有することを特徴とする。

請求項１８に記載の発明は、請求項１１または１２に記載のファイル配信方法において、クライアント装置は、暗号化されたファイルを復号化するときに、クライアント装置固有の情報を復号化後のファイルに付加することを特徴とする。

このように、本発明のファイル配信システム及びファイル配信方法によれば、Ｐ２Ｐ通信方式によるファイル配信システムにおいて、ファイル配信者が利益を損なわず安価にファイルを配信することができる。

本発明では、Ｐ２Ｐ通信方式によるファイル配信システムにおいて、転送に加わったクライアントを所持するユーザに対して、何らかの報酬を与えるシステムを提案するものである。その目的とするところは、ファイル配信者が利益を損なわないで安価にファイルを配信できる枠組みを提供しつつ、更にユーザが手軽にファイルを得ることができ、且つ、コンテンツ配信のためのＰ２Ｐネットワークにユーザが転送者として参加するメリットを与えることである。

すなわち、本発明では、購入者と転送者とが適宜入れ替わり、転送によって得た報酬をファイルの購入資金に充てることができるため、ファイルの価格が見かけ上減少することになる。これについて、以下に、本実施形態のファイル配信システム及びファイル配信方法を、図面を参照しながら説明する。なお、本実施形態は以下に述べるものに限定されず、その趣旨を逸脱しない範囲において種々変更が可能である。

図１は、本実施形態のファイル配信システムの構成の一例を示す図であり、配信ファイルおよび暗号化キー、復号化キーのやりとりの流れを示している。

図１に示すように、本実施形態のファイル通信システムでは、配信サーバ１０００と、転送管理サーバ１００１と、第１クライアント１００２と、第２クライアント１００３と、第３クライアント１００４と、第４クライアント１００５とが、それぞれネットワークを介して相互に接続可能な状態にある。また、図１中において、点線は暗号化キー若しくは復号化キーのやりとりを示し、実線は配信ファイルのやりとりを示すものとする。

まず、ファイルの配信者は、配信サーバ１０００および転送管理サーバ１００１を用意しておく。
ここからは、配信ファイル、暗号化キー、復号化キーのやりとりを詳述する。

まず、あるクライアント、例えば第４クライアント１００５が、転送管理サーバ１００１に対してファイルの配信要求を出すと、転送管理サーバ１００１はファイルの配布元を決定する。このとき、ファイルの配布元となるのは配信サーバ１０００か、もしくは、既に配信サーバ１０００によりファイルを配布されたクライアント（以下、このようなクライアントを「配布元クライアント」と呼ぶ）、例えば第１クライアント１００２である。

ここで、転送管理サーバ１００１による、配信サーバ１０００が配布元となるか、いずれかのクライアント（配布元クライアント）が配布元となるかの決定は、配信履歴管理ＤＢの配信履歴管理テーブルを参照することによって行われる。配信履歴管理テーブルの例を図８に示した。

まず、転送管理サーバ１００１は、第４クライアント１００５から受け取ったファイル配信要求の内容を確認する。そして、転送管理サーバ１００１は、ファイル配信要求によって配信要求がなされているファイル名に基づき配信履歴管理テーブルを参照することで、配信要求がなされているファイルを有したクライアントの情報を取得する。転送管理サーバ１００１は、配信要求がなされているファイルを有したクライアントが存在しない場合には、配信サーバ１０００を配布元として選択し、配信要求がなされているファイルを有したクライアントが存在する場合には、配信要求がなされているファイルを有したクライアントのうちいずれかのクライアントを転送元（配布元クライアント）として選択する。

ここで、配信要求がなされているファイルを有したクライアントが複数存在する場合には、各クライアントが配布元クライアントとなった場合の報酬条件等に基づき、いずれかのクライアントを配布元クライアントとして選択する。後述する転送クライアント管理テーブルを参照し、各クライアントの報酬条件を得て、条件に合うクライアントを配布元クライアントとする。
なお、クライアント毎に配布元クライアントとなった場合の報酬条件を登録したテーブルを別に有する構成としてもよい。また、報酬条件等によらず、配信要求がなされているファイルを有したクライアントからランダムに選択してもよい。

ファイルの配布元が配信サーバ１０００であった場合には、以下のような動作が行われる。

転送管理サーバ１００１はまず、配信サーバ１０００に対して第４クライアント１００５の通信先（宛先）を通知し、用意されていた第４クライアント１００５に対する暗号化鍵を送信する。すると配信サーバ１０００は、受信した暗号化鍵を用いて配信するファイルを暗号化する。

一方、ファイルを受け取った第４クライアント１００５は、配信者にファイル利用の対価を支払うことで、転送管理サーバ１００１に存在する暗号化鍵を得ることが可能となり、この暗号化鍵を用いてファイルを復号化することで、配信ファイルを使用できるようになる。なお、ファイルを復号化する際には、例えばファイルの冒頭部に、ＩＰアドレスなどユーザ固有の情報を付加しておく。
このように、ファイルにユーザの固有情報を付加することによって、ファイルを不特定多数にばらまいたユーザについて、ネットワーク上にばらまかれたファイルから特定することが可能となる。

このように本実施形態では、各クライアントで個別のファイルごとに暗号化が施されていることで、暗号化鍵を不正に共有されることに対する抑止力となる。また、ファイルが複合化される際にも、ユーザの情報をファイルに埋め込むことができるので、復号化後のファイルの違法共有に対する抑止力にもなる。

次に、転送管理サーバによって選択された配布元が、配布元クライアントである場合について説明する。

まず、転送管理サーバ１００１は転送経路を決定する。転送経路の決定には、転送に加わるクライアント（以下、このようなクライアントを「転送クライアント」と呼ぶ）の決定、及び、どのような順番で複数の転送クライアントを経由していくかの決定を含む。
次に、転送管理サーバ１００１は、転送クライアント管理ＤＢの転送クライアント管理テーブルを参照する。
ここで、転送クライアント管理テーブルは、転送クライアントとすることができるクライアントが登録されているテーブルである。

転送クライアント管理テーブルの例を図９に示した。
転送管理サーバ１００１は、転送クライアント管理テーブルを参照し、転送クライアント管理テーブルに登録されているクライアントの中からいくつかのクライアントを選択し、転送クライアントとする。ここで、配布元クライアントが転送クライアントとして転送クライアント管理テーブルに登録されている場合には、配布元クライアントが転送クライアントとして選択されないようにすると良い。つまり、配布元クライアントの名前（又は、識別番号）と、転送クライアント管理テーブルから選択したクライアントの名前（又は、識別番号）とが同一の場合には、そのクライアントは転送クライアントとしないようにすればよい。

なお、転送クライアント管理テーブルとしては、種々の設計方法が考えられる。単に、何の分類もせず、各転送クライアントを転送クライアント管理テーブルに登録しても良いし、各転送クライアントが存在する国毎、地域毎に分類して登録しても良いし、各転送クライアントの通信能力（通信速度、帯域等）毎に分類して登録しておいても良い。また、図９に示したように、転送クライアント管理テーブルとして、各クライアント毎にどのような条件（対象とするファイルの内容、報酬の額等）であれば転送クライアントとして転送に加わるかを登録しておくと良い。このように分類して登録しておくことで、所望の条件に合うような転送経路を決定しやすくすることが出来る。

このとき、何台の転送クライアントを経由してファイルを転送するかについては、配信者が事前に決定しておくものとするが、経由される転送クライアントの数は、ある程度の長さで、且つ、特定の数字ではなく所定の範囲（例えば６台〜８台など）に設定しておくと良い。こうすると、転送クライアントのユーザが経路をある程度たどることによって、どのユーザがどのようなファイルを入手したかというような個人情報が、転送クライアントのユーザに知られないようにすることができる。

なお、配信者は経由される転送クライアントの数は、ある程度の長さで、且つ、特定の数字ではなく所定の範囲（例えば６台〜８台など）と設定しておき、所定の範囲からの転送クライアント数の選択を配信の都度自分で行っても良いし、乱数等によって行うようにしても良い。

ここでは転送クライアントとして、第２クライアント１００３、第３クライアント１００４の２つが選択され、転送経路として、配布元クライアントである第１クライアント１００２から、転送クライアントである第２クライアント１００３、第３クライアント１００４の順にファイルを転送する経路が決定されたものとする。

前述したように、本実施形態では、ファイルが経る転送クライアントの数を、ファイルの発信者が指定しておくことによって、流通コストを任意の額に抑制することができる。したがって、ファイル配信者がシステムを利用し易くなる。また、この転送者数（転送クライアントの数）の範囲内での不特定数を、ファイルが経る転送者数（転送クライアントの数）とすることで、各転送者は誰がファイルを所望したのか知ることができない。したがって、ファイルの所望者に係る個人情報の保護にもつながる。

次に、転送経路が決定すると、転送管理サーバ１００１は、配布元クライアントに対して、転送経路となっている各転送クライアント用の暗号化鍵を合成した転送用鍵を送付する。
この例では、転送管理サーバ１００１は、配布元クライアントである第１クライアント１００２に対して、転送クライアントである第２クライアント１００３の暗号化鍵と、第３クライアント１００４の暗号化鍵と、を合成した転送用のキー（転送用鍵）を作成して第１クライアント１００２へと送信する。
なお、転送用鍵の合成方法については後述する。

転送用鍵を受け取った配布元クライアントである第１クライアント１００２は、この転送用鍵を用いて転送するファイルを暗号化して、転送クライアントである第２クライアント１００３へ送信する。
第２クライアント１００３は配布元クライアントである第１クライアント１００２からファイルを受信する。また、転送管理サーバ１００１から転送要求情報を受信する。ここで、転送要求情報の構成を図１０に示した。転送要求情報には、対象となっているファイルを次に転送する通式先（宛先）と第２クライアント１００３用の復号化鍵が含まれている。

ファイル及び転送要求情報を受信した第２クライアント１００３は、第２クライアント１００３用の復号化鍵により、ファイルを復号化して、転送要求情報の通信先（宛先）に基づき、転送経路上の次の転送クライアントである第３クライアント１００４へとファイルを送信する。このとき、第２クライアント１００３は転送対象であるファイルを、第２クライアント１００３の記憶装置に保存しておく。第３クライアント１００４は、第２クライアントと同様の動作をする。つまり、第３クライアント１００４は転送クライアントである第２クライアント１００３からファイルを受信し、転送管理サーバ１００１から転送要求情報を受信する。

第３クライアント１００４用の復号化鍵により、ファイルを復号化して、転送要求情報の通信先（宛先）に基づき、転送経路上の次のクライアントへとファイルを送信する。また、第３クライアント１００４も同様に、転送対象であるファイルを、第３クライアント１００４の記憶装置に保存しておく。

そして、最終的にファイルの配信要求を行った第４クライアント１００５へファイルが到達する。上記した第４クライアントのファイルの配信要求から、第４クライアントへファイルが到達するまでの転送フローを図１１に示した。なお、図１１では、転送管理サーバを１００１をサーバとしている。これは、転送管理サーバと配信サーバとをまとめて１つのサーバとしてもよいし、さらに、その他の機能を有するサーバを含めて１つのサーバとしても良いことを意味している。

第４クライアント１００５は、第３クライアント１００４からファイルが転送されて到達すると、ファイルが到達した旨を転送管理サーバ１００１へ通知する。このとき、第１クラインアント１００２と第２クライアント１００３、及び第３クライアント１００４は、ファイルの配信（配布及び転送）に加わった報酬を受け取る権利を得る。このとき、転送管理サーバ１００１より、ファイルの配信（配布及び転送）に加わった各クライアントに対して報酬を送信する。
ここで、報酬の送信は、銀行への振り込みや、電子マネーの送付のように、実際の報酬をその場で送信（支払い）する方法でもよいし、将来的に実際の報酬が支払われる旨の通知をする方法でも良い。

このように、ファイルの配信（配布及び転送）に加わることによって報酬を得ることができるので、ファイル転送者が積極的に本実施形態のファイル配信システムに参加することになる。また、転送者がファイル転送の参加時に得た報酬を用いれば、例えばファイルを購入する際などに、見かけ上の価格が下がることになる。したがって、ファイルの購買意欲の向上に結びつき、ファイル配信者の利益も向上する。

また、転送管理サーバ１００１から各クライアントに対して報酬の発生を通知することで、転送参加者のモチベイションを向上させることにもなる。なおこの際、通知とともにクライアント側から、視覚的・聴覚的にもユーザに報酬の発生を通知することとすることが更に好ましい。報酬の発生に係る演出を行うことにより、ユーザはファイル転送に参加した意義を実感できるので、より一層ファイル転送に参加するモチベイションを高めることができる。
なお、上記した例では、配布元が配布元クライアントであった場合に、転送クライアント及び転送経路を設定してファイルの配信を行ったが、配布元が配信サーバ１０００であった場合にも同様の処理を行うことができる。

また、前述のファイル配信があった後に、前述にて選択されなかったクライアント（例えば、第５クライアント）からファイル配信要求があった場合について説明する。
まず、前述のファイル配信があった後、転送管理サーバ１００１は、配信履歴管理テーブルの更新を行う。つまり、前述のファイル配信により、転送クライアントであった第２クライアント１００３及び第３クライアント１００４はファイル１を保持することとなったため、配信履歴管理テーブルのファイル１の欄に、第２クライアント１００３及び第３クライアント１００４を追加する。

そして、第５クライアントからファイル１の配信要求があった場合には、転送管理サーバ１００１は、更新された配信履歴管理テーブルを参照し、配信要求がなされているファイルを有したクライアントの情報を取得する。更新後の配信履歴管理テーブルでは、配信要求がなされているファイルを有したクライアントとして第１クライアント１００２、第２クライアント１００３，第３クライアント１００４が存在するため、この中のいずれか１つのクライアントを転送元（配布元クライアント）として選択する。

なお、配布元クライアントとなっても良いか否かについて、事前にクライアントに申請させ、申請があったクライアントのみ配布元クライアントとしても良い。また、申請があったクライアントのみを、配信履歴管理テーブルに追加するようにしてもかまわない。

このように、転送の過程に存在したクライアントには、実際に転送したファイルが残る。したがって、後にこのファイルを所望するユーザが現れた場合には、転送を行った複数のクライアントからファイルを入手できるので、ファイルを手に入れやすい状況が作られることになる。

以上、本実施形態によれば、Ｐ２Ｐ通信により特定のサーバに過大な負荷がかかる虞が無くなる。したがって、転送過程において、転送の前段階にあるクライアントが暗号化を繰り返すことによって当該クライアントに残ったファイルが、それぞれのクライアント毎に異なる暗号化を施された状態のファイルであるようにすることができる。

次に、本実施形態における暗号化について、図面を用いて説明する。なお暗号化の方法として、ここではより簡潔化するため、ヴィジュネル暗号方式を用いるものとする。
まず、図２は、ヴィジュネル方陣を示す図である。

ヴィジュネル暗号方式は、この図２に示すようなヴィジュネル方陣を用いて暗号化を行う。ヴィジュネル方陣の第一行は、鍵となる文字、第一列は暗号化を施す平文を示している。一般的なヴィジュネル方陣の鍵および平文では、ＡからＺまでのアルファベットを用いるが、ファイルとして流通するものはデジタルコンテンツであることから、扱いやすいように鍵および平文は１６進数を表現できる０〜ｆとした。

この方陣を使って暗号化する方法を例示する。例えば、平文が１０２７ｅ７０３であり、かつ、鍵がｆ３０１だったとすると、その復号化は以下の手順で行う。

まず、平文の１文字目は１であり鍵の１文字目はｆであるため、ヴィジュネル方陣の３行１７列を見るとａである。次に、平文の２文字目は０であり、かつ鍵の２文字目は３である。そこでヴィジュネル方陣の２行４列を見ると３である。同様に２は２、７は８となる。

次に、平文５文字目のｅに対し、鍵の５文字目は存在しないので１文字目に戻ることになる。したがって、ｅはｆを鍵とする。このようにして、平文：１０２７ｅ７０３を鍵ｆ３０１で暗号化すると、第１の暗号：ａ３７８４ａ０４となる。なお、復号化する場合は、この逆の手順を追えばよい。

次に、２つ目の鍵として９００１を考える。この鍵を、第１の鍵であるｆ３０１で復号化する。このとき、鍵ｆに対して暗号化後の値が９である平文を探すと、ａとなる。同様にしてｆ３０１を９００１で復号すると、第３の鍵：ａ３００になる。
さらに、第３の鍵で先ほど暗号化して得られた第１の暗号：ａ３７８４ａ０４を再度暗号化すると、第２の暗号：４０７８ａｄ０４となる。

この第２の暗号を第３の鍵で復号すると、もともとの平文：１０２７ｅ７０３になる。つまり、第１の暗号に対して、一度復号化することなく第２の鍵に対する暗号が作成できたことになる。この仕組みは単純で、そもそもヴィジュネル方陣は平文を対応する鍵の値だけシフトさせたものである。つまり平文をｘ、第一の鍵をａとすると、第一の暗号はｘ＋ａで表わせる。

一方、平文を第２の鍵ｂで暗号化すると、第２の暗号はｘ＋ｂである。それに対し、第２の鍵を第１の鍵で復号した第３の鍵を考えると、ｂ−ａとなる。つまり、第３の暗号はｘ＋ａ＋（ｂ−ａ）＝ｘ＋ｂとなる。

これにより、配信者は転送者に対して復号化キーを送ること無く暗号化を行ってもらうことが可能となる。したがって、復号化キーを盗用されることが無くなるとともに、転送者側でも復号化、暗号化という二つの処理を行わなくてすむため、処理量が少なくなるというメリットがある。ただし、暗号鍵の長さは一定である必要がある。

このように、本実施形態によれば、暗号化されたファイルを一度復号化することなく、さらに暗号化することができる。これは、前述したように、暗号化する方式としてヴィジュネル暗号化方式を用いているからである。したがって、暗号化を容易に行うことが可能となり、転送者たる各クライアントにかかる負担を軽減することが可能となる。

もう少し分かり易くするために、以下、ファイル要求クライアント、転送管理サーバ１００１、転送クライアントの各動作について詳細に説明する。まず、本実施形態のファイル要求クライアントの動作について図面を用いて説明する。

なお、以下の各フローチャートにおいて、暗号化及び復号化の処理は、それぞれ同じ処理を施している。転送管理サーバ側から各クライアントに対して送信するものは復号化鍵であり、各クライアント間で送信するものは暗号化鍵となる。

図３は、ファイルを要求するクライアントの動作を示すフローチャートである。

ファイルを要求するクライアントは、必要なファイルの配信要求を転送管理サーバ１００１に送信する（ステップＳ１０１）。
次に、転送クライアント若しくは配信サーバ１０００から、暗号化された必要なファイルを取得して、さらに、転送管理サーバ１００１から、復号化キーを取得する（ステップＳ１０２）。
ここで、復号化キーは、要求したファイルに対する対価を支払った場合にのみ取得できるものとする。なお、ファイルを実際に使用するためには、転送クライアント若しくは配信サーバ１０００から入手した暗号化済みのファイルを、転送管理サーバより入手した復号化キーにて復号化すればよい。

このように、ファイルに対する対価を支払うことを除けば、ファイルを要求するユーザは、転送管理サーバ１００１にファイルの配信要求を出すだけでよい。したがってユーザは、所望するファイルを手軽に入手することができる。

次に、本実施形態の転送管理サーバ１００１の動作について説明する。
図４は、転送管理サーバ１００１の動作を示すフローチャートである。

まず、転送管理サーバ１００１では、転送クライアント管理テーブルに登録された各転送クライアントに対して、予め個別の復号化鍵を用意しておく（ステップＳ２０１）。そして転送管理サーバ１００１は、クライアントからのファイルの要求（ファイルの配信要求）を受けると（ステップＳ２０２）、ファイルの配布元を配信サーバ１０００とするか否かを決定する（ステップＳ２０３）。この決定は、配布すべきファイルが、以前にどれだけのクライアントに配布されたかなどによって決定すればよい。

つまり、配信要求されたファイルに基づき、配信履歴管理テーブルを参照し、配信要求されたファイルを有するクライアントの情報を得て、配信要求されたファイルを有するクライアントがどれくらい存在するかに応じて、ファイルの配布元を配信サーバ１０００とするか否かを決定すればよい。

配布元が配信サーバ１０００であった場合には（ステップＳ２０３／Ｙｅｓ）、要求のあったクライアントに対して、ステップＳ２０１にて予め個別に用意していた復号化キーを送信する（ステップＳ２０９）。

一方、配布元が配信サーバ１０００ではなかった場合には（ステップＳ２０３／Ｎｏ）、配信ファイルの転送経路を設定する（ステップＳ２０４）。転送経路の決定には、転送に加わる転送クライアントの決定、及び、どのような順番で複数の転送クライアントを経由していくかの決定を含む。ファイルの転送経路を設定すると、次に、転送経路中における１番初めの転送クライアントに対する復号化キーと、次のクライアント、すなわち、転送経路中における２番目の転送クライアントに対する復号化キーとを合成して、暗号化キーを作成する（ステップＳ２０５）。ここで、暗号化キーの合成方法は、上述した合成方法に基づいて行われる。

暗号化キーを合成すると、この暗号化キーを転送経路中の１番最初のクライアントへと転送する（ステップＳ２０６）。さらに、１番最初の転送クライアントに対して、次にファイルを転送する転送先（２番目）のクライアントを示して、ファイルの転送要求を行う（ステップＳ２０７）。そして、１番最初のクライアントから２番目のクライアントへ、ファイルが到達したかどうかを確認する（ステップＳ２０８）。

このとき、ファイルを要求したクライアントに配布ファイルが到達した場合には（ステップＳ２０８／Ｙｅｓ）、前述したステップＳ２０１にて準備していた復号化キーを、ファイルを要求したクライアントに転送して（ステップＳ２０９）、処理を終了する。一方、配布ファイルが到達しなかった場合には（ステップＳ２０８／Ｎｏ）、ステップＳ２０５へと移行し、再度暗号化キーを合成する。

次に、本実施形態の転送クライアントの動作について説明する。
図５は、転送クライアントの動作を示すフローチャートである。

まず、転送クライアントは、配信サーバ１０００、転送管理サーバ１００１、配布元クライアント、若しくは他の転送クライアントから、ファイルの転送要求を受け付ける（ステップＳ３０１）。このとき、転送クライアントは同時に、転送管理サーバ１００１より復号化キーを取得して（ステップＳ３０２）、ファイルの復号化を行う（ステップＳ３０３）。
そして最後に、復号化したファイルを、転送管理サーバ１００１により設定された次の転送先クライアントへと転送して（ステップＳ３０３）、処理を終了する。

なお本実施形態において、更に望ましくは、ファイルの配信者が各転送者に対して、配信者の提供するファイルの転送を行った際に、転送量に応じてどれだけの報酬を支払うかを宣言、告知しておくとよい。一方、ファイルの受信者であり、また転送者たる各クライアントは、前記の宣言、告知条件を判断基準の一つとして、どのファイルの転送に参加する意志があるかを、事前に転送管理サーバ１００１に対して宣言しておく。
そして、各クライアントからの宣言を受けた転送管理サーバ１００１は、転送クライアント管理テーブルとして、各クライアント毎にどのような条件（対象とするファイルの種類や内容、報酬の額等）であれば転送クライアントとして転送に加わるかを登録しておく。

このように、各クライアント（ユーザ）に対して、ファイル転送に係る参加意志・参加条件などを事前に確認しておくことで、ユーザが不本意なファイルの共有に参加してしまうことが無くなる。不本意なファイルの共有とは、例えば、配信者からの報酬が少ないファイル共有や違法ファイルの共有を意味する。

またこのとき、個々のファイルを指定するのでなく、様々な条件に応じてファイルの転送に参加するグループ分けを行うことが更に望ましい。このグループ分けの条件とは、例えば、転送するファイルが音楽ファイルであるとか、この会社の提供するファイルであるといった条件である。このように、転送に参加するグループ分けを行うことにより、ファイルの転送量を管理したり、特定のファイル配信者には荷担したりしたくはないというようなユーザの意志を反映させることが可能となり、ユーザの利便性が向上する。

以上、本実施形態のファイル配信システム及びファイル配信方法によれば、Ｐ２Ｐ通信方式によるファイル配信システムにおいて、ファイル配信者が利益を損なわないで安価にファイルを配信することができる。

従来技術でも、クライアントサーバ方式と比べてＰ２Ｐ方式のファイル配信は、配信サーバにかかる負荷が非常に小さくなるため、大容量のファイルを配信するのに好適である。しかし、Ｐ２Ｐ方式におけるファイル配信の問題点のとして、転送者が通信に加わるメリットが薄い点や、違法共有に使われるという点が挙げられる。

これに対して本実施形態のファイル配信システムでは、まず転送クライアントに報酬を発生することにより転送者が通信に加わるメリットを増大させた。また本実施形態では、違法共有に用いられるデメリットを回避する効果がある。これについて詳述する。

本実施形態では、転送をピュアＰ２Ｐ方式ではなく、ハイブリッドＰ２Ｐを用いることによってファイルの転送を管理している。したがって、違法なファイルの配布や共有に用いられる可能性は、ピュアＰ２Ｐ方式に比べて低くなる。また、各ファイルに応じて個別の暗号化を行っているため、更に違法なファイルの配布、共有に用いられる可能性は低くなる。

しかし、一部のユーザが、ファイルと復号化キーの両方、若しくは復号化したファイルを、他のピュアＰ２Ｐ方式等を用いて、違法に配布、共有してしまうことに対する抑止力にはならない。一方、本実施形態では、ファイルを所持して転送に参加すればファイルの配信者から報酬が得られる。もし、違法にファイルを配布、共有してしまうと、このユーザは報酬を得る機会を失うことになるため、違法な配布、共有を抑止する効果がある。

さらに本実施形態には、ファイルの売り上げを向上させる効果もある。なぜなら、本実施形態ではファイルの転送者に報酬が発生するからである。ここでいう報酬とは、実際の金銭でもよいし、本実施形態のファイル配信システム内においてのみ利用できるポイントのようなものでもよい。どちらにしても、自動的に貯まる報酬によって、ファイルの価格は見た目上は下落する。

通常の商品流通においては、商品を欲しいと思うユーザ層（図６（Ａ））の中で、業者が設定する価格を支払ってもよいユーザ層（図６（Ｃ））のみが商品を購入する。実際の価格が安ければ安いほど、図６（Ｃ）の円は図６（Ｂ）のように、図６（Ａ）の円へと近づいていく。

本実施形態のファイル配信システムでは、転送に参加しているユーザにとって、時間さえかければ価格が０になる。一方、配信者側から見ると、図６（Ｃ）の円を図６（Ａ）の円にすることができる、つまり、ファイルの売り上げが向上するのである。

ここで、極端な説を挙げると、違法ファイル共有によりファイルを得るユーザは、そのファイルが無料で手に入るから利用するのであって、ファイルが無料で手に入らなければ、そもそもそのファイルを利用しないという説がある。

本実施形態のファイル配信システムにおいては、ある程度報酬が貯まるとファイルを無料で手に入れることができる。また、ファイルを無料で入手できる程の報酬が貯まらなくても、ファイルの入手時に減額などが行われる。したがって、ファイルを無料で手に入れたい、あるいは、割引で手に入れたいと思うユーザ、すなわち、違法ファイルを入手する前記のようなユーザも顧客層として取り込むことができ、さらに売り上げを向上させることができる。

なお、これだけでは、金銭が配信者のみの間でやりとりされるように見えるが、そうではない。前述した「時間さえかければ、価格が下落する」ということが、その理由である。転送クライアントにどれだけの報酬を支払うかにもよるが、実際には、ユーザにとって欲しいファイルが存在するときに、必ずしも転送によって得た報酬があるとは限らない。

例えば、音楽ファイルの配信を用いて説明すると、あるユーザ１にとっては、該音楽ファイルがすぐに所望するファイルであり、別のユーザ２にとっては、ある程度の日時の経過後、すなわち、すぐには必要ないが後で所望する予定の音楽ファイルである、と仮定する。

この場合、ユーザ１がファイルを要求する場合には、転送による報酬如何に関わらず、すぐにファイルを要求（購入）することになる。一方、ユーザ２にとっては、現時点では必要ないがいずれファイルを要求する。このとき、ユーザ１のファイル要求時よりも時間が経過していることになる。前述したとおり、一般的には「時間さえかければ、価格が下落する」ので、ユーザ２はユーザ１よりもファイルを安価に購入することができる。

しかしこの場合でも、図６（Ｃ）のユーザならば、ユーザ１のように転送による報酬に関わらず、すなわち、転送によって得た報酬以外の金銭を用いてファイルを購入するので、システム上で流通する金銭自体は増加することになる。

前述した特許文献１では、転送者が得た報酬がシステム内で還元されず、ユーザにとっては価格が上昇することにしかならない。一方、これまで述べたように、本実施形態のファイル配信システムでは、受信者は転送者でもあるため、配信者が流通コストとして計上したファイルの価格は、転送者たる受信者に支払われている。そのため、見かけ上の価格は上昇しない。更に、図６で示したような様々な顧客層を取り込めると言う点で、配信者にも大きなメリットがあるのである。

なお、本実施形態においては、配信サーバが１つ、転送管理サーバ兼報酬管理サーバが１つとして説明したが、これらの機能をシステムで具備していれば問題なく、それぞれが別個に存在しても、１つのサーバによって行われても構わない。勿論、転送管理サーバの数、配信サーバの数、報酬管理サーバの数が異なっていても何ら問題はない。

また、本実施形態のファイル配信システムにおいて、管理サーバの負担をさらに軽減させることも可能である。これについては、図７を用いて説明する。

まず、前提条件として、本実施形態のファイル配信システムにファイル転送者およびファイル受信者として参加するユーザは、管理サーバに登録することで識別ＩＤを取得しておく。
次に、ファイルの配信者は、配信するファイルの一次転送者を募り、事前に転送者に対して配信サーバからファイルを配信しておく。このとき、ファイルを特定の暗号鍵を用いてヴィジュネル暗号化方式を用いて暗号化する。その後、各一次転送者の識別ＩＤをファイルの一部に付加する。

次に、ファイルを所望するユーザの動作について説明する。
各ユーザがファイル配信システムに参加するためには、まず、事前にインストールしたアプリケーションを起動させる。アプリケーションを起動させると、ユーザは、図７に示すような仮想ネットワークにおいて、Ａ００〜Ａ４４で示される何れかのノードとなる。
各段のノードは、下層のノードにどのようなファイルが存在するかを把握しておく。なおここでは、ユーザがＡ４４としてネットワークに参加したこととして、以降の説明を行う。

ユーザは、特定のファイルを所望する際に、上段のノードＡ３３に対し要求を出す。もし、上段のノードにぶら下がることができるＡ４３〜Ａ４４の何れかにファイルが存在する場合には、該ノードに対して要求を出し、自らを転送者としてＡ４４へファイルを転送する。そしてこの転送過程において、各転送元では転送先の識別ＩＤを転送先ノードから取得して、ファイルの一部に付加する。同様に、Ａ３３に情報が無ければＡ２２へ要求を出し、Ａ２２に情報が無ければ更にＡ１１へとファイル探索を行う。

また、前述したファイル探索方法にても所望のファイルが見つからない場合には、現在接続しているこの仮想ネットワークから一度離脱して、別の仮想ネットワークにつなぎ直す。このような動作を繰り返すことで、ファイルを発見して所望のファイルを得る。最終的にファイルを所望したユーザが得た転送ファイルには、転送に加わったクライアント識別ＩＤが全て記載されている。

そして、ファイルを所望したユーザがファイルの利用を行いたい場合には、管理サーバへファイルに対する対価を支払うことによって鍵を得る。このとき、転送に加わったクライアントの識別ＩＤを管理サーバに送付することで、転送に加わったクライアントは、事前に配信者が定めた報酬量を頭割りで受け取る権利を得る。

すなわち、ファイルを購入してもらって初めて転送者に報酬が発生するので、流通コストを任意の額内に抑制することができ、ファイル配信者が、本実施形態のファイル配信システムを利用し易くなる。また、ファイル配信者が予め定めた報酬料を頭割りにすることで、流通コストを一定にしつつ、且つ、転送者数を完全に不特定数とすることができるので、ファイル所望者の個人情報をより一層秘匿することができる。

なお本実施形態では、ファイルがどこにあるかを管理しているサーバは存在しない。したがって、所望するファイルの検索をするためには、単純には、世界中のＰＣに対して所望するファイルをブロードキャストする必要がある。すると、検索情報だけでネットワークが飽和してしまう虞があるため、このような仮想ネットワークに対する仕組みを用いている。

このように、本実施形態のファイル配信システム及びファイル配信方法によれば、管理サーバにかかる負担を極めて少なくすることができる。その一方で、ユーザ毎に異なる暗号化を施すことができなくなるため、暗号化鍵を違法に共有される虞がある。しかし、転送に加わるユーザにとって鍵を共有してしまうことは、前述したように、自らが転送により得られる報酬を失うというデメリットがあるため、違法共有に対する抑止力をも有することになる。

なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。

本実施形態のファイル配信システムの構成を示す図である。 ヴィジュネル方陣を示す図である。 本実施形態において、ファイルを要求するクライアントの動作を示すフローチャートである。 本実施形態の転送管理サーバ１００１の動作を示すフローチャートである。 本実施形態の転送クライアントの動作を示すフローチャートである。 商品流通におけるユーザ層の分類を模式的に示す図である。 本実施形態のファイル配信システムの仮想ネットワークを示す図である。 配信履歴管理テーブルの一例を示す図である。 転送クライアント管理テーブルの一例を示す図である。 転送要求情報の構成の一例を示す図１０である。 第４クライアントのファイルの配信要求から、第４クライアントへファイルが到達するまでの転送フローを示す図である。

符号の説明

１０００ 配信サーバ
１００１ 転送管理サーバ
１００２ 第１クライアント
１００３ 第２クライアント
１００４ 第３クライアント
１００５ 第４クライアント

Claims (18)

1. ファイルの配信を管理するサーバと、少なくとも２以上のクライアント装置とが、ネットワークを介して相互に接続可能であり、前記ファイルを要求する前記クライアント装置へ、転送にてファイルを配信するファイル配信システムであって、
   前記クライアント装置は、
   前記サーバが配信する前記ファイルを保持する保持手段と、
   他の前記クライアント装置へ前記ファイルを転送する転送手段とを有し、
   前記サーバは、
   前記ファイルを管理する管理手段と、
   前記クライアント装置からの要求に基づいて前記ファイルを配信する配信手段と、
   前記ファイルの転送に加わった前記クライアント装置が、前記転送に対して受給する報酬を管理する報酬管理手段を有することを特徴とするファイル配信システム。
2. 前記サーバは、
   前記要求に基づいて前記ファイルを転送する前記クライアント装置に対して、それぞれの前記クライアント装置毎に異なる暗号鍵を生成して送信する暗号鍵送信手段を有することを特徴とする請求項１に記載のファイル配信システム。
3. 前記サーバから配信された、若しくは、前記クライアント装置から転送された前記ファイルは、前記サーバ若しくは転送元の前記クライアント装置が有する個別の前記暗号鍵に基づいて暗号化されたことを特徴とする請求項２に記載のファイル配信システム。
4. 前記暗号化された前記ファイルは、復号化せずに再度暗号化が可能であることを特徴とする請求項２または３に記載のファイル配信システム。
5. 前記ファイルの暗号化は、ヴィジュネル暗号化方式を用いて暗号化することを特徴とする請求項４に記載のファイル配信システム。
6. 配信される前記ファイルの発信元は、該ファイルの転送に加わる前記クライアント装置のクライアント数の範囲を予め設定することを特徴とする請求項１に記載のファイル配信システム。
7. 前記ファイルを転送する前記クライアント数は、前記配信元が設定した前記クライアント数の範囲内でランダムに決定される数であることを特徴とする請求項６に記載のファイル配信システム。
8. 前記サーバは、前記報酬が支払われる場合に、該報酬を受給する前記クライアント装置に対して通知を行う支払い通知手段を有することを特徴とする請求項１に記載のファイル配信システム。
9. 前記クライアント装置は、暗号化された前記ファイルを復号化するときに、前記クライアント装置固有の情報を復号化後のファイルに付加することを特徴とする請求項２または３に記載のファイル配信システム。
10. ファイルを配信するサーバからネットワークを介して、前記ファイルの要求先のクライアント装置へ、転送にて前記ファイルを配信するファイル配信方法であって、
    前記サーバが、前記クライアント装置から前記ファイルの要求を受けると、前記要求先のクライアント装置以外の前記クライアント装置へ前記ファイルを配信する工程と、
    前記ファイルの要求先以外のクライアント装置が、前記要求先のクライアント装置へと前記ファイルを転送する工程とを有し、
    前記サーバは、前記ファイルの転送に加わった前記クライアント装置に対して報酬を支払うことを特徴とするファイル配信方法。
11. 前記サーバは、前記ファイルを転送する前記クライアント装置に対して、それぞれの前記クライアント装置毎に異なる暗号鍵を生成して送信する暗号鍵送信工程を有することを特徴とする請求項１０に記載のファイル配信方法。
12. 前記サーバから配信された、若しくは、前記クライアント装置から転送された前記ファイルは、前記サーバ若しくは転送元の前記クライアント装置が有する個別の前記暗号鍵に基づいて暗号化されることを特徴とする請求項１１に記載のファイル配信方法。
13. 前記暗号化された前記ファイルは、復号化せずに再度暗号化が可能であることを特徴とする請求項１１または１２に記載のファイル配信方法。
14. 前記ファイルは、ヴィジュネル暗号化方式を用いて暗号化することを特徴とする請求項１３に記載のファイル配信方法。
15. 配信される前記ファイルの発信元は、該ファイルの転送に加わる前記クライアント装置のクライアント数の範囲を予め設定することを特徴とする請求項１０に記載のファイル配信方法。
16. 前記ファイルを転送する前記クライアント数は、前記配信元が設定した前記クライアント数の範囲内でランダムに決定されることを特徴とする請求項１５に記載のファイル配信方法。
17. 前記サーバは、前記報酬が支払われる場合に、該報酬を受給する前記クライアント装置に対して通知を行う支払い通知工程を有することを特徴とする請求項１０に記載のファイル配信方法。
18. 前記クライアント装置は、暗号化された前記ファイルを復号化するときに、前記クライアント装置固有の情報を復号化後のファイルに付加することを特徴とする請求項１１または１２に記載のファイル配信方法。

Images