JP2012194880A - 情報提供方法、情報提供装置及び情報提供プログラム - Google Patents

Abstract

【課題】適切なタイミングで、タクシーの空き台数をユーザに通知する。
【解決手段】ユーザの現在位置データを取得し（ステップＳ５０）、ユーザの到着駅をユーザＩＤと対応付けて記憶する到着駅ＤＢと、現在位置データとに基づいて、ユーザが到着駅に到着する到着予測時刻を算出し（ステップＳ５２）、現在の時刻が、到着予測時刻の所定時間前になった段階で、到着駅近傍におけるタクシーの空き台数を取得し、予約条件リストに基づいて、タクシーの空き台数が予約条件の台数よりも多いか否かを判断し、少なかった場合に、ユーザに対して、タクシーの空き台数を通知することとする（ステップＳ５８）。
【選択図】図２１

Description

本件は、情報提供方法、情報提供装置及び情報提供プログラムに関する。

従来、交通手段（例えばタクシー）の配車予約を事前に登録された条件（予約曜日や予約時間、入場駅、配車駅、行先など）に基づいて自動的に行うシステムがある（例えば、特許文献１参照）。この特許文献１に記載のシステムでは、鉄道の自動改札の入出場情報に基づいて、事前に登録された条件に沿った予約が行われる。

特開２００４−１８５４９４号公報

しかしながら、タクシーを予約すると、ユーザは通常の利用料金のほかに予約料金を支払わなければならない。一方、上記特許文献１では、自動改札の入出場情報や事前に登録された条件に基づいて予約が行われる。このため、例えば駅前にタクシーが数多く停車しており、予約が不要な場合であっても、タクシーが自動的に予約されてしまい、ユーザにとって無駄な出費が発生するおそれがある。

このような場合、ユーザは、タクシーの予約をするか否かを適切なタイミングで判断する必要がある。

そこで本件は上記の課題に鑑みてなされたものであり、適切なタイミングで交通手段の空き状況に関する情報を提供することが可能な情報提供方法、情報提供装置及び情報提供プログラムを提供することを目的とする。

本明細書に記載の情報提供方法は、コンピュータが、交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する情報提供方法であって、ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信する受信工程と、前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信工程で受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出する算出工程と、現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得する取得工程と、予め設定された前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得工程で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断する判断工程と、前記判断工程の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する通知工程と、をコンピュータが実行する情報提供方法である。

本明細書に記載の情報提供装置は、交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する情報提供装置であって、ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信する受信部と、前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信部が受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出する算出部と、現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得する取得部と、予め設定した前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得部で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断する判断部と、前記判断部の判断の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する通知部（４９）と、を含む情報提供装置である。

本明細書に記載の情報提供プログラムは、交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する処理をコンピュータに実行させる情報提供プログラムであって、ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信し、前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信する処理で受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出し、現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得し、予め設定した前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得する処理で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断し、前記判断する処理の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する処理、を前記コンピュータに実行させる情報提供プログラムである。

本明細書に記載の情報提供方法、情報提供装置及び情報提供プログラムは、適切なタイミングで交通手段の空き状況に関する情報を提供することができるという効果を奏する。

一実施形態に係るタクシー予約システムの構成を概略的に示す図である。 図２（ａ）は、ユーザ端末のハードウェア構成図であり、図２（ｂ）は、車載端末のハードウェア構成図である。 図３（ａ）は、タクシー会社端末のハードウェア構成図であり、図３（ｂ）は、センター処理装置のハードウェア構成図である。 ユーザ端末の機能ブロック図である。 図５（ａ）は、車載端末の機能ブロック図であり、図５（ｂ）は、タクシー会社端末の機能ブロック図である。 センター処理装置の機能ブロック図である。 車両ＤＢを示す図である。 駅ＤＢを示す図である。 各社待機情報ＤＢを示す図である。 図１０（ａ）は、経路探索部で探索される経路の一例を示す図であり、図１０（ｂ）は、経路候補データを示す図である。 経路候補ＤＢを示す図である。 到着駅ＤＢを示す図である。 図１３（ａ）は、ユーザの現在位置データを示す図であり、図１３（ｂ）は、到着予測時刻ＤＢを示す図である。 接近検知結果ＤＢを示す図である。 予約条件リストを示す図である。 全社待機情報ＤＢを示す図である。 ユーザ情報ＤＢを示す図である。 予約結果データを示す図である。 経路候補・到着駅の登録処理を示すフローチャートである。 図２０（ａ）は、予約条件の登録処理を示すフローチャートであり、図２０（ｂ）は、駅毎の待機数情報の登録処理を示すフローチャートである。 タクシー予約・通知処理を示すフローチャートである。 図２１のステップＳ５４の具体的処理を示すフローチャートである。 図２１のステップＳ５８の具体的処理を示すフローチャートである。 図２１のステップＳ６２の具体的処理を示すフローチャートである。

以下、一実施形態について、図１〜図２４に基づいて詳細に説明する。図１には、一実施形態に係るタクシー予約システム１００の構成が概略的に示されている。タクシー予約システム１００は、交通機関としての鉄道を利用するユーザに対して、鉄道の利用を終了する予定の地点（到着駅）に到着した後に利用する別の交通手段（本実施形態ではタクシー）の予約をしたり、タクシーの情報を提供したりするシステムである。図１に示すように、タクシー予約システム１００は、複数のユーザ端末１０と、複数の車載端末２０と、複数のタクシー会社端末３０と、情報処理装置としてのセンター処理装置４０と、を備える。これら各装置は、インターネット等のネットワーク７０を介して接続されている。

ユーザ端末１０は、例えば、携帯電話やスマートフォン、ＰＤＡ（Personal Digital Assistant）などの移動端末であり、ユーザの位置情報を取得したり、センター処理装置４０と通信したりすることが可能な端末であるものとする。また、ユーザ端末１０は、ユーザが移動経路の検索や選択を行ったり、タクシーの予約条件の入力を行うのにも用いられる。

