特許 5957519 携帯電話を遠隔制御する方法及びシステム

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

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

(11)【特許番号】5957519

(24)【登録日】2016年6月24日

(45)【発行日】2016年7月27日

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

(51)【国際特許分類】

   G06F 13/00 20060101AFI20160714BHJP

   G06F 9/48 20060101ALI20160714BHJP

【ＦＩ】

   G06F13/00 650A

   G06F9/46 452B

【請求項の数】35

【全頁数】29

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

(86)(22)【出願日】2012年5月24日

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

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

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

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

(87)【国際公開日】20121129

【審査請求日】2015年3月11日

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

(32)【優先日】2011年5月26日

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

(31)【優先権主張番号】61/497,298

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

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

(73)【特許権者】

【識別番号】512269742

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100091214

【弁理士】

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

(72)【発明者】

【氏名】グレイ，トビアス，エドワード，セバスチャン

【審査官】 木村 雅也

(56)【参考文献】

【文献】 特開平０７−２５３８９３（ＪＰ，Ａ）

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

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

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

【文献】 国際公開第２００８／１１４５２５（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１０／０２９９４３６（ＵＳ，Ａ１）

【文献】 田中 充，即座のプレイバックを可能とする双方向プレゼンテーション配信システムの提案と実装，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ）シンポジウム論文集 １９９７年〜２００６年版 Ｖｅｒ．１．１ ［ＤＶＤ−ＲＯＭ］ Multimedia,Distributed,Cooperative and Mobile Symposium，日本，社団法人情報処理学会，２００４年 ７月 ７日，第2004巻，第67頁

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

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ ９／４８

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

【請求項1】

モバイル機器であって、
複数のスレッドのうちの少なくとも１つを実行するよう構成されたプロセッサであって、前記複数のスレッドは、モバイル制御スレッド、優先度調整スレッド及び少なくとも１つの他のスレッドを含む、プロセッサと、
スレッドの、他のスレッドに対する優先度に依存して、前記プロセッサ上で実行されることになるスレッドをスケジュールするスケジューラと、
データをユーザに表示するディスプレイと、
ユーザがコマンドを入力する入力システムと、
当該モバイル機器をリモート端末に接続する通信リンクと、
を含み、
前記モバイル制御スレッドが実行中の場合、前記プロセッサは、
前記ディスプレイに現在表示されているデータをキャプチャするステップと、
前記のキャプチャされたデータを前記通信リンクを通じて送信するステップと、
ひとたび前記キャプチャされたデータが送信されると、前記優先度調整スレッドをアクティブにするように、更新送信済み通知を発行するステップと、
をなすように構成されて、
前記優先度調整スレッドが実行中の場合、前記プロセッサは、
更新送信済み通知の受信を受けると、前記受信前の閾値時間内に先行する更新送信済み通知が発行されていたかどうかを判定するステップと、
前記判定するステップが満たされる場合、
前記モバイル制御スレッドの優先度を、前記少なくとも１つの他のスレッドの優先度に対して低めるステップと、
タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、前記少なくとも１つの他のスレッドの優先度に対して高められる、ステップと、
をなすように構成される、
モバイル機器。

【請求項2】

前記優先度調整スレッドは、すべての他のスレッドよりも高い優先度を有する、請求項１に記載のモバイル機器。

【請求項3】

前記閾値時間は約７００ｍｓである、請求項１又は請求項２に記載のモバイル機器。

【請求項4】

前記タイマは約３５０ｍｓ後に終了するように設定される、請求項１乃至３のいずれか１項に記載のモバイル機器。

【請求項5】

前記優先度調整スレッドは、前記モバイル制御スレッドの優先度を、高い優先度と通常の優先度レベルとの間で変化させる、請求項１乃至４のいずれか１項に記載のモバイル機器。

【請求項6】

前記プロセッサは、前記モバイル制御スレッドが前記プロセッサを閾値量より多く使用したかどうかを判定するステップと、双方の判定するステップが満たされる場合、
前記モバイル制御スレッドの優先度を、前記少なくとも１つの他のスレッドの優先度に対して低めるステップと、
タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、前記少なくとも１つの他のスレッドの優先度に対して高められる、ステップと、
をなすように構成される、請求項１乃至５のいずれか１項に記載のモバイル機器。

【請求項7】

前記プロセッサの前記閾値量は約５０％である、請求項６に記載のモバイル機器。

【請求項8】

前記データをキャプチャするステップは、前記ディスプレイからのディスプレイ変更通知を受信することに応じるものである、請求項１乃至７のいずれか１項に記載のモバイル機器。

【請求項9】

前記モバイル制御スレッドが実行中の場合、前記プロセッサは、
前記のキャプチャされたデータを、先行してキャプチャされたデータと比較するステップ、
をなすように構成され、
前記送信するステップは、前記比較するステップで差分を検出することを条件とする、
請求項８に記載のモバイル機器。

【請求項10】

モバイル機器を制御するシステムであって、
請求項１乃至９のいずれか１項に示されるモバイル機器と、
リモート端末と、
前記リモート端末と前記モバイル機器とを接続しているデータリンクと、
を含み、
前記リモート端末は、
データをユーザに表示するディスプレイと、
ユーザがコマンドを入力する入力システムと、
前記キャプチャされたデータを前記モバイル機器から受信するステップと、前記のデータを前記リモート端末のディスプレイに表示するステップであって、前記モバイル機器のディスプレイからのデータが前記リモート端末のディスプレイに再現される、ステップと、をなすように構成されたプロセッサと、
を含む、システム。

【請求項11】

前記リモート端末のプロセッサは、
入力コマンドをキャプチャするステップと、
前記のキャプチャされた入力コマンドを前記通信リンクを通じて前記モバイル機器に送信するステップと、
をなすように構成され、
前記モバイル機器のプロセッサは、
前記キャプチャされた入力コマンドを受信するステップと、
前記キャプチャされた入力コマンドを、それらが前記モバイル機器の入力システムで入力されたかのように、実行するステップと、
をなすように構成される、
請求項１０に記載のシステム。

【請求項12】

モバイル機器とリモート端末との間でデータを送信するモバイル制御スレッドの優先度を動的に調整する方法であって、
前記モバイル機器のディスプレイに現在表示されているデータをキャプチャするステップと、
前記のキャプチャされたデータを、前記モバイル機器と前記リモート端末との間の通信リンクを通じて送信するステップと、
ひとたび前記キャプチャされたデータが送信されると、第１の更新送信済み通知を発行するステップと、
前記キャプチャするステップ及び前記送信するステップを繰り返すステップと、
ひとたび前記のキャプチャされたデータが送信されると、第２の更新送信済み通知を発行するステップと、
前記第２の更新送信済み通知の受信を受けると、前記第２の更新送信済み通知受信前の閾値時間内に前記第１の更新送信済み通知が発行されていたかどうかを判定するステップと、
前記判定するステップが満たされる場合、
前記キャプチャするステップ、送信するステップ及び発行するステップを実行する前記モバイル制御スレッドの優先度を、より高いレベルからより低いレベルに低めるステップと、
タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、前記より高いレベルに戻される、ステップと、
を含む、方法。

【請求項13】

前記判定するステップ、低めるステップ及び設定するステップは、すべての他のスレッドよりも高い優先度を有する優先度調整スレッドによって制御される、請求項１２に記載の方法。

【請求項14】

前記閾値時間は約７００ｍｓである、請求項１２又は請求項１３に記載の方法。

【請求項15】

前記タイマは約３５０ｍｓ後に終了するように設定される、請求項１２乃至１４のいずれか１項に記載の方法。

【請求項16】

前記モバイル制御スレッドの優先度は、高い優先度と通常の優先度レベルとの間で低められる、請求項１２乃至１５のいずれか１項に記載の方法。

【請求項17】

前記モバイル制御スレッドは前記モバイル機器のプロセッサを閾値量より多く使用したかどうかを判定するステップと、双方の判定するステップが満たされる場合、
前記モバイル制御スレッドの優先度を、前記少なくとも１つの他のスレッドの優先度より下に低めるステップと、
タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、前記少なくとも１つの他のスレッドの優先度より上に高められる、ステップと、
をさらに含む、請求項１２乃至１６のいずれか１項に記載の方法。

【請求項18】

前記プロセッサの前記閾値量は約５０％である、請求項１７に記載の方法。

【請求項19】

前記データをキャプチャするステップは、前記ディスプレイからのディスプレイ変更通知を受信することに応じるものである、請求項１２乃至１８のいずれか１項に記載の方法。

【請求項20】

前記キャプチャされたデータを、先行してキャプチャされたデータと比較するステップ、
を含み、
前記送信するステップは、前記比較するステップで差分を検出することを条件とする、
請求項１９に記載の方法。

【請求項21】

モバイル機器をリモート端末から制御する方法であって、
請求項１２乃至２０のいずれか１項に示される方法と、
前記キャプチャされたデータを前記モバイル機器から受信するステップと、
前記のデータを前記リモート端末のディスプレイに表示するステップであって、前記モバイル機器のディスプレイからのデータが前記リモート端末のディスプレイに再現される、ステップと、
を含む、方法。

【請求項22】

入力コマンドを前記リモート端末上でキャプチャするステップと、
前記のキャプチャされた入力コマンドを前記通信リンクを通じて前記モバイル機器に送信するステップと、
前記キャプチャされた入力コマンドを前記モバイル機器で受信するステップと、
前記キャプチャされた入力コマンドを、それらが前記モバイル機器の入力システムで入力されたかのように、前記モバイル機器上で実行するステップと、
を含む、請求項２１に記載の方法。

【請求項23】

モバイル機器であって、
複数のスレッドのうちの少なくとも１つを実行するように構成されたプロセッサであって、前記複数のスレッドは、モバイル制御スレッド、優先度調整スレッド及び少なくとも１つの他のスレッドを含む、プロセッサと、
ユーザにデータを表示するディスプレイと、
ユーザがコマンドを入力する入力システムと、
当該モバイル機器をリモート端末に接続する通信リンクと、
を含み、
前記モバイル制御スレッドが実行中の場合、前記プロセッサは、
前記ディスプレイに現在表示されているデータをキャプチャするステップと、
前記のキャプチャされたデータを前記通信リンクを通じて送信するステップと、
前記優先度調整スレッドをアクティブにするように、更新通知を発行するステップと、
をなすように構成されて、
前記優先度調整スレッドが実行中の場合、前記プロセッサは、
更新通知の受信を受けると、前記受信前の閾値時間内に先行する更新通知が発行されていたかどうかを判定するステップと、
前記判定するステップが満たされる場合、前記モバイル制御スレッドの優先度を、前記少なくとも１つの他のスレッドの優先度に対して低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、前記少なくとも１つの他のスレッドの優先度に対して高められる、ステップと、
をなすように構成される、
モバイル機器。

