JP2007503624A - 表示データ・マッピングの方法、システム、およびプログラム - Google Patents

Abstract

【課題】 表示データ・マッピングの方法、システム、およびプログラムを提供することにある。
【解決手段】 少なくとも１つのウィンドウ（６４Ａ〜６４Ｈ）を含む表示域（６０）に関する表示データが共用フォーマットにマッピングされる方法が提供される。表示域内の各ウィンドウに関する属性情報が決定され、各ウィンドウごとに作成された固有のノード（６６Ａ〜６６Ｈ）に保管される（Ｓ２）。属性情報を使用してノード階層（６２）が生成される（Ｓ３）。ノード内の属性情報を使用して、表示データが共用フォーマットにマッピングされる（Ｓ７）。その後、マッピングされた表示データは、１つまたは複数の他のシステムと共用することができる。
【選択図】 図３

Description

本発明は、一般に、表示データをマッピングすることに関し、詳細には、１つまたは複数のフォーマットから１つの共用フォーマットに表示データをマッピングすることに関する。

個人間のコラボレーションは多くの形を呈し、対面、電話、および電子メールは最もユビキタスなものの一部である。技術が進歩するにつれて、個人は、ビデオ、音声、ホワイトボード・マークアップ、チャット、ならびにコンピュータ・アプリケーションを共用することにより、さらにコラボレーションしようと努めてきた。このような共用を可能にする２つの一般的なコラボレーション・ソフトウェア・プログラム（software product）は、Ｌｏｔｕｓ ＳＡＭＥＴＩＭＥ（商標）およびＭｉｃｒｏｓｏｆｔ ＮＥＴＭＥＥＴＩＮＧ（商標）である。多くの現行コラボレーション・ソフトウェア・プログラムの問題の１つは、そのプラットフォーム依存関係である。たとえば、Ｍｉｃｒｏｓｏｆｔ ＮＥＴＭＥＥＴＩＮＧ（商標）は、Ｍｉｃｒｏｓｏｆｔ ＷＩＮＤＯＷＳ（商標）オペレーティング・システムのあるバージョンを使用するシステム上でのみ機能する。異なるプラットフォームは異なる方法で表示データを管理する。これは、プラットフォーム間で使用できるコラボレーション・プログラム（collaborationproduct）の作成に対する重大な障害を提起する。

たとえば、表示データは、表示内の各ピクセルに関するピクセル・データを含む。ピクセル・データは、ピクセルの位置、ピクセルのカラー、およびピクセルの深さに関する情報を含む。ピクセル・データ内のカラー情報を表すために様々なフォーマットが使用される。その結果として、プラットフォーム間の表示データの共用を実現するために、ピクセル・データを共用フォーマットに変換することができる。しかし、いくつかの要因により、多くの実現例はピクセル・データを共用フォーマットに効率よく変換することができない。１つの要因は、変換すべき表示域内の各ピクセルを「所有」するウィンドウを決定する必要があることである。ウィンドウは、ピクセルに関するピクセル・データを提供するときにそのピクセルを所有する。

典型的なウィンドウ表示環境では、ウィンドウは階層関係を有することができる。たとえば、その表示スペース内に１つまたは複数の子ウィンドウを含む親ウィンドウを作成することができる。子ウィンドウもそれ自体の１つまたは複数の子ウィンドウを有することができる。各ウィンドウは任意の祖先ウィンドウ（ancestor window）（すなわち、親ウィンドウ、祖父母ウィンドウ（grandparent window）など）の表示スペースの一部分を占有する。兄弟ウィンドウは、同じ親ウィンドウを共用するかまたは親ウィンドウを一切持たない（すなわち、デスクトップ上に表示される）。兄弟ウィンドウにはスタック順序が割り当てられる。スタック順序は、兄弟ウィンドウが描画される順序を決定し、その結果、２つの兄弟ウィンドウに関する表示域がオーバラップするときにどちらの兄弟ウィンドウが「上に」あるかを決定する。ウィンドウのサイズ、スタック順序、および数は頻繁にユーザによって変更される。たとえば、親ウィンドウは、表示域全体を占めるように「最大化」される可能性がある。さらに、ユーザは、部分的に兄弟ウィンドウの後ろにあるウィンドウを選択することができ、その結果、選択されたウィンドウは兄弟ウィンドウの上に示される。

たとえば、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍでは、各ウィンドウごとに異なる方法でピクセル・データをフォーマットすることができるので、このシステムではピクセル所有権を決定することは重要なことである。Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍは、表示を変更するためのコマンドを含む処理を「Ｘクライアント」（アプリケーション）が実行するクライアント／サーバ・ウィンドウ・システムである。これらのコマンドは、表示変更を実現する（すなわち、ユーザに画像を「供する」）「Ｘサーバ」に提供される。Ｘサーバはその表示を備えたコンピュータ上に常駐し、Ｘクライアントは、その表示を備えたコンピュータを含むコンピュータ・ネットワーク内の任意のコンピュータ上に常駐することができる。

典型的な表示フォーマットは、「深さ」、すなわち、各ピクセルに関するピクセル・データに使用されるビット数と、「ビジュアル（visual）」、すなわち、ピクセル・データをどのように解釈するかによって変化する。深さは、ウィンドウ内のピクセルについて一度に表示できるカラーの数を決定する。たとえば、８ビットの深さを有するピクセル・データは、最高２５６（２⁸）色のカラーを同時に表示できるようにする。一般に、ビジュアルは、カラー値を含むものとしてピクセル・データを解釈すべきか、またはカラー値を含むカラー・テーブル（複数も可）に対する１つまたは複数の指標を含むものとしてピクセル・データを解釈すべきかを決定する。Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍ環境には６通りの標準タイプのビジュアルが存在し、ＴｒｕｅＣｏｌｏｒピクセル・データはピクセル・データ内にエンコードされた赤／緑／青（ＲＧＢ）カラー値を含み、ＳｔａｔｉｃＣｏｌｏｒおよびＳｔａｔｉｃＧｒａｙピクセル・データは不変のカラー値を含むカラー・テーブルに対する指標を含み、ＤｉｒｅｃｔＣｏｌｏｒピクセル・データは３つの個別の変更可能カラー・テーブル内のＲＧＢカラー値をルックアップするための３つの個別の指標値を含み、ＧｒａｙＳｃａｌｅおよびＰｓｅｕｄｏＣｏｌｏｒピクセル・データはカラー値を含む変更可能カラー・テーブルに対する指標を有する。最後の３通りのビジュアルにより、１つまたは複数のカラー・テーブル内の値を変更することができ、それにより、特定の値について表示される実際のカラーを可変のものにすることができる。２４ビットのＴｒｕｅＣｏｌｏｒフォーマットは、表示データに一般に使用されるフォーマットである。このフォーマットでは、各カラー（すなわち、赤、緑、および青）に関する実際の値は２４ビットの値のうちの固有の８ビット部分によって表される。多くのシステムおよびアプリケーションはこのフォーマットをサポートするように構成されている。たとえば、サン・マイクロシステムズ社によって開発されたＪＡＶＡ（商標）プログラミング言語は、２４ビットのＴｒｕｅＣｏｌｏｒフォーマットをサポートするものであり、多数のシステムおよびプラットフォーム上に実現されている。

