JP7457540B2 - 運賃収受システム - Google Patents

Description

本発明は、乗合車両の利用者から当該車両の利用運賃を収受する運賃収受システムに関するものである。なお、乗合車両には、路線バス、路面電車、トロリーバス等の乗合バスや鉄道等が含まれる。

乗車券の代わりに、スマートフォン等の携帯情報端末装置を鉄道駅の自動改札機にかざすことにより改札から入場したり出場したりすることを可能にする技術、つまり乗車券のデジタルチケットに関する技術が下記特許文献１に開示されている。デジタルチケットは、入場券や引換券等の一定の権利を電子化したものであり、電子チケットと呼ばれる場合もある。

特開２０１８－１４７２７０号公報

デジタルチケットの典型的な例は、エンコードされたコード（例えば、ＱＲコード（登録商標）やバーコード）を紙等に印刷したりスマートフォン等の携帯情報端末装置の画面に表示させたりして、それを当該コード用のリーダで読み取ることで入場券や引換券等の一定の権利を確認する。これを鉄道駅の自動改札機に適用した場合には、特許文献１に開示されている交通システムのタイプαの自動改札機のように、改札機自体にリーダの機能を持たせる必要がある（特許文献１；段落００１１等）。そのため、システム導入時等の設備コストが増大するおそれがある。

また、特許文献１の交通システムは、鉄道駅の自動改札機に関するものであり、自動改札機は駅構内に設けられる。そのため、入場駅に設けられる自動改札機とセンタサーバ装置との間や、出場駅に設けられる自動改札機と決済サーバ装置との間は、有線通信回線で接続することが比較的容易である。ところが、このような交通システムの技術を路線バスの運賃収受システムに導入しようとすると、路線バスに搭載された運賃箱とセンタサーバ装置や決済サーバ装置との間は、無線通信回線で接続せざるを得ない。車載の運賃箱はそれ自体が移動するからである。無線通信回線は、有線通信回線に比べて利用料金が桁違いに高額であり、運用コストの問題が設備コスト以上にシステム導入の障害になり易い。

本発明は、上述した課題を解決するためになされたものであり、設備コストや運用コストの増大を抑制しつつもデジタルチケットによる決済を可能にし得る運賃収受システムを提供することを目的とする。

上記目的を達成するため、特許請求の範囲の請求項１に記載された運賃収受システムは、乗合車両の利用者から当該車両の利用運賃を収受する運賃収受システムであって、前記車両内の乗車口付近に設けられる乗車情報提供装置と、前記車両内の降車口付近に設けられる降車情報提供装置と、前記車両が停留所に停車した前記停留所に対応する情報であってそれぞれの停留所ごとに異なる停留所情報を停車するごとに前記乗車情報提供装置および前記降車情報提供装置に出力させる制御装置と、前記車両外に設けられて前記利用運賃を収受する電子決済に関する情報処理を行う決済サーバ装置と、前記利用者が所持して前記乗車情報提供装置および前記降車情報提供装置から出力される前記停留所情報を取得可能かつ前記決済サーバ装置に対し無線通信回線を介して情報通信可能な携帯情報端末装置と、を含み、前記携帯情報端末装置は、前記利用者の乗車時に前記乗車情報提供装置から出力された乗車時の前記停留所情報（以下、請求項１～５において「乗車停留所情報」という）を取得し、前記利用者の降車時に前記降車情報提供装置から出力された降車時の前記停留所情報（以下、請求項１～５において「降車停留所情報」という）を取得し、前記乗車停留所情報に含まれる前記乗車時の停留所に対応した整理券番号と前記降車停留所情報に含まれる前記整理券番号に対応した運賃データとに基づいて得られた前記利用運賃に関する利用運賃情報を前記決済サーバ装置に送信し、前記決済サーバ装置は、前記携帯情報端末装置から送信された前記利用運賃情報に基づいて前記電子決済に関する情報処理を行うことを技術的特徴とする。

請求項１に記載の運賃収受システムの発明では、乗車情報提供装置、降車情報提供装置、制御装置、決済サーバ装置および携帯情報端末装置が当該システムを構成する。携帯情報端末装置は、利用者の乗車時に乗車情報提供装置から出力された乗車停留所情報を取得し、利用者の降車時に降車情報提供装置から出力された降車停留所情報を取得し、乗車停留所情報に含まれる乗車時の停留所に対応した整理券番号と降車停留所情報に含まれるこの整理券番号に対応した運賃データとに基づいて得られた利用運賃に関する利用運賃情報を決済サーバ装置に送信し、決済サーバ装置は、携帯情報端末装置から送信された利用運賃情報に基づいて電子決済に関する情報処理を行う。制御装置は、典型的には、例えば、乗合車両内の既存設備として存在する運賃箱、運賃表示器や車内放送装置等の車載機器を構成する制御装置が用いられる。また、決済サーバ装置も、既存設備のものが使用できる。携帯情報端末装置は、当該乗合車両の利用者が所持するものである。なお、制御装置は、それ自体を単体で設けてもよい。

このため、運賃収受システムを構成するうえで、新規に必要になるものは乗車情報提供装置と降車情報提供装置である。また、利用運賃に関する利用運賃情報を得る情報処理や、決済サーバ装置との通信処理は、利用者が所持する携帯情報端末装置が行う。これにより、乗合車両に搭載された制御装置、乗車情報提供装置や降車情報提供装置は、利用運賃情報を得る情報処理を行ったり、決済サーバ装置との通信処理を行ったりする必要がないので、これらの制御装置等に演算処理能力が高いマイクロコンピュータや記憶容量が大きなメモリ等を設ける必要もない。また通信コストの増加もない。

また、決済サーバ装置と無線通信回線を介して情報通信を行うのは、専ら携帯情報端末装置であり、乗合車両に設けられた、乗車情報提供装置、降車情報提供装置および制御装置は、決済サーバ装置と直接、情報通信を行わない。つまり、乗合車両を運行する事業者等は、運賃収受システムの運用においては決済サーバ装置との間において無線通信回線を利用する必要がない。これにより、車載の乗車情報提供装置、降車情報提供装置や制御装置が無線通信回線を使用する場合に比べて通信コストが大幅に減少する。

また、特許請求の範囲の請求項２に記載された運賃収受システムは、請求項１に記載の運賃収受システムにおいて、前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、それぞれ時間の経過とともに変化し、かつ、出力時刻の時間情報が少なくとも含まれていることを技術的特徴とする。

請求項２に記載の運賃収受システムの発明では、乗車停留所情報や降車停留所情報は、それぞれ時間の経過とともに変化し、これらの停留所情報が出力された時刻の時間情報が少なくとも含まれているため、この出力時刻の時間情報とこれらの停留所情報の取得時の時間情報とを比較することで、例えば、取得した乗車停留所情報や降車停留所情報が乗車情報提供装置や降車情報提供装置から乗車時や降車時以前の過去に出力されたものであるか否かを判定することが可能になる。なお、停留所情報の取得時の時間情報は、例えば、当該携帯情報端末装置が有する時計機能から得たり、乗車情報提供装置や降車情報提供装置が有する時計機能から得たりする。

これにより、取得した乗車停留所情報や降車停留所情報が、例えば、その日前のものであった場合には、本来であれば、乗車時または降車時に乗車停留所情報や降車停留所情報を取得すべきところを、当該利用者が予め準備した古い乗車停留所情報や降車停留所情報を意図的に携帯情報端末装置で取得した蓋然性が高いため、このような不正使用の有無を判定することが可能になる。

また、特許請求の範囲の請求項３に記載された運賃収受システムは、請求項１または２に記載の運賃収受システムにおいて、前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、暗号化されており、前記携帯情報端末装置は、暗号化された前記乗車停留所情報および前記降車停留所情報を所定の暗号鍵で復号して前記整理券番号と前記運賃データを取得することを技術的特徴とする。

請求項３に記載の運賃収受システムの発明では、乗車情報提供装置から出力される乗車停留所情報および降車情報提供装置から出力される降車停留所情報は、暗号化されているため、乗車停留所情報や降車停留所情報を不正に生成されることを防止可能にしている。携帯情報端末装置は、暗号化された乗車停留所情報および降車停留所情報を所定の暗号鍵で復号して整理券番号と運賃データを取得する。これにより、乗車停留所情報および降車停留所情報が暗号化されていても、携帯情報端末装置はこれらの情報から整理券番号と運賃データを取得して利用運賃に関する利用運賃情報を得ることが可能になる。

また、特許請求の範囲の請求項４に記載された運賃収受システムは、請求項１～３のいずれか一項に記載の運賃収受システムにおいて、前記携帯情報端末装置は、前記降車停留所情報および前記乗車停留所情報に基づいて、前記決済サーバ装置への前記利用運賃情報の送信が完了しなかった場合または前記電子決済に関する情報処理を行うことができなかった場合には、所定の未了情報を前記車両の乗務員に告知可能に出力し、または、前記決済サーバ装置への前記利用運賃情報の送信が完了した場合または前記電子決済に関する情報処理を行うことができた場合には、所定の完了情報を前記車両の乗務員に告知可能に出力することを技術的特徴とする。

請求項４に記載の運賃収受システムの発明では、携帯情報端末装置は、降車停留所情報および乗車停留所情報に基づいて、決済サーバ装置への利用運賃情報の送信が完了しなかった場合または前記電子決済に関する情報処理を行うことができなかった場合には、所定の未了情報を車両の乗務員に告知可能に出力する。これにより、乗務員は、当該利用者の運賃収受が済んでいないことを知ることができるので、当該利用者に対して事後精算処理等が必要であることを説明する等の適切な乗客対応が可能になる。また、決済サーバ装置への利用運賃情報の送信が完了した場合または前記電子決済に関する情報処理を行うことができた場合には、所定の完了情報を車両の乗務員に告知可能に出力する。これにより、乗務員は、当該利用者の利用運賃収受が済んだことを知ることができるので、当該利用者には事後精算処理等の説明が不要であることを把握することが可能になる。

また、特許請求の範囲の請求項５に記載された運賃収受システムは、請求項１～４のいずれか一項に記載の運賃収受システムにおいて、前記携帯情報端末装置は、前記利用者の降車時において、前記無線通信回線を介した情報通信を行わないように当該携帯情報端末装置が設定されている場合には、所定の通信不能情報を前記車両の乗務員に告知可能に出力することを技術的特徴とする。

請求項５に記載の運賃収受システムの発明では、携帯情報端末装置は、利用者の降車時において、無線通信回線を介した情報通信を行わないように当該携帯情報端末装置が設定されている場合（例えば、当該携帯情報端末装置が「機内モード」に設定されている場合）には、所定の通信不能情報を車両の乗務員に告知可能に出力する。これにより、乗務員は、無線通信回線を介して、携帯情報端末装置が決済サーバ装置に利用運賃情報を送信したり他のサーバ装置等に乗車停留所情報や降車停留所情報を送信したりすることができない状態であることを把握できるので、例えば、当該利用者に対して機内モードを解除するように促すことが可能になる。したがって、機内モードに起因した携帯情報端末装置による決済サーバ装置への利用運賃情報の送信未了を防ぐことができる。

本発明の運賃収受システムでは、乗合車両に搭載された制御装置、乗車情報提供装置や降車情報提供装置は、利用運賃に関する利用運賃情報を得る情報処理を行ったり、決済サーバ装置との通信処理を行ったりする必要がないので、これらの制御装置等に演算処理能力が高いマイクロコンピュータや大容量メモリ等を設ける必要もない。また通信コストの増加もない。したがって、設備コストの増大を抑制しつつもデジタルチケットによる決済を可能にすることができる。

