(57)【要約】      （修正有）【課題】大容量のストレージを用いずにコンテンツの再生遅延を低減する。【解決手段】ネットワーク上のコンテンツの位置を示すコンテンツ位置情報の取得要求に基づいて、リクエストを送信するリクエスト送信部１０１と、レスポンスに対する処理を規定したレスポンス処理ルールを記憶するレスポンス処理ルール記憶部１０３と、前記リクエストに対応したレスポンスを受信し、受信したレスポンスに基づいて前記レスポンス処理ルール記憶部を検索し、前記レスポンス処理ルールから、前記受信したレスポンスに対応する処理を検出し、検出した処理として、リダイレクトの続行、リダイレクトの停止、及び新規リクエストの生成のいずれか１つを実行し、前記リダイレクトの停止を実行する場合は、前記受信したレスポンスから前記コンテンツ位置情報を取得して送信するレスポンス受信部１０２と、を備える通信装置。【選択図】図１
2010160610.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ配信ネットワークを構成する同一のコンテンツを保持した複数のサーバのうち、いずれか１つのサーバの位置が記載された、前記コンテンツの配信を行うサーバの位置を示すコンテンツ位置情報の取得要求を受信し、前記取得要求に位置が記載された前記サーバに対する前記コンテンツ位置情報の通知を要求するリクエストを構築する第１制御部と、
前記第１制御部が構築した前記リクエストを前記取得要求に位置が記載された前記サーバへ送信するリクエスト送信部と、
前記サーバから送信される、前記リクエストに対する応答であり、この応答の意味を表すステータスコードを含むレスポンスを受信するレスポンス受信部と、
前記前記レスポンスに記載された情報と、レスポンス受信後の処理としてのリクエストの再送信又はコンテンツ位置情報の生成との対応関係が規定されたレスポンス処理ルールを記憶するルール記憶部と、
前記レスポンス受信部が受信したレスポンスに記載された情報に対応するレスポンス処理ルールを前記ルール記憶部から検出し、検出したレスポンス処理ルールが、前記リクエストの再送信である場合は、前記送信先とは異なるサーバを再送信先として生成した前記リクエストの再送信要求、もしくは前記送信先と同一のサーバで異なるパラメータを付与した前記リクエストの再送信要求を前記第１制御部へ通知し、検出したレスポンス処理ルールが、前記コンテンツ位置情報の生成である場合は、前記レスポンスに記載された情報から前記コンテンツ位置情報を生成し、前記取得要求の送信元へ送信する第２制御部と、
を備える通信装置。
【請求項２】
前記第２制御部は、検出したレスポンス処理ルールが、前記リクエストの再送信である場合、前記受信したレスポンスのヘッダに記載されたサーバの位置を前記再送信先として前記第１制御部へ通知し、
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先へのリクエストを構築し、
前記リクエスト送信部は、前記第１制御部が構築したリクエストを前記再送信先へ送信することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第２制御部は、検出したレスポンス処理ルールが、前記リクエストの再送信である場合、前記受信したレスポンスのボディを解析し、解析により得られた文字列を用いて前記再送信先を生成して前記第１制御部へ通知し、
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先へのリクエストを構築し、
前記リクエスト送信部は、前記第１制御部が構築したリクエストを前記再送信先へ送信することを特徴とする請求項１に記載の通信装置。
【請求項４】
前記リクエストの送信先、及び前記リクエストを送信したコネクションを識別する接続識別情報を記憶するコンテンツ情報記憶部をさらに備え、
前記第１制御部は、前記取得要求に基づいて前記リクエストの送信先及び前記接続識別情報を前記コンテンツ情報記憶部へ出力し、
前記レスポンス受信部は、前記レスポンスを受信したコネクションの接続識別情報を前記第２制御部へ出力し、
前記第２制御部は、前記レスポンス受信部から通知された前記接続識別情報を用いて前記コンテンツ情報記憶部を検索し、前記レスポンスに対応するリクエストの送信先を検出し、検出した送信先を用いて前記ルール記憶部からレスポンス処理ルールを検出することを特徴とする請求項１に記載の通信装置。
【請求項５】
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先への第２のリクエストを構築し、前記リクエスト送信部による前記第２のリクエストの送信に伴い、前記コンテンツ情報記憶部に記憶されている前記送信先及び前記接続識別情報を、前記再送信先及び前記第２のリクエストを送信したコネクションを識別する接続識別情報に更新することを特徴とする請求項４に記載の通信装置。
【請求項６】
前記第２制御部は、検出したレスポンス処理ルールが、前記リクエストの再送信である場合、前記受信したレスポンスのヘッダに記載されたサーバの位置を前記再送信先として前記第１制御部へ通知し、
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先への第２のリクエストを構築し、前記リクエスト送信部による前記第２のリクエストの送信に伴い、前記コンテンツ情報記憶部に記憶されている前記送信先及び前記接続識別情報を、前記再送信先及び前記第２のリクエストを送信したコネクションを識別する接続識別情報に更新することを特徴とする請求項４に記載の通信装置。
【請求項７】
前記第２制御部は、検出したレスポンス処理ルールが、前記リクエストの再送信である場合、前記受信したレスポンスのボディを解析し、解析により得られた文字列を用いて前記再送信先を生成して前記第１制御部へ通知し、
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先への第２のリクエストを構築し、前記リクエスト送信部による前記第２のリクエストの送信に伴い、前記コンテンツ情報記憶部に記憶されている前記送信先及び前記接続識別情報を、前記再送信先及び前記第２のリクエストを送信したコネクションを識別する接続識別情報に更新することを特徴とする請求項４に記載の通信装置。
【請求項８】
前記第２制御部は、前記受信したレスポンスから前記コンテンツ位置情報と共にこのコンテンツ位置情報の有効期限を取得して送信し、
前記第２制御部から送信される前記コンテンツ位置情報及び前記有効期限を記憶するコンテンツ位置情報記憶部をさらに備え、
前記コンテンツ位置情報記憶部は、前記取得要求を受信し、前記取得要求に対応する前記有効期限が切れていないコンテンツ位置情報を記憶している場合はコンテンツ位置情報を前記取得要求の送信元へ送信し、前記取得要求に対応する前記有効期限が切れていないコンテンツ位置情報を記憶していない場合は前記取得要求を前記第１制御部へ送信することを特徴とする請求項１に記載の通信装置。
【請求項９】
前記第２制御部は、検出したレスポンス処理ルールが、前記リクエストの再送信である場合、前記受信したレスポンスのヘッダに記載されたサーバの位置を前記再送信先として前記第１制御部へ通知し、
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先へのリクエストを構築し、
前記リクエスト送信部は、前記第１制御部が構築したリクエストを前記再送信先へ送信することを特徴とする請求項８に記載の通信装置。
【請求項１０】
前記第２制御部は、検出したレスポンス処理ルールが、前記リクエストの再送信である場合、前記受信したレスポンスのボディを解析し、解析により得られた文字列を用いて前記再送信先を生成して前記第１制御部へ通知し、
前記第１制御部は、前記第２制御部からの通知に基づいて前記再送信先へのリクエストを構築し、
前記リクエスト送信部は、前記第１制御部が構築したリクエストを前記再送信先へ送信することを特徴とする請求項８に記載の通信装置。
【請求項１１】
ユーザの視聴するコンテンツを予測し、予測したコンテンツについて前記コンテンツ位置情報の取得要求を前記第１制御部へ送信し、前記第２制御部から送信される前記コンテンツ位置情報を受信するアプリケーションをさらに備えることを特徴とする請求項１に記載の通信装置。
【請求項１２】
コンテンツ配信ネットワークを構成する、同一のコンテンツを保持した複数のサーバのうち、いずれか１つのサーバの位置が記載された、前記コンテンツの配信を行うサーバの位置を示すコンテンツ位置情報の取得要求を受信し、
前記取得要求に位置が記載された前記サーバに対する前記コンテンツ位置情報の通知を要求するリクエストを構築し、
前記リクエストを前記取得要求に位置が記載された前記サーバへ送信し、
前記リクエストを受信したサーバから送信される、前記リクエストに対する応答であり、この応答の意味を表すステータスコードを含むレスポンスを受信し、
前記レスポンスに記載された情報と、レスポンス受信後の処理としてのリクエストの再送信又はコンテンツ位置情報の生成との対応関係が規定されたレスポンス処理ルールを記憶するルール記憶部から前記受信したレスポンスに対応するレスポンス処理ルールを検出し、
検出したレスポンス処理ルールが、前記リクエストの再送信である場合は、前記リクエストの送信先とは異なるサーバを再送信先として生成して、前記再送信先へリクエストを再送信し、
検出したレスポンス処理ルールが、前記コンテンツ位置情報の生成である場合は、前記レスポンスに記載された情報から前記コンテンツ位置情報を生成し、前記取得要求の送信元へ送信する、
通信方法。
【請求項１３】
コンテンツ配信ネットワークを構成する、同一のコンテンツを保持した複数のサーバのうち、いずれか１つのサーバの位置が記載された、前記コンテンツの配信を行うサーバの位置を示すコンテンツ位置情報の取得要求を受信するステップと、
前記取得要求に位置が記載された前記サーバに対する前記コンテンツ位置情報の通知を要求するリクエストを構築するステップと、
前記リクエストを前記取得要求に位置が記載された前記サーバへ送信するステップと、
前記リクエストを受信したサーバから送信される、前記リクエストに対する応答であり、この応答の意味を表すステータスコードを含むレスポンスを受信するステップと、
前記レスポンスに記載された情報と、レスポンス受信後の処理としてのリクエストの再送信又はコンテンツ位置情報の生成との対応関係が規定されたレスポンス処理ルールを記憶するルール記憶部から前記受信したレスポンスに対応するレスポンス処理ルールを検出するステップと、
検出したレスポンス処理ルールが、前記リクエストの再送信である場合は、前記リクエストの送信先とは異なるサーバを再送信先として生成して、前記再送信先へリクエストを再送信するステップと、
検出したレスポンス処理ルールが、前記コンテンツ位置情報の生成である場合は、前記レスポンスに記載された情報から前記コンテンツ位置情報を生成し、前記取得要求の送信元へ送信するステップと、
をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法、及びプログラムに関するものである。
【背景技術】
【０００２】
ユーザからアップロードされた動画を他のユーザと共有することを目的とした動画共有サイトでは、ユーザが撮影した動画や企業の広告などが共有され、配信される。動画共有サイトのコンテンツは、ＣＤＮ（Contents Delivery Network）を用いて配信されることが多い。動画共有サイトをウェブブラウザ等で閲覧し、ウェブブラウザ上でコンテンツを視聴する場合でも、コンテンツだけはＣＤＮを介してウェブブラウザ上の動画再生プラグインに配信される。
【０００３】
ＣＤＮは、映像、音楽等のコンテンツを分散配置し、配信するネットワークである。例えば、１つのコンテンツが複製されて、複数の異なるキャッシュサーバに配置される。ＣＤＮは、ユーザからのアクセスがあると、ユーザのアクセスの集中度合いや、物理的・ネットワーク構成的に最も効率よくユーザへの送信を行えるキャッシュサーバからコンテンツを送信する。従って、同じコンテンツであっても、常に同じキャッシュサーバから送信されるわけではなく、アクセスするユーザやアクセスする時間帯、地域によって、コンテンツを送信するキャッシュサーバが異なる場合がある。
【０００４】
ＣＤＮでは、ある特定のユーザが同一コンテンツを同一のサーバで視聴できる期間に制限を設けている場合が多い。従って、同じコンテンツへ再度アクセスがあった場合、ＣＤＮが再度別のキャッシュサーバに割り振る。これを実現するために、ＣＤＮではセッション制御を行っている。コンテンツ配信にＨＴＴＰ（Hypertext Transfer Protocol）が使われることが多いことから、ＣＤＮは、有効期限付きのセッションＩＤを発行し、セッションＩＤを伴ったリクエストに対してのみコンテンツを配信することで、ユーザからの無制限のアクセスを防止している。
【０００５】
ＣＤＮ及び動画共有サイトでアクセスしてきたクライアントを別のウェブサーバに誘導するＨＴＴＰの機能としてリダイレクトがある（例えば非特許文献１参照）。ＨＴＴＰサーバは、アクセスしてきたＨＴＴＰクライアントに対して、３００番台のステータスコードを持ち、Ｌｏｃａｔｉｏｎヘッダに誘導先のＵＲＬを指定したレスポンスを送信する。このレスポンスを受け取ったＨＴＴＰクライアントは、Ｌｏｃａｔｉｏｎヘッダに記載されているＵＲＬへ再度アクセスする。
【０００６】
通常、ウェブブラウザ等のＨＴＴＰクライアントは、自動的にリダイレクト先へアクセスし、ＨＴＴＰサーバから３００番台以外のステータスコードを持つレスポンスが返されるまで、リダイレクトを繰り返す。
【０００７】
このように、ＣＤＮによって、処理負荷に余裕があり、かつ、ユーザに物理的・ネットワーク構成的に近い位置にあるキャッシュサーバが自動的に選択される。そのため、１つのサーバに負荷が集中しなくなり、効率的な配信が可能になるとともに、ユーザがサーバからの応答を待つ時間が短縮された。
【０００８】
しかし、このような方式を用いてもユーザがコンテンツを選択してからコンテンツが再生されるまでには遅延がある。例えば、ユーザからのリクエストに対して適切なキャッシュサーバを選択し、リダイレクトによってユーザの端末をキャッシュサーバに誘導するのに要する時間が遅延の要因となる。
【０００９】
キャッシュサーバにリダイレクトされるのに要する時間には、ＣＤＮの負荷分散機能によってユーザからのリクエストに対して割り当てるキャッシュサーバの選択や、リダイレクトされたクライアントが再度ＨＴＴＰリクエストを送信する際のＤＮＳによる名前解決などの、クライアント等の処理遅延や、ネットワークそのものの遅延が含まれる。
【００１０】
ＣＤＮにおける再生遅延をユーザに意識させないために、従来からコンテンツ視聴アプリケーションにはユーザが視聴する可能性のあるコンテンツの一部もしくは全体をあらかじめダウンロードして保存しておく「プリフェッチ」が広く実装されている。
【００１１】
プリフェッチは、再生遅延の縮小に効果的ではあるが、先行して取得したコンテンツの一部もしくは全体を格納しておくためのストレージが必要になる。プリフェッチがより有効に機能するためには、より多くのコンテンツについてプリフェッチを行う必要があるため、その分のストレージを持たなければならない。
【００１２】
ＰＣで視聴する場合には、ストレージにも余裕があり、大量のコンテンツをプリフェッチしても特に問題にはならない。しかし、家電機器の場合、ハードディスク等の大容量の記憶装置は搭載されておらず、メモリも必要最小限の容量しか搭載されていない。そのため、大量のコンテンツをプリフェッチするのは困難であった。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】ＨＴＴＰ１．１ ＲＦＣ２０６８
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明は、大容量のストレージを用いずにコンテンツの再生遅延を低減できる通信装置、通信方法、及び通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の一態様による通信装置は、コンテンツ配信ネットワークを構成する同一のコンテンツを保持した複数のサーバのうち、いずれか１つのサーバの位置が記載された、前記コンテンツの配信を行うサーバの位置を示すコンテンツ位置情報の取得要求を受信し、前記取得要求に位置が記載された前記サーバに対する前記コンテンツ位置情報の通知を要求するリクエストを構築する第１制御部と、前記第１制御部が構築した前記リクエストを前記取得要求に位置が記載された前記サーバへ送信するリクエスト送信部と、前記サーバから送信される、前記リクエストに対する応答であり、この応答の意味を表すステータスコードを含むレスポンスを受信するレスポンス受信部と、前記前記レスポンスに記載された情報と、レスポンス受信後の処理としてのリクエストの再送信又はコンテンツ位置情報の生成との対応関係が規定されたレスポンス処理ルールを記憶するルール記憶部と、前記レスポンス受信部が受信したレスポンスに記載された情報に対応するレスポンス処理ルールを前記ルール記憶部から検出し、検出したレスポンス処理ルールが、前記リクエストの再送信である場合は、前記送信先とは異なるサーバを再送信先として生成した前記リクエストの再送信要求、もしくは前記送信先と同一のサーバで異なるパラメータを付与した前記リクエストの再送信要求を前記第１制御部へ通知し、検出したレスポンス処理ルールが、前記コンテンツ位置情報の生成である場合は、前記レスポンスに記載された情報から前記コンテンツ位置情報を生成し、前記取得要求の送信元へ送信する第２制御部と、を備えるものである。
【００１６】
また、本発明は、上記通信装置を実行することができる方法及びプログラムである。
【発明の効果】
【００１７】
本発明によれば、大容量のストレージを用いずにコンテンツの再生遅延を低減できる。
【図面の簡単な説明】
【００１８】
【図１】本発明の第１の実施形態に係る通信装置を含むネットワーク構成図である。
【図２】同第１の実施形態に係る通信方法を説明するフローチャートである。
【図３】同第１の実施形態に係る通信方法の一例を説明するシーケンス図である。
【図４】同第１の実施形態に係る通信方法の一例を説明するシーケンス図である。
【図５】本発明の第２の実施形態に係る通信装置を含むネットワーク構成図である。
【図６】同第２の実施形態に係る通信方法を説明するフローチャートである。
【図７】同第２の実施形態に係る通信方法の一例を説明するシーケンス図である。
【図８】本発明の第３の実施形態に係る通信装置を含むネットワーク構成図である。
【図９】同第３の実施形態に係る通信方法を説明するフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２０】
（第１の実施形態）図１に本発明の第１の実施形態に係る通信装置１００を含むネットワーク構成を示す。アプリケーション１０は、コンテンツを取得・視聴するアプリケーション部分であり、所定の予測方法に基づいて、ユーザが選択するコンテンツを予測する。アプリケーション１０が予測したコンテンツと同一のコンテンツが複数のキャッシュサーバ２０に保持されている。コンテンツ配信ネットワーク（ＣＤＮ）では、複数のキャッシュサーバのうち、アプリケーション１０へのコンテンツ配信が好適なキャッシュサーバからコンテンツが配信される。
【００２１】
通常、ＣＤＮ上のキャッシュサーバ２０は、アクセスがあると、アクセスしてきた相手に対して、３００番台のＨＴＴＰステータスコードを持ち、Ｌｏｃａｔｉｏｎヘッダに誘導先（別のサーバ）のＵＲＬを指定したレスポンスを送信する。このレスポンスを受け取った相手先は、Ｌｏｃａｔｉｏｎヘッダに記載されているＵＲＬへ再度アクセスする。これはリダイレクトと呼ばれる。このリダイレクトを繰り返すことで、アプリケーション１０へのコンテンツ配信が好適なキャッシュサーバへ誘導される。
【００２２】
アプリケーション１０は、予測したコンテンツを配信するキャッシュサーバの位置を特定する情報（コンテンツ位置情報）の取得を要求するコンテンツ位置情報取得要求を通信装置１００へ送信する。このコンテンツ位置情報取得要求は、予測したコンテンツを保持するＣＤＮ上の複数のキャッシュサーバのうちいずれか１つの位置（ＵＲＬ）を含む。また、アプリケーション１０は、通信装置１００が取得したコンテンツ位置情報を保持し、コンテンツ再生時に利用する。
【００２３】
通信装置１００は、アプリケーション１０からのコンテンツ位置情報取得要求に基づいて、リダイレクトを行い、コンテンツを配信するキャッシュサーバ２０の位置を特定し、コンテンツ位置情報をアプリケーション１０へ送信する。
【００２４】
通信装置１００は、リクエスト送信部１０１、レスポンス受信部１０２、レスポンス処理ルール記憶部１０３、第１制御部１１０、及び第２制御部１２０を備える。
【００２５】
第１制御部１１０は、アプリケーション１０からのコンテンツ位置情報取得要求、又は第２制御部１２０の処理結果に基づいて、キャッシュサーバ（ＨＴＴＰサーバ）２０に対してコンテンツ位置情報を通知するよう要求するリクエスト信号（ＨＴＴＰリクエスト）を構築する。
【００２６】
リクエスト送信部１０１は、第１制御部１１０が構築したＨＴＴＰリクエストをキャッシュサーバ２０へ送信する。
【００２７】
レスポンス受信部１０２は、キャッシュサーバ２０からリクエスト送信部１０１が送信したＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを受信する。レスポンス受信部１０２は、受信したＨＴＴＰレスポンスを第２制御部１２０へ出力する。
【００２８】
第２制御部１２０は、レスポンス処理ルール記憶部１０３を検索して、受信したＨＴＴＰレスポンスに対応する処理を決定し、この処理を実行する。第２制御部１２０は、処理結果を第１制御部１１０へ出力する。また、第２制御部１２０は、ＨＴＴＰレスポンスの処理結果からコンテンツ位置情報を取得した場合は、コンテンツ位置情報をアプリケーション１０へ送信する。
【００２９】
レスポンス処理ルール記憶部１０３は、ＨＴＴＰレスポンスの「条件」と、ＨＴＴＰレスポンスが「条件」に一致した場合に第２制御部１２０が実行する「処理」との組み合わせを示すレスポンス処理ルールを格納する。
【００３０】
「条件」として、例えば、ＨＴＴＰレスポンスのステータスコードや、ＨＴＴＰヘッダの値などが記述される。
【００３１】
「処理」には、任意の処理を登録し得るが、処理の結果として、リクエストの再送信（リダイレクトの続行又は新規リクエストの生成）、及びコンテンツ位置情報の取得・送信（リダイレクトの停止）のいずれかが行われるようにする。
【００３２】
このような通信装置１００を用いた通信方法を図２に示すフローチャートを用いて説明する。
【００３３】
（ステップＳ１０１）アプリケーション１０が、ユーザが選択するコンテンツを予測し、予測したコンテンツについてのコンテンツ位置情報取得要求を送信する。第１制御部１１０が、このコンテンツ位置情報取得要求を受信する。
【００３４】
（ステップＳ１０２）第１制御部１１０が、コンテンツ位置情報取得要求に基づいて、ＨＴＴＰリクエストを構築し、リクエスト送信部１０１がこのＨＴＴＰリクエストをキャッシュサーバ２０へ送信する。
【００３５】
（ステップＳ１０３）レスポンス受信部１０２が、ステップＳ１０２で送信されたＨＴＴＰリクエストに対するキャッシュサーバ２０からのＨＴＴＰレスポンスを受信する。レスポンス受信部１０２は受信したＨＴＴＰレスポンスを第２制御部１２０へ出力する。
【００３６】
（ステップＳ１０４）第２制御部１２０が、レスポンス処理ルール記憶部１０３に格納されたレスポンス処理ルールのうち、「条件」がステップＳ１０３で受信したＨＴＴＰレスポンスと一致するものを検索し、一致した「条件」に対応する「処理」を検出する。
【００３７】
なお、一致する「条件」が無い場合は、エラーとしてアプリケーション１０に通知するようにしてもよく、また予め実行する処理を決めておいてもよい。
【００３８】
（ステップＳ１０５）第２制御部１２０が、ステップＳ１０４で検出した「処理」を実行する。
【００３９】
（ステップＳ１０６）ステップＳ１０５の処理の結果、リクエストを再送信するか否か判定される。リクエストを再送信しない場合はステップＳ１０７へ進む。
【００４０】
リクエストを再送信する（リダイレクトを続行する、又は新規リクエストを生成する）場合は、ステップＳ１０２に戻る。この時、第２制御部１２０が、受信したレスポンスから再送信先を生成する。
【００４１】
（ステップＳ１０７）処理の結果得られたコンテンツ位置情報がアプリケーション１０へ送信される。
【００４２】
このように、本実施形態では、コンテンツそのものの情報を予め取得しておくプリフェッチと異なり、コンテンツの位置を特定する情報のみを予め取得するため、大容量のストレージは不要である。また、予めコンテンツの位置を特定する情報を取得しておくことで、コンテンツの選択から再生開始までに要する時間を短縮できる。
【００４３】
レスポンス処理ルール記憶部１０３に格納されるレスポンス処理ルールの一例を表１に示す。ここでは、レスポンス処理ルールは、動画共有サイト“○○○○○”に対応したものである。
【表１】
2010160610.tif 000003
【００４４】
レスポンス処理ルール記憶部１０３が、このようなレスポンス処理ルールを格納している場合の通信装置１００による通信方法を図３に示すシーケンスを用いて説明する。
【００４５】
（ステップＳ２０１）アプリケーション１０が、動画視聴用ページのＵＲＬであるhttp://www.○○○○○.com/watch?v=vVLATiD0Jzsを含むコンテンツ位置情報取得要求を通信装置１００の第１制御部１１０へ送信する。
【００４６】
（ステップＳ２０２）第１制御部１１０が、ステップＳ２０１で指定されたＵＲＬ宛のＨＴＴＰリクエストを構築し、リクエスト送信部１０１がこのＨＴＴＰリクエストを送信する。
【００４７】
（ステップＳ２０３）レスポンス受信部１０２が、ステータスコードが３０３で、Ｌｏｃａｔｉｏｎヘッダの値がドメインｊｐ．○○○○○．ｃｏｍを含むＵＲＬであるＨＴＴＰレスポンスを受信し、第２制御部１２０へ出力する。第２制御部１２０が、レスポンス処理ルール記憶部１０３を検索し、ルール１に一致することを検出する。
【００４８】
第２制御部１２０が、ルール１に対応づけられた処理を実行し、レスポンスのＬｏｃａｔｉｏｎヘッダのＵＲＬを宛先とするＨＴＴＰリクエストの送信（リクエスト再送信）を第１制御部１１０に要求する。
【００４９】
（ステップＳ２０４）第１制御部１１０が、ステップＳ２０３で指定されたＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部１０１が送信する（リダイレクトを続行する）。
【００５０】
（ステップＳ２０５）レスポンス受信部１０２が、ステータスコードが２００で、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダの値がｔｅｘｔ／ｈｔｍｌであるＨＴＭＬ形式のボディを持つＨＴＴＰレスポンスを受信し、第２制御部１２０へ出力する。
【００５１】
第２制御部１２０が、レスポンス処理ルール記憶部１０３を検索し、ルール２に一致することを検出する。
【００５２】
第２制御部１２０が、ルール２に対応づけられた処理を実行し、ＨＴＭＬを解析した結果から得られたコンテンツＩＤとセッションＩＤを使って新たなＵＲＬを生成し、第１制御部１１０にリクエストの送信（リクエスト再送信）を要求する。
【００５３】
（ステップＳ２０６）第１制御部１１０が、ステップＳ２０５で指定されたＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部１０１が送信する（新規リクエストを送信する）。
【００５４】
（ステップＳ２０７）レスポンス受信部１０２が、ステータスコードが３０３で、Ｌｏｃａｔｉｏｎヘッダの値がドメインｊｐ．○○○○○．ｃｏｍを含むＵＲＬであるＨＴＴＰレスポンスを受信し、第２制御部１２０へ出力する。第２制御部１２０が、レスポンス処理ルール記憶部１０３を検索し、ルール１に一致することを検出する。
【００５５】
第２制御部１２０が、ルール１に対応づけられた処理を実行し、レスポンスのＬｏｃａｔｉｏｎヘッダのＵＲＬを宛先とするＨＴＴＰリクエストの送信を第１制御部１１０に要求する。
【００５６】
（ステップＳ２０８）第１制御部１１０が、ステップＳ２０７で指定されたＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部１０１が送信する（リダイレクトを続行する）。
【００５７】
（ステップＳ２０９）リクエスト受信部１０２が、ステータスコードが３０３で、Ｌｏｃａｔｉｏｎヘッダの値がドメインｃａｃｈｅ．△△△△ｖｉｄｅｏ．ｃｏｍを含むＵＲＬであるレスポンスを受信し、第２制御部１２０へ出力する。
【００５８】
第２制御部１２０が、レスポンス処理ルール記憶部１０３を検索し、ルール３に一致することを検出する。第２制御部１２０が、ルール３に対応づけられた処理を実行する。
【００５９】
（ステップＳ２１０）第２制御部１２０が、ステップＳ２０９におけるルール３に対応づけられた処理の実行の結果、レスポンスのＬｏｃａｔｉｏｎヘッダの値をコンテンツの位置を特定するＵＲＬ（コンテンツ位置情報）としてアプリケーション１０へ送信する（リダイレクトを停止する）。
【００６０】
レスポンス処理ルール記憶部１０３が格納するレスポンス処理ルールの別の例を表２に示す。ここでは、レスポンス処理ルールは、動画共有サイト“ｘｘｘｘｘ”に対応したものとなっている。
【表２】
2010160610.tif 000004
【００６１】
レスポンス処理ルール記憶部１０３が、このようなレスポンス処理ルールを格納している場合の通信装置１００による通信方法を図４に示すシーケンスを用いて説明する。
【００６２】
（ステップＳ３０１）アプリケーション１０が、動画視聴用ページのＵＲＬであるhttp://ｘｘｘｘｘ.jp/watch.do?movie=1103949 を含むコンテンツ位置情報取得要求を通信装置１００の第１制御部１１０へ送信する。
【００６３】
（ステップＳ３０２）第１制御部１１０が、ステップＳ３０１で指定されたＵＲＬ宛のＨＴＴＰリクエストを構築し、リクエスト送信部１０１が送信する。
【００６４】
（ステップＳ３０３）レスポンス受信部１０２が、ステータスコードが２００であり、かつContent-Typeヘッダの値が"text/html"のＨＴＴＰレスポンスを受信し、第２制御部１２０へ出力する。
【００６５】
第２制御部１２０は、レスポンス処理ルール記憶部１０３を検索し、受信したレスポンスがルール１に一致することを検出する。第２制御部１２０が、ルール１に対応づけられた処理を実行する。
【００６６】
（ステップＳ３０４）第２制御部１２０が、ステップＳ３０３におけるルール１に対応づけられた処理の実行の結果、レスポンスのＬｏｃａｔｉｏｎヘッダの値をコンテンツの位置を特定するＵＲＬ（コンテンツ位置情報）としてアプリケーション１０へ送信する（リダイレクトを停止する）。
【００６７】
コンテンツの位置を事前に特定せずにコンテンツを視聴する場合、リダイレクトによってキャッシュサーバに誘導された上で、コンテンツが配信される。大規模なＣＤＮではキャッシュサーバへの誘導に１．５秒〜２秒程度を要する。
【００６８】
本実施形態では、コンテンツの再生が始まる前にコンテンツの位置を特定する情報を取得しているため、この時間を省くことができ、リダイレクトに要する時間を短縮し、コンテンツの選択から再生開始までの遅延を短縮できる。
【００６９】
また、コンテンツの位置を特定する情報（コンテンツ位置情報）は、コンテンツ自体の一部又は全体と比較して、非常に容量が小さい。そのため、大量のコンテンツのコンテンツ位置情報を取得しても、大容量のストレージは必要とならない。
【００７０】
コンテンツ位置情報は、ＵＲＬなどのテキスト情報で表現できる場合が多い。従って、長くても１０２４バイトあれば、ほとんどのＵＲＬを格納するのに十分な容量となる。動画コンテンツのデータサイズは動画の解像度やフレームレート、ビットレート等によって異なるため一概にデータサイズを述べることはできないが、１０２４バイトではキャッシュとして不十分な容量である。
【００７１】
ＵＲＬ（コンテンツ位置情報）だけを取得しておくほうが、コンテンツの一部を取得することに比べてメモリ消費が少なく、家電機器のメモリの一部を用いても十分にコンテンツ再生遅延短縮効果を得ることができる。
【００７２】
上記第１の実施形態において、アプリケーション１０と通信装置１００は同一の端末装置内に存在してもよいし、異なる端末装置に分割され、ネットワークを介して接続されていてもよい。異なる端末装置に分割されている場合は、任意の通信プロトコルによってコンテンツ位置情報取得要求を送信してよい。
【００７３】
アプリケーション１０は、リクエスト送信部１０１が送信するリクエストのＨＴＴＰメソッドを指定してもよい。
【００７４】
また、アプリケーション１０は、リクエスト送信部１０１が送信するリクエストに挿入する複数のＨＴＴＰヘッダとその値を指定してもよい。
【００７５】
また、アプリケーション１０は、リクエスト送信部１０１が送信するリクエスト（ＰＯＳＴ）のボディに挿入するデータを指定してもよい。
【００７６】
また、アプリケーション１０は、リクエスト送信部１０１が送信するリクエストの送信先をＵＲＬで直接指定してもよいし、リクエスト送信部１０１が送信先を決定するために必要な情報のみを指定してもよい。
【００７７】
第２制御部１２０は、レスポンス処理ルール記憶部１０３に格納されたマッチングルールを実行するための実行環境を備えてもよく、レスポンスとルールをマッチさせるためにルールを実行してマッチするか否かを判定してもよい。
【００７８】
レスポンス処理ルール記憶部１０３の「条件」には、任意のプログラミング言語で記述されたプログラムの断片もしくは、全体を記述できる。
【００７９】
また、「条件」には、任意のプログラミング言語で記述され、処理系によって変換された実行コードの断片もしくは全体を格納してもよい。
【００８０】
また、レスポンス処理ルール記憶部１０３には、「処理」を実行するための処理系を特定する情報を格納してもよい。また、処理系を識別するＩＤもしくは処理系のメモリ上での実行アドレスを格納してもよい。
【００８１】
（第２の実施形態）図５に本発明の第２の実施形態に係る通信装置２００を含むネットワーク構成を示す。通信装置２００は、リクエスト送信部２０１、レスポンス受信部２０２、レスポンス処理ルール記憶部２０３、コンテンツ情報記憶部２０４、第１制御部２１０、及び第２制御部２２０を備える。
【００８２】
コンテンツ情報記憶部２０４は、「コンテンツ識別子」及び「接続識別子」を格納する。「コンテンツ識別子」は、ＣＤＮ（コンテンツ配信ネットワーク）上のサーバにＨＴＴＰリクエストを送信し、送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを待ち受けている状態にあるコンテンツを識別する情報を示す。「コンテンツ識別子」として、例えば、コンテンツを一意に識別できるＵＲＬや、ＣＤＮによってコンテンツに付与されたＩＤが用いられる。
【００８３】
「接続識別子」は、ＨＴＴＰリクエストの送信、ＨＴＴＰレスポンスの受信のために、ＣＤＮ上のサーバと確立した接続（ＴＣＰコネクション）を識別する情報を示す。
【００８４】
第１制御部２１０は、コンテンツ位置情報取得要求に基づくコンテンツ情報記憶部２０４へのデータ登録（新規データ作成）、及び送信されたＨＴＴＰリクエストに基づくコンテンツ情報記憶部２０４のデータ更新を行う点を除いて、上記第１の実施形態における第１制御部１１０と同様のものとなっている。
【００８５】
第２制御部２２０は、ＨＴＴＰレスポンスを受信した接続の識別情報に基づいて、コンテンツ情報記憶部２０４の検索を行い、受信したＨＴＴＰレスポンスに対応するＨＴＴＰリクエストの送信先を検出し、検出した送信先を用いてレスポンス処理ルール記憶部２０３の検索を行う点を除いて、上記第１の実施形態における第２制御部１２０と同様のものとなっている。
【００８６】
レスポンス処理ルール記憶部２０３は、上記第１の実施形態におけるレスポンス処理ルール記憶部１０３と同様に、ＨＴＴＰレスポンスの「条件」と、ＨＴＴＰレスポンスが「条件」に一致した場合にレスポンス受信部２０２が実行する「処理」との組み合わせを示すレスポンス処理ルールを格納する。
【００８７】
このような通信装置２００を用いた通信方法を図６に示すフローチャートを用いて説明する。
【００８８】
（ステップＳ４０１）アプリケーション１０が先行して取得するコンテンツを予測し、第１制御部２１０へコンテンツ位置情報取得要求を送信する。第１制御部２１０は、コンテンツ情報記憶部２０４に、コンテンツ位置情報取得要求に対応するデータを登録する。
【００８９】
（ステップＳ４０２）第１制御部２１０が、コンテンツ位置情報取得要求に基づいて、ＨＴＴＰリクエストを構築し、リクエスト送信部２０１がキャッシュサーバ２０へ送信する。
【００９０】
（ステップＳ４０３）第１制御部２１０が、リクエスト送信部２０１によるＨＴＴＰリクエストの送信に伴い、コンテンツ情報記憶部２０４のデータを更新する。
【００９１】
（ステップＳ４０４）レスポンス受信部２０２が、ステップＳ４０２で送信されたＨＴＴＰリクエストに対するキャッシュサーバ２０からのＨＴＴＰレスポンスを受信し、第２制御部２２０へ出力する。
【００９２】
（ステップＳ４０５）第２制御部２２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを識別するＴＣＰコネクション識別情報を用いて、コンテンツ情報記憶部２０４の検索を行い、ステップＳ４０２で送信したＨＴＴＰリクエストの送信先を検出する。
【００９３】
（ステップＳ４０６）第２制御部２２０が、ステップＳ４０５で検出されたＨＴＴＰリクエストの送信先を用いて、レスポンス処理ルール記憶部２０３に格納されたレスポンス処理ルールのうち、「条件」がステップＳ４０４で受信したＨＴＴＰレスポンスと一致するものを検索し、一致した「条件」に対応する「処理」を検出する。
【００９４】
なお、一致する「条件」が無い場合は、エラーとしてアプリケーション１０に通知するようにしてもよく、また予め実行する処理を決めておいてもよい。
【００９５】
（ステップＳ４０７）第２制御部２２０が、ステップＳ４０６で検出した「処理」を実行する。
【００９６】
（ステップＳ４０８）ステップＳ４０７の処理の結果、リクエストの再送信を行うか否か判定される。リクエストの再送信を行わない場合はステップＳ４０９へ進む。
【００９７】
リクエストを再送信する（リダイレクトを続行する、又は新規リクエストを生成する）場合は、ステップＳ４０２に戻る。この時、第２制御部２２０が、受信したレスポンスから再送信先を生成する。
【００９８】
（ステップＳ４０９）処理の結果得られたコンテンツ位置情報がアプリケーション１０へ送信される。
【００９９】
このように、本実施形態では、コンテンツそのものの情報を予め取得しておくプリフェッチと異なり、コンテンツの位置を特定する情報のみを予め取得するため、大容量のストレージは不要である。また、予めコンテンツの位置を特定する情報を取得しておくことで、コンテンツの選択から再生開始までに要する時間を短縮できる。
【０１００】
また、上記第１の実施形態では１つのサービス（動画共有サイト）に対してコンテンツ位置情報を取得していたが、本実施形態ではコンテンツ情報記憶部２０４を備えており、ＨＴＴＰレスポンスがどのサービスに対応するものなのか識別できるため、複数のサービスに対してコンテンツ位置情報を取得できる。
【０１０１】
レスポンス処理ルール記憶部２０３が格納するレスポンス処理ルールの一例を表３に示す。ここでは、レスポンス処理ルールは、動画共有サイト“○○○○○”と“ｘｘｘｘｘ”に対応したものとなっている。
【表３】
2010160610.tif 000005
2010160610.tif 000006
【０１０２】
レスポンス処理ルール記憶部２０３が、このようなレスポンス処理ルールを格納している場合の通信装置２００による通信方法を図７に示すシーケンスを用いて説明する。
【０１０３】
（ステップＳ５０１）アプリケーション１０が、動画視聴用ページのＵＲＬであるhttp://www.○○○○○.com/watch?v=vVLATiD0Jzsを含むコンテンツ位置情報取得要求を通信装置２００の第１制御部２１０へ送信する。
【０１０４】
（ステップＳ５０２）第１制御部２１０が、「接続識別子」としてＨＴＴＰリクエストを送信するＴＣＰコネクションを識別する情報と、「コンテンツ識別子」としてステップＳ５０１で指定されたＵＲＬ、及びリクエスト送信先のＵＲＬ（ここではステップＳ５０１で指定されたＵＲＬと同じ）と、をコンテンツ情報記憶部２０４に格納（登録）する。
【０１０５】
そして、第１制御部２１０が、ステップＳ５０１で指定されたＵＲＬ宛のＨＴＴＰリクエストを構築し、リクエスト送信部２０１が送信する。
【０１０６】
（ステップＳ５０３）レスポンス受信部５０２が、ステータスコードが３０３で、Ｌｏｃａｔｉｏｎヘッダの値がドメインｊｐ．○○○○○．ｃｏｍを含むＵＲＬであるＨＴＴＰレスポンスを受信し、第２制御部２２０へ出力する。
【０１０７】
第２制御部２２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを表す情報に基づいて、コンテンツ情報記憶部２０４を検索し、ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストの送信先ＵＲＬを得る。
【０１０８】
さらに、第２制御部２２０が、コンテンツ情報記憶部２０４の検索により得たリクエスト送信先ＵＲＬを用いて、レスポンス処理ルール記憶部２０３を検索し、受信したＨＴＴＰレスポンスがルール１に一致することを検出する。
【０１０９】
第２制御部２２０が、ルール１に対応づけられた処理を実行し、レスポンスのＬｏｃａｔｉｏｎヘッダのＵＲＬを宛先とするＨＴＴＰリクエストの送信を第１制御部２１０に要求する。
【０１１０】
（ステップＳ５０４）第１制御部２１０が、ステップＳ５０３で指定されたＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部２０１が送信する（リダイレクトを続行する）。
【０１１１】
そして、第１制御部２１０が、コンテンツ情報記憶部２０４に格納されているリクエストの送信先ＵＲＬ（「コンテンツ識別子」）をステップＳ５０３で指定されたＵＲＬに更新する。また、コネクションを識別する情報（「接続識別子」）も更新する。
【０１１２】
（ステップＳ５０５）レスポンス受信部２０２が、ステータスコードが２００で、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダの値がｔｅｘｔ／ｈｔｍｌでＨＴＭＬ形式のボディを持つＨＴＴＰレスポンスを受信し、第２制御部２２０へ出力する。
【０１１３】
第２制御部２２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを表す情報に基づいて、コンテンツ情報記憶部２０４を検索し、ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストの送信先ＵＲＬを得る。
【０１１４】
そして、第２制御部２２０が、コンテンツ情報記憶部２０４の検索により得たリクエスト送信先ＵＲＬを用いて、レスポンス処理ルール記憶部２０３を検索し、受信したＨＴＴＰレスポンスがルール２に一致することを検出する。
【０１１５】
第２制御部２２０が、ルール２に対応づけられた処理を実行し、ＨＴＭＬを解析した結果から得られたコンテンツＩＤとセッションＩＤを使って新たなＵＲＬを生成し、第１制御部２１０にリクエストの送信を要求する。
【０１１６】
（ステップＳ５０６）第１制御部２１０が、ステップＳ５０５で指定されたＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部２０１が送信する（新規リクエストを送信する）。
【０１１７】
さらに、第２制御部２２０は、コンテンツ情報記憶部２０４のリクエスト送信先ＵＲＬ（「コンテンツ識別子」）とコネクション識別情報（「接続識別子」）とを更新する。
【０１１８】
（ステップＳ５０７）レスポンス受信部２０２が、ステータスコードが３０３で、Ｌｏｃａｔｉｏｎヘッダの値がドメインｊｐ．○○○○○．ｃｏｍを含むＵＲＬであるＨＴＴＰレスポンスを受信し、第２制御部２２０へ出力する。
【０１１９】
第２制御部２２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを表す情報に基づいて、コンテンツ情報記憶部２０４を検索し、ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストの送信先ＵＲＬを得る。
【０１２０】
そして、第２制御部２２０が、コンテンツ情報記憶部２０４の検索により得たリクエスト送信先ＵＲＬを用いて、レスポンス処理ルール記憶部２０３を検索し、受信したＨＴＴＰレスポンスがルール１に一致することを検出する。
【０１２１】
第２制御部２２０は、ルール１に対応づけられた処理を実行し、レスポンスのＬｏｃａｔｉｏｎヘッダのＵＲＬを宛先とするＨＴＴＰリクエストの送信を第１制御部２１０に要求する。
【０１２２】
（ステップＳ５０８）第１制御部２１０が、ステップＳ５０７で指定されたＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部２０１が送信する（リダイレクトを続行する）。
【０１２３】
さらに、第１制御部２１０は、コンテンツ情報記憶部２０４のリクエスト送信先ＵＲＬとコネクション識別情報とを更新する。
【０１２４】
（ステップＳ５０９）リクエスト受信部２０２が、ステータスコードが３０３で、Ｌｏｃａｔｉｏｎヘッダの値がドメインｃａｃｈｅ．△△△△ｖｉｄｅｏ．ｃｏｍを含むＵＲＬであるレスポンスを受信し、第２制御部２２０へ出力する。
【０１２５】
第２制御部２２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを表す情報に基づいて、コンテンツ情報記憶部２０４を検索し、ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストの送信先ＵＲＬを得る。
【０１２６】
そして、第２制御部２２０が、コンテンツ情報記憶部２０４の検索により得たリクエスト送信先ＵＲＬを用いて、レスポンス処理ルール記憶部２０３を検索し、受信したＨＴＴＰレスポンスがルール３に一致することを検出する。
【０１２７】
第２制御部２２０が、ルール３に対応づけられた処理を実行する。
【０１２８】
（ステップＳ５１０）第２制御部２２０が、ステップＳ５０９におけるルール３に対応づけられた処理の実行の結果、レスポンスのＬｏｃａｔｉｏｎヘッダの値をコンテンツの位置を特定するＵＲＬ（コンテンツ位置情報）としてアプリケーション１０へ送信する（リダイレクトを停止する）。
【０１２９】
（ステップＳ５１１）アプリケーション１０が、動画視聴用ページのＵＲＬであるhttp://ｘｘｘｘｘ.jp/watch.do?movie=1103949 を含むコンテンツ位置情報取得要求を通信装置２００の第１制御部２１０へ送信する。
【０１３０】
（ステップＳ５１２）第１制御部２１０が、「接続識別子」としてＨＴＴＰリクエストを送信するＴＣＰコネクションを識別する情報と、「コンテンツ識別子」としてステップＳ５１１で指定されたＵＲＬ、及びリクエスト送信先のＵＲＬ（ここではステップＳ５１１で指定されたＵＲＬと同じ）と、をコンテンツ情報記憶部２０４に格納する。
【０１３１】
そして、第２制御部２２０が、ステップＳ５１１で指定されたＵＲＬ宛のＨＴＴＰリクエストを構築し、リクエスト送信部２０１が送信する。
【０１３２】
（ステップＳ５１３）レスポンス受信部２０２が、ステータスコードが２００であり、かつContent-Typeヘッダの値が"text/html"のＨＴＴＰレスポンスを受信し、第２制御部２２０へ出力する。
【０１３３】
第２制御部２２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを表す情報に基づいて、コンテンツ情報記憶部２０４を検索し、ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストの送信先ＵＲＬを得る。
【０１３４】
そして、第２制御部２２０が、コンテンツ情報記憶部２０４の検索により得たリクエスト送信先ＵＲＬを用いて、レスポンス処理ルール記憶部２０３を検索し、受信したＨＴＴＰレスポンスがルール４に一致することを検出する。
【０１３５】
第２制御部２２０が、ルール４に対応づけられた処理を実行する。
【０１３６】
（ステップＳ５１４）第２制御部２２０が、ステップＳ５１３におけるルール４に対応づけられた処理の実行の結果、レスポンスのＬｏｃａｔｉｏｎヘッダの値をコンテンツの位置を特定するＵＲＬ（コンテンツ位置情報）としてアプリケーション１０へ送信する（リダイレクトを停止する）。
【０１３７】
このように、本実施形態によっても、上記第１の実施形態と同様に、コンテンツの再生が始まる前にコンテンツの位置を特定する情報を取得しているため、コンテンツの選択から再生開始までの遅延を短縮できる。
【０１３８】
また、コンテンツの位置を特定する情報（コンテンツ位置情報）は、コンテンツ自体の一部又は全体と比較して、非常に容量が小さい。従って、大量のコンテンツのコンテンツ位置情報を取得しても、大容量のストレージは必要とならない。
【０１３９】
さらに、ＨＴＴＰレスポンスのコネクション識別情報からＨＴＴＰリクエストの送信先ＵＲＬを識別することで、複数の動画共有サービスに対して、コンテンツ位置情報の事前取得を行うことができる。
【０１４０】
上記第２の実施形態では、コンテンツ情報記憶部２０４に、最後に送信したＨＴＴＰリクエストの送信先ＵＲＬ、又は最後に送信したＨＴＴＰリクエストそのものを保持するようにしてもよい。
【０１４１】
また、コンテンツ情報記憶部２０４は、すべてのＨＴＴＰリクエスト、ＨＴＴＰレスポンスを保持してもよい。
【０１４２】
上記第２の実施形態では、「コンテンツ識別子」及び「接続識別子」を含むコンテンツ情報をコンテンツ情報記憶部２０４に格納し、レスポンス処理ルールをレスポンス処理ルール記憶部２０３に格納していたが、レスポンス処理ルールもコンテンツ情報記憶部２０４に格納するようにしてもよい。
【０１４３】
この場合、アプリケーション１０は、コンテンツ位置情報取得要求（コンテンツのＵＲＬ）を送信する時に、リクエスト送信部２０１が送信するリクエストに対するレスポンスを処理するルールも送信する。
【０１４４】
第１制御部２１０は、ＨＴＴＰリクエストを送信するＴＣＰコネクションを識別する情報、アプリケーション１０から指定されたＵＲＬ、及びリクエスト送信先のＵＲＬ（アプリケーション１０から指定されたＵＲＬと同じ）と共に、レスポンス処理ルールをコンテンツ情報記憶部２０４に登録する。
【０１４５】
（第３の実施形態）図８に本発明の第３の実施形態に係る通信装置３００を含むネットワーク構成を示す。通信装置３００は、コンテンツ位置情報記憶部３０５を備える以外は図５に示す上記第２の実施形態に係る通信装置２００と同様の構成となっている。
【０１４６】
コンテンツ位置情報記憶部３０５は、コンテンツを一意に識別する情報（ＵＲＬ、ＣＤＮによってコンテンツに付与されたＩＤ等）と、コンテンツの位置を特定する情報（ＵＲＬ、ＩＰアドレス等）と、コンテンツの位置を特定する情報の有効期限と、の組み合わせを格納する。コンテンツへのアクセスにコンテンツの位置を特定する情報（ＵＲＬ）以外の情報が必要な場合は、併せて格納する。
【０１４７】
コンテンツ情報記憶部３０５は、通信装置３００と同一の端末装置内に存在してもよいし、異なる端末装置に分割され、ネットワークを介して接続されていてもよい。異なる端末装置に分割されている場合は、任意の通信プロトコルによってコンテンツ位置情報取得要求を送信してよい。コンテンツ位置情報記憶部３０５は例えばキャッシュメモリである。
【０１４８】
コンテンツ位置情報記憶部３０５は、アプリケーション１０から送信されるコンテンツ位置情報取得要求を受け取り、この要求に対応する有効期限が切れていないコンテンツ位置情報を格納している場合は、このコンテンツ位置情報をアプリケーション１０へ送信する。
【０１４９】
コンテンツ位置情報記憶部３０５は、コンテンツ位置情報取得要求に対応する有効期限が切れていないコンテンツ位置情報を格納していない場合は、コンテンツ位置情報取得要求を第１制御部３１０へ送信する。
【０１５０】
リクエスト送信部３０１、レスポンス受信部３０２、レスポンス処理ルール記憶部３０３、コンテンツ情報記憶部３０４、第１制御部３１０、及び第２制御部３２０の機能は上記第２の実施形態と同様であるため、説明を省略する。
【０１５１】
第２制御部３２０は、処理の結果得られたコンテンツ位置情報を、コンテンツ位置情報記憶部３０５へ送信する。コンテンツ位置情報記憶部３０５は、受け取ったコンテンツ位置情報を格納すると共に、アプリケーション１０へ送信する。
【０１５２】
このような通信装置３００を用いた通信方法を図９に示すフローチャートを用いて説明する。
【０１５３】
（ステップＳ６０１）アプリケーション１０がコンテンツ位置情報取得要求を送信する。コンテンツ位置情報取得要求の受信に伴い、コンテンツ位置情報記憶部３０５を検索する。
【０１５４】
（ステップＳ６０２）コンテンツ位置情報取得要求に対応し、有効期限が切れていないコンテンツ位置情報がコンテンツ位置情報記憶部３０５に格納されている場合は、そのコンテンツ位置情報をアプリケーション１０へ送信し、終了する。
【０１５５】
コンテンツ位置情報取得要求に対応し、有効期限が切れていないコンテンツ位置情報がコンテンツ位置情報記憶部３０５に格納されていない場合は、コンテンツ位置情報取得要求を第１制御部３１０へ送信し、ステップＳ６０３へ進む。
【０１５６】
（ステップＳ６０３）第１制御部３１０が、コンテンツ情報記憶部３０４に、コンテンツ位置情報取得要求に対応するデータを登録する。
【０１５７】
（ステップＳ６０４）第１制御部３１０が、コンテンツ位置情報取得要求に含まれるＵＲＬ宛てのＨＴＴＰリクエストを構築し、リクエスト送信部３０１が送信する。
【０１５８】
（ステップＳ６０５）第１制御部３１０が、リクエスト送信部３０１によるＨＴＴＰリクエストの送信に伴い、コンテンツ情報記憶部３０４のデータを更新する。
【０１５９】
（ステップＳ６０６）レスポンス受信部３０２が、ステップＳ６０４で送信されたＨＴＴＰリクエストに対するキャッシュサーバ２０からのＨＴＴＰレスポンスを受信し、第２制御部３２０へ出力する。
【０１６０】
（ステップＳ６０７）第２制御部３２０が、ＨＴＴＰレスポンスを受信したＴＣＰコネクションを識別するＴＣＰコネクション識別情報を用いて、コンテンツ情報記憶部３０４の検索を行い、ステップＳ６０４で送信されたＨＴＴＰリクエストの送信先を検出する。
【０１６１】
（ステップＳ６０８）第２制御部３２０が、ステップＳ６０７で検出した送信先を用いて、レスポンス処理ルール記憶部３０３に格納されたレスポンス処理ルールのうち、「条件」がステップＳ６０６で受信したＨＴＴＰレスポンスと一致するものを検索し、一致した「条件」に対応する「処理」を検出する。
【０１６２】
なお、一致する「条件」が無い場合は、エラーとしてアプリケーション１０に通知するようにしてもよく、また予め実行する処理を決めておいてもよい。
【０１６３】
（ステップＳ６０９）第２制御部３２０が、ステップＳ６０８で検出した「処理」を実行する。
【０１６４】
（ステップＳ６１０）ステップＳ６０９の処理の結果、リクエストの再送信を行うか否か判定される。リクエストの再送信を行わない場合はステップＳ６１１へ進む。リクエストの再送信を行う（リダイレクトを続行する、又は新規リクエストを生成する）場合は、ステップＳ６０４に戻る。
【０１６５】
（ステップＳ６１１）処理の結果得られたコンテンツ位置情報がコンテンツ位置情報記憶部３０５へ送信される。コンテンツ位置情報記憶部３０５は受け取ったコンテンツ位置情報を用いてデータの登録（更新）を行い、コンテンツ位置情報をアプリケーション１０へ送信する。
【０１６６】
このように、本実施形態によっても、上記第１、第２の実施形態と同様に、コンテンツの再生が始まる前にコンテンツの位置を特定する情報を取得しているため、コンテンツの選択から再生開始までの遅延を短縮できる。
【０１６７】
また、コンテンツの位置を特定する情報（コンテンツ位置情報）は、コンテンツ自体の一部又は全体と比較して、非常に容量が小さい。従って、大量のコンテンツのコンテンツ位置情報を取得しても、大容量のストレージは必要とならない。
【０１６８】
また、コンテンツ位置情報記憶部３０５を設けることで、既にコンテンツ位置情報を取得していたコンテンツに対しては、リクエストの送信やレスポンスの受信等を行わず、コンテンツ位置情報記憶部３０５からコンテンツ位置情報を取り出してアプリケーション１０に返すため、アプリケーション１０は多くのコンテンツのコンテンツ位置情報を短時間に取得できる。
【０１６９】
上記第３の実施形態において、コンテンツ位置情報記憶部３０５に格納されているコンテンツ位置情報のうち、有効期限が近付いたコンテンツについて、再度コンテンツ位置情報を取得して、コンテンツ位置情報記憶部３０５のデータを更新するようにしてもよい。
【０１７０】
上記第１〜第３の実施形態では、１つのレスポンスに対して１つのレスポンス処理ルールの「条件」が一致する場合を例に説明していたが、１つのレスポンスに対して複数のレスポンス処理ルールの「条件」が一致する場合もある。その場合、レスポンス受信部１０２、２０２、３０２は複数のルールに対応する処理を並行して実行する。
【０１７１】
この時、コンテンツ情報記憶部２０４、３０４、コンテンツ位置情報記憶部３０５は、レスポンス処理ルールの「条件」が一致する毎に、エントリを複製する。また、コンテンツ位置情報記憶部３０５は、アプリケーション１０からのコンテンツ位置情報取得要求があった場合、複数の位置情報を返す。また、コンテンツ位置情報記憶部３０５は、各エントリの有効期限を個別に管理する。
【０１７２】
上記実施形態におけるアプリケーション１０は、ユーザが選択するコンテンツを視聴履歴や嗜好情報などから予測し得る。また、動画共有サイトのトップページに表示されるすべてのコンテンツについてコンテンツ位置情報を取得するようにしても良い。
【０１７３】
上述した実施形態で説明した通信装置の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、通信装置の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
【０１７４】
また、通信装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
【０１７５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１７６】
１０  アプリケーション
２０  キャッシュサーバ
１００  通信装置
１０１  リクエスト送信部
１０２  レスポンス受信部
１０３  レスポンス処理ルール記憶部
１１０  第１制御部
１２０  第２制御部
【図１】
2010160610.tif 000007
【図２】
2010160610.tif 000008
【図３】
2010160610.tif 000009
【図４】
2010160610.tif 000010
【図５】
2010160610.tif 000011
【図６】
2010160610.tif 000012
【図７】
2010160610.tif 000013
【図８】
2010160610.tif 000014
【図９】
2010160610.tif 000015