JP2020091564A - 定期券処理システム - Google Patents

Abstract

【課題】路線バスの定期券利用者の利便性を向上し得る定期券処理システムを提供する。【解決手段】実施形態の定期券処理システムでは、バス１０に搭載された乗車用カードリーダ３０により乗客が乗車するときに定期券であるＩＣカードを識別可能なカードＩＤを、ＩＣカードから読み出して出力し、運賃収受装置２０のＩＣカードＲ／Ｗにより乗客が降車するときにカードＩＤをＩＣカードから読み出して出力する。バス１０以外に設けられるサーバ４０は、カードＩＤに関連付けられたＩＣカードの利用可能期間および利用可能区間の情報を含む定期券情報を記憶している。運賃収受装置２０の制御ユニットにより乗客の乗車から降車までの間において、乗車用カードリーダ３０からのカードＩＤに基づいて無線通信回線を介してサーバ４０から定期券情報を取得するとともに当該定期券情報と運賃収受装置２０のＩＣカードＲ／ＷからのカードＩＤとに基づいて可否判定を行う。【選択図】図２

Description

本発明は、定期券処理システムに関し、例えば、路線バスにおいて乗客が定期券を利用して降車停留所で降車することの可否判定を行う定期券処理システムに関する。

定期券処理システムに関する技術として、例えば、下記特許文献１に開示される「改札システム」がある。この技術では、定期券を利用可能な定期券利用者が所持する乗車券の識別番号を、定期期間の開始日に合わせて駅の自動改札機に記憶させる。これにより、当該自動改札機は、多大なメモリを必要とすることなく、定期券利用者であるか否かの判定を行うことが可能になる。また、定期券利用者は、定期券の更新時に駅の窓口等で更新の手続を行う必要もなくなるため、利用者の利便性が向上する。

特開２００７−１７９４４８号公報

しかしながら、上記特許文献１に開示されている技術は、鉄道の駅の改札口に設置される改札機を対象にするものである。そのため、路線バスの車内に設けられる運賃収受装置等を含めた定期券処理システムには必ずしも適用が容易ではない。

即ち、改札機は駅の改札口に固定されているのに対して、車内に設けられる運賃収受装置は路線バスの運行に伴って移動する。そのため、駅の改札機は有線回線を利用できるのに対して路線バスの運賃収受装置は無線回線の利用に限られることから、通信環境を比較すると、運賃収受装置の場合には、改札機の場合よりも通信品質が低下する地域や通信不能の地点が存在し得るため、劣悪になり易い。

また、鉄道に比べて、路線バスは停留所の数が桁違いに多く、さらに停留所の増設や廃止も鉄道の駅よりも容易であり路線変更の頻度も格段に多い。また路線バスの場合には、定期券利用者が複数の路線を乗り継いで利用する乗り継ぎのバリエーションも、鉄道に比べて多様であり多い。

このため、例えば、定期券利用者が所持する定期券の識別番号を路線バスの運賃収受装置に記憶させる構成を採用したとしても、運賃収受装置にダウンロードする必要のある識別番号の数が膨大になり得るため、運賃収受装置のメモリ容量の不足や通信帯域の狭小化に起因したシステム動作の不具合を招き得る。したがって、特許文献１の開示技術は、路線バスの定期券処理システムには導入することが難しい。

本発明は、上述した課題を解決するためになされたものであり、路線バスの定期券利用者の利便性を向上し得る定期券処理システムを提供することを目的とする。

上記目的を達成するため、特許請求の範囲の請求項１に記載された定期券処理システムは、運賃後払い方式の路線バスにおいて乗客が定期券を利用して降車停留所で降車することの可否判定を行う定期券処理システムであって、前記乗客が前記路線バスに乗車するときに前記定期券を識別可能な識別データを前記定期券から読み出して出力する乗車時読出装置と、前記乗客が前記路線バスを降車するときに前記識別データを前記定期券から読み出して出力する降車時読出装置と、前記路線バス以外に設けられ前記識別データに関連付けられた前記定期券の利用可能期間および利用可能区間の情報を含む定期券情報を記憶している外部サーバと、前記乗客が乗車してから降車するまでの間において、前記乗車時読出装置から出力された前記識別データに基づいて無線通信回線を介して前記外部サーバから前記定期券情報を取得するとともに、前記乗客が前記路線バスを降車するときにおいて、当該取得した前記定期券情報と前記降車時読出装置から出力された前記識別データとに基づいて前記可否判定を行う降車可否判定装置と、を備えることを技術的特徴とする。

なお、「路線バス」とは、予め定められている路線を運行する乗合バスのことである。また「定期券」とは、定期乗車券のことであり、より具体的には、乗客である利用者の申告区間に対応して発券される「区間定期乗車券」や「区間定期券」のことである。さらに「降車停留所」とは、運行路線に設けられている始発地点、停留所および終着地点のうち、乗客の降車意思に応じて路線バスが停車する停車所のことである。また「定期券を識別可能な識別データ」には、定期券が有するＩＣメモリや磁気ストライプ等の情報記憶媒体（電磁的記録媒体）に記憶（記録）されている電子データのほかに、定期券の表面または裏面に表示や印刷されている、英数字や記号等から構成される印字データおよび一次元バーコードや二次元バーコード等も含まれる。また「定期券の利用可能期間」とは、当該定期券を利用（使用）することのできる期間、つまり定期券の有効期間のことである。また「定期券の利用可能区間」とは、当該定期券を利用（使用）して乗降可能な始発地点、停留所および終着地点のうち両端に位置する停車所のことである。また「乗車するとき」は、乗車時および乗車直後を含む概念である。また「降車するとき」は、降車直前および降車時を含む概念である。

請求項１に記載の定期券処理システムの発明では、乗車時読出装置により、乗客が路線バスに乗車するときに定期券を識別可能な識別データを定期券から読み出して出力し、降車時読出装置により、乗客が路線バスを降車するときに識別データを定期券から読み出して出力する。路線バス以外に設けられる外部サーバは、識別データに関連付けられた定期券の利用可能期間および利用可能区間の情報を含む定期券情報を記憶している。そして、降車可否判定装置により、乗客が乗車してから降車するまでの間において、乗車時読出装置から出力された識別データに基づいて無線通信回線を介して外部サーバから定期券情報を取得するとともに、乗客が路線バスを降車するときにおいて、当該取得した定期券情報と降車時読出装置から出力された識別データとに基づいて可否判定を行う。

これにより、乗客の定期券情報は、当該乗客が乗車してから降車するまでの間、つまり路線バスの走行中や降車停留所に到着するまでに、乗車時読出装置から出力された識別データに基づいて無線通信回線を介して外部サーバから取得される。即ち、定期券にはそれを識別可能な識別データを持たせれば、路線バスの走行中等に外部サーバから利用可能期間および利用可能区間の情報を取得することが可能になるため、利用可能期間や利用可能区間の情報を定期券が持たなくても当該乗客が路線バスを降車するときに降車可否判定装置により可否判定を行うことができる。そのため、定期券の更新等に関与する利用可能期間および利用可能区間の情報を定期券に持たせる必要がないので、当該乗客である定期券利用者は、定期券の更新時に路線バス会社の窓口等で更新の手続を行う必要がない。

また、特許請求の範囲の請求項２に記載された定期券処理システムは、請求項１に記載された定期券処理システムにおいては、前記定期券がストアードフェア機能を有するＩＣカードである場合において、前記降車可否判定装置は、前記乗客が前記定期券を利用して前記降車停留所で降車することができないと判定したときには、ストアードフェアデータから、前記乗客が乗車してから降車するまでの間の利用運賃分を減額して降車を許容することを技術的特徴とする。

請求項２に記載の定期券処理システムの発明では、降車可否判定装置は、乗客が定期券を利用して降車停留所で降車することができないと判定したときには、定期券のストアードフェアデータ（または定期券に対応するストアードフェアデータ）から利用運賃分を減額して降車を許容する。これにより、例えば、利用運賃分を現金で精算する必要がない。そのため、このような路線バスの利用場面においても定期券利用者の利便性を向上させることが可能になる。

さらに、特許請求の範囲の請求項３に記載された定期券処理システムは、請求項２に記載された定期券処理システムにおいて、前記降車可否判定装置は、少なくとも前記ストアードフェアデータから前記利用運賃分を減額した場合には、前記利用運賃分の情報を前記外部サーバに送ることを技術的特徴とする。なお、「利用運賃分の情報」には、利用運賃分を算出可能な情報も含まれる。

請求項３に記載の定期券処理システムの発明では、降車可否判定装置は、少なくともストアードフェアデータから利用運賃分を減額した場合には、利用運賃分の情報を外部サーバに送る。これにより、外部サーバでは、定期券の（または定期券に対応する）ストアードフェアデータから利用運賃分を減額したことを把握することが可能になる。そのため、例えば、乗客の定期券情報が外部サーバに記憶されているにもかかわらず、無線通信回線の通信不具合等により、乗客が乗車してから降車するまでの間に外部サーバから乗客の定期券情報を取得できない場合が生じたときには、それをリカバリする処理（例えば、減額した運賃と同等価値の、ＳＦバリューやＳＦポイントを加算するようにストアードフェアデータを変更する）を外部サーバ等において行うことが可能になる。なお、ＳＦバリューは、ストアードフェアにおいて金銭と同等の交換価値を有する電子データのことである。またＳＦポイントは、ＳＦバリューの使用額に応じて付与される電子データのことであり、運賃の支払い等に使用することのできるものである。

また、特許請求の範囲の請求項４に記載された定期券処理システムは、請求項３に記載された定期券処理システムにおいて、前記外部サーバは、前記定期券に対応する前記定期券情報を記憶している場合に前記降車可否判定装置から前記利用運賃分の情報を受けたときは、当該利用運賃分の情報を、前記ＩＣカードの前記ストアードフェアデータを変更可能なＳＦデータ変更装置に提供可能にすることを技術的特徴とする。

請求項４に記載の定期券処理システムの発明では、外部サーバは、定期券に対応する定期券情報を記憶している場合に降車可否判定装置から利用運賃分の情報を受けたときは、当該利用運賃分の情報を、ＩＣカードのストアードフェアデータを変更可能なＳＦデータ変更装置に提供可能にする。「定期券に対応する定期券情報を記憶している場合に降車可否判定装置から利用運賃分の情報を受けたとき」とは、乗客の定期券情報が外部サーバに記憶されているにもかかわらず、例えば、無線通信回線の通信不具合等により、乗客が乗車してから降車するまでの間に外部サーバから乗客の定期券情報を取得できない場合、乗客が定期券を利用して降車停留所で降車することができないと判定してＩＣカードの（またはＩＣカードに対応する）ストアードフェアデータから利用運賃分を減額したときである。

つまり、乗客はその定期券を利用して降車停留所で降車できる場合であったにもかかわらず、定期券を利用できない場合と同様にストアードフェアデータから利用運賃分を減額されたケースである。このようなケースにおいては、外部サーバは、当該利用運賃分の情報をＳＦデータ変更装置に提供し得る。これにより、ＳＦデータ変更装置によって、例えば、事後的に当該利用運賃分を補填するようにＩＣカードのストアードフェアデータを変更することが可能になる。