図２（ａ）には、ユーザ端末１０のハードウェア構成図が示されている。この図２（ａ）に示すように、ユーザ端末１０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ここではＨＤＤ（Hard Disk Drive））１９６、ネットワークインタフェース１９７、入力部１９１、表示部１９３、絶対位置情報取得部１８０等を備えている。ユーザ端末１０の構成各部は、バス１９８に接続されている。ユーザ端末１０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラムをＣＰＵ１９０が実行することにより、図４の各部の機能が実現される。なお、図４の機能ブロック図の詳細については後述する。入力部１９１は、キーボードやタッチパネルなどを含み、表示部１９３は、液晶ディスプレイ（ＬＣＤ）や有機ＥＬディスプレイなどを含む。絶対位置情報取得部１８０は、ＧＰＳ衛星との通信により、ユーザ端末１０（及びユーザ端末１０を保有するユーザ）の絶対位置（緯度、経度、高度で表される位置）の情報を取得する。

車載端末２０は、タクシーに搭載される端末であり、タクシーの現在位置と運行情報（運行状況）を取得して、タクシー会社端末３０に通知する、この車載端末２０は、図２（ｂ）に示すようなハードウェア構成を有する。具体的には、車載端末２０は、ＣＰＵ２９０、ＲＯＭ２９２、ＲＡＭ２９４、記憶部（ＨＤＤ）２９６、ネットワークインタフェース２９７、入力部２９１、表示部２９３、絶対位置情報取得部２８０、運行状況取得部２９５等を備える。運行状況取得部２９５は、タクシーの運転手が入力する車両の運行状況（実車、空車、配車（予約）、回送、休憩など）を取得する。その他各部の構成は、図２（ａ）のユーザ端末と同様であるが、車載端末２０では、ＣＰＵ２９０がプログラムを実行することにより、図５（ａ）の各部の機能を実現する。なお、図５（ａ）の機能ブロック図の詳細については後述する。

タクシー会社端末３０は、ＰＣ（Personal Computer）等の情報処理装置を含み、各タクシー会社に所属するタクシーに搭載された車載端末２０から送信される情報を集計する。タクシー会社端末３０のハードウェア構成は、図３（ａ）に示すようになっている。具体的には、タクシー会社端末３０は、ＣＰＵ３９０、ＲＯＭ３９２、ＲＡＭ３９４、記憶部（ＨＤＤ）３９６、ネットワークインタフェース３９７、入力部３９１、表示部３９３等を備えている。タクシー会社端末３０では、ＣＰＵ３９０がプログラムを実行することにより、図５（ｂ）の各部の機能を実現する。なお、図５（ｂ）の機能ブロック図の詳細については後述する。

センター処理装置４０は、複数のタクシー会社端末３０で集計された情報を更に集計する。また、センター処理装置４０は、ユーザ端末１０から入力されたタクシーの予約条件や、移動経路（経路候補）、ユーザ（ユーザ端末１０）の絶対位置情報などに基づいて、ユーザの到着駅でのタクシー予約を行ったり、到着駅における空車状況（例えば空車台数）をユーザ端末１０に対して通知したりする。センター処理装置４０は、図３（ｂ）に示すようなハードウェア構成を有している。具体的には、センター処理装置４０は、ＣＰＵ４９０、ＲＯＭ４９２、ＲＡＭ４９４、記憶部（ＨＤＤ）４９６、ネットワークインタフェース４９７、入力部４９１、表示部４９３、可搬型記憶媒体用ドライブ４９９等を備えている。センター処理装置４０では、ＲＯＭ４９２あるいはＨＤＤ４９６に格納されているプログラム（情報提供プログラム）、或いは可搬型記憶媒体用ドライブ４９９が可搬型記憶媒体４９５から読み取ったプログラム（情報提供プログラム）をＣＰＵ４９０が実行することにより、図６の各部の機能が実現される。

次に、図４〜図６に基づいて、ユーザ端末１０、車載端末２０、タクシー会社端末３０、及びセンター処理装置４０の各ＣＰＵ（１９０，２９０，３９０，４９０）によって実現される機能について、詳細に説明する。

図４は、ユーザ端末１０のＣＰＵ１９０によって実現される機能ブロック図である。この図４に示すように、ユーザ端末１０では、ＣＰＵ１９０により、探索条件入力部１１、探索結果取得部１２、経路候補入力部１３、現在位置データ入力部１４、予約条件入力部１５、通知受信部１６、及び予約選択部１７としての機能が実現されている。

探索条件入力部１１は、ユーザが入力部１９１を介して入力した探索条件を取得し、センター処理装置４０（経路探索部４１）に対して入力する。探索結果取得部１２は、探索条件入力部１１が入力した探索条件に基づいてセンター処理装置４０（経路探索部４１）が探索した経路候補を取得して、表示部１９３に表示する。

経路候補入力部１３は、ユーザ端末１０の表示部１９３に表示された経路候補を見たユーザが、入力部１９１を介して選択した経路（経路候補）を取得して、センター処理装置４０（経路候補登録部４２）に対して入力する。

現在位置データ入力部１４は、絶対位置情報取得部１８０が取得したユーザ端末１０（すなわちユーザ端末１０を保有するユーザ）の位置を取得し、センター処理装置４０（到着時刻予測部４４、接近検知部４５及び予約部５０）に対して入力する。

予約条件入力部１５は、ユーザが入力部１９１を介して入力した、タクシーの予約条件（駅前に存在する空きのタクシーの数が何台以下の場合に予約を行うかを駅ごとに定めた条件）を取得する。そして、予約条件入力部１５は、取得した予約条件をセンター処理装置４０（予約条件設定部５１）に対して入力する。

通知受信部１６は、センター処理装置４０（通知部４９）から通知される情報を受信して、ユーザ端末１０の表示部１９３に表示する。

予約選択部１７は、ユーザが入力部１９１を介してタクシーの予約をすることを選択したときに、当該予約をする旨をセンター処理装置４０（予約部５０）に通知する。

図５（ａ）は、車載端末２０のＣＰＵ２９０によって実現される機能ブロック図である。この図５（ａ）に示すように、車載端末２０では、ＣＰＵ２９０により、車両情報提供部２１としての機能が実現されている。