【請求項24】

スレッドの、他のスレッドに対する優先度に依存して、前記プロセッサ上で実行されることになるスレッドをスケジュールするスケジューラ、
をさらに含む、請求項２３に記載のモバイル機器。

【請求項25】

前記プロセッサは、ひとたび前記のキャプチャされたデータが送信されると、前記優先度調整スレッドをアクティブにするために、更新通知を送信するように構成される、請求項２３又は請求項２４に記載のモバイル機器。

【請求項26】

前記プロセッサは、前記データをキャプチャするステップの前に、前記優先度調整スレッドをアクティブにするために、更新通知を送信するように構成される、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項27】

前記優先度調整スレッドは、すべての他のスレッドよりも高い優先度を有する、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項28】

前記閾値時間は約７００ｍｓである、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項29】

前記タイマは、約２５０ｍｓ後又は約３５０ｍｓ後に終了するように設定される、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項30】

前記優先度調整スレッドは、前記モバイル制御スレッドの優先度を、高い優先度と通常の優先度レベルとの間で変化させる、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項31】

前記優先度調整スレッドは通常の優先度レベルを有する、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項32】

前記優先度調整スレッドは、前記モバイル制御スレッドの優先度を、通常の優先度と低い優先度レベルとの間で変化させる、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項33】

前記プロセッサは、前記モバイル制御スレッドが前記プロセッサを閾値量より多く使用したかどうかを判定するステップと、双方の判定するステップが満たされる場合、
前記モバイル制御スレッドの優先度を低めるステップと、
タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、元の、前のレベルに高められる、ステップと、
をなすように構成される、請求項２３乃至２５のいずれか１項に記載のモバイル機器。

【請求項34】

前記プロセッサの前記閾値量は約５０％である、請求項３３に記載のモバイル機器。

【請求項35】

モバイル機器とリモート端末との間でデータを送信するモバイル制御スレッドの優先度を動的に調整する方法であって、
前記モバイル機器のディスプレイに現在表示されているデータをキャプチャするステップと、
前記のキャプチャされたデータを、前記モバイル機器と前記リモート端末との間の通信リンクを通じて送信するステップと、
第１の更新通知を発行するステップと、
前記キャプチャするステップ及び前記送信するステップを繰り返すステップと、
第２の更新通知を発行するステップと、
前記第２の更新通知の受信を受けると、前記第２の更新通知受信前の閾値時間内に前記第１の更新通知が発行されていたかどうかを判定するステップと、
前記判定するステップが満たされる場合、
前記キャプチャするステップ、送信するステップ及び発行するステップを実行する前記モバイル制御スレッドの優先度を、より高いレベルからより低いレベルに低めるステップと、
タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は、前記より高いレベルに戻される、ステップと、
を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、携帯電話又は類似の小型ポータブル・デバイスを遠隔制御する方法及びシステムに関する。

【背景技術】

【0002】

携帯電話を表示及び制御するために、リモートコンピュータ端末を使用することが知られている。そうした構成の１つを、図１ａに示す。モバイル機器１０のディスプレイの内容を、リモートコンピュータ端末１２上に再現する。リモートコンピュータ端末はインタフェース機構を有し、それにより、ユーザは、機器上の物理的なキーを押下すること又はタッチスクリーン入力に触れることなどのユーザ入力イベントを、制御中のモバイル機器に送信することが可能となる。十分理解されるように、データリンクの形式及びリモートコンピュータ端末の種類は、使用される状況に依存して、異なってよい。

【0003】

リモートコンピュータ端末は、携帯電話を利用している顧客に機器サポートを提供するために遠隔制御設備を使用している、サポートエンジニア向けであってよい。ある会社の顧客が、携帯電話について、画像メッセージを送信できないなどの問題を抱えている場合、サポートエンジニアは、リモート端末を使用してその電話とやりとりすることによって、問題を診断及び解決することができる。あるいは、サポートエンジニアは、ユーザの携帯電話上にソフトウェア又は他の設定をインストール又は更新するために、リモート端末を使用してもよい。この場合、データリンクは一般的に、Ｗｉｆｉ、ＧＰＲＳ又はＨＳＤＰＡなどの無線通信という形式によるであろうし、リモート端末は遠距離にあってよく、例えばその携帯電話から数百マイル離れていてもよい。

【0004】

あるいは、例えば自動車産業において、リモート端末は携帯電話の近くに位置するかも知れない。リモート端末を、車のダッシュボード上に取り付けられる大型ディスプレイとして組み込む場合がある。ユーザの電話という見慣れたインタフェースをディスプレイに表示し、ユーザは音楽を再生したり地図に基づくナビゲーションを実行したりするのに、このインタフェースを使用することができる。一般的に、運転中、コンピュータゲームなどの気を散らすアプリケーションを制御する目的でユーザがリモート端末を使用することを防ぐ、追加の安全機構があるであろう。この場合、データリンクは一般的に、ＵＳＢ、又はＷｉｆｉ若しくはＢｌｕｅｔｏｏｔｈ（登録商標）などの短距離無線通信システム、などの物理的に有線の接続によるであろう。

【0005】

図１ｂは、携帯電話１０及び接続されたリモート端末１２の内部コンポーネントとそれらのやりとりとを示しているブロック図である。電話上のアクティビティを、「スレッド（thread）」に分割してよく、ここで、スレッドを、オペレーティングシステムがスケジュールすることが可能な、処理の最小単位として定義してよい。一般的に、一度に実行中となるのは一スレッドだけである。携帯電話１０は、ディスプレイシステム２０、入力システム２２及びデータリンクシステム２６を有するオペレーティングシステムを含み、それらのすべてを、ＶＮＣ（Virtual Networking Computing）サーバスレッド２４に接続する。他のスレッド、例えば他のアプリケーション（図示せず）をその電話上にインストールしてもよい。同様に、リモート端末は、ディスプレイシステム３０、制御システム３２及びデータリンクシステム３６を有するオペレーティングシステムを含み、それらのすべてを、ＶＮＣ（Virtual Networking Computing）ビューアスレッド３４に接続する。携帯電話及びリモート端末のデータリンクシステムを、上述したように接続する。

【0006】

ＶＮＣサーバスレッドの動作を図２に示す。ＶＮＣサーバスレッドは、入力イベント又はディスプレイ変更通知の受信を待つ。入力イベントを検出した場合、その入力イベントをリモート端末のオペレーティングシステムに送信する。ディスプレイ変更通知を受信した場合、携帯電話ディスプレイをキャプチャし、続いて、ＶＮＣフォーマットにエンコードし、携帯電話及びリモート端末のデータリンクシステム間の接続を通じて送信する。

【0007】

歴史的な理由で、スレッドは、ＣＰＵ（プロセッサ）時間をどれくらい必要とするかを宣言しない。代わりに、それぞれのスレッドは、
・いかなる瞬間でもＣＰＵを必要とするかどうか
・他のスレッドに対する優先度
を宣言する。

【0008】

それから、電話のオペレーティングシステムは、ＣＰＵを必要とする、優先度が最も高いスレッドを効率的に選択する。（マルチコアの電話は複数選択するであろう。）電話上の大抵のスレッドは、それら自身を特定の優先度で宣言する。例えば、バックグラウンドでのＥメールのダウンロードを必要とするアプリケーションは、それ自身に低い優先度を宣言するであろうし、一方、３Ｄゲームは、それ自身に可能な限り高い優先度を宣言するであろう。ほとんどの通常のアプリケーションは、その間のどこかであろう。

【0009】

歴史的に、電話へのリモート端末接続には、携帯電話及びリモート端末間の通信向けのＧＰＲＳ又はＨＳＤＰＡなどの技術に基づいて、無線データリンクを使用してきている。ＧＰＲＳの理論的なデータレートはおよそ１０ｋｂ／ｓであり（ただし実使用ではおよそ５ｋｂ／ｓしか見られない）、ＨＳＤＰＡデータ接続ではおよそ１Ｍｂ／ｓである（ただし実使用ではおよそ１００ｋｂ／ｓしか見られない）。これらのレートを有するデータリンクを使用することは、ボトルネックとなり、１秒あたりの更新の回数を制限し、その結果、機器のＣＰＵをＶＮＣメインスレッドが使用する時間を、減らす。

【発明の概要】

【発明が解決しようとする課題】

【0010】

しかしながら、より高速なデータリンク、データレート６０ＭＢ／ｓを有するＵＳＢ２（ただし実使用ではおよそ２Ｍｂ／ｓしか見られない）などを使用することにより、データリンクはボトルネックにならなくなる。より高速なデータレートは、ＶＮＣメインスレッドが大幅により高い頻度で更新データを送信できるということを意味する。ＶＮＣメインスレッドが使用するＣＰＵ時間を制限するメカニズムがない場合、すべてのＣＰＵ時間を更新データの送信に使用できてしまい、電話上の他のアプリケーションを何度も遅延させてしまう。例えば、Ｎｏｋｉａ５８００Ｘｐｒｅｓｓの音楽機器では、ＶＮＣメインスレッドの処理時間を制限する目的で使用するメカニズムがない場合、ビデオのロードに要する時間が６秒から１分を超えるまでに至る場合がある。

【0011】

本出願人は、携帯電話を遠隔制御するための、改善された方法及びシステムが必要とされていることを認識している。

【課題を解決するための手段】

【0012】

