特許 6228916 携帯電話の遠隔制御及び閲覧方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6228916

(24)【登録日】2017年10月20日

(45)【発行日】2017年11月8日

(54)【発明の名称】携帯電話の遠隔制御及び閲覧方法及びシステム

(51)【国際特許分類】

   H04M 1/00 20060101AFI20171030BHJP

   H04W 4/18 20090101ALI20171030BHJP

【ＦＩ】

   H04M1/00 U

   H04W4/18

【請求項の数】18

【全頁数】36

(21)【出願番号】特願2014-519630(P2014-519630)

(86)(22)【出願日】2012年7月12日

(65)【公表番号】特表2014-522157(P2014-522157A)

(43)【公表日】2014年8月28日

(86)【国際出願番号】GB2012051646

(87)【国際公開番号】WO2013011280

(87)【国際公開日】20130124

【審査請求日】2015年7月10日

(31)【優先権主張番号】1112204.1

(32)【優先日】2011年7月15日

(33)【優先権主張国】GB

(73)【特許権者】

【識別番号】512269742

【氏名又は名称】リアル ヴィエヌシー リミテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ハゲット，サイモン ジェームス

(72)【発明者】

【氏名】テーラー，エイドリアン アラスター

【審査官】 望月 章俊

(56)【参考文献】

【文献】 欧州特許出願公開第２２３７５２６（ＥＰ，Ａ１）

【文献】 特開２００４−１７９６７９（ＪＰ，Ａ）

【文献】 特開２００６−３３２９３（ＪＰ，Ａ）

【文献】 特開２０１０−１７１６７０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｍ１／００

Ｈ０４Ｗ４／１８

(57)【特許請求の範囲】

【請求項1】

モバイル装置がリモート端末にリンクされるセッションを改良するシステムであって、
モバイル装置と、
リモート端末と、
前記リモート端末と前記モバイル装置とを接続するデータリンクと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記モバイル装置が前記リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットであって、静的パラメータと動的パラメータとの双方を有する前記パラメータセットを規定し、
当該システムは、
前記モバイル装置と前記リモート端末との間のライブセッションのパフォーマンスを評価し、
前記パラメータセットからのパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
必要に応じて終了まで前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
当該システムは、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるよう構成されるシステム。

【請求項2】

前記パラメータセットは、前記モバイル装置からキャプチャされて送信されたイメージデータが前記リモート端末上に正しく表示されることを保証するため、イメージスケーリングパラメータを有し、
前記特定は、前記イメージスケーリングパラメータに対する変更が適切である場合、前記変更の特定を優先させる、請求項１記載のシステム。

【請求項3】

セッションのパフォーマンスは、フレームレンダリングメトリック又はピクセルスループットメトリックから選ばれる１以上のパフォーマンスメトリックを利用することによって評価される、請求項１又は２記載のシステム。

【請求項4】

セッションのパフォーマンスは、前記１以上のパフォーマンスメトリックと閾値とを比較することによって評価され、
前記変更を特定するステップは、前記パフォーマンスメトリックが前記閾値以下に低下することに依存する、請求項３記載のシステム。

【請求項5】

当該システムは、前記パフォーマンスが前記閾値以上であるときに終了が発生するように構成される、請求項４記載のシステム。

【請求項6】

当該システムは、所定の期間後に終了が発生するよう構成される、請求項１乃至５何れか一項記載のシステム。

【請求項7】

当該システムは、異なるシナリオにおいて有効であるすべての変更を記述するルールセットを格納するデータベースを有し、
当該システムは、前記ルールセットから有効な変更を選択することによってパラメータに対する変更を特定するよう構成される、請求項１乃至６何れか一項記載のシステム。

【請求項8】

前記ルールセットは、静的ルールと動的ルールとにグループ化される、請求項７記載のシステム。

【請求項9】

イメージスケーリングパラメータに対する変更は、前記静的ルールの範囲内であり、
当該システムは、前記動的ルールの前に前記静的ルールを考慮するよう構成され、
前記特定は、前記イメージスケーリングパラメータに対する変更が適切である場合、前記変更の特定を優先させる、請求項８記載のシステム。

【請求項10】

前記パラメータセットはさらに、ピクセルフォーマットと符号化との１以上を有する、請求項１乃至９何れか一項記載のシステム。

【請求項11】

当該システムは、前記ピクセルフォーマットのパラメータの変更が、前記モバイル装置と前記リモート端末との双方について前記リモート端末により利用されるピクセルフォーマットを採用することを特定する、請求項１０記載のシステム。

【請求項12】

前記再評価されたパフォーマンスが以前に評価されたパフォーマンスを下回ると、前記変更がリバースされる、請求項１乃至１１何れか一項記載のシステム。

【請求項13】

前記モバイル装置又は前記リモート端末の少なくとも１つは、入力システムを有し、
ユーザは、前記モバイル装置又は前記リモート端末の前記入力システムにキャリブレーション段階に対するリクエストを入力する、請求項１乃至１２何れか一項記載のシステム。

【請求項14】

前記モバイル装置のプロセッサは、当該システムの評価、変更、再評価及び採用ステップを実現するよう構成される、請求項１乃至１３何れか一項記載のシステム。

【請求項15】

前記リモート端末のプロセッサは、当該システムの評価、変更、再評価及び採用ステップを実現するよう構成される、請求項１乃至１４何れか一項記載のシステム。

【請求項16】

モバイル装置がリモート端末にリンクされるセッションを改善するよう構成されるモバイル装置であって、
プロセッサと、
当該モバイル装置をリモート端末に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記モバイル装置がディスプレイ上に現在表示されるデータのイメージをキャプチャ及び送信するため、リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットであって、静的パラメータと動的パラメータとの双方を有する前記パラメータセットを規定し、
前記プロセッサは、
前記モバイル装置と前記モバイル装置が接続可能な前記リモート端末との間のライブセッションのパフォーマンスを評価し、
前記パラメータセットからのパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
前記プロセッサは、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるよう構成されるモバイル装置。

【請求項17】

リモート端末がモバイル装置にリンクされるセッションを改善する方法であって、
前記リモート端末とモバイル装置との間のライブセッションのパフォーマンスを評価するステップであって、前記リモート端末、前記モバイル装置及び前記モバイル装置と前記リモート端末とを接続するよう構成されるデータリンクは、前記セッションのパフォーマンスを決定するパラメータセットを規定する、前記評価するステップと、
静的パラメータと動的パラメータとの双方を含む前記パラメータセットからのパラメータに対する変更を特定するステップと、
前記特定されたパラメータを変更するステップと、
前記変更されたパラメータに基づきパフォーマンスを再評価するステップと、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用するステップと、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すステップと、
を有し、
前記方法は更に、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるステップを有する方法。

【請求項18】

プロセッサ上で実現されると、請求項１７記載の方法を前記プロセッサに実行させるプロセッサ制御コードを担持するキャリア。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、携帯電話又は同様の小型携帯装置を遠隔制御及び／又は閲覧する方法及びシステムに関する。

【背景技術】

【0002】

リモートコンピュータ端末（ＶＮＣビューワ）と携帯電話（ＶＮＣサーバ）との双方において実行されるバーチャルネットワークコンピューティング（ＶＮＣ）アプリケーションを利用して携帯電話を閲覧及び制御するためリモートコンピュータ端末を利用することが知られている。モバイル装置のディスプレイのコンテンツは、リモートコンピュータ端末上に複製される。リモートコンピュータ端末は、ユーザがデバイス上の物理的キーの押下やタッチ画面入力のタッチなどのユーザ入力イベントを制御されているモバイル装置に送信することを可能にするインタフェース機構を有する。理解されるように、データリンクの形式及びリモートコンピュータ端末の性質は、利用される状況に応じて変化しうる。

【0003】

リモートコンピュータ端末は、サポートエンジニアがリモート制御機能を利用して携帯電話を利用する顧客にデバイスサポートを提供するためのものであってもよい。顧客や企業がピクチャメッセージを送信することができないなどの携帯電話による問題に遭遇する場合、サポートエンジニアは、リモート端末を利用することによって電話を確認又はやりとりすることによって問題を診断及び修復することができる。あるいは、サポートエンジニアは、リモート端末を利用してユーザの携帯電話にソフトウェア又は他の設定をインストール又はアップデートするかもしれない。この状況では、データリンクは、典型的には、ＷｉＦｉ、ＧＰＲＳ又はＨＳＤＰＡなどのある形態の無線通信を介するものであり、リモート端末は、携帯電話から数百マイル離れた長距離であってもよい。

【0004】

あるいは、リモート端末は、例えば、自動車産業などでは携帯電話の近くに配置されてもよい。リモート端末は、自動車のダッシュボードに備えられた大型ディスプレイとして埋め込まれたヘッドユニットであってもよい。ユーザの電話のよく知られたインタフェースがディスプレイに示され、ユーザはこのインタフェースを利用して、音楽を再生し、又は地図ベースナビゲーションを実行することができる。典型的には、ユーザが運転中にリモート端末を用いてコンピュータゲームなどの気を散らすアプリケーションを制御することを防ぐための追加的なセーフティ機構がある。この状況では、データリンクは、典型的には、ＵＳＢなどの物理配線された接続又はＷｉＦｉやブルートゥースなどの短距離無線通信システムを介したものであろう。

【0005】

特に、限定することなく、自動車設定では、モバイル装置及びリモート端末（すなわち、ヘッドユニット）は、典型的には、広範なハードウェア仕様を有することが可能なリソースが制約された装置である。さらに、ＶＮＣセッションのサポートと共に、モバイル装置とヘッドユニットとは共に、装置のリソースに対して競合する１以上のサードパーティアプリケーションを実行する可能性がある。これらのアプリケーションはまた、ＶＮＣセッションをサポートするのに利用可能な帯域幅に影響を与えるモバイル装置とヘッドユニットとの間のインタフェースを利用する可能性がある。

【0006】

ＶＮＣセッションは、複数のパラメータのコンフィギュレーションを要求する。これらのパラメータの多くは、ＶＮＣサーバとＶＮＣビューワとの間のネゴシエーションを要求し、いくつかのパラメータはいずれかのサイドによって必須とされる可能性がある。ＶＮＣセッションのパフォーマンスにおける１つのキーファクタは、当該セッションにより利用されるコンフィギュレーションパラメータである。ピクセルフォーマット、符号化及び暗号化などの性質はすべて、コンフィギュレーションパラメータを介し変更可能である。これらのパラメータの一部は、特定のシナリオについて必須の値である必要があるが、他のものはパフォーマンスを最適化するため調整可能である。

【0007】

ＶＮＣセッション中、ＶＮＣビューワは、ピクセルデータが特定のフォーマット及び符号化タイプで提供されることを要求する。ピクセルフォーマットは、ピクセルがどのように記述されるべきか規定する。それは、ピクセルを記述するのに利用されるビット数と、赤色、緑色及び青色コンポーネント情報がどのように符号化されるかとを指定する。ピクセルを記述するのに利用されるビット数が多くなるに従って、ＶＮＣセッションを介し通信可能なカラーのシェードがより明確になる。しかしながら、ビット数の増加はまた、フレームバッファアップデートを示すためＶＮＣサーバからＶＮＣビューワに転送される必要があるデータ量を増加させる。

【0008】

符号化タイプは、ピクセルデータがどのようにＶＮＣサーバによって送信されるべきか規定する。符号化タイプは、ピクセルデータの圧縮を実行可能であり、配線を介し送信されるバイト数を低減する。例えば、ピクセルデータは、ＪＰＥＧ符号化圧縮画像フォーマットを利用して符号化できる。しかしながら、ピクセルデータの圧縮はフレームバッファアップデートを示すのに必要とされるバイト数を減少させる一方、これはまた、データを符号化及び復号化するためＶＮＣセッションの双方のサイドにおける追加的なＣＰＵリソースを要求する。

