JPH10500514A

JPH10500514A - コンピュータ・ワークステーション

Info

Publication number: JPH10500514A
Application number: JP8518389A
Authority: JP
Inventors: シングルトン、ヴェンセント、ジョセフ; アダムス、ポール、スチュアート; グラッドウィン、ベネデイクト、ダニエル
Original assignee: インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン
Priority date: 1994-12-13
Filing date: 1995-08-23
Publication date: 1998-01-13
Anticipated expiration: 2015-08-23
Also published as: DE69506914D1; JP2970687B2; EP0797796A1; GB9425142D0; EP0797796B1; GB2296114A; WO1996018943A1; DE69506914T2

Abstract

(57)【要約】２つのコンピュータ・ワークステーションが通信リンク３００によって共に接続される。一方の（ローカル）ワークステーション）１００は、他方の（リモート）ワークステーション２００のスクリーン上に現在表示されているもののコピーを表示するために使用されるウインドウ６１０を含む。リモート・ワークステーションのスクリーンに対する更新が行われる度に、その更新はローカル・ワークステーションに伝送されなければならない。更新によって変更されるそのスクリーンの領域に対する境界矩形９２０が決定される。境界矩形が所定サイズよりも大きい場合、実際の更新自体の伝送前に、第１パケットがリモート・ワークステーションからローカル・ワークステーションに伝送される。この第１パケットはスクリーンの更新された領域に対する境界矩形を表す。ローカル・ワークステーションは第１パケットに応答して遠隔スクリーンのコピーを含むそのウインドウの対応する領域９２５をグレイ化し（影付きにし）、それによって、更新がすぐに生じることをローカル・スクリーンのユーザに表示する。

Description