本発明の第１の実施形態によると、モバイル機器が提供され、当該モバイル機器は、複数のスレッドのうちの少なくとも１つを実行するように構成されたプロセッサであって、前記複数のスレッドはモバイル制御スレッド、優先度調整スレッド及び少なくとも１つの他のスレッドを含む、プロセッサと、スレッドの、他のスレッドに対する優先度に依存して、前記プロセッサ上で実行されることになるスレッドをスケジュールするスケジューラと、ユーザにデータを表示するディスプレイと、ユーザがコマンドを入力する入力システムと、当該モバイル機器をリモート端末に接続する通信リンクと、を含み、前記モバイル制御スレッドが実行中の場合、前記プロセッサは、前記ディスプレイに現在表示されているデータをキャプチャするステップと、前記のキャプチャされたデータを前記通信リンクを通じて送信するステップと、ひとたび前記キャプチャされたデータが送信されると、前記優先度調整スレッドをアクティブにするために更新送信済み通知（update sent notification）を発行するステップと、をなすように構成されて、前記優先度調整スレッドが実行中の場合、前記プロセッサは、更新送信済み通知の受信を受けると、前記受信前の閾値時間内に先行する更新送信済み通知が発行されていたかどうかを判定するステップと、前記判定するステップが満たされる場合、前記モバイル制御スレッドの優先度を前記少なくとも１つの他のスレッドの優先度に対して低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度は前記少なくとも１つの他のスレッドの優先度に対して高められる、ステップと、をなすように構成される。

【0013】

したがって、モバイル機器は、どんな優先度変更も行うか否かを判定する前に、完全な更新データが送信されるまで、待機する。前記判定するステップが満たされない場合、モバイル制御スレッドの優先度の変更は全く行われない。このようにして、モバイル制御スレッドはそれのステップ、すなわち、キャプチャするステップ、送信するステップ及び発行するステップを反復して繰り返す。前記優先度調整スレッドはもはやアクティブではないが実行可能状態であり、次にアクティブになる場合の実行を待ち受ける。タイマ終了時のモバイル制御スレッドにおける優先度の上昇は、優先度制御スレッドの制御下にあることが好ましい。したがって、優先度調整スレッドを、タイマ終了の通知の受信、及び／又は更新送信済み通知の受信のいずれかを受けると、アクティブにしてよい。アクティブ化後、優先度調整スレッドはほんの短時間だけ動作し、したがって、携帯電話のパフォーマンスに悪影響を与えることはない。

【0014】

優先度調整スレッドの機能は、モバイル制御スレッドの優先度を、より高いレベルとより低いレベルとの間で調整することであり、これらのより高いレベル及びより低いレベルとは、その機器上で動作している他のスレッドと比較してのものである。前記優先度調整スレッドは、前記モバイル制御スレッドの優先度を、高い優先度と通常の優先度レベルとの間で変化させてよい。あるいは、前記優先度調整スレッドは、前記モバイル制御スレッドの優先度を、通常の優先度と低い優先度レベルとの間で変化させる。モバイル制御スレッドの優先度を少なくとも１つの他のスレッドの優先度より上に高める（すなわち、高レベルに上げる）場合、プロセッサは、前記少なくとも１つの他のスレッドに優先して、モバイル制御スレッドを実行することになる。一方、モバイル制御スレッドの優先度を少なくとも１つの他のスレッドのものより下に低める（すなわち、低レベルに下げる）場合、モバイル制御スレッドは、前記他のスレッドが実行中でない場合にのみ、動作するであろう。モバイル制御スレッドの優先度が前記他のスレッドとほぼ同一である（すなわち通常レベルに設定されている）場合、スケジューラは、それのルールに依存して、どちらかのスレッドを選択するであろう。他のスレッドが複数ある場合、優先度調整スレッドは、モバイル制御スレッドの優先度を、すべての他のスレッドのうちの最も高い優先度と最も低い優先度との間で調整してよい。あるいは、優先度調整スレッドは、他のスレッドの優先順位を付けするために、すべてのスレッドではなくともいくつかのスレッドよりも上に、モバイル制御スレッドの優先度を高めてよい。前記優先度調整スレッドは、トリガ信号を受信した場合にその動作を保証するために、すべての他のスレッドよりも高い固定の優先度を有することが好ましい。このようにして、オペレーティングシステム内でのタスクスケジューリングを改善するため、優先度調整スレッドは機器のパフォーマンスの向上をもたらす。

【0015】

一方、ＶＮＣサーバは一般的に、ＶＮＣサーバスレッドについて固定の優先度を使用する。しかしながら、本出願人は、固定の優先度は適切ではないと認識している。優先度が高く固定され、高帯域が存在する（例えば、上述の自動車用途において）場合、ＶＮＣサーバは、ビューアに連続的に更新データを送信する必要があるであろう。したがって、ＶＮＣサーバは、ＣＰＵを連続的に必要とするものとしてそれ自身を宣言するであろうし、通常のアプリケーションのような、より低い優先度のタスクは動作しなくなるであろう。対照的に、優先度を低く固定する場合、他の高い優先度のスレッド、例えば３Ｄゲームなどが画面に連続的に描画することを必要とするであろうし、したがってＣＰＵを連続的に使用するであろう。それに応じて、ＶＮＣサーバスレッドは、その画面イメージをビューアに送信する機会を全く持てないおそれがある。それゆえに本書で説明する発明は、種々のアプリケーションによって使用されるＣＰＵリソースに依存して優先度を変化させることによって、内蔵されたＣＰＵのパフォーマンスを向上する。そして、モバイル機器は、当該モバイル機器上で動作しているどんなアプリケーションの要求も満たすように適応することが可能である。

【0016】

これらの制約は、モバイル機器では特に深刻である。なぜならば、ＰＣとは違って、アプリケーションが、いくらかの情報を提供するために遅い機械的なハードディスクを待っている間、ＣＰＵを放棄しない可能性があるからである。これは、モバイル機器が有する一般的により遅いＣＰＵクロックレート（それゆえに一定時間内の動作がより少ない）と、遅い機械的なディスクがないこととに起因して、モバイル機器上では発生しない。したがって、単一の高い優先度のスレッドが中断なくＣＰＵを連続的に使用することを、目にすることがより一般的である。

【0017】

携帯電話よりも多くのハードウェア制約を有するシステムは、たいてい、リアルタイムオペレーティングシステム（Real Time Operating Systems；ＲＴＯＳ）を実行しているであろうし、ひとたび機器が生成されたら追加のソフトウェアを加える機能がほぼない、又は全くないであろう。追加のソフトウェアを加えられないことが、スケジューリングを扱う場合にスレッド間の協同的なマルチタスキングを可能とし、したがって、動的な優先度調整を行う必要性を除外する。ＲＴＯＳでは、本発明が取り扱う優先度に基づいてスケジューリングするオペレーティングシステムに代わって、デッドライン・スケジューリング手法を使用することも通例である。

【0018】

このようにして、モバイル制御スレッドと優先度調整スレッドとの間のやりとりは、２つの競合するもの、すなわち、
ａ）リモート端末の画面更新データのビューアが電話画面にすぐ応答するビューを得るように、画面更新データを頻繁に送出すること
ｂ）電話上の他のアプリケーションソフトウェア（すなわち、少なくとも１つの他のスレッド）のパフォーマンスにマイナスの影響を与えるほど、多くの電話ＣＰＵを使用しないこと
の平衡を保っている。

【0019】

本発明は、適応的な種類のＶＮＣプロトコルを使用する。より遅いデータレートを使用する場合、複数の画面更新データを、リモート端末上で単一の更新データにマージしてよい。歴史的に見て、これが、より遅いデータリンクをサポートしてきている。しかしながら本発明では、複数の画面更新データが発生する可能性はあるが、モバイル制御スレッドは優先度が低められている間はそれらについて対処しない。結果としてこの適応性は、遠隔制御されている携帯電話のＣＰＵ上でＶＮＣメインスレッドによって使用されるＣＰＵ時間を、減らすことに用いられている。

【0020】

上記で説明したように、電話の遠隔制御は、例えば、ネットワークオペレータやヘルプデスクによって、及び車内で使用される可能性がある。これを行うために、モバイル制御ビューアスレッド又は「ＶＮＣビューア」をヘルプデスク／車にインストールすることが好ましく、モバイル制御スレッド又は「ＶＮＣサーバ」をモバイル機器にインストールすることが好ましい。

【0021】

このようにして、本発明の別の態様によると、モバイル機器を制御するシステムが提供され、当該システムは、上述したモバイル機器と、リモート端末と、前記リモート端末と前記モバイル機器とを接続しているデータリンクと、を含み、前記リモート端末は、データをユーザに表示するディスプレイと、ユーザがコマンドを入力する入力システムと、前記キャプチャされたデータを前記モバイル機器から受信するステップと、前記のデータを前記リモート端末のディスプレイに表示するステップであって、前記モバイル機器のディスプレイからのデータが前記リモート端末のディスプレイに再現される、ステップと、をなすように構成されたプロセッサと、を含む。

【0022】

以下の随意的な特性が上述のすべての態様に当てはまる。

【0023】

遠隔制御を実行する影響を最小化する一方で、妥当な更新レート（毎秒１乃至５フレーム）を提供するために、以下の閾値
・閾値時間 − ７００ｍｓ
・前記プロセッサの閾値量 − ５０％
・タイマ時間 − ３５０ｍｓ
を使用してよい。

【0024】

前記データをキャプチャするステップは、前記ディスプレイからのディスプレイ変更通知の受信に応じるものであってよい。言い換えると、モバイル制御スレッドを、前記ディスプレイが発行するディスプレイ変更通知によって、アクティブにしてよい。モバイル制御スレッドが次のアクティブ化を実行するか否かは、他のスレッドに対するモバイル制御スレッドの優先度と、こうした他のスレッドが実行中であるか否かとに依存する。

【0025】

前記データをキャプチャするステップはさらに、キャプチャされたデータをデータリンクを通じて送信するのに適切な形式にエンコードする、エンコードするステップを含んでよい。

【0026】

前記プロセッサをさらに、前記モバイル制御スレッドが前記プロセッサを閾値量より多く使用したかどうかを判定するように、構成してよい。前記第２の判定するステップを、前記第１の判定するステップと同時に行ってよい。双方の判定するステップが満たされる場合に限り、プロセッサは、前記モバイル制御スレッドの優先度を前記少なくとも１つの他のスレッドの優先度より下に低めることになり、かつ、タイマを設定し、タイマが終了した場合、前記モバイル制御スレッドの優先度を前記少なくとも１つの他のスレッドの優先度より上に高めることになる。双方の前記判定するステップは、モバイル制御スレッドがモバイル機器上で実行中の間に、行われてよい。プロセッサの使用量を判定する方法は多くあり、これを、モバイル制御スレッド自身又は別のスレッドが判定してよい。

