JP2008538631A - ウィンドウ・マネジャにおけるライブ・ウィンドウのサムネールを操作するインターフェース及びシステム - Google Patents

Abstract

本発明は、アプリケーション・ウィンドウに対応するサムネールが修正可能であるウィンドウをディスプレイに表示するインターフェース、システム又は方法を提供する。サムネールの修正は、リアルタイムに達成される。また、本発明は、ディスプレイにウィンドウ又はサムネールを表示するインターフェース、システム及び方法を提供するのであるが、その際に、デスクトップ・ウィンドウ・マネジャ（ＤＷＭ）がソース・ウィンドウと宛先ウィンドウとを登録する、及び／又は、ソース・ウィンドウと関連するサムネールを更新又は修正する。特別な効果をサムネールに与えることができる。本発明は、更に、サムネール及びその属性を登録及び／又は修正する方法や、サムネール登録のリストを維持する方法も提供する。

Description

本発明の特徴は、ウィンドウのサムネールに関し、更に詳しくは、ウィンドウ・マネジャにおけるサムネールの操作のためのインターフェース及びシステムに関する。

コンピュータ・システムズは、ユーザがデータを入力するかもしれないか、データを操作するかもしれないか、手続きを活性化してもよい様々なウィンドウを表示する。
１つを超えるアプリケーションを同時に起動する場合、いくつかのウィンドウはコンピューター・ディスプレイ（アプリケーションに対応する個別窓）上に表示されるかもしれない。任意の１つのアプリケーション用マルチウィンドウがさらにあるかもしれない。例えば、さらに表計算プログラムで働く間に、ユーザがワードプロセッシングプログラムへテキストを入力していれば、ディスプレイ上で開いた２つのウィンドウがあるかもしれない。ウィンドウのうちの１つはワードプロセッシングアプリケーション・ウィンドウである。また、第２のウィンドウは表計算プログラムウィンドウである。ユーザがメディア・プレイヤー・アプリケーション上のビデオをさらに見ていれば、メディア・プレイヤー・アプリケーションに対応する付加的なウィンドウがあるだろう。活発なアプリケーションの数が増加するように、コンピューター・ディスプレイ上に表示されるウィンドウの数も増加する。

多数のアプリケーションを同時に使用するユーザは、ディスプレイ上で見られたクラッタからの混乱およびフラストレーションに結びつく、取り乱されたデスクトップを引き起こすディスプレイ上の多くのウィンドウにしばしば直面する。例えば、非常に多くのオーバーラップするウィンドウがディスプレイ上であるかもしれないので、ユーザは、ユーザが異なるアプリケーションでのタスクを終えたいごとに、希望のウィンドウを見つけて時間を浪費しなければならないかもしれない。この問題を緩和するために、ユーザはウィンドウを最小化するか、あるいはクラッタ（またディスプレイ上のウィンドウの数）を減少させるためにアプリケーションをすべて中止するかもしれない。しかしながら、ウィンドウが最小化される場合、ユーザはもはや対応するアプリケーションに対して即時アクセスを持っていない。ウィンドウが最小化された特定のアプリケーションで行為を得る必要がある場合、ユーザは最初に希望のウィンドウを見つけて、ウィンドウを見つけた後に希望のウィンドウを開けなければならない。このプロセスは非常に時間を消費する。同様に、ユーザがデスクトップ・クラッタを取り除くためにアプリケーションをすべて中止すれば、アプリケーションはもはや活発ではない。この場合、ユーザは希望のタスクおよび不用のより多くの時間を終えるために再度アプリケーションを始めなければならない。さらに、アプリケーションが進行中の機能を行なう場合、その機能はアプリケーションが活発でなかった間失われる。

典型的に、アプリケーションウィンドウが最小化される場合、タスクバー・ボタンはアプリケーションが活発であることを示すためにタスクバーに表示されるかもしれない。
アプリケーションが活発であることをタスクバー・ボタンは示すかもしれないが、多くの場合タスクバー・ボタンにアイコンあるいはアプリケーションの名前だけがある。追加情報なしでは、ユーザは、ウィンドウのコンテンツを見るためにウィンドウを開けなければならないだろう。しかしながら、開閉によって、ウィンドウ、単にウィンドウ（例えばウィンドウの同一性を確認すること）のコンテンツをチェックするために、ユーザは、効率と生産性の損失を引き起こす時および労力を浪費する。ユーザが希望のウィンドウを見つけるために多くのウィンドウを開けて閉じなければならないとともに、活発なアプリケーションの数およびウィンドウの数が増加する場合、この問題は悪化する。

したがって、システム用の芸術、およびサムネールおよびサムネール内容のディスプレイでの柔軟性を提供する方法で、ウィンドウまたはアプリケーションのサムネールおよび表現するサムネールを操作することへの便利な標題音楽のアクセスを提供する方法に必要が存在する。さらに、プログラミングインターフェース、および（有効に管理するプログラミングインターフェースおよび道具アプリケーションウィンドウ、インプリメントする、サムネール）方法用の芸術および柔軟な方法でウィンドウとサムネールを表現することに必要がある。

発明の概要

本発明の特徴によると、ディスプレイにウィンドウを表示することにより、上述した１又は複数の問題点に対応するインターフェース、システム又は方法が提供される。アプリケーション・ウィンドウに対応する動的なサムネールも提供され、その場合は、アプリケーション・ウィンドウにおけるコンテンツの修正は、対応する動的サムネールに反映される。アプリケーション・ウィンドウのコンテンツの修正は、対応する動的なサムネールにおいてリアルタイムで反映される。

このドキュメントはリーダを支援するためにセクションに分割される。これらのセクションは次のものを含んでいる：概観；汎用コンピュータ環境；サムネール。

様々な接続が次の銘柄でエレメント間で述べられることは注目される。
それは注目される、これらの接続一般、もし、また指定されなかったならば―〈―そうでなければ〉、直接かもしれないか間接かもしれない、そして、この仕様は、この点で制限するようには意図されない。
概観
Ａ．静的なサムネール
１つのアプローチでは、サムネールはアプリケーションに関係しているかもしれない。サムネールで、アプリケーションウィンドウの小さなバージョンはユーザがウィンドウの近似の内容を識別することを可能にして、アプリケーションウィンドウのオリジナルコンテンツを示すために表示されるかもしれない。しかしながら、これらのサムネールは、アプリケーションウィンドウの最新の内容を提供しないかもしれない。したがって、変更がアプリケーションウィンドウになされた場合、サムネールは時代遅れかもしれないし、アプリケーションウィンドウの実際の内容の特有画像を提供しないかもしれない。したがって、アプリケーションウィンドウを自体開く必要なしに望まれたアプリケーションウィンドウを適切に識別することはユーザにとって難しい。

さらに、サムネールは、内容、職業紹介のディスプレイ、サイジングおよび（または）結果の点から柔軟性を欠く。アプリケーションウィンドウのサムネールは、アプリケーションウィンドウのオリジナルコンテンツの静止画像を提供する。しかしながら、だけでなく、内容を行う、静的・潜在的に時代遅れのままである、また、サムネールの特性および職業紹介は先決されるかもしれないし、ユーザの必要によって（どの時間にも）異ならないかもしれない。

コンピューター・オペレーティングシステムはサムネールのようなユーザ・インターフェース・オブジェクトを管理し監査用プログラム適用業務にユーザ・インターフェース・サービスを提供することの原因であるソフトウェア層を使用する。ソフトウェア層はデスクトップ・ウインドウマネージャ（ＤＷＭ）と呼ばれるかもしれない。レンダーリング・ロジック、入力イベントルーティングおよびデスクトップ・ウインドウマネージャ（ＤＷＭ）のアプリケーションプログラムインターフェイス（ＡＰＩ）は、集団的にユーザ・インターフェース保険証券を具体化する。それは、次にはオペレーティングシステムの全面的なユーザ・エクスペリエンスを定義する。デスクトップを与える際に、ＤＷＭは、典型的には表示画面上に直接描いて調和することにより、ウィンドウの移動ような画面更新を処理する。従って、オーバーラップするウィンドウが閉じられるか移される場合、新しく表示された根本的なウィンドウあるいはデスクトップは塗り重ねられるに違いない。これは時間とリソースが無益に浪費される遅いプロセスである。さらに、典型的に行われるように、ウィンドウがディスプレイ上で特別の位置で、および特別の構成中で直接描かれる場合、ウィンドウの該当イメージは特にその位置および構成でセットされる。ウィンドウの位置か構成への変更は、イメージを塗り重ねることをリソースの大規模な消費に要求するだろう。
Ｂ． ダイナミック（動的）なサムネール
本発明の別の実施例では、インターフェース、システムおよび方法は、デスクトップ・ウインドウマネージャ（ＤＷＭ）がソース・ウィンドウおよび宛先ウィンドウを登録するアプリケーションプログラムインターフェイス（ＡＰＩ）を提供するディスプレイ上にサムネールを表示するために提供される。この例において、宛先ウィンドウはサムネールが与えられるかもしれないウィンドウである。宛先ウィンドウ内に与えられたサムネールは、少なくとも対応するソース・ウィンドウの一部を表わすかもしれない。従って、サムネールは、少なくとも少なくとも宛先ウィンドウの一部に引っ張って行かれたソース・ウィンドウの一部の提供により、ソース・ウィンドウと宛先ウィンドウの間の関連性を表わすかもしれない。ＤＷＭは宛先ウィンドウに相当するソース・ウィンドウおよびＨＷＮＤに対応するウィンドウ・ハンドル（ＨＷＮＤ）を受け取るかもしれない。そのアプリケーションは、ソース・ウィンドウに対応するサムネールのレジストレーションを表わすハンドルをさらに受け取るかもしれない。

本発明の別の実施例では、インターフェース、システムおよび方法は、デスクトップ・ウインドウマネージャ（ＤＷＭ）が対応するソース・ウィンドウに関連したサムネールを更新するか修正するディスプレイ上にサムネールを表示するために提供される。この例において、ＤＷＭはするかもしれない、受信データ、宛先ウィンドウのサイズの定義、サムネールとしての宛先ウィンドウへ引くソース・ウィンドウのリージョン、サムネールの不透明度、サムネールの視程、サムネールなどの特殊効果
本発明の一層の実施例は、サムネール・ハンドルを登録し、サムネール・レジストレーションのリストを維持し、ソース・ウィンドウ（そこではソース・ウィンドウはアプリケーションウィンドウかもしれない）に基づいたサムネールまたは宛先のウィンドウを引き、サムネールのプロパティを更新し、ダイナミックなサムネールを登録しないためにアプリケーションプログラムインターフェイスを輸出することを含むダイナミックなサムネールをさらに提供する。さらに、ソース・ウィンドウへの変更は宛先ウィンドウ中の対応する変更を達成するために自動的に扱われるかもしれない。

