JP2002169818A

JP2002169818A - ユーザ支援装置およびシステム

Info

Publication number: JP2002169818A
Application number: JP2000369116A
Authority: JP
Inventors: Mutsumi Ikeda; 睦美池田; Atsushi Maeda; 篤志前田; Tsugufumi Matsuoka; 継文松岡
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2000-12-04
Filing date: 2000-12-04
Publication date: 2002-06-14

Abstract

(57)【要約】【課題】ユーザフレンドリーかつ迅速に情報を検索で
きる環境を実現する。【解決手段】起点サーバ２０は、ユーザの発話を特定
するための発話特定ブロックを有し、ユーザの発話をユ
ーザ発話集に照合して内容を特定して、応答すべき専門
サーバへ処理をうつす。専門サーバではエージェントが
ユーザの発話に応答する。起点サーバ２０は、情報の検
索を開始する契機となる発話を集めた付加発話集をさら
に有し、ユーザの発話がこれに含まれるとき、情報検索
部が検索処理を行う。検索結果はキャラクタによる発話
の形でユーザへ提示される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ユーザ支援技術
に関する。この発話はとくに、エージェントを利用して
ユーザの操作、検索その他の処理を支援するシステムに
関する。

【０００２】

【従来の技術】インターネットの利用が進むにつれ、そ
の主要なアプリケーションであるＷＷＷ（World Wide W
eb）の利用者が激増し、ＷＷＷのふたつの利用形態、す
なわち情報の発信と検索がユーザに広く浸透した。情報
の発信が増えるにつれ、たいがいの情報はいずれかのＷ
ｅｂサイトのいずれかのページにあるという状況が現実
になった。しかし、検索対象であるＷｅｂサイトやその
ページがあまりにも多くなった結果、求める情報はどこ
かにあると確信しつつ、現実にはなかなかその情報へた
どり着けない状況が日常的になっている。

【０００３】こうした状況に敏感な検索系ポータルサイ
トでは、以前より、情報の階層化や検索方法の洗練に努
めている。すなわち、ユーザは予め絞り込まれたトピッ
クの範囲において、論理和、論理積などの検索条件を駆
使することにより、情報の洪水から欲しい情報を効率的
に発見できるというものである。

【０００４】

【発明が解決しようとする課題】しかし、インターネッ
ト利用が専門家に限られていた時代ならともかく、検索
の実務に不慣れなユーザによるＷＷＷの利用が増えた今
日、高度な検索式の利用を一般ユーザに求めることは困
難である。また、情報の激増に従って情報の階層が深く
なり、求める情報がどこに分類されているか把握できな
い場合も多い。情報を発信するサイトは増加の一途を辿
り、かつ相当数のユーザのコンピュータ利用経験が浅い
今日の状況から、情報の氾濫が情報の利用を妨げる事態
が喚起されつつある。

【０００５】本発明は、そうした課題に鑑みてなされた
ものであり、その目的は、ユーザがより親しみやすい環
境の中で所望の情報へ到達し、または所望の処理を円滑
にコンピュータその他の装置に実行させることの可能な
ユーザ支援技術の提供にある。

【０００６】

【課題を解決するための手段】本発明のある態様は、ユ
ーザ支援装置（以下、単に「装置」または「本装置」と
もいう）に関する。この装置は、ユーザの発話を想定し
て作成された電子的なユーザ発話集を有し、前記ユーザ
から発話が入力されたときその内容を特定する発話特定
ブロックと、前記発話に対する応答を目的とするエージ
ェントの行動を想定して作成された電子的なエージェン
ト行動集を有し、前記ユーザの発話に前記エージェント
によって応答せしめる応答ブロックと、前記ユーザが検
索を希望する情報の内容を予め取得して保持する検索内
容保持部と、前記情報を検索する情報検索部と含み、前
記発話特定ブロックはさらに、前記情報検索部が前記検
索を開始すべき発話を想定して作成された付加発話集を
有し、前記ユーザからの発話がその付加発話集に含まれ
るとき、その内容を特定し、前記情報検索部は、前記ユ
ーザが前記付加発話集に含まれる発話を行ったことを契
機として、前記情報の検索を開始する。

【０００７】「エージェント」は、ユーザに代わって情
報の検索を行ったり、ユーザと対話しながら所望の情報
へ到達するための支援を行う機能の総称であり、主に擬
人化されたキャラクタを画面に登場させ、ユーザとの対
話を行う。エージェントは、キャラクタのように可視的
であるとは限らず、システムのバックエンド等、見えな
いところでユーザを支援するプログラムその他の処理機
能を指してもよい。エージェントの「行動」は、エージ
ェントの発話、画像、動作その他、支援のための処理に
関連する任意の処理要素や処理動作を指す。

【０００８】このユーザ支援装置において、前記付加発
話集に盛り込むべき内容を前記ユーザ発話集に組み入れ
ることによりそれらを前記ユーザ発話集に一元化しても
よい。これにより、ユーザの発話を特定する際にユーザ
発話集と付加発話集の双方に一度に照合することができ
る。

【０００９】前記情報検索部は、前記情報の検索を自発
的に開始する自発検索部をさらに含んでもよい。ユーザ
の発話を待たずに情報の検索を行っておくので、ユーザ
から情報を要求されたときに迅速に提示することができ
る。情報を提示する際も、ユーザの発話を待たず自発的
に提示してもよい。検索を行うタイミングは、所定の間
隔で定期的に行ってもよいし、ネットワークの負荷が少
ない時間帯に行ってもよい。