本発明の一実施形態に係る運賃収受システムの構成例を示す説明図である。 本実施形態の運賃収受システムを構成する乗車表示端末および降車表示端末の外観構成例を示す斜視図である。 データカセットに格納されている運賃三角表データの一例を示す説明図である。 本実施形態の運賃収受システムを構成するホスト機器の制御ユニットにより実行される停留所情報等送出処理の流れを示すフローチャートである。 乗車表示端末や降車表示端末の制御ユニットにより実行されるコード出力処理の流れを示すフローチャートである。 本実施形態の運賃収受システムを構成するスマートフォンの制御ユニットにより実行される運賃精算処理の流れを示すフローチャートである。 図６に表されているコード取得処理の流れを示すフローチャートである。 図７に表されている無線送信処理の流れを示すフローチャートである。 本実施形態の運賃収受システムを構成する管理サーバにより実行される停留所情報等記録処理の流れを示すフローチャートである。 本実施形態の運賃収受システムを構成する決済サーバにより実行される運賃決済処理の流れを示すフローチャートである。 ホスト機器、乗車表示端末、降車表示端末、スマートフォン、管理サーバおよび決済サーバにより、利用者が路線バスに乗車して降車するまでの間において実行される各処理の一連の流れを示すシーケンス図である。 スマートフォンの画面表示の例であり、図１２(A)は選択メニュー表示処理における表示例を表したもの、図１２(B)はコード情報取込処理における表示例を表したものである。 スマートフォンの画面表示の例であり、図１３(A)は乗車時のコード取得処理において機内モード状態であると判定した場合の表示例を表したものであり、図１３(B)は降車時のコード取得処理において機内モード状態であると判定した場合の表示例を表したものである。 図３に示す運賃三角表データに基づいて利用運賃が求められることを表した説明図である。 スマートフォンの画面表示の例であり、図１４(A)は処理結果告知処理における決済完了の表示例を表したもの、図１４(B)は処理結果告知処理における決済未了の表示例を表したものである。

以下、本発明の運賃収受システムの実施形態について図を参照して説明する。

本発明の運賃収受システムの一実施形態は、路線バス（以下「バス」という）９０を利用する乗客（以下「利用者」という）から利用運賃を収受する運賃収受システム１０であり、利用者が携帯情報端末装置としてスマートフォン５０を所持していることを前提とするものである。利用者のスマートフォン５０には、後述する運賃精算用のアプリケーションプログラム（以下「運賃精算アプリ」という）がインストールされている。

図１に示すように、本実施形態のバス９０は、ワンマン運行方式であり、利用者が後方の乗車口９１から乗車した後、前方の降車口９３から降車する際に利用運賃を支払う「後乗り前降り後払い方式」を採用している。「後乗り前降り後払い方式」は、運賃後払い方式の一態様であり、典型的には、距離に応じて金額が増加する運賃体系を採る。そのため、利用運賃の取得には、例えば、後述する運賃三角表データが用いられる。

このバス９０には、降車口９３付近に利用者が現金やＩＣカードで利用運賃の支払いを行うことが可能な運賃箱が設けられている。本実施形態では、この運賃箱がホスト機器４０の役割を果たす。ホスト機器４０は、バス９０に搭載される機器装置であれば、このような運賃箱のほかに、例えば、利用者に乗車区間に対応した運賃を表示する運賃表示器、次の停留所名等を車内に放送する車内放送装置や、車外に向けて当該バス９０の行き先等を表示する行先表示装置の操作盤等の車載機器でもよい。

運賃収受システム１０は、乗車表示端末２０、降車表示端末３０、ホスト機器４０、スマートフォン５０、管理サーバ６０、決済サーバ７０等により構成されている。これらのうち、乗車表示端末２０、降車表示端末３０およびホスト機器４０は、バス９０に搭載されており、スマートフォン５０は利用者が所持している。管理サーバ６０および決済サーバ７０は、例えば、バス９０の運行事業者の社屋内に収容されている。これらのサーバ６０，７０は、他の事業者が管理するレンタルサーバを利用していてもよい。

管理サーバ６０や決済サーバ７０は、例えば、図略のインターネット接続事業者（ＩＳＰ）を介してインターネットＮに接続されている。また、スマートフォン５０は、移動体通信事業者（ＭＮＯ）が管理する基地局８０等を介してインターネットＮに接続されている。インターネットＮは、データを伝送する情報通信回線網の一例であり、インターネットプロトコルを使用してコンピュータを相互接続するコンピュータネットワークである。なお、スマートフォン５０と管理サーバ６０の間およびスマートフォン５０と決済サーバ７０の間でデータ通信可能であれば、インターネットＮ以外の情報通信回線網でもよい。

図１および図２に示すように、乗車表示端末２０は、主に、制御ユニット２１、表示ユニット２３、照明ユニット２５、通信ユニット２７等により構成されており、本実施形態では、例えば、バス９０の乗車口９１付近に設けられる握り棒Ｐに取り付けられている。乗車表示端末２０の外観は、例えば、制御ユニット２１等を収容する矩形箱形状のハウジングと、このハウジング前面に設けられる表示ユニット２３の矩形状の液晶表示パネルと、により構成されている。

制御ユニット２１は、後述するホスト機器４０の制御ユニット４１とほぼ同様に、ＭＰＵ、メモリ（ＤＲＡＭ、ＲＯＭ）、インタフェース等により構成されるコントローラであり、本実施形態では、表示ユニット２３、照明ユニット２５や通信ユニット２７等が接続されている。メモリのＲＯＭには、表示ユニット２３、照明ユニット２５や通信ユニット２７をＭＰＵが制御可能に構成される所定のシステムプログラムや、後述のコード出力処理２００をＭＰＵが実行可能に構成されるコード出力プログラム等が格納されている。

表示ユニット２３は、表示デバイスとして液晶表示パネルや電子ペーパを備えたディスプレィ装置であり、制御ユニット２１に対して、例えば、液晶映像パラレルインタフェースやＬＶＤＳ（Low voltage differential signaling）インタフェースやＳＰＩ（Serial Peripheral Interface）等を介して接続されている。画面のサイズは、後述する二次元コードＤＣを十分に表示可能な大きさ、例えば、横縦比率が４：３のスクエア型の場合には５～６インチに設定され、また横縦比率が１６：９のワイド型の場合には６～７インチに設定されている。

照明ユニット２５は、表示ユニット２３を照らす面発光可能な照明デバイスであり、例えば、光源はＬＥＤや有機ＥＬ等である。照明ユニット２５は、シリアルインタフェースやＧＰＩＯ（General-purpose input/output）インタフェースを介して制御ユニット２１に接続されており、制御ユニット２１により発光のオンオフや輝度が制御され得るように構成されている。例えば、表示ユニット２３の表示デバイスが液晶表示パネルである場合には、照明ユニット２５は表示ユニット２３の裏側に設けられる。また、表示デバイスが電子ペーパである場合には、照明ユニット２５は、表示ユニット２３の表側に設けられる。

本実施形態では、乗車表示端末２０は表示ユニット２３を照らす照明ユニット２５を備えることから、例えば、夜間等、乗車表示端末２０の周囲が暗い環境になっても表示ユニット２３に表示される二次元コードＤＣを照明ユニット２５が照らすことが可能になる。そのため、スマートフォン５０による二次元コードＤＣの取り込み場面において、カメラ５５による二次元コードＤＣの画像撮影の成功率を高めることが可能になる。

通信ユニット２７は、有線通信回線１５を介して制御ユニット２１がホスト機器４０とデータ通信可能に構成されるシリアル通信装置である。本実施形態では、ホスト機器４０、乗車表示端末２０、降車表示端末３０等の間をマルチドロップで接続可能なRS-458に準拠したものを使用しているが、ホスト機器４０と乗車表示端末２０の間やホスト機器４０と降車表示端末３０の間をそれぞれＰＰ（Point to Point）接続する場合には、例えば、カレントループやRS-422に準拠したものを用いてもよい。また、Ethernetに準拠したＬＡＮを用いてホスト機器４０、乗車表示端末２０、降車表示端末３０等を接続してもよい。

本実施形態では、このような通信ユニット２７および有線通信回線１５を介してホスト機器４０から乗車表示端末２０に対して、表示や照明に関する制御コマンドや後述する停留所情報等が送られて来る。また乗車開扉信号も送られて来る。乗車開扉信号は、バス９０の乗車扉を開くタイミングで他の車載機器（不図示）から送出される信号で乗車扉開閉装置（不図示）に開扉を指示するものである。また、バス９０の乗車扉を閉じるために他の車載機器から乗車扉開閉装置に送出されて閉扉を指示する乗車閉扉信号が乗車表示端末２０に送られる場合もある。

なお、破線で表されている符号１７は、手動で操作する押しボタン（以下「停留所送りボタン」という）をバス９０の乗務員（運転士）が操作するごとに当該押しボタンから出力される停留所送り信号であり、歩進信号と呼ばれる場合もある。停留所送り信号１７は、バス９０の走行に伴って次に停車を予定する停留所（以下「次停留所」という）に合わせて、運賃表示器、車内放送装置、運賃箱等の車載機器の制御を進めるトリガ信号のことである。停留所送り信号１７により得られる情報のことを「停留所送り情報」という。

なお、このような乗務員（運転士）が手動で操作する停留所送りボタンに代えて、ＧＰＳ（Global Positioning System）により当該バス９０の走行位置を把握して自動的に停留所送り情報を出力するものを用いてもよい。これにより、乗務員（運転士）による停留所送りボタンの操作忘れによる停留所送り情報の出力抜けが発生しないため、乗車表示端末２０や降車表示端末３０に後述する二次元コードＤＣが表示されない事態を防ぐことが可能になる。

また、制御ユニット２１、表示ユニット２３、照明ユニット２５および通信ユニット２７には、ハウジング内に設けられる図略の電源ユニットからそれぞれの駆動電力が供給されている。そのため、図２には図示されていないが、乗車表示端末２０には、有線通信回線１５と電源ラインのワイヤハーネスが接続されている。また、有線通信回線１５は、Bluetooth（登録商標）やZigBee（登録商標）等の無線規格に準拠した無線通信回線に代えてもよい。この場合には、通信ユニット２７は、Bluetooth（登録商標）やZigBee（登録商標）等に対応したものに置き換える必要がある。

降車表示端末３０は、例えば、バス９０の降車口９３付近に設けられる握り棒Ｐ等に取り付けられており、乗車表示端末２０と同様にハードウェアが構成されている。つまり、降車表示端末３０は、主に、制御ユニット３１、表示ユニット３３、照明ユニット３５、通信ユニット３７等により構成されており、前述した乗車表示端末２０の、制御ユニット２１、表示ユニット２３、照明ユニット２５、通信ユニット２７にそれぞれ対応する。そのため、ここでは制御ユニット３１等の構成や接続関係の説明を省略する。

なお、降車表示端末３０はバス９０の降車口９３付近に設けられているため、バス９０の降車扉を開くタイミングで他の車載機器（不図示）から、降車扉信号が送られて来る。降車扉信号は、降車扉開閉装置に開扉を指示する信号である。また、降車口９３付近の運賃箱に当該利用者が見ることのできる小型ディスプレィが設けられている場合には、この小型ディスプレィを降車表示端末３０に代えて使用してもよい。この場合には、降車表示端末３０のハードウェアが削減でき、設備コストをさらに減らすことが可能になる。

ホスト機器４０は、本実施形態では運賃箱がこれに相当する。そのため、制御ユニット４１は運賃箱の制御ユニットが、また通信ユニット４７は運賃箱の通信ユニットが、それぞれその役割を担う。なお、ホスト機器４０は、このように既存の運賃箱等を用いることなく、既存の運賃箱等に関係なくホスト機器４０自体を単独で新規に設けてもよい。

制御ユニット４１は、運賃箱に設けられている運賃収受機構の駆動ユニット、運賃三角表データ等が書き込まれたデータカセット、ＩＣカードリーダライタ、ディスプレィ等の各種ユニット４６や、通信ユニット４７等を制御するコントローラであり、ＭＰＵ４２、メモリ４３、入出力インタフェース４４、図略の時計ユニット等から構成されている。ＭＰＵ４２は、各種ユニット４６等を制御する演算処理装置であり、システムバス４５等を介して、メモリ４３や入出力インタフェース４４等と接続されている。

