(57)【要約】  複数のアプリケーションウインドウ表現を管理するための方法を説明する。本方法は、事前定義された領域内でアプリケーションウインドウ表現位置セットを定義するステップと、それらのアプリケーションウインドウ表現位置において複数のアプリケーションウインドウ表現を表示するステップと、第１のアプリケーションウインドウを開く入力を受け取るステップと、事前定義された領域内で第１のアプリケーションウインドウ表現を作成するステップと、それら複数のアプリケーションウインドウ表現の第２のアプリケーションウインドウ表現が、隠されたアプリケーションウインドウ表現位置に再配置される必要があるかどうかを判定するステップと、第２のアプリケーションウインドウ表現が再配置される必要があると判定されると、第２のアプリケーションウインドウ表現を、グロム内にある隠されたアプリケーションウインドウ表現位置に再配置するステップとを含む。
2008535084.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションウインドウ表現を管理する方法であって、
事前定義された領域内で、事前定義された数の目に見えるアプリケーションウインドウ表現位置におけるフォーマットに基づいてアプリケーションウインドウ表現を配置するように構成されたアプリケーションウインドウ表現位置セットを定義するステップと、
前記アプリケーションウインドウ表現位置において、アプリケーションウインドウにそれぞれが関連する前記複数のアプリケーションウインドウ表現を表示するステップと、
第１のアプリケーションウインドウを開く入力を受け取るステップと、
前記事前定義された領域内で、前記フォーマットに基づいて前記セット内の位置を占める、前記第１のアプリケーションウインドウに関連する第１のアプリケーションウインドウ表現を作成するステップと
前記複数のアプリケーションウインドウ表現の第２のアプリケーションウインドウ表現が、隠されたアプリケーションウインドウ表現位置に再配置される必要があるかどうかを判定するステップと、
前記第２のアプリケーションウインドウ表現が再配置される必要があると判定されると、前記第２のアプリケーションウインドウ表現を、前記隠されたアプリケーションウインドウ表現に再配置するステップとを含み、
前記隠されたアプリケーションウインドウ表現位置は、グロム内にあることを特徴とする方法。
【請求項２】
前記フォーマットは、アプリケーションウインドウタイルが、どれだけ新しく使用されたかによって定義されることを特徴とする請求項１に記載の方法。
【請求項３】
前記隠されたアプリケーションウインドウ表現は、前記隠されたアプリケーションウインドウ表現を表示する入力が受け取られると、目に見えるようになることを特徴とする請求項１に記載の方法。
【請求項４】
目に見えるアプリケーションウインドウ表現位置を占める、第３のアプリケーションウインドウに関連する第３のアプリケーションウインドウ表現が、前記グロム内のアプリケーションウインドウ表現の数を識別するカウンタを含むように構成されることを特徴とする請求項１に記載の方法。
【請求項５】
前記第３のアプリケーションウインドウは、複数ドキュメントインタフェース親アプリケーションウインドウであることを特徴とする請求項４に記載の方法。
【請求項６】
前記グロム内の前記アプリケーションウインドウ表現は、複数ドキュメントインタフェース子アプリケーションウインドウであることを特徴とする請求項５に記載の方法。
【請求項７】
第３のアプリケーションウインドウ表現を、前記アプリケーションウインドウ表現位置セット内の異なる位置に再配置するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記第１のアプリケーションウインドウ表現の位置は、最近に使用された位置であることを特徴とする請求項１に記載の方法。
【請求項９】
前記事前定義された領域は、オーバーフロー表現を含むように構成されることを特徴とする請求項１に記載の方法。
【請求項１０】
前記オーバーフロー表現は、前記セット内にではなく、アプリケーションウインドウ表現を表示するように構成されることを特徴とする請求項９に記載の方法。
【請求項１１】
前記オーバーフロー表現は、前記オーバーフロー表現内に前記アプリケーションウインドウ表現を表示する入力が受け取られると、そのことを表示するように構成されることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記オーバーフロー表現は、前記オーバーフロー表現内の前記アプリケーションウインドウ表現の数を表す視覚的指示を含むように構成されることを特徴とする請求項９に記載の方法。
【請求項１３】
請求項１に記載のステップを実行するための一連のコンピュータ実行可能命令を含むことを特徴とするコンピュータ可読媒体。
【請求項１４】
アプリケーションウインドウに関連する通知を表示する方法であって、
ディスプレイスクリーンの事前定義された領域内の目に見えるアプリケーションウインドウ表現位置に、第１のアプリケーションウインドウ表現を表示するステップと、
前記第１のアプリケーションウインドウ表現に関連するグロム内の隠されたアプリケーションウインドウ表現位置内に、第２のアプリケーションウインドウ表現を保つステップと、
前記第２のアプリケーションウインドウ表現に関連する通知を受け取るステップと、
前記第２のアプリケーションウインドウ表現を、前記隠されたアプリケーションウインドウ表現位置から、前記ディスプレイスクリーンの前記事前定義された領域内の第２の目に見えるアプリケーションウインドウ表現位置に再配置するステップとを含むことを特徴とする方法。
【請求項１５】
前記第１のアプリケーションウインドウ表現は、前記グロム内のアプリケーションウインドウ表現の数を表す視覚的指示を含むように構成されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記視覚的指示は、カウンタであり、前記カウンタを１だけ減分するステップをさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記第２のアプリケーションウインドウ表現は、前記ディスプレイスクリーンの前記事前定義された領域内の最近に使用された位置に再配置されることを特徴とする請求項１４に記載の方法。
【請求項１８】
前記第１のアプリケーションウインドウ表現は、前記ディスプレイスクリーンの前記事前定義された領域内で再配置されることを特徴とする請求項１７に記載の方法。
【請求項１９】
請求項１４に記載のステップを実行するための一連のコンピュータ実行可能命令を含むことを特徴とするコンピュータ可読媒体。
【請求項２０】
第１のアプリケーションウインドウ表現および第２のアプリケーションウインドウ表現をグロムの中に配置するように構成された少なくとも１つのコンポーネントと、
前記コンポーネントにアクセスする少なくとも１つのアプリケーションプログラムインタフェースとを含むことを特徴とする、グロムされたアプリケーションウインドウ表現を表すデータを処理するためのソフトウェアアーキテクチャ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、オペレーティングシステムにおけるアプリケーションウインドウグラフィカルインタフェースに関し、より詳細には、オペレーティングシステムにおける複数のアプリケーションウインドウ表現をグループ化して、アプリケーションウインドウ表現の間でインテリジェントな振舞いが存在することを可能にする方法およびシステムに関する。
【背景技術】
【０００２】
仕事においても、私生活においてもともにコンピュータの使用が増大するにつれ、コンピュータのより容易な使用を可能にする要望も高まっている。今日の多くのオペレーティングシステムは、ウインドウベースのアプリケーションプログラム構成を利用する。情報は、数枚の紙のように見える物でディスプレイスクリーン上に表示される。ウインドウとインタフェースをとることにより、ユーザは、あたかも１枚の紙をつかむかのように、任意のウインドウにアクセスすることができる。ウインドウベースの構成は、ユーザが、ディスプレイスクリーン上に同時に２つ以上のウインドウを開かせることを可能にする。
【０００３】
アプリケーションウインドウは、すべてのＧＵＩ（グラフィカルユーザインタフェース）システムのユーザインタフェース機構である。アプリケーションウインドウは、複数のシステムにわたって外観が異なる可能性がある一方で、サイズ変更および再配置を行うことが可能であることや、異なるアプリケーションに関連する、他のアプリケーションウインドウの間で存在することが可能であることなどの、多くの共通の属性を共有する。多くのＧＵＩシステムでは、開かれたアプリケーションウインドウのそれぞれに関して、事前定義された領域内に、タスクバーなどの表現が存在する。その表現は、特定のアプリケーションウインドウを迅速に探し出し、かつ／または特定のアプリケーションウインドウにアクセスするために、ユーザによって使用されることが可能な参照案内である。
【０００４】
最新のＧＵＩにおける一般的なユーザ対話シナリオには、共通のスクリーンスペースを共有する複数の同時に開かれたアプリケーションウインドウが関わる。複数の同時に開かれたアプリケーションウインドウのサポートは、最新のＧＵＩの魅力および能力の一部であるが、これにより、しばしば、アプリケーションウインドウが重なり合い、互いを見えにくくすることがもたらされ、ユーザが、特定のアプリケーションウインドウを探し出す、または特定のアプリケーションウインドウに移動するのを困難にする。以上のタイプのシナリオおよび関連する問題解決法は、一般に、ウインドウ管理の問題および問題解決法と呼ばれる。
【０００５】
ユーザは、通常、アプリケーションウインドウを電子メールなどのタスクに関連付け、複数のアプリケーションウインドウと単一のタスクまたはプロジェクトとの間の心的な関連付けをさらに作成することができる。例えば、スライドショープレゼンテーションを作成するため、ユーザは、場合により、電子メール、グラフィックスアプリケーション、およびスプレッドシートアプリケーションなどの１つまたは複数のアプリケーションからの、３つまたは４つの異なるアプリケーションウインドウからのコンテンツを必要とする可能性がある。複数のアプリケーションウインドウを、スクリーン上で見ることが可能であり、各アプリケーションウインドウを、１つまたは複数のタスクに関連させることが可能である。ユーザは、コンテンツにアクセスして、またはコンテンツを交換して、タスクを完了させるために、それらの異種のアプリケーションウインドウを探し出し、それらのウインドウの間で移動しなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
多くのＧＵＩにおいて、アプリケーションウインドウが、最小化され、主要な作業スクリーンスペースにおける表示から取り除かれることが可能である、一般的なウインドウ管理問題解決法が存在する。最小化されたアプリケーションウインドウは、通常、大幅に小さいＵＩ要素によって表現される。本件特許出願人によるＷｉｎｄｏｗｓ（登録商標）  ＸＰでは、最小化されたアプリケーションウインドウは、タスクバーコントロールなどの、コントロールバー上のアプリケーションウインドウタイルとして表現される。カリフォルニア州クパチーノ在のアップルコンピュータ社によるＭａｃ  ＯＳ  Ｘでは、最小化されたアプリケーションウインドウは、Ｄｏｃｋにおけるミニチュアサムネイルボタンとして表現される。アプリケーションウインドウを最小化することにより、ユーザが、不要なアプリケーションウインドウをスクリーンスペースから取り除くことが可能になり、ユーザが、アプリケーションウインドウの、より小さいセットに注目することが可能になる。しかし、タスクバー領域においてアプリケーションウインドウ表現にアクセスすることによりアプリケーションウインドウを取得しようと試みる際、必要とされる表現は、それほど重要でない表現がユーザの目に入る場合、しばしば、グロム（gloms）の中に埋もれてしまう。
【課題を解決するための手段】
【０００７】
ディスプレイスクリーンの事前定義された領域内で複数のアプリケーションウインドウ表現を管理することを支援するウインドウ管理システムを提供する必要性が存在する。本発明の諸態様は、複数のアプリケーションウインドウ表現を管理するための新たな方法を提供する。その方法は、事前定義された領域内でアプリケーションウインドウ表現位置セットを定義するステップと、それらのアプリケーションウインドウ表現位置において複数のアプリケーションウインドウ表現を表示するステップとを含む。第１のアプリケーションウインドウを開く入力を受け取ると、その方法は、事前定義された領域内で第１のアプリケーションウインドウ表現を作成し、それら複数のウインドウ表現の第２のアプリケーションウインドウ表現が、隠されたアプリケーションウインドウ表現位置に再配置される必要があるかどうかを判定し、第２のアプリケーションウインドウ表現が再配置される必要があると判定されると、第２のアプリケーションウインドウ表現を、グロム内にある隠されたアプリケーションウインドウ表現位置に再配置する。
【０００８】
本発明の別の態様は、アプリケーションウインドウに関連する通知を表示するための方法を提供する。この方法は、ディスプレイスクリーンの事前定義された領域内の目に見えるアプリケーションウインドウ表現位置に第１のアプリケーションウインドウ表現を表示するステップと、隠されたアプリケーションウインドウ表現位置内に第２のアプリケーションウインドウ表現を保つステップとを含み、グロム内の隠されたアプリケーションウインドウ表現位置は、第１のアプリケーションウインドウ表現に関連する。また、この方法は、第２のアプリケーションウインドウに関連する通知を受け取るステップと、隠されたアプリケーションウインドウ表現位置から、ディスプレイスクリーンの事前定義された領域内の第２の目に見えるアプリケーションウインドウ表現位置に、第２のアプリケーションウインドウ表現を再配置するステップも含む。
【０００９】
本発明の以上の概要、および例示的な諸実施形態の以下の詳細な説明は、主張される発明に関して、例として、限定としてではなく含められる、添付の図面と併せて読むことでよりよく理解されるだろう。
【発明を実施するための最良の形態】
【００１０】
様々な例示的な実施形態についての以下の説明では、本明細書の一部を成し、例示として、本発明が実施されることが可能な様々な実施形態が示される添付の図面を参照する。本発明の範囲を逸脱することなく、他の諸実施形態を利用することが可能であり、構造上および機能上の変更が行われることが可能であるものと理解されたい。
【００１１】
図１Ａは、本発明を実施することが可能である、適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の用途または機能の範囲について、何ら限定を示唆することは意図していない。また、コンピューティングシステム環境１００が、例示的なコンピューティングシステム環境１００に例示される、いずれのコンポーネント、またはコンポーネントの組合せと関連する依存関係も、要件も有すると解釈してはならない。
【００１２】
本発明は、他の多数の汎用または専用のコンピューティングシステム環境またはコンピューティングシステム構成で機能する。本発明で使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスもしくはラップトップデバイス、マイクロプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれるが、以上には限定されない。
【００１３】
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈において説明することが可能である。一般に、プログラムモジュールには、特定のタスクを実行する、または特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。また、本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散コンピューティング環境において実行されることも可能である。分散コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含むローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体の両方の中に配置することが可能である。
【００１４】
図１Ａを参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形態の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、処理装置１２０、システムメモリ１３０、ならびにシステムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１が含まれることが可能であるが、以上には限定されない。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含め、いくつかのタイプのバス構造のいずれであってもよい。例として、限定としてではなく、そのようなアーキテクチャには、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびメザニン（Mezzanine）バスとしても知られるＰＣＩ（Peripheral component Interconnect）バスが含まれる。
【００１５】
コンピュータ１１０は、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０がアクセスすることができる任意の利用可能な媒体であることが可能であり、揮発性媒体と不揮発性媒体、取外し可能な媒体と取外し不可能な媒体がともに含まれる。例として、限定としてではなく、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含む。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の格納のために任意の方法または技術で実装される、揮発性媒体および不揮発性媒体、取外し可能な媒体および取外し不可能な媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読取り専用メモリ）、ＥＥＰＲＯＭ（電子的に消去可能なプログラマブル読取り専用メモリ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタルバーサタイルディスク）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは所望の情報を格納するのに使用することができ、コンピュータ１１０がアクセスすることができる他の任意の媒体が含まれるが、以上には限定されない。通信媒体は、通常、搬送波などの被変調データ信号、または他のトランスポート機構において、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実体化し、あらゆる情報配信媒体を含む。「被変調データ信号」という用語は、信号内に情報を符号化するような形で特性の１つまたは複数が設定または変更されている信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。また、以上のいずれかの媒体の組合せも、コンピュータ可読媒体の範囲内に含められなければならない。
【００１６】
システムメモリ１３０は、ＲＯＭ１３１やＲＡＭ１３２などの揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動中などに、コンピュータ１１０内部の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（基本入出力システム）１３３が、通常、ＲＯＭ１３１の中に格納される。ＲＡＭ１３２は、通常、処理装置１２０が、即時にアクセスすることができ、かつ／または現在処理しているデータおよび／またはプログラムモジュールを含む。例として、限定としてではなく、図１Ａは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００１７】
また、コンピュータ１１０は、他の取外し可能な／取外し不可能な、揮発性／不揮発性のコンピュータ記憶媒体も含むことが可能である。単に例として、図１Ａは、取外し不可能な不揮発性の磁気媒体に対して読み取りまたは書き込みを行うハードディスクドライブ１４１、取外し可能な不揮発性の磁気ディスク１５２に対して読み取りまたは書き込みを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭまたは他の光学媒体などの取外し可能な不揮発性の光ディスク１５６に対して読み取りまたは書き込みを行う光ディスクドライブ１５５を示す。例示的な動作環境において使用することができる、他の取外し可能な／取外し不可能な、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、以上には限定されない。ハードディスクドライブ１４１は、通常、インタフェース１４０のような取外し不可能なメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インタフェース１５０のような取外し可能なメモリインタフェースでシステムバス１２１に接続される。
【００１８】
前述した図１Ａに示すドライブ群、および関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージをコンピュータ１１０に提供する。図１Ａでは、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているものとして示されている。以上のコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同一であることも、異なることも可能であることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７に、ここでは、少なくともそれらが異なるコピーであることを示すように、異なる符号が与えられている。ユーザは、デジタルカメラ１６３、キーボード１６２、ならびにマウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力デバイスを介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）には、ペン、スタイラス及びタブレット、マイク、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどが含まれることが可能である。以上、およびその他の入力デバイスは、しばしば、システムバス１２１に結合されたユーザ入力インタフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（ユニバーサルシリアルバス）などの、他のインタフェースおよびバス構造で接続されてもよい。また、モニタ１９１、または他のタイプのディスプレイデバイスが、ビデオインタフェース１９０のようなインタフェースを介して、システムバス１２１に接続されることも可能である。モニタに加え、コンピュータは、出力周辺インタフェース１９５を介して接続されることが可能な、スピーカ１９７やプリンタ１９６などの、他の周辺出力デバイスも含むことが可能である。
【００１９】
コンピュータ１１０は、リモートコンピュータ１８０のような１つまたは複数のリモートコンピュータに対する論理接続を使用する、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードであることが可能であり、通常、コンピュータ１１０に関連して前述した要素の多く、またはすべてを含むが、メモリストレージデバイス１８１だけが、図１Ａに示されている。図１Ａに示す論理接続には、ＬＡＮ（ローカルエリアネットワーク）１７１およびＷＡＮ（ワイドエリアネットワーク）１７３が含まれるが、他のネットワークも含むことが可能である。そのようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。
【００２０】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、ネットワークインタフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、通常、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２、または他の手段を含む。内部にあることも、外部にあることも可能なモデム１７２は、ユーザ入力インタフェース１６０、または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはプログラムモジュールの諸部分は、リモートメモリストレージデバイスの中に格納することができる。例として、限定としてではなく、図１Ａは、リモートアプリケーションプログラム１８５が、メモリデバイス１８１上に存在するものとして示す。図示したネットワーク接続は、例示的であり、コンピュータ間で通信リンクを確立する他の手段も使用できることを理解されたい。
【００２１】
図示したネットワーク接続は、例示的であり、コンピュータ間で通信リンクを確立する他の手段も使用できることを理解されたい。ＴＣＰ／ＩＰ、イーサネット（登録商標）、ＦＴＰ、ＨＴＴＰなどの、様々な周知のプロトコルのいずれかの存在が想定され、システムは、ユーザが、ＷｅｂベースのサーバからＷｅｂページを取得することを可能にするように、クライアント−サーバ構成において動作することが可能である。様々な従来のＷｅｂブラウザのいずれかを使用して、Ｗｅｂページ上のデータを表示し、操作することが可能である。
【００２２】
プログラミングインタフェース（または、より単純には、インタフェース）は、１つまたは複数のコードセグメント（segment(s) of code）が、他の１つまたは複数のコードセグメントによって提供される機能と対話する、またはそのような機能にアクセスすることができるようにするための任意の機構、プロセス、プロトコルと考えることが可能である。代替として、プログラミングインタフェースは、他のコンポーネントの１つまたは複数の機構、メソッド、ファンクションコール、モジュールなどと通信するように結合することができるシステムのコンポーネントの１つまたは複数の機構、メソッド、ファンクションコール、モジュール、オブジェクトなどと考えてもよい。前文における「コードセグメント」という用語は、適用される用語法にかかわらず、またはコードセグメントが別個にコンパイルされるかどうか、またはコードセグメントがソースコードとして提供されるか、中間コードとして提供されるか、またはオブジェクトコードとして提供されるか、コードセグメントがランタイムシステムまたはランタイムプロセスにおいて利用されるかどうか、またはコードセグメントが同一のマシン上に配置されるか、異なるマシン上に配置されるか、または複数のマシンにわたって分散されるか、またはコードセグメントによって表される機能が、完全にソフトウェアで実施されるか、完全にハードウェアで実施されるか、ハードウェアとソフトウェアの組合せで実施さるかにかかわらず、１つまたは複数の命令またはコードラインを含むものとされ、例えば、コードモジュール、オブジェクト、サブルーチン、ファンクションなどが含まれる。
【００２３】
概念上、プログラミングインタフェースは、図１Ｂまたは図１Ｃに示されるように、一般的に考えることが可能である。図１Ｂは、第１のコードセグメントと第２のコードセグメントが通信するパイプ（conduit）としてのインタフェース、Ｉｎｔｅｒｆａｃｅ１を示す。図１Ｃは、インタフェースオブジェクトＩ１とインタフェースオブジェクトＩ２と（これらは、第１のコードセグメントおよび第２のコードセグメントの一部であっても、そうでなくてもよい）を含むものとしてインタフェースを示し、オブジェクトＩ１およびＩ２は、システムの第１のコードセグメントと第２のコードセグメントが、媒体Ｍを介して通信することを可能にする。図１Ｃでは、インタフェースオブジェクトＩ１およびＩ２を、同一のシステムの別々のインタフェースと考えることができ、また、オブジェクトＩ１およびＩ２に媒体Ｍを加えたものが、インタフェースを成すと考えることもできる。図１Ｂおよび図１Ｃは、双方向のフロー、およびそのフローのそれぞれの側のインタフェースを示すが、いくつかの実装形態では、一方向の情報フローだけを有する（または後段で説明するように、情報フローなし）ことが可能であり、あるいは一方の側にだけインタフェースオブジェクトを有することが可能である。例として、限定としてではなく、ＡＰＩ（アプリケーションプログラミングインタフェース）、エントリポイント、メソッド、ファンクション、サブルーチン、リモートプロシージャコール、およびＣＯＭ（コンポーネントオブジェクトモデル）インタフェースなどの用語が、プログラミングインタフェースの定義の範囲内に包含される。
【００２４】
そのようなプログラミングインタフェースの諸態様は、第１のコードセグメントが、情報（ここで、「情報」は、最も広い意味で使用され、データ、コマンド、要求などを含む）を第２のコードセグメントに送信する方法、第２のコードセグメントが、情報を受信する方法、ならびにその情報の構造、シーケンス、シンタックス、編成、スキーマ、タイミング、および内容を含むことが可能である。これに関して、基礎をなすトランスポート媒体自体は、その媒体が、有線であるか、または無線であるか、あるいはその両方の組合せであるかにかかわらず、情報が、インタフェースによって定義されたようにトランスポートされる限り、インタフェースの動作に重要ではない可能性がある。いくつかの状況では、情報は、従来の意味において一方向、または両方向で送られない可能性がある。というのは、情報転送は、１つのコードセグメントが、第２のコードセグメントによって実行される機能に単にアクセスする場合のように、別の機構を介する（例えば、コードセグメント間の情報フローとは別個のバッファ、ファイルなどに入れられた情報）、または存在しない可能性があるからである。以上の態様のいずれか、またはすべてが、例えば、コードセグメントが、緩く結合された構成におけるシステムの一部であるか、またはきつく結合された構成におけるシステムの一部であるかに依存して、所与の状況において重要である可能性があり、したがって、以上のリストは、例示的であり、限定的ではないものと考えられなければならない。
【００２５】
プログラミングインタフェースの以上の概念は、当業者には周知であり、本発明の以上の詳細な説明から明らかである。しかし、プログラミングインタフェースを実施する他の方法も存在し、明確に除外されない限り、それらの方法も、特許請求の範囲によって包含されるものとする。そのような他の方法は、図１Ｂおよび図１Ｃの単純すぎる図と比べて、より高度である、またはより複雑であるように見える可能性があるが、それでも、それらの方法は、同一の全体的な結果を実現する同様の機能を実行する。次に、プログラミングインタフェースのいくつかの例示的な代替の実装形態を簡単に説明する。
【００２６】
（Ａ．因数分解（factoring））
１つのコードセグメントから別のコードセグメントへの通信は、通信を複数の離散的な通信に分割することにより、間接的に達せられることが可能である。そのことを、図１Ｄおよび図１Ｅに概略で示す。図示するように、いくつかのインタフェースを、分割可能な機能セットとして説明することが可能である。このため、図１Ｂおよび図１Ｃのインタフェース機能を因数分解して、まさに、２４、つまり、２掛ける２掛ける３掛ける２を数学的にもたらすことができるように、同一の結果を実現することができる。したがって、図１Ｄに示すとおり、インタフェース、Ｉｎｔｅｒｆａｃｅ１によって提供される機能は、同一の結果を実現しながら、そのインタフェースの通信を複数のインタフェース、Ｉｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃなどに変換するように細分化することが可能である。図１Ｅに示すとおり、ＩｎｔｅｒｆａｃｅＩ１によって提供される機能は、同一の結果を実現しながら、複数のインタフェース、Ｉ１ａ、Ｉ１ｂ、Ｉ１ｃなどに細分化することが可能である。同様に、第１のコードセグメントから情報を受信する第２のコードセグメントのインタフェースＩ２は、複数のインタフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに因数分解することが可能である。因数分解を行う際、第１のコードセグメントに含まれるインタフェースの数は、第２のコードセグメントに含まれるインタフェースの数と一致しなくてもよい。図１Ｄおよび図１Ｅのケースのいずれにおいても、インタフェース、Ｉｎｔｅｒｆａｃｅ１およびインタフェースＩ１の機能上の趣旨は、それぞれ、図１Ｂおよび図１Ｃの場合と同一のままである。また、インタフェースの因数分解は、結合特性、交換特性、およびその他の数学的特性にも従うことが可能であり、したがって、因数分解は、認識するのが困難であることが可能である。例えば、演算の順序は重要ではない可能性があり、したがって、或るインタフェースによって実行される機能が、そのインタフェースに到達するはるか以前に、別のコードまたはインタフェースによって実行されることが可能であり、あるいはシステムの別個のコンポーネントによって実行されることが可能である。さらに、プログラミングの分野における当業者は、同一の結果を実現する様々なファンクションコールを行う様々な方法が存在することを理解することができよう。
【００２７】
（Ｂ．再定義（redefinition））
一部のケースでは、意図される結果を依然として実現しながら、プログラミングインタフェースのいくつかの態様（例えば、パラメータ）を無視する、追加する、または再定義することができる。そのことを、図１Ｆおよび図１Ｇに示す。例えば、図１Ｂのインタフェース、Ｉｎｔｅｒｆａｃｅ１が、３つのパラメータである、入力、精度、および出力を含む、第１のコードセグメントから第２のコードセグメントに発行されるファンクションコールである、Ｓｑｕａｒｅ（入力、精度、出力）を含むものと想定されたい。中央のパラメータである精度が、図１Ｆに示すように、所与のシナリオにおいて関係がない場合、そのパラメータを無視することも可能であり、（この状況では）無意味なパラメータで置き換えることさえ可能である。また、関係がないさらなるパラメータを追加することもできる。いずれにしても、ｓｑｕａｒｅの機能は、入力が第２のコードセグメントによって２乗された後に出力が戻される限り、達成することが可能である。精度は、コンピューティングシステムの何らかの下流の部分、またはその他の部分に有意なパラメータである可能性があるが、ｓｑｕａｒｅを計算するという限られた目的において、精度が必要ないと認識されると、精度は、置き換える、または無視することが可能である。例えば、有効な精度値を渡す代わりに、結果に悪影響を及ぼすことなしに、生年月日などの無意味な値を渡すことも可能である。同様に、図１Ｇに示すように、インタフェースＩ１は、パラメータを無視する、または、このインタフェースにパラメータを追加するように再定義されたインタフェースＩ１′で置き換えられる。インタフェースＩ２も同様に、不必要なパラメータ、または別の箇所で処理されることが可能なパラメータを無視するように再定義されたインタフェースＩ２′として再定義されることが可能である。ここでの要点は、一部のケースにおいて、プログラミングインタフェースが、一部の目的で必要とされないパラメータのような態様を含むことが可能であり、したがって、それらの態様が無視される、または再定義される、あるいは他の目的において、別の箇所で処理されることが可能であることである。
【００２８】
（Ｃ．インラインコーディング（inline coding））
また、２つの別々のコードモジュールの機能の一部、またはすべてをマージして、それらのモジュール間の「インタフェース」の形態が変わるようにすることも可能である。例えば、図１Ｂおよび図１Ｃの機能が、それぞれ、図１Ｈおよび図１Ｉの機能に変換されることが可能である。図１Ｈでは、図１Ｂの前の第１のコードセグメントと第２のコードセグメントがマージされて、これらのコードセグメントの両方を含むモジュールになる。その場合、それらのコードセグメントは、依然として、互いに通信していることが可能であるが、インタフェースは、単一のモジュールに、より適した形態に適合することが可能である。そのため、例えば、正規のＣａｌｌステートメントおよびＲｅｔｕｒｎステートメントは、もはや必要ない可能性があるが、インタフェース、Ｉｎｔｅｒｆａｃｅ１に準拠する同様の処理または応答は、依然として実施されていることが可能である。同様に、図１Ｉに示すとおり、図１ＣからのインタフェースＩ２の一部（またはすべて）が、インタフェースＩ１にインラインで書き込まれて、インタフェースＩ１”を形成することも可能である。例示するように、インタフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インタフェース部分Ｉ２ａが、インタフェースＩ１にインラインコーディングされて、インタフェースＩ１”を形成している。具体的な例として、図１ＣからのインタフェースＩ１が、ファンクションコール、ｓｑｕａｒｅ（入力、出力）を実行し、このコールがインタフェースＩ２によって受け取られ、インタフェースＩ２は、入力で渡された値を、第２のコードセグメントによって（その値を２乗するように）処理した後、２乗された結果を出力で戻すことを考慮されたい。そのようなケースでは、第２のコードセグメントによって実行される処理（入力を２乗すること）は、インタフェースへのコールなしに、第１のコードセグメントによって実行することが可能である。
【００２９】
（Ｄ．分離（divorce））
１つのコードセグメントから別のコードセグメントへの通信は、その通信を複数の離散的な通信に分割することにより、間接的に達せられることが可能である。そのことを、図１Ｊおよび図１Ｋに概略で示す。図１Ｊに示すように、１つまたは複数のミドルウェア（元のインタフェースから、機能および／またはインタフェース機能を分離する分離インタフェース）が、第１のインタフェース、Ｉｎｔｅｒｆａｃｅ１上の通信を、異なるインタフェースに、このケースでは、インタフェース、Ｉｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃに適合させるように変換するように提供される。例えば、Ｉｎｔｅｒｆａｃｅ１プロトコルに準拠してオペレーティングシステムと通信するように設計された、インストール済みのアプリケーションベースが存在するが、そのオペレーティングシステムが、異なるインタフェース、このケースでは、インタフェース、Ｉｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃを使用するように変更された場合に、この変換は行われることが可能である。要点は、第２のコードセグメントによって使用される元のインタフェースが、第１のコードセグメントによって使用されるインタフェースと互換性がないように変更され、古いインタフェースと新たなインタフェースに互換性があるようにするように、仲介が使用されるということである。同様に、図１Ｋに示すように、第３のコードセグメントが、分離インタフェースＤＩ１を使用して導入されて、インタフェースＩ１からの通信を受信し、分離インタフェースＤＩ２を使用して、インタフェース機能を、例えば、ＤＩ２で機能し、同一の機能上の結果をもたらすように再設計されたインタフェースＩ２ａおよびＩ２ｂに送信することが可能である。同様に、ＤＩ１とＤＩ２は、同一の、または同様の機能上の結果をもたらしながら、図１ＣのインタフェースＩ１およびＩ２の機能を、新たなオペレーティングシステムに対して変換するように協同することが可能である。
【００３０】
（Ｅ．書き換え（rewriting））
さらに別の可能な態様は、コードを動的に書き換えて、インタフェース機能を、別の、ただし、同一の全体的な結果を実現する何物かで置き換えることである。例えば、中間言語（例えば、Ｍｉｃｒｏｓｏｆｔ  ＩＬ、Ｊａｖａ（登録商標）  ＢｙｔｅＣｏｄｅなど）で与えられたコードセグメントが、或る実行環境（．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様のランタイムタイプの環境によって提供される環境）におけるＪＩＴ（ジャストインタイム）のコンパイラまたはインタプリタに与えられるシステムが存在することが可能である。ＪＩＴコンパイラは、第１のコードセグメントから第２のコードセグメントへの通信を変換するように、すなわち、通信を、第２のコードセグメント（元の第２のコードセグメント、または異なる第２のコードセグメント）によって要求されることが可能な、異なるインタフェースに適合させるように書かれることが可能である。そのことを、図１Ｌおよび図１Ｍに示す。図１Ｌで見ることができるように、このアプローチは、前述した分離シナリオに類似している。このアプローチは、例えば、インストール済みのアプリケーションベースが、Ｉｎｔｅｒｆａｃｅ１プロトコルに準拠してオペレーティングシステムと通信するように設計されているが、そのオペレーティングシステムが、異なるインタフェースを使用するように変更された場合に、行われることが可能である。ＪＩＴコンパイラを使用して、通信を、インストールベースの（installed-base）アプリケーションから、オペレーティングシステムの新たなインタフェースにオンザフライで適合させることが可能である。図１Ｍに示すように、インタフェースを動的に書き換えるこのアプローチは、インタフェースを動的に因数分解する、または別の方法で変更するのにも同様に適用することが可能である。
【００３１】
また、代替の諸実施形態を介して或るインタフェースと同一または同様の結果を実現するための前述したシナリオは、様々な形で、逐次に、または並行に、または他の仲介するコードを使用して組み合わされてもよいことにも留意されたい。このため、前述した代替の諸実施形態は、相互排他的ではなく、混合され、合わせられ、組み合わされて、図１Ｂおよび図１Ｃに提示した一般的なシナリオと同一の、または均等のシナリオをもたらすことが可能である。また、ほとんどのプログラミング構成体の場合と同様に、本明細書で説明されない可能性があるが、それでも、本発明の趣旨および範囲によって表される、或るインタフェースの同一または同様の機能を実現する他の同様の方法が存在することにも留意されたい。すなわち、インタフェースの価値の基礎をなすのは、少なくとも部分的に、インタフェースによって表される機能、およびインタフェースによって可能にされる有利な結果であることに留意されたい。
【００３２】
図２は、一部のグラフィカルユーザインタフェースシステムにおける従来のウインドウ管理シナリオ２００を示す。図示するように、複数の開かれたアプリケーションウインドウが、前部に配置された、より大きい他のウインドウによって、部分的または完全に見えなくされている。具体的には、図２は、アプリケーションウインドウ２０３ａが、ウインドウ２０３ｂ、２０３ｃ、および２０３ｄよりＺ次（Z-order）高い、Ｚ次構成における複数のウインドウ２０３ａ〜２０３ｄのシナリオ２００を示す。アプリケーションウインドウ２０３ａ〜２０３ｄは、デスクトップスペース２０１内に示される。
【００３３】
デスクトップスペース２０１は、アプリケーションプログラムに対応するウインドウの表示を可能にするディスプレイの領域である。一番下の、タスクバーなどの事前定義された領域２１０は、どのウインドウが、目に見える、または最小化されることが可能であるかを含め、どのアプリケーションウインドウが、現在使用中であるかを示す。事前定義された領域２１０は、活性化すること、移動すること、隠すこと、および最小化することなどのウインドウの操作をリストアップし、その操作を可能にするために使用される、スクリーン上のウインドウリモートコントロールの特定の実装形態である。ウインドウ２０３ａ、２０３ｂ、および２０３ｃは、アプリケーションタイル２１３ａによって表され、ウインドウ２０３ｄは、アプリケーションウインドウタイル２１３ｂによって表される。この例に示すように、「Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅ」として特定されたアプリケーションプログラムは、現在、６つの開かれたウインドウを有している。アプリケーションウインドウ２０３ａ〜２０３ｄおよびアプリケーションタイル２１３は、ユーザが、アプリケーションウインドウを実行しているアプリケーションのタイプを識別することを可能にするアプリケーションアイコン識別子２２３ａを含む。参照されていないが、アプリケーションウインドウタイル２１３ｂも、アプリケーションアイコン識別子を含むことができる。ユーザが、ポップアップメニューを開くためにアイコン２４７の上にポインタ２３１を移動すると、ウインドウ２０３ａ〜２０３ｄの内容のファイル名が、ポップアップメニュー２７１の中に示される。ファイル名は、ウインドウを操作するアプリケーションプログラムによって生成されることが可能であり、かつ／またはユーザによってカスタマイズされることも可能である。
【００３４】
図２は、グロムの中にあるアプリケーションウインドウの例を示す。示される従来のグロムは、アプリケーションタイル２１３ａの下に、開かれた各アプリケーションウインドウタイルに関するアプリケーションウインドウタイルを保つ。アプリケーションタイル２１３ａは、グロムの中のアプリケーションウインドウ間の共通のアプリケーションを識別し、いずれの特定の開かれたアプリケーションウインドウも表現しない。例えば、図２に示すように、「Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅ」アプリケーションの下で開かれている、いずれのアプリケーションウインドウも、グロム内に含まれる。図示するように、１つのタイプの視覚的インジケータであるアプリケーションウインドウタイルカウンタ２４４が、「Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅ」アプリケーションの下で、現在いくつのアプリケーションウインドウが開かれているかを、ユーザが識別することを可能にするように示されている。
【００３５】
ウインドウ２０３ａ〜２０３ｄは、ユーザに内容を表示するために、アプリケーションプログラムによって使用される。ウインドウ２０３ａ〜２０３ｄのそれぞれは、その他のウインドウ２０３ａ〜２０３ｄとは独立であり、その他のウインドウ２０３ａ〜２０３ｄの外部にある。本明細書における用法では、第１のウインドウが第２のウインドウ内に含まれず、第２のウインドウが第１のウインドウ内に含まれない場合、第１のウインドウは、第２のウインドウの外部にある。第１のウインドウと第２のウインドウが単に重なり合う場合、第１のウインドウは、第２のウインドウに含まれないことを理解されたい。
【００３６】
図３は、本発明の少なくとも１つの態様によるアプリケーション関連のアプリケーションウインドウのグロムを含むアプリケーションウインドウ表現システムの実施例を示す。シナリオ３００では、タスクバー領域のような事前定義された領域が、アプリケーションウインドウタイル３１３ａ〜３１３ｌが配置された、定義された位置セットを含む。図示するように、アプリケーションウインドウタイル３１３ａは、最も新しく使用される位置にあり、アプリケーションウインドウタイル３１３ｂは、２番目に新しく使用される位置にあり、他のアプリケーションウインドウタイルは、他の位置にあることが示される。アプリケーションウインドウタイルの位置の配置は、対応するアプリケーションウインドウが、どれだけ新しく使用されたかとは異なるフォーマットに基づくように構成されてもよいことが、当業者には理解されよう。
【００３７】
アプリケーションウインドウタイル３１３ｃは、３番目に新しく使用された位置に示される。５つのアプリケーションウインドウタイルが示され、タイル３１３ｃ、３１３ｄ、および３１３ｇが特に参照されるグロムが、図示される。アプリケーションウインドウタイル３１３ａ〜３１３ｇは、同一のアプリケーションの下で機能するアプリケーションウインドウに対応する。アプリケーションアイコン識別子３２３ａにより、アプリケーションウインドウタイルが、どのアプリケーションプログラムの下で機能するかが示される。ユーザが、グロムメニュー３７１を開くためにアイコン３４７ａの上にポインタ２３１を移動すると、グロムメニュー３７１が、隠された状態から表示される。グロムメニュー３７１は、グロムのアプリケーションウインドウタイルを示して、ユーザが、特定のアプリケーションウインドウに迅速にアクセスすることを可能にする。本発明の一態様は、ユーザが、アプリケーションウインドウタイルのグロムを最初に開く必要なしに、アプリケーションウインドウタイル３１３ｃに直接アクセスすることを可能にする。図２の従来のシステムは、ユーザが、アプリケーションタイル２１３ａを最初に開いて、グロム内のすべてのタイルを見なければならないことを示す。本発明の一態様の下では、ユーザは、グロムを最初に開くことなしに、アプリケーションウインドウタイル３１３ｃに関連するアプリケーションウインドウに直接にアクセスすることができる。
【００３８】
アプリケーションウインドウタイル３１３ｃおよび３１３ｊは、ユーザに対してさらなるデータを含むように構成されているため、アプリケーションウインドウタイル３１３ａ、３１３ｂ、３１３ｈ、および３１３ｌとは異なる。ユーザは、アプリケーションアイコン識別子のタイトル部分をクリックすることにより、アプリケーションウインドウタイル３１３ｃに関連するアプリケーションウインドウにアクセスすることができる。代替として、ユーザは、アイコン３４７ａ、３４７ｂのいずれかにアクセスして、グロムを拡張することにより、グロムの内容を見ることができる。グロムを拡張する際、グロムメニュー３７１、またはグロムされた（glommed）アプリケーションウインドウタイルの、他の何らかの形態の表示が、表示されることが可能である。次に、ユーザは、ポインタ２３１を使用して、グロムメニュー３７１の中の対応するアプリケーションウインドウタイルを選択することにより、所望されるアプリケーションウインドウにアクセスすることができる。ユーザは、アプリケーションウインドウタイルカウンタ３２４ａにより、グロム内のアプリケーションウインドウタイルの数を識別することができる。アプリケーションウインドウタイルカウンタ３２４ａは、グロムの中のアプリケーションウインドウの数を識別する１つのタイプの視覚的インジケータである。図３に示すように、アプリケーションウインドウタイルカウンタは、グロム内の４つのアプリケーションウインドウタイルと互いに関係する４という値を示す。アプリケーションウインドウタイルカウンタ３２４ｂは、異なるグロムの中の２つのアプリケーションウインドウタイルと互いに関係する２という値を示す。いくつかの異なるアプリケーションウインドウ表現を使用することが可能であり、アプリケーションウインドウタイルは一例に過ぎないことが、当業者には理解されよう。本発明は、アプリケーションウインドウのいずれか１つのタイプの表現に限定されない。
【００３９】
さらに、図３は、ユーザがアプリケーションウインドウのグロムに対して行うことができる様々なアクションを示す。例えば、ユーザは、グロムの中のアプリケーションウインドウのすべてを、タスクバーのような事前定義された領域に最小化するため、「Ｍｉｎｉｍｉｚｅ  Ａｌｌ（すべて最小化）」操作の上にポインタ２３１を移動することができる。さらに、アプリケーションウインドウをグロムするための方法は、システムのデフォルトの動作であるように構成されることが可能であり、サードパーティベンダによって構成可能であり、かつ／またはユーザによって構成可能であることが可能である。例えば、デフォルトのプログラムは、アプリケーションウインドウがどれだけ新しく使用されたかにより、アプリケーションウインドウタイルを配置することができる。サードパーティベンダプログラムは、内容の類似性に従ってアプリケーションウインドウタイルを配置してもよく、一方、ユーザは、アプリケーションタイプによるなど、他の何らかの方法に従ってユーザのアプリケーションウインドウを構成してもよい。この場合も、本発明は、提供する実施例および例示に限定されないことが、当業者には理解されよう。
【００４０】
従来のグラフィカルユーザインタフェースシステムの下では、ユーザは、トップレベルのウインドウに切り替えることしかできない。一方、いくつかのウインドウは、何らかのタイプのコンテナ内のウインドウのグループの一部であるため、子ウインドウと呼ばれる。そのようなコンテナの一例が、ＭＤＩ（複数ドキュメントインタフェース）アプリケーションであり、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｖｉｓｉｏのようなアプリケーションプログラムは、単一のトップレベルウインドウ、つまり、親ウインドウと、そのウインドウ内に開かれた複数のドキュメントウインドウ、つまり子ウインドウとを有する。ＭＤＩの代替が、ＳＤＩ（単一ドキュメントインタフェース）であり、各ウインドウは１つのファイルを含むが、いくつかのファイルを一度に表示するために、ディスプレイスクリーン上に開かれた複数のウインドウが存在することが可能である。Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄは、ＳＤＩアプリケーションプログラムの例である。
【００４１】
図４は、本発明の少なくとも１つの態様によるＭＤＩ（複数ドキュメントインタフェース）親アプリケーションウインドウに関連するＭＤＩ子アプリケーションウインドウのグロムを含むアプリケーションウインドウ表現システムの例を示す。このシナリオ４００では、複数のアプリケーションウインドウ４０３ａ〜４０３ｄが示される。アプリケーションウインドウ４０３ａは、アプリケーションウインドウタイル４１３ａによって表される。アプリケーションウインドウタイル４１３ａは、アプリケーションウインドウタイルカウンタ４２４およびアイコン４４７を含むという点で、アプリケーションウインドウタイル３１３ｃと同様である。ユーザが、アイコン４４７上でポインタをさまよわせた場合、グロムメニュー４７１が表示されて、グロム内に潜在するアプリケーションウインドウアイコンを示す。
【００４２】
アプリケーションウインドウ４０３ａは、ＭＤＩ親アプリケーションウインドウである。アプリケーションウインドウ４０３ｂ〜４０３ｄは、ＭＤＩ親アプリケーションウインドウ４０３ａに関連するＭＤＩ子アプリケーションウインドウである。一例によって示されるように、アプリケーションウインドウ４０３ｂ〜４０３ｄのそれぞれは、ディスプレイスクリーンの事前定義された領域２１０内で、グロムの中のアプリケーションウインドウタイル４１３ａによって表される。次に、ユーザが、ポインタ２３１を使用して、グロムメニュー４７１の中の対応するアプリケーションウインドウタイルを選択することにより、所望のアプリケーションウインドウにアクセスすることができる。アプリケーションアイコン識別子４２３により、アプリケーションウインドウタイルがどのアプリケーションプログラムの下で機能するかが示される。このように、アプリケーションウインドウ４０３ｂ〜４０３ｄが、ＭＤＩ親アプリケーションウインドウ４０３ａに関連するＭＤＩ子アプリケーションウインドウであるので、各アプリケーションウインドウに関するアプリケーションアイコン識別子は同一である。アプリケーションウインドウタイルのグロムの構成は、デフォルトのシステム構成であること、サードパーティベンダによって設計された構成であること、および／またはユーザがカスタマイズすることができる構成であることが可能である。このため、本発明の少なくとも１つの態様の下では、開かれたＭＤＩ子アプリケーションウインドウは、ＭＤＩ親アプリケーションウインドウ４０３ａのグロム内で、対応するアプリケーションウインドウ表現４１３を有するように、自動的に構成されることが可能である。
【００４３】
図３の説明の諸態様は、図４の説明の中にも含まれることが可能であることが、当業者には理解されよう。例えば、ユーザは、図３に関連して説明したアクションと同一または同様の形で、ＭＤＩアプリケーションウインドウのグロムに対して様々なアクションを行うことができる。ユーザは、グロムの中のＭＤＩ子アプリケーションウインドウのすべてを、タスクバーのような事前定義された領域に最小化するために、図３に示したのと同様に、「Ｍｉｎｉｍｉｚｅ  Ａｌｌ」操作の上にポインタ２３１を移動することができる。さらに、アプリケーションウインドウをグロムするための方法は、システムのデフォルトの動作であるように構成されることが可能であり、サードパーティベンダによって構成可能であり、かつ／またはユーザによって構成可能であることが可能である。例えば、デフォルトのプログラムは、アプリケーションウインドウが、どれだけ新しく使用されたかにより、アプリケーションウインドウタイルを配置することができる。サードパーティベンダプログラムは、内容の類似性に従ってアプリケーションウインドウタイルを配置してもよく、一方、ユーザは、アプリケーションタイプによるなど、他の何らかの方法に従ってユーザのアプリケーションウインドウを構成してもよい。この場合も、本発明は、提供する実施例および例示に限定されず、様々な実施例からの特徴の組合せを一緒に使用することも可能であることが、当業者には理解されよう。
【００４４】
図５Ａは、アプリケーションウインドウタイルをめくる（page through）オーバーフロー追加（overflow added）スクロールバーを含む従来のタスクバー領域を示す。シナリオ５００ａでは、タスクバー領域２１０ａ内のタイル位置セットを超える、多数のアプリケーションウインドウが開かれると、追加のタイルが、第２のタスクバー領域２１０ｂ内に配置される。シナリオ５００ａは、アプリケーションタイル５１３ａおよび５１３ｂが、タスクバー領域２１０ａ内のタイル位置セットに、どのように配置されるかを示す。同様に、アプリケーションウインドウタイル５１３ｃおよび５１３ｊも、タスクバー領域２１０ａ内に配置される。タスクバー領域２１０ａ内のタイル位置のすべてが占有され、新たなアプリケーションウインドウが開かれると、その新たなアプリケーションウインドウに対応するアプリケーションウインドウタイル５１８ａが、第２のタスクバー領域２１０ｂ内に配置される。ユーザは、スクロールバー５５１をクリックして、様々なタスクバー２１０ａおよび２１０ｂの間をスクロールしなければならない。タスクバー領域２１０ｂ内のタイル位置のすべてが占有されると、第３のタスク領域を作成することが可能である。スクロールすべき様々なタスクバー領域のすべてをともなって、無数のアプリケーションウインドウタイルおよびアプリケーションタイルのなかで、所望のタイルを識別することは、困難である可能性がある。
【００４５】
図５Ｂは、本発明の少なくとも１つの態様によるオーバーフローメニューを含むアプリケーションウインドウ表現システムの例を示す。シナリオ５００ｂでは、タスクバー領域のような事前定義された領域内のアプリケーションウインドウタイル位置セットを超える、多数のアプリケーションウインドウが開かれると、さらなるアプリケーションウインドウタイルが、オーバーフロー表現５６２の中でグロム内に配置される。オーバーフロー表現５６２は、アプリケーションウインドウタイルカウンタ５６３およびアイコン５６４を含むという点において、アプリケーションウインドウタイル５１９ｃと同様である。ユーザが、アイコン５６４上でポインタをさまよわせた場合、グロムメニュー（図示せず）が表示されて、オーバーフローグロム内に潜在するアプリケーションウインドウアイコンを示す。シナリオ５００ｂでは、ユーザは、特定のアプリケーションウインドウタイルを探し出すために、様々なタスクバー領域をスクロールしなくてもよい。代わりに、ユーザは、アイコン５６４上でポインタ２３１をさまよわせて、事前定義された領域内で特定されていない、残りの１４のアプリケーションウインドウタイルに関係する情報を表示する。このようにユーザは、全てのウインドウアプリケーションタイルへのワンステップアクセスを有する。
【００４６】
図６Ａは、アプリケーション通知を含む従来のタスクバー領域を示す。シナリオ６００ａでは、グロムの中に８つのアプリケーションウインドウを含むアプリケーションタイル２１３ｂが示される。８つのアプリケーションウインドウは、アプリケーションウインドウタイルカウンタ２２４によって識別される。アプリケーションタイル２１３ｂは、通知がユーザに対して行われている状態において示される。通知は、ユーザによって対処が行われることが可能な条件／イベントを意味する何らかのシグナルである。例えば、通知は、新たな電子メールメッセージが受信されていることを示すための、タイル２１３ｂの点滅であることが可能である。通知は、アプリケーションタイル２１３ｂに色の変化を生じさせて、ユーザの注意を引くように試みてもよい。しかし、アプリケーションウインドウがグロムされると、通知もグロムされる。ユーザは、グロムメニューを開くことなしに、どのアプリケーションウインドウが通知に対応するかを特定することができる。ユーザは、通知を生じさせているアプリケーションウインドウタイル、およびどのようなタイプの注意がユーザに必要であるかを確認するために、グロムメニューを開くことを要求される。
【００４７】
図６Ｂは、本発明の少なくとも１つの態様によるアプリケーションウインドウ固有の通知を含むアプリケーションウインドウ表現システムの例を示す。シナリオ６００ｂでは、８つのアプリケーションウインドウタイル表現が、事前定義された領域内の位置セット内の位置を占めるように示されている。この例では、最近に使用された位置が、事前定義された領域の左側にある、８つの位置が示されている。アプリケーションウインドウタイル６１３ａが、最近に使用された位置内に配置されているのが示され、アプリケーションウインドウタイル６１３ｌが、８番目の、最後の位置内に配置されているのが示されている。以上は、アプリケーションウインドウタイル表現の構成の１つの例示的な実施例に過ぎず、アプリケーションウインドウタイル表現を表示するための他の方法が使用されることも可能であることを理解されたい。
【００４８】
アプリケーションウインドウタイル６１３ｅは、事前定義された領域内の３番目の位置におけるグロムメニュー内にある。アプリケーションウインドウタイル６１３ｃは、グロムメニューが４つのアプリケーションウインドウタイルを含むことを示す、アプリケーションウインドウタイルカウンタ６２４ａを含む。アプリケーションウインドウタイル６１３ｅは、通知がユーザに対して行われている状態で示されている。この例に示すように、グロムメニューは、グロム内のアプリケーションウインドウに関する通知が受け取られると、自動的に表示されることが可能である。このため、ユーザは、そのアプリケーションウインドウに関する通知が受け取られると、図６Ｂに示すように、グロムメニューの中の点滅するアプリケーションウインドウタイル６１３ｅによって通知されることが可能である。
【００４９】
図６Ｃは、本発明の少なくとも１つの態様によるアプリケーションウインドウ固有の通知を含むアプリケーションウインドウ表現システムの別の例を示す。シナリオ６００ｃでは、通知を受け取ったアプリケーションウインドウ６１３ｅが、ユーザの目に見える事前定義された領域内の８つの位置の１つを占めるように移動される。この例では、アプリケーションウインドウ６１３ｅは、グロムから取り出されて、事前定義された領域内の最近に使用された位置に挿入されている。これに応答して、３番目に新しく使用された位置におけるグロムからアプリケーションウインドウタイルが取り除かれるため、事前定義された領域内のタイルの配置に、いくつかの変更が行われることが可能である。例えば、図６Ｃに示すように、事前定義された領域内のアプリケーションウインドウタイルのそれぞれが、位置を１つ（右に）下げられる。例えば、図６Ｂの最近に使用された位置にあるアプリケーションウインドウタイル６１３ａが、現時点では、図６Ｃの２番目に新しく使用された位置に示される。通知を受け取ったアプリケーションウインドウ６１３ｅは、最近に使用された位置に移動されている。さらに、アプリケーションウインドウタイル６１３ｅがグロムから取り除かれているため、アプリケーションウインドウタイルカウンタ６２４ａは１だけ減分されて、他の３つのアプリケーションウインドウだけが、対応するグロムメニューの中でグロムされていることを示す。さらに、アプリケーションウインドウタイル６１３ｅの再配置のため、グロムが確立されることが可能である。図６Ｃでは、アプリケーションウインドウタイル６１３ｋが、アプリケーションウインドウタイルカウンタ６２４ｂを含むアプリケーションウインドウタイルに変換されている。図示していないが、アプリケーションウインドウタイル６１３ｌが、事前定義された領域内のセット内の８番目の、最後の位置でグロム内に配置される。
【００５０】
本発明の諸態様は、図に示されるアプリケーションウインドウおよび／またはグロムの数に限定されず、任意の数の異なるアプリケーションウインドウグロムが作成されることが可能であることを理解されたい。さらに、本発明の様々な態様によれば、１つまたは複数のウインドウがグロムに追加されること、またはグロムから取り除かれることが可能であることを理解されたい。さらに、通知を受け取るとグロムからアプリケーションウインドウタイル表現を再配置する例示的な実施例は、本発明を限定しないことを理解されたい。他の方法を使用して、アプリケーションウインドウタイル表現を再配置してもよい。例えば、アプリケーションウインドウタイル表現は、グロムから取り除かれて、対応するグロムの右側などの、図に示すのとは異なる位置に配置されてもよい。
【００５１】
図７は、本発明の少なくとも１つの態様によるアプリケーションウインドウ表現を配置するための方法の例示的な実施例を示す流れ図である。プロセスは、ステップ７０１において始まり、アプリケーションウインドウタイル位置セットが、ディスプレイスクリーン上の事前定義された領域内で定義される。事前定義された領域は、ディスプレイスクリーンの底部に沿ったタスクバー領域であることが可能である。例えば、アプリケーションウインドウタイル位置セットは、事前定義された領域が常に目に見える場合に、常にユーザの目に見える８つの位置であることが可能である。プロセスは、ステップ７０３に進み、複数のアプリケーションウインドウ表現が、その位置セット内で表示される。タイルは、表現の１つのタイプである。ステップ７０５において、新たなアプリケーションウインドウを開く入力が、受け取られたかどうかの判定が行われる。受け取られていない場合、プロセスは、入力が受け取られるまで待ちつづける。入力が、ステップ７０５において受け取られると、プロセスはステップ７０７に進み、その新たなアプリケーションウインドウに関連するアプリケーションウインドウタイルが作成される。ステップ７０９において、その新たに作成されたアプリケーションウインドウタイルが、最近に使用された位置でセット内に表示される。この場合も、その新たに作成されたアプリケーションウインドウタイルは、デフォルトのスキーム、サードパーティベンダスキーム、かつ／またはユーザが構成したスキームなどの異なるスキームに従って配置されることが可能であることが、当業者には理解されよう。
【００５２】
ステップ７１１に進み、複数のアプリケーションウインドウタイルのうちの或るアプリケーションウインドウタイルが、新たなアプリケーションウインドウタイルの追加に応じて再配置される必要があるかどうかの判定が行われる。その必要がない場合、プロセスは終了する。その必要がある場合は、ステップ７１３において、ステップ７１１からのウインドウタイルが、隠されたアプリケーションウインドウタイル位置に再配置される必要があるかどうかについての、別の判定が行われる。隠されたアプリケーションウインドウタイル位置は、前述したとおり、グロムメニュー内、またはオーバーフローメニュー内に位置することが可能である。隠されたアプリケーションウインドウタイルは、グロムメニューまたはオーバーフローメニューにアクセスが行われると、ユーザの目に見えるようになる。タイルが、隠された位置に再配置される必要がある場合、ステップ７１５において、アプリケーションウインドウタイルは、セット内で適宜、再配置され、表示される。ステップ７１３において、タイルが、隠された位置に再配置される必要がないと判定された場合、プロセスはステップ７１７に進み、アプリケーションウインドウタイルは、適宜、セット内の目に見える位置に再配置され、表示される。
【００５３】
図８は、本発明の少なくとも１つの態様によるアプリケーションウインドウ表現を配置するための方法の別の例示的な実施例を示す流れ図である。ステップ８０１において、ＭＤＩ（複数ドキュメントインタフェース）親アプリケーションウインドウを開く要求が受け取られる。そのような状況は、ユーザが、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｖｉｓｉｏのようなアプリケーションを起動した際に生じる可能性がある。ステップ８０３において、ＭＤＩ親アプリケーションウインドウタイルが作成され、ステップ８０５において、そのＭＤＩ親アプリケーションウインドウタイルが、事前定義された領域内に表示される。ステップ８０７に進み、新たなアプリケーションウインドウを開く要求が受け取られる。ステップ８０９において、ＭＤＩ子アプリケーションウインドウを開く入力が受け取られているかどうかの判定が行われる。受け取られていない場合、プロセスは、ステップ８１１に進み、その新たなアプリケーションウインドウのための対応するアプリケーションウインドウタイルが作成され、ステップ８１３において、そのアプリケーションウインドウタイルが、事前定義された領域内に表示される。ステップ８１９において、アプリケーションウインドウタイルが、必要に応じて、事前定義された領域内で再配置されてから、プロセスは終了する。例えば、その新たなアプリケーションウインドウタイルが、事前定義された領域内の最近に使用された位置を占めることが可能である。このため、ＭＤＩ親アプリケーションウインドウタイルは、別の位置に再配置されることが可能である。
【００５４】
ステップ８０９において、入力が、ＭＤＩ子アプリケーションウインドウを開く要求であった場合、プロセスは、ステップ８１５に進み、ＭＤＩ子アプリケーションウインドウタイルが作成される。ステップ８１７において、ＭＤＩ子アプリケーションウインドウタイルが、ＭＤＩ親アプリケーションウインドウタイルの下に、グロムされたアイテムとして表示される。ステップ８１９に進み、アプリケーションウインドウタイルが、適宜、事前定義された領域内で再配置される。例えば、ＭＤＩ親アプリケーションウインドウは、事前定義された領域内の最近に使用された位置に再配置されることが可能である。
【００５５】
図９は、本発明の少なくとも１つの態様によるアプリケーションウインドウ表現を配置するための方法の別の例示的な実施例を示す流れ図である。プロセスは、ステップ９０１において始まり、アプリケーションウインドウタイル位置セットが、ディスプレイスクリーン上の事前定義された領域内で定義される。事前定義された領域は、ディスプレイスクリーンの底部に沿ったタスクバー領域であることが可能である。例えば、アプリケーションウインドウタイル位置セットは、事前定義された領域が常に目に見える場合に、常にユーザの目に見える８つの位置であることが可能である。プロセスは、ステップ９０３に進み、複数のアプリケーションウインドウ表現が、事前定義された領域内のセット内の目に見えるすべての位置までを占めるように表示される。タイルは、表現の１つのタイプである。ステップ９０５において、さらなるアプリケーションウインドウを開く入力が、受け取られているかどうかの判定が行われる。受け取られていない場合、プロセスは、入力が受け取られるまで待ちつづける。ステップ９０５において、入力が受け取られると、プロセスはステップ９０７に進み、その新たなアプリケーションウインドウに関連するアプリケーションウインドウタイルが作成される。ステップ９０９において、その新たに作成されたアプリケーションウインドウタイルが、オーバーフロー領域内に表示され、オーバーフローカウンタが１だけ増分される。オーバーフロー領域は、メニューであることが可能である。この場合も、その新たに作成されたアプリケーションウインドウタイルは、デフォルトのスキーム、サードパーティベンダスキーム、かつ／またはユーザが構成したスキームなどの異なるスキームに従って配置されてもよく、次いで、異なるアプリケーションウインドウタイルが、そのオーバーフロー領域に再配置されてもよいことが、当業者には理解されよう。
【００５６】
ステップ９１１において、任意のさらなるアプリケーションウインドウタイルが作成されて、オーバーフロー領域内に表示され、カウンタが各タイルに関して１だけ増分される。ステップ９１３に進み、オーバーフロー領域にアクセスする入力が受け取られているかどうかの判定が行われる。受け取られていない場合、プロセスは終了する。受け取られている場合、プロセスは、ステップ９１５に進み、オーバーフロー領域内のアプリケーションウインドウタイルが表示される。ステップ９１７において、オーバーフロー領域内のアプリケーションウインドウタイルにアクセスする入力が、受け取られているかどうかの判定が行われる。受け取られていない場合、プロセスは、入力アクセスが受け取られるまで待つ。ステップ９１７において、オーバーフロー領域内のアプリケーションウインドウタイルにアクセスする入力が受け取られると、プロセスはステップ９１９に進み、選択されたアプリケーションウインドウタイルに関連するアプリケーションウインドウが、ディスプレイスクリーン上のデスクトップスペース内のＺ次の一番上に表示される。プロセスはステップ９２１に進み、アプリケーションウインドウタイルが、適宜、事前定義された領域内、およびオーバーフロー領域内で再配置される。
【００５７】
図１０は、本発明の少なくとも１つの態様によるアプリケーションウインドウ表現に対応する通知を表示するための方法の別の例示的な実施例を示す流れ図である。プロセスはステップ１００１において始まり、アプリケーションウインドウのグロムに関するアプリケーションウインドウタイルを含む、複数のアプリケーションウインドウタイルが、事前定義された領域内に表示される。ステップ１００３において、注目を要求する入力が、受け取られているかどうかの判定が行われる。例えば、そのような状況は、通知警報が受け取られると、生じる可能性がある。受け取られていない場合、プロセスは、入力が受け取られるまで待つ。受け取られている場合、プロセスは、ステップ１００５に進み、注目を必要とするアプリケーションウインドウが、グロム内にあるかどうかの判定が行われる。グロム内にない場合、プロセスはステップ１００７に進み、或るアクションが、ユーザのためにアプリケーションウインドウタイルに適用され、プロセスは終了する。ステップ１００５において、アプリケーションウインドウがグロム内にある場合、プロセスはステップ１００９に進み、アプリケーションウインドウタイルが、適宜、グロムに関するグロムメニューから、事前定義された領域内の目に見える位置に再配置される。例えば、アプリケーションウインドウは、最近に使用された位置に再配置されることが可能である。ステップ１０１１において、或るアクションが、ユーザのためにアプリケーションウインドウタイルに適用される。そのようなアクションは、アプリケーションウインドウタイルが点滅するように、かつ／または色を変えるようにさせることであることが可能である。ステップ１０１３において、グロム内のアプリケーションウインドウタイルの数を識別するカウンタが、ステップ１００５から、グロムされたアプリケーションウインドウタイルが目に見える位置に再配置されているので、１だけ減分される。
【００５８】
別の実施形態は、グロムの中へのアプリケーションウインドウの直接の配置を、プログラミングで制御することである。例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅのような１つまたは複数のアプリケーションが、いくつかのドキュメントから成るプロジェクトの概念を共有することが可能である。それらのドキュメントは、プロジェクトにおける新たなドキュメントがユーザによって開かれるにつれ、グロムの中に同時に開かれること、またはグロムに自動的に追加されることが可能である。
【００５９】
ＡＰＩ（アプリケーションプログラミングインタフェース）に関連して、本発明の様々な態様が、ＡＰＩによって実行されることが可能である。例えば、公開ＡＰＩがオペレーティングシステムとインタフェースして、オペレーティングシステムが、本発明の様々なフィーチャ（feature）を提供することを可能にすることが可能である。一実施形態では、グロムされたアプリケーションウインドウタイルを表すデータを処理するためのソフトウェアアーキテクチャが、第１のアプリケーションウインドウタイル、および第２のアプリケーションウインドウタイルをグロムの中に配置するように構成されたコンポーネントと、そのコンポーネントにアクセスするためのアプリケーションプログラムインタフェースとを含むことが可能である。ＡＰＩは、２つのアプリケーションウインドウタイルをグロムする要求を受け取り、その動作を実行するのに必要なファンクションにアクセスし、次に、結果をオペレーティングシステムに送り返す。オペレーティングシステムは、ＡＰＩによって提供されたデータを使用して、本発明の様々なフィーチャを実行することができる。アプリケーションプログラムに、アプリケーションウインドウタイルグロムを利用させるＡＰＩは、プログラミングによってアプリケーションウインドウタイルを配置すること、および再配置することを含む。
【００６０】
本発明の様々な態様を実施するための例示的なシステムおよび方法を示したが、本発明はそれらの実施形態に限定されないことが、当業者には理解されよう。特に、以上の教示に鑑みて、変形が当業者によって行われることが可能である。例えば、前述した諸実施形態の要素のそれぞれを、単独で、あるいは他の諸実施形態の要素と組み合わせて、または部分的に組み合わせて、利用することが可能である。また、本発明の趣旨および範囲を逸脱することなく、変形が行われることが可能であることも認識され、理解されよう。このため、以上の説明は本発明を限定するものではなく、例示的であると見なされるべきである。
【図面の簡単な説明】
【００６１】
【図１Ａ】本発明のいくつかの態様を実施することが可能な汎用デジタルコンピューティング環境を示す概略図である。
【図１Ｂ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｃ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｄ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｅ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｆ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｇ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｈ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｉ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｊ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｋ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｌ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図１Ｍ】本発明の１つまたは複数の態様をサポートする汎用コンピュータ環境を示す図である。
【図２】従来のウインドウ管理シナリオを示す図である。
【図３】本発明の少なくとも１つの態様によるアプリケーション関連のアプリケーションウインドウのグロムを含むアプリケーションウインドウ表現システムの例を示す図である。
【図４】本発明の少なくとも１つの態様によるＭＤＩ（複数ドキュメントインタフェース）親アプリケーションウインドウに関連するＭＤＩ子アプリケーションウインドウのグロムを含むアプリケーションウインドウ表現システムの別の例を示す図である。
【図５Ａ】アプリケーションウインドウタイルをめくるオーバーフロー追加スクロールバーを含む従来のタスクバー領域を示す図である。
【図５Ｂ】本発明の少なくとも１つの態様によるオーバーフローメニューを含むアプリケーションウインドウ表現システムの例を示す図である。
【図６Ａ】アプリケーション通知を含む従来のタスクバー領域を示す図である。
【図６Ｂ】本発明の少なくとも１つの態様によるアプリケーションウインドウ固有の通知を含むアプリケーションウインドウ表現システムの例を示す図である。
【図６Ｃ】本発明の少なくとも１つの態様によるアプリケーションウインドウ固有の通知を含むアプリケーションウインドウ表現システムの例を示す図である。
【図７】本発明の少なくとも１つの態様によるアプリケーションウインドウ表現を配置するための方法の例示的な実施例を示す流れ図である。
【図８】本発明の少なくとも１つの態様によるアプリケーションウインドウ表現を配置するための方法の別の例示的な実施例を示す流れ図である。
【図９】本発明の少なくとも１つの態様によるアプリケーションウインドウ表現を配置するための方法の別の例示的な実施例を示す流れ図である。
【図１０】本発明の少なくとも１つの態様によるアプリケーションウインドウ表現に対応する通知を表示するための方法の別の例示的な実施例を示す流れ図である。
【図１Ａ】
2008535084.tif 000003
【図１Ｂ】
2008535084.tif 000004
【図１Ｃ】
2008535084.tif 000005
【図１Ｄ】
2008535084.tif 000006
【図１Ｅ】
2008535084.tif 000007
【図１Ｆ】
2008535084.tif 000008
【図１Ｇ】
2008535084.tif 000009
【図１Ｈ】
2008535084.tif 000010
【図１Ｉ】
2008535084.tif 000011
【図１Ｊ】
2008535084.tif 000012
【図１Ｋ】
2008535084.tif 000013
【図１Ｌ】
2008535084.tif 000014
【図１Ｍ】
2008535084.tif 000015
【図２】
2008535084.tif 000016
【図３】
2008535084.tif 000017
【図４】
2008535084.tif 000018
【図５Ａ】
2008535084.tif 000019
【図５Ｂ】
2008535084.tif 000020
【図６Ａ】
2008535084.tif 000021
【図６Ｂ】
2008535084.tif 000022
【図６Ｃ】
2008535084.tif 000023
【図７】
2008535084.tif 000024
【図８】
2008535084.tif 000025
【図９】
2008535084.tif 000026
【図１０】
2008535084.tif 000027
【国際調査報告】
2008535084.tif 000028