特許 7232523 区間制運賃の後払い方式を採用する交通機関で用いられる携帯端末およびコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-02-22

(45)【発行日】2023-03-03

(54)【発明の名称】区間制運賃の後払い方式を採用する交通機関で用いられる携帯端末およびコンピュータプログラム

(51)【国際特許分類】

   G07B 15/00 20110101AFI20230224BHJP

【ＦＩ】

G07B15/00 V

【請求項の数】 12

(21)【出願番号】P 2019152162

(22)【出願日】2019-08-22

(65)【公開番号】P2021033575

(43)【公開日】2021-03-01

【審査請求日】2021-10-01

(73)【特許権者】

【識別番号】500011528

【氏名又は名称】株式会社岩手銀行

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100076428

【弁理士】

【氏名又は名称】大塚 康徳

(74)【代理人】

【識別番号】100115071

【弁理士】

【氏名又は名称】大塚 康弘

(74)【代理人】

【識別番号】100112508

【弁理士】

【氏名又は名称】高柳 司郎

(74)【代理人】

【識別番号】100116894

【弁理士】

【氏名又は名称】木村 秀二

(74)【代理人】

【識別番号】100130409

【弁理士】

【氏名又は名称】下山 治

(74)【代理人】

【識別番号】100134175

【弁理士】

【氏名又は名称】永川 行光

(74)【代理人】

【識別番号】100199277

【弁理士】

【氏名又は名称】西守 有人

(72)【発明者】

【氏名】関村 淳哉

(72)【発明者】

【氏名】清水 雅俊

(72)【発明者】

【氏名】西 高宏

(72)【発明者】

【氏名】梨本 裕太郎

(72)【発明者】

【氏名】伊藤 明美

(72)【発明者】

【氏名】馬場 真一郎

(72)【発明者】

【氏名】里見 海帆

(72)【発明者】

【氏名】須藤 圭輔

【審査官】永安 真

(56)【参考文献】

【文献】特開２０１５－１５２６２４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０７Ｂ １５／００

(57)【特許請求の範囲】

【請求項1】

整理券を用いた区間制運賃の後払い方式を採用する交通機関の乗務員の携帯端末に、
乗客が降車する際、当該乗客の携帯端末との非接触の直接通信により、当該乗客が指定した乗降地を示す乗降地情報を取得する機能と、
取得された乗降地情報に基づいて、前記乗客によって提示されるべき整理券を識別するための整理券情報および前記乗客が指定した降車地を示す降車地情報を、前記乗務員の携帯端末の出力手段に出力させる機能と、を実現させるためのコンピュータプログラム。

【請求項2】

取得された乗降地情報に基づいて決定された運賃を決済するための処理を行う機能をさらに前記乗務員の携帯端末に実現させる請求項１に記載のコンピュータプログラム。

【請求項3】

前記乗務員から予め路線の指定を受け付ける機能と、
取得された乗降地情報と指定された路線とに基づいて、前記乗客が払うべき運賃を決定する機能と、をさらに前記乗務員の携帯端末に実現させる請求項２に記載のコンピュータプログラム。

【請求項4】

前記決定する機能は、乗車地が同じであり降車地が同じであっても、路線が異なる場合、異なる運賃を決定する機能を含む請求項３に記載のコンピュータプログラム。

【請求項5】

整理券情報および降車地情報が前記出力手段によって出力された後、前記乗客が払うべき運賃の指定を前記乗務員から受け付ける機能と、
前記乗客の携帯端末と非接触の直接通信を介して通信することにより、前記乗務員によって指定された運賃を決済するための処理を行う機能と、をさらに前記乗務員の携帯端末に実現させる請求項２から４のいずれか一項に記載のコンピュータプログラム。

【請求項6】

前記決済するための処理を行う機能は、ネットワークを介した決済サーバとの通信ができない場合、前記乗務員の携帯端末に取引内容を蓄積し、通信が回復した後に蓄積されていた取引内容を前記決済サーバに送信する機能を含む請求項２から５のいずれか一項に記載のコンピュータプログラム。

【請求項7】

整理券を用いた区間制運賃の後払い方式を採用する交通機関の乗務員の携帯端末であって、
乗客が降車する際、当該乗客の携帯端末との非接触の直接通信により、当該乗客が指定した乗降地を示す乗降地情報を取得する手段と、
取得された乗降地情報に基づいて、前記乗客によって提示されるべき整理券を識別するための整理券情報および前記乗客が指定した降車地を示す降車地情報を、前記乗務員の携帯端末の出力手段に出力させる手段と、を備える携帯端末。

【請求項8】

整理券を用いた区間制運賃の後払い方式を採用する交通機関の乗客の携帯端末に、
乗降地の指定を前記乗客から受け付ける機能と、
前記乗客が降車する際、非接触の直接通信を介して乗務員の携帯端末に、前記乗客が指定した乗降地を示す乗降地情報を送信する機能と、
送信された前記乗降地情報に基づいて決定された運賃の決済結果を前記乗客の携帯端末のディスプレイに表示させる機能と、を実現させるためのコンピュータプログラム。

【請求項9】

予め乗車地または降車地もしくはそれらの組み合わせの登録を受け付ける機能と、
乗降地の指定を前記乗客から受け付ける際、予め登録されている乗車地または降車地もしくはそれらの組み合わせの指定を可能とする機能と、をさらに前記乗客の携帯端末に実現させる請求項８に記載のコンピュータプログラム。

【請求項10】

路線の指定を前記乗客から受け付ける機能と、
乗降地情報と指定された路線とに基づいて前記乗客が払うべき運賃を決定する機能と、
決定された運賃を乗降地情報と共に前記乗客の携帯端末のディスプレイに表示させる機能と、をさらに前記乗客の携帯端末に実現させる請求項８または９に記載のコンピュータプログラム。

【請求項11】

前記乗客により指定された路線と前記乗務員により指定された路線とが異なることにより前記乗客の携帯端末のディスプレイに表示された運賃と実際に決済された運賃とが異なる場合、表示された運賃とは異なる額の運賃が決済されたことを示す情報を、前記乗客の携帯端末のディスプレイに表示させる機能をさらに前記乗客の携帯端末に実現させる請求項１０に記載のコンピュータプログラム。

【請求項12】

整理券を用いた区間制運賃の後払い方式を採用する交通機関の乗客の携帯端末であって、
乗降地の指定を前記乗客から受け付ける手段と、
前記乗客が降車する際、非接触の直接通信を介して乗務員の携帯端末に、前記乗客が指定した乗降地を示す乗降地情報を送信する手段と、
送信された前記乗降地情報に基づいて決定された運賃の決済結果を前記乗客の携帯端末のディスプレイに表示させる手段と、を備える携帯端末。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、区間制運賃の後払い方式を採用する交通機関で用いられる携帯端末およびコンピュータプログラムに関する。

【背景技術】

【0002】

近年、ＩＴ技術の進歩と共に、電子マネーやキャッシュレス決済の普及が進んでいる。特に小銭の収受の多い公共交通機関へのキャッシュレス決済の導入は利点が多く、例えば、非特許文献１には電子マネーを用いて路線バスの多区間運賃決済を実現する例が記載されている。

【先行技術文献】

【非特許文献】

【0003】