【0027】

モバイル制御スレッドによるプロセッサ使用量を考慮することは、モバイル制御スレッドがどれほどその機器のスピートを落としているかで決定する場合、いくらかの当て推量を除外するため、有利である。その判定するステップは、モバイル制御スレッドがプロセッサを他のどのスレッドよりも長く使用していたか否かを、判定することを含んでよい。言い換えると、その決定には、経過時間（実時間）を使用することを含む。これは、システム内のモバイル制御スレッドと他のスレッドとの間でかなり対等に平衡を保っているような状況において、有益である。しかしながら、この方法は、低速のデータリンクと非常にストレスを加えられたシステムとには、有益性が低くなる。

【0028】

その判定するステップは、モバイル制御スレッドの種々のステップの各々がどれほどの時間プロセッサを使用したのかを判定することを含んでよく、そして、前記のキャプチャするステップ、特に、エンコードするステップが他のどのスレッドよりも長く動作したのかどうかを判定してよい。

【0029】

例えば、プロセッサは、モバイル制御スレッドが更新の実行に閾値時間（例えば７００ｍｓ）全体を要したと、判定するかもしれない。低速のデータリンクの場合、モバイル制御スレッドはその時間のうちのごく一部の間だけプロセッサを使用したという可能性がある。時間の大半は、通信リンクを通じてデータを転送することに占められたもので、これが発生する間、プロセッサは他のスレッドを実行する。この場合、モバイル制御スレッドの優先度を低めることは、その機器に対するモバイル制御スレッドの影響を減らすことなく、更新頻度を減らすことになる（いずれにせよごく一部の時間しか使用していなかったため）。したがって、この場合、モバイル制御スレッドの優先度を低めることは望ましくない。

【0030】

更新の実行に７００ｍｓを要することは、モバイル制御スレッドがデータリンクを通じて送信するデータをエンコードするために、５００ｍｓというＣＰＵ時間を要しているような状況においても、発生する可能性がある。この場合、モバイル制御スレッドを抑制することが望ましい。そうでなければ、システムで実行中の、「有益な」作業を行っている他のスレッドが、３０％のＣＰＵ時間しか得られないことになり、ゆえに、実行に３倍以上かかってしまうことになる。エンコードにどれほどのＣＰＵ時間を要するかは、エンコードするものに依存して、大きく変化する可能性がある。

【0031】

これは、機器間（現今発売されている機器は、４年前に発売された機器よりもかなり速いプロセスを有している）と、同じ機器上（単に黒い色の画面は、多くの細かい詳細を有する画面よりもエンコードがはるかに容易である）とに当てはまる。

【0032】

前記モバイル制御スレッドが実行中の場合、プロセッサを、前記のキャプチャされたデータを先行してキャプチャされたデータと比較するように構成してよく、前記送信するステップは、前記の比較するステップで差分検出することを条件としてよい。このようにして、不必要なデータ送信を回避する。

【0033】

前記キャプチャされたデータを、リモート端末への送信に適切なデータフォーマットにエンコードしてよい。リモート端末は、前記モバイル機器とは物理的に分かれているものであり、前記モバイル機器から離れたところに位置していてよい。しかしながら、リモート端末はさらに、例えば上述の車内の配置のように、モバイル機器の近くに位置していてもよい。

【0034】

前記リモート端末のプロセッサを、入力コマンドをキャプチャするステップと、前記キャプチャされた入力コマンドを前記通信リンクを通じて前記モバイル機器に送信するステップとをなすように、構成してよい。そして、前記モバイル機器のプロセッサを、前記キャプチャされた入力コマンドを受信するステップと、前記キャプチャされた入力コマンドを、それらがモバイル機器の入力システムで入力されたかのように、実行するステップとをなすように、構成してよい。このようにして、ユーザは、モバイル機器をリモート端末から制御することが可能となる。モバイル制御スレッドを、前記リモート端末からの入力コマンドの受信、及び／又は前記携帯電話のディスプレイからのディスプレイ変更通知の受信を受けると、アクティブにしてよい。

【0035】

本発明の別の態様によると、モバイル機器とリモート端末との間でデータを送信するモバイル制御スレッドの優先度を動的に調整する方法が提供され、当該方法は、前記モバイル機器のディスプレイに現在表示されているデータをキャプチャするステップと、前記のキャプチャされたデータを、前記モバイル機器と前記リモート端末との間の通信リンクを通じて送信するステップと、ひとたび前記キャプチャされたデータが送信されると、第１の更新送信済み通知を発行するステップと、前記キャプチャするステップ及び前記送信するステップを繰り返すステップと、ひとたび前記のキャプチャされたデータが送信されると、第２の更新送信済み通知を発行するステップと、前記第２の更新送信済み通知の受信を受けると、前記第２の更新送信済み通知受信前の閾値時間内に前記第１の更新送信済み通知が発行されていたかどうかを判定するステップと、前記判定するステップが満たされる場合、前記のキャプチャするステップ、送信するステップ及び発行するステップを実行する前記モバイル制御スレッドの優先度を、より高いレベルからより低いレベルに低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度が、前記より高いレベルに戻される、ステップと、を含む。

【0036】

前の態様と同様に、前記判定するステップが満たされない場合、モバイル制御スレッドの優先度の変更は全く行われない。このようにして、モバイル制御スレッドは、それのステップ、すなわち、キャプチャするステップ、送信するステップ及び発行するステップを反復して繰り返す。前記判定するステップ、低めるステップ及び設定するステップを、上述のように、優先度調整スレッドが制御してよい。それに応じて、上述の随意的な特性が本発明のこの態様に同様に当てはまる。

【0037】

本発明の別の態様によると、モバイル機器が提供され、当該モバイル機器は、複数のスレッドのうちの少なくとも１つを実行するように構成されたプロセッサであって、前記複数のスレッドは、モバイル制御スレッド、優先度調整スレッド及び少なくとも１つの他のスレッドを含む、プロセッサと、ユーザにデータを表示するディスプレイと、ユーザがコマンドを入力する入力システムと、当該モバイル機器をリモート端末に接続する通信リンクと、を含み、前記モバイル制御スレッドが実行中の場合、前記プロセッサは、前記ディスプレイに現在表示されているデータをキャプチャするステップと、前記のキャプチャされたデータを前記通信リンクを通じて送信するステップと、前記優先度調整スレッドをアクティブにするように、更新送信済み通知を発行するステップと、をなすように構成されて、前記優先度調整スレッドが実行中の場合、前記プロセッサは、更新送信済み通知の受信を受けると、前記受信前の閾値時間内に先行する更新送信済み通知が発行されていたかどうかを判定するステップと、前記判定するステップが満たされる場合、前記モバイル制御スレッドの優先度を、前記少なくとも１つの他のスレッドの優先度に対して低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度が、前記少なくとも１つの他のスレッドの優先度に対して高められる、ステップと、をなすように構成される。

【0038】

本発明の別の態様によると、モバイル機器とリモート端末との間でデータを送信するモバイル制御スレッドの優先度を動的に調整する方法が提供され、当該方法は、前記モバイル機器のディスプレイに現在表示されているデータをキャプチャするステップと、前記のキャプチャされたデータを、前記モバイル機器と前記リモート端末との間の通信リンクを通じて送信するステップと、第１の更新通知を発行するステップと、前記キャプチャするステップ及び前記送信するステップを繰り返すステップと、第２の更新通知を発行するステップと、前記第２の更新送信済み通知の受信を受けると、前記第２の更新通知受信前の閾値時間内に前記第１の更新通知が発行されていたかどうかを判定するステップと、前記判定するステップが満たされる場合、前記キャプチャするステップ、送信するステップ及び発行するステップを実行する前記モバイル制御スレッドの優先度を、より高いレベルからより低いレベルに低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度が、前記より高いレベルに戻される、ステップと、を含む。

【0039】

これら直近の２つの態様において、前記モバイル制御スレッドが実行中の場合、プロセッサを、前記送信するステップに応じて、更新送信済み通知を発行するように構成してよい。言い換えると、前記更新通知を、キャプチャを完了し、モバイル機器からリモート端末へディスプレイ更新を送信した後に、送出する。あるいは、プロセッサを、前記キャプチャするステップに先行して、更新通知を発行するように構成してもよい。この場合、その更新通知は、更新送信中通知と名づけられるであろう。

【0040】

メトリック（metric）としてはビューアがリモート端末で見ているものを有益なものにしっかりと近づける必要があるため、更新送信済み通知のタイミングは重要である。遅いデータリンクをモバイル機器とリモート端末との間で使用している場合、データリンクを通じてデータを送信するのに要する時間を考慮に入れる必要がある。遅いデータリンクは、データ転送に要する時間のため、いくらかの抑制を更新レートに加えるであろう
部分的な更新はそれほどユーザの役に立たないため、更新の終了を使用することもまた有利である。例えば、モバイル機器のユーザインタフェースが、はいボタンといいえボタンとをインタフェース下部に有し、ユーザに「このファイルを削除しますか？」と問いかけていることを想像しよう。その機器が、この質問を有する画面をエンコードし始め、しかしその後、更新の途中で抑制されてしまう場合、ユーザは、その質問を有する、画面の最初の半分だけを見ることになる。ユーザは、「はい」及び「いいえ」のボタンを有する残りの更新が送信されてくるまで、応答するために何をすべきかわからないであろう。

【0041】

優先度の調整を考慮する以前に、完全な更新が送信されてくるまで待つことによって、ユーザは、質問及びボタンを有する完全な画面を受信するであろう。この場合、遅いデータリンクにおいて活用されていたデータ転送時間と同様に、テキストを読んで対応方針を決定するのにユーザが費やす時間を、抑制方法として用いることが可能である。機器のユーザインタフェースがアニメ化されている（例えば、はいボタン及びいいえボタンが燃えるようなアニメーションを有する）場合でさえも、優先度のどんな調整もが、第１の更新が完全に行われた後にのみ発生することになる。これのユーザへの影響は、ボタンのアニメーションが滑らかでないことくらいであろう。応答性及び機器の遠隔制御に要する時間は、影響を受けない。

【0042】

上述された随意的な特性がさらに当てはまる。

【0043】