メモリ４３は、半導体記憶装置であり、ＭＰＵ４２が使用する主記憶空間を構成するものである。本実施形態では、プログラム領域を担うＲＯＭとワーク領域やデータ領域に割り当てられるＤＲＡＭとにより構成されている。本実施形態では、ＲＯＭには、各種ユニット４６を制御するシステムプログラムや、後述する停留所情報等送出処理１００を可能にする停留所情報等送出プログラム等、各種の制御プログラムが格納されている。

なお、データカセットのメモリには、運賃三角表データのほかに、その系統番号、事業者名称、営業所名称、車両番号等が書き込まれているため、例えば、バス９０の運行路線が変更されるごとにその運行路線に対応したものに取り替えられる。運賃三角表データの例は、図３に図示されている。

入出力インタフェース４４は、制御ユニット４１の周辺装置に対して、シリアルやパラレルのデータのやり取りを仲介する入出力インタフェース装置である。本実施形態では、各種ユニット４６や通信ユニット４７等と接続可能に構成されている。入出力インタフェース４４は、各種ユニット４６を駆動するドライバ回路を備えている場合もある。

通信ユニット４７は、有線通信回線１５を介して制御ユニット４１が乗車表示端末２０や降車表示端末３０とデータ通信可能に構成されるシリアル通信装置であり、これらの通信ユニット２７，３７であるスレーブに対してホストとして機能するものである。本実施形態では、RS-458に準拠したものを使用しており、ホスト機器４０、乗車表示端末２０、降車表示端末３０等の間を有線通信回線１５でマルチドロップ接続している。通信プロトコルは、ホスト機器４０を含めて有線通信回線１５に接続されている乗車表示端末２０、降車表示端末３０等をＩＤで識別可能なものを使用している。

スマートフォン５０は、利用者が所有（所持）する携帯情報端末装置であり、「携帯型情報端末」や「携帯端末」と呼ばれる場合もある。スマートフォン５０は、一般に市販されているものであり、制御ユニット５１（ＭＰＵ、メモリ等）、無線ユニット５２、表示ユニット５３、カメラ５５、メモリカード、バッテリ等により構成され、これらが厚さ数ミリ程度の薄板状のケース内に収容されている。

なお、このようなスマートフォン５０の代わりに、画面サイズが８～１０インチの表示ユニットを有するデータ通信可能なタブレットタイプのパーソナルコンピュータ（以下「タブレット」という）を利用者が所持していてもよい。また、スマートフォンやタブレットでなく、携帯情報端末装置として、一般に市販されているカメラ付きの携帯電話装置（カメラ付き携帯）を利用者が所持していてもよい。

本実施形態では、スマートフォン５０は、例えば、Android（登録商標）やiOS（登録商標）等のＯＳ（基本ソフトウェア）で制御ユニット５１が動作しており、後述する運賃精算処理３００を実行する運賃精算アプリもこれらのＯＳ上で動作可能に構成されている。スマートフォン５０のＯＳはAndroid（登録商標）やiOS（登録商標）以外のものでもよいが、その場合には運賃精算アプリもそのＯＳ上で動作するように対応させる必要がある。無線ユニット５２は、移動体通信事業者（ＭＮＯ）の無線通信回線８５を介してデータ通信や音声通信可能に構成されている。

カメラ５５は、ＣＣＤやＣＭＯＳ等の固体撮像素子を備えたものであり、スマートフォン５０の裏側にレンズを有し、乗車表示端末２０や降車表示端末３０に表示された二次元コードＤＣの画像を撮影可能に構成されている。カメラ５５で撮影した画像データは、制御ユニット５１で情報処理することが可能であり、本実施形態では、運賃精算アプリによりデコードして二次元コードＤＣに埋め込まれた情報を取得可能にしている。なお、タブレットの場合は、表示ユニットの画面サイズが異なる以外はスマートフォン５０とほぼ同様に構成される。

管理サーバ６０および決済サーバ７０は、いずれも、主に、制御装置、データベース装置、ネットワーク機器等から構成されているファイルサーバである。制御装置は、データベース装置やネットワーク機器に接続されてこれらを制御する情報処理装置であり、例えば、サーバコンピュータがこれに相当する。データベース装置は、記憶容量が数１００ＴＢ（テラバイト）クラスの大容量情報記憶媒体である。ネットワーク機器は、例えば、インターネットＮに接続されている。

管理サーバ６０と決済サーバ７０のハードウェアの相違は、例えば、制御装置の処理速度やデータベース装置の記憶容量になるが、基本的には両サーバ６０，７０はハードウェア的にはほぼ同様に構成される。ソフトウェア的には、管理サーバ６０の場合、例えば、後述する停留所情報等記録処理をその制御装置が実行可能な停留所情報等記録プログラムが、当該制御装置のハードディスク装置等に格納される。また、決済サーバ７０の場合には、例えば、後述する運賃決済処理をその制御装置が実行可能な運賃決済プログラムが、当該制御装置のハードディスク装置等に格納される。

このため、本実施形態では、管理サーバ６０と決済サーバ７０を別体に構成したが、これらのサーバ６０，７０を同じサーバで構成してもよい。即ち、管理サーバ６０に決済サーバ７０の機能を持たせたり、決済サーバ７０に管理サーバ６０を機能を持たせたりしてもよい。この場合には、単一のサーバが備える制御装置のハードディスク装置等に停留所情報等記録プログラムや運賃決済プログラムが格納される。

このように乗車表示端末２０、降車表示端末３０、ホスト機器４０、スマートフォン５０、管理サーバ６０や決済サーバ７０を構成することによって、本実施形態の運賃収受システム１０では、図１１に表したシーケンス図のように、利用者Ｍがバス９０に乗車して降車するまでの間において、停留所情報等送出処理１００、コード出力処理２００、運賃精算処理３００等の各処理を行う。

なお、利用者Ｍは、運賃収受システム１０を利用するための事前準備として、例えば、運賃精算処理３００を当該利用者Ｍのスマートフォン５０において実行し得る運賃精算アプリをバス９０の運行事業者やスマートフォン用のアプリケーションプログラム（スマホアプリ）の販売業者等が運営するウェブサイトからダウンロードして当該スマートフォン５０にインストール（実装）する必要がある。

また、スマートフォン５０において運賃精算アプリを起動した後、初期設定作業として、利用者Ｍの氏名、生年月日、性別、住所、電話番号、職業等の個人情報を当該スマートフォン５０や管理サーバ６０に設定したり、またクレジットカード等の決済情報を当該スマートフォン５０に登録したりする必要がある。セキュアな情報管理を行う場合には、個人情報や決済情報は管理サーバ６０にのみ登録する。なお、スマートフォン５０は、ＭＡＣアドレスやデバイスＩＤにより一意に特定することが可能である。また、スマートフォン５０のＳＩＭカードに記憶されているＩＭＳＩ（International Mobile Subscriber Identity）でも特定できる。これにより、スマートフォン５０の所持者は利用者Ｍであることがわかるため、後述の停留所情報等ＩＳと利用者Ｍとの関連付けが可能になる。

［停留所情報等送出処理１００］
図１１に示すように、本実施形態の運賃収受システム１０では、まずバス９０のホスト機器４０が停留所情報等送出処理１００を開始する。即ち、ホスト機器４０では、前述したように制御ユニット４１のメモリ４３のＲＯＭに停留所情報等送出プログラムが格納されている。そのため、バス９０の運行開始前においてホスト機器４０に電源が投入されると、その直後にメモリ４３のＤＲＡＭに展開される停留所情報等送出プログラムを、ＭＰＵ４２が実行することによって図４に示す停留所情報等送出処理１００が開始される。なお、ＤＲＡＭに展開されたものではなくＲＯＭに格納された停留所情報等送出プログラムをＭＰＵ４２が直接実行するように構成してもよい。

図４に示すように、停留所情報等送出処理１００では、まずステップＳ１０１により所定の初期化処理が行われる。この処理では、例えば、制御ユニット４１のメモリ４３の本処理用のワーク領域やフラグをクリアしたり、ほぼ同時期に起動される乗車表示端末２０や降車表示端末３０に対する初期設定用の制御コマンドの送出が行われたりする。続くステップＳ１０２では、当該バス９０が走行する系統番号を乗務員が入力する系統番号入力処理が行われる。

次のステップＳ１０３では始発停留所情報等読出し処理が行われる。始発停留所情報等は、バス９０の始発の停留所ＢＳａに関する情報であり、例えば、次に列挙する(1)～(8)の情報である。これらのうち、(1)～(4)はバス９０の走行中に変動するものであり、(5)～(8)は固定されているものである。
(1) 整理券番号
(2) 各整理券番号に対応した運賃データ
(3) 停留所名称
(4) 停留所連番号
(5) 系統番号
(6) 事業者名称
(7) 営業所名称
(8) 車両番号

始発の停留所ＢＳａにおいては、(1)の整理券番号は「４」であり、(2)の運賃データは、整理券番号４に対応した２００円だけである。また、(3)の停留所名称は、例えば「ＡＢＣ駅」であり、(4)の停留所連番号は、例えば「０」である。これらの各情報は停留所ＢＳごとに変更される。これに対して(5)～(8)の各情報は停留所ＢＳが進んでも変更されることのない情報である。例えば、(5)の系統番号は「０１」、(6)の事業者名称は「ＸＹＺ交通」、(7)の営業所名称は「○×△営業所」、(8)の車両番号は「１２３」等である。本実施形態では、これらの各情報は、例えば、ホスト機器４０に接続されているデータカセットのメモリに記憶されているため、そこから読み出して前記の(1)～(8)の各情報を得る（図３参照）。

次のステップＳ１０５では始発停留所情報等送出処理が行われる。運行開始前の始発の停留所ＢＳａにおいては、運賃表示器等の車載機器の電源が投入されると、押しボタンから停留所送り信号１７が出力されなくても、運賃表示器や車内放送装置により当該バス９０の系統番号や行き先等の案内情報が自動的に行われて運賃箱等も所定の制御処理が開始される。そのため、ホスト機器４０においても、乗車表示端末２０や降車表示端末３０に対して始発の停留所ＢＳａの停留所情報等ＩＳａを生成して送出する（図１１参照）。

送出する始発の停留所情報等ＩＳａには、上記(1)～(8)の各情報に加えて(9)の表示更新日時が付加される。即ち、ホスト機器４０では、停留所情報等ＩＳａを送出する直前時点の年月日時分秒の時刻情報を(9)の表示更新日時として追加して停留所情報等ＩＳａを生成する。例えば、２０１９年９月２５日１７時４６分をバイナリデータで表したものを追加する。本実施形態では、停留所情報等ＩＳａは、例えば、上記(1),(2),(4),(5),(8),(9)をバイナリデータ、(3),(6),(7)をテキストデータでそれぞれ表したものとして生成される。なお、これら(1)～(9)をすべてテキストデータで生成してもよい。

これにより、乗車表示端末２０や降車表示端末３０では、後述するように、図５に示すコード出力処理２００によって停留所情報等ＩＳａを取得し（Ｓ２０３）、表示ユニット２３，３３に二次元コードＤＣ等を出力することが可能になる（Ｓ２１３，Ｓ２１５，Ｓ２１７）。これらの表示端末２０，３０の制御ユニット２１，３１により実行されるコード出力処理２００の内容については後で詳述する。

次のステップＳ１０７では停留所送り情報取得処理が行われる。停留所送り情報は、前述したように乗務員（運転士）が図略の押しボタンを操作するごとに出力される停留所送り信号１７により得られる情報のことである。この停留所送り情報の入力の有無は、例えば、所定の割り込み処理の有無や所定のフラグのオンオフにより得ることができる。停留所送り情報が得られた場合には、次停留所に合わせて、運賃表示器、車内放送装置、運賃箱等の車載機器の制御を進める指示を乗務員が行ったことになる。