【発明の詳細な説明】コンピュータ・ワークステーション技術分野本発明は、第１コンピュータ・ワークステーションのスクリーンに対して行われた更新が第２コンピュータ・ワークステーションに伝送され、その更新のコピーが第２コンピュータ・ワークステーションのスクリーン上に表示されるシステムに関するものである。背景技術近年、コンピュータ・ワークステーション同士がデータを交換することを可能にするために、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）において、或いは、統合サービス・ディジタル・ネットワーク（ＩＳＤＮ）接続によってコンピュータ・ワークステーションをリンクすることが益々一般的になっている。これは、一般に、連携作業（ｃｏｌｌａｂｏｒａｔｉｖｅ−ｗｏｒｋｉｎｇ）とよく呼ばれるコンピュータ・テクノロジの新しい分野を生じさせた。連携作業の特定の例の２つがアプリケーション共用及び遠隔制御である。前者では、１つのアプリケーションが２つの機械において実行され、一方の機械においてそのアプリケーションになされた更新が他方の機械に伝送され、そして他方の機械においてミラーリングされる。明らかに、この技法は３つ以上の機械にも拡張可能である。遠隔制御では、一方の機械において実行中のアプリケーションが他方の機械においてユーザにより効果的に制御される。連携作業システムの例は、ヨーロッパ特許出願ＥＰＡ−４７５５８１及び国際特許出願ＷＯ８９／１２８５９において見ることができる。連携作業における１つの問題は、通信リンクを通してデータを伝送する必要があるために応答時間が遅いことがあるということである。これは、例えば、遠隔制御において、ローカルの機械のユーザがマウス・ボタンのクリックのような何らかのアクションを行うが、遠隔制御されている機械とコミュニケートするために必要な時間のために如何なる即時応答も得られない時、特に欲求不満を生じさせることがある。この遅れの間、ユーザは、自分のマウス・アクションがシステムによって受け入れられなかったと勘違いしてそのアクションを繰り返すことがある。しかし、これによって、最終的には、当初の意図に反してそのアクションが２回行われるという結果になるであろう。機械がデータを処理しようとしているという何らかの表示を行うことは、勿論、通常の独立型ワークステーションにおいては知られている。例えば、ＩＢＭ社から入手可能なＯＳ／２オペレーティング・システムでは、システムが現在リクエストされたアクションを実行していることを表すために、カーソルが時計の形に変化する。別の方法として、リクエストされたアクションが進行中であることを記述したテキスト・メッセージを表示することも可能である。所定のＨＴＭＬフォーマットを持った情報ページを与える情報を、クライアントの端末が遠隔のサーバから検索することもワールド・ワイド・ウェブに関連して知られている。或ページが、そのページに含まれるべきイメージを表す別のグラフィックス・ファイルの引用を含むことも可能である。クライアントがそのようなページを検索する時、クライアントは、そのイメージを検索するためにはそのグラフィックス・ファイルをアクセスすべきであることを知る。クライアントは、イメージを位置付けるべきスクリーンの特定の領域を決定することができるように、先ず、イメージ自体よりも前にそのイメージに対するヘッダ情報を与えるようにサーバにリクエストすることができる。一旦そのイメージ・データ自体が検索されてしまうと、そのイメージが満たすべきボックス又は領域をそのままにして、クライアントはそのページに対するテキストをスクリーンに書くことができる。この方法はクライアント及びサーバの明確なサポートを必要とし、基本的にはクライアント（即ち、受信）端末によって駆動される。それは連携作業環境に直接に適用し得るものではない。 Computer Practices，Communications of the ACM 誌の Vol.30，No.1，Jan． 1987 の pp.32-47 における M.Stefik，G.Foster，D.Bobrow，K.Kahn，S.Lannin g 及び L.Suchman 氏による「黒板を越えて：会議における連携及び問題解決のためのコンピュータ・サポート(Beyond the Chalkboard: Computer Support for C ollaboration and Problem Solving in Meetings)」と題した論文は連携作業システム（しかし、それは遠隔制御を述べてはいない）を開示している。２人以上のユーザが共用オブジェクトを同時に編集しようとする問題を克服するために、一方のユーザが現在作業している項目はグレイ・アウト（ｇｒｅｙｏｕｔ）される。この方法は、特別に適応されたアプリケーション（例えば、どの項目が編集されようとしているかを監視するための）を必要とする。しかし、更に最近の連携作業システムに対する重要な目的は、それらが既存の（独立した）アプリケーション（例えば、遠隔制御を行うための）を働かせることができなければならないことである。発明の開示従って、本発明は、ディスプレイ・スクリーンを有し、ローカル・ワークステーションにリンクされたリモート・コンピュータ・ワークステーションを操作する方法を提供するものであり、その方法は、前記リモート・ワークステーションのスクリーンに対する更新を発生するステップと、前記リモート・ワークステーションの更新されようとしている領域を決定するステップと、前記更新されようとしている領域の指示を前記ローカル・ワークステーションに伝送するステップと、前記更新を表すデータを前記ローカル・ワークステーションに別に伝送するステップと、を含んでいる。それに対応して、本発明は、リモート・ワークステーションにリンクされたローカル・ワークステーションを操作する方法も提供するものである。前記ローカル・ワークステーションのスクリーンの少なくとも一部分は前記リモート・ワークステーションのスクリーンの少なくとも一部分に対応するように配列される。その方法は、更新が施されようとしているリモート・ワークステーションのスクリーンの領域を表す第１メッセージを前記リモート・ワークステーションから受信するステップと、前記更新が施されようとしている前記リモート・ワークステーションのスクリーンの部分に対応した前記ローカル・ワークステーションの領域を視覚的に指示するステップと、前記リモート・ワークステーションに対して行われた更新を含む第２メッセージを前記リモート・ワークステーションから受信するステップと、前記ローカル・ワークステーションにおける前記更新を、前記指示された前記スクリーンの領域に施すステップと、を含むものである。従って、一方のコンピュータ（リモート・ワークステーション）において行われた更新が他方のコンピュータ（ローカル・ワークステーション）のスクリーン上にミラーリングされる（即ち、表示される）べき状況において、本発明は、その更新が処理及び伝送されようとしていることの表示をローカル・ワークステーションのユーザに与えることが重要であるということを認識している。これは、始めに更新を行うこと及びローカル・ワークステーションにおいてそれを表示できることの間の遅延は、その更新を処理及び伝送するための必要な時間のために意味あることであるが、それによって、ローカル・ワークステーションにおけるユーザが正しい制御オペレーションを行うことを困難にしているためである。従って、本発明によれば、実際の更新自体の伝送の前に、その更新によって影響を受けたスクリーン領域の指示を含むメッセージがリモート・ワークステーションからローカル・ワークステーションに伝送される。そのメッセージは、更新データ自体ではなく更新された領域の指示を含むだけなので、この更新領域メッセージは比較的小さく、従って、更新データ自体よりもずっと速く処理及び伝送することが可能である。事実、その領域に対する境界矩形によって更新領域を表すことが都合がよく、従って、更新された領域の表示は、ちょうど２対の座標（例えば、左上隅及び右下隅）によって与えられる。そこで、更新領域の指示は、すぐ後に生じる更新が施される領域をローカル・ワークステーションにおけるスクリーン上に視覚的に示すために使用される。これは、更新されるべき領域を実際にマークすることに関連するということに留意して欲しい。これは幾つかの利点を有する。先ず、更新自体がその後施される時、それは自動的に上書きされるので、そのマーキングを後で明示的に削除する必要がない。第２に、それはユーザがすぐ後に生じる更新のサイズを知ることを可能にし、従って、更新自体が受信される前に、予想される遅延の概略の見積を行うことを可能にする（大きい領域に対する遅延は、明らかに、処理及び伝送に長く時間かかり易いので）。又、それは、すぐ後に生じる更新の性質に関する何らかの情報をユーザに与える（例えば、ユーザは、更新が影響を与えないスクリーンの部分を直ちに知ることができる）。更なるメッセージがその伝送されるべき更新領域を含むことを必要とすることによって、本発明の方法は、実際には、更新自体を送ることの遅れをわずかに増大するであろう。しかし、実際には、この余分な遅延によって生じる損失は、ローカル・ワークステーションにおいてすぐにユーザに利用され、正確な制御オペレーションを遂行する能力を大いに強化するその更新領域に関する初期情報によって補償されるものではない。これに対する唯一の例外は、更新自体がほとんどその更新領域を表すメッセージのように速く受信されるように、その更新が非常に速く処理及び伝送される時である。これに関しては、更新が少なければ少ないほど、更新領域メッセージに起因する伝送及び処理要件の増加は比例的に大きくなることは留意すべきである。それは、更新領域メッセージのサイズが一般には更新自体の範囲に関係ないためである（しかし、これは特に大きな効果ではない）。従って、好適な実施例では、その方法は、更に、その更新を所定の基準と比較するステップを含み、それによって、そのような基準が合致する場合、その更新は、更新された領域の表示の事前伝送なしに直接に伝送される。その更新された基準は、その更新が処理され、そしてローカル・ワークステーションへ伝送される速度に関連する。これが非常に速く行われる場合、その更新された領域のメッセージを送ることにおける利点は比較的小さいものである（事実、上述のように、実際には、それはわずかな損失を表すだけである）。一般に、所定の基準は、更新された領域のサイズ、即ち、更新されたピクセルの数に関連する。本実施例では、更新されるピクセルの数が一定の閾値を超えた場合、更新領域メッセージが送られる。一般に、明らかに大幅な更新は伝送に長い時間を取り、リモート・ワークステーション及びローカル・ワークステーションの両方において処理に長い時間を取るので、この簡単なテストは効果的である。しかし、この方法の拡張を予測することは容易であり、それによって、その閾値は、例えば、ローカル・ワークステーション及びリモート・ワークステーションの間の通信リンクの帯域幅及びそのリンクにおける現在のトラフィック量に従って、或いはプロセッサ・ローディングに従って変更されてもよい。１つの可能性は、リモート・ワークステーションにおける更新の発生及びローカル・ワークステーションにおけるそれの表示の間の遅れを周期的に測定し、それに従って閾値を変更することである。例えば、所定の基準に含まれてもよいもう１つの要素は、更新データに関して遂行されるべきデータ圧縮（それがある場合）の効果である。それは、これが処理及び伝送時間にも影響を与えるためである。非常に小さい更新領域メッセージの処理効率を改良するための１つの方法は、複数の更新に対するその更新された領域の指示を１つのメッセージで伝送することである。ほとんどの通信システムは、１つのメッセージ当たり、ある程度の一定のオーバヘッドを有するので、幾つかの非常に小さい更新領域メッセージを個々に送ることは比較的非効率的であるため、これは有益である。従って、複数の更新のための領域の指示を結合して１つのメッセージにすることは、ローカル・ワークステーションにおける更新領域情報の最終的な到着にわずかな遅れ（それがあったとしても）を加えるだけで、システム及びネットワークのパフォーマンスを助けることができる。１つの領域を視覚的に指示するステップは、その領域におけるオリジナルのイメージ（即ち、テキスト、図形、或いは如何なるものでも）が実質的に可視状態のままであることを妨げず、従って、更新自体が到着した時に上書きされるまで、それはユーザにとって識別可能のままであることが望ましい。これを行う速く且つ効率的な方法は、関連する領域をグレイ・アウト（網目模様に）することであるが、多くの他の代替方法（例えば、縞模様、関連領域の背景色の変更、或いは色付けされた枠による関連領域の縁取り）も使用可能である。本発明は、先ず、ローカル・ワークステーションにおけるユーザからのコマンドがリモート・ワークステーションにおいて受信され、そしてこのコマンドの結果として更新が発生されるという状況において特に有益である。これは、そのコマンドに対する応答を知るのに遅れがあって、そのコマンドが受領されたかどうか確信がない場合、ローカル・ワークステーションにおけるユーザが性急になるためである。これは、ユーザがそのコマンドを反復することに通じ、思いも寄らない（及び望ましくない）結果をもたらすかもしれない。この問題は、更新領域メッセージを送ることによって回避される。それは、可視的な応答がローカル・ワークステーションにおけるユーザに速く表示されることをこれが可能にし、それによって、そのコマンドがアクティブに処理されることをユーザに再保証するためである。事実、ユーザは、その更新が既にそのコマンドに応答して発生されている（即ち、そのコマンドは受領され、伝送され、更新を発生するように実行されている）ことを知る。更に、上述のように、指示された領域のサイズは、更新自体がローカル・ワークステーションにおける表示のために処理及び伝送されるまでの時間をユーザが粗く見積もることを可能にする。その指示された領域は、ユーザのコマンドの結果として変更されようとしているスクリーンの領域を、勿論、そのユーザにも知らせる。次に、ローカル・ワークステーション及びリモート・ワークステーションの考察に話を進めると、本発明はディスプレイ・スクリーンの少なくとも一部分をリモート・ワークステーションからローカル・ワークステーションのディスプレイ・スクリーン上にミラーリングする方法を提供し、それによって、リモート・ワークステーションのスクリーンに施された更新は、それに対応してローカル・ワークステーションにも施される。その方法は、リモート・ワークステーションのスクリーンに更新を施すステップと、更新されようとしているリモート・ワークステーションのスクリーンの領域を決定するステップと、更新されようとしている領域の指示をリモート・ワークステーションからローカル・ワークステーションに伝送するステップと、前記指示をローカル・ワークステーションにおいて受信するステップと、前記更新が施されたリモート・ワークステーションのスクリーンの指示された領域に対応するローカル・ワークステーションのスクリーンの領域を視覚的に表すステップと、スクリーンに施された更新を表すデータをリモート・ワークステーションからローカル・ワークステーションに別々に伝送するステップと、前記更新をローカル・ワークステーションにおいて受信するステップと、ローカル・ワークステーションにおけるスクリーンの前記指示された領域に前記更新を施すステップと、を含んでいる。本発明は、２つのワークステーションしか持たないシステムに限定されるのではなく、オリジナルの更新が複数の他のスクリーンにコピーされるシステムに等しく適用可能であることにも留意して欲しい。そのような場合、更新領域の指示は、一般に、複数の他のスクリーンに与えられるであろうが、或端末に対するリンクが他の端末に対するリンクよりもずっと遅い場合、その遅いリンクによって接続される端末だけが実際の更新自体の前に更新領域メッセージを受信することは理解されるであろう。本発明は、更に、上記の方法を実施するための装置を提供する。図面の簡単な説明次の図面に関連して、本発明の実施例を詳細に説明することにする。第１図は、代表的なコンピュータ・ワークステーションの簡略化した図である。第２図は、本発明を実施する場合に利用される主要なソフトウエア・コンポーネントの概略図である。第３Ａ図及び第３Ｂ図は、遠隔制御の一般的なオペレーションを示すフローチャートである。第４図は、遠隔制御を行おうとするコンピュータ・ワークステーションのスクリーンの概略図である。第５図は、遠隔端末装置における更新の処理を表すフローチャートである。第６図は、遠隔制御を行おうとしているコンピュータ・ワークステーションにおける更新の処理を表すフローチャートである。第７図は、遠隔制御オペレーションの例を示す図である。発明を実施するための最良の形態第１図は、システム・ユニット１０、ディスプレイ・スクリーン１２、キーボード１４、及びマウス１６を持ったコンピュータ・システムの簡略化した概略図である。システム・ユニット１０はマイクロプロセッサ２２、半導体メモリ（ＲＯＭ／ＲＡＭ）２４、及びデータを転送するバス２６を含んでいる。第１図のコンピュータは、ＩＢＭ社から入手可能なＰＳ／２コンピュータのような任意の通常のワークステーションであってもよい。第１図のコンピュータはネットワーク・アダプタ・カード３０を備えている。このカードは、付属のソフトウエアと一緒になって、メッセージがそのコンピュータ・ワークステーションから伝送されること及びそのコンピュータ・ワークステーションによって受信されることを可能にする。トークン・リング、イーサネット、ＩＳＤＮ等のような種々のネットワークによる使用のために、種々の形式のネットワーク・アダプタ・カードが利用可能である。そのネットワーク・アダプタ・カードのオペレーションは周知であり、従って、詳細には説明しないことにする。第２図は、遠隔制御セッションに関連した２つの端末Ａ及びＢにおける主要なソフトウエア・コンポーネントを示す。各端末は、第１図に示されたようなコンピュータ・ワークステーション１００、２００を含み、マイクロソフト社から入手可能なＷｉｎｄｏｗｓオペレーティング・システム１３０、２３０を実行する（厳密に云えば、勿論、そのオペレーティング・システムはＷｉｎｄｏｗｓがその上で走るＤＯＳであるが、この区別は本発明には関係ない）。Ｗｉｎｄｏｗｓオペレーティング・システムに関する更なる詳細は、Microsoft Press 発行の C hatjes Petzold 著の「プログラミングＷｉｎｄｏｗｓ（Programming Windows）」において見ることができる。そのオペレーティング・システムの下で動作するデバイス・ドライバ１５０、２５０は、そのオペレーティング・システムとそのコンピュータに取り付けられた外部装置との間の相互接続を制御する。各ワークステーションに対して、３つの特定のデバイス・ドライバが示されている。第１のものはマウス・デバイス・ドライバ１５５、２５５であり、それは、マウス１６から受け取ったそのマウスのロケーションに関する情報及びどのボタンが押されているかに関する情報をオペレーティング・システムに送る。スクリーン・デバイス・ドライバ１５６、２５６は、ディスプレイ・スクリーン１２上にイメージを表示するためにオペレーティング・システムによって使用される。最後に、通信デバイス・ドライバ１５７、２５７は、オペレーティング・システムとネットワーク・アダプタ・カード３０の間のインターフェースとして使用される。デバイス・ドライバはその分野では周知であることは認められており、従って、更に詳しくそれを説明することはしない。同様に、他のデバイス・ドライバ（例えば、キーボード１４に関するもの）でもよいが、これらは本発明を理解するために直接関連するものではないので省略した。各端末は通信ソフトウエア１２０、２２０も含んでおり、それらはコンピュータ相互間のリンク３００を介して（通信デバイス・ドライバを介して）メッセージを伝送することを可能にする。又、そのようなメッセージング・ソフトウエアはその分野では周知であり、従って、更にそれを説明することはしない。最後に、各ワークステーションにおいて走るアプリケーション１１０、２１０がある。ＲＣ１１６、２１６として示された特定のアプリケーションは遠隔制御機能を与え、それによって、第２図における一方のコンピュータ・ワークステーションが他方のワークステーションを遠隔操作又は制御するために使用可能である。その目的のために、ユーザは端末Ｂにあり且つ端末Ａを遠隔制御しようとしているものと仮定する。更に詳しく云えば、端末Ｂにおけるユーザは端末Ａにおける残りのアプリケーション（ＲＣではない）を制御しようとしている。説明を簡単にするために、端末Ａでは１つのアプリケーションだけが示されているが、実際には、その遠隔制御機能は端末Ａにおける複数のアプリケーションを処理することができる。端末ＢにはアクティブなＲＣ以外にもアプリケーション（Ａｐｐｓ）１１５が存在するが、これらは本発明を理解するに当たって直接に関連するものではない。遠隔制御の一般的な動作が第３Ａ図及び第３Ｂ図に示され、それらは、それぞれ、端末Ａ及びＢにおける発生事項を示している。両方のロケーションにおける第１のアクションは遠隔制御アプリケーションを開始することである（ステップ４１０、５１０）。これは、それらの２つの端末等の間に通信チャネルを設定することに関連する。この初期設定の一部分として、端末Ａのスクリーン全体が端末Ａから端末Ｂへ伝送され（ステップ５２０）、端末Ｂにおいて、それは、一般には、遠隔制御ウインドウに表示される（ステップ４２０）。今や、ユーザが端末Ｂにおいて遠隔制御に入ることによって、遠隔制御が開始可能である（ステップ４３０）。そこで、これは端末Ａに伝送され（ステップ４４０）、端末Ａにおいて、それは受信され（ステップ５３０）、その遠隔制御アプリケーションにいて適当に遂行される（ステップ５４０）。この結果、端末Ａのスクリーンに対する更新の発生が生じるものと仮定すると（ステップ５５０）、この更新は端末Ａから端末Ｂに伝送され（ステップ５６０）、端末Ｂにおいて、それは型どおり受信され（ステップ４５０）、端末Ａにおけるスクリーンを表す遠隔制御ウインドウがそれに従って更新される（ステップ４６０）。端末Ｂからの如何なる特定のアクションを必要とすることなく、端末Ａにおいて更新が発生可能であることに注意して欲しい。これの代表的な例は、ＡＰＰ１が端末Ａにおけるスクリーン上に時計を表示する場合であろう。従って、時計の針が動く時には、いつも、端末Ａにおいて更新が自動的に発生され（ステップ５５０）、しかる後、端末Ｂに送られる。端末Ｂにおいて、それは受信されそして表示される（ステップ４５０、４６０）。従って、端末Ａでは、更新の発生及び端末Ｂへのそれらの伝送は、端末Ｂからの遠隔制御アクションの受信に関して非同期的に生じ得る。同様に、端末Ｂにおける更新の受信及び表示は、端末Ａへの遠隔制御コマンドの伝送に関して非同期的に生じ得る。第４図は端末Ｂにおけるスクリーン６００を示し、それは遠隔制御ウインドウ６１０を含んでいる。Ｗｉｎｄｏｗｓオペレーティング・システムはこのウインドウのロケーションを知っており、或ユーザ・アクションはそのＷｉｎｄｏｗｓオペレーティング・システムによって自動的に処理される。例えば、アクション・バー６２０におけるクリックの結果、メニューが表示される。しかし、端末Ａからのウインドウ６５０が端末Ｂにおいて（遠隔制御ウインドウ６１０内に）表示される時、端末ＢにおけるＷｉｎｄｏｗｓオペレーティング・システムはそれがウインドウであることを知らず、遠隔制御ウインドウ内に表示されたビット・マップの一部分としてそれを見なすだけである。端末Ｂが端末Ａからのスクリーン全体をウインドウ６１０に表示する時、何らかのサイズの縮小が必要であることは明らかであろう。２つの方法が可能である。即ち、スクリーン全体がその使用可能なウインドウ・サイズに適合するように縮小される（Ｗｉｎｄｏｗｓオペレーティング・システムはこの機能を直接に遂行することができる）か、或いは端末Ｂにおけるウインドウが端末Ａからのスクリーンの一部分だけを表示する。しかる後、そのスクリーンの他の部分へのアクセスを可能にするために、このウインドウ内でスクロール・アクションを行うことが可能である。いずれの場合も、前述のように、端末Ａからのスクリーンは単にビット・マップとして表示される。遠隔制御オペレーションに進むと、端末Ｂにおけるユーザは何らかのマウス・アクションを行うこと、例えば、ウインドウ６５０におけるアクション・バー６６０においてマウス・ボタンをクリックすることを決定する。前段で述べたように、端末ＢにおけるＷｉｎｄｏｗｓオペレーティング・システムはアクション・バー６６０の存在を知らないので、それは、単に、ウインドウ６１０と関連してそのマウス・クリックのロケーションを表すマウス・クリック事象を遠隔制御アプリケーション１１６に報告するだけである。そこで、遠隔制御アプリケーションは、そのマウス・クリックのロケーションを含むメッセージを発生し、そしてそのメッセージは、標準的な通信手順を使用して、端末Ａにおける遠隔制御アプリケーションに送られる。そこで、端末Ａにおける遠隔制御アプリケーション２１６は、このメッセージの受信時に、端末Ａで生じる同等の事象をシミュレートする。それは、Ｗｉｎｄｏｗｓオペレーティング・システム及びマウス・デバイス・ドライバの間のインターフェースを使用することによってこれを行う。従って、その遠隔制御アプリケーションは、マウス事象が生じたことをマウス・デバイス・ドライバがＷｉｎｄｏｗｓオペレーティング・システムに知らせるために通常使用するそのＷｉｎｄｏｗｓオペレーティング・システムに対するエントリ・ポイントを呼び出す。換言すれば、遠隔制御アプリケーションは、マウス・デバイス・ドライバであるように効果的に装う。従って、それは、マウス・アクションが生じたことを、そのマウス・アクションの性質と端末Ｂにおける遠隔制御ウインドウ内のそのユーザにより遂行されたアクションに対応するそのマウス・アクションのロケーションとをＷｉｎｄｏｗｓオペレーティング・システムに知らせる。そこで、Ｗｉｎｄｏｗｓオペレーティング・システムはウインドウ６５０に責任のあるアプリケーションＡＰＰ１にこのマウス事象を送る（勿論、それがアクション・バー事象又は同様のものでない場合、それは、前述のように、端末ＡにおけるＷｉｎｄｏｗｓオペレーティング・システムによって直接に処理される）。次に、端末Ａにおける更新の処理に話題を変えると、第３Ａ図に示されるように、スクリーン更新は端末Ｂから遠隔制御を通して受信したコマンドに応答して生じるか、又は、単に端末Ａにおける処理（端末Ａにおけるクロックの操作のような）によって生じることが可能である。そこで、スクリーンのどの領域が更新されたかを決定することが必要である。その使用される技法は、ヨーロッパ特許出願ＥＰＡ−５９０８１７に開示されたものと本質的に同じであるので、単に概説するに留める。その方法は、第２図においてグラフィカル・デバイス・インターフェース（ＧＤＩ）１３５、２３５として概略的に表されたオペレーティング・システム及びスクリーン・デバイス・ドライバの間のインターフェースを活用する。Ｗｉｎｄｏｗｓオペレーティング・システムはスクリーンに書き込むためにＧＤＩコールを使用する（ＷｉｎｄｏｗｓにおけるＧＤＩコールは上記特許出願におけるＯＳ／２用のＧＰＩコールと同じである）。現に、遠隔制御アプリケーションはこれらのＧＤＩコールを代行受信し、それらを使用してそのスクリーンのうちの更新されようとしている領域を決定する。そのコールはデバイス・ドライバに送られ、そのリクエストされた更新が遂行されるのを可能にし、一方、遠隔制御アプリケーションはその更新によって変更されるスクリーンのレコードを得る。現在の実施方法では、この領域は、ＥＰＡ−５９０８１７に示されるように、ほとんどのアプリケーションに対して非常に有効であることがわかっている境界矩形としていつも説明される（しかし、円又は多角形、凸面、或いは凹面のような更新領域のより複雑な説明を、それが望ましい場合には使用可能である）。更新領域を決定するための上記の技法の利点は、それがアプリケーション及びオペレーティング・システムに対して透明であり、従って、一般的な使用に適していることである。しかし、代わりの方法は、アプリケーション自体が更新領域を計算しそして遠隔制御アプリケーションにこの情報を直接に供給するためのものであるが、これが特別に適用されたアプリケーションを必要とすることは明らかである。端末Ａにおける更新処理が第５図に示される。更新が遠隔制御コマンドに応答して或いは単にＡＰＰ１自体によって発生された後（ステップ７１０）、それは端末Ｂへの伝送を待っている更新の待ち行列に加えられる（ステップ７１５）。肯定応答されるべき何らかの未決の更新伝送があるかどうかを表す「ＣＡＮ＿ＳＥＮＤ」フラッグのステータスを決定するためのテストが行われる（ステップ７２０）。「ＣＡＮ＿ＳＥＮＤ」フラッグがセットされている場合、伝送が行われる（下記参照）。それがセットされていない場合、プロセスは前の伝送からの肯定応答の受信を待たなければならない。そのような肯定応答の受信はステップ７３０として示され、現在、待ち行列において何らかの更新があるかどうかを決定するためのテスト（ステップ７３５）がこれに続く。更新がない場合、「ＣＡＮ＿ＳＥＮＤ」フラッグがセットされ（ステップ７４０）、それによって、何らかの将来の更新が発生される場合のその更新の伝送を可能にする。待ち行列からの実際の更新の伝送がステップ７５０乃至７８５において示され、その伝送が新しい更新の発生によって（即ち、ステップ７１０を介して）トリガされても、或いは肯定応答の受信によって（ステップ７３０）トリガされても本質的には同じである（注意：肯定応答の受信及び更新の発生は相互に関して非同期的に生じる）。待ち行列は２つのバッファに分けられ、それらの１つは、如何なる特定の時間においても「アクティブ」バッファとして指定される（当面の目的のために、もう１つのバッファは「送信」バッファと呼ばれる）。現在アクティブであるどちらのバッファにも新しい更新が加えられる（ステップ７１５）。伝送プロセスは、アクティブ・バッファを変更する（スワップする）ことによって開始し（ステップ７５０）、従って、前のアクティブバッファは送信バッファとなり、一方、他のバッファは、新しい更新が加えられるアクティブ・バッファとなる。又、「ＣＡＮ＿ＳＥＮＤ」フラッグは、伝送が進行中であることをことを表すためにリセット（アンセット）される（ステップ７６０）（注意：それは既にリセットされていることもある）。端末Ａから端末Ｂに更新を伝送するために如何に長い時間を要するかに関する所定の基準にその更新が合致するかどうかを決定するためのテストが送信バッファにおける各更新に対して行われる。比較的長い時間を必要としそうな更新に対して、初期メッセージ（「グレイリスト」メッセージ）が先ず端末Ｂに送られる（ステップ７８０）。グレイリスト・メッセージは、スクリーンのどの領域に更新が施されるかを単に表すだけである。上述のように、すべての更新がそれらの境界矩形によって処理され、従って、グレイリスト・メッセージは２つの座標（この実施例では、矩形の左上隅及び右下隅）を含む必要があるだけである。従って、グレイリスト・メッセージのサイズが実際の更新のサイズに無関係であることは明らかである。それはいつも非常に小さく、従って、速く伝送可能である。この実施例では、所定の基準に合致しない送信バッファにおけるすべての更新に対して境界矩形を含む単一のグレイリスト・メッセージが送られる。それは、これが多くの非常に小さいグレイリスト・メッセージを別々に送るよりも更に効率的であるためである（しかし、すべてのグレイリスト・メッセージを個々に送ることは確かに可能であろう）。たとえ、グレイリスト・メッセージが複数の更新に関連するとしても、それは依然として非常に小さいサイズであることに留意して欲しい。一旦、グレイリスト・メッセージが伝送されると（或いは、送るべきグレイリスト・メッセージがない場合、ステップ７７５のテストの直後に）、更新自体が端末Ｂに伝送可能である（ステップ７８５）。その更新を送るステップは、送信バッファからすべての更新を除去すること及びそれらを通信ソフトウエアに送ることを表す。それらは比較的速く行われる。そこで通信ソフトウエアは端末Ｂへのそれらの実際の伝送の責任を負う。グレイリスト・メッセージとは違って、送信バッファからの更新は送るために個々のメッセージに維持される（これは単純なＦＩＦＯに基づいて行うことができるが、それに関係なく、更新はグレイリスト・パケットに含まれている）。しかし、別の方法として、送信バッファにおけるすべての更新を集めて１つのメッセージにすることも考えられることである。待ち行列への更新の付加（ステップ７１５）がその更新によって変更された領域をその待ち行列における他のものに関してチェックすることを含むことは明らかであろう。他の更新の中に完全に含まれる更新は除去され、一方、重畳又は近接する更新は１つの更新によって置換される。実際に、この作用は送るべき更新の数をかなり減少させる。待ち行列に記憶された更新は更新されてしまったスクリーンの領域を単に表すだけであることも理解されよう。本実施例では、更新のための境界矩形の左上隅及び右下隅が記憶される。更新と関連する実際のスクリーン・データは、その更新が伝送の準備をされるまでは（Ｗｉｎｄｏｗｓオペレーティング・システムへのリクエストを介して）得られることはない。これは大量のデータを待ち行列に記憶する必要をなくし、しかも、待ち行列における更新の削除又はマージングをずっと簡単にする。特定の更新に対するグレイリスト・メッセージを送るべきかどうかに関する所定の基準は、更新の処理及び伝送に起因する遅延に関連する。本実施例では、更新の領域に基づくテストは非常に簡単である。例えば、２００ピクセルの閾値よりも大きい領域を有する更新は、すべて、その更新自体の伝送前にグレイリスト・メッセージを送られる。しかし、例えば、遂行されるべきすべてのデータ圧縮を考慮して、ずっと複雑なテストが使用可能である。考慮される他の局面はプロセッサ・ローディング（更新の任意のフォーマットの変換又は圧縮に必要な時間に影響する）、及びネットワーク帯域幅及び現在のネットワーク・トラフィック（伝送時間に影響する）を含んでいる。例えば、そのネットワークが比較的低い帯域幅を有する場合、上記の閾値を更に小さいピクセル数まで減少させることが望ましい。端末Ｂにおいて受信された更新メッセージの処理が第６図に示される。更新が端末Ｂに到達した（ステップ８１０）後、それがグレイリスト・メッセージである（即ち、更新されたスクリーン・データ自体ではなく、更新されるべき領域の指示だけを含む）か否かを知るためにそれは調べられる（ステップ８２０）。それが肯定される場合、更新された領域の範囲を表す情報が、その更新された領域を視覚的にマークするために、Ｗｉｎｄｏｗｓオペレーティング・システムに対するｐａｔＢｌｔコールによって利用される（ｐａｔＢｌｔは前述の Petzold 氏による文献に詳しく開示されている）。このコールは、スクリーンの指定された領域、即ち、更新されるべき遠隔制御ウインドウの領域をアプリケーション供給のパターンでもって満たす（ステップ８３０）（そのパターンは指定された領域を満たすために必要な回数だけ繰り返される）。本実施例では、そのパターンはグレイ・ドットの配列を含む。このオペレーションは非常に高速であり、その結果、指定された領域における選択されたピクセルがグレイ・ドットによって上書きされ、全体的な効果はその指定された領域のグレイ化（クロス・ハッチング）である。この方法では、ユーザは、スクリーンのグレイ化された領域がその更新されつつあるプロセスにあることを知らされる。なお、如何なる遅延も、主として、データを処理しそしてそれを遠隔の機械（端末Ａ）からローカルの機械（端末Ｂ）に伝送するために必要な時間による。ＰａｔＢｌｔコールのパラメータは、グレイ・ドットのパターンがオリジナルのスクリーン・データに重畳されるように指定される。この結果、そのオリジナルのデータは、依然として、それらのドットの間では実質的に可視的である。前述のように、グレイリスト・パケットは、実際に、幾つかの更新に関連した情報（座標のセット）を含むことができる。この場合、各更新に対して、ＰａｔＢｌｔコールが行われてその更新に対する適当な領域をグレイ・アウトする。一方、受信されたメッセージが実際の更新データを表す場合、肯定応答が端末Ａに戻される（ステップ８４０）。グレイリスト・メッセージに対しては、詳しく後述するように、肯定応答が要求されないので、肯定応答は送られないことに注意して欲しい。そこで、その更新はスクリーンへの適用に対して待ち行列化される（複数の更新が集められて１つのメッセージにされていた場合、ここでは、それらは待ち行列への挿入のために分解されるであろう。しかし、前述のように、本実施例では、更新は個々に送られる）。各更新がそれを端末における表示に適した形式に変換するためには、一定の量の処理が必要である（ステップ８５０）。従って、本実施例では、更新データは伝送端末においてデバイス独立ビット・マップ（ＤＩＢ）フォーマットに変換され、しかる後、受信端末において適当な表示フォーマットに戻される（しかし、ＤＩＢフォーマットを直接に表示することは、実際には可能であろう）。ＤＩＢフォーマットを使用する理由は、それが端末Ａ及びＢの間の如何なるハードウエア上の相異（例えば、サポートされるカラーの数に関する）も克服するということである。同様に、その更新を圧縮解除することも必要であろう（しかし、通信ソフトウエアは既にこれを行っているかもしれない）。本願では、実際の更新は、英国特許出願９４２２８５６．６号において開示された技法を使用してリモート端末とローカル端末との間の伝送のために圧縮される。しかし、他の多くのデータ圧縮アルゴリズムが適するであろう（状況によっては、如何なる圧縮も全く使用しない方が適当であるものもある）。一旦、更新が適当なフォーマットに変換されてしまうと、それは、ＢｉｔＢｌｔコマンド（前述の Petzold の文献において更に説明されているＷｉｎｄｏｗｓオペレーティング・システムにおけるもう１つの標準的コマンド）を使用してスクリーンに与えられる（ステップ８６０）。ＢｉｔＢｌｔオペレーションは単にそのコマンドをスクリーンの関連領域に上書きするだけなので、更新自体の到着前にその更新領域を表すために使用されるすべてのグレイ・パターンを明確に除去する必要はない。ＢｉｔＢｌｔオペレーション及びＰａｔＢｌｔオペレーションの両方とも、端末Ａの座標から端末Ｂのウインドウの座標に変換することが必要であるは明らかであろう。例えば、端末Ｂから端末Ａに遠隔制御アクションをレポートするためには、明らかに逆変換が必要である。実際に、これは非常に簡単である。それは、端末Ｂにおける遠隔制御ウインドウ（即ち、第４図におけるウインドウ６１０に対応する）が一般には左上隅にそれの起点を有し、これが端末Ａにおけるスクリーン座標と直接に対応するように作られているためである。前述の肯定応答の使用は、単に、端末Ｂが処理及び表示のために更新によって過負荷にならないようにするための制御機構として作用するだけである。換言すれば、肯定応答は、端末Ｂが前の更新の処理を終了したこと、従って、他の更新伝送を受容する準備ができていることを表すように、端末Ａにおいて「ＣＡＮ＿ＳＥＮＤ」フラッグを制御するために有効に使用される。しかし、第６図に示されるように、如何なるグレイリスト・メッセージに関しても肯定応答は発生されないことに注意してほしい。肯定応答は伝送端末のリクエスト時に発生される。グレイリスト・メッセージに対して、そのようなリクエストは行われない。これは、グレイリスト・メッセージが端末Ｂにおいて非常に速く処理され、従って、システムにおける大きな負荷を表さない。簡単な遠隔制御コマンドの例が第７図に示される。先ず、端末Ａにおけるアプリケーションが面９００を表示する（第７図のａ）。端末Ａは端末Ｂから遠隔制御されるので、同じ面のイメージが端末Ｂにおける遠隔制御ウインドウ９１０内にも表示される。（Ｗｉｎｄｏｗｓオペレーティング・システムは、ウインドウ９１０内に適合するように面イメージのサイズの縮小を処理する）。端末Ｂにおけるポイント９１５には、カーソル位置が表される。端末Ｂにおけるユーザがボタンのクリックのような何らかのマウス・アクションを行うものと仮定すると、前述のように、これは端末Ａに送り戻され、そして使用される。そのマウス・アクションの結果、端末Ａにおけるアプリケーションは、口の形を悲しい形から笑顔に変更するものと仮定する。その結果、端末Ａにおけるスクリーン・イメージは、第７図のｂに示されるように更新される。又、第７図のｂには、この更新に対する境界矩形９２０が示される（勿論、その境界矩形は、実際には、端末Ａにおけるスクリーン上には現れない）。この段階では、端末Ｂは更新されていない。端末Ａに対する更新の結果、前述のように、境界矩形のサイズが所定の閾値を超えるかどうか決定するためのテストがその境界矩形に関して行われ、この結果、先ず、端末Ａから端末Ｂへのグレイリスト・パケットの伝送が生じ、次に実際の更新データの伝送が生じるものと仮定する。第７図のｃの端末Ｂはグレイリスト・パケットの到着後で且つ更新データの到着前における状況を示す。境界矩形９２０に対応するウインドウ９１０の領域９２５はグレイ化されている（表示を容易にするために、第７図のｃでは影付きとして示される）。これは、端末Ｂにおけるユーザに、それらのアクションが受信されそして処理されつつあることを保証し、又、そのアクションが終了する前の遅延の可能性があるという粗い表示を与える。（影付き領域が大きければ大きいほど、送られるべき更新は大きくなり、その起こりそうな遅延は長くなる）。最後に、第７図のｄに示されるように、すべての更新が到着しそして端末Ｂにおけるスクリーンに与えられたので、端末Ｂにおける面９３０は再び端末Ａと同じになる。一般に、第７図のａと第７図のｃとの間のタイム・インターバルは比較的短く、それによってユーザへの速いフィードバックを与え、一方、第７図のｃと第７図のｄとの間のインターバルは、関連する更新の大きさ次第で極めて大きくなることがあることに留意して欲しい。例えば、一般的な環境では、更新自体が端末Ｂに与えられるためには、最初のコマンドから２秒を必要とし、一方、グレイ化は数分の一秒内に実行可能である。実際に、更新の発生は一般にクラスタ化されることがわかっているので、一般には、１つ又は複数のユーザ・アクションによって多数の更新が発生され、これの後に、ユーザが思案のために休止する時、ほとんど更新のない一時的休止が生じる。他の端末への更新の伝送は、それらの更新が速く発生される時には遅れることが多いが、その一時休止中に遅れを取り戻すことが可能である。受信端末はスクリーンの関連部分をグレイ・アウトするので、更新の範囲に関する情報は「グレイリスト」メッセージと呼ばれたけれども、実際には、スクリーンの関連部分の明瞭な視覚的表示を行うための他の任意の技法が使用可能である。例えば、或可能性は、更新されるべき領域を斜めの縞でもってマークすること、更新されるべき領域を高輝度フレームでもって囲むこと、或いは更新されるべき領域の背景カラーを変更することであろう。これらの提案はすべてスクリーンに描くのが速いこと、及び更新されたデータの到着まで、基礎となるスクリーン表示をユーザがそのまま（少なくとも部分的に）見ることができるという利点をすべてが保持していることに留意して欲しい。更に、そのマーキングが更新の領域内に含まれるので、それは、更新自体が到着する時、自動的に上書きされ、従って、そのマーキングを特別に削除する必要がない。上記のメッセージが、伝送遠隔制御アプリケーションから通信ソフトウエアに送られるメッセージを表すことは明らかである。ネットワーク特性、メッセージ・サイズ等次第で、通信ソフトウエアは、何れのメッセージも小さいコンポーネントに分割すること、又は伝送のためにそのメッセージを他のメッセージと結合して１つのパケットにすることを決定することが可能である。そこで、受信の通信ソフトウエアは、その受信したメッセージを受信遠隔制御アプリケーションに別々に送るために逆の動作を遂行する。従って、メッセージ伝送のために通信ソフトウエアによって選択されたフォーマットは遠隔制御アプリケーションにとって透明であり、本発明に直接関係するものではない。産業上の利用可能性理解を容易にするために２つの端末（「ポイント・ツー・ポイント」として知られている）に関して遠隔制御機能を説明したけれども、本実施例は、実際に、遠隔制御されたスクリーンを複数の他の端末（「マルチポイント」として知られている）から見ることを可能にする。ポイント・ツー・ポイントからマルチポイントへの拡張は、主として、グレイリスト・パケット及び更新をすべての関連端末に送る通信ソフトウエアによって行われる。更新の処理を制御するために使用される肯定応答（第５図参照）は、現在、更新を受信するために第１の端末からの肯定応答に基づいているが、それは、或環境では、更新を受信するために最後の端末からの肯定応答を待つ方がよいかもしれない。更に、本発明は、主として、遠隔制御機能に関連して説明されたけれども、例えば、１つの機械からの選択されたアプリケーション又はウインドウが単に他の端末において表示される（ミラーリングされる）べき場合のような他の多くの状況においても同様に適用可能である。

