JP2008535083A - アプリケーションウィンドウのグループ化および管理のための方法および装置 - Google Patents

Abstract

ディスプレイ画面上に複数のウィンドウを表示するための方法が説明される。本方法は、ディスプレイ画面（要素３００ｂ）上に第１のアプリケーションウィンドウ（要素３４０ａ）と、第１のアプリケーションウィンドウと独立しており外部に存在する第２のアプリケーションウィンドウ（要素３３１）とを表示するステップと、第１のアプリケーションウィンドウと第２のアプリケーションウィンドウとを１つのグループとして宣言するステップと、第１のアプリケーションウィンドウと第２のウィンドウとを１つのグループ（３３０）へとグループ化するステップと、ディスプレイ画面（３３０）上の表現としてそのグループを表示するステップとを含んでいる。新しいアプリケーションウィンドウが開かれるときに、それらは、そのグループに追加することができ、かつ／またはそれらは、第２のグループのアプリケーションウィンドウのメンバになることができる。ユーザは、様々なグループ間で切り換えることができる。

Description

本発明の態様は、一般にオペレーティングシステム中におけるウィンドウ構成を対象としている。より詳細には、本発明の態様は、オペレーティングシステム中における複数のウィンドウをグループ化し、何らかのインテリジェントな動作が諸ウィンドウ間に存在することができるようにするための方法およびシステムを対象としている。

労働においても私生活においてもコンピュータの使用が増大するにつれて、コンピュータのより簡単な使用を可能にしたいという要望がもたれている。今日では多数のオペレーティングシステムが、ウィンドウベースのコンフィギュレーションのアプリケーションプログラムを利用している。情報は、数枚の書類があるように見えるようにしてディスプレイスクリーン上に表示される。諸ウィンドウとインターフェースすることにより、ユーザは、まるで１枚の書類をつかむかのように任意のウィンドウにアクセスすることができる。ウィンドウベースのコンフィギュレーションにより、ユーザは、ディスプレイ画面上に同時に複数のウィンドウを開くことができるようになる。

アプリケーションウィンドウは、すべてのグラフィックユーザインターフェース（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）（ＧＵＩ）システムのためのユーザインターフェース機能である。アプリケーションウィンドウは、システム間で外観が異なることもあるが、それらのアプリケーションウィンドウは、サイズ変更し位置を変更する機能、異なる複数のアプリケーションに関連する他の複数のアプリケーションウィンドウの間に存在させる機能など、多数の共通の属性を共有する。複数のアプリケーションウィンドウは、一緒に、互いに他方の上に層状に重ねられ、一般的に各ウィンドウがユーザによって最後にアクセスされた順序によって表わされて画面上に同時に現れる。

現代のＧＵＩに共通のユーザ対話のシナリオは、共通の画面領域（ｓｃｒｅｅｎ ｒｅａｌ ｅｓｔａｔｅ）を共用する複数の同時に開かれたアプリケーションウィンドウを伴う。複数の同時に開かれたアプリケーションウィンドウについてのサポートは、現代のＧＵＩの魅力および能力の一部分であるが、これは、しばしばアプリケーションウィンドウのオーバーラップと互いに見えなくすることをもたらし、ユーザが特定のアプリケーションウィンドウを見出し、それにナビゲートすることを困難にする。このタイプのシナリオと関連するソリューションは、一般にウィンドウ管理の問題とソリューションと称される。

ユーザは一般的に、アプリケーションウィンドウを電子メールなどのタスクに関連付け、さらに複数のアプリケーションウィンドウと単一のタスクまたはプロジェクトとの間の精神的な関連付けを作成することができる。例えば、スライドショープレゼンテーション（ｓｌｉｄｅ ｓｈｏｗ ｐｒｅｓｅｎｔａｔｉｏｎ）を生成するために、ユーザは、おそらく電子メール、グラフィックアプリケーション、スプレッドシートアプリケーションなど、１つまたは複数のアプリケーションからの３つまたは４つの異なるアプリケーションウィンドウからのコンテンツを必要とすることもある。複数のアプリケーションウィンドウが、画面上で目に見えることもあり、各アプリケーションウィンドウは、１つまたは複数のタスクに関連付けられる。ユーザは、これらの異なるアプリケーションウィンドウの間で所在を見出しナビゲートして、コンテンツにアクセスし、またはコンテンツを交換して、タスクを完了する必要がある。

多数のＧＵＩ中には共通のウィンドウ管理ソリューションが存在し、それによってアプリケーションウィンドウは、一次作業画面スペース中において最小にし、ビューから取り除くことができる。最小化されたアプリケーションウィンドウは、一般的にかなり小さなＵＩ要素によって表される。ワシントン州、レッドモンド市のマイクロソフト（登録商標）（Ｍｉｃｒｏｓｏｆｔ^(R) Ｃｏｒｐｏｒａｔｉｏｎ）によるＷｉｎｄｏｗｓ（登録商標）ＸＰにおいては、最小化されたアプリケーションウィンドウは、タスクバーコントロール（Ｔａｓｋ Ｂａｒ ｃｏｎｔｒｏｌ）など、コントロールバー（ｃｏｎｔｒｏｌ ｂａｒ）上のボタン（ｂｕｔｔｏｎ）として表される。カリフォルニア州、クパチーノ市のアップルコンピュータ社（Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ， Ｉｎｃ．）によるＭａｃ ＯＳ Ｘにおいては、最小化されたアプリケーションウィンドウは、ドック（Ｄｏｃｋ）中の小型サムネイルボタン（ｍｉｎｉａｔｕｒｅ ｔｈｕｍｂｎａｉｌ ｂｕｔｔｏｎ）として表される。アプリケーションウィンドウを最小化することにより、ユーザは、画面スペースから不必要なアプリケーションウィンドウを取り除くことができ、それによってユーザは、アプリケーションウィンドウのより小さな組に集中することができる。しかし、アプリケーションウィンドウを最小化することは、個別に実行することができるだけである。同様に、アプリケーションウィンドウは、最小化状態から取り出し、目に見えるアプリケーションウィンドウの組に対して再導入することができるが、これは、個別のアプリケーションウィンドウに基づいて行うことができるにすぎない。

現在では、独立した外部のウィンドウは、一緒にしてグループ化することができず、それ故に異種のウィンドウは、一緒に管理することができない。オペレーティングシステムは、現在では互いに一緒にグループ化すべき複数のウィンドウを許可せず、その結果、１つのウィンドウ上で実行されるオペレーションは、第２の独立した外部のアプリケーションウィンドウ上で自動的に実行することができない。

任意の複数のアプリケーションウィンドウを一緒にしてグループ化し、それ故に異種ウィンドウを、一緒に管理することができる機能が必要になっている。ディスプレイ画面上で第１のアプリケーションウィンドウと、第１のアプリケーションウィンドウと独立しており外部に存在する第２のアプリケーションウィンドウとを表示し、第１のアプリケーションウィンドウと第２のアプリケーションウィンドウとを１つのグループとして宣言し、第１のアプリケーションウィンドウと第２のアプリケーションウィンドウとを１つのグループへとグループ化し、ディスプレイ画面上で表現としてそのグループを表示するための方法が必要になっている。

本発明の態様は、複数のアプリケーションウィンドウを１つのグループとして管理する際の助けとなるウィンドウ管理システムを提供する。本発明の態様は、アプリケーションウィンドウの１つのグループを作成し、そのグループを最小化し、それによって以前に識別されたグループを取り出すことができるようにする新しい方法および装置を提供する。本方法により、ユーザは、それらのアプリケーションウィンドウからタスクへの関連付けを形式化し、例えば１つのグループを作成し、これらの関連付け、例えばアプリケーションウィンドウグループアイコン（ａｐｐｌｉｃａｔｉｏｎ ｗｉｎｄｏｗ ｇｒｏｕｐ ｉｃｏｎ）を管理する機能を提供することができるようになる。

本発明の前述の概要、ならびに例示の実施形態についての以降の詳細な説明は、一例として含められるが、請求されている本発明に関する限定としては含められていない添付図面と併せて読まれるときに、よりよく理解される。