【文献】全国初！路線バスで電子マネー「WAON」の多区間運賃決済を開始 、https://www.figinc.jp/news/3553/、令和１年７月３１日検索

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、非特許文献１に記載されるようなスキームでは、交通機関の車両に専用の車載器を導入し、既設車載システムと接続する必要があるのでコストが嵩む。さらに、既設車載システム接続の代替手法として乗車位置測位にＧＰＳを用いるとすると、ＧＰＳが利用不可または利用困難な地域を通る路線バスには適用できない。

【0005】

本発明はこうした課題に鑑みてなされたものであり、その目的は、区間制運賃の後払い方式を採用する交通機関において、運賃収受のキャッシュレス化を図りつつそれによるコストの増大を抑制できる技術の提供にある。

【課題を解決するための手段】

【0006】

本発明のある態様は、コンピュータプログラムに関する。このコンピュータプログラムは、整理券を用いた区間制運賃の後払い方式を採用する交通機関の乗務員の携帯端末に、乗客が降車する際、当該乗客の携帯端末との非接触の直接通信により、当該乗客が指定した乗降地を示す乗降地情報を取得する機能と、取得された乗降地情報に基づいて、乗客によって提示されるべき整理券を識別するための整理券情報および乗客が指定した降車地を示す降車地情報を、乗務員の携帯端末の出力手段に出力させる機能と、を実現させる。

【0007】

本発明の別の態様もまた、コンピュータプログラムである。このコンピュータプログラムは、整理券を用いた区間制運賃の後払い方式を採用する交通機関の乗客の携帯端末に、乗降地の指定を乗客から受け付ける機能と、乗客が降車する際、非接触の直接通信を介して乗務員の携帯端末に、乗客が指定した乗降地を示す乗降地情報を送信する機能と、送信された乗降地情報に基づいて決定された運賃の決済結果を乗客の携帯端末のディスプレイに表示させる機能と、を実現させる。

【0008】

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

【発明の効果】

【0009】

本発明によれば、区間制運賃の後払い方式を採用する交通機関において、運賃収受のキャッシュレス化を図りつつそれによるコストの増大を抑制できる。

【図面の簡単な説明】

【0010】

【図1】本実施の形態に係る利用シナリオの説明図である。

【図2】本実施の形態に係る決済システムの構成を示す模式図である。

【図3】図１の乗務員端末のハードウエア構成図である。

【図4】図１の乗務員端末の機能および構成を示すブロック図である。

【図5】図４のバス情報保持部の一例を示すデータ構造図である。

【図6】図４の運賃情報保持部の一例を示すデータ構造図である。

【図7】図４の整理券情報保持部の一例を示すデータ構造図である。

【図8】同一乗降地でも路線が異なると運賃が異なりうることを説明するための図である。

【図9】図１の乗客端末の機能および構成を示すブロック図である。

【図10】図９のお気に入り情報保持部の一例を示すデータ構造図である。

【図11】図９の乗降地情報保持部の一例を示すデータ構造図である。

【図12】図２の決済システムにおける処理の流れを示すチャートである。

【図13】乗客端末のディスプレイに表示されるお気に入り登録画面の代表画面図である。

【図14】乗客端末のディスプレイに表示される乗降地選択画面の代表画面図である。

【図15】乗客端末のディスプレイに表示される乗降地直接入力画面の代表画面図である。

【図16】乗客端末のディスプレイに表示される乗降地確認画面の代表画面図である。

【図17】乗客端末のディスプレイに表示される乗降地確定画面の代表画面図である。

【図18】乗客端末のディスプレイに表示される決済結果画面の代表画面図である。

【図19】乗客端末のディスプレイに表示される別の決済結果画面の代表画面図である。

【図20】乗務員端末のディスプレイに表示されるバス情報登録画面の代表画面図である。

【図21】乗務員端末のディスプレイに表示される照合画面の代表画面図である。

【図22】乗務員端末のディスプレイに表示される運賃入力画面の代表画面図である。

【図23】乗務員端末のディスプレイに表示されるホーム画面の代表画面図である。

【図24】乗客端末のディスプレイに表示される直接入力画面の代表画面図である。

【発明を実施するための形態】

【0011】

以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

【0012】

実施の形態は、バスなどの公共交通機関でのキャッシュレス決済（例えば、ＮＦＣ決済）に関し、現在、多区間運賃を行っている公共交通機関で用いられている「整理券」の運用を残しながら、決済のキャッシュレス化を図る。

【0013】

交通事業者が本実施の形態に係るスキームを採用するメリットとしては、下記が考えられる。
１．圧倒的に低コストでキャッシュレスを実現することができる。例えば、現行の交通系ＩＣカードを導入する場合と比較して圧倒的に低コストでバス等に設置する設備を導入することができる。
２．乗車停留場、降車停留所を判断するために、従来は「ＧＰＳ等による停留所位置認識」や「音声合成システム」などがあったが、本スキームではすでに備え付けられている整理券運用と連携した方法を取ることで、他の方法と比較して、技術的ハードルが圧倒的に低くなる。
３．乗務員の負担がほとんど発生しない。

【0014】

本開示は、整理券を用いた区間制運賃の後払い方式を採用する交通機関を対象とする。
「整理券」は、乗車地を証明するために発行される切符であり、乗車整理券・乗車票・乗車駅証明書とも呼ばれる。
「区間制運賃」は、路線を区間ごとに区切って、区間をまたぐごとに運賃が加算されていく運賃制度である。
「後払い方式」は、運賃を降車時に支払う支払い方式である。
「交通機関」は、バスや電車などの公共交通機関を含む。
本実施の形態では特に、整理券を用いた区間制運賃の後払い方式を採用するバスを対象とするが、他の実施の形態では整理券を用いた区間制運賃の後払い方式を採用する他の交通機関に本実施の形態の技術的思想を適用してもよい。

【0015】

図１は、本実施の形態に係る利用シナリオの説明図である。バスの乗客２は自己の携帯端末（以下、乗客端末４と称す）に乗客用の決済アプリケーションプログラム（以下、乗客アプリと称す）をダウンロードしてインストールする。乗客２は、乗客アプリを起動して初期の利用登録をする。この利用登録では、乗客２の個人情報の登録や決済口座の指定が行われる。乗客２は、よく使うバス停や路線があればお気に入りのバス停・路線として登録する。

【0016】

乗客２はバスに乗り込むとまず、バスの乗車口に設けられた整理券発券機６から整理券８を取得する。乗客２は着席して乗客アプリを開き、乗降地すなわち乗車バス停および降車バス停を選択して登録する。当該登録は乗車の前に行われてもよい。

【0017】

乗客２は、降車の際、整理券８をバスの降車口（運転席付近）に設けられた整理券箱１０に投入すると共に、乗客端末４を整理券箱１０の近くに設けられたＲ／Ｗ（リーダライタ）１２に近づける。するとＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を介して乗客端末４からＲ／Ｗ１２へ、決済用情報と共に乗客２が指定した乗降地を示す情報（以下、乗降地情報と称す）が送信される。乗客２はその場で、または降車後に、乗客端末４において運賃の決済結果を確認することができる。乗降地情報は、乗車地すなわち乗車バス停のＩＤおよび／または名称と、降車地すなわち降車バス停のＩＤおよび／または名称と、を含む。

【0018】

