JP5044160B2 - ガイド情報提供システム - Google Patents

Description

本発明は、特定の地点に対応するガイド情報を、ユーザに提供するガイド情報提供システムに関する。

店舗が予め登録した広告データをユーザに配信する広告配信システムが広く活用されている。広告配信システムによる配信対象を、カーナビゲーションとすることにより、車両で移動中のユーザへの広告配信を行う技術も提案されている。通常のパーソナルコンピュータなどに配信する場合と異なり、カーナビゲーションへの配信では、ユーザが閲覧可能な情報量には制限があること、カーナビゲーションを利用中のユーザは何らかの目的を持って移動中であることが多いため、目的に応じて、ユーザが欲する情報内容もある程度絞られることなどの特徴がある。

かかる特徴に基づき、従来、カーナビゲーションへの広告配信を対象として、ユーザが欲する情報をタイムリーに提供する技術が種々提案されてきた。例えば、特許文献１は、広告の配信対象エリア、配信期間、配信する時間帯による配信条件を設定することにより、広告によるＰＲ効果が有効に得られると考えられるユーザに集約して広告を効率的に配信する技術を開示している。特許文献２は、ユーザの年齢、性別、職業などの個人情報と、広告主が設定した配信条件、即ち広告を配信すべき時間帯や配信対象者の年齢などの条件とを比較することにより、効率的な広告配信を行う技術を開示している。

特開２００３−９９６７０号公報 特開２００２−７７４６４号公報

しかし、従来の絞り込みでは、まだ十分とは言えなかった。カーナビゲーションを含む経路案内装置では、ユーザは移動する間に種々の情報を閲覧することになるため、先に述べた通り、ユーザが閲覧可能な情報量は制限される。従って、ユーザが無用と感じる情報が多数配信されている場合には、ユーザは、それらの情報全体を無視するようになり、広告等の情報の有用性が一気に失われてしまうおそれがある。また、広告の配信などは、配信に応じた従量制で広告主に課金されることが多いため、ユーザが必要としていない情報を配信することは、広告主に無用な費用負担をかけることにもなる。つまり、カーナビゲーションを含む経路案内装置への広告その他の情報の配信では、情報を利用する可能性がある人により集約して配信することが重要な課題となる。

かかる観点から見ると、従来技術では、まだ絞り込みが十分とは言えなかった。一例として、ある店舗についての広告を配信する場合を考える。この時、従来技術では配信対象となる範囲を特定する技術が提案されている（特許文献１参照）。しかし、この範囲内にいるユーザであっても、店舗に近づく方向に移動している者と、店舗から遠ざかる方向に移動している者とでは、広告の有用性が自ずと異なってくる。また、ユーザは何らかの目的を持って移動していることが多いから、この移動目的に沿った広告を配信するか否かによって、広告の有用性は異なってくる。従来技術では、これらの条件を反映した絞り込みは行うことができなかった。

上述の課題は、広告に限らず、観光案内、その他、特定の地点との関係で提供される種々のガイド情報に共通であった。本発明は、これらの課題に鑑み、経路案内装置を利用中のユーザに対して、ガイド情報をより効率的に提供可能とすることを目的とする。

本発明は、経路案内装置に対して特定の地点に対応するガイド情報を提供するガイド情報提供システムとして構成することができる。ガイド情報には、特定の地点との関係で予め登録された種々の情報、例えば、広告、観光案内、行政その他の地域情報などが含まれる。ガイド情報は、予めガイド情報データベースとして登録されている。経路案内装置は、ユーザの現在位置を地図上で提示する装置であり、例えば携帯電話、カーナビゲーション装置、ノートパソコン、ＰＤＡなどを利用して提供することができる。ユーザが今後、進むべき経路を地図上で提示する経路案内を行うようにしてもよい。ガイド情報提供システムは、これらの装置を利用してスタンドアロンで稼働するように構成してもよいし、これらの装置を利用した端末とサーバ等をネットワークで接続して構成してもよい。本発明のガイド情報提供システムは、以下に示す種々の構成により、ガイド情報の効率的な提供を実現する。

第１の構成では、ガイド情報データベースには、ガイド情報と、ユーザが特定の地点（以下、「登録地点」と呼ぶ）に接近しているか否かという接近状況に基づいて定められた提供条件とを対応づけて登録しておく。ガイド情報提供システムは、ユーザの接近状況を検出し、検出された接近状況に基づいてガイド情報データベースを参照することで、ユーザに提供すべきガイド情報を選択して提供する。接近状況は、例えば、複数の時点で現在位置を検出し、その移動状況から求める方法を採ることができる。また、ユーザが経路案内に従って移動している場合には、案内すべき経路と現在位置に基づいて求めることもできる。第１の構成において多数のガイド情報が選択された場合には、更に付加的な条件によって絞り込みを行っても良い。

第１の構成によれば、ユーザの接近状況を絞り込み条件として利用することにより、登録地点にユーザが近づいているのか否かによってガイド情報の提供可否を判断することができる。こうすることにより、例えば、登録地点に近づいているユーザに対しては、登録地点自体の魅力を伝えるガイド情報を提供することができる。登録地点から遠ざかっているユーザに対しては、この次の機会に有用な情報、例えば、登録地点で今後行われる予定のイベント情報などを提供することができる。また、登録地点に対してほぼ一定の距離を移動中のユーザに対しては、登録地点のみならず、その周辺の地点も含めた地域全体の魅力を伝えるガイド情報を提供することにより、ユーザの興味を登録地点に向けさせることもできる。このように、ユーザの接近状況を考慮して提供すべきガイド情報を選択することにより、ガイド情報の有用性、即ちガイド情報をユーザが活用する可能性を向上させることができる。ガイド情報の有用性が向上することにより、ユーザにとってのガイド情報提供システムの利便性が向上し、利用頻度が向上するため、更にガイド情報の有用性を向上させる相乗効果をもたらすことができる。また、ガイド情報の配信量に応じて従量制で課金される場合であっても、その経済的負担を軽減することができる。

第１の構成において、提供条件には、ガイド情報を提供すべきユーザの存在地域を規定するエリア条件を含めても良い。ガイド情報提供システムは、ユーザの進行方向だけでなく、ユーザの現在位置を検出可能とし、検出された現在位置がエリア条件を満たす場合にガイド情報の選択を行う。エリア条件は、例えば、登録地点を中心とする所定半径の円形地域その他の任意の形状の地域、登録地点を含む行政界などの形で設定することができる。登録地点のガイド情報は、その地点から離れた場所にいるユーザには有用性が低いことが多いため、このようにエリア条件を考慮することにより、提供されるガイド情報の有用性を向上することができる。

上記態様では、登録地点を含まない地域をエリア条件として指定してもよい。こうすることにより、登録地点から離れたユーザに集約してガイド情報を提供することが可能となり、例えば、登録地点を含む一定の地域の魅力を概括的に伝えるガイド情報など、遠方にいるユーザの興味を登録地点に向けさせるための情報の有用性を向上させることができる。

第２の構成では、ユーザが移動可能な道路を記録した地図データベースを用いる。地図データベースは、道路をノード、リンクで表したものや、ポリゴンで表したものなど、各地点がいずれかの道路上の地点か否かを判断可能なデータベースであればよい。ガイド情報データベースには、ガイド情報の提供範囲を道路単位で特定する提供条件とガイド情報とを対応づけて登録する。道路の「単位」は提供条件を一義的に特定できるように任意に設定可能である。例えば、道路に「国道○号線」などのように名称が付されている場合には、その名称で道路を特定するようにしてもよい。また、地図データベースに道路のポリゴンが格納されている場合には、当該ポリゴン単位で道路を特定してもよい。道路がノード、リンクで表されている時は、リンク単位で道路を特定してもよい。ガイド情報提供システムは、ユーザの現在位置を道路単位で検出する。そして、検出されたリンクに基づいてガイド情報データベースに登録された提供条件を参照して、ユーザに提供すべきガイド情報を選択して提供する。

第２の構成では、ガイド情報の提供範囲を道路単位で特定するため、登録地点により密接な位置関係にあるユーザに対して効率的にガイド情報を提供することが可能となる。ガイド情報の提供範囲として単に登録地点を中心とする円形領域などを指定する場合に比べて、登録地点に来る者や、登録地点から帰る者が頻繁に通行する道路を特定して提供範囲とすることができるからである。また、登録地点によっては、道路を指定することによってユーザの移動目的を実質的に絞り込むことも可能となる。例えば、温泉付近の幹線道路に対応する道路を提供範囲として指定することにより、ガイド情報が温泉からの帰路にあるユーザや温泉に向かうユーザに提供される可能性を高めることができる。このように、道路単位で提供範囲を特定することには、ガイド情報が提供対象として想定に沿ったユーザへの情報提供がなされる可能性を実質的に向上させることができる利点がある。

第２の構成において提供条件には、道路上の進行方向を含めてもよい。ガイド情報提供システムは、ユーザの進行方向を検出し、検出された進行方向も含めてガイド情報を選択する。こうすることにより、例えば、ある道路の上り／下りのいずれかに進行しているユーザに対してのみ、ガイド情報を提供することが可能となる。この結果、例えば、特定の道路を通って登録地点に向かってくるユーザ、または登録地点から遠ざかっているユーザのみを対象としてガイド情報を提供することが可能となる。ガイド情報の提供条件をより絞り込むことができるため、ガイド情報の有用性を更に向上させることが可能となる。

第２の構成において、道路をノードおよびリンクで表した地図データベースを用いている場合、道路の少なくとも一部を上り下りの２条からなるリンクで表しても良い。この場合には、ガイド情報の提供範囲をリンク単位で指定すると、ユーザの現在位置および進行方向を同時に提供条件に含めることができる。ガイド情報提供システムは、ユーザが２条のリンクのうち、いずれのリンク上にいるかを特定する必要がある。地図データベースのリンクを用いて、ユーザが指定した出発地から目的地に向かうために通行すべき経路を案内している場合には、ガイド情報提供システムは、この案内すべき経路とユーザの現在位置から、リンク単位で現在位置を検出することが可能である。この態様によれば、進行方向を簡易に提供条件に含めることができ、またユーザの進行方向も精度良く検出することが可能となるため、より効率的にガイド情報の提供を行うことができる。

第２の構成では、提供条件には、ユーザの出発地、目的地の少なくとも一方に基づいて、ガイド情報を提供すべきか否かを特定する条件を含めても良い。ガイド情報提供システムは、ユーザの出発地、目的地の少なくとも一方を入力し、入力された出発地等が提供条件に該当するか否かによって、提供すべきガイド情報を選択する。指定された道路またはリンク上にいるユーザであっても、その移動目的は多種多様であるが、出発地、目的地を提供条件とすることによって、特定の出発地を出発したユーザ、または特定の目的地からの帰路にあるユーザを対象としてガイド情報を提供することができる。従って、指定された道路またはリンク上のユーザのうち、ガイド情報が想定した移動目的を有するユーザに対してガイド情報が提供される可能性を向上させることができ、ガイド情報の有用性を更に向上させることが可能となる。

第３の構成では、ガイド情報提供システムは、ユーザの過去の移動状況を保持可能とする。例えば、出発以降の移動状況を限定的に保持するようにしてもよいし、出発以前の移動状況も含めて保持するようにしてもよい。いずれの場合においても、保持の対象を、過去の一定期間のみに限定することも可能である。移動状況としては、例えば、出発時を含む過去のある時点からの移動時間や移動経路、途中で立ち寄った場所などを含めることができる。移動時間は、単純に経過時間を保持しておくようにしてもよいし、信号待ちなどで一定時間以上動かなかった場合を除く正味の移動時間を保持するようにしてもよい。立ち寄った場所については、道路上からそれて、いずれかの地点で一定時間以上継続して停止している場合に、その停止場所に立ち寄ったと判断する方法を採ることができる。ガイド情報データベースには、ガイド情報と、移動状況に基づいて定められた提供条件とを対応づけて登録しておく。