様々な例示の実施形態の以降の説明においては、本明細書の一部分を形成し、本発明を実行することができる様々な実施形態が例証として示される添付図面に対する参照が行われる。他の実施形態を利用することができ、本発明の範囲を逸脱することなく構成および機能の修正を行うことができることを理解すべきである。

図１は、本発明を実装することができる適切なコンピューティングシステム環境１００の一例を示すものである。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の用途または機能の範囲についてどのような限定も示唆することは意図されてはいない。コンピューティングシステム環境１００は、例示のコンピューティングシステム環境１００中に示されるコンポーネントの任意の１つまたは組合せに関連したどのような依存性も要件も有するものと解釈されるべきではない。

本発明は、非常に多数の他の汎用または専用のコンピューティングシステムの環境またはコンフィギュレーションを用いて動作可能である。本発明と共に使用するのに適したものとすることができるよく知られているコンピューティングシステム、コンピューティング環境、および／またはコンピューティングコンフィギュレーションの例は、それだけには限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルな大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのどれかを含む分散コンピューティング環境などを含む。

本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な場合について説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、あるいは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでいる。本発明は、タスクが、通信ネットワークを介してリンクされるリモート処理デバイスによって実行される場合の分散コンピューティング環境において実行することもできる。分散コンピューティング環境においては、プログラムモジュールは、メモリストレージデバイスを含めて、ローカルコンピュータストレージ媒体にもリモートコンピュータストレージ媒体にも配置することができる。

図１Ａを参照すると、本発明を実装するための例示のシステムは、コンピュータ１１０の形態の汎用コンピューティングデバイスを含んでいる。コンピュータ１１０のコンポーネントは、それだけには限定されないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含めて様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１を含むことができる。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用したメモリバスまたはメモリコントローラ、ペリフェラルバス、およびローカルバスを含めて、いくつかのタイプのバス構造のうちの任意のものであってもよい。一例として、限定するものではないが、そのようなアーキテクチャは、業界標準アーキテクチャ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＭＣＡ）バス、拡張ＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）（ＥＩＳＡ）バス、ビデオエレクトロニクス規格協会（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄ Ａｓｓｏｃｉａｔｉｏｎ）（ＶＥＳＡ）ローカルバス、およびメザニンバス（Ｍｅｚｚａｎｉｎｅ ｂｕｓ）としても知られているペリフェラルコンポーネント相互接続（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）（ＰＣＩ）バスを含んでいる。

コンピュータ１１０は、一般的に様々なコンピュータ読取り可能媒体を含んでいる。コンピュータ読取り可能媒体は、コンピュータ１１０によってアクセスすることができ、揮発性媒体も不揮発性媒体も、着脱可能媒体も着脱不能媒体も含む使用可能な任意の媒体とすることができる。一例として限定するものではないが、コンピュータ読取り可能媒体は、コンピュータストレージ媒体および通信媒体を備えることができる。コンピュータストレージ媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、他のデータなどの情報の記憶のための任意の方法または技術で実装された揮発性および不揮発性の着脱可能および着脱不能な媒体を含んでいる。コンピュータストレージ媒体は、それだけには限定されないが、望ましい情報を記憶するために使用することができ、コンピュータ１１０によってアクセスすることができるランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）（ＲＡＭ）、読取り専用メモリ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）（ＲＯＭ）、電子的消去可能プログラマブル読取り専用メモリ（ｅｌｅｃｔｒｏｎｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは任意の他の媒体を含む。通信媒体は、一般的に搬送波や他の移送メカニズムなどの被変調データ信号の形のコンピュータ読取り可能命令、データ構造、プログラムモジュールまたは他のデータを実装し、任意の情報配信媒体を含んでいる。用語「被変調データ信号」は、情報を信号の形で符号化するような方法で１つまたは複数のその特性が設定され、または変更された信号を意味する。一例として、限定するものではないが、通信媒体は、有線ネットワーク、直接配線接続などの有線媒体と、音響媒体、ＲＦ媒体、赤外線媒体、他の無線媒体などの無線媒体を含んでいる。以上のうちの任意の組合せもまた、コンピュータ読取り可能媒体の範囲内に含められるべきである。

システムメモリ１３０は、ＲＯＭ１３１やＲＡＭ１３２など、揮発性および／または不揮発性のメモリの形態のコンピュータストレージ媒体を含んでいる。起動中などにコンピュータ１１０内の要素間の情報を転送する助けを行う基本ルーチンを含む基本入出力システム（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）（ＢＩＯＳ）１３３は、一般的にＲＯＭ１３１中に記憶される。ＲＡＭ１３２は、一般的に処理装置１２０によって直接にアクセス可能であり、かつ／または現在動作させられているデータおよび／またはプログラムモジュールを含んでいる。一例として、限定するものではないが、図１Ａは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０は、他の着脱可能／着脱不能な揮発性／不揮発性のコンピュータストレージ媒体も含むこともできる。一例としてだけであるが、図１Ａは、着脱不能な不揮発性の磁気媒体から読み取り、またはそれに書き込むハードディスクドライブ１４１と、着脱可能な不揮発性の磁気ディスク１５２から読み取り、それに書き込む磁気ディスクドライブ１５１と、ＣＤ ＲＯＭや他の光媒体など着脱可能な不揮発性の光ディスク１５６から読み取り、またはそれに書き込む光ディスクドライブ１５５とを示している。例示の動作環境中において使用することができる他の着脱可能／着脱不能な揮発性／不揮発性のコンピュータストレージ媒体は、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどを含んでいる。ハードディスクドライブ１４１は、一般的にインターフェース１４０などの着脱不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、一般的にインターフェース１５０などの着脱可能メモリインターフェースによってシステムバス１２１に接続される。

以上で論じられ図１Ａに示されたドライブとそれらの関連するコンピュータストレージ媒体は、コンピュータ１１０についてのコンピュータ読取り可能命令、データ構造、プログラムモジュールおよび他のデータの記憶を実現する。図１Ａにおいては、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示される。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、またはそれらとは異なっていてもどちらにもすることができることに注意すべきである。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくともそれらが異なるコピーであることを示すためにここでは異なる番号が付与される。ユーザは、デジタルカメラ１６３、キーボード１６２、一般的にマウス、トラックボールまたはタッチパッドと称されるポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。（図示されていない）他の入力デバイスは、ペン、スタイラス（ｓｔｙｌｕｓ）およびタブレット（ｔａｂｌｅｔ）、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ（ｓａｔｅｌｌｉｔｅ ｄｉｓｈ）、スキャナなどを含むことができる。これらおよび他の入力デバイスは、多くの場合にシステムバス１２１に結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することもできる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを経由してシステムバス１２１に接続される。モニタに追加して、コンピュータはまた、スピーカ１９７やプリンタ１９６などの他のペリフェラル出力デバイスを含むこともでき、これらは、出力ペリフェラルインターフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータに対する論理接続を使用してネットワーク化された環境中において動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通のネットワークノードとすることができ、一般的にコンピュータ１１０に対して以上で説明された要素のうちの多くまたはすべてを含んでいるが、メモリストレージデバイス１８１だけが図１Ａには示されている。図１Ａ中に示された論理接続は、ローカルエリアネットワーク（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）（ＬＡＮ）１７１と、ワイドエリアネットワーク（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）（ＷＡＮ）１７３とを含んでいるが、他のネットワークを含むこともできる。そのようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的になっている。

ＬＡＮネットワーキング環境において使用されるときには、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用されるときには、コンピュータ１１０は、一般的にインターネットなどのＷＡＮ１７３上で通信を確立するためのモデム１７２または他の手段を含んでいる。内部にあっても、または外部にあってもよいモデム１７２は、ユーザ入力インターフェース１６０または他の適切なメカニズムを経由してシステムバス１２１に接続することができる。ネットワーク化環境においては、コンピュータ１１０に対して示されるプログラムモジュール、またはその一部分は、リモートメモリストレージデバイスに記憶することができる。一例として限定するものではないが、図１Ａは、リモートアプリケーションプログラム１８５をメモリデバイス１８１上に存在するものとして示している。図に示されるネットワーク接続は、例示的なものであり、コンピュータ間で通信リンクを確立する他の手段が使用されてもよいことが理解されよう。