【手続補正書】【提出日】１９９７年６月１１日【補正内容】明細書コンピュータ・ワークステーション技術分野本発明は、第１コンピュータ・ワークステーションのスクリーンに対して行われた更新が第２コンピュータ・ワークステーションに伝送され、その更新のコピーが第２コンピュータ・ワークステーションのスクリーン上に表示されるシステムに関するものである。背景技術近年、コンピュータ・ワークステーション同士がデータを交換することを可能にするために、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）において、或いは、統合サービス・ディジタル・ネットワーク（ＩＳＤＮ）接続によってコンピュータ・ワークステーションをリンクすることが益々一般的になっている。これは、一般に、連携作業（ｃｏｌｌａｂｏｒａｔｉｖｅ−ｗｏｒｋｉｎｇ）とよく呼ばれるコンピュータ・テクノロジの新しい分野を生じさせた。連携作業の特定の例の２つがアプリケーション共用及び遠隔制御である。前者では、１つのアプリケーションが２つの機械において実行され、一方の機械においてそのアプリケーションになされた更新が他方の機械に伝送され、そして他方の機械においてミラーリングされる。国際特許出願ＷＯ９１／０９３７８及びヨーロッパ特許出願ＥＰＡ−５９０８１７はミラーリングの例を開示している。その例では、更新によって影響されるスクリーンの領域は、リモート・ノードに伝送される更新及び適当な位置情報によって決定される。明らかに、この技法は３つ以上の機械にも拡張可能である。遠隔制御では、一方の機械において実行中のアプリケーションが他方の機械においてユーザにより効果的に制御される。連携作業システムの例は、ヨーロッパ特許出願ＥＰＡ−４７５５８１及び国際特許出願ＷＯ８９／１２８５９において見ることができる。連携作業における１つの問題は、通信リンクを通してデータを伝送する必要があるために応答時間が遅いことがあるということである。これは、例えば、遠隔制御において、ローカルの機械のユーザがマウス・ボタンのクリックのような何らかのアクションを行うが、遠隔制御されている機械とコミュニケートするために必要な時間のために如何なる即時応答も得られない時、特に欲求不満を生じさせることがある。この遅れの間、ユーザは、自分のマウス・アクションがシステムによって受け入れられなかったと勘違いしてそのアクションを繰り返すことがある。しかし、これによって、最終的には、当初の意図に反してそのアクションが２回行われるという結果になるであろう。機械がデータを処理しようとしているという何らかの表示を行うことは、勿論、通常の独立型ワークステーションにおいては知られている。例えば、ＩＢＭ社から入手可能なＯＳ／２オペレーティング・システムでは、システムが現在リクエストされたアクションを実行していることを表すために、カーソルが時計の形に変化する。別の方法として、リクエストされたアクションが進行中であることを記述したテキスト・メッセージを表示することも可能である。所定のＨＴＭＬフォーマットを持った情報ページを与える情報を、クライアントの端末が遠隔のサーバから検索することもワールド・ワイド・ウェブに関連して知られている。或ページが、そのページに含まれるべきイメージを表す別のグラフィックス・ファイルの引用を含むことも可能である。クライアントがそのようなページを検索する時、クライアントは、そのイメージを検索するためにはそのグラフィックス・ファイルをアクセスすべきであることを知る。クライアントは、イメージを位置付けるべきスクリーンの特定の領域を決定することができるように、先ず、イメージ自体よりも前にそのイメージに対するヘッダ情報を与えるようにサーバにリクエストすることができる。一旦そのイメージ・データ自体が検索されてしまうと、そのイメージが満たすべきボックス又は領域をそのままにして、クライアントはそのページに対するテキストをスクリーンに書くことができる。この方法はクライアント及びサーバの明確なサポートを必要とし、基本的にはクライアント（即ち、受信）端末によって駆動される。それは連携作業環境に直接に適用し得るものではない。 Computer Practices，Communications of the ACM 誌の Vol.30，No.1，Jan． 1987 の pp.32-47 における M.Stefik，G.Foster，D.Bobrow，K.Kahn，S.Lannin g 及び L.Suchman 氏による「黒板を越えて：会議における連携及び問題解決のためのコンピュータ・サポート(Beyond the Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings)」と題した論文は連携作業システム（しかし、それは遠隔制御を述べてはいない）を開示している。２人以上のユーザが共用オブジェクトを同時に編集しようとする問題を克服するために、一方のユーザが現在作業している項目はグレイ・アウト（ｇｒｅｙｏｕｔ）される。この方法は、特別に適応されたアプリケーション（例えば、どの項目が編集されようとしているかを監視するための）を必要とする。しかし、更に最近の連携作業システムに対する重要な目的は、それらが既存の（独立した）アプリケーション（例えば、遠隔制御を行うための）を働かせることができなければならないことである。発明の開示従って、本発明は、ディスプレイ・スクリーンを有し、リモート・ワークステーション（２００）にリンクされたコンピュータ・ワークステーション（１００）を操作する方法を提供するものであり、その方法は、前記ワークステーションのスクリーンに対する更新を発生するステップと、前記ワークステーションのスクリーンの更新されようとしている領域を決定するステップと、前記更新されようとしている領域の指示を前記リモート・ワークステーションに伝送するステップと、前記更新されようとしている領域の指示の前記伝送の後に、前記更新を表すデータを前記リモート・ワークステーションに別に伝送するステップと、を含んでいる。請求の範囲１．ディスプレイ・スクリーンを有し、リモート・ワークステーション（２００）にリンクされたコンピュータ・ワークステーション（１００）を操作する方法であって、前記コンピュータ・ワークステーションのスクリーンに対する更新を発生するステップと、前記コンピュータ・ワークステーションのスクリーンにおける更新されようとしている領域を決定するステップと、前記更新されようとしている領域の指示を前記リモート・ワークステーションに伝送するステップと、前記更新されようとしている領域の指示の前記伝送の後に、前記更新を表すデータを前記リモート・ワークステーションに別に伝送するステップと、を含む方法。２．前記更新を所定の基準と比較するステップを含み、それによって、そのような基準と合致した場合、前記更新は更新された領域を表す指示を事前伝送することなく直接に伝送されることを特徴とする請求の範囲第１項に記載の方法。３．前記所定の基準は前記更新された領域のサイズに関連することを特徴とする請求の範囲第２項に記載の方法。４．各更新はそれの境界矩形によって処理されることを特徴とする請求の範囲第１項乃至第３項の１つに記載の方法。５．複数の更新に対する更新された領域の指示が１つのメッセージで伝送されることを特徴とする請求の範囲第１項乃至第４項の１つに記載の方法。６．先ず前記リモート・ワークステーションからコマンドを受信するステップ（５３０）、及び前記コマンドを前記コンピュータ・ワークステーションにおいて実行して前記更新を発生するステップ（５４０）を含むことを特徴とする請求の範囲第１項乃至第５項の１つに記載の方法。７．ディスプレイ・スクリーンを有し、リモート・ワークステーション（２００）にリンクされたコンピュータ・ワークステーション（１００）であって、前記コンピュータ・ワークステーションのディスプレイ・スクリーンに対する更新を発生するための手段と、前記コンピュータ・ワークステーションのディスプレイ・スクリーンの更新されようとしている領域を決定するための手段と、前記更新されようとしている領域の指示を前記リモート・ワークステーションに伝送するための手段と、前記更新されようとしている領域の指示の前記伝送の後に、前記更新を表すデータを前記リモート・ワークステーションに別に伝送するための手段と、を含むコンピュータ・ワークステーション。８．リモート・ワークステーション（２００）にリンクされたコンピュータ・ワークステーション（１００）を操作する方法であって、前記コンピュータ・ワークステーションのスクリーンの少なくとも一部分が前記リモート・ワークステーションのスクリーンの少なくとも一部分に対応するように配列されているものにおいて、更新が施されようとしている前記リモート・ワークステーションのスクリーンの領域を表す第１メッセージを前記リモート・ワークステーションから受信するステップと、前記更新が施されようとしている前記リモート・ワークステーションの部分に対応する前記コンピュータ・ワークステーションのスクリーンの領域を視覚的に指示するステップと、前記リモート・ワークステーションに対して行われた更新を含む第２メッセージを前記リモート・ワークステーションから受信するステップと、前記コンピュータ・ワークステーションにおいて前記更新を前記スクリーンの前記指示された領域に施すステップと、を含む方法。９．前記領域を視覚的に指示するステップは当該領域におけるオリジナルのイメージが実質的に可視的なままであることを妨げないことを特徴とする請求の範囲第８項に記載の方法。１０．前記領域を視覚的に指示するステップは、関連する領域をグレイ・アウトすることを含むことを特徴とする請求の範囲第８項又は第９項に記載の方法。１１．前記領域を視覚的に指示するステップは、背景カラーを反転すること又は関連する領域を縞模様にすることを含むことを特徴とする請求の範囲第８項又は第９項に記載の方法。１２．各更新はそれの境界矩形によって処理されることを特徴とする請求の範囲第８項乃至第１１項の１つに記載の方法。１３．先ず前記リモート・ワークステーションにコマンドを送るステップ（４４０）を含み、それによって、前記更新が前記コマンドに応答して前記リモート・ワークステーションにおいて施されることを特徴とする請求の範囲第８項乃至第１２項の１つに記載の方法。１４．リモート・ワークステーション（２００）にリンクされたコンピュータ・ワークステーション（１００）であって、前記コンピュータ・ワークステーションのスクリーンの少なくとも一部分が前記リモート・ワークステーションのスクリーンの少なくとも一部分に対応するように配列されているものにおいて、更新が施されようとしている前記リモート・ワークステーションのスクリーンの領域を表す第１メッセージを前記リモート・ワークステーションから受信するための手段と、前記更新が施されようとしている前記リモート・ワークステーションの部分に対応する前記コンピュータ・ワークステーションのスクリーンの領域を視覚的に指示するための手段と、前記リモート・ワークステーションに対して行われた更新を含む第２メッセージを前記リモート・ワークステーションから受信するための手段と、前記コンピュータ・ワークステーションにおける前記更新を、前記指示された前記スクリーンの領域に施すための手段と、を含むコンピュータ・ワークステーション。１５．リモート・ワークステーション（２００）からのディスプレイ・スクリーンの少なくとも一部分をローカル・ワークステーション（１００）のディスプレイ・スクリーン上にミラーリングし、それによって、前記リモート・ワークステーションのスクリーンに施された更新が前記ローカル・ワークステーションに対応して施される方法であって、前記リモート・ワークステーションのスクリーンに更新を施すステップと、前記リモート・ワークステーションの更新されようとしている領域を決定するステップと、前記更新されようとしている領域の指示を前記リモート・ワークステーションから前記ローカル・ワークステーションに伝送するステップと、前記指示を前記ローカル・ワークステーションにおいて受信するステップと、前記更新が施された前記リモート・ワークステーションの指示された領域に対応する前記ローカル・ワークステーションの領域を視覚的に指示するステップと、前記スクリーンに施された更新を表すデータを前記リモート・ワークステーションから前記ローカル・ワークステーションに別に伝送するステップと、前記更新を前記ローカル・ワークステーションにおいて受信するステップと、前記更新を前記ローカル・ワークステーションにおけるスクリーンの前記指示された領域に施すステップと、を含む方法。１６．前記更新を前記リモート・ワークステーションにおける所定の基準と比較するステップ（７７５）を含み、それによって、そのような基準が合致する場合、前記更新された領域の指示を事前伝送することなく前記更新が直接に伝送され、及びそのような基準が合致しない場合、前記更新された領域の指示が前記更新を表すデータの電送前に伝送されることを特徴とする請求の範囲第１５項に記載の方法。１７．前記所定の基準は前記更新された領域のサイズに関連することを特徴とする請求の範囲第１６項に記載の方法。１８．各更新はそれの境界矩形によって処理されることを特徴とする請求の範囲第１５項乃至第１７項の１つに記載の方法。１９．前記領域を視覚的に指示するステップは当該領域におけるオリジナルのイメージが実質的に可視的なまま残ることを妨げないことを特徴とする請求の範囲第１５項乃至第１８項の１つに記載の方法。２０．前記領域を視覚的に指示するステップは、関連の領域をグレイ・アウトすることを含むことを特徴とする請求の範囲第１５項乃至第１９項の１つに記載の方法。２１．前記領域を視覚的に指示するステップは、背景カラーを反転すること又は関連領域を縞模様にすることを含むことを特徴とする請求の範囲第１５項乃至第１９項の１つに記載の方法。２２．先ず前記ローカル・ワークステーションから前記リモート・ワークステーションにコマンドを送るステップを含み、それによって、前記更新が前記コマンドに応答して前記リモート・ワークステーションにおいて施されることを特徴とする請求の範囲第１５項乃至第２１項の１つに記載の方法。

───────────────────────────────────────────────────── フロントページの続き (72)発明者グラッドウィン、ベネデイクト、ダニエルイギリス国ハンツ、ウインチェスター、リットルトン、デイーン・ダウン・ドローブチェストナッツ（番地なし)

Claims

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