(57)【特許請求の範囲】
【請求項１】
複数のユーザ端末と、当該ユーザ端末とデータ通信可能なセンタとを備える情報サービスシステムであって、
前記センタは、
前記ユーザ端末から送信される端末側情報を情報データベースに追加すると共に、その端末側情報と前記情報データベースに既に追加されている前記端末側情報とから予測した情報又は抽出した統計的推論規則の少なくとも何れか一方を、前記情報データベースに追加するデータベース構築手段と、
前記ユーザ端末から送信される前記端末側情報に検索要求が含まれる場合、当該端末側情報に含まれる検索情報を利用し、前記検索要求に対する情報を前記データベース構築手段にて構築された情報データベースから検索する検索手段と、
該検索手段にて検索された情報を配信情報として配信する配信手段とを備えており、
一方、前記ユーザ端末は、
ユーザからの情報を入力する入力手段と、
前記ユーザが置かれている状況の情報を検出する状況検出手段と、
前記入力手段にて入力された情報及び前記状況検出手段にて検出された状況情報を少なくとも含む前記端末側情報を生成する端末側情報生成手段と、
該端末側情報生成手段にて生成された前記端末側情報に基づき、サーバが検索を行う際に必要な検索情報を決定し、その決定した検索情報を検索要求と共に前記端末側情報へ付加した後、前記センタへ送信する送信手段と、
前記端末側情報生成手段にて生成された端末側情報を記憶する記憶手段と、
前記センタから配信された配信情報に基づく報知処理を実行する処理実行手段とを備えており、
前記端末側情報は、前記センタの検索手段が前記検索要求に対する適切な情報を検索する際に必要とされる所定の項目とその項目に対応する情報とで構成され、これらは特定の項目によってまとめられたプロファイルの単位で記憶及び送受信され、
前記ユーザ端末の端末側情報生成手段は、前記記憶手段にプロファイルの単位で記憶された過去の端末側情報に基づき、ユーザが希望する情報であるが前記入力手段にて直前に入力された情報及び前記状況検出手段にて直前に検出された状況情報だけからでは得られない情報である第一の未知の情報を推定し、その推定した情報を加えて前記端末側情報を生成し、
前記センタの検索手段は、ユーザが希望する情報であるが前記ユーザ端末では推定することができない情報である第二の未知の情報を、前記情報データベースに記憶された過去の端末側情報の中から前記送信された端末側情報に類似するものを前記プロファイルの単位でその類似度を計算して選択した端末側情報に基づいて推定し、その推定した情報を検索結果とし、
前記ユーザ端末の処理実行手段は、前記検索手段によって検索された前記第二の未知の情報であって、前記配信情報として前記センタから配信される情報を、前記記憶手段に記憶した端末側情報に追加する情報更新処理をさらに実行すること
を特徴とする情報サービスシステム。
【請求項２】
請求項１に記載の情報サービスシステムにおいて、
前記ユーザ端末は、さらに、
前記入力手段にて入力された情報に基づき、前記端末側情報の所定の項目に優先度を設定する優先度設定手段と、
該優先度設定手段にて相対的に高い優先度が設定された項目に対応する情報が所定条件を満たしていない場合には、当該情報の入力をユーザに促す問合せ手段とを備えていること
を特徴とする情報サービスシステム。
【請求項３】
請求項１又は２に記載の情報サービスシステムにおいて、
前記ユーザ端末が車両に搭載されて用いられることを前提として、
前記センタの検索手段は、前記送信された端末側情報に車両位置の情報が含まれている場合、当該車両位置周辺の風景情報を検索し、
前記配信手段は、前記風景情報を配信情報として前記ユーザ端末へ配信するよう構成されており、
前記ユーザ端末の処理実行手段は、前記配信情報としての前記風景情報に基づき、車両周辺の構造物を推定する構造物推定処理をさらに実行すること
を特徴とする情報サービスシステム。
【請求項４】
請求項３に記載の情報サービスシステムにおいて、
前記センタの検索手段によって検索される前記風景情報は、前記各ユーザ端末から画像情報が前記センタへ送信され、前記センタにて構築された情報であること
を特徴とする情報サービスシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報の検索サービスに係る技術に関する。
【０００２】
【従来の技術】
近年、通信機能を用いた情報サービスシステムが知られている。例えば、ユーザがユーザ端末を操作しセンタとの間にデータ通信可能状態を確立して所定情報の検索を要求すると、センタ側の情報データベースが検索され、検索要求に対する情報がユーザ端末へ配信されるという具合である。
【０００３】
【発明が解決しようとする課題】
しかしながら、このような従来の情報サービスシステムには、次のような問題点があった。
▲１▼所望の情報を検索するために例えばキーワードを検索条件としてユーザ端末からセンタへ情報検索を要求することが考えられるが、本当に望んでいる情報を検索するためには、多くのキーワードを入力する必要があり、検索条件の設定が困難であった。
【０００４】
▲２▼センタでは、情報データベースの構築に多大な労力を必要とするため、情報料が比較的高くなってしまう。
▲３▼センタの情報データベースに短時間で変化する動的な情報が多くなればなるほど、リアルタイムに情報データベースを更新していくことが難しい。
【０００５】
本発明は、このような問題点を解決するためになされたものであり、検索条件の設定を簡潔にし、また、リアルタイム性も確保しつつ、検索要求に対する情報を低コストで利用者へ提供することを目的とする。
【０００６】
【課題を解決するための手段及び発明の効果】
上述した目的を達成するためになされた請求項１に記載の情報サービスシステムは、複数のユーザ端末と、当該ユーザ端末とデータ通信可能なセンタとを備える。本システムにおけるユーザ端末は、固定的に設置されて使用されるものであってもよいが、特にモバイル機器として使用されることを想定している。例えば車両に搭載され、周知のナビゲーション機能を有効利用するための情報検索機器として使用されるという具合である。そこで以下では、本システムのユーザ端末が車両に搭載された場合を例に挙げて適宜説明を行う。
【０００７】
ユーザ端末では、入力手段にてユーザからの情報が入力される。入力手段は、ユーザからの情報を音声にて入力する手段であることが考えられる。例えば対話データベースに基づくユーザ端末からの問いかけに応じたユーザの発話情報、例えば「レストランが近くにないか」といった情報が入力されるという具合である。また、入力手段をユーザ端末のキーボード装置として構成すれば、ユーザが当該キーボード装置を用いて情報を入力することも考えられる。
【０００８】
状況検出手段は、ユーザが置かれている状況の情報を検出する。ユーザ端末がナビゲーション装置と共に車両に搭載されている場合には、ユーザが置かれている状況情報として、例えば日時、現在地、目的地、車外温度、車内温度、天候、オーディオ環境、騒音環境などを検出する。
【０００９】
そして、端末側情報生成手段は、入力手段にて入力された情報、及び状況検出手段にて検出された状況情報を少なくとも含む端末側情報を生成する。ここで「少なくとも」としたのは、さらに、ユーザの個人情報、車両の情報などを含む情報を端末側情報として生成することも考えられるためである。
【００１０】
端末側情報が生成されると、送信手段は、生成された端末側情報をセンタへ送信する。
センタでは、複数のユーザ端末から送信される端末側情報が、データベース構築手段によって、情報データベースに追加される。また、その端末側情報と情報データベースに既に追加されている端末側情報とから予測された情報又は抽出された統計的推論規則の少なくとも何れか一方も情報データベースに追加される。なお、データベース構築手段における「予測」や「統計的推論規則の抽出」を行うまでの過程についても、以下では「編集」と言う。例えばユーザ端末が車両に搭載されている場合、各ユーザ端末からの目的地についての情報を編集すれば、その目的地までの経路の渋滞予測を行うことができ、この渋滞予測情報を情報データベースに追加する。また例えば、端末側情報を編集することにより、統計的推論規則を抽出することができる。具体的には、「土曜の午後にはＸＸカフェは混んでいる」や「平日朝７時から１０時にはＺＺ交差点付近は渋滞する」といったものが考えられる。このようにすれば、個々のユーザ端末からの情報だけでなく、それら情報を総合してはじめて得られる情報までもがユーザ端末にて享受できる点で有利である。
なお、情報データベースは、送信された端末側情報だけで構築してもよいが、既存の情報データベースの情報も利用して構築していくのが現実的である。
【００１１】
センタの検索手段は、ユーザ端末から送信される端末側情報に検索要求が含まれる場合、当該端末側情報に含まれる検索情報を利用し、検索要求に対する情報をデータベース構築手段にて構築された情報データベースから検索する。例えば、端末側情報に「レストラン」の検索要求があった場合、端末側情報に現在地、目的地などの情報が含まれていれば、現在地に近く、かつ、目的地への経路上にあるレストランの情報を検索するという具合である。検索手段によって検索された情報は、配信手段により配信情報としてユーザ端末へ配信される。
【００１２】
すると、ユーザ端末の処理実行手段は、センタからの配信情報に基づく報知処理を実行する。
なお、ユーザ端末の送信手段は、端末側情報生成手段にて生成された端末側情報に基づき、サーバが検索を行う際に必要な情報を決定し、その決定した情報を検索要求と共に端末側情報へ付加した後、センタへ送信するようになっている。
【００１３】
またこのとき、センタの検索手段は、検索要求に対する適切な情報を、端末側情報に含まれる情報から推定して検索するようになっている。例えば端末側情報にユーザの発話情報が含まれている場合、その発話内容が「何か食べたい」「暑い」などであれば、冷たいものを食べることのできる店、あるいは、涼しげな雰囲気の店などを検索するという具合である。
【００１４】
本発明の情報サービスシステムでは、センタの備える情報データベースを構築する情報ソースが、複数のユーザ端末となっている。言い換えれば、ユーザ端末から送信される端末側情報に基づいてセンタの情報データベースが構築される。したがって、情報データベースが半自動的に構築されることになり、構築に要する労力が削減される。また、通常、センタ側は情報データベースを構築するにあたり、情報ソースに対して情報料を支払う。そのため、センタからの情報に対して、ユーザは情報料を支払うことになる。本発明では、ユーザ自身が情報ソースとなり情報提供を行うため、センタから獲得した情報に対してユーザが支払う情報料を安価に設定できる。
【００１５】
また、ユーザ端末の情報送信期間を短くすれば、あるいは、ユーザ端末の数が多くなれば、リアルタイムに近い情報データベースの更新が可能となる。
すなわち、本発明の情報サービスシステムによれば、上述した▲２▼及び▲３▼の問題点を解決することができる。
【００１６】
さらに、端末側情報は、入力手段にて入力された情報だけでなく、状況検出手段にて検出された状況情報を少なくとも含むものである。そして、センタではこの端末側情報に応じた情報の検索が行われるため、適切な情報の検索ができる。すなわち、検索要求に対して、検索要求に合致した情報、あるいは、検索要求に合致すると推定される情報を提供することができる。これによって、例えば検索条件として多くのキーワードを入力する必要もなくなる。したがって、本発明の情報サービスシステムによれば、上述した▲１▼の問題点を解決することができる。
【００１７】
また、センタでは、上述したように各ユーザ端末から送信される端末側情報を情報データベースに追加していく。なお、追加する端末情報は、ユーザ端末から送信された情報そのものであってもよいし、送信された情報を加工したものであってもよい。あるいは、その両方を含むものであってもよい。
【００１９】
なお、上述したように本情報サービスシステムでは、各ユーザ端末からの端末側情報に基づき構築された情報データベースを用いて、センタがユーザの検索要求に対する情報を検索する。
そして、端末側情報は、検索要求に対する適切な情報を推定する際に必要とされる所定の項目とその項目に対応する情報とで構成されている。例えば所定の項目として、日時、現在地、目的地、車外温度、車内温度、天候、交通状況、オーディオ環境、騒音環境、ユーザ要求、ユーザ状態、ユーザ指名、ユーザの好きな料理、ユーザの趣味、お気に入りの店、といった項目を設定することが考えられる。このような項目を設定するのは、検索要求がユーザを取り巻く環境や状態に依存するからである。このようにすれば、各ユーザ端末がまちまちの情報を端末側情報として送信する場合に比べ、検索要求に対する適切な情報を正確に推定することができる。また、情報データベースを充実させることができる。なお、これら項目に対応する情報が全て既知であるとは限らないため、未知である場合、その項目に対応する情報は「なし」として生成する。
【００２０】
また、上述したように端末側情報に様々な項目が存在する場合、端末側情報の検索・編集が容易となるような単位で端末側情報を取り扱うとよい。具体的には、所定項目中の特定項目に対応する情報が記載されたプロファイルの単位で、端末側情報を記憶及び送受信することが考えられる。
【００２１】
例えば、日時、現在地、目的地、車外温度、車内温度、天候、交通状況、オーディオ環境、騒音環境の項目に対応する情報が記述される環境・状況プロファイル、ユーザ要求、ユーザ状態の項目に対応する情報が記述される要求・状態プロファイル、ユーザ指名、ユーザの好きな料理、ユーザの趣味、お気に入りの店の項目に対応する情報が記述されるユーザプロファイルを用意し、これらプロファイルの単位で端末側情報を管理することが考えられる。このように特定項目に対応する情報が記載されたプロファイルの単位で端末側情報を記憶しておけば、例えば店に関する情報を検索する場合、「お気に入りの店」の項目に対応する情報が記載されたユーザプロファイルを検索することで対応でき、検索が容易になるという点で有利である。
【００２２】
なお、上述した端末側情報として、どのような情報をどのような単位で管理するかについての具体例は、実施例中に詳述する。
ところで、このように所定の項目に対応する情報にて端末側情報が構成されることを前提とすれば、さらに、ユーザ端末は、端末側情報生成手段にて生成された端末側情報を記憶する記憶手段を備え、ユーザ端末の端末側情報生成手段は、記憶手段に記憶された過去の端末側情報に基づき、ユーザが希望する情報であるが入力手段にて直前に入力された情報及び状況検出手段にて直前に検出された状況情報だけからでは得られない情報である第二の未知の情報を推定し、その推定した情報を加えて端末側情報を生成するようにしてもよい。過去の端末側情報を記憶しておけば、同様の状況下で生成された過去の端末側情報を検索することによって、未知の情報をある程度推定することができる。これによって、ユーザの入力操作を増やすことなく、端末側情報を充実させることができる。
【００２３】
ただし、ユーザ端末という閉じた環境では、端末側情報の中の未知の情報を推定する場合に限界がある。例えば天候情報などは過去の端末側情報を参照して推定しても信頼性が低い。
そこで、次に示す構成を採用することが考えられる。その構成は、センタの検索手段が、送信された端末側情報の項目に対応する情報であって、ユーザが希望する情報であるがユーザ端末では推定することができない情報である第二の未知の情報を検索し、ユーザ端末の処理実行手段が、検索手段によって検索された第二の未知の情報であって、配信情報としてセンタから配信される情報を、記憶手段に記憶した端末側情報に追加する情報更新処理をさらに実行することを特徴とするものである。
【００２４】
上述したように端末側情報生成手段が端末側情報を生成する際、未知の項目を推定するには限界がある。そのため、この構成では未知の項目に対応する情報をセンタ側で検索する。例えば目的地の天候情報が未知である場合、その目的地の近くにある別のユーザ端末から近い過去の時点で送信された情報を検索するという具合である。このようにすれば、たとえユーザが入力手段を介して天候情報を入力しなくても、天候の情報がある程度の信頼性を持って確定できる。
【００２５】
なお、天候の情報が未知である場合は、場所及び時刻によって情報データベースを検索することで、その項目に対応する情報を検索することができる。しかし、ある特定の検索条件で検索できない未知の情報もある。
そこで、センタの検索手段は、情報データベースに記憶された過去の端末側情報の中から、送信された端末側情報に類似するものを選択し、選択した端末側情報に基づいて未知の情報を検索するようにしてもよい。このとき、送信された端末側情報に類似する過去の端末側情報として、複数の端末側情報を選択してもよい。このように類似する端末側情報を選択すれば、特定の検索条件で検索することが困難な未知の情報を推定することができる。
【００２６】
ここで、情報データベースに記憶された過去の端末側情報の中から、送信された端末側情報に類似するものを選択する際、プロファイルの単位でその類似度を計算し、当該計算した類似度に基づき端末側情報を選択することが考えられる。プロファイルの単位で情報を管理すれば、このような類似判断が適切に行えるという点でも有利である。
【００２７】
このように端末側情報の中の未知の情報をセンタ側で推定するようにすれば、ユーザが入力する情報量を少なくでき、また、項目によってはある程度正確な推定が可能となるため、ユーザにとって大変便利である。
ところで、例えば検索要求に対する適切な情報を検索するにあたって、端末側情報の中で重要となる情報とそうでない情報とが存在する。例えばレストランを検索する場合、ユーザの好みの料理や現在地などの情報は重要な情報であるが、ユーザの氏名などの情報は必要でない。そして、このような重要な情報が未知である場合、あるいは、既知であっても信頼性が低い場合などは、結局、検索要求に対する適切な情報が検索できない可能性が高くなる。
【００２８】
そこで、請求項２に示すように、さらに、優先度設定手段と、問合せ手段とを備えるようにユーザ端末を構成することが考えられる。優先度設定手段は、入力手段にて入力された情報に基づき、端末側情報の各項目に優先度を設定する。例えば入力手段を介してユーザからの情報が音声にて入力されるとき、ユーザの発話内容で各項目の優先度を変えることが考えられる。例えばユーザの発話内容が「食事」に関連する場合、上述したようにユーザの好みの料理や現在地などの項目の優先度を相対的に高くする。発話内容によってどの項目の優先度を高くするかについては、予め発話内容と優先度を高くする項目との対応関係を記憶しておけばよい。
【００２９】
そして、問合せ手段は、優先度設定手段にて相対的に高い優先度が設定された項目に対応する情報が所定条件を満たしていない場合、当該情報の入力をユーザに促す。ここで所定条件を満たしていない場合というのは、その項目情報が未知であるとき、動的に変化する情報であるにもかかわらず記載された時刻がかなり以前であるとき、あるいは、その情報の信頼性が低いときなどが該当する。
【００３０】
このような構成を採用すれば、検索条件として重要な項目に対応する情報の信頼性が高くなり、検索要求に対する適切な情報を検索できる可能性が高くなる。この場合、ユーザの入力操作回数は増えるものの、推定された情報であっても信頼性の高いものなどについてはユーザの入力操作が不要であるため、従来のシステムと比較すれば、ユーザの入力操作回数を十分減少させることができる。
【００３１】
なお、情報サービスシステムのユーザ端末が車両に搭載されて用いられることを前提とすれば、センタの検索手段は、送信された端末側情報に車両位置の情報が含まれている場合、当該車両位置周辺の風景情報を検索し、配信手段は、風景情報を配信情報としてユーザ端末へ配信するよう構成し、ユーザ端末の処理実行手段が、配信情報としての風景情報に基づき、車両周辺の構造物を推定する構造物推定処理をさらに実行するようにしてもよい（請求項３）。
【００３２】
車両前方の走行環境をレーダやカメラで取得する技術が提案・実現されているが、現状の認識技術では人や車などとそれ以外の物体を判別することが困難である。したがって、センタから風景情報を配信することによって、この風景情報に基づいて車両周辺の環境を適切に推定することが可能となる。なお、風景情報には、風景を構成するオブジェクト間の関係情報や、３次元データで示される風景構造の情報を用いることが考えられる。
【００３３】
このようなセンタの検索手段によって検索される風景情報は、ユーザ端末から画像情報がセンタへ送信され、センタにて構築された情報であるとよい（請求項４）。このようにすれば、風景画像などを取得するカメラなどを路上等に大量に設置する必要がない。その結果、通常、カメラなどが設置されることのない過疎地域の情報収集も、ユーザ端末を搭載した車両がその地域にあれば可能となる。また、密集地域では、建物などの建造あるいは取り壊しによって風景が比較的短時間のうちに変化していくが、各ユーザ端末からの画像情報を収集すれば、風景情報をリアルタイムに更新することができる。
【００３４】
【発明の実施の形態】
以下、本発明を具体化した一実施形態を図面を参照して説明する。
図１及び図２は、実施例の情報サービスシステムを示す機能ブロック図である。図１は、センタ１０の構成を示すものであり、一方、図２はユーザ端末２０の構成を示すものである。センタ１０及びユーザ端末２０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏなどを備えたコンピュータシステムとして実現される。
【００３５】
本実施例の情報サービスシステムにおいて、ユーザ端末２０は、車両に搭載され、図示しないナビゲーション装置と接続され情報検索のために用いられる。センタ１０とユーザ端末２０とは無線回線網を含む情報通信網（不図示）で接続され、ユーザ端末２０は、いわゆるモバイルの環境でセンタ１０とデータ通信可能になっている。
【００３６】
最初に図１に基づいてセンタ１０を説明する。
センタ１０は、通信ブロック１１と、プロファイル記憶・編集ブロック１２と、プロファイル選択ブロック１３と、情報検索ブロック１４と、配信プロファイル生成ブロック１５と、情報データベース１６とを備えている。情報データベース１６は、プロファイルデータベース１６ａ及びコンテンツデータベース１６ｂを備えている。プロファイルデータベース１６ａは、各ユーザ端末２０から送信されるプロファイル情報にて構築されるデータベースであり、各ユーザ端末２０が情報ソースとなっている。一方、コンテンツデータベース１６ｂは、センタ１０側で用意された構築済みのデータベースである。情報ソースはユーザ側と無関係である。コンテンツデータベース１６には、例えばレストラン、観光地、遊園地などの各種情報が記憶されている。
【００３７】
通信ブロック１１は、複数のユーザ端末２０とデータ通信を行うためのインターフェース装置である。センタ１０は、この通信ブロック１１を介して、ユーザ端末２０との間にデータ通信可能状態が確立されると、そのユーザ端末２０との間でデータ通信を行う。なお、図１及び図２では、通信ブロック１１を介して３台のユーザ端末２０がセンタ１０とデータ通信可能な状態となっている。ユーザ端末２０は、３台に制限されるものではない。通信ブロック１１は、各ユーザ端末２０からの検索要求及びプロファイルの単位で送信されてくるプロファイル情報を受信する。また、検索結果、情報、制御データを各ユーザ端末２０へ配信する。
【００３８】
プロファイル記憶・編集ブロック１２は、各ユーザ端末２０からのプロファイル情報を、プロファイルデータベース１６ａへ追加記憶する。プロファイル情報の記憶は、特定項目に対応する情報が記述されたプロファイルの単位で実行される。プロファイルについては後述する。また、送信されてくるプロファイル情報を編集し、プロファイル情報から新たな情報を抽出し、当該情報もプロファイルデータベース１６ａへ記憶する。
【００３９】
プロファイル選択ブロック１３は、送信されてきたプロファイルに類似する過去のプロファイルを選択する。この選択は、プロファイルの類似度を計算することで行われる。この類似度は、プロファイル間に後述する「距離」を定義し、この距離が小さいか大きいかで判断する。
【００４０】
情報検索ブロック１４は、プロファイルデータベース１６ａを用い検索要求に対する情報を検索したり、プロファイル選択ブロック１３にて選択されたプロファイルに基づいて、送信されたプロファイル情報の中の未知の情報を推定したりする。また、コンテンツデータベース１６ｂを用い検索要求に対応する情報を検索することも可能である。
【００４１】
配信プロファイル生成ブロック１５は、情報検索ブロック１４にて検索された情報を、配信プロファイルとして生成する。上述した通信ブロック１１からは、この配信プロファイルの形式で、検索結果、情報、制御データがユーザ端末２０へ配信されることになる。
【００４２】
次に図２に基づいてユーザ端末２０を説明する。なお、３台のユーザ端末２０は同様の構成であるため、１台のユーザ端末２０の構成のみを図２に示した。
ユーザ端末２０は、音声認識辞書設定ブロック２１と、ユーザインターフェース２２と、プロファイル生成・更新ブロック２３と、環境・状況推定ブロック２３ａと、要求・状態推定ブロック２３ｂと、位置・時刻特定ブロック２３ｃと、個人情報記憶ブロック２３ｄと、プロファイル記憶ブロック２４と、不足情報検出ブロック２５と、検索要求生成ブロック２６と、情報検索ブロック２７と、プロファイルデータベース２７ａと、ローカルコンテンツデータベース２７ｂと、セキュリティチェックブロック２８と、通信ブロック２９と、新規情報取得ブロック３０と、状況検出ブロック３１とを備えている。
【００４３】
ユーザインタフェース２２は、ユーザの発話情報を入力する音声入力装置、及び検索した情報などをユーザへ報知する音声合成装置及び表示装置を備えている。なお、この表示装置は、ナビゲーション装置の地図データを表示するものと共通化してもよい。
【００４４】
そして、ユーザインタフェース２２には、ユーザの発話内容を正しく認識するために、音声認識辞書設定ブロック２１から話題に応じた音声認識辞書が設定される。
プロファイル生成・更新ブロック２３は、各種プロファイルの生成及び更新を行う。
【００４５】
ここで本実施例で用いられるプロファイルについて説明する。
本実施例では、ユーザの環境・状況に関する情報を記述する環境・状況プロファイル、ユーザの要求・状態に関する情報を記述する要求・状態プロファイル、ユーザの個人情報を記述するユーザプロファイル、ユーザ端末２０が搭載される車両の状況を記述する車両状況プロファイルの４つのプロファイルを設定している。
【００４６】
そして、環境・状況プロファイル、要求・状態プロファイル、及びユーザプロファイルに記載された情報が「端末側情報」に相当する。すなわち、この３つのプロファイルがユーザ端末２０からセンタ１０へ送信されることになる。
このようなプロファイルを用いるのは、ユーザが望む情報が、ユーザを取り巻く環境・状況、ユーザの要求・状態、個人の特徴と深くかかわっているためである。
【００４７】
まず環境・状況プロファイルについて説明する。
環境・状況プロファイルには、次に示す項目に対応する情報が記述される。
（１）時間情報                        （２）現在地
（３）目的地                          （４）経由地の数
（５）経由地１、経由地２、・・・      （６）車外温度
（７）車内温度                        （８）エアコン設定温度
（９）自車位置の座標                  （10）自車位置の住所
（11）自車位置の所属地方              （12）自車位置の道路区分
（13）自車位置の道路状態              （14）自車位置の交通環境
（15）自車位置の地理環境              （16）周囲状況
（17）現在地の天候                    （18）目的地の天候
（19）交通状況                        （20）車両周辺状況
（21）運転状態                        （22）移動目的
（23）話題                            （24）乗員構成
（25）オーディオ環境                  （26）会話状況
（27）騒音環境
以下、各項目についての説明を加える。
【００４８】
（１）時間情報
時間情報としては、季節、日時、時間帯の情報が記述される。季節は、春、夏、秋、冬の区分で記述してもよいし、あるいはさらに細かい区分で記述してもよい。例えば夏という区分をさらに初夏、盛夏として記述するという具合である。
【００４９】
日時は、何月何日何時何分何秒という形式で記述される。また、時間帯は、早朝、朝、昼、夕方、夜、深夜の区分で記述される。
（２）現在地  （３）目的地  （５）経由地
現在地、目的地、経由地は、それぞれ住所の形式で記述する。なお、経由地が複数ある場合、経由地は複数記述される。
【００５０】
（４）経由地の数
経由地が複数ある場合に経由地の数が記述される。
（６）車外温度  （７）車内温度  （８）エアコン設定温度
車外温度、車内温度、エアコン設定温度は、温度情報として記述される。エアコン設定温度は、オートエアコンの目標車内温度である。
【００５１】
（９）自車位置の座標  （10）自車位置の住所  （11）自車位置の所属地方
自車位置の座標、自車位置の住所、自車位置の所属地方は、自車位置関連情報として記述される。
自車位置の座標は、ナビゲーション装置の地図データベースにおける、基準区画番号、Ｘ座標、Ｙ座標で記述される。自車位置の住所は、都道府県、市町村まで記述される。自車位置の所属地方は、北海道、東北、関東、甲信越、東海、北陸、近畿、中国、四国、九州、沖縄の区分で記述される。
【００５２】
（12）自車位置の道路区分  （13）自車位置の道路状態  （14）自車位置の交通環境  （15）自車位置の地理環境  （16）周囲状況
自車位置の道路区分、自車位置の道路状態、自車位置の交通環境、自車位置の地理環境、周囲状況が、自車位置環境の情報として記述される。
【００５３】
自車位置の道路区分は、高速道路、有料道路、国道、県道、市町村道、その他の区分で記述される。
自車位置の道路状態は、ドライ、ウェット、積雪、凍結の区分で記述される。また、場合によって、冠水、高潮、落石、崩落の区分、急勾配、長大トンネル、長大橋梁、連続カーブの区分が記述される。
【００５４】
自車位置の交通環境としては、交通規制情報及び交通状況が記載される。交通規制情報は、速度制限、駐車禁止、駐停車禁止、一方通行、転回禁止、はみ出し禁止、追い越し禁止、高さ制限、幅制限、重量制限の区分で記述される。また、交通状況は、順調、混雑、渋滞の区分で記述される。
【００５５】
自車位置の地理環境は、自宅付近、街中、駅前、自宅周辺、目的地周辺、経由地周辺の区分で記述される。
周囲状況は、高速道路、一般道路、目的地、経由地の大区分が記述されると共に、次のような小区分が記述される。
【００５６】
高速道路の場合には、インター入り口、自車合流、自車分岐、SA、PA、合流あり、分岐あり、料金所の区分、及び、左側車線、左から２番目の車線、・・・、追い越し車線の区分が記述される。
一般道路の場合には、左側車線、追い越し車線、交差点、信号、横断歩道、陸橋、ロータリーの区分が記述される。
【００５７】
目的地の場合には、入り口、出口、駐車場といった区分と、ガソリンスタンド、コンビニ、ファーストフード、駅、郵便局、銀行、ＳＡ、ＰＡといった区分が記述される。
経由地の場合には、ガソリンスタンド、コンビニ、ファーストフード、駅、郵便局、銀行、ＳＡ、ＰＡといった区分が記述される。
【００５８】
（17）現在地の天候  （18）目的地の天候
これら天候情報は、晴れ、曇り、小雨、雨、大雨、小雪、雪、大雪、雷、台風、強風、濃霧、その他の区分で記述される。
（19）交通状況
交通状況は、空いている、混んでいる、平均の区分で記述される。
【００５９】
（20）車両周辺状況
車両周辺状況は、自車との相対関係、自車との相対位置、移動方向・移動速度、前方の物体の種別が記述される。
自車との相対関係は、先行、追従、並走、追越、被追越、前方を横切る、停止の区分で記述される。
【００６０】
自車との相対位置は、右、左、前方、後方、その他の区分と、座標値が記述される。
物体の種別は、大型車、小型車、バイク、自転車、歩行者、動物、落下物、その他の区分で記述される。
【００６１】
なお、車両周辺に複数台の車両が存在すれば、そのぞれ複数の区分が記述されることもある。
（21）運転状態
運転状態は、まず大区分に、運転中、停車中、駐車中の区分が記述される。
【００６２】
さらに小区分としてそれぞれ以下の記述がなされる。
運転中である場合、走行速度が、快適な走行、速度オーバー、渋滞、一時停止の区分で記述される。速度オーバーは、例えば、一般道は80km/h以上、高速道は120km/h以上で判定する。また、走行状態が、振動あり、振動無し、Ｇの大中小、その他の区分で記述される。
【００６３】
停車中である場合、発車前、路側帯停車、その他の区分が記述される。
駐車中である場合、エンジン回転中、エンジン停止、給油中、その他の区分が記述される。
（22）移動目的
移動目的は、行楽、買い物、ドライブ、食事、移動、通勤、通学、スポーツ、送り迎え、病院、その他の区分で記述される。
【００６４】
（23）話題
話題は、目的地、食事、現在地付近、時間、家族、知人・友人、音楽、ナビ、ドライブ、買い物、ゴルフ、スキー、その他の区分で記述される。
（24）乗員構成
乗員構成、すなわち、どの座席にどの様な人が座っているかという詳細な情報は、下記の［］内のように記述される。
【００６５】
［SEAT#ID ，PSTYPE，PATYPE，PTYPE ，PROFILE#ID］
SEAT#ID は、座席（シート）の分類を表すデータであり、SEAT#ID =0が運転席を示し、SEAT#ID =1が助手席を示し、SEAT#ID =2が後部座席を示す。なお、SEAT#ID =0の乗員は、ユーザプロファイルに記述されているユーザを示している。
【００６６】
PSTYPEは、乗員の性別を表すデータであり、PSTYPE=0が荷物や動物などの人間以外を示し、PSTYPE=1が男性を示し、PSTYPE=2が女性を示す。
PATYPEは、乗員の年齢の分類を表すデータであり、PATYPE=0が乳幼児を示し、PATYPE=1が小学生を示し、PATYPE=2が中学生を示し、PATYPE=3が高校生を示し、PATYPE=4が若者を示し、PATYPE=5が一般を示し、PATYPE=6が老人を示す。なお、例えば１９〜２９歳を若者、３０〜６４歳を一般、６５歳以上を老人として分類することが考えられる。
【００６７】
PTYPE は、乗員のタイプを表すデータであり、PTYPE =0が運転者（ドライバ）を示し、PTYPE =1が運転者の配偶者を示し、PTYPE =2が運転者の子供を示し、PTYPE =3が運転者の親を示し、PTYPE =4が運転者の他の家族を示し、PTYPE =5が家族以外の親しい人を示し、PTYPE =6が運転者の知人を示し、PTYPE =7がその他の人を示す。
【００６８】
そして更に、PROFILE#IDは、乗員の氏名或いは名前を表すデータである。
よって、例えば、［SEAT#ID ，PSTYPE，PATYPE，PTYPE ，PROFILE#ID］＝［2 ，1 ，2 ，2 ，○○太郎］の場合には、後部座席に男子小学生であって、運転者の子供である○○太郎が座っていることを表す。
【００６９】
（25）オーディオ環境
オーディオ環境は、１２ビットのデータとして記述される。
bit-0：カセット
bit-1：CD
bit-2：MD
bit-3：DVD
bit-4：FM放送
bit-5：AM放送
bit-6：道路交通センターの放送
bit-7：TV
bit-8：ビデオ
bit-9：電話
bit-10：reserved
bit-11：reserved
上述のように各ビットが割り当てられており、それぞれのビットがセットされているかリセットされているかによってオーディオ環境が記述される。
【００７０】
（26）会話状況
会話状況は、５ビットのデータとして記述される。
bit-0：ドライバーとエージェント間の対話
bit-1：ドライバーと助手席間の会話
bit-2：ドライバーと後部座席間の対話
bit-3：ドライバーの電話
bit-4：その他の会話
上述のように各ビットが割り当てられており、それぞれのビットがセットされているかリセットされているかによって会話状況が記述される。
【００７１】
（27）騒音環境
騒音環境は、車内騒音と、車外騒音がそれぞれ、大、中、小の区分で記述される。
以上が環境・状況プロファイルの項目及び対応する項目値であった。以下に記述例を示す。
【００７２】
0003788111.tif 000002
0003788111.tif 000003
続いて要求・状態プロファイルについて説明する。
【００７３】
要求・状態プロファイルには、次に示す項目に対応する情報が記述される。
（１）日付                            （２）時刻
（３）ユーザ識別名                    （４）現在要求
（５）予測要求                        （６）現在状態
（７）予測状態                        （８）移動目的
（９）運転状態                        （10）騒音状況
以下、各項目についての説明を加える。
【００７４】
（１）日付
日付は、yyyy年mm月dd日の形式で記述される。
（２）時刻
時刻は、tt時mm分ss秒で形式で記述される。
【００７５】
（３）ユーザ識別名
ユーザ識別名としては、個人名、番号、パスワードなどで記述される。
（４）現在要求
特願平１０−１６２４５７号及び特願平１０−１８４８４０号で開示したメカニズムに基づき、ユーザの現在時刻における要求を推定した結果を記述する。
【００７６】
例えば、ルート探索、ルートガイド、食事、休む、宿泊、駐車場、ショッピング、遊ぶ、歌う、踊る、写真を撮る、ビデオを撮る、メール読み上げ、天候情報、スキー、海水浴、ジョギング、ゴルフ、TVを見る、公園、遊園地、テーマパーク、ボーリング、インターネット、電話をかける、窓をあける、エアコンをつける、音楽を聴く、その他の区分で記述される。
【００７７】
（５）予測要求
特願平１０−１８４８４０号に開示したメカニズムに基づき、ユーザの未来時刻における要求を予測した結果を記述する。
（６）現在状態  （７）予測状態
例えば、平常、元気はつらつ、快適、ドライブを楽しんでいる、空腹、食事中、音楽鑑賞中、TVその他鑑賞中、満腹、疲労、帰りたい、遊びたい、早く目的地に着きたい、休憩中、いらいらしている、あせっている、怒っている、気が沈んでいる、落ち込んでいる、眠いの区別で記述される。
【００７８】
要求と状態とを記述するのは、ユーザの状態から要求が発生することが多く、状態を情報として持つことにより、要求の推定が容易になるからである。例えば、帰りたい、遊びたいという状態は、そのまま要求として捉えることもできるが、怒っている、空腹、いらいらしている、などはそのまま要求として捉えることができない点で要求と状態とを別に情報として持つのである。また、現在要求、現在状態の情報が分かれば、予測要求、予測状態を推定することも可能である。この予測要求、予測状態は、未来のどの時点を予測した情報であるかを明示するために、日時を記載するようにする。
【００７９】
（８）移動目的
移動目的は、行楽、ショッピング、食事、旅行、無目的、所用、通勤、業務、憂晴し、その他の区分で記述される。
以上が要求・状態プロファイルの項目及び対応する項目値であった。以下に記述例を示す。
記述例
日付            ：yyyy/mm/dd
時刻            ：hh:mm:ss
ユーザ識別      ：  愛知太郎
現在要求        ：  食事の準備
予測要求        ：  公園(19981018-14:00),買い物（19981018-15:00）
現在状態        ：  空腹の準備
予測状態        ：  空腹（19981018-12:00）
移動目的        ：  行楽, ショッピング, 食事
運転状態        ：  快適
続いてユーザプロファイルについて説明する。
【００８０】
ユーザプロファイルには、次に示す項目に対応する情報が記述される。
（１）氏名                            （２）年令
（３）住所                            （４）家族
（５）職業                            （６）役職
（７）好きな料理                      （８）趣味
趣味には、スポーツ、音楽などの分類だけでなく、スポーツの種類、音楽のジャンルまでが記載される。以下にその記述例を示す。
【００８１】
氏名      ：平成太郎
年令      ：34
住所      ：○○市○○町○丁目○番地
家族      ：妻、娘１人、息子1人
職業      ：会社員
役職      ：主任
好きな料理：中華料理、和食
趣味      ：旅行、ドライブ、スポーツ（テニス、ジョギング、スキー）、音楽（歌謡曲、フォーク、クラシック）
続いて車両状況プロファイルについて説明する。
【００８２】
車両状況プロファイルには、次に示す項目に対応する情報が記述される。
（１）走行状態                        （２）イグニッション
（３）車室内イルミネーション          （４）ライト
（５）エアコン                        （６）AT Position
（７）バッテリー                      （８）燃料
（９）ブレーキ                        （10）走行距離
（11）速度、回転数                    （12）オイル交換時期
（13）車検時期                        （14）定期点検時期
（15）窓の開閉状態                    （16）シートベルト
（17）トランクの開閉
走行状態は、走行中、停車中の区分で記述される。また、イグニッション、車室内イルミネーション、ライト、エアコンの情報はオン・オフの情報で記述される。
【００８３】
以上、本実施例で用いられるプロファイルの項目名とその項目に対応する情報である項目値について説明した。
上述した各プロファイルは、ヘッダと、項目レジスタ群とで構成される。
ヘッダとは、記憶時及び送受信時に、どの種類のプロファイルかを特定するためのものである。
【００８４】
一方、項目レジスタは、下記の要素で構成される。
（１）更新時刻
（２）状態フラグ、信頼性ランク
（３）パーミッション
（４）項目名
（５）項目値
（６）情報ソース（発信元）
このうち、項目名および項目値に関しては、上述の通りである。この項目名、項目値の他に、更新時刻、状態フラグ及び信頼性ランク情報、パーミッション、情報ソース（発信元）の情報が各項目毎に割り当てられている。
【００８５】
更新時刻とは、内容を更新した時刻を記述する。
状態フラグとは、項目値が既知であるか否かを判断するためのフラグである。フラグ＝０ならば項目値が未知であることを示し、フラグ＝１ならば項目値が検索されていることを示し、フラグ＝２であれば項目値が既知であることを示す。
【００８６】
信頼性ランクとは、既知となっている情報の信憑性をランクで示すものであり、この信頼性のランクは、動的な情報であれば時間と共に変化する。本実施例では、センタ側で計算する。
パーミッションは、センターへプライバシー情報を誤って送信しないようにするための情報であり、主にユーザプロファイルの項目に対して設定される。このパーミッション情報は１ビットのデータで記述され、ビット＝０であれば送信不可、ビット＝１であれば送信許可となっている。
【００８７】
例えば、ユーザプロファイル中で下記のように記述されているとする。
好きな食べ物：１：  ステーキ、中華料理
家族構成    ：０：  妻、長女、長男
目的地      ：１：  愛知青少年公園
この場合、家族構成はセンターに送信されない。
【００８８】
情報ソースとしては、情報を提供者、発信元などが記述される。
以上、各種プロファイルのデータ構造について詳述した。
ここで図２に示したユーザ端末２０のプロファイル生成・更新ブロック２３の説明に戻る。
【００８９】
プロファイル生成・更新ブロック２３では、上述した４つのプロファイルを生成する。しかし、上述したプロファイルの各項目値が全て既知となっているわけではない。
そこで、プロファイル生成・更新ブロック２３は、プロファイルデータベース２７ａに記憶された過去のプロファイルを参照して未知の項目値を可能な限り推定する。このとき、環境・状況プロファイルの項目値を推定するのが環境・状況推定ブロック２３ａであり、要求・状態プロファイルの項目値を推定するのが要求・状態推定ブロック２３ｂである。また、位置・時刻特定ブロック２３ｃは、図示しないナビゲーション装置からの情報によって車両位置、及び時刻を特定する。さらに、個人情報記憶ブロック２３ｄにはユーザの個人情報が予め記憶されており、これを基にして上述したユーザプロファイルが生成される。また、プロファイル生成・更新ブロック２３には、車両に搭載された各種センサ等からの情報が状況検出ブロック３１を介して入力されるようになっている。この情報に基づいて環境・状況プロファイル及び車両状況プロファイルが生成される。
【００９０】
また、プロファイル生成・更新ブロック２３には、センタ１０から送信される情報が新規情報取得ブロック３０から入力されるようになっており、この情報に基づいてプロファイルを更新する。
プロファイル記憶ブロック２４は、生成又は更新されたプロファイルをプロファイルデータベース２７ａに記憶する。これによって、過去に記述されたプロファイル情報がユーザ端末２０内で再利用できる。
【００９１】
不足情報検出ブロック２５は、プロファイルの未知の項目の中で、検索要求を生成するのに必要な項目を不足情報として検出する。不足情報があれば、ユーザインタフェース２２を介してユーザへの問合せが行われ、プロファイル生成・更新ブロック２３が、ユーザインタフェース２２を介して入力されたユーザの発話情報に基づいて、不足情報を確定してプロファイルの更新を行う。
【００９２】
検索要求生成ブロック２６は、プロファイル情報に基づいて検索要求を生成する。検索要求生成ブロック２６は、センタ１０へ送信する検索要求と、ユーザ端末２０内での検索に用いる検索要求の両方を生成可能となっている。
情報検索ブロック２７は、検索要求生成ブロック２６にて生成された検索要求に基づき、プロファイルデータベース２７ａ及びローカルコンテンツデータベース２７ｂを用いて検索要求に対する情報の検索を行う。
【００９３】
セキュリティチェックブロック２８は、上述したプロファイルのパーミションを参照して送信不可となっているデータを選別する。
通信ブロック２９は、セキュリティチェックブロック２８からのプロファイル情報及び検索要求生成ブロック２６からの検索要求をセンタ１０へ送信する。また、通信ブロック２９は、センタ１０からの検索結果、情報、制御データを受信する。受信した情報は、新規情報取得ブロック３０によって、編集され、ユーザインタフェース２２、プロファイル生成・更新ブロック２３、ローカルコンテンツデータベース２７ｂへ送信される。例えば検索結果は、ユーザインタフェース２２へ送信され報知される。また、受信した情報によってローカルコンテンツデータベース２７ｂが更新される。
【００９４】
次に、本実施例の情報サービスシステムの動作を説明する。
最初にセンタ１０にて実行されるセンタ側処理を、図３のフローチャートに基づき説明する。
まずステップＳ１００において、検索要求、プロファイルを受信する。この処理は、ユーザ端末２０の通信ブロック２９から送信された情報を、センタ１０の通信ブロック１１を介して受信するものである。なお、検索要求は必ずしも存在しない。したがって、ここでは少なくともプロファイルを受信する。受信するプロファイルは、上述した環境・状況プロファイル、要求・状態プロファイル、及びユーザプロファイルの３つのプロファイルである。
【００９５】
続くＳ１１０では、受信したプロファイルを記憶する。各プロファイルは、ユーザ名、日時、場所のヘッダを付けて記憶される。
また、次のＳ１２０では、プロファイル情報を１次情報とした場合に、受信したプロファイル情報を編集し、プロファイル情報に基づく２次情報を抽出する。そして、このような２次情報もプロファイルデータベース１６ａに追加される。
【００９６】
このように複数ユーザのプロファイルを編集することにより、より完全な事象データベースを自動的に構築することができる。
例えば、多くのユーザからドライブの目的地情報（１次情報）を受信してセンターで編集することにより、混雑（２次情報）を予測することができる。このように特定の情報を編集すれば、既存の天気情報で対応できない局所的な天候、交通状況、道路状態などの情報をリアルタイムに抽出できる。例えば局所的な天候情報を２次情報として抽出する場合、環境・状況プロファイルに記述された場所、時間、現在地の天候、などについての情報を編集する。このとき、天候情報にソース情報を含めるようにしてもよい。ソース情報は、天候情報が、センサ出力に基づく情報であるのか、それともユーザの主観に基づく情報であるのかを区別するものである。例えば、ソース情報が「１」であれば人間の評価に基づく情報、ソース情報が「０」であればセンサ出力に基づく情報として取り決めておけば、ユーザの主観がどれくらい含まれる情報であるかということまで分かる。同様に、交通状況であれば、環境・状況プロファイルに記述された、場所、時間、交通状況などの情報を編集する。道路状況であれば、環境・状況プロファイルに記述された、場所、時間、道路状況などの情報を編集する。
【００９７】
なお、２次情報として、統計的推論規則などを抽出することも考えられる。例えば、「土曜の午後にはＸＸカフェは混んでいる」、「平日朝７時から１０時にはＺＺ交差点付近は渋滞する」、「ｙｙｙスカイラインのｘｘｘ地点の道路状態は滑り易い」などの情報が抽出されるという具合である。
【００９８】
また、各情報には信頼性のランク付けを行う。ランク付けは、情報提供者の信頼性、及び情報の元になったデータの信頼性を総合的に判断して行う。例えば情報提供者の信頼性は、過去の時点で送信されたユーザプロファイルのユーザＩＤに基づき、情報の提供実績回数が多いか否かで判断する。データの信頼性は、ある場所に関する天候情報などを知りたい場合、その場所に近い場所のデータであるか、あるいは、知りたい時刻に近い時刻のデータであるかなどから判断する。
【００９９】
ところで、センタ１０にはユーザ端末２０からの情報が蓄積されていくが、センタ１０の記憶容量に応じて蓄積期間が予め設定されているものとし、古くなった情報は順に削除される。
なお、Ｓ１１０及びＳ１２０の処理が、上述したプロファイル記憶・編集ブロック１２における処理に相当する。
【０１００】
続くＳ１３０では、検索要求があるか否かを判断する。つまり、プロファイル情報と共に検索要求を受信したか否かを判断する。ここで検索要求があると判断された場合（Ｓ１３０：ＹＥＳ）、Ｓ１４０へ移行する。一方、検索要求がないと判断された場合（Ｓ１３０：ＮＯ）、Ｓ２００へ移行する。
【０１０１】
Ｓ１４０では、検索要求に対する情報の検索を行う。この検索処理は、プロファイルとして送信された情報を利用し、プロファイルデータベース１６ａを用いて行われる。
プロファイルデータベース１６ａを用いた検索には、時間による検索、場所による検索、天候情報の検索、要求による検索などが考えられる。
【０１０２】
時間による検索では、さらに、特定メンバー（例えば知人など）のプロファイルに決めて検索したり、検索対象を決めて検索することが考えられる。例えば複数台の車を使ってドライブにいく場合に、ある友人が今どの地点を走行しているのかを検索することが考えられる。また、時間的にどこのレストランが混雑しているのかを検索することができる。
【０１０３】
場所による検索では、時間と組み合わせて検索することが考えられる。例えば現在時刻の天候、渋滞、道路状況などを検索するという具合である。
天候による検索では、例えば現在時刻の目的地近辺の天候情報を含むプロファイルを検索したり、場所を特定し、過去数年間の同時期のプロファイル群を検索したりするという具合である。後者のような検索を行えば、例えば８月中旬の北海道ｘｘｘは天気が崩れやすいといった統計情報が得られる。
【０１０４】
要求による検索では、人気のあるレストランや行楽地、施設などを検索する。音声認識を用いた検索技術については、特願平１０−１６２４５７号、特願平１０−１８４８４０号、特願平１１−２０３４９号に開示した。
Ｓ１５０では、検索要求に対応する該当情報がプロファイルデータベースにあったか否かを判断する。ここで該当する情報があれば、Ｓ１６０にてその情報を獲得し、Ｓ１８０へ移行する。一方、該当する情報がなければ、Ｓ１７０にてその情報を推定して獲得し、Ｓ１８０へ移行する。該当する情報がない場合とは、例えば検索要求がキーワードで構成されるような場合であって、直接的に対応する情報が検索できない場合をいう。この場合は、単語列を推定することによって、検索要求に対する最適な情報を推定して獲得する。この方法は、特願平１１−２０３４９号に開示した。
【０１０５】
Ｓ１８０では、検索サービスを利用するか否かを判断する。ここでいう検索サービスの対象となるデータベースは、上述したコンテンツデータベース１６ｂである。コンテンツデータベース１６ｂは、情報ソースをユーザ端末２０とするものではないため、プロファイルデータベース１６ａと比べて情報料が高く設定されるのが一般的である。そこで本実施例では、予めユーザ毎にこの検索サービスを利用するか否かの設定をしておく。例えば検索サービスの利用契約をしたユーザＩＤを記憶しておくという具合である。ここで検索サービスを利用する場合（Ｓ１８０：ＹＥＳ）、Ｓ１９０にてコンテンツデータベース１６ｂを用いた検索を行い、検索要求に対する情報があれば獲得する。そして、Ｓ２００へ移行する。一方、検索サービスを利用しない場合（Ｓ１８０：ＮＯ）、Ｓ１９０の検索処理を実行せず、Ｓ２００へ移行する。
【０１０６】
Ｓ１３０で否定判断された場合、Ｓ１８０で否定判断された場合、又はＳ１９０から移行するＳ２００では、送信されたプロファイル中の未知の項目値を特定するため類似するプロファイルを選択する。
類似するプロファイルの選択は、プロファイル間の距離を定義することにより実行する。
【０１０７】
２つの異なるプロファイルＰm、Ｐn間の距離Ｌを次の式で定義する。
Ｌ（Ｐm、Ｐn）＝Σ wi・ｄ(s(i),Aim,Ain)
なお、各変数は以下のようになっている。
【０１０８】
Aij       ：  Pjのs(i)番目の項目の項目値
ｄ(s,a,b) ：s番目の項目について項目値a,b間の距離を定義する関数。
s(i)      ：Pj中のレジスタから選択されたi番目のレジスタの識別番号。
【０１０９】
0003788111.tif 000004
また、上述した和記号Σは、ｎ＝１〜Ｎまでの和を示すものとする。
【０１１０】
つまり、この距離は、活性化されたレジスタの項目値の距離の和として定義されるものである。活性化については後述する。
最初に、自分のプロファイルを検索する場合を考える。
ユーザプロファイルには静的な情報が記述されているが、環境・状況プロファイルや要求・状態プロファイルには、場所や時間に依存する情報が記述される。そこで、センタ１０側に蓄積された自分の過去の類似状況に対応したプロファイルを検索することが考えられる。
【０１１１】
例えばドライブ開始時に過去のプロファイルを検索する際には、ユーザ名が一致することを前提として、曜日の近さ、休日かどうか、年中行事や個人のメモリアルデーの日付が一致するかどうか、日付の近さ、時間帯の近さ、現在地の近さ、目的地の近さ、ドライブ目的の類似性などを用いて距離Ｌを計算し、Lが最も小さいプロファイルを上位３個程度選択するという具合である。これをもとにして未知情報の推定を行う。
【０１１２】
例えば曜日の近さを距離として数学的に記述することを考えると、日曜から土曜までを０から６の数字に対応させ次の式で２つの曜日y1、y2の間の距離DYを計算するようにすればよい。
DY=min(ADY,7-ADY)、ADY=|y1-y2|
なお、日曜日は休日として平日との行動パターンが違っている可能性が高いため、「日曜と火曜、水曜、木曜  の間の距離はDY=10」といった補正を加えてもよい。また、曜日感覚については個人の生活形態が大きく影響するので、現在の曜日y1と検索対象の曜日y2との間の距離関係をすべてマトリクス形式で定義することも考えられる。
【０１１３】
このような距離を計算するために、休日、年中行事・メモリアルデーなどの情報をユーザプロファイルに記述するようにしてもよい。
例えば休日といった場合、個人の生活様式に整合した休日は、勤務先の休み、長期連休、暦の上での休日、記念日、休暇の区分で記述する。また、年中行事・メモリアルデーとしては、日付の決まっている年中行事（クリスマス、祇園祭、正月、など）やメモリアルデー（結婚記念日、子供の誕生日、など）の区分で記述する。年中行事やメモリアルデーに関する距離計算では、当日から１週間前までは小さい距離に設定し、行事が終了してからは次の年の日付までの日数を距離とすることが考えられる。
【０１１４】
上述したような距離計算において、日付に関しては、特に行事の影響を受けない場合は、単純に日付の絶対差を日数で計算する。また、時間帯に関しては、特にスケジュールの影響を受けない場合は、単純に時刻の差を時間数で計算する。現在地に関しては、特に目的地やレジャーポイント、知っている場所（自宅、勤務先、公園、デパートなど）の影響を受けなければ、単純に物理的距離を距離とする。目的地に関しても同様である。ドライブ目的に関して、所定の分類を用意しておき、同一の分類における異なる目的（レジャーにおけるお花見と公園など）は比較的近く、異なる分類に属する目的（通勤とスキーなど）は距離を大きく定義する。
【０１１５】
次に、他人のプロファイルを検索することを考える。
上述した自分のプロファイルの検索結果の適正度があまり高くない（Lが非常に大きく、ある一定のしきい値を超える）場合は、他人のプロファイルを検索することが考えられる。ただし、この場合、ユーザ名の違い（自分と他人の違い）を上記の距離計算に組み入れる。
【０１１６】
続くＳ２１０では、未知情報を推定する。例えば目的地の天候が未知の情報である場合、次のようにして天候情報を推定する。
上述したように天候情報は、快晴、晴れ、曇り、小雨、雨、大雨、・・・という区別で記述されるが、最初に天気の良さを示す「１」〜「１０」までの自然数（天候レベル）に変換する。ここでは数字が大きくなるほど天気が良いことを示す。例えば「快晴」であれば「１０」、強風や大雨であれば「１」という具合である。
【０１１７】
そして、目的地Ａ１の天候が知りたい場合、類似したプロファイルを選択した結果、次の情報が記述されたプロファイルが検索されたとする。
ユーザR1        ：K1地点、    晴れ、15:20
ユーザR2        ：K2地点、    快晴、13:20
ユーザR3        ：K3地点、    曇り、15:50
また、センタ１０側で収集された情報として
気象台お天気情報：○○市全域、晴れ、14:30
が存在するとする。
【０１１８】
このとき、次に示す３つの式にて、現在時刻の目的地Ａ１の天候情報を推定する。１つ目の式の左辺Ｌが目的地の天候レベルを示す。
L=AINT（RL）
RL ＝  （1/P）Σ f(ｔ-tn)・Cn・E(A1,Kn)・Ln
P  ＝          Σ f(ｔ-tn)・Cn・E(A1,Kn)
ｔ      ：現在時刻
tn      ：ユーザRnから情報を得た時刻。
【０１１９】
AINT(Ｘ)：Ｘの最も近い整数
N       ：情報提供のあったユーザの数
f(ｘ)   ：時間ｘについての単調減少関数。F(0)=1,f(∞)=0であり、提供データの新鮮度に対応する。
【０１２０】
Cn      ：ユーザRnの提供する情報の信憑性。１から０の値を取る。ｎ=0は気象台に相当し、C0=1。
E(a,b)  ：a地点の情報をｂ地点の情報で代用する場合の確信度。
Ln      ：ユーザRnからの天気情報のレベル値。
【０１２１】
上述した和記号Σは、ｎ＝０〜Ｎの和を示すものとする。
続くＳ２２０では、配信プロファイルを記述する。配信プロファイルには、上述した検索結果、推定した未知情報、プロファイル情報の編集によって得られた新しい情報（２次情報）、制御データが記述される。制御データとは、新しい情報に基づく報知を行うためのデータであることが考えられる。
【０１２２】
次のＳ２３０では、配信プロファイルを生成する。ここではＳ２２０にて記述された配信プロファイルにヘッダ情報など送信のためのデータを付け加えたプロファイルを生成する。
なお、上述したＳ１４０，Ｓ１９０，Ｓ２１０の処理が情報検索ブロック１４における処理に相当し、Ｓ２００の処理がプロファイル選択ブロック１３における処理に相当する。また、Ｓ２２０及びＳ２３０の処理が、配信プロファイル生成ブロック１５における処理に相当する。
【０１２３】
続くＳ２４０では、配信情報をプロファイルデータベース１６ａへ追加する。配信情報は、検索結果、推定した未知情報などである。これら検索結果や推定した未知情報をプロファイルデータベース１６ａへ追加することによって、情報データベース１６を充実させることができる。
【０１２４】
そして次のＳ２５０では、配信プロファイルをユーザ端末２０へ配信する。この処理は、通信ブロック１１における処理に相当する。
続いてユーザ端末２０にて実行される端末側処理を、図４及び図５のフローチャートに基づき説明する。
【０１２５】
まずステップＳ３００において、プロファイルの初期設定を行う。上述したように各プロファイルには、特定項目に対応する項目値が記述される。ここでは、このような情報を記述するための空のプロファイルを用意する。具体的には、各プロファイルを記述するための領域をメモリ上に確保する。
【０１２６】
続くＳ３１０では、音声認識辞書の設定を行う。後述するようにユーザ端末２０では、未知の情報の中で検索に必要なものについてはユーザへ問い合わせる処理を行う。そこで、この問合せ処理に対応してユーザが発話するだろうと予測される内容を認識し易い辞書を設定する。音声認識辞書は、図２に示した音声認識辞書設定ブロック２１に記憶されている。
【０１２７】
次のＳ３２０では、ユーザ入力を受け付ける。この処理は、ユーザインタフェース２２を介してユーザの発話情報を取り込むものである。
続くＳ３３０では、個人情報の記憶を参照する。上述したようにユーザ端末２０の個人情報記憶ブロック２３ｄには、予め個人情報が記憶されている。そこで、この個人情報を読み出す。なお、個人情報が複数ある場合、例えば処理開始以前に暗証番号や氏名を入力させて特定する。
【０１２８】
また、続くＳ３４０では、環境・状況の推定を行う。この処理は、環境・状況プロファイルの未知の項目を推定するものであり、環境・状況推定ブロック２３ａにおける処理に相当する。
同様に、次のＳ３５０では、要求・状態の推定を行う。この処理は、要求・状態プロファイルの未知の項目を推定するものであり、要求・状態推定ブロック２３ｂにおける処理に相当する。
【０１２９】
例えば環境・状況から要求・状態を推定できる。具体的な手法については、特願平１０−１６２４５７号及び特願平１０−１８４８４０号に開示した。例えば、平日の朝であれば、「通勤、急いでいる」という状態が推定できる。また、休日の昼であれば、「ショッピング」、「行楽」という要求が推定できる。同様に、平日、仕事帰りの深夜であれば「疲れている、早く帰りたい」、長期連休、家族で泊りがけのドライブであれば「うれしい、楽しみ、忘れ物はないか、天気は」などといった要求・状態が推定できる。
【０１３０】
続くＳ３６０では、位置・時刻の特定を行う。この処理は、ナビゲーション装置の機能を用いて、車両位置及び現在時刻を特定するものである。これは、位置・時刻特定ブロック２３ｃにおける処理に相当する。
次のＳ３７０では、ユーザ端末２０のプロファイルデータベース２７ａを参照する。ここでは、プロファイルデータベース２７ａに記憶された過去のプロファイル情報に基づいて、さらにユーザの置かれている環境・状況、ユーザの要求・状態などを推定する。
【０１３１】
例えば過去の履歴からユーザ名、現在地名、目的地名、時間などからもっとも近いプロファイルを選択し、そのプロファイルの項目値を転写する。
そして、次のＳ３８０では、プロファイルを更新（生成）する。この処理が、図２中のプロファイル生成・更新ブロック２３における処理に相当する。続いてＳ３９０では、ユーザ端末２０のプロファイルデータベース２７ａに、生成又は更新したプロファイルを記憶する。この処理は、図２中のプロファイル記憶ブロック２４における処理に相当する。
【０１３２】
続くＳ４００では、ユーザの発話内容に応じて、各プロファイルの項目レジスタの活性化レベルを決定する。活性化とは、特定の項目を重要必須項目として設定することを意味する。活性化する項目レジスタとそのレベルは、予め用意されているテーブルに基づいて決定する。したがって、このテーブルには、話題内容と、活性化する項目レジスタ及びその活性化レベルとが対応させて記述されている。話題内容とは、一例として「食事」、「交通」、「行楽」などといった単位で記述される。そして、話題内容「食事」に対しては、環境・状況プロファイルの時間情報、現在地、目的地、経由地といった項目が活性化する項目として記述されている。活性化レベルは、活性化する項目に対してレベル１〜３の３段階で記述される。レベル１は話題に直接的に対応する項目を示し、レベル２は話題の展開に必要な項目を示し、レベル３はドライブの支援に必要な項目を示す。
【０１３３】
次のＳ４１０では、実際にプロファイルの項目レジスタに対し、活性化を行い、活性化する項目レジスタに対しレベル１〜３を設定する。そして、続くＳ４２０では、レベル１が設定された項目に対応する項目値の中で所定条件を満たさないものを、不足情報として検出する。所定条件を満たさないものとは、項目値が未知である、きわめて情報が古い、確信度が極めて低い、といったものが該当する。
【０１３４】
なお、Ｓ４００〜Ｓ４２０までの処理が不足情報検出ブロック２５における処理に相当する。
次のＳ４３０では、検索処理を実行するか否かを判断する。検索処理を実行するか否かの設定は、システム設定メニューにおいて予め切り替え可能となっている。ここで検索処理を実行しない場合（Ｓ４３０：ＮＯ）、Ｓ４４０にて表示・音声出力を行い、Ｓ３１０からの処理を繰り返す。表示・音声出力は、さらにユーザ入力を促すような問いかけを行うものとすることが考えられる。その結果、プロファイル情報が補完される。一方、検索処理を実行する場合（Ｓ４３０：ＹＥＳ）、図５中のＳ４５０へ移行する。
【０１３５】
図５のＳ４５０では、生成・更新したプロファイルに検索要求があるか否かを判断する。検索要求とは、ユーザからの明示的な検索の要求である。上述した図４中のＳ３２０において、例えばユーザが「レストランを探してほしい」や「目的地までの交通状況が知りたい」といった発話をした場合、検索要求と見なされる。ここで検索要求がないと判断された場合（Ｓ４５０：ＮＯ）、Ｓ５３０へ移行する。一方、検索要求があると判断された場合（Ｓ４５０：ＹＥＳ）、Ｓ４６０へ移行する。
【０１３６】
Ｓ４６０では、不足情報があるか否かを判断する。この判断処理は、Ｓ４２０の検出結果に基づいて行われる。つまり、Ｓ４２０で不足情報が検出された場合に肯定判断される。不足情報がある場合（Ｓ４６０：ＹＥＳ）、Ｓ５００にてユーザインタフェース２２を介した不足情報の問合せを行い、その後、図４中のＳ３１０からの処理を繰り返す。一方、不足情報がない場合（Ｓ４６０：ＮＯ）、Ｓ４７０へ移行する。
【０１３７】
Ｓ４７０では、プロファイルデータベース２７ａを用い、検索要求に対応する情報を検索する。また、Ｓ４８０では、ローカルコンテンツデータベース２７ｂの検索を行うための検索要求を生成する。そして、次のＳ４９０では、ローカルコンテンツデータベース２７ｂを用い、検索要求に対応する情報を検索する。
【０１３８】
つまり、Ｓ４７０〜Ｓ４９０の処理はユーザ端末２０内での検索処理である。Ｓ５１０では、通信検索を行うか否かを判断する。すなわちセンタ１０側での検索を行うか否かを判断する。通信検索を行うか否かの設定は、システム設定メニューにおいて予め切り替え可能となっている。ここで通信検索を行う場合（Ｓ５１０：ＹＥＳ）、Ｓ５２０へ移行する。一方、通信検索を行わない場合（Ｓ５１０：ＮＯ）、Ｓ５８０へ移行する。
【０１３９】
Ｓ５２０では、通信検索に用いる検索要求を生成する。
そして、Ｓ５２０から移行する又はＳ４５０で否定判断された場合に移行するＳ５３０では、セキュリティチェックを行う。このセキュリティチェックは、各項目レジスタのパーミッションが「０」として設定された送信不可情報を選別し、送信対象から外す処理である。なお、このＳ５３０の処理が、ユーザ端末２０のセキュリティチェックブロック２８における処理である。
【０１４０】
Ｓ５４０では、Ｓ５２０で生成された検索要求、及びプロファイルを送信する。送信されるプロファイルは、上述したように、環境・状況プロファイル、要求・状態プロファイル、及びユーザプロファイルの３つのプロファイルである。このＳ５４０の送信処理に対応する処理が、図３中のＳ１００の受信処理である。
【０１４１】
Ｓ５５０では、センタ１０からの応答があったか否かを判断する。図３中のＳ２５０の配信処理があると、ここで肯定判断される。ここで応答があった場合（Ｓ５５０：ＹＥＳ）、Ｓ５６０にてプロファイルを受信し、続いてＳ５７０にて情報を取得し、Ｓ５８０へ移行する。一方、応答がない場合（Ｓ５５０：ＮＯ）、Ｓ５６０及びＳ５７０の処理を実行せず、Ｓ５８０へ移行する。なお、Ｓ５４０及びＳ５６０の処理が通信ブロック２９における処理に相当し、Ｓ５７０の処理が新規情報取得ブロック３０における処理に相当する（図２参照）。
【０１４２】
Ｓ５８０では、表示・音声出力を行う。この処理は、Ｓ５７０にて取得した情報に基づき、ユーザへ情報の報知を行うものである。例えば「○○レストランが１ｋｍ先左側にあります。」という具合に検索結果の報知を行うことが考えられる。
【０１４３】
Ｓ５９０では、終了するか否かを判断する。ここでユーザからの終了指示がなければ（Ｓ５９０：ＮＯ）、図４中のＳ３１０へ移行する。一方、ユーザからの終了指示があれば、Ｓ６００へ移行する。
Ｓ６００では受信した情報に基づきプロファイルを更新して、その後、本端末側処理を終了する。このＳ６００の処理は、プロファイル生成・更新ブロック２３における処理に相当する。
【０１４４】
なお、本実施例におけるセンタ１０のプロファイル記憶・編集ブロック１２が「データベース構築手段」に相当し、プロファイル選択ブロック１３及び情報検索ブロック１４が「検索手段」に相当し、配信プロファイル生成ブロック１５及び通信ブロック１１が「配信手段」に相当する。
【０１４５】
そして、図３中のＳ１１０及びＳ１２０の処理がデータベース構築手段としての処理に相当し、Ｓ１３０〜Ｓ２１０の処理が検索手段としての処理に相当し、Ｓ２２０，Ｓ２３０及びＳ２５０の処理が配信手段としての処理に相当する。
また、本実施例におけるユーザ端末２０のユーザインタフェース２２が「入力手段」及び「問合せ手段」に相当し、状況検出ブロック３１が「状況検出手段」に相当し、プロファイル生成・更新ブロック２３が「端末側情報生成手段」に相当し、プロファイル記憶ブロック２４が「記憶手段」に相当し、通信ブロック２９が「送信手段」に相当し、不足情報検出ブロック２５が「優先度設定手段」に相当する。
【０１４６】
そして、図４中のＳ３２０の処理が入力手段としての処理に相当し、Ｓ５００の処理が問合せ手段としての処理に相当する。また、Ｓ３３０〜Ｓ３８０の処理が端末側情報生成手段としての処理に相当し、Ｓ３９０の処理が記憶手段としての処理に相当し、Ｓ５４０の処理が送信手段としての処理に相当し、Ｓ５８０の処理が処理実行手段としての処理に相当する。さらにＳ４１０及びＳ４２０の処理が優先度設定手段としての処理に相当する。
【０１４７】
次に、本実施例の情報サービスシステムが発揮する効果を説明する。なお、ここでの説明に対する理解を容易にするために、従来の問題点を最初に説明する。従来よりユーザ端末を用い、センタにアクセスして情報検索を行うシステムが提案され実現されている。しかしながら、次に示すような問題点があった。
【０１４８】
▲１▼所望の情報を検索するために例えばキーワードを検索条件としてユーザ端末からセンタへ検索を要求することが考えられるが、本当に望んでいる情報を検索するためには、多くのキーワードを入力する必要があり、検索条件の設定が困難であった。
【０１４９】
▲２▼センタでは、情報データベースの構築に多大な労力を必要とするため、情報料が比較的高くなってしまう。
▲３▼センタの情報データベースに短時間で変化する動的な情報が多くなればなるほど、リアルタイムに情報データベースを更新していくことが難しい。
【０１５０】
これに対して、本実施例の情報サービスシステムでは、センタ１０の備える情報データベース１６を構築する情報ソースが、複数のユーザ端末２０となっている。言い換えれば、ユーザ端末２０から送信されるプロファイル情報によってセンタ１０の情報データベース１６が構築される。詳しくは、情報データベース１６のプロファイルデータベース１６ａが追加されていく。したがって、情報データベース１６が半自動的に構築されることになり、構築に要する労力が削減される。また、ユーザ自身が情報提供する。その結果、獲得した情報に対してユーザが支払う情報料は、極めて安価となる。
【０１５１】
また、ユーザ端末２０の情報送信期間を短くすれば、あるいは、ユーザ端末２０の数が多くなれば、リアルタイムに近い情報データベース１６の更新が可能となる。すなわち、本実施形態の情報サービスシステムによれば、上述した▲２▼及び▲３▼の問題点を解決することができる。
【０１５２】
さらに、検索に用いられるプロファイル情報は、ユーザ端末２０のユーザインタフェース２２を介して入力されるユーザの発話情報だけでなく、状況検出ブロック３１を介して入力される状況情報を含むものである。そして、センタ１０ではこのプロファイル情報を用いて情報の検索を行う。したがって、検索要求に対して、検索要求に合致した情報、あるいは、検索要求に合致すると推定される情報を提供することができる。これによって、例えば検索条件として多くのキーワードを入力する必要がなくなる。したがって、本実施例の情報サービスシステムによれば、上述した▲１▼の問題点を解決することができる。
【０１５３】
また、本実施例の情報サービスシステムでは、センタ１０のプロファイル記憶・編集ブロック１２がプロファイル情報を編集し、その編集結果に基づく情報をもプロファイルデータベース１６ａに追加する（図３中のＳ１２０）。これによって、ユーザはユーザ端末２０を介し、より幅広い情報を享受できる点で有利である。
【０１５４】
さらにまた、本実施例の情報サービスシステムでは、ユーザ端末２０のプロファイル生成・更新ブロック２３が４つのプロファイル、すなわち環境・状況プロファイル、要求・状態プロファイル、ユーザプロファイル、及び車両状況プロファイルを生成する（図４中のＳ３８０）。そして、センタ１０へは、環境・状況プロファイル、要求・状態プロファイル、ユーザプロファイルを送信する（図５中のＳ５４０）。これによって、ユーザ端末２０がまちまちの情報を送信する場合に比べ、ある項目についてプロファイルの単位で編集することができる（図３中のＳ１２０）。また、予め定められた所定の項目に対応する項目値をプロファイルに記述するようにしたため、情報データベース１６のプロファイルデータベース１６ａを充実させることができる。
【０１５５】
また、本実施例の情報サービスシステムのユーザ端末２０は、プロファイルデータベース２７ａに記憶された過去のプロファイルを参照して（図４中のＳ３７０）プロファイルを生成する（Ｓ３８０）。また、環境・状況推定ブロック２３ａ、要求・状態推定ブロック２３ｂ、位置・時刻特定ブロック２３ｃ、個人情報記憶ブロック２３ｄからの情報に基づき（Ｓ３３０〜Ｓ３６０）、プロファイルを生成する（Ｓ３８０）。つまり、過去のプロファイルを記憶しておき、同様の状況にあるプロファイルを検索することによって、未知の情報を推定する。これによって、ユーザの入力操作を増やすことなく、プロファイル情報を充実させることができる。
【０１５６】
ただし、ユーザ端末２０という閉じた環境では、プロファイルの中の未知の情報を推定する場合に限界がある。例えば天候情報などは過去のプロファイルを参照して推定しても信頼性が低い。
そこで、本実施例の情報サービスシステムでは、センタ１０のプロファイル選択ブロック１３が情報データベース１６のプロファイルデータベース１６ａに記憶された過去のプロファイルの中で、ユーザ端末２０から送信されたプロファイルに類似するものを選択する（図３中のＳ２００）。そして、情報検索ブロック１４が、選択されたプロファイルに基づき、未知の情報を推定する（Ｓ２１０）。これによって、ユーザ入力のさらなる減少を実現した。
【０１５７】
なお、類似する過去のプロファイルを選択するにあたり、プロファイル間の距離を定義して、距離の小さなプロファイルを選択する。このような距離の計算を実現するという観点からも、本実施例で開示するプロファイルの単位でのデータ管理が有効である。
【０１５８】
このようにプロファイル中の未知の情報をセンタ１０側で推定するようにすれば、ユーザが入力する情報量を少なくでき、また、項目によってはある程度正確な推定が可能となるため、ユーザにとって大変便利である。
さらにまた、本実施例の情報サービスシステムでは、話題内容に応じてプロファイルの項目レジスタを活性化し、レベル１〜３のレベルを設定する（図４中のＳ４００，Ｓ４１０）。そして、検索条件として重要な項目である、レベル１が設定された項目を不足情報として検出する（Ｓ４２０）。そして、不足情報がある場合には（Ｓ４６０：ＹＥＳ）、情報の問合せを行い（Ｓ５００）ユーザからの入力を促す。これによって、検索条件として重要な項目に対応する情報の信頼性が高くなり、検索要求に対する適切な情報を検索できる可能性が高くなる。
【０１５９】
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
（１）上記実施例で示した以外の情報をプロファイルの項目として採用してもよい。また、ユーザが定義した新しい項目をプロファイルの項目に追加できるようにしてもよい。その場合、項目の追加されたプロファイルがあるユーザ端末２０からセンタ１０に送信された場合、追加項目に対する問合せ処理を行う制御データを含めた情報を他のユーザ端末２０へ配信し、他のユーザ端末２０からも同様の情報を集める構成とすることが考えられる。
【０１６０】
上述した項目以外の情報としては、建物や景観、道路環境に関する３次元情報、自動車におけるセンシング情報（道路特性）、ビデオカメラや車載カメラなどで獲得した映像情報などをプロファイル項目として採用することが考えられる。
その場合、例えば特願平９−２９２９６２号に開示される映像データベースと同様に、地図または３次元仮想世界にマッピングされた情報または事象としてセンタ１０上でデータベース化され、ユーザ間で相互に交換されようにする。
【０１６１】
このようにすれば、次に示す環境理解支援を行うことができる。
たとえば、カメラなどで車両前方を撮像して前方の構造物を認識する技術が提案されている。しかし、現状の認識技術では人や車などの対象物とそれ以外の物体を明確に判別することはかなり困難である。そこで、あらかじめ背景となる固定的な環境（ビル、道路、山など）の３次元構造を自己位置に合わせて情報として保持すれば、非常に効率よく対象物を信号処理で認識することができる。したがって、センタ１０から上述したような風景情報を配信してもらうようにすれば、システムの環境理解動作を支援することができる。
【０１６２】
ここでセンタ１０の風景情報データベースは、各ユーザ端末２０にて取得された画像情報に基づき構築するようにしてもよい。このようにすれば、風景画像などを取得するカメラなどを設置する必要がない。その結果、通常、カメラなどが設置されることのない過疎地域の情報収集も、ユーザ端末２０を搭載した車両がその地域にあれば可能となる。また、密集地域では、建物などの建造あるいは取り壊しによって風景が比較的短時間のうちに変化していくが、各ユーザ端末２０からの画像情報を収集すれば、風景情報をリアルタイムに更新していくことができる。
【０１６３】
このような環境理解支援を実現するにあたって、センタ１０とユーザ端末２０の間では、次に示すような情報をやり取りすることが考えられる。
例えばセンタ１０からユーザ端末２０へ送信する情報としては、風景情報、移動体の構造や経路、また、対象物を特定する統計的規則などが考えられる。
【０１６４】
風景情報は、風景を構成するオブジェクト間の関係記述であったり、３次元の風景構造の情報である。また、移動体の構造や経路の情報は、例えば道路上を直進するトラックや自動車の情報や、停留所に発着するバスの情報、踏み切りで目の前を横切る電車の情報であることが考えられる。
【０１６５】
また、対象物を特定する統計的規則は、「車は道路や駐車場に存在する」や「人は歩道に多く存在し、特に駅前や繁華街、観光地には多い」などである。
一方、ユーザ端末２０からセンタ１０へ送信する情報として、対象領域を特定する情報、風景情報を修正する情報などが考えられる。
【０１６６】
風景情報を修正する情報には、単に構造データベースを修正する情報のみならず、ユーザからの教示も含めた情報であってもよい。例えば「新しいビルが建った」、「道路ができた」、「民家が２階建てになった」、「横断歩道ができた」、「道路が広くなった」、「信号がついた」、「木が大きくなって視界を妨げている」、「壁ができた」、「工事中で片側車線になっている」、「イベントで仮設ステージができている」といった情報である。
（２）また、上記実施例のシステムを用いて車両位置管理を行うことも考えられる。つまり、車両ＩＤをセンタ１０へ送信する構成とし、プロファイル中の現在時刻、場所、車両ＩＤを検索条件とすると、所望の車両がどこにいるかを検索することができる。この場合、定期的にプロファイルをセンターに発信する必要がある。
（３）さらにまた、位置情報をセンタ１０へ送信する構成を用いれば、盗難防止に応用できる。
（４）また、センタ１０でユーザ状態を管理することによって、ユーザに生じた緊急事態をセンタ１０側で把握することもできる。
（５）さらにまた、上記実施例のように検索要求に対する情報だけでなく、通知・警告・宣伝に係る情報をセンタ１０から配信するようにしてもよい。例えば「kk公園内の屋内プールは今日はスポーツ大会のため一般開放していない。」、「llトンネルは事故のため通行止めになっている」、「aa交差点前は工事中で渋滞している」、「ssグリーンロードのcc公園前にはおいしいお好み焼き屋がある」、「yyスカイラインのbb地点にはトイレがある」、「UUスーパーKK店は本日10時から12時まで朝市を開催する」といった情報をユーザ端末２０へ送信することが考えられる。
（６）また、上記実施例ではユーザ端末２０の音声認識辞書設定ブロック２１に各種話題に応じた音声認識辞書を予め記憶しておく構成であったが、これに対して、センタ１０から各種話題や環境・状況に応じた音声認識辞書と意味ネットワークを配信するようにしてもよい。これによって、誤認識を低減し、音声対話を円滑化するすることができる。
（７）上記実施例では、ユーザからの情報入力がある毎にユーザ端末２０からセンタ１０へプロファイルを配信する構成であったが、一定時間間隔で送信する構成としてもよい。また、プロファイルで記述する環境・状況、要求・状態に変化があったときに送信する構成としてもよい。さらに、予め決められた場所、時刻において送信する構成としてもよい。また、センタ１０から要求があったときに送信する構成としてもよい。
【図面の簡単な説明】
【図１】本実施例のセンタの概略構成を示す機能ブロック図である。
【図２】本実施例のユーザ端末の概略構成を示す機能ブロック図である。
【図３】センタにて実行されるセンタ側処理を示すフローチャートである。
【図４】ユーザ端末にて実行される端末側処理の前半部分を示すフローチャートである。
【図５】ユーザ端末にて実行される端末側処理の後半部分を示すフローチャートである。
【符号の説明】
１０…センタ
１１…通信ブロック
１２…プロファイル記憶・編集ブロック
１３…プロファイル選択ブロック
１４…情報検索ブロック
１５…配信プロファイル生成ブロック
１６…情報データベース
１６ａ…プロファイルデータベース
１６ｂ…コンテンツデータベース
２０…ユーザ端末
２１…音声認識辞書設定ブロック
２２…ユーザインタフェース
２３…プロファイル生成・更新ブロック
２３ａ…環境・状況推定ブロック
２３ｂ…要求・状態推定ブロック
２３ｃ…位置・時刻特定ブロック
２４ｄ…個人情報記憶ブロック
２４…プロファイル記憶ブロック
２５…不足情報検出ブロック
２６…検索要求生成ブロック
２７…情報検索ブロック
２７ａ…プロファイルデータベース
２７ｂ…ローカルコンテンツデータベース
２８…セキュリティチェックブロック
２９…通信ブロック
３０…新規情報取得ブロック
【図１】
0003788111.tif 000005
【図２】
0003788111.tif 000006
【図３】
0003788111.tif 000007
【図４】
0003788111.tif 000008
【図５】
0003788111.tif 000009