さらに、特許請求の範囲の請求項５に記載された定期券処理システムは、請求項３に記載された定期券処理システムにおいて、前記外部サーバは、前記定期券に対応する前記定期券情報を記憶している場合に前記降車可否判定装置から前記利用運賃分の情報を受けたときは、当該利用運賃分の情報を、前記外部サーバに記憶されている前記定期券情報を変更可能な定期券情報変更装置に提供可能にすることを技術的特徴とする。

請求項５に記載の定期券処理システムの発明では、外部サーバは、定期券に対応する定期券情報を記憶している場合に降車可否判定装置から利用運賃分の情報を受けたときは、当該利用運賃分の情報を、外部サーバに記憶されている定期券情報を変更可能な定期券情報変更装置に提供可能にする。「定期券に対応する定期券情報を記憶している場合に降車可否判定装置から利用運賃分の情報を受けたとき」とは、乗客の定期券情報が外部サーバに記憶されているにもかかわらず、例えば、無線通信回線の通信不具合等により、乗客が乗車してから降車するまでの間に外部サーバから乗客の定期券情報を取得できない場合、乗客が定期券を利用して降車停留所で降車することができないと判定してＩＣカードの（またはＩＣカードに対応する）ストアードフェアデータから利用運賃分を減額したときである。

つまり、乗客はその定期券を利用して降車停留所で降車できる場合であったにもかかわらず、定期券を利用できない場合と同様にストアードフェアデータから利用運賃分を減額されたケースである。このようなケースにおいては、外部サーバは、当該利用運賃分の情報を定期券情報変更装置に提供し得る。これにより、定期券情報変更装置によって、例えば、定期券の更新手続等により定期券情報を変更するときに、当該利用運賃分だけ更新料金を割り引いたり、当該運賃額相当分だけ更新期間を延長したりすることが可能になる。

本発明の定期券処理システムでは、定期券の更新等に関与する利用可能期間および利用可能区間の情報を定期券に持たせる必要がないので、定期券の利用者は、定期券の更新時に路線バス会社の窓口等で更新の手続を行う必要がない。したがって、路線バスの定期券利用者の利便性を向上させることが可能になる。

本発明の一実施形態に係る定期券処理システムの構成例を示すシステム構成図である。 本実施形態の定期券処理システムを構成する運賃収受装置、乗車用カードリーダおよびサーバにより、路線バスの運行時において実行される各処理の流れを示すシーケンス図である。 乗車用カードリーダが路線バスの乗車期間中において実行する乗車期間処理の流れを示すフローチャートである。 運賃収受装置が路線バスの乗車期間中において実行する乗車期間処理の流れを示すフローチャートである。 サーバが路線バスの乗車期間中において実行する乗車期間処理の流れを示すフローチャートである。 サーバが路線バスの走行期間中において実行する走行期間処理の流れを示すフローチャートである。 運賃収受装置が路線バスの走行期間中において実行する走行期間処理の流れを示すフローチャートである。 サーバが路線バスの走行期間中において実行する走行期間処理の流れを示すフローチャートである。 運賃収受装置が路線バスの降車期間中において実行する降車期間処理の流れを示すフローチャートである。 運賃収受装置およびサーバにより、路線バスの運行期間やサーバのバッチ処理期間において実行される各処理の流れを示すシーケンス図である。 運賃収受装置が路線バスの運行期間中において実行する利用明細処理の流れを示すフローチャートである。 サーバが路線バスの運行期間中において実行する利用明細処理の流れを示すフローチャートである。 サーバがバッチ処理期間中において実行するリカバリ処理の流れを示すフローチャートである。

以下、本発明の定期券処理システムの実施形態について図を参照して説明する。まず、本発明の実施形態に係る定期券処理システムの構成例を図１に基づいて説明する。図１には、定期券処理システムの構成例を示すシステム構成図が図示されている。

本実施形態は、路線バス（以下「バス」という）１０の利用者（以下「利用者」という）が後方口１４から乗車した後、前方口１２から降車する際に運賃を支払う「後乗り前降り後払い方式」のバス１０に、本発明の定期券処理システムを適用した例である。なお、利用者は、当該バス１０の乗客であり、ＩＣカードタイプの定期券を利用する場合もある。また、バス１０はワンマン運行方式である。「後乗り前降り後払い方式」は、運賃後払い方式の一態様であり、典型的には、距離に応じて金額が増加する運賃体系を採る。

図１に示すように、本実施形態の定期券処理システム（以下「本システム」という）は、主に、バス１０の前方口１２付近に搭載される運賃収受装置２０と、バス１０の後方口１４付近に搭載される乗車用カードリーダ３０と、バス１０の運行事業者（路線バス会社）等に設けられるサーバ４０等と、から構成されている。バス１０とサーバ４０は、無線通信回線９０を介してデータ通信可能であり、またサーバ４０は、インターネット１００等を介して、バスターミナル等のＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１や、バスターミナル構内６０の定期券発行装置６１等とデータ通信可能である。

《運賃収受装置２０》
運賃収受装置２０は、バス１０の車内に設けられる、制御ユニット２１、ＩＣカードリーダ／ライタ（以下「ＩＣカードＲ／Ｗ」という）２６、液晶表示ユニット２７、有線通信ユニット２８、無線通信ユニット２９等を含んで構成されている。なお、図１では、運賃収受装置２０を構成する運賃収受機構や金庫等の図示を省略している。

制御ユニット２１は、ＩＣカードＲ／Ｗ２６、液晶表示ユニット２７、有線通信ユニット２８、無線通信ユニット２９等を制御するコントローラであり、ＭＰＵ２２、メモリ２３、入出力インタフェース２４等から構成されている。ＭＰＵ２２は、運賃収受装置２０を制御する演算処理装置であり、システムバスやデータバス等を介して、メモリ２３や入出力インタフェース２４等と接続されている。本実施形態では、制御ユニット２１は、ＩＣカードＲ／Ｗ２６等のほかに運賃収受機構の駆動ユニット等も制御している。

メモリ２３は、半導体記憶装置であり、ＭＰＵ２２が使用する主記憶空間を構成するものである。本実施形態では、プログラム領域を担うＲＯＭとワーク領域やデータ領域に割り当てられるＤＲＡＭとにより構成されている。ＲＯＭには、ＩＣカードＲ／Ｗ２６等や運賃収受機構の駆動ユニット等を制御するシステムプログラムや、後述する乗車期間処理２１００、走行期間処理２２００、降車期間処理２３００や利用明細処理２４００等の各制御プログラムが格納されている。また、ＤＲＡＭには、サーバ４０から送信されてきた定期券情報を格納する定期券情報格納領域や後述の降車期間処理２３００により生成される利用明細情報格納領域が確保されている。

入出力インタフェース２４は、制御ユニット２１の周辺装置に対して、シリアル（ＵＳＢ規格等）またはパラレル（IEEE1284規格等）のデータのやり取りを仲介する入出力インタフェース装置である。本実施形態では、ＩＣカードＲ／Ｗ２６、液晶表示ユニット２７、有線通信ユニット２８、無線通信ユニット２９や運賃収受機構の駆動ユニット等と接続可能に構成されている。

ＩＣカードＲ／Ｗ２６は、主に、ＩＣカード７０のＩＣチップ７１に記憶されたデータを読み出すＩＣカードリーダと、同ＩＣチップ７１にデータを書き込むＩＣカードライタと、により構成されている降車時読出装置であり、制御ユニット２１の入出力インタフェース２４に接続されている。本実施形態では、ＩＣチップ７１は、半導体メモリを含んで構成されており、当該半導体メモリには、ＩＣカード７０のカードＩＤ（識別データ）等のデータが記憶されている。

ＩＣカードＲ／Ｗ２６は、利用者がＩＣカード７０をタッチし易い位置、例えば、運賃収受装置２０の上部に運賃収受機構と並んで設けられている。ＩＣカードＲ／Ｗ２６が読み出したＩＣカード７０のカードＩＤ等のデータは、制御ユニット２１に出力される。また、制御ユニット２１から出力される乗車日時や乗車区間等のデータは、ＩＣカードＲ／Ｗ２６を介してＩＣカード７０に書き込まれる。

なお、カードＩＤは、英数字や記号の組み合わせで構成されるＩＣカード７０ごとに固有の情報であり、例えば、ＩＣカード７０の製造時にＩＣチップ７１に書き込まれたり、利用者に渡される前のＩＣカード７０の発行時にＩＣチップ７１に書き込まれたりする。本実施形態では、ＩＣカード７０は、ストアードフェア機能付きのバス１０の定期券として使用（利用）される。以下、ストアードフェア（stored fare）を「ＳＦ」と略して記載する場合があるので、注意されたい。

液晶表示ユニット２７は、利用者に対して運賃や支払い金額に関する情報等を明示する告知装置であり、この装置も制御ユニット２１の入出力インタフェース２４に接続されている。本実施形態では、ＩＣカード７０をＩＣカードＲ／Ｗ２６にかざした場合に、その読み出し結果（後述する情報処理の結果）や、定期券の表面に明示されるべき内容（利用可能区間や利用可能期間（有効期間））を表示して、利用者に告知する。なお、液晶表示ユニット２７は、液晶に代えてＬＥＤで表示したり、液晶とＬＥＤの併用で表示したりするように構成してもよい。

有線通信ユニット２８は、制御ユニット２１と乗車用カードリーダ３０等とのデータのやり取りを有線通信回線８０により行うもので、例えば、RS-422やRS-485等のシリアル伝送によりデータ通信可能な通信規格に準拠したものである。有線通信ユニット２８も制御ユニット２１の入出力インタフェース２４に接続されている。

無線通信ユニット２９は、制御ユニット２１と外部とのデータのやり取りを無線通信回線９０により行うもので、例えば、データ通信可能な業務無線装置や携帯電話装置等が使用される。本実施形態では、データ通信は、無線パケット通信網を介して行われる。無線通信ユニット２９も制御ユニット２１の入出力インタフェース２４に接続されている。

なお、制御ユニット２１には、前方口１２や後方口１４の扉の開閉状態を検出可能な図略のドアセンサが入出力インタフェース２４を介して接続されている。これにより、バス１０が停留所に停車している期間中であるか否かを扉の開閉状態（開状態は停車中、閉状態は走行中）に関する情報に基づいて検出することができる。後方口１４の扉の開閉状態に関する情報は、有線通信回線８０を介して乗車用カードリーダ３０に送られる。

《乗車用カードリーダ３０》
乗車用カードリーダ３０は、ＩＣカードＲ／Ｗ２６のＩＣカードリーダとほぼ同様の機能を備えた乗車時読出装置であり、バス１０の後方口１４の付近に例えば整理券発行機と並んで設けられている。

