(57)【要約】【課題】配信装置のコンテンツの配信にかかる負荷を軽減すること。【解決手段】取得部１０１は、ユーザ端末３０がコンテンツ配信装置２０に対してコンテンツを要求した時刻を表す時刻情報及びそのユーザ端末３０のＩＰアドレスを取得する。特定部１０３は、取得された時刻情報に基づいて、第１端末が要求したコンテンツをその第１端末よりも先に要求した第２端末を特定する。特定部１０３は、取得されたＩＰアドレスが表す端末の所在地が他の端末よりも第１端末に近い端末を第２端末として特定する。送信部１０４は、第１端末で取得されていないパーツをその第１端末が第２端末から取得する際に用いられるデータを第１端末及び第２端末に送信する。第２要求部３０４は、送信されてきたデータを用いて、第２端末に対して、自端末が要求したコンテンツのパーツのうちまだ取得されていないものを要求する。【選択図】図７
2016197340.tif 000002
【特許請求の範囲】
【請求項１】
複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを端末が要求した時刻を表す時刻情報を取得する取得部と、
取得された前記時刻情報に基づいて、第１端末が要求した前記コンテンツを当該第１端末よりも先に要求した第２端末を特定する特定部と、
前記第１端末が自端末でまだ取得されていない前記パーツを前記配信装置でなく前記第２端末から取得する際に用いられるデータを前記第１端末及び第２端末のいずれか又は両方に送信する送信部と
を備えるサーバ装置。
【請求項２】
前記送信部は、特定された前記第２端末が自端末で取得済みの前記パーツを前記第１端末に対して送信する機能を実現するプログラムを前記データとして当該第２端末に送信する
請求項１に記載のサーバ装置。
【請求項３】
前記送信部は、前記第１端末が自端末で取得していないパーツを前記第２端末に要求する機能を実現するプログラムを前記データとして当該第１端末に送信する
請求項１又は２に記載のサーバ装置。
【請求項４】
前記第１端末及び第２端末は、ＷｅｂＲＴＣ（Web Real-Time Communication）に対応したブラウザを記憶しており、
前記コンテンツは前記ブラウザにより実現される機能によって出力され、
前記送信部は、ＷｅｂＲＴＣに準拠した端末間の通信で用いられる暗号鍵を前記データとして前記第１端末及び第２端末に送信し、当該暗号鍵を用いた通信相手のＩＰアドレスを前記データとして前記第１端末及び第２端末のいずれか又は両方に送信する
請求項１から３のいずれか１項に記載のサーバ装置。
【請求項５】
前記取得部は、前記時刻情報に加え、前記第１端末及び前記第２端末のＩＰ（Internet Protocol）アドレスを取得し、
前記特定部は、取得された前記ＩＰアドレスが表す端末の所在地が他の端末よりも前記第１端末に近い端末を前記第２端末として特定する
請求項１から４のいずれか１項に記載のサーバ装置。
【請求項６】
前記取得部は、前記時刻情報に加え、当該時刻情報が表す時刻に前記コンテンツを要求した端末と他の端末との間の通信速度に関連する第１関連情報を取得し、
前記特定部は、取得された前記第１関連情報に基づいて、前記第１端末にとって他の端末よりも前記コンテンツが早く取得される端末を前記第２端末として特定する
請求項１から５のいずれか１項に記載のサーバ装置。
【請求項７】
前記取得部は、前記時刻情報に加え、当該時刻情報が表す時刻に前記コンテンツを要求した端末と前記配信装置との間の通信速度に関連する第２関連情報を取得し、
前記特定部は、取得された前記第１及び第２関連情報に基づいて、前記第１端末にとって前記配信装置よりも前記コンテンツが早く取得される端末を前記第２端末として特定する
請求項６に記載のサーバ装置。
【請求項８】
前記配信装置は、前記複数のパーツを決められたタイムテーブルに沿って順次配信し、前記端末から前記コンテンツが要求されると、当該端末に対しては、当該要求のあった時刻に対応するパーツから順次配信し、
前記送信部は、前記第１端末がまだ取得しておらず、且つ、当該第１端末が前記コンテンツを要求した時刻とは異なる時刻に対応するパーツから順次前記第２端末から取得する際に用いられるデータを送信する
請求項１から７のいずれか１項に記載のサーバ装置。
【請求項９】
前記第１端末及び第２端末のうち少なくとも一方は、ＩＰｖ４（Internet Protocol Version 4）のＩＰアドレスを変換するゲートウェイを介した通信を前記配信装置と行い、
前記第１端末及び第２端末には、ＩＰｖ６（Internet Protocol Version 6）のＩＰアドレスが割り当てられており、
前記取得部は、前記時刻情報に加え、前記第１端末及び前記第２端末のＩＰｖ６のＩＰアドレスを取得し、
前記送信部は、前記ＩＰｖ６で表された通信相手のＩＰアドレスを前記データとして前記第１端末及び第２端末のいずれか又は両方に送信する
請求項１から８のいずれか１項に記載のサーバ装置。
【請求項１０】
前記送信部は、共通の前記第２端末が特定され且つマルチキャスト可能な複数の前記第１端末が存在する場合には、決められたマルチキャストアドレスを前記データとして当該複数の第１端末及び当該共通の第２端末に送信する
請求項１から９のいずれか１項に記載のサーバ装置。
【請求項１１】
コンピュータを、
複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを端末が要求した時刻を表す時刻情報を取得する取得部と、
取得された前記時刻情報に基づいて、第１端末が要求した前記コンテンツを当該第１端末よりも先に要求した第２端末を特定する特定部と、
前記第１端末が自端末で取得されていない前記パーツを前記配信装置でなく前記第２端末から取得する際に用いられるデータを前記第１端末及び第２端末のいずれか又は両方に送信する送信部
として機能させるためのプログラム。
【請求項１２】
端末を制御するコンピュータを、
複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを自端末が要求した時刻を表す時刻情報を、サーバ装置に送信する第１送信部と、
送信された前記時刻情報に基づいて前記サーバ装置から自端末が要求した前記コンテンツを自端末よりも後に要求した他の端末が前記パーツを取得する際に用いられるデータが送信されてくると、当該データを用いて、当該他の端末に対して、自端末からの前記要求に応答して前記配信装置から送信されてきた前記パーツを送信する第２送信部
として機能させるためのプログラム。
【請求項１３】
端末を制御するコンピュータを、
複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを自端末が要求した時刻を表す時刻情報をサーバ装置に送信する送信部と、
送信された前記時刻情報に基づいて前記サーバ装置から自端末が要求した前記コンテンツを自端末よりも先に要求した他の端末との通信に用いられるデータが送信されてくると、当該データを用いて、自端末が要求した前記コンテンツの前記パーツのうちまだ取得されていないものを、前記配信装置でなく当該他の端末に対して要求する要求部
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを配信する技術に関する。
【背景技術】
【０００２】
コンテンツを配信する技術が知られている。例えば、特許文献１には、ブラウザを搭載する端末が要求したコンテンツに含まれるメディアを、その端末の周囲に存在するＤＬＮＡ（Digital Living Network Alliance）端末で再生させる技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−４９７７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の技術では、ブラウザを搭載する端末が取得したコンテンツを再生する処理が分散されるので、その端末の処理の負荷は軽減される。一方、コンテンツを配信する装置においては、複数の端末からコンテンツを要求されればそれらに対してそれぞれコンテンツを配信することになるので、配信先の端末が増えるほど負荷も増大する。
そこで、本発明は、配信装置のコンテンツの配信にかかる負荷を軽減することを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するために、本発明は、複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを端末が要求した時刻を表す時刻情報を取得する取得部と、取得された前記時刻情報に基づいて、第１端末が要求した前記コンテンツを当該第１端末よりも先に要求した第２端末を特定する特定部と、前記第１端末が自端末でまだ取得されていない前記パーツを前記配信装置でなく前記第２端末から取得する際に用いられるデータを前記第１端末及び第２端末のいずれか又は両方に送信する送信部とを備えるサーバ装置を提供する。
【０００６】
また、前記送信部は、特定された前記第２端末が自端末で取得済みの前記パーツを前記第１端末に対して送信する機能を実現するプログラムを前記データとして当該第２端末に送信してもよい。
さらに、前記送信部は、前記第１端末が自端末で取得していないパーツを前記第２端末に要求する機能を実現するプログラムを前記データとして当該第１端末に送信してもよい。
【０００７】
また、前記第１端末及び第２端末は、ＷｅｂＲＴＣ（Web Real-Time Communication）に対応したブラウザを記憶しており、前記コンテンツは前記ブラウザにより実現される機能によって出力され、前記送信部は、ＷｅｂＲＴＣに準拠した端末間の通信で用いられる暗号鍵を前記データとして前記第１端末及び第２端末に送信し、当該暗号鍵を用いた通信相手のＩＰアドレスを前記データとして前記第１端末及び第２端末のいずれか又は両方に送信してもよい。
さらに、前記取得部は、前記時刻情報に加え、前記第１端末及び前記第２端末のＩＰ（Internet Protocol）アドレスを取得し、前記特定部は、取得された前記ＩＰアドレスが表す端末の所在地が他の端末よりも前記第１端末に近い端末を前記第２端末として特定してもよい。
【０００８】
また、前記取得部は、前記時刻情報に加え、当該時刻情報が表す時刻に前記コンテンツを要求した端末と他の端末との間の通信速度に関連する第１関連情報を取得し、前記特定部は、取得された前記第１関連情報に基づいて、前記第１端末にとって他の端末よりも前記コンテンツが早く取得される端末を前記第２端末として特定してもよい。
さらに、前記取得部は、前記時刻情報に加え、当該時刻情報が表す時刻に前記コンテンツを要求した端末と前記配信装置との間の通信速度に関連する第２関連情報を取得し、前記特定部は、取得された前記第１及び第２関連情報に基づいて、前記第１端末にとって前記配信装置よりも前記コンテンツが早く取得される端末を前記第２端末として特定してもよい。
【０００９】
また、前記配信装置は、前記複数のパーツを決められたタイムテーブルに沿って順次配信し、前記端末から前記コンテンツが要求されると、当該端末に対しては、当該要求のあった時刻に対応するパーツから順次配信し、前記送信部は、前記第１端末がまだ取得しておらず、且つ、当該第１端末が前記コンテンツを要求した時刻とは異なる時刻に対応するパーツから順次前記第２端末から取得する際に用いられるデータを送信してもよい。
【００１０】
また、前記第１端末及び第２端末のうち少なくとも一方は、ＩＰｖ４（Internet Protocol Version 4）のＩＰアドレスを変換するゲートウェイを介した通信を前記配信装置と行い、前記第１端末及び第２端末には、ＩＰｖ６（Internet Protocol Version 6）のＩＰアドレスが割り当てられており、前記取得部は、前記時刻情報に加え、前記第１端末及び前記第２端末のＩＰｖ６のＩＰアドレスを取得し、前記送信部は、前記ＩＰｖ６で表された通信相手のＩＰアドレスを前記データとして前記第１端末及び第２端末のいずれか又は両方に送信してもよい。
さらに、前記送信部は、共通の前記第２端末が特定され且つマルチキャスト可能な複数の前記第１端末が存在する場合には、決められたマルチキャストアドレスを前記データとして当該複数の第１端末及び当該共通の第２端末に送信してもよい。
【００１１】
また、本発明は、コンピュータを、複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを端末が要求した時刻を表す時刻情報を取得する取得部と、取得された前記時刻情報に基づいて、第１端末が要求した前記コンテンツを当該第１端末よりも先に要求した第２端末を特定する特定部と、前記第１端末が自端末で取得されていない前記パーツを前記配信装置でなく前記第２端末から取得する際に用いられるデータを前記第１端末及び第２端末のいずれか又は両方に送信する送信部として機能させるためのプログラムを提供する。
【００１２】
また、本発明は、端末を制御するコンピュータを、複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを自端末が要求した時刻を表す時刻情報を、サーバ装置に送信する第１送信部と、送信された前記時刻情報に基づいて前記サーバ装置から自端末が要求した前記コンテンツを自端末よりも後に要求した他の端末が前記パーツを取得する際に用いられるデータが送信されてくると、当該データを用いて、当該他の端末に対して、自端末からの前記要求に応答して前記配信装置から送信されてきた前記パーツを送信する第２送信部として機能させるためのプログラムを提供する。
【００１３】
また、本発明は、端末を制御するコンピュータを、複数のパーツを有するコンテンツを配信する配信装置に対して当該コンテンツを自端末が要求した時刻を表す時刻情報をサーバ装置に送信する送信部と、送信された前記時刻情報に基づいて前記サーバ装置から自端末が要求した前記コンテンツを自端末よりも先に要求した他の端末との通信に用いられるデータが送信されてくると、当該データを用いて、自端末が要求した前記コンテンツの前記パーツのうちまだ取得されていないものを、前記配信装置でなく当該他の端末に対して要求する要求部として機能させるためのプログラムを提供する。
【発明の効果】
【００１４】
本発明によれば、第１端末のパーツの取得先が配信装置から替わらない場合に比べて、配信装置のコンテンツの配信にかかる負荷を軽減することができる。
【図面の簡単な説明】
【００１５】
【図１】第１実施例に係るコンテンツ提供システムの全体構成を表す図
【図２】インデックスサーバ装置のハードウェア構成を表す図
【図３】コンテンツ配信装置のハードウェア構成を表す図
【図４】ユーザ端末のハードウェア構成を表す図
【図５】各装置が実現する機能構成を表す図
【図６】送信されるＨＴＭＬ文書の一例を表す図
【図７】機能追加プログラムの実行後に各装置が実現する機能構成を表す図
【図８】出力されたコンテンツの一例を表す図
【図９】蓄積部が蓄積する情報の一例を表す図
【図１０】全パーツが出力されたコンテンツの一例を表す図
【図１１】データ送信処理における動作手順の一例を表す図
【図１２】時刻情報送信処理における動作手順の一例を表す図
【図１３】パーツ取得処理における動作手順の一例を表す図
【図１４】第２実施例における機能構成を表す図
【図１５】パーツ取得処理における動作手順の一例を表す図
【図１６】第３実施例における機能構成の一例を表す図
【図１７】蓄積された第１関連情報の一例を表す図
【図１８】蓄積された第１及び第２関連情報の一例を表す図
【図１９】変形例のパーツ取得処理における動作手順の一例を表す図
【図２０】変形例におけるコンテンツ提供システムの全体構成の一例を表す図
【図２１】ライブコンテンツが配信される様子の一例を表す図
【図２２】変形例におけるコンテンツ提供システムの全体構成の一例を表す図
【図２３】変形例のパーツ取得処理における動作手順の一例を表す図
【発明を実施するための形態】
【００１６】
［１］第１実施例
図１は第１実施例に係るコンテンツ提供システム１の全体構成を表す。コンテンツ提供システム１は、Ｗｅｂページなどのコンテンツをユーザに提供するためのシステムである。コンテンツ提供システム１は、ネットワーク２と、インデックスサーバ装置１０と、コンテンツ配信装置２０と、ユーザ端末３０−１、３０−２、３０−３、３０−４（これらを区別しない場合は「ユーザ端末３０」という）とを備える。
【００１７】
ネットワーク２は、移動体通信網及びインターネットを含み、装置同士のデータのやり取りを仲介する。ネットワーク２にはインデックスサーバ装置１０、コンテンツ配信装置２０及び各ユーザ端末３０が接続される。コンテンツ配信装置２０は、Ｗｅｂページなどの複数のパーツ（画像や動画など）を有するコンテンツをユーザに配信する配信装置である。コンテンツ配信装置２０は、例えばユーザ端末３０から要求されたコンテンツのパーツを要求元のユーザ端末３０に順次送信することで、コンテンツの配信を行う。
【００１８】
ユーザ端末３０は、コンテンツを出力する機能（例えばコンテンツに含まれる画像を表示したり音を放出したりする機能）を有し、自端末に対して送信されてきたコンテンツを出力する。ユーザ端末３０は、例えばパーソナルコンピュータやスマートフォン、タブレット端末などである。図１では各ユーザ端末３０が有線でネットワーク２と接続されているように表されているが、移動体通信や無線ＬＡＮ（Local Area Network）の通信などの無線通信でネットワーク２と接続されてもよい。
【００１９】
コンテンツの送信元は、例えばコンテンツ配信装置２０であるが、それ以外にも、他のユーザ端末３０がコンテンツの送信元となる場合もある。より詳細には、コンテンツの一部のパーツはコンテンツ配信装置２０が送信元で、それ以外のパーツは他のユーザ端末３０が配信元となる場合がある。インデックスサーバ装置１０は、ユーザ端末３０が他のユーザ端末３０にコンテンツのパーツを送信したり要求したりする際に用いられるデータ（例えば送信先や要求先のユーザ端末３０のＩＰ（Internet Protocol）アドレスなど）を、それらのユーザ端末３０に送信する。各ユーザ端末３０は、このデータに基づいてコンテンツのパーツをやり取りする。
【００２０】
図２はインデックスサーバ装置１０のハードウェア構成を表す。インデックスサーバ装置１０は、制御部１１と、記憶部１２と、通信部１３とを備えるコンピュータである。制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びリアルタイムクロックを備え、ＣＰＵが、ＲＡＭをワークエリアとして用いてＲＯＭや記憶部１２に記憶されたプログラムを実行することによって各部の動作を制御する。リアルタイムクロックは、現在の日時を算出してＣＰＵに通知する。
【００２１】
記憶部１２は、ＨＤＤ（Hard disk drive）等を備え、制御部１１が制御に用いるデータやプログラムの他、自機を識別する発信器ＩＤを記憶している。通信部１３は、ネットワーク２を介した通信を行うための通信回路を備え、ネットワーク２を介してユーザ端末３０及びコンテンツ配信装置２０との間でデータの送信及び受信を行う。
【００２２】
図３はコンテンツ配信装置２０のハードウェア構成を表す。コンテンツ配信装置２０は、制御部２１と、記憶部２２と、通信部２３とを備えるコンピュータである。制御部２１、記憶部２２及び通信部２３は、図２に表された制御部１１、記憶部１２及び通信部１３と同種のハードウェアである。記憶部２２には、コンテンツであるＷｅｂページを表すＨＴＭＬ（HyperText Markup Language）文書及びそのＷｅｂページ上に表示される画像や動画などのパーツを表すパーツファイル（画像ファイルや動画ファイルなど）が記憶されている。
【００２３】
図４はユーザ端末３０のハードウェア構成を表す。ユーザ端末３０は、制御部３１と、記憶部３２と、通信部３３と、表示部３４と、操作部３５とを備えるコンピュータである。制御部３１は、図２に表された制御部１１と同種のハードウェアである。記憶部３２は、フラッシュメモリ等を備え、制御部３１が制御に用いるデータやプログラムを記憶している。本実施例では、記憶部３２には、ＷｅｂＲＴＣ（Web Real-Time Communication）に対応したブラウザのプログラムが記憶されている。ＷｅｂＲＴＣとは、ブラウザを実行する端末間でファイルを共有するためのＡＰＩ（Application Programming Interface）を定義したものである。
【００２４】
通信部３３は、ネットワーク２を介した通信（有線通信又は無線通信）を行うための通信回路を有する。表示部３４は、液晶ディスプレイ等を有し、制御部３１からの制御に基づいて画像を表示する。操作部３５は、ユーザの操作を受け付ける操作子（自端末がパーソナルコンピュータであればキーボード等、スマートフォンやタブレット端末であればタッチスクリーン等）を有する。
【００２５】
インデックスサーバ装置１０、コンテンツ配信装置２０及びユーザ端末３０の各制御部が自装置の記憶部に記憶されているプログラムを実行して自装置の各部を制御することで、以下に述べる機能が実現される。
図５は各装置が実現する機能構成を表す。インデックスサーバ装置１０は、取得部１０１と、蓄積部１０２と、特定部１０３と、送信部１０４とを備え、コンテンツ配信装置２０は、コンテンツ送信部２０１を備える。図５では、複数のユーザ端末３０のうち、偶然同じコンテンツを要求することになったユーザ端末３０ａ及びユーザ端末３０ｂが表されている（これらを区別しない場合も前述と同様に「ユーザ端末３０」という）。
【００２６】
ユーザ端末３０は、第１要求部３０１と、出力部３０２とを備える。これらの機能は、ユーザ端末３０が自端末の記憶部３２に記憶されているブラウザを実行することにより実現される機能である。なお、図５では、後から実現されるユーザ端末３０の各部（第１送信部３０３、第２要求部３０４及び第２送信部３０５）が破線で表されている。これらの各部は、ブラウザに加えてさらに別のプログラムが実行されることで実現される。以下ではこの別のプログラムのことを「機能追加プログラム」という。本実施例では、インデックスサーバ装置１０が、ブラウザとともに実行されるＪａｖａＳｃｒｉｐｔ（登録商標）を機能追加プログラムとして記憶している。
【００２７】
ユーザ端末３０の第１要求部３０１は、コンテンツ配信装置２０に対してコンテンツを要求する。コンテンツがウェブページである場合、コンテンツの要求は、まずＨＴＭＬ文書（ウェブページのレイアウトやパーツの記憶場所などが記述された文書）を要求し、その後にＨＴＭＬ文書に記述されたプログラム（ＪａｖａＳｃｒｉｐｔなど）やパーツを要求することになる。第１要求部３０１は、例えばブラウザの画面でユーザがコンテンツ配信装置２０から配信されるコンテンツ（例えばＷｅｂページ）へのリンクを選択したり、そのコンテンツのＵＲＬ（Uniform Resource Locator）を入力したりすることで、まずＨＴＭＬ文書を要求することを表すＨＴＴＰ（Hypertext Transfer Protocol）リクエストをコンテンツ配信装置２０に対して送信する。
【００２８】
コンテンツ配信装置２０のコンテンツ送信部２０１は、ユーザ端末３０から要求されたコンテンツを要求元のユーザ端末３０に対して送信する。コンテンツ送信部２０１は、まず、要求されたＨＴＭＬ文書を要求元のユーザ端末３０に対して送信する。
図６は送信されるＨＴＭＬ文書の一例を表す。この例では、前述した機能追加プログラムの記憶場所を表すＵＲＬ（本実施例ではインデックスサーバ装置１０の記憶部１２へのパスを表す）を含む記述ＰＧＭ１を含むＨＴＭＬ文書Ｂ１が表されている。
【００２９】
ＨＴＭＬ文書Ｂ１には、「ｉｍｇｅｘ」や「ｅｍｂｅｄｅｘ」という文字列と、「ＩＭＧ０１．ｇｉｆ」、「ＩＭＧ０２．ｇｉｆ」、「ＶＩＤ０１．ｍｐ４」、「ＩＭＧ０３．ｇｉｆ」、・・・、「ＩＭＧ０９．ｇｉｆ」という１０個のパーツ（９個の画像ファイル及び１個の動画ファイル）の記憶場所を表すＵＲＬ（本実施例ではいずれもコンテンツ配信装置２０の記憶部２２へのパスを表す）とを含む記述Ｃ１〜Ｃ１０が含まれている。これらはこのままではタグとして解釈されないが、後ほど機能追加プログラムの機能により「ｉｍｇ」タグや「ｅｍｂｅｄ」タグに変換されることで、画像や動画を表示するタグとして解釈されることになる。
【００３０】
ユーザ端末３０は、受信したＨＴＭＬ文書Ｂ１を自端末の第１要求部３０１及び出力部３０２に供給する。第１要求部３０１は、ＨＴＭＬ文書Ｂ１の記述を上から順番に解析し、ＵＲＬを含む記述があれば、そのＵＲＬを記憶場所とするデータを要求する。具体的には、第１要求部３０１は、ＵＲＬを含む記述のうち一番上に記述されている記述ＰＧＭ１に含まれるＵＲＬ（上記のとおりインデックスサーバ装置１０の記憶部１２へのパスを表す）を記憶場所とする機能追加プログラムを要求する。インデックスサーバ装置１０の送信部１０４は、この要求を受け取ると、要求された機能追加プログラムを要求元のユーザ端末３０に送信する。
【００３１】
第１要求部３０１は、引き続きＨＴＭＬ文書Ｂ１の記述を上から順番に解析するが、前述したように画像や動画を表示するタグが解釈されない状態になっているため、画像や動画の要求を行うことなくＨＴＭＬ文書Ｂ１の解析を終了する。ユーザ端末３０の制御部３１は、ＨＴＭＬ文書Ｂ１の解析を終了したときに、インデックスサーバ装置１０から送信されてきた機能追加プログラムを実行する。これにより、上述した第１送信部３０３、第２要求部３０４及び第２送信部３０５が実現される。
【００３２】
図７は機能追加プログラムの実行後に各装置が実現する機能構成を表す。第２要求部３０４は、記述Ｃ１〜Ｃ１０の「ｉｍｇｅｘ」という文字列を「ＩＭＧ」に変換し、「ｅｍｂｅｄｅｘ」という文字列を「ｅｍｂｅｄ」に変換する。これにより、前述したように記述Ｃ１〜Ｃ１０が画像や動画を表示するタグとして解釈されることになる。第２要求部３０４は、記述Ｃ１〜Ｃ１０のうち最も上に配置された記述Ｃ１に含まれるＵＲＬ（上記のとおりコンテンツ配信装置２０の記憶部２２へのパスを表す）を記憶場所とする「ＩＭＧ０１．ｇｉｆ」というパーツ（画像ファイル）を要求する。
【００３３】
第２要求部３０４による要求はコンテンツ配信装置２０のコンテンツ送信部２０１によって受け取られる。コンテンツ送信部２０１は、この要求を受け取ると、要求されたパーツを要求元のユーザ端末３０に送信する。ユーザ端末３０は受信したパーツを自端末の出力部３０２に供給する。出力部３０２は、自端末に送信されてきたコンテンツを出力する。本実施例では、出力部３０２は、コンテンツ送信部２０１から送信されてきたＨＴＭＬ文書Ｂ１及びパーツが表すＷｅｂページをコンテンツとして出力する。
【００３４】
図８は出力されたコンテンツの一例を表す。この例では、出力部３０２は、ＨＴＭＬ文書Ｂ１の記述Ｃ１〜Ｃ１０で表された各パーツが表示される領域Ｄ１〜Ｄ１０と、既に取得された「ＩＭＧ０１．ｇｉｆ」、「ＩＭＧ０２．ｇｉｆ」、「ＶＩＤ０１．ｍｐ４」というファイル名のパーツとを表したＷｅｂページＥ１を出力している。第２要求部３０４によるパーツの要求及びコンテンツ配信装置２０のパーツの送信が順次行われることで、出力部３０２は図８に表すＷｅｂページＥ１で空欄となっている領域Ｄ４等にもパーツを順次出力していく。このように、ＷｅｂページＥ１は、取得される順序が決まっている複数のパーツを有するコンテンツである。
【００３５】
第１送信部３０３は、自端末がコンテンツ配信装置２０に対してコンテンツを要求した時刻を表す時刻情報を、インデックスサーバ装置１０に送信する。第１送信部３０３は、例えば、機能追加プログラムが実行されて自身が動作を開始すると、ブラウザの閲覧履歴を参照し、最も新しい履歴が表す時刻を自端末がコンテンツを要求した時刻とみなし、その時刻を表す時刻情報を生成してインデックスサーバ装置１０に送信する。第１送信部３０３が送信する時刻情報が表す時刻は、例えば「○○分○○秒○○○」というように、分、秒及びミリ秒の単位が表される。
【００３６】
その後は、第１送信部３０３は、第１要求部３０１を監視して、第１要求部３０１がＨＴＭＬ文書を要求するＨＴＴＰリクエストを送信した場合に、その時刻を自端末がコンテンツを要求した時刻とみなし、その時刻を表す時刻情報を生成してインデックスサーバ装置１０に送信する。また、第１送信部３０３は、本実施例では、コンテンツを識別する識別情報として、例えばそのコンテンツのＵＲＬを時刻情報に対応付けて送信する。なお、コンテンツの識別情報は、これに限らず、例えば各コンテンツに対して割り当てられた値（ハッシュ値など）が用いられてもよい。第１送信部３０３は、送信した時刻情報を第２要求部３０４にも供給する。インデックスサーバ装置１０は、こうして送信されてきた時刻情報及びコンテンツ識別情報を受信すると、それらを取得部１０１に供給する。
【００３７】
取得部１０１は、以上のとおり供給された時刻情報、すなわちユーザ端末３０がコンテンツ配信装置２０に対してコンテンツを要求した時刻を表す情報を取得する。また、取得部１０１は、時刻情報とともに送信されてきたコンテンツ識別情報（本実施例ではＵＲＬ）と、その時刻情報を受信したときの送信元の宛先を表す宛先情報（例えばＩＰアドレス）とを取得する。取得部１０１は、取得した時刻情報、コンテンツ識別情報及び宛先情報を蓄積部１０２に供給する。蓄積部１０２は、取得部１０１から供給されたこれらの情報を蓄積する。
【００３８】
図９は蓄積部１０２が蓄積する情報の一例を表す。この例では、「ｈｔｔｐ：／／ｘｘ．・・．ｈｔｍｌ」というＵＲＬに、「ＩＰ１」から「ＩＰ４」までの４つのＩＰアドレスと、「０１：０１：０５０」、「０１：０１：８００」、「０１：０２：３００」、「０１：０４：８００」という４つの時刻情報とが対応付けて蓄積されている。蓄積部１０２は、これ以外にも、様々なＵＲＬに対応付けてＩＰアドレス及び時刻情報を蓄積する。蓄積部１０２に蓄積されている情報は特定部１０３から参照可能になっている。また、蓄積部１０２は、新たな時刻情報を蓄積すると、その時刻情報及び対応するＩＰアドレス、ＵＲＬを特定部１０３に供給する。
【００３９】
特定部１０３は、取得された時刻情報に基づいて、第１端末が要求したコンテンツをその第１端末よりも先に要求した第２端末を特定する。例えば図９に表す「０１：０４：８００」という時刻情報と、「ｈｔｔｐ：／／ｘｘ．・・．ｈｔｍｌ」というＵＲＬと、「ＩＰ４」というＩＰアドレスとが蓄積部１０２から供給されると、特定部１０３は、このＩＰアドレスが割り当てられたユーザ端末３０を第１端末とする。そして、特定部１０３は、蓄積部１０２において同じＵＲＬに対応付けられ且つ時刻情報により表される時刻が第１端末よりも先のユーザ端末３０（この例では「ＩＰ１」、「ＩＰ２」、「ＩＰ３」がそれぞれ割り当てられた３つのユーザ端末３０）のうちから第２端末を特定する。
【００４０】
特定部１０３は、本実施例では、取得されたＩＰアドレスが表す端末の所在地が他の端末よりも第１端末に近い端末を第２端末として特定する。特定部１０３は、例えば、上記の４つのＩＰアドレスから、周知の技術を用いてそれらが割り当てられた機器の所在地を推定し、「ＩＰ４」について推定した所在地と最も近い所在地を推定したＩＰアドレスが割り当てられたユーザ端末３０を、第２端末として特定する。特定部１０３は、例えば「ＩＰ４」については東京が所在地と推定し、「ＩＰ１」、「ＩＰ２」、「ＩＰ３」についてはそれぞれ北海道、神奈川、カリフォルニア州を所在地と推定した場合には、東京に最も近い神奈川を所在地と推定した「ＩＰ２」が割り当てられたユーザ端末３０を第２端末として特定する。
【００４１】
図７の例では、図５の例と同様に、同じコンテンツを要求することになったユーザ端末３０ａ及びユーザ端末３０ｂが表されているが、以下では、ユーザ端末３０ａが第１端末、ユーザ端末３０ｂが特定された第２端末であるものとして説明する。特定部１０３は、第１端末（ユーザ端末３０ａ）に割り当てられているＩＰアドレス及びそれに対応付けて蓄積されている時刻情報と、第２端末として特定したユーザ端末３０（ユーザ端末３０ｂ）に割り当てられているＩＰアドレス及びそれに対応付けて蓄積されている時刻情報とを送信部１０４に供給する。
【００４２】
送信部１０４は、第１端末が自端末でまだ取得されていないパーツをコンテンツ配信装置２０でなく第２端末から取得する際に用いられるパーツ取得用データを、第１端末及び第２端末に送信する。前述した機能追加プログラムは、パーツ取得用データの１つである（詳しくは後述する）。送信部１０４は、本発明の「サーバ装置」が備える「送信部」の一例である。送信部１０４は、機能追加プログラム以外にも、次のようなパーツ取得用データを送信する。
【００４３】
例えば第１端末が図８に表す状態までパーツを取得していれば、「ＩＭＧ０３．ｇｉｆ」から「ＩＭＧ０９．ｇｉｆ」までの７つのパーツが第１端末で取得されていないパーツとなる。送信部１０４は、本実施例では、ＷｅｂＲＴＣに準拠した端末間の通信で用いられる暗号鍵をパーツ取得用データとして第１端末及び第２端末に送信するとともに、第２端末のＩＰアドレスをパーツ取得用データとして第１端末に送信する。
【００４４】
具体的には、送信部１０４は、特定部１０３から供給された時刻情報のうち後の時刻を表している方に対応付けられているＩＰアドレス、すなわち第１端末（ユーザ端末３０ａ）のＩＰアドレスに対しては前述した暗号鍵ともう一方のＩＰアドレス、すなわち第２端末（ユーザ端末３０ｂ）のＩＰアドレスを送信し、その第２端末のＩＰアドレスに対しては前述した暗号鍵を送信する。両ユーザ端末３０は、送信部１０４から送信されてきた情報を受信すると、それらを第２要求部３０４、第２送信部３０５及び出力部３０２にそれぞれ供給する。
【００４５】
第２要求部３０４は、第１送信部３０３により送信された時刻情報に基づいてインデックスサーバ装置１０から前述したパーツ取得用データ（自端末が要求したコンテンツを自端末よりも先に要求した他の端末、すなわち特定された第２端末との通信に用いられるデータ）が送信されてくると、そのパーツ取得用データを用いて、自端末が要求したコンテンツのパーツのうち自端末で取得されていないものを、コンテンツ配信装置２０でなく第２端末に対して要求する。本実施例では、第２要求部３０４は、自端末が要求したコンテンツのパーツのうち、まだコンテンツ配信装置２０に対して要求していないものを、コンテンツ配信装置２０でなく第２端末に対して要求する。第２要求部３０４は、本発明の「要求部」の一例である。
【００４６】
第２要求部３０４は、暗号鍵のみが供給されると、自端末が第２端末であると判断してその後は動作を行わず、暗号鍵及びＩＰアドレスが供給されると、自端末が第１端末であると判断し、自端末でまだ取得されていないパーツを第２端末に要求するための動作を行う。具体的には、後者の第２要求部３０４（この例ではユーザ端末３０ａの第２要求部３０４）は、自端末の第１要求部３０１からＨＴＭＬ文書を取得し、且つ、第１要求部３０１が現在コンテンツ配信装置２０に対して要求しているパーツを確認する。
【００４７】
この第２要求部３０４は、取得したＨＴＭＬ文書において、確認したパーツの次に設置場所を表すＵＲＬが記述されているパーツ（つまり自端末がまだ取得していないパーツ）を、第２端末に対して要求する。第２要求部３０４は、例えば図６に表すＨＴＭＬ文書Ｂ１において記述Ｃ３に含まれる「ＶＩＤ０１．ｍｐ４」が現在コンテンツ配信装置２０に対して要求されているパーツとして確認されると、その下側で最初にＵＲＬを含む記述Ｃ４に記述されている「ＩＭＧ０３．ｇｉｆ」を第２端末に対して要求する。
【００４８】
第２要求部３０４は、供給された暗号鍵及びＩＰアドレスを用いて第２端末（ユーザ端末３０ｂ）とＷｅｂＲＴＣのピアコネクションを生成し、生成したピアコネクションにおいて、前述のとおり確認した自端末がまだ取得していないパーツを要求する。第２要求部３０４が行った要求は、第２端末であるユーザ端末３０ｂの第２送信部３０５によって受け取られる。
【００４９】
第２送信部３０５は、送信された時刻情報に基づいてインデックスサーバ装置１０からパーツ取得用データ（自端末が要求したコンテンツを自端末よりも後に要求した他の端末、すなわち第１端末がパーツを取得する際に用いられるデータ）が送信されてくると、そのパーツ取得用データを用いて、その第１端末に対して、自端末からの要求に応答してコンテンツ配信装置から送信されてきたパーツを送信する。
【００５０】
本実施例では、ユーザ端末３０ｂ（第２端末）の第２送信部３０５が、ユーザ端末３０ａ（第１端末）の第２要求部３０４からのパーツの要求を受け取ると、要求されたパーツが出力済みであるか否かを出力部３０２に対して問い合わせる。出力部３０２は、問い合わせを受けたパーツを既に出力していれば、出力したそのパーツを第２送信部３０５に供給する。第２送信部３０５は、供給されたパーツを、インデックスサーバ装置１０から送信されてきたデータが表す暗号鍵を用いて暗号化して、ピアコネクションが生成されたユーザ端末３０ａに対して送信する。
【００５１】
こうして送信されたパーツは、ユーザ端末３０ａの出力部３０２に供給される。ユーザ端末３０ａの出力部３０２は、第２送信部３０５から送信されてきた暗号化されたパーツを、インデックスサーバ装置１０の送信部１０４から送信されてきた暗号鍵で復号化して出力する。第２要求部３０４は、前述のとおり取得したＨＴＭＬ文書に自端末がまだ取得していないパーツの設置場所を表すＵＲＬが含まれていれば、そのパーツの要求を前述のとおり行う。
【００５２】
こうして第１端末の第２要求部３０４は、自端末がまだ取得していないパーツの要求を繰り返し行い、第２端末の第２送信部３０５は、要求された各パーツを第１端末に送信する。その結果、第１端末が要求するパーツを第２端末が全て既に取得していれば、第１端末は要求したパーツを全て第２端末から取得する。以上のとおり、第２要求部３０４及び第２送信部３０５は、第１端末が自端末でまだ取得されていないパーツをコンテンツ配信装置２０でなく第２端末から取得するための機能である。これらの機能を実現する機能追加プログラムは、この第１端末が第２端末からパーツを取得する際に用いられるデータ、すなわちパーツ取得用データである。
【００５３】
図１０は全パーツが出力されたコンテンツの一例を表す。図１０では、図６に表すＨＴＭＬ文書Ｂ１が記述したＷｅｂページＥ１が表されている。この例では、「ＩＭＧ０１．ｇｉｆ」、「ＩＭＧ０２．ｇｉｆ」及び「ＶＩＤ．ｍｐ４」という３つのパーツがコンテンツ配信装置２０から取得され、「ＩＭＧ０３．ｇｉｆ」から「ＩＭＧ０９．ｇｉｆ」までの７つのパーツが第２端末から取得されている。なお、これは一例であり、第１要求部３０１がコンテンツの要求を開始してから第２要求部３０４によるパーツの要求先の切り替え（コンテンツ配信装置２０から第２端末への切り替え）までに要する時間が長くなるほど（又は短くなるほど）、コンテンツ配信装置２０から取得されるパーツの数が多くなる（又は少なくなる）。
【００５４】
インデックスサーバ装置１０は、上記構成に基づいて、ユーザ端末３０にパーツ取得用データを送信するデータ送信処理を行う。
図１１はデータ送信処理における動作手順の一例を表す。この動作手順は、例えばユーザ端末３０がコンテンツ配信装置２０から取得したＨＴＭＬ文書に記述された機能追加プログラムをインデックスサーバ装置１０に要求してくることを契機に開始される。まず、インデックスサーバ装置１０（送信部１０４）は、要求元のユーザ端末３０に対して機能追加プログラムを送信する（ステップＳ１１）。次に、インデックスサーバ装置１０（取得部１０１）は、機能追加プログラムを実行したユーザ端末３０から送信されてくる時刻情報等（時刻情報、ＵＲＬ、ＩＰアドレス）を取得する（ステップＳ１２）。
【００５５】
インデックスサーバ装置１０（蓄積部１０２）は、取得された時刻情報等を図９に表す例のように蓄積する（ステップＳ１３）。続いて、インデックスサーバ装置１０（特定部１０３）は、蓄積された時刻情報等に基づいて、時刻情報が取得されたユーザ端末３０を第１端末とした場合の第２端末を特定する（ステップＳ１４）。そして、インデックスサーバ装置１０（送信部１０４）は、第１端末及び第２端末に対して、パーツ取得用データを送信する（ステップＳ１５）。具体的には、インデックスサーバ装置１０は、ＷｅｂＲＴＣに準拠した端末間の通信で用いられる暗号鍵をパーツ取得用データとして第２端末に送信し、その暗号鍵と第２端末のＩＰアドレスとをパーツ取得用データとして第１端末に送信する。以上でデータ送信処理の動作手順を終了する。
【００５６】
ユーザ端末３０は、上記構成に基づいて、インデックスサーバ装置１０に時刻情報等を送信する時刻情報送信処理を行う。
図１２は時刻情報送信処理における動作手順の一例を表す。この動作手順は、例えばユーザ端末３０がコンテンツ配信装置２０に対して要求したＨＴＭＬ文書を受信することを契機に開始される。まず、ユーザ端末３０（第１要求部３０１）は、受信したＨＴＭＬ文書を解析し（ステップＳ２１）、ＨＴＭＬ文書に記述された機能追加プログラムを要求して取得する（ステップＳ２２）。取得された機能追加プログラムを実行すると、ユーザ端末３０（第１送信部３０３）は、上述した時刻情報等（時刻情報の他にコンテンツのＵＲＬ、自端末のＩＰアドレス）をインデックスサーバ装置１０に送信する（ステップＳ２３）。以上で時刻情報送信処理の動作手順を終了する。
【００５７】
上述した第１端末は、コンテンツ配信装置２０及び第２端末からコンテンツのパーツを取得するパーツ取得処理を行う。
図１３はパーツ取得処理における動作手順の一例を表す。この動作手順では、まず、第２端末であるユーザ端末３０ｂが、コンテンツ配信装置２０に要求したＨＴＭＬ文書を取得し（ステップＳ３１）、図１２に表す時刻情報送信処理を行って時刻情報等をインデックスサーバ装置１０に送信する（ステップＳ３２）。次に、ユーザ端末３０ｂは、コンテンツ配信装置２０に要求したパーツを取得し（ステップＳ３３）、取得したパーツをＷｅｂページ上に出力する（ステップＳ３４）。第１端末であるユーザ端末３０ａも、ステップＳ４１からＳ４４にかけて、ステップＳ３１からＳ３４までと同様の動作を行って時刻情報等のインデックスサーバ装置１０への送信と、Ｗｅｂページ及びパーツの出力とを行う。
【００５８】
この後、各ユーザ端末３０から送信されてきた時刻情報等に基づいて第１端末に対する第２端末を特定したインデックスサーバ装置１０からパーツ取得用データが送信されてきて、ユーザ端末３０ａがそのパーツ取得用データを受信し（ステップＳ５１）、ユーザ端末３０ｂもそのパーツ取得用データを受信する（ステップＳ５２）。ユーザ端末３０ａ（第２要求部３０４）は、自端末がまだ取得していないパーツを確認し（ステップＳ５３）、パーツ取得用データである暗号鍵及びＩＰアドレスを用いて第２端末であるユーザ端末３０ｂとピアコネクションを生成する（ステップＳ５４）。
【００５９】
ユーザ端末３０ａ（第２要求部３０４）は、生成したピアコネクションを用いて未取得のパーツをコンテンツ配信装置２０でなくユーザ端末３０ｂに対して要求する（ステップＳ５５）。ユーザ端末３０ｂ（第２送信部３０５）は、ステップＳ５５で要求されたパーツを、パーツ取得用データである暗号鍵で暗号化し、要求元であるユーザ端末３０ａに送信する（ステップＳ５６）。ユーザ端末３０ａ（出力部３０２）は、受信したパーツを、パーツ取得用データである暗号鍵で復号化して出力する（ステップＳ５７）。以上でパーツ取得処理の動作手順を終了する。
【００６０】
本実施例では、上記のとおり、コンテンツ配信装置２０が配信するコンテンツのパーツが、そのパーツを先に取得したユーザ端末３０（第２端末）から、そのパーツをまだ取得していないユーザ端末３０（第１端末）に送信される。また、第１端末は、自端末がまだ取得していないパーツをコンテンツ配信装置２０でなく第２端末に対して要求する。つまり、本実施例では、第１端末のパーツの取得先が、コンテンツ配信装置２０から第２端末に替わっている。これにより、第１端末のコンテンツのパーツの取得先がコンテンツ配信装置２０から替わらない場合に比べて、コンテンツ配信装置２０のコンテンツの配信にかかる負荷を軽減することができる。
【００６１】
また、本実施例では、第１端末が未取得のパーツを第２端末に対して要求し、その要求への応答で送信されてくるパーツを取得する。つまり、第１端末は、いわゆるプル型でパーツを取得する。これにより、第１端末がまだ取得していないパーツだけが取得されることになり、例えば第１端末が既に取得されているパーツが第２端末から第１端末に送信されて通信の負荷を高めるということが生じないようにすることができる。
【００６２】
また、本実施例では、ＷｅｂＲＴＣに準拠した端末間の通信で用いられる暗号鍵をパーツ取得用データとしてインデックスサーバ装置１０が第１端末及び第２端末に対して送信した。これにより、ＷｅｂＲＴＣに対応したブラウザを記憶するユーザ端末同士のパーツのやり取りを実現することができる。また、本実施例では、ＩＰアドレスに基づいて第１端末に所在地が近いと推定されるユーザ端末３０を第２端末として特定した。通信に要する時間は端末間の距離が近いほど短くなりやすいから、本実施例によれば、所在地を考慮せずに第２端末を特定する場合に比べて、第１端末が第２端末にパーツを要求してからそのパーツが送信されてくるまでに要する時間が短くなりやすいようにすることができる。
【００６３】
［２］第２実施例
本発明の第２実施例について、以下、第１実施例と異なる点を中心に説明する。第１実施例では、第１端末が未取得のパーツを第２端末に対して要求して取得するという、いわゆるプル型のパーツの取得が行われたが、第２実施例では、第２端末が要求されなくてもパーツを送信することで第１端末がパーツを取得するという、いわゆるプッシュ型のパーツの取得が行われる。
【００６４】
図１４は第２実施例における機能構成を表す。図１４では、図７と同様の各部を備えるユーザ端末３０ａ及び３０ｂが表されている。本実施例では、インデックスサーバ装置１０の送信部１０４は、第１端末（ユーザ端末３０ａ）のＩＰアドレスに対しては暗号鍵だけを送信し、第２端末（ユーザ端末３０ｂ）に対しては、その暗号鍵と第１端末のＩＰアドレスとを送信する。両ユーザ端末３０は、送信部１０４から送信されてきた情報を受信すると、それらを自端末の第２要求部３０４、第２送信部３０５及び出力部３０２にそれぞれ供給する。
【００６５】
第２送信部３０５は、暗号鍵のみが供給されると、自端末が第１端末であると判断してその後は動作を行わず、暗号鍵及びＩＰアドレスが供給されると、自端末が第２端末であると判断して、自端末で既に取得しているパーツを第１端末に送信するための動作を行う。具体的には、後者の第２送信部３０５（ユーザ端末３０ｂの第２送信部３０５）は、自端末の出力部３０２に、現在出力しているコンテンツが有するパーツのうち取得済みのパーツを要求する。この第２送信部３０５は、その応答で出力部３０２からパーツが供給されると、第１実施例の第２要求部３０４と同様に第１端末（ユーザ端末３０ａ）とＷｅｂＲＴＣのピアコネクションを生成し、供給されたパーツを送信する。
【００６６】
ユーザ端末３０ａは、ユーザ端末３０ｂから送信されてきたパーツを受信すると、出力部３０２及び第２要求部３０４に供給する。第２要求部３０４は、コンテンツ配信装置２０に対してパーツを要求する。第２要求部３０４は、暗号鍵及びＩＰアドレスが供給されると、自端末が第２端末であると判断して、コンテンツ配信装置２０に対するパーツの要求を継続する。一方、第２要求部３０４は、暗号鍵のみが供給されると、自端末が第１端末であると判断して、ユーザ端末３０ｂから送信されてきたパーツが供給されるまでは、コンテンツ配信装置２０に対するパーツの要求を継続する。第１端末の第２要求部３０４は、第２端末からのパーツが供給されると、コンテンツ配信装置２０に対するパーツの要求を停止する。出力部３０２は、図１０に表す例のように、コンテンツ配信装置２０から取得したパーツ及び第２端末から取得したパーツをそれぞれ出力する。
【００６７】
図１５は本実施例のパーツ取得処理における動作手順の一例を表す。この例では、図１３に表すステップＳ５１及びＳ５２（パーツ取得用データの受信）までの動作が行われる。次に、ユーザ端末３０ｂ（第２送信部３０５）は、パーツ取得用データである暗号鍵及びＩＰアドレスを用いて第１端末であるユーザ端末３０ａとピアコネクションを生成し（ステップＳ６１）、生成したピアコネクションを用いて取得済みのパーツをユーザ端末３０ａに送信する（ステップＳ６２）。ユーザ端末３０ａ（出力部３０２）は、ステップＳ６２で送信されてきたパーツを出力する（ステップＳ６３）。また、ユーザ端末３０ａ（第２要求部３０４）は、ステップＳ６２で第２端末からのパーツを受信した後は、コンテンツ配信装置２０へのパーツの要求を停止する（ステップＳ６４）。本実施例では、第１端末からの要求を待つことなく第２端末がパーツをプッシュ型で第１端末に送信するので、プル型でパーツが取得される場合に比べてより早いタイミングで第１端末がパーツを出力することができる。
【００６８】
［３］第３実施例
本発明の第３実施例について、以下、第１及び第２実施例と異なる点を中心に説明する。第１及び第２実施例では、ＩＰアドレスに基づいて第２端末が特定されたが、第３実施例では、通信速度に基づいて第２端末が特定される。通信速度には、端末間の通信速度と、コンテンツ配信装置２０からのコンテンツのダウンロード速度の２つがある。
【００６９】
［３−１］端末間の通信速度
本実施例のインデックスサーバ装置１０の取得部１０１は、時刻情報に加え、その時刻情報が表す時刻にコンテンツを要求したユーザ端末３０と他のユーザ端末３０との間の通信速度に関連する第１関連情報を取得する。第１関連情報は例えば次のように取得される。
【００７０】
図１６は第３実施例における機能構成の一例を表す。この例では、ユーザ端末３０が図７に表す各部に加えて測定部３０６を備える。測定部３０６は、自端末が他のユーザ端末３０と通信を行った際の通信速度を測定する。測定部３０６には、例えば第２要求部３０４からパーツの要求を行った旨が通知され、出力部３０２からそのパーツが受信された旨が通知される。測定部３０６は、このパーツのファイルサイズと、要求の通知から受信の通知までに経過した時間とに基づいて、第２端末と自端末との間の通信速度（単位は例えばＭｂｐｓ）を測定する。
【００７１】
また、測定部３０６は、過去にパーツの通信を行っていないユーザ端末３０との間の通信速度も測定する。例えば、インデックスサーバ装置１０の特定部１０３が、ＩＰアドレスに基づいて第２端末を特定する際に、第２端末以外にも、第１端末との距離が比較的近いユーザ端末３０を、通信速度の測定対象端末として特定する。特定された測定対象端末のＩＰアドレスを送信部１０４が第１端末に送信することで、第１端末の測定部３０６が、パーツの通信とは別に、測定対象端末に対して応答を求めるパケットを繰り返し送信して、その応答に要した時間から通信速度を測定する。
【００７２】
測定部３０６は、測定した結果を第１送信部３０３に供給する。第１送信部３０３は、例えば時刻情報等とともにこの測定結果をインデックスサーバ装置１０に送信する。取得部１０１は、こうして送信されてきた測定結果を第１関連情報として取得する。蓄積部１０２は取得された第１関連情報を時刻情報とともに蓄積する。
図１７は蓄積された第１関連情報の一例を表す。図１７では、図９に表すＵＲＬ、ＩＰアドレス、時刻情報に対応付けられた第１関連情報（単位はＭｂｐｓ）が表されている。
【００７３】
この例では「ＩＰ２１」、「ＩＰ１１」、「ＩＰ１９」、「ＩＰ３２」という４つのＩＰアドレスが同じＵＲＬに対応付けられている。これらは対応する時刻情報が表す時刻の順番に並んでおり、「ＩＰ２１」の時刻が最も早く「ＩＰ３２」の時刻が最も遅いものとする。「ＩＰ２１」及び「ＩＰ１１」に対応付けられた第１関連情報として「１１０」が蓄積されている。これは、「ＩＰ２１」が割り当てられたユーザ端末３０と「ＩＰ１１」が割り当てられたユーザ端末３０との間の通信速度の測定結果が１１０Ｍｂｐｓであったことを表している。「−」は同一ユーザ端末３０同士の組み合わせなので測定ができないことを表し、「なし」は測定結果が蓄積されていないことを表している。
【００７４】
特定部１０３は、取得された第１関連情報に基づいて、第１端末にとって他の端末よりもコンテンツが早く取得される端末を第２端末として特定する。特定部１０３は、例えば図１７に表す「ＩＰ３２」が新たに蓄積されたＩＰアドレスとして供給されると、「ＩＰ２１」、「ＩＰ１１」、「ＩＰ１９」がそれぞれ割り当てられた３つのユーザ端末３０のうちから第２端末を特定する。図１７の例では、「ＩＰ３２」及び「ＩＰ１１」の組には「７０」が、「ＩＰ３２」及び「ＩＰ１９」の組には「９０」が、「ＩＰ３２」及び「ＩＰ２１」の組には「８０」が対応付けられている。つまり、「ＩＰ３２」が割り当てられたユーザ端末３０との通信速度が最も速いのは「ＩＰ１９」が割り当てられたユーザ端末３０となっている。
【００７５】
従って、特定部１０３は、「ＩＰ３２」が割り当てられたユーザ端末３０を第１端末とした場合の第２端末として、「ＩＰ１９」が割り当てられたユーザ端末３０を特定する。このようにユーザ端末３０の間の通信速度に基づいて第２端末を特定することで、この通信速度を考慮せずに第２端末を特定する場合に比べて、第１端末が第２端末にパーツを要求してからそのパーツが送信されてくるまでに要する時間を短くすることができる。
【００７６】
［３−２］ダウンロード速度
本実施例のインデックスサーバ装置１０の取得部１０１は、時刻情報に加え、その時刻情報が表す時刻にコンテンツを要求したユーザ端末３０とコンテンツ配信装置２０との間の通信速度に関連する第２関連情報を取得する。例えば図１６に表す測定部３０６が端末間の通信速度に代えてコンテンツ配信装置２０と自端末との間の通信速度を測定し、その測定結果を取得部１０１が第２関連情報として取得する。
【００７７】
特定部１０３は、取得された第１関連情報及び第２関連情報に基づいて、第１端末にとってコンテンツ配信装置２０よりもコンテンツが早く取得される端末を第２端末として特定する。
図１８は蓄積された第１及び第２関連情報の一例を表す。図１８では、図１７に表す第１関連情報に加えて第２関連情報（単位はＭｂｐｓ）が表されている。特定部１０３は、例えば図１８に表す「ＩＰ３２」が新たに蓄積されたＩＰアドレスとして供給されると、その「ＩＰ３２」に対応付けられた第１関連情報のうち、同じく「ＩＰ３２」に対応付けられた第２関連情報である「７５」Ｍｂｐｓよりも速い通信速度を表す第１関連情報に対応付けられたＩＰアドレスを抽出する。この例では、特定部１０３は、「９０」Ｍｂｐｓに対応付けられた「ＩＰ１９」と、「８０」Ｍｂｐｓに対応付けられた「ＩＰ２１」とを抽出し、それらのＩＰアドレスが割り当てられた２つのユーザ端末３０のうちから第２端末を特定する。
【００７８】
特定部１０３は、例えばこれら２つのユーザ端末３０のうちランダムで選択された方を第２端末として選択する。なお、特定部１０３は、例えば既に他のユーザ端末３０にとっての第２端末として特定されている数が少ない方を第２端末として特定してもよい。例えば「ＩＰ２１」は既に「ＩＰ１１」、「ＩＰ１９」が割り当てられたユーザ端末３０にとっての第２端末として特定されており、「ＩＰ１９」はどのユーザ端末３０の第２端末としても特定されていない場合、特定部１０３は、「ＩＰ１９」が割り当てられたユーザ端末３０を第２端末として特定する。
【００７９】
また、特定部１０３は、第２関連情報よりも速い通信速度を表す第１関連情報がない場合には、第２端末を特定しない。例えば「ＩＰ１９」が新たに蓄積されたＩＰアドレスとして供給された場合には、この「ＩＰ１９」に対応付けられた第２関連情報である「１００」Ｍｂｐｓよりも速い通信速度を表す第１関連情報がないので、特定部１０３は第２端末を特定しない。これにより、第２端末からパーツを取得したために、コンテンツ配信装置２０からパーツを取得し続ける場合に比べて第１端末がパーツを要求してからそのパーツが送信されてくるまでに要する時間が長くなる、ということが生じないようにすることができる。
【００８０】
［４］変形例
上述した各実施形態は、それぞれが本発明の実施の一例に過ぎず、以下のように変形させてもよい。また、各実施形態及び各変形例は必要に応じてそれぞれ組み合わせてもよい。
【００８１】
［４−１］プル型・プッシュ型
実施例では第１端末がプル型又はプッシュ型のいずれかでパーツを取得したが、状況に応じてプル型及びプッシュ型が使い分けられてもよい。例えば同じＵＲＬにアクセスしても、第１端末と第２端末とで取得されるパーツが異なる場合（それまでのアクセス履歴や購買履歴に応じた広告画像がコンテンツのパーツとして表示される場合など）がある。この場合に、第１端末は、まずはプッシュ型で第２端末からパーツを取得し、それでは取得されなかったパーツをプル型でコンテンツ配信装置２０から取得する。
【００８２】
図１９は本変形例のパーツ取得処理における動作手順の一例を表す。この例では、図１５に表すステップＳ６４（コンテンツ配信装置２０へのパーツの要求の停止）までの動作が行われる。次に、ユーザ端末３０ｂ（第２送信部３０５）が、自端末で取得済みのパーツの送信が終了した旨をユーザ端末３０ａに通知する（ステップＳ７１）。続いて、ユーザ端末３０ａ（第２要求部３０４）が、ＨＴＭＬ文書に記述されていたがまだ取得されていないパーツがあるか否かを判断し（ステップＳ７２）、あると判断した場合には、その未取得のパーツをコンテンツ配信装置２０に要求して取得する（ステップＳ７３）。そして、ユーザ端末３０ａ（出力部３０２）が、取得したパーツを出力する（ステップＳ７４）。この例によれば、プッシュ型では取得できなかったパーツを取得することができる。
【００８３】
［４−２］各機能を実現する装置
図５等に表す各機能は、実施例とは異なる装置によって実現されてもよい。
図２０は本変形例におけるコンテンツ提供システムの全体構成の一例を表す。図２０に表すコンテンツ提供システム１ｃは、インデックスサーバ装置１０ｃと、プログラムサーバ装置１０ｄとを備える。この例では、機能拡張プログラムがインデックスサーバ装置１０ｃではなくプログラムサーバ装置１０ｄに記憶されている。
【００８４】
プログラムサーバ装置１０ｄは、図５等に表す送信部１０４を備える。図２０の例では、ＨＴＭＬ文書に含まれる機能追加プログラムの記憶場所を表すＵＲＬがプログラムサーバ装置１０ｄの記憶部へのパスを表す。プログラムサーバ装置１０ｄの送信部１０４は、ユーザ端末３０から機能追加プログラムを要求されると、それに応答して要求元のユーザ端末３０に機能追加プログラムを送信する。この場合、インデックスサーバ装置１０ｃ及びプログラムサーバ装置１０ｄが協働して、実施例のインデックスサーバ装置１０に相当するサーバ装置として機能する。
【００８５】
なお、これ以外にも、例えば図５等に表す蓄積部１０２やパーツ取得用データを送信する送信部１０４がインデックスサーバ装置とは別のサーバ装置によって実現されてもよい。また、パーツ取得用データのうち、機能追加プログラムの送信だけを別のサーバ装置の送信部１０４が行ってもよい。例えば図６に表す記述ＰＧＭ１にＵＲＬではなくＪａｖａＳｃｒｉｐｔそのものを記述する場合、コンテンツ配信装置２０が機能追加プログラムをパーツ取得用データとして送信する送信部１０４を実現することになる。このように、インデックスサーバ装置１０が実現する各機能は、様々な装置によって実現されてもよい。いずれの場合も、それらの機能を実現する各装置が協働して、実施例のインデックスサーバ装置１０に相当するサーバ装置として機能する。
【００８６】
［４−３］機能拡張プログラム
ユーザ端末３０は、実施例や上記の変形例では機能拡張プログラムをインデックスサーバ装置やプログラムサーバ装置、コンテンツ配信装置２０から取得したが、これに限らず、機能拡張プログラムを予め記憶しておいてもよい。この機能拡張プログラムは、ユーザの操作で起動されたり、ブラウザとともに起動されたりする。この場合、機能拡張プログラムはパーツ取得用データとして送信されないが、上述した暗号鍵やＩＰアドレスがパーツ取得用データとして送信される。
【００８７】
［４−４］パーツ取得用データ
パーツ取得用データは実施例で述べたもの（機能拡張プログラム、ＷｅｂＲＴＣに準拠した暗号鍵、ＩＰアドレス）に限らない。パーツ取得用データには例えばＷｅｂＲＴＣ以外の規格に準拠した暗号鍵が含まれていてもよい。また、暗号鍵を含んでいなくてもよく、その場合は第１端末及び第２端末の間で暗号化しない通信が行われる。また、パーツ取得用データに、改ざんを防止するための情報が含まれていてもよい。例えば、インデックスサーバ装置１０の送信部１０４は、複数のパーツを含むコンテンツであるＷｅｂページのＨＴＭＬ文書内の各パーツに関する記述（図６に表す記述Ｃ１など）に基づいて各パーツに対応するハッシュ値を算出する。送信部１０４は、各パーツのファイル名とハッシュ値とを対応付けたデータをパーツ取得用データとして第１端末及び第２端末に送信する。
【００８８】
第２端末の第２送信部３０５は、第１端末にパーツを送信する際に、そのパーツに対応付けられたハッシュ値をともに送信する。第１端末の出力部３０２は、第２端末からのパーツを受け取ると、ともに送信されてきたハッシュ値が、パーツ取得用データにおいてそのパーツのファイル名に対応付けられたハッシュ値と一致していれば、パーツが改ざんされていないと判断してそのパーツを出力する。また、出力部３０２は、これらのハッシュ値が一致していない場合や、パーツだけが送信されてきてハッシュ値が送信されてこない場合には、パーツが改ざんされているおそれがあると判断してそのパーツを出力しない。これにより、改ざんされたおそれのあるパーツが出力されることを防ぐことができる。
【００８９】
［４−５］パーツ取得用データの送信先
送信部１０４は、パーツ取得用データを、実施例では第１端末及び第２端末の両方に送信したが、これに限らず、いずれか一方に送信してもよい。例えば前述した変形例のように機能拡張プログラムが予めユーザ端末３０に記憶されており、且つ、暗号化通信が行われない場合に、送信部１０４が第２端末のＩＰアドレス（この場合のパーツ取得用データ）の第１端末への送信だけを行い、第１端末が、送信されてきたＩＰアドレスを用いて第２端末からパーツをプル型で取得してもよい。また、この場合に、送信部１０４が第１端末のＩＰアドレス（この場合のパーツ取得用データ）の第２端末への送信だけを行い、第２端末がそのＩＰアドレスを用いてパーツを送信することで、第１端末がプッシュ型でパーツを取得してもよい。
【００９０】
［４−６］第１及び第２関連情報
第１及び第２関連情報は、実施例では通信速度そのものを表す情報であったが、これに限らない。例えばパケットのロス率やＰｉｎｇに対する応答時間（遅延時間）などがこれらの関連情報として用いられてもよい。要するに、通信速度に関連する情報であり、その情報に基づいて通信速度が算出又は推定できる情報であれば、どのような情報が第１及び第２関連情報として用いられてもよい。
【００９１】
［４−７］コンテンツ
実施例では複数のパーツを有するコンテンツとしてＷｅｂページを例に挙げて説明したが、コンテンツはこれに限らない。例えばＷｅｂページに含まれる動画のコンテンツは、複数のパーツ（動画を分割したデータ）を有していたり、動画中の各シーンを表す複数の画像を複数のパーツとして有していたりする。そのような動画のコンテンツの配信において本発明が適用されてもよい。また、コンテンツを表す１つのファイルを分割した分割ファイルが配信される場合には、それらの分割ファイルを複数のパーツとして扱い、本発明を適用してもよい。この場合も、第１端末のパーツの取得先がコンテンツ配信装置２０から第２端末に替わるという点では実施例と変わらないので、実施例と同様にコンテンツ配信装置２０のコンテンツの配信にかかる負荷を軽減することができる。
【００９２】
［４−８］パーツの取得先の切り替え
第１端末のパーツの取得先をコンテンツ配信装置２０から第２端末へ切り替える方法は、実施例で述べた方法に限らない。実施例では、各パーツの要求が開始される前に機能追加プログラムを実行させるために＜ｉｍｇｅｘ＞などの解釈されない文字列を用いたが、これ以外にも、例えば＜ｂｏｄｙ＞タグの前に＜ｔｅｘｔ＞タグを記述し、対応する終了タグ（＜／ｔｅｘｔ＞）を省くことで、＜ｂｏｄｙ＞タグ内の記述を解釈させないようにして機能追加プログラムを実行させてもよい。これにより、各パーツの要求が開始される前に第２要求部３０４が実現され、実施例と同様にパーツの取得先の切り替えが行われる。
【００９３】
また、通常のブラウザの機能では各パーツが順次要求されている途中にパーツの要求先を切り替えることができないが、上述した変形例のように機能拡張プログラムがユーザ端末３０に予め記憶されていれば、その機能拡張プログラムがブラウザとともに実行されることで、各パーツが順次要求されている途中に要求先を切り替える要求部（実施例の第２要求部３０４に相当する機能）が実現されるようになっていてもよい。
【００９４】
［４−９］第１端末及び第２端末
実施例では、特定部１０３が１台の第１端末に対して１台の第２端末を特定したが、これに限らない。同じコンテンツを要求したユーザ端末３０が増えてくると、特定部１０３は、複数の第１端末に対する第２端末として同じユーザ端末３０を特定することがある。また、特定部１０３は、１台の第１端末に対して複数の第２端末を特定してもよい。この場合、例えば、第１端末の第２要求部３０４が、特定された複数の第２端末に対してそれぞれパーツを要求し、第１端末の出力部３０２が、その応答で先に送信されてきたパーツを出力する。
【００９５】
また、第１端末は、他のユーザ端末３０にとっての第２端末となる場合がある。例えば図９の例であれば、ＩＰアドレスが「ＩＰ２」のユーザ端末３０は、ＩＰアドレスが「ＩＰ１」のユーザ端末３０を第２端末としたときの第１端末となり、ＩＰアドレスが「ＩＰ３」のユーザ端末３０を第１端末としたときの第２端末となるという具合である。その場合、第１端末が第２端末から取得したパーツがさらに他のユーザ端末３０によって取得されることになり、先頭のユーザ端末３０がパーツを取得してから最後尾の第１端末がそのパーツを取得するまでに時間を要することになる。
【００９６】
そこで、特定部１０３は、先頭のユーザ端末３０がコンテンツを要求した時刻から所定の時間経過したあとにそのコンテンツを要求したユーザ端末３０については第２端末を特定しないようにしてもよい。その場合、第２端末が特定されなかったユーザ端末３０は、そのコンテンツのパーツを全てコンテンツ配信装置２０から取得する。所定の時間は、コンテンツを配信するサービスにおいて配信の遅延が許容される範囲（例えば２秒〜１０秒程度）で定められればよい。
【００９７】
なお、このユーザ端末３０は、同じコンテンツを要求した他のユーザ端末３０にとっての第２端末として特定されると、先頭のユーザ端末３０となってパーツを第１端末に送信する。以上のとおり特定部１０３が第２端末を特定しないようにすることで、例えばライブ動画のように即時性を重視するコンテンツが配信される場合に、第２端末から取得したパーツがそのライブ動画におけるそのパーツの実際の配信時刻よりも所定の時間以上遅延しないようにすることができる。
【００９８】
［４−１０］ライブコンテンツの配信
コンテンツ配信装置２０は、ライブコンテンツを配信することがある。通常のコンテンツの場合、コンテンツ配信装置２０は、ユーザ端末３０から要求された時刻に関係なく、その先頭のパーツから最後のパーツまでを順次配信する。これに対し、ライブコンテンツの場合、コンテンツ配信装置２０は、そのライブコンテンツが有する複数のパーツを決められたタイムテーブルに沿って順次配信し、ユーザ端末３０からライブコンテンツが要求されると、そのユーザ端末３０に対しては、その要求のあった時刻に対応するパーツから順次配信する。
【００９９】
この場合に、送信部１０４は、第１端末がまだ取得しておらず、且つ、その第１端末がコンテンツを要求した時刻とは異なる時刻に対応するパーツから順次第２端末から取得する際に用いられるデータを、パーツ取得用データとして送信する。これについて図２１を参照して説明する。
図２１はライブコンテンツが配信される様子の一例を表す。図２１（ａ）では、ユーザ端末３０−１が時刻ｔ１にライブコンテンツを要求し、そのライブコンテンツのパーツｆ１、ｆ２、・・・、ｆ１１が順次配信されて出力される様子が表されている。つまり、時刻ｔ１はパーツｆ１に対応する時刻である。各パーツの符号を含む矩形はそのパーツが出力される時間帯を表しており、時刻ｔ１とパーツｆ１の出力の開始時刻との差は、ユーザ端末３０−１がコンテンツを要求してからコンテンツ配信装置２０からパーツｆ１が取得されるまでに要する時間を表している。
【０１００】
また、ユーザ端末３０−２がパーツｆ２に対応する時刻ｔ２にライブコンテンツを要求し、パーツｆ２、ｆ３、・・・、ｆ１１が順次出力され、ユーザ端末３０−３がパーツｆ３に対応する時刻ｔ３にライブコンテンツを要求し、パーツｆ３、ｆ４、・・・、ｆ１１が順次出力される様子が表されている。そして、ユーザ端末３０−４は、パーツｆ４に対応する時刻ｔ４にライブコンテンツを要求している。この例では、インデックスサーバ装置１０の特定部１０３は、ユーザ端末３０−１を、ユーザ端末３０−４を第１端末とした場合の第２端末として特定している。送信部１０４は、第２端末であるユーザ端末３０−１に対して、暗号鍵及びＩＰアドレスに加え、第１端末であるユーザ端末３０−４の時刻情報をパーツ取得用データとして送信する。
【０１０１】
ユーザ端末３０−１の第２送信部３０５は、送信されてきた時刻情報が表す時刻（この例ではｔ４）よりも所定の時間だけ早い時刻に対応付けられているパーツから、第１端末であるユーザ端末３０−４に対して順次送信を開始する。所定の時間としては、例えば所定の数のパーツの出力に要する時間が用いられる。所定の数が２であれば、第１端末がコンテンツを要求した時刻に対応付けられているパーツ（この例ではパーツｆ４）よりも２つ前のパーツ（この例ではパーツｆ２）から順次送信を開始する。
【０１０２】
仮にユーザ端末３０−１が、時刻情報が表す時刻ｔ４に対応するパーツｆ４からユーザ端末３０−４への送信を開始するのであれば、ユーザ端末３０−１は、取得したばかりのパーツｆ４をすぐにパーツｆ４を送信することになる。そのため、それ以降、コンテンツ配信装置２０との通信不良などでパーツの取得が遅れると、ユーザ端末３０−４のパーツの取得も遅れ、そのパーツの出力が遅延すること（前のパーツの出力が終わったのに次のパーツが出力できないということ）になる。この場合に比べると、本変形例では、上記のとおり第２端末がより早いタイミングで取得したパーツから第１端末への送信が開始されるため、第２端末におけるパーツの取得に遅延が生じても、そのパーツが第１端末で出力されるまでの時間に余裕があるので、第１端末でのパーツ出力の遅延を生じにくくすることができる。
【０１０３】
なお、本変形例では、特定部１０３が、第１端末がライブコンテンツを要求した時刻よりも前述した所定の時間以上早い時刻にそのライブコンテンツを要求した端末を第２端末として特定するようにしてもよい。これにより、ライブコンテンツの要求時刻に関係なく第２端末を特定する場合に比べて、前述の事態の発生をより確実に抑えることができる。また、第２端末の第２送信部３０５は、送信されてきた時刻情報が表す時刻よりも遅い時刻に対応付けられているパーツから順次送信を開始してもよい。ただし、その場合は、例えばそのパーツを取得した後に所定の時間が経過してから、第２送信部３０５が送信を開始する。そのため、第１端末がパーツを出力するタイミングがコンテンツ配信装置２０によるそのパーツの配信タイミングよりもその所定の時間以上遅くなるが、前述した例と同様に、第２端末で取得されたパーツが第１端末で出力されるまでの時間に余裕ができ、第１端末でのパーツ出力の遅延を生じにくくすることができる。
【０１０４】
［４−１１］ＩＰｖ４とＩＰｖ６
コンテンツ配信装置２０がＩＰｖ４（Internet Protocol Version 4）のＩＰアドレスを宛先としてコンテンツを配信する場合に、第２端末から第１端末へのパーツの送信がＩＰｖ６（Internet Protocol Version 6）のＩＰアドレスを宛先として行われてもよい。
図２２は本変形例におけるコンテンツ提供システムの全体構成の一例を表す。図２２に表すコンテンツ提供システム１ｄは、第１通信網３及び第２通信網４を備えるネットワーク２ｄと、第１通信網３に接続されるプロバイダサーバ装置５及び６とを備える。各ユーザ端末３０は、第１通信網３に接続されている。
【０１０５】
インデックスサーバ装置１０、コンテンツ配信装置２０、プロバイダサーバ装置５及び６は、いずれも、ＩＰｖ４に準拠したグローバルＩＰアドレスを有する。一方、各ユーザ端末３０は、ＩＰｖ４に準拠したグローバルＩＰアドレスを有していない。プロバイダサーバ装置５及び６は、例えばＮＡＰＴ（Network Address Port Translation）と呼ばれるネットワークアドレス変換を行うゲートウェイである。各ユーザ端末３０には、これらプロバイダサーバ装置５及び６のいずれかによってローカルＩＰアドレスが割り当てられている。
【０１０６】
そのため、ユーザ端末３０と第２通信網４に接続された装置（インデックスサーバ装置１０やコンテンツ配信装置２０）との通信は、プロバイダサーバ装置５又は６を介して行われる。このように、本変形例では、ユーザ端末３０が、ＩＰｖ４のＩＰアドレスを変換するゲートウェイを介した通信をコンテンツ配信装置２０と行う。また、各ユーザ端末３０には、ＩＰｖ６のＩＰアドレスが割り当てられているものとする。この場合に、ユーザ端末３０の第１送信部３０３は、時刻情報に加えて自端末に割り当てられたＩＰｖ６のＩＰアドレスを送信する。
【０１０７】
インデックスサーバ装置１０の取得部１０１は、時刻情報に加え、ユーザ端末３０のＩＰｖ６のＩＰアドレスを取得し、送信部１０４は、通信相手のＩＰｖ６のＩＰアドレスをパーツ取得用データとして第１端末及び第２端末に送信する。プル型のパーツの取得が行われる場合は、第１端末の第２要求部３０４が、送信されてきたＩＰｖ６のＩＰアドレスを用いて第２端末とＷｅｂＲＴＣのピアコネクションを生成する。また、プッシュ型のパーツの取得が行われる場合は、第２端末の第２送信部３０５が、送信されてきたＩＰｖ６のＩＰアドレスを用いて第１端末とＷｅｂＲＴＣのピアコネクションを生成する。
【０１０８】
通信相手のＩＰｖ４のＩＰアドレスがパーツ取得用データとして送信されてくる場合、第１端末及び第２端末間の通信は、ゲートウェイであるプロバイダサーバ装置５及び６のいずれか又は両方を介して行われることになる。これに対し、本変形例では、ＩＰｖ６のＩＰアドレスを用いて、これらのゲートウェイを介さずに第１端末及び第２端末間の通信が行われることになる。これにより、通信相手のＩＰアドレスがＩＰｖ４に準拠している場合に比べて、第２端末からパーツを取得するのに要する時間を短くすることができ、また、ゲートウェイ（プロバイダサーバ装置５及び６）の負荷を減らすことができる。
【０１０９】
［４−１２］ユニキャストとマルチキャスト
第２端末は、パーツの送信先の第１端末が１台であれば実施例のようにユニキャスト（単一の相手へのデータ送信）でパーツを送信するが、送信先の第１端末が複数である場合には、マルチキャスト（複数の相手へのデータ送信）でパーツを送信してもよい。
【０１１０】
図２３は本変形例のパーツ取得処理における動作手順の一例を表す。この例では、インデックスサーバ装置１０が、まず図１３に表すステップＳ１４（第２端末の特定）までの動作を行う。次に、インデックスサーバ装置１０（送信部１０４）は、ステップＳ１４で特定した第２端末と共通の第２端末が特定された複数の第１端末が存在するか否かを判断する（ステップＳ９１）。インデックスサーバ装置１０（送信部１０４）は、そのような複数の第１端末が存在しない（ＮＯ）と判断した場合には、ユニキャストアドレス（実施例におけるＩＰアドレスのこと）及び暗号鍵をパーツ取得用データとして第２端末に送信し（ステップＳ９２）、第１端末には暗号鍵をパーツ取得用データとして送信する（ステップＳ９３）。この例ではプッシュ型のパーツの取得が行われるものとする。
【０１１１】
インデックスサーバ装置１０（送信部１０４）は、ステップＳ９１で複数の第１端末が存在する（ＹＥＳ）と判断した場合には、それら複数の第１端末の中に、マルチキャスト可能な複数の第１端末が存在するか否かを判断し（ステップＳ９４）、存在しない（ＮＯ）と判断した場合にはステップＳ９２の動作を行う。また、インデックスサーバ装置１０は、ステップＳ９４で存在する（ＹＥＳ）と判断した場合には、本システムで用いるものとして予め用意されたマルチキャストアドレス及び暗号鍵をパーツ取得用データとして第２端末に送信する（ステップＳ９５）。
【０１１２】
インデックスサーバ装置１０（送信部１０４）は、例えば、複数の第１端末のＩＰアドレスの中に、同一ＬＡＮ内のＩＰアドレス（例えばセグメントが共通するＩＰアドレス）が複数存在していれば、それらのＩＰアドレスが割り当てられた複数の第１端末はマルチキャスト可能だと判断する。なお、マルチキャストの可否の判断は、これ以外の周知の技術を用いて行われてもよい。
【０１１３】
続いて、インデックスサーバ装置１０（送信部１０４）は、ステップＳ９４で存在すると判断した複数の第１端末（マルチキャストの対象となる複数の第１端末）に対して、ステップＳ９５で送信した暗号鍵に対応する共通の暗号鍵と、同じくステップＳ９５で送信したものと同じマルチキャストアドレスとをパーツ取得用データとして送信する（ステップＳ９６）。なお、ステップＳ９２及びＳ９３の順番、Ｓ９５及びＳ９６の順番、Ｓ９１及びＳ９４の順番は、いずれもこの例の順番に限らず、反対でもよいし同時でもよい。
【０１１４】
第１端末は、パーツ取得用データであるマルチキャストアドレスを受信すると、そのマルチキャストアドレスに送信されたデータを受信するための処理を行う。第１端末は、例えば、そのマルチキャストアドレスへのマルチキャストを待ち受けている（リッスンしている）ことをＬＡＮ内のルータに通知する。これにより、ルータは、そのマルチキャストアドレスへ送信されてきたデータを第１端末に転送するようになる。一方、第２端末は、パーツ取得用データであるマルチキャストアドレスを受信すると、そのマルチキャストアドレスに対して取得済みのパーツを送信する。
【０１１５】
以上のとおり、本変形例では、送信部１０４が、共通の第２端末が特定され且つマルチキャスト可能な複数の第１端末が存在する場合には、決められたマルチキャストアドレスをパーツ取得用データとしてそれら複数の第１端末及び共通の第２端末に送信する。これにより、常にユニキャストでパーツが送信される場合に比べて、第２端末のパーツの送信にかかる負荷を軽減することができる。例えば会場内の無線ＬＡＮに接続された多数のスマートフォンに共通のコンテンツを配信すると、第２端末が多数の第１端末にパーツを送信することが起こり得る。本変形例におけるコンテンツ提供システムは、そのような場面で特に効果を発揮する。
【０１１６】
なお、本変形例において、プル型のパーツの取得が行われてもよい。その場合は、送信部１０４が、前述した複数の第１端末のうち、例えばコンテンツの要求が最も遅かった第１端末に対して、さらに第２端末のＩＰアドレスをパーツ取得用データとして送信する。その第１端末は、受信したＩＰアドレスを用いて第２端末に対してパーツを要求し、第２端末は、この要求に応答してマルチキャストアドレスに対してパーツを送信する。この場合、第２端末のＩＰアドレスが送信されてこなかった第１端末においては、プッシュ型でのパーツの取得が行われることになる。
【０１１７】
［４−１３］時刻情報の取得方法
インデックスサーバ装置１０の取得部１０１は、実施例ではユーザ端末３０から時刻情報を取得したが、これに限らず、他の装置から時刻情報を取得してもよい。例えば、コンテンツ配信装置２０がコンテンツを要求してきたユーザ端末３０のＩＰアドレスをインデックスサーバ装置１０に送信する。取得部１０１は、このＩＰアドレスを自装置が受信した時刻をユーザ端末３０がコンテンツを要求した時刻とみなして、その時刻を表す情報を時刻情報として取得してもよい。
【０１１８】
［４−１４］発明のカテゴリ
本発明は、インデックスサーバ装置のようなサーバ装置の他、コンテンツ配信装置のような配信装置及びユーザ端末といった各装置の他、図５及び図７等に表す各機能を実現する他の装置（インデックスサーバ装置１０に相当する装置群を含む）としても捉えられる。また、それらの装置を備えるコンテンツ提供システムとしても捉えられるし、それらの装置が実施する処理を実現するための情報処理方法やそれらの装置を制御するコンピュータを機能させるためのプログラムとしても捉えられる。このプログラムは、それを記憶させた光ディスク等の記録媒体の形態で提供されてもよいし、インターネット等のネットワークを介してコンピュータにダウンロードさせ、それをインストールして利用可能にするなどの形態で提供されてもよい。
【符号の説明】
【０１１９】
１…コンテンツ提供システム、２…ネットワーク、５、６…プロバイダサーバ装置、１０…インデックスサーバ装置、１０ｄ…プログラムサーバ装置、２０…コンテンツ配信装置、３０…ユーザ端末、１１、２１、３１…制御部、１２、２２、３２…記憶部、１３、２３、３３…通信部、２４…表示部、２５…操作部、１０１…取得部、１０２…蓄積部、１０３…特定部、１０４…送信部、２０１…コンテンツ送信部、３０１…第１要求部、３０２…出力部、３０３…第１送信部、３０４…第２要求部、３０５…第２送信部、３０６…測定部
【図１】
2016197340.tif 000003
【図２】
2016197340.tif 000004
【図３】
2016197340.tif 000005
【図４】
2016197340.tif 000006
【図５】
2016197340.tif 000007
【図６】
2016197340.tif 000008
【図７】
2016197340.tif 000009
【図８】
2016197340.tif 000010
【図９】
2016197340.tif 000011
【図１０】
2016197340.tif 000012
【図１１】
2016197340.tif 000013
【図１２】
2016197340.tif 000014
【図１３】
2016197340.tif 000015
【図１４】
2016197340.tif 000016
【図１５】
2016197340.tif 000017
【図１６】
2016197340.tif 000018
【図１７】
2016197340.tif 000019
【図１８】
2016197340.tif 000020
【図１９】
2016197340.tif 000021
【図２０】
2016197340.tif 000022
【図２１】
2016197340.tif 000023
【図２２】
2016197340.tif 000024
【図２３】
2016197340.tif 000025