バスの乗務員１４は自己またはバス運行会社の携帯端末（以下、乗務員端末１６と称す）に乗務員用の決済アプリケーションプログラム（以下、乗務員アプリと称す）をダウンロードしてインストールする。乗務員１４は乗務員アプリを起動してログインし、自己が乗務または運転するバスの路線・系統を選択して登録する。

【0019】

乗客２が降車する際、乗務員端末１６は、乗客２の乗客端末４からＮＦＣを介して取得した決済用情報を基に、図１では不図示の決済サーバと通信することで運賃を決済する。乗務員端末１６は、乗客２の乗客端末４からＮＦＣを介して取得した乗降地情報を基に、乗客２が登録（自己申告）した乗車バス停に対応する整理券番号と、降車バス停と、運賃と、をディスプレイに表示させる。併せて乗務員端末１６はそれらの情報を音声で出力する。乗務員１４は、乗務員端末１６のディスプレイに表示される整理券番号または音声で出力される整理券番号と、整理券箱１０に投入された整理券８の番号と、を照合する。乗務員１４は、それらが一致すれば何もせず、相違すれば支払いを一端取り消して、正しい運賃を入力し、乗客２に再度、乗客端末４をＲ／Ｗ１２に近づけるよう促す。

【0020】

乗務員１４は、乗務が終了すると、乗務員端末１６において乗務員アプリからログオフする。

【0021】

図２は、本実施の形態に係る決済システム１の構成を示す模式図である。決済システム１は、決済サーバ１８と、乗務員端末１６と、乗客端末４と、を備える。決済サーバ１８、乗務員端末１６、乗客端末４はそれぞれ移動体通信ネットワークやインターネットなどのネットワーク２０に接続され、ネットワーク２０を介して互いに通信可能に構成される。図２に示される構成は例示であり、乗務員端末１６、乗客端末４の数に制限はない。決済サーバ１８は複数のサーバを含んでもよい。

【0022】

決済システム１は、乗客２とバス運行会社との間のキャッシュレス決済を可能とするシステムである。決済サーバ１８はキャッシュレス決済のサービスを提供する事業体により管理される。乗客２、バス運行会社はいずれも予めサービスに利用登録を行い、端末および口座の情報をサービスに提供し、ＩＤ・パスワードの付与を受ける。図１に示す通り、乗客２がバスから降車する際、乗客端末４から乗務員端末１６に直接（すなわち、ネットワーク２０を介さず）、乗客２を特定する利用者ＩＤを含む決済用情報がＮＦＣを用いて送信される。乗務員端末１６は取得した利用者ＩＤに乗降地・路線から算出された運賃を加えて決済要求を生成し、ネットワーク２０を介して決済サーバ１８に送信する。決済サーバ１８は、決済要求を受信すると、当該決済を実行する。この決済処理は即時に行われてもよいし、決済データを蓄えて後日まとめて行ってもよい。乗務員端末１６および乗客端末４は、決済の結果を決済サーバ１８に問い合わせすることが出来る。

【0023】

決済サーバ１８における決済の処理は、乗客２の決済用口座からバス運行会社の決済用口座へ運賃分の金額を電子的に移動するための処理であり、公知の電子決済技術を用いて実現されてもよい。

【0024】

なお、本実施の形態では乗務員端末１６と乗客端末４との間の非接触の直接通信としてＮＦＣを想定するが、他の実施の形態ではＮＦＣに代えて、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ、ＩＲ（Ｉｎｆｒａｒｅｄ、赤外線）、画像（例えば、バーコード、ＱＲコード（登録商標）など）などの他のタイプの非接触の直接通信を用いて、乗務員端末１６と乗客端末４との間で情報をやりとりしてもよい。本実施の形態ではＱＲコード（登録商標）を用いた情報の伝達についても触れる。以下、本明細書に記載の「ＱＲコード」を「ＱＲコード（登録商標）」に読み替えるものとする。

【0025】

乗客端末４および乗務員端末１６はいずれも携帯端末（例えば、スマートフォン、タブレット端末、ラップトップＰＣなど）であり、いずれの携帯端末もアンテナ間の通信により情報を伝達する方式および撮像により情報を伝達する方式の両方に対応可能に構成される。例えば乗客端末４は、利用者ＩＤおよび乗降地情報をＮＦＣにより他の端末に送信する機能と、利用者ＩＤおよび乗降地情報を符号化された形で示すＱＲコードをディスプレイに表示させる機能と、を有する。乗務員端末１６は、利用者ＩＤおよび乗降地情報をＮＦＣにより他の端末から受信する機能と、他の端末に表示されたＱＲコードをカメラなどの撮像手段により読み取る機能と、を有する。ＮＦＣによる通信は公知の技術を用いて実現されてもよい。ＱＲコードによる情報の伝達は公知の技術を用いて実現されてもよい。

【0026】

乗客端末４のユーザである乗客２は、ダウンロードサイトからネットワーク２０を介して乗客アプリを乗客端末４にダウンロードし、インストールする。あるいはまた、乗客アプリは乗客端末４にプリインストールされていてもよい。乗客アプリはキャッシュレス決済のサービスの事業体またはバス運行会社により提供される。乗客アプリが乗客端末４により実行されることにより、乗客端末４は各種機能を実現する。乗務員端末１６についても同様に、バスの乗務員１４が乗務員アプリを乗務員端末１６にダウンロードし、インストールしてもよいし、乗務員アプリはプリインストールされていてもよい。

【0027】

図３は、図１の乗務員端末１６のハードウエア構成図である。乗客端末４は図３に示される乗務員端末１６のハードウエア構成と同様のハードウエア構成を有する。乗務員端末１６は、メモリ２２と、プロセッサ２４と、ネットワークインタフェース２６と、ディスプレイ２８と、入力インタフェース３０と、ＮＦＣインタフェース３２と、スピーカ３４と、カメラ３８と、を備える。これらの要素はそれぞれバス３６に接続され、バス３６を介して互いに通信する。

【0028】

メモリ２２は、データやプログラムを記憶するための記憶領域である。データやプログラムは、メモリ２２に恒久的に記憶されてもよいし、一時的に記憶されてもよい。プロセッサ２４は、メモリ２２に記憶されている乗務員アプリなどのプログラムを実行することにより、乗務員端末１６の各種機能を実現する。ネットワークインタフェース２６は、乗務員端末１６の外部との間でデータの送受信を行うためのインタフェースである。ネットワークインタフェース２６はネットワーク２０と接続され、ネットワーク２０を介して決済サーバ１８とデータをやりとりする。ＮＦＣインタフェース３２は、ＮＦＣのためのインタフェースであり、ＮＦＣを用いて乗客端末４とデータをやりとりする。ネットワークインタフェース２６およびＮＦＣインタフェース３２はそれぞれ専用の半導体チップであってもよい。ディスプレイ２８は、各種情報を表示するためのデバイスである。入力インタフェース３０は、乗務員１４からの入力を受け付けるためのデバイスであり、例えばタッチパネルや物理的なボタンを含む。スピーカ３４は音声を出力する。カメラ３８はレンズおよび撮像素子を含む。カメラ３８は特に乗客端末４のディスプレイに表示されるＱＲコードを撮像することで読み込む。

【0029】

図４は、図１の乗務員端末１６の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

【0030】