表示の一領域が変更された時期を決定することは、表示データを効率よく変換することを妨げるもう１つの要因である。たとえば、Ｘサーバは、アプリケーションにユーザ開始イベントを通知するための表示ベースのイベント・ストリームおよび照会メカニズムを提供し、それにより、アプリケーションがユーザと対話できるようにする。アプリケーションは、どのイベントに関する通知を所望するかを指定し、そのイベントに基づいて適切なアクションを実行することができる。一般的なイベントとしては、ウィンドウの作成／破壊、ウィンドウのサイズ変更、ウィンドウのスタック順序の変更などを含む。しかし、Ｘサーバは、表示の一領域が変更された時期をシグナル通知するイベントを提供しない。その結果として、他のシステムと表示域を共用するためには、表示域全体に関する表示データを絶えずコピーしモニターしなければならない。

Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍ内で表示データを共用することを含むアプリケーション共用を実現するために、いくつかの手法が提供されている。たとえば、個別のビューア・プログラムを実行することができる。この手法は、ＡＴ＆Ｔ Ｌａｂｏｒａｔｏｒｉｅｓによって提供された仮想ネットワーク・コンピューティング（ＶＮＣ：Virtual Network Computing）ソリューションで使用される。代わって、複数のＸクライアントとＸサーバとの間の通信を多重化することができる。この手法は、ブラウン大学によって開発されたＸＭＸソリューションで使用される。しかし、これらの手法はいずれも、アプリケーションを共用するために、Ｘサーバ内でアプリケーションを始動することを必要とする。これは、アプリケーションが起動される前にそのアプリケーションを共用するかまたはリモート側でそのアプリケーションにアクセスしたいという要求をユーザが認識する必要があることを意味する。この制限は、アプリケーションを容易に再始動できないときに生産性を低下させる可能性がある。アプリケーション共用のためのもう１つの手法は、Ｘサーバに機能拡張を追加することである。しかし、拡張機能を使用することは、この手法を容易に実現できるプラットフォームの数を著しく制限する。各ピクセルをカテゴリ化しマッピングすることは、共用表示域内の様々なウィンドウが異なる表示フォーマットを使用して表示データを表す可能性があるときに、外部機能（すなわち、プロキシなし、標準のＸ１１プロトコル）を使用して表示データを共用しようと努めるＸ Ｗｉｎｄｏｗベースの共用手法に関するもう１つのパフォーマンス上の問題である。種々の表示フォーマットの使用に対処しようと試みる外部手法は、ウィンドウの階層関係を利用する、ピクセル・データをマッピングするための効率の良いソリューションを提供することができない。

その結果、複数のウィンドウが存在し、表示データを表すために２つ以上の表示フォーマットが使用される表示域に関する表示データを効率よくマッピングするための方法が必要である。

本発明は、表示データ・マッピングの方法、システム、およびプログラムを提供する。マッピングされる表示域に関連する様々なウィンドウおよびそのそれぞれの属性情報を表すノード階層が生成される。表示域に関する表示データが入手され、ノード階層を使用して効率よくマッピングされる。マッピングされた表示データは、たとえば、複数のシステムのユーザ間のコラボレーションを実現するために使用することができる。たとえば、Ｘ Ｗｉｎｄｏｗアプリケーションは、そのアプリケーションが実行される場所またはＸサーバ・ソフトウェアを変更する必要なしに共用することができる。さらに、本発明により、システムは種々のタイプのシステム（すなわち、Ｘ ＷｉｎｄｏｗおよびＭｉｃｒｏｓｏｆｔ ＷＩＮＤＯＷＳ（商標））と表示データを共用することができる。

本発明の第１の態様は、少なくとも１つのウィンドウを含む表示域に関する表示データをマッピングする方法を提供し、この方法は、各ウィンドウごとにノードを作成するステップであって、各ノードが階層関係データを含むステップと、階層関係データに基づいてノード階層を生成するステップと、ノード階層を使用して第１のフォーマットから共用フォーマットに表示データをマッピングするステップとを有する。

本発明の第２の態様は、少なくとも１つのウィンドウを含む共用表示域に関する表示データを共用するためのシステムを提供し、このシステムは、各ウィンドウごとにノードを作成するための手段と、各ノードを含むノード階層を管理するための手段と、ノード階層を使用して表示データを共用フォーマットにマッピングするための手段と、マッピングされた表示データを宛先コンピュータと共用するための手段とを有する。

本発明の第３の態様は、少なくとも１つのウィンドウを含む共用表示域に関する表示データをマッピングするためのシステムを提供し、このシステムは、各ウィンドウごとにノードを作成するための手段と、各ノードを含むノード階層を管理するための手段と、ノード階層を使用して表示データを共用フォーマットにマッピングするための手段とを有する。

本発明の第４の態様は、少なくとも１つのウィンドウを含む表示域に関する表示データをマッピングするためにそこに実施されたコンピュータ可読プログラム・コードを有するコンピュータ使用可能媒体を有するコンピュータ・プログラムを提供し、このプログラムは、各ウィンドウごとにノードを作成するように構成されたプログラム・コードであって、そのノードが属性情報を含むプログラム・コードと、各ノードを含むノード階層を管理するように構成されたプログラム・コードと、ノード階層を使用して表示データを共用フォーマットにマッピングするように構成されたプログラム・コードとを有する。

本発明の第５の態様は、方法を実行するための命令がそこに保管されたコンピュータ可読記憶媒体を提供し、この方法は、各ウィンドウごとにノードを作成するステップであって、各ノードが階層関係データを含むステップと、階層関係データに基づいてノード階層を生成するステップと、ノード階層を使用して第１のフォーマットから共用フォーマットに表示データをマッピングするステップとを有する。

本発明の例示的な諸態様は、本明細書に記載された問題および論じていない他の問題であって当業者によって発見可能な問題を解決するように設計されている。

本発明の上記その他の特徴は、添付図面に併せて取り上げた本発明の様々な態様に関する以下の詳細な説明から、より容易に理解されるであろう。

本発明の図面は一定の縮尺ではないことは留意されることである。図面は、本発明の典型的な諸態様のみを描写するためのものであり、したがって、本発明の範囲を制限するものと見なしてはならない。図面では、同様の番号は図面間で同様の要素を表している。

本発明は、表示データ・マッピングの方法、システム、およびプログラムを提供する。マッピングされる表示域に関連する様々なウィンドウおよびそのそれぞれの属性情報を表すノード階層が生成される。表示域に関する表示データが入手され、ノード階層を使用して効率よくマッピングされる。マッピングされた表示データは、たとえば、コラボレーション・システムの一部として複数のシステムのユーザ間で表示データを共用できるようにするために使用することができる。以下の説明ではコラボレーション・システムの一部として実現された本発明を記載しているが、そのコラボレーション・システムは本発明を実現できる様々なシステムの例証に過ぎないことは言うまでもない。

便宜上のためにのみ、以下の説明は、Ｉ．環境、ＩＩ．コラボレーション・システムの概要、およびＩＩＩ．マッピング方法という見出しによって示される３つの項を含む。

Ｉ．環境
図１は、例示的な表示域６０を示している。表示域６０は、現在知られているかまたは今後開発される任意の方法を使用して定義することができる。たとえば、表示域６０は、アプリケーションによるか、１つまたは複数のウィンドウによって定義された領域によるか、ディスプレイ（すなわち、モニターの画面区域）の表示域の一部分または全部を有する領域によるか、ディスプレイの複数の排反領域（disjoint area）によるか、またはこれらの組合せにより定義することができる。

