JP2002175316A

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

Info

Publication number: JP2002175316A
Application number: JP2000373601A
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-07
Filing date: 2000-12-07
Publication date: 2002-06-21
Also published as: US20020073176A1

Abstract

(57)【要約】【課題】ユーザにとっても広告提供主にとってもメリ
ットのある広告の提供技術が求められていた。【解決手段】起点サーバ２０は、ユーザの発話を特定
するための発話特定ブロックを有し、ユーザの発話をユ
ーザ発話集に照合して内容を特定して、応答すべき専門
サーバへ処理をうつす。専門サーバではエージェントが
ユーザの発話に応答する。起点サーバ２０は、特定のス
ポンサーを優遇する処理を実行する契機となる発話を集
めた付加発話集をさらに有し、ユーザの発話がこれに含
まれるとき、スポンサー処理部がスポンサーを優遇する
処理を行う。ユーザがスポンサーに関連した発話をした
ときに広告が表示される。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】インターネットの利用が進むにつれ、そ
の主要なアプリケーションであるＷＷＷ（World Wide W
eb）の利用者が激増し、ＷＷＷのふたつの利用形態、す
なわち情報の発信と検索がユーザに広く浸透した。情報
提供者から発信される情報の量が増えるにつれ、たいが
いの情報はいずれかのＷｅｂサイトのいずれかのページ
にあるという状況が現実になった。自宅にいながらにし
て膨大な量の情報にアクセスできるという利便性によ
り、ユーザの数はさらに増加し続けている。

【０００３】Ｗｅｂサイトを閲覧するユーザの増加に伴
い、Ｗｅｂというメディアに対して大きな広告効果が期
待できるようになった。多くの情報提供者が、自身のＷ
ｅｂサイトや、閲覧者数の多いＷｅｂサイトに広告を掲
載するようになっている。他者のＷｅｂサイトに広告を
掲載した場合には、自身のＷｅｂサイトへのリンクをは
っておくことができるなど、今までのテレビ、ラジオ、
新聞などの広告にはなかった技術が利用できることも大
きな魅力の一つである。

【０００４】

【発明が解決しようとする課題】しかしながら、情報の
発信者および閲覧者のあまりにも急激な増加により、か
えって情報の円滑な利用に支障をきたす事態が発生しつ
つある。閲覧者であるユーザの立場から見ると、膨大な
情報の中から所望の情報を探し出すことが困難になって
きており、あるはずの情報にたどりつけないという状況
が日常化している。コンピュータ利用経験が浅いユーザ
が相当数いる今日では、初心者でも分かりやすく情報を
検索できる技術が必要になっている。

【０００５】また、Ｗｅｂ独自の広告技術も、転送速度
などの問題から必ずしも有効に利用されているとは言い
がたい。利用者の増加にインフラの整備が追いついてい
ない今、画像を利用したバナー広告は表示までに時間が
かかり、ユーザに煩わしさを感じさせてしまう恐れがあ
る。バナー広告をクリックして詳細情報を得ようとする
ユーザの数も多いとは言えず、さらに効率の良い広告技
術が求められていた。

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

【０００７】

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

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

【０００９】「特定の情報提供者」は、たとえば、ユー
ザ支援装置の管理者へ広告の掲載を依頼しその対価を支
払うスポンサー（以下、単に「スポンサー」ともいう）
であってもよい。一つのエージェントに対して、複数の
スポンサーを受け付けてもよい。

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

【００１１】前記スポンサー処理部は、前記情報検索部
の検索結果を前記ユーザへ提示する際に、前記特定の情
報提供者の情報を先頭に表示させる表示順序設定部を含
んでもよい。すなわち、ユーザが所望した情報を検索し
た結果、複数の情報がヒットした場合に、スポンサーと
なっている情報提供者の情報を最上部に表示すること
で、スポンサーの情報を視認しやすくする。