【００１０】このユーザ支援装置は、前記情報の属する
分野ごとに擬人化されたキャラクタを対応づけ、前記検
索の結果をその情報の属する分野に対応したキャラクタ
の発話として前記ユーザへ示すキャラクタ表示部をさら
に含んでもよい。これにより、キャラクタ自身が主体的
に検索を行っているように見せることができ、より親し
みやすい環境を提供することができる。

【００１１】前記検索内容保持部は、ウェブサイトのネ
ットワークアドレスをブックマーク情報として保持する
ブックマーク保持部を含み、前記情報検索部は、前記ウ
ェブサイトの更新状況を取得してもよい。前記キャラク
タ表示部は、前記キャラクタに対応づけられた分野に属
する前記ウェブサイトが更新されていたとき、そのキャ
ラクタの発話として前記更新状況を前記ユーザへ提示し
てもよい。ネットワークアドレスは、インターネット上
の情報にアクセスするための表記であるＵＲＬ（Univer
sal Resource Locator）であってもよい。ブックマーク
情報はキャラクタごとに複数登録してもよい。このと
き、キャラクタはブックマークを整理するフォルダとし
ても機能する。更新状況は、ユーザが関連した発話を行
ったときに提示されてもよいし、キャラクタから自発的
に提示してもよい。

【００１２】このユーザ支援装置は、前記キャラクタの
属性値を管理し、前記ユーザの前記キャラクタに対する
扱いにより前記属性値を変化させ、前記属性値に応じて
前記キャラクタの行動を変化させるキャラクタ管理部を
さらに含んでもよい。前記キャラクタ管理部は、前記属
性値に基づいて、前記キャラクタに対応づけられた分野
に属する前記ウェブサイトの更新状況を取得する頻度を
変更してもよい。これにより、ユーザはよりキャラクタ
に親しみを感じ、楽しみながら情報を得ることができ
る。

【００１３】本発明の別の態様は、ユーザ支援システム
に関する。このユーザ支援システムは、前述のユーザ支
援装置を専門分野に応じて複数設け、それらを異なるノ
ードとしてネットワークに接続し、かつそれらのユーザ
支援装置の前記ユーザ発話集、前記エージェント行動集
および前記付加発話集を、それぞれ当該装置の専門分野
を中心に形成する。その場合、ユーザがクライアント、
ユーザ支援装置がサーバとなり、サーバクライアントシ
ステムが構築される。ユーザ支援装置は、ユーザに対す
るサービスの内容ごとに設けられてもよく、たとえばニ
ュース、占い、旅行、料理、ビジネス、健康などのトピ
ックごとに設けられてもよい。この場合、それぞれのユ
ーザ支援装置が明確なテーマをもっているため、エージ
ェントの洗練が比較的容易になる。また、トピックごと
に異なるノードで処理ができるため、分散処理による負
荷の軽減が図られる。

【００１４】このユーザ支援システムにおいて、前記ユ
ーザ支援装置は、それぞれ前記応答ブロックを自ノード
に保持する一方、前記発話特定ブロックを前記ネットワ
ークのひとつのノードにおいて共用してもよい。この構
成では、共用される発話特定ブロックには、他の全ての
応答ブロックに対応するユーザ発話集が含まれてもよ
い。このとき、発話特定ブロックを含むユーザ支援装置
は、ユーザ支援システム内で処理可能な全ての発話を特
定できるエントランスまたはポータル的なサーバであ
り、そこで特定された発話の内容にしたがい、複数のユ
ーザ支援装置から適切なものが選定されてもよい。これ
により、発話の内容の特定と、エージェントの応答とを
異なるノードで処理できるので、分散処理による負荷の
軽減が図られる。

【００１５】このユーザ支援システムにおいて、前記発
話特定ブロックは、前記ユーザの発話を前記ユーザ発話
集の中で検索する発話検索部と、前記ユーザの発話が前
記ユーザ発話集の中に見い出されなかったとき、その旨
をシステム管理者へ通知する通知部とを含んでもよい。
その場合、管理者がユーザに別途対応したり、ユーザ発
話集およびエージェント行動集を改訂したりすることが
できる。

【００１６】前記発話特定ブロックは、前記ユーザ発話
集の内容に対するインデックスを保持するインデックス
格納部を有し、前記検索部は、前記ユーザの発話が入力
されたとき、前記インデックス格納部に対して初期的な
検索をかけてもよい。この場合、前記検索部は、前記ユ
ーザの発話が入力されたとき、前記インデックス格納部
に対して初期的な検索、すなわち、絞込のための検索等
をかけることができ、検索の高速化が実現する。

【００１７】このユーザ支援システムは、前記ユーザ発
話集の使用を希望する者に対して、当該発話集をオフラ
インまたはオンラインで提供するライブラリ提供部をさ
らに含んでもよい。オフラインによる提供には、たとえ
ば、ユーザ発話集をパッケージとして提供するなどの方
法がある。オンラインによる提供には、たとえば、ユー
ザ発話集を置いたサーバを設け、そのライブラリサイト
の利用権を提供するなどの方法がある。ユーザ発話集の
中でも、ユーザの一般的な発話を自然言語のライブラリ
として記録した一般発話ライブラリを提供してもよい。
この構成により、第三者がユーザ発話集、付加発話集、
およびエージェント行動集を独自に開発して、新たなユ
ーザ支援装置を設けることが可能となり、ひいては、ユ
ーザ支援システムのさらなる充実化を図ることができ
る。