このため、続くステップＳ１０９により、停留所送り情報を取得したか否かを判定し、取得した場合には（Ｓ１０９；Ｙｅｓ）、次のステップＳ１１１に処理を進め、停留所送り情報を取得したと判定できない（取得していない）場合には（Ｓ１０９；Ｎｏ）、ステップＳ１０７に戻り、再度、停留所送り情報取得処理を行う。つまり、停留所送り情報を取得するまでステップＳ１０７，Ｓ１０９を繰り返し行う。

ステップＳ１１１では次停留所情報等読出し処理が行われる。この処理では、ホスト機器４０のデータカセットから、次停留所ＢＳｂに関する情報として上記(1)～(8)の次停留所情報等を読み出す。もし読み出した次停留所情報等が上記(1)～(8)の各情報ではなく、次停留所が存在しない旨の終了情報であった場合には、次のステップＳ１１３による判定処理により次停留所がない、つまり前停留所が終着の停留所であったと判定して（Ｓ１１３；Ｙｅｓ）、本停留所情報等送出処理１００を終了する。

ステップＳ１１１により読み出した次停留所情報等が上記(1)～(8)の各情報である場合には次停留所ＢＳｂがあると判定して（Ｓ１１３；Ｎｏ）、続くステップＳ１１５に処理を移行する。ステップＳ１１５では停留所情報等送出処理が行われる。この処理は、前述の始発停留所情報等送出処理（Ｓ１０５）と同様に、送出直前時点の(9)表示更新日時の情報を付加して停留所情報等ＩＳｂを生成して乗車表示端末２０や降車表示端末３０に送出する。

ここで送出される停留所情報等ＩＳｂは、上記(1)～(4),(9)が変更される。例えば、図３に示す運賃三角表データの場合、停留所ＢＳｂに対する停留所情報等ＩＳｂは、(1)の整理券番号が「３」になり、(2)の運賃データが整理券番号３に対応した２００円と整理券番号４に対応した２００円になる。(3)の停留所名称は「○×△１丁目」になり、(4)の停留所連番号は「１」になるため、それぞれ変更される。また(9)の表示更新日時は、例えば、２０１９年９月２５日１７時５２分に変更される。

ステップＳ１１５の停留所情報等送出処理が終わると、ステップＳ１０７に戻り停留所送り情報取得処理が行われる。そして、停留所送り情報を取得するごとに（Ｓ１０７，Ｓ１０９：Ｙｅｓ）、次停留所情報等を読み出して（Ｓ１１１）、停留所情報等ＩＳを生成して乗車表示端末２０や降車表示端末３０に送出する（Ｓ１１５）。これにより、乗車表示端末２０や降車表示端末３０では、停留所ＢＳａ，ＢＳｂ，…，ＢＳｄごとに異なる二次元コードＤＣａ，ＤＣｂ，…，ＤＣｄを表示ユニット２３，３３に表示することが可能になる（図１１参照）。

［コード出力処理２００］
次に乗車表示端末２０や降車表示端末３０が実行するコード出力処理２００を説明する。これらの表示端末２０，３０も、前述したように制御ユニット２１，３１のメモリにコード出力プログラムが格納されている。そのため、バス９０の運行開始前においてホスト機器４０とともに表示端末２０，３０に電源が投入されると、その直後にメモリのＤＲＡＭに展開されるコード出力プログラムを、制御ユニット２１，３１のＭＰＵが実行することによって図５に示すコード出力処理２００が開始される。なお、ＤＲＡＭに展開されたものではなくＲＯＭに格納されたコード出力プログラムをＭＰＵが直接実行するように構成してもよい。

乗車表示端末２０および降車表示端末３０で実行されるコード出力処理２００は、これらの表示端末２０，３０のいずれも同様に情報処理がされるため、ここでは乗車表示端末２０のコード出力処理２００を代表して説明する。なお、降車表示端末３０の場合には、制御ユニット２１を制御ユニット３１に置き換え、また表示ユニット２３を表示ユニット３３に置き換え、乗車口９１の乗車扉を降車口９３の降車扉に置き換え、乗車開扉信号を降車開扉信号に置き換えると処理内容が理解できる。

図５に示すように、コード出力処理２００では、まずステップＳ２０１により所定の初期化処理が行われる。この処理では、例えば、制御ユニット２１のメモリ（ＤＲＡＭやＳＲＡＭ）のワーク領域、タイマーカウンタやフラグをクリアしたり、ほぼ同時期に起動されるホスト機器４０から送られて来る制御コマンドに基づいて初期設定等が行われたりする。

次のステップＳ２０３では停留所情報等取得処理が行われる。前述したように、電源投入後の運行開始前のホスト機器４０では、始発の停留所ＢＳａの停留所情報等ＩＳａを送出するので（図１１参照）、この処理では、制御ユニット２１の入力バッファに保持されている停留所情報等ＩＳａを取得する。取得した場合には（Ｓ２０５；Ｙｅｓ）、続くステップＳ２０７でエンコード処理が行われ、取得していない場合には（Ｓ２０５；Ｎｏ）、取得するまでステップＳ２０３，Ｓ２０５を繰り返し行う。

ステップＳ２０７のエンコード処理では、ステップＳ２０３により取得した停留所情報等ＩＳａを暗号化した後、二次元コードＤＣを生成する。本実施形態では、停留所情報等ＩＳを直接、二次元コードにするのではなく、暗号化したものを二次元コードＤＣにしているため、二次元コードＤＣが不正に生成されるのを防止可能にしている。

本実施形態では、二次元コードＤＣは、例えばＱＲコードである。なお、ＱＲコードは登録商標である（以下同じ）。本実施形態では、停留所情報等ＩＳａは、例えば、次に列挙する(1)～(9)の情報であり、このうち(1),(2),(4),(5),(8),(9)はバイナリデータ、(3),(6),(7)はテキストデータでそれぞれ表されており暗号化されていない（平文データ）。なお、これら(1)～(9)をすべてテキストデータで生成してもよい。
(1) 整理券番号
(2) 各整理券番号に対応した運賃データ
(3) 停留所名称
(4) 停留所連番号
(5) 系統番号
(6) 事業者名称
(7) 営業所名称
(8) 車両番号
(9) 表示更新日時

このため、ステップＳ２０７では、このような平文データを所定の暗号鍵で暗号化して暗文データに変換（暗号化）した後、二次元コードＤＣの画像情報を生成する。本実施形態では、暗号鍵は共通鍵であり、例えば、乗車表示端末２０の製造時に制御ユニット２１のメモリ（ＲＯＭやＳＲＡＭ）に暗号鍵が書き込まれる。本実施形態では、二次元コードＤＣは、例えば、サイズが２１×２１モジュールのタイプ１（型番１）のＱＲコードであるが、データ容量が不足する場合には、２５×２５モジュールのタイプ２（型番２）のＱＲコードやタイプ３（型番３）以上のＱＲコードを用いてもよい。

続くステップＳ２０９では開扉信号取得処理が行われる。本実施形態では、乗車口９１の乗車扉を開けるタイミングで、有線通信回線１５を介して他の車載機器（不図示）から乗車表示端末２０に乗車開扉信号が送られて来る。乗車開扉信号の有無は、例えば、所定の割り込み処理の有無や所定のフラグのオンオフにより得ることができるため、この処理では、乗車開扉信号の情報（開扉情報）を所定の割り込み処理の有無やフラグの状態により取得する。そして、乗車開扉信号を取得していると判定した場合には（Ｓ２１１；Ｙｅｓ）、次のステップＳ２１３のコード出力開始処理により二次元コードＤＣの画像情報を表示ユニット２３に出力する。

乗車開扉信号を取得していないと判定した場合には（Ｓ２１１；Ｎｏ）、取得するまでステップＳ２０９，Ｓ２１１を繰り返し行う。本実施形態では、ステップＳ２１３によるコード出力開始処理は、乗車開扉信号を取得した後（Ｓ２１１；Ｙｅｓ）、乗車開扉信号を取得できなくなってから（Ｓ２１５；Ｎｏ）、予め定められた所定時間（例えば、３０秒間または１分間等）が経過するまで継続される（Ｓ２１６；Ｎｏ）。これにより、乗車扉が開いている間と扉が閉じてから所定時間（例えば３０秒間）が経過するまでは二次元コードＤＣが乗車表示端末２０や降車表示端末３０に表示される。そのため、扉が閉じる直前に乗車した利用者や乗車時に二次元コードＤＣの取得を忘れてそれに直ぐ気がついた利用者等も二次元コードＤＣの取得が可能になる。また、バス９０の走行中においては、乗車表示端末２０や降車表示端末３０に二次元コードＤＣが表示されないため、二次元コードＤＣの不正取得を防止することが可能になる。

即ち、開扉期間中に実行される開扉信号取得処理（Ｓ２１４）で乗車扉開信号を取得できなくなったと判定（Ｓ２１５；Ｎｏ）した直後から、カウントを開始するタイマーカウンタの値に基づいて、ステップＳ２１６により所定時間が経過した否かを判定する。そして、所定時間が経過したと判定すると（Ｓ２１６；Ｙｅｓ）、続くステップＳ２１７のコード出力終了処理により表示ユニット２３に対する二次元コードＤＣの画像情報の出力を終了して、前述の停留所情報等取得処理（Ｓ２０３）に処理を戻す。

これにより、図１１に示すように、例えば、乗車表示端末２０では、始発の停留所ＢＳａにおいて乗車扉が開くと（開扉→）、そのタイミングで表示ユニット２３に二次元コードＤＣａの表示を開始し乗車扉が閉じてから（閉扉→）所定時間の経過後に表示を終了する。また、次の停留所ＢＳｂにおいても、乗車扉が開くと（開扉→）、乗車表示端末２０が二次元コードＤＣｂの表示を開始し乗車扉が閉じてから（閉扉→）所定時間の経過後に表示を終了し、また降車扉が開く（開扉→）と、降車表示端末３０が二次元コードＤＣｂの表示を開始し所定時間の経過後に表示を終了する。

同様に、停留所ＢＳｄにおいて、乗車扉が開くと（開扉→）乗車表示端末２０が二次元コードＤＣｄの表示を開始し、降車扉が開く（開扉→）と降車表示端末３０が二次元コードＤＣｄの表示を開始する。そして、それぞれの扉が閉じてから（閉扉→）、所定時間が経過すると、表示ユニット２３，３３による二次元コードＤＣｄのそれぞれの表示を終了する。

したがって、バス９０の走行中には、乗車表示端末２０や降車表示端末３０に二次元コードＤＣが表示されないことから、例えば、乗車時に乗車表示端末２０に表示された二次元コードＤＣｂをスマートフォン５０で取得することなく、乗車後に他の停留所に対応して二次元コードＤＣｂよりも後に表示された二次元コードＤＣｄを事後的に取得するような二次元コードＤＣの不正取得を防止することが可能になる。

［運賃精算処理３００］
続いてスマートフォン５０が実行する運賃精算処理３００を説明する。なお、ここでは運賃精算処理３００を実行可能な運賃精算アプリがスマートフォン５０にインストールされ、かつ、利用者Ｍの個人情報やクレジットカード等の決済情報が、管理サーバ６０や決済サーバ７０に登録されていることを前提とする。

図１１に示すように、利用者Ｍは、バス９０に乗車する前にスマートフォン５０を操作して運賃精算アプリを起動する。これにより、スマートフォン５０の制御ユニット５１によって図６に示す運賃精算処理３００が開始される。

図６に示すように、運賃精算処理３００では、まずステップＳ３０１により所定の初期化処理が行われる。この処理では、例えば、制御ユニット５１のメモリ（ＤＲＡＭ）の本処理用のワーク領域やフラグ等がクリアされる。次のステップＳ３０３では選択メニュー表示処理が行われる。