【００１２】前記スポンサー処理部は、前記情報検索部
の検索結果を前記ユーザへ提示する際に、前記特定の情
報提供者の情報を強調表示する表示属性設定部を含んで
もよい。たとえば、色、大きさ、フォントの種類、下線
や影などの文字修飾などの表示属性を他の情報のものと
変えることにより、スポンサーの情報を視認しやすくす
る。スポンサーの情報を枠で囲んだり、「おすすめ」な
どの表示を付加してもよい。

【００１３】前記スポンサー処理部は、前記情報検索部
の検索結果を前記ユーザへ提示する際に、前記特定の情
報提供者の広告を付加して表示させる広告表示部を含ん
でもよい。前記スポンサー処理部は、前記特定の情報提
供者の情報の更新状況を監視し、更新されたときにその
旨を前記ユーザへ通知する更新状況通知部を含んでもよ
い。

【００１４】このユーザ支援装置は、前記スポンサー処
理部が前記優遇する処理を実行したとき、優遇された前
記情報提供者へ課金する課金部をさらに含んでもよい。
スポンサーの情報をユーザへ提示した対価として、その
回数に応じてスポンサーへ課金してもよい。スポンサー
の情報にスポンサーサイトへのリンクをはっておき、ユ
ーザがそれをクリックした回数に応じてスポンサーへ課
金してもよい。

【００１５】このユーザ支援装置は、前記優遇する処理
を実行すべき情報提供者を前記ユーザに設定させるスポ
ンサー設定部をさらに含み、前記スポンサー処理部は、
前記スポンサー設定部により設定された情報提供者に対
して前記優遇する処理を実行してもよい。ユーザ自身に
スポンサーを選択させることで、よりターゲットを絞っ
た広告を提供することができる。

【００１６】このユーザ支援装置は、前記優遇する処理
を実行すべき情報提供者を前記ユーザが設定したとき
に、前記ユーザへ利益を与える利益還元部をさらに含ん
でもよい。たとえば、スポンサー情報が表示された回数
に応じて、スポンサーまたはシステム管理者から金銭ま
たは物品が提供されてもよい。システムを利用するため
の料金を減額してもよい。これにより、ユーザにスポン
サーの設定を促し、より多くのユーザへスポンサーの情
報を提供することができるので、ひいては、スポンサー
のメリットにもなる。

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

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

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

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

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

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

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

【００２４】

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

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

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

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

【００２８】本実施形態のユーザ支援システムでは、そ
れぞれの専門エージェントに対してスポンサー契約をし
た特定の情報提供者（以下、単に「スポンサー」ともい
う）を優遇する処理を行う。たとえば、自動車メーカー
Ａ社がおしゃべりエージェントのスポンサーである場合
に、ユーザがおしゃべりエージェントに対して「今年の
新型車の情報が欲しい」と発話したとする。この発話を
受けて、おしゃべりエージェントはウェブサイトの中か
ら新型車の情報を掲載したページを検索してユーザへ提
示する。このとき、おしゃべりエージェントは、スポン
サーであるＡ社のページが他のページよりも目立つよう
に表示する。表示順序を入れ替えてＡ社のページを先頭
に表示してもよいし、色、フォント、大きさなどの表示
属性を変えて強調表示してもよい。Ａ社のページを枠で
囲んだり、「おすすめ」などの表示を付加してもよい。
このとき、同時にＡ社の広告を表示してもよい。これに
より、ユーザがスポンサーのサイトへアクセスする可能
性が高まるとともに、効率よく広告を提供することがで
きる。

