JP2013218414A - タクシーのカード決済システムおよび方法 - Google Patents

Abstract

【課題】タクシーを利用した場合に、利用料金のカード決済を確実に行なうことができるカード決済システムを提供することである。
【解決手段】提案するカード決済システムは、タクシーに設置される決済端末と、外部のサーバとがネットワークを通して接続されるタクシー利用料金のカード決済システムである。前記決済端末は、利用者から指定された前記タクシーの目的地情報を含む目的地電波状態問い合わせ情報を前記サーバに送信し、前記サーバは、前記目的地問い合わせ情報を受信したときに、その目的地の位置情報に対応する電波状態を、位置情報と、各位置における電波状態とを有する電波状態情報ＤＢから取得して、その目的地の電波状態期待値として前記決済端末に送信し、前記決済端末は、受信した前記目的地情報に対応した電波状態期待値を基に、乗車時または実車中に与信促進アナウンスを行なうかどうかを決定する。
【選択図】図１

Description

本発明は、タクシーを利用した場合に、利用料金のカード決済を確実に行なうことができるカード決済システムに関する。

タクシー利用での料金のクレジットカード決済に使用されるカード決済システムがある。このようなタクシーのカード決済においては、既存のシステムとして、非特許文献１に示すように、売上情報の他に、乗車地／経由地／降車地の位置情報をタクシー業務を管理するタクシー業務サーバに送信して、乗車区間の履歴として利用者に提供するサービスが存在する。

このサービスを組み込んだカード決済システムは、ＧＰＳ（Global Positioning System）衛星から受信した情報（時刻情報、衛星の軌道情報）や、タクシーに搭載される加速度センサ等の情報を組み合わせてそのタクシーの現在位置（緯度、経度）を算出する、ＧＰＳ受信機を内蔵したカーナビゲーション装置と、空車、実車、支払の３つの状態を持ち、操作スイッチの押下により、空車、実車、支払の状態を切り替えるタクシーメータと、乗客の降車時の料金精算時に、売上情報とともに、位置情報（乗車位置および降車位置の緯度、経度）を、タクシー業務を管理するタクシー業務サーバに送信して、カード決済のための情報をタクシー業務サーバとやり取りする決済端末とを備えている。

タクシー利用でのカード決済においては、タクシーの乗車代金（利用代金）が決済可能であるかどうかを確認するために、利用代金相当額を例えば１万円などと見積もって、クレジットカードが有効であり、まだ、１万円の利用枠が残っているかどうかを決済端末からタクシー業務サーバに問い合わせる与信確認を行なっている。

例えば、タクシーが目的地に到着したときに与信確認がすでに済んでいれば、その目的地の電波状態が悪く、その目的地でタクシーの決済端末とタクシー業務サーバとの間で通信不能な状態であっても、後で、売上情報をタクシー業務サーバに上げる（アップロードする）ことができ、利用代金決済業務に問題は生じない。しかし、タクシーが目的地に到着したときに与信確認が済んでなく、かつ、その到着地の電波状態が悪い場合は、タクシーの利用代金をクレジットカードで決済することができず、利用代金決済業務に支障が生じている。

駅の近くの人通りが多い場所であっても、実際に調査した範囲では、基地局の設置台数が十分でないなどの理由から、電波状態が悪い場所は多数存在している。これは、タクシーの目的地が駅の側である場合などに、電波状態が悪いため与信確認を目的地で行なえず、クレジットカードによる決済も行なえない、というケースの多発につながり、タクシー利用でのクレジットカード決済が円滑に行なえないことの原因の１つになっている。

このように、タクシーにおいて、目的地での電波状態が悪く、通信できない場合は、カード決済を目的地で実施できない。目的地に到着するまでの間に、予めカードの与信確認を実施し、目的地で通信できない場合も支払いを可能にする仕組みは存在するが、タクシーで目的地に向けて移動中にカードの与信確認をしなかった場合は、目的地で通信できない限り、カード決済を実施できない。

そして、目的地で通信できない場合は、カード決済できなくなるので、乗客との間でトラブルが発生してしまう。通信キャリア会社の圏内エリアであっても、立地環境によっては、建物などが遮蔽物となり電波が不安定で通信できない場所が存在することを考慮すると、通信圏内であるかどうか、という単純な区分けでは、目的地が通信圏内であっても、電波状態が悪く、カード決済できない場合も考えられ、十分な対処にはならない。

なお、関連技術として、特許文献１では、タクシーメータのタリフ状態が支払タリフに変化する前に、決済カード情報取込手段によって取り込まれた決済カード情報を決済予約情報として記憶し、タクシーメータが支払タリフに変化した際に、決済予約情報に基づいて後払料金情報を発生させる技術が示されている。

また、特許文献２では、タクシーに無効カード番号情報を記憶させた信用照会機を搭載し、営業所にはデータ管理用コンピュータを設置し、データ管理用コンピュータから信用照会機への無効カード番号情報の複写と、信用照会機に蓄積されたその日のクレジットカードによる取引内容の転送を、ＩＣカードにより行なう技術が示されている。

特開２０００−３２２６０８号公報 特開平８−３３５２９３号公報

キャブホームページ（http://www.cabcard.jp/cabcard.html）のCAB CARDサービス、クレジットカードサービス、WEBサービスの各項目の記述

本発明は、上記問題を解決するためになされたものであり、タクシーを利用した場合に、利用料金のカード決済を確実に行なうことができるカード決済システムを提供することを目的とする。

提案する第１のタクシー利用料のカード決済システムは、タクシーに設置される決済端末と、外部のサーバとがネットワークを通して接続されるシステムである。
この第１のシステムにおいて、前記決済端末は、利用者から指定された前記タクシーの目的地情報を含む目的地電波状態問い合わせ情報を前記サーバに送信する電波状態問い合わせ部、を備え、前記サーバは、位置情報と、各位置における電波状態期待値とを有する電波状態情報を記憶する電波状態情報記憶部と、前記目的地電波状態問い合わせ情報を受信したときに、前記目的地情報に対応する電波状態期待値を前記電波状態情報記憶部から取得して、前記目的地情報に対応した電波状態期待値として前記決済端末に送信する電波状態期待値送信部と、を備え、前記決済端末は、前記サーバから受信した前記目的地情報に対応した電波状態期待値を基に、乗車時または実車中に与信促進アナウンスを行なうかどうかを決定する与信促進アナウンス可否決定部と、与信促進アナウンスを行なうと決定された場合に、該与信確認を促すメッセージを利用者に出力する出力部と、をさらに備えるものである。