ガイド情報提供システムは、保持された移動状況に基づいてガイド情報データベースに登録された提供条件を参照して、ユーザに提供すべきガイド情報を選択し提供する。こうすることで、ユーザの移動履歴を考慮してガイド情報を提供することができる。従って、ガイド情報の意図に沿ったユーザに絞り込んで情報を提供することが可能となり、ガイド情報の有用性を向上させることができる。

第３の構成では、地物の位置、および地物の属性とを含む地図データベースを用いても良い。ユーザの現在位置が検出されると、ガイド情報提供システムは、検出された現在位置に基づいて地図データベースを参照して、ユーザが立ち寄った地物を特定することができる。また、属性に地物の種別が含まれている場合には、属性に基づいて地物の種別を特定してもよい。これらの特定された地物等は移動状況としてガイド情報提供システム内に保持しておくことができる。また、ガイド情報提供システムには、登録地点への訪問目的に基づいて定められた条件を提供条件として登録しておく。こうすることで、例えば、食事、ショッピングなど登録地点への訪問目的によって、ガイド情報の提供対象となるユーザを絞り込むことができる。ガイド情報提供システムは、更に、ユーザが立ち寄った地物の種別に基づいて、その場所の訪問目的を特定する。例えば、立ち寄った地物の種別と訪問目的とを予め対応づけておくことによって特定するようにしてもよいし、地物の属性として訪問目的を地図データベースに登録しておくようにしてもよい。そして、ガイド情報提供システムは、提供すべきガイド情報の選択に際して、立ち寄った地物から特定された訪問目的と同一の訪問目的に対応するガイド情報の優先度を低くする。

立ち寄った地物から特定される訪問目的は、その地物で既に済ませてしまっている可能性がある目的と言える。従って、同じ訪問目的に該当するガイド情報を提供されても、ユーザにとっての有用性は低いおそれがある。上記態様によれば、ユーザが済ませてしまった可能性が高い訪問目的に対応するガイド情報の提供を抑制し、未済の訪問目的に対応するガイド情報を優先的に提供することが可能となる。従って、ガイド情報の有用性を向上することができる。上述の態様において、同一の訪問目的に対応するガイド情報の優先度を低くする方法としては、例えば、そのようなガイド情報を選択対象から除外する方法を採ってもよい。また、提供条件に該当するガイド情報を、立ち寄った場所の訪問目的と一致するか否かでソートすることにより、優先度を低くするようにしてもよい。

本発明のガイド情報提供システムでは、ガイド情報に対して種々の提供条件が設定されている。この提供条件を、ガイド情報の提供主の意図に沿うように設定することも、本発明による効果を得るために重要である。本発明は、かかる観点から、ガイド情報提供システム用に、ガイド情報を提供するための提供条件の設定を支援する支援装置として構成することもできる。この支援装置は、ガイド情報提供システムの一機能として組み込んでも良いし、別体の装置として構成してもよい。

上述した種々の提供条件の中では、第２の構成において、提供範囲を規定する道路またはリンクの設定が、最も支援を要する。例えば、登録地点に最も近い道路を提供範囲として指定したとしても、その道路が細街路に当たっている場合など、通行量の少ない道路に当たる場合には、ガイド情報はほとんど有効活用されなくなってしまうからである。以下では、道路単位での提供条件の設定を支援する場合の構成をまず説明する。この設定支援には、経路探索を利用する。従って、以下ではリンク単位で提供条件が指定される場合を対象とする。

本発明の支援装置は、以下の手順で提供範囲となるべきリンクの候補を提示する。まず、支援装置は、ガイド情報に関連づけられるべき目的地を、経路探索の一端として設定する。例えば、ガイド情報がスキー場や温泉などに向かうユーザや、これらの場所からの帰路にあるユーザ向けの情報を提供している場合には、スキー場や温泉を目的地として設定することができる。ガイド情報に関連づけられるべき目的地については、ガイド情報の提供者が任意に指定可能としてもよいし、ガイド情報に含まれる用語などから自動的に判断するようにしてもよい。後者の場合には、例えば、所定のキーワードと目的地とを対応づけるテーブル等を用意しておき、ガイド情報に含まれる用語に基づいてこのテーブルを参照することで特定する方法を採ることができる。

目的地の設定がなされると、支援装置は、地図データベースを参照して、目的地を一端とし、目的地と異なるいずれかの地点を他端とする経路探索を行う。経路探索の他端は任意に設定可能である。支援装置は、こうして得られた経路探索の結果に基づいて、提供範囲となるべきリンクの候補を提示する。つまり、目的地を一端とする経路に基づいて候補のリンクが設定されることになる。こうすることにより、ガイド情報に関連した目的地に向かうユーザ、目的地からの帰路にあるユーザが通行する可能性が高いリンクを、提供範囲として設定することが可能となる。

上記経路探索においては、例えば、ノードのうち予め基点候補として設定されたもののいずれかを、目的地との位置関係に基づいて選択し、これを経路探索の他端となるべき基点として設定する方法を採ることもできる。この場合は、経路探索は、目的地と基点との間で行うことになる。基点には、例えば、高速道路のインターチェンジや、バイパスなどの幹線道路への入り口にあたる交差点など、目的地への往路または帰路において、多くのユーザが通行すると考えられる地点や、ドライブイン、著名なファーストフード店など、多くのユーザが休憩に利用すると考えられる地点などを用いることができる。個別の地点を予め基点候補として設定しておいてもよいし、インターチェンジなどの種別または属性によって包括的に基点候補を設定しておいてもよい。支援装置は、目的地との位置関係、例えば、目的地との距離や、目的地と主要な都市とを結ぶ直線からの距離などに基づいて経路探索に使用すべき基点を設定することができる。

上記態様によれば、目的地と基点との間で行われた経路探索の結果に基づいてリンクの候補を提供することができる。多くのユーザが利用すると考えられる場所を基点として用いることにより、目的地への往路、帰路において多くのユーザが利用するであろう経路に基づいてリンクの候補を提供することが可能となる。従って、上記態様によれば、より効率的なガイド情報の提供を実現可能となる候補リンクを提示することができる。

経路探索の他端として特定の地点、即ち登録地点を設定し、目的地と登録地点との間で経路探索を行うようにしてもよい。こうすることにより、目的地から登録地点に至る経路上のリンクを候補として挙げることができる。従って、目的地からの帰路において登録地点に向かうのに都合のよいユーザを対象としてガイド情報を効率的に提供可能となる候補リンクを提示することができる。

上述のいずれの態様においても、目的地は複数設定し、各目的地を一端とする複数の経路探索を行うようにしてもよい。例えば、スキー場への行き帰りのユーザを対象とするガイド情報の提供を考える場合には、登録地点の周囲に存在する複数のスキー場を目的地として抽出し、各スキー場を一端とする複数の経路を得ることができる。こうして得られた全経路上のリンクを候補リンクとして提示する方法を採ることもできるが、２以上の経路が重なるリンクを優先的に候補として提示することが好ましい。こうすることにより、複数の目的地に共通した経路上のリンクを候補として提示することができ、効率的にガイド情報を提供可能な候補リンクを提示することができる。

同様に、目的地の他端となるべき基点を複数設定してもよい。他端には登録地点も含めてもよい。これらの場合には、複数の基点および登録地点と、複数の目的地との複数通りの組み合わせで経路探索を行えばよい。この場合も、複数の探索結果で重複している経路上のリンクを候補として提示することが好ましい。

支援装置は、候補リンクを提供する他、提供条件の設定を支援する種々の機能を提供することができる。例えば、ガイド情報の配信に対して従量制で課金される場合には、ガイド情報の提供主が設定した提供条件に対してコストの見積もり結果を提示するようにしてもよい。この場合、提供主が設定した提供条件の一部その他、コストに影響を与える条件の一部を変動させ、複数通りの見積もり結果を自動的に提示することが好ましい。こうすることにより、ガイド情報の提供主は予算に合致する提供条件を比較的容易に見つけることが可能となる。

本発明は、上述した種々の特徴を必ずしも全て備えている必要はなく、一部を省略したり適宜組み合わせたりして構成することができる。本発明は、上述したガイド情報提供システム、支援装置として構成する他、コンピュータによってガイド情報を提供するガイド情報提供方法や支援方法として構成することもできる。また、ガイド情報の提供や提供条件の設定を支援するためのコンピュータプログラムとして構成したり、このコンピュータプログラムの少なくとも一部を記録した記録媒体として構成したりすることもできる。この場合、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。

本発明の実施例について以下の順序で説明する。
Ａ．システム構成：
Ｂ．データ構造：
Ｃ．広告登録処理：
Ｃ１．配信ターゲット設定処理：
Ｃ２．エリア・ルート選択処理：
Ｃ２−１．ルート選択処理：
Ｃ２−２．ルート選択例：
Ｃ３．日付指定処理：
Ｃ４．時間帯指定処理：
Ｃ５．広告内容指定処理：
Ｃ６．コスト見積もり処理：
Ｄ．経路案内の概要：
Ｅ．経路探索、経路案内処理：
Ｅ１．経路探索処理：
Ｅ２．経路案内処理：
Ｅ３．広告選択処理：
Ｆ．変形例：

Ａ．システム構成：
図１は実施例としてのガイド情報提供システムの構成を示す説明図である。ガイド情報提供システムは、特定の地点（以下、「登録地点」と呼ぶ）との関係で予め登録されたガイド情報をユーザに提供するシステムである。本明細書では、ガイド情報として登録地点についての広告を提供する場合を例にとってシステムの構成、機能等について説明する。

実施例のガイド情報提供システムは、情報提供サーバ２００（以下、単に「サーバ」と呼ぶこともある）と、端末１００とをインターネットＩＮＴで接続して構成される。図中の例では、端末１００はカーナビゲーション装置である。端末には、この他、携帯電話、ノートＰＣ、ＰＤＡなど携帯可能な種々の装置が利用可能である。

端末１００には、情報提供サーバ２００から提供される広告を取得するためにインターネットＩＮＴとの通信機能が要求されるが、予めガイド情報を取得しておくことにより、オフラインで広告を提供することも可能である。サーバ２００との通信が確保できない場合のみ、オフラインで広告を提供するようにしてもよい。図の例では、インターネットＩＮＴを適用した例を示したが、インターネットＩＮＴに代えて、イントラネットなどの限定的なネットワークを用いることも可能である。

ガイド情報提供システムは、上述の通り、サーバ２００と端末１００とを中心として構成されるが、この他にもパソコン３００および多数のＷｅｂサーバ４００［１］、４００［２］を含めることができる。パソコン３００は、サーバ２００に広告およびその配信条件の登録を行うための装置である。本実施例では、これらの機能は、サーバ２００から提供されるＷｅｂページによって実現するものとした。従って、上述の機能を実現するためには、パソコン３００はブラウザを搭載していれば足りる。上述の機能は、端末１００でも実現可能である。この意味で、パソコン３００は端末１００の一種と呼ぶこともできるが、スケジュールの登録等の機能は、デスクトップ型のパソコンなど携帯不能な装置でも実現可能であるため、本実施例では端末１００と区別して示した。

Ｗｅｂサーバ４００［１］、４００［２］（以下、両者をＷｅｂサーバ４００と総称することもある。）は、インターネット上のＷｅｂサイトを通じて種々の情報を提供するサーバである。図中では、Ｗｅｂサーバ４００［１］は気象情報を提供し、Ｗｅｂサーバ４００［２］は渋滞情報を提供する例を示した。提供される情報には、これらに限らず、ショッピング情報、行政情報など多種多様な情報が含まれる。Ｗｅｂサーバ４００は、ガイド情報提供システムに特化したサーバである必要はない。ただし、ガイド情報提供システムと提携したサーバとしておけば、より利便性の高いシステムを構築することができる。例えば、Ｗｅｂサーバ４００が情報を規定のフォーマットに従って提供することにより、本システムの情報収集効率を向上させることができる。また、情報の中に固有のパラメータを含み得るようにしておくことで、Ｗｅｂサーバ４００側からガイド情報提供システムにおける情報の利用態様を制御することも可能となる。