上記態様の各々において、モバイル機器上で動作するよう構成可能な他のスレッドは、連続的に動作するスレッド、例えばゲーム、及び／又は、単一の固定長の時間動作するスレッド、例えばブラウザのダウンロード、及び／又は、複数の短いバーストを実行するスレッドであってよい。

【0044】

上記態様の各々において、モバイル制御スレッドの優先度を調整している。しかしながら、十分理解されるように、本発明は、プロセッサの能力が限定されるような機器での速やかな動作を保証することに対して、より一般的な適用可能性を有する。この場合、スレッドは、動作を完了した場合に、更新動作通知を発行してよい。

【0045】

このようにして、本発明の別の態様によると、機器が提供され、当該機器は、複数のスレッドのうちの少なくとも１つを実行するように構成されたプロセッサであって、前記複数のスレッドは、第１のスレッド、優先度調整スレッド及び少なくとも１つの他のスレッドを含む、プロセッサと、スレッドの、他のスレッドに対する優先度に依存して、前記プロセッサ上で実行されることになるスレッドをスケジュールするスケジューラと、ユーザにデータを表示するディスプレイと、ユーザがコマンドを入力する入力システムと、を含み、前記第１のスレッドが実行中の場合、前記プロセッサは、ひとたび前記第１のスレッドが動作を完了すると、前記優先度調整スレッドをアクティブにするように、更新動作通知を発行するステップ、をなすように構成されて、前記優先度調整スレッドが実行中の場合、前記プロセッサは、更新動作通知の受信を受けると、前記受信前の閾値時間内に先行する更新動作通知が発行されていたかどうかを判定するステップと、前記判定するステップが満たされる場合、前記モバイル制御スレッドの優先度を、前記少なくとも１つの他のスレッドの優先度より下に低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記モバイル制御スレッドの優先度が、前記少なくとも１つの他のスレッドの優先度より上に高められる、ステップと、をなすように構成される。

【0046】

同様にして、本発明の別の態様によると、第１のスレッドの優先度を動的に調整する方法が提供され、当該方法は、ひとたび前記第１のスレッドが動作を完了すると、第１の更新動作通知を発行するステップと、ひとたび前記第１のスレッドがその次の動作を完了すると、第２の更新動作通知を発行するステップと、前記第２の更新動作通知の受信を受けると、前記第２の更新動作通知受信前の閾値時間内に前記第１の更新動作通知が発行されていたかどうかを判定するステップと、前記判定するステップが満たされる場合、前記第１のスレッドの優先度を、より高いレベルからより低いレベルに低めるステップと、タイマを設定するステップであって、前記タイマが終了した場合、前記第１のスレッドの優先度が前記より高いレベルに戻される、ステップと、を含む。

【図面の簡単な説明】

【0047】

本発明を、例示として、以下の添付図面において図式的に説明する。

【図1a】既知の遠隔制御システムを示している略ブロック図である。

【図1b】既知の遠隔制御システムを示している略ブロック図である。

【図2】図１ａ及び図１ｂのシステム上で実施される方法を設計しているフローチャートである。

【図3】本発明の一実施形態による遠隔制御システムに関するコンポーネントを示しているブロック図である。

【図4a】それぞれ、ＶＮＣサーバスレッド及びＶＮＣサーバ優先度調整スレッドが従うステップのフローチャートである。

【図4b】それぞれ、ＶＮＣサーバスレッド及びＶＮＣサーバ優先度調整スレッドが従うステップのフローチャートである。

【図4c】それぞれ、別のＶＮＣサーバスレッド及びＶＮＣサーバ優先度調整スレッドが従うステップのフローチャートである。

【図4d】それぞれ、別のＶＮＣサーバスレッド及びＶＮＣサーバ優先度調整スレッドが従うステップのフローチャートである。

【図5a】それぞれ、４つの異なるアプリケーションスレッドによって用いられる方法のステップのフローチャートである。

【図5b】それぞれ、４つの異なるアプリケーションスレッドによって用いられる方法のステップのフローチャートである。

【図5c】それぞれ、４つの異なるアプリケーションスレッドによって用いられる方法のステップのフローチャートである。

【図5d】それぞれ、４つの異なるアプリケーションスレッドによって用いられる方法のステップのフローチャートである。

【図6a】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ａのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図6b】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ａのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図7a】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ｂのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図7b】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ｂのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図8a】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ｃのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図8b】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ｃのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図9a】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ｄのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

【図9b】それぞれ、図４ａ又は図４ｃのシステムを使用している図５ｄのアプリケーションスレッドに関して、優先度の変化を時間と共に図示する。

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

【0048】

本発明による遠隔制御システムは、図１ａ及び１ｂに示す既知のシステムのための適応（adaptation）である。図１ａ及び１ｂに示すように、本発明において、モバイル機器のディスプレイの内容を、リモートコンピュータ端末上に再現する。さらに、本発明は、既知のシステムの内部コンポーネントも含む。したがって、その携帯電話は、ディスプレイシステム、入力システム及びデータリンクシステムを有するオペレーティングシステムを含み、それらのすべてをＶＮＣサーバスレッド（モバイル制御スレッド）に接続する。同様に、リモート端末は、ディスプレイシステム、制御システム及びデータリンクシステムを有するオペレーティングシステムを含み、それらのすべてをＶＮＣビューアスレッドに接続する。

【0049】

図３は、既知のシステムを本発明に照らしてどのように適応させるかを示す。図３に示すコンポーネントをモバイル機器の内部に備えることが好ましいが、十分理解されるように、別の構成もまた可能である。上記のように、ディスプレイシステム４０、入力システム４２及びデータ通信システム４６を、ＶＮＣサーバスレッド４４に接続する。データ通信システム４６をデータリンク４８（例えば、ＵＳＢ、ＧＰＲＳ、３Ｇ）に接続して、別の機器に接続する。中心となる適応は、ＶＮＣサーバ優先度調整スレッド５４を含むことであり、以下でより詳細に説明する。図３はまた、スケジューラ５２とそれに接続されるプロセッサ５０というさらなるコンポーネントも示す。追加のアプリケーションスレッド５６を、随意に携帯電話上にインストールしてもよく、これらの随意のスレッド、及びこれらと他のコンポーネントとのやりとりを、破線で示す。

【0050】

図４ａは、図３のＶＮＣサーバスレッド（モバイル制御スレッド）が実行するステップを示しているフローチャートである。このスレッドは、ＶＮＣ作業の大半を行い、固定の優先度を持たない。そのＶＮＣサーバスレッドは、図２のＶＮＣサーバスレッドと同様に、入力イベント又はディスプレイ変更通知の受信を待つ。入力イベントを検出した場合、その入力イベントをリモート端末のオペレーティングシステムに送信し、スレッドは待機へとループバックする。ディスプレイ変更通知を受信した場合、携帯電話ディスプレイをキャプチャする。しかしながら、図２に示す処理とは対照的に、続いてＶＮＣスレッドは、ディスプレイ内に何らかの変更を検出できるか否かを判定する。何の変更も検出されない場合、スレッドは待機へとループバックする。変更が検出された場合、携帯電話ディスプレイを、ＶＮＣフォーマットにエンコードし、携帯電話及びリモート端末のデータリンクシステム間の接続を通じて送信する。処理を再び繰り返す前の最後のステップは、ＶＮＣサーバスレッドが、更新がまさに発生したということをＶＮＣサーバ優先度調整スレッドに通知することである。

【0051】

図４ｂは、図３のＶＮＣサーバ優先度調整スレッドが実行するステップを示しているフローチャートである。このスレッドは専ら、ＶＮＣサーバスレッドの優先度を調整するために存在する。ＶＮＣサーバ優先度調整スレッドは、可能な限り高い優先度で動作するが、ＶＮＣメインスレッドの優先度の調整から離れたいかなる動作も実行しない。優先度調整スレッドは時には、ＶＮＣメインスレッドの優先度を通常の優先度に低めて、一定時間経過後に、ＶＮＣメインスレッドを元の高い優先度に戻す。優先度調整スレッドは、更新されたフレームの送信の完了（すなわち、図４ａに示す最後のステップ）を、ＶＮＣメインスレッドの優先度を低めるべきかどうかをチェックするトリガとして使用する。

【0052】

図４ｂに示すように、最初の判断は、優先度タイマが終了したかどうか、又は、更新通知を受信したかどうかを、ＶＮＣサーバ優先度調整スレッドが判定することである。タイマが終了している場合、ＶＮＣサーバ優先度調整スレッドは、ＣＰＵにアクセスできることを保証するために、ＶＮＣサーバスレッドの優先度を高い優先度に設定する。更新通知を受信した場合、ＶＮＣサーバ優先度調整スレッドは、先行する通知をいつ受信したか、及び、上記先行する通知を、所定の閾値時間（例えば７００ｍｓ）内に受信していたかどうかを判定する。通知間の時間間隔が、所定の時間よりも大きい場合、ＶＮＣサーバ優先度調整スレッドは、最初の判断ステップにループバックする。通知間の時間間隔が固定の時間よりも小さい場合、ＶＮＣサーバ優先度調整スレッドは、ＶＮＣサーバスレッドが前の更新以後にプロセッサを所定の量（例えば５０％）より多く使用していたかどうかを判定する。

【0053】

ＶＮＣサーバスレッドが所定よりも多くのＣＰＵ量を使用していなかった場合、ＶＮＣサーバ優先度調整スレッドは、最初の判断ステップにループバックする。ＶＮＣサーバスレッドが所定よりも多くのＣＰＵ量を使用していた場合、あるいは、ＶＮＣサーバ優先度調整スレッドにて処理がどれほど使用したかを特定できない場合、ＶＮＣサーバ優先度調整スレッドは、優先度タイマを３５０ｍｓに設定する。さらにＶＮＣサーバ優先度調整スレッドは、ＶＮＣサーバスレッドの優先度を低め、例えば、ＶＮＣサーバスレッドを通常の優先度に設定する。その後、ＶＮＣサーバ優先度調整スレッドは、最初の判断ステップにループバックし、処理を再び繰り返す。

【0054】

遠隔制御を実行する影響を最小化する一方で、妥当な更新レート（毎秒１乃至５フレーム）を提供するために、以下の閾値
・更新閾値 − ７００ｍｓ
・ＣＰＵ使用量閾値 − ５０％
・低い優先度の期間 − ３５０ｍｓ
を使用する。

【0055】