即ち、乗車用カードリーダ３０は、主に、制御ユニット３１、ＩＣカードリーダ３３、表示ユニット３５、通信ユニット３７等により構成されており、ＩＣカード７０のＩＣチップ７１に記憶されたカードＩＤ（識別データ）等をＩＣカードリーダ３３により読み出した後、カードＩＤ等のデータを通信ユニット３７を介して運賃収受装置２０に出力する機能を持っている。

制御ユニット３１は、図略のＭＰＵ、メモリ、入出力インタフェースやシステムバス等から構成されている演算処理装置であり、入出力インタフェースを介して接続されているＩＣカードリーダ３３、表示ユニット３５、通信ユニット３７等を制御するコントローラである。制御ユニット３１のメモリには、後述する乗車期間処理１１００等の制御プログラムが格納されている。なお、通信ユニット３７は、運賃収受装置２０の有線通信ユニット２８と同様に構成されているため、説明を省略する。

ＩＣカードリーダ３３は、ＩＣカードＲ／Ｗ２６のＩＣカードリーダと同様に構成されており、タッチ面にＩＣカード７０を近づけるか、または軽くタッチ（接触）させることで、ＩＣカード７０のＩＣチップ７１に記憶されたデータが読み出される。ＩＣカードリーダ３３のタッチ面は、表示ユニット３５の発光部としても機能しており、例えば、正常に読み出された場合には緑色に発光する。また、読み出しに失敗したり読み出したデータが異常であったりした場合には、例えば、タッチ面が赤色に発光する。これらの発光は、例えば、ＬＥＤにより行われる。

《サーバ４０》
サーバ４０は、主に、制御装置４１、データベース装置４３、無線通信装置４５等から構成されているファイルサーバである。制御装置４１は、データベース装置４３や無線通信装置４５に接続されてこれらを制御する情報処理装置であり、例えば、インターネット１００に接続されているネットワーク機器やサーバコンピュータにより構成されている。データベース装置４３は、大容量の情報記憶媒体であり、例えば、記憶容量が数１００ＴＢ（テラバイト）のデータストレージ装置である。

サーバコンピュータのメモリやストレージデバイス（以下「メモリ等」という）には、後述する乗車期間処理３１００、走行期間処理３２００、走行期間処理３３００、利用明細処理３４００やリカバリ処理３５００等の各制御プログラムが格納されている。また、同メモリには、運賃収受装置２０から送信されてきたカードＩＤを格納するカードＩＤ格納領域やカードＩＤ再送領域が確保されている。また、同メモリには、運賃収受装置２０から送信されてきた利用明細情報を格納する利用明細情報格納領域も確保されている。なお、無線通信装置４５は、運賃収受装置２０の無線通信ユニット２９と同様に構成されているため、説明を省略する。

サーバ４０は、より具体的には、データベース装置４３に蓄積されている、カードＩＤやカードＩＤに関連付けられた定期券情報、さらにはＳＦバリューやＳＦポイント（ストアードフェアデータ）の情報等、ＩＣカード７０に紐付けられた様々な情報に対するアクセス制御やデータ管理等を行う。本実施形態では、データベース装置４３に対するアクセスは、例えば、無線通信回線９０を介してバス１０の運賃収受装置２０から行われたり、インターネット１００を介してＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１や駅構内６０の定期券発行装置６１から行われたりする。

<<< バス運行時の処理 >>>
次に、図２〜図９を参照しながら本システムにおける各処理の流れを説明する。まず、図２に基づいて各処理の概要を説明する。図２には、運賃収受装置２０、乗車用カードリーダ３０およびサーバ４０により、運行時において実行される各処理の流れを示すシーケンス図が図示されている。

＜乗車期間＞
図２に示すように、乗車期間、即ち停留所等にバス１０が停車している期間においては、停車中のバス１０に利用者が乗車すると、当該利用者は、後方口１４付近に設けられている乗車用カードリーダ３０（のＩＣカードリーダ３３）にＩＣカード７０をかざしたりタッチしたりする。すると、乗車用カードリーダ３０では、後述する乗車期間処理１１００によりＩＣカード７０からカードＩＤを読み取った後、有線通信回線８０を介して運賃収受装置２０に当該カードＩＤを送る。

一方、運賃収受装置２０では、乗車用カードリーダ３０からカードＩＤを受け取ると、乗車期間処理２１００により所定の情報処理を行った後、無線通信回線９０を介してサーバ４０にカードＩＤを送信する。また、サーバ４０では、乗車期間処理３１００により運賃収受装置２０からカードＩＤを受信すると、受信したカードＩＤをサーバコンピュータのメモリ等に保存する。

このような一連の処理（乗車期間処理１１００→乗車期間処理２１００→乗車期間処理３１００）は、乗車期間中において、乗車用カードリーダ３０が利用者のＩＣカード７０からカードＩＤを読み取るたびごとに繰り返し行われる。

［乗車期間処理１１００］
図３に示す乗車期間処理１１００は、乗車用カードリーダ３０の制御ユニット３１により実行される処理であり、バス１０の後方口１４の扉が開いている期間中に繰り返し実行される。後方口１４の扉の開閉状態に関する情報は、有線通信回線８０を介して運賃収受装置２０から制御ユニット３１が取得する。図３には、乗車用カードリーダ３０が実行する乗車期間処理１１００の流れを示すフローチャートが図示されている。

乗車期間処理１１００では、まずステップＳ１１０１により制御ユニット３１のメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ＩＣカードリーダ３３がＩＣカード７０（のＩＣチップ７１）からカードデータを読み取ったか否かの判定がステップＳ１１０３により行われる。

そして、ＩＣカードリーダ３３によりＩＣカード７０の読み取りが行われていると制御ユニット３１が判定した場合には（Ｓ１１０３；Ｙｅｓ）、次のステップＳ１１０５により当該読み取られたカードデータの内容を解析する処理が行われる。これに対して、ＩＣカード７０の読み取りが行われていないと制御ユニット３１が判定した場合には（Ｓ１１０３；Ｎｏ）、利用者がＩＣカード７０をタッチ等していないことになるから、本処理１１００を終える。

ステップＳ１１０５のカードデータ解析処理では、カードデータを構成する情報内容の解析が行われる。本実施形態では、予め定められたデータ形式やデータフォーマットに従って所定のデータ項目（例えば、バス事業者名、定期券発行日、カードＩＤ、乗車日時、乗車区間、ＳＦバリューの残額やＳＦポイントの残数等）がすべてＩＣカード７０に記憶されているか否かが調べられその結果（解析結果）が生成される。この解析結果は、次の判定処理（Ｓ１１０７）に用いられる。

即ち、ステップＳ１１０７では、当該解析結果から、所定のデータ項目が存在し正常であると判定された場合には（Ｓ１１０７；Ｙｅｓ）、続くステップＳ１１０９により表示ユニット３５に読取り完了を表示させる処理が行われる。これに対して、当該解析結果から、不足するデータ項目があると判定された場合、つまりカードデータが壊れている（異常である）場合には（Ｓ１１０７；Ｎｏ）、ステップＳ１１１１により表示ユニット３５に読取りエラーを表示させる処理が行われる。

ステップＳ１１０７によりデータ項目が正常であると判定された場合には（Ｓ１１０７；Ｙｅｓ）、ステップＳ１１１３によりカードデータからカードＩＤを抽出して運賃収受装置２０に送出した後、一連の本処理１１００を終了する。このカードＩＤの送出は、有線通信回線８０を介して行われるため、データの送信エラー等が発生する可能性は極めて低い。ただし、構成によっては送信エラー発生時の送信リトライ処理を追加してもよい。

［乗車期間処理２１００］
図４に示す乗車期間処理２１００は、運賃収受装置２０の制御ユニット２１により実行される処理であり、バス１０の前方口１２の扉が開いている期間中に繰り返し実行される。図４には、運賃収受装置２０が実行する乗車期間処理２１００の流れを示すフローチャートが図示されている。

乗車期間処理２１００では、まずステップＳ２１０１により制御ユニット２１のメモリ２３の本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、有線通信ユニット２８からデータの入力（入力データ）が有るか否かの判定がステップＳ２１０３により行われる。例えば、入力データが有る場合には（Ｓ２１０３；Ｙｅｓ）、有線通信ユニット２８の入力バッファに入力データが保持されているため、そのデータが取得された後、続くステップＳ２１０５によりカードＩＤ抽出処理が行われる。これに対して、入力データが有ると判定されない場合には（Ｓ２１０３；Ｎｏ）、乗車用カードリーダ３０からカードＩＤ等のデータが送られていないことになるから、本処理２１００を終える。

ステップＳ２１０５のカードＩＤ抽出処理では、入力データからカードＩＤを抽出（取得）する処理が行われる。これにより取得されたカードＩＤは、続くステップＳ２１０７により所定の送信データフォーマットに組み込まれて送信データとして生成される。ステップＳ２１０７の送信データ生成処理により生成された送信データは、次のステップＳ２１０９によりサーバ４０に送信される。より具体的には、送信データは、制御ユニット２１により制御される無線通信ユニット２９によって無線通信回線９０を介してサーバ４０に無線送信される。

運賃収受装置２０からの送信データがサーバ４０により正常に受信されると、例えば、サーバ４０から肯定応答（ＡＣＫ）のデータが送信されて運賃収受装置２０の無線通信ユニット２９に届く。もしサーバ４０が送信データを正常に受信することができなかったときには、否定応答（ＮＡＣＫ）のデータがサーバ４０から送信されて無線通信ユニット２９に届いたり、所定時間を経過（タイムアウト）しても何ら応答データが届かなかったりする。そのため、運賃収受装置２０は、続くステップＳ２１１１により、サーバ４０から届くこれらの応答データを無線通信ユニット２９を介して受信し（送信結果受信処理）、応答データを取得する。

そして、ステップＳ２１１３により送信エラーが有るか否かの判定が行われる。即ち、ステップＳ２１１１により取得された応答データが肯定応答（ＡＣＫ）のデータであるときには、送信エラーが発生していない（送信エラーがない）ことになるので（Ｓ２１１３；Ｎｏ）、そのまま本処理２１００を終える。

これに対して応答データが否定応答（ＮＡＣＫ）のデータであるときや、応答データを受信できていないときには、送信エラーが発生している（送信エラーが有る）ことになるので（Ｓ２１１３；Ｙｅｓ）、リトライカウンタをインクリメント（＋１）して所定のリトライ回数を超えていない場合には（Ｓ２１１５；Ｎｏ）、ステップＳ２１０９に戻って再度、送信処理を行う。

リトライカウンタをインクリメント（＋１）した結果、所定のリトライ回数を超えている場合には（Ｓ２１１５；Ｙｅｓ）、制御ユニット２１は、サーバ４０に対するカードＩＤの送信を止めて本処理２１００を終了する。所定のリトライ回数は、例えば、５回に設定される。