図中には、ガイド情報提供システムとしての機能を提供するための情報提供サーバ２００の機能ブロックを併せて示した。本実施例では、これらの機能ブロックは、これらの機能を実現するためのＣＧＩ（Common Gateway Interface ）などで構成されたコンピュータプログラムを情報提供サーバ２００にインストールすることによってソフトウェア的に実現される。図中の機能ブロックの少なくとも一部は、ＡＳＩＣなどの回路によって、ハードウェア的に構成することも可能である。

サーバ２００は、図示する４通りのデータベースを備えている。地図ＤＢ２０１は、経路探索や案内に使用されるデータベースであり、道路をノード・リンクの集合で表した道路ネットワークデータと、地図を表示するための描画データとを格納する。描画データには、地形や地物の形状を表すポリゴンデータ、および地物の位置や属性のデータなどが格納されている。道路ネットワークデータには、車両で移動する際に活用できる車両用のネットワークデータ、歩行時に活用できる歩行者用のネットワークデータ、交通機関を利用する際に活用できる交通機関用のネットワークデータなどを含めることができる。地図ＤＢ２０１のデータ例については後述する。

ユーザＤＢ２０２は、ユーザＩＤ、氏名、生年月日などのユーザ個人の識別情報の他、ユーザが経路探索時に指定した探索条件や、経路探索の結果などを保持している。また、経路案内時には、出発以降の移動履歴も保持する。ユーザＤＢ２０２には、更に、広告の配信時に利用可能な情報として、ユーザの趣味、嗜好などの情報、および画面や音声出力などに関するカスタマイズの情報を格納してもよい。

広告ＤＢ２０３は、ガイド情報提供システムがユーザに提供する広告およびその配信条件を対応づけて格納する。広告の他、天気予報、渋滞情報、ニュースなどＷｅｂサーバ４００から収集した情報を格納可能としてもよい。広告主ＤＢ２０４は、広告主のＩＤ、氏名などの個人情報、広告主の業種、広告の配信条件のデフォルト設定値、および広告主ごとの課金データなどを格納する。広告ＤＢ２０３に登録された広告は、広告主のＩＤによって、広告主ＤＢ２０４の登録内容と関連づけられている。

各機能ブロックは、それぞれ次の機能を奏する。通信部２１０は、インターネットＩＮＴを介した情報授受を制御する。広告登録部２４０は、広告主ＤＢ２０４を参照しながら、広告を広告ＤＢ２０３に登録するためのインタフェースを提供する。本実施例では、このインタフェース画面は、ＨＴＭＬやＸＭＬを用いたＷｅｂページの形で生成され、出力データ生成部２２０を介して端末３００に提供される。広告主が、端末３００で広告の内容および配信条件を指定すると、広告登録部２４０は、これらのデータを広告ＤＢ２０３に登録する。

広告配信部２４２は、ユーザＤＢ２０２を参照しながら、広告ＤＢ２０３に登録された広告から、ユーザの端末１００に配信すべき広告を選択する。選択された広告は、出力データ生成部２２０を介して端末１００に提供される。

課金処理部２５０は、広告を登録する際に、配信条件に応じて、広告の配信コストを試算して提示する。また、広告配信部２４２から、広告の配信状況を受信し、配信された広告に応じて従量制でコストを算出し、結果を広告主ＤＢ２０４に登録する。

経路探索部２３２は、地図ＤＢ２０１を参照して、ユーザが端末１００で指定した出発地、目的地の間で経路探索を行う。地図ＤＢ２０１の道路ネットワークデータを参照し、ダイクストラ法など周知の方法を適用して実現することができる。経路探索の結果は、ユーザＤＢ２０２に保持される。

経路探索部２３２は、この他、広告主が広告の配信条件を設定する際の支援情報を提供するための経路探索も実行する。本実施例では、後述する通り、広告の配信条件をリンク単位で設定可能となっており、広告登録部２４０は、推奨されるリンクを広告主に提示する。経路探索部２３２は、この推奨されるリンクを特定するために用いる情報として、経路探索結果を広告登録部２４０に提供することになる。経路案内部２３０は、ユーザの現在位置に応じて、ユーザＤＢ２０２に登録された経路探索結果、地図ＤＢ２０１を参照しながら地図表示を行うとともに、地図上に移動経路の表示を行う。

出力データ生成部２２０は、広告配信部２４２および経路案内部２３０から提供されるデータに基づいて、端末１００に表示するための表示データを生成する。本実施例では、多種多様な端末１００を利用できるよう、ＨＴＭＬ、ＸＭＬを利用して表示データを生成するものとした。出力データ生成部２２０は、先に説明した通り、広告登録用のインタフェース画面、動作を選択するためのメニュー画面など、ガイド情報提供システムに要求される種々の画面の表示データを生成する。

図中に端末１００に備えられる機能ブロックを併せて例示した。端末１００では、主制御部１１０の管理下で、図示する各機能ブロックが稼働する。本実施例では、これらの機能ブロックは、端末１００としての機能を実現するためのプログラムによって、ソフトウェア的に構成したが、ハードウェア的に構成してもよい。

通信部１２０は、インターネットＩＮＴを介した情報の授受を制御する。コマンド入力部１３０は、ユーザの操作に応じてメニューの選択、案内の開始、表示すべき情報の選択など種々のコマンドを入力する。表示制御部１５０は、情報提供サーバ２００からのデータに従って画面表示を行う機能を奏する。本実施例では、ブラウザによって提供される。ＧＰＳ（Global Positioning System）１４０は、ユーザの現在位置を検出する。現在位置は、サーバ２００に送信され、ガイド情報や経路案内の表示制御に活用される。

ここで示したのは、ガイド情報提供システムの一例に過ぎない。図１中に示した各機能ブロックは、必ずしも情報提供サーバ２００または端末１００に全て備えられている必要はなく、分散処理によって複数のサーバ等の連携で実現するようにしてもよい。また、全ての機能ブロックを端末１００に備えることにより、スタンドアロンで稼働するガイド情報提供システムを構築することも可能である。

Ｂ．データ構造：
図２は地図ＤＢ２０１のデータ構造を例示する説明図である。図２（ａ）は、描画データの内容を例示している。描画データには、道路や地物等を表すポリゴンデータが格納されており、それぞれのポリゴンデータには、ＩＤ、形状、およびその属性等が格納されている。例えば、建物ＢＬＤは、図示する通り、ハッチングを付した矩形のポリゴンで表される。このポリゴンには、ＩＤとして「ＰＯＬ１」が付されている。形状は、ポリゴンの頂点Ｐ１、Ｐ２、Ｐ３、Ｐ４の位置座標（緯度、経度）を列挙することで表される。ポリゴンＰＯＬ１には、その他、建物の種別や高さなどの属性も付されている。属性には、種別、高さの他にも種々の情報を登録可能である。例えば、宿泊、食事、休憩、ショッピング、スポーツなど、その建物で済ませることができる用事を登録可能としてもよい。

道路ＲＤには、「ＰＯＬ２」のＩＤとともに、図中のクロスハッチングを付した矩形領域を表す形状データ、および種別、車線などの属性データが格納される。形状は、建物と同様、頂点の位置座標を列挙することで表される。本実施例では、道路ポリゴンは、後述するリンクに対応して形成されており、交差点で挟まれる間を一つの単位として形成されている。

図２（ｂ）は、道路ネットワークデータを例示している。図２（ａ）に示した道路を、ノード・リンクで表したものである。ノードＮ１、Ｎ２等は、交差点に相当する点である。各ノードには、ＩＤとともに、位置座標が格納されている。この他、ノードを通行する際の通行規制などの属性を格納してもよい。

リンクは、道路を表すように、ノード間を結ぶ線分である。本実施例では、幅が広い道路は、リンクＬ１、Ｌ２のように上り／下りの２条で表し、狭い道路はリンクＬ３のように上下を１条で表している。各リンクには、リンクＩＤ、形状、通行方向が登録されている。リンクの形状は、リンクの通過点の位置座標を列挙して表される。通行方向は、リンクＬ１、Ｌ２のように２条の道路については、「単方向」と登録され、リンクＬ３のように１条の道路については「双方向」と登録される。単方向の場合には、形状を表す点列の始点から終点に向かう方向の通行のみが許容される。リンクについては、上述したデータの他、国道、県道などの道路種別、道路幅、通行規制などの属性を登録してもよい。

本実施例では、２条の道路と１条の道路とを混在させているが、全ての道路を２条または１条で統一してもよい。例えば、２条で統一する場合には、リンクＬ３のように幅が狭い道路については、同じ位置に２本のリンクを設定しても構わない。

Ｃ．広告登録処理：
図３は広告登録処理のフローチャートである。サーバ２００の広告登録部２４０が実行する処理であり、広告主による端末３００の操作に応じて、広告主の店舗などの地点（以下、「登録地点」と呼ぶ）に対する広告および配信条件を登録するための処理である。

処理を開始すると、サーバ２００は広告主からのＩＤ、パスワードの入力によるログインを受け付け（ステップＳ１０）、登録インタフェース画面を提示する（ステップＳ１２）。図中に登録インタフェース画面ＤＩＳＰの例を示した。この例では、「１．配信ターゲット設定」、「２．エリア・ルートの選択」、「３．日付の指定」、「４．時間帯の指定」、「５．広告内容の指定」、「６．コスト見積もり」の６通りのメニューを設けた。サーバ２００は、広告主からの選択結果に応じて（ステップＳ１４）、それぞれのメニューに対応した処理を実行する。それぞれの処理の詳細な内容については後述する。

「１．スケジュール登録・変更」が選択された場合には、サーバ２００は、配信ターゲット設定処理を行う（ステップＳ１００）。これは、配信条件の一つとして、広告の提供すべきユーザを絞り込む条件を設定する処理である。例えば、広告主が、スキー場帰りの家族連れ向けの広告を登録する際には、広告の有用性を高めるため、「スキー場帰り」、「家族連れ」などを配信条件として設定し、配信対象となるべきユーザ（以下、「配信ターゲット」と呼ぶこともある）を絞り込むのである。

「２．エリア・ルートの選択」が選択された場合には、サーバ２００は、エリア・ルート選択処理を行う（ステップＳ２００）。これは、配信条件の一つとして、広告の配信対象となるべき範囲を指定する処理である。本実施例では、一定の領域（エリア）で指定する方法と、ルート（リンク）単位で指定する方法とを設けた。

「３．日付の指定」が選択された場合には、サーバ２００は、日付指定処理を行う（ステップＳ３００）。これは、配信条件の一つとして、広告を配信すべき日付を特定するための処理である。

「４．時間帯の指定」が選択された場合には、サーバ２００は、時間帯指定処理を行う（ステップＳ４００）。これは、配信条件の一つとして、広告を配信すべき時間帯を特定するための処理である。

「５．広告内容の指定」が選択された場合には、サーバ２００は、広告内容指定処理を行う（ステップＳ５００）。これは、提供すべき広告を登録するための処理である。

「６．コスト見積もり」が選択された場合には、サーバ２００は、コスト見積り処理を行う（ステップＳ６００）。これは、指定された条件下で広告主に課されるコストを試算し、結果を提示する処理である。広告主は、この結果に基づいて、コストが自己の許容可能な予算範囲内に収まるよう、配信条件を調整することができる。

登録インタフェース画面ＤＩＳＰで「登録」ボタン（メニュー７に相当）が押されると、サーバ２００は、広告データおよび配信条件を広告ＤＢ２０３に登録して（ステップＳ７００）、広告登録処理を終了する。また、登録インタフェース画面ＤＩＳＰで、「キャンセル」ボタン（メニュー８に相当）が押されると、サーバ２００は、これらの登録をスキップして、そのまま広告登録処理を終了する。

Ｃ１．配信ターゲット設定処理：
図４は配信ターゲット設定処理のフローチャートである。広告登録処理（図３）のステップＳ１００に相当する処理である。この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。

この処理を開始すると、サーバ２００は、広告主ＤＢ２０４から配信ターゲットについての既設定のデータを読み込み（ステップＳ１０２）、インタフェース画面を提供して、広告主からの入力を受け付ける（ステップＳ１０４）。新規に設定する場合には、広告主が通常、使う設定データとして登録されているデフォルトの設定を読み込むことにより、インタフェース画面にはデフォルト設定を表示させることができる。また、配信ターゲットを一旦設定した後、再度、配信ターゲット設定処理を実行している場合には、前回までに設定されたデータを読み込むことにより、設定済みのデータの修正用のインタフェース画面を提供することが可能となる。