様々な接続が次の銘柄でエレメント間で述べられることは注目される。それは注目される、これらの接続一般、もし、また他の方法で指定されなかったならば、直接かもしれないか間接かもしれない、そして、このスペックは、この点で制限するようには意図されない。

本発明の実施例は、ウィンドウあるいはディスプレイ上のサムネールのようなウィンドウの他の表現のような表示要素のディスプレイのコントロールのためにアプリケーションプログラムインターフェイス（ＡＰＩ）、システムおよび方法を提供する。本発明の１つの例では、アプリケーションウィンドウの交互のバージョンはアプリケーションウィンドウのより小さなバージョンで、ディスプレイ上に表示される。アプリケーションウィンドウのより小さなバージョンは、場所に原出願ウィンドウとは異なるディスプレイ上にさらに表示されるかもしれない。あるいは、アプリケーションウィンドウのより小さなバージョンがディスプレイ上に表示される間に、原出願ウィンドウが表示されないように、原出願ウィンドウは最小化されるかもしれない。さらに、例えば、ディスプレイ上の追加スペースが望まれる場合、アプリケーションウィンドウのより小さなバージョンはそれ自体最小化されるかもしれない。アプリケーションウィンドウの交互のバージョンが記述されるようなアプリケーションのより小さなバージョンかもしれない間、アプリケーションウィンドウの交互のバージョンが原出願ウィンドウあるいはユーザの必要に依存する他のサイズより大きいかもしれないことが注目される。

例えば、アプリケーションウィンドウの交互のバージョンはアプリケーションウィンドウのサムネールかもしれない。サムネールは、典型的により大きなグラフィックの小さなイメージか表現、あるいはより大きなイメージ（アプリケーションウィンドウに対応する）の一部である。サムネールは、さらに、サムネールのソースか内容、およびサムネールがソース・ウィンドウからの内容を提供するウィンドウかもしれない宛先ウィンドウを提供して、ソース・ウィンドウ間の関連性を表わすかもしれない。サムネールは、ディスプレイ上の宇宙利用を最小化する間に便利なフォーマットで直ちにいくつかのウィンドウを表示する能力という利点を備えている。さらに、サムネールはイメージとウィンドウをより容易に選択しソートするのに使用されてもよい。

本発明の別の実施例では、要求された時、アプリケーションウィンドウのサムネールか交互のバージョンはディスプレイ上に表示されるかもしれない。例えば、タスクバー・ボタンに関するカーソルを抱くことは、アプリケーションウィンドウのサムネールのディスプレイを呼び出すかもしれない。１例において、サムネールはダイナミックなサムネールで、原出願ウィンドウが修正されるとともに修正されるかもしれない。例えば、アプリケーションウィンドウに行なわれた変更は、アプリケーションウィンドウに対応するダイナミックなサムネールに反映されている。例えば、そのような変更は実時間のダイナミックなサムネールに反映されているかもしれない。

本発明の別の実施例では、サムネールあるいはダイナミックなサムネールは別のウィンドウ、あるいは宛先ウィンドウ内に配列されるかもしれない。
例えば、異なるアプリケーションからの多数のダイナミックなサムネールは宛先ウィンドウに含まれているかもしれない、そのようなもの、宛先ウィンドウディスプレイ・サムネール、から、個々、異なるアプリケーションの。
さらに、宛先ウィンドウに表示されたダイナミックなサムネールのうちのどれでも、対応するアプリケーションウィンドウの現状ステータスを反映するかもしれない。
あるいは、サムネールは別のサムネールに表示されるかもしれない。あるいは、最初のサムネールが３番めのサムネールなどに表示されるかもしれない（順番に）、別のサムネールに表示されるかもしれないように、サムネールが滝のように落とされるかもしれない。

本発明の別の実施例では、システムと方法は画面外のウィンドウを準備するために提供される。その後、ウィンドウの合成は遂行され、したがって、スクリーン上でコンピュータリソースを保存するかもしれない。さらに、画面外で、スクリーン上のウィンドウを合成しているウィンドウの準備は本発明に述べられているようなサムネール機能性を可能にする。
汎用コンピュータ環境
図ＩＡは、発明が実行されるかもしれない適切な計算機システム環境１００の例を例証する。計算機システム環境１００は適切なコンピュータ環境の単なる１つの例で、使用あるいは発明の機能性のスコープに関してどんな制限も示唆するようには意図されない。
また、コンピュータ環境１００はどんな従属性あるいは任意のものあるいは典型的な操作環境１００に例証されたコンポーネントの組合せに関係のある要求も持っているとは解釈されるべきでない。

その発明は、多数の他の汎用または専用の計算機システム環境か構成で使用可能である。有名な計算機システムの例、環境、または、構成、それは発明加算を備えた使用にふさわしいかもしれない、しかし制限されていない、に、パーソナルコンピュータ、サーバーコンピュータ、携帯型のデバイスあるいはラップトップ・デバイス、マルチプロセッサーシステム、マイクロプロセッサー−基づいたシステム、プログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピューター、分散コンピューティング環境、それは、上記のシステムあるいはデバイスのうちのどれでも含んでいる、など。

図ＩＡに関して、発明を実行するための実例となるシステムは汎用コンピューティング装置をコンピューター１１０の形で含んでいる。コンピューター１１０のコンポーネントは含んでいるかもしれない、しかし制限されない、演算処理装置１２０、システムメモリー１３０、および演算処理装置１２０へのシステムメモリーを含む様々なシステムコンポーネントを連結するシステム・バス１２１。システム・バス１２１は、様々なバス方式のうちのどれでも使用して、メモリーバスかメモリーコントローラー、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のいずれかかもしれない。制限ではなく例経由で、そのようなアーキテクチャは産業標準アーキテクチャ（ＩＳＡ）バス（マイクロチャネル・アーキテクチャ（ＭＣＡ）バス）を含んでいる、ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準組織（ＶＥＳＡ）ローカルバス、およびメザニーン・バスとして知られている周辺の構成要素の相互接続（ＰＣＩ）バスを向上させた。

コンピューター１１０は典型的には様々なコンピューター読取り可能な媒体を含んでいる。コンピューター読取り可能な媒体は揮発性・不揮発性の媒体（取外し可能で、非取外し可能な媒体）を含んでいる。制限ではなく例経由で、コンピューター読取り可能な媒体はコンピュータ記憶装置媒体および通信メディアおよび加算を含むかもしれないが、制限されない、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーあるいは他のメモリ技術、ＣＤ−ＲＯＭディジタル・バーサタイル・ディスク（ＤＶＤ）あるいは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置あるいは他の磁気記憶装置、あるいは希望情報を格納するために使用することができ、できる他のミディアム、コンピューター１１０によってアクセスされた。通信メディアは、典型的にはコンピューター読取り可能な命令、データ構造、プログラムモジュールあるいは他のデータを搬送波あるいは他の移送機構のような変調データ信号で具体化し、どんな情報配送媒体も含んでいる。用語「変調データ信号」は、信号中のエンコード情報にような方法で１つあるいはその特性のそれ以上のをセットするか変更される信号を意味する。
制限ではなく例経由で、通信メディア、有線ネットワークか直接の有線接続のようなインターネットを利用している媒体および無線メディアを含んでいる、のように、音響、ＲＦ、赤外線および他の無線メディア。組合せ、上記のもののうちのどれでもコンピューター読取り可能な媒体の範囲内で含まれているべきである。

システムメモリー１３０は、コンピュータ記憶装置媒体を揮発性および（または）読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセス記憶装置（ＲＡＭ）１３２のような不揮発性メモリーの形で含んでいる。操業開始中にのようにコンピューター１１０内のエレメント間の情報を転送するのを支援する基礎的なルーチンを含んでいる基本入出力システム１３３（ＢＩＯＳ）は、ＲＯＭ １３１に典型的に格納される。ＲＡＭ １３２は典型的にはデータおよび（または）直ちにアクセス可能なプログラムモジュールを含んでいる、に、または演算処理装置１２０によってまもなく作動されること制限ではなく例経由で、図１はオペレーティングシステム１３４、アプリケーション・プログラム１３５、他のプログラムモジュール１３６および番組データ１３７を示す。

コンピューター１１０はさらに他のものを含んでいるかもしれない、取外し可能な／非取外し可能、揮発性の／不揮発性のコンピュータ記憶装置媒体。例のみ経由で、図１は、非取外し可能で不揮発性の磁気媒体から読むか、書くハードディスク・ドライブ１４０、取外し可能で不揮発性の磁気ディスク１５２から読むか、書く磁気ディスク装置１５１、およびＣＤ ＲＯＭあるいは他の光学の媒体のような取外し可能で不揮発性の光ディスク１５６から読むか、書く光ディスクドライブ１５５を示す。取外し可能な／非取外し可能な他のもの、揮発性の／不揮発性のコンピュータ記憶装置媒体、それは典型的な操作環境加算の中で使用することができるが、制限されない、磁気カセットテープ、フラッシュ・メモリカード、ディジタル・バーサタイル・ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、など。ハードディスク・ドライブ１４１は、インターフェース１４０のような非リムーバブルメモリ・インターフェースを通ってシステム・バス１２１に典型的に接続される。また、磁気ディスク装置１５１および光ディスクドライブ１５５はインターフェース１５０のようなリムーバブルメモリ・インターフェースによってシステム・バス１２１に典型的に接続される。