図に示されるネットワーク接続は、例示的なものであり、コンピュータ間で通信リンクを確立する他の手段を使用することもできることが理解されよう。ＴＣＰ／ＩＰ、イーサネット（登録商標）、ＦＴＰ、ＨＴＴＰなど、様々なよく知られているプロトコルのうちの任意のものの存在が仮定され、システムは、クライアント−サーバのコンフィギュレーション中で動作させられて、それにより、ユーザは、ウェブベースのサーバからウェブページを取り出すことができるようになる。様々な従来のウェブブラウザのうちの任意のものを使用して、ウェブページ上でデータを表示し、操作することができる。

プログラミングインターフェース（またはより簡単に、インターフェース）は、コードの１つまたは複数の他のセグメントによって実現される機能と情報をやり取りし、あるいはその機能にアクセスするコードの１つまたは複数のセグメントを可能にするための任意のメカニズム、プロセス、プロトコルとみなすことができる。代わりに、プログラミングインターフェースは、他の１つ（または複数）のコンポーネントのうちの１つまたは複数のメカニズム、メソッド（ｍｅｔｈｏｄ）、ファンクションコール（ｆｕｎｃｔｉｏｎ ｃａｌｌ）、モジュールなどに結合して情報伝達することが可能なシステムのコンポーネントの１つまたは複数のメカニズム、メソッド、ファンクションコール、モジュール、オブジェクトなどとみなすこともできる。先行する文章中の用語「コードのセグメント」は、コードの１つまたは複数の命令またはラインを含むことを意図しており、例えば、適用される専門用語にかかわらず、あるいはコードセグメントが別々にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードとして提供されるかどうか、コードセグメントがランタイムのシステムまたはプロセス中で利用されるかどうか、それらが同じマシンもしくは異なるマシン上に配置され、または複数のマシンにまたがって分散されるかどうか、またはコードのセグメントによって表される機能が、全体的にソフトウェアで、全体的にハードウェアで、またはハードウェアとソフトウェアの組合せの形で実装されるかどうかにかかわらず、コードモジュール、オブジェクト、サブルーチン、ファンクションなどを含んでいる。

概念的に、プログラミングインターフェースは、図１Ｂまたは図１Ｃに示されるように、包括的に考えることができる。図１Ｂは、それを介して第１および第２のコードセグメントが情報をやり取りするコンジット（ｃｏｎｄｕｉｔ）としてインターフェース、インターフェース１を示している。図１Ｃは、（第１および第２のコードセグメントの一部分であっても、あるいはそうでなくてもよい）インターフェースオブジェクトＩ１およびＩ２を備えるものとしてインターフェースを示しており、これらのインターフェースオブジェクトにより、システムの第１および第２のコードセグメントは媒体Ｍを経由して情報をやり取りすることができるようになる。図１Ｃの図においては、人は、インターフェースオブジェクトＩ１とＩ２とを同じシステムの別のインターフェースとして考えることができ、人はまた、オブジェクトＩ１およびＩ２プラス媒体Ｍがインターフェースを構成するものと考えることもできる。図１Ｂおよび１Ｃは、双方向フローと、そのフローのおのおのの側上のインターフェースを示すが、ある種の実装形態は、一方向の情報フローを有することができるだけであり（または以下で説明されるように情報フローがない）、あるいは一方の側上にインターフェースオブジェクトを有することができるだけである。一例として、限定するものではないが、アプリケーションプログラミングインターフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）（ＡＰＩ）、エントリポイント（ｅｎｔｒｙ ｐｏｉｎｔ）、メソッド、ファンクション、サブルーチン、リモートプロシージャコール（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ）、およびコンポーネントオブジェクトモデル（ｃｏｍｐｏｎｅｎｔ ｏｂｊｅｃｔ ｍｏｄｅｌ）（ＣＯＭ）インターフェースなどの用語は、プログラミングインターフェースの定義内に包含される。

そのようなプログラミングインターフェースの態様は、第１のコードセグメントが情報（ここで、「情報」は、その最も広い意味で使用され、データ、コマンド、要求などを含んでいる）を第２のコードセグメントに送る方法と、第２のコードセグメントがその情報を受け取る方法と、その情報の構成、シーケンス、構文（ｓｙｎｔａｘ）、組織、スキーマ、タイミングおよびコンテンツを含むことができる。この点については、基礎になっている移送媒体それ自体は、情報がインターフェースによって定義されるように移送される限り、媒体が有線であれ、または無線であれ、あるいは両方の組合せであれ、インターフェースのオペレーションにとって重要でないこともある。ある種の状況においては、１つのコードセグメントが、単に第２のコードセグメントによって実施される機能にアクセスするときなど、情報転送は、別のメカニズムを経由している（例えば、バッファ、ファイルなどに配置された情報は、コードセグメントの間の情報フローから別になっている）か、または存在しないこともあるので、情報は、従来の意味で一方向または両方向に渡されないこともある。これらの態様のうちの任意のもの、または、すべては、例えばコードセグメントが疎結合または密結合のコンフィギュレーションにおけるシステムの一部分であるかどうかに応じて、与えられた状況において重要なこともあり、それ故に、このリストは、例示的であり非限定的であると考えられるべきである。

プログラミングインターフェースのこの概念は、当業者には知られており、本発明の前述の詳細な説明から明らかである。しかし、プログラミングインターフェースを実装する他の方法が存在し、明示的に除外されない限り、これらはまた、本明細書に添付された特許請求の範囲によって包含されることが意図される。そのような他の方法は、図１Ｂおよび１Ｃの極度に単純化された図よりも高度または複雑であるように見えることもあるが、それらは、それにもかかわらず、同じ全体的な結果を遂行する類似した機能を実行する。本発明者等は、次にプログラミングインターフェースの一部の例示的な代替実装形態について簡単に説明することにする。

Ａ．ファクタリング（ＦＡＣＴＯＲＩＮＧ）
１つのコードセグメントから別のコードセグメントに対するコミュニケーションは、コミュニケーションを複数の離散的なコミュニケーションに分解することにより、間接的に遂行することができる。これは、図１Ｄおよび１Ｅに概略的に示される。図に示されるように、一部のインターフェースは、機能の分割可能な組の観点から説明することができる。したがって、図１Ｂおよび１Ｃのインターフェース機能は、ちょうど人が数学的に２４、または２×２×３×２を提供することができるように同じ結果を達成するためにファクタリングする（ｆａｃｔｏｒ）ことができる。したがって、図１Ｄに示されるように、インターフェース、インターフェース１によって提供されるファンクションは、同じ結果を達成しながら、再分割してインターフェースのコミュニケーションを複数のインターフェース、インターフェース１Ａ、インターフェース１Ｂ、インターフェース１Ｃなどへと変換することができる。図１Ｅに示されるように、インターフェースＩ１によって提供されるファンクションは、同じ結果を達成しながら、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに再分割することができる。同様に、第１のコードセグメントから情報を受け取る第２のコードセグメントのインターフェースＩ２は、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどへとファクタリングすることができる。ファクタリングするときに、第１のコードセグメントと共に含められるインターフェースの数は、第２のコードセグメントと共に含められるインターフェースの数と一致する必要はない。図１Ｄおよび１Ｅの場合のいずれにおいても、インターフェース、インターフェース１およびＩ１の機能的な趣旨は、それぞれ図１Ｂおよび１Ｃと同じままに留まる。インターフェースのファクタリングはまた、ファクタリングを認識することが困難なこともあるように、連想的な性質、交換可能な性質、および他の数学的性質に従うこともできる。例えば、オペレーションの順序は、重要でないこともあり、その結果、インターフェースによって実行されるファンクションは、インターフェースに到達するのに先立って、コードまたはインターフェースの別の部分によってうまく実行し、あるいはシステムの別個のコンポーネントによって実行することができる。さらに、プログラミング技術分野の当業者は、同じ結果を達成する異なるファンクションコールを行う様々な方法が存在することを認識することができる。

