本発明の実施例について以下の順序で説明する。
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の機能ブロックを併せて示した。本実施例では、これらの機能ブロックは、これらの機能を実現するためのCGI(Common Gateway Interface )などで構成されたコンピュータプログラムを情報提供サーバ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からのデータに従って画面表示を行う機能を奏する。本実施例では、ブラウザによって提供される。GPS(Global Positioning System)140は、ユーザの現在位置を検出する。現在位置は、サーバ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が登録されることになる。後者の例によれば、スケジュール関連情報には、全て「移動」に付された関連ID「INFO1」が付されることになる。いずれの態様を採るかは任意に選択可能である。前者の態様を採る場合において、「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はスケジュール・ガイド処理時の表示画面例を示す説明図である。図7(a)は、次の目的地に向かって移動中の画面を表している。この画面では、左側に地図および移動経路が表示され、右上にスケジュール、右下にガイド情報が提示される。本実施例では、情報ボックス・メンテナンス処理(図6)時の画面と類似の画面構成を採用した。ただし、情報ボックス・メンテナンス処理では、右下に、スケジュール関連情報の一覧が表示されるのに対し、スケジュール・ガイド処理では、いずれか選択された情報が提示される点で相違する。以下、スケジュール関連情報のうち、ユーザに提示するよう選択された情報を「ガイド情報」と称する。
図7(a)中の点PPはユーザの現在位置を表している。実線の矢印は次の予定の目的地に至るまでの移動経路を表している。図中のハッチングを付した地点a,b,cは、現在位置付近のスケジュール関連情報の所在地を表している。サーバ200は、この中から、現在位置PPに最も近い地点cを選択し、ガイド情報として、画面の右下に詳細な情報を表示する。また、左側の地図上には破線矢印で示すように現在位置PPから地点cに至るまでの寄り道経路を表示する。ユーザは、この表示画面により、移動経路、寄り道経路、スケジュールおよびガイド情報の内容を一覧することができる。ユーザは、これらの情報を総合的に考慮して、ガイド情報で提供された地点cを訪問するか否かを決定できる。
図7(b)は、ユーザが地点cを訪問すると決めた時の表示画面例である。本実施例では、ユーザが寄り道経路に沿って一定の距離または一定の時間、進行を開始したところで、サーバ200は、ユーザが地点cを訪問するつもりであると判断して図7(b)の画面を表示する。ユーザの移動状況に応じて判断する方法に代えて、またはこのような判断方法と共に、ユーザが端末100を操作して、地点cを訪問する旨をサーバ200に指示する態様をとってもよい。図7(b)の画面では、図中に実線矢印で示すように、寄り道経路が表示される。従前の移動経路は消え、地点cに訪問した後、目的地に向かう経路が再探索されて表示される。端末100がサーバ200と通信できない環境にある場合には、経路の再探索をできないため、従前の移動経路をそのまま継続して表示してもよい。
図の例では、スケジュール関連情報a〜cは「麺類のお店」など、共通のジャンルの情報であるとする。サーバ200は、ユーザが地点cを訪問すると決めた時点で、更に、類似の情報をガイド情報として提供する必要性はないと判断する。従って、共通のジャンルの情報である情報a,cの提供を停止する。この結果、図7(b)の実施例では、地点a,bはハッチングを削除した状態での表示に切り替わる。ユーザが地点cに到達するまで待ってから切り換えるようにしてもよい。また、ユーザが地点cに進行を開始した時点で、一旦、削除した後、地点cの訪問を中断した時点で、再度、ハッチング表示を復活させてもよい。
図7(c)は、ユーザが地点cを訪問しない場合の表示画面例である。本実施例では、ユーザが寄り道経路を採らず、移動経路に沿って一定の距離または一定の時間、進行を開始したところで、サーバ200は、ユーザが地点cを訪問しないつもりであると判断して、図7(c)の画面を表示する。この画面では、地点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)。
これに対し、現在位置が移動経路上にはなく、寄り道経路上にいる場合には、図7(b)で説明した通り、ユーザは提示されたガイド情報に従って、移動しようとしていると判断される。従って、サーバ200は、移動経路のリルート処理を行う(ステップS315)。つまり、ガイド情報で示した設定地点から、次の予定の目的地までの経路を探索し、これを従前の移動経路に代えてユーザに提示する。ユーザが設定場所をまだ訪問していない場合には(ステップS316)、ガイド情報提示処理を終了する。これに対し、ユーザが設定場所を訪問した後は(ステップS316)、設定場所と同一ジャンルのガイド情報を削除する(ステップS317)。これによって、図7(b)において地点a,bがハッチング無しの表示に切り替わったように、同一ジャンルの情報が繰り返しユーザに提供されることを回避できる。同一ジャンルの情報であっても、繰り返し欲するユーザがいることも考慮して、ステップS317の処理をユーザの指定等に応じて省略可能としてもよい。
現在位置が寄り道上にない場合には(ステップS314)、サーバ200は、寄り道経路に対応したガイド情報は不要と判断し、このガイド情報を削除する(ステップS318)。この結果、先に図7(c)に示したように、ガイド情報の設定場所である地点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、経路案内部、情報提供制御部を備えてもよい。こうすることにより、サーバとの通信負荷を軽減することができるメリットがある。
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。