【0009】

図１において、パラメータを動的に調整するための１つの手段が示され、以下においてより詳細に説明される。図１において、ピクセルフォーマット及び符号化タイプは、パフォーマンスメトリック、すなわち、Ｌｉｎｅ Ｓｐｅｅｄ Ｅｓｔｉｍａｔｅ（ＬＳＥ）に従って調整される。

【0010】

本願出願人は、ベストパフォーマンスを達成可能なＶＮＣセッションパラメータセットが、サーバ及びビューワプラットフォームハードウェアの性質、ビューワとサーバとを接続するインタフェースのスピード及びサードパーティアプリケーションにより提供される影響に大きく依存することを認識した。これに関して、本願出願人は、携帯電話を遠隔制御する改良された方法及びシステムが要求されることを認識した。

【発明の概要】

【0011】

本発明の第１の態様によると、モバイル装置がリモート端末にリンクされるセッションを改良するシステムであって、
プロセッサとユーザにデータを表示するディスプレイとを有するモバイル装置と、
リモート端末と、
前記リモート端末と前記モバイル装置とを接続するデータリンクと、
を有し、
前記モバイル装置のプロセッサは、
前記ディスプレイ上に現在表示されるデータのイメージをキャプチャし、
前記データリンクを介し前記キャプチャされたイメージデータを送信するよう構成され、
前記リモート端末は、
ユーザにデータを表示するディスプレイと、
前記モバイル装置から前記キャプチャされたイメージデータを受信し、前記リモート端末のディスプレイ上に前記イメージデータを表示し、これにより、前記モバイル装置のディスプレイからのデータが前記リモート端末のディスプレイ上に複製されるよう構成されるプロセッサと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記モバイル装置が前記リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットであって、静的パラメータと動的パラメータとの双方を有する前記パラメータセットを規定し、
当該システムは、
前記モバイル装置と前記リモート端末との間のセッションのパフォーマンスを評価し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
必要に応じて終了まで前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
前記パラメータセットは、前記モバイル装置からキャプチャされたイメージデータが前記リモート端末上に正しく表示されることを保証するためのイメージスケーリングパラメータを有し、前記特定ステップは、前記イメージスケーリングパラメータに対する変更が適切である場合、前記変更の特定を優先させるシステムが提供される。

【0012】

本発明の第２の態様によると、リモート端末がモバイル装置にリンクされるセッションを改善する方法であって、
前記リモート端末とモバイル装置との間のセッションのパフォーマンスを評価するステップであって、前記リモート端末、前記モバイル装置及び前記モバイル装置と前記リモート端末とを接続するよう構成されるデータリンクは、前記セッションのパフォーマンスを決定するパラメータセットを規定する、前記評価するステップと、
前記パラメータセットからパラメータに対する変更を特定するステップと、
前記特定されたパラメータを変更するステップと、
前記変更されたパラメータに基づきパフォーマンスを再評価するステップと、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用するステップと、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すステップと、
を有し、
前記パラメータセットは、前記モバイル端末からキャプチャ及び送信されるイメージデータが前記リモート端末上に正しく表示されることを保証するためのイメージスケーリングパラメータを有し、前記特定ステップは、前記イメージスケーリングパラメータに対する変更が適切である場合、前記変更の特定を優先させる方法が提供される。

【0013】

以下の特徴は、方法とシステムとの双方に適用される。

【0014】

本システム及び方法は、従って、ＶＮＣセッションパラメータのセットを介しループし、最良のパフォーマンスを提供するパラメータが選択されることを可能にする。パラメータセットは、ＶＮＣセッションの性質から決定されてもよく、モバイル装置及びリモート端末のプラットフォームハードウェアの性質、モバイル装置及びリモート端末を接続するデータリンクのスピード及びサードパーティアプリケーションにより提供される影響を含むものであってもよい。

【0015】

モバイル装置によって、それはポータブルな任意の装置を意味し、これは、携帯電話、ＰＤＡ、ラップトップ、タブレット及び同様の装置を含む。リモート端末によって、それは、モバイル装置から物理的に遠隔の任意の装置を意味する。リモート端末は、モバイル装置からかなり離れた距離に配置されるか、又は近くに配置されてもよい（双方とも車両内など）。モバイル装置は、リモート端末上で視聴される情報を送信するため、ＶＮＣサーバと呼ばれてもよい。リモート端末はまた、ＶＮＣビューワと呼ばれてもよい。これらの用語は、本明細書を通じて互換的に利用される。

【0016】

自動車のシナリオで特に用いられるリモート端末は、モバイル装置によって提供されるスクリーンを異なるサイズにスケーリングする必要がある。このスケーリング処理は、ＣＰＵを多く利用しうる。従って、イメージスケーリングの考慮が本発明により優先される。しかしながら、リモート端末が高速なＣＰＵ又は専用のグラフィックスハードウェアを有するプラットフォーム上で実行されているときなど、イメージスケーリングを変更する必要がない場合、何れの変更も特定されない。この場合、イメージスケーリングは、パフォーマンスに対する影響を有すべきでない。しかしながら、リモート端末は、これらのリソースが欠落したリソースに制約のある埋め込み装置上で実行されているかもしれず、この場合、イメージスケーリングはパフォーマンスに対して強力な影響を有する可能性がある。従って、これらのシナリオでは、システムは、ターミナル装置がイメージをスケーリングすることから携帯電話がイメージをスケーリングすることへの変更を特定してもよい。Ｓａｍｓｏｎ Ｎｅｘｕｓ Ｓなどの多くの最近のモバイル装置は、パフォーマンスに影響を与えることなくイメージスケーリングを可能にするのに十分なハードウェアリソースを有する。従って、携帯電話がそれをビューワに送信する前にそれのサーバデスクトップイメージをスケーリングするよう指示する携帯電話スケーリングパラメータを導入することが有用であるかもしれない。

【0017】

すなわち、ターミナル装置のプロセッサがデータを表示する前に受信したキャプチャされたイメージデータをスケーリングするよう構成される場合、システムは、イメージスケーリングパラメータの変更がキャプチャされたイメージデータの送信前にイメージをスケーリングするよう携帯電話のプロセッサを設定し、これにより、ターミナル装置がスケーリングされた受信したイメージデータを単に表示するよう構成されることを特定してもよい。あるいは、携帯電話のプロセッサがキャプチャされたイメージデータの送信前にキャプチャされたイメージデータをスケーリングするよう構成される場合、システムは、イメージスケーリングパラメータの変更がデータの表示前に受信したキャプチャされたイメージデータをターミナル装置のプロセッサがスケーリングするよう設定することを特定してもよい。イメージスケーリングは、装置間でスイッチできる。

【0018】

キャプチャされたイメージデータは、フレームバッファアップデートの形式を有してもよく、パラメータセットは、フレームバッファ比較パラメータを有してもよい。セッションの一部として、携帯電話が直近のフレームバッファアップデートから変更されたスクリーンのエリアのみを記述することによって、フレームバッファアップデートを最小限にするよう試みることが知られている。これは、携帯電話が現在状態のフレームバッファと前の状態のフレームバッファとの間の比較を行うことを要求する。一部のケースでは、これらの比較により受けるオーバヘッドは、スクリーン全体がフレームバッファアップデートにおいて単に示される場合より、パフォーマンスに対してより強力な悪影響を有しうる。このような場合、システムは、フレームバッファ比較パラメータの変更が比較ステップを不可にすることを特定してもよい。これは、携帯電話サイドの処理を解放するかもしれない。あるいは、利用可能な十分な処理がある場合、システムは、フレームバッファ比較パラメータの変更が比較ステップを有効にすることを特定してもよい。

【0019】

パラメータセットはさらに、ピクセルフォーマット及び符号化の１以上を有してもよい。特定可能なこれらのパラメータのそれぞれに対して各種の可能な変更がある。例えば、ピクセルフォーマットに対する変更は、モバイル装置とリモート端末との双方についてモバイル装置により利用されるピクセルフォーマットを採用するものであってもよい。あるいは、ピクセルフォーマットに対する変更は、モバイル装置とリモート端末との双方についてリモート端末により利用されるピクセルフォーマットを採用するものであってもよい。ピクセルフォーマットに対する他の変更は、モバイル装置とリモート端末との双方においてよりコンパクトなピクセルフォーマットを採用するものであってもよい。符号化タイプに対する変更は、より高い又はより低い圧縮レベルを有する符号化にスイッチするものであってもよい。

【0020】

セッションのパフォーマンスは、フレームレンダリングメトリック又はピクセルスループットメトリックを含む非網羅的なリストから選ばれる１以上のパフォーマンスメトリックを利用することによって、評価（及び再評価）されてもよい。フレームレンダリングは、毎秒ビューワによりレンダリングされるフレームの平均数を測定する。ピクセルスループットは、毎秒ビューワにより受信されるピクセルの平均数を測定する。

【0021】

セッションのパフォーマンスは、１以上のパフォーマンスメトリックと閾値とを比較することによって評価され、パフォーマンスメトリックが閾値を上回る場合、何れの変更も特定されないようにしてもよい。このように、繰り返しのループが終了されてもよい。パフォーマンスメトリックが閾値を下回る場合、変更が特定され、パフォーマンスを最適化することを試みるよう実現される。

【0022】

システムは、パフォーマンスが上述された閾値に到達すると、繰り返し処理を終了するよう構成されてもよい。これは、評価、特定、変更、再評価及び採用ステップの１回のパスの後、すなわち、繰り返しステップなしに行われてもよい。システムは、所定の期間後又は所定数の繰り返し後自動的に終了が行われるように設定されてもよい。

【0023】

１つの通常の最適化問題は、特定のコンフィギュレーションが局所最大条件を導く可能性があり、増分的な変化がパフォーマンスの減少をもたらすということである。従って、システムは、局所最大に到達すると、繰り返し処理を終了するよう構成されてもよい。パフォーマンスはまた、閾値を上回るが、そうである必要はない。あるいは、局所最大に到達すると、システムは、ルールセットから有効な変更をランダムに選択し、ランダムに選択された変更を実現し、評価ステップをループバックするよう構成されてもよい。すなわち、ランダムに選択された変更は、好ましくは、当該変更に基づくパフォーマンスの再評価なしに実現される。

【0024】

システムは、ライブセッション中にモバイル装置とリモート端末との間でセッションのパフォーマンスを定期的に評価するよう構成されてもよい。すなわち、アプローチは、アクティブなセッションのパラメータを調整する動的なものである。これは、特定の接続の正確な条件にシステムが調整されることを可能にする効果を有する。しかしながら、セッション中のパラメータの変更は、所望されないユーザにより認識可能であるかもしれない。

【0025】

従って、本発明の他の態様によると、モバイル装置がリモート端末にリンクされるセッションを改良するシステムであって、
モバイル装置と、
リモート端末と、
前記リモート端末と前記モバイル装置とを接続するデータリンクと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記モバイル装置が前記リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットであって、静的パラメータと動的パラメータとの双方を有する前記パラメータセットを規定し、
当該システムは、
前記モバイル装置と前記リモート端末との間のライブセッションのパフォーマンスを評価し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
必要に応じて終了まで前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
当該システムは、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるよう構成されるシステムが提供される。

【0026】

