(57)【要約】  送信端末は、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、代表端末に対して１対１通信で情報を送信すると共に、代表端末へ送信するパケットに含まれる該パケットの送信先を示す第１のＭＡＣアドレスを、代表端末以外の受信端末でも該パケットの受信が可能な第２のＭＡＣアドレスに変換する。受信端末は、送信端末から代表端末に選択されたことが通知されると、送信端末から１対１通信で情報を受信し、送信端末から代表端末に選択されていないことが通知されると送信端末から代表端末へ送信される情報を傍受する。
2014083922.tif 000002
【特許請求の範囲】
【請求項１】
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた１対１通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換して送信する送信端末と、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信し、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する1台以上の受信端末と、
を有する情報配信システム。
【請求項２】
前記第２のＭＡＣアドレスは、ブロードキャストアドレスである請求項１記載の情報配信システム。
【請求項３】
前記第２のＭＡＣアドレスは、マルチキャストアドレスである請求項１記載の情報配信システム。
【請求項４】
前記送信端末及び前記受信端末は、
前記１対１通信と１対多通信とで用いる暗号鍵が異なり、前記１対１通信で前記情報を送受信するときに通信相手毎に異なる暗号鍵を用いる暗号化方式を使用し、
前記送信端末は、前記代表端末へ送信する情報を前記１対多通信で用いる暗号鍵で暗号化し、
前記受信端末は、前記１対多通信で用いる暗号鍵を予め備える請求項１から３のいずれか１項記載の情報配信システム。
【請求項５】
前記暗号化方式は、ＷＰＡまたはＷＰＡ２である請求項４記載の情報配信システム。
【請求項６】
前記１対１通信の通信プロトコルにＴＣＰまたはＴＣＰ／ＩＰを使用する請求項１から５のいずれか１項記載の情報配信システム。
【請求項７】
前記送信端末及び前記受信端末は、
無線通信により前記情報を送受信する請求項１から６のいずれか１項記載の情報配信システム。
【請求項８】
送信端末が、
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、
前記代表端末に対して信頼性のある通信プロトコルを用いた１対１通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換して送信し、
前記送信端末から前記情報を受信する複数の受信端末が、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信し、
前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する情報配信方法。
【請求項９】
情報を送信する送信端末または前記情報を受信する受信端末として動作する通信端末であって、
前記送信端末として動作するとき、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた１対１通信で前記情報を送信し、前記受信端末として動作するとき、前記情報を送信する送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信するコンテンツ配信制御部と、
前記送信端末として動作するとき、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換するＭＡＣアドレス変換部と、
前記受信端末として動作するとき、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受するデータパケット傍受部と、
を有する通信端末。
【請求項１０】
通信端末を、情報を送信する送信端末として動作させる、または前記情報を受信する受信端末として動作させるためのプログラムであって、
前記通信端末を前記送信端末として動作させるとき、
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択させ、
前記代表端末に対して１対１通信で前記情報を送信させると共に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換させて送信させ、
前記通信端末を前記受信端末として動作させるとき、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信させ、
前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末から他の通信端末へ情報を配信するための情報配信システム、情報配信方法、通信端末及びプログラムに関する。
【背景技術】
【０００２】
通信端末から他の通信端末へ情報を配信する方式としては、大きく分けて１対１通信と１対多通信とがある。１対１通信の代表的な通信プロトコルとしてはＴＣＰ（Transport  Control  Protocol）やＴＣＰ／ＩＰ（Internet  Protocol）が知られている。このような１対１通信で複数の通信端末に同じコンテンツを配信する場合、各通信端末に１台ずつコンテンツを送信していると、コンテンツの送信先となる通信端末数が増える程、配信に要する時間が長くなり通信効率が低下する。【０００３】
一方、１対多通信の方式としてはブロードキャスト方式とマルチキャスト方式とがある。これらの通信方式では、複数の通信端末に対して同じコンテンツを同時に配信できるため、高い通信効率でコンテンツを配信できる。しかしながら、一般的なブロードキャスト方式やマルチキャスト方式では、通信端末間で再送要求や確認応答等の制御メッセージの送受信、あるいは消失パケットの再送等を行わないため、通信の信頼性が低いという課題がある。【０００４】
また、上記のような１対多通信において、制御メッセージの送受信や消失パケットの再送等を行う場合、複数の通信端末でパケットを正常に受信できないと、それらの通信端末毎に制御メッセージの送受信やパケットの再送を行う必要がある。そのため、制御メッセージの送受信や消失パケットの再送に要する処理負荷が大きくなる問題がある。また、１対多通信では１対１通信のように輻輳制御を効果的に実施することも困難である。【０００５】
このような問題を解決するコンテンツ配信方式の一例が非特許文献１や特許文献１で提案されている。【０００６】
非特許文献１及び特許文献１には、コンテンツを配信する通信端末（送信端末）が特定の通信端末に１対１通信でコンテンツを送信し、それと同時に送信端末から特定の通信端末に送信されているコンテンツデータを他の通信端末（受信端末）にも傍受させる方法が記載されている。【０００７】
なお、電力線通信（ＰＬＣ：Power  Line  Communication）システムや無線ＬＡＮ（Local  Area  Network）等のように、通信速度の変動が激しいモデムを使用する場合でも大容量のデータをマルチキャストできるマルチキャスト通信システムが、例えば特許文献２で提案されている。特許文献２には、通信速度が変動し易いＰＬＣシステムや無線ＬＡＮ等をサブネットワークとするマルチキャスト通信システムにおけるマルチキャストパケットの転送方法について記載されている。【０００８】
上述した非特許文献１及び特許文献１に記載された技術では、特定の通信端末に対してコンテンツを１対１通信方式で送信し、それと同時に送信端末から特定の通信端末に送信されているコンテンツデータを他の通信端末にも傍受させるため、信頼性の高い通信を実現しつつ、より短い時間で効率よく複数の通信端末にコンテンツを配信できる。【０００９】
ところで、現在、多くの通信ネットワークでは、送受信するデータが第三者に不正に取得されるのを防止するため、送受信対象のデータを所定の暗号鍵を用いて符号化（暗号化）する暗号化方式が採用されている。例えば無線ＬＡＮ等では、１対多通信と１対１通信とで異なる暗号鍵を用い、さらに１対１通信において通信相手毎に異なる暗号鍵を用いるＷＰＡ（Wi-Fi  Protected  Access）やＷＰＡ２等の暗号化方式が採用されている。このような暗号化方式を採用した通信ネットワークに上記非特許文献１や特許文献１に記載された技術を適用すると、送信端末と１対１通信を行っていない通信端末は、暗号化されたコンテンツデータを傍受することになるため、該コンテンツデータを復号してコンテンツを再生する必要がある。【００１０】
しかしながら、上記非特許文献１及び特許文献１では、暗号化方式を採用した通信ネットワークにおける具体的な処理方法に何も言及していないため、送信端末と１対１通信を行っていない通信端末は、１対１通信用の暗号鍵を取得できず、コンテンツを再生することができない。すなわち、非特許文献１や特許文献１に記載された技術では、暗号化方式を採用する通信ネットワークにおいて、情報の配信を実現することが困難である。【００１１】
なお、上述したように、特許文献２にはＰＬＣシステム（または無線ＬＡＮ等）をサブネットワークとして備えるマルチキャスト通信システムが記載されている。特許文献２に記載された通信システムでは、通信速度が変動し易いＰＬＣシステムにおけるモデム間ではマルチキャストパケットをマルチキャスト通信で転送せず、送信側のモデムは一旦マルチキャストパケットをユニキャストパケットに変換してから１対１通信で受信側のモデムに転送する。さらに、特許文献２に記載された通信システムでは、該変換されたユニキャストパケットを受信した受信側のモデムをマルチキャストパケットに戻し、マルチキャストパケットを必要とする（イーサネット（登録商標）で接続された）端末に対してマルチキャスト通信で転送する。このように、ＰＬＣシステム（電力線）におけるモデム間ではマルチキャストパケットの転送を１対１通信で実現し、イーサネット（登録商標）で接続された端末に対してマルチキャストパケットをマルチキャスト通信で転送することで、マルチキャスト通信の通信速度の変動が大きいＰＬＣシステムをサブネットワークとするネットワークにおいて、適切にマルチキャストパケットを転送できる。【００１２】
しかしながら、上記特許文献２に記載された通信システムおけるマルチキャスト通信では、送信側のモデムと受信側の端末間の通信は再送機能を持たないマルチキャスト通信であるため、高い信頼性が期待できず、上記背景技術で既に述べた１対多通信（マルチキャストを含む）の課題（通信の信頼性が低い）が解決されていない。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００１−１４７８８３号公報
【特許文献２】特開２００８−１８７６２６号公報
【非特許文献】
【００１４】
【非特許文献１】鶴田  節夫、宮本捷二著、「大量データの高効率送信用簡易高信頼ブロードキャストプロトコルの提案と評価」、情報処理学会論文誌出版、1986年4月、Vol.27、No.4、pp.462−470
【発明の概要】
【００１５】
そこで、本発明は、配信効率を向上させつつ、信頼性の高い通信方式で情報を配信することが可能な情報配信システム、情報配信方法、通信端末及びプログラムを提供することを目的とする。
【００１６】
上記目的を達成するため本発明の情報配信システムは、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた１対１通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換して送信する送信端末と、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信し、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する1台以上の受信端末と、
を有する。
【００１７】
一方、本発明の情報配信方法は、送信端末が、
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、
前記代表端末に対して信頼性のある通信プロトコルを用いた１対１通信で前記情報を送信する際に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換して送信し、
前記送信端末から前記情報を受信する複数の受信端末が、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信し、
前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求する方法である。
【００１８】
本発明の通信端末は、情報を送信する送信端末または前記情報を受信する受信端末として動作する通信端末であって、
前記送信端末として動作するとき、予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択し、前記代表端末に対して信頼性のある通信プロトコルを用いた１対１通信で前記情報を送信し、前記受信端末として動作するとき、前記情報を送信する送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信するコンテンツ配信制御部と、
前記送信端末として動作するとき、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換するＭＡＣアドレス変換部と、
前記受信端末として動作するとき、前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受するデータパケット傍受部と、
を有する。
【００１９】
また、本発明のプログラムは、通信端末を、情報を送信する送信端末として動作させる、または前記情報を受信する受信端末として動作させるためのプログラムであって、
前記通信端末を前記送信端末として動作させるとき、
予め決められた選択方法にしたがって同じ情報の配信を要求する複数の受信端末のなかから代表端末を選択させ、
前記代表端末に対して１対１通信で前記情報を送信させると共に、前記情報を含む前記代表端末へ送信するパケットに含まれる前記パケットの送信先を示す第１のＭＡＣアドレスを、前記代表端末以外の受信端末でも前記パケットの受信が可能な第２のＭＡＣアドレスに変換させて送信させ、
前記通信端末を前記受信端末として動作させるとき、
前記送信端末から前記代表端末に選択されたことが通知されると、前記送信端末から前記１対１通信で前記情報を受信させ、
前記送信端末から前記代表端末に選択されていないことが通知されると、前記送信端末から前記代表端末へ送信される前記情報を傍受し、傍受できなかった情報は同一の情報を有する端末へ再度要求させるためのものである。
【図面の簡単な説明】
【００２０】
【図１】図１は、本発明の情報配信システムの一構成例を示すブロック図である。
【図２】図２は、図１に示した送信端末及び受信端末となる通信端末の一構成例を示すブロック図である。
【図３】図３は、図２に示した通信端末の情報受信時の処理手順の一例を示すフローチャートである。
【図４】図４は、図３に示したステップＡ６の処理手順の一例を示すフローチャートである。
【図５】図５は、図３に示したステップＡ７の処理手順の一例を示すフローチャートである。
【図６】図６は、図２に示した通信端末の情報送信時の処理手順の一例を示すフローチャートである。
【図７】図７は、図６に示したステップＢ５の処理手順の一例を示すフローチャートである。
【図８】図８は、本発明の情報配信システムの第１実施例の構成を示すブロック図である。
【図９】図９は、本発明の情報配信システムの第２実施例の構成を示すブロック図である。
【発明を実施するための形態】
【００２１】
次に本発明について図面を用いて説明する。
【００２２】
図１は、本発明の情報配信システムの一構成例を示すブロック図である。
【００２３】
図１に示すように、本発明の情報配信システムを適用する通信ネットワークは、情報を送信する通信端末である少なくとも１台の送信端末１と、情報を受信する通信端末である複数の受信端末１０とを有する構成である。送信端末１と受信端末１０とは、例えばＷＰＡやＷＰＡ２等の暗号化方式を採用したＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ、ＩＥＥＥ８０２．１１ｇ、ＩＥＥＥ８０２．１１ｎ等の無線通信規格に基づいて情報の送受信が可能に接続される。送信端末１と受信端末１０とは、例えば周知のＷｉ−Ｆｉ  ｄｉｒｅｃｔのように、通信端末間で直接リンクを形成する通信規格に基づいて情報の送受信が可能に接続されていてもよい。
【００２４】
以下では、本発明における配信対象を「コンテンツ」と称するが、配信対象は「情報」全般であり、特定のコンテンツに限定されるものではない。
【００２５】
図２は、図１に示した送信端末及び受信端末となる通信端末の一構成例を示すブロック図である。
【００２６】
図２に示すように、本実施形態の通信端末１００は、コンテンツ配信制御部１０１、ＭＡＣ（Media  Access  Control）アドレス変換部１０２、データパケット傍受部１０３、コンテンツ復元部１０４、ネットワーク処理部１０５、ＭＡＣ処理部１０６及びパケット送受信部１０７を備える。
【００２７】
図１に示した送信端末１及び受信端末１０は、図２に示すコンテンツ配信制御部１０１、ＭＡＣアドレス変換部１０２、データパケット傍受部１０３、コンテンツ復元部１０４、ネットワーク処理部１０５、ＭＡＣ処理部１０６及びパケット送受信部１０７を備えた通信端末１００であり、コンテンツを送信する場合は送信端末１となり、コンテンツを受信する場合は受信端末１０となる。各通信端末１００は、自端末が保有しているコンテンツの一覧（コンテンツリスト）を定期的に交換することで、通信ネットワーク内の各通信端末１００が保有しているコンテンツを互いに知ることができるものとする。コンテンツリストの交換方法は、例えば非特許文献２（Jonah  P.  Tower  and  Thomas  D.C.  Little,  “A  Proposed  Scheme  for  Epidemic  Routing  with  Active  Curing  for  Opportunistic  Networks”,  Proceeding  of  22nd  International  Conference  on  Advanced  Information  Networking  and  Applications,  2008年3月、pp.  1696-1701）に記載された技術で実現できる。非特許文献２では、各通信端末がSummary  Vectorと呼ばれる情報（共有情報のリスト）を交換することで、各通信端末で保有する情報を共有する手法が開示されている。
【００２８】
図２に示す通信端末１００は、プログラムにしたがって動作するＣＰＵ、メモリ、入出力装置、通信回路等を備えた情報処理装置としての機能を備える各種の電気機器で実現できる。通信端末１００としては、例えば携帯電話機、ＰＨＳ（Personal  Handyphone  System）、ＰＤＡ（Personal  Data  Assistance，Personal  Digital  Assistants）、ゲーム機、デジタルカメラ、ノート型やタブレット型あるいは据え置き型のパーソナルコンピュータ等が考えられる。
【００２９】
本発明の通信端末１００は、情報配信用の通信モードとして、通常モードと相乗り通信モードとを有する。通常モードとは、一般的な１対１通信で情報を送受信する通信モードであり、例えば通信プロトコルとしてＴＣＰやＴＣＰ／ＩＰを利用して通信を行う。ＴＣＰやＴＣＰ／ＩＰ等を利用する１対１通信は、当業者によく知られた技術であるため、ここではその詳細な説明を省略する。相乗り通信モードとは、送信端末１が選択した特定の受信端末１０（以下、代表端末と称す）に対して１対１通信でコンテンツデータをパケット形式で送信しつつ、同時に他の受信端末１０に同じパケットを傍受させる通信モードである。
【００３０】
本発明では、相乗り通信モードによる情報配信時、送信端末１から代表端末に１対１通信でデータパケットを送信する際に、送信端末１から代表端末へ送信するデータパケットに含まれる、該データパケットの送信先を示すＭＡＣアドレス（第１のＭＡＣアドレス）を、該代表端末以外の受信端末１０でも傍受可能なＭＡＣアドレス（第２のＭＡＣアドレス）に変換する。そのようなＭＡＣアドレスとしては、例えばブロードキャストアドレスやマルチキャストアドレスがある。また、本発明では、相乗り通信モードによる情報配信時、送信端末１から代表端末に対してデータパケットをブロードキャストやマルチキャスト等の１対多通信用の暗号鍵を用いて暗号化して送信する。送信端末１と代表端末間の１対１通信には、通常モードと同様にＴＣＰやＴＣＰ／ＩＰ等の通信プロトコルを用いる。
【００３１】
データパケットを傍受する受信端末１０は、例えば周知のＰｒｏｍｉｓｃｕｏｕｓモードで動作し、自端末のＩＰアドレス宛ではないパケットを傍受することで、所望のコンテンツのデータパケットを受信できる。データパケットを傍受した受信端末１０は、事前に配布されたブロードキャストやマルチキャスト等の１対多通信用の暗号鍵を用いてコンテンツデータを復号してコンテンツを再生する。さらに、本発明では、送信端末１が、配信するコンテンツを予め設定した所定サイズのデータブロックに分割し、該データブロック毎にコンテンツＩＤ及びブロックＩＤを付与して送信する。受信端末１０は、データブロックの傍受に失敗した場合、傍受に失敗したデータブロック単位で送信端末１に再送を要求する。
【００３２】
まず、本発明で用いる制御メッセージである、コンテンツリクエスト、コンテンツリプライ、終了メッセージ及び再送リクエストについて説明する。
【００３３】
コンテンツリクエストとは、あるコンテンツ（情報）の受信を希望する通信端末１００がそのコンテンツを保有する通信端末１００に対して該コンテンツの送信を要求するために使用するメッセージである。コンテンツリクエストには、少なくとも、送信を要求するコンテンツを識別するためのコンテンツＩＤと、該コンテンツリクエストを送信した通信端末１００を識別するためのＩＤとが含まれる。
【００３４】
コンテンツリプライとは、コンテンツを保有する通信端末１００が該コンテンツの送信を要求した通信端末１００に対して、要求されたコンテンツを送信する旨を知らせるためのメッセージである。コンテンツリプライには、少なくとも、上記代表端末を識別するためのＩＤ、あるいは代表端末のＩＰアドレスと、該コンテンツリプライを送信した通信端末１００を識別するためのＩＤと、送信対象のコンテンツを識別するためのコンテンツＩＤとが含まれる。コンテンツを保有する通信端末１００が通常モードでコンテンツデータを送信する場合、代表端末のＩＤのフィールドには、例えば全て「１」が格納される。
【００３５】
終了メッセージとは、コンテンツデータを送信する通信端末１００（送信端末１）が相乗り通信モードによるコンテンツの配信が終了したことを、コンテンツデータを受信する通信端末１００（受信端末１０）に知らせるためのメッセージである。終了メッセージには、少なくとも送信端末１を識別するためのＩＤと、送信対象のコンテンツを識別するためのコンテンツＩＤと、終了メッセージであることを示すフラグとが含まれる。
【００３６】
再送リクエストとは、コンテンツの傍受に失敗した受信端末１０が、傍受に失敗した該コンテンツのデータブロックの再送を送信端末１に要求するためのメッセージである。再送リクエストには、少なくとも、再送を要求するコンテンツを識別するためのコンテンツＩＤと、再送を要求するデータブロックのブロックＩＤと、該再送リクエストを送信する通信端末を識別するためのＩＤとが含まれる。
【００３７】
図２に示したパケット送受信部１０７は、ネットワークプロトコルで規定されたＰＨＹ層（physical  layer）を実現する。パケット送受信部１０７は、他の通信端末１００からパケットを受信すると、受信したパケットをＭＡＣ処理部１０６に出力する。また、自端末のＭＡＣ処理部１０６からパケットを受け取ると、該パケットの宛先である他の通信端末１００へ送信する。
【００３８】
ＭＡＣ処理部１０６は、ネットワークプロトコルで規定されたＭＡＣ層を実現する。ＭＡＣ処理部１０６は、ネットワーク処理部１０５からパケットを受け取ると、ＭＡＣプロトコルにしたがって所要の処理を実行し、処理後のパケットをパケット送受信部１０７に出力する。また、ＭＡＣ処理部１０６は、パケット送受信部１０７からパケットを受け取ると、ＭＡＣプロトコルにしたがって所要の処理を実行し、処理後のパケットをネットワーク処理部１０５に出力する。さらに、ＭＡＣ処理部１０６は、データパケット傍受部１０３から相乗り通信モードによるパケットの傍受指示（例えば、Ｐｒｏｍｉｓｃｕｏｕｓモードの実行命令）を受け取ると、パケット送受信部１０７で受信した自端末のＩＰアドレス宛ではないパケットをデータパケット傍受部１０３へ出力する。また、ＭＡＣ処理部１０６は、ＭＡＣアドレス変換部１０２から代表端末へ送信するパケットの送信先のＭＡＣアドレスの変換が指示されると、該指示にしたがって、代表端末へ送信するパケットに含まれる、該パケットの送信先のＭＡＣアドレスを書き換える。
【００３９】
ネットワーク処理部１０５は、ネットワークプロトコルにおけるＴＣＰまたはＴＣＰ／ＩＰ層を実現する。ネットワーク処理部１０５は、ＭＡＣ処理部１０６からパケット（制御メッセージまたはデータパケット）を受け取ると、ＴＣＰまたはＴＣＰ／ＩＰで規定された周知の処理を実行し、処理後のパケットをコンテンツ配信制御部１０１に出力する。また、ネットワーク処理部１０５は、コンテンツ配信制御部１０１からデータブロックを受け取ると、ＴＣＰまたはＴＣＰ／ＩＰにしたがって該データブロックを分割してデータパケットを生成し、生成したデータパケットをＭＡＣ処理部１０６に出力する。
【００４０】
上記ネットワーク処理部１０５、ＭＡＣ処理部１０６及びびパケット送受信部１０７の機能は、例えば通信端末１００のＯＳ（Operation  System）に含まれるカーネルで実現される。その場合、通信端末１００は、カーネルに実装されたＴＣＰ／ＩＰ、ＭＡＣ、ＰＨＹ等のネットワークプロトコルにしたがって処理を実行する。ネットワークプロトコルのＴＣＰ／ＩＰ、ＭＡＣ、ＰＨＹ等にしたがった処理は、当業者によく知られているため、ここではその詳細な説明を省略する。
【００４１】
ＭＡＣアドレス変換部１０２は、コンテンツ配信制御部１０１から相乗り通信モードでコンテンツを配信する指示を受け取った場合、代表端末へ送信するデータパケットに含まれる、該データパケットの送信先のＭＡＣアドレスを他の受信端末１０でも傍受可能なＭＡＣアドレスに変換させる。そのようなアドレスとしては、ブロードキャストアドレス（具体的には「ff-ff-ff-ff-ff-ff」）やマルチキャストアドレスがある。ＭＡＣアドレスの変換処理は、例えば周知のＡＲＰ（Address  Resolution  Protocol）技術を用いることで実現できる。ＡＲＰは、送信先のＭＡＣアドレスをＩＰアドレスから求める際に用いる、ＭＡＣアドレスとＩＰアドレスの対応関係を示す情報をＡＲＰテーブルとして保存・更新する技術である。ＡＲＰは、当業者によく知られた技術であるため、ここではその詳細な説明を省略する。
【００４２】
データパケット傍受部１０３は、コンテンツ配信制御部１０１から相乗り通信モードによるデータパケットの傍受の起動命令を受け取った場合、自端末のＩＰアドレス宛ではないパケットを受信するようＭＡＣ処理部１０６に指示する。このような傍受機能は、例えばＵＮＩＸ（登録商標）系のＯＳで提供されるパケットキャプチャー用のライブラリ（プログラム）であるＬｉｂｐｃａｐ（Ｗｉｎｄｏｗｓ（登録商標）の場合はＷｉｎｐｃａｐ等）のＰｒｏｍｉｓｃｕｏｕｓモードを起動することで実現できる。Ｐｒｏｍｉｓｃｕｏｕｓモードによるパケットの傍受は一般的な技術であるため、ここでは詳細な説明を省略する。以下では、受信端末１０がデータパケットを傍受する動作を「傍受モード」と称す。また、データパケット傍受部１０３は、ＭＡＣ処理部１０６から受け取ったデータパケットからデータブロックを組み立て、組み立てたデータブロックをコンテンツ復元部１０４に出力する。
【００４３】
コンテンツ復元部１０４は、コンテンツ配信制御部１０１またはデータパケット傍受部１０３から受け取ったデータブロックを組み立て、元のコンテンツを復元する。コンテンツを構成する全てのデータブロックが揃わない場合、コンテンツ復元部１０４は、不足するデータブロック、すなわち傍受に失敗したデータブロック（以下、傍受失敗データブロックと称す）のブロックＩＤをコンテンツ配信制御部１０１に通知する。
【００４４】
コンテンツ配信制御部１０１は、本発明のコンテンツ配信方法を実現する制御装置である。
【００４５】
自端末が送信端末１である場合、コンテンツ配信制御部１０１は、ネットワーク処理部１０５を介してコンテンツリクエストを受信すると、予め設定された所定時間（待機時間）内に到着したコンテンツリクエスト数に基づいて通常モードでコンテンツを配信するか、相乗り通信モードでコンテンツを配信するかを決定する。コンテンツ配信制御部１０１は、待機時間内に予め設定されたしきい値以上のコンテンツリクエストを受信した場合、相乗り通信モードでコンテンツを送信すると決定し、コンテンツリクエストがしきい値よりも少なければ通常モードでコンテンツを送信すると決定する。また、コンテンツ配信制御部１０１は、相乗り通信モードでコンテンツを送信すると決定した場合、予め決められた選択方法にしたがって代表端末を選択する。代表端末の選択方法としては、例えばコンテンツリクエストを送信した受信端末１０のうち、ランダムに１台の受信端末１０を代表端末として選択する方法がある。コンテンツ配信制御部１０１は、代表端末を選択すると、選択した受信端末１０のＩＤをコンテンツリプライに格納し、該コンテンツリプライをネットワーク処理部１０５からコンテンツリクエストを送信した受信端末１０にブロードキャストさせる。さらに、コンテンツ配信制御部１０１は、代表端末へ送信するパケットに含まれる、該パケットの宛先（送信先）を示すＭＡＣアドレスを他の受信端末１０でも傍受可能なＭＡＣアドレスに変換するようＭＡＣアドレス変換部１０２に指示する。そして、コンテンツ配信制御部１０１は、配信するコンテンツデータを所定サイズのデータブロックに分割し、各データブロックにコンテンツＩＤ及びブロックＩＤを付与した後、ネットワーク処理部１０６に出力する。相乗り通信モードによるコンテンツの送信が終了した場合、コンテンツ配信制御部１０１は、終了メッセージを生成して、ネットワーク処理部１０５に出力する。
【００４６】
一方、自端末が受信端末１０である場合、コンテンツ配信制御部１０１は、ネットワーク処理部１０５を介してコンテンツリプライを受け取ると、該コンテンツリプライの情報に基づいて傍受モードでコンテンツを受信すべきか否かを判定する。傍受モードでコンテンツを受信すると判定した場合、コンテンツ配信制御部１０１は、データパケットを傍受するようにデータパケット傍受部１０３に指示する。自端末が代表端末である場合、コンテンツ配信制御部１０１は、ネットワーク処理部１０５を介して受け取ったデータパケットからデータブロックを組み立て、該データブロックをコンテンツ復元部１０４に出力する。以下では、受信端末１０が代表端末としてデータパケットを受信する動作を「代表モード」と称す。自端末が傍受モードで動作中であり、相乗り通信モードの終了メッセージを受信した場合、コンテンツ配信制御部１０１は、傍受失敗データブロックがあるか否かを確認する。傍受失敗データブロックがある場合、コンテンツ配信制御部１０１は、該傍受失敗データブロックを送信端末１に再送させるための再送リクエストを生成し、該再送リクエストをネットワーク処理部１０５に出力する。
【００４７】
以下、通信端末１００がコンテンツを受信する場合とコンテンツを送信する場合とに分けて、本発明のコンテンツ配信方法について説明する。
【００４８】
まず、図２〜図５を用いて、本実施形態の通信端末１００がコンテンツを受信する場合の動作について説明する。
【００４９】
図３は、図２に示した通信端末のコンテンツ受信時の処理手順の一例を示すフローチャートである。図４は図３に示したステップＡ６の処理手順の一例を示すフローチャートであり、図５は図３に示したステップＡ７の処理手順の一例を示すフローチャートである。
【００５０】
なお、上述したように各通信端末１００は、自端末が保有しているコンテンツの一覧（コンテンツリスト）を定期的に交換することで、通信ネットワーク内の各通信端末１００で保有している情報を共有しているものとする。
【００５１】
図３に示すように、通信端末１００のユーザが、不図示の入力装置を用いて他の通信端末１００が保有するコンテンツの受信指示を入力すると、該通信端末１００のコンテンツ配信制御部１０１は、指定されたコンテンツの送信を要求するコンテンツリクエストを生成し、ネットワーク処理部１０５に出力する。
【００５２】
ネットワーク処理部１０５は、所定のプロトコル（ＴＣＰまたはＴＣＰ／ＩＰ等）にしたがってコンテンツリクエストを処理し、処理後のコンテンツリクエストをＭＡＣ処理部１０６に出力する。ＭＡＣ処理部１０６は、ＭＡＣプロトコルにしたがってコンテンツリクエストを処理し、処理後のコンテンツリクエストをパケット送受信部１０７に出力する。パケット送受信部１０７は、コンテンツを保有する、指定された通信端末１００（送信端末１）にコンテンツリクエストを送信する（ステップＡ１）。
【００５３】
パケット送受信部１０７は、送信端末１からコンテンツリプライを受信すると、該コンテンツリプライをＭＡＣ処理部１０６に出力する。
【００５４】
ＭＡＣ処理部１０６は、ＭＡＣプロトコルにしたがってコンテンツリプライを処理し、処理後のコンテンツリプライをネットワーク処理部１０５に出力する。ネットワーク処理部１０５は、所定のプロトコル（ＴＣＰまたはＴＣＰ／ＩＰ等）にしたがってコンテンツリプライを処理し、処理後のコンテンツリプライをコンテンツ配信制御部１０１に出力する。
【００５５】
コンテンツ配信制御部１０１は、コンテンツリプライを受け取ると（ステップＡ２）、該コンテンツリプライの内容を参照し、送信端末１が相乗り通信モードでコンテンツを送信するか否かを確認する（ステップＡ３）。
【００５６】
送信端末１が相乗り通信モードでコンテンツを送信しない場合、すなわちコンテンツリプライの代表端末ＩＤのフィールドが特定の値（例えば、代表端末ＩＤのフィールドが４ｂｉｔであり、その値が「１１１１」）である場合、以降、受信端末１０は通常モードでコンテンツを受信する（ステップＡ４）。
【００５７】
送信端末１が相乗り通信モードでコンテンツを送信する場合、すなわちコンテンツリプライの代表端末ＩＤのフィールドが上記特定の値以外である場合、コンテンツ配信制御部１０１は、該フィールドの値が自端末のＩＤであるか否かを確認する（ステップＡ５）。
【００５８】
コンテンツリプライの代表端末ＩＤのフィールドが自端末のＩＤと一致する場合、すなわち自端末が相乗り通信モードの代表端末に選択されている場合、受信端末１０はステップＡ６の処理へ移行し代表モードとして動作する。ステップＡ６において、受信端末１０は、例えば図４に示す手順にしたがって処理を実行する。
【００５９】
ステップＡ６において、受信端末１０は、パケット送受信部１０７によりパケットを受信すると、受信したパケットをＭＡＣ処理部１０６及びネットワーク処理部１０５を介してコンテンツ配信制御部１０１に出力する（ステップＡ８）。
【００６０】
コンテンツ配信制御部１０１は、ネットワーク処理部１０５からパケットを受け取ると、受け取ったパケットがデータパケットであるか否か（制御メッセージではないこと）を確認し、データパケットの場合は該データパケットからデータブロックを組み立て、該データブロックをコンテンツ復元部１０４に出力する（ステップＡ９）。
【００６１】
コンテンツ復元部１０４は、コンテンツ配信制御部１０１から全てのデータブロックを受け取ると、コンテンツを復元して処理を終了する（ステップＡ１０）。
【００６２】
ステップＡ５において、コンテンツリプライの代表端末ＩＤのフィールドが自端末のＩＤと一致しない場合、すなわち自端末が相乗り通信モードの代表端末に選択されていない場合、コンテンツ配信制御部１０１は、データパケット傍受部１０３にデータパケットを傍受モードで受信するよう指示する。
【００６３】
データパケット傍受部１０３は、コンテンツ配信制御部１０１から傍受モードの起動命令を受け取ると、自端末のＩＰアドレス宛ではないパケットを受信するようＭＡＣ処理部１０６に指示する。具体的には、上記ＬｉｂｐｃａｐやＷｉｎｐｃａｐ等のＰｒｏｍｉｓｃｕｏｕｓモードの受信プログラムを起動することで、自端末のＩＰアドレス宛ではないパケットを受信させる。
【００６４】
続いて、受信端末１０は、ステップＡ７の処理へ移行し、例えば図５に示す手順にしたがって処理を実行する。
【００６５】
ステップＡ７において、受信端末１０は、パケット送受信部１０７でパケットを受信すると、受信したパケットをＭＡＣ処理部１０６に出力する。ＭＡＣ処理部１０６は、受け取ったパケットをＭＡＣプロトコルにしたがって処理し、処理後のパケットをコピーしてデータパケット傍受部１０３に出力する（ステップＡ１１）。
【００６６】
データパケット傍受部１０３は、受け取ったパケットが自端末から送信を要求したコンテンツのデータパケットであるか否かを確認する。具体的には、パケットの宛先ＭＡＣアドレスがブロードキャストアドレスであり、かつ宛先ＩＰアドレスが代表端末のＩＰアドレスと一致しており、かつ送信元ＩＰアドレスがコンテンツリクエストを送信した送信端末１のＩＰアドレスと一致しており、かつＩＰヘッダのプロトコル番号がＴＣＰ（６）である場合、受け取ったパケットが自端末から送信を要求したコンテンツのデータパケットである可能性が高いと判定する。
【００６７】
受け取ったパケットが送信を要求したコンテンツのデータパケットである場合、データパケット傍受部１０３は、受信したパケットのＴＣＰヘッダにある宛先ポート番号と送信元ポート番号の組が一致するデータパケット群毎に該データパケットからデータブロックを組み立て、組み立てたデータブロックのコンテンツＩＤが送信を要求したコンテンツＩＤと一致する場合はコンテンツ復元部１０４に出力する。このとき、データブロックを構成する全てのデータパケットを受信できなかった場合、データパケット傍受部１０３は、データブロックを組み立てられないため、データブロックをコンテンツ復元部１０４に出力しない。
【００６８】
受け取ったパケットが送信を要求したコンテンツのデータパケットでない場合、あるいは該データパケットのコピーを既に受け取っている場合、データパケット傍受部１０３は、ＭＡＣ処理部１０６から受け取ったパケットを廃棄する。
【００６９】
また、コンテンツ配信制御部１０１は、パケット送受信部１０７、ＭＡＣ処理部１０６、ネットワーク処理部１０５を介してパケットを受け取ると、該受信したパケットが終了メッセージであるか否かを確認する（ステップＡ１２）。
【００７０】
受信したパケットが終了メッセージでない場合、コンテンツ配信制御部１０１は、ステップＡ１１の処理に戻って、データパケット傍受部１０３に引き続き傍受モードでデータパケットを受信させる。
【００７１】
受信したパケットが終了メッセージの場合、コンテンツ配信制御部１０１は、コンテンツ復元部１０４にデータパケット傍受部１０３で受信したデータブロックを用いてコンテンツを復元させる。このとき、コンテンツ配信制御部１０１は、傍受失敗データブロックがあるか否かを確認する（ステップＡ１３)。傍受失敗データブロックがあるか否かは、例えばコンテンツを構成するデータブロックが不足する場合、例えば受信したブロックＩＤが連続値でない場合に傍受失敗データブロックがあると判定する。
【００７２】
傍受失敗データブロックが無い場合、コンテンツ配信制御部１０１は、受信したデータブロックを組み立て、コンテンツ復元部１０４にコンテンツを復元させて（ステップＡ１４）処理を終了する。
【００７３】
一方、傍受失敗データブロックがある場合、コンテンツ配信制御部１０１は、コンテンツ復元部１０４に傍受失敗データブロックの情報を通知させる。コンテンツ配信制御部１０１は、コンテンツ復元部１０４から傍受失敗データブロックの情報が通知されると、該傍受失敗データブロックの再送を要求するための再送リクエストを生成し、該再送リクエストを、ネットワーク処理部１０５、ＭＡＣ処理部１０６及びパケット送受信部１０７を介して送信端末１に送信する（ステップＡ１５）。再送リクエストの送信処理は、図３で示したステップＡ１におけるコンテンツリクエストの送信手順と同様であるため、ここではその説明を省略する。
【００７４】
受信端末１０は、送信端末から再送された全ての傍受失敗データブロックを受信すると（ステップＡ１６）、コンテンツ配信制御部１０１によりデータブロックを組み立て、コンテンツ復元部１０４にコンテンツを復元させて処理を終了する。なお、傍受失敗データブロックは、ＴＣＰやＴＣＰ／ＩＰ等の既存の通信プロトコルを用いて再送してもよく、相乗り通信モードで再送してもよい。相乗り通信モードで傍受失敗データブロックを再送する場合、図５に示すステップＡ１６の処理は、本実施形態の通信端末１００におけるコンテンツの受信処理（ステップＡ１〜ステップＡ１６）と同様である。
【００７５】
次に、図２及び図６〜図７を用いて、本実施形態の通信端末１００がコンテンツを送信する場合の動作について説明する。
【００７６】
図６は図２に示した通信端末のコンテンツ送信時の処理手順の一例を示すフローチャートであり、図７は図６に示したステップＢ５の処理手順の一例を示すフローチャートである。
【００７７】
図６に示すように、送信端末１がパケット送受信部１０７によりコンテンツリクエストを受信すると、該コンテンツリクエストはＭＡＣ処理部１０６及びネットワーク処理部１０５を介してコンテンツ配信制御部１０１に出力される（ステップＢ１）。
【００７８】
コンテンツ配信制御部１０１は、予め設定された所定時間以内に受信したコンテンツリクエストのうち、異なる端末ＩＤを含むコンテンツリクエスト数をカウントすることで、同一コンテンツの受信を希望する通信端末１００が予め設定されたしきい値以上であるか否かを確認する（ステップＢ２）。
【００７９】
同一コンテンツの受信を希望する通信端末１００数がしきい値よりも少ない場合、送信端末１は、コンテンツリプライの代表端末ＩＤのフィールドに特定の値（例えば「１１１１」）を格納し、受信端末１０宛に該コンテンツリプライを送信した後、ＴＣＰやＴＣＰ／ＩＰ等（通常モード）にしたがってコンテンツを受信端末１０に送信する（ステップＢ３）。この場合、送信端末１は、受信端末１０がコンテンツを構成する全てのデータブロックの受信を完了するまでＴＣＰやＴＣＰ／ＩＰ等にしたがってコンテンツを配信する。
【００８０】
コンテンツの受信を希望する通信端末１００数がしきい値以上である場合、送信端末１は、コンテンツ配信制御部１０１により相乗り通信モードでコンテンツを送信すると決定し、コンテンツリクエストを送信した受信端末１０から予め決められた選択方法にしたがって代表端末を選択する（ステップＢ４）。
【００８１】
代表端末を選択すると、送信端末１は、ステップＢ５の処理に移行して相乗り通信モードでコンテンツを送信する。ステップＢ５において、送信端末１は、例えば図７に示す手順にしたがって処理を実行する。
【００８２】
送信端末１が相乗り通信モードでコンテンツを送信する場合、コンテンツ配信制御部１０１は、代表端末として選択した受信端末１０の端末ＩＤをコンテンツリプライの代表端末ＩＤのフィールドに格納し、該代表端末ＩＤを含むコンテンツリプライをネットワーク処理部１０５、ＭＡＣ処理部１０６及びパケット送受信部１０７を介してコンテンツリクエストを送信した全ての受信端末１０にブロードキャストする（ステップＢ６）。
【００８３】
コンテンツ配信制御部１０１は、コンテンツリプライをネットワーク処理部１０５に出力すると、代表端末へ送信するパケットに含まれる、該パケットの宛先を示すＭＡＣアドレスを他の受信端末１０でも傍受可能なＭＡＣアドレス（例えば、ブロードキャストアドレス）に変換するようＭＡＣアドレス変換部１０２に指示する。ＭＡＣアドレス変換部１０２は、コンテンツ配信制御部１０１の指示にしたがってＭＡＣアドレスの変換処理を実行する（ステップＢ７）。
【００８４】
以降、送信端末１は、ＴＣＰやＴＣＰ／ＩＰ等の通信プロトコルにしたがって代表端末にコンテンツを送信する（ステップＢ８)。代表端末に対するコンテンツの送信が終了すると、送信端末１は、終了メッセージをブロードキャストし、傍受中の全ての受信端末１０にコンテンツの配信終了を通知する（ステップＢ９）。終了メッセージの送信処理は、図３で示したステップＡ１におけるコンテンツリクエストの送信手順と同様であるため、ここではその説明を省略する。
【００８５】
次に、送信端末１は、コンテンツ配信制御部１０１により予め設定された所定時間内に代表端末以外の受信端末１０（傍受中の受信端末）から再送リクエストを受信したか否かを確認する（ステップＢ１０）。
【００８６】
傍受中の受信端末１０から再送リクエストを受信しなかった場合、送信端末１は処理を終了する。
【００８７】
傍受中の受信端末１０から再送リクエストを受信した場合、送信端末１は再送リクエストを送信した受信端末１０に対して要求されたデータブロックを再送する（ステップＢ１１）。なお、傍受失敗データブロックは、ＴＣＰやＴＣＰ／ＩＰ等の既存の通信プロトコルを用いて再送してもよく、相乗り通信モードで再送してもよい。相乗り通信モードで傍受失敗データブロックを再送する場合、図７に示すステップＢ１１の処理は、本実施形態の通信端末１００におけるコンテンツの送信処理（ステップＢ１〜ステップＢ１１）と同様である。
【００８８】
上述したように、本発明では、相乗り通信モードにおけるコンテンツ配信時、送信端末１から代表端末に１対１通信でコンテンツのデータパケットを送信すると共に、該データパケットを他の受信端末１０でも傍受できるように送信端末１によって該データパケットの送信先を示すＭＡＣアドレスを、例えばブロードキャストアドレスやマルチキャストアドレスに変換する。また、本発明では、相乗り通信モードによるコンテンツの配信時、送信端末１から代表端末に対してコンテンツのデータパケットをブロードキャストやマルチキャスト等の１対多通信用の暗号鍵を用いて暗号化して送信する。送信端末１と代表端末間の１対１通信には、通常モードと同様にＴＣＰやＴＣＰ／ＩＰ等の通信プロトコルを用いる。
【００８９】
さらに、本発明では、コンテンツのデータパケットを傍受する受信端末１０が、例えばＰｒｏｍｉｓｃｕｏｕｓモードで動作し、自端末のＩＰアドレスを宛先としないパケットであっても受信することで、所望のコンテンツのデータパケットを傍受できる。データパケットを傍受した受信端末１０は、事前に配布されたブロードキャストやマルチキャスト等の１対多通信用の暗号鍵を用いてコンテンツデータを復号してコンテンツを再構築する。また、本発明では、受信端末１０がコンテンツのデータブロックの傍受に失敗した場合、該受信端末１０は、傍受に失敗したデータブロック単位で送信端末１に再送を要求し、該再送要求にしたがって送信端末１から傍受失敗データブロックを受信できる。
【００９０】
そのため、本発明によれば、ＷＰＡやＷＰＡ２等のように、１対多通信と１対１通信とで用いる暗号鍵が異なり、１対１通信においても通信相手毎に異なる暗号鍵を用いる暗号化方式を使用した通信ネットワークであっても、送信端末１から代表端末へ、例えばＴＣＰまたはＴＣＰ／ＩＰのような信頼性の高いトランスポートプロトコルを用いてコンテンツを配信しつつ、同一のコンテンツを他の受信端末１０でも受信させることができる。
【００９１】
したがって、配信効率を向上させつつ、信頼性の高い通信方式によりコンテンツを配信することが可能になる。
【００９２】
なお、本実施形態では、送信端末１と代表端末間の１対１通信にＴＣＰやＴＣＰ／ＩＰを用いる例を示したが、送信端末１と代表端末間の通信プロトコルはＴＣＰやＴＣＰ／ＩＰに限定されるものではなく、再送機能を追加したＵＤＰ（User  Datagram  Protocol）等、他の信頼性の高い通信プロトコルを用いてもよい。
【００９３】
また、本実施形態では、送信端末１が相乗り通信モードでコンテンツを配信する場合に１台の代表端末を固定的に選択する例を示したが、送信端末１は、複数台の代表端末を選択してもよい。その場合、例えば所定量のコンテンツデータを送信する毎に代表端末を変更すればよい。
【００９４】
さらに、本実施形態では、各通信端末１００が無線通信によりコンテンツを送受信する例を示したが、通信端末１００間は有線通信によりコンテンツを送受信してもよい。
【００９５】
また、本実施形態では、送信端末１から受信端末１０にコンテンツを直接送信する例で説明したが、送信端末１と受信端末１０間には、送信端末１と受信端末１０間で送受信する情報を中継する各種の中継装置（ルータ、ブリッジやアクセスポイント等）が挿入されていてもよい。その場合、受信端末１０と通信する中継装置に、図２に示したコンテンツ配信制御部１０１、ＭＡＣアドレス変換部１０２、データパケット傍受部１０３、コンテンツ復元部１０４、ネットワーク処理部１０５、ＭＡＣ処理部１０６及びパケット送受信部１０７の機能を備えていてもよい。
【００９６】
また、本実施形態では、送信端末１が代表端末との通信終了を他の受信端末１０へ通知するために終了メッセージを使用する例を示したが、送信端末１と代表端末との通信終了は終了メッセージを使用しなくても代表端末以外の受信端末１０で知ることが可能である。例えば、代表端末以外の受信端末１０は、代表端末が送信端末１から最終のデータブロックを受信したことを検出した場合に、送信端末１と代表端末間の通信が終了すると判断してもよい。あるいは、代表端末以外の受信端末１０は、送信端末１と代表端末間の通信レート及び残りの通信データサイズを計算し、その計算結果に基づいて送信端末１と代表端末間の通信が終了する時刻を推測し、該推測した時刻が過ぎた時点（タイムアウト）で通信終了と判断してもよい。
【００９７】
また、本実施形態では、各受信端末１０がコンテンツを１台の送信端末から受信する例で示したが、受信端末１０はコンテンツを受信する通信端末１００を変更してもよい。例えば、傍受モードによる１回目の処理サイクルにおけるコンテンツデータの傍受が終了し、傍受失敗データブロックの再送を要求する場合、再送を要求する通信端末１００は、最初にコンテンツの送信を要求した通信端末１００である必要はなく、当該コンテンツを保有する他の通信端末１００に再送を要求してもよい。
【００９８】
さらに、本実施形態では、コンテンツリプライを用いて代表端末のＩＤ（もしくはＩＰアドレス）を受信端末１０に通知し、受信端末１０が該代表端末のＩＤのフィールドの値に基づいて、通常モード、代表モードまたは傍受モードで受信処理を実行する例を示したが、代表端末のＩＤ（もしくはＩＰアドレス）等は予め設けた専用の制御メッセージを用いて受信端末１０に通知してもよい。その場合、コンテンツリプライには、受信端末１０からのコンテンツリクエストを送信端末１が正しく受信できたことを通知する働きを持たせればよい。
【実施例】
【００９９】
次に本発明の実施例について図面を用いて説明する。
（第１実施例）
図８は、本発明のコンテンツ配信システムの第１実施例の構成を示すブロック図である。【０１００】
第１実施例のコンテンツ配信システムは、送信端末１１、受信端末１０１及び受信端末１０２を有する構成である。送信端末１１、受信端末１０１及び受信端末１０２は、例えばＷＰＡやＷＰＡ２等の暗号化方式を採用する通信ネットワークを構成する。【０１０１】
以下では、送信端末１１がコンテンツＡを保有し、受信端末１０１及び１０２が該コンテンツＡを受信するものとする。また、コンテンツリクエストの待機時間を１００ｍｓとし、相乗り通信モードで動作するか否かを判定するためのコンテンツリクエスト数のしきい値を「２」とする。さらに、代表端末は、コンテンツリクエストを送信した受信端末１０のなかから１台の受信端末１０をランダムに選択するものとする。また、受信端末１０１のＩＤを「０００１」とし、受信端末１０２のＩＤを「００１０」とする。また、受信端末１０１のＩＰアドレスは「１９２．１６８．０．１０１」とする。【０１０２】
まず、送信端末１１から受信端末１０１及び１０２へコンテンツを配信する場合の動作について説明する。【０１０３】
受信端末１０１及び受信端末１０２は、ユーザによって受信を希望するコンテンツＡが指定されると、送信端末１１にコンテンツＡの送信を要求するコンテンツリクエストを送信する（図３のステップＡ１）。送信端末１１は、受信端末１０１及び１０２から送信されたコンテンツリクエストを受信する（図６のステップＢ１）。ここでは、送信端末１１が、待機時間である１００ｍｓ以内に受信端末１０１及び受信端末１０２からそれぞれコンテンツリクエストを受信したものとする。【０１０４】
送信端末１１は、コンテンツリクエスト数がしきい値「２」以上であるため、相乗り通信モードでコンテンツを送信することを決定し、受信端末１０１及び１０２からランダムに１台の代表端末を選択する（図６のステップＢ４）。ここでは受信端末１０１を代表端末として選択する。また、送信端末１１は、相乗り通信モードでコンテンツを送信することを受信端末１０１及び１０２に通知するため、代表端末ＩＤ「０００１」を含むコンテンツリプライをブロードキャストする（図７のステップＢ６）。【０１０５】
受信端末１０１は、送信端末１１からコンテンツリプライを受信すると（図３のステップＡ２）、コンテンツが相乗り通信モードで配信されるか否かを確認する（図３のステップＡ３）。ここでは受信したコンテンツリプライに含まれる代表端末ＩＤのフィールドが特定の値（例えば、「１１１１」）ではないため、受信端末１０１は、送信端末１１が相乗り通信モードでコンテンツを配信すると判定する。また、受信端末１０１は、コンテンツリプライに含まれる代表端末ＩＤのフィールドの値が自端末のＩＤと一致するため、自端末が代表端末に選択されたと判定する（図３のステップＡ５）。以降、受信端末１０１は、代表モードで動作して送信端末１から送信されるコンテンツを受信する（図３のステップＡ６）。【０１０６】
一方、受信端末１０２は、送信端末１１からコンテンツリプライを受信すると（図３のステップＡ２）、コンテンツが相乗り通信モードで配信されるか否かを確認する（図３のステップＡ３）。ここでは受信したコンテンツリプライに含まれる代表端末ＩＤのフィールドが特定の値（例えば、「１１１１」）ではないため、受信端末１０２は、送信端末１１が相乗り通信モードでコンテンツを配信すると判定する。また、受信端末１０２は、コンテンツリプライに含まれる代表端末ＩＤのフィールドの値が自端末のＩＤと一致しないため、自端末が代表端末ではないと判定する（図３のステップＡ５）。以降、受信端末１０２は、傍受モードで動作して送信端末１から受信端末１０１に送信されるコンテンツを傍受する（図３のステップＡ７）。【０１０７】
送信端末１１は、コンテンツの配信時、代表端末（受信端末１０１）へ送信するデータパケットの宛先を示すＭＡＣアドレスを、代表端末（受信端末１０１）のＭＡＣアドレスからブロードキャストアドレスに変換する。具体的に、ＭＡＣアドレスは、ＯＳのコマンドを用いて変換できる。例えば、送信端末１１がＷｉｎｄｏｗｓ（登録商標）端末の場合、コマンドプロンプト等で「arp  -s    192.168.0.101    FF-FF-FF-FF-FF-FF」を実行することで、受信端末１０１へ送信するデータパケットの宛先を示すＭＡＣアドレスをブロードキャストアドレスに変換できる（図７のステップＢ７）。この結果、受信端末１０２は送信端末１１から受信端末１０１へ送信されるデータパケットを傍受できるようになる。【０１０８】
ここで、送信端末１１が、コンテンツＡをデータブロックＡ１とデータブロックＡ２とに分割したとする。この場合、送信端末１１は、代表端末である受信端末１０１に対してＴＣＰ／ＩＰを用いてデータブロックＡ１を少なくとも１つのデータパケットに分割して送信を開始する（図７のステップＢ８）。【０１０９】
受信端末１０１は、送信端末１１からデータブロックＡ１のデータパケットを受信すると（図４のステップＡ８）、受信したデータパケットからデータブロックＡ１を組み立てる（図４のステップＡ９）。【０１１０】
受信端末１０２は、送信端末１１が受信端末１０１に送信したデータパケットを傍受モードで受信し、受信したデータパケットからデータブロックＡ１を組み立てる（図５のステップＡ１１）。【０１１１】
続いて、送信端末１１は、データブロックＡ２のデータパケットを受信端末１０１に送信し、受信端末１０１は受信したデータパケットからデータブロックＡ２を組み立てる。ここでは、受信端末１０２が、通信環境の劣化等により送信端末１１から送信されたデータブロックＡ２を正常に受信できなかったものとする。【０１１２】
この場合、受信端末１０１は、全てのデータブロックが揃っているため、コンテンツＡを復元する（図４のステップＡ１０）。この段階で、送信端末１１は、コンテンツＡの全データブロックを代表端末である受信端末１０１に送信し終わったため、終了メッセージをブロードキャストし、相乗り通信モードによるコンテンツの配信終了を受信端末１０２にも知らせる（図７のステップＢ９）。【０１１３】
終了メッセージを受信した受信端末１０２は、相乗り通信モードの終了を検知すると（図５のステップＡ１２）、傍受失敗データブロックがあるか否かを確認する（図５のステップＡ１３）。ここでは、データブロックＡ２の傍受を失敗しているため、受信端末１０２はデータブロックＡ２を再送するよう送信端末１１に再送リクエストを送信する（図５のステップＡ１５）。【０１１４】
送信端末１１は、受信端末１０２からデータブロックＡ２の再送要求を受信すると、受信端末１０２に要求されたデータブロックＡ２を再送する（図７のステップＢ１１）。【０１１５】
受信端末１０２は、送信端末１１から再送されたデータブロックＡ２を受信し（図５のステップＡ１６）、データブロックＡ１及びＡ２が揃った時点でそれらを組み立ててコンテンツＡを復元する。【０１１６】
このようにして、送信端末１１は受信端末１０１及び１０２に対するコンテンツの配信を終了する。
（第２実施例）
図９は、本発明のコンテンツ配信システムの第２実施例の構成を示すブロック図である。【０１１７】
図９に示すように、第２実施例のコンテンツ配信システムは、コンテンツを送信する通信端末である送信端末２と、コンテンツを受信する通信端末である複数台の受信端末２０と、送信端末２と受信端末２０間で送受信されるデータを中継するブリッジであるアクセスポイント３０とを有する。【０１１８】
第２実施例のコンテンツ配信システムは、送信端末２と受信端末２０間にアクセスポイント３０が挿入される点で第１実施例のコンテンツ配信システムと異なっている。送信端末２及び受信端末２０の構成、並びに動作は、第１実施例の送信端末１１、並びに受信端末１０１及び１０２と同様であるため、その説明は省略する。送信端末２とアクセスポイント３０間は無線通信で情報の送受信が可能に接続されていてもよく、有線通信で情報の送受信が可能に接続されていてもよい。【０１１９】
なお、図９に示す第２実施例のコンテンツ配信システムでは、アクセスポイント３０に、図２に示したコンテンツ配信制御部１０１、ＭＡＣアドレス変換部１０２、データパケット傍受部１０３、コンテンツ復元部１０４、ネットワーク処理部１０５、ＭＡＣ処理部１０６及びパケット送受信部１０７の機能を備えていてもよい。【０１２０】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されものではない。本願発明の構成や詳細は本願発明のスコープ内で当業者が理解し得る様々な変更が可能である。【０１２１】
この出願は、２０１２年１１月３０日に出願された特願２０１２−２６２９３３号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2014083922.tif 000003
【図２】
2014083922.tif 000004
【図３】
2014083922.tif 000005
【図４】
2014083922.tif 000006
【図５】
2014083922.tif 000007
【図６】
2014083922.tif 000008
【図７】
2014083922.tif 000009
【図８】
2014083922.tif 000010
【図９】
2014083922.tif 000011
【国際調査報告】
2014083922.tif 000012
2014083922.tif 000013
2014083922.tif 000014
2014083922.tif 000015