JP2970687B2 - コンピュータ・ワークステーション - Google Patents

Description

【発明の詳細な説明】 技術分野 本発明は、第１コンピュータ・ワークステーションの
スクリーンに対して行われた更新が第２コンピュータ・
ワークステーションに伝送され、その更新のコピーが第
２コンピュータ・ワークステーションのスクリーン上に
表示されるシステムに関するものである。

背景技術 近年、コンピュータ・ワークステーション同士がデー
タを交換することを可能にするために、例えば、ローカ
ル・エリア・ネットワーク（LAN）において、或いは、
統合サービス・ディジタル・ネットワーク（ISDN）接続
によってコンピュータ・ワークステーションをリンクす
ることが益々一般的になっている。これは、一般に、連
携作業（collaborative−working）とよく呼ばれるコン
ピュータ・テクノロジの新しい分野を生じさせた。連携
作業の特定の例の２つがアプリケーション共用及び遠隔
制御である。前者では、１つのアプリケーションが２つ
の機械において実行され、一方の機械においてそのアプ
リケーションになされた更新が他方の機械に伝送され、
そして他方の機械においてミラーリングされる。国際特
許出願WO91/09378及びヨーロッパ特許出願EPA−590817
はミラーリングの例を開示している。その例では、更新
によって影響されるスクリーンの領域は、リモート・ノ
ードに伝送される更新及び適当な位置情報によって決定
される。明らかに、この技法は３つ以上の機械にも拡張
可能である。遠隔制御では、一方の機械において実行中
のアプリケーションが他方の機械においてユーザにより
効果的に制御される。連携作業システムの例は、ヨーロ
ッパ特許出願EPA−475581及び国際特許出願PO89/12859
において見ることができる。

連携作業における１つの問題は、通信リンクを通して
データを伝送する必要があるために応答時間が遅いこと
があるということである。これは、例えば、遠隔制御に
おいて、ローカルの機械のユーザがマウス・ボタンのク
リックのような何らかのアクションを行うが、遠隔制御
されている機械とコミュニケートするために必要な時間
のために如何なる即時応答も得られない時、得に欲求不
満を生じさせることがある。この遅れの間、ユーザは、
自分のマウス・アクションがシステムによって受け入れ
られなかったと勘違いしてそのアクションを繰り返すこ
とがある。しかし、これによって、最終的には、当初の
意図に反してそのアクションが２回行われるという結果
になるであろう。

機械がデータを処理しようとしているという何らかの
表示を行うことは、勿論、通常の独立型ワークステーシ
ョンにおいては知られている。例えば、IBM社から入手
可能なOS/2オペレーティング・システムでは、システム
が現在リクエストされたアクションを実行していること
を表すために、カーソルが時計の形に変化する。別の方
法として、リクエストされたアクションが進行中である
ことを記述したテキスト・メッセージを表示することも
可能である。

所定のHTMLフォーマットを持った情報ページを与える
情報を、クライアントの端末が遠隔のサーバから検索す
ることもワールド・ワイド・ウェブに関連して知られて
いる。或ページが、そのページに含まれるべきイメージ
を表す別のグラフィックス・ファイルの引用を含むこと
も可能である。クライアントがそのようなページを検索
する時、クライアントは、そのイメージを検索するため
にはそのグラフィックス・ファイルをアクセスすべきで
あることを知る。クライアントは、イメージを位置付け
るべきスクリーンの特定の領域を決定することができる
ように、先ず、イメージ自体よりも前にそのイメージに
対するヘッダ情報を与えるようにサーバにリクエストす
ることができる。一旦そのイメージ・データ自体が検索
されてしまうと、そのイメージが満たすべきボックス又
は領域をそのままにして、この方法はクライアント及び
サーバの明確なサポートを必要とし、基本的にはクライ
アント（即ち、受信）端末によって駆動される。それは
連携作業環境に直接に適用し得るものではない。

Computer Practices,Communications of the ACM誌の
Vol.30,No.1,Jan.1987のpp.32−47におけるM.Stefik,G.
Foster,D.Bobrow,K.Kahn,S.Lanning及びL.Suchman氏に
よる「黒板を越えて：会議における連携及び問題解決の
ためのコンピュータ・サポート（Beyond the Chalkboar
d:Computer Support for Collaboration and Problem S
olving in Meetings）」と題した論文は連携作業システ
ム（しかし、それは遠隔制御を述べてはいない）を開示
している。２人以上のユーザが共用オブジェクトを同時
に編集しようとする問題を克服するために、一方のユー
ザが現在作業している項目はグレイ・アウト（grey ou
t）される。この方法は、特別に適応されたアプリケー
ション（例えば、どの項目が編集されようとしているか
を監視するための）を必要とする。しかし、更に最近の
連携作業システムに対する重要な目的は、それらが既存
の（独立した）アプリケーション（例えば、遠隔制御を
行うための）を働かせることができなければならないこ
とである。

発明の開示 従って、本発明は、ディスプレイ・スクリーンを有
し、リモート・ワークステーション（200）にリンクさ
れたコンピュータ・ワークステーション（100）を操作
する方法を提供するものであり、その方法は、 前記ワークステーションのスクリーンに対する更新を
発生するステップと、 前記ワークステーションのスクリーンの更新されよう
としている領域を決定するステップと、 前記更新されようとしている領域の指示を前記リモー
ト・ワークステーションに伝送するステップと、 前記更新されようとしている領域の指示の前記伝送の
後に、前記更新を表すデータを前記リモート・ワークス
テーションに別に伝送するステップと、 を含む方法。

それに対応して、本発明は、リモート・ワークステー
ションにリンクされたローカル・ワークステーションを
操作する方法も提供するものである。前記ローカル・ワ
ークステーションのスクリーンの少なくとも一部分は前
記リモート・ワークステーションのスクリーンの少なく
とも一部分に対応するように配列される。その方法は、 更新が施されようとしているリモート・ワークステー
ションのスクリーンの領域を表す第１メッセージを前記
リモート・ワークステーションから受信するステップ
と、 前記更新が施されようとしている前記リモート・ワー
クステーションのスクリーンの部分に対応した前記ロー
カル・ワークステーションの領域を視覚的に指示するス
テップと、 前記リモート・ワークステーションに対して行われた
更新を含む第２メッセージを前記リモート・ワークステ
ーションから受信するステップと、 前記ローカル・ワークステーションにおける前記更新
を、前記指示された前記スクリーン領域に施すステップ
と、 を含むものである。