本発明の他の態様によると、リモート端末がモバイル装置にリンクされるセッションを改善する方法であって、
前記リモート端末とモバイル装置との間のライブセッションのパフォーマンスを評価するステップであって、前記リモート端末、前記モバイル装置及び前記モバイル装置と前記リモート端末とを接続するよう構成されるデータリンクは、前記セッションのパフォーマンスを決定するパラメータセットを規定する、前記評価するステップと、
静的パラメータと動的パラメータとの双方を含む前記パラメータセットからパラメータに対する変更を特定するステップと、
前記特定されたパラメータを変更するステップと、
前記変更されたパラメータに基づきパフォーマンスを再評価するステップと、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用するステップと、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すステップと、
を有し、
前記プロセッサは、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるよう構成される方法が提供される。

【0027】

適切である場合、上記及び下記に特定される任意的な特徴が、ライブセッションが評価される上記態様の双方に適用される。

【0028】

あるいは、システムは、セッションが実行中でないとき、すなわち、セッションが開始される前、モバイル装置とリモート端末との間のセッションのパフォーマンスを評価するよう構成されてもよい。このアプローチは、変更すべき動的なパラメータがないため、静的解析サーチとみなされてもよい。当該アプローチは、最初の接続時に１回だけ実行されてもよい。結果としてのセッションパラメータは、２つの同一の装置の間の以降の核接続に対してサーチを実行する必要を回避するため、キャッシュされてもよい。この場合、パフォーマンスが改善された場合、特定されたパラメータの変更を採用するステップは、特定されたパラメータの変更を適切なパフォーマンスプロファイルに含めることを含むものであってもよい。

【0029】

従って、本発明の他の態様によると、モバイル装置がリモート端末にリンクされるセッションを改善するシステムであって、
モバイル装置と、
リモート端末と、
前記リモート端末と前記モバイル装置とを接続するデータリンクと、
を有し、
当該システムは、
前記リモート端末と前記モバイル装置とのそれぞれについて、前記モバイル装置が前記リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットを含むパフォーマンスプロファイルを決定し、
ライブセッションがない間、前記モバイル装置と前記リモート端末との間のセッションのパフォーマンスを推定し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づき前記推定を再評価し、
パフォーマンスが改善している場合、前記特定されたパラメータの変更を前記適切なパフォーマンスプロファイルに含め、
終了まで必要に応じて前記推定、特定、変更、再評価及び採用ステップを繰り返し、
前記モバイル装置と前記リモート端末とについて前記変更されたパフォーマンスプロファイルを格納するよう構成されるシステムが提供される。

【0030】

本発明の他の態様によると、リモート端末がモバイル装置にリンクされるセッションを改善する方法であって、
前記リモート端末と前記モバイル装置とのそれぞれについて、前記モバイル装置上に現在表示されるデータのイメージを受信及び表示するため、前記リモート端末がモバイル装置にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットを含むパフォーマンスプロファイルを決定するステップと、
前記リモート端末と前記モバイル装置との間のセッションのパフォーマンスを、ライブ接続がない間に推定するステップと、
前記パラメータセットからパラメータに対する変更を特定するステップと、
前記特定されたパラメータを変更するステップと、
前記変更されたパラメータに基づき前記推定を再評価するステップと、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を前記適切なパフォーマンスプロファイルに含めるステップと、
終了まで必要に応じて前記推定、特定、変更、再評価及び採用ステップを繰り返すステップと、
前記モバイル装置と前記リモート端末とについて前記変更されたパフォーマンスプロファイルを格納するステップと、
を有する方法が提供される。

【0031】

適切である場合、上記及び下記に特定された任意的な特徴が、ライブセッションが実行されていないこれらの双方の態様に適用される。

【0032】

各変更は、ルールセットとして決定される特定のシナリオにおいて適している可能性のあるアクションとみなされてもよい。各アクションは、改善された（好ましくは、最適な）パフォーマンスに進むためのステップを提供するべきである。従って、各アクションは、パフォーマンスレベルの低下をもたらす場合、リバース（又はバックトラック）されるべきである。再評価されたパフォーマンスが前に評価されたパフォーマンスを下回る場合、当該変更は採用されず、リバースされ、本方法は繰り返しステップに移行する。

【0033】

必ずしもすべての変更（アクション）が、すべてのシナリオにおいて有効であると限らない。従って、システムは、異なるシナリオにおいて有効であるすべてのアクションを記述するルールセットを格納するデータベースを有してもよい。例えば、リモート端末がハードウェアイメージスケーリングサポートを有しない場合、ハードウェアイメージスケーリングをリモート端末に委託するための変更は有効でない。ルールは、静的制約（ハードウェアコンフィギュレーションなど）により課される条件に対して作用する静的ルールと、動的制約（携帯電話又はリモート端末の一方又は双方におけるＣＰＵ利用など）に対して採用する動的ルールとの２つのタイプにグループ化されてもよい。ライブセッションがない場合、静的制約のみが考慮されてもよい。

【0034】

イメージスケーリングパラメータに対する変更は、静的ルール内でリストされ、システムは、動的ルールの前に静的ルールを考慮するよう構成され、特定ステップは、イメージスケーリングパラメータに対する変更が適切である場合、当該変更の特定を優先させる。静的ルールのみが考慮される場合、イメージスケーリングパラメータは、それが考慮すべき最初のパラメータであることを保証することによって優先されてもよい。

【0035】

キャリブレーション段階が、任意の時点、セッション前若しくはセッション中又はその双方においてユーザにより開始されてもよい。キャリブレーション段階がセッション前に開始される場合、静的解析サーチが実行されてもよく、又はモバイル装置とリモート端末との間のライブテストセッションが、動的評価が実行されるように開始されてもよい。

【0036】

上述されるように、当該解析は、完全に静的であってもよく、すなわち、ライブセッション又はライブテストセッションなしであってもよい。この場合、システムは、リモート端末とモバイル装置とのそれぞれについてパフォーマンスプロファイルを決定し、決定されたパフォーマンスプロファイルに関連するコストを推定するよう構成されてもよい。システムは、パフォーマンスボトルネックを決定し、当該ボトルネックを用いてパラメータに対する変更を特定することによって、パフォーマンスを推定するよう構成されてもよい。ボトルネックの特定は、まず帯域幅を推定し、推定した帯域幅と閾値とを比較し、推定された帯域幅が閾値以下である場合、帯域幅のボトルネックが存在すると判断することによって、実行されてもよい。推定された帯域幅が閾値以上である場合、システムは、モバイル装置とリモート端末との双方におけるプロセッサの利用を推定し、推定されたプロセッサの利用を比較し、推定されたモバイル装置のプロセッサの利用が推定されたリモート端末のプロセッサの利用より高い場合、又はその反対である場合、モバイル装置におけるプロセッサの利用のボトルネックが存在すると判断するよう構成されてもよい。

【0037】

システムは、携帯電話のプロセッサ及び／又はリモート端末のプロセッサを利用することによって、各種ステップを実現するよう構成されてもよい。従って、リモート端末のプロセッサ及び／又はモバイル装置のプロセッサは、システムの評価、特定、変更、再評価及び採用ステップを実現するよう構成されてもよい。

【0038】

従って、本発明の他の態様によると、モバイル装置がリモート端末にリンクされるセッションを改善するよう構成されるモバイル装置であって、
プロセッサと、
ユーザにデータを表示するディスプレイと、
当該モバイル装置をリモート端末に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記ディスプレイ上に現在表示されるデータのイメージをキャプチャ及び送信するため、前記モバイル装置が前記リモート端末にリンクされると、セッションのパフォーマンスを決定するパラメータセットを定義し、
前記プロセッサは、
前記モバイル装置と前記モバイル装置が接続可能なリモート端末との間のセッションのパフォーマンスを評価し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
前記パラメータセットは、前記モバイル装置からキャプチャされたイメージデータが前記リモート端末上に正しく表示されることを保証するためのイメージスケーリングパラメータを有し、
前記特定ステップは、前記イメージスケーリングパラメータに対する変更が適切である場合、前記変更の特定を優先させるモバイル装置が提供される。

【0039】

本発明の他の態様によると、モバイル装置がリモート端末にリンクされるセッションを改善するよう構成されるモバイル装置であって、
プロセッサと、
当該モバイル装置をリモート端末に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記プロセッサは、
前記リモート端末と前記モバイル装置とのそれぞれについて、前記モバイル装置が前記リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットを含むパフォーマンスプロファイルを決定し、
前記モバイル装置と前記モバイル装置が接続可能なリモート端末との間のセッションのパフォーマンスを、前記モバイル装置と前記リモート端末との間のライブ接続がない間に推定し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づき前記推定を再評価し、
パフォーマンスが改善している場合、前記特定されたパラメータの変更を前記適切なパフォーマンスプロファイルに含め、
終了まで必要である場合、前記推定、特定、変更、再評価及び採用ステップを繰り返し、
前記モバイル装置と前記リモート端末とについて前記変更されたパフォーマンスプロファイルを格納するよう構成されるモバイル装置が提供される。

【0040】

本発明の他の態様によると、モバイル装置がリモート端末にリンクされるセッションを改善するよう構成されるモバイル装置であって、
プロセッサと、
当該モバイル装置をリモート端末に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記モバイル装置がディスプレイ上に現在表示されるデータのイメージをキャプチャ及び送信するため、リモート端末にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットであって、静的パラメータと動的パラメータとの双方を有する前記パラメータセットを規定し、
前記プロセッサは、
前記モバイル装置と前記モバイル装置が接続可能な前記リモート端末との間のライブセッションのパフォーマンスを評価し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
前記プロセッサは、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるよう構成されるモバイル装置が提供される。

【0041】

本発明の他の態様によると、リモート端末がモバイル装置にリンクされるセッションを改善するよう構成されるリモート端末であって、
プロセッサと、
ユーザにデータを表示するディスプレイと、
当該リモート端末をモバイル装置に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記モバイル装置上に現在表示されるデータのイメージを受信及び表示するため、前記リモート端末がモバイル装置にリンクされるとき、セッションのパフォーマンスを決定するパラメータセットを定義し、
前記プロセッサは、
前記リモート端末と前記リモート端末が接続可能なモバイル装置との間のセッションのパフォーマンスを評価し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
前記パラメータセットは、前記受信されたイメージデータが前記リモート端末上に正しく表示されていることを保証するためのイメージスケーリングパラメータを有し、
前記特定ステップは、前記イメージスケーリングパラメータに対する変更が適切である場合、前記変更の特定を優先させるリモート端末が提供される。

【0042】

本発明の他の態様によると、リモート端末がモバイル装置にリンクされるセッションを改善するよう構成されるリモート端末であって、
プロセッサと、
当該リモート端末をモバイル装置に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記プロセッサは、前記リモート端末と前記モバイル装置とのそれぞれについて、前記リモート端末がモバイル装置にリンクされるセッションのパフォーマンスを決定するパラメータセットを含むパフォーマンスプロファイルを決定し、
前記リモート端末と前記リモート端末が接続可能であるモバイル装置との間のセッションのパフォーマンスを、ライブ接続がない間に推定し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づき前記推定を再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を前記適切なパフォーマンスプロファイルに含め、
終了まで必要に応じて前記推定、特定、変更、再評価及び採用ステップを繰り返し、
前記モバイル装置と前記リモート端末とについて前記変更されたパフォーマンスプロファイルを格納するよう構成されるリモート端末が提供される。

【0043】