Ｂ．再定義
一部の場合においては、意図される結果を依然として遂行しながら、プログラミングインターフェースのある種の態様（例えば、パラメータ）を無視し、追加し、または再定義することが可能なこともある。これについては、図１Ｆおよび１Ｇに示される。例えば、図１Ｂのインターフェース、インターフェース１は、３つのパラメータ、入力、精度および出力を含み、第１のコードセグメントから第２のコードセグメントへと発行されるファンクションコール、スクエア（Ｓｑｕａｒｅ）（入力，精度，出力）を含んでいる。図１Ｆに示されるように、中間のパラメータ精度が、与えられたシナリオにおいて関係がない場合、それは、同様にただ無視し、あるいは（この状況では）意味のないパラメータと置き換えることさえできる。人はまた、関係のない追加パラメータを追加することもできる。いずれにしても、入力が第２のコードセグメントによって２乗された後に、出力が戻される限り、スクエアの機能は、達成することができる。精度は、確実にコンピューティングシステムのあるダウンストリームまたは他の部分に対する意味のあるパラメータとなり得る。しかし、ひとたび精度がスクエアを計算する狭い目的のためには必要でないことが認識されると、精度は、置き換え、または無視することができる。例えば、有効な精度値を渡す代わりに、誕生日など、意味のない値は、その結果に悪影響を及ぼすことなく渡すことができる。同様に、図１Ｇに示されるように、インターフェースＩ１は、インターフェースＩ１’によって置き換えられ、インターフェースに対するパラメータを無視または追加するために再定義される。インターフェースＩ２も同様に、インターフェースＩ２’として再定義され、不必要なパラメータ、あるいは他のどこかで処理することができるパラメータを無視するために再定義される。ここでのポイントは、一部の場合においては、プログラミングインターフェースは、ある目的のために必要とされない、パラメータなどの態様を含むことができ、それ故にそれらは、無視または再定義し、あるいは他の目的のために他のどこかで処理することができる。

Ｃ．インラインコーディング（ＩＮＬＩＮＥ ＣＯＤＩＮＧ）
それらのコードモジュールの間の「インターフェース」が形態を変更するように、２つの別個のコードモジュールの機能の一部またはすべてをマージすることも実現可能なこともある。例えば、図１Ｂおよび１Ｃの機能は、それぞれ図１Ｈおよび１Ｉの機能に変換することができる。図１Ｈにおいては、図１Ｂの以前の第１のコードセグメントと第２のコードセグメントは、それらの両方を含むモジュールにマージされる。この場合に、それらのコードセグメントは、依然として互いに情報をやり取りしていることもあるが、インターフェースは、単一のモジュールにより適した形態に適応させることができる。したがって、例えば形式的なコールステートメント（Ｃａｌｌ ｓｔａｔｅｍｅｎｔ）およびリターンステートメント（Ｒｅｔｕｒｎ ｓｔａｔｅｍｅｎｔ）が、もはや必要でないこともあり、インターフェース、インターフェース１に従った同様な処理または１つ（または複数）の応答が、依然として効力があることもある。同様に、図１Ｉに示されるように、図１ＣからのインターフェースＩ２の一部（または全部）は、インターフェースＩ１にインラインに書き込まれ、インターフェースＩ１”を形成することができる。例示されるように、インターフェースＩ２は、Ｉ２ａとＩ２ｂに分割され、インターフェース部分Ｉ２ａはインターフェースＩ１と共にインラインに符号化されて、インターフェースＩ１”を形成している。具体的な例では、図１ＣからのインターフェースＩ１は、ファンクションコール、スクエア（入力，出力）を実行し、このスクエア（入力，出力）は、インターフェースＩ２によって受け取られ、このスクエア（入力，出力）は、第２のコードセグメントによって（それを２乗する）入力と共に渡される値を処理した後に、２乗された結果を出力と共に戻して渡す。そのような場合には、第２のコードセグメント（２乗する入力）によって実行される処理は、そのインターフェースに対するコールなしに第１のコードセグメントによって実行することができる。

Ｄ．分離（ＤＩＶＯＲＣＥ）
１つのコードセグメントから別のコードセグメントへのコミュニケーションは、そのコミュニケーションを複数の離散的なコミュニケーションへと分解することにより、間接的に遂行することができる。これについては、図１Ｊおよび１Ｋに概略的に示される。図１Ｊに示されるように、１つまたは複数のミドルウェアの部分（それらが、元のインターフェースから機能および／またはインターフェースのファンクションを分離するので、１つ（または複数）の分離インターフェースという）が、第１のインターフェース、インターフェース１上のコミュニケーションを変換して、異なるインターフェース、この場合には諸インターフェース、インターフェース２Ａ、インターフェース２Ｂおよびインターフェース２Ｃに準拠させるように設けられる。これは、例えば、言わばインターフェース１プロトコルに従ってオペレーティングシステムと情報をやり取りするように設計されたインストールベースのアプリケーションが存在する場合に行われる可能性があるが、次いでそのオペレーティングシステムは、異なるインターフェース、この場合には諸インターフェース、インターフェース２Ａ、インターフェース２Ｂおよびインターフェース２Ｃを使用するように変更される。要点は、第２のコードセグメントによって使用される元のインターフェースは、それが第１のコードセグメントによって使用されるインターフェースとはもはや互換性がないように変更され、それ故に仲介手段が、古いインターフェースと新しいインターフェースを互換にするために使用されることである。同様に、図１Ｋに示されるように、第３のコードセグメントが、インターフェースＩ１からのコミュニケーションを受け取る分離インターフェースＤＩ１と、例えばＤＩ２と共に機能するように設計変更されたインターフェースＩ２ａおよびＩ２ｂへとインターフェース機能を伝送するが、同じ機能結果を実現する分離インターフェースＤＩ２と共に導入することができる。同様に、ＤＩ１およびＤＩ２は、同じまたは類似した機能結果を実現しながら、図１ＣのインターフェースＩ１およびＩ２の機能を新しいオペレーティングシステムに対して変換するように一緒に機能することができる。

Ｅ．再書込み（ＲＥＷＲＩＴＩＮＧ）
さらに別の可能性のある変形は、コードを動的に再書き込みして、インターフェース機能を何か他のもので置き換えることであるが、これは、同じ全体的な結果を達成する。例えば、中間言語（例えば、マイクロソフトのＩＬ、Ｊａｖａ（登録商標）バイトコード（ＢｙｔｅＣｏｄｅ）など）で提示されるコードセグメントが、（．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の類似したランタイムタイプの環境によって提供される環境など）実行環境中におけるジャストインタイム（Ｊｕｓｔ−ｉｎ−Ｔｉｍｅ）（ＪＩＴ）のコンパイラまたはインタープリタに供給される。ＪＩＴコンパイラは、第１のコードセグメントから第２のコードセグメントへとコミュニケーションを動的に変換するために、すなわち第２のコードセグメント（元のまたは異なる第２のコードセグメントのいずれか）によって必要とされるようにそれらを異なるインターフェースに準拠させるために書き込むことができる。これについては、図１Ｌおよび１Ｍに示される。図１Ｌから分かるように、このアプローチは、上記の分離シナリオに類似している。例えば、インストールベースのアプリケーションが、インターフェース１プロトコルに従ってオペレーティングシステムと情報をやり取りするように設計されるが、次いでそのオペレーティングシステムは、異なるインターフェースを使用するために変更される場合に、それは、行うことができる。ＪＩＴコンパイラを使用して、インストールベースのアプリケーションからの実行中のコミュニケーションをオペレーティングシステムの新しいインターフェースに準拠させることができる。図１Ｍに示されるように、１つ（または複数）のインターフェースを動的に書き換えるこのアプローチは、同様に１つ（または複数）のインターフェースを同様に動的にファクタリングし、あるいはそうでなければ変更するように適用することができる。

代替実施形態を経由してインターフェースと同じまたは類似した結果を達成するための上記のシナリオは、様々な方法で、逐次的および／または並列的に、あるいは他の介入するコードと共に、組み合わせることもできることにも注意すべきである。したがって、以上で提示された代替実施形態は、相互に排他的ではなく、混合し、マッチングさせ、組み合わせて、図１Ｂおよび１Ｃ中において提示される包括的なシナリオと同じまたは同等なシナリオを生成することができる。ほとんどのプログラミング構造と同様に、本明細書中で説明されないこともあるが、それにもかかわらず本発明の趣旨および範囲によって表されるインターフェースの同じまたは類似した機能を達成する他の類似した方法が存在することにも注意すべきであり、すなわち、それは、少なくとも部分的にはインターフェースの価値の基礎になるインターフェースによって表される機能であり、またそのインターフェースによって可能とされる有利な結果であることに注意すべきである。