提案する第２のタクシー利用時のカード決済システムは、前記第１のシステムにおいて、前記決済端末は、前記サーバへの通信の可能／不可能状態に対応して、目的地での電波状態を決定する電波状態決定部と、決定された電波状態を目的地の位置情報に対応付けて前記サーバに送信する電波状態送信部と、をさらに備え、前記サーバは、前記タクシーから受信した目的地の電波状態と、位置情報とを収集し、利用者情報として記憶する利用者情報記憶部と、前記利用者情報のうちの、各位置において、直近の所定期間での電波状態を参照して、前記各位置での電波状態期待値を決定し、前記電波状態期待値を更新する電波状態更新部と、をさらに備えるものである。

提案する第１のタクシー利用時のカード決済システムでは、乗車時や実車中などの目的地に到着する前のタイミングで、目的地の電波状態期待値を受信して、目的地の電波状態が悪いと想定される場合は、乗車時や実車中にクレジットカードの与信確認を実施するように促すアナウンスを行なうことで、クレジットカードによる決済ＮＧを回避している。これにより、サービスを向上し、目的地でクレジットカードによる決済ができないことによる利用者とのトラブルを防止可能としている。

提案する第２のタクシー利用時のカード決済システムでは、タクシー業務サーバ側で、位置情報と電波状態とで作成する、電波状態情報を所定のタイミングで、直近の各タクシーから収集した電波状態で更新しているので、目的地の電波状態を高精度に予測することが可能となる。

本発明の一実施形態に係るタクシーのカード決済システムを示す図である。 本実施形態のカード決済システムに加えて、クレジット会社のサーバを含むシステム全体のタクシー乗車から目的地到着後の売上情報送信までの処理フロー（その１）である。 本実施形態のカード決済システムに加えて、クレジット会社のサーバを含むシステム全体のタクシー乗車から目的地到着後の売上情報送信までの処理フロー（その２）である。 電波状態確認および電波状態通知パケットのデータ構造を示す図である。 電波状態テーブルのデータ構造を示す図である。 与信確認および結果通知パケットのデータ構造を示す図である。 売上情報／利用情報パケットのデータ構造を示す図である。 売上情報／利用情報パケットから分離された売上情報パケットのデータ構造を示す図である。 利用者情報テーブルのデータ構造を示す図である。 図１の決済端末の機能ブロック図である。 図１のタクシー業務サーバの機能ブロック図である。 利用者の乗車から降車後の売上情報送信までのタクシー業務における本実施形態のカード決済システムの処理フロー（その１）である。 利用者の乗車から降車後の売上情報送信までのタクシー業務における本実施形態のカード決済システムの処理フロー（その２）である。

以下、本発明に係る実施の形態について図面を参照して詳細に説明する。
タクシーの利用料金の決済にはクレジットカードを使用することを前提として、以下で実施形態を説明する。

図１は、本発明の一実施形態に係るタクシー料金のカード決済システムを示す図である。
図１に示すように、このカード決済システムは、タクシー１内に設置された各種機器と、外部のタクシー業務サーバ２とがデータをやり取りすることで、タクシー利用時のクレジットカードによる料金決済を実行するものである。

タクシー１内に設置された各種機器としては、ＧＰＳ衛星からの情報（時刻情報、衛星の軌道情報）をアンテナ１１を通して受信し、加速度センサ１３、ジャイロ１５、車速センサ１７の情報を組み合わせてタクシー１の現在位置（緯度、経度）を算出する、ＧＰＳ受信機を内蔵したカーナビゲーション装置１８と、空車、実車、支払の３つの状態を持ち、操作スイッチ（空車スイッチ２１−１、実車スイッチ２１−２、支払スイッチ２１−３）の押下により、空車、実車、支払の各状態を切り替える（常に１つのスイッチのみが押下されている状態になる）タクシーメータ２３と、乗客の降車時の精算で、売上情報とともに、位置情報（乗車位置および降車位置の緯度、経度）を、タクシー業務を管理するタクシー業務サーバ２に送信して、カード決済のための情報をタクシー業務サーバ２とやり取りする決済端末２５とを備えている。

なお、タクシーメータ２３はこの他に、走行中に現地点までの料金を表示する表示部（不図示）を備えている。乗車位置から現地点までの移動距離は、車速センサ１７の情報を用いて算出し、タリフ（料金表）情報を参照して料金に換算し、表示部に表示している。

また、タクシー１内には、この他に、精算時にレシートを（タクシーメータ２３経由で）印字するプリンタ２６や、後述の与信促進アナウンスを行なうスピーカ２４も備えられている。

図２Ａおよび図２Ｂは、本実施形態のカード決済システムに加えて、クレジット会社のサーバを含むシステム全体のタクシー乗車から目的地到着後の売上情報送信までの処理フローである。

図２Ａの（Ｓ１）で、客がタクシー１に乗車し、運転手に行き先（目的地）を告げ、運転手が目的地をカーナビゲーション装置１８に目的地情報（駅名、施設名、地番など）として入力すると、カーナビゲーション装置１８は、入力された駅名、施設名、地番などと、それに対応する位置情報（緯度、経度）とをタクシーメータ２３を経由して決済端末２５に出力する。そして、（Ｓ２）で、目的地に向けての実車（走行）が開始される。

そして、走行中の所定のタイミング（Ｓ３）で、図３（ａ）に示す目的地の位置情報を含む目的地の電波状態確認の問い合わせパケット３１が決済端末２５からタクシー業務サーバ２に送信される。

