以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。
実施の形態は、バスなどの公共交通機関でのキャッシュレス決済(例えば、NFC決済)に関し、現在、多区間運賃を行っている公共交通機関で用いられている「整理券」の運用を残しながら、決済のキャッシュレス化を図る。
交通事業者が本実施の形態に係るスキームを採用するメリットとしては、下記が考えられる。
1.圧倒的に低コストでキャッシュレスを実現することができる。例えば、現行の交通系ICカードを導入する場合と比較して圧倒的に低コストでバス等に設置する設備を導入することができる。
2.乗車停留場、降車停留所を判断するために、従来は「GPS等による停留所位置認識」や「音声合成システム」などがあったが、本スキームではすでに備え付けられている整理券運用と連携した方法を取ることで、他の方法と比較して、技術的ハードルが圧倒的に低くなる。
3.乗務員の負担がほとんど発生しない。
本開示は、整理券を用いた区間制運賃の後払い方式を採用する交通機関を対象とする。
「整理券」は、乗車地を証明するために発行される切符であり、乗車整理券・乗車票・乗車駅証明書とも呼ばれる。
「区間制運賃」は、路線を区間ごとに区切って、区間をまたぐごとに運賃が加算されていく運賃制度である。
「後払い方式」は、運賃を降車時に支払う支払い方式である。
「交通機関」は、バスや電車などの公共交通機関を含む。
本実施の形態では特に、整理券を用いた区間制運賃の後払い方式を採用するバスを対象とするが、他の実施の形態では整理券を用いた区間制運賃の後払い方式を採用する他の交通機関に本実施の形態の技術的思想を適用してもよい。
図1は、本実施の形態に係る利用シナリオの説明図である。バスの乗客2は自己の携帯端末(以下、乗客端末4と称す)に乗客用の決済アプリケーションプログラム(以下、乗客アプリと称す)をダウンロードしてインストールする。乗客2は、乗客アプリを起動して初期の利用登録をする。この利用登録では、乗客2の個人情報の登録や決済口座の指定が行われる。乗客2は、よく使うバス停や路線があればお気に入りのバス停・路線として登録する。
乗客2はバスに乗り込むとまず、バスの乗車口に設けられた整理券発券機6から整理券8を取得する。乗客2は着席して乗客アプリを開き、乗降地すなわち乗車バス停および降車バス停を選択して登録する。当該登録は乗車の前に行われてもよい。
乗客2は、降車の際、整理券8をバスの降車口(運転席付近)に設けられた整理券箱10に投入すると共に、乗客端末4を整理券箱10の近くに設けられたR/W(リーダライタ)12に近づける。するとNFC(Near Field Communication)を介して乗客端末4からR/W12へ、決済用情報と共に乗客2が指定した乗降地を示す情報(以下、乗降地情報と称す)が送信される。乗客2はその場で、または降車後に、乗客端末4において運賃の決済結果を確認することができる。乗降地情報は、乗車地すなわち乗車バス停のIDおよび/または名称と、降車地すなわち降車バス停のIDおよび/または名称と、を含む。
バスの乗務員14は自己またはバス運行会社の携帯端末(以下、乗務員端末16と称す)に乗務員用の決済アプリケーションプログラム(以下、乗務員アプリと称す)をダウンロードしてインストールする。乗務員14は乗務員アプリを起動してログインし、自己が乗務または運転するバスの路線・系統を選択して登録する。
乗客2が降車する際、乗務員端末16は、乗客2の乗客端末4からNFCを介して取得した決済用情報を基に、図1では不図示の決済サーバと通信することで運賃を決済する。乗務員端末16は、乗客2の乗客端末4からNFCを介して取得した乗降地情報を基に、乗客2が登録(自己申告)した乗車バス停に対応する整理券番号と、降車バス停と、運賃と、をディスプレイに表示させる。併せて乗務員端末16はそれらの情報を音声で出力する。乗務員14は、乗務員端末16のディスプレイに表示される整理券番号または音声で出力される整理券番号と、整理券箱10に投入された整理券8の番号と、を照合する。乗務員14は、それらが一致すれば何もせず、相違すれば支払いを一端取り消して、正しい運賃を入力し、乗客2に再度、乗客端末4をR/W12に近づけるよう促す。
乗務員14は、乗務が終了すると、乗務員端末16において乗務員アプリからログオフする。
図2は、本実施の形態に係る決済システム1の構成を示す模式図である。決済システム1は、決済サーバ18と、乗務員端末16と、乗客端末4と、を備える。決済サーバ18、乗務員端末16、乗客端末4はそれぞれ移動体通信ネットワークやインターネットなどのネットワーク20に接続され、ネットワーク20を介して互いに通信可能に構成される。図2に示される構成は例示であり、乗務員端末16、乗客端末4の数に制限はない。決済サーバ18は複数のサーバを含んでもよい。
決済システム1は、乗客2とバス運行会社との間のキャッシュレス決済を可能とするシステムである。決済サーバ18はキャッシュレス決済のサービスを提供する事業体により管理される。乗客2、バス運行会社はいずれも予めサービスに利用登録を行い、端末および口座の情報をサービスに提供し、ID・パスワードの付与を受ける。図1に示す通り、乗客2がバスから降車する際、乗客端末4から乗務員端末16に直接(すなわち、ネットワーク20を介さず)、乗客2を特定する利用者IDを含む決済用情報がNFCを用いて送信される。乗務員端末16は取得した利用者IDに乗降地・路線から算出された運賃を加えて決済要求を生成し、ネットワーク20を介して決済サーバ18に送信する。決済サーバ18は、決済要求を受信すると、当該決済を実行する。この決済処理は即時に行われてもよいし、決済データを蓄えて後日まとめて行ってもよい。乗務員端末16および乗客端末4は、決済の結果を決済サーバ18に問い合わせすることが出来る。
決済サーバ18における決済の処理は、乗客2の決済用口座からバス運行会社の決済用口座へ運賃分の金額を電子的に移動するための処理であり、公知の電子決済技術を用いて実現されてもよい。
なお、本実施の形態では乗務員端末16と乗客端末4との間の非接触の直接通信としてNFCを想定するが、他の実施の形態ではNFCに代えて、例えば、Bluetooth(登録商標)、WiFi、IR(Infrared、赤外線)、画像(例えば、バーコード、QRコード(登録商標)など)などの他のタイプの非接触の直接通信を用いて、乗務員端末16と乗客端末4との間で情報をやりとりしてもよい。本実施の形態ではQRコード(登録商標)を用いた情報の伝達についても触れる。以下、本明細書に記載の「QRコード」を「QRコード(登録商標)」に読み替えるものとする。
乗客端末4および乗務員端末16はいずれも携帯端末(例えば、スマートフォン、タブレット端末、ラップトップPCなど)であり、いずれの携帯端末もアンテナ間の通信により情報を伝達する方式および撮像により情報を伝達する方式の両方に対応可能に構成される。例えば乗客端末4は、利用者IDおよび乗降地情報をNFCにより他の端末に送信する機能と、利用者IDおよび乗降地情報を符号化された形で示すQRコードをディスプレイに表示させる機能と、を有する。乗務員端末16は、利用者IDおよび乗降地情報をNFCにより他の端末から受信する機能と、他の端末に表示されたQRコードをカメラなどの撮像手段により読み取る機能と、を有する。NFCによる通信は公知の技術を用いて実現されてもよい。QRコードによる情報の伝達は公知の技術を用いて実現されてもよい。
乗客端末4のユーザである乗客2は、ダウンロードサイトからネットワーク20を介して乗客アプリを乗客端末4にダウンロードし、インストールする。あるいはまた、乗客アプリは乗客端末4にプリインストールされていてもよい。乗客アプリはキャッシュレス決済のサービスの事業体またはバス運行会社により提供される。乗客アプリが乗客端末4により実行されることにより、乗客端末4は各種機能を実現する。乗務員端末16についても同様に、バスの乗務員14が乗務員アプリを乗務員端末16にダウンロードし、インストールしてもよいし、乗務員アプリはプリインストールされていてもよい。
図3は、図1の乗務員端末16のハードウエア構成図である。乗客端末4は図3に示される乗務員端末16のハードウエア構成と同様のハードウエア構成を有する。乗務員端末16は、メモリ22と、プロセッサ24と、ネットワークインタフェース26と、ディスプレイ28と、入力インタフェース30と、NFCインタフェース32と、スピーカ34と、カメラ38と、を備える。これらの要素はそれぞれバス36に接続され、バス36を介して互いに通信する。
メモリ22は、データやプログラムを記憶するための記憶領域である。データやプログラムは、メモリ22に恒久的に記憶されてもよいし、一時的に記憶されてもよい。プロセッサ24は、メモリ22に記憶されている乗務員アプリなどのプログラムを実行することにより、乗務員端末16の各種機能を実現する。ネットワークインタフェース26は、乗務員端末16の外部との間でデータの送受信を行うためのインタフェースである。ネットワークインタフェース26はネットワーク20と接続され、ネットワーク20を介して決済サーバ18とデータをやりとりする。NFCインタフェース32は、NFCのためのインタフェースであり、NFCを用いて乗客端末4とデータをやりとりする。ネットワークインタフェース26およびNFCインタフェース32はそれぞれ専用の半導体チップであってもよい。ディスプレイ28は、各種情報を表示するためのデバイスである。入力インタフェース30は、乗務員14からの入力を受け付けるためのデバイスであり、例えばタッチパネルや物理的なボタンを含む。スピーカ34は音声を出力する。カメラ38はレンズおよび撮像素子を含む。カメラ38は特に乗客端末4のディスプレイに表示されるQRコードを撮像することで読み込む。
図4は、図1の乗務員端末16の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
乗務員端末16は、バス情報受付部40と、乗降地取得部42と、出力情報生成部44と、出力制御部46と、運賃決定部48と、決済実行部50と、決済取消部54と、手動入力受付部56と、バス情報保持部58と、運賃情報保持部60と、整理券情報保持部62と、を備える。
図5は、図4のバス情報保持部58の一例を示すデータ構造図である。バス情報保持部58は、乗務員14が乗務しているまたは乗務しようとしているバスに関する情報を保持する。バス情報保持部58は、バスを特定するバスIDと、当該バスに乗務する乗務員14の名前と、当該バスの路線の経路番号と、を対応付けて保持する。以下ではバスの「路線」と「系統」と「経路」とを同じ意味で用いる。
図6は、図4の運賃情報保持部60の一例を示すデータ構造図である。運賃情報保持部60は、バス情報保持部58に登録されているバスの路線(経路番号)に対応する運賃表のデータを保持する。乗務員端末16は、各路線に対応する運賃表のデータを図6のデータ構造と同様のデータ構造で保持する。運賃情報保持部60は、乗車バス停を特定する乗車バス停IDを縦(行)、降車バス停を特定する降車バス停IDを横(列)とするマトリクス形式で表現され、各セルは対応する乗車バス停から対応する降車バス停まで乗車したときの運賃を示している。例えば、図6の符号64で示されるセルは、乗車バス停ID「AG001」のバス停で乗車し、降車バス停ID「HJ024」のバス停で降車したときの運賃が「340円」であることを示す。
図7は、図4の整理券情報保持部62の一例を示すデータ構造図である。整理券情報保持部62は全路線の各バス停に対応する整理券番号を保持する。整理券情報保持部62は、路線を特定する経路番号と、当該路線におけるバス停を特定するバス停IDと、当該バス停のバス停名と、当該路線における当該バス停の整理券番号と、を対応付けて保持する。
図4に戻り、バス情報受付部40は、乗務員14から予め乗務対象のバスの情報を受け付ける。バス情報受付部40は、受け付けた情報をバス情報保持部58に登録する。バス情報受付部40は特に、乗務員14から予めバスの路線の指定を受け付けて、バス情報保持部58に登録する。
乗降地取得部42は、乗客2がバスから降車する際、NFCまたはQRコード撮像を介して乗客端末4から、当該乗客2の利用者IDと当該乗客2が指定した乗降地を示す乗降地情報とを取得する。
出力情報生成部44は、乗降地取得部42によって取得された乗降地情報に基づいて、乗客2によって提示されるべき整理券8を識別するための情報である整理券番号と、乗客2が指定した降車バス停を示す降車地情報と、を含む出力情報を生成する。出力情報生成部44は、バス情報保持部58を参照してバスの路線を特定する。出力情報生成部44は、乗降地取得部42によって取得された乗降地情報に含まれる乗車バス停名または乗車バス停IDを特定する。出力情報生成部44は、バス情報保持部58と整理券情報保持部62とを参照し、特定された路線の特定された乗車バス停名または乗車バス停IDに対応する整理券番号を特定する。出力情報生成部44は、特定された整理券番号と、乗降地取得部42によって取得された乗降地情報に含まれる降車バス停名と、後述の運賃決定部48によって決定された運賃と、を合わせて出力情報とする。なお、バス情報保持部58のバス路線に、乗降地取得部42に保持する乗車バス停IDまたは降車バス停IDのいずれかが存在しない場合は、乗務員端末16のディスプレイに「乗車バス停不一致」または「降車バス停不一致」または「乗車バス停、降車バス停不一致」のエラー表示を行い、同時に乗務員端末16が警告音を発して、乗客2および乗務員14に対して決済不能である旨通知し、処理を中断する。
出力制御部46は、出力情報生成部44によって生成された出力情報を、乗務員端末16の出力手段に出力させる。出力手段はディスプレイ28またはスピーカ34もしくはその両方である。出力情報をディスプレイ28に表示させる例は後述する。出力情報をスピーカ34から音声として出力する場合、公知の音声合成技術が用いられてもよい。
運賃決定部48は、乗降地取得部42によって取得された乗降地情報と乗務員14によって予め指定された路線とに基づいて、乗客2が払うべき運賃を決定する。運賃決定部48は、バス情報保持部58を参照してバスの路線を特定する。運賃決定部48は、乗降地情報に含まれる乗車バス停IDおよび降車バス停IDを特定する。運賃決定部48は、特定された路線に対応する運賃表のデータ(図6参照)を参照し、特定された乗車バス停IDおよび降車バス停IDに対応するセルに保持される運賃を、乗客2が払うべき運賃として決定する。
運賃決定部48において、乗車バス停が同じであり降車バス停が同じであっても、路線が異なる場合、異なる運賃が決定されることがある。図8は、同一乗降地でも路線が異なると運賃が異なりうることを説明するための図である。図8(a)に示されるように、乗車バス停「A」から降車バス停「B」への路線として路線「C07」と路線「C34」とがあるとする。路線「C07」は途中でバス停「C」を経由するがバス停「D」は経由せず、路線「C34」は途中でバス停「D」を経由するがバス停「C」は経由しない。図8(b)は路線「C07」の整理券番号および運賃を示し、図8(c)は路線「C34」の整理券番号および運賃を示す。このように、同じ乗車バス停「A」および同じ降車バス停「B」に対して、路線「C07」では運賃が「470円」、路線「C34」では運賃が「490円」となり、路線が異なれば運賃も異なる。運賃決定部48は、乗客2の自己申告に係る乗車バス停および降車バス停に加えて、バスの路線を考慮することで、図8のような状況でも正しい運賃を決定することができる。
図4に戻り、決済実行部50は、運賃決定部48によって決定された運賃を決済するための処理を行う。決済実行部50は、乗降地取得部42によって取得された利用者IDと、運賃決定部48によって決定された運賃と、決済要求を特定する決済要求IDと、を含む決済要求を生成し、ネットワーク20を介して決済サーバ18に送信する。
手動入力受付部56は、乗客2が整理券箱10に投入した整理券8の番号と乗務員端末16から出力された整理券番号とが相違すると判断した乗務員14からの正当金額の入力を受け付ける。乗務員14は、乗務員端末16から出力された降車地情報と、実際の降車バス停とが相違すると判断した場合にも正当金額の入力を行う。
手動入力受付部56は、乗客2が払うべき運賃の指定を乗務員14から受け付ける。決済実行部50は、乗客端末4とNFCまたはQRコード撮像を介して通信することにより、手動入力受付部56によって受け付けられた運賃を決済するための処理を行う。同時に決済取消部54は、当該乗客端末4に紐づけられた乗客IDによる決済履歴についてネットワーク20を介して決済サーバ18に問い合わせ、現在時刻より過去一定時間の範囲(例:2分以内)に該当する履歴がある場合には、これの取消要求を決済サーバ18に対して行う。
決済取消部54による決済履歴照会がネットワーク20の不通により行えない場合は、決済取消部54は一連の動作(決済履歴照会→取消要求)について、ネットワーク20の回復を待って行う。決済実行部50についても同様の動作をおこなう。
図9は、図1の乗客端末4の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
乗客端末4は、利用登録受付部65と、お気に入り登録受付部66と、乗降地指定受付部68と、運賃決定部70と、乗降地情報送信部72と、決済結果取得部74と、表示制御部76と、お気に入り情報保持部78と、乗降地情報保持部80と、図6の運賃情報保持部60と同様のデータ構造を有する運賃情報保持部82と、を備える。
図10は、図9のお気に入り情報保持部78の一例を示すデータ構造図である。お気に入り情報保持部78は、乗客2がよく使う乗車バス停や降車バス停や路線やそれらの組み合わせをお気に入りとして保持する。乗車バス停、降車バス停および路線を全て指定することで、どのバスにどのバス停からどのバス停まで乗るかが指定され、運賃が一意に定まる。お気に入り情報保持部78は、お気に入りデータを特定する通し番号と、お気に入りに指定された路線を特定する経路番号と、お気に入りに指定された乗車バス停の名称と、お気に入りに指定された降車バス停の名称と、を対応付けて保持する。バス停は名称の代わりにまたはそれに加えてIDで特定されてもよい。
図11は、図9の乗降地情報保持部80の一例を示すデータ構造図である。乗降地情報保持部80は、乗客2の自己申告に係る乗車バス停、降車バス停および路線を保持する。乗降地情報保持部80は、乗客2の乗客IDと、当該乗客2が登録した路線の経路番号と、当該乗客2が登録した乗車バス停の名称と、当該乗客2が登録した降車バス停の名称と、を対応付けて保持する。バス停は名称の代わりにまたはそれに加えてIDで特定されてもよい。
図9に戻り、お気に入り登録受付部66は、予め乗客2から、乗車バス停、降車バス停や路線などの組み合わせのお気に入りへの登録を受け付ける。お気に入り登録受付部66は、乗客2がお気に入りに指定した内容をお気に入り情報保持部78に登録する。
乗降地指定受付部68は、乗客2がバスに乗る前または乗車中に、乗客2から、乗車バス停および降車バス停の指定を受け付ける。乗降地指定受付部68は、お気に入り情報保持部78を参照して乗客2のお気に入りの乗車バス停、降車バス停や路線を取得し、取得したお気に入り情報からの選択を乗客2に促す画面(後述)を乗客端末4のディスプレイに表示させる。乗降地指定受付部68は、乗客2によるお気に入り情報からの選択を受け付ける。乗降地指定受付部68はまた、お気に入り情報からの選択ではない、乗客2による乗車バス停、降車バス停および路線の直接的な指定も受け付ける。乗降地指定受付部68は、受け付けた情報を乗降地情報保持部80に登録する。
運賃決定部70は、乗降地指定受付部68で指定された乗車バス停、降車バス停および路線に基づいて、運賃情報保持部82を参照することで、乗客2が払うべき運賃を決定する。運賃決定部70における運賃の決定は、運賃決定部48における運賃の決定に準じる。
乗降地情報送信部72は、乗客2が降車する際、NFCまたはQRコード撮像を介して乗務員端末16に、乗客2が指定した乗車バス停および降車バス停を示す乗降地情報と乗客IDとを送信する。
決済結果取得部74は、乗降地情報送信部72によって送信された乗降地情報に基づいて乗務員端末16において決定された運賃の決済結果を、ネットワーク20を介して決済サーバ18から取得する。
表示制御部76は、乗客端末4のディスプレイに各種画面を表示させる。例えば表示制御部76は、決済結果取得部74によって取得された決済結果を示す画面(後述)を乗客端末4のディスプレイに表示させる。また、表示制御部76は、運賃決定部70によって決定された運賃を、乗客2が登録した乗車バス停および降車バス停と共に乗客端末4のディスプレイに表示させる。
以上の構成による決済システム1の動作を説明する。
図12は、決済システム1における処理の流れを示すチャートである。
(乗車前)
乗客2は乗客端末4に乗客アプリをダウンロードしてインストールする(S202)。乗客2は乗客アプリを起動して利用登録する(S204)。乗客端末4は乗客2が入力した情報を決済サーバ18に送信し、決済サーバ18は受信した情報を登録する。乗客2は乗客アプリにお気に入りのバス停等を登録する(S206)。
乗務員14は乗務員端末16に乗務員アプリをダウンロードしてインストールする(S208)。乗務員14はバスへの乗務前に乗務員アプリにログインする(S210)。この際、乗務員14は乗務員端末16に乗務員IDおよびパスワードを入力し、認証する。ログインが成功すると、乗務員14は、これから乗務するバスの路線を乗務員アプリに登録する(S212)。
(乗車時)
乗客2は乗車の際に整理券8を取得する(S214)。乗客2は着席すると乗客端末4で乗客アプリを開いて、自分が乗っているバスの路線および乗車バス停、降車バス停を指定する(S216)。乗客端末4は、ステップS216で指定された乗降地情報および乗客2の利用者IDを、NFCの場合はNFCインタフェース32(NFCチップ)に書き込むことでNFC送信可能な状態とし、QRコードの場合はそれらの情報を符号化することでQRコードを生成する(S218)。
(降車時)
乗客2は降車の際に、整理券8を整理券箱10に投入する(S220)と共に、NFCの場合は乗客端末4をバスのR/W12に近づけるか、QRコードの場合は乗客端末4のディスプレイにQRコードを表示させる。NFCの場合はR/W12がNFCを介して、乗客端末4のNFCチップに書き込まれていた乗降地情報および利用者IDを乗務員端末16に送信する。QRコードの場合は乗務員端末16がカメラを用いて乗客端末4のディスプレイに表示されたQRコードを読み取り、復号することで乗降地情報および利用者IDを取得する(S224)。なお、乗務員端末16のカメラを用いる代わりに、QRコード読み取り専用のカメラをバスに搭載し、当該カメラで読み取った情報を乗務員端末16に送信する構成としてもよい。
乗務員端末16はステップS224のNFCタッチ/QRスキャンの結果、乗客2が指定した乗車バス停および降車バス停、利用者IDを取得する(S226)。乗務員端末16は、ステップS226で取得された乗車バス停および降車バス停と、ステップS212で予め登録された路線と、に基づいて、乗客2が払うべき運賃を決定する(S228)。乗務員端末16は、決済サーバ18と通信することで、ステップS228で決定された運賃を決済するための処理を行う(S230)。乗務員端末16と決済サーバ18間の通信は、必ずしもリアルタイムである必要はない。乗務員端末16は、ステップS226で取得された乗車バス停を基に乗客2によって提示されるべき整理券番号を決定する(S232)。乗務員端末16は、ステップS232で決定された整理券番号を含む出力情報を出力する(S234)。
乗務員14は、ステップS230で乗客2により提出された整理券8を受け取り(S222)、その番号と、ステップS234で出力された整理券番号と、を照合する(S236)。当該照合では降車バス停の異同も判定されてもよい。照合の結果、番号や降車バス停に相違なければ乗務員14は何もせず、相違があれば以下の取消処理が行われる。
(整理券番号が違う場合)
乗務員14は乗務員端末16を操作することで、支払いを取り消すための処理を行う(S238)。ここでは、乗務員14は乗客2が払うべき正しい運賃を乗務員端末16に入力する(S240)。乗務員端末16はステップS240で入力された運賃の決済を待ち受ける(S242)。乗客2は乗客端末4をR/W12に近づけるかQRコードを乗務員端末16に読み取らせることで、支払いを取り消す(S238)と同時に再度決済を行う(S244)。
(当該路線に乗客が選択した乗車バス停IDまたは降車バス停IDが存在しない場合)
乗務員14は乗務員端末16を操作することで、正当金額での決済を行うための処理を行う。乗務員14は乗客2が払うべき正しい運賃を乗務員端末16に入力する(S240)。乗務員端末16はステップS240で入力された運賃の決済を待ち受ける(S242)。乗客2は乗客端末4をR/W12に近づけるかQRコードを乗務員端末16に読み取らせることで、正当金額での決済を行う(S244)。
図13は、乗客端末4のディスプレイに表示されるお気に入り登録画面100の代表画面図である。お気に入り登録画面100は、お気に入りとして登録する乗車バス停、降車バス停、路線をそれぞれプルダウン形式で選択できるように構成されている。乗客2がお気に入りを選択した後、登録ボタンをタップすると、お気に入り登録受付部66は選択内容を取得してお気に入り情報保持部78に登録する。
図14は、乗客端末4のディスプレイに表示される乗降地選択画面102の代表画面図である。乗降地選択画面102は、乗客2が、お気に入り情報保持部78に登録されているお気に入りの乗車バス停・降車バス停・路線のセットのなかから選択できるように構成されている。例えば、図14の乗降地選択画面102において乗客2が「お気に入り1」をタップすると、乗降地指定受付部68は、乗車バス停「A」、降車バス停「B」、路線「C07」を、乗客2により指定された情報として受け付ける。
図15は、乗客端末4のディスプレイに表示される乗降地直接入力画面104の代表画面図である。図14の乗降地選択画面102において、乗客2がお気に入りを選択する代わりに直接入力ボタンをタップすると、乗降地直接入力画面104がディスプレイに表示される。乗降地直接入力画面104は、乗客2が指定する路線、乗車バス停、降車バス停をそれぞれプルダウン形式で選択できるように構成されている。乗客2が選択した後、登録ボタンをタップすると、乗降地指定受付部68は選択内容を取得して乗降地情報保持部80に登録する。
図16は、乗客端末4のディスプレイに表示される乗降地確認画面106の代表画面図である。図14の乗降地選択画面102でお気に入りのひとつが選択された場合、または図15で登録ボタンがタップされた場合、表示制御部76は乗降地確認画面106をディスプレイに表示させる。乗降地確認画面106は、選択された乗車バス停・降車バス停・路線および運賃決定部70によって決定された運賃を表示し、乗客2に確認を求めるよう構成される。乗降地確認画面106でやり直しボタンがタップされると、ディスプレイの表示は図14の乗降地選択画面102に戻る。
図17は、乗客端末4のディスプレイに表示される乗降地確定画面108の代表画面図である。図16の乗降地確認画面106で確定ボタンがタップされると、表示制御部76は乗降地確定画面108をディスプレイに表示させる。乗降地確定画面108は、乗降地確認画面106で確認した内容を再掲すると共に、降車時には整理券の提出および乗客端末4をR/W12に近づけることが必要である旨のテキストを表示する。QRコードを用いる場合は、乗降地確定画面108にQRコードを表示するかQRコードを表示するためのボタンを配置してもよい。
図24は、乗客端末4のディスプレイに表示される直接入力画面302の代表画面図である。図15、図16、図17では画面遷移により入力受付→入力内容確認→乗降地登録を行う例を示したが、図24ではそれらをひとつの画面で行う例を示す。直接入力画面302は、バス運行会社の名称等が表示されるヘッダー画像304と、路線選択領域306と、乗車地選択領域308と、降車地選択領域310と、運賃計算ボタン312と、運賃表示領域314と、登録ボタン316と、を有する。
乗客2はまず路線選択領域306で路線を選択し、次いで乗車地選択領域308、降車地選択領域310で乗車地、降車地を選択する。乗客2が運賃計算ボタン312をタップすると、選択された路線、乗車地、降車地で決まる運賃が運賃表示領域314に表示される。乗客2が登録ボタン316をタップすると、乗客端末4は選択された路線、乗車地、降車地を登録する。
図18は、乗客端末4のディスプレイに表示される決済結果画面110の代表画面図である。表示制御部76は、決済結果取得部74が取得した決済結果を基に決済結果画面110を生成してディスプレイに表示させる。決済結果画面110は、乗客2が登録した乗車バス停および降車バス停と、乗務員端末16に予め登録されていた路線と、乗務員端末16の運賃決定部48によって決定された運賃と、決済後の乗客2の口座の残高と、を表示する。
図19は、乗客端末4のディスプレイに表示される別の決済結果画面112の代表画面図である。別の決済結果画面112は、乗客2により指定された路線と乗務員14が登録した路線とが異なることにより、乗客端末4のディスプレイに表示された運賃(例えば、図16の乗降地確認画面106の「運賃(予定)」や図17の乗降地確定画面108の「運賃(予定)」)と実際に決済された運賃(例えば、図19の別の決済結果画面112の「運賃」)とが異なる場合、表示された運賃とは異なる額の運賃が決済されたことを示す注意テキスト114を含む。
乗車バス停や降車バス停が乗客2の申告と実際とで異なる場合は、システムまたは乗務員14による照合の結果、降車時に正当な金額による再度の決済が行われる。このように乗務員14による手作業が発生するのは、乗務員14による正しい乗車バス停、降車バス停の確認およびそれに基づく正しい運賃の入力が必要となるので、やむを得ない。これに対して乗車バス停および降車バス停は乗客2の指定したとおりであるものの、乗客2の指定した路線と実際の路線とが異なる場合は、乗務員端末16が予め正しい路線を把握しているので、自動で正しい運賃が算出され、決済される。したがって、図19に示されるような、降車時に乗務員14の手作業や乗客2の再度の決済を発生させることなく、事後的に正しい運賃を乗客2に知らせる運用が可能となる。
図20は、乗務員端末16のディスプレイ28に表示されるバス情報登録画面116の代表画面図である。バス情報登録画面116は、バスに乗務する乗務員14の名前およびバスの路線をそれぞれプルダウン形式で選択できるように構成されている。乗務員14が選択した後、登録ボタンをタップすると、バス情報受付部40は選択内容を取得してバス情報保持部58に登録する。乗務員名は名称の代わりにまたはそれに加えてIDで特定されてもよい。
図21は、乗務員端末16のディスプレイ28に表示される照合画面118の代表画面図である。乗客2が乗客端末4をR/W12に近づけて乗降地情報および利用者IDが乗務員端末16に送信されると、乗務員端末16のディスプレイ28に照合画面118が表示される。乗務員14は照合画面118に表示される情報もしくは音声出力される情報と整理券箱10に投入された整理券8とを照合し、正しい運賃が支払われたかを確認する。
出力制御部46は、出力情報生成部44によって生成された出力情報に基づいて照合画面118を生成する。照合画面118は、予め乗務員14が登録した路線を表示する路線表示領域120と、出力情報生成部44によって特定された整理券番号を表示する整理券番号表示領域122と、乗降地取得部42によって取得された乗降地情報に含まれる降車バス停を表示する降車バス停表示領域124と、運賃決定部48によって決定された運賃を表示する運賃表示領域126と、金額手入力ボタン128と、を有する。乗務員14は、整理券番号や降車バス停に相違があると判断した場合、金額手入力ボタン128をタップする。そうでなければ何もしない。何もしなければ、次の乗客が乗客端末をR/W12に近づけることによりその乗客に対応する新たな照合画面が表示される。
図22は、乗務員端末16のディスプレイ28に表示される運賃入力画面130の代表画面図である。図21の照合画面118において金額手入力ボタン128がタップされると、手動入力受付部56は運賃入力画面130を生成してディスプレイ28に表示させる。運賃入力画面130は、乗客2が払うべき正しい運賃を乗務員14がプルダウン形式で選択もしくは直接入力できるように構成されている。プルダウン内の選択肢は、乗務員14が予め登録した路線(図22の運賃入力画面130にもこの路線が表示されている)において設定されている運賃で構成される。手動入力受付部56は、運賃情報保持部60を参照することで、この選択肢を決定してもよい。乗務員14が正しい運賃を選択した後、決済待ち受けボタンをタップすると、乗務員端末16は選択された運賃を決済するための乗客端末4のタッチを待ち受ける状態に遷移する。
上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。
本実施の形態に係る決済システム1によると、以下の作用効果が奏される。
(1)現金による運賃収受との比較
今現在、整理券を用いた区間制運賃の後払い方式を採用するバスでは多くの場合、現金による運賃収受が行われている。この方式では、乗務員は投入された整理券、料金表、投入された小銭を目視で確認する必要がある。この作業は乗務員にとって負担であり、人の目視に頼る以上、ある程度の回収漏れや不足のリスクがある。
これに対して、本実施の形態に係る決済システム1では運賃の収受はキャッシュレス決済により行われるので、乗務員による小銭の目視、計算の負担を軽減または除去することができる。また、システムが自動的に運賃を算出して決済するので、回収漏れや不足のリスクを軽減または除去することができる。決済システム1では乗務員14に整理券番号や降車バス停の照合が求められるが、小銭の目視と比較すると乗務員14の負担は相当小さくなる。
また、乗客にとっても、運賃の準備や両替が不要となるので負担が軽減される。決済システム1では乗客2に乗車前または乗車中の乗降地情報の登録が求められるが、運賃の両替や準備と比較すると乗客2の負担は相当小さくなる。さらに、現状では降車時に運賃の両替や準備をする乗客が多く、スムーズな乗り降りの妨げになっていたが、本実施の形態に係る決済システム1では両替も準備も不用となるのでよりスムーズな乗り降りが実現される。
(2)整理券を廃した方式との比較
区間制運賃の後払い方式を採用するバスにおいて、整理券を廃し、代わりに携帯端末やICカードに乗車バス停の情報を書き込む方式も考えられる。この方式では、バスに乗車するときに乗車バス停の情報を書き込むためのR/Wと、バスから降りるときに決済を行うためのR/Wと、の少なくとも2台のR/Wをバスに搭載する必要がある。さらに、バス停を自動で判別するための仕組みをシステムに組み込む必要がある。例えば、GPS情報からバス停情報を自動検知する、もしくは音声合成システムと接続する、といった開発が必要となる。自動検知の場合は検知ロジックを開発する必要があり、システム接続する場合でも相応に開発規模やコストが高くなり、難易度が上がる。
これに対して、本実施の形態に係る決済システム1では、整理券の運用を残す代わりに、バスに搭載するR/Wは1台でよい。さらに、乗車バス停、降車バス停を乗客2に登録させ、その当否を乗務員14に判断させるので、バス停を判別するロジックが不要となる。したがって、開発の規模やコストを低く抑えることができる。決済システム1で用いる乗務員端末16は市販の汎用のタブレット端末などに乗務員アプリをインストールすることにより実現可能であり、専用の端末は不要であるから、これもコスト削減に貢献する。
また、バスの路線がGPS測位不能な地域または地理的制約に起因した低精度のGPS情報しか得られない地域を通る場合、GPS情報からバス停を自動検知する手法の適用は不可能または困難であるところ、本実施の形態に係る決済システム1はGPS情報を必要としないので、そのような路線のバスにも容易に適用可能である。
以上、実施の形態に係る決済システム1の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。
実施の形態では、乗降地選択画面102にお気に入りの乗降地・路線を提示して乗客2に選ばせる場合を説明したが、これに限られない。例えば、図10に示されるお気に入り情報保持部78にある通りにお気に入りデータが登録されているとする。乗客2が乗客アプリを開くと、お気に入り情報保持部78の通し番号「3」のエントリの乗車バス停「A」、降車バス停「B」を通過する直近3本程度の時刻表が、行きと帰りの両方表示される。
乗客2が降車の際に乗客端末4をR/W12に近づけると、バスの乗務員端末16は現在の路線にお気に入りデータの乗車バス停IDと降車バス停IDが存在するかを確認して決済する。乗車バス停IDと降車バス停IDが存在しない場合は、乗務員端末16は警告音と画面で警告し処理を中断する。路線に乗車バス停IDと降車バス停IDが存在している(例えば、路線「C07」)場合は以下の判定を行う。
1.整理券情報保持部62(図7参照)において、現路線(「C07」)の2つのバス停ID(「A」、「B」)に対応する整理券番号(「0」、「21」)を抽出
2.整理券番号の小さい方(「0」)を乗車バス停、大きい方(「21」)を降車バス停と判定
3.当該路線における運賃(「470円」)を運賃情報保持部60(図6参照)から算定
4.上記判定に基づいて、乗務員アプリが音声および画面で、2つの整理券番号(「0」、「21」)と運賃を通知。
具体的には、路線「C07」の場合、降車時のタッチにより、乗務員アプリは「A」を整理券番号0と判定し、「B」を整理券番号21と判定。運賃も470円と判定する。路線「C34」の場合は、「A」を整理券番号2と判定し、「B」盛岡大学を23と判定。運賃を490円と判定する。
実施の形態では、乗務員端末16が乗客端末4からNFC/QRコードにより乗降地情報および利用者IDを取得すると、乗務員14による操作を介することなく、決済要求を決済サーバ18に送る場合を説明したが、これに限られず、乗務員14による確認を経てから決済要求を決済サーバ18に送信する構成としてもよい。例えば、照合画面118に確認ボタンをさらに設け、この確認ボタンが乗務員14によってタップされると決済要求を送信する構成としてもよい。この場合、タッチの都度、乗務員14が確認ボタンを押さなければならないが、乗車バス停等の相違があった場合に決済サーバ18で決済が行われる前に修正することができ、決済取消要求が不要となる。したがって、決済サーバ18側での処理を簡単化することができる。
実施の形態では、運賃を決済する場合を説明したが、これに限られず、定期券を利用する場合にも本実施の形態の技術的思想を適用できる。この場合、定期券の区間および有効期限をお気に入りとして登録する。降車の際、定期券の区間および有効期限が乗降地情報として乗務員端末16に送信され、乗務員端末16のディスプレイ28に定期券の区間および有効期限が表示される。乗務員14は表示された有効期限を確認すると共に、投入された整理券の番号と、表示された定期券の区間と、を照合する。定期券の場合、決済要求に代えて、定期券の利用情報が決済サーバ18に送信され、決済サーバ18で決済は行われない。
実施の形態では、乗客2が登録した降車バス停が正しいか否かを乗務員14が判断する場合を説明したが、これに限られず、正しい降車バス停を乗務員端末16が指定してもよい。この場合、例えば、乗務員端末16を、乗務員14が正しい降車バス停を選択可能に構成してもよく、乗客2による乗客アプリへの降車バス停入力が不要となる。
図23は、乗務員端末16のディスプレイ28に表示されるホーム画面132の代表画面図である。本変形例では、乗務員アプリのホーム画面132に、照合画面へのリンク134と、現在設定されている降車バス停の表示136と、降車バス停を進めるためのボタン138と、を有する。乗務員14は、バス停で停車するか停車せずに通過するたびに、ボタン138をタップする。ボタン138が一回タップされるごとに、予め登録されているバスの路線にしたがって、降車バス停がひとつずつ進んでいく。例えば、バスの路線においてバス停が「A」、「B」、「C」、「D」、「E」、「F」、…と並んでいる場合、バス停「C」での乗降が終わると乗務員14はバスを発車させる前にホーム画面132に戻ってボタン138をタップする。すると、降車バス停の表示136が「C」から「D」に変わる。次のバス停「D」では、乗務員端末16は、乗客端末4から取得される乗車バス停と、予め乗務員端末16が登録しておいた路線の経路番号と、更新された降車バス停(この場合、「D」)と、から運賃を決定する。
実施の形態では、乗客端末4から乗務員端末16に乗降地情報および利用者IDを非接触の直接通信を介して送信する場合を説明したが、これに限られない。例えば、乗客端末4は、乗客2が乗客アプリに登録した乗車バス停および降車バス停を利用者IDと共に、ネットワーク20を介して決済サーバ18または他の管理サーバに送信してもよい。乗客2が降車する際に乗客端末4をR/W12に近づけると、NFCにより乗客端末4からR/W12に利用者IDが送信される。乗務員端末16は、R/W12から渡された利用者IDを含む乗降地要求を生成し、ネットワーク20を介して決済サーバ18または他の管理サーバに送信する。決済サーバ18または他の管理サーバは、当該乗降地要求に含まれる利用者IDに対応する乗車バス停および降車バス停を、ネットワーク20を介して乗務員端末16に送信する。乗務員端末16は受信した乗車バス停および降車バス停を用いて運賃の決定、出力情報の生成を行う。決済サーバ18またはほかの管理サーバがネットワーク20を介して乗務員端末16に情報を送信する代わりに、乗客端末4から受信した情報を乗務員端末16とネットワーク20を介して、決済サーバ18に送信し、決済サーバが乗降情報と利用者IDの突合を実施してもよい。この場合、乗客端末4と乗務員端末16間の通信は乗客2が事前決済済みという情報だけに留めておき、事前決済と実際の乗車利用に差異がある場合は、差額を該当利用者IDに対し請求することが可能となる。
実施の形態では、決済サーバ18で決済を行うサーバ型またはネットワーク型のキャッシュレス決済を用いる場合を説明したが、これに限られず、例えば端末で電子マネーの残高を記録、管理する端末型のキャッシュレス決済に本実施の形態の技術的思想を適用してもよい。この場合、乗務員端末16は、乗客端末4からNFCを介して乗降地情報を取得すると、決定された運賃を含む決済要求を、決済サーバ18にネットワーク20を介して送信する代わりに、NFCを介して乗客端末4に返す。乗客端末4は、受信した決済要求に含まれる運賃分の金額を、保持している残高から減算することで決済を行う。端末型のキャッシュレス決済の仕組み自体は、公知の端末型電子マネー決済技術を用いて実現されてもよい。