なお、所定のリトライ回数を超えている場合において（Ｓ２１１５；Ｙｅｓ）、例えば、カードＩＤ再送フラグを設けてそれを「１」にセットし、カードＩＤ再送フラグが「１」である場合には、所定時間（例えば、６０秒〜１２０秒）の経過後に、再度、本処理２１００をステップＳ２１０９から開始するように、例えば、後述する利用明細処理２４００のように本処理２１００のアルゴリズムを構成してもよい。これにより、例えば、時間経過に伴うバス１０の進行によって走行経路周辺の電波伝搬状態が変動し得ることから、サーバ４０に対するカードＩＤの送信完了の可能性が向上する。

［乗車期間処理３１００］
図５に示す乗車期間処理３１００は、サーバ４０の制御装置４１のサーバコンピュータにより実行される処理であり、バス１０の運行期間中に繰り返し実行される。図５には、サーバ４０が実行する乗車期間処理３１００の流れを示すフローチャートが図示されている。

乗車期間処理３１００では、まずステップＳ３１０１により制御装置４１のサーバコンピュータのメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ステップＳ３１０３により無線通信装置４５の受信データが有るか否かの判定が行われる。例えば、受信データが有る場合には（Ｓ３１０３；Ｙｅｓ）、無線通信装置４５の受信バッファに受信データが保持されているため、そのデータが取得された後、続くステップＳ３１０５により受信データ解析処理が行われる。これに対して、受信データが有ると判定されない場合には（Ｓ３１０３；Ｎｏ）、運賃収受装置２０からカードＩＤを含む送信データが送信されていないことになるから、本処理３１００を終える。

ステップＳ３１０５の受信データ解析処理では、受信データを構成する情報内容の解析が行われる。本実施形態では、予め定められたデータ形式やデータフォーマットに従ってカードＩＤが入っているか否かが調べられその結果（解析結果）が生成される。この解析結果は、次の判定処理（Ｓ３１０７）に用いられる。

続くステップＳ３１０７では、この解析結果から、カードＩＤが存在し正常であると判定された場合には（Ｓ３１０７；Ｙｅｓ）、続くステップＳ３１０９により正常受信情報（つまり肯定応答（ＡＣＫ））が運賃収受装置２０に送信される。一方、当該解析結果から、例えば、カードＩＤのデータが壊れておりカードＩＤが存在しないと判定された場合（Ｓ３１０７；Ｎｏ）、ステップＳ３１１１により受信エラー情報（つまり否定応答（ＮＡＣＫ））が運賃収受装置２０に送信される。

ステップＳ３１０７によりカードＩＤが存在し正常であると判定された場合（Ｓ３１０７；Ｙｅｓ）、続くステップＳ３１１３によりサーバコンピュータのメモリ等のうち予め設けられているカードＩＤ格納領域に当該カードＩＤを保存する処理が行われて、一連の本処理３１００を終了する。

＜走行期間＞
図２に示すように、走行期間、即ちバス１０が前の停留所を出発してから次の停留所に到着するまでの期間においては、サーバ４０は、乗車期間中に運賃収受装置２０から受信して保存したカードＩＤに対して、それに関連付けられた定期券情報を走行期間処理３２００により検索した後、検索された定期券情報を無線通信回線９０を介して運賃収受装置２０に送信する。サーバ４０では、このような走行期間処理３２００を保存したすべてのカードＩＤに対して行う。また、通信環境等に起因して送信エラーが発生した場合には、当該検索された定期券情報等を走行期間処理３３００により、再度、運賃収受装置２０に送信する。

これに対して運賃収受装置２０では、走行期間処理２２００によりカードＩＤに関連付けられた定期券情報がサーバ４０から受信されると、受信した定期券情報を制御ユニット２１のメモリ２３等に保存する。定期券情報には、少なくとも、利用者のＩＣカード７０を定期券として機能させ得る、利用可能期間および利用可能区間の情報が含まれる。定期券の利用可能期間とは、当該定期券を利用（使用）することのできる期間、つまり定期券の有効期間のことである。また、定期券の利用可能区間とは、当該定期券を利用（使用）して乗降可能な、始発地点、停留所および終着地点のうち、両端に位置する停車所のことである。

このような一連の処理（走行期間処理３２００，３３００→走行期間処理２２００）は、走行期間中において、サーバ４０から運賃収受装置２０に定期券情報が送信されるごとに繰り返し行われる。

［走行期間処理３２００］
図６に示す走行期間処理３２００は、サーバ４０のサーバコンピュータにより実行される処理であり、バス１０の運行期間中に実行される。図６には、サーバ４０が実行する走行期間処理３２００の流れを示すフローチャートが図示されている。

走行期間処理３２００では、まずステップＳ３２０１により制御装置４１のサーバコンピュータのメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ステップＳ３２０３によりサーバコンピュータのメモリのうち予め設けられているカードＩＤ格納領域に保存されているカードＩＤを読み出す処理が行われる。このカードＩＤは、前述した乗車期間処理３１００のカードＩＤ保存処理（Ｓ３１１３）によりカードＩＤ格納領域に保存されたものであり、乗車期間処理２１００の送信処理（Ｓ２１０９）により運賃収受装置２０から送信されたカードＩＤの数分、即ち直近に停車した停留所において乗車した利用者の人数分だけ保存されている。

続くステップＳ３２０５ではデータベース検索処理が行われる。この処理では、カードＩＤに関連付けられている定期券情報をデータベース装置４３から探し出す。データベース装置４３には、定期券を発行している全利用者の定期券情報が蓄積されているため、カードＩＤが現在も有効である場合には、必ずデータベース装置４３から当該カードＩＤに対応する定期券情報を見つけることが可能である。もし見つけることができない場合は、そのカードＩＤが過去に発行した定期券であって現在は有効期限が満了しているものに対応しているか、またはカードＩＤ自体がバス１０の運行事業者以外が発行したものであるか等が想定される。

ステップＳ３２０５のデータベース検索処理によって、サーバ４０のサーバコンピュータがカードＩＤに対応する（関連付けられた）定期券情報を見つけることができた場合には、ステップＳ３２０７により該当する定期券情報が取得される。また定期券情報を見つけることができない場合には、ステップＳ３２０７により検索エラー情報が取得される。なお、本実施形態では、ステップＳ３２０５によりデータベース検索処理が終了したカードＩＤについては、例えば、サーバコンピュータのメモリ等に設けられているカードＩＤ格納領域から削除する。

ステップＳ３２０７により取得した定期券情報または検索エラー情報（以下「定期券情報等」という）は、続くステップＳ３２０９により所定の送信データフォーマットに組み込まれて送信データとして生成される。ステップＳ３２０９の送信データ生成処理により生成された送信データは、次のステップＳ３２１１により運賃収受装置２０に送信される。より具体的には、送信データは、制御ユニット２１のサーバコンピュータにより制御される無線通信装置４５によって無線通信回線９０を介して運賃収受装置２０に無線送信される。

サーバ４０からの送信データが運賃収受装置２０により正常に受信されると、例えば、運賃収受装置２０から肯定応答（ＡＣＫ）のデータが送信されてサーバ４０の無線通信装置４５に届く。もし運賃収受装置２０が送信データを正常に受信することができなかったときには、否定応答（ＮＡＣＫ）のデータが運賃収受装置２０から送信されて無線通信装置４５に届いたり、所定時間を経過（タイムアウト）しても何ら応答データが届かなかったりする。そのため、サーバコンピュータは、続くステップＳ３２１３により、運賃収受装置２０から届くこれらの応答データを無線通信装置４５によって無線通信回線９０を介して受信し（送信結果受信処理）、応答データを取得する。

そして、ステップＳ３２１５により送信エラーが有るか否かの判定が行われる。即ち、ステップＳ３２１３により取得された応答データが肯定応答（ＡＣＫ）のデータであるときには、送信エラーが発生していない（送信エラーがない）ことになるので（Ｓ３２１５；Ｎｏ）、サーバコンピュータは、ステップＳ３２２１に処理を移行して未検索のカードＩＤが有るか否かを判定する。

即ち、前述のカードＩＤ格納領域には、直近で停車した停留所において乗車した利用者の人数分だけカードＩＤが保存されているので、そのすべてについてデータベース検索処理が完了しているか否かがステップＳ３２２１により判定される。例えば、本実施形態では、データベース検索処理（Ｓ３２０５）が終了したカードＩＤは、カードＩＤ格納領域から削除されることから、カードＩＤ格納領域に保存されているカードＩＤの残数をカウンタやポインタ等で確認することによりステップＳ３２２１による判定が可能になる。

もし未検索のカードＩＤがカードＩＤ格納領域に残っている場合には（Ｓ３２２１；Ｙｅｓ）、サーバコンピュータは、カードＩＤ読出処理（Ｓ３２０３）に戻ってカードＩＤ格納領域からカードＩＤを読み出した後、データベース検索処理（Ｓ３２０５）により定期券情報を検索する。

これに対して応答データが否定応答（ＮＡＣＫ）のデータであるときや、応答データを受信できていないときには、送信エラーが発生している（送信エラーが有る）ことになるので（Ｓ３２１５；Ｙｅｓ）、サーバコンピュータは、リトライカウンタをインクリメント（＋１）して、所定のリトライ回数を超えていない場合には（Ｓ３２１７；Ｎｏ）、ステップＳ３２１１に戻って再度、送信処理を行う。

リトライカウンタをインクリメント（＋１）した結果、所定のリトライ回数を超えている場合には（Ｓ３２１７；Ｙｅｓ）、サーバコンピュータは、ステップＳ３２１９の送信エラー処理により運賃収受装置２０に対する定期券情報等の送信を止めるとともに、定期券情報再送フラグを「１」にセットする。運賃収受装置２０に送信することのできなかった送信データに含まれ定期券情報等に関連付けられているカードＩＤは、サーバコンピュータのメモリ等のうち予め設けられているカードＩＤ再送領域に保存される。また、定期券情報再送フラグは、カードＩＤ再送領域に保存される当該カードＩＤに付加される。

続くステップＳ３２２１では、前述したように未検索のカードＩＤが有るか否かの判定処理が行われて、また未検索のカードＩＤがない場合には（Ｓ３２２１；Ｎｏ）、一連の本処理３２００を終了する。

［走行期間処理２２００］
図７に示す走行期間処理２２００は、運賃収受装置２０の制御ユニット２１により実行される処理であり、バス１０の走行期間中（バス１０の前方口１２および後方口１４の扉がいずれも閉じている期間中）、繰り返し実行される。図７には、運賃収受装置２０が実行する走行期間処理２２００の流れを示すフローチャートが図示されている。

走行期間処理２２００では、まずステップＳ２２０１により制御ユニット２１のメモリ２３のメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、無線通信ユニット２９の受信データが有るか否かの判定がステップＳ２２０３により行われる。例えば、受信データが有る場合には（Ｓ２２０３；Ｙｅｓ）、無線通信ユニット２９の受信バッファに受信データが保持されているため、そのデータが取得された後、続くステップＳ２２０５により受信データ解析処理が行われる。これに対して、受信データが有ると判定されない場合には（Ｓ２２０３；Ｎｏ）、サーバ４０から、定期券情報等を含む送信データが送信されていないことになるから、本処理２２００を終える。