本発明の他の態様によると、リモート端末がモバイル装置にリンクされるセッションを改善するよう構成されるリモート端末であって、
プロセッサと、
当該リモート端末をモバイル装置に接続するよう構成されるデータリンクと通信する通信モジュールと、
を有し、
前記リモート端末、前記モバイル装置及び前記データリンクは、前記リモート端末がモバイル装置にリンクされるときにセッションのパフォーマンスを決定するパラメータセットであって、静的パラメータと動的パラメータとの双方を有する前記パラメータセットを規定し、
前記プロセッサは、
前記リモート端末と前記リモート端末が接続可能なモバイル装置との間のライブセッションのパフォーマンスを評価し、
前記パラメータセットからパラメータに対する変更を特定し、
前記特定されたパラメータを変更し、
前記変更されたパラメータに基づきパフォーマンスを再評価し、
パフォーマンスが改善されている場合、前記特定されたパラメータの変更を採用し、
終了まで必要に応じて前記評価、特定、変更、再評価及び採用ステップを繰り返すよう構成され、
前記プロセッサは、前記動的パラメータに対する変更前に前記静的パラメータに対する変更の特定を優先させるよう構成されるリモート端末が提供される。

【0044】

リモート端末は、ユーザがコマンドを入力するための入力システムを有し、リモート端末のプロセッサは、入力されたコマンドをキャプチャし、キャプチャされた入力コマンドを通信リンクを介しモバイル装置に送信するよう構成されてもよい。モバイル装置のプロセッサは、その後、キャプチャされた入力コマンドを受信し、それらがあたかもモバイル装置の入力システム上で入力されたかのように、キャプチャされた入力コマンドを実行するよう構成されてもよい。従って、ユーザは、リモート端末からモバイル装置を制御することができる。モバイル装置は、ユーザがコマンドを入力するための入力システムを有してもよい。

【0045】

本発明はさらに、例えば、汎用コンピュータシステム上又はデジタル信号プロセッサ（ＤＳＰ）上などで上述したシステム及び方法を実現するためのプロセッサ制御コードを提供する。当該コードは、ディスク、ＣＤ又はＤＶＤ ＲＯＭ、不揮発性メモリ（フラッシュなど）などのプログラムされたメモリ又はＲＯＭ（ファームウェア）などのキャリア上に備えられてもよい。本発明の実施例を実現するためのコード（及び／又はデータ）は、Ｃやアセンブリコードなどの従来のプログラミング言語（インタープリット又はコンパイル）によるソース、オブジェクト又は実行可能コードを有してもよい。当業者は、当該コード及び／又はデータが互いに通信する複数の接続されたコンポーネント間に配布されてもよいことを理解するであろう。

【図面の簡単な説明】

【0046】

【図1】図１は、ＶＮＣセッションのパラメータを調整するための従来技術による方法を示すフローチャートである。

【図2a】図２ａは、本発明による遠隔制御システムのコンポーネントを示す概略ブロック図である。

【図2b】図２ｂは、図２ａのコンポーネント間のインタラクションを示す概略ブロック図である。

【図3a】図３ａは、図２ａのシステムを制御する方法を示すフローチャートを構成するため組み合わす。

【図3b】図３ｂは、図２ａのシステムを制御する方法を示すフローチャートを構成するため組み合わす。

【図3c】図３ｃは、図２ａのシステムを制御する方法を示すフローチャートを構成するため組み合わす。

【図4】図４は、図２ａのシステムを制御する方法を示すフローチャートである。

【発明を実施するための形態】

【0047】

従来技術によるアプローチ：Ｌｉｎｅ Ｓｐｅｅｄ Ｅｓｔｉｍａｔｅによるパフォーマンスの動的な最適化
図１は、ＶＮＣセッションのパフォーマンスが最適化可能である１つの既知の方法がセッションがアクティブである間にセッションのパラメータを動的に調整するためのものであることを示す。このアプローチは、選択されたピクセルフォーマット及び符号化タイプのみを考慮した動的パフォーマンス最適化技術を提案する。

【0048】

このアプローチでは、ステップＳ１００において、プロセッサは、ユーザにより初期的に選択されたピクセルフォーマット及び符号化タイプに基づき、現在のピクセルフォーマット及び符号化タイプを設定するよう構成される。ステップＳ１０２において、ライン速度推定値又はＬＳＥが、現在の接続スループットのインジケータを提供するため計算される。この推定値は、動的なプロセスであるため、ＶＮＣセッションの期間全体で定期的に計算される。ＬＳＥは、矩形データを受信するのにかかった時間に基づき計算される。基礎となるトランスポートを介し複数のユニット（ＩＰパケットなど）により送信された大きな矩形に関するデータのみが、推定値を決定する際に考慮される。接続がまず確立されると、ラウンドトリップタイムの推定値が、代わりにＬＳＥを決定するのに利用される。これは、より高いクオリティのピクセルフォーマット又はより強力でない符号化タイプが低速接続について謝って選択されることを防ぐ。

【0049】

ＬＳＥの各計算時に、プロセッサは、ＬＳＥが高速接続を示すか判断するよう構成される（ステップＳ１０４）。接続が高速でないと判断された場合、すなわち、ＬＳＥがより小さくなるに従って、プロセッサは、ＶＮＣセッションの設定を再設定するよう構成される。ステップＳ１０６において、符号化タイプは、増加した圧縮レベルを提供するものに変更される。また、ステップＳ１０８において、よりコンパクトなピクセルフォーマットが選択される。その後、本方法は他のＬＳＥを計算するためステップＳ１０２にループバックする。

【0050】

あるいは、接続が高速であると判断された場合、すなわち、ＬＳＥがより大きくなるに従って、プロセッサはまた、ＶＮＣセッションの設定を再設定するよう構成される。ステップＳ１１０において、より強力でない符号化タイプが選択される。また、ステップＳ１１２において、より高いクオリティのピクセルフォーマットが選択される。その後、本方法は他のＬＳＥを計算するためステップＳ１０２にループバックする。このアプローチは、スクリーン画質を犠牲にしてＶＮＣセッションのパフォーマンスが維持されることを確実にする。

【0051】

図２ａは、データリンク１４を介しリモート装置１２に接続されるモバイル装置１０を有する遠隔制御システムのコンポーネントを示す。モバイル装置１０は、プロセッサ２０、ディスプレイ２２及びデータリンクに接続されるデータ通信サブシステム２４を有する。リモート装置１２は、プロセッサ２０、ディスプレイ３２及びデータリンクに接続されるデータ通信サブシステム３４を有する。以下でより詳細に説明されるように、ＶＮＣサーバアプリケーション２６は、ディスプレイ２２のイメージをキャプチャし、それをデータ通信サブシステム２４を介しリモート装置に送信するため、モバイル装置のプロセッサ２０上で実行されている。従って、モバイル装置は、ＶＮＣサーバと呼ばれてもよい。対応するＶＮＣビューワアプリケーション３６は、データ通信サブシステム３４を介しディスプレイのイメージを受信し、それをリモート装置のディスプレイ３２に出力するため、リモート装置のプロセッサ３０上で実行されている。従って、リモート装置は、ＶＮＣビューワと呼ばれてもよい。

【0052】

リモート装置とモバイル装置とは共に、双方のユニット上にハードウェアスケーリングユニット３７，２７、モバイル装置上にハードウェア符号化ユニット２８及びリモート装置上に対応するハードウェア復号化ユニット３８を含む任意的なコンポーネントを有する。以下でより詳細に説明されるように、これらの任意的なコンポーネントは、等価なソフトウェア手段より高速な実装を提供するようにしてもよい。他の任意的なハードウェアコンポーネントがまた含まれてもよい。リモート装置１２はまた、以下でより詳細に説明されるように利用されるルールのデータベース３９を有する。データベースはリモート端末上に示されるが、それはさらに又はあるいは、以下のアプローチをシステムがどのように実現するかに依存してモバイル装置に含まれてもよい。

【0053】

図２ｂは、モバイル装置１０上で実行されるＶＮＣサーバアプリケーション２６からリモート装置１２又はビューワプラットフォーム上で実行されるＶＮＣビューワアプリケーション３６にフレームバッファアップデートとしてサーバデスクトップのイメージを送信するキーとなる段階を示す。ＶＮＣサーバアプリケーションの制御の下、モバイル装置のプロセッサは、フレームバッファの比較、イメージスケーリング、ピクセルフォーマット変換及びピクセルデータ符号化の１以上を実行するよう構成される。同様に、ＶＮＣビューワアプリケーションの制御の下、リモート装置のプロセッサは、フレームバッファの比較、ピクセルフォーマット変換、ピクセルデータ符号化、画像スケーリング及びスクリーンイメージ又はすべてのステップのレンダリングの１以上を実行するよう構成される。これらのステップのそれぞれは、以下でより詳細に説明される。

【0054】

フレームバッファの比較
モバイル装置のプロセッサは、ある時間におけるモバイル装置のスクリーンフレームバッファとビューワに以前に送信されたフレームバッファのコンテンツとを比較するよう構成されてもよい。これは、変更されたスクリーンの部分しか記述される必要がないため、以降のフレームバッファアップデートのサイズを低減できる。しかしながら、このタスクはＣＰＵリソースを必要とし、ＣＰＵが制約されるデバイス上ではコストのかかるものであるかもしれない。さらに、スクリーン全体が変更した場合、この比較はパフォーマンスの効果を有しない。いくつかのシナリオでは、これらの比較を無効にし、スクリーン全体が変更したと仮定することが適切であるかもしれない。

【0055】

イメージスケーリング
イメージスケーリングは、強力なタスクである。典型的には、スケーリングされたイメージはまた、スケーリングされたイメージにおける認知可能なクオリティの消失を低減するためアンチエイリアシングされる必要がある。ビューワがＣＰＵの制約のないか、又はスケーリング処理を実行可能なハードウェアリソース（グラフィックスコプロセッサなど）を有するシステム上で実行されている場合、ＶＮＣセッションのビューワサイドにおけるイメージのスケーリングは、妥当な選択である可能性がある。しかしながら、ハードウェアが十分なリソースを提供しない場合、イメージスケーリングタスクを代わりにＶＮＣサーバに委託することがより適切である可能性がある。利用可能な帯域幅の欠落が良好なパフォーマンスを維持するためにより小さいサイズのイメージが配線を介し送信されることを要求する場合、イメージスケーリングがまたＶＮＣサーバにおいて要求されてもよい。何れの理由であれ、ＶＮＣサーバアプリケーションを実行するプロセッサによるイメージスケーリングは、モバイル装置がスケーリング処理を効果的に処理するのに十分なリソースを有している場合、唯一の適切な選択肢である。

【0056】

ピクセルフォーマット変換
サーバデスクトップのイメージを表現するのに利用されるピクセルフォーマットは、ＶＮＣサーバ、ＶＮＣビューワ又はこれらの双方によって変換される必要があるかもしれない。モバイル装置は、サーバネイティブフォーマットとして参照される特定のピクセルフォーマットを利用して、それのディスプレイを自らレンダリングする。同様に、ＶＮＣビューワアプリケーションが実行されるシステムは、ビューワネイティブフォーマットとここで呼ばれるネイティブピクセルフォーマットを有する。サーバ及びビューワネイティブフォーマットが一致しない場合、ピクセルフォーマット変換が必要である。
選択されたピクセルフォーマットはまた、所与のフレームバッファアップデートを示すためＶＮＣサーバからＶＮＣビューワに送信される必要があるバイト数に対して影響を有する。従って、利用可能な帯域幅はまた、双方のサイドがイメージにピクセルフォーマット変換を適用する可能性があるため、ピクセルフォーマット変換の選択に影響を与えうる。例えば、ネイティブピクセルフォーマットが共にＲＧＢ−８８８（ピクセル毎に２４ビット）であるＶＮＣサーバとＶＮＣビューワは、配線を介した送信のため、よりコンパクトなＲＧＢ−５６５フォーマット（ピクセル毎に１６ビット）を利用することを選択してもよい。

