知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024158829
(43)【公開日】2024-11-08
(54)【発明の名称】運賃収受システムおよびその車載装置
(51)【国際特許分類】
G08G 1/127 20060101AFI20241031BHJP
G06Q 50/40 20240101ALI20241031BHJP
G06Q 20/34 20120101ALI20241031BHJP
【ＦＩ】
G08G1/127 B
G06Q50/30
G06Q20/34
【審査請求】未請求
【請求項の数】5
【出願形態】ＯＬ
(21)【出願番号】P 2023074387
(22)【出願日】2023-04-28
(71)【出願人】
【識別番号】000144544
【氏名又は名称】レシップホールディングス株式会社
(74)【代理人】
【識別番号】100147625
【弁理士】
【氏名又は名称】澤田 高志
(74)【代理人】
【識別番号】100150430
【弁理士】
【氏名又は名称】河野 元
(74)【代理人】
【識別番号】100155099
【弁理士】
【氏名又は名称】永井 裕輔
(74)【代理人】
【識別番号】100190333
【弁理士】
【氏名又は名称】木村 群司
(72)【発明者】
【氏名】岩佐 幸治
【テーマコード（参考）】
5H181
5L020
5L049
5L050
5L055
【Ｆターム（参考）】
5H181AA16
5H181BB04
5H181EE10
5H181FF13
5H181FF25
5H181FF27
5H181FF33
5H181MA22
5H181MA30
5H181MA48
5L020AA66
5L049CC41
5L050CC41
5L055AA66
(57)【要約】
【課題】通信障害が生じた場合においても運賃収受を行い得る運賃収受システムおよびその車載装置を提供する。
【解決手段】運賃収受システムは、車載装置、ＩＣカードおよびサーバ装置を含む。サーバ装置は、車両外に設けられてインターネットに接続されており、バスの利用者を識別する識別情報と、これに関連付けられた運賃バリューと、利用者が当該システムの利用登録時にバスの事業者に提供した担保金の担保金情報と、を記憶する。ＩＣカードは、利用者に所持されて識別情報および担保金情報を有する。車載装置は、利用運賃情報と、ＩＣカードから読み出された識別情報と、を無線通信回線およびインターネットを介してサーバ装置に送信する。
【選択図】図５
【解決手段】運賃収受システムは、車載装置、ＩＣカードおよびサーバ装置を含む。サーバ装置は、車両外に設けられてインターネットに接続されており、バスの利用者を識別する識別情報と、これに関連付けられた運賃バリューと、利用者が当該システムの利用登録時にバスの事業者に提供した担保金の担保金情報と、を記憶する。ＩＣカードは、利用者に所持されて識別情報および担保金情報を有する。車載装置は、利用運賃情報と、ＩＣカードから読み出された識別情報と、を無線通信回線およびインターネットを介してサーバ装置に送信する。
【選択図】図５
【特許請求の範囲】
【請求項1】
交通機関の車両の利用者から利用運賃を収受する運賃収受システムであって、
前記車両外に設けられており前記利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと前記利用者が当該システムの利用登録時に前記交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、
前記利用者に所持されて前記識別情報および前記担保金情報を有する情報担持媒体と、
前記利用運賃の情報または前記利用運賃の算出に要する情報（以下「利用運賃等情報」という）と前記情報担持媒体から読み出された前記識別情報とを無線通信回線を介して前記サーバ装置に送信する車載装置と、を含み、
前記車載装置は、前記サーバ装置に対して送信した、
(1) 前記識別情報および前記利用運賃等情報が前記サーバ装置に受信された場合、前記利用者の乗車または降車を許容する情報を出力し、
(2) 前記識別情報および／または前記利用運賃等情報が前記サーバ装置に受信されない通信障害が発生した場合、前記利用者が所持する前記情報担持媒体から読み出された前記担保金情報に基づいて、(2a)前記利用運賃等情報から得られる前記利用運賃が前記担保金以下であるときには、前記利用者の乗車または降車を許容する情報を出力し、かつ、前記通信障害の解消後、前記サーバ装置に前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を送信し、(2b)前記利用運賃等情報から得られる前記利用運賃が前記担保金を超えるときには、前記利用者に前記利用運賃の現金支払いを要求する情報を出力し、
前記サーバ装置は、前記車載装置から、
(3) 前記識別情報および前記利用運賃等情報を受信した場合、前記利用運賃等情報に基づく前記利用運賃に相当するバリューを前記運賃バリューから減算して収受し、
(4) 前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を受信した場合、(4a)前記利用運賃等情報に基づく前記利用運賃に相当するバリューが前記運賃バリュー以下であるときには、前記運賃バリューから前記利用運賃に相当するバリューを減算し、(4b)前記利用運賃等情報に基づく前記利用運賃に相当するバリューが前記運賃バリューを超えるときには、前記運賃バリューを超える超過分を前記担保金情報に基づく前記担保金の範囲内で負債バリューとして記憶するとともに前記運賃バリューをゼロまたは無価値に変更し、かつ、その後、前記識別情報に関連付けられた前記運賃バリューを用いた前記利用運賃の収受を停止する、ことを特徴とする運賃収受システム。
前記車両外に設けられており前記利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと前記利用者が当該システムの利用登録時に前記交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、
前記利用者に所持されて前記識別情報および前記担保金情報を有する情報担持媒体と、
前記利用運賃の情報または前記利用運賃の算出に要する情報（以下「利用運賃等情報」という）と前記情報担持媒体から読み出された前記識別情報とを無線通信回線を介して前記サーバ装置に送信する車載装置と、を含み、
前記車載装置は、前記サーバ装置に対して送信した、
(1) 前記識別情報および前記利用運賃等情報が前記サーバ装置に受信された場合、前記利用者の乗車または降車を許容する情報を出力し、
(2) 前記識別情報および／または前記利用運賃等情報が前記サーバ装置に受信されない通信障害が発生した場合、前記利用者が所持する前記情報担持媒体から読み出された前記担保金情報に基づいて、(2a)前記利用運賃等情報から得られる前記利用運賃が前記担保金以下であるときには、前記利用者の乗車または降車を許容する情報を出力し、かつ、前記通信障害の解消後、前記サーバ装置に前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を送信し、(2b)前記利用運賃等情報から得られる前記利用運賃が前記担保金を超えるときには、前記利用者に前記利用運賃の現金支払いを要求する情報を出力し、
前記サーバ装置は、前記車載装置から、
(3) 前記識別情報および前記利用運賃等情報を受信した場合、前記利用運賃等情報に基づく前記利用運賃に相当するバリューを前記運賃バリューから減算して収受し、
(4) 前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を受信した場合、(4a)前記利用運賃等情報に基づく前記利用運賃に相当するバリューが前記運賃バリュー以下であるときには、前記運賃バリューから前記利用運賃に相当するバリューを減算し、(4b)前記利用運賃等情報に基づく前記利用運賃に相当するバリューが前記運賃バリューを超えるときには、前記運賃バリューを超える超過分を前記担保金情報に基づく前記担保金の範囲内で負債バリューとして記憶するとともに前記運賃バリューをゼロまたは無価値に変更し、かつ、その後、前記識別情報に関連付けられた前記運賃バリューを用いた前記利用運賃の収受を停止する、ことを特徴とする運賃収受システム。
【請求項2】
前記(4b)において前記利用運賃の収受を停止する対象になった前記運賃バリューに対して前記超過分以上のバリューがチャージされた場合、前記サーバ装置は、当該運賃バリューを用いた前記利用運賃の収受を再開する、ことを特徴とする請求項１に記載の運賃収受システム。
【請求項3】
前記担保金情報は、前記情報担持媒体に代えて、または前記情報担持媒体に加えて、
前記車載装置に記憶されている、ことを特徴とする請求項１または２に記載の運賃収受システム。
前記車載装置に記憶されている、ことを特徴とする請求項１または２に記載の運賃収受システム。
【請求項4】
交通機関の車両の利用者から利用運賃を収受する運賃収受システムに用いられる車載装置であって、
前記運賃収受システムは、前記車両外に設けられており前記利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと前記利用者が当該システムの利用登録時に前記交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、前記利用者に所持されて前記識別情報および前記担保金情報を有する情報担持媒体と、を含み、
前記車載装置は、前記利用運賃の情報または前記利用運賃の算出に要する情報（以下「利用運賃等情報」という）と前記情報担持媒体から読み出された前記識別情報とを無線通信回線を介して前記サーバ装置に送信し、
(1) 前記識別情報および前記利用運賃等情報が前記サーバ装置に受信された場合、前記利用者の乗車または降車を許容する情報を出力し、
(2) 前記識別情報および／または前記利用運賃等情報が前記サーバ装置に受信されない通信障害が発生した場合、前記情報担持媒体から読み出された前記担保金情報に基づいて、(2a)前記利用運賃等情報から得られる前記利用運賃が前記担保金以下であるときには、前記利用者の乗車または降車を許容する情報を出力し、かつ、前記通信障害の解消後、前記サーバ装置に前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を送信し、(2b)前記利用運賃等情報から得られる前記利用運賃が前記担保金を超えるときには、前記利用者に前記利用運賃の現金支払いを要求する情報を出力する、ことを特徴とする車載装置。
前記運賃収受システムは、前記車両外に設けられており前記利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと前記利用者が当該システムの利用登録時に前記交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、前記利用者に所持されて前記識別情報および前記担保金情報を有する情報担持媒体と、を含み、
前記車載装置は、前記利用運賃の情報または前記利用運賃の算出に要する情報（以下「利用運賃等情報」という）と前記情報担持媒体から読み出された前記識別情報とを無線通信回線を介して前記サーバ装置に送信し、
(1) 前記識別情報および前記利用運賃等情報が前記サーバ装置に受信された場合、前記利用者の乗車または降車を許容する情報を出力し、
(2) 前記識別情報および／または前記利用運賃等情報が前記サーバ装置に受信されない通信障害が発生した場合、前記情報担持媒体から読み出された前記担保金情報に基づいて、(2a)前記利用運賃等情報から得られる前記利用運賃が前記担保金以下であるときには、前記利用者の乗車または降車を許容する情報を出力し、かつ、前記通信障害の解消後、前記サーバ装置に前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を送信し、(2b)前記利用運賃等情報から得られる前記利用運賃が前記担保金を超えるときには、前記利用者に前記利用運賃の現金支払いを要求する情報を出力する、ことを特徴とする車載装置。
【請求項5】
前記情報担持媒体に代えて、または前記情報担持媒体に加えて、
前記担保金情報を記憶している、ことを特徴とする請求項４に記載の車載装置。
前記担保金情報を記憶している、ことを特徴とする請求項４に記載の車載装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、交通機関の車両の利用者から利用運賃を収受する運賃収受システムおよびその車載装置に関するものである。なお、交通機関の車両には、路線バス、路面電車、トロリーバス等の乗合バスや鉄道等のほかに、オンデマンド交通やオンデマンドタクシー等も含まれる。
【背景技術】
【0002】
交通系ＩＣカードを利用した運賃計算や運賃決済方式（以下「運賃収受方式」という）として、例えば、下記特許文献１に開示される「運賃精算装置」に関する技術がある。この技術では、ＩＣカードに対する読み出しや書き込みのほかに運賃計算や運賃精算等の情報処理を、交通機関の車両に搭載された運賃精算装置がすべて行う。
【0003】
車両に搭載された装置（以下「車載装置」という）で情報処理の大半を行う運賃収受方式は、下記、非特許文献１に記載されているようにＣＢＴ（Card Based Ticketing）方式と呼ばれている。ＣＢＴ方式では、車載装置による情報処理の負担が大きい。そのため、処理速度の速いハードウェアが必要になることから設備のコスト高の一因になり得る。
【0004】
これに対して、非特許文献１で紹介されているＡＢＴ（Account Based Ticketing）方式は、運賃計算や運賃精算等の情報処理をクラウドサーバで行う運賃収受方式である。そのため、ＡＢＴ方式は車載装置による情報処理の負担が小さい。したがって、車載装置には処理速度の速さが要求され難くなることから設備の低廉化が可能になる。今後、交通機関の車両の運賃収受方式は、ＣＢＴ方式からＡＢＴ方式に移行が進むことが予想される。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開２０１０－４４７３４号公報
【非特許文献】
【0006】
【非特許文献1】“本邦初！ＡＢＴ方式の乗車券システムを商用化する”、[online]、bp-Affairs（運営会社 一般社団法人ビジネス＆パブリック アフェアーズ）、HOME > bp-Aニュース、[令和５年４月２４日検索]、インターネット [https://bp-affairs.com/news/2022/03/20220308-11448.html]
【発明の概要】
【発明が解決しようとする課題】
【0007】
ところで、上記、非特許文献１に紹介されている運賃収受のＡＢＴ方式は、運賃計算や運賃精算等の情報処理をクラウドサーバで行うことから、インターネット等の情報通信ネットワークが安定して機能することが必要になる。例えば、駅構内に設けられる鉄道の自動改札機のように、一所に固定された装置の場合には有線通信回線を利用することにより比較的安定した情報通信が可能である。
【0008】
しかしながら、車両に搭載されて移動する車載装置においては、無線通信回線を利用せざるを得ないことから、通信が不安定になり易い。無線通信回線は、移動場所や通信環境の変動により電波伝播障害や外来ノイズに起因した通信途絶（通信障害）も発生し得る。そのため、停留所や運行経路の一部において無線通信が不安定な場所が存在する場合には車載装置はＡＢＴ方式による運賃収受を行い難いケースが生じ得る。
【0009】
このような無線通信に特有の通信障害による運賃収受の問題は、無線通信回線の基地局を増設する等の無線通信インフラの増強によって解決し得るものの、それにはコストや時間を要することから解決が容易ではない。したがって、交通機関の車両に搭載される車載装置を含めた運賃収受システムにおいては、通信障害が生じた場合における運賃収受に課題が残されている。
【0010】
本発明は、上述した課題を解決するためになされたものであり、通信障害が生じた場合においても運賃収受を行い得る運賃収受システムおよびその車載装置を提供することを目的とする。
【課題を解決するための手段】
【0011】
上記目的を達成するため、特許請求の範囲の請求項１に記載された運賃収受システムは、交通機関の車両の利用者から利用運賃を収受する運賃収受システムであって、前記車両外に設けられており前記利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと前記利用者が当該システムの利用登録時に前記交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、前記利用者に所持されて前記識別情報および前記担保金情報を有する情報担持媒体と、前記利用運賃の情報または前記利用運賃の算出に要する情報（以下、請求項１～３において「利用運賃等情報」という）と前記情報担持媒体から読み出された前記識別情報とを無線通信回線を介して前記サーバ装置に送信する車載装置と、を含み、前記車載装置は、前記サーバ装置に対して送信した、(1) 前記識別情報および前記利用運賃等情報が前記サーバ装置に受信された場合、前記利用者の乗車または降車を許容する情報を出力し、(2) 前記識別情報および／または前記利用運賃等情報が前記サーバ装置に受信されない通信障害が発生した場合、前記利用者が所持する前記情報担持媒体から読み出された前記担保金情報に基づいて、(2a)前記利用運賃等情報から得られる前記利用運賃が前記担保金以下であるときには、前記利用者の乗車または降車を許容する情報を出力し、かつ、前記通信障害の解消後、前記サーバ装置に前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を送信し、(2b)前記利用運賃等情報から得られる前記利用運賃が前記担保金を超えるときには、前記利用者に前記利用運賃の現金支払いを要求する情報を出力し、前記サーバ装置は、前記車載装置から、(3) 前記識別情報および前記利用運賃等情報を受信した場合、前記利用運賃等情報に基づく前記利用運賃に相当するバリューを前記運賃バリューから減算して収受し、(4) 前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を受信した場合、(4a)前記利用運賃等情報に基づく前記利用運賃に相当するバリューが前記運賃バリュー以下であるときには、前記運賃バリューから前記利用運賃に相当するバリューを減算し、(4b)前記利用運賃等情報に基づく前記利用運賃に相当するバリューが前記運賃バリューを超えるときには、前記運賃バリューを超える超過分を前記担保金情報に基づく前記担保金の範囲内で負債バリューとして記憶するとともに前記運賃バリューをゼロまたは無価値に変更し、かつ、その後、前記識別情報に関連付けられた前記運賃バリューを用いた前記利用運賃の収受を停止する、ことを技術的特徴とする。
【0012】
なお、上記の「前記利用運賃等情報から得られる前記利用運賃」には、「利用運賃の情報」が表す利用運賃と、「利用運賃の算出に要する情報」に基づいて算出される利用運賃と、の両方が含まれる。また、上記の「運賃バリュー」および「バリュー」は、当該車両の利用運賃を精算することが可能な価値のことである。さらに、上記の「負債バリュー」は、当該交通機関の事業者から利用者が借りている価値であり借り主である当該利用者が返済義務（債務）を負うものである。
【0013】
請求項１に記載の運賃収受システムの発明では、当該システムは、サーバ装置と情報担持媒体と車載装置を含む。サーバ装置は、車両外に設けられており、交通機関の車両の利用者を識別する識別情報と、この識別情報に関連付けられた運賃バリューと、利用者が当該システムの利用登録時に交通機関の事業者に提供した担保金の担保金情報と、を記憶する。情報担持媒体は、利用者に所持されて識別情報および担保金情報を有する。車載装置は、利用運賃等情報（利用運賃の情報または利用運賃の算出に要する情報）と、情報担持媒体から読み出された識別情報と、を無線通信回線を介してサーバ装置に送信する。車載装置は、サーバ装置に対して送信した、(1) 識別情報および利用運賃等情報がサーバ装置に受信された場合、利用者の乗車または降車を許容する情報を出力する（通信正常時）。そして、サーバ装置は、車載装置から、(3) 識別情報および利用運賃等情報を受信した場合、利用運賃等情報に基づく利用運賃に相当するバリューを運賃バリューから減算して収受する。
【0014】
これに対して、サーバ装置に送信した、(2) 識別情報および／または利用運賃等情報、即ち識別情報および利用運賃等情報の両方または一方がサーバ装置に受信されない通信障害が発生した場合には、車載装置は、利用者が所持する情報担持媒体から読み出された担保金情報に基づいて次のいずれかを行う（通信障害時）。(2a)利用運賃等情報から得られる利用運賃が担保金以下であるときには、利用者の乗車または降車を許容する情報を出力し、かつ、通信障害の解消後、サーバ装置に通信障害の発生情報、識別情報および利用運賃等情報を送信する。また、(2b)利用運賃等情報から得られる利用運賃が担保金を超えるときには、利用者に利用運賃の現金支払いを要求する情報を出力する。
【0015】
これにより、通信障害が発生して車載装置とサーバ装置が情報通信を行うことができない事態が生じても（上記(2)）、交通機関の車両の利用者は、利用運賃が担保金以下である場合には、利用者の乗車や降車を許容する情報が出力されるので（上記(2a)）、運賃前払い方式の場合には乗車することが可能になり、また運賃後払い方式の場合には降車することが可能になる。利用運賃が担保金を超えるときには、利用者に利用運賃の現金支払いを要求する情報が出力されるので（上記(2b)）、当該利用者は利用運賃を現金で支払うことにより乗車したり降車したりすることが可能になる。
【0016】
そして、車載装置が上記(2a)を行い、サーバ装置が、(4) 通信障害の発生情報、識別情報および利用運賃等情報を受信した場合において、(4a)利用運賃等情報に基づく利用運賃に相当するバリューが運賃バリュー以下であるときには、運賃バリューから利用運賃に相当するバリューを減算する。また、(4b)利用運賃等情報に基づく利用運賃に相当するバリューが運賃バリューを超えるときには、運賃バリューを超える超過分を担保金情報に基づく担保金の範囲内で負債バリューとして記憶するとともに運賃バリューをゼロまたは無価値に変更し、かつ、その後、識別情報に関連付けられた運賃バリューを用いた利用運賃の収受を停止する。
【0017】
これにより、交通機関の事業者は、サーバ装置が通信障害の発生情報、識別情報および利用運賃等情報を車載装置から受信した場合においては（上記(4)）、利用運賃に相当するバリューが運賃バリュー以下であるときには、運賃バリューから利用運賃に相当するバリューが減算されるので（上記(4a)）、事後的に利用運賃を運賃バリューから回収することが可能になる。利用運賃に相当するバリューが運賃バリューを超えるときには、運賃バリューを超える超過分は担保金の範囲内で負債バリューとしてサーバ装置に記憶されるとともに運賃バリューはゼロまたは無価値に変更され（上記(4b)）、その後、当該運賃バリューを用いた利用運賃の収受が停止される（上記(4b)）。負債バリューは、運賃バリューを超える超過分であり担保金の範囲内で当該事業者が立て替える「立替えバリュー」でもある。そのため、当該超過分を担保金の範囲内で当該事業者は負債バリューの支払い債権を得ることが可能になり、利用者には当該超過分の返済義務を負わせることが可能になる。また利用者は、当該運賃バリューを用いた利用運賃の支払いができなくなるため、情報担持媒体を用いた当該交通機関の車両の利用ができなくなる。例えば、利用者が当該システムの登録時に事業者に提供した担保金から、当該システムの解約時に当該超過分を差し引いて返金することにより、当該超過分の返済義務（債務）を当該利用者に履行させることが可能になる。
【0018】
また、特許請求の範囲の請求項２に記載された運賃収受システムは、請求項１に記載の運賃収受システムにおいて、前記(4b)において前記利用運賃の収受を停止する対象になった前記運賃バリューに対して前記超過分以上のバリューがチャージされた場合、前記サーバ装置は、当該運賃バリューを用いた前記利用運賃の収受を再開する、ことを技術的特徴とする。
【0019】
請求項２に記載の運賃収受システムの発明では、(4b)において利用運賃の収受を停止する対象になった運賃バリューに対して、利用者が超過分以上のバリューをチャージした場合には、サーバ装置は、記憶している負債バリュー（運賃バリューを超える超過分であり担保金の範囲内で立て替え分）を、チャージされた運賃バリューから減算することにより、当該超過分の返済義務（債務）を当該利用者に履行させることが可能になる。また、このような返済義務（債務）の履行により負債バリューの支払い債権が消滅することから、当該運賃バリューを用いた利用運賃の収受を再開することによって、当該利用者は、当該運賃バリューを用いた利用運賃の支払いが可能になる。これにより、情報担持媒体を用いた当該交通機関の車両の利用ができなくなった利用者は、超過分以上のバリューを運賃バリューにチャージすることによって、再び情報担持媒体を用いた当該車両の利用が可能になる。そのため、運賃バリューのチャージを促すことが可能になり、利用者による当該超過分の返済義務（債務）の履行を促進させることができる。
【0020】
さらに、特許請求の範囲の請求項３に記載された運賃収受システムは、請求項１または２に記載の運賃収受システムにおいて、前記担保金情報は、前記情報担持媒体に代えて、または前記情報担持媒体に加えて、前記車載装置に記憶されている、ことを技術的特徴とする。
【0021】
請求項３に記載の運賃収受システムの発明では、担保金情報は、情報担持媒体に代えて車載装置に記憶されていたり、情報担持媒体に加えて車載装置に記憶されていたりする。これにより、情報担持媒体に代えて担保金情報が車載装置に記憶されている場合には、情報担持媒体は担保金情報を担持する必要がないので、例えば、担持可能な情報が少ない一次元バーコードを用いて識別情報を表示させることが可能になる。また、担保金情報は車載装置に記憶されるので、担保金情報の改ざんを防止することも可能になる。また、情報担持媒体に加えて車載装置にも記憶されている場合には、これらの両方に担保金情報が記憶されて担保金情報の記憶を冗長構成にするので、いずれか一方の担保金情報が壊れた場合においても残りの他方の担保金情報を用いることが可能になる。
【0022】
上記目的を達成するため、特許請求の範囲の請求項４に記載された車載装置は、交通機関の車両の利用者から利用運賃を収受する運賃収受システムに用いられる車載装置であって、前記運賃収受システムは、前記車両外に設けられており前記利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと前記利用者が当該システムの利用登録時に前記交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、前記利用者に所持されて前記識別情報および前記担保金情報を有する情報担持媒体と、を含み、前記車載装置は、前記利用運賃の情報または前記利用運賃の算出に要する情報（以下、請求項４，５において「利用運賃等情報」という）と前記情報担持媒体から読み出された前記識別情報とを無線通信回線を介して前記サーバ装置に送信し、(1) 前記識別情報および前記利用運賃等情報が前記サーバ装置に受信された場合、前記利用者の乗車または降車を許容する情報を出力し、(2) 前記識別情報および／または前記利用運賃等情報が前記サーバ装置に受信されない通信障害が発生した場合、前記情報担持媒体から読み出された前記担保金情報に基づいて、(2a)前記利用運賃等情報から得られる前記利用運賃が前記担保金以下であるときには、前記利用者の乗車または降車を許容する情報を出力し、かつ、前記通信障害の解消後、前記サーバ装置に前記通信障害の発生情報、前記識別情報および前記利用運賃等情報を送信し、(2b)前記利用運賃等情報から得られる前記利用運賃が前記担保金を超えるときには、前記利用者に前記利用運賃の現金支払いを要求する情報を出力する、ことを技術的特徴とする。なお、「前記利用運賃等情報から得られる前記利用運賃」には、「利用運賃の情報」が表す利用運賃と、「利用運賃の算出に要する情報」に基づいて算出される利用運賃と、の両方が含まれる。また、「運賃バリュー」は、当該車両の利用運賃を精算することが可能な価値のことである。
【0023】
請求項４に記載の車載装置の発明では、当該装置は、交通機関の車両の利用者から利用運賃を収受する運賃収受システムに用いられる。当該運賃収受システムは、車両外に設けられており利用者を識別する識別情報とこの識別情報に関連付けられた運賃バリューと利用者が当該システムの利用登録時に交通機関の事業者に提供した担保金の担保金情報とを記憶するサーバ装置と、利用者に所持されて識別情報および担保金情報を有する情報担持媒体と、を含む。車載装置は、利用運賃の情報または利用運賃の算出に要する情報（以下、請求項４，５において「利用運賃等情報」という）と情報担持媒体から読み出された識別情報とを無線通信回線を介してサーバ装置に送信する。
【0024】
そして、車載装置は、(1) 識別情報および利用運賃等情報がサーバ装置に受信された場合、利用者の乗車または降車を許容する情報を出力する（通信正常時）。また、(2) 識別情報および／または利用運賃等情報、即ち識別情報および利用運賃等情報の両方または一方がサーバ装置に受信されない通信障害が発生した場合、情報担持媒体から読み出された担保金情報に基づいて次のいずれかを行う（通信障害時）。(2a)利用運賃等情報から得られる利用運賃が担保金以下であるときには、利用者の乗車または降車を許容する情報を出力し、かつ、通信障害の解消後、サーバ装置に通信障害の発生情報、識別情報および利用運賃等情報を送信する。また、(2b)利用運賃等情報から得られる利用運賃が担保金を超えるときには、利用者に利用運賃の現金支払いを要求する情報を出力する。
【0025】
これにより、通信障害が発生して車載装置とサーバ装置が情報通信を行うことができない事態が生じても（上記(2)）、交通機関の車両の利用者は、利用運賃が担保金以下である場合には、利用者の乗車や降車を許容する情報を出力されるので（上記(2a)）、運賃前払い方式の場合に乗車することが可能になり、また運賃後払い方式の場合には降車することが可能になる。そして、通信障害の解消後、車載装置からサーバ装置に対して、通信障害の発生情報、識別情報および利用運賃等情報が送信されるので、サーバ装置は、通信障害が発生した情報と、その通信障害により当該サーバ装置が受信することができなかった識別情報および利用運賃等情報とを、得ることが可能になる。例えば、交通機関の事業者は、これらの情報に基づいて、事後的に利用運賃を運賃バリューから回収したり、利用運賃が運賃バリューを超えるときにはその超過分を担保金の範囲内で当該事業者は負債バリューの支払い債権を得たり、することが可能になる。これに対して、利用運賃が担保金を超えるときには、利用者に利用運賃の現金支払いを要求する情報が出力されるので（上記(2b)）、当該利用者は利用運賃を現金で支払うことにより乗車したり降車したりすることが可能になる。なお、「負債バリュー」は、当該交通機関の事業者から利用者が借りている価値であり借り主である当該利用者が返済義務（債務）を負うものである。
【0026】
また、特許請求の範囲の請求項５に記載された車載装置は、請求項４に記載の車載装置において、前記情報担持媒体に代えて、または前記情報担持媒体に加えて、前記担保金情報を記憶している、ことを技術的特徴とする。
【0027】
請求項５に記載の車載装置の発明では、担保金情報は、情報担持媒体に代えて車載装置に記憶されていたり、情報担持媒体に加えて車載装置に記憶されていたりする。これにより、情報担持媒体に代えて担保金情報が車載装置に記憶されている場合には、情報担持媒体は担保金情報を担持する必要がないので、例えば、担持可能な情報が少ない一次元バーコードを用いて識別情報を表示させることが可能になる。また、担保金情報は車載装置に記憶されるので、担保金情報の改ざんを防止することも可能になる。また、情報担持媒体に加えて車載装置にも記憶されている場合には、これらの両方に担保金情報が記憶されて担保金情報の記憶を冗長構成にするので、いずれか一方の担保金情報が壊れた場合においても残りの他方の担保金情報を用いることが可能になる。
【発明の効果】
【0028】
本発明の運賃収受システムでは、通信障害が発生して車載装置とサーバ装置が情報通信を行うことができない事態が生じても、交通機関の車両の利用者は、利用運賃が担保金以下である場合には、乗車や降車することが可能になる。利用運賃が担保金を超えるときには、当該利用者は利用運賃を現金で支払うことにより乗車や降車することが可能になる。また、交通機関の事業者は、利用運賃が運賃バリュー以下であるときには、事後的に利用運賃を運賃バリューから回収することが可能になる。したがって、通信障害が生じた場合においても運賃収受を行うことができる。
【0029】
本発明の車載装置では、通信障害が発生して車載装置とサーバ装置が情報通信を行うことができない事態が生じても、交通機関の車両の利用者は、利用運賃が担保金以下である場合には、乗車や降車することが可能になる。サーバ装置は、通信障害が発生した情報と、その通信障害により当該サーバ装置が受信することができなかった識別情報および利用運賃等情報とを、得ることが可能になる。例えば、交通機関の事業者は、これらの情報に基づいて、事後的に利用運賃を運賃バリューから回収したり、利用運賃が運賃バリューを超えるときにはその超過分を担保金の範囲内で当該事業者は負債バリューの支払い債権を得たり、することが可能になる。これに対して、利用運賃が担保金を超えるときには、当該利用者は利用運賃を現金で支払うことにより乗車や降車することが可能になる。したがって、通信障害が生じた場合においても運賃収受を行うことができる。
【図面の簡単な説明】
【0030】
【図1】本発明の一実施形態に係る運賃収受システムの構成例を示す説明図である。
【図2】本実施形態の運賃収受システムが運賃後払い方式の交通機関に適用される場合において、利用者が所持するＩＣカード、車載装置（ホスト装置、乗車時端末、降車時端末）およびサーバ装置により実行される各処理の一連の流れを示すシーケンス図である。
【図3】本実施形態の運賃収受システムを構成する車載装置のホスト装置により実行される運賃収受処理の流れを示すフローチャートである。
【図6】本実施形態の運賃収受システムを構成する車載装置の乗車時端末（または降車時端末）により実行される乗車時読取り等処理（または降車時読取り等処理）の流れを示すフローチャートである。
【図7】本実施形態の運賃収受システムを構成するサーバ装置により実行される運賃決済処理の流れを示すフローチャートである。
【図10】車載装置のホスト装置により実行されるリカバリ処理の流れを示すフローチャートである。
【図11】本実施形態の運賃収受システムが運賃前払い方式の交通機関に適用される場合において、利用者が所持するＩＣカード、車載装置（ホスト装置、乗車時端末、降車時端末）およびサーバ装置により実行される各処理の一連の流れを示すシーケンス図である。
【発明を実施するための形態】
【0031】
以下、本発明の運賃収受システムおよびその車載装置の実施形態について図を参照して説明する。
【0032】
本発明の運賃収受システムの一実施形態は、図１に示すように、路線バス（以下「バス」という）９０を利用する乗客（以下「利用者」という）から利用運賃を収受する運賃収受システム５であり、利用者が情報担持媒体としてＩＣカード５０を所持していることを前提とするものである。利用者のＩＣカード５０には、後述する識別情報ＩＤや担保金情報ＣＭが保持（担持）されている。
【0033】
本実施形態のバス９０は、ワンマン運行方式であり、停留所ＢＳで利用者が後方の乗車口９１から乗車した後、前方の降車口９３から降車する際に利用運賃を支払う「後乗り前降り後払い方式」を採用している。「後乗り前降り後払い方式」は、運賃後払い方式の一態様であり、典型的には、距離に応じて金額が増加する運賃体系を採る。そのため、利用運賃の取得には、例えば、前述した特許文献１の図４に開示されているような運賃三角表データが用いられる。
【0034】
このバス９０には、降車口９３付近に利用者が現金やＩＣカードで利用運賃の支払いを行うことが可能な運賃箱が設けられている。本実施形態では、この運賃箱がホスト装置４０の役割を果たす。ホスト装置４０は、バス９０に搭載される機器装置であれば、このような運賃箱のほかに、例えば、利用者に乗車区間に対応した運賃を表示する運賃表示器、次の停留所名等を車内に放送する車内放送装置や、車外に向けて当該バス９０の行き先等を表示する行先表示装置の操作盤等の車載機器でもよい。
【0035】
運賃収受システム５は、主に、車載装置１０、ＩＣカード５０、サーバ装置６０により構成されており、さらに車載装置１０は、乗車時端末２０、降車時端末３０およびホスト装置４０により構成されている。これらのうち、車載装置１０はバス９０に搭載されており、ＩＣカード５０は利用者が所持している。サーバ装置６０は、例えば、クラウド（インターネットＮ）上に存在している。
【0036】
インターネットＮは、データを伝送する情報通信回線網の一例であり、インターネットプロトコルを使用してコンピュータを相互接続するコンピュータネットワークである。インターネットＮには、移動体通信事業者（ＭＮＯ）が運用管理する基地局８０や、ＩＳＰ（Internet Service Provider）が接続されており、これらや基地局８０の無線通信回線８５を経由して、バス９０に搭載されたホスト装置４０がインターネットＮに接続される。なお、ホスト装置４０とサーバ装置６０の間でデータ通信可能であれば、インターネットＮ以外の情報通信回線網（例えば、専用線やＶＰＮ等）でもよい。また、有線通信回線に限られることなく無線通信回線でもよい。
【0037】
乗車時端末２０は、主に、制御ユニット２１、読取りユニット２３、表示ユニット２５、有線通信ユニット２７等により構成されており、本実施形態では、例えば、バス９０の乗車口９１付近に設けられる握り棒等に取り付けられている。
【0038】
制御ユニット２１は、ＭＰＵ、メモリ（ＤＲＡＭ、ＲＯＭ）、インタフェース等により構成されるコントローラである。本実施形態では、制御ユニット２１には、読取りユニット２３や有線通信ユニット２７等が接続されている。ＲＯＭには、これらのユニット２５，２７をＭＰＵが制御可能に構成される所定のシステムプログラムや、後述する乗車時読取り等処理２００をＭＰＵが実行可能に構成される乗車時読取り等処理プログラム等が格納されている。
【0039】
読取りユニット２３は、例えばＩＣカード５０に保持されたデータ（識別情報ＩＤ等）を読み取り可能なＩＣカードリーダである。本実施形態では、後述するように、例えば、交通系ＩＣカードをＩＣカード５０として使用するため、読取りユニット２３はそれに対応した非接触式タイプのＩＣカードリーダである。なお、交通系ＩＣカードは、データの読み取りに加えて書き込みも可能に構成されているが、後述する識別情報ＩＤおよび担保金情報ＣＭは、ＩＣカード５０に一度記憶（保存）された後は、乗車時端末２０では書き換え等の更新は行われない。そのため、本実施形態では、読取りユニット２３はデータ、つまり識別情報ＩＤおよび担保金情報ＣＭの読み取りだけを行う。
【0040】
表示ユニット２５は、表示デバイスとして液晶表示パネルを備えたディスプレィ装置であり、制御ユニット２１に対して、例えば、液晶映像パラレルインタフェース等を介して接続されている。本実施例では、利用者に対して乗車の可否を視覚的に明示可能な情報を表示したり所定のメッセージを表示したりする。表示ユニット２５には、図略の音響デバイスが内蔵されており、本実施形態では、聴覚的に乗車可否のイメージさせる効果音を出力し得るように構成されている。
【0041】
有線通信ユニット２７は、有線通信回線１５を介して制御ユニット２１がホスト装置４０とデータ通信可能に構成されるシリアル通信装置である。本実施形態では、ホスト装置４０、乗車時端末２０、降車時端末３０等の間をマルチドロップで接続可能なRS-458に準拠したものを使用している。これらの接続は、例えば、カレントループやRS-422に準拠したものや、Ethernetに準拠したＬＡＮを用いてもよい。
【0042】
本実施形態では、例えば、有線通信ユニット２７は、ホスト装置４０から送出されるポーリング信号に呼応してデータを送出する。即ち、読取りユニット２３により読み取られた識別情報ＩＤおよび担保金情報ＣＭは、ホスト装置４０から自装置宛のポーリング信号が届くとそれに応答して当該ホスト装置４０に送出される。そのため、ホスト装置４０は、送られてきた識別情報ＩＤおよび担保金情報ＣＭが乗車時端末２０から送出されたものであることを把握することが可能である。
【0043】
なお、制御ユニット２１、読取りユニット２３および有線通信ユニット２７には、ハウジング内に設けられる図略の電源ユニットからそれぞれの駆動電力が供給されている。そのため、図１には図示されていないが、乗車時端末２０には電源ラインのワイヤハーネスが接続されている。また、有線通信回線１５は、Bluetooth（登録商標）やZigBee（登録商標）等の無線規格に準拠した無線通信回線に代えてもよい。この場合、通信ユニット２７は、Bluetooth（登録商標）やZigBee（登録商標）等に対応したものに置き換える。
【0044】
降車時端末３０は、例えば、バス９０の降車口９３付近に設けられる運賃箱に隣接して取り付けられており、前述の乗車時端末２０と同様にハードウェアが構成されている。即ち、降車時端末３０は、主に、制御ユニット３１、読取りユニット３３、表示ユニット３５、有線通信ユニット３７等により構成されており、前述した乗車時端末２０の、制御ユニット２１、読取りユニット２３、表示ユニット２５、有線通信ユニット２７にそれぞれ対応する。そのため、ここでは制御ユニット３１等の構成や接続関係の説明を省略する。
【0045】
ホスト装置４０は、本実施形態では運賃箱がこれに相当する。そのため、制御ユニット４１は運賃箱の制御ユニットが、また有線通信ユニット４７は運賃箱の通信ユニットが、それぞれその役割を担う。なお、ホスト装置４０は、このように既存の運賃箱等を用いることなく、ホスト装置４０を別個に設けてもよい。
【0046】
制御ユニット４１は、運賃箱に設けられている運賃収受機構の駆動ユニット、運賃三角表データ等が書き込まれたデータカセット、ＩＣカードリーダライタ、ディスプレィ等の各種ユニット４６や、有線通信ユニット４７、無線通信ユニット４８等を制御するコントローラであり、ＭＰＵ４２、メモリ４３、入出力インタフェース４４、図略の時計ユニット等から構成されている。ＭＰＵ４２は、各種ユニット４６等を制御する演算処理装置であり、システムバス４５等を介して、メモリ４３や入出力インタフェース４４等と接続されている。
【0047】
なお、図示されていないが、バス９０が停留所ＢＳを発車する都度、乗務員（運転士）が手動で操作する押しボタン（以下「停留所送りボタン」という）が運転席に設けられている。本実施形態では、この停留所送りボタンから出力される停留所送り信号（歩進信号）がホスト装置４０に入力される。この停留所送り信号は、運賃表示器、車内放送装置、運賃箱等の車載機器の制御を次に停車する停留所ごとに進めるトリガ信号であり、これらの機器にも入力される。本実施形態では、ホスト装置４０は、この停留所送り信号が入力されるごとに、乗車時端末２０および降車時端末３０に対して停留所連番号ＢＳ＃を１つ進める指令信号を送出する。
【0048】
メモリ４３は、半導体記憶装置であり、ＭＰＵ４２が使用する主記憶空間を構成するものである。本実施形態では、プログラム領域を担うＲＯＭとワーク領域やデータ領域に割り当てられるＤＲＡＭとにより構成されている。本実施形態では、ＲＯＭには、各種ユニット４６を制御するシステムプログラムや、後述する運賃収受処理１００やリカバリ処理４００を可能にする各種の制御プログラムが格納されている。
【0049】
入出力インタフェース４４は、制御ユニット４１の周辺装置に対して、シリアルやパラレルのデータのやり取りを仲介する入出力インタフェース装置である。本実施形態では、各種ユニット４６や有線通信ユニット４７、無線通信ユニット４８等と接続可能に構成されている。入出力インタフェース４４は、各種ユニット４６を駆動するドライバ回路を備えている場合もある。
【0050】
通信ユニット４７は、前述した乗車時端末２０の有線通信ユニット２７と同様に構成されているので、ここでは説明を省略する。無線通信ユニット４８は、移動体通信事業者（ＭＮＯ）により運用される、例えば、８００ＭHz帯や１.５ＧHz帯の無線通信回線８５を介してデータ通信や音声通信可能に構成されている。本実施形態では、ホスト装置４０は、無線通信回線８５やＩＳＰ（Internet Service Provider）を経由してインターネットＮに接続される。
【0051】
ＩＣカード５０は、例えば交通系ＩＣカードであり、FeliCa（登録商標）の規格に準拠したＩＣチップや電磁誘導コイルが内蔵された非接触式タイプである。ＩＣチップは、制御ユニットや半導体メモリを備えており、近距離無線通信を介して取得された、利用者の基本情報（氏名、電話番号等）、識別情報ＩＤや担保金情報ＣＭを記憶している。本実施形態では、これらの情報は、バス９０の運行事業者の営業所等において、利用者が本運賃収受システム５の利用登録を行う際にＩＣカード５０に書き込まれて記憶（保存）されるが、その後は、同営業所等にて基本情報や担保金の金額が変更される等の変更が行われる場合以外は、書き換え等の更新は行われない。したがって、ＩＣカード５０は、乗車時端末２０では書き換え等の更新は行われない。
【0052】
サーバ装置６０は、例えば、インターネットＮに接続されたクラウドサーバである。クラウドサーバは、インターネットＮ上に分散して設けられる複数のサーバ装置（物理サーバ）を１つの仮想サーバとして、クラウドサービス提供事業者が提供するクラウドコンピューティングの１つである。本実施形態では、サーバ装置６０は、管理機能と決済機能を有し後述する運賃決済処理５００を行う。これらの機能は、例えば、ＩａａＳ（Infrastructure as a Service）やＰａａＳ（Platform as a Service）により提供される。
【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】
後述するように、サーバ装置６０では、車載側降車時処理（Ｓ１５０）による送信データＴＸｂを受信すると、運賃決済処理５００による情報処理の結果として、決済完了情報、ＩＤ未登録情報や利用停止中情報を当該ホスト装置４０に対して送信する（図２；ＲＸｂ、図９(A)；Ｓ５７５、図７；Ｓ５１３）。これに対して、送信データＴＸｃ，ＴＸｄのように、受信できないとき（図２；×印付きの破線矢印）には何も送信しない。そのため、ホスト装置４０では、送信データＴＸｂ等を送信した後、サーバ装置６０から決済完了情報等の受信データＲＸｂを受信したか否か、つまりサーバ装置６０が送信データＴＸｂを受信したか否かを判定する処理が行われる。
【0088】
そして、送信データＴＸｃ，ＴＸｄのように所定時間を経過してもサーバ装置６０から決済完了情報等を受信できない場合には（Ｓ１５７；Ｎｏ）、ステップＳ１５５に戻って送信データＴＸｂの再送信を行い、所定のタイムアウト時間が経過するまでこの再送信を繰り返す。送信データＴＸｃのようにタイムアウト時間が経過する前に受信完了情報等を受信できた場合には（Ｓ１５７；Ｙｅｓ）、ステップＳ１５９による利用停止中判定処理に移行する。一方、送信データＴＸｄのようにタイムアウト時間が経過した場合には（Ｓ１５７；ＮＡ）、無線通信回線８５において通信障害が発生している可能性が高いことから、ステップＳ１６３による降車時送信エラーフラグ設定処理に移行する。
【0089】
ステップＳ１６３の降車時送信エラーフラグ設定処理は、送信データＴＸｄのようにホスト装置４０からサーバ装置６０に送信データ（ＩＣカード５０から読み取られた識別情報等ＩＤａ／ＣＭａ）が通信障害によりサーバ装置６０に受信されていないと推定されること、換言すれば送信を失敗したことを、降車時送信エラーフラグをオンに設定して明示するものである。このエラーフラグのオン情報は、ステップＳ１６９によりホスト装置４０のメモリ４３（ＤＲＡＭ）に記憶されて後述するリカバリ処理４００において読み出されて使用される。
【0090】
サーバ装置６０に対してＩＣカード５０から読み取られ識別情報等ＩＤａ／ＣＭａが送信できなかった場合には（Ｓ１５７；Ｎｏ）、現時点においてはサーバ装置６０による利用運賃Ｘの決済処理を行うことができない。そのため、本実施形態では、ステップＳ１６５による判定処理を行う。即ち、この判定処理では、ステップＳ１５１により算出された利用者Ｍａの利用運賃Ｘが、ＩＣカード５０から降車時端末３０により読み取られた担保金情報ＣＭａによる担保金Ｙ（の金額）以下（利用運賃Ｘ≦担保金Ｙ）であるか否かを判定する。
【0091】
そして、利用運賃Ｘが担保金Ｙ以下である場合には（Ｓ１６５；Ｙｅｓ）、当該識別情報ＩＤａに関連付けられてサーバ装置６０により管理されている運賃バリューＶ（利用者Ｍａが有する運賃バリュー）が利用運賃Ｘに相当する運賃バリューよりも小さいときにも（Ｖ＜Ｘ）、当該利用運賃Ｘが運賃バリューＶを超える超過分（Ｘ－Ｖ）を担保金Ｙにより補填し得る。利用運賃Ｘが担保金Ｙ以下である場合には（Ｘ≦Ｙ）、超過分（Ｘ－Ｖ）は必ず担保金Ｙよりも小さくなる（(Ｘ－Ｖ)＜Ｙ）からである。したがって、この場合には（Ｓ１６５；Ｙｅｓ）、当該利用者の降車を許容する情報ＭＳｂをステップＳ１６７に移行して降車時端末３０に出力する。
【0092】
これに対して、利用運賃Ｘが担保金Ｙ以下でない場合、つまり利用運賃Ｘが担保金Ｙを超える場合には（Ｓ１６５；Ｎｏ）、その超過分が利用者Ｍａの有する運賃バリューＶよりも大きいときには、当該利用運賃Ｘが運賃バリューＶを超える超過分を担保金Ｙにより補填することができない。利用運賃Ｘが担保金Ｙを超える場合には（Ｘ＞Ｙ）、超過分（Ｘ－Ｖ）が担保金Ｙを上回る可能性がある（(Ｘ－Ｖ)＞Ｙ）からである。したがって、この場合には（Ｓ１６５；Ｎｏ）、ステップＳ１６１に現金決済情報出力処理を移行し当該利用者Ｍａに対して利用運賃Ｘを現金で支払う必要があることを明示する情報ＭＳｂを降車時端末３０に出力させる処理が行われる。
【0093】
ステップＳ１５９では、識別情報ＩＤが利用停止中であるか否か、または運賃バリュー不足であるか否かを判定する処理が行われる。後述するように、サーバ装置６０では、ホスト装置４０から送信されてきた識別情報ＩＤ、即ち利用者Ｍａが所持するＩＣカード５０の識別情報ＩＤａが本運賃収受システム５の利用を停止されているか否かを判定し、停止されている場合には利用停止中情報を当該ホスト装置４０に送信する。また、利用者Ｍａが所持するＩＣカード５０の識別情報ＩＤａに関連付けられた運賃バリューＶ、つまり当該利用者Ｍａが有する運賃バリューＶに対して、利用者Ｍａの利用運賃Ｘに相当するバリューがそれ以下（利用運賃Ｘ相当のバリュー≦運賃バリューＶ）であるか否かを判定し、利用運賃Ｘ相当のバリューが運賃バリューＶを超えている場合には運賃バリュー不足情報を当該ホスト装置４０に送信する。
【0094】
このため、利用停止中情報や運賃バリュー不足情報を受信した場合には、先に送信した識別情報等ＩＤａ／ＣＭａを保持しているＩＣカード５０は、本運賃収受システム５を利用することができないことから、ステップＳ１５９では利用停止中や運賃バリュー不足であると判定して（Ｓ１５９；Ｙｅｓ）、ステップＳ１６１により現金決済情報出力処理が行われる。これにより、降車時端末３０の表示ユニット３５には、利用者Ｍａに対して利用運賃Ｘを現金で支払う必要があることを明示する情報ＭＳａが出力される。
【0095】
一方、利用停止中情報や運賃バリュー不足情報のいずれも受信することなく決済完了情報を受信した場合には、後述するように、サーバ装置６０において利用運賃Ｘの決済処理が完了していることになるので、ステップＳ１５９では本運賃収受システム５の利用停止中ではない（利用可能である）と判定して（Ｓ１５９；Ｎｏ）、ステップＳ１６７に処理を移行する。
【0096】
ステップＳ１６１の現金決済情報出力処理では、利用者Ｍａに対して利用運賃Ｘを現金で支払う必要があることを明示する情報ＭＳａをホスト装置４０から降車時端末３０に出力する。利用運賃Ｘを現金で支払う必要があることを明示する情報は、例えば、利用者Ｍａが一見して「現金支払いが必要」であることを視覚的に理解可能な図形（赤色の大きな￥印等）や現金をイメージさせるピクトグラム等を降車時端末３０の表示ユニット３５に表示し得るものである。またこの処理では、このような表示とともに利用者Ｍａに対して聴覚的に注意喚起し得る「ピッピッピッ」等の効果音を表示ユニット３５から出力し得る音響データを降車時端末３０に出力してもよい。
【0097】
ステップＳ１６７の降車許容情報出力処理では、当該利用者Ｍａに対して降車を許容することを明示する情報ＭＳａをホスト装置４０から降車時端末３０に出力する。降車を許容することを明示する情報は、例えば、利用者Ｍａが一見して「降車してもよい」ことを視覚的に理解可能な図形（緑色の大きな○印等）や降車をイメージさせるピクトグラム等を降車時端末３０の表示ユニット３５に表示し得るものである。またこの処理では、このような表示とともに「降車してもよい」ことを聴覚的にイメージさせる「ピンポーン」等の効果音を表示ユニット３５から出力し得る音響データを降車時端末３０に出力してもよい。
【0098】
ステップＳ１６９のＩＤ情報等記憶処理では、車載側降車時処理（Ｓ１５０）において行われた情報処理の結果（サーバ装置６０から受信した情報（決済完了情報、ＩＤ未登録情報または利用停止中情報）、降車時送信エラーフラグのオン情報）を、識別情報ＩＤａ（ＩＤ）とともにこれに関連付けてホスト装置４０のメモリ４３（ＤＲＡＭ）に記憶する。ステップＳ１６９の処理が終わると本車載側降車時処理（Ｓ１５０）が終了するため、図３に示す運賃収受処理１００に戻る。この後は車載側乗車時処理（Ｓ１２０）で説明した通りである。
【0099】
［乗車時読取り等処理２００（降車時読取り等処理３００）］
本実施形態の運賃収受システム５では、前述したように、乗車時端末２０は乗車時読取り等処理２００を行い、また降車時端末３０は降車時読取り等処理３００を行う。そのため、ここからは、図６を参照しながら、乗車時読取り等処理２００（乗車時）および降車時読取り等処理３００について説明する。なお、乗車時読取り等処理２００と降車時読取り等処理３００は、情報処理の内容がほぼ同様であることから、ここでは乗車時読取り等処理２００を代表して説明する。降車時読取り等処理３００については、乗車時読取り等処理２００の各ステップＳ２ｘｘ（ｘｘは０１，０３，０５，０７，０９，１１，１３，１５）の番号をステップＳ３ｘｘに変更することによって、ほぼ同じように説明することができる。また、乗車時端末２０の制御ユニット２１等の符号に続けて記載する括弧内の番号が降車時端末３０の制御ユニット３１等の符号に対応する。
本実施形態の運賃収受システム５では、前述したように、乗車時端末２０は乗車時読取り等処理２００を行い、また降車時端末３０は降車時読取り等処理３００を行う。そのため、ここからは、図６を参照しながら、乗車時読取り等処理２００（乗車時）および降車時読取り等処理３００について説明する。なお、乗車時読取り等処理２００と降車時読取り等処理３００は、情報処理の内容がほぼ同様であることから、ここでは乗車時読取り等処理２００を代表して説明する。降車時読取り等処理３００については、乗車時読取り等処理２００の各ステップＳ２ｘｘ（ｘｘは０１，０３，０５，０７，０９，１１，１３，１５）の番号をステップＳ３ｘｘに変更することによって、ほぼ同じように説明することができる。また、乗車時端末２０の制御ユニット２１等の符号に続けて記載する括弧内の番号が降車時端末３０の制御ユニット３１等の符号に対応する。
【0100】
図６に示すように、乗車時読取り等処理２００では、まずステップＳ２０１により所定の初期化処理が行われる。この処理では、例えば、制御ユニット２１（３１）のメモリの本処理用のワーク領域やフラグをクリアしたり、ほぼ同時期に起動されるホスト装置４０から送られてくる初期設定用の制御コマンドに従って、読取りユニット２３（３３）、表示ユニット２５（３５）や有線通信ユニット２７（３７）の初期設定がそれぞれ行われたりする。停留所連番号ＢＳ＃もこの初期化処理において、始発の停留所連番号である「０１」にセットされる。停留所連番号ＢＳ＃は、停留所連番号ＢＳ＃を１つ進める指令信号がホスト装置４０から送られてくると、その時点の停留所連番号ＢＳ＃に１を加えた新たな停留所連番号ＢＳ＃が自動的にセットされる。
【0101】
次のステップＳ２０３では停留所情報取得処理が行われる。この処理は、現在、セットされている停留所連番号ＢＳ＃を取得する処理であり、取得された停留所連番号ＢＳ＃は、次のステップＳ２０５において使用される。続くステップＳ２０５ではＩＤ情報等読取り処理が行われる。本実施形態では、ＩＣカード５０に保持されている識別情報等ＩＤ／ＣＭ（識別情報ＩＤおよび担保金情報ＣＭ）を読取りユニット２３（３３）により読み取る。読取りユニット２３はＩＣカード５０に対応した非接触式タイプのＩＣカードリーダであるため、読取りユニット２３にＩＣカード５０がかざされることで識別情報等ＩＤ／ＣＭが読み取られる。
【0102】
次のステップＳ２０７では、ステップＳ２０５により識別情報等ＩＤ／ＣＭが読み取られたか否かが判定される。即ち、読取りユニット２３（３３）にＩＣカード５０がかざされていない場合や、ＩＣカード５０がかざされていても識別情報ＩＤや担保金情報ＣＭを正常に読み取ることができない場合がある。そのため、ステップＳ２０７ではこのような読み取りの可否を判定する。
【0103】
そして、ステップＳ２０７により識別情報等ＩＤ／ＣＭが読み取られたと判定した場合には（Ｓ２０７；Ｙｅｓ）、続くステップＳ２０９に処理を移行し、読み取られていないと判定した場合には（Ｓ２０７；Ｎｏ）、ステップＳ２０５に戻る。つまり、識別情報等ＩＤ／ＣＭを読み取ることができるまで、ＩＤ情報等読取り処理（Ｓ２０５）と判定処理（Ｓ２０７）が繰り返し行われる。
【0104】
ステップＳ２０９ではＩＤ情報等送出処理が行われる。この処理は、ステップＳ２０５により読み取った識別情報等ＩＤ／ＣＭをその読み取った停留所ＢＳの停留所連番号ＢＳ＃とともにホスト装置４０に送るものである。また前述したように、ホスト装置４０から送出されるポーリング信号に呼応して有線通信ユニット２７（３７）がデータを送出するように、乗車時端末２０（降車時端末３０）が構成されていない場合、即ち乗車時端末２０（降車時端末３０）が自発的に識別情報等ＩＤ／ＣＭとその停留所連番号ＢＳ＃をホスト装置４０に送出する場合には、送出元を識別可能な情報（乗車／降車フラグ等）をさらに付加してホスト装置４０に送る。
【0105】
次のステップＳ２１１では出力情報受取り処理が行われる。前述したようにホスト装置４０は、車載側降車時処理（図５）において、利用運賃Ｘを現金で支払う必要があることを明示する情報ＭＳａ（Ｓ１６１）や、降車を許容することを明示する情報ＭＳａ，ＭＳｂ（Ｓ１６７）を降車時端末３０に出力する。また、前述した車載側乗車時処理（図４）においてはなかったが、ホスト装置４０から乗車時端末２０に同様の情報を出力する場合もある。例えば、図１１を参照しながら後述するように、バス９０が「前乗り前払い後降り方式」を採用する場合には、利用運賃Ｘを現金で支払う必要がある旨や降車を許容する旨を明示する情報ＭＳａがホスト装置４０から乗車時端末２０に出力される。
【0106】
このため、ステップＳ２１１では出力情報受取り処理によりこれらの情報ＭＳａ，ＭＳｂの受け取りを試み次のステップＳ２１３により情報ＭＳａ，ＭＳｂを受け取ったか否かを判定する。そして、受け取っていない場合には（Ｓ２１３；Ｎｏ）、所定回数または所定時間の間、ステップＳ２１１の出力情報受取り処理を繰り返し、情報ＭＳａ，ＭＳｂを受け取ったと判定したときには（Ｓ２１３；Ｙｅｓ）、受け取ったこれらの情報ＭＳａ，ＭＳｂのいずれかを次のステップＳ２１５の出力情報表示処理によって表示ユニット２５（３５）に表示する。
【0107】
これに対して、所定回数または所定時間を経過しても情報ＭＳａ，ＭＳｂを受け取ることができない場合には（Ｓ２１３；ＮＡ）、例えば、前述した車載側乗車時処理（Ｓ１２０）のように、ホスト装置４０から乗車時端末２０（降車時端末３０）に送出される情報ＭＳａ，ＭＳｂがないこともある。そのため、この場合には次の利用者Ｍ等がＩＣカード５０を読取りユニット２３にかざすときに備えてステップＳ２０３に戻った後、ＩＤ情報等読取り処理（Ｓ２０５）と読取り判定処理（Ｓ２０７）を繰り返して待機する。ステップＳ２１５の出力情報表示処理を終えた後もステップＳ２０３に戻って同様に待機する。
【0108】
［運賃決済処理５００］
本実施形態の運賃収受システム５では、前述したように、車載装置１０は、乗車時端末２０や降車時端末３０から識別情報ＩＤが送られてくると、それに停留所連番号ＢＳ＃の情報や利用運賃情報ＣＦ等を付加した送信データＴＸａ（ＴＸ）をサーバ装置６０に送信する。そのため、ここからは図７を参照しながら、送信データＴＸａを受信するサーバ装置６０により行われる運賃決済処理５００について説明する。
本実施形態の運賃収受システム５では、前述したように、車載装置１０は、乗車時端末２０や降車時端末３０から識別情報ＩＤが送られてくると、それに停留所連番号ＢＳ＃の情報や利用運賃情報ＣＦ等を付加した送信データＴＸａ（ＴＸ）をサーバ装置６０に送信する。そのため、ここからは図７を参照しながら、送信データＴＸａを受信するサーバ装置６０により行われる運賃決済処理５００について説明する。
【0109】
図７に示すように、運賃決済処理５００では、まずステップＳ５０１によりテーブル読出し処理が行われる。このテーブルは、利用者Ｍに関する一連の情報を当該利用者Ｍの識別情報ＩＤに関連付けて記憶されている複数の情報の集まりである。本実施形態では、例えば、利用者Ｍが有する運賃バリューＶ、負債バリューＷ、担保金情報ＣＭ、各種のフラグ、利用者の基本情報等が登録（記憶）されている。なお、各種のフラグについては後述する。
【0110】
次のステップＳ５０３ではＩＤ情報等受信処理が行われる。この処理では、ホスト装置４０から送信されてくる識別情報ＩＤ等を受信する。図２に表されるシーケンス図の例では、利用者Ｍａの乗車時には、識別情報ＩＤ、乗車フラグや乗車時の停留所連番号ＢＳ＃等が送信データＴＸａとしてホスト装置４０から送信され（図４；Ｓ１２１）、また利用者Ｍａの降車時には、識別情報ＩＤ、利用運賃情報ＣＦ、降車フラグや降車時の停留所連番号ＢＳ＃等が送信データＴＸｂとして送信されてくる（図５；Ｓ１５５）。また、後述するリカバリ処理４００では、サーバ装置６０が受信できなかったと推定される識別情報ＩＤ等に加えて乗車時送信エラーフラグや降車時送信エラーフラグも送信データＴＸｅとしてホスト装置４０から送られてくる。そのため、ステップＳ５０３のＩＤ情報等受信処理では、これらの送信データＴＸａ等（識別情報ＩＤ等）を受信する。
【0111】
なお、利用運賃情報ＣＦは、サーバ装置６０で利用運賃Ｘを算出しない（ホスト装置４０で利用運賃Ｘを算出する）場合にホスト装置４０から送られてくるが、サーバ装置６０で利用運賃Ｘを算出する（ホスト装置４０で利用運賃Ｘを算出しない）場合には、前述したように利用運賃情報ＣＦの代わりに、乗車時の停留所連番号ＢＳ＃および降車時の停留所連番号ＢＳ＃がホスト装置４０から送られてくる。
【0112】
そして、続くステップＳ５０５によりこれらの識別情報ＩＤ等が受信されたか否かが判定され、ホスト装置４０から受信した場合には（Ｓ５０５；Ｙｅｓ）、次のステップＳ５０７の判定処理に進む。まだ受信していない場合には（Ｓ５０５；Ｎｏ）、ステップＳ５０３に戻って識別情報ＩＤ等を受信するまでステップＳ５０３とステップＳ５０５を繰り返し行う。つまり、サーバ装置６０は識別情報ＩＤ等を受信するまで待機する。
【0113】
続くステップＳ５０７では、識別情報ＩＤが未登録であるか否か、または利用停止中であるか否かを判定する処理が行われる。利用者Ｍは、本運賃収受システム５を利用する場合には、前述したように、予め本システム５の利用登録を行う必要があり、この利用登録により、前述のテーブルに識別情報ＩＤが登録される。そのため、ステップＳ５０７では読み出されたテーブルに当該識別情報ＩＤが登録されているか否かを判定する。また、後述する事後決済処理（Ｓ５８０）においては、利用運賃Ｘが運賃バリューＶ以下でない（利用運賃Ｘが運賃バリューＶを超えている）と判定した場合に利用停止フラグをオンに設定する（Ｓ５９１）。そのため、ステップＳ５０７ではこの利用停止フラグの情報に基づいて利用停止中であるか否かについても判定する。
【0114】
そして、ステップＳ５０７の判定処理により、当該識別情報ＩＤが未登録および利用停止中のいずれか一方または両方（少なくとも一方）であると判定した場合には（Ｓ５０７；Ｙｅｓ）、ステップＳ５１１に移行してＩＤ未登録または停止中の情報をホスト装置４０に送信する処理が行われる。即ち、当該識別情報ＩＤがサーバ装置６０のテーブルに登録されていないと判定した場合にはＩＤ未登録情報をホスト装置４０に送信し、また当該識別情報ＩＤが本運賃収受システム５の利用を停止されていると判定した場合には利用停止中情報をホスト装置４０に送信する。これを受信したホスト装置４０は、前述のように、ＩＤ未登録フラグをオンに設定したり（図４；Ｓ１２７）、現金決済情報を降車時端末３０に出力したりする（図５；Ｓ１６１）。
【0115】
これに対して、当該識別情報ＩＤが未登録でも利用停止中でもないと判定した場合には（Ｓ５０７；Ｎｏ）、ステップＳ５０３により受信した識別情報ＩＤ等が乗車時のものであるか降車時のものであるかをステップＳ５０９で判定する。ステップＳ５０３では識別情報ＩＤのほかに乗車フラグや降車フラグも受信しているため、ステップＳ５０９の乗降車判定処理ではこれらのフラグに基づいて乗車時か降車時かを判定する。
【0116】
そして、乗車時のものであると判定した場合には（Ｓ５０９；乗車）、ステップＳ５３０に移行してサーバ側乗車時処理を行い、降車時のものであると判定した場合には（Ｓ５０９；降車）、ステップＳ５５０に移行してサーバ側降車時処理を行う。サーバ側乗車時処理（Ｓ５３０）は図８(A)に、またサーバ側降車時処理は図８(B)にそれぞれ表されているため、ここからは図８も参照しながら説明する。
【0117】
<サーバ側乗車時処理（Ｓ５３０）>
図８(A)に示すように、サーバ側乗車時処理ではステップＳ５３１により識別情報ＩＤに関連付けられた情報の更新が行われる。例えば、先の例で停留所ＢＳａから利用者Ｍａがバス９０に乗車したときにホスト装置４０から識別情報ＩＤ等が送信された場合には、前述したように乗車フラグや乗車時の停留所連番号ＢＳ＃も一緒に送信されていることから、識別情報ＩＤに関連付けてこれらで前述したテーブルを書き換えて更新する。また、リカバリ処理４００により、識別情報ＩＤ等（サーバ装置６０が受信できなかったと推定されるもの）と一緒に乗車時送信エラーフラグが送信されてきた場合には、識別情報ＩＤに関連付けてこのようなエラーフラグで前述したテーブルを書き換えて更新する。なお、これらのフラグは、前述した各種のフラグ（識別情報ＩＤに関連付けられてテーブルに登録されるフラグ）に含まれる。
図８(A)に示すように、サーバ側乗車時処理ではステップＳ５３１により識別情報ＩＤに関連付けられた情報の更新が行われる。例えば、先の例で停留所ＢＳａから利用者Ｍａがバス９０に乗車したときにホスト装置４０から識別情報ＩＤ等が送信された場合には、前述したように乗車フラグや乗車時の停留所連番号ＢＳ＃も一緒に送信されていることから、識別情報ＩＤに関連付けてこれらで前述したテーブルを書き換えて更新する。また、リカバリ処理４００により、識別情報ＩＤ等（サーバ装置６０が受信できなかったと推定されるもの）と一緒に乗車時送信エラーフラグが送信されてきた場合には、識別情報ＩＤに関連付けてこのようなエラーフラグで前述したテーブルを書き換えて更新する。なお、これらのフラグは、前述した各種のフラグ（識別情報ＩＤに関連付けられてテーブルに登録されるフラグ）に含まれる。
【0118】
次のステップＳ５３３では受信完了情報送信処理が行われる。受信完了情報は、ホスト装置４０から送信されてきた識別情報ＩＤ等が当該サーバ装置６０に問題なく受信されたことを示す情報であり、これを当該ホスト装置４０に送信する（図２に示すＲＸａ）。これにより、前述したように、サーバ装置６０が受信したか否かの判定をホスト装置４０が行うことを可能にしている。ステップＳ５３３の処理が終わると、本サーバ側乗車時処理が終了するため、図７に示す運賃決済処理５００に戻る。
【0119】
運賃決済処理５００に戻ると、次のステップＳ５１３によりテーブル保存処理が行われる。この処理では、前述した受信完了情報送信処理（図８(A)）の更新処理（Ｓ５３１）により更新されたテーブルをホスト装置４０のメモリ４３に保存する。ステップＳ５１３の処理が終わると、一連の運賃決済処理５００が終了する。そのため、サーバ装置６０は、再度、運賃決済処理５００を最初（Ｓ５０１）から実行して、次の送信データＴＸｂ等がホスト装置４０から送信されてくるまで、ＩＤ情報等受信処理（Ｓ５０３）と受信判定処理（Ｓ５０５）を繰り返して待機する。
【0120】
<サーバ側降車時処理（Ｓ５５０）>
図８(B)に示すように、サーバ側降車時処理ではステップＳ５５１により利用運賃算出処理が行われる。この処理は、前述した車載側降車時処理（図５）で説明した利用運賃算出処理（Ｓ１５１）とほぼ同じであり、乗車時の停留所連番号ＢＳ＃と降車時の停留所連番号ＢＳ＃とに基づいて利用運賃Ｘの金額を算出する。乗車時と降車時の停留所連番号ＢＳ＃は、前述したＩＤ情報等受信処理（Ｓ５０３）によりホスト装置４０から受信したものである。なお、降車時の停留所連番号ＢＳ＃と乗車時の停留所連番号ＢＳ＃は、特許請求の範囲に記載の「利用運賃の算出に要する情報」に相当し得るものである。
図８(B)に示すように、サーバ側降車時処理ではステップＳ５５１により利用運賃算出処理が行われる。この処理は、前述した車載側降車時処理（図５）で説明した利用運賃算出処理（Ｓ１５１）とほぼ同じであり、乗車時の停留所連番号ＢＳ＃と降車時の停留所連番号ＢＳ＃とに基づいて利用運賃Ｘの金額を算出する。乗車時と降車時の停留所連番号ＢＳ＃は、前述したＩＤ情報等受信処理（Ｓ５０３）によりホスト装置４０から受信したものである。なお、降車時の停留所連番号ＢＳ＃と乗車時の停留所連番号ＢＳ＃は、特許請求の範囲に記載の「利用運賃の算出に要する情報」に相当し得るものである。
【0121】
この算出には、前述のＩＤ情報等受信処理（Ｓ５０３）と同様に、例えば運賃三角表が用いられるが、所定の演算式に基づいて算出してもよい。例えば、基本運賃（例えばＸＸＸ円）に対して、降車する停留所ＢＳ＃から乗車した停留所ＢＳ＃を減算して得られた数（例えばＮ）を所定金額（例えばＹＹ円）に乗算したものを加算して算出してもよい（（ＸＸＸ＋ＹＹ×Ｎ）円）。なお、ホスト装置４０により利用運賃Ｘが算出される場合には、ホスト装置４０から送信されてきた利用運賃情報ＣＦに基づいて利用運賃Ｘが得られて算出する必要がない。そのため、この利用運賃算出処理（Ｓ５５１）は不要になる。
【0122】
次のステップＳ５５３では、ステップＳ５０３により受信した識別情報ＩＤ等が、現在降車しようとしている利用者ＭａのＩＣカード５０から読み取られてホスト装置４０によりほぼリアルタイムに送信されたものであるか、それとも通信障害の発生により送信できなかったことに起因して後述するリカバリ処理４００により再度送信されたものであるかを判定する。
【0123】
そして、ほぼリアルタイムに送信されたものであると判定した場合には（Ｓ５５３；現時点）、ステップＳ５７０に移行して現時点決済処理を行い、再度送信されたものであると判定した場合には（Ｓ５５３；リカバリ）、ステップＳ５８０に移行して事後決済処理を行う。現時点決済処理（Ｓ５７０）は図９(A)に、また事後決済処理は図９(B)にそれぞれ表されているため、ここからは図９も参照しながら説明する。
【0124】
<現時点決済処理（Ｓ５７０）>
図９(A)に示すように、現時点決済処理ではステップＳ５７１の判定処理により、ステップＳ５５１により算出された利用者Ｍａの利用運賃Ｘに相当するバリューが、当該利用者Ｍａが有する運賃バリューＶ以下（利用運賃Ｘ相当のバリュー（利用運賃）≦運賃バリューＶ）であるか否かを判定する。なお、「利用運賃Ｘ相当のバリュー（利用運賃）」の括弧内は利用運賃Ｘと運賃バリューＶが等価である場合には、利用運賃Ｘ≦運賃バリューＶになることを表しており、図９(A)や図９(B)にはこの場合が図示されている。
図９(A)に示すように、現時点決済処理ではステップＳ５７１の判定処理により、ステップＳ５５１により算出された利用者Ｍａの利用運賃Ｘに相当するバリューが、当該利用者Ｍａが有する運賃バリューＶ以下（利用運賃Ｘ相当のバリュー（利用運賃）≦運賃バリューＶ）であるか否かを判定する。なお、「利用運賃Ｘ相当のバリュー（利用運賃）」の括弧内は利用運賃Ｘと運賃バリューＶが等価である場合には、利用運賃Ｘ≦運賃バリューＶになることを表しており、図９(A)や図９(B)にはこの場合が図示されている。
【0125】
そして、利用運賃Ｘに相当するバリューが利用者Ｍａの運賃バリューＶ以下であると判定された場合には（Ｓ５７１；Ｙｅｓ）、続くステップＳ５７３の運賃バリュー減算処理により、利用者Ｍａの運賃バリューＶから利用運賃Ｘに相当するバリューを減算する。つまり、利用運賃Ｘを運賃バリューＶで決済（精算）する。そしてその後、ステップＳ５７５の決済完了情報送信処理により、決済完了情報をホスト装置４０に送信する（図２に示すＲＸａ）。これにより、決済完了情報を受信したホスト装置４０は、前述したように、車載側降車時処理（図５）の降車許容情報出力処理（Ｓ１６７）によって当該利用者Ｍａに対して降車を許容することを明示する情報ＭＳａを降車時端末３０に出力する。利用者Ｍａは、降車時端末３０の表示ユニット３５に出力される表示を見たり表示ユニット３５から出力される音を聞いたりして、自分が所持するＩＣカード５０により利用運賃Ｘが決済されたことや、バス９０を降車できることを把握する。
【0126】
これに対して、利用運賃Ｘに相当するバリューが利用者Ｍａの運賃バリューＶを超えると判定された場合には（Ｓ５７１；Ｎｏ）、利用者Ｍａが所持するＩＣカード５０では運賃バリューＶが不足することから利用運賃Ｘを決済することができない。このような場合には、ステップＳ５７７の運賃バリュー不足情報送信処理により、運賃バリュー不足情報をリアルタイムでホスト装置４０に送信する（図２に示すＲＸａ）。これにより、運賃バリュー不足情報を受信したホスト装置４０は、前述したように、車載側降車時処理（図５）の現金決済情報出力処理（Ｓ１６１）によって当該利用者Ｍａに対して利用運賃Ｘを現金で支払う必要があることを明示する情報ＭＳａを降車時端末３０に出力する。利用者Ｍａは、降車時端末３０の表示ユニット３５に出力される表示を見たり表示ユニット３５から出力される音を聞いたりして、自分が所持するＩＣカード５０では利用運賃Ｘを決済することができないことや、利用運賃Ｘを現金で支払うことでバス９０を降車できることを把握する。これにより、当該利用者Ｍａに対して利用運賃Ｘを現金で支払う必要があることをリアルタイムに告知する。
【0127】
ステップＳ５７５やステップＳ５７７の処理が終わると、本現時点決済処理（Ｓ５７０）が終了するため、図８(B)に示すサーバ側降車時処理に戻る。サーバ側降車時処理（Ｓ５５０）に戻ると、次のステップＳ５５５により識別情報ＩＤに関連付けられた情報の更新が行われる。先の例では、利用者Ｍａが停留所ＢＳｃでバス９０を降車する際にホスト装置４０から識別情報ＩＤ等が送信された場合には、前述したように降車フラグや降車時の停留所連番号ＢＳ＃も一緒に送信されていることから、識別情報ＩＤに関連付けてこれらで前述したテーブルを書き換えて更新する。また、リカバリ処理４００により、識別情報ＩＤ等（サーバ装置６０が受信できなかったと推定されるもの）と一緒に降車時送信エラーフラグが送信されてきた場合には、識別情報ＩＤに関連付けてこのようなエラーフラグで前述したテーブルを書き換えて更新する。なお、これらのフラグは、前述した各種のフラグ（識別情報ＩＤに関連付けられてテーブルに登録されるフラグ）に含まれる。
【0128】
ステップＳ５５５の処理が終わると、本サーバ側降車時処理（Ｓ５５０）が終了するため、図７に示す運賃決済処理５００に戻る。この後はサーバ側乗車時処理（Ｓ５３０）で説明した通りである。
【0129】
<事後決済処理（Ｓ５８０）>
図９(B)に示すように、事後決済処理ではステップＳ５８１の判定処理により、ステップＳ５５１により算出された利用者Ｍａの利用運賃Ｘに相当するバリューが、当該利用者Ｍａが有する運賃バリューＶ以下（利用運賃Ｘ相当のバリュー（利用運賃）≦運賃バリューＶ）であるか否かを判定する。
図９(B)に示すように、事後決済処理ではステップＳ５８１の判定処理により、ステップＳ５５１により算出された利用者Ｍａの利用運賃Ｘに相当するバリューが、当該利用者Ｍａが有する運賃バリューＶ以下（利用運賃Ｘ相当のバリュー（利用運賃）≦運賃バリューＶ）であるか否かを判定する。
【0130】
そして、利用運賃Ｘに相当するバリューが利用者Ｍａの運賃バリューＶ以下であると判定された場合には（Ｓ５８１；Ｙｅｓ）、続くステップＳ５８３の運賃バリュー減算処理により、利用者Ｍａの運賃バリューＶから利用運賃Ｘに相当するバリューを減算する。つまり、利用運賃Ｘを運賃バリューＶで決済（精算）する。ここまでは、前述した現時点決済処理（図９(A)）の場合と同様である。
【0131】
これに対して、利用運賃Ｘに相当するバリューが利用者Ｍａの運賃バリューＶを超えると判定された場合には（Ｓ５８１；Ｎｏ）、当該利用者Ｍａが所持するＩＣカード５０では運賃バリューＶが不足することから利用運賃Ｘを決済することができない。そのため、前述の現時点決済処理（図９(A)）では、運賃バリュー不足情報をホスト装置４０に送信し、当該利用者Ｍａに対して利用運賃Ｘを現金で支払う必要があることをリアルタイムに告知した。
【0132】
しかし、本事後決済処理（Ｓ５８０）の場合には、車載側降車時処理（図５）において通信障害に起因してホスト装置４０が識別情報ＩＤ等の送信を失敗したことから、利用者Ｍａの利用運賃Ｘが利用者Ｍａの担保金Ｙ以下（利用運賃Ｘ≦担保金Ｙ）であるときに限って当該利用者Ｍの降車を許容した。前述したように、利用運賃Ｘが運賃バリューＶを超えたとしても、その超過分（Ｘ－Ｖ）を担保金Ｙにより補填し得るからである。
【0133】
このため、利用運賃Ｘに相当するバリューが利用者Ｍａの運賃バリューＶを超えると判定された場合には（Ｓ５８１；Ｎｏ）、ステップＳ５８７の負債バリュー算出処理により負債バリューＷを算出する。負債バリューＷは、利用運賃Ｘが運賃バリューＶを超える金額であって担保金Ｙの範囲内、つまり担保金Ｙ以下の金額に相当するバリューである。なお、負債バリューは、バス９０の事業者から利用者Ｍａが借りている価値であり借り主である当該利用者Ｍａが返済義務（債務）を負うものである。
【0134】
続くステップＳ５８９では運賃バリュー無効化処理が行われる。負債バリューＷが算出されている場合、利用運賃Ｘに相当するバリューが利用者Ｍａの運賃バリューＶを超えているため、利用者Ｍａが有する運賃バリューＶは０（ゼロ）になるべきである。そのため、この処理では、当該利用者Ｍａの運賃バリューＶを０（ゼロ）に設定したり、運賃バリューＶそれ自体を使用することができないように無効（無価値）にしたりする。
【0135】
そして、次のステップＳ５９１では、利用停止フラグをオンに設定する処理が行われる。利用停止フラグがオンに設定されると、そのフラグに関連付けられた識別情報ＩＤや、当該識別情報ＩＤを有するＩＣカード５０では、本運賃収受システム５を利用することができなくなる。つまり、本運賃収受システム５の利用が停止される。なお、この利用停止フラグも、前述した各種のフラグ（識別情報ＩＤに関連付けられてテーブルに登録されるフラグ）に含まれる。
【0136】
この利用停止フラグは、サーバ装置６０に接続されて営業所等に設備されるチャージ端末等により、例えば、ＩＣカード５０を用いてその識別情報ＩＤに関連付けられた運賃バリューＶをチャージ（ＩＣカード５０をチャージ）することによって、運賃バリューＶが前述した超過分（利用運賃Ｘ－運賃バリューＶ）以上になった場合や超過分以上バリューがチャージされた場合には、フラグがオフにされる。これにより、本システム５の利用の停止が解除されるので、利用者Ｍは、本システム５を再び利用することが可能になる。また、運賃バリューＶのチャージを促すことが可能になるので、利用者Ｍによる当該超過分の返済義務（債務）の履行が促進される。
【0137】
ステップＳ５８５では決済完了情報送信処理が行われる。運賃バリュー減算処理（Ｓ５８３）が行われた場合には、利用運賃Ｘを運賃バリューＶで決済している。また負債バリュー算出処理（Ｓ５８７）や運賃バリュー無効化処理（Ｓ５８９）が行われた場合には、担保金Ｙの範囲内で負債バリューＷが生じさせることにより、負債バリューＷに相当する超過分の金額（Ｘ－Ｖ）は回収が可能であり、将来の決済が見込まれる。したがって、ステップＳ５８５の決済完了情報送信処理により、決済完了情報をホスト装置４０に送信する（図２に示すＲＸａ）。これにより、後述のリカバリ処理４００において決済完了情報を受信したホスト装置４０は、送信エラー情報等送信処理（Ｓ４０５）で再度送信した識別情報ＩＤ等がサーバ装置６０によって決済処理された旨の情報を得ることができる。
【0138】
ステップＳ５８５の処理が終わると、本事後決済処理（Ｓ５８０）が終了するため、図８(B)に示すサーバ側降車時処理に戻る。この後は現時点決済処理（Ｓ５７０）で説明した通りであるので、省略する。
【0139】
［リカバリ処理４００］
図２に示すように、本実施形態の運賃収受システム５では、前述した通信障害の発生により、ホスト装置４０からサーバ装置６０に送信された送信データＴＸがサーバ装置６０に受信されない場合がある（図２に示すＴＸｄ）。つまり、ホスト装置４０からの送信が失敗する場合がある。そのため、本実施形態では、このように送信が失敗した場合には、車載側乗車時処理（図４）や車載側降車時処理（図５）において乗車時送信エラーフラグや降車時送信エラーフラグをオンに設定し、かつ、識別情報ＩＤに関連付けてホスト装置４０のメモリ４３に記憶している（図４；Ｓ１２９、図５；Ｓ１６３）。
図２に示すように、本実施形態の運賃収受システム５では、前述した通信障害の発生により、ホスト装置４０からサーバ装置６０に送信された送信データＴＸがサーバ装置６０に受信されない場合がある（図２に示すＴＸｄ）。つまり、ホスト装置４０からの送信が失敗する場合がある。そのため、本実施形態では、このように送信が失敗した場合には、車載側乗車時処理（図４）や車載側降車時処理（図５）において乗車時送信エラーフラグや降車時送信エラーフラグをオンに設定し、かつ、識別情報ＩＤに関連付けてホスト装置４０のメモリ４３に記憶している（図４；Ｓ１２９、図５；Ｓ１６３）。
【0140】
このため、リカバリ処理４００では、このような乗車時送信エラーフラグや降車時送信エラーフラグがホスト装置４０のメモリ４３に記憶されている場合には通信障害の発生に起因した送信エラーが生じている可能性が高いことから、該当する識別情報ＩＤについて送信されるべき識別情報ＩＤ等の送信データＴＸｅを再度送信する。そのため、ここからは図１０も参照しながら、リカバリ処理４００について説明する。なお、このリカバリ処理４００は、原則として、ホスト装置４０の無線通信ユニット４８に対して、電波状態が良好な場所、例えば、終着停留所ＢＳｚ、バス９０の営業所等、その車庫の付近や当該車庫（入庫時）において行われるが、電波状態が良好な路線をバス９０が走行している間に行ってもよい。
【0141】
図１０に示すように、リカバリ処理４００では、まずステップＳ４０１により送信エラー情報読出し処理が行われる。この処理では、送信エラー情報として、車載側乗車時処理（図４）や車載側降車時処理（図５）において、オンに設定された乗車時送信エラーフラグや降車時送信エラーフラグをホスト装置４０のメモリ４３から読み出す。読み出された乗車時送信エラーフラグや降車時送信エラーフラグが存在するか否かの判定処理が続くステップＳ４０３により行われる。
【0142】
そして、これらいずれの送信エラーフラグがメモリ４３から読み出されている場合には（Ｓ４０３；Ｙｅｓ）、次のステップＳ４０５により再度送信する必要のある識別情報ＩＤ等の送信処理を行い、読み出されていない場合には（Ｓ４０３；Ｎｏ）、再度送信する必要のある識別情報ＩＤ等は存在しないため、本リカバリ処理４００を終了する。
【0143】
ステップＳ４０５により再度送信される情報は、本来、利用者Ｍの乗車時や降車時にほぼリアルタイムに送信されるべき識別情報ＩＤ等とそれに付加する送信エラーフラグである。そのため、車載側乗車時処理（図４）のＩＤ情報等送信処理（Ｓ１２１）や車載側降車時処理（図５）のＩＤ情報等送信処理（Ｓ１５５）において送信されるものと、乗車時送信エラーフラグや降車時送信エラーフラグである。なお、このような送信エラーフラグを付加するのは、サーバ装置６０で行われる運賃決済処理５００において、リアルタイムにホスト装置４０から送信されてくる識別情報ＩＤ等と区別して情報処理を行うためである（図８(B)；Ｓ５５３）。
【0144】
即ち、乗車時送信エラーフラグがオンに設定されている場合には、それに関連付けられている識別情報ＩＤ、乗車フラグおよび乗車時送信エラーフラグを送信する。また、サーバ装置６０において利用運賃Ｘを算出するときには、乗車時の停留所連番号ＢＳ＃も一緒に送信する。また、降車時送信エラーフラグがオンに設定されている場合には、それに関連付けられている識別情報ＩＤ、降車フラグ、利用運賃情報ＣＦおよび降車時送信エラーフラグを送信する（送信データＴＸｅ）。また、サーバ装置６０において利用運賃Ｘを算出するときには、利用運賃情報ＣＦに代えて降車時の停留所連番号ＢＳ＃を一緒に送信する。
【0145】
そして、所定時間を経過してもサーバ装置６０から受信完了情報等（受信データＴＸｅ）を受信できない場合には（Ｓ４０７；Ｎｏ）、ステップＳ４０５に戻って送信データＴＸｅの再送信を行い、所定のタイムアウト時間が経過するまでこの再送信を繰り返す。
【0146】
タイムアウト時間が経過する前に受信完了情報等を受信できた場合には（Ｓ４０７；Ｙｅｓ）、ステップＳ４０９の乗(降)車送信エラーフラグオフ処理に移行する。またタイムアウト時間が経過した場合には（Ｓ４０７；ＮＡ）、その時点においても無線通信回線８５において通信障害が発生している可能性が高い。そのため、送信エラーフラグをオンに設定したままステップＳ４１１の判定処理に移行する。なお、送信エラーフラグをオンに設定したまま本リカバリ処理４００を終了してもよい。
【0147】
ステップＳ４０９の乗(降)車送信エラーフラグオフ処理では、送信が完了した送信データＴＸｅの識別情報ＩＤ等は再度送信する必要がないため、これに関連付けられている乗車送信エラーフラグまたは降車送信エラーフラグをオフに設定する処理が行われる。そして、ステップＳ４１１により、再送の必要がある乗車時送信エラーフラグや降車時送信エラーフラグが残っているか否かの判定処理を行い、残っている場合には（Ｓ４１１;Ｙｅｓ）、ステップＳ４０５に戻って再度送信を試みる。残っていない場合には本リカバリ処理４００を終了する。
【0148】
上述した本実施形態の運賃収受システム５について、より具体的な例を挙げて説明すると次のようになる。例えば、利用者Ｍは、毎日の通勤に片道５００円（往復１０００円）の利用運賃Ｘが必要な経路でバス９０を利用している。利用者Ｍは、運賃収受システム５の利用登録時に担保金Ｙとして１０００円（往復時の利用運賃Ｘの相当額）を支払って本システム５に登録している。運賃バリューＶは、担保金Ｙとは別に、いくらか支払ってチャージしている。このような状況において、５つのケースを例示して説明する。
【0149】
（ケース１）
運賃バリューＶ：６００円相当、利用運賃Ｘ：５００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、ホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信された。これにより、サーバ装置６０の運賃決済処理（図７）は、運賃バリューＶでの精算を完了したため、利用者ＭはＩＣカード５０を使って降車できた。
運賃バリューＶ：６００円相当、利用運賃Ｘ：５００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、ホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信された。これにより、サーバ装置６０の運賃決済処理（図７）は、運賃バリューＶでの精算を完了したため、利用者ＭはＩＣカード５０を使って降車できた。
【0150】
この場合、利用運賃Ｘ：５００円≦運賃バリューＶ：６００円であることから、運賃バリュー減算処理（図９(A)；Ｓ５７３）により運賃バリューＶの残高は１００円相当（＝６００円(運賃バリューＶ)－５００円(利用運賃Ｘ)）になった。
【0151】
（ケース２）
運賃バリューＶ：６００円相当、利用運賃Ｘ：７００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、ホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信された。これにより、サーバ装置６０の運賃決済処理（図７）は、運賃バリューＶでは不足するため、精算できないことから、降車時端末３０の表示ユニット３５には現金支払いのメッセージが表示された。利用者Ｍは現金で７００円を支払って降車した。
運賃バリューＶ：６００円相当、利用運賃Ｘ：７００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、ホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信された。これにより、サーバ装置６０の運賃決済処理（図７）は、運賃バリューＶでは不足するため、精算できないことから、降車時端末３０の表示ユニット３５には現金支払いのメッセージが表示された。利用者Ｍは現金で７００円を支払って降車した。
【0152】
この場合、利用運賃Ｘ：７００円＞運賃バリューＶ：６００円であることから、運賃バリュー不足情報送信処理（図９(A)；Ｓ５７７）により運賃バリュー不足情報が送信され、それを受信したホスト装置４０から降車時端末３０にメッセージ情報が出力されて表示ユニット３５に「現金支払いが必要」である旨が表示された。運賃バリューＶは、何も引かれていないことから、現状の６００円相当を維持している。
【0153】
（ケース３）
運賃バリューＶ：６００円相当、利用運賃Ｘ：５００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、通信障害が発生してホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信されなかった。そのため、リアルタイムではサーバ装置６０の運賃決済処理が行われなかったが、ホスト装置４０の運賃収受処理（図３）は、降車を許容したため、利用者ＭはＩＣカード５０を使って降車できた。
運賃バリューＶ：６００円相当、利用運賃Ｘ：５００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、通信障害が発生してホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信されなかった。そのため、リアルタイムではサーバ装置６０の運賃決済処理が行われなかったが、ホスト装置４０の運賃収受処理（図３）は、降車を許容したため、利用者ＭはＩＣカード５０を使って降車できた。
【0154】
この場合、利用運賃Ｘ：５００円≦担保金Ｙ：１０００円であることから、降車許容情報出力処理（図５；Ｓ１６７）により降車許容情報が送出されて降車時端末３０にメッセージ情報が出力されて表示ユニット３５に「降車してもよい」旨が表示された。また、利用運賃Ｘ：５００円≦運賃バリューＶ：６００円であることから、運賃バリュー減算処理（図９(B)；Ｓ５８３）により運賃バリューＶの残高は１００円相当（＝６００円(運賃バリューＶ)－５００円(利用運賃Ｘ)）になった。
【0155】
（ケース４）
運賃バリューＶ：３００円相当、利用運賃Ｘ：５００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、通信障害が発生して車載装置１０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信されなかった。そのため、リアルタイムではサーバ装置６０の運賃決済処理（図７）が行われなかったが、ホスト装置４０の運賃収受処理（図３）は、降車を許容したため、利用者ＭはＩＣカード５０を使って降車できたが、その後のＩＣカード５０を使用したバス９０の利用（本運賃収受システム５の利用）ができなくなった。
運賃バリューＶ：３００円相当、利用運賃Ｘ：５００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、通信障害が発生して車載装置１０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信されなかった。そのため、リアルタイムではサーバ装置６０の運賃決済処理（図７）が行われなかったが、ホスト装置４０の運賃収受処理（図３）は、降車を許容したため、利用者ＭはＩＣカード５０を使って降車できたが、その後のＩＣカード５０を使用したバス９０の利用（本運賃収受システム５の利用）ができなくなった。
【0156】
この場合、利用運賃Ｘ：５００円≦担保金Ｙ：１０００円であることから、降車許容情報出力処理（図５；Ｓ１６７）により降車許容情報が送出されて降車時端末３０にメッセージ情報が出力されて表示ユニット３５に「降車してもよい」旨が表示された。また、利用運賃Ｘ：５００円＞運賃バリューＶ：３００円であることから、負債バリュー算出処理（図９(B)；Ｓ５８７）により負債バリューＷ：２００円相当（＝５００円(利用運賃Ｘ)－３００円(運賃バリューＶ)）が生じて利用者ＭのＩＣカード５０が利用停止になった。利用者Ｍは、負債バリューＷ：２００円相当以上チャージすることによって、負債バリューＷ（超過分）の返済義務が履行されて負債バリューＷの支払い債権が消滅するため、再びＩＣカード５０を使用したバス９０の利用（本運賃収受システム５の利用）ができるようになる。
【0157】
（ケース５）
運賃バリューＶ：６００円相当、利用運賃Ｘ：１１００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、通信障害が発生してホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信されなかった。そのため、リアルタイムではサーバ装置６０の運賃決済処理が行われず、ホスト装置４０の運賃収受処理（図３）は、利用運賃Ｘが担保金Ｙを超えており運賃バリューＶの残高によっては回収できない可能性があるので、降車時端末３０の表示ユニット３５には現金支払いのメッセージが表示された。利用者Ｍは現金で１１００円を支払って降車した。
運賃バリューＶ：６００円相当、利用運賃Ｘ：１１００円、担保金Ｙ：１０００円である場合において、降車時にＩＣカード５０を使って利用運賃Ｘを精算しようとしたところ、通信障害が発生してホスト装置４０からサーバ装置６０にＩＣカード５０の識別情報ＩＤ等が送信されなかった。そのため、リアルタイムではサーバ装置６０の運賃決済処理が行われず、ホスト装置４０の運賃収受処理（図３）は、利用運賃Ｘが担保金Ｙを超えており運賃バリューＶの残高によっては回収できない可能性があるので、降車時端末３０の表示ユニット３５には現金支払いのメッセージが表示された。利用者Ｍは現金で１１００円を支払って降車した。
【0158】
この場合、利用運賃Ｘ：１１００円＞担保金Ｙ：１０００円であることから、現金決済情報出力処理（図５；Ｓ１６１）により現金決済情報が送出されて降車時端末３０にメッセージ情報が出力され表示ユニット３５に「現金支払いが必要」である旨が表示された。運賃バリューＶは、何も引かれていないことから、現状の６００円相当を維持している。
【0159】
なお、本実施形態のバス９０と異なり、停留所ＢＳで利用者Ｍが前方の乗車口しその際に定額の利用運賃Ｘを支払い、降車時には後方の降車口から降車する「前乗り前払い後降り方式」を採用するバス９０’においても、本発明の運賃収受システムや車載装置を適用することが可能である。例えば、車載装置１０’、ＩＣカード５０およびサーバ装置６０’により実行される各処理の一連の流れは、例えば、図１１に示すようなシーケンス図で表される。図１１に示すように「前乗り前払い後降り方式」のバス９０’では、利用運賃Ｘが定額であり、利用者Ｍは乗車時に利用運賃Ｘを支払う。そのため、降車時端末３０は存在することなく、降車時の処理もないので（図１１に示す停留所ＢＳｃ，ＢＳｇ付近の一点鎖線部分）、シーケンスがシンプルになる。なお、利用者Ｍ（Ｍａ，Ｍｂ）が所持するＩＣカード５０は変更がない。
【0160】
ホスト装置４０’は、ハードウェア的には前述のホスト装置４０と同様であるものの、運賃収受処理１００’は次のように異なる。降車時端末３０が存在しないため、例えば、図３に示す運賃収受処理１００に対して、ステップＳ１０７の乗降車判定処理と、ステップＳ１５０の車載側降車時処理が不要になる。またステップＳ１２０の車載側降車時処理の内容が図５に示す車載側降車時処理に置き換わる。そして、そのステップＳ１５１の利用運賃算出処理が不要になる。利用運賃Ｘは定額であり算出する必要がないからである。またステップＳ１６３が「乗車時送信エラーフラグ設定」になり、さらにステップＳ１６７が「乗車許容情報出力処理」になる。これらの説明においては「降車」が「乗車」に置き換わる。また、図６に示す乗車時読取り等処理２００（降車時読取り等処理３００）は、乗車時読取り等処理２００’だけになり、説明においては乗車時の処理だけになる（降車に関するものは必要なくなる）。
【0161】
また、リカバリ処理４００’においては、送信エラーフラグは、降車送信エラーフラグがなくなり、乗車時送信エラーフラグだけになるため、図１０に示すリカバリ処理４００のステップＳ４０９は、乗車送信エラーフラグオフ処理になる。また説明においても、降車に関するものは必要なくなる。
【0162】
サーバ装置６０’は、ハードウェア的には前述のサーバ装置６０と同様であるものの、運賃決済処理５００’は次のように異なる。降車時端末３０が存在しないため、例えば、図７に示す運賃決済処理５００に対して、ステップＳ５０９の乗降車判定処理と、ステップＳ５５０のサーバ側降車時処理が不要になる。またステップＳ５３０のサーバ側乗車時処理の内容が図８(B)に示すサーバ側降車時処理に置き換わる。そして、そのステップＳ５５１の利用運賃算出処理が不要になる。利用運賃Ｘは定額であり算出する必要がないからである。これらの説明においては「降車」が「乗車」に置き換わり、乗車時の処理だけになる（降車に関するものは必要なくなる）。
【0163】
このように車載装置１０’（乗車時端末２０’、ホスト装置４０’）、ＩＣカード５０’およびサーバ装置６０’を構成することによって「前乗り前払い後降り方式」を採用するバス９０’においても、本発明の運賃収受システムや車載装置を適用することが可能になり、上述した運賃収受システム５と同様に以下のように作用および効果が得られる。なお、括弧内の数字や用語が「前乗り前払い後降り方式」を採用するバス９０’に本発明の運賃収受システムや車載装置を適用した場合である。
【0164】
以上説明したように本実施形態の運賃収受システム５は、車載装置１０（１０’）、ＩＣカード５０およびサーバ装置６０（６０’）を含む。サーバ装置６０（６０’）は、バス９０（９０’）外に設けられてインターネットＮに接続されており、バス９０（９０’）の利用者Ｍを識別する識別情報ＩＤと、これに関連付けられた運賃バリューＶと、利用者Ｍが当該システム５の利用登録時にバス９０（９０’）の事業者に提供した担保金Ｙの担保金情報ＣＭと、を記憶する。ＩＣカード５０は、利用者Ｍに所持されて識別情報ＩＤおよび担保金情報ＣＭを有する。車載装置１０（１０’）は、利用運賃情報ＣＦと、ＩＣカード５０から読み出された識別情報ＩＤと、を無線通信回線８５およびインターネットＮを介してサーバ装置６０（６０’）に送信する。車載装置１０（１０’）は、サーバ装置６０（６０’）に対して送信した、(1) 識別情報ＩＤおよび利用運賃情報ＣＦがサーバ装置６０（６０’）に受信された場合、利用者Ｍの降車（乗車）を許容する情報ＭＳａを出力する［通信正常時］。そして、サーバ装置６０（６０’）は、車載装置１０（１０’）から、(3) 識別情報ＩＤおよび利用運賃情報ＣＦを受信した場合、利用運賃Ｘに相当するバリューを運賃バリューＶから減算し収受する。
【0165】
これに対して、サーバ装置６０（６０’）に送信した、(2) 識別情報ＩＤおよび／または利用運賃情報ＣＦがサーバ装置６０（６０’）に受信されない通信障害が発生した場合には、車載装置１０（１０’）は、利用者Ｍが所持するＩＣカード５０から読み出された担保金情報ＣＭに基づいて次のいずれかを行う［通信障害時］。(2a)利用運賃情報ＣＦから得られる利用運賃Ｘが担保金Ｙ以下であるときには、利用者Ｍの降車（乗車）を許容する情報ＭＳａを出力し、かつ、通信障害の解消後、サーバ装置６０（６０’）に通信障害の発生情報、識別情報ＩＤおよび利用運賃情報ＣＦを送信する。また、(2b)利用運賃情報ＣＦから得られる利用運賃Ｘが担保金Ｙを超えるときには、利用者Ｍに利用運賃Ｘの現金支払いを要求する情報ＭＳｂを出力する。
【0166】
これにより、通信障害が発生して車載装置１０（１０’）とサーバ装置６０（６０’）が情報通信を行うことができない事態が生じても（上記(2)）、バス９０（９０’）の利用者Ｍは、利用運賃Ｘが担保金Ｙ以下である場合には、利用者Ｍの降車（乗車）を許容する情報ＭＳａが出力されるので（上記(2a)）、運賃後払い方式（運賃前払い方式）の場合には降車（乗車）することが可能になる。利用運賃Ｘが担保金Ｙを超えるときには、利用者Ｍに利用運賃Ｘの現金支払いを要求する情報ＭＳｂが出力されるので（上記(2b)）、当該利用者Ｍは利用運賃Ｘを現金で支払うことにより乗車したり降車したりすることが可能になる。
【0167】
そして、車載装置１０（１０’）が上記(2a)を行い、サーバ装置６０（６０’）が、(4) 通信障害情報ＦＣ、識別情報ＩＤおよび利用運賃情報ＣＦを受信した場合において、(4a)利用運賃情報ＣＦに基づく利用運賃Ｘが運賃バリューＶ以下であるときには、運賃バリューＶから利用運賃Ｘに相当するバリューを減算する。また、(4b)利用運賃情報ＣＦに基づく利用運賃Ｘが運賃バリューＶを超えるときには、運賃バリューＶを超える超過分を担保金情報ＣＭに基づく担保金Ｙの範囲内で負債バリューＷとして記憶するとともに運賃バリューＶをゼロまたは無価値に変更し、かつ、その後、識別情報ＩＤに関連付けられた運賃バリューＶを用いた利用運賃Ｘの収受を停止する。
【0168】
これにより、バス９０（９０’）の事業者は、サーバ装置６０（６０’）が通信障害情報ＦＣ、識別情報ＩＤおよび利用運賃情報ＣＦを車載装置１０（１０’）から受信した場合においては（上記(4)）、利用運賃Ｘが運賃バリューＶ以下であるときには、運賃バリューＶから利用運賃Ｘに相当するバリューが減算されるので（上記(4a)）、事後的に利用運賃Ｘを運賃バリューＶから回収することが可能になる。利用運賃Ｘが運賃バリューＶを超えるときには、運賃バリューＶを超える超過分は担保金Ｙの範囲内で負債バリューＷとしてサーバ装置６０（６０’）に記憶されるとともに運賃バリューＶはゼロまたは無価値に変更され（上記(4b)）、その後、当該運賃バリューＶを用いた利用運賃Ｘの収受が停止される（上記(4b)）。負債バリューＷは、運賃バリューＶを超える超過分であり担保金Ｙの範囲内で当該事業者が立て替える「立替えバリュー」でもある。そのため、当該超過分を担保金Ｙの範囲内で当該事業者は負債バリューＷの支払い債権を得ることが可能になり、利用者Ｍには当該超過分の返済義務を負わせることが可能になる。また利用者Ｍは、当該運賃バリューＶを用いた利用運賃Ｘの支払いができなくなるため、ＩＣカード５０を用いた当該バス９０（９０’）の利用ができなくなる。例えば、利用者Ｍが当該システム５の登録時に事業者に提供した担保金Ｙから、当該システム５の解約時に当該超過分を差し引いて返金することにより、当該超過分の返済義務（債務）を当該利用者Ｍに履行させることが可能になる。したがって、通信障害が生じた場合においても運賃収受を行うことができる。
【0169】
また、本実施形態の車載装置１０（１０’）は、バス９０（９０’）の利用者Ｍから利用運賃Ｘを収受する運賃収受システム５に用いられる。当該システム５は、バス９０（９０’）外に設けられてインターネットＮに接続されており利用者Ｍを識別する識別情報ＩＤとこの識別情報ＩＤに関連付けられた運賃バリューＶと利用者Ｍが当該システム５の利用登録時にバス９０（９０’）の事業者に提供した担保金Ｙの担保金情報ＣＭとを記憶するサーバ装置６０（６０’）と、利用者Ｍに所持されて識別情報ＩＤおよび担保金情報ＣＭを有するＩＣカード５０と、を含む。車載装置１０（１０’）は、利用運賃情報ＣＦとＩＣカード５０から読み出された識別情報ＩＤとを無線通信回線８５およびインターネットＮを介してサーバ装置６０（６０’）に送信する。
【0170】
そして、車載装置１０（１０’）は、(1) 識別情報ＩＤおよび利用運賃情報ＣＦがサーバ装置６０（６０’）に受信された場合、利用者Ｍの降車（乗車）を許容する情報ＭＳａを出力する［通信正常時］。また、(2) 識別情報ＩＤおよび／または利用運賃情報ＣＦがサーバ装置６０（６０’）に受信されない通信障害が発生した場合、ＩＣカード５０から読み出された担保金情報ＣＭに基づいて次のいずれかを行う［通信障害時］。(2a)利用運賃情報ＣＦから得られる利用運賃Ｘが担保金Ｙ以下であるときには、利用者Ｍの降車（乗車）を許容する情報ＭＳａを出力し、かつ、通信障害の解消後、サーバ装置６０（６０’）に通信障害情報ＦＣ、識別情報ＩＤおよび利用運賃情報ＣＦを送信する。また、(2b)利用運賃情報ＣＦから得られる利用運賃Ｘが担保金Ｙを超えるときには、利用者Ｍに利用運賃Ｘの現金支払いを要求する情報ＭＳｂを出力する。
【0171】
これにより、通信障害が発生して車載装置１０（１０’）とサーバ装置６０（６０’）が情報通信を行うことができない事態が生じても（上記(2)）、バス９０（９０’）の利用者Ｍは、利用運賃Ｘが担保金Ｙ以下である場合には、利用者Ｍの乗車や降車を許容する情報ＭＳａを出力されるので（上記(2a)）、運賃前払い方式の場合に乗車することが可能になり、また運賃後払い方式の場合には降車することが可能になる。そして、通信障害の解消後、車載装置１０（１０’）からサーバ装置６０（６０’）に対して、通信障害情報ＦＣ、識別情報ＩＤおよび利用運賃情報ＣＦが送信されるので、サーバ装置６０（６０’）は、通信障害情報ＦＣと、その通信障害により当該サーバ装置６０（６０’）が受信することができなかった識別情報ＩＤおよび利用運賃情報ＣＦとを、得ることが可能になる。例えば、バス９０（９０’）の事業者は、これらの情報に基づいて、事後的に利用運賃Ｘを運賃バリューＶから回収したり、利用運賃Ｘが運賃バリューＶを超えるときにはその超過分を担保金Ｙの範囲内で負債バリューＷの支払い債権を得たり、することが可能になる。これに対して、利用運賃Ｘが担保金Ｙを超えるときには、利用者Ｍに利用運賃Ｘの現金支払いを要求する情報ＭＳｂが出力されるので（上記(2b)）、当該利用者Ｍは利用運賃Ｘを現金で支払うことにより降車したり（乗車したり）することが可能になる。したがって、通信障害が生じた場合においても運賃収受を行うことができる。
【0172】
担保金Ｙの金額は、本運賃収受システム５の利用登録時において、利用者Ｍが任意に設定することが可能である。そのため、上述した無線通信回線８５による通信障害の発生が一時的なものであり発生頻度が運賃収受システム５の構成上、低いことが想定される場合、例えば、通勤や通学でバス９０を日常的に利用する利用者Ｍは、その往復の利用で必要になる往復利用運賃（片道利用運賃の２倍）を担保金Ｙとしてバス９０の運営事業者に提供することによって、当該利用者Ｍが負担する担保金Ｙの額を最小限に抑えることができる。また、例えば、日常的にキャッシュレス決済を利用しており現金を通常所持していない利用者Ｍは、不測の事態に備えて必要であると想定する任意の金額を担保金Ｙとしてバス９０の運営事業者に提供することによって、通信障害が発生してもキャッシュレスで当該バス９０に乗車したり降車したりすることができる。さらに、例えば、日常的に現金決済を利用している利用者Ｍは、バス９０の運営事業者が求める最小金額を担保金Ｙとして提供することによって、通信障害の発生の有無にかかわらず常に現金支払いで当該バス９０に乗車したり降車したりすることができる。
【0173】
なお、上述した実施形態では、車載装置１０（１０’）を構成する降車時端末３０（乗車時端末２０’）を運賃箱に隣接して設けるとともに、車載装置１０（１０’）を構成するホスト装置４０（４０’）の機能を運賃箱に担わせる構成を例示して説明したが、本発明の車載装置はこのような構成に限られない。例えば、読取りユニット３３（２３）や表示ユニット３５（２５）にそれぞれ相当するものが運賃箱に設けられている場合には、当該運賃箱に降車時端末３０（乗車時端末２０’）およびホスト装置４０（４０’）の機能を担わせるように構成してもよい。この場合には、降車時端末３０（乗車時端末２０’）の有線通信ユニット３７（２７）は不要になる。
【0174】
また、上述した実施形態では、情報担持媒体としてＩＣカード５０を用いて運賃収受システムを構成する場合を例示して説明したが、本発明の運賃収受システムは、識別情報および担保金情報を担持可能または記憶可能な情報媒体であれば、このような構成に限られない。例えば、二次元コード（ＱＲコード（登録商標）、ＰＤＦ４１７等）や一次元コード（ＪＡＮコード、ＣＯＤＥ３９等）を印刷した紙等の情報印刷媒体、これらのコードを画面表示可能な携帯情報端末装置（スマートフォン、携帯電話機等）等の情報表示媒体、識別情報ＩＤおよび担保金情報ＣＭを記録している磁気カード、接触式タイプのＩＣカード、ＲＦＩＤやＩＣカード５０の機能を備える携帯情報端末装置（スマートフォン、携帯電話機等等）等の情報記憶媒体でもよい。
【0175】
また、上述した実施形態では、担保金情報は、情報担持媒体としてのＩＣカード５０が有する場合を例示して説明したが、例えば、車載装置１０を構成するホスト装置４０（４０’）のメモリ４３に担保金情報ＣＭを記憶させたり保持させたりするように構成してもよい。また、ＩＣカード５０とホスト装置４０（４０’）のメモリ４３の両方に担保金情報ＣＭを保持させるように構成してもよい。これにより、ＩＣカード５０に代えて担保金情報ＣＭがホスト装置４０（４０’）のメモリ４３に記憶されている場合には、ＩＣカード５０は担保金情報ＣＭを保持する必要がないので、例えば、保持可能な情報が少ない一次元バーコードを用いて識別情報ＩＤを表示させることが可能になる。また、担保金情報ＣＭはホスト装置４０（４０’）に保持されるので、担保金情報ＣＭの改ざんを防止することも可能になる。また、ＩＣカード５０に加えてホスト装置４０（４０’）のメモリ４３にも記憶されている場合には、これらの両方に担保金情報ＣＭが記憶されて、担保金情報ＣＭの記憶を冗長構成にするので、いずれか一方の担保金情報ＣＭが壊れた場合においても残りの他方の担保金情報ＣＭを用いることが可能になる。
【0176】
また、上述した実施形態では、乗車時端末２０（２０’）および降車時端末３０の読取りユニット２３，３３として、非接触式タイプのＩＣカードリーダで構成する場合を例示して説明したが、情報担持媒体が有する識別情報および担保金情報を読み取り可能な装置であれば、情報担持媒体に担持された情報の読み取り方式（光学式、磁気式、電磁波式等）に合わせて、例えば、光学式コードリーダや磁気カードリーダ、ＲＦＩＤリーダ等でもよい。
【0177】
以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、上述した具体例を様々に変形または変更したものが含まれる。また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時の請求項に記載の組合せに限定されるものではない。さらに、本明細書または図面に例示した技術は、複数の目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つ。なお、[符号の説明]の欄における括弧内の記載は、上述した各実施形態で用いた用語と、特許請求の範囲に記載の用語との対応関係を明示し得るものである。
【符号の説明】
【0178】
５…運賃収受システム
１０，１０’…車載装置
１５…有線通信回線
２０，２０’…乗車時端末
３０…降車時端末
４０，４０’…ホスト装置
５０…ＩＣカード（情報担持媒体）
６０，６０’…サーバ装置
８０…基地局
８５…無線通信回線
９０，９０’…バス（交通機関の車両）
９１…乗車口
９３…降車口
１００，１００’…運賃収受処理
２００，２００’…乗車時読取り等処理
３００…降車時読取り等処理
４００，４００’…リカバリ処理
５００，５００’…運賃決済処理
ＢＳ，ＢＳａ，ＢＳｃ，ＢＳｄ，ＢＳｇ，ＢＳｚ…停留所
ＣＦ…利用運賃情報
ＣＭ…担保金情報
ＦＣ…通信障害情報
ＩＤ，ＩＤａ，ＩＤｂ…識別情報
Ｍ，Ｍａ，Ｍｂ…利用者
ＭＳ，ＭＳａ，ＭＳｂ…情報
Ｎ…インターネット
ＲＸ，ＲＸａ，ＲＸｂ，ＲＸｃ，ＲＸｅ…受信データ
ＴＸ，ＴＸａ，ＴＸｂ，ＴＸｃ，ＴＸｄ，ＴＸｅ…送信データ
Ｖ…運賃バリュー
Ｗ…負債バリュー
Ｘ…利用運賃
Ｙ…担保金
１０，１０’…車載装置
１５…有線通信回線
２０，２０’…乗車時端末
３０…降車時端末
４０，４０’…ホスト装置
５０…ＩＣカード（情報担持媒体）
６０，６０’…サーバ装置
８０…基地局
８５…無線通信回線
９０，９０’…バス（交通機関の車両）
９１…乗車口
９３…降車口
１００，１００’…運賃収受処理
２００，２００’…乗車時読取り等処理
３００…降車時読取り等処理
４００，４００’…リカバリ処理
５００，５００’…運賃決済処理
ＢＳ，ＢＳａ，ＢＳｃ，ＢＳｄ，ＢＳｇ，ＢＳｚ…停留所
ＣＦ…利用運賃情報
ＣＭ…担保金情報
ＦＣ…通信障害情報
ＩＤ，ＩＤａ，ＩＤｂ…識別情報
Ｍ，Ｍａ，Ｍｂ…利用者
ＭＳ，ＭＳａ，ＭＳｂ…情報
Ｎ…インターネット
ＲＸ，ＲＸａ，ＲＸｂ，ＲＸｃ，ＲＸｅ…受信データ
ＴＸ，ＴＸａ，ＴＸｂ，ＴＸｃ，ＴＸｄ，ＴＸｅ…送信データ
Ｖ…運賃バリュー
Ｗ…負債バリュー
Ｘ…利用運賃
Ｙ…担保金
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】