表示域６０内のウィンドウ６４Ａ〜６４Ｈは、互いに関連する可能性もあれば、互いに一切関係を持たない可能性もある。たとえば、各ウィンドウ６４Ａ〜６４Ｈは、固有のアプリケーションに関するデータを表示することができ、したがって、任意の他のウィンドウ６４Ａ〜６４Ｈとの関係を一切持つことができない。代わって、ウィンドウ６４Ａ〜６４Ｈのうちの一部または全部は互いに階層関係を持つこともできる。ウィンドウ階層では、一方のウィンドウの表示域に限定されたウィンドウは、もう一方の「親ウィンドウ」の「子ウィンドウ」である。ウィンドウ階層は任意の数のレベルを有することができ、その結果、「孫ウィンドウ」は「祖父母ウィンドウ」を有し、「曾孫ウィンドウ（great-grandchild window）」は「曾祖父母ウィンドウ（great-grandparent window）」を有することになる。同じ親ウィンドウを共用するかまたは親ウィンドウを一切持たない（すなわち、デスクトップ上に表示される）ウィンドウは「兄弟ウィンドウ」である。ウィンドウ６４Ａ〜６４Ｈ間の関係はアプリケーションの視点から論じられることは言うまでもない。その結果、ウィンドウをレンダリングする際にオペレーティング・システムによって行われる可能性のある階層に対する任意の変更または修正については、この考察では扱わない。たとえば、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍでは、ウィンドウ・マネージャは、ウィンドウのサイズ変更、移動などを可能にするウィンドウ・マネージャ装飾を提供して、最上位アプリケーション・ウィンドウの親変更（reparent）を行うことができる。

説明のため、他のウィンドウ６４Ａ〜６４Ｈ内に完全に表示される任意のウィンドウ６４Ａ〜６４Ｈはそのウィンドウの子または孫であると想定する。その結果、ウィンドウ６４Ｂ〜６４Ｄはウィンドウ６４Ａの子ウィンドウであり、ウィンドウ６４Ｅ〜６４Ｇはウィンドウ６４Ｂの子ウィンドウであってウィンドウ６４Ａの孫であり、ウィンドウ６４Ｈはウィンドウ６４Ｄの子ウィンドウであってウィンドウ６４Ａの孫である。その結果として、ウィンドウ６４Ａ、ウィンドウ６４Ｂ〜６４Ｄ、ウィンドウ６４Ｅ〜６４Ｇ、およびウィンドウ６４Ｈは、４組の別個の兄弟ウィンドウを構成する。ウィンドウ６４Ａ〜６４Ｈ間では多数の他の関係が可能であり、本発明の教示はこのような他の関係に等しく適用されることは言うまでもない。

ウィンドウ６４Ａ〜６４Ｈのオーバラップ領域がどのように表示されるかを決定するために、ウィンドウ６４Ａ〜６４Ｈにスタック順序が割り当てられる。スタック順序は、ウィンドウの階層関係によって部分的に決定される。たとえば、子ウィンドウは親ウィンドウの上に表示される。その結果として、ウィンドウ６４Ｂ〜６４Ｄはいずれも、それらの親ウィンドウ６４Ａの上に表示される。１組の兄弟ウィンドウ内では、スタック順序は、ウィンドウが作成された順序、ユーザによって選択された順序、更新された順序などの順序によってさらに決定される。図示の通り、その１組の兄弟ウィンドウ６４Ｂ〜６４Ｄ内では、ウィンドウ６４Ｂは、ウィンドウ６４Ｄの上に表示されるウィンドウ６４Ｃの上に表示される。その結果として、ウィンドウ６４Ｂはその１組の兄弟ウィンドウに関するスタック順序の最上位にあり、次にウィンドウ６４Ｃが続き、さらにウィンドウ６４Ｄが続く。同様に、１組の兄弟ウィンドウ６４Ｅ〜６４Ｇ内では、ウィンドウ６４Ｅはスタック順序の最上位にあり、次にウィンドウ６４Ｆが続き、さらにウィンドウ６４Ｇが続く。

ＩＩ．コラボレーション・システムの概要
前に論じた通り、表示データのマッピングは一般に、表示データを共用できるようにコラボレーション・システムの一部として実現される。図２は、複数のコンピュータ１２、１６を使用してコラボレーションするための例示的なシステム１０のブロック図を示している。システム１０は、ソース・ディスプレイ１４を有するソース・コンピュータ１２と、宛先ディスプレイ１８を有する宛先コンピュータ１６とを含む。２つのコンピュータ１２、１６についてのみ図示し論じるが、本発明の教示は任意の数のコンピュータを使用して実現されたコラボレーション・システムに適用されることは言うまでもない。概して、ユーザ２０は、ソース・ディスプレイ１４を含む１つまたは複数の入出力装置を使用してソース・コンピュータ１２と対話する。ソース・コンピュータ１２は、ソース・ディスプレイ１４上のウィンドウ２２Ａ〜２２Ｄ内に１つまたは複数のアプリケーションに関するデータを表示するウィンドウベースの表示システムを含むことができる。さらに、ソース・コンピュータ１２あるいは宛先コンピュータ１６またはその両方は、ソース・ディスプレイ１４に関する表示データを宛先ディスプレイ１８と共用するための１つまたは複数のシステムを含む。

ソース・ディスプレイ１４は表示域２３を含む。共用表示域２５は、たとえば、ソース・コンピュータ１２上で実行されるアプリケーションにより、ソース・ディスプレイ１４上に表示される１つまたは複数のウィンドウ２２Ａ〜２２Ｄ、あるいはソース・ディスプレイ１４の表示域２５の一部分または全部を有する領域、またはこれらの組合せを含み、任意の方法を使用して表示域２３内に定義することができる。この例では、共用表示域２５は、ウィンドウ２２Ａ〜２２Ｃを有する表示域２３の一部分として定義される。共用表示域２５は、宛先表示域１２５として宛先ディスプレイ１８上に表示するために宛先コンピュータ１６と共用される。ウィンドウ２２Ｄは宛先コンピュータ１６と共用されない。ユーザ２４は、ウィンドウ１２２Ａ〜１２２Ｃとして宛先ディスプレイ１８上で宛先表示域１２５を見ることができる。また、ユーザ２４は、その後、宛先表示域１２５内に表示される共用表示域２５に関する表示データを変更するために宛先コンピュータ１６と対話できるようにすることができる。