図２は、グラフィックユーザインターフェースシステムに共通の従来のウィンドウ管理シナリオ２００を示している。図に示されるように、複数の開かれたアプリケーションウィンドウは、前面に位置付けられた他のより大きなウィンドウによって部分的に、または完全に見えなくされる。特に、図２は、アプリケーションウィンドウ２０３ｄが、ウィンドウ２０３ａ、２０３ｂ、および２０３ｃよりもＺ順（Ｚ−ｏｒｄｅｒ）が高くなっている、Ｚ順のコンフィギュレーションの４枚のウィンドウ２０３ａ〜２０３ｄのシナリオを示している。アプリケーションウィンドウ２０３ａ〜２０３ｄは、デスクトップスペース（ｄｅｓｋｔｏｐ ｓｐａｃｅ）２０１内に示される。

デスクトップスペース２０１は、アプリケーションプログラムに対応するウィンドウの表示を可能にするディスプレイの１つの区域である。底部にあるタスクバー２１０は、どのアプリケーションウィンドウが現在使用中であり、どれが見ることができ、または最小化されていることがあるかを示す。タスクバー２１０は、アクティブにすること、移動させること、隠すこと、最小化することなど、ウィンドウの操作をリストアップし、イネーブルにするために使用されるオンスクリーンウィンドウリモートコントロール（ｏｎ−ｓｃｒｅｅｎ ｗｉｎｄｏｗ ｒｅｍｏｔｅ ｃｏｎｔｒｏｌ）の特定の実装形態である。ウィンドウ２０３ａは、タスクバーボタン（ｔａｓｋｂａｒ ｂｕｔｔｏｎ）２１３ａによって表され、ウィンドウ２０３ｂは、タスクバーボタン２１３ｂによって表され、ウィンドウ２０３ｃは、タスクバーボタン２１３ｃによって表され、ウィンドウ２０３ｄは、タスクバーボタン２１３ｄによって表される。この例に示されるように、４つのウィンドウ２０３ａ〜２０３ｄが、開かれて示される。ウィンドウ２０３ａ〜２０３ｄのコンテンツのファイル名は、ぞれぞれのウィンドウのタイトルバー区域２２３ａ〜２２３ｄに沿って示される。これらのファイル名は、ウィンドウを動作させるアプリケーションプログラムによって生成することができ、かつ／またはユーザによってカスタマイズ化可能とすることができる。各ウィンドウ２０３ａ〜２０３ｄについての同じファイル名が、対応するタスクバーボタン２１３ａ〜２１３ｄに示される。

ウィンドウ２０３ａ〜２０３ｄは、ユーザにコンテンツを表示するためにアプリケーションプログラムによって使用される。ウィンドウ２０３ａに関連するアプリケーションプログラムは、ウィンドウ２０３ｂ、２０３ｃ、および／または２０３ｄに対応する異なるアプリケーションプログラムまたは同じアプリケーションプログラムであってもよい。ウィンドウ２０３ａ〜２０３ｄのおのおのは、他のウィンドウ２０３ａ〜２０３ｄに対して独立しており、また外部にある。本明細書中で使用されるように、第１のウィンドウは、第１のウィンドウが第２のウィンドウ内に含まれず、第２のウィンドウが第１のウィンドウ内に含まれないときに、第２のウィンドウに対して外部にある。２つのウィンドウがただオーバーラップしているにすぎない場合に、第１のウィンドウは、第２のウィンドウ内に含まれないことを理解すべきである。

図２に示されるように、ユーザは、タスクを完了するために、この組のアプリケーションウィンドウ２０３ａ〜２０３ｄを明示的に開いている。タスクは、開かれたアプリケーションウィンドウ２０３ａ〜２０３ｄのおのおのから情報またはコンテンツを取得することを必要とすることもある。例えば、このタスクは、インターネットブラウザウィンドウ（Ｉｎｔｅｒｎｅｔ ｂｒｏｗｓｅｒ ｗｉｎｄｏｗ）とグラフィックス編集アプリケーションからの２つのウィンドウを必要とすることもある。ユーザが、この第１のタスクに関連していない追加のアプリケーションウィンドウを開く場合、これらの既存のアプリケーションウィンドウ２０３ａ〜２０３ｄは、デスクトップスペース２０１中で変更されないまま留まることになる。既存のウィンドウ管理ソリューションを使用して、ユーザは、ビューからそれらのウィンドウを個別に取り除くために第１のタスクに関連するアプリケーションウィンドウ２０３ａ〜２０３ｄのおのおのを最小化することができる。元のタスクに戻るためには、ユーザは、各最小化されたアプリケーションウィンドウ２０３ａ〜２０３ｄを個別に取り出す必要があるはずである。

図３Ａに示されるように、本発明の態様によれば、ユーザインターフェースコントロール３３０が、１組の現在開かれており、かつ／またはアクティブなアプリケーションウィンドウ２０３ａ〜２０３ｄをウィンドウグループとして宣言するために設けられる。図３Ａは、本発明の少なくとも一態様による、グループ化コントロール（ｇｒｏｕｐｉｎｇ ｃｏｎｔｒｏｌ）３３０を含むウィンドウ管理システムの一例を示している。本明細書中で使用されるように、用語「宣言する」および「宣言すること」は、本明細書中ではアクションを開始して２つの独立な外部のアプリケーションウィンドウの間の関係を作成することを意味するように定義される。

シナリオ３００ａにおいては、ユーザは、アプリケーションウィンドウグループ化コントロール３３０に向かってポインタ３３１を移動させる。タスクバー区域２１０に示されているが、グループ化コントロール要素３３０は、デスクトップスペース２０１内など他のロケーションに配置することができることが、当業者によって理解されるべきである。さらに、作動可能ボタンとして図３Ａには示されているが、グループ化コントロール３３０を開始して、他の手段によるアプリケーションウィンドウをグループ化することができる。例えば、一実施形態においては、ユーザは、単一および／または一連のキー／ボタンのストロークを実行して、アプリケーションウィンドウ２０３ａ〜２０３ｄなど、複数のウィンドウをグループ化することができる。ユーザは、キーボード上であらかじめ定義された一連のキーストロークを押して、アプリケーションウィンドウをグループ化することができる。本発明の別の実施形態においては、タスクバーボタン２１３ａをタスクバーボタン２１３ｂへとクリックしドラッグして、ウィンドウ２０３ａおよびウィンドウ２０３ｂをグループ化するためのプロセスを開始することができる。さらに別の実施形態においては、ユーザは、電子的マウスなどの入力デバイス上の作動ボタンをクリックして、タスクバーボタン２１３ａおよび２１３ｂを作動させることにより直接または間接にアプリケーションウィンドウ２１３ａおよび２１３ｂをグループ化することができる。本発明は、本明細書中に含まれる例だけに限定されるものでないことが、当業者によって理解されるべきである。

図３Ａに戻ると、グループ化コントロール３３０を押し下げるとすぐに、ウィンドウ２０３ａ〜２０３ｄは、一緒にグループ化することができ、ここで次いでそのグループは、図３Ｂに示されるように、サムネイル画像３４０ａのサイズまで一括して縮小することができる。グループ化コントロール３３０の押し下げの例示の例は、図３Ｂ中のシナリオ３００ｂに示される。この例のシナリオ３００ｂにおいては、ウィンドウ２０３ａ〜２０３ｄのグループ化は、デスクトップスペース２０１中のサムネイル画像３４０ａまで縮小されている。さらに、タスクバーボタン２１３ａ〜２１３ｄが、タスクバー区域２１０から取り除かれている。この例には示されていないが、対応するタスクバーボタン２１３ａ〜２１３ｄのうちの１つまたは複数が、タスクバー区域２１０内に留まることができることを理解すべきである。