【００２９】本システムは、スポンサーを優遇する処理
を行った対価をＡ社に課金する。検索結果を優先して表
示する処理や広告を表示する処理の回数に応じて課金し
てもよい。スポンサーサイトをユーザが実際に訪れた場
合に課金してもよい。スポンサーはユーザ自身が選択で
きるようにしてもよい。たとえば、おしゃべりエージェ
ントに対してＡ社（たとえばインスタント食品メーカ
ー）、Ｂ社（たとえば自動車メーカー）、Ｃ社（たとえ
ばレストラン）がスポンサーとなっているときに、ある
ユーザはＡ社をスポンサーとして設定し、別のユーザは
Ｂ社をスポンサーとして設定したとする。このとき、Ａ
社をスポンサーに設定したユーザが「ラーメンが食べた
い」と発話した場合、発話の内容に応じて、Ａ社（イン
スタント食品メーカー）の広告が表示されるが、Ｂ社
（自動車メーカー）、Ｃ社（レストラン）の広告は表示
されない。これにより、ユーザが欲しい情報のみをユー
ザに提示することができる。ユーザがスポンサーを設定
したときに、システム管理者またはスポンサーからユー
ザへ利益が与えられてもよい。たとえば、システムの利
用料金を減額したり、金銭または物品が提供されてもよ
い。

【００３０】上記のようなビジネスモデルは、ユーザ、
スポンサー、およびユーザ支援システムの運営者とい
う、本システムに関与する三者すべてに利益をもたらす
ことができる、いわゆるＷｉｎ−Ｗｉｎ−Ｗｉｎモデル
となりうる。まず、ユーザは、エージェントを利用して
所望の情報を的確に取得することができるとともに、従
来のバナー広告のように常時画面を占有する広告から解
放され、快適にウェブページを閲覧することができる。
関連する発話をしたときにだけ広告が表示されるので、
望まない広告が表示されることに対する抵抗感を軽減す
ることができる。また、スポンサーを設定することによ
り利益が得られ、そのスポンサーの情報を随時取得する
ことができる。

【００３１】スポンサーは、広告したい製品、サービス
などに関連した発話を行ったユーザに対して広告を提供
するので、不特定のユーザに広告を提供するよりも高い
広告効果を期待できる。また、広告を必要としないユー
ザには広告を提供しないので、広告宣伝費の節約につな
がり、高いコストパフォーマンスを実現できる。広告を
表示する契機となる発話を自由に設計することにより、
広告を提供するユーザ層、頻度などを調整することもで
きる。たとえば、「東京の居酒屋をおしえて」と発話し
たユーザに対しては、東京のスポンサーの広告のみを表
示し、他地域の居酒屋の広告を提示しないように設計し
てもよい。ユーザが発話する可能性の高い語を設定して
おくことで、広告提供の頻度を高くすることもできる
し、逆に、ユーザが発話する可能性の低い専門用語を設
定しておくことで、より的を絞った広告を提示すること
ができる。

【００３２】ユーザ支援システムの管理者は、スポンサ
ーから広告収入を得ることができる。バナー広告などの
広告方法にくらべて、的確かつネットワークへの負担の
少ない広告を提示できるので、多くのユーザが集まる可
能性がある。これにより、ユーザのシステム利用料金や
スポンサーの広告提示料金による収入が見込める。

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

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

【００３５】処理開始発話が、ユーザが設定したスポン
サーの付加発話集に含まれていたときは、専門サーバ内
のスポンサー優遇処理を実行するためのページへジャン
プする。そのページでは、スポンサーのウェブページを
強調表示したり、広告を表示するなどの処理が実行され
る。そして、ユーザの次の発話を待つ。

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

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

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

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

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

【００４１】ユーザの発話が付加発話集３９にも含まれ
ていた場合は、その発話に対応する付加発話集３９のフ
ァイルには、スポンサーを優遇する処理を実行するため
のページのＵＲＬが記述されている。ここで、スポンサ
ー情報ファイル５０に格納されたスポンサー設定状況が
参照される。ユーザが該当するスポンサーを登録してい
た場合には、付加発話集３９に記述されたＵＲＬが優先
され、スポンサー優遇処理が実行される。ユーザがその
スポンサーを登録していなかった場合には、ユーザ発話
集３８に記述されたページへジャンプする。このとき、
スポンサーを優遇する処理は実行されない。

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

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

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

