(57)【特許請求の範囲】
【請求項１】
文書が内容と前記内容のハンドラとを有する複数のパーツに基づいており、前記内容が、夫々が内容の特徴を示唆する複数の異なる種類の内、少なくとも１つの種類に属しているとして認識されるようなコンピュータ−ヒューマンインタフェースを備えたコンピュータシステムにおいて、パーツにハンドラを結合する処理を実行する結合方法であって、
前記パーツに含まれる少なくとも１つの種類を取り扱うに適したコンピュータシステムにおいて利用可能なハンドラがあるかどうかを自動的に判別し、前記ハンドラが利用可能であると判別された時には、前記ハンドラを前記パーツに結合する判別・結合工程と、
前記ハンドラが利用可能でない場合、前記パーツが変換可能な別の種類を自動的に決定する決定工程と、
前記決定された別の種類の内、いづれかの種類に適した利用可能なハンドラを前記システムで自動的に識別する第１識別工程と、
前記パーツの内容を、前記識別されたハンドラに適した前記決定された別の種類に自動的に変換する第１変換工程と、
前記変換されたパーツを前記識別されたハンドラに自動的に結合する第１結合工程とを有することを特徴とする結合方法。
【請求項２】
パーツを前記コンピュータシステムのユーザに呈示可能にする最後の手段としてのハンドラを提供する第１提供工程と、
前記決定された別の種類のいずれにも適したハンドラが利用可能でない場合、前記最後の手段としてのハンドラを前記パーツに結合する第２結合工程とをさらに有することを特徴とする請求項１に記載の結合方法。
【請求項３】
前記判別・結合工程は、
前記パーツが好適なハンドラを識別する情報を含んでいるかどうかを判別する第１判別工程と、
前記好適なハンドラが識別されたとき、前記コンピュータシステムで前記識別された好適なハンドラが利用可能であるかどうかを判別する第２判別工程と、
前記識別された好適なハンドラが利用可能であるとき、前記パーツへの結合のため、前記好適なハンドラを選択する第１選択工程とを含むことを特徴とする請求項１に記載の結合。
【請求項４】
前記判別・結合工程は、さらに
前記パーツを含む文書に限定されたハンドラのセットを提供する第２提供工程と、
前記限定されたセットにおけるハンドラのいずれかが、前記パーツに含まれた種類に適しているかどうかを判別する第３判別工程と、
前記種類に適した１つのハンドラを前記限定されたセットから選択する第２選択工程とを含むことを特徴とする請求項３に記載の結合方法。
【請求項５】
前記パーツの内容は、夫々対応する忠実度をもった複数の種類に関連づけられ、前記種類の１つが、それ以外の他の種類に相対的な忠実度に基づいて選択されることを特徴とする請求項４に記載の結合方法。
【請求項６】
前記複数の種類各々の忠実度は、最後に前記パーツに結合されたハンドラによって決定されることを特徴とする請求項５に記載の結合方法。
【請求項７】
前記コンピュータシステムが前記選択された種類に好適なハンドラの識別情報を含んでいるかどうかを判別する第４判別工程と、
前記コンピュータシステムにおいて前記好適なハンドラが識別され、前記好適なハンドラが利用可能であれば、前記好適なハンドラを選択する第３選択工程とをさらに有することを特徴とする請求項５に記載の結合方法。
【請求項８】
前記複数の種類各々は少なくとも１つのジェネリックなカテゴリと関連づけられ、
前記選択された種類に関連したカテゴリを識別する第２識別工程と、
前記カテゴリに好適なハンドラの識別情報を前記コンピュータシステムが含んでいるかどうかを判別する第５判別工程と、
前記カテゴリに関して好適なハンドラが識別されたなら、前記好適なハンドラが前記選択された種類について適しているかどうかを判別する第６判別工程と、
前記好適なハンドラが前記選択された種類について適しているなら、前記識別されたカテゴリについて前記好適なハンドラを選択する第４選択工程とをさらに有することを特徴とする請求項７に記載の結合方法。
【請求項９】
好適なハンドラがシステムで識別されないなら、前記選択された種類について適している、前記コンピュータシステムで利用可能な何らかのハンドラから１つのハンドラを選択する第５選択工程をさらに有することを特徴とする請求項８に記載の結合方法。
【請求項１０】
前記決定工程は、
前記パーツの内容に関連する１つの種類を選択する第６選択工程と、
前記選択された種類が変換される目的となる種類のセットを決定する第１決定工程と、
前記セットから、前記パーツの内容に関連する前記１つの種類を除く他の全ての種類を除去する第１除去工程と、
前記選択された種類に関連する１つ以上のジェネリックなカテゴリを決定する第２決定工程と、
前記セットから、前記カテゴリの少なくとも１つにも関連しない全ての前記目的となる種類を除去する第２除去工程とを含むことを特徴とする請求項１に記載の結合方法。
【請求項１１】
前記第１識別工程は、
前記セットにおける前記目的となる種類に適した、前記コンピュータシステムで利用可能なハンドラを確認する確認工程と、
前記確認されたハンドラのいずれかが少なくとも前記カテゴリの１つに適しているかどうかを判別する第７判別工程と、
適していると判別されたハンドラを選択する第７選択工程とを含むことを特徴とする請求項１０に記載の結合方法。
【請求項１２】
前記ハンドラのいずれもが、前記カテゴリのいづれにも適していないことが判別されたなら、前記確認されたハンドラのいずれかからハンドラを選択する第８選択工程をさらに含むことことを特徴とする請求項１１に記載の結合方法。
【請求項１３】
前記第１変換工程は、
前記識別されたハンドラに関連する、異なる種類についての忠実度の好適な順番を決定する第３決定工程と、
前記パーツの内容を、前記識別されたハンドラについて最も忠実度の高い他の種類の内の１つの種類に変換する第１変換工程とを含むことを特徴とする請求項１に記載の結合方法。
【請求項１４】
文書が内容と前記内容のハンドラとを有する複数のパーツに基づいており、前記内容が、夫々が内容の特徴を示唆する複数の異なる種類の内、少なくとも１つの種類に属しており、前記複数の種類各々は対応する忠実度を有しているとして認識されるようなコンピュータ−ヒューマンインタフェースを備えたコンピュータシステムにおいて、パーツにハンドラを結合する処理を実行する結合方法であって、
前記パーツに関し前記複数の種類の内の１つの種類を、前記パーツについての他の種類に相対的な忠実度に基づいて、自動的に選択する第１選択工程と、
前記コンピュータシステムが前記選択された種類に関して好適なハンドラの識別情報を含むかどうかを自動的に判別する第１判別工程と、
前記好適なハンドラが識別され、前記好適なハンドラが前記コンピュータシステムで利用可能である場合には、前記好適なハンドラを自動的に選択する第２選択工程と、
前記選択されたハンドラを前記パーツに自動的に結合する第１結合工程とを有することを特徴とする結合方法。
【請求項１５】
前記パーツを含む前記文書に限定されたハンドラのセットを提供する第１提供工程と、
前記限定されたセットにおいて、前記ハンドラのいずれかが前記選択された種類に適しているかどうかを判別する第２判別工程と、
前記限定されたセットから、前記種類に適したハンドラの１つを選択する第３選択工程とをさらに有することを特徴とする請求項１４に記載の結合方法。
【請求項１６】
前記複数の種類各々の忠実度は、前記パーツに最後に結合されたハンドラによって決定されることを特徴とする請求項１４に記載の結合方法。
【請求項１７】
前記複数の種類各々は少なくとも１つのジェネリックなカテゴリに関連しており、
前記選択された種類に関連するカテゴリを識別する第１識別工程と、
前記コンピュータシステムが前記カテゴリに関して好適なハンドラの識別情報を含むかどうかを判別する第３判別工程と、
前記カテゴリに関する好適なハンドラが識別されたなら、前記好適なハンドラが前記選択された種類に適しているかどうかを判別する第４判別工程と、
前記好適なハンドラが前記選択された種類に適しているなら、前記識別されたカテゴリに関して、前記好適なハンドラを選択する第４選択工程とをさらに有することを特徴とする請求項１４に記載の結合方法。
【請求項１８】
もし、好適なハンドラがシステム内で識別されなければ、前記選択された種類について適している１つのハンドラを、前記コンピュータシステムで利用可能な何らかのハンドラから選択する第５選択工程をさらに有することを特徴とする請求項１７に記載の結合方法。
【請求項１９】
文書が内容と前記内容のハンドラとを有する複数のパーツに基づいており、前記内容が、夫々が内容の特徴を示唆する複数の異なる種類の内、少なくとも１つの種類に属しているとして認識されるようなコンピュータ−ヒューマンインタフェースを備えたコンピュータシステムにおいて、パーツをある種類から別の種類に変換し、前記変換されたパーツにハンドラを結合する処理を実行する変換結合方法であって、
前記パーツの内容が関連する１つの種類を自動的に選択する第１選択工程と、
前記選択された種類が変換される目的となる種類のセットを自動的に決定する第１決定工程と、
前記セットから、前記のパーツの内容が関連する他の全ての種類を自動的に除去する第１除去工程と、
前記選択された種類が関連する１つ以上のジェネリックなカテゴリを自動的に決定する第２決定工程と、
前記セットから、前記カテゴリの少なくとも１つとも関連のない全ての目的となる種類を自動的に除去する第２除去工程と、
前記セットにおける前記目的となる種類に適する、前記コンピュータシステムで利用可能なハンドラを自動的に確認する確認工程と、
前記確認されたハンドラのいずれかが前記カテゴリの少なくとも１つに適しているかどうかを自動的に判別する判別工程と、
適していると判別されたハンドラを自動的に選択する第２選択工程と、
前記パーツの内容を、前記選択されたハンドラが適している前記目的となる種類の内の１つの種類に自動的に変換する変換工程と、
前記変換されたパーツを前記選択されたハンドラに自動的に結合する結合工程とを有することを特徴とする変換結合方法。
【請求項２０】
前記ハンドラのいずれもが、前記カテゴリのいずれにも適していないと判別された場合には、前記確認されたハンドラのいずれかからハンドラを選択する第３選択工程をさらに有することを特徴とする請求項１９に記載の変換結合方法。
【請求項２１】
内容と前記内容のハンドラとを有する複数のパーツに基づいた文書を扱うコンピュータ−ヒューマンインタフェースを備えたコンピュータにおいて、ハンドラをパーツに結合する結合システムであって、
前記コンピュータ内にあって利用可能なハンドラと各ハンドラに関連するパーツの内容の特徴を示唆する種類を識別する第１のセットの情報と、パーツの内容の特徴を示唆する種類を識別する第２のセットの情報とを格納する格納手段と、
利用可能なハンドラが前記パーツの種類に関連しているかどうかを判別する第１判別手段と、
もし、ハンドラが前記パーツの種類に関連しているなら、前記パーツに前記ハンドラを結合する第１結合手段と、
前記パーツの内容を変換可能な種類を決定する決定手段と、
利用可能なハンドラが前記パーツの内容を変換可能な種類のいずれかに関連しているかどうかを判別する第２判別手段と、
前記パーツの内容を、利用可能なハンドラに関連する種類に変換する変換手段とを有することを特徴とする結合システム。
【請求項２２】
前記コンピュータのユーザにいかなるパーツも呈示可能にする最後の手段としてのハンドラを格納する格納手段と、
前記利用可能なハンドラが前記パーツの種類とも、前記パーツの内容を変換可能な種類とも関連がない場合には、前記パーツに前記最後の手段としてのハンドラを結合する第２結合手段とをさらに有することを特徴とする請求項２１に記載の結合システム。
【請求項２３】
前記第２のセットの情報は、前記パーツの種類各々についての忠実度の順番を認識し、
前記決定手段は、利用可能なハンドラが前記種類と関連しているどうかを判別するために、前記忠実度の順番で前記パーツの種類を順次選択することを特徴とする請求項２１に記載の結合システム。
【請求項２４】
前記種類各々は少なくとも１つのジェネリックなカテゴリと関連があり、
前記決定手段は、前記コンピュータが前記選択された種類と関連するカテゴリについての好適なハンドラを識別する情報を含んでいるかどうかを判別し、さらに、もし前記情報を含んでいるなら、前記好適なエディタが前記選択された種類と関連しているかどうかを判別することを特徴とする請求項２３に記載の結合システム。
【請求項２５】
前記変換手段は、前記利用可能なハンドラと関連する、異なる種類についての忠実度の好適な順番を決定し、変換に適した最も忠実度の高い種類に前記パーツの内容を変換することを特徴とする請求項２１に記載の結合システム。
【請求項２６】
内容と前記内容のハンドラとを有する複数のパーツに基づいた文書を扱うコンピュータ−ヒューマンインタフェースを備えたコンピュータにおいて、
パーツにハンドラを結合する結合システムであって、
各々がパーツの内容の特徴を示唆しさらに対応する忠実度をもつ複数の異なる種類の内の少なくとも１つの種類に属するとして、パーツの内容を認識するデータを格納する格納鍛と、
前記パーツについての他の種類に関する相対的な忠実度に基づいて、前記パーツについて前記種類の１つを選択する第１選択手段と、
前記コンピュータシステムが前記選択された種類について適したハンドラを含んでいるかどうかを判別する第１判別手段と、
利用可能であると判別された適切なハンドラに前記パーツを結合する結合手段とを有することを特徴とする結合システム。
【請求項２７】
前記種類各々についての忠実度は、最後に前記パーツに結合された前記ハンドラによって決定されることを特徴とする請求項２６に記載の結合システム。
【請求項２８】
前記種類各々を少なくとも１つのジェネリックなカテゴリに関連づける情報を格納する第２格納手段と、
前記選択された種類に関連するカテゴリを識別する識別手段と、
前記コンピュータが前記カテゴリに適したハンドラを含んでいるかどうかを判別し、もし前記カテゴリに適したハンドラが利用可能であれば、前記ハンドラが前記選択された種類に適しているかどうかを判別する第２判別手段と、
前記ハンドラが前記選択された種類に適しているなら、前記識別されたカテゴリが前記パーツに結合されるよう前記ハンドラを選択する第２選択手段とをさらに有することを特徴とする請求項２６に記載の結合システム。
【発明の詳細な説明】
発明の属する分野
本発明はパーツが文書についての基本的な構築ブロックを形成するようにしたコンピュータ−ヒューマンインタフェースのアークテクチュアに関するものであり、特に、パーツがオープンされたときエディタをそのパーツに結合するシステムに関するものである。
発明の背景
パーツが文書についての基本的な構築ブロックを形成するようにしたコンピュータ−ヒューマンインタフェースのアークテクチュアは、１９９３年５月１０日出願の米国特許出願第08/058260号に説明されている。パーツは、２つの基本的な構成要素、即ち、内容と、その内容の操作子或はハンドラで構成される自己完結的なエンティティである。一般的に、そのハンドラはそのパーツのいくらか或いは全ての内容に追加をしたり、そこから削除したり、さもなくば修正したりするために必要な機能を提供しているエディタである。例えば、もし、そのパーツがテキスト文書を有していれば、その内容はテキストであり、そのパーツの構成要素となるエディタは、ユーザがそのテキストを編集できるようにするワードプロセッシングソフトウェアである。或は、そのパーツの構成要素を形成するハンドラはビューワでも良い、これによって、ユーザはパーツの内容を見ることができる。しかし、そのビューワに編集可能な機能は備えられていない。
この種のアーキテクチュアでは、パーツの内容はそれ自身によっては存在しない。むしろ、その内容は常にパーツがアクティブであればいつでもハンドラと関係づけられる。言い換えると、パーツがオープンしたとき、パーツの構成要素を形成するハンドラもまたオープンされ、バックグランンドで実行され、これによってその機能がユーザに利用可能となる。
どのパーツであっても、それに関連したある特性をもっている。これらの特性の１つは、そのパーツに関する好適なエディタの認識である。パーツが最初に創成されたとき、そのパーツを創成するために用いられたプログラムは、普通は、好適なエディタとして認識される。例えば、テキストパーツについて考えると、好適なエディタは、その文書を創成するために用いられた特定のワードプロセッシングプログラムを認識するかもしれない。この特性は、パーツとともに保存される。そのパーツが次にオープンされるときはいつも、そのワードプロセッシングプログラムが起動され、その結果、その機能はユーザがそのパーツの内容にアクセスするとき、利用可能となる。
そのパーツに関する好適なエディタをもっていない別のコンピュータシステムヘあるコンピュータシステムからパーツが移される場合がある。或は、好適なエディタがそのシステムから除去されることがあるかもしれない。例えば、そのエディタが単に試行的に用いられていたり、或は、その試用期間が過ぎてしまった場合があるかもしれない。これらの場合、システムで利用可能な異なるハンドラがそのパーツに割当てられねばならない。従って、最適で利用可能なハンドラをパーツに割当て、これによってそのパーツがアクセスされるときにはいつもその機能を利用可能にするシステムを提供することが望まれている。パーツにハンドラを割当てるこのプロセスは、バインデディング（結合）として知られている。
本発明の簡単な説明
本発明は、コンピュータで最も効率的に使用できるプログラムを利用可能にするように、パーツにハンドラを結合するシステムを提供する。その結合動作は、パーツのオープン時、或は、ハンドラの機能にアクセスする必要があると判断される適切な時に、発生する。その結合動作において、本発明のシステムは、まず、コンピュータ上でパーツに関して好適なエディタが利用可能であるかどうかを決定する。もし、利用可能であれば、そのエディタがパーツと結合され、これがまだ実行されていないなら起動される。一方、その好適なエディタが利用可能でないなら、本発明のシステムはカテゴリや種類のようなパーツの内容の種々の特徴に基づいて、そのパーツに関する最適なハンドラを関係づける。もし、コンピュータ上で適切なエディタや他のハンドラが利用可能であれば、それがパーツと結合されて起動される。もし、コンピュータで利用可能なプログラム中にそのパーツに適切なハンドラがないなら、そのパーツをエディタが利用可能な別の種類のものに変換するかどうかを決定する。もし、変換するように決定されたなら、そのパーツは変換され、ハンドラが結合される。さもなければ、最後の手段としてのハンドラがエディタとしてそのパーツに結合される。この種のハンドラは、通常、パーツの特定の種類の内容を操作するエディタに関係した機能を全く使用することはできないが、パーツをユーザに呈示できるようにするジェネリックなツールである。
以下、本発明の特徴について、付属した図面によって説明されている好適な実施例を参照して説明する。
【図面の簡単な説明】
図１Ａ及び図１Ｂは、パーツを採用した図形インタフェースによって生成される画面を示す図である。
図２は、本発明の結合システムの基本的なプロセスを示すフローチャートである。
図３は、Direct Binding（直接接合）ルーチンのステップを示すフローチャートである。
図４は、パーツの種類によって直接結合する手順のステップを示すフローチャートである。
図５は、カテゴリエディタを関係ずけるプロセスを示すフローチャートである。
図６は、パーツの種類に基づいてハンドラを選択するサブルーチンのフローチャートである。
図７は、Translated Binding（変換結合）のルーチンのフローチャートである。
図８は、選択されたカテゴリに従ったTranslated Binding（変換結合）サブルーチンのフローチャートである。
図９は、ハンドラリスト内でカテゴリエディタを関係づけるサブルーチンのフローチャートである。
図１０は、選択されないカテゴリにおける変換結合のサブルーチンのフローチャートである。
詳細な説明
本発明の理解を容易にするために、文書の基本的な構成要素としてパーツを採用したコンピュータ−ヒューマンインタフェースについてまず説明する。ここで説明する特定の例では、アップルコンピュータ株式会社によって供給されているマッキントッシュ（登録商標）ブランドのコンピュータに適したインタフェースを説明する。しかしながら、本発明の原理はこの特定な例に限定されるものではないことを理解すべきである。
図１Ａ及び図１Ｂは、パーツを採用したコンピュータ−ヒューマンインタフェースを介してユーザに提示される画面を示す図である。これらの画面はワークスペース３６を定義するデスクトップ３４を示している。また、デスクトップにはメニューバー３８が含まれている。ワークスペース３６内には２つのウィンドウ４０、４２がある。左側のウィンドウ４０はフォルダウィンドウであり、種々のパーツを示すアイコンを含んでいる。図１Ａに示されているように、３つのアイコン４４はテキストパーツに関係しており、４番目のアイコン４５は図形パーツであり、もう１つのアイコン４６は帳票パーツである。６番目のアイコン４８はプレゼンテーション・スライドの創成のために用いられるパーツを表現するステーショナリ・アイコンである。図１Ａにおいて、右側のウィンドウ４２はテキスト文書を含んでいる。具体的には、その文書はテキストパーツ５０を含んでいる。このテキストパーツは、ウィンドウ４２内にテキストをタイプするか或は１つのアイコンによって表現される以前に創成されたテキストパーツをウィンドウ内でオープンすることによって創成される。
図１Ｂは図形アイコン４５が左側のウィンドウ４０のフォルダから右側のウィンドウ４２のテキスト文書にドラッグする動作を行なったときの結果を示している。図１Ａ及び図１Ｂに示されるようなデスクトップメタフォーを採用するユーザインタフェースでは知られているように、ドラッギングとはマウスのような適当なカーソル制御デバイスを起動することでデスクトップ上やウィンドウ内でオブジェクトを移動させたり、コピーしたりする動作のことである。いったん、図形アイコンが文書内に置かれると、その内容がフレーム５２に表示される。今や、文書はテキストも図形要素も含んでいるのであるから、それは複合文書として言及される。
複合文書において、例えば、エディタのような異なるプログラム実行モジュールは協働して１つに統合された情報の体裁をなすようにする。そのような実行モジュール各々は、文書の全ての情報の内容の１つのセグメント、即ち、パーツを制御する。ここで、文書のパーツは互いに関係するように制約が設けられる。その制約によって、ユーザは含まれる或は埋め込まれた従属パーツが主たるコンテナパーツとともに移動したり、その主たるコンテナパーツによって影響を受けたりすることを予想できる論理的な関係を表現することができる。テキスト５０とフレーム５２内の図形要素とは夫々別々のパーツに属しており、これらが一緒になって複合文書を構成する。図形パーツはこの具体例の場合、テキストパーツに含まれている。
パーツは内容とその内容の操作子或はハンドラとから構成される自己完結型のエンティティである。これら２つの構成要素は、そのパーツがアクセスされたときは、それが、デスクトップのどこに位置していようと、常に利用可能である。従って、図１Ａに示すように、図形アイコン４５がウィンドウ４０のフォルダに位置しているとき、それは、図形要素とその要素についてのエディタとを含むパーツを表現している。そのパートがウィンドウ４２の文書に移動したとき、その内容もパーツとともに移動し、それらの内容のエディタの機能もユーザにはすぐに利用可能である。
この特徴で重要なことは、パーツの内容は、それがどこに位置していようとも常に編集可能、さもなければ、操作可能であるという事実である。従って、図１Ｂの複合文書において、テキストの内容５０は、その文書内で、例えば、そのテキストを初めて創成したときに用いられたと同じワードプロセッサを用いて編集可能である。図形エディタが、フレーム５２によって表現されるパーツの構成要素として存在しているので、パーツの図形要素も適宜に直接編集可能となる。従って、ユーザが別の図形アプリケーションを、例えば、デスクトップ３４の別のウィンドウでオープンし、その図形情報を所望の形に編集し、その後、編集された図形をウィンドウ４２の文書に移動させる必要はない。むしろ、ユーザは、直接、ウィンドウ４２の文書の内容の中で、中間的な過程を組み込むことなく、フレーム５２の内容を編集することができる。ユーザは、アプリケーションプログラムではなく、むしろ、文書の内容に注意を集中することができ、周辺の文書によって備えられた文脈を利用することができる。
それ故に、パーツとは、基幹システム技術における自律性のある自己完結的なオブジェクトである。それは、どんな種類のソフトウェアエンジンでも環境でも使用することができ、ユーザはパーツについて特別なエディタの操作を学ぶ必要はない。そのパーツに適したエディタが基幹システムで表現されている限り、ユーザは、そのパーツの能力を十分に利用することができる。さらに、もし、テキスト部分が特別なテキストエディタ（ワードプロセッサ）で生成されたとしても、ユーザはただそのテキストエディタをそのパーツとともに用いるように限定されている訳ではない。もし、そのユーザが異なるワードプロセッサのコマンドにより親しんでいるなら、例えば、そのワードプロセッサを、その文書或はコンピュータシステムでの全てのテキストパーツに関する好適なエディタとして指定できる。
パーツに関するエディタ或はハンドラは、従来のコンピュータシステムでのアプリケーションプログラムに類似している。それは、パーツの内容を表示したり、適当であればこれらの内容を修正するためのユーザインタフェースを呈示するための必要な機能を提供するソフトウェア要素である。これには、メニューや、コントローラや、ツールパレットや、他のユーザインタラクティブな機能が含まれる。他のパーツを含むことができるパーツに関して言えば、そのエディタは、その内容を表示するとき、これら含まれた従属のパーツを考慮にいれる。例えば、テキストエディタはそのパーツの内容を包み込み、その内容が埋め込まれた図形パーツ内で現れないようにする。
パーツは数多くのそれに関連した特性をもっている。これらの１つは、その好適なエディタである。例えば、パーツが最初に創成されたとき、そのパーツを創成するために用いられたプログラムはその好適なエディタとして識別される。その後、その好適なエディタは変更可能である。通常、そのような変更はユーザの好みに合わせて、ユーザによってなされる。これとは別に、或は、これに加えて、好適なエディタの変更は、例えばシステムのデフォルトに合わせて、システムによって自動的になされることもある。
パーツの別の特性は、そのタイプ或は種類と呼ばれるものである。種々の種類のパーツが異なるカテゴリに分類される。一般的に言って、カテゴリは、テキスト、図形、帳票などのパーツの内容についての情報のいくつかのジェネリックなクラスの１つを識別する。この種類という特性は、その内容の１つ以上の特徴を示唆する。例えば、その種類は、内容の属性（イタリック体）、データ形式（ＰＩＣＴ或はＴＩＦＦファイル）、或は、テキストを創成するために用いた特定のワードプロセッサが備えるようなテキストに関連したフォーマッティングや他の制御コードを本質的に識別する他の顕著な特徴を示す。
パーツに関するより詳細な情報、パーツに基づいた図形インタフェースについては上述の米国特許出願第08/058260号に見いだすことができ、そこで開示された情報は参照として本願に組み込まれている。
従来のアプリケーションプログラムによって提供される機能を利用するために、プログラムが起動され実行されねばばらない。言い換えると、それはコンピュータシステムの主記憶メモリに格納しておかねばならない。これと同じような方法で、文書パーツに基づくインタフェースにおいて、パーツがユーザによってアクセスされたとき、そのパーツについてのエディタもシステムメモリさもなければコンピュータのＣＰＵにアクセス可能なメモリで実行しなければならない。そのようにするために、エディタはシステムにインストールされなければならない。例えば、それは、フォルダ或はハードディスクのような永久記憶メモリのサブディレクトリに格納され、関連するパーツがアクセスされたとき呼び出し可能となっている。システム資源を無駄にしないため、全てのインストールされたエディタは全時間システムメモリにロードしておく必要はない。むしろ、これらは必要に応じて起動される。例えば、パーツについてのエディタは、パーツが文書にドラッグされたとき、このときがエディット能力が最も必要とされるときであるので、起動される。
従って、パーツの内容へのアクセスが必要であるときはいつでも、エディタとそのパーツとを関係づけることが望ましい。特定のエディタをパーツに関連づけるプロセスは、バインディング（結合）として知られている。通常、結合はパーツが最初にオープンしたとき実行され、そのパーツがオープンしている限り、エディタとそのパーツとの結合は続く。或は、エディタをパーツとを別のときに結合されることが望ましいかもしれない。例えば、そのパーツを含むウィンドウがアクティブとなっているとき、たとえそのパーツ自身がそのウィンドウ内でまだオープンされていなくとも、結合を実行しても良い。
もちろん、全てのエディタが、パーツがアクセスされるどのコンピュータシステムでも利用可能であるという訳ではないだろう。例えば、あるコンピュータシステムで特定のワードプロセッシングプログラムを用いて、テキスト文書が創成される。従って、そのパーツに関する好適なエディタとは、それを創成したときも用いたワードプロセッサである。さて、そのパーツが最初にそれを創成したときに用いたものとは異なるワードプロセッシングプログラムを採用した他のコンピュータに移動することは有り得る。従って、この別のコンピュータシステムでそのパーツがアクセスされたとき、そのパーツに関する好適なエディタは、利用可能ではない。そのような場合、そのシステムで利用可能なものからそのパーツと結合するのに適した別のエディタを認識することが必要である。
本発明は、そのコンピュータシステムで利用可能なものからパーツについて最適なハンドラを識別し、そのハンドラとそのパーツとを結合する手順に関するものである。本発明に従って、エディタとパーツとを結合する全般的な手順についての概要は、図２のフローチャートに図示されている。この全般的な手順の個々のステップの詳細はこれに続く図のフローチャートに図示されている。
ハンドラとパーツとを関係づける必要があるときにはいつでも、この結合手順が実行される。通常、これは、パーツがクローズされた状態や隠された状態から最初にオープンしたとき、実行される。例えば、マウスボタンが押下されたときやスクリプト内のステップにおいて生成されるイベントフラグに応答して、この結合は発生するかもしれない。ハンドラとパーツとを結合する他の適切な時には、パーツがシステムに最初にロードされた時や、パーツを含むウィンドウのオープン時や、パーツがアクティブな文書にドラッグされた時がある。
図２において、いったん結合を開始する適切なイベントが検出されたなら、本発明のシステムはまず、Direct Binding（直接結合）（ステップ２０１）として知られるルーチンを実行する。Direct Bindingにおいて、パーツに関して好適なエディタ、或は、もし好適なエディタが利用可能でないなら、そのパーツの内容の種類の１つをサポートする別のハンドラを確認する試みがなされる。適したハンドラが確認されたとき、それがパーツに結合される。適切な基準を満たすパーツのハンドラが利用可能でないなら、Direct Bindingはうまくいかなかったことになる。ステップ２０２において、Direct Bindingルーチンがうまく実行できたかどうかを判別する。もし、うまく実行されたなら、システムは結合プロセス（ステップ２０３）と呼ばれるプログラムに進む。
Direct Bindingルーチンがうまく実行できなかったなら（ステップ２０２における応答がネガティブ（ＮＯ））、手順はTranslated Binding（変換結合）を実行する（ステップ２０４）。このプロセスでは、パーツの内容をハンドラが利用可能な種類に変換する試みがなされる。そのような手順によってうまくいく可能性があれば、そのパーツは変換され、利用可能なハンドラが変換されたパーツに結合される。もし、ステップ２０５で判断されるように、その手順の結果がよいものであれば、システムはステップ２０３に進む。しかしながら、ステップ２０５においてその応答がネガティブ（ＮＯ）であれば、即ち、Translated Binding（変換結合）ルーチンの実行がうまくいかなったなら、システムはステップ２０６においてパーツを最後の手段となるハンドラと結合する。最後の手段となるハンドラは、そのパーツをユーザに呈示できるようにするプログラム実行モジュールである。そのハンドラの機能に依存して、パーツの内容が表示できるようになる。さもなければ、そのパーツは空のボックスとして表示され、ユーザには文書全体のどこにそれが位置するのかを可視化して示すようにする。例えば、最後の手段としてのハンドラが図１Ｂの例において、図形パーツに関して用いられていた場合、フレーム５２の輪郭は表示されるかもしれないが、内部の内容については表示されない。最後の手段としてのハンドラはまた、パーツについての、そのパーツが明らかに変換された特定の種類であるといったある限定された情報を提供する。
図３には、ステップ２０１のDirect Bindingルーチンの詳細が示されている。ステップ３０１では、システムは好適なハンドラがそのパーツに指定されているかどうかを判別する。もし、好適なハンドラが指定されていれば、ステップ３０２ではその好適なハンドラがコンピュータシステム上で利用可能であるかどうかを判別する。もし、それが利用可能であれば、ステップ３０３ではそのハンドラがそのパーツに結合されたハンドラであると認識される。例えば、ハンドラを識別する唯一の文字列が、結合プロセスを呼び出したプログラムに返される。この文字列は、そのパーツがアクセスされたときにはいつでも参照されるローカル変数として記憶される。適当なフラグがステップ３０４でセットされ、Direct Bindingルーチンの実行がうまくいったことを示す。そして、システムは図２のフローチャートのステップ２０２に戻る。
もし、ステップ３０１において好適なハンドラが指定されていないか、或は、ステップ３０２において確認できないなら、システムはどんな種類のデータがパーツに含まれているかを決定する。もし、そのパーツが多数の種類のデータから構成されているなら、その１種類が選択される（ステップ３０５、３０６）。好適には、その種類はデータの忠実度の順番に従って選択される。この点に関して、どのハンドラにもそのエディタについての好適な種類とカテゴリのリストが伴っている。異なる種類やカテゴリのデータは同じ情報を表現すると言えるが、定性的に言えば、そのエディタの機能性を考慮するとあるものの表現能力は別のものよりもその質が良いこともあれば、悪いこともある。定性的に比較的良質の種類のデータが、高い忠実度をもっていると認識される。忠実度についてのデータ種類に関する所定の順番というものはない。むしろ、忠実度は常に特定の状況によって決定される。エディタは多くの異なる種類のデータをサポートすることができるかもしれず、それ故に適切なデータ構造は、忠実度の順序に従って、特定のエディタに関連するデータ種のリストを保存している。例えば、ワードプロセッシングプログラムは通常は異なる種類のテキストを扱うことができる。これらの異なる種類の忠実度の順序は、（１）リッチテキスト、（２）スタイルテキスト、（３）プレインテキスト等である。
それゆえ、どのパーツも忠実度の順序に従ってリストされた異なる種類のデータを有している。この順番は、そのパーツに最後に結合したエディタによって決定される。ステップ３０６では、この種のデータが、忠実度の順序に従って、選択される。パーツに関して１種類のデータが選択された後、システムはステップ３０７でDirect Bind By Kindとラベルされたルーチンを実行する。このルーチンにおいて、システムは、ハンドラが選択された種類をサポートするために存在するかどうかを判別する。もし、それが存在すれば、そのハンドラがパーツに結合されたハンドラであるとして認識される（ステップ３０８、３０９）。そして、それがうまくいったことを示すフラグ（成功フラグ）がステップ３０４でセットされる。もし、ステップ３０７において、そのルーチンがその種のパーツについてのハンドラを確認できなければ、システムはステップ３０５に戻り、そのパーツがまだ検証されていない別の種類の内容を含んでいるかどうかを判別する。もし、別の種類の内容を含んでいるなら、ステップ３０７のDirect Bind By Kindルーチンがその種の内容に関して繰り返し実行される。このプロセスは、パーツの内容の１種類についてハンドラが認識されるまで続く。もし、パーツの種類の何れに対してもハンドラが見つからなければ、プロセスはステップ３１０に進み、成功フラグをリセットし、失敗の状態にする。そして、システムはステップ２０２に戻る。
ステップ３０７のDirect Bind By Kindサブルーチンの詳細は、図４のフローチャートに図示されている。この図において、文書各々（１以上のパーツを含む）は、ハンドラの限定されたリストと関係づけられている。このリストは、ユーザがその文書に関して好適である１セットのハンドラを選択するときに、形成される。ステップ４０１では、システムはChoose By Kindとラベルされたサブルーチンを実行する。このサブルーチンにおいて、システムはその文書に限定されたリスト上のハンドラのいずれか１つがステップ３０６で選択された種類のパーツをサポートしているかどうかを判別する。もし、サポートされていれば、何らかの適切な手順を用いて、その選択された種類をサポートするハンドラの１つが選択される。例えば、その適切なハンドラは、アルファベット順にハンドラをソートし、リスト上の最初のハンドラを選択することによって、選んでも良い。
もし、Choose By Kindサブルーチンの実行が、ハンドラの選択でうまくいったなら、そのハンドラがステップ４０３でパーツに結合される。そして、成功フラグがステップ４０４でセットされる。その後、プロセスはステップ３０８に戻る。
さて、ステップ４０１のサブルーチンの実行が、ハンドラの選択でうまくいかなかったなら、ステップ４０６において選択された種類のパーツについての好適なハンドラが基幹コンピュータシステムで識別されるかどうかを判別する。例えば、最初にユーザがコンピュータシステムを構成するとき、パーツ各種に対して好適なエディタをユーザは認識しているかもしれない。また、好適なハンドラは自動的にそのコンピュータシステムで選択されることもある。或は、他のいくつかの適当な手順によって、好適なハンドラを認識するようにしても良い。好適なハンドラが指定されたなら、システムはステップ４０７でそのハンドラがシステムに現在存在しているかどうかを判別する。もし、存在していれば、そのハンドラはパーツにステップ４０８で結合され、ステップ４０４で成功フラグをセットした後、そのプロセスは続行する。
もし、指定された好適なハンドラがなかったり、或は、それが現在システム上に存在していないなら、サブルーチンがステップ４０９で実行され、そのパーツのカテゴリに従って、ハンドラが利用可能であるかどうかを判別する。このサブルーチンの詳細は、図５のフローチャートに図示されている。その図において、このサブルーチンでは、選択された種類のパーツに関連する種々のカテゴリに基づいて、ハンドラが選択される。具体的にいうと、どの種類のパーツも少なくとも１つのカテゴリと関係している。ある種のパーツについていえば、１つ以上のカテゴリと関連があるかもしれない。ステップ５０１、５０２では、選択された種類のパーツに関連するカテゴリの１つが選択され、ステップ５０３では、そのコンピュータシステムがそのカテゴリのパーツについて好適なハンドラをもっているかどうかを判別する。もし、そのようなハンドラをもっていれば、ステップ５０４では、その好適なハンドラが選択された種類のパーツに適しているかどうか、即ち、その機能がその種のパーツをサポートしているかどうかを判別する。もし、そのハンドラが適していれば、ステップ５０５においてそのハンドラが現在システムに存在しているかどうかを判別する。もし、存在していれば、そのハンドラがステップ５０６で選択され、成功フラグがセットされる。もし、このプロセスの結果として、何のハンドラも選択されなければ、システムはステップ５０１に戻り、選択された種類のパーツが別のカテゴリと関連しているかどうかを判別する。もし、他の何かのカテゴリと関連していれば、そのプロセスは、ハンドラが選択されるか或は全てのカテゴリを調べてしまうまで、繰り返される。もし、どのカテゴリについてのハンドラを選択することができなければ、成功フラグはステップ５０７でリセットされ、そのプロセスは図４のフローチャートのステップ４１０に戻る。
再び、図４において、ステップ４０９のサブルーチンの実行がうまくいけば、選択されたハンドラはステップ４１１においてパーツに結合され、成功フラグがステップ４０４でセットされる。さもなければ、そのプロセスはステップ４１２のサブルーチンに進む。このサブルーチンでは、選択された種類をサポートするハンドラの確認がなされる。そのサブルーチンの詳細は、図６に図示されている。この図において、ステップ６０１、６０２では、システムはコンピュータシステムで現在利用可能な全てのハンドラから１つを選択する。ステップ６０３では、このハンドラが選択された種類のパーツに適しているかどうかを判別する。もし、それが適したものであれば、このハンドラは検証済ハンドラの一時的なリストに加えられる（ステップ６０４）。ステップ６０１〜６０４は、選択された種類のパーツに相対するコンピュータシステム上で現在利用可能である全てのハンドラが検証されるまで繰り返され、検証済ハンドラの一時的なリストを創成していく。その後、ステップ６０５では、検証済ハンドラのリストがソートされ、エディタがビューワの前に置かれ、これら２つのカテゴリ各々の内でハンドラはアルファベット順或は何か他の適切な順番に調整される。その後、ステップ６０６では、それらハンドラの１つ、例えば、リストの最上位にあるハンドラ、がリストから選択される。それから、このプロセスは図４のフローチャートのステップ４１３に戻る。もし、そのサブルーチンの実行がハンドラの選択においてうまくゆけば、そのハンドラはステップ４１４でパーツに結合され、成功フラグがステップ４０４でセットされる。一方、図４のDirect Bind By Kindルーチン実行の結果として、何のハンドラも選択されなかったなら、成功フラグはステップ４１５でリセットされ、システムは図３のフローチャートのステップ３０８に戻る。
パーツに関する全ての種類を検証後、Direct Bindingルーチンがハンドラを選択することができないなら、ステップ２０３のTranslated Bindingルーチンが実行される。このルーチンのプロセスは、図７のフローチャートに図示されている。Translated Bindingルーチンの最初のステップとして（ステップ７０１）、システムは、指定されたカテゴリに関して変換が実行されるサブルーチンを実行する。そのサブルーチンの各ステップは、図８に図示されている。この図において、ステップ８０１では、パーツの種類が“all kinds（全種）”とラベルされているリストに格納される。ステップ８０２と８０３では、このリストにある１種類が選択され、リスト上の残りのエントリは“other kinds（他種）”とラベルされている第２のリストに格納される。システムは、選択された種類が変換可能な種類のパーツを認識する。このことは、例えば、コンピュータシステムで利用可能な変換機能によって決定される。これら認識されたパーツ種は、目的種のリストに格納される。他種のリストに格納されているパーツ種は、目的種のリストから除去される。他種のリストにあるパーツ種を目的種のリストから除去する理由は、これら他種のパーツはDirect Bindingルーチンの実行中に適したハンドラの存在に関して既に検証されているという事実のためである。Translated Bindingルーチンが今実行されているという事実によって、適切なハンドラは他種のリストにあるパーツ種に関しては存在しないことが前に判別されている。従って、Translated Bindingルーチンにおいて、これらの種類のパーツをこれ以上検証する必要はない。
ステップ８０４では、選択種に関連した種々のカテゴリが識別される。目的種のリストにあるエントリが検証され、このリスト上のどんな種類も、選択種についてのカテゴリの１つと同じ関連するカテゴリをもたないなら、これらもまた除去される。それ故に、目的種のリストは、選択種が変換可能であり、選択種と共通の少なくとも１つのカテゴリを有し、他種のリストに現れない全ての種類を含んでいる。
ステップ８０５と８０６では、目的種のリストにおける種類のパーツの１つが選択され、ステップ８０７では、以前に図４のフローチャートに関して説明したように、Direct Bind By Kindサブルーチンが実行される。もし、そのサブルーチンの実行が利用可能なハンドラを確認するのにうまくいけば、そのハンドラはステップ８０８において目的ハンドラのリストに付加される。また、ハンドラが見つけられなければ、選択された目的種はステップ８０９において、目的種のリストから除去される。それから、プロセスはステップ８０５に戻り、他の目的種が検証のために残存しているかどうかを判別する。このプロセスの結果により、注目しているパーツが変換可能な目的種に適したシステム上の全てのハンドラのリストが創成される。
全目的種の検証後、システムはステップ８１０で目的ハンドラのリストが空となったかどうかを判別する。もし、空になっていないなら、即ち、少なくとも１つのハンドラがDirect Bind By Kindサブルーチンの実行結果として、確認されたなら、システムはステップ８１１に進む。このステップでは、サブルーチンが実行され、カテゴリに基づいて、目的ハンドラの１つを選択する。このサブルーチンの各ステップは、図９のフローチャートに図示されている。この図において、ステップ９０１、９０２では、選択種のパーツ（ステップ８０３で認識されるように）についてのカテゴリの１つが選択される。ステップ９０３では、システムの好適なエディタがそのカテゴリについて認識されたかどうかを判別する。もし、認識されたならば、ステップ９０４では、システムはそのハンドラがステップ８０８で設けられた目的ハンドラのリストに見出されるかどうかを判別する。もし、見出されれば、ステップ９０５において、選択されたハンドラが現在コンピュータシステムにあるかどうかを判別するチェックを行う。もし、そのハンドラが見出されたならば、このハンドラが選択され、成功フラグがステップ９０６でセットされる。その時、システムは図８のサブルーチンに戻り、その図のステップ８１２では、成功フラグの状態が認識され、選択されたハンドラはステップ８１３で選択されたカテゴリについての好適なハンドラであると定められる。
もし、最初に選択されたカテゴリに関して、何のハンドラも見つからなければ、システムはステップ９０１に戻り、別のカテゴリを選択し、システムの好適なハンドラがそのカテゴリで見出されるかどうかを判別する。このプロセスは、ハンドラが見出されるまで、各カテゴリについてステップ９０２〜９０５でループする。全てのカテゴリについての検証がなされた後も、ハンドラが見出されなければ、ステップ９０７において成功フラグには失敗（false）状態がセットされる。
このサブルーチン実行の結果として、何のハンドラも選択されないなら、システムはステップ８１４に進み、そこで、何らかの好適な手順に従って、目的ハンドラのリストにあるハンドラの１つが選択される。例えば、前述のように、ハンドラのリストがアルファベット順にソートされ、さらなる処理のために、そのリスト上の最上位にあるハンドラが選択される。
ステップ８１４でいったんハンドラが選択されれば、目的種のリストが検証され、どの種類が選択エディタによって最も高い忠実度をもつと考えられるかを決定する。最大の忠実度をもつ種と関連したカテゴリが識別され、各々のカテゴリについてシステムの好適なエディタがあるかどうかが判別される。どのカテゴリもシステムの好適なエディタを未だ有していないなら、選択されたエディタは、ステップ８１６で、そのカテゴリについてのシステムの好適なエディタであると設定がなされる。その後、成功フラグがセットされ、ステップ７０２での肯定的な応答（ＹＥＳ）によりシステムはステップ７０３へと進み、そこで選択されたハンドラがパーツに結合される。その後、ステップ７０４では、そのパーツは、目的種のリストにあるもので、選択されたハンドラが最も高い忠実度をもつと考える種類に変換される。
再び図８において、ステップ８１０で目的種のリストが空であることが分かったなら、或は、ハンドラがステップ８１４で選択されていないなら、システムはステップ８０２に戻り、そのパーツが未だ検証されていない他の関連種を有しているかどうかを判別する。もし、これを有しているなら、処理は他の種類に関しても繰り返される。また、全ての種について検証後にも、ハンドラが選択できないなら、成功フラグはステップ８１８でリセットされ、そして、そのフラグがステップ７０２でチェックされる。ハンドラが選択されていないので、システムはステップ７０５のサブルーチンに進む。そのサブルーチンは図１０で詳細に図示されている。
ステップ７０１のサブルーチンにおいて、注目パーツに関連するカテゴリの１つをサポートする利用可能なハンドラを確認することがなされる。もし、その手順の実行がうまくいかないなら、ステップ７０５のサブルーチンは他のカテゴリのパーツに基づいて利用可能なハンドラを確認することを試みる。図１０において、ステップ１００１〜１００３では、注目するパーツの１種が選択され、その選択種についての目的種のリストが形成され、他の種類についてはそのリストから除去される。この処理はステップ８０１〜８０３と同様である。ステップ１００４では、目的種のリストではそのリストから、選択種と関連したカテゴリのいづれかと同じ関連したカテゴリをもった種類を除去する。言い換えると、ステップ１００４で実行されるプロセスは、ステップ８０４で実行される手順の補完となっている。ステップ８０５〜８０９に対応したステップ１００５〜１００９では、目的種とハンドラのリストを創成するために実行される。その後、ステップ１０１０では、これらのリストが空であるかどうかを判別する。もし、空でないなら、即ち、少なくとも１つの目的とするハンドラが確認されれば、そのハンドラの１つが無作為に或は何かの望ましい技術を用いてステップ１０１１で選択され、成功フラグがステップ１０１２でセットされる。その後、プロセスは図７のフローチャートに戻り、ステップ７０６で選択されたハンドラがパーツに結合される。その後、ステップ７０４では選択ハンドラが最も高い忠実度をもっていると考える目的種が選択され、パーツはその種に変換される。成功フラグが再びセットされ、そのプロセスは終了する。
これに対して、目的とするハンドラが選択されなかったなら、成功フラグがステップ１０１３でリセットされる。その後、プロセスはステップ２０４に戻り、ハンドラ選択において、Direct Bindingルーチンの実行もTranslated Bindingルーチンの実行もうまくいかなかったとの決定がなされる。従って、最後の手段としてのハンドラがステップ２０５においてパーツに結合される。
従って、要約すると、本発明ではパーツに関する最適なエディタ、或は、他のハンドラを識別し、そのハンドラをパーツに結合する手順が提供される。動作の好適なモードでは、まず、パーツを変換する必要なく、そのパーツを構成する種類の１つに適したハンドラを結合することが試みられる。もし、そのパーツの好適なエディタがその基幹コンピュータシステムに存在するなら、そのエディタが選択される。さもなければ、一連の優先度に基づいて、１つのエディタが選択される。これらの優先度にはその種のパーツを取り扱うその文書に限定されたエディタのセット、その種のパーツについてのシステムの好適なエディタ群、その種のパーツを取り扱うことができるカテゴリのパーツについてのシステムの好適なエディタ群、その種のパーツを取り扱う何か他のエディタからのエディタを含んでいる。エディタの選択において、これらのどの方法もうまくいかないなら、変換がなされる。この方法では、注目するパーツについて変換可能であり、そのパーツのカテゴリと互換性のある種類の１つについてのエディタが認識される。そのようなエディタが見つからないなら、他のカテゴリのパーツと互換性のあるエディタが選択される。これら種々の基準値に基づいて、適したエディタが利用可能ではないことが分かれば、最後の手段としてのハンドラがパーツに結合され、そのパーツをシステムのユーザに呈示できるようにする。
本発明の理解を容易にするために、その原理を具体的な実施例を参照して説明した。しかしながら、本発明を実際に適用することはこの特定の実施例に限定されるものではないことは言うまでもない。例えば、適切なハンドラを確認するための種々のサブルーチンや、これらサブルーチンに含まれるステップは、ここで説明した特定の順序で実行される必要はない。異なる順序のステップで種々の基準で検証することにより、好ましい結果が得られる。従って、本発明の範囲は、以下のクレームによって記述され、前述の説明によって定義されるものではない。そして、クレームの意味に矛盾のない全ての等価物が、その範囲に含められるものである。
【図１Ａ】
0003950938.tif 000002
【図１Ｂ】
0003950938.tif 000003
【図２】
0003950938.tif 000004
【図３】
0003950938.tif 000005
【図４】
0003950938.tif 000006
【図５】
0003950938.tif 000007
【図６】
0003950938.tif 000008
【図７】
0003950938.tif 000009
【図８】
0003950938.tif 000010
【図９】
0003950938.tif 000011
【図１０】
0003950938.tif 000012