グループ化されたウィンドウは、グループの表現として一緒に管理することができ、例えば保存し、リフレッシュすることなどができる１組のウィンドウである。ウィンドウを一緒にグループ化することは、ユーザが、実行しなければならないウィンドウ管理の量を低減させ、同様にオーバーラップしたウィンドウから構成される作業表面のビジュアルクラッタ（ｖｉｓｕａｌ ｃｌｕｔｔｅｒ）も低減させる。さらに、ウィンドウのグループは、一緒に存続させ続けることができ、その結果、ウィンドウのグループは、後になってから取り出すことができる。任意のアプリケーションウィンドウは、アプリケーションウィンドウ２０３ａ〜２０３ｄのサムネイル画像３４０ａに追加し、あるいはサムネイル画像から後で取り除くことができる。

サムネイル画像３４０ａから以前に最小化されたアプリケーションウィンドウを回復させるために、ユーザは、ポインタ３３１を移動させ、アクティブにする、例えばサムネイル画像３４０ａをクリックオン（ｃｌｉｃｋ ｏｎ）することができる。ユーザがデスクトップアイコン（ｄｅｓｋｔｏｐ ｉｃｏｎ）３４０ａをクリックオンするのに応じて、ウィンドウ２０３ａ〜２０３ｄのグループ化は、グループコントロール３３０の実行に先立つそれらの状態へと回復させられる。この例においては、ウィンドウの外観は、図３Ａにおいて行ったとちょうど同じように見えるはずである。

図３Ｃは、本発明の少なくとも一態様による、グループ化コントロール３３０の実行のすぐ後でのウィンドウ管理システムの他の例を示している。図３Ｂに示されるように、シナリオ３００ｃは、アプリケーションウィンドウ２０３ａ〜２０３ｄのサムネイル画像３４０ａの代わりにあるタイプのアイコン３４０ｂとしてウィンドウ２０３ａ〜２０３ｄのグループ化を示すことができる。代わりに、かつ／または追加して、タスクバーボタン３４０ｃは、ウィンドウ２０３ａ〜２０３ｄのグループ化を表すために作成することができる。サムネイル画像３４０ａと同様に、ウィンドウ２０３ａ〜２０３ｄは、アイコン３４０ｂおよび／またはタスクバーボタン３４０ｃのアクティブ化により回復させることができる。そのような例においては、ウィンドウの外観は、この場合にもまた図３Ａにおいて行ったとちょうど同じように見えるはずである。

図４は、本発明の少なくとも一態様による、グループ化コントロール３３０の実行のすぐ後でのウィンドウ管理システムの別の例を示している。このシナリオ４００においては、一部分、例えば４つの開かれたアプリケーションウィンドウ２０３ａ〜２０３ｄのうちの３つは、１つのグループとして宣言されており、サムネイル画像４４０へと縮小されている。したがって、本発明の一実施形態においては、ユーザは、ウィンドウ２０３ｄをデスクトップスペース２１０中において開かれてアクティブのままにしながら、ウィンドウ２０３ａ〜２０３ｃをグループ化するように選択することができる。多数の異なる方法を使用して、デスクトップスペース２０１中のすべての開かれたウィンドウよりも少ないウィンドウのグループ化を可能にすることができ、本発明は、１つの任意の方法だけに限定されるものではない。タスクバーに最小化された開かれたウィンドウは、２１０であり、それはグループコントロール３３０の作動によってウィンドウグループ内に含めることもできることが、当業者によって理解されるべきである。他の実施形態においては、システムは、たとえ別の開かれたウィンドウによってオーバーラップされていたとしても、最小化された任意のウィンドウをグループ化しないまま、開かれてアクティブなウィンドウをグループ化するだけのように構成することができる。

ひとたびウィンドウグループが宣言され、サムネイル画像３４０ａへと最小化された後には、ユーザは、新しいアプリケーションウィンドウを開くこと、あるいは以前に最小化されたアプリケーションウィンドウを回復させることで再開することができる。ウィンドウグループが暗黙のうちに宣言された後に開かれたウィンドウは、第２のウィンドウグループのメンバと考えることができる。図５Ａは、ウィンドウグループ３４０ａが宣言され最小化されており、追加のアプリケーションウィンドウ５０３ａおよび５０３ｂがその後に開かれているシナリオ５００ａを示している。これらのアプリケーションウィンドウは、第２のウィンドウグループのメンバである。ウィンドウ２０３ａ〜２０３ｄと同様に、ウィンドウ５０３ａおよび５０３ｂは、タスクバー区域２１０内に対応するタスクバーボタン５１３ａおよび５１３ｂを有する。

ひとたびウィンドウグループが宣言され、最小化された後には、ユーザは、サムネイル画像３４０ａ上でダブルクリックすることやコンテキストメニュー（ｃｏｎｔｅｘｔｕａｌ ｍｅｎｕ）から「開かれたグループ」を右クリックし選択することなど、標準の既存のオープン化メカニズムを介してグループを開くことにより、そのグループを取り出すことができる。図５Ａに示されるように、ユーザは、ポインタ３３１をサムネイル画像グループ３４０ａへと移動させる。グループを開くことは、フルスクリーンにアニメ化する（ａｎｉｍａｔｉｎｇ）、サムネイル画像グループ３４０ａからのアプリケーションウィンドウ２０３ａ〜２０３ｄをもたらすが、同時に、アプリケーションウィンドウ５０３ａ〜５０３ｂは、図５Ｂに示されるサムネイル画像５４０へとアニメ化する、アプリケーションウィンドウの第２のグループ化としてシステムによって宣言される。第２のグループのウィンドウは、第１のグループのウィンドウを取り出したすぐ後に自動的に宣言することができることが、当業者によって理解されるべきである。代わりに、システムは、ユーザが第２のグループのウィンドウをアクティブに宣言する必要があるように構成することができる。

図５Ｂは、サムネイル画像３４０ａを経由して第１のウィンドウグループを開くシナリオ５００ｂを示すものである。第２のグループは、その後にサムネイル画像５４０へと最小化されており、サムネイル画像３４０ａとしての第１のグループの位置を置き換えている。ひとたびウィンドウグループが取り出された後に、通常のウィンドウの対話が効力を有する。個別のアプリケーションウィンドウは、移動させ、アクティブにし、閉じることができる。ウィンドウ５０３ａおよび５０３ｂは、別のグループのウィンドウがすでに存在していることにより、暗黙のうちにグループ化することができることを理解すべきである。したがって、ユーザは、グループコントロール３３０を２度目に作動してウィンドウ５０３ａおよび５０３ｂをグループ化する必要はない。

本発明の態様は、図に示されるウィンドウおよび／またはグループの数だけに限定されるものでないこと、ならびに任意数の異なるグループのウィンドウを作成することができることが、当業者によって理解されるべきである。さらに、本発明の様々な態様によれば、１つまたは複数のウィンドウを、ウィンドウグループに追加し、またはウィンドウグループから取り除くことができることも理解すべきである。さらに、１つのウィンドウグループ中のアプリケーションウィンドウは、別のウィンドウグループに現れることもできる。さらにまた、本発明の態様により、ウィンドウグループはマシンの開始および／またはログアウト／ログインセッションにまたがって保存し、回復させることができるようになる。

本発明の態様は、ウィンドウグループ上のウィンドウオペレーション（ｗｉｎｄｏｗｉｎｇ ｏｐｅｒａｔｉｏｎ）をサポートする。例えば、ウィンドウグループが、コンテンツを閉じ、保存し、またはリフレッシュするとすぐに作動されるコマンドは、そのグループ内のウィンドウのすべてがそのコンテンツを閉じ、保存し、またはリフレッシュするようにさせることができる。コマンドは、全体のグループに対してグローバルであっても、グループ内のウィンドウのサブセットに対して特有であっても、あるいは１つのアプリケーションウィンドウに対して特有であってもよい。ウィンドウアプリケーションが２つの別個のグループ内にあるときに、１つのグループ内のアプリケーションウィンドウ上で実行されるコマンドは、別のグループ内の同じアプリケーションウィンドウ上で同じオペレーションを実行し、あるいは実行しないように構成することができる。さらにまた、コマンドオプションは、新しいアプリケーションウィンドウが、グループに追加され、かつ／またはグループから取り除かれるときに、変化することができる。例えば、おのおのが、リフレッシュオペレーションを実行することができる２つのウィンドウを含むグループが、そのグループに追加されたそのコンテンツをリフレッシュする機能のない新しいウィンドウを有する場合、リフレッシュコマンドは、ウィンドウのグループを操作するときに、もはやユーザにとって使用可能なオプションではないこともある。グループとしてのウィンドウ上で使用するためのコマンドは、システムがどのように構成されているかに応じて、動的であっても、あるいは動的でなくてもよい。