図中にインタフェース画面例を示した。本実施例では、配信ターゲットを、対象者、目的地、立寄目的で絞り込むものとした。「対象者」とは、どのようなグループで移動しているユーザを配信ターゲットとするのかを特定するための項目である。１人で行動している者、ビジネスで移動中の者、ファミリー、カップル、子供連れなどを指定可能とした。

「目的地」とは、スキー場、温泉、ショッピングセンターなど、ユーザの目的地によって配信ターゲットを絞り込むための項目である。目的地への「行き」、「帰り」、「指定なし」の指定を可能とすることにより、更に詳細に絞り込むことができる。例えば、広告主がスキー場帰りのユーザを食事に誘い込むための広告を配信しようと考えている場合には、図示するように「スキー場」、「帰り」という条件を指定することにより、効率的な配信を実現することが可能となる。

「立寄目的」は、広告主の店舗に来る目的によって配信ターゲットを絞り込むための条件である。例えば、「食事」に関する広告を配信しようと考えている場合には、図示するように「立寄目的」として「食事」を指定することにより、効率的な配信を実現することが可能となる。「立寄目的」としては、この他、休憩、おみやげ、情報収集など種々の目的を選択可能である。

配信ターゲットを絞り込むための条件は、上述した項目に限らず、任意の種々の項目を設定可能である。また、上述の例では、各項目につき一つの条件を設定する場合を例示したが、複数の条件を設定可能としてもよい。

広告主がインタフェース画面で、条件を入力した後、「確定」を押すと（ステップＳ１０６）、サーバ２００は入力された配信ターゲット設定を保存して（ステップＳ１０８）、この処理を終了する。この時点では、まだ後で修正される可能性がある仮の設定であるため、本実施例では、この時点では、広告主ＤＢ２０４に保存するものとした。設定内容は、広告登録処理（図３）のステップＳ７００で広告ＤＢ２０３に登録されることになる。もっとも、図４のステップＳ１０８の時点で広告ＤＢ２０３に登録する構成を採っても差し支えない。広告主がインタフェース画面で、「キャンセル」を押すと（ステップＳ１０６）、サーバ２００はインタフェース画面に入力された条件を保存することなく、この処理を終了する。

Ｃ２．エリア・ルート選択処理：
図５はエリア・ルート選択処理のフローチャートである。広告登録処理のステップＳ２００に相当する処理である。この処理は、配信条件の一つとして、広告を配信する対象となる範囲をエリアまたはルートで指定するための処理である。サーバ２００の経路探索部２３２および広告登録部２４０が主として実行する処理に相当する。

処理を開始すると、サーバ２００は既設定データを読み込む（ステップＳ２０２）。エリアまたはルートを一旦設定した後、再度、この処理を実行している場合には、前回までに設定されたデータを読み込むことにより、設定済みのデータの修正用のインタフェース画面を提供することが可能となる。

サーバ２００は、次にメニュー画面を提供し、エリア選択、ルート選択のいずれかのモードの選択指示を入力する（ステップＳ２０４）。エリア選択とは、一定の領域内を広告配信の対象領域として指定するためのモードであり、ルート選択とは、道路ネットワークに登録されたリンク単位で広告の配信対象となる場所を指定するためのモードである。

メニュー画面で「キャンセル」ボタンが押された場合には（ステップＳ２０６）、サーバ２００は何ら処理を行うことなく、エリア・ルート選択処理を終了する。「エリア選択」が指定された場合には（ステップＳ２０６）、サーバ２００はエリア選択用のインタフェース画面を提供し、広告主からの入力を受け付ける（ステップＳ２０８）。図中にインタフェース画面を例示した。図は、星印を中心とし、矢印で示す半径を有する円形領域内をエリアとして指定する例を示している。星印は、広告主の店舗位置をデフォルト値として用いることができるが、広告主が、マウス等のポインティングデバイスによって地図上の任意の場所を指定可能としてもよい。エリアは、円形領域である必要はなく、矩形その他の多角形、楕円形など種々の形状を選択可能としたり、ポインティングデバイスで頂点を順次指定することで任意の形状を設定可能としてもよい。更に、エリアは、行政界を単位として選択可能としてもよい。

メニュー画面中には、「接近のみ」、「指定なし」というラジオボタンを設けた。「接近のみ」とは、上述のエリア内で登録地点（図中の星印）に接近しているユーザのみを配信ターゲットとする旨の指定である。「指定なし」とは進行方向を問わずエリア内のユーザを配信ターゲットとする旨の指定である。この他に、登録地点から遠ざかっているユーザのみを配信ターゲットとする旨の指定を可能としてもよい。

メニュー画面において、広告主が「ルート選択」を指定した場合には（ステップＳ２０６）、サーバ２００はルート選択処理を実行する（ステップＳ２１０）。この処理内容については後述する。以上の処理によって、広告を配信すべきエリアまたはルートの指定が完了し、広告主が「確定」ボタンを押すと（ステップＳ２３０）、サーバ２００はエリア・ルートの指定を保存して（ステップＳ２３２）、この処理を終了する。保存先は、広告主ＤＢ２０４である。広告主がインタフェース画面で、「キャンセル」を押すと（ステップＳ２３０）、サーバ２００はエリア・ルートの指定を保存することなく、この処理を終了する。

Ｃ２−１．ルート選択処理：
図６はルート選択処理のフローチャートである。エリア・ルート選択処理（図５）のステップＳ２１０に相当する処理であり、広告の配信対象となる場所を、道路ネットワークのルート単位で指定するための処理である。

この処理も、既に一旦、ルートが選択された後に、設定内容を修正するために実行される場合と、新規にルートを設定するために実行される場合の２通りがある。既設定データがない場合（ステップＳ２１２）、即ち新規にルートの設定を行う場合には、サーバ２００は、以下で示す手順により、候補となるべきルートを広告主に提示する。

まず、サーバ２００は、配信ターゲット設定、つまり配信ターゲット設定処理（図４）で設定され、広告主ＤＢ２０４に保存されているデータを読み込む（ステップＳ２１４）。また、広告主ＤＢ２０４を参照して、店舗の位置情報を入力する（ステップＳ２１６）。

そして、これらを参照して、目的地候補および基点候補を抽出する（ステップＳ２１８）。目的地候補は、配信ターゲット設定から得ることができる。図４で説明した通り、本実施例では、配信ターゲット設定として、「目的地」が設定されているため、このデータを用いればよい。ただし、配信ターゲット設定では、「スキー場」などのカテゴリーで指定されているに過ぎないため、サーバ２００は、このカテゴリーに基づいて具体的な目的地候補を設定する必要がある。目的地候補の設定には、例えば、店舗の位置を中心として所定の距離内で、配信ターゲットとして設定された目的地のカテゴリーに該当する地点を順次抽出する方法を採ることができる。目的地候補は、一つだけに絞っても良いし、複数抽出可能としてもよい。

基点候補は、ノードのうち予め基点候補として設定されたもののいずれかを、目的地との位置関係に基づいて選択すればよい。基点候補としては、例えば、高速道路のインターチェンジや、バイパスなどの幹線道路への入り口にあたる交差点など、目的地への往路または帰路において、多くのユーザが通行すると考えられる地点や、ドライブイン、著名なファーストフード店など、多くのユーザが休憩に利用すると考えられる地点などを用いることができる。ステップＳ２１８の処理では、これらの基点候補のうち、店舗から所定距離内にあるものを順次抽出する方法を採ることができる。目的地候補は、一つだけに絞っても良いし、複数抽出可能としてもよい。

サーバ２００は、こうして設定された目的地候補を出発地とし、基点候補および店舗の位置を終点とする複数の組み合わせについてパラメトリックに経路探索を実行する（ステップＳ２２０）。図中に処理例を示した。目的地候補として、目的地１、目的地２等が設定されている場合には、「出発地＝目的地１、終点＝店舗」という経路探索、「出発地＝目的地１、終点＝基点１」という経路探索という具合に、組み合わせを変えて、順次経路探索を実行するのである。

サーバ２００は、この経路探索の結果に基づいて、候補ルートを抽出する（ステップＳ２２２）。本実施例では、次の３つの基準に従って、候補ルートを設定するものとした。
基準１：各目的地について少なくとも一つのルートを抽出する；
基準２：複数の経路探索結果において多数重複しているルートを優先的に抽出する；
基準３：店舗を終点とするルートを優先して抽出する
これらの基準を適用した設定例は後で示す。候補ルートを抽出するための基準は、任意に設定可能であり、上述の３つの基準の一部を省略してもよいし、この他の条件を考慮してもよい。

サーバ２００は、以上で得られた候補ルートを示すインタフェース画面を広告主に提示し、広告主からの入力を受け付ける（ステップＳ２２４）。ルートの設定について、既設定のデータがある場合（ステップＳ２１２）、つまり既に設定されたルートを修正するためにルート選択処理が実行されている場合には、サーバ２００は、上述のステップＳ２１４〜Ｓ２２２の処理を省略して、インタフェース画面の提供を実行する（ステップＳ２２４）。

図中にインタフェース画面例を示した。この例では、矢印ＭＡで示すように、ノードＰＡからノードＰＢに向かう方向のリンクがルートとして選択されている。先に図２で示した通り、本実施例では、リンクは２条で定義されているため、このように進行方向も含めた指定が可能となっているのである。矢印ＭＡで示された区間は、店舗の正面の道路から一本隔てた道路である。しかし、店舗正面の道路幅が狭く、矢印ＭＡに対応する道路が幹線道路である場合には、広告の配信対象をこのように指定した方が、多数のユーザに配信可能となるため、広告の有用性を高めることができる。本実施例では、経路探索を利用するため、このように店舗から離れた場所であっても、多くの経路探索において利用されるリンクを候補として抽出することが可能となっている。図中では、店舗の左側にも候補ルートが選択されている。これは、ノードＰＡ，ＰＢ間のルートを通らずに目的地に至る経路に対応して抽出されたものである。

広告主は、この画面でルートの選択を手作業で指定することができる。例えば、図中の例で、矢印ＭＡをポインティングデバイスで選択し、削除を指示することによって、このルートを対象から除外することができる。また、別のルートを選択し、広告の配信対象として指定することもできる。広告主が「確定」または「キャンセル」ボタンを押すと、サーバ２００はルート選択処理を終了して、エリア・ルート選択処理（図５）に戻り、先に説明した通り、広告主ＤＢ２０４に設定を保存等する。

Ｃ２−２．ルート選択例：
図７はルート選択例を示す説明図である。図中の店舗の広告主が、スキー場帰りのユーザを配信ターゲットとする広告について、ルート設定を行う場合の例を示した。この場合、サーバ２００は、経路探索の目的地として、店舗周辺のスキー場を抽出する。図の例では、スキー場Ａ〜スキー場Ｃが抽出される。また、基点として、店舗周辺のインターチェンジＩＣが抽出される。

スキー場ＡとインターチェンジＩＣとの間の経路探索結果がルートＲＡ１であり、店舗との間の経路探索結果がルートＲＡ２である。スキー場ＢとインターチェンジＩＣとの間の経路探索結果がルートＲＢ１であり、店舗との間の経路探索結果がルートＲＢ２である。スキー場ＣとインターチェンジＩＣとの間の経路探索結果がルートＲＣ１であり、スキー場Ｃと店舗との間の経路探索結果がルートＲＣ１のうちの区間Ｄ３の部分である。

スキー場Ｃからの経路はルートＲＣ１のみであるから、先に説明した「基準１：各目的地について少なくとも一つのルートを抽出する」より、このルートＲＣ１が候補ルートとして抽出され、その中でも、「基準３：店舗を終点とするルートを優先して抽出する」を満たす区間Ｄ３が候補ルートとして抽出される。

また、「基準２：複数の経路探索結果において多数重複しているルートを優先的に抽出する」から、ルートＲＡ１、ＲＢ１が重複している箇所（図中の区間Ｄ１、Ｄ２等）が抽出され、その中でも「基準３：店舗を終点とするルートを優先して抽出する」を満たす区間Ｄ１が候補ルートとして抽出される。