ステップＳ２２０５の受信データ解析処理では、受信データを構成する情報内容の解析が行われる。本実施形態では、予め定められたデータ形式やデータフォーマットに従って定期券情報等が入っているか否かが調べられその結果（解析結果）が生成される。この解析結果は、次の判定処理（Ｓ２２０７）に用いられる。

続くステップＳ２２０７では、この解析結果から、定期券情報等が存在し正常であると判定された場合には（Ｓ２２０７；Ｙｅｓ）、続くステップＳ２２０９により正常受信情報（つまり肯定応答（ＡＣＫ））がサーバ４０に送信される。一方、当該解析結果から、例えば、定期券情報等のデータが壊れており定期券情報等が存在しないと判定された場合（Ｓ２２０７；Ｎｏ）、ステップＳ２２１１により受信エラー情報（つまり否定応答（ＮＡＣＫ））がサーバ４０に送信される。

ステップＳ２２０７により定期券情報等が存在し正常であると判定された場合（Ｓ２２０７；Ｙｅｓ）、制御ユニット２１は、続くステップＳ２２１３により制御ユニット２１のメモリ２３のうち予め設定されている定期券情報格納領域に当該定期券情報等を保存して、一連の本処理２２００を終了する。

［走行期間処理３３００］
図８に示す走行期間処理３３００は、サーバ４０のサーバコンピュータにより実行される処理であり、走行期間処理３２００が実行された後、バス１０が次の停留所に停車して乗車期間処理３１００が実行されるまでの間に繰り返し実行される。図８には、サーバ４０が実行する走行期間処理３３００の流れを示すフローチャートが図示されている。

走行期間処理３３００では、まずステップＳ３３０１により制御装置４１のサーバコンピュータのメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ステップＳ３３０３により、サーバコンピュータのメモリ等に確保されているカードＩＤ再送領域にカードＩＤが存在するか否かを判定する処理が行われる。このカードＩＤ再送領域に保存されているカードＩＤには、前述の走行期間処理３２００の送信エラー処理（Ｓ３２１９）によって、定期券情報再送フラグ「１」が付加されている。そのため、この領域にカードＩＤが保存されている場合には、定期券情報再送フラグ「１」のカードＩＤが有ることになる。

ステップＳ３３０３により定期券情報再送フラグ「１」のカードＩＤが有ると判定した場合には（Ｓ３３０３；Ｙｅｓ）、当該カードＩＤは、続くステップＳ３３０５により所定の送信データフォーマットに組み込まれて送信データとして生成される。ステップＳ３３０５の送信データ生成処理により生成された送信データは、次のステップＳ３３０７により運賃収受装置２０に送信される。つまり、運賃収受装置２０に向けて再送信される。

続くステップＳ３３０９では、運賃収受装置２０から届く肯定応答（ＡＣＫ）や否定応答（ＮＡＣＫ）のデータを無線通信装置４５によって無線通信回線９０を介して受信し（送信結果受信処理）、応答データを取得する。

そして、ステップＳ３３１１により送信エラーが有るか否かを判定する。即ち、ステップＳ３３１１では、ステップＳ３３０９により取得された応答データが肯定応答（ＡＣＫ）のデータであるときには、送信エラーが発生していない（送信エラーがない）ことになるので（Ｓ３３１１；Ｎｏ）、ステップＳ３３１３に処理を移行して定期券情報再送フラグに「０」をセット、つまりクリアする。

これに対して応答データが否定応答（ＮＡＣＫ）のデータであるときや、応答データを受信できていないときには、送信エラーが発生している（送信エラーが有る）ことになるので（Ｓ３３１１；Ｙｅｓ）、リトライカウンタをインクリメント（＋１）して所定のリトライ回数を超えていない場合には（Ｓ３３１５；Ｎｏ）、ステップＳ３３０７に戻って再度、送信処理を行う。一方、リトライカウンタをインクリメント（＋１）した結果、所定のリトライ回数を超えている場合には（Ｓ３３１５；Ｙｅｓ）、一連の本処理３３００を終了する。

＜降車期間＞
図２に示すように、降車期間、即ち次の停留所等にバス１０が停車している期間においては、当該次の停留所で降車したい利用者が運賃収受装置２０（のＩＣカードＲ／Ｗ２６）にＩＣカード７０をかざしたりタッチしたりする。すると、運賃収受装置２０では、次に説明する降車期間処理２３００によって、ＩＣカード７０から読み取ったカードＩＤに関連付けられた定期券情報を制御ユニット２１のメモリ２３から検索して、当該利用者がこの停留所（降車停留所）で降車することの可否判定等を行う。可否判定等の結果は、運賃収受装置２０の液晶表示ユニット２７に表示される。降車期間処理２３００は、運賃収受装置２０が降車予定の利用者のＩＣカード７０を読み取るごとに繰り返し行われる。

［降車期間処理２３００］
図９に示す降車期間処理２３００は、運賃収受装置２０の制御ユニット２１により実行される処理であり、バス１０の前方口１２の扉が開いている期間中に繰り返し実行される。図９には、運賃収受装置２０が実行する降車期間処理２３００の流れを示すフローチャートが図示されている。

降車期間処理２３００では、まずステップＳ２３０１により制御ユニット２１のメモリ２３の本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ＩＣカードＲ／Ｗ２６がＩＣカード７０（のＩＣチップ７１）からカードデータを読み取ったか否かの判定がステップＳ２３０３により行われる。

そして、ＩＣカードＲ／Ｗ２６によりＩＣカード７０の読み取りが行われていると制御ユニット２１が判定した場合には（Ｓ２３０３；Ｙｅｓ）、次のステップＳ２３０５により当該読み取られたカードデータの内容を解析する処理が行われる。これに対して、ＩＣカード７０の読み取りが行われていないと制御ユニット２１が判定した場合には（Ｓ２３０３；Ｎｏ）、利用者がＩＣカード７０をタッチ等していないことになるから、本処理２３００を終える。

ステップＳ２３０５のカードデータ解析処理では、カードデータを構成する情報内容の解析が行われる。本実施形態では、予め定められたデータ形式やデータフォーマットに従って所定のデータ項目（例えば、バス事業者名、定期券発行日、カードＩＤ、乗車日時、乗車区間、ＳＦバリューの残額やＳＦポイントの残数等）がすべてＩＣカード７０に記憶されているか否かが調べられその結果（解析結果）が生成される。この解析結果は、次の判定処理（Ｓ２３０７）に用いられる。

ステップＳ２３０７では、当該解析結果から、不足するデータ項目があると判定した場合、つまりカードデータが壊れている（異常である）場合には（Ｓ２３０７；Ｎｏ）、ステップＳ２３２３により液晶表示ユニット２７にカードがエラーである旨を表示させる処理が行われる。これに対して所定のデータ項目が存在し正常であると判定した場合には（Ｓ２３０７；Ｙｅｓ）、続くステップＳ２３０９により、メモリ２３のＤＲＡＭに確保されている定期券情報格納領域から、定期券情報を検索する処理が行われる。この定期券情報等は、それぞれのカードＩＤに関連付けられているサーバ４０から送信されてきたものであり、定期券情報や検索エラー情報が含まれている。

即ち、サーバ４０が、走行期間処理３２００のデータベース検索処理（Ｓ３２０５）によって検索した結果、カードＩＤに関連付けられた定期券情報が見つかった場合には、その定期券情報が定期券情報格納領域に格納されているのに対して、カードＩＤに関連付けられた定期券情報が見つからなかった場合には、定期券情報の代わりに検索エラー情報が定期券情報格納領域に格納されている。

このため、ステップＳ２３１１の判定処理においては、カードＩＤに関連付けられて定期券情報格納領域に格納されている情報が定期券情報である場合には、定期券情報が存在する（有る）と判定され（Ｓ２３１１；Ｙｅｓ）、続くステップＳ２３１３により当該定期券情報を参照される。そして、ステップＳ２３１３の判定情報取得処理により、ＩＣカードＲ／Ｗ２６にタッチされた当該ＩＣカード７０が有する定期券機能の利用可能期間や利用可能区間等の判定情報が取得される。

これに対して、定期券情報格納領域に格納されている情報が検索エラー情報である場合には、定期券情報がないと判定されて（Ｓ２３１１；Ｎｏ）、ＳＦ精算処理（Ｓ２３１５）が行われる。即ち、当該ＩＣカード７０が有する定期券機能は有効ではないと判定されるため、当該定期券機能は利用されることなく、利用区間分の運賃はＳＦバリューやＳＦポイントで精算されることになる（Ｓ２３１５）。

ステップＳ２３１７では、ステップＳ２３１３で取得した判定情報（利用可能期間や利用可能区間等）に基づいて、当該ＩＣカード７０の定期券機能により当該利用者が降車停留所で降車可能であるか否かの判定が行われる（降車可否判定処理）。即ち、本日の日付が利用可能期間内であり、かつ、降車停留所が利用可能区間内に存在する場合には、降車可であると判定され、本日の日付が利用可能期間外であるか、または降車停留所が利用可能区間外に存在する場合には、降車不可であると判定される。

ステップＳ２３１７により降車可であると判定された場合には（Ｓ２３１７；Ｙｅｓ）、次のステップＳ２３１９により利用明細情報を生成する。一方、降車不可であると判定された場合には（Ｓ２３１７；Ｎｏ）、利用区間分の運賃をＳＦバリューやＳＦポイントで精算するＳＦ精算処理（Ｓ２３１５）に移行する。

ステップＳ２３１５のＳＦ精算処理では、利用区間の運賃分（利用運賃分）に相当するＳＦバリューを算出した後、当該算出されたＳＦバリューを、データ解析処理（Ｓ２３０５）により参照したＳＦバリューの残額やＳＦポイントの残数から減額する処理が行われる。ＩＣカード７０には、所定のデータ項目としてＳＦバリューの残額やＳＦポイントの残数等が記憶されているため、当該算出されたＳＦバリュー分だけ減額された後のＳＦバリューやＳＦポイントが、新たなＳＦバリューの残額やＳＦポイントの残数としてＩＣカード７０に書き込まれる（記憶される）。

また、ＳＦバリューの場合には、減額前のＳＦバリューの残額は「処理前ＳＦ残額」として、また減額後のＳＦバリューの残額は「処理後ＳＦ残額」として、それぞれ次のステップＳ２３１９により生成される利用明細情報にも記録される。またＳＦポイントの場合には、減額により使用したＳＦポイント数が「利用ポイント」として、ＳＦポイントの残数が「残ポイント」として、それぞれ次のステップＳ２３１９により生成される利用明細情報にも記録される。

ステップＳ２３１９の利用明細情報生成処理では、例えば、次の項目等を含んだ利用明細情報が生成される。これらの項目は、いずれもＩＣカード７０のカードＩＤに関連付けられている。なお、生成された利用明細情報は、メモリ２３のＤＲＡＭに確保されている利用明細情報格納領域に保存される。