上に議論され、図ＩＡで例証されたドライブおよびそれらの関連するコンピュータ記憶装置媒体は、コンピューター１１０のためにコンピューター読取り可能な命令、データ構造、プログラムモジュールおよび他のデータの記憶を提供する。図ＩＡでは、例えば、ハードディスク・ドライブ１４１は、オペレーティングシステム１４４、アプリケーション・プログラム１４５、他のプログラムモジュール１４６および番組データ１４７の格納として例証される。これらのコンポーネントが同じでありえることに注目する、として、あるいはオペレーティングシステム１３４、アプリケーション・プログラム１３５、他のプログラムモジュール１３６および番組データ１３７と異なるオペレーティングシステム１４４、アプリケーション・プログラム１４５、他のプログラムモジュール１４６および番組データ１４７は、最小では、それらが異なるコピーであることを例証するためにここで異なる数を与えられる。ユーザは、マウス、トラックボールあるいはタッチパッドと一般に呼ばれるキーボード１６２のような入力装置およびポインティング・デバイス１６１によってコンピューター２０へコマンドと情報を入力してもよい。他の入力装置（図示せず）はマイクロホン、ジョイスティック、ゲーム・パッド、衛星放送アンテナ、スキャナーなどを含んでいるかもしれない。これらおよび他の入力装置は、ユーザ入力によって演算処理装置１２０にしばしば接続される、システム・バスにつながれるが、パラレルポート、ゲームポートあるいはユニバーサル・シリアル・バス（ＵＳＢ）のような、他のインターフェースおよびバス構造によって接続されるかもしれない１６０を接続する。モニター１９１あるいは他のタイプの表示装置もビデオインタフェース１９０のようなインターフェース経由でシステム・バス１２１に接続される。モニターに加えて、コンピューターは、さらにスピーカー１９７およびプリンタ１９６のような他の周辺の出力デバイスを含んでいるかもしれない。それはアウトプット周辺インタフェース１９０によって接続されるかもしれない。

コンピューター１１０は、リモートコンピューター１８０のような１つ以上のリモートコンピューターへの論理結合を使用して、ネットワーク化された環境中で作動するかもしれない。リモートコンピューター１８０は、パーソナルコンピュータ、サーバー、ルーター、ネットワークＰＣ、貴族デバイスあるいは他の共通ネットワークノードで典型的には多数含んでいる。あるいは、要素はすべて上に記述した、記憶装置デバイス１８１だけは図ＩＡで例証されたが、コンピューター１１０に関連のある図ＩＡで描かれた論理結合はローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含んでいるが、さらに他のネットワークを含んでいるかもしれない。そのようなネットワーキング環境はオフィスで普通である、企業−広いコンピューターネットワーク、イントラネットおよびインターネット。

ＬＡＮネットワーキング環境の中で使用された時、コンピューター１１０はネットワークインターフェイスまたはアダプターの１７０によってＬＡＮ １７１に接続される。
ＷＡＮネットワーキング環境の中で使用された時、コンピューター１１０は典型的にはモデム１７２あるいはインターネットのようなＷＡＮ １７３の上のコミュニケーションを確立するための他の手段を含んでいる。モデム１７２（それは内部かもしれないか外部かもしれない）は、ユーザ入力インターフェース１６０経由のシステム・バス１２１、あるいは他の適切な機構に接続されるかもしれない。ネットワーク化された環境では、コンピューター１１０（すなわちそれの部分）へのプログラムモジュールに描かれた関係詞は、遠隔記憶記憶装置に格納されるかもしれない。制限ではなく例経由で、図ＩＡはメモリ・デバイス１８１上で駐在するとして遠隔のアプリケーション・プログラム１８５を例証する。示されたネットワーク接続がコンピューター間の通信リンクが使用されてもよいと確証する典型的・他の手段であることが認識されるだろう。

示されたネットワーク接続がコンピューター間の通信リンクを使用することができると確証する典型的・他の手段であることは認識されるだろう。ＴＣＰ／ＩＰ、イーサネット（登録商標）、ＦＴＰ、ＨＴＴＰなどのような様々な有名なプロトコルのうちのいずれかの存在有無は推定される。また、システムはクライアント中で操作することができる−ユーザがウェブ・ベースのサーバーからウェブ・ページを検索することを可能にするサーバー構成。様々な従来のウェブ・ブラウザのうちのどれはウェブ・ページにデータを表示し操作するために使用することができる。

プログラミングインターフェース（より単に「インターフェース」）は、任意の機構、プロセス、コードの１つ以上のセグメントが１時までに提供される機能性と通信するかあるいはアクセスすることを可能にするためのプロトコルあるいはコードのより多くの他のセグメントとして見られるかもしれない。あるいは、プログラミングインターフェースは、他のコンポーネントに１つ以上の機構、方法、関数呼出し、モジュールなどへの通信するカップリングに有能なシステムのコンポーネントに１つ以上の機構、方法、関数呼出し、モジュール、オブジェクトなどとして見られるかもしれない。用語「コードのセグメント」は、前の文で１つ以上の命令あるいは命令行を含むように意図され含んでいる、例えばコード・モジュール、オブジェクト、サブルーチン、機能など、用語にかかわらず、適用された、あるいは、コードセグメントが別々にコンパイルされても、あるいは、コードセグメントが実行時システムかプロセスで利用されても、コードセグメントがソース、中間物あるいはオブジェクトコードとして提供されても、あるいは、それらが同じか異なるマシンに置かれるか、多数のマシンを横切って分配されても、あるいはかどうか、コードのセグメントによって表わされる機能性、全くハードウェア、あるいはハードウェアとソフトウェアの組み合わせ中で全くソフトウェア中でインプリメントされる。

概念的に、図ＩＢあるいは図の中で１Ｃ示されるように、プログラミングインターフェースは属に関して見られるかもしれない。図ＩＢは、第１と第２コードセグメントが通信する導管としてインターフェース、インターフェース１を例証する。図１Ｃはインターフェース・オブジェクトＩｌおよび１２（それらは１番目と２番目コードセグメントの一部かもしれないし、でないかもしれない）を含むとしてインターフェースを例証する。それはシステムの第１と第２コードセグメントがミディアムＭによって通信することを可能にする。図１Ｃの視界では、人は、Ｉｌと１２がミディアムＭを加えてインターフェースを含むことにそれが反対すると同システムの個別のインターフェースおよび一つとしてＩｌと１２がさらに思うかもしれないことにインターフェースが反対すると思うかもしれない。図、ＩＢおよび１Ｃは、フロー（単に一方向（あるいは下記に述べられるような情報の流れはない）の中にインプリメンテーションが情報の流れを持っているかもしれないか、単に一面でインターフェース・オブジェクトを持っているかもしれなくてある）の両側の双方向フローおよびインターフェースを示す。制限ではなく例経由で、名付ける、アプリケーションプログラムインターフェイス（ＡＰＩ）、入口点、方法、機能、サブルーチン、リモート・プロシージャ・コールおよびコンポーネント・オブジェクト・モデル（ＣＯＭ）インターフェースのように、プログラミングインターフェースの定義内に包含される。

そのようなプログラミングインターフェースの実施例は方法を含んでいるかもしれない、それによって、第２のコードセグメントへの最初のコードセグメント送信情報（ここで（コマンド、要求する、など）「情報」はその最も広い意味の中で使用され、データを含んでいる）；それによって第２のコードセグメントが情報を得る方法；また構造、シーケンス、シンタックス、構成、スキーマ、タイミングおよび情報の内容。この点では、根本的な輸送培地はそれ自身インターフェースのオペレーションに些細かもしれない、かどうか、ミディアム、インターネットを利用している、あるいはワイヤレス、あるいは両方の組合せ、情報が運ばれる限り、インターフェースによって定義された方法。あるシチュエーションで、１つのコードセグメントが別のコードセグメントによって行なわれた機能性に単にアクセスする場合ので、情報転送が別の機構（例えば、バッファーに置かれた情報、ファイルなどは、コードセグメント間の情報の流れから分離する）によってか、あるいは存在しないかもしれないので、情報は１あるいは従来の感覚の両方の方角に判決を下されないかもしれない。これらの実施例のうちのどれあるいはすべてでも与えられたシチュエーションで重要かもしれない、例えば、コードセグメントが疎結合か密結合の構成中のシステムの一部かどうかに依存すること、それで、このリストは、実例となり、制限しない、と考えられるべきである。

