無線端末動的プログラマブルプロキシ
【課題】限られたリソースの携帯端末のためのデータコンテンツのスケジューリング、圧縮及びトランスコーディングに関する。
【解決手段】端末に関連するパラメータに応じて、情報又はコンテンツを転送する方法を提供する。パラメータは、電池レベル、処理リソースステータスとメモリリソースステータス、ネットワークへの接続の性質である。端末は、高い解凍処理オーバヘッドを必要としても端末へのファイル転送時間の改善のため高圧縮率を実現してよい。セットアップは、電池が欠乏し、処理削減を必要とする場合、接続セッション中に変更されてよい。コンテンツを転送する方法は、１つ以上のネットワーク接続上での端末とのトランスコーディング／圧縮情報の転送のスケジューリング又は速度及びタイミングだけではなく、トランスコーディングや圧縮も調整するプログラマブルプロキシデバイス、又は動的に適応可能なプロキシデバイスを使用して実現される。
【解決手段】端末に関連するパラメータに応じて、情報又はコンテンツを転送する方法を提供する。パラメータは、電池レベル、処理リソースステータスとメモリリソースステータス、ネットワークへの接続の性質である。端末は、高い解凍処理オーバヘッドを必要としても端末へのファイル転送時間の改善のため高圧縮率を実現してよい。セットアップは、電池が欠乏し、処理削減を必要とする場合、接続セッション中に変更されてよい。コンテンツを転送する方法は、１つ以上のネットワーク接続上での端末とのトランスコーディング／圧縮情報の転送のスケジューリング又は速度及びタイミングだけではなく、トランスコーディングや圧縮も調整するプログラマブルプロキシデバイス、又は動的に適応可能なプロキシデバイスを使用して実現される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソースが制限された携帯端末のためのデータコンテンツのスケジューリング、圧縮及びトランスコーディングに関する。
【背景技術】
【０００２】
ウェブページ及び他のマルチメディアサービスは、ＧＩＦ画像又はＦＬＡＳＨ動画などの大型グラフィックファイル、及びＪａｖａ（登録商標）アプレットなどの自動化されたプロシージャだけではなく、例えばリアルプレーヤビデオクリップなども使用するなど、コンテンツがますます精密化し、豊富になってきている。その結果、生じるウェブページがウェブページサーバから要求側クライアントマシンに転送されなければならない大型のオブジェクトとなることがある。ブロードバンドインターネット接続の使用が増加するにつれて、このような豊富なメディアコンテンツをサポートできるが、多くの他のクライアントは、例えば狭帯域無線接続上であるかもしれないインターネットへのその接続だけではなく、内蔵処理能力と電池寿命の両方の点で限られたリソースを有するマシンをベースにしている。
【０００３】
限られたリソース端末の例は、インターネットに対する相対的に狭帯域な接続（例えばＧＳＭ）だけではなく、限られた電池寿命、限られた処理能力、及びメモリサイズを有する携帯電話である。これらの限られた資源により、端末が前述された豊富なメディアコンテンツを十分にサポートすることは困難になる。例えば、前述されたグラフィックファイルの多くはそのサイズを縮小するために圧縮されるが、これは端末による解凍処理を必要とする。豊富なメディアＨＴＭＬページは１から２ＭＩＰＳ（毎秒１００万の命令）の処理を必要とする可能性がある。明らかにこれは、これを十分にサポートするための処理能力及びメモリの最小閾値を必要とする。加えて、現代の（ｍｏｄｅｒｎ）電池重量の１００ｇが約５×１０８の命令を与え、その結果このような電池はウェブブラウジングを提供する８分間の使用後に放電すると推定されている。
【０００４】
この問題は、ある表現又はフォーマットのオブジェクトを別の表現又はフォーマットに変換する、つまりトランスコードする、トランスコーディングプロキシサーバ又はゲートウェイを使用して対処されてきた。ＷＡＰがイネーブルされたこのような携帯電話機のシステムの概略は、図１に図示されている。トランスコーディングされたオブジェクトは、通常はより小さくなり、携帯端末による処理及び表示により適している。例えば、意味情報を保持する一方で、ビデオクリップなどのコンテンツのいくらかは削除されてよい。言い換えると、オリジナルの豊富なメディアページの簡略なテキスト専用表現だけが、モバイルデバイスで表示されてよい。これにより、処理能力が限られた端末は、依然としてウェブページ上で与えられる基本的な情報にアクセスできる。例えば解凍処理の欠如などの削減された処理負荷は、電池に対するドレインも削減する。追加の利点は、情報が消費するネットワークリソースが少なくなり、オリジナルのフルコンテンツオブジェクトよりも迅速に、狭帯域リンク上のデバイスに転送できるという点である。
【０００５】
トランスコーダプロキシは、米国特許第６５３５９２２号、及びＨａｎら、ＩＢＭトーマス・Ｊ・ワトソン研究所（IBM Thomas J. Watson Research Center）、「モバイルウェブブラウジングのための画像トランスコーディングプロキシ内での動的適応（Dynamic adaptation in an image transcoding proxy for mobile web browsing）」、ＩＥＥＥパーソナル・コミュニケーション・マガジン（IEEE Personal Communications magazine）、１９９８年１２月号にさらに詳細に記載されている。これは、それが性能を改善しないいくつかの状況があるため、仮にもトランスコーディングする、及び／又は圧縮するかどうか、などの考慮すべき事柄を含む。これは、トランスコーディングされたファイルのサイズを予測するトランスコーディングするために要する時間、及びトランスコーディングされたファイル及びオリジナルファイルをダウンロードするために要する時間の推定を必要とする。
【０００６】
Ｈａｎらに説明されるように、トランスコーディングする／圧縮するか否かの決定は多くの異なる基準に基づく場合がある。例えば、これは、推定されるリンク速度での応答時間の予測される改善に基づくことがある―Ｈａｎの図４を参照すること。代わりに、前記決定はストリーミングアプリケーションにおけるデータ単位の一様な送達を実現することに基づく場合がある―Ｈａｎの図１０を参照する。追加の代替策では、圧縮するという決定はデータブロックサイズ及び推定される圧縮待ち時間又は発生する遅延に基づいて圧縮決定ができる。
【０００７】
ＵＭＴＳとして知られている第３世代のセルラーエアインタフェース規格は、トラフィックペイロードに応じて使用されるパケットヘッダ圧縮の種類を変えるための機構（ロバストヘッダ圧縮、つまりＲＯＣＨ）を含む。ヘッダ圧縮は、主にＩＰベース及びビデオベースのアプリケーションのためのパケットヘッダ構造の知識に基づいて作用する。
【０００８】
「ロバストヘッダ圧縮による無線伝送のためのビデオ品質評価（Video quality evaluation for wireless transmission with robust header compression）」Ｆ．Ｆｉｔｚｅｋ、Ｓ．Ｈｅｎｄｒａｔａ、Ｐ．Ｓｅｅｌｉｎｇ、Ｍ．Ｒｅｉｓｓｌｅｉｎ Ａｃｔｉｃｏｍ−０３−００３技術報告書は、ヘッダ圧縮に特有であり、圧縮機とデコンプレッサの両方がパケットヘッダについての状態情報を保持する手法を開示する。これは、特定の「繰り返される」情報を送信し続けなければならないことを回避する。例えば、圧縮器と解凍器の両方がシーケンス番号が連続パケットで特定の方法で（例えば順次に）増加することを知っているために、シーケンス番号は送信されない。これは高い圧縮率を達成するが、エラーを受けやすい。例えば、パケットが失われる場合には、シーケンス番号についての仮定は無効となり、再構築されるパケットは、オリジナルとは異なる。したがって、正しい仮定を確立し直すためにはフォールバック状態が必要とされるが、これを達成するにはいくつかの再送、したがって圧縮率の損失が必要となる。圧縮のレベルは、接続のロバストネス（エラー特性）に合わせられる必要があり、これは動的に変化する。これは、ベースフレームが失われると、全ての予測フレームが無意味になり、エラーの波及が生じ、次のベースフレームが無事に受信されるまで多くの連続するエラーを起こしやすいフレームが生じる、ＭＰＥＧ２圧縮アルゴリズムに似ている。通常、ベースフレームあたりの予測フレーム数はデコンプレッサによって静的に固定されるが、これはエラーに対して多かれ少なかれ免疫性を与えるために動的に変化するであろう。
【０００９】
よく知られているポイントツーポイントプロトコル（ＰＰＰ）などの従来のパケット圧縮方式は、ヘッダ圧縮に加えてペイロードをベースにした圧縮を使用している。パケットペイロード圧縮アルゴリズムは接続確立時に取り決められ、通常、送信前にはパケットのハフマン符号化に基づいており、逆プロセスは受信端で実行される。各パケットペイロードはパケット単位で圧縮されるため、さらに短いパケット又は（グラフィックデータなどの）すでに圧縮されたデータを含むパケットは、より長いパケット又はより高い層で過去に圧縮されていないパケットより低い圧縮率を有することが一般的に知られている。（ＬＺＷ７７又はＬＺＷ７８などの）異なるアルゴリズムを使用するＩＰベースの圧縮は、ＩＥＴＦ ＲＦＣ ２３９３に記載されている―ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／のインターネットエンジニアリングタスクフォースウェブサイト（Internet Engineering Task Force Web Site）を参照する。この種のペイロード圧縮は（例えばＶａｎ Ｊａｃｏｂｓｏｎなどの特殊ヘッダ圧縮アルゴリズムを使用して圧縮できる）パケットヘッダ情報を圧縮しないが、代わりにパケットペイロードに作用するため、小さなパケットは（それ以外の場合、それらはオリジナルパケットより大きくなる可能性があるため）通常まったく圧縮されない場合がある。ＩＰ圧縮制御プロトコル（ＣＣＰ）は、ＩＥＴＦ ＲＦＣ １９６２に記載され、リンク層フレーム内でパケットを結合することに対処できるが、これはさらに高い圧縮率を達成するためにパケットスケジューリングと圧縮を組み合わせる方法を含んでいない。
【００１０】
圧縮方式は、コンテンツについて掘り下げた知識が入手できるプレゼンテーション層及びアプリケーション層でも使用できる。これは、必ずしもサポートされていない、あるいはクライアントデバイスにとって最適でない可能性があるため、トランスコーディングプロキシが導入されるアプリケーションに特有の（つまりトラフィックタイプに特有の）解決策につながる。例えば、標準ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ＨＴＭＬページの圧縮を動的に実行しないが、グラフィック画像又はページに埋め込まれたビデオ／音声データは、様々なアルゴリズム（ｊｐｅｇ、ｐｎｇ、ｇｉｆ、ｍｐｅｇ、ｍｐ３等）を使用して推測的に圧縮される。未処理のＨＴＭＬよりむしろＧＺＩＰ圧縮済みＨＴＭＬページをサポートする圧縮されたＨＴＭＬ又はＣＨＴＭＬは、最新のサーバ及びブラウザソフトウェアに符号化されるが、解凍はブラウザソフトウェア内で行われるので、これはある特定のターゲットプラットフォームに対して最適に行われない可能性がある。したがって、これらの異なる圧縮方式は、解凍が行われるため、及び検索データのために、クライアントブラウザ（又はブラウザプラグイン）によりサポートされなければならない。また、コンテンツの視点から、圧縮フォーマットは、最もよく知られている一般的なブラウザ、及び最も一般的なアクセス方法（例えば、ダイヤルアップ接続又はブロードバンドインターネットアクセス）のために品質と圧縮済みサイズの最善の組み合わせを提供するために、ウェブサイト作成中に選択される。ページあたり２５ｋｂｙｔｅｓ未満の画像を有するなどの特定の経験則が存在するが、これらは様々なネットワーク上でコンテンツにアクセスする全てのデバイスタイプに必ずしも適用できない。
【００１１】
無線アプリケーションプロトコル（ＷＡＰ）は、ＷＡＰコンテンツのＷＡＰに特殊な圧縮済みバイトフォーマットへの圧縮を実行するためにゲートウェイデバイスを使用するが、圧縮済みフォーマットの特定のセットだけがサポートされ、コンテンツは特定のＷＭＬフォーマットで提供しなければならない。
【００１２】
セッション開始プロトコル（ＳＩＰ）内では、指定された解凍アルゴリズムの特定のセットを有さなくても信号パケット上で適切な解凍を実行できるようにする、（バイトコードを用いて）適切に構成できる、汎用解凍仮想マシン（ＵＤＶＭ）を活用する信号圧縮方式が定義される。しかしながら、この概念は、圧縮が一般的にはより計算機的に集約的であり複雑なプロセスであるために、汎用圧縮仮想マシン（ＵＣＶＭ）の指定は含まない。これにより、デコーダはデコーダインプリメンテーションで事前にプログラミングされたアルゴリズムの共通した合意セットを有さなくてもセッションの始まりで（ＵＤＶＭを用いて）プログラミングできるため、解凍アルゴリズムが使用される内容にある程度の柔軟性が許される。
【発明の開示】
【課題を解決するための手段】
【００１３】
大まかに言えば、本発明は情報又はコンテンツを、そのコンテンツのフォーマットを、端末及び／又はそのサービスプロバイダと関連付けられる性能パラメータの数に応じて、端末に又は端末から、あるいはさらに一般的には、インターネットに結合される、例えば無線基地局を含むネットワークに転送するときに変更することによって、転送する方法を提供する。このような性能パラメータは、待ち時間及びスループットなどのネットワーク性能パラメータだけではなく、端末の電池レベル、処理リソース及びメモリリソースなどの端末性能パラメータを含む可能性がある。したがって、例えば、低プロセッサリソースを有する携帯電話は、これがオリジナルコンテンツの低レベル（例えばテキスト専用）のレンダリングを意味するとしても、限られた解凍処理で動作することによりさらに優れたウェブコンテンツレンダリングサービスを提供できる可能性がある。他方、多くのプロセッサリソースを備えるが、狭帯域無線リンクの端末は、これが高解凍処理オーバヘッドを必要としようとも、端末へのファイル転送時間を改善するためにさらに高い圧縮率でさらによい状態になる可能性がある。
【００１４】
コンテンツフォーマット変換は、例えば端末の電池が乏しくなり、処理の削減を必要とする場合、あるいは待ち時間及びスループットなどのネットワークリソースが削減し、補償するための圧縮処理の増加を必要とする場合に、接続セッション中に変更されてよい。これは、既存の手法におけるような特殊規格コーデックの動作パラメータを変更することに限定されないが、ある圧縮及びスケジューリング方式から別の圧縮及びスケジューリング方式への完全な切り替えを可能にする。それは、また、プロキシデバイスで実現されるフレームの圧縮及び伝送のスケジューリングを実行するインテリジェンスも可能にし、したがって端末が、どの記述をいつ要求するのかに関する決定を下さなくてもよいようにする。これにより、次のフレームに対する要求が、過去のフレームが受信された後に行われるため、要求をサーバに戻し、それから次のフレームを端末に送信するための待ち時間は必要とされる期限より長くなる可能性があるという、既存の手法で発生する可能性がある問題が排除される。これは、ネットワーク性能及び端末リソースの可用性を考慮に入れるスケジューリング機能性を組み込んだネットワーク常駐プログラマブルプロキシを有することにより、本構成において回避される。
【００１５】
転送方法は、複数の使用可能なモードの１つから選択されてよい、あるいはそれは条件が変化するにつれて動的に適応されてよい。転送方法は、異なるトランスコーディング及び／又は圧縮アルゴリズム並びにスケジューリング方式を含む多くの伝送パラメータ又は変数で成り立っており、これらは標準化セットの合意アルゴリズムが有っても無くても使用できる。さらに、リンクパラメータは変更されてもよい。これは、他の伝送パラメータの変更と組み合されるとコンテンツフォーマットの変更を増長する。例えば、リンクレートは、エラーの増加を犠牲にして高次変調を使用して増加してよい、あるいはリンクは、例えばＧＳＭからＩＥＥＥ８０２．１１ ＷＬＡＮに切り替えられてよい。
【００１６】
好ましい実施形態では、このコンテンツを転送する方法は、プログラマブル、又は動的に適応可能なネットワーク常駐プロキシデバイス、及び／又は携帯端末を使用して実現される。プロキシデバイス、及び／又は携帯端末は、トランスコーディング済み／圧縮済みの情報を端末及び／又はプロキシデバイスへの転送するスケジューリング又は速度及びタイミングだけではなく、そのトランスコーディング及び／又は圧縮も調整する。プロキシデバイスは、一実施形態ではエンドシステム（コンテンツプロバイダ）に常駐してよいが、モバイル装置までの経路に沿った他の点にも常駐してもよい。
【００１７】
変化する条件、例えば電池の不足又はネットワーク待ち時間の増加に従って伝送方法変数又は伝送パラメータを適用することによって、オリジナルコンテンツをレンダリングする際の端末の性能が最適化される。性能が最適化される方法は、転送されるデータのタイプ（例えば、再生用のテレビ会議、又はビデオファイル）及び／又はユーザの選択（例えば、電池充電間での長い旅行による電池寿命を最大化すること）に依存することもある。
【００１８】
特に、ある態様では、請求項１に記載のプロキシ装置が提供される。
【００１９】
また、請求項３２に従ったプロキシ装置を操作する方法も提供される。
【００２０】
特に、別の態様では、請求項１６に記載の端末装置が提供される。
【００２１】
請求項４３に従って端末装置を動作する方法も提供される。コンテンツフォーマットを修正するという表現は、コンテンツ（情報）の表現を、それを伝達するために使用されるデータ通信プロトコルとは無関係に修正することを指す。このようなフォーマット変更の例は、なんらかのコンテンツの圧縮、解凍、トランスコーディング、及び／又は削除を含む。
【００２２】
トランスコーディング及び圧縮という用語は、明細書を通して同義的に使用され、概して、例えばウェブページからグラフィックを削除し、次にこのデータを、それが例えば携帯電話などの限られたリソースの端末に適するように圧縮することなどのあるフォーマットから、別のフォーマットに情報を変更することを指す。さらに一般的には、符号化は、トランスコーディング及び圧縮を指すためにも使用される。
【００２３】
圧縮方式を適応させるために使用される性能パラメータは、端末の動作環境に関係し、コンテンツの転送を達成する。このようなパラメータは、ネットワーク待ち時間及びスループットなどのネットワークベースのパラメータだけではなく、電池レベル、処理リソースレベル及びメモリリソースレベルなどの端末に特有のパラメータも含む。
【００２４】
伝送パラメータは、圧縮率及び／又はトランスコーディングアルゴリズム、及び符号化されたパケットのネットワーク上への伝送速度などのスケジューリング情報（イベントの予定を立てる周期性及び最大待ち時間ターゲットに関するパラメータ）などの、コンテンツを転送する方法に関係する。
【００２５】
これらの構成は、現在のシステムがその圧縮及び／又はトランスコーディングを（及びスケジューリングも）設計時又はインストール時に設定させる、発明者により特定される問題を克服し、例えば、特定のエアインタフェース規格を使用する使用可能な処理能力が最低の端末などの特定のネットワークアクセスモードに対する最悪のシナリオを対象としている。上記のように特徴付けられた構成は、その現在の動作環境に依存する特定の端末に対して伝送パラメータを最適化することを可能にする柔軟性を提供する。
【００２６】
さらに、圧縮方式の変動は単に誤り率などの無線リンクパラメータの変化に関係しないと言うだけでなく、むしろ、電池レベル及び／又は待ち時間及びパケット損失確率などのネットワークに特有の条件などの端末に特有の条件に関係する。それは、また推定帯域幅、待ち時間、待ち時間変動、無線リンク伝送スケジュールなどの、他のリンクパラメータにも関係してよい。それは、複数のアクティブな無線技術が同時に活用されるマルチモード端末の動作もサポートする。
【００２７】
さらに、端末が（プロキシスケジューリング及び圧縮機能性をプログラミングすることによって）伝送パラメータを制御する実施形態では、それは、基地局又は端末によって直接的に又は間接的に制御されていないプロキシデバイスなどのサードパーティに依存するよりむしろ、独自の現在の動作条件のためにプロキシにより実行されるコンテンツフォーマット変換を最適化できる。
【００２８】
大まかに言えば、別の態様では、ユーザデバイスによる消費のためにコンテンツを変換するプロキシ装置を介して、コンテンツプロバイダからユーザデバイスにコンテンツを転送するシステムが提供される。この変換は、例えば、これらをユーザデバイスに転送する前にトランスコーディングする、及び／又は圧縮することによる、プロバイダから受信されるコンテンツパケットの符号化を含んでよい。ユーザデバイスは、プロキシに、変換の変更を信号で知らせるためにプロキシ装置にフィードバックリンクを提供するように構成される。これにより、ユーザデバイスは、専用のリソースの使用、ユーザデバイスでのコンテンツの表示又はレンダリング、及び／又はコンテンツプロバイダとユーザデバイス間の通信リンクの使用などの多様な要因を最適化するために、受信された（変換された）コンテンツを適応できる。
【００２９】
通信リンクは、通常、ユーザデバイスと無線サービスプロバイダの間の無線リンクを含む。フィードバック誘導コンテンツ変換変更に加えて、無線サービスプロバイダは、リンクの帯域幅を改善するために、さらに、変調速度などの特定の無線リンク伝送パラメータを調整してよい。ユーザデバイスは、この余分な帯域幅をうまく利用するためにコンテンツ変換を調整することによりこれに応えることができる。
【００３０】
大まかに言えば、別の態様では、ユーザデバイスによる消費のためにコンテンツを変換するプロキシ装置を介して、コンテンツプロバイダからユーザデバイスにコンテンツを転送するためのシステムが提供される。この変換は、例えばユーザデバイスへの転送の前にこれらをトランスコーディングする、及び／又は圧縮することによって、プロバイダから受信されるコンテンツパケットの符号化を含んでよい。ソフトウェアコントローラは、様々な変換を実現するためのソフトウェアモジュールをダウンロードするために、ユーザデバイス及び／又はプロキシ装置で利用される。コントローラは、例えば、プロキシ装置により活用される圧縮機モジュールに対応する適切な解凍モジュールを転送するために、局所的に記憶されるモジュールもアップロードしてよい。使用される変換は、好ましくは、コンテンツプロバイダとユーザデバイス間のリンク上の条件が変化するにつれて動的に更新される。変換要件が変化するに従い、ソフトウェアコントローラは適切なソフトウェアモジュールを実現する。
【００３１】
実施形態はほんの一例として、及び制限することを目的とせずに、図面を参照して説明される。
【発明を実施するための最良の形態】
【００３２】
図１は、インターネットなどのネットワーク１、ネットワーク１に接続される無線サービスプロバイダ２、及び無線サービスプロバイダ２に無線で結合される携帯端末３を有する、既知の種類の通信システムを示す。携帯端末３は、通常、インターネット１からのウェブページ情報の限られた検索を可能にするＷＡＰ（無線アプリケーションプロトコル）機能付きの携帯電話である。携帯端末３は、無線サービスプロバイダ２及びインターネット１を通してウェブページ５にアクセスするが、ウェブページコンテンツは、制限された無線帯域幅及び表示機能を有する携帯端末３によって受信及び表示できるように、ＷＡＰゲートウェイデバイス４によって圧縮フォーマットにトランスコーディングされる。
【００３３】
しかしながら、より強力な携帯端末は依然として基本的なＷＡＰサービスに制限され、例えば異なるコンテンツフォーマットを使用して異なる画質を表示するために、そのさらに大きな処理能力を利用することができないため、このようなシステムは制限され、柔軟性がない。他方、例えば追加の圧縮を提供するより精密なシステムを構想できる場合、これは、端末の電池残量が乏しくなり、これに対処するための性能のレベルの低下が望ましいケースでは適切ではない可能性がある。
【００３４】
図２を参照すると、第１の実施形態に従った通信システムが図示されている。システムは、インターネットなどのネットワーク１、無線サービスプロバイダ２、及び改良された携帯端末１３のユーザが所望するコンテンツ（例えばウェブページ又はビデオストリーム）を含むコンテンツプロバイダ１５をさらに備える。システムはネットワーク１に接続される動的トランスコーディングプロキシデバイス１４をさらに備える。
【００３５】
図１のシステムと同様に、ウェブページ、ｅメールサーバ、ビデオサーバ又は他のコンテンツプロバイダ１５のコンテンツは最初に、無線サービスプロバイダ２、及び最終的には携帯端末１３への転送の前にこれを処理する、トランスコーディングプロキシ１４に転送される。トランスコーディングプロキシ１４は、図１のＷＡＰシステムの場合のようにセットトランスコーディングアルゴリズムに制限されないが、代わりに、端末１３の機能に応じて動的にプログラミングされてよい多くのアルゴリズムを有する。端末１３は、プロキシ１４に、多くの所定のアルゴリズムの１つ、又は電池レベル、無線接続（８）容量、処理容量及びメモリ容量などの端末性能パラメータに基づいた（例えば、ＵＲＬにより特定され、例えばＪａｖａ（登録商標）バイトコードで実現される）指定されたアルゴリズムコードインプリメンテーションを使用するように命令する。このようにして、構成コマンド１６が、例えば無線リンク８及びインターネット１上で、端末１３からプロキシ１４に送信される。
【００３６】
プロキシデバイス１４は、多くの伝送パラメータと関連付けられた多くのアルゴリズムを有し、したがって例えば１つのアルゴリズムは、端末１３が高レベルの処理及び電池残量を有するが、狭帯域無線チャネルを有するときに適切となる可能性のある、高度の圧縮を提供してよい。このケースでは、大きなファイルは圧縮し、無線チャネル上で相対的に迅速に端末１３に送信できる。他方、端末１３が、ＩＥＥＥ８０２．１１ｇ ＷＬＡＮなどの大きな帯域幅の無線リンク８であるが、低い処理及び／又は電池のレベルを有する状況が発生する場合、ＸＸは別のアルゴリズムによって得をするであろう。例えば、大きなファイルは高容量チャネル８上で、これらをユーザに提供するために限られた処理で管理できる端末１３に、圧縮を使用せずにあるいは低圧縮で送信することができる。
【００３７】
未圧縮ファイルの伝送／受信から生じる電力消費は、それが圧縮された場合の節電と解凍に必要とされる電力消費の差異に対して釣り合わなければならない。例えば、８０２．１１ａでは、３０ｍ未満の分離で、伝送のための電力消費はデータ（ペイロード）ビットあたり５０ｎＪ未満である。したがって、選択されたアルゴリズムのための圧縮率がｒである場合、解凍処理電力消費はこの圧縮方式を選択するためにビットあたり５０＊（１−ｒ）ｎＪ未満でなければならない。これがどのアルゴリズムが使用されるのかを決定し、これは例えば汎用プロセッサ（ＧＰＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又はハードコードされたＡＳＩＣベースのインプリメンテーションにおいて、動的に構成できる。端末がファイルを（伝送しているのではなく）受信している場合には、電力消費はさらに少なくなり（例えばビットあたり２５ｎＪ）、このケースでは解凍処理電力消費は、前記方式を選択するためにビットあたり２５＊（１−ｒ）ｎＪ未満でなければならない。また、これは、ネットワーク転送待ち時間の削減に対して相殺されるときに圧縮及び解凍の待ち時間が許容されることを仮定している。例えば、ネットワーク待ち時間はビットあたりＮｎｓで推定され、その結果圧縮及び解凍待ち時間は圧縮使用時に待ち時間の利点を有するためにビットあたりＮ＊（１−ｒ）ｎｓ未満でなければならない。
【００３８】
構成コマンド１６は、接続又はセッションセットアップシーケンスの一部としてプロキシデバイス１４に転送でき、次に、プロキシによって使用されるアルゴリズムは接続セッションの持続期間の間固定される。さらに好ましくは、端末１３は、セッションの伝送パラメータ（例えば、圧縮レベル及びいつ圧縮が発生するのかのスケジューリングなど）を動的に変更することに対処するために、接続セッションの間に構成及びステータスコマンドをプロキシデバイス１４に転送するように構成される。これは、端末性能パラメータが無線サービスプロバイダ２との接続セッション中に変化する場合に有利である。例えば、電池レベルが減少するにつれて、あるいはリンク８上でのスループットが削減されるように、おそらくフェージング及び干渉のために無線接続性能が変化する場合である。したがって、プロキシデバイス１４の動作は、コンテンツプロバイダ１５のコンテンツの検索を最適化するために端末１３と関連付けられるリアルタイム状態に合わせることができる。また、これは代替圧縮フォーマットデータの過去の送信されたフレームを再送するためのフィードバックも含むであろう。
【００３９】
端末パラメータは、選択された無線サービスプロバイダ２又は２’に依存してもよい。例えば、図２に図示されるように、モバイルデバイス１３は第１の無線サービスプロバイダ（Ａ）２と第２の無線サービスプロバイダ（Ｂ）２’の間で選択してよい。これは、例えば、セルラーＧＳＭ接続及びＷＬＡＮ ８０２．１１ａ接続であってよい。このケースでは、無線接続容量端末パラメータは、選択されるサービスプロバイダ２又は２’に依存する。これは、代わりに伝送パラメータ又はトランスコーディングアルゴリズムに影響を及ぼす可能性がある。
【００４０】
図２の一般的な方法は、図３に描かれている。端末パラメータは最初に決定される。例えば、端末１３はその現在の電池レベル、処理能力及びメモリ能力、ならびに無線リンク容量を検出し、これらを使用可能にする。これらの端末パラメータに基づいて、例えば適切な伝送パラメータが選択され、圧縮方式が選択され、アルゴリズムがプロキシデバイス１４でプログラミングされる。対応する構成コマンドは、圧縮を行う時と方法の両方を含むこの圧縮機能性を設定するために、プロキシ１４に送信される。説明した機能ステップの種々の形態は、各種のハードウェアに配置できる。例えば、これらの全ては汎用プロセッサ上のソフトウェア又は端末１３で実行されるプログラマブルロジックで実現されてよく、その結果、単に適切な構成コマンド１６がプロキシ１４に送信されることになる。代わりに、端末機能及びリソースステータス収集機能性は端末１３に常駐する可能性があり、プロキシデバイス１４のアルゴリズム選択又は他のインテリジェンスはそれに結合される可能性がある。このケースでは、端末は次に必要な解凍アルゴリズム及びリソースをセットアップするための適切な構成コマンドを送信される。
【００４１】
コンテンツの変化するフォーマット（例えば圧縮タイプ）に加えて、変調又は他のリンクに特有のパラメータも、コンテンツ転送を最適化するために変更できる。
【００４２】
図４は、プロキシデバイス１４の例のアーキテクチャを示し、入力バッファ２１、トランスコーダ処理ブロック又はエンコーダ２２、出力バッファ２３、プロキシコントローラ２４及びスケジューラ２５を備える。プロキシ１４は、エンコーダ処理ブロック２２で使用するためのトランスコーディング及び／又は圧縮コードをダウンロードするために、ソフトウェアコントローラ２６をさらに備えてよい。さらに、プロキシデバイスは、プロキシ専用の圧縮及び／又はトランスコーディングを容易にするために、サービスプロバイダ１５からの圧縮済みパケットを「中立」フォーマットに解凍するための、デコンプレッサ２７を備えてよい。
【００４３】
プロキシは、ネットワーク１上でビデオストリームなどのコンテンツプロバイダ１５からの（例えばビデオフレームを搬送する）パケットを受信する。フレームはデコンプレッサ２７によって解凍され、周知のように受信された順序で入力バッファ２１に記憶される。バッファに格納されたフレームは、スケジューラ２５から受信される命令に従って制御された方法で、エンコーダ処理ブロック２２に渡される。入力バッファ２１は、循環形式で動作してよい。入力バッファ２１により受信されるフレームの率が、これらフレームが移動される率を超える場合には、バッファは他のフレームを上書きし、いくつかのフレームは失される（落とされる）。入力バッファ２１は、例えば１フレームおきに指定されたフレームを落とすようにスケジューラ２５により設定できる。これは、伝えられたフレーム数をなんらかの形式で削減することが必要とされるように、端末１３がフレームのさらに低い速度を単に受け入れることができることをスケジューラ２５が「知っている」ときに発生する可能性がある。スケジューラ２５は、所定数のフレームを、これらをエンコーダ２２に渡す前に最初に記憶するように入力バッファ２１を構成してもよい。これは、エンコーダ２２が、（ＭＰＥＧ２などの）フレーム単位よりむしろフレームのブロックを必要とする圧縮アルゴリズムを使用するために発生する可能性がある。また、入力バッファ２１に記憶されるフレームは、スケジューラ２５によって命令されるときに、同じフレームが別の圧縮フォーマットを使用して再びエンコーダ２２に渡すことを可能にするために、エンコーダ２２に渡された後にもバッファ内に保持されてよい。
【００４４】
エンコーダ処理ブロック２２は、コンテンツプロバイダ１５からの現在のパケット流入を端末１３に適した別のパケット流出に変換するために適した、圧縮及び／又はトランスコーダアルゴリズムを実行する。エンコーダブロック２２は、プロキシコントローラ２４により命令されるように多くの所定のアルゴリズムの内の１つを実行してよい。使用される前記特定のアルゴリズムは、例えば無線リンク帯域幅又は端末１３内の処理リソースのレベルなど端末パラメータが変化するにつれて、端末１３との接続の過程で変化する可能性がある。多岐に渡るアルゴリズムは、プロキシデバイス１４に記憶されてよいか、あるいはそれらは、例えばソフトウェアライブラリ１７から、ソフトウェアコントローラ２６によって必要に応じてダウンロードされてよい。アルゴリズムは、このオプションが使用できる場合オンザフライで構成されてもよい。
【００４５】
エンコーダ処理ブロック２２は、入力バッファ２１から受信したフレームを、伝送又は出力バッファ２３に渡される「新規」フレームに変換する。エンコーダ処理ブロック２２から受信したパケットは記憶され、又は出力バッファ２３によってバッファに入れられ、次にスケジューラ２５によって命令される速度で、及びスケジューラ２５によって命令される時間内のインスタンスで端末１３に転送される。
【００４６】
好ましくは、スケジューラ２５は、代わりに端末パラメータに依存する出力バッファ２３の処理速度によって必要とされるときにだけ、エンコーダ２２にパケットを転送するように入力バッファ２１に命令するように構成される。これにより、エンコーダブロック２２による、それ以外の場合省略されていた可能性があるフレームの不必要な符号化が回避される。また、必要な場合、スケジューラ２５は、（入力バッファ２１に保持される）同じフレームが（エンコーダ２５によって）符号化され、端末からのフィードバックに基づいて端末１３へ同じ又は別のネットワーク上で渡すために２つ以上の異なるコンテンツフォーマットで出力バッファ２３に記憶することを命令する機能を有する。
【００４７】
したがって、スケジューラ２５は、バッファにサービスを提供し、入力バッファ２１からエンコーダ２２に転送するだけではなく、入力バッファ２１内でのパケットの省略も制御する。それは、（適切なネットワーク接続を選択する）適切なネットワーク上での出力バッファ２３から端末１３へのパケットの伝送も制御できる。出力バッファ２３から端末１３への出力速度は、フレーム又はパケットが符号化のために入力バッファ２１からエンコーダ２２に転送される速度によって有効に設定される。スケジューラ２５は、端末１３への伝送スケジュールに関してコントローラ２４から命令を受信してから、入力バッファ及び出力バッファ２１と２３に相応してサービスを提供する。これを示すフローチャートは図５に示される。
【００４８】
スケジューラ２５は、端末における解凍の処理時間（端末における処理速度）及びエンコーダ処理ブロック２２における解凍の処理時間（プロキシにおける処理速度）、エンコーダ入力が動作ごとに必要とするデータ又はフレームの量、及び送達されるデータ又はパケットの量、使用可能なネットワーク接続ごとのネットワーク性能推定値（誤り率、待ち時間及びスループット）などの他の必要な情報だけではなく、コントローラ２４からの端末伝送スケジュールも受信する。それから、スケジューラ２５は、コンテンツプロバイダ１５からパケットを受信する近似（又は実際の）速度を含む、指定された入力バッファ２１からの情報を決定する。例えばＲＳＶＰプロトコルはスループット、バッファサイズ及び現在の占有率を取り決めるために使用できる。このことから、スケジューラ２５は出力バッファサイズを設定し、適切な場合、パケット削除又は省略設定だけではなく適切なネットワークへの伝送の予定をいつ立てるのか、（エンコーダ２２に対する）入力バッファサービス速度及びスケジュールも決定できる。これらの設定は、コントローラ２４によって受信される命令に従って、端末１３へのセッション内のトラフィックフローごとに動的に変更できる。したがって、スケジューラ２５は、いつアルゴリズムを使用する（つまり符号化を実行する）時、及び符号化されたパケットを端末装置に送信する時を指示する。
【００４９】
スケジューラが、ある特定の点がトラフィックストリーム内で（特定のサイズ及び圧縮型の）データの特定のブロックを復号するには、時間４０ｍｓを要すると知っている場合には、フィードバック信号は、端末リソースが変化するとき、あるいは（パケット破壊又は損失などの）予期せぬ出来事が発生するときにのみ必要となり、その時、スケジューラは例えば５０ｍｓを要することを伝える必要がある。同様に、ネットワーク待ち時間がフレーム当たり２０ｍｓである場合には、これは次のブロックを圧縮する時を決定するためにスケジューラ２５によって考慮でき、それにより最小記憶圧縮パケットが存在することになり、故に（目標性能要求に基づく）アプリケーションに解凍データを与える全待ち時間が受け入れできる。
【００５０】
プロキシコントローラ２４は、例えば、セッションがサポートするアプリケーションのタイプだけではなく、誤り率、待ち時間及びスループット、現在のリソースステータス（処理容量及びメモリ容量ならびに電池レベル）などの無線ネットワーク性能などの端末パラメータ又は設定値を含む、端末１３からの制御コマンド又は構成コマンドを受信する。アプリケーションのタイプは、コンテンツプロバイダ１５がある特定のトラフィックフローの中で供給しているコンテンツのタイプに関係し、単に一般的なウェブトラフィック又は画像トラフィック、ファイル転送、ビデオストリーミング、又はボイスオーバＩＰ呼に関する場合がある。この情報から、コントローラ２４は、プロキシ１４と端末１３の間の待ち時間及びスループット、及び必要とされる圧縮又は符号化のレベルなどの多くの伝送パラメータを決定する。端末処理速度又はスケジューリング要件だけではなく圧縮及び／又は符号化の要件からも、コントローラ２４は、エンコーダ処理ブロック２２により実現される適切な圧縮及び／又は符号化アルゴリズムを選択する。これは、ローカルライブラリ２６に記憶される、あるいは遠隔位置１７からダウンロードされるソフトウェアコードであってよい。端末処理速度及びネットワーク待ち時間及びスループット分散などの他のスケジューリングパラメータは、前述されたように入力バッファ及び出力バッファ２１と２３を構成するスケジューラ２５に転送される。このプロセスは図６に描かれている。
【００５１】
各端末―プロキシ接続は専用の入力バッファ２１、エンコーダ２２、出力バッファ２３、及びスケジューラ２５の組み合わせを含む。プロキシコントローラ２４は、それぞれのエンコーダ処理ブロック２２に適切なアルゴリズムを提供するだけではなく、それぞれのスケジューラ２５に対する命令でこれらのそれぞれを制御する。
【００５２】
代替の構成では、端末パラメータから伝送パラメータを決定することは、端末１３で実行される。次に、端末１３は、伝送パラメータを含む構成コマンド１６を、適切なトランスコーディング及び／又は圧縮アルゴリズムを選択、プログラミングし、スケジューラ２５に指示するコントローラ２４に転送する。追加の構成では、構成コマンドは（Ｊａｖａ（登録商標）バイトコードへのＵＲＬなどの）アルゴリズムに対する参照、及びコントローラ２４がスケジューラ２５に渡す必要とされるスケジューリング情報を単に含む場合がある。
【００５３】
ソフトウェアコントローラ２６は、プロキシデバイス１４に、構成コマンド１６により指定されるトランスコーダ／圧縮アルゴリズムソフトウェアモジュールをダウンロードする能力を与える。これらは、例えば端末１３から、あるいはサードパーティライブラリ１７からダウンロードされてよい。追加の代替策では、ソフトウェアコントローラ２６は、オンボードライブラリからソフトウェアモジュールをアップロードするように命令され、端末１３での実現を意図してよい。さらに追加の代替策では、トランスコーダアルゴリズムは、入力バッファ２１から出力バッファ２３に単にフレームを渡してよい。これは、受信されたフレームレートが、端末に伝送する前に減速されることだけが必要とされるときに発生し、その結果、例えば入力バッファ２１はビデオストリーム内で１フレームおきに省略し、それにより端末１３への速度を半減するように構成される。
【００５４】
実施形態はこれまでコンテンツプロバイダ１５から端末１３にコンテンツを転送することに関して説明されてきたが、多くの場合、例えば、双方向ビデオ呼など、端末１３からコンテンツプロバイダ１５にコンテンツを転送するニーズもある。このケースでは、符号化されたパケット又はフレームは端末１３からプロキシデバイス１４によって受信され、プロキシ１４はこれらを復号し、例えばあるフォーマットから別のフォーマットにパケットを解凍及び／又はトランスコーディングし、伝送の前に、おそらく別のタイプの符号化を使用してコンテンツプロバイダ１５にそれらを転送する。プロキシ１４により利用される復号のタイプは、再び前述された符号化決定と類似の方法で指定又は決定できる。
【００５５】
図７は、処理ブロックの伝送と受信の両方を示す端末１３のためのアーキテクチャを描く。端末１３は、入力バッファ３１、エンコーダ処理ブロック３２、出力バッファ３３、スケジューラ３５、及び端末コントローラ３４を備え、その全ては前述されたプロキシデバイス１４の対応する構成部品、及びそれぞれ入力バッファ２１、エンコーダブロック２２、出力バッファ２３、スケジューラ２５、及びプロキシコントローラ２４に類似する。
【００５６】
一実施形態では、端末コントローラ３４は、端末パラメータを決定し、これから前述されたように適切な圧縮体制を実現する。構成コマンドは、コンテンツを適切に受信するために実現するための圧縮／トランスコーディングアルゴリズムをプロキシデバイス１４に知らせるためにそれに送信される。代わりに、端末パラメータは構成コマンドで、使用する適切な復号アルゴリズムを決定するプロキシに転送されてよい。プロキシ１４は、次に端末エンコーダブロック３２内で実現される定義されたアルゴリズムを実現するように端末コントローラ３４に指示する。エンコーダアルゴリズムは、端末１３に記憶される、あるいは端末ソフトウェアコントローラ３６により指定位置からダウンロードされるコードであってよい。
【００５７】
端末コントローラ３４は、プロキシデバイス１４について前述されたように、選択的フレーム省略を起動するために、スケジューラ３５に入力バッファ３１を制御するように指示してもよい。さらに、又は代わりに、コントローラ３４はすでに説明されたような速度調整のためのフレーム複製を実現してよい。これは、例えばアプリケーションが動的に適応するフレームレートを受け入れることができない場合に必要である。
【００５８】
端末は、さらに、プロキシデバイスから受信されるパケットを受信し、復号する受信バッファ３８及びデコーダ処理ブロック３９を備える。デコーダ３９は、エンコーダ２２によって使用されるアルゴリズムを知っているので、例えばパケットを解凍して、プロキシデバイス１４のエンコーダ２２を補完する。符号化／復号アルゴリズムは、構成コマンドを使用してプロキシコントローラ２４と端末コントローラ３４の間で合意される。復号されたパケットは、次に端末処理チェーン又はブロックの残りに渡される。類似した構成は、符号化されたパケットが端末１３から受信され、復号され、コンテンツプロバイダ１５に渡される、プロキシデバイス１４で活用される。
【００５９】
圧縮のレベルは端末の解凍性能に合わせられる。好ましい方法は、無線リンク上での以後の対話を最小限に抑えるために、端末１３にプロキシデバイス１４において圧縮機／トランスコーダ２２をプログラミングさせることによる。通常、高圧縮率を達成するためには圧縮は解凍の少なくとも１０倍複雑であるため、圧縮機が待ち時間要件を満たすために圧縮処理の量を最小限に抑えるために端末１３で実現されるときに、圧縮方式を動的に変更することはきわめて魅力的になる。ＧＰＲＳのような低速の広域ネットワーク（ＷＡＮ）接続は、例えばブルーツース又はＩＥＥＥ８０２．１１上でのローカルエリアネットワーク（ＬＡＮ）接続よりも伝送データのビットあたりで多くの電力を消費するため、理想的には、圧縮のレベルは使用されているネットワークの性能に合わせて最適化されるべきであるが、両方のケースでは、ネットワーク及び端末のステータスからプロキシ構成を動的に変更する能力は、いつでも最善の方式が使用されることを意味する。例えば、マルチモード端末のための１つの考えられる解決策は、ビデオストリーム内でより確実にではなく（決定的待ち時間）ベースフレームを伝送するために、相対的に低速であるが確実なＧＰＲＳ接続を使用するが、機能強化層フレームを伝送するには、より性能が高く、より決定的ではないＷＬＡＮ接続を使用することである。冗長性のために、例えば、ＷＬＡＮ接続とＧＰＲＳ接続の両方でベース層フレームを、ＷＬＡＮ接続においては、機能強化層フレームを送信することも可能である。
【００６０】
これらの実施形態及び他の実施形態をさらに描くために、応用の例が後に続く。ビデオトラフィックの場合、スケジューラ２５は入力バッファ２１にサービスを提供し、特定のフレームレートで符号化するように指示されるエンコーダ２２にフレームを転送し、したがって符号化されたフレームは、例えばビデオの毎秒あたり１２フレームに対応して、出力バッファに、及び端末装置に転送される。入信フレームレートが発信フレームレートより高い場合には、スケジューラ２５は、入力バッファ２１に、あるいはいくつかの実施ではエンコーダアルゴリズム自体（２２）に、適切な場合、フレームを省略するように命令する。前記省略は端末のステータスによって決定でき、例えばフレームは、端末が忙しすぎてそれらを復号できないと予想されるときに省略される（端末の処理速度から決定される）、あるいはネットワークリソース（推定ネットワーク待ち時間）が、次のフレームが送信準備完了となる前にフレームを送達し、それを復号できるには十分でないときに省略される。さらに、端末とプロキシの間に複数のネットワーク接続が存在するとき、プロキシから端末への出力フレームは、フレームのタイプ、及び個々のネットワーク接続の性能推定値に応じて様々なネットワーク接続で送信できる。
【００６１】
この構成は、例えば電池が乏しくなる、又は端末が別の呼を開始したために、その使用可能な帯域幅を削減するために端末パラメータが変更する場合に、ネットワーク接続又は伝送パラメータを変更する能力をサポートする。これは、余分な容量を利用できない、あるいは接続が劣化するときに接続を維持できない、既知の「静的な」又は「固定された」構成での不利な点を克服する。例えば、ある瞬間に毎秒１００ｋｂｉｔが使用できるが、毎秒５６ｋｂｉｔが再生に必要とされる最悪のケースの平均スループットであるという事実に適応しない毎秒５６ｋｂｉｔのビデオ符号化を使用すると、何の適応も実行されない。次に、スループットが毎秒５６ｋｂｉｔ以上であると仮定して、パケットはバッファに入れられ、端末への伝送のためにスケジューリングされ、それ以外の場合、バッファは単にオーバフローし、パケットは失われるであろう（パケットは通常１フレーム分のデータより少なく搬送するので、これは、フレーム内の任意の点に対応するパケットとなるであろう）。
【００６２】
対照的に、実施形態はプロキシ１２で符号化（圧縮）エンティティ２２を動的にプログラミングし、パケットが符号化の後非常に長い間、バッファに入れられることが決してないように、これをスケジューリングと結合する。パケットは廃棄され、それらを圧縮するために使用される処理時間及び処理リソースの浪費を生じさせるため、符号化に続く拡張バッファリングは非効率的である。他の面は、端末の状態が、いつ、どのようにして圧縮が実行されるのかを制御するために使用されるものである。環境が静的である場合には、これは必要ではないが、動的な環境では、端末１３又は異なるネットワークリソースは経時的に変化し、したがってこれは、いつ、どのようにして圧縮が行われるのか、端末への伝送のためにどのネットワークを活用するのかを制御するために使用できる。例えば、端末１３内のプロセッサに対する負荷が、解凍するための処理速度が例えば毎秒２５（つまり、フレームを復号する速度は４０ｍｓ要する）であり、したがってスケジューラが、過去のフレームが復号されている間（つまり４０ｍｓ内に）次のフレームを送信しないことを知っているが、次に別のアプリケーションが起動され、ここでは処理速度が毎秒２０であり（フレーム復号は５０ｍｓを要する）、それからプロキシ１２においてプロキシコントローラ２４がこれを考慮に入れ、フレームを省略することによりフレームレートを減少し、解凍時間を短縮し、処理速度を毎秒２５に加速する圧縮のレベルを削減すると仮定する。さらに、端末が無線伝送／受信及びアプリケーション処理のために取りのけられた異なるリソースを有し、アプリケーション処理がボトルネックである場合には、アプリケーション処理のいくらかは無線通信のために取りのけられているリソースを使用するため、及びその逆のために切り替えることができるであろう。例えば、同じＤＳＰプロセッサが変調及び復調に加えてビデオ解凍のために使用できるであろう。端末処理リソース可用性のこの柔軟性は、プロキシを再構成することにより利用でき、フレームレートは再び毎秒２５に加速できる。
【００６３】
逆に、ネットワーク活動が増加する、あるいは端末が信号フェードに移動中であるために、ネットワークリソースが制限されるようになる場合には、ネットワーク状態も、トランスコーダがパケットが廃棄されるように不必要に圧縮を実行することが決してないように、スケジューリングを制御するために使用される。また、よりタイムクリティカルではないトラフィックが圧縮の前により長くプロキシ２１の入力バッファでバッファに入れることができ、さらに強力な圧縮アルゴリズムが使用され、このようにして圧縮率の利点を獲得できる。このケースでは、ビデオトラフィックは優先順位を取得するが、端末に送信できるトラフィックの量は少なくなるため、フレームレートは相応して減速され、圧縮率はより強力なアルゴリズム又はより低い解像度を使用することにより改善される。代わりに、マルチモード機能端末装置のケースでは、電池電力消費の増加を犠牲にしてさらに高いネットワークスループットを達成するために、２つ以上のネットワーク接続が同時に使用できる。
【００６４】
追加の例では、毎秒２５フレームのビデオストリームは端末１３に宛てられ、プロキシ１４に到達する。端末１３は処理を行い、電池電力リソースは制約され、電力消費を最小限に抑えようとする。端末では最小の処理が必要とされるため、端末１３は、電力効率を最大限にするために低レベルの圧縮で毎秒３フレームというフレームレートを可能にするために、トランスコーディングの予定を立てるようにプロキシ１４をプログラミングする。次に、端末１３は本線供給に接続されるか、あるいは電池が充電され、これが現在のＧＰＲＳ接続上で持続できる最大速度であるため、プロキシ１４は毎秒１２フレームでトランスコーディングを実行するように構成される。
【００６５】
ウェブブラウジングセッションは、ここでまた起動され、端末１３はビデオトランスコーディングの解像度を削減し、ビデオ品質まで破壊を最小限に抑えるために、ウェブトラフィックを、圧縮され、あらゆるビデオフレームの間で送信されるようにスケジューリングする。ウェブセッションは優れた反応性も必要とするが、ビデオほど重大ではなく、したがってウェブページ画像はさらに低い解像度に、及びこの反応性を維持するためにより高い圧縮率（より低い品質）を用いてトランスコーディングされる。その結果、ＷＬＡＮが使用可能になり、ここでプロキシコントローラ２４はビデオフレームレートを毎秒２５フレームまで加速するように構成され、品質（解像度）も改善され、ウェブブラウジングトラフィックはもはや圧縮されないか、あるいは画像はユーザの観点から最高の品質を達成するためにトランスコーディングされる。
【００６６】
変化する状態は、接続が互いに及ぼす影響を考慮に入れ、トラフィックフロー（ビデオ及びウェブブラウジング）ごとに適切な伝送パラメータを決定するプロキシコントローラ２４により監視される。
【００６７】
これらの実施形態により、動的なトランスコーディング／圧縮が可能になり、これを達成するために必要とされるスケジューリングの変更が実現される。これは、好ましくは、（エンドシステムに常駐できるであろう）プロキシエンティティ１４及び端末１３をプログラマブルにすることによって達成される。端末ステータスは、アルゴリズム及び構成コマンドの対話の標準化されたセットを必要としなくても、柔軟にプロキシを動的プログラミングするために使用できるため、このプログラム化可能性はソフトウェアダウンロード及び構成フレームワークを有することによって最も容易に達成される。従来の方法では、ウェブサイト又はプロキシは、端末により動的に構成（プログラミング）することはできないため、柔軟性は限られている。例えば、ダイヤルアップ接続を介して接続されるＷｉｎＣＥ（商標）デバイス、あるいはＧＰＲＳを介して接続されるＷＡＰ電話のために最適化されたビデオサービスはきわめて特殊であり、柔軟ではない。プログラム化可能性により、端末１３は、特殊なアルゴリズムの過去に合意された（つまり標準化された）セットを必要としなくてもどのようにして、いつトランスコーディング又は圧縮が行われるのかを正確に指定できる。プロキシは端末ほど処理リソースや、メモリが制約されておらず、したがって様々なアルゴリズムインプリメンテーションを保持できるため、これは、これらのタイプの構成の配備にはきわめて魅力的である。対照的に、端末は、シナリオの変化ごとに（適切なデコーダプラグインを用いて）それ自体を特殊に構成する必要があり、それは端末１３の仕様及びコストを増加するであろう。
【００６８】
プロキシ１４は、性能のために最適化する、及び必要な場合にリソースが制約された端末の処理及び電力消費の要件を削減するために、圧縮及び伝送の動作のバッファリング及びスケジューリングを可能にする。いつ、どの方式を使用するのかのタイミングをはかる際の精度は、アプリケーション及びユーザの優先順位に応じて端末（又は他の意思決定エンティティ）によって決定できる。例えば、端末内のスケジューリング機能は（端末のコンテキストに基づいて）ユーザからの優先順位によって、高速反応性及び特定のサイズでの全てのグラフィックオブジェクトがより重要であると見なされる（さらに高い優先順位の）テキストオブジェクトに優先して、端末に転送されるのを抑制するための無線接続の現在の低速度のためのアプリケーションを決定できる。
【００６９】
最もリソースが制約されているのは端末であるため、伝送パラメータ決定機能を実行するためにネットワーク内のプログラマブルプロキシデバイスを活用することが好ましく、このケースでは、これは有益ではあるが、端末が多少なりともマルチモード可能、構成可能、あるいはプログラム可能であることを命令することは必要とされない。
【００７０】
したがって、これらの実施形態は、異なるトラフィックコンテンツタイプの要件及び優先順位、及び（無線）接続８又は８’のコンテキスト及び性能を動的に変更するクライアント（エンド）デバイス１３を考慮に入れ、結合された方法で圧縮（又はトランスコーディング）プロキシ１４が伝送の予定を立て（つまり、記憶し、転送し）、データを圧縮又はトランスコーディングすることができるプロトコル柔軟性の使用に関する。このようにして、性能と品質の均衡をユーザの優先順位及び端末のコンテキストに合わせて保たせる最適化された解決策を達成することができる。
【００７１】
好ましくは、構成可能なプロキシデバイス１４は、（メモリの中に）前記（又はそれぞれの）端末１３に宛てられたパケットをバッファに格納し、（好ましくは端末に常駐する実行論理に基づいて）スケジューリングコードを使用していつ前記結合されたパケット（複数の場合がある）を圧縮（又はトランスコーディング）し、端末に送信するのかを決定する。また、圧縮アルゴリズムは、好ましくは、プロキシデバイス１４上でパケットの共同の圧縮及びスケジューリングを実行するために、端末１３によって提供される（又は示される）コードで実現される。加えて、解凍は、プロキシがパケットをネットワーク１（例えばインターネット）に転送する前に、端末からプロキシへ逆の方向で実行できる。
【００７２】
随意的に、スケジューリング、圧縮及び解凍を実行するためのコードは、Ｊａｖａ（登録商標）バイトコード、つまり共通言語ランタイム（ＣＬＲ）コードでプロキシデバイス１４に供給される。随意的に、プロキシデバイスはアクセスポイント又は基地局２に配置できるが、好ましくは法人のイントラネット又はネットワーク事業者の敷地内に配置できる。
【００７３】
別の実施形態では、プロキシデバイスは主要な意思決定インテリジェンスの機能を果たし、端末にダウンロードされるコードを指定することによって端末圧縮及びスケジューリング機能性を制御できる。このケースでは、プロキシデバイスは、最も適切なスケジューリング、及び一連のプログラムライブラリ（つまりＵＲＬにより識別されるウェブベースのリソース）から圧縮インプリメンテーション機能性に関して決定するために、一般的な優先順位及びコンテキスト情報を端末から収集しなければならない。これが図８に描かれている。
【００７４】
図９に描かれている別の実施形態では、第２のプロキシデバイス（Ｙ）１４’は端末コンテキストを認識し、最も適切な共同圧縮及びスケジューリング方針を決定するために必要とされるインテリジェンスを含んでいる。次に、それは端末タイプ及び圧縮／解凍を実行するプロキシデバイスによってサポートされる、考えられるインプリメンテーションのライブラリ１７から選択する。次に、適切な端末及び／プロキシソフトウェアモジュールは、これらのそれぞれのプラットホーム（端末１３及び／又は第１のプロキシデバイス（Ｘ）１４）に転送される。このケースでは、端末のコンテキスト及びプロキシの機能に関する情報が収集される必要がある。
【００７５】
この実施形態は、伝送の点で現在バッファに入れられているデータに作用するコード（ネイティブオブジェクトコード又はＪａｖａ（登録商標）バイトコード）で実現できる、（トランスコーディングを含む）一般的な意味でデータ圧縮アルゴリズムの使用をサポートする。加えて（及び随意的に）、バッファは、端末とプロキシの両方におけるさらに長期のキャッシュ（例えば、非常に大きな入力バッファ２１）機能性で拡張できる。このケースでは、端末（及びプロキシ）にダウンロードされる圧縮コードは、（メモリ又は二次記憶装置のサイズによって制限される）はるかに長い期間に渡って受信されたデータを記憶する圧縮アルゴリズムを含むことができ、データの圧縮を実行するときにはこのデータのプールを使用できる。例えば、同じデータ又は類似するデータが後の時点で転送される場合、バッファ内に保持される過去のコピーに対する参照が行われる。
【００７６】
好ましくは、実施形態は、圧縮フォーマット検出及び圧縮コード内の変化するアルゴリズムもサポートできる。例えば、ＪＰＥＧフォーマットで過去に符号化されたグラフィックオブジェクトをＰＮＧフォーマットに解凍するためである。
【００７７】
随意的に、プロキシは最小の追加オーバヘッドで強化されたセキュリティのために、結合された圧縮及び暗号化をサポートできる。
【００７８】
プロキシデバイスは信頼されなければならず、安全なセッションが使用される場合、法人のイントラネットに常駐できる。これは、暗号化により暗号化層の下にある層で圧縮を実行する能力が削減されるためである。追加のプロキシデバイスは、ネットワーク事業者又は彼らと関連するサービスプロバイダにより提供されるサービスのために、ネットワーク事業者の敷地に常駐できる。プロキシデバイス及び端末の相互認証は、例えばＰＫＩ証明書又は他の手段を使用して必要である。その結果、端末は（起源及び確実性の妥当性検査も必要とする）指定されたコードを使用して、適切にプロキシをプログラミングできる。それから、端末１３は（例えばウェブブラウザ及び他のインターネットアプリケーションの通常のプロキシ設定値を使用することによって）最も適切な圧縮機構を使用する適切なプロキシエンティティ１４を介する、ある特定のサービス（又はアプリケーション）のための全てのトラフィックの経路を定めることができる。また、前記機構は、（例えばＷＬＡＮホットスポットからセルラーネットワーク等に移動するなど）デバイスコンテキストの変更を考慮するために動的に再構成できる。
【００７９】
動的に構成可能なトランスコーディング及びスケジューリングを提供することに加えて、仮にもトランスコーディングする／圧縮するかどうかを決定するためには既知の機構を利用できる。例えば、適切な機構は、Ｈａｎら、ＩＢＭトーマス・Ｊ・ワトソン研究所（IBM Thomas J. Watson Research Center）、「モバイルウェブブラウジングのための画像トランスコーディングプロキシ内での動的適応（Dynamic adaptation in an image transcoding proxy for mobile web browsing）」、ＩＥＥＥパーソナル・コミュニケーション・マガジン（IEEE Personal Communications magazine）、１９９８年１２月号に記載されている。トランスコーディングのための意思決定プロセスは、予測されるリンク速度とともに（低応答時間が必要とされると仮定する）応答時間の予測される改善に基づくことができる。本参考文献の図４を参照すること。なんらかのリンク速度では、トランスコーディングする、又は圧縮することはもはや魅力的ではない。代わりに、以下に示すように、決定はエンドデバイスに対し（ストリーミング運転モードを仮定して）データ単位の一様な送達を提供することに基づくことができる。Ｈａｎの図１０を参照すること。
【００８０】
単純な端末は、端末パラメータを提供するにすぎないいくつかの実施形態で使用することができるが、さらに精密な端末はシステム柔軟性を高めるために使用できる。図１０は、完全にプログラマブルな端末１３の端末動作フローチャートを示す。端末１３は、例えば、ボイスオーバＩＰセッションを作成し、ウェブページをブラウジングする、あるいはビデオストリームを受信することを希望する端末ユーザから、セッション要求を受信する。前記要求は、例えば入信ビデオセッションを示す無線サービスプロバイダのアクセスポイント２からである場合もあるであろう。
【００８１】
端末１３は、次に、他のエンティティと関連付けられた特定のセッションパラメータを決定するために、発呼者エンティティ又は被呼者エンティティ（例えばコンテンツプロバイダ１５）とのハンドシェーキングプロトコルを実行する。特定のセッションパラメータは例えば、インターネット全体での（プロキシに対する）パケット伝送のその速度、転送されるデータの量、その使用可能な圧縮フォーマット、及び端末の無線帯域幅、処理、メモリ及び電池リソースに影響を及ぼす暗号化方式などの他のパラメータである。
【００８２】
端末１３は、次に、使用可能な帯域幅、処理、メモリ及び電池リソースを含む独自の端末パラメータを決定する。情報の両方のこれらの集合から、端末１３は、その内部使用のための適切なスケジューリング及びトランスコーディング方式を決定する。例えば特定の圧縮設定値を用いて、ビデオの毎秒１２フレームを受信する。端末１３は、次に適切な解凍及びスケジューリングソフトウェアモジュールをダウンロードする。端末１３は、次に、プロキシが正しいトランスコーディング／圧縮及び伝送スケジューリングを実現するために、適切な構成コマンド１６をプロキシ１４に転送する。プロキシデバイス１４は、これを達成するために、適切な圧縮及びスケジューリングソフトウェアモジュールをダウンロードしてもよい。
【００８３】
最終的には、端末１３は、例えばセッション開始プロトコル（ＳＩＰ）を使用して全て実行できるセッションを開始するためにプロキシ１４と通信する。端末はその端末パラメータを監視し続け、必要な場合、これらが変更する場合に、新しいスケジューリング及びトランスコーディングの要件を決定する。これは追加のスケジューリング及び／又はトランスコーディングソフトウェアモジュールのダウンロードを必要とする可能性は低いが、既存のものを再構成することを必要とする可能性はある。それは、また、セッション又は伝送パラメータを修正するために、追加の構成コマンドをプロキシ１４に転送することも必要とする可能性がある。
【００８４】
当業者は、前述された装置及び方法が、例えばディスク、ＣＤ−ＲＯＭ又はＤＶＤ−ＲＯＭなどのキャリヤ媒体、読取専用メモリ（ファームウェア）などのプログラミングされたメモリ上で、あるいは光信号キャリヤ又は電気信号キャリヤなどのデータキャリヤ上で、プロセッサ制御コードとして具現化されてよいことを認識する。多くの用途のために、本発明の実施形態は、ＤＳＰ（デジタル信号プロセッサ）、ＡＳＩＣ（特定用途向け集積回路）又はＦＰＧＡ（フィールドプログラマブルゲートアレイ）で実現されるであろう。このようにして、コードは従来のプログラムコード又はマイクロコード、あるいは例えばＡＳＩＣ又はＦＰＧＡをセットアップする、又は制御するためのコードを備えてよい。コードは、再プログラマブルロジックゲートアレイなどの再構成可能な装置を動的に構成するためのコードも備えてよい。同様に、コードはＶｅｒｉｌｏｇ（商標）又はＶＨＤＬ（超高速集積回路ハードウェア記述言語）などのハードウェア記述言語用のコードも備えてよい。当業者が認識するように、コードは、互いと通信する複数の結合された構成要素の間で分散されてよい。適切な場合、実施形態は、アナログハードウェアを構成するために、フィールド（再）プログラマブルアナログアレイ又は類似したデバイス上で実行するコードを使用して実現されてもよい。
【００８５】
当業者は、それらに関して説明される多様な実施形態及び特殊な機能が、前記教示に従って、他の実施形態又は概してそれらの明確に説明される機能と自由に結合できるであろうことも認識する。当業者は、また、添付請求項の範囲から逸脱することなく、多様な改変及び変型も説明された特定の例に対して加えることができることも認識するであろう。
【図面の簡単な説明】
【００８６】
【図１】携帯電話のためのＷＡＰトランスコーダプロキシ構成を示す図である。
【図２】一実施形態に従った無線端末用の動的トランスコーダプロキシ構成を示す図である。
【図３】特定の端末のために図２の動的プロキシのための適切な設定値を求める方法を示す図である。
【図４】一実施形態に従った動的プロキシの概略図を示す図である。
【図５】図４のプロキシのスケジューラ機能の動作の方法を示す図である。
【図６】図４のプロキシのプロキシコントローラ機能の操作の方法を示す図である。
【図７】一実施形態に従って、端末とプロキシの間で接続セッションをセットアップするためのプロセスを示す図である。
【図８】別の実施形態に従った無線端末用の動的トランスコーディングプロキシ構成を示す図である。
【図９】一実施形態に従った端末の操作を示すフローチャートである。
【図１０】完全にプログラマブルな端末のための端末動作フローチャートを示す図である。
【技術分野】
【０００１】
本発明は、リソースが制限された携帯端末のためのデータコンテンツのスケジューリング、圧縮及びトランスコーディングに関する。
【背景技術】
【０００２】
ウェブページ及び他のマルチメディアサービスは、ＧＩＦ画像又はＦＬＡＳＨ動画などの大型グラフィックファイル、及びＪａｖａ（登録商標）アプレットなどの自動化されたプロシージャだけではなく、例えばリアルプレーヤビデオクリップなども使用するなど、コンテンツがますます精密化し、豊富になってきている。その結果、生じるウェブページがウェブページサーバから要求側クライアントマシンに転送されなければならない大型のオブジェクトとなることがある。ブロードバンドインターネット接続の使用が増加するにつれて、このような豊富なメディアコンテンツをサポートできるが、多くの他のクライアントは、例えば狭帯域無線接続上であるかもしれないインターネットへのその接続だけではなく、内蔵処理能力と電池寿命の両方の点で限られたリソースを有するマシンをベースにしている。
【０００３】
限られたリソース端末の例は、インターネットに対する相対的に狭帯域な接続（例えばＧＳＭ）だけではなく、限られた電池寿命、限られた処理能力、及びメモリサイズを有する携帯電話である。これらの限られた資源により、端末が前述された豊富なメディアコンテンツを十分にサポートすることは困難になる。例えば、前述されたグラフィックファイルの多くはそのサイズを縮小するために圧縮されるが、これは端末による解凍処理を必要とする。豊富なメディアＨＴＭＬページは１から２ＭＩＰＳ（毎秒１００万の命令）の処理を必要とする可能性がある。明らかにこれは、これを十分にサポートするための処理能力及びメモリの最小閾値を必要とする。加えて、現代の（ｍｏｄｅｒｎ）電池重量の１００ｇが約５×１０８の命令を与え、その結果このような電池はウェブブラウジングを提供する８分間の使用後に放電すると推定されている。
【０００４】
この問題は、ある表現又はフォーマットのオブジェクトを別の表現又はフォーマットに変換する、つまりトランスコードする、トランスコーディングプロキシサーバ又はゲートウェイを使用して対処されてきた。ＷＡＰがイネーブルされたこのような携帯電話機のシステムの概略は、図１に図示されている。トランスコーディングされたオブジェクトは、通常はより小さくなり、携帯端末による処理及び表示により適している。例えば、意味情報を保持する一方で、ビデオクリップなどのコンテンツのいくらかは削除されてよい。言い換えると、オリジナルの豊富なメディアページの簡略なテキスト専用表現だけが、モバイルデバイスで表示されてよい。これにより、処理能力が限られた端末は、依然としてウェブページ上で与えられる基本的な情報にアクセスできる。例えば解凍処理の欠如などの削減された処理負荷は、電池に対するドレインも削減する。追加の利点は、情報が消費するネットワークリソースが少なくなり、オリジナルのフルコンテンツオブジェクトよりも迅速に、狭帯域リンク上のデバイスに転送できるという点である。
【０００５】
トランスコーダプロキシは、米国特許第６５３５９２２号、及びＨａｎら、ＩＢＭトーマス・Ｊ・ワトソン研究所（IBM Thomas J. Watson Research Center）、「モバイルウェブブラウジングのための画像トランスコーディングプロキシ内での動的適応（Dynamic adaptation in an image transcoding proxy for mobile web browsing）」、ＩＥＥＥパーソナル・コミュニケーション・マガジン（IEEE Personal Communications magazine）、１９９８年１２月号にさらに詳細に記載されている。これは、それが性能を改善しないいくつかの状況があるため、仮にもトランスコーディングする、及び／又は圧縮するかどうか、などの考慮すべき事柄を含む。これは、トランスコーディングされたファイルのサイズを予測するトランスコーディングするために要する時間、及びトランスコーディングされたファイル及びオリジナルファイルをダウンロードするために要する時間の推定を必要とする。
【０００６】
Ｈａｎらに説明されるように、トランスコーディングする／圧縮するか否かの決定は多くの異なる基準に基づく場合がある。例えば、これは、推定されるリンク速度での応答時間の予測される改善に基づくことがある―Ｈａｎの図４を参照すること。代わりに、前記決定はストリーミングアプリケーションにおけるデータ単位の一様な送達を実現することに基づく場合がある―Ｈａｎの図１０を参照する。追加の代替策では、圧縮するという決定はデータブロックサイズ及び推定される圧縮待ち時間又は発生する遅延に基づいて圧縮決定ができる。
【０００７】
ＵＭＴＳとして知られている第３世代のセルラーエアインタフェース規格は、トラフィックペイロードに応じて使用されるパケットヘッダ圧縮の種類を変えるための機構（ロバストヘッダ圧縮、つまりＲＯＣＨ）を含む。ヘッダ圧縮は、主にＩＰベース及びビデオベースのアプリケーションのためのパケットヘッダ構造の知識に基づいて作用する。
【０００８】
「ロバストヘッダ圧縮による無線伝送のためのビデオ品質評価（Video quality evaluation for wireless transmission with robust header compression）」Ｆ．Ｆｉｔｚｅｋ、Ｓ．Ｈｅｎｄｒａｔａ、Ｐ．Ｓｅｅｌｉｎｇ、Ｍ．Ｒｅｉｓｓｌｅｉｎ Ａｃｔｉｃｏｍ−０３−００３技術報告書は、ヘッダ圧縮に特有であり、圧縮機とデコンプレッサの両方がパケットヘッダについての状態情報を保持する手法を開示する。これは、特定の「繰り返される」情報を送信し続けなければならないことを回避する。例えば、圧縮器と解凍器の両方がシーケンス番号が連続パケットで特定の方法で（例えば順次に）増加することを知っているために、シーケンス番号は送信されない。これは高い圧縮率を達成するが、エラーを受けやすい。例えば、パケットが失われる場合には、シーケンス番号についての仮定は無効となり、再構築されるパケットは、オリジナルとは異なる。したがって、正しい仮定を確立し直すためにはフォールバック状態が必要とされるが、これを達成するにはいくつかの再送、したがって圧縮率の損失が必要となる。圧縮のレベルは、接続のロバストネス（エラー特性）に合わせられる必要があり、これは動的に変化する。これは、ベースフレームが失われると、全ての予測フレームが無意味になり、エラーの波及が生じ、次のベースフレームが無事に受信されるまで多くの連続するエラーを起こしやすいフレームが生じる、ＭＰＥＧ２圧縮アルゴリズムに似ている。通常、ベースフレームあたりの予測フレーム数はデコンプレッサによって静的に固定されるが、これはエラーに対して多かれ少なかれ免疫性を与えるために動的に変化するであろう。
【０００９】
よく知られているポイントツーポイントプロトコル（ＰＰＰ）などの従来のパケット圧縮方式は、ヘッダ圧縮に加えてペイロードをベースにした圧縮を使用している。パケットペイロード圧縮アルゴリズムは接続確立時に取り決められ、通常、送信前にはパケットのハフマン符号化に基づいており、逆プロセスは受信端で実行される。各パケットペイロードはパケット単位で圧縮されるため、さらに短いパケット又は（グラフィックデータなどの）すでに圧縮されたデータを含むパケットは、より長いパケット又はより高い層で過去に圧縮されていないパケットより低い圧縮率を有することが一般的に知られている。（ＬＺＷ７７又はＬＺＷ７８などの）異なるアルゴリズムを使用するＩＰベースの圧縮は、ＩＥＴＦ ＲＦＣ ２３９３に記載されている―ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／のインターネットエンジニアリングタスクフォースウェブサイト（Internet Engineering Task Force Web Site）を参照する。この種のペイロード圧縮は（例えばＶａｎ Ｊａｃｏｂｓｏｎなどの特殊ヘッダ圧縮アルゴリズムを使用して圧縮できる）パケットヘッダ情報を圧縮しないが、代わりにパケットペイロードに作用するため、小さなパケットは（それ以外の場合、それらはオリジナルパケットより大きくなる可能性があるため）通常まったく圧縮されない場合がある。ＩＰ圧縮制御プロトコル（ＣＣＰ）は、ＩＥＴＦ ＲＦＣ １９６２に記載され、リンク層フレーム内でパケットを結合することに対処できるが、これはさらに高い圧縮率を達成するためにパケットスケジューリングと圧縮を組み合わせる方法を含んでいない。
【００１０】
圧縮方式は、コンテンツについて掘り下げた知識が入手できるプレゼンテーション層及びアプリケーション層でも使用できる。これは、必ずしもサポートされていない、あるいはクライアントデバイスにとって最適でない可能性があるため、トランスコーディングプロキシが導入されるアプリケーションに特有の（つまりトラフィックタイプに特有の）解決策につながる。例えば、標準ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ＨＴＭＬページの圧縮を動的に実行しないが、グラフィック画像又はページに埋め込まれたビデオ／音声データは、様々なアルゴリズム（ｊｐｅｇ、ｐｎｇ、ｇｉｆ、ｍｐｅｇ、ｍｐ３等）を使用して推測的に圧縮される。未処理のＨＴＭＬよりむしろＧＺＩＰ圧縮済みＨＴＭＬページをサポートする圧縮されたＨＴＭＬ又はＣＨＴＭＬは、最新のサーバ及びブラウザソフトウェアに符号化されるが、解凍はブラウザソフトウェア内で行われるので、これはある特定のターゲットプラットフォームに対して最適に行われない可能性がある。したがって、これらの異なる圧縮方式は、解凍が行われるため、及び検索データのために、クライアントブラウザ（又はブラウザプラグイン）によりサポートされなければならない。また、コンテンツの視点から、圧縮フォーマットは、最もよく知られている一般的なブラウザ、及び最も一般的なアクセス方法（例えば、ダイヤルアップ接続又はブロードバンドインターネットアクセス）のために品質と圧縮済みサイズの最善の組み合わせを提供するために、ウェブサイト作成中に選択される。ページあたり２５ｋｂｙｔｅｓ未満の画像を有するなどの特定の経験則が存在するが、これらは様々なネットワーク上でコンテンツにアクセスする全てのデバイスタイプに必ずしも適用できない。
【００１１】
無線アプリケーションプロトコル（ＷＡＰ）は、ＷＡＰコンテンツのＷＡＰに特殊な圧縮済みバイトフォーマットへの圧縮を実行するためにゲートウェイデバイスを使用するが、圧縮済みフォーマットの特定のセットだけがサポートされ、コンテンツは特定のＷＭＬフォーマットで提供しなければならない。
【００１２】
セッション開始プロトコル（ＳＩＰ）内では、指定された解凍アルゴリズムの特定のセットを有さなくても信号パケット上で適切な解凍を実行できるようにする、（バイトコードを用いて）適切に構成できる、汎用解凍仮想マシン（ＵＤＶＭ）を活用する信号圧縮方式が定義される。しかしながら、この概念は、圧縮が一般的にはより計算機的に集約的であり複雑なプロセスであるために、汎用圧縮仮想マシン（ＵＣＶＭ）の指定は含まない。これにより、デコーダはデコーダインプリメンテーションで事前にプログラミングされたアルゴリズムの共通した合意セットを有さなくてもセッションの始まりで（ＵＤＶＭを用いて）プログラミングできるため、解凍アルゴリズムが使用される内容にある程度の柔軟性が許される。
【発明の開示】
【課題を解決するための手段】
【００１３】
大まかに言えば、本発明は情報又はコンテンツを、そのコンテンツのフォーマットを、端末及び／又はそのサービスプロバイダと関連付けられる性能パラメータの数に応じて、端末に又は端末から、あるいはさらに一般的には、インターネットに結合される、例えば無線基地局を含むネットワークに転送するときに変更することによって、転送する方法を提供する。このような性能パラメータは、待ち時間及びスループットなどのネットワーク性能パラメータだけではなく、端末の電池レベル、処理リソース及びメモリリソースなどの端末性能パラメータを含む可能性がある。したがって、例えば、低プロセッサリソースを有する携帯電話は、これがオリジナルコンテンツの低レベル（例えばテキスト専用）のレンダリングを意味するとしても、限られた解凍処理で動作することによりさらに優れたウェブコンテンツレンダリングサービスを提供できる可能性がある。他方、多くのプロセッサリソースを備えるが、狭帯域無線リンクの端末は、これが高解凍処理オーバヘッドを必要としようとも、端末へのファイル転送時間を改善するためにさらに高い圧縮率でさらによい状態になる可能性がある。
【００１４】
コンテンツフォーマット変換は、例えば端末の電池が乏しくなり、処理の削減を必要とする場合、あるいは待ち時間及びスループットなどのネットワークリソースが削減し、補償するための圧縮処理の増加を必要とする場合に、接続セッション中に変更されてよい。これは、既存の手法におけるような特殊規格コーデックの動作パラメータを変更することに限定されないが、ある圧縮及びスケジューリング方式から別の圧縮及びスケジューリング方式への完全な切り替えを可能にする。それは、また、プロキシデバイスで実現されるフレームの圧縮及び伝送のスケジューリングを実行するインテリジェンスも可能にし、したがって端末が、どの記述をいつ要求するのかに関する決定を下さなくてもよいようにする。これにより、次のフレームに対する要求が、過去のフレームが受信された後に行われるため、要求をサーバに戻し、それから次のフレームを端末に送信するための待ち時間は必要とされる期限より長くなる可能性があるという、既存の手法で発生する可能性がある問題が排除される。これは、ネットワーク性能及び端末リソースの可用性を考慮に入れるスケジューリング機能性を組み込んだネットワーク常駐プログラマブルプロキシを有することにより、本構成において回避される。
【００１５】
転送方法は、複数の使用可能なモードの１つから選択されてよい、あるいはそれは条件が変化するにつれて動的に適応されてよい。転送方法は、異なるトランスコーディング及び／又は圧縮アルゴリズム並びにスケジューリング方式を含む多くの伝送パラメータ又は変数で成り立っており、これらは標準化セットの合意アルゴリズムが有っても無くても使用できる。さらに、リンクパラメータは変更されてもよい。これは、他の伝送パラメータの変更と組み合されるとコンテンツフォーマットの変更を増長する。例えば、リンクレートは、エラーの増加を犠牲にして高次変調を使用して増加してよい、あるいはリンクは、例えばＧＳＭからＩＥＥＥ８０２．１１ ＷＬＡＮに切り替えられてよい。
【００１６】
好ましい実施形態では、このコンテンツを転送する方法は、プログラマブル、又は動的に適応可能なネットワーク常駐プロキシデバイス、及び／又は携帯端末を使用して実現される。プロキシデバイス、及び／又は携帯端末は、トランスコーディング済み／圧縮済みの情報を端末及び／又はプロキシデバイスへの転送するスケジューリング又は速度及びタイミングだけではなく、そのトランスコーディング及び／又は圧縮も調整する。プロキシデバイスは、一実施形態ではエンドシステム（コンテンツプロバイダ）に常駐してよいが、モバイル装置までの経路に沿った他の点にも常駐してもよい。
【００１７】
変化する条件、例えば電池の不足又はネットワーク待ち時間の増加に従って伝送方法変数又は伝送パラメータを適用することによって、オリジナルコンテンツをレンダリングする際の端末の性能が最適化される。性能が最適化される方法は、転送されるデータのタイプ（例えば、再生用のテレビ会議、又はビデオファイル）及び／又はユーザの選択（例えば、電池充電間での長い旅行による電池寿命を最大化すること）に依存することもある。
【００１８】
特に、ある態様では、請求項１に記載のプロキシ装置が提供される。
【００１９】
また、請求項３２に従ったプロキシ装置を操作する方法も提供される。
【００２０】
特に、別の態様では、請求項１６に記載の端末装置が提供される。
【００２１】
請求項４３に従って端末装置を動作する方法も提供される。コンテンツフォーマットを修正するという表現は、コンテンツ（情報）の表現を、それを伝達するために使用されるデータ通信プロトコルとは無関係に修正することを指す。このようなフォーマット変更の例は、なんらかのコンテンツの圧縮、解凍、トランスコーディング、及び／又は削除を含む。
【００２２】
トランスコーディング及び圧縮という用語は、明細書を通して同義的に使用され、概して、例えばウェブページからグラフィックを削除し、次にこのデータを、それが例えば携帯電話などの限られたリソースの端末に適するように圧縮することなどのあるフォーマットから、別のフォーマットに情報を変更することを指す。さらに一般的には、符号化は、トランスコーディング及び圧縮を指すためにも使用される。
【００２３】
圧縮方式を適応させるために使用される性能パラメータは、端末の動作環境に関係し、コンテンツの転送を達成する。このようなパラメータは、ネットワーク待ち時間及びスループットなどのネットワークベースのパラメータだけではなく、電池レベル、処理リソースレベル及びメモリリソースレベルなどの端末に特有のパラメータも含む。
【００２４】
伝送パラメータは、圧縮率及び／又はトランスコーディングアルゴリズム、及び符号化されたパケットのネットワーク上への伝送速度などのスケジューリング情報（イベントの予定を立てる周期性及び最大待ち時間ターゲットに関するパラメータ）などの、コンテンツを転送する方法に関係する。
【００２５】
これらの構成は、現在のシステムがその圧縮及び／又はトランスコーディングを（及びスケジューリングも）設計時又はインストール時に設定させる、発明者により特定される問題を克服し、例えば、特定のエアインタフェース規格を使用する使用可能な処理能力が最低の端末などの特定のネットワークアクセスモードに対する最悪のシナリオを対象としている。上記のように特徴付けられた構成は、その現在の動作環境に依存する特定の端末に対して伝送パラメータを最適化することを可能にする柔軟性を提供する。
【００２６】
さらに、圧縮方式の変動は単に誤り率などの無線リンクパラメータの変化に関係しないと言うだけでなく、むしろ、電池レベル及び／又は待ち時間及びパケット損失確率などのネットワークに特有の条件などの端末に特有の条件に関係する。それは、また推定帯域幅、待ち時間、待ち時間変動、無線リンク伝送スケジュールなどの、他のリンクパラメータにも関係してよい。それは、複数のアクティブな無線技術が同時に活用されるマルチモード端末の動作もサポートする。
【００２７】
さらに、端末が（プロキシスケジューリング及び圧縮機能性をプログラミングすることによって）伝送パラメータを制御する実施形態では、それは、基地局又は端末によって直接的に又は間接的に制御されていないプロキシデバイスなどのサードパーティに依存するよりむしろ、独自の現在の動作条件のためにプロキシにより実行されるコンテンツフォーマット変換を最適化できる。
【００２８】
大まかに言えば、別の態様では、ユーザデバイスによる消費のためにコンテンツを変換するプロキシ装置を介して、コンテンツプロバイダからユーザデバイスにコンテンツを転送するシステムが提供される。この変換は、例えば、これらをユーザデバイスに転送する前にトランスコーディングする、及び／又は圧縮することによる、プロバイダから受信されるコンテンツパケットの符号化を含んでよい。ユーザデバイスは、プロキシに、変換の変更を信号で知らせるためにプロキシ装置にフィードバックリンクを提供するように構成される。これにより、ユーザデバイスは、専用のリソースの使用、ユーザデバイスでのコンテンツの表示又はレンダリング、及び／又はコンテンツプロバイダとユーザデバイス間の通信リンクの使用などの多様な要因を最適化するために、受信された（変換された）コンテンツを適応できる。
【００２９】
通信リンクは、通常、ユーザデバイスと無線サービスプロバイダの間の無線リンクを含む。フィードバック誘導コンテンツ変換変更に加えて、無線サービスプロバイダは、リンクの帯域幅を改善するために、さらに、変調速度などの特定の無線リンク伝送パラメータを調整してよい。ユーザデバイスは、この余分な帯域幅をうまく利用するためにコンテンツ変換を調整することによりこれに応えることができる。
【００３０】
大まかに言えば、別の態様では、ユーザデバイスによる消費のためにコンテンツを変換するプロキシ装置を介して、コンテンツプロバイダからユーザデバイスにコンテンツを転送するためのシステムが提供される。この変換は、例えばユーザデバイスへの転送の前にこれらをトランスコーディングする、及び／又は圧縮することによって、プロバイダから受信されるコンテンツパケットの符号化を含んでよい。ソフトウェアコントローラは、様々な変換を実現するためのソフトウェアモジュールをダウンロードするために、ユーザデバイス及び／又はプロキシ装置で利用される。コントローラは、例えば、プロキシ装置により活用される圧縮機モジュールに対応する適切な解凍モジュールを転送するために、局所的に記憶されるモジュールもアップロードしてよい。使用される変換は、好ましくは、コンテンツプロバイダとユーザデバイス間のリンク上の条件が変化するにつれて動的に更新される。変換要件が変化するに従い、ソフトウェアコントローラは適切なソフトウェアモジュールを実現する。
【００３１】
実施形態はほんの一例として、及び制限することを目的とせずに、図面を参照して説明される。
【発明を実施するための最良の形態】
【００３２】
図１は、インターネットなどのネットワーク１、ネットワーク１に接続される無線サービスプロバイダ２、及び無線サービスプロバイダ２に無線で結合される携帯端末３を有する、既知の種類の通信システムを示す。携帯端末３は、通常、インターネット１からのウェブページ情報の限られた検索を可能にするＷＡＰ（無線アプリケーションプロトコル）機能付きの携帯電話である。携帯端末３は、無線サービスプロバイダ２及びインターネット１を通してウェブページ５にアクセスするが、ウェブページコンテンツは、制限された無線帯域幅及び表示機能を有する携帯端末３によって受信及び表示できるように、ＷＡＰゲートウェイデバイス４によって圧縮フォーマットにトランスコーディングされる。
【００３３】
しかしながら、より強力な携帯端末は依然として基本的なＷＡＰサービスに制限され、例えば異なるコンテンツフォーマットを使用して異なる画質を表示するために、そのさらに大きな処理能力を利用することができないため、このようなシステムは制限され、柔軟性がない。他方、例えば追加の圧縮を提供するより精密なシステムを構想できる場合、これは、端末の電池残量が乏しくなり、これに対処するための性能のレベルの低下が望ましいケースでは適切ではない可能性がある。
【００３４】
図２を参照すると、第１の実施形態に従った通信システムが図示されている。システムは、インターネットなどのネットワーク１、無線サービスプロバイダ２、及び改良された携帯端末１３のユーザが所望するコンテンツ（例えばウェブページ又はビデオストリーム）を含むコンテンツプロバイダ１５をさらに備える。システムはネットワーク１に接続される動的トランスコーディングプロキシデバイス１４をさらに備える。
【００３５】
図１のシステムと同様に、ウェブページ、ｅメールサーバ、ビデオサーバ又は他のコンテンツプロバイダ１５のコンテンツは最初に、無線サービスプロバイダ２、及び最終的には携帯端末１３への転送の前にこれを処理する、トランスコーディングプロキシ１４に転送される。トランスコーディングプロキシ１４は、図１のＷＡＰシステムの場合のようにセットトランスコーディングアルゴリズムに制限されないが、代わりに、端末１３の機能に応じて動的にプログラミングされてよい多くのアルゴリズムを有する。端末１３は、プロキシ１４に、多くの所定のアルゴリズムの１つ、又は電池レベル、無線接続（８）容量、処理容量及びメモリ容量などの端末性能パラメータに基づいた（例えば、ＵＲＬにより特定され、例えばＪａｖａ（登録商標）バイトコードで実現される）指定されたアルゴリズムコードインプリメンテーションを使用するように命令する。このようにして、構成コマンド１６が、例えば無線リンク８及びインターネット１上で、端末１３からプロキシ１４に送信される。
【００３６】
プロキシデバイス１４は、多くの伝送パラメータと関連付けられた多くのアルゴリズムを有し、したがって例えば１つのアルゴリズムは、端末１３が高レベルの処理及び電池残量を有するが、狭帯域無線チャネルを有するときに適切となる可能性のある、高度の圧縮を提供してよい。このケースでは、大きなファイルは圧縮し、無線チャネル上で相対的に迅速に端末１３に送信できる。他方、端末１３が、ＩＥＥＥ８０２．１１ｇ ＷＬＡＮなどの大きな帯域幅の無線リンク８であるが、低い処理及び／又は電池のレベルを有する状況が発生する場合、ＸＸは別のアルゴリズムによって得をするであろう。例えば、大きなファイルは高容量チャネル８上で、これらをユーザに提供するために限られた処理で管理できる端末１３に、圧縮を使用せずにあるいは低圧縮で送信することができる。
【００３７】
未圧縮ファイルの伝送／受信から生じる電力消費は、それが圧縮された場合の節電と解凍に必要とされる電力消費の差異に対して釣り合わなければならない。例えば、８０２．１１ａでは、３０ｍ未満の分離で、伝送のための電力消費はデータ（ペイロード）ビットあたり５０ｎＪ未満である。したがって、選択されたアルゴリズムのための圧縮率がｒである場合、解凍処理電力消費はこの圧縮方式を選択するためにビットあたり５０＊（１−ｒ）ｎＪ未満でなければならない。これがどのアルゴリズムが使用されるのかを決定し、これは例えば汎用プロセッサ（ＧＰＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又はハードコードされたＡＳＩＣベースのインプリメンテーションにおいて、動的に構成できる。端末がファイルを（伝送しているのではなく）受信している場合には、電力消費はさらに少なくなり（例えばビットあたり２５ｎＪ）、このケースでは解凍処理電力消費は、前記方式を選択するためにビットあたり２５＊（１−ｒ）ｎＪ未満でなければならない。また、これは、ネットワーク転送待ち時間の削減に対して相殺されるときに圧縮及び解凍の待ち時間が許容されることを仮定している。例えば、ネットワーク待ち時間はビットあたりＮｎｓで推定され、その結果圧縮及び解凍待ち時間は圧縮使用時に待ち時間の利点を有するためにビットあたりＮ＊（１−ｒ）ｎｓ未満でなければならない。
【００３８】
構成コマンド１６は、接続又はセッションセットアップシーケンスの一部としてプロキシデバイス１４に転送でき、次に、プロキシによって使用されるアルゴリズムは接続セッションの持続期間の間固定される。さらに好ましくは、端末１３は、セッションの伝送パラメータ（例えば、圧縮レベル及びいつ圧縮が発生するのかのスケジューリングなど）を動的に変更することに対処するために、接続セッションの間に構成及びステータスコマンドをプロキシデバイス１４に転送するように構成される。これは、端末性能パラメータが無線サービスプロバイダ２との接続セッション中に変化する場合に有利である。例えば、電池レベルが減少するにつれて、あるいはリンク８上でのスループットが削減されるように、おそらくフェージング及び干渉のために無線接続性能が変化する場合である。したがって、プロキシデバイス１４の動作は、コンテンツプロバイダ１５のコンテンツの検索を最適化するために端末１３と関連付けられるリアルタイム状態に合わせることができる。また、これは代替圧縮フォーマットデータの過去の送信されたフレームを再送するためのフィードバックも含むであろう。
【００３９】
端末パラメータは、選択された無線サービスプロバイダ２又は２’に依存してもよい。例えば、図２に図示されるように、モバイルデバイス１３は第１の無線サービスプロバイダ（Ａ）２と第２の無線サービスプロバイダ（Ｂ）２’の間で選択してよい。これは、例えば、セルラーＧＳＭ接続及びＷＬＡＮ ８０２．１１ａ接続であってよい。このケースでは、無線接続容量端末パラメータは、選択されるサービスプロバイダ２又は２’に依存する。これは、代わりに伝送パラメータ又はトランスコーディングアルゴリズムに影響を及ぼす可能性がある。
【００４０】
図２の一般的な方法は、図３に描かれている。端末パラメータは最初に決定される。例えば、端末１３はその現在の電池レベル、処理能力及びメモリ能力、ならびに無線リンク容量を検出し、これらを使用可能にする。これらの端末パラメータに基づいて、例えば適切な伝送パラメータが選択され、圧縮方式が選択され、アルゴリズムがプロキシデバイス１４でプログラミングされる。対応する構成コマンドは、圧縮を行う時と方法の両方を含むこの圧縮機能性を設定するために、プロキシ１４に送信される。説明した機能ステップの種々の形態は、各種のハードウェアに配置できる。例えば、これらの全ては汎用プロセッサ上のソフトウェア又は端末１３で実行されるプログラマブルロジックで実現されてよく、その結果、単に適切な構成コマンド１６がプロキシ１４に送信されることになる。代わりに、端末機能及びリソースステータス収集機能性は端末１３に常駐する可能性があり、プロキシデバイス１４のアルゴリズム選択又は他のインテリジェンスはそれに結合される可能性がある。このケースでは、端末は次に必要な解凍アルゴリズム及びリソースをセットアップするための適切な構成コマンドを送信される。
【００４１】
コンテンツの変化するフォーマット（例えば圧縮タイプ）に加えて、変調又は他のリンクに特有のパラメータも、コンテンツ転送を最適化するために変更できる。
【００４２】
図４は、プロキシデバイス１４の例のアーキテクチャを示し、入力バッファ２１、トランスコーダ処理ブロック又はエンコーダ２２、出力バッファ２３、プロキシコントローラ２４及びスケジューラ２５を備える。プロキシ１４は、エンコーダ処理ブロック２２で使用するためのトランスコーディング及び／又は圧縮コードをダウンロードするために、ソフトウェアコントローラ２６をさらに備えてよい。さらに、プロキシデバイスは、プロキシ専用の圧縮及び／又はトランスコーディングを容易にするために、サービスプロバイダ１５からの圧縮済みパケットを「中立」フォーマットに解凍するための、デコンプレッサ２７を備えてよい。
【００４３】
プロキシは、ネットワーク１上でビデオストリームなどのコンテンツプロバイダ１５からの（例えばビデオフレームを搬送する）パケットを受信する。フレームはデコンプレッサ２７によって解凍され、周知のように受信された順序で入力バッファ２１に記憶される。バッファに格納されたフレームは、スケジューラ２５から受信される命令に従って制御された方法で、エンコーダ処理ブロック２２に渡される。入力バッファ２１は、循環形式で動作してよい。入力バッファ２１により受信されるフレームの率が、これらフレームが移動される率を超える場合には、バッファは他のフレームを上書きし、いくつかのフレームは失される（落とされる）。入力バッファ２１は、例えば１フレームおきに指定されたフレームを落とすようにスケジューラ２５により設定できる。これは、伝えられたフレーム数をなんらかの形式で削減することが必要とされるように、端末１３がフレームのさらに低い速度を単に受け入れることができることをスケジューラ２５が「知っている」ときに発生する可能性がある。スケジューラ２５は、所定数のフレームを、これらをエンコーダ２２に渡す前に最初に記憶するように入力バッファ２１を構成してもよい。これは、エンコーダ２２が、（ＭＰＥＧ２などの）フレーム単位よりむしろフレームのブロックを必要とする圧縮アルゴリズムを使用するために発生する可能性がある。また、入力バッファ２１に記憶されるフレームは、スケジューラ２５によって命令されるときに、同じフレームが別の圧縮フォーマットを使用して再びエンコーダ２２に渡すことを可能にするために、エンコーダ２２に渡された後にもバッファ内に保持されてよい。
【００４４】
エンコーダ処理ブロック２２は、コンテンツプロバイダ１５からの現在のパケット流入を端末１３に適した別のパケット流出に変換するために適した、圧縮及び／又はトランスコーダアルゴリズムを実行する。エンコーダブロック２２は、プロキシコントローラ２４により命令されるように多くの所定のアルゴリズムの内の１つを実行してよい。使用される前記特定のアルゴリズムは、例えば無線リンク帯域幅又は端末１３内の処理リソースのレベルなど端末パラメータが変化するにつれて、端末１３との接続の過程で変化する可能性がある。多岐に渡るアルゴリズムは、プロキシデバイス１４に記憶されてよいか、あるいはそれらは、例えばソフトウェアライブラリ１７から、ソフトウェアコントローラ２６によって必要に応じてダウンロードされてよい。アルゴリズムは、このオプションが使用できる場合オンザフライで構成されてもよい。
【００４５】
エンコーダ処理ブロック２２は、入力バッファ２１から受信したフレームを、伝送又は出力バッファ２３に渡される「新規」フレームに変換する。エンコーダ処理ブロック２２から受信したパケットは記憶され、又は出力バッファ２３によってバッファに入れられ、次にスケジューラ２５によって命令される速度で、及びスケジューラ２５によって命令される時間内のインスタンスで端末１３に転送される。
【００４６】
好ましくは、スケジューラ２５は、代わりに端末パラメータに依存する出力バッファ２３の処理速度によって必要とされるときにだけ、エンコーダ２２にパケットを転送するように入力バッファ２１に命令するように構成される。これにより、エンコーダブロック２２による、それ以外の場合省略されていた可能性があるフレームの不必要な符号化が回避される。また、必要な場合、スケジューラ２５は、（入力バッファ２１に保持される）同じフレームが（エンコーダ２５によって）符号化され、端末からのフィードバックに基づいて端末１３へ同じ又は別のネットワーク上で渡すために２つ以上の異なるコンテンツフォーマットで出力バッファ２３に記憶することを命令する機能を有する。
【００４７】
したがって、スケジューラ２５は、バッファにサービスを提供し、入力バッファ２１からエンコーダ２２に転送するだけではなく、入力バッファ２１内でのパケットの省略も制御する。それは、（適切なネットワーク接続を選択する）適切なネットワーク上での出力バッファ２３から端末１３へのパケットの伝送も制御できる。出力バッファ２３から端末１３への出力速度は、フレーム又はパケットが符号化のために入力バッファ２１からエンコーダ２２に転送される速度によって有効に設定される。スケジューラ２５は、端末１３への伝送スケジュールに関してコントローラ２４から命令を受信してから、入力バッファ及び出力バッファ２１と２３に相応してサービスを提供する。これを示すフローチャートは図５に示される。
【００４８】
スケジューラ２５は、端末における解凍の処理時間（端末における処理速度）及びエンコーダ処理ブロック２２における解凍の処理時間（プロキシにおける処理速度）、エンコーダ入力が動作ごとに必要とするデータ又はフレームの量、及び送達されるデータ又はパケットの量、使用可能なネットワーク接続ごとのネットワーク性能推定値（誤り率、待ち時間及びスループット）などの他の必要な情報だけではなく、コントローラ２４からの端末伝送スケジュールも受信する。それから、スケジューラ２５は、コンテンツプロバイダ１５からパケットを受信する近似（又は実際の）速度を含む、指定された入力バッファ２１からの情報を決定する。例えばＲＳＶＰプロトコルはスループット、バッファサイズ及び現在の占有率を取り決めるために使用できる。このことから、スケジューラ２５は出力バッファサイズを設定し、適切な場合、パケット削除又は省略設定だけではなく適切なネットワークへの伝送の予定をいつ立てるのか、（エンコーダ２２に対する）入力バッファサービス速度及びスケジュールも決定できる。これらの設定は、コントローラ２４によって受信される命令に従って、端末１３へのセッション内のトラフィックフローごとに動的に変更できる。したがって、スケジューラ２５は、いつアルゴリズムを使用する（つまり符号化を実行する）時、及び符号化されたパケットを端末装置に送信する時を指示する。
【００４９】
スケジューラが、ある特定の点がトラフィックストリーム内で（特定のサイズ及び圧縮型の）データの特定のブロックを復号するには、時間４０ｍｓを要すると知っている場合には、フィードバック信号は、端末リソースが変化するとき、あるいは（パケット破壊又は損失などの）予期せぬ出来事が発生するときにのみ必要となり、その時、スケジューラは例えば５０ｍｓを要することを伝える必要がある。同様に、ネットワーク待ち時間がフレーム当たり２０ｍｓである場合には、これは次のブロックを圧縮する時を決定するためにスケジューラ２５によって考慮でき、それにより最小記憶圧縮パケットが存在することになり、故に（目標性能要求に基づく）アプリケーションに解凍データを与える全待ち時間が受け入れできる。
【００５０】
プロキシコントローラ２４は、例えば、セッションがサポートするアプリケーションのタイプだけではなく、誤り率、待ち時間及びスループット、現在のリソースステータス（処理容量及びメモリ容量ならびに電池レベル）などの無線ネットワーク性能などの端末パラメータ又は設定値を含む、端末１３からの制御コマンド又は構成コマンドを受信する。アプリケーションのタイプは、コンテンツプロバイダ１５がある特定のトラフィックフローの中で供給しているコンテンツのタイプに関係し、単に一般的なウェブトラフィック又は画像トラフィック、ファイル転送、ビデオストリーミング、又はボイスオーバＩＰ呼に関する場合がある。この情報から、コントローラ２４は、プロキシ１４と端末１３の間の待ち時間及びスループット、及び必要とされる圧縮又は符号化のレベルなどの多くの伝送パラメータを決定する。端末処理速度又はスケジューリング要件だけではなく圧縮及び／又は符号化の要件からも、コントローラ２４は、エンコーダ処理ブロック２２により実現される適切な圧縮及び／又は符号化アルゴリズムを選択する。これは、ローカルライブラリ２６に記憶される、あるいは遠隔位置１７からダウンロードされるソフトウェアコードであってよい。端末処理速度及びネットワーク待ち時間及びスループット分散などの他のスケジューリングパラメータは、前述されたように入力バッファ及び出力バッファ２１と２３を構成するスケジューラ２５に転送される。このプロセスは図６に描かれている。
【００５１】
各端末―プロキシ接続は専用の入力バッファ２１、エンコーダ２２、出力バッファ２３、及びスケジューラ２５の組み合わせを含む。プロキシコントローラ２４は、それぞれのエンコーダ処理ブロック２２に適切なアルゴリズムを提供するだけではなく、それぞれのスケジューラ２５に対する命令でこれらのそれぞれを制御する。
【００５２】
代替の構成では、端末パラメータから伝送パラメータを決定することは、端末１３で実行される。次に、端末１３は、伝送パラメータを含む構成コマンド１６を、適切なトランスコーディング及び／又は圧縮アルゴリズムを選択、プログラミングし、スケジューラ２５に指示するコントローラ２４に転送する。追加の構成では、構成コマンドは（Ｊａｖａ（登録商標）バイトコードへのＵＲＬなどの）アルゴリズムに対する参照、及びコントローラ２４がスケジューラ２５に渡す必要とされるスケジューリング情報を単に含む場合がある。
【００５３】
ソフトウェアコントローラ２６は、プロキシデバイス１４に、構成コマンド１６により指定されるトランスコーダ／圧縮アルゴリズムソフトウェアモジュールをダウンロードする能力を与える。これらは、例えば端末１３から、あるいはサードパーティライブラリ１７からダウンロードされてよい。追加の代替策では、ソフトウェアコントローラ２６は、オンボードライブラリからソフトウェアモジュールをアップロードするように命令され、端末１３での実現を意図してよい。さらに追加の代替策では、トランスコーダアルゴリズムは、入力バッファ２１から出力バッファ２３に単にフレームを渡してよい。これは、受信されたフレームレートが、端末に伝送する前に減速されることだけが必要とされるときに発生し、その結果、例えば入力バッファ２１はビデオストリーム内で１フレームおきに省略し、それにより端末１３への速度を半減するように構成される。
【００５４】
実施形態はこれまでコンテンツプロバイダ１５から端末１３にコンテンツを転送することに関して説明されてきたが、多くの場合、例えば、双方向ビデオ呼など、端末１３からコンテンツプロバイダ１５にコンテンツを転送するニーズもある。このケースでは、符号化されたパケット又はフレームは端末１３からプロキシデバイス１４によって受信され、プロキシ１４はこれらを復号し、例えばあるフォーマットから別のフォーマットにパケットを解凍及び／又はトランスコーディングし、伝送の前に、おそらく別のタイプの符号化を使用してコンテンツプロバイダ１５にそれらを転送する。プロキシ１４により利用される復号のタイプは、再び前述された符号化決定と類似の方法で指定又は決定できる。
【００５５】
図７は、処理ブロックの伝送と受信の両方を示す端末１３のためのアーキテクチャを描く。端末１３は、入力バッファ３１、エンコーダ処理ブロック３２、出力バッファ３３、スケジューラ３５、及び端末コントローラ３４を備え、その全ては前述されたプロキシデバイス１４の対応する構成部品、及びそれぞれ入力バッファ２１、エンコーダブロック２２、出力バッファ２３、スケジューラ２５、及びプロキシコントローラ２４に類似する。
【００５６】
一実施形態では、端末コントローラ３４は、端末パラメータを決定し、これから前述されたように適切な圧縮体制を実現する。構成コマンドは、コンテンツを適切に受信するために実現するための圧縮／トランスコーディングアルゴリズムをプロキシデバイス１４に知らせるためにそれに送信される。代わりに、端末パラメータは構成コマンドで、使用する適切な復号アルゴリズムを決定するプロキシに転送されてよい。プロキシ１４は、次に端末エンコーダブロック３２内で実現される定義されたアルゴリズムを実現するように端末コントローラ３４に指示する。エンコーダアルゴリズムは、端末１３に記憶される、あるいは端末ソフトウェアコントローラ３６により指定位置からダウンロードされるコードであってよい。
【００５７】
端末コントローラ３４は、プロキシデバイス１４について前述されたように、選択的フレーム省略を起動するために、スケジューラ３５に入力バッファ３１を制御するように指示してもよい。さらに、又は代わりに、コントローラ３４はすでに説明されたような速度調整のためのフレーム複製を実現してよい。これは、例えばアプリケーションが動的に適応するフレームレートを受け入れることができない場合に必要である。
【００５８】
端末は、さらに、プロキシデバイスから受信されるパケットを受信し、復号する受信バッファ３８及びデコーダ処理ブロック３９を備える。デコーダ３９は、エンコーダ２２によって使用されるアルゴリズムを知っているので、例えばパケットを解凍して、プロキシデバイス１４のエンコーダ２２を補完する。符号化／復号アルゴリズムは、構成コマンドを使用してプロキシコントローラ２４と端末コントローラ３４の間で合意される。復号されたパケットは、次に端末処理チェーン又はブロックの残りに渡される。類似した構成は、符号化されたパケットが端末１３から受信され、復号され、コンテンツプロバイダ１５に渡される、プロキシデバイス１４で活用される。
【００５９】
圧縮のレベルは端末の解凍性能に合わせられる。好ましい方法は、無線リンク上での以後の対話を最小限に抑えるために、端末１３にプロキシデバイス１４において圧縮機／トランスコーダ２２をプログラミングさせることによる。通常、高圧縮率を達成するためには圧縮は解凍の少なくとも１０倍複雑であるため、圧縮機が待ち時間要件を満たすために圧縮処理の量を最小限に抑えるために端末１３で実現されるときに、圧縮方式を動的に変更することはきわめて魅力的になる。ＧＰＲＳのような低速の広域ネットワーク（ＷＡＮ）接続は、例えばブルーツース又はＩＥＥＥ８０２．１１上でのローカルエリアネットワーク（ＬＡＮ）接続よりも伝送データのビットあたりで多くの電力を消費するため、理想的には、圧縮のレベルは使用されているネットワークの性能に合わせて最適化されるべきであるが、両方のケースでは、ネットワーク及び端末のステータスからプロキシ構成を動的に変更する能力は、いつでも最善の方式が使用されることを意味する。例えば、マルチモード端末のための１つの考えられる解決策は、ビデオストリーム内でより確実にではなく（決定的待ち時間）ベースフレームを伝送するために、相対的に低速であるが確実なＧＰＲＳ接続を使用するが、機能強化層フレームを伝送するには、より性能が高く、より決定的ではないＷＬＡＮ接続を使用することである。冗長性のために、例えば、ＷＬＡＮ接続とＧＰＲＳ接続の両方でベース層フレームを、ＷＬＡＮ接続においては、機能強化層フレームを送信することも可能である。
【００６０】
これらの実施形態及び他の実施形態をさらに描くために、応用の例が後に続く。ビデオトラフィックの場合、スケジューラ２５は入力バッファ２１にサービスを提供し、特定のフレームレートで符号化するように指示されるエンコーダ２２にフレームを転送し、したがって符号化されたフレームは、例えばビデオの毎秒あたり１２フレームに対応して、出力バッファに、及び端末装置に転送される。入信フレームレートが発信フレームレートより高い場合には、スケジューラ２５は、入力バッファ２１に、あるいはいくつかの実施ではエンコーダアルゴリズム自体（２２）に、適切な場合、フレームを省略するように命令する。前記省略は端末のステータスによって決定でき、例えばフレームは、端末が忙しすぎてそれらを復号できないと予想されるときに省略される（端末の処理速度から決定される）、あるいはネットワークリソース（推定ネットワーク待ち時間）が、次のフレームが送信準備完了となる前にフレームを送達し、それを復号できるには十分でないときに省略される。さらに、端末とプロキシの間に複数のネットワーク接続が存在するとき、プロキシから端末への出力フレームは、フレームのタイプ、及び個々のネットワーク接続の性能推定値に応じて様々なネットワーク接続で送信できる。
【００６１】
この構成は、例えば電池が乏しくなる、又は端末が別の呼を開始したために、その使用可能な帯域幅を削減するために端末パラメータが変更する場合に、ネットワーク接続又は伝送パラメータを変更する能力をサポートする。これは、余分な容量を利用できない、あるいは接続が劣化するときに接続を維持できない、既知の「静的な」又は「固定された」構成での不利な点を克服する。例えば、ある瞬間に毎秒１００ｋｂｉｔが使用できるが、毎秒５６ｋｂｉｔが再生に必要とされる最悪のケースの平均スループットであるという事実に適応しない毎秒５６ｋｂｉｔのビデオ符号化を使用すると、何の適応も実行されない。次に、スループットが毎秒５６ｋｂｉｔ以上であると仮定して、パケットはバッファに入れられ、端末への伝送のためにスケジューリングされ、それ以外の場合、バッファは単にオーバフローし、パケットは失われるであろう（パケットは通常１フレーム分のデータより少なく搬送するので、これは、フレーム内の任意の点に対応するパケットとなるであろう）。
【００６２】
対照的に、実施形態はプロキシ１２で符号化（圧縮）エンティティ２２を動的にプログラミングし、パケットが符号化の後非常に長い間、バッファに入れられることが決してないように、これをスケジューリングと結合する。パケットは廃棄され、それらを圧縮するために使用される処理時間及び処理リソースの浪費を生じさせるため、符号化に続く拡張バッファリングは非効率的である。他の面は、端末の状態が、いつ、どのようにして圧縮が実行されるのかを制御するために使用されるものである。環境が静的である場合には、これは必要ではないが、動的な環境では、端末１３又は異なるネットワークリソースは経時的に変化し、したがってこれは、いつ、どのようにして圧縮が行われるのか、端末への伝送のためにどのネットワークを活用するのかを制御するために使用できる。例えば、端末１３内のプロセッサに対する負荷が、解凍するための処理速度が例えば毎秒２５（つまり、フレームを復号する速度は４０ｍｓ要する）であり、したがってスケジューラが、過去のフレームが復号されている間（つまり４０ｍｓ内に）次のフレームを送信しないことを知っているが、次に別のアプリケーションが起動され、ここでは処理速度が毎秒２０であり（フレーム復号は５０ｍｓを要する）、それからプロキシ１２においてプロキシコントローラ２４がこれを考慮に入れ、フレームを省略することによりフレームレートを減少し、解凍時間を短縮し、処理速度を毎秒２５に加速する圧縮のレベルを削減すると仮定する。さらに、端末が無線伝送／受信及びアプリケーション処理のために取りのけられた異なるリソースを有し、アプリケーション処理がボトルネックである場合には、アプリケーション処理のいくらかは無線通信のために取りのけられているリソースを使用するため、及びその逆のために切り替えることができるであろう。例えば、同じＤＳＰプロセッサが変調及び復調に加えてビデオ解凍のために使用できるであろう。端末処理リソース可用性のこの柔軟性は、プロキシを再構成することにより利用でき、フレームレートは再び毎秒２５に加速できる。
【００６３】
逆に、ネットワーク活動が増加する、あるいは端末が信号フェードに移動中であるために、ネットワークリソースが制限されるようになる場合には、ネットワーク状態も、トランスコーダがパケットが廃棄されるように不必要に圧縮を実行することが決してないように、スケジューリングを制御するために使用される。また、よりタイムクリティカルではないトラフィックが圧縮の前により長くプロキシ２１の入力バッファでバッファに入れることができ、さらに強力な圧縮アルゴリズムが使用され、このようにして圧縮率の利点を獲得できる。このケースでは、ビデオトラフィックは優先順位を取得するが、端末に送信できるトラフィックの量は少なくなるため、フレームレートは相応して減速され、圧縮率はより強力なアルゴリズム又はより低い解像度を使用することにより改善される。代わりに、マルチモード機能端末装置のケースでは、電池電力消費の増加を犠牲にしてさらに高いネットワークスループットを達成するために、２つ以上のネットワーク接続が同時に使用できる。
【００６４】
追加の例では、毎秒２５フレームのビデオストリームは端末１３に宛てられ、プロキシ１４に到達する。端末１３は処理を行い、電池電力リソースは制約され、電力消費を最小限に抑えようとする。端末では最小の処理が必要とされるため、端末１３は、電力効率を最大限にするために低レベルの圧縮で毎秒３フレームというフレームレートを可能にするために、トランスコーディングの予定を立てるようにプロキシ１４をプログラミングする。次に、端末１３は本線供給に接続されるか、あるいは電池が充電され、これが現在のＧＰＲＳ接続上で持続できる最大速度であるため、プロキシ１４は毎秒１２フレームでトランスコーディングを実行するように構成される。
【００６５】
ウェブブラウジングセッションは、ここでまた起動され、端末１３はビデオトランスコーディングの解像度を削減し、ビデオ品質まで破壊を最小限に抑えるために、ウェブトラフィックを、圧縮され、あらゆるビデオフレームの間で送信されるようにスケジューリングする。ウェブセッションは優れた反応性も必要とするが、ビデオほど重大ではなく、したがってウェブページ画像はさらに低い解像度に、及びこの反応性を維持するためにより高い圧縮率（より低い品質）を用いてトランスコーディングされる。その結果、ＷＬＡＮが使用可能になり、ここでプロキシコントローラ２４はビデオフレームレートを毎秒２５フレームまで加速するように構成され、品質（解像度）も改善され、ウェブブラウジングトラフィックはもはや圧縮されないか、あるいは画像はユーザの観点から最高の品質を達成するためにトランスコーディングされる。
【００６６】
変化する状態は、接続が互いに及ぼす影響を考慮に入れ、トラフィックフロー（ビデオ及びウェブブラウジング）ごとに適切な伝送パラメータを決定するプロキシコントローラ２４により監視される。
【００６７】
これらの実施形態により、動的なトランスコーディング／圧縮が可能になり、これを達成するために必要とされるスケジューリングの変更が実現される。これは、好ましくは、（エンドシステムに常駐できるであろう）プロキシエンティティ１４及び端末１３をプログラマブルにすることによって達成される。端末ステータスは、アルゴリズム及び構成コマンドの対話の標準化されたセットを必要としなくても、柔軟にプロキシを動的プログラミングするために使用できるため、このプログラム化可能性はソフトウェアダウンロード及び構成フレームワークを有することによって最も容易に達成される。従来の方法では、ウェブサイト又はプロキシは、端末により動的に構成（プログラミング）することはできないため、柔軟性は限られている。例えば、ダイヤルアップ接続を介して接続されるＷｉｎＣＥ（商標）デバイス、あるいはＧＰＲＳを介して接続されるＷＡＰ電話のために最適化されたビデオサービスはきわめて特殊であり、柔軟ではない。プログラム化可能性により、端末１３は、特殊なアルゴリズムの過去に合意された（つまり標準化された）セットを必要としなくてもどのようにして、いつトランスコーディング又は圧縮が行われるのかを正確に指定できる。プロキシは端末ほど処理リソースや、メモリが制約されておらず、したがって様々なアルゴリズムインプリメンテーションを保持できるため、これは、これらのタイプの構成の配備にはきわめて魅力的である。対照的に、端末は、シナリオの変化ごとに（適切なデコーダプラグインを用いて）それ自体を特殊に構成する必要があり、それは端末１３の仕様及びコストを増加するであろう。
【００６８】
プロキシ１４は、性能のために最適化する、及び必要な場合にリソースが制約された端末の処理及び電力消費の要件を削減するために、圧縮及び伝送の動作のバッファリング及びスケジューリングを可能にする。いつ、どの方式を使用するのかのタイミングをはかる際の精度は、アプリケーション及びユーザの優先順位に応じて端末（又は他の意思決定エンティティ）によって決定できる。例えば、端末内のスケジューリング機能は（端末のコンテキストに基づいて）ユーザからの優先順位によって、高速反応性及び特定のサイズでの全てのグラフィックオブジェクトがより重要であると見なされる（さらに高い優先順位の）テキストオブジェクトに優先して、端末に転送されるのを抑制するための無線接続の現在の低速度のためのアプリケーションを決定できる。
【００６９】
最もリソースが制約されているのは端末であるため、伝送パラメータ決定機能を実行するためにネットワーク内のプログラマブルプロキシデバイスを活用することが好ましく、このケースでは、これは有益ではあるが、端末が多少なりともマルチモード可能、構成可能、あるいはプログラム可能であることを命令することは必要とされない。
【００７０】
したがって、これらの実施形態は、異なるトラフィックコンテンツタイプの要件及び優先順位、及び（無線）接続８又は８’のコンテキスト及び性能を動的に変更するクライアント（エンド）デバイス１３を考慮に入れ、結合された方法で圧縮（又はトランスコーディング）プロキシ１４が伝送の予定を立て（つまり、記憶し、転送し）、データを圧縮又はトランスコーディングすることができるプロトコル柔軟性の使用に関する。このようにして、性能と品質の均衡をユーザの優先順位及び端末のコンテキストに合わせて保たせる最適化された解決策を達成することができる。
【００７１】
好ましくは、構成可能なプロキシデバイス１４は、（メモリの中に）前記（又はそれぞれの）端末１３に宛てられたパケットをバッファに格納し、（好ましくは端末に常駐する実行論理に基づいて）スケジューリングコードを使用していつ前記結合されたパケット（複数の場合がある）を圧縮（又はトランスコーディング）し、端末に送信するのかを決定する。また、圧縮アルゴリズムは、好ましくは、プロキシデバイス１４上でパケットの共同の圧縮及びスケジューリングを実行するために、端末１３によって提供される（又は示される）コードで実現される。加えて、解凍は、プロキシがパケットをネットワーク１（例えばインターネット）に転送する前に、端末からプロキシへ逆の方向で実行できる。
【００７２】
随意的に、スケジューリング、圧縮及び解凍を実行するためのコードは、Ｊａｖａ（登録商標）バイトコード、つまり共通言語ランタイム（ＣＬＲ）コードでプロキシデバイス１４に供給される。随意的に、プロキシデバイスはアクセスポイント又は基地局２に配置できるが、好ましくは法人のイントラネット又はネットワーク事業者の敷地内に配置できる。
【００７３】
別の実施形態では、プロキシデバイスは主要な意思決定インテリジェンスの機能を果たし、端末にダウンロードされるコードを指定することによって端末圧縮及びスケジューリング機能性を制御できる。このケースでは、プロキシデバイスは、最も適切なスケジューリング、及び一連のプログラムライブラリ（つまりＵＲＬにより識別されるウェブベースのリソース）から圧縮インプリメンテーション機能性に関して決定するために、一般的な優先順位及びコンテキスト情報を端末から収集しなければならない。これが図８に描かれている。
【００７４】
図９に描かれている別の実施形態では、第２のプロキシデバイス（Ｙ）１４’は端末コンテキストを認識し、最も適切な共同圧縮及びスケジューリング方針を決定するために必要とされるインテリジェンスを含んでいる。次に、それは端末タイプ及び圧縮／解凍を実行するプロキシデバイスによってサポートされる、考えられるインプリメンテーションのライブラリ１７から選択する。次に、適切な端末及び／プロキシソフトウェアモジュールは、これらのそれぞれのプラットホーム（端末１３及び／又は第１のプロキシデバイス（Ｘ）１４）に転送される。このケースでは、端末のコンテキスト及びプロキシの機能に関する情報が収集される必要がある。
【００７５】
この実施形態は、伝送の点で現在バッファに入れられているデータに作用するコード（ネイティブオブジェクトコード又はＪａｖａ（登録商標）バイトコード）で実現できる、（トランスコーディングを含む）一般的な意味でデータ圧縮アルゴリズムの使用をサポートする。加えて（及び随意的に）、バッファは、端末とプロキシの両方におけるさらに長期のキャッシュ（例えば、非常に大きな入力バッファ２１）機能性で拡張できる。このケースでは、端末（及びプロキシ）にダウンロードされる圧縮コードは、（メモリ又は二次記憶装置のサイズによって制限される）はるかに長い期間に渡って受信されたデータを記憶する圧縮アルゴリズムを含むことができ、データの圧縮を実行するときにはこのデータのプールを使用できる。例えば、同じデータ又は類似するデータが後の時点で転送される場合、バッファ内に保持される過去のコピーに対する参照が行われる。
【００７６】
好ましくは、実施形態は、圧縮フォーマット検出及び圧縮コード内の変化するアルゴリズムもサポートできる。例えば、ＪＰＥＧフォーマットで過去に符号化されたグラフィックオブジェクトをＰＮＧフォーマットに解凍するためである。
【００７７】
随意的に、プロキシは最小の追加オーバヘッドで強化されたセキュリティのために、結合された圧縮及び暗号化をサポートできる。
【００７８】
プロキシデバイスは信頼されなければならず、安全なセッションが使用される場合、法人のイントラネットに常駐できる。これは、暗号化により暗号化層の下にある層で圧縮を実行する能力が削減されるためである。追加のプロキシデバイスは、ネットワーク事業者又は彼らと関連するサービスプロバイダにより提供されるサービスのために、ネットワーク事業者の敷地に常駐できる。プロキシデバイス及び端末の相互認証は、例えばＰＫＩ証明書又は他の手段を使用して必要である。その結果、端末は（起源及び確実性の妥当性検査も必要とする）指定されたコードを使用して、適切にプロキシをプログラミングできる。それから、端末１３は（例えばウェブブラウザ及び他のインターネットアプリケーションの通常のプロキシ設定値を使用することによって）最も適切な圧縮機構を使用する適切なプロキシエンティティ１４を介する、ある特定のサービス（又はアプリケーション）のための全てのトラフィックの経路を定めることができる。また、前記機構は、（例えばＷＬＡＮホットスポットからセルラーネットワーク等に移動するなど）デバイスコンテキストの変更を考慮するために動的に再構成できる。
【００７９】
動的に構成可能なトランスコーディング及びスケジューリングを提供することに加えて、仮にもトランスコーディングする／圧縮するかどうかを決定するためには既知の機構を利用できる。例えば、適切な機構は、Ｈａｎら、ＩＢＭトーマス・Ｊ・ワトソン研究所（IBM Thomas J. Watson Research Center）、「モバイルウェブブラウジングのための画像トランスコーディングプロキシ内での動的適応（Dynamic adaptation in an image transcoding proxy for mobile web browsing）」、ＩＥＥＥパーソナル・コミュニケーション・マガジン（IEEE Personal Communications magazine）、１９９８年１２月号に記載されている。トランスコーディングのための意思決定プロセスは、予測されるリンク速度とともに（低応答時間が必要とされると仮定する）応答時間の予測される改善に基づくことができる。本参考文献の図４を参照すること。なんらかのリンク速度では、トランスコーディングする、又は圧縮することはもはや魅力的ではない。代わりに、以下に示すように、決定はエンドデバイスに対し（ストリーミング運転モードを仮定して）データ単位の一様な送達を提供することに基づくことができる。Ｈａｎの図１０を参照すること。
【００８０】
単純な端末は、端末パラメータを提供するにすぎないいくつかの実施形態で使用することができるが、さらに精密な端末はシステム柔軟性を高めるために使用できる。図１０は、完全にプログラマブルな端末１３の端末動作フローチャートを示す。端末１３は、例えば、ボイスオーバＩＰセッションを作成し、ウェブページをブラウジングする、あるいはビデオストリームを受信することを希望する端末ユーザから、セッション要求を受信する。前記要求は、例えば入信ビデオセッションを示す無線サービスプロバイダのアクセスポイント２からである場合もあるであろう。
【００８１】
端末１３は、次に、他のエンティティと関連付けられた特定のセッションパラメータを決定するために、発呼者エンティティ又は被呼者エンティティ（例えばコンテンツプロバイダ１５）とのハンドシェーキングプロトコルを実行する。特定のセッションパラメータは例えば、インターネット全体での（プロキシに対する）パケット伝送のその速度、転送されるデータの量、その使用可能な圧縮フォーマット、及び端末の無線帯域幅、処理、メモリ及び電池リソースに影響を及ぼす暗号化方式などの他のパラメータである。
【００８２】
端末１３は、次に、使用可能な帯域幅、処理、メモリ及び電池リソースを含む独自の端末パラメータを決定する。情報の両方のこれらの集合から、端末１３は、その内部使用のための適切なスケジューリング及びトランスコーディング方式を決定する。例えば特定の圧縮設定値を用いて、ビデオの毎秒１２フレームを受信する。端末１３は、次に適切な解凍及びスケジューリングソフトウェアモジュールをダウンロードする。端末１３は、次に、プロキシが正しいトランスコーディング／圧縮及び伝送スケジューリングを実現するために、適切な構成コマンド１６をプロキシ１４に転送する。プロキシデバイス１４は、これを達成するために、適切な圧縮及びスケジューリングソフトウェアモジュールをダウンロードしてもよい。
【００８３】
最終的には、端末１３は、例えばセッション開始プロトコル（ＳＩＰ）を使用して全て実行できるセッションを開始するためにプロキシ１４と通信する。端末はその端末パラメータを監視し続け、必要な場合、これらが変更する場合に、新しいスケジューリング及びトランスコーディングの要件を決定する。これは追加のスケジューリング及び／又はトランスコーディングソフトウェアモジュールのダウンロードを必要とする可能性は低いが、既存のものを再構成することを必要とする可能性はある。それは、また、セッション又は伝送パラメータを修正するために、追加の構成コマンドをプロキシ１４に転送することも必要とする可能性がある。
【００８４】
当業者は、前述された装置及び方法が、例えばディスク、ＣＤ−ＲＯＭ又はＤＶＤ−ＲＯＭなどのキャリヤ媒体、読取専用メモリ（ファームウェア）などのプログラミングされたメモリ上で、あるいは光信号キャリヤ又は電気信号キャリヤなどのデータキャリヤ上で、プロセッサ制御コードとして具現化されてよいことを認識する。多くの用途のために、本発明の実施形態は、ＤＳＰ（デジタル信号プロセッサ）、ＡＳＩＣ（特定用途向け集積回路）又はＦＰＧＡ（フィールドプログラマブルゲートアレイ）で実現されるであろう。このようにして、コードは従来のプログラムコード又はマイクロコード、あるいは例えばＡＳＩＣ又はＦＰＧＡをセットアップする、又は制御するためのコードを備えてよい。コードは、再プログラマブルロジックゲートアレイなどの再構成可能な装置を動的に構成するためのコードも備えてよい。同様に、コードはＶｅｒｉｌｏｇ（商標）又はＶＨＤＬ（超高速集積回路ハードウェア記述言語）などのハードウェア記述言語用のコードも備えてよい。当業者が認識するように、コードは、互いと通信する複数の結合された構成要素の間で分散されてよい。適切な場合、実施形態は、アナログハードウェアを構成するために、フィールド（再）プログラマブルアナログアレイ又は類似したデバイス上で実行するコードを使用して実現されてもよい。
【００８５】
当業者は、それらに関して説明される多様な実施形態及び特殊な機能が、前記教示に従って、他の実施形態又は概してそれらの明確に説明される機能と自由に結合できるであろうことも認識する。当業者は、また、添付請求項の範囲から逸脱することなく、多様な改変及び変型も説明された特定の例に対して加えることができることも認識するであろう。
【図面の簡単な説明】
【００８６】
【図１】携帯電話のためのＷＡＰトランスコーダプロキシ構成を示す図である。
【図２】一実施形態に従った無線端末用の動的トランスコーダプロキシ構成を示す図である。
【図３】特定の端末のために図２の動的プロキシのための適切な設定値を求める方法を示す図である。
【図４】一実施形態に従った動的プロキシの概略図を示す図である。
【図５】図４のプロキシのスケジューラ機能の動作の方法を示す図である。
【図６】図４のプロキシのプロキシコントローラ機能の操作の方法を示す図である。
【図７】一実施形態に従って、端末とプロキシの間で接続セッションをセットアップするためのプロセスを示す図である。
【図８】別の実施形態に従った無線端末用の動的トランスコーディングプロキシ構成を示す図である。
【図９】一実施形態に従った端末の操作を示すフローチャートである。
【図１０】完全にプログラマブルな端末のための端末動作フローチャートを示す図である。
【特許請求の範囲】
【請求項１】
コンテンツプロバイダを有するネットワークに結合され、コンテンツプロバイダとリンクによって前記ネットワークに結合された端末装置の間でコンテンツを転送するためのプロキシ装置であって、
第１のフォーマットで前記コンテンツを受信するための手段と、
性能パラメータを決定するための手段と、
前記性能パラメータに応じて第２のフォーマットに前記コンテンツを修正するための手段と、
前記修正されたコンテンツを伝送するための手段と、
を備える、プロキシ装置。
【請求項２】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワーク誤り率、パケット損失率、スループット及び／又は待ち時間のうち、１つ以上を備える、請求項１に記載の装置。
【請求項３】
前記リンクは無線リンクである、請求項１又は２に記載の装置。
【請求項４】
前記修正する手段は、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを備える、請求項１、２又は３に記載の装置。
【請求項５】
前記伝送手段と関連付けられる伝送パラメータを調整するための手段をさらに備える、請求項１、２又は３に記載の装置。
【請求項６】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを伝送する時、及び修正されたコンテンツを伝送するために使用するネットワーク接続のうち、１つ以上で構成する、請求項５に記載の装置。
【請求項７】
前記修正されたコンテンツは接続セッションの間に伝送され、前記第２のフォーマットは前記セッションの間に変化する、請求項１から６のいずれか１項に記載の装置。
【請求項８】
前記伝送パラメータは前記セッションの間に変化する、請求項６に従属するときの請求項７に記載の装置。
【請求項９】
前記受信手段は入力バッファを備え、前記修正する手段はエンコーダ処理ブロックを備え、前記送信手段はスケジューラによって制御される出力バッファを備える、請求項１から８のいずれか１項に記載の装置。
【請求項１０】
前記性能パラメータを受信し、前記エンコーダ処理ブロック内での使用のために、圧縮又はトランスコーディングアルゴリズムを選択、プログラミング化、あるいは構成するために設けられるプロキシコントローラをさらに備える、請求項７に記載の装置。
【請求項１１】
エンコーダ処理ブロック内で使用するためのトランスコーダ及び／又は圧縮アルゴリズムを実行する命令を受信するために設けられるプロキシコントローラをさらに備える、請求項９に記載の装置。
【請求項１２】
前記スケジューラは、前記出力バッファ内で未決の修正されたコンテンツの量を最小限に抑えるために、入力バッファ及び／又は符号化処理ブロックをさらに制御する、請求項９から１１のいずれか１項に記載の装置。
【請求項１３】
前記コンテンツ修正手段を実行するためにソフトウェアモジュールをダウンロードし、インストールする手段をさらに備える、請求項１から１２のいずれか１項に記載の装置。
【請求項１４】
第３のフォーマットで前記コンテンツを受信する手段と、
前記性能パラメータに応じて第４のフォーマットに前記コンテンツを修正する手段と、
前記修正されたコンテンツを送信するための手段と、
をさらに備える、請求項１から１４のいずれか１項に記載の装置。
【請求項１５】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項１４に記載の装置。
【請求項１６】
リンクによってネットワークに結合される端末装置のための端末装置であって、前記ネットワークは、コンテンツプロバイダ、及び前記コンテンツプロバイダと前記端末装置の間でプロキシ装置にコンテンツを転送する前記端末装置を有し、プロキシ装置は、
第１のフォーマットで前記コンテンツを受信するための手段と、
性能パラメータを決定するための手段と、
前記性能パラメータに応じて第２のフォーマットに前記コンテンツを修正する手段と、
前記修正されたコンテンツを送信する手段と、
を備える、端末装置。
【請求項１７】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワークスループット及び／又は待ち時間のうち、１つ以上を備える、請求項１６に記載の装置。
【請求項１８】
前記リンクは無線リンクである、請求項１６又は１７に記載の装置。
【請求項１９】
前記修正手段は、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを備える、請求項１６から１８のいずれか１項に記載の装置。
【請求項２０】
前記伝送手段に関連付けられる伝送パラメータを調整する手段をさらに備える、請求項１６から１８のいずれか１項に記載の装置。
【請求項２１】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを伝送する時、修正されたコンテンツの伝送のために使用するネットワーク接続のうち、１つ以上を含む、請求項２０に記載の装置。
【請求項２２】
前記修正されたコンテンツは接続セッションの間に送信され、前記第２のフォーマットは前記セッションの間に変化する、請求項１６から２１のいずれか１項に記載の装置。
【請求項２３】
前記伝送パラメータは前記セッションの間に変化する、請求項２０又は２１に従属するときの請求項２２に記載の装置。
【請求項２４】
前記受信手段は入力バッファを備え、前記修正手段はエンコーダ処理ブロックを備え、前記伝送手段はスケジューラによって制御される出力バッファを備える、請求項１６から２３のいずれか１項に記載の装置。
【請求項２５】
前記性能パラメータを受信し、前記エンコーダ処理ブロック内での使用のために、圧縮又はトランスコーディングアルゴリズムを選択し、プログラミングし、又は構成するために設けられるプロキシコントローラをさらに備える、請求項２２に記載の装置。
【請求項２７】
前記エンコーダ処理ブロック内での使用のために、トランスコーダ及び／又は圧縮アルゴリズムを実行する命令を受信するために設けられるプロキシコントローラをさらに備える、請求項２４に記載の装置。
【請求項２８】
前記スケジューラは、前記出力バッファ内で未決の修正されたコンテンツの量を最小限に抑えるために、前記入力バッファ及び／又は符号化処理ブロックをさらに制御する、請求項２４から２７のいずれか１項に記載の装置。
【請求項２９】
前記コンテンツ修正手段を実現するためにソフトウェアモジュールをダウンロードし、インストールする手段をさらに備える、請求項１６から１８のいずれか１項に記載の装置。
【請求項３０】
第３のフォーマットで前記コンテンツを受信する手段と、
前記性能パラメータに応じて第４のフォーマットに前記コンテンツを修正する手段と、
前記修正されたコンテンツを伝送する手段と、
をさらに備える、請求項１６から２９のいずれか１項に記載の装置。
【請求項３１】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項３０に記載の装置。
【請求項３２】
コンテンツプロバイダを有するネットワークに結合され、コンテンツプロバイダとリンクによって前記ネットワークに結合された端末装置の間でコンテンツを転送するプロキシ装置を操作する方法であって、
第１のフォーマットで前記コンテンツを受信すること、
性能パラメータを決定すること、
前記性能パラメータに応じて前記コンテンツを第２のフォーマットに修正すること、
前記修正されたコンテンツを伝送すること、
を含む、方法。
【請求項３３】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワーク誤り率、パケット損失率、スループット及び／又は待ち時間のうち、１つ以上を備える、請求項３２に記載の方法。
【請求項３４】
前記リンクは無線リンクである、請求項３２又は３３に記載の方法。
【請求項３５】
前記修正する工程は、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを有する、請求項３２から３４のいずれか１項に記載の方法。
【請求項３６】
前記伝送手段と関連付けられる伝送パラメータを調整することをさらに有する、請求項３２から３５のいずれか１項に記載の方法。
【請求項３７】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを送信する時、修正されたコンテンツを送信するために使用するネットワーク接続の１つ以上を有する、請求項３６に記載の方法。
【請求項３８】
前記修正されたコンテンツは接続セッションの間に伝送され、前記第２のフォーマットは前記セッションの間に変化する、請求項３２から３７のいずれか１項に記載の方法。
【請求項３９】
前記伝送パラメータは前記セッションの間に変化する、請求項３６又は３７に従属するときの請求項３８に記載の方法。
【請求項４０】
前記コンテンツ修正工程を実行するためにソフトウェアモジュールをダウンロードし、インストールすることをさらに備える、請求項３２から３９のいずれか１項に記載の方法。
【請求項４１】
第３のフォーマットで前記コンテンツを受信すること、
前記性能パラメータに応じて前記コンテンツを第４のフォーマットに修正すること、
前記修正されたコンテンツを送信すること、
をさらに有する、請求項３２から４０のいずれか１項に記載の方法。
【請求項４２】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項４１に記載の方法。
【請求項４３】
ネットワークにリンクによって結合される端末装置のために端末装置を操作する方法であって、前記ネットワークは、コンテンツプロバイダと、前記コンテンツプロバイダと前記端末装置の間でプロキシ装置にコンテンツを転送する前記端末装置とを有し、
第１のフォーマットで前記コンテンツを受信すること、
性能パラメータを決定すること、
前記性能パラメータに応じて第２のフォーマットに前記コンテンツを修正すること、
前記修正されたコンテンツを伝送すること、
を含む、方法。
【請求項４４】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワーク誤り率、パケット損失率、スループット及び／又は待ち時間のうち、１つ以上を含む、請求項４３に記載の方法。
【請求項４５】
前記リンクは無線リンクである、請求項４３又は４４に記載の方法。
【請求項４６】
前記修正することは、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを含む、請求項４３から４５のいずれか１項に記載の方法。
【請求項４７】
前記伝送手段と関連付けられる伝送パラメータを調整することをさらに備える、請求項４３から４５のいずれか１項に記載の方法。
【請求項４８】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを伝送する時、修正されたコンテンツの伝送のために使用するネットワーク接続のうち、１つ以上を含む、請求項４７に記載の方法。
【請求項４９】
前記修正されたコンテンツは接続セッションの間に伝送され、前記第２のフォーマットは前記セッションの間に変化する、請求項４３から４８のいずれか１項に記載の方法。
【請求項５０】
前記伝送パラメータは前記セッションの間に変化する、請求項４７又は４８に従属するときの請求項４９に記載の方法。
【請求項５１】
前記コンテンツ修正工程を実行するためにソフトウェアモジュールをダウンロードし、インストールすることをさらに備える、請求項４３から５０のいずれか１項に記載の方法。
【請求項５２】
第３のフォーマットで前記コンテンツを受信すること、
前記性能パラメータに依存して第４のフォーマットに前記コンテンツを修正すること、
前記修正されたコンテンツを伝送すること、
をさらに含む、請求項４３から５１のいずれか１項に記載の方法。
【請求項５３】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項５２に記載の方法。
【請求項５４】
請求項３２から５３のいずれか１項に記載の方法を実施するためにプロセッサを制御するための、プロセッサコード。
【請求項５５】
請求項５４に記載のコードを備える、コンピュータプログラム製品。
【請求項１】
コンテンツプロバイダを有するネットワークに結合され、コンテンツプロバイダとリンクによって前記ネットワークに結合された端末装置の間でコンテンツを転送するためのプロキシ装置であって、
第１のフォーマットで前記コンテンツを受信するための手段と、
性能パラメータを決定するための手段と、
前記性能パラメータに応じて第２のフォーマットに前記コンテンツを修正するための手段と、
前記修正されたコンテンツを伝送するための手段と、
を備える、プロキシ装置。
【請求項２】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワーク誤り率、パケット損失率、スループット及び／又は待ち時間のうち、１つ以上を備える、請求項１に記載の装置。
【請求項３】
前記リンクは無線リンクである、請求項１又は２に記載の装置。
【請求項４】
前記修正する手段は、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを備える、請求項１、２又は３に記載の装置。
【請求項５】
前記伝送手段と関連付けられる伝送パラメータを調整するための手段をさらに備える、請求項１、２又は３に記載の装置。
【請求項６】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを伝送する時、及び修正されたコンテンツを伝送するために使用するネットワーク接続のうち、１つ以上で構成する、請求項５に記載の装置。
【請求項７】
前記修正されたコンテンツは接続セッションの間に伝送され、前記第２のフォーマットは前記セッションの間に変化する、請求項１から６のいずれか１項に記載の装置。
【請求項８】
前記伝送パラメータは前記セッションの間に変化する、請求項６に従属するときの請求項７に記載の装置。
【請求項９】
前記受信手段は入力バッファを備え、前記修正する手段はエンコーダ処理ブロックを備え、前記送信手段はスケジューラによって制御される出力バッファを備える、請求項１から８のいずれか１項に記載の装置。
【請求項１０】
前記性能パラメータを受信し、前記エンコーダ処理ブロック内での使用のために、圧縮又はトランスコーディングアルゴリズムを選択、プログラミング化、あるいは構成するために設けられるプロキシコントローラをさらに備える、請求項７に記載の装置。
【請求項１１】
エンコーダ処理ブロック内で使用するためのトランスコーダ及び／又は圧縮アルゴリズムを実行する命令を受信するために設けられるプロキシコントローラをさらに備える、請求項９に記載の装置。
【請求項１２】
前記スケジューラは、前記出力バッファ内で未決の修正されたコンテンツの量を最小限に抑えるために、入力バッファ及び／又は符号化処理ブロックをさらに制御する、請求項９から１１のいずれか１項に記載の装置。
【請求項１３】
前記コンテンツ修正手段を実行するためにソフトウェアモジュールをダウンロードし、インストールする手段をさらに備える、請求項１から１２のいずれか１項に記載の装置。
【請求項１４】
第３のフォーマットで前記コンテンツを受信する手段と、
前記性能パラメータに応じて第４のフォーマットに前記コンテンツを修正する手段と、
前記修正されたコンテンツを送信するための手段と、
をさらに備える、請求項１から１４のいずれか１項に記載の装置。
【請求項１５】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項１４に記載の装置。
【請求項１６】
リンクによってネットワークに結合される端末装置のための端末装置であって、前記ネットワークは、コンテンツプロバイダ、及び前記コンテンツプロバイダと前記端末装置の間でプロキシ装置にコンテンツを転送する前記端末装置を有し、プロキシ装置は、
第１のフォーマットで前記コンテンツを受信するための手段と、
性能パラメータを決定するための手段と、
前記性能パラメータに応じて第２のフォーマットに前記コンテンツを修正する手段と、
前記修正されたコンテンツを送信する手段と、
を備える、端末装置。
【請求項１７】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワークスループット及び／又は待ち時間のうち、１つ以上を備える、請求項１６に記載の装置。
【請求項１８】
前記リンクは無線リンクである、請求項１６又は１７に記載の装置。
【請求項１９】
前記修正手段は、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを備える、請求項１６から１８のいずれか１項に記載の装置。
【請求項２０】
前記伝送手段に関連付けられる伝送パラメータを調整する手段をさらに備える、請求項１６から１８のいずれか１項に記載の装置。
【請求項２１】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを伝送する時、修正されたコンテンツの伝送のために使用するネットワーク接続のうち、１つ以上を含む、請求項２０に記載の装置。
【請求項２２】
前記修正されたコンテンツは接続セッションの間に送信され、前記第２のフォーマットは前記セッションの間に変化する、請求項１６から２１のいずれか１項に記載の装置。
【請求項２３】
前記伝送パラメータは前記セッションの間に変化する、請求項２０又は２１に従属するときの請求項２２に記載の装置。
【請求項２４】
前記受信手段は入力バッファを備え、前記修正手段はエンコーダ処理ブロックを備え、前記伝送手段はスケジューラによって制御される出力バッファを備える、請求項１６から２３のいずれか１項に記載の装置。
【請求項２５】
前記性能パラメータを受信し、前記エンコーダ処理ブロック内での使用のために、圧縮又はトランスコーディングアルゴリズムを選択し、プログラミングし、又は構成するために設けられるプロキシコントローラをさらに備える、請求項２２に記載の装置。
【請求項２７】
前記エンコーダ処理ブロック内での使用のために、トランスコーダ及び／又は圧縮アルゴリズムを実行する命令を受信するために設けられるプロキシコントローラをさらに備える、請求項２４に記載の装置。
【請求項２８】
前記スケジューラは、前記出力バッファ内で未決の修正されたコンテンツの量を最小限に抑えるために、前記入力バッファ及び／又は符号化処理ブロックをさらに制御する、請求項２４から２７のいずれか１項に記載の装置。
【請求項２９】
前記コンテンツ修正手段を実現するためにソフトウェアモジュールをダウンロードし、インストールする手段をさらに備える、請求項１６から１８のいずれか１項に記載の装置。
【請求項３０】
第３のフォーマットで前記コンテンツを受信する手段と、
前記性能パラメータに応じて第４のフォーマットに前記コンテンツを修正する手段と、
前記修正されたコンテンツを伝送する手段と、
をさらに備える、請求項１６から２９のいずれか１項に記載の装置。
【請求項３１】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項３０に記載の装置。
【請求項３２】
コンテンツプロバイダを有するネットワークに結合され、コンテンツプロバイダとリンクによって前記ネットワークに結合された端末装置の間でコンテンツを転送するプロキシ装置を操作する方法であって、
第１のフォーマットで前記コンテンツを受信すること、
性能パラメータを決定すること、
前記性能パラメータに応じて前記コンテンツを第２のフォーマットに修正すること、
前記修正されたコンテンツを伝送すること、
を含む、方法。
【請求項３３】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワーク誤り率、パケット損失率、スループット及び／又は待ち時間のうち、１つ以上を備える、請求項３２に記載の方法。
【請求項３４】
前記リンクは無線リンクである、請求項３２又は３３に記載の方法。
【請求項３５】
前記修正する工程は、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを有する、請求項３２から３４のいずれか１項に記載の方法。
【請求項３６】
前記伝送手段と関連付けられる伝送パラメータを調整することをさらに有する、請求項３２から３５のいずれか１項に記載の方法。
【請求項３７】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを送信する時、修正されたコンテンツを送信するために使用するネットワーク接続の１つ以上を有する、請求項３６に記載の方法。
【請求項３８】
前記修正されたコンテンツは接続セッションの間に伝送され、前記第２のフォーマットは前記セッションの間に変化する、請求項３２から３７のいずれか１項に記載の方法。
【請求項３９】
前記伝送パラメータは前記セッションの間に変化する、請求項３６又は３７に従属するときの請求項３８に記載の方法。
【請求項４０】
前記コンテンツ修正工程を実行するためにソフトウェアモジュールをダウンロードし、インストールすることをさらに備える、請求項３２から３９のいずれか１項に記載の方法。
【請求項４１】
第３のフォーマットで前記コンテンツを受信すること、
前記性能パラメータに応じて前記コンテンツを第４のフォーマットに修正すること、
前記修正されたコンテンツを送信すること、
をさらに有する、請求項３２から４０のいずれか１項に記載の方法。
【請求項４２】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項４１に記載の方法。
【請求項４３】
ネットワークにリンクによって結合される端末装置のために端末装置を操作する方法であって、前記ネットワークは、コンテンツプロバイダと、前記コンテンツプロバイダと前記端末装置の間でプロキシ装置にコンテンツを転送する前記端末装置とを有し、
第１のフォーマットで前記コンテンツを受信すること、
性能パラメータを決定すること、
前記性能パラメータに応じて第２のフォーマットに前記コンテンツを修正すること、
前記修正されたコンテンツを伝送すること、
を含む、方法。
【請求項４４】
前記性能パラメータは、端末電池レベル、端末処理リソースステータス、端末メモリリソースステータス、ネットワーク誤り率、パケット損失率、スループット及び／又は待ち時間のうち、１つ以上を含む、請求項４３に記載の方法。
【請求項４５】
前記リンクは無線リンクである、請求項４３又は４４に記載の方法。
【請求項４６】
前記修正することは、圧縮アルゴリズム、トランスコーディングアルゴリズム、前記第１のフォーマットでの前記コンテンツのいくらかの削除のうち、１つ又は組み合わせを含む、請求項４３から４５のいずれか１項に記載の方法。
【請求項４７】
前記伝送手段と関連付けられる伝送パラメータを調整することをさらに備える、請求項４３から４５のいずれか１項に記載の方法。
【請求項４８】
前記伝送パラメータは、前記修正されたコンテンツを伝送する速度、前記修正されたコンテンツを伝送する時、修正されたコンテンツの伝送のために使用するネットワーク接続のうち、１つ以上を含む、請求項４７に記載の方法。
【請求項４９】
前記修正されたコンテンツは接続セッションの間に伝送され、前記第２のフォーマットは前記セッションの間に変化する、請求項４３から４８のいずれか１項に記載の方法。
【請求項５０】
前記伝送パラメータは前記セッションの間に変化する、請求項４７又は４８に従属するときの請求項４９に記載の方法。
【請求項５１】
前記コンテンツ修正工程を実行するためにソフトウェアモジュールをダウンロードし、インストールすることをさらに備える、請求項４３から５０のいずれか１項に記載の方法。
【請求項５２】
第３のフォーマットで前記コンテンツを受信すること、
前記性能パラメータに依存して第４のフォーマットに前記コンテンツを修正すること、
前記修正されたコンテンツを伝送すること、
をさらに含む、請求項４３から５１のいずれか１項に記載の方法。
【請求項５３】
前記第１のコンテンツフォーマット及び第３のコンテンツフォーマットが同じであり、前記第２のコンテンツフォーマット及び第４のコンテンツフォーマットが同じである、請求項５２に記載の方法。
【請求項５４】
請求項３２から５３のいずれか１項に記載の方法を実施するためにプロセッサを制御するための、プロセッサコード。
【請求項５５】
請求項５４に記載のコードを備える、コンピュータプログラム製品。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００６−７４７２８（Ｐ２００６−７４７２８Ａ）
【公開日】平成１８年３月１６日（２００６．３．１６）
【国際特許分類】
【外国語出願】
【出願番号】特願２００５−１７３４３５（Ｐ２００５−１７３４３５）
【出願日】平成１７年６月１４日（２００５．６．１４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成１８年３月１６日（２００６．３．１６）
【国際特許分類】
【出願番号】特願２００５−１７３４３５（Ｐ２００５−１７３４３５）
【出願日】平成１７年６月１４日（２００５．６．１４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]