JP2002163054A

JP2002163054A - ユーザ支援方法、装置およびシステム

Info

Publication number: JP2002163054A
Application number: JP2000362400A
Authority: JP
Inventors: Akihiro Yamada; 晃弘山田; Atsushi Maeda; 篤志前田; Tsugufumi Matsuoka; 継文松岡
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2000-11-29
Filing date: 2000-11-29
Publication date: 2002-06-07

Abstract

(57)【要約】【課題】各社各様のエージェントを利用すると、エー
ジェント間の通信ができなかった。【解決手段】第１ユニット８２は、複数エージェント
間の相互作用を実現するための場を提供し、かつ複数の
エージェントの実体的機能を実現する。第２ユニット８
４は、複数エージェント間の相互作用をキャラクタのレ
ベルで可視的に表現するための基本機能と基本動作を提
供する。複数エージェント間の横断的機能と、エージェ
ントごとの個別的機能とのインタフェイスが、いずれの
エージェントおよびいずれのキャラクタについても統一
されている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明はユーザ支援技術に
関し、とくにエージェントを用いてユーザを支援する方
法、装置およびシステムに関する。

【０００２】

【従来の技術】インターネットや携帯電話の普及によっ
て、非常に多くの人がコンピュータや各種情報端末に触
れるようになった。ここ数年、パーソナルコンピュー
タ、ＰＤＡをはじめとする機器の販売台数は大きく伸び
ており、いわゆる初心者が激増している。ＣＰＵパワー
やメモリ容量の飛躍的な向上により、そうしたユーザで
も比較的容易に機器操作ができるためのＧＵＩ（グラフ
ィカル・ユーザ・インタフェイス）も整備されつつあ
る。初心者にとって、機器のもつ高度な機能を使いこな
し、また、必要な情報へ正しくアクセスすることは、Ｇ
ＵＩその他の助けがなければ相当困難である。

【０００３】そうしたユーザ支援技術のひとつに、エー
ジェントの利用が知られている。エージェントは、おも
に擬人化されたキャラクタを用い、ユーザの要求を実現
すべくユーザと相互作用する。キャラクタは、コンピュ
ータ画面に登場し、ユーザの発話を取得する。その発話
は、そのキャラクタを利用するエージェントの実体的な
機能によって解釈され、必要な処理がなされる。すなわ
ち、キャラクタを媒介とするエージェントの存在によ
り、ユーザはコンピュータという機械を相手にする堅苦
しさから解放され、コンピュータをより身近な存在とし
て感じることができる。

【０００４】

【発明が解決しようとする課題】しかしながら、キャラ
クタを用いたエージェントの処理は、ユーザの発話内容
解釈の困難さや処理負荷の大きさなどが原因で、まだ完
全に満足のいく成功例はないといってもよい。この点に
鑑み、本出願人は先に特願２０００−３２３５６０にお
いて、ユーザの発話を全文検索によって特定する技術を
提案している。また、特願２０００−２７０８４５にお
いて、複数のキャラクタが登場して、いわば掛け合い漫
才的に対話をもつための技術を提案している。

【０００５】本発明はこうした一連の取組みの中で創作
されたものであり、その目的は、上述の特許出願に係る
発明とは別の技術的観点から複数のキャラクタの相互作
用を実現する技術を提供することにある。本発明の別の
目的は、本来全く異なるか、全く関係なく作成される複
数のキャラクタ間でもそうした相互作用の可能な技術の
提供にある。本発明のさらに別の目的は、そうしたエー
ジェント機能を効率的に開発することの可能な技術を提
供することにある。

【０００６】

【課題を解決するための手段】本発明のある態様は、ユ
ーザ支援装置に関する。この装置は、キャラクタを利用
してユーザを支援するエージェントを提供する装置であ
り、エージェントのレベルで制御を行う第１ユニット
と、キャラクタのレベルで制御を行う第２ユニットとを
含む。第１ユニットは、複数エージェント間の相互作用
を実現するための場を提供し、それらのエージェントを
総合的に管理する全体統括部と、それぞれがキャラクタ
を媒介としてユーザの要求を取得および解釈することに
より、エージェントの実体的機能を実現する複数のエー
ジェント制御部とを有する。第２ユニットは、前記複数
エージェント間の相互作用をキャラクタのレベルで可視
的に表現するための基本機能を提供するキャラクタ統括
部と、それぞれが前記複数のエージェント制御部のいず
れかに対応し、当該対応するエージェント制御部が利用
するキャラクタの一連の基本動作を提供する複数のキャ
ラクタ制御部とを有する。この構成でさらに、全体統括
部およびキャラクタ統括部によって提供される複数エー
ジェント間の横断的機能と、エージェント制御部および
キャラクタ制御部によって提供されるエージェントごと
の個別的機能とのインタフェイスが、複数のエージェン
ト制御部および複数のキャラクタ制御部について統一さ
れている。「エージェント」は、あるサービスをユーザ
のためになす機能であり、狭義には擬人化されたキャラ
クタによる活動をいう。ただし、本発明ではエージェン
トはキャラクタに限らず、その背後でなされる処理も含
めた概念である。したがって、以下単にエージェントと
いうとき、キャラクタも含むとする。「実体的機能」と
は、単にユーザから見える部分に限らず、その背後でな
される処理も含む機能をいい、例えばユーザが求める情
報の検索を含む。

【０００７】この装置では、全体統括部およびキャラク
タ統括部が複数エージェント間の横断的機能を有する。
したがって、明示的または暗黙的に、それらは複数キャ
ラクタ間の横断機能をも有する。一方、エージェント制
御部およびキャラクタ制御部はエージェントごとの個別
的機能を提供する。これら横断機能と個別的機能のイン
タフェイスが統一されているため、個別的機能の部分を
そのインタフェイスに準拠して追加していくことができ
る。その設計はインタフェイスに準拠する限り誰でもな
しうるため、エージェント機能の充実が容易になる。

【０００８】インタフェイスの統一によってキャラクタ
の入出力形式の相違を吸収することにより、キャラクタ
間の相互作用、たとえばそれらが同一の画面に現れてな
す会話が実現する。従来一般に、例えば異なる会社で開
発されたエージェント間では通信ができなかったが、こ
の装置のごとく、インタフェイスに準拠する形で実装す
れば、それが可能になる。そのため、従来にないタイプ
のエージェントシステムが提供できる。

【０００９】この装置は、クライアント・サーバシステ
ムのクライアント端末として構成され、少なくともエー
ジェント制御部の実体的機能がサーバとの通信を交えて
提供されてもよい。逆にこの装置は、そのサーバとして
構成されてもよい。