(1) カードＩＤ（当該ＩＣカード７０の識別データ）
(2) 系統番号（当該バス１０が走行した経路を表した番号）
(3) 乗車時刻（利用者が当該バス１０に乗車した時刻）
(4) 乗車停留所番号（利用者が当該バス１０に乗車した停留所を表した番号）
(5) 降車時刻（利用者が当該バス１０を降車した時刻）
(6) 降車停留所番号（利用者が当該バス１０に降車した停留所を表した番号）
(7) 処理前ＳＦ残額（減額前のＳＦバリューの残額）
(8) 処理後ＳＦ残額（減額後のＳＦバリューの残額）
(9) ＳＦ処理金額（減額したＳＦバリュー）
(10)正規区間運賃（当該利用区間の運賃で割引なし運賃）
(11)割引金額（乗り継ぎの場合等に割り引かれる金額）
(12)残ポイント（ＳＦポイントの残数）
(13)利用ポイント（使用したＳＦポイント数）
(14)利用明細再送フラグ（運賃収受装置２０による再送信の要否を示すフラグ）

ステップＳ２３２１のカード処理結果表示処理では、液晶表示ユニット２７に、例えば、当該ＩＣカード７０がその定期券機能を利用して降車することができた旨や、定期券機能を利用することなく当該利用区間の運賃をＳＦバリューやＳＦポイントで精算した旨を表示させる処理が行われる。また、これらのほかに、例えば、定期券機能の利用可能区間および利用可能期間（有効期間）等を表示させる処理が行われる。

<<< 運行期間やバッチ処理期間の処理 >>>
次に、図１０〜図１３を参照しながら本システムにおける利用明細書に関する各処理の流れを説明する。まず、図１０に基づいて利用明細書に関する処理概要を説明する。図１０には、運賃収受装置２０およびサーバ４０により、運行期間やバッチ処理期間において実行される各処理の流れを示すシーケンス図が図示されている。

＜運行期間＞
図１０に示すように、運行期間、即ちバス１０が所定路線の始発地点から終着地点までを運行（停留所間を走行したり停留所に停車したり）している期間においては、運賃収受装置２０は、利用明細処理２４００により未だサーバ４０に送信していない利用明細情報を制御ユニット２１のメモリ２３から見つけると、無線通信回線９０を介して当該未送信の利用明細書情報をサーバ４０に送信する。これに対してサーバ４０では、利用明細処理３４００により利用明細書情報を運賃収受装置２０から受信すると、受信した利用明細書情報をサーバコンピュータのメモリ等に保存する。

このような一連の処理（利用明細処理２４００→利用明細処理３４００）は、運行期間中において、未送信の利用明細書情報が運賃収受装置２０（制御ユニット２１のメモリ２３）に存在しなくなるまで繰り返し行われる。

［利用明細処理２４００］
図１１に示す利用明細処理２４００は、運賃収受装置２０の制御ユニット２１により実行される処理であり、バス１０の運行期間中に繰り返し実行される。図１１には、運賃収受装置２０が実行する利用明細処理２４００の流れを示すフローチャートが図示されている。

利用明細処理２４００では、まずステップＳ２４０１により制御ユニット２１のメモリ２３の本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ステップＳ２４０３により、利用明細情報格納領域に保存された利用明細情報のうち利用明細再送フラグが「１」に設定されているものが有るか否かを判定する処理が行われる。利用明細再送フラグは、利用明細情報に含まれるフラグであり、運賃収受装置２０による再送信の要否を示すものである。

例えば、利用明細再送フラグが「０」にセットされている場合には、当該利用明細情報は未だサーバ４０に送信されていないことを表し、「１」にセットされている場合には、当該利用明細情報は既に送信を失敗しておりサーバ４０に対する再送信が必要であることを表す。本実施形態では、利用明細再送フラグは、デフォルトで「０」、つまり未送信に設定されている。

利用明細情報は、前述した降車期間処理２３００の利用明細情報生成処理（Ｓ２３１９）によってメモリ２３に保存されているが、後述するステップＳ２４２１により、利用明細再送フラグが「１」にセットされる場合がある。そのため、このステップＳ２４０３では、このような利用明細再送フラグ「１」の利用明細情報が有るか否かを判定する処理が行われる。

このため、利用明細再送フラグが「１」に設定されているものが存在する場合には（Ｓ２４０３；Ｙｅｓ）、それらの利用明細情報は、過去に、本利用明細処理２４００により情報処理が行われている。即ち、利用明細再送フラグが「１」の利用明細情報の送信データは、既に、ステップＳ２４０７により生成されてステップＳ２４１９によりメモリ２３に保存されているので、制御ユニット２１では、メモリ２３から読み出した当該送信データを、ステップＳ２４０９の送信処理によりサーバ４０に対して再度送信する。

これに対して、利用明細再送フラグが「１」に設定されているものが存在しない場合には（Ｓ２４０３；Ｎｏ）、次のステップＳ２４０５により、利用明細再送フラグが「０」の未送信の利用明細情報が利用明細情報格納領域に存在するか否かを判定する処理が行われる。即ち、利用明細情報の送信データは、送信エラーが生じることなくサーバ４０に送信された場合には、その利用明細情報は、後述の利用明細情報削除処理（Ｓ２４１７）によって、利用明細情報格納領域から削除される。そのため、利用明細情報格納領域に存在する利用明細再送フラグ「０」の利用明細情報は、今回、初めてサーバ４０に送信されるものである。

したがって、続くステップＳ２４０５の判定処理により、未送信の利用明細情報が存在すると判定された場合には（Ｓ２４０５；Ｙｅｓ）、当該利用明細情報は、次のステップＳ２４０７により所定の送信データフォーマットに組み込まれて送信データとして生成された後、当該送信データは、ステップＳ２４０９によりサーバ４０に送信される。より具体的には、送信データは、制御ユニット２１により制御される無線通信ユニット２９によって無線通信回線９０を介してサーバ４０に無線送信される。一方、ステップＳ２４０５の判定処理により、未送信の利用明細情報が存在しないと判定された場合には（Ｓ２４０５；Ｎｏ）、サーバ４０に送信する必要の有る利用明細情報は存在しないため、本処理２４００を終える。

運賃収受装置２０からの送信データがサーバ４０により正常に受信されると、例えば、サーバ４０から肯定応答（ＡＣＫ）のデータが送信されて運賃収受装置２０の無線通信ユニット２９に届く。もしサーバ４０が送信データを正常に受信することができなかったときには、否定応答（ＮＡＣＫ）のデータがサーバ４０から送信されて無線通信ユニット２９に届いたり、所定時間を経過（タイムアウト）しても何ら応答データが届かなかったりする。そのため、運賃収受装置２０は、続くステップＳ２４１１により、サーバ４０から届くこれらの応答データを無線通信ユニット２９を介して受信し（送信結果受信処理）、応答データを取得する。

そして、続くステップＳ２４１３により送信エラーが有るか否かの判定が行われて、ステップＳ２４１１により取得された応答データが肯定応答（ＡＣＫ）のデータであるときには、送信エラーが発生していない（送信エラーがない）ことになるので（Ｓ２４１３；Ｎｏ）、ステップＳ２４１７の利用明細情報削除処理によって、当該送信済み利用明細情報を利用明細情報格納領域から削除した後、本処理２４００を終える。

これに対して、応答データが否定応答（ＮＡＣＫ）のデータであるときや、応答データを受信できていないときには、送信エラーが発生している（送信エラーが有る）ことになるので（Ｓ２４１３；Ｙｅｓ）、リトライカウンタをインクリメント（＋１）して所定のリトライ回数を超えていない場合には（Ｓ２４１５；Ｎｏ）、ステップＳ２４０９に戻って再度、送信処理を行う。

リトライカウンタをインクリメント（＋１）した結果、所定のリトライ回数を超えている場合には（Ｓ２４１５；Ｙｅｓ）、制御ユニット２１は、サーバ４０に対する利用明細情報の送信を止めた後、ステップＳ２４１９の送信データ保存処理により、送信できなかった送信データをメモリ２３に保存する。所定のリトライ回数は、例えば、５回に設定される。そして、ステップＳ２４２１により利用明細再送フラグを「１」にセットして本処理２４００を終了する。

［利用明細処理３４００］
図１２に示す利用明細処理３４００は、サーバ４０のサーバコンピュータにより実行される処理であり、前述の利用明細処理２４００と同様に、バス１０の運行期間中に繰り返し実行される。図１２には、サーバ４０が実行する利用明細処理３４００の流れを示すフローチャートが図示されている。

利用明細処理３４００では、まずステップＳ３４０１により制御装置４１のサーバコンピュータのメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ステップＳ３４０３により無線通信装置４５の受信データが有るか否かの判定が行われる。例えば、受信データが有る場合には（Ｓ３４０３；Ｙｅｓ）、無線通信装置４５の受信バッファに受信データが保持されているため、そのデータが取得された後、続くステップＳ３４０５により受信データ解析処理が行われる。これに対して、受信データが有ると判定されない場合には（Ｓ３４０３；Ｎｏ）、運賃収受装置２０から利用明細情報を含む送信データが送信されていないことになるから、本処理３４００を終える。

ステップＳ３４０５の受信データ解析処理では、受信データを構成する情報内容の解析が行われる。本実施形態では、予め定められたデータ形式やデータフォーマットに従って利用明細情報が入っているか否かが調べられその結果（解析結果）が生成される。この解析結果は、次の判定処理（Ｓ３４０７）に用いられる。

続くステップＳ３４０７では、この解析結果から、利用明細情報が存在し正常であると判定された場合には（Ｓ３４０７；Ｙｅｓ）、続くステップＳ３４０９により正常受信情報（つまり肯定応答（ＡＣＫ））が運賃収受装置２０に送信される。一方、当該解析結果から、例えば、利用明細情報のデータが壊れていると判定された場合（Ｓ３４０７；Ｎｏ）、ステップＳ３４１１により受信エラー情報（つまり否定応答（ＮＡＣＫ））が運賃収受装置２０に送信される。

ステップＳ３４０７により利用明細情報が正常であると判定された場合には（Ｓ３４０７；Ｙｅｓ）、利用明細情報に含まれる利用明細再送フラグが「１」にセットされているか否かを判定するとともに、当該フラグが「１」である場合にはさらにその利用明細情報と同じ情報であって利用明細再送フラグが「０」である利用明細情報がサーバコンピュータのメモリの利用明細情報格納領域に存在するか否かの判断が行われる（Ｓ３４１３）。

即ち、後述のステップＳ３４１７により、既に、サーバ４０に送信されて正常に受信された利用明細情報（利用明細再送フラグ「０」）がサーバコンピュータの利用明細情報格納領域に保存されている場合には、今回、正常に受信した利用明細情報は、その利用明細再送フラグが「１」であり、重複して受信した蓋然性が高い。このような重複受信は、例えば、サーバ４０が、前回、利用明細情報（利用明細再送フラグ「０」）の送信データを正常に受信した後、運賃収受装置２０に向けて送信した正常受信情報（肯定応答（ＡＣＫ））が通信障害等により運賃収受装置２０に届いていない場合において、運賃収受装置２０が利用明細情報（利用明細再送フラグ「１」）の送信データを再送信することに起因して発生し得る。