プログラミングインターフェースについてのこの概念は当業者に知られており、発明の先の詳述から明らかである。しかしながら、プログラミングインターフェースをインプリメントする他の方法がある、また、もし明らかに除外されなかったならば、これらはこのスペックの終わりに述べられたクレームによって包含されるようにまた意図される。他のそのような方法は、もっと精巧かあるいは図ＩＢおよび１Ｃの極度に単純化した視界より複雑なように見えるかもしれない。しかし、それらは、同じ全面的な結果を遂行するためにそれにもかかわらず相似関数を行なう。我々は、今プログラミングインターフェースのいくつかの実例となる代替インプリメンテーションについて概説するだろう。
くくり出し（ファクタリング）
あるコードセグメントから別のコードセグメントまでのコミュニケーションは、多数の離散的なコミュニケーションへコミュニケーションを壊すことにより間接的に遂行されるかもしれない。これは、図ＩＤおよびＩＥで概略的に描かれる。示されると、いくつかのインターフェースは、機能性の割り切れるセットの点から記述することができる。したがって、図のインターフェース機能性、ちょうど一つが数学上２回３回２４、あるいは２回を提供するかもしれないように、ＩＢおよび１Ｃは同じ結果を達成するために因数分解されるかもしれない、２．従って、図ＩＤで例証されるように、インターフェース・インターフェース１によって提供される機能は同じ結果を達成する間にインターフェースのコミュニケーションを複合のインターフェース、インターフェースＩＡ、インターフェースＩＢ、インターフェースの１Ｃなどに変換するために細分されるかもしれない。図ＩＥの中で例証されるように、インターフェースＩｌによって提供される機能は複合のインターフェースｈａへ細分されるかもしれない、Ｈｂ、彼、など、同じ結果を達成している間。同様に、最初のコードセグメントから情報を得る、第２のコードセグメントのインターフェース１２は、複合のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどの要因として考慮されるかもしれない。代理商として働く場合、第１のコードセグメントで含まれたインターフェースの数は第２のコードセグメントで含まれたインターフェースの数と一致する必要はない。図の場合のどちらかでは、ＩＤおよびＩＥ、インターフェース、インターフェース１の機能的な精神およびＩｌは、それぞれ図ＩＢおよび１Ｃでのと同じ物ままである。
インターフェースのくくり出しはさらに結合性の数学的なプロパティ、交換のプロパティおよび他のプロパティにくくり出しが認識するのが難しいかもしれないそのように続くかもしれない。例えば、オペレーションの順序は些細かもしれない。また、従って、インターフェースによって実行された機能は、もう１個のコードあるいはインターフェースによって、インターフェースに到着する進歩中でよく実行されるかもしれないか、システムの個別のコンポーネントによって行なわれるかもしれない。さらに、プログラムする芸術における通常の熟練のうちの１つは、同じ結果を達成する異なる関数呼出しを行う様々な方法があることを認識することができる。
再定義
ある場合には、意図した結果をまだ遂行する間にプログラミングインターフェースのある実施例（例えばパラメーター）を無視するか、加えるか、再定義することが可能かもしれない。これは図ＩＦおよびＩＧの中で例証される。例えば、図ＩＢのインターフェース、インターフェース１が関数呼出し二乗（インプット、精度、アウトプット）、３つのパラメーター、インプット、精度およびアウトプットを含んでいる呼び出し、および第１のコードセグメントから第２のコードセグメントまでどれが出されるかを含むと仮定する。図ＩＦの中で示されるように、中央のパラメーターの精度が与えられたシナリオ中の関係である場合、それ、できた、かえって都合がよい、無視されるか、無意味な（このシチュエーションで）パラメーターとさらに取り替えられる。一つはさらに重要でない付加パラメータを加えるかもしれない。いずれにしても、インプットが第２のコードセグメントによって２乗された後、アウトプットが返される限り、二乗の機能性は達成することができる。精度は、非常によく計算機システムのある下流か他の部分への意味のあるパラメーターかもしれない；しかしながら、一旦精度が二乗を計算する狭い目的に必要ではないことが認識されれば、それは交換されるかもしれないし無視されるかもしれない。例えば、有効な精度価値を判決を下す代わりに、結果に悪影響を及ぼさずに、生年月日のような無意味な値を判決を下すことができるかもしれない。同様に、図ＩＧの中で示されるように、インターフェースＩｌはインターフェースへのパラメーターを無視するか加えると再定義されて、インターフェースＨ’と取り替えられる。インターフェース１２は、不必要なパラメーター、あるいは他のところに処理されるかもしれないパラメーターを無視すると再定義されて、インターフェース’１２として同様に再定義されるかもしれない。ここのポイントは、ある場合には、プログラミングインターフェースがパラメーターのような実施例を含むかもしれないということである。それはある目的に必要とされない。したがって、それらは無視されるかもしれないし、再定義されるかもしれないか、他の目的のためにどこか他のところに処理されるかもしれない。
インライン・コーディング
それらの間の「インターフェース」が形式を変更するように、２つの別個のコード・モジュールの機能性のうちのいくらかあるいはすべてを合併することも実現可能かもしれない。例えば、図ＩＢおよび１Ｃの機能性は図ＩＨおよびＩＩの機能性にそれぞれ変換されるかもしれない。図ＩＨの中で、前、図ＩＢの第１と第２コードセグメントはそれらを両方とも含んでいるモジュールへ合併される。この場合、コードセグメントは、まだ互いに伝達しているかもしれない。しかし、インターフェースは、シングルモジュールに、よりふさわしい形式に適しているかもしれない。したがって、例えば、儀礼的訪問とリターンのステートメントはもはや必要ではないかもしれない。しかし、インターフェース１を接続するのに準ずる同様の処理あるいはレスポンスはまだ有効かもしれない。同様に、図ＩＩの中で示されて、図１Ｃからのインターフェース１２の一部（あるいは万物）はインターフェースＩｌへインラインで、インターフェースＨを形成するために書かれるかもしれない。」例証されるように、インターフェース１２はＩ２ａとＩ２ｂに分割される。また、インターフェース部分Ｉ２ａはインターフェースＨを形成するためにインターフェースＩｌに従ってコード化された。」具体的な例については、図１ＣからのインターフェースＩｌが関数呼出し二乗（インプット、アウトプット）（それはインターフェース１２によって受け取られる）を行なうと思う、どれ、値の処理がインプット（インプットの二乗の計算）で第２のコードセグメントによって通過していった後、パス、後ろに、アウトプットを備えた２乗された結果。そのような場合では、第２のコードセグメント（２乗するインプット）によって行なわれた処理は、インターフェースへの呼び出しのない最初のコードセグメントによって行なうことができる。
離婚
あるコードセグメントから別のコードセグメントまでのコミュニケーションは、多数の離散的なコミュニケーションへコミュニケーションを壊すことにより間接的に遂行されるかもしれない。これは、図ＩＪおよびＩＫの中で概略的に描かれる。図Ｕの中で示されるように、１以上個のコード（それらが機能性および（または）オリジナルのインターフェースからのインターフェース機能を離婚させるので、離婚インターフェース）はそれらを異なるインターフェースに順応させるために最初のインターフェース（インターフェース１）上のコミュニケーションを変換するために提供される、この場合、インターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２ＢとＩｎｔｅｒｆａｃｅ２Ｃ。これは行われるかもしれない、例えば、インターフェース１に従って例えば、オペレーティングシステムを通信するように設計されたアプリケーションのインストールベースがあるところに、プロトコルを作る、しかし、その後、オペレーティングシステムはこの場合異なるインターフェースを使用するために変更される、インターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２ＢとＩｎｔｅｒｆａｃｅ２Ｃ。ポイントは、第２のコードセグメントによって使用されるオリジナルのインターフェースが、それが第１のコードセグメントによって使用されるインターフェースともはや互換性をもたないそのように変更されるということである、それで１つの、仲介、古く新しいインターフェースを互換性をもつようにするために使用される。同様に、図ＩＫの中で示されるように、３番めのコードセグメントは、インターフェースＩｌから知らせを受ける離婚インターフェースＤＩｌおよびジ２で働くのデザインを変更されて、例えばインターフェースＩ２ａおよびＩ２ｂにインターフェース機能性を送信する離婚インターフェース・ジ２で開始することができる、しかし同じ機能的な結果を提供すること 同様に、同じか同様の機能的な結果を提供している間、ＤＩｌとジ２はインターフェースＩｌおよび図のうちの１２の機能性を新しいオペレーティングシステムに１Ｃ翻訳するためにともに働くかもしれない。
書換え
しかし、別の可能な変形は、インターフェース機能性を他のものだがどれが同じ全面的な結果を達成するかに取り替えるためにダイナミックにコードを書き直すことである。例えば、実行環境（．Ｎｅｔフレーム・ワーク、Ｊａｖａ（登録商標）実行時環境あるいは他の同様のランタイム・タイプ環境によって提供されるそのような）中のジャスティン時間（ＪＩＴ）コンパイラーかインタープリターに中間言語（例えばマイクロソフトＩＬ、Ｊａｖａ（登録商標） ＢｙｔｅＣｏｄｅなど）で示されたコードセグメントが提供されるシステムがあるかもしれない。ＪＩＴコンパイラーはダイナミックにつまり、それらを第２のコードセグメント（オリジナルあるいは異なる別のコードセグメントのいずれか）によって要求されるかもしれないのと同じくらい異なるインターフェースに順応させるためにコミュニケーションを第１のコードセグメントから第２のコードセグメントに変換するように書かれるかもしれない。これは図ＩＬおよびＩＭで描かれる。図ＩＬで見ることができるように、このアプローチは上に記述された離婚シナリオに似ている。それは行われるかもしれない、例えば、どこで、アプリケーションのインストールベース、インターフェース１に従ってオペレーティングシステムと通信するように設計されている、プロトコルを作る、しかし、その後、オペレーティングシステムは異なるインターフェースを使用するために変更される。
オペレーティングシステムの新しいインターフェースへのインストールベース・アプリケーションから急いでコミュニケーションを準拠するためにＪＩＴコンパイラーを使用することができるかもしれない。図ＩＭの中で描かれるように、ダイナミックにインターフェースを書き直すこのアプローチはダイナミックに代理商として働くかあるいはそうでなければ、同様にインターフェースを変更するために適用されるかもしれない。

代替実施例によってインターフェースと同じか同様である結果を達成するための上記シナリオも、様々な方法で連続的に、並列中で、あるいは他の中間コードで組み合わせられるかもしれないことはさらに注目される。したがって、上に示された代替実施例は相互排除でなく、図ＩＢおよび１Ｃの中で示された総括的なシナリオに同じか等価なシナリオを生産するために混合され、一致し、組み合わせられるかもしれない。さらに、それは注目される、それはそこで、ほとんどのプログラミングコンストラクトでのように、ここに記述されないかもしれないが、それにもかかわらず発明の趣旨およびスコープによって表わされるインターフェースの同じか同様の機能性を達成する他の同様の方法である、つまり、それが少なくとも部分的にそばに表わされた機能性、および可能にされた有利な結果であることは注目される、インターフェース、それはインターフェースの値の基礎となる。
サムネール
図４Ａおよび４Ｂは、アプリケーションウィンドウのサムネールを提供する際に本発明のアプリケーションの１つの例を実証する。図４Ａの例では、タスクバー・ボタンを含んでいるタスクバー４００は例証される。タスクバー・ボタンの各々は活発なアプリケーションに相当する。タスクバー・ボタン４０２はコンピューター上で現在作動する一つ珠アプリケーション・プログラムに相当する。同様に、タスクバー・ボタン４０３はワードプロセッシングアプリケーション・プログラム・ウィンドウに相当する。タスクバー・ボタン４０５はメディア・プレイヤー・アプリケーション・プログラム・ウィンドウに相当する。また、タスクバー・ボタン４０６は計算機アプリケーション・プログラム・ウィンドウに相当する。一つ珠サムネール４０１は一つ珠アプリケーション・プログラム・ウィンドウのために提供される。また、メディア・プレイヤー・サムネール４０４はメディア・プレイヤー・アプリケーション・プログラムのために提供される。対応するサムネールは様々な方法で呼び出されるかもしれない。１つの非制限的な例では、サムネールは対応するタスクバー・ボタンに関するカーソルを抱くことにより呼び出されるかもしれない。例えば、一つ珠サムネール４０１は一つ珠タスクバー・ボタン４０２に関するカーソルを抱くことにより呼び出されるかもしれない。

図４Ａの中で例証されて、ダイナミックなサムネールは更新されて、提供するかもしれないか、あるいはアプリケーション・プログラムに対応する内容を「実践する」。例えば、メディア・プレイヤー・アプリケーションはビデオを再生しているかもしれない。メディア・プレイヤー・アプリケーションウィンドウ（図示せず）中のビデオ・プレーとして、ビデオは、さらにメディア・プレイヤー・サムネール４０４に遊ぶ。メディア・プレイヤー・アプリケーションウィンドウがそれ自体最小化される場合、メディア・プレイヤー・サムネール４０４は最小化前にメディア・プレイヤー・アプリケーションウィンドウ中の最終場面を表示するかもしれない。あるいは、たとえメディア・プレイヤー・アプリケーションウィンドウがそれ自体最小化されても、それがメディア・プレイヤー・アプリケーションで遊び続けるとともに、メディア・プレイヤー・サムネール４０４はビデオを表示し続けるかもしれない。