これらの数字は単に例示に過ぎず、他の値を検討してもよいということが、十分理解されるであろう。

【0056】

図４ｃは、図３において実行可能な、別のＶＮＣサーバスレッドが実行するステップを示しているフローチャートである。この場合も先と同様に、このスレッドはＶＮＣ作業の大半を行い、固定の優先度を持たない。ＶＮＣサーバスレッドは、図４ｃのＶＮＣサーバスレッドと同様に、入力イベント又はディスプレイ変更通知の受信を待ち受ける。入力イベントを検出した場合、その入力イベントをリモート端末のオペレーティングシステムに送信し、スレッドは待機へとループバックする。しかしながら、図４ａとは異なり、ディスプレイ変更通知を受信した場合、ＶＮＣサーバ優先度調整スレッドに更新が始まったことを通知すると同時に、携帯電話ディスプレイをキャプチャする。

【0057】

続いて、ＶＮＣスレッドは、ディスプレイ内に何らかの変更を検出できるか否かを判定する。何の変更も検出されない場合、スレッドは待機へとループバックする。変更を検出した場合、ＶＮＣスレッドの優先度を通常へとリセットすると同時に、携帯電話ディスプレイをＶＮＣフォーマットにエンコードする。それから、エンコード済みのフォーマットを、携帯電話及びリモート端末のデータリンクシステム間の接続を通じて送信する。これが、処理を繰り返す前の最後のステップとなる。

【0058】

図４ｄは、図３において実施可能な、別のＶＮＣサーバ優先度調整スレッドが実行するステップを示しているフローチャートである。このスレッドは専ら、ＶＮＣサーバスレッドの優先度を調整するために存在する。しかしながら、図４ｂで示すスレッドとは対照的に、ＶＮＣサーバ優先度調整スレッドは、通常の優先度で動作する。以下でより詳細に説明するが、優先度調整スレッドは、一定の期間（おそらく２５０ｍｓ）、ＶＮＣメインスレッドの優先度を、通常の優先度から低い優先度に低める。優先度調整スレッドは、優先度を低めることに変更の通知を使用し、通常の優先度に戻すことに変更検出コードの終了の通知を使用する。したがって、図４ａ及び４ｂとは対照的に、優先度の変更が、更新データをエンコードしてリモート端末に送信する時点とは、直接結びつかない。さらに、更新データのエンコード及び送信は常に通常の優先度において発生する。

【0059】

図４ｄに示すように、最初の判断は、優先度タイマが終了したかどうか、又は、更新通知を受信したかどうかを、ＶＮＣサーバ優先度調整スレッドが判定することである。タイマが終了している場合、ＶＮＣサーバ優先度調整スレッドは、ＣＰＵにアクセスできることを保証するために、ＶＮＣサーバスレッドの優先度を通常の優先度に設定する。更新通知を受信した場合、ＶＮＣサーバ優先度調整スレッドは、先行する通知をいつ受信したか、及び、上記先行する通知を、所定の閾値時間（例えば２５０ｍｓ）内に受信していたかどうかを判定する。通知間の時間間隔が、所定の時間よりも大きい場合、ＶＮＣサーバ優先度調整スレッドは、最初の判断ステップにループバックする。

【0060】

しかしながら、図４ｂに示す処理とは対照的に、通知間の時間間隔が固定の時間よりも小さい場合、ＶＮＣサーバ優先度調整スレッドは、低優先度タイマ（low priority timer）がすでに設定されていなければ、その先の２５０ｍｓに対する低優先度タイマを設定する。ＶＮＣサーバ優先度調整スレッドはまた、ＶＮＣサーバスレッドの優先度を低め、例えば、ＶＮＣサーバスレッドを低い優先度に設定する。その後、ＶＮＣサーバ優先度調整スレッドは、最初の判断ステップにループバックし、処理を再び繰り返す。

【0061】

したがって、２つの代替手段の間には注目すべき違いがある。例えば、図４ａ及び４ｂにおいて、ＶＮＣサーバ優先度調整スレッドは、ＶＮＣスレッドの優先度を、高い優先度と通常の優先度との間で変化させる。しかしながら、図４ｃ及び４ｄにおいて、ＶＮＣサーバ優先度調整スレッドは、ＶＮＣスレッドの優先度を、通常の優先度と低い優先度との間で変化させる。さらに、図４ａ及び４ｂの優先度タイマで使用される閾値は３５０ｍｓである一方、図４ｃ及び４ｄに関する閾値は２５０ｍｓである。

【0062】

図５ａ乃至５ｄは、携帯電話上で実行可能な、４つの異なるアプリケーションスレッドの動作、すなわち、
１．一定のＣＰＵ使用量 − ゲームアプリケーション
２．低いＣＰＵ使用量 − ハードウェアでアクセラレートされるビデオ再生
３．固定のＣＰＵ使用量 − ウェブブラウザ
４．ＵＩ制御 − 次のページへのスクローリング
を示す。

【0063】

図５ａは、携帯電話のプロセッサを絶えず使用するアプリケーション、例えば、ゲームアプリケーションを示す。図示するように、ゲームアプリケーションスレッドは、各描画時点でゲームの状態を計算することと、ディスプレイにゲーム状態を描画することとの間を連続的にループする。図５ｂは、プロセッサを大量には使用しないアプリケーションスレッド、例えば、ハードウェアでアクセラレートされるビデオ再生を示す。図示するように、スレッドは、最初にハードウェアに次のビデオフレームをデコードすることを要求すること、そのデコードを待つこと、そしてデコードされたフレームをディスプレイに描画することの間をループする。

【0064】

図５ｃは、プロセッサの使用量を固定しているアプリケーションスレッド、例えば、ウェブブラウザを示す。図５ａ及び５ｂとは対照的に、連続的なループは無い。図示するように、スレッドは、ウェブページを表示するためのユーザ要求を受け、サーバからのウェブページを要求し、ウェブページをダウンロードし、ウェブページをデコードし、ウェブページをディスプレイにレンダリングし、そして終了する。図５ｄは、ユーザインタフェースを制御するアプリケーションスレッド、例えば、次のページへのスクローリングを示す。図５ｃと同様に、連続的なループは無い。最初にユーザがダウンキーを押下し、続いてアプリケーションが次のページを画面に描画し、そして終了する。

【0065】

図６ａ〜９ｂは、上記４つの例示的なスレッドに、ＶＮＣサーバ優先度調整スレッドの実装がどのように影響を及ぼすのかを示す。目標は、他にＣＰＵを使用したいものがいない場合に、ビューアに多くの画面更新データを送信することであり、さらに、他のものがＣＰＵ全体を使用しようとしている場合であっても、時には単独の更新データを送信することである。以下でより詳細に示すが、その解決法は、ＣＰＵを放棄する通常のアプリケーションにおいても、ＣＰＵを連続的に使用するゲームのようなアプリケーションにおいてもどちらでも功を奏する。

【0066】

図６ａ〜９ｂの各々において、破線を用いて示すスレッドは、実行可能であるが実行中ではなく、実線を用いてグレースケールで示すスレッドは、実行可能であり実行中である。矢印は、ＶＮＣサーバスレッドからＶＮＣサーバ優先度調整スレッドへの更新の通知を示す。水平な点線の各々の左にある円内の文字は、その点線が表す優先度を示す。最も高い優先度をアスタリスク（“＊”）で表し、高い優先度を文字“Ｈ”、通常の優先度を文字“Ｎ”、低い優先度を文字“Ｌ”とする。稲妻記号は、ＶＮＣメインスレッドがディスプレイへの変更を検出した場合を表し、星記号はＶＮＣメインスレッドが更新データの送信を完了した場合を表し、シェブロン（chevron）は、他のスレッドがディスプレイを変更した場合を示す。

【0067】

図６ａ及び６ｂは、ＣＰＵを常時使用する、例示的なゲームアプリケーションを示す。図６ａには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ゲームスレッドと、ＶＮＣメインスレッドとがある。ＶＮＣスレッドらが取るステップを、図４ｃ及び４ｄが示す。ゲームスレッド及びＶＮＣメインスレッドの双方が通常の優先度で動作する。さらにＶＮＣメインスレッドは、低い優先度と通常の優先度との間で変化する。明確にするために、通常の優先度で実行しているゲームスレッドとＶＮＣメインスレッドとを図６ａで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。最初はゲームスレッドが実行中である。６０１とラベル付けされたポイントで、ＶＮＣメインスレッドがディスプレイ変更通知を受信し、更新通知を優先度スレッドに送信する。このようにして優先度スレッドは、更新を始めたメインスレッドから受信した更新通知に応じて動作する。前回の更新から２５０ｍｓを上回っているため、ゲームスレッドは中断され、ＶＮＣメインスレッドはリモート端末へのデータをキャプチャし、エンコードし、送信する。星記号で示すように、ひとたびこれらのステップを完了すると、ＶＮＣメインスレッドは実行可能へと変化し、ディスプレイ変更の通知又は入力イベントを待ち受ける状態となって、ゲームスレッドが再開される。２５０ｍｓは単に例示であって他の時間を使用してもよいということが、十分理解されるであろう。

【0068】

続いて６０２とラベル付けされたポイントにおいて、第２の更新通知を優先度スレッドが受信し、優先度スレッドは２回目の動作をなす。しかしながら、前回の更新から２５０ｍｓ経っていない。したがって、低優先度タイマをその先の２５０ｍｓに対して設定し、ＶＮＣメインスレッドを低い優先度に設定する。ＶＮＣメインスレッドが低い優先度となる一方、ゲームスレッドは、ＶＮＣメインスレッドが受信するいかなるディスプレイ変更通知又は入力イベントにもかかわらず、中断なしで動作する。この間、ＶＮＣメインスレッドは実行可能であるが実行中とはならない。優先度スレッドが動作する３回目は、６０３とラベル付けされているポイントで、低優先度タイマが終了したことに応じるものである。ＶＮＣ優先度スレッドは、ＶＮＣメインスレッドをもとの通常の優先度へと高めて、その後、ＶＮＣメインスレッドは実行可能となり、ポイント６０２で通知された変更のエンコードを続ける。

【0069】