【００１０】前記の相互作用は少なくともキャラクタ間
の会話を含み、全体統括部は、その会話のために一方の
キャラクタから他方のキャラクタへの会話データを受け
渡してもよい。キャラクタ統括部は、複数のキャラクタ
間の位置関係を取得し、その位置関係を変えることによ
り相互作用が起こされてもよい。

【００１１】本発明の別の態様は、キャラクタを利用し
てユーザを支援するエージェントを提供するクライアン
ト・サーバによるシステムに関する。このシステムに
て、クライアントは、エージェントのレベルで制御を行
う第１ユニットと、前記キャラクタのレベルで制御を行
う第２ユニットとを含む。第１ユニットは、複数エージ
ェント間の相互作用を実現するためにそれらのエージェ
ントを総合的に管理する全体統括部と、それぞれがキャ
ラクタを媒介としてユーザの要求に応答する複数のエー
ジェント制御部とを有し、第２ユニットは、複数エージ
ェント間の相互作用をキャラクタのレベルで表現するキ
ャラクタ統括部と、それぞれが複数のエージェント制御
部のいずれかに対応し、当該対応するエージェント制御
部が利用するキャラクタの一連の基本動作を提供する複
数のキャラクタ制御部とを有する。一方、サーバは、前
記複数のエージェント制御部と連携し、ユーザの要求を
解釈してその応答に必要な情報を前記クライアントへ提
供する。

【００１２】サーバはさらにコントロールウィンドウ管
理部を含み、それが全体統括部およびキャラクタ統括部
の機能をクライアントへ提供してもよい。すなわち、こ
こでいうサーバは、クライアントにサービスを提供する
任意の構成要素の総称と考えることができる。サーバは
また、複数の専門サーバを含み、これらがそれぞれ自己
の専門分野に関するサービスをなすべく、エージェント
制御部およびキャラクタ制御部の機能を前記クライアン
トへ提供してもよい。

【００１３】本発明のさらに別の態様は、キャラクタを
利用してユーザを支援するエージェントを提供する方法
に関する。この方法は、エージェントのレベルで制御を
行う第１の処理過程と、キャラクタのレベルで制御を行
う第２の処理過程とを含む。第１の処理過程は、複数エ
ージェント間の相互作用を実現するために、それらのエ
ージェントを総合的に管理する全体統括過程と、それぞ
れがキャラクタを媒介としてユーザの要求に応答する複
数のエージェント制御過程とを有する。第２の処理過程
は、前記複数エージェント間の相互作用をキャラクタの
レベルで表現するキャラクタ統括過程と、それぞれが前
記複数のエージェント制御過程のいずれかに対応し、当
該対応するエージェント制御過程が利用するキャラクタ
の一連の基本動作を提供する複数のキャラクタ制御過程
とを有する。以上の過程の連鎖によって実現される複数
エージェント間の横断的機能とエージェントごとの個別
的機能とのインタフェイスが、複数のキャラクタについ
て統一されている。

【００１４】なお、以上の構成要素の任意の組合せ、本
発明の表現を方法、装置、システム、記録媒体、コンピ
ュータプログラムなどの間で変換したものもまた、本発
明の態様として有効である。

【００１５】

【発明の実施の形態】図１は、実施の形態に係るユーザ
支援システム１０の全体構成を示す。ここでは、ユーザ
端末１２、コントロールウィンドウ管理サイト１６、お
しゃべりサーバ１８、献立サーバ２０がインターネット
１４を介して接続されている。ユーザ端末１２はＰＣ
（パーソナルコンピュータ）、ＰＤＡ、インターネット
１４へ接続可能な携帯電話、その他任意のハードウエア
である。コントロールウィンドウ管理サイト１６、おし
ゃべりサーバ１８、献立サーバ２０が広義のサーバに当
たる。

【００１６】おしゃべりサーバ１８、献立サーバ２０は
それぞれの担当する専門分野に関するユーザの発話の解
釈とエージェントの行動を処理する。たとえば、おしゃ
べりサーバ１８は「こんにちは」などの一般的なあいさ
つに関する発話を処理し、献立サーバ２０は、「レシピ
をおしえて」などの献立に関する発話を処理する。これ
により、処理を分散させることができ、また、エージェ
ント単位のメンテナンスが容易になる。おしゃべりサー
バ１８、献立サーバ２０という名称もその担当分野また
は専門分野に応じて与えられている。

【００１７】おしゃべりサーバ１８、献立サーバ２０等
を総括的に「専門サーバ」とよび、専門サーバにおかれ
たエージェントを「専門エージェント」とよぶ。例えば
おしゃべりサーバ１８におかれたエージェントは「おし
ゃべりエージェント」とよび、他の専門サーバでも同様
とする。なお、コントロールウィンドウ管理サイト１
６、おしゃべりサーバ１８、献立サーバ２０はネットワ
ーク上、別ノードとしてもよいが、例えばコントロール
ウィンドウ管理サイト１６をおしゃべりサーバ１８へ編
入し、おしゃべりサーバ１８をユーザ端末１２とのやり
とりの起点として設計してもよい。以下、そうした例を
扱う。

【００１８】詳細は後述するが、図１における処理の概
要は以下のとおりである。すなわち、ユーザ端末１２は
最初にコントロールウィンドウ管理サイト１６へ接続す
る。コントロールウィンドウ管理サイト１６は複数のエ
ージェントを統括的に管理する全体統括機能と、同様に
複数のキャラクタを統括的に管理するキャラクタ統括機
能を有している。これらを総称して「横断機能」とい
う。横断機能は実施の形態の特徴のひとつであり、複数
のまったく異なるエージェント間で対話等の相互作用な
す際、いわゆるブリッジとして働く。コントロールウィ
ンドウ管理サイト１６は横断機能を実現するプログラム
を適宜ユーザ端末１２へ送信し、以降、ユーザ端末１２
はオフラインでも横断機能を有する。

【００１９】つづいて、ユーザ端末１２は特定のサービ
スを受けるべく、おしゃべりサーバ１８へ接続する。お
しゃべりサーバ１８はおしゃべりに特化したエージェン
ト制御機能と、同様にそのためのキャラクタ制御機能を
有する。これらを総称して「個別的機能」という。個別
的機能は専門サーバごとに設計され、献立サーバ２０も
献立に関する個別的機能をもつ。以下、たとえば旅行エ
ージェント、ＰＣエージェント、占いエージェントな
ど、ユーザが興味をもちうる分野ごとに専門サーバを設
けてもよい。