図４Ｂは、本発明のサムネールの別の例を例証する。タスクバー４１０は、一つ珠アプリケーションウィンドウ（図示せず）に対応する一つ珠タスクバー・ボタン４１１、ワードプロセッシングアプリケーション・ウィンドウ（図示せず）に対応するワードプロセシング・タスクバー・ボタン４１２、メディア・プレイヤー・アプリケーションウィンドウ（図示せず）に対応するメディア・プレイヤー・タスクバー・ボタン４１３、および計算機アプリケーションウィンドウ（図示せず）に対応する計算機タスクバー・ボタン４１４を含んで例証される。この例において、計算機サムネール４１５は提供される。計算機サムネール４１５は、計算機アプリケーションウィンドウの現在と更新された内容を表示する。本発明の１つの実施例では、計算機サムネール４１５はさらにアプリケーションウィンドウを更新するかもしれない。例えば、計算は数学的な結果を達成するために計算機サムネール４１５によって行なわれるかもしれない。この結果は計算機アプリケーションウィンドウ（図示せず）にも計算機サムネール４１５にも表示することができる。この例において、「＝」キーは計算機サムネール４１５に選択されている。また、結果は計算機サムネール（つまり「４」）に表示される。たとえ計算が計算機サムネール４１５によって行なわれたとしても、この結果も、計算機アプリケーションウィンドウに同様に（図示せず）映っているかもしれない。

図５は、サムネールがＡＬＴ−ＴＡＢメニューに表示される本発明のサムネールの別のアプリケーションを例証する。図５が例証するとともに、ディスプレイ５００はアプリケーションウィンドウを表示する。この場合、計算機アプリケーションウィンドウ５０２の一部および一つ珠アプリケーションウィンドウ５０１の一部は、ディスプレイ５００上で目に見える。アプリケーションの各々はタスクバーに対応するタスクバー・ボタンを持っている。計算機アプリケーションは対応する計算機タスクバー・ボタン５０３を持っている。また、一つ珠アプリケーションには対応する一つ珠タスクバー・ボタン５０４がある。さらに、メディア・プレイヤー・アプリケーションは活発である（図示せず）。また、さらに、対応するメディア・プレイヤー・タスクバー・ボタン５０６はタスクバーの中にある。

図５で示された例において、ＡＬＴ−ＴＡＢメニュー５０５は、それが活発なアプリケーションのダイナミックなサムネールを表示すると規定される。この例に、ダイナミックなサムネール・ディスプレイの各々は、対応するアプリケーションウィンドウの内容を「実践する」（つまり、更新された）。ダイナミックなサムネール内容は実時間において更新されるかもしれない。アプリケーションウィンドウが修正されるか更新されるとともに、対応するダイナミックなサムネールも従って更新されるかもしれない。ダイナミックなサムネールの更新も実時間において遂行されるかもしれない。この例において、ＡＬＴ−ＴＡＢメニュー５０５はダイナミックなサムネールを含んでいる、個々、対応するアプリケーションのアプリケーションウィンドウがディスプレイ上で目に見えても目に見えなくても、活発なアプリケーションに。計算機サムネール５０７、メディア・プレイヤー・サムネール５０８および一つ珠サムネール５０９は、ＡＬＴ−ＴＡＢメニュー５０５に一つ珠サムネール５０９を選択して例証される。ダイナミックなサムネールの各々は「実際の」内容を提供するかもしれない。例えば、ビデオは実時間のメディア・プレイヤー・サムネール５０８に遊んでいるかもしれない。

図２Ａおよび２Ｂはサンプル表示のコンポーネントを例証するダイアグラムである。
デスクトップは、エレメント２００としてシーングラフまたはディスプレイの木の図２Ａの中で表わされ、デスクトップの壁紙２０１と２アプリケーション、計算機２０２および一つ珠２０３を含んでいる。さらに、デスクトップはさらにタスクバー２０８を含んでいる。表現のこの方法では、ウィンドウおよび個別窓のクライアント領域のまわりのフレームはすべてシーングラフの一部である。ウィンドウ移動はディスプレイ木の変わる変換価値になる。この例におけるアプリケーションの各々はウィンドウフレーム２０４、２０５をそれぞれ含んでいる、そしてウィンドウ内容２０６、２０７、それぞれ。タスクバー２０８はウィンドウ内容２０９を含んでいる。図２Ａでは、ディスプレイ上のエレメントは左から右まで与えられる。従って、デスクトップの壁紙２０１は、一つ珠２０２アプリケーションウィンドウの後ろに与えられる計算機２０３アプリケーションウィンドウの後ろに与えられる。

図２Ｂは図２ Ａの中で表わされるようなディスプレイを例証する。そのディスプレイはバックグラウンドにデスクトップの壁紙２２０を含んでいる。計算機アプリケーションウィンドウ２２２はデスクトップの壁紙の前に表示される。また、一つ珠アプリケーションウィンドウ２２１は、計算機アプリケーションウィンドウ２２２およびデスクトップの壁紙２２０の前に表示される。図２Ｂの中で示されるように、アプリケーションウィンドウの各々はタスクバー・ボタンによってタスクバー２２５に表わされるかもしれない。この例において、計算機アプリケーションはタスクバー・ボタン２２３によってタスクバー２２５に表わされる。また、一つ珠アプリケーション・プログラムはタスクバー・ボタン２２４によってタスクバー２２５に表わされる。計算機アプリケーションウィンドウ２２２および一つ珠アプリケーションウィンドウ２２１の各々は、デスクトップの壁紙２２０に表示されるようなウィンドウフレームとウィンドウの内容を含んでいる。

図２Ａの中で描かれるような木のどんなサブノードも、木の別のノードの内容として使用されてもよい。そうすることによって、１部の木のコンテンツは、別の場所で木のどこか他のところに見られるかもしれない。別の場所で木のノードの演出を木のどこか他のところに達成する多くの方法がある。１つの非リミッティング例として、視覚的なブラシは使用されてもよい。「ＶｉｓｕａｌＢｒｕｓｈ」は技術である、常にシーングラフの既存の部分を参考文献として載せた、しかし位置、スケール、ローテーション、不透明度、効力などのようなグラフィックスコンテキストの「現在の」セットでそれを与えることこれは、他のところに与えられる１つの場所に与えられた木の一部を引き起こす。例えば、計算機アプリケーションウィンドウのダイナミックなサムネールが望まれる場合、適切なプログラミングインターフェース（例えばアプリケーションプログラムインターフェイスかＡＰＩ）はサムネール・ホストＨＷＮＤあるいはウィンドウ・ハンドルを提供するために呼ばれるかもしれない。この例は図３Ａおよび３Ｂの中で実証される。
［５８］ 図３Ａは、本発明のディスプレイのコンポーネントの例を例証するシーングラフまたはディスプレイの樹形図である。デスクトップはエレメントまたはノードの３００として図３ Ａの中で表わされ、デスクトップの壁紙３０１と２アプリケーション、計算機３０２および一つ珠３０３を含んでいる。この例におけるアプリケーションの各々はウィンドウフレーム３０５、３０６をそれぞれ含んでいる、そしてウィンドウ内容３０７、３０８、それぞれ。この例におけるデスクトップは、さらにタスクバー３０７を含んでいる。

この例において、計算機アプリケーションウィンドウのサムネールは適切なＡＰＩを呼ぶことにより提供される。図３Ａの中で例証されるように、サムネール・ホストＨＷＮＤ３０４ウィンドウ・ハンドルはアプリケーションによって作成され、計算機アプリケーションのようなアプリケーションのサムネールを登録してもよい。例えば、図３Ａでは、タスクバー３０７はサムネール・ホストＨＷＮＤ ３０４およびウィンドウ内容３１０を含んでいる。サムネール・ホストＨＷＮＤ ３０４は計算機サムネール３１１を含んでおり、サムネール・ホストにアプリケーションウィンドウのサムネールを付けてもよい。図３ Ａの中の点のある矢は、サムネール・ホストＨＷＮＤ ３０４の計算機サムネール３１１が後ろに指すか計算機アプリケーションウィンドウからの計算機を描き直すことを例証する。その結果、「実際の」ダイナミックなサムネールは、それがアプリケーションウィンドウ内容についての単に静的な見方ではなく対応するアプリケーションウィンドウ（この場合計算機アプリケーションウィンドウ）の最新の内容を示すと規定される。

図２Ａの例でのように、図３ Ａの中で表わされたディスプレイ上の要素は、左から右まで与えられる。従って、デスクトップの壁紙３０１は、一つ珠３０３アプリケーションウィンドウおよびタスクバー２０８の後ろに与えられる計算機３０２アプリケーションウィンドウの後ろに与えられる。図３Ｂは図３Ａに対応するディスプレイを実証する。図３Ｂが例証するとともに、ディスプレイはバックグラウンドにデスクトップの壁紙３２０を含んでいる。計算機アプリケーションウィンドウ３２２はデスクトップの壁紙３２０の前に表示される。また、一つ珠アプリケーションウィンドウ３２１は、計算機アプリケーションウィンドウ３２２およびデスクトップの壁紙３２０の前に表示される。さらに、タスクバー３２６が表示される。アプリケーションの各々はタスクバー３２６に対応するタスクバー・ボタンに関係している。この例において、計算機アプリケーションはタスクバー・ボタン３２４に関係している。また、一つ珠アプリケーションはタスクバー・ボタン３２５に関係している。さらに、図３Ｂは、サムネールが、それが計算機アプリケーションに関係していると規定されることを例証する。計算機アプリケーション・プログラムおよびウィンドウ３２２はタスクバー３２６および一つ珠アプリケーション・プログラムにタスクバー・ボタン３２４に関係している。また、ウィンドウ３２１はタスクバー・ボタン３２５に関係している。

さらに図３Ｂの中で例証された、計算機アプリケーションのダイナミックなサムネール３２３である’ウィンドウ３２２。サムネール３２３は、後ろに指すか、ウィンドウフレーム３０５および図３ Ａの中で描かれるような計算機アプリケーション３０２のウィンドウ内容３０８を描き直すサムネール・ホストＨＷＮＤ ３０４の計算機サムネール・ノード３１１によって提供される。結果は、それがそうであるという計算機アプリケーションウィンドウ３２２のダイナミックなサムネール３２３である「生きている。」つまり、対応する変更がアプリケーションウィンドウ自体になされるとともに、サムネールが修正される。図３Ｂの中で例証されるように、計算機アプリケーションウィンドウ３２２に計算された「２４３」の値も、対応するサムネール３２３に反映されている。