従って、一方のコンピュータ（リモート・ワークステ
ーション）において行われた更新が他方のコンピュータ
（ローカル・ワークステーション）のスクリーン上にミ
ラーリングされる（即ち、表示される）べき状況におい
て、本発明は、その更新が処理及び伝送されようとして
いることの表示をローカル・ワークステーションのユー
ザに与えることが重要であるということを認識してい
る。これは、始めに更新を行うこと及びローカル・ワー
クステーションにおいてそれを表示できることの間の遅
延は、その更新を処理及び伝送するための必要な時間の
ために意味あることであるが、それによって、ローカル
・ワークステーションにおけるユーザが正しい制御オペ
レーションを行うことを困難にしているためである。従
って、本発明によれば、実際の更新自体の伝送の前に、
その更新によって影響を受けたスクリーン領域の指示を
含むメッセージがリモート・ワークステーションからロ
ーカル・ワークステーションに伝送される。そのメッセ
ージは、更新データ自体ではなく更新された領域の指示
を含むだけなので、この更新領域メッセージは比較的小
さく、従って、更新データ自体よりもずっと速く処理及
び伝送することが可能である。事実、その領域に対する
境界矩形によって更新領域を表すことが都合がよく、従
って、更新された領域の表示は、ちょうど２対の座標
（例えば、左上隅及び右下隅）によって与えられる。

そこで、更新領域の指示は、すぐ後に生じる更新が施
される領域をローカル・ワークステーションにおけるス
クリーン上に視覚的に示すために使用される。これは、
更新されるべき領域を実際にワークすることに関連する
ということに留意して欲しい。これは幾つかの利点を有
する。先ず、更新自体がその後施される時、それは自動
的に上書きされるので、そのマーキングを後で明示的に
削除する必要がない。第２に、それはユーザがすぐ後に
生じる更新のサイズを知ることを可能にし、従って、更
新自体が受信される前に、予想される遅延の概略の見積
を行うことを可能にする（大きい領域に対する遅延は、
明らかに、処理及び伝送に長く時間かかり易いので）。
又、それは、すぐ後に生じる更新の性質に関する何らか
の情報をユーザに与える（例えば、ユーザは、更新が影
響を与えないスクリーンの部分を直ちに知ることができ
る）。

更なるメッセージがその伝送されるべき更新領域を含
むことを必要とすることによって、本発明の方法は、実
際には、更新自体を送ることの遅れをわずかに増大する
であろう。しかし、実際には、この余分な遅延によって
生じる損失は、ローカル・ワークステーションにおいて
すぐにユーザに利用され、正確な制御オペレーションを
遂行する能力を大いに強化するその更新領域に関する初
期情報によって補償されるものではない。これに対する
唯一の例外は、更新自体がほとんどその更新領域を表す
メッセージのような速く受信されるように、その更新が
非常に速く処理及び伝送される時である。これに関して
は、更新が少なければ少ないほど、更新領域メッセージ
に起因する伝送及び処理要件の増加は比例的に大きくな
ることは留意すべきである。それは、更新領域メッセー
ジのサイズが一般には更新自体の範囲に関係ないためで
ある（しかし、これは特に大きな効果ではない）。

従って、好適な実施例では、その方法は、更に、その
更新を所定の基準と比較するステップを含み、それによ
って、そのような基準が合致する場合、その更新は、更
新された領域の表示の事前伝送なしに直接に伝送され
る。その更新された基準は、その更新が処理され、そし
てローカル・ワークステーションへ伝送される速度に関
連する。これが非常に速く行われる場合、その更新され
た領域のメッセージを送ることにおける利点は比較的小
さいものである（事実、上述のように、実際には、それ
はわずかな損失を表すだけである）。

一般に、所定の基準は、更新された領域のサイズ、即
ち、更新されたピスセルの数に関連する。本実施例で
は、更新されるピクセルの数が一定の闘値を超えた場
合、更新領域メッセージが送られる。一般に、明らかに
大幅な更新な伝送に長い時間を取り、リモート・ワーク
ステーション及びローカル・ワークステーションの両方
において処理に長い時間を取るので、この簡単なテスト
は効果的である。しかし、この方法の拡張を予測するこ
とは容易であり、それによって、その闘値は、例えば、
ローカル・ワークステーション及びリモート・ワークス
テーションの間の通信リンクの帯域幅及びそのリンクに
おける現在のトラフィック量に従って、或いはプロセッ
サ・ローディングに従って変更されてもよい。１つの可
能性は、リモート・ワークステーションにおける更新の
発生及びローカル・ワークステーションにおけるそれの
表示の間の遅れを周期的に測定し、それに従って闘値を
変更することである。例えば、所定の基準に含まれても
よいもう１つの要素は、更新データに関して遂行される
べきデータ圧縮（それがある場合）の効果である。それ
は、これが処理及び伝送時間にも影響を与えるためであ
る。

非常に小さい更新領域メッセージの処理効率を改良す
るための１つの方法は、複数の更新に対するその更新さ
れた領域の指示を１つのメッセージで伝送することであ
る。ほとんどの通信システムは、１つのメッセージ当た
り、ある程度の一定のオーバヘッドを有するので、幾つ
かの非常に小さい更新領域メッセージを個々に送ること
は比較的非効率的であるため、これは有益である。従っ
て、複数の更新のための領域の指示を結合して１つのメ
ッセージにすることは、ローカル・ワークステーション
における更新領域情報の最終的な到着にわずかな遅れ
（それがあったとしても）を加えるだけで、システム及
びネットワークのパフォーマンスを助けることができ
る。

１つの領域を視覚的に指示するステップは、その領域
におけるオリジナルのイメージ（即ち、テキスト、図
形、或いは如何なるものでも）が実質的に可視状態のま
まであることを妨げず、従って、更新自体が到達した時
に上書きされるまで、それはユーザにとって識別可能の
ままであることが望ましい。これを行う速く且つ効率的
な方法は、関連する領域をグレイ・アウト（網目模様
に）することであるが、多くの他の代替方法（例えば、
稿模様、関連領域の背景色の変更、或いは色付けされた
枠による関連領域の縁取り）も使用可能である。

本発明は、先ず、ローカル・ワークステーションにお
けるユーザからのコマンドがリモート・ワークステーシ
ョンにおいて受信され、そしてこのコマンドの結果とし
て更新が発生されるという状況において特に有益であ
る。これは、そのコマンドに対する応答を知るのに遅れ
があって、そのコマンドが受領されたかどうか確信がな
い場合、ローカル・ワークステーションにおけるユーザ
が性急になるためである。これは、ユーザがそのコマン
ドを反復することに通じ、思いも寄らない（及び望まし
くない）結果をもたらすかもしれない。この問題は、更
新領域メッセージを送ることによって回避される。それ
は、可視的な応答がローカル・ワークステーションにお
けるユーザに速く表示されることをこれが可能にし、そ
れによって、そのコマンドがアクティブに処理されるこ
とをユーザに最保証するためである。事実、ユーザは、
その更新が既にそのコマンドに応答して発生されている
（即ち、そのコマンドは受領され、伝送され、更新を発
生するように実行されている）ことを知る。更に、上述
のように、指示された領域のサイズは、更新自体がロー
カル・ワークステーションにおける表示のために処理及
び伝送されるまでの時間をユーザが粗く見積もることを
可能にする。その指示された領域は、ユーザのコマンド
の結果として変更されようとしているスクリーンの領域
を、勿論、そのユーザにも知らせる。