この目的地の電波状態確認の問い合わせパケット３１を受信したタクシー業務サーバ２は、（Ｓ４）で、電波状態ＤＢ（図４に示す電波状態テーブル３５）を、電波状態確認の問い合わせパケット３１に含まれる位置情報をキーとして検索して目的地の電波状態期待値を取得し、（Ｓ５）で、図３（ｂ）に示す目的地の電波状態期待値通知パケット３２を決済端末２５に送信する。

目的地の電波状態期待値をタクシー業務サーバ２から受信した決済端末２５は、（Ｓ６）で、その目的地の電波状態期待値が良好であるかどうかを判定する。
目的地の電波状態期待値が良好ではないと判定された場合（Ｓ６の判定結果がＮｏの場合）、（Ｓ７）で、決済端末２５は、与信促進アナウンスをタクシー車内にてスピーカー（不図示）を通して行なう。

このアナウンスの結果、例えば乗客からタクシー運転手にクレジットカードが手渡され、運転手がそのクレジットカードを決済端末２５の差込口（不図示）に差し込むことで、そのクレジットカードのクレジットカード番号が決済端末２５に読み込まれて、図５（ａ）に示す与信確認の問い合わせパケット３７（例えば、１万円分の利用可能枠がまだ残っているかの確認問い合わせ）が決済端末２５からタクシー業務サーバ２に、（Ｓ８）で送信される。

決済端末２５からの与信確認の問い合わせパケット３７を受信したタクシー業務サーバ２では、その与信確認の問い合わせパケット３７のヘッダ部に含まれる送信元と送信先アドレスを自端末２５のものとクレジット会社のサーバのものに変更することで、（Ｓ９）で、その与信確認の問い合わせパケット３７をクレジット会社のサーバに転送する。

タクシー業務サーバ２からの与信確認の問い合わせパケット３７を受信したクレジット会社のサーバは、（Ｓ１０）で、その与信確認の問い合わせパケット３７に含まれる、クレジットカード番号をキーとして、利用状況ＤＢ（不図示。ここでは、その詳細は述べないが、要は、利用可能枠がいくらで、そのうちのいくらを利用済みで、利用可能な残高がいくらか、という情報をクレジットカード番号毎に持つデータベースである）を検索し、見つけたクレジットカード番号に対応する利用可能な残高が例えば１万円より大きいかどうかを判定することで、与信確認の結果として「ＯＫ」を返すか、「ＮＧ」を返すかを決める。この結果通知パケット３８（そのデータ構造は図５（ｂ）に示される）が（Ｓ１１）でクレジット会社のサーバからタクシー業務サーバ２に送信され、（Ｓ１２）で、タクシー業務サーバ２からタクシー１に設置された決済端末２５に送信される。

目的地に到着したとき、前の（Ｓ６）で、目的地の電波状態が良好と判定されていた場合（Ｓ６の判定結果がＹｅｓの場合）には、（Ｓ１３）で示したように、（Ｓ８）〜（Ｓ１２）の与信確認がこのタイミングで行なわれる。なお、前のＳ６の判定結果がＮｏの場合には何も行なわない。

そして、（Ｓ１４）で、料金の支払い（与信確認の結果が「ＯＫ」の場合にはサイン）が行なわれ、（Ｓ１５）で、プリンタ２６によりレシートが印字される。このようにして、売上が確定すると、（Ｓ１６−１）で、図６に示す売上情報／利用情報パケット４１が決済端末２５からタクシー業務サーバ２に送信される。

決済端末２５からの売上情報／利用情報を受信したタクシー業務サーバ２では、その受信した売上情報／利用情報から売上情報のみを分離して、（Ｓ１７−１）で、図７に示すような分離結果の売上情報パケット４３をタクシー業務サーバ２からクレジット会社のサーバに送信する。

また、タクシー業務サーバ２では、（Ｓ１８）で、受信した売上情報／利用情報パケット４１を利用者情報ＤＢに蓄積する。利用者情報ＤＢには、図８に示す利用者情報テーブル４５が記憶されている。

（Ｓ１７−１）で、タクシー業務サーバ２からクレジット会社のサーバに送信された売上情報パケット４３の受信処理が正常に完了したかどうかは、（Ｓ１７−２）で、受信処理の完了状態通知として、クレジット会社のサーバからタクシー業務サーバ２に送信される。

この(Ｓ１７−２)の受信処理の完了状態通知を受け取った後に、（Ｓ１６−１）で、決済端末２５からタクシー業務サーバ２に送信された売上情報／利用情報パケット４１の受信処理がクレジット会社への転送処理も含めて正常に完了したかどうかは、（Ｓ１６−２）で、受信処理の完了状態通知として、タクシー業務サーバ２から決済端末２５に送信される。

タクシー業務サーバ２では、（Ｓ１８）に続いて、（Ｓ１９）で、利用者情報ＤＢ内の情報のうちの直近の所定期間に各タクシーの決済端末から収集した情報を用いて電波状態ＤＢを更新する。

このように、電波状態ＤＢに記憶される各位置での電波状態を常に最新に保つことで、地震などの自然災害で基地局が使用不能になり、しばらくして回線が復旧するなど、通信可能なエリアが環境変化により変わっていくことにシステム側でも対処可能となる。

図３は、電波状態確認および電波状態通知パケットのデータ構造を示す図である。
図３（ａ）は、目的地の電波状態確認の問い合わせパケット（電波状態確認パケット）のデータ構造を示している。電波状態確認の問い合わせパケット３１は、ヘッダ部３１−１、電波状態確認の問い合わせであることを示す情報３１−２、目的地の緯度３１−３、目的地の経度３１−４、の各項目を備える。

図３（ｂ）は、目的地の電波状態確認の問い合わせに対するタクシー業務サーバ２側から決済端末２５側への応答としての目的地の電波状態通知パケットのデータ構造を示している。電波状態通知パケット３２は、ヘッダ部３２−１、電波状態確認の応答であることを示す情報３２−２、目的地の電波状態３２−３、の各項目を備える。

図４は、電波状態テーブルのデータ構造を示す図である。
図４に示すように、電波状態テーブル３５は、緯度３５−１、経度３５−２、場所３５−３、電波状態３５−４、サンプル台数３５−５、の各項目を備える。サンプル台数３５−５については後述する。