本発明の実施例では、ダイナミックなサムネールはサムネールのレジストレーション、登録解除（登録解除）および更新するプロパティによって達成される。そのようなレジストレーション、登録解除、およびサムネールの更新するプロパティか、変更は、デスクトップ・ウインドウマネージャ（ＤＷＭ）の中でアプリケーションプログラムインターフェイス（ＡＰＩ）によって遂行されるかもしれない。典型的な３つのＡＰＩが本発明のサムネールを達成すると説明される。ＡＰＩエグザンプル１ − サムネールのレジストレーション
サムネールはウィンドウ（例えばアプリケーションウィンドウ）から生成されるかもしれない。アプリケーションウィンドウがサムネールの内容に基礎を提供するとともに、アプリケーションウィンドウはこの場合、ソース・ウィンドウである。１例において、サムネールはアプリケーションウィンドウの小型化したバージョンで、アプリケーションウィンドウの全コンテンツを含んでいる。あるいは、サムネールは、ソース・ウィンドウの選択された部分だけを含んでいるかもしれない。

ソース・ウィンドウからのサムネールの内容は別のエリアに翻訳される。この第２のエリアは、ソース・ウィンドウに基づいたサムネールの内容を提供する宛先ウィンドウと指示される。宛先ウィンドウは、サムネール自体の基礎を形成するかもしれない。例えば、アプリケーションウィンドウに基づいたサムネールを表示するために、アプリケーションウィンドウ以外の場所の小さなウィンドウフレーム、ディスプレイでの指定地域あるいはポップアップ・メニューは、宛先ウィンドウとして使用されてもよい。

サムネールが登録される場合、ソース・ウィンドウと宛先ウィンドウの関係を築くオペレーションは行なわれるかもしれない。宛先ウィンドウを指定するウィンドウ・ハンドル（ＨＷＮＤ）が指定されるかもしれない。指定された宛先ウィンドウは、サムネール・レンダーリングのターゲットとして役立つかもしれないし、サムネールを呼ぶか登録するプロセスによって所有される。サムネールを登録するプロセスがさらに宛先ウィンドウを所有する場合、他のアプリケーションによるアプリケーションの望まれない変更は回避することができる。同様に、ソース・ウィンドウ用のＨＷＮＤも指定されるかもしれない。
［６６］ サムネールのキャッシュに入れられたビットマップのサイズも指定されるかもしれない。例えば、システムにソース・ウィンドウの最後の既知のビットマップのことが通知されるように、最小サイズは示されるかもしれない。このように、ソース・ウィンドウが続いて最小化され、ディスプレイ上で目に見えない場合、ウィンドウのビットマップはしかしながら保存される。また、サムネールはまだ利用可能である。サイズは、呼び出しのアプリケーションの必要によって異なるかもしれない。同じソース・ウィンドウの多重登録がある場合、プロセスはどのサムネール・サイズが現在のニーズに基づいて当てはまるか決めるかもしれない。例えば、サムネール・サイズを変える多重登録の場合には、最大のサイズは使用されてもよい。

ＡＰＩは、さらにサムネールのレジストレーションを表わすハンドルを含んでいるかもしれない。このハンドルは、呼び出しをサムネールが、それが登録されたプロセスからのみ続いて未登録かもしれないそのように出しているプロセスに特有かもしれない。

サムネールを登録するためのＡＰＩの一例は以下のとおりである：

その中でｄｓｔＷｉｎｄｏｗは宛先ウィンドウを表わす、ｓｒｃＷｉｎｄｏｗはソース・ウィンドウを表わす、ｌｐＭｉｎｉｍｉｚｅｄＳｉｚｅはサイズを表わす、いったんｓｒｃウィンドウが最小化されれば、ソース・ウィンドウ（ｓｒｃウィンドウ）およびｌｐｈＴｈｕｍｂｎａｉｌの最後の既知のビットマップがそうであるシステム・キャッシュ、呼び出しで作られたレジストレーションを表わすユニークなハンドルを表わす返される値。ＡＰＩエグザンプル２ − 修正するサムネール・プロパティあるいはセットするサムネール・プロパティ
サムネール・レジストレーションの後に、ソース・ウィンドウからの内容（すなわちそれの部分）はサムネールとして宛先ウィンドウに置かれる。例えば、呼ばれた時、アップデート・サムネール・プロパティＡＰＩは宛先ウィンドウ中のサムネールのレンダーリングのプロパティを修正するかもしれないし更新するかもしれない。例えば、ＵｐｄａｔｅＴｈｕｍｂｎａｉｌプロパティは視程、形、長方形などのようなサムネールのプロパティをセットするために使用されてもよい。アップデート・サムネール・プロパティＡＰＩは、更新されるサムネールのハンドルを示すかもしれない。サムネールへの最新版は、サムネールのどんな変更も含んでいる、サムネールのポジショニングを含み、これらに限定されずに、サムネールのサイズ、サムネールに使用されるソース・ウィンドウの部分、サムネールに使用される宛先ウィンドウの部分、サムネールの不透明度あるいは透明度、サムネールの視程、サムネールなど（例えば、回転する曲げて、粉々になるなど）の特殊効果
別の例において、サムネールは、それらが登録されたプロセスから更新されるかもしれないし修正されるかもしれない。１例において、サムネールが宛先ウィンドウのまわりで移動されるかもしれないように、サムネール・ハンドルは宛先ウィンドウに繰り返し呼ばれる。この場合、サムネールの位置は宛先ウィンドウ内に変えられるかもしれない。例えば、ＡＬＴ−ＴＡＢウィンドウ中で、サムネールは、宛先ウィンドウにサムネールを呼び戻すことによりオーダーを変える際に再整理されるかもしれない。

パラメーターはサムネール・プロパティを修正するかセットするのに使用されてもよい。サムネール・プロパティを修正するかセットするためのパラメーターの多くの例がある、のように、しかしフラグに制限されていなかった。パラメーターの使用を通じて、ＡＰＩ構造はＡＰＩを将来のアップグレードに対してより柔軟にして、より容易に修正されるかもしれない。パラメーターは、使用されるサムネールのプロパティを指示するかもしれないし、指定された定数によってそれら自身定義されるかもしれない。例えば、パラメーターは、ソース・ウィンドウ未満全体がサムネールに使用されることが望まれる場合に、宛先ウィンドウの中でサムネールとして使用されるソース・ウィンドウのエリアか部分を定義するソース・ウィンドウ・パラメーターを定義し相当するかもしれない。この例において、ソース・ウィンドウ・パラメーターによって示されるようなソース・ウィンドウの指定相続分だけが、宛先ウィンドウの中でサムネールに使用される。１例において、宛先ウィンドウの中でサムネールとして使用されるソース・ウィンドウの部分は、ディスプレイの座標として指定される。例えば、希望の部分がソース・ウィンドウ内の長方形である場合、ＡＰＩは、サムネールとして使用される最終長方形を得るソース・ウィンドウを備えた交差する長方形の座標を示すためにパラメーターを指定するかもしれない。例として、座標（０と０）はウィンドウ領域の左上コーナーとしてセットされるかもしれない。パラメーターを希望のソース・ウィンドウ・パラメーターを定義し一致することはサムネール（提供される座標の点から定義されているソース・ウィンドウの指定相続分）としてソース・ウィンドウの指定相続分だけが使用されることになっていることを示すためにセットされるかもしれない。座標およびソース・ウィンドウの希望の部分を指定する多くの方法があるが、１例は交差した実原始ウィンドウを備えた提供される長方形の交切によって定義されたソース・ウィンドウの部分を使用することを含んでいるかもしれない。

さらに、サムネールに使用される宛先ウィンドウの部分は、宛先ウィンドウ・パラメーターを定義し相当するパラメーターによって指定されるかもしれない。この場合、宛先ウィンドウ全体がサムネールに使用されることが望まれず、宛先ウィンドウの一部だけがサムネールに使用されることになっている場合、サムネールが翻訳されるかもしれない宛先ウィンドウのエリアは宛先ウィンドウ・パラメーターによって指定されるかもしれない。
その場合、１つのアプローチは、宛先ウィンドウ・パラメーター（つまりレンダーリングが指定地域の外部で生じる場合、イメージを切り取って）によって定義されるような希望の指定地域内にのみ与えることだろう。さらに、サムネールが引っ張って行かれるかもしれない宛先ウィンドウの部分の場所を決定する１つの方法は、使用される宛先ウィンドウおよび宛先ウィンドウ自体の部分の交切を決定する予定である。これは指定地域に外部のレンダーリングを防ぐ。さらに、パラメーターを宛先ウィンドウ・パラメーターを定義し一致することはソース・ウィンドウからのサムネールとして使用されるように指定地域内のエリアを選定するために使用されてもよい。この例において、宛先ウィンドウ・パラメーターが定義されない場合、指示されたウィンドウ全体はサムネール内容に使用されてもよい。

他のサムネール・プロパティのどんな数もＡＰＩの中で指定されるかもしれない。例えば、サムネールの不透明度あるいは透明度は指定されるかもしれない。本発明のこの例の１つの実施例では、パラメーターはサムネールの不透明度（あるいは透明度）を指定するために譲渡されるかもしれない、例えば、完全に透明なものとして、０が譲渡されているかもしれない一方、完全に不透明なものとして、２５５が譲渡されるかもしれない。したがって、パラメーターを不透明度パラメーターを定義し一致することがセットされる場合、サムネールの不透明度用の指定の割り当てられた数値は適用されるかもしれない。その結果、サムネールは、ユーザによって望まれるような不透明度の変わる程度を示すかもしれない。

補足例として、サムネールは、必要に応じて目に見えるか目に見えられないかもしれなくなるかもしれない。パラメーターを視程パラメーターを定義し一致することが提供されるかもしれない。視程パラメーターがＴＲＵＥである場合、視程パラメーターがＦＡＬＳＥである場合、サムネールが目に見えなくなる間に、サムネールが目に見えるようになるように、視程パラメーターはブール値かもしれない。サムネールのどんな変更も本発明の範囲内のように、本発明はサムネールのどんな特別の変更にも制限されていない。

サムネールを更新するか修正するためのＡＰＩの一例は、以下のようにＤｗｍＵｐｄａｔｅＴｈｕｍｂｎａｉｌＰｒｏｐｅｒｔｉｅｓである：