図３は、システム１０のより詳細なブロック図を示している。ソース・コンピュータ１２は、中央演算処理装置（ＣＰＵ）３０と、メモリ３２と、入出力（Ｉ／Ｏ）インターフェース３４と、バス３６と、任意選択のデータベース３８とを含むものとして示されている。宛先コンピュータ１６は、ソース・コンピュータ１２と通信状態にあるものとして示されている。ソース・コンピュータ１２と宛先コンピュータ１６との通信は、このような目的のために現在知られているかまたは今後開発される任意のもの、たとえば、１つまたは複数の直接ハードワイヤード接続（たとえば、シリアル・ポート）または有線伝送方法あるいは無線伝送方法またはその両方の任意の組合せを使用できるクライアント／サーバ（またはサーバ／サーバ）環境においてアドレス可能接続を介するものにすることができる。クライアント／サーバ環境では、サーバおよびクライアントは、インターネット、広域ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、仮想プライベート・ネットワーク（ＶＰＮ）、またはその他のプライベート・ネットワークを介して接続することができる。サーバおよびクライアントは、トークンリング、イーサネット、ＷｉＦｉ、またはその他の従来の通信規格などの従来のネットワーク接続を使用することができる。クライアントがインターネットを介してサーバと通信する場合、従来のＴＣＰ／ＩＰソケットベースのプロトコルにより接続を提供することができるであろう。この事例では、クライアントは、サーバへの接続を確立するためにインターネット・サービス・プロバイダを使用することになるであろう。

ソース・コンピュータ１２および宛先コンピュータ１６は、標準のオペレーティング・システム・ソフトウェアを使用する任意の汎用または特定用途システムを有することができ、そのソフトウェアは、特定のハードウェアの動作を駆動するように設計され、他のシステム・コンポーネントおよび入出力コントローラと互換性のあるものである。ＣＰＵ３０は、単一処理装置または並列動作が可能な複数処理装置を有する場合もあれば、１つまたは複数の位置で、たとえば、クライアントおよびサーバ上で、１つまたは複数の処理装置間に分散される場合もある。メモリ３２は、磁気媒体、光メディア、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、データ・キャッシュ、データ・オブジェクトなどを含む、任意の既知のタイプのデータ・ストレージあるいは伝送媒体またはその両方を有することができる。その上、ＣＰＵ３０と同様に、メモリ３２は、１つまたは複数のタイプのデータ・ストレージを有する単一物理位置に存在する場合もあれば、様々な形の複数の物理システム間に分散される場合もある。

図示の通り、ユーザ２０、ソース・ディスプレイ１４、および宛先コンピュータ１６は、入出力インターフェース３４を介してソース・コンピュータ１２と対話する。入出力インターフェース３４は、たとえば、入出力ポート（シリアル、パラレル、イーサネット、キーボード、マウスなど）、ユニバーサル・シリアル・バス（ＵＳＢ）ポート、拡張バス、インテグレーテッド・ドライブ・エレクトロニクス（ＩＤＥ）、ネットワーク・システム、モデム、スピーカ、モニター（陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）など）、ハンドヘルド・デバイス、キーボード、マウス、音声認識システム、音声出力システム、スキャナ、プリンタ、ファクシミリ、ページャ、ストレージ・デバイスなどを含む、ユーザ２０、ソース・ディスプレイ１４、あるいは宛先コンピュータ１６、またはこれらの組合せと情報を交換するための任意のシステムを有することができる。バス３６は、ソース・コンピュータ１２内のそれぞれのコンポーネント間の通信リンクを提供し、同様に、電気、光、無線などを含む、任意の既知のタイプの伝送リンクを有することができる。加えて、図示されていないが、キャッシュ・メモリ、通信システム、システム・ソフトウェアなどの追加のコンポーネントもソース・コンピュータ１２に組み込むことができる。

データベース３８は、本明細書に記載した通り、本発明を実行するために必要な情報のための記憶域を提供することができる。このため、データベース３８は、磁気ディスク・ドライブまたは光ディスク・ドライブなどの１つまたは複数のストレージ・デバイスを含むことができる。さらに、データベース３８は、たとえば、ＬＡＮ、ＷＡＮ、またはストレージ・エリア・ネットワーク（ＳＡＮ）（図示せず）により分散されたデータを含むことができる。また、データベース３８は、１つまたは複数のストレージ・デバイスを含むものとして当業者が解釈できるように構成することもできる。宛先コンピュータ１６はソース・コンピュータ１２に併せて図示し論じた様々なハードウェア・コンポーネントも含むことは言うまでもない。これらのコンポーネントについては、簡潔にするために個別に描写または考察されていない。

コラボレーション・システム１０の様々な機能を実現するために、ソース・コンピュータ１２は、コンピュータ・プログラム・コードとしてメモリ３２に保管されたコラボレーション・プログラム４０Ａを含み、宛先コンピュータ１６は、コンピュータ・プログラム・コードとして保管されたコラボレーション・プログラム４０Ｂを含む。コラボレーション・プログラム４０Ａは、マッピング・システム４１と共用システム５４とを含む。以下に詳述するように、マッピング・システム４１は共用表示域２５（図２）に関する表示データを第１のフォーマットから共用フォーマットにマッピングする。共用システム５４は、その後、宛先コンピュータ１６上のコラボレーション・プログラム４０Ｂに提供される共用表示データとして、マッピングされた表示データを保管する。マッピング・システム４１は共用表示データを更新することができ、共用システム５４は、定期的に、要求あり次第、またはその何らかの組合せで、共用表示データを共用することができる。

コラボレーション・プログラム４０Ｂは、宛先ディスプレイ１８上の宛先表示域１２５（図２）内に共用表示データを表示するように構成された表示システム５６を含む。共用表示データを表示する場合、表示システム５６は、共用表示データのうちのいずれかが変更されているかどうかを決定し、宛先表示域１２５のうちの変更された部分を更新することができる。この決定は、たとえば、表示データをセクション単位に分割し、一度に１つのセクションを比較することにより行うことができる。共用システム５４は、共用表示データが宛先コンピュータ１６によって使用される頻度をモニターし、モニター対象の頻度に基づいてマッピング・システム４１が表示データをマッピングする速度を調整することができる。このケースでは、最大期間を設定することができ、その最大期間を超えると新たにマッピングされた表示データによって共用表示データがリフレッシュされる。また、コラボレーション・プログラム４０Ｂは、ユーザ２４が宛先コンピュータ１６を使用して共用表示域２５に関する表示データを変更できるようにするリモート・システム５８も含む。ユーザ２４による変更を実現するために、リモート・システム５８は、宛先コンピュータ１６で生成された入力装置イベント（たとえば、キーボード、マウスなど）を収集し、これらのイベントをソース・コンピュータ１２上の共用システム５４に転送する。ソース・コンピュータ１２に位置する入力装置によって生成された場合と同様にイベントが処理されるように、共用システム５４はイベントをソース・コンピュータ１２のイベント・ストリームに入れる。

マッピング・システム４１は、共用表示域２５（図２）に関する表示データを、共用システム５４によって使用される共用表示データにマッピングする。特に、マッピング・システム４１は、表示域２５内の各ピクセルについて表示データに含まれるピクセル・データを、第１のフォーマットから共用フォーマットにマッピングする。マッピング・システム４１は、定義システム４２と、ノード・システム４４と、マネージャ・システム４６と、モニター・システム４８と、検索システム５０と、変換システム５２とを含む。これらのシステムの動作については、本発明のマッピング方法に関連して以下に説明する。