【００４５】付加発話集３９には、スポンサーを優遇す
る処理を実行する契機となる発話が格納されている。図
２においては、便宜上、付加発話集３９とユーザ発話集
３８とを別個に示しているが、実際は、付加発話集３９
の内容はユーザ発話集３８に組み入れられ一元化されて
いる。付加発話集３９に格納すべき発話は、スポンサー
自身が設定してもよい。このとき、発話の内容により、
広告を表示する対象ユーザの数や層を調整することもで
きる。図示しないユーザデータベースを設けておき、そ
こに記述されたユーザの属性情報を参照して広告を表示
してもよい。

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

【００４７】スポンサー設定部４８は、ユーザ自身がス
ポンサーを個別に設定するための処理を行う。スポンサ
ー設定部４８は、専門エージェントと契約しているスポ
ンサーをユーザへ提示し、その中でユーザがどのスポン
サーを選択するかを問い合わせる。ユーザが設定したス
ポンサー情報は、スポンサー情報ファイル５０に格納さ
れる。

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

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

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

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

【００５２】図６は、スポンサー情報ファイル５０の内
部記述例である。同図では、あるユーザ「ｕｓｅｒ１」
は、おしゃべりエージェントのスポンサーとして「Ａ
社」と「Ｃ社」を設定しており、グルメエージェントの
スポンサーとして「中華Ａ店」と「レストランＺ」を設
定している。したがって、ｕｓｅｒ１がおしゃべりエー
ジェントと対話しているとき、Ａ社とＣ社の広告は表示
されるが、Ｂ社の広告は表示されない。

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

【００５４】付加発話集３９は、ファイル名欄２０４、
ユーザの発話欄２０２、応答すべき専門サーバのページ
欄２２０を有する。例えば、ユーザ発話「まんじゅう」
に応答する専門サーバのページは「ＵＲＬａ２０３」で
あり、「まんじゅう」という発話と「ＵＲＬａ２０３」
の組がファイルｆ７０２を構成する。ユーザの発話は、
和菓子店Ｄの発話集２１０、中華Ａ店の発話集２１２、
イタリアンレストランＥの発話集２１４など、スポンサ
ーごとに分類されている。付加インデックスファイル３
７と付加発話集３９はファイル名によってリンクされ、
例えば「ぎょうざ」という発話には、付加インデックス
ファイル３７においてファイルｆ８０５が記述され、こ
れが付加発話集３９のファイルｆ８０５を指している。

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

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

【００５７】図１０は、エージェント行動集６２に格納
されたページのうち、スポンサーを優遇する処理を行う
ページの例を示す。ＵＲＬａ２のページ６６の特定処理
実行部７６は、ユーザが所望する情報をインターネット
１４を介して検索する情報検索部７８と、検索結果に対
してスポンサー優遇処理を施すスポンサー処理部８０を
含む。スポンサー処理部８０は、検索結果を並べ替えて
スポンサーの情報を最上部に表示する表示順序設定部８
２と、スポンサーの情報を強調表示する表示属性設定部
８４と、スポンサーの広告を表示する広告表示部８８
と、スポンサーサイトの更新状況を通知する更新状況通
知部８６とを含む。スポンサー処理部８０は、スポンサ
ーデータ９０に格納された情報を参照して、そのスポン
サーの情報をどのように表示するかを決定する。スポン
サー処理部８０により加工された検索結果は、エージェ
ント出力部７０の情報提示部７１によりユーザへ提示さ
れる。

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

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

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

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

【００６２】図１５はそうして移った先のページを示す
画面１５０である。情報検索部７８により取得されたウ
ェブページのタイトル１７０が情報提示部７１により表
示されている。それぞれのタイトル１７０にはリンクが
はられており、当該ページへアクセス可能に構成されて
いる。ここで、ユーザがグルメエージェントのスポンサ
ーとして中華Ａ店を設定しているため、表示順序設定部
８２により、Ａ店のウェブページが先頭に表示されてい
る。また、表示属性設定部８４により、Ａ店のウェブペ
ージのタイトルは太字で表示されている。また、広告表
示部８８は、グルメエージェント１６０による発話の形
で、「Ａ店は、ゆず風味の手作りぎょうざが自慢！お
すすめです。」という内容の広告を表示している。