次に、ローカル・ワークステーション及びリモート・
ワークステーションの考察に話を進めると、本発明はデ
ィスプレイ・スクリーンの少なくとも一部分をリモート
・ワークステーションからローカル・ワークステーショ
ンのディスプレイ・スクリーン上にミラーリングする方
法を提供し、それによって、リモート・ワークステーシ
ョンのスクリーンに施された更新は、それに対応してロ
ーカル・ワークステーションにも施される。その方法
は、 リモート・ワークステーションのスクリーンに更新を
施すステップと、 更新されようとしているリモート・ワークステーショ
ンのスクリーンの領域を決定するステップと、 更新されようとしている領域の指示をリモート・ワー
クステーションからローカル・ワークステーションに伝
送するステップと、 前記指示をローカル・ワークステーションにおいて受
信するステップと、 前記更新が施されたリモート・ワークステーションの
スクリーンの指示された領域に対応するローカル・ワー
クステーションのスクリーンの領域を視覚的に表すステ
ップと、 スクリーンに施された更新を表すデータをリモート・
ワークステーションからローカル・ワークステーション
に別々に伝送するステップと、 前記更新をローカル・ワークステーションにおいて受
信するステップと、 ローカル・ワークステーションにおけるスクリーンの
前記指示された領域に前記更新を施すステップと、 を含んでいる。

本発明は、２つのワークステーションしか持たないシ
ステムに限定されるのではなく、オリジナルの更新が複
数の他のスクリーンにコピーされるシステムに等しく適
用可能であることにも留意して欲しい。そのような場
合、更新領域の指示は、一般に、複数の他のスクリーン
に与えられるであろうが、或端末に対するリンクが他の
端末に対するリンクよりもずっと遅い場合、その遅いリ
ンクによって接続される端末だけが実際の更新自体の前
に更新領域メッセージを受信することは理解されるであ
ろう。

本発明は、更に、上記の方法を実施するための装置を
提供する。

図面の簡単な説明 次の図面に関連して、本発明の実施例を詳細に説明す
ることにする。

第１図は、代表的なコンピュータ・ワークステーショ
ンの簡略化した図である。

第２図は、本発明を実施する場合に利用される主要な
ソフトウエア・コンポーネントの概略図である。

第3A図及び第3B図は、遠隔制御の一般的なオペレーシ
ョンを示すフローチャートである。

第４図は、遠隔制御を行おうとするコンピュータ・ワ
ークステーションのスクリーンの概略図である。

第５図は、遠隔端末装置における更新の処理を表すフ
ローチャートである。

第６図は、遠隔制御を行おうとしているコンピュータ
・ワークステーションにおける更新の処理を表すフロー
チャートである。

第７図は、遠隔制御オペレーションの例を示す図であ
る。

発明を実施するための最良の形態 第１図は、システム・ユニット10、ディスプレイ・ス
クリーン12、キーボード14、及びマウス16を持ったコン
ピュータ・システムの簡略化した概略図である。システ
ム・ユニット10はマイクロプロセッサ22、半導体メモリ
（ROM/RAM）24、及びデータを転送するバス26を含んで
いる。第１図のコンピュータは、IBM社から入手可能なP
S/2コンピュータのような任意の通常のワークステーシ
ョンであってもよい。第１図のコンピュータはネットワ
ーク・アダプタ・カード30を備えている。このカード
は、付属のソフトウエアと一緒になって、メッセージが
そのコンピュータ・ワークステーションから伝送される
こと及びそのコンピュータ・ワークステーションによっ
て受信されることを可能にする。トークン・リング・イ
ーサネット、ISDN等のような種々のネットワークによる
使用のために、種々の形成のネットワーク・アダプタ・
カードが利用可能である。そのネットワーク・アダプタ
・カードのオペレーションは周知であり、従って、詳細
には説明しないことにする。

第２図は、遠隔制御セッションに関連した２つの端末
Ａ及びＢにおける主要なソフトウエア・コンポーネント
を示す。各端末は、第１図に示されたようなコンピュー
タ・ワークステーション100、200を含み、マイクロソフ
ト社から入手可能なWindowsオペレーティング・システ
ム130、230を実行する（厳密に云えば、勿論、そのオペ
レーティング・システムはWindowsがその上で走るDOSで
あるが、この区別は本発明には関係ない）。Windowsオ
ペレーティング・システムに関する更なる詳細は、Micr
osoft Press発行のChatjes Petzold著の「プログラミン
グWindows（Programming Windows）」において見ること
ができる。

そのオペレーティング・システムの下で動作するデバ
イス・ドライバ150、250は、そのオペレーティング・シ
ステムとそのコンピュータに取り付けられた外部装置と
の間の相互接続を制御する。各ワークステーションに対
して、３つの特定のデバイス・ドライバが示されてい
る。第１のものはマウス・デバイス・ドライバ155、255
であり、それは、マウス16から受け取ったそのマウスの
ロケーションに関する情報及びどのボタンが押されてい
るかに関する情報をオペレーティング・システムに送
る。スクリーン・デバイス・ドライバ156、256は、ディ
スプレイ・スクリーン12上にイメージを表示するために
オペレーティング・システムによって使用される。最後
に、通信デバイス・ドライバ157、257は、オペレーティ
ング・システムとネットワーク・アダプタ・カード30の
間のインターフェースとして使用される。デバイス・ド
ライバはその分野では周知であることは認められてお
り、従って、更に詳しくそれを説明することはしない。
同様に、他のデバイス・ドライバ（例えば、キーボード
14に関するもの）でもよいが、これらは本発明を理解す
るために直接関連するものではないので省略した。

各端末は通信ソフトウエア120、220も含んでおり、そ
れらはコンピュータ相互間のリンク300を介して（通信
デバイス・ドライバを介して）メッセージを伝送するこ
とを可能にする。又、そのようなメッセージング・ソフ
トウエアはその分野では周知であり、従って、更にそれ
を説明することはしない。最後に、各ワークステーショ
ンにおいて走るアプリケーション110、210がある。RC11
6、216として示された特定のアプリケーションは遠隔制
御機能を与え、よりによって、第２図における一方のコ
ンピュータ・ワークステーションが他方のワークステー
ションを遠隔操作又は制御するために使用可能である。
その目的のために、ユーザは端末Ｂにあり且つ端末Ａを
遠隔制御しようとしているものと仮定する。更に詳しく
云えば、端末Ｂにおけるユーザは端末Ａにおける残りの
アプリケーション（RCではない）を制御しようとしてい
る。説明を簡単にするために、端末Ａでは１つのアプリ
ケーションだけが示されているが、実際には、その遠隔
制御機能は端末Ａにおける複数のアプリケーションを処
理することができる。端末ＢにはアクティブなRC以外に
もアプリケーション（Apps）115が存在するが、これら
は本発明を理解するに当たって直接に関連するものでは
ない。