【００２０】ユーザはまず、おしゃべりエージェントに
対して発話し、なんらかのサービスを求める。おしゃべ
りエージェントはその発話を取得し、解釈する。発話が
献立に関するものであれば、おしゃべりエージェントは
前記の全体統括機能を呼び出し、献立エージェントを登
場せしめる。このとき、全体統括機能はユーザ端末１２
の画面をふたつのフレームに分割し、おしゃべりエージ
ェントと献立エージェントをそれらにそれぞれ収容す
る。おしゃべりエージェントと献立エージェントは、あ
いさつを交わしたり、その他対話をもつ。そのために、
各エージェントの機能は横断機能を呼び出して利用す
る。横断機能と個別的機能とのインタフェイスは決めら
れており、各エージェント設計者がこれに従う限り、エ
ージェント単体では不可能な、他のエージェントへの語
りかけなどを実現することができる。逆に、他のエージ
ェントに応答したり、全体統括機能からの要求に応じた
行動をとるために、インタフェイスに応じた機能を予め
実装しておく必要がある。なお、エージェントを収容す
るフレームの代わりにウィンドウを生成してもよく、以
下、いずれかを説明したら他方も同様なので煩を避け並
記しない。

【００２１】いままで述べた各種機能は、実際にはプロ
グラム中の関数という形で実現される。したがって、ユ
ーザ支援システム１０全体の主導的な開発者（以下「一
次開発者」という）は、全体の枠組みとしてコントロー
ルウィンドウ管理サイト１６に横断機能を実装してお
き、その内容を公表する。各専門エージェントの設計者
（以下「二次開発者」という）は、利用可能な横断機
能、すなわち各関数の内容と利用形式を知る。一方、横
断機能側から各エージェントに指令を出すために、一次
開発者は各エージェント側で個別的機能を実現する関数
の内容を決め、この実装を二次開発者に義務づける。以
上の関数に関する仕様を総称してインタフェイスとよ
ぶ。

【００２２】図２はコントロールウィンドウ管理サイト
１６の内部構成である。コントロールウィンドウ管理サ
イト１６は、全体統括部２２、キャラクタ統括部２４、
ユーザダイアログ処理部２６を有し、これらが通信部２
８、インターネット１４を介してユーザ端末１２と通信
する。全体統括部２２は、エージェントレベルにおける
横断機能を実現する。同様にキャラクタ統括部２４はキ
ャラクタレベルにおける横断機能を実現する。ユーザダ
イアログ処理部２６は、ユーザ端末１２の画面にユーザ
入力プロンプトを表示し、ユーザの入力文字列等を取得
する。実際には後述のごとくこれら一連の機能はユーザ
端末１２にダウンロードされ、ユーザ端末１２の側で作
動してもよい。

【００２３】全体統括部２２は、複数エージェント間の
相互作用を実現するための場を提供し、それらのエージ
ェントを総合的に管理する。その実体はこの実施の形態
ではＨＴＭＬファイルとし、スクリプト言語等で記述さ
れた関数の例は以下のとおりである。ＡｄｄＡｇｅｎｔ（）：新たなキャラクタを場におくＢｃａｓｔ（）：表示されている全キャラクタに情報
を伝達するＴｅｌｌ（）：あるひとりのエージェントに情報を伝
達するＲｅｑＵＩ（）：おしゃべりエージェントにユーザ情
報の取得ユニット依頼するＲｅｑＰｒ（）：ユーザ入力プロンプトの表示を要求
するこれらの関数には、それぞれ対象となる情報、エージェ
ントなどを引数として記述する。これらの関数は、標準
で準備されているものであり、二次開発者が各エージェ
ントを設計する際に利用が可能である。全体統括部２２
は、これらの他にクッキー処理を行う。

【００２４】キャラクタ統括部２４は、複数エージェン
ト間の相互作用をキャラクタのレベルで可視的に表現す
るための基本機能を提供する。これもＨＴＭＬファイル
であり、関数はスクリプト言語等で記述される。関数の
例は以下のとおりである。ＷａｌｋＣｌｏｓｅ（）：指定したキャラクタのそば
に移動するＰｏｉｎｔＷｉｎ（）：指定したウィンドウを指し示
すＴａｌｋ（）：指定したキャラクタのほうを見て話すこれらの関数も標準で準備されている。これらの関数を
実現するために、キャラクタ統括部２４には全キャラク
タの位置把握機能を実装しておく。

【００２５】図３はおしゃべりサーバ１８の内部構成を
示す。同図中、「Ｈ」は発話データ、「Ｉ」は発話のイ
ンデックス検索、「Ｆ」は特定されたユーザ発話に応答
すべき専門サーバのページのＵＲＬを保持するファイル
の名称、「Ｘ」は特定できなかった発話（以下、不明発
話ともいう）をそれぞれ示す。図３の構成は、ハードウ
エア的には、任意のコンピュータのＣＰＵ、メモリ、そ
の他のＬＳＩで実現でき、ソフトウエア的にはメモリの
ロードされたプログラムなどによって実現されるが、こ
こではそれらの連携によって実現される機能ブロックを
描いている。したがって、これらの機能ブロックがハー
ドウエアのみ、ソフトウエアのみ、またはそれらの組合
せによっていろいろな形で実現できることは、当業者に
は理解されるところである。以下、同様の配慮は本明細
書全体にわたって有効とする。

【００２６】エージェント制御部６６は、キャラクタを
媒介としてユーザの要求を取得および解釈することによ
り、エージェントの実体的機能を実現する。キャラクタ
制御部６８はエージェント制御部６６が利用するキャラ
クタの一連の基本動作を提供する。エージェント制御部
６６およびキャラクタ制御部６８の組が各専門サーバに
最低ひとつずつ存在し、専門分野のサービスをなす。通
信部３０はインターネット１４を介して主にエージェン
ト制御部６６およびキャラクタ制御部６８とユーザ端末
１２とのやりとりをする。

【００２７】エージェント制御部６６は、おしゃべりに
関するユーザまたは他のエージェントの発話（以下単に
「対象発話」ともいう）に応答する一連の機能を含む。
主制御部６０は発話取得部３２およびキャラクタ制御部
６８を中心に一連の処理を制御する。主制御部６０の処
理概要は、対象発話があるたびに、それに応答するため
のページを特定し、処理をそのページへ移す点にある。
発話取得部３２はユーザ端末１２からの対象発話を取得
し、これを発話検索部３４へ送る。発話検索部３４はそ
の発話の第一文字をインデックスファイル３６へ照合
し、まずインデックスによる絞り込みをかけ、その後、
対象発話を特定する。この際、対象発話全体についてフ
レーズ検索をかける。フレーズ検索とは、単語の順番ま
で含めて一致するものを見いだす処理である。フレーズ
検索で該当するものが見つからないときは、後述のよう
に、対象発話を形態素に分け、キーワードまたは単語に
よって近いものを検索する。