いずれはスケジューラが、ＶＮＣメインスレッドを、ゲームスレッドと同じ優先度となり、かつ、実行可能となるようにスケジュールするであろう。その後、スケジューラは、ゲームスレッド及びＶＮＣメインスレッドの間でＣＰＵ時間を分け合い続ける。一定時間経過後、ＶＮＣメインスレッドは、星記号で示すように、最新の更新データのエンコードを終了している。それから、稲妻記号で示すようにディスプレイ変更通知を受信し、更新通知を優先度スレッドに送信する。その優先度スレッドは６０４とラベル付けされたポイントにおいてつかの間動作する。ディスプレイ変更をＶＮＣメインスレッドが処理した後、ＶＮＣメインスレッドは待機へと戻り、ゲームスレッドが動作する。その処理が反復的に繰り返される。

【0070】

図６ｂには、３つのスレッド、すなわち、最も高い優先度を有する優先度スレッドと、ゲームスレッドと、ＶＮＣメインスレッドとがある。ＶＮＣスレッドらが取るステップを、図４ａ及び４ｂが示す。ＶＮＣメインスレッドの優先度は、図６ａの処理とは対照的に、時にはゲームスレッドよりも高くなる。これにより、ＶＮＣメインスレッドはさらに定期的に更新することが可能となり、一方、ゲームスレッドにも妥当な量のＣＰＵ時間を与えることが可能となる。明確にするために、通常の優先度で動作しているゲームスレッドとＶＮＣメインスレッドとを図６ｂで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。

【0071】

最初はゲームスレッドが実行中である。これを、当初は高い優先度にあるＶＮＣメインスレッドが中断する。ＶＮＣメインスレッドは、入力イベントの受信、又はディスプレイ変更通知の受信に応じて、ゲームスレッドを中断してよい。後者の場合、ＶＮＣメインスレッドは、リモート端末へのデータをキャプチャし、エンコードし、送信する。続いて、ポイント６５１に示すように、ＶＮＣ優先度スレッドに更新が発生したことを通知する。このようにして図６ａとは対照的に、更新通知を、ＶＮＣメインスレッド処理の開始時ではなく終了時に送信する。その後、ＶＮＣメインスレッドが稲妻で示すようにディスプレイ変更通知を受信してゲームスレッドを再度中断するまで、ゲームスレッドが続く。ＶＮＣメインスレッドは、星記号で示すように更新を完了し、ポイント６５２で示すように、ＶＮＣ優先度スレッドに通知を送信する。ＶＮＣ優先度スレッドは、２つの通知の時間間隔が閾値時間（例えば７５０ｍｓ）未満であったかと、ＶＮＣメインスレッドは２つの更新通知間にＣＰＵを閾値（５０％）より多く使用していたかとを、判定する。それに応じて、ＶＮＣ優先度スレッドは、タイマを所定の値（例えば３５０ｍｓ）に設定し、メインスレッドの優先度を通常に低める。

【0072】

ＶＮＣメインスレッドは通常の優先度にあってもなお動作することが可能である。しかしながら、動作時間は少なくなり、ゲームスレッドが動作可能となる。タイマの時間が経過した後、すなわち、ＶＮＣメインスレッドの優先度が調整されてから３５０ｍｓ後、ポイント６５３に示すようにＶＮＣ優先度スレッドが再び動作し、ＶＮＣメインスレッドの優先度を元の高い優先度に高める。ＶＮＣメインスレッドは、別の更新を実行し、ＶＮＣ優先度スレッドに通知して、その処理が再び始まる。

【0073】

図７ａ及び７ｂは、一定の間隔で短時間ＣＰＵを使用する、例示的な、ハードウェアでアクセラレートされるビデオ再生を示す。図７ａには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ビデオプレーヤスレッドと、ＶＮＣメインスレッドとがある。ＶＮＣスレッドらが取るステップを、図４ｃ及び４ｄが示す。明確にするために、通常の優先度で動作しているビデオプレーヤスレッドとＶＮＣメインスレッドとを図７ａで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。図のとおり、ビデオプレーヤスレッドはＶＮＣメインスレッドと同じ優先度を有し、通常の優先度で動作する。さらにＶＮＣメインスレッドは、低い優先度と通常の優先度との間で変化する。ビデオプレーヤスレッドは周期的に動作し、各回は短時間である。ビデオプレーヤスレッドがＣＰＵを使用する合間に、ＶＮＣメインスレッドが主として動作可能となる。ポイント７０１〜７０６に示すように、ＶＮＣメインスレッドは優先度スレッドに、リモート端末への更新をまさに始めようとしているという更新情報を、周期的に送信する。このようにして、優先度スレッドが短時間動作し、続いて、ＶＮＣメインスレッドは、ビデオプレーヤスレッドからの次のバーストまで実行を続ける。これらの処理が反復的に繰り返される。

【0074】

図７ｂには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ビデオプレーヤスレッドと、ＶＮＣメインスレッドとがある。ＶＮＣスレッドらが取るステップを、図４ａ及び４ｂが示す。明確にするために、通常の優先度で動作しているビデオプレーヤスレッドとＶＮＣメインスレッドとを図７ｂで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。ＶＮＣメインスレッドの優先度は、図７ａの処理とは対照的に、時にはビデオプレーヤスレッドよりも高くなる。以下でより詳細に説明するが、図７ａ及び７ｂには同じ数の更新があり、したがって、空いているＣＰＵ処理時間がある場合、図４ａ及び４ｂの処理は更新の回数を減らすものではない。

【0075】

ビデオプレーヤスレッドは周期的に動作し、各回は短時間である。ビデオプレーヤスレッドがＣＰＵを使用する合間に、ＶＮＣメインスレッドは主として動作可能となる。図７ａとは対照的に、ＶＮＣメインスレッドの優先度は時間とともに変化する。当初は、ＶＮＣメインスレッドは高い優先度を有する。ＶＮＣメインスレッドは、リモート端末へのディスプレイの更新データをキャプチャし、エンコードし、送信する。続いてＶＮＣメインスレッドは、優先度スレッドに、リモート端末への更新を終了したという更新情報を送信する。このようにして優先度スレッドは、ポイント７５１において短時間動作する。

【0076】

ビデオプレーヤスレッドからの第２のバースト後、ＶＮＣメインスレッドは、リモート端末へのディスプレイのまた別の更新データをキャプチャし、エンコードし、送信する。続いてポイント７５２に示すように、ＶＮＣメインスレッドは、優先度スレッドに、リモート端末への更新を終了したという更新情報を送信する。ＶＮＣ優先度スレッドは、２つの通知の時間間隔が閾値時間（例えば７５０ｍｓ）未満であったかと、ＶＮＣメインスレッドは２つの更新通知間にＣＰＵを閾値（５０％）より多く使用していたかとを、判定する。それに応じて、ＶＮＣ優先度スレッドは、タイマを所定の値（例えば３５０ｍｓ）に設定し、ＶＮＣメインスレッドの優先度を通常に低める。優先度の低下にもかかわらず、ＶＮＣメインスレッドは、ビデオプレーヤスレッドからのバーストの合間に（入力イベント及び／又はディスプレイ変更通知を処理するために）動作を続ける。ポイント７５３及び７５４において、更新情報をＶＮＣ優先度スレッドに送信し、ＶＮＣ優先度スレッドが動作する。

【0077】

ビデオプレーヤストリームからの第４のバーストと第５のバーストとの間に、タイマの時間が経過している、すなわち、ＶＮＣメインスレッドの優先度を調整してから３５０ｍｓが経過している。それに応じて、ポイント７５５において、ＶＮＣ優先度スレッドが再び動作し、ＶＮＣメインスレッドの優先度を元の高い優先度に高める。その後、ＶＮＣメインスレッドは別の入力、例えばディスプレイ変更通知を待ち受ける、すなわち、ビデオプレーヤスレッドからの次のバースト後まで待機する。続いてＶＮＣメインスレッドは、また別の更新を実行し、ポイント７５６においてＶＮＣ優先度スレッドに通知する。いま一度、ＶＮＣ優先度スレッドは、優先度を低めるべきかを判定する。それでもなおＶＮＣメインスレッドは、ビデオプレーヤストリームのバーストの間に更新を実行し、ポイント７５７においてＶＮＣ優先度スレッドに通知する。

【0078】

図８ａ及び８ｂは、ダウンロードしたページをデコードするために一定時間ＣＰＵを使用する必要がある、例示的なブラウザアプリケーションを示す。図８ａには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ブラウザスレッドと、ＶＮＣメインスレッドとがある。明確にするために、通常の優先度で動作しているブラウザスレッドとＶＮＣメインスレッドとを図８ａで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。ＶＮＣスレッドらが取るステップを、図４ｃ及び４ｄが示す。図のとおり、ブラウザスレッドはＶＮＣメインスレッドと同じ優先度を有し、通常の優先度で動作する。さらにＶＮＣメインスレッドは、低い優先度と通常の優先度との間で変化する。ＶＮＣメインスレッドは通常の優先度で動作している場合、ブラウザスレッドを中断する。

【0079】

最初はブラウザスレッドが実行中である。ＶＮＣメインスレッドは、ディスプレイ変更通知を受信し、ポイント８０１に示すように、リモート端末への更新データをまさに送信しようとしていることを示す更新通知を、ＶＮＣ優先度スレッドに送信する。続いて、ＶＮＣメインスレッドは、更新データをキャプチャし、エンコードし、送信できるように動作する。ＶＮＣメインスレッドはブラウザと同じ優先度にあるため、ＶＮＣメインスレッドがデータをエンコードしている間、スケジューラは２つのスレッド間でＣＰＵ時間を分け合う。星記号で示すように、更新されたディスプレイデータをＶＮＣメインスレッドがひとたびエンコードして送信すると、稲妻で示すように、ＶＮＣメインスレッドがディスプレイ変更通知を受信するまで、ブラウザスレッドが再び動作する。再度、ＶＮＣメインスレッドは、リモート端末へ更新データをまさに送信しようとしていることを示す更新通知を、ＶＮＣ優先度スレッドに送信し、ポイント８０２に示すように、優先度スレッドは２回目の動作をなす。しかしながら、前回の更新から２５０ｍｓ経っていない。それに応じて、優先度スレッドは、低優先度タイマを固定の閾値に設定して、ＶＮＣメインスレッドを低い優先度に低める。

【0080】