遠隔制御の一般的な動作が第3A図及び第3B図に示さ
れ、それらは、それぞれ、端末Ａ及びＢにおける発生事
項を示している。両方のロケーションにおける第１のア
クションは遠隔制御アプリケーションを開始することで
ある（ステップ410、510）。これは、それらの２つの端
末等の間に通信チャンネルを設定することに関連する。
この初期設定の一部として、端末Ａのスクリーン全体が
端末Ａから端末Ｂへ伝送され（ステップ520）、端末Ｂ
において、それは、一般には、遠隔制御ウインドウに表
示される（ステップ420）、今や、ユーザが端末Ｂにお
いて遠隔制御に入ることによって、遠隔制御が開始可能
である（ステップ430）。そこで、これは端末Ａに伝送
され（ステップ440）、端末Ａにおいて、それは受信さ
れ（ステップ530）、その遠隔制御アプリケーションに
いて適当に遂行される（ステップ540）。この結果、端
末Ａのスクリーンに対する更新の発生が生じるものと仮
定すると（ステップ550）、この更新は端末Ａから端末
Ｂに伝送され（ステップ560）、端末Ｂにおいて、それ
は型どおり受信され（ステップ450）、端末Ａにおける
スクリーンを表す遠隔制御ウインドウがそれに従って更
新される（ステップ460）。

端末Ｂからの如何なる特定のアクションを必要とする
ことなく、端末Ａにおいて更新が発生可能であることに
注意して欲しい。これの代表的な例は、APP1が端末Ａに
おけるスクリーン上に時計を表示する場合であろう。従
って、時計の針が動く時には、いつも、端末Ａにおいて
更新が自動的に発生され（ステップ550）、しかる後、
端末Ｂに送られる。端末Ｂにおいて、それは受信されそ
して表示される（ステップ450、460）。従って、端末Ａ
では、更新の発生及び端末Ｂへのそれらの伝送は、端末
Ｂからの遠隔制御アクションの受信に関して非同期的に
生じ得る。同様に、端末Ｂにおける更新の受信及び表示
は、端末Ａへの遠隔制御コマンドの伝送に関して非同期
的に生じ得る。

第４図は端末Ｂにおけるスクリーン600を示し、それ
は遠隔制御ウインドウ610を含んでいる。Windowsオペレ
ーティング・システムはこのウインドウのロケーション
を知っており、或ユーザ・アクションはそのWindowsオ
ペレーティング・システムによって自動的に処理され
る。例えば、アクション・バー620におけるクリックの
結果、メニューが表示される。しかし、端末Ａからのウ
インドウ650が端末Ｂにおいて（遠隔制御ウインドウ610
内に）表示される時、端末ＢにおけるWindowsオペレー
ティング・システムはそれがウインドウであることを知
らず、遠隔制御ウインドウ内に表示されたビット・マッ
プの一部分としてそれを見なすだけである。

端末Ｂが端末Ａからのスクリーン全体をウインドウ61
0に表示する時、何らかのサイズの縮小が必要であるこ
とは明らかであろう。２つの方法が可能である。即ち、
スクリーン全体がその作用可能なウインドウ・サイズに
適合するように縮小される（Windowsオペレーティング
・システムはこの機能を直接に遂行することができる）
か、或いは端末Ｂにおけるウインドウが端末Ａからのス
クリーンの一部分だけを表示する。しかる後、そのスク
リーンの他の部分へのアクセスを可能にするために、こ
のウインドウ内でスクロール・アクションを行うことが
可能である。いずれの場合も、前述のように、端末Ａか
らのスクリーンは単にビット・マップとして表示され
る。

遠隔制御オペレーションに進むと、端末Ｂにおけるユ
ーザは何らかのマウス・アクションを行うこと、例え
ば、ウインドウ650におけるアクション・バー660におい
てマウス・ボタンをクリックすることを決定する。前段
で述べたように、端末ＢにおけるWindowsオペレーティ
ング・システムはアクション・バー660の存在を知らな
いので、それは、単に、ウインドウ610と関連してその
マウス・クリックのロケーションを表すマウス・クリッ
ク事象を遠隔制御アプリケーション116に報告するだけ
である。そこで、遠隔制御アプリケーションは、そのマ
ウス・クリックのロケーションを含むメッセージを発生
し、そしてそのメッセージは、標準的な通信手順を使用
して、端末Ａにおける遠隔制御アプリケーションに送ら
れる。

そこで、端末Ａにおける遠隔制御アプリケーション21
6は、このメッセージの受信時に、端末Ａで生じる同等
の事象をシミュレートする。それは、Windowsオペレー
ティング・システム及びマウス・デバイス・ドライバの
間のインターフェースを使用することによってこれを行
う。従って、その遠隔制御アプリケーションは、マウス
事象が生じたことをマウス・デバイス・ドライバがWind
owsオペレーティング・システムに知らせるために通常
使用するそのWindowsオペレーティング・システムに対
するエントリ・ポイントを呼び出す。換言すれば、遠隔
制御アプリケーションは、マウス・デバイス・ドライバ
であるように効果的に装う。従って、それは、マウス・
アクションが生じたことを、そのマウス・アクションの
性質と端末Ｂにおける遠隔制御ウイドウ内のそのユーザ
により遂行されたアクションに対応するそのマウス・ア
クションのロケーションとをWindowsオペレーティング
・システムに知らせる。そこで、Windowsオペレーティ
ング・システムはウインドウ650に責任のあるアプリケ
ーションAPP1にこのマウス事象を送る（勿論、それがア
クション・バー事象又は同様のものでない場合、それ
は、前述のように、端末ＡにおけるWindowsオペレーテ
ィング・システムによって直接に処理される）。

次に、端末Ａにおける更新の処理に話題を変えると、
第3A図に示されるように、スクリーン更新は端末Ｂから
遠隔制御を通して受信したコマンドに応答して生じる
か、又は、単に端末Ａにおける処理（端末Ａにおけるク
ロックの操作のような）によって生じることが可能であ
る。そこで、スクリーンのどの領域が更新されたかを決
定することが必要である。その使用される技法は、ヨー
ロッパ特許出願EPA−590817に開示されたものと本質的
に同じであるので、単に概略するに留める。その方法
は、第２図においてグラフィカル・デバイス・インター
フェース（GDI）135、235として概略的に表されたオペ
レーティング・システム及びスクリーン・デバイス・ド
ライバの間のインターフェースを活用する。Windowsオ
ペレーティング・システムはスクリーンに書き込むため
にGDIコールを使用する（WindowsにおけるGDIコールは
上記特許出願におけるOS/2用のGPIコールと同じであ
る）。現に、遠隔制御アプリケーションはこれらのGDI
コールを代行受信し、それらを使用してそのスクリーン
のうちの更新されようとしている領域を決定する。その
コールはデバイス・ドライバに送られ、そのリクエスト
された更新が遂行されるのを可能に、一方、遠隔制御ア
プリケーションはその更新によって変更されるスクリー
ンのレコードを得る。現在の実施方法では、この領域
は、EPA−590817に示されるように、ほとんどのアプリ
ケーションに対して非常に有効であることがわかってい
る境界矩形としていつも説明される（しかし、円又は多
角形、凸面、或いは凹面のような更新領域のより複雑な
説明を、それが望ましい場合には使用可能である）。