【００１８】本システムはさらに、前記ユーザによる本
システムへのアクセス記録を取得する記録部を含んでも
よい。この場合、前記応答ブロックは、前記応答のため
の前記エージェントの発話を前記ユーザによるアクセス
の状況にしたがって複数の候補から選択してもよい。例
えば、あるユーザがエージェントＡに対して「こんにち
は」といったとき、そのユーザによる初回の訪問であれ
ば、エージェントＡは「こんにちは」と答えればよい
が、２回目であれば「やあ、また会いましたね」などと
応答してもよい。この場合、ユーザのアクセス履歴をも
とに最適と思われるものが選択され、より自然な、また
は、より親しみやすい会話が実現する。

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

【００２０】

【発明の実施の形態】図１は、第１の実施形態に係るユ
ーザ支援システム１６を含むネットワークシステム１０
の全体構成を示す。ここでは、ユーザ端末１２とユーザ
支援システム１６がインターネット１４を介して接続さ
れている。ユーザ端末１２はＰＣ（パーソナルコンピュ
ータ）、ＰＤＡ、インターネット１４へ接続可能な携帯
電話、その他任意のハードウエアである。

【００２１】ユーザ支援システム１６は、起点サーバ２
０、おしゃべりサーバ２４、およびグルメサーバ２６を
有し、これらがそれぞれインターネット１４に接続され
ている。起点サーバ２０は、ユーザの発話を想定して作
成された電子的なユーザ発話集を有し、ユーザから発話
が入力されたときその内容を特定する発話特定ブロック
を保持する。この発話特定ブロックは、ユーザ支援シス
テム内の他のサーバ、すなわち、おしゃべりサーバ２４
およびグルメサーバ２６により共用される。おしゃべり
サーバ２４およびグルメサーバ２６は、それぞれ、発話
に対する応答を目的とするエージェントの行動を想定し
て作成された電子的なエージェント行動集を有し、ユー
ザの発話にエージェントによって応答せしめる応答ブロ
ックを自ノードに保持する。

【００２２】起点サーバ２０、おしゃべりサーバ２４、
グルメサーバ２６は異なるネットワークノードとして構
成されており、ユーザの発話の特定処理とエージェント
の応答処理を分散することができる。また、エージェン
トもその担当分野に応じて別ノードにすることができ、
エージェント単位のメンテナンスが容易になる。おしゃ
べりサーバ２４、グルメサーバ２６という名称もその担
当分野または専門分野に応じて与えられている。以下、
おしゃべりサーバ２４、グルメサーバ２６等を総括的に
「専門サーバ」とよび、それらのサーバに置かれたエー
ジェントを「専門エージェント」とよぶ。ユーザ支援シ
ステム１６は一体に構成され、たとえばひとつのポータ
ルサイト内に構成されてもよいが、以下の説明では別ノ
ードとして構成され、起点サーバ２０がユーザ端末１２
に対してポータルサーバとして振る舞う例を考える。

【００２３】ユーザの発話は、まず起点サーバ２０へ送
られ、ユーザ発話集に照らして内容が特定される。そし
て、その内容に応じて応答すべきエージェントが特定さ
れ、応答ブロックにより応答処理が実行される。たとえ
ば、「こんにちは」などの一般的なあいさつに対して
は、おしゃべりサーバ２４に実装されたエージェント
（以下、「おしゃべりエージェント」ともいう）が応答
し、「ぎょうざのおいしい店をおしえて」などの料理、
食事等に関する発話に対しては、グルメサーバ２６に実
装されたエージェント（以下、「グルメエージェント」
ともいう）が応答する。それぞれの専門エージェント
が、ユーザと対話していく中でユーザの望む情報を的確
に聞き出し、膨大な量の情報の中から所望の情報を見つ
け出すための支援を行う。

【００２４】本実施形態のユーザ支援システムでは、ユ
ーザが関心を持っていてよく検索を行う情報の内容を予
め登録させ保持しておく。これにより、ユーザがその情
報に関連した発話を行ったときに、すぐに検索を開始す
ることができる。また、予め検索を行っておくことで、
すぐに検索結果を提示することができる。検索を開始す
るトリガとなるユーザ発話、または検索結果を表示する
トリガとなるユーザ発話をうまく調整することにより、
タイミングよくユーザへ情報を提示することができ、使
い勝手を向上させることができる。

【００２５】また、情報をユーザへ提示する際に、擬人
化されたキャラクタの発話の形で提示するので、キャラ
クタが主体的に検索を行っているように見える。これに
より、非常に親しみやすく、初心者でも使いやすい環境
を提供することができる。情報が属する専門分野ごとに
キャラクタを対応づけておくので、キャラクタを見ただ
けでどのような分野の情報が提示されているのかが分か
る。とくに、ユーザが頻繁に検索を行う分野のキャラク
タは、頻繁に登場してユーザと対話することとなり、ユ
ーザはそのキャラクタに愛着を感じるようになる。