本実施形態では、例えば、図１２(A)に示すような選択メニュー画面がスマートフォン５０の表示ユニット５３に表示される（Ｓ３０３）。表示ユニット５３の画面には、「乗車」、「降車」、「終了」および「ヘルプ」の各ボタンが表示されるため、利用者Ｍはこれらのボタンに触れることでそれぞれの機能を選択する。

例えば、「乗車」は、乗車口９１の乗車表示端末２０に表示される二次元コードＤＣを取得する機能を選択するボタンであり、利用者Ｍが「降車」ボタンを選択する前のみ選択可能に構成されている。通常は、利用者Ｍがバス９０の乗車前に選択する。また「降車」は、降車口９３の降車表示端末３０に表示される二次元コードＤＣを取得する機能を選択するボタンであり、利用者Ｍが「乗車」ボタンを選択した後のみに選択可能に構成されている。通常は、バス９０に乗車した利用者Ｍが降車前に選択する。

「ヘルプ」は、利用者Ｍがこの運賃精算アプリの使い方を知りたい場合に選択するボタンである。「終了」は、利用者Ｍがこの運賃精算アプリを終了したい場合に選択するボタンである。「ヘルプ」ボタンと「終了」ボタンは、選択メニュー画面が表示されている状態であれば、いつでも選択できる。図示されていないが、本実施形態では、選択不能のボタンは、ボタン表示の色調を弱く（淡く）して視覚的に選択できないことを表している。

なお、図示されていないが、利用履歴を表示させて確認することができる「利用履歴」ボタンや、フリーパスや定期券等の予め定められた期間だけ利用可能な機能を運賃精算アプリが有する場合には、その有効期限を表示させて確認することができる「有効期限」ボタン等がスマートフォン５０の選択メニュー画面に表示される。

ステップＳ３０５により利用者Ｍの選択入力の有無を判定して入力があるまで待つ（Ｓ３０５；Ｎｏ）。そして、選択入力があった場合には、その選択が「乗車」であれば（Ｓ３０５；Ｙｅｓ：乗車）、続くステップＳ３０７に処理を移行し、「終了」であれば（Ｓ３０５；Ｙｅｓ：終了）、本運賃精算処理３００を終えて運賃精算アプリを終了する。

なお、利用者Ｍは、運賃精算アプリにおいて「乗車」ボタンを選択する前は「降車」ボタンを選択することができないため、このステップＳ３０５では「降車」ボタンの入力判定は行われない。また、「ヘルプ」ボタンが選択入力された場合は、図略の別のタスク（スレッド、プログラム）においてヘルプ画面等が表示される。

利用者Ｍの選択入力が「乗車」であった場合には、続くステップＳ３０７によりコード取得処理が行われる。この処理は、サブルーチンとして図７にその流れが図示されているため、ここからは図７も参照しながら説明する。

［コード取得処理４００］
図７に示すように、コード取得処理４００では、ステップＳ４０１の所定の初期化処理により、デコードに使用するワーク領域やフラグ等をクリアした後、ステップＳ４０３のコード情報取得処理によって二次元コードＤＣを取得する。本実施形態では、二次元コードＤＣの取得は、カメラ５５で二次元コードＤＣの画像を撮影することにより行う。

この処理では、例えば、図１２(B)に示すように、四隅を「」で囲んだガイド枠によって被写体の位置および範囲を明示することによって、このガイド枠内に二次元コードＤＣが収まるように利用者Ｍによるスマートフォン５０の操作を案内する。スマートフォン５０のカメラ５５は、焦点距離、露出、シャッタスピードおよびシャッタタイミングを適切に設定する自動調整機能を有する。そのため、二次元コードＤＣの全体がガイド枠内に入ると、カメラ５５が自動で撮影する。

前述したように、バス９０の乗車扉が開いた後から乗車扉が閉じても所定期間中（例えば３０秒間）、乗車口９１の乗車表示端末２０に二次元コードＤＣａが表示され続ける。そのため、利用者Ｍは、乗車口９１から乗車する際にスマートフォン５０のカメラ５５で二次元コードＤＣａを撮影する。乗車する際（乗車時）に撮影された二次元コードＤＣａは、乗車停留所情報として、制御ユニット５１のメモリのワーク領域に格納される（図１１参照）。

二次元コードＤＣが撮影できた場合には、ステップＳ４０５の判定処理により取得したと判定して（Ｓ４０５；Ｙｅｓ）、次のステップＳ４０７のデコード処理を行う。二次元コードＤＣが撮影できない場合には（Ｓ４０５；Ｎｏ）、撮影できるまでコード情報取得処理（Ｓ４０３）を行う。なお、所定時間経過しても、二次元コードＤＣが撮影できない場合には、本コード取得処理４００を強制的に終了して、選択メニュー表示処理（Ｓ３０３）に戻るように処理の流れを構成してもよい。

ステップＳ４０７では取得した二次元コードＤＣのデコード処理が行われる。本実施形態では、二次元コードＤＣはＱＲコードであるため、所定のアルゴリズムに従って解析した後、得られた暗文データを所定の暗号鍵で復号して平文データに戻す。この暗号鍵は、共通鍵であり、ウェブサイトから運賃精算アプリをダウンロードしてインストールする際にスマートフォン５０が取得している。平文データには、停留所情報等ＩＳとして、前述した(1)～(9)の各情報が含まれている。つまり、二次元コードＤＣから停留所情報等ＩＳが取り出される。なお、暗号鍵は、セキュリティの強度を高めるため、初回のインストール時のみならず、定期的に更新(ダウンロード)されるのが望ましい。

次のステップＳ４０９では停留所情報等記憶処理が行われる。この処理では、デコードして取り出した停留所情報等ＩＳ（乗車停留所情報）を制御ユニット５１のメモリのワーク領域に記憶する。続くステップＳ４１１ではモード情報取得処理が行われる。この処理では、スマートフォン５０の無線ユニット５２の動作モード情報を取得し、取得した動作モード情報に基づいて、利用可能ではない機内モードに設定されているか否かをステップＳ４１３により判定する。

そして、無線ユニット５２を利用不能な機内モード、つまり無線通信回線を介した情報通信を行わないようにスマートフォン５０が設定されている場合には（Ｓ４１３；Ｙｅｓ）、停留所情報等ＩＳを管理サーバ６０に送信することができないことから、ステップＳ４１５により機内モード表示処理が行われる。この処理では、例えば、図１３(A)に示すような機内モードの解除を促すメッセージ「機内モードを解除してくださ」がスマートフォン５０の表示ユニット５３の画面に表示される。このメッセージの背景色は、例えば、赤色に設定され、文字色は白色または黄色に設定される。これにより、利用者Ｍに対して色彩的にインパクトを与え得るメッセージの表示が可能になる。

この図１３(A)に示す画面の例では、乗車した停留所名称として「ＡＢＣ駅」が表示され、また整理券番号として「４」も表示されている。これは、ステップＳ４０７でデコードした停留所情報等ＩＳａから得た情報のうち、(1)の整理券番号および(3)の停留所名称の各情報である。このほか(2)の運賃データとして「整理券番号４に対応した２００円」、(4)の停留所連番号として「０」、(5)の系統番号として「０１」、(6)の事業者名称として「ＸＹＺ交通」、(7)の営業所名称として「○×△営業所」、(8)の車両番号として「１２３」、(9)の表示更新日時として「２０１９年９月２５日１７時４６分」が得られている。

ステップＳ４１５によるこのようなメッセージの表示は、機内モードが解除されるまで継続される（Ｓ４１３；Ｙｅｓ→Ｓ４１１）。もとからスマートフォン５０が機内モードに設定されていない場合や機内モードが解除された場合には（Ｓ４１３；Ｎｏ）、ステップＳ４１７により無線送信処理が行われる。この無線送信処理は、管理サーバ６０に対する送信処理であり、サブルーチンとして図８にその流れが図示されているため、ここからはさらに図８も参照しながら説明する。

［無線送信処理５００］
図８に示すように、無線送信処理５００では、ステップＳ５０１の所定の初期化処理により、送信バッファに使用するワーク領域、リトライカウンタやフラグ等をクリアした後、ステップＳ５０３の送信バッファセット処理が行われる。送信バッファは、無線ユニット５２が無線送信するデータフォーマット（送信フォーマット）を所定の通信プロトコルに準拠させるために設けられている。そのため、この処理では、宛先情報として管理サーバ６０のＩＰアドレス情報、送信元情報としてスマートフォン５０のＩＰアドレス情報や停留所情報等ＩＳａを送信バッファにセットする。

続くステップＳ５０５では送信処理が行われる。これにより、送信バッファにセットされた停留所情報等ＩＳａ（乗車停留所情報）は、無線ユニット５２が送信する送信データＴＸａとして、例えば、最寄りの基地局８０に向けて送信される（図１１参照）。送信データＴＸａは、複数のパケットデータに分割されて基地局８０に送信される場合もある。基地局８０では、このような送信データＴＸａを受信すると、所定のデータフォーマットに変換した後、インターネットＮに接続された管理サーバ６０に向けて送信する。

管理サーバ６０では、後述するように停留所情報等ＩＳａ（乗車停留所情報）等を受信すると、スマートフォン５０に向けて受信結果情報を折り返して送信する。そのため、スマートフォン５０の無線ユニット５２では、ステップＳ５０５により停留所情報等ＩＳａを送信した後、管理サーバ６０から送信されて来る受信結果情報ＲＸａを受信する。そのため、続くステップＳ５０７では、この受信結果情報ＲＸａに基づいて送信完了の可否を判定する。

送信が完了した場合には（Ｓ５０７；Ｙｅｓ）、ステップＳ５０８により送信結果フラグに送信完了情報をセットして本無線送信処理５００を終了し、図７のコード取得処理４００に処理を戻す。これに対して、送信が完了しない場合や受信結果情報ＲＸａを受信できない場合には（Ｓ５０７；Ｎｏ）、ステップＳ５０９によりリトライカウンタをインクリメント（加算）した後、カウンタ値、つまりリトライ回数が所定回数（例えば３回）を超えているか否かをステップＳ５１１により判定する。

リトライ回数が所定回数を超えていない場合には（Ｓ５１１；Ｎｏ）、リトライ回数が所定回数を超えるか（Ｓ５１１；Ｙｅｓ）、または送信完了するまで（Ｓ５０７；Ｙｅｓ）、ステップＳ５０５による送信処理を繰り返す。また、リトライ回数が所定回数を超えている場合には（Ｓ５１１；Ｙｅｓ）、ステップＳ５１３により送信結果フラグに送信未了情報をセットして本無線送信処理５００を終了し、図７のコード取得処理４００に処理を戻す。

図７のコード取得処理４００のステップＳ４１７に戻ると、コード取得処理４００を終了して図６の運賃精算処理３００のステップＳ３０９に戻る。本実施形態では、送信結果フラグに送信未了情報がセットされている場合、つまり停留所情報等ＩＳａ（乗車停留所情報）が管理サーバ６０に対して送信できていない場合においても、利用者Ｍの乗車を拒否することなく許容する。これにより、例えば、利用者Ｍがスマートフォン５０を使用している周囲の電波状態が良好でなく無線通信回線８５に通信障害が生じている場合等においても、滞りなく利用者Ｍの乗車を可能にすることができる。

なお、図６には図示されていないが、送信結果フラグに送信未了情報がセットされている場合には、例えば、図略の別のタスク（スレッド、プログラム）において、管理サーバ６０に対する停留所情報等ＩＳａ（乗車停留所情報）の再送信を複数回実行する処理（再送処理）を行うように処理の流れを構成してもよい。これにより、利用者Ｍが乗車した後、または降車した後に事後的に停留所情報等ＩＳａを管理サーバ６０に送信することが可能になるため、利用者Ｍがどこからどこまでバス９０（乗合車両）を利用したかの情報（いわゆるＯＤデータ（Ｏrgin；出発地、Ｄestination；目的地））の収集率を高めることができる。また意図的に通信障害を発生させて無賃乗車を謀ることを防止したりそのような企てを抑制したりすることもできる。