乗務員端末１６は、バス情報受付部４０と、乗降地取得部４２と、出力情報生成部４４と、出力制御部４６と、運賃決定部４８と、決済実行部５０と、決済取消部５４と、手動入力受付部５６と、バス情報保持部５８と、運賃情報保持部６０と、整理券情報保持部６２と、を備える。

【0031】

図５は、図４のバス情報保持部５８の一例を示すデータ構造図である。バス情報保持部５８は、乗務員１４が乗務しているまたは乗務しようとしているバスに関する情報を保持する。バス情報保持部５８は、バスを特定するバスＩＤと、当該バスに乗務する乗務員１４の名前と、当該バスの路線の経路番号と、を対応付けて保持する。以下ではバスの「路線」と「系統」と「経路」とを同じ意味で用いる。

【0032】

図６は、図４の運賃情報保持部６０の一例を示すデータ構造図である。運賃情報保持部６０は、バス情報保持部５８に登録されているバスの路線（経路番号）に対応する運賃表のデータを保持する。乗務員端末１６は、各路線に対応する運賃表のデータを図６のデータ構造と同様のデータ構造で保持する。運賃情報保持部６０は、乗車バス停を特定する乗車バス停ＩＤを縦（行）、降車バス停を特定する降車バス停ＩＤを横（列）とするマトリクス形式で表現され、各セルは対応する乗車バス停から対応する降車バス停まで乗車したときの運賃を示している。例えば、図６の符号６４で示されるセルは、乗車バス停ＩＤ「ＡＧ００１」のバス停で乗車し、降車バス停ＩＤ「ＨＪ０２４」のバス停で降車したときの運賃が「３４０円」であることを示す。

【0033】

図７は、図４の整理券情報保持部６２の一例を示すデータ構造図である。整理券情報保持部６２は全路線の各バス停に対応する整理券番号を保持する。整理券情報保持部６２は、路線を特定する経路番号と、当該路線におけるバス停を特定するバス停ＩＤと、当該バス停のバス停名と、当該路線における当該バス停の整理券番号と、を対応付けて保持する。

【0034】

図４に戻り、バス情報受付部４０は、乗務員１４から予め乗務対象のバスの情報を受け付ける。バス情報受付部４０は、受け付けた情報をバス情報保持部５８に登録する。バス情報受付部４０は特に、乗務員１４から予めバスの路線の指定を受け付けて、バス情報保持部５８に登録する。

【0035】

乗降地取得部４２は、乗客２がバスから降車する際、ＮＦＣまたはＱＲコード撮像を介して乗客端末４から、当該乗客２の利用者ＩＤと当該乗客２が指定した乗降地を示す乗降地情報とを取得する。

【0036】

出力情報生成部４４は、乗降地取得部４２によって取得された乗降地情報に基づいて、乗客２によって提示されるべき整理券８を識別するための情報である整理券番号と、乗客２が指定した降車バス停を示す降車地情報と、を含む出力情報を生成する。出力情報生成部４４は、バス情報保持部５８を参照してバスの路線を特定する。出力情報生成部４４は、乗降地取得部４２によって取得された乗降地情報に含まれる乗車バス停名または乗車バス停ＩＤを特定する。出力情報生成部４４は、バス情報保持部５８と整理券情報保持部６２とを参照し、特定された路線の特定された乗車バス停名または乗車バス停ＩＤに対応する整理券番号を特定する。出力情報生成部４４は、特定された整理券番号と、乗降地取得部４２によって取得された乗降地情報に含まれる降車バス停名と、後述の運賃決定部４８によって決定された運賃と、を合わせて出力情報とする。なお、バス情報保持部５８のバス路線に、乗降地取得部４２に保持する乗車バス停ＩＤまたは降車バス停ＩＤのいずれかが存在しない場合は、乗務員端末１６のディスプレイに「乗車バス停不一致」または「降車バス停不一致」または「乗車バス停、降車バス停不一致」のエラー表示を行い、同時に乗務員端末１６が警告音を発して、乗客２および乗務員１４に対して決済不能である旨通知し、処理を中断する。

【0037】

出力制御部４６は、出力情報生成部４４によって生成された出力情報を、乗務員端末１６の出力手段に出力させる。出力手段はディスプレイ２８またはスピーカ３４もしくはその両方である。出力情報をディスプレイ２８に表示させる例は後述する。出力情報をスピーカ３４から音声として出力する場合、公知の音声合成技術が用いられてもよい。

【0038】

運賃決定部４８は、乗降地取得部４２によって取得された乗降地情報と乗務員１４によって予め指定された路線とに基づいて、乗客２が払うべき運賃を決定する。運賃決定部４８は、バス情報保持部５８を参照してバスの路線を特定する。運賃決定部４８は、乗降地情報に含まれる乗車バス停ＩＤおよび降車バス停ＩＤを特定する。運賃決定部４８は、特定された路線に対応する運賃表のデータ（図６参照）を参照し、特定された乗車バス停ＩＤおよび降車バス停ＩＤに対応するセルに保持される運賃を、乗客２が払うべき運賃として決定する。

【0039】

運賃決定部４８において、乗車バス停が同じであり降車バス停が同じであっても、路線が異なる場合、異なる運賃が決定されることがある。図８は、同一乗降地でも路線が異なると運賃が異なりうることを説明するための図である。図８（ａ）に示されるように、乗車バス停「Ａ」から降車バス停「Ｂ」への路線として路線「Ｃ０７」と路線「Ｃ３４」とがあるとする。路線「Ｃ０７」は途中でバス停「Ｃ」を経由するがバス停「Ｄ」は経由せず、路線「Ｃ３４」は途中でバス停「Ｄ」を経由するがバス停「Ｃ」は経由しない。図８（ｂ）は路線「Ｃ０７」の整理券番号および運賃を示し、図８（ｃ）は路線「Ｃ３４」の整理券番号および運賃を示す。このように、同じ乗車バス停「Ａ」および同じ降車バス停「Ｂ」に対して、路線「Ｃ０７」では運賃が「４７０円」、路線「Ｃ３４」では運賃が「４９０円」となり、路線が異なれば運賃も異なる。運賃決定部４８は、乗客２の自己申告に係る乗車バス停および降車バス停に加えて、バスの路線を考慮することで、図８のような状況でも正しい運賃を決定することができる。

【0040】

図４に戻り、決済実行部５０は、運賃決定部４８によって決定された運賃を決済するための処理を行う。決済実行部５０は、乗降地取得部４２によって取得された利用者ＩＤと、運賃決定部４８によって決定された運賃と、決済要求を特定する決済要求ＩＤと、を含む決済要求を生成し、ネットワーク２０を介して決済サーバ１８に送信する。

【0041】

手動入力受付部５６は、乗客２が整理券箱１０に投入した整理券８の番号と乗務員端末１６から出力された整理券番号とが相違すると判断した乗務員１４からの正当金額の入力を受け付ける。乗務員１４は、乗務員端末１６から出力された降車地情報と、実際の降車バス停とが相違すると判断した場合にも正当金額の入力を行う。

【0042】

手動入力受付部５６は、乗客２が払うべき運賃の指定を乗務員１４から受け付ける。決済実行部５０は、乗客端末４とＮＦＣまたはＱＲコード撮像を介して通信することにより、手動入力受付部５６によって受け付けられた運賃を決済するための処理を行う。同時に決済取消部５４は、当該乗客端末４に紐づけられた乗客ＩＤによる決済履歴についてネットワーク２０を介して決済サーバ１８に問い合わせ、現在時刻より過去一定時間の範囲（例：２分以内）に該当する履歴がある場合には、これの取消要求を決済サーバ１８に対して行う。