【００２６】そのようなキャラクタを、「お気に入りキ
ャラクタ」として登録しておき、ユーザがすぐに呼び出
せるようにしてもよい。お気に入りキャラクタには、ユ
ーザが気に入ったウェブサイトのＵＲＬを登録可能と
し、そのウェブサイトの更新状況をキャラクタが提示す
る。それぞれのキャラクタは、自身の担当する専門分野
に属するウェブサイトのＵＲＬを保持するので、ブック
マーク情報を専門分野ごとに整理することができる。す
なわち、キャラクタがブックマークを整理するフォルダ
として機能する。また、キャラクタには複数のＵＲＬを
登録しておくことができ、そのウェブサイトの更新状況
をキャラクタが通知してくれるので、ユーザはウェブサ
イトに一つ一つアクセスして更新状況を確認する必要が
ない。更新状況を確認し通知するタイミングは、ユーザ
が関連する発話を行ったときでもよいし、たとえば一定
時間ごとに自発的に行ってもよい。

【００２７】ユーザがお気に入りキャラクタを飼うこと
ができるようにしてもよい。たとえば、画面に「キャラ
クタハウス」を表示し、その中でキャラクタが生活して
いるように見せてもよい。このとき、ユーザのキャラク
タに対する扱いにより、その属性値が変化するようにし
てもよい。そして、その属性値の大小によりキャラクタ
の行動を変化させてもよい。たとえば、「ごきげん」と
いう属性値を設けておき、ユーザがキャラクタを優しく
扱ったときに「ごきげん」属性値が大きくなり、ユーザ
がキャラクタを手荒く扱ったときに「ごきげん」属性値
が小さくなるようにしてもよい。その結果、「ごきげ
ん」属性値が大きいキャラクタの検索頻度を高くし、
「ごきげん」属性値が小さいキャラクタは機嫌が直るま
で検索を行わないようにしてもよい。これにより、ユー
ザはよりいっそうキャラクタに親しみを抱くようにな
る。

【００２８】詳細は後に述べるが、図１における処理の
概要は以下のとおりである。ユーザがユーザ端末１２を
起動すると、ユーザ端末１２内部に実装されたローカル
エージェントが現れる。このローカルエージェントはユ
ーザの最初の発話（以下この発話を「処理開始発話」と
いう）を待つ。処理開始発話はインターネット１４を経
由して起点サーバ２０へ送信される。このとき、ユーザ
端末１２はＷＷＷブラウザによって起点サーバ２０のペ
ージを表示している。

【００２９】起点サーバ２０には、ユーザ発話集、すな
わちユーザがなすであろう発話の想定集が実装されてい
る。ユーザ発話集には、専門エージェントが検索を開始
する契機となる発話の想定集である付加発話集が組み入
れられ、これらが一元化されている。処理開始発話はユ
ーザ発話集に照合され、発話内容が特定される。その結
果、処理開始発話に応答すべき専門エージェントが特定
され、その専門サーバのＵＲＬ（同図中ＵＲＬａ、ＵＲ
Ｌｂと表記）がユーザ端末１２のブラウザへ送られる。
ＵＲＬを取得したユーザ端末１２の画面にはその専門サ
ーバのページが表示され、専門エージェントが現れる。
専門サーバはそれぞれ専門エージェントのためのエージ
ェント行動集をもっており、処理開始発話およびそれ以
降のユーザの発話（以下「通常発話」という）に応答す
る。以下、エージェントの行動として主に発話を例にと
るが、それに限られるものではなく、エージェントの身
振りその他の動作、画像上の色、テクスチャ等の変化、
エージェントによる検索動作その他のプログラム処理な
どでユーザに対応してもよい。

【００３０】処理開始発話が付加発話集に含まれていた
ときは、検索を実行し結果を表示するためのページへジ
ャンプする。そのページでは、ユーザが予め登録してい
た内容に基づいて検索処理を行い、その結果をキャラク
タの発話として提示する。または、ユーザが予め登録し
ていたウェブサイトの更新状況を取得し、その結果をキ
ャラクタの発話として提示する。そして、ユーザの次の
発話を待つ。検索を実行するためのページへ遷移するの
ではなく、検索の開始を専門エージェントへ伝え、背後
で検索処理を実行させてもよい。このとき、画面上で
は、引き続きキャラクタとユーザの間で対話が続行され
てもよい。

【００３１】ユーザがその専門エージェントに新たな発
話、すなわち通常発話をしたとき、これが取得され、起
点サーバ２０へ送られる。起点サーバ２０はその発話に
応答すべき専門エージェントを再度特定し、その専門サ
ーバのＵＲＬを再度ユーザ端末１２へ送信する。以下同
様に、１．起点サーバ２０によるユーザ発話の特定２．特定された発話を担当する専門サーバの特定３．その専門サーバに置かれた専門エージェントによる
ユーザへの応答４．検索処理の実行および検索結果の提示５．ユーザの通常発話の要求または促進という一連の処理が繰り返される。処理がつねに一旦起
点サーバ２０へ戻り、そこから新たに開始されるため、
起点サーバ２０の名がある。

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

【００３３】通信部３０はインターネット１４を介して
専門サーバおよびユーザ端末１２とやりとりをする。発
話取得部３２はユーザ端末１２からユーザの発話を取得
し、これを発話検索部３４へ送る。また、発話取得部３
２は、専門サーバから専門エージェントの発話を取得
し、これを発話検索部３４へ送る。発話検索部３４はそ
の発話の第一文字をインデックスファイル３６へ照合
し、まずインデックスによる絞り込みをかけ、その後、
発話の内容を特定する。この際、発話全体についてフレ
ーズ検索をかける。フレーズ検索とは、単語の順番まで
含めて一致するものを見いだす処理である。フレーズ検
索で該当するものが見つからないときは、後述のよう
に、発話を形態素に分け、キーワードまたは単語によっ
て近いものを検索する。

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