車両情報提供部２１は、絶対位置情報取得部１８０が取得した車載端末２０（車載端末２０を搭載するタクシー）の位置を取得する。また、車両情報提供部２１は、運行状況取得部２９５が取得したタクシーの運行状況（実車、空車、配車（予約）、回送、休憩など）を取得する。そして、車両情報提供部２１は、タクシー会社端末３０（車両情報取得部３１）に対して、取得した情報を提供（出力）する。

図５（ｂ）は、タクシー会社端末３０のＣＰＵ３９０によって実現される機能ブロック図である。この図５（ｂ）に示すように、タクシー会社端末３０では、ＣＰＵ３９０により、車両情報取得部３１、待機情報取得部３２としての機能が実現されている。なお、図５（ｂ）には、ＨＤＤ３９６等に格納される車両データベース（以下、単に「ＤＢ」と記述する）３３、駅ＤＢ３４、各社待機情報ＤＢ３５も図示されている。

車両情報取得部３１は、車載端末２０の車両情報提供部２１から提供された車両情報（位置及び運行状況）を取得する。なお、各タクシー会社端末３０では、各タクシー会社に所属するタクシーに搭載された車載端末２０から車両情報を取得することになる。なお、車両情報取得部３１は、取得した車両情報を、車両ＤＢ３３に格納する。車両ＤＢ３３には、図７に示すように、タクシーの車両ＩＤと、車両情報を取得した時刻と、当該時刻におけるタクシーの位置情報（緯度経度情報）と、タクシーの運行情報（運行状況）と、が対応付けて格納される。

図５（ｂ）に戻り、待機情報取得部３２は、車両ＤＢ３３の情報と、駅ＤＢ３４の情報と、に基づいて、各駅の周辺における空車台数を集計し、各社待機情報ＤＢ３５に格納する。駅ＤＢ３４は、図８に示すように、駅名と、駅の位置情報（緯度経度情報）と、タクシー乗り場の名称と、駅前領域の設定値とを、関連付けて格納する。この駅ＤＢ３４は、予め管理者等により用意されたものであるものとする。各社待機情報ＤＢ３５には、図９に示すように、駅名と、更新時刻と、空車台数（各駅の駅前領域内に存在する空車台数）と、が対応付けて格納されている。

図６は、センター処理装置４０のＣＰＵ４９０によって実現される機能ブロック図である。この図６に示すように、センター処理装置４０では、ＣＰＵ４９０により、経路探索部４１、経路候補登録部４２、到着駅検索部４３、受信部及び算出部としての到着時刻予測部４４、接近検知部４５、予約条件検索部４６、取得部としての待機数検索部４７、判断部４８、通知部４９、予約部５０、予約条件設定部５１、待機情報収集部５２としての機能が実現されている。なお、図６には、ＨＤＤ４９６等に格納される経路候補ＤＢ６０、駅ＤＢ６１、閾値テーブルとしての予約条件リスト６２、終了予定地点テーブルとしての到着駅ＤＢ６３、到着予測時刻ＤＢ６４、接近検知結果ＤＢ６５、全社待機情報ＤＢ６６、ユーザ情報ＤＢ６７についても図示されている。

経路探索部４１は、探索条件入力部１１から入力された検索条件（乗車駅と、目的地を含む条件）に基づいて、経路候補を探索する。この探索の結果、図１０（ａ）に示すような複数通りの経路が探索される場合もある。図１０（ｂ）は、図１０（ａ）の探索結果を表で示した経路候補データである。この図１０（ｂ）に示すように、経路候補データは、移動経路ＩＤ、路線名、乗車駅、到着駅、出発時刻、到着時刻等を含んでいる。経路探索部４１は、この経路候補データをユーザ端末１０の探索結果取得部１２に送信する。探索結果取得部１２は、受信した経路候補データを表示部１９３上に表示する。図１０（ｂ）の場合、ユーザは、経路１−１と１−２の組み合わせ、又は経路２−１と２−２の組み合わせのいずれかの経路を経路候補として選択することができる。

経路候補登録部４２は、経路候補入力部１３から入力された経路候補を経路候補ＤＢ６０に格納する。図１１には、経路候補データベース６０が示されている。この図１１に示すように、経路候補データベース６０は、ユーザＩＤに関連付けて、選択された経路候補（図１１では経路候補１−１，１−２の組み合わせ）のデータが格納される。

到着駅検索部４３は、各ユーザの経路候補から到着駅を検索し、その到着駅に関する情報を、経路候補ＤＢ６０（図１１）と、駅ＤＢ６１（図８の駅ＤＢ３４と同様）から取得して、到着駅ＤＢ６３を生成する。ここで、到着駅ＤＢ６３には、図１２に示すように、ユーザＩＤと、到着駅と、到着時刻と、駅の位置情報（緯度経度情報）と、駅前領域の設定値と、が格納されている。なお、各ユーザの到着駅は、各ユーザが選択した経路候補の最終到着駅を意味する。

到着時刻予測部４４は、ユーザ端末１０（現在位置データ入力部１４）から入力される現在位置データを取得する。そして、到着時刻予測部４４は、到着駅ＤＢ６３に登録されている到着時刻及び到着駅の位置に対する、現在時刻及びユーザの現在位置データから公共交通機関の運行状況を推定して、到着予測時刻を算出する。ここで、ユーザの現在位置データとしては、図１３（ａ）のようなデータ（ユーザＩＤと時刻と位置情報とが関連付けられたデータ）を、ユーザ端末１０の現在位置データ入力部１４から得ることができる。そして、到着時刻予測部４４は、算出された到着予測時刻と、図１２の到着駅ＤＢ６３の内容を、図１３（ｂ）に示す到着予測時刻ＤＢ６４に登録する。

接近検知部４５は、到着予測時刻ＤＢ６４の内容と、ユーザ端末１０（現在位置データ入力部１４）から入力されるユーザの現在位置データとを接近検知結果ＤＢ６５に登録する。接近検知結果ＤＢ６５は、具体的には、図１４に示すように、ユーザＩＤと、現在時刻と、現在位置情報と、到着駅と、到着駅位置情報と、到着予測時刻と、が対応付けて格納される。また、接近検知部４５は、接近検知結果ＤＢ６５に登録した内容を確認し、ユーザが、到着駅から所定範囲（所定時間で到着する範囲又は所定距離の範囲）まで接近しているか否かを判断する。接近検知部４５は、ユーザが到着駅から所定範囲まで接近していると判断した場合には、予約条件検索部４６及び待機数検索部４７に対してその旨を通知する。