駅や空港などでタクシーの降車場所が決まっている場所は数多く存在し、それらの場所については正確な位置情報を緯度３５−１、経度３５−２に設定するが、それ以外の場所についてはある程度の丸め込みを（緯度、経度）について行なう。

図５は、与信確認および結果通知パケットのデータ構造を示す図である。
図５（ａ）は、与信確認の問い合わせパケット（与信確認パケット）のデータ構造を示している。与信確認の問い合わせパケット３７は、ヘッダ部３７−１、与信確認であることを示す情報３７−２、（乗客の）クレジットカード情報（クレジットカード番号、有効期限などである）３７−３、の各項目を備える。

図２Ａで示したように、与信確認の問い合わせは、決済端末２５からタクシー業務サーバ２を経由して、クレジット会社のサーバに送信される。与信確認の問い合わせパケット３７のヘッダ部３７−１は、送信元と送信先のアドレスを含んでいる。タクシー業務サーバ２での転送時に、このヘッダ部３７−１の送信元と送信先のアドレスは更新される。

図５（ｂ）は、与信確認の問い合わせに対するタクシー業務サーバ２（クレジット会社のサーバ）側から決済端末２５側への応答としての結果通知パケットのデータ構造を示している。結果通知パケット３８は、ヘッダ部３８−１、与信確認の応答であることを示す情報３８−２、結果情報（「ＯＫ」または「ＮＧ」）３８−３、の各項目を備える。

図２Ａで示したように、結果通知パケット３８は、クレジット会社のサーバからタクシー業務サーバ２を経由して、決済端末２５に送信される。結果通知パケット３８のヘッダ部３８−１は、送信元と送信先のアドレスを含んでいる。タクシー業務サーバ２での転送時に、このヘッダ部３８−１の送信元と送信先のアドレスは更新される。

図６は、売上情報／利用情報パケットのデータ構造を示す図である。
図６に示すように、売上情報／利用情報パケット４１は、ヘッダ部４１−１、クレジットカード番号４１−２、売上金額４１−３、決済日時４１−４、乗車位置緯度４１−５、乗車位置経度４１−６、降車位置緯度４１−７、降車位置経度４１−８、降車位置電波状態４１−９、の各項目を備える。

図７は、売上情報／利用情報パケットから分離された売上情報パケットのデータ構造を示す図である。
図７に示すように、売上情報パケット４３は、ヘッダ部４３−１、クレジットカード情報（クレジットカード番号、有効期限などである）４１−２、売上金額４１−３、決済日時４１−４、の各項目を備える。クレジットカード番号４１−２、売上金額４１−３、決済日時４１−４、の各項目は、分離元の売上情報／利用情報４１のものと一致している。

図８は、利用者情報テーブルのデータ構造を示す図である。
図８に示すように、利用者情報テーブル４５は、決済端末ＩＤ４５−１、売上金額４５−２、降車日時（決済は降車時に行なわれるため、このような項目名となっている）４５−３、乗車位置緯度４５−４、乗車位置経度４５−５、乗車した場所４５−６、降車位置緯度４５−７、降車位置経度４５−８、降車した場所４５−９、降車位置電波状態４５−１０、の各項目を備える。

乗車した場所４５−６や降車した場所４５−９としては、「○×駅東口」など名称で示す。これは、タクシー業務サーバ２側で受信した乗車位置緯度４５−４、乗車位置経度４５−５、降車位置緯度４５−７、降車位置経度４５−８に基づいて求められる。

各タクシーに設置された各決済端末から収集された情報が格納された利用者情報テーブル４５中の各行（各レコード）のうちの、直近の所定期間（１日、３日、１週間、１ヶ月、等）につき、降車した場所４５−９毎に、レコード中の降車位置電波状態４５−１０の統計処理を行い、その降車した場所４５−９の、その直近の所定期間での電波状態として、図４の電波状態テーブル３５の電波状態３５−４、サンプル台数（統計処理に使用したレコード数）３５−５に反映させている。統計の取り方としては任意の方法を採用可能である。

例えば、ある「降車した場所４５−９」でのサンプル数の過半数を「良好」、「リトライ回数×回」、「通信圏外／リトライオーバ」がそれぞれ占めていた場合、その「降車した場所４５−９」の電波状態３５−４を、「良好」、「リトライ回数×回」、「通信圏外／リトライオーバ」にそれぞれ設定する。

サンプル数のうちで最も多い状態が５割未満で、「良好」、「リトライ回数×回」、「通信圏外／リトライオーバ」であった場合、その「降車した場所４５−９」の電波状態３５−４を、「リトライ回数×回」、「リトライ回数×回」、「通信圏外／リトライオーバ」と「良好」については実際より悪く設定して、目的地での与信確認不能となる状況をなるべく避けるようにする。

図９は、図１の決済端末の機能ブロック図である。
図９に示すように、決済端末２５は、通信インターフェイス５１、電波状態確認情報送信部５２、与信確認情報送信部５３、売上情報／利用情報送信部５４、与信促進アナウンス可否決定部５５、監視部５６、メモリ５８、を備える。

メモリ５８には、目的地情報６１、クレジットカード情報（クレジットカード番号、有効期限など）６２、売上情報／利用情報６３、カード確認済みフラグ６４、の各データが記憶される。

目的地情報６１は、目的地の緯度（降車位置近辺を代表する地点の緯度）、目的地の経度（降車位置近辺を代表する地点の経度）である。
売上情報／利用情報６３のうちの、売上情報６３−１は、図６のクレジットカード情報４１−２、売上金額４１−３、決済日時４１−４の組み合わせに対応する。

乗車位置情報６３−２は、図６の乗車位置緯度４１−５、乗車位置経度４１−６の組み合わせに対応する。
降車位置情報６３−３は、図６の降車位置緯度４１−７、降車位置経度４１−８の組み合わせに対応する。

降車位置電波状態６３−４は、図６の降車位置電波状態４１−９に対応する。
タクシーメータ２３からのデータがメモリ５８内の目的地情報６１にセットされたことを監視部５６が確認すると、監視部５６は電波状態確認情報送信部５２に起動指示を出す。