ただし、ｄｗＦｌａｇｓが使用される後のプロパティを指定するパラメーターに対応するパラメーターあるいはフラグを定義するところで。この例において、ｒｃＳｏｕｒｃｅパラメーターは、サムネールとして使用するためにソース・ウィンドウ（ｓｒｃＷｉｎｄｏｗ）のリージョンを指定するソース・ウィンドウ・パラメーターである、ｒｃＤｅｓｔｉｎａｔｉｏｎは、サムネールが与えられる宛先ウィンドウ（ｄｓｔＷｉｎｄｏｗ）を指定する宛先ウィンドウ・パラメーターである、不透明度は、サムネール（例えば、０〜２５５をセットする）の不透明度をコントロールする不透明度パラメーターでｆＶｉｓｉｂｌｅである、ブール値に基づいて、目に見えないか可視であるものとしてサムネールを指定する視程パラメーターである。
ＡＰＩの例３ − サムネールの登録解除
もはや必要でなかった時、ソースと宛先のウィンドウ間の関連性は削除される。例えば、ウィンドウがもはやアクティブでない場合、ウィンドウとサムネールの間の関連させることは結合を登録しないことにより遂行されるかもしれない。リソースの解放におけるこの業績。登録するプロセスが出る場合、Ｍｏｒｅｏｅｖｅｒとサムネールはさらにリリースされるかもしれない。サムネールを登録しないためのＡＰＩの一例は以下のようにＤｗｍＵｎｒｅｇｉｓｔｅｒＴｈｕｍｂｎａｉｌである：

図６は、本発明に、「実際の」ダイナミックなサムネールを含むサムネールを提供する過程の例を例証するフローチャートである。ＳＴＥＰ ６０１では、アプリケーションが最初のトップレベルのウィンドウを要求するかもしれないか、別のトップレベルのウィンドウあるいは宛先ウィンドウのセクションに位置するサムネールを表示するためにウィンドウを部品外注するかもしれないＡＰＩは提供される。従って、最初のトップレベルのウィンドウあるいはソース・ウィンドウは宛先ウィンドウ内の最高のオブジェクトとして与えられるかもしれない。このインプリメンテーションの制限しない１つの例は、ＡＬＴ−ＴＡＢウィンドウ（つまり宛先ウィンドウ）内にソース・ウィンドウに対応するサムネールが提供される、ＡＴＬ−ＴＡＢウィンドウである。

ＳＴＥＰ ６０２では、サムネール・ハンドルを提供するＤＷＭにレジスター電話をかける。同じソース・ウィンドウあるいは同じ宛先ウィンドウ上に多数の呼び出しがさらにあるかもしれない。ＡＬＴ−ＴＡＢ例で、同じソース・ウィンドウおよび同じ宛先ウィンドウ上の多数の呼び出し、サムネールが選択されている場合にアプリケーションのサムネールのより大きくかつ、または型にはめられた表現を同様に提供するＡＬＴ−ＴＡＢウィンドウ内のサムネールの転位に帰着する。別の例において、サムネールのＺ順序は後のレジストレーション呼び出しによって変更されるかもしれない。他の表示要素に関するサムネールのｚ−順序の変更が望まれる場合、新しいサムネールは別のサムネール・レジストレーション呼び出しで登録されるかもしれない。プロパティが古いサムネールに相当する新しいサムネールのためのセットだった後、古いサムネールは未登録かもしれない。
したがって、この例において、サムネールのｚ−順序はサムネールの多重登録によって変更されるかもしれない。

あるいは、同じ宛先ウィンドウ用に多重音源ウィンドウに呼び出しがあるかもしれない。この例において、多重音源ウィンドウに１つの宛先ウィンドウを要求する、宛先ウィンドウ内の多数の異なるサムネールの提供に帰着する。

まだ別の例において、ダイナミックなサムネールは他のダイナミックなサムネール内に表示されるかもしれない。例えば、より高いｚ−オーダーを備えた最初のダイナミックなサムネールは、より低いｚ−オーダーを備えたアプリケーションのより大きなダイナミックなサムネールに置かれるかもしれない。この例において、サムネールは他のサムネール内に埋め込まれるかもしれない。さらに、結果はサムネールあるいは任意の埋め込まれたサムネールのいずれかに適用されるかもしれない。あるいは、任意のｚ−オーダーのサムネールは任意のｚ−オーダーの別のサムネールへ滝のように落とされるかもしれない。例えば、少なくとも１つのサムネール（ｚ−オーダーに関係ない）は、任意のｚ−オーダーのアプリケーションのより大きなダイナミックなサムネールに置かれるかもしれない。同様に、より大きなダイナミックなサムネールは任意のｚ−オーダーの別のダイナミックなサムネールに置かれるかもしれない。したがって、サムネールはｚ−オーダーにかかわらず滝のように落とされるかもしれない。

ＳＴＥＰ ６０３では、ＤＷＭは、サムネールのためのプロセス／ＩＤペアを登録した。ＤＷＭは、アプリケーションがそれぞれ対応するサムネール・ハンドル（ＨＷＮＤ）とペアになるサムネール・レジストレーションの広域のリストをさらに維持するかもしれない。広域のリストはユーザの必要に依存して、様々な方法で維持されるかもしれない。例えば、広域のリストを維持する１つの便利な方法は、どんな希望の宛先ウィンドウも効率的にアクセスされるかもしれないように、宛先窓（ｄｓｔウィンドウ）からサムネールにインデックスを付けることである。さらに、任意の特別の宛先ウィンドウ中のサムネールは、オーバーラップの順序でのように、論理順序でさらに組織されるか、あるいはｚ−オーダーに基づくかもしれない。

別の例において、ＤＷＭは、最小化されているウィンドウに先立ってウィンドウ（つまり、ウィンドウの現在のコンテンツをちょうど今保存する）のコンテンツを「折ってもよい」。ＤＷＭは、特別のサイズのビットマップへ、例えばウィンドウの内容を折る。サイズはレジストレーションＡＰＩによって決定されるかもしれないし、サムネール・マッピングのための適切なサイズである。ウィンドウが最小化された後、ウィンドウの内容は既にアプリケーションウィンドウに対応するサムネールがまだ利用可能かもしれないそのように保存されている。あるいは、最小化されるウィンドウは一時的に「駐車されるかもしれない」本当に最小化されたのではなく画面外。このように、そのアプリケーションは、サムネールを更新するために情報とデータを送り続けるかもしれない。したがって、アプリケーションウィンドウが「最小化された」後、サムネール・レジストレーションが生じる場合、あたかもウィンドウが最小化されなかったかのように、サムネールはまだ登録され更新されるかもしれない。あるいは、サムネール・レジストレーションが実現可能でない場合、サムネールはアイコンあるいはキャプション法廷と取り替えられるかもしれない。

ＳＴＥＰ ６０４では、サムネール特性への最新版は決定されインプリメントされる。サムネール特性を修正するか更新する際に、ＤＷＭは広域のリストを従って修正するかもしれない。例えば、ＤＷＭアプリケーションは、ターゲット・ウィンドウを表わす適切なトップレベルのウィンドウ・ノードが追加の描画命令に基づいたソース・ウィンドウ（つまりｓｒｅウィンドウ）からのｒｅｄｒａｗｎであるそれ自身のシーングラフ（例えば図２Ａあるいは図３Ａ）にサムネールを加えるかもしれない。サムネールへのそれ以上指定された変更あるいは結果も計って、例えば組込まれるかもしれない、ポジショニング、不透明度、不可視性か特殊効果。

ＳＴＥＰ ６０５では、サムネールは受け取られた命令に基づいて修正される。例えば、ｆＶｉｓｉｂｌｅなパラメーターがＴＲＵＥか、ＵｐｄａｔｅＴｈｕｍｂｎａｉｌ ＡＰＩが、サムネールの不透明度を増加させるかもしれない（あるいは減少）場合、ＵｐｄａｔｅＴｈｕｍｂｎａｉｌ ＡＰＩは、サムネール・ノードの視程を修正するかもしれない。サムネールの登録解除が望まれる場合、結局、サムネールへの希望の変更は行なわれる、ということをＤＷＭプロセスが決める。サムネールの登録解除が望まれるかどうか判断するこの過程は、ＵｐｄａｔｅＴｈｕｍｂｎａｉｌプロセスとは別々に行なわれるかもしれない。この場合、登録解除がＵｎｒｅｇｉｓｔｅｒＴｈｕｍｂｎａｉｌ ＡＰＩ呼び出し（図示せず）により生じるかもしれない。ＳＴＥＰ ６０６では、登録解除ＡＰＩがＤＷＭプロセスによって受け取られる場合、それは決定される。登録解除ＡＰＩが受け取られる場合、プロセスおよび対応するサムネールＩＤの対現象は削除される（例えばＤＷＭプロセスで維持されたサムネール・レジストレーションの広域のリストから）。ＳＴＥＰ ６０７では、トップ・レベル・ウィンドウ命令ストリームは、未登録のサムネールの結果再度出される。その結果、サムネールは削除される。

１例において、カーソルは、対応するアプリケーションのサムネールのディスプレイに帰着するタスクバー・ボタンに関して抱かれる。カーソルがタスクバー・ボタンに関して抱かれる場合、プロセスはサムネールを主催する新しいトップのレベル・ウィンドウ・ハンドル（ＨＷＮＤ）を作成する。そのプロセスは、内容のソースとしてアプリケーションのウィンドウ・ハンドル（ＨＷＮＤ）をサムネール（つまりｓｒｃＷｉｎｄｏｗ）に使用するレジストレーションＡＰＩを呼ぶ。サムネールを主催する新しいトップのレベルＨＷＮＤは宛先ウィンドウ（ｄｓｔＷｉｎｄｏｗ）である。その後、ソース・ウィンドウからの内容（すなわちそれの希望の部分）は、サムネールを表示するために宛先ウィンドウに入れられる。サムネールはソース・ウィンドウ内容全体を含んでいるかもしれないし、あるいは上に述べられるような前もって定義しているか選択された部分だけを含んでいるかもしれない。最新版サムネールＡＰＩはサムネールを修正するかもしれないし移動させるかもしれない。例えば、サムネールの位置は対応するアイコンに比べて変えられるかもしれない。あるいは、特殊効果はサムネール（例えば透明度、不可視性、ひずみなど）に適用されるかもしれない。カーソルがタスクバー・ボタンから移される場合、サムネールが隠されるように、サムネールを主催するトップ・レベルＨＷＮＤは未登録かもしれない。あるいは、サムネールはサムネールがまだ登録され、続いて呼び出されるかもしれないように、目に見えないために更新されるかもしれない。代替方法では、生成上の個別窓は、タスクバーでそのために作成されたサムネールを割り当てられるかもしれない。この例において、タスクバー・コードは例えば、サムネールの職業紹介用のサムネール視程および宛先長方形を操作するために使用されてもよい。