【００６３】図１６は、グルメエージェント１６０がス
ポンサーの更新状況を通知する画面の例を示す。グルメ
エージェント１６０は、中華Ａ店をスポンサーに設定し
たユーザに対して、中華Ａ店のウェブサイトが更新され
たことを通知している。ユーザが関連する発話を行った
ときに、スポンサーサイトの更新状況を確認し、更新さ
れていれば通知する構成であってもよいし、定期的に更
新状況を監視しておき、更新されたときまたはユーザの
発話を契機としてその旨を通知してもよい。ユーザがス
ポンサーサイトを最後に訪れた日時を記録しておき、そ
れよりも後に更新が行われた場合にそれを通知してもよ
い。最終訪問日時は、起点サーバ２０などのデータベー
スに格納されてもよいし、ユーザ端末１２にクッキー情
報として記録されてもよい。

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

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

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

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

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

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

【００７０】実施の形態では、アクセス情報ファイル４
６やスポンサー情報ファイル５０を起点サーバ２０にお
いたが、これらをユーザ端末１２にクッキー情報として
格納しておいてもよい。

【００７１】実施の形態では、ユーザが個別にスポンサ
ーを設定できる構成としたが、専門サーバを訪れた全て
のユーザに対して同じようにスポンサー情報を提供して
もよい。

【００７２】実施の形態では、発話特定ブロック、応答
ブロックなどの機能をサーバにおいたが、これらの機能
の一部または全部をユーザ端末１２側においてもよい。
たとえば、発話特定ブロックをユーザ端末１２へダウン
ロードしておき、発話解釈をユーザ端末側で行い、応答
ブロックを有するサーバへアクセスするような構成であ
ってもよい。専門エージェントのうちユーザが頻繁に使
うものをユーザ端末１２にダウンロードしておいてもよ
い。これにより、発話解釈およびエージェントの応答処
理のうちの一部または全部をユーザ端末１２側で行うこ
とができるので、迅速な応答が期待できる。このよう
に、サーバとクライアントの間における機能分担は任意
であってよい。

【００７３】

【発明の効果】本発明によれば、ユーザが所望する情報
を的確に提示することができるシステムが実現する。ま
た、情報提供者が効果的な広告をユーザに提供できるシ
ステムが実現する。

【図面の簡単な説明】

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

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

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

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

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

【図６】起点サーバに含まれるスポンサー情報ファイ
ルの構成図である。

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

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

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

【図１０】スポンサー処理部を含むページの構成図で
ある。

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

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

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

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

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

【図１６】グルメエージェントがスポンサーサイトの
更新状況を通知する様子を示す図である。

【符号の説明】