更新領域を決定するための上記の技法の利点は、それ
がアプリケーション及びオペレーティング・システムに
対して透明であり、従って、一般的な使用に適している
ことである。しかし、代わりの方法は、アプリケーショ
ン自体が更新領域を計算しそして遠隔制御アプリケーシ
ョンにこの情報を直接に供給するためのものであるが、
これが特別に適用されたアプリケーションを必要とする
ことは明らかである。

端末Ａにおける更新処理が第５図に示される。更新が
遠隔制御コマンドに応答して或いは単にAPP1自体によっ
て発生された後（ステップ710）、それは端末Ｂへの伝
送を待っている更新の待ち行列に加えられる（ステップ
715）。肯定応答されるべき何らかの未決の更新伝送が
あるかどうかを表す「CAN_SEND」フラッグのステータス
を決定するためのテストが行われる（ステップ720）。
「CAN_SEND」フラッグがセットされている場合、伝送が
行われる（下記参照）。それがセットされていない場
合、プロセスは前の伝送からの肯定応答の受信を持たな
ければならない。そのような肯定応答の受信はステップ
730として示され、現在、待ち行列において何らかの更
新があるかどうかを決定するためのテスト（ステップ73
5）がこれに続く。更新がない場合、「CAN_SEND」フラ
ッグがセットされ（ステップ740）、それによって、何
らかの将来の更新が発生される場合のその更新の伝送を
可能にする。

待ち行列からの実際の更新の伝送がステップ750乃至7
85において示され、その伝送が新しい更新の発生によっ
て（即ち、ステップ710を介して）トリガされても、或
いは肯定応答の受信によって（ステップ730）トリガさ
れても本質的には同じである（注意：肯定応答の受信及
び更新の発生は相互に関して非同期的に生じる）。待ち
行列は２つのバッファに分けられ、それらの１つは、如
何なる特定の時間においても「アクティブ」バッファと
して指定される（当面の目的のために、もう１つのバッ
ファは「送信」バッファと呼ばれる）。現在アクティブ
であるどちらのバッファにも新しい更新が加えられる
（ステップ715）。伝送プロセスは、アクティブ・バッ
ファを変更する（スワップする）ことによって開始し
（ステップ750）、従って、前のアクティブバッファは
送信バッファとなり、一方、他のバッファは、新しい更
新が加えられるアクティブ・バッファとなる。又、「CA
N_SEND」フラッグは、伝送が進行中であることをことを
表すためにリセット（アンセット）される（ステップ76
0）（注意：それは既にリセットされていることもあ
る）。端末Ａから端末Ｂに更新を伝送するために如何に
長い時間を要するかに関する所定の基準にその更新が合
致するかどうかを決定するためのテストが送信バッファ
における各更新に対して行われる。比較的長い時間を必
要としそうな更新に対して、初期メッセージ（「グレイ
リスト」メッセージ）が先ず端末Ｂに送られる（ステッ
プ780）。グレイリスト・メッセージは、スクリーンの
どの領域に更新が施されるかを単に表すだけである。上
述のように、すべての更新がそれらの境界矩形によって
形成され、従って、グレイリスト・メッセージは２つの
座標（この実施例では、矩形の左上隅及び右下隅を含む
必要があるだけである。従って、グレイリスト・メッセ
ージのサイズが実際の更新のサイズに無関係であること
は明らかである。それはいつも非常に小さく、従って、
速く伝送可能である。この実施例では、所定の基準に合
致しない伝送バッファにおけるすべての更新に対して境
界矩形を含む単一のグレイリスト・メッセージが送られ
る。それは、これが多くの非常に小さいグレイリスト・
メッセージを別々に送るよりも更に効率的であるためで
ある（しかし、すべてのグレイリスト・メッセージを個
々に送ることは確かに可能であろう）。たとえ、グレイ
リスト・メッセージが複数の更新に関連するとしても、
それは依然として非常に小さいサイズであることに留意
して欲しい。

一旦、グレイリスト・メッセージが伝送されると（或
いは、送るべきグレイリスト・メッセージがない場合、
ステップ775のテストの直後に）、更新自体が端末Ｂに
伝送可能である（ステップ785）。その更新を送るステ
ップは、送信バッファからすべての更新を除去すること
及びそれらの通信ソフトウエアに送ることを表す。それ
らは比較的速く行われる。そこで通信ソフトウエアは端
末Ｂへのそれらの実際の伝送の責任を負う。グレイリス
ト・メッセージとは違って、送信バッファからの更新は
送るために個々のメッセージに維持される（これは単純
なFIFOに基づいて行うことができるが、それに関係な
く、更新なグレイリスト・パケットに含まれている）。
しかし、別の方法として、送信バッファにおけるすべて
の更新を集めて１つのメッセージにすることも考えられ
ることである。

待ち行列への更新の付加（ステップ715）がその更新
によって変更された領域をその待ち行列における他のも
のに関してチェックすることを含むことは明らかであろ
う。他の更新の中で完全に含まれる更新は除去され、一
方、重畳又は近接する更新は１つの更新によって置換さ
れる。実際に、この作用は送るべき更新の数をかなり減
少させる。待ち行列に記憶された更新は更新されてしま
ったスクリーンの領域を単に表すだけであることも理解
されよう。本実施例では、更新のための境界矩形の左上
隅及び右下隅が記憶される。更新と関連する実際のスク
リーン・データは、その更新が伝送の準備をされるまで
は（Windowsオペレーティング・システムへのリクエス
トを介して）得られることはない。これは大量のデータ
を待ち行列に記憶する必要をなくし、しかも、待ち行列
における更新の削除又はマージングをずっと簡単にす
る。

特定の更新に対するグレイリスト・メッセージを送る
べきかどうかに関する所定の基準は、更新の処理及び伝
送に起因する遅延に関連する。本実施例では、更新の領
域に基づくテストは非常に簡単である。例えば、200ピ
クセルの闘値よりも大きい領域を有する更新は、すべ
て、その更新自体の伝送前にグレイリスト・メッセージ
を送られる。しかし、例えば、遂行されるべきすべての
データ圧縮を考慮して、ずっと複雑なテストが使用可能
である。考慮される他の局面はプロセッサ・ローディン
グ（更新の任意のフォーマットの変換又は圧縮に必要な
時間に影響する）、及びネットワーク帯域幅及び現在の
ネットワーク・トラフィック（伝送時間に影響する）を
含んでいる。例えば、そのネットワークが比較的低い帯
域幅を有する場合、上記の闘値を更に小さいピクセル数
まで減少させることが望ましい。