ＶＮＣメインスレッドが低い優先度となる一方、ブラウザスレッドはＶＮＣメインスレッドが受信するいかなるディスプレイ変更通知又は入力イベントにもかかわらず、中断なしで動作する。この間、ＶＮＣメインスレッドは実行可能であるが実行中とはならない。タイマの時間が経過した後、すなわち、ＶＮＣメインスレッドの優先度を調整してから３５０ｍｓ後、ポイント８０３で示すようにＶＮＣ優先度スレッドが再び動作し、ＶＮＣメインスレッドの優先度を元の通常に高める。その後、ＶＮＣメインスレッドは、ポイント８０２で検出した更新データのエンコード及び送信を完了することができる。ひとたび更新を伝え終えると、ブラウザスレッドが一定の時間を経過するまで再び動作する。ＶＮＣメインスレッドは、ディスプレイ変更通知を受信する。再度、ＶＮＣメインスレッドは、リモート端末への更新データをまさに送信しようとしていることを示す更新通知を、ＶＮＣ優先度スレッドに送信し、そして、ポイント８０４に示すように、ＶＮＣメインスレッドが更新データの送信を実行する前に、優先度スレッドが３回目の動作をなす。

【0081】

図８ｂには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ブラウザスレッドと、ＶＮＣメインスレッドとがある。明確にするために、通常の優先度で実行しているブラウザスレッドとＶＮＣメインスレッドとを図８ｂで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。ＶＮＣスレッドらが取るステップを、図４ａ及び４ｂが示す。ＶＮＣメインスレッドの優先度は、図８ａの処理とは対照的に、時にはブラウザスレッドよりも高くなる。以下でより詳細に説明するが、ＶＮＣメインスレッドからの更新情報の合計回数に影響を与えることなく、ブラウザスレッドはわずかにより早く完了することが可能である。

【0082】

最初はブラウザスレッドが実行中である。ＶＮＣメインスレッドが入力データ、例えば、ディスプレイ変更通知又は入力イベントを受信する。その結果、ＶＮＣメインスレッドは、より高い優先度にあるためブラウザスレッドを中断して、実行中となる。ＶＮＣメインスレッドがディスプレイ変更通知に続く処理を完了すると、ポイント８５１に示すように、ＶＮＣ優先度スレッドに更新通知を送信する。ＶＮＣ優先度スレッドが短時間動作後、ブラウザスレッドは、第２の稲妻が示すようにＶＮＣメインスレッドが次のディスプレイ変更通知を受信するまで、実行を続ける。このようにして、ＶＮＣメインスレッドは実行を開始し、より高い優先度にあることからブラウザスレッドを中断する。

【0083】

ポイント８５２において、ＶＮＣメインスレッドからの第２の通知を受信すると、ＶＮＣ優先度スレッドは、２つの通知の時間間隔が閾値時間（例えば７５０ｍｓ）未満であったかと、ＶＮＣメインスレッドは２つの更新通知間にＣＰＵを閾値（例えば５０％）より多く使用していたかとを、判定する。それに応じて、ＶＮＣ優先度スレッドは、タイマを所定の値（例えば３５０ｍｓ）に設定し、ＶＮＣメインスレッドの優先度を通常に低める。ＶＮＣメインスレッドは今度は、ブラウザスレッドがダウンロードを完了するまで、それを中断できない。ダウンロード終了において、ＶＮＣメインスレッドが再び動作する。

【0084】

ＶＮＣ優先度スレッドの次の始動は、ポイント８５３における、タイマ終了に応じるものである。したがって、ＶＮＣ優先度スレッドはＶＮＣメインスレッドの優先度を元の高い優先度に高める。このようにしてＶＮＣメインスレッドは上記で説明したように動作する。

【0085】

図９ａ及び９ｂは、短時間ＣＰＵを使用する必要がある、例示的なブラウザアプリケーションを示す。図９ａには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ブラウザスレッドと、ＶＮＣメインスレッドとがある。明確にするために、ブラウザスレッドとＶＮＣメインスレッドとを図９ａで分けているが、それらには同じ「通常の」優先度レベルを割り当てている。ＶＮＣスレッドらが取るステップを、図４ｃ及び４ｄが示す。図のとおり、ブラウザスレッドはＶＮＣメインスレッドと同じ優先度を有する。前の例とは対照的に、図示している時間内に、ＶＮＣメインスレッドの優先度の変化はない。

【0086】

最初はブラウザスレッドが実行中である。ＶＮＣメインスレッドがディスプレイ変更通知を受信し、ブラウザスレッドを中断して、更新データをまさに送信しようとしているという更新通知を、ポイント９０１に示すようにＶＮＣ優先度スレッドに送信する。しかしながら、ブラウザスレッド及びＶＮＣメインスレッドが同じ優先度を有するため、更新の処理はすぐには発生せず、その結果、スケジューラはどちらを実行するかを自由に決定する。

【0087】

ひとたびＶＮＣメインスレッドがリモート端末に更新データを送信すると、ＶＮＣメインスレッドは待ち状態（すなわち、実行中ではなく実行可能の状態）に戻る。その後、ブラウザスレッドは、ユーザインタフェース更新を完了することができる。ひとたびブラウザスレッドが実行を終了すると、ＶＮＣスレッドは標準的に自由に動作する。このようにして、ＶＮＣメインスレッドは、稲妻で示すようにディスプレイ変更通知を受信し、ポイント９０２において更新通知を優先度スレッドに送信する。ＶＮＣメインスレッドは中断なしで更新を完了することが可能となる。

【0088】

図９ｂには、３つのスレッド、すなわち、最も高い優先度を有するＶＮＣ優先度スレッドと、ブラウザスレッドと、ＶＮＣメインスレッドとがある。ＶＮＣスレッドらが取るステップを、図４ａ及び４ｂが示す。今回は、ＶＮＣメインスレッドは、ブラウザスレッドよいも高い優先度を有する。短い時間枠のため、ＶＮＣメインスレッドの優先度の変更は示されない。この場合、最初のＶＮＣ更新を図９ａのものよりも早く完了し、したがって、リモート端末上のディスプレイの応答性を向上させる。

【0089】

最初はブラウザスレッドが実行中である。ＶＮＣメインスレッドがディスプレイ変更通知を受信し、ブラウザスレッドを中断してディスプレイ変更を処理し、続いてポイント９５１に示すように、更新通知をＶＮＣ優先度スレッドに送信する。その後、ＶＮＣメインスレッドは動作、例えば入力イベントの処理を続ける。ひとたびこれらを完了すると、ＶＮＣメインスレッドは待ち状態に戻り、ブラウザスレッドが再びその処理を完了するために動作する。ひとたびブラウザスレッドが実行を終了すると、ＶＮＣスレッドは標準的に自由に動作する。このようにして、ＶＮＣメインスレッドは、稲妻で示すようにディスプレイ変更通知を受信し、ポイント９５２において更新通知を優先度スレッドに送信する。ＶＮＣメインスレッドは、中断なしで更新を完了することが可能である。

【0090】

要約すると、携帯電話を遠隔制御する場合、最良のユーザ・エクスペリエンスのための重要な特性は、
１．全体の所要時間 ‐ 一タスクが遠隔制御下にある場合、遠隔制御下にない場合と比較して、実行に著しく長い時間を要するべきではない。一操作が、機器を遠隔制御していない場合は１０秒かかるところ、機器を遠隔制御している場合は３０秒超かかる場合、ユーザ・エクスペリエンスにマイナスの影響を与えるであろう。
２．リモート端末での更新のレート ‐ リモート端末上のモバイルディスプレイの表示を、一定の頻度で更新するべきである。ユーザが、１秒間に何度もアニメーションを更新している機器を直接見ることに慣れている場合、同様の更新レートをリモート端末上で達成する必要がある。
３．入力イベントへの応答性 ‐ リモート端末上のモバイルディスプレイの表示を、タイムリーに更新するべきである。ユーザが、リモート端末上の何らかの動作の結果を見るために、数百ミリ秒を上回って待たなければならない場合、ユーザ・エクスペリエンスにマイナスの影響を与えるであろう。
となる。

【0091】

これらの特性を上述の実施形態が対処し、モバイル機器で利用可能なＣＰＵリソースが有限であるという課題を克服する。その実施形態は遠隔で制御される機器のパフォーマンスを向上し、すなわち、特に大量の要求がモバイルプロセッサ内のＣＰＵに出される場合に、リモートのやりとりを向上する。さらにそのシステムは、ＣＰＵに負担をかけるアプリケーションを実行中であっても、モバイル機器で実行中のアプリケーションのパフォーマンスを深刻に低下させることなく、リモート端末上で適切なディスプレイ・リフレッシュ・レートを維持するという課題に対処することが可能である。それゆえに、上記の実施形態は、モバイル機器上で実行されている他のアプリケーションとは独立して、上記の特性を達成するために、発明をどのようにモバイル機器に適用可能であるのかを明示している。

【0092】

マルチコアのシステムにおいて、タスク・スケジューラ（又はオペレーティングシステムの他の機能）が、プロセッサ間のタスクの配分を制御してよい。プロセッサ・リソースが要求される状況において、モバイル機器で実行中のアプリケーションにマイナスの影響を与えることなく、リモート端末上で適切なリフレッシュ・レートを維持するにあたり、どのプロセッサにおいても利用可能なリソースが不十分となる可能性がある。本書で説明する方法は、マルチコアのシステムにおいてそうした状況に対処する。

【0093】

さらに、本書で説明する方法を、Ｊａｖａ（登録商標）仮想マシン（Java（登録商標） Virtual Machines）のガベージコレクション（garbage collection）などの他のアプリケーションに適用してもよい。一般的に、ガベージコレクションは、Ｊａｖａ（登録商標）仮想マシンのバックグラウンド・タスクとして動作する。特にリソースに負担をかけるアクティビティの時にそのようなガベージコレクションタスクの優先度が制御されるように、ガベージコレクションのインスタンスを制御することが望ましい場合がある。

【0094】

無論、当業者は多くの他の有効な代替手段に気付くことになる。理解されるであろうように、本発明は、上述の実施形態に限定されず、本書に添付の請求項の主旨及び範囲内にある、当業者に明らかである変更を包含する。

【図1a】

【図1b】

【図2】

【図3】

【図4a】

【図4b】

【図4c】

【図4d】

【図5a】

【図5b】

【図5c】

【図5d】

【図6a】

【図6b】

【図7a】

【図7b】

【図8a】

【図8b】

【図9a】

【図9b】