予約条件検索部４６は、予約条件リスト６２から到着駅におけるタクシーの予約条件を検索する。ここで、予約条件リスト６２は、予約条件設定部５１が、ユーザ端末１０（予約条件入力部１５）から入力される予約条件を纏めたリストである。具体的には、図１５に示すように、予約条件リスト６２においては、ユーザＩＤごとに、到着駅と予約取得の閾値とが定められている。例えば、予約条件リスト６２の１行目は、ユーザＩＤが「fuji2taro」であるユーザが到着駅に到着したときに１台未満の空車がある場合（すなわち空車が１台もない場合）にタクシーの予約をセンター処理装置４０に行わせ、空車が１台以上ある場合には、タクシーの予約をセンター処理装置４０に行わせない、という条件である。

待機数検索部４７は、全社待機情報ＤＢ６６を参照して、到着駅におけるタクシーの待機数を検索する。ここで、全社待機情報ＤＢ６６は、前述した各タクシー会社のタクシー会社端末３０で管理されている各社待機情報ＤＢ３５を待機情報収集部５２が収集して纏めたデータベースである。具体的には、全社待機情報ＤＢ６６には、図１６に示すように、タクシー会社名と、駅名と、更新時刻と、空車台数と、が対応付けて登録される。待機数検索部４７では、図１６の全社待機情報ＤＢ６６を検索し、ユーザの到着駅における空車台数を検索し、取得する。

判断部４８は、予約条件検索部で検索されたユーザの到着駅に関する予約条件と、待機数検索部で検索されたユーザの到着駅におけるタクシーの待機数と、に基づいて、タクシーの予約を行うべきか否かを判断する。判断部４８において、タクシーの予約を行うべきと判断された場合には、判断部４８から予約部５０に対してその旨が通知される。また、判断部４８において、タクシーの予約を行うべきと判断されなかった場合には、判断部４８から通知部４９に対してその旨が通知される。

通知部４９は、判断部４８から通知を受けた場合、図１７のユーザ情報ＤＢ６７から、ユーザＩＤに対応するメールアドレスを取得する。そして、通知部４９は、取得したメールアドレスのユーザ端末１０（通知受信部１６）に対して、タクシーの空車台数を通知する。また、通知部４９は、タクシーの予約を行うか否かをユーザに選択させるための情報（画面データ）も、取得したメールアドレスのユーザ端末１０（通知受信部１６）に対して送信する。

予約部５０は、タクシーの予約を行う旨の通知を、ネットワーク７０を介して、各タクシー会社端末３０に送信する。予約部５０は、この通知に対して、最も応答（レスポンス）の早かったタクシー会社を選択し、当該タクシー会社に対してタクシーの予約を行う。この予約を行うに際して、予約部５０は、ユーザ情報ＤＢ６７に格納されているユーザの氏名などをタクシー会社端末３０に通知するものとする。なお、予約の方法は、上記の方法に限らず、例えば、予約部５０は、空車台数の最も多い会社に対して予約を行う旨の通知をするようにしてもよい。また、予約部５０は、抽選等により選ばれた会社に対して予約を行う旨の通知を行うようにしてもよい。また、予約部５０は、所定の順位に従って会社を選択し、予約を行う旨の通知を行うようにしてもよい。

予約部５０において上記のようにタクシーの予約を行った場合、予約部５０は、図１８に示す予約結果データを、通知部４９に対して通知する。通知部４９は、予約結果データをユーザ情報ＤＢ６７から取得可能なメールアドレスのユーザ端末１０（通知受信部１６）に対して送信する。なお、通知受信部１６では当該予約結果を表示部１９３上に表示する。

なお、予約部５０は、タクシーの予約解除も行う。例えば、現在時刻が到着予測時刻になった段階でのユーザの現在位置データに基づいて、ユーザが到着駅を乗り越したと判断できるような場合には、予約部５０は、タクシーの予約を解除する。

次に、本実施形態におけるセンター処理装置４０の処理について、図１９〜図２３に基づいて、詳細に説明する。なお、以下の説明におけるユーザは、ユーザＩＤが「fuji2taro」のユーザであるものとする。

（経路候補・到着駅の登録処理）
図１９は、移動経路の登録処理を示すフローチャートである。この図１９の処理では、ステップＳ１０において、経路探索部４１が、ユーザ端末１０（探索条件入力部１１）から検索条件（乗車駅、目的地、乗車時刻など）が入力されるまで待機する。なお、ユーザは、経路探索部４１が提供する移動経路探索用のアプリケーション上から、検索条件を入力することができる。この場合、経路探索部４１に検索条件が入力された段階で、ステップＳ１２に移行する。

ステップＳ１２では、経路探索部４１は、利用可能な移動経路を検索する。ここでは、経路探索部４１は、例えば、図１０（ｂ）に示すような２通りの移動経路を含む経路候補データを取得したものとする。

次いで、ステップＳ１４では、経路探索部４１が、検索結果（図１０（ｂ）の経路候補データ）を探索結果取得部１２に対して通知する。なお、ユーザ端末１０では、探索結果取得部１２が、当該通知内容を表示部１９３上に表示する。

次のステップＳ１６では、経路候補登録部４２は、入力部１９１を介してユーザが選択した経路候補が経路候補入力部１３から入力されるまで、待機する。この場合、経路候補登録部４２は、経路候補入力部１３から経路候補が入力された段階で、ステップＳ１８に移行する。

ステップＳ１８に移行すると、経路候補登録部４２は、経路候補を経路候補ＤＢ６０（図１１参照）上に登録する。

次いで、ステップＳ２０では、到着駅検索部４３が、経路候補ＤＢ６０（図１１）を参照して、ユーザの到着駅を検索し、到着駅ＤＢ６３（図１２）上に登録する。