端末Ｂにおいて受信された更新メッセージの処理が第
６図に示される。更新が端末Ｂに到達した（ステップ81
0）後、それがグレイリスト・メッセージである（即
ち、更新されたスクリーン・データ自体ではなく、更新
されるべき領域の指示だけを含む）か否かを知るために
それは調べられる（ステップ820）。それが肯定される
場合、更新された領域の範囲を表す情報が、その更新さ
れた領域を視覚的にマークするために、Windowsオペレ
ーティング・システムに対するPatBltコールによって利
用される（PatBltは前述のPetzold氏による文献に詳し
く開示されている）。このコールは、スクリーンの指定
された領域、即ち、更新されるべき遠隔制御ウインドウ
の領域をアプリケーション供給のパターンでもって満た
す（ステップ830）（そのパターンは指定された領域を
満たすために必要な回数だけ繰り返される）。本実施例
では、そのパターンはグレイ・ドットの配列を含む。こ
のオペレーションは非常に高速であり、その結果、指定
された領域における選択されたピクセルがグレイ・ドッ
トによって上書きされ、全体的な効果はその指定された
領域のグレイ化（クロス・ハッチング）である。この方
法では、ユーザは、スクリーンのグレイ化された領域が
その更新されつつあるプロセスにあることを知らされ
る。なお、如何なる遅延も、主として、データを処理し
そしてそれを遠隔の機械（端末Ａ）からローカルの機械
（端末Ｂ）に伝送するために必要な時間による。PatBlt
コールのパラメータは、グレイ・ドットのパターンがオ
リジナルのスクリーン・データに重畳されるように指定
される。この結果、そのオリジナルのデータは、依然と
して、それらのドットの間では実質的に可視的である。

前述のように、グレイリスト・パケットは、実際に、
幾つかの更新に関連した情報（座標のセット）を含むこ
とができる。この場合、各更新に対して、PatBltコール
が行われてその更新に対する適当な領域をグレイ・アウ
トする。

一方、受信されたメッセージが実際の更新データを表
す場合、肯定応答が端末Ａに戻される（ステップ84
0）。グレイリスト・メッセージに対しては、詳しく後
述するように、肯定応答が要求されないので、肯定応答
は送られないことに注意して欲しい。そこで、その更新
はスクリーンへの適用に対して待ち行列化される（複数
の更新が集められて１つのメッセージにされていた場
合、ここでは、それらは待ち行列への挿入のために分解
されるであろう。しかし、前述のように、本実施例で
は、更新は個々に送られる）。各更新がそれを端末にお
ける表示に適した形式に変換するためには、一定の量の
処理が必要である（ステップ850）。従って、本実施例
では、更新データは伝送端末においてデバイス独立ビッ
ト・マップ（DIB）フォーマットに変換され、しかる
後、受信端末において適当な表示フォーマットに戻され
る（しかし、DIBフォーマットを直接に表示すること
は、実際には可能であろう）。DIBフォーマットを使用
する理由は、それが端末Ａ及びＢの間の如何なるハード
ウエア上の相異（例えば、サポートされるカラーの数に
関する）も克服するということである。同様に、その更
新を圧縮解除することも必要であろう（しかし、通信ソ
フトウエアは既にこれを行っているかもしれない）。本
願では、実際の更新は、英国特許出願9422856.6号にお
いて開示された技法を使用してリモート端末とローカル
端末との間の伝送のために圧縮される。しかし、他の多
くのデータ圧縮アルゴリズムが適するであろう（状況に
よっては、如何なる圧縮も全く使用しない方が適当であ
るものもある）。

一旦、更新が適当なフォーマットに変換されてしまう
と、それは、BitBltコマンド（前述のPetzoldの文献に
おいて更に説明されているWindowsオペレーティング・
システムにおけるもう１つの標準的コマンド）を使用し
てスクリーンを与えられる（ステップ860）。BitBltオ
ペレーションは単にそのコマンドをスクリーンの関連領
域に上書きするだけなので、更新自体の到着前にその更
新領域を表すために使用されるすべてのグレイ・パター
ンを明確に除去する必要はない。

BitBltオペレーション及びPatBltオペレーションの両
方とも、端末Ａの座標から端末Ｂのウインドウの座標に
変換することが必要であるは明らかであろう。例えば、
端末Ｂから端末Ａに遠隔制御アクションをレポートする
ためには、明らかに逆変換で必要である。実際に、これ
は非常に簡単である。それは、端末Ｂにおける遠隔制御
ウインドウ（即ち、第４図におけるウインドウ610に対
応する）が一般には左上隅にそれの起点を有し、これが
端末Ａにおけるスクリーン座標と直接に対応するように
作られているためである。

前述の肯定応答の使用は、単に、単末Ｂが処理及び表
示のために更新によって過負荷にならないようにするた
めの制御機構として作用するだけである。換言すれば、
肯定応答は、端末Ｂが前の更新の処理を終了したこと、
従って、他の更新伝送を受容する準備ができていること
を表すように、端末Ａにおいて「CAN_SEND」フラッグを
制御するために有効に使用される。しかし、第６図に示
されるように、如何なるグレイリスト・メッセージに関
しても肯定応答は発生されないことに注意してほしい。
肯定応答は伝送端末のリクエスト時に発生される。グレ
イリスト・メッセージに対して、そのようなリクエスト
は行われない。これは、グレイリスト・メッセージが端
末Ｂにおいて非常に速く処理され、従って、システムに
おける大きな負荷を表さない。

簡単な遠隔制御コマンドの例が第７図に示される。先
ず、端末Ａにおけるアプリケーションが面900を表示す
る（第７図のａ）。端末Ａは端末Ｂから遠隔制御される
ので、同じ面のイメージが端末Ｂにおける遠隔制御ウイ
ンドウ910内にも表示される。（Windowsオペレーティン
グ・システムは、ウインドウ910内に適合するように面
イメージのサイズの縮小を処理する）。端末Ｂにおける
ポイント915には、カーソル位置が表される。端末Ｂに
おけるユーザがボタンのクリックのような何らかのマウ
ス・アクションを行うものと仮定すると、前述のよう
に、これは端末Ａに送り戻され、そして使用される。

そのマウス・アクションの結果、端末Ａにおけるアプ
リケーションは、口の形を悲しい形から笑顔に変更する
ものと仮定する。その結果、端末Ａにおけるスクリーン
・イメージは、第７図のｂに示されるように更新され
る。又、第７図のｂには、この更新に対する境界矩形92
0が示される（勿論、その境界矩形は、実際には、端末
Ａにおけるスクリーン上には現れない）。この段階で
は、端末Ｂは更新されていない。