図６は、本発明の少なくとも一態様による、複数のアプリケーションウィンドウをグループ化するための方法の例示的な一実施例のフローチャートである。プロセスは、ステップ６０１から開始され、ここで複数のアプリケーションウィンドウが開かれる。ステップ６０３において、複数の開かれたアプリケーションウィンドウをグループへと宣言する入力が受け取られる。プロセスは、ステップ６０５へと進み、ここですべての開かれたウィンドウが、一緒にグループ化されるべきであるかどうかについての判定が行われる。すべての開かれたウィンドウが一緒にグループ化されるべきである場合、プロセスは、ステップ６０７へと進み、ここで複数のウィンドウのすべてが、グループとして宣言され、次いでプロセスは、ステップ６１１へと進む。ステップ６０５の判定が、必ずしもすべての開かれたウィンドウが一緒にグループ化されるべきではないことを見出す場合には、プロセスは、ステップ６０９へと進み、ここで複数のアプリケーションウィンドウのうちの一部分が、グループとして宣言され、プロセスは、ステップ６１１へと進む。ステップ６１１において、アプリケーションウィンドウのグループの表現が表示される。ステップ６１１において表示されるウィンドウの表現と共に、プロセスは、終了することができる。ステップ６１１は、サムネイル画像３４０ａなどのサムネイル画像、アイコン３４０ｂなどのアイコン、および／またはタスクバーボタン３４０ｃなどのタスクバーボタンであってもよいことが、理解されるべきである。

プロセスは、ステップ６１３へと続くこともでき、ここで、その表現中においてアプリケーションウィンドウのグループ上でオペレーションを実行する入力が受け取られているかどうかについての判定が行われる。１タイプのオペレーションは、アプリケーションウィンドウのコンテンツを表現内に保存するオペレーションを含むことができる。入力が受け取られていない場合、プロセスは終了する。ステップ６１３において入力が受け取られている場合には、プロセスは、ステップ６１５へと進み、ここでオペレーションは、グループ内のアプリケーションウィンドウ上で実行される。コンテンツを保存するそのようなケースでは、オペレーションがグローバルである場合、各アプリケーションウィンドウのコンテンツが保存される。代わりに、オペレーションが、アプリケーションウィンドウのサブセット、またはグループ内の単一のアプリケーションウィンドウを対象としている場合、オペレーションは、オペレーションが対象としていたサブセット上、または１つのウィンドウ上だけで実行される。

ステップ６１５から、プロセスは、ステップ６１７へと進み、ここでアプリケーションウィンドウをグループから取り出す入力が受け取られているかどうかについての判定が行われる。例えば、ユーザは、ユーザが、アプリケーションウィンドウをそれらの元の状態に回復させることを望むことを決定することができる。入力が受け取られていない場合、プロセスは終了する。ステップ６１７において入力が受け取られている場合には、プロセスは、ステップ６１９へと進み、ここでアプリケーションウィンドウは、デスクトップスペース中においてそれらの元の状態へと回復させられ、プロセスは終了する。

図７は、本発明の少なくとも一態様による、ウィンドウの複数のグループ化の間で切り換えるための方法の例示的な一実施例のフローチャートである。プロセスは、ステップ７０１から開始され、ここで複数のアプリケーションウィンドウが開かれる。ステップ７０３において、複数の開かれたアプリケーションウィンドウをグループへと宣言する入力が受け取られる。ステップ７０５において、アプリケーションウィンドウは、第１のグループとして宣言される。ステップ７０７へと進んで、第１のグループのアプリケーションウィンドウの表現が表示される。

ステップ７０９において、少なくとも１つの新しいアプリケーションウィンドウを開く入力が受け取られる。ステップ７１１において、少なくとも１つの新しいアプリケーションウィンドウが開かれる。少なくとも１つの新しいアプリケーションウィンドウは、第１のグループのアプリケーションウィンドウと同じアプリケーションウィンドウであってもよいことが理解されるべきである。ステップ７１１からは、ステップ７１３〜７２１についての実線によって定義されるように、またステップ７２３〜７２９についての破線によって定義されるように、プロセス中の２つの進行のうちの一方が行われることができる。第１の進行中に示されるように、ステップ７１１から、プロセスはステップ７１３へと進み、ここで少なくとも１つの新しいアプリケーションウィンドウをグループへと宣言する入力が受け取られる。ステップ７１５において、少なくとも１つの新しいアプリケーションウィンドウは、第２のグループとして宣言される。ステップ７１７へと進んで、第２のグループの少なくとも１つのアプリケーションウィンドウの表現が表示される。ステップ７１９において、選択された第１または第２のグループから１つ（または複数）のアプリケーションウィンドウを取り出す入力が受け取られているかどうかについての判定が行われる。受け取られていない場合、プロセスは、選択が行われ受け取られるまで待つ。ステップ７１９において入力が受け取られている場合、プロセスは、ステップ７２１へと進み、ここで選択されたグループの１つ（または複数）のアプリケーションウィンドウは、デスクトップスペース中においてそれらの元の状態へと回復させられ、プロセスは終了する。

諸ステップの間の破線によって定義される第２の進行中に示されるように、ステップ７１１から、プロセスは、ステップ７２３へと進み、ここで第１のグループからアプリケーションウィンドウを取り出す入力が受け取られているかどうかについての判定が行われる。受け取られていない場合、プロセスは、入力が受け取られるまで待つ。ステップ７２３において入力が受け取られている場合には、プロセスは、ステップ７２５へと進み、ここでシステムは、デスクトップスペース中の少なくとも１つの新しいアプリケーションウィンドウを第２のグループへと自動的に宣言する。ユーザが、第１のグループのアプリケーションウィンドウへと戻ることを決定しているので、システムは、暗黙のうちに新しい１つ（または複数）のアプリケーションウィンドウを新しいグループへとグループ化する。プロセスは、ステップ７２７へと進み、ここで第２のグループのアプリケーションウィンドウの表現が表示される。ステップ７２９において、第１のグループのアプリケーションウィンドウは、デスクトップスペース中においてそれらの元の状態へと回復させられ、プロセスは終了する。ユーザは、上記のステップのうちの１つまたは複数のステップに従うことにより、必要に応じてアプリケーションウィンドウのグループの間で切り換えることができることが、当業者によって理解されるべきである。

別の実施形態は、直接にグループへの、ウィンドウの宣言およびグループ化をプログラムにより制御している。例えば、マイクロソフトオフィス（Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ）など１つまたは複数のアプリケーションは、いくつかのドキュメントから構成されるプロジェクトの概念を共有することができる。これらのドキュメントは、プロジェクト中の新しいドキュメントがユーザによって開かれるときに、同時に１つのグループ中へと開き、あるいはグループに自動的に追加することができる。

アプリケーションプログラミングインターフェース（ＡＰＩ）に関しては、本発明の様々な態様をＡＰＩによって実行することができる。例えば、公開ＡＰＩは、オペレーティングシステムが本発明の様々な特徴を実現することができるようにオペレーティングシステムとインターフェースすることができる。一実施形態においては、グループ化されたウィンドウのデータ表現を処理するためのソフトウェアアーキテクチャは、第１の開かれたウィンドウと第２の開かれたウィンドウとを１つのグループへとグループ化するように構成されたコンポーネントと、そのコンポーネントにアクセスするアプリケーションプログラムインターフェースとを含むことができる。ＡＰＩは、２つのウィンドウをグループ化し、オペレーションを実行する必要な１つ（または複数）のファンクションにアクセスし、次いでそれらの結果をオペレーティングシステムに返送する要求を受け取ることができる。オペレーティングシステムは、ＡＰＩから供給されるデータを使用して、本発明の様々な特徴を実施することができる。