以上のようにして、経路候補の経路候補ＤＢ６０への登録及び到着駅の到着駅ＤＢ６３への登録が完了する。なお、図１９の処理は、あるユーザから検索条件が入力されるたびに、繰り返し実行されることになる。

（予約条件の登録処理）
次に、予約条件の登録処理について、図２０（ａ）のフローチャートに沿って説明する。この予約条件の登録処理は、予約条件設定部５１が実行する処理である。

図２０（ａ）の処理では、予約条件設定部５１は、まずステップＳ３０において、ユーザが入力部１９１を介して入力した予約条件が、予約条件入力部１５から入力されるまで待機する。なお、ユーザは、予約条件設定部５１が提供する予約条件入力用のアプリケーション上から、予約条件を入力できるものとする。予約条件設定部５１は、予約条件入力部１５から予約条件の入力があった後、ステップＳ３２に移行する。

ステップＳ３２に移行すると、予約条件設定部５１は、予約条件を予約条件リスト６２（図１５参照）に登録する。

その後は、いずれかのユーザ端末１０から予約条件が入力されるたびに、予約条件が予約条件リスト６２に登録されることとなる。

（駅毎の待機数情報の登録処理）
次に、駅毎の待機数情報の登録処理について、図２０（ｂ）のフローチャートに沿って説明する。この駅毎の待機数情報の登録処理は、タクシー会社端末３０の車両情報取得部３１と、待機情報取得部３２が実行する処理である。

図２０（ｂ）の処理では、まずステップＳ４０において、車両情報取得部３１が、各車載装置２０の車両情報提供部２１から、車両（タクシー）の現在位置、運行状況を取得する。車両情報取得部３１は、取得した情報を車両ＤＢ３３（図７）に格納する。

次いで、ステップＳ４２では、待機情報取得部３２が、車両が駅前に存在しているか否かを判断する。この場合、車両ＤＢ３３と駅ＤＢ３４（図８）とを用いて、車両が駅前に存在しているか否かを判断する。この場合、駅ＤＢ３４には駅の位置（緯度経度）と駅前領域の設定値（例えば半径１００ｍ）が設定されている。したがって、待機情報取得部３２は、ステップＳ４０で現在位置等を取得した車両（タクシー）が駅前領域の範囲内に入っているか否かについて判断する。ここでの判断が否定された場合には、図２０（ｂ）の全処理を終了するが、ここでの判断が肯定された場合には、ステップＳ４４に移行する。

ステップＳ４４に移行した場合、待機情報取得部３２は、駅前に存在している車両の運行状況が「空車」であるか否かを判断する。ここでの判断が否定された場合には、図２０（ｂ）の全処理を終了するが、ここでの判断が肯定された場合には、ステップＳ４６に移行する。

ステップＳ４６に移行した場合、待機情報取得部３２は、駅前に存在しており、かつ空車である車両を空車車両として集計し、各社待機情報ＤＢ３５（図９）の空車台数を変更する。

なお、図２０（ｂ）の処理は、各車両について、所定タイミングで繰り返し実行される。この場合、前回空車車両であった車両が、空車車両でなくなった場合には、図９の空車台数を減らすように変更することとしてもよい。また、所定タイミングで、図９のデータベースをリセットし、新たに空車車両を集計するようにしてもよい。

なお、センター処理装置４０の待機情報収集部５２では、適宜、タクシー会社端末３０で収集された情報（各社待機情報ＤＢ３５）を収集して、全社待機情報ＤＢ６６（図１６）を更新しているものとする。

（タクシー予約・通知処理）
次に、タクシー予約・通知処理について、図２１〜図２４のフローチャートに沿って説明する。このタクシー予約・通知処理は、センター処理装置４０において実行される処理である。なお、本処理が開始される時点においては、ユーザ（ユーザＩＤがfuji2taroであるユーザ）が、鉄道を利用している状態にあるものとする。また、本処理は、図１０（ａ）に示すように、到着駅から目的地までの経路をタクシーで移動する場合にのみ実施される処理である。

図２１の処理では、まずステップＳ５０において、到着時刻予測部４４が、ユーザ（fuji2taro）の現在位置データ（図１３（ａ）参照）をユーザ端末１０の現在位置データ入力部１４から取得する。なお、このステップＳ５０を実行するタイミングは、到着駅ＤＢ６３の到着時刻の所定時間前（例えば１０分や２０分前など）とする。

次いで、ステップＳ５２では、到着時刻予測部４４が、到着予測時刻を算出し、到着予測時刻データベース（図１３（ｂ）参照）に登録する。この場合、到着時刻予測部４４は、到着駅ＤＢ６３に登録されている到着時刻及び到着駅の位置に対する、現在時刻及びユーザ（fuji2taro）の現在位置データから公共交通機関の運行状況を推定して、到着予測時刻を算出する。

次いで、ステップＳ５４では、接近検知部４５が、接近判定処理を実行する。この接近判定処理では、接近検知部４５は、図２２のフローチャートに沿った処理を実行する。

図２２の処理では、まずステップＳ７０において、接近検知部４５が、ユーザ（fuji2taro）の現在位置データを取得するとともに、到着予測時刻ＤＢ６４から、到着駅への到着予測時刻を取得する。

次いで、ステップＳ７４では、接近検知部４５が、到着予測時刻と現時刻の差が閾値以上であるか否かを判断する。ここでの判断が肯定された場合には、図２１のステップＳ５６に移行する。一方、ここでの判断が否定された場合、すなわち、到着予測時刻と現時刻の差が閾値未満である場合には、ステップＳ７６に移行して、接近検知部４５は、到着駅に接近したと判定した後、図２１のステップＳ５６に移行する。

図２１に戻り、ステップＳ５６では、接近検知部４５が、鉄道を利用しているユーザ（fuji2taro）が到着駅に接近したか否かを判断する。ここでの判断が否定された場合には、ステップＳ５４に戻るが、ここでの判断が肯定された場合には、ステップＳ５８に移行する。

ステップＳ５８に移行すると、予約・通知処理が実行される。このステップＳ５８では、具体的には、図２３のフローチャートに沿った処理が実行されることになる。