【００３５】付加インデックスファイル３７は、付加発
話集３９に格納された他のエージェントの想定発話を５
０音順に並べて生成される。図２においては、便宜上、
付加インデックスファイル３７とインデックスファイル
３６とを別個に示しているが、実際は、付加インデック
スファイル３７の内容はインデックスファイル３６に組
み入れられ一元化されている。

【００３６】インデックスファイル３６で発話が特定さ
れると、その発話に応答すべき専門サーバのＵＲＬ等の
情報が記述されたファイルがインデックスファイル３６
内で特定され、ユーザ発話集３８または付加発話集３９
に内蔵されたそのファイル本体がオープンされ、前記Ｕ
ＲＬが判明する。

【００３７】ユーザ発話集３８には、ひとつの発話に対
してひとつのファイルが形成されている。ファイルに
は、ユーザの発話に応答するためのページのＵＲＬが記
述されている。図２においては、便宜上、付加発話集３
９とユーザ発話集３８とを別個に示しているが、実際
は、付加発話集３９の内容はユーザ発話集３８に組み入
れられ一元化されている。

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

【００３９】ユーザの発話と完全に一致するものがユー
ザ発話集３８に格納されているときは問題がないが、と
くにユーザ発話集３８の充実化の過程では、そうならな
いことも多い。その場合、発話検索部３４は既知の方法
でユーザの発話を形態素に分解し、それらのうち名詞の
論理積をとって再検索をかけるなどの処理により、最も
確からしい発話をユーザ発話集３８から見いだす。再検
索の対象となった発話、および、そうした再検索を通し
ても判明しなかった発話は、ともに不明発話として不明
発話ファイル４０に記録され、これが通知部４２を通じ
て起点サーバ２０の管理者へ電子メール等により通報さ
れる。管理者はその発話およびそれに応答すべき専門サ
ーバのページのＵＲＬをユーザ発話集３８へ新規登録
し、その発話のインデックスをインデックスファイル３
６へ登録し、かつそのページにおける専門エージェント
の発話を含む処理を設計する。このメンテナンスによれ
ば、なんら困難なプロセスなく、不明発話をそのままユ
ーザ発話集３８に追加していくことができるため、ユー
ザ発話集３８の充実は非常に容易である。

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

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

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

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

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

【００４５】図６は、付加インデックスファイル３７の
内部構成、図７は付加発話集３９の内部構成をそれぞれ
示す。前述のように、これらは実際にはインデックスフ
ァイル３６およびユーザ発話集３８に組み入れられてい
るが、ここでは理解を容易にするために、別個のファイ
ルとして説明する。付加インデックスファイル３７は、
５０音欄２００、ユーザの発話欄２０２、ファイル名欄
２０４を有する。ユーザの発話は、インデックスファイ
ル３６の場合と同様に、５０音順に整列される。

【００４６】付加発話集３９は、ファイル名欄２０４、
ユーザの発話欄２０２、応答すべき専門サーバのページ
欄２２０を有する。例えば、ユーザ発話「更新」に応答
する専門サーバのページは「ＵＲＬａ２０３」であり、
「更新」という発話と「ＵＲＬａ２０３」の組がファイ
ルｆ８０４を構成する。付加インデックスファイル３７
と付加発話集３９はファイル名によってリンクされ、例
えば「新着情報」という発話には、付加インデックスフ
ァイル３７においてファイルｆ８０５が記述され、これ
が付加発話集３９のファイルｆ８０５を指している。

【００４７】図８は専門サーバの例として、グルメサー
バ２６の内部構成を示す。通信部６０はインターネット
１４を介してユーザ端末１２、起点サーバ２０等と交信
する。起点サーバ２０の発話検索部３４によって特定さ
れたＵＲＬ、すなわち図４のごとくユーザ発話が「こん
にちは」の場合におけるＵＲＬａ１またはＵＲＬａ２
は、通信部６０を経てエージェント行動集６２に与えら
れる。エージェント行動集６２は、専門エージェントの
発話に加えて、その画像や動作を記述するエージェント
データ７２を含む。また、発話検索部３４によって特定
されたＵＲＬと一対一でページが設けられ、具体的に
は、ＵＲＬａ１のページ６４、ＵＲＬａ２のページ６
６、ＵＲＬａｎのページ６８のように構成される。ペー
ジはそれぞれいわゆるＷｅｂページであり、グルメエー
ジェントによる発話だけでなく、その画像や動作の表
示、さらにはそのエージェントがなすべきサービス、た
とえば情報の検索なども実行する。すなわち、ユーザの
発話ひとつに対してＷｅｂページをひとつ設け、対応の
柔軟性と充実を図る趣旨である。