コラボレーション・システム１０に含まれる機能性を追加／削減できることは言うまでもない。たとえば、リモート・システム５８により、ユーザ２４は、コラボレーション・システム１０の任意選択の特徴である宛先コンピュータ１６を使用して共用表示域２５に関する表示データを変更することができる。さらに、ユーザ２０あるいはユーザ２４またはその両方は、システム間で実現されるコラボレーションの範囲を選択できるようにすることができる。コラボレーションなし、共用表示のみ、共用表示およびオーディオ、リモート・コントロールなどが行われることを指定するために、キーストローク・シーケンスを使用することができる。さらに、ディスプレイ（ソース・ディスプレイ１４あるいは宛先ディスプレイ１８またはその両方）内のマウス・ポインタの位置は、共用システム５４あるいはリモート・システム５８またはその両方を使用して、ソース・コンピュータ１２と宛先コンピュータ１６との間で共用することができる。

ＩＩＩ．マッピング方法
本発明は、表示域に関する表示データを共用フォーマットにマッピングする。一実施形態では、表示データは、表示域内の各ピクセルに関するピクセル・データを含む。ピクセル・データは、ピクセルの位置、ピクセルのカラー、およびピクセルの深さに関する情報を含む。ピクセル・データは第１のフォーマットから共用フォーマットにマッピングされる。本発明の方法については図３および図４に関連して論じるが、これらの図はそれぞれ、例示的なマッピング・システム４１と、本発明の一実施形態によりマッピングを実行する際に使用される方法ステップの概要を示している。ステップＳ１（図４）では、マッピングすべき表示域２５（図２）が定義システム４２（図３）によって定義される。

ステップＳ２（図４）では、ノード・システム４４（図３）によって表示域２５に関連するノードが各ウィンドウごとに作成される。一実施形態では、ソース・ディスプレイ１４上に表示された各ウィンドウ（すなわち、図２のウィンドウ２２Ａ〜２２Ｄ）ごとにノードが作成される。すべてのウィンドウを含むことにより、共用されないウィンドウ（すなわち、ウィンドウ２２Ｄ）の位置をモニターして、それがその後、共用域内に移動するかまたは共用ウィンドウにオーバラップするかを決定することができる。しかし、ウィンドウ（たとえば、ソース・ディスプレイ１４の特定の領域内のすべてのウィンドウまたは共用されると指定されたすべてのウィンドウ）の一部分についてのみノードを作成できることは言うまでもない。図６は、ノード６６Ａ〜６６Ｈを含む、図１の表示域６０に関するノード階層６２の概略表現を描写している。各ノード６６Ａ〜６６Ｈは、それに対応するウィンドウ６４Ａ〜６４Ｈ（図１）に関する属性情報を含むデータの集合である。「属性情報」は、階層関係データ（すなわち、親ウィンドウあるいは子ウィンドウ（複数も可）またはその両方に関するデータ）ならびに対応するウィンドウのサイズ、位置、あるいは形状またはこれらの組合せを含む。加えて、ウィンドウに関するピクセル・データのフォーマットに関するデータが属性情報として保管される。この例示的な実施形態では、フォーマット・データは、図６に示す通り、ピクセル・データに関する深さおよびビジュアルを含む。さらに、指標付きピクセル値を使用して、ウィンドウに対応するノードに関する属性情報としてカラー・マップを作成し保管することができる。多くの場合、あるアプリケーション内のウィンドウは単一カラー・マップを共用する。その結果として、１つのカラー・マップを共用するウィンドウに対応するすべてのノードによって、そのカラー・マップを作成し共用することができる。動的ビジュアル・タイプの場合、カラー・マップは、カラー・マップ・インスタンスが変更されたことを示すウィンドウ・イベントの発生に基づいてあるいはカラー・マップ内のいずれかの値が変更されたかどうかを判定するために定期的にまたはその両方で、更新する必要がある可能性がある。たとえば、動的カラー・マップの場合、表示域を再マッピングするたびにカラー・マップ内の値を再読取りすることができる。それより多くの情報または少ない情報を属性情報として保管できることは言うまでもない。たとえば、スタック順序データ、クリッピング情報（すなわち、その親の内部に見えるウィンドウの量）、あるいはボーダ・サイズ、またはこれらの組合せを各ウィンドウごとに含めることができる。

図４のステップＳ３では、マネージャ・システム４６（図３）により各ノード６６Ａ〜６６Ｈの属性情報の一部として保管された階層関係データあるいはスタック順序データまたはその両方を使用してノード階層６２（図６）が生成される。図７は、ノード階層６２の例示的な一実施形態を示し、そのノード階層の各ノード６６Ａ〜６６Ｈは、対応するウィンドウ６４Ａ〜６４Ｈ（図１）に関する属性情報ならびに階層構造を実現するための親ノード、前の兄弟ノード、次の兄弟ノード、および子ノードへのポインタを含む。当技術分野で周知の通り、ポインタの使用は、ノードの再配列、挿入、および削除を含む、ノード階層６２の効率の良いナビゲーションおよび管理を可能にする。データを管理するためのポインタの使用および設定は当技術分野で周知のものであり、したがって、本明細書ではこれ以上詳述しない。使用するポインタの追加または削減が可能であるとともにポインタの有無にかかわらずデータを管理する任意の代替方法も使用できることは言うまでもない。

ノード６６Ａ〜６６Ｈは最初は、階層関係データに基づいてノード階層６２内に置かれる。図１、図６、および図７をまとめて参照すると、ウィンドウ６４Ａは親ウィンドウを持っていないので、その対応するノードであるノード６６Ａはノード階層６２の最上位に置かれる。ウィンドウ６４Ａの子ウィンドウ６４Ｂ〜６４Ｄに関するノード６６Ｂ〜６６Ｄはノード６６Ａより１つ下のレベルに置かれ、ウィンドウ６４Ｂの子ウィンドウ６４Ｅ〜６４Ｇに関するノード６６Ｅ〜６６Ｇはノード６６Ｂより１つ下のレベルに置かれ、ウィンドウ６４Ｄの子ウィンドウ６４Ｈに関するノード６６Ｈはノード６６Ｄより１つ下のレベルに置かれる。この実施形態では、１組の兄弟ノード（すなわち、１組の兄弟ウィンドウに関する１組のノード）はさらに、その１組の兄弟ウィンドウに関するスタック順序データに応じてノード階層６２内に置かれる。その１組の兄弟ノードは、スタック順序内の最上位ノードが最初に置かれ、残りのノードが降順に続くように構成される。その結果として、ウィンドウ６４Ｂ〜６４Ｄの場合、ノード６６Ｂが最初に置かれ、次にノード６６Ｃが続き、さらにノード６６Ｄが続く。同様に、ウィンドウ６４Ｅ〜６４Ｇの場合、ノード６６Ｅが最初に置かれ、次にノード６６Ｆが続き、さらにノード６６Ｇが続く。

作成されると、ノード階層６２および個々のノード６６Ａ〜６６Ｈ内の属性情報は直ちに時代遅れになる可能性がある。その結果として、ステップＳ４およびＳ５が図４に含まれる。ステップＳ４では、様々なウィンドウ・イベント・タイプがモニター・システム４８（図３）によってモニターされる。ステップＳ５では、モニター対象のウィンドウ・イベント・タイプの１つの発生に基づいて、マネージャ・システム４６（図３）によりノード階層が更新される。たとえば、図１を参照すると、ユーザはウィンドウ６４Ｈを選択することができ、それにより、その親ウィンドウ６４Ｄを１組の兄弟６４Ｂ〜６４Ｄ内のスタック順序の前面に移動する。さらに、１つまたは複数のウィンドウの作成、破壊、移動、サイズ変更などを行うことができる。一般に、これらのアクションのうちの１つまたは複数が行われると、ウィンドウ表示システムはウィンドウ・イベントを生成する。その結果として、これらのイベントの発生は非同期式にモニターすることができ、モニター対象のウィンドウ・イベントの発生に基づいてノード階層６２あるいは１つまたは複数のノード６６Ａ〜６６Ｈ内の属性情報またはその両方を更新することができる。