【００２８】インデックスファイル３６は、想定発話集
３８に格納された対象発話を特定するための想定発話を
５０音順に並べて生成され、前記の第一文字をこのイン
デックスファイル３６に照合することにより、たとえ想
定発話集３８が膨大であっても、非常に高速にそれらの
発話を検索することができる。後述するごとく、この実
施の形態では想定発話集３８の充実化が容易であるた
め、短期間で想定発話集３８の容量が非常に大きくなる
ことが予想され、インデックス検索による高速化のメリ
ットは大きい。

【００２９】インデックスファイル３６で対象発話が特
定されると、それに応答すべき専門サーバのＵＲＬ等の
情報が記述されたファイルがインデックスファイル３６
内で特定され、想定発話集３８に内蔵されたそのファイ
ル本体がオープンされ、前記ＵＲＬが判明する。想定発
話集３８には、ひとつの対象発話に対してひとつのファ
イルが形成されている。

【００３０】判明したＵＲＬが自サーバのものであった
場合、主制御部６０にそのＵＲＬが伝達される。主制御
部６０は、通信部３０を経てユーザ端末１２のブラウザ
にそのＵＲＬを設定する。

【００３１】判明したＵＲＬが他の専門サーバのもので
あった場合は、通信部３０を経てユーザ端末１２のブラ
ウザにそのＵＲＬが設定され、ユーザ端末１２のアクセ
ス先がその専門サーバになる。厳密には、そのＵＲＬは
専門サーバのホームページを指しているのではなく、対
象発話に応答するための個別のページを指しており、ひ
とつの発話に対してひとつ、または場合により複数のペ
ージが割り当てられている。複数の場合は後述する。

【００３２】対象発話と完全に一致するものが想定発話
集３８に格納されているときは問題がないが、とくに想
定発話集３８の充実化の過程では、そうならないことも
多い。その場合、発話検索部３４は既知の方法で対象発
話を形態素に分解し、それらのうち名詞の論理積をとっ
て再検索をかけるなどの処理により、最も確からしい発
話を想定発話集３８から見いだす。再検索の対象となっ
た発話、および、そうした再検索を通しても判明しなか
った発話は、ともに不明発話として不明発話ファイル４
０に記録され、これが通知部４２を通じてシステム管理
者へ電子メール等により通報される。

【００３３】システム管理者は、その発話に応答すべき
専門サーバの管理者に対して、その発話の内容を通知
し、専門エージェントによる応答処理の開発を依頼す
る。専門サーバの管理者は、その発話およびそれに応答
すべき専門サーバのページのＵＲＬを、自サーバの想定
発話集３８へ新規登録し、その発話のインデックスをイ
ンデックスファイル３６へ登録し、かつそのページにお
ける専門エージェントの発話を含む処理を設計する。こ
のメンテナンスによれば、適切に不明発話を想定発話集
３８に追加していくことができるため、想定発話集３８
の充実は非常に容易である。

【００３４】主制御部６０はさらに、個人情報ファイル
４８を管理している。個人情報ファイル４８は数ある専
門サーバの中で、おしゃべりサーバ１８のみが管理して
もよい。おしゃべりサーバ１８はつねにユーザと最初の
会話をもち、ユーザからその個人情報を聞き出すのにふ
さわしい存在だからである。例えば、主制御部６０の中
に、定期的にユーザに情報、たとえばユーザの年齢、性
別、職業といった属性情報や、食事の好みなどを聞き出
す関数を実装しておき、ユーザが答えるたびにそれを個
人情報ファイル４８へ記録してもよい。他のエージェン
トからは、前述のＲｅｑＵＩ（）関数を利用して個人情
報の取得を依頼することができる。この情報はいろいろ
な専門サーバでユーザに対するサービスをなすときに利
用されたり、実施の形態に特徴的なごとく、他のエージ
ェントがユーザにサービスする際、おしゃべりエージェ
ントがユーザの代役としてそのエージェントに指示を出
すといった処理が実現する。その際、エージェント間の
相互作用が発生する。

【００３５】主制御部６０にはこのほかに、以下の関数
などを実装しておく。Ｒｅｓｐｏｎｄ（）：キャラクタがクリックされたと
きによばれ、その際、なすべき処理を記述するＬｉｓｔｅｎ（）：他のエージェントから情報が伝達
されたときこれを取得するこれらの関数の実装はおしゃべりサーバ１８を設計する
二次開発者に課されるもので、これらの関数は全体統括
部２２、キャラクタ統括部２４などから呼ばれることが
ある。

【００３６】キャラクタ制御部６８は、対象発話ごとに
なすべきキャラクタの行動を記述する行動ファイル６２
と、キャラクタの画像データ、音声データなどを格納す
るキャラクタデータ６４を含む。キャラクタデータ６４
は最初にユーザ端末１２にダウンロードされれば、以降
ユーザ端末１２と通信する必要はない。

【００３７】キャラクタ制御部６８には例えば以下の関
数を実装しておく。ＣｏｍｅＯｕｔ（）：キャラクタを登場させるＡｃｔ（）：指定の動作を再生させるＳｐｋ（）：指定したテキストを吹き出しに表示し、
音声でも出力するＧｏＯｕｔ（）：画面から退場するＨａｌｔ（）：キャラクタの全動作を停止させる以上の関数により、キャラクタの基本動作を実現するこ
とができる。これらの関数も二次開発者に実装が義務づ
けられるもので全体統括部２２、キャラクタ統括部２４
などから呼ばれることがある。

【００３８】アクセス記録部４４は、専門サーバに対す
るアクセスの状況をユーザごとにアクセス情報ファイル
４６へ記録する。これにより、同じユーザ発話に対して
異なる応答をすることが可能になる。例えば、おしゃべ
りサーバ１８を初めて訪問したユーザが「こんにちは」
といったとき、おしゃべりエージェントは「はじめまし
て」という。一方、そのユーザによるおしゃべりサーバ
１８への再訪に際し、おしゃべりエージェントは「こん
にちは。あれからどうですか。」などということがで
き、きめの細かい対応が実現する。アクセス記録部４４
はアクセスの状況を発話検索部３４へ伝える。発話検索
部３４は対象発話に対応するための専門サーバのページ
が、いまの例のように想定発話集３８において複数記述
されているとき、その中からアクセスの状況をもとにふ
さわしいものを選択し、そのＵＲＬをユーザ端末１２の
ブラウザへ設定する。