【0057】

選択されたピクセルフォーマットはパフォーマンスを最適化する際に変更可能であるが、許容できると考えられる最小のカラー深度に対する制限がある可能性がある。例えば、１６ビット未満のカラー深度によるサーバデスクトップのイメージは、不十分すぎるクオリティであるとみなされてもよい。

【0058】

ピクセルデータ符号化
ＶＮＣサーバからＶＮＣビューワにスクリーンイメージを送信する際、各種符号化タイプが利用可能である。これらは、異なるレベルのデータ圧縮をピクセルデータに適用するのに利用可能である。符号化タイプのいくつかの具体例が以下にリストされる。
・Ｒａｗ：ピクセルデータは、圧縮が適用されることなくそのまま送信される。これは、ＶＮＣサーバとビューワとの間で最も大きな帯域幅を必要とするが、各サイドについてＣＰＵを最も少なくしか利用しない。
・Ｔｅｒｍｉｎａｌ Ｍｏｄｅ Ｒｕｎ−Ｌｅｎｇｔｈ Ｅｎｃｏｄｉｎｇ（ＴＭＲＬＥ）：ＴＭＲＬＥはまた、“Ｓｃａｎ Ｌｉｎｅ ｂａｓｅｄ Ｒｕｎ−Ｌｅｎｇｔｈ Ｅｎｃｏｄｉｎｇ”としても知られ、Ｔｅｒｍｉｎａｌ Ｍｏｄｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ，ｖ１．０，Ｃａｒ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｃｏｎｓｏｒｔｉｕｍ（２０１０）−ｗｗｗ．ｔｅｒｍｉｎａｌｍｏｄｅ．ｏｒｇの一部である“Ｔｅｒｍｉｎａｌ Ｍｏｄｅ Ｔｅｃｈｎｉｃａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ，Ｒｅｌｅａｓｅ Ｖｅｒｓｉｏｎ １．０”のＳｅｃｔｉｏｎ ５．４．３に記載されている。必須の符号化タイプは、Ｔｅｒｍｉｎａｌ Ｍｏｄｅ仕様書に記載されている。これは、Ｔｅｒｍｉｎａｌ Ｍｏｄｅ ｄｅｖｉｃｅによりサポートされる唯一の符号化タイプであり、完全性のためここでリスとされる。
・Ｔｉｌｅｄ Ｒｕｎ−Ｌｅｎｇｔｈ Ｅｎｃｏｄｉｎｇ（ＴＲＬＥ）：ピクセルデータはタイル系列にグループ化され、その各々は単一のピクセル（単色のタイルについて）、ｐａｃｋｅｄ ｐａｌｅｔｔｅ、プレインＲｕｎ−Ｌｅｎｇｔｈ Ｅｎｃｏｄｉｎｇ（ＲＬＥ）、ｐａｌｅｔｔｅ ＲＬＥ又は生の若しくは未処理のピクセルデータによって記述される。これは、比較とＣＰＵ強度との間の適度なバランスを提供する。
・Ｚｌｉｂ Ｒｕｎ−Ｌｅｎｇｔｈ Ｅｎｃｏｄｉｎｇ（ＺＲＬＥ）：利用されるタイルサイズがより大きく、符号化されたピクセルデータがまたｚｌｉｂを用いて圧縮されることを除き、ＴＲＬＥに類似する符号化タイプである。これは、より大きなレベルの圧縮を提供するが、より多くＣＰＵを利用する。
・ＪＰＥＧ：ピクセルデータは、ＪＰＥＧ圧縮イメージフォーマットを利用して送信される。これは、再びハイレベルな圧縮を提供し、ＣＰＵを多く利用する。しかしながら、一部のプラットフォームは、ＪＰＥＧ符号化及び復号化のためのハードウェアサポートを提供し、この符号化タイプのＣＰＵ要求を解消する。

【0059】

上記のリストから理解できるように、利用される圧縮レベルを増加させる符号化タイプはまた、ＶＮＣセッションの両サイドにおいてより多くのＣＰＵリソースを要求する。これは、通常は帯域幅とＣＰＵ利用との間のトレードオフがあることを意味する。しかしながら、いくつかのケースでは、ハードウェアサポートは特定の符号化タイプについて利用可能であってもよい。これは、特にＪＰＥＧ符号化タイプについて観察されてきた。最後に、限定数の符号化タイプしかサポートしないＶＮＣサーバと接続される可能性がある。例えば、ターミナルモードデバイスは、ＴＭＲＬＥ符号化しかサポートせず、可能なパフォーマンスチューニングパラメータとして符号化タイプを削除する。

【0060】

いくつかのケースでは、選択された符号化はまた、利用可能な最適なピクセルフォーマットに対して影響を有する。例えば、ＪＰＥＧ符号化によると、２４ｂｐｐピクセルフォーマットは、唯一の妥当な選択である。この符号化タイプはまた、結果としてのイメージのクオリティが制御されることを可能にする他のパラメータを導入する。イメージクオリティが高くなるに従って、符号化されたイメージを表現するのに要求されるバイト数はより大きくなる。ＪＰＥＧ符号化によるイメージクオリティは、他の符号化によるピクセルフォーマット設定に類似する。

【0061】

ＲＦＢトランスポート
ＶＮＣサーバとＶＮＣビューワとの間のデータリンクは、ＲＦＢトランスポートと呼ばれ、ＶＮＣセッションをサポートするＲＦＢ説即とそれの基礎となるネットワークスタックとを表す。ここでの主要なパフォーマンスボトルネックの可能性は、接続の利用可能なデータ帯域幅である。基礎となるトランスポートは、ＶＮＣセッションに利用可能な帯域幅を変動させる可能性のある他のサードパーティアプリケーションによって利用される可能性がある。さらに、特にモバイル装置などの一部のプラットフォーム上のより大きな帯域幅の利用は、データを送受信する際により大きなＣＰＵの利用を生じさせる可能性がある。この場合、帯域幅の利用を最小化することがまた、ＣＰＵの利用を減少させる。

【0062】

制約条件及びコンフィギュレーション選択の重要性
上記の説明から、出願人はＶＮＣセッションにより実現されるパフォーマンスが以下の制約を受けることを認識していたことが明らかである。
・利用可能なサーバサイドのハードウェアリソース：ＣＰＵ利用、イメージスケーリング及びＪＰＥＧ符号化のためのハードウェアサポート
・利用可能なビューワサイドハードウェアリソース：ＣＰＵリソース、イメージスケーリング及びＪＰＥＧ符号化のためのハードウェアサポート
・観察可能な接続スループット
以下のコンフィギュレーション選択がまた、パフォーマンスに対して優位な影響を有する。
・フレームバッファ比較
・イメージスケーリング
・ピクセルフォーマット変換
・ピクセルデータ符号化
ハードウェアイメージスケーリングサポートの有無など、これらの制約条件の一部は静的である。

【0063】

現在のＣＰＵ利用などの他の制約条件は、動的である。最も重要なものから最も重要でない制約条件のリストは、以下のとおりである。
１．サーバ及びビューワプラットフォーム上のＣＰＵ利用：動的な制約条件は、ビューワとサーバとがどの程度迅速に動作可能であるか示す。ＣＰＵ利用は、特にモバイル装置についてユーザ体感に影響を与えることを回避するため最小化する必要がある。ＣＰＵ利用はまた、何れかのプラットフォーム上のサードパーティアプリケーションにより影響を受ける可能性がある。
２．接続スループット：動的な制約条件は、フレームバッファアップデートデータがサーバからビューワに伝送可能な速度に影響を与える。これは、再びサードパーティアプリケーションにより影響を受ける可能性がある。さらに、上述されるように、サーバとビューワとの間で伝送されるデータ量は、サーバ又はビューワプラットフォーム（又は双方）におけるＣＰＵ利用に対して有意な影響を有する可能性がある。
３．イメージスケーリング及び符号化のためのハードウェアサポート：静的な制約条件は、ＣＰＵ利用及び／又は接続スループットを低減するため、利用される可能性がある。

【0064】

最も重要なものから最も重要でないものまでコンフィギュレーション選択をリスト
１．ピクセルデータ符号化、イメージスケーリング：これらは、ＣＰＵ及び帯域幅利用に対して最も大きな影響を有する。より大きな計算量の符号化タイプは、より大きなデータ圧縮を生じさせるが（従って、帯域幅の利用を低下させる）、より多くのＣＰＵリソースを要求する。ビューワにより要求された場合、イメージスケーリングはまた、ＣＰＵを多く利用する可能性がある（ハードウェアサポートが利用可能でない場合）。
２．フレームバッファ比較：変化したスクリーンのエリアのみを記述することは、フレームバッファアップデートのサイズを有意に減少させることができる。しかしながら、このタスクは、ＣＰＵリソースを必要とし、スクリーンのより大きなエリアが変更しているときにはリターンを減少させる。

【0065】

ＶＮＣセッションのパフォーマンスの最適化
上記に関して、符号化及びピクセルフォーマットを調整する図１に示される従来技術によるアプローチは、少なくとも２つの重要なコンフィギュレーションパラメータ、すなわち、イメージスケーリング及びフレームバッファ比較に対処していない。出願人は、ＶＮＣセッションのパフォーマンスを最適化するのに利用可能な改良されたアプローチがあることを認識し、これらは図３ａ〜４に示される。ＶＮＣセッションのコンフィギュレーション及び／又は制約条件に関する情報の一部又はすべてが考慮されてもよい。ＶＮＣサーバ又はＶＮＣビューワは、パフォーマンス最適化処理を管理するようにしてもよい。

【0066】

いくつかのパラメータはＶＮＣセッションの初期的な接続段階に影響を与える性質を規定することに留意されたい。例えば、ＶＮＣセッションのセキュリティの側面（認証及び暗号化）が設定可能である。プロキシサーバが選択可能であるか、又は特定のプラグインベアラが選択可能である。このような初期的な接続パラメータは、ＶＮＣセッションが確立されると変更できない。これらのパラメータは、調整不可であると考えられ、本明細書ではさらには考慮されない。

【0067】

各アプローチについて、パフォーマンスが許容レベル以下であるときをハイライト可能な機構が存在する必要がある。以降の図面を参照してより詳細に説明されるように、以下のメトリックの一部又はすべてがこの機構において利用されてもよい。これは網羅的なリストではないが、例えば、毎秒再描画されるスクリーンエリアのトータルパーセンテージなどの他のメトリック
・ＦｒａｍｅｓＲｅｎｄｅｒｅｄ
・接続スループット又はＰｉｘｅｌＴｈｒｏｕｇｈｐｕｔ
など、利用可能なメトリックのタイプの単なる一例であることが理解されるであろう。

【0068】

ＦｒａｍｅｓＲｅｎｄｅｒｅｄ
これは、毎秒ビューワによりレンダリングされるフレームの平均数である。このメトリックは、パフォーマンスを評価する際のキーとなるインジケータとして現在頻繁に利用される。しかしながら、ＦｒａｍｅｓＲｅｎｄｅｒｅｄの小さな値は、必ずしも不良なパフォーマンスを示すとは限らない。ＶＮＣサーバは、サーバデスクトップスクリーンが変わるときのみ、フレームアップデートを送信する。遠隔制御下のモバイル装置のスクリーンが静的であるか、又は頻繁には更新されない場合、ＶＮＣビューワは極めて低い（又はゼロでさえある）フレームレートを記録する。これは、全体的に通常であり所望されるが、それは、ＦｒａｍｅｓＲｅｎｄｅｒｅｄメトリックの特定値がさらなるコンテクスト情報なしに適切には評価できないことを意味する。具体的には、ＦｒａｍｅｓＲｅｎｄｅｒｅｄメトリックの正しい評価は、モバイル装置のスクリーン自体がアップデートされている実際のレートとの比較に基づくものである必要がある。