図４のステップＳ６およびＳ７は、ステップＳ４およびＳ５と並列に行われるものとして示されている。ステップＳ６では、検索システム５０（図２）によって表示データが入手される。ステップＳ７では、変換システム５２（図２）によりノード階層を使用して表示データが共用フォーマットにマッピングされる。各組のステップＳ４〜Ｓ５およびＳ６〜Ｓ７は、表示データのマッピングがもはや不要であるとそれぞれステップＳ８およびＳ９で判定されるまで繰り返される。並列に示されているが、ステップＳ４〜Ｓ５およびＳ６〜Ｓ７は、並列、直列、または何らかの組合せとして実現することができる。

ステップＳ６ならびに図１、図６、および図７をまとめて参照すると、ノード階層６２の使用により、１つまたは複数の子ウィンドウ、孫ウィンドウなどをマッピングする際に、祖先ウィンドウに関して入手した表示データを使用することができる。表示データを入手するために、最上位ウィンドウ（すなわち、図１のウィンドウ６４Ａ）によって定義された表示域に関する表示データが表示メモリからコピーされる。各ウィンドウはその親ウィンドウの表示域内に位置するので、子ウィンドウ、孫ウィンドウなど（すなわち、ウィンドウ６４Ｂ〜６４Ｈ）の一部または全部に関する表示データも入手することができる。

Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍで実現されると、祖先ノードおよび各介入祖先ノード（intervening ancestor node）と共通の深さを共用するノード（複数も可）に関する表示データは、祖先ノードに関する表示データを獲得する単一操作で入手することができる。たとえば、図６は、８ビットのＰｓｅｕｄｏＣｏｌｏｒ（ＰＣ）ピクセル・データを有するノード６６Ａ、６６Ｂ、６６Ｅと、２４ビットのＰＣピクセル・データを有するノード６６Ｃ、６６Ｈと、２４ビットのＴｒｕｅＣｏｌｏｒ（ＴＣ）ピクセル・データを有するノード６６Ｄ、６６Ｇと、８ビットのＴＣピクセル・データを有するノード６６Ｆとを示している。ピクセル・データの深さが同じである限り、複数のノードに関する表示データは、使用するビジュアルにかかわらず、１回の操作で入手することができる。その結果、ノード６６Ａに関する表示データが入手されると、ノード６６Ｂ、６６Ｅ、および６６Ｆに関する表示データも入手される。その祖先ノード６６Ａ、６６ＢがＰＣピクセル・データを使用する間にノード６６ＦがＴＣピクセル・データを使用する場合でも、ノード６６Ｆに関する表示データを入手することができる。

しかし、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍでは、ウィンドウまたは介入祖先ウィンドウが祖先ウィンドウとは異なる深さを使用する場合、そのウィンドウに関する表示データは、その祖先ウィンドウに関する表示データが検索されるときに未定義である。このケースでは、すべてのノード６６Ａ〜６６Ｈに関する表示データを入手するために、複数の操作が必要になる。たとえば、ノード６６Ｇは２４ビットを有するピクセル・データを使用する。その結果として、そのピクセル・データを入手するために、個別の操作が必要になる。同様に、ノード６６Ｃ、６６Ｄも２４ビットを有するピクセル・データを使用する。ノード６６Ｃ、６６Ｄはいずれももう一方のノードの祖先ではないので、ノード６６Ｃ、６６Ｄのそれぞれは、その表示データを入手するために追加の操作を必要とする。しかし、ノード６６Ｄに関する表示データが入手されると、ノード６６Ｈも同じ深さを使用するので、ノード６６Ｈに関する表示データも入手される。

表示データが入手されると、ステップＳ７（図４）は、表示データ内のピクセル・データをその現行フォーマットから共用フォーマットにマッピングする。図５は、マッピング・ステップの例示的な一実施形態を示し、ステップＳ７Ａは各ピクセルに対応するノードを決定し、ステップＳ７Ｂはそのノードを使用してそのピクセルに関するピクセル・データの現行フォーマットを決定し、ステップＳ７Ｃはその現行フォーマットのピクセル・データから共用フォーマットのピクセル・データを生成する。ステップＳ７Ｄは、表示データ内の各ピクセルごとにこれらのステップを繰り返す。ノード６６Ａ〜６６Ｈを備えたノード階層６２（図６および図７）を生成し、対応するウィンドウ６４Ａ〜６４Ｈに関する属性情報を各ノード６６Ａ〜６６Ｈに保管すると、正しいノードをステップＳ７Ａで効率よく突き止めることができる。適切なノードを突き止めるために、ノード階層６２は接頭部順にトラバースされる。すなわち、あるピクセルを含む第１のノードであって、それに関するピクセルがその子ノード、孫ノードなどのいずれにも入っていないノードは、そのピクセルに関するピクセル・データをマッピングする際に使用するために正しいノードである。

図１のピクセル６８は、ステップＳ６およびＳ７（図４）の例示的な一例を提供する。ピクセル６８は各ウィンドウ６４Ａ〜６４Ｈによって定義された領域内にあるが、現在、ウィンドウ６４Ｅがピクセル６８を所有している。したがって、ピクセル６８に関するピクセル・データをあるフォーマットから共用フォーマットにマッピングするには、ノード６６Ｅ内の属性情報を使用することが必要である。ノード６６Ｅがピクセル６８に対応すると判定するために、階層の最上位にあるノードが最初に調べられる。ノード６６Ａ内の属性情報を使用して、ピクセル６８がウィンドウ６４Ａの領域内にあるかどうかを判定する。そうであるので、ノード６６Ａの第１の子であるノード６６Ｂが次に調べられる。ピクセル６８はウィンドウ６４Ｂの領域内にあるので、ノード６６Ｂの第１の子であるノード６６Ｅが調べられる。次に、ピクセル６８がウィンドウ６４Ｅの領域内にあり、ノード６６Ｅはいかなる子も持っていないと判定される。したがって、ノード６６Ｅはピクセル６８に関連するノードである。

ピクセル・データとその対応するノードが使用可能であるので、そのノードの属性情報を使用してピクセル・データの現行フォーマットが決定され（図５のステップＳ７Ｂ）、共用フォーマットのピクセル・データが生成される（図５のステップＳ７Ｃ）。一実施形態では、ノード内の深さ、ビジュアル、あるいはカラー・マップ、またはこれらの組合せの情報を使用して、ピクセル・データを共用フォーマットにマッピングする。共用フォーマットは、たとえば、他のアプリケーションあるいはシステムまたはその両方によって容易に変換できる２４ビットのＴｒｕｅＣｏｌｏｒフォーマットを有することができる。このケースでは、ピクセル・データがそのデータ自体にＲＧＢ値を含む場合、データのマッピングは、各ＲＧＢ値が８ビットで表されるようにピクセル・データをシフトすることを含むことができる。指標付けを使用するピクセル・データの場合、そのピクセル・データを使用してカラー・マップ内のＲＧＢ値をルックアップすることができ、その後、ＲＧＢ値は各値が８ビットを有するようにシフトされる。