【００３９】図４はインデックスファイル３６の内部構
成、図５は想定発話集３８の内部構成をそれぞれ示す。
インデックスファイル３６は５０音欄１００、対象発話
欄１０２、ファイル名欄１０４を有する。対象発話は５
０音順に整列され、第１文字が「あ」であれば、５０音
欄１００の「あ」の下に分類され、以下同様に第１文字
をもとに分類されている。

【００４０】想定発話集３８はファイル名欄１０４、対
象発話欄１０２、応答すべき専門サーバのページ欄１２
０を有する。例えば、ユーザ発話「やあ」に応答する専
門サーバのページは「ＵＲＬａ４３」であり、「やあ」
という発話と「ＵＲＬａ４３」の組がファイルｆ０４４
を構成する。対象発話は専門サーバごとにまとめられ、
例えばおしゃべりサーバ１８が担当すべきユーザ発話１
１０と、献立サーバ２０が担当すべきユーザ発話１１２
とがそれぞれひとまとまりで記述されている。インデッ
クスファイル３６と想定発話集３８はファイル名によっ
てリンクされ、例えば「こんにちは」という発話には、
インデックスファイル３６においてファイルｆ０４５が
記述され、これが想定発話集３８のファイルｆ０４５を
指している。

【００４１】図５のごとく、「こんにちは」に対する応
答のページはＵＲＬａ１とＵＲＬａ２のふたつがある。
ここでは、おしゃべりサーバ１８にはじめて来たユーザ
にはＵＲＬａ１、再訪の場合はＵＲＬａ２がそれぞれ送
信されるとする。

【００４２】図６はアクセス情報ファイル４６の内部記
述例である。同図では、あるユーザ「ｕｓｅｒ１」は過
去に「おしゃべり」「献立」「オークション」という専
門サーバを訪れている。一方、ユーザ「ｕｓｅｒ２」は
「旅行」「ＰＣ」という専門サーバを訪れている。した
がって、ｕｓｅｒ２がおしゃべりサーバ１８を訪れる
と、前述のごとく、おしゃべりエージェントから初回訪
問者用の発話がなされ、ｕｓｅｒ１がおしゃべりサーバ
１８を訪れると再訪者向けの挨拶が発話される。

【００４３】図７は行動ファイル６２の内部構成を示
す。発話検索部３４によって特定されたＵＲＬ、すなわ
ち図５のごとくユーザ発話が「こんにちは」の場合にお
けるＵＲＬａ１またはＵＲＬａ２は、主制御部６０を経
て行動ファイル６２に与えられる。行動ファイル６２に
は、発話検索部３４によって特定されたＵＲＬと一対一
でページが設けられ、具体的には、ＵＲＬａ１のページ
７０、ＵＲＬａ２のページ７２、ＵＲＬａｎのページ７
４のように、多数のページがバンドルされている。ペー
ジはそれぞれいわゆるＷｅｂページであり、対象発話ひ
とつに対してＷｅｂページをひとつ設け、対応の柔軟性
と充実を図っている。

【００４４】以下、行動ファイル６２に含まれるページ
のイメージを示す。このページは「ＡＣ．ｈｔｍｌ」と
いうファイルであり、あるＯＳにおいて標準的に提供さ
れているキャラクタを「ＡＣｈａｒａ」の名でロードし
て表示する機能をもつ。したがって、外部から関数Ｓｐ
ｋが呼ばれたら、そのキャラクタがしゃべる。 <html> <head> <title>テスト</title> <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> </head> <body bgcolor="#FFFFFF">  <OBJECT ID="AgentControl" CLASSID="xxx" CODEBASE="#VERSION=2,0,0,0"> </OBJECT> <SCRIPT language=Javascript> var AChara; Agent.Characters.Load("AChara","C:\\XXX\\Xagent\\CHARS\\AChara.acs"); AChara = Agent.Characters.Character("AChara"); AChara.ComeOut(); </SCRIPT> <SCRIPT language=Javascript SRC="AC.js"></SCRIPT> </body> </html>

【００４５】このファイルで利用されるスクリプトファ
イルは以下のとおりであり、この関数によってキャラク
タがしゃべる。いままで述べた関数とは、ＨＴＭＬファ
イルとスクリプトで記述される関数の総称である。ここで、ＡＣ．ｈｔｍｌの表示されているフレームの名
称をａＦｒａｍｅとすると、フレームの外からＡＣｈａ
ｒａをしゃべらせるには、aFrame.Spk("じゃあね");な
どと記述すればよい。

【００４６】図８は、ユーザ端末１２の内部構成を示
す。ユーザ端末１２の各機能は、コントロールウィンド
ウ管理サイト１６、おしゃべりサーバ１８、献立サーバ
２０その他の専門サーバからすべて与えられてもよい
し、一部を予めローカルでもっていてもよいし、コント
ロールウィンドウ管理サイト１６等に接続された初回に
限りダウンロードし、以降ローカルに保持してもよい。
つまり、ユーザ端末１２とコントロールウィンドウ管理
サイト１６その他のサーバでユーザ支援システム１０を
構築するとき、処理機能はクライアントおよびサーバの
いずれの場所にあってもよく、一般則としては、更新頻
度が低いか、まったく更新の必要がないものは予めクラ
イアントに実装しておいてもよい。以下、各機能が当初
どこに存在したかは問わない。

【００４７】通信部１１４はインターネット１４を介し
てコントロールウィンドウ管理サイト１６等と通信す
る。コントロールウィンドウ８０は第１ユニット８２、
第２ユニット８４、ユーザダイアログ処理部８６を有す
る。第１ユニット８２は全体統括部９０を有し、全体統
括部９０はおしゃべりエージェント制御部９２、献立エ
ージェント制御部９４を統括する。全体統括部９０はコ
ントロールウィンドウ管理サイト１６の全体統括部２２
に、おしゃべりエージェント制御部９２はおしゃべりサ
ーバ１８のエージェント制御部６６に、献立エージェン
ト制御部９４は献立サーバ２０の図示しないエージェン
ト制御部にそれぞれ対応する。おしゃべりエージェント
制御部９２、献立エージェント制御部９４は、それらの
エージェントによるサービスの結果を表示するためのウ
ィンドウを生成するおしゃべり用領域生成部１０６、献
立用領域生成部１０８をそれぞれ管理している。第２ユ
ニット８４はキャラクタ統括部９６を有し、キャラクタ
統括部９６はおしゃべりキャラクタ制御部９８、献立キ
ャラクタ制御部１１６を統括する。キャラクタ統括部９
６はコントロールウィンドウ管理サイト１６のキャラク
タ統括部２４に、おしゃべりキャラクタ制御部９８はお
しゃべりサーバ１８のキャラクタ制御部６８に、献立キ
ャラクタ制御部１１６は献立サーバ２０の図示しないキ
ャラクタ制御部にそれぞれ対応する。ユーザダイアログ
処理部８６はコントロールウィンドウ管理サイト１６の
ユーザダイアログ処理部２６に対応する。ユーザダイア
ログ処理部８６の入力内容は第１ユニット８２、第２ユ
ニット８４から参照される。