【0043】

決済取消部５４による決済履歴照会がネットワーク２０の不通により行えない場合は、決済取消部５４は一連の動作（決済履歴照会→取消要求）について、ネットワーク２０の回復を待って行う。決済実行部５０についても同様の動作をおこなう。

【0044】

図９は、図１の乗客端末４の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

【0045】

乗客端末４は、利用登録受付部６５と、お気に入り登録受付部６６と、乗降地指定受付部６８と、運賃決定部７０と、乗降地情報送信部７２と、決済結果取得部７４と、表示制御部７６と、お気に入り情報保持部７８と、乗降地情報保持部８０と、図６の運賃情報保持部６０と同様のデータ構造を有する運賃情報保持部８２と、を備える。

【0046】

図１０は、図９のお気に入り情報保持部７８の一例を示すデータ構造図である。お気に入り情報保持部７８は、乗客２がよく使う乗車バス停や降車バス停や路線やそれらの組み合わせをお気に入りとして保持する。乗車バス停、降車バス停および路線を全て指定することで、どのバスにどのバス停からどのバス停まで乗るかが指定され、運賃が一意に定まる。お気に入り情報保持部７８は、お気に入りデータを特定する通し番号と、お気に入りに指定された路線を特定する経路番号と、お気に入りに指定された乗車バス停の名称と、お気に入りに指定された降車バス停の名称と、を対応付けて保持する。バス停は名称の代わりにまたはそれに加えてＩＤで特定されてもよい。

【0047】

図１１は、図９の乗降地情報保持部８０の一例を示すデータ構造図である。乗降地情報保持部８０は、乗客２の自己申告に係る乗車バス停、降車バス停および路線を保持する。乗降地情報保持部８０は、乗客２の乗客ＩＤと、当該乗客２が登録した路線の経路番号と、当該乗客２が登録した乗車バス停の名称と、当該乗客２が登録した降車バス停の名称と、を対応付けて保持する。バス停は名称の代わりにまたはそれに加えてＩＤで特定されてもよい。

【0048】

図９に戻り、お気に入り登録受付部６６は、予め乗客２から、乗車バス停、降車バス停や路線などの組み合わせのお気に入りへの登録を受け付ける。お気に入り登録受付部６６は、乗客２がお気に入りに指定した内容をお気に入り情報保持部７８に登録する。

【0049】

乗降地指定受付部６８は、乗客２がバスに乗る前または乗車中に、乗客２から、乗車バス停および降車バス停の指定を受け付ける。乗降地指定受付部６８は、お気に入り情報保持部７８を参照して乗客２のお気に入りの乗車バス停、降車バス停や路線を取得し、取得したお気に入り情報からの選択を乗客２に促す画面（後述）を乗客端末４のディスプレイに表示させる。乗降地指定受付部６８は、乗客２によるお気に入り情報からの選択を受け付ける。乗降地指定受付部６８はまた、お気に入り情報からの選択ではない、乗客２による乗車バス停、降車バス停および路線の直接的な指定も受け付ける。乗降地指定受付部６８は、受け付けた情報を乗降地情報保持部８０に登録する。

【0050】

運賃決定部７０は、乗降地指定受付部６８で指定された乗車バス停、降車バス停および路線に基づいて、運賃情報保持部８２を参照することで、乗客２が払うべき運賃を決定する。運賃決定部７０における運賃の決定は、運賃決定部４８における運賃の決定に準じる。

【0051】

乗降地情報送信部７２は、乗客２が降車する際、ＮＦＣまたはＱＲコード撮像を介して乗務員端末１６に、乗客２が指定した乗車バス停および降車バス停を示す乗降地情報と乗客ＩＤとを送信する。

【0052】

決済結果取得部７４は、乗降地情報送信部７２によって送信された乗降地情報に基づいて乗務員端末１６において決定された運賃の決済結果を、ネットワーク２０を介して決済サーバ１８から取得する。

【0053】

表示制御部７６は、乗客端末４のディスプレイに各種画面を表示させる。例えば表示制御部７６は、決済結果取得部７４によって取得された決済結果を示す画面（後述）を乗客端末４のディスプレイに表示させる。また、表示制御部７６は、運賃決定部７０によって決定された運賃を、乗客２が登録した乗車バス停および降車バス停と共に乗客端末４のディスプレイに表示させる。

【0054】

以上の構成による決済システム１の動作を説明する。
図１２は、決済システム１における処理の流れを示すチャートである。
（乗車前）
乗客２は乗客端末４に乗客アプリをダウンロードしてインストールする（Ｓ２０２）。乗客２は乗客アプリを起動して利用登録する（Ｓ２０４）。乗客端末４は乗客２が入力した情報を決済サーバ１８に送信し、決済サーバ１８は受信した情報を登録する。乗客２は乗客アプリにお気に入りのバス停等を登録する（Ｓ２０６）。

【0055】

乗務員１４は乗務員端末１６に乗務員アプリをダウンロードしてインストールする（Ｓ２０８）。乗務員１４はバスへの乗務前に乗務員アプリにログインする（Ｓ２１０）。この際、乗務員１４は乗務員端末１６に乗務員ＩＤおよびパスワードを入力し、認証する。ログインが成功すると、乗務員１４は、これから乗務するバスの路線を乗務員アプリに登録する（Ｓ２１２）。

【0056】

（乗車時）
乗客２は乗車の際に整理券８を取得する（Ｓ２１４）。乗客２は着席すると乗客端末４で乗客アプリを開いて、自分が乗っているバスの路線および乗車バス停、降車バス停を指定する（Ｓ２１６）。乗客端末４は、ステップＳ２１６で指定された乗降地情報および乗客２の利用者ＩＤを、ＮＦＣの場合はＮＦＣインタフェース３２（ＮＦＣチップ）に書き込むことでＮＦＣ送信可能な状態とし、ＱＲコードの場合はそれらの情報を符号化することでＱＲコードを生成する（Ｓ２１８）。

【0057】

（降車時）
乗客２は降車の際に、整理券８を整理券箱１０に投入する（Ｓ２２０）と共に、ＮＦＣの場合は乗客端末４をバスのＲ／Ｗ１２に近づけるか、ＱＲコードの場合は乗客端末４のディスプレイにＱＲコードを表示させる。ＮＦＣの場合はＲ／Ｗ１２がＮＦＣを介して、乗客端末４のＮＦＣチップに書き込まれていた乗降地情報および利用者ＩＤを乗務員端末１６に送信する。ＱＲコードの場合は乗務員端末１６がカメラを用いて乗客端末４のディスプレイに表示されたＱＲコードを読み取り、復号することで乗降地情報および利用者ＩＤを取得する（Ｓ２２４）。なお、乗務員端末１６のカメラを用いる代わりに、ＱＲコード読み取り専用のカメラをバスに搭載し、当該カメラで読み取った情報を乗務員端末１６に送信する構成としてもよい。

【0058】

