(57)【要約】【課題】  予め登録されたスケジュールを実行する際に有用な情報を効率的にユーザに提供する。【解決手段】  情報提供サーバ２００は予め登録されたスケジュールに関連した情報を、スケジュール上の時間的制約も考慮して、事前にＷｅｂサーバ４００等から収集し蓄積しておく。スケジュール実行時には、目的地までの移動経路を提供するとともに、事前に収集したガイド情報をユーザに提供する。この際、ユーザの現在位置、次の予定までの余裕時間等を考慮して、情報提供を行うか否かを制御する。また、情報提供後は、ユーザが提供された情報に従った行動を採っているか否かを見て、提供した情報をユーザが欲しているか否かを判断し、情報不要と判断される場合には、他の情報を提供する。これらの判断処理を施すことにより、有用性の高い情報をユーザに効率的に提供することが可能となる。【選択図】  図１
2011081840.tif 000002
【特許請求の範囲】
【請求項１】
予め登録されたスケジュールに関連する情報を収集し、ガイド情報として提供するガイド情報提供システムであって、
時刻および目的地を含む予め登録されたスケジュールを参照し、該スケジュールに関連する情報を所定の情報源から収集する情報収集部と、
前記時刻および目的地を考慮して、前記収集された情報のうちユーザに提供すべき情報を選択し、該選択された情報を前記ガイド情報として提供する情報提供制御部と、
前記ユーザの現在位置を取得する現在位置取得部と、を備え
前記ガイド情報には、音声出力すべき情報が含まれており、
前記情報収集部は、更に、前記スケジュールと無関係に音声出力可能な汎用情報を保持しており、
前記情報提供制御部は、前記現在位置および前記スケジュールに基づいて前記音声出力すべきガイド情報の出力を開始する時刻までの余裕時間を推測し、該推測された余裕時間に基づいて出力すべき汎用情報を選択するガイド情報提供システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、予め登録されたスケジュールに関連する情報を収集し、ガイド情報として提供するガイド情報提供システムに関する。
【背景技術】
【０００２】
ユーザの指定した目的地までの経路を案内する経路案内システムが幅広く活用されている。近年では、経路を案内するだけでなく、経路を移動する際に有用な情報を提供する提案もなされている。例えば、特許文献１は、ユーザが通勤中ならビジネス書の入手先に関する情報を提供し、レジャー中であれば趣味に関する書籍の入手先に関する情報を提供するというように、ユーザの移動目的に応じた情報を提供するシステムを開示する。特許文献２は、ユーザが登録した店舗をジャンル毎に集計するなどの方法で、ユーザの嗜好を分析しておき、ユーザが目的地の検索を行った場合には、ユーザの嗜好に沿った店舗を紹介するシステムを開示する。特許文献３は、カーナビゲーションシステムを対象とし、例えば、車両の燃料残量が少なくなるとユーザが通常利用しているガソリンスタンドへの経路を案内するというように、車両の状況等に基づいて有用な情報を提示するシステムを開示する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１４４５３１号公報
【特許文献２】特開２００４−３７２９２号公報
【特許文献３】特開２００５−３３９２７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１、２記載の技術は、ユーザが何らかの情報を欲した時に、ユーザの要望に添った情報を提供することでシステムの利便性を向上させることを主目的としていた。特許文献３の技術は、自動的に情報を提供してはいるが、情報が要求されるタイミングを車両の燃料残量の低下などの典型的な状況に基づいて判断するものであり、ユーザが欲した時になって初めて、必要な情報を収集して提供するというものであった。このように従来技術では、提供される情報がユーザにとって有用な情報か否かは、ユーザの要望に添っているか否かという観点から判断されていた。
【０００５】
ユーザは、予め設定されたスケジュールに従って行動することがある。このスケジュールには、通勤や通学などのように日常的に繰り返されるスケジュールもあれば、出張などのように日常とは異なるスケジュールもある。スケジュールが予め定まっている場合には、移動すべき目的地および到着すべき時刻が定まっているため、移動のための経路はユーザに有用な情報と言える。また、この経路を移動中に活用できる種々の情報も有用な情報となり得る。ただし、スケジュールに従った移動中は、次の目的地および到着時刻によって行動範囲が制約されるため、活用できる情報には限りがある。活用可能な限界を考慮せずに提供される情報は、例えユーザの嗜好や目的などの要望に沿っていたとしても、有用な情報とはなり得ない。従来技術では、こうしたスケジュールを実行する際の制約を考慮した情報提供は行うことができなかった。本発明は、この課題に鑑みなされたものであり、ユーザがスケジュールに沿って行動する際に、スケジュールを実行する際の制約事項を考慮に入れた有用な情報提供を実現することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、予め登録されたスケジュールに関連する情報を収集し、ガイド情報として提供するガイド情報提供システムとして構成することができる。ガイド情報は、ユーザがスケジュール実行時に参照可能な装置、例えば携帯電話、カーナビゲーション装置、ノートパソコン、ＰＤＡなどを利用して提供することができる。ガイド情報提供システムは、これらの装置を利用してスタンドアロンで稼働するように構成してもよいし、これらの装置を利用した端末とサーバ等をネットワークで接続して構成してもよい。
【０００７】
ガイド情報提供システムは、予め登録されたスケジュールを参照して、このスケジュールに関連する情報を所定の情報源から収集する。スケジュールには、時刻および目的地が含まれる。この他の情報、会議、レジャーなど、移動目的を表す情報をスケジュールに含めても良い。情報は、例えば、ガイド情報提供システムに設置されたＤＶＤその他の記録媒体から収集してもよいし、ネットワーク経由で収集してもよい。情報源は、必ずしもガイド情報提供システムの一部として構成されている必要はなく、例えば、インターネットに接続されたＷｅｂサーバを情報源として利用してもよい。
【０００８】
ガイド情報提供システムは、スケジュールで指定された時刻および目的地を考慮して、収集された情報のうちユーザに提供すべき情報を選択し、選択された情報をガイド情報としてユーザに提供する。例えば、次の目的地への移動経路に対して所定距離内にある地点に関する情報のみを選択する態様、指定された時刻に目的地に到達可能な範囲内の地点に関する情報のみを選択する態様を採ることができる。また、食事場所についての情報提供する場合には、目的地に移動する時間帯が食事時に当たるか否かを考慮して情報を選択するようにしてもよい。また、次の予定までの時間的な余裕が少ない場合には、予定に遅れる危険性を低減するため、目的地から遠い地点に関する情報は除外し、目的地に十分に近い地点に関する情報を選択するようにしてもよい。
【０００９】
このように本発明によれば、スケジュールに関連した情報を事前に収集しておくことができる。従って、情報の収集をリアルタイムで行う必要がないため、多種多様な情報源にアクセスして、幅広く有用な情報を収集できる。また、こうして収集した情報の中から、ユーザのスケジュールに適合した情報を選択して提供するため、スケジュール上の制約によりユーザが活用しづらい情報を排除することができる。従って、ユーザに有用な情報を効率的に提供することが可能となる。
【００１０】
本発明では、予め登録されたスケジュールに従って情報を収集するため、スケジュールを実行に移す時点よりも事前に十分な情報を収集しておくことも可能である。ガイド情報提供システムが、サーバと端末から構成されている場合でも、スケジュールの実行を開始する時点で、サーバに蓄積済みの情報を端末に移行させておけば、その後は逐次通信を行わなくてもガイド情報を提供することが可能となる。従って、本発明によれば、通信環境が比較的悪い場合でも、ガイド情報を有効活用できる利点も得られる。
【００１１】
ガイド情報提供装置は、ユーザの現在位置を取得可能としてもよい。この場合には、更に、取得された現在位置および現在時刻に基づいて、提供すべき情報を選択してもよい。こうすることにより、ユーザの移動状況と予め登録されたスケジュールとのずれを反映して情報の提供を行うことができる。例えば、ユーザの移動が予定よりも遅れており、次の目的地に到達するまでの時間余裕が短くなってしまった場合には、遅れている状況下でも活用可能な情報のみを更に絞り込んでガイド情報を提供することができる。また、ユーザの移動が予定よりも早い場合や、次の予定がキャンセルされた場合など、時間余裕が増えた場合には、収集されていた情報のうち一旦、除外されていた情報を有用な情報と評価し直すことでガイド情報として提供可能としてもよい。また、ユーザの移動している経路がスケジュール上予定されていた経路からずれている時も同様である。このような場合には、例えば予定されていた経路に近いという理由でガイド情報に組み込まれていた情報を、ガイド情報から削除することができる。また、予定されていた経路から遠いという理由でガイド情報から除外されていた情報を、再度有用な情報と評価し直すことでガイド情報として提供可能とすることもできる。
【００１２】
ガイド情報提供システムは、情報を所定のジャンルに分類して収集してもよい。分類のジャンルは任意に設定可能である。例えば、ショッピング、レストランという大きな分類をジャンルとして用いても良いし、ショッピングを「洋服」、「和服」、「セーラー服」、「下着」のように細分化した分類をジャンルとして用いても良い。この時、ガイド情報提供システムは、ガイド情報として提供済みの情報と関連するジャンルの情報を避けて情報の選択を行うことが可能となる。こうすることにより、類似の情報を繰り返しユーザに提供することを回避でき、有用な情報を効率的に提供することが可能となる。
【００１３】
ガイド情報提供システムは、所定の地図データベースを参照し、スケジュールに従った移動経路を探索するとともに、地図上に移動経路を示す案内情報を提供可能としてもよい。この時、移動経路およびガイド情報は、スケジュールとともに表示部に表示させることが好ましい。全スケジュールを表示してもよいし、次の予定を含む一部のスケジュールだけを表示してもよい。このようにスケジュールを併せて表示しておくことにより、ユーザは、自分のスケジュールを意識しながら移動経路およびガイド情報を活用することができる。上述の例において、ガイド情報提供システムが、サーバと端末から構成されている場合には、端末が表示部として機能する。従って、サーバは端末に表示させるための出力データを生成し、端末に送信すればよい。
【００１４】
ガイド情報提供システムがユーザの現在位置を取得可能である場合には、先に説明した移動経路を探索するとともに、現在位置からガイド情報に対応する地点まで移動する寄り道経路を探索してもよい。この場合、地図上には移動経路および寄り道経路を共に示すことが好ましい。例えば、ガイド情報として、移動経路から若干それた場所にある名所、店舗、レストランなどの情報を提供する場合には、現在位置からの行き方が寄り道経路として提供されることになる。この態様では、移動経路と寄り道とが併せて提供されるため、ユーザは、寄り道するための迂回距離などを踏まえて、情報提供された場所に立ち寄るか否かを決めることが可能となる。
【００１５】
このように移動経路と寄り道経路とを提供する態様においては、ユーザが寄り道経路を進行しているか否かを現在位置に基づいて判断し、寄り道経路から外れたと判断される場合には、寄り道経路に対応するガイド情報の提供を停止することが好ましい。寄り道経路から外れたところを進行しているということは、ユーザは寄り道をしないという決定をしたものと判断して、寄り道経路の表示を消すのである。こうすることで、ガイド情報が提供されるたびに、ユーザがそのガイド情報の要否を入力するという煩雑な必要がなくなるため、システムの利便性を向上することができる。この態様において情報提供が停止されるのは、表示されていた寄り道経路に対応する情報のみであり、新たな情報をガイド情報として提供するのは差し支えない。
【００１６】
本発明において、ガイド情報には、音声出力すべき情報（以下、「音声ガイド情報」と呼ぶ）を含めても良い。例えば、名所案内などを読み上げたり、店舗やレストランの宣伝を音声出力したりする態様などが挙げられる。また、ユーザに提供可能な情報には、スケジュールと無関係に音声出力する汎用情報を含めても良い。汎用情報としては、例えば、ニュース、天気予報、および広告などが挙げられる。音楽を含めても良い。音声ガイド情報は、名所や店舗などの決まって地点に近づいた時点で出力する必要があるため、その出力タイミングがスケジュールによって制約されるのに対し、汎用情報はスケジュールによる制約を受けずに任意のタイミングで出力可能である。ガイド情報提供システムは、ユーザの現在位置およびスケジュールに基づいてガイド情報の音声出力を開始する時刻までの余裕時間を推測することができる。ガイド情報提供システムは、こうして推測された余裕時間に基づいて、出力すべき汎用情報を選択することが好ましい。一例として、各汎用情報を出力するための所要時間を参照し、上述の余裕時間内に出力を完了できる汎用情報を選択する方法を採ることができる。このような汎用情報が複数存在する場合には、所要時間が長いものを優先してもよい。このようにガイド情報の出力までの余裕時間と、汎用情報の所要時間とを考慮して出力すべき汎用情報を選択することにより、ガイド情報が出力されていない空白の時間を利用して、効率的に汎用情報を提供することが可能となる。
【００１７】
本発明は、先に説明した通り、スタンドアロンで稼働するシステムとして構成してもよいし、サーバとクライアントとをネットワークで接続して構成してもよい。後者の態様では、例えば、サーバには、予め登録されたスケジュールおよび前記情報のユーザにとっての有用性の判断に用いることができる情報を格納したユーザプロファイルを参照し、前記スケジュールおよびユーザプロファイルに関連する情報を、所定の情報源から収集する機能を分担させることができる。ユーザプロファイルとは、例えば、ユーザの趣味、嗜好、家族構成などの情報を格納したデータベースとすることができる。サーバはユーザプロファイルを参照することにより、ユーザの趣味等に関連する範囲に絞って情報収集することができる。
【００１８】
クライアントは、収集された情報の少なくとも一部をサーバから取得し、ガイド情報として提供する機能を分担する。サーバは、十分な情報収集、情報蓄積、情報処理能力を有しているのが通常であるため、上述の構成によれば、これらの能力による制約なく、有用な情報を収集することができる。この態様では、クライアントは、収集された全情報を取得する必要はなく、一部を取得するだけでもよい。先に説明した種々の選択方法によって収集された情報のうち、有効活用し得る情報のみを選択して取得するようにすれば、効率的にガイド情報を提供することが可能となる。本態様では、クライアントは、スケジュール実行に先立って、サーバから情報を取得してもよい。こうすれば、サーバとクライアントとの通信環境に依らず、収集された情報を有効活用することが可能となる。
【００１９】
本発明は、上述した種々の特徴を必ずしも全て備えている必要はなく、一部を省略したり適宜組み合わせたりして構成することができる。本発明は、上述したガイド情報提供システムとして構成する他、コンピュータによってガイド情報を提供するガイド情報提供方法として構成することもできる。また、かかるガイド情報の提供を実現するためのコンピュータプログラムとして構成したり、このコンピュータプログラムの少なくとも一部を記録した記録媒体として構成したりすることもできる。この場合、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。
【図面の簡単な説明】
【００２０】
【図１】実施例としてのガイド情報提供システムの構成を示す説明図である。
【図２】個人プロファイル２０１、マイボックス２０３のデータ構造を示す説明図である。
【図３】ガイド情報提供システムにおける制御処理のフローチャートである。
【図４】スケジュール登録・変更処理のフローチャートである。
【図５】情報収集処理のフローチャートである。
【図６】情報ボックス・メンテナンス処理のフローチャートである。
【図７】スケジュール・ガイド処理時の表示画面例を示す説明図である。
【図８】スケジュール・ガイド処理のフローチャートである。
【図９】ガイド情報提示処理のフローチャートである。
【図１０】汎用情報出力処理のフローチャートである。
【図１１】変形例におけるガイド情報の提供例を示す説明図である。
【図１２】変形例におけるスケジュール・ガイド処理のフローチャートである。
【発明を実施するための形態】
【００２１】
本発明の実施例について以下の順序で説明する。
Ａ．システム構成：
Ｂ．データ構造：
Ｃ．ガイド情報提供の制御処理：
Ｃ１．スケジュール登録・変更処理：
Ｃ２．情報ボックス・メンテナンス処理：
Ｃ３．スケジュール・ガイド処理：
Ｄ．変形例：
【００２２】
Ａ．システム構成：
図１は実施例としてのガイド情報提供システムの構成を示す説明図である。ガイド情報提供システムは、予め登録されたスケジュールに関連する情報を収集し、ユーザがスケジュールを実行する際に、収集した情報の中からユーザが有効活用できる情報を、移動経路とともに提供するシステムである。本明細書では、収集された情報をスケジュール関連情報と呼び、収集された情報のうち、ユーザに提供すべき情報として選択されたものをガイド情報と呼ぶ。
【００２３】
実施例のガイド情報提供システムは、情報提供サーバ２００（以下、単に「サーバ」と呼ぶこともある）と、端末１００［１］、１００［２］とをインターネットＩＮＴで接続して構成される。図中の例では、端末１００［１］は携帯電話であり、端末１００［２］はカーナビゲーション装置である。端末には、この他、ノートＰＣ、ＰＤＡなど携帯可能な種々の装置が利用可能である。以下の説明では、両者を総称して単に端末１００と称する時もある。端末１００には、情報提供サーバ２００から提供されるガイド情報を取得するためにインターネットＩＮＴとの通信機能が要求されるが、スケジュールの実行中に常時、インターネットＩＮＴへのアクセスが常時確保されている必要はない。図の例では、インターネットＩＮＴを適用した例を示したが、インターネットＩＮＴに代えて、イントラネットなどの限定的なネットワークを用いることも可能である。
【００２４】
ガイド情報提供システムは、上述の通り、サーバ２００と端末１００とを中心として構成されるが、この他にもパソコン３００および多数のＷｅｂサーバ４００［１］、４００［２］を含めることができる。パソコン３００は、サーバ２００にスケジュールの登録、およびスケジュールに従って事前に収集された情報の管理を行うための装置である。本実施例では、これらの機能は、サーバ２００から提供されるＷｅｂページによって実現するものとした。従って、上述の機能を実現するためには、パソコン３００はブラウザを搭載していれば足りる。上述の機能は、端末１００でも実現可能である。この意味で、パソコン３００は端末１００の一種と呼ぶこともできるが、スケジュールの登録等の機能は、デスクトップ型のパソコンなど携帯不能な装置でも実現可能であるため、本実施例では端末１００と区別して示した。
【００２５】
Ｗｅｂサーバ４００［１］、４００［２］（以下、両者をＷｅｂサーバ４００と総称することもある。）は、インターネット上のＷｅｂサイトを通じて種々の情報を提供するサーバである。図中では、Ｗｅｂサーバ４００［１］は観光情報を提供し、Ｗｅｂサーバ４００［２］はグルメ情報を提供する例を示した。提供される情報には、これらに限らず、ショッピング情報、行政情報など多種多様な情報が含まれる。Ｗｅｂサーバ４００は、ガイド情報提供システムに特化したサーバである必要はない。ただし、ガイド情報提供システムと提携したサーバとしておけば、より利便性の高いシステムを構築することができる。例えば、Ｗｅｂサーバ４００が情報を規定のフォーマットに従って提供することにより、本システムの情報収集効率を向上させることができる。また、情報の中に固有のパラメータを含み得るようにしておくことで、Ｗｅｂサーバ４００側からガイド情報提供システムにおける情報の利用態様を制御することも可能となる。
【００２６】
図中には、ガイド情報提供システムとしての機能を提供するための情報提供サーバ２００の機能ブロックを併せて示した。本実施例では、これらの機能ブロックは、これらの機能を実現するためのＣＧＩ（Common Gateway Interface）などで構成されたコンピュータプログラムを情報提供サーバ２００にインストールすることによってソフトウェア的に実現される。図中の機能ブロックの少なくとも一部は、ＡＳＩＣなどの回路によって、ハードウェア的に構成することも可能である。
【００２７】
サーバ２００は、図示する４通りのデータベースを備えている。個人プロファイル２０１は、後述する通り、ユーザＩＤ、氏名、生年月日などのユーザ個人の識別情報、ユーザの趣味、嗜好などの情報、および画面や音声出力などに関するカスタマイズの情報を格納する。個人プロファイル２０１の読み出し、書き込みは、プロファイル管理部２４０が制御する。
【００２８】
汎用情報ＤＢ２０２は、ガイド情報提供システムがユーザに提供する汎用情報を格納する。汎用情報とは、スケジュールに無関係に提供可能な情報を言い、ニュース、天気予報、各種の広告などが含まれる。音楽を含めても良い。マイボックス２０３は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ２００が収集した情報（以下、「スケジュール関連情報」と称する）を格納する。マイボックス２０３の内容についても後述する。
【００２９】
地図ＤＢ２０４は、スケジュールに基づいて定まる目的地までの経路の探索や案内に使用されるデータベースであり、道路をノード・リンクの集合で表した道路ネットワークデータと、地図を表示するための描画データとを格納する。本実施例では、サーバ２００は、これらのデータベースを活用しながら、以下に示す各機能ブロックの作用によって、ガイド情報の提供を行う。道路ネットワークデータには、車両で移動する際に活用できる車両用のネットワークデータ、歩行時に活用できる歩行者用のネットワークデータ、交通機関を利用する際に活用できる交通機関用のネットワークデータなどを含めることができる。
【００３０】
通信部２１０は、インターネットＩＮＴを介した情報授受を制御する機能を奏する。情報収集部２５０は、通信部１２０を介して得られた情報を、汎用情報ＤＢ２０２またはマイボックス２０３に格納したり、逆にこれらのデータベースから情報を読み出したりする機能を奏する。一例として、情報収集部２５０は、パソコン３００との間で情報授受を行い、ユーザからの指定に従って、マイボックス内のスケジュールの更新、読み出しなどを行う。また、情報収集部２５０は、Ｗｅｂサーバ４００にアクセスして、汎用情報ＤＢ２０２に格納すべきニュース、広告等の汎用情報を収集したり、マイボックス２０３に格納すべき情報、即ちスケジュール関連情報を収集したりする。
【００３１】
情報提供制御部２３０は、個人プロファイル２０１、汎用情報ＤＢ２０２、マイボックス２０３を参照し、スケジュールの実行中にユーザに提供すべきガイド情報の取捨選択を行う。取捨選択するための処理内容については後述する。情報提供制御部２３０の機能によって、サーバ２００は、ユーザにとって有用性の高い情報を提供することが可能となる。経路案内部２６０は、マイボックス２０３に登録されたスケジュールに従って移動する際の移動経路や、スケジュール関連情報で得られた各地点まで移動するための寄り道経路を探索する。経路探索は、地図ＤＢ２０４の道路ネットワークデータを参照し、ダイクストラ法など周知の方法を適用して実現することができる。経路案内部２６０は、また、スケジュール実行時には、描画データに基づいて地図表示を行うとともに、地図上に移動経路や寄り道経路の表示を行う。
【００３２】
出力データ生成部２２０は、情報提供制御部２３０および経路案内部２６０から提供されるデータに基づいて、端末１００に表示するための表示データを生成する。本実施例では、多種多様な端末１００を利用できるよう、ＨＴＭＬ、ＸＭＬを利用して表示データを生成するものとした。出力データ生成部２２０は、ガイド情報等を提供するための画面の他、スケジュールを登録・管理するための画面、動作を選択するためのメニュー画面など、ガイド情報提供システムに要求される種々の画面の表示データを生成する。
【００３３】
図中に端末１００［１］に備えられる機能ブロックを併せて例示した。端末１００［２］も同様の構成を有している。端末１００では、主制御部１１０の管理下で、図示する各機能ブロックが稼働する。本実施例では、これらの機能ブロックは、端末１００としての機能を実現するためのプログラムによって、ソフトウェア的に構成したが、ハードウェア的に構成してもよい。
【００３４】
通信部１２０は、インターネットＩＮＴを介した情報の授受を制御する。コマンド入力部１３０は、ユーザの操作に応じてメニューの選択、案内の開始、表示すべき情報の選択など種々のコマンドを入力する。表示制御部１５０は、情報提供サーバ２００からのデータに従って画面表示を行う機能を奏する。本実施例では、ブラウザによって提供される。ＧＰＳ（Global Positioning System）１４０は、ユーザの現在位置を検出する。現在位置は、サーバ２００に送信され、ガイド情報や経路案内の表示制御に活用される。
【００３５】
ここで示したのは、ガイド情報提供システムの一例に過ぎない。図１中に示した各機能ブロックは、必ずしも情報提供サーバ２００または端末１００に全て備えられている必要はなく、分散処理によって複数のサーバ等の連携で実現するようにしてもよい。
【００３６】
Ｂ．データ構造：
図２は個人プロファイル２０１、マイボックス２０３のデータ構造を示す説明図である。左側に個人プロファイル２０１の内容を示し、右側にマイボックス２０３の内容を示した。個人プロファイル２０１は、ガイド情報提供システムの利用者を管理するためのデータベースであるとともに、ユーザにとって有用な情報を選択する際に活用できる情報を提供するデータベースともなる。個人プロファイル２０１には、図示する通り、ユーザＩＤ、氏名、生年月日、性別、家族構成などのユーザ個人の識別情報が格納される。図の例では、ユーザＩＤとして「ＵＳＲ００１」が格納されている例を示した。家族構成は、「妻、娘１人、息子１人」という人数構成を格納した例を示したが、各人の年齢や趣味、嗜好などを格納するようにしてもよい。家族構成を詳細にするほど、収集・選択される情報の有用性が向上する。例えば、家族でレジャーに出かける場合のガイド情報を提供する場合、娘が小学生なのか女子高生なのかによって、有用な情報は異なるからである。
【００３７】
個人プロファイル２０１には、ユーザの趣味、嗜好などの情報も格納される。この情報もスケジュール関連情報の収集およびガイド情報の選択に活用される。図示するように、ラーメン好みであるなどの嗜好を把握しておくことにより、レストラン情報を提供する際にはラーメン屋を優先させるなどの態様で、ユーザに有用な情報を提供することが可能となる。趣味についても同様である。図の例では、嗜好および趣味を例示したが、この他、職業、ガイド情報の利用実績など、ガイド情報の収集・選択に活用可能な種々の情報を含めることができる。
【００３８】
個人プロファイル２０１には、更に、オプション情報を格納してもよい。図の例では、情報提供に関するカスタマイズの情報を例示した。画面色とは、情報提供画面の背景色の選択を意味する。音声とは、音声出力時の読み上げ音声の種類（以下、「音声種別」と呼ぶ）を意味する。本実施例では、予め登録された複数種類の音声種別の中からユーザの好みの音声種別を選択する態様を採った。音声に格納された「ＦＶＯＩＣＥ１」は、登録された女性音声の識別コードである。サーバ２００がガイド情報等を音声出力する際には、この音声識別コードを反映した音声出力データを生成し、端末１００に送信すればよい。
【００３９】
マイボックス２０３は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ２００が収集した情報（以下、「スケジュール関連情報」と称する）を格納する。マイボックス２０３と個人プロファイル２０１とは、ユーザＩＤで対応づけられている。スケジュールには、日付、時間帯、場所、スケジュールの内容などが登録される。図の例では、３月１日には、「１３時からＺ社で会議」という予定が入っており、その前の時間帯、１０時〜１３時の間は特に予定がない移動時間となっていることが分かる。また、３月２日の例では、「１１時〜１２時に来客」の予定が入っており、「１２時〜１３時過ぎに昼食」の予定が入っていることが分かる。
【００４０】
情報ボックスには、スケジュール関連情報が登録されている。この情報とスケジュールとは、「関連ＩＤ」で関連づけられる。図中の例で示す情報には、「ＩＮＦＯ１」なる関連ＩＤが付されており、３月１日のスケジュールにおける移動時間に「ＩＮＦＯ１」なる関連ＩＤが付されているため、この情報は３月１日の移動中に活用できる情報であることが分かる。情報ボックスには、多くのスケジュール関連情報が登録される。関連ＩＤは、それぞれの情報に固有としてもよいし、スケジュールの項目に固有としてもよい。例えば、図の例において、３月１日の「移動」に関連するスケジュール関連情報が複数存在する場合を考える。前者の例によれば、これらの全情報には個別の関連ＩＤが付されるため、スケジュールにおける「移動」に対して、複数の関連ＩＤが登録されることになる。後者の例によれば、スケジュール関連情報には、全て「移動」に付された関連ＩＤ「ＩＮＦＯ１」が付されることになる。いずれの態様を採るかは任意に選択可能である。前者の態様を採る場合において、「ＩＮＦＯ１＊＊＊」のように、共通の「ＩＮＦＯ１」を含む形で関連ＩＤを設定することにより、「移動」との対応関係を容易に判断できるようにしてもよい。
【００４１】
それぞれのスケジュール関連情報には、図中に示す種々の情報が格納される。「パス」は、情報の格納先を表している。サーバ２００内のディレクトリやファイル名で表しても良いし、Ｗｅｂサーバ４００に格納された情報のＵＲＬを用いても良い。「優先度」は、ガイド情報として提供する際の優先度を表している。後述する通り、優先度を用いることで、類似の情報が繰り返し提供されることを回避したり、ユーザの嗜好を反映した情報を優先的に提供したりすることが可能となる。「ＮＯＲＭＡＬ」は、通常の優先度を意味している。「優先度」は、優先度の高低を表す数値としても良い。「名称」には、店舗名、名所の名称、地名など、スケジュール関連情報を表す名称が格納される。「場所」は店舗の所在地、名所の所在地など、スケジュール関連情報に関連する地点を表す緯度、経度が格納される。Ｗｅｂサーバ４００を参照して、スケジュール関連情報を収集する場合、住所は特定できても緯度、経度までは特定できないことがある。このような場合には、「場所」は住所で登録可能としてもよい。本実施例では、ガイド情報を提供する際の処理の簡略化を図るため、「場所」は緯度、経度の形式に統一して格納するものとした。緯度、経度が直接、収集できなかった場合には、サーバ２００が住所に基づいて地図ＤＢ２０４を参照し緯度、経度を検索する。
【００４２】
「音声」は音声出力データの出力時の音声識別コードである。個人プロファイル２０１に登録されているのと同様、予めサーバ２００に登録されている音声種別を特定するための情報である。この音声識別コードは、Ｗｅｂサイトで提供される情報に音声識別コードを埋め込まれている場合に格納される。こうすることで、情報の提供者は、自己がＷｅｂサイトを通じて提供する情報の一部に、音声識別コードを埋め込んでおくだけで、ガイド情報提供システムで利用される時の音声種別を制御することが可能となる。例えば、図の例であれば、「○○ラーメン」の店主は、自己の好みの音声で、自己の店舗の宣伝や案内を提供することが可能となるのである。
【００４３】
「所要時間」は、スケジュール関連情報に従って行動する際に必要となる時間余裕を表している。例えば、ラーメン屋の場合には、ラーメンを注文してから食べ終わるまでの時間を所要時間とすることができる。人気の高いラーメン屋の場合には、平均の待ち時間を考慮してもよい。所要時間は、情報の提供者が情報内に埋め込んでおくようにしてもよいし、スケジュール関連情報で与えられる店舗、名所などの種別、人気度等に応じて平均的な値をサーバ２００が設定するようにしてもよい。
【００４４】
「提供履歴」は、スケジュール関連情報が端末１００に提供された履歴を記録する。図の例では、この情報が、２００６年３月１日に、端末１００［１］に提供されたことを示している。提供履歴を参照することにより、サーバ２００は同一の情報が繰り返しユーザに提供されることを回避することができる。提供履歴には、ユーザが、この情報を活用したか否かの履歴を含めるようにしてもよい。
【００４５】
以上で説明したデータ構造は、一例に過ぎない。個人プロファイル２０１およびマイボックス２０３共に、図示した項目全てのデータを格納している必要はなく、一部の項目を省略してもよい。また、図示した項目以外のデータを含めるようにしてもよい。データの格納形式も、図の例に限らず、種々の形式を採り得る。
【００４６】
Ｃ．ガイド情報提供の制御処理：
図３はガイド情報提供システムにおける制御処理のフローチャートである。サーバ２００が実行するメインルーチンに相当する。処理を開始すると、サーバ２００はユーザからのログインを受け付け（ステップＳ１０）、メニュー画面を提示して、ユーザからの指示を入力する（ステップＳ１２）。図中にメニュー画面ＭＥＮＵの例を示した。この例では、「１．スケジュール登録・変更」、「２．情報ボックス・メンテナンス」、「３．スケジュール・ガイド」、「４．個人プロファイル管理」の４通りのメニューを設けた。サーバは、ユーザからの選択指示に応じて（ステップＳ１４）、それぞれのメニューに対応した処理を実行する。
【００４７】
「１．スケジュール登録・変更」が選択された場合には、サーバ２００は、スケジュール登録・変更処理を行う（ステップＳ１００）。これは、マイボックス２０３にスケジュールを登録したり、登録済みのスケジュールを変更したりするための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。スケジュール登録・変更処理の内容については後で詳述する。
【００４８】
「２．情報ボックス・メンテナンス」が選択された場合には、サーバ２００は、情報ボックス・メンテナンス処理を行う（ステップＳ２００）。これは、マイボックス２０３に蓄積されたスケジュール関連情報の追加、変更、削除を行うための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。スケジュール登録・変更処理の内容については後で詳述する。
【００４９】
「３．スケジュール・ガイド」が選択された場合には、サーバ２００は、スケジュール・ガイド処理を行う（ステップＳ３００）。これは、スケジュールの実行時に、スケジュールに従った移動経路の案内や、ガイド情報の提供を行うための処理である。ユーザが移動している状態での案内、情報提供を行う処理であるため、携帯性のある端末１００を利用することになる。
【００５０】
「４．個人プロファイル管理」が選択された場合には、サーバ２００は、個人プロファイル管理処理を行う（ステップＳ４００）。これは、個人プロファイル２０１の登録、変更、削除を行うための処理である。端末１００およびパソコン３００のいずれを利用することも可能であるが、パソコン３００を利用する方が操作性の面で好ましい。この処理では、サーバ２００は、個人プロファイル２０１の内容（図２参照）を、ユーザのパソコン３００等に表示し、ユーザが各項目を入力すると、その内容で個人プロファイル２０１を更新する。
【００５１】
Ｃ１．スケジュール登録・変更処理：
図４はスケジュール登録・変更処理のフローチャートである。メインルーチン（図３）のステップＳ１００に相当する処理である。先に説明した通り、この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。
【００５２】
この処理を開始すると、サーバ２００は、マイボックス２０３から既存のスケジュールを読み込む（ステップＳ１０２）。スケジュールが未登録の場合には、実質的に何も読み込まれないまま、ステップＳ１０２の処理を終えることになる。そして、サーバ２００は、読み込んだスケジュールをパソコン３００の画面に表示し、ユーザの操作に基づいてスケジュールの編集コマンドを入力する（ステップＳ１０４）。
【００５３】
図中にスケジュールの編集画面の例を示した。パソコン３００には、指定された日のスケジュール画面Ｗ１が表示される。既に登録済みのスケジュールは、この画面Ｗ１に表示される。図中の例では、「１３時からＺ社で会議」という予定が登録済みである。ユーザがパソコン３００のマウスまたはキーボードを操作して、画面Ｗ１内でいずれかの時間帯を指定すると、スケジュールを入力するためのサブウィンドウＷ２が表示される。既に予定を登録済みの時間帯をクリックした場合には、サブウィンドウＷ２には、登録済みの予定内容が表示される。ユーザは、このサブウィンドウを利用して、日時、タイトル、場所、メンバー、その他のメモなどを登録することができる。また、スケジュール関連情報の収集を行うか否か（ＯＮ／ＯＦＦ）を切り換えることができる。情報収集をＯＮとすると、サーバ２００によって、スケジュールとスケジュール関連情報とを対応づける関連ＩＤが割り振られる。図中の例は、関連ＩＤとして「ＩＮＦＯ１」が割り当てられた状態を示している。スケジュールの編集は、図示した画面に限らず、周知の種々の編集画面を利用することが可能である。
【００５４】
図では、スケジュール関連情報の収集を行うか否かをユーザが指定する例を示した。情報収集のＯＮ／ＯＦＦの指定は不要としてもよい。例えば、サーバ２００は、予定が登録された場合に、その直前の空き時間に対して、自動的に情報収集をＯＮに設定するようにしてもよい。また、このような設定をするまでなく、全時間帯について情報収集を行うようにしてもよい。例えば、予定が登録されている時間帯については、その予定に対応した情報を収集し、空き時間については次の予定までの移動中で有効活用できる情報を収集すればよい。
【００５５】
スケジュールの編集が完了すると、サーバ２００は編集結果をマイボックス２０３に格納して、スケジュールを更新する（ステップＳ１０６）。そして、情報収集処理、即ちスケジュール関連情報を収集するための処理を実行する（ステップＳ１１０）。
【００５６】
図５は情報収集処理のフローチャートである。この処理では、サーバ２００はマイボックス２０３からスケジュールを読み込み、情報収集の対象となるべき予定、即ち対象スケジュールを抽出する（ステップＳ１１２）。本実施例では、先に説明した通り、情報収集が「ＯＮ」に設定された予定を抽出することになる。
【００５７】
サーバ２００は、この対象スケジュールに対して、直前のスケジュールの場所を開始時位置として設定し、対象スケジュールの直後の場所を終了時位置に設定する（ステップＳ１１４）。そして、開始時位置から終了時位置までの経路探索を行う（ステップＳ１１６）。経路探索は、地図ＤＢ２０４の道路ネットワークデータを参照して行うことができる。ここでは、対象スケジュール前後の予定が与えられているため、この予定に支障がない移動方法を探索する必要がある。つまり、直前の予定の終了時刻に開始時位置を出発し、直後の予定の開始時刻には終了時位置に到達していなくてはならない。このような経路は、所要時間最短という条件で探索すればよい。ダイクストラ法を用いる場合には、各リンクの通過所要時間を反映したコストが最小となるよう、経路探索を行えばよい。経路探索には、種々の条件を考慮することができ、例えば、車両、徒歩、交通機関利用時など、移動手段を多様に変化させて、それぞれの経路を求めても良い。徒歩の時には、坂道や階段に高いコスト値を付すことによって、坂道や階段を避ける経路を探索してもよい。同様に、ユーザの要望をコストに反映させることで、種々の要望を考慮した経路探索を行うことが可能である。
【００５８】
本実施例では、対象スケジュールが移動不能な予定の場合もある。例えば、「会議」という予定に対して、スケジュール関連情報の収集がＯＮとなっている場合が該当する。このように移動不能な予定に対しては、ステップＳ１１６の処理は省略してもよい。
【００５９】
サーバ２００は、次に、個人プロファイル２０１から、ユーザの嗜好および趣味に関するデータを読み込む（ステップＳ１１８）。そして、以上で取り込んだ情報に基づいてＷｅｂサーバから情報を収集する（ステップＳ１２０）。この情報収集は、ユーザに有用な情報を提供することが目的であるから、次の条件で行う。まず、ユーザの嗜好、趣味に合致または類似する情報であることが条件となる。例えば、ユーザが「ラーメン好き」という嗜好を有している場合には、合致する情報として「ラーメン屋」の案内情報を収集すればよい。また、類似する情報として、「中華料理屋」や、そば屋、うどん屋などの麺類の店の案内情報を収集すればよい。趣味についても同様である。情報収集時には、スケジュールに同行するメンバー構成を考慮してもよい。例えば、家族でのレジャーの場合には、家族構成や家族のメンバーの嗜好、趣味等を考慮することができる。出張の場合には、会社の同僚の嗜好、趣味等を考慮することもできる。
【００６０】
第２の条件は、直後の予定に間に合う場所的範囲で情報収集を行うことである。例えば、いくら人気のあるラーメン屋に関する情報であっても、次の予定に間に合わないほど遠くにある店についての情報では活用できないからである。この条件は、種々の方法で判断することができる。例えば、ステップＳ１１６で探索した経路から所定距離内の場所についての情報というように簡易な方法で判断するようにしてもよい。この場合の「所定距離」は、次の予定までの余裕時間、次の目的地までの距離、ユーザの移動速度を考慮して設定することができる。また、別の態様として、スケジュール関連情報に対応した場所を経由地としてステップＳ１１６の経路探索を行い、直後の予定に間に合うか否かを判断するようにしてもよい。
【００６１】
以上の条件に合致する情報が得られると、サーバ２００は、その情報に、対象スケジュールに付された関連ＩＤを付して、情報ボックスに格納する（ステップＳ１２２）。サーバ２００は、情報収集処理を適宜、繰り返し実行することで、関連ＩＤが付された全スケジュールについてスケジュール関連情報を収集するとともに、それぞれの予定について、できるだけ多くのスケジュール関連情報を収集するよう努める。情報収集処理は、例えば、全スケジュールについて一定数までの情報が収集されるまで繰り返し実行するようにしてもよい。
【００６２】
以上の説明では、スケジュールの登録・変更がなされた時に情報収集処理を行う場合を示した。情報収集処理は、この他のタイミングにも実行可能である。例えば、スケジュールが実行されるまでの間、スケジュールの登録・変更が行われるか否かとは無関係に定期的に実行してもよい。このように繰り返し実行することにより、より多くの情報、かつより新しい情報を収集することが可能となる。
【００６３】
Ｃ２．情報ボックス・メンテナンス処理：
図６は情報ボックス・メンテナンス処理のフローチャートである。メインルーチンのステップＳ２００に相当する処理である。この処理は、サーバ２００が収集したスケジュール関連情報を、スケジュールの実行前にユーザが確認し、不要な情報を削除するための処理である。先に説明した通り、この処理では、端末１００を利用することも可能ではあるが、以下では説明の便宜上、パソコン３００を利用するものとして説明する。
【００６４】
処理を開始すると、サーバ２００はユーザからスケジュール関連情報を表示する対象となる予定、即ち対象スケジュールの指定を受け付ける（ステップＳ２０２）。ユーザがパソコン３００で、対象スケジュールを指定すると、サーバ２００はマイボックス２０３の情報ボックスを参照して、対象スケジュールに割り振られた関連ＩＤが付された情報を読み込む（ステップＳ２０４）。
【００６５】
サーバ２００は、読み込んだ結果をパソコン３００に表示し、スケジュール関連情報の編集を受け付ける（ステップＳ２０６）。図中にパソコン３００に表示される編集画面例を示した。この例では、画面の左側に矢印で示すように、地図上にスケジュールに従った移動経路が表示される。そして、スケジュール関連情報の項目が、右下に表示され、地図上には、この項目に対応する場所が表示される。図中の例では、スケジュール関連情報として、情報ａ「○○ラーメン」、情報ｂ「△△チャンポン」、情報ｃ「＊＊うどん」が得られている。左側の地図では、ａ〜ｃの符号で、それぞれの情報に対応する店舗の位置が表示される。ここでは、店舗の例を示したが、名所等についても同様である。また、右上には登録されているスケジュールが表示される。
【００６６】
図示した編集画面では、上述の通り、ユーザは地図によってスケジュール関連情報に対応する地点（以下、「設定場所」という）と移動経路との位置関係を把握することができ、同時に、右上のスケジュール画面によって次の予定までの時間余裕を把握することができる。更に、右下の画面で各項目をクリックすると、詳細な情報が表示されるようにしてもよい。ユーザは、これらの情報を一覧して、スケジュール関連情報の要否を判断する。例えば、情報ａ「○○ラーメン」は店の場所が遠いため不要と判断した場合には、画面の右下のエリアで、情報ａのチェックボックスをチェックし、「削除」ボタンをクリックすればよい。
【００６７】
サーバ２００は、編集結果を入力すると、それに応じて情報ボックスの内容を更新し（ステップＳ２０８）、情報ボックス・メンテナンス処理を終了する。実施例では、情報を削除する方法を例示したが、更に、ユーザ自身が収集した情報を追加可能としてもよい。例えば、ステップＳ２０６中に示した編集画面に、ユーザが情報のパスまたはＵＲＬを入力可能とし、ステップＳ２０８では、サーバ２００がこれに従って、情報を取得して情報ボックスに格納するようにすればよい。
【００６８】
Ｃ３．スケジュール・ガイド処理：
ユーザはスケジュールの実行時になると、メニュー画面ＭＥＮＵ（図３参照）でスケジュール・ガイドを指示する。サーバ２００は、この指示に応じて、端末１００に対して、ユーザがスケジュールを実行する際の支援情報、つまり目的地までの経路その他の有用な情報を提供する。以下では、まず端末１００の表示画面例によって、スケジュール・ガイド処理における具体的な処理内容を説明した後、この処理を実現するためのフローチャートを示す。
【００６９】
先に説明した通り、スケジュールを開始する時点で、サーバ２００には、スケジュール・ガイドに必要な情報は一通り蓄積されている。従って、ユーザは端末１００にこれらの情報を一括ダウンロードしておくことにより、サーバ２００との通信を行わずにスケジュール・ガイド処理を実行させることも可能である。ただし、以下では、端末１００はサーバ２００と適宜、通信可能な環境にあることを前提として説明する。スケジュール・ガイド中にサーバ２００と通信することによって、ユーザの現状に応じて、提供する情報の内容を柔軟に変更できる利点があるからである。
【００７０】
図７はスケジュール・ガイド処理時の表示画面例を示す説明図である。図７（ａ）は、次の目的地に向かって移動中の画面を表している。この画面では、左側に地図および移動経路が表示され、右上にスケジュール、右下にガイド情報が提示される。本実施例では、情報ボックス・メンテナンス処理（図６）時の画面と類似の画面構成を採用した。ただし、情報ボックス・メンテナンス処理では、右下に、スケジュール関連情報の一覧が表示されるのに対し、スケジュール・ガイド処理では、いずれか選択された情報が提示される点で相違する。以下、スケジュール関連情報のうち、ユーザに提示するよう選択された情報を「ガイド情報」と称する。
【００７１】
図７（ａ）中の点ＰＰはユーザの現在位置を表している。実線の矢印は次の予定の目的地に至るまでの移動経路を表している。図中のハッチングを付した地点ａ，ｂ，ｃは、現在位置付近のスケジュール関連情報の所在地を表している。サーバ２００は、この中から、現在位置ＰＰに最も近い地点ｃを選択し、ガイド情報として、画面の右下に詳細な情報を表示する。また、左側の地図上には破線矢印で示すように現在位置ＰＰから地点ｃに至るまでの寄り道経路を表示する。ユーザは、この表示画面により、移動経路、寄り道経路、スケジュールおよびガイド情報の内容を一覧することができる。ユーザは、これらの情報を総合的に考慮して、ガイド情報で提供された地点ｃを訪問するか否かを決定できる。
【００７２】
図７（ｂ）は、ユーザが地点ｃを訪問すると決めた時の表示画面例である。本実施例では、ユーザが寄り道経路に沿って一定の距離または一定の時間、進行を開始したところで、サーバ２００は、ユーザが地点ｃを訪問するつもりであると判断して図７（ｂ）の画面を表示する。ユーザの移動状況に応じて判断する方法に代えて、またはこのような判断方法と共に、ユーザが端末１００を操作して、地点ｃを訪問する旨をサーバ２００に指示する態様をとってもよい。図７（ｂ）の画面では、図中に実線矢印で示すように、寄り道経路が表示される。従前の移動経路は消え、地点ｃに訪問した後、目的地に向かう経路が再探索されて表示される。端末１００がサーバ２００と通信できない環境にある場合には、経路の再探索をできないため、従前の移動経路をそのまま継続して表示してもよい。
【００７３】
図の例では、スケジュール関連情報ａ〜ｃは「麺類のお店」など、共通のジャンルの情報であるとする。サーバ２００は、ユーザが地点ｃを訪問すると決めた時点で、更に、類似の情報をガイド情報として提供する必要性はないと判断する。従って、共通のジャンルの情報である情報ａ，ｃの提供を停止する。この結果、図７（ｂ）の実施例では、地点ａ，ｂはハッチングを削除した状態での表示に切り替わる。ユーザが地点ｃに到達するまで待ってから切り換えるようにしてもよい。また、ユーザが地点ｃに進行を開始した時点で、一旦、削除した後、地点ｃの訪問を中断した時点で、再度、ハッチング表示を復活させてもよい。
【００７４】
図７（ｃ）は、ユーザが地点ｃを訪問しない場合の表示画面例である。本実施例では、ユーザが寄り道経路を採らず、移動経路に沿って一定の距離または一定の時間、進行を開始したところで、サーバ２００は、ユーザが地点ｃを訪問しないつもりであると判断して、図７（ｃ）の画面を表示する。この画面では、地点ｃへの寄り道経路は消され、地点ｃはハッチング無しの表示に切り替わる。また、ガイド情報欄の表示も削除される。地点ａ，ｂはそのままハッチングを付した状態で表示される。ただし、現在位置ＰＰは地点ａ，ｂからは、まだ通りため、寄り道経路もガイド情報も提示されていない状況である。
【００７５】
このように、スケジュール・ガイド処理では、サーバ２００は、ユーザの現在位置に応じて、ガイド情報を提示するとともに、ユーザの進行状況に応じて、提示したガイド情報の採否を判断して、ガイド情報を切り換える。こうすることにより、ユーザに煩雑な操作を要求するまでなく、有用な情報を提供することが可能となる。
【００７６】
図８はスケジュール・ガイド処理のフローチャートである。メインルーチンのステップＳ３００に相当する処理である。この処理を開始すると、サーバ２００は、スケジュールデータおよび経路探索結果を読み込む（ステップＳ３０２）。そして、ユーザの現在位置および現在時刻を入力し（ステップＳ３０４）、現在実行中の予定が対象スケジュールであるか否かを判断する（ステップＳ３０６）。対象スケジュールを実行している場合には、サーバ２００は、ガイド情報提示処理および汎用情報出力処理を実行する（ステップＳ３１０、Ｓ３３０）。ガイド情報提示処理とは、マイボックスに蓄積されていたスケジュール関連情報の中から、ユーザに提供すべきガイド情報を選択する処理である。汎用情報出力処理とは、ニュース、広告などの汎用情報の中から、出力すべきガイド情報がない空白の時間帯を利用して出力すべき汎用情報を選択する処理である（ステップＳ３３０）。各処理の内容は後で示す。対象スケジュールの実行中でない場合には（ステップＳ３０６）、サーバ２００は、ガイド情報提示処理および汎用情報出力処理はスキップして、次の処理に移行する。
【００７７】
以上の処理に基づき、サーバ２００は、また、端末１００に移動経路の案内を行うとともに、ガイド情報、汎用情報の出力を行う（ステップＳ３５０）。経路案内は、図７に示した様に、端末１００の画面に地図、現在位置、移動経路を提示することで行う。ガイド情報は、図７に示したように、地図上でガイド情報に対応する地点を表示し、その地点に至るまでの寄り道経路を表示するとともに、画面右下にガイド情報の内容を表示する。汎用情報は、画面右下のガイド情報のエリアに表示させることができる。また、ガイド情報、汎用情報に音声データが含まれている場合には、サーバ２００は、その音声出力も行う。音声出力は、ユーザが個人プロファイル２０１で指定した音声種別（図２参照）または情報提供者がＷｅｂサイトを通じて指定した音声種別を使用する。後者を前者よりも優先することが好ましい。サーバ２００は、以上の処理を、ユーザがスケジュールを完了するまで、またはユーザがスケジュール・ガイド処理の終了を指示するまで（ステップＳ３５２）、繰り返し実行する。
【００７８】
図９はガイド情報提示処理のフローチャートである。スケジュール・ガイド処理のステップＳ３１０に相当する処理である。この処理では、サーバ２００は、スケジュール関連情報に対応する地点（以下、「設定場所」と呼ぶ）が現在位置に最も近いガイド情報を情報ボックスから抽出する（ステップＳ３１１）。ガイド情報の抽出時には、現在位置との距離関係の他、種々の要素を考慮してもよい。例えば、先に図２で示した通り、本実施例では、スケジュール関連情報には、提示履歴が記録されている。ステップＳ３１１では、サーバ２００は、提示履歴を参照し、ユーザに未提示の情報の中からガイド情報を選択してもよい。こうすることにより、例えば、スケジュール・ガイド処理の途中でユーザが利用する端末を変更した場合でも、提示済みの情報が繰り返し提示されることを回避することができる。
【００７９】
別の態様として、ユーザの嗜好や趣味を考慮してもよい。こうすることで、現在位置の近傍に、複数のスケジュール関連情報が収集されている場合には、ユーザの嗜好や趣味により合致する情報を優先的に選択することができる。ユーザのみならず同行者の趣味や嗜好を考慮してもよい。また、時間帯や次の予定の内容を考慮してもよい。例えば、食事の時間帯からずれている時はレストランの情報を除いてガイド情報を選択することが好ましく、食事の時間帯の場合には逆にレストラン情報を優先的に選択することが好ましい。次の予定が仕事の場合には、居酒屋よりも喫茶店の情報を優先的に案内するなどの態様を採ってもよい。
【００８０】
次に、サーバ２００は、現在位置から設定場所まで至る寄り道経路を探索する（ステップＳ３１２）。また、スケジュールデータを参照して、現在時刻から次の予定までの余裕時間を求め、ガイド情報に登録された所要時間（図２参照）が許容範囲か否かを判断する（ステップＳ３１３）。この判断においては、登録されている所要時間の他に、設定地点までの移動に要する時間を考慮する必要がある。つまり、「所要時間＜余裕時間−移動時間」という関係にあることが必要である。移動時間は、種々の方法で推定することができる。例えば、現在地点から設定地点までの距離、または移動経路から設定地点までの距離に応じて、移動時間を推定してもよい。ステップＳ３１２で求めた寄り道経路と、ユーザの移動速度に基づいて、移動時間を求めてもよい。
【００８１】
所要時間が許容範囲であると判断された場合（ステップＳ３１３）、サーバ２００は、次に、ユーザの現在位置と、移動経路、寄り道経路との位置関係を判定する（ステップＳ３１４）。この時点で抽出されたガイド情報がユーザに提示されることは確定したことになるから、サーバ２００はガイド情報の提示履歴に、提示時刻や情報を提示した端末の情報などを記録する。
【００８２】
ガイド情報が提示された当初は、移動経路、寄り道経路の分岐に至っていない場合がある。このような場合、即ち現在位置が移動経路上、寄り道経路上のいずれにも該当する場合には、提示されたガイド情報をユーザが利用しようとしているのか否かをサーバ２００は判断できないため、そのままガイド情報提示処理を終了する。この場合、寄り道経路のデータは削除されてはいないから、案内画面には、移動経路、寄り道経路の双方が表示される（図８のステップＳ３５０）。
【００８３】
これに対し、現在位置が移動経路上にはなく、寄り道経路上にいる場合には、図７（ｂ）で説明した通り、ユーザは提示されたガイド情報に従って、移動しようとしていると判断される。従って、サーバ２００は、移動経路のリルート処理を行う（ステップＳ３１５）。つまり、ガイド情報で示した設定地点から、次の予定の目的地までの経路を探索し、これを従前の移動経路に代えてユーザに提示する。ユーザが設定場所をまだ訪問していない場合には（ステップＳ３１６）、ガイド情報提示処理を終了する。これに対し、ユーザが設定場所を訪問した後は（ステップＳ３１６）、設定場所と同一ジャンルのガイド情報を削除する（ステップＳ３１７）。これによって、図７（ｂ）において地点ａ，ｂがハッチング無しの表示に切り替わったように、同一ジャンルの情報が繰り返しユーザに提供されることを回避できる。同一ジャンルの情報であっても、繰り返し欲するユーザがいることも考慮して、ステップＳ３１７の処理をユーザの指定等に応じて省略可能としてもよい。
【００８４】
現在位置が寄り道上にない場合には（ステップＳ３１４）、サーバ２００は、寄り道経路に対応したガイド情報は不要と判断し、このガイド情報を削除する（ステップＳ３１８）。この結果、先に図７（ｃ）に示したように、ガイド情報の設定場所である地点ｃは、ハッチング無しの表示、即ちガイド情報と無関係の地点の表示に切り替えられる。また、この地点に対する寄り道経路も消去される。ステップＳ３１３で、所要時間が許容範囲を超えていると判断された場合も、サーバ２００は上記処理を行う（ステップＳ３１８）。
【００８５】
実施例のガイド情報提示処理では、ステップＳ３１７、Ｓ３１８において、ガイド情報を削除する例を示した。ガイド情報は、情報ボックスから完全に削除するようにしてもよいし、情報ボックスの「優先度」のデータを、「削除」に書き換える方法を採っても良い。後者の場合には、サーバ２００は、「削除」が付された情報を除いてガイド情報を抽出すればよい。後者の態様では、ガイド情報は見かけ上、削除されるものの、「優先度」のデータを書き換えることにより、容易に再度、利用可能となる利点がある。また、ガイド情報等の削除に代えて、ガイド情報の優先度を低下させる処理を行ってもよい。この場合、例えば、サーバ２００は、優先度の高い情報からユーザに提供すべきガイド情報が得られなかった場合にのみ、優先度の低いガイド情報を提供すればよい。
【００８６】
図１０は汎用情報出力処理のフローチャートである。スケジュール・ガイド処理のステップＳ３３０に相当する処理である。ここでは、汎用情報は音声出力を伴うものであるとする。サーバ２００は、まず、音声情報を出力中であるか否かを判断する（ステップＳ３３１）。音声情報出力中には、更に音声を伴う汎用情報を出力する必要性、可能性はないからである。音声情報は、ガイド情報、汎用情報いずれであってもよい。
【００８７】
音声情報を出力していない場合には（ステップＳ３３１）、サーバ２００は、汎用情報ＤＢ２０２から情報リストを取得する（ステップＳ３３２）。図中に情報リストの例を示した。この例では、ニュース１、ニュース２、広告１等が登録されており、それぞれの音声出力の所要時間が記録されている。
【００８８】
次に、サーバ２００は、音声データを含むガイド情報を情報ボックスから抽出する（ステップＳ３３３）。そして、現在位置、ガイド情報の設定場所、移動速度に基づいて、ガイド情報の音声データを出力するまでの余裕時間を推定する（ステップＳ３３４）。ガイド情報の設定場所が移動経路上にある時には、まず、現在位置から設定場所までの距離を求め、これを移動速度で除することによって、音声出力までの余裕時間を求めることができる。ガイド情報の設定場所が移動経路からそれている時には、移動経路上で設定場所に最も近い地点を求め、現在位置からこの地点までの距離に基づいて余裕時間を求めればよい。ガイド情報を出力すべき地点を予め移動経路上に設定しておいてもよい。
【００８９】
サーバ２００は、このようにして求められた余裕時間に基づき、次の条件に従って、音声出力すべき汎用情報を選択する（ステップＳ３３５）。条件１により、サーバ２００は、ユーザへの提供回数が最小の情報を優先する。汎用情報は、ニュース、広告等の情報なので、ユーザに何度も繰り返し提供しても差し支えない。ただし、汎用情報は、提供回数の偏りなく平均して提供されることが好ましい。ユーザへの提供回数が最小の情報を優先的に選択するようにすれば、汎用情報を提供する際の偏りを抑制することが可能となる。条件１によれば、例えば、ニュース１の提供回数が０回、ニュース２、広告１の提供回数が１回以上の場合には、ニュース１が優先されることになる。全汎用情報の提供回数が同一である場合には、回数による優劣なく、他の条件に従って情報の選択が行われる。
【００９０】
条件２により、サーバ２００は、汎用情報の音声出力時間が、余裕時間以下となる情報を選択する。こうすることにより、汎用情報の末尾が切れるなどの支障なく、ガイド情報の音声出力が始まるまでの空白時間内でおさまるように、汎用情報を出力することができる。条件２は、情報を選択する際に、必須の条件として扱っても良いし、単に選択の優先度を決定する条件として扱っても良い。後者の例によれば、余裕時間内に収まる汎用情報がない場合には、条件２を考慮に入れずに汎用情報の選択が行われることとなり、この結果、末尾が切れて汎用情報が出力されることになる。
【００９１】
条件３により、サーバ２００は、条件１、２を満たす中で音声出力時間が最長のものを選択する。つまり、条件３は、条件１、２に該当する出力情報が複数存在する場合に適用される絞り込み条件である。最長のものを選択するのは、一般に出力時間が長いものほど、余裕時間内で出力できる可能性が低い点を考慮したものである。この条件で選択することにより、音声出力時間が長い汎用情報の出力回数が少なくなるのを緩和することができる。
【００９２】
汎用情報を選択するための条件１〜３は、上述の例に限らず、種々の設定が可能である。上述した条件の一部を省略してもよいし、この他の条件を加えても良い。
【００９３】
以上で説明した実施例のガイド情報提供システムによれば、スケジュールを登録すると、そのスケジュールに関連した情報をサーバ２００が自動的に収集するため、ユーザによる情報収集の負荷を軽減することができる。また、スケジュール実行中の情報収集に比較し、情報の収集に対する時間的な制約が少ないため、サーバ２００は有用かつ最新の情報を広範囲に収集することができる利点もある。この過程において、ガイド情報提供システムは、スケジュールによる時間的制約の範囲内でユーザが活用可能な情報を収集するため、活用できない無用な情報をユーザに提供することが回避され、有用な情報を効率的に提供することが可能となる。更に、実施例のガイド情報提供システムは、こうして収集された情報の中から、ユーザの現在位置に応じて、ユーザに有用性の高い情報を選択して提供することも可能であり、情報の有効活用を促進することができる。
【００９４】
Ｄ．変形例：
実施例では、スケジュールの実行前に収集した情報を活用する例を示した。ガイド情報提供システムは、スケジュール・ガイド処理の過程で、情報収集を並行して行うようにしてもよい。以下では、変形例として、情報収集を並行して行う場合の処理例を示す。
【００９５】
図１１は変形例におけるガイド情報の提供例を示す説明図である。ユーザが車両で移動する場合を例示した。車両に搭載されたカーナビゲーション装置が端末１００として機能する。
【００９６】
図の例では、Ａ地点からＥ地点に移動するスケジュールがサーバ２００に登録されているものとする。サーバ２００は、このスケジュールに従って、ガイド情報Ｃおよびガイド情報Ｄを取得する。この例では、ガイド情報Ｄは四季に応じて４通り用意されている場合を例示した。このような場合、サーバ２００は、全季節の情報を取得してもよいし、スケジュールに該当する季節の情報のみを取得してもよい。ガイド情報Ｃ、Ｄは、それぞれ移動経路から若干、離れた名所等の情報である。変形例では、これらの情報を、移動経路上の地点Ｃ、Ｄに対応づけて格納しておくものとした。こうすることにより、ユーザが地点Ｃ、Ｄに到達した時点で、ガイド情報Ｃ、Ｄを流せば良いため、ガイド情報を提供するタイミングを比較的容易に決定できる利点がある。このように情報を提供する場所としてガイド情報に対応づけられている地点を以下では「情報提供位置」と呼ぶ。
【００９７】
ユーザは、出発する際に、サーバ２００に収集されている情報をダウンロードする。端末１００としてのカーナビゲーション装置は、この情報に基づいて経路案内をするとともに、ユーザがＣ地点、Ｄ地点に到達すると、収集されていたガイド情報をユーザに提供する。端末１００は、この他、リアルタイム情報も随時、取得する。リアルタイム情報とは、スケジュール実行時に入手してこそ意味のある情報である。図の例では、区間Ｂの渋滞情報を取得する例を示した。端末１００は、取得したリアルタイム情報を適宜、ユーザに提供する。
【００９８】
図１２は変形例におけるスケジュール・ガイド処理のフローチャートである。端末１００が実行する処理である。この処理を開始すると、端末１００は、スケジュールデータ、経路探索結果、ガイド情報をサーバ２００からダウンロードする（ステップＳ５００）。そして、現在位置、時刻を入力し（ステップＳ５０２）、リアルタイム情報を取得する（ステップＳ５０４）。リアルタイム情報の取得タイミングは、図示した例に限らず、種々のタイミングを採り得る。
【００９９】
そして、端末１００は、情報提供位置に到達している場合には（ステップＳ５０６）、ガイド情報およびリアルタイム情報を提供する（ステップＳ５０８）。リアルタイム情報の場合には、取得した時点で提供するようにしてもよい。端末１００は、以上の処理を、目的地に到達するまで繰り返し実行する（ステップＳ５１０）。
【０１００】
変形例のスケジュール・ガイド処理によれば、サーバ２００が予め収集したガイド情報と、リアルタイム情報とを併用することができる。事前に収集したガイド情報については、一括ダウンロードされているため、端末１００がサーバ２００と通信不能であっても、支障なくユーザに提供することが可能である。一方、渋滞情報のようにスケジュール実行時にしか分からない情報はリアルタイム情報として取得することにより、事前に収集しておくことができない情報を補うことができ、さらに有用性の高い情報をユーザに提供することが可能となる。また、通信するのはリアルタイム情報のみで済むため、通信負荷が軽くなるという利点もある。
【０１０１】
変形例では、サーバ２００が収集した情報を出発時にダウンロードする例を示したが、実施例と同様、移動中にサーバ２００から適宜、ガイド情報を取得する構成を採ることも可能である。かかる構成を採る場合には、リアルタイム情報もサーバ２００が取得した上で、端末１００に提供してもよい。このようにサーバ２００を経由する構成では、サーバ２００で情報の要否を判定できるため、端末１００で処理する場合よりも複雑な処理を適用可能であり、より有用性の高い情報を効率的にユーザに提供することが可能となる利点がある。
【０１０２】
また、変形例のように、カーナビゲーション装置を端末として用いる場合など、端末が十分な記憶容量、処理速度を有する場合には、端末に地図ＤＢ、経路案内部、情報提供制御部を備えてもよい。こうすることにより、サーバとの通信負荷を軽減することができるメリットがある。
【０１０３】
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。
【符号の説明】
【０１０４】
１００・・・端末、１１０・・・主制御部、１２０・・・通信部、１３０・・・コマンド入力部、１４０・・・ＧＰＳ、１５０・・・表示制御部、２００・・・情報提供サーバ、２０１・・・個人プロファイル、２０２・・・汎用情報ＤＢ、２０３・・・マイボックス、２０４・・・地図ＤＢ、２２０・・・出力データ生成部、２３０・・・情報提供制御部、２４０・・・プロファイル管理部、２５０・・・情報収集部、２６０・・・経路案内部、３００・・・パソコン、４００・・・Ｗｅｂサーバ。
【図１】
2011081840.tif 000003
【図２】
2011081840.tif 000004
【図３】
2011081840.tif 000005
【図４】
2011081840.tif 000006
【図５】
2011081840.tif 000007
【図６】
2011081840.tif 000008
【図７】
2011081840.tif 000009
【図８】
2011081840.tif 000010
【図９】
2011081840.tif 000011
【図１０】
2011081840.tif 000012
【図１１】
2011081840.tif 000013
【図１２】
2011081840.tif 000014
【手続補正書】
【提出日】平成23年2月7日(2011.2.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
情報提供サーバと、情報提供サーバと通信可能に接続された端末とから成り、
予め登録されたスケジュールに関連する情報を収集し、ユーザがスケジュールを実行する際に、前記収集した情報から当該ユーザに対して、移動経路と共にガイド情報として提供するガイド情報提供システムであって、
情報提供サーバは、ユーザのスケジュールを蓄積するスケジュール蓄積手段から対象スケジュールを抽出する手段と、
対象スケジュールの直前のスケジュールの終了時の場所を開始時位置として設定する手段と、前記対象スケジュールの直後の場所を終了時位置に設定する手段と、開始時位置から前記終了時位置までの経路探索を行う手段と、
ユーザにスケジュールに関連した情報としてスケジュールに割り振って提供するスケジュール関連情報を収集する手段と、収集したスケジュール関連情報を前記経路探索の結果得られた経路に関連付けて蓄積するスケジュール関連情報蓄積手段と、を有し、
前記端末は、対象スケジュールを指定する手段と、前記サーバから前記スケジュール関連情報から指定された対象スケジュールに割り振られたガイド情報を読み込む手段と、読み込んだガイド情報に対応する場所を、スケジュールに基づく前記経路探索により得られた経路上に表示する手段と、を有することを特徴とするガイド情報提供システム。
【請求項２】
請求項１に記載されたガイド情報システムにおいて、
前記情報提供サーバは、ユーザの嗜好又は趣味に関する情報を蓄積する手段からユーザの嗜好又は趣味に関する情報を読み込む手段と、読み込んだ前記情報に基づき情報提供サーバから前記情報の関連情報を収集する手段と、を有し、収集した関連情報を前記スケジュールに割り振りかつ前記経路探索の結果得られた経路に関連付けて蓄積する手段と、を有することを特徴とするガイド情報提供システム。
【手続補正書】
【提出日】平成23年3月8日(2011.3.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザ端末と通信可能に接続され、Ｗｅｂサーバから収集したガイド情報を前記端末に提供する情報提供サーバであって、
ユーザの少なくとも時間と場所情報を含むスケジュールを登録する手段と、
登録されたスケジュールからユーザが指定した対象スケジュールを抽出する手段と、
抽出した対象スケジュールに基づき、スケジュール上の出発地からスケジュール上の目的地までの経路探索を行う手段と、
探索された経路に関連して前記端末へ提供するガイド情報をＷｅｂサーバから収集する手段と、
を有することを特徴とする情報提供サーバ。
【請求項２】
請求項１に記載された情報提供サーバと、前記端末とから成るガイド情報提供システムであって、
前記端末は、
情報提供サーバから探索された経路情報と共に情報提供サーバが収集した前記ガイド情報を読み込む手段と、
読み込んだ前記ガイド情報に対応する場所を、前記探索された経路上に表示する手段と、
を有することを特徴とするガイド情報提供システム。
【請求項３】
請求項２に記載されたガイド情報システムにおいて、
経路に関連して前記端末へ提供するガイド情報は、予め定めたジャンル毎に分類された情報であり、
情報提供サーバは、前記ジャンル毎に分類された情報を前記スケジュールに割り振りかつ前記経路探索の結果得られた経路に関連付けて蓄積する手段と、を有することを特徴とするガイド情報提供システム。
【請求項４】
請求項２又は３に記載されたガイド情報提供システムにおいて、
前記情報提供サーバは、前記スケジュール上の出発地から目的地までの経路探索において、ユーザの移動速度を考慮して前記目的地におけるスケジュールに間に合う場所的範囲内において、複数の経路について経路検索を行うことを特徴とするガイド情報提供システム。
【請求項５】
請求項２ないし４のいずれかに記載されたガイド情報提供システムにおいて、
前記情報提供サーバは、前記対象スケジュールの指定が行われた、当該スケジュール上の出発位置情報に基づき、出発位置から最も近いガイド情報の所在地を選択し、前記端末は前記ガイド情報の詳細情報を表示することを特徴とするガイド情報提供システム。
【請求項６】
請求項５に記載されたガイド情報提供システムにおいて、
前記情報提供サーバは、スケジュール上の現在位置から最も近いガイド情報の所在地が前記探索された経路上にないとき、当該所在地への寄り道経路を探索し、
前記端末は、前記寄り道経路を表示することを特徴とするガイド情報提供システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、予め登録されたスケジュールに関連する情報を収集し、ガイド情報として提供するサーバ及び前記サーバを含むガイド情報提供システムに関する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
請求項１の発明は、ユーザ端末と通信可能に接続され、Ｗｅｂサーバから収集したガイド情報を前記端末に提供する情報提供サーバであって、ユーザの少なくとも時間と場所情報を含むスケジュールを登録する手段と、登録されたスケジュールからユーザが指定した対象スケジュールを抽出する手段と、抽出した対象スケジュールに基づき、スケジュール上の出発地からスケジュール上の目的地までの経路探索を行う手段と、探索された経路に関連して前記端末へ提供するガイド情報をＷｅｂサーバから収集する手段と、を有することを特徴とする情報提供サーバである。
請求項２の発明は、請求項１に記載された情報提供サーバと、前記端末とから成るガイド情報提供システムであって、前記端末は、情報提供サーバから探索された経路情報と共に情報提供サーバが収集した前記ガイド情報を読み込む手段と、読み込んだ前記ガイド情報に対応する場所を、前記探索された経路上に表示する手段と、を有することを特徴とするガイド情報提供システムである。
請求項３の発明は、請求項２に記載されたガイド情報システムにおいて、経路に関連して前記端末へ提供するガイド情報は、予め定めたジャンル毎に分類された情報であり、情報提供サーバは、前記ジャンル毎に分類された情報を前記スケジュールに割り振りかつ前記経路探索の結果得られた経路に関連付けて蓄積する手段と、を有することを特徴とするガイド情報提供システムである。
請求項４の発明は、請求項２又は３に記載されたガイド情報提供システムにおいて、前記情報提供サーバは、前記スケジュール上の出発地から目的地までの経路探索において、ユーザの移動速度を考慮して前記目的地におけるスケジュールに間に合う場所的範囲内において、複数の経路について経路検索を行うことを特徴とするガイド情報提供システムである。
請求項５の発明は、請求項２ないし４のいずれかに記載されたガイド情報提供システムにおいて、前記情報提供サーバは、前記対象スケジュールの指定が行われた、当該スケジュール上の出発位置情報に基づき、出発位置から最も近いガイド情報の所在地を選択し、前記端末は前記ガイド情報の詳細情報を表示することを特徴とするガイド情報提供システムである。
請求項６の発明は、請求項５に記載されたガイド情報提供システムにおいて、前記情報提供サーバは、スケジュール上の現在位置から最も近いガイド情報の所在地が前記探索された経路上にないとき、当該所在地への寄り道経路を探索し、前記端末は、前記寄り道経路を表示することを特徴とするガイド情報提供システムである。
ガイド情報は、ユーザがスケジュール実行時に参照可能な装置、例えば携帯電話、カーナビゲーション装置、ノートパソコン、ＰＤＡなどを利用して提供することができる。ガイド情報提供システムは、これらの装置を利用してスタンドアロンで稼働するように構成してもよいし、これらの装置を利用した端末とサーバ等をネットワークで接続して構成してもよい。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】削除
【補正の内容】