アプリケーションプログラムにウィンドウグループをうまく利用させるＡＰＩは、プログラムによりウィンドウをグループ化すること、および非グループ化すること、ならびにコマンドがグループ上で実装されるときに、アプリケーションプログラムに、保存する、印刷する、コンテンツをリフレッシュする、バージョンを比較する、ソースコードをコンパイルするなど、どのようにしてウィンドウの状態が処理されるかを指定させることを含んでいる。この状態情報により、グループ中のアプリケーションプログラムのウィンドウは、グループが取り出され、対応するアプリケーションウィンドウが回復させられるときにデフォルトの代わりに、ある適切な状態に回復させることができるようになる。例えば、あるグループに宣言された最小化されたウィンドウは、元の状態に回復させることができる。

本発明の様々な態様を実施する、本明細書中で説明される例示のシステムおよび方法が示されているが、本発明は、これらの実施形態だけに限定されるものではないことが当業者には理解されよう。当業者によって特に前述の教示の観点から修正を行うことができる。例えば、前述の実施形態の各要素は、単独で、または組み合わせて、あるいは他の実施形態の要素と部分的に組み合わせて利用することができる。本発明の趣旨および範囲を逸脱することなく、修正を行うことができることも認識され理解されよう。したがって本明細書は、本発明に対して限定的である代わりに例示的なものとみなされるべきである。

本発明のある種の態様を実装することができる汎用デジタルコンピューティング環境の概略図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。 従来のウィンドウ管理シナリオを示す図である。 本発明の少なくとも一態様による、グループ化コントロールを含むウィンドウ管理システムの一例を示す図である。 本発明の少なくとも一態様による、グループ化コントロールの実行直後のウィンドウ管理システムの一例を示す図である。 本発明の少なくとも一態様による、グループ化コントロールの実行直後のウィンドウ管理システムの他の例を示す図である。 本発明の少なくとも一態様による、グループ化コントロールの実行直後のウィンドウ管理システムの別の例を示す図である。 諸ウィンドウの複数のグループ化が、本発明の少なくとも一態様に従って示されるウィンドウ管理システムの別の例を示す図である。 本発明の少なくとも一態様による、ウィンドウの第１のグループ化の再オープン化直後の図５Ａのウィンドウ管理システムの一例を示す図である。 本発明の少なくとも一態様による、２つのウィンドウをグループ化するための方法の例示的な一実施例のフローチャートである。 本発明の少なくとも一態様による、ウィンドウの複数のグループ化の間で切り換えるための方法の例示的な一実施例のフローチャートである。

Claims (20)

1. 複数のアプリケーションウィンドウをグループ化するための方法であって、
   第１のアプリケーションウィンドウと、前記第１のアプリケーションウィンドウと独立しており外部に存在する第２のアプリケーションウィンドウとをディスプレイ画面上に表示するステップと、
   前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを１つのグループとして宣言するステップと、
   前記第１のアプリケーションウィンドウと前記第２のウィンドウとを１つのグループへとグループ化するステップと、
   前記グループを前記ディスプレイ画面上で表現として表示するステップと
   を含むことを特徴とする方法。
2. 前記グループ上でオペレーションを実行するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 実行する前記ステップは、入力デバイスからのコマンドの受け取りに基づくことを特徴とする請求項２に記載の方法。
4. 動作を実行する前記ステップは、前記グループの前記アプリケーションウィンドウのサブセット上で実行されることを特徴とする請求項２に記載の方法。
5. 前記第１のアプリケーションウィンドウは、第１のアプリケーションプログラムに対応し、前記第２のアプリケーションウィンドウは、第２のアプリケーションプログラムに対応することを特徴とする請求項１に記載の方法。
6. 前記第１のアプリケーションプログラムと前記第２のアプリケーションプログラムとは、異なるアプリケーションプログラムであることを特徴とする請求項５に記載の方法。
7. 前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記グループから取り出す入力を受け取るステップと、
   前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記ディスプレイ画面上で元の状態へと回復させるステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
8. 宣言する前記ステップは、前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとをグループ化する入力を入力デバイスから受け取るステップを含むことを特徴とする請求項１に記載の方法。
9. 前記表現は、前記ディスプレイ画面のデスクトップスペース中に表示される前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとの縮小されたバージョンのサムネイル画像であることを特徴とする請求項１に記載の方法。
10. 前記表現は、前記ディスプレイ画面上のタスクバー区域内のタスクバーボタンであることを特徴とする請求項１に記載の方法。
11. 少なくとも１つの第３のアプリケーションウィンドウを表示するステップと、
    前記少なくとも１つの第３のアプリケーションウィンドウを１つのグループとして宣言するステップと、
    前記少なくとも１つの第３のアプリケーションウィンドウを第２のグループへとグループ化するステップと、
    前記第２のグループを前記ディスプレイ画面上で第２の表現として表示するステップと
    をさらに含むことを特徴とする請求項１に記載の方法。
12. 前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記グループから取り出す入力を受け取るステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記ディスプレイ画面上で元の状態に回復させるステップと
    をさらに含むことを特徴とする請求項１１に記載の方法。
13. 前記少なくとも１つの第３のアプリケーションウィンドウを前記第２のグループから取り出す入力を受け取るステップと、
    前記少なくとも１つの第３のアプリケーションウィンドウを前記ディスプレイ画面上で元の状態に回復させるステップと
    をさらに含むことを特徴とする請求項１１に記載の方法。
14. 少なくとも１つの第３のアプリケーションウィンドウを表示するステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記グループから取り出す入力を受け取るステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記ディスプレイ画面上で元の状態に回復させるステップと、
    前記入力を受け取ることに応じて前記少なくとも１つの第３のアプリケーションウィンドウを第２のグループへとグループ化するステップと、
    前記第２のグループを前記ディスプレイ画面上で第２の表現として表示するステップと
    をさらに含むことを特徴とする請求項１に記載の方法。
15. 複数のアプリケーションウィンドウをグループ化するための一連のコンピュータ実行可能命令を含むコンピュータ読取り可能媒体であって、前記命令は、
    第１のアプリケーションウィンドウと、前記第１のアプリケーションウィンドウと独立しており外部に存在する第２のアプリケーションウィンドウとをディスプレイ画面上で表示するステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを１つのグループとして宣言するステップと、
    前記第１のアプリケーションウィンドウと前記第２のウィンドウとを１つのグループへとグループ化するステップと、
    前記グループを前記ディスプレイ画面上で表現として表示するステップと
    を実行することを特徴とするコンピュータ読取り可能媒体。
16. 前記命令は、さらに
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記グループから取り出す入力を受け取るステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記ディスプレイ画面上で元の状態へと回復させるステップと
    を実行することを特徴とする請求項１５に記載のコンピュータ読取り可能媒体。
17. 前記命令は、さらに
    少なくとも１つの第３のアプリケーションウィンドウを表示するステップと、
    前記少なくとも１つの第３のアプリケーションウィンドウを１つのグループとして宣言するステップと、
    前記少なくとも１つの第３のアプリケーションウィンドウを第２のグループへとグループ化するステップと、
    前記第２のグループを前記ディスプレイ画面上で第２の表現として表示するステップと
    を実行することを特徴とする請求項１５に記載のコンピュータ読取り可能媒体。
18. 前記命令は、さらに
    少なくとも１つの第３のアプリケーションウィンドウを表示するステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記グループから取り出す入力を受け取るステップと、
    前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとを前記ディスプレイ画面上で元の状態に回復させるステップと、
    前記入力を受け取ることに応じて前記少なくとも１つの第３のアプリケーションウィンドウを第２のグループへとグループ化するステップと、
    前記第２のグループを前記ディスプレイ画面上で第２の表現として表示するステップと
    を実行することを特徴とする請求項１５に記載のコンピュータ読取り可能媒体。
19. グループ化されたウィンドウを表すデータを処理するためのソフトウェアアーキテクチャであって、
    第１のアプリケーションウィンドウと第２のアプリケーションウィンドウとを前記第１のアプリケーションウィンドウと前記第２のアプリケーションウィンドウとのサムネイル画像を表すグループへとグループ化するように構成される少なくとも１つのコンポーネントと、
    前記コンポーネントにアクセスする少なくとも１つのアプリケーションプログラムインターフェースと
    を備えることを特徴とするソフトウェアアーキテクチャ。
20. ログアウトセッション中に前記グループの保存することをプログラムにより制御するように構成される少なくとも１つのコンポーネントをさらに備えることを特徴とする請求項１９に記載のソフトウェアアーキテクチャ。

Images