電波状態確認情報送信部５２は、図３（ａ）に示す目的地の電波状態確認の問い合わせパケット（電波状態確認パケット）３１を通信インターフェイス５１を通してタクシー業務サーバ２に送信する。

カード情報読取り部（不図示）が読み取ったデータのうちのクレジットカード番号、有効期限などがメモリ５８内のクレジットカード情報６２にセットされたことを監視部５６が確認すると、監視部５６は与信確認情報送信部５３に起動指示を出す。

与信確認情報送信部５３は、図５（ａ）に示す与信確認の問い合わせパケット（与信確認パケット）３７を通信インターフェイス５１を通してタクシー業務サーバ２に送信する。この与信確認の問い合わせパケット３７は、タクシー業務サーバ２を経由して最終的には、クレジット会社のサーバに受信される。

乗客がタクシーに乗車すると、カーナビゲーション装置１８から出力される乗車位置の情報がタクシーメータ２３を経由してメモリ５８内の乗車位置情報６３−２にセットされる。また、目的地に到着すると、その目的地の位置（降車位置）の情報がタクシーメータ２３を経由してメモリ５８内の降車位置情報６３−３にセットされる。そして、目的地において、乗客がタクシー運転手に運賃の支払いを行なうと、支払いに伴う情報がタクシーメータ２３からメモリ５８内の売上情報６３−１にセットされる。監視部５６は、メモリ５８内の売上情報／利用情報６３のうちの、売上情報６３−１、乗車位置情報６３−２、降車位置情報６３−３のすべてがセットされたときに、降車位置が通信圏外であるかどうかを判断する。

降車位置が通信圏外であると判断した場合、監視部５６は、売上情報／利用情報６３の降車位置電波状態（具体的にはこの項目は通信圏内であるかどうか、通信圏内である場合はリトライ回数を示している）６３−４の値を「通信圏外／リトライオーバ（本実施形態では、通信圏外とリトライオーバとを区別していない）」にセットして、タクシーが移動してその現在位置が通信圏内になるまで監視を続け、通信圏内になったときに、売上情報／利用情報送信部５４に起動指示を出す。

降車位置が通信圏内であると判断した場合、監視部５６は、売上情報／利用情報６３の降車位置電波状態６３−４の値を「リトライ回数０（ゼロ）回」にセットして、売上情報／利用情報送信部５４に起動指示を出す。

売上情報／利用情報送信部５４は、通信インターフェイス５１を通してタクシー業務サーバ２への売上情報／利用情報６３のパケット送信を試みる。この送信の試みが１回目で成功すると、タクシー業務サーバ２が受信した売上情報／利用情報６３の降車位置電波状態６３−４の値は「リトライ回数０（ゼロ）回」である。タクシー業務サーバ２はこれを「電波状態：良好」と判断する。

送信の試みが規定回数以内で成功すると、タクシー業務サーバ２が受信した売上情報／利用情報６３の降車位置電波状態６３−４の値は「ある回数−１」である。タクシー業務サーバ２はこれを「電波状態：リトライ回数×回（値×の回数分リトライして成功）」と判断する。なお、目的地が通信圏外であった場合や目的地でリトライオーバがあった場合は、目的地を離れた通信可能な場所で再度送信を試みるが、その場合にはリトライ回数のインクリメント処理は行なわず、「電波状態：通信圏外／リトライオーバ」に設定したままである。

電波状態確認情報送信部５２がタクシー業務サーバ２に送信した、図３（ａ）に示す目的地の電波状態確認の問い合わせパケット（電波状態確認パケット）３１に対するサーバ２側からの応答として、（目的地の）電波状態期待値通知パケット３２を通信インターフェイス５１を通して受信した与信促進アナウンス可否決定部５５は、その受信した目的地の電波状態期待値に応じて、乗車中に与信促進アナウンスを行なうかどうかを決定する。

例えば、受信した目的地の電波状態期待値が「良好（＝リトライ回数ゼロ回相当）」であれば、与信促進アナウンス可否決定部５５は、乗車中に与信を促すアナウンスを行なわないこととし、受信した目的地の電波状態期待値が「リトライ回数×回」あるいは「通信圏外／リトライオーバ」であれば、与信促進アナウンス可否決定部５５は、乗車中に与信を促すアナウンスを行なうことと決定する。

乗車中に与信を促すアナウンスを行なうことと決定された場合、与信促進アナウンス可否決定部５５から図１のスピーカ２４に指示が発行され、スピーカ２４から与信確認を促す旨のメッセージ（例えば次のような音声案内等）が出力（タクシー１車内にアナウンス）される。
目的地の電波状態が良好でない恐れがありますので、クレジットカードでお支払いのお客様は与信確認のため前もってカードのご提示をお願いいたします。

この与信確認を促す音声アナウンスの結果として、例えば乗客からタクシー運転手に乗客のクレジットカード（個人名義または法人名義）が手渡され、そのクレジットカードの情報（クレジットカード番号、有効期限など）が決済端末２５に読み取られて、決済端末２５のメモリ５８内のクレジット情報６２に設定される。

図１０は、図１のタクシー業務サーバの機能ブロック図である。
図１０に示すように、タクシー業務サーバ２は、通信インターフェイス６５、データ分離部６６、電波状態取得部６８、電波状態更新部７１、目的地電波状態期待値送信部７２、売上情報転送部７３、電波状態ＤＢ７５、利用者情報ＤＢ８０、を備える。

電波状態ＤＢ７５には、図４の電波状態テーブル３５が記憶される。利用者情報ＤＢ８０には、図８の利用者情報テーブル４５が記憶される。

決済端末２５が送信した図３（ａ）に示す目的地の電波状態確認の問い合わせパケット（電波状態確認パケット）３１を、通信インターフェイス６５を通して受信した電波状態取得部６８は、その電波状態確認の問い合わせパケット３１中の目的地の緯度３１−３、目的地の経度３１−４をキーとして、電波状態ＤＢ７５に記憶された図４の電波状態テーブル３５を検索し、電波状態テーブル３５中で見つけた、一致する（あるいは最も近い）緯度３５−１、経度３５−２の組み合わせの行（または、一致する場所３５−３の行）の電波状態期待値３５−４を取得し、目的地電波状態期待値送信部７２に渡す。