【００４８】以上の機能は図２、図３において既述のと
おりであるが、ユーザとのやりとりからいえば、おしゃ
べり用領域生成部１０６、献立用領域生成部１０８はユ
ーザに情報を表示し、逆に指示その他の操作を受け付け
る。第２ユニット８４はユーザに表示または音声によっ
て情報を提供し、ユーザからクリックを代表とする操作
を受け付ける。ユーザダイアログ処理部８６はユーザ入
力プロンプトをユーザに表示し、文字入力を受け付け
る。

【００４９】以上の構成によるユーザとエージェントの
相互作用、およびエージェント間の相互作用を説明す
る。図９はユーザがユーザ端末１２を起動したとき表示
される画面１５０を示す。ここではおしゃべりエージェ
ントのキャラクタ１５６（以下単におしゃべりエージェ
ント１５６という）が現れ、「こんにちは！私はおし
ゃべりエージェントのピー子です。・・・」と発話す
る。ユーザは入力領域１５４に「レシピをおしえて」と
入力し、送信ボタンを押す。入力領域１５４はユーザが
おしゃべりエージェント１５６をクリックしたとき現れ
る構成としてもよく、クリックがなされない間はおしゃ
べりエージェント１５６がとりとめのないことばを発し
続けてもよいし、ユーザに質問をして発話を促してもよ
い。

【００５０】入力された「こんにちは」はユーザダイア
ログ処理部８６で取得され、おしゃべりエージェント制
御部９２によって解析される。すなわち、おしゃべりエ
ージェント制御部９２は図３のおしゃべりサーバ１８の
エージェント制御部６６の機能をコピーしており、対象
発話の内容の特定により、キャラクタ制御部６８の行動
ファイル６２の中からユーザに応答するためのページが
特定される。ページの特定は、キャラクタ制御部６８の
行動ファイル６２で行われてもよいし、そのコピーであ
るユーザ端末１２内のおしゃべりキャラクタ制御部９８
で実施してもよい。ここでは対象発話がレシピに関する
ものであり、応答のために特定されたページには、「献
立エージェントを画面に呼び出す」旨の処理が記述さ
れ、具体的には、前述の全体統括部２２が準備する関数
ＡｄｄＡｇｅｎｔ（）をそのページのＨＴＭＬファイル
内に記述しておく。すなわち、あるエージェントによる
処理が他のエージェントに関連するとき、エージェント
レベルでの横断機能を利用し、エージェント間の橋渡し
が実現する。

【００５１】図１０はこうして現れた画面１５０を示
す。全体統括部９０の機能により、画面１５０は第１フ
レーム１５０ａ、第２フレーム１５０ｂに分割され、お
しゃべりエージェント１５６が前者、献立エージェント
１６０が後者に置かれている。献立エージェント１６０
の呼び出しに先立ち、おしゃべりエージェント１５６は
「では献立エージェントをよびましょう．．．」とユー
ザに発話しており、一方、呼び出された献立エージェン
ト１６０は「わたしが献立エージェント。どんな料理が
知りたいですか？」とユーザに尋ねている。献立エージ
ェント１６０によるこの発話は、献立エージェント制御
部９４および献立キャラクタ制御部１１６によって、や
はりユーザへの応答のためのページ（図示せず）に記述
された関数、たとえばキャラクタに発言をさせるＳｐｋ
（）等により実現される。ユーザは図１０の入力領域１
５４において「中華」と入力し、これを送信する。

【００５２】図１１はその結果現れる画面１５０を示
す。おしゃべりエージェント１５６は献立エージェント
１６０の発話が料理の紹介に言及していることを解釈
し、おしゃべりキャラクタ制御部９８がその発話に対す
る応答のページを特定する。そのページには「現在発話
中のエージェントに対し、辛いものを勧めないよう忠告
する」旨が記述されており、同図ではおしゃべりエージ
ェント１５６が献立エージェント１６０に近づき、かつ
その方を見て「ねえ、あんまり辛いのはやめてね。」と
頼んでいる。この処理のために、おしゃべりエージェン
ト１５６のページには、前述の関数のうち、ＷａｌｋＣ
ｌｏｓｅ（）、Ｔａｌｋ（）などが利用されている。一
方、その忠告を「他のエージェントの発話」として受け
取った献立エージェント１６０は、その内容を解釈し、
応答のためのページを特定する。そのページには例えば
「了解するとともに、チリソースの入っていないレシピ
を探す」旨が記述されている。このときもＴａｌｋ（）
の利用により、献立エージェント１６０はおしゃべりエ
ージェント１５６のほうを向いて話している。また、バ
ックグランドではおしゃべりエージェント制御部９２
が、（「レシピ」ｏｒ「献立」）ａｎｄ「中華」ａｎｄ
「おすすめ」ａｎｄ／「チリソース」などの検索式で条
件検索を実行している。／はｎｏｔ演算子である。な
お、ユーザが辛いものを苦手とする旨は、個人情報ファ
イル４８に予め記録されている。

【００５３】図１２は献立エージェント１６０による検
索の結果を示す画面１５０である。ここでは、献立エー
ジェント１６０が「今日のおすすめはこちら」と発話し
ながら、献立用領域生成部１０８によって生成された献
立用ウィンドウ１６６に検索結果を表示している。これ
らの検索結果はタイトル表示され、リンク先に詳細情報
が置かれている。また、検索の結果、中華料理のレシピ
があるサイトが献立エージェント制御部９４によって別
の検索結果欄１７２に表示され、ユーザの便宜が図られ
ている。一方、おしゃべりエージェントは、しばらく自
分に対する発話がなかったことを契機として、寝入って
いる。すなわち、対象発話の内容のみならず、その間隔
など、発話の状況に応じるページを作っておいてもよ
い。

【００５４】図１２では、ユーザはさらに、「もみじの
名所は？」という質問を入力している。図１３はこの結
果現れる画面１５０を示し、新設された第３フレーム１
５０ｃに旅行エージェント１７０が登場している。新た
なエージェントの登場は既述の方法による。おしゃべり
エージェント１５６は旅行エージェント１７０に向けて
「Ｈｅｌｌｏ．久しぶり。」といい、後者が「やあ」と
答えている。これら一連のエージェント間相互作用も、
既述の関数、またはそれらに類する関数によって実現で
きることは明らかである。