本発明の実施例が多くの形式および具体化をとることができることは理解される。ここに示された実施例は、発明を制限するのではなく例証するように意図される、それ、評価、変化は発明のスコープの精神から外れずに作られるかもしれない。発明の実例となる実施例は示され記述されたが、広範囲の変更、変更および置換は、先の開示、および本発明のいくつかの特徴が他の特徴の対応する使用なしで雇われるかもしれないいくつかのインスタンスで意図される。従って、追加されたクレームが広く発明のスコープと一致する方法で解釈されることは適切である。

本発明の特徴により、ディスプレイにウィンドウを表示して従来技術における１又は複数の問題を解消するインターフェース、システム又は方法が提供される。アプリケーション・ウィンドウに対応する動的なサムネールも提供され、その場合には、アプリケーション・ウィンドウにおけるコンテンツの修正は、対応する動的なサムネールに反映される。アプリケーション・ウィンドウのコンテンツの修正は、対応する動的なサムネールにおいてリアルタイムに反映される。
本発明を実現するシステムの一例を図解しており、コンピュータの形式を有する汎用計算機が含まれている。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 本発明の１又は複数の特徴をサポートする汎用コンピュータ環境を示す。 ディスプレイのコンポーネントの例を図解するシーン・グラフ又はディスプレイ・ツリー・ダイアグラムである。 図２Ａに対応するサンプル・ディスプレイのコンポーネントを示している。 本発明のディスプレイのコンポーネントの例を図解するシーン・グラフ又はディスプレイ・ツリー・ダイアグラムである。 図３Ａに対応するディスプレイを示している。 アプリケーション・ウィンドウのサムネールを提供する本発明のアプリケーションの例を示している。 アプリケーション・ウィンドウのサムネールを提供する本発明のアプリケーションの例を示している。 ＡＬＴ−ＴＡＢのメニュにサムネールが表示されている本発明のサムネールの別のアプリケーションを図解している。 サムネールを提供するプロセスの例を図解する流れ図である。

Claims (20)

1. 表示装置にウィンドウを表示するコンピュータ実装された方法であって、
   修正が可能なコンテンツを含むソース・ウィンドウを表示するステップと、
   宛先ウィンドウを表示するステップであって、前記宛先ウィンドウの少なくとも一部は、前記ソース・ウィンドウの前記コンテンツの少なくとも一部に実質的に類似するコンテンツを含むサムネールを含む、ステップと、
   前記ソース・ウィンドウの前記コンテンツを修正し、前記ソース・ウィンドウの前記修正を前記サムネールに表示するステップと、
   を含むことを特徴とする方法。
2. 請求項１記載の方法において、前記サムネールを登録するステップを更に含み、前記サムネールを登録するステップは、前記ソース・ウィンドウのためのウィンドウ・ハンドルを受け取るステップを含むことを特徴とする方法。
3. 請求項２記載の方法において、前記サムネールを登録するステップは、前記ソース・ウィンドウと前記サムネールとの間の関連を確立し前記ソース・ウィンドウの前記コンテンツの少なくとも一部が前記サムネールの中に引き込まれるようにするステップを更に含むことを特徴とする方法。
4. 請求項３記載の方法において、前記サムネールを登録するステップは、サイズ・パラメータを受け取るステップと、前記サイズ・パラメータに対応するサイズにおいて前記ソース・ウィンドウを記憶するステップとを更に含むことを特徴とする方法。
5. 請求項４記載の方法において、前記サムネールを登録するステップは、前記ソース・ウィンドウと前記サムネールとの間の関連を表す一意的なハンドルを受け取るステップを更に含むことを特徴とする方法。
6. 請求項５記載の方法において、前記サムネールを登録解除するステップを更に含み、前記登録解除するステップは、前記ソース・ウィンドウと前記サムネールとの間の関連を表す一意的なハンドルを除去するステップを含むことを特徴とする方法。
7. 請求項６記載の方法において、前記サムネールを登録解除するステップは、前記ソース・ウィンドウと前記サムネールとの間の関連を表す一意的なハンドルを削除するステップを含むことを特徴とする方法。
8. 請求項６記載の方法において、ウィンドウ関連のリストを維持するステップを更に含み、前記ウィンドウ関連のリストは前記ソース・ウィンドウと前記サムネールとの間の関連の情報を含むことを特徴とする方法。
9. 請求項１記載の方法において、前記ソース・ウィンドウの少なくとも一部を定義する第１のパラメータを受け取るステップを更に含み、前記修正するステップは、前記ソース・ウィンドウの少なくとも一部を決定して前記第１のパラメータに基づいて前記サムネールの中に引き込むステップを含むことを特徴とする方法。
10. 請求項９記載の方法において、前記宛先ウィンドウの少なくとも一部を定義する第２のパラメータを受け取るステップを更に含み、前記修正するステップは前記宛先ウィンドウの少なくとも一部を決定し前記第２のパラメータに基づいて前記サムネールをレンダリングするステップを含むことを特徴とする方法。
11. 請求項１記載の方法において、前記修正するステップは、制御値を受け取るステップと、前記制御値の値に基づいて前記サムネールの不透明性（opacity）を設定するステップと、を更に含むことを特徴とする方法。
12. 請求項１１記載の方法において、前記制御値の値は０から２５５までの間にあることを特徴とする方法。
13. 請求項１１記載の方法において、前記修正するステップはブール値（Boolean value）を受け取るステップと、前記ブール値に基づいて前記サムネールを不可視的にするステップと、を更に含むことを特徴とする方法。
14. コンピュータ実行可能な命令を有するコンピュータ可読な媒体であって、前記命令は、
    修正可能なコンテンツを含むソース・ウィンドウをディスプレイに表示するステップと、
    宛先ウィンドウを表示するステップであって、前記宛先ウィンドウの少なくとも一部は、前記ソース・ウィンドウの前記コンテンツの少なくとも一部に実質的に類似するコンテンツを含むサムネールを含む、ステップと、
    前記ソース・ウィンドウの前記コンテンツを修正し、前記ソース・ウィンドウの前記修正を前記サムネールに表示するステップと、
    を実行することを特徴とするコンピュータ可読媒体。
15. 請求項１４記載のコンピュータ可読媒体において、
    前記サムネールを登録するステップと、
    前記ソース・ウィンドウと前記対応するサムネールとの間の関連の情報を含むウィンドウ関連のリストを維持するステップと、
    を実行するコンピュータ可読な命令を更に有することを特徴とするコンピュータ可読媒体。
16. 請求項１５記載のコンピュータ可読媒体において、前記登録するステップは、
    前記ソース・ウィンドウのためのウィンドウ・ハンドルを受け取るステップと、
    前記ソース・ウィンドウと前記対応するサムネールとの間の関連を確立し前記ソース・ウィンドウの前記コンテンツの少なくとも一部が前記サムネールの中に引き込まれるようにするステップと、
    サイズ・パラメータを受け取り、前記サイズ・パラメータに対応するサイズにおいて前記ソース・ウィンドウを記憶するステップと、
    前記ソース・ウィンドウと前記宛先ウィンドウとの間の関連を表す一意的なハンドルを受け取るステップと、
    を含むことを特徴とする方法。
17. 請求項１５記載のコンピュータ可読媒体において、前記修正するステップは、
    前記ソース・ウィンドウの少なくとも一部を定義する第１のパラメータに基づき、前記宛先ウィンドウに引き込まれる前記ソース・ウィンドウの少なくとも一部を決定するステップと、
    前記サムネールを定義する第２のパラメータに基づき、コンテンツをレンダリングする前記宛先ウィンドウの少なくとも一部を決定するステップと、
    制御値を受け取り、前記制御値の値に基づいて前記サムネールの不透明性（opacity）を設定するステップと、
    ブール値（Boolean value）を受け取り、前記ブール値に基づいて前記サムネールを不可視的にするステップと、
    を更に含むことを特徴とするコンピュータ可読媒体。
18. 請求項１５記載のコンピュータ可読媒体において、前記ソース・ウィンドウと前記サムネールとの間の関連を表す一意的なハンドルを削除するステップを含む前記サムネールを登録解除するステップを実行するコンピュータ実行可能な命令を更に含むことを特徴とするコンピュータ可読媒体。
19. 表示装置にウィンドウを表示するシステムであって、
    修正が可能なコンテンツを含むソース・ウィンドウと前記ソース・ウィンドウに対応する宛先ウィンドウとを表示するディスプレイと、
    宛先ウィンドウの中にあり前記ソース・ウィンドウの少なくとも一部と対応するサムネールを登録するマネジャであって、前記登録するステップは、
    前記ソース・ウィンドウのためのウィンドウ・ハンドルを受け取るステップと、
    前記ソース・ウィンドウと前記サムネールとの間の関連を確立し前記ソース・ウィンドウの前記コンテンツの少なくとも一部が前記サムネールの中に引き込まれるようにするステップと、
    前記ソース・ウィンドウに対応するサイズ・パラメータを受け取り、前記サイズ・パラメータに対応するサイズにおいて前記ソース・ウィンドウを記憶するステップと、
    前記ソース・ウィンドウと前記サムネールとの間の関連を表す一意的なハンドルを受け取るステップと、
    を含むマネジャと、
    前記ソース・ウィンドウのコンテンツを修正して、前記サムネールの対応する部分において表示するプロセッサであって、前記修正するステップは、
    前記ソース・ウィンドウの少なくとも一部を決定する第１のパラメータに基づいて前記サムネールの中に引き込む前記ソース・ウィンドウの少なくとも一部分を決定するステップと、
    前記宛先ウィンドウの少なくとも一部を定義する第２のパラメータに基づいてレンダリングされる前記サムネールを決定するステップと、
    制御値を受け取り、前記制御値の値に基づいて前記サムネールの不透明性を設定するステップと、
    ブール値（Boolean value）を受け取り、前記ブール値に基づいて前記サムネールを不可視的にするステップと、
    を含む、プロセッサと、
    を含むことを特徴とするシステム。
20. 請求項１９記載のシステムにおいて、前記マネジャは、更に、前記サムネールを登録解除し、前記登録解除は前記ソース・ウィンドウと前記サムネールとの間の関連を除去することを含むことを特徴とするシステム。

Images