【0069】

ＶＮＣセッションの不良なパフォーマンスは、当該セッションのビューワサイドから特定できる。これを実現するため、ＶＮＣサーバが観察される実際のフレームレート（すなわち、サーバデスクトップが更新される実際のレート）を報告することを可能にする機構が導入できる。サーバデスクトップがビューワへの新たなフレームバッファアップデートの送信を証明するのに十分変化したとき、新たなフレームが観察される。実際のフレームレートに関する情報は、要求に応答してＲＦＢ拡張メッセージを介しサーバからビューワに送信可能である。

【0070】

しかしながら、サーバデスクトップの変化を特定することは、残念ながら困難なタスクとなりうる。大部分のモバイル装置のプラットフォームは、アプリケーションにスクリーンの変化を通知することを可能にする機構を備えていない。従って、アプリケーションは、スクリーンの状態を定期的に調べる必要がある。ポーリングと呼ばれるこの調査プロセスは非効率的であり、ＣＰＵの利用を増大させる。

【0071】

他のアプローチは、所定のフレームレートによりスクリーンアップデートを生成することであろう。例えば、スクリーンに毎秒Ｎフレームのレートでアップデートさせるテストカードアプリケーションが利用可能である。しかしながら、これは、ユーザがデバイスとやりとりすることを阻むため、動的パフォーマンス最適化アプローチにおいて利用するのに適していない。

【0072】

接続スループット
データ接続のスループットの測定は、困難なタスクである。スループットは、２つのファクタ、すなわち、帯域幅（ある期間における当該接続により送信可能な最大データ量）及び遅延（ＩＰパケットなどのデータユニットを送信するのに要求される時間）に依存する。接続の遅延が減少すると、当該接続の可能なスループットは帯域幅に役立つ。ＶＮＣセッションにより生じる遅延の測定は、特にＶＮＣモバイルソリューションによりサポートされる異なるトランスポートに対して困難である。

【0073】

１つのパフォーマンスメトリックは、毎秒ビューワにより受信される平均ピクセル数であるＰｉｘｅｌＴｈｒｏｕｇｈｐｕｔである。低いＰｉｘｅｌＴｈｒｏｕｇｈｐｕｔの値は、低スループットの接続を示す。しかしながら、サーバデスクトップが頻繁には更新されない場合、又は小さな領域しか変化していない場合、低い値がまた当該メトリックについて取得される可能性がある。制限されたハードウェアリソースのためサーバにより生成される頻繁でないフレームバッファアップデートはまた、ビューワに毎秒より少ないピクセルを受信させることになる。従って、自動調整パラメータのため、このパフォーマンスメトリックは有用となる十分な情報を提供しない。

【0074】

接続スループットのインジケータを取得するための１つの方法は、フレームバッファアップデートを構成するピクセルデータを受信するのに要する時間に基づき推定値を構成することである。Ｌｉｎｅ Ｓｐｅｅｄ Ｅｓｔｉｍａｔｅとして知られるこの推定値は、ピクセルデータが十分であり、基礎となるトランスポート例や上で複数のユニット（ＩＰパケットなど）に分割される場合にのみ意味がある。しかしながら、このピクセルデータを受信するのに要する時間は、サーバがデータを符号化するのに低速である場合、増加する可能性がある。従って、このインジケータはいくつかのシナリオでは不正確なものとなりうる。

【0075】

アプローチ１：ルールベースシステムを利用した動的に調整されるパラメータによるパフォーマンスの最適化
図３ａ及び３ｂは、ルールベースシステムによりガイドされるパフォーマンス最適化に対する動的なアプローチを示す。ステップＳ２００において、ＶＮＣセッションのパフォーマンスが評価される。この評価は、これが動的なプロセスであるため、ＶＮＣセッションの期間を通じて定期的に計算される。この評価は、例えば、パフォーマンス測定機能により報告されるＦｒａｍｅｓＲｅｎｄｅｒｅｄメトリックを利用することによって実現されてもよい。ステップＳ２０２において、パフォーマンスが許容されるかに関する評価がある。パフォーマンスが許容される場合、パフォーマンスは所定の時間後に再評価される。

【0076】

あるいは、パフォーマンスが許容レベル以下であると特定された場合、当該パフォーマンスを最適化する試みが開始される。最適化プロセスは、パフォーマンスが許容レベルに到達するまで、又はある時間が経過するまで継続される。１つのパラメータの変更は、アクションとみなすことができ、特定のシナリオに適している可能性のあるこれらのアクションはルールセットにより決定可能である。可能なアクションはビューワにより実現可能であり、パフォーマンスレベルを低下させる場合、リバース（又はバックトラック）することができる。選択される各アクションは、最適なパフォーマンスへのステップを提供すべきである。このアプローチは、知識ベースにより符号化されるエクスパート知識と、特定の状況においてベストなステップを特定するため試みるための能力とを合成する。

【0077】

アクションがルールベースシステムを利用して選択されることが提案される。このシステムは、特定のシナリオにおいて採用可能な可能なアクションを説明する知識ベースに保持されるルールセットから構成される。ルールは、静的な制約条件により課される条件に対して作用するものと、動的な制約条件に対して作用するものとの２つのタイプにグループ化される。静的なルールがまず評価され、関連するアクションはより高い優先度を有する。従って、ステップＳ２０４において設定されるように、最適化プロセスにおける最初のステップは静的なルールを考慮することである。これらは、ＶＮＣサーバ又はＶＮＣビューワがイメージスケーリングや画像圧縮などの特定のタイプのハードウェアを有するか否かなど、変化しないシステムのパラメータ又はコンフィギュレーションである。ルールが評価されると、システムはステップＳ２０６において、より有効なアクションを特定することを試みるよう構成される。

【0078】

以下のアクションは、パフォーマンスの最適化のためビューワに利用可能である。
１．より高い圧縮レベルを有する符号化タイプにスイッチ
２．より低い圧縮レベルを有する符号化タイプにスイッチ
３．ＪＰＥＧ符号化タイプにスイッチ
４．よりコンパクトなピクセルフォーマットにスイッチ
５．サーバネイティブなピクセルフォーマットにスイッチ
６．ビューワネイティブなピクセルフォーマットにスイッチ
７．イメージスケーリングをサーバサイドに委託
８．イメージスケーリングをビューワサイドに委託
９．サーバサイドのフレームバッファ比較を有効
１０．サーバサイドのフレームバッファ比較を無効
各アクションは、単一のリバース可能な変更がＶＮＣセッションに行われることを可能にする。

【0079】

アクションの有効性
１以上のアクションは、すべてのシナリオについて必ずしも有効でない可能性がある。例えば、許容されると考えられるカラー深度及びＪＰＥＧ圧縮に関して最小レベルの画質に対する制約があってもよい。従って、ピクセルフォーマットに影響を与えるアクションは、カラー深度を当該最小レベル以下にさせないべきである。これは、いくつかのケースにおいてピクセルフォーマットアクションを無効にさせる可能性がある。同様に、ＪＰＥＧ圧縮のために利用されるクオリティ設定は、特定レベル以下に低下しないよう制限されてもよい。ＪＰＥＧ符号化タイプが選択されると、ピクセルフォーマットの変更に関するルールが、代わりにＪＰＥＧ画質レベルに適用可能である。

【0080】

いくつかのアクションは、特定のシナリオにおいて適用不可であってもよい。例えば、ターミナルモードデバイスに接続されるとき、ＴＭＲＬＥから符号化タイプを変更することは不可である。他のアクションは、それらが以前のステップにおいてすでに適用されているため、又はアクションにより対象とされるパラメータの初期設定のため、コンフィギュレーションの変更を生じさせない可能性がある。適用不可なアクション又はコンフィギュレーションの変更を生じさせないアクションはまた、無効とみなされる。

【0081】

最後に、多くのアクションは互いに直接的に反対のものであり、１つのアクションの適用は他方の取り消しを有効にする可能性がある。例えば、アクション１が以前に適用された後にアクション２を適用することは、アクション１の効果を無効にすることになる。これは、アクション及びその反対のアクションが連続的に交互に適用される状況を導く可能性があり、これは望ましくない。これを解決するため、以下の制限が課される。すなわち、以前に適用されたアクションの反対のアクションは、以前に適用されたアクションの適用から指定された（設定可能な）期間が経過するまで呼び出されないようにしてもよい。この制限を充たさないアクションは無効とみなされる。

【0082】

静的ルールからのアクションの選択
無効なアクションが静的ルールの評価後に特定された場合、ステップＳ２０８において、それが選択及び実現される。

【0083】

以下のテーブルは、静的ルールの知識ベースがどのように構築できるかの具体例を提供する。

【0084】

【表1】

パフォーマンス変更
ステップＳ２１０において、変更がパフォーマンスを改善するか判断される。より不良なパフォーマンスレベルを生じさせる変更は、ステップＳ２１２においてリバース（バックトラック）される。アクションはまた、“ｔｒｉｅｄ”としてマーク付けされ、それはもはや有効なアクションとしてリストされない。本方法は、その後に静的ルールを評価するＳ２０４のプロセスの最初にループバックし、少なくともステップＳ２０４及びＳ２０６を繰り返す。

【0085】

パフォーマンスが悪化していない場合、変更は維持されてもよい。図３ａはＳ１を介し図３ｂにわたされる。次のステップは、終了条件に到達したか否かを決定するＳ２１４である。結果が否定的である場合、本方法は、ステップＳ２１６において、アクションを“ｉｍｐｌｅｍｅｎｔｅｄ”としてマーク付けし、すべての“ｔｒｉｅｄ”アクションのマーク付けを解除する。従って、“ｉｍｐｌｅｍｅｎｔｅｄ”とマーク付けされたアクションは有効でなくなるが、以前の“ｔｒｉｅｄ”アクションは有効になる。当該プロセスは、Ｓ２０４において静的ルールを再評価し、少なくともＳ２０４及びＳ２０６のステップを繰り返すため、Ｓ２を介しループバックする。終了条件に到達した場合、本方法は、現在のパフォーマンスレベルが許容可能であると設定されるステップＳ２１８にわたされ、ステップＳ２０２における判定にわたされる。その後、本方法は、Ｅ１を介し最初のステップにループバックし、すなわち、ＶＮＣセッションのパフォーマンスが評価される。

【0086】

ステップＳ２０６において静的ルールから１以上の有効なアクションを特定することを試みる際にアクションが特定されない場合、ステップＳ２２４において、動的な制約条件が評価され、ステップＳ２２６において、システムは１以上の有効なアクションを特定することを試みる。有効なアクションが特定される場合、ステップＳ２２８において、これは、ビューワがその次のアクションを選択する前に静的ルールのループの一部として変更が実現されることによって、選択及び実現される。変更を処理するためのループは、このとき、静的ルールに対するものと同じである。

【0087】

ステップＳ２３０において、変更がパフォーマンスを向上させるか判断される。不良なレベルのパフォーマンスを生じさせる変更は、ステップＳ２３２においてリバース（バックトラック）される。当該アクションはまた“ｔｒｉｅｄ”としてマーク付けされ、もはや有効なアクションとしてリストされない。本方法は、その後にステップＳ２２４において動的ルールを再評価し、少なくともステップＳ２２４及びＳ２２６を繰り返すためループバックする。

【0088】

