(57)【要約】  ウェブブラウザにプラグイン又はソフトウエアをインストールする必要なしにユーザがリモートデスクトップ又はリモートアプリケーションにアクセスしてそれとインタラクションを行う可能にするシステム及び方法（ツール）が説明されている。いくつかの実施形態では、ツールはリモートデスクトップ又はリモートアプリケーションを表示するダブルバッファリンググラフィクスと、繰り返されるイメージをキャッシュ処理することとを含む。それらのツールはまた変化したデスクトップ又はアプリケーションの部分を識別することと、その変化した部分を送信することとを含む。
2010531488.tif 000002
【特許請求の範囲】
【請求項１】
ウェブブラウザによってユーザに対して表示されるウェブリソースを更新する方法であって、
リモートアプリケーション及びリモートデスクトップのうちの少なくとも１つを表す新しいウェブリソース及び更新済みウェブリソースのうちの少なくとも１つを要求するリクエストを送信するステップ（５０２，６０２，７０２）と、
変化した前記アプリケーション及び前記デスクトップのうちの少なくとも１つの少なくとも部分を表すイメージを受信するステップ（６１０，７１０）と、
ユーザによってインストールされたリモートデスクトッププラグイン／リモートアプリケーションプラグイン又はリモートデスクトップソフトウエア／リモートアプリケーションソフトウエアを用いることなく前記リモートアプリケーション又はリモートデスクトップを表す前記新しいウェブリソース及び前記更新済みウェブリソースのうちの前記少なくとも１つを表示するステップ（６１２，６１４，７１２）と
を具えたことを特徴とする方法。
【請求項２】
前記少なくとも変化した部分を表すイメージを受信するステップは、
少なくとも１つのイメージＵＲＬを含むリストを受信するステップ（６１０）と、
前記少なくとも１つのイメージのための位置情報を受信するステップ（６１０）と
を含むことを特徴とする請求項１記載の方法。
【請求項３】
受信された前記リスト及び前記位置情報に基づいてイメージオブジェクトを前記ウェブブラウザによって作成して配置するステップ（６１２）と、
その作成及び配置したイメージのＵＲＬをその受信されたリストにおいて識別されたＵＲＬに合わせるステップ（６１２）と
をさらに具えたことを特徴とする請求項２記載の方法。
【請求項４】
前記イメージが前記ウェブブラウザのキャッシュにないとき、当該ＵＲＬによって識別されたイメージを前記ウェブブラウザによって取り出すステップ（６１２）をさらに具えたことを特徴とする請求項３記載の方法。
【請求項５】
前記リクエストはサーバに送信され、前記方法は、
前記リモートアプリケーション又はリモートデスクトップの前記変化した部分を前記サーバによって識別するステップ（６０６）と、
前記変化した部分に関係した前記リスト及び前記位置情報を前記サーバによって送信するステップ（６０８）と
をさらに具えたことを特徴とする請求項４記載の方法。
【請求項６】
当該少なくとも変化した部分を表すイメージを受信するステップは、
少なくとも１つのイメージのための位置情報を受信するステップ（７１０）と、
前記少なくとも１つのイメージをバイナリデータとして受信するステップ（７１０）と
を含むことを特徴とする請求項１記載の方法。
【請求項７】
受信された前記位置情報及び前記バイナリデータに基づいてイメージオブジェクトを前記ウェブブラウザによって作成して配置するステップ（７１２）をさらに具えたことを特徴とする請求項６記載の方法。
【請求項８】
前記リクエストはサーバに送信され、前記方法は、
前記リモートアプリケーション又はリモートデスクトップの前記変化した部分を前記サーバによって識別するステップ（７０６）と、
前記変化した部分に関係した前記位置情報及び前記バイナリデータを前記サーバによって送信するステップ（７０８）と
をさらに具えたことを特徴とする請求項７記載の方法。
【請求項９】
ウェブブラウザで入力をバッチ処理する方法であって、
前記ウェブブラウザによって入力イベントを受信するステップ（１２０２）と、
データ構造に複数の受信した入力イベントを累積するステップ（１２０４）と、
クライアント側スクリプトリクエストと関連したオブジェクトが有効であるとき前記累積した入力イベントを送信するステップ（１２０６）と
を具えたことを特徴とする方法。
【請求項１０】
前記データ構造はリスト及びデータベースのうちの少なくとも１つを含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記クライアント側スクリプトリクエストはＸＭＬＨＴＴＰオブジェクトを含むことを特徴とする請求項９記載の方法。
【請求項１２】
前記データ構造はアレイ型データ構造であることを特徴とする請求項９記載の方法。
【請求項１３】
前記オブジェクトがデータの送信を終了したとき、累積した入力イベントについての前記データ構造をチェックするステップと、
前記データ構造が入力イベントを含むとき前記累積した入力イベントを送信するステップと
をさらに具えたことを特徴とする請求項９記載の方法。
【請求項１４】
クライアント側スクリプトリクエストに関連したオブジェクトがＸＭＬＨＴＴＰオブジェクトを含み、前記方法は、
リモートサーバでＸＭＬＨＴＴＰオブジェクトによって送信された前記データを受信するステップと、
前記ＸＭＬＨＴＴＰオブジェクトによって送信された前記データから複数の入力イベントを抽出するステップと、
リモートデスクトップ又はリモートアプリケーションへの入力として当該抽出した入力イベントを使用するステップと
をさらに具えたことを特徴とする請求項９記載の方法。
【請求項１５】
前記ＸＭＬＨＴＴＰオブジェクトによって送信された前記データはウェブサーバによって受信され、前記方法は、
前記ウェブサーバ上のターミナルサーバクライアントを用いて前記ウェブサーバからターミナルサーバに入力イベントデータを送信するステップをさらに具えたことを特徴とする請求項１４記載の方法。
【請求項１６】
ウェブブラウザによってユーザに対して表示されるグラフィクスを更新する方法であって、
ウェブリソースの一部についての少なくとも１つの更新済みイメージを受信するステップ（８０２，９０２）と、
ユーザによってインストールされるリモートデスクトッププラグイン又はリモートアプリケーションプラグイン又は他のリモートデスクトップソフトウエア又はリモートアプリケーションソフトウエアを用いることなくダブルバッファリングを用いて前記ウェブリソースの表示したイメージを更新するステップ（８０３）と
を具えたことを特徴とする方法。
【請求項１７】
前記ダブルバッファリングは、
トップＤＩＶ又はボトムＤＩＶに前記更新済みイメージを配置することによりその表示したウェブページを更新するステップ（９０４）と、
前記トップＤＩＶ及び前記ボトムＤＩＶのｚ−オーダをスワップ処理するステップ（９０６）と
を含むことを特徴とする請求項１６記載の方法。
【請求項１８】
前記更新済みイメージが前記ウェブブラウザのキャッシュにあり、前記ウェブブラウザによって表示されるべきものであるとき、前記更新済みイメージを受信する代わりに表示されるべき前記キャッシュに記憶されたイメージを識別するイメージ識別子を受信するステップ（１００６）をさらに具えたことを特徴とする請求項１６記載の方法。
【請求項１９】
前記更新済みイメージが前記ウェブブラウザの前記キャッシュになく、前記ウェブブラウザによって表示されるべきものであるとき、前記更新済みイメージを要求して受信するステップと、
当該受信した更新済みイメージをキャッシュ処理する命令を受信するステップ（１０１０）と、
当該キャッシュ処理された更新済みイメージについての識別子を受信するステップ（１０１０）と
をさらに具えたことを特徴とする請求項１８記載の方法。
【請求項２０】
前記更新済みイメージの名称又は前記更新済みイメージのＵＲＬが前記更新済みイメージのハッシュであるウェブリソースを受信するステップと、
前記名称又はＵＲＬが前記ウェブブラウザによってキャッシュ処理されたイメージを識別するならば、前記ウェブブラウザによってキャッシュ処理された当該イメージを用いるステップと、
前記名称又はＵＲＬが前記ウェブブラウザによってキャッシュ処理されたイメージを識別しないならば、前記更新済みイメージを要求するステップと
をさらに具えたことを特徴とする請求項１６記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
現在、多くのユーザはネットワーク使用可能なアプリケーションとインタラクションを行っている。ホームコンピュータのユーザは、例えば、ウェブブラウザアプリケーションとインタラクションとを行ってインターネット上のウェブページを見ている。他のユーザは旅行又は在宅勤務の間にリモートデスクトップアプリケーションを使用してリモートコンピュータにアクセスする。
【０００２】
マイクロソフトによって提供されるようなウェブを介したデスクトップ／アプリケーションリモーティングを提供する現在のソリューションはウェブブラウザ内でActiveXコントロールをロードすることを含んでいる。特に、マイクロソフトソリューションはTSクライアントActiveXコントロールと呼ばれ、リモートデスクトップ、リモートウェブコネクション、リモートプログラム、リモートアシスタンス、及びウインドウズミーティングスペースを含む他のネットワーク使用可能なアプリケーションを動かす同じコントロールである。
【０００３】
ActiveXコントロールはオペレーティングシステム（ＯＳ）及びアーキテクチャ依存コンポーネントであり、全てのウェブブラウザによってサポートされていない。それらの限定に加えて、エンドユーザはActiveXコントロールをまだインストールしていないならば、リモートデスクトップ又はリモートアプリケーションを使用する前にインストールを要求される。インストールは多くのセキュリティ上の問題を引き起こしている。更に、ユーザはインストールを実際に行うためにはマシンに許可又は権利を持つことを要求される。また、ユーザはコンポーネントをインストールすることのセキュリティに及ぼす影響を理解していない。ユーザのマシンで動作するコントロールはユーザの観点から安全と考えられるシステムの一部へのアクセスを可能にする。
【発明の概要】
【課題を解決するための手段】
【０００４】
本明細書に開示された技術は、プラットフォーム独立性及びユーザのインストールなしのソリューションを与えることによりデスクトップリモーティング及びアプリケーションリモーティングを提供する課題を解決する。ウェブブラウザは主なエンドユーザ伝達メカニズムである。
【０００５】
１つの実施例では、ウェブ／ウェブブラウザベースの技術は追加のコンポーネントのインストールをユーザに要求することなく従来のActiveXコントロールに類似のリモーティングソリューションを伝達するために利用される。ユーザ体験はユーザがグラフィックスやテキストを見たり、フォームに書き込み及び提出する従来のウェブページを訪れることと類似している。リモートアプリケーションの観点から、ウェブページ上のイメージは、リモートアプリケーションの「表示」変化として、またインタラクションを行うためにリモートアプリケーション用のウェブページからの入力を受信すると、更新されるべきである。
【０００６】
この概要は以下に詳細な説明で更に説明される簡単なフォームにおいてコンセプトの選択を導くために与えられる。この概要は請求項の構成の重要な特徴又は主たる特徴を認識することを意図しておらず、又は請求項の構成の範囲を限定するために用いられることを意図していない。
【図面の簡単な説明】
【０００７】
詳細な説明は添付図面を参照して説明されている。図において、異なる図における同一の参照番号の使用は同類又は同一のアイテムを示している。
【図１】ターミナルサーバがウェブサーバから分離した動作環境例を示す。
【図２】ターミナルサーバがウェブサーバと結合した動作環境例を示す。
【図３】図１に示したシステム用のデータフロー例を示す。
【図４】図２に示したシステム用のデータフロー例を示す。
【図５】グラフィックスデータを更新するための第１の処理例を示す。
【図６】グラフィックスデータを更新するための第２の処理例である。
【図７】グラフィックスデータを更新するための第３の処理例である。
【図８】ダブルバッファリングを用いたグラフィックス表示を更新するための処理例である。
【図９】ダブルバッファリングを用いたグラフィックス表示を更新するための第２の処理例である。
【図１０】グラフィックスデータをキャッシュ処理するために用いられるべき処理例である。
【図１１】グラフィックスデータをキャッシュ処理するために用いられるべき第２の処理例である。
【図１２】入力イベントをバッチ処理するために用いられるべき処理例である。
【発明を実施するための形態】
【０００８】
概説
以下の説明はリモートデスクトップ又はリモートアプリケーションのソフトウエア又はプラグインをインストールする必要なしにブラウザを用いてリモートデスクトップ又はリモートアプリケーションをユーザがアクセスできるようにするシステム及び方法を述べている。本明細書で説明される技術は、サーバ及びサーバシステムのより大きな有用性を潜在的に与える技術分野の現在の状況を越える重要な改良、減少したバンド幅コスト、及びリモートデスクトップ又はリモートアプリケーションとの改良したクライアント体験を提供する。
【０００９】
特に、本明細書で開示されたシステム及び方法は、（１）主なエンドユーザ伝達メカニズムとてウェブブラウザを用いるデスクトップリモーティング及びアプリケーションリモーティング、（２）コンポーネントをインストールすることをユーザに要求しない環境、（３）プラットフォーム独立性を提供することができる。それらのツールがそれら及び他の技術を可能にする環境例が以下に説明され、そして様々な発明に関する技術及びツールの実施形態例を説明する他のセクションが続く。
【００１０】
動作環境例
詳細にツールを説明する前に、次の２つの動作環境例の説明はツールの様々な発明に関する態様が用いられる２つの方法例を理解する上で助けとなる。以下に説明される環境は２つの例となっているが、特定の動作環境にツールの適用を限定するつもりではない。請求項の構成の精神及び範囲から離れることなく他の環境を用いても良い。
【００１１】
図１は１つのそのような動作環境を１００で示している。動作環境１００は１以上のクライアントプロセッサ１０４及びクライアントコンピュータ可読媒体１０６を有するクライアント１０２を含んでいる。クライアント１０２はセル電話機、デスクコンピュータ、パーソナルディジタルアシスタント又はサーバ等のコンピューティング装置を備えている。プロセッサ１０４はコンピュータ可読媒体１０６に記憶された命令をアクセス及び／又は実行することができる。コンピュータ可読媒体１０６はブラウザ１０８へのアクセスを備え又は有する。ブラウザ１０８はモジュール、プログラム、又はネットワーク使用可能なものとインタラクションを行うことができる他のものである。ブラウザ１０８は１以上のスクリプト１１０を動作させ、応答することができる。ブラウザ１０８の１つの例はウェブブラウザである。
【００１２】
また、動作環境は、クライアント１０２、ウェブサーバ１２０及びターミナルサーバ１３０と接続されたネットワーク１１２を含んでいる。ネットワーク１１２はクライアント１０２とウェブサーバ１２０との間の通信を可能にし、インターネット、又は会社のイントラネット等のグローバル又はローカルネットワーク（有線又は無線）からなる。また、ネットワーク１１２はウェブサーバ１２０とターミナルサーバ１３０との間の通信を可能にする。
【００１３】
ウェブサーバ１２０はウェブサーバプロセッサ１２２とサーバコンピュータ可読媒体１２４とを含んでいる。ウェブサーバプロセッサ１２２はサーバコンピュータ可読媒体１２４に記憶された命令をアクセス及び／又は実行することができる。コンピュータ可読媒体１２４はウェブサーバモジュール１２６及び内蔵のターミナルサーバ（ＴＳ）クライアント１２８へのアクセスを備え又は有する。図１のウェブサーバ１２０は図示のためにそれらの素子の全てと共に示されている。しかしながら、１以上のそれらの素子は各サーバ又はウェブサーバ１２０によって備えられる、ウェブサーバファームを制御する他のコンピューティング装置等の他のものに分散されても良い。
【００１４】
ターミナルサーバ１３０はターミナルサーバプロセッサ１３２とターミナルサーバコンピュータ可読媒体１３４とを含んでいる。ターミナルサーバプロセッサ１３２とはターミナルサーバコンピュータ可読媒体１３４に記憶された命令をアクセス及び／又は実行することができる。ターミナルサーバコンピュータ可読媒体１３４はターミナルサーバモジュール１３６及びデスクトップ（又はアプリケーション）１３８へのアクセスを備え又は有する。図１のターミナルサーバ１３０は図示のためにそれらの素子の全てと共に示されている。しかしながら、１以上のそれらの素子は各サーバ又はターミナルサーバ１３０によって備えられる、ターミナルサーバファームを制御する他のコンピューティング装置等の他のものに分散されても良い。
【００１５】
動作においては、クライアント１２０によって受け入れられた入力はウェブサーバ１２０に送信される。そして、ウェブサーバ１２０はその入力を内蔵のターミナルサーバクライアント１２８を用いてターミナルサーバ１３０に送信する。デスクトップ又はアプリケーション１３８からの更新済みグラフィクスはターミナルサーバ１３０からウェブサーバ１２０に送信される。内蔵のターミナルサーバクライアント１２８及びウェブサーバモジュール１２６はその更新済みグラフィクスを更新済みウェブページとしてクライアント１０２に協同して供給する。この構成の利点は、ウェブサーバが多数のターミナルサーバに接続することができることであるが、クライアントがターミナルサーバと直接通信した従来のリモートデスクトップ／ターミナルサーバシナリオに比べて、クライアント１０２とターミナルサーバ１３０との間にウェブサーバが存在するのでより大きなラテンシィ（持ち時間）がある。
【００１６】
図２は第２のそのような動作環境を２００で示している。図１に示した実施形態に比べて、この実施形態はウェブサーバ１２０からターミナルサーバ１３０までの追加のホップからの追加のラテンシィを必要としないが、動作環境２００においてはウェブサーバ１２０が同一のマシン又はサーバファーム上でターミナルサーバ１３０とインタラクションを行うことに限定される。
【００１７】
動作環境２００は１以上のクライアントプロセッサ２０４及びクライアントコンピュータ可読媒体２０６を有するクライアント２０２を含んでいる。クライアント２０２はセル電話機、デスクコンピュータ、パーソナルディジタルアシスタント又はサーバ等のコンピューティング装置を備えている。プロセッサ２０４はコンピュータ可読媒体２０６に記憶された命令をアクセス及び／又は実行することができる。コンピュータ可読媒体２０６はブラウザ２０８へのアクセスを備え又は有する。ブラウザ２０８はモジュール、プログラム、又はネットワーク使用可能なものとインタラクションを行うことができる他のものである。ブラウザ２０８は１以上のスクリプト２１０を動作させ、応答することができる。
【００１８】
また、動作環境２００は、クライアント２０２及びサーバ２２０と接続されたネットワーク２１２を含んでいる。ネットワーク２１２はクライアント２０２とサーバ２２０との間の通信を可能にし、インターネット、又は会社のイントラネット等のグローバル又はローカルネットワーク（有線又は無線）からなる。
【００１９】
サーバ２２０はサーバプロセッサ２２２とサーバコンピュータ可読媒体２２４とを含んでいる。サーバプロセッサ２２２はサーバコンピュータ可読媒体２２４に記憶された命令をアクセス及び／又は実行することができる。コンピュータ可読媒体２２４はサーバモジュール２２６、リモートデスクトップ又はアプリケーションプロセッシング（ＲＤＰ）モジュール２２８及びデスクトップ（又はアプリケーション）２３０へのアクセスを備え又は有する。再度、図２のサーバは図示のためにそれらの素子の全てと共に示されている。しかしながら、１以上のそれらの素子は各サーバ２２０ａ，２２０ｂ又はサーバ２２０によって備えられる、ウェブサーバファームを制御する他のコンピューティング装置等の他のものに分散されても良い。
【００２０】
データフロー
図３は図１に示された動作環境１００用のデータ３００のフローの実施形態例を示している。よって、図３はウェブブラウザ３１０とウェブサーバ３２０との間、及びウェブサーバ３２０とターミナルサーバ３３０との間のデータフロー３００を例示している。このデータフロー３００はユーザがウェブブラウザ３１０を介してリモートデスクトップ／リモートアプリケーション３３２とインタラクションを行うことを可能にする。
【００２１】
図３に示された実施形態において、ウェブブラウザ３１０内で動作するスクリプトはユーザ入力からの入力イベント（例えば、キーストローク及びマウスイベント）を収集し、そして、それらをネットワーク３４０を介してウェブサーバ３２０に送信する。一般に、スクリプト（例えば、図１のスクリプト１１０）は入力イベントをＨＴＴＰに変換し、ネットワーク３４０を介してＨＴＴＰの入力イベントを送信する。いくつかの実施形態では、スクリプトはＸＭＬＨＴＴＰオブジェクトを用いてデータをサーバに送信する。
【００２２】
この実施形態では、実際のリモートデスクトップ／リモートアプリケーション３３２がターミナルサーバ３３０上で動作しており、よって、ウェブサーバ３２０は内蔵のターミナルサーバ（ＴＳ）クライアント３２２を用いて入力データをターミナルサーバ３３０に中継する。よって、ウェブサーバ３２０はＨＴＴＰとＲＤＰとの間の変換層とみなすことができる。ウェブサーバ３２０はＲＤＰを介してターミナルサーバ３３０と通信するために実装した内蔵のＴＳクライアント３２２を動作させている。
【００２３】
図３に示された実施形態において、ターミナルサーバ３３０は実際のリモートデスクトップ又はリモートアプリケーション３３２が動作しているところであるので、グラフィクスデータはターミナルサーバ３３０で発生する。ターミナルサーバ３３０はでデスクトップ及び／又はアプリケーション３３２のグラフィカルな描写をウェブサーバ３２０で動作しているＴＳクライアント３２２に送信する。ウェブサーバ３２０はこのグラフィクスデータを受け取り、それをウェブブラウザ３１０が描画できる標準のイメージフォーマット（例えば、jpeg,gif，png）に変換する。そのグラフィクスデータはそしてウェブブラウザ３１０に送信され、ウェブブラウザ３１０はそのイメージを用いてデスクトップのグラフィク描写を更新する。
【００２４】
図４は図２に示された動作環境用のデータフロー４００の実施形態例を示している。よって、ウェブブラウザ４１０とサーバ４２０との間、及びサーバ４２０内のデータフロー４００を例示している。このデータフロー４００はユーザがウェブブラウザ４１０を介してリモートデスクトップ／リモートアプリケーション４２６とインタラクションを行うことを可能にする。
【００２５】
図４に示された実施形態において、ウェブブラウザ４１０内で動作するスクリプトはユーザ入力からの入力イベント（例えば、キーストローク及びマウスイベント）を収集し、そして、それらをネットワーク４４０を介してサーバ４２０に送信する。一般に、スクリプトは入力イベントをＨＴＴＰに変換し、ネットワーク４４０を介してＨＴＴＰの入力イベントを送信する。他の実施形態では、入力イベントは他の通信プロトコルを用いてサーバ４２０に送信される。
【００２６】
この実施形態において、実際のリモートデスクトップ／リモートアプリケーション４２６がウェブサーバ４２２として同一のサーバ４２０上で動作している。ウェブサーバ４２２はその入力データをユーザのセッションに関連したＲＤＰディスプレイ及び入力ドライバ４２４内の入力ドライバに中継する。ＲＤＰディスプレイ及び入力ドライバ４２４はその入力をデスクトップ又はアプリケーション４２６のユーザのセッションに送信する。
【００２７】
グラフィクスデータはウェブサーバ４２２を動作しているサーバ４２０で発生し、ここでサーバ４２０はリモートデスクトップ／リモートアプリケーション４２６を動作している同一サーバである。デスクトップ／アプリケーション４２６が変化したときその変化又は更新がウェブサーバ４２２に通知される。この時点で、ウェブサーバ４２２はＲＤＰディスプレイ及び入力ドライバ４２４に更新済みグラフィクスデータを要求する。ウェブサーバ４２２は更新済みグラフィクスデータを受信した後、そのグラフィクスデータをウェブブラウザが描画できる標準のイメージフォーマット（例えば、jpeg,gif，png）に変換する。グラフィクスデータはウェブブラウザ４１０に送信され、ウェブブラウザ４１０はそのイメージを使用してデスクトップ／アプリケーション４２６のグラフィクス描写を更新する。他の実施形態では、デスクトップ／アプリケーション４２６は更新済みグラフィクスデータをＲＤＰディスプレイ及び入力ドライバ４２４に送信する。それで、ＲＤＰディスプレイ及び入力ドライバ４２４はこのグラフィクスデータをウェブサーバ４２２に転送する。
【００２８】
ウェブブラウザでのグラフィクスのダイナミックな更新
一般的に言えば、リモートデスクトップ又はリモートアプリケーションの正確なグラフィカルな描画を維持するために、本開示の教示に応じて動作するウェブページはＨＴＴＰを介してウェブサーバからイメージを受信し、そして、変化した描画の部分をダイナミックに更新する。これはAsynchronous JavaScript + XML(AJAX)又は他の類似技術を用いることにより行うことができる。
【００２９】
例えば、図５はリモートデスクトップ又はリモートアプリケーションの正確なグラフィカルな描画を維持するために用いられるステップ５００のシリーズ例を示している。ブロック５０２では、クライアント上で動作しているウェブブラウザが新しいグラフィクスデータを要求する。例えば、ウェブブラウザで動作しているスクリプトはＸＭＬＨＴＴＰオブジェクトを用いてＨＴＴＰリクエストを作成してサーバに「新しいグラフィクスデータ」を求める。ブロック５０４では、サーバは新しいグラフィクスデータのためのリクエストを受信する。ブロック５０６では、サーバはデスクトップ又はアプリケーションのどの部分が変化したのか判別する。ブロック５０８では、サーバはデータをウェブブラウザが描画できる標準のイメージフォーマットで送り返す。
【００３０】
本開示に応じた技術を用いることにより、ウェブページはこのリクエストによりページのリフレッシュ（例えば、リローディング）なしに新しいイメージデータを得させ、ウェブブラウザを更新させる。
【００３１】
イメージ送信
本開示の技術に応じてグラフィクスデータを得るためにブラウザが用いるメカニズム又は処理の２例が図６及び図７に示されている。図６に示された例においては、ウェブブラウザはブロック６０２で「新しいグラフィクスデータ」を求める。例えば、ウェブブラウザで動作しているスクリプトはＸＭＬＨＴＴＰオブジェクトを用いてＨＴＴＰリクエストを作成して「新しいグラフィクスデータ」をサーバに求める。ブロック６０４では、サーバは新しいグラフィクスデータについてのリクエストを受信する。ブロック６０６では、サーバはデスクトップ又はアプリケーションのどの部分が変化したのか判別する。ブロック６０８では、サーバはデータをウェブブラウザが描画できる標準のイメージフォーマットで送り返す。
【００３２】
この実施形態では、サーバは、ブロック６０８では、更新済みグラフィクスデータをイメージ毎の位置情報と共にイメージＵＲＬのリストとしてブラウザに送信する。ウェブブラウザがブロック６１０でその更新済みグラフィクスデータを受信した後、そのウェブブラウザで動作するスクリプトがブロック６１２で新しい「イメージオブジェクト」を作成し、それらを正確に配置し、それらのＵＲＬを受信したファイル名のリストに合わせるウェブブラウザはブロック６１４でウェブサーバに戻ってイメージを取ってくる。
【００３３】
同様に、図７に示された例においては、ウェブブラウザはブロック７０２で「新しいグラフィクスデータ」を求める。例えば、ウェブブラウザで動作しているスクリプトはＸＭＬＨＴＴＰオブジェクトを用いてＨＴＴＰリクエストを作成して「新しいグラフィクスデータ」をサーバに求める。ブロック７０４では、サーバは新しいグラフィクスデータについてのリクエストを受信する。ブロック７０６では、サーバはデスクトップ又はアプリケーションのどの部分が変化したのか判別する。ブロック７０８では、サーバはデータをウェブブラウザが描画できる標準のイメージフォーマットで送り返す。
【００３４】
この実施形態では、サーバは、ブロック７０８では１組のイメージについての位置情報とバイナリデータ等のイメージ自身を送信することにより応答する。１つの実施形態ではバイナリデータはBase64エンコーディングを用いて送信される。ウェブブラウザはブロック７１０で更新済みグラフィクスデータを受信した後、そのウェブブラウザで動作するスクリプトがブロック７１２で新しい「イメージオブジェクト」を作成し、それらを正確に配置し、イメージのコンテンツをサーバから受信したバイナリデータにセットする。
【００３５】
更新のサイズ
イメージ更新のサイズを定める２つの可能な方法としては均等タイル、不均等タイルが用いられる。均一タイルを用いるときには、デスクトップ／アプリケーションは均等なグリッドのタイルに分割される。各タイルはインデックスを有し、ウェブページ上のＨＴＭＬ  ＤＩＶタグによって表される。このシナリオまでは、ＤＩＶはウェブページ内の位置合わせ可能なコンポーネントであると考えることができる。ＤＩＶはタイルのイメージを含んでいる。ウェブサーバがウェブブラウザにイメージデータを送信するときそのウェブブラウザで動作するスクリプトが更新しているタイルのインデックスに基づいて適切なＤＩＶにイメージを配置する。
【００３６】
不均等タイルを用いるときには、ウェブサーバは不均等なサイズのイメージをその大きさ及び座標位置と共にウェブブラウザに送信する。ウェブページは新しいイメージのためのＤＩＶを作成し、サーバによって与えられたデータに応じてそのサイズを定めて配置する。ＤＩＶがもはや可視的でないときそれは通常ウェブページから除去される。
【００３７】
ダブルバッファリング
デスクトップ／アプリケーションの更新済み部分が受信されると、それによってデスクトップ／アプリケーションの存在する部分が通常、置き換えられる。これはある状態においてＤＩＶ内で「イメージオブジェクト」が新しい「イメージオブジェクト」と書き換えられるので弱いフリッカを生じさせる。これが起きるとき全くイメージが表示されない瞬間が存在する。ダブルバッファリングはこの問題を解決するために用いられる。
【００３８】
図８はウェブページ表示を更新するために用いられる処理８００の例を示している。ブロック８０２では、デスクトップ／アプリケーションの更新済み部分が受信される。その後、ブロック８０４では、表示イメージがダブルバッファリングを用いて更新される。
【００３９】
図９はダブルバッファリング処理９００の例を示している。ダブルバッファリング処理はデスクトップ／アプリケーションを表す２層のＤＶＩを有している。デスクトップ／アプリケーションにおいてタイル毎に「トップ」としてマークされたＤＶＩと「ボトム」としてマークされたＤＶＩとがある。新しい更新がブロック９０２で受信されると、「トップ」及び「ボトム」ＤＶＩのいずれかにおいてイメージがブロック９０４で更新される。通常、「ボトム」ＤＶＩが更新される。その後、その２つのＤＶＩのｚ−ｏｒｄｅｒ（ｚ−オーダ）がブロック９０６でスワップ処理される。よって、「ボトム」ＤＶＩは更新されたならば、このＤＶＩは今、新しい「トップ」ＤＶＩとなる。
【００４０】
新しいイメージがロードすると、その他のＤＶＩが新しいＤＶＩの後ろにされるか、新しいＤＶＩのトップにされる（ブラウザがイメージ及びＤＶＩのｚ−オーダの更新をどのように扱うかに応じて定まる）。新しいイメージが一時的にブランクである場合に、他のＤＶＩがその新しいイメージの後ろにあるならば、それは透過され、又は他のＤＶＩがその新しいイメージの前にあるならば、他のＤＶＩによって暗くされる。イメージを常に見ることになるので、タイルが更新されているときに欠落したイメージのフラッシュを見ることが決してない。
【００４１】
キャッシュ処理
リモートデスクトップ／リモートアプリケーションを見るときに絶えず繰り返される多数のイメージがある。例えば、ウインドウズにおいて、デスクトップ背景又はスタートメニューは、ユーザがデスクトップとインタラクションを行う如きセッションの間、何回もビジビリティを変化する。ウェブブラウザのクライアント側のキャッシュ処理は見たコンポーネントを頻繁にキャッシュ処理することによりデスクトップにおける変化の反応に役立つ。
【００４２】
図１０及び図１１はクライアント側キャッシュ処理のためのメカニズム又は処理の２例を提供する。図１０に示された処理１０００においては、キャッシュ処理はサーバによって指示される。この状態において、サーバはブロック１００２で、ウェブブラウザに送信したタイル又はイメージのハッシュを計算する。ＣＢ６４は用いられるハッシュの１例である。
【００４３】
サーバが、ブロック１００４でタイル又はイメージがウェブブラウザによってキャッシュ処理されたことを認識したならば、タイル又はイメージを送信する代わりに、サーバはブロック１００６でイメージ識別子を用いてタイル又はイメージのキャッシュ処理したコピーを用いることをウェブブラウザに伝える。イメージ又はタイルがウェブブラウザのキャッシュに記憶されておらず、サーバがブロック１００８で同一のイメージが過去にウェブブラウザに送信されたと認識したときには、サーバはブロック１０１０でそのイメージをキャッシュ処理することをウェブブラウザに伝え、そのキャッシュ処理したアイテムを識別する識別子を備える。いくつかの実施形態では、識別子はユニーク識別子である。他の実施形態では、識別子はユーザに対して又は特定のユーザのセッションに対してユニークである。その後、ブロック１０１２でそのイメージ又はタイルはサーバによって送信される。
【００４４】
図１１はクライアント側キャッシュ処理のためのメカニズムの例を示している。図１１において、処理１１００はイメージのためにブラウザの内蔵のキャッシュ処理メカニズムを利用する。処理１１００は、ウェブブラウザ及びウェブサーバが上記及び図６に示されたようなファイルＵＲＬ方法を介してグラフィクスデータを交換するときに用いられる。この処理において、サーバはブロック１１０２でタイル又はイメージのハッシュを計算する。ＣＢ６４は適したハッシュの１例である。その後、サーバはブロック１１０４で、イメージのハッシュ値に応じてイメージファイルに名称を付ける。これをすることにより、普通に繰り返されるイメージは、同一イメージＵＲＬを常に有し、よって、同一イメージとしてウェブブラウザによって見られ、ウェブブラウザによってキャッシュ処理される。
【００４５】
ウェブブラウザでの入力バッチ処理
本開示に応じた技術を用いることにより、ウェブページはユーザがリモートアプリケーションに入力を与えることを可能にする。ウェブページはユーザからの入力イベント（キーストロークやマウスイベント等）を待ち、ウェブサーバに対してＸＭＬＨＴＴＰオブジェクトを介してＨＴＴＰリクエストを作成して、ちょうど起きた入力イベントを通知する。
【００４６】
ウェブブラウザからウェブサーバに入力を送信する簡単なアプローチは、キーストローク及びマウスイベントを監視し、入力イベント毎にＸＭＬＨＴＴＰオブジェクトを介してサーバにＨＴＴＰリクエストを作成することである。入力は通常非常に頻繁に生ずるので（ユーザがマウスをちょうど動かしたときどのくらいのイベントが発生されるのか想像される）、入力イベント毎に別々のリクエストを作成することは非常に効率が悪いことである。
【００４７】
イベント毎に１つのリクエストを作成する代わりに、入力バッチ処理が用いられる。図１２はリモートアプリケーションに入力バッチ処理を施すために用いられる処理１２００の例を示している。図１２に示されたバッチ処理の実施形態において、処理１２００はブロック１２０２で入力イベントを待つ。入力イベントを受信した後、ブロック１２０４でＸＭＬＨＴＴＰオブジェクトの有効性がチェックされる。いくつかの実施形態では、ＸＭＬＨＴＴＰオブジェクトの有効性のチェックの前に、所定時間又は所定数の入力イベントを待つことが望まれる。ＸＭＬＨＴＴＰオブジェクトが使用されていないならば、ブロック１２０６で累積された入力データがウェブサーバに送信される。ＸＭＬＨＴＴＰオブジェクトが使用されているならば（すなわち、過去の入力イベントの処理又は送信途中にある）、ブロック１２０４で入力データが累積される。
【００４８】
このメカニズムは、ＨＴＴＰコネクションのときにできるだけ多くのデータを送信することによりＨＴＴＰコネクションの使用を最大化する。有効性があるＸＭＬＨＴＴＰオブジェクトの限界数に応じて、グラフィクスを受信し入力を送信するために別々のＸＭＬＨＴＴＰオブジェクトを使用することは良い方法である。これはグラフィクス及び入力が並行して送信及び受信されることを可能にする。入力データはウェブブラウザにおいてリスト又はアレイ型のデータ構造で累積される。
【００４９】
いくつかの実施形態では、ＸＭＬＨＴＴＰオブジェクトは送信するデータを終了するとき、そのデータ構造をチェックし、データ構造内に有効なデータがあるならば新しいリクエストを発生するか、リクエストを再発生する。ＨＴＴＰリクエストがウェブサーバに対して発生される場合には、各入力イベントがＵＲＬにエンコードされる。その各入力イベントはそれらのパラメータの名称の最後にユニークＩＤをタグ化することにより互いに区別される。そのＩＤはバッチ処理において１つの入力イベントを他のものから区別するため、ユーザによって発生されたイベントの順番を維持するように順番情報を提供するために用いられる。
【００５０】
次はイベントＵＲＬの例である。  
eventType=input&ioType_0=keyDown&keyCode_1=200&i
oType_1=keyUp&keyCode_2=200&ioCount=2
【００５１】
この場合には、ユーザはkeyCode 200でキーを押し、続いてキーを放した。ウェブサーバはそのeventTypeフィールドを見てそのリクエストが入力のためであるかを判断する。ioCountを見て各入力イベントを見つけるために０から(ioCount-1)までの全てのioTypeを尋ねる。
【００５２】
結論
上記したシステム及び方法は、リモートデスクトップ又はリモートアプリケーションのソフトウエア又はプラグインをインストールする必要なしにブラウザを用いてリモートデスクトップ又はリモートアプリケーションをユーザがアクセスすることができる。本明細書で説明された技術及び他の技術は、サーバ及びサーバシステムのより大きな有用性を潜在的に与える技術分野の現在の状況を越える重要な改良、減少したバンド幅コスト、及びリモートデスクトップ又はリモートアプリケーションとの改良したクライアント体験を提供する。このシステム及び方法は構成上の特徴及び／又は方法論的な動作に特有の言語で説明されているが、添付の特許請求の範囲に定義されたシステム及び方法が説明された特有の特徴及び動作に必ずしも限定されないことは理解されるべきである。むしろ、特有の特徴及び動作は請求項のシステム及び方法を実施する形態例として開示されている。
【図１】
2010531488.tif 000003
【図２】
2010531488.tif 000004
【図３】
2010531488.tif 000005
【図４】
2010531488.tif 000006
【図５】
2010531488.tif 000007
【図６】
2010531488.tif 000008
【図７】
2010531488.tif 000009
【図８】
2010531488.tif 000010
【図９】
2010531488.tif 000011
【図１０】
2010531488.tif 000012
【図１１】
2010531488.tif 000013
【図１２】
2010531488.tif 000014
【国際調査報告】
2010531488.tif 000015
2010531488.tif 000016
2010531488.tif 000017