端末Ａに対する更新の結果、前述のように、境界矩形
をサイズが所定の闘値を超えるかどうか決定するための
テストがその境界矩形に関して行われ、この結果、先
ず、端末Ａから端末Ｂへのグレイリスト・パケットの伝
送が生じ、次に実際の更新データの伝送が生じるものと
仮定する。第７図のｃの端末Ｂはグレイリスト・パケッ
トの到着後で且つ更新データの到着前における状況を示
す。境界矩形920に対応するウインドウ910の領域925は
グレイ化されている（表示を容易にするために、第７図
のｃでは影付きとして示される）。これは、端末Ｂにお
けるユーザに、それらのアクションが受信されそして処
理されつつあることを保証し、又、そのアクションが終
了する前の遅延の可能性があるという粗い表示を与え
る。（影付き領域が大きければ大きいほど、送られるべ
き更新は大きくなり、その起こりそうな遅延は長くな
る）。最後に、第７図にｄに示されるように、すべての
更新が到着しそして端末におけるスクリーンに与えられ
たので、端末Ｂにおける面930は再び端末Ａと同じにな
る。一般に、第７図のａと第７図のｃとの間のタイム・
インターバルは比較的短く、それによってユーザへの速
いフィードバックを与え、一方、第７図のｃと第７図の
ｄとの間のインターバルは、関連する更新の大きさ次第
で極めて大きくなることに留意して欲しい。例えば、一
般的な環境では、更新自体が末端Ｂに与えられるために
は、最初のコマンドから２秒を必要とし、一方、グレイ
化は数分の一秒内に実行可能である。

実際に、更新の発生は一般にクラスタ化されることが
わかっているので、一般には、１つ又は複数のユーザ・
アクションによって多数の更新が発生され、これの後
に、ユーザが思案のために休止する時、ほとんど更新の
ない一時的休止が生じる。他の端末への更新の伝送は、
それらの更新が速く発生される時には遅れることが多い
が、その一時休止中に遅れを取り戻すことが可能であ
る。

受信端末はスクリーンの関連部分をグレイ・アウトす
るので、更新の範囲に関する情報は「グレイリスト」メ
ッセージと呼ばれたけれども、実際には、スクリーンの
関連部分の明瞭な視覚的表示を行うための他の任意の技
法が使用可能である。例えば、或可能性は、更新される
べき領域を斜めの稿でもってマークすること、更新され
るべき領域を高輝度フレームでもって囲むこと、或いは
更新されるべき領域の背景カラーを変更することであろ
う。これらの提案はすべてスクリーンに描くのが速いこ
と、及び更新されたデータの到着まで、基礎となるスク
リーン表示をユーザがそのまま（少なくとも部分的に）
見ることができるという利点をすべてが保持しているこ
とに留意して欲しい。更に、そのマーキングが更新の領
域内に含まれるので、それは、更新自体が到着する時、
自動的に上書きされ、従って、そのマーキングを特別に
削除する必要がない。

上記のメッセージが、伝送遠隔制御アプリケーション
から通信ソフトウエアに送られるメッセージを表すこと
は明らかである。ネットワーク特性、メッセージ・サイ
ズ等次第で、通信ソフトウエアは、何れのメッセージも
小さいコンポーネントに分割すること、又は伝送のため
にそのメッセージを他のメッセージと結合して１つのパ
ケットにすることを決定することが可能である。そこ
で、受信の通信ソフトウエアは、その受信したメッセー
ジを受信遠隔制御アプリケーションに別々に送るために
逆の動作を遂行する。従って、メッセージ伝送のために
通信ソフトウエアによって選択されたフォーマットは遠
隔制御アプリケーションにとって透明であり、本発明に
直接関係するものではない。