パフォーマンスが悪化していない場合、当該変更は維持されてもよい。図３ａは、Ｄ１を介し図３ｂにわたされる。次のステップは、終了条件に到達したか判断するためのＳ２３４である。結果が否定的である場合、本方法は、ステップＳ２３６において、当該アクションを“ｉｍｐｌｅｍｅｎｔｅｄ”としてマーク付けし、すべての“ｔｒｉｅｄ”アクションのマーク付けを解除する。当該プロセスは、その後にＳ２２４において動的ルールを再評価し、少なくともステップＳ２２４及びＳ２２６を繰り返すため、Ｄ２を介しループバックする。従って、動的ルールは、終了条件に到達するまで、動的制約条件に関する新たな情報によって評価が継続される。

【0089】

終了条件に到達した場合、本方法は、現在のレベルのパフォーマンスが許容できるとして設定されるステップＳ２１６にわたされ、ステップＳ２０２の判定にわたされる。その後、本方法は、Ｅ１を介し最初のステップにループバックし、すなわち、ＶＮＣセッションのパフォーマンスが評価される。このようにして、ビューワは、パフォーマンスが要求されるレベルに到達したこと、指定された期間が経過したことなどの適切な終了条件に到達するまで、動的制約条件を評価し、選択されたアクションを適用し続ける。

【0090】

動的ルールからのアクションの選択
動的ルールの評価後に有効なアクションが特定された場合、その後、それは、ステップＳ２２８において選択及び実現される。上述されるように、動的ルールは、静的ルールが調査された後に始めて評価される。動的ルールにより指定されるアクションは、それが静的ルールにより以前に課されたアクションに矛盾する場合、常に無視される。

【0091】

以下のテーブルは、動的ルールの知識ベースがどのように構築可能であるかの具体例を提供する。

【0092】

【表2】

知識ベースにおいて利用される正確なルールは、実験を介して決定可能である。例えば、上記のルールは、中程度のレベルに到達した場合にサーバＣＰＵの利用を低減することが試みられるか、又は高いレベルに到達した場合にのみビューワＣＰＵの利用が低減されることが試みられることを仮定する。この仮定は、変更される必要があってもよい。

【0093】

特定のシナリオでは、パフォーマンスを最適化する際にビューワがトライ可能な複数の異なるアクションがある。例えば、ビューワプラットフォームとサーバプラットフォームとの双方におけるＣＰＵ利用が低い場合、よりコンパクトなピクセルフォーマットを選択するか、又は異なる符号化タイプを選択することによって、パフォーマンスは改善されてもよい。従って、１つのルールは、ビューワがランダムに選択可能な可能な適切なアクションのグループを指定できる。選択されたアクションは、意図しない副次的効果をもたらす可能性があり、実際にパフォーマンスの低下を生じさせる。アクションがパフォーマンスの低下を生じさせる場合、ビューワは、以前のコンフィギュレーションにトラックバックをし、他のアクションを試行できる。

【0094】

有効なアクションが特定されない
サーチ及び最適化において通常見られる１つの問題は、特定のコンフィギュレーションが局所最大条件を導く可能性があることである。すなわち、ビューワは、それのコンフィギュレーションに対して行われたインクリメンタルな変更がパフォーマンスの低下を導くことを検出する可能性がある。この局所的に高いレベルのパフォーマンスは、特定の状況において達成可能な最も高いパフォーマンスレベルを表すかもしれず、この場合、最適化は終了すべきである。残念ながら、現在の局所最大コンフィギュレーションがそれのサーチを継続することなく実現可能な最良のパフォーマンスを表しているかビューワが知ることはできない。従って、ビューワは、これまで実現されたパフォーマンスに満足すべきであるか判断しなければならない。

【0095】

局所最大条件が検出される場合、すべての一致するルールにより特定されたすべてのアクションが無視されるべきか、又はより不良なパフォーマンスを導き、ビューワは、実現することを試みている要求されるパフォーマンスのレベルと比較して、それが“十分良好である”か判断するため、現在実現されているパフォーマンスを比較できる。実現されたパフォーマンスが許容できると考えられる場合、要求されるレベルのパフォーマンスは、取得したレベルに一致するよう調整されるべきであり、パフォーマンスの最適化の試みは終了される。

【0096】

図３ａに戻って、ビューワが所与のルールにより提供されるすべてのアクションが無効であるか、又はパフォーマンスの向上をもたらさないと判断した場合、他のマッチングルールが求められるべきである。従って、静的ルール又は動的ルールから有効なアクションが検出されない場合、本方法はＤ３を介し図３ｃにわたされる。ステップＳ２４０において、パフォーマンスが“十分良好である”かに関する判定が行われる。結果が肯定的である場合、本方法は、現在のパフォーマンスレベルが許容できるとして設定されるステップＳ２４２にわたされ、Ｅ１を介し図３ａに示される方法の最初のステップにループバックし、すなわち、ステップＳ２００において、ＶＮＣセッションのパフォーマンスが評価される。

【0097】

パフォーマンスが“十分良好”でないと判断された場合、システムは、ステップＳ２４４においてルールベース全体において有効であるアクションがあるか判断する。結果が否定的である場合、本方法は、現在のパフォーマンスレベルが許容できると設定されるステップＳ２４２にわたされ、ステップＳ２０２における判定にわたされる。本方法は、その後、図３ａに示される方法の最初のステップにＥ１を介しループバックし、すなわち、ステップＳ２００において、ＶＮＣセッションのパフォーマンスが評価される。

【0098】

より良好なコンフィギュレーションが依然として存在する可能性があり、それは、検索パスがコンフィギュレーションの実行の悪化を導いた後に始めて検出可能である。これは、有効なアクションが存在すると判断された場合に適用可能である。この場合、他の調査手段を開くための１つの方法は、ステップＳ２４６においてランダムに選択されたアクション（必ずしもマッチングルールにより規定される必要があるとは限らない）を選択及び実現することである。ランダムな有効なアクションが、バックトラックなしに選択及び実現される。動的ルールについてランダムに選択されたアクションは、静的ルールにより以前に選択されたアクションに矛盾してはならない。システムは、ランダムなアクションを実現し、動的ルールを再評価し、少なくともＳ２２４及びＳ２２６を繰り返すため、Ｄ２を介し図３ａにわたされる。すべての“ｔｒｉｅｄ”アクションはマーク付けが解除され、自由に利用される。ランダムなアクションは、実現可能なものが検出されるまで、選択され続けるべきである。

【0099】

終了
局所最大条件と共に、ビューワは、所定のパフォーマンス要求レベルが実現されると、パフォーマンス最適化の試みを終了できる。例えば、上述されるように、終了条件に到達した場合、本方法は、現在のパフォーマンスレベルが許容できるとして設定されるステップＳ２１６にわたされ、ステップＳ２０２における判定にわたされる。本方法は、その後に図３ａの方法の最初のステップにＥ１を介しループバックし、ＶＮＣセッションのパフォーマンスが評価される。以降において、パフォーマンスがこの許容レベルを下回った場合、新たなパフォーマンス最適化の試みが開始できる。ビューワはまた、最適化の試みが永久に継続されることを回避するため、パフォーマンス最適化が結果をもたらすことができない終了条件を規定することを所望してもよい。この場合、許容されるパフォーマンスレベルは、利用可能なタイムフレームにおいて最良の実現されたパフォーマンスレベルに一致するよう再び変更されるべきである。

【0100】

アプローチ２：パフォーマンスプロファイルによるパフォーマンスの静的最適化
ここまで提案されたアプローチは、許容されるパフォーマンスレベルが維持されることを保証するため、アクティブなＶＮＣセッションのパラメータを動的に調整する問題を検討した。この問題に対する動的アプローチは、ビューワ及びサーバが特定のＶＮＣ接続の正確な条件に調整することを可能にする効果を有する。特に、アプローチ１は、実験が行われることを可能にし、それは、通常では検出されなかった可能性のある新規なパラメータセットの特定を可能にする。さらに、動的アプローチはまた、ビューワ及びサーバがサードパーティアプリケーションによる影響を受ける可能性がある利用可能な帯域幅及びＣＰＵなど、ＶＮＣ接続に影響を与える変更可能なファクタに適応することを可能にする。

【0101】

しかしながら、動的アプローチはまた１つの重大な欠点を有している。ライブのＶＮＣセッションパラメータの変更は、ユーザに新式可能な視覚的変化をもたらす可能性がある。例えば、ＲＧＢ−５６５からＲＧＢ−２２２へのピクセルフォーマットの変更は、ビューワにより示されるスクリーンイメージのクオリティの認識可能な変化を生じさせる。これは、ユーザ体感にとってネガティブな影響を与えるかもしれない。最適なパフォーマンスを実現するため、ＶＮＣセッションパラメータを動的に調整する代わりに、適切なパラメータ値が静的解析を介し選択可能である。すなわち、適切なＶＮＣセッションパラメータは、ＶＮＣセッション自体を確立する前に特定できる。パラメータは、ビューワ及びサーバプラットフォームに関する既知の情報に基づき選択できる。静的アプローチはビューワにより提示されるスクリーンイメージのクオリティの認識可能な変化を回避する一方、ビューワ及びサーバがいくつかの困難なシナリオにおいて良好に対処し、又は変更する条件に適応することを可能にする。

【0102】

このアプローチは、ＶＮＣセッションが完全に確立される前に、パフォーマンスプロファイルを設定し、これらを用いて適切なＶＮＣセッションパラメータ値を特定する静的解析技術を提案する。ＶＮＣセッションが完全に確立されると、それのパラメータに対してさらなる変更が行われる。このアプローチでは、モバイル装置上で実行されるＶＮＣサーバは既知の静的パフォーマンスプロファイルを有し、それは、当該装置の性質と各種ハードウェア機能、符号化タイプ及びピクセルフォーマットを可能にするコストとを特定することが提案される。その後、ＶＮＣビューワは、当該情報を利用してセッションについて予想されるフレームレートを最大化するパラメータ値のセットを検索する。この検索中、ビューワはまた、それ自身の能力を記述するパフォーマンスプロファイルを考慮する。

【0103】

パフォーマンスプロファイル
従って、本方法の第１ステップＳ４００は、ＶＮＣビューワがＲＦＢ拡張メッセージを用いて通信可能なＶＮＣビューワからパフォーマンスプロファイルを取得することである。ＶＮＣビューワはまた、ＶＮＣビューワについてパフォーマンスプロファイルを生成可能である。これらのプロファイルは、当該装置の性質に関して以下の情報を含むことができる。
・スクリーン解像度
・ハードウェアイメージスケーリングサポート
・ハードウェアＪＰＥＧ符号化／復号化サポート
・予想される接続スループット
プロファイルはまた、各種パラメータの選択を支援するため、ＣＰＵ時間の単位に関してコスト情報を提供する。各パラメータはそれに関連するコストを有し、パラメータセットの全体的なコストが、ステップＳ４００において、各パラメータに関連するコスト値を単に合計することによって取得される。可能なサーバパフォーマンスプロファイルにより提供されるコスト情報の具体例が、以下のテーブルに提供される。

【0104】

【表3】

パラメータが、パフォーマンスプロファイルに対して追加又は削除されてもよい。帯域幅コストはまた重要であり、これらは、特定のピクセルフォーマット及び符号化タイプについてＶＮＣビューワにより推定可能である。帯域幅の推定値は、当該接続を介し実現可能なＦＰＳ（Ｆｒａｍｅｓ Ｐｅｒ Ｓｅｃｏｎｄ）による最大フレームレートに関して表現できる。

【0105】

