(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-19
(45)【発行日】2024-03-28
(54)【発明の名称】運賃収受システム
(51)【国際特許分類】
G06Q 50/40 20240101AFI20240321BHJP
G07B 15/00 20110101ALI20240321BHJP
【FI】
G06Q50/40
G07B15/00 G
(21)【出願番号】P 2020041047
(22)【出願日】2020-03-10
【審査請求日】2022-12-22
(73)【特許権者】
【識別番号】000144544
【氏名又は名称】レシップホールディングス株式会社
(74)【代理人】
【識別番号】100147625
【氏名又は名称】澤田 高志
(74)【代理人】
【識別番号】100150430
【氏名又は名称】河野 元
(74)【代理人】
【識別番号】100155099
【氏名又は名称】永井 裕輔
(74)【代理人】
【識別番号】100190333
【氏名又は名称】木村 群司
(72)【発明者】
【氏名】立川 貴仁
【審査官】加舎 理紅子
(56)【参考文献】
【文献】特開2018-195114(JP,A)
【文献】特開2020-004292(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
G07B 15/00
(57)【特許請求の範囲】
【請求項1】
乗合車両の利用者から当該車両の利用運賃を収受する運賃収受システムであって、
前記車両内の乗車口付近に設けられる乗車情報提供装置と、
前記車両内の降車口付近に設けられる降車情報提供装置と、
前記車両が停留所に停車した前記停留所に対応する情報であってそれぞれの停留所ごとに異なる停留所情報を停車するごとに前記乗車情報提供装置および前記降車情報提供装置に出力させる制御装置と、
前記車両外に設けられて前記利用運賃を収受する電子決済に関する情報処理を行う決済サーバ装置と、
前記利用者が所持して前記乗車情報提供装置および前記降車情報提供装置から出力される前記停留所情報を取得可能かつ前記決済サーバ装置に対し無線通信回線を介して情報通信可能な携帯情報端末装置と、を含み、
前記携帯情報端末装置は、
前記利用者の乗車時に前記乗車情報提供装置から出力された乗車時の前記停留所情報(以下、請求項1~5において「乗車停留所情報」という)を取得し、
前記利用者の降車時に前記降車情報提供装置から出力された降車時の前記停留所情報(以下、請求項1~5において「降車停留所情報」という)を取得し、
前記乗車停留所情報
に含まれる前記乗車時の停留所に対応した整理券番号と前記降車停留所情報
に含まれる前記整理券番号に対応した運賃データとに基づいて得られた前記利用運賃に関する利用運賃情報を前記決済サーバ装置に送信し、
前記決済サーバ装置は、前記携帯情報端末装置から送信された前記利用運賃情報に基づいて前記電子決済に関する情報処理を行うことを特徴とする運賃収受システム。
【請求項2】
前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、それぞれ時間の経過とともに変化し、かつ、出力時刻の時間情報が少なくとも含まれていることを特徴とする請求項1に記載の運賃収受システム。
【請求項3】
前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、暗号化されており、
前記携帯情報端末装置は、暗号化された前記乗車停留所情報および前記降車停留所情報を所定の暗号鍵で復号して前記整理券番号と前記運賃データを取得することを特徴とする請求項1または2に記載の運賃収受システム。
【請求項4】
前記携帯情報端末装置は、
前記降車停留所情報および前記乗車停留所情報に基づいて、前記決済サーバ装置への前記利用運賃情報の送信が完了しなかった場合または前記電子決済に関する情報処理を行うことができなかった場合には、所定の未了情報を前記車両の乗務員に告知可能に出力し、
または、前記決済サーバ装置への前記利用運賃情報の送信が完了した場合または前記電子決済に関する情報処理を行うことができた場合には、所定の完了情報を前記車両の乗務員に告知可能に出力する、
ことを特徴とする請求項1~3のいずれか一項に記載の運賃収受システム。
【請求項5】
前記携帯情報端末装置は、前記利用者の降車時において、前記無線通信回線を介した情報通信を行わないように当該
携帯情報端末装置が設定されている場合には、所定の通信不能情報を前記車両の乗務員に告知可能に出力することを特徴とする請求項1~4のいずれか一項に記載の運賃収受システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、乗合車両の利用者から当該車両の利用運賃を収受する運賃収受システムに関するものである。なお、乗合車両には、路線バス、路面電車、トロリーバス等の乗合バスや鉄道等が含まれる。
【背景技術】
【0002】
乗車券の代わりに、スマートフォン等の携帯情報端末装置を鉄道駅の自動改札機にかざすことにより改札から入場したり出場したりすることを可能にする技術、つまり乗車券のデジタルチケットに関する技術が下記特許文献1に開示されている。デジタルチケットは、入場券や引換券等の一定の権利を電子化したものであり、電子チケットと呼ばれる場合もある。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
デジタルチケットの典型的な例は、エンコードされたコード(例えば、QRコード(登録商標)やバーコード)を紙等に印刷したりスマートフォン等の携帯情報端末装置の画面に表示させたりして、それを当該コード用のリーダで読み取ることで入場券や引換券等の一定の権利を確認する。これを鉄道駅の自動改札機に適用した場合には、特許文献1に開示されている交通システムのタイプαの自動改札機のように、改札機自体にリーダの機能を持たせる必要がある(特許文献1;段落0011等)。そのため、システム導入時等の設備コストが増大するおそれがある。
【0005】
また、特許文献1の交通システムは、鉄道駅の自動改札機に関するものであり、自動改札機は駅構内に設けられる。そのため、入場駅に設けられる自動改札機とセンタサーバ装置との間や、出場駅に設けられる自動改札機と決済サーバ装置との間は、有線通信回線で接続することが比較的容易である。ところが、このような交通システムの技術を路線バスの運賃収受システムに導入しようとすると、路線バスに搭載された運賃箱とセンタサーバ装置や決済サーバ装置との間は、無線通信回線で接続せざるを得ない。車載の運賃箱はそれ自体が移動するからである。無線通信回線は、有線通信回線に比べて利用料金が桁違いに高額であり、運用コストの問題が設備コスト以上にシステム導入の障害になり易い。
【0006】
本発明は、上述した課題を解決するためになされたものであり、設備コストや運用コストの増大を抑制しつつもデジタルチケットによる決済を可能にし得る運賃収受システムを提供することを目的とする。
【課題を解決するための手段】
【0007】
上記目的を達成するため、特許請求の範囲の請求項1に記載された運賃収受システムは、乗合車両の利用者から当該車両の利用運賃を収受する運賃収受システムであって、前記車両内の乗車口付近に設けられる乗車情報提供装置と、前記車両内の降車口付近に設けられる降車情報提供装置と、前記車両が停留所に停車した前記停留所に対応する情報であってそれぞれの停留所ごとに異なる停留所情報を停車するごとに前記乗車情報提供装置および前記降車情報提供装置に出力させる制御装置と、前記車両外に設けられて前記利用運賃を収受する電子決済に関する情報処理を行う決済サーバ装置と、前記利用者が所持して前記乗車情報提供装置および前記降車情報提供装置から出力される前記停留所情報を取得可能かつ前記決済サーバ装置に対し無線通信回線を介して情報通信可能な携帯情報端末装置と、を含み、前記携帯情報端末装置は、前記利用者の乗車時に前記乗車情報提供装置から出力された乗車時の前記停留所情報(以下、請求項1~5において「乗車停留所情報」という)を取得し、前記利用者の降車時に前記降車情報提供装置から出力された降車時の前記停留所情報(以下、請求項1~5において「降車停留所情報」という)を取得し、前記乗車停留所情報に含まれる前記乗車時の停留所に対応した整理券番号と前記降車停留所情報に含まれる前記整理券番号に対応した運賃データとに基づいて得られた前記利用運賃に関する利用運賃情報を前記決済サーバ装置に送信し、前記決済サーバ装置は、前記携帯情報端末装置から送信された前記利用運賃情報に基づいて前記電子決済に関する情報処理を行うことを技術的特徴とする。
【0008】
請求項1に記載の運賃収受システムの発明では、乗車情報提供装置、降車情報提供装置、制御装置、決済サーバ装置および携帯情報端末装置が当該システムを構成する。携帯情報端末装置は、利用者の乗車時に乗車情報提供装置から出力された乗車停留所情報を取得し、利用者の降車時に降車情報提供装置から出力された降車停留所情報を取得し、乗車停留所情報に含まれる乗車時の停留所に対応した整理券番号と降車停留所情報に含まれるこの整理券番号に対応した運賃データとに基づいて得られた利用運賃に関する利用運賃情報を決済サーバ装置に送信し、決済サーバ装置は、携帯情報端末装置から送信された利用運賃情報に基づいて電子決済に関する情報処理を行う。制御装置は、典型的には、例えば、乗合車両内の既存設備として存在する運賃箱、運賃表示器や車内放送装置等の車載機器を構成する制御装置が用いられる。また、決済サーバ装置も、既存設備のものが使用できる。携帯情報端末装置は、当該乗合車両の利用者が所持するものである。なお、制御装置は、それ自体を単体で設けてもよい。
【0009】
このため、運賃収受システムを構成するうえで、新規に必要になるものは乗車情報提供装置と降車情報提供装置である。また、利用運賃に関する利用運賃情報を得る情報処理や、決済サーバ装置との通信処理は、利用者が所持する携帯情報端末装置が行う。これにより、乗合車両に搭載された制御装置、乗車情報提供装置や降車情報提供装置は、利用運賃情報を得る情報処理を行ったり、決済サーバ装置との通信処理を行ったりする必要がないので、これらの制御装置等に演算処理能力が高いマイクロコンピュータや記憶容量が大きなメモリ等を設ける必要もない。また通信コストの増加もない。
【0010】
また、決済サーバ装置と無線通信回線を介して情報通信を行うのは、専ら携帯情報端末装置であり、乗合車両に設けられた、乗車情報提供装置、降車情報提供装置および制御装置は、決済サーバ装置と直接、情報通信を行わない。つまり、乗合車両を運行する事業者等は、運賃収受システムの運用においては決済サーバ装置との間において無線通信回線を利用する必要がない。これにより、車載の乗車情報提供装置、降車情報提供装置や制御装置が無線通信回線を使用する場合に比べて通信コストが大幅に減少する。
【0011】
また、特許請求の範囲の請求項2に記載された運賃収受システムは、請求項1に記載の運賃収受システムにおいて、前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、それぞれ時間の経過とともに変化し、かつ、出力時刻の時間情報が少なくとも含まれていることを技術的特徴とする。
【0012】
請求項2に記載の運賃収受システムの発明では、乗車停留所情報や降車停留所情報は、それぞれ時間の経過とともに変化し、これらの停留所情報が出力された時刻の時間情報が少なくとも含まれているため、この出力時刻の時間情報とこれらの停留所情報の取得時の時間情報とを比較することで、例えば、取得した乗車停留所情報や降車停留所情報が乗車情報提供装置や降車情報提供装置から乗車時や降車時以前の過去に出力されたものであるか否かを判定することが可能になる。なお、停留所情報の取得時の時間情報は、例えば、当該携帯情報端末装置が有する時計機能から得たり、乗車情報提供装置や降車情報提供装置が有する時計機能から得たりする。
【0013】
これにより、取得した乗車停留所情報や降車停留所情報が、例えば、その日前のものであった場合には、本来であれば、乗車時または降車時に乗車停留所情報や降車停留所情報を取得すべきところを、当該利用者が予め準備した古い乗車停留所情報や降車停留所情報を意図的に携帯情報端末装置で取得した蓋然性が高いため、このような不正使用の有無を判定することが可能になる。
【0014】
また、特許請求の範囲の請求項3に記載された運賃収受システムは、請求項1または2に記載の運賃収受システムにおいて、前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、暗号化されており、前記携帯情報端末装置は、暗号化された前記乗車停留所情報および前記降車停留所情報を所定の暗号鍵で復号して前記整理券番号と前記運賃データを取得することを技術的特徴とする。
【0015】
請求項3に記載の運賃収受システムの発明では、乗車情報提供装置から出力される乗車停留所情報および降車情報提供装置から出力される降車停留所情報は、暗号化されているため、乗車停留所情報や降車停留所情報を不正に生成されることを防止可能にしている。携帯情報端末装置は、暗号化された乗車停留所情報および降車停留所情報を所定の暗号鍵で復号して整理券番号と運賃データを取得する。これにより、乗車停留所情報および降車停留所情報が暗号化されていても、携帯情報端末装置はこれらの情報から整理券番号と運賃データを取得して利用運賃に関する利用運賃情報を得ることが可能になる。
【0016】
また、特許請求の範囲の請求項4に記載された運賃収受システムは、請求項1~3のいずれか一項に記載の運賃収受システムにおいて、前記携帯情報端末装置は、前記降車停留所情報および前記乗車停留所情報に基づいて、前記決済サーバ装置への前記利用運賃情報の送信が完了しなかった場合または前記電子決済に関する情報処理を行うことができなかった場合には、所定の未了情報を前記車両の乗務員に告知可能に出力し、または、前記決済サーバ装置への前記利用運賃情報の送信が完了した場合または前記電子決済に関する情報処理を行うことができた場合には、所定の完了情報を前記車両の乗務員に告知可能に出力することを技術的特徴とする。
【0017】
請求項4に記載の運賃収受システムの発明では、携帯情報端末装置は、降車停留所情報および乗車停留所情報に基づいて、決済サーバ装置への利用運賃情報の送信が完了しなかった場合または前記電子決済に関する情報処理を行うことができなかった場合には、所定の未了情報を車両の乗務員に告知可能に出力する。これにより、乗務員は、当該利用者の運賃収受が済んでいないことを知ることができるので、当該利用者に対して事後精算処理等が必要であることを説明する等の適切な乗客対応が可能になる。また、決済サーバ装置への利用運賃情報の送信が完了した場合または前記電子決済に関する情報処理を行うことができた場合には、所定の完了情報を車両の乗務員に告知可能に出力する。これにより、乗務員は、当該利用者の利用運賃収受が済んだことを知ることができるので、当該利用者には事後精算処理等の説明が不要であることを把握することが可能になる。
【0018】
また、特許請求の範囲の請求項5に記載された運賃収受システムは、請求項1~4のいずれか一項に記載の運賃収受システムにおいて、前記携帯情報端末装置は、前記利用者の降車時において、前記無線通信回線を介した情報通信を行わないように当該携帯情報端末装置が設定されている場合には、所定の通信不能情報を前記車両の乗務員に告知可能に出力することを技術的特徴とする。
【0019】
請求項5に記載の運賃収受システムの発明では、携帯情報端末装置は、利用者の降車時において、無線通信回線を介した情報通信を行わないように当該携帯情報端末装置が設定されている場合(例えば、当該携帯情報端末装置が「機内モード」に設定されている場合)には、所定の通信不能情報を車両の乗務員に告知可能に出力する。これにより、乗務員は、無線通信回線を介して、携帯情報端末装置が決済サーバ装置に利用運賃情報を送信したり他のサーバ装置等に乗車停留所情報や降車停留所情報を送信したりすることができない状態であることを把握できるので、例えば、当該利用者に対して機内モードを解除するように促すことが可能になる。したがって、機内モードに起因した携帯情報端末装置による決済サーバ装置への利用運賃情報の送信未了を防ぐことができる。
【発明の効果】
【0029】
本発明の運賃収受システムでは、乗合車両に搭載された制御装置、乗車情報提供装置や降車情報提供装置は、利用運賃に関する利用運賃情報を得る情報処理を行ったり、決済サーバ装置との通信処理を行ったりする必要がないので、これらの制御装置等に演算処理能力が高いマイクロコンピュータや大容量メモリ等を設ける必要もない。また通信コストの増加もない。したがって、設備コストの増大を抑制しつつもデジタルチケットによる決済を可能にすることができる。
【図面の簡単な説明】
【0031】
【
図1】本発明の一実施形態に係る運賃収受システムの構成例を示す説明図である。
【
図2】本実施形態の運賃収受システムを構成する乗車表示端末および降車表示端末の外観構成例を示す斜視図である。
【
図3】データカセットに格納されている運賃三角表データの一例を示す説明図である。
【
図4】本実施形態の運賃収受システムを構成するホスト機器の制御ユニットにより実行される停留所情報等送出処理の流れを示すフローチャートである。
【
図5】乗車表示端末や降車表示端末の制御ユニットにより実行されるコード出力処理の流れを示すフローチャートである。
【
図6】本実施形態の運賃収受システムを構成するスマートフォンの制御ユニットにより実行される運賃精算処理の流れを示すフローチャートである。
【
図7】
図6に表されているコード取得処理の流れを示すフローチャートである。
【
図8】
図7に表されている無線送信処理の流れを示すフローチャートである。
【
図9】本実施形態の運賃収受システムを構成する管理サーバにより実行される停留所情報等記録処理の流れを示すフローチャートである。
【
図10】本実施形態の運賃収受システムを構成する決済サーバにより実行される運賃決済処理の流れを示すフローチャートである。
【
図11】ホスト機器、乗車表示端末、降車表示端末、スマートフォン、管理サーバおよび決済サーバにより、利用者が路線バスに乗車して降車するまでの間において実行される各処理の一連の流れを示すシーケンス図である。
【
図12】スマートフォンの画面表示の例であり、
図12(A)は選択メニュー表示処理における表示例を表したもの、
図12(B)はコード情報取込処理における表示例を表したものである。
【
図13】スマートフォンの画面表示の例であり、
図13(A)は乗車時のコード取得処理において機内モード状態であると判定した場合の表示例を表したものであり、
図13(B)は降車時のコード取得処理において機内モード状態であると判定した場合の表示例を表したものである。
【
図14】
図3に示す運賃三角表データに基づいて利用運賃が求められることを表した説明図である。
【
図15】スマートフォンの画面表示の例であり、
図14(A)は処理結果告知処理における決済完了の表示例を表したもの、
図14(B)は処理結果告知処理における決済未了の表示例を表したものである。
【発明を実施するための形態】
【0032】
以下、本発明の運賃収受システムの実施形態について図を参照して説明する。
【0033】
本発明の運賃収受システムの一実施形態は、路線バス(以下「バス」という)90を利用する乗客(以下「利用者」という)から利用運賃を収受する運賃収受システム10であり、利用者が携帯情報端末装置としてスマートフォン50を所持していることを前提とするものである。利用者のスマートフォン50には、後述する運賃精算用のアプリケーションプログラム(以下「運賃精算アプリ」という)がインストールされている。
【0034】
図1に示すように、本実施形態のバス90は、ワンマン運行方式であり、利用者が後方の乗車口91から乗車した後、前方の降車口93から降車する際に利用運賃を支払う「後乗り前降り後払い方式」を採用している。「後乗り前降り後払い方式」は、運賃後払い方式の一態様であり、典型的には、距離に応じて金額が増加する運賃体系を採る。そのため、利用運賃の取得には、例えば、後述する運賃三角表データが用いられる。
【0035】
このバス90には、降車口93付近に利用者が現金やICカードで利用運賃の支払いを行うことが可能な運賃箱が設けられている。本実施形態では、この運賃箱がホスト機器40の役割を果たす。ホスト機器40は、バス90に搭載される機器装置であれば、このような運賃箱のほかに、例えば、利用者に乗車区間に対応した運賃を表示する運賃表示器、次の停留所名等を車内に放送する車内放送装置や、車外に向けて当該バス90の行き先等を表示する行先表示装置の操作盤等の車載機器でもよい。
【0036】
運賃収受システム10は、乗車表示端末20、降車表示端末30、ホスト機器40、スマートフォン50、管理サーバ60、決済サーバ70等により構成されている。これらのうち、乗車表示端末20、降車表示端末30およびホスト機器40は、バス90に搭載されており、スマートフォン50は利用者が所持している。管理サーバ60および決済サーバ70は、例えば、バス90の運行事業者の社屋内に収容されている。これらのサーバ60,70は、他の事業者が管理するレンタルサーバを利用していてもよい。
【0037】
管理サーバ60や決済サーバ70は、例えば、図略のインターネット接続事業者(ISP)を介してインターネットNに接続されている。また、スマートフォン50は、移動体通信事業者(MNO)が管理する基地局80等を介してインターネットNに接続されている。インターネットNは、データを伝送する情報通信回線網の一例であり、インターネットプロトコルを使用してコンピュータを相互接続するコンピュータネットワークである。なお、スマートフォン50と管理サーバ60の間およびスマートフォン50と決済サーバ70の間でデータ通信可能であれば、インターネットN以外の情報通信回線網でもよい。
【0038】
図1および
図2に示すように、乗車表示端末20は、主に、制御ユニット21、表示ユニット23、照明ユニット25、通信ユニット27等により構成されており、本実施形態では、例えば、バス90の乗車口91付近に設けられる握り棒Pに取り付けられている。乗車表示端末20の外観は、例えば、制御ユニット21等を収容する矩形箱形状のハウジングと、このハウジング前面に設けられる表示ユニット23の矩形状の液晶表示パネルと、により構成されている。
【0039】
制御ユニット21は、後述するホスト機器40の制御ユニット41とほぼ同様に、MPU、メモリ(DRAM、ROM)、インタフェース等により構成されるコントローラであり、本実施形態では、表示ユニット23、照明ユニット25や通信ユニット27等が接続されている。メモリのROMには、表示ユニット23、照明ユニット25や通信ユニット27をMPUが制御可能に構成される所定のシステムプログラムや、後述のコード出力処理200をMPUが実行可能に構成されるコード出力プログラム等が格納されている。
【0040】
表示ユニット23は、表示デバイスとして液晶表示パネルや電子ペーパを備えたディスプレィ装置であり、制御ユニット21に対して、例えば、液晶映像パラレルインタフェースやLVDS(Low voltage differential signaling)インタフェースやSPI(Serial Peripheral Interface)等を介して接続されている。画面のサイズは、後述する二次元コードDCを十分に表示可能な大きさ、例えば、横縦比率が4:3のスクエア型の場合には5~6インチに設定され、また横縦比率が16:9のワイド型の場合には6~7インチに設定されている。
【0041】
照明ユニット25は、表示ユニット23を照らす面発光可能な照明デバイスであり、例えば、光源はLEDや有機EL等である。照明ユニット25は、シリアルインタフェースやGPIO(General-purpose input/output)インタフェースを介して制御ユニット21に接続されており、制御ユニット21により発光のオンオフや輝度が制御され得るように構成されている。例えば、表示ユニット23の表示デバイスが液晶表示パネルである場合には、照明ユニット25は表示ユニット23の裏側に設けられる。また、表示デバイスが電子ペーパである場合には、照明ユニット25は、表示ユニット23の表側に設けられる。
【0042】
本実施形態では、乗車表示端末20は表示ユニット23を照らす照明ユニット25を備えることから、例えば、夜間等、乗車表示端末20の周囲が暗い環境になっても表示ユニット23に表示される二次元コードDCを照明ユニット25が照らすことが可能になる。そのため、スマートフォン50による二次元コードDCの取り込み場面において、カメラ55による二次元コードDCの画像撮影の成功率を高めることが可能になる。
【0043】
通信ユニット27は、有線通信回線15を介して制御ユニット21がホスト機器40とデータ通信可能に構成されるシリアル通信装置である。本実施形態では、ホスト機器40、乗車表示端末20、降車表示端末30等の間をマルチドロップで接続可能なRS-458に準拠したものを使用しているが、ホスト機器40と乗車表示端末20の間やホスト機器40と降車表示端末30の間をそれぞれPP(Point to Point)接続する場合には、例えば、カレントループやRS-422に準拠したものを用いてもよい。また、Ethernetに準拠したLANを用いてホスト機器40、乗車表示端末20、降車表示端末30等を接続してもよい。
【0044】
本実施形態では、このような通信ユニット27および有線通信回線15を介してホスト機器40から乗車表示端末20に対して、表示や照明に関する制御コマンドや後述する停留所情報等が送られて来る。また乗車開扉信号も送られて来る。乗車開扉信号は、バス90の乗車扉を開くタイミングで他の車載機器(不図示)から送出される信号で乗車扉開閉装置(不図示)に開扉を指示するものである。また、バス90の乗車扉を閉じるために他の車載機器から乗車扉開閉装置に送出されて閉扉を指示する乗車閉扉信号が乗車表示端末20に送られる場合もある。
【0045】
なお、破線で表されている符号17は、手動で操作する押しボタン(以下「停留所送りボタン」という)をバス90の乗務員(運転士)が操作するごとに当該押しボタンから出力される停留所送り信号であり、歩進信号と呼ばれる場合もある。停留所送り信号17は、バス90の走行に伴って次に停車を予定する停留所(以下「次停留所」という)に合わせて、運賃表示器、車内放送装置、運賃箱等の車載機器の制御を進めるトリガ信号のことである。停留所送り信号17により得られる情報のことを「停留所送り情報」という。
【0046】
なお、このような乗務員(運転士)が手動で操作する停留所送りボタンに代えて、GPS(Global Positioning System)により当該バス90の走行位置を把握して自動的に停留所送り情報を出力するものを用いてもよい。これにより、乗務員(運転士)による停留所送りボタンの操作忘れによる停留所送り情報の出力抜けが発生しないため、乗車表示端末20や降車表示端末30に後述する二次元コードDCが表示されない事態を防ぐことが可能になる。
【0047】
また、制御ユニット21、表示ユニット23、照明ユニット25および通信ユニット27には、ハウジング内に設けられる図略の電源ユニットからそれぞれの駆動電力が供給されている。そのため、
図2には図示されていないが、乗車表示端末20には、有線通信回線15と電源ラインのワイヤハーネスが接続されている。また、有線通信回線15は、Bluetooth(登録商標)やZigBee(登録商標)等の無線規格に準拠した無線通信回線に代えてもよい。この場合には、通信ユニット27は、Bluetooth(登録商標)やZigBee(登録商標)等に対応したものに置き換える必要がある。
【0048】
降車表示端末30は、例えば、バス90の降車口93付近に設けられる握り棒P等に取り付けられており、乗車表示端末20と同様にハードウェアが構成されている。つまり、降車表示端末30は、主に、制御ユニット31、表示ユニット33、照明ユニット35、通信ユニット37等により構成されており、前述した乗車表示端末20の、制御ユニット21、表示ユニット23、照明ユニット25、通信ユニット27にそれぞれ対応する。そのため、ここでは制御ユニット31等の構成や接続関係の説明を省略する。
【0049】
なお、降車表示端末30はバス90の降車口93付近に設けられているため、バス90の降車扉を開くタイミングで他の車載機器(不図示)から、降車扉信号が送られて来る。降車扉信号は、降車扉開閉装置に開扉を指示する信号である。また、降車口93付近の運賃箱に当該利用者が見ることのできる小型ディスプレィが設けられている場合には、この小型ディスプレィを降車表示端末30に代えて使用してもよい。この場合には、降車表示端末30のハードウェアが削減でき、設備コストをさらに減らすことが可能になる。
【0050】
ホスト機器40は、本実施形態では運賃箱がこれに相当する。そのため、制御ユニット41は運賃箱の制御ユニットが、また通信ユニット47は運賃箱の通信ユニットが、それぞれその役割を担う。なお、ホスト機器40は、このように既存の運賃箱等を用いることなく、既存の運賃箱等に関係なくホスト機器40自体を単独で新規に設けてもよい。
【0051】
制御ユニット41は、運賃箱に設けられている運賃収受機構の駆動ユニット、運賃三角表データ等が書き込まれたデータカセット、ICカードリーダライタ、ディスプレィ等の各種ユニット46や、通信ユニット47等を制御するコントローラであり、MPU42、メモリ43、入出力インタフェース44、図略の時計ユニット等から構成されている。MPU42は、各種ユニット46等を制御する演算処理装置であり、システムバス45等を介して、メモリ43や入出力インタフェース44等と接続されている。
【0052】
メモリ43は、半導体記憶装置であり、MPU42が使用する主記憶空間を構成するものである。本実施形態では、プログラム領域を担うROMとワーク領域やデータ領域に割り当てられるDRAMとにより構成されている。本実施形態では、ROMには、各種ユニット46を制御するシステムプログラムや、後述する停留所情報等送出処理100を可能にする停留所情報等送出プログラム等、各種の制御プログラムが格納されている。
【0053】
なお、データカセットのメモリには、運賃三角表データのほかに、その系統番号、事業者名称、営業所名称、車両番号等が書き込まれているため、例えば、バス90の運行路線が変更されるごとにその運行路線に対応したものに取り替えられる。運賃三角表データの例は、
図3に図示されている。
【0054】
入出力インタフェース44は、制御ユニット41の周辺装置に対して、シリアルやパラレルのデータのやり取りを仲介する入出力インタフェース装置である。本実施形態では、各種ユニット46や通信ユニット47等と接続可能に構成されている。入出力インタフェース44は、各種ユニット46を駆動するドライバ回路を備えている場合もある。
【0055】
通信ユニット47は、有線通信回線15を介して制御ユニット41が乗車表示端末20や降車表示端末30とデータ通信可能に構成されるシリアル通信装置であり、これらの通信ユニット27,37であるスレーブに対してホストとして機能するものである。本実施形態では、RS-458に準拠したものを使用しており、ホスト機器40、乗車表示端末20、降車表示端末30等の間を有線通信回線15でマルチドロップ接続している。通信プロトコルは、ホスト機器40を含めて有線通信回線15に接続されている乗車表示端末20、降車表示端末30等をIDで識別可能なものを使用している。
【0056】
スマートフォン50は、利用者が所有(所持)する携帯情報端末装置であり、「携帯型情報端末」や「携帯端末」と呼ばれる場合もある。スマートフォン50は、一般に市販されているものであり、制御ユニット51(MPU、メモリ等)、無線ユニット52、表示ユニット53、カメラ55、メモリカード、バッテリ等により構成され、これらが厚さ数ミリ程度の薄板状のケース内に収容されている。
【0057】
なお、このようなスマートフォン50の代わりに、画面サイズが8~10インチの表示ユニットを有するデータ通信可能なタブレットタイプのパーソナルコンピュータ(以下「タブレット」という)を利用者が所持していてもよい。また、スマートフォンやタブレットでなく、携帯情報端末装置として、一般に市販されているカメラ付きの携帯電話装置(カメラ付き携帯)を利用者が所持していてもよい。
【0058】
本実施形態では、スマートフォン50は、例えば、Android(登録商標)やiOS(登録商標)等のOS(基本ソフトウェア)で制御ユニット51が動作しており、後述する運賃精算処理300を実行する運賃精算アプリもこれらのOS上で動作可能に構成されている。スマートフォン50のOSはAndroid(登録商標)やiOS(登録商標)以外のものでもよいが、その場合には運賃精算アプリもそのOS上で動作するように対応させる必要がある。無線ユニット52は、移動体通信事業者(MNO)の無線通信回線85を介してデータ通信や音声通信可能に構成されている。
【0059】
カメラ55は、CCDやCMOS等の固体撮像素子を備えたものであり、スマートフォン50の裏側にレンズを有し、乗車表示端末20や降車表示端末30に表示された二次元コードDCの画像を撮影可能に構成されている。カメラ55で撮影した画像データは、制御ユニット51で情報処理することが可能であり、本実施形態では、運賃精算アプリによりデコードして二次元コードDCに埋め込まれた情報を取得可能にしている。なお、タブレットの場合は、表示ユニットの画面サイズが異なる以外はスマートフォン50とほぼ同様に構成される。
【0060】
管理サーバ60および決済サーバ70は、いずれも、主に、制御装置、データベース装置、ネットワーク機器等から構成されているファイルサーバである。制御装置は、データベース装置やネットワーク機器に接続されてこれらを制御する情報処理装置であり、例えば、サーバコンピュータがこれに相当する。データベース装置は、記憶容量が数100TB(テラバイト)クラスの大容量情報記憶媒体である。ネットワーク機器は、例えば、インターネットNに接続されている。
【0061】
管理サーバ60と決済サーバ70のハードウェアの相違は、例えば、制御装置の処理速度やデータベース装置の記憶容量になるが、基本的には両サーバ60,70はハードウェア的にはほぼ同様に構成される。ソフトウェア的には、管理サーバ60の場合、例えば、後述する停留所情報等記録処理をその制御装置が実行可能な停留所情報等記録プログラムが、当該制御装置のハードディスク装置等に格納される。また、決済サーバ70の場合には、例えば、後述する運賃決済処理をその制御装置が実行可能な運賃決済プログラムが、当該制御装置のハードディスク装置等に格納される。
【0062】
このため、本実施形態では、管理サーバ60と決済サーバ70を別体に構成したが、これらのサーバ60,70を同じサーバで構成してもよい。即ち、管理サーバ60に決済サーバ70の機能を持たせたり、決済サーバ70に管理サーバ60を機能を持たせたりしてもよい。この場合には、単一のサーバが備える制御装置のハードディスク装置等に停留所情報等記録プログラムや運賃決済プログラムが格納される。
【0063】
このように乗車表示端末20、降車表示端末30、ホスト機器40、スマートフォン50、管理サーバ60や決済サーバ70を構成することによって、本実施形態の運賃収受システム10では、
図11に表したシーケンス図のように、利用者Mがバス90に乗車して降車するまでの間において、停留所情報等送出処理100、コード出力処理200、運賃精算処理300等の各処理を行う。
【0064】
なお、利用者Mは、運賃収受システム10を利用するための事前準備として、例えば、運賃精算処理300を当該利用者Mのスマートフォン50において実行し得る運賃精算アプリをバス90の運行事業者やスマートフォン用のアプリケーションプログラム(スマホアプリ)の販売業者等が運営するウェブサイトからダウンロードして当該スマートフォン50にインストール(実装)する必要がある。
【0065】
また、スマートフォン50において運賃精算アプリを起動した後、初期設定作業として、利用者Mの氏名、生年月日、性別、住所、電話番号、職業等の個人情報を当該スマートフォン50や管理サーバ60に設定したり、またクレジットカード等の決済情報を当該スマートフォン50に登録したりする必要がある。セキュアな情報管理を行う場合には、個人情報や決済情報は管理サーバ60にのみ登録する。なお、スマートフォン50は、MACアドレスやデバイスIDにより一意に特定することが可能である。また、スマートフォン50のSIMカードに記憶されているIMSI(International Mobile Subscriber Identity)でも特定できる。これにより、スマートフォン50の所持者は利用者Mであることがわかるため、後述の停留所情報等ISと利用者Mとの関連付けが可能になる。
【0066】
[停留所情報等送出処理100]
図11に示すように、本実施形態の運賃収受システム10では、まずバス90のホスト機器40が停留所情報等送出処理100を開始する。即ち、ホスト機器40では、前述したように制御ユニット41のメモリ43のROMに停留所情報等送出プログラムが格納されている。そのため、バス90の運行開始前においてホスト機器40に電源が投入されると、その直後にメモリ43のDRAMに展開される停留所情報等送出プログラムを、MPU42が実行することによって
図4に示す停留所情報等送出処理100が開始される。なお、DRAMに展開されたものではなくROMに格納された停留所情報等送出プログラムをMPU42が直接実行するように構成してもよい。
【0067】
図4に示すように、停留所情報等送出処理100では、まずステップS101により所定の初期化処理が行われる。この処理では、例えば、制御ユニット41のメモリ43の本処理用のワーク領域やフラグをクリアしたり、ほぼ同時期に起動される乗車表示端末20や降車表示端末30に対する初期設定用の制御コマンドの送出が行われたりする。続くステップS102では、当該バス90が走行する系統番号を乗務員が入力する系統番号入力処理が行われる。
【0068】
次のステップS103では始発停留所情報等読出し処理が行われる。始発停留所情報等は、バス90の始発の停留所BSaに関する情報であり、例えば、次に列挙する(1)~(8)の情報である。これらのうち、(1)~(4)はバス90の走行中に変動するものであり、(5)~(8)は固定されているものである。
(1) 整理券番号
(2) 各整理券番号に対応した運賃データ
(3) 停留所名称
(4) 停留所連番号
(5) 系統番号
(6) 事業者名称
(7) 営業所名称
(8) 車両番号
【0069】
始発の停留所BSaにおいては、(1)の整理券番号は「4」であり、(2)の運賃データは、整理券番号4に対応した200円だけである。また、(3)の停留所名称は、例えば「ABC駅」であり、(4)の停留所連番号は、例えば「0」である。これらの各情報は停留所BSごとに変更される。これに対して(5)~(8)の各情報は停留所BSが進んでも変更されることのない情報である。例えば、(5)の系統番号は「01」、(6)の事業者名称は「XYZ交通」、(7)の営業所名称は「○×△営業所」、(8)の車両番号は「123」等である。本実施形態では、これらの各情報は、例えば、ホスト機器40に接続されているデータカセットのメモリに記憶されているため、そこから読み出して前記の(1)~(8)の各情報を得る(
図3参照)。
【0070】
次のステップS105では始発停留所情報等送出処理が行われる。運行開始前の始発の停留所BSaにおいては、運賃表示器等の車載機器の電源が投入されると、押しボタンから停留所送り信号17が出力されなくても、運賃表示器や車内放送装置により当該バス90の系統番号や行き先等の案内情報が自動的に行われて運賃箱等も所定の制御処理が開始される。そのため、ホスト機器40においても、乗車表示端末20や降車表示端末30に対して始発の停留所BSaの停留所情報等ISaを生成して送出する(
図11参照)。
【0071】
送出する始発の停留所情報等ISaには、上記(1)~(8)の各情報に加えて(9)の表示更新日時が付加される。即ち、ホスト機器40では、停留所情報等ISaを送出する直前時点の年月日時分秒の時刻情報を(9)の表示更新日時として追加して停留所情報等ISaを生成する。例えば、2019年9月25日17時46分をバイナリデータで表したものを追加する。本実施形態では、停留所情報等ISaは、例えば、上記(1),(2),(4),(5),(8),(9)をバイナリデータ、(3),(6),(7)をテキストデータでそれぞれ表したものとして生成される。なお、これら(1)~(9)をすべてテキストデータで生成してもよい。
【0072】
これにより、乗車表示端末20や降車表示端末30では、後述するように、
図5に示すコード出力処理200によって停留所情報等ISaを取得し(S203)、表示ユニット23,33に二次元コードDC等を出力することが可能になる(S213,S215,S217)。これらの表示端末20,30の制御ユニット21,31により実行されるコード出力処理200の内容については後で詳述する。
【0073】
次のステップS107では停留所送り情報取得処理が行われる。停留所送り情報は、前述したように乗務員(運転士)が図略の押しボタンを操作するごとに出力される停留所送り信号17により得られる情報のことである。この停留所送り情報の入力の有無は、例えば、所定の割り込み処理の有無や所定のフラグのオンオフにより得ることができる。停留所送り情報が得られた場合には、次停留所に合わせて、運賃表示器、車内放送装置、運賃箱等の車載機器の制御を進める指示を乗務員が行ったことになる。
【0074】
このため、続くステップS109により、停留所送り情報を取得したか否かを判定し、取得した場合には(S109;Yes)、次のステップS111に処理を進め、停留所送り情報を取得したと判定できない(取得していない)場合には(S109;No)、ステップS107に戻り、再度、停留所送り情報取得処理を行う。つまり、停留所送り情報を取得するまでステップS107,S109を繰り返し行う。
【0075】
ステップS111では次停留所情報等読出し処理が行われる。この処理では、ホスト機器40のデータカセットから、次停留所BSbに関する情報として上記(1)~(8)の次停留所情報等を読み出す。もし読み出した次停留所情報等が上記(1)~(8)の各情報ではなく、次停留所が存在しない旨の終了情報であった場合には、次のステップS113による判定処理により次停留所がない、つまり前停留所が終着の停留所であったと判定して(S113;Yes)、本停留所情報等送出処理100を終了する。
【0076】
ステップS111により読み出した次停留所情報等が上記(1)~(8)の各情報である場合には次停留所BSbがあると判定して(S113;No)、続くステップS115に処理を移行する。ステップS115では停留所情報等送出処理が行われる。この処理は、前述の始発停留所情報等送出処理(S105)と同様に、送出直前時点の(9)表示更新日時の情報を付加して停留所情報等ISbを生成して乗車表示端末20や降車表示端末30に送出する。
【0077】
ここで送出される停留所情報等ISbは、上記(1)~(4),(9)が変更される。例えば、
図3に示す運賃三角表データの場合、停留所BSbに対する停留所情報等ISbは、(1)の整理券番号が「3」になり、(2)の運賃データが整理券番号3に対応した200円と整理券番号4に対応した200円になる。(3)の停留所名称は「○×△1丁目」になり、(4)の停留所連番号は「1」になるため、それぞれ変更される。また(9)の表示更新日時は、例えば、2019年9月25日17時52分に変更される。
【0078】
ステップS115の停留所情報等送出処理が終わると、ステップS107に戻り停留所送り情報取得処理が行われる。そして、停留所送り情報を取得するごとに(S107,S109:Yes)、次停留所情報等を読み出して(S111)、停留所情報等ISを生成して乗車表示端末20や降車表示端末30に送出する(S115)。これにより、乗車表示端末20や降車表示端末30では、停留所BSa,BSb,…,BSdごとに異なる二次元コードDCa,DCb,…,DCdを表示ユニット23,33に表示することが可能になる(
図11参照)。
【0079】
[コード出力処理200]
次に乗車表示端末20や降車表示端末30が実行するコード出力処理200を説明する。これらの表示端末20,30も、前述したように制御ユニット21,31のメモリにコード出力プログラムが格納されている。そのため、バス90の運行開始前においてホスト機器40とともに表示端末20,30に電源が投入されると、その直後にメモリのDRAMに展開されるコード出力プログラムを、制御ユニット21,31のMPUが実行することによって
図5に示すコード出力処理200が開始される。なお、DRAMに展開されたものではなくROMに格納されたコード出力プログラムをMPUが直接実行するように構成してもよい。
【0080】
乗車表示端末20および降車表示端末30で実行されるコード出力処理200は、これらの表示端末20,30のいずれも同様に情報処理がされるため、ここでは乗車表示端末20のコード出力処理200を代表して説明する。なお、降車表示端末30の場合には、制御ユニット21を制御ユニット31に置き換え、また表示ユニット23を表示ユニット33に置き換え、乗車口91の乗車扉を降車口93の降車扉に置き換え、乗車開扉信号を降車開扉信号に置き換えると処理内容が理解できる。
【0081】
図5に示すように、コード出力処理200では、まずステップS201により所定の初期化処理が行われる。この処理では、例えば、制御ユニット21のメモリ(DRAMやSRAM)のワーク領域、タイマーカウンタやフラグをクリアしたり、ほぼ同時期に起動されるホスト機器40から送られて来る制御コマンドに基づいて初期設定等が行われたりする。
【0082】
次のステップS203では停留所情報等取得処理が行われる。前述したように、電源投入後の運行開始前のホスト機器40では、始発の停留所BSaの停留所情報等ISaを送出するので(
図11参照)、この処理では、制御ユニット21の入力バッファに保持されている停留所情報等ISaを取得する。取得した場合には(S205;Yes)、続くステップS207でエンコード処理が行われ、取得していない場合には(S205;No)、取得するまでステップS203,S205を繰り返し行う。
【0083】
ステップS207のエンコード処理では、ステップS203により取得した停留所情報等ISaを暗号化した後、二次元コードDCを生成する。本実施形態では、停留所情報等ISを直接、二次元コードにするのではなく、暗号化したものを二次元コードDCにしているため、二次元コードDCが不正に生成されるのを防止可能にしている。
【0084】
本実施形態では、二次元コードDCは、例えばQRコードである。なお、QRコードは登録商標である(以下同じ)。本実施形態では、停留所情報等ISaは、例えば、次に列挙する(1)~(9)の情報であり、このうち(1),(2),(4),(5),(8),(9)はバイナリデータ、(3),(6),(7)はテキストデータでそれぞれ表されており暗号化されていない(平文データ)。なお、これら(1)~(9)をすべてテキストデータで生成してもよい。
(1) 整理券番号
(2) 各整理券番号に対応した運賃データ
(3) 停留所名称
(4) 停留所連番号
(5) 系統番号
(6) 事業者名称
(7) 営業所名称
(8) 車両番号
(9) 表示更新日時
【0085】
このため、ステップS207では、このような平文データを所定の暗号鍵で暗号化して暗文データに変換(暗号化)した後、二次元コードDCの画像情報を生成する。本実施形態では、暗号鍵は共通鍵であり、例えば、乗車表示端末20の製造時に制御ユニット21のメモリ(ROMやSRAM)に暗号鍵が書き込まれる。本実施形態では、二次元コードDCは、例えば、サイズが21×21モジュールのタイプ1(型番1)のQRコードであるが、データ容量が不足する場合には、25×25モジュールのタイプ2(型番2)のQRコードやタイプ3(型番3)以上のQRコードを用いてもよい。
【0086】
続くステップS209では開扉信号取得処理が行われる。本実施形態では、乗車口91の乗車扉を開けるタイミングで、有線通信回線15を介して他の車載機器(不図示)から乗車表示端末20に乗車開扉信号が送られて来る。乗車開扉信号の有無は、例えば、所定の割り込み処理の有無や所定のフラグのオンオフにより得ることができるため、この処理では、乗車開扉信号の情報(開扉情報)を所定の割り込み処理の有無やフラグの状態により取得する。そして、乗車開扉信号を取得していると判定した場合には(S211;Yes)、次のステップS213のコード出力開始処理により二次元コードDCの画像情報を表示ユニット23に出力する。
【0087】
乗車開扉信号を取得していないと判定した場合には(S211;No)、取得するまでステップS209,S211を繰り返し行う。本実施形態では、ステップS213によるコード出力開始処理は、乗車開扉信号を取得した後(S211;Yes)、乗車開扉信号を取得できなくなってから(S215;No)、予め定められた所定時間(例えば、30秒間または1分間等)が経過するまで継続される(S216;No)。これにより、乗車扉が開いている間と扉が閉じてから所定時間(例えば30秒間)が経過するまでは二次元コードDCが乗車表示端末20や降車表示端末30に表示される。そのため、扉が閉じる直前に乗車した利用者や乗車時に二次元コードDCの取得を忘れてそれに直ぐ気がついた利用者等も二次元コードDCの取得が可能になる。また、バス90の走行中においては、乗車表示端末20や降車表示端末30に二次元コードDCが表示されないため、二次元コードDCの不正取得を防止することが可能になる。
【0088】
即ち、開扉期間中に実行される開扉信号取得処理(S214)で乗車扉開信号を取得できなくなったと判定(S215;No)した直後から、カウントを開始するタイマーカウンタの値に基づいて、ステップS216により所定時間が経過した否かを判定する。そして、所定時間が経過したと判定すると(S216;Yes)、続くステップS217のコード出力終了処理により表示ユニット23に対する二次元コードDCの画像情報の出力を終了して、前述の停留所情報等取得処理(S203)に処理を戻す。
【0089】
これにより、
図11に示すように、例えば、乗車表示端末20では、始発の停留所BSaにおいて乗車扉が開くと(開扉→)、そのタイミングで表示ユニット23に二次元コードDCaの表示を開始し乗車扉が閉じてから(閉扉→)所定時間の経過後に表示を終了する。また、次の停留所BSbにおいても、乗車扉が開くと(開扉→)、乗車表示端末20が二次元コードDCbの表示を開始し乗車扉が閉じてから(閉扉→)所定時間の経過後に表示を終了し、また降車扉が開く(開扉→)と、降車表示端末30が二次元コードDCbの表示を開始し所定時間の経過後に表示を終了する。
【0090】
同様に、停留所BSdにおいて、乗車扉が開くと(開扉→)乗車表示端末20が二次元コードDCdの表示を開始し、降車扉が開く(開扉→)と降車表示端末30が二次元コードDCdの表示を開始する。そして、それぞれの扉が閉じてから(閉扉→)、所定時間が経過すると、表示ユニット23,33による二次元コードDCdのそれぞれの表示を終了する。
【0091】
したがって、バス90の走行中には、乗車表示端末20や降車表示端末30に二次元コードDCが表示されないことから、例えば、乗車時に乗車表示端末20に表示された二次元コードDCbをスマートフォン50で取得することなく、乗車後に他の停留所に対応して二次元コードDCbよりも後に表示された二次元コードDCdを事後的に取得するような二次元コードDCの不正取得を防止することが可能になる。
【0092】
[運賃精算処理300]
続いてスマートフォン50が実行する運賃精算処理300を説明する。なお、ここでは運賃精算処理300を実行可能な運賃精算アプリがスマートフォン50にインストールされ、かつ、利用者Mの個人情報やクレジットカード等の決済情報が、管理サーバ60や決済サーバ70に登録されていることを前提とする。
【0093】
図11に示すように、利用者Mは、バス90に乗車する前にスマートフォン50を操作して運賃精算アプリを起動する。これにより、スマートフォン50の制御ユニット51によって
図6に示す運賃精算処理300が開始される。
【0094】
図6に示すように、運賃精算処理300では、まずステップS301により所定の初期化処理が行われる。この処理では、例えば、制御ユニット51のメモリ(DRAM)の本処理用のワーク領域やフラグ等がクリアされる。次のステップS303では選択メニュー表示処理が行われる。
【0095】
本実施形態では、例えば、
図12(A)に示すような選択メニュー画面がスマートフォン50の表示ユニット53に表示される(S303)。表示ユニット53の画面には、「乗車」、「降車」、「終了」および「ヘルプ」の各ボタンが表示されるため、利用者Mはこれらのボタンに触れることでそれぞれの機能を選択する。
【0096】
例えば、「乗車」は、乗車口91の乗車表示端末20に表示される二次元コードDCを取得する機能を選択するボタンであり、利用者Mが「降車」ボタンを選択する前のみ選択可能に構成されている。通常は、利用者Mがバス90の乗車前に選択する。また「降車」は、降車口93の降車表示端末30に表示される二次元コードDCを取得する機能を選択するボタンであり、利用者Mが「乗車」ボタンを選択した後のみに選択可能に構成されている。通常は、バス90に乗車した利用者Mが降車前に選択する。
【0097】
「ヘルプ」は、利用者Mがこの運賃精算アプリの使い方を知りたい場合に選択するボタンである。「終了」は、利用者Mがこの運賃精算アプリを終了したい場合に選択するボタンである。「ヘルプ」ボタンと「終了」ボタンは、選択メニュー画面が表示されている状態であれば、いつでも選択できる。図示されていないが、本実施形態では、選択不能のボタンは、ボタン表示の色調を弱く(淡く)して視覚的に選択できないことを表している。
【0098】
なお、図示されていないが、利用履歴を表示させて確認することができる「利用履歴」ボタンや、フリーパスや定期券等の予め定められた期間だけ利用可能な機能を運賃精算アプリが有する場合には、その有効期限を表示させて確認することができる「有効期限」ボタン等がスマートフォン50の選択メニュー画面に表示される。
【0099】
ステップS305により利用者Mの選択入力の有無を判定して入力があるまで待つ(S305;No)。そして、選択入力があった場合には、その選択が「乗車」であれば(S305;Yes:乗車)、続くステップS307に処理を移行し、「終了」であれば(S305;Yes:終了)、本運賃精算処理300を終えて運賃精算アプリを終了する。
【0100】
なお、利用者Mは、運賃精算アプリにおいて「乗車」ボタンを選択する前は「降車」ボタンを選択することができないため、このステップS305では「降車」ボタンの入力判定は行われない。また、「ヘルプ」ボタンが選択入力された場合は、図略の別のタスク(スレッド、プログラム)においてヘルプ画面等が表示される。
【0101】
利用者Mの選択入力が「乗車」であった場合には、続くステップS307によりコード取得処理が行われる。この処理は、サブルーチンとして
図7にその流れが図示されているため、ここからは
図7も参照しながら説明する。
【0102】
[コード取得処理400]
図7に示すように、コード取得処理400では、ステップS401の所定の初期化処理により、デコードに使用するワーク領域やフラグ等をクリアした後、ステップS403のコード情報取得処理によって二次元コードDCを取得する。本実施形態では、二次元コードDCの取得は、カメラ55で二次元コードDCの画像を撮影することにより行う。
【0103】
この処理では、例えば、
図12(B)に示すように、四隅を「」で囲んだガイド枠によって被写体の位置および範囲を明示することによって、このガイド枠内に二次元コードDCが収まるように利用者Mによるスマートフォン50の操作を案内する。スマートフォン50のカメラ55は、焦点距離、露出、シャッタスピードおよびシャッタタイミングを適切に設定する自動調整機能を有する。そのため、二次元コードDCの全体がガイド枠内に入ると、カメラ55が自動で撮影する。
【0104】
前述したように、バス90の乗車扉が開いた後から乗車扉が閉じても所定期間中(例えば30秒間)、乗車口91の乗車表示端末20に二次元コードDCaが表示され続ける。そのため、利用者Mは、乗車口91から乗車する際にスマートフォン50のカメラ55で二次元コードDCaを撮影する。乗車する際(乗車時)に撮影された二次元コードDCaは、乗車停留所情報として、制御ユニット51のメモリのワーク領域に格納される(
図11参照)。
【0105】
二次元コードDCが撮影できた場合には、ステップS405の判定処理により取得したと判定して(S405;Yes)、次のステップS407のデコード処理を行う。二次元コードDCが撮影できない場合には(S405;No)、撮影できるまでコード情報取得処理(S403)を行う。なお、所定時間経過しても、二次元コードDCが撮影できない場合には、本コード取得処理400を強制的に終了して、選択メニュー表示処理(S303)に戻るように処理の流れを構成してもよい。
【0106】
ステップS407では取得した二次元コードDCのデコード処理が行われる。本実施形態では、二次元コードDCはQRコードであるため、所定のアルゴリズムに従って解析した後、得られた暗文データを所定の暗号鍵で復号して平文データに戻す。この暗号鍵は、共通鍵であり、ウェブサイトから運賃精算アプリをダウンロードしてインストールする際にスマートフォン50が取得している。平文データには、停留所情報等ISとして、前述した(1)~(9)の各情報が含まれている。つまり、二次元コードDCから停留所情報等ISが取り出される。なお、暗号鍵は、セキュリティの強度を高めるため、初回のインストール時のみならず、定期的に更新(ダウンロード)されるのが望ましい。
【0107】
次のステップS409では停留所情報等記憶処理が行われる。この処理では、デコードして取り出した停留所情報等IS(乗車停留所情報)を制御ユニット51のメモリのワーク領域に記憶する。続くステップS411ではモード情報取得処理が行われる。この処理では、スマートフォン50の無線ユニット52の動作モード情報を取得し、取得した動作モード情報に基づいて、利用可能ではない機内モードに設定されているか否かをステップS413により判定する。
【0108】
そして、無線ユニット52を利用不能な機内モード、つまり無線通信回線を介した情報通信を行わないようにスマートフォン50が設定されている場合には(S413;Yes)、停留所情報等ISを管理サーバ60に送信することができないことから、ステップS415により機内モード表示処理が行われる。この処理では、例えば、
図13(A)に示すような機内モードの解除を促すメッセージ「機内モードを解除してくださ」がスマートフォン50の表示ユニット53の画面に表示される。このメッセージの背景色は、例えば、赤色に設定され、文字色は白色または黄色に設定される。これにより、利用者Mに対して色彩的にインパクトを与え得るメッセージの表示が可能になる。
【0109】
この
図13(A)に示す画面の例では、乗車した停留所名称として「ABC駅」が表示され、また整理券番号として「4」も表示されている。これは、ステップS407でデコードした停留所情報等ISaから得た情報のうち、(1)の整理券番号および(3)の停留所名称の各情報である。このほか(2)の運賃データとして「整理券番号4に対応した200円」、(4)の停留所連番号として「0」、(5)の系統番号として「01」、(6)の事業者名称として「XYZ交通」、(7)の営業所名称として「○×△営業所」、(8)の車両番号として「123」、(9)の表示更新日時として「2019年9月25日17時46分」が得られている。
【0110】
ステップS415によるこのようなメッセージの表示は、機内モードが解除されるまで継続される(S413;Yes→S411)。もとからスマートフォン50が機内モードに設定されていない場合や機内モードが解除された場合には(S413;No)、ステップS417により無線送信処理が行われる。この無線送信処理は、管理サーバ60に対する送信処理であり、サブルーチンとして
図8にその流れが図示されているため、ここからはさらに
図8も参照しながら説明する。
【0111】
[無線送信処理500]
図8に示すように、無線送信処理500では、ステップS501の所定の初期化処理により、送信バッファに使用するワーク領域、リトライカウンタやフラグ等をクリアした後、ステップS503の送信バッファセット処理が行われる。送信バッファは、無線ユニット52が無線送信するデータフォーマット(送信フォーマット)を所定の通信プロトコルに準拠させるために設けられている。そのため、この処理では、宛先情報として管理サーバ60のIPアドレス情報、送信元情報としてスマートフォン50のIPアドレス情報や停留所情報等ISaを送信バッファにセットする。
【0112】
続くステップS505では送信処理が行われる。これにより、送信バッファにセットされた停留所情報等ISa(乗車停留所情報)は、無線ユニット52が送信する送信データTXaとして、例えば、最寄りの基地局80に向けて送信される(
図11参照)。送信データTXaは、複数のパケットデータに分割されて基地局80に送信される場合もある。基地局80では、このような送信データTXaを受信すると、所定のデータフォーマットに変換した後、インターネットNに接続された管理サーバ60に向けて送信する。
【0113】
管理サーバ60では、後述するように停留所情報等ISa(乗車停留所情報)等を受信すると、スマートフォン50に向けて受信結果情報を折り返して送信する。そのため、スマートフォン50の無線ユニット52では、ステップS505により停留所情報等ISaを送信した後、管理サーバ60から送信されて来る受信結果情報RXaを受信する。そのため、続くステップS507では、この受信結果情報RXaに基づいて送信完了の可否を判定する。
【0114】
送信が完了した場合には(S507;Yes)、ステップS508により送信結果フラグに送信完了情報をセットして本無線送信処理500を終了し、
図7のコード取得処理400に処理を戻す。これに対して、送信が完了しない場合や受信結果情報RXaを受信できない場合には(S507;No)、ステップS509によりリトライカウンタをインクリメント(加算)した後、カウンタ値、つまりリトライ回数が所定回数(例えば3回)を超えているか否かをステップS511により判定する。
【0115】
リトライ回数が所定回数を超えていない場合には(S511;No)、リトライ回数が所定回数を超えるか(S511;Yes)、または送信完了するまで(S507;Yes)、ステップS505による送信処理を繰り返す。また、リトライ回数が所定回数を超えている場合には(S511;Yes)、ステップS513により送信結果フラグに送信未了情報をセットして本無線送信処理500を終了し、
図7のコード取得処理400に処理を戻す。
【0116】
図7のコード取得処理400のステップS417に戻ると、コード取得処理400を終了して
図6の運賃精算処理300のステップS309に戻る。本実施形態では、送信結果フラグに送信未了情報がセットされている場合、つまり停留所情報等ISa(乗車停留所情報)が管理サーバ60に対して送信できていない場合においても、利用者Mの乗車を拒否することなく許容する。これにより、例えば、利用者Mがスマートフォン50を使用している周囲の電波状態が良好でなく無線通信回線85に通信障害が生じている場合等においても、滞りなく利用者Mの乗車を可能にすることができる。
【0117】
なお、
図6には図示されていないが、送信結果フラグに送信未了情報がセットされている場合には、例えば、図略の別のタスク(スレッド、プログラム)において、管理サーバ60に対する停留所情報等ISa(乗車停留所情報)の再送信を複数回実行する処理(再送処理)を行うように処理の流れを構成してもよい。これにより、利用者Mが乗車した後、または降車した後に事後的に停留所情報等ISaを管理サーバ60に送信することが可能になるため、
利用者Mがどこからどこまでバス90(乗合車両)を利用したかの情報(いわゆるODデータ
(Orgin;出発地、Destination;目的地))の収集率を高めることができる。また意図的に通信障害を発生させて無賃乗車を謀ることを防止したりそのような企てを抑制したりすることもできる。
【0118】
[運賃精算処理300の続き]
図6に示すように、ステップS307によるコード取得処理が終わると、次にステップS309により選択メニュー表示処理が行われる。コード取得処理(S307)は、利用者Mがバス90に乗車する際に乗車口91で乗車表示端末20に表示される二次元コードDCをスマートフォン50で取得するときに実行されることから、コード取得処理(S307)が終了したタイミングでは、利用者Mはバス90に乗車している蓋然性が高い。
【0119】
このため、ステップS309では選択メニュー表示処理を実行することにより、利用者Mに対して、降車時においてもスマートフォン50により二次元コードDCを取得する必要があることを明示する。例えば、
図12(A)に示すような選択メニュー画面がスマートフォン50の表示ユニット53に表示される。
【0120】
ここでの利用者Mは、既にバス90の乗車時において乗車表示端末20の二次元コードDCを取得しているため、「乗車」ボタンを選択することも「終了」ボタンを選択することもできない。したがって、利用者Mは、「降車」ボタンと「ヘルプ」ボタンの択一的な選択だけが許容される。なお、「ヘルプ」ボタンが選択入力された場合は、図略の別のタスク(スレッド、プログラム)においてヘルプ画面等が表示される。なお、このような画面に代えて、例えば、「乗車日時」、「乗車停留所名称」、「路線名称」等をスマートフォン50の表示ユニット53に表示させるように構成してもよい。これにより、乗車済みであることを一目瞭然に把握することができる。
【0121】
ステップS311の判定処理により利用者Mの選択入力が「降車」であったと判定した場合には(S311;Yes:降車)、続くステップS313によりコード取得処理が行われる。この処理については、既に
図7を参照して説明しているので、ここではコード取得処理(S313)の説明は省略して
図11を参照しながら処理概要を説明する。
【0122】
例えば、利用者Mが、停留所BSdで降車する場面には、バス90の降車扉が開いた後から降車扉が閉じても所定期間中(例えば30秒間)、降車口93の降車表示端末30に二次元コードDCdが表示され続ける。そのため、利用者Mは、降車口93から降車する前(または降車する際)にスマートフォン50のカメラ55で二次元コードDCdを撮影する(S403)。撮影された二次元コードDCdは、降車停留所情報として、制御ユニット51のメモリのワーク領域に格納された後、デコードされて停留所情報等ISd(降車停留所情報)が取り出される(S407)。
【0123】
停留所情報等ISdは、停留所BSdに対応するものである。即ち、例えば、(1)の整理券番号として「2」、(2)の運賃データとして「整理券番号2に対応した200円、整理券番号3に対応した220円および整理券番号4に対応した220円」、(3)の停留所名称として「○○公園北」、(4)の停留所連番号として「4」、(5)の系統番号として「01」、(6)の事業者名称として「XYZ交通」、(7)の営業所名称として「○×△営業所」、(8)の車両番号として「123」、(9)の表示更新日時として「2019年9月25日18時03分」が得られる(
図3参照)。
【0124】
そして、スマートフォン50が機内モードである場合には(S413;Yes)、
図13(B)に示すようにスマートフォン50の表示ユニット53の画面に、利用者Mにインパクトを与え得る色彩で機内モードの解除を促すメッセージ「機内モードを解除してくださ」が表示される。
図13(B)に示す画面の例では、乗車した停留所名称「ABC駅」に加えて降車する停留所名称として上記(3)の「○○公園北」が表示されている。
【0125】
二次元コードDCdから取り出された停留所情報等ISd(降車停留所情報)は、スマートフォン50の無線ユニット52が送信する送信データTXbとして、最寄りの基地局80に向けて送信されて、基地局80およびインターネットNを経由して管理サーバ60に到達する。管理サーバ60では、停留所情報等ISd(降車停留所情報)を受信すると、スマートフォン50に向けて受信結果情報を折り返して送信する。スマートフォン50の無線ユニット52では、停留所情報等ISdの送信後に管理サーバ60から送信されて来る受信結果情報RXbを受信する。
【0126】
本実施形態では、停留所情報等ISd(降車停留所情報)が管理サーバ60に対して送信できていない場合においても、利用者Mが降車に際して行う予定の決済処理を拒否することなく許容する。これにより、例えば、利用者Mがスマートフォン50を使用している周囲の電波状態が良好でなく無線通信回線85に通信障害が生じている場合等においても、滞りなく利用者Mの決済処理を可能にすることができる。
【0127】
図6には図示されていないが、このような場合には、例えば、図略の別のタスク(スレッド、プログラム)において、管理サーバ60に対する停留所情報等ISd(降車停留所情報)の再送信を複数回実行する処理(再送処理)を行うように処理の流れを構成してもよい。これにより、利用者Mが降車した後に事後的に停留所情報等ISdを管理サーバ60に送信することが可能になるため、ODデータの収集率を高めることができる。また、意図的に通信障害を発生させて無賃乗車を謀ることを防止したりそのような企てを抑制したりすることもできる。
【0128】
ステップS313によるコード取得処理が終わると、利用者Mのスマートフォン50には、乗車した停留所BSaの停留所情報等ISa(乗車停留所情報)と、降車する停留所BSdの停留所情報等ISd(降車停留所情報)とが保持(記憶)されている。そのため、次のステップS315により利用運賃取得処理が行われる。本実施形態では、利用運賃は、例えば、乗車した停留所BSの停留所情報等ISに含まれる(1)整理券番号と、降車する停留所BSの停留所情報等ISに含まれる(2)運賃データと、により求める。
【0129】
図11に示す例では、スマートフォン50は、停留所情報等ISa(乗車停留所情報)として(1)の整理券番号「4」と、停留所情報等ISd(降車停留所情報)として(2)の運賃データ「整理券番号2に対応した200円、整理券番号3に対応した220円および整理券番号4に対応した220円」と、得ている。そのため、停留所情報等ISd(降車停留所情報)に含まれる(2)の運賃データ「整理券番号2に対応した200円、整理券番号3に対応した220円および整理券番号4に対応した220円」の中から、停留所情報等ISa(乗車停留所情報)の(1)の整理券番号「4」に対応した「220円」を選択することで、利用運賃「220円」(利用運賃情報)が求められる(
図14参照)。
【0130】
利用者Mの利用運賃情報がステップS315により得られると、決済サーバ70において電子決済に関する情報処理を行うため、利用運賃情報と決済情報を決済サーバ70に送信する必要がある。そこで、次のステップS317では、今回の運賃情報(利用運賃情報)と利用者Mの決済情報を無線送信処理により決済サーバ70に送信する。なお、無線送信処理についても、既に
図8を参照して説明しているので、ここでは無線送信処理(S317)の説明は省略して、
図11を参照しながら処理概要を説明する。
【0131】
利用者Mの決済情報(クレジットカードの情報(氏名、カード番号、有効期限、セキュリティコード等))は、運賃精算アプリの初期設定時にスマートフォン50に登録されている(セキュアな情報管理を行う場合、決済情報は管理サーバ60に登録されている)。そのため、無線送信処理500では、このような決済情報と利用運賃情報(先の例では220円)に加えて、宛先情報として決済サーバ70のIPアドレス情報や、送信元情報としてスマートフォン50のIPアドレス情報を送信バッファにセットした後(S503)、送信データTXcとして、例えば、最寄りの基地局80に向けて送信する(決済情報が管理サーバ60にのみ登録されている場合には、スマートフォン50からは決済情報が送られて来ないため、決済サーバ70は決済情報を管理サーバ60から取得する)。
【0132】
決済サーバ70では、後述するように利用運賃情報等を受信すると、スマートフォン50に向けて受信結果情報を折り返して送信する。本実施形態では、利用運賃情報等が決済サーバ70に対して送信できていない場合には、決済サーバ70のよる決済処理が未了の場合、即ち決済結果フラグが決済未了にセットされている場合と同様の処理をステップS323による処理結果告知処理において行う。
【0133】
また、決済サーバ70では、決済処理を行いその決済処理の結果をスマートフォン50に向けて送信する。そのため、
図6に示すように、スマートフォン50による運賃精算処理300では、決済サーバ70から送信されて来る決済結果情報RXcをステップS319の決済結果受信処理により受信する。そして、受信した決済結果情報RXcをステップS321により制御ユニット51のメモリ(DRAM)に保存した後、ステップS323によりその決済結果情報RXcに基づいて処理結果告知処理を行う。
【0134】
即ち、決済サーバ70による運賃決済処理700により、決済処理が完了している場合には、決済完了にセットされた決済結果フラグが決済結果情報RXcに含まれており、決済処理が完了していない場合には、決済未了にセットされた決済結果フラグが決済結果情報RXcに含まれている。
【0135】
このため、ステップS323の処理結果告知処理では、決済結果フラグの情報に基づいて決済完了の場合には、
図15(A)に示すように、大きく目立つ青色の「○」印や、乗車停留所名称、降車停留所名称、整理券番号および利用運賃が表示ユニット53の画面に表示される。背景色は、例えば、水色に設定される。この例では、乗車停留所名称として[乗]ABC駅、降車停留所名称として[降]○○公園北、整理券番号として「4」、利用運賃として運賃:220円と、感謝を伝える「ありがとうございました」のメッセージが表示ユニット53の画面に表示される。
【0136】
また、決済完了の場合には、このような表示ユニット53による画面表示に加えて、スマートフォン50のスピーカから、「ピンポーン」や「ご利用ありがとうございました」という内容で発声する合成音声によるメッセージを音響出力可能にステップS323の処理結果告知処理を構成してもよい。なお、音響出力が制限されるマナーモードやサイレントモードにスマートフォン50が設定されている場合においても、乗務員(運転士)や当該利用者Mに対して聴覚を介した告知を可能にするため、このようなスマートフォン50の設定に関係なく、強制的に合成音声によるメッセージ等を音響出力するようにステップS323の処理結果告知処理を構成してもよい。
【0137】
これに対して、決済結果フラグの情報に基づいて決済未了の場合や、利用運賃情報等が決済サーバ70に対して送信できていない場合には、決済完了の場合と同様に、
図15(A)に示すように、大きく目立つ青色の「○」印や、乗車停留所名称、降車停留所名称、整理券番号および利用運賃が表示ユニット53の画面に表示されるものの、背景色が例えば黄色に設定されるとともに、「ありがとうございました」のメッセージに代えて「決済処理ができませんでした」の警告メッセージが表示ユニット53の画面に表示される。また、スマートフォン50のスピーカから、「決済処理ができませんでした」という内容で発声する合成音声によるメッセージを音響出力可能にステップS323の処理結果告知処理を構成してもよい。これにより、事後的に決済処理が行われる旨を利用者Mや乗務員(運転士)に伝えることが可能になる。この場合においても、強制的に合成音声によるメッセージ等の出力を可能にステップS323の処理結果告知処理を構成してもよい。
【0138】
なお、
図15(B)に示す表示ユニット53の画面表示は、例えば、不正使用の蓋然性が高い場合に行われるものであり、大きく目立つ赤色の「×」印や、「利用が制限されています」の警告メッセージが表示ユニット53の画面に表示されたり、スマートフォン50のスピーカから、「ブッブー」や「利用が制限されています」という内容で発声する合成音声によるメッセージを音響出力したりする。なお、このような場合にも、利用内容を乗務員(運転士)や当該利用者Mに明示可能にするため、乗車停留所名称、降車停留所名称、整理券番号および利用運賃が表示ユニット53の画面に表示される。また、この場合においても、強制的な合成音声によるメッセージ等を可能に構成してもよい。
【0139】
また、不正使用の履歴データを利用者ごとに管理することによって、例えば、特定の利用者による不正使用の頻度が高い場合には、当該利用者による本運賃収受システム10の利用を停止(拒否)する措置を採ることが可能になる。このような不正使用の履歴データの管理は、例えば、管理サーバ60に蓄積された停留所情報等ISとこれに関連付けられた個人情報とにより行うことが可能になる。
【0140】
また、本実施形態では、二次元コードDCには上記(9)の表示更新日時が埋め込まれている。そのため、スマートフォン50が二次元コードDCを取得した時点の当該スマートフォン50の時計ユニットから得られる時間情報Xと、二次元コードDCに埋め込まれた(9)の表示更新日時の時間情報Yとに基づいて、両時刻の差(時間差)から二次元コードDCの不正使用の有無を判定することが可能になる。
【0141】
例えば、スマートフォン50の時間情報Xの方が二次元コードDCに埋め込まれた時間情報Yよりも古い(小さい)場合には、スマートフォン50による撮影時刻の方が二次元コードDCの表示更新時刻よりも本来、新しい筈が、逆の時間関係(古いこと)になるので、当該二次元コードDCは不正に生成されたり複製されたりした蓋然性が高いと判定することができる。
【0142】
また、スマートフォン50の時間情報Xの方が二次元コードDCに埋め込まれた時間情報Yよりも新しい(大きい)場合であっても、両時刻の差(時間差)が所定時間Nよりも大きいときには、時間間隔の開きが大きいことから、当該二次元コードDCは不正に生成されたり複製されたりした蓋然性が高いと判定することができる。この場合の所定時間Nは、例えば、バス90が停留所間の移動に実際に要する時間またはそれよりも小さい時間に設定されたり、運行ダイヤを管理するシステムが有する停留所間所要時間情報に基づく時間に設定されたり、運行ダイヤと連携した可変時間長に設定されたりする。
【0143】
[停留所情報等記録処理600]
次に管理サーバ60が実行する停留所情報等記録処理600を説明する。管理サーバ60は、制御装置としてのサーバコンピュータのハードディスク装置等に停留所情報等記録処理600を実行可能な停留所情報等記録プログラムが格納されている。サーバコンピュータにおいて実行される停留所情報等記録処理600では、まずステップS601により所定の初期化処理が済むと、スマートフォン50から基地局80やインターネットNを介して送信データTXa,TXbとして送られて来る停留所情報等ISを受信する、ステップS603の停留所情報等受信処理が行われる。
【0144】
そして、ステップS605により停留所情報等ISを受信したか否かを判定して、受信した場合には(S605;Yes)、次のステップS607に処理を移行し、受信していない場合には(S605;No)、再度、ステップS603に戻って停留所情報等受信処理を行う。ステップS607では受信結果情報をスマートフォン50に向けて送信する処理が行われる。正常に受信できている場合には正常受信情報を送信し、受信した停留所情報等ISの一部が欠落したり破損したりしている場合には正常に受信できていないため、異常受信情報を送信する。
【0145】
続くステップS609では、ステップS603により受信した正常な停留所情報等ISをデータベース装置に格納して蓄積する処理(蓄積処理)が行われる。この処理を終えると、再度、ステップS603に戻って停留所情報等受信処理を行う。これにより、管理サーバ60では、受信した停留所情報等ISを、逐次、データベース装置に蓄積することが可能になる。
【0146】
[運賃決済処理700]
続いて決済サーバ70が実行する運賃決済処理700を説明する。決済サーバ70は、制御装置としてのサーバコンピュータのハードディスク装置等に運賃決済処理700を実行可能な運賃決済プログラムが格納されている。サーバコンピュータにおいて実行される運賃決済処理700では、まずステップS701により所定の初期化処理を行いそれが済むと、スマートフォン50から基地局80やインターネットNを介して送信データTXcとして送られて来る利用運賃情報と決済情報(利用運賃情報等)を受信する、ステップS703の利用運賃情報等受信処理が行われる(決済情報が管理サーバ60にのみ登録されている場合には、決済サーバ70は決済情報を管理サーバ60から得る)。
【0147】
そして、ステップS705により利用運賃情報等を受信したか否かを判定して、受信した場合には(S705;Yes)、次のステップS707に処理を移行し、受信していない場合には(S705;No)、再度、ステップS703に戻って利用運賃情報等受信処理を行う。ステップS707では受信結果情報をスマートフォン50に向けて送信する処理が行われる。正常に受信できている場合には正常受信情報を送信し、受信した利用運賃情報等の一部が欠落したり破損したりしている場合には正常に受信できていないため、異常受信情報を送信する。
【0148】
次のステップS709では利用運賃情報等に基づく決済処理が行われる。即ち、ステップS709では、利用者Mがバス90を利用したことによる利用運賃(
図11の例では、運賃220円)を電子決済により収受する処理が行われる。つまり、電子決済による運賃収受処理である。利用者Mの決済情報としては、例えば、クレジットカードの情報(利用者Mの氏名、カード番号、有効期限、セキュリティコード等)である。
【0149】
続くステップS711では、ステップS709による決済処理が完了したか否かを判定する。クレジットカードの情報に誤りや有効期限切れ等の問題がない場合には、決済処理が完了するため(S711;Yes)、ステップS713により決済結果フラグに決済完了をセットする。これに対して、例えば、カード番号やセキュリティコードに誤りがあったり有効期限が過ぎていたりしてクレジットカードの情報に問題がある場合には、決済処理が完了しないため(S711;No)、ステップS715により決済結果フラグに決済未了をセットする。
【0150】
そして、次のステップS717により決済結果情報、つまり決済結果フラグをスマートフォン50に向けて送信する処理が行われる。決済処理が完了している場合には決済完了がセットされた決済結果フラグが送信され、決済処理が完了していない場合には決済未了がセットされた決済結果フラグが送信される。この処理を終えると、再度、ステップS703に戻って利用運賃情報等受信処理を行う。これにより、決済サーバ70では、受信した利用運賃情報等を、逐次、電子決済することが可能になる。
【0151】
以上説明したように本実施形態の運賃収受システム10では、スマートフォン50は、利用者Mの乗車時に乗車表示端末20から出力された二次元コードDCaを取得し、利用者Mの降車時に降車表示端末30から出力された二次元コードDCdを取得し、二次元コードDCaをデコードした停留所情報等ISaと二次元コードDCdをデコードした停留所情報等ISdとに基づいて得られた利用運賃に関する利用運賃情報を決済サーバ70に送信する。そして、決済サーバ70は、運賃決済処理700により、スマートフォン50から送信された利用運賃情報に基づいて電子決済に関する情報処理を行う。ホスト機器40は、典型的には、例えば、バス90内の既存設備として存在する運賃箱、運賃表示器や車内放送装置等の車載機器を構成する制御装置が用いられる。また、決済サーバ70も既存設備のものが使用できる。スマートフォン50は当該バス90の利用者Mが所持する。
【0152】
このため、運賃収受システム10を構成するうえで、新規に必要になるものは乗車表示端末20と降車表示端末30である。また、利用運賃に関する利用運賃情報を得る情報処理や、決済サーバ70との通信処理は、利用者Mが所持するスマートフォン50が行う。これにより、バス90に搭載されたホスト機器40、乗車表示端末20や降車表示端末30は、利用運賃情報を得る情報処理を行ったり、決済サーバ70との通信処理を行ったりする必要がないので、これらのホスト機器40等に演算処理能力が高いマイクロコンピュータや記憶容量が大きなメモリ等を設ける必要もない。また通信コストの増加もない。したがって、設備コストの増大を抑制しつつもデジタルチケットによる決済を可能にすることができる。
【0153】
また、本実施形態の運賃収受システム10では、乗車表示端末20が出力する二次元コードDCや降車表示端末30が出力する二次元コードDCは、停留所ごとに異なるばかりでなく、それぞれ時間の経過とともに変化するように二次元コードDCが出力された時刻の時間情報が少なくとも含まれている(上記(9)の表示更新日時の情報)。そのため、例えば、車両、系統、停留所が同じであっても、日時が違えば異なる二次元コードDCが生成されるため、二次元コードDCを不正に生成したり複製したりすることを極めて困難にしている。また、この表示更新日時の情報とこれらの二次元コードDCの取得時の時間情報(スマートフォン50の時計機能によるもの)とを比較することで、二次元コードDCの不正取得行為の有無を判定することが可能になる。
【0154】
例えば、スマートフォン50のカメラ55で撮影して取得した二次元コードDCの画像データが乗車表示端末20や降車表示端末30から乗車時や降車時以前の過去に出力されたものであるか否かを判定することにより、取得した二次元コードDCの画像データがその乗車日または降車日以前のものであった場合には、当該利用者Mが予め準備した古い二次元コードDCの画像データを意図的にスマートフォン50で取得した蓋然性が高いことになるため、このような不正取得行為の有無を判定することが可能になる。
【0155】
また、本実施形態の運賃収受システム10では、スマートフォン50は、二次元コードDCから得られた停留所情報等ISを、車両外に設けられる管理サーバ60や決済サーバ70に送信するため、これらのサーバ60,70では、利用者Mがどこからどこまでバス90を利用したかの情報(いわゆるODデータ)を蓄積することが可能になる。停留所情報等ISと利用者Mの関連付けは、例えば、スマートフォン50や管理サーバ60に登録されている利用者Mの個人情報(利用者Mの氏名、生年月日、性別、住所、電話番号、職業等)とスマートフォン50の所持者が利用者Mであることから可能である。これにより、バス90を利用した場合の出地と着地の組み合わせごとの利用者数を把握することが可能になるので、例えば、運輸効率の改善や関連サービスの提供等に用いることができる利用価値の高いODデータの収集が可能になる。
【0156】
また、本実施形態の運賃収受システム10では、スマートフォン50は、決済サーバ70への利用運賃情報の送信が完了しなかった場合や電子決済に関する情報処理を行うことができなかった場合には、スマートフォン50の画面の背景色を、例えば黄色にしたり、「決済処理ができませんでした」の警告メッセージが画面に表示されたりする。また、スマートフォン50のスピーカから、「決済処理ができませんでした」という内容で発声する合成音声によるメッセージを音響出力可能にステップS323の処理結果告知処理を構成してもよい。これにより、事後的に決済処理が行われる旨を利用者Mや乗務員(運転士)に伝えることが可能になり、乗務員は、当該利用者Mの運賃収受が済んでいないことを知ることができるので、当該利用者Mに対して事後精算処理等が必要であることを説明する等の適切な乗客対応が可能になる。
【0157】
これに対して、管理サーバ60への利用運賃情報の送信が完了した場合または電子決済に関する情報処理を行うことができた場合には、大きく目立つ青色の「○」印や「ありがとうございました」のメッセージがスマートフォン50の画面に表示される(
図15(A))。また、スマートフォン50のスピーカから、「ピンポーン」や「ご利用ありがとうございました」という内容で発声する合成音声によるメッセージを音響出力可能にステップS323の処理結果告知処理を構成してもよい。これにより、乗務員は、当該利用者Mの利用運賃収受が済んだことを知ることができるので、当該利用者Mには事後精算処理等の説明が不要であることを把握することが可能になる。
【0158】
また、本実施形態の運賃収受システム10では、スマートフォン50は、利用者Mの降車時において、無線通信回線85を介した情報通信を行わないようにスマートフォン50が設定されている場合(例えば「機内モード」に設定されている場合)には、例えば、
図13(B)に示すような機内モードの解除を促すメッセージ「機内モードを解除してくださ」(例えば、背景色は赤色、文字色は白色または黄色)がスマートフォン50の表示ユニット53の画面に表示される。
【0159】
これにより、利用者Mに対して色彩的にインパクトを与え得るメッセージの表示が可能になる。また乗務員も「機内モード」に設定されているため、当該スマートフォン50が決済サーバ70に利用運賃情報を送信したり管理サーバ60に停留所情報等ISを送信したりすることができない状態であることを把握でき、例えば、当該利用者Mに対して機内モードを解除するように促すことが可能になる。したがって、機内モードに起因したスマートフォン50による決済サーバ70への利用運賃情報の送信未了を防ぐことができる。
【0160】
また、本実施形態の運賃収受システム10では、乗車表示端末20と降車表示端末30をハードウェアおよびソフトウェアのいずれについても同じ構成にしたため、これらを異なるハードウェア構成やソフトウェア構成にした場合に比べ、開発コスト、製造コストやメンテナンスコストを抑制することが可能になる。また量産に伴う低コスト化も期待できるため、さらに製品コストが下がり設備の導入コストをより低減することが可能になる。
【0161】
なお、[先行技術文献]の欄で述べた特許文献1(特開2018-147270号公報)においては、タイプαの自動改札機のほかに、タイプβの自動改札機が開示されている(特許文献1;段落0020等)。このタイプβの自動改札機はQRコードを表示させる構成を有するが、鉄道駅の自動改札機は一般的には駅構内に固定されている。
【0162】
このため、タイプβの自動改札機を利用する場合のスマートフォンや携帯電話機は、比較的安定した通信状態が得やすいのに対して、路線バスを利用する場合のスマートフォンや携帯電話機は、バスの走行に伴い移動したり携帯基地局等のインフラが十分に整っていない地域の停留所に移動したりすることから、通信状態が不安定な環境で使用される場合がある。このような場合には不安定な通信状態に起因して決済サーバが決済不能に陥ることもあるため、本発明は上記の構成によりこれを解決している。
【0163】
なお、上述した実施形態では、乗車表示端末20や降車表示端末30に表示ユニット23,33を設けて二次元コードDC等のコードを表示可能に構成し、スマートフォン50のカメラ55により二次元コードDC等の画像を撮影することで当該二次元コードDC等の取り込みを可能にした。しかし、本発明の適用はこれに限られることはなく、例えば、表示ユニット23,33に代えて(または表示ユニット23,33に加えて)、乗車表示端末20や降車表示端末30にRFID(Radio Frequency IDentification)等の近距離無線通信(NFC;Near field communication)が可能な無線ユニットとそのアンテナを設けてもよい。
【0164】
これにより、このような乗車表示端末20や降車表示端末30から近距離無線通信で出力される乗車停留所情報や降車停留所情報を、RFID等の近距離無線通信機能を備えたスマートフォンが取得することが可能になるので、スマートフォン50のカメラ55等で二次元コードDCを撮影して取得する場合に比べて、素早く乗車停留所情報や降車停留所情報を取得することが可能になる。したがって、バス90の乗車口91や降車口93で利用者M(乗客)の滞りが起こり難くなるため、乗降客が多い時間帯や停留所であっても、バス90の乗車や降車がスムーズになる。
【0165】
また、上述した実施形態では、データカセットのメモリに格納された運賃三角表データを用いる場合を例示して説明したが、本発明の適用はこれに限られることはなく、例えば、運賃表示器や車内放送装置等の車載機器から有線通信回線15を介して送られてくる運賃三角表データを用いてもよい。
【0166】
さらに、上述した実施形態では、スマートフォン50が二次元コードDCを取得した時点の時間情報Xを当該スマートフォン50の時計ユニットから得る場合を例示して説明したが、本発明の適用はこれに限られることはなく、例えば、乗車表示端末20や降車表示端末30から当該スマートフォン50が時間情報Xを得るように構成してもよい。
【0167】
なお、上述した実施形態では、二次元コードとして、QRコードを使用する場合を例示して説明したが、本発明の適用はこれに限られることはなく、例えば、マトリクス型の二次元コードとして、DataMatrix、VeriCode、AztecやMaxCodeを用いてもよい。また、スタック型の二次元コードとして、PDF471やCODE49を用いてもよい。また、コード化するデータ量が少ない場合には、バーコード等の一次元コードを用いてもよい。
【0168】
また、上述した実施形態では、乗車表示端末20から出力される二次元コードDCと降車表示端末30から出力される二次元コードDCとを同じデータ内容のコード(同じコード)にしたが、両者異なるデータ内容のコード(違うコード)を出力するように構成してもよい。これにより、不正に二次元コードDCを生成した場合には発覚する可能性が高まるため、二次元コードDCの不正な生成や複製を抑制することが可能になる。
【0169】
また、上述した実施形態では、乗車表示端末20と降車表示端末30とを同じハードウェアおよびソフトウェアで構成したが、両者をそれぞれ異なるようにハードウェアおよびソフトウェアを構成してもよい。これにより、様々な顧客ニースに対応することが可能になる。
【0170】
また、二次元コードDCを表示可能な表示装置を有するバス用の車載設備機器を乗車表示端末20や降車表示端末30に代えて用いてもよい。これにより、乗車表示端末20や降車表示端末30を別途設ける必要がなくなるため、さらに設備の導入コストを低減することが可能になる。
【0171】
また、上述した実施形態では、本発明の運賃収受システムをバス90(路線バス)の運賃収受に適用する場合を例示して説明したが、本発明の適用はこれに限られることはなく、乗合車両の利用運賃を収受するものであれば、例えば、路面電車、トロリーバスやワンマン運行方式の鉄道等の乗合車両の利用運賃を収受するものにも適用することができ、これらの場合においても路線バスに適用したときと同様の作用・効果を得ることができる。
【0172】
以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、上述した具体例を様々に変形または変更したものが含まれる。また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時の請求項に記載の組合せに限定されるものではない。さらに、本明細書または図面に例示した技術は、複数の目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つ。なお、[符号の説明]の欄における括弧内の記載は、上述した各実施形態で用いた用語と、特許請求の範囲に記載の用語との対応関係を明示し得るものである。
【符号の説明】
【0173】
10…運賃収受システム
20…乗車表示端末(乗車情報提供装置)
30…降車表示端末(降車情報提供装置)
40…ホスト機器(制御装置)
50…スマートフォン(携帯情報端末装置)
51…制御ユニット
52…無線ユニット
53…表示ユニット
55…カメラ
60…管理サーバ
70…決済サーバ(決済サーバ装置)
80…基地局
85…無線通信回線
90…路線バス(乗合車両)
91…乗車口
93…降車口
100…停留所情報等送出処理
200…コード出力処理
300…運賃精算処理
400…コード取得処理
500…無線送信処理
600…停留所情報等記録処理
700…運賃決済処理
BS,BSa,BSb,BSd…停留所
DC,DCa,DCb,DCd…二次元コード(乗車停留所情報、降車停留所情報)
IS,ISa,ISb,ISd…停留所情報等(乗車停留所情報、降車停留所情報)
M…利用者
N…インターネット
TXa,TXb,TXc…送信データ
RXa,RXb…受信結果情報