ガイド情報選別システム
【課題】 経路案内装置を利用したガイド情報選別システムにおいて、ユーザのその時々の状況に応じて有用性の高い情報を配信する。
【解決手段】 サーバ２００は、ユーザに配信可能な情報（ガイド情報）をジャンルに分けて管理する。各ジャンルには、優先度、および移動目的、移動状況に応じて定まる評価値が推奨データとして付されている。ユーザが経路案内の過程において、移動目的および移動状況に基づいて推奨データを参照することで、各ジャンルの評価値を求めることができる。評価値の高いジャンルを優先的に選択することで、ユーザのその時々の状況を反映して有用性の高い情報配信を実現することが可能となる。
【解決手段】 サーバ２００は、ユーザに配信可能な情報（ガイド情報）をジャンルに分けて管理する。各ジャンルには、優先度、および移動目的、移動状況に応じて定まる評価値が推奨データとして付されている。ユーザが経路案内の過程において、移動目的および移動状況に基づいて推奨データを参照することで、各ジャンルの評価値を求めることができる。評価値の高いジャンルを優先的に選択することで、ユーザのその時々の状況を反映して有用性の高い情報配信を実現することが可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動中のユーザに有用なガイド情報を選別するガイド情報選別システムに関する。
【背景技術】
【０００２】
店舗が予め登録した広告データをユーザに配信する広告配信システムが広く活用されている。広告配信システムによる配信対象を、カーナビゲーションとすることにより、車両で移動中のユーザへの広告配信を行う技術も提案されている。通常のパーソナルコンピュータなどに配信する場合と異なり、カーナビゲーションへの配信では、ユーザが閲覧可能な情報量には制限があること、カーナビゲーションを利用中のユーザは何らかの目的を持って移動中であることが多いため、目的に応じて、ユーザが欲する情報内容もある程度絞られることなどの特徴がある。
【０００３】
かかる特徴に基づき、従来、カーナビゲーションへの広告配信を対象として、ユーザが欲する情報をタイムリーに提供する技術が種々提案されてきた。例えば、特許文献１は、広告の配信対象エリア、配信期間、配信する時間帯による配信条件を設定することにより、広告によるＰＲ効果が有効に得られると考えられるユーザに集約して広告を効率的に配信する技術を開示している。特許文献２は、ユーザの年齢、性別、職業などの個人情報と、広告主が設定した配信条件、即ち広告を配信すべき時間帯や配信対象者の年齢などの条件とを比較することにより、効率的な広告配信を行う技術を開示している。
【０００４】
【特許文献１】特開２００３−９９６７０号公報
【特許文献２】特開２００２−７７４６４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、従来の絞り込みは、広告主の意図に沿って配信対象となるユーザを絞り込むものであり、ユーザの必要とする情報をその時々のユーザの状況に応じて選択するものとは言えなかった。例えば、ユーザの趣味に関する情報を選択したとしても、ビジネスで移動中など、趣味に関する情報を閲覧するゆとりのない状況下では、ユーザが必要とする情報とは言えず、その情報を有効活用することもできない。
【０００６】
カーナビゲーションを含む経路案内装置では、ユーザは移動する間に種々の情報を閲覧することになるため、先に述べた通り、ユーザが閲覧可能な情報量は制限される。従って、ユーザが無用と感じる情報が多数配信されている場合には、ユーザは、それらの情報全体を無視するようになり、広告等の情報の有用性が一気に失われてしまうおそれがある。
【０００７】
上述の課題は、広告に限らず、観光案内など、種々のガイド情報に共通であった。本発明は、これらの課題に鑑み、経路案内装置を利用中のユーザに対して、その時々のユーザの状況に応じてユーザが必要とするガイド情報を提供可能とすることを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、経路案内装置等を利用して移動中のユーザに有用なガイド情報を選別するガイド情報選別システムとして構成することができる。本明細書において、「移動中」とは、経路案内装置等の案内に従って現実に移動している状態、およびシミュレーションによって仮想的に移動している状態の双方を含む広い意味で用いる。ガイド情報には、ニュース、クイズ、占い、経済情報など地点と無関係の一般的な情報、およびいずれかの地点との関係で予め登録された種々の情報、例えば、広告、観光案内、行政その他の地域情報などが含まれる。ガイド情報は、予めガイド情報データベースとして登録しておいてもよいし、Ｗｅｂサーバなどを情報源としてネットワーク経由で取得するものとしてもよい。ガイド情報は、所定の複数のジャンルに分けておいてもよい。経路案内装置としては、例えば携帯電話、カーナビゲーション装置、ノートパソコン、ＰＤＡなどを利用して提供することができる。ガイド情報選別システムは、これらの装置内でスタンドアロンで稼働するように構成してもよいし、これらの装置を利用した端末とサーバ等をネットワークで接続して構成してもよい。本発明のガイド情報選別システムは、以下に示す種々の構成により、ガイド情報の効率的な提供を実現する。
【０００９】
ガイド情報選別システムは、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された複数の評価パラメータと、ガイド情報自体またはそのジャンルの必要度との対応関係を予め記憶している。必要度とは、ガイド情報をユーザが必要とする可能性を表す指標を意味する。必要度は、数値で表しても良いし、「Ａ，Ｂ，Ｃ」などのランクで表してもよい。移動目的としては、ユーザは一人なのか、家族連れなのか、カップルなのかといった、グループ構成を含めることができる。これらのグループ構成によって、移動目的がビジネス、レジャー、デートというように異なることが多いからである。また、移動目的を表す評価パラメータには、直接、ビジネス、レジャー、休養、食事、ショッピングなどの目的を含めてもよい。移動状況を表す評価パラメータには、現在時刻、現在位置、出発地または目的地からの距離、運転開始後の経過時間などを含めることができる。例えば、レストラン情報は、食事前の時間帯であれば必要度は高くなるが、食事後の時間帯であれば低くなるというように、現在時刻によって必要度は影響を受ける。移動目的、移動状況を表す評価パラメータには、このようにガイド情報の必要性に影響を与え得る種々の項目を含めることが可能である。
【００１０】
ガイド情報選別システムは、ユーザについて、上述の評価パラメータの少なくとも一部に対応する情報を入力し、入力された情報に基づいて上述の対応関係を参照することで、ガイド情報またはジャンルごとの必要度を判断する。そして、この判断結果に基づいて、ユーザに対して有用なガイド情報を選別する。選別したガイド情報は、ユーザに提供してもよいし、ユーザが適宜参照するためのデータベースとしてシステム内で蓄積しておいてもよい。また、選別したガイド情報に基づいて、ユーザの次の目的地を自動的に設定し、経路案内するようにしてもよい。
【００１１】
本発明のガイド情報選別システムでは上述の選別に当り、移動状況等の条件に応じて、それぞれのガイド情報またはジャンルの必要度を評価するという過程を経る。こうすることにより、選別されるべきガイド情報等を移動状況等に基づいて画一的に設定する方法と異なり、移動目的および移動状況が異なるその時々の状況に応じて、柔軟、適格にユーザが必要とするガイド情報を提供することが可能となる。
【００１２】
一例として、ランチタイム（ここでは、午前１１時〜午後１時などの時間帯とする）にユーザにガイド情報を提供する場合を考える。「ランチタイム」であれば、「食事情報」を提供するという画一的な条件設定によって情報を選別する場合には、ユーザの移動目的等に関わらず、付近のレストラン等の情報が選別されることになる。これに対し、本発明では、ランチタイムという評価パラメータ下で、予め用意された対応関係に基づいて、「食事情報」、「お弁当スポット」などのジャンルに対する必要度を評価する。また、並行して、ビジネス関連の情報を収集するために活用できる「本屋情報」や、買い物の「タイムサービス情報」などのジャンルに対する必要度も評価する。この評価は、ユーザの移動目的等によって相違する。例えば、ユーザがビジネス中であれば、「食事情報」や「本屋情報」の必要度は高くなる。ユーザが家族でレジャー中であれば、「お弁当スポット」の必要度が高くなる。ユーザが友人とショッピング中であれば、「タイムサービス情報」の必要度が高くなる。ガイド情報選別システムは、各ガイド情報またはジャンルに対する評価結果を比較して、情報の選別を行う。従って、選別される情報は、画一的なものとはならず、ユーザの移動目的等を反映した多種多様な結果となる。各ガイド情報等に対する必要度の評価より適格な選別結果が得られるようにするためには、上述の対応関係を見直し、各ガイド情報またはジャンルごとの必要度を調整すればよい。これらの作用によって、本発明は柔軟、適格な情報選別を実現することができるのである。ここでは、ジャンルごとに評価する例を示したが、ガイド情報ごとに必要度を評価してもよい。
【００１３】
本発明において必要度を評価するための対応関係は、テーブル、関数など種々の形式で用意することができる。また、この対応関係は、固定的なものであってもよいし、多種多様な対応関係を種々の条件に基づいて使い分けるようにしてもよい。例えば、性別、年齢などユーザの属性による使い分け、ユーザの現在位置が一般道路上か高速道路上かという道路種別による使い分け、現在位置が都心か田舎かという地域による使い分け、ウィークデーか週末・休日かによる使い分け、季節による使い分け、徒歩か車かという移動手段や移動速度による使い分けなどが考えられる。これらの使い分けを行うことにより、更に柔軟、適格な情報選別が可能となる。
【００１４】
また、対応関係は、階層的に用意してもよい。例えば、「食事情報」など、大きなジャンルで必要度を与える対応関係を用意し、その下位層に、「和食」、「洋食」など食事を細分化したジャンルで必要度を与える対応関係を用意してもよい。こうすることで、「食事情報」の必要度が高いと判断された時に、下位層の対応関係を利用して、細分化されたジャンルで有用性の高い情報を選別することが可能となる。
【００１５】
本発明の情報選別は種々の態様で行うことができる。例えば、予め用意された複数のガイド情報またはジャンルの中から、必要度の高いガイド情報等を選別してもよい。また、別の態様として、ある特定のガイド情報またはジャンルを対象とし、そのガイド情報等を選別すべきか否かという態様を採っても良い。後者では、ガイド情報等を評価して得られた必要度が、所定の基準を超える時に、そのガイド情報等を選別するという方法を採ることができる。
【００１６】
本発明では、ガイド情報またはジャンルごとに、ユーザに対するガイド情報の配信実績を記憶するようにしてもよい。ガイド情報選別システムは、必要度に加えて、この配信実績を参照してガイド情報を選別することが可能となる。こうすることで、例えば、配信済みのガイド情報と同一または類似のガイド情報の配信を控えることができ、より有用性の高い情報を提供可能となる。また、別の態様として、配信済みのガイド情報を、周期的に配信することで、ユーザに更に印象づけるようにしてもよい。
【００１７】
配信されたガイド情報を、ユーザが活用したか否かを配信実績に併せて記憶するようにしてもよい。こうすることで、ユーザが活用したガイド情報を優先的に提供することが可能となる。また、ガイド情報を活用したか否かの実績を、評価パラメータと必要度との対応関係に反映させるようにしてもよい。例えば、活用されたガイド情報については、実績に応じて必要度を高め、活用されなかった場合には必要度を下げる態様が考えられる。
【００１８】
ガイド情報選別システムが、地物の位置および地物の属性とを含む地図データベースを備えている場合には、ガイド情報選別システムは、ユーザの現在位置を検出し、その現在位置に基づいて地図データベースを参照することで、ユーザが立ち寄った地物を特定することが可能となる。そして、この立ち寄った地物の属性を参照してガイド情報を選別することが可能となる。こうすることで、例えば、既にレストランに立ち寄ったユーザに対しては、食事前の時間帯であってもレストラン情報が配信される可能性を低減させることができ、代わりに、より有用性が高いガイド情報を選別することが可能となる。また、逆に、ユーザが景色の良い観光スポットに立ち寄った場合などには、ユーザが希望するであろう多くの観光情報を選別することが可能となる。こうした選別は、立ち寄った地物の属性に応じて、各ガイド情報の必要性を減少または増大させる方法によって行っても良いし、属性に基づいて一部のガイド情報を選別対象から除外する等の方法で行ってもよい。
【００１９】
本発明では、評価パラメータの値に対する連続関数で必要度を与えるように対応関係を設定してもよい。例えば、時間帯や距離など、実数値をとることができる評価パラメータに適用することができる。こうすることで、時刻が１分ほど異なるだけで必要度が極端に変化するなどの事態を回避することができ、評価パラメータを適切に必要度に反映することが可能となる。
【００２０】
本発明では、更に、ガイド情報の選別に関してジャンル間の優劣を定める優先度を保持しておくようにしてもよい。優先度とは、例えば、「天気予報」というジャンルよりは、「観光案内」の方を優先することを示す情報である。優先度は、数値やランクなど種々の形式で表すことができる。評価パラメータに応じた必要度が、ユーザのその時々の状況を反映させたものであるのに対し、優先度は各ジャンルの情報の質に応じた有用性を反映させたものと言うこともできる。ガイド情報選別システムは、この優先度を考慮してガイド情報を選別する。こうすることにより、多面的に有用性を判断したガイド情報の選別が可能となる。
【００２１】
優先度は、管理者が予め設定して登録しておくようにしてもよいし、ガイド情報選別システムが、選別されるべきガイド情報を特定し、特定されたガイド情報の内容に基づいて設定するようにしてもよい。ジャンルごとの優先度は、各ジャンル内のガイド情報に基づいて設定すればよい。優先度の設定は、例えば、ガイド情報が更新された日付けが新しいほど優先度が高くなるよう設定する方法をとってもよい。優先度は、固定値としてもよいし、所定の条件で再設定されるようにしてもよい。
【００２２】
優先度は、ＰＲ度の高いとして予め設定された文言が、ガイド情報に含まれる量または割合に応じて、設定する方法を採ることもできる。ＰＲ度の高い文言としては、例えば、「話題の…」、「行列ができる…」、「日本最大の…」などの表現が挙げられる。ガイド情報選別システムは、ガイド情報で使われる種々の表現の中から、このようなＰＲ度の高い表現を予め登録しておき、そのような表現が、ガイド情報に含まれる数やガイド情報中の全表現に占める割合などによってガイド情報を評価し、優先度を設定するのである。こうすることにより、ＰＲ度がより高いガイド情報を優先的に配信することが可能となる。
【００２３】
ガイド情報選別システムは、所定以上の必要度となる情報を検索し得ない場合もある。このような場合には、単にエラー表示等を行うようにしてもよい。別の態様として、ユーザに将来の見通しを与える方法を採ってもよい。つまり、ガイド情報選別システムは、ユーザに案内すべき経路を保持しておく。そして、ユーザの現在位置から所定の範囲内で、所定以上の必要度を有するガイド情報を選別できない場合には、経路上でガイド情報を提供可能な地点を探索し、その結果をユーザに提供する。例えば、ユーザの要望に沿うレストランは近くに存在しないものの、予定の経路を「○分進んだところ」、または「○ｋｍ先」に良いレストランがあるという情報を提供するのである。こうすることで、ユーザは将来の見通しを踏まえて、ガイド情報を活用することが可能となる。
【００２４】
ガイド情報は、ジャンルに分ける他、ジャンル内に、サブジャンルを設けることにより階層管理するようにしてもよい。例えば、「レストラン」というジャンル内に、「イタリアン」、「フランス料理」、「ファーストフード」などのサブジャンルを設ける態様が相当する。料理の種別でサブジャンルを構成する他、「予算」、「大人向け」など、レストランの利用態様に基づいてサブジャンルを構成してもよい。このようにサブジャンルを設けることにより、サブジャンルごとにガイド情報を探索すればよいため、情報選別を効率的に行うことが可能となる。
【００２５】
階層管理する場合には、ガイド情報の選別に関し、サブジャンル間の優劣を定める優先度を設定しておいてもよい。こうすることにより、優先度の設定方法に応じて最適な情報、次善の情報というように、一定の傾向を持たせてガイド情報を提供することができる。例えば、サブジャンル間の優劣は、ユーザの趣味・嗜好や、年齢、性別などに応じて設定することができる。このように設定した場合には、ユーザの趣味・嗜好に沿ったガイド情報を優先的に提供し、かかる情報が存在しない場合に、趣味・嗜好から外れるガイド情報を提供するということが可能となる。また、別の態様として、サブジャンル間の優劣は、予算の額に応じて定めても良い。このように設定した場合には、ユーザの予算に適合するガイド情報を優先的に提供し、かかる情報が存在しない場合に、予算枠を外れるガイド情報を提供することが可能となる。ここで説明したように、サブジャンル間に優劣を持たせることにより、ガイド情報の提供に一定の傾向を持たせることが可能となり、ガイド情報の有用性を更に向上させることが可能となる。
【００２６】
本発明は、上述した種々の特徴を必ずしも全て備えている必要はなく、一部を省略したり適宜組み合わせたりして構成することができる。本発明は、上述したガイド情報選別システムとして構成する他、コンピュータによってガイド情報を提供するガイド情報提供方法として構成することもできる。また、ガイド情報を提供するためのコンピュータプログラムとして構成したり、このコンピュータプログラムの少なくとも一部を記録した記録媒体として構成したりすることもできる。この場合、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。
【発明を実施するための最良の形態】
【００２７】
本発明の実施例について以下の順序で説明する。
Ａ．システム構成：
Ｂ．データ構造：
Ｃ．ガイド情報提供の制御処理：
Ｄ．スケジュール登録・変更処理：
Ｅ．情報ボックス・メンテナンス処理：
Ｆ．スケジュール・ガイド処理：
Ｆ１．ガイド情報選択処理：
Ｆ２．ジャンル内情報選択処理：
Ｆ３．ガイド情報選択例：
Ｇ．第２実施例：
Ｇ１．ガイド情報選択処理：
Ｇ２．優先度設定処理：
Ｇ３．ジャンル内情報選択処理：
【００２８】
Ａ．システム構成：
図１は実施例としてのガイド情報選別システムの構成を示す説明図である。ガイド情報選別システムは、ユーザが指定した出発地から目的地までの経路案内を行う際に、その移動過程でユーザが有効活用できる情報を選別するシステムである。本実施例では、選別された情報をユーザに提供するシステムとして構成しているが、情報の提供は必須ではなく、例えば、選別された情報をユーザが適宜参照するためのデータベースとして登録しておくようにしてもよいし、選別された情報に基づいて経路案内の目的地を自動設定するようにしてもよい。
【００２９】
本実施例では、ユーザが、予めスケジュールを登録しておくと、ガイド情報選別システムが種々の情報源から有用な情報を収集しておくものとした。ユーザがスケジュールを実行する際には、ガイド情報選別システムは、収集した情報の中からユーザが有効活用できる情報を、移動経路とともに提供する。もっとも、これは一例に過ぎず、本実施例のガイド情報選別システムは、スケジュールと無関係に、単に出発地と目的地を指定した経路案内を行わせる態様で利用することもできる。また、提供すべき情報は、事前に収集しておくだけでなく、リアルタイムに収集する態様で実現してもよい。
【００３０】
実施例のガイド情報選別システムは、情報提供サーバ２００（以下、単に「サーバ」と呼ぶこともある）と、端末１００とをインターネットＩＮＴで接続して構成される。図中の例では、端末１００はカーナビゲーション装置である。端末には、この他、携帯電話、ノートＰＣ、ＰＤＡなど携帯可能な種々の装置が利用可能である。端末１００には、情報提供サーバ２００から提供されるガイド情報を取得するためにインターネットＩＮＴとの通信機能が要求されるが、スケジュールの実行中に常時、インターネットＩＮＴへのアクセスが常時確保されている必要はない。図の例では、インターネットＩＮＴを適用した例を示したが、インターネットＩＮＴに代えて、イントラネットなどの限定的なネットワークを用いることも可能である。
【００３１】
ガイド情報選別システムは、上述の通り、サーバ２００と端末１００とを中心として構成されるが、この他にもパソコン３００および多数のＷｅｂサーバ４００［１］、４００［２］を含めることができる。パソコン３００は、サーバ２００にスケジュールの登録、およびスケジュールに従って事前に収集された情報の管理を行うための装置である。本実施例では、これらの機能は、サーバ２００から提供されるＷｅｂページによって実現するものとした。従って、上述の機能を実現するためには、パソコン３００はブラウザを搭載していれば足りる。上述の機能は、端末１００でも実現可能である。この意味で、パソコン３００は端末１００の一種と呼ぶこともできるが、スケジュールの登録等の機能は、デスクトップ型のパソコンなど携帯不能な装置でも実現可能であるため、本実施例では端末１００と区別して示した。
【００３２】
Ｗｅｂサーバ４００［１］、４００［２］（以下、両者をＷｅｂサーバ４００と総称することもある。）は、インターネット上のＷｅｂサイトを通じて種々の情報を提供するサーバである。図中では、Ｗｅｂサーバ４００［１］は観光情報を提供し、Ｗｅｂサーバ４００［２］はグルメ情報を提供する例を示した。提供される情報には、これらに限らず、ショッピング情報、行政情報など多種多様な情報が含まれる。Ｗｅｂサーバ４００は、ガイド情報選別システムに特化したサーバである必要はない。ただし、ガイド情報選別システムと提携したサーバとしておけば、より利便性の高いシステムを構築することができる。例えば、Ｗｅｂサーバ４００が情報を規定のフォーマットに従って提供することにより、本システムの情報収集効率を向上させることができる。
【００３３】
図中には、ガイド情報選別システムとしての機能を提供するための情報提供サーバ２００の機能ブロックを併せて示した。本実施例では、これらの機能ブロックは、これらの機能を実現するためのＣＧＩ（Common Gateway Interface ）などで構成されたコンピュータプログラムを情報提供サーバ２００にインストールすることによってソフトウェア的に実現される。図中の機能ブロックの少なくとも一部は、ＡＳＩＣなどの回路によって、ハードウェア的に構成することも可能である。
【００３４】
サーバ２００は、図示する４通りのデータベースを備えている。個人プロファイル２０１は、後述する通り、ユーザＩＤ、氏名、生年月日などのユーザ個人の識別情報、ユーザの趣味、嗜好などの情報、および画面や音声出力などに関するカスタマイズの情報を格納する。個人プロファイル２０１の読み出し、書き込みは、プロファイル管理部２４０が制御する。
【００３５】
汎用情報ＤＢ２０２は、ガイド情報選別システムがユーザに提供する汎用情報を格納する。汎用情報とは、スケジュールに無関係に提供可能な情報を言い、ニュース、天気予報、各種の広告などが含まれる。音楽を含めても良い。マイボックス２０３は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ２００が収集した情報（以下、「スケジュール関連情報」と称する）を格納する。マイボックス２０３の内容についても後述する。本実施例では、汎用情報およびスケジュール関連情報は、それぞれ「天気」、「ニュース」、「食事」、「スイーツ」などのジャンルに分けて格納、管理されている。本実施例では、汎用情報とスケジュール管理情報のジャンルは同一として説明するが、両者は異なっていてもよく、いずれか一方の情報についてのみ設けられているジャンルが存在してもよい。
【００３６】
地図ＤＢ２０４は、スケジュールに基づいて定まる目的地までの経路の探索や案内に使用されるデータベースであり、道路をノード・リンクの集合で表した道路ネットワークデータと、地図を表示するための描画データとを格納する。本実施例では、サーバ２００は、これらのデータベースを活用しながら、以下に示す各機能ブロックの作用によって、ガイド情報の提供を行う。道路ネットワークデータには、車両で移動する際に活用できる車両用のネットワークデータ、歩行時に活用できる歩行者用のネットワークデータ、交通機関を利用する際に活用できる交通機関用のネットワークデータなどを含めることができる。描画データには、地図に含まれる各地物について、代表点の位置座標、描画用のポリゴンデータ、地物の種別を含む属性などが格納されている。
【００３７】
通信部２１０は、インターネットＩＮＴを介した情報授受を制御する機能を奏する。情報収集部２５０は、通信部２１０を介して得られた情報を、汎用情報ＤＢ２０２またはマイボックス２０３に格納したり、逆にこれらのデータベースから情報を読み出したりする機能を奏する。一例として、情報収集部２５０は、パソコン３００との間で情報授受を行い、ユーザからの指定に従って、マイボックス内のスケジュールの更新、読み出しなどを行う。また、情報収集部２５０は、Ｗｅｂサーバ４００にアクセスして、汎用情報ＤＢ２０２に格納すべきニュース、広告等の汎用情報を収集したり、マイボックス２０３に格納すべき情報、即ちスケジュール関連情報を収集したりする。
【００３８】
情報提供制御部２３０は、個人プロファイル２０１、汎用情報ＤＢ２０２、マイボックス２０３を参照し、スケジュールの実行中にユーザに提供すべきガイド情報の取捨選択を行う。取捨選択するための処理内容については後述するが、本実施例では、汎用情報およびスケジュール関連情報の各ジャンルについて、ユーザの移動目的や移動状況を評価する評価パラメータとの関係で必要度が設定されている。必要度を与えるために設定されているデータを以下では「推奨データ」と呼ぶ。情報提供制御部２３０は、評価パラメータに応じて、この推奨データを参照し、各ジャンルの必要度を求めた上で、必要度の高いジャンルから提供すべきガイド情報を選択する。このような情報提供制御部２３０の機能によって、サーバ２００は、ユーザのその時々の状況において、それぞれ有用性の高い情報を提供することが可能となる。
【００３９】
経路案内部２６０は、マイボックス２０３に登録されたスケジュールに従って移動する際の移動経路や、スケジュール関連情報で得られた各地点まで移動するための寄り道経路を探索する。経路探索は、地図ＤＢ２０４の道路ネットワークデータを参照し、ダイクストラ法など周知の方法を適用して実現することができる。経路案内部２６０は、また、スケジュール実行時には、描画データに基づいて地図表示を行うとともに、地図上に移動経路や寄り道経路の表示を行う。
【００４０】
出力データ生成部２２０は、情報提供制御部２３０および経路案内部２６０から提供されるデータに基づいて、端末１００に表示するための表示データを生成する。本実施例では、多種多様な端末１００を利用できるよう、ＨＴＭＬ、ＸＭＬを利用して表示データを生成するものとした。出力データ生成部２２０は、ガイド情報等を提供するための画面の他、スケジュールを登録・管理するための画面、動作を選択するためのメニュー画面など、ガイド情報選別システムに要求される種々の画面の表示データを生成する。
【００４１】
図中に端末１００に備えられる機能ブロックを併せて例示した。端末１００では、主制御部１１０の管理下で、図示する各機能ブロックが稼働する。本実施例では、これらの機能ブロックは、端末１００としての機能を実現するためのプログラムによって、ソフトウェア的に構成したが、ハードウェア的に構成してもよい。
【００４２】
通信部１２０は、インターネットＩＮＴを介した情報の授受を制御する。コマンド入力部１３０は、ユーザの操作に応じてメニューの選択、案内の開始、表示すべき情報の選択など種々のコマンドを入力する。表示制御部１５０は、情報提供サーバ２００からのデータに従って画面表示を行う機能を奏する。本実施例では、ブラウザによって提供される。ＧＰＳ（Global Positioning System）１４０は、ユーザの現在位置を検出する。現在位置は、サーバ２００に送信され、ガイド情報や経路案内の表示制御に活用される。
【００４３】
ここで示したのは、ガイド情報選別システムの一例に過ぎない。図１中に示した各機能ブロックは、必ずしも情報提供サーバ２００または端末１００に全て備えられている必要はなく、分散処理によって複数のサーバ等の連携で実現するようにしてもよい。
【００４４】
Ｂ．データ構造：
図２は個人プロファイル２０１、マイボックス２０３のデータ構造を示す説明図である。左側に個人プロファイル２０１の内容を示し、右側にマイボックス２０３の内容を示した。個人プロファイル２０１は、ガイド情報選別システムの利用者を管理するためのデータベースであるとともに、ユーザにとって有用な情報を選択する際に活用できる情報を提供するデータベースともなる。個人プロファイル２０１には、図示する通り、ユーザＩＤ、氏名、生年月日、性別、家族構成などのユーザ個人の識別情報が格納される。図の例では、ユーザＩＤとして「ＵＳＲ００１」が格納されている例を示した。家族構成は、「妻、娘１人、息子１人」という人数構成を格納した例を示したが、各人の年齢や趣味、嗜好などを格納するようにしてもよい。家族構成を詳細にするほど、収集・選択される情報の有用性が向上する。例えば、家族でレジャーに出かける場合のガイド情報を提供する場合、娘が小学生なのか女子高生なのかによって、有用な情報は異なるからである。
【００４５】
個人プロファイル２０１には、ユーザの趣味、嗜好などの情報も格納される。この情報もスケジュール関連情報の収集およびガイド情報の選択に活用される。図示するように、ラーメン好みであるなどの嗜好を把握しておくことにより、レストラン情報を提供する際にはラーメン屋を優先させるなどの態様で、ユーザに有用な情報を提供することが可能となる。趣味についても同様である。図の例では、嗜好および趣味を例示したが、この他、職業、ガイド情報の利用実績など、ガイド情報の収集・選択に活用可能な種々の情報を含めることができる。
【００４６】
個人プロファイル２０１には、更に、オプション情報を格納してもよい。図の例では、情報提供に関するカスタマイズの情報を例示した。画面色とは、情報提供画面の背景色の選択を意味する。音声とは、音声出力時の読み上げ音声の種類（以下、「音声種別」と呼ぶ）を意味する。本実施例では、予め登録された複数種類の音声種別の中からユーザの好みの音声種別を選択する態様を採った。音声に格納された「ＦＶＯＩＣＥ１」は、登録された女性音声の識別コードである。サーバ２００がガイド情報等を音声出力する際には、この音声識別コードを反映した音声出力データを生成し、端末１００に送信すればよい。
【００４７】
マイボックス２０３は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ２００が収集した情報（以下、「スケジュール関連情報」と称する）を格納する。マイボックス２０３と個人プロファイル２０１とは、ユーザＩＤで対応づけられている。スケジュールには、日付、時間帯、場所、スケジュールの内容などが登録される。図の例では、３月１日には、「１３時からＺ社で会議」という予定が入っており、その前の時間帯、１０時〜１３時の間は特に予定がない移動時間となっていることが分かる。また、３月２日の例では、「１１時〜１２時に来客」の予定が入っており、「１２時〜１３時過ぎに昼食」の予定が入っていることが分かる。
【００４８】
情報ボックスには、スケジュール関連情報が登録されている。この情報とスケジュールとは、「関連ＩＤ」で関連づけられる。図中の例で示す情報には、「ＩＮＦＯ１」なる関連ＩＤが付されており、３月１日のスケジュールにおける移動時間に「ＩＮＦＯ１」なる関連ＩＤが付されているため、この情報は３月１日の移動中に活用できる情報であることが分かる。情報ボックスには、多くのスケジュール関連情報が登録される。関連ＩＤは、それぞれの情報に固有としてもよいし、スケジュールの項目に固有としてもよい。例えば、図の例において、３月１日の「移動」に関連するスケジュール関連情報が複数存在する場合を考える。前者の例によれば、これらの全情報には個別の関連ＩＤが付されるため、スケジュールにおける「移動」に対して、複数の関連ＩＤが登録されることになる。後者の例によれば、スケジュール関連情報には、全て「移動」に付された関連ＩＤ「ＩＮＦＯ１」が付されることになる。いずれの態様を採るかは任意に選択可能である。前者の態様を採る場合において、「ＩＮＦＯ１＊＊＊」のように、共通の「ＩＮＦＯ１」を含む形で関連ＩＤを設定することにより、「移動」との対応関係を容易に判断できるようにしてもよい。
【００４９】
それぞれのスケジュール関連情報には、図中に示す種々の情報が格納される。「パス」は、情報の格納先を表している。サーバ２００内のディレクトリやファイル名で表しても良いし、Ｗｅｂサーバ４００に格納された情報のＵＲＬを用いても良い。「名称」には、店舗名、名所の名称、地名など、スケジュール関連情報を表す名称が格納される。「場所」は店舗の所在地、名所の所在地など、スケジュール関連情報に関連する地点を表す緯度、経度が格納される。Ｗｅｂサーバ４００を参照して、スケジュール関連情報を収集する場合、住所は特定できても緯度、経度までは特定できないことがある。このような場合には、「場所」は住所で登録可能としてもよい。本実施例では、ガイド情報を提供する際の処理の簡略化を図るため、「場所」は緯度、経度の形式に統一して格納するものとした。緯度、経度が直接、収集できなかった場合には、サーバ２００が住所に基づいて地図ＤＢ２０４を参照し緯度、経度を検索する。
【００５０】
マイボックスには、この他、ユーザが行きたいと思う場所を、ユーザ自身が登録可能としてもよい。この登録には、スケジュール関連情報と同様のフォーマットを用いることができる。この情報は、スケジュールと無関係に事前に登録可能としておくことが好ましい。こうすることで、ユーザは、雑誌等で興味を得た情報を登録しておくことが可能になるとともに、その付近に出かける際に、その情報を有効活用することが可能となる。
【００５１】
「音声」は音声出力データの出力時の音声識別コードである。個人プロファイル２０１に登録されているのと同様、予めサーバ２００に登録されている音声種別を特定するための情報である。この音声識別コードは、Ｗｅｂサイトで提供される情報に音声識別コードを埋め込まれている場合に格納される。こうすることで、情報の提供者は、自己がＷｅｂサイトを通じて提供する情報の一部に、音声識別コードを埋め込んでおくだけで、ガイド情報選別システムで利用される時の音声種別を制御することが可能となる。例えば、図の例であれば、「○○ラーメン」の店主は、自己の好みの音声で、自己の店舗の宣伝や案内を提供することが可能となるのである。
【００５２】
「所要時間」は、スケジュール関連情報に従って行動する際に必要となる時間余裕を表している。例えば、ラーメン屋の場合には、ラーメンを注文してから食べ終わるまでの時間を所要時間とすることができる。人気の高いラーメン屋の場合には、平均の待ち時間を考慮してもよい。所要時間は、情報の提供者が情報内に埋め込んでおくようにしてもよいし、スケジュール関連情報で与えられる店舗、名所などの種別、人気度等に応じて平均的な値をサーバ２００が設定するようにしてもよい。
【００５３】
「提供履歴」は、スケジュール関連情報が端末１００に提供された履歴を記録する。図の例では、この情報が、２００６年３月１日に、端末１００［１］に提供されたことを示している。提供履歴を参照することにより、サーバ２００は同一の情報が繰り返しユーザに提供されることを回避することができる。提供履歴には、ユーザが、この情報を活用したか否かの履歴を含めるようにしてもよい。
【００５４】
以上で説明したデータ構造は、一例に過ぎない。個人プロファイル２０１およびマイボックス２０３共に、図示した項目全てのデータを格納している必要はなく、一部の項目を省略してもよい。また、図示した項目以外のデータを含めるようにしてもよい。データの格納形式も、図の例に限らず、種々の形式を採り得る。
【００５５】
図３は推奨データの例を示す説明図である。先に説明した通り、ユーザの移動目的や移動状況を表す評価パラメータに対して、各ジャンルの情報の必要度を与えるデータである。図中に示す「天気」、「ニュース」、「相場」等がそれぞれジャンルに相当する。評価パラメータとしては、移動目的に関連する項目として「シーン」、移動状況に関連する項目として「時間帯」が設けられている。「シーン」とは、「通勤、出張、ひとり、カップル、ファミリー、仲間」など、ユーザが移動する際に、どのようなグループで移動しているか、どのような目的で移動しているかを表す項目である。図に示した評価パラメータは一例であり、更に多くの評価パラメータを設けても良い。また、図の例では、「シーン」と「時間帯」で個別に必要度を与えるテーブルとしているが、この対応関係は、「シーン」と「時間帯」とが決まった時に、必要度を与える２次元的なテーブルとして構成してもよい。更に多くの評価パラメータに応じて定まる多次元的なテーブルとして構成することも可能である。
【００５６】
推奨データでは、各評価パラメータに対して必要度が与えられる。例えば、「天気」というジャンルについては、「通勤」というシーンでは「○」となり、「朝５〜１１時」という時間帯であれば「◎」となる。必要度の使用方法については、ガイド情報の選択処理で説明する。本実施例では、「◎」「○」「×」というランクで必要度を表しているが、数値で表すようにしてもよい。
【００５７】
推奨データには、この他、「優先度」および配信のための「条件」も設定されている。「優先度」は、ガイド情報を提供する際にジャンル間の優劣を与えるデータである。評価パラメータに基づいて判断される必要度が同等となるジャンルが複数存在する場合には、「優先度」が高い情報が提供されることになる。「優先度」も高い順にＳ、Ａ、Ｂ、Ｃというランクで表しているが、数値で表すようにしてもよい。
【００５８】
「条件」は、必要度および優先度に関わらず、情報の提供可否を制御するために用いられる。図中の例では、「天気」には、「運転開始５分後＋渋滞時」という条件が付されている。この条件によれば、「天気」は、運転開始から５分後までの期間、および渋滞中を除く期間では、必要度、優先度が高い場面であっても配信されないことになる。この条件は、評価パラメータに「運転開始後の経過時間」、「渋滞中か」という項目を設け、「天気」については経過時間が「５分後」まで、および「渋滞中」の場合にそれぞれ必要度を「◎」に設定し、その他の場合には「×」に設定することによって実現してもよい。
【００５９】
「条件」には、情報提供の可否を規定するものだけでなく、「ファミレス」に付されている「”食事”で該当する条件の店がなかったときに案内」という条件のように、ジャンル間の情報提供の優劣を規定するものも含めうる。これは、実質的には、「食事」というジャンルを、「ファミレス」と「その他」のサブジャンルに分けた上で、「その他」を「ファミレス」よりも優先するという優先度を設定したのと同等である。図中に示した「条件」は、このようにそれぞれ評価パラメータや優先度に組み入れることも可能である。
【００６０】
Ｃ．ガイド情報提供の制御処理：
図４はガイド情報選別システムにおける制御処理のフローチャートである。サーバ２００が実行するメインルーチンに相当する。処理を開始すると、サーバ２００はユーザからのログインを受け付け（ステップＳ１０）、メニュー画面を提示して、ユーザからの指示を入力する（ステップＳ１２）。図中にメニュー画面ＭＥＮＵの例を示した。この例では、「１．スケジュール登録・変更」、「２．情報ボックス・メンテナンス」、「３．スケジュール・ガイド」、「４．個人プロファイル管理」の４通りのメニューを設けた。サーバは、ユーザからの選択指示に応じて（ステップＳ１４）、それぞれのメニューに対応した処理を実行する。
【００６１】
「１．スケジュール登録・変更」が選択された場合には、サーバ２００は、スケジュール登録・変更処理を行う（ステップＳ１００）。これは、マイボックス２０３にスケジュールを登録したり、登録済みのスケジュールを変更したりするための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。スケジュール登録・変更処理の内容については後で詳述する。
【００６２】
「２．情報ボックス・メンテナンス」が選択された場合には、サーバ２００は、情報ボックス・メンテナンス処理を行う（ステップＳ２００）。これは、マイボックス２０３に蓄積されたスケジュール関連情報の追加、変更、削除を行うための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。情報ボックス・メンテナンス処理の内容については後で詳述する。
【００６３】
「３．スケジュール・ガイド」が選択された場合には、サーバ２００は、スケジュール・ガイド処理を行う（ステップＳ３００）。これは、スケジュールの実行時に、スケジュールに従った移動経路の案内や、ガイド情報の提供を行うための処理である。ユーザが移動している状態での案内、情報提供を行う処理であるため、携帯性のある端末１００を利用することになる。
【００６４】
「４．個人プロファイル管理」が選択された場合には、サーバ２００は、個人プロファイル管理処理を行う（ステップＳ４００）。これは、個人プロファイル２０１の登録、変更、削除を行うための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。この処理では、サーバ２００は、個人プロファイル２０１の内容（図２参照）を、ユーザのパソコン３００等に表示し、ユーザが各項目を入力すると、その内容で個人プロファイル２０１を更新する。
【００６５】
Ｄ．スケジュール登録・変更処理：
図５はスケジュール登録・変更処理のフローチャートである。メインルーチン（図４）のステップＳ１００に相当する処理である。先に説明した通り、この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。
【００６６】
この処理を開始すると、サーバ２００は、マイボックス２０３から既存のスケジュールを読み込む（ステップＳ１０２）。スケジュールが未登録の場合には、実質的に何も読み込まれないまま、ステップＳ１０２の処理を終えることになる。そして、サーバ２００は、読み込んだスケジュールをパソコン３００の画面に表示し、ユーザの操作に基づいてスケジュールの編集コマンドを入力する（ステップＳ１０４）。
【００６７】
図中にスケジュールの編集画面の例を示した。パソコン３００には、指定された日のスケジュール画面Ｗ１が表示される。既に登録済みのスケジュールは、この画面Ｗ１に表示される。図中の例では、「１３時からＺ社で会議」という予定が登録済みである。ユーザがパソコン３００のマウスまたはキーボードを操作して、画面Ｗ１内でいずれかの時間帯を指定すると、スケジュールを入力するためのサブウィンドウＷ２が表示される。既に予定を登録済みの時間帯をクリックした場合には、サブウィンドウＷ２には、登録済みの予定内容が表示される。ユーザは、このサブウィンドウを利用して、日時、タイトル、場所、メンバー、その他のメモなどを登録することができる。また、スケジュール関連情報の収集を行うか否か（ＯＮ／ＯＦＦ）を切り換えることができる。情報収集をＯＮとすると、サーバ２００によって、スケジュールとスケジュール関連情報とを対応づける関連ＩＤが割り振られる。図中の例は、関連ＩＤとして「ＩＮＦＯ１」が割り当てられた状態を示している。スケジュールの編集は、図示した画面に限らず、周知の種々の編集画面を利用することが可能である。
【００６８】
図では、スケジュール関連情報の収集を行うか否かをユーザが指定する例を示した。情報収集のＯＮ／ＯＦＦの指定は不要としてもよい。例えば、サーバ２００は、予定が登録された場合に、その直前の空き時間に対して、自動的に情報収集をＯＮに設定するようにしてもよい。また、このような設定をするまでなく、全時間帯について情報収集を行うようにしてもよい。例えば、予定が登録されている時間帯については、その予定に対応した情報を収集し、空き時間については次の予定までの移動中で有効活用できる情報を収集すればよい。
【００６９】
スケジュールの編集が完了すると、サーバ２００は編集結果をマイボックス２０３に格納して、スケジュールを更新する（ステップＳ１０６）。そして、情報収集処理、即ちスケジュール関連情報を収集するための処理を実行する（ステップＳ１１０）。
【００７０】
図６は情報収集処理のフローチャートである。この処理では、サーバ２００はマイボックス２０３からスケジュールを読み込み、情報収集の対象となるべき予定、即ち対象スケジュールを抽出する（ステップＳ１１２）。本実施例では、先に説明した通り、情報収集が「ＯＮ」に設定された予定を抽出することになる。
【００７１】
サーバ２００は、この対象スケジュールに対して、直前のスケジュールの場所を開始時位置として設定し、対象スケジュールの直後の場所を終了時位置に設定する（ステップＳ１１４）。そして、開始時位置から終了時位置までの経路探索を行う（ステップＳ１１６）。経路探索は、地図ＤＢ２０４の道路ネットワークデータを参照して行うことができる。ここでは、対象スケジュール前後の予定が与えられているため、この予定に支障がない移動方法を探索する必要がある。つまり、直前の予定の終了時刻に開始時位置を出発し、直後の予定の開始時刻には終了時位置に到達していなくてはならない。このような経路は、所要時間最短という条件で探索すればよい。ダイクストラ法を用いる場合には、各リンクの通過所要時間を反映したコストが最小となるよう、経路探索を行えばよい。経路探索には、種々の条件を考慮することができ、例えば、車両、徒歩、交通機関利用時など、移動手段を多様に変化させて、それぞれの経路を求めても良い。徒歩の時には、坂道や階段に高いコスト値を付すことによって、坂道や階段を避ける経路を探索してもよい。同様に、ユーザの要望をコストに反映させることで、種々の要望を考慮した経路探索を行うことが可能である。
【００７２】
本実施例では、対象スケジュールが移動不能な予定の場合もある。例えば、「会議」という予定に対して、スケジュール関連情報の収集がＯＮとなっている場合が該当する。このように移動不能な予定に対しては、ステップＳ１１６の処理は省略してもよい。
【００７３】
サーバ２００は、次に、個人プロファイル２０１から、ユーザの嗜好および趣味に関するデータを読み込む（ステップＳ１１８）。そして、以上で取り込んだ情報に基づいてＷｅｂサーバから情報を収集する（ステップＳ１２０）。この情報収集は、ユーザに有用な情報を提供することが目的であるから、次の条件で行う。まず、ユーザの嗜好、趣味に合致または類似する情報であることが条件となる。例えば、ユーザが「ラーメン好き」という嗜好を有している場合には、合致する情報として「ラーメン屋」の案内情報を収集すればよい。また、類似する情報として、「中華料理屋」や、そば屋、うどん屋などの麺類の店の案内情報を収集すればよい。趣味についても同様である。情報収集時には、スケジュールに同行するメンバー構成を考慮してもよい。例えば、家族でのレジャーの場合には、家族構成や家族のメンバーの嗜好、趣味等を考慮することができる。出張の場合には、会社の同僚の嗜好、趣味等を考慮することもできる。
【００７４】
第２の条件は、直後の予定に間に合う場所的範囲で情報収集を行うことである。例えば、いくら人気のあるラーメン屋に関する情報であっても、次の予定に間に合わないほど遠くにある店についての情報では活用できないからである。この条件は、種々の方法で判断することができる。例えば、ステップＳ１１６で探索した経路から所定距離内の場所についての情報というように簡易な方法で判断するようにしてもよい。この場合の「所定距離」は、次の予定までの余裕時間、次の目的地までの距離、ユーザの移動速度を考慮して設定することができる。また、別の態様として、スケジュール関連情報に対応した場所を経由地としてステップＳ１１６の経路探索を行い、直後の予定に間に合うか否かを判断するようにしてもよい。
【００７５】
以上の条件に合致する情報が得られると、サーバ２００は、その情報に、対象スケジュールに付された関連ＩＤを付して、情報ボックスに格納する（ステップＳ１２２）。サーバ２００は、情報収集処理を適宜、繰り返し実行することで、関連ＩＤが付された全スケジュールについてスケジュール関連情報を収集するとともに、それぞれの予定について、できるだけ多くのスケジュール関連情報を収集するよう努める。情報収集処理は、例えば、全スケジュールについて一定数までの情報が収集されるまで繰り返し実行するようにしてもよい。
【００７６】
以上の説明では、スケジュールの登録・変更がなされた時に情報収集処理を行う場合を示した。情報収集処理は、この他のタイミングにも実行可能である。例えば、スケジュールが実行されるまでの間、スケジュールの登録・変更が行われるか否かとは無関係に定期的に実行してもよい。このように繰り返し実行することにより、より多くの情報、かつより新しい情報を収集することが可能となる。
【００７７】
Ｅ．情報ボックス・メンテナンス処理：
図７は情報ボックス・メンテナンス処理のフローチャートである。メインルーチンのステップＳ２００に相当する処理である。この処理は、サーバ２００が収集したスケジュール関連情報を、スケジュールの実行前にユーザが確認し、不要な情報を削除したり、収集された情報のうち必ず提供するよう指示するための処理である。先に説明した通り、この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。
【００７８】
処理を開始すると、サーバ２００はユーザからスケジュール関連情報を表示する対象となる予定、即ち対象スケジュールの指定を受け付ける（ステップＳ２０２）。ユーザがパソコン３００で、対象スケジュールを指定すると、サーバ２００はマイボックス２０３の情報ボックスを参照して、対象スケジュールに割り振られた関連ＩＤが付された情報を読み込む（ステップＳ２０４）。
【００７９】
サーバ２００は、読み込んだ結果をパソコン３００に表示し、スケジュール関連情報の編集を受け付ける（ステップＳ２０６）。図中にパソコン３００に表示される編集画面例を示した。この例では、画面の左側に矢印で示すように、地図上にスケジュールに従った移動経路が表示される。そして、スケジュール関連情報の項目が、右下に表示され、地図上には、この項目に対応する場所が表示される。図中の例では、スケジュール関連情報として、情報ａ「○○ラーメン」、情報ｂ「△△チャンポン」、情報ｃ「＊＊うどん」が得られている。左側の地図では、ａ〜ｃの符号で、それぞれの情報に対応する店舗の位置が表示される。ここでは、店舗の例を示したが、名所等についても同様である。また、右上には登録されているスケジュールが表示される。
【００８０】
図示した編集画面では、上述の通り、ユーザは地図によってスケジュール関連情報に対応する地点（以下、「設定場所」という）と移動経路との位置関係を把握することができ、同時に、右上のスケジュール画面によって次の予定までの時間余裕を把握することができる。更に、右下の画面で各項目をクリックすると、詳細な情報が表示されるようにしてもよい。ユーザは、これらの情報を一覧して、スケジュール関連情報の要否を判断する。例えば、情報ａ「○○ラーメン」は店の場所が遠いため不要と判断した場合には、画面の右下のエリアで、情報ａのチェックボックスをチェックし、「削除」ボタンをクリックすればよい。また、必ず提供されることを要求する情報がある場合には、チェックボックスにチェックした上で「登録」ボタンをクリックすればよい。
【００８１】
サーバ２００は、編集結果を入力すると、それに応じて情報ボックスの内容を更新し（ステップＳ２０８）、情報ボックス・メンテナンス処理を終了する。実施例では、情報を削除および提供対象として登録する方法を例示したが、更に、ユーザ自身が収集した情報を追加可能としてもよい。例えば、ステップＳ２０６中に示した編集画面に、ユーザが情報のパスまたはＵＲＬを入力可能とし、ステップＳ２０８では、サーバ２００がこれに従って、情報を取得して情報ボックスに格納するようにすればよい。
【００８２】
Ｆ．スケジュール・ガイド処理：
ユーザはスケジュールの実行時になると、メニュー画面ＭＥＮＵ（図４参照）でスケジュール・ガイドを指示する。サーバ２００は、この指示に応じて、端末１００に対して、ユーザがスケジュールを実行する際の支援情報、つまり目的地までの経路その他の有用な情報を提供する。以下では、まず端末１００の表示画面例によって、スケジュール・ガイド処理における具体的な処理内容を説明した後、この処理を実現するためのフローチャートを示す。
【００８３】
先に説明した通り、スケジュールを開始する時点で、サーバ２００には、スケジュール・ガイドに必要な情報は一通り蓄積されている。従って、ユーザは端末１００にこれらの情報を一括ダウンロードしておくことにより、サーバ２００との通信を行わずにスケジュール・ガイド処理を実行させることも可能である。ただし、以下では、端末１００はサーバ２００と適宜、通信可能な環境にあることを前提として説明する。スケジュール・ガイド中にサーバ２００と通信することによって、ユーザの現状に応じて、提供する情報の内容を柔軟に変更できる利点があるからである。
【００８４】
図８はスケジュール・ガイド処理のフローチャートである。ユーザが移動を開始した後の現在位置に応じて経路の案内、およびガイド情報の提供を行うための処理である。サーバ２００は、まず、マイボックス２０３から、スケジュールデータおよび経路探索結果を読み込む（ステップＳ３０２）。そして、ユーザの現在位置および現在時刻を入力する（ステップＳ３０３）。現在位置は、端末１００のＧＰＳ１４０を利用して検出することができる。
【００８５】
ユーザの現在位置が所定時間、移動しない時は停止中と判断し（ステップＳ３０４）、サーバ２００は、地図ＤＢ２０４から立寄場所を特定し（ステップＳ３０５）、マイボックス２０３に走行履歴として記録する（ステップＳ３０６）。立寄場所は、地図ＤＢ２０４を参照することにより、現在位置の座標に対応する地物を抽出すればよい。対応する地物が得られない場合には、立寄場所不明と扱うものとした。現在位置に含まれる誤差範囲を考慮して、所定距離内の地物を立寄場所として扱っても良い。停止中でない場合には（ステップＳ３０４）、これらの処理はスキップされる。
【００８６】
次に、サーバ２００は、ガイド情報選択処理を実行する（ステップＳ３１０）。ユーザのシーン、時間帯等（図３参照）に応じて、配信条件に適合するガイド情報を選択する処理である。送信すべき情報は、汎用情報およびスケジュール関連情報の双方を対象として選択される。ガイド情報選択処理の処理内容は後述する。サーバ２００は、こうして選択されたガイド情報を端末１００、即ちカーナビに出力する（ステップＳ５００）。
【００８７】
図中に端末１００の表示例を示した。本実施例では、端末１００の画面は、３つのウィンドウＷ１〜Ｗ３から構成される。ウィンドウＷ１には、地図、経路、および現在位置が表示される。ウィンドウＷ２には、気象情報、渋滞情報、および目的地までの距離、到着予想時刻などが表示される。ウィンドウＷ３には、その他のガイド情報が表示される。ウィンドウＷ３において、ユーザが「詳細を見る」をクリックすると、登録されている詳細なガイド情報を表示させることができる。「場所を確認」をクリックすると、ガイド情報が登録されている店舗位置がウィンドウＷ１に表示される。現在位置から店舗までの経路を併せて表示するようにしてもよい。
【００８８】
サーバ２００は、以上の処理を、目的地に到着するまで（ステップＳ５０２）、繰り返し実行する。上述の説明は、サーバ２００と端末１００との通信が確保されている状況での処理である。本実施例では、先に説明した通り、経路探索処理において、事前に経路探索結果やガイド情報が取得されている。従って、移動中の状況により、サーバ２００と端末１００との通信が遮断されている場合には、端末１００に取得済みのデータを用いて経路案内やガイド情報出力（ステップＳ５００）を行ってもよい。
【００８９】
Ｆ１．ガイド情報選択処理：
図９はガイド情報選択処理のフローチャートである。スケジュール・ガイド処理（図８）のステップＳ３１０に相当する処理であり、汎用情報ＤＢ２０２およびマイボックス２０３（図１参照）から、ユーザに提供すべきガイド情報を選択する処理である。
【００９０】
まず、サーバ２００は、汎用情報ＤＢ２０２およびマイボックス２０３のうち、提供するようにユーザが指示した情報の有無（図７のステップＳ２０６参照）を判定する（ステップＳ３１１）。かかる情報がある場合には、指定されたガイド情報を読み込み（ステップＳ３１２）、そのガイド情報の配信、配信実績の記録を行う（ステップＳ３４１）。
【００９１】
ユーザが指示した情報が無い場合（ステップＳ３１１）、サーバ２００はユーザに提供すべき情報を選択するため、モード、移動状況、配信実績、走行履歴を読み込む（ステップＳ３１５）。モードとは、推奨データのシーン（図３参照）に対応する情報である。本実施例では、スケジュールの内容および同行するメンバーから、サーバ２００がモードを判断するものとした。ステップＳ３１５を実行する段階、または経路案内を開始する段階で、ユーザにモードを選択させる方法を採ってもよい。移動状況は、本実施例では、推奨データの「時間帯」に対応する情報であり、ここでは現在時刻の入力となる。移動状況に対して多種類の評価パラメータが設けられている場合には、それぞれの評価パラメータに対応する情報を入力することになる。配信実績は、それぞれの情報と対応づけて汎用情報ＤＢ２０２およびマイボックス２０３に格納されている。走行履歴は、出発後の経過時間およびユーザが立ち寄った場所の履歴である。これらは、本実施例ではマイボックス２０３に格納されている。
【００９２】
サーバ２００は、これらの情報に基づいてジャンル毎に評価値を算出する（ステップＳ３１６）。本実施例では、必要度の総和で評価値を求めるものとした。まず、モードに基づいて推奨データ（図３）を参照し、必要度を求める（求められた必要度を数値で表したものを「モード評価値」と呼ぶ）。次に、移動状況に応じて同様に必要度を求める（求められた必要度を数値で表したものを「移動状況評価値」と呼ぶ）。そして、両者の和（モード評価値＋移動状況評価値）を「評価値」とするのである。これは、評価値の求め方の一例に過ぎず、両者に重み係数を乗じて和を求めてもよい、モード評価値、移動状況評価値のいずれか大きい方または小さい方を評価値として採用してもよい、または両者の積を評価値としてもよい。
【００９３】
図３の例に即して説明する。必要度「◎」、「○」、「×」をそれぞれ「２」、「１」、「０」の数値で表すとする。ジャンル「天気」については、「通勤」モードであれば、必要度「○」なのでモード評価値は「１」となる。「５〜１１時」の時間帯であれば、必要度「◎」なので移動状況評価値は「２」となる。従って、この状況に対する「天気」の評価値は「３」と求まる。その他のジャンルに対しても、モードおよび時間帯に応じて、それぞれ評価値を求めることができる。
【００９４】
サーバ２００は、次にジャンルをソートする（ステップＳ３１７）。ソートのキーは、任意に設定可能であるが、本実施例では、配信実績を第１キー、評価値を第２キー、優先順位を第３キーとした。こうすることで、未配信のジャンル、評価値の高いジャンル、優先度の高いジャンルが、上位に配置されることになる。
【００９５】
ソートが完了すると、サーバ２００は、走行履歴の立寄場所と同一ジャンル、および配信条件（図３参照）を満たさないジャンルを、配信対象から除外する（ステップＳ３１８）。例えば、ユーザが既にレストランに立ち寄っていることが走行履歴から得られている場合には、レストランのガイド情報が属するジャンル、即ち「食事」、「ファミレス」等を配信対象から除外するのである。こうすることで、途中の立ち寄りによって、ユーザにとって有用性が低くなった情報が繰り返し配信されることを回避できる。
【００９６】
これは、処理の一例に過ぎず、逆に、立寄場所と同一のジャンルを上位にソートし直す処理を施してもよい。例えば、ユーザが景色の美しい観光スポットに立ち寄っている場合には、ユーザが他にも景色の美しい場所を求めていると判断できる。従って、「観光名所」に相当するジャンルを上位にソートし直すことで有用性の高い情報を提供することが可能となる。走行履歴の立寄場所が含まれるジャンルに応じて、除外するか、上位にソートするかを切り換える態様を採ってもよい。
【００９７】
以上の処理が完了すると、サーバ２００は最上位のジャンルを配信対象として選択し（ステップＳ３１９）、ジャンル内情報選択処理を実行する（ステップＳ３２０）。これは、指定されたジャンルに含まれる種々のガイド情報の中から、配信すべき情報を選択する処理である。この処理によって、配信すべき情報が選択された場合には（ステップＳ３４０）、サーバ２００は、そのガイド情報を配信し、配信実績に記録して（ステップＳ３４１）、ガイド情報選択処理を終了する。
【００９８】
ジャンル内情報選択処理では、配信すべきガイド情報が存在しないこともある。例えば、指定されたジャンル内には、ユーザの現在位置から遠方にある地点に対するガイド情報しか収集されていない場合などである。情報が選択されなかった場合には（ステップＳ３４０）、サーバ２００は選択すべきガイド情報が得られるまで、ソートされた順序に従って、次のジャンルを指定し、ジャンル内情報選択処理を再試行する（ステップＳ３２０）。
【００９９】
Ｆ２．ジャンル内情報選択処理：
図１０はジャンル内情報選択処理のフローチャートである。ガイド情報選択処理（図９）のステップＳ３２０に相当する処理である。この処理では、サーバは、まず、ジャンルに該当するガイド情報を汎用情報ＤＢ２０２およびマイボックス２０３から読み込む（ステップＳ３２１）。
【０１００】
次に、サーバ２００は、ガイド情報をソートする（ステップＳ３２２）。ソートのキーは任意に設定可能であるが、本実施例では、モードの適合性を第１キー、情報の新しさを第２キー、情報のＰＲ度を第３キーとした（ステップＳ３２２）。モードの適合性とは、ガイド情報が、ユーザの指定したモードに適しているか否かの判断を言う。例えば、「カップル」モードでの移動中には、カップル向きのおしゃれなレストランはモードに適合しており、ファーストフードは非適合と判断される。この判断は、例えば、予めそれぞれのガイド情報に対して、適合するモードを登録しておき、この中に、ユーザから指定されたモードが含まれるか否かをサーバ２００が判断する方法を採ることができる。適合するモードの登録は、サーバ２００のオペレータが、それぞれのガイド情報の内容を判断して手作業で登録してもよい。ガイド情報の提供者が、自己のガイド情報の狙いを考慮して、適合するモードを設定した上でＷｅｂサーバ４００にアップロードするようにしてもよい。更に、店名や種別に基づいて、サーバ２００が適合するモードを自動設定してもよい。自動設定は、店名や種別とモードとを予め対応づけたテーブルを参照することにより、比較的容易に実現できる。もちろん、ここに例示した種々の方法を組み合わせて適用することも可能である。
【０１０１】
情報の新しさは、それぞれのガイド情報の最終更新日からの経過時間である。情報の新しさをソートキーとすることにより、新しい情報を優先的に提供することが可能となる。情報のＰＲ度は、ユーザにとってのガイド情報の魅力を表す評価値である。ＰＲ度は種々の方法で評価可能である。本実施例では、予め定めた表現、例えば「話題の…」、「行列ができる…」、「日本最大の…」などが、ガイド情報中に含まれる割合に基づいてＰＲ度を評価するものとした。割合とは、ＰＲ度の高い表現が、ガイド情報全体の表現の中で占める割合であり、それぞれの表現を単語数で数値化して求めることができる。ＰＲ度の高い表現が使用されている数量で評価してもよい。
【０１０２】
サーバ２００は、ガイド情報のソートが終了すると、最上位のガイド情報を抽出する（ステップＳ３２３）。そして、現在位置から、そのガイド情報に対応する地点（以下、「設置場所」と呼ぶ）までの所要時間を算出する（ステップＳ３２４）。所要時間は、両地点の直線距離に基づいて簡易に求めても良いし、両地点間の経路探索を行って得られる道のりに基づいて求めてもよい。
【０１０３】
こうして得られた所要時間が、予め設定された許容範囲内である場合には（ステップＳ３２５）、サーバ２００は、そのガイド情報を配信対象として選択する（ステップＳ３２９）。許容範囲を超えている場合（ステップＳ３２５）、当該ジャンル内の全ガイド情報について判断が終了するまでの間は（ステップＳ３２６）、ソートされた順に従って次のガイド情報について同様の処理を実行する（ステップＳ３２４、Ｓ３２５）。「許容範囲」は、このようにガイド情報の採否を決める判断基準となる値であり、任意に設定可能である。許容範囲を大きくすれば、現在位置から遠方にあるガイド情報が提供される可能性が高くなり、小さくすれば、条件を満たすガイド情報が得られにくくなる。許容範囲は、これらのバランスを考慮して、ユーザに対し有用な情報を適量提供できる範囲に調整すればよい。
【０１０４】
全てのガイド情報について所要時間が許容範囲を超えている場合には（ステップＳ３２５、Ｓ３２６）、サーバ２００は、予告情報を選択して（ステップＳ３２７）、ジャンル内情報選択処理を終了する。予告情報とは、現在位置からはやや遠方に位置するが、ユーザにとって有用性が高い情報である。この情報を提供することにより、ユーザは、しばらく走行を続けることで、所望のガイド情報が得られるという見通しを立てることができる。例えば、カップル向けのレストランを探している時、現在位置の近くではレストランが見つからなかったとしても、あと３０分ほど移動したところにあることが予告情報で提供されれば、おしゃれさを度外視して手近にある立ち食いそばで済ませてしまい、ロマンチックな食事を逃してしまうという失敗を回避することが可能となるのである。
【０１０５】
本実施例では、予告情報の選択は、モードに適合していること、経路から所定距離内にあることを満たすガイド情報の中で、現在位置に最も近いものを選択することとした（ステップＳ３２７）。予告情報の選択については、後で具体例を示しながら説明する。
【０１０６】
上述の選択にあたっては、所要時間の他、営業時間を考慮してもよい。例えば、レストランなどの施設について営業時間の情報を取得し、その店舗への到着予想時刻が、営業日、営業時間から外れる場合には、当該施設を選択対象から除外する方法を採ることができる。同様に、映画の上映時間を考慮して、情報の選択を行うようにしてもよい。
【０１０７】
Ｆ３．ガイド情報選択例：
図１１はガイド情報選択例を示す説明図である。ガイド情報選択処理におけるソート（図９のステップＳ３１７）の処理例を示した。図の左上には、各ジャンルについて優先順位、評価値、配信実績を示した。評価値は、「カップル」で昼食時「１１〜１４」という条件で、推奨データ（図３）に基づいて設定した値である。ガイド情報選択処理では、配信実績、評価値、優先順位をキーとしてこれらのジャンルがソートされる。右上にソート結果を示した。図中に示したジャンル内で、更に細分化されたジャンルの評価を行うようにしてもよい。例えば、最上位にソートされた「食事」を細分化した「洋食」、「和食」などのサブジャンルを設け、これらのジャンルについて必要度を評価してソートしてもよい。このように階層的に必要度の評価、ソートを行うことにより、「クイズ」などのように評価が低かったジャンルについてはサブジャンルについての無用な評価を回避しつつ、必要度が高いジャンルについては、より柔軟、適切な情報選択を実現することが可能となる。
【０１０８】
右上の図には、併せて立寄実績を示した。ユーザの走行履歴に基づいて判断した結果である。ここでは、レストランなど「食事」「ファミレス」には立ち寄っておらず、喫茶店には立ち寄っているものとする。サーバ２００は、立寄場所と同一ジャンルを除外するため（図９のステップＳＳ３１８）、喫茶が配信対象から除外されることになる。
【０１０９】
図の下側には、ガイド内情報選択処理例を示した。「食事」のジャンル内に、レストランＡ〜レストランＤのガイド情報が収集されているとする。ジャンル内情報選択処理では、モード適合性、情報の新しさ、情報のＰＲ度でソートを行う（図１０のステップＳ３２２）。まず、モード適合性について図１１の例に則して考える。レストランＡは「カップル」向けであるため、ユーザが指定したモード「カップル」に適合する。レストランＢ，Ｃは非適合である。レストランＤは、モードの指定がなされていないため、ユーザが指定したモード「カップル」に適合するものとして扱う。
【０１１０】
レストランＡは更新日が「２００６．７．２」であり、レストランＤは「２００６．６．４」であるから、情報の新しさでは、レストランＡの方が上位となる。次に、情報のＰＲ度では、レストランＤが評価値５であり、レストランＡの評価値４よりも高い。ただし、本実施例では、情報の新しさの方が、ＰＲ度よりも優先のソートキーであるから、総合的にレストランＡの方がレストランＤよりも上位のガイド情報となる。しかし、レストランＡ、Ｂは所要時間が許容範囲を超えている。従って、サーバ２００は許容範囲内にあるレストランＤを配信対象として選択する。この例で、仮にレストランＤのガイド情報が存在しないとすれば、サーバ２００はレストランＡの情報を予告情報として選択することになる。
【０１１１】
上述の例は、複数存在するガイド情報の中から、ユーザに提供すべき物を選択する例を示した。本実施例は、この他、リアルタイムに検索された情報の提供可否を判断する態様で利用することもできる。例えば、ユーザの移動目的等を考慮して図１１に示すようにジャンルのソートが行われているとする。この時点で、ガイド情報選別システムが、Ｗｅｂサーバ等から新たな情報を得たとする。ガイド情報選別システムは、この新たな情報が、図１１中のいずれのジャンルに属するかを判断する。そして、必要度が上位から３位以上など、任意に設定された所定基準以上のジャンルに属する情報であれば、それをユーザに提供する。例えば、上位から３位以上のジャンルに属するレストラン情報が得られている場合には、その情報はユーザに提供されることになるが、クイズ情報の場合には提供されないことになる。このように各ジャンルの必要度を評価した結果に基づいて、新たに得られた情報の提供要否を判断することによって、本実施例は、ユーザに提供すべき情報を柔軟、適切に選別することが可能となる。
【０１１２】
図１２は予告情報の選択例を示す説明図である。ユーザが現在位置ＳＴから目的地ＧＬに向かう状況を例示した。ガイド情報選択処理において、端末１００に配信すべきガイド情報は存在しなかったとする。この場合、サーバ２００はジャンル内情報選択処理において予告情報の選択を行う（図１０のステップＳ３２７）。ここでは、「カップル」向けのレストランを提供するものとし、サーバ２００が提供可能なガイド情報として、レストラン１〜４の４カ所が得られているものとする。予告情報は、モードに適合していること、経路から所定距離内であることを満たすガイド情報の中から、現在位置に最も近いものが選択される（図１０のステップＳ３２７）。まず、モードについて検討する。図示する通り、レストラン１は「ファミリー」向けであり、レストラン２〜４は「カップル」向けである。従って、レストラン１は予告情報の選択対象から外れる。
【０１１３】
次に、経路からの距離を検討する。レストラン２〜４の経路からの距離はそれぞれＤ２、Ｄ３、Ｄ４である。経路からの距離とは、経路から外れて走行すべき距離であり、現在位置から各レストランまでの距離ではない。この距離は、経路上の一点からレストランまでの経路探索によって求めても良いが、本実施例では、レストランから経路に至る最短の直線距離を用いている。経路からの距離の許容範囲は任意に設定可能である。図１２の例では、レストラン２の距離Ｄ２は許容範囲を超えており、レストラン３，４の距離Ｄ３、Ｄ４は許容範囲内であるとする。従って、サーバ２００は、レストラン３，４のうち、現在位置ＳＴから最も近い位置にあるレストラン３を予告情報として選択する。
【０１１４】
ここでは、一つのレストランを選択する例を示したが、レストラン１〜４を候補として提示し、ユーザに選択を委ねても良い。最終決定をユーザが行うことにより、その時の気分や、空腹具合、具体的に提示されたお店の雰囲気などを踏まえた選択をすることができる。この態様を採る場合には、ユーザが選択しやすい範囲、例えば、２〜５個程度まで情報を絞り込んだ上で、提示することが好ましい。
【０１１５】
図１３は予告情報選択の変形例を示す説明図である。図１２では、経路からの距離に基づいて情報選択を行う例を示した。変形例では、距離の評価を簡略化した処理例を示す。変形例では、図示するように、出発地ＳＴ、および目的地ＧＬを含む範囲を所定サイズのエリアＡ１〜Ｄ５に分割する。そして、この中から、経路の通過エリアを選択する。図中にハッチングを付した領域（エリアＡ４、Ｂ４、Ｂ３、Ｃ３、Ｃ２、Ｃ１、Ｄ１）が通過エリアである。次に、レストラン１〜４がこれらの通過エリア内に属するか否かを判断する。図示する通り、レストラン１〜３は、通過エリア内に存在するが、レストラン４は通過エリアから外れることが分かる。変形例では、この結果に基づき、通過エリアから外れるレストラン４は、経路から遠すぎると判断し、選択対象から除外する。レストラン１〜３については、実施例と同様、レストランの種別等に基づいて情報の適用可否を判断する。こうすることにより、簡易な処理で、経路からの距離を反映した情報選択を実現することができる。
【０１１６】
以上で説明した第１実施例のガイド情報選別システムによれば、推奨データ（図３）を用いることにより、ユーザのその時々のモード、移動状況に応じて、ガイド情報のジャンルの必要度を判断することができ、これを反映してユーザに提供されるガイド情報を選択することができる。従って、ユーザにとって有用な情報を提供することが可能となる。
【０１１７】
第１実施例においては、提示されたガイド情報に基づいてレストラン等を利用した結果をマイボックス等に記録可能としてもよい。例えば、施設の利用後にユーザに評価用の画面を提供し、５段階等でユーザが登録した評価結果を、利用した施設と対応づけて登録しておく方法を採ることができる。次にガイド情報を選択する際、高い評価が得られた施設の情報を優先的に提供し、低い評価が得られた情報は選択対象から除外することによって、ユーザに対して有用性の高い情報を提供することが可能となる。
【０１１８】
また、上述の評価結果は、複数のユーザ間で共有可能としてもよい。それぞれの施設に対する平均的な評価を求めることによって、評判の高い施設に関する情報を優先的に提供することが可能となる。また、趣向の類似したユーザ間で情報を共有することにより、ユーザの感覚に適合した情報の提供が可能となる。
【０１１９】
実施例で示した立寄実績は、肯定的な評価に利用することも可能である。特定の施設への立寄実績を記録しておくことにより、ユーザが日常的に利用している施設を知ることが可能となり、これをガイド情報の選択に活用することが可能となる。一例として、ユーザが利用したガソリンスタンドへの立寄実績を記録している場合において、車両の残燃料および平均燃費から給油が必要と判断された場合を考える。立寄結果から、ユーザが特定のガソリンスタンドを利用している場合には、このお得意ガソリンスタンドまでの走行可否を判断し、走行可能であれば、ユーザには給油が必要であることを促しつつ、他のガソリンスタンドの情報は選択対象から除外すればよい。お得意ガソリンスタンドまで走行不能の場合には、お得意ガソリンスタンドと同系列のガソリンスタンドの情報を優先的に提供するなどの態様を採ることができる。同系列を優先するか否かをユーザが設定可能としてもよい。
【０１２０】
Ｇ．第２実施例：
ガイド情報選別システムにおいて、推奨データ（図３）は、種々の設定が可能である。評価パラメータの種類を増やしても良い。また、第１実施例（図３）では、必要度をランクで表す例を示したが、それぞれを数値で表すようにしてもよい。必要度は、評価パラメータの連続関数で与えるようにしてもよい。かかる例を第２実施例として以下で示す。
【０１２１】
図１４は第２実施例における推奨データを示す説明図である。第２実施例では、ガイド情報は、図の左側に示すように、階層化されて管理されている。汎用情報という大分類の中に「天気」、「ニュース」、「クイズ」等のジャンルが設けられ、飲食系の大分類の中に「スイーツ」、「食事」などのジャンルが設けられている。「食事」は、「ファミレス」、「ぐるめ」などのサブジャンルに分かれている。この階層構造は、第２実施例に固有ではなく、第１実施例についても同様に適用可能である。
【０１２２】
図の右側に、「天気」に対応する優先度および必要度を示した。第２実施例では、これらのデータが、ジャンルごとに設定されている。「優先度」は後述する通り、第２実施例ではサーバ２００が設定するものとした。「モード」は、第１実施例（図３）では記号で表していたものを数値で表した点が異なるのみであり、内容は第１実施例と同様である。第２実施例では、時間帯、運転時間、目的地までの距離を評価パラメータとして適用し、図示する通りの関数で評価値を与えるものとした。図中の各グラフは、それぞれの評価パラメータに対して「天気」に対する評価値を与えるものである。「時間帯」は横軸に時間を取って表してあり、午前中の時間帯で評価値が高く設定されている。「運転時間」は出発後の経過時間を横軸にとって表してあり、運転開始後１時間以内で評価値が高く設定されている。「目的地までの距離」については、距離が伸びるほど評価値が高く設定されている。これは、目的地から離れているほど、目的地の「天気」情報の必要度が高いことを意味している。このように連続関数で評価値を与える構成をとることにより、例えば、現在時刻が１分異なるだけで「時間帯」による評価値が大きく変動するという弊害を回避することが可能となる。第２実施例では、移動状況に関する評価パラメータを全て連続関数で規定する例を示したが、第１実施例のようにランクで与える項目と、連続関数で与える項目とを混在させてもよい。
【０１２３】
Ｇ１．ガイド情報選択処理：
図１５は第２実施例におけるガイド情報選択処理のフローチャートである。スケジュール・ガイド処理（図８）のステップＳ３１０に相当する処理である。サーバ２００は、第１実施例（図９）と同様、ユーザが指示した情報がある場合には（ステップＳ４０１）、指定されたガイド情報を読み込み（ステップＳ４０２）、そのガイド情報の配信、配信実績の記録を行う（ステップＳ４６２）。
【０１２４】
ユーザが指示した情報が無い場合（ステップＳ４０１）、サーバ２００はモード、移動状況、配信実績、走行履歴を読み込み（ステップＳ４０３）、優先度設定処理を実行する（ステップＳ４１０）。第１実施例では各ジャンルの優先度が予め与えられていたのに対し、第２実施例ではこの処理によって各ジャンルの優先度を設定するのである。第２実施例では、優先度は数値で設定されるものとした。
【０１２５】
次に、サーバ２００は、推奨データ（図１４）を参照してジャンル毎に評価値を算出する（ステップＳ４３０）。まず、第１実施例と同様、ユーザが指定した「モード」に基づき、モード評価値を求める。次に、時間帯評価値、運転時間評価値、距離評価値を、それぞれ推奨データのグラフに基づき算出する。第２実施例では、優先度も含めて全体の評価値を次式で求めるものとした。この式は、任意に設定可能である。
評価値＝優先度×（モード評価値＋時間帯評価値＋運転時間評価値＋距離評価値）
このように優先度を含めて評価値を求めることにより、ジャンルを選択する基準として、評価パラメータと優先度を同等に扱うことができる。例えば、モード評価値、時間帯評価値、運転時間評価値、距離評価値が比較的低いジャンルであっても、優先度が高いものがあれば、提供対象として選択することが可能となる。
【０１２６】
サーバ２００は、次に配信実績および評価値に基づいてジャンルをソートする（ステップＳ４３２）。第１実施例と異なり、優先度は評価値に含まれているため、ソートキーとして用いる必要はない。ソートが完了すると、第１実施例と同様、サーバ２００は、走行履歴の立寄場所と同一ジャンル、および配信条件（図３参照）を満たさないジャンルを、配信対象から除外する（ステップＳ４３４）。
【０１２７】
そして、サーバ２００は最上位のジャンルを配信対象として選択し（ステップＳ４３６）、ジャンル内情報選択処理を実行する（ステップＳ４４０）。この処理によって、配信すべき情報が選択された場合には（ステップＳ４６０）、サーバ２００は、そのガイド情報を配信し、配信実績に記録して（ステップＳ４６２）、ガイド情報選択処理を終了する。情報が選択されなかった場合には（ステップＳ４６０）、サーバ２００は選択すべきガイド情報が得られるまで、ソートされた順序に従って、次のジャンルを指定し、ジャンル内情報選択処理を再試行する（ステップＳ４４０）。
【０１２８】
Ｇ２．優先度設定処理：
図１６は優先度設定処理のフローチャートである。ガイド情報選択処理（図１５）のステップＳ４１０に相当する処理であり、推奨データ（図１４）に含まれる各ジャンルの優先度を設定する処理である。
【０１２９】
この処理では、サーバ２００は推奨データに含まれる中から処理対象とすべきいずれかのジャンルを選択し（ステップＳ４１１）、デフォルトの優先度を読み込む（ステップＳ４１２）。本実施例では、デフォルトの優先度は予め推奨データに登録してある。
【０１３０】
次にサーバ２００は、処理対象となるジャンル内で、ユーザの現在位置に基づき、提供可能なガイド情報を抽出する（ステップＳ４１３）。現在位置から所要時間が所定範囲内のガイド情報を抽出すればよい。そして、これらのガイド情報のうち、最新のものに基づいて新鮮度を設定する（ステップＳ４１４）。図中に新鮮度の設定例を示した。図示する通り、ガイド情報の更新後の経過時間に応じて０．０〜１．０の範囲の実数値で新鮮度を与えるグラフを用意しておく。このグラフは任意に設定可能である。サーバ２００は、最新のガイド情報の経過時間に基づいて、このグラフを参照することにより新鮮度を決定することができる。ここでは、グラフを用意する例を示したが、関数、テーブルなど経過時間と新鮮度の関係は、種々の形式で与えることが可能である。
【０１３１】
サーバ２００は、次に、ステップＳ４１３で抽出された各ガイド情報のＰＲ度を算出する（ステップＳ４１５）。本実施例では、ＰＲ度は、「期間限定係数×売り文句係数」で求めるものとした。期間限定係数とは、ガイド情報の有効期限に応じて定まる係数である。図中に期間限定係数の設定例を示した。この例では、有効期限が短いほど、係数が高くなるよう設定されている。例えば、期間限定のセールや、桜の開花情報など、残り期間が短いほど貴重な情報であり、ユーザへのアピール度が高いと考えられることを反映した設定である。売り文句係数は、売り文句に相当する単語数と、全単語数との比である。売り文句係数は、第１実施例で説明したＰＲ度に相当する値である。ここで示したのは、期間限定係数や売り文句係数の一例に過ぎず、これらの係数は任意に設定可能である。また、この他の要素を用いても良い。売り文句係数は、必ずしもリアルタイムに求める必要はなく、事前に情報収集した時点で求めても良いし、Ｗｅｂページの作成者がＷｅｂページの一情報として含めておくようにしてもよい。
【０１３２】
サーバ２００は、以上の結果を基に、次式によって優先度を算出する。優先度は、デフォルト値に、新鮮度とＰＲ度を考慮した修正を施した値となっている。
優先度＝新鮮度×ＰＲ度の最大値×デフォルト優先度；
ＰＲ度はジャンル内で抽出された各ガイド情報について求められるため、ここではその最大値を用いるものとした。平均値その他の代表値を用いても良い。サーバ２００は以上の値を全ジャンルについて終了するまで繰り返す（ステップＳ４１７）。こうして設定された優先度を用いることにより、新鮮な情報、ＰＲ度が高い情報が入っているジャンルは優先度が高くなり、そうでないジャンルは優先度が低くなる。
【０１３３】
Ｇ３．ジャンル内情報選択処理：
図１７は第２実施例におけるジャンル内情報選択処理のフローチャートである。ガイド情報選択処理（図１５）のステップＳ４４０に相当する処理である。第２実施例では、ガイド情報がジャンル、サブジャンルという階層構造（図１４）に応じた処理内容となっている。このため、サーバは、まず、ガイド情報を、サブジャンル単位で優先順位に基づきソートする（ステップＳ４４１）。本実施例では、サブジャンル単位の優先順位は、予め推奨データ（図１４）に登録されているものとした。この優先順位を優先順位設定処理（図１６）等によって設定するものとしてもよい。
【０１３４】
次に、サーバ２００は、サブジャンルに該当するガイド情報を汎用情報ＤＢ２０２およびマイボックス２０３から読み込み（ステップＳ４４２）、第１実施例（図１０）と同様、ガイド情報をソートする（ステップＳ４４３）。
【０１３５】
サーバ２００は、ガイド情報のソートが終了すると、第１実施例と同様、サーバ２００は、最上位のガイド情報を抽出し（ステップＳ４４４）、現在位置から、そのガイド情報に対応する地点（以下、「設置場所」と呼ぶ）までの所要時間を算出する（ステップＳ４４５）。
【０１３６】
こうして得られた所要時間が、予め設定された許容範囲内である場合には（ステップＳ４４６）、サーバ２００は、そのガイド情報を配信対象として選択する（ステップＳ４５０）。許容範囲を超えている場合（ステップＳ４４６）、当該ジャンル内の全ガイド情報について判断が終了するまでの間は（ステップＳ４４７）、ソートされた順に従って次のガイド情報について同様の処理を実行する。
【０１３７】
全てのガイド情報について所要時間が許容範囲を超えている場合には（ステップＳ３２５、Ｓ３２６）、サーバ２００は、次のサブジャンルに移行し（ステップＳ４４８）、上述の処理（ステップＳ４４２〜Ｓ４４７）を繰り返す。全サブジャンルが終了した時は、サーバ２００は、予告情報を選択して（ステップＳ３２７）、ジャンル内情報選択処理を終了する。
【０１３８】
第２実施例のジャンル内情報選択処理では、サブジャンルを優先順位に従ってソートした上でサブジャンルごとにガイド情報を選択する。従って、一定の傾向に従って、ガイド情報を提供することが可能となる。例えば、第２実施例では、図１４に示したように「食事」のジャンル内に「ファミレス」「ぐるめ」等のサブジャンルがある。本実施例によれば、例えば、「ぐるめ」に属するレストランを優先的に選択し、その中で配信すべきガイド情報が見いだされない時に「ファミレス」に属するレストランを探すよう、指定することができる。この結果、ユーザが「ぐるめ」に属するレストランがファミレスよりも若干遠方にある場合でも、ファミレスより優先してガイド情報を与えることが可能となる。このようにサブジャンル単位でガイド情報を選択することによって、ユーザの意図に沿った情報選択がより実現可能となる。
【０１３９】
第２実施例によれば、第１実施例と同様、ユーザのその時々の状況を考慮して、有用性の高いガイド情報を適切に配信することができる。
【０１４０】
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。本実施例は、広告の配信等に限らず、観光案内や行政情報など種々の情報を配信対象とすることができる。また、実施例では、ユーザの事情を広告の配信に反映させる技術を例示したが、ガイド情報を提供者が、受信するユーザの条件を既定し、サーバ２００は、この条件に基づいて受信対象者を絞り込むようにしてもよい。こうすることで、ガイド情報は、その提供者の意図に沿ったユーザ、かつ当該情報を欲していると推測されるユーザに提供可能となり、ガイド情報の有用性を更に向上させることが可能となる。
【図面の簡単な説明】
【０１４１】
【図１】実施例としてのガイド情報選別システムの構成を示す説明図である。
【図２】個人プロファイル２０１、マイボックス２０３のデータ構造を示す説明図である。
【図３】推奨データの例を示す説明図である。
【図４】ガイド情報選別システムにおける制御処理のフローチャートである。
【図５】スケジュール登録・変更処理のフローチャートである。
【図６】情報収集処理のフローチャートである。
【図７】情報ボックス・メンテナンス処理のフローチャートである。
【図８】スケジュール・ガイド処理のフローチャートである。
【図９】ガイド情報選択処理のフローチャートである。
【図１０】ジャンル内情報選択処理のフローチャートである。
【図１１】ガイド情報選択例を示す説明図である。
【図１２】予告情報の選択例を示す説明図である。
【図１３】予告情報選択の変形例を示す説明図である。
【図１４】第２実施例における推奨データを示す説明図である。
【図１５】第２実施例におけるガイド情報選択処理のフローチャートである。
【図１６】優先度設定処理のフローチャートである。
【図１７】第２実施例におけるジャンル内情報選択処理のフローチャートである。
【符号の説明】
【０１４２】
１００…端末
１１０…主制御部
１２０…通信部
１３０…コマンド入力部
１４０…ＧＰＳ
１５０…表示制御部
２００…情報提供サーバ
２０１…地図ＤＢ
２０２…ユーザＤＢ
２０３…マイボックス
２０４…地図ＤＢ
２１０…通信部
２２０…出力データ生成部
２３０…情報提供制御部
２４０…プロファイル管理部
２５０…情報収集部
２６０…経路案内部
３００…パソコン
４００…Ｗｅｂサーバ
【技術分野】
【０００１】
本発明は、移動中のユーザに有用なガイド情報を選別するガイド情報選別システムに関する。
【背景技術】
【０００２】
店舗が予め登録した広告データをユーザに配信する広告配信システムが広く活用されている。広告配信システムによる配信対象を、カーナビゲーションとすることにより、車両で移動中のユーザへの広告配信を行う技術も提案されている。通常のパーソナルコンピュータなどに配信する場合と異なり、カーナビゲーションへの配信では、ユーザが閲覧可能な情報量には制限があること、カーナビゲーションを利用中のユーザは何らかの目的を持って移動中であることが多いため、目的に応じて、ユーザが欲する情報内容もある程度絞られることなどの特徴がある。
【０００３】
かかる特徴に基づき、従来、カーナビゲーションへの広告配信を対象として、ユーザが欲する情報をタイムリーに提供する技術が種々提案されてきた。例えば、特許文献１は、広告の配信対象エリア、配信期間、配信する時間帯による配信条件を設定することにより、広告によるＰＲ効果が有効に得られると考えられるユーザに集約して広告を効率的に配信する技術を開示している。特許文献２は、ユーザの年齢、性別、職業などの個人情報と、広告主が設定した配信条件、即ち広告を配信すべき時間帯や配信対象者の年齢などの条件とを比較することにより、効率的な広告配信を行う技術を開示している。
【０００４】
【特許文献１】特開２００３−９９６７０号公報
【特許文献２】特開２００２−７７４６４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、従来の絞り込みは、広告主の意図に沿って配信対象となるユーザを絞り込むものであり、ユーザの必要とする情報をその時々のユーザの状況に応じて選択するものとは言えなかった。例えば、ユーザの趣味に関する情報を選択したとしても、ビジネスで移動中など、趣味に関する情報を閲覧するゆとりのない状況下では、ユーザが必要とする情報とは言えず、その情報を有効活用することもできない。
【０００６】
カーナビゲーションを含む経路案内装置では、ユーザは移動する間に種々の情報を閲覧することになるため、先に述べた通り、ユーザが閲覧可能な情報量は制限される。従って、ユーザが無用と感じる情報が多数配信されている場合には、ユーザは、それらの情報全体を無視するようになり、広告等の情報の有用性が一気に失われてしまうおそれがある。
【０００７】
上述の課題は、広告に限らず、観光案内など、種々のガイド情報に共通であった。本発明は、これらの課題に鑑み、経路案内装置を利用中のユーザに対して、その時々のユーザの状況に応じてユーザが必要とするガイド情報を提供可能とすることを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、経路案内装置等を利用して移動中のユーザに有用なガイド情報を選別するガイド情報選別システムとして構成することができる。本明細書において、「移動中」とは、経路案内装置等の案内に従って現実に移動している状態、およびシミュレーションによって仮想的に移動している状態の双方を含む広い意味で用いる。ガイド情報には、ニュース、クイズ、占い、経済情報など地点と無関係の一般的な情報、およびいずれかの地点との関係で予め登録された種々の情報、例えば、広告、観光案内、行政その他の地域情報などが含まれる。ガイド情報は、予めガイド情報データベースとして登録しておいてもよいし、Ｗｅｂサーバなどを情報源としてネットワーク経由で取得するものとしてもよい。ガイド情報は、所定の複数のジャンルに分けておいてもよい。経路案内装置としては、例えば携帯電話、カーナビゲーション装置、ノートパソコン、ＰＤＡなどを利用して提供することができる。ガイド情報選別システムは、これらの装置内でスタンドアロンで稼働するように構成してもよいし、これらの装置を利用した端末とサーバ等をネットワークで接続して構成してもよい。本発明のガイド情報選別システムは、以下に示す種々の構成により、ガイド情報の効率的な提供を実現する。
【０００９】
ガイド情報選別システムは、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された複数の評価パラメータと、ガイド情報自体またはそのジャンルの必要度との対応関係を予め記憶している。必要度とは、ガイド情報をユーザが必要とする可能性を表す指標を意味する。必要度は、数値で表しても良いし、「Ａ，Ｂ，Ｃ」などのランクで表してもよい。移動目的としては、ユーザは一人なのか、家族連れなのか、カップルなのかといった、グループ構成を含めることができる。これらのグループ構成によって、移動目的がビジネス、レジャー、デートというように異なることが多いからである。また、移動目的を表す評価パラメータには、直接、ビジネス、レジャー、休養、食事、ショッピングなどの目的を含めてもよい。移動状況を表す評価パラメータには、現在時刻、現在位置、出発地または目的地からの距離、運転開始後の経過時間などを含めることができる。例えば、レストラン情報は、食事前の時間帯であれば必要度は高くなるが、食事後の時間帯であれば低くなるというように、現在時刻によって必要度は影響を受ける。移動目的、移動状況を表す評価パラメータには、このようにガイド情報の必要性に影響を与え得る種々の項目を含めることが可能である。
【００１０】
ガイド情報選別システムは、ユーザについて、上述の評価パラメータの少なくとも一部に対応する情報を入力し、入力された情報に基づいて上述の対応関係を参照することで、ガイド情報またはジャンルごとの必要度を判断する。そして、この判断結果に基づいて、ユーザに対して有用なガイド情報を選別する。選別したガイド情報は、ユーザに提供してもよいし、ユーザが適宜参照するためのデータベースとしてシステム内で蓄積しておいてもよい。また、選別したガイド情報に基づいて、ユーザの次の目的地を自動的に設定し、経路案内するようにしてもよい。
【００１１】
本発明のガイド情報選別システムでは上述の選別に当り、移動状況等の条件に応じて、それぞれのガイド情報またはジャンルの必要度を評価するという過程を経る。こうすることにより、選別されるべきガイド情報等を移動状況等に基づいて画一的に設定する方法と異なり、移動目的および移動状況が異なるその時々の状況に応じて、柔軟、適格にユーザが必要とするガイド情報を提供することが可能となる。
【００１２】
一例として、ランチタイム（ここでは、午前１１時〜午後１時などの時間帯とする）にユーザにガイド情報を提供する場合を考える。「ランチタイム」であれば、「食事情報」を提供するという画一的な条件設定によって情報を選別する場合には、ユーザの移動目的等に関わらず、付近のレストラン等の情報が選別されることになる。これに対し、本発明では、ランチタイムという評価パラメータ下で、予め用意された対応関係に基づいて、「食事情報」、「お弁当スポット」などのジャンルに対する必要度を評価する。また、並行して、ビジネス関連の情報を収集するために活用できる「本屋情報」や、買い物の「タイムサービス情報」などのジャンルに対する必要度も評価する。この評価は、ユーザの移動目的等によって相違する。例えば、ユーザがビジネス中であれば、「食事情報」や「本屋情報」の必要度は高くなる。ユーザが家族でレジャー中であれば、「お弁当スポット」の必要度が高くなる。ユーザが友人とショッピング中であれば、「タイムサービス情報」の必要度が高くなる。ガイド情報選別システムは、各ガイド情報またはジャンルに対する評価結果を比較して、情報の選別を行う。従って、選別される情報は、画一的なものとはならず、ユーザの移動目的等を反映した多種多様な結果となる。各ガイド情報等に対する必要度の評価より適格な選別結果が得られるようにするためには、上述の対応関係を見直し、各ガイド情報またはジャンルごとの必要度を調整すればよい。これらの作用によって、本発明は柔軟、適格な情報選別を実現することができるのである。ここでは、ジャンルごとに評価する例を示したが、ガイド情報ごとに必要度を評価してもよい。
【００１３】
本発明において必要度を評価するための対応関係は、テーブル、関数など種々の形式で用意することができる。また、この対応関係は、固定的なものであってもよいし、多種多様な対応関係を種々の条件に基づいて使い分けるようにしてもよい。例えば、性別、年齢などユーザの属性による使い分け、ユーザの現在位置が一般道路上か高速道路上かという道路種別による使い分け、現在位置が都心か田舎かという地域による使い分け、ウィークデーか週末・休日かによる使い分け、季節による使い分け、徒歩か車かという移動手段や移動速度による使い分けなどが考えられる。これらの使い分けを行うことにより、更に柔軟、適格な情報選別が可能となる。
【００１４】
また、対応関係は、階層的に用意してもよい。例えば、「食事情報」など、大きなジャンルで必要度を与える対応関係を用意し、その下位層に、「和食」、「洋食」など食事を細分化したジャンルで必要度を与える対応関係を用意してもよい。こうすることで、「食事情報」の必要度が高いと判断された時に、下位層の対応関係を利用して、細分化されたジャンルで有用性の高い情報を選別することが可能となる。
【００１５】
本発明の情報選別は種々の態様で行うことができる。例えば、予め用意された複数のガイド情報またはジャンルの中から、必要度の高いガイド情報等を選別してもよい。また、別の態様として、ある特定のガイド情報またはジャンルを対象とし、そのガイド情報等を選別すべきか否かという態様を採っても良い。後者では、ガイド情報等を評価して得られた必要度が、所定の基準を超える時に、そのガイド情報等を選別するという方法を採ることができる。
【００１６】
本発明では、ガイド情報またはジャンルごとに、ユーザに対するガイド情報の配信実績を記憶するようにしてもよい。ガイド情報選別システムは、必要度に加えて、この配信実績を参照してガイド情報を選別することが可能となる。こうすることで、例えば、配信済みのガイド情報と同一または類似のガイド情報の配信を控えることができ、より有用性の高い情報を提供可能となる。また、別の態様として、配信済みのガイド情報を、周期的に配信することで、ユーザに更に印象づけるようにしてもよい。
【００１７】
配信されたガイド情報を、ユーザが活用したか否かを配信実績に併せて記憶するようにしてもよい。こうすることで、ユーザが活用したガイド情報を優先的に提供することが可能となる。また、ガイド情報を活用したか否かの実績を、評価パラメータと必要度との対応関係に反映させるようにしてもよい。例えば、活用されたガイド情報については、実績に応じて必要度を高め、活用されなかった場合には必要度を下げる態様が考えられる。
【００１８】
ガイド情報選別システムが、地物の位置および地物の属性とを含む地図データベースを備えている場合には、ガイド情報選別システムは、ユーザの現在位置を検出し、その現在位置に基づいて地図データベースを参照することで、ユーザが立ち寄った地物を特定することが可能となる。そして、この立ち寄った地物の属性を参照してガイド情報を選別することが可能となる。こうすることで、例えば、既にレストランに立ち寄ったユーザに対しては、食事前の時間帯であってもレストラン情報が配信される可能性を低減させることができ、代わりに、より有用性が高いガイド情報を選別することが可能となる。また、逆に、ユーザが景色の良い観光スポットに立ち寄った場合などには、ユーザが希望するであろう多くの観光情報を選別することが可能となる。こうした選別は、立ち寄った地物の属性に応じて、各ガイド情報の必要性を減少または増大させる方法によって行っても良いし、属性に基づいて一部のガイド情報を選別対象から除外する等の方法で行ってもよい。
【００１９】
本発明では、評価パラメータの値に対する連続関数で必要度を与えるように対応関係を設定してもよい。例えば、時間帯や距離など、実数値をとることができる評価パラメータに適用することができる。こうすることで、時刻が１分ほど異なるだけで必要度が極端に変化するなどの事態を回避することができ、評価パラメータを適切に必要度に反映することが可能となる。
【００２０】
本発明では、更に、ガイド情報の選別に関してジャンル間の優劣を定める優先度を保持しておくようにしてもよい。優先度とは、例えば、「天気予報」というジャンルよりは、「観光案内」の方を優先することを示す情報である。優先度は、数値やランクなど種々の形式で表すことができる。評価パラメータに応じた必要度が、ユーザのその時々の状況を反映させたものであるのに対し、優先度は各ジャンルの情報の質に応じた有用性を反映させたものと言うこともできる。ガイド情報選別システムは、この優先度を考慮してガイド情報を選別する。こうすることにより、多面的に有用性を判断したガイド情報の選別が可能となる。
【００２１】
優先度は、管理者が予め設定して登録しておくようにしてもよいし、ガイド情報選別システムが、選別されるべきガイド情報を特定し、特定されたガイド情報の内容に基づいて設定するようにしてもよい。ジャンルごとの優先度は、各ジャンル内のガイド情報に基づいて設定すればよい。優先度の設定は、例えば、ガイド情報が更新された日付けが新しいほど優先度が高くなるよう設定する方法をとってもよい。優先度は、固定値としてもよいし、所定の条件で再設定されるようにしてもよい。
【００２２】
優先度は、ＰＲ度の高いとして予め設定された文言が、ガイド情報に含まれる量または割合に応じて、設定する方法を採ることもできる。ＰＲ度の高い文言としては、例えば、「話題の…」、「行列ができる…」、「日本最大の…」などの表現が挙げられる。ガイド情報選別システムは、ガイド情報で使われる種々の表現の中から、このようなＰＲ度の高い表現を予め登録しておき、そのような表現が、ガイド情報に含まれる数やガイド情報中の全表現に占める割合などによってガイド情報を評価し、優先度を設定するのである。こうすることにより、ＰＲ度がより高いガイド情報を優先的に配信することが可能となる。
【００２３】
ガイド情報選別システムは、所定以上の必要度となる情報を検索し得ない場合もある。このような場合には、単にエラー表示等を行うようにしてもよい。別の態様として、ユーザに将来の見通しを与える方法を採ってもよい。つまり、ガイド情報選別システムは、ユーザに案内すべき経路を保持しておく。そして、ユーザの現在位置から所定の範囲内で、所定以上の必要度を有するガイド情報を選別できない場合には、経路上でガイド情報を提供可能な地点を探索し、その結果をユーザに提供する。例えば、ユーザの要望に沿うレストランは近くに存在しないものの、予定の経路を「○分進んだところ」、または「○ｋｍ先」に良いレストランがあるという情報を提供するのである。こうすることで、ユーザは将来の見通しを踏まえて、ガイド情報を活用することが可能となる。
【００２４】
ガイド情報は、ジャンルに分ける他、ジャンル内に、サブジャンルを設けることにより階層管理するようにしてもよい。例えば、「レストラン」というジャンル内に、「イタリアン」、「フランス料理」、「ファーストフード」などのサブジャンルを設ける態様が相当する。料理の種別でサブジャンルを構成する他、「予算」、「大人向け」など、レストランの利用態様に基づいてサブジャンルを構成してもよい。このようにサブジャンルを設けることにより、サブジャンルごとにガイド情報を探索すればよいため、情報選別を効率的に行うことが可能となる。
【００２５】
階層管理する場合には、ガイド情報の選別に関し、サブジャンル間の優劣を定める優先度を設定しておいてもよい。こうすることにより、優先度の設定方法に応じて最適な情報、次善の情報というように、一定の傾向を持たせてガイド情報を提供することができる。例えば、サブジャンル間の優劣は、ユーザの趣味・嗜好や、年齢、性別などに応じて設定することができる。このように設定した場合には、ユーザの趣味・嗜好に沿ったガイド情報を優先的に提供し、かかる情報が存在しない場合に、趣味・嗜好から外れるガイド情報を提供するということが可能となる。また、別の態様として、サブジャンル間の優劣は、予算の額に応じて定めても良い。このように設定した場合には、ユーザの予算に適合するガイド情報を優先的に提供し、かかる情報が存在しない場合に、予算枠を外れるガイド情報を提供することが可能となる。ここで説明したように、サブジャンル間に優劣を持たせることにより、ガイド情報の提供に一定の傾向を持たせることが可能となり、ガイド情報の有用性を更に向上させることが可能となる。
【００２６】
本発明は、上述した種々の特徴を必ずしも全て備えている必要はなく、一部を省略したり適宜組み合わせたりして構成することができる。本発明は、上述したガイド情報選別システムとして構成する他、コンピュータによってガイド情報を提供するガイド情報提供方法として構成することもできる。また、ガイド情報を提供するためのコンピュータプログラムとして構成したり、このコンピュータプログラムの少なくとも一部を記録した記録媒体として構成したりすることもできる。この場合、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。
【発明を実施するための最良の形態】
【００２７】
本発明の実施例について以下の順序で説明する。
Ａ．システム構成：
Ｂ．データ構造：
Ｃ．ガイド情報提供の制御処理：
Ｄ．スケジュール登録・変更処理：
Ｅ．情報ボックス・メンテナンス処理：
Ｆ．スケジュール・ガイド処理：
Ｆ１．ガイド情報選択処理：
Ｆ２．ジャンル内情報選択処理：
Ｆ３．ガイド情報選択例：
Ｇ．第２実施例：
Ｇ１．ガイド情報選択処理：
Ｇ２．優先度設定処理：
Ｇ３．ジャンル内情報選択処理：
【００２８】
Ａ．システム構成：
図１は実施例としてのガイド情報選別システムの構成を示す説明図である。ガイド情報選別システムは、ユーザが指定した出発地から目的地までの経路案内を行う際に、その移動過程でユーザが有効活用できる情報を選別するシステムである。本実施例では、選別された情報をユーザに提供するシステムとして構成しているが、情報の提供は必須ではなく、例えば、選別された情報をユーザが適宜参照するためのデータベースとして登録しておくようにしてもよいし、選別された情報に基づいて経路案内の目的地を自動設定するようにしてもよい。
【００２９】
本実施例では、ユーザが、予めスケジュールを登録しておくと、ガイド情報選別システムが種々の情報源から有用な情報を収集しておくものとした。ユーザがスケジュールを実行する際には、ガイド情報選別システムは、収集した情報の中からユーザが有効活用できる情報を、移動経路とともに提供する。もっとも、これは一例に過ぎず、本実施例のガイド情報選別システムは、スケジュールと無関係に、単に出発地と目的地を指定した経路案内を行わせる態様で利用することもできる。また、提供すべき情報は、事前に収集しておくだけでなく、リアルタイムに収集する態様で実現してもよい。
【００３０】
実施例のガイド情報選別システムは、情報提供サーバ２００（以下、単に「サーバ」と呼ぶこともある）と、端末１００とをインターネットＩＮＴで接続して構成される。図中の例では、端末１００はカーナビゲーション装置である。端末には、この他、携帯電話、ノートＰＣ、ＰＤＡなど携帯可能な種々の装置が利用可能である。端末１００には、情報提供サーバ２００から提供されるガイド情報を取得するためにインターネットＩＮＴとの通信機能が要求されるが、スケジュールの実行中に常時、インターネットＩＮＴへのアクセスが常時確保されている必要はない。図の例では、インターネットＩＮＴを適用した例を示したが、インターネットＩＮＴに代えて、イントラネットなどの限定的なネットワークを用いることも可能である。
【００３１】
ガイド情報選別システムは、上述の通り、サーバ２００と端末１００とを中心として構成されるが、この他にもパソコン３００および多数のＷｅｂサーバ４００［１］、４００［２］を含めることができる。パソコン３００は、サーバ２００にスケジュールの登録、およびスケジュールに従って事前に収集された情報の管理を行うための装置である。本実施例では、これらの機能は、サーバ２００から提供されるＷｅｂページによって実現するものとした。従って、上述の機能を実現するためには、パソコン３００はブラウザを搭載していれば足りる。上述の機能は、端末１００でも実現可能である。この意味で、パソコン３００は端末１００の一種と呼ぶこともできるが、スケジュールの登録等の機能は、デスクトップ型のパソコンなど携帯不能な装置でも実現可能であるため、本実施例では端末１００と区別して示した。
【００３２】
Ｗｅｂサーバ４００［１］、４００［２］（以下、両者をＷｅｂサーバ４００と総称することもある。）は、インターネット上のＷｅｂサイトを通じて種々の情報を提供するサーバである。図中では、Ｗｅｂサーバ４００［１］は観光情報を提供し、Ｗｅｂサーバ４００［２］はグルメ情報を提供する例を示した。提供される情報には、これらに限らず、ショッピング情報、行政情報など多種多様な情報が含まれる。Ｗｅｂサーバ４００は、ガイド情報選別システムに特化したサーバである必要はない。ただし、ガイド情報選別システムと提携したサーバとしておけば、より利便性の高いシステムを構築することができる。例えば、Ｗｅｂサーバ４００が情報を規定のフォーマットに従って提供することにより、本システムの情報収集効率を向上させることができる。
【００３３】
図中には、ガイド情報選別システムとしての機能を提供するための情報提供サーバ２００の機能ブロックを併せて示した。本実施例では、これらの機能ブロックは、これらの機能を実現するためのＣＧＩ（Common Gateway Interface ）などで構成されたコンピュータプログラムを情報提供サーバ２００にインストールすることによってソフトウェア的に実現される。図中の機能ブロックの少なくとも一部は、ＡＳＩＣなどの回路によって、ハードウェア的に構成することも可能である。
【００３４】
サーバ２００は、図示する４通りのデータベースを備えている。個人プロファイル２０１は、後述する通り、ユーザＩＤ、氏名、生年月日などのユーザ個人の識別情報、ユーザの趣味、嗜好などの情報、および画面や音声出力などに関するカスタマイズの情報を格納する。個人プロファイル２０１の読み出し、書き込みは、プロファイル管理部２４０が制御する。
【００３５】
汎用情報ＤＢ２０２は、ガイド情報選別システムがユーザに提供する汎用情報を格納する。汎用情報とは、スケジュールに無関係に提供可能な情報を言い、ニュース、天気予報、各種の広告などが含まれる。音楽を含めても良い。マイボックス２０３は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ２００が収集した情報（以下、「スケジュール関連情報」と称する）を格納する。マイボックス２０３の内容についても後述する。本実施例では、汎用情報およびスケジュール関連情報は、それぞれ「天気」、「ニュース」、「食事」、「スイーツ」などのジャンルに分けて格納、管理されている。本実施例では、汎用情報とスケジュール管理情報のジャンルは同一として説明するが、両者は異なっていてもよく、いずれか一方の情報についてのみ設けられているジャンルが存在してもよい。
【００３６】
地図ＤＢ２０４は、スケジュールに基づいて定まる目的地までの経路の探索や案内に使用されるデータベースであり、道路をノード・リンクの集合で表した道路ネットワークデータと、地図を表示するための描画データとを格納する。本実施例では、サーバ２００は、これらのデータベースを活用しながら、以下に示す各機能ブロックの作用によって、ガイド情報の提供を行う。道路ネットワークデータには、車両で移動する際に活用できる車両用のネットワークデータ、歩行時に活用できる歩行者用のネットワークデータ、交通機関を利用する際に活用できる交通機関用のネットワークデータなどを含めることができる。描画データには、地図に含まれる各地物について、代表点の位置座標、描画用のポリゴンデータ、地物の種別を含む属性などが格納されている。
【００３７】
通信部２１０は、インターネットＩＮＴを介した情報授受を制御する機能を奏する。情報収集部２５０は、通信部２１０を介して得られた情報を、汎用情報ＤＢ２０２またはマイボックス２０３に格納したり、逆にこれらのデータベースから情報を読み出したりする機能を奏する。一例として、情報収集部２５０は、パソコン３００との間で情報授受を行い、ユーザからの指定に従って、マイボックス内のスケジュールの更新、読み出しなどを行う。また、情報収集部２５０は、Ｗｅｂサーバ４００にアクセスして、汎用情報ＤＢ２０２に格納すべきニュース、広告等の汎用情報を収集したり、マイボックス２０３に格納すべき情報、即ちスケジュール関連情報を収集したりする。
【００３８】
情報提供制御部２３０は、個人プロファイル２０１、汎用情報ＤＢ２０２、マイボックス２０３を参照し、スケジュールの実行中にユーザに提供すべきガイド情報の取捨選択を行う。取捨選択するための処理内容については後述するが、本実施例では、汎用情報およびスケジュール関連情報の各ジャンルについて、ユーザの移動目的や移動状況を評価する評価パラメータとの関係で必要度が設定されている。必要度を与えるために設定されているデータを以下では「推奨データ」と呼ぶ。情報提供制御部２３０は、評価パラメータに応じて、この推奨データを参照し、各ジャンルの必要度を求めた上で、必要度の高いジャンルから提供すべきガイド情報を選択する。このような情報提供制御部２３０の機能によって、サーバ２００は、ユーザのその時々の状況において、それぞれ有用性の高い情報を提供することが可能となる。
【００３９】
経路案内部２６０は、マイボックス２０３に登録されたスケジュールに従って移動する際の移動経路や、スケジュール関連情報で得られた各地点まで移動するための寄り道経路を探索する。経路探索は、地図ＤＢ２０４の道路ネットワークデータを参照し、ダイクストラ法など周知の方法を適用して実現することができる。経路案内部２６０は、また、スケジュール実行時には、描画データに基づいて地図表示を行うとともに、地図上に移動経路や寄り道経路の表示を行う。
【００４０】
出力データ生成部２２０は、情報提供制御部２３０および経路案内部２６０から提供されるデータに基づいて、端末１００に表示するための表示データを生成する。本実施例では、多種多様な端末１００を利用できるよう、ＨＴＭＬ、ＸＭＬを利用して表示データを生成するものとした。出力データ生成部２２０は、ガイド情報等を提供するための画面の他、スケジュールを登録・管理するための画面、動作を選択するためのメニュー画面など、ガイド情報選別システムに要求される種々の画面の表示データを生成する。
【００４１】
図中に端末１００に備えられる機能ブロックを併せて例示した。端末１００では、主制御部１１０の管理下で、図示する各機能ブロックが稼働する。本実施例では、これらの機能ブロックは、端末１００としての機能を実現するためのプログラムによって、ソフトウェア的に構成したが、ハードウェア的に構成してもよい。
【００４２】
通信部１２０は、インターネットＩＮＴを介した情報の授受を制御する。コマンド入力部１３０は、ユーザの操作に応じてメニューの選択、案内の開始、表示すべき情報の選択など種々のコマンドを入力する。表示制御部１５０は、情報提供サーバ２００からのデータに従って画面表示を行う機能を奏する。本実施例では、ブラウザによって提供される。ＧＰＳ（Global Positioning System）１４０は、ユーザの現在位置を検出する。現在位置は、サーバ２００に送信され、ガイド情報や経路案内の表示制御に活用される。
【００４３】
ここで示したのは、ガイド情報選別システムの一例に過ぎない。図１中に示した各機能ブロックは、必ずしも情報提供サーバ２００または端末１００に全て備えられている必要はなく、分散処理によって複数のサーバ等の連携で実現するようにしてもよい。
【００４４】
Ｂ．データ構造：
図２は個人プロファイル２０１、マイボックス２０３のデータ構造を示す説明図である。左側に個人プロファイル２０１の内容を示し、右側にマイボックス２０３の内容を示した。個人プロファイル２０１は、ガイド情報選別システムの利用者を管理するためのデータベースであるとともに、ユーザにとって有用な情報を選択する際に活用できる情報を提供するデータベースともなる。個人プロファイル２０１には、図示する通り、ユーザＩＤ、氏名、生年月日、性別、家族構成などのユーザ個人の識別情報が格納される。図の例では、ユーザＩＤとして「ＵＳＲ００１」が格納されている例を示した。家族構成は、「妻、娘１人、息子１人」という人数構成を格納した例を示したが、各人の年齢や趣味、嗜好などを格納するようにしてもよい。家族構成を詳細にするほど、収集・選択される情報の有用性が向上する。例えば、家族でレジャーに出かける場合のガイド情報を提供する場合、娘が小学生なのか女子高生なのかによって、有用な情報は異なるからである。
【００４５】
個人プロファイル２０１には、ユーザの趣味、嗜好などの情報も格納される。この情報もスケジュール関連情報の収集およびガイド情報の選択に活用される。図示するように、ラーメン好みであるなどの嗜好を把握しておくことにより、レストラン情報を提供する際にはラーメン屋を優先させるなどの態様で、ユーザに有用な情報を提供することが可能となる。趣味についても同様である。図の例では、嗜好および趣味を例示したが、この他、職業、ガイド情報の利用実績など、ガイド情報の収集・選択に活用可能な種々の情報を含めることができる。
【００４６】
個人プロファイル２０１には、更に、オプション情報を格納してもよい。図の例では、情報提供に関するカスタマイズの情報を例示した。画面色とは、情報提供画面の背景色の選択を意味する。音声とは、音声出力時の読み上げ音声の種類（以下、「音声種別」と呼ぶ）を意味する。本実施例では、予め登録された複数種類の音声種別の中からユーザの好みの音声種別を選択する態様を採った。音声に格納された「ＦＶＯＩＣＥ１」は、登録された女性音声の識別コードである。サーバ２００がガイド情報等を音声出力する際には、この音声識別コードを反映した音声出力データを生成し、端末１００に送信すればよい。
【００４７】
マイボックス２０３は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ２００が収集した情報（以下、「スケジュール関連情報」と称する）を格納する。マイボックス２０３と個人プロファイル２０１とは、ユーザＩＤで対応づけられている。スケジュールには、日付、時間帯、場所、スケジュールの内容などが登録される。図の例では、３月１日には、「１３時からＺ社で会議」という予定が入っており、その前の時間帯、１０時〜１３時の間は特に予定がない移動時間となっていることが分かる。また、３月２日の例では、「１１時〜１２時に来客」の予定が入っており、「１２時〜１３時過ぎに昼食」の予定が入っていることが分かる。
【００４８】
情報ボックスには、スケジュール関連情報が登録されている。この情報とスケジュールとは、「関連ＩＤ」で関連づけられる。図中の例で示す情報には、「ＩＮＦＯ１」なる関連ＩＤが付されており、３月１日のスケジュールにおける移動時間に「ＩＮＦＯ１」なる関連ＩＤが付されているため、この情報は３月１日の移動中に活用できる情報であることが分かる。情報ボックスには、多くのスケジュール関連情報が登録される。関連ＩＤは、それぞれの情報に固有としてもよいし、スケジュールの項目に固有としてもよい。例えば、図の例において、３月１日の「移動」に関連するスケジュール関連情報が複数存在する場合を考える。前者の例によれば、これらの全情報には個別の関連ＩＤが付されるため、スケジュールにおける「移動」に対して、複数の関連ＩＤが登録されることになる。後者の例によれば、スケジュール関連情報には、全て「移動」に付された関連ＩＤ「ＩＮＦＯ１」が付されることになる。いずれの態様を採るかは任意に選択可能である。前者の態様を採る場合において、「ＩＮＦＯ１＊＊＊」のように、共通の「ＩＮＦＯ１」を含む形で関連ＩＤを設定することにより、「移動」との対応関係を容易に判断できるようにしてもよい。
【００４９】
それぞれのスケジュール関連情報には、図中に示す種々の情報が格納される。「パス」は、情報の格納先を表している。サーバ２００内のディレクトリやファイル名で表しても良いし、Ｗｅｂサーバ４００に格納された情報のＵＲＬを用いても良い。「名称」には、店舗名、名所の名称、地名など、スケジュール関連情報を表す名称が格納される。「場所」は店舗の所在地、名所の所在地など、スケジュール関連情報に関連する地点を表す緯度、経度が格納される。Ｗｅｂサーバ４００を参照して、スケジュール関連情報を収集する場合、住所は特定できても緯度、経度までは特定できないことがある。このような場合には、「場所」は住所で登録可能としてもよい。本実施例では、ガイド情報を提供する際の処理の簡略化を図るため、「場所」は緯度、経度の形式に統一して格納するものとした。緯度、経度が直接、収集できなかった場合には、サーバ２００が住所に基づいて地図ＤＢ２０４を参照し緯度、経度を検索する。
【００５０】
マイボックスには、この他、ユーザが行きたいと思う場所を、ユーザ自身が登録可能としてもよい。この登録には、スケジュール関連情報と同様のフォーマットを用いることができる。この情報は、スケジュールと無関係に事前に登録可能としておくことが好ましい。こうすることで、ユーザは、雑誌等で興味を得た情報を登録しておくことが可能になるとともに、その付近に出かける際に、その情報を有効活用することが可能となる。
【００５１】
「音声」は音声出力データの出力時の音声識別コードである。個人プロファイル２０１に登録されているのと同様、予めサーバ２００に登録されている音声種別を特定するための情報である。この音声識別コードは、Ｗｅｂサイトで提供される情報に音声識別コードを埋め込まれている場合に格納される。こうすることで、情報の提供者は、自己がＷｅｂサイトを通じて提供する情報の一部に、音声識別コードを埋め込んでおくだけで、ガイド情報選別システムで利用される時の音声種別を制御することが可能となる。例えば、図の例であれば、「○○ラーメン」の店主は、自己の好みの音声で、自己の店舗の宣伝や案内を提供することが可能となるのである。
【００５２】
「所要時間」は、スケジュール関連情報に従って行動する際に必要となる時間余裕を表している。例えば、ラーメン屋の場合には、ラーメンを注文してから食べ終わるまでの時間を所要時間とすることができる。人気の高いラーメン屋の場合には、平均の待ち時間を考慮してもよい。所要時間は、情報の提供者が情報内に埋め込んでおくようにしてもよいし、スケジュール関連情報で与えられる店舗、名所などの種別、人気度等に応じて平均的な値をサーバ２００が設定するようにしてもよい。
【００５３】
「提供履歴」は、スケジュール関連情報が端末１００に提供された履歴を記録する。図の例では、この情報が、２００６年３月１日に、端末１００［１］に提供されたことを示している。提供履歴を参照することにより、サーバ２００は同一の情報が繰り返しユーザに提供されることを回避することができる。提供履歴には、ユーザが、この情報を活用したか否かの履歴を含めるようにしてもよい。
【００５４】
以上で説明したデータ構造は、一例に過ぎない。個人プロファイル２０１およびマイボックス２０３共に、図示した項目全てのデータを格納している必要はなく、一部の項目を省略してもよい。また、図示した項目以外のデータを含めるようにしてもよい。データの格納形式も、図の例に限らず、種々の形式を採り得る。
【００５５】
図３は推奨データの例を示す説明図である。先に説明した通り、ユーザの移動目的や移動状況を表す評価パラメータに対して、各ジャンルの情報の必要度を与えるデータである。図中に示す「天気」、「ニュース」、「相場」等がそれぞれジャンルに相当する。評価パラメータとしては、移動目的に関連する項目として「シーン」、移動状況に関連する項目として「時間帯」が設けられている。「シーン」とは、「通勤、出張、ひとり、カップル、ファミリー、仲間」など、ユーザが移動する際に、どのようなグループで移動しているか、どのような目的で移動しているかを表す項目である。図に示した評価パラメータは一例であり、更に多くの評価パラメータを設けても良い。また、図の例では、「シーン」と「時間帯」で個別に必要度を与えるテーブルとしているが、この対応関係は、「シーン」と「時間帯」とが決まった時に、必要度を与える２次元的なテーブルとして構成してもよい。更に多くの評価パラメータに応じて定まる多次元的なテーブルとして構成することも可能である。
【００５６】
推奨データでは、各評価パラメータに対して必要度が与えられる。例えば、「天気」というジャンルについては、「通勤」というシーンでは「○」となり、「朝５〜１１時」という時間帯であれば「◎」となる。必要度の使用方法については、ガイド情報の選択処理で説明する。本実施例では、「◎」「○」「×」というランクで必要度を表しているが、数値で表すようにしてもよい。
【００５７】
推奨データには、この他、「優先度」および配信のための「条件」も設定されている。「優先度」は、ガイド情報を提供する際にジャンル間の優劣を与えるデータである。評価パラメータに基づいて判断される必要度が同等となるジャンルが複数存在する場合には、「優先度」が高い情報が提供されることになる。「優先度」も高い順にＳ、Ａ、Ｂ、Ｃというランクで表しているが、数値で表すようにしてもよい。
【００５８】
「条件」は、必要度および優先度に関わらず、情報の提供可否を制御するために用いられる。図中の例では、「天気」には、「運転開始５分後＋渋滞時」という条件が付されている。この条件によれば、「天気」は、運転開始から５分後までの期間、および渋滞中を除く期間では、必要度、優先度が高い場面であっても配信されないことになる。この条件は、評価パラメータに「運転開始後の経過時間」、「渋滞中か」という項目を設け、「天気」については経過時間が「５分後」まで、および「渋滞中」の場合にそれぞれ必要度を「◎」に設定し、その他の場合には「×」に設定することによって実現してもよい。
【００５９】
「条件」には、情報提供の可否を規定するものだけでなく、「ファミレス」に付されている「”食事”で該当する条件の店がなかったときに案内」という条件のように、ジャンル間の情報提供の優劣を規定するものも含めうる。これは、実質的には、「食事」というジャンルを、「ファミレス」と「その他」のサブジャンルに分けた上で、「その他」を「ファミレス」よりも優先するという優先度を設定したのと同等である。図中に示した「条件」は、このようにそれぞれ評価パラメータや優先度に組み入れることも可能である。
【００６０】
Ｃ．ガイド情報提供の制御処理：
図４はガイド情報選別システムにおける制御処理のフローチャートである。サーバ２００が実行するメインルーチンに相当する。処理を開始すると、サーバ２００はユーザからのログインを受け付け（ステップＳ１０）、メニュー画面を提示して、ユーザからの指示を入力する（ステップＳ１２）。図中にメニュー画面ＭＥＮＵの例を示した。この例では、「１．スケジュール登録・変更」、「２．情報ボックス・メンテナンス」、「３．スケジュール・ガイド」、「４．個人プロファイル管理」の４通りのメニューを設けた。サーバは、ユーザからの選択指示に応じて（ステップＳ１４）、それぞれのメニューに対応した処理を実行する。
【００６１】
「１．スケジュール登録・変更」が選択された場合には、サーバ２００は、スケジュール登録・変更処理を行う（ステップＳ１００）。これは、マイボックス２０３にスケジュールを登録したり、登録済みのスケジュールを変更したりするための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。スケジュール登録・変更処理の内容については後で詳述する。
【００６２】
「２．情報ボックス・メンテナンス」が選択された場合には、サーバ２００は、情報ボックス・メンテナンス処理を行う（ステップＳ２００）。これは、マイボックス２０３に蓄積されたスケジュール関連情報の追加、変更、削除を行うための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。情報ボックス・メンテナンス処理の内容については後で詳述する。
【００６３】
「３．スケジュール・ガイド」が選択された場合には、サーバ２００は、スケジュール・ガイド処理を行う（ステップＳ３００）。これは、スケジュールの実行時に、スケジュールに従った移動経路の案内や、ガイド情報の提供を行うための処理である。ユーザが移動している状態での案内、情報提供を行う処理であるため、携帯性のある端末１００を利用することになる。
【００６４】
「４．個人プロファイル管理」が選択された場合には、サーバ２００は、個人プロファイル管理処理を行う（ステップＳ４００）。これは、個人プロファイル２０１の登録、変更、削除を行うための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。この処理では、サーバ２００は、個人プロファイル２０１の内容（図２参照）を、ユーザのパソコン３００等に表示し、ユーザが各項目を入力すると、その内容で個人プロファイル２０１を更新する。
【００６５】
Ｄ．スケジュール登録・変更処理：
図５はスケジュール登録・変更処理のフローチャートである。メインルーチン（図４）のステップＳ１００に相当する処理である。先に説明した通り、この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。
【００６６】
この処理を開始すると、サーバ２００は、マイボックス２０３から既存のスケジュールを読み込む（ステップＳ１０２）。スケジュールが未登録の場合には、実質的に何も読み込まれないまま、ステップＳ１０２の処理を終えることになる。そして、サーバ２００は、読み込んだスケジュールをパソコン３００の画面に表示し、ユーザの操作に基づいてスケジュールの編集コマンドを入力する（ステップＳ１０４）。
【００６７】
図中にスケジュールの編集画面の例を示した。パソコン３００には、指定された日のスケジュール画面Ｗ１が表示される。既に登録済みのスケジュールは、この画面Ｗ１に表示される。図中の例では、「１３時からＺ社で会議」という予定が登録済みである。ユーザがパソコン３００のマウスまたはキーボードを操作して、画面Ｗ１内でいずれかの時間帯を指定すると、スケジュールを入力するためのサブウィンドウＷ２が表示される。既に予定を登録済みの時間帯をクリックした場合には、サブウィンドウＷ２には、登録済みの予定内容が表示される。ユーザは、このサブウィンドウを利用して、日時、タイトル、場所、メンバー、その他のメモなどを登録することができる。また、スケジュール関連情報の収集を行うか否か（ＯＮ／ＯＦＦ）を切り換えることができる。情報収集をＯＮとすると、サーバ２００によって、スケジュールとスケジュール関連情報とを対応づける関連ＩＤが割り振られる。図中の例は、関連ＩＤとして「ＩＮＦＯ１」が割り当てられた状態を示している。スケジュールの編集は、図示した画面に限らず、周知の種々の編集画面を利用することが可能である。
【００６８】
図では、スケジュール関連情報の収集を行うか否かをユーザが指定する例を示した。情報収集のＯＮ／ＯＦＦの指定は不要としてもよい。例えば、サーバ２００は、予定が登録された場合に、その直前の空き時間に対して、自動的に情報収集をＯＮに設定するようにしてもよい。また、このような設定をするまでなく、全時間帯について情報収集を行うようにしてもよい。例えば、予定が登録されている時間帯については、その予定に対応した情報を収集し、空き時間については次の予定までの移動中で有効活用できる情報を収集すればよい。
【００６９】
スケジュールの編集が完了すると、サーバ２００は編集結果をマイボックス２０３に格納して、スケジュールを更新する（ステップＳ１０６）。そして、情報収集処理、即ちスケジュール関連情報を収集するための処理を実行する（ステップＳ１１０）。
【００７０】
図６は情報収集処理のフローチャートである。この処理では、サーバ２００はマイボックス２０３からスケジュールを読み込み、情報収集の対象となるべき予定、即ち対象スケジュールを抽出する（ステップＳ１１２）。本実施例では、先に説明した通り、情報収集が「ＯＮ」に設定された予定を抽出することになる。
【００７１】
サーバ２００は、この対象スケジュールに対して、直前のスケジュールの場所を開始時位置として設定し、対象スケジュールの直後の場所を終了時位置に設定する（ステップＳ１１４）。そして、開始時位置から終了時位置までの経路探索を行う（ステップＳ１１６）。経路探索は、地図ＤＢ２０４の道路ネットワークデータを参照して行うことができる。ここでは、対象スケジュール前後の予定が与えられているため、この予定に支障がない移動方法を探索する必要がある。つまり、直前の予定の終了時刻に開始時位置を出発し、直後の予定の開始時刻には終了時位置に到達していなくてはならない。このような経路は、所要時間最短という条件で探索すればよい。ダイクストラ法を用いる場合には、各リンクの通過所要時間を反映したコストが最小となるよう、経路探索を行えばよい。経路探索には、種々の条件を考慮することができ、例えば、車両、徒歩、交通機関利用時など、移動手段を多様に変化させて、それぞれの経路を求めても良い。徒歩の時には、坂道や階段に高いコスト値を付すことによって、坂道や階段を避ける経路を探索してもよい。同様に、ユーザの要望をコストに反映させることで、種々の要望を考慮した経路探索を行うことが可能である。
【００７２】
本実施例では、対象スケジュールが移動不能な予定の場合もある。例えば、「会議」という予定に対して、スケジュール関連情報の収集がＯＮとなっている場合が該当する。このように移動不能な予定に対しては、ステップＳ１１６の処理は省略してもよい。
【００７３】
サーバ２００は、次に、個人プロファイル２０１から、ユーザの嗜好および趣味に関するデータを読み込む（ステップＳ１１８）。そして、以上で取り込んだ情報に基づいてＷｅｂサーバから情報を収集する（ステップＳ１２０）。この情報収集は、ユーザに有用な情報を提供することが目的であるから、次の条件で行う。まず、ユーザの嗜好、趣味に合致または類似する情報であることが条件となる。例えば、ユーザが「ラーメン好き」という嗜好を有している場合には、合致する情報として「ラーメン屋」の案内情報を収集すればよい。また、類似する情報として、「中華料理屋」や、そば屋、うどん屋などの麺類の店の案内情報を収集すればよい。趣味についても同様である。情報収集時には、スケジュールに同行するメンバー構成を考慮してもよい。例えば、家族でのレジャーの場合には、家族構成や家族のメンバーの嗜好、趣味等を考慮することができる。出張の場合には、会社の同僚の嗜好、趣味等を考慮することもできる。
【００７４】
第２の条件は、直後の予定に間に合う場所的範囲で情報収集を行うことである。例えば、いくら人気のあるラーメン屋に関する情報であっても、次の予定に間に合わないほど遠くにある店についての情報では活用できないからである。この条件は、種々の方法で判断することができる。例えば、ステップＳ１１６で探索した経路から所定距離内の場所についての情報というように簡易な方法で判断するようにしてもよい。この場合の「所定距離」は、次の予定までの余裕時間、次の目的地までの距離、ユーザの移動速度を考慮して設定することができる。また、別の態様として、スケジュール関連情報に対応した場所を経由地としてステップＳ１１６の経路探索を行い、直後の予定に間に合うか否かを判断するようにしてもよい。
【００７５】
以上の条件に合致する情報が得られると、サーバ２００は、その情報に、対象スケジュールに付された関連ＩＤを付して、情報ボックスに格納する（ステップＳ１２２）。サーバ２００は、情報収集処理を適宜、繰り返し実行することで、関連ＩＤが付された全スケジュールについてスケジュール関連情報を収集するとともに、それぞれの予定について、できるだけ多くのスケジュール関連情報を収集するよう努める。情報収集処理は、例えば、全スケジュールについて一定数までの情報が収集されるまで繰り返し実行するようにしてもよい。
【００７６】
以上の説明では、スケジュールの登録・変更がなされた時に情報収集処理を行う場合を示した。情報収集処理は、この他のタイミングにも実行可能である。例えば、スケジュールが実行されるまでの間、スケジュールの登録・変更が行われるか否かとは無関係に定期的に実行してもよい。このように繰り返し実行することにより、より多くの情報、かつより新しい情報を収集することが可能となる。
【００７７】
Ｅ．情報ボックス・メンテナンス処理：
図７は情報ボックス・メンテナンス処理のフローチャートである。メインルーチンのステップＳ２００に相当する処理である。この処理は、サーバ２００が収集したスケジュール関連情報を、スケジュールの実行前にユーザが確認し、不要な情報を削除したり、収集された情報のうち必ず提供するよう指示するための処理である。先に説明した通り、この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。
【００７８】
処理を開始すると、サーバ２００はユーザからスケジュール関連情報を表示する対象となる予定、即ち対象スケジュールの指定を受け付ける（ステップＳ２０２）。ユーザがパソコン３００で、対象スケジュールを指定すると、サーバ２００はマイボックス２０３の情報ボックスを参照して、対象スケジュールに割り振られた関連ＩＤが付された情報を読み込む（ステップＳ２０４）。
【００７９】
サーバ２００は、読み込んだ結果をパソコン３００に表示し、スケジュール関連情報の編集を受け付ける（ステップＳ２０６）。図中にパソコン３００に表示される編集画面例を示した。この例では、画面の左側に矢印で示すように、地図上にスケジュールに従った移動経路が表示される。そして、スケジュール関連情報の項目が、右下に表示され、地図上には、この項目に対応する場所が表示される。図中の例では、スケジュール関連情報として、情報ａ「○○ラーメン」、情報ｂ「△△チャンポン」、情報ｃ「＊＊うどん」が得られている。左側の地図では、ａ〜ｃの符号で、それぞれの情報に対応する店舗の位置が表示される。ここでは、店舗の例を示したが、名所等についても同様である。また、右上には登録されているスケジュールが表示される。
【００８０】
図示した編集画面では、上述の通り、ユーザは地図によってスケジュール関連情報に対応する地点（以下、「設定場所」という）と移動経路との位置関係を把握することができ、同時に、右上のスケジュール画面によって次の予定までの時間余裕を把握することができる。更に、右下の画面で各項目をクリックすると、詳細な情報が表示されるようにしてもよい。ユーザは、これらの情報を一覧して、スケジュール関連情報の要否を判断する。例えば、情報ａ「○○ラーメン」は店の場所が遠いため不要と判断した場合には、画面の右下のエリアで、情報ａのチェックボックスをチェックし、「削除」ボタンをクリックすればよい。また、必ず提供されることを要求する情報がある場合には、チェックボックスにチェックした上で「登録」ボタンをクリックすればよい。
【００８１】
サーバ２００は、編集結果を入力すると、それに応じて情報ボックスの内容を更新し（ステップＳ２０８）、情報ボックス・メンテナンス処理を終了する。実施例では、情報を削除および提供対象として登録する方法を例示したが、更に、ユーザ自身が収集した情報を追加可能としてもよい。例えば、ステップＳ２０６中に示した編集画面に、ユーザが情報のパスまたはＵＲＬを入力可能とし、ステップＳ２０８では、サーバ２００がこれに従って、情報を取得して情報ボックスに格納するようにすればよい。
【００８２】
Ｆ．スケジュール・ガイド処理：
ユーザはスケジュールの実行時になると、メニュー画面ＭＥＮＵ（図４参照）でスケジュール・ガイドを指示する。サーバ２００は、この指示に応じて、端末１００に対して、ユーザがスケジュールを実行する際の支援情報、つまり目的地までの経路その他の有用な情報を提供する。以下では、まず端末１００の表示画面例によって、スケジュール・ガイド処理における具体的な処理内容を説明した後、この処理を実現するためのフローチャートを示す。
【００８３】
先に説明した通り、スケジュールを開始する時点で、サーバ２００には、スケジュール・ガイドに必要な情報は一通り蓄積されている。従って、ユーザは端末１００にこれらの情報を一括ダウンロードしておくことにより、サーバ２００との通信を行わずにスケジュール・ガイド処理を実行させることも可能である。ただし、以下では、端末１００はサーバ２００と適宜、通信可能な環境にあることを前提として説明する。スケジュール・ガイド中にサーバ２００と通信することによって、ユーザの現状に応じて、提供する情報の内容を柔軟に変更できる利点があるからである。
【００８４】
図８はスケジュール・ガイド処理のフローチャートである。ユーザが移動を開始した後の現在位置に応じて経路の案内、およびガイド情報の提供を行うための処理である。サーバ２００は、まず、マイボックス２０３から、スケジュールデータおよび経路探索結果を読み込む（ステップＳ３０２）。そして、ユーザの現在位置および現在時刻を入力する（ステップＳ３０３）。現在位置は、端末１００のＧＰＳ１４０を利用して検出することができる。
【００８５】
ユーザの現在位置が所定時間、移動しない時は停止中と判断し（ステップＳ３０４）、サーバ２００は、地図ＤＢ２０４から立寄場所を特定し（ステップＳ３０５）、マイボックス２０３に走行履歴として記録する（ステップＳ３０６）。立寄場所は、地図ＤＢ２０４を参照することにより、現在位置の座標に対応する地物を抽出すればよい。対応する地物が得られない場合には、立寄場所不明と扱うものとした。現在位置に含まれる誤差範囲を考慮して、所定距離内の地物を立寄場所として扱っても良い。停止中でない場合には（ステップＳ３０４）、これらの処理はスキップされる。
【００８６】
次に、サーバ２００は、ガイド情報選択処理を実行する（ステップＳ３１０）。ユーザのシーン、時間帯等（図３参照）に応じて、配信条件に適合するガイド情報を選択する処理である。送信すべき情報は、汎用情報およびスケジュール関連情報の双方を対象として選択される。ガイド情報選択処理の処理内容は後述する。サーバ２００は、こうして選択されたガイド情報を端末１００、即ちカーナビに出力する（ステップＳ５００）。
【００８７】
図中に端末１００の表示例を示した。本実施例では、端末１００の画面は、３つのウィンドウＷ１〜Ｗ３から構成される。ウィンドウＷ１には、地図、経路、および現在位置が表示される。ウィンドウＷ２には、気象情報、渋滞情報、および目的地までの距離、到着予想時刻などが表示される。ウィンドウＷ３には、その他のガイド情報が表示される。ウィンドウＷ３において、ユーザが「詳細を見る」をクリックすると、登録されている詳細なガイド情報を表示させることができる。「場所を確認」をクリックすると、ガイド情報が登録されている店舗位置がウィンドウＷ１に表示される。現在位置から店舗までの経路を併せて表示するようにしてもよい。
【００８８】
サーバ２００は、以上の処理を、目的地に到着するまで（ステップＳ５０２）、繰り返し実行する。上述の説明は、サーバ２００と端末１００との通信が確保されている状況での処理である。本実施例では、先に説明した通り、経路探索処理において、事前に経路探索結果やガイド情報が取得されている。従って、移動中の状況により、サーバ２００と端末１００との通信が遮断されている場合には、端末１００に取得済みのデータを用いて経路案内やガイド情報出力（ステップＳ５００）を行ってもよい。
【００８９】
Ｆ１．ガイド情報選択処理：
図９はガイド情報選択処理のフローチャートである。スケジュール・ガイド処理（図８）のステップＳ３１０に相当する処理であり、汎用情報ＤＢ２０２およびマイボックス２０３（図１参照）から、ユーザに提供すべきガイド情報を選択する処理である。
【００９０】
まず、サーバ２００は、汎用情報ＤＢ２０２およびマイボックス２０３のうち、提供するようにユーザが指示した情報の有無（図７のステップＳ２０６参照）を判定する（ステップＳ３１１）。かかる情報がある場合には、指定されたガイド情報を読み込み（ステップＳ３１２）、そのガイド情報の配信、配信実績の記録を行う（ステップＳ３４１）。
【００９１】
ユーザが指示した情報が無い場合（ステップＳ３１１）、サーバ２００はユーザに提供すべき情報を選択するため、モード、移動状況、配信実績、走行履歴を読み込む（ステップＳ３１５）。モードとは、推奨データのシーン（図３参照）に対応する情報である。本実施例では、スケジュールの内容および同行するメンバーから、サーバ２００がモードを判断するものとした。ステップＳ３１５を実行する段階、または経路案内を開始する段階で、ユーザにモードを選択させる方法を採ってもよい。移動状況は、本実施例では、推奨データの「時間帯」に対応する情報であり、ここでは現在時刻の入力となる。移動状況に対して多種類の評価パラメータが設けられている場合には、それぞれの評価パラメータに対応する情報を入力することになる。配信実績は、それぞれの情報と対応づけて汎用情報ＤＢ２０２およびマイボックス２０３に格納されている。走行履歴は、出発後の経過時間およびユーザが立ち寄った場所の履歴である。これらは、本実施例ではマイボックス２０３に格納されている。
【００９２】
サーバ２００は、これらの情報に基づいてジャンル毎に評価値を算出する（ステップＳ３１６）。本実施例では、必要度の総和で評価値を求めるものとした。まず、モードに基づいて推奨データ（図３）を参照し、必要度を求める（求められた必要度を数値で表したものを「モード評価値」と呼ぶ）。次に、移動状況に応じて同様に必要度を求める（求められた必要度を数値で表したものを「移動状況評価値」と呼ぶ）。そして、両者の和（モード評価値＋移動状況評価値）を「評価値」とするのである。これは、評価値の求め方の一例に過ぎず、両者に重み係数を乗じて和を求めてもよい、モード評価値、移動状況評価値のいずれか大きい方または小さい方を評価値として採用してもよい、または両者の積を評価値としてもよい。
【００９３】
図３の例に即して説明する。必要度「◎」、「○」、「×」をそれぞれ「２」、「１」、「０」の数値で表すとする。ジャンル「天気」については、「通勤」モードであれば、必要度「○」なのでモード評価値は「１」となる。「５〜１１時」の時間帯であれば、必要度「◎」なので移動状況評価値は「２」となる。従って、この状況に対する「天気」の評価値は「３」と求まる。その他のジャンルに対しても、モードおよび時間帯に応じて、それぞれ評価値を求めることができる。
【００９４】
サーバ２００は、次にジャンルをソートする（ステップＳ３１７）。ソートのキーは、任意に設定可能であるが、本実施例では、配信実績を第１キー、評価値を第２キー、優先順位を第３キーとした。こうすることで、未配信のジャンル、評価値の高いジャンル、優先度の高いジャンルが、上位に配置されることになる。
【００９５】
ソートが完了すると、サーバ２００は、走行履歴の立寄場所と同一ジャンル、および配信条件（図３参照）を満たさないジャンルを、配信対象から除外する（ステップＳ３１８）。例えば、ユーザが既にレストランに立ち寄っていることが走行履歴から得られている場合には、レストランのガイド情報が属するジャンル、即ち「食事」、「ファミレス」等を配信対象から除外するのである。こうすることで、途中の立ち寄りによって、ユーザにとって有用性が低くなった情報が繰り返し配信されることを回避できる。
【００９６】
これは、処理の一例に過ぎず、逆に、立寄場所と同一のジャンルを上位にソートし直す処理を施してもよい。例えば、ユーザが景色の美しい観光スポットに立ち寄っている場合には、ユーザが他にも景色の美しい場所を求めていると判断できる。従って、「観光名所」に相当するジャンルを上位にソートし直すことで有用性の高い情報を提供することが可能となる。走行履歴の立寄場所が含まれるジャンルに応じて、除外するか、上位にソートするかを切り換える態様を採ってもよい。
【００９７】
以上の処理が完了すると、サーバ２００は最上位のジャンルを配信対象として選択し（ステップＳ３１９）、ジャンル内情報選択処理を実行する（ステップＳ３２０）。これは、指定されたジャンルに含まれる種々のガイド情報の中から、配信すべき情報を選択する処理である。この処理によって、配信すべき情報が選択された場合には（ステップＳ３４０）、サーバ２００は、そのガイド情報を配信し、配信実績に記録して（ステップＳ３４１）、ガイド情報選択処理を終了する。
【００９８】
ジャンル内情報選択処理では、配信すべきガイド情報が存在しないこともある。例えば、指定されたジャンル内には、ユーザの現在位置から遠方にある地点に対するガイド情報しか収集されていない場合などである。情報が選択されなかった場合には（ステップＳ３４０）、サーバ２００は選択すべきガイド情報が得られるまで、ソートされた順序に従って、次のジャンルを指定し、ジャンル内情報選択処理を再試行する（ステップＳ３２０）。
【００９９】
Ｆ２．ジャンル内情報選択処理：
図１０はジャンル内情報選択処理のフローチャートである。ガイド情報選択処理（図９）のステップＳ３２０に相当する処理である。この処理では、サーバは、まず、ジャンルに該当するガイド情報を汎用情報ＤＢ２０２およびマイボックス２０３から読み込む（ステップＳ３２１）。
【０１００】
次に、サーバ２００は、ガイド情報をソートする（ステップＳ３２２）。ソートのキーは任意に設定可能であるが、本実施例では、モードの適合性を第１キー、情報の新しさを第２キー、情報のＰＲ度を第３キーとした（ステップＳ３２２）。モードの適合性とは、ガイド情報が、ユーザの指定したモードに適しているか否かの判断を言う。例えば、「カップル」モードでの移動中には、カップル向きのおしゃれなレストランはモードに適合しており、ファーストフードは非適合と判断される。この判断は、例えば、予めそれぞれのガイド情報に対して、適合するモードを登録しておき、この中に、ユーザから指定されたモードが含まれるか否かをサーバ２００が判断する方法を採ることができる。適合するモードの登録は、サーバ２００のオペレータが、それぞれのガイド情報の内容を判断して手作業で登録してもよい。ガイド情報の提供者が、自己のガイド情報の狙いを考慮して、適合するモードを設定した上でＷｅｂサーバ４００にアップロードするようにしてもよい。更に、店名や種別に基づいて、サーバ２００が適合するモードを自動設定してもよい。自動設定は、店名や種別とモードとを予め対応づけたテーブルを参照することにより、比較的容易に実現できる。もちろん、ここに例示した種々の方法を組み合わせて適用することも可能である。
【０１０１】
情報の新しさは、それぞれのガイド情報の最終更新日からの経過時間である。情報の新しさをソートキーとすることにより、新しい情報を優先的に提供することが可能となる。情報のＰＲ度は、ユーザにとってのガイド情報の魅力を表す評価値である。ＰＲ度は種々の方法で評価可能である。本実施例では、予め定めた表現、例えば「話題の…」、「行列ができる…」、「日本最大の…」などが、ガイド情報中に含まれる割合に基づいてＰＲ度を評価するものとした。割合とは、ＰＲ度の高い表現が、ガイド情報全体の表現の中で占める割合であり、それぞれの表現を単語数で数値化して求めることができる。ＰＲ度の高い表現が使用されている数量で評価してもよい。
【０１０２】
サーバ２００は、ガイド情報のソートが終了すると、最上位のガイド情報を抽出する（ステップＳ３２３）。そして、現在位置から、そのガイド情報に対応する地点（以下、「設置場所」と呼ぶ）までの所要時間を算出する（ステップＳ３２４）。所要時間は、両地点の直線距離に基づいて簡易に求めても良いし、両地点間の経路探索を行って得られる道のりに基づいて求めてもよい。
【０１０３】
こうして得られた所要時間が、予め設定された許容範囲内である場合には（ステップＳ３２５）、サーバ２００は、そのガイド情報を配信対象として選択する（ステップＳ３２９）。許容範囲を超えている場合（ステップＳ３２５）、当該ジャンル内の全ガイド情報について判断が終了するまでの間は（ステップＳ３２６）、ソートされた順に従って次のガイド情報について同様の処理を実行する（ステップＳ３２４、Ｓ３２５）。「許容範囲」は、このようにガイド情報の採否を決める判断基準となる値であり、任意に設定可能である。許容範囲を大きくすれば、現在位置から遠方にあるガイド情報が提供される可能性が高くなり、小さくすれば、条件を満たすガイド情報が得られにくくなる。許容範囲は、これらのバランスを考慮して、ユーザに対し有用な情報を適量提供できる範囲に調整すればよい。
【０１０４】
全てのガイド情報について所要時間が許容範囲を超えている場合には（ステップＳ３２５、Ｓ３２６）、サーバ２００は、予告情報を選択して（ステップＳ３２７）、ジャンル内情報選択処理を終了する。予告情報とは、現在位置からはやや遠方に位置するが、ユーザにとって有用性が高い情報である。この情報を提供することにより、ユーザは、しばらく走行を続けることで、所望のガイド情報が得られるという見通しを立てることができる。例えば、カップル向けのレストランを探している時、現在位置の近くではレストランが見つからなかったとしても、あと３０分ほど移動したところにあることが予告情報で提供されれば、おしゃれさを度外視して手近にある立ち食いそばで済ませてしまい、ロマンチックな食事を逃してしまうという失敗を回避することが可能となるのである。
【０１０５】
本実施例では、予告情報の選択は、モードに適合していること、経路から所定距離内にあることを満たすガイド情報の中で、現在位置に最も近いものを選択することとした（ステップＳ３２７）。予告情報の選択については、後で具体例を示しながら説明する。
【０１０６】
上述の選択にあたっては、所要時間の他、営業時間を考慮してもよい。例えば、レストランなどの施設について営業時間の情報を取得し、その店舗への到着予想時刻が、営業日、営業時間から外れる場合には、当該施設を選択対象から除外する方法を採ることができる。同様に、映画の上映時間を考慮して、情報の選択を行うようにしてもよい。
【０１０７】
Ｆ３．ガイド情報選択例：
図１１はガイド情報選択例を示す説明図である。ガイド情報選択処理におけるソート（図９のステップＳ３１７）の処理例を示した。図の左上には、各ジャンルについて優先順位、評価値、配信実績を示した。評価値は、「カップル」で昼食時「１１〜１４」という条件で、推奨データ（図３）に基づいて設定した値である。ガイド情報選択処理では、配信実績、評価値、優先順位をキーとしてこれらのジャンルがソートされる。右上にソート結果を示した。図中に示したジャンル内で、更に細分化されたジャンルの評価を行うようにしてもよい。例えば、最上位にソートされた「食事」を細分化した「洋食」、「和食」などのサブジャンルを設け、これらのジャンルについて必要度を評価してソートしてもよい。このように階層的に必要度の評価、ソートを行うことにより、「クイズ」などのように評価が低かったジャンルについてはサブジャンルについての無用な評価を回避しつつ、必要度が高いジャンルについては、より柔軟、適切な情報選択を実現することが可能となる。
【０１０８】
右上の図には、併せて立寄実績を示した。ユーザの走行履歴に基づいて判断した結果である。ここでは、レストランなど「食事」「ファミレス」には立ち寄っておらず、喫茶店には立ち寄っているものとする。サーバ２００は、立寄場所と同一ジャンルを除外するため（図９のステップＳＳ３１８）、喫茶が配信対象から除外されることになる。
【０１０９】
図の下側には、ガイド内情報選択処理例を示した。「食事」のジャンル内に、レストランＡ〜レストランＤのガイド情報が収集されているとする。ジャンル内情報選択処理では、モード適合性、情報の新しさ、情報のＰＲ度でソートを行う（図１０のステップＳ３２２）。まず、モード適合性について図１１の例に則して考える。レストランＡは「カップル」向けであるため、ユーザが指定したモード「カップル」に適合する。レストランＢ，Ｃは非適合である。レストランＤは、モードの指定がなされていないため、ユーザが指定したモード「カップル」に適合するものとして扱う。
【０１１０】
レストランＡは更新日が「２００６．７．２」であり、レストランＤは「２００６．６．４」であるから、情報の新しさでは、レストランＡの方が上位となる。次に、情報のＰＲ度では、レストランＤが評価値５であり、レストランＡの評価値４よりも高い。ただし、本実施例では、情報の新しさの方が、ＰＲ度よりも優先のソートキーであるから、総合的にレストランＡの方がレストランＤよりも上位のガイド情報となる。しかし、レストランＡ、Ｂは所要時間が許容範囲を超えている。従って、サーバ２００は許容範囲内にあるレストランＤを配信対象として選択する。この例で、仮にレストランＤのガイド情報が存在しないとすれば、サーバ２００はレストランＡの情報を予告情報として選択することになる。
【０１１１】
上述の例は、複数存在するガイド情報の中から、ユーザに提供すべき物を選択する例を示した。本実施例は、この他、リアルタイムに検索された情報の提供可否を判断する態様で利用することもできる。例えば、ユーザの移動目的等を考慮して図１１に示すようにジャンルのソートが行われているとする。この時点で、ガイド情報選別システムが、Ｗｅｂサーバ等から新たな情報を得たとする。ガイド情報選別システムは、この新たな情報が、図１１中のいずれのジャンルに属するかを判断する。そして、必要度が上位から３位以上など、任意に設定された所定基準以上のジャンルに属する情報であれば、それをユーザに提供する。例えば、上位から３位以上のジャンルに属するレストラン情報が得られている場合には、その情報はユーザに提供されることになるが、クイズ情報の場合には提供されないことになる。このように各ジャンルの必要度を評価した結果に基づいて、新たに得られた情報の提供要否を判断することによって、本実施例は、ユーザに提供すべき情報を柔軟、適切に選別することが可能となる。
【０１１２】
図１２は予告情報の選択例を示す説明図である。ユーザが現在位置ＳＴから目的地ＧＬに向かう状況を例示した。ガイド情報選択処理において、端末１００に配信すべきガイド情報は存在しなかったとする。この場合、サーバ２００はジャンル内情報選択処理において予告情報の選択を行う（図１０のステップＳ３２７）。ここでは、「カップル」向けのレストランを提供するものとし、サーバ２００が提供可能なガイド情報として、レストラン１〜４の４カ所が得られているものとする。予告情報は、モードに適合していること、経路から所定距離内であることを満たすガイド情報の中から、現在位置に最も近いものが選択される（図１０のステップＳ３２７）。まず、モードについて検討する。図示する通り、レストラン１は「ファミリー」向けであり、レストラン２〜４は「カップル」向けである。従って、レストラン１は予告情報の選択対象から外れる。
【０１１３】
次に、経路からの距離を検討する。レストラン２〜４の経路からの距離はそれぞれＤ２、Ｄ３、Ｄ４である。経路からの距離とは、経路から外れて走行すべき距離であり、現在位置から各レストランまでの距離ではない。この距離は、経路上の一点からレストランまでの経路探索によって求めても良いが、本実施例では、レストランから経路に至る最短の直線距離を用いている。経路からの距離の許容範囲は任意に設定可能である。図１２の例では、レストラン２の距離Ｄ２は許容範囲を超えており、レストラン３，４の距離Ｄ３、Ｄ４は許容範囲内であるとする。従って、サーバ２００は、レストラン３，４のうち、現在位置ＳＴから最も近い位置にあるレストラン３を予告情報として選択する。
【０１１４】
ここでは、一つのレストランを選択する例を示したが、レストラン１〜４を候補として提示し、ユーザに選択を委ねても良い。最終決定をユーザが行うことにより、その時の気分や、空腹具合、具体的に提示されたお店の雰囲気などを踏まえた選択をすることができる。この態様を採る場合には、ユーザが選択しやすい範囲、例えば、２〜５個程度まで情報を絞り込んだ上で、提示することが好ましい。
【０１１５】
図１３は予告情報選択の変形例を示す説明図である。図１２では、経路からの距離に基づいて情報選択を行う例を示した。変形例では、距離の評価を簡略化した処理例を示す。変形例では、図示するように、出発地ＳＴ、および目的地ＧＬを含む範囲を所定サイズのエリアＡ１〜Ｄ５に分割する。そして、この中から、経路の通過エリアを選択する。図中にハッチングを付した領域（エリアＡ４、Ｂ４、Ｂ３、Ｃ３、Ｃ２、Ｃ１、Ｄ１）が通過エリアである。次に、レストラン１〜４がこれらの通過エリア内に属するか否かを判断する。図示する通り、レストラン１〜３は、通過エリア内に存在するが、レストラン４は通過エリアから外れることが分かる。変形例では、この結果に基づき、通過エリアから外れるレストラン４は、経路から遠すぎると判断し、選択対象から除外する。レストラン１〜３については、実施例と同様、レストランの種別等に基づいて情報の適用可否を判断する。こうすることにより、簡易な処理で、経路からの距離を反映した情報選択を実現することができる。
【０１１６】
以上で説明した第１実施例のガイド情報選別システムによれば、推奨データ（図３）を用いることにより、ユーザのその時々のモード、移動状況に応じて、ガイド情報のジャンルの必要度を判断することができ、これを反映してユーザに提供されるガイド情報を選択することができる。従って、ユーザにとって有用な情報を提供することが可能となる。
【０１１７】
第１実施例においては、提示されたガイド情報に基づいてレストラン等を利用した結果をマイボックス等に記録可能としてもよい。例えば、施設の利用後にユーザに評価用の画面を提供し、５段階等でユーザが登録した評価結果を、利用した施設と対応づけて登録しておく方法を採ることができる。次にガイド情報を選択する際、高い評価が得られた施設の情報を優先的に提供し、低い評価が得られた情報は選択対象から除外することによって、ユーザに対して有用性の高い情報を提供することが可能となる。
【０１１８】
また、上述の評価結果は、複数のユーザ間で共有可能としてもよい。それぞれの施設に対する平均的な評価を求めることによって、評判の高い施設に関する情報を優先的に提供することが可能となる。また、趣向の類似したユーザ間で情報を共有することにより、ユーザの感覚に適合した情報の提供が可能となる。
【０１１９】
実施例で示した立寄実績は、肯定的な評価に利用することも可能である。特定の施設への立寄実績を記録しておくことにより、ユーザが日常的に利用している施設を知ることが可能となり、これをガイド情報の選択に活用することが可能となる。一例として、ユーザが利用したガソリンスタンドへの立寄実績を記録している場合において、車両の残燃料および平均燃費から給油が必要と判断された場合を考える。立寄結果から、ユーザが特定のガソリンスタンドを利用している場合には、このお得意ガソリンスタンドまでの走行可否を判断し、走行可能であれば、ユーザには給油が必要であることを促しつつ、他のガソリンスタンドの情報は選択対象から除外すればよい。お得意ガソリンスタンドまで走行不能の場合には、お得意ガソリンスタンドと同系列のガソリンスタンドの情報を優先的に提供するなどの態様を採ることができる。同系列を優先するか否かをユーザが設定可能としてもよい。
【０１２０】
Ｇ．第２実施例：
ガイド情報選別システムにおいて、推奨データ（図３）は、種々の設定が可能である。評価パラメータの種類を増やしても良い。また、第１実施例（図３）では、必要度をランクで表す例を示したが、それぞれを数値で表すようにしてもよい。必要度は、評価パラメータの連続関数で与えるようにしてもよい。かかる例を第２実施例として以下で示す。
【０１２１】
図１４は第２実施例における推奨データを示す説明図である。第２実施例では、ガイド情報は、図の左側に示すように、階層化されて管理されている。汎用情報という大分類の中に「天気」、「ニュース」、「クイズ」等のジャンルが設けられ、飲食系の大分類の中に「スイーツ」、「食事」などのジャンルが設けられている。「食事」は、「ファミレス」、「ぐるめ」などのサブジャンルに分かれている。この階層構造は、第２実施例に固有ではなく、第１実施例についても同様に適用可能である。
【０１２２】
図の右側に、「天気」に対応する優先度および必要度を示した。第２実施例では、これらのデータが、ジャンルごとに設定されている。「優先度」は後述する通り、第２実施例ではサーバ２００が設定するものとした。「モード」は、第１実施例（図３）では記号で表していたものを数値で表した点が異なるのみであり、内容は第１実施例と同様である。第２実施例では、時間帯、運転時間、目的地までの距離を評価パラメータとして適用し、図示する通りの関数で評価値を与えるものとした。図中の各グラフは、それぞれの評価パラメータに対して「天気」に対する評価値を与えるものである。「時間帯」は横軸に時間を取って表してあり、午前中の時間帯で評価値が高く設定されている。「運転時間」は出発後の経過時間を横軸にとって表してあり、運転開始後１時間以内で評価値が高く設定されている。「目的地までの距離」については、距離が伸びるほど評価値が高く設定されている。これは、目的地から離れているほど、目的地の「天気」情報の必要度が高いことを意味している。このように連続関数で評価値を与える構成をとることにより、例えば、現在時刻が１分異なるだけで「時間帯」による評価値が大きく変動するという弊害を回避することが可能となる。第２実施例では、移動状況に関する評価パラメータを全て連続関数で規定する例を示したが、第１実施例のようにランクで与える項目と、連続関数で与える項目とを混在させてもよい。
【０１２３】
Ｇ１．ガイド情報選択処理：
図１５は第２実施例におけるガイド情報選択処理のフローチャートである。スケジュール・ガイド処理（図８）のステップＳ３１０に相当する処理である。サーバ２００は、第１実施例（図９）と同様、ユーザが指示した情報がある場合には（ステップＳ４０１）、指定されたガイド情報を読み込み（ステップＳ４０２）、そのガイド情報の配信、配信実績の記録を行う（ステップＳ４６２）。
【０１２４】
ユーザが指示した情報が無い場合（ステップＳ４０１）、サーバ２００はモード、移動状況、配信実績、走行履歴を読み込み（ステップＳ４０３）、優先度設定処理を実行する（ステップＳ４１０）。第１実施例では各ジャンルの優先度が予め与えられていたのに対し、第２実施例ではこの処理によって各ジャンルの優先度を設定するのである。第２実施例では、優先度は数値で設定されるものとした。
【０１２５】
次に、サーバ２００は、推奨データ（図１４）を参照してジャンル毎に評価値を算出する（ステップＳ４３０）。まず、第１実施例と同様、ユーザが指定した「モード」に基づき、モード評価値を求める。次に、時間帯評価値、運転時間評価値、距離評価値を、それぞれ推奨データのグラフに基づき算出する。第２実施例では、優先度も含めて全体の評価値を次式で求めるものとした。この式は、任意に設定可能である。
評価値＝優先度×（モード評価値＋時間帯評価値＋運転時間評価値＋距離評価値）
このように優先度を含めて評価値を求めることにより、ジャンルを選択する基準として、評価パラメータと優先度を同等に扱うことができる。例えば、モード評価値、時間帯評価値、運転時間評価値、距離評価値が比較的低いジャンルであっても、優先度が高いものがあれば、提供対象として選択することが可能となる。
【０１２６】
サーバ２００は、次に配信実績および評価値に基づいてジャンルをソートする（ステップＳ４３２）。第１実施例と異なり、優先度は評価値に含まれているため、ソートキーとして用いる必要はない。ソートが完了すると、第１実施例と同様、サーバ２００は、走行履歴の立寄場所と同一ジャンル、および配信条件（図３参照）を満たさないジャンルを、配信対象から除外する（ステップＳ４３４）。
【０１２７】
そして、サーバ２００は最上位のジャンルを配信対象として選択し（ステップＳ４３６）、ジャンル内情報選択処理を実行する（ステップＳ４４０）。この処理によって、配信すべき情報が選択された場合には（ステップＳ４６０）、サーバ２００は、そのガイド情報を配信し、配信実績に記録して（ステップＳ４６２）、ガイド情報選択処理を終了する。情報が選択されなかった場合には（ステップＳ４６０）、サーバ２００は選択すべきガイド情報が得られるまで、ソートされた順序に従って、次のジャンルを指定し、ジャンル内情報選択処理を再試行する（ステップＳ４４０）。
【０１２８】
Ｇ２．優先度設定処理：
図１６は優先度設定処理のフローチャートである。ガイド情報選択処理（図１５）のステップＳ４１０に相当する処理であり、推奨データ（図１４）に含まれる各ジャンルの優先度を設定する処理である。
【０１２９】
この処理では、サーバ２００は推奨データに含まれる中から処理対象とすべきいずれかのジャンルを選択し（ステップＳ４１１）、デフォルトの優先度を読み込む（ステップＳ４１２）。本実施例では、デフォルトの優先度は予め推奨データに登録してある。
【０１３０】
次にサーバ２００は、処理対象となるジャンル内で、ユーザの現在位置に基づき、提供可能なガイド情報を抽出する（ステップＳ４１３）。現在位置から所要時間が所定範囲内のガイド情報を抽出すればよい。そして、これらのガイド情報のうち、最新のものに基づいて新鮮度を設定する（ステップＳ４１４）。図中に新鮮度の設定例を示した。図示する通り、ガイド情報の更新後の経過時間に応じて０．０〜１．０の範囲の実数値で新鮮度を与えるグラフを用意しておく。このグラフは任意に設定可能である。サーバ２００は、最新のガイド情報の経過時間に基づいて、このグラフを参照することにより新鮮度を決定することができる。ここでは、グラフを用意する例を示したが、関数、テーブルなど経過時間と新鮮度の関係は、種々の形式で与えることが可能である。
【０１３１】
サーバ２００は、次に、ステップＳ４１３で抽出された各ガイド情報のＰＲ度を算出する（ステップＳ４１５）。本実施例では、ＰＲ度は、「期間限定係数×売り文句係数」で求めるものとした。期間限定係数とは、ガイド情報の有効期限に応じて定まる係数である。図中に期間限定係数の設定例を示した。この例では、有効期限が短いほど、係数が高くなるよう設定されている。例えば、期間限定のセールや、桜の開花情報など、残り期間が短いほど貴重な情報であり、ユーザへのアピール度が高いと考えられることを反映した設定である。売り文句係数は、売り文句に相当する単語数と、全単語数との比である。売り文句係数は、第１実施例で説明したＰＲ度に相当する値である。ここで示したのは、期間限定係数や売り文句係数の一例に過ぎず、これらの係数は任意に設定可能である。また、この他の要素を用いても良い。売り文句係数は、必ずしもリアルタイムに求める必要はなく、事前に情報収集した時点で求めても良いし、Ｗｅｂページの作成者がＷｅｂページの一情報として含めておくようにしてもよい。
【０１３２】
サーバ２００は、以上の結果を基に、次式によって優先度を算出する。優先度は、デフォルト値に、新鮮度とＰＲ度を考慮した修正を施した値となっている。
優先度＝新鮮度×ＰＲ度の最大値×デフォルト優先度；
ＰＲ度はジャンル内で抽出された各ガイド情報について求められるため、ここではその最大値を用いるものとした。平均値その他の代表値を用いても良い。サーバ２００は以上の値を全ジャンルについて終了するまで繰り返す（ステップＳ４１７）。こうして設定された優先度を用いることにより、新鮮な情報、ＰＲ度が高い情報が入っているジャンルは優先度が高くなり、そうでないジャンルは優先度が低くなる。
【０１３３】
Ｇ３．ジャンル内情報選択処理：
図１７は第２実施例におけるジャンル内情報選択処理のフローチャートである。ガイド情報選択処理（図１５）のステップＳ４４０に相当する処理である。第２実施例では、ガイド情報がジャンル、サブジャンルという階層構造（図１４）に応じた処理内容となっている。このため、サーバは、まず、ガイド情報を、サブジャンル単位で優先順位に基づきソートする（ステップＳ４４１）。本実施例では、サブジャンル単位の優先順位は、予め推奨データ（図１４）に登録されているものとした。この優先順位を優先順位設定処理（図１６）等によって設定するものとしてもよい。
【０１３４】
次に、サーバ２００は、サブジャンルに該当するガイド情報を汎用情報ＤＢ２０２およびマイボックス２０３から読み込み（ステップＳ４４２）、第１実施例（図１０）と同様、ガイド情報をソートする（ステップＳ４４３）。
【０１３５】
サーバ２００は、ガイド情報のソートが終了すると、第１実施例と同様、サーバ２００は、最上位のガイド情報を抽出し（ステップＳ４４４）、現在位置から、そのガイド情報に対応する地点（以下、「設置場所」と呼ぶ）までの所要時間を算出する（ステップＳ４４５）。
【０１３６】
こうして得られた所要時間が、予め設定された許容範囲内である場合には（ステップＳ４４６）、サーバ２００は、そのガイド情報を配信対象として選択する（ステップＳ４５０）。許容範囲を超えている場合（ステップＳ４４６）、当該ジャンル内の全ガイド情報について判断が終了するまでの間は（ステップＳ４４７）、ソートされた順に従って次のガイド情報について同様の処理を実行する。
【０１３７】
全てのガイド情報について所要時間が許容範囲を超えている場合には（ステップＳ３２５、Ｓ３２６）、サーバ２００は、次のサブジャンルに移行し（ステップＳ４４８）、上述の処理（ステップＳ４４２〜Ｓ４４７）を繰り返す。全サブジャンルが終了した時は、サーバ２００は、予告情報を選択して（ステップＳ３２７）、ジャンル内情報選択処理を終了する。
【０１３８】
第２実施例のジャンル内情報選択処理では、サブジャンルを優先順位に従ってソートした上でサブジャンルごとにガイド情報を選択する。従って、一定の傾向に従って、ガイド情報を提供することが可能となる。例えば、第２実施例では、図１４に示したように「食事」のジャンル内に「ファミレス」「ぐるめ」等のサブジャンルがある。本実施例によれば、例えば、「ぐるめ」に属するレストランを優先的に選択し、その中で配信すべきガイド情報が見いだされない時に「ファミレス」に属するレストランを探すよう、指定することができる。この結果、ユーザが「ぐるめ」に属するレストランがファミレスよりも若干遠方にある場合でも、ファミレスより優先してガイド情報を与えることが可能となる。このようにサブジャンル単位でガイド情報を選択することによって、ユーザの意図に沿った情報選択がより実現可能となる。
【０１３９】
第２実施例によれば、第１実施例と同様、ユーザのその時々の状況を考慮して、有用性の高いガイド情報を適切に配信することができる。
【０１４０】
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。本実施例は、広告の配信等に限らず、観光案内や行政情報など種々の情報を配信対象とすることができる。また、実施例では、ユーザの事情を広告の配信に反映させる技術を例示したが、ガイド情報を提供者が、受信するユーザの条件を既定し、サーバ２００は、この条件に基づいて受信対象者を絞り込むようにしてもよい。こうすることで、ガイド情報は、その提供者の意図に沿ったユーザ、かつ当該情報を欲していると推測されるユーザに提供可能となり、ガイド情報の有用性を更に向上させることが可能となる。
【図面の簡単な説明】
【０１４１】
【図１】実施例としてのガイド情報選別システムの構成を示す説明図である。
【図２】個人プロファイル２０１、マイボックス２０３のデータ構造を示す説明図である。
【図３】推奨データの例を示す説明図である。
【図４】ガイド情報選別システムにおける制御処理のフローチャートである。
【図５】スケジュール登録・変更処理のフローチャートである。
【図６】情報収集処理のフローチャートである。
【図７】情報ボックス・メンテナンス処理のフローチャートである。
【図８】スケジュール・ガイド処理のフローチャートである。
【図９】ガイド情報選択処理のフローチャートである。
【図１０】ジャンル内情報選択処理のフローチャートである。
【図１１】ガイド情報選択例を示す説明図である。
【図１２】予告情報の選択例を示す説明図である。
【図１３】予告情報選択の変形例を示す説明図である。
【図１４】第２実施例における推奨データを示す説明図である。
【図１５】第２実施例におけるガイド情報選択処理のフローチャートである。
【図１６】優先度設定処理のフローチャートである。
【図１７】第２実施例におけるジャンル内情報選択処理のフローチャートである。
【符号の説明】
【０１４２】
１００…端末
１１０…主制御部
１２０…通信部
１３０…コマンド入力部
１４０…ＧＰＳ
１５０…表示制御部
２００…情報提供サーバ
２０１…地図ＤＢ
２０２…ユーザＤＢ
２０３…マイボックス
２０４…地図ＤＢ
２１０…通信部
２２０…出力データ生成部
２３０…情報提供制御部
２４０…プロファイル管理部
２５０…情報収集部
２６０…経路案内部
３００…パソコン
４００…Ｗｅｂサーバ
【特許請求の範囲】
【請求項１】
移動中のユーザに対して有用なガイド情報を選別するガイド情報選別システムであって、
前記ガイド情報またはそのジャンルに応じて、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された評価パラメータと、該ガイド情報を該ユーザが必要とする必要度との対応関係を記憶した推奨データ保持部と、
前記ユーザについて、前記評価パラメータに対応する情報を入力する入力部と、
前記入力された情報に基づき、前記対応関係を参照して、前記ガイド情報またはジャンルごとの必要度を判断し、該判断結果に基づいて、前記ユーザに対して有用なガイド情報を選別するガイド情報選別部とを備えるガイド情報選別システム。
【請求項２】
請求項１記載のガイド情報選別システムであって、
前記ガイド情報選別部は、前記必要度の高いガイド情報またはジャンルを優先的に選別するガイド情報選別システム。
【請求項３】
請求項１記載のガイド情報選別システムであって、
所定の情報源を参照して、前記選別の対象となるべきガイド情報またはジャンルを特定する情報収集部を有し、
前記ガイド情報選別部は、前記特定されたガイド情報またはジャンルの必要度が所定の基準を超える時に、該ガイド情報またはジャンルを選別するガイド情報選別システム。
【請求項４】
請求項１〜３いずれか記載のガイド情報選別システムであって、
前記ガイド情報またはジャンルごとに、前記ユーザに対するガイド情報の配信実績を記憶する実績データベースを備え、
前記ガイド情報選別部は、更に、前記配信実績を参照して前記選別を行うガイド情報選別システム。
【請求項５】
請求項１〜４いずれか記載のガイド情報選別システムであって、
地物の位置、および該地物の属性とを含む地図データベースと、
前記ユーザの現在位置を検出する検出部と、
前記検出された現在位置に基づいて前記地図データベースを参照して前記ユーザが立ち寄った地物を特定し、格納する経過保持部と、
前記ガイド情報選別部は、更に前記立ち寄った地物の属性を参照して前記選別を行うガイド情報選別システム。
【請求項６】
請求項１〜５いずれか記載のガイド情報選別システムであって、
前記対応関係の少なくとも一部は、評価パラメータに対する連続関数で前記必要度を与えるガイド情報選別システム。
【請求項７】
請求項１〜６いずれか記載のガイド情報選別システムであって、
前記推奨データ保持部は、更に、前記選別に関し、前記ガイド情報またはジャンル間の優劣を定める優先度を保持し、
前記ガイド情報選別部は、更に、前記優先度を考慮して前記選別を行うガイド情報選別システム。
【請求項８】
請求項７記載のガイド情報選別システムであって、
前記選別されるべきガイド情報を特定し、該特定されたガイド情報の内容に基づいて、該ガイド情報またはそのジャンルの優先度を設定する優先度設定部を備えるガイド情報選別システム。
【請求項９】
請求項７または８記載のガイド情報選別システムであって、
ＰＲ度が高いとして予め設定された文言が、前記ガイド情報に含まれる量または割合に応じて、該ガイド情報またはそのジャンルの優先度を設定するガイド情報選別システム。
【請求項１０】
請求項１〜９いずれか記載のガイド情報選別システムであって、
前記ユーザに案内すべき経路を保持する経路保持部を有し、
前記ガイド情報選別部が、前記ユーザの現在位置から所定の範囲内で、所定以上の必要度を有するガイド情報を選別できない場合、前記経路上で該ガイド情報を提供可能な地点を探索し、その結果を前記ユーザに提供する予告情報提供部を有するガイド情報選別システム。
【請求項１１】
請求項１〜１０いずれか記載のガイド情報選別システムであって、
前記ガイド情報の情報源として、前記ガイド情報を、所定のジャンルおよびサブジャンルによって階層管理するガイド情報データベースを有するガイド情報選別システム。
【請求項１２】
請求項１１記載のガイド情報選別システムであって、
前記推奨データ保持部は、更に、前記選別に関し、前記サブジャンル間の優劣を定める優先度を保持するガイド情報選別システム。
【請求項１３】
移動中のユーザに対して有用なガイド情報を選別するガイド情報提供方法であって、
コンピュータが実行する工程として、
前記ガイド情報またはそのジャンルに応じて、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された評価パラメータと、該ガイド情報を該ユーザが必要とする必要度との対応関係を記憶する工程と、
前記ユーザについて、前記評価パラメータの少なくとも一部に対応する情報を入力する工程と、
前記入力された情報に基づき、前記対応関係を参照して、前記ガイド情報またはジャンルごとの必要度を判断し、該判断結果に基づいて、前記ユーザに対して有用なガイド情報を選別する工程とを備えるガイド情報提供方法。
【請求項１４】
移動中のユーザに対して有用なガイド情報を選別するコンピュータプログラムであって、
前記ガイド情報またはそのジャンルに応じて、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された評価パラメータと、該ガイド情報を該ユーザが必要とする必要度との対応関係を記憶するサブプログラムと、
前記ユーザについて、前記評価パラメータに対応する情報を入力するサブプログラムと、
前記入力された情報に基づき、前記対応関係を参照して、前記ガイド情報またはジャンルごとの必要度を判断し、該判断結果に基づいて、前記ユーザに対して有用なガイド情報を選別するサブプログラムとを備えるコンピュータプログラム。
【請求項１】
移動中のユーザに対して有用なガイド情報を選別するガイド情報選別システムであって、
前記ガイド情報またはそのジャンルに応じて、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された評価パラメータと、該ガイド情報を該ユーザが必要とする必要度との対応関係を記憶した推奨データ保持部と、
前記ユーザについて、前記評価パラメータに対応する情報を入力する入力部と、
前記入力された情報に基づき、前記対応関係を参照して、前記ガイド情報またはジャンルごとの必要度を判断し、該判断結果に基づいて、前記ユーザに対して有用なガイド情報を選別するガイド情報選別部とを備えるガイド情報選別システム。
【請求項２】
請求項１記載のガイド情報選別システムであって、
前記ガイド情報選別部は、前記必要度の高いガイド情報またはジャンルを優先的に選別するガイド情報選別システム。
【請求項３】
請求項１記載のガイド情報選別システムであって、
所定の情報源を参照して、前記選別の対象となるべきガイド情報またはジャンルを特定する情報収集部を有し、
前記ガイド情報選別部は、前記特定されたガイド情報またはジャンルの必要度が所定の基準を超える時に、該ガイド情報またはジャンルを選別するガイド情報選別システム。
【請求項４】
請求項１〜３いずれか記載のガイド情報選別システムであって、
前記ガイド情報またはジャンルごとに、前記ユーザに対するガイド情報の配信実績を記憶する実績データベースを備え、
前記ガイド情報選別部は、更に、前記配信実績を参照して前記選別を行うガイド情報選別システム。
【請求項５】
請求項１〜４いずれか記載のガイド情報選別システムであって、
地物の位置、および該地物の属性とを含む地図データベースと、
前記ユーザの現在位置を検出する検出部と、
前記検出された現在位置に基づいて前記地図データベースを参照して前記ユーザが立ち寄った地物を特定し、格納する経過保持部と、
前記ガイド情報選別部は、更に前記立ち寄った地物の属性を参照して前記選別を行うガイド情報選別システム。
【請求項６】
請求項１〜５いずれか記載のガイド情報選別システムであって、
前記対応関係の少なくとも一部は、評価パラメータに対する連続関数で前記必要度を与えるガイド情報選別システム。
【請求項７】
請求項１〜６いずれか記載のガイド情報選別システムであって、
前記推奨データ保持部は、更に、前記選別に関し、前記ガイド情報またはジャンル間の優劣を定める優先度を保持し、
前記ガイド情報選別部は、更に、前記優先度を考慮して前記選別を行うガイド情報選別システム。
【請求項８】
請求項７記載のガイド情報選別システムであって、
前記選別されるべきガイド情報を特定し、該特定されたガイド情報の内容に基づいて、該ガイド情報またはそのジャンルの優先度を設定する優先度設定部を備えるガイド情報選別システム。
【請求項９】
請求項７または８記載のガイド情報選別システムであって、
ＰＲ度が高いとして予め設定された文言が、前記ガイド情報に含まれる量または割合に応じて、該ガイド情報またはそのジャンルの優先度を設定するガイド情報選別システム。
【請求項１０】
請求項１〜９いずれか記載のガイド情報選別システムであって、
前記ユーザに案内すべき経路を保持する経路保持部を有し、
前記ガイド情報選別部が、前記ユーザの現在位置から所定の範囲内で、所定以上の必要度を有するガイド情報を選別できない場合、前記経路上で該ガイド情報を提供可能な地点を探索し、その結果を前記ユーザに提供する予告情報提供部を有するガイド情報選別システム。
【請求項１１】
請求項１〜１０いずれか記載のガイド情報選別システムであって、
前記ガイド情報の情報源として、前記ガイド情報を、所定のジャンルおよびサブジャンルによって階層管理するガイド情報データベースを有するガイド情報選別システム。
【請求項１２】
請求項１１記載のガイド情報選別システムであって、
前記推奨データ保持部は、更に、前記選別に関し、前記サブジャンル間の優劣を定める優先度を保持するガイド情報選別システム。
【請求項１３】
移動中のユーザに対して有用なガイド情報を選別するガイド情報提供方法であって、
コンピュータが実行する工程として、
前記ガイド情報またはそのジャンルに応じて、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された評価パラメータと、該ガイド情報を該ユーザが必要とする必要度との対応関係を記憶する工程と、
前記ユーザについて、前記評価パラメータの少なくとも一部に対応する情報を入力する工程と、
前記入力された情報に基づき、前記対応関係を参照して、前記ガイド情報またはジャンルごとの必要度を判断し、該判断結果に基づいて、前記ユーザに対して有用なガイド情報を選別する工程とを備えるガイド情報提供方法。
【請求項１４】
移動中のユーザに対して有用なガイド情報を選別するコンピュータプログラムであって、
前記ガイド情報またはそのジャンルに応じて、ユーザの移動目的および移動状況の少なくとも一部に関して予め設定された評価パラメータと、該ガイド情報を該ユーザが必要とする必要度との対応関係を記憶するサブプログラムと、
前記ユーザについて、前記評価パラメータに対応する情報を入力するサブプログラムと、
前記入力された情報に基づき、前記対応関係を参照して、前記ガイド情報またはジャンルごとの必要度を判断し、該判断結果に基づいて、前記ユーザに対して有用なガイド情報を選別するサブプログラムとを備えるコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２００８−７１０９５（Ｐ２００８−７１０９５Ａ）
【公開日】平成２０年３月２７日（２００８．３．２７）
【国際特許分類】
【出願番号】特願２００６−２４８７６６（Ｐ２００６−２４８７６６）
【出願日】平成１８年９月１３日（２００６．９．１３）
【出願人】（５００５７８２１６）株式会社ゼンリンデータコム (231)
【公開日】平成２０年３月２７日（２００８．３．２７）
【国際特許分類】
【出願日】平成１８年９月１３日（２００６．９．１３）
【出願人】（５００５７８２１６）株式会社ゼンリンデータコム (231)
[ Back to top ]