パフォーマンスプロファイルの静的解析
推定される帯域幅コストと共に、サーバサイド及びビューワサイドのパフォーマンスプロファイルからの利用可能な情報を利用して、ビューワは、最良のパフォーマンスを提供する適切なＶＮＣセッションパラメータ値のセットを特定できる（ステップＳ４０２）。当該情報は、可能なパフォーマンスボトルネックを特定するため解析可能であり（ステップＳ４０４）、これらのボトルネックに対するロードはその後に低減できる。

【0106】

繰り返しアルゴリズムが、検索を実行するため提案される。ビューワは、ＶＮＣセッションパラメータのデフォルトセットから開始される。ＣＰＵ利用及び帯域幅の可用性の解析から、毎秒レンダリングされるフレーム、接続スループット又はピクセルスループットなどの特定のパフォーマンスメトリックについて推定値が生成される（ステップＳ４０２）。ステップＳ４０４において、ビューワ、サーバ又は帯域幅となりうるパフォーマンスボトルネックが、その後に以下でより詳細に説明されるように特定される。パフォーマンスプロファイルの解析からの情報は、ボトルネックに対するロードを低減するよう調整可能な１つのセッションパラメータを特定するため利用される。ステップＳ４０６において、当該パラメータに対する調整が行われ、ステップＳ４０８において、パフォーマンスメトリックが再推定される。

【0107】

このとき、ステップＳ４１０においてパフォーマンスの評価がある。パフォーマンスが増加している場合、本方法は、ステップＳ４０４において他のパフォーマンスボトルネックを特定するためループバックし、Ｓ４０４〜Ｓ４１０を繰り返す。パフォーマンスが向上していない場合、調整はステップＳ４１２において取り消され、サーチは終了し、セッションパラメータの結果としてのセットは、ステップＳ４１４において、ＶＮＣセッションに利用するためシステムに提供される。

【0108】

以前の変化をすぐに取り消すことを回避するため、アプローチ１において提案されたものと同様に、特定の期間に変更が反対にされることを防ぐための制限を課すことができる。例えば、ピクセル符号化タイプの変更は、帯域幅のボトルネックを軽減するかもしれないが、サーバサイドのＣＰＵボトルネックを生じさせる。この制限は、ボトルネックを単に帯域幅に移すことを回避するため、ピクセル符号化タイプが再び変更されることを防ぐことができる。

【0109】

この静的解析サーチは、初期的な接続において１回のみ実行される。さらに、結果として得られるＶＮＣセッションパラメータは、同一の２つの装置の間の以降の各接続に対してサーチを実行する必要を回避するため、キャッシュされてもよい。パラメータがキャッシュされている場合、これらのキャッシュされた値がクリアされ、最適値に対する新たなサーチが開始されることを可能にするため、エンドユーザにオプションが提供可能である。

【0110】

パフォーマンスボトルネックの特定
パフォーマンスプロファイルにより提供される情報と共に、利用可能な帯域幅の推定値を利用することによって、パフォーマンスボトルネック（ビューワ、サーバ又は帯域幅）がサーチの各繰り返しに対して特定される必要がある。これら２つの段階において実行される。
１．帯域幅：帯域幅の推定値がまず、所望されるフレームレートが実現可能であるか判断するため調べられる。帯域幅の推定値が、実現可能な最大フレームレートが所望のフレームレート未満であることを示唆する場合、パフォーマンスボトルネックは帯域幅として特定される。
２．ＣＰＵ：帯域幅推定値が、所望のフレームレートが実現可能であることを示唆する場合、ＣＰＵコストはボトルネックを決定するため利用される。ビューワのトータルＣＰＵコストがより大きい場合、パフォーマンスボトルネックはビューワとして特定される。サーバのトータルＣＰＵコストがより大きい場合、パフォーマンスボトルネックはサーバとして特定される。ビューワ及びサーバのトータルＣＰＵコストが等しい場合、ビューワ又はサーバがランダムにボトルネックとして特定される。

【0111】

これを示すため、サーバ及びビューワの以下の具体例となるパフォーマンスプロファイルを検討する（ステップＳ４００）。この図では、１０ＦＰＳのパフォーマンスが所望される。

【0112】

【表4】

所与のＶＮＣセッションパラメータセットに対して、ビューワ及びサーバコストはこの情報から計算可能である（ステップＳ４００）。例えば、以下の通りである。

【0113】

【表5】

上記の図によると、一例となるＶＮＣセッションは７ＦＰＳの最大フレームレートを実現することが期待される。これは１０ＦＰＳの所望のフレームレート以下であるため、帯域幅は、この繰り返しに対するボトルネックであると示される（ステップＳ４０４）。これは、例えば、ピクセルフォーマットをＲＧＢ−８８８からＲＧＢ−５６５に変更することによって対処できる（ステップＳ４０６）。これは、このとき以下の結果を生じさせる可能性がある。

【0114】

【表6】

推定される帯域幅は、１０ＦＰＳの所望のフレームレートをサポートすることが可能である（ステップＳ４０８及びＳ４１０）。このとき、次のボトルネックは、サーバとして特定され、ビューワへのイメージスケーリングの委任などの他の変更が実行可能である。すべてのパラメータが選択されるまで、当該プロセスが繰り返される。あるいは、静的解析段階の時間が許容される場合、何れかのボトルネックからの最も遠くのものが選択可能であるか、又は所望のフレームレート以下に下落することなく最良の画質を提供することが期待されるものが選択できるように、パラメータのすべての有効な組み合わせが考慮可能である。

【0115】

アプローチ３：キャリブレーション段階を利用した最適なＶＮＣセッションパラメータの特定
当該最後のアプローチは、最適なＶＮＣセッションパラメータのサーチをトリガするのに利用可能な特定のキャリブレーション段階の生成を提案する。ここでは、実際のサーチ機構は提案されない。その代わりに、当該アプローチは、アプローチ１及び２の従来技術において提案されたサーチ機構の何れかを再利用できる。

【0116】

多数の装置は、それらが最適なパフォーマンスを提供可能になる前にキャリブレーションを要求する。このキャリブレーション段階は、一般にエンドユーザからのインタラクションを伴うが、ユーザに対して不良なパフォーマンスを示さない。例えば、タッチスクリーンは、ユーザがそれのコーナー及び中央をタップすることを要求するキャリブレーション段階を有してもよい。この期間中、クロスヘアが、ユーザからのタップを要求するポイントに表示されるようにしてもよい。キャリブレーション段階中の何れの段階でも、ユーザは誤って解釈されたタップなどの不良なキャリブレーションのアーチファクトを観察する。

【0117】

ＶＮＣセッションパラメータを最適化する動的アプローチは、ビューワがサーバから受信するスクリーンをレンダリングする方法についてユーザが認知可能な変更を観察する可能性があるという欠点を有する。セッションパラメータが最適化を実行しているとき、ユーザ体感は不良になる可能性がある。あるいは、静的アプローチは、ビューワとサーバとの間のＶＮＣ接続を確立するのに必要とされる時間を増大しうる追加的な処理時間を要求する可能性がある。この接続時間の増加は、不良なパフォーマンスを表すものとして観察される可能性がある。特定のキャリブレーション段階に最適化処理を含めることによって、これらの問題は回避できる。

【0118】

提案されるキャリブレーション段階は、あるＨｕｍａｎ−Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃｅ（ＨＭＩ）を介しエンドユーザによりトリガできる。これは、ＶＮＣセッションの確立前に、又は新たなアプリケーションがモバイル装置上でスタートされたとき、ユーザに推奨されてもよい。スタートされると、パラメータ最適化が終了するまで、又は所定の期間が経過するまで継続できる。キャリブレーション段階中、従来技術又はアプローチ１，２において提案されるサーチ機構の何れかが利用可能である。必要とされる場合、ＶＮＣセッションが最適化処理中に生成されてもよいが、これらはユーザから隠蔽される。当該処理中の不良なユーザ体感の証拠を隠蔽するのと同様に、これはまた、例えば、予測可能なフレームレートにおいてスクリーンアップデートを提供するテストユーティリティの利用を可能にする。特に、これはユーザ体感に影響を与えることなく実際のデバイスフレームレートを特定する際の問題が解消されることを可能にするであろう。ＶＮＣサーバにより示されるテストカードユーティリティはまた、モバイル装置の実際のスクリーン上に表示される必要はない。

【0119】

パフォーマンスキャリブレーションがアプリケーション単位で実行される場合、これは、ＶＮＣセッションパラメータの最適なセットに各アプリケーションが関連付けされることを可能にする可能性を有する。ユーザがモバイル装置上でアプリケーションをスイッチするとき、ＶＮＣセッションパラメータは、当該アプリケーションに最適なセッションパラメータセットに変更可能である。ＨＭＩがアプリケーションに関連するセッションパラメータを有しない場合、メッセージ又は通知がキャリブレーションの実行を推奨するユーザに提示できる。アプリケーションの現在のパフォーマンスレベルが以前に観察されたものよりかなり不良である場合、キャリブレーションが実行されることを推奨することが適切であるかもしれない。

【0120】

提案されるアプリケーションの変形
本明細書に提供されるアプローチに対して生成可能な多数の変形がある。このような１つの変形は、パフォーマンス最適化処理の管理の委託を変更することである。ここに提案されるすべてのアプローチにおいて、ＶＮＣビューワは、パフォーマンス最適化処理を管理するのに必要とされる。これは、ＶＮＣビューワは一般に関連するＶＮＣセッションパラメータを制御するためである。しかしながら、これらのアプローチの何れかは、パフォーマンス最適化処理をＶＮＣサーバに管理させるため容易に変更可能である。サーバは、ビューワに対するパラメータの変更を示唆するか、又は単にビューワの嗜好を無効にする可能性がある。このような変形は、何れかのアプローチに対して有意な変更を構成するものでない。

【0121】

各アプリケーションにより利用される情報はまた変更可能である。特に、アプローチ１及び２は、ここに提供されるものより多くの又は少ない詳細を検討するよう容易に変更されてもよい。より多くの考慮が具体的な実現形態の詳細に提供されるとき、特定の情報の包含又は排除が変更される可能性がある。

【0122】

アプローチ２では、パフォーマンスボトルネックの可能性を特定するとき、ビューワ及びサーバＣＰＵコストの前に帯域幅が評価されることが提案される。これは、ＣＰＵコストが帯域幅の前に評価されるように変更されてもよい。再び、これは、アプローチに対する有意な変更を構成するものでない。

【0123】

最後に、ある実現形態を構成するため本明細書において提供されるアプローチの態様を組み合わせることが可能であってもよい。アプローチ３について、これはそれ自体がサーチ機構を提供しないため、必須である。しかしながら、これはまた、他のアプローチに関連する。例えば、アプローチ１はまた、従来技術によるアプローチに提案されるＬＳＥメトリックをそれのルールの知識ベースに内蔵できる。

【0124】

結論
本明細書は、ＶＮＣセッションの各種パラメータが当該セッションのパフォーマンスを最適化するよう自動的に調整されることを可能にするいくつかのアプローチを提案する。このパフォーマンス最適化は、ＶＮＣセッションがアクティブであるときには動的に実行されるか、又はセッションがスタートする前には静的に実行されてもよい。キャリブレーション段階が、不良なユーザ体感を生じさせることからパフォーマンス最適化を防ぐため導入されてもよい。これらのアプローチのいくつかの可能な変形がまた特定された。

【0125】

他の多数の効果的な代替が当業者に想到することは疑いない。本発明は説明された実施例に限定されず、ここに添付された請求項の趣旨及び範囲内において当業者に明らかな変更を含むことが理解されるであろう。

【図1】

【図2a】

【図2b】

【図3a】

【図3b】

【図3c】

【図4】