したがって、受信した送信データの利用明細情報に含まれる利用明細再送フラグが「１」である場合には（Ｓ３４１３；Ｙｅｓ）、ステップＳ３４１５により、さらにサーバコンピュータの利用明細情報格納領域に重複した利用明細情報が保存されているか否かを判定する。そして、利用明細再送フラグ「０」の利用明細書情報が保存されていない場合には、当該「１」がセットされた利用明細再送フラグをクリア（「０」にセット）して（Ｓ３４１５）、ステップＳ３４１７の利用明細情報保存処理により利用明細情報格納領域に保存する。そして、一連の本処理３４００を終える。

これに対して、利用明細再送フラグ「０」の利用明細情報が既に利用明細情報格納領域に保存されている場合には、今回受信した利用明細再送フラグ「１」の利用明細情報を破棄するか、当該「１」がセットされた利用明細再送フラグをクリア（「０」にセット）する（Ｓ３４１５）。そして、破棄した場合にはそのまま本処理３４００を終え、破棄でない場合には、利用明細再送フラグを「０」にセットした利用明細情報を利用明細情報格納領域に上書き保存した後（Ｓ３４１７）、一連の本処理３４００を終える。

一方、受信した送信データの利用明細情報に含まれる利用明細再送フラグが「１」でない場合（利用明細再送フラグが「０」である場合）には（Ｓ３４１３；Ｎｏ）、当該受信した利用明細再送フラグ「０」の利用明細情報をステップＳ３４１７の利用明細情報保存処理により利用明細情報格納領域に保存した後、一連の本処理３４００を終える。

＜バッチ処理期間＞
図１０に示すように、サーバ４０のバッチ処理期間、即ちバス１０が運行していない夜間等においては、サーバ４０はリカバリ処理３５００を行う。リカバリ処理３５００は、サーバ４０に定期券情報が存在しているにもかかわらず、運賃収受装置２０においてＳＦ精算処理を行った場合にそれを救済（補填）するものである。

［リカバリ処理３５００］
図１３に示すリカバリ処理３５００は、サーバ４０のサーバコンピュータにより実行される処理であり、例えば、バス１０がバスターミナル等で待機していたり車庫に入庫されていたりして運行していない期間（サーバ４０のバッチ処理期間）中に繰り返し実行される。図１３には、サーバ４０がバッチ処理期間中において実行するリカバリ処理３５００の流れを示すフローチャートが図示されている。

リカバリ処理３５００では、まずステップＳ３５０１により制御装置４１のサーバコンピュータのメモリの本処理用のワーク領域をクリアする等の所定の初期化処理が行われた後、ステップＳ３５０３により利用実績確認処理が行われる。

ステップＳ３５０３の利用実績確認処理は、サーバコンピュータのメモリの利用明細情報格納領域に保存されている利用明細情報のうち、未だ利用実績確認処理が行われていないものに対して行われる。本実施形態では、例えば、サーバ４０による利用実績確認処理の要否を示す情報として、所定フラグがそれぞれの利用明細情報に付加されていたり、個々の利用明細情報に関連付けされた当該所定フラグがワーク領域に設けらたりしている。例えば、この所定フラグは「０」にセットされている場合には、当該利用明細情報の利用実績は未だ確認されていないことを表し、「１」にセットされている場合には、当該利用明細情報の利用実績は既に確認されていることを表す。本実施形態では、当該フラグはデフォルトで「０」、つまり未確認に設定されている。

このため、本実施形態の利用実績確認処理では、当該所定フラグが「０」であるものについて、さらに当該利用明細情報からカードＩＤを読み出して、当該カードＩＤに関連付けられている定期券情報をデータベース装置４３から探し出す。また定期券情報からＳＦ処理金額および利用ポイントを読み出す。ＳＦ処理金額は、運賃収受装置２０において減額されたＳＦバリューを表す。また、利用ポイントは、運賃収受装置２０において減額により使用されたＳＦポイント数を表す。したがって、ＳＦ処理金額が０円でない（０円を超える）場合や利用ポイントが０ポイントでない（０ポイントを超える）場合には、それらは運賃収受装置２０においてＳＦ精算されたことを表している。

前述したように、データベース装置４３には、定期券を発行している全利用者の定期券情報が蓄積されているため、カードＩＤが現在も有効である場合には、必ずデータベース装置４３から当該カードＩＤに対応する定期券情報を見つけることができる。したがって、当該カードＩＤに対応する定期券情報の有無と運賃収受装置２０におけるＳＦ精算の有無とに基づいて、ＩＣカード７０の有効な定期券情報が存在するにもかかわらず、運賃収受装置２０においてＳＦ精算されたか否かを判定することが可能になる（Ｓ３５０５）。

次のステップＳ３５０５では、定期券情報が存在しかつＳＦ精算済みであるか否かの判定が行われる。即ち、利用明細情報格納領域に保存されている利用明細情報のなかに、そのカードＩＤに関連付けられている定期券情報がデータベース装置４３に存在し、かつ、当該利用明細情報に０円を超えるＳＦ処理金額や０ポイントを超える利用ポイントが含まれている場合には（Ｓ３５０５；Ｙｅｓ）、続くステップＳ３５０７によりＳＦ精算救済処理が行われる。

つまり、この場合（Ｓ３５０５；Ｙｅｓ）、当該ＩＣカード７０は有効な定期券機能を有し得るものである。そのため、本来であれば、当該ＩＣカード７０の利用者はＳＦ精算をすることなく、降車停留所で降車可能であったにもかかわらず、運賃収受装置２０が当該ＩＣカード７０の定期券情報をサーバ４０から受信できなかったことから、当該利用者はＳＦ精算をして降車している。したがって、この場合には、降車時に運賃収受装置２０によって減額されたＳＦバリューや減額により使用されたＳＦポイントを、事後的に補填するためにステップＳ３５０７によりＳＦ精算救済処理が行われる。

これに対して、カードＩＤに関連付けられている定期券情報がデータベース装置４３に存在しないか、または存在してもその利用明細情報に０円を超えるＳＦ処理金額や０ポイントを超える利用ポイントが含まれていない（ＳＦ処理金額が０円や利用ポイントが０ポイントである）場合には（Ｓ３５０５；Ｎｏ）、運賃収受装置２０の降車期間処理２３００において適切に降車可否判定処理（Ｓ２３１７）が行われており、ＳＦ精算救済処理（Ｓ３５０７）を行う必要がない。そのため、ステップＳ３５０７をスキップしてステップＳ３５０９に処理を移行する。

ステップＳ３５０７のＳＦ精算救済処理では、例えば、ＳＦバリューの減額分に相当するポイント数や、減額により使用されたＳＦポイントと同じポイント数のＳＦポイントを付与し得る処理が行われる。これらのＳＦポイントの付与は、例えば、利用者がＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１を利用する場合や、駅構内６０の定期券発行装置６１を利用する場合において、ＩＣカードＲ／Ｗ端末装置５１や定期券発行装置６１がインターネット１００を介してサーバ４０にアクセスするときに当該ＳＦポイントの付与情報をサーバ４０から、これらの装置５１，６１に送る。これにより、ＩＣカードＲ／Ｗ端末装置５１や定期券発行装置６１は、当該利用者のＩＣカード７０に対して、補填すべき当該ＳＦポイントを付与することが可能になる。

また、ＳＦ精算救済処理（Ｓ３５０７）では、例えば、ＩＣカード７０の定期券機能の更新時において、その更新に要する料金（更新料金）からＳＦバリューの減額分を控除し得る処理が行われる。ＳＦバリューの減額分の控除は、例えば、利用者がＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１を利用する場合や、駅構内６０の定期券発行装置６１を利用する場合において、ＩＣカードＲ／Ｗ端末装置５１や定期券発行装置６１がインターネット１００を介してサーバ４０にアクセスするときに当該ＳＦバリューの減額分の控除情報をサーバ４０から、これらの装置５１，６１に送る。これにより、ＩＣカードＲ／Ｗ端末装置５１や定期券発行装置６１は、ＩＣカード７０の更新料金から、補填すべき当該ＳＦバリューの減額分を控除することが可能になる。

さらに、ＳＦ精算救済処理（Ｓ３５０７）では、例えば、ＩＣカード７０の定期券機能の更新時において、新たに設定される定期券機能の利用可能期間（更新期間）に対して、ＳＦバリューの減額分を定期券機能の利用可能区間の往復運賃で除算して得られた日数分だけ延長し得る処理が行われる。当該日数分の延長は、例えば、利用者がＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１を利用する場合や、駅構内６０の定期券発行装置６１を利用して定期券機能の更新する場合において、ＩＣカードＲ／Ｗ端末装置５１や定期券発行装置６１がインターネット１００を介してサーバ４０にアクセスするときに当該日数分の延長情報をサーバ４０から、これらの装置５１，６１に送る。これにより、ＩＣカードＲ／Ｗ端末装置５１や定期券発行装置６１では、定期券機能の更新期間に補填すべき当該ＳＦバリューの減額分相当の往復日数を延長することが可能になる。

ステップＳ３５０９では、実績が未だ確認されていない利用明細書情報が存在するか否かを確認する処理が行われる。サーバコンピュータの利用明細情報格納領域に実績が未だ確認されていない利用明細書情報が存在する場合には（Ｓ３５０９；Ｙｅｓ）、ステップＳ３５０３に戻って、再度、利用実績確認処理が行われる。これに対して、利用明細情報格納領域に実績が未だ確認されていない利用明細書情報が存在しない場合には（Ｓ３５０９；Ｎｏ）、一連の本処理３５００を終了する。

以上説明したように本実施形態に係る定期券処理システムによると、バス１０に搭載された乗車用カードリーダ３０（ＩＣカードリーダ３３）により、乗客がバス１０に乗車するときに定期券として機能し得るＩＣカード７０を識別可能なカードＩＤを、当該ＩＣカード７０から読み出して出力し、運賃収受装置２０のＩＣカードＲ／Ｗ２６により、乗客がバス１０を降車するときにカードＩＤをＩＣカード７０から読み出して出力する。バス１０以外に設けられるサーバ４０は、カードＩＤに関連付けられたＩＣカード７０の利用可能期間および利用可能区間の情報を含む定期券情報を記憶している。そして、運賃収受装置２０の制御ユニット２１により、乗客が乗車してから降車するまでの間において、乗車用カードリーダ３０から出力されたカードＩＤに基づいて無線通信回線９０を介してサーバ４０から定期券情報を取得するとともに当該取得した定期券情報と運賃収受装置２０のＩＣカードＲ／Ｗ２６から出力されたカードＩＤとに基づいて可否判定を行う。