産業上の利用可能性 理解を容易にするために２つの端末（「ポイント・ツ
ー・ポイント」として知られている）に関して遠隔制御
機能を説明したけれども、本実施例は、実際に、遠隔制
御されたスクリーンを複数の他の端末（「マルチポイン
ト」として知られている）から見ることを可能にする。
ポイント・ツー・ポイントからマルチポイントへの拡張
は、主として、グレイリスト・パケット及び更新をすべ
ての関連端末に送る通信ソフトウエアによって行われ
る。更新の処理を制御するために使用される肯定応答
（第５図参照）は、現在、更新を受信するために第１の
端末からの肯定応答に基づいているが、それは、或環境
では、更新を受信するために最後の端末からの肯定応答
を待つ方がよいかもしれない。更に、本発明は、主とし
て、遠隔制御機能に関連して説明されたけれども、例え
ば、１つの機械からの選択されたアプリケーション又は
ウインドウが単に他の端末において表示される（ミラー
リングされる）べき場合のような他の多くの状況におい
ても同様に適用可能である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 グラッドウィン、ベネデイクト、ダニエ ル イギリス国ハンツ、ウインチェスター、 リットルトン、デイーン・ダウン・ドロ ーブ チェストナッツ（番地なし) (56)参考文献 特開 平６−161957（ＪＰ，Ａ) 特開 昭57−182785（ＪＰ，Ａ) 特開 平２−190926（ＪＰ，Ａ) 特開 平４−93886（ＪＰ，Ａ) 欧州公開590817（ＥＰ，Ａ１) (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 13/00 G06F 3/153 G09G 5/00

Claims (22)

(57)【特許請求の範囲】
1. 【請求項１】ディスプレイ・スクリーンを有し、リモー
   ト・ワークステーション（200）にリンクされたコンピ
   ュータ・ワークステーション（100）を操作する方法で
   あって、 前記コンピュータ・ワークステーションのスクリーンに
   対する更新を発生するステップと、 前記コンピュータ・ワークステーションのスクリーンに
   おける更新されようとしている領域を決定するステップ
   と、 前記更新されようとしている領域の指示を前記リモート
   ・ワークステーションに伝送するステップと、 前記更新されようとしている領域の指示の前記伝送の後
   に、前記更新を表すデータを前記リモート・ワークステ
   ーションに別に伝送するステップと、 を含む方法。
2. 【請求項２】前記更新を所定の基準と比較するステップ
   を含み、それによって、そのような基準と合致した場
   合、前記更新は更新された領域を表す指示を事前伝送す
   ることなく直接に伝送されることを特徴とする請求の範
   囲第１項に記載の方法。
3. 【請求項３】前記所定の基準は前記更新された領域のサ
   イズに関連することを特徴とする請求の範囲第２項に記
   載の方法。
4. 【請求項４】名更新はそれの境界矩形によって処理され
   ることを特徴とする請求の範囲第１項乃至第３項の１つ
   に記載の方法。
5. 【請求項５】複数の更新に対する更新された領域の指示
   が１つのメッセージで伝送されることを特徴とする請求
   の範囲第１項乃至第４項の１つに記載の方法。
6. 【請求項６】先ず前記リモート・ワークステーションか
   らコマンドを受信するステップ（530）、及び前記コマ
   ンドを前記コンピュータ・ワークステーションにおいて
   実行して前記更新を発生するステップ（540）を含むこ
   とを特徴とする請求の範囲第１項乃至第５項の１つに記
   載の方法。
7. 【請求項７】ディスプレイ・スクリーンを有し、リモー
   ト・ワークステーション（200）にリンクされたコンピ
   ュータ・ワークステーション（100）であって、 前記コンピュータ・ワークステーションのディスプレイ
   ・スクリーンに対する更新を発生するための手段と、 前記コンピュータ・ワークステーションのディスプレイ
   ・スクリーンの更新されようとしている領域を決定する
   ための手段と、 前記更新されようとしている領域の指示を前記リモート
   ・ワークステーションに伝送するための手段と、 前記更新されようとしている領域の指示の前記伝送の後
   に、前記更新を表すデータを前記リモート・ワークステ
   ーションに別に伝送するための手段と、 を含むコンピュータ・ワークステーション。
8. 【請求項８】リモート・ワークステーション（200）に
   リンクされたコンピュータ・ワークステーション（10
   0）を操作する方法であって、前記コンピュータ・ワー
   クステーションのスクリーンの少なくとも一部分が前記
   リモート・ワークステーションのスクリーンの少なくと
   も一部分に対応するように配列されているものにおい
   て、 更新が施されようとしている前記リモート・ワークステ
   ーションのスクリーンの領域を表す第１メッセージを前
   記リモート・ワークステーションから受信するステップ
   と、 前記更新が施されようとしている前記リモート・ワーク
   ステーションの部分に対応する前記コンピュータ・ワー
   クステーションのスクリーンの領域を視覚的に指示する
   ステップと、 前記リモート・ワークステーションに対して行われた更
   新を含む第２メッセージを前記リモート・ワークステー
   ションから受信するステップと、 前記コンピュータ・ワークステーションにおいて前記更
   新を前記スクリーンの前記指示された領域に施すステッ
   プと、 を含む方法。
9. 【請求項９】前記領域を視覚的に指示するステップは当
   該領域におけるオリジナルのイメージが実質的に可視的
   なままであることを妨げないことを特徴とする請求の範
   囲第８項に記載の方法。
10. 【請求項１０】前記領域を視覚的に指示するステップ
    は、関連する領域をグレイ・アウトすることを含むこと
    を特徴とする請求の範囲第８項又は第９項に記載の方
    法。
11. 【請求項１１】前記領域を視覚的に指示するステップ
    は、背景カラーを反転すること又は関連する領域を稿模
    様にすることを含むことを特徴とする請求の範囲第８項
    又は第９項に記載の方法。
12. 【請求項１２】各更新はそれの境界矩形によって処理さ
    れることを特徴とする請求の範囲第８項乃至第11項の１
    つに記載の方法。
13. 【請求項１３】先ず前記リモート・ワークステーション
    にコマンドを送るステップ（440）を含み、それによっ
    て、前記更新が前記コマンドに応答して前記リモート・
    ワークステーションにおいて施されることを特徴とする
    請求の範囲第８項乃至第12項の１つに記載の方法。
14. 【請求項１４】リモート・ワークステーション（200）
    にリンクされたコンピュータ・ワークステーション（10
    0）であって、前記コンピュータ・ワークステーション
    のスクリーンの少なくとも一部分が前記リモート・ワー
    クステーションのスクリーンの少なくとも一部分に対応
    するように配列されているものにおいて、 更新が施されようとしている前記リモート・ワークステ
    ーションのスクリーンの領域を表す第１メッセージを前
    記リモート・ワークステーションから受信するための手
    段と、 前記更新が施されようとしている前記リモート・ワーク
    ステーションの部分に対応する前記コンピュータ・ワー
    クステーションのスクリーンの領域を視覚的に指示する
    ための手段と、 前記リモート・ワークステーションに対して行われた更
    新を含む第２メッセージを前記リモート・ワークステー
    ションから受信するための手段と、 前記コンピュータ・ワークステーションにおける前記更
    新を、前記指示された前記スクリーンの領域に施すため
    の手段と、 を含むコンピュータ・ワークステーション。
15. 【請求項１５】リモート・ワークステーション（200）
    からのディスプレイ・スクリーンの少なくとも一部分を
    ローカル・ワークステーション（100）のディスプレイ
    ・スクリーン上にミラーリングし、それによって、前記
    リモート・ワークステーションのスクリーンに施された
    更新が前記ローカル・ワークステーションに対応して施
    される方法であって、 前記リモート・ワークステーションのスクリーンに更新
    を施すステップと、 前記リモート・ワークステーションの更新されようとし
    ている領域を決定するステップと、 前記更新されようとしている領域の指示を前記リモート
    ・ワークステーションから前記ローカル・ワークステー
    ションに伝送するステップと、 前記指示を前記ローカル・ワークステーションにおいて
    受信するステップと、 前記更新が施された前記リモート・ワークステーション
    の指示された領域に対応する前記ローカル・ワークステ
    ーションの領域を視覚的に指示するステップと、 前記スクリーンに施された更新を表すデータを前記リモ
    ート・ワークステーションから前記ローカル・ワークス
    テーションに別に伝送するステップと、 前記更新を前記ローカル・ワークステーションにおいて
    受信するステップと、 前記更新を前記ローカル・ワークステーションにおける
    スクリーンの前記指示された領域に施すステップと、 を含む方法。
16. 【請求項１６】前記更新を前記リモート・ワークステー
    ションにおける所定の基準と比較するステップ（775）
    を含み、それによって、そのような基準が合致する場
    合、前記更新された領域の指示を事前伝送することなく
    前記更新が直接に伝送され、及びそのような基準が合致
    しない場合、前記更新された領域の指示が前記更新を表
    すデータの伝送前に伝送されることを特徴とする請求の
    範囲第15項に記載の方法。
17. 【請求項１７】前記所定の基準は前記更新された領域の
    サイズに関連することを特徴とする請求の範囲第16項に
    記載の方法。
18. 【請求項１８】各更新はそれの境界矩形によって処理さ
    れることを特徴とする請求の範囲第15項乃至第17項の１
    つに記載の方法。
19. 【請求項１９】前記領域を視覚的に指示するステップは
    当該領域におけるオリジナルのイメージが実質的に可視
    的なまま残ることを妨げないことを特徴とする請求の範
    囲第15項乃至第18項の１つに記載の方法。
20. 【請求項２０】前記領域を視覚的に指示するステップ
    は、関連の領域をグレイ・アウトすることを含むことを
    特徴とする請求の範囲第15項乃至第19項の１つに記載の
    方法。
21. 【請求項２１】前記領域を視覚的に指示するステップ
    は、背景カラーを反転すること又は関連領域を稿模様に
    することを含むことを特徴とする請求の範囲第15項乃至
    第19項の１つに記載の方法。
22. 【請求項２２】先ず前記ローカル・ワークステーション
    から前記リモート・ワークステーションにコマンドを送
    るステップを含み、それによって、前記更新が前記コマ
    ンドに応答して前記リモート・ワークステーションにお
    いて施されることを特徴とする請求の範囲第15項乃至第
    21項の１つに記載の方法。