目的地電波状態期待値送信部７２は、受け取った電波状態期待値３５−４を、目的地の電波状態期待値３２−３に設定し、あて先を、電波状態確認の問い合わせの送信元の決済端末とした、図３（ｂ）に示す電波状態期待値通知パケット３２を作成し、通信インターフェイス６５を通して、該当する決済端末に送信する。

また、タクシー業務サーバ２は、図６に示す売上情報／利用情報パケット４１を受信すると、そのヘッダ部の送信元の決済端末アドレスから、決済端末アドレスと決済端末ＩＤとを対応付けたテーブル（不図示）を用いて、送信元の決済端末ＩＤを割り出し、それに、受信した売上情報／利用情報４１のクレジットカード情報４１−２、・・・、降車位置電波状態４１−９を追加して１レコードを作成し、利用者情報ＤＢ８０に記憶される利用者情報テーブル４５に、その作成した１レコードが追加する。なお、上述したように、乗車位置緯度４１−５、乗車位置経度４１−６、降車位置緯度４１−７、降車位置経度４１−８を基に、タクシー業務サーバ２側で「乗車した場所４５−６」と「降車した場所４５−９」に値（駅名、地名、等）が設定される。

また、タクシー業務サーバ２は、データ分離部６６を通して、受信した売上情報／利用情報４１から売上情報（４１−２、４１−３、４１−４）を分離して売上情報転送部７３に渡す。

売上情報転送部７３は、ヘッダ部４３−１に、送信元としてタクシー業務サーバ２のアドレスを指定し、送信先に該当するクレジット会社のサーバを指定した、図７に示す売上情報パケット４３を作成し、通信インターフェイス６５を通して該当するクレジット会社のサーバに送信する。

電波状態更新部７１は、各タクシーに設置された各決済端末から収集された利用者情報テーブル４５中の各行（各レコード）のうちの、直近の所定期間（１日、３日、１週間、１ヶ月、等）につき、降車した場所４５−９毎に、レコード中の降車位置電波状態４５−１０の統計処理を行い、その降車した場所４５−９の、その直近の所定期間での電波状態として、図４の電波状態テーブル３５の電波状態期待値３５−４、サンプル台数（統計処理に使用したレコード数）３５−５に反映させることで、電波状態テーブル３５の更新処理を行なっている。

図１１Ａおよび図１１Ｂは、利用者の乗車から降車後の売上情報送信までのタクシー業務における本実施形態のカード決済システムの処理フローである。
図１１ＡのステップＳ３１で、客がタクシー１に乗車し、ステップＳ３２で、その客が告げた目的地がカーナビゲーション装置１８にセットされ、タクシーメータ２３経由で、決済端末２５のメモリ５８内の目的地情報６１にデータ（目的地の緯度、目的地の経度、目的地の場所）がセットされる。

また、続く、ステップＳ３３で、カーナビゲーション装置１８が内蔵したＧＰＳ受信機が受信したＧＰＳ情報、各種センサ（加速度センサ１３、ジャイロ１５、車速センサ１７）情報などから乗車した場所の位置情報（緯度、経度）が取得され、タクシーメータ２３経由で、決済端末２５のメモリ５８内の乗車位置情報６３−２にデータがセットされる。乗車位置情報６３−２中の「乗車した場所」については、タクシー業務サーバ２側で、売上情報／利用情報４１受信時に求めるようにする。

そして、ステップＳ３４で、目的地に向けてタクシー１が走行を開始し、実車の状態となる。ステップＳ３５では、ステップＳ３２でカーナビゲーション装置１８にセットされた目的地情報６１を用いて、電波状態確認情報送信部５２により図３（ａ）に示す目的地の電波状態確認の問い合わせパケット（電波状態確認パケット）３１が作成され、タクシー業務サーバ２に送信される。この電波状態確認の問い合わせパケット３１を受信したタクシー業務サーバ２は、その電波状態確認の問い合わせパケット３１中の目的地の緯度３１−３、目的地の経度３１−４をキーとして、電波状態ＤＢ７５内に記憶される電波状態テーブル３５を検索し、電波状態テーブル３５中で見つけた、一致する（あるいは最も近い）緯度３５−１、経度３５−２の組み合わせの行（または、一致する場所３５−３の行）の電波状態期待値３５−４を取得し、その電波状態期待値３５−４を用いて、図３（ｂ）に示す電波状態期待値通知パケット３２を作成し、決済端末２５に送信する。これにより、決済端末２５側で、目的地の電波状態期待値を取得する。

続く、ステップＳ３６では、受信した目的地の電波状態期待値を基に、目的地の電波状態が良好であるかどうかを判定する。すなわち、目的地の電波状態期待値が「良好」であるかどうかを判定する。

ステップＳ３６で目的地の電波状態期待値が「良好（リトライ０（ゼロ）回）」であると判定された場合（ステップＳ３６の判定結果がＹｅｓの場合）、ステップＳ３９に進む。この場合、実車（走行）中には与信確認を行なわないことになる。

ステップＳ３６で目的地の電波状態期待値が「良好」ではないと判定された場合（ステップＳ３６の判定結果がＮｏの場合）、すなわち、目的地からの売上情報／利用情報４１中の降車位置電波状態が、「リトライｎ回（ｎは１以上）」、または、「通信圏外／リトライオーバ」であった場合、ステップＳ３７において、与信促進のアナウンスが行なわれ、メモリ５８内のクレジットカード情報（クレジットカード番号、有効期限など）６２へのデータ設定が行なわれる。

その後、ステップＳ３８のカード確認処理で、そのクレジット情報６２を用いて、与信確認情報送信部５３が、図５（ａ）に示す与信確認の問い合わせパケット（与信確認パケット）３７を作成し、タクシー業務サーバ２に送信する。なお、この与信確認の問い合わせパケット３７がタクシー業務サーバ２からクレジット会社のサーバに転送される点などについては上述した通りである。その後、決済端末２５は、タクシー業務サーバ２から与信確認の問い合わせに対する応答としての、図５（ｂ）に示す結果通知パケット３８を受信する。結果通知パケット３８を受信すると、メモリ５８内のカード確認済みフラグ６４が「ＯＦＦ」から「ＯＮ」に変更される。