図２３の処理では、まず、ステップＳ９０において、待機数検索部４７が、到着駅の空車台数を検索する。この場合、ユーザ（fuji2taro）は、Ｃ駅を到着駅としているので、Ｃ駅における全社の空車台数を、全社待機情報ＤＢ６６から検索し、取得する。なお、待機数検索部４７は、取得した空車台数を判断部４８に対して送信する。

次いで、ステップＳ９２では、予約条件検索部４６が、予約条件リスト６２（図１５）を用いて、ユーザ（fuji2taro）の到着駅における予約条件を検索する。図１５では、ユーザ（fuji2taro）の到着駅（Ｃ駅）における予約条件は、３台となっている。なお、予約条件検索部４６は、取得した予約条件を、判断部４８に対して送信する。

次いで、ステップＳ９４では、判断部４８が、空車台数が予約条件を満たすか否かを判断する。この場合、空車台数が３台未満であった場合には、ステップＳ９４の判断が肯定され、３台以上であった場合には、ステップＳ９４の判断が否定されることになる。

ステップＳ９４の判断が肯定されて、ステップＳ９６に移行すると、予約部５０は、タクシーの配車予約を行い、予約結果を通知部４９に通知する。そして通知部４９は、当該予約結果（予約結果データ（図１８））を、ユーザ端末１０（通知受信部１６）に対して通知する。通知受信部１６は、ユーザ端末１０の表示部１９３に予約結果データを表示する。その後は、図２１のステップＳ６０に移行する。

一方、ステップＳ９４の判断が否定されて、ステップＳ９８に移行すると、通知部４９は、到着駅の空車台数をユーザ端末に通知する。なお、この通知においては、空車台数のみならず、タクシーの予約を行うか否かの判断を促す表示（「予約する」ボタンと「予約しない」ボタンの表示など）を行うこととする。

次いで、ステップＳ１００では、予約部５０が、ユーザによって「予約する」ボタンが押されるなどして、予約選択部１７が予約することを選択したか否かを判断する。なお、いずれのボタンも押されずに所定時間が経過した場合には、予約しないことを選択したものとみなす（ステップＳ１００の判断が否定される）。ここでの判断が肯定された場合には、前述したステップＳ９６を経て図２１のステップＳ６０に移行する。一方、ここでの判断が否定された場合には、図２１のタクシー予約・通知処理の全処理を終了する。

図２１に戻り、ステップＳ６０では、予約部５０は、到着予測時刻から所定時間経過するまで待機する。なお、ステップＳ６０に移行するのは、タクシーの予約が行われている場合のみである。その後、到着予測時刻から所定時間経過した時点となった段階でステップＳ６２に移行する。

ステップＳ６２では、予約部５０が予約継続／解除処理を実行する。この処理では、予約部５０は、図２４のフローチャートに沿った処理を実行する。

図２４の処理では、まずステップＳ１０２において、予約部５０が、ユーザ（fuji2taro）の現在位置データを取得する。次いで、ステップＳ１０４では、予約部５０が、ユーザ（fuji2taro）が、到着駅で降車したか否かを判断する。この場合、予約部５０は、現在時刻が到着予測時刻になった段階でのユーザの現在位置データに基づいて、ユーザが到着駅で降車したか否かを判断する。

このステップＳ１０４における判断が否定された場合、すなわち、ユーザ（fuji2taro）が到着駅を乗り越してしまったと判断されるような場合には、ステップＳ１０６に移行する。なお、ステップＳ１０４の判断が肯定された場合には、図２４の全処理を終了するとともに、図２１の全処理も終了する。

ステップＳ１０６に移行した場合、予約部５０は、タクシーの配車予約の解除を行う。このように配車予約を解除するのは、ユーザ（fuji2taro）が乗り越してしまい、タクシーを長時間にわたって待たせてしまうおそれがあるからである。次いで、ステップＳ１０８では、通知部４９が、解除結果をユーザ端末１０の通知受信部１６に通知する。以上のようにして、図２４の全処理が終了すると、図２１の全処理も終了する。

なお、上記のようにタクシーの予約が解除された後は、再度ステップＳ５４以降の処理を行うことで、改めてタクシーの予約を行うようにしてもよい。

以上詳細に説明したように、本実施形態によると、ユーザＩＤと対応づけられたユーザの現在位置データ（図１３（ａ））を取得し（ステップＳ５０）、ユーザの到着駅をユーザＩＤと対応付けて記憶する到着駅ＤＢ６３と、現在位置データとに基づいて、ユーザが到着駅に到着する到着予測時刻を算出し（ステップＳ５２）、現在の時刻が、到着予測時刻の所定時間前になった段階（ステップＳ７４が否定された段階）で、到着駅近傍におけるタクシーの空き台数を取得し（ステップＳ９０）、ユーザが設定した予約条件（タクシーの空き台数に関する閾値）をユーザＩＤと対応付けて記憶した予約条件リスト６２に基づいて、タクシーの空き台数が予約条件の台数よりも多いか否かを判断し（ステップＳ９４）、少なかった場合には、ユーザに対して、タクシーの空き台数を通知する（ステップＳ９８）。これにより、本実施形態では、鉄道を利用するユーザが到着駅近傍に近づいた際に、到着駅のタクシーの空き台数が多ければ、ユーザに対してタクシーの空き台数を通知するので、ユーザがタクシーの予約をすべきか予約する必要が無いかを判断することが可能な適切なタイミングで、タクシーの空き台数をユーザに通知することができる。この場合、到着駅におけるタクシーの空き台数が非常に多く、予約をする必要が無いような状況で、自動的にタクシーの予約を行うことを回避することができる。これにより、ユーザはタクシーの予約料金の無駄な出費を抑制することができる。

また、本実施形態によると、タクシーの空き台数をユーザに対して通知する際に、空き台数とともに、タクシーの予約を行うか否かを選択可能な表示を行い、予約部５０は、ユーザの選択に基づいて、タクシーの予約を行う。したがって、タクシーの空き台数を確認したユーザは、簡易な選択を行うことで、タクシーの予約を行うことが可能となる。これにより、ユーザは到着駅から目的地までの移動がスムーズに行えるようになり、利便性の向上を図ることが可能となる。

