(57)【特許請求の範囲】
【請求項１】
リモートメディアソースに格納されたリモートメディアファイルのコピーであるメディアファイルがキャッシュに存在するか判断するキャッシュサービスモジュールであって、前記キャッシュサービスモジュールは、
コンピュータ可読命令が格納されるコンピュータ可読記憶媒体を有するファイル分析モジュールを備え、
前記コンピュータ可読命令が、プロセッサによって実行されると、
（ｉ）前記リモートメディアソースから、前記リモートメディアファイルのファイルサイズ、及び、Ｍ個のバイト範囲を取得する段階と、
（ｉｉ）前記Ｍ個のバイト範囲におけるバイトを、バイトのストリングに連結する段階と、
（ｉｉｉ）前記バイトのストリングを使用して、前記メディアファイルに対する署名を生成する段階と、
（ｉｖ）前記メディアファイルに対する前記署名を使用して前記キャッシュに問い合わせることを含む、前記メディアファイルが前記キャッシュに存在するかを判断する段階とが実行され、
前記Ｍは、Ｍ≧２であり、前記Ｍ個のバイト範囲は、前記リモートメディアファイルの開始点を基準としたそれぞれのオフセットで取得され、前記Ｍ個のバイト範囲の各々は、前記リモートメディアファイルの前記ファイルサイズよりも小さいキャッシュサービスモジュール。
【請求項２】
前記Ｍの値と、
前記Ｍ個の範囲の各々に対して取得されるべきバイト数をそれぞれ規定する所定のパラメータと、
前記リモートメディアファイルの前記ファイルサイズの関数として、それぞれのオフセットを計算するための所定のパラメータとを格納するためのコンピュータ可読命令を格納するコンピュータ可読媒体を有するコンフィギュレーションテーブルを更に備える請求項１に記載のキャッシュサービスモジュール。
【請求項３】
前記Ｍ個のバイト範囲が重複していない、又は、
前記Ｍ個の範囲全てのバイトの総計が、前記リモートメディアファイルの前記ファイルサイズよりも小さい、又は、
前記オフセットのうちの１つが０に等しい、という条件のうちの１以上が満たされている請求項１又は２に記載のキャッシュサービスモジュール。
【請求項４】
前記コンフィギュレーションテーブルは、前記メディアファイルに対する所定の閾値を更に有し、
前記キャッシュサービスモジュールは、
前記メディアファイルについて、メディアクライアントデバイスからのメディアリクエストを記録するためのリクエストログモジュールと、
前記メディアファイルに対する前記リクエストログに格納されたリクエストの数と、前記所定の閾値とを比較するための比較器と、
前記メディアファイルが前記キャッシュに存在せず、前記所定の閾値を超える場合には、前記メディアファイルを前記キャッシュへと送信するキャッシュインターフェースモジュールとを更に有する請求項２に記載のキャッシュサービスモジュール。
【請求項５】
前記コンピュータ可読命令は、前記バイトのストリングをメディアキーへとハッシュするためのコンピュータ可読命令を含み、
前記メディアキーは、前記メディアファイルの前記署名となる請求項１から４の何れか１項に記載のキャッシュサービスモジュール。
【請求項６】
メディアファイルをキャッシュするためのシステムであって、
前記システムは、
（ａ）リモートメディアソースに格納されたリモートメディアファイルのコピーであるメディアファイルを格納するためのコンピュータ可読記憶媒体を有するキャッシュと、
（ｂ）前記メディアファイルに対するメディアクライアントデバイスからのリクエストを受信するためのコンピュータ可読命令を格納するコンピュータ可読媒体と、プロセッサとを有する帯域幅最適化サーバーと、
（ｃ）前記プロセッサによって実行されるコンピュータ可読命令を格納するコンピュータ可読媒体と、プロセッサとを有するキャッシュサーバーとを備え、
前記キャッシュサーバーは、前記キャッシュにおいて前記メディアファイルが存在するかを判断するキャッシュサービスモジュールを有し、
前記キャッシュサービスモジュールは、
（ｉ）前記リモートメディアソースから、前記リモートメディアファイルのファイルサイズ、及び、Ｍ個のバイト範囲を取得する段階と、
（ｉｉ）前記Ｍ個のバイト範囲におけるバイトを、バイトのストリングに連結する段階と、
（ｉｉｉ）前記バイトのストリングを使用して、前記メディアファイルに対する署名を生成する段階と、
（ｉｖ）前記メディアファイルに対する前記署名を使用して前記キャッシュに問い合わせることを含む、前記メディアファイルが前記キャッシュに存在するかを判断する段階と、
（ｖ）前記キャッシュに前記メディアファイルが存在しない場合には、前記リモートメディアソースから前記メディアファイル全体を取得し、前記署名と共に前記メディアファイルを前記キャッシュに格納する段階とを実行するためのファイル分析モジュールを含み、
前記Ｍは、Ｍ≧２であり、前記Ｍ個のバイト範囲は、前記リモートメディアファイルの開始点を基準としたそれぞれのオフセットで取得され、前記Ｍ個のバイト範囲の各々は、前記リモートメディアファイルの前記ファイルサイズよりも小さいシステム。
【請求項７】
前記リモートメディアソースと通信を行うためのネットワークインターフェースモジュールと、
前記キャッシュから前記メディアファイルを取得し、前記帯域幅最適化サーバーを介して前記メディアファイルを前記メディアクライアントデバイスへと転送するキャッシュインターフェースモジュールとを更に備え、
前記帯域幅最適化サーバーは、前記メディアクライアントデバイスのメディア構造に適応化バージョンを一致させるべく、前記メディアファイルの前記適応化バージョンを生成するためのメディアトランスコーダモジュールを有する請求項６に記載のシステム。
【請求項８】
前記キャッシュサービスモジュールは更に、コンフィギュレーションテーブルを有し、
前記コンフィギュレーションテーブルは、
前記Ｍの値と、
前記Ｍ個の範囲の各々に対して取得されるべきバイト数をそれぞれ規定する所定のパラメータと、
前記リモートメディアファイルの前記ファイルサイズに基づいて、それぞれのオフセットを計算するための所定のパラメータとを格納するためのコンピュータ可読命令を格納するコンピュータ可読媒体を含む請求項６又は請求項７に記載のシステム。
【請求項９】
前記Ｍ個のバイト範囲が重複していない、又は、
前記Ｍ個の範囲全てのバイトの総計が、前記リモートメディアファイルの前記ファイルサイズよりも小さい、又は、
前記オフセットのうちの１つが０に等しいという条件のうちの１以上が満たされている請求項６から８の何れか１項に記載のシステム。
【請求項１０】
前記コンフィギュレーションテーブルは更に、前記メディアファイルに対する所定の閾値を更に有し、
前記キャッシュサービスモジュールは、
前記メディアファイルについて、メディアクライアントデバイスからのメディアリクエストを記録するためのリクエストログモジュールと、
前記メディアファイルに対する前記リクエストログに格納されたリクエストの数と、前記所定の閾値とを比較するための比較器と、
前記メディアファイルが前記キャッシュに存在せず、前記所定の閾値を超える場合には、前記メディアファイルを前記キャッシュへと送信するキャッシュインターフェースモジュールとを更に有する請求項８に記載のシステム。
【請求項１１】
前記ファイル分析モジュールは、前記バイトのストリングをメディアキーへとハッシュし、
前記メディアキーは、前記メディアファイルの前記署名である請求項６から１０の何れか１項に記載のシステム。
【請求項１２】
リモートメディアソースに格納されたリモートメディアファイルのコピーであるメディファイルをキャッシュするための方法であって、
前記方法は、
（ａ）前記リモートメディアソースから、前記リモートメディアファイルのファイルサイズ、及び、Ｍ個のバイト範囲を取得する段階と、
（ｂ）前記Ｍ個のバイト範囲におけるバイトを、バイトのストリングに連結する段階と、
（ｃ）前記バイトのストリングを使用して、前記メディアファイルに対する署名を生成する段階と、
（ｄ）前記メディアファイルに対する前記署名を前記キャッシュに問い合わせることを含む、前記メディアファイルが前記キャッシュに存在するかを判断する段階と、
（ｅ）前記キャッシュに前記メディアファイルが存在しない場合には、前記リモートメディアソースから前記メディアファイル全体を取得し、前記署名と共に前記メディアファイルを前記キャッシュに格納する段階とを備え、
前記Ｍは、Ｍ≧２であり、前記Ｍ個のバイト範囲は、前記リモートメディアファイルの開始点を基準とした対応するオフセットで取得され、前記Ｍ個のバイト範囲の各々は、前記リモートメディアファイルの前記ファイルサイズよりも小さい方法。
【請求項１３】
前記段階（ａ）は、
前記Ｍの値と、
コンフィギュレーションテーブルからの各範囲に対して、取得されるべきバイト数をそれぞれ規定する所定のパラメータと、
前記リモートメディアファイルの前記ファイルサイズに基づいて、オフセットをそれぞれ計算するための前記コンフィギュレーションテーブルからの所定のパラメータとを取得する段階を含む請求項１２に記載の方法。
【請求項１４】
前記Ｍ個のバイト範囲が重複していない、又は、
全範囲のバイトの総計が、前記リモートメディアファイルの前記ファイルサイズよりも小さい、又は、
前記オフセットのうちの１つが０に等しい請求項１２又は１３に記載の方法。
【請求項１５】
前記段階（ｅ）は、前記メディアファイルに対するリクエストログに格納されたリクエストの数と、コンフィギュレーションテーブルに格納された所定の閾値とを比較する段階と、
前記所定の閾値を超えた場合に、前記署名と共に前記メディアファイルを前記キャッシュに格納する段階とを含む請求項１２から１４のうちの何れか１項に記載の方法。
【請求項１６】
前記メディアファイルをリクエストしたメディアクライアントデバイスのメディア構造に適応化バージョンを一致させるべく、前記メディアファイルの前記適応化バージョンを生成する段階と、
前記メディアファイルに対するリクエストログに格納されたリクエストの数と、コンフィギュレーションテーブルに格納された所定の閾値とを比較する段階と、
前記所定の閾値を超え、前記キャッシュに前記適応化バージョンが存在しない場合には、前記署名と共に前記適応化バージョンを前記キャッシュに格納する段階とを更に備える請求項１２から１５の何れか１項に記載の方法。
【請求項１７】
前記段階（ｃ）は、前記バイトのストリングをメディアキーへとハッシュする段階を含み、
前記メディアキーは前記メディアファイルの前記署名である請求項１２から１６の何れか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアファイルの配信に関し、より詳細には、電子ファイルの比較を含むキャッシュを使用したメディアファイルの効率的な配信のためのシステム及び方法に関する。
【０００２】
［優先権情報］
本願は、２００９年１２月１日出願の米国仮出願61/265,676号"System and Methods for Efficient Media Delivery using Cache（キャッシュを利用した効率的なメディア配信のためのシステム及び方法）"の優先権を主張するものであり、前記出願の内容は、参照により本明細書に組み込まれる。
【背景技術】
【０００３】
ユーザーが作成したコンテンツ、いわゆるＵＧＣ（user generated content）を含むメディアファイルは、携帯電話等のユーザー機器を含む様々な種類の端末で生成される。また、メディアファイルは、ネットワーク上にも存在し、ＵＧＣは、このようなサーバーからアップロードされる場合がある。ＵＧＣを格納するネットワークの一例としては、インターネット上のwww.youtube.comが挙げられる。世界中のほぼ全ての場所から、携帯電話又はパソコンのようなエンドユーザー機器を使用して、コンテンツにアクセスすることができる。コンテンツ有する人気のあるサイトへのアクセスは、大量のネットワーク及びサーバートラフィックを発生させる。したがって、効率的にサーバートラフィックを搬送する又は低減する方法及びシステムを開発することが望まれている。
【発明の概要】
【０００４】
本発明は、キャッシュを使用してリモートメディアファイルを効率的に配信するシステム及び方法を提供することを目的とする。
【０００５】
また、電子ファイルの存在を判断することを含む、電子ファイルの比較のためのシステム及び方法を提供することも目的とする。
【０００６】
本発明の一側面によれば、リモートメディアソースに格納されたリモートメディアファイルのコピーであるメディアファイルがキャッシュに存在するか判断するキャッシュサービスモジュールを提供する。当該キャッシュサービスモジュールは、コンピュータ可読命令が格納されるコンピュータ可読記憶媒体を有するファイル分析モジュールを備え、コンピュータ可読命令が、プロセッサによって実行されると、（ｉ）リモートメディアソースから、リモートメディアファイルのファイルサイズ、及び、Ｍ個のバイト範囲を取得する段階と、（ｉｉ）Ｍ個のバイト範囲におけるバイトを、バイトのストリングに連結する段階と、（ｉｉｉ）バイトのストリングを使用して、前記メディアファイルに対する署名を生成する段階と、（ｉｖ）メディアファイルに対する署名を使用してキャッシュに問い合わせることを含む、メディアファイルがキャッシュに存在するかを判断する段階とが実行され、Ｍは、Ｍ≧２であり、Ｍ個のバイト範囲は、リモートメディアファイルの開始点を基準としたそれぞれのオフセットで取得される。
【０００７】
キャッシュサービスモジュールは更に、Ｍの値と、Ｍ個の範囲の各々に対して取得されるべきバイト数をそれぞれ規定する所定のパラメータを格納するコンピュータ可読媒体を有するコンフィギュレーションテーブルを備える。コンフィギュレーションテーブルは更に、リモートメディアファイルのファイルサイズの関数として、それぞれのオフセットを計算するための所定のパラメータを含む。
【０００８】
上述のキャッシュサービスモジュールにおいて、Ｍ個のバイト範囲が重複していない、又は、Ｍ個の範囲全てのバイトの総計が、リモートメディアファイルのファイルサイズよりも小さい、又は、Ｍ個の範囲全てのバイトの総計が、リモートメディアファイルのファイルサイズよりも実質的に小さい、又は、オフセットのうちの１つが０に等しい、という条件のうちの１以上が満たされている。
【０００９】
本発明の実施形態において、コンフィギュレーションテーブルは更に、メディアファイルに対する所定の閾値を更に有し、キャッシュサービスモジュールは、メディアファイルについて、メディアクライアントデバイスからのメディアリクエストを記録するためのリクエストログモジュールと、メディアファイルに対するリクエストログに格納されたリクエストの数と、所定の閾値とを比較するための比較器と、メディアファイルがキャッシュに存在せず、所定の閾値を超える場合には、メディアファイルをキャッシュへと送信するキャッシュインターフェースモジュールとを更に有する。
【００１０】
また、コンピュータ可読命令は、バイトのストリングをメディアキーへとハッシュするためのコンピュータ可読命令を含み、メディアキーは、メディアファイルの署名となる。
【００１１】
本発明の別の側面によれば、メディアファイルをキャッシュするためのシステムが提供される。当該システムは、（ａ）リモートメディアソースに格納されたリモートメディアファイルのコピーであるメディアファイルを格納するためのコンピュータ可読記憶媒体を有するキャッシュと、（ｂ）メディアファイルに対するメディアクライアントデバイスからのリクエストを受信するためのコンピュータ可読命令を格納するコンピュータ可読媒体と、プロセッサとを有する帯域幅最適化サーバーと、（ｃ）プロセッサによって実行されるコンピュータ可読命令を格納するコンピュータ可読媒体と、プロセッサとを有するキャッシュサーバーとを備え、キャッシュサーバーは、キャッシュにおいてメディアファイルが存在するかを判断するキャッシュサービスモジュールを有し、キャッシュサービスモジュールは、（ｉ）リモートメディアソースから、リモートメディアファイルのファイルサイズ、及び、Ｍ個のバイト範囲を取得する段階と、（ｉｉ）Ｍ個のバイト範囲におけるバイトを、バイトのストリングに連結する段階と、（ｉｉｉ）バイトのストリングを使用して、メディアファイルに対する署名を生成する段階と、（ｉｖ）メディアファイルに対する署名を使用してキャッシュに問い合わせることを含む、メディアファイルがキャッシュに存在するかを判断する段階と、（ｖ）キャッシュにメディアファイルが存在しない場合には、リモートメディアソースからメディアファイル全体を取得し、署名と共にメディアファイルをキャッシュに格納する段階とを実行するためのファイル分析モジュールを含み、Ｍは、Ｍ≧２であり、Ｍ個のバイト範囲は、リモートメディアファイルの開始点を基準としたそれぞれのオフセットで取得される。
【００１２】
システムは更に、リモートメディアソースと通信を行うためのネットワークインターフェースモジュールを備える。システムは、キャッシュからメディアファイルを取得し、帯域幅最適化サーバーを介してメディアファイルを前記メディアクライアントデバイスへと転送するキャッシュインターフェースモジュールとを更に備える。帯域幅最適化サーバーは、メディアクライアントデバイスのメディア構造に適応化バージョンを一致させるべく、メディアファイルの適応化バージョンを生成するためのメディアトランスコーダモジュールを有する。メディアクライントデバイスからのリクエストは、当該メディアクライアントデバイスのメディア構造に関する情報を含む。
【００１３】
上述のシステムにおいて、キャッシュサービスモジュールは更に、コンフィギュレーションテーブルを有し、コンフィギュレーションテーブルは、Ｍの値と、Ｍ個の範囲の各々に対して取得されるべきバイト数をそれぞれ規定する所定のパラメータとを格納するためのコンピュータ可読命令を格納するコンピュータ可読媒体を含む。コンフィギュレーションテーブルは更に、リモートメディアファイルのファイルサイズに基づいて、それぞれのオフセットを計算するための所定のパラメータを含む。
【００１４】
上述した発明の実施形態のシステムにおいて、望ましくは、Ｍ個のバイト範囲が重複していない、又は、Ｍ個の範囲全てのバイトの総計が、リモートメディアファイルのファイルサイズよりも小さい、又は、Ｍ個の範囲全てのバイトの総計が、リモートメディアファイルのファイルサイズよりも実質的に小さい、又は、オフセットのうちの１つが０に等しいという条件のうちの１以上が満たされている。
【００１５】
上述のシステムにおいて、コンフィギュレーションテーブルは更に、メディアファイルに対する所定の閾値を更に有し、キャッシュサービスモジュールは、メディアファイルについて、メディアクライアントデバイスからのメディアリクエストを記録するためのリクエストログモジュールと、メディアファイルに対するリクエストログに格納されたリクエストの数と、所定の閾値とを比較するための比較器と、メディアファイルがキャッシュに存在せず、所定の閾値を超える場合には、メディアファイルをキャッシュへと送信するキャッシュインターフェースモジュールとを更に有する。
【００１６】
上述のシステムにおいて、ファイル分析モジュールは、バイトのストリングをメディアキーへとハッシュし、メディアキーは、メディアファイルの署名である。
【００１７】
本発明の別の側面によれば、リモートメディアソースに格納されたリモートメディアファイルのコピーであるメディファイルをキャッシュするための方法を提供する。方法は、（ａ）リモートメディアソースから、リモートメディアファイルのファイルサイズ、及び、Ｍ個のバイト範囲を取得する段階と、（ｂ）Ｍ個のバイト範囲におけるバイトを、バイトのストリングに連結する段階と、（ｃ）バイトのストリングを使用して、メディアファイルに対する署名を生成する段階と、（ｄ）メディアファイルに対する署名をキャッシュに問い合わせることを含む、メディアファイルがキャッシュに存在するかを判断する段階と、（ｅ）キャッシュにメディアファイルが存在しない場合には、リモートメディアソースからメディアファイル全体を取得し、署名と共にメディアファイルをキャッシュに格納する段階とを備え、Ｍは、Ｍ≧２であり、Ｍ個のバイト範囲は、前記リモートメディアファイルの開始点を基準とした対応するオフセットで取得される。
【００１８】
方法は更に、メディアファイルをリクエストしたメディアクライアントデバイスのメディア構造に適応化バージョンを一致させるべく、メディアファイルの適応化バージョンを生成する段階を備える。
【００１９】
方法は更に、キャッシュからメディアファイルを読み出し、メディアファイルをメディアクライアントデバイスに転送する段階を備える。
【００２０】
上述の取得する段階は、Ｍの値と、コンフィギュレーションテーブルからの各範囲に対して、取得されるべきバイト数をそれぞれ規定する所定のパラメータとを取得する段階を含む。上述の取得する段階は更に、リモートメディアファイルのファイルサイズに基づいて、オフセットをそれぞれ計算するためのコンフィギュレーションテーブルからの所定のパラメータとを取得する段階を含む。
【００２１】
上述の本発明の実施形態の方法において、望ましくは、Ｍ個のバイト範囲が重複していない、又は、全範囲のバイトの総計が、前記リモートメディアファイルのファイルサイズよりも小さい、又は、全範囲のバイトの総計が、リモートメディアファイルのファイルサイズよりも実質的に小さい、又は、オフセットのうちの１つが０に等しいのうちの少なくとも１つが満たされる。
【００２２】
上記の方法において、段階（ｅ）は、メディアファイルに対するリクエストログに格納されたリクエストの数と、コンフィギュレーションテーブルに格納された所定の閾値とを比較する段階と、所定の閾値を超えた場合に、署名と共にメディアファイルをキャッシュに格納する段階とを含む。
【００２３】
上述の方法は、（ｆ）メディアファイルをリクエストしたメディアクライアントデバイスのメディア構造に適応化バージョンを一致させるべく、メディアファイルの適応化バージョンを生成する段階と、（ｇ）メディアファイルに対するリクエストログに格納されたリクエストの数と、コンフィギュレーションテーブルに格納された所定の閾値とを比較する段階と、（ｈ）所定の閾値を超え、キャッシュに適応化バージョンが存在しない場合には、署名と共に適応化バージョンをキャッシュに格納する段階とを更に備える。所定の閾値を超えた場合には、署名と共に適応化バージョンをキャッシュに格納する。
【００２４】
段階（ｆ）は、リクエストしているメディアクライアントデバイスの種類をリクエストログに記録する段階と、（ｉ）リクエストログに格納されているリクエストしているメディアクライアントからのリクエストの数と、コンフィギュレーションテーブルに格納されている所定の閾値とを比較する段階と、（ｊ）所定の閾値を超えた場合に、メディアファイルの適応化バージョンを生成する段階とを含む。
【００２５】
上述の方法において、適応化バージョンは、トランスレートされたバージョン又はトランスコードされたバージョンである。
【００２６】
上述の方法において、段階（ｃ）は、バイトのストリングをメディアキーへとハッシュする段階を含み、メディアキーはメディアファイルの署名である。
【００２７】
このように、キャッシュを使用してメディアファイルを効率的に配信する改良されたシステム及び方法が提供される。
【００２８】
以下、本発明の実施形態を、添付の図面を参照して例示する。
【図面の簡単な説明】
【００２９】
【図１】本発明の一実施形態に係る、帯域幅最適化器（Bandwidth Optimizer）１０６を含むメディア配信システム１００のブロック図である。
【図２】図１の帯域幅最適化器１０６の拡張ブロック図である。
【図３】図１のメディア配信システム１００の構成要素内で実行される機能を示す機能図３００である。
【図４】図３の機能モジュール３１４"プロセス最適化要求"の拡張を示した図である。
【図５】図３の機能モジュール３１４"最適化要求を処理"の機能を示したフローチャート５００である。
【図６】図５の段階５０２"リモートメディアの複数部分をフェッチ"、段階５０４"ストリング'Ｓ'へ複数部分を連結"、段階５０６"署名生成"を示したフローチャート６００である。
【発明を実施するための形態】
【００３０】
本発明の実施形態は、インターネットを含むネットワークを介して搬送されるトラフィックの量を低減するという課題に対処するメディア配信システム及び方法を提供するものであり、リモートサーバーからメディアコンテンツをダウンロードすることを望むエンドユーザーの近くに配備することができる効率的なキャッシュメカニズムを提供することによって課題に対処する。
【００３１】
図１は、本発明の一実施形態に係る、帯域幅最適化器（Bandwidth Optimizer）１０６を含むメディア配信システム１００のブロック図である。メディア配信システム１００は、メディアクライアントデバイス１０２、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）プロキシ１０４、帯域幅最適化（Bandwidth Optimizing：ＢＷＯ）サーバーコンピュータ１０８、キャッシュサーバーコンピュータ１１０及びキャッシュメモリ１１２を含む帯域幅最適化器１０６、及び、インターネット１１６を介してキャッシュサーバー１１０に接続されるメディアソース１１４を備える。メディアソース１１４は、典型的には、離れた場所に位置し、リモートメディアソース１１４とも称される。
【００３２】
ＢＷＯサーバー１０８は、コンピュータハードウェア及びソフトウェアから構成されるデバイスであり、例えば、プロセッサ及びコンピュータ可読記憶媒体を有する汎用コンピュータ又は専用コンピュータである。コンピュータ可読記憶媒体としては、例えば、コンピュータメモリ、ＤＶＤ、ＣＤ−ＲＯＭ又はその他の記憶媒体が挙げられ、これらには、ＢＷＯサーバー１０８のオペレーションに関する機能をプロセッサが実行するためのコンピュータ可読命令が格納される。
【００３３】
キャッシュサーバー１１０は、コンピュータハードウェア及びソフトウェアから構成されるデバイスであり、例えば、プロセッサ及びコンピュータ可読記憶媒体を有する汎用コンピュータ又は専用コンピュータである。コンピュータ可読記憶媒体としては、例えば、コンピュータメモリ、ＤＶＤ、ＣＤ−ＲＯＭ、又はその他の記憶媒体が挙げられ、これらには、キャッシュサーバー１１０のオペレーションに関する機能をプロセッサが実行するためのコンピュータ可読命令が格納される。
【００３４】
図１には、１つのメディアクライアントデバイス１０２が示されているが、メディア配信システム１００は、メディアクライアント１０２と論理的に等価な多数のインターネットを可能とするメディアクライアントデバイスを含む、又は、これらにサービスを提供してもよい。"メディアクライアント"という言葉は、パーソナルコンピュータ（ＰＣ）、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン及び携帯電話のような、あらゆる種類のインターネットを利用可能なクライアントデバイスを表す一般的な言葉を意図しており、これらクライアントデバイスは、メディアファイルを受信することができる。
【００３５】
同様に、図１にはリモートメディアソース１１４が１つのみ示されているが、インターネット１１６は、ユーザー生成コンテンツ（ＵＧＣ）サーバーを含むプライベート又はパブリックコンテンツサーバーコンピュータのような数多くのメディアソース１１４にアクセスを提供してもよい。
【００３６】
メディアクライアント１０２とＨＴＴＰプロキシ１０４との間のリンク１２０、ＨＴＴＰプロキシ１０４自体、ＨＴＴＰプロキシ１０４とＢＷＯサーバー１０８との間のリンク１２２、キャッシュサーバー１１０と通信を行うＢＷＯサーバー１０８自体、キャッシュサーバー１１０自体、及び、キャッシュサーバー１１０とメディアソース１１４との間のリンク１１８を使用して、メディアクライアントデバイス１０２は、間接的にメディアソース１１４に接続される。帯域幅最適化器１０６の目的は、キャッシュサーバー１１０と接続されるキャッシュ１１２にメディアファイルをキャッシュすることにより、リンク１１８における帯域幅利用（利用するのに非常に長い又はコストがかかる場合がある）を節約することである。
【００３７】
帯域幅最適化器１０６が提供する更なる機能としては、リンク１２２と同様な帯域幅制限を有してもよいリンク１２０上でのメディア送信のレートを制御し、メディアクライアント１０２の能力と一致させる機能である。好ましくは、必要に応じて、帯域幅最適化器１０６は、メディアクライアント１０２のデバイスの特性にメディアファイルを適合させる。
【００３８】
帯域幅最適化又は適応が必要ない場合には、ＨＴＴＰプロキシ１０４は、帯域幅最適化器１０６をバイパスして、リンク１２４上で直接インターネット１１６にアクセスしてもよい。
【００３９】
図２は、ＢＷＯサーバー１０８を備える帯域幅最適化器１０６を単純化して示した拡張ブロック図であり、ＢＷＯサーバー１０８は、ユニバーサルリソースロケータ（ＵＲＬ）リライトモジュール２０６及びＵＲＬフォワーダモジュール２０８を含むＢＷＯゲートウェイ２０４、メディアバッファモジュール２１０及びメディアトランスコーダ（ＴＲＸ）モジュール２１２を有する。帯域幅最適化器１０６は更に、キャッシュサービスモジュール２１４を含むキャッシュサーバー１１０と接続されるキャッシュ１１２を備える。キャッシュサービスモジュール２１４は、コンピュータ可読命令を有するコンピュータ可読媒体を備え、プロセッサによって命令が実行されると、メディアソース１１４からメディアファイルを取得するタスクの処理が実行され、メディアファイルを格納及び読み出すためのキャッシュ１１２と通信を行い、ＢＷＯサーバー１０８からのメディアリクエストを受信し、キャッシュ１１２から読み出したメディアファイルをＢＷＯサーバー１０８へと送信する。
【００４０】
ＢＷＯサーバー１０８及びキャッシュサーバー１１０の両方が、コンピュータ可読記憶媒体、例えば、１以上のメモリユニット（ＭＥＭ）及び１以上の中央演算処理装置（ＣＰＵ）を含むコンピュータハードウェアに実装される。モジュール２０６−２１４は、ソフトウェアモジュールでありそれぞれ、例えば、ＭＥＭのようなコンピュータ可読媒体に格納され、対応するＣＰＵで実行されるコンピュータ可読命令を有する。ＢＷＯサーバー１０８及びキャッシュサーバー１１０の機能モジュール及びソフトウェアモジュールは、対応するコンピュータ記憶媒体に格納され対応するＣＰＵにおいて実行されるコンピュータ可読命令を含む。一般性を失うことなく、ＢＷＯサーバー１０８及びキャッシュサーバー１１０を、別個のコンピュータ又は１つのコンピュータとして実現してもよい。キャッシュ１１２は、通常、ハードディスク又はその他の好適なメモリ技術に実装されるハードウェア構成要素であり、キャッシュメモリ構成要素の階層構造、及び、ファイル及び関連するファイルキー（key）を格納するのに有用なあらゆる一般的なデータベースソフトウェアを含む。
【００４１】
キャッシュサービスモジュール２１４は、キャッシュサーバー１１０のコンピュータ可読記憶媒体に格納されるコンピュータ可読命令を有するソフトウェアモジュールであり、コンピュータ可読記憶媒体としては、例えば、コンユータメモリ、ＤＶＤ、ＣＤ−ＲＯＭ又はその他の記憶媒体がある。キャッシュサービスモジュール２１４は、メディアファイルを送受信し、メディアファイルをキャッシュ１１２に格納する及びキャッシュ１１２からメディアファイルを読み出すべく、メディアソース１１４及びＢＷＯサーバー１０８と通信を行うのに適している。キャッシュサービスモジュール２１４は更に、キャッシュ動作を制御するべくプログラム可能な所定のパラメータを設定するためのコンフィギュレーションテーブル２１６、及び、メディアリクエストを記録するリクエストログモジュール２１８を備える。また、キャッシュサービスモジュール２１４は、リモートメディアファイルの選択された部分（バイトの範囲）を収集し、リモートメディアファイルのメディアキー２２２とも称されるファイル署名を生成するためのファイル分析モジュール２２０を備える。キャッシュサービスモジュール２１４は更に、リクエストログモジュール２１８に記録されている所与のメディアファイルに対してのリクエストの数と、コンフィギュレーションテーブル２１６に格納されているキャッシュ閾値とを比較するための比較器２２４を備える。キャッシュサービスモジュール２１４はまた、キャッシュ１１２と通信を行うためのキャッシュインターフェースモジュール２２６、及び、メディアソース１１４と通信を行うためのネットワークインターフェースモジュール（ＮＷ  Ｉ／Ｆ）２２８を備える。
【００４２】
メディア配信システム１００のコンテキストを説明するべく、最初に、システムオペレーションの概略について説明する。
【００４３】
メディアクライアント１０２（図１）が、メディアソース１１４のリモートメディアファイルを要求する場合、メディアクライアントは、メディアソース１１４を対象とするターゲットＵＲＬを含むリクエストを、リンク１２０上でＨＴＴＰプロキシ１０４に送信する。ＨＴＴＰプロキシ１０４は、対象ＵＲＬを評価した後に、通常のように、リンク１２４上で直接リモートメディアファイルを取得してもよい。ＨＴＴＰプロキシ１０４に、リモートメディアが最適化を要求していることが示されていた場合には、ターゲットＵＲＬが、ＨＴＴＰプロキシ１０４からＢＷＯサーバー１０８のＵＲＬリライトモジュール２０６に送信されてもよく、そこで、符号のＵＲＬ又はグループＵＲＬである対象ＵＲＬを、帯域幅最適化されたＵＲＬ（ＢＷＯ  ＵＲＬ）へと書き換える。ＢＷＯ  ＵＲＬは、帯域幅最適化器１０６のアドレスをパラメータの形式で含み、メディアソース１１４の実際のＵＲＬ及びメディアソース１１４におけるリクエストされたリモートメディアファイルの完全なパスも含む。ＢＷＯ  ＵＲＬは、ＨＴＴＰプロキシ１０４を介して、メディアクライアント１０２に戻され、そこで、ＢＷＯ  ＵＲＬを使用してリクエストが再構成されて再送されてもよい。
【００４４】
図１に示すように、ＨＴＴＰプロキシ１０４及び帯域幅最適化器１０６は通常、２つの別個のサブシステムとして設けられるが、リンク１２２によって接続されるので、これら２つのサブシステムが物理的に異なるロケーションに位置する、又は、異なる商業団体が管理することを可能としている。適切であると考えられる場合には、ＨＴＴＰプロキシ１０４の機能をＢＷＯサーバー１０８に含めることができ、これにより単純化できると考えられる。
【００４５】
ＢＷＯ  ＵＲＬは、メディアクライアント１０２からＨＴＴＰプロキシ１０４へと送信されて、ＢＷＯサーバー１０８のＵＲＬフォワーダモジュール２０８を介して、ＢＷＯ  ＵＲＬは、キャッシュサービスモジュール２１４に転送される。キャッシュサービスモジュール２１４は、以下に説明する本発明の方法により、リモートメディアファイルのコピーが既にキャッシュ１１２に存在するか否かを判断する。存在しない場合には、キャッシュサービスモジュール２１４は、キャッシュされたメディアファイルを、ＢＷＯサーバー１０８のメディアバッファモジュールを２１０を介して、リンク１２２上でＨＴＴＰプロキシ１０４を介して、メディアクライアント１０２に送信する。
【００４６】
リモートメディアファイル又はそのキャッシュされたコピーを、メディアクライアント１０２の要求を満たすように適応させる必要が生じる場合があり、その場合には、メディアＴＲＸモジュール２１２が呼び出されて、必要な適応機能を提供する。適応化されたバージョンのリモートメディアファイルが既にキャッシュに存在している場合には、メディアＴＲＸモジュール２１２はバイパスされる。適応化されたバージョンは、メディアクライアント１０２の特定のデバイスの種類のメディア構造に一致するトランスコーディングされたバージョンであってもよい、又は、メディアが、メディア構造を変更することなくビットレートを低減させるために再エンコードされただけである場合には、適応化されたバージョンは、単純にトランスレートバージョンであってもよい。
【００４７】
メディアクライアント１０２からのリクエスト内に含まれる情報、例えば、共通のデバイス種類に対してメディア構造をリストしたコンフィギュレーションテーブル２１６に含まれるテーブルを使用して、トランスコーディングするためのメディア構造が推定される。適応化された又はトランスレートされたバージョンへのリクエストは、リクエストログ２１８に記録されてもよく、リクエスト対象のメディアファイルに関する情報だけでなく、リクエストを行うメディアクライアントのデバイス種類に関する情報も含めて記録されてもよい。コンフィギュレーションテーブル２１６に格納される閾値は、リクエストに応答してトランスレートされた又はトランスコーディングされたバージョンをいつ生成するかを判断するのに使用されてもよい。リクエストを行うデバイスの種類のメディア構造に関する完全な情報が入手不可能であり、デバイスのビットレートの制限に関する情報のみが入手可能であるような場合に、トランスレートバージョンが生成されてもよい。トランスコーディングバージョンは、特定のメディアファイルに対する特定のデバイスからのリクエストに関する閾値を超えた場合にのみ、生成されてもよい。
【００４８】
トランスコーディングされたバージョンでは、例えば、メディアのフレームレート、又は、メディアのＸ及びＹ寸法は、受信デバイス（メディアクライアント１０２）に適応させるべく変更されている。メディアファイルをトランスコーディングする実用的な方法が、発明者Stephane Coulombe、２００８年６月３０日出願の米国特許出願第12/164,836号明細書"System And Method For Quality-Aware Selection of Parameters In Transcoding of Digital Images（デジタル画像のトランスコーディングにおけるパラメータの品質指向選択のためのシステム及び方法）"に記載されており、その内容は参照により本明細書に組み込まれる。
【００４９】
図３は、メディアクライアント１０２によるメディアのリクエストの結果、メディア配信システム１００の構成要素内で実行される機能のシーケンス例を示した機能図３００である。実行のシーケンスを示すべく矢印で機能が接続されており、典型的な場合が示されている。
【００５０】
メディア配信システム１００の構成要素名は、図の上部に示されており、構成要素間は、縦の点線によって区切られて示されている。
【００５１】
シーケンスは、メディアクライアント１０２における機能３０２"クライアント生成リクエスト"から開始する。初期ターゲットＵＲＬを含むリクエストは、ＨＴＴＰプロキシ１０４によって受信されて、機能３０４"初期リクエスト処理"において処理される。
【００５２】
このリクエストは最適化されるべきであると決定されると、ＨＴＴＰプロキシ１０４は、リクエストをＢＷＯサーバー１０８に転送し、機能３０６"初期リクエストをリダイレクト"におけるＵＲＬリライトモジュール２０６により、初期ターゲットＵＲＬが書き換えられる。ここで、初期ターゲットＵＲＬは、ＢＷＯ  ＵＲＬに変換される。
【００５３】
そして、"リダイレクト"を示すリターンコード"３０３"がＢＷＯ  ＵＲＬと共に、ＨＴＴＰプロキシ１０４に戻されて、そこでＢＷＯ  ＵＲＬはリターンコード"３０３"と共に、プロトコル機能３０８"リターン３０３、ＵＲＬ"においてプロトコルデータユニットへとリパッケージされて、メディアクライアント１０２へと返送される。
【００５４】
ＨＴＴＰプロキシ１０４とＢＷＯサーバー１０８との間のトラフィックは、図３に示すＢＷＯサーバー１０８におけるＵＲＬリライト（書き換え）を含んでもよい。これに替えて、メディアクライアント１０２からの初期リクエストは、ＢＷＯサーバー１０８のＵＲＬリライトモジュール２０６が関与することなく、ＨＴＴＰプロキシ１０４によって、ＢＷＯサーバー１０８に対してトランスパレントにプロキシされてもよい（すなわち、ＢＷＯ  ＵＲＬ置換されてもよい）。
【００５５】
メディアクライアント１０２は、インターネットにおけるメディアファイルを対象とするターゲットＵＲＬを含む初期リクエスト（クライアント生成リクエスト）を送信する。ＨＴＴＰプロキシ１０４には、どのドメインＵＲＬをＵＲＬリライトモジュール２０６又はディレクトリに送信するか、及び、ＢＷＯサーバー１０８にトランスパレントに転送するかを決定するための規則が設けられている。ＨＴＴＰプロキシ機能は、本発明の範囲外のその他の機能も含んでいてもよい。メディアクライアント１０２との通信は、典型的にはＨＴＴＰを使用して行われるが、ＨＴＴＰプロキシ１０４とＢＷＯサーバー１０８との間の通信も、ＨＴＴＰベースの軽いプロトコルでありプロキシ／サーバーの相互作用のために設計されており、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）のRecommendation for Comment（ＲＦＣ）３５０７に規定されているインターネット・コンテント・アダプテーション・プロトコル（ＩＣＡＰ）に基づいてもよい。
【００５６】
ＢＷＯサーバー１０８は、転送されてきたリクエストを直接扱うため、又は、図３に示す機能３０６（初期リクエストをリダイレクトする）におけるＢＷＯ  ＵＲＬを生成するために、ＩＣＡＰサーバーを実装してもよい。ＢＷＯサーバー１０８では、初期ターゲットＵＲＬを含むＩＣＡＰに封入された初期リクエストが分析される。リクエストされたメディアを提供することができるサービス又はデバイスの実際のＵＲＬを読み出すべく、発行されたＵＲＬ又はグループＵＲＬのような初期ターゲットＵＲＬの解釈が行われる。実際のＵＲＬが、ＢＷＯ  ＵＲＬへと変換されて、ＨＴＴＰリダイレクトコマンドが、ＨＴＴＰプロキシ１０４へと戻されて、ＨＴＴＰプロキシ１０４はプロトコル機能３０８（リターン３０３、ＵＲＬ）を使用して、ＢＷＯ  ＵＲＬをメディアクライアント１０２に戻す。
【００５７】
ここで簡単に説明されたＩＣＡＰを使用した方法は、ＨＴＴＰプロキシ１０４とＢＷＯサーバー１０８との間の通信の単なる一例に過ぎず、単純なトランスパレントプロキシのようなその他の方法を使用してもよい。
【００５８】
再リクエスト機能３１０"新規ＵＲＬを転送"では、メディアクライアント１０２がリダイレクトコマンドを認識し、今度は、ＢＷＯ  ＵＲＬを使用して"最適化された"リクエストをＢＷＯサーバー１０８に送信する。最適化されたリクエストは、メディアソース１１４におけるメディアファイルを示す実際のＵＲＬをパラメータとして含む。
【００５９】
図４には、メディアクライアント１０２、ＨＴＴＰプロキシ１０４及びＢＷＯサーバー１０８の間のやり取り４００の例の段階を例示した要約されたフローチャートが示されている。フローチャートには、次のような段階が含まれる。
４０２"クライアントが初期リクエストを送信"
４０４"プロキシが初期リクエストを受信"
４０６"リクエストを分析"
４０８"最適化が必要？"
４１０"初期リクエストに規則セットを適用"
４１２"初期ＵＲＬをＢＷＯ  ＵＲＬへと変更"
４１４"コード３０３及びＢＷＯ  ＵＲＬをクライアントに送信"
４１６"クライアントがＢＷＯリクエストを送信"
４１８"プロキシがＢＷＯリクエストを受信"
４２０"ＢＷＯリクエストをキャッシュサーバーに渡す"
４２２"リクエストをインターネット宛先に転送"
【００６０】
段階４０２"クライアントが初期リクエストを送信"において、メディアクライアント１０２は、メディアファイルに対する初期リクエストをＨＴＴＰプロキシ１０４に送信する。
【００６１】
段階４０４"プロキシが初期リクエストを受信"では、ＨＴＴＰプロキシ１０４は、メディアクライアント１０２から初期リクエストを受信する。
【００６２】
段階４０６"リクエストを分析"では、ＨＴＴＰプロキシ１０４は、リクエストに含まれるＵＲＬを分析して、メディアソース１１４の正しいＵＲＬ及びリクエストを行ったリモートメディアファイルのパスを決定する。
【００６３】
段階４０８"最適化が必要？"では、ＨＴＴＰプロキシ１０４は、リクエストのＵＲＬが、最適化される必要があるメディアファイルを参照しているかを判断する。
【００６４】
最適化が必要ない場合（段階４０８において"Ｎ"を返答）には、段階４２２"リクエストをインターネット宛先に転送"に進み、最適化が必要な場合（段階４０８において"Ｙ"を返答）には、段階４１０"初期リクエストに規則セットを適用"に進む。
【００６５】
段階４０８"最適化が必要？"では、帯域幅最適化器１０６によって最適化できないメディアリクエストを含む、その他の種類のトラフィックに対する要求をフィルタして、このようなリクエストについては、段階４２２"リクエストをインターネット宛先に転送"において、帯域幅最適化器１０６をバイパスしてリンク１２４（図１）上で、要求されたインターネット宛先に直接転送される。
【００６６】
段階４１０"初期リクエストに規則セットを適用"において、設定された規則セットが、初期リクエストのＵＲＬに適用される。このプロセスにより、先に説明した、ＢＷＯ  ＵＲＬが生成される。
【００６７】
段階４１２"初期ＵＲＬをＢＷＯ  ＵＲＬへと変更"におて、初期ターゲットＵＲＬがＢＷＯ  ＵＲＬで置き換えられたリダイレクトメッセージが生成される。
【００６８】
図３に示すように、段階４１０及び段階４１２は、望ましくはＢＷＯサーバー１０８の機能３０６（初期リクエストのリダイレクト）において実行される。これに替えて、機能３０６がＨＴＴＰプロキシ１０４に位置していてもよい。
【００６９】
段階４１４"コード３０３及びＢＷＯ  ＵＲＬをクライアントに送信"において、ＵＲＬリダイレクトコード３０３及びＢＷＯ  ＵＲＬを含むリダイレクトメッセージが、メディアクライアント１０２に送信される。
【００７０】
段階４１６"クライアントがＢＷＯリクエストを送信"において、メディアクライアント１０２は、初期リクエストのＵＲＬをＢＷＯ  ＵＲＬで置き換えて、帯域幅最適化器（ＢＷＯ）リクエストとなる修正されたリクエストを生成して、このＢＷＯリクエストをＨＴＴＰプロキシ１０４に送信する。
【００７１】
段階４１８"プロキシがＢＷＯリクエストを受信"において、ＨＴＴＰプロキシ１０４は、ＢＷＯリクエストを受信して、直接ＢＷＯサーバー１０８に渡す。
【００７２】
段階４２０"ＢＷＯリクエストをキャッシュサーバーに渡す"において、ＢＷＯサーバー１０８は、ＢＷＯリクエストを直接キャッシュサーバー１１０に渡し、そこで実際の最適化が実行される（図５参照）。
【００７３】
一例として、次のような単純なフローが挙げられる。
メディアクライアント１０２がＨＴＴＰ  ＧＥＴリクエストを、ＵＲＬ  http://lscache6.youtube.com/videoplaybackに送信する（段階４０２）。  ＨＴＴＰプロキシ１０４は、リクエストを受信して、リクエストＵＲＬに設定された規則セットを適用する（段階４１０）。ここで、Youtubeの動画リクエストに対する規則セットは、フォームの一般的な表現"*.youtube.com/videoplayback*"を使用して表されてもよく、これは、リクエストＵＲＬと一致している。  ＨＴＴＰプロキシ１０４は、ＨＴＴＰ３０３リダイレクト応答を、帯域幅最適化器（ＢＷＯサーバー１０８）を指すロケーションヘッダ、及び、それに続く初期ＵＲＬを含むパラメータ、例えば、http://optmizer.vatrix.com/?url=ls6ache.youtube.com%2Fvideoplayback.で、メディアクライアント１０２に送信する（段階４１４）。
【００７４】
機能的に言えば、ＢＷＯサーバー１０８のＵＲＬフォワーダ２０８は、最適化されリダイレクトされたリクエストを受信し、機能３１２"受け渡し"において、それをキャッシュサーバー１１０のキャッシュサービスモジュール２１４に渡して、機能モジュール３１４"最適化要求を処理"において処理が行われる。
【００７５】
図３には、更なる機能モジュールが示されている。
３１６"部分的なメディアを返す"
３１８"完全なメディアを返す"
３２０"メディアをキャッシュに送信"
３２２"キャッシュされたメディアを再生"
３２６"メディア適応化"
３２４"メディアをバッファ"
３２８"クライアントがメディアを使用"
これらの機能モジュールについては、以下に図５を参照して機能モジュール３１４"最適化要求を処理"を説明した後で、理解されるであろう。
【００７６】
図５は、機能モジュール３１４"最適化要求を処理"の機能を示したフローチャート５００であり、キャッシュされたバージョンが存在する場合には、リクエストされたメディアのキャッシュされたバージョンを取得する高レベル段階、及び、存在しない場合には、リモートファイルを取得してキャッシュする段階が示されている。これら段階には、以下の段階が含まれる。
５０２"リモートメディアの複数部分をフェッチ"
５０４"複数部分をストリング'Ｓ'に連結"
５０６"署名を生成"
５０８"メディアがキャッシュに存在？"
５１０"完全なメディアファイルをフェッチ"
５１２"適応化バージョンがキャッシュに存在？"
５１４"バージョンを選択"
５１６"メディアをキャッシュすべき？"
５１８"メディアをキャッシュ"
５２０"メディアを適応化"
５２２"適応化バージョンをキャッシュすべき？"
５２４"適応化バージョンをキャッシュ"
【００７７】
段階５０２"リモートメディアの複数部分をフェッチ"において、キャッシュサービスモジュール２１４は、ＢＷＯ要求（ラベル"Ａ"）を受信し、ＢＷＯ要求において特定されたリモートメディアファイルの選択された部分を取得するべく、メディアソース１１４と通信を行う（ラベル"Ｂ"）。選択された部分は、メディアソース１１４の機能３１６"部分的なメディアを返す"（図３）によってリモートメディアファイルから抽出され、機能モジュール３１４"最適化要求を処理"に送られて、段階５０４"複数部分をストリング'Ｓ'に連結"において受信及び処理される。
【００７８】
段階５０２"リモートメディアの複数部分をフェッチ"の読み出しプロセスは、レンジヘッダを含む一連のＨＴＴＰ  ＧＥＴリクエストを使用してもよく、それにより、ＨＴＴＰクライアント（すなわち、キャッシュサーバー１１０）は、リモートファイルのサイズ（コンテンツ長ＣＬ）を判断することができ、ＨＴＴＰサーバー（メディアソース１１４）から特定の範囲のバイトを要求することができる。応答は、要求されたバイトのみを含み、また、リモートメディアファイルの全長を示すコンテンツ長ヘッダを含む。
【００７９】
段階５０２"リモートメディアの複数部分をフェッチ"は、次のような簡単なフローとして要約できる。
メディアの開始点における初期範囲のバイトに対する第１リクエストを送信
コンテンツ長ヘッダを取得するべく、バイトを取得して応答ヘッダを処理
構成及びコンテンツ長"ＣＬ"に基づいて、要求する次のバイト範囲を決定
選択されたファイル部分の要求されたバイト全てが取得されるまで、次に続くバイト範囲のリクエストを実行
【００８０】
図６には、図５の段階５０２"リモートメディアの複数部分をフェッチ"、段階５０４"ストリング'Ｓ'へ複数部分を連結"、段階５０６"署名生成"の詳細な例を示したフローチャート６００が示されている。
６０２："第１リクエストを送信"
６０４："応答を分析：コンテンツ長を取得"
６０６："Ｍ個のリクエストに対する範囲及びオフセットを決定"
６０８："ｉ：＝１に設定；Ｎ０バイトを有する'Ｓ'を読み込む"
６１０："次のリクエストを送信（範囲Ｒｉ）"
６１２："受信したＮｉバイトを連結して'Ｓ'とする"
６１４："ｉがＭ未満？"
６１６："ｉをインクリメント"、及び、
６１８："メディアキー：＝ハッシュ（Ｓ）"
【００８１】
ラベル（Ａ）（図３及び図５参照）から開始して、段階６０２"第１リクエストを送信"において、第１ＨＴＴＰ  ＧＥＴリクエストがメディアソース１１４に送信され、コンテンツ長（リモートメディアファイル全体のサイズ）を要求し、必要に応じて、リモートメディアファイルの始まりからＮ０バイトである第１範囲、すなわち、範囲＝０からＮ０−１を要求する。Ｎ０の値は固定されていてもよいし、コンフィギュレーションテーブル２１６から取得されてもよい。第１ＧＥＴリクエスト及びそれに続くＧＥＴリクエストは、図３及び図５において（Ｂ）で示されている。
【００８２】
段階６０４："応答を分析：コンテンツ長を取得"において、第１ＨＴＴＰ  ＧＥＴリクエストに対する応答、部分的な応答メッセージが受信され分析される。これは、ファイルのサイズを示すコンテンツ長が含まれ、要求された場合には、第１範囲のＮ０バイトも含まれる。この応答メッセージ及びこれ以降の応答メッセージは、図３及び図５において、（Ｃ）で示されている。
【００８３】
段階６０６："Ｍ個のリクエストに対する範囲Ｒｉを決定"において、設定された所定のパラメータに基づいて、次に続くリクエストの数及びそのバイト範囲が決定される。複数の範囲、各範囲のサイズ、及び、リモートファイル内の各範囲のロケーションを決定する規則は、望ましくは、コンフィギュレーションテーブル２１６に規定される。例えば、（段階６０２における第１リクエストの）オフセット０における第１範囲のＮ０バイトに加えて、所定数のＭ個の範囲が規定されてもよく、これら範囲の各々は、Ｎｉバイトの長さを有し、ファイル内で所定のオフセットで開始する。これに替えて、第１範囲のバイト、及び、Ｍ個の（次に続く）範囲のバイトは、Ｍ個の範囲に組み合わせられもよい、すなわち、"Ｍ"は、オフセット０で第１範囲を含む全ての範囲を含む。第１範囲のＮ０バイトが別個に規定される理由は、第１リクエスト（段階６０２）は、少なくともコンテンツ長を取得するのに必要であるが、同時にファイルの開始点からの一定の範囲のバイトを取得することは任意であるからである（以下に説明する論理的根拠を参照）。
【００８４】
オフセットは、リモートメディアファイルのコンテンツ長（ＣＬ）の比率Ｆｉ（ｉ＝１からＭ）として規定されてもよい。この場合、次に続く範囲のロケーションは、Ｒｉ＝［ＣＬ＊Ｆｉ…ＣＬ＊Ｆｉ＋Ｎｉ−１）として計算してもよい。次に続くリクエストのファイルロケーションをその他の方法を使用して求めてもよく、例えば、実際のコンテンツ長に応じて、少数の又は多数のリクエストを動的に規定してもよい。個々の範囲に対して選択されるサイズは、変数であってもよい、すなわち、次に続く範囲における変数Ｎｉ個のバイトとして規定されてもよいし、又は、各範囲に対して固定数であるＮバイトを規定してもよい。範囲を決定するその他の規則が、本発明の範囲内で容易に想定されることは明らかである。
【００８５】
複数のバイトの範囲は、実質的には、完全なリモートメディアファイルのバイトからの別個のサンプルを構成する。リモートメディアソース１１４へのネットワークトラフィックを大幅に低減させるため、Ｍ個の範囲全てのバイトＮｉの合計と第１範囲のＮ０バイトとを足し合わせたバイト数は望ましくは、商業団体における完全なリモートメディアファイルのバイト数よりも小さく、例えば、１％未満といったようにかなり小さいことが更に望ましい。リモートメディアファイルが小さい場合には、選択された範囲が実際に重複してしまう場合もあるが、通常は、リモートメディアファイルのサイズは、選択された範囲全てにおけるバイト数よりも十分大きい。オフセット因子を利用して、複数の範囲がファイルの全長にわたって分散するようにし、望ましくは、重複が全く発生しないようにする。
【００８６】
次に示すのは、コンフィギュレーションテーブル２１６に格納される設定パラメータのセットの単純化された例である。Ｎ０＝２５６、Ｍ＝３、Ｎ（固定）＝１０２４、及び、ｉ＝１から３の場合、Ｆｉ＝１／４、１／２及び３／４。この構成において、少なくとも４０９６バイトの長さを有する任意のメディアファイルの場合、次に続く連結（段階６１２）及びハッシング（段階６１８）において、重複が存在しないような４つの範囲、全部で２５６＋３＊１０２４＝３３２８バイトが求められる。同じパラメータを使用して、１メガバイトの長さの典型的なメディアフィルの場合、範囲のセットの合計バイト数は、メディアファイルサイズの０．３３％となり、ファイル全体をダウンロードする場合と比較して、ネットワークトラフィックを３００分の１に低減させることができる。
【００８７】
Ｍ個の範囲の実施例では、個々の長さ"Ｎｉ"（ｉ＝０からＭ）及びリモートメディア内での位置が、比率"Ｆｉ"として求められたが、これらの値は、コンフィギュレーションテーブル２１６を使用してプログラム可能であり、異なる値を選択してもよいことは明らかである。
【００８８】
段階６０８"ｉ＝１に設定；Ｎ０バイトを有する'Ｓ'を読み込む"において、第１リクエストに応答して受信された任意のＮ０バイトでストリング"Ｓ"がロードされて、インデックス変数"ｉ"が１に設定される。
【００８９】
段階６１０から段階６１６は、次に続くＭ個のリクエストを送信し、応答を処理するためのループを構成する。ループ構文を使用することにより、"Ｍ"を容易に動的に又は設定により変更可能としている。
【００９０】
段階６１０："次のリクエストを送信（範囲Ｒｉ）"において、ＨＴＴＰ  ＧＥＴリクエストがメディアソース１１４に送信され、Ｎｉバイトを含む範囲Ｒｉをリクエストする。
【００９１】
段階６１２："受信したＮｉバイトを連結して'Ｓ'とする"において、メディアソース１１４からの応答で受信されたＮｉバイトがストリング"Ｓ"として連結される。
【００９２】
段階６１４："ｉがＭ未満？"において、インデックス変数"ｉ"と、次に続くリクエストの所定の数Ｍとを比較する。Ｍ個の範囲が全て受信された場合（段階６１４において"Ｎ"を選択）、ループを抜け、次に段階６１８："メディアキー：＝ハッシュ（Ｓ）"に進む、又は、ループが継続し次の段階６１６："ｉをインクリメント"においてインデックス変数"ｉ"がインクリメントされ、段階６１０："次のリクエストを送信（範囲Ｒｉ）"において再びループに入る。
【００９３】
段階６１８："メディアキー：＝ハッシュ（Ｓ）"において、第１リクエストからのＮ０バイト及びＭ個の範囲全てからの蓄積されたバイト全てを含むストリング"Ｓ"が、メディアキー２２２へとハッシュされる。
【００９４】
数個のセグメントのみからハッシュされたファイル署名（メディアキー）を取得する、すなわち、ファイル全体から導かれる署名の替わりに、メディアファイルのバイトの部分的な範囲又は規定された範囲からファイル署名を取得する理由について、以下に説明する。
【００９５】
ＢＷＯ  ＵＲＬは、リモートメディアファイルを特定する。メディアソース１１４へのトラフィックを低減させるのに、２つの要因が重要となる。１つは、リモートメディアファイルが大きい場合があることであり、もう１つは、メディアソース１１４が、帯域幅最適化器１０６及びメディアクライアント１０２から、地理的に遠い距離に位置している場合があることである。本発明の目的は、概して、キャッシュ１１２に既にファイルが存在している場合には、メディアソース１１４から完全なファイルを読み出すことを回避することである。ＢＷＯ  ＵＲＬは、前にファイルがダウンロード及びキャッシュされた時とは異なっている、又は、リモートメディアファイルの複数のコピーが複数の異なるＵＲＬに存在する可能性があることから、キャッシュサーバー１１０は、リモートメディアファイルのキャッシュされたバージョンが既にキャッシュに存在するか否かを判断するのに、単純にＢＷＯ  ＵＲＬとキャッシュされたＵＲＬとの比較に依存することはできない。
【００９６】
この問題を解決するべく、本発明の実施形態によれば、キャッシュサーバー１１０は、最初に、メディアソース１１４から、リモートメディアファイルの規定数の小さな部分から、代表的なストリング"Ｓ"のバイトのみを取得する。
【００９７】
図５に戻って説明を続ける。
【００９８】
上記したように、段階５０６"署名生成"において、キャッシュサーバー１１０は、ストリング"Ｓ"をファイル署名へとハッシュし、既にキャッシュに存在するファイル署名と比較するために、これを"メディアキー"とする。署名は、キャッシュへのファイルキーとして使用され、一般的なデータベース原理に従って構成される。ファイルキーがキャッシュに見つかった場合には、リモートメディアファイル（のコピー）が格納されていることを意味する。
【００９９】
段階５０２から段階５２４が、ＢＷＯサーバー１０８及びキャッシュサーバー１１０のモジュールにおいて実行される。特に、段階５０２、５０４、５０６及び５２４は、キャッシュサービスモジュール２１４のファイル分析モジュール２２０で実行され、メディアキー２２２が生成される。段階５０８、５１０、５１８及び５２４は、キャッシュインターフェースモジュール２２６に関連する。段階５２０は、ＢＷＯサーバー１０８のメディアＴＲＸモジュール２１２で実行される。段階５１６及び段階５２２は、キャッシュサービスモジュール２１４のコンパレータ２２４で実行され、段階５０２、５０４及び５１０は、ネットワークインターフェースモジュール２２８の利用に関する。
【０１００】
コンテンツのハッシュに基づくキャッシュ方法は、１００％完全ではないことが知られており、異なるコンテンツが同一の署名にハッシュされてしまいキャッシュから正しくないファイルが読み出される可能性が僅かに存在する。このような誤判定の可能性は、ハッシュ関数及びハッシュされる署名のビットサイズを選択することにより、０に近づけることができる。本例の場合、署名としてハッシュするために選択されたメディアファイルの部分の性質及びサイズを、更なる変数としている。署名が異なるファイルで一致してしまうことによる、キャッシュからの正しくないファイルの読み出しが発生する失敗率を０に近づけるために、本願では、複数のロケーションからバイトセグメントを読み出すことを提案する、すなわち、ファイルの開始点からのセグメントのみを使用するのではなく、例えば、ファイルにおける特徴のある所定のバイト範囲を読み出すことを提案する。例えば、同じ映画制作会社の作品には同じ開始部分が使用されるといった場合が存在するように、開始部分のセグメントのみを使用する場合には、誤判定が発生する可能性が高くなる。本発明の実施形態の典型的なシステムについて、ファイルの２５％、５０％及び７５％の３つの位置における読み出しを使用した場合の評価を行った。
【０１０１】
メディアソース１１４によって送信されたリモートメディアファイルの部分をハッシュすることにより、段階５０６"署名を生成"において署名が生成されるが、これは、段階５０２において読み出された個々の範囲のバイトを連結して生成されたストリング"Ｓ"のバイトシーケンスであり、これが、キャッシュサーバー１１０のメモリに格納される。メッセージダイジェストアルゴリズムナンバー５（ＭＤ５）は、本発明の実施形態ではメディアファイルの署名と称されているファイル署名として使用されている１２８ビットハッシュ値を生成するのに広く使用されている暗号化ハッシュ関数である。ＭＤ５は、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）のコメントに対する提言（ＲＦＣ）１３２１に規定されている。ＭＤ５は、段階５０６を実装するのに有効な暗号法ハッシュ関数である。これに替えて、十分にロバストである限り、その他の暗号化ハッシュ関数を使用してもよい。様々な複雑度及び効率を有する好適な暗号化ハッシュ関数のリストが、http://en.wikipedia.org/wiki/Cryptographic_hash_functionに提供されており、よく知られている"ＧＯＳＴ"、"ＨＡＶＡＬ"、"ＰＡＮＡＭＡ"、"ＳＨＡ−０"等のハッシュ関数を含むリストが表として提供されている。
【０１０２】
段階５０８"メディアがキャッシュに存在？"において、署名又はメディアキーを使用して、キャッシュ１１２にアクセス及び照会を行い、要求されたリモートメディアファイルがキャッシュ１１２に存在するかを判断する。
【０１０３】
メディアがキャッシュ１１２に存在しない場合（段階５０８において、"Ｎ"が選択される）、"見つからない（not found）"のリターンコードがキャッシュ１１２からキャッシュサーバー１０８へと送信され、次に段階５１０"完全なメディアファイルをフェッチ"に進み、メディアソース１１４（図中Ｅ）から完全なリモートメディアファイルをフェッチする。メディアソース１１４の機能３１８"完全なメディアを返す"により、完全なリモートメディアファイルが送信され（図中Ｆ）キャッシュサーバー１０８で受信された後、ＢＷＯ  サーバー１０８に転送される。
【０１０４】
段階５１６"メディアをキャッシュすべき？"において、キャッシュサーバー１０８のコンフィギュレーションテーブル２１６を閲覧して、メディアをキャッシュすべきか否かを判断する。コンフィギュレーションテーブル２１６は、読み出された完全なリモートメディアファイルをキャッシュすべきかを判断するプログラム可能なルールを含む。例えば、キャッシュするためのルールとして、キャッシュサーバー１１０のリクエストログ２１８におけるメディアリクエストの全てを記録し、要求されたレートが十分に高く、特定の閾値に達する場合にのみリモートメディアファイルがキャッシュされる。
【０１０５】
段階５１８"メディアをキャッシュ"が、キャッシュサービスモジュール２１４の機能３２０"メディアをキャッシュに送信"で実行され、完全なメディアがキャッシュ１１２に送信されて、前の段階５０６"署名を生成"において先に決定されたメディアキー（署名）に対して格納される。
【０１０６】
メディアファイルがキャッシュされているか否かに関わらず、すなわち、段階５１８"メディアをキャッシュ"又は段階５１６において"Ｎ"が選択されたかに関わらず、以下に説明する段階５２０"メディアを適応化"に進む。
【０１０７】
キャッシュ１１２にリモートメディアファイルが既に格納されている場合（段階５０８において"Ｙ"が選択された場合）、特定の適応化されたバーション、すなわち、リクエストを行っているデバイスであるメディアクライアント１０２の特性に好適に適応したバージョンも、キャッシュ１１２に既に存在している可能性がある。先に説明したように、適用化されたバージョンは、トランスレートされたバージョン又はトランスコードされたバージョンであってもよい。
【０１０８】
段階５１２"適応化バージョンがキャッシュに存在？"において、好適に適応化されタバージョンがキャッシュ１１２に存在するかの判断が行われる。適応化されたバージョンが存在する場合、又は、元の（完全な）メディアファイルがメディアクライント１０２に送信されている（段階５１２において"Ｙ"が選択される）ために適応化バージョンが必要ない場合は、段階５１４"バージョンを選択"においてキャッシュ１１２における適切なバージョンに対するポインタが選択されて、ＢＷＯサーバー１０８の機能３２２"キャッシュされたメディアを再生"に転送される（図中Ｄ）。
【０１０９】
好適な適応化されたバージョンがキャッシュ１１２に存在しない場合（段階５１２において"Ｎ"が選択される）、メディアファイルの適応化を行ってもよい、すなわち、トランスレートされる、又は、段階５２０"メディアを適応化"が、図２のＴＲＸモジュール２１２において実行される機能３２６"メディアを適応化"（図３においてＧ）でトランスレートされる。
【０１１０】
リクエストレートが十分に高く、特定の閾値に達する場合に、適応化バージョンが元のキャッシュされたバージョンから生成される。閾値は、コンフィギュレーションテーブル２１６に設定されてもよい。リクエストは、全種類のメディアクライアントデバイス又はこのようなデバイスの特定のサブセットについて、グローバルにトラッキングされてもよい。デバイスの種類は、メディアクライアント１０２からのメディアＢＷＯリクエストにおけるヘッダから特定される。グローバル閾値は、トランスレートをトリガしてもよく、デバイス固有の閾値は、トランスコーディングをトリガしてもよい。
【０１１１】
段階５２０"メディアを適応化"で生成されたトランスレート及びトランスコードされた両バージョンは、キャッシュに保持されてもよく、段階５２２"適応化バージョンをキャッシュする？"において、リクエストログ２１８及びコンフィギュレーションテーブル２１６に問い合わせを行ってキャッシュするか否かを判断する。
【０１１２】
段階５２４"適応化バージョンをキャッシュ"では、適応化されたバージョンが、予め計算されたメディアキーを使用してキャッシュ１１２に送信される。
【０１１３】
キャッシュ１１２に既に見つけられたメディアファイルのバージョンは、段階５１４"バージョン選択"においてポインタを使用して示され、"リダイレクト"リターンコード（図中Ｄ）を使用してＢＷＯサーバー１０８に送信され、サーバーは、機能３２２"キャッシュされたメディアを再生"において特定されたキャッシュされたメディアファイルを、バッファ機能３２４"メディアをバッファ"を実行するメディアバッファ２１０を介して、メディアクライアント１０２に送信する。
【０１１４】
メディアファイルの適応化されたバージョンがキャッシュされるか否かに関わらず、すなわち、段階５２４"適応化バージョンをキャッシュ"又は段階５２２"適応化バージョンをキャッシュする？"において、"Ｎ"を選択するかに関わらず、特定されたメディアファイルは、バッファ機能３２４"メディアをバッファ"を実行するメディアバッファ２１０及びメディアクライアント１０２へと転送（図のＧ）される。
【０１１５】
このようにして、メディアクライアント１０２は、リクエストしたメディアファイルを受信し、自身の機能３２８"クライアントがメディアを消費"においてメディアファイルを消費（表示又は使用）する。
【０１１６】
ＢＷＯサーバーにおけるメディアバッファモジュール２１０の目的は、メディア自体の特性（例えば、メディアビットレート）に基づいて、又は、設定されたポリシーに従って、メディア配信レートを調節するべく、ＢＷＯサーバー１０８からメディアクライアント１０２へのメディアファイルの送信を制御することである。
【０１１７】
メディアファイルの連結されている部分、すなわち、メディアファイルの個別のバイト範囲の読み出し、及び、１つのメディアキーへのハッシングについて、上記の実施形態例で説明された。本発明の実施形態は、ファイルのキャッシュコピーが帯域幅最適化器１０６に既に存在するか否かを効率的に判断するべく、このような帯域幅に有効な方法を提案する。ファイルをキャッシュするか否かについての規則は、様々に規定及び設定されてもよく、これらについての例が上記でも記載された。例えば、最初の事例発生時には署名のみをキャッシュして、ある時間内における２番目の事例発生時に、完全なファイルをキャッシュしてもよい。非修正（完全な）ファイルのキャッシュ及び適応化バージョンのキャッシュについて、同じ規則又は異なる規則を適用してもよい。
【０１１８】
メディアファイルであるか否か及びリモートであるか否かに関わらず、様々な電子ファイルを、本発明の実施形態の方法及びシステムを使用して比較してもよい。例えば、２つの電子ファイルを以下のような段階に従って比較してもよい。
各電子ファイルについて：
Ｍ≧２であり、電子ファイルの開始点を基準とした所定のオフセットで、バイト範囲をＭ個取得する、各バイト範囲は、電子ファイルのファイルサイズよりも短い；
Ｍ個の範囲におけるバイトを連結して、バイトの１ストリングにする；
バイトのストリングを使用して電子ファイルの署名を生成する；及び
電子ファイルが同一であるかを判断するべく、２つのファイルの署名を比較する。
【０１１９】
電子ファイルの署名を生成する段階は、バイトのストリングをファイルキーへとハッシュする段階を含んでもよく、署名を比較する段階は、２つのファイルキーを比較する段階を含んでもよい。
【０１２０】
２つの電子ファイルを比較するための同様なコンピュータシステムは、上記の方法の段階を実効するプロセッサによって実行されるコンピュータ可読命令を格納するプロセッサ及びコンピュータ可読媒体を備える汎用又は特殊コンピュータに実装されてもよい。
【０１２１】
本発明の実施形態が詳細に説明されたが、当業者であれば、添付の特許請求の範囲に記載される範囲内において、様々な変更及び改良を実施形態に加えることが可能であることを理解できる。
【図１】
0005487457.tif 000002
【図２】
0005487457.tif 000003
【図３】
0005487457.tif 000004
【図４】
0005487457.tif 000005
【図５】
0005487457.tif 000006
【図６】
0005487457.tif 000007