［運賃精算処理３００の続き］
図６に示すように、ステップＳ３０７によるコード取得処理が終わると、次にステップＳ３０９により選択メニュー表示処理が行われる。コード取得処理（Ｓ３０７）は、利用者Ｍがバス９０に乗車する際に乗車口９１で乗車表示端末２０に表示される二次元コードＤＣをスマートフォン５０で取得するときに実行されることから、コード取得処理（Ｓ３０７）が終了したタイミングでは、利用者Ｍはバス９０に乗車している蓋然性が高い。

このため、ステップＳ３０９では選択メニュー表示処理を実行することにより、利用者Ｍに対して、降車時においてもスマートフォン５０により二次元コードＤＣを取得する必要があることを明示する。例えば、図１２(A)に示すような選択メニュー画面がスマートフォン５０の表示ユニット５３に表示される。

ここでの利用者Ｍは、既にバス９０の乗車時において乗車表示端末２０の二次元コードＤＣを取得しているため、「乗車」ボタンを選択することも「終了」ボタンを選択することもできない。したがって、利用者Ｍは、「降車」ボタンと「ヘルプ」ボタンの択一的な選択だけが許容される。なお、「ヘルプ」ボタンが選択入力された場合は、図略の別のタスク（スレッド、プログラム）においてヘルプ画面等が表示される。なお、このような画面に代えて、例えば、「乗車日時」、「乗車停留所名称」、「路線名称」等をスマートフォン５０の表示ユニット５３に表示させるように構成してもよい。これにより、乗車済みであることを一目瞭然に把握することができる。

ステップＳ３１１の判定処理により利用者Ｍの選択入力が「降車」であったと判定した場合には（Ｓ３１１；Ｙｅｓ：降車）、続くステップＳ３１３によりコード取得処理が行われる。この処理については、既に図７を参照して説明しているので、ここではコード取得処理（Ｓ３１３）の説明は省略して図１１を参照しながら処理概要を説明する。

例えば、利用者Ｍが、停留所ＢＳｄで降車する場面には、バス９０の降車扉が開いた後から降車扉が閉じても所定期間中（例えば３０秒間）、降車口９３の降車表示端末３０に二次元コードＤＣｄが表示され続ける。そのため、利用者Ｍは、降車口９３から降車する前（または降車する際）にスマートフォン５０のカメラ５５で二次元コードＤＣｄを撮影する（Ｓ４０３）。撮影された二次元コードＤＣｄは、降車停留所情報として、制御ユニット５１のメモリのワーク領域に格納された後、デコードされて停留所情報等ＩＳｄ（降車停留所情報）が取り出される（Ｓ４０７）。

停留所情報等ＩＳｄは、停留所ＢＳｄに対応するものである。即ち、例えば、(1)の整理券番号として「２」、(2)の運賃データとして「整理券番号２に対応した２００円、整理券番号３に対応した２２０円および整理券番号４に対応した２２０円」、(3)の停留所名称として「○○公園北」、(4)の停留所連番号として「４」、(5)の系統番号として「０１」、(6)の事業者名称として「ＸＹＺ交通」、(7)の営業所名称として「○×△営業所」、(8)の車両番号として「１２３」、(9)の表示更新日時として「２０１９年９月２５日１８時０３分」が得られる（図３参照）。

そして、スマートフォン５０が機内モードである場合には（Ｓ４１３；Ｙｅｓ）、図１３(B)に示すようにスマートフォン５０の表示ユニット５３の画面に、利用者Ｍにインパクトを与え得る色彩で機内モードの解除を促すメッセージ「機内モードを解除してくださ」が表示される。図１３(B)に示す画面の例では、乗車した停留所名称「ＡＢＣ駅」に加えて降車する停留所名称として上記(3)の「○○公園北」が表示されている。

二次元コードＤＣｄから取り出された停留所情報等ＩＳｄ（降車停留所情報）は、スマートフォン５０の無線ユニット５２が送信する送信データＴＸｂとして、最寄りの基地局８０に向けて送信されて、基地局８０およびインターネットＮを経由して管理サーバ６０に到達する。管理サーバ６０では、停留所情報等ＩＳｄ（降車停留所情報）を受信すると、スマートフォン５０に向けて受信結果情報を折り返して送信する。スマートフォン５０の無線ユニット５２では、停留所情報等ＩＳｄの送信後に管理サーバ６０から送信されて来る受信結果情報ＲＸｂを受信する。

本実施形態では、停留所情報等ＩＳｄ（降車停留所情報）が管理サーバ６０に対して送信できていない場合においても、利用者Ｍが降車に際して行う予定の決済処理を拒否することなく許容する。これにより、例えば、利用者Ｍがスマートフォン５０を使用している周囲の電波状態が良好でなく無線通信回線８５に通信障害が生じている場合等においても、滞りなく利用者Ｍの決済処理を可能にすることができる。

図６には図示されていないが、このような場合には、例えば、図略の別のタスク（スレッド、プログラム）において、管理サーバ６０に対する停留所情報等ＩＳｄ（降車停留所情報）の再送信を複数回実行する処理（再送処理）を行うように処理の流れを構成してもよい。これにより、利用者Ｍが降車した後に事後的に停留所情報等ＩＳｄを管理サーバ６０に送信することが可能になるため、ＯＤデータの収集率を高めることができる。また、意図的に通信障害を発生させて無賃乗車を謀ることを防止したりそのような企てを抑制したりすることもできる。

ステップＳ３１３によるコード取得処理が終わると、利用者Ｍのスマートフォン５０には、乗車した停留所ＢＳａの停留所情報等ＩＳａ（乗車停留所情報）と、降車する停留所ＢＳｄの停留所情報等ＩＳｄ（降車停留所情報）とが保持（記憶）されている。そのため、次のステップＳ３１５により利用運賃取得処理が行われる。本実施形態では、利用運賃は、例えば、乗車した停留所ＢＳの停留所情報等ＩＳに含まれる(1)整理券番号と、降車する停留所ＢＳの停留所情報等ＩＳに含まれる(2)運賃データと、により求める。

図１１に示す例では、スマートフォン５０は、停留所情報等ＩＳａ（乗車停留所情報）として(1)の整理券番号「４」と、停留所情報等ＩＳｄ（降車停留所情報）として(2)の運賃データ「整理券番号２に対応した２００円、整理券番号３に対応した２２０円および整理券番号４に対応した２２０円」と、得ている。そのため、停留所情報等ＩＳｄ（降車停留所情報）に含まれる(2)の運賃データ「整理券番号２に対応した２００円、整理券番号３に対応した２２０円および整理券番号４に対応した２２０円」の中から、停留所情報等ＩＳａ（乗車停留所情報）の(1)の整理券番号「４」に対応した「２２０円」を選択することで、利用運賃「２２０円」（利用運賃情報）が求められる（図１４参照）。

利用者Ｍの利用運賃情報がステップＳ３１５により得られると、決済サーバ７０において電子決済に関する情報処理を行うため、利用運賃情報と決済情報を決済サーバ７０に送信する必要がある。そこで、次のステップＳ３１７では、今回の運賃情報（利用運賃情報）と利用者Ｍの決済情報を無線送信処理により決済サーバ７０に送信する。なお、無線送信処理についても、既に図８を参照して説明しているので、ここでは無線送信処理（Ｓ３１７）の説明は省略して、図１１を参照しながら処理概要を説明する。

利用者Ｍの決済情報（クレジットカードの情報（氏名、カード番号、有効期限、セキュリティコード等））は、運賃精算アプリの初期設定時にスマートフォン５０に登録されている（セキュアな情報管理を行う場合、決済情報は管理サーバ６０に登録されている）。そのため、無線送信処理５００では、このような決済情報と利用運賃情報（先の例では２２０円）に加えて、宛先情報として決済サーバ７０のＩＰアドレス情報や、送信元情報としてスマートフォン５０のＩＰアドレス情報を送信バッファにセットした後（Ｓ５０３）、送信データＴＸｃとして、例えば、最寄りの基地局８０に向けて送信する（決済情報が管理サーバ６０にのみ登録されている場合には、スマートフォン５０からは決済情報が送られて来ないため、決済サーバ７０は決済情報を管理サーバ６０から取得する）。

決済サーバ７０では、後述するように利用運賃情報等を受信すると、スマートフォン５０に向けて受信結果情報を折り返して送信する。本実施形態では、利用運賃情報等が決済サーバ７０に対して送信できていない場合には、決済サーバ７０のよる決済処理が未了の場合、即ち決済結果フラグが決済未了にセットされている場合と同様の処理をステップＳ３２３による処理結果告知処理において行う。

また、決済サーバ７０では、決済処理を行いその決済処理の結果をスマートフォン５０に向けて送信する。そのため、図６に示すように、スマートフォン５０による運賃精算処理３００では、決済サーバ７０から送信されて来る決済結果情報ＲＸｃをステップＳ３１９の決済結果受信処理により受信する。そして、受信した決済結果情報ＲＸｃをステップＳ３２１により制御ユニット５１のメモリ（ＤＲＡＭ）に保存した後、ステップＳ３２３によりその決済結果情報ＲＸｃに基づいて処理結果告知処理を行う。

即ち、決済サーバ７０による運賃決済処理７００により、決済処理が完了している場合には、決済完了にセットされた決済結果フラグが決済結果情報ＲＸｃに含まれており、決済処理が完了していない場合には、決済未了にセットされた決済結果フラグが決済結果情報ＲＸｃに含まれている。

このため、ステップＳ３２３の処理結果告知処理では、決済結果フラグの情報に基づいて決済完了の場合には、図１５(A)に示すように、大きく目立つ青色の「○」印や、乗車停留所名称、降車停留所名称、整理券番号および利用運賃が表示ユニット５３の画面に表示される。背景色は、例えば、水色に設定される。この例では、乗車停留所名称として［乗］ＡＢＣ駅、降車停留所名称として［降］○○公園北、整理券番号として「４」、利用運賃として運賃：２２０円と、感謝を伝える「ありがとうございました」のメッセージが表示ユニット５３の画面に表示される。

また、決済完了の場合には、このような表示ユニット５３による画面表示に加えて、スマートフォン５０のスピーカから、「ピンポーン」や「ご利用ありがとうございました」という内容で発声する合成音声によるメッセージを音響出力可能にステップＳ３２３の処理結果告知処理を構成してもよい。なお、音響出力が制限されるマナーモードやサイレントモードにスマートフォン５０が設定されている場合においても、乗務員（運転士）や当該利用者Ｍに対して聴覚を介した告知を可能にするため、このようなスマートフォン５０の設定に関係なく、強制的に合成音声によるメッセージ等を音響出力するようにステップＳ３２３の処理結果告知処理を構成してもよい。

これに対して、決済結果フラグの情報に基づいて決済未了の場合や、利用運賃情報等が決済サーバ７０に対して送信できていない場合には、決済完了の場合と同様に、図１５(A)に示すように、大きく目立つ青色の「○」印や、乗車停留所名称、降車停留所名称、整理券番号および利用運賃が表示ユニット５３の画面に表示されるものの、背景色が例えば黄色に設定されるとともに、「ありがとうございました」のメッセージに代えて「決済処理ができませんでした」の警告メッセージが表示ユニット５３の画面に表示される。また、スマートフォン５０のスピーカから、「決済処理ができませんでした」という内容で発声する合成音声によるメッセージを音響出力可能にステップＳ３２３の処理結果告知処理を構成してもよい。これにより、事後的に決済処理が行われる旨を利用者Ｍや乗務員（運転士）に伝えることが可能になる。この場合においても、強制的に合成音声によるメッセージ等の出力を可能にステップＳ３２３の処理結果告知処理を構成してもよい。