以上より、図７の例では、区間Ｄ１、Ｄ３のルートが候補として抽出されることになる。先に図６で示した候補ルートはこのようにして決められたものである。上述の基準を用いれば、次に示す理由から、有用性の高い広告配信を実現することができる。まず、「基準１：各目的地について少なくとも一つのルートを抽出する」ことにより、全ての目的地からの配信ターゲットを漏れなく広告の配信対象に含めることができる。図７では、基準１が設けられているからこそ、区間Ｄ３がルートとして選択され、スキー場Ｃからのユーザが配信ターゲットに含められているのである。

「基準２：複数の経路探索結果において多数重複しているルートを優先的に抽出する」を用いることにより、多くの目的地からのユーザが重複して利用するルートを候補とすることができ、複数の目的地からの配信ターゲットに効率的に広告の配信を行うことが可能となる。図７の例では、ルートＲＡ１、ＲＢ１において、スキー場Ａ、スキー場Ｂから区間Ｄ１に至るまでのルートを配信対象としても、それぞれスキー場Ａまたはスキー場Ｂからのユーザに対してしか広告を配信できないが、区間Ｄ１を指定することにより、スキー場Ａ，Ｂからのユーザ双方にまとめて広告を配信可能となるのである。

また、「基準３：店舗を終点とするルートを優先して抽出する」を用いることにより、店舗に来る可能性の低いユーザを配信ターゲットから除くことができる。例えば、図７において、区間Ｄ２にいるユーザは店舗に向かうためには後戻りまたは遠回りをしなくてはならないため、広告を受け取ったとしても店舗に向かう可能性は比較的低い。これに対し、店舗を終点とするルートと重複している区間Ｄ１を配信対象とすれば、広告を受け取ったユーザは店舗に向かう可能性が高い。従って、基準３を用いることにより、店舗に来る可能性が低いユーザへの配信を抑制し、広告の有用性を高めることが可能となるのである。

Ｃ３．日付指定処理：
図８は日付指定処理のフローチャートである。広告登録処理のステップＳ３００に相当する処理である。この処理は、配信条件の一つとして、広告を配信する日時を指定するための処理である。サーバ２００の広告登録部２４０が主として実行する処理に相当する。

処理を開始すると、サーバ２００は既設定データおよび配信ターゲット設定を読み込む（ステップＳ３０２）。既設定データの読み込みは、設定済みのデータの修正用のインタフェース画面を提供するために行われる。

既設定データがない場合（ステップＳ３０４）、サーバ２００は推奨日付を設定する（ステップＳ３０６）。本実施例では、図中に示すように、それぞれ適したシーズンおよび曜日を、目的別にテーブルとして登録しておき、配信ターゲット設定の「目的地」に応じて、このテーブルを参照することで推奨日付を設定する方法を採った。例えば、配信ターゲット設定において、「スキー場」が目的地として設定されている場合には、「１２月〜３月」の「土・日・祝日」が推奨日付として設定されることになる。「温泉」が目的地として設定されている場合には、シーズンの指定なく、「金・土・日・祝日」が推奨日付として設定される。推奨日付の設定は、広告主の入力の便宜のために実行される処理であるから、省略しても差し支えない。

推奨日付を設定すると、サーバ２００はインタフェース画面を提供し、広告主による入力を受け付ける（ステップＳ３０８）。既設定データがある場合には（ステップＳ３０４）、推奨日付の設定（ステップＳ３０６）を省略し、既設定データに従ってインタフェース画面を提供することになる。推奨日付の設定は、広告主の入力の便宜を図るための処理であるため、省略しても差し支えない。

図中にインタフェース画面の例を示した。本実施例では、２種類の入力インタフェースを提供可能とした。左側は、カレンダーを利用した入力画面である。この画面では、広告主は配信対象とすべき日を個別に選択することができる。図中のチェックマークを付した日は、配信日として選択された日を示す。このインタフェース画面では、その他、曜日ごとに毎週繰り返して配信日とするためのチェック欄も設けた。画面下段にある「毎週」の欄をチェックすることにより、個別に指定するまでなく、毎週所定の曜日を配信対象として一括指定することが可能である。

右側は、条件によって配信日を指定するための画面である。この例では、まず、日付によって配信対象となる期間を指定する。この中で、毎週配信対象とすべき曜日を指定する。入力の便宜のため、指定された曜日を配信対象に「含む」「含まない」を選択可能とした。例えば、月曜日にチェックを入れた状態で「含む」を選択すれば、月曜日のみが配信対象となり、「含まない」を選択すれば、月曜日を除く火曜日〜日曜日が配信対象となる。

インタフェース画面において、広告主が「確定」ボタンを押すと（ステップＳ３１０）、サーバ２００は日付指定を保存して（ステップＳ３１２）、この処理を終了する。保存先は、広告主ＤＢ２０４である。広告主がインタフェース画面で、「キャンセル」を押すと（ステップＳ３１０）、サーバ２００は日付指定を保存することなく、この処理を終了する。

Ｃ４．時間帯指定処理：
図９は時間帯指定処理のフローチャートである。広告登録処理のステップＳ４００に相当する処理である。この処理は、配信条件の一つとして、広告を配信する日時を指定するための処理である。サーバ２００の広告登録部２４０が主として実行する処理に相当する。

処理を開始すると、サーバ２００は既設定データ、配信ターゲット設定、および日付指定を読み込む（ステップＳ４０２）。既設定データの読み込みは、設定済みのデータの修正用のインタフェース画面を提供するために行われる。

既設定データがない場合（ステップＳ４０４）、サーバ２００は広告を配信する推奨時間帯を設定する（ステップＳ４０６）。本実施例では、図中に示すように、それぞれ適した時間帯を、目的の往復別にテーブルとして登録しておき、配信ターゲット設定の「目的地」に応じて、このテーブルを参照することで推奨日付を設定する方法を採った。テーブルは、平日（月曜日〜金曜日）と週末（土曜、日曜）・祝日に分けて用意した。このテーブルを参照することで、例えば、スキー場に向かうユーザを配信ターゲットとする場合には、平日は８：００〜１０：００、休日は６：００〜１０：００が推奨時間帯として設定されることになる。スキー場から帰ってくるユーザを配信ターゲットとする場合には、平日は１４：００〜１７：００、休日は１４：００〜２０：００が推奨時間帯として設定されることになる。

推奨時間帯を設定すると、サーバ２００はインタフェース画面を提供し、広告主による入力を受け付ける（ステップＳ４０８）。既設定データがある場合には（ステップＳ４０４）、推奨時間帯の設定（ステップＳ４０６）を省略し、既設定データに従ってインタフェース画面を提供することになる。推奨時間帯の設定は、広告主の入力の便宜を図るための処理であるため、省略しても差し支えない。

図中にインタフェース画面の例を示した。広告主は、この画面での時間帯の設定を適用する日付を指定する。指定方法には、日付を個別に指定する方法、および曜日、祝日などのカテゴリーで指定する方法がある。図の例は、土曜日、日曜日および祝日用の設定を行うことを示している。

次に、広告主は広告を配信すべき時間帯を設定する。下に示す時間帯バーにおいて、配信すべき時間帯を個別に指定すればよい。図の例では、６時〜９時、および１５時〜１８時の合計６時間が指定されていることになる。本実施例では、入力の便宜を図るため、カテゴリー指定も可能とした。データイムを選択すると６〜１８時が設定され、アクティブタイムを選択すると９〜２１時が設定され、ナイトタイムを選択すると１８：００〜翌朝６：００が設定される。カテゴリーで時間帯を設定した後、時間帯バーにおける個別指定によって調整することも可能である。広告主が、「追加」のボタンを押すと、別の日付、曜日に対して時間帯を設定することが可能となる。

インタフェース画面において、広告主が「確定」ボタンを押すと（ステップＳ４１０）、サーバ２００は時間帯指定を保存して（ステップＳ４１１）、この処理を終了する。保存先は、広告主ＤＢ２０４である。広告主がインタフェース画面で、「キャンセル」を押すと（ステップＳ４１０）、サーバ２００は時間帯指定を保存することなく、この処理を終了する。

Ｃ５．広告内容指定処理：
図１０は広告内容指定処理のフローチャートである。広告登録処理のステップＳ５００に相当する処理である。この処理は、配信条件の一つとして、広告を配信する日時を指定するための処理である。サーバ２００の広告登録部２４０が主として実行する処理に相当する。

処理を開始すると、サーバ２００は既設定データを読み込む（ステップＳ５０２）。既設定データの読み込みは、設定済みのデータの修正用のインタフェース画面を提供するために行われる。

次に、サーバ２００はインタフェース画面を提供し、広告主による入力を受け付ける（ステップＳ５０４）。図中にインタフェース画面の例を示した。インタフェース画面では、広告主は、店名、広告文、設備・サービス、位置情報などの定型的な情報を入力することができる。画面右下には、この入力内容に応じてユーザの端末１００（図１参照）に表示される広告イメージを例示した。このような設定方法では、定型的な項目を用いるため、入力された情報の管理、検索が用意になるという利点がある。また、広告データの作成に不慣れな広告主でも、容易に設定可能であるという利点がある。

インタフェース画面では、広告主が用意した詳細広告を登録することもできる。本実施例では、詳細広告のデータのパスを入力することで指定可能とした。こうすることにより、広告主が独自に用意したＰＲ度の高い広告を利用することも可能となる。右下に示した広告イメージの「詳細を見る」には、詳細広告のデータへのリンクが設定されている。ユーザが、端末１００に表示された広告イメージにおいて、「詳細を見る」をクリックすると、広告主が独自に用意した詳細な広告を見ることが可能となる。図中に示したのは、広告イメージおよびその設定方法の一例に過ぎない。広告データは、この他、種々の方法で設定可能である。

広告の内容を入力した後、インタフェース画面において、広告主が「確定」ボタンを押すと（ステップＳ５０６）、サーバ２００は時間帯指定を保存して（ステップＳ５０８）、この処理を終了する。保存先は、広告主ＤＢ２０４である。広告主がインタフェース画面で、「キャンセル」を押すと（ステップＳ５０６）、サーバ２００は時間帯指定を保存することなく、この処理を終了する。

Ｃ６．コスト見積もり処理：
図１１はコスト見積もり処理のフローチャートである。広告登録処理のステップＳ５００に相当する処理である。この処理は、配信条件に基づいて、広告配信のコストを試算する処理である。サーバ２００の課金処理部２５０が主として実行する処理に相当する。

処理を開始すると、サーバ２００は配信条件指定データを読み込む（ステップＳ６０２）。そして、日付指定に基づき、広告の配信日を抽出する（ステップＳ６０４）。配信日の抽出は、期間を限定せずに行っても良いし、年単位、月単位、週単位のように期間を絞って抽出してもよい。

サーバ２００は、抽出された日を対象として、一日あたりの広告の広告料、つまり配信コストを算出する（ステップＳ６０６）。図中に広告料の算出方法を示した。本実施例では、基本料金に対して、エリア・ルート指定による係数、日付による係数、時間による係数を乗じることでコストを算出する。基本料金は、優先順位、つまり他の広告主に比較して自己の配信を優先させるか否かの設定に応じて、複数段階の料金設定がある。

エリア係数は、広告の配信対象となるエリアの広さやルートの長さに応じてコストを増減するための係数である。エリア指定がされている時には、指定された配信エリアの広さを、予め設定された基本エリアで除した値を係数として用いる。配信エリアが、基本エリアよりも広い場合には、広告料は増加し、基本エリアより狭い場合には、広告料は低くなる。ルート指定された場合には、指定された区間の総距離を、予め設定された基本距離で除した値に、ルート係数を乗じた値を用いる。ルート係数とは、道路種別に応じた係数であり、一般道や県道の場合は値１、国道の場合には１．１に設定した。国道の方が一般道よりも通行量が多く、広告の有用性が高くなることを反映させるためである。もっとも、ルート係数は、任意に設定可能であり、道路種別に応じて更に細分化した設定としてもよいし、道路種別に依らず値１としてもよい。

