"予め登録されたスケジュールに関連する情報を収集し、ガイド情報として提供するガイド情報提供システムであって、時刻および目的地を含む予め登録されたスケジュールを参照し、該スケジュールに関連する情報を所定の情報源から収集する情報収集部と、前記時刻および目的地を考慮して、前記収集された情報のうちユーザに提供すべき情報を選択し、該選択された情報を前記ガイド情報として提供する情報提供制御部と、前記ユーザの現在位置を取得する現在位置取得部と、を備え前記ガイド情報には、音声出力すべき情報が含まれており、前記情報収集部は、更に、前記スケジュールと無関係に音声出力可能な汎用情報を保持しており、前記情報提供制御部は、前記現在位置および前記スケジュールに基づいて前記音声出力すべきガイド情報の出力を開始する時刻までの余裕時間を推測し、該推測された余裕時間に基づいて出力すべき汎用情報を選択するガイド情報提供システム。しかし、特許文献1、2記載の技術は、ユーザが何らかの情報を欲した時に、ユーザの要望に添った情報を提供することでシステムの利便性を向上させることを主目的としていた。特許文献3の技術は、自動的に情報を提供してはいるが、情報が要求されるタイミングを車両の燃料残量の低下などの典型的な状況に基づいて判断するものであり、ユーザが欲した時になって初めて、必要な情報を収集して提供するというものであった。このように従来技術では、提供される情報がユーザにとって有用な情報か否かは、ユーザの要望に添っているか否かという観点から判断されていた。ユーザは、予め設定されたスケジュールに従って行動することがある。このスケジュールには、通勤や通学などのように日常的に繰り返されるスケジュールもあれば、出張などのように日常とは異なるスケジュールもある。スケジュールが予め定まっている場合には、移動すべき目的地および到着すべき時刻が定まっているため、移動のための経路はユーザに有用な情報と言える。また、この経路を移動中に活用できる種々の情報も有用な情報となり得る。ただし、スケジュールに従った移動中は、次の目的地および到着時刻によって行動範囲が制約されるため、活用できる情報には限りがある。活用可能な限界を考慮せずに提供される情報は、例えユーザの嗜好や目的などの要望に沿っていたとしても、有用な情報とはなり得ない。従来技術では、こうしたスケジュールを実行する際の制約を考慮した情報提供は行うことができなかった。本発明は、この課題に鑑みなされたものであり、ユーザがスケジュールに沿って行動する際に、スケジュールを実行する際の制約事項を考慮に入れた有用な情報提供を実現することを目的とする。本発明は、予め登録されたスケジュールに関連する情報を収集し、ガイド情報として提供するガイド情報提供システムとして構成することができる。ガイド情報は、ユーザがスケジュール実行時に参照可能な装置、例えば携帯電話、カーナビゲーション装置、ノートパソコン、PDAなどを利用して提供することができる。ガイド情報提供システムは、これらの装置を利用してスタンドアロンで稼働するように構成してもよいし、これらの装置を利用した端末とサーバ等をネットワークで接続して構成してもよい。ガイド情報提供システムは、予め登録されたスケジュールを参照して、このスケジュールに関連する情報を所定の情報源から収集する。スケジュールには、時刻および目的地が含まれる。この他の情報、会議、レジャーなど、移動目的を表す情報をスケジュールに含めても良い。情報は、例えば、ガイド情報提供システムに設置されたDVDその他の記録媒体から収集してもよいし、ネットワーク経由で収集してもよい。情報源は、必ずしもガイド情報提供システムの一部として構成されている必要はなく、例えば、インターネットに接続されたWebサーバを情報源として利用してもよい。ガイド情報提供システムは、スケジュールで指定された時刻および目的地を考慮して、収集された情報のうちユーザに提供すべき情報を選択し、選択された情報をガイド情報としてユーザに提供する。例えば、次の目的地への移動経路に対して所定距離内にある地点に関する情報のみを選択する態様、指定された時刻に目的地に到達可能な範囲内の地点に関する情報のみを選択する態様を採ることができる。また、食事場所についての情報提供する場合には、目的地に移動する時間帯が食事時に当たるか否かを考慮して情報を選択するようにしてもよい。また、次の予定までの時間的な余裕が少ない場合には、予定に遅れる危険性を低減するため、目的地から遠い地点に関する情報は除外し、目的地に十分に近い地点に関する情報を選択するようにしてもよい。このように本発明によれば、スケジュールに関連した情報を事前に収集しておくことができる。従って、情報の収集をリアルタイムで行う必要がないため、多種多様な情報源にアクセスして、幅広く有用な情報を収集できる。また、こうして収集した情報の中から、ユーザのスケジュールに適合した情報を選択して提供するため、スケジュール上の制約によりユーザが活用しづらい情報を排除することができる。従って、ユーザに有用な情報を効率的に提供することが可能となる。本発明では、予め登録されたスケジュールに従って情報を収集するため、スケジュールを実行に移す時点よりも事前に十分な情報を収集しておくことも可能である。ガイド情報提供システムが、サーバと端末から構成されている場合でも、スケジュールの実行を開始する時点で、サーバに蓄積済みの情報を端末に移行させておけば、その後は逐次通信を行わなくてもガイド情報を提供することが可能となる。従って、本発明によれば、通信環境が比較的悪い場合でも、ガイド情報を有効活用できる利点も得られる。ガイド情報提供装置は、ユーザの現在位置を取得可能としてもよい。この場合には、更に、取得された現在位置および現在時刻に基づいて、提供すべき情報を選択してもよい。こうすることにより、ユーザの移動状況と予め登録されたスケジュールとのずれを反映して情報の提供を行うことができる。例えば、ユーザの移動が予定よりも遅れており、次の目的地に到達するまでの時間余裕が短くなってしまった場合には、遅れている状況下でも活用可能な情報のみを更に絞り込んでガイド情報を提供することができる。また、ユーザの移動が予定よりも早い場合や、次の予定がキャンセルされた場合など、時間余裕が増えた場合には、収集されていた情報のうち一旦、除外されていた情報を有用な情報と評価し直すことでガイド情報として提供可能としてもよい。また、ユーザの移動している経路がスケジュール上予定されていた経路からずれている時も同様である。このような場合には、例えば予定されていた経路に近いという理由でガイド情報に組み込まれていた情報を、ガイド情報から削除することができる。また、予定されていた経路から遠いという理由でガイド情報から除外されていた情報を、再度有用な情報と評価し直すことでガイド情報として提供可能とすることもできる。ガイド情報提供システムは、情報を所定のジャンルに分類して収集してもよい。分類のジャンルは任意に設定可能である。例えば、ショッピング、レストランという大きな分類をジャンルとして用いても良いし、ショッピングを洋服、和服、セーラー服、下着のように細分化した分類をジャンルとして用いても良い。この時、ガイド情報提供システムは、ガイド情報として提供済みの情報と関連するジャンルの情報を避けて情報の選択を行うことが可能となる。こうすることにより、類似の情報を繰り返しユーザに提供することを回避でき、有用な情報を効率的に提供することが可能となる。ガイド情報提供システムは、所定の地図データベースを参照し、スケジュールに従った移動経路を探索するとともに、地図上に移動経路を示す案内情報を提供可能としてもよい。この時、移動経路およびガイド情報は、スケジュールとともに表示部に表示させることが好ましい。全スケジュールを表示してもよいし、次の予定を含む一部のスケジュールだけを表示してもよい。このようにスケジュールを併せて表示しておくことにより、ユーザは、自分のスケジュールを意識しながら移動経路およびガイド情報を活用することができる。上述の例において、ガイド情報提供システムが、サーバと端末から構成されている場合には、端末が表示部として機能する。従って、サーバは端末に表示させるための出力データを生成し、端末に送信すればよい。ガイド情報提供システムがユーザの現在位置を取得可能である場合には、先に説明した移動経路を探索するとともに、現在位置からガイド情報に対応する地点まで移動する寄り道経路を探索してもよい。この場合、地図上には移動経路および寄り道経路を共に示すことが好ましい。例えば、ガイド情報として、移動経路から若干それた場所にある名所、店舗、レストランなどの情報を提供する場合には、現在位置からの行き方が寄り道経路として提供されることになる。この態様では、移動経路と寄り道とが併せて提供されるため、ユーザは、寄り道するための迂回距離などを踏まえて、情報提供された場所に立ち寄るか否かを決めることが可能となる。このように移動経路と寄り道経路とを提供する態様においては、ユーザが寄り道経路を進行しているか否かを現在位置に基づいて判断し、寄り道経路から外れたと判断される場合には、寄り道経路に対応するガイド情報の提供を停止することが好ましい。寄り道経路から外れたところを進行しているということは、ユーザは寄り道をしないという決定をしたものと判断して、寄り道経路の表示を消すのである。こうすることで、ガイド情報が提供されるたびに、ユーザがそのガイド情報の要否を入力するという煩雑な必要がなくなるため、システムの利便性を向上することができる。この態様において情報提供が停止されるのは、表示されていた寄り道経路に対応する情報のみであり、新たな情報をガイド情報として提供するのは差し支えない。本発明において、ガイド情報には、音声出力すべき情報以下、音声ガイド情報と呼ぶを含めても良い。例えば、名所案内などを読み上げたり、店舗やレストランの宣伝を音声出力したりする態様などが挙げられる。また、ユーザに提供可能な情報には、スケジュールと無関係に音声出力する汎用情報を含めても良い。汎用情報としては、例えば、ニュース、天気予報、および広告などが挙げられる。音楽を含めても良い。音声ガイド情報は、名所や店舗などの決まって地点に近づいた時点で出力する必要があるため、その出力タイミングがスケジュールによって制約されるのに対し、汎用情報はスケジュールによる制約を受けずに任意のタイミングで出力可能である。ガイド情報提供システムは、ユーザの現在位置およびスケジュールに基づいてガイド情報の音声出力を開始する時刻までの余裕時間を推測することができる。ガイド情報提供システムは、こうして推測された余裕時間に基づいて、出力すべき汎用情報を選択することが好ましい。一例として、各汎用情報を出力するための所要時間を参照し、上述の余裕時間内に出力を完了できる汎用情報を選択する方法を採ることができる。このような汎用情報が複数存在する場合には、所要時間が長いものを優先してもよい。このようにガイド情報の出力までの余裕時間と、汎用情報の所要時間とを考慮して出力すべき汎用情報を選択することにより、ガイド情報が出力されていない空白の時間を利用して、効率的に汎用情報を提供することが可能となる。本発明は、先に説明した通り、スタンドアロンで稼働するシステムとして構成してもよいし、サーバとクライアントとをネットワークで接続して構成してもよい。後者の態様では、例えば、サーバには、予め登録されたスケジュールおよび前記情報のユーザにとっての有用性の判断に用いることができる情報を格納したユーザプロファイルを参照し、前記スケジュールおよびユーザプロファイルに関連する情報を、所定の情報源から収集する機能を分担させることができる。ユーザプロファイルとは、例えば、ユーザの趣味、嗜好、家族構成などの情報を格納したデータベースとすることができる。サーバはユーザプロファイルを参照することにより、ユーザの趣味等に関連する範囲に絞って情報収集することができる。クライアントは、収集された情報の少なくとも一部をサーバから取得し、ガイド情報として提供する機能を分担する。サーバは、十分な情報収集、情報蓄積、情報処理能力を有しているのが通常であるため、上述の構成によれば、これらの能力による制約なく、有用な情報を収集することができる。この態様では、クライアントは、収集された全情報を取得する必要はなく、一部を取得するだけでもよい。先に説明した種々の選択方法によって収集された情報のうち、有効活用し得る情報のみを選択して取得するようにすれば、効率的にガイド情報を提供することが可能となる。本態様では、クライアントは、スケジュール実行に先立って、サーバから情報を取得してもよい。こうすれば、サーバとクライアントとの通信環境に依らず、収集された情報を有効活用することが可能となる。本発明は、上述した種々の特徴を必ずしも全て備えている必要はなく、一部を省略したり適宜組み合わせたりして構成することができる。本発明は、上述したガイド情報提供システムとして構成する他、コンピュータによってガイド情報を提供するガイド情報提供方法として構成することもできる。また、かかるガイド情報の提供を実現するためのコンピュータプログラムとして構成したり、このコンピュータプログラムの少なくとも一部を記録した記録媒体として構成したりすることもできる。この場合、記録媒体としては、フレキシブルディスクやCD-ROM、光磁気ディスク、ICカード、ROMカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置RAMやROMなどのメモリおよび外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。本発明の実施例について以下の順序で説明する。A.システム構成:B.データ構造:C.ガイド情報提供の制御処理:C1.スケジュール登録変更処理:C2.情報ボックスメンテナンス処理:C3.スケジュールガイド処理:D.変形例:A.システム構成:図1は実施例としてのガイド情報提供システムの構成を示す説明図である。ガイド情報提供システムは、予め登録されたスケジュールに関連する情報を収集し、ユーザがスケジュールを実行する際に、収集した情報の中からユーザが有効活用できる情報を、移動経路とともに提供するシステムである。本明細書では、収集された情報をスケジュール関連情報と呼び、収集された情報のうち、ユーザに提供すべき情報として選択されたものをガイド情報と呼ぶ。実施例のガイド情報提供システムは、情報提供サーバ200以下、単にサーバと呼ぶこともあると、端末100[1]、100[2]とをインターネットINTで接続して構成される。図中の例では、端末100[1]は携帯電話であり、端末100[2]はカーナビゲーション装置である。端末には、この他、ノートPC、PDAなど携帯可能な種々の装置が利用可能である。以下の説明では、両者を総称して単に端末100と称する時もある。端末100には、情報提供サーバ200から提供されるガイド情報を取得するためにインターネットINTとの通信機能が要求されるが、スケジュールの実行中に常時、インターネットINTへのアクセスが常時確保されている必要はない。図の例では、インターネットINTを適用した例を示したが、インターネットINTに代えて、イントラネットなどの限定的なネットワークを用いることも可能である。ガイド情報提供システムは、上述の通り、サーバ200と端末100とを中心として構成されるが、この他にもパソコン300および多数のWebサーバ400[1]、400[2]を含めることができる。パソコン300は、サーバ200にスケジュールの登録、およびスケジュールに従って事前に収集された情報の管理を行うための装置である。本実施例では、これらの機能は、サーバ200から提供されるWebページによって実現するものとした。従って、上述の機能を実現するためには、パソコン300はブラウザを搭載していれば足りる。上述の機能は、端末100でも実現可能である。この意味で、パソコン300は端末100の一種と呼ぶこともできるが、スケジュールの登録等の機能は、デスクトップ型のパソコンなど携帯不能な装置でも実現可能であるため、本実施例では端末100と区別して示した。Webサーバ400[1]、400[2]以下、両者をWebサーバ400と総称することもある。は、インターネット上のWebサイトを通じて種々の情報を提供するサーバである。図中では、Webサーバ400[1]は観光情報を提供し、Webサーバ400[2]はグルメ情報を提供する例を示した。提供される情報には、これらに限らず、ショッピング情報、行政情報など多種多様な情報が含まれる。Webサーバ400は、ガイド情報提供システムに特化したサーバである必要はない。ただし、ガイド情報提供システムと提携したサーバとしておけば、より利便性の高いシステムを構築することができる。例えば、Webサーバ400が情報を規定のフォーマットに従って提供することにより、本システムの情報収集効率を向上させることができる。また、情報の中に固有のパラメータを含み得るようにしておくことで、Webサーバ400側からガイド情報提供システムにおける情報の利用態様を制御することも可能となる。図中には、ガイド情報提供システムとしての機能を提供するための情報提供サーバ200の機能ブロックを併せて示した。本実施例では、これらの機能ブロックは、これらの機能を実現するためのCGICommonGatewayInterfaceなどで構成されたコンピュータプログラムを情報提供サーバ200にインストールすることによってソフトウェア的に実現される。図中の機能ブロックの少なくとも一部は、ASICなどの回路によって、ハードウェア的に構成することも可能である。サーバ200は、図示する4通りのデータベースを備えている。個人プロファイル201は、後述する通り、ユーザID、氏名、生年月日などのユーザ個人の識別情報、ユーザの趣味、嗜好などの情報、および画面や音声出力などに関するカスタマイズの情報を格納する。個人プロファイル201の読み出し、書き込みは、プロファイル管理部240が制御する。汎用情報DB202は、ガイド情報提供システムがユーザに提供する汎用情報を格納する。汎用情報とは、スケジュールに無関係に提供可能な情報を言い、ニュース、天気予報、各種の広告などが含まれる。音楽を含めても良い。マイボックス203は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ200が収集した情報以下、スケジュール関連情報と称するを格納する。マイボックス203の内容についても後述する。地図DB204は、スケジュールに基づいて定まる目的地までの経路の探索や案内に使用されるデータベースであり、道路をノードリンクの集合で表した道路ネットワークデータと、地図を表示するための描画データとを格納する。本実施例では、サーバ200は、これらのデータベースを活用しながら、以下に示す各機能ブロックの作用によって、ガイド情報の提供を行う。道路ネットワークデータには、車両で移動する際に活用できる車両用のネットワークデータ、歩行時に活用できる歩行者用のネットワークデータ、交通機関を利用する際に活用できる交通機関用のネットワークデータなどを含めることができる。通信部210は、インターネットINTを介した情報授受を制御する機能を奏する。情報収集部250は、通信部120を介して得られた情報を、汎用情報DB202またはマイボックス203に格納したり、逆にこれらのデータベースから情報を読み出したりする機能を奏する。一例として、情報収集部250は、パソコン300との間で情報授受を行い、ユーザからの指定に従って、マイボックス内のスケジュールの更新、読み出しなどを行う。また、情報収集部250は、Webサーバ400にアクセスして、汎用情報DB202に格納すべきニュース、広告等の汎用情報を収集したり、マイボックス203に格納すべき情報、即ちスケジュール関連情報を収集したりする。情報提供制御部230は、個人プロファイル201、汎用情報DB202、マイボックス203を参照し、スケジュールの実行中にユーザに提供すべきガイド情報の取捨選択を行う。取捨選択するための処理内容については後述する。情報提供制御部230の機能によって、サーバ200は、ユーザにとって有用性の高い情報を提供することが可能となる。経路案内部260は、マイボックス203に登録されたスケジュールに従って移動する際の移動経路や、スケジュール関連情報で得られた各地点まで移動するための寄り道経路を探索する。経路探索は、地図DB204の道路ネットワークデータを参照し、ダイクストラ法など周知の方法を適用して実現することができる。経路案内部260は、また、スケジュール実行時には、描画データに基づいて地図表示を行うとともに、地図上に移動経路や寄り道経路の表示を行う。出力データ生成部220は、情報提供制御部230および経路案内部260から提供されるデータに基づいて、端末100に表示するための表示データを生成する。本実施例では、多種多様な端末100を利用できるよう、HTML、XMLを利用して表示データを生成するものとした。出力データ生成部220は、ガイド情報等を提供するための画面の他、スケジュールを登録管理するための画面、動作を選択するためのメニュー画面など、ガイド情報提供システムに要求される種々の画面の表示データを生成する。図中に端末100[1]に備えられる機能ブロックを併せて例示した。端末100[2]も同様の構成を有している。端末100では、主制御部110の管理下で、図示する各機能ブロックが稼働する。本実施例では、これらの機能ブロックは、端末100としての機能を実現するためのプログラムによって、ソフトウェア的に構成したが、ハードウェア的に構成してもよい。通信部120は、インターネットINTを介した情報の授受を制御する。コマンド入力部130は、ユーザの操作に応じてメニューの選択、案内の開始、表示すべき情報の選択など種々のコマンドを入力する。表示制御部150は、情報提供サーバ200からのデータに従って画面表示を行う機能を奏する。本実施例では、ブラウザによって提供される。GPSGlobalPositioningSystem140は、ユーザの現在位置を検出する。現在位置は、サーバ200に送信され、ガイド情報や経路案内の表示制御に活用される。ここで示したのは、ガイド情報提供システムの一例に過ぎない。図1中に示した各機能ブロックは、必ずしも情報提供サーバ200または端末100に全て備えられている必要はなく、分散処理によって複数のサーバ等の連携で実現するようにしてもよい。B.データ構造:図2は個人プロファイル201、マイボックス203のデータ構造を示す説明図である。左側に個人プロファイル201の内容を示し、右側にマイボックス203の内容を示した。個人プロファイル201は、ガイド情報提供システムの利用者を管理するためのデータベースであるとともに、ユーザにとって有用な情報を選択する際に活用できる情報を提供するデータベースともなる。個人プロファイル201には、図示する通り、ユーザID、氏名、生年月日、性別、家族構成などのユーザ個人の識別情報が格納される。図の例では、ユーザIDとしてUSR001が格納されている例を示した。家族構成は、妻、娘1人、息子1人という人数構成を格納した例を示したが、各人の年齢や趣味、嗜好などを格納するようにしてもよい。家族構成を詳細にするほど、収集選択される情報の有用性が向上する。例えば、家族でレジャーに出かける場合のガイド情報を提供する場合、娘が小学生なのか女子高生なのかによって、有用な情報は異なるからである。個人プロファイル201には、ユーザの趣味、嗜好などの情報も格納される。この情報もスケジュール関連情報の収集およびガイド情報の選択に活用される。図示するように、ラーメン好みであるなどの嗜好を把握しておくことにより、レストラン情報を提供する際にはラーメン屋を優先させるなどの態様で、ユーザに有用な情報を提供することが可能となる。趣味についても同様である。図の例では、嗜好および趣味を例示したが、この他、職業、ガイド情報の利用実績など、ガイド情報の収集選択に活用可能な種々の情報を含めることができる。個人プロファイル201には、更に、オプション情報を格納してもよい。図の例では、情報提供に関するカスタマイズの情報を例示した。画面色とは、情報提供画面の背景色の選択を意味する。音声とは、音声出力時の読み上げ音声の種類以下、音声種別と呼ぶを意味する。本実施例では、予め登録された複数種類の音声種別の中からユーザの好みの音声種別を選択する態様を採った。音声に格納されたFVOICE1は、登録された女性音声の識別コードである。サーバ200がガイド情報等を音声出力する際には、この音声識別コードを反映した音声出力データを生成し、端末100に送信すればよい。マイボックス203は、ユーザから登録されたスケジュールや、このスケジュールに関してサーバ200が収集した情報以下、スケジュール関連情報と称するを格納する。マイボックス203と個人プロファイル201とは、ユーザIDで対応づけられている。スケジュールには、日付、時間帯、場所、スケジュールの内容などが登録される。図の例では、3月1日には、13時からZ社で会議という予定が入っており、その前の時間帯、10時~13時の間は特に予定がない移動時間となっていることが分かる。また、3月2日の例では、11時~12時に来客の予定が入っており、12時~13時過ぎに昼食の予定が入っていることが分かる。情報ボックスには、スケジュール関連情報が登録されている。この情報とスケジュールとは、関連IDで関連づけられる。図中の例で示す情報には、INFO1なる関連IDが付されており、3月1日のスケジュールにおける移動時間にINFO1なる関連IDが付されているため、この情報は3月1日の移動中に活用できる情報であることが分かる。情報ボックスには、多くのスケジュール関連情報が登録される。関連IDは、それぞれの情報に固有としてもよいし、スケジュールの項目に固有としてもよい。例えば、図の例において、3月1日の移動に関連するスケジュール関連情報が複数存在する場合を考える。前者の例によれば、これらの全情報には個別の関連IDが付されるため、スケジュールにおける移動に対して、複数の関連IDが登録されることになる。後者の例によれば、スケジュール関連情報には、全て移動に付された関連IDINFO1が付されることになる。いずれの態様を採るかは任意に選択可能である。前者の態様を採る場合において、INFO1のように、共通のINFO1を含む形で関連IDを設定することにより、移動との対応関係を容易に判断できるようにしてもよい。それぞれのスケジュール関連情報には、図中に示す種々の情報が格納される。パスは、情報の格納先を表している。サーバ200内のディレクトリやファイル名で表しても良いし、Webサーバ400に格納された情報のURLを用いても良い。優先度は、ガイド情報として提供する際の優先度を表している。後述する通り、優先度を用いることで、類似の情報が繰り返し提供されることを回避したり、ユーザの嗜好を反映した情報を優先的に提供したりすることが可能となる。NORMALは、通常の優先度を意味している。優先度は、優先度の高低を表す数値としても良い。名称には、店舗名、名所の名称、地名など、スケジュール関連情報を表す名称が格納される。場所は店舗の所在地、名所の所在地など、スケジュール関連情報に関連する地点を表す緯度、経度が格納される。Webサーバ400を参照して、スケジュール関連情報を収集する場合、住所は特定できても緯度、経度までは特定できないことがある。このような場合には、場所は住所で登録可能としてもよい。本実施例では、ガイド情報を提供する際の処理の簡略化を図るため、場所は緯度、経度の形式に統一して格納するものとした。緯度、経度が直接、収集できなかった場合には、サーバ200が住所に基づいて地図DB204を参照し緯度、経度を検索する。音声は音声出力データの出力時の音声識別コードである。個人プロファイル201に登録されているのと同様、予めサーバ200に登録されている音声種別を特定するための情報である。この音声識別コードは、Webサイトで提供される情報に音声識別コードを埋め込まれている場合に格納される。こうすることで、情報の提供者は、自己がWebサイトを通じて提供する情報の一部に、音声識別コードを埋め込んでおくだけで、ガイド情報提供システムで利用される時の音声種別を制御することが可能となる。例えば、図の例であれば、○○ラーメンの店主は、自己の好みの音声で、自己の店舗の宣伝や案内を提供することが可能となるのである。所要時間は、スケジュール関連情報に従って行動する際に必要となる時間余裕を表している。例えば、ラーメン屋の場合には、ラーメンを注文してから食べ終わるまでの時間を所要時間とすることができる。人気の高いラーメン屋の場合には、平均の待ち時間を考慮してもよい。所要時間は、情報の提供者が情報内に埋め込んでおくようにしてもよいし、スケジュール関連情報で与えられる店舗、名所などの種別、人気度等に応じて平均的な値をサーバ200が設定するようにしてもよい。提供履歴は、スケジュール関連情報が端末100に提供された履歴を記録する。図の例では、この情報が、2006年3月1日に、端末100[1]に提供されたことを示している。提供履歴を参照することにより、サーバ200は同一の情報が繰り返しユーザに提供されることを回避することができる。提供履歴には、ユーザが、この情報を活用したか否かの履歴を含めるようにしてもよい。以上で説明したデータ構造は、一例に過ぎない。個人プロファイル201およびマイボックス203共に、図示した項目全てのデータを格納している必要はなく、一部の項目を省略してもよい。また、図示した項目以外のデータを含めるようにしてもよい。データの格納形式も、図の例に限らず、種々の形式を採り得る。C.ガイド情報提供の制御処理:図3はガイド情報提供システムにおける制御処理のフローチャートである。サーバ200が実行するメインルーチンに相当する。処理を開始すると、サーバ200はユーザからのログインを受け付けステップS10、メニュー画面を提示して、ユーザからの指示を入力するステップS12。図中にメニュー画面MENUの例を示した。この例では、1.スケジュール登録変更、2.情報ボックスメンテナンス、3.スケジュールガイド、4.個人プロファイル管理の4通りのメニューを設けた。サーバは、ユーザからの選択指示に応じてステップS14、それぞれのメニューに対応した処理を実行する。1.スケジュール登録変更が選択された場合には、サーバ200は、スケジュール登録変更処理を行うステップS100。これは、マイボックス203にスケジュールを登録したり、登録済みのスケジュールを変更したりするための処理である。端末100およびパソコン300のいずれを利用することも可能であるが、パソコン300を利用する方が操作性の面で好ましい。スケジュール登録変更処理の内容については後で詳述する。2.情報ボックスメンテナンスが選択された場合には、サーバ200は、情報ボックスメンテナンス処理を行うステップS200。これは、マイボックス203に蓄積されたスケジュール関連情報の追加、変更、削除を行うための処理である。端末100およびパソコン300のいずれを利用することも可能であるが、パソコン300を利用する方が操作性の面で好ましい。スケジュール登録変更処理の内容については後で詳述する。3.スケジュールガイドが選択された場合には、サーバ200は、スケジュールガイド処理を行うステップS300。これは、スケジュールの実行時に、スケジュールに従った移動経路の案内や、ガイド情報の提供を行うための処理である。ユーザが移動している状態での案内、情報提供を行う処理であるため、携帯性のある端末100を利用することになる。4.個人プロファイル管理が選択された場合には、サーバ200は、個人プロファイル管理処理を行うステップS400。これは、個人プロファイル201の登録、変更、削除を行うための処理である。端末100およびパソコン300のいずれを利用することも可能であるが、パソコン300を利用する方が操作性の面で好ましい。この処理では、サーバ200は、個人プロファイル201の内容図2参照を、ユーザのパソコン300等に表示し、ユーザが各項目を入力すると、その内容で個人プロファイル201を更新する。C1.スケジュール登録変更処理:図4はスケジュール登録変更処理のフローチャートである。メインルーチン図3のステップS100に相当する処理である。先に説明した通り、この処理では、端末100を利用することも可能ではあるが、以下では説明の便宜上、パソコン300を利用するものとして説明する。この処理を開始すると、サーバ200は、マイボックス203から既存のスケジュールを読み込むステップS102。スケジュールが未登録の場合には、実質的に何も読み込まれないまま、ステップS102の処理を終えることになる。そして、サーバ200は、読み込んだスケジュールをパソコン300の画面に表示し、ユーザの操作に基づいてスケジュールの編集コマンドを入力するステップS104。図中にスケジュールの編集画面の例を示した。パソコン300には、指定された日のスケジュール画面W1が表示される。既に登録済みのスケジュールは、この画面W1に表示される。図中の例では、13時からZ社で会議という予定が登録済みである。ユーザがパソコン300のマウスまたはキーボードを操作して、画面W1内でいずれかの時間帯を指定すると、スケジュールを入力するためのサブウィンドウW2が表示される。既に予定を登録済みの時間帯をクリックした場合には、サブウィンドウW2には、登録済みの予定内容が表示される。ユーザは、このサブウィンドウを利用して、日時、タイトル、場所、メンバー、その他のメモなどを登録することができる。また、スケジュール関連情報の収集を行うか否かON/OFFを切り換えることができる。情報収集をONとすると、サーバ200によって、スケジュールとスケジュール関連情報とを対応づける関連IDが割り振られる。図中の例は、関連IDとしてINFO1が割り当てられた状態を示している。スケジュールの編集は、図示した画面に限らず、周知の種々の編集画面を利用することが可能である。図では、スケジュール関連情報の収集を行うか否かをユーザが指定する例を示した。情報収集のON/OFFの指定は不要としてもよい。例えば、サーバ200は、予定が登録された場合に、その直前の空き時間に対して、自動的に情報収集をONに設定するようにしてもよい。また、このような設定をするまでなく、全時間帯について情報収集を行うようにしてもよい。例えば、予定が登録されている時間帯については、その予定に対応した情報を収集し、空き時間については次の予定までの移動中で有効活用できる情報を収集すればよい。スケジュールの編集が完了すると、サーバ200は編集結果をマイボックス203に格納して、スケジュールを更新するステップS106。そして、情報収集処理、即ちスケジュール関連情報を収集するための処理を実行するステップS110。図5は情報収集処理のフローチャートである。この処理では、サーバ200はマイボックス203からスケジュールを読み込み、情報収集の対象となるべき予定、即ち対象スケジュールを抽出するステップS112。本実施例では、先に説明した通り、情報収集がONに設定された予定を抽出することになる。サーバ200は、この対象スケジュールに対して、直前のスケジュールの場所を開始時位置として設定し、対象スケジュールの直後の場所を終了時位置に設定するステップS114。そして、開始時位置から終了時位置までの経路探索を行うステップS116。経路探索は、地図DB204の道路ネットワークデータを参照して行うことができる。ここでは、対象スケジュール前後の予定が与えられているため、この予定に支障がない移動方法を探索する必要がある。つまり、直前の予定の終了時刻に開始時位置を出発し、直後の予定の開始時刻には終了時位置に到達していなくてはならない。このような経路は、所要時間最短という条件で探索すればよい。ダイクストラ法を用いる場合には、各リンクの通過所要時間を反映したコストが最小となるよう、経路探索を行えばよい。経路探索には、種々の条件を考慮することができ、例えば、車両、徒歩、交通機関利用時など、移動手段を多様に変化させて、それぞれの経路を求めても良い。徒歩の時には、坂道や階段に高いコスト値を付すことによって、坂道や階段を避ける経路を探索してもよい。同様に、ユーザの要望をコストに反映させることで、種々の要望を考慮した経路探索を行うことが可能である。本実施例では、対象スケジュールが移動不能な予定の場合もある。例えば、会議という予定に対して、スケジュール関連情報の収集がONとなっている場合が該当する。このように移動不能な予定に対しては、ステップS116の処理は省略してもよい。サーバ200は、次に、個人プロファイル201から、ユーザの嗜好および趣味に関するデータを読み込むステップS118。そして、以上で取り込んだ情報に基づいてWebサーバから情報を収集するステップS120。この情報収集は、ユーザに有用な情報を提供することが目的であるから、次の条件で行う。まず、ユーザの嗜好、趣味に合致または類似する情報であることが条件となる。例えば、ユーザがラーメン好きという嗜好を有している場合には、合致する情報としてラーメン屋の案内情報を収集すればよい。また、類似する情報として、中華料理屋や、そば屋、うどん屋などの麺類の店の案内情報を収集すればよい。趣味についても同様である。情報収集時には、スケジュールに同行するメンバー構成を考慮してもよい。例えば、家族でのレジャーの場合には、家族構成や家族のメンバーの嗜好、趣味等を考慮することができる。出張の場合には、会社の同僚の嗜好、趣味等を考慮することもできる。第2の条件は、直後の予定に間に合う場所的範囲で情報収集を行うことである。例えば、いくら人気のあるラーメン屋に関する情報であっても、次の予定に間に合わないほど遠くにある店についての情報では活用できないからである。この条件は、種々の方法で判断することができる。例えば、ステップS116で探索した経路から所定距離内の場所についての情報というように簡易な方法で判断するようにしてもよい。この場合の所定距離は、次の予定までの余裕時間、次の目的地までの距離、ユーザの移動速度を考慮して設定することができる。また、別の態様として、スケジュール関連情報に対応した場所を経由地としてステップS116の経路探索を行い、直後の予定に間に合うか否かを判断するようにしてもよい。以上の条件に合致する情報が得られると、サーバ200は、その情報に、対象スケジュールに付された関連IDを付して、情報ボックスに格納するステップS122。サーバ200は、情報収集処理を適宜、繰り返し実行することで、関連IDが付された全スケジュールについてスケジュール関連情報を収集するとともに、それぞれの予定について、できるだけ多くのスケジュール関連情報を収集するよう努める。情報収集処理は、例えば、全スケジュールについて一定数までの情報が収集されるまで繰り返し実行するようにしてもよい。以上の説明では、スケジュールの登録変更がなされた時に情報収集処理を行う場合を示した。情報収集処理は、この他のタイミングにも実行可能である。例えば、スケジュールが実行されるまでの間、スケジュールの登録変更が行われるか否かとは無関係に定期的に実行してもよい。このように繰り返し実行することにより、より多くの情報、かつより新しい情報を収集することが可能となる。C2.情報ボックスメンテナンス処理:図6は情報ボックスメンテナンス処理のフローチャートである。メインルーチンのステップS200に相当する処理である。この処理は、サーバ200が収集したスケジュール関連情報を、スケジュールの実行前にユーザが確認し、不要な情報を削除するための処理である。先に説明した通り、この処理では、端末100を利用することも可能ではあるが、以下では説明の便宜上、パソコン300を利用するものとして説明する。処理を開始すると、サーバ200はユーザからスケジュール関連情報を表示する対象となる予定、即ち対象スケジュールの指定を受け付けるステップS202。ユーザがパソコン300で、対象スケジュールを指定すると、サーバ200はマイボックス203の情報ボックスを参照して、対象スケジュールに割り振られた関連IDが付された情報を読み込むステップS204。サーバ200は、読み込んだ結果をパソコン300に表示し、スケジュール関連情報の編集を受け付けるステップS206。図中にパソコン300に表示される編集画面例を示した。この例では、画面の左側に矢印で示すように、地図上にスケジュールに従った移動経路が表示される。そして、スケジュール関連情報の項目が、右下に表示され、地図上には、この項目に対応する場所が表示される。図中の例では、スケジュール関連情報として、情報a○○ラーメン、情報b△△チャンポン、情報cうどんが得られている。左側の地図では、a~cの符号で、それぞれの情報に対応する店舗の位置が表示される。ここでは、店舗の例を示したが、名所等についても同様である。また、右上には登録されているスケジュールが表示される。図示した編集画面では、上述の通り、ユーザは地図によってスケジュール関連情報に対応する地点以下、設定場所というと移動経路との位置関係を把握することができ、同時に、右上のスケジュール画面によって次の予定までの時間余裕を把握することができる。更に、右下の画面で各項目をクリックすると、詳細な情報が表示されるようにしてもよい。ユーザは、これらの情報を一覧して、スケジュール関連情報の要否を判断する。例えば、情報a○○ラーメンは店の場所が遠いため不要と判断した場合には、画面の右下のエリアで、情報aのチェックボックスをチェックし、削除ボタンをクリックすればよい。サーバ200は、編集結果を入力すると、それに応じて情報ボックスの内容を更新しステップS208、情報ボックスメンテナンス処理を終了する。実施例では、情報を削除する方法を例示したが、更に、ユーザ自身が収集した情報を追加可能としてもよい。例えば、ステップS206中に示した編集画面に、ユーザが情報のパスまたはURLを入力可能とし、ステップS208では、サーバ200がこれに従って、情報を取得して情報ボックスに格納するようにすればよい。C3.スケジュールガイド処理:ユーザはスケジュールの実行時になると、メニュー画面MENU図3参照でスケジュールガイドを指示する。サーバ200は、この指示に応じて、端末100に対して、ユーザがスケジュールを実行する際の支援情報、つまり目的地までの経路その他の有用な情報を提供する。以下では、まず端末100の表示画面例によって、スケジュールガイド処理における具体的な処理内容を説明した後、この処理を実現するためのフローチャートを示す。先に説明した通り、スケジュールを開始する時点で、サーバ200には、スケジュールガイドに必要な情報は一通り蓄積されている。従って、ユーザは端末100にこれらの情報を一括ダウンロードしておくことにより、サーバ200との通信を行わずにスケジュールガイド処理を実行させることも可能である。ただし、以下では、端末100はサーバ200と適宜、通信可能な環境にあることを前提として説明する。スケジュールガイド中にサーバ200と通信することによって、ユーザの現状に応じて、提供する情報の内容を柔軟に変更できる利点があるからである。図7はスケジュールガイド処理時の表示画面例を示す説明図である。図7aは、次の目的地に向かって移動中の画面を表している。この画面では、左側に地図および移動経路が表示され、右上にスケジュール、右下にガイド情報が提示される。本実施例では、情報ボックスメンテナンス処理図6時の画面と類似の画面構成を採用した。ただし、情報ボックスメンテナンス処理では、右下に、スケジュール関連情報の一覧が表示されるのに対し、スケジュールガイド処理では、いずれか選択された情報が提示される点で相違する。以下、スケジュール関連情報のうち、ユーザに提示するよう選択された情報をガイド情報と称する。図7a中の点PPはユーザの現在位置を表している。実線の矢印は次の予定の目的地に至るまでの移動経路を表している。図中のハッチングを付した地点a,b,cは、現在位置付近のスケジュール関連情報の所在地を表している。サーバ200は、この中から、現在位置PPに最も近い地点cを選択し、ガイド情報として、画面の右下に詳細な情報を表示する。また、左側の地図上には破線矢印で示すように現在位置PPから地点cに至るまでの寄り道経路を表示する。ユーザは、この表示画面により、移動経路、寄り道経路、スケジュールおよびガイド情報の内容を一覧することができる。ユーザは、これらの情報を総合的に考慮して、ガイド情報で提供された地点cを訪問するか否かを決定できる。図7bは、ユーザが地点cを訪問すると決めた時の表示画面例である。本実施例では、ユーザが寄り道経路に沿って一定の距離または一定の時間、進行を開始したところで、サーバ200は、ユーザが地点cを訪問するつもりであると判断して図7bの画面を表示する。ユーザの移動状況に応じて判断する方法に代えて、またはこのような判断方法と共に、ユーザが端末100を操作して、地点cを訪問する旨をサーバ200に指示する態様をとってもよい。図7bの画面では、図中に実線矢印で示すように、寄り道経路が表示される。従前の移動経路は消え、地点cに訪問した後、目的地に向かう経路が再探索されて表示される。端末100がサーバ200と通信できない環境にある場合には、経路の再探索をできないため、従前の移動経路をそのまま継続して表示してもよい。図の例では、スケジュール関連情報a~cは麺類のお店など、共通のジャンルの情報であるとする。サーバ200は、ユーザが地点cを訪問すると決めた時点で、更に、類似の情報をガイド情報として提供する必要性はないと判断する。従って、共通のジャンルの情報である情報a,cの提供を停止する。この結果、図7bの実施例では、地点a,bはハッチングを削除した状態での表示に切り替わる。ユーザが地点cに到達するまで待ってから切り換えるようにしてもよい。また、ユーザが地点cに進行を開始した時点で、一旦、削除した後、地点cの訪問を中断した時点で、再度、ハッチング表示を復活させてもよい。図7cは、ユーザが地点cを訪問しない場合の表示画面例である。本実施例では、ユーザが寄り道経路を採らず、移動経路に沿って一定の距離または一定の時間、進行を開始したところで、サーバ200は、ユーザが地点cを訪問しないつもりであると判断して、図7cの画面を表示する。この画面では、地点cへの寄り道経路は消され、地点cはハッチング無しの表示に切り替わる。また、ガイド情報欄の表示も削除される。地点a,bはそのままハッチングを付した状態で表示される。ただし、現在位置PPは地点a,bからは、まだ通りため、寄り道経路もガイド情報も提示されていない状況である。このように、スケジュールガイド処理では、サーバ200は、ユーザの現在位置に応じて、ガイド情報を提示するとともに、ユーザの進行状況に応じて、提示したガイド情報の採否を判断して、ガイド情報を切り換える。こうすることにより、ユーザに煩雑な操作を要求するまでなく、有用な情報を提供することが可能となる。図8はスケジュールガイド処理のフローチャートである。メインルーチンのステップS300に相当する処理である。この処理を開始すると、サーバ200は、スケジュールデータおよび経路探索結果を読み込むステップS302。そして、ユーザの現在位置および現在時刻を入力しステップS304、現在実行中の予定が対象スケジュールであるか否かを判断するステップS306。対象スケジュールを実行している場合には、サーバ200は、ガイド情報提示処理および汎用情報出力処理を実行するステップS310、S330。ガイド情報提示処理とは、マイボックスに蓄積されていたスケジュール関連情報の中から、ユーザに提供すべきガイド情報を選択する処理である。汎用情報出力処理とは、ニュース、広告などの汎用情報の中から、出力すべきガイド情報がない空白の時間帯を利用して出力すべき汎用情報を選択する処理であるステップS330。各処理の内容は後で示す。対象スケジュールの実行中でない場合にはステップS306、サーバ200は、ガイド情報提示処理および汎用情報出力処理はスキップして、次の処理に移行する。以上の処理に基づき、サーバ200は、また、端末100に移動経路の案内を行うとともに、ガイド情報、汎用情報の出力を行うステップS350。経路案内は、図7に示した様に、端末100の画面に地図、現在位置、移動経路を提示することで行う。ガイド情報は、図7に示したように、地図上でガイド情報に対応する地点を表示し、その地点に至るまでの寄り道経路を表示するとともに、画面右下にガイド情報の内容を表示する。汎用情報は、画面右下のガイド情報のエリアに表示させることができる。また、ガイド情報、汎用情報に音声データが含まれている場合には、サーバ200は、その音声出力も行う。音声出力は、ユーザが個人プロファイル201で指定した音声種別図2参照または情報提供者がWebサイトを通じて指定した音声種別を使用する。後者を前者よりも優先することが好ましい。サーバ200は、以上の処理を、ユーザがスケジュールを完了するまで、またはユーザがスケジュールガイド処理の終了を指示するまでステップS352、繰り返し実行する。図9はガイド情報提示処理のフローチャートである。スケジュールガイド処理のステップS310に相当する処理である。この処理では、サーバ200は、スケジュール関連情報に対応する地点以下、設定場所と呼ぶが現在位置に最も近いガイド情報を情報ボックスから抽出するステップS311。ガイド情報の抽出時には、現在位置との距離関係の他、種々の要素を考慮してもよい。例えば、先に図2で示した通り、本実施例では、スケジュール関連情報には、提示履歴が記録されている。ステップS311では、サーバ200は、提示履歴を参照し、ユーザに未提示の情報の中からガイド情報を選択してもよい。こうすることにより、例えば、スケジュールガイド処理の途中でユーザが利用する端末を変更した場合でも、提示済みの情報が繰り返し提示されることを回避することができる。別の態様として、ユーザの嗜好や趣味を考慮してもよい。こうすることで、現在位置の近傍に、複数のスケジュール関連情報が収集されている場合には、ユーザの嗜好や趣味により合致する情報を優先的に選択することができる。ユーザのみならず同行者の趣味や嗜好を考慮してもよい。また、時間帯や次の予定の内容を考慮してもよい。例えば、食事の時間帯からずれている時はレストランの情報を除いてガイド情報を選択することが好ましく、食事の時間帯の場合には逆にレストラン情報を優先的に選択することが好ましい。次の予定が仕事の場合には、居酒屋よりも喫茶店の情報を優先的に案内するなどの態様を採ってもよい。次に、サーバ200は、現在位置から設定場所まで至る寄り道経路を探索するステップS312。また、スケジュールデータを参照して、現在時刻から次の予定までの余裕時間を求め、ガイド情報に登録された所要時間図2参照が許容範囲か否かを判断するステップS313。この判断においては、登録されている所要時間の他に、設定地点までの移動に要する時間を考慮する必要がある。つまり、所要時間<余裕時間-移動時間という関係にあることが必要である。移動時間は、種々の方法で推定することができる。例えば、現在地点から設定地点までの距離、または移動経路から設定地点までの距離に応じて、移動時間を推定してもよい。ステップS312で求めた寄り道経路と、ユーザの移動速度に基づいて、移動時間を求めてもよい。所要時間が許容範囲であると判断された場合ステップS313、サーバ200は、次に、ユーザの現在位置と、移動経路、寄り道経路との位置関係を判定するステップS314。この時点で抽出されたガイド情報がユーザに提示されることは確定したことになるから、サーバ200はガイド情報の提示履歴に、提示時刻や情報を提示した端末の情報などを記録する。ガイド情報が提示された当初は、移動経路、寄り道経路の分岐に至っていない場合がある。このような場合、即ち現在位置が移動経路上、寄り道経路上のいずれにも該当する場合には、提示されたガイド情報をユーザが利用しようとしているのか否かをサーバ200は判断できないため、そのままガイド情報提示処理を終了する。この場合、寄り道経路のデータは削除されてはいないから、案内画面には、移動経路、寄り道経路の双方が表示される図8のステップS350。これに対し、現在位置が移動経路上にはなく、寄り道経路上にいる場合には、図7bで説明した通り、ユーザは提示されたガイド情報に従って、移動しようとしていると判断される。従って、サーバ200は、移動経路のリルート処理を行うステップS315。つまり、ガイド情報で示した設定地点から、次の予定の目的地までの経路を探索し、これを従前の移動経路に代えてユーザに提示する。ユーザが設定場所をまだ訪問していない場合にはステップS316、ガイド情報提示処理を終了する。これに対し、ユーザが設定場所を訪問した後はステップS316、設定場所と同一ジャンルのガイド情報を削除するステップS317。これによって、図7bにおいて地点a,bがハッチング無しの表示に切り替わったように、同一ジャンルの情報が繰り返しユーザに提供されることを回避できる。同一ジャンルの情報であっても、繰り返し欲するユーザがいることも考慮して、ステップS317の処理をユーザの指定等に応じて省略可能としてもよい。現在位置が寄り道上にない場合にはステップS314、サーバ200は、寄り道経路に対応したガイド情報は不要と判断し、このガイド情報を削除するステップS318。この結果、先に図7cに示したように、ガイド情報の設定場所である地点cは、ハッチング無しの表示、即ちガイド情報と無関係の地点の表示に切り替えられる。また、この地点に対する寄り道経路も消去される。ステップS313で、所要時間が許容範囲を超えていると判断された場合も、サーバ200は上記処理を行うステップS318。実施例のガイド情報提示処理では、ステップS317、S318において、ガイド情報を削除する例を示した。ガイド情報は、情報ボックスから完全に削除するようにしてもよいし、情報ボックスの優先度のデータを、削除に書き換える方法を採っても良い。後者の場合には、サーバ200は、削除が付された情報を除いてガイド情報を抽出すればよい。後者の態様では、ガイド情報は見かけ上、削除されるものの、優先度のデータを書き換えることにより、容易に再度、利用可能となる利点がある。また、ガイド情報等の削除に代えて、ガイド情報の優先度を低下させる処理を行ってもよい。この場合、例えば、サーバ200は、優先度の高い情報からユーザに提供すべきガイド情報が得られなかった場合にのみ、優先度の低いガイド情報を提供すればよい。図10は汎用情報出力処理のフローチャートである。スケジュールガイド処理のステップS330に相当する処理である。ここでは、汎用情報は音声出力を伴うものであるとする。サーバ200は、まず、音声情報を出力中であるか否かを判断するステップS331。音声情報出力中には、更に音声を伴う汎用情報を出力する必要性、可能性はないからである。音声情報は、ガイド情報、汎用情報いずれであってもよい。音声情報を出力していない場合にはステップS331、サーバ200は、汎用情報DB202から情報リストを取得するステップS332。図中に情報リストの例を示した。この例では、ニュース1、ニュース2、広告1等が登録されており、それぞれの音声出力の所要時間が記録されている。次に、サーバ200は、音声データを含むガイド情報を情報ボックスから抽出するステップS333。そして、現在位置、ガイド情報の設定場所、移動速度に基づいて、ガイド情報の音声データを出力するまでの余裕時間を推定するステップS334。ガイド情報の設定場所が移動経路上にある時には、まず、現在位置から設定場所までの距離を求め、これを移動速度で除することによって、音声出力までの余裕時間を求めることができる。ガイド情報の設定場所が移動経路からそれている時には、移動経路上で設定場所に最も近い地点を求め、現在位置からこの地点までの距離に基づいて余裕時間を求めればよい。ガイド情報を出力すべき地点を予め移動経路上に設定しておいてもよい。サーバ200は、このようにして求められた余裕時間に基づき、次の条件に従って、音声出力すべき汎用情報を選択するステップS335。条件1により、サーバ200は、ユーザへの提供回数が最小の情報を優先する。汎用情報は、ニュース、広告等の情報なので、ユーザに何度も繰り返し提供しても差し支えない。ただし、汎用情報は、提供回数の偏りなく平均して提供されることが好ましい。ユーザへの提供回数が最小の情報を優先的に選択するようにすれば、汎用情報を提供する際の偏りを抑制することが可能となる。条件1によれば、例えば、ニュース1の提供回数が0回、ニュース2、広告1の提供回数が1回以上の場合には、ニュース1が優先されることになる。全汎用情報の提供回数が同一である場合には、回数による優劣なく、他の条件に従って情報の選択が行われる。条件2により、サーバ200は、汎用情報の音声出力時間が、余裕時間以下となる情報を選択する。こうすることにより、汎用情報の末尾が切れるなどの支障なく、ガイド情報の音声出力が始まるまでの空白時間内でおさまるように、汎用情報を出力することができる。条件2は、情報を選択する際に、必須の条件として扱っても良いし、単に選択の優先度を決定する条件として扱っても良い。後者の例によれば、余裕時間内に収まる汎用情報がない場合には、条件2を考慮に入れずに汎用情報の選択が行われることとなり、この結果、末尾が切れて汎用情報が出力されることになる。条件3により、サーバ200は、条件1、2を満たす中で音声出力時間が最長のものを選択する。つまり、条件3は、条件1、2に該当する出力情報が複数存在する場合に適用される絞り込み条件である。最長のものを選択するのは、一般に出力時間が長いものほど、余裕時間内で出力できる可能性が低い点を考慮したものである。この条件で選択することにより、音声出力時間が長い汎用情報の出力回数が少なくなるのを緩和することができる。汎用情報を選択するための条件1~3は、上述の例に限らず、種々の設定が可能である。上述した条件の一部を省略してもよいし、この他の条件を加えても良い。以上で説明した実施例のガイド情報提供システムによれば、スケジュールを登録すると、そのスケジュールに関連した情報をサーバ200が自動的に収集するため、ユーザによる情報収集の負荷を軽減することができる。また、スケジュール実行中の情報収集に比較し、情報の収集に対する時間的な制約が少ないため、サーバ200は有用かつ最新の情報を広範囲に収集することができる利点もある。この過程において、ガイド情報提供システムは、スケジュールによる時間的制約の範囲内でユーザが活用可能な情報を収集するため、活用できない無用な情報をユーザに提供することが回避され、有用な情報を効率的に提供することが可能となる。更に、実施例のガイド情報提供システムは、こうして収集された情報の中から、ユーザの現在位置に応じて、ユーザに有用性の高い情報を選択して提供することも可能であり、情報の有効活用を促進することができる。D.変形例:実施例では、スケジュールの実行前に収集した情報を活用する例を示した。ガイド情報提供システムは、スケジュールガイド処理の過程で、情報収集を並行して行うようにしてもよい。以下では、変形例として、情報収集を並行して行う場合の処理例を示す。図11は変形例におけるガイド情報の提供例を示す説明図である。ユーザが車両で移動する場合を例示した。車両に搭載されたカーナビゲーション装置が端末100として機能する。図の例では、A地点からE地点に移動するスケジュールがサーバ200に登録されているものとする。サーバ200は、このスケジュールに従って、ガイド情報Cおよびガイド情報Dを取得する。この例では、ガイド情報Dは四季に応じて4通り用意されている場合を例示した。このような場合、サーバ200は、全季節の情報を取得してもよいし、スケジュールに該当する季節の情報のみを取得してもよい。ガイド情報C、Dは、それぞれ移動経路から若干、離れた名所等の情報である。変形例では、これらの情報を、移動経路上の地点C、Dに対応づけて格納しておくものとした。こうすることにより、ユーザが地点C、Dに到達した時点で、ガイド情報C、Dを流せば良いため、ガイド情報を提供するタイミングを比較的容易に決定できる利点がある。このように情報を提供する場所としてガイド情報に対応づけられている地点を以下では情報提供位置と呼ぶ。ユーザは、出発する際に、サーバ200に収集されている情報をダウンロードする。端末100としてのカーナビゲーション装置は、この情報に基づいて経路案内をするとともに、ユーザがC地点、D地点に到達すると、収集されていたガイド情報をユーザに提供する。端末100は、この他、リアルタイム情報も随時、取得する。リアルタイム情報とは、スケジュール実行時に入手してこそ意味のある情報である。図の例では、区間Bの渋滞情報を取得する例を示した。端末100は、取得したリアルタイム情報を適宜、ユーザに提供する。図12は変形例におけるスケジュールガイド処理のフローチャートである。端末100が実行する処理である。この処理を開始すると、端末100は、スケジュールデータ、経路探索結果、ガイド情報をサーバ200からダウンロードするステップS500。そして、現在位置、時刻を入力しステップS502、リアルタイム情報を取得するステップS504。リアルタイム情報の取得タイミングは、図示した例に限らず、種々のタイミングを採り得る。そして、端末100は、情報提供位置に到達している場合にはステップS506、ガイド情報およびリアルタイム情報を提供するステップS508。リアルタイム情報の場合には、取得した時点で提供するようにしてもよい。端末100は、以上の処理を、目的地に到達するまで繰り返し実行するステップS510。変形例のスケジュールガイド処理によれば、サーバ200が予め収集したガイド情報と、リアルタイム情報とを併用することができる。事前に収集したガイド情報については、一括ダウンロードされているため、端末100がサーバ200と通信不能であっても、支障なくユーザに提供することが可能である。一方、渋滞情報のようにスケジュール実行時にしか分からない情報はリアルタイム情報として取得することにより、事前に収集しておくことができない情報を補うことができ、さらに有用性の高い情報をユーザに提供することが可能となる。また、通信するのはリアルタイム情報のみで済むため、通信負荷が軽くなるという利点もある。変形例では、サーバ200が収集した情報を出発時にダウンロードする例を示したが、実施例と同様、移動中にサーバ200から適宜、ガイド情報を取得する構成を採ることも可能である。かかる構成を採る場合には、リアルタイム情報もサーバ200が取得した上で、端末100に提供してもよい。このようにサーバ200を経由する構成では、サーバ200で情報の要否を判定できるため、端末100で処理する場合よりも複雑な処理を適用可能であり、より有用性の高い情報を効率的にユーザに提供することが可能となる利点がある。また、変形例のように、カーナビゲーション装置を端末として用いる場合など、端末が十分な記憶容量、処理速度を有する場合には、端末に地図DB、経路案内部、情報提供制御部を備えてもよい。こうすることにより、サーバとの通信負荷を軽減することができるメリットがある。以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。"