なお、図１５(B)に示す表示ユニット５３の画面表示は、例えば、不正使用の蓋然性が高い場合に行われるものであり、大きく目立つ赤色の「×」印や、「利用が制限されています」の警告メッセージが表示ユニット５３の画面に表示されたり、スマートフォン５０のスピーカから、「ブッブー」や「利用が制限されています」という内容で発声する合成音声によるメッセージを音響出力したりする。なお、このような場合にも、利用内容を乗務員（運転士）や当該利用者Ｍに明示可能にするため、乗車停留所名称、降車停留所名称、整理券番号および利用運賃が表示ユニット５３の画面に表示される。また、この場合においても、強制的な合成音声によるメッセージ等を可能に構成してもよい。

また、不正使用の履歴データを利用者ごとに管理することによって、例えば、特定の利用者による不正使用の頻度が高い場合には、当該利用者による本運賃収受システム１０の利用を停止（拒否）する措置を採ることが可能になる。このような不正使用の履歴データの管理は、例えば、管理サーバ６０に蓄積された停留所情報等ＩＳとこれに関連付けられた個人情報とにより行うことが可能になる。

また、本実施形態では、二次元コードＤＣには上記(9)の表示更新日時が埋め込まれている。そのため、スマートフォン５０が二次元コードＤＣを取得した時点の当該スマートフォン５０の時計ユニットから得られる時間情報Ｘと、二次元コードＤＣに埋め込まれた(9)の表示更新日時の時間情報Ｙとに基づいて、両時刻の差（時間差）から二次元コードＤＣの不正使用の有無を判定することが可能になる。

例えば、スマートフォン５０の時間情報Ｘの方が二次元コードＤＣに埋め込まれた時間情報Ｙよりも古い（小さい）場合には、スマートフォン５０による撮影時刻の方が二次元コードＤＣの表示更新時刻よりも本来、新しい筈が、逆の時間関係（古いこと）になるので、当該二次元コードＤＣは不正に生成されたり複製されたりした蓋然性が高いと判定することができる。

また、スマートフォン５０の時間情報Ｘの方が二次元コードＤＣに埋め込まれた時間情報Ｙよりも新しい（大きい）場合であっても、両時刻の差（時間差）が所定時間Ｎよりも大きいときには、時間間隔の開きが大きいことから、当該二次元コードＤＣは不正に生成されたり複製されたりした蓋然性が高いと判定することができる。この場合の所定時間Ｎは、例えば、バス９０が停留所間の移動に実際に要する時間またはそれよりも小さい時間に設定されたり、運行ダイヤを管理するシステムが有する停留所間所要時間情報に基づく時間に設定されたり、運行ダイヤと連携した可変時間長に設定されたりする。

［停留所情報等記録処理６００］
次に管理サーバ６０が実行する停留所情報等記録処理６００を説明する。管理サーバ６０は、制御装置としてのサーバコンピュータのハードディスク装置等に停留所情報等記録処理６００を実行可能な停留所情報等記録プログラムが格納されている。サーバコンピュータにおいて実行される停留所情報等記録処理６００では、まずステップＳ６０１により所定の初期化処理が済むと、スマートフォン５０から基地局８０やインターネットＮを介して送信データＴＸａ,ＴＸｂとして送られて来る停留所情報等ＩＳを受信する、ステップＳ６０３の停留所情報等受信処理が行われる。

そして、ステップＳ６０５により停留所情報等ＩＳを受信したか否かを判定して、受信した場合には（Ｓ６０５；Ｙｅｓ）、次のステップＳ６０７に処理を移行し、受信していない場合には（Ｓ６０５；Ｎｏ）、再度、ステップＳ６０３に戻って停留所情報等受信処理を行う。ステップＳ６０７では受信結果情報をスマートフォン５０に向けて送信する処理が行われる。正常に受信できている場合には正常受信情報を送信し、受信した停留所情報等ＩＳの一部が欠落したり破損したりしている場合には正常に受信できていないため、異常受信情報を送信する。

続くステップＳ６０９では、ステップＳ６０３により受信した正常な停留所情報等ＩＳをデータベース装置に格納して蓄積する処理（蓄積処理）が行われる。この処理を終えると、再度、ステップＳ６０３に戻って停留所情報等受信処理を行う。これにより、管理サーバ６０では、受信した停留所情報等ＩＳを、逐次、データベース装置に蓄積することが可能になる。

［運賃決済処理７００］
続いて決済サーバ７０が実行する運賃決済処理７００を説明する。決済サーバ７０は、制御装置としてのサーバコンピュータのハードディスク装置等に運賃決済処理７００を実行可能な運賃決済プログラムが格納されている。サーバコンピュータにおいて実行される運賃決済処理７００では、まずステップＳ７０１により所定の初期化処理を行いそれが済むと、スマートフォン５０から基地局８０やインターネットＮを介して送信データＴＸｃとして送られて来る利用運賃情報と決済情報（利用運賃情報等）を受信する、ステップＳ７０３の利用運賃情報等受信処理が行われる（決済情報が管理サーバ６０にのみ登録されている場合には、決済サーバ７０は決済情報を管理サーバ６０から得る）。

そして、ステップＳ７０５により利用運賃情報等を受信したか否かを判定して、受信した場合には（Ｓ７０５；Ｙｅｓ）、次のステップＳ７０７に処理を移行し、受信していない場合には（Ｓ７０５；Ｎｏ）、再度、ステップＳ７０３に戻って利用運賃情報等受信処理を行う。ステップＳ７０７では受信結果情報をスマートフォン５０に向けて送信する処理が行われる。正常に受信できている場合には正常受信情報を送信し、受信した利用運賃情報等の一部が欠落したり破損したりしている場合には正常に受信できていないため、異常受信情報を送信する。

次のステップＳ７０９では利用運賃情報等に基づく決済処理が行われる。即ち、ステップＳ７０９では、利用者Ｍがバス９０を利用したことによる利用運賃（図１１の例では、運賃２２０円）を電子決済により収受する処理が行われる。つまり、電子決済による運賃収受処理である。利用者Ｍの決済情報としては、例えば、クレジットカードの情報（利用者Ｍの氏名、カード番号、有効期限、セキュリティコード等）である。

続くステップＳ７１１では、ステップＳ７０９による決済処理が完了したか否かを判定する。クレジットカードの情報に誤りや有効期限切れ等の問題がない場合には、決済処理が完了するため（Ｓ７１１；Ｙｅｓ）、ステップＳ７１３により決済結果フラグに決済完了をセットする。これに対して、例えば、カード番号やセキュリティコードに誤りがあったり有効期限が過ぎていたりしてクレジットカードの情報に問題がある場合には、決済処理が完了しないため（Ｓ７１１；Ｎｏ）、ステップＳ７１５により決済結果フラグに決済未了をセットする。

そして、次のステップＳ７１７により決済結果情報、つまり決済結果フラグをスマートフォン５０に向けて送信する処理が行われる。決済処理が完了している場合には決済完了がセットされた決済結果フラグが送信され、決済処理が完了していない場合には決済未了がセットされた決済結果フラグが送信される。この処理を終えると、再度、ステップＳ７０３に戻って利用運賃情報等受信処理を行う。これにより、決済サーバ７０では、受信した利用運賃情報等を、逐次、電子決済することが可能になる。

以上説明したように本実施形態の運賃収受システム１０では、スマートフォン５０は、利用者Ｍの乗車時に乗車表示端末２０から出力された二次元コードＤＣａを取得し、利用者Ｍの降車時に降車表示端末３０から出力された二次元コードＤＣｄを取得し、二次元コードＤＣａをデコードした停留所情報等ＩＳａと二次元コードＤＣｄをデコードした停留所情報等ＩＳｄとに基づいて得られた利用運賃に関する利用運賃情報を決済サーバ７０に送信する。そして、決済サーバ７０は、運賃決済処理７００により、スマートフォン５０から送信された利用運賃情報に基づいて電子決済に関する情報処理を行う。ホスト機器４０は、典型的には、例えば、バス９０内の既存設備として存在する運賃箱、運賃表示器や車内放送装置等の車載機器を構成する制御装置が用いられる。また、決済サーバ７０も既存設備のものが使用できる。スマートフォン５０は当該バス９０の利用者Ｍが所持する。

このため、運賃収受システム１０を構成するうえで、新規に必要になるものは乗車表示端末２０と降車表示端末３０である。また、利用運賃に関する利用運賃情報を得る情報処理や、決済サーバ７０との通信処理は、利用者Ｍが所持するスマートフォン５０が行う。これにより、バス９０に搭載されたホスト機器４０、乗車表示端末２０や降車表示端末３０は、利用運賃情報を得る情報処理を行ったり、決済サーバ７０との通信処理を行ったりする必要がないので、これらのホスト機器４０等に演算処理能力が高いマイクロコンピュータや記憶容量が大きなメモリ等を設ける必要もない。また通信コストの増加もない。したがって、設備コストの増大を抑制しつつもデジタルチケットによる決済を可能にすることができる。

また、本実施形態の運賃収受システム１０では、乗車表示端末２０が出力する二次元コードＤＣや降車表示端末３０が出力する二次元コードＤＣは、停留所ごとに異なるばかりでなく、それぞれ時間の経過とともに変化するように二次元コードＤＣが出力された時刻の時間情報が少なくとも含まれている（上記(9)の表示更新日時の情報）。そのため、例えば、車両、系統、停留所が同じであっても、日時が違えば異なる二次元コードＤＣが生成されるため、二次元コードＤＣを不正に生成したり複製したりすることを極めて困難にしている。また、この表示更新日時の情報とこれらの二次元コードＤＣの取得時の時間情報（スマートフォン５０の時計機能によるもの）とを比較することで、二次元コードＤＣの不正取得行為の有無を判定することが可能になる。

例えば、スマートフォン５０のカメラ５５で撮影して取得した二次元コードＤＣの画像データが乗車表示端末２０や降車表示端末３０から乗車時や降車時以前の過去に出力されたものであるか否かを判定することにより、取得した二次元コードＤＣの画像データがその乗車日または降車日以前のものであった場合には、当該利用者Ｍが予め準備した古い二次元コードＤＣの画像データを意図的にスマートフォン５０で取得した蓋然性が高いことになるため、このような不正取得行為の有無を判定することが可能になる。

また、本実施形態の運賃収受システム１０では、スマートフォン５０は、二次元コードＤＣから得られた停留所情報等ＩＳを、車両外に設けられる管理サーバ６０や決済サーバ７０に送信するため、これらのサーバ６０，７０では、利用者Ｍがどこからどこまでバス９０を利用したかの情報（いわゆるＯＤデータ）を蓄積することが可能になる。停留所情報等ＩＳと利用者Ｍの関連付けは、例えば、スマートフォン５０や管理サーバ６０に登録されている利用者Ｍの個人情報（利用者Ｍの氏名、生年月日、性別、住所、電話番号、職業等）とスマートフォン５０の所持者が利用者Ｍであることから可能である。これにより、バス９０を利用した場合の出地と着地の組み合わせごとの利用者数を把握することが可能になるので、例えば、運輸効率の改善や関連サービスの提供等に用いることができる利用価値の高いＯＤデータの収集が可能になる。

また、本実施形態の運賃収受システム１０では、スマートフォン５０は、決済サーバ７０への利用運賃情報の送信が完了しなかった場合や電子決済に関する情報処理を行うことができなかった場合には、スマートフォン５０の画面の背景色を、例えば黄色にしたり、「決済処理ができませんでした」の警告メッセージが画面に表示されたりする。また、スマートフォン５０のスピーカから、「決済処理ができませんでした」という内容で発声する合成音声によるメッセージを音響出力可能にステップＳ３２３の処理結果告知処理を構成してもよい。これにより、事後的に決済処理が行われる旨を利用者Ｍや乗務員（運転士）に伝えることが可能になり、乗務員は、当該利用者Ｍの運賃収受が済んでいないことを知ることができるので、当該利用者Ｍに対して事後精算処理等が必要であることを説明する等の適切な乗客対応が可能になる。