これにより、乗客の定期券情報は、当該乗客が乗車してから降車するまでの間、つまりバス１０の走行中や降車停留所に到着するまでにおいて、乗車用カードリーダ３０から出力されたカードＩＤに基づいて無線通信回線９０を介してサーバ４０から取得される。即ち、ＩＣカード７０にはそれを識別可能なカードＩＤを持たせれば、バス１０の走行中等にサーバ４０から利用可能期間および利用可能区間の情報を取得することが可能になるため、利用可能期間や利用可能区間の情報をＩＣカード７０が持たなくても運賃収受装置２０の制御ユニット２１により可否判定を行うことができる。そのため、ＩＣカード７０の更新等に関与する利用可能期間および利用可能区間の情報をＩＣカード７０に持たせる必要がないので、当該乗客であるＩＣカード７０の利用者は、ＩＣカード７０の定期券機能の更新時にＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１や駅構内６０の定期券発行装置６１等で更新の手続を行う必要がない。したがって、バス１０のＩＣカード７０の利用者の利便性を向上させることが可能になる。

また、本実施形態に係る定期券処理システムによると、運賃収受装置２０の制御ユニット２１は、降車期間処理２３００により、乗客がＩＣカード７０を利用して降車停留所で降車することができないと判定したときには（Ｓ２３１７；Ｎｏ）、ＩＣカード７０のＳＦバリューから利用運賃分を減額して降車を許容する。これにより、利用運賃分を現金で精算する必要がないため、このようなバス１０の利用場面においてもＩＣカード７０の利用者の利便性を向上させることが可能になる。

さらに、本実施形態に係る定期券処理システムによると、運賃収受装置２０の制御ユニット２１は、降車期間処理２３００により、ＩＣカード７０のＳＦバリューから利用運賃分を減額した場合には（Ｓ２３１５）、ＳＦ処理金額（利用運賃分の情報）を含んだ利用明細情報をサーバ４０に送る。これにより、サーバ４０では、ＩＣカード７０のＳＦバリューから利用運賃分を減額したことを把握することが可能になる。そのため、例えば、乗客の定期券情報がサーバ４０に記憶されているにもかかわらず、無線通信回線９０の通信不具合等により、乗客が乗車してから降車するまでの間にサーバ４０から乗客の定期券情報を取得できない場合（Ｓ３２１７；Ｙｅｓ、Ｓ３３１５；Ｙｅｓ）が生じたときには、それをリカバリするリカバリ処理３５００をサーバ４０において行うことが可能になる。

さらにまた、本実施形態に係る定期券処理システムによると、サーバ４０は、ＩＣカード７０に対応する定期券情報を記憶している場合に運賃収受装置２０の制御ユニット２１からＳＦ処理金額を含んだ利用明細情報を受けたときは、当該ＳＦ処理金額（利用運賃分の情報）を、ＩＣカード７０のＳＦバリューを変更可能なＩＣカードＲ／Ｗ端末装置５１に提供可能に保持する。即ち、乗客はそのＩＣカード７０の定期券機能を利用して降車停留所で降車できる場合であったにもかかわらず、ＩＣカード７０の定期券機能を利用できない場合と同様にＳＦバリューから利用運賃分をＳＦ処理金額として減額された場合においては、サーバ４０は、当該ＳＦ処理金額の情報を、例えば、ＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１に提供し得るように保存する。これにより、ＩＣカード取扱い窓口５０のＩＣカードＲ／Ｗ端末装置５１によって、例えば、事後的に当該ＳＦ処理金額分を補填するようにＩＣカード７０のＳＦバリューを変更することが可能になる。

また、本実施形態に係る定期券処理システムによると、サーバ４０は、ＩＣカード７０に対応する定期券情報を記憶している場合に運賃収受装置２０の制御ユニット２１からＳＦ処理金額を含んだ利用明細情報を受けたときは、当該ＳＦ処理金額（利用運賃分の情報）を、サーバ４０に記憶されている定期券情報を変更可能な定期券発行装置６１に提供可能に保持する。即ち、乗客はそのＩＣカード７０の定期券機能を利用して降車停留所で降車できる場合であったにもかかわらず、ＩＣカード７０の定期券機能を利用できない場合と同様にＳＦバリューから利用運賃分をＳＦ処理金額として減額された場合においては、サーバ４０は、当該ＳＦ処理金額の情報を、例えば、駅構内６０の定期券発行装置６１に提供し得るように保存する。これにより、定期券発行装置６１によって、例えば、ＩＣカード７０の更新手続等により定期券情報を変更するときに、当該ＳＦ処理金額分だけ定期券の更新料金を割り引いたり、当該ＳＦ処理金額分だけ定期券の更新期間を延長したりすることが可能になる。

なお、上述した実施形態では、バス１０が停車（または走行）しているか否かを、前方口１２や後方口１４の扉の開閉状態に関する情報に基づいて判定する場合を例示して説明したが、これに限られることはなく、例えば、運賃収受装置２０または乗車用カードリーダ３０がＧＰＳセンサを備えている場合には、当該ＧＰＳセンサにより得られる位置情報の経時変化に基づいてバス１０が停車（または走行）しているか否かを判定するように構成してもよい。

また、上述した実施形態では、定期券の一例として、ＩＣチップ７１を有するＩＣカード７０を用いる場合を例示して説明したが、これに限られることはなく、カードＩＤ（定期券の識別情報）等を記憶したり記録したりすることが可能であれば、例えば、帯状の磁性体部分を表面または裏面に有する磁気ストライプカードや、縞模様状の線の太さにより英数字や記号を表す一次元バーコードまたはＱＲコード（登録商標）等の二次元バーコードが表面もしくは裏面に印刷されている定期券カードを用いてもよい。

さらに、上述した実施形態では、降車時読出装置の一例としてのＩＣカードＲ／Ｗ２６と、降車可否判定装置の一例としての制御ユニット２１とを同じ運賃収受装置２０に収容するように構成したが、これに限られることはなく、ＩＣカードＲ／Ｗ２６と制御ユニット２１をそれぞれ別個の装置として構成してもよい。このような構成においても、上述と同様の作用および効果を得ることができる。

また、上述した実施形態では、運賃収受装置２０と乗車用カードリーダ３０を別個に構成したが、これらを同じ装置に収容するように構成してもよい。また、乗車時読出装置と降車時読出装置の両機能を、１つのＩＣカードＲ／Ｗ２６に担わせてもよい。このような構成においても、上述と同様の作用および効果を得ることができ、しかも本システムを構成するハードウェアの数が減るので、省スペース化が可能になる。

また、上述した実施形態では、ＩＣカード７０のＩＣチップ７１にＳＦバリューの情報（ＳＦバリュー残額等）やＳＦポイントの情報（ＳＦポイント残数等）を記憶させるように構成したが、これに限られることはなく、例えば、ＩＣカード７０のカードＩＤに関連付けられたＳＦバリューの情報やＳＦポイントの情報をサーバ４０のサーバコンピュータのメモリに記憶させるようにサーバコンピュータを構成してもよい。この場合、降車期間処理２３００のＳＦ精算処理（Ｓ２３１５）に相当する情報処理は、サーバ４０において行われる。そのため、降車期間処理２３００の利用明細情報生成処理（Ｓ２３１９）で生成される利用明細情報には、ＳＦ処理金額（減額したＳＦバリュー）や利用ポイント（使用したＳＦポイント数）を記録する必要があるが、ＩＣカード７０自体はＳＦバリューやＳＦポイントの情報を持たないため、減額後のＳＦバリューやＳＦポイントを書き込む必要はない。

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

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

１０…バス（路線バス）
２０…運賃収受装置（降車時読出装置、降車可否判定装置）
２１…制御ユニット（降車可否判定装置）
２２…ＭＰＵ
２３…メモリ
２６…ＩＣカードＲ／Ｗ（降車時読出装置）
２７…液晶表示ユニット
２８…有線通信ユニット
２９…無線通信ユニット
３０…乗車用カードリーダ（乗車時読出装置）
３１…制御ユニット
３３…ＩＣカードリーダ（乗車時読出装置）
３５…表示ユニット
３７…通信ユニット
４０…サーバ（外部サーバ）
４１…制御装置
４３…データベース装置
４５…無線通信装置
５１…ＩＣカードＲ／Ｗ端末装置（ＳＦデータ変更装置）
６１…定期券発行装置（定期券情報変更装置）
７０…ＩＣカード（定期券）
７１…ＩＣチップ
８０…有線通信回線
９０…無線通信回線
１００…インターネット
１１００，２１００，３１００…乗車期間処理
２２００，３２００，３３００…走行期間処理
２３００…降車期間処理
２４００，３４００…利用明細処理
３５００…リカバリ処理

Claims (5)

1. 運賃後払い方式の路線バスにおいて乗客が定期券を利用して降車停留所で降車することの可否判定を行う定期券処理システムであって、
   前記乗客が前記路線バスに乗車するときに前記定期券を識別可能な識別データを前記定期券から読み出して出力する乗車時読出装置と、
   前記乗客が前記路線バスを降車するときに前記識別データを前記定期券から読み出して出力する降車時読出装置と、
   前記路線バス以外に設けられ前記識別データに関連付けられた前記定期券の利用可能期間および利用可能区間の情報を含む定期券情報を記憶している外部サーバと、
   前記乗客が乗車してから降車するまでの間において、前記乗車時読出装置から出力された前記識別データに基づいて無線通信回線を介して前記外部サーバから前記定期券情報を取得するとともに、前記乗客が前記路線バスを降車するときにおいて、当該取得した前記定期券情報と前記降車時読出装置から出力された前記識別データとに基づいて前記可否判定を行う降車可否判定装置と、
   を備えることを特徴とする定期券処理システム。
2. 前記定期券がストアードフェア機能を有するＩＣカードである場合において、
   前記降車可否判定装置は、前記乗客が前記定期券を利用して前記降車停留所で降車することができないと判定したときには、ストアードフェアデータから、前記乗客が乗車してから降車するまでの間の利用運賃分を減額して降車を許容することを特徴とする請求項１に記載の定期券処理システム。
3. 前記降車可否判定装置は、少なくとも前記ストアードフェアデータから前記利用運賃分を減額した場合には、前記利用運賃分の情報を前記外部サーバに送ることを特徴とする請求項２に記載の定期券処理システム。
4. 前記外部サーバは、前記定期券に対応する前記定期券情報を記憶している場合に前記降車可否判定装置から前記利用運賃分の情報を受けたときは、当該利用運賃分の情報を、前記ＩＣカードの前記ストアードフェアデータを変更可能なＳＦデータ変更装置に提供可能にすることを特徴とする請求項３に記載の定期券処理システム。
5. 前記外部サーバは、前記定期券に対応する前記定期券情報を記憶している場合に前記降車可否判定装置から前記利用運賃分の情報を受けたときは、当該利用運賃分の情報を、前記外部サーバに記憶されている前記定期券情報を変更可能な定期券情報変更装置に提供可能にすることを特徴とする請求項３に記載の定期券処理システム。

Images