【００４８】各ページはほぼ同じ構成であるから、同図
ではＵＲＬａ１のページ６４のみを詳述している。ＵＲ
Ｌａ１のページ６４はエージェント出力部７０、ユーザ
発話取得部７４、特定処理実行部７６を有する。これら
は、ＣＧＩ（Common GatewayInterface）のようにサー
バ側に処理の主たる機能が残るもの、Ｊａｖａ（商標）
アプレットやＡｃｔｉｖｅＸ（商標）のようにクライア
ント側に処理の主たる機能が移動するもの、ＡＰＩ（Ap
plication Program Interface）型でサーバとクライア
ントの両方に処理の主たる機能であるＪａｖａアプリケ
ーションなどを配するものなど、いろいろな態様で実現
できる。エージェント出力部７０はエージェントデータ
７２をもとに、グルメエージェントによってユーザの発
話へ応答する。特定処理実行部７６は、前述のごとく、
発話による応答以外の処理、例えば情報の検索、各種プ
ログラムの実行など任意の処理を行う。一例として、こ
のページに到達する原因となったユーザの発話が「新宿
のレストラン情報が知りたい」であれば、グルメエージ
ェントはインターネット１４を通してレストラン情報を
検索し、ユーザに示す。ユーザ発話取得部７４は、ユー
ザによるそれ以降の通常発話を取得し、これを起点サー
バ２０へ通知する。その結果、起点サーバ２０によって
新たに専門サーバが特定される。

【００４９】お気に入り登録部８０は、ユーザからグル
メエージェントをお気に入りキャラクタに登録したいと
いう要求を受け付けて、お気に入りデータ８２へ登録す
る。お気に入り登録部８０は、ユーザが検索を希望する
情報の内容およびウェブサイトのＵＲＬを取得して、同
様にお気に入りデータ８２へ登録する。キャラクタ管理
部８４は、キャラクタの属性値を管理し、ユーザのキャ
ラクタに対する扱いにより属性値を変化させる。キャラ
クタの属性値はお気に入りデータ８２に保持される。

【００５０】図９は、お気に入りデータの内部構成を示
す。お気に入りデータ８２には、ユーザ名欄３００、検
索内容欄３０２、キャラクタ属性値欄３０４、ブックマ
ーク欄３１２および３１８が設けられている。検索内容
欄３０２にはユーザが予め登録した検索を希望する情報
の内容が格納される。すなわち、お気に入りデータ８２
は、検索内容保持部としての機能を有する。キャラクタ
属性値欄３０４は、年齢欄３０６、ごきげん度欄３０
８、知性欄３１０を有し、キャラクタ管理部８４により
管理される。この属性値はキャラクタ表示部がキャラク
タを表示するときに参照される。属性値には、このほか
にも、性別、性格、空腹度などが考えられる。ブックマ
ーク欄は必要に応じて複数設けられ、ユーザが登録した
ブックマーク情報が格納される。ブックマーク欄はそれ
ぞれ、ウェブサイトのＵＲＬを格納するＵＲＬ欄３１
４、およびそのウェブサイトを最後に閲覧した日時を格
納する最終閲覧日欄３１６を有する。たとえば、「ｕｓ
ｅｒ１」の情報は、検索を希望する情報の内容は「ぎょ
うざ」および「天気」であり、キャラクタの年齢は「１
年８ヶ月」、ごきげん度は「１８０」、知性度は「９
５」、登録したブックマークの１つめは「http://○○.
com」で、その最終閲覧日は「２０００年１１月１９
日」、ブックマークの２つめは「http://○○.co.jp」
で、その最終閲覧日は「２０００年１０月２５日」であ
る。

【００５１】図１０は、エージェント行動集６２に格納
されたページのうち、検索処理を行うページの例を示
す。ＵＲＬａ２のページ６６の特定処理実行部７６は、
ユーザが所望する情報をインターネット１４を介して検
索する情報検索部７７と、自発的に検索を開始する自発
検索部７８を含む。情報検索部７７および自発検索部７
８は、お気に入りデータ８２に格納された検索内容およ
びＵＲＬ情報を取得して検索を行う。自発検索部７８
は、お気に入りデータ８２に格納されたキャラクタの属
性値を参照して、検索を行うタイミングを決めてもよ
い。検索結果はエージェント出力部７０のキャラクタ表
示部７１により、キャラクタの発話の形でユーザへ提示
される。

【００５２】図１１は、ユーザ端末１２の内部構成を示
す。通信部１３０はインターネット１４を介して起点サ
ーバ２０、おしゃべりサーバ２４、グルメサーバ２６等
と通信する。ユーザインタフェイス１３８はユーザの意
思決定を促し、またそれを入力するための構成全般の総
称で、キーボード、マウス、表示装置、各種データイン
タフェイスを含む。ローカルエージェント出力部１３２
はローカルエージェントデータ１３４を読み出してユー
ザインタフェイス１３８を通じてユーザへ提供する。ユ
ーザの処理開始発話および通常発話は、ユーザインタフ
ェイス１３８を介してユーザ発話入力部１３６に取得さ
れ、これが通信部１３０、インターネット１４を経由し
て起点サーバ２０へ送信される。以上が実施の形態の構
成全般であり、以下その処理を具体例で示す。