しばらく乗車してからタクシー１が目的地に到着すると、ステップＳ３９で、乗客のクレジットカードによる支払いが行なわれる。この際、ステップＳ４０で、決済端末２５のメモリ５８内のカード確認済みフラグ６４が参照され、カード確認済みであるかどうかが判定される。

カード確認済みである場合（カード確認済みフラグ６４が「ＯＮ」の場合）、ステップＳ４２に進む。
カード確認済みでない場合（カード確認済みフラグ６４が「ＯＦＦ」の場合）、ステップＳ４１でカード確認処理を行なう。この処理は、ステップＳ３８のカード確認処理と同様であるので説明を省略する。

ステップＳ４１が実行された結果として、与信確認の結果が「ＯＫ」であった場合、カード確認済みフラグ６４の値が「ＯＦＦ」から「ＯＮ」に変更され、続く、ステップＳ４２で、位置情報取得、売上情報取得、および、決済端末２５に接続されたプリンタ２６によるレシート印字が行われる。

なお、ステップＳ４２で、「位置情報取得」とは、カーナビゲーション装置１８が内蔵したＧＰＳ受信機が受信したＧＰＳ情報、各種センサ（加速度センサ１３、ジャイロ１５、車速センサ１７）情報などから降車する場所の位置情報（緯度、経度）を取得し、タクシーメータ２３経由で、決済端末２５のメモリ５８内の降車位置情報６３−３にデータがセットされることをいう。

また、ステップＳ４２で、「売上情報取得」とは、クレジットカード番号、売上金額、決済日時をメモリ５８の売上情報６３−１にセットすることである。このうち、「売上金額」については、タクシーメータ２３経由でデータがセットされる。

続く、ステップＳ４３で、客が降車する。
そして、図１１Ｂに移り、ステップＳ４４で、その目的地（降車位置）が通信圏外であるかどうかを判定する（圏外であれば電波が全く検知されない）。

ステップＳ４４で目的地が通信圏外ではないと判定された場合（ステップＳ４４の判定結果がＮｏの場合）、ステップＳ４５で、決済端末２５のメモリ５８の降車位置電波状態６３−４に、「リトライ回数０（ゼロ）回」をセットし、ステップＳ４６で、売上情報、乗車・降車位置情報、リトライ回数０（ゼロ）回がセットされた売上情報／利用情報パケット４１をタクシー業務サーバ２に送信する。

続く、ステップＳ４７では、ステップＳ４６の売上情報／利用情報パケット４１の送信処理が正常に完了したかどうかを判定する。これは、例えば、図２Ｂの（Ｓ１６−２）の受信処理の完了状態通知を参照することで判定する。

ステップＳ４７で売上情報／利用情報パケット４１の送信処理が正常に完了したと判定された場合（ステップＳ４７の判定結果がＹｅｓの場合）、一連の処理を終了する。この場合、タクシー業務サーバ２側では、収集した目的地の電波状態が「良好（＝リトライ回数０（ゼロ）回相当）」となる。

ステップＳ４７で売上情報／利用情報パケット４１の送信処理が正常に完了しなかったと判定された場合（ステップＳ４７の判定結果がＮｏの場合）、ステップＳ４８で、リトライ回数が規定回数に達し、リトライオーバであるかどうかが判定される。

ステップＳ４８でリトライオーバであると判定された場合（ステップＳ４８の判定結果がＹｅｓの場合）、ステップＳ５１に進む。
ステップＳ４８でリトライオーバではないと判定された場合（ステップＳ４８の判定結果がＮｏの場合）、ステップＳ４９で、リトライ回数を更新し、すなわち、リトライ回数をインクリメントし、決済端末２５のメモリ５８の降車位置電波状態６３−４に、インクリメントされたリトライ回数（「リトライ回数×回」）をセットし、ステップＳ４６に戻る。

ステップＳ４４で目的地が通信圏外であると判定された場合（ステップＳ４４の判定結果がＹｅｓの場合）、ステップＳ５０で、決済端末２５のメモリ５８の降車位置電波状態６３−４に、「通信圏外／リトライオーバ」をセットし、ステップＳ５１に進む。

ステップＳ５０またはステップＳ４８から制御を渡されたステップＳ５１では、通信状態が回復したかどうかを判定し（ステップＳ５１の判定処理は例えばタクシーを「空車」として他の場所に移動中に行なう）、通信状態が回復した場合に、ステップＳ５２で、乗車・降車位置情報、通信圏外／リトライオーバがセットされた売上情報／利用情報４１をタクシー業務サーバ２に送信する。カード確認済みのときは、売上情報６３−１に有効な値をセットして送信を行なうが、カード確認済みでない場合は、売上情報６３−１に無効な値をセットして送信する。そして、一連の処理を終了する。

以上説明したように、本実施形態のタクシー利用時のカード決済システムでは、乗車時や実車中などの目的地に到着する前のタイミングで、目的地の電波状態期待値を電波状態ＤＢから収集して、目的地の電波状態が悪いと想定される場合は、乗車時や実車中にクレジットカードの与信確認を実施して、クレジットカードによる決済ＮＧを回避している。これにより、サービスが向上し、目的地でクレジットカードによる決済ができないことによる利用者とのトラブルを防止可能としている。

また、目的地で通信せずにレシートの印字を行うことができ、スピーディに降車可能である。また、タクシー業務サーバ側で、位置情報と電波状態（すなわち、通信結果）とで作成する、電波状態ＤＢを所定のタイミングで、各タクシーから直近の時点で収集した電波状態で更新しているので、目的地の電波状態を高精度に予測することが可能となる。

なお、以上の説明では、図３（ａ）に示す電波状態確認の問い合わせ（電波状態確認情報）や、図４に示す電波状態テーブルは、場所（目的地）の情報として、緯度・経度と名称の双方を持っていたが、いずれか一方でもよい。要は、目的地が特定でき、その目的地の電波状態期待値が分かればよい。