適切なノードを突き止める際の速度をさらに高めるために、表示域を複数のセクションに分割することができる。たとえば、図１は、２次元グリッドに分割された表示域６０を示し、各セクション７０Ａ〜７０Ｃの幅および長さは設定されたピクセル数になっている。一実施形態では、各セクション７０Ａ〜７０Ｃは、２の累乗であるサイズを有する正方形のピクセル・ブロックであり、たとえば、幅が２４ピクセルで長さが２４ピクセルである。各セクション７０Ａ〜７０Ｃには、ディスプレイ内のピクセルと同様のアドレス（すなわち、ｘ，ｙ座標）を割り当てることができる。２の累乗である長さおよび幅を使用すると、ピクセル位置を表す値を右シフトすることにより、ピクセルが位置するセクションのアドレスを迅速に決定することができる。しかし、セクション７０Ａ〜７０Ｃについて任意のサイズまたは形状を使用できることは言うまでもない。

図１および図６〜８をまとめて参照すると、ノード階層６２およびセクション７０Ａ〜７０Ｃを使用する場合、各セクション７０Ａ〜７０Ｃについてノード・リスト７６Ａ〜７６Ｃを作成することができる。各ノード・リスト７６Ａ〜７６Ｃは、セクション７０Ａ〜７０Ｃ内で現在見えている各ウィンドウに関するノードを含む。一実施形態では、各アレイ・エレメント７２Ａ〜７２Ｃが固有のセクション７０Ａ〜７０Ｃに関連付けられている２次元アレイ７４が作成される。各アレイ・エレメント７２Ａ〜７２Ｃは、そのセクション７０Ａ〜７０Ｃに関するノード・リスト７６Ａ〜７６Ｃを有する。各ノード・リスト７６Ａ〜７６Ｃは、そのエレメント７２Ａ〜７２Ｃに関するセクション７０Ａ〜７０Ｃ内の少なくとも１つのピクセルを所有する各ノードを含む。たとえば、エレメント７２Ａに関するノード・リスト７６Ａは、セクション７０Ａ内に見える各ノードを含む。各ノード・リスト７６Ａ〜７６Ｃは、そのセクション７０Ａ〜７０Ｃ内の最上位ウィンドウに対応するノードがノード・リスト７６Ａ〜７６Ｃの先頭に位置し、残りのノードが降順に位置するように順序付けられる。代わって、そのセクション７０Ａ〜７０Ｃ内の最多数のピクセルを現在所有するウィンドウに対応するノードは、各ノード・リスト７６Ａ〜７６Ｃの先頭に位置することができる。

ノード・リスト７６Ａ〜７６Ｃについて追加のデータ保守が必要になるが、それは、所与のピクセルについて適切なノードを決定するためにサーチしなければならないノードの平均数を削減するものである。たとえば、セクション７０Ｂは表示域６０の１つのセクションである。ウィンドウ６４Ｂ、６４Ｃ、６４Ｅ、および６４Ｇは、セクション７０内の表示域の少なくとも一部分を所有する。その結果として、アレイ・エレメント７２Ｂは、ノード６６Ｂ、６６Ｃ、６６Ｅ、および６６Ｇを含むノード・リスト７６Ｂを有する。上記で論じた通り、ノード・リスト７６Ｂは、スタック順序の先頭にあるノードが最初に突き止められるように順序付けられる。このケースでは、ノード６６Ｅが第１のノードになり、次にノード６６Ｇ、ノード６６Ｂが続き、さらにノード６６Ｃが続く。ピクセル６８に対応するノードを突き止めるために、ピクセル６８がセクション７０Ｂ内に位置すると判定される。エレメント７２Ｂに関するノード・リスト７６Ｂを使用すると、単一ノードのみを調べた後、ノード６６Ｅが適切なノードであると判定される。

セクション７０Ａ〜７０Ｃおよびノード・リスト７６Ａ〜７６Ｃを使用すると、ウィンドウごとではなく、セクションごとに表示データを容易に入手することができる。セクションごとに入手されると、各ノード６６Ａ〜６６Ｈの属性情報は、最上位祖先ノードを識別するデータをさらに含むことができる。最上位祖先ノードは、単一操作を使用してそのノードに対応するウィンドウに関する表示データを入手できる、最遠祖先ウィンドウに対応する。上記で論じた通り、Ｘ Ｗｉｎｄｏｗでは、あるウィンドウに関する表示データがその親ウィンドウとは異なる深さを使用して保管されると、各ウィンドウに関する表示データを入出するために２回の操作が必要になる。その結果、ノード６６Ａはノード６６Ａ、６６Ｂ、６６Ｅ、６６Ｆに関する最上位祖先ノードになり、ノード６６Ｃ、６６Ｄ、６６Ｇはそれ自体をその最上位祖先ノードとして持つことになり、ノード６６Ｈはノード６６Ｄをその最上位祖先ノードとして持つことになるであろう。最上位祖先ノードを含むことにより、ノード階層６２の恩恵をセクションごとに容易に活用することができる。たとえば、セクション７０Ａに関する表示データを入手する場合、ノード・リスト７６Ａが調べられる。ノード６６Ｅは第１のノードであり、ノード６６Ａという最上位祖先を有する。その結果として、セクション７０Ａ内にあるウィンドウ６４Ａの一部分に関する表示データが入手される。入手された表示データは、ウィンドウ６４Ｅ、６４Ｆ、および６４Ｂに関する表示データをマッピングするために使用される。ウィンドウ６４Ｃに関する表示データを検索するために第２の操作が必要になり、ウィンドウ６４Ｈに関する表示データを検索するために第３の操作が必要になるが、それは、これらのウィンドウがウィンドウ６４Ａとは異なる深さを使用するからである。

表示データのマッピングの効率は、各アレイ・エレメント７２Ａ〜７２Ｃに関する第２の２次元アレイ７８Ａを含めることにより、さらに高めることができる。アレイ７８Ａは対応するセクション７０Ａ内に位置する各ピクセルに関するアレイ・エレメント８０を含む。各アレイ・エレメント８０は、そのピクセルを所有するウィンドウに対応するノードを識別するＩＤを含む。共用されないウィンドウがセクション７０Ａ〜７０Ｃ内に表示されると、アレイ７８Ａ内のエレメント８０のうち、そのウィンドウによって所有されるピクセルに対応するエレメント８０には、無効のマークを付けることができる。アレイ７８Ａの使用により、共用表示域内の任意のピクセルに関する対応ノードを単一操作で見つけられることが保証される。

セクション７０Ａ〜７０Ｃに関するノード・リスト７６Ａ〜７６Ｃあるいはアレイ７８Ａまたはこれらの組合せは、ノード・リスト７６Ａ〜７６Ｃあるいはアレイ７８Ａまたはこれらの組合せのうちの１つまたは複数を達成するモニター対象のウィンドウ・イベントの発生が検出されたときに、ノード階層６２とともに更新することができる。一実施形態では、モニター対象のウィンドウ・イベントは、共用表示データの更新が再始動されるまでキューに入れられ、その時点でノード階層６２、ノード・リスト７６Ａ〜７６Ｃ、およびアレイ７８Ａは、必要であれば、キューに入れられたすべてのウィンドウ・イベントに基づいて更新される。ノード・リスト７６Ａ〜７６Ｃおよびアレイ７８Ａは、現在知られているかまたは今後開発される任意の方法を使用して実現することができる。たとえば、各ノード・リスト７６Ａ〜７６Ｃは、メモリに保管された対応するノードへのポインタのリンク・リストを有することができ、各アレイ７８Ａは、当技術分野で周知の通り、各ピクセルについてメモリに保管された対応するノードへのポインタを含むエレメントを有する２次元アレイを有することができる。