これに対して、管理サーバ６０への利用運賃情報の送信が完了した場合または電子決済に関する情報処理を行うことができた場合には、大きく目立つ青色の「○」印や「ありがとうございました」のメッセージがスマートフォン５０の画面に表示される（図１５(A)）。また、スマートフォン５０のスピーカから、「ピンポーン」や「ご利用ありがとうございました」という内容で発声する合成音声によるメッセージを音響出力可能にステップＳ３２３の処理結果告知処理を構成してもよい。これにより、乗務員は、当該利用者Ｍの利用運賃収受が済んだことを知ることができるので、当該利用者Ｍには事後精算処理等の説明が不要であることを把握することが可能になる。

また、本実施形態の運賃収受システム１０では、スマートフォン５０は、利用者Ｍの降車時において、無線通信回線８５を介した情報通信を行わないようにスマートフォン５０が設定されている場合（例えば「機内モード」に設定されている場合）には、例えば、図１３(B)に示すような機内モードの解除を促すメッセージ「機内モードを解除してくださ」（例えば、背景色は赤色、文字色は白色または黄色）がスマートフォン５０の表示ユニット５３の画面に表示される。

これにより、利用者Ｍに対して色彩的にインパクトを与え得るメッセージの表示が可能になる。また乗務員も「機内モード」に設定されているため、当該スマートフォン５０が決済サーバ７０に利用運賃情報を送信したり管理サーバ６０に停留所情報等ＩＳを送信したりすることができない状態であることを把握でき、例えば、当該利用者Ｍに対して機内モードを解除するように促すことが可能になる。したがって、機内モードに起因したスマートフォン５０による決済サーバ７０への利用運賃情報の送信未了を防ぐことができる。

また、本実施形態の運賃収受システム１０では、乗車表示端末２０と降車表示端末３０をハードウェアおよびソフトウェアのいずれについても同じ構成にしたため、これらを異なるハードウェア構成やソフトウェア構成にした場合に比べ、開発コスト、製造コストやメンテナンスコストを抑制することが可能になる。また量産に伴う低コスト化も期待できるため、さらに製品コストが下がり設備の導入コストをより低減することが可能になる。

なお、［先行技術文献］の欄で述べた特許文献１（特開２０１８－１４７２７０号公報）においては、タイプαの自動改札機のほかに、タイプβの自動改札機が開示されている（特許文献１；段落００２０等）。このタイプβの自動改札機はＱＲコードを表示させる構成を有するが、鉄道駅の自動改札機は一般的には駅構内に固定されている。

このため、タイプβの自動改札機を利用する場合のスマートフォンや携帯電話機は、比較的安定した通信状態が得やすいのに対して、路線バスを利用する場合のスマートフォンや携帯電話機は、バスの走行に伴い移動したり携帯基地局等のインフラが十分に整っていない地域の停留所に移動したりすることから、通信状態が不安定な環境で使用される場合がある。このような場合には不安定な通信状態に起因して決済サーバが決済不能に陥ることもあるため、本発明は上記の構成によりこれを解決している。

なお、上述した実施形態では、乗車表示端末２０や降車表示端末３０に表示ユニット２３，３３を設けて二次元コードＤＣ等のコードを表示可能に構成し、スマートフォン５０のカメラ５５により二次元コードＤＣ等の画像を撮影することで当該二次元コードＤＣ等の取り込みを可能にした。しかし、本発明の適用はこれに限られることはなく、例えば、表示ユニット２３，３３に代えて（または表示ユニット２３，３３に加えて）、乗車表示端末２０や降車表示端末３０にＲＦＩＤ（Radio Frequency IDentification）等の近距離無線通信（ＮＦＣ；Near field communication）が可能な無線ユニットとそのアンテナを設けてもよい。

これにより、このような乗車表示端末２０や降車表示端末３０から近距離無線通信で出力される乗車停留所情報や降車停留所情報を、ＲＦＩＤ等の近距離無線通信機能を備えたスマートフォンが取得することが可能になるので、スマートフォン５０のカメラ５５等で二次元コードＤＣを撮影して取得する場合に比べて、素早く乗車停留所情報や降車停留所情報を取得することが可能になる。したがって、バス９０の乗車口９１や降車口９３で利用者Ｍ（乗客）の滞りが起こり難くなるため、乗降客が多い時間帯や停留所であっても、バス９０の乗車や降車がスムーズになる。

また、上述した実施形態では、データカセットのメモリに格納された運賃三角表データを用いる場合を例示して説明したが、本発明の適用はこれに限られることはなく、例えば、運賃表示器や車内放送装置等の車載機器から有線通信回線１５を介して送られてくる運賃三角表データを用いてもよい。

さらに、上述した実施形態では、スマートフォン５０が二次元コードＤＣを取得した時点の時間情報Ｘを当該スマートフォン５０の時計ユニットから得る場合を例示して説明したが、本発明の適用はこれに限られることはなく、例えば、乗車表示端末２０や降車表示端末３０から当該スマートフォン５０が時間情報Ｘを得るように構成してもよい。

なお、上述した実施形態では、二次元コードとして、ＱＲコードを使用する場合を例示して説明したが、本発明の適用はこれに限られることはなく、例えば、マトリクス型の二次元コードとして、DataMatrix、VeriCode、AztecやMaxCodeを用いてもよい。また、スタック型の二次元コードとして、PDF471やCODE49を用いてもよい。また、コード化するデータ量が少ない場合には、バーコード等の一次元コードを用いてもよい。

また、上述した実施形態では、乗車表示端末２０から出力される二次元コードＤＣと降車表示端末３０から出力される二次元コードＤＣとを同じデータ内容のコード（同じコード）にしたが、両者異なるデータ内容のコード（違うコード）を出力するように構成してもよい。これにより、不正に二次元コードＤＣを生成した場合には発覚する可能性が高まるため、二次元コードＤＣの不正な生成や複製を抑制することが可能になる。

また、上述した実施形態では、乗車表示端末２０と降車表示端末３０とを同じハードウェアおよびソフトウェアで構成したが、両者をそれぞれ異なるようにハードウェアおよびソフトウェアを構成してもよい。これにより、様々な顧客ニースに対応することが可能になる。

また、二次元コードＤＣを表示可能な表示装置を有するバス用の車載設備機器を乗車表示端末２０や降車表示端末３０に代えて用いてもよい。これにより、乗車表示端末２０や降車表示端末３０を別途設ける必要がなくなるため、さらに設備の導入コストを低減することが可能になる。

また、上述した実施形態では、本発明の運賃収受システムをバス９０（路線バス）の運賃収受に適用する場合を例示して説明したが、本発明の適用はこれに限られることはなく、乗合車両の利用運賃を収受するものであれば、例えば、路面電車、トロリーバスやワンマン運行方式の鉄道等の乗合車両の利用運賃を収受するものにも適用することができ、これらの場合においても路線バスに適用したときと同様の作用・効果を得ることができる。

以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、上述した具体例を様々に変形または変更したものが含まれる。また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時の請求項に記載の組合せに限定されるものではない。さらに、本明細書または図面に例示した技術は、複数の目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つ。なお、[符号の説明]の欄における括弧内の記載は、上述した各実施形態で用いた用語と、特許請求の範囲に記載の用語との対応関係を明示し得るものである。

１０…運賃収受システム
２０…乗車表示端末（乗車情報提供装置）
３０…降車表示端末（降車情報提供装置）
４０…ホスト機器（制御装置）
５０…スマートフォン（携帯情報端末装置）
５１…制御ユニット
５２…無線ユニット
５３…表示ユニット
５５…カメラ
６０…管理サーバ
７０…決済サーバ（決済サーバ装置）
８０…基地局
８５…無線通信回線
９０…路線バス（乗合車両）
９１…乗車口
９３…降車口
１００…停留所情報等送出処理
２００…コード出力処理
３００…運賃精算処理
４００…コード取得処理
５００…無線送信処理
６００…停留所情報等記録処理
７００…運賃決済処理
ＢＳ，ＢＳａ，ＢＳｂ，ＢＳｄ…停留所
ＤＣ，ＤＣａ，ＤＣｂ，ＤＣｄ…二次元コード（乗車停留所情報、降車停留所情報）
ＩＳ，ＩＳａ，ＩＳｂ，ＩＳｄ…停留所情報等（乗車停留所情報、降車停留所情報）
Ｍ…利用者
Ｎ…インターネット
ＴＸａ，ＴＸｂ，ＴＸｃ…送信データ
ＲＸａ，ＲＸｂ…受信結果情報

Claims (5)

1. 乗合車両の利用者から当該車両の利用運賃を収受する運賃収受システムであって、
   前記車両内の乗車口付近に設けられる乗車情報提供装置と、
   前記車両内の降車口付近に設けられる降車情報提供装置と、
   前記車両が停留所に停車した前記停留所に対応する情報であってそれぞれの停留所ごとに異なる停留所情報を停車するごとに前記乗車情報提供装置および前記降車情報提供装置に出力させる制御装置と、
   前記車両外に設けられて前記利用運賃を収受する電子決済に関する情報処理を行う決済サーバ装置と、
   前記利用者が所持して前記乗車情報提供装置および前記降車情報提供装置から出力される前記停留所情報を取得可能かつ前記決済サーバ装置に対し無線通信回線を介して情報通信可能な携帯情報端末装置と、を含み、
   前記携帯情報端末装置は、
   前記利用者の乗車時に前記乗車情報提供装置から出力された乗車時の前記停留所情報（以下、請求項１～５において「乗車停留所情報」という）を取得し、
   前記利用者の降車時に前記降車情報提供装置から出力された降車時の前記停留所情報（以下、請求項１～５において「降車停留所情報」という）を取得し、
   前記乗車停留所情報に含まれる前記乗車時の停留所に対応した整理券番号と前記降車停留所情報に含まれる前記整理券番号に対応した運賃データとに基づいて得られた前記利用運賃に関する利用運賃情報を前記決済サーバ装置に送信し、
   前記決済サーバ装置は、前記携帯情報端末装置から送信された前記利用運賃情報に基づいて前記電子決済に関する情報処理を行うことを特徴とする運賃収受システム。
2. 前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、それぞれ時間の経過とともに変化し、かつ、出力時刻の時間情報が少なくとも含まれていることを特徴とする請求項１に記載の運賃収受システム。
3. 前記乗車情報提供装置から出力される前記乗車停留所情報および前記降車情報提供装置から出力される前記降車停留所情報は、暗号化されており、
   前記携帯情報端末装置は、暗号化された前記乗車停留所情報および前記降車停留所情報を所定の暗号鍵で復号して前記整理券番号と前記運賃データを取得することを特徴とする請求項１または２に記載の運賃収受システム。
4. 前記携帯情報端末装置は、
   前記降車停留所情報および前記乗車停留所情報に基づいて、前記決済サーバ装置への前記利用運賃情報の送信が完了しなかった場合または前記電子決済に関する情報処理を行うことができなかった場合には、所定の未了情報を前記車両の乗務員に告知可能に出力し、
   または、前記決済サーバ装置への前記利用運賃情報の送信が完了した場合または前記電子決済に関する情報処理を行うことができた場合には、所定の完了情報を前記車両の乗務員に告知可能に出力する、
   ことを特徴とする請求項１～３のいずれか一項に記載の運賃収受システム。
5. 前記携帯情報端末装置は、前記利用者の降車時において、前記無線通信回線を介した情報通信を行わないように当該携帯情報端末装置が設定されている場合には、所定の通信不能情報を前記車両の乗務員に告知可能に出力することを特徴とする請求項１～４のいずれか一項に記載の運賃収受システム。

Images