【００５３】図１２はユーザがユーザ端末１２を起動し
たとき表示される画面１５０を示す。ここではローカル
エージェント１５２が現れ、「ようこそ！私とおしゃ
べりをいたしましょう。」と話す。ユーザは入力領域１
５４に「こんにちは」と入力し、送信ボタンを押す。入
力領域１５４はユーザがローカルエージェント１５２を
クリックしたとき現れる構成としてもよく、クリックが
なされない間はローカルエージェント１５２がとりとめ
のないことばを発し続けてもよいし、ユーザに質問をし
て発話を促してもよい。いずれにせよ、入力された「こ
んにちは」は処理開始発話として起点サーバ２０へ送ら
れ、その内容から専門サーバとしておしゃべりサーバ２
４が特定され、ユーザ端末１２のアクセス先がそのペー
ジへ移行する。

【００５４】図１３はそのとき表示される画面１５０で
ある。ここではおしゃべりエージェント１５６が表示さ
れるが、この実施の形態では、ローカルエージェント１
５２と同一のエージェント画像を利用することにより、
シームレスな会話が続いているように見せている。おし
ゃべりエージェント１５６は「こんにちは！私はおし
ゃべりエージェントのピー子です。・・・」と発話す
る。ユーザが入力領域１５４で「ぎょうざのおいしい店
をおしえて」と入力し、これを送信すると、これが起点
サーバ２０で取得され、新たにグルメサーバ２６のひと
つのページが特定される。特定されたページのＵＲＬは
ユーザ端末１２へ送られ、ユーザ端末１２のアクセス先
がそのページへ移る。

【００５５】図１４はそのとき現れる画面１５０を示
す。ここではグルメエージェント１６０が新たに登場
し、「りょうかい！グルメエージェントの私におまか
せを。」と発話し、情報検索部７７が、たとえば「ぎょ
うざ」をキーワードとしてウェブページを検索する。検
索の間、ユーザが退屈しないよう、「今、探してくるか
らちょっと待ってね」と発話して、検索が実行されてい
ることを伝える。検索が終了すると、結果を表示するた
めのページへジャンプする。

【００５６】図１５はそうして移った先のページを示す
画面１５０である。情報検索部７７により取得されたウ
ェブページのタイトル１７０が表示されている。それぞ
れのタイトル１７０にはリンクがはられており、当該ペ
ージへアクセス可能に構成されている。この画面で、ユ
ーザが登録ボタン１８０をクリックすると、お気に入り
登録部８０がグルメエージェントをお気に入りキャラク
タとして登録する。

【００５７】図１６は、お気に入り登録部８０がユーザ
からブックマークの登録を受け付ける画面１５０を示
す。ユーザがＵＲＬ記入欄１９２にお気に入りのウェブ
サイトのＵＲＬを記入して登録ボタン１９０をクリック
すると、お気に入りデータ８２にブックマーク情報が登
録される。ブックマーク情報は、そのウェブサイトを閲
覧しているときに、図示しないブックマーク登録ボタン
などにより登録されてもよい。

【００５８】図１７は、お気に入りキャラクタを登録し
ている場合に表示される画面１５０を示す。画面にはお
気に入りキャラクタが生活するキャラクタハウス１９４
が新たに表示されている。ここで、ユーザが「新着情報
は？」と発話すると、このユーザ発話は付加発話集に含
まれるため、検索処理が実行される。

【００５９】図１８は、グルメエージェント１６０が検
索結果を提示する画面の例を示す。グルメエージェント
１６０は、ユーザが登録したウェブサイトのうち２つの
サイトが更新されたことを通知している。このとき、お
気に入りデータ８２に記録された最終閲覧日を参照し、
最終閲覧日よりも後に更新されたサイトの情報のみを提
示してもよい。ユーザが関連する発話を行ったときに、
登録ウェブサイトの更新状況を確認し、更新されていれ
ば通知する構成であってもよいし、定期的に更新状況を
監視しておき、更新されたときまたはユーザの発話を契
機としてその旨を通知してもよい。

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

【００６１】本実施形態では、発話特定ブロックを起点
サーバ２０において共用したが、それぞれの専門サーバ
に発話特定ブロックと応答ブロックの双方をおいてもよ
い。この構成では、自身の担当する専門分野について、
ユーザ発話集とエージェント行動集の双方を独自に管理
することができるので、エージェントの管理やメンテナ
ンスが容易である。この場合においても、全ての発話を
処理することができる中核的な役割を担うサーバをおい
てもよい。

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

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

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

【００６５】実施の形態では、ローカルエージェント１
５２とおしゃべりエージェント１５６の画像を一致させ
たが、当然それに限る必要はない。また、ローカルエー
ジェント１５２をユーザ端末１２に実装することはや
め、起動時に現れる「処理開始エージェント」のような
ものを起点サーバ２０に実装しておいてもよい。

【００６６】実施の形態では、お気に入り登録部８０、
お気に入りデータ８２、およびキャラクタ管理部８４を
専門サーバにおいたが、これらを起点サーバ２０にて一
括管理してもよい。お気に入りデータ８２をユーザ端末
１２においてもよい。このとき、お気に入りキャラクタ
をローカルエージェントとして機能させてもよい。

【００６７】

【発明の効果】本発明によれば、ユーザが所望する情報
を迅速に提示することができるシステムが実現する。ま
た、ユーザが親しみやすい情報検索環境が実現する。

【図面の簡単な説明】

【図１】実施の形態に係るユーザ支援システムを含む
ネットワークシステムの全体構成図である。

【図２】ユーザ支援システムに含まれる起点サーバの
構成図である。

【図３】起点サーバに含まれるインデックスファイル
の構成図である。

【図４】起点サーバに含まれるユーザ発話集の構成図
である。