なお、本実施形態の方法により、各位置での電波状態期待値を更新し、更新された電波状態期待値を使用して、目的地の電波状態を予測し、例えば「良好」と判断されれば実際のところ、殆どのケースで問題なくクレジットカード決済での手続きが降車位置で与信確認も含めて可能となると考えられる。しかし、予測に反して降車位置の電波状態が「リトライオーバ」になるなどして、現金決済するようになるケースも可能性としては非常に小さいが絶無ではない。

１ タクシー
２ タクシー業務サーバ
１１ アンテナ
１２ ＧＰＳ受信機
１３ 加速度センサ
１５ ジャイロ
１７ 車速センサ
１８ カーナビゲーション装置
２１−１ 空車スイッチ
２１−２ 実車スイッチ
２１−３ 支払スイッチ
２３ タクシーメータ
２４ スピーカ
２５ 決済端末
３１ 電波状態確認パケット
３２ 電波状態確認の応答パケット
３５ 電波状態テーブル
３７ 与信確認パケット
３８ 与信確認の応答パケット
４１ 売上情報／利用情報パケット
４３ 売上情報パケット
４５ 利用者情報テーブル
５１、６５ 通信インターフェイス
５２ 電波状態確認情報送信部
５３ 与信確認情報送信部
５４ 売上情報／利用情報送信部
５５ 与信促進アナウンス可否決定部
５６ 監視部
５８ メモリ
６１ 目的地情報
６２ クレジットカード情報
６３ 売上情報／利用情報
６４ カード確認済みフラグ
６６ データ分離部
６８ 電波状態取得部
７１ 電波状態更新部
７２ 目的地電波状態期待値送信部
７３ 売上情報転送部
７５ 電波状態ＤＢ
８０ 利用者情報ＤＢ

Claims (6)

1. タクシーに設置される決済端末と、外部のサーバとがネットワークを通して接続されるタクシー利用料のカード決済システムにおいて、
   前記決済端末は、利用者から指定された前記タクシーの目的地情報を含む目的地電波状態問い合わせ情報を前記サーバに送信する電波状態問い合わせ部、を備え、
   前記サーバは、位置情報と、各位置における電波状態期待値とを有する電波状態情報を記憶する電波状態情報記憶部と、
   前記目的地電波状態問い合わせ情報を受信したときに、前記目的地情報に対応する電波状態期待値を前記電波状態情報記憶部から取得して、前記目的地情報に対応した電波状態期待値として前記決済端末に送信する電波状態期待値送信部と、を備え、
   前記決済端末は、前記サーバから受信した前記目的地情報に対応した電波状態期待値を基に、乗車時または実車中に与信促進アナウンスを行なうかどうかを決定する与信促進アナウンス可否決定部と、
   与信促進アナウンスを行なうと決定された場合に、該与信確認を促すメッセージを利用者に出力する出力部と、をさらに備えることを特徴とするタクシー利用時のカード決済システム。
2. 前記決済端末は、前記サーバへの通信の可能／不可能状態に対応して、目的地での電波状態を決定する電波状態決定部と、決定された電波状態を目的地の位置情報に対応付けて前記サーバに送信する電波状態送信部と、をさらに備え、
   前記サーバは、前記タクシーから受信した目的地の電波状態と、位置情報とを収集し、利用者情報として記憶する利用者情報記憶部と、
   前記利用者情報のうちの、各位置において、直近の所定期間での電波状態を参照して、前記各位置での電波状態期待値を決定し、前記電波状態期待値を更新する電波状態更新部と、をさらに備えることを特徴とする請求項１記載のタクシー利用時のカード決済システム。
3. 前記目的地の電波状態および前記目的地の電波状態期待値は、「目的地からの通信のリトライ回数ゼロの場合」、「リトライ回数が１回以上でリトライオーバでない場合」、および「目的地が通信圏外であるか、または、圏内でリトライオーバである場合」、の３つの値を持つことを特徴とする請求項１記載のタクシー利用時のカード決済システム。
4. 位置情報と、各位置における電波状態期待値とを有する電波状態情報を記憶する電波状態情報記憶部、を備えるサーバと、タクシーに設置された決済端末とがネットワークを通して情報をやり取りすることで実行するタクシー利用料のカード決済方法において、
   前記決済端末が、利用者から指定された前記タクシーの目的地情報を含む目的地電波状態問い合わせ情報を前記サーバに送信する電波状態問い合わせステップと、
   前記サーバが、前記目的地電波状態問い合わせ情報を受信したときに、前記目的地情報に対応する電波状態期待値を前記電波状態情報記憶部から取得して、前記目的地情報に対応した電波状態期待値として前記決済端末に送信するステップと、
   前記決済端末が、前記サーバから受信した前記目的地情報に対応した電波状態期待値を基に、乗車時または実車中に与信促進アナウンスを行なうかどうかを決定する与信促進アナウンス可否決定ステップと、
   前記決済端末が、与信促進アナウンスを行なうと決定された場合に、該与信確認を促すメッセージを利用者に出力するステップと、を有する、ことを特徴とするタクシー利用時のカード決済方法。
5. 前記決済端末が、前記サーバへの通信の可能／不可能状態に対応して、目的地での電波状態を決定する電波状態決定ステップと、
   前記決済端末が、決定された電波状態を目的地の位置情報に対応付けて前記サーバに送信する電波状態送信ステップと、
   前記サーバが、前記タクシーから受信した目的地の電波状態と位置情報とを収集し、利用者情報として記憶するステップと、
   前記サーバが、前記利用者情報のうちの、各位置において、直近の所定期間での電波状態を参照して、前記各位置での電波状態期待値を決定し、前記電波状態期待値を更新するステップと、をさらに有する、ことを特徴とする請求項４記載のタクシー利用時のカード決済方法。
6. 前記目的地の電波状態および前記目的地の電波状態期待値は、「目的地からの通信のリトライ回数ゼロの場合」、「リトライ回数が１回以上でリトライオーバでない場合」、および「目的地が通信圏外であるか、または、圏内でリトライオーバである場合」、の３つの値を持つことを特徴とする請求項４記載のタクシー利用時のカード決済方法。

Images