(57)【要約】【目的】本発明は、クライアントと複数のサービス・モジュールとの間の処理を仲介する手段をもうけて、クライアントとシステムとの間のデータ表記などの整合をとるようにすることを目的とする。【構成】複数のサービス・モジュールと、テンプレートと、処理手順情報出力手段と、サービス・モジュールを選択する適用手段と、データ形式の変換などを行う制御手段とを有する。【選択図】　　　　　　　　　図１
2004054942.tif 000002
【特許請求の範囲】
【請求項１】
複数のサービス・モジュールと、
クライアントから送られてくる情報の形式と前記複数のサービス・モジュールが処理できるデータ形式との対応関係を示したテンプレートと、
クライアントが入力したサービス要求情報に応じてそのサービスの処理手順を出力する処理手順情報出力手段と、
クライアントが前記処理手順情報出力手段によって出力された処理手順の各項目に対して選択した処理に応じて適用する前記サービス・モジュールを選択する適用手段と、
前記適用手段による選択処理の後、クライアントからのデータが到来すると、前記テンプレートを参照し、該データを、前記処理手順情報出力手段により出力された処理手順に従って次に処理すべき前記サービス・モジュールが処理できるデータ形式に変換を行い、対応する前記サービス・モジュールに変換されたデータによって処理を行わせる制御手段と、
を備えたことを特徴とする情報処理装置。
【請求項２】
表示手段を有し、
前記テンプレートは、前記各サービス・モジュールの出力データの形式と前記表示手段に表示させるデータ形式との対応関係も記憶しており、
前記制御手段は、更に、前記テンプレートを参照して、前記サービス・モジュールからの出力形式をデータ変換した後、前記表示手段に表示させる
ことを特徴とする請求項１記載の情報処理装置。
【請求項３】
複数のサービス・モジュールと、
クライアントから送られてくる情報の形式と前記複数のサービス・モジュールが処理できるデータ形式との対応関係を示したテンプレートと、
を有する情報処理装置が、
クライアントが入力したサービス要求情報に応じてそのサービスの処理手順を出力する処理手順情報出力ステップと、
前記処理手順情報出力ステップによる処理手順によって出力された処理手順の各項目に対して選択した処理に応じて適用する前記サービス・モジュールを選択する適用ステップと、
前記適用ステップによる選択処理の後、クライアントからのデータが到来すると、前記テンプレートを参照し、該データを、前記処理手順情報出力ステップにより出力された処理手順に従って次に処理すべき前記サービス・モジュールが処理できるデータ形式に変換を行い、対応する前記サービス・モジュールに変換されたデータによって処理を行わせる処理ステップと、
を実行することを特徴とする情報処理方法。
【請求項４】
前記情報処理装置は、更に
表示手段を有するとともに、前記各サービス・モジュールの出力データの形式と前記表示手段に表示させるデータ形式との対応関係も記憶しており、
前記テンプレートを参照して、前記サービス・モジュールからの出力形式をデータ変換した後、前記表示手段に表示させる表示ステップを実行する
ことを特徴とする請求項３記載の情報処理方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は，クライアントがサーバと対話しながら、クライアントの意図にしたがったサービスを実行してゆくようにした情報処理装置および情報処理方法に関する。
【０００２】
【従来の技術】
従来から情報処理装置の画面に向かって対話を行いつつ処理を実行することが行われる。そして、特開昭６３−１３８４３０号公報、特開昭６３−１３８４３１号公報に示すように、システムがオブジェクトや管理プログラムを意識することなく処理を実行するようにすることが知られている。
【０００３】
ある課題を解決し処理結果を得るためには、好奇心から意図が発生し、その意図を満足させるようなサービス・システムが必要となる。このために図３０のようなクライアント・サーバ間の対話モデルを考えると、意図をグラフ構造によって表現したオブジェクト・ネットワークによって定義することが考えられる。そして、個々の意図が逐次あるいは並行的にサービスを行う対話図式によって、オブジェクト・ネットワークの内容が表現される。
【０００４】
図３０の左側はクライアントであって当該クライアントが行う意図についての内容記述作業を矩形の枠で示し、図示の右側はサーバであって当該サーバが行う処理を矩形の枠で示し、中央部に点線で囲ってディスプレイなどの表示機能を含む表示的プロセスが介在していることを表している。なお、クライアントが行う意図はクライアントからの指示および／またはデータを受取り、システム側において解読される。
【０００５】
クライアントは興味をもったサービス名によって意図として、表示的プロセスにサービスの要求を行う▲１▼。サーバは当該要求に対応して意図実現計画を実行して当該処理の対象となるオブジェクト・ネットワークを呈示する▲２▼。
【０００６】
当該呈示されたオブジェクト・ネットワークを画面でみながら、クライアントは単位意図の選択を行う▲３▼。この選択された単位意図はサーバ側に示されてそのときの処理を実行する上での制約データや条件や処理を実行する関数計画を実行して画面上で呈示する▲４▼。
【０００７】
クライアントは呈示されたデータや条件や関数を選択する▲５▼。サーバ側では選択されたデータや条件や関数にもとづいてサービス機能実行計画を実行してその実行結果を画面上で呈示する▲６▼。クライアントはその実行結果を評価して次の意図選択を行う▲７▼。
【０００８】
上記の如くクライアントおよびサーバが協調して意図を実現する。即ちクライアントは意図を選択する過程でサーバに単位意図を要求する。これに答えてサーバはサービス実行に必要な制約条項を計画し、クライアントに向けて、それの必要性を応答する。このようなインタラクションのための場が対話に有効である。
【０００９】
対話が円滑であるためには、対話プロセス意味論上の結束性が、意図駆動による意図内容の連接的整合性によって表現され、それはオブジェクト・ネットワークの妥当性を保証する。
【００１０】
【発明が解決しようとする課題】
対話プロセスを円滑に進行させるためには、サービス・プロセスに役割を特化させるのが効率的である。人間にとって表現シンボルとしては、画像・図形の方がテキスト文よりも一眼で直観的に理解されるのに対し、計算機は論理的記述が処理し易い。役割は、理解解読機能、実行処理機能などの諸機能、あるいは述語や表現スタイルなどの記述形式によって規定される。
【００１１】
本発明は、各種ウインドウをもつコモン・プラットフォームと呼ばれるものの如き処理手段を用意し、コモン・プラットフォーム内のコミュニケーション・マネージャと呼ばれるものの如き制御手段がクライアントとサーバとの間でのデータ表記形式などの整合をとるようにして、対話を効果的に進めうるようにすることを目的としている。
【００１２】
【課題を解決するための手段】
図１は本発明の一実施例構成図を示す。図中の符号１はクライアント、２はコモン・プラットフォーム、３はサーバを表している。コモン・プラットフォームにおいて、４はディスプレイなどの表示手段上に表示されるウインドウであり、大別して、ネットワーク・オペレーション・ウインドウ５とデータ・ウインドウ９とに分けられる。そして、６はオペレーション・ウインドウであって各種オペレーションを指示可能にする画像や文字を表示するもの、７はコマンド・ウインドウであって各種コマンドを指示可能にする画像や文字を表示するもの、８はメッセージ・ウインドウであって各種メッセージを表示可能にするものを表している。
【００１３】
またデータ・ウインドウ９は、処理結果を表すデータ・ウインドウ（Ｉ）９−１と、処理に必要な制約データなどを表すデータ・ウインドウ（ＩＩ）９−２とからなる。
【００１４】
１０はコミュニケーション・マネージャであって、ウインドウ４を介して交換されるクライアント１とサーバ３との交信を仲介する。
【００１５】
１１はウエル・システム（各種のオブジェクト・ネットワークに対処できる拡張性をもっているという意味で、以下、エキステンシブ・ウエル・システムと呼ぶことがある）である。１２はウエル・カーネルであって上記コミュニケーション・マネージャ１０や以下の各種マネージャや、グラフ構造エディタを管理し、また作業領域をもっている。１３はグラフ構造エディタであってオブジェクト・ネットワークをも一種のデータと考えて、グラフ構造をテンプレートとして表現して処理を行う。
【００１６】
１４はウインドウ・マネージャであって、ウインドウ４の選択などを処理する機能をもつものである。１５はディスプレイ・マネージャであって、ウインドウを表示するディスプレイを制御する機能をもつものである。１６は関数実行マネージャであって、オブジェクト・ネットワークに対してクライアントの意図に沿った処理を行う上での関数を実行する上での処理を行う機能をもつものである。
【００１７】
１７−１，１７−２は夫々の目的に対応した処理を行うサービス・モジュールである。
【００１８】
サーバ３はクライアントが処理対象にしようとしている意図内容を記述しているオブジェクト・ネットワークを呼び出して、グラフ構造エディタ１３はウエル・カーネル１２がもつ作業領域上に当該オブジェクト・ネットワークを記憶する。
【００１９】
この結果にもとづいて、ウインドウ・マネージャ１４などの働きによってかつコミュニケーション・マネージャ１０の仲介によってオブジェクト・ネットワークがオペレーション・ウインドウ６に表示される。
【００２０】
この状態の下で、クライアントは、表示されたオブジェクト・ネットワークにもとづいて、当該オブジェクト・ネットワーク上の全部または一部を特定して自己の意図を指示する。この指示に対応して、コミュニケーション・マネージャ１０が当該意図を解釈し、サーバに対して処理対象となる位置に該当するオブジェクト（例えば名詞オブジェクト）についてのテンプレートを呼び出させる。そしてサービス・モジュールが当該テンプレートに対応した領域準備などを行い、ウインドウ４はそのときの制約データの存在をデータ・ウインドウ（ＩＩ）９−２に表示する。
【００２１】
クライアントは、制約データをデータ・ウインドウ（ＩＩ）９−２上で選択し、サーバが実行計画を実行し、サービス・モジュール１７が実行し、ウインドウ４が実行結果をデータ・ウインドウ（Ｉ）９−１に表示する。その結果をクライアントが評価し、次の指示を行う。
【００２２】
図２と図３とは一緒になって１つのフローチャートを示すものであって、図１に示す構成が用いられる態様を表すフローチャートを示す。
（Ｓ１）：後述する図５に示す如き、例えばカラー画像生成・色付け処理分野１８Ｃに対応する処理を行う場合、サーバが該当するオブジェクト・ネットワーク１９Ｃを呼び出す。
（Ｓ２）：これに応じて、グラフ構造エディタは、ウエル・カーネル１２上の作業領域上に当該オブジェクト・ネットワークを格納する。
（Ｓ３）：ウエル・カーネル１２によって、図１示すウインドウ・マネージャ１４やディスプレイ・マネージャ１５を起動しまたカーネル１２が当該各マネージャからの応答を受けるなどの処理をへて、コミュニケーション・マネージャ１０の仲介によって、オブジェクト・ネットワークがオペレーション・ウインドウ６に表示される。
（Ｓ４）：クライアント１は、オペレーション・ウインドウ６上のオブジェクト・ネットワークをみた上で、当該オブジェクト・ネットワーク上の全部または一部を特定して自己の意図を指示する。
（Ｓ５）：この状況をコミュニケーション・マネージャ１０が識別し、カーネル１２を介在させて、サーバに対して処理対象となる位置に該当するオブジェクトについてのテンプレートを呼出させる（サーバがテンプレートを呼出す）。
（Ｓ６）：サービス・モジュールは当該テンプレートに対応した領域準備を行う。
（Ｓ７）：コモン・プラットフォームにおいては、当該テンプレートに記述されていることのある制約データを抽出して、当該制約データをデータ・ウインドウ（ＩＩ）９−２に表示する。
（Ｓ８）：クライアント１は当該制約データをみて、その中から所望する制約データを選択する。
（Ｓ９）：この状況をコミュニケーション・マネージャ１０が識別し、カーネル１２を介在させ、サーバに通知し、サーバが実行計画を実行する。
（Ｓ１０）：これにともなって、サービス・モジュールが所望される処理（例えば、線引きや色付けなどの処理）を実行する。
（Ｓ１１）：処理結果をデータ・ウインドウ（Ｉ）９−１に表示する。
（Ｓ１２）：クライアントはその処理結果を評価し、次の指示を行う。
【００２３】
本願請求項１にいう（ｉ）「サービス・モジュール」は図１に示すサービス・モジュール１７−ｉに対応し、（ｉｉ）　「処理手順情報出力手段」は、上記図３におけるステップ（Ｓ３）に記述しているように、図１に示すウエル・カーネル１２に対応し、（ｉｉｉ）　「適用手段」は、上記図３におけるステップ（Ｓ５）に記述しているような、図１に示すコミュニケーション・マネージャ１０による処理に対応する処理手段に対応し、（ｉｖ）「制御手段」は、上記図３におけるステップ（Ｓ６）やステップ（Ｓ７）に記述している如く、図１に示すコモン・プラットフォーム２による制御手段に対応している。
【００２４】
また本願請求項２にいう（ｖ）「表示手段」は、図１に示すウィンドウ４に対応し、（ｖｉ）「制御手段がデータ変換後に表示手段に表示させる」処理は、後述するコモン・プラットフォームの機能（段落〔００２６〕、〔００４７〕、〔００７１〕〜〔００７９〕など参照）にもとづいている。
【００２５】
【実施例】
図３０に示した如きクライアントとサーバとの間の対話をより効果的に実現させるためには、クライアントと個々の処理を行うサーバとの間に、エイジェントの役割を行うエイジェント・ロール・サーバを介在させることが有効な場合がある。
【００２６】
コモン・プラットフォーム機能は、オブジェクト・ネットワークを表示するウインドウ５と、実行に伴って必要とするデータおよび実行結果のデータを可視画像として表示するデータ・ウインドウ９−ｉとを持ち、これらを支援するためのコミュニケーション・マネージャ１０などを有しており、これらの機能によりクライアント１としてのユーザに最も適した表示形式を使用可能にし、それをコモン・プラットフォーム２において、データ処理装置内部での処理用に変換するようにして、ユーザにとって使い易くしている。
【００２７】
一方、サーバ３にとっては、個々のデータなどはインデックス形式のタグが付いたテキスト形式で処理する必要がある。このようなクライアント１とサーバ３とはそれぞれ特有の役割をもっているので、コミュニケーション・マネージャ１０はそれらの役割に応じたデータ形式に変換する役割をもっている。このためのデータの型を規定するためにテンプレートで制御を行うようにする。
【００２８】
このテンプレートにもとづいて、変換が行われるが、この場合クライアント１とサーバ３との役割の差に対応して表記の形式が異なる。クライアントである人間にとっては、テキスト形式よりは、グラフのような図や画像の方が分かり易く、また指示も容易である。特に点や線についてはデータ・ウインドウ上で直接あるいはマウスによって参照指示が行えることが望ましい。一方、サーバとしての計算機にとっては、点については（ｘ，ｙ）　の座標値として数値化され、線については始点から終点まで通過する画素点をリストの形式となっていなければ処理効率が悪い。このような観点から表１に示す如く役割機能に応じて表記形式が異なる必要がある。
【００２９】
【表１】
2004054942.tif 000003
【００３０】
即ち、点や線を表すデータについては、クライアント１との間では、点や線を実体で表示しまたクライアント１がそれぞれの実体を参照しつつ指示できるようにし、サーバ３との間では、インデックス形式で特定しまた特定されたものについて一括転送したり連合して処理したりする。
【００３１】
図形や画像を表すデータについては、クライアント１との間では、画像や図形を実体表示しまたクライアント１が参照指示できるようにし、サーバ３との間ではリスト構造やラスタ構造で特定するようにする。
【００３２】
データ要素については、クライアント１との間では名前を指示し、サーバ３との間では名前ヘッダで特定するようにする。
【００３３】
サービス機能（エイジェントの抽象化サービス機能）については、クライアント１との間では、サービスをどのようなプログラムで行うかを明細にするサービス構造が先ずジェネリック・オブジェクト・ネットワーク形式で与えるようにする（クライアント１はこれにもとづいて所望するパラメータを与える）。そしてサービス実行の途中では、（ｉ）　サービス制約項目をパラメータとしてもつサービス項目や、（ｉｉ）サービス名をクライアント１が与え得るようにする。サーバ３との間では、（ｉ）　サービス構造表を与え、（ｉｉ）クライアント１からのサービス項目の指示に応じて、サービスを実行するサーバやサービスに当たって責任をもつサーバを指定するようにする。
【００３４】
図４はエイジェントをもつ構成を示している。図４に示すクライアント（Ｃｌｉｅｎｔ）とサーバ（Ｓｐｅｃｉｆｉｃ　ｒｏｌｅ　ｓｅｒｖｅｒ）とが、図３０に示すクライアント１とサーバ３″とに対応している。そして、図４に示す場合には、エイジェント（Ａｇｅｎｔ　ｒｏｌｅ　ｓｅｒｖｅｒ　）が中間において、例えて言えば旅行仲介業者の如き役割をはたすサーバ３′としてもうけられるようにされる。
【００３５】
図４に示す表示的プロセス２−１および従属表示的プロセス２−２は夫々図３０に示す表示的プロセスと同じ機能をもつものである。図４に示す場合には、クライアント１とエイジェント３′との間で表示的プロセス２−１に向かって、サービス要求と応答とが行われる。
【００３６】
エイジェント３′はクライアント１の意図にしたがったサービス計画を準備し、その役割を実行するサーバ（Ｓｐｅｃｉｆｉｃ　ｒｏｌｅ　ｓｅｒｖｅｒ）を検索し、サービス役割割当計画を行って、従属表示的プロセス２−２に向かって役割機能を実行すべく要求する。
【００３７】
サーバ（Ｓｐｅｃｉｆｉｃ　ｒｏｌｅ　ｓｅｒｖｅｒ）３″は割当サービス実行計画を実行し、実行結果を従属表示的プロセス２−２に呈示する。
【００３８】
エイジェント３′はサービス結果の内容をチェックして、サービス結果をクライアント１に呈示すべく表示的プロセス２−１に指示する。
【００３９】
図４に示す表示的プロセス２−１および従属表示的プロセス２−２は夫々、図１に示すコモン・プラットフォーム２によって実現される。そして図４に示すエイジェント３″は、図１に示すサービス・モジュール１７−ｉの１つとして与えられると考えてもよい。
【００４０】
図１に示すウエル・システム１１は、ＷＥＬＬ（Ｗｉｎｄｏｗ−ｂａｓｅｄ　ＥｌａｂｏｒａｔｉｏｎＬａｎｇｕａｇｅ　の略）　と仮称される機能言語を取り扱う機能部であるとしているが、ＷＥＬＬと呼ばれる特別な言語を取り扱う機能部のみに限定して考えられるべきものではなく、ウインドウを用いて対話を行い得る、より広い意味の処理機能部が図１に示すウエル・システム１１であると考えるべきである。
【００４１】
図５はウエル・システムとオブジェクト・ネットワークとの関係を説明する図である。図中の符号１１は図１に示すウエル・システムに対応している。また１９Ａ、１９Ｂ、１９Ｃは夫々図１に示すサービス・モジュールと組合わせられたオブジェクト・ネットワークであり、１８Ａ、１８Ｂ、１８Ｃは夫々所定の処理分野であり、図示の場合１８Ｃはカラー画像生成・色付け処理（Ｃｏｌｏｒ　Ｐｉｃｔｕｒｅ　Ｐｒｏｃｅｓｓｉｎｇ　ａｎｄ　Ｐａｉｎｔｉｎｇ）分野を表している。
【００４２】
ＷＥＬＬと仮称される機能言語に対して分野に対応するオブジェクト・ネットワークを与えると当該オブジェクト・ネットワークの処理がプログラムレスで実行が可能となる。また当該言語はウインドウ指向の言語であり、クライアントとのインターフェースはウインドウを介すことによって、クライアント・サーバ・モデルが実現される。
【００４３】
図５においては、ウエル・システム１１に対して、例えばカラー画像生成・色付け処理分野１８Ｃに対応して必要とされるウインドウと当該対応する処理を行うサービス・モジュール定義とで与えられるオブジェクト・ネットワーク１９Ｃを組合わせると、図示点線で示す如く当該ウエル・システムはカラー画像生成・色付け処理分野１８Ｃに対応するシステムとなる。言うまでもなく他の分野のオブジェクト・ネットワーク１９Ａや１９Ｂを組合わせると分野１８Ａや分野１８Ｂに対応するシステムとなる。
【００４４】
システムを構成する言語処理系に与えられるオブジェクト・ネットワークを変更すれば、システム機能は変化する。処理系は、対象とするオブジェクト・ネットワークの構成記述を入力データとして与えることにより、該当する分野処理を行うのであるから、ＷＥＬＬは元来グラフ構造エディタ１３を持っている。従ってシステムに、実行時にオブジェクト・ネットワークの変更機能を持たせることにより、システムの拡張性を持たせられる。特にインターフェースのために制約条件を名詞オブジェクトに持たせ、コモン・プラットフォーム中にあるメッセージ・ウインドウを利用できる。
【００４５】
互いに独立性のある多分野間の協調的統合のためにも拡張性は必要である。それは名詞オブジェクトについての制約関係の変更、動詞オブジェクトの実行制御についての同期性や排他性の動的変更など並行実行中のシステム環境への適応性がある。この場合、共通資財や計画修正などの管理の際に発生する役割転換を行う必要があり、得意機能に対応する対応処理機能を新しい共通の場の導入によって整合させる必要性が発生する。
【００４６】
図６は処理の整合を行う状況を概念的に示した図である。図示左端のクライアントが意図Ａないし意図Ｎをもって対応するサービスＡないしＮを並行して実行させようとするとき、各サービスを実行する上での制約が存在することが多い。
このような制約には、時相制約的なものと形態制約的なものとが存在し、前者にって実行時の規制やサービス間時相調整制御が行われ、後者によってサービス間形態調整制御が行われる。そして、このような規制や制御が行われた上で実行された複合サービス結果内容についてのチェックが行われ、クライアントに対してウインドウを介して呈示され、クライアントが評価を行うこととなる。
【００４７】
図７はコミュニケーション・マネージャの働きを示す図である。図中の符号は図１に対応している。なお図７においてウインドウ４に対応して「コモン・プラットフォーム」というラベルを付しているが、図１に示すコモン・プラットフォーム２においてクライアント１から直接見える所がウインドウ４であってコモン・プラットフォーム２を代表しているとも考えられることから「コモン・プラットフォーム」とラベルを付しているだけであり、図１に対応するとウインドウ４に該当しているものである。
【００４８】
図７に示す如くクライアントの意図がウインドウ４を介してシステムに伝えられるときには、必ずコミュニケーション・マネージャ１０を経由してカーネル１２や各マネージャ１４，１５，１６更にはサービス・モジュール１７−ｉに伝えられる。このことから、コミュニケーション・マネージャ１０はウインドウ４に直結している唯一のマネージャとなり、対話プロセスを集中的に管理している。
当該コミュニケーション・マネージャ１０の働きについては更に詳しく後述される。
【００４９】
上述の如くＷＥＬＬは分野を問わない拡張性のある言語である。それぞれの分野に対応するウインドウ定義やサービス・モジュール定義といったオブジェクト・ネットワークを与えると、ＷＥＬＬはその分野に対応する形で分野記述言語となる。このＷＥＬＬを用いたウエル・システムは、ウエル・カーネル１２と各種マネージャ１４，１５，１６など（ウエル・マネージャ）との２つの要素から構成される。
【００５０】
エキステンシブ・ウエル・カーネル１２は、以下の項目を行う。
（１）データ状態の把握（プロセスの把握を行い、次に実行するべき関数の選択）
（２）イベントの解析（各ウインドウから送られてくるイベントを判別し、その結果に対応するシステム内のプロシージャをコール）
（３）関数実行要求（総称的関数に制約条件を付加し、関数の実行をリクエスト）
【００５１】
また各マネージャは以下の４つに分けられる。
（１）コミュニケーション・マネージャ１０（テンプレート（データ）の間接的管理及びコモン・プラットフォームからの入力に対する各マネージャの制御）
（２）関数実行マネージャ１６（関数の実行管理）
（３）ウインドウ・マネージャ１４（ウインドウの管理）
（４）ディスプレイ・マネージャ１５（テンプレートの数値変換）
【００５２】
分野に依存しないＷＥＬＬと分野依存のサービス・モジュール１７−ｉとのデータ変換は、コミュニケーション・マネージャ１０が行う。このコミュニケーション・マネージャ１０を介すことによって、あらゆる分野のデータを扱うことが可能となり、ウエル・システム自体の汎用性は失われないこととなる。
【００５３】
ウインドウ４はクライアント１との間のインターフェースを行うものであり、以下の５つの個々のウインドウが存在する。
【００５４】
（１）ネットワーク・オペレーション・ウインドウ５（システム全体の制御）
（２）オペレーション・ウインドウ６（ネットワークのオペレーション表示及びその制御）
（３）コマンド・ウインドウ７（選択候補の表示及びキーボードからの入力）
（４）メッセージ・ウインドウ８（システム側からのメッセージ表示）
（５）データ・ウインドウ９−１，９−２（データの表示）
【００５５】
言うまでもなく、ある役割をプロセッサに導入する時、オブジェクト・ネットワーク中の個々のオブジェクトについての当該オブジェクトの表現方法は、役割依存でなければならない。人間に対しては、可視オブジェクトであり、計算機にとってはデータスキーマに則したデータ構造によって、オブジェクトが表現される必要がある。オブジェクト・ネットワークは個々のプロセッサで共有するが、データ構造は、テンプレート形式で定義されて、相互変換可能とされる。
【００５６】
オブジェクト・ネットワークを構成する各オブジェクトとしては、分野記述言語の枠組みに従って、名詞オブジェクトと動詞オブジェクトと制約オブジェクトとされ、制約オブジェクトは、被制約オブジェクトと制約条件とが属性として与えられ、そのための妥当性が各マネージャによって判定されて対応するオブジェクト処理を行いうるようにされる。
【００５７】
上述のウエル・システム１１にカラー画像生成・色付け処理分野をあてはめると上記ＷＥＬＬはいわばＷＥＬＬ−ＰＰＰ（Ｗｉｎｄｏｗ−ｂａｓｅｄ　Ｅｌａｂｏｒａｔｉｏｎ　Ｌａｎｇｕａｇｅ　ｆｏｒ　Ｐｉｃｔｕｒｅ　Ｐｒｏｃｅｓｓｉｎｇ　ａｎｄ　Ｐａｉｎｔｉｎｇ　）となる。そしてウエル・システム１１はカラー画像生成・色付け処理システムとなる。この場合の１つのオブジェクト・ネットワークである要素ネットワークは、個別オブジェクトの外観を表しかつ領域を確保している輪郭（Ｏｕｔｌｉｎｅ）を生成する輪郭部（Ｆｒａｍｅ　Ｓｅｃｔｉｏｎ）と、ラインとそれによって確保されている領域にしたがって属性値（Ａｔｔｒｉｂｕｔｅ　ｖａｌｕｅ）を与えるカラー部（Ｃｏｌｏｒ　Ｓｅｃｔｉｏｎ）とからなる。
【００５８】
図８は要素ネットワークの関係を示す図である。図８における左半分の「フレーム」２０は上述の輪郭部（Ｆｒａｍｅ　Ｓｅｃｔｉｏｎ）に該当し、右半分の「カラー」２１は上述のカラー部（Ｃｏｌｏｒ　Ｓｅｃｔｉｏｎ）に該当している。
【００５９】
輪郭部２０ではデータ自身を表す項目（Ｅｎｔｉｔｙ）を作成し、カラー部２１では輝度、色度などを表す属性（Ａｔｔｒｉｂｕｔｅ）を作成する。各クラスの状態は以下のようになる。
【００６０】
＜ＮＯＮＥ＞まだ処理の行われていない状態を表す
＜ＰＯＩＮＴ＞輪郭の基本となる点を示し、これを主要点（Ｐｒｉｎｃｉｐａｌ　Ｐｏｉｎｔ）と呼ぶ
＜ＰＯＩＮＴ　ＳＥＱＵＥＮＣＥ＞主要点に対し、その接続順序を示す
＜ＬＩＮＥ　ＳＥＧＭＥＮＴ＞接続順序に基づいてスプライン関数で補間処理がされた状態
＜ＬＩＮＥ＞ＬＩＮＥ　ＳＥＧＭＥＮＴを接続して１つのラインを完成した状態＜ＲＥＧＩＯＮ　ＳＥＧＭＥＮＴ＞画像におけるその水平走査線１本分の領域を示す
＜ＲＥＧＩＯＮ＞ＲＥＧＩＯＮ　ＳＥＧＭＥＮＴを画像に沿って上下方向に接続したものを示す
＜ＣＯＬＯＲＥＤ〜＞輝度、色度情報を示したそれぞれの項目を表す。また輪郭部とカラー部を結ぶＩＤＥＮＴＩＦＹは以下のように定義される。
〔ＩＤＥＮＴＩＦＹ〕処理の対象を特定する作業を示す。
【００６１】
図８に示す如きネットワークを利用してクライアントが絵を描く処理を行うことができる。当該処理の態様に関しては、本願発明と直接関連するものではないが、先に特許出願している特許第２８０１４５９号（特開平５−２３３６９０号公報）（オブジェクト・ネットワークによる言語処理システム）にも一部記述されている。
【００６２】
図９はコモン・プラットフォームをもつシステムにおいてカラー画像生成・色付け処理を行う態様を示している。図中の符号１，２，３は図１に対応している。
【００６３】
コモン・プラットフォームにおけるウインドウの表示によって、視覚的に要素ネットワークが組み込まれたことがクライアントにわかると、クライアントは描画するために必要な意図を選択する（クラス選択）。この例では点に輝度・色度を与えるＣＯＬＯＲＥＤ　ＰＯＩＮＴを選択する。
【００６４】
点に色をのせたいというクライアントの要求に対して、サーバは情報を格納するためのテンプレートを準備し（ＤＥＦＩＮＩＮＧ　ＰＲＯＣＥＳＳ）、どの点に対して色情報をのせたいのかクライアントに要求する。テンプレートについては後述される。
【００６５】
クライアントが点を指定すると（ＩＤＥＮＴＩＦＹ）、サーバはインデックスを参照することでその点を認識する。そしてその点にのせる輝度・色度データをクライアントに要求する。
【００６６】
クライアントからデータを応答として受け取るとＤＥＦＩＮＥ　ＯＰＥＲＡＴＩＯＮとしてテンプレートにデータを入力し、その結果としてのカラー画像をウインドウに表示する。
【００６７】
この表示によってクライアントは、そのプロセスを認識し、それを評価し、次の意図選択へ移ることができる。このようにクライアントはサーバからの意図を可視化オブジェクトとして把握する。
【００６８】
上述の如く描かれる点や線は夫々上述の名詞オブジェクトの形で管理され、また個々の名詞オブジェクトに対して行われる処理態様は上述の動詞オブジェクトとして与えられる。
【００６９】
上述のコミュニケーション・マネージャ１０は、ＷＥＬＬの拡張性を維持するためにデータ相互関係を管理する。そのためにデータは、テンプレートとして一元的に管理され、そこに属性を自由に設定できるようにされている。
【００７０】
図１０はテンプレートのフォーマットの一例を示す。個々のテンプレート２２がその属するオブジェクトについての番号に対応するかを示すインデックスと、座標と、属性とをもつ。テンプレートは、サービス・モジュール１７−ｉ内では「インデックス」によって管理されるが、データ・ウインドウ９を通してクライアントから与えられるものは、データ・ウインドウ９上の座標値である。サービス・モジュール１７−ｉは、座標値からテンプレートのインデックス検索を行えないので、コミュニケーション・マネージャ１０は座標値をインデックスに変換し、それをサービス・モジュール１７−ｉに引き渡す。更に、コミュニケーション・マネージャ１０は、ウエル・システムの持つ対話プロセスを集中管理する。
コモン・プラットフォームは、（ｉ）クライアントにオペレーションを伝えるオブジェクト・ネットワーク、（ｉｉ）メッセージや選択項目を伝えるメッセージ・ウインドウ、（ｉｉｉ）実際に描画などの作業を行い、画像データなどを表示するデータ・ウインドウなどを持つが、それらのウインドウを通して得られたクライアントの意図を実現するために、コミュニケーション・マネージャ１０は、その意図内容の入力に応じて、それを各マネージャやカーネルへ伝える。コミュニケーション・マネージャ１０のこのような対話プロセスの一元管理により、データが必ずここを通過することになり、テンプレートのチェックを行ったり、制約条件のチェックを行うことも可能になってくる。
【００７１】
図１１はコミュニケーション・マネージャの動作態様を示す。図中の符号１，３，５，８，９，１０，１２，１４，１５，１７は夫々図１中の符号に対応している。
【００７２】
ウインドウ上でのクライアントによる指示点（ｘ，ｙ）などがデータ・ウインドウ９からコミュニケーション・マネージャ１０に伝えられ、メッセージはメッセージ・ウインドウ８を介して伝えられ、オペレーションはオペレーション・ウインドウ５を介して伝えられる。そしてそれらは夫々コミュニケーション・マネージャ１０によって各種他のマネージャ１４，１５やカーネル１２やサービス・モジュール１７との間で情報の送受が行われる。
【００７３】
図１０に示す如きテンプレートは、点や線のデータ、図形／画像データなどに対応して用意されるものである。これは、点や線のデータ、図形／画像データなども、コモン・プラットフォームにおいて取り扱われるデータであることによる。それらは、オブジェクト・ネットワークの中でノードを形づくる名詞オブジェクトに属している。
【００７４】
したがって、データをクライアントが表示させあるいは参照しようとする場合、ウインドウ４上に表示されているデータの参照部分をマウスなどで示すと共に、名詞オブジェクトをオブジェクト・ネットワーク上で参照指示する。
【００７５】
このような参照指示機能は、クライアントが動詞オブジェクトの目的格としてのデータを指示することを主眼とするものである。これに対して、実体表示に当たっては、サーバが実行処理した結果をクライアントにみせるのに実際の点、線、図形、画像を実体としてウインドウ４上に見せるようにする。サーバ側ではデータを蓄積し、処理を行うに当たって、具体的なデータ構造（例えば、インデックス付加リスト構造、ラスタ構造など）に沿って蓄積したデータに対して処理を行う。
【００７６】
図１２はクライアントの指示に対応する動作を説明する図である。図中の符号１，４，１０，１２，１５，１７−ｉは夫々図１に対応し、２３はカーネル１２内にもうけられている作業用のバッファ、２３’はバッファ２３上の内容例、１９Ｃはオブジェクト・ネットワークを表している。
【００７７】
今、カラー画像生成・色付け処理がある程度進行しているとする。この場合、画像生成・色付け処理に対応するオブジェクト・ネットワーク１９Ｃから、該当するサービス・モジュール１７−ｉに対して、点や線などに対応するテンプレートがデータとして与えられ、当該サービス・モジュール１７−ｉからカーネル１２上（なお、バッファ２３はコミュニケーション・マネージャ１０上に位置していてもよい）のバッファ２３に対して、図示のバッファ内容２３’の如く、テンプレートのコピーが書き込まれている。即ち、例えば（ｉ）インデックス「１」で特定される点の座標が（５０，４０）であって色度や輝度（属性で示される）については未定（？で表している）であり、（ｉｉ）インデックス「２」で特定される点の座標が（８０，２５０）であって色度や輝度は未定であり、（ｉｉｉ）インデックス「３」で特定される点の座標が（２７０，４００）であって色度や輝度は未定であり、・・・の如き、各テンプレートのコピーがバッファ２３上に記述されている。
【００７８】
この状態の下で、いま、クライアント１がウインドウ４上で例えば座標（８０，２５０）を指示して１つの点を特定したとすると、コミュニケーション・マネージャはその動作を検出し、座標値についてウインドウ・マネージャ１４が検出してコミュニケーション・マネージャ１０に通知する。したがって、コミュニケーション・マネージャ１０は当該指示された点の座標値（８０，２５０）と対応するインデックス値を検索する。すなわちコミュニケーション・マネージャ１０はバッファ２３の内容にもとづいて座標（８０，２５０）をもつテンプレートに対応するものがインデックス「２」であることをコミュニケーション・マネージャ１０は知り、その後の処理に移る。
【００７９】
したがって、輪郭部で打たれた主要点の全座標を作業領域にコピーしたテンプレートと送られた座標との照合が行われる。一致もしくは近似の座標を検索するとそのインデックスを特定し、コミュニケーション・マネージャ１０はサービス・モジュール１７−ｉに送り制御を行う。サービス・モジュール１７−ｉはそのインデックスをもとにそのテンプレートの値を更新する。例えば座標位置を変更したり、属性上での輝度値を記述したりする。当該更新されたテンプレートはディスプレイ・マネージャ１５によって可視化オブジェクトに変換されウインドウ４に表示される。この場合は打たれた点がクライアントに認識できるように反転し浮き上がる。このようにエキステンシブ・ウエルは常にインデックスを中心に管理しているサービス・モジュール１７−ｉと情報交換をする。こうすることで特定の分野に依存しない拡張性の高いシステムが実現できるとともに、どのような分野に対してもクライアントはサーバの意図をディスプレイ・マネージャ１５によって変換された可視化オブジェクトをみて操作できる環境を提供する。
【００８０】
図１３は情報の交換動作を説明する図である。図中の符号１，４，６，９，１０，１２，１４，１６，１７は夫々図１に対応している。
【００８１】
クライアントがサーバと情報のやりとりを行う際、クライアントは常にウインドウを介して情報のやりとりを行う。そのためシステムは常にウインドウで待ち状態になっていなければならない。クライアントの意図によって駆動される駆動（Ｅｖｅｎｔ　Ｄｒｉｖｅｎという）にたいして、システムの制御をウインドウでの待ち状態にする駆動をＤａｔａ　Ｄｒｉｖｅｎ　という。Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔ　のクラスが選択されていてそれを駆動するのがＥｖｅｎｔ　Ｄｒｉｖｅｎである。しかし輝度・色度のデータが与えられなければ、関数は実行できないのでウインドウにてクライアントの入力待ちとなる必要がある。この駆動がＤａｔａ　Ｄｒｉｖｅｎ　である。
【００８２】
図１３において、クライアント１が或る座標上の点を指示して上記イベント・ドリブン（Ｅｖｅｎｔ　Ｄｒｉｖｅｎ）を行ったとする。この状況の下で、「コミュニケーション・マネージャ１０によってウインドウ・マネージャ１４に通知された上でウインドウ・マネージャ１４が座標値（例えば８０，２５０）を報告し、対応するインデックス「２」が調べられてサービス・モジュール１７−ｉに通知される」ことは、図１２に関連して説明した通りである。
【００８３】
今、クライアント１が当該点に対して色付けを行おうとしているとすると、図８に示したクラス「　Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔ」の状態分析をカーネル１２が行う。当該分析を行ったカーネル１２は関数実行マネージャ１６に対して関数実行要求を発する。これによって関数実行マネージャ１６は与えられる制約条件（Ｃｏｎｓｔｒａｉｎｔ）によって具体的関数を特定する。サービス・モジュール１７−ｉは特定された具体的関数にもとづいて処理が実行可能であるかを判別し、当該処理に必要なデータが不足していればカーネル１２を介して必要な作業を行う。例えば今、サービス・モジュールはクライアントに特定された点のテンプレートに輝度・色度情報を入力するようにしているとすると、輝度・色度データが未定であるため、関数の実行ができない。ここでＤａｔａ　Ｄｒｉｖｅｎ　が駆動され、この場合データ入力に必要なＣｈｒｏｍｉｎａｎｃｅ　Ｄｉａｇｒａｍ　とＬｕｍｉｎａｎｃｅ　Ｄｉａｇｒａｍ　が開かれ、輝度見本や色見本が表示され、クライアントの入力待ちとなる。
【００８４】
サービス・モジュール１７−ｉは必要なウインドウ（図１３に示すＤＩＡＧＲＡＭのためのウインドウ）を開いて、ユーザの応答を待つが、その応答以後そのウインドウが不要になる場合がある。またサービス・モジュールによっては多数のウインドウを必要とするものも考えられるため、表示されるウインドウは必要最小限にするべきである。そこでウインドウ・マネージャ１４内にウインドウの状態を示すテーブルを用意し、不要ウインドウの自動消去を行う。
【００８５】
図１４はチェック・モジュールの動作を説明する図である。図中の符号８はメッセージ・ウインドウ、９はデータ・ウインドウ、２２はテンプレート、２４はチェック・モジュール、２５は制約条件、２６はオブジェクト・ネットワークを表している。
【００８６】
クライアントは、オブジェクト・ネットワークに従った作業の流れの中で、自分がデータ・ウインドウ上に生成していったデータの正当性を確認したいと思うことがある。そのようなクライアントが確認したいと思う事柄を一つの制約条件として捉える。このような制約条件２５は、オブジェクト・ネットワーク２６のそれぞれの名詞オブジェクト（テンプレート２２で表されるデータの状態）に付属的なものとして課され、サーバ側では、その制約条件とテンプレートの内容とを比較することで確認作業を行う。ここで問題にされるのは、サーバが、処理対象とされるテンプレートの特定方法（Ｉｄｅｎｔｉｆｙ）をどのように持つべきかである。ウエル・システムでは、コミュニケーション・マネージャの機能を利用してこれを実現できる。コミュニケーション・マネージャ１０は、オブジェクト・ネットワークの持つテンプレートの内容データによってクライアントとサーバとの間のデータの整合性を管理しているので、クライアントがマウスでヒットした座標値（Ｘ，Ｙ）から上記図１２を参照して説明した如く処理対象を特定するための情報をテンプレート２２から引き出して、チェック・モジュール２４（具体的に制約条件をテンプレートに照らし合わせるサービス・モジュール）に渡すことが出来る。チェック・モジュールでは、その情報を頼りに、その制約条件が満足されているかどうかを確認し、その結果をメッセージ・ウインドウを通してクライアントに知らせる。このようなチェック・モジュール２４によるチェック動作は、図８において例えばクラス＜ＰＯＩＮＴ＞の状態からクラス＜ＣＯＬＯＲＥＤＰＯＩＮＴ＞の状態へ移行した際に、正しい形で移行が行われたか否かをチェックするためなどに利用される。更に他の制約動作も、他のサービス・モジュールと同様に対応するマネージャを用意することで実現される。
【００８７】
図１５は制約条件の表示態様を示す図である。図中の符号５，８，９，１０は図１に対応し、２５は図１４に示される制約条件、２７は名詞オブジェクトを表している。
【００８８】
図形描画の間に、例えば描かれたライン（線分）に対してどのような制約条件が付されているかをクライアントに知らせる必要があることがある。このような場合の各マネージャの動作が図１５によって説明される。
【００８９】
上記ライン（線分）は、それ自体がデータの状態を表していることから、名詞オブジェクト２７の１つとして捉えることができる。上記制約条件２５は名詞オブジェクト２７に対応して付されているが、ライン（線分）という状態に対して課され得る制約条件２５として考えられるのは「連続性（Ｃｏｎｔｉｎｕｉｔｙ）」と「対称性（Ｓｙｍｍｅｔｒｙ）・・・（註）当該線分がある軸または点に対して対称な状態にあるか否か」といったものである。
【００９０】
名詞オブジェクト２７がもつこのような制約条件２５はコミュニケーション・マネージャ１０の介在の下でメッセージ・ウインドウ８に表示されてクライアントに知らされる。なお図１５において、メッセージ・ウインドウ８の内容に関して「Ｓｙｍｍｅｔｒｙ−Ｐｏｉｎｔ，Ａｘｉｓ」とあるのは「点対称」か「線対称」かを問う表示である。当該表示に対応して、クライアントは「Ｐｏｉｎｔ　」か「Ａｘｉｓ」かをピック・アップするようにして意図をサーバ側に通知する。
【００９１】
図１４に示すチェック・モジュール２４は、メッセージ・ウインドウ８を通しての起動要求をクライアントから受けるとファンクション・マネージャによって起動される。チェック・モジュール２４は、必要があればクライアントに対してアイデンティファイ作業の要求をメッセージ・ウインドウ８を用いて行う。クライアントは、それに対してマウスでデータ・ウインドウ上の可視化対象をヒットすることでコミュニケーション・マネージャ１０へその対象についてのデータ値の引き渡しを行う。このデータ値は、コミュニケーション・マネージャ１０によって図１２に示す如く対象に相当する項目データのインデックスに変換されるとチェック・モジュール２４へ送られ、このインデックスを使ってチェック・モジュール２４は、テンプレートから具体的な属性値を引き出してチェックを行う。
チェックされた結果は、メッセージ・ウインドウによってクライアントに知らされる。
【００９２】
図１６はアイデンティファイ作業を説明する図である。図中の符号４，５，８，９，１０，１４，１７−ｉは夫々図１に対応している。
【００９３】
上述の如くチェック・モジュール２４がクライアントに対してアイデンティファイ作業の要求を行うと、クライアントはデータ・ウインドウ９上で、図１６に示す如く、例えばあるライン（線分）をヒットする。これに対応して図１２に示した如くウインドウ・マネージャ１４の働きによって関連しているデータがコミュニケーション・マネージャ１０に知らされ、コミュニケーション・マネージャ１０が、対応するインデックスを知り、当該インデックスをチェック・モジュール２４に通知する。これによって、図１４に示した如く、チェック・モジュール２４がチェックし、その結果がメッセージ・ウインドウ８において表示される。
【００９４】
なお、図形描画における点や線が名詞オブジェクトとしてデータの１つとして把握され、図９に示す「単位意図（要求）」などの要求が動詞オブジェクトとして対応づけられる。そしてそれらの名詞オブジェクトや動詞オブジェクトが夫々テンプレートの形で表現される。
【００９５】
上述した構成と動作とについて、より具体的に例を挙げつつ説明を補足する。
図４において、クライアント１の意向に従ってサービス計画を準備するようにする。例えば、図１７に示す如き魚のうろこパターンのようなテキスチャを描画したいとの意図をクライアントが持つとき、テキスチャ描画の意図をサービス依頼（要求）としてエイジェント・ロール・サーバ３′に伝えると、エイジェント・ロール・サーバ３′は流れ線（ｆｌｏｗ　ｌｉｎｅｓ）とセル画像（ｃｅｌｌ　ｐｉｃｔｕｒｅ）とをクライアントと協力して描画するサービス計画を具体的に準備する。流れ線を書くには、図８の要素ネットワークがある要素画像を描くために利用できるので、それを利用する。すなわち、図８中でＰＯＩＮＴ　からＬＩＮＥまでの部分ネットワークをまずオブジェクトネットワークとして表示する。
【００９６】
それは図４に示す役割サーバ検索（事項検索）が流れ線（ｆｌｏｗ　ｌｉｎｅｓ）のｌｉｎｅの事項を検索すると、相当する単語が要素ネットワーク中に存在することを検索し、その部分オブジェクト・ネットワークを、コモン・プラットフォーム２に「ｆｌｏｗ　ｌｉｎｅ　」の表示と共に表示する。
【００９７】
クライアント１は当該表示に従って図１７（ａ）に示すように魚体を示す点線を沿う形で曲線ＡとＢとを描く。
【００９８】
次に図１７（ｂ）に示すように、線Ｃ，Ｄを描く。このとき、Ｈｏｗ　ｍａｎｙ　ｐｏｉｎｔｓ　　ｄｏ　ｙｏｕ　ｄｉｖｉｄｅ　ｏｎ　Ｃ　ａｎｄ　Ｄ　？　の如き質問がエイジェントからメッセージ・ウインドウ８に表示され、それに対してクライアント１が値「４」とキーインして答えると、図１７（ｃ）に示すように、４個の補間曲線が引かれる。次のステップで質問Ｈｏｗ　ｍａｎｙ　ｐｏｉｎｔｓ　ｄｏ　ｙｏｕ　ｄｉｖｉｄｅ　ｏｎ　Ａ　ａｎｄ　Ｂ　？に対し値「１６」と答えると、各補間曲線上に図１７（ｄ）に示す如くうろこを描くための１６個の中心点が表示される。この場合、Ｆｌｏｗ　ｌｉｎｅｓについての制約条件として隣接するＦｌｏｗｌｉｎｅｓとの間の距離に比例して中心点間距離が大きくなるような制約条件が与えられるとすると、即ち、Ｆｌｏｗ　ｌｉｎｅｓ間隔が狭ければ、Ｃｅｌｌ　Ｐｉｃｔｕｒｅとしての「うろこ」の寸法が小さくなければならないとすると、このため次のＳａｔｉｓｆｙｉｎｇ文制約記述が与えられる。
【００９９】
Ｓａｔｉｓｆｙｉｎｇ　：
Ｅｖｅｒｙ　ｌｅｎｇｔｈ　ｂｅｔｗｅｅｎ　ａｄｊａｃｅｎｔ　ｐｏｉｎｔｓ　ａｌｏｎｇ　ｆｌｏｗ　ｌｉｎｅ　ｉｓ　ｐｒｏｐｏｒｔｉｏｎａｌ　ｈａｖｉｎｇ　ａ　ｆｉｘｅｄ　ｒａｔｉｏ　ｗｉｔｈ　ｖｅｒｔｉｃａｌ　ｌｅｎｇｔｈ　ａｔ　ｔｈｅ　ｐｏｉｎｔ　ｂｅｔｗｅｅｎ　ａｄｊａｃｅｎｔ　ｆｌｏｗ　ｌｉｎｅｓ，
ｅｎｄ．
【０１００】
それと同時に「ｃｅｌｌ　ｐｉｃｔｕｒｅ」の表示と共にうろこパターンを画像を描くようにＦｌｏｗ　ｌｉｎｅｓと同時に要素ネットワークとしてのオブジェクト・ネットワークが表示され、クライアントはそれに従って図１８に示す如く、上記中心点（×印）を中心としてうろこのカラー画像を描く。
【０１０１】
この処理は、図２の処理フロー（Ｉ）に従って実行される。
この実行をある特定のスペシフィック・ロール・サーバ３″に割り当てるために、図４に示すサービス役割割り当て計画（サービス仕様）によって実施すべき処理内容があるサーバに要求される。
【０１０２】
それが図４に示すサービス役割機能（要求）として計画されたスペシフィック・ロール・サーバに実行要求が発行される。この発行はエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との間での共通の場を通じて機能する。
【０１０３】
エイジェント・ロール・サーバ３′に依存した図４に示す従属表示的プロセスで所定の表示が行われて、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との交信が行われ、当該従属表示的プロセスがコモン・プラットフォームとして、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″群との間の連絡通信の場を提供する。したがって、エイジェント・ロール・サーバ３′が複数のスペシフィック・ロール・サーバ３″に依頼した複数の処理内容、この例では「Ｆｌｏｗ　ｌｉｎｅｓ」と「ｃｅｌｌ　ｐｉｃｔｕｒｅ」との間に存在する整合性についての制約条件について規定し、実行する必要がある。
【０１０４】
そのための前提条件として、予めテンプレートについての定義を行うことを必要とする。点についてのテンプレートは図１０のように定義され、そこでの属性値集合としてのａｔｔｒｉｂｕｔｅｓ　ｆｏｒ　ｐｏｉｎｔ（ｓ）（ｘ，ｙ）として、当該点に関する輝度、色度などの属性値を入れるべきデータ形式が示されている。Ｌｉｎｅについては、走査線インデックスを”ｉ”　とすると、”ｉ”　についてのリスト構造として（ｘ，ｙｉ　）の値が、図１９に示す如きＬｉｎｅ用テンプレートが定義される。
【０１０５】
即ち、当該Ｌｉｎｅが走査線と交差する各点のうちの主要点Ｎｏ．１，Ｎｏ．２．．．Ｎｏ．ｎについてのテンプレート（図１０参照）上のａｔｔｒｉｂｕｔｅｓ　ｆｏｒ　ｐｏｉｎｔ（ｓ）（ｘ，ｙ）に、入口側のポインタｐと当該点の輝度と当該点の色度ベクトルと出口側のポインタｐとが記述され、上記夫々のポインタによって他を指示することによって、全体が１つのＬｉｎｅに対応するＬｉｎｅ用テンプレートとして定義される。
【０１０６】
なお、図１９に示す各点の属性値に輝度と色度ベクトルとを記述しているのは次の理由による。即ち、Ｐｏｉｎｔ　とＣｏｌｏｒｅｄ　ｐｏｉｎｔ　とがオブジェクト・ネットワーク中に定義されているような要素ネットワークでは、最初からＰｏｉｎｔ　のテンプレート中に、Ｃｏｌｏｒｅｄ　の修飾形容詞に対応した輝度値や色度ベクトル値を属性値として持たせることが望まれるからである。
【０１０７】
ＦｌｏｗというＬｉｎｅを限定する形容詞節が付加されると、そのためにテンプレートに付加属性のためのスペースを必要とする。このスペースの設定は予め行われてもよいし、エクステンシブル　ＷＥＬＬ　の機能の拡張機構としてのグラフ構造エディタを用いて必要時点で設定してもよい。
【０１０８】
図１７（ｃ）に示した流れ線を示すようにする当該形容詞節で特定するデータ構成としては、図２０に示す如きものが用意される。図２０における符号３０はＦｌｏｗという『Ｌｉｎｅを限定する形容詞節』につけられたインデックスであり、符号３１は当該Ｆｌｏｗに属するＬｉｎｅについてのインデックスであり、符号３２は当該Ｌｉｎｅについてのデータ配列（図１９に示す如きもの）である。
【０１０９】
Ｃｏｌｏｒｅｄ　ｐｏｉｎｔ　についてＦｅａｔｕｒｅ　という形容詞をつけて、それをＦｅａｔｕｒｅｄ　ｃｏｌｏｒｅｄ　ｐｏｉｎｔとすると、テンプレートの属性の所に、図２１に示す如く、Ｆｅａｔｕｒｅ　名を付加する。Ｆｅａｔｕｒｅ　名の所には、”ｅｄｇｅ”，”ｈｉｇｈｌｉｇｈｔ”または”ｎｏｎｅ”を記述するようにする。”ｅｄｇｅ”が記述されると、その点が輝度や色度ベクトルからエッジと識別されたことを示す。”ｈｉｇｈｌｉｇｈｔ”　が記述されると、その点がハイライトとして示されることを示す。また”ｎｏｎｅ”が記述されると、その点にはＦｅａｔｕｒｅ　を持たないことが示される。
【０１１０】
そのいずれにしても、Ｆｌｏｗ　ｌｉｎｅｓに対して図１７に示したようなＡ，Ｂ，ＣおよびＤの４個のＬｉｎｅｓ　に対応して、夫々のＬｉｎｅ用テンプレートが準備される。次にクライアント１とコモン・プラットフォーム２中のメッセージ・ウインドウ８との通信によって更に４本のＦｌｏｗ　ｌｉｎｅｓのためのＬｉｎｅ用テンプレートが設定される。次に”ｃｅｌｌ　ｐｉｃｔｕｒｅ”を描画するために、オブジェクト・ネットワーク（図８に示す如き）に対応したオブジェクトに対応してテンプレートが設定され、最後のＣｏｌｒｅｄ　Ｒｅｇｉｏｎ　では輝度色度データをもつラスタ形式のテンプレートを持つようになる。
【０１１１】
このように設定された「うろこ」画像を、流れ線上に設定された中心点に「うろこ」の中心点を合わせ、サイズを選んで写像する。この際、制約条件を必要とする。
【０１１２】
この時点までにおいて、Ｉｎｔｅｒｖａｌ　ｂｅｔｗｅｅｎ　ｔｈｅ　ａｄｊａｃｅｎｔ　ｃｅｎｔｅｒ　ｐｏｉｎｔｓ　ｏｎ　ｔｈｅ　ｆｌｏｗ　ｌｉｎｅｓ　が各ｃｅｎｔｅｒ　ｐｏｉｎｔに定義されている。即ち、各ｆｌｏｗ　ｌｉｎｅ　がもつ属性としてＩｎｔｅｒｖａｌが定義されており、ｆｌｏｗ　ｌｉｎｅ　のｄｒａｗｉｎｇ　の実行後計算され、属性値として、各ｃｅｎｔｅｒ　ｐｏｉｎｔｓ　についてのテンプレート中にそのＩｎｔｅｒｖａｌ値が格納されている。
【０１１３】
そして同様に、ｃｅｌｌ　ｐｉｃｔｕｒｅのもつ属性としてｓｃａｌｅ　をもち、そのｓｃａｌｅ　値とｉｎｔｅｒｖａｌ値との間の制約関係として、
ａ　ｓｃａｌｅ　ｏｆ　ｃｅｌｌ　ｐｉｃｔｕｒｅ　＝　ｔｈｅ　ｉｎｔｅｒｖａｌ　ｂｅｔｗｅｅｎ　ｔｈｅ　ａｄｊａｃｅｎｔ　ｃｅｎｔｅｒ　ｐｏｉｎｔｓ　ｏｎ　ｔｈｅ　ｆｌｏｗ　ｌｉｎｅ
を設定する。そしてこれを満足するように、ｍａｐｐｉｎｇ　を行うスペシフィック・ロール・サーバ３″にそのｍａｐｐｉｎｇ　を依頼する。
【０１１４】
図２２と図２３とは上下に組合されて１つの流れを表すテキスチャ描画の流れ図を示している。
【０１１５】
クライアント１の意図する所が、図２２、図２３における左端に、上から下に向かう時系列で示される。またエイジェント・ロール・サーバ３′の処理が、図２２、図２３の左右中央部に、上から下に向かう時系列で示される。さらにスペシフィック・ロール・サーバ３″の処理が、図２２、図２３における右端に、上から下に向かう時系列で示される。また図２２、図２３における符号１，２−１，２−２，３′，３″は図４に対応している。更に図２２の下端における矢印（Ａ）は図２３に示す矢印（Ａ）につらなるものである。
【０１１６】
クライアント１がテキスチャ描画を意図してテキスチャ・サービスを要求すると、エイジェント・ロール・サーバ３′はテキスチャ描画サービス計画を準備し、統合サービス・プラットフォームを設定する。これにもとづいて、クライアントは図１７に示した如きＦｌｏｗ　ｌｉｎｅ　を表示させようとして、Ｆｌｏｗ　ｌｉｎｅ　表示を要求する。
【０１１７】
エイジェント・ロール・サーバ３′はフローライン計画を検索し、スペシフィック・ロール・サーバ３″に対してフローライン実行サービス設定を要求する。
【０１１８】
スペシフィック・ロール・サーバ３″の設定した結果が、エイジェント・ロール・サーバ３′にて中継されて、クライアント１に示される。
【０１１９】
クライアント１がＦｌｏｗ　ｌｉｎｅ　描画を意図して、フローライン用画面を要求すると、エイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″に依頼されて、クライアント１に対してフローライン画面が表示されると共に制約条件の提示を要求する。
【０１２０】
制約条件について応答が了承されると、エイジェント・ロール・サーバ３′はフローラインとセンタ点とを表示する計算を行って、クライアント１に対して表示する。クライアント１は必要に応じて修正要求を行う。
【０１２１】
次いでクライアント１はＣｅｌｌ　ｐｉｃｔｕｒｅについての描画を意図し、図２３に示す如く、エイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との処理によって、セル・ピクチャ用のコモン・プラットフォームが設定される。
【０１２２】
クライアント１がセル・ピクチャの描画を意図すると、同様に、セル・ピクチャの画面が表示されかつ制約条件の提示が要求される。
【０１２３】
クライアント１が制約条件について応答すると、セル・ピクチャについての処理結果が統合サービス・プラットフォームに統合され、クライアント１の評価を待つようにされる。
【０１２４】
ここでは、フローライン描画とセルピクチャ描画との二つの仕事が並列に実行可能になっている。並列実行可能な動詞オブジェクトを検出するためのシステム構成は上記テキスチャ描画の例では、テキスチャを描くためのフローラインのための線を描くことと、フローライン上にセル画像を描くこととを並列に行い得るようにされる。そしてその結果がそろった所で、統合描画プロセスに移る。従ってスペシフィック・ロール・サーバ３″としてはフローライン用、セルピクチャ用、統合描画用の３個のサーバがエイジェント・ロール・サーバ３′に付属している。これらを制御するオブジェクト・ネットワークとしては図８の要素ネットワークを使用し、フローラインとしては図中右側のＮｏｎｅからＬｉｎｅまでを使用する。これはＦｌｏｗ　ｌｉｎｅ　のｌｉｎｅを描くことを目的としていることから、この部分のみがコモン・プラットフォームに図示され、表示的プロセス２−１中でクライアント１が使用する。Ｃｅｌｌ　ｐｉｃｔｕｒｅと統合描画との両部はｐｉｃｔｕｒｅ　を描画することから、図８全体がオブジェクト・ネットワークとしてクライアントに使用可能である。
【０１２５】
これら個々のスペシフィック・ロール・サーバ３″における実行結果は、エイジェント・ロール・サーバ３′を通じて、クライアント１とエイジェント・ロール・サーバ３′との間に存在するコモンプラットフォーム上にその実行結果としての画面表示される。
【０１２６】
得られた画像表示をクライアント１は観察しながら、エイジェント・ロール・サーバ３′はその仕事に関して必要とする属性もしくは制約についてクライアントに質問を行う。このための構成が図１４に示されている。図１４に示す如く実行され確認され、ｄａｔａ　ｉｄｅｎｔｉｆｙ　の後に、コモン・プラットフォームのデータ・ウインドウ９に表示され、クライアントから応答された制約がチェックされ、その実行がＶａｌｉｄｉｔｙ　ｃｈｅｃｋ２４によっておこなわれ、メッセージ・ウインドウ８でその実行が確認されて、結果がデータ・ウインドウ９に表示される。
【０１２７】
これらの特定サービスは、エイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″へ、その間に存在するコモン・プラットフォームを用いて依頼される。このコモン・プラットフォームが図２２、図２３においては従属表示的プロセス２−２として示され、エイジェント・ロール・サーバ３′に従属しているものとして示されている。この場合の態様は、ソフトウェアの仕様からオブジェクト・ネットワーク・データをはじめとするすべては、クライアント１とエイジェント・ロール・サーバ３′との間の場合と全く同じ形式をとる。それは、システム開発の際のユーザフレンドリ性を確保するためである。
【０１２８】
インタラクションの形態としては、
（ａ）エイジェント・ロール・サーバ３′のような抽象化サービスはジェネリック・オブジェクト・ネットワークとして抽象化されている。当該ジェネリック・オブジェクト・ネットワークは、パラメータあるいは制約条件によって具体化されたスペシフィック・オブジェクト・ネットワークと階層化される。なおスペシフィック・オブジェクト・ネットワークは特定の機能に対応したサービスを行うネットワークである。
（ｂ）個々のオブジェクト間の属性は、親の方から（例えばエイジェント・ロール・サーバ３′）　から受け取り、それを用いてスペシフィック・ロール・サーバ３″は実行し、その結果は合成された属性（ｓｙｎｔｈｅｓｉｚｅｄ　ａｔｔｒｉｂｕｔｅ）　として、依頼した親の方に受け渡され、エイジェント・ロール・サーバ３′はそれらの属性値を用いて、制約条件を付し、新しいデータを得たり、チェック機構を動かす。（ｃ）制約条件などは、図６に示す如く、形態的制約と時相的制約とが存在する。
【０１２９】
ジェネリック・オブジェクト・ネットワークは、図８に示す要素ネットワークの如きものでテキスチャ画像を図１７、図１８のように描くため、クライアントがテキスチャ描画の意図からその要求をエイジェント・ロール・サーバ３′に与えると、エイジェント・ロール・サーバ３′のもつジェネリック・オブジェクト・ネットワークを、統合サービスプラットフォームとして、クライアント１とエイジェント・ロール・サーバ３′との間の意志疎通のために設定する。そしてその上に上記図１７や図１８を表示するようにする。このようなネットワークは、エクステンシブル　ＷＥＬＬ　のカーネル部の機能としてのグラフ構造エディタで行われる。
【０１３０】
図２４はオブジェクト・ネットワークの階層構造を示すものである。例えば数学において変数を一般化して与えて公式を用意しておくように、パラメータや制約条件などを一般化して（抽象化して）与えておいたジェネリック・オブジェクト・ネットワーク３３を用意しておく。そして、特定の処理を行わせるための特定のパラメータや制約条件３４を、ジェネリック・オブジェクト・ネットワーク３３中に組み込むことによって、当該特定の処理のためのスペシフィック・オブジェクト・ネットワーク３５がつくり上げられる。
【０１３１】
図２５はエイジェント・ロール・サーバ３′からスペシフィック・ロール・サーバ３″への処理の詳細化をテキスチャ描画の場合についてのジェネリック・オブジェクト・ネットワークを例示した図である。
【０１３２】
そして図２５中で四角形で示した名詞オブジェクトと関連したテンプレートがテキスチャ描画システムの設計を行ったエキスパートによって準備され、それをＷＥＬＬの機能によってエイジェント・ロール・サーバ３′もジェネリック・オブジェクト・ネットワークとデータとに分けてもつようにされる。
【０１３３】
Ｆｌｏｗ　ｌｉｎｅ　の名詞オブジェクトがクライアントにより指示されると、図８の要素ネットワークのうちＬＩＮＥ〜ＮＯＮＥの部分グラフがＦｌｏｗ　ｌｉｎｅ　のための部分描画プロセスとして、フローライン用コモン・プラットフォームがスペシフィック・ロール・サーバ３″からエイジェント・ロール・サーバ３′を中継して、クライアント１に指示され、これを用いて図１７（ａ）（ｂ）（ｃ）（ｄ）のように描画プロセスが進行するようにされる。
【０１３４】
この際、テンプレートは、要素ネットワークのもつテンプレートがそのまま利用される。ＦｌｏｗというＬＩＮＥについた修飾用形容詞は、ＬＩＮＥに新しい属性構造をテンプレートとしてもち、さらに、（ｉ）　制約条件を付加すべきこと、および（ｉｉ）テキスチャ描画のためにはＬＩＮＥが描画用データウインドウに表示されるのではなくセルピクチャを写像する図２６に示すような点の位置のみが必要であること、を示している。
【０１３５】
以上のことから、Ｆｌｏｗ　ｌｉｎｅ　を描画するためには、図１７（ｂ）をもとに図１７（ｄ）を描き、さらに図２６を描画するための制約条件、もしくはサブネットワークを与えるようにされる。
【０１３６】
したがってＦｌｏｗという形容詞による修飾内容についての枠組みとして、前述したように、与えられた制約条件のもとに、
Ｌｅｎｇｔｈ　ｂｅｔｗｅｅｎ　ａｄｊａｃｅｎｔ　ｐｏｉｎｔｓ　ａｌｏｎｇ　ｆｌｏｗ　ｌｉｎｅ
Ｖｅｒｔｉｃａｌ　Ｌｅｎｇｔｈ　ｂｅｔｗｅｅｎ　ａｄｊａｃｅｎｔ　ｆｌｏｗ　ｌｉｎｅｓ　について、エイジェント・ロール・サーバ３′はクライアントから定義してもらう。このために、メッセージ・ウインドウ８によって前述したような分割する点の数についての質問応答が行われる。その結果が図１４のＣｏｎｓｔｒａｉｎｔｓ　ｏｎ　ｎｏｕｎ　ｏｂｊｅｃｔ２５に与えられ、Ｆｌｏｗの修飾が行われ、図２６の結果が得られる。図中の点はＣｅｌｌ　ｐｉｃｔｕｒｅを写像する位置を知らせるためのもので、実際のＴｅｘｔｕｒｅ　画面には表示されない。これはＴｅｘｔｕｒｅ　とＦｌｏｗ　ｌｉｎｅ　の両者が与えられることから、Ｔｅｘｔｕｒｅ　ｐｉｃｔｕｒｅ　表示の際、消去される。
【０１３７】
Ｃｅｌｌ　ｐｉｃｔｕｒｅについても同様で、ｐｉｃｔｕｒｅ　によって要素ネットワークによってカラー画像が描画される。この描画の後、図２６の点集合中の各点の周りに写像されるが、ｐｉｃｔｕｒｅ　はＣｅｌｌによって修飾されており、その大きさをＦｌｏｗ　ｌｉｎｅ　での隣接点間距離との関係によって規定する。そのためにＣｅｌｌ　ｐｉｃｔｕｒｅに付属する制約としてＣｅｌｌ　ｐｉｃｔｕｒｅの２つのｌｅｎｇｔｈｓ　がＦｌｏｗ　ｌｉｎｅ　について定義されているｌｅｎｇｔｈと一致させる処理が行われて写像（ｍａｐｐｉｎｇ）　描画がＴｅｘｔｕｒｅ　ｐｉｃｔｕｒｅ　によって行われる。この際、Ｃｅｌｌ　ｐｉｃｔｕｒｅ　ｓｉｚｅ　とＦｌｏｗ　ｌｉｎｅ　のｌｅｎｇｔｈとの比を設定することが可能である。これは図６に示される制約意図の実現と考えられ、サービス間形態調整制御が実際に整合化を行う。
【０１３８】
以上のことを実行するために、Ｔｅｘｔｕｒｅ　ｐｉｃｔｕｒｅ　を描画対策としての要求は、Ｒｅｑｕｅｓｔ　ｔｏ　ｐａｉｎｔ　ｔｅｘｔｕｒｅ　ｐｉｃｔｕｒｅがクライアントから意図として、図２２、図２３に示されているように、エイジェント・ロール・サーバ３′に与えられると、エイジェント・ロール・サーバ３′は、統合サービス・プラットフォームをサービス計画準備のプロセスとして設定し、その上に図２５で示されるジェネリック・オブジェクト・ネットワークをデータベース検索によって取り出し、それと同時にｆｌｏｗ　ｌｉｎｅ　とｃｅｌｌ　ｐｉｃｔｕｒｅとのためのスペシフィック・ロール・サーバが割り当てられる。
【０１３９】
以上のスペシフィック・ロール・サーバのなすべき仕事については、図４に示されるサービス計画準備で、役割サーバ検索（事項要求）が、エイジェント・ロール・サーバ３′を制御しているＷＥＬＬシステムのカーネル部を介してデータベースサーバに検索依頼し、割り当てられたスペシフィック・ロール・サーバにその仕事を割り付ける。あるいは、元来その仕事を行っていたスペシフィック・ロール・サーバを事項検索を行って見出し、それに依頼する。
【０１４０】
スペシフィック・ロール・サーバが行う役割は基本的な名詞オブジェクトの実現を行うサービス実行と考えられ、その役割は具体的オブジェクトネットワークによって定義される。これに対しエイジェント・ロール・サーバは、それに制約条件や、他との整合化を行う仕事で、クライアントとの間でのインタラクティブな対話プロセスを伴うようなジェネリック・オブジェクト・ネットワークを含んだ仕事を分担する。
【０１４１】
以上述べたことを、インタラクションの形態について説明したオブジェクト指向の属性値についての継承および合成型の観点からシステムを考えると、
継承型データ：継承型データをもとにある処理を要求（Ｒｅｑｕｅｓｔ）　するエイジェント機能を行うサーバから具体的テンプレートを受け取る。即ちそのデータに対応したテンプレートの型として定まったデータ容器にデータ値が格納された具体的テンプレートを受け取る。この仕事を担当するスペシフィック・ロール・サーバもエクステンシブル　ＷＥＬＬ　によって記述され、実行を行う。具体的実行は自身が行っても、他のサービスモジュールに依頼してもよい。
合成型データ：上記によりＲｅｑｕｅｓｔ　されたデータをもとに依頼されたスペシフィック・ロール・サーバが実行処理を行う。その結果を格納すべきデータ型としてのテンプレート型式は、Ｒｅｑｕｅｓｔ　時に受け取っており、それに格納して応答としてエイジェント・ロール・サーバに返す。この一連の仕事もエイジェント・ロール・サーバとの間に存在するコモン・プラットフォーム（これはスペシフィック・ロール・サーバがもっている）とそれを支援するコミュニケーション・マネージャが行う。
【０１４２】
以上のエイジェント・ロール・サーバ３′と、スペシフィック・ロール・サーバ３″との関係は、クライアントとＳｅｒｖｅｒとの間のエクステンシブル　ＷＥＬＬ　の処理形態と全く同様である。しかしながらエイジェント・ロール・サーバが複数のデータをもとに継承型データとして複数個のスペシフィック・ロール・サーバに処理作業を依頼した時には、制約処理をエイジェント・ロール・サーバが行わなければならない。例として前述したＴｅｘｔｕｒｅ　ｐｉｃｔｕｒｅ　の描画を考えるとＦｌｏｗ　ｌｉｎｅｓとＣｅｌｌ　ｐｉｃｔｕｒｅとの描画を、それぞれ独立のスペシフィック・ロール・サーバに依頼し、その結果が返された時、Ｆｌｏｗ　ｌｉｎｅｓとＣｅｌｌ　ｐｉｃｔｕｒｅとの間の制約条件を満足させなければならないので、そのための制約条項が図２５のＩｎｔｅｇｒａｔｉｎｇ　Ｃｏｎｓｔｒａｉｎｔｓ　についての属性値とＳａｔｉｓｆｙｉｎｇ文によっての規定とを満足させる。
【０１４３】
この制約処理をコミュニケーション・マネージャに行わせる。したがって、コミュニケーション・マネージャは、
（１）テンプレート構造の役割に応じた変換を行う。（上記表１参照）
（２）テンプレート内容および複数個のテンプレート内容についての制約処理に関連した整合化のための通信管理作業を行う。
【０１４４】
この制約処理は形態制約である。それはＦｌｏｗ　ｌｉｎｅｓとＣｅｌｌ　ｐｉｃｔｕｒｅとの２個のサービス・オブジェクト相互に関連していることによる。このため、図２７のように制約処理の間での統合がはかられる。
【０１４５】
図２７において、
▲１▼　クライアント１は、ウインドウのデータを眺めながら、オブジェクト・ネットワークによって要求を発する。
▲２▼　エイジェント・ロール・サーバ３′は、サービス計画用のデータを用意し、スペシフィック・ロール・サーバ３″に対して、即ち所望する処理を行うための各　Ｆｌｏｗ　ｌｉｎｅ　処理用のサーバや　Ｃｅｌｌ　ｐｉｃｔｕｒｅ　処理用のサーバや　Ｔｅｘｔｕｒｅ　ｐｉｃｔｕｒｅ　処理用のサーバに対して、要求を発しおよび／または処理の継承を指示する。
▲３▼　　スペシフィック・ロール・サーバ３″における各サーバは、夫々自己の処理を行い、処理結果にもとづいた反応を返しおよび／または処理を合成して、エイジェント・ロール・サーバ３′へ応答する。
▲４▼　エイジェント・ロール・サーバ３′は、サービス内容をチェックし、制約条件があるか否かや現在の制約条件に追加や変更があるかなどを、クライアント１に尋ねるように処理する。
【０１４６】
このように図２７に示す如く、スペシフィック・ロール・サーバ３′中の各サーバが処理した結果あるいは所定の制約条件の下で処理した結果について、改めて、各処理結果の間で生じうる制約条件を新たに考慮してゆくようにする。即ち、制約処理の間での統合がはかられる。
【０１４７】
図２７に示すプロセスによって図２５で述べたＡｇｅｎｔ　ｒｏｌｅとＳｐｅｃｉｆｉｃ　ｒｏｌｅ　との差異が示されている。Ｆｌｏｗ　ｌｉｎｅ　とＣｅｌｌ　ｐｉｃｔｕｒｅとについてもＦｌｏｗとＣｅｌｌとの修飾に関連した制約処理はａｇｅｎｔ　ｒｏｌｅの働きと考え、要素ネットワークに対応する処理はｓｐｅｃｉｆｉｃ　ｒｏｌｅ　の働きによって行われる。
【０１４８】
また画像処理と画像描画とを相互作用のある形で、コモン・プラットフォームを用いて対話的情報処理を行うことができる。例えば、エッジ線やハイライト線のような特徴抽出を行う画像処理を行い、抽出されたハイライト線を移動させる。すなわち、左目から見た左画像が与えられた時に視点を右目の位置に移動させて右画像を求めるようにして、立体画像を得たり、あるいは顔の目尻を上下させて表情変化をさせる時に目尻の位置を検出するような画像処理によって表情の特徴を得たりすることができる。
【０１４９】
しかし、これら特徴検出については、サーバがいつも完全な実行処理できるとは限らない。そこで明確な特徴を検出しうる箇所をクライアントが選び、そこである性質としての特徴名としての制約を示して特徴を表現する点の候補を求め、次いでその中から特徴点を確定するようにする。この操作は例えば図８の要素ネットワークにおいて、クライアント側の動作を時系列的にＣ１，Ｃ２・・・として示し、システム側の処理を時系列的にＳ１，Ｓ２・・・として示すと次の如く処理が進行される。即ち、
（Ｃ１−１）Ｃｏｌｏｒｅｄ　Ｒｅｇｉｏｎ　Ｓｅｇｍｅｎｔの項目名を指定し、データ・ウインドウ上で抽出したい特徴の明らかな、
（Ｃ１−２）Ｒｅｇｉｏｎ　ＳｅｇｍｅｎｔをＩｄｅｎｔｉｆｙする。
（Ｃ１−３）ついで、Ｆｅａｔｕｒｅｄをキーボードから入力し、Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔ　の項目を指定することにより、Ｆｅａｔｕｒｅｄ　Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔを求めたことを、クライアントの意図として、システムに要求する。
（Ｓ１）システムはメッセージ・ウインドウによって意図を確認してＳｅｅｋ　ｆｅａｔｕｒｅｄ　Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔ　を表示し、ＩｄｅｎｔｉｆｙされたＣｏｌｏｒｅｄ　Ｒｅｇｉｏｎ　Ｓｅｇｍｅｎｔを表示する。
（Ｃ２）Ｆｅａｔｕｒｅｄの制約としてＨｉｇｈｌｉｇｈｔ　をキーボードから入力する。Ｈｉｇｈｌｉｇｈｔ　の性質はシステムに既に与えてあるとする。
（Ｓ２）Ｆｅａｔｕｒｅｄ（Ｈｉｇｈｌｉｇｈｔ）　Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔ　を抽出する。
（Ｃ３〜Ｓ３）Ｆｅａｔｕｒｅｄ（Ｈｉｇｈｌｉｇｈｔ）　の単語をコピーし、Ｃｏｌｏｒｅｄ　Ｌｉｎｅ　ＳｅｇｍｅｎｔをＩｄｅｎｔｉｆｙする。これにより、システムは、クライアントがＦｅａｔｕｒｅｄ　Ｃｏｌｏｒｅｄ　Ｐｏｉｎｔ　Ｓｅｑｕｅｎｃｅ　を経てＦｅａｔｕｒｅｄ　Ｃｏｌｏｒｅｄ　Ｌｉｎｅ　Ｓｅｇｍｅｎｔ　を作るべきことを、サービスとして実行する。
【０１５０】
以上によって、Ｈｉｇｈｌｉｇｈｔ　線を構成し、クライアントはその確認を行った後、それを移動した上で新Ｈｉｇｈｌｉｇｈｔ　線およびエッジ線を左右の眼の視差に対応して移動する。この際、Ｃｏｌｏｒｅｄ　属性を継承し、その上でＨｉｇｈｌｉｇｈｔ　線の特徴を維持するように描画サービスをシステムが行う。このＨｉｇｈｌｉｇｈｔ　線の移動差をｍｏｖｅｄ　ｈｉｇｈｌｉｇｈｔ　線として修飾を行い、ｍｏｖｉｎｇ　ｖｅｃｔｏｒ　ｄｉａｇｒａｍ　を用いて時間的な移動を行うようにする。
【０１５１】
またこれらの修飾を行うのに当たって、ｃｏｌｏｒｅｄ．．．．　によって輝度や色度の属性用テンプレートを付加したのと同様に追加テンプレート部分が付加される。これらは名詞オブジェクトに対するものであったが、動詞オブジェクトについてもｐｏｉｎｔ　からｌｉｎｅ　ｓｅｇｍｅｎｔに至るｄｒａｗが継承される。したがって動詞オブジェクトについても実行開始時、実行中、実行終了時の制約条件が付加される。
【０１５２】
また実行要求と制約との関係としては、サービスとしての実行要求を行いうる条件を規定することが必要で、
（１）属性値処理のために、エイジェント・ロール・サーバ３′からの継承性属性のみが要求により実行可能で、結果は合成属性として上位エイジェント・ロール・サーバ３′へ応答するようにされる。
（２）実行要求は、クライアントによってオブジェクト・ネットワーク上の動詞オブジェクトを指定し、もしくは上述のような実行の単位（ｐｏｉｎｔからｌｉｎｅへのｄｒａｗ）　によって実行系列を定めるようにして、委任発行される。
（３）ジェネリック・オブジェクト・ネットワーク上のジェネリックな動詞オブジェクトについても実行系列命令の生成を（２）と同様に行う。
【０１５３】
このために図６に関連して記述した時相的制約が満足されていることを制約処理によって調べる。
【０１５４】
実行結果をエイジェント・ロール・サーバ３′に応答すると、エイジェント・ロール・サーバ３′は制約処理のプロセスに入る。制約条件を満足していない時には、合成データを応答してきたスペシフィック・ロール・サーバへ継承属性を変更させて再実行に移らせる。それでも不満足な時には合成ルートをたどって（図２２、図２３の中継などによって）最終的にクライアントの判断を仰ぐパスが設定される。
【０１５５】
これまでの説明は、クライアントが一人であったが、複数のクライアントの協調化も行いうる。それはクライアントの上位階層として協調化を行う協調化エイジェントが存在すると考えることによって、コモン・プラットフォームを協調化して実行する場として使用可能である。
【０１５６】
グラフ構造化エディタは、オブジェクト・ネットワークの定義を読み取り、それを可視化可能なオブジェクト・ネットワークに表示すると共に、各オブジェクトのテンプレート構造および制約条件を各オブジェクトの属性として管理している。したがってエクステンシブル　ＷＥＬＬ　の機能によってエイジェント・ロール・サーバ，　スペシフィック・ロール・サーバのソフトウェアが記述される。そしてオブジェクト・ネットワークとテンプレートの構造とは、システム設計の最初の段階で、開発担当のその分野を担当するエキスパートによって記述が行われる。
【０１５７】
サービス・モジュールが、できるだけ基本的なソフトウェア・モジュールとそれに対応する専門分野との組み合わせという考え方で、開発し用意される。
【０１５８】
並行処理のためには、オブジェクト・ネットワークの構造を図２８のように、ＴＯＰ　を目的ゴール、ＢＯＴＴＯＭを出発点として表現する。当該ＢＯＴＴＯＭは上述の図８のＮＯＮＥの如きものと考えてよい。
【０１５９】
図２８においては、現在実行中のタスクが今ＣとＥとであるとすると次に並行実行可能なタスクがＡとＤとであり、ＡとＤとの並行実行が終了した時には次にＡとＢとに移ることを可能とすることが示されている。このように、オブジェクト・ネットワークの構造を解析して、並行実行の進行と共に複数個のサーバの並行実行を動的に制御させるようにする。
【０１６０】
図４において、クライアント１とエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との関係を示し、クライアント１とエイジェントとの間に表示的プロセス２−１としてのコモン・プラットフォーム２が存在し、かつエイジェントと各サーバ＃ｉとの間に従属表示的プロセス２−２としてのコモン・プラットフォーム２が存在する態様を示した。
【０１６１】
図４においてクライアント１の存在を示しているが、当該クライアント１として、エイジェント・ロール・サーバ３′に対して処理を希望するユーザを考慮することは言うまでもないが、当該ユーザとエイジェント・ロール・サーバ３′との間の情報交換を援助するエキスパートを更に考慮することができる。
【０１６２】
図２９はエキスパートの存在を考慮したシステム構成を示す。図中の符号１，２−１，２−２，３′，３″は夫々図１や図４に対応している。そして、符号１−１は図１や図４に示すクライアントに相当するユーザ、１−２はエイジェント・エキスパートであってユーザ１−１とエイジェント・ロール・サーバ３′との間の情報交換を援助するもの、１−３はスペシフィック・エキスパートであってエイジェント・ロール・サーバ３′とスペシフィック・ロール・サーバ３″との間の情報交換を援助するものを表している。
【０１６３】
図示のユーザ１−１は人間であるが、エイジェント・エキスパート１−２やスペシフィック・エキスパート１−３は夫々人間に限られるものではなくインテリジェント機能をもつ処理ユニットであってもよい。
【０１６４】
図２９に示すように、エイジェントに対してユーザ１−１としてのクライアントは、ある局所的な特定の問題解決（ｐｒｏｂｌｅｍ　ｒｅｓｏｌｕｔｉｏｎ）を依頼する。すなわち、ある問題についてエイジェントの支援をたのみ満足する解を得る。
【０１６５】
これに対し、専門家としてのエイジェント・エキスパート１−２はエイジェントが担当する問題解決を行うための各種サービスの仲介実行を行う仕事を担当する。すなわち、ジェネリック・オブジェクト・ネットワークを構成し、それをエイジェント・ロール・サーバ３′に対して実際に実行するオブジェクト・ネットワーク群に分解し、図２２，図２３のような実行を可能とする方法を設計する。
【０１６６】
この際、ジェネリック・オブジェクト・ネットワークとそのためのテンプレート（これにはデータのみでなくサービスモジュール名を含む）と制約条項とをもっている。図２２，図２３に示したエイジェントの中継機能は、エイジェント・ロール・サーバ３′のもつウエル・システム１１の中核部に備えられている。制約条項の処理は、一般的形式で記述されている部分については制約処理サーバに依頼する。
【０１６７】
ジェネリック・オブジェクト・ネットワークとそれに関連するテンプレートをエイジェント・ロール・サーバ３′のウエル・システム１１の言語処理部に記憶し、それを抽象化サービスとして実現させるためには、ウエル・システム１１のグラフ構造化エディタの機能を用いてエイジェント・エキスパート１−２が行う。
【０１６８】
同様に，個々のスペシフィック・ロール・サーバ３″にも，対応するスペシフィック・エキスパート１−３が存在し、この場合のユーザに該当するエイジェントが分配したある特定のサービスを実現するための実際に実行するオブジェクト・ネットワークとそれに関連したテンプレートを設計し、それぞれのウエル・システム１１の言語処理に格納する。
【０１６９】
以上のようなジェネリック・オブジェクト・ネットワークおよび実際に実行するオブジェクト・ネットワークはウエル・システム１１の拡張機能を利用して動的変更を行うことが可能である。
【０１７０】
同様のことが制約条項についても行われる。すなわち制約条項をその時点での入力データと見なし、制約条項を拡張し、設計を行うような制約処理用オブジェクト・ネットワークをジェネリック・オブジェクト・ネットワークと実際に実行するオブジェクト・ネットワークとの両者を設計し、それによって制約条項変更サービスを行うようにシステムを動的に変化させる。これもそれぞれのエキスパートが計画し、方法を実現させる。
【０１７１】
以上のことは、表１に示したサービス機能の計画設計に関しており、エキスパートの役割となり、エキスパートは、ユーザ１−１とサーバとの間の問題解決手段を提供し、その評価によって動的設計を行う。
【０１７２】
データに関連する部分については、ユーザのもつ得意機能とサーバのもつ得意機能に対応して、それぞれデータを理解し参照指示する機能にもとづいて記述内容のもつ役割を分化させ、全体システムを効率化するようにさせている。
【０１７３】
上述の如く、ユーザ１−１は或る目的意図の下でシステムを使用して成果を得る役目を果たすものであり、これに対してエキスパート１−２（又は１−３）はシステムを計画し設計し実現させてユーザ１−１の使用のために提供する。当該エキスパート１−２（又は１−３）も，エイジェント・ロール・サーバ３′やスペシフィック・ロール・サーバ３″との間でのインタラクションを行う場としてコモン・プラットフォーム２が用いられる。
【０１７４】
ユーザ１−１は可視型のオブジェクト・ネットワークを用いデータを入力するなどして操作を行う。オブジェクト・ネットワークは、オブジェクトとして名詞型オブジェクトや動詞型オブジェクトを用いる。他動詞型のオブジェクトでは目的語データや補語データについても可視型として表現され操作される。名詞や動詞についての修飾語ではテキスト形式の文や語を用いることが許される。上記のウエル・システム１１（図５参照）はこの考え方にもとづいて実現されていると考えてよい。
【０１７５】
エキスパート１−２（又は１−３）は、ユーザ１−１が利用できるように、ウエル・システム１１の機能を用いてオブジェクト・ネットワークを設定し、名詞オブジェクトについてはデータ構造としてのテンプレートを用意するようにし、動詞オブジェクトについても同様にサービス名や制約処理のためのテンプレートを用意するようにする。またオブジェクト間に制約条項が存在する場合には、テンプレート内に制約条項へのポインタが設定される。このためにグラフ構造エディタが上記ウエル・システム１１における言語処理系に設けられてオブジェクト・ネットワークの変更や拡張が動的に行われる。この動的な処理は、ユーザ１−１の意図を実現する上での、キーワードにもとづいたデータベースに対する事項検索によって行われる。あるいは、エイジェント・ロール・サーバ３′の助けをかりてユーザ１−１自身がオブジェクト・ネットワークの書き下しや訂正を行う。勿論並行処理の下で行うこともできる。これらのサービス計画は、エイジェント・エキスパートによって設計され、ジェネリック・オブジェクト・ネットワークとしてコモン・プラットフォーム上に表示される。
【０１７６】
エイジェント・ロール・サーバ３′は、サービス計画として、ユーザ１−１の要求に対応したオブジェクト・ネットワークをユーザに提示し、その結果にもとづいてサービス役割の割当てを行い、個々のスペシフィック・ロール・サーバにサービス仕様を与えると共に、プロトコル仕様にもとづいて具体的に各割当てサービスを並行的に実行させる。
【０１７７】
【発明の効果】
以上説明した如く、本発明によれば、クライアントとサーバとの間に、可視的な表示をもってクライアントに通知しかつクライアントからの意図を受け取り、クライアント側への可視的表示を用いた情報授受とサーバ側へのデータスキーマに則したデータ構造での情報授受とを仲介し、クライアントはディスプレイのウインドウに表示された画像と対話を行いながら、所望するオブジェクト・ネットワーク例えばカラー画像生成・色付け処理分野に対する処理を実行することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施例構成図を示す。
【図２】処理フロー（Ｉ）を示す。
【図３】処理フロー（ＩＩ）を示す。
【図４】エイジェントをもつ構成を示す。
【図５】ウエル・システムとオブジェクト・ネットワークとの関係を説明する図である。
【図６】処理の整合を行う状況を概念的に示した図である。
【図７】コミュニケーション・マネージャの働きを示す図である。
【図８】要素ネットワークの関係を示す図である。
【図９】コモン・プラットフォームをもつシステムにおいてカラー画像生成・色付け処理を行う態様を示している。
【図１０】テンプレートのフォーマットを示す。
【図１１】コミュニケーション・マネージャの動作態様を示す。
【図１２】クライアントの指示に対応する動作を説明する図である。
【図１３】情報の交換動作を説明する図である。
【図１４】チェック・モジュールの動作を説明する図である。
【図１５】制約条件の表示態様を示す図である。
【図１６】アイデンティファイ作業を説明する図である。
【図１７】ＦＬＯＷ　ＬＩＮＥＳの描画態様を示す図である。
【図１８】うろこパターンの画像を表す図である。
【図１９】ライン用のテンプレートのフォーマットを表す図である。
【図２０】ＬＩＮＥＳを限定する形容詞節を表す図である。
【図２１】属性にＦｅａｔｕｒｅ　名を記述されたテンプレートを表す図である。
【図２２】テキスチャ描画の流れ（Ｉ）　を表す図である。
【図２３】テキスチャ描画の流れ（ＩＩ）を表す図である。
【図２４】オブジェクト・ネットワークに概念を説明する図である。
【図２５】サーバ３′とサーバ３″との処理例を表す図である。
【図２６】中心点を表示した図である。
【図２７】制約処理の統合を表す図である。
【図２８】並列処理を分析した図である。
【図２９】エキスパートの存在を表すシステムの図である。
【図３０】クライアント・サーバ間の対話モデルを表す図である。
【符号の説明】
１　クライアント
１−１　ユーザ
１−２　エイジェント・エキスパート
１−３　スペシフィック・エキスパート
２　コモン・プラットフォーム
３　サーバ
４　ウインドウ
５　ネットワーク・オペレーション・ウインドウ
６　オペレーション・ウインドウ
７　コマンド・ウインドウ
８　メッセージ・ウインドウ
９　データ・ウインドウ
１０　コミュニケーション・マネージャ
１１　ウエル・システム
１２　ウエル・カーネル
１３　グラフ構造エディタ
１４　ウインドウ・マネージャ
１５　ディスプレイ・マネージャ
１６　関数実行・マネージャ
１７　サービス・モジュール
１８　分野
１８Ｃ　カラー画像生成・色付け処理分野
１９　オブジェクト・ネットワーク
２０　輪郭部（Ｆｒａｍｅ　Ｓｅｃｔｉｏｎ）
２１　カラー部（Ｃｏｌｏｒ　Ｓｅｃｔｉｏｎ）
２２　テンプレート
２３　バッファ
２３’バッファの内容
２４　チェック・モジュール
２５　制約条件
２７　名詞オブジェクト
３３　ジェネリック・オブジェクト・ネットワーク
３４　特定のパラメータや制約条件
３５　スペシフィック・オブジェクト・ネットワーク
【図１】
2004054942.tif 000004
【図２】
2004054942.tif 000005
【図３】
2004054942.tif 000006
【図４】
2004054942.tif 000007
【図５】
2004054942.tif 000008
【図６】
2004054942.tif 000009
【図７】
2004054942.tif 000010
【図８】
2004054942.tif 000011
【図９】
2004054942.tif 000012
【図１０】
2004054942.tif 000013
【図１１】
2004054942.tif 000014
【図１２】
2004054942.tif 000015
【図１３】
2004054942.tif 000016
【図１４】
2004054942.tif 000017
【図１５】
2004054942.tif 000018
【図１６】
2004054942.tif 000019
【図１７】
2004054942.tif 000020
【図１８】
2004054942.tif 000021
【図１９】
2004054942.tif 000022
【図２０】
2004054942.tif 000023
【図２１】
2004054942.tif 000024
【図２２】
2004054942.tif 000025
【図２３】
2004054942.tif 000026
【図２４】
2004054942.tif 000027
【図２５】
2004054942.tif 000028
【図２６】
2004054942.tif 000029
【図２７】
2004054942.tif 000030
【図２８】
2004054942.tif 000031
【図２９】
2004054942.tif 000032
【図３０】
2004054942.tif 000033