１２ユーザ端末、１６ユーザ支援システム、２
０起点サーバ、２４おしゃべりサーバ、２６
グルメサーバ、３２発話取得部、３４発話検索
部、３６インデックスファイル、３７付加イン
デックスファイル、３８ユーザ発話集、３９付
加発話集、４２通知部、４４アクセス記録部、
６２エージェント行動集、８０スポンサー処理
部、８２表示順序設定部、８４表示属性設定
部、８６更新状況通知部、８８広告表示部、
１０４ファイル名、１２０応答すべき専門サーバ
のページアドレス、１３２ローカルエージェント出
力部、１５２ローカルエージェント、１５６お
しゃべりエージェント、１６０グルメエージェン
ト。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 17/60 ３３８Ｇ０６Ｆ 17/60 ３３８５０２５０２ (72)発明者松岡継文大阪府守口市京阪本通２丁目５番５号三洋電機株式会社内Ｆターム(参考） 5B075 PP07 PQ02 PQ22 PQ32 PQ75

Claims

【特許請求の範囲】

【請求項１】ユーザの発話を想定して作成された電子
的なユーザ発話集を有し、前記ユーザから発話が入力さ
れたときその内容を特定する発話特定ブロックと、前記発話に対する応答を目的とするエージェントの行動
を想定して作成された電子的なエージェント行動集を有
し、前記ユーザの発話に前記エージェントによって応答
せしめる応答ブロックと、複数の情報提供者が提供する情報の中から前記ユーザが
所望した情報を検索する情報検索部と、前記情報提供者のうち特定の情報提供者を優遇する処理
を行うスポンサー処理部とを含み、前記発話特定ブロックはさらに、前記優遇する処理を実
行する契機となる発話を想定して作成された付加発話集
を有し、前記スポンサー処理部は、前記ユーザの発話がその付加
発話集に含まれるとき、前記優遇する処理を開始するこ
とを特徴とするユーザ支援装置。
【請求項２】前記付加発話集に盛り込むべき内容を前
記ユーザ発話集に組み入れることによりそれらを前記ユ
ーザ発話集に一元化したことを特徴とする請求項１に記
載のユーザ支援装置。
【請求項３】前記スポンサー処理部は、前記情報検索
部の検索結果を前記ユーザへ提示する際に、前記特定の
情報提供者の情報を先頭に表示させる表示順序設定部を
含むことを特徴とする請求項１または２に記載のユーザ
支援装置。
【請求項４】前記スポンサー処理部は、前記情報検索
部の検索結果を前記ユーザへ提示する際に、前記特定の
情報提供者の情報を強調表示する表示属性設定部を含む
ことを特徴とする請求項１から３のいずれかに記載のユ
ーザ支援装置。
【請求項５】前記スポンサー処理部は、前記情報検索
部の検索結果を前記ユーザへ提示する際に、前記特定の
情報提供者の広告を付加して表示させる広告表示部を含
むことを特徴とする請求項１から４のいずれかに記載の
ユーザ支援装置。
【請求項６】前記スポンサー処理部は、前記特定の情
報提供者の情報の更新状況を監視し、更新されたときに
その旨を前記ユーザへ通知する更新状況通知部を含むこ
とを特徴とする請求項１から５のいずれかに記載のユー
ザ支援装置。
【請求項７】前記スポンサー処理部が前記優遇する処
理を実行したとき、優遇された前記情報提供者へ課金す
る課金部をさらに含むことを特徴とする請求項１から６
のいずれかに記載のユーザ支援装置。
【請求項８】前記優遇する処理を実行すべき情報提供
者を前記ユーザに設定させるスポンサー設定部をさらに
含み、前記スポンサー処理部は、前記スポンサー設定部により
設定された情報提供者に対して前記優遇する処理を実行
することを特徴とする請求項１から７のいずれかに記載
のユーザ支援装置。
【請求項９】前記優遇する処理を実行すべき情報提供
者を前記ユーザが設定したときに、前記ユーザへ利益を
与える利益還元部をさらに含むことを特徴とする請求項
８に記載のユーザ支援装置。
【請求項１０】請求項１に記載のユーザ支援装置を専
門分野に応じて複数設け、それらを異なるノードとして
ネットワークに接続し、かつそれらのユーザ支援装置の前記ユーザ発話集、前記
エージェント行動集および前記付加発話集を、それぞれ
当該装置の専門分野を中心に形成したことを特徴とする
ユーザ支援システム。
【請求項１１】前記ユーザ支援装置は、それぞれ前記
応答ブロックを自ノードに保持する一方、前記発話特定
ブロックを前記ネットワークのひとつのノードにおいて
共用することを特徴とする請求項１０に記載のユーザ支
援システム。
【請求項１２】前記発話特定ブロックは、前記ユーザ
発話集の内容に対するインデックスを保持するインデッ
クス格納部を有し、前記検索部は、前記ユーザの発話が入力されたとき、前
記インデックス格納部に対して初期的な検索をかけるこ
とを特徴とする請求項１０または１１に記載のユーザ支
援システム。