乗務員端末１６はステップＳ２２４のＮＦＣタッチ／ＱＲスキャンの結果、乗客２が指定した乗車バス停および降車バス停、利用者ＩＤを取得する（Ｓ２２６）。乗務員端末１６は、ステップＳ２２６で取得された乗車バス停および降車バス停と、ステップＳ２１２で予め登録された路線と、に基づいて、乗客２が払うべき運賃を決定する（Ｓ２２８）。乗務員端末１６は、決済サーバ１８と通信することで、ステップＳ２２８で決定された運賃を決済するための処理を行う（Ｓ２３０）。乗務員端末１６と決済サーバ１８間の通信は、必ずしもリアルタイムである必要はない。乗務員端末１６は、ステップＳ２２６で取得された乗車バス停を基に乗客２によって提示されるべき整理券番号を決定する（Ｓ２３２）。乗務員端末１６は、ステップＳ２３２で決定された整理券番号を含む出力情報を出力する（Ｓ２３４）。

【0059】

乗務員１４は、ステップＳ２３０で乗客２により提出された整理券８を受け取り（Ｓ２２２）、その番号と、ステップＳ２３４で出力された整理券番号と、を照合する（Ｓ２３６）。当該照合では降車バス停の異同も判定されてもよい。照合の結果、番号や降車バス停に相違なければ乗務員１４は何もせず、相違があれば以下の取消処理が行われる。

【0060】

（整理券番号が違う場合）
乗務員１４は乗務員端末１６を操作することで、支払いを取り消すための処理を行う（Ｓ２３８）。ここでは、乗務員１４は乗客２が払うべき正しい運賃を乗務員端末１６に入力する（Ｓ２４０）。乗務員端末１６はステップＳ２４０で入力された運賃の決済を待ち受ける（Ｓ２４２）。乗客２は乗客端末４をＲ／Ｗ１２に近づけるかＱＲコードを乗務員端末１６に読み取らせることで、支払いを取り消す（Ｓ２３８）と同時に再度決済を行う（Ｓ２４４）。
（当該路線に乗客が選択した乗車バス停ＩＤまたは降車バス停ＩＤが存在しない場合）
乗務員１４は乗務員端末１６を操作することで、正当金額での決済を行うための処理を行う。乗務員１４は乗客２が払うべき正しい運賃を乗務員端末１６に入力する（Ｓ２４０）。乗務員端末１６はステップＳ２４０で入力された運賃の決済を待ち受ける（Ｓ２４２）。乗客２は乗客端末４をＲ／Ｗ１２に近づけるかＱＲコードを乗務員端末１６に読み取らせることで、正当金額での決済を行う（Ｓ２４４）。

【0061】

図１３は、乗客端末４のディスプレイに表示されるお気に入り登録画面１００の代表画面図である。お気に入り登録画面１００は、お気に入りとして登録する乗車バス停、降車バス停、路線をそれぞれプルダウン形式で選択できるように構成されている。乗客２がお気に入りを選択した後、登録ボタンをタップすると、お気に入り登録受付部６６は選択内容を取得してお気に入り情報保持部７８に登録する。

【0062】

図１４は、乗客端末４のディスプレイに表示される乗降地選択画面１０２の代表画面図である。乗降地選択画面１０２は、乗客２が、お気に入り情報保持部７８に登録されているお気に入りの乗車バス停・降車バス停・路線のセットのなかから選択できるように構成されている。例えば、図１４の乗降地選択画面１０２において乗客２が「お気に入り１」をタップすると、乗降地指定受付部６８は、乗車バス停「Ａ」、降車バス停「Ｂ」、路線「Ｃ０７」を、乗客２により指定された情報として受け付ける。

【0063】

図１５は、乗客端末４のディスプレイに表示される乗降地直接入力画面１０４の代表画面図である。図１４の乗降地選択画面１０２において、乗客２がお気に入りを選択する代わりに直接入力ボタンをタップすると、乗降地直接入力画面１０４がディスプレイに表示される。乗降地直接入力画面１０４は、乗客２が指定する路線、乗車バス停、降車バス停をそれぞれプルダウン形式で選択できるように構成されている。乗客２が選択した後、登録ボタンをタップすると、乗降地指定受付部６８は選択内容を取得して乗降地情報保持部８０に登録する。

【0064】

図１６は、乗客端末４のディスプレイに表示される乗降地確認画面１０６の代表画面図である。図１４の乗降地選択画面１０２でお気に入りのひとつが選択された場合、または図１５で登録ボタンがタップされた場合、表示制御部７６は乗降地確認画面１０６をディスプレイに表示させる。乗降地確認画面１０６は、選択された乗車バス停・降車バス停・路線および運賃決定部７０によって決定された運賃を表示し、乗客２に確認を求めるよう構成される。乗降地確認画面１０６でやり直しボタンがタップされると、ディスプレイの表示は図１４の乗降地選択画面１０２に戻る。

【0065】

図１７は、乗客端末４のディスプレイに表示される乗降地確定画面１０８の代表画面図である。図１６の乗降地確認画面１０６で確定ボタンがタップされると、表示制御部７６は乗降地確定画面１０８をディスプレイに表示させる。乗降地確定画面１０８は、乗降地確認画面１０６で確認した内容を再掲すると共に、降車時には整理券の提出および乗客端末４をＲ／Ｗ１２に近づけることが必要である旨のテキストを表示する。ＱＲコードを用いる場合は、乗降地確定画面１０８にＱＲコードを表示するかＱＲコードを表示するためのボタンを配置してもよい。

【0066】

図２４は、乗客端末４のディスプレイに表示される直接入力画面３０２の代表画面図である。図１５、図１６、図１７では画面遷移により入力受付→入力内容確認→乗降地登録を行う例を示したが、図２４ではそれらをひとつの画面で行う例を示す。直接入力画面３０２は、バス運行会社の名称等が表示されるヘッダー画像３０４と、路線選択領域３０６と、乗車地選択領域３０８と、降車地選択領域３１０と、運賃計算ボタン３１２と、運賃表示領域３１４と、登録ボタン３１６と、を有する。

【0067】

乗客２はまず路線選択領域３０６で路線を選択し、次いで乗車地選択領域３０８、降車地選択領域３１０で乗車地、降車地を選択する。乗客２が運賃計算ボタン３１２をタップすると、選択された路線、乗車地、降車地で決まる運賃が運賃表示領域３１４に表示される。乗客２が登録ボタン３１６をタップすると、乗客端末４は選択された路線、乗車地、降車地を登録する。

【0068】

図１８は、乗客端末４のディスプレイに表示される決済結果画面１１０の代表画面図である。表示制御部７６は、決済結果取得部７４が取得した決済結果を基に決済結果画面１１０を生成してディスプレイに表示させる。決済結果画面１１０は、乗客２が登録した乗車バス停および降車バス停と、乗務員端末１６に予め登録されていた路線と、乗務員端末１６の運賃決定部４８によって決定された運賃と、決済後の乗客２の口座の残高と、を表示する。

【0069】

図１９は、乗客端末４のディスプレイに表示される別の決済結果画面１１２の代表画面図である。別の決済結果画面１１２は、乗客２により指定された路線と乗務員１４が登録した路線とが異なることにより、乗客端末４のディスプレイに表示された運賃（例えば、図１６の乗降地確認画面１０６の「運賃（予定）」や図１７の乗降地確定画面１０８の「運賃（予定）」）と実際に決済された運賃（例えば、図１９の別の決済結果画面１１２の「運賃」）とが異なる場合、表示された運賃とは異なる額の運賃が決済されたことを示す注意テキスト１１４を含む。