日付係数は、広告配信日の種別に応じて広告料を増減するための係数である。本実施例では、平日には値１、土曜・日曜・祝日には値１．０５、ゴールデンウィーク（ＧＷ）やお盆などには値１．１を設定するようにした。平日よりも、週末、ＧＷ等の方が、通行量が多く、広告の有用性が高くなることを反映させるためである。日付係数は、任意に設定可能であり、日付の種別に応じて更に細分化した設定としてもよいし、種別に依らず値１としてもよい。

時間係数は、広告配信の時間長に応じて広告料を増減するための係数である。本実施例では、配信時間を基本時間で除した値を用いた。時間帯によって重みを変えるようにしてもよい。

サーバ２００は、以上のコスト算出を、全配信日について実行する（ステップＳ６０８）。そして、これらの算出結果を提示し、優先順位についての指定を入力する（ステップＳ６１０）。図中に結果の表示例を示した。ステップＳ６０６で説明した通り、本実施例では、基本料金が「優先順位」によって変動する。優先順位を「高」に設定すれば、料金が高くなるが、他の広告主よりも優先的に配信されるため、広告の有用性を高めることができる。優先順位を「低」に設定すれば、広告配信の優先性は劣るものの、料金を抑えることができる利点がある。結果表示では、優先順位ごとに、全配信日についてのコストの総和を表示する。また、配信条件の適否を判断する目安として、コスト算出に用いた配信日数、および配信時間も表示する。

広告主は、これらの結果を参照し、自己の予算を考慮して、優先順位を選択する。図の例では、「高」を選択した状態を示した。広告主が「確定」を押すと、サーバ２００は優先順位の指定を保存して（ステップＳ６１２）、この処理を終了する。保存先は、広告主ＤＢ２０４である。

ステップＳ６０６で示した広告料の算出方法は、配信条件を決定するために、広告料の目安を与えるためのものである。広告料が配信条件に応じて定まる固定料金となっている場合には、実際にかかるコストとステップＳ６０６の算出結果とは一致する。広告料が実際に配信された回数等に応じて変化する場合には、ステップＳ６０６は平均的な配信頻度を想定した見積もりを表しているに過ぎず、実際の課金とは必ずしも一致しない。

Ｄ．経路案内の概要：
図１２は経路案内処理の概要を示す説明図である。サーバ２００には、先に説明した通り、広告ＤＢ２０３に広告および配信条件が登録されている。この状態で、ユーザが出発地、目的地を指定すると、サーバ２００は指定された出発地から目的地までの経路を探索し、ユーザの端末１００にその経路を表示しつつ、適宜、広告ＤＢ２０３に登録された広告も提示する。この提示は、ユーザの現在位置等が、各広告に設定された配信条件を満たした時に行われる。経路案内および広告配信をするための制御処理は後述するとして、まずは図１２に即して、本実施例で実現される広告配信の概要を説明する。

図の例では、星印で示した店舗に、配信条件１、２に対応する２つの広告が登録されている。「配信条件２」では、店舗を中心として半径Ｒｒの円弧内を配信対象とし、その中で店舗に接近してくるユーザを配信ターゲットとして指定している。その他の条件についての指定はない。あるユーザが、図中の点Ｐ１からＰ２に移動したとする。この移動によって店舗とユーザとの距離は、Ｄｐ１からＤｐ２に短くなっている。サーバ２００は、この結果、このユーザは店舗に接近しているものと判断し、配信条件２を満たすと判断して、この広告をユーザの端末に配信する。ここでは、単にユーザと店舗との距離の変化に基づいて「接近」と判断したが、点Ｐ１におけるユーザの進行方向と店舗の存在方向との角度、つまり図中の点Ｐ２、点Ｐ１、店舗の内角の大きさに基づいて接近か否かを判断するようにしてもよい。

「配信条件１」では、配信対象となる範囲は「ルートＲｏＡ」（図中でハッチングを付したルート）に指定されている。また「スキー場帰り」のユーザのうち、「食事」したいと考えているユーザを配信ターゲットとしている。従って、スキー場Ａから矢印Ａｒ１のように帰ってくるユーザ、スキー場Ｂから矢印Ａｒ２のように帰ってくるユーザに対しては、ルートＲｏＡに到達した時点で、配信条件１の広告が配信される。

配信条件１には、この他に移動開始後、所定時間以上経過したユーザを配信ターゲットとする条件を設定してもよい。設定次第では、比較的近距離にあるスキー場Ｂからのユーザには、広告が配信されなくなる場合もある。このように移動開始後の経過時間を考慮して配信ターゲットを設定することにより、「食事」はある程度、運転に疲れたところで休憩を兼ねて取ることが多いことを反映した広告配信が可能となり、広告の有用性を向上させることが可能となる。

スキー場Ｃから帰宅するユーザは、矢印Ａｒ３に示すように途中でレストランに立ち寄った後、矢印Ａｒ４のように移動している。このユーザは、レストランに立ち寄った時点で食事を済ませている可能性が高い。そこで、サーバ２００は、このユーザがルートＲｏＡに到達した場合であっても、「食事」という目的での店舗への立ち寄りは考えないと判断し、配信条件１の広告の配信を差し控える。このようにサーバ２００は、ユーザの過去の走行履歴を考慮して、広告の配信を制御することもできる。

自宅から出発し矢印Ａｒ５のように移動しているユーザは、「スキー場帰り」という条件を満たさない。また、Ｚ社から矢印Ａｒ６のようにインターチェンジＩＣに向かうユーザも、「スキー場帰り」という条件を満たさない。従って、ルートＲｏＡに到達した場合でも、これらのユーザには、配信条件１の広告は配信されない。

Ｅ．経路探索、経路案内処理：
以上で説明した経路案内、広告配信は、ユーザが指定した出発地、目的地間の経路を探索する経路探索処理、およびこの経路をユーザに案内する経路案内処理によって、実現される。以下、これらの処理について順次、説明する。

Ｅ１．経路探索処理：
図１３は経路探索処理のフローチャートである。ユーザが、端末１００を搭載した車両での移動に先立って、サーバ２００に出発地から目的地までの経路を探索させるための処理である。サーバ２００は、ユーザが端末１００の操作によって指示した探索条件を入力する（ステップＳ８０２）。探索条件には、出発地、経由地、目的地の指定、出発日時の指定が含まれる。ユーザが移動する際のグループおよび移動目的の指定などを含めても良い。

探索条件の指定を入力すると、サーバ２００は、経路探索を実行し、結果を格納する（ステップＳ８０４）。経路探索には、ダイクストラ法など周知の方法を利用することができる。結果の格納先は、ユーザＤＢ２０２である。

次に、サーバ２００は、ドライブシミュレーションを実行する（ステップＳ８０６）。ユーザが指定した出発日時に、指定された出発地から予め設定された標準的な移動速度で移動を開始したとして、経路上の各地点の到達予想時刻を求めるのである。この処理の過程で、サーバ２００は広告選択処理を併せて行う（ステップＳ８３０）。この処理は、広告配信部２４２（図１参照）の実行する処理に相当し、広告ＤＢ２０３の中から、配信条件に適合する広告を選択する処理である。処理内容については後述する。ドライブシミュレーションの過程で広告選択処理を実行することにより、ユーザが受け取る広告を特定することができる。サーバ２００は選択結果も併せてユーザＤＢ２０２に格納しておく。

以上の処理をサーバ２００は、ユーザが指定した全行程について完了するまで実行する（ステップＳ８５０）。出発地から目的地までの片道行程のみが指定されている場合には、目的地に到達するまでドライブシミュレーションを繰り返すことになるし、更に復路の出発日時等が指定されている場合には復路のドライブシミュレーションも実行する。この結果、サーバ２００は指定された全行程について、ユーザに配信されることとなる広告を特定することが可能となる。

サーバ２００は、以上で得られた結果を端末１００（本実施例では、カーナビ）に出力する（ステップＳ８５２）。出力されるデータには、経路探索結果、およびドライブシミュレーションで特定された広告データが含まれる。この結果、端末１００はサーバ２００との通信なく、スタンドアロンでも経路案内、広告の提示が可能な状態となる。スタンドアロンでの経路案内が不要な場合には、ステップＳ８０６以下の処理は省略しても差し支えない。

Ｅ２．経路案内処理：
図１４は経路案内処理のフローチャートである。ユーザが移動を開始した後の現在位置に応じて経路の案内、および広告の提供を行うための処理である。サーバ２００は、まず、ユーザＤＢ２０２から、経路探索結果を読み込む（ステップＳ８１０）。そして、ユーザの現在位置を入力する（ステップＳ８１２）。現在位置は、端末１００のＧＰＳ１４０を利用して検出することができる。

ユーザの現在位置が所定時間、移動しない時は停止中と判断し（ステップＳ８１４）、サーバ２００は、地図ＤＢ２０１から立寄場所を特定し（ステップＳ８１６）、ユーザＤＢ２０２の走行履歴に記録する（ステップＳ８１８）。立寄場所は、地図ＤＢ２０１を参照することにより、現在位置の座標に対応する地物を抽出すればよい。対応する地物が得られない場合には、立寄場所不明と扱うものとした。現在位置に含まれる誤差範囲を考慮して、所定距離内の地物を立寄場所として扱っても良い。停止中でない場合には（ステップＳ８１４）、これらの処理はスキップされる。

次に、サーバ２００は、広告選択処理を実行する（ステップＳ８３０）。現在位置に応じて、配信条件に適合する広告を選択する処理である。処理内容は後述する。サーバ２００は、こうして選択された広告を端末１００、即ちカーナビに出力する（ステップＳ８６０）。併せて、気象情報、渋滞情報など、サーバ２００がＷｅｂサーバ４００から取得した情報を提供してもよい。

図中に端末１００の表示例を示した。本実施例では、端末１００の画面は、３つのウィンドウＷ１〜Ｗ３から構成される。ウィンドウＷ１には、地図、経路、および現在位置が表示される。ウィンドウＷ２には、気象情報、渋滞情報、および目的地までの距離、到着予想時刻などが表示される。ウィンドウＷ３には、広告が表示される。ウィンドウＷ３において、ユーザが「詳細を見る」をクリックすると、広告主が登録した詳細な広告を表示させることができる。「場所を確認」をクリックすると、広告主が登録した店舗位置がウィンドウＷ１に表示される。現在位置から店舗までの経路を併せて表示するようにしてもよい。

サーバ２００は、以上の処理を、目的地に到着するまで（ステップＳ８６２）、繰り返し実行する。上述の説明は、サーバ２００と端末１００との通信が確保されている状況での処理である。本実施例では、先に説明した通り、経路探索処理において、事前に経路探索結果や広告データが取得されている。従って、移動中の状況により、サーバ２００と端末１００との通信が遮断されている場合には、端末１００に取得済みのデータを用いて経路案内や広告出力（ステップＳ８６０）を行ってもよい。

Ｅ３．広告選択処理：
図１５は広告選択処理のフローチャートである。経路探索処理（図１３）および経路案内処理（図１４）のステップＳ８３０に相当する処理である。広告配信部２４２（図１参照）が実行する処理であり、広告ＤＢ２０３に登録された広告の中から、ユーザの現在位置等に応じて配信条件に適合する広告を選択する処理である。

この処理では、サーバ２００は、経路探索条件、経路探索結果、および走行履歴を読み込む（ステップＳ８３２）。そして、ユーザの現在位置、日時を入力する（ステップＳ８８４）。経路探索処理（図１３）において広告選択処理を実行する際には、ドライブシミュレーションによって求められる各位置の到達予測時刻を入力することになる。

サーバ２００は、以上で入力された情報に基づき、配信条件に適合する広告を広告ＤＢ２０３から抽出する（ステップＳ８３６）。例えば、サーバ２００は、ユーザの現在位置が、配信条件で設定されたエリア・ルートの指定を満たしているか否かを判断する。これらの指定において、ユーザの進行方向も条件に含まれている時には、現在位置の変化に基づいて進行方向を判断することができる。また、ルート指定されている場合には、探索結果と現在位置から、ユーザが通行しているリンクを特定することで、進行方向も含めてルート条件を満たすか否かを判断するようにしてもよい。