【図５】起点サーバに含まれるアクセス情報ファイル
の構成図である。

【図６】起点サーバに含まれる付加インデックスファ
イルの構成図である。

【図７】起点サーバに含まれる付加発話集の構成図で
ある。

【図８】ユーザ支援システムに含まれるグルメサーバ
の構成図である。

【図９】お気に入りデータの内部構成図である。

【図１０】情報検索部を含むページの構成図である。

【図１１】ユーザ支援システムを利用するユーザ端末
の構成図である。

【図１２】ユーザ端末を起動したときに現れるローカ
ルエージェントを示す図である。

【図１３】ユーザが発話したとき現れるおしゃべりエ
ージェントを示す図である。

【図１４】ユーザが餃子店の情報をたずねたとき現れ
るグルメエージェントを示す図である。

【図１５】グルメエージェントが検索結果をユーザに
提示する様子を示す図である。

【図１６】お気に入り登録部が登録を受け付ける画面
を示す図である。

【図１７】キャラクタハウスが表示された画面を示す
図である。

【図１８】グルメエージェントが更新状況を提示する
画面を示す図である。

【符号の説明】

１２ユーザ端末、１６ユーザ支援システム、２
０起点サーバ、２４おしゃべりサーバ、２６
グルメサーバ、３２発話取得部、３４発話検索
部、３６インデックスファイル、３７付加イン
デックスファイル、３８ユーザ発話集、３９付
加発話集、４２通知部、４４アクセス記録部、
６２エージェント行動集、７１キャラクタ表示
部、７７情報検索部、７８自発検索部、８０
お気に入り登録部、８２お気に入りデータ、８
４キャラクタ管理部、１５６おしゃべりエージェ
ント、１６０グルメエージェント。

フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 3/16 ３４０Ｇ０６Ｆ 3/16 ３４０Ｚ (72)発明者松岡継文大阪府守口市京阪本通２丁目５番５号三洋電機株式会社内Ｆターム(参考） 5B075 PP07 PQ02 QS05 5E501 AA02 AB15 AC15 AC33 BA05 CA06 CB15 DA01 EA21 FA14 FA32 FA43

Claims

【特許請求の範囲】

【請求項１】ユーザの発話を想定して作成された電子
的なユーザ発話集を有し、前記ユーザから発話が入力さ
れたときその内容を特定する発話特定ブロックと、前記発話に対する応答を目的とするエージェントの行動
を想定して作成された電子的なエージェント行動集を有
し、前記ユーザの発話に前記エージェントによって応答
せしめる応答ブロックと、前記ユーザが検索を希望する情報の内容を予め取得して
保持する検索内容保持部と、前記情報を検索する情報検索部と、を含み、前記発話特定ブロックはさらに、前記情報検索部が前記
検索を開始すべき発話を想定して作成された付加発話集
を有し、前記ユーザからの発話がその付加発話集に含ま
れるとき、その内容を特定し、前記情報検索部は、前記ユーザが前記付加発話集に含ま
れる発話を行ったことを契機として、前記情報の検索を
開始することを特徴とするユーザ支援装置。
【請求項２】前記情報検索部は、前記情報の検索を自
発的に開始する自発検索部をさらに含むことを特徴とす
る請求項１に記載のユーザ支援装置。
【請求項３】前記情報の属する分野ごとに擬人化され
たキャラクタを対応づけ、前記検索の結果をその情報の
属する分野に対応したキャラクタの発話として前記ユー
ザへ示すキャラクタ表示部をさらに含むことを特徴とす
る請求項１または２に記載のユーザ支援装置。
【請求項４】前記検索内容保持部は、ウェブサイトの
ネットワークアドレスをブックマーク情報として保持す
るブックマーク保持部を含み、前記情報検索部は、前記ウェブサイトの更新状況を取得
することを特徴とする請求項３に記載のユーザ支援装
置。
【請求項５】前記キャラクタ表示部は、前記キャラク
タに対応づけられた分野に属する前記ウェブサイトが更
新されていたとき、そのキャラクタの発話として前記更
新状況を前記ユーザへ提示することを特徴とする請求項
４に記載のユーザ支援装置。
【請求項６】前記キャラクタの属性値を管理し、前記
ユーザの前記キャラクタに対する扱いにより前記属性値
を変化させ、前記属性値に応じて前記キャラクタの行動
を変化させるキャラクタ管理部をさらに含むことを特徴
とする請求項３から５のいずれかに記載のユーザ支援装
置。
【請求項７】前記キャラクタ管理部は、前記属性値に
基づいて、前記キャラクタに対応づけられた分野に属す
る前記ウェブサイトの更新状況を取得する頻度を変更す
ることを特徴とする請求項６に記載のユーザ支援装置。
【請求項８】請求項１に記載のユーザ支援装置を専門
分野に応じて複数設け、それらを異なるノードとしてネ
ットワークに接続し、かつそれらのユーザ支援装置の前記ユーザ発話集、前記
付加発話集、および前記エージェント行動集を、それぞ
れ当該装置の専門分野を中心に形成したことを特徴とす
るユーザ支援システム。
【請求項９】前記ユーザ支援装置は、それぞれ前記応
答ブロックを自ノードに保持する一方、前記発話特定ブ
ロックを前記ネットワークのひとつのノードにおいて共
用することを特徴とする請求項８に記載のユーザ支援シ
ステム。