【0070】

乗車バス停や降車バス停が乗客２の申告と実際とで異なる場合は、システムまたは乗務員１４による照合の結果、降車時に正当な金額による再度の決済が行われる。このように乗務員１４による手作業が発生するのは、乗務員１４による正しい乗車バス停、降車バス停の確認およびそれに基づく正しい運賃の入力が必要となるので、やむを得ない。これに対して乗車バス停および降車バス停は乗客２の指定したとおりであるものの、乗客２の指定した路線と実際の路線とが異なる場合は、乗務員端末１６が予め正しい路線を把握しているので、自動で正しい運賃が算出され、決済される。したがって、図１９に示されるような、降車時に乗務員１４の手作業や乗客２の再度の決済を発生させることなく、事後的に正しい運賃を乗客２に知らせる運用が可能となる。

【0071】

図２０は、乗務員端末１６のディスプレイ２８に表示されるバス情報登録画面１１６の代表画面図である。バス情報登録画面１１６は、バスに乗務する乗務員１４の名前およびバスの路線をそれぞれプルダウン形式で選択できるように構成されている。乗務員１４が選択した後、登録ボタンをタップすると、バス情報受付部４０は選択内容を取得してバス情報保持部５８に登録する。乗務員名は名称の代わりにまたはそれに加えてＩＤで特定されてもよい。

【0072】

図２１は、乗務員端末１６のディスプレイ２８に表示される照合画面１１８の代表画面図である。乗客２が乗客端末４をＲ／Ｗ１２に近づけて乗降地情報および利用者ＩＤが乗務員端末１６に送信されると、乗務員端末１６のディスプレイ２８に照合画面１１８が表示される。乗務員１４は照合画面１１８に表示される情報もしくは音声出力される情報と整理券箱１０に投入された整理券８とを照合し、正しい運賃が支払われたかを確認する。

【0073】

出力制御部４６は、出力情報生成部４４によって生成された出力情報に基づいて照合画面１１８を生成する。照合画面１１８は、予め乗務員１４が登録した路線を表示する路線表示領域１２０と、出力情報生成部４４によって特定された整理券番号を表示する整理券番号表示領域１２２と、乗降地取得部４２によって取得された乗降地情報に含まれる降車バス停を表示する降車バス停表示領域１２４と、運賃決定部４８によって決定された運賃を表示する運賃表示領域１２６と、金額手入力ボタン１２８と、を有する。乗務員１４は、整理券番号や降車バス停に相違があると判断した場合、金額手入力ボタン１２８をタップする。そうでなければ何もしない。何もしなければ、次の乗客が乗客端末をＲ／Ｗ１２に近づけることによりその乗客に対応する新たな照合画面が表示される。

【0074】

図２２は、乗務員端末１６のディスプレイ２８に表示される運賃入力画面１３０の代表画面図である。図２１の照合画面１１８において金額手入力ボタン１２８がタップされると、手動入力受付部５６は運賃入力画面１３０を生成してディスプレイ２８に表示させる。運賃入力画面１３０は、乗客２が払うべき正しい運賃を乗務員１４がプルダウン形式で選択もしくは直接入力できるように構成されている。プルダウン内の選択肢は、乗務員１４が予め登録した路線（図２２の運賃入力画面１３０にもこの路線が表示されている）において設定されている運賃で構成される。手動入力受付部５６は、運賃情報保持部６０を参照することで、この選択肢を決定してもよい。乗務員１４が正しい運賃を選択した後、決済待ち受けボタンをタップすると、乗務員端末１６は選択された運賃を決済するための乗客端末４のタッチを待ち受ける状態に遷移する。

【0075】

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

【0076】

本実施の形態に係る決済システム１によると、以下の作用効果が奏される。
（１）現金による運賃収受との比較
今現在、整理券を用いた区間制運賃の後払い方式を採用するバスでは多くの場合、現金による運賃収受が行われている。この方式では、乗務員は投入された整理券、料金表、投入された小銭を目視で確認する必要がある。この作業は乗務員にとって負担であり、人の目視に頼る以上、ある程度の回収漏れや不足のリスクがある。

【0077】

これに対して、本実施の形態に係る決済システム１では運賃の収受はキャッシュレス決済により行われるので、乗務員による小銭の目視、計算の負担を軽減または除去することができる。また、システムが自動的に運賃を算出して決済するので、回収漏れや不足のリスクを軽減または除去することができる。決済システム１では乗務員１４に整理券番号や降車バス停の照合が求められるが、小銭の目視と比較すると乗務員１４の負担は相当小さくなる。

【0078】

また、乗客にとっても、運賃の準備や両替が不要となるので負担が軽減される。決済システム１では乗客２に乗車前または乗車中の乗降地情報の登録が求められるが、運賃の両替や準備と比較すると乗客２の負担は相当小さくなる。さらに、現状では降車時に運賃の両替や準備をする乗客が多く、スムーズな乗り降りの妨げになっていたが、本実施の形態に係る決済システム１では両替も準備も不用となるのでよりスムーズな乗り降りが実現される。

【0079】

（２）整理券を廃した方式との比較
区間制運賃の後払い方式を採用するバスにおいて、整理券を廃し、代わりに携帯端末やＩＣカードに乗車バス停の情報を書き込む方式も考えられる。この方式では、バスに乗車するときに乗車バス停の情報を書き込むためのＲ／Ｗと、バスから降りるときに決済を行うためのＲ／Ｗと、の少なくとも２台のＲ／Ｗをバスに搭載する必要がある。さらに、バス停を自動で判別するための仕組みをシステムに組み込む必要がある。例えば、ＧＰＳ情報からバス停情報を自動検知する、もしくは音声合成システムと接続する、といった開発が必要となる。自動検知の場合は検知ロジックを開発する必要があり、システム接続する場合でも相応に開発規模やコストが高くなり、難易度が上がる。

【0080】

これに対して、本実施の形態に係る決済システム１では、整理券の運用を残す代わりに、バスに搭載するＲ／Ｗは１台でよい。さらに、乗車バス停、降車バス停を乗客２に登録させ、その当否を乗務員１４に判断させるので、バス停を判別するロジックが不要となる。したがって、開発の規模やコストを低く抑えることができる。決済システム１で用いる乗務員端末１６は市販の汎用のタブレット端末などに乗務員アプリをインストールすることにより実現可能であり、専用の端末は不要であるから、これもコスト削減に貢献する。

【0081】

また、バスの路線がＧＰＳ測位不能な地域または地理的制約に起因した低精度のＧＰＳ情報しか得られない地域を通る場合、ＧＰＳ情報からバス停を自動検知する手法の適用は不可能または困難であるところ、本実施の形態に係る決済システム１はＧＰＳ情報を必要としないので、そのような路線のバスにも容易に適用可能である。

【0082】

以上、実施の形態に係る決済システム１の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。

【0083】

実施の形態では、乗降地選択画面１０２にお気に入りの乗降地・路線を提示して乗客２に選ばせる場合を説明したが、これに限られない。例えば、図１０に示されるお気に入り情報保持部７８にある通りにお気に入りデータが登録されているとする。乗客２が乗客アプリを開くと、お気に入り情報保持部７８の通し番号「３」のエントリの乗車バス停「Ａ」、降車バス停「Ｂ」を通過する直近３本程度の時刻表が、行きと帰りの両方表示される。