配信日時、配信時間帯の条件は、現在日時から容易に判断可能である。また、配信ターゲット（図４参照）のうち、「対象者」については、経路探索時に入力された「グループ」に基づいて判断することができる。配信ターゲットの指定条件のうち、「目的地」、「立寄目的」については、ユーザが探索条件で指定した目的地に基づいて判断することができる。この他、ユーザが探索条件で指定した「移動目的」を参照してもよい。こうすることにより、例えば、探索条件の目的地として、スキー場にある「ペンション」が指定されている場合でも、移動目的として「スキー」が入力されている時には、配信条件（図４）における目的地「スキー場」という条件を満たすものと判断することが可能となる。

広告の配信条件には、移動開始後の経過時間を指定することもできる。例えば、「３時間以上」経過したユーザを配信ターゲットとする旨の指定である。かかる指定が含まれている場合には、サーバ２００は、出発時刻と現在時刻の差違から、移動開始後の経過時間を算出し、この条件が満たされているか否かを判定すればよい。サーバ２００は、走行履歴を参照して、休憩などで停止している時間の総和を求め、この総和を上述の経過時間から引いた時間に基づいて上述の条件を満たすか否かを判断してもよい。こうすることにより、実際に運転していた時間を基準とすることができ、運転者の疲労度を考慮して条件を判断することが可能となる。

サーバ２００は、次に抽出した広告をソートするための条件として、目的別の優先順位を設定する（ステップＳ８３８）。図中に優先順位の設定例を示した。自宅を出発し、ランチをとった後、目的地に到着し、帰りにディナーを食べて、帰宅するという行程を想定した場合の例である。サーバ２００は、ユーザの立ち寄り場所に基づき、行程を複数のフェーズに分ける。図の例では、自宅を出た後、ランチをとるまでの間（第１フェーズ）、ランチから目的地まで（第２フェーズ）、目的地からディナーまで（第３フェーズ）、ディナーから帰宅まで（第４フェーズ）と分けられる。

フェーズに分けた後、サーバ２００は、各フェーズについて、ユーザが必要とする情報を抽出する。例えば、第１フェーズでは、目的地周辺の観光情報、ランチ用のレストラン、ガソリンスタンド、高速道路のサービスエリア情報、観光道路の情報などが抽出される。この情報は、２通りの方法で設定可能である。

第１の方法では、自宅を出発した後に要求される情報のテーブルを予め用意しておく。そして、ユーザが設定した行程に応じて、このテーブルから不要なものを除外していくのである。図中の第１フェーズを例にとって説明する。まず、図中に列挙した各情報を予め用意しておく。そして、仮にユーザの移動目的がビジネスであったとすれば、「目的地周辺の観光情報」を除外するのである。また、目的地までの移動経路に高速道路を使用しない場合には「高速ＳＡ」を除外する。出発時刻によっては、「レストラン（ランチ）」が不要となる場合もある。第１の方法では、各情報の優先順位は、予めフェーズごとに設定しておくことができる。

第２の方法では、フェーズと無関係に用意された多種多様な情報から、各フェーズの条件に該当するものを抽出する方法である。図中の第１フェーズを例にとって説明する。まず、「目的地周辺の観光情報」、「レストラン（ランチ）」などの情報項目をフェーズと無関係に用意しておく。各情報には、フェーズとの関係で採用の適否を決定するための条件が付されている。例えば、「目的地周辺の観光情報」については、「目的地に到達するまで」という条件が付され、「レストラン（ランチ）」には「ランチ前」という条件が付されている。サーバ２００はこの条件を参照して、第１フェーズに適合する情報項目を抽出する。第１フェーズでは、目的地にも到達しておらず、ランチもとっていないため、「目的地周辺の観光情報」、「レストラン（ランチ）」が抽出されることになる。抽出された情報の優先順位も種々の方法で設定可能である。本実施例では、目的地に関する情報、立寄場所に関する情報、その他の情報の順で優先順位を設定した。こうすることにより、図中の第１フェーズに示したような優先順位設定を行うことができる。

目的別の優先順位設定が完了すると（ステップＳ８３８）、サーバ２００はステップＳ８３６で抽出された広告を、目的、配信実績、広告主が設定した優先順位、近い順にソートする（ステップＳ８４０）。ステップＳ８３８の優先順位は、「目的」をキーとするソートに利用される。このソートについては具体例を後で示す。

サーバ２００は、次に、走行履歴を参照し、ユーザが立ち寄ってきた場所の立寄目的と同一目的の広告を配信対象から除外する（ステップＳ８４２）。例えば、ユーザが「レストラン」に立ち寄った場合には、「食事」は済ませていると判断し、配信ターゲットの条件として「食事」を立寄目的としている広告を除外するのである。これらの情報を除外せずに、ソート順位を下げて配信の優先度を低下させる方法を採っても良い。

立寄場所の立寄目的は、次の方法で特定することができる。図２で説明した通り、地図ＤＢ２０１には、地物ごとの種別を含む属性が記録されている。サーバ２００には、地図ＤＢ２０１とは別に、この地物の種別と立寄目的とを予め対応づけたテーブルを用意しておく。例えば、「レストラン」という種別に対して、「食事」という立寄目的を対応づけたテーブルである。「ドライブイン」という種別に対して、「食事」、「休憩」、「おみやげ」というように複数の立寄目的を対応づけてもよい。サーバ２００は、ユーザが立ち寄った地物から種別を特定し、上述のテーブルを参照することによって、更に立寄目的を特定することができる。この方法の他、地図ＤＢ２０１の属性として、予め立寄目的を格納しておくようにしてもよい。サーバ２００は、以上の処理によって配信対象となる広告を絞り込んだ後、最上位の広告を配信対象として選択する（ステップＳ８４６）。選択された情報は、経路探索処理、経路案内処理において、それぞれ端末１００に送信等される。

図１６は広告のソート例を示す説明図である。図の左側には、広告ＤＢ２０３に登録されている広告の配信実績および配信条件を列挙した。ここでは、「対象者」、「目的地」、「立寄目的」は配信ターゲットの設定条件（図４参照）で指定された条件である。「運転時間」は出発後の経過時間に関する条件である。「配信回数」は、それぞれをそのユーザに配信した実績を表している。この実績はユーザＤＢ２０２に格納可能である。「優先順位」は広告主が設定した優先順位（図１１参照）である。

ファミリーでスキー場から帰ってくる途中のユーザがいる場合を想定して説明する。サーバ２００は、まず配信条件に適合する広告を抽出する（図１５のステップＳ８３６の処理）。従って、「カップル」、「ビジネス」を対象者と指定する広告２、３は配信条件を満たさない。また、「温泉」を目的地とする広告５も配信条件を満たさない。ユーザの運転時間が３時間に至っていない場合には、「運転時間」の点でも広告２は配信条件を満たさないことになる。この結果、配信条件を満たす広告として、広告１、４、６、７の４つが抽出されることになる。

次に、サーバ２００は抽出された広告をソートする（図１５のステップＳ８４０の処理）。本実施例では、立寄目的を第１キー、配信回数を第２キー、優先順位を第３キーとしてソートするものとした。立寄目的の優先順位は、図１５のステップＳ８３８の処理で設定される。ここでは、「おみやげ」、「食事」の順で優先順位が設定されているとする。

図中の右側にソート結果を示した。立寄目的によって、「おみやげ」（広告６）、「食事」（広告７、１）、指定なし（広告４）の順にソートされる。広告７、１については配信回数が同数であるため、優先順位に基づき、広告７の方が広告１よりも優先となる。結果として、広告６、７、１、４の順にソートされる。

次に、走行履歴を参照して、ユーザが「おみやげ」を既に購入していたことが見いだされたとする。サーバ２００は、同一の立寄目的の広告を除外するから（図１５のステップＳ８４２の処理）、広告６は配信対象から除外される。従って、残った広告の中で最も最上位の広告７が選択されることになる。本実施例では、広告を一つだけ選択しているが、複数選択可能としてもよい。この場合には、ソート結果に従って、広告７、１、４の順に必要な数だけ選択すればよい。

以上で説明した本実施例のガイド情報提供システムによれば、広告主が設定した配信条件に従って（ステップＳ８３６）、広告を配信することができる。また、ステップＳ８３８の処理によって、ユーザが必要とする情報を優先して配信することができる。更に、走行履歴を考慮することにより（ステップＳ８４２）、ユーザにとって不要となったと推測される広告の配信を抑制することができる。従って、広告の有用性を向上させることができる。また、広告主にとっては、効率的に広告を提供することが可能となる。

本実施例のガイド情報提供システムは、エリア・ルート設定など、配信条件の設定時に、広告主に推奨の設定を提示することができる。従って、広告主は、比較的容易に適切な配信条件の設定をすることができる。この結果、広告の効率を更に向上させることが可能である。

Ｆ．変形例：
本実施例では、以下で変形例として示す通り、広告の配信に際し、更に種々の配信条件を考慮することが可能である。
（１）出発前も含む過去の履歴を考慮する例：
実施例では、配信条件として、出発以降の運転時間や立寄場所を考慮する場合を例示した（図１６参照）。本実施例では、出発前も含めて過去の履歴を考慮するようにしてもよい。例えば、ガソリンスタンドの広告主が、燃料残量の少ないユーザに絞って広告を配信したいと考え、「残燃料量が○％以下」という配信条件を設定した場合を考える。この場合、サーバ２００は、出発前も含めて走行履歴を参照し、最後に給油を行った時点からのユーザの車両の走行距離を求め、その車両が給油間で走行する平均的な距離に基づいて残燃料量の割合を推測し、上述の条件に合致すれば広告を配信するという制御をすることができる。残燃料量に代えて、「走行可能距離が○ｋｍ以下」という形で配信条件を設定してもよい。この条件に対して、更に、「現在位置からガソリンスタンドまでの道のりが、走行可能距離より短いこと」を追加してもよい。

（２）ネットワークで提供される情報を考慮した配信条件の設定例１：
実施例では、端末１００のウィンドウＷ２に気象情報、渋滞情報など、ネットワーク経由でＷｅｂサーバ４００から取得した情報を提示する例を示した（図１４）。本実施例では、これらの情報を考慮して配信条件を設定してもよい。一例として、自動車用品店がタイヤチェーンなど滑り止め具の広告を発信する場合を考える。広告主は、「雪が降っている時、または雪が数日内に降る時」という気象条件に基づいて、配信条件を設定したとする。この場合、当該店舗の周辺で雪が降っていない場合であっても、ユーザの目的地周辺で雪が降っている場合には、そのユーザは配信ターゲットとして抽出することが好ましい。そこで、サーバ２００はユーザが設定している目的地付近の気象情報を取得し、その気象情報に基づいて配信条件に合致するか否かを判断するのである。こうすることにより、店舗周辺の気象情報だけで配信可否を判断する場合よりも、広告の有用性を向上させることができる。かかる判断をした場合には、ユーザに対して、判断の基礎となった情報、即ち「目的地周辺の気象情報」と併せて広告を配信してもよい。こうすることで、広告に対してユーザの注意をより喚起することが可能となる。

（３）ネットワークで提供される情報を考慮した配信条件の設定例２：
別の態様として、渋滞情報を配信可否の判断に活用する例を２通り示す。第１の態様では、図７に示したように、広告主がある店舗について食事の広告を配信する場合を考える。広告主は、図７で示した配信条件を付した広告の他、区間Ｄ１にいるユーザを対象として、「区間Ｄ２が渋滞時」という配信条件を付した渋滞用広告を用意しておく。サーバ２００は、ユーザが区間Ｄ１にいるユーザを見いだすと、区間Ｄ２が渋滞しているか否かを判断し、渋滞している時には、渋滞用広告を配信する。渋滞していない時には、図７で説明した通り、その他の配信条件を考慮して、通常の広告を配信する。このように区間Ｄ２が渋滞しているか否かによって、配信する広告を切り換えることによって、それぞれの状況に応じて広告の有用性を向上させることができる。