この考察はマッピングすべき表示域内の各ウィンドウについて作成されたノードに限られているが、マッピングすべき表示域内に位置するかどうかにかかわらず、ディスプレイ内のすべてのウィンドウについてノードを作成し管理できることは言うまでもない。さらに、この方法はピクセル・データに関連して記載されているが、本発明の教示は任意のタイプの表示データに適用されることは言うまでもない。さらに、任意のウィンドウに含まれないディスプレイの一部分に関する表示データを入手するために、ディスプレイのデスクトップ（すなわち、背景）についてノードを作成できることは言うまでもない。

本発明は、表示データのマッピングが所望される汎用コンピュータ／サーバ・システムに適用可能である。本発明がハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現可能であることは認識されるであろう。ハードウェアとソフトウェアの典型的な組合せは、ロードされ実行されたときに、本明細書に記載したそれぞれの方法を実行するようにソース・コンピュータ１２（図２）あるいは宛先コンピュータ１６またはその両方を制御するコンピュータ・プログラムを備えた汎用コンピュータ・システムにすることができるであろう。代わって、本発明の機能上のタスクのうちの１つまたは複数を実行するための特殊ハードウェアを含む特定用途コンピュータを使用できるであろう。

本発明はコンピュータ・プログラムに組み込むこともでき、そのコンピュータ・プログラムは本明細書に記載した方法の実現を可能にするそれぞれの特徴をすべて有し、コンピュータ・システムにロードされたときにこれらの方法を実行することができる。これに関連して、コンピュータ・プログラム、ソフトウェア・プログラム、プログラム、またはソフトウェアは、直接または（ａ）他の言語、コード、または表記への変換、または（ｂ）異なる物質的形式による複製のいずれか一方または両方の後、情報処理機能を有するシステムに特定の機能を実行させるための１組の命令を任意の言語、コード、または表記で表した任意の表現を意味する。

様々な方法が特定の順序で発生するものとして記載されているが、複数の独立ステップを同時にまたは本明細書に記載したものとは異なる順序で実行できることは言うまでもない。さらに、様々なシステムが様々な機能を実現するものとして描写され論じられているが、本明細書に記載した様々な機能を実現するために使用できるシステムの削減あるいは追加またはその両方が可能であることは言うまでもない。

本発明の様々な態様の上記の説明は、例示および説明のために提示されたものである。これは、網羅的なものではなく、開示されている正確な形式に本発明を限定するためのものでもなく、明らかに、多くの変更および変形が可能である。当業者にとって明白である可能性がある変更および変形は、特許請求の範囲によって定義された本発明の範囲内に含まれるものである。

例示的な共用表示を示す図である。 複数のコンピュータ間でコラボレーションするための例示的なシステムのブロック図である。 図２のシステムのより詳細なブロック図である。 本発明の一実施形態による方法を示す図である。 図４のマッピング・ステップの一実施形態を示す図である。 図１の共用表示に基づくノード階層の概略表現である。 図６の例示的なノード階層の代替概略表現である。 複数のノード・リストおよび２次元アレイの一実施形態の概略表現である。

Claims (13)

1. 少なくとも１つのウィンドウ（６４Ａ〜６４Ｈ）を含む表示域（６０）に関する表示データをマッピングする方法において、前記方法が、
   各ウィンドウごとにノード（６６Ａ〜６６Ｈ）を作成するステップ（Ｓ２）であって、各ノードが階層関係データを含むステップと、
   前記階層関係データに基づいてノード階層（６２）を生成するステップ（Ｓ３）と、
   前記ノード階層を使用して第１のフォーマットから共用フォーマットに前記表示データをマッピングするステップ（Ｓ７）と、
   を有する方法。
2. ウィンドウ・イベントの発生をモニターするステップ（Ｓ４）と、
   前記ウィンドウ・イベントの前記発生に基づいて前記ノード階層（６２）を更新するステップ（Ｓ５）と、
   をさらに有する、請求項１に記載の方法。
3. 前記ウィンドウ・イベントの前記発生に基づいて前記階層関係データを更新するステップをさらに有する、請求項２に記載の方法。
4. １組の兄弟ウィンドウ（６４Ｂ〜６４Ｄ）に関する１組の兄弟ノード（６６Ｂ〜６６Ｄ）が、前記兄弟ウィンドウのスタック順序に基づいて前記ノード階層（６２）内に位置する、請求項１に記載の方法。
5. 前記表示域（６０）を複数のセクション（７０Ａ〜７０Ｃ）に分割するステップと、
   前記ノード階層（６２）を使用して各セクションに関するノード・リスト（７６Ａ〜７６Ｃ）を作成するステップであって、前記セクションの少なくとも一部分に表示される各ウィンドウに関する前記ノードが前記ノード・リストに含まれるステップと、
   をさらに有する、請求項１に記載の方法。
6. 各セクションに関するエレメント（７２Ａ〜７２Ｃ）を有するアレイ（７４）を作成するステップであって、各エレメントが対応するセクションに関する前記ノード・リストを含むステップをさらに有する、請求項５に記載の方法。
7. ウィンドウ・イベントの発生をモニターするステップ（Ｓ４）と、
   前記ウィンドウ・イベントの前記発生に基づいて前記ノード・リストのうちの少なくとも１つを更新するステップ（Ｓ５）と、
   をさらに有する、請求項５に記載の方法。
8. 単一操作で第１のピクセル深さを有する複数のウィンドウに関する表示データを入手するステップ（Ｓ６）をさらに有する、請求項１に記載の方法。
9. 第２のピクセル深さを有する少なくとも１つのウィンドウについて前記入手ステップ（Ｓ６）および前記マッピング・ステップ（Ｓ７）を繰り返すステップをさらに有する、請求項８に記載の方法。
10. 前記マッピング・ステップ（Ｓ７）が、
    前記表示データ内の各ピクセルに対応する前記ノードを決定するステップ（Ｓ７Ａ）と、
    前記ノードを使用して各ピクセルに関するピクセル・データの第１のフォーマットを決定するステップ（Ｓ７Ｂ）と、
    前記第１のフォーマットの前記ピクセル・データから各ピクセルについて前記共用フォーマットのピクセル・データを生成するステップ（Ｓ７Ｃ）と、
    を含む、請求項１に記載の方法。
11. 前記マッピングされた表示データを宛先コンピュータ（１６）と共用するステップをさらに有する、請求項１に記載の方法。
12. 前記方法が、前記方法の実現を可能にするコンピュータ可読プログラム・コードを有するコンピュータ・プログラムで実施されることを特徴とする、請求項１に記載の方法。
13. 前記方法が、コンピュータ可読記憶媒体に保管された命令で実施されることを特徴とする、請求項１に記載の方法。

Images