また、本実施形態によると、タクシーの空き台数が予約条件の台数より少なかった場合に、予約部５０はタクシーの予約を自動的に実行する。すなわち、予め予約条件を設定しておけば、ユーザは、当該予約条件よりも空き台数が少ないため予約をしなければタクシーに早く乗れないような場合に、タクシーの予約を自動で行うことができる。これにより、ユーザの利便性を向上することができる。

また、本実施形態によると、予約部５０は、タクシーの予約を行った後、到着駅への到着予測時刻から所定時間経過した時点でのユーザの現在位置データに基づいて、ユーザが到着駅を乗り過ごしてしまったか否かを判断する。そして、乗り過ごした場合には、予約部５０が、タクシーの予約を解除することとしている。これにより、タクシーを長時間待たせないようにすることができる。

なお、上記実施形態では、到着駅ＤＢ６３を利用すれば、タクシー会社は駅ごとのタクシー需要を把握することができるので、効率の良い配車を行うことも可能である。この場合、ユーザが、経路探索の際にタクシー利用の有無と必要台数をセンター処理装置４０（例えば、経路候補ＤＢ６０や到着駅ＤＢ６３）に登録しておけば、タクシー会社端末３０では、空車台数情報と必要台数の差分値を計算して、駅毎に必要なタクシーの台数を配車することが可能である。

なお、上記実施形態では、ステップＳ７４のように、到着駅への接近判定を、到着予測時刻と現在の時刻との差に基づいて行う場合について説明したが、これに限られるものではない。例えば、到着駅への接近判定を、到着駅の位置と現在の位置との差（距離）に基づいて行うこととしてもよい。また、例えば、利用する鉄道の種別（各駅停車の普通車、急行列車や特急列車などの速達車などの種別）ごとに、到着駅への接近判定方法を異ならせることとしてもよい。

なお、上記実施形態では、予約条件リスト６２に台数の閾値のみを登録する場合について説明したが、これに限らず、その他の予約条件を登録することとしてもよい。予約条件としては、例えば、小型車の台数の閾値、中型車の台数の閾値や、天候別（例えば雨の日や晴れの日）の台数の閾値などを採用してもよい。

なお、上記実施形態では、ユーザの現在位置データが、ＧＰＳ衛星を利用した絶対位置情報である場合について説明したが、これに限られるものではない。例えば、ユーザの現在位置データは、改札の入出場情報であってもよい。また、ユーザの現在位置データは、ユーザ端末１０が通信可能な、無線ＬＡＮのアクセスポイントの情報や携帯電話の基地局などの情報であってもよい。

なお、上記実施形態では、駅前の範囲を、駅の位置を中心とした所定半径の範囲というように設定する場合について説明したが、これに限らず、駅前の範囲を、駅前の通り、タクシー乗り場の範囲のように設定してもよい。

なお、上記実施形態では、予約条件をユーザが設定する場合について説明したが、これに限らず、予約条件は自動的に設定することとしてもよい。この場合、例えば、大規模な駅では２０台、小規模な駅では３台など、駅の規模に応じて予約条件を決定してもよい。また、予約条件はユーザごとに設定する場合に限らず、全ユーザ共通の予約条件であってもよい。

なお、上記実施形態では、センター処理装置４０内に経路探索部４１が存在している場合について説明したが、これに限られるものではない。例えば、センター処理装置４０では、経路探索部４１の機能を省略して、別のサーバ（Ｗｅｂサーバなど）上で動作する経路探索用のアプリケーションでユーザが検索した経路を取得するようにしてもよい。

なお、上記実施形態では、タクシー会社端末３０を用いる場合について説明したが、これに限らず、タクシー会社端末３０の機能のすべてをセンター処理装置４０に持たせることとしてもよい。

なお、上記実施形態では、空車台数をユーザ端末１０に対して通知する際に、タクシーの予約を行うか否かの判断を促す表示（「予約する」ボタンと「予約しない」ボタンの表示など）を行う場合について説明した。しかしながら、これに限られるものではなく、予約を行うか否かの判断を促す表示を行わなくてもよい。この場合、ユーザは、空車台数に基づいて、タクシー会社に直接電話を掛けて予約を行うこととしてもよい。なお、このような場合には、ユーザ端末１０に対して、空車台数とともに、到着駅近傍のタクシー会社の電話番号を通知することとしてもよい。

また、上記とは逆に、センター処理装置４０の機能をタクシー会社端末３０のそれぞれに持たせることとしてもよい。

なお、上記実施形態では、交通機関が鉄道である場合について説明したが、これに限らず、飛行機、バス、船舶などであってもよい。また、上記実施形態では、交通手段が、タクシーである場合について説明したが、これに限らず、交通手段は、例えば、サイクルシェアリングやカーシェアリングシステムなどであってもよい。