【００５５】実施の形態による効果は以下のとおりであ
る。従来、各社各様だったエージェントも、関数レベル
でのインタフェイスの標準化により、相互作用が可能に
なる。したがって、まったく出力形式が違うエージェン
ト、例えばＶＲＭＬ（Virtual Reality Modeling Langu
age）で記述された３Ｄポリゴンキャラクタ、ＪＰＥＧ
（Joint Photographic Expert Group）による平面キャ
ラクタ、ユーザがデジタルカメラで撮影した任意のビッ
トマップ形式のキャラクタ等が、同一の画面上で会話等
することができ、きわめてユニークなエージェント装置
を提供することができる。

【００５６】また、インタフェイスの統一により、例え
ばコントロールウィンドウ管理サイト１６を自社開発
し、各専門エージェントを第三者が開発していくことが
容易になる。したがって、ユーザの要望に応じて、多数
の専門エージェントを容易かつモジュラーに設計し、追
加していくことができる。

【００５７】以上、本発明をいくつかの実施の形態をも
とに説明した。これらの実施の形態は例示であり、それ
らの各構成要素や各処理プロセスの組合せにいろいろな
変形例が可能なこと、またそうした変形例も本発明の範
囲にあることは当業者に理解されるところである。そう
した例を挙げる。

【００５８】ユーザ端末１２に、使用頻度の高い専門エ
ージェントを予め複数実装し、またはダウンロードして
おいてもよい。その場合、おしゃべりエージェント１５
６による想定発話の解釈の後に呼び出すべき専門エージ
ェントがユーザ端末１２に存在すれば、おしゃべりエー
ジェント１５６による処理は不要になり、その専門エー
ジェントが自ら即座に画面１５０に現れることができ
る。したがって、おしゃべりエージェント１５６以外の
専門エージェントは、たとえユーザ端末１２の中に存在
しても、当初は隠れていてもよい。

【００５９】コントロールウィンドウ８０はコントロー
ルウィンドウ管理サイト１６から提供される概念的な存
在としてとくに説明しなかったが、現実の実装において
は、コントロールウィンドウ８０を画面１５０上のオブ
ジェクトや領域と対応させ、可視的に、または不可視的
に設けてもよい。たとえば、画面１５０全体に見えない
コントロールウィンドウ８０を設けておき、ユーザが画
面１５０の任意の個所をクリックしたとき、はじめてお
しゃべりエージェント１５６が登場する構成であっても
よい。

【００６０】対象発話はテキストベースで行われたが、
これは音声認識で行ってもよい。その場合、ユーザはよ
り一層専門エージェントと対話している形になる。

【００６１】不明発話は、想定発話集３８において特定
できなかった発話と考えたが、想定発話集３８では特定
できても、実際に専門エージェントによる応答が不完全
だったか、または全く実現できなかった場合に、その発
話を不明発話としてもよい。たとえば、「レシピを知り
たい」という対象発話をもとに検索をかけたとき、候補
が多すぎてユーザの意に叶わなかったような場合も不明
発話として管理者へ通知し、専門エージェントによる対
応を改善させてもよい。

【００６２】実施の形態では、ユーザによる専門サーバ
へのアクセス状況を考慮して専門エージェントによる発
話を適宜選択した。これ以外にも、ユーザの属性情報を
もとに発話を選択してもよい。例えば、ユーザが女性の
場合、専門エージェントは比較的柔らかい表現を選択し
てもよいし、ユーザが年輩の場合、よりていねいな表現
を選択してもよい。

【００６３】実施の形態では、専門エージェントは全文
検索を用いて発話を解釈したが、これはそれに限る必要
はない。例えば、ある専門エージェントはユーザの発話
に「牛」ということばが含まれていれば必ず反応する
「牛専門エージェント」のような方法も可能である。す
なわち、専門エージェントごとに発話解釈方法は異なっ
てもよいし、同じ専門エージェントが複数の発話解釈方
法を併用してもよい。

【００６４】第２ユニット８４のキャラクタ統括部９６
は、第１ユニット８２の全体統括部９０へ吸収するな
ど、これまで述べた以外にもいろいろな構成が可能であ
る。いずれの部分を統合し、または分割するかについて
は、設計の指針および実際の運用に応じて決めていけば
よい。

【００６５】キャラクタの「Ｓｐｅａｋ」などの動作
は、サーバ側から各キャラクタ制御部へ伝達されるとし
たが、これをいったん各エージェント制御部で受け、全
体統括部９０を経由して各キャラクタ制御部に伝えても
よい。この場合、全体統括部９０が現在進行している全
ての状況を把握できる。また、全体統括部９０は、各キ
ャラクタ制御部のあるフレーム名、専門エージェントや
キャラクタの数、キャラクタの位置などを把握している
ため、全てのキャラクタに対して「Ｓｐｅａｋ」する動
作や、あるキャラクタの動作を他のキャラクタに認識さ
せることが容易になる。

【発明の効果】本発明によれば、開発効率に優れたユー
ザ支援技術が提供される。また多様なサービスをユーザ
に提供することができる。

【図面の簡単な説明】

【図１】実施の形態に係るクライアント・サーバシス
テムの全体構成図である。

【図２】実施の形態に係るコントロールウィンドウ管
理サイトの構成図である。

【図３】実施の形態に係るおしゃべりサーバの構成図
である。

【図４】おしゃべりサーバに含まれるインデックスフ
ァイルの構成図である。

【図５】おしゃべりサーバに含まれる想定発話集の構
成図である。

【図６】おしゃべりサーバに含まれるアクセス情報フ
ァイルの構成図である。

【図７】おしゃべりサーバに含まれる行動ファイルの
構成図である。

【図８】クライアントであるユーザ端末の構成図であ
る。

【図９】ユーザ端末を起動したときに現れるおしゃべ
りエージェントを示す図である。

【図１０】ユーザがレシピを尋ねたとき、おしゃべり
エージェントと並行して現れる献立エージェントを示す
図である。

【図１１】おしゃべりエージェントと献立エージェン
トの会話を示す図である。

【図１２】献立エージェントが検索結果をユーザに提
示する場面を示す図である。

【図１３】おしゃべりエージェントが新たに登場した
旅行エージェントと会話する様子を示す図である。

【符号の説明】

１０ユーザ支援システム、１２ユーザ端末、１
６コントロールウィンドウ管理サイト、１８おし
ゃべりサーバ、２０献立サーバ、３２発話取得
部、３４発話検索部、３６インデックスファイ
ル、３８想定発話集、６２行動ファイル、８
０コントロールウィンドウ、８２第１ユニット、
８４第２ユニット、８６ユーザダイアログ処理
部、９０全体統括部、９２おしゃべりエージェ
ント制御部、９４献立エージェント制御部、９６
キャラクタ統括部、９８おしゃべりキャラクタ制
御部、１１６献立キャラクタ制御部、１５６お
しゃべりエージェント、１６０献立エージェント、
１７０旅行エージェント。