【0084】

乗客２が降車の際に乗客端末４をＲ／Ｗ１２に近づけると、バスの乗務員端末１６は現在の路線にお気に入りデータの乗車バス停ＩＤと降車バス停ＩＤが存在するかを確認して決済する。乗車バス停ＩＤと降車バス停ＩＤが存在しない場合は、乗務員端末１６は警告音と画面で警告し処理を中断する。路線に乗車バス停ＩＤと降車バス停ＩＤが存在している（例えば、路線「Ｃ０７」）場合は以下の判定を行う。
１．整理券情報保持部６２（図７参照）において、現路線（「Ｃ０７」）の２つのバス停ＩＤ（「Ａ」、「Ｂ」）に対応する整理券番号（「０」、「２１」）を抽出
２．整理券番号の小さい方（「０」）を乗車バス停、大きい方（「２１」）を降車バス停と判定
３．当該路線における運賃（「４７０円」）を運賃情報保持部６０（図６参照）から算定
４．上記判定に基づいて、乗務員アプリが音声および画面で、２つの整理券番号（「０」、「２１」）と運賃を通知。

【0085】

具体的には、路線「Ｃ０７」の場合、降車時のタッチにより、乗務員アプリは「Ａ」を整理券番号０と判定し、「Ｂ」を整理券番号２１と判定。運賃も４７０円と判定する。路線「Ｃ３４」の場合は、「Ａ」を整理券番号２と判定し、「Ｂ」盛岡大学を２３と判定。運賃を４９０円と判定する。

【0086】

実施の形態では、乗務員端末１６が乗客端末４からＮＦＣ／ＱＲコードにより乗降地情報および利用者ＩＤを取得すると、乗務員１４による操作を介することなく、決済要求を決済サーバ１８に送る場合を説明したが、これに限られず、乗務員１４による確認を経てから決済要求を決済サーバ１８に送信する構成としてもよい。例えば、照合画面１１８に確認ボタンをさらに設け、この確認ボタンが乗務員１４によってタップされると決済要求を送信する構成としてもよい。この場合、タッチの都度、乗務員１４が確認ボタンを押さなければならないが、乗車バス停等の相違があった場合に決済サーバ１８で決済が行われる前に修正することができ、決済取消要求が不要となる。したがって、決済サーバ１８側での処理を簡単化することができる。

【0087】

実施の形態では、運賃を決済する場合を説明したが、これに限られず、定期券を利用する場合にも本実施の形態の技術的思想を適用できる。この場合、定期券の区間および有効期限をお気に入りとして登録する。降車の際、定期券の区間および有効期限が乗降地情報として乗務員端末１６に送信され、乗務員端末１６のディスプレイ２８に定期券の区間および有効期限が表示される。乗務員１４は表示された有効期限を確認すると共に、投入された整理券の番号と、表示された定期券の区間と、を照合する。定期券の場合、決済要求に代えて、定期券の利用情報が決済サーバ１８に送信され、決済サーバ１８で決済は行われない。

【0088】

実施の形態では、乗客２が登録した降車バス停が正しいか否かを乗務員１４が判断する場合を説明したが、これに限られず、正しい降車バス停を乗務員端末１６が指定してもよい。この場合、例えば、乗務員端末１６を、乗務員１４が正しい降車バス停を選択可能に構成してもよく、乗客２による乗客アプリへの降車バス停入力が不要となる。

【0089】

図２３は、乗務員端末１６のディスプレイ２８に表示されるホーム画面１３２の代表画面図である。本変形例では、乗務員アプリのホーム画面１３２に、照合画面へのリンク１３４と、現在設定されている降車バス停の表示１３６と、降車バス停を進めるためのボタン１３８と、を有する。乗務員１４は、バス停で停車するか停車せずに通過するたびに、ボタン１３８をタップする。ボタン１３８が一回タップされるごとに、予め登録されているバスの路線にしたがって、降車バス停がひとつずつ進んでいく。例えば、バスの路線においてバス停が「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」、「Ｅ」、「Ｆ」、…と並んでいる場合、バス停「Ｃ」での乗降が終わると乗務員１４はバスを発車させる前にホーム画面１３２に戻ってボタン１３８をタップする。すると、降車バス停の表示１３６が「Ｃ」から「Ｄ」に変わる。次のバス停「Ｄ」では、乗務員端末１６は、乗客端末４から取得される乗車バス停と、予め乗務員端末１６が登録しておいた路線の経路番号と、更新された降車バス停（この場合、「Ｄ」）と、から運賃を決定する。

【0090】

実施の形態では、乗客端末４から乗務員端末１６に乗降地情報および利用者ＩＤを非接触の直接通信を介して送信する場合を説明したが、これに限られない。例えば、乗客端末４は、乗客２が乗客アプリに登録した乗車バス停および降車バス停を利用者ＩＤと共に、ネットワーク２０を介して決済サーバ１８または他の管理サーバに送信してもよい。乗客２が降車する際に乗客端末４をＲ／Ｗ１２に近づけると、ＮＦＣにより乗客端末４からＲ／Ｗ１２に利用者ＩＤが送信される。乗務員端末１６は、Ｒ／Ｗ１２から渡された利用者ＩＤを含む乗降地要求を生成し、ネットワーク２０を介して決済サーバ１８または他の管理サーバに送信する。決済サーバ１８または他の管理サーバは、当該乗降地要求に含まれる利用者ＩＤに対応する乗車バス停および降車バス停を、ネットワーク２０を介して乗務員端末１６に送信する。乗務員端末１６は受信した乗車バス停および降車バス停を用いて運賃の決定、出力情報の生成を行う。決済サーバ１８またはほかの管理サーバがネットワーク２０を介して乗務員端末１６に情報を送信する代わりに、乗客端末４から受信した情報を乗務員端末１６とネットワーク２０を介して、決済サーバ１８に送信し、決済サーバが乗降情報と利用者ＩＤの突合を実施してもよい。この場合、乗客端末４と乗務員端末１６間の通信は乗客２が事前決済済みという情報だけに留めておき、事前決済と実際の乗車利用に差異がある場合は、差額を該当利用者ＩＤに対し請求することが可能となる。

【0091】

実施の形態では、決済サーバ１８で決済を行うサーバ型またはネットワーク型のキャッシュレス決済を用いる場合を説明したが、これに限られず、例えば端末で電子マネーの残高を記録、管理する端末型のキャッシュレス決済に本実施の形態の技術的思想を適用してもよい。この場合、乗務員端末１６は、乗客端末４からＮＦＣを介して乗降地情報を取得すると、決定された運賃を含む決済要求を、決済サーバ１８にネットワーク２０を介して送信する代わりに、ＮＦＣを介して乗客端末４に返す。乗客端末４は、受信した決済要求に含まれる運賃分の金額を、保持している残高から減算することで決済を行う。端末型のキャッシュレス決済の仕組み自体は、公知の端末型電子マネー決済技術を用いて実現されてもよい。

【符号の説明】

【0092】

２ 乗客、 ４ 乗客端末、 ６ 整理券発券機、 ８ 整理券、 １０ 整理券箱、 １２ Ｒ／Ｗ、 １４ 乗務員、 １６ 乗務員端末、 １８ 決済サーバ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】