なお、上記実施形態では、交通機関が鉄道で、交通手段も鉄道（例えば指定席を有する鉄道）であってもよい。この場合、例えば、普通列車でターミナル駅に向かって移動している適切なタイミングで、新幹線や特急列車の自由席の空席情報をユーザ端末１０に対して提供するなどすることができる。このようにすることで、ユーザは、自由席に空きが多くあれば、指定席を予約する必要がなくなるため、無駄な出費を抑えることが可能となる。なお、自由席の空席情報は、例えば、指定席券の発券数量と、所定時間内に新幹線や特急列車専用の改札を通過した人数から算出することができる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１） コンピュータが、交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する情報提供方法であって、ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信する受信工程と、前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信工程で受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出する算出工程と、現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得する取得工程と、予め設定された前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得工程で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断する判断工程と、前記判断工程の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する通知工程と、をコンピュータが実行することを特徴とする情報提供方法。
（付記２） 前記通知工程では、前記コンピュータは、前記ユーザに対して、前記空き状況に関する情報とともに、前記交通手段の予約実行の有無に関する選択肢を通知し、前記ユーザによって選択された選択肢の情報に基づいて、前記交通手段の予約を実行する第１予約工程を前記コンピュータが更に実行することを特徴とする付記１に記載の情報提供方法。
（付記３） 前記判断工程の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていないことを示していた場合に、前記交通手段の予約を実行する第２予約工程を前記コンピュータが更に実行することを特徴とする付記１又は２に記載の情報提供方法。
（付記４） 前記交通手段の予約を実行した後、前記到着予定時刻を過ぎた時点での前記ユーザの現在位置に関する情報を取得し、当該現在位置に関する情報に基づいて、前記ユーザが前記交通機関の利用を終了する予定の地点を通り過ぎていると判断できる場合に、前記予約を解除する解除工程を前記コンピュータが更に実行することを特徴とする付記２又は３に記載の情報提供方法。
（付記５） 交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する情報提供装置であって、ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信する受信部と、前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信部が受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出する算出部と、現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得する取得部と、予め設定した前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得部で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断する判断部と、前記判断部の判断の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する通知部と、を含む情報提供装置。
（付記６） 前記通知部は、前記ユーザに対して、前記空き状況に関する情報とともに、前記交通手段の予約実行の有無に関する選択肢を通知し、前記ユーザによって選択された選択肢の情報に基づいて、前記交通手段の予約を実行する第１予約部を更に備える付記５に記載の情報提供装置。
（付記７） 前記判断部の判断の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていないことを示していた場合に、前記交通手段の予約を実行する第２予約部を更に備える付記５又は６に記載の情報提供装置。
（付記８） 前記交通手段の予約を実行した後、前記到着予定時刻を過ぎた時点での前記ユーザの現在位置に関する情報を取得し、当該現在位置に関する情報に基づいて、前記ユーザが前記交通機関の利用を終了する予定の地点を通り過ぎていると判断できる場合に、前記予約を解除する解除部を更に備える付記６又は７に記載の情報提供装置。
（付記９） 交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する処理をコンピュータに実行させる情報提供プログラムであって、ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信し、前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信する処理で受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出し、現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得し、予め設定した前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得する処理で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断し、前記判断する処理の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する処理、を前記コンピュータに実行させる情報提供プログラム。
（付記１０） 前記通知する処理では、前記ユーザに対して、前記空き状況に関する情報とともに、前記交通手段の予約実行の有無に関する選択肢を通知し、前記ユーザによって選択された選択肢の情報に基づいて、前記交通手段の予約を実行する処理を前記コンピュータに更に実行させることを特徴とする付記９に記載の情報提供プログラム。
（付記１１） 前記判断する処理の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていないことを示していた場合に、前記交通手段の予約を実行する処理を前記コンピュータに更に実行させることを特徴とする付記９又は１０に記載の情報提供プログラム。
（付記１２） 前記交通手段の予約を実行した後、前記到着予定時刻を過ぎた時点での前記ユーザの現在位置に関する情報を取得し、当該現在位置に関する情報に基づいて、前記ユーザが前記交通機関の利用を終了する予定の地点を通り過ぎていると判断できる場合に、前記予約を解除する処理を前記コンピュータに更に実行させることを特徴とする付記１０又は１１に記載の情報提供プログラム。

４０ センター処理装置（情報処理装置）
４４ 到着時刻予測部（受信部、算出部）
４７ 待機数検索部（取得部）
４８ 判断部
４９ 通知部
６２ 予約条件リスト（閾値テーブル）
６３ 到着駅ＤＢ（終了予定地点テーブル）

Claims (6)

1. コンピュータが、交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する情報提供方法であって、
   ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信する受信工程と、
   前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信工程で受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出する算出工程と、
   現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得する取得工程と、
   予め設定された前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得工程で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断する判断工程と、
   前記判断工程の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する通知工程と、をコンピュータが実行することを特徴とする情報提供方法。
2. 前記通知工程では、前記コンピュータは、前記ユーザに対して、前記空き状況に関する情報とともに、前記交通手段の予約実行の有無に関する選択肢を通知し、
   前記ユーザによって選択された選択肢の情報に基づいて、前記交通手段の予約を実行する第１予約工程を前記コンピュータが更に実行することを特徴とする請求項１に記載の情報提供方法。
3. 前記判断工程の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていないことを示していた場合に、
   前記交通手段の予約を実行する第２予約工程を前記コンピュータが更に実行することを特徴とする請求項１又は２に記載の情報提供方法。
4. 前記交通手段の予約を実行した後、前記到着予定時刻を過ぎた時点での前記ユーザの現在位置に関する情報を取得し、当該現在位置に関する情報に基づいて、前記ユーザが前記交通機関の利用を終了する予定の地点を通り過ぎていると判断できる場合に、前記予約を解除する解除工程を前記コンピュータが更に実行することを特徴とする請求項２又は３に記載の情報提供方法。
5. 交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する情報提供装置であって、
   ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信する受信部と、
   前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信部が受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出する算出部と、
   現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得する取得部と、
   予め設定した前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得部で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断する判断部と、
   前記判断部の判断の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する通知部と、を含む情報提供装置。
6. 交通機関を利用するユーザに対して、当該交通機関利用後に使用する交通手段に関する情報を提供する処理をコンピュータに実行させる情報提供プログラムであって、
   ユーザの識別子と対応づけられた前記ユーザの現在位置に関する情報を受信し、
   前記ユーザが前記交通機関の利用を終了する予定の地点を前記ユーザの識別子と対応付けて記憶する終了予定地点テーブルと、前記受信する処理で受信した前記ユーザの現在位置に関する情報と、に基づいて、前記ユーザが前記地点に到着する到着予測時刻を算出し、
   現在の時刻が、前記到着予測時刻の所定時間前になった段階で、前記地点近傍における前記交通手段の空き状況を取得し、
   予め設定した前記交通手段の空き状況閾値を記憶した閾値テーブルに基づいて、前記取得する処理で取得された前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示すか否かを判断し、
   前記判断する処理の結果、前記交通手段の空き状況が前記空き状況閾値よりも空いていることを示していた場合に、前記ユーザに対して、前記交通手段の空き状況に関する情報を通知する処理、を前記コンピュータに実行させる情報提供プログラム。

Images