───────────────────────────────────────────────────── フロントページの続き (72)発明者松岡継文大阪府守口市京阪本通２丁目５番５号三洋電機株式会社内Ｆターム(参考） 5B069 AA01 AA20 BA03 CA19 DD01 LA03 5E501 AA04 BA05 CA04 DA01 EA34 FA14 FA26 FA42

Claims

【特許請求の範囲】

【請求項１】キャラクタを利用してユーザを支援する
エージェントを提供する装置であって、エージェントのレベルで制御を行う第１ユニットと、キャラクタのレベルで制御を行う第２ユニットとを含
み、第１ユニットは、複数エージェント間の相互作用を実現するための場を提
供し、それらのエージェントを総合的に管理する全体統
括部と、それぞれがキャラクタを媒介としてユーザの要求を取得
および解釈することにより、エージェントの実体的機能
を実現する複数のエージェント制御部とを有し、第２ユニットは、前記複数エージェント間の相互作用をキャラクタのレベ
ルで可視的に表現するための基本機能を提供するキャラ
クタ統括部と、それぞれが前記複数のエージェント制御部のいずれかに
対応し、当該対応するエージェント制御部が利用するキ
ャラクタの一連の基本動作を提供する複数のキャラクタ
制御部とを有し、全体統括部およびキャラクタ統括部によって提供される
複数エージェント間の横断的機能と、エージェント制御
部およびキャラクタ制御部によって提供されるエージェ
ントごとの個別的機能とのインタフェイスが、複数のエ
ージェント制御部および複数のキャラクタ制御部につい
て統一されていることを特徴とするユーザ支援装置。
【請求項２】前記インタフェイスの統一によって前記
複数のキャラクタの出力形式の相違が吸収され、それら
のキャラクタが表示装置の画面に同時に現れて相互作用
をすることを特徴とする請求項１に記載のユーザ支援装
置。
【請求項３】前記複数のエージェント制御部のいずれ
かに対応し、当該対応するエージェント制御部の処理結
果を表示するためのウインドウまたはフレームを生成す
る領域生成部をさらに含むことを特徴とする請求項１、
２のいずれかに記載のユーザ支援装置。
【請求項４】前記複数のエージェント制御部は、それ
ぞれ専門分野のサービスを担当するようセグメント化が
なされて実装されていることを特徴とする請求項１から
３のいずれかに記載のユーザ支援装置。
【請求項５】当該ユーザ支援装置はクライアント・サ
ーバシステムのクライアント端末として構成され、少な
くとも前記エージェント制御部の実体的機能がサーバと
の通信を交えて提供されることを特徴とする請求項１か
ら４のいずれかに記載のユーザ支援装置。
【請求項６】当該ユーザ支援装置はクライアント・サ
ーバシステムのサーバとして構成され、少なくとも前記
エージェント制御部の実体的機能をクライアントとの通
信を交えて提供することを特徴とする請求項１から４の
いずれかに記載のユーザ支援装置。
【請求項７】前記キャラクタ制御部は、前記ユーザの
要求に応じるための行動を記述した行動ファイルを備
え、当該行動ファイルはひとつの行動についてひとつの
ページが対応する形で多数のページがバンドルされ、形
成されていることを特徴とする請求項１から６のいずれ
かに記載のユーザ支援装置。
【請求項８】前記相互作用は少なくともキャラクタ間
の会話を含み、前記全体統括部は、その会話のために一
方のキャラクタから他方のキャラクタへの会話データを
受け渡しすることを特徴とする請求項１から７のいずれ
かに記載のユーザ支援装置。
【請求項９】前記キャラクタ統括部は、複数のキャラ
クタ間の位置関係を取得し、その位置関係を変えること
により前記相互作用が起こされることを特徴とする請求
項１から８のいずれかに記載のユーザ支援装置。
【請求項１０】キャラクタを利用してユーザを支援す
るエージェントを提供するクライアント・サーバによる
システムであって、前記クライアントは、エージェントのレベルで制御を行
う第１ユニットと、キャラクタのレベルで制御を行う第
２ユニットとを含み、第１ユニットは、複数エージェント間の相互作用を実現
するためにそれらのエージェントを総合的に管理する全
体統括部と、それぞれがキャラクタを媒介としてユーザ
の要求に応答する複数のエージェント制御部とを有し、第２ユニットは、前記複数エージェント間の相互作用を
キャラクタのレベルで表現するキャラクタ統括部と、そ
れぞれが前記複数のエージェント制御部のいずれかに対
応し、当該対応するエージェント制御部が利用するキャ
ラクタの一連の基本動作を提供する複数のキャラクタ制
御部とを有し、前記サーバは、前記複数のエージェント制御部と連携
し、前記ユーザの要求を解釈してその応答に必要な情報
を前記クライアントへ提供することを特徴とするユーザ
支援システム。
【請求項１１】前記サーバはさらにコントロールウィ
ンドウ管理部を含み、当該コントロールウィンドウ管理
部は、前記全体統括部およびキャラクタ統括部の機能を
前記クライアントへ提供することを特徴とする請求項１
０に記載のユーザ支援システム。
【請求項１２】前記サーバは複数の専門サーバを含
み、これらの専門サーバはそれぞれ自己の専門分野に関
するサービスをなすべく、前記エージェント制御部およ
びキャラクタ制御部の機能を前記クライアントへ提供す
ることを特徴とする請求項１０、１１のいずれかに記載
のユーザ支援システム。
【請求項１３】キャラクタを利用してユーザを支援す
るエージェントを提供する方法であって、エージェントのレベルで制御を行う第１の処理過程と、キャラクタのレベルで制御を行う第２の処理過程とを含
み、第１の処理過程は、複数エージェント間の相互作用を実現するために、それ
らのエージェントを総合的に管理する全体統括過程と、それぞれがキャラクタを媒介としてユーザの要求に応答
する複数のエージェント制御過程とを有し、第２の処理過程は、前記複数エージェント間の相互作用をキャラクタのレベ
ルで表現するキャラクタ統括過程と、それぞれが前記複数のエージェント制御過程のいずれか
に対応し、当該対応するエージェント制御過程が利用す
るキャラクタの一連の基本動作を提供する複数のキャラ
クタ制御過程とを有し、以上の過程の連鎖によって実現される複数エージェント
間の横断的機能とエージェントごとの個別的機能とのイ
ンタフェイスが、複数のキャラクタについて統一されて
いることを特徴とするユーザ支援方法。