第２の態様では、区間Ｄ２が渋滞しているか否かによって配信条件を切り換える。店舗の広告主は、通常時の配信条件として「区間Ｄ１にいるスキー場帰りのユーザ」を指定し、更に、「区間Ｄ２が渋滞している時には「区間Ｄ１にいる全ユーザ」を指定しているとする。そして、サーバ２００は区間Ｄ１にいるユーザを見いだした時、区間Ｄ２が渋滞していなければ他の配信条件を満たした時にのみ配信し、渋滞時であれば無条件に広告を配信する。区間Ｄ２が渋滞時であれば、トラック運転手など、スキー場帰り以外のユーザも広告に興味を示す可能性が高まるからである。このように区間Ｄ２の渋滞状況に応じて、広告の配信条件を切り換える態様を採ることにより、広告の有用性を向上させることができる。

上述の２つの態様を組み合わせ、区間Ｄ２の渋滞状況に応じて、広告内容および配信条件の双方を切り換えるようにしてもよい。このように、本実施例は、ユーザが将来至る経路の状態を表す情報、例えば目的地の天候や将来の経路の渋滞状況などに応じて、配信可否の判断または配信すべきガイド情報の内容を切り換えるという態様で構成することも可能である。

（４）ガイド情報の利用実績を考慮する例：
実施例では、ユーザごとにガイド情報の配信実績を考慮して、既に受け取ったガイド情報が繰り返し配信されるのを回避する例を示した（図１６）。本実施例は、更に、以下の手順により、各ガイド情報の利用実績を考慮し、この利用実績に基づいてガイド情報間の優劣を設けるものとしてもよい。サーバ２００は、ユーザにガイド情報を配信した後のユーザの走行履歴に基づいて、ユーザがガイド情報の登録地点に立ち寄ったか否かを判断し、ユーザの異同を問わず立ち寄った回数を、当該ガイド情報の利用実績としてカウントする。そして、この利用実績に基づいてガイド情報間に優劣をつける。ただし、実施例で示したように、広告主が支払う費用によって優先順位が規定されている場合には、利用実績に基づく優劣は同順位の中だけにとどめることが望ましい。このように優劣を付けることにより、ユーザには利用実績の高い広告が優先的に配信されるようになり、かかる広告の有用性をより向上させることが可能となる。併せて、サーバ２００が、各広告主に対して利用実績をレポートするようにしてもよい。

（５）広告に対する応答を許容する例：
実施例では、ユーザが広告を受信し、必要に応じて場所を確認したり、詳細な情報を閲覧したりする例を示した（図１４）。本実施例は、ユーザがこの広告に対して、更に積極的な応答をすることが可能なシステムとして構成してもよい。例えば、広告に対して、所定の操作をすることにより、店舗に予約を入れることができるようにしてもよい。サーバ２００が端末１００から予約の指示を受け付けると、その予約を広告主から指定されたアドレスにメールで送信する方法等を採ることができる。サーバ２００は、予約に連動して、ユーザに対してその店舗までの経路を案内するようにしてもよい。また、ユーザが予約を申し込んだ時点で、サーバ２００が店舗までの経路、所要時間、渋滞の有無など、店舗に到達するまでの困難さを推測させる情報を提示した上で、予約をするか否かの確認をするようにしてもよい。更に、サーバ２００が他のユーザの走行履歴を参照することで、当該店舗に立ち寄っているユーザ数を算出し、その結果を基に、当該店舗の混雑具合を推測してユーザに提示するようにしてもよい。

以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。実施例では、広告の配信を例示したが、観光案内や行政情報など種々の情報を配信対象とすることができる。

実施例としてのガイド情報提供システムの構成を示す説明図である。 地図ＤＢ２０１のデータ構造を例示する説明図である。 広告登録処理のフローチャートである。 配信ターゲット設定処理のフローチャートである。 エリア・ルート選択処理のフローチャートである。 ルート選択処理のフローチャートである。 ルート選択例を示す説明図である。 日付指定処理のフローチャートである。 時間帯指定処理のフローチャートである。 広告内容指定処理のフローチャートである。 コスト見積もり処理のフローチャートである。 経路案内処理の概要を示す説明図である。 経路探索処理のフローチャートである。 経路案内処理のフローチャートである。 広告選択処理のフローチャートである。 広告のソート例を示す説明図である。

符号の説明

１００…端末
１１０…主制御部
１２０…通信部
１３０…コマンド入力部
１４０…ＧＰＳ
１５０…表示制御部
２００…情報提供サーバ
２０１…地図ＤＢ
２０２…ユーザＤＢ
２０３…広告ＤＢ
２０４…広告主ＤＢ
２１０…通信部
２２０…出力データ生成部
２３０…経路案内部
２３２…経路探索部
２４０…広告登録部
２４２…広告配信部
２５０…課金処理部
３００…パソコン
４００…Ｗｅｂサーバ

Claims (10)

1. 特定の地点に対応するガイド情報を、ユーザに提供するガイド情報提供システムであって、
   前記ユーザが移動可能な道路を記録した地図データベースと、
   前記ユーザの現在位置を前記道路単位で検出する検出部と、
   ユーザの出発地、目的地の少なくとも一方と道路単位で特定されたガイド情報の提供範囲とを含む提供条件とガイド情報とを対応づけて登録したガイド情報データベースと、
   ユーザの出発地、目的地の少なくとも一方を入力する入力部と、
   前記入力されたユーザの出発地と前記検出された現在位置を表わす道路単位との組み合わせ、および前記入力されたユーザの目的地と前記検出された現在位置を表わす道路単位との組み合わせ、の少なくとも一方に基づいて、ガイド情報データベースに登録された提供条件を参照して、前記ユーザに提供すべきガイド情報を選択するガイド情報選択部と、
   前記選択されたガイド情報を出力するガイド情報出力部と
   を備えるガイド情報提供システム。
2. 請求項１記載のガイド情報提供システムであって、
   前記提供条件には、前記道路上のユーザの進行方向を含む
   ガイド情報提供システム。
3. 請求項１または請求項２記載のガイド情報提供システムであって、
   前記入力部は、前記出発地と前記目的地との入力を受け付け、
   前記出発地および前記目的地を用いて、経路案内を行なう経路案内部を備えたガイド情報提供システム。
4. 請求項３記載のガイド情報提供システムであって、
   前記地図データベースは、前記道路をノードおよびリンクにより記憶するとともに、該道路の少なくとも一部を上り下りの２条からなるリンクにより記憶しており、
   前記経路案内部は、前記地図データベースのリンクを用いて、前記ユーザが指定した出発地から目的地に向かうために通行すべき経路を案内し、
   前記検出部は、前記道路単位での前記現在位置の検出を、前記案内すべき経路と前記現在位置とから、前記リンク単位で行う
   ガイド情報提供システム。
5. 特定の地点に対応するガイド情報を、ユーザに提供するガイド情報提供システムであって、
   前記ユーザの現在位置を検出する検出部と、
   地物の位置および該地物の種別とを含む地図データベースと、
   前記検出されたユーザの現在位置に基づいて、前記地図データベースを参照して、前記ユーザが立ち寄った地物を特定する手段と、
   前記検出されたユーザの現在位置から、当該ガイド情報の提供を行なっている際のユーザの移動状況であって、前記ユーザが立ち寄った地物を含む移動状況を保持する移動状況保持部と、
   前記ガイド情報と前記ガイド情報を提供する条件である提供条件とを対応づけて登録したガイド情報データベースと、
   前記ガイド情報データベースから、前記保持された移動状況が前記提供条件に該当するガイド情報を選択するガイド情報選択部と、
   前記選択されたガイド情報を出力するガイド情報出力部と、
   前記ユーザが立ち寄った地物から前記ユーザの訪問目的を特定する手段と
   を備え、
   前記提供条件は、前記特定の地点への訪問目的に基づいて定められた条件を含み、
   前記ガイド情報選択部は、前記立ち寄った地物の種別に基づいて特定される訪問目的と同一の訪問目的に対応するガイド情報の優先度を低くして前記選択を行う
   ガイド情報提供システム。
6. 請求項５記載のガイド情報提供システムであって、
   前記ユーザの現在位置を用いて、前記地図上で、経路案内を行なう経路案内部を備えたガイド情報提供システム。
7. 特定の地点に対応するガイド情報を、ユーザに提供するガイド情報提供方法であって、
   コンピュータが実行すべき工程として、
   前記ユーザが移動可能な道路を記録した地図データベースを参照する工程と、
   前記ユーザの現在位置を前記道路単位で検出する工程と、
   ユーザの出発地、目的地の少なくとも一方を入力する工程と、
   ユーザの出発地、目的地の少なくとも一方と道路単位で特定されたガイド情報の提供範囲とを含む提供条件とガイド情報とを対応づけて登録したガイド情報データベースから、前記入力されたユーザの出発地と前記検出された現在地を表わす道路単位との組み合わせ、または前記入力されたユーザの目的地と前記検出された現在地を表わす道路単位との組み合わせ、の少なくとも一方に該当するガイド情報を選択する工程と、
   前記選択されたガイド情報を出力する工程と
   を備えるガイド情報提供方法。
8. 特定の地点に対応するガイド情報を、ユーザに提供するガイド情報提供方法であって、
   コンピュータが実行すべき工程として、
   前記ユーザの現在位置を検出する工程と
   前記検出されたユーザの現在位置に基づいて、少なくとも地物の位置および該地物の種別とを含む地図データベースを参照して、前記ユーザが立ち寄った地物を特定する工程と、
   前記検出されたユーザの現在位置に基づいて、当該ガイド情報の提供を行なっている際のユーザの移動状況であって、前記ユーザが立ち寄った地物を含む移動状況を保持する工程と、
   前記ガイド情報と前記ガイド情報を提供する条件である提供条件とを対応づけて記憶するガイド情報データベースから、前記保持された移動状況が前記提供条件に該当するガイド情報を選択する工程と、
   前記選択されたガイド情報を出力する工程と、
   前記ユーザが立ち寄った地物から前記ユーザの訪問目的を特定する工程と
   を備え、
   前記提供条件は、前記特定の地点への訪問目的に基づいて定められた条件を含み、
   前記ガイド情報の選択を、前記立ち寄った地物の種別に基づいて特定される訪問目的と同一の訪問目的に対応するガイド情報の優先度を低くして行う
   ガイド情報提供方法。
9. 特定の地点に対応するガイド情報を、ユーザに提供する処理をコンピュータに実現させるプログラムであって、
   前記ユーザが移動可能な道路を記録した地図データベースを参照する手順と、
   前記ユーザの現在位置を前記道路単位で検出する手順と、
   ユーザの出発地、目的地の少なくとも一方と道路単位で特定されたガイド情報の提供範囲とを含む提供条件とガイド情報とを対応づけて登録したガイド情報データベースから、前記入力されたユーザの出発地と前記検出された現在地を表わす道路単位との組み合わせ、または前記入力されたユーザの目的地と前記検出された現在地を表わす道路単位との組み合わせ、の少なくとも一方に該当するガイド情報を選択する手順と、
   前記選択されたガイド情報を出力する手順と
   をコンピュータに実現させるプログラム。
10. 特定の地点に対応するガイド情報を、ユーザに提供する処理をコンピュータに実現させるプログラムであって、
    前記ユーザの現在位置を検出する手順と
    前記検出されたユーザの現在位置に基づいて、少なくとも地物の位置および該地物の種別を含む地図データベースを参照して、前記ユーザが立ち寄った地物を特定する手順と、
    前記検出されたユーザの現在位置に基づいて、当該ガイド情報の提供を行なっている際のユーザの移動状況であって、前記ユーザが立ち寄った地物を含む移動状況を保持する手順と、
    前記ユーザが立ち寄った地物から前記ユーザの訪問目的を特定する手順と、
    前記ガイド情報と、前記ガイド情報を提供する条件であって、前記特定の地点への訪問目的に基づいて定められた条件を含む提供条件とを対応づけて記憶するガイド情報データベースから、前記保持された移動状況が前記提供条件に該当するガイド情報を、前記立ち寄った地物の種別に基づいて特定された訪問目的と同一の訪問目的に対応するガイド情報の優先度を低くして選択する手順と、
    前記選択されたガイド情報を出力する手順と、
    をコンピュータに実現させるプログラム。