制約あるシステムリソースを有するデバイス上でアプリケーション出力を表示する方法およびシステム
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示されるシステムは、アプリケーションプログラムを実行するアプリケーションサーバを含む。プロキシサーバは、アプリケーションプログラムによって形成されたグラフィカルディスプレイ出力のスクリーンを表わすデータをアプリケーションサーバから受信する。ユーザデバイスは、クライアントアプリケーションを実行する。クライアントアプリケーションは、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表現する静的イメージデータをプロキシサーバから受信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、サーバデバイス上で実行するアプリケーションプログラムの出力をクライアントデバイスに表示することに関する。より特定的には、制約あるシステムリソースを有するデバイス上でアプリケーションプログラムの出力を表示する技術および装置に関する。
【背景技術】
【０００２】
ネットワーク化されたリソースにリモートアクセスを提供する技術は、様々なクライアント／サーバソフトウェアの組み合わせを含む。こうした組み合わせの一つは、「シンクライアント（ｔｈｉｎ−ｃｌｉｅｎｔ）」または「分散型アプリケーション処理」システムと、称されることが多い。これらシステムにおいて、アプリケーションプログラムは、サーバコンピュータデバイスによって実行される。このデバイスは、「シンクライアント」または「シンクライアントアプリケーション」と通常称される１つ以上のクライアントコンピュータデバイスを代表して、「アプリケーションサーバ」と、通常称される。シンクライアントでユーザから受信されたアプリケーションへの入力、および、アプリケーションサーバで実行するアプリケーションによって生成された出力のみが、シンクライアントとアプリケーションサーバとの間で送信される。シンクライアントのコンピュータアーキテクチャは、アプリケーションおよび他のシステムリソースにリモート接続を提供するために、よく使われているインプリメンテーションである。このようなシステムの例には、Ｉｎｔｅｌｌｉｇｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ （ＩＣＡ）クライアントと組み合わせるＣｉｔｒｉｘ ＭｅｔａＦｒａｍｅ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｓｅｒｖｅｒソフトウェア（フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．から市販）、Ｘ Ｗｉｎｄｏｗｓ（登録商標）クライアントと組み合わせるＸサーバ（Ｘ Ｃｏｎｓｏｒｔｉｕｍから市販）、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）クライアントと組み合わせるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＮＴ Ｓｅｒｖｅｒ ４．０ Ｔｅｒｍｉｎａｌ Ｓｅｒｖｅｒ Ｅｄｉｔｉｏｎ（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販）が含まれる。
【０００３】
シンクライアントコンピュータアーキテクチャ内のクライアントは、アプリケーションプログラムを実行しないため、かつ、ユーザ入力をアプリケーションサーバに送信するのみで、そのアプリケーションサーバ上で実行されるアプリケーションの出力を表示するのみであるため、クライアントデバイスは、ユーザが気付くような性能低下をともなわずに、限られたメモリ量、より遅い通信サブシステム、限られたシステムリソースを提供し得る。パソコン、ワークステーション、あるいは、他のコンピュータデバイスは、典型的には、豊富なシステムリソースを提供する。これは、シンクライアントのアプリケーションを実行し、アプリケーションサーバと通信するためである。
【０００４】
しかしながら、リモート接続を必要とする多くのユーザは、携帯電話および携帯情報端末のようなシンクライアントとして機能するのに十分なメモリ、ネットワークリソース、あるいは、適切なオペレーティングシステム環境を提供しないコンピュータデバイスを、シンクライアントとして使用している。例えば、現行の携帯電話の多くは、１メガバイト未満のランダムアクセスメモリーを備えるが、これは、シンクライアントのアプリケーション実行には一般に十分でない。さらに、内蔵システムにとって、アプリケーション出力用のアプリケーションサーバにアクセスすることは、しばしば、有用である。典型的には、これらシステムも、また、メモリのようなリソースに制約がある。
【０００５】
メモリ制限があるように、システムリソースに制約のあるクライアントデバイスが、アプリケーションサーバ上で実行するアプリケーションプログラムと、相互作用するシステムを所有することは、有益なことである。
【発明の開示】
【課題を解決するための手段】
【０００６】
（発明の概要）
本発明は、ローエンド（ｌｏｗ−ｅｎｄ）クライアントデバイス（例えば、携帯電話、携帯情報端末、内蔵システム）が、アプリケーションサーバ上で実行するアプリケーションプログラムと相互作用して、アプリケーションが、様々な位置からのリモートアクセスを可能とする。
【０００７】
一局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示するシステムに関する。本システムは、アプリケーションプログラムを実行するアプリケーションサーバを含む。プロキシサーバは、アプリケーションサーバから、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信する。ユーザデバイスは、プロキシサーバから静的イメージデータを受信するクライアントアプリケーションを実行する。静的イメージデータは、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わす。
【０００８】
別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する方法に関する。アプリケーションサーバは、グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを実行し、生成されたグラフィカルユーザインターフェースデータのスクリーンを、プロキシサーバに送信する。プロキシサーバは、生成されたグラフィカルユーザインターフェースデータのスクリーンの少なくとも一部を表わす静的イメージデータを、ユーザデバイスに送信する。ユーザデバイスは、送信された静的イメージデータを表示する。
【０００９】
さらに別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する装置に関する。本装置は、アプリケーションサーバから、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを、第一のプロトコル形式で受信する第一のプロトコルハンドラを含む。本装置は、また、第一のプロトコルハンドラによって受信されたグラフィカルディスプレイ出力のスクリーンの少なくとも一部を表わす静的イメージデータを、表示用クライアントアプリケーションに、第二のプロトコル形式で送信する第二のプロトコルハンドラを含む。
【００１０】
また別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成されたグラフィカルディスプレイ出力を、ユーザデバイスに表示する方法に関する。静的イメージデータは、アプリケーションサーバから、第一のプロトコル形式を介して受信され、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わす。静的イメージデータは、ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して送信される。この静的イメージデータは、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンの少なくとも一部を表わす。
【００１１】
さらにまた別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示するシステムに関する。本システムは、アプリケーションプログラムを実行するアプリケーションサーバを含む。本システムは、また、アプリケーションサーバから、プレゼンテーションレベルのプロトコルを介して、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するプロキシサーバも含む。本システムは、さらに、クライアントアプリケーションを実行するユーザデバイスを含み、このクライアントアプリケーションは、プロキシサーバから、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わす静的イメージデータを、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して受信する。
【００１２】
別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示する方法に関する。アプリケーションサーバは、グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを実行する。アプリケーションサーバは、生成されたグラフィカルユーザインターフェースデータのスクリーンを、プレゼンテーションレベルのプロトコルを介して、プロキシサーバに送信する。プロキシサーバは、生成されたグラフィカルユーザインターフェースデータのスクリーンの少なくとも一部を表わす静的イメージを、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して、ユーザデバイスに送信する。ユーザデバイスによって、この送信された静的イメージデータを表示する。
【００１３】
さらなる局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラムを具体化した製品の品目に関する。この製品の品目には、サーバ上で実行するアプリケーションによって生成されたグラフィカルユーザデータインターフェースのスクリーンを、プロキシサーバに送信するコンピュータ読み出し可能なプログラム手段と、生成されたグラフィカルユーザデータインターフェースのスクリーンの少なくとも一部を表わす静的イメージデータを、プロキシサーバを介して、ユーザデバイスに通信するコンピュータ読み出し可能なプログラム手段と、送信された静的イメージデータを、ユーザデバイスによって、表示するコンピュータ読み出し可能なプログラム手段とが、含まれる。
【００１４】
さらに別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成されるグラフィカルディスプレイ出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラムを具体化した製品の品目に関する。この製品の品目には、アプリケーションサーバから、第一のプロトコルを介して、アプリケーションサーバ上で実行するアプリケーションによって形成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するコンピュータ読み出し可能なプログラム手段と、第二のプロトコルを介して、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンの少なくとも一部を表わす静的イメージデータを、ディスプレイ用クライアントアプリケーションに通信するコンピュータ読み出し可能なプログラム手段とが、含まれる。
【００１５】
本発明のこれらおよび他の局面が、以下の詳細な記述と添付図面から容易に明らかになる。添付図面は、本発明を説明することを意図し、本発明を限定することを意図していない。
【発明を実施するための最良の形態】
【００１６】
（詳細な説明）
図１を参照すると、システムリソース制約を有するクライアントデバイスにアプリケーション出力を提供するシステム１００は、アプリケーションサーバ１１０と、プロキシサーバ１５０と、クライアント１４０とを含む。図１に示す実施形態において、１つのみのアプリケーションサーバ１１０と、プロキシサーバ１５０と、クライアント１４０としか描かれていないが、これらコンポーネントの任意または各々は複数個を備え得る。例えば、一実施形態において、システム１００は、複数の論理グループ化されたアプリケーションサーバ１１０を備え、そのそれぞれは、クライアント１４０を代表して、アプリケーションを実行するために利用可能である。これらの実施形態において、サーバの論理グループは、「サーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）」と称され得る。他の実施形態において、複数のプロキシサーバ１５０が備えられ得る。これら実施形態の一部において、プロキシサーバは、地理的に分散され得る。
【００１７】
アプリケーションサーバ１１０は、クライアント１４０を代表して、１つ以上のプログラム１２２、１２４、１２６、１２８を実行する。アプリケーションプログラムは、データを処理して、出力を提供することと、オペレーティングシステムを用いて、システムリソースにアクセスすることとを行う任意のプログラムである。例示的なアプリケーションプログラムには、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤ（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）のような言語処理アプリケーション、ＭＩＣＲＯＳＯＦＴ ＥＸＣＥＬ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）のような表計算プログラム、ＭＩＣＲＯＳＯＦＴ ＯＵＴＬＯＯＫ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）およびＧＲＯＵＰＷＩＳＥ（ユタ州ＰｒｏｖｏのＮｏｖｅｌｌ Ｃｏｒｐ．製）のような電子メールプログラム、ＳＴＡＲ ＯＦＦＩＣＥ（カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ製）のような生産性一式（ｐｒｏｄｕｃｔｉｖｉｔｙ ｓｕｉｔｅｓ）を含む。
【００１８】
アプリケーションサーバ１１０は、第一のネットワーク１２５を介して、プロキシサーバ１５０と通信する。第一のネットワーク１２５は、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、あるいは、インターネットのような広域ネットワーク（ＷＡＮ）であり得る。アプリケーションサーバ１１０およびプロキシサーバ１５０は、標準の電話回線、ＬＡＮまたはＷＡＮリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、広帯域接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）および無線接続を含む様々な接続を介して、第一のネットワーク１２５に接続し得る。アプリケーションサーバ１１０とプロキシサーバ１５０との間の接続は、様々なデータリンク層通信プロトコル（例えば、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、ＮｅｔＢＥＵＩ、ＳＭＢ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＡＲＣＮＥＴ、Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）、ＲＳ２３２、ＩＥＥＥ ８０２．１１、ＩＥＥＥ ８０２．１１ａ、ＩＥＥＥ ８０２．１１ｂ、ＩＥＥＥ ８０２．１１ｇおよび直接非同期接続）を使用し得る。
【００１９】
プロキシサーバ１５０は、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌクライアント（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）、または、ＩＣＡクライアント（フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．製）のような１つ以上のシンクライアントアプリケーション１５２、１５４を実行する。アプリケーションサーバ１１０は、アプリケーションプログラム１２２、１２４、１２６、１２８の出力を、プロキシサーバ１５０上で実行するシンクライアントアプリケーション１５２、１５４に通信し、アプリケーションプログラム１２２、１２４、１２６、１２８に向けられたユーザ入力を、シンクライアントアプリケーション１５２、１５４から受信する。アプリケーションサーバ１１０は、Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）プロトコル（フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．から市販）、または、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販）のようなプレゼンテーション層プロトコルを使用して、ネットワーク１２５を介して、シンクライアントアプリケーション１５２、１５４と、通信する。図１に示す実施形態において、２つのシンクライアントアプリケーションのみしか描かれていないが、プロキシサーバ１５０は、任意の数のシンクライアントアプリケーション１５２、１５４をホストし得る。
【００２０】
また、プロキシサーバ１５０は、プロキシサーバアプリケーション１５８を実行する。プロキシサーバアプリケーション１５８は、アプリケーションプログラム、サブシステムまたはサービスであり得る。プロキシサーバアプリケーション１５８は、プロキシサーバ１５０によってホストされるシンクライアントアプリケーション１５２、１５４を管理する。プロキシサーバアプリケーションは、また、シンクライアントアプリケーション１５２、１５４によって受信されたアプリケーション出力を、クライアントデバイス１４０に送信し、クライアントデバイス１４０から受信されたユーザ入力を、プロキシサーバ１５０上で実行する適切なシンクライアントアプリケーション１５２、１５４に送信する。
【００２１】
プロキシサーバ１５０上で実行するプロキシサーバアプリケーション１５８は、第二のネットワーク１７５を介して、クライアント１４０と通信する。クライアント１４０が内蔵システムである実施形態において、クライアント１４０とプロキシサーバ１５０とは、標準の電話回線、ＬＡＮまたはＷＡＮリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、広帯域接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）および無線接続を含む様々な接続を介して、第二のネットワーク１７５と接続し得る。クライアント１４０とプロキシサーバ１５０との間の接続は、様々なデータリンク層通信プロトコル（例えば、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、ＮｅｔＢＥＵＩ、ＳＭＢ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＡＲＣＮＥＴ、Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）、ＲＳ２３２、ＩＥＥＥ ８０２．１１、ＩＥＥＥ ８０２．１１ａ、ＩＥＥＥ ８０２．１１ｂ、ＩＥＥＥ ８０２．１１ｇおよび直接非同期接続）を使用し得る。
【００２２】
他の実施形態において、クライアントデバイス１４０は、携帯電話または携帯情報端末のような移動体デバイスである。これらの実施形態において、クライアント１４０とプロキシサーバアプリケーション１５８とは、Ｗ−ＣＤＭＡのようなＧＳＭまたはＣＤＭＡファミリからなる多数の周知のプロトコルの任意の一つを用いて、第二のネットワークと接続する。これらプロトコルは、商業無線通信サービスおよびＷ−ＣＤＭＡをサポートし、特に、ＮＴＴ ＤｏＣｏＭｏによって提供されるｉ−ＭｏｄｅおよびｍＭｏｄｅサービスをサポートする基底プロトコルである。
【００２３】
クライアントデバイス１４０は、クライアントアプリケーション１４６を実行する。クライアントアプリケーションは、ｈｔｔｐまたはｈｔｔｐｓ要求を、プロキシサーバアプリケーション１５８へ送信し、プロキシサーバアプリケーション１５８から受信する。クライアントアプリケーション１４８は、実行するアプリケーションプログラム１２２、１２４、１２６、１２８に向けられたユーザ入力を、プロキシサーバアプリケーション１５８に、第二のネットワーク１７５を介して送信する。それは、また、アプリケーションサーバ１１０上で実行するアプリケーションプログラム１２２、１２４、１２６、１２８の出力に対応するクライアントデバイスのスクリーン上に、グラフィカル出力を与える役割も担っている。
【００２４】
多くの実施形態において、アプリケーションサーバ１１０およびプロキシサーバ１５０は、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎまたはテキサス州Ｒｏｕｎｄ ＲｏｃｋのＤｅｌｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造されたもののようなパーソナルコンピュータまたはコンピュータサーバとして、提供される。クライアントデバイス１４０が内蔵システムである実施形態において、クライアントデバイス１４０もまた、パーソナルコンピュータとしても、また提供され得る。図２Ａおよび図２Ｂは、これらの実施形態において、アプリケーションサーバ１１０、、プロキシサーバ１５０、または、クライアントデバイスとして有用な典型的なコンピュータ２００のブロック図を示す。図２Ａおよび図２Ｂに示すように、各コンピュータは、中央演算処理装置２０２、および主記憶装置２０４を含む。各コンピュータ２００は、また、１つ以上の入出力デバイス２３０ａ〜２３０ｎ（一般に、参照番号２３０で示す）、および、中央演算処理装置２０２と通信するキャッシュメモリ２４０のような他のオプション要素も含み得る。
【００２５】
中央演算処理装置２０２は、主記憶装置２０４から取り出された命令に応答し、処理する任意の論理回路網である。多数の実施形態において、中央演算処理装置は、マイクロプロセッサユニットによって提供される。例えば、８０８８、８０２８６、８０３８６、８０４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標） ＩＩ、ＣｅｌｅｒｏｎまたはＸｅｏｎプロセッサ（いずれもカリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ製）、６８０００、６８０１０、６８０２０、６８０３０、６８０４０、ＰｏｗｅｒＰＣ６０１、ＰｏｗｅｒＰＣ６０４、ＰｏｗｅｒＰＣ６０４ｅ、ＭＰＣ６０３ｅ、ＭＰＣ６０３ｅｉ、ＭＰＣ６０３ｅｖ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｐ、ＭＰＣ７４０、ＭＰＣ７４５、ＭＰＣ７５０、ＭＰＣ７５５、ＭＰＣ７４００、ＭＰＣ７４１０、ＭＰＣ７４４１、ＭＰＣ７４４５、ＭＰＣ７４４７、ＭＰＣ７４５０、ＭＰＣ７４５１、ＭＰＣ７４５５、ＭＰＣ７４５７プロセッサ（いずれもイリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎ製）、Ｃｒｕｓｏｅ ＴＭ５８００、Ｃｒｕｓｏｅ ＴＭ５６００、Ｃｒｕｓｏｅ ＴＭ５５００、Ｃｒｕｓｏｅ ＴＭ５４００、Ｅｆｆｉｃｅｏｎ ＴＭ８６００、Ｅｆｆｉｃｅｏｎ ＴＭ８３００またはＥｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ（カリフォルニア州Ｓａｎｔａ ＣｌａｒａのＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎ製）、ＲＳ／６０００プロセッサ、ＲＳ６４、ＲＳ６４ ＩＩ、Ｐ２ＳＣ、ＰＯＷＥＲ３、ＲＳ６４ ＩＩＩ、ＰＯＷＥＲ３−１１、ＲＳ６４ ＩＶ、ＰＯＷＥＲ４、ＰＯＷＥＲ４＋、ＰＯＷＥＲ５またはＰＯＷＥＲ６プロセッサ（いずれもニューヨーク州Ｗｈｉｔｅ ＰｌａｉｎｓのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ製）、あるいは、ＡＭＤ Ｏｐｔｅｒｏｎ、ＡＭＤ Ａｔｈａｌｏｎ ６４ＦＸ、ＡＭＤ ＡｔｈａｌｏｎまたはＡＭＤ Ｄｕｒｏｎプロセッサ（カリフォルニア州ＳｕｎｎｙｖａｌｅのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ製）である。
【００２６】
主記憶装置２０４は、データを格納可能で、マイクロプロセッサ２０２によって直接アクセスされる任意のストレージロケーションが可能な１つ以上のメモリチップであり得る。例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ）、Ｂｕｒｓｔ ＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ ＳＲＡＭ（ＢＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、Ｆａｓｔ Ｐａｇｅ Ｍｏｄｅ ＤＲＡＭ（ＦＰＭ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＲＡＭ（ＥＤＯ ＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＥＤＯ ＤＲＡＭ）、Ｂｕｒｓｔ Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＢＥＤＯ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、シンクロナスＤＲＡＭ （ＳＤＲＡＭ）、ＪＥＤＥＣ ＳＲＡＭ、ＰＣ１００ ＳＤＲＡＭ、Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ）、ＳｙｎｃＬｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＤＲＡＭ（ＤＲＤＲＡＭ）、あるいは、強誘電体ＲＡＭ（ＦＲＡＭ）である。
【００２７】
図２Ａに示す実施形態において、プロセッサ２０２は、システムバス２２０（詳細は後述）を介して、主記憶装置２０４と通信する。図２Ｂは、コンピュータシステム２００の実施形態を示す。ここでは、プロセッサは、メモリポートを介して、主記憶装置２０４と直接通信する。例えば、図２Ｂにおいて、主記憶装置２０４は、ＤＲＤＲＡＭであり得る。
【００２８】
図２Ａおよび図２Ｂは、主記憶装置２０２が、二次バス（ときどき、「バックサイド」バスと称される）を介して、キャッシュメモリ２４０と直接通信する実施形態を示す。他の実施形態において、主記憶装置２０２は、システムバス２２０を用いて、キャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、典型的には、主記憶装置２０４より応答速度が速く、典型的には、ＳＲＡＭ、ＢＳＲＡＭまたはＥＤＲＡＭによって提供される。
【００２９】
図２Ａに示す実施形態において、プロセッサ２０２は、様々な入出力デバイス２３０と、ローカルシステムバス２２０を介して、通信する。様々なバスは、中央演算処理装置２０２を入出力デバイス２３０に接続するために使用され得る。これらバスには、ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−Ｅｘｐｒｅｓｓバス、またはＮｕＢｕｓを含む。入出力デバイスがビデオディスプレイである実施形態において、プロセッサ２０２は、このディスプレイと通信するために、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図２Ｂは、コンピュータシステム２００の実施形態を示す。ここでは、主記憶装置２０２は、入出力デバイス２３０ｂと、ＨｙｐｅｒＴｒａｎｓｐｏｒｔ、Ｒａｐｉｄ Ｉ／ＯまたはＩｎｆｉｎｉＢａｎｄを介して、直接通信している。図２Ｂは、また、ローカルバスと直接通信の混合された実施形態を示す。すなわち、プロセッサ２０２は、ローカル相互接続バスを使用して、入出力デバイス２３０ａと通信し、その一方、入出力デバイス２３０ｂと直接通信する。
【００３０】
幅広い多様な入出力デバイス２３０が、コンピュータシステム２００内で使用され得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイク、および、ドローイングタブレットを含む。出力デバイスは、ビデオディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および、昇華型プリンタを含む。入出力デバイスには、コンピュータシステム２００用の大容量ストレージを提供し得る。例えば、ハードディスクドライブ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクのようなフロッピディスクを受け入れるフロッピディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、様々な形式のテープドライブ、および、ＵＳＢ Ｆｌａｓｈ ＤｒｉｖｅラインのようなＵＳＢストレージデバイス（カリフォルニア州Ｌｏｓ ＡｌａｍｉｔｏｓのＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ，Ｉｎｃ．製）である。
【００３１】
さらなる実施形態において、入出力デバイス２３０は、システムバス２２０と外部通信バスとの間のブリッジになり得る。外部通信バスは、例えば、ＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｂｕｓ、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標）バス、ＡｐｐｌｅＴａｌｋ ｂｕｓバス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ バス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、または、Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ 小型コンピュータシステムインターフェースバスである。
【００３２】
図２Ａおよび図２Ｂに示すような汎用デスクトップコンピュータは、典型的には、オペレーティングシステムの制御下で動作し、このオペレーティングシステムが、タスクのスケジューリングおよびシステムリソースへのアクセスを管理する。典型的なオペレーティングシステムには、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．製）、ＭａｃＯＳ（カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ製）、ＯＳ／２（ニューヨーク州ＡｒｍｏｎｋのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ製）、および、Ｌｉｎｕｘ（ユタ州Ｓａｌｔ Ｌａｋｅ ＣｉｔｙのＣａｌｄｅｒａ Ｃｏｒｐ．より無料で頒布されているオペレーティングシステム）がある。
【００３３】
クライアントデバイス１４０が、移動体デバイスである実施形態において、クライアントデバイスは、ＪＡＶＡ（登録商標）対応の携帯電話であり得る。例えば、ｉ５０ｓｘ、ｉ５５ｓｒ、ｉ５８ｓｒ、ｉ８５ｓ、ｉ８８ｓ、ｉ９０ｃ、ｉ９５ｃ１またはｉｍ１１０００（いずれもイリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐ．製）、６０３５または７１３５（日本国京都府の京セラ製）、あるいは、ｉ３００またはｉ３３０（韓国ソウルのＳａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．製）である。クライアントデバイス１４０が移動体である他の実施形態において、クライアントデバイスは、ＰａｌｍＯＳのオペレーティングシステムの制御下で動作する携帯情報端末（ＰＤＡ）であり得る。例えば、Ｔｕｎｇｓｔｅｎ Ｗ、ＶＩＩ、ＶＩＩｘ、ｉ７０５（いずれもカリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．製）である。さらなる実施形態において、クライアントデバイス１４０は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で動作する携帯情報端末（ＰＤＡ）であり得る。例えば、ｉＰＡＱ ４１５５、ｉＰＡＱ ５５５５、ｉＰＡＱ １９４５、ｉＰＡＱ ２２１５およびｉＰＡＱ ４２５５（いずれもカリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎ製）、ＶｉｅｗＳｏｎｉｃ Ｖ３６（カリフォルニア州ＷａｌｎｕｔのＶｉｅｗＳｏｎｉｃ製）、あるいは、Ｔｏｓｈｉｂａ ＰｏｃｋｅｔＰＣ ｅ４０５（ニューヨーク州Ｎｅｗ ＹｏｒｋのＴｏｓｈｉｂａ Ａｍｅｒｉｃａ，Ｉｎｃ．製）である。さらなる他の実施形態において、クライアントデバイスは、ＰＤＡ／携帯電話の組み合わせであり得る。例えば、Ｔｒｅｏ １８０、Ｔｒｅｏ ２７０またはＴｒｅｏ ６００（いずれもカリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．製）である。またさらなる実施形態において、クライアントデバイス１４０は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で動作する携帯電話である。例えば、ＭＰｘ２００（Ｍｏｔｏｒｏｌａ Ｃｏｒｐ．製）である。
【００３４】
図３は、図１〜図２Ｂで記載されたばかりのシステムの動作を示す。クライアントアプリケーション１４６は、自身の代理として、アプリケーションプログラム１２２、１２４、１２６、１２８を実行するようにという要求を、プロキシサーバアプリケーション１５８に送信する（ステップ３０２）。一部の実施形態において、クライアントアプリケーション１４６によって送信されるｈｔｔｐ要求には、ユーザが実行されるべきと欲するアプリケーションの名前が含まれる。他の実施形態において、要求は、ユーザが機能したいと欲するファイルを同定し得る。これらの実施形態において、要求には、ファイルタイプが含まれ、プロキシサーバアプリケーション１５８は、ファイルを処理可能な１つ以上のアプリケーションプログラムを同定する。例えば、プロキシサーバアプリケーション１５８は、使用するアプリケーションプログラムを、テーブルマッピングファイルタイプから、それらのファイルに関連する特定のアプリケーションプログラムまで参照し得る。さらなる実施形態において、クライアントアプリケーション１４６によって送信されたｈｔｔｐ要求は、このアプリケーションプログラム１２２、１２４、１２６、１２８が実行されるべき特定の公開デスクトップまたは特定のサーバ１００を、特定的に同定する。
【００３５】
プロキシサーバアプリケーション１５８は、シンクライアントアプリケーション１５２、１５４を呼び出し（ステップ３２２）、要求されたプログラムのアイデンティティを有するシンクライアントアプリケーション１５２、１５４を提供する。シンクライアントアプリケーション１５２、１５４は、業界でよく知られた方法で動作する。しかし、シンクライアントアプリケーション１５２、１５４が、シンクライアントがアプリケーション出力を書き込むメモリのブロックを脇に置く点で異なる（ステップ３４２）。言い換えれば、シンクライアントアプリケーション１５２、１５４は、業界で通常行われるようにビジュアルディスプレイにではなく、むしろ、メモリ内に維持される仮想スクリーンに、アプリケーション出力を書き込む。しかしながら、一部の実施形態において、シンクライアントアプリケーション１５２、１５４は、仮想スクリーンと従来のディスプレイスクリーンとの双方に書き込む。
【００３６】
シンクライアントアプリケーション１５２、１５４は、サーバ１１０に、アプリケーションプログラム１２２、１２４、１２６、１２８の実行を開始するようにという要求を送信する（ステップ３４４）。一部の実施形態において、シンクライアントアプリケーション１５２、１５４は、サーバファーム内の１つのサーバに要求を送信する。このサーバは、要求されたアプリケーションプログラム１２２、１２４、１２６、１２８をホストするサーバ１１０のアドレスを有するシンクライアントアプリケーション１５２、１５４に応答する。他の実施形態において、シンクライアントアプリケーション１５２、１５４は、サービスアクセスポイントに要求を送信する。このサービスアクセスポイントは、クライアントアプリケーション１４６に、適切なアプリケーションサーバ１１０と接続するために必要な情報を提供するクライアントデバイス１４０にドキュメントを返却する。これら実施形態の全てにおいて、シンクライアントアプリケーション１５２、１５４は、同定されたサーバ１１０との接続で開始する。
【００３７】
他の実施形態において、シンクライアントアプリケーション１５２、１５４は、アプリケーション要求をアプリケーションサーバ１１０に送信した（ステップ３４４）後、仮想スクリーンメモリエリアを設定する（ステップ３４２）。さらに別の実施形態において、これらのアクションは、実質的に同時に起こる。
【００３８】
サーバ１１０は、要求されたアプリケーションプログラム１２２、１２４、１２６、１２８を実行によって開始し（ステップ３８２）、シンクライアントプレゼンテーションプロトコルを用いて、第一のネットワーク１２５を介して、グラフィカルアプリケーション出力を送信する（３８４）。シンクライアントアプリケーション１５２、１５４への送信用プレゼンテーションレベルのプロトコルパケットを形成するために、アプリケーションサーバ１１０によって取られるステップの様々な実施形態は、米国特許第６，１４１，７３７号、第６，１１８，８９９号、第６，０８１，６２３号、第６，０５７，８５７号および第６，０１６，５３５号に記載されており、これら特許の内容全体は、本明細書において参考として援用される。
【００３９】
シンクライアントアプリケーション１５２、１５４は、アプリケーションサーバ１１０から受信した表示プロトコルパケットをデコードし、プレゼンテーションプロトコルパケットによって表示されたグラフィカルアプリケーション出力を、仮想スクリーンメモリに書き込む（ステップ３４６）。多くの実施形態において、仮想スクリーンメモリは、スクリーンバッファである。すなわち、仮想スクリーンメモリエリアは、グラフィカル出力のビジュアルディスプレイを形成するために必要とされるデータのビットマップ表現を格納する。
【００４０】
図３に示す実施形態において、クライアントアプリケーション１４６は、プロキシサーバアプリケーションに、グラフィカルアプリケーション出力の現在状態を表わす静的イメージに対する要求を送信する（ステップ３０４）。クライアントアプリケーションは、グラフィカルアプリケーション出力の現在状態を、毎１分、毎３０秒、毎１５秒、毎１０秒、毎５秒、毎２秒、毎秒１回、毎秒２回、毎秒５回、毎秒１０回、毎秒２０回または毎秒３０回要求し得る。他の実施形態において、プロキシサーバアプリケーション１５８は、グラフィカルアプリケーション出力の現在状態を表わす静的イメージを、クライアントアプリケーション１４６に定期的に送信する。これらの他の実施形態において、プロキシサーバアプリケーション１５８は、クライアントアプリケーション１４６に、毎分、毎３０秒、毎１５秒、毎１０秒、毎５秒、毎２秒、毎秒１回、毎秒２回、毎秒５回、毎秒１０回、毎秒２０回または毎秒３０回、更新を送信し得る。代替的に、プロキシサーバアプリケーション１５８は、仮想スクリーンメモリエリアの所定の割合が状態を変化したと、プロキシサーバアプリケーション１５８が判断したとき、あるいは、グラフィカルアプリケーション出力の現在状態に対する要求が、プロキシサーバアプリケーションによって受信されたとき、クライアントアプリケーション１４６に、更新を送信し得る。
【００４１】
図３に戻ると、プロキシサーバアプリケーション１５８は、送信された要求を受信し（ステップ３２４）、入力として、適切なシンクライアントアプリケーション１５２、１５４の仮想スクリーンメモリを使用して、静的イメージファイルを生成する（ステップ３２６）。一部の実施形態において、クライアントアプリケーション１４６は、例えば、「クッキー」内に、そのプロキシサーバアプリケーション１５８との接続状態を格納する。これら実施形態において、送信された要求（ステップ３２４）は、セッション識別子を含み得る。このセッション識別子は、プロキシサーバアプリケーション１５８が、静的イメージファイルを生成するために、仮想スクリーンメモリから選択するために使用する。さらなる実施形態において、この要求には、クライアントデバイス１４０と関連するユニークな識別子が含まれる。例えば、クライアントデバイス１４０が携帯電話である実施形態において、ユニークな識別子は、携帯電話と関連する電話番号であり得る。
【００４２】
他の実施形態において、クライアントアプリケーション１４６は、そのプロキシサーバアプリケーション１５８との間の接続状態を格納しない。これらの実施形態において、セッションは、そのセッション識別子を傍聴者に明かさないような方法で、送信された要求内で同定されなくてはならない（ステップ３２４）。例えば、セッションを同定する送信されたｈｔｔｐ要求の部分（ステップ３２４）は、クライアントアプリケーション１４６とプロキシサーバアプリケーション１５８とで共有されたプライベートキーを用いて、暗号化され得る。これら実施形態において、さらに、要求は、クライアントデバイス１４０と関連するユニークな識別子を含む。この識別子もまた、この識別子を傍聴者から保護するために、暗号化され得る。例えば、クライアントデバイス１４０が携帯電話である実施形態において、ユニークな識別子は、携帯電話と関連する電話番号であり得る。
【００４３】
プロキシサーバアプリケーション１５８によって生成された静的イメージは、多数の標準形式（ＪＰＥＧ、ＧＩＦ、ＰＩＮ、ＴＩＦＦまたはＢＭＰを含む）の任意の一つであり得る。一部の実施形態において、プロキシサーバアプリケーション１５８は、シンクライアントアプリケーション１５２、１５４によって露呈された（ｅｘｐｏｓｅｄ）Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ （ＣＯＭ） Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ （ＡＰＩ）を呼び出して、静的イメージを生成する。
【００４４】
一部の実施形態において、プロキシサーバアプリケーション１５８は、生成された静的イメージのサイズを最適化する。これらの実施形態の一つにおいて、プロキシサーバアプリケーション１５８は、ユーザの現在位置を取り囲むスクリーンエリアを選択することによって、スクリーンイメージのサイズを決定する。ユーザの現在位置は、最後のマウスクリックにおけるｘ座標およびｙ座標、または、プロキシサーバアプリケーション１５８に送信される最後のマウス位置におけるｘ座標およびｙ座標を用いて決定され得る。ユーザの最後の位置から、スクリーンがどれだけ上下左右にあるかという量が、スクリーンイメージを形成するために使用され、これは、所定の画素数に設定され得るか、あるいは、クライアントデバイス１４０に基づいて選択され得る。
【００４５】
別の実施形態において、プロキシサーバアプリケーション１５８は、許容可能なイメージロスの量を増加し得る。つまり、プロキシサーバアプリケーション１５８は、送信前のスクリーンイメージを符号化するために、ＪＰＥＧのような損失（ｌｏｓｓｙ）圧縮アルゴリズムを使用している。プロキシサーバアプリケーション１５８は、送信されるイメージタイプ、クライアントデバイス１５８と仮想スクリーンメモリとの間の相対的なサイズの差、クライアントデバイス１４０のスクリーンの絶対的サイズ、クライアントデバイス１４０のスクリーンのビット深さ、または、ネットワーク１７５を介して使用する利用可能な帯域幅に基づいて、許容可能なイメージロスの量を選択し得る。
【００４６】
さらに別の実施形態において、プロキシサーバアプリケーション１５８は、グラフィカル要素を有しないスクリーンを送信するために、静的イメージを使用しない。このような実施形態において、クライアントアプリケーション１４６は、テキストドローイングコマンド用と、グラフィカルコマンド用とに、個別セットのプログラミングインターフェースを露呈する。グラフィカル要素を有しないスクリーンにおいて、テキストドローイング呼び出しのみが、アプリケーションにスクリーンを出力させるために使われる。
【００４７】
さらに別の実施形態において、プロキシサーバアプリケーション１５８は、仮想スクリーンバッファからの読まれたアプリケーション出力をスケーリングし得る。これは、そのスクリーンまたはそのスクリーンの大部分が、クライアントデバイス１４０のスクリーン上で見ることができるようにするためである。代替的に、スケーリングは、ＣＯＭインターフェースによって提供され得る。
【００４８】
プロキシサーバアプリケーション１５８は、クライアントアプリケーション１４６に、生成された静的イメージファイルを送信する（ステップ３２８）。一部の実施形態において、単一のセッション識別子は、多数のクライアントデバイス１４０と共有され得る。これによって、１つ以上のクライアントデバイス１４０が、別のクライアントデバイス１４０を影にすることを許す。すなわち、「影にする」クライアントデバイス１４０によって表示された出力は、「影にされた」クライアントデバイス１４０の出力と同じになる。一実施形態において、静的イメージファイルは、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ｈｔｔｐ）またはＳｅｃｕｒｅ ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ｈｔｔｐｓ）を用いて、クライアントアプリケーション１４６に送信される。クライアントアプリケーション１４６に静的イメージファイルを送信し、クライアントアプリケーション１４６からクライアント入力を受信するために使用されたプロトコルは、図４と関連付けて、以下に、より詳細に記載される。クライアントアプリケーション１４６は、受信した静的イメージファイルを表示する（ステップ３０８）。
【００４９】
ここで、図４を参照すると、ユーザの入力とアプリケーションの実行出力とを交換するために、クライアントアプリケーション１４６とプロキシサーバアプリケーション１５８とによって使用されるプロトコルの一実施形態が、図式的に示される。図４に示す実施形態においては、「イメージを得よ」４１０、「ストリングを送れ」４２０、「キーストロークを送れ」４３０、および「マウスイベントを送れ」４４０の４つのプロトコルコマンドが示されている。
【００５０】
図４に示すように、クライアントアプリケーション１４６は、プロキシサーバアプリケーション１５８に、要求が向けられたサーバと、クライアントアプリケーション１４６によって要求された静的イメージに関するパラメータとを同定するｈｔｔｐ要求４１２を送信する。図４に示す実施形態において、クライアントアプリケーション１４６によって送信されたｈｔｔｐ要求に含まれるパラメータには、開始ｘ座標、開始ｙ座標、終了ｘ座標、終了ｙ座標、および、好ましい静的イメージタイプが含まれる。プロキシサーバアプリケーション１５８は、ｈｔｔｐパケット４１４に応答し、要求された静的イメージファイルを送信する。
【００５１】
図４に示すプロトコル実施形態には、また、「ストリングを送れ」４２０、「キーストロークを送れ」４３０、および「マウスイベントを送れ」４４０の３つの入力コマンドも含まれる。これらコマンドのそれぞれに対し、クライアントアプリケーション１４６は、プロキシサーバアプリケーション１５８に、ユーザ入力が向けられたサーバと、入力とを同定するｈｔｔｐパケットを送信する。「ストリングを送れ」コマンド４２２の場合、ユーザ入力は、一連の英数字である。「キーストロークを送れ」コマンド４３２の場合、ユーザ入力は、キーストロークである。「マウスイベントを送れ」コマンド４４２の場合、ユーザ入力は、マウスイベントのｘ座標と、マウスイベントのｙ座標と、そのマウスイベントに「クリック」が含まれるか否かである。一部の実施形態において、「マウスイベントを送れ」には、また、どのマウスボタンがクリックされたかの表示も含まれる。これらの場合それぞれにおいて、プロキシサーバアプリケーション１５８は、クライアントアプリケーション１４６に、「ＯＫ」メッセージ４２４、４３４、４４４で応答する。
【００５２】
ユーザ入力４２２、４３２、４４２を受信すると、プロキシサーバアプリケーション１５８は、シンクライアントアプリケーション１５２、１５４にユーザ入力を転送する。シンクライアントアプリケーション１５２、１５４は、受信したユーザ入力を、アプリケーションサーバ１１０に転送する。アプリケーションサーバ１１０は、ユーザ入力を受信し、それをアプリケーションプログラム１２２、１２４、１２６、１２８に提供する。
【００５３】
本発明は、製品の１つ以上の品目に具体化された１つ以上のコンピュータ読み出し可能プログラムとして、提供され得る。製品の品目は、フロッピディスク、ハードディスク、コンパクトディスク、デジタル汎用ディスク、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭまたは磁気テープであり得る。一般に、コンピュータ読み出し可能プログラムは、任意のプログラミング言語でインプリメントされ得る。使用可能な言語の例の一部は、Ｃ、Ｃ＋＋、Ｃ＃またはＪＡＶＡ（登録商標）であり得る。ソフトウェアプログラムは、オブジェクトコードの製品の１つ以上の品目上または品目内に格納され得る。
【００５４】
本発明は、特定の好ましい実施形態を参照しながら、図示および記載されてきたが、以下の請求項で規定される本発明の精神と範囲から逸脱することなく、形式および詳細において、様々な変更がなされ得ることは、当業者によって理解されるべきである。
【図面の簡単な説明】
【００５５】
【図１】図１は、制約あるシステムリソースを有するデバイスにアプリケーション出力を提供するシステムの一実施形態のブロック図である。
【図２Ａ】図２Ａは、本発明と関連して、有益なコンピュータの実施形態を示すブロック図である。
【図２Ｂ】図２Ｂは、本発明と関連して、有益なコンピュータの実施形態を示すブロック図である。
【図３】図３は、制約あるシステムリソースを有するデバイスにアプリケーション出力を提供するシステムの動作の一実施形態を示す流れ図である。
【図４】図４は、制約あるシステムリソースを有するデバイスにアプリケーション出力を通信するために使用されるプロトコルの一実施形態の図式表現である。
【技術分野】
【０００１】
本発明は、一般的に、サーバデバイス上で実行するアプリケーションプログラムの出力をクライアントデバイスに表示することに関する。より特定的には、制約あるシステムリソースを有するデバイス上でアプリケーションプログラムの出力を表示する技術および装置に関する。
【背景技術】
【０００２】
ネットワーク化されたリソースにリモートアクセスを提供する技術は、様々なクライアント／サーバソフトウェアの組み合わせを含む。こうした組み合わせの一つは、「シンクライアント（ｔｈｉｎ−ｃｌｉｅｎｔ）」または「分散型アプリケーション処理」システムと、称されることが多い。これらシステムにおいて、アプリケーションプログラムは、サーバコンピュータデバイスによって実行される。このデバイスは、「シンクライアント」または「シンクライアントアプリケーション」と通常称される１つ以上のクライアントコンピュータデバイスを代表して、「アプリケーションサーバ」と、通常称される。シンクライアントでユーザから受信されたアプリケーションへの入力、および、アプリケーションサーバで実行するアプリケーションによって生成された出力のみが、シンクライアントとアプリケーションサーバとの間で送信される。シンクライアントのコンピュータアーキテクチャは、アプリケーションおよび他のシステムリソースにリモート接続を提供するために、よく使われているインプリメンテーションである。このようなシステムの例には、Ｉｎｔｅｌｌｉｇｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ （ＩＣＡ）クライアントと組み合わせるＣｉｔｒｉｘ ＭｅｔａＦｒａｍｅ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｓｅｒｖｅｒソフトウェア（フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．から市販）、Ｘ Ｗｉｎｄｏｗｓ（登録商標）クライアントと組み合わせるＸサーバ（Ｘ Ｃｏｎｓｏｒｔｉｕｍから市販）、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）クライアントと組み合わせるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＮＴ Ｓｅｒｖｅｒ ４．０ Ｔｅｒｍｉｎａｌ Ｓｅｒｖｅｒ Ｅｄｉｔｉｏｎ（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販）が含まれる。
【０００３】
シンクライアントコンピュータアーキテクチャ内のクライアントは、アプリケーションプログラムを実行しないため、かつ、ユーザ入力をアプリケーションサーバに送信するのみで、そのアプリケーションサーバ上で実行されるアプリケーションの出力を表示するのみであるため、クライアントデバイスは、ユーザが気付くような性能低下をともなわずに、限られたメモリ量、より遅い通信サブシステム、限られたシステムリソースを提供し得る。パソコン、ワークステーション、あるいは、他のコンピュータデバイスは、典型的には、豊富なシステムリソースを提供する。これは、シンクライアントのアプリケーションを実行し、アプリケーションサーバと通信するためである。
【０００４】
しかしながら、リモート接続を必要とする多くのユーザは、携帯電話および携帯情報端末のようなシンクライアントとして機能するのに十分なメモリ、ネットワークリソース、あるいは、適切なオペレーティングシステム環境を提供しないコンピュータデバイスを、シンクライアントとして使用している。例えば、現行の携帯電話の多くは、１メガバイト未満のランダムアクセスメモリーを備えるが、これは、シンクライアントのアプリケーション実行には一般に十分でない。さらに、内蔵システムにとって、アプリケーション出力用のアプリケーションサーバにアクセスすることは、しばしば、有用である。典型的には、これらシステムも、また、メモリのようなリソースに制約がある。
【０００５】
メモリ制限があるように、システムリソースに制約のあるクライアントデバイスが、アプリケーションサーバ上で実行するアプリケーションプログラムと、相互作用するシステムを所有することは、有益なことである。
【発明の開示】
【課題を解決するための手段】
【０００６】
（発明の概要）
本発明は、ローエンド（ｌｏｗ−ｅｎｄ）クライアントデバイス（例えば、携帯電話、携帯情報端末、内蔵システム）が、アプリケーションサーバ上で実行するアプリケーションプログラムと相互作用して、アプリケーションが、様々な位置からのリモートアクセスを可能とする。
【０００７】
一局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示するシステムに関する。本システムは、アプリケーションプログラムを実行するアプリケーションサーバを含む。プロキシサーバは、アプリケーションサーバから、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信する。ユーザデバイスは、プロキシサーバから静的イメージデータを受信するクライアントアプリケーションを実行する。静的イメージデータは、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わす。
【０００８】
別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する方法に関する。アプリケーションサーバは、グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを実行し、生成されたグラフィカルユーザインターフェースデータのスクリーンを、プロキシサーバに送信する。プロキシサーバは、生成されたグラフィカルユーザインターフェースデータのスクリーンの少なくとも一部を表わす静的イメージデータを、ユーザデバイスに送信する。ユーザデバイスは、送信された静的イメージデータを表示する。
【０００９】
さらに別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する装置に関する。本装置は、アプリケーションサーバから、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを、第一のプロトコル形式で受信する第一のプロトコルハンドラを含む。本装置は、また、第一のプロトコルハンドラによって受信されたグラフィカルディスプレイ出力のスクリーンの少なくとも一部を表わす静的イメージデータを、表示用クライアントアプリケーションに、第二のプロトコル形式で送信する第二のプロトコルハンドラを含む。
【００１０】
また別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成されたグラフィカルディスプレイ出力を、ユーザデバイスに表示する方法に関する。静的イメージデータは、アプリケーションサーバから、第一のプロトコル形式を介して受信され、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わす。静的イメージデータは、ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して送信される。この静的イメージデータは、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンの少なくとも一部を表わす。
【００１１】
さらにまた別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示するシステムに関する。本システムは、アプリケーションプログラムを実行するアプリケーションサーバを含む。本システムは、また、アプリケーションサーバから、プレゼンテーションレベルのプロトコルを介して、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するプロキシサーバも含む。本システムは、さらに、クライアントアプリケーションを実行するユーザデバイスを含み、このクライアントアプリケーションは、プロキシサーバから、アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わす静的イメージデータを、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して受信する。
【００１２】
別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示する方法に関する。アプリケーションサーバは、グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを実行する。アプリケーションサーバは、生成されたグラフィカルユーザインターフェースデータのスクリーンを、プレゼンテーションレベルのプロトコルを介して、プロキシサーバに送信する。プロキシサーバは、生成されたグラフィカルユーザインターフェースデータのスクリーンの少なくとも一部を表わす静的イメージを、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して、ユーザデバイスに送信する。ユーザデバイスによって、この送信された静的イメージデータを表示する。
【００１３】
さらなる局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラムを具体化した製品の品目に関する。この製品の品目には、サーバ上で実行するアプリケーションによって生成されたグラフィカルユーザデータインターフェースのスクリーンを、プロキシサーバに送信するコンピュータ読み出し可能なプログラム手段と、生成されたグラフィカルユーザデータインターフェースのスクリーンの少なくとも一部を表わす静的イメージデータを、プロキシサーバを介して、ユーザデバイスに通信するコンピュータ読み出し可能なプログラム手段と、送信された静的イメージデータを、ユーザデバイスによって、表示するコンピュータ読み出し可能なプログラム手段とが、含まれる。
【００１４】
さらに別の局面において、本発明は、サーバ上で実行するアプリケーションプログラムによって生成されるグラフィカルディスプレイ出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラムを具体化した製品の品目に関する。この製品の品目には、アプリケーションサーバから、第一のプロトコルを介して、アプリケーションサーバ上で実行するアプリケーションによって形成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するコンピュータ読み出し可能なプログラム手段と、第二のプロトコルを介して、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンの少なくとも一部を表わす静的イメージデータを、ディスプレイ用クライアントアプリケーションに通信するコンピュータ読み出し可能なプログラム手段とが、含まれる。
【００１５】
本発明のこれらおよび他の局面が、以下の詳細な記述と添付図面から容易に明らかになる。添付図面は、本発明を説明することを意図し、本発明を限定することを意図していない。
【発明を実施するための最良の形態】
【００１６】
（詳細な説明）
図１を参照すると、システムリソース制約を有するクライアントデバイスにアプリケーション出力を提供するシステム１００は、アプリケーションサーバ１１０と、プロキシサーバ１５０と、クライアント１４０とを含む。図１に示す実施形態において、１つのみのアプリケーションサーバ１１０と、プロキシサーバ１５０と、クライアント１４０としか描かれていないが、これらコンポーネントの任意または各々は複数個を備え得る。例えば、一実施形態において、システム１００は、複数の論理グループ化されたアプリケーションサーバ１１０を備え、そのそれぞれは、クライアント１４０を代表して、アプリケーションを実行するために利用可能である。これらの実施形態において、サーバの論理グループは、「サーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）」と称され得る。他の実施形態において、複数のプロキシサーバ１５０が備えられ得る。これら実施形態の一部において、プロキシサーバは、地理的に分散され得る。
【００１７】
アプリケーションサーバ１１０は、クライアント１４０を代表して、１つ以上のプログラム１２２、１２４、１２６、１２８を実行する。アプリケーションプログラムは、データを処理して、出力を提供することと、オペレーティングシステムを用いて、システムリソースにアクセスすることとを行う任意のプログラムである。例示的なアプリケーションプログラムには、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤ（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）のような言語処理アプリケーション、ＭＩＣＲＯＳＯＦＴ ＥＸＣＥＬ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）のような表計算プログラム、ＭＩＣＲＯＳＯＦＴ ＯＵＴＬＯＯＫ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）およびＧＲＯＵＰＷＩＳＥ（ユタ州ＰｒｏｖｏのＮｏｖｅｌｌ Ｃｏｒｐ．製）のような電子メールプログラム、ＳＴＡＲ ＯＦＦＩＣＥ（カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ製）のような生産性一式（ｐｒｏｄｕｃｔｉｖｉｔｙ ｓｕｉｔｅｓ）を含む。
【００１８】
アプリケーションサーバ１１０は、第一のネットワーク１２５を介して、プロキシサーバ１５０と通信する。第一のネットワーク１２５は、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、あるいは、インターネットのような広域ネットワーク（ＷＡＮ）であり得る。アプリケーションサーバ１１０およびプロキシサーバ１５０は、標準の電話回線、ＬＡＮまたはＷＡＮリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、広帯域接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）および無線接続を含む様々な接続を介して、第一のネットワーク１２５に接続し得る。アプリケーションサーバ１１０とプロキシサーバ１５０との間の接続は、様々なデータリンク層通信プロトコル（例えば、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、ＮｅｔＢＥＵＩ、ＳＭＢ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＡＲＣＮＥＴ、Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）、ＲＳ２３２、ＩＥＥＥ ８０２．１１、ＩＥＥＥ ８０２．１１ａ、ＩＥＥＥ ８０２．１１ｂ、ＩＥＥＥ ８０２．１１ｇおよび直接非同期接続）を使用し得る。
【００１９】
プロキシサーバ１５０は、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌクライアント（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ製）、または、ＩＣＡクライアント（フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．製）のような１つ以上のシンクライアントアプリケーション１５２、１５４を実行する。アプリケーションサーバ１１０は、アプリケーションプログラム１２２、１２４、１２６、１２８の出力を、プロキシサーバ１５０上で実行するシンクライアントアプリケーション１５２、１５４に通信し、アプリケーションプログラム１２２、１２４、１２６、１２８に向けられたユーザ入力を、シンクライアントアプリケーション１５２、１５４から受信する。アプリケーションサーバ１１０は、Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）プロトコル（フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．から市販）、または、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販）のようなプレゼンテーション層プロトコルを使用して、ネットワーク１２５を介して、シンクライアントアプリケーション１５２、１５４と、通信する。図１に示す実施形態において、２つのシンクライアントアプリケーションのみしか描かれていないが、プロキシサーバ１５０は、任意の数のシンクライアントアプリケーション１５２、１５４をホストし得る。
【００２０】
また、プロキシサーバ１５０は、プロキシサーバアプリケーション１５８を実行する。プロキシサーバアプリケーション１５８は、アプリケーションプログラム、サブシステムまたはサービスであり得る。プロキシサーバアプリケーション１５８は、プロキシサーバ１５０によってホストされるシンクライアントアプリケーション１５２、１５４を管理する。プロキシサーバアプリケーションは、また、シンクライアントアプリケーション１５２、１５４によって受信されたアプリケーション出力を、クライアントデバイス１４０に送信し、クライアントデバイス１４０から受信されたユーザ入力を、プロキシサーバ１５０上で実行する適切なシンクライアントアプリケーション１５２、１５４に送信する。
【００２１】
プロキシサーバ１５０上で実行するプロキシサーバアプリケーション１５８は、第二のネットワーク１７５を介して、クライアント１４０と通信する。クライアント１４０が内蔵システムである実施形態において、クライアント１４０とプロキシサーバ１５０とは、標準の電話回線、ＬＡＮまたはＷＡＮリンク（例えば、Ｔ１、Ｔ３、５６ｋｂ、Ｘ．２５）、広帯域接続（ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）および無線接続を含む様々な接続を介して、第二のネットワーク１７５と接続し得る。クライアント１４０とプロキシサーバ１５０との間の接続は、様々なデータリンク層通信プロトコル（例えば、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＰＸ、ＮｅｔＢＩＯＳ、ＮｅｔＢＥＵＩ、ＳＭＢ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＡＲＣＮＥＴ、Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）、ＲＳ２３２、ＩＥＥＥ ８０２．１１、ＩＥＥＥ ８０２．１１ａ、ＩＥＥＥ ８０２．１１ｂ、ＩＥＥＥ ８０２．１１ｇおよび直接非同期接続）を使用し得る。
【００２２】
他の実施形態において、クライアントデバイス１４０は、携帯電話または携帯情報端末のような移動体デバイスである。これらの実施形態において、クライアント１４０とプロキシサーバアプリケーション１５８とは、Ｗ−ＣＤＭＡのようなＧＳＭまたはＣＤＭＡファミリからなる多数の周知のプロトコルの任意の一つを用いて、第二のネットワークと接続する。これらプロトコルは、商業無線通信サービスおよびＷ−ＣＤＭＡをサポートし、特に、ＮＴＴ ＤｏＣｏＭｏによって提供されるｉ−ＭｏｄｅおよびｍＭｏｄｅサービスをサポートする基底プロトコルである。
【００２３】
クライアントデバイス１４０は、クライアントアプリケーション１４６を実行する。クライアントアプリケーションは、ｈｔｔｐまたはｈｔｔｐｓ要求を、プロキシサーバアプリケーション１５８へ送信し、プロキシサーバアプリケーション１５８から受信する。クライアントアプリケーション１４８は、実行するアプリケーションプログラム１２２、１２４、１２６、１２８に向けられたユーザ入力を、プロキシサーバアプリケーション１５８に、第二のネットワーク１７５を介して送信する。それは、また、アプリケーションサーバ１１０上で実行するアプリケーションプログラム１２２、１２４、１２６、１２８の出力に対応するクライアントデバイスのスクリーン上に、グラフィカル出力を与える役割も担っている。
【００２４】
多くの実施形態において、アプリケーションサーバ１１０およびプロキシサーバ１５０は、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎまたはテキサス州Ｒｏｕｎｄ ＲｏｃｋのＤｅｌｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造されたもののようなパーソナルコンピュータまたはコンピュータサーバとして、提供される。クライアントデバイス１４０が内蔵システムである実施形態において、クライアントデバイス１４０もまた、パーソナルコンピュータとしても、また提供され得る。図２Ａおよび図２Ｂは、これらの実施形態において、アプリケーションサーバ１１０、、プロキシサーバ１５０、または、クライアントデバイスとして有用な典型的なコンピュータ２００のブロック図を示す。図２Ａおよび図２Ｂに示すように、各コンピュータは、中央演算処理装置２０２、および主記憶装置２０４を含む。各コンピュータ２００は、また、１つ以上の入出力デバイス２３０ａ〜２３０ｎ（一般に、参照番号２３０で示す）、および、中央演算処理装置２０２と通信するキャッシュメモリ２４０のような他のオプション要素も含み得る。
【００２５】
中央演算処理装置２０２は、主記憶装置２０４から取り出された命令に応答し、処理する任意の論理回路網である。多数の実施形態において、中央演算処理装置は、マイクロプロセッサユニットによって提供される。例えば、８０８８、８０２８６、８０３８６、８０４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標） ＩＩ、ＣｅｌｅｒｏｎまたはＸｅｏｎプロセッサ（いずれもカリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ製）、６８０００、６８０１０、６８０２０、６８０３０、６８０４０、ＰｏｗｅｒＰＣ６０１、ＰｏｗｅｒＰＣ６０４、ＰｏｗｅｒＰＣ６０４ｅ、ＭＰＣ６０３ｅ、ＭＰＣ６０３ｅｉ、ＭＰＣ６０３ｅｖ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｐ、ＭＰＣ７４０、ＭＰＣ７４５、ＭＰＣ７５０、ＭＰＣ７５５、ＭＰＣ７４００、ＭＰＣ７４１０、ＭＰＣ７４４１、ＭＰＣ７４４５、ＭＰＣ７４４７、ＭＰＣ７４５０、ＭＰＣ７４５１、ＭＰＣ７４５５、ＭＰＣ７４５７プロセッサ（いずれもイリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎ製）、Ｃｒｕｓｏｅ ＴＭ５８００、Ｃｒｕｓｏｅ ＴＭ５６００、Ｃｒｕｓｏｅ ＴＭ５５００、Ｃｒｕｓｏｅ ＴＭ５４００、Ｅｆｆｉｃｅｏｎ ＴＭ８６００、Ｅｆｆｉｃｅｏｎ ＴＭ８３００またはＥｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ（カリフォルニア州Ｓａｎｔａ ＣｌａｒａのＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎ製）、ＲＳ／６０００プロセッサ、ＲＳ６４、ＲＳ６４ ＩＩ、Ｐ２ＳＣ、ＰＯＷＥＲ３、ＲＳ６４ ＩＩＩ、ＰＯＷＥＲ３−１１、ＲＳ６４ ＩＶ、ＰＯＷＥＲ４、ＰＯＷＥＲ４＋、ＰＯＷＥＲ５またはＰＯＷＥＲ６プロセッサ（いずれもニューヨーク州Ｗｈｉｔｅ ＰｌａｉｎｓのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ製）、あるいは、ＡＭＤ Ｏｐｔｅｒｏｎ、ＡＭＤ Ａｔｈａｌｏｎ ６４ＦＸ、ＡＭＤ ＡｔｈａｌｏｎまたはＡＭＤ Ｄｕｒｏｎプロセッサ（カリフォルニア州ＳｕｎｎｙｖａｌｅのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ製）である。
【００２６】
主記憶装置２０４は、データを格納可能で、マイクロプロセッサ２０２によって直接アクセスされる任意のストレージロケーションが可能な１つ以上のメモリチップであり得る。例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ）、Ｂｕｒｓｔ ＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ ＳＲＡＭ（ＢＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、Ｆａｓｔ Ｐａｇｅ Ｍｏｄｅ ＤＲＡＭ（ＦＰＭ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＲＡＭ（ＥＤＯ ＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＥＤＯ ＤＲＡＭ）、Ｂｕｒｓｔ Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＢＥＤＯ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、シンクロナスＤＲＡＭ （ＳＤＲＡＭ）、ＪＥＤＥＣ ＳＲＡＭ、ＰＣ１００ ＳＤＲＡＭ、Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ）、ＳｙｎｃＬｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＤＲＡＭ（ＤＲＤＲＡＭ）、あるいは、強誘電体ＲＡＭ（ＦＲＡＭ）である。
【００２７】
図２Ａに示す実施形態において、プロセッサ２０２は、システムバス２２０（詳細は後述）を介して、主記憶装置２０４と通信する。図２Ｂは、コンピュータシステム２００の実施形態を示す。ここでは、プロセッサは、メモリポートを介して、主記憶装置２０４と直接通信する。例えば、図２Ｂにおいて、主記憶装置２０４は、ＤＲＤＲＡＭであり得る。
【００２８】
図２Ａおよび図２Ｂは、主記憶装置２０２が、二次バス（ときどき、「バックサイド」バスと称される）を介して、キャッシュメモリ２４０と直接通信する実施形態を示す。他の実施形態において、主記憶装置２０２は、システムバス２２０を用いて、キャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、典型的には、主記憶装置２０４より応答速度が速く、典型的には、ＳＲＡＭ、ＢＳＲＡＭまたはＥＤＲＡＭによって提供される。
【００２９】
図２Ａに示す実施形態において、プロセッサ２０２は、様々な入出力デバイス２３０と、ローカルシステムバス２２０を介して、通信する。様々なバスは、中央演算処理装置２０２を入出力デバイス２３０に接続するために使用され得る。これらバスには、ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−Ｅｘｐｒｅｓｓバス、またはＮｕＢｕｓを含む。入出力デバイスがビデオディスプレイである実施形態において、プロセッサ２０２は、このディスプレイと通信するために、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図２Ｂは、コンピュータシステム２００の実施形態を示す。ここでは、主記憶装置２０２は、入出力デバイス２３０ｂと、ＨｙｐｅｒＴｒａｎｓｐｏｒｔ、Ｒａｐｉｄ Ｉ／ＯまたはＩｎｆｉｎｉＢａｎｄを介して、直接通信している。図２Ｂは、また、ローカルバスと直接通信の混合された実施形態を示す。すなわち、プロセッサ２０２は、ローカル相互接続バスを使用して、入出力デバイス２３０ａと通信し、その一方、入出力デバイス２３０ｂと直接通信する。
【００３０】
幅広い多様な入出力デバイス２３０が、コンピュータシステム２００内で使用され得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイク、および、ドローイングタブレットを含む。出力デバイスは、ビデオディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および、昇華型プリンタを含む。入出力デバイスには、コンピュータシステム２００用の大容量ストレージを提供し得る。例えば、ハードディスクドライブ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクのようなフロッピディスクを受け入れるフロッピディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、様々な形式のテープドライブ、および、ＵＳＢ Ｆｌａｓｈ ＤｒｉｖｅラインのようなＵＳＢストレージデバイス（カリフォルニア州Ｌｏｓ ＡｌａｍｉｔｏｓのＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ，Ｉｎｃ．製）である。
【００３１】
さらなる実施形態において、入出力デバイス２３０は、システムバス２２０と外部通信バスとの間のブリッジになり得る。外部通信バスは、例えば、ＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｂｕｓ、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標）バス、ＡｐｐｌｅＴａｌｋ ｂｕｓバス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ バス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、または、Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ 小型コンピュータシステムインターフェースバスである。
【００３２】
図２Ａおよび図２Ｂに示すような汎用デスクトップコンピュータは、典型的には、オペレーティングシステムの制御下で動作し、このオペレーティングシステムが、タスクのスケジューリングおよびシステムリソースへのアクセスを管理する。典型的なオペレーティングシステムには、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．製）、ＭａｃＯＳ（カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ製）、ＯＳ／２（ニューヨーク州ＡｒｍｏｎｋのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ製）、および、Ｌｉｎｕｘ（ユタ州Ｓａｌｔ Ｌａｋｅ ＣｉｔｙのＣａｌｄｅｒａ Ｃｏｒｐ．より無料で頒布されているオペレーティングシステム）がある。
【００３３】
クライアントデバイス１４０が、移動体デバイスである実施形態において、クライアントデバイスは、ＪＡＶＡ（登録商標）対応の携帯電話であり得る。例えば、ｉ５０ｓｘ、ｉ５５ｓｒ、ｉ５８ｓｒ、ｉ８５ｓ、ｉ８８ｓ、ｉ９０ｃ、ｉ９５ｃ１またはｉｍ１１０００（いずれもイリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐ．製）、６０３５または７１３５（日本国京都府の京セラ製）、あるいは、ｉ３００またはｉ３３０（韓国ソウルのＳａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．製）である。クライアントデバイス１４０が移動体である他の実施形態において、クライアントデバイスは、ＰａｌｍＯＳのオペレーティングシステムの制御下で動作する携帯情報端末（ＰＤＡ）であり得る。例えば、Ｔｕｎｇｓｔｅｎ Ｗ、ＶＩＩ、ＶＩＩｘ、ｉ７０５（いずれもカリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．製）である。さらなる実施形態において、クライアントデバイス１４０は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で動作する携帯情報端末（ＰＤＡ）であり得る。例えば、ｉＰＡＱ ４１５５、ｉＰＡＱ ５５５５、ｉＰＡＱ １９４５、ｉＰＡＱ ２２１５およびｉＰＡＱ ４２５５（いずれもカリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎ製）、ＶｉｅｗＳｏｎｉｃ Ｖ３６（カリフォルニア州ＷａｌｎｕｔのＶｉｅｗＳｏｎｉｃ製）、あるいは、Ｔｏｓｈｉｂａ ＰｏｃｋｅｔＰＣ ｅ４０５（ニューヨーク州Ｎｅｗ ＹｏｒｋのＴｏｓｈｉｂａ Ａｍｅｒｉｃａ，Ｉｎｃ．製）である。さらなる他の実施形態において、クライアントデバイスは、ＰＤＡ／携帯電話の組み合わせであり得る。例えば、Ｔｒｅｏ １８０、Ｔｒｅｏ ２７０またはＴｒｅｏ ６００（いずれもカリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．製）である。またさらなる実施形態において、クライアントデバイス１４０は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で動作する携帯電話である。例えば、ＭＰｘ２００（Ｍｏｔｏｒｏｌａ Ｃｏｒｐ．製）である。
【００３４】
図３は、図１〜図２Ｂで記載されたばかりのシステムの動作を示す。クライアントアプリケーション１４６は、自身の代理として、アプリケーションプログラム１２２、１２４、１２６、１２８を実行するようにという要求を、プロキシサーバアプリケーション１５８に送信する（ステップ３０２）。一部の実施形態において、クライアントアプリケーション１４６によって送信されるｈｔｔｐ要求には、ユーザが実行されるべきと欲するアプリケーションの名前が含まれる。他の実施形態において、要求は、ユーザが機能したいと欲するファイルを同定し得る。これらの実施形態において、要求には、ファイルタイプが含まれ、プロキシサーバアプリケーション１５８は、ファイルを処理可能な１つ以上のアプリケーションプログラムを同定する。例えば、プロキシサーバアプリケーション１５８は、使用するアプリケーションプログラムを、テーブルマッピングファイルタイプから、それらのファイルに関連する特定のアプリケーションプログラムまで参照し得る。さらなる実施形態において、クライアントアプリケーション１４６によって送信されたｈｔｔｐ要求は、このアプリケーションプログラム１２２、１２４、１２６、１２８が実行されるべき特定の公開デスクトップまたは特定のサーバ１００を、特定的に同定する。
【００３５】
プロキシサーバアプリケーション１５８は、シンクライアントアプリケーション１５２、１５４を呼び出し（ステップ３２２）、要求されたプログラムのアイデンティティを有するシンクライアントアプリケーション１５２、１５４を提供する。シンクライアントアプリケーション１５２、１５４は、業界でよく知られた方法で動作する。しかし、シンクライアントアプリケーション１５２、１５４が、シンクライアントがアプリケーション出力を書き込むメモリのブロックを脇に置く点で異なる（ステップ３４２）。言い換えれば、シンクライアントアプリケーション１５２、１５４は、業界で通常行われるようにビジュアルディスプレイにではなく、むしろ、メモリ内に維持される仮想スクリーンに、アプリケーション出力を書き込む。しかしながら、一部の実施形態において、シンクライアントアプリケーション１５２、１５４は、仮想スクリーンと従来のディスプレイスクリーンとの双方に書き込む。
【００３６】
シンクライアントアプリケーション１５２、１５４は、サーバ１１０に、アプリケーションプログラム１２２、１２４、１２６、１２８の実行を開始するようにという要求を送信する（ステップ３４４）。一部の実施形態において、シンクライアントアプリケーション１５２、１５４は、サーバファーム内の１つのサーバに要求を送信する。このサーバは、要求されたアプリケーションプログラム１２２、１２４、１２６、１２８をホストするサーバ１１０のアドレスを有するシンクライアントアプリケーション１５２、１５４に応答する。他の実施形態において、シンクライアントアプリケーション１５２、１５４は、サービスアクセスポイントに要求を送信する。このサービスアクセスポイントは、クライアントアプリケーション１４６に、適切なアプリケーションサーバ１１０と接続するために必要な情報を提供するクライアントデバイス１４０にドキュメントを返却する。これら実施形態の全てにおいて、シンクライアントアプリケーション１５２、１５４は、同定されたサーバ１１０との接続で開始する。
【００３７】
他の実施形態において、シンクライアントアプリケーション１５２、１５４は、アプリケーション要求をアプリケーションサーバ１１０に送信した（ステップ３４４）後、仮想スクリーンメモリエリアを設定する（ステップ３４２）。さらに別の実施形態において、これらのアクションは、実質的に同時に起こる。
【００３８】
サーバ１１０は、要求されたアプリケーションプログラム１２２、１２４、１２６、１２８を実行によって開始し（ステップ３８２）、シンクライアントプレゼンテーションプロトコルを用いて、第一のネットワーク１２５を介して、グラフィカルアプリケーション出力を送信する（３８４）。シンクライアントアプリケーション１５２、１５４への送信用プレゼンテーションレベルのプロトコルパケットを形成するために、アプリケーションサーバ１１０によって取られるステップの様々な実施形態は、米国特許第６，１４１，７３７号、第６，１１８，８９９号、第６，０８１，６２３号、第６，０５７，８５７号および第６，０１６，５３５号に記載されており、これら特許の内容全体は、本明細書において参考として援用される。
【００３９】
シンクライアントアプリケーション１５２、１５４は、アプリケーションサーバ１１０から受信した表示プロトコルパケットをデコードし、プレゼンテーションプロトコルパケットによって表示されたグラフィカルアプリケーション出力を、仮想スクリーンメモリに書き込む（ステップ３４６）。多くの実施形態において、仮想スクリーンメモリは、スクリーンバッファである。すなわち、仮想スクリーンメモリエリアは、グラフィカル出力のビジュアルディスプレイを形成するために必要とされるデータのビットマップ表現を格納する。
【００４０】
図３に示す実施形態において、クライアントアプリケーション１４６は、プロキシサーバアプリケーションに、グラフィカルアプリケーション出力の現在状態を表わす静的イメージに対する要求を送信する（ステップ３０４）。クライアントアプリケーションは、グラフィカルアプリケーション出力の現在状態を、毎１分、毎３０秒、毎１５秒、毎１０秒、毎５秒、毎２秒、毎秒１回、毎秒２回、毎秒５回、毎秒１０回、毎秒２０回または毎秒３０回要求し得る。他の実施形態において、プロキシサーバアプリケーション１５８は、グラフィカルアプリケーション出力の現在状態を表わす静的イメージを、クライアントアプリケーション１４６に定期的に送信する。これらの他の実施形態において、プロキシサーバアプリケーション１５８は、クライアントアプリケーション１４６に、毎分、毎３０秒、毎１５秒、毎１０秒、毎５秒、毎２秒、毎秒１回、毎秒２回、毎秒５回、毎秒１０回、毎秒２０回または毎秒３０回、更新を送信し得る。代替的に、プロキシサーバアプリケーション１５８は、仮想スクリーンメモリエリアの所定の割合が状態を変化したと、プロキシサーバアプリケーション１５８が判断したとき、あるいは、グラフィカルアプリケーション出力の現在状態に対する要求が、プロキシサーバアプリケーションによって受信されたとき、クライアントアプリケーション１４６に、更新を送信し得る。
【００４１】
図３に戻ると、プロキシサーバアプリケーション１５８は、送信された要求を受信し（ステップ３２４）、入力として、適切なシンクライアントアプリケーション１５２、１５４の仮想スクリーンメモリを使用して、静的イメージファイルを生成する（ステップ３２６）。一部の実施形態において、クライアントアプリケーション１４６は、例えば、「クッキー」内に、そのプロキシサーバアプリケーション１５８との接続状態を格納する。これら実施形態において、送信された要求（ステップ３２４）は、セッション識別子を含み得る。このセッション識別子は、プロキシサーバアプリケーション１５８が、静的イメージファイルを生成するために、仮想スクリーンメモリから選択するために使用する。さらなる実施形態において、この要求には、クライアントデバイス１４０と関連するユニークな識別子が含まれる。例えば、クライアントデバイス１４０が携帯電話である実施形態において、ユニークな識別子は、携帯電話と関連する電話番号であり得る。
【００４２】
他の実施形態において、クライアントアプリケーション１４６は、そのプロキシサーバアプリケーション１５８との間の接続状態を格納しない。これらの実施形態において、セッションは、そのセッション識別子を傍聴者に明かさないような方法で、送信された要求内で同定されなくてはならない（ステップ３２４）。例えば、セッションを同定する送信されたｈｔｔｐ要求の部分（ステップ３２４）は、クライアントアプリケーション１４６とプロキシサーバアプリケーション１５８とで共有されたプライベートキーを用いて、暗号化され得る。これら実施形態において、さらに、要求は、クライアントデバイス１４０と関連するユニークな識別子を含む。この識別子もまた、この識別子を傍聴者から保護するために、暗号化され得る。例えば、クライアントデバイス１４０が携帯電話である実施形態において、ユニークな識別子は、携帯電話と関連する電話番号であり得る。
【００４３】
プロキシサーバアプリケーション１５８によって生成された静的イメージは、多数の標準形式（ＪＰＥＧ、ＧＩＦ、ＰＩＮ、ＴＩＦＦまたはＢＭＰを含む）の任意の一つであり得る。一部の実施形態において、プロキシサーバアプリケーション１５８は、シンクライアントアプリケーション１５２、１５４によって露呈された（ｅｘｐｏｓｅｄ）Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ （ＣＯＭ） Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ （ＡＰＩ）を呼び出して、静的イメージを生成する。
【００４４】
一部の実施形態において、プロキシサーバアプリケーション１５８は、生成された静的イメージのサイズを最適化する。これらの実施形態の一つにおいて、プロキシサーバアプリケーション１５８は、ユーザの現在位置を取り囲むスクリーンエリアを選択することによって、スクリーンイメージのサイズを決定する。ユーザの現在位置は、最後のマウスクリックにおけるｘ座標およびｙ座標、または、プロキシサーバアプリケーション１５８に送信される最後のマウス位置におけるｘ座標およびｙ座標を用いて決定され得る。ユーザの最後の位置から、スクリーンがどれだけ上下左右にあるかという量が、スクリーンイメージを形成するために使用され、これは、所定の画素数に設定され得るか、あるいは、クライアントデバイス１４０に基づいて選択され得る。
【００４５】
別の実施形態において、プロキシサーバアプリケーション１５８は、許容可能なイメージロスの量を増加し得る。つまり、プロキシサーバアプリケーション１５８は、送信前のスクリーンイメージを符号化するために、ＪＰＥＧのような損失（ｌｏｓｓｙ）圧縮アルゴリズムを使用している。プロキシサーバアプリケーション１５８は、送信されるイメージタイプ、クライアントデバイス１５８と仮想スクリーンメモリとの間の相対的なサイズの差、クライアントデバイス１４０のスクリーンの絶対的サイズ、クライアントデバイス１４０のスクリーンのビット深さ、または、ネットワーク１７５を介して使用する利用可能な帯域幅に基づいて、許容可能なイメージロスの量を選択し得る。
【００４６】
さらに別の実施形態において、プロキシサーバアプリケーション１５８は、グラフィカル要素を有しないスクリーンを送信するために、静的イメージを使用しない。このような実施形態において、クライアントアプリケーション１４６は、テキストドローイングコマンド用と、グラフィカルコマンド用とに、個別セットのプログラミングインターフェースを露呈する。グラフィカル要素を有しないスクリーンにおいて、テキストドローイング呼び出しのみが、アプリケーションにスクリーンを出力させるために使われる。
【００４７】
さらに別の実施形態において、プロキシサーバアプリケーション１５８は、仮想スクリーンバッファからの読まれたアプリケーション出力をスケーリングし得る。これは、そのスクリーンまたはそのスクリーンの大部分が、クライアントデバイス１４０のスクリーン上で見ることができるようにするためである。代替的に、スケーリングは、ＣＯＭインターフェースによって提供され得る。
【００４８】
プロキシサーバアプリケーション１５８は、クライアントアプリケーション１４６に、生成された静的イメージファイルを送信する（ステップ３２８）。一部の実施形態において、単一のセッション識別子は、多数のクライアントデバイス１４０と共有され得る。これによって、１つ以上のクライアントデバイス１４０が、別のクライアントデバイス１４０を影にすることを許す。すなわち、「影にする」クライアントデバイス１４０によって表示された出力は、「影にされた」クライアントデバイス１４０の出力と同じになる。一実施形態において、静的イメージファイルは、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ｈｔｔｐ）またはＳｅｃｕｒｅ ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ｈｔｔｐｓ）を用いて、クライアントアプリケーション１４６に送信される。クライアントアプリケーション１４６に静的イメージファイルを送信し、クライアントアプリケーション１４６からクライアント入力を受信するために使用されたプロトコルは、図４と関連付けて、以下に、より詳細に記載される。クライアントアプリケーション１４６は、受信した静的イメージファイルを表示する（ステップ３０８）。
【００４９】
ここで、図４を参照すると、ユーザの入力とアプリケーションの実行出力とを交換するために、クライアントアプリケーション１４６とプロキシサーバアプリケーション１５８とによって使用されるプロトコルの一実施形態が、図式的に示される。図４に示す実施形態においては、「イメージを得よ」４１０、「ストリングを送れ」４２０、「キーストロークを送れ」４３０、および「マウスイベントを送れ」４４０の４つのプロトコルコマンドが示されている。
【００５０】
図４に示すように、クライアントアプリケーション１４６は、プロキシサーバアプリケーション１５８に、要求が向けられたサーバと、クライアントアプリケーション１４６によって要求された静的イメージに関するパラメータとを同定するｈｔｔｐ要求４１２を送信する。図４に示す実施形態において、クライアントアプリケーション１４６によって送信されたｈｔｔｐ要求に含まれるパラメータには、開始ｘ座標、開始ｙ座標、終了ｘ座標、終了ｙ座標、および、好ましい静的イメージタイプが含まれる。プロキシサーバアプリケーション１５８は、ｈｔｔｐパケット４１４に応答し、要求された静的イメージファイルを送信する。
【００５１】
図４に示すプロトコル実施形態には、また、「ストリングを送れ」４２０、「キーストロークを送れ」４３０、および「マウスイベントを送れ」４４０の３つの入力コマンドも含まれる。これらコマンドのそれぞれに対し、クライアントアプリケーション１４６は、プロキシサーバアプリケーション１５８に、ユーザ入力が向けられたサーバと、入力とを同定するｈｔｔｐパケットを送信する。「ストリングを送れ」コマンド４２２の場合、ユーザ入力は、一連の英数字である。「キーストロークを送れ」コマンド４３２の場合、ユーザ入力は、キーストロークである。「マウスイベントを送れ」コマンド４４２の場合、ユーザ入力は、マウスイベントのｘ座標と、マウスイベントのｙ座標と、そのマウスイベントに「クリック」が含まれるか否かである。一部の実施形態において、「マウスイベントを送れ」には、また、どのマウスボタンがクリックされたかの表示も含まれる。これらの場合それぞれにおいて、プロキシサーバアプリケーション１５８は、クライアントアプリケーション１４６に、「ＯＫ」メッセージ４２４、４３４、４４４で応答する。
【００５２】
ユーザ入力４２２、４３２、４４２を受信すると、プロキシサーバアプリケーション１５８は、シンクライアントアプリケーション１５２、１５４にユーザ入力を転送する。シンクライアントアプリケーション１５２、１５４は、受信したユーザ入力を、アプリケーションサーバ１１０に転送する。アプリケーションサーバ１１０は、ユーザ入力を受信し、それをアプリケーションプログラム１２２、１２４、１２６、１２８に提供する。
【００５３】
本発明は、製品の１つ以上の品目に具体化された１つ以上のコンピュータ読み出し可能プログラムとして、提供され得る。製品の品目は、フロッピディスク、ハードディスク、コンパクトディスク、デジタル汎用ディスク、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭまたは磁気テープであり得る。一般に、コンピュータ読み出し可能プログラムは、任意のプログラミング言語でインプリメントされ得る。使用可能な言語の例の一部は、Ｃ、Ｃ＋＋、Ｃ＃またはＪＡＶＡ（登録商標）であり得る。ソフトウェアプログラムは、オブジェクトコードの製品の１つ以上の品目上または品目内に格納され得る。
【００５４】
本発明は、特定の好ましい実施形態を参照しながら、図示および記載されてきたが、以下の請求項で規定される本発明の精神と範囲から逸脱することなく、形式および詳細において、様々な変更がなされ得ることは、当業者によって理解されるべきである。
【図面の簡単な説明】
【００５５】
【図１】図１は、制約あるシステムリソースを有するデバイスにアプリケーション出力を提供するシステムの一実施形態のブロック図である。
【図２Ａ】図２Ａは、本発明と関連して、有益なコンピュータの実施形態を示すブロック図である。
【図２Ｂ】図２Ｂは、本発明と関連して、有益なコンピュータの実施形態を示すブロック図である。
【図３】図３は、制約あるシステムリソースを有するデバイスにアプリケーション出力を提供するシステムの動作の一実施形態を示す流れ図である。
【図４】図４は、制約あるシステムリソースを有するデバイスにアプリケーション出力を通信するために使用されるプロトコルの一実施形態の図式表現である。
【特許請求の範囲】
【請求項１】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスで表示するシステムであって、
アプリケーションプログラムを実行するアプリケーションサーバと、
該アプリケーションサーバから、該アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するプロキシサーバと、
クライアントアプリケーションを実行するユーザデバイスであって、該クライアントアプリケーションは、該プロキシサーバから、該アプリケーションプログラムによって生成された該グラフィカルディスプレイ出力のスクリーンを表わす静的イメージデータを受信する、ユーザデバイスと
を備える、システム。
【請求項２】
前記アプリケーションサーバは、サーバファーム内の複数のサーバのうちの１つを備える、請求項１に記載のシステム。
【請求項３】
前記プロキシサーバは、前記クライアントアプリケーションから送信された入力を受信し、該受信した入力を前記アプリケーションサーバに送信する、請求項１に記載のシステム。
【請求項４】
前記プロキシサーバは、前記アプリケーションサーバから、プレゼンテーションプロトコルを介してデータを受信する、請求項１に記載のシステム。
【請求項５】
前記プロキシサーバは、前記アプリケーションサーバから、Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）プロトコルを介してデータを受信する、請求項１に記載のシステム。
【請求項６】
前記プロキシサーバは、前記アプリケーションサーバから、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）を介してデータを受信する、請求項１に記載のシステム。
【請求項７】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データを修正する、請求項１に記載のシステム。
【請求項８】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データをスケーリングする、請求項７に記載のシステム。
【請求項９】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データのカラー深さを修正する、請求項７に記載のシステム。
【請求項１０】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データに損失イメージ圧縮を実行する、請求項７に記載のシステム。
【請求項１１】
前記プロキシサーバは、前記アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンにおける変化を表わすデータを、前記アプリケーションサーバデータから受信し、更新された静的イメージデータを前記クライアントアプリケーションに送信する、請求項１に記載のシステム。
【請求項１２】
前記更新された静的イメージデータは、所定の期間が経過した後に、前記プロキシサーバによって送信される、請求項１１に記載のシステム。
【請求項１３】
前記クライアントアプリケーションによって受信された前記静的イメージデータは、ＧＩＦ形式のイメージファイルの少なくとも一部を備える、請求項１に記載のシステム。
【請求項１４】
前記クライアントアプリケーションによって受信された前記静的イメージデータは、ＪＰＥＧ形式のイメージファイルの少なくとも一部を備える、請求項１に記載のシステム。
【請求項１５】
前記クライアントアプリケーションは、前記プロキシサーバから、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して、静的イメージデータを受信する、請求項１に記載のシステム。
【請求項１６】
前記クライアントアプリケーションは、ＪＡＶＡ（登録商標）アプリケーションを備える、請求項１に記載のシステム。
【請求項１７】
前記クライアントアプリケーションは、実行中に、５０ｋＢ未満のメモリを使用する、請求項１に記載のシステム。
【請求項１８】
前記クライアントアプリケーションは、前記プロキシサーバからの更新された静的イメージデータを要求する、請求項１に記載のシステム。
【請求項１９】
前記ユーザデバイスは、携帯電話を備える、請求項１に記載のシステム。
【請求項２０】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する方法であって、該方法は、
（ａ）グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを、アプリケーションサーバによって実行するステップと、
（ｂ）生成されたグラフィカルユーザインターフェースデータの該スクリーンを、該アプリケーションサーバによってプロキシサーバに送信するステップと、
（ｃ）生成されたグラフィカルユーザインターフェースデータの該スクリーンの少なくとも一部を表わす静的イメージデータを、該プロキシサーバによってユーザデバイスに送信するステップと、
（ｄ）該送信された静的イメージデータを、該ユーザデバイスによって表示するステップと
を包含する、方法。
【請求項２１】
前記実行するアプリケーションによって生成されたグラフィカルユーザインターフェースデータの前記スクリーンを、プレゼンテーションプロトコル形式内の少なくとも第一のメッセージの中に、前記アプリケーションサーバによってフォーマットするステップをさらに包含する、請求項２０に記載の方法。
【請求項２２】
前記実行するアプリケーションによって生成されたグラフィカルユーザインターフェースデータの前記スクリーンを、Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）プロトコル形式内の少なくとも第一のメッセージの中に、前記アプリケーションサーバによってフォーマットするステップをさらに包含する、請求項２０に記載の方法。
【請求項２３】
前記実行するアプリケーションによって生成されたグラフィカルユーザインターフェースデータの前記スクリーンを、前記アプリケーションサーバによってＲｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）形式内の少なくとも第一のメッセージの中に、フォーマットするステップをさらに包含する、請求項２０に記載の方法。
【請求項２４】
生成されたグラフィカルユーザインターフェースデータの前記スクリーンの少なくとも一部を表わす静的イメージを、前記プロキシサーバによって生成するステップをさらに包含する、請求項２０に記載の方法。
【請求項２５】
前記アプリケーションサーバから受信したデータを、前記プロキシサーバによって修正するステップをさらに包含する、請求項２０に記載の方法。
【請求項２６】
前記修正するステップは、前記アプリケーションサーバから受信した前記データに損失イメージ圧縮を適用することを包含する、請求項２５に記載の方法。
【請求項２７】
前記修正するステップは、前記アプリケーションサーバから受信した前記データのカラー深さを変更することを包含する、請求項２５に記載の方法。
【請求項２８】
前記修正するステップは、前記アプリケーションサーバから受信した前記データをスケーリングすることを包含する、請求項２５に記載の方法。
【請求項２９】
前記ステップ（ｃ）は、グラフィカルユーザ出力の前記スクリーンの少なくとも一部を表わすＧＩＦイメージデータを、前記プロキシサーバによって、ユーザデバイスに送信することを包含する、請求項１８に記載の方法。
【請求項３０】
前記ステップ（ｃ）は、グラフィカルユーザ出力の前記スクリーンの少なくとも一部を表わすＪＰＥＧイメージデータを、前記プロキシサーバによって、ユーザデバイスに送信することを包含する、請求項２０に記載の方法。
【請求項３１】
前記ステップ（ｃ）は、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して、グラフィカルユーザインターフェースデータの前記スクリーンの少なくとも一部を表わす静的イメージデータを、前記プロキシサーバによって、ユーザデバイスに送信することを包含する、請求項２０に記載の方法。
【請求項３２】
前記ユーザデバイスからの入力を表わすデータを、前記プロキシサーバによって、受信するステップをさらに包含する、請求項２０に記載の方法。
【請求項３３】
前記受信したユーザ入力データを、前記アプリケーションサーバに、前記プロキシサーバによって、送信するステップをさらに包含する、請求項３２に記載の方法。
【請求項３４】
生成されたグラフィカルユーザインターフェースデータの前記スクリーン内の変化を表わす前記アプリケーション実行サーバからのデータを、前記プロキシサーバによって、受信するステップをさらに包含する、請求項２０に記載の方法。
【請求項３５】
生成されたグラフィカルユーザインターフェースデータの前記変化したスクリーンを表わす静的イメージデータを、前記プロキシサーバによって、ユーザデバイスに送信するステップをさらに包含する、請求項３４に記載の方法。
【請求項３６】
前記送信するステップは、所定の期間が経過した後に起こる、請求項３５に記載の方法。
【請求項３７】
更新された静的イメージ情報を、クライアントアプリケーションによって、送信するステップをさらに包含する、請求項２０に記載の方法。
【請求項３８】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する装置であって、
アプリケーションサーバから、該アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを、第一のプロトコル形式で受信する第一のプロトコルハンドラと、
該第一のプロトコルハンドラによって受信されたグラフィカルディスプレイ出力の該スクリーンの少なくとも一部を表わす静的イメージデータを、表示用クライアントアプリケーションに、第二のプロトコル形式で送信する第二のプロトコルハンドラと
を備える、装置。
【請求項３９】
前記第二のプロトコルハンドラは、ユーザ入力を表わすデータを、前記クライアントアプリケーションから受信する、請求項３８に記載の装置。
【請求項４０】
前記第一のプロトコルハンドラは、前記第二のプロトコルハンドラによって受信されたユーザ入力を表わす前記データを、前記アプリケーションサーバに送信する、請求項３９に記載の装置。
【請求項４１】
前記第一のプロトコルハンドラは、前記受信したデータを、前記第一のプロトコルから前記第二のプロトコルに翻訳する、請求項３８に記載の装置。
【請求項４２】
前記第二のプロトコルハンドラは、前記受信したデータを、前記第一のプロトコルから前記第二のプロトコルに翻訳する、請求項３８に記載の装置。
【請求項４３】
前記第一のプロトコル内で、前記第一のプロトコルハンドラによって受信されたデータにアクセスし、それを前記第二のプロトコル形式の少なくとも１つのメッセージに翻訳する翻訳モジュールをさらに備える、請求項３８に記載の装置。
【請求項４４】
サーバ上で実行するアプリケーションプログラムによって生成されたグラフィカルディスプレイ出力を、ユーザデバイスに表示する方法であって、
（ａ）アプリケーションサーバから、第一のプロトコル形式を介して、該アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するステップと、
（ｂ）ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して、
該アプリケーションサーバ上で実行する該アプリケーションによって生成されたグラフィカルディスプレイ出力の該スクリーンの少なくとも一部を表わす静的イメージデータを送信するステップと
を包含する、方法。
【請求項４５】
前記クライアントアプリケーションから、前記第二のプロトコルを介して、前記アプリケーションプログラムへのユーザ入力を表わすデータを受信するステップをさらに包含する、請求項４４に記載の方法。
【請求項４６】
前記アプリケーションに、前記第一のプロトコルを介して、前記クライアントアプリケーションから受信したユーザ入力を表わすデータを送信するステップをさらに包含する、請求項４５に記載の方法。
【請求項４７】
グラフィカルディスプレイ出力の前記スクリーンを表わすデータを、第一のプロトコル形式から、第二のプロトコル形式翻訳するステップをさらに包含する、請求項４４に記載の方法。
【請求項４８】
ステップ（ｂ）は、ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して、前記アプリケーションサーバ上で実行するアプリケーションのグラフィカルディスプレイ出力の前記スクリーンの少なくとも一部を表わすＧＩＦデータを送信することを包含する、請求項４４に記載の方法。
【請求項４９】
前記ＧＩＦファイルは、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して、前記クライアントアプリケーションに送信される、請求項４８に記載の方法。
【請求項５０】
ステップ（ｂ）は、ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して、前記アプリケーションサーバ上で実行するアプリケーションのグラフィカルディスプレイ出力の前記スクリーンの少なくとも一部を表わすＪＰＥＧデータを送信することを包含する、請求項４４に記載の方法。
【請求項５１】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスで表示するシステムであって、該システムは、
アプリケーションプログラムを実行するアプリケーションサーバと、
該アプリケーションサーバから、プレゼンテーションレベルのプロトコルを介して、該アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するプロキシサーバと、
クライアントアプリケーションを実行するユーザデバイスであって、該クライアントアプリケーションは、該プロキシサーバから、該アプリケーションプログラムによって生成された該グラフィカルディスプレイ出力のスクリーンを表わす静的イメージデータを、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して受信する、ユーザデバイスと
を備える、システム。
【請求項５２】
サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示する方法であって、該方法は、
（ａ）グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを、アプリケーションサーバによって実行するステップと、
（ｂ）生成されたグラフィカルユーザインターフェースデータの該スクリーンを、該アプリケーションサーバによって、プレゼンテーションレベルのプロトコルを介して、プロキシサーバに送信するステップと、
（ｃ）生成されたグラフィカルユーザインターフェースデータの該スクリーンの少なくとも一部を表わす静的イメージデータを、該プロキシサーバによって、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して、ユーザデバイスに送信するステップと、
（ｄ）該送信された静的イメージデータを、該ユーザデバイスによって表示するステップと
を包含する、方法。
【請求項５３】
サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラム手段を具体化した製品の品目であって、該製品の品目は、
該サーバ上で実行するアプリケーションによって生成されたグラフィカルユーザデータインターフェースのスクリーンを、プロキシサーバに送信するコンピュータ読み出し可能なプログラム手段と、
生成されたグラフィカルユーザデータインターフェースの該スクリーンの少なくとも一部を表わす静的イメージデータを、該プロキシサーバによって、ユーザデバイスに通信するコンピュータ読み出し可能なプログラム手段と、
該送信された静的イメージデータを、該ユーザデバイスによって、表示するコンピュータ読み出し可能なプログラム手段と
を備える、製品の品目。
【請求項５４】
サーバ上で実行するアプリケーションプログラムによって生成されるグラフィカルディスプレイ出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラムを具体化した製品の品目であって、
アプリケーションサーバから、第一のプロトコルを介して、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するコンピュータ読み出し可能なプログラム手段と、
第二のプロトコルを介して、該アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力の該スクリーンの少なくとも一部を表わす静的イメージデータを、ディスプレイ用クライアントアプリケーションに通信するコンピュータ読み出し可能なプログラム手段と
を備える、製品の品目。
【請求項１】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスで表示するシステムであって、
アプリケーションプログラムを実行するアプリケーションサーバと、
該アプリケーションサーバから、該アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するプロキシサーバと、
クライアントアプリケーションを実行するユーザデバイスであって、該クライアントアプリケーションは、該プロキシサーバから、該アプリケーションプログラムによって生成された該グラフィカルディスプレイ出力のスクリーンを表わす静的イメージデータを受信する、ユーザデバイスと
を備える、システム。
【請求項２】
前記アプリケーションサーバは、サーバファーム内の複数のサーバのうちの１つを備える、請求項１に記載のシステム。
【請求項３】
前記プロキシサーバは、前記クライアントアプリケーションから送信された入力を受信し、該受信した入力を前記アプリケーションサーバに送信する、請求項１に記載のシステム。
【請求項４】
前記プロキシサーバは、前記アプリケーションサーバから、プレゼンテーションプロトコルを介してデータを受信する、請求項１に記載のシステム。
【請求項５】
前記プロキシサーバは、前記アプリケーションサーバから、Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）プロトコルを介してデータを受信する、請求項１に記載のシステム。
【請求項６】
前記プロキシサーバは、前記アプリケーションサーバから、Ｒｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）を介してデータを受信する、請求項１に記載のシステム。
【請求項７】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データを修正する、請求項１に記載のシステム。
【請求項８】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データをスケーリングする、請求項７に記載のシステム。
【請求項９】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データのカラー深さを修正する、請求項７に記載のシステム。
【請求項１０】
前記プロキシサーバは、前記アプリケーションサーバから受信した前記データに損失イメージ圧縮を実行する、請求項７に記載のシステム。
【請求項１１】
前記プロキシサーバは、前記アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンにおける変化を表わすデータを、前記アプリケーションサーバデータから受信し、更新された静的イメージデータを前記クライアントアプリケーションに送信する、請求項１に記載のシステム。
【請求項１２】
前記更新された静的イメージデータは、所定の期間が経過した後に、前記プロキシサーバによって送信される、請求項１１に記載のシステム。
【請求項１３】
前記クライアントアプリケーションによって受信された前記静的イメージデータは、ＧＩＦ形式のイメージファイルの少なくとも一部を備える、請求項１に記載のシステム。
【請求項１４】
前記クライアントアプリケーションによって受信された前記静的イメージデータは、ＪＰＥＧ形式のイメージファイルの少なくとも一部を備える、請求項１に記載のシステム。
【請求項１５】
前記クライアントアプリケーションは、前記プロキシサーバから、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して、静的イメージデータを受信する、請求項１に記載のシステム。
【請求項１６】
前記クライアントアプリケーションは、ＪＡＶＡ（登録商標）アプリケーションを備える、請求項１に記載のシステム。
【請求項１７】
前記クライアントアプリケーションは、実行中に、５０ｋＢ未満のメモリを使用する、請求項１に記載のシステム。
【請求項１８】
前記クライアントアプリケーションは、前記プロキシサーバからの更新された静的イメージデータを要求する、請求項１に記載のシステム。
【請求項１９】
前記ユーザデバイスは、携帯電話を備える、請求項１に記載のシステム。
【請求項２０】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する方法であって、該方法は、
（ａ）グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを、アプリケーションサーバによって実行するステップと、
（ｂ）生成されたグラフィカルユーザインターフェースデータの該スクリーンを、該アプリケーションサーバによってプロキシサーバに送信するステップと、
（ｃ）生成されたグラフィカルユーザインターフェースデータの該スクリーンの少なくとも一部を表わす静的イメージデータを、該プロキシサーバによってユーザデバイスに送信するステップと、
（ｄ）該送信された静的イメージデータを、該ユーザデバイスによって表示するステップと
を包含する、方法。
【請求項２１】
前記実行するアプリケーションによって生成されたグラフィカルユーザインターフェースデータの前記スクリーンを、プレゼンテーションプロトコル形式内の少なくとも第一のメッセージの中に、前記アプリケーションサーバによってフォーマットするステップをさらに包含する、請求項２０に記載の方法。
【請求項２２】
前記実行するアプリケーションによって生成されたグラフィカルユーザインターフェースデータの前記スクリーンを、Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）プロトコル形式内の少なくとも第一のメッセージの中に、前記アプリケーションサーバによってフォーマットするステップをさらに包含する、請求項２０に記載の方法。
【請求項２３】
前記実行するアプリケーションによって生成されたグラフィカルユーザインターフェースデータの前記スクリーンを、前記アプリケーションサーバによってＲｅｍｏｔｅ Ｄｉｓｐｌａｙ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）形式内の少なくとも第一のメッセージの中に、フォーマットするステップをさらに包含する、請求項２０に記載の方法。
【請求項２４】
生成されたグラフィカルユーザインターフェースデータの前記スクリーンの少なくとも一部を表わす静的イメージを、前記プロキシサーバによって生成するステップをさらに包含する、請求項２０に記載の方法。
【請求項２５】
前記アプリケーションサーバから受信したデータを、前記プロキシサーバによって修正するステップをさらに包含する、請求項２０に記載の方法。
【請求項２６】
前記修正するステップは、前記アプリケーションサーバから受信した前記データに損失イメージ圧縮を適用することを包含する、請求項２５に記載の方法。
【請求項２７】
前記修正するステップは、前記アプリケーションサーバから受信した前記データのカラー深さを変更することを包含する、請求項２５に記載の方法。
【請求項２８】
前記修正するステップは、前記アプリケーションサーバから受信した前記データをスケーリングすることを包含する、請求項２５に記載の方法。
【請求項２９】
前記ステップ（ｃ）は、グラフィカルユーザ出力の前記スクリーンの少なくとも一部を表わすＧＩＦイメージデータを、前記プロキシサーバによって、ユーザデバイスに送信することを包含する、請求項１８に記載の方法。
【請求項３０】
前記ステップ（ｃ）は、グラフィカルユーザ出力の前記スクリーンの少なくとも一部を表わすＪＰＥＧイメージデータを、前記プロキシサーバによって、ユーザデバイスに送信することを包含する、請求項２０に記載の方法。
【請求項３１】
前記ステップ（ｃ）は、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して、グラフィカルユーザインターフェースデータの前記スクリーンの少なくとも一部を表わす静的イメージデータを、前記プロキシサーバによって、ユーザデバイスに送信することを包含する、請求項２０に記載の方法。
【請求項３２】
前記ユーザデバイスからの入力を表わすデータを、前記プロキシサーバによって、受信するステップをさらに包含する、請求項２０に記載の方法。
【請求項３３】
前記受信したユーザ入力データを、前記アプリケーションサーバに、前記プロキシサーバによって、送信するステップをさらに包含する、請求項３２に記載の方法。
【請求項３４】
生成されたグラフィカルユーザインターフェースデータの前記スクリーン内の変化を表わす前記アプリケーション実行サーバからのデータを、前記プロキシサーバによって、受信するステップをさらに包含する、請求項２０に記載の方法。
【請求項３５】
生成されたグラフィカルユーザインターフェースデータの前記変化したスクリーンを表わす静的イメージデータを、前記プロキシサーバによって、ユーザデバイスに送信するステップをさらに包含する、請求項３４に記載の方法。
【請求項３６】
前記送信するステップは、所定の期間が経過した後に起こる、請求項３５に記載の方法。
【請求項３７】
更新された静的イメージ情報を、クライアントアプリケーションによって、送信するステップをさらに包含する、請求項２０に記載の方法。
【請求項３８】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスに表示する装置であって、
アプリケーションサーバから、該アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを、第一のプロトコル形式で受信する第一のプロトコルハンドラと、
該第一のプロトコルハンドラによって受信されたグラフィカルディスプレイ出力の該スクリーンの少なくとも一部を表わす静的イメージデータを、表示用クライアントアプリケーションに、第二のプロトコル形式で送信する第二のプロトコルハンドラと
を備える、装置。
【請求項３９】
前記第二のプロトコルハンドラは、ユーザ入力を表わすデータを、前記クライアントアプリケーションから受信する、請求項３８に記載の装置。
【請求項４０】
前記第一のプロトコルハンドラは、前記第二のプロトコルハンドラによって受信されたユーザ入力を表わす前記データを、前記アプリケーションサーバに送信する、請求項３９に記載の装置。
【請求項４１】
前記第一のプロトコルハンドラは、前記受信したデータを、前記第一のプロトコルから前記第二のプロトコルに翻訳する、請求項３８に記載の装置。
【請求項４２】
前記第二のプロトコルハンドラは、前記受信したデータを、前記第一のプロトコルから前記第二のプロトコルに翻訳する、請求項３８に記載の装置。
【請求項４３】
前記第一のプロトコル内で、前記第一のプロトコルハンドラによって受信されたデータにアクセスし、それを前記第二のプロトコル形式の少なくとも１つのメッセージに翻訳する翻訳モジュールをさらに備える、請求項３８に記載の装置。
【請求項４４】
サーバ上で実行するアプリケーションプログラムによって生成されたグラフィカルディスプレイ出力を、ユーザデバイスに表示する方法であって、
（ａ）アプリケーションサーバから、第一のプロトコル形式を介して、該アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するステップと、
（ｂ）ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して、
該アプリケーションサーバ上で実行する該アプリケーションによって生成されたグラフィカルディスプレイ出力の該スクリーンの少なくとも一部を表わす静的イメージデータを送信するステップと
を包含する、方法。
【請求項４５】
前記クライアントアプリケーションから、前記第二のプロトコルを介して、前記アプリケーションプログラムへのユーザ入力を表わすデータを受信するステップをさらに包含する、請求項４４に記載の方法。
【請求項４６】
前記アプリケーションに、前記第一のプロトコルを介して、前記クライアントアプリケーションから受信したユーザ入力を表わすデータを送信するステップをさらに包含する、請求項４５に記載の方法。
【請求項４７】
グラフィカルディスプレイ出力の前記スクリーンを表わすデータを、第一のプロトコル形式から、第二のプロトコル形式翻訳するステップをさらに包含する、請求項４４に記載の方法。
【請求項４８】
ステップ（ｂ）は、ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して、前記アプリケーションサーバ上で実行するアプリケーションのグラフィカルディスプレイ出力の前記スクリーンの少なくとも一部を表わすＧＩＦデータを送信することを包含する、請求項４４に記載の方法。
【請求項４９】
前記ＧＩＦファイルは、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して、前記クライアントアプリケーションに送信される、請求項４８に記載の方法。
【請求項５０】
ステップ（ｂ）は、ディスプレイ用クライアントアプリケーションに、第二のプロトコルを介して、前記アプリケーションサーバ上で実行するアプリケーションのグラフィカルディスプレイ出力の前記スクリーンの少なくとも一部を表わすＪＰＥＧデータを送信することを包含する、請求項４４に記載の方法。
【請求項５１】
サーバ上で実行するアプリケーションプログラムによって生成された出力を、ユーザデバイスで表示するシステムであって、該システムは、
アプリケーションプログラムを実行するアプリケーションサーバと、
該アプリケーションサーバから、プレゼンテーションレベルのプロトコルを介して、該アプリケーションプログラムによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するプロキシサーバと、
クライアントアプリケーションを実行するユーザデバイスであって、該クライアントアプリケーションは、該プロキシサーバから、該アプリケーションプログラムによって生成された該グラフィカルディスプレイ出力のスクリーンを表わす静的イメージデータを、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して受信する、ユーザデバイスと
を備える、システム。
【請求項５２】
サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示する方法であって、該方法は、
（ａ）グラフィカルユーザインターフェースデータのスクリーンを生成するアプリケーションを、アプリケーションサーバによって実行するステップと、
（ｂ）生成されたグラフィカルユーザインターフェースデータの該スクリーンを、該アプリケーションサーバによって、プレゼンテーションレベルのプロトコルを介して、プロキシサーバに送信するステップと、
（ｃ）生成されたグラフィカルユーザインターフェースデータの該スクリーンの少なくとも一部を表わす静的イメージデータを、該プロキシサーバによって、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）コマンドを介して、ユーザデバイスに送信するステップと、
（ｄ）該送信された静的イメージデータを、該ユーザデバイスによって表示するステップと
を包含する、方法。
【請求項５３】
サーバ上で実行するアプリケーションプログラムによって生成される出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラム手段を具体化した製品の品目であって、該製品の品目は、
該サーバ上で実行するアプリケーションによって生成されたグラフィカルユーザデータインターフェースのスクリーンを、プロキシサーバに送信するコンピュータ読み出し可能なプログラム手段と、
生成されたグラフィカルユーザデータインターフェースの該スクリーンの少なくとも一部を表わす静的イメージデータを、該プロキシサーバによって、ユーザデバイスに通信するコンピュータ読み出し可能なプログラム手段と、
該送信された静的イメージデータを、該ユーザデバイスによって、表示するコンピュータ読み出し可能なプログラム手段と
を備える、製品の品目。
【請求項５４】
サーバ上で実行するアプリケーションプログラムによって生成されるグラフィカルディスプレイ出力を、ユーザデバイスに表示するコンピュータ読み出し可能なプログラムを具体化した製品の品目であって、
アプリケーションサーバから、第一のプロトコルを介して、アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力のスクリーンを表わすデータを受信するコンピュータ読み出し可能なプログラム手段と、
第二のプロトコルを介して、該アプリケーションサーバ上で実行するアプリケーションによって生成されたグラフィカルディスプレイ出力の該スクリーンの少なくとも一部を表わす静的イメージデータを、ディスプレイ用クライアントアプリケーションに通信するコンピュータ読み出し可能なプログラム手段と
を備える、製品の品目。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【公表番号】特表２００８−５０２１７６（Ｐ２００８−５０２１７６Ａ）
【公表日】平成２０年１月２４日（２００８．１．２４）
【国際特許分類】
【出願番号】特願２００７−５１３４３６（Ｐ２００７−５１３４３６）
【出願日】平成１７年５月１３日（２００５．５．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０１６９２８
【国際公開番号】ＷＯ２００５／１１４３９５
【国際公開日】平成１７年１２月１日（２００５．１２．１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＲＡＭ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
【公表日】平成２０年１月２４日（２００８．１．２４）
【国際特許分類】
【出願日】平成１７年５月１３日（２００５．５．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０１６９２８
【国際公開番号】ＷＯ２００５／１１４３９５
【国際公開日】平成１７年１２月１日（２００５．１２．１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＲＡＭ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
[ Back to top ]