(57)【特許請求の範囲】
【請求項１】
決済処理に関する情報をカード会社のサーバに送信する決済センター装置との間で決済に必要な情報を送受信する決済端末システムであって、
前記決済に必要な情報の送受信状態に応じて、前記決済センター装置との通信をリトライする方法を決定し、決定した前記リトライ方法に基づいて前記決済センター装置との通信をリトライさせるリトライ制御手段と、
当該決済端末システムの現在の状態に関する情報の入力を受け付ける手段と、
前記決済に必要な情報の種別ごとに、送受信の完了状況を記憶する手段とを備え、
前記リトライ制御手段は、前記状態に関する情報の入力を受け付けたときに、当該状態に関する情報と、記憶されている、前記決済に必要な情報の種別ごとの送受信の完了状況に基づいて、前記決済に必要な情報の送受信のリトライを、種別ごとに実施するか否か決定する
ことを特徴とする決済端末システム。
【請求項２】
前記リトライ制御手段は、
前記決済に必要な情報のデータサイズに基づいてリトライ回数を決定する、
ことを特徴とする請求項１に記載の決済端末システム。
【請求項３】
前記リトライ制御手段は、
前記決済に必要な情報のデータサイズと、決定した前記リトライ回数とに基づいてリトライ間隔を決定する、
ことを特徴とする請求項２に記載の決済端末システム。
【請求項４】
前記リトライ制御手段は、
前記決済センター装置から送信されてきた前記決済に必要な情報の送信信号に含まれるデータサイズの情報を、該決済に必要な情報のデータサイズとする、
ことを特徴とする請求項３に記載の決済端末システム。
【請求項５】
前記リトライ制御手段は、
前記決済センター装置から送信されてきた前記決済に必要な情報の送信信号に含まれる各データのデータサイズを累積し、前記累積したデータサイズを該決済に必要な情報のデータサイズとする、
ことを特徴とする請求項３に記載の決済端末システム。
【請求項６】
タクシーに設置され、移動体通信網を介して前記決済センター装置と通信を行い、
前記決済端末システムの現在の状態に関する情報として、当該タクシーに搭載されたタクシーメータ装置から当該タクシーの運転情報の入力を受け付け、
前記リトライ制御手段は、前記タクシーメータから前記運転情報を受け付けたときに、
当該運転情報と、記憶されている、前記決済に必要な情報の種別ごとの送受信の完了状況に基づいて、前記決済に必要な情報の送受信のリトライを、種別ごとに実施するか否か決定する
請求項１から５のいずれかに記載の決済端末システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クレジットカードなどの決済カードの利用可否データを取得し、取得した利用可否データに基づいて決済を行う決済端末システムおよびデータ送受信方法に関する。
【背景技術】
【０００２】
従来から、クレジットカードなどを利用した決済方法が導入されている。このような決済方法においては、例えば、接触型の磁気決済カードや接触型のＩＣ決済カード（以下、「接触型決済カード」ともいう）が用いられたオンライン決済がある。この方法で決済を行う際には、決済端末のカード読み取り部によって接触型磁気決済カードの磁気記録部または接触型ＩＣ決済カードのＩＣ記録部に記録されたカード番号などの情報が読み取られ、読み取ったカード情報が、決済端末からの情報を集約して決済端末を管理する決済センターを介して、当該カードのカード会社のサーバに送信され、カード会社のサーバによってカード情報の認証や決済が行わる。
カード会社のサーバには、例えば、カードの有効期限や、紛失届の提出の有無など、接触型決済カードが使用可能なカードであるか否かを表す情報が記録されている。例えば、接触型磁気決済カードによって決済を行おうとする場合、決済端末は、毎回、決済センターを介して当該カードのカード会社のサーバと通信を行い、決済を行おうとしているカードが有効なカードであるか否かの認証結果をカード会社のサーバから決済センター経由で受信し、有効なカードである場合にのみ決済処理を行っている。このように、決済端末は、決済を行う際、毎回決済センターを介したカード会社のサーバによる認証を得、確実に決済が行われるようにしている（特許文献１参照）。
【０００３】
近年、接触型磁気決済カードや接触型ＩＣ決済カードに加えて、非接触型のＩＣ決済カードの利用が増加している。この非接触型ＩＣ決済カードには、利用できる金額などのデータが記録されており、この利用可能な金額の範囲内での決済を迅速に行うことができる決済方法（オフライン決済）を採用しているものもある。しかし、このような非接触型ＩＣ決済カードを利用したオフライン決済においては、決済を迅速に行うという目的から、決済端末が決済センターからカード会社のサーバが行った認証結果等の情報を取得するための通信時間を、決済処理のたびに確保することができない。すなわち、非接触型ＩＣ決済カードを利用した決済では、接触型決済カードを利用した決済で用いられていたように、非接触型ＩＣ決済カードが使用可能なカードであるか否かを表す情報を、毎回決済センターを介してカード会社のサーバから取得して照合するという決済処理を行うことができない。このため、非接触型ＩＣ決済カードに対応した決済端末は、決済センターが取得・記憶しているカードが使用可能なカードであるか否かを表す情報（ネガデータ）を、決済処理とは別のタイミングで決済センターから取得し、自決済端末内に記憶しておく方法がとられている。そして、決済を行う際に取得した非接触型ＩＣ決済カードのカード番号などの情報と、自決済端末内に記憶した非接触型ＩＣ決済カードが使用可能なカードであるか否かを表す情報とを照合することによって、確実に決済が行われるようにしている。
【０００４】
非接触型ＩＣ決済カードが使用可能なカードであるか否かを表す情報は、日々更新される情報である。仮に、決済端末に記憶している情報が古い状態であっても、決済を行う時点で使用不可能である非接触型ＩＣ決済カードによる決済処理を行ってしまう。このような場合、後に完了した決済処理の情報に基づいて決済金額が入金される入金処理の際に、非接触型ＩＣ決済カードに基づいた入金がなされないという問題が発生し、非接触型ＩＣ決済カードの会社側の損害が発生する。このため、決済センターは、決済端末からの情報を集約し管理するとともにカード会社からネガデータを定期的に取得して記憶しており、決済端末は、このネガデータの最新のものを決済センターから取得して、自決済端末内に記憶しておくことが望まれている。
【０００５】
また、決済端末は、非接触型ＩＣ決済カードが使用可能なカードであるか否かを表す情報を取得する以外にも、決済後の入金処理のデータとなる決済処理済み記録の送信、決済処理を実行する際に必要となる決済端末の設定データの取得、例えば、システム変更などに伴う決済端末の動作プログラムの更新データ（更新プログラム）の取得など、決済センターと通信することによって様々なデータの送受信を行っている。
【０００６】
ところが、決済端末によって決済処理が行われる場面は様々であり、常に安定して決済センターと通信を行うことができる環境であるとは限らない。例えば、タクシーに搭載された決済端末は、移動体通信サービスを利用して決済センターとの通信を行っているため、安定した通信状態を保つことができない、すなわち、通信状態が常に変化している環境で使用されることとなる。このような通信状態が変化する環境に置かれた決済端末では、通信状態の変化に起因した通信異常が起きやすく、この通信異常によるデータの送受信の失敗が起きやすい。
従来の決済端末では、データの送受信に失敗したときに、データの送受信が成功するまで一定間隔で通信のリトライ（再実行）を繰り返すということが行われている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−５４６２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、データの送受信に失敗した後に、データの送受信が成功するまで一定間隔で通信のリトライを繰り返す方法では、データの送受信を繰り返すたびに移動体通信サービスの利用料金が計上されることとなるため、リトライ回数の増加に伴って通信料金が増大する。特に、送受信するデータ量が大量である場合には、通信状態が安定していないことによるリトライ回数も多くなることも予想され、より通信料金が増大してしまうという問題がある。
【０００９】
また、データ送受信のリトライを繰り返していると、他の処理で必要な通信時間を確保することが困難な状態となり、他の処理に大きな支障をおよぼす可能性が高くなるという問題がある。例えば、データ送受信のリトライを繰り返していたときに、決済処理時に決済センターとの通信を必要とする接触型決済カードを利用した決済を行おうとすると、接触型決済カードを利用した決済処理のために行われる決済センターとの通信が待たされることがある。また、例えば、接触型決済カードを利用した決済処理のためにリトライによるデータ送受信を中断した場合には、接触型決済カードによる決済処理の完了後に、再びリトライが繰り返されることとなり、データ送受信のリトライが収束しない可能性が高くなる。
【００１０】
本発明は、上記の課題認識に基づいてなされたものであり、決済端末システムによる決済処理時の通信への影響を少なくし、かつデータ送受信における通信料金の増大を抑えることができる決済端末システムおよびデータ送受信方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記の課題を解決するため、本発明の決済端末システム（例えば、実施形態における決済端末システム１０）は、決済処理に関する情報をカード会社のサーバに送信する決済センター装置（例えば、実施形態における決済センター１）との間で決済に必要な情報を送受信する決済端末システムであって、前記決済に必要な情報の送受信状態に応じて、前記決済センター装置との通信をリトライする方法を決定し、決定した前記リトライ方法に基づいて前記決済センター装置との通信をリトライさせるリトライ制御手段（例えば、実施形態における決済処理部２２０、非接触ＩＣカード決済処理部３２０）、を備える、ことを特徴とする。
これにより、決済に必要な情報の送受信状態に応じて、例えば、送受信に失敗した決済に必要な情報のリトライを制御することができる。
【００１２】
また、本発明の前記リトライ制御手段は、前記決済に必要な情報のデータサイズに基づいてリトライ回数を決定する、ことを特徴とする。
これにより、決済に必要な情報のデータサイズ毎に送受信のリトライ回数を変えることができ、例えば、データサイズが大きい決済に必要な情報のリトライ回数を少なくすることによって、特定の決済に必要な情報による通信の占有を回避することができる。
【００１３】
また、本発明の前記リトライ制御手段は、前記決済に必要な情報のデータサイズと、決定した前記リトライ回数とに基づいてリトライ間隔を決定する、ことを特徴とする。
これにより、決済に必要な情報のデータサイズやリトライ回数毎に送受信のリトライ間隔を変えることができ、例えば、何度もリトライを繰り返している決済に必要な情報のリトライの通信が、決済センター装置の他の通信に影響をおよぼさないようにすることができる。
【００１４】
また、本発明の前記リトライ制御手段は、前記決済センター装置から送信されてきた前記決済に必要な情報の送信信号に含まれるデータサイズの情報を、該決済に必要な情報のデータサイズとする、ことを特徴とする。
これにより、決済に必要な情報のデータサイズを即座に取得することができる。
【００１５】
また、本発明の前記リトライ制御手段は、前記決済センター装置から送信されてきた前記決済に必要な情報の送信信号に含まれる各データのデータサイズを累積し、前記累積したデータサイズを該決済に必要な情報のデータサイズとする、ことを特徴とする。
これにより、決済に必要な情報の送信信号にデータサイズの情報が含まれていない場合でも決済に必要な情報のデータサイズを取得することができる。
【００１６】
また、本発明の前記リトライ制御手段は、前記決済に必要な情報の種別に基づいて前記決済センター装置との通信をリトライするか否かを決定する、ことを特徴とする。
これにより、決済に必要な情報を確実に送受信することができる。
【００１７】
また、本発明のデータ送受信方法は、決済処理に関する情報をカード会社のサーバに送信する決済センター装置との間で決済に必要な情報を送受信し、送受信した前記決済に必要な情報を使用して決済を行う決済端末システムのデータ送受信方法であって、リトライ制御手段が、前記決済に必要な情報の送受信状態に応じて、前記決済センター装置との通信をリトライする方法を決定し、決定した前記リトライ方法に基づいて前記決済センター装置との通信をリトライさせるリトライ制御手順、を含む、ことを特徴とする。
【発明の効果】
【００１８】
本発明によれば、決済端末システムによる決済処理時の通信への影響を少なくし、かつデータ送受信における通信料金の増大を抑えることができるという効果が得られる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態による決済端末システムの概略構成の例を示したブロック図である。
【図２】本発明の実施形態による決済端末システムの別の概略構成の例を示したブロック図である。
【図３】本発明の実施形態における決済端末システムの起動時の処理手順を示したフローチャートである。
【図４】本発明の実施形態における決済端末システムのリトライ時の処理手順を示したフローチャートである。
【図５】本発明の実施形態の決済端末システムにおいて最大リトライ回数を算出する処理手順を示したフローチャートである。
【図６】本発明の実施形態の決済端末システムにおいてリトライ開始時間を算出する処理手順を示したフローチャートである。
【図７】本発明の実施形態の決済端末システムが送受信する通信信号におけるデータ構造の例を示したデータ構成図である。
【図８】本発明の実施形態の決済端末システムにおいてデータサイズを算出する処理手順を示したフローチャートである。
【図９】本発明の実施形態における決済端末システムの空車時の処理手順を示したフローチャートである。
【図１０】本発明の実施形態における決済端末システムの締めまたは集計時の処理手順を示したフローチャートである。
【図１１】本発明の実施形態における決済端末システムの決済開始時の処理手順を示したフローチャートである。
【発明を実施するための形態】
【００２０】
以下、本発明の実施形態について、図面を参照して説明する。図１は、本実施形態による決済端末システムの概略構成の例を示したブロック図である。図１において、決済端末システム１０は、移動体通信モジュール１００、決済端末２００から構成される。
また、決済端末２００は、センターＩ／Ｆ（インタフェース）部２１０、決済処理部２２０、設定データ記憶部２３０、接触カード決済ログ記憶部２４０、接触カードＩ／Ｆ（インタフェース）部２５０、非接触ＩＣカード決済処理部３２０、非接触カード設定データ記憶部３３０、非接触ＩＣカード決済ログ記憶部３４０、非接触ＩＣカードＩ／Ｆ（インタフェース）部３５０、ネガデータ記憶部３６０から構成される。
また、決済処理部２２０は、リトライ処理部２２１を備え、非接触ＩＣカード決済処理部３２０は、非接触ＩＣリトライ処理部３２１を備える。
また、決済端末システム１０は、無線通信によって、移動体通信網２を介して決済センター１と互いに接続され、決済システムとして構築されている。
また、図１では、決済端末システム１０が、タクシーに搭載されたタクシー決済端末である例を示しており、決済端末２００は、さらにメーターＩ／Ｆ（インタフェース）部２７０を備えている。以下、決済端末システム１０は、タクシーに搭載されたタクシー決済端末であるものとして説明する。
【００２１】
決済センター１は、例えば、サーバなどのコンピュータ装置を備え、図示しないカード会社のサーバと接続し、決済システム１０から受信した決済要求をカード会社のサーバに送信する。また、カード決済をオンラインで行う場合には、カード会社のサーバへ決済システム１０からの決済要求を送信した後、当該決済に使用するカードが使用可能なカードであり売上が可能か否かという承認結果をカード会社のサーバから受信し、決済システム１０へ送信する。
また、決済センター１は、例えば、カードの有効期限、紛失届の提出の有無など、接触型決済カードや非接触型ＩＣ決済カードが使用可能なカードであるか否かを表す情報として、使用不可能なカードの一覧を示した情報（ネガデータ）を、各カード会社のサーバから取得し記録している。これは、決済システム１０が、決済に使用するカードが使用可能なカードであるかの確認を自システム内で行う際に必要なデータ（決済に必要な情報）であり、決済システム１０は、以下で説明するように、このデータの最新のものを取得するような仕組みを持っている。
また、決済センター１には、接触型決済カード４および非接触型ＩＣ決済カード５によって決済処理を行うために必要となる決済端末２００の設定データや、決済端末２００の動作プログラムを更新するための更新プログラムなど、決済端末システム１０が常に正常に動作するための保守情報が記録されている。このような保守情報も、決済システム１０が決済を行うのに必要な情報であるため、決済システム１０は、ネガデータと同様に、保守情報も最新のものを取得する。
【００２２】
決済端末システム１０は、タクシー車両に搭載され、タクシーメーター装置３から入力された、タクシーの運転状態を表す情報（タクシー運転情報）に基づいて、タクシーの乗車料金の精算の処理を行う。
また、決済端末システム１０は、接触型決済カード４または非接触型ＩＣ決済カード５から読み取ったカード情報と、決済センター１から取得したネガデータとを照合し、読み取ったカード情報が有効なカードの情報である場合にタクシーの乗車料金の決済処理を行う。
【００２３】
移動体通信モジュール１００は、移動体通信網２を介して決済センター１と通信を行う通信装置である。移動体通信モジュール１００は、決済端末２００が決済センター１から設定データ、ネガデータ、更新プログラムなどのデータを取得する際、決済センター１から移動体通信網２を介して送信されてきたデータを受信し、受信したデータを順次決済端末２００に出力する。
また、移動体通信モジュール１００は、決済端末２００が決済センター１に決済ログなどのデータを送信する際、決済端末２００から順次出力されたデータを、移動体通信網２を介して決済センター１に送信する。
【００２４】
決済端末２００は、移動体通信モジュール１００から入力された設定データ、ネガデータに基づいて、接触型決済カード４または非接触型ＩＣ決済カード５による決済処理を行う。
また、決済端末２００は、決済処理が完了した決済ログのデータ（接触カード決済ログおよび非接触ＩＣカード決済ログ）を移動体通信モジュール１００に出力する。また、決済端末２００は、移動体通信モジュール１００から入力された更新プログラムに基づいて、自決済端末２００の動作プログラムを更新する。
【００２５】
センターＩ／Ｆ部２１０は、移動体通信モジュール１００と決済端末２００とのインタフェースであり、移動体通信モジュール１００から順次入力されたデータを、決済処理部２２０が処理するデータ系列（例えば、パラレルデータ系列）に変換し、変換後のデータを決済処理部２２０に出力する。
また、センターＩ／Ｆ部２１０は、決済処理部２２０から入力されたデータを、移動体通信モジュール１００に出力するデータ系列（例えば、シリアルデータ系列）に変換し、変換後のデータを順次移動体通信モジュール１００に出力する。
【００２６】
メーターＩ／Ｆ部２７０は、タクシーメーター装置３とのインタフェースであり、タクシーメーター装置３から入力されたタクシー運転情報や乗車料金の情報を取得し、決済処理部２２０に出力する。
【００２７】
設定データ記憶部２３０は、例えば、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）やＦｌａｓｈＲＯＭ（Ｆｌａｓｈ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）などの書き込み可能なメモリであり、決済処理部２２０におけるタクシー乗車料金の決済処理を行うための設定データを記憶する。
【００２８】
接触カード決済ログ記憶部２４０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリであり、接触型決済カード４を利用して決済処理された接触カード決済ログを記憶する。
【００２９】
接触カードＩ／Ｆ部２５０は、例えば、磁気カードリーダやＩＣカードリーダなどのカードリーダであり、接触型決済カード４に記録されているカード情報を読み取り、読み取ったカード情報を決済処理部２２０に出力する。
【００３０】
決済処理部２２０は、例えば、ＣＰＵ（中央処理装置：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの処理装置であり、例えば、図示しないＦｌａｓｈＲＯＭなどの書き込み可能な不揮発性メモリ（以下、「決済処理部用プログラム記憶部」という）に記憶されている動作プログラムに基づいて決済端末２００の全体を制御する。
また、決済処理部２２０は、接触型決済カード４によって決済処理を行う際に必要な設定データを設定データ記憶部２３０に記憶させる。また、決済処理部２２０は、接触カードＩ／Ｆ部２５０が読み取った接触型決済カード４のカード情報と設定データ記憶部２３０に記憶されている設定データとに基づいて、接触型決済カード４を利用した決済処理を行う。
また、決済処理部２２０は、接触型決済カード４を利用して決済処理された接触カード決済ログを接触カード決済ログ記憶部２４０に記憶させ、センターＩ／Ｆ部２１０に出力する。
また、決済処理部２２０は、センターＩ／Ｆ部２１０から入力された更新プログラムを決済処理部用プログラム記憶部に記憶し、記憶した更新プログラムに基づいて、自決済処理部２２０の動作プログラムを更新する。
【００３１】
また、決済処理部２２０は、自決済処理部２２０が決済処理を行う際に必要な設定データ、自決済処理部２２０の更新プログラム、非接触ＩＣカード決済処理部３２０が決済処理を行う際に必要な設定データ、ネガデータ、および更新プログラムのデータを決済センター１から取得する際に、データが正常に取得できなかった場合には、リトライ処理を行って正常なデータを取得する。
また、決済処理部２２０は、決済センター１から取得した非接触ＩＣカード決済処理部３２０が決済処理を行う際に必要な設定データ、ネガデータ、および更新プログラムを非接触ＩＣカード決済処理部３２０に出力する。
【００３２】
リトライ処理部２２１は、決済処理部２２０によるデータ取得のリトライ処理を行う。なお、リトライ処理部２２１によるリトライ処理に関しては、後述する。
【００３３】
非接触カード設定データ記憶部３３０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリであり、非接触ＩＣカード決済処理部３２０におけるタクシー乗車料金の決済処理を行うための設定データを記憶する。
【００３４】
非接触ＩＣカード決済ログ記憶部３４０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリであり、非接触型ＩＣ決済カード５を利用して決済処理された非接触ＩＣカード決済ログを記憶する。
【００３５】
ネガデータ記憶部３６０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリであり、非接触型ＩＣ決済カード５のネガデータを記憶する。
【００３６】
非接触ＩＣカードＩ／Ｆ部３５０は、例えば、非接触ＩＣカードリーダライターなどのカードリーダライターであり、非接触型ＩＣ決済カード５に記録されているカード情報や利用可能金額などの情報を読み取り、読み取ったカード情報や利用可能金額情報を非接触ＩＣカード決済処理部３２０に出力する。また、非接触ＩＣカード決済処理部３２０による決済処理が完了した後に、非接触ＩＣカード決済処理部３２０から出力された決済処理後の利用可能金額の情報を非接触型ＩＣ決済カード５に記録する。
【００３７】
非接触ＩＣカード決済処理部３２０は、例えば、ＣＰＵなどの処理装置であり、例えば、図示しないＦｌａｓｈＲＯＭなどの書き込み可能な不揮発性メモリ（以下「非接触ＩＣカード決済処理部用プログラム記憶部」という）に記憶されている動作プログラムに基づいて決済端末２００における非接触型ＩＣ決済カード５による決済処理を制御する。
なお、非接触ＩＣカード決済処理部３２０は、機能的に、決済端末２００における決済処理部２２０の一部として位置づけられ、決済処理部２２０からの指示に基づいて、決済端末２００による決済処理の内の非接触型ＩＣ決済カード５に関する決済処理を行う。
また、非接触ＩＣカード決済処理部３２０は、決済処理部２２０から入力された、非接触型ＩＣ決済カード５によって決済処理を行う際に必要な設定データを非接触カード設定データ記憶部３３０に記憶させる。また、非接触ＩＣカード決済処理部３２０は、決済処理部２２０から入力された非接触型ＩＣ決済カード５のネガデータをネガデータ記憶部３６０に記憶させる。また、非接触ＩＣカード決済処理部３２０は、非接触ＩＣカードＩ／Ｆ部３５０が読み取った非接触型ＩＣ決済カード５のカード情報と、非接触カード設定データ記憶部３３０に記憶されている設定データと、ネガデータ記憶部３６０に記憶されているネガデータとに基づいて、非接触型ＩＣ決済カード５を利用した決済処理を行う。
また、非接触ＩＣカード決済処理部３２０は、非接触型ＩＣ決済カード５を利用して決済処理された非接触ＩＣカード決済ログを非接触ＩＣカード決済ログ記憶部３４０に記憶させ、決済処理部２２０に出力する。また、非接触ＩＣカード決済処理部３２０は、決済処理部２２０から入力された更新プログラムを非接触ＩＣカード決済処理部用プログラム記憶部に記憶し、記憶した更新プログラムに基づいて、自非接触ＩＣカード決済処理部３２０の動作プログラムを更新する。
なお、本実施形態の説明においては、非接触ＩＣカード決済処理部３２０と、決済処理部２２０とは、それぞれ別のＣＰＵで構成した場合について説明するが、非接触ＩＣカード決済処理部３２０と決済処理部２２０とを１つのＣＰＵで構成することもできる。例えば、決済処理部２２０のＣＰＵのみを備えている場合、この決済処理部２２０のＣＰＵは、上述した非接触ＩＣカード決済処理部３２０と同様の動作も行う。
【００３８】
また、非接触ＩＣカード決済処理部３２０は、決済処理を行う際に必要な設定データ、ネガデータ、および更新プログラムのデータを決済センター１から取得する際に、データが正常に取得できなかった場合には、リトライ処理を行って正常なデータを取得する。
【００３９】
非接触ＩＣリトライ処理部３２１は、非接触ＩＣカード決済処理部３２０によるデータ取得のリトライ処理を行う。なお、非接触ＩＣリトライ処理部３２１によるリトライ処理に関しては、後述する。
【００４０】
次に、本発明の実施形態の決済端末システムの別の構成について説明する。図２は、本実施形態による決済端末システムの別の概略構成の例を示したブロック図である。
図２において、決済端末システム２０は、移動体通信モジュール１００、決済端末２００、非接触ＩＣカードリーダライター３００から構成される。
また、決済端末２００は、センターＩ／Ｆ部２１０、決済処理部２２０、設定データ記憶部２３０、接触カード決済ログ記憶部２４０、接触カードＩ／Ｆ部２５０、リーダライターＩ／Ｆ部２６０から構成される。
また、決済処理部２２０は、リトライ処理部２２１を備える。また、非接触ＩＣカードリーダライター３００は、決済端末Ｉ／Ｆ部３１０、非接触ＩＣカード決済処理部３２０、非接触カード設定データ記憶部３３０、非接触ＩＣカード決済ログ記憶部３４０、非接触ＩＣカードＩ／Ｆ部３５０、ネガデータ記憶部３６０から構成される。
また、非接触ＩＣカード決済処理部３２０は、非接触ＩＣリトライ処理部３２１を備える。
また、決済端末システム２０は、図１に示した決済端末システム１０と同様に、無線通信によって、移動体通信網２を介して決済センター１と互いに接続され、決済システムとして構築されている。
また、図２では、決済端末システム２０が、タクシーに搭載されたタクシー決済端末である例を示しており、決済端末２００は、さらにメーターＩ／Ｆ部２７０を備えている。以下、決済端末システム２０は、タクシーに搭載されたタクシー決済端末であるものとして説明する。
【００４１】
なお、図２に示した決済端末システム２０と図１に示した決済端末システム１０との構成の違いは、図１に示した決済端末システム１０内の非接触型ＩＣ決済カード５による決済処理に関する構成要素が、非接触ＩＣカードリーダライター３００として決済端末２００と異なる装置で構成されたことである。これに伴い、決済端末２００と非接触ＩＣカードリーダライター３００のインタフェースとして、決済端末２００にリーダライターＩ／Ｆ部２６０が追加され、非接触ＩＣカードリーダライター３００に決済端末Ｉ／Ｆ部３１０が追加されている。
なお、図２に示した決済端末システム２０と図１に示した決済端末システム１０とにおいて、同様の動作をする構成要素については、同一の符号を付与して説明を省略する。
【００４２】
決済端末システム２０は、図１に示した決済端末システム１０と同様に、タクシー車両に搭載され、タクシーメーター装置３から入力されたタクシー運転情報に基づいて、タクシーの乗車料金の精算の処理を行う。
また、決済端末システム２０は、接触型決済カード４または非接触型ＩＣ決済カード５から読み取ったカード情報と、決済センター１から取得したネガデータとを照合し、読み取ったカード情報が有効なカードの情報である場合にタクシーの乗車料金の決済処理を行う。
【００４３】
決済端末２００は、移動体通信モジュール１００から入力された設定データ、ネガデータに基づいて、接触型決済カード４による決済処理を行う。
また、決済端末２００は、自決済端末２００によって決済処理が完了した決済ログのデータ（接触カード決済ログ）および非接触ＩＣカードリーダライター３００から入力された非接触型ＩＣ決済カード５による決済処理が完了した決済ログのデータ（非接触ＩＣカード決済ログ）を移動体通信モジュール１００に出力する。
また、決済端末２００は、移動体通信モジュール１００から入力された更新プログラムに基づいて、自決済端末２００の動作プログラムを更新する。
また、決済端末２００は、移動体通信モジュール１００から入力された非接触ＩＣカードリーダライター３００が決済処理を行う際に必要な設定データ、ネガデータ、および更新プログラムを非接触ＩＣカードリーダライター３００に出力する。
【００４４】
リーダライターＩ／Ｆ部２６０は、決済端末２００と非接触ＩＣカードリーダライター３００とのインタフェースであり、決済処理部２２０から入力されたデータを、非接触ＩＣカードリーダライター３００に出力するデータ系列（例えば、シリアルデータ系列）に変換し、変換後のデータを順次非接触ＩＣカードリーダライター３００に出力する。
また、リーダライターＩ／Ｆ部２６０は、非接触ＩＣカードリーダライター３００から順次入力されたデータを、決済処理部２２０が処理するデータ系列（例えば、パラレルデータ系列）に変換し、変換後のデータを決済処理部２２０に出力する。
【００４５】
決済処理部２２０は、例えば、ＣＰＵなどの処理装置であり、決済処理部用プログラム記憶部に記憶されている動作プログラムに基づいて決済端末２００の全体を制御する。また、決済処理部２２０は、図１に示した決済端末システム１０と同様に、接触カードＩ／Ｆ部２５０が読み取った接触型決済カード４のカード情報と設定データ記憶部２３０に記憶されている設定データとに基づいて、接触型決済カード４による決済処理を行い、センターＩ／Ｆ部２１０に出力する。
また、決済処理部２２０は、非接触ＩＣカード決済処理部３２０が決済処理を行う際に必要な設定データ、ネガデータ、および更新プログラムをリーダライターＩ／Ｆ部２６０に出力する。
【００４６】
非接触ＩＣカードリーダライター３００は、決済端末２００から入力された設定データ、ネガデータに基づいて、非接触型ＩＣ決済カード５による決済処理を行う。
また、非接触ＩＣカードリーダライター３００は、自非接触ＩＣカードリーダライター３００によって決済処理が完了した決済ログのデータ（非接触ＩＣカード決済ログ）を決済端末２００に出力する。
また、非接触ＩＣカードリーダライター３００は、決済端末２００から入力された更新プログラムに基づいて、自非接触ＩＣカードリーダライター３００の動作プログラムを更新する。
【００４７】
決済端末Ｉ／Ｆ部３１０は、決済端末２００と非接触ＩＣカードリーダライター３００とのインタフェースであり、決済端末２００から順次入力されたデータを、非接触ＩＣカード決済処理部３２０が処理するデータ系列（例えば、パラレルデータ系列）に変換し、変換後のデータを非接触ＩＣカード決済処理部３２０に出力する。
また、決済端末Ｉ／Ｆ部３１０は、非接触ＩＣカード決済処理部３２０から入力されたデータを、決済端末２００に出力するデータ系列（例えば、シリアルデータ系列）に変換し、変換後のデータを順次決済端末２００に出力する。
【００４８】
非接触ＩＣカード決済処理部３２０は、例えば、ＣＰＵなどの処理装置であり、非接触ＩＣカード決済処理部用プログラム記憶部に記憶されている動作プログラムに基づいて非接触ＩＣカードリーダライター３００における非接触型ＩＣ決済カード５による決済処理を制御する。なお、非接触ＩＣカードリーダライター３００は、決済端末システム２０において、決済端末２００による決済処理の一部、より具体的には、非接触型ＩＣ決済カード５に関する決済処理を行う構成要素として位置づけられているため、非接触ＩＣカード決済処理部３２０は、決済端末２００内の決済処理部２２０からの指示に基づいて、非接触型ＩＣ決済カード５に関する決済処理を行う。
また、非接触ＩＣカード決済処理部３２０は、決済端末Ｉ／Ｆ部３１０から入力された、非接触型ＩＣ決済カード５によって決済処理を行う際に必要な設定データを非接触カード設定データ記憶部３３０に記憶させる。
また、非接触ＩＣカード決済処理部３２０は、決済端末Ｉ／Ｆ部３１０から入力された非接触型ＩＣ決済カード５のネガデータをネガデータ記憶部３６０に記憶させる。
また、非接触ＩＣカード決済処理部３２０は、非接触ＩＣカードＩ／Ｆ部３５０が読み取った非接触型ＩＣ決済カード５のカード情報と、非接触カード設定データ記憶部３３０に記憶されている設定データと、ネガデータ記憶部３６０に記憶されているネガデータとに基づいて、非接触型ＩＣ決済カード５を利用した決済処理を行う。
また、非接触ＩＣカード決済処理部３２０は、非接触型ＩＣ決済カード５を利用して決済処理された非接触ＩＣカード決済ログを非接触ＩＣカード決済ログ記憶部３４０に記憶させ、決済端末Ｉ／Ｆ部３１０に出力する。
【００４９】
ここで、本発明の実施形態の決済端末システムにおける決済処理について説明する。なお、図１に示した決済端末システム１０と図２に示した決済端末システム２０とは、非接触型ＩＣ決済カード５による決済処理を行う構成要素を決済端末２００内に備えているか、決済端末２００の外部で別の構成要素（非接触ＩＣカードリーダライター３００）として備えているかの違いのみであり、決済処理における処理方法は同等である。従って、以下の説明では、図１に示した決済端末システム１０における決済処理について説明する。
【００５０】
決済端末システム１０におけるオンラインでカード認証処理を行うタイプの決済処理は、以下の手順で行われる。なお、以下の説明において決済を行う接触型決済カード４は、接触型の磁気決済カードであるものとし、センターＩ／Ｆ部２１０によるデータ系列の変換は逐次行われていることとし、センターＩ／Ｆ部２１０に関する説明を省略する。
【００５１】
（手順１）：決済処理部２２０は、接触カードＩ／Ｆ部２５０が読み取った接触型決済カード４のカード情報を移動体通信モジュール１００に出力する。そして、移動体通信モジュール１００は、決済処理部２２０から入力された接触型決済カード４のカード情報と、メーターＩ／Ｆ部２７０がタクシーメーター装置３から取得した乗車料金の情報とを、移動体通信網２を介して決済センター１に送信する。
（手順２）：決済センター１は、送信されてきたカード情報と乗車料金の情報とをカード会社のサーバに送信し、カード会社のサーバから受信した、当該接触型決済カード４が使用可能なカードであり売上が可能であるか否かの承認結果を、移動体通信網２を介して決済端末システム１０に送信する。
（手順３）：移動体通信モジュール１００は、受信した承認結果を決済処理部２２０に出力する。そして、決済処理部２２０は、移動体通信モジュール１００から、接触型決済カード４が使用可能なカードであると認証され、売上が可能であるという承認結果であった場合、メーターＩ／Ｆ部２７０がタクシーメーター装置３から取得した乗車料金の情報と、設定データ記憶部２３０に記憶されている設定データとに基づいて、タクシーメーター装置３に売上伝票を印字させ、接触型決済カード４を利用した決済処理を完了させる。
（手順４）：決済処理部２２０は、決済処理が完了した接触型決済カード４による接触カード決済ログを接触カード決済ログ記憶部２４０に記憶する。
（手順５）：カード会社は、決済センター１から受けた該決済に関する情報により、決済端末システム１０を使用しているタクシー会社への入金処理を行う。
【００５２】
上記の処理手順のように、接触型決済カード４による決済処理では、決済処理を行うときに接触型決済カード４のカード情報とネガデータとの照合を毎回行い、使用可能なカードによってのみ決済処理を行う。これにより、確実に入金処理が行われるようにしている。
【００５３】
また、決済端末システム１０におけるオフラインでカード認証処理を行うタイプの決済処理は、以下の手順で行われる。なお、以下の説明において決済を行う非接触型ＩＣ決済カード５は、非接触型のＩＣ決済カードであるものとし、決済端末２００は、事前に決済センター１から非接触型ＩＣ決済カード５のネガデータを取得し、ネガデータ記憶部３６０に記憶しているものとする。
【００５４】
（手順１）：非接触ＩＣカード決済処理部３２０は、非接触ＩＣカードＩ／Ｆ部３５０が読み取った非接触型ＩＣ決済カード５のカード情報と、ネガデータ記憶部３６０に記憶しているネガデータとを照合し、カード情報を取得した非接触型ＩＣ決済カード５が使用可能なカードであるか否かを確認する。
（手順２）：非接触型ＩＣ決済カード５が使用可能なカードである場合、非接触ＩＣカード決済処理部３２０は、非接触型ＩＣ決済カード５が使用可能なカードであることを示す情報を決済処理部２２０に出力する。
（手順３）：決済処理部２２０は、非接触ＩＣカード決済処理部３２０から使用可能なカードであることを示す情報が入力されると、メーターＩ／Ｆ部２７０がタクシーメーター装置３から取得した乗車料金の情報を非接触ＩＣカード決済処理部３２０に出力する。
（手順４）：非接触ＩＣカード決済処理部３２０は、決済処理部２２０から入力された乗車料金の情報と、非接触カード設定データ記憶部３３０に記憶されている設定データと、非接触ＩＣカードＩ／Ｆ部３５０が読み取った非接触型ＩＣ決済カード５の利用可能金額の情報とに基づいて、非接触型ＩＣ決済カード５を利用した決済処理を行う。
（手順５）：非接触ＩＣカード決済処理部３２０は、非接触ＩＣカードＩ／Ｆ部３５０によって、決済処理後の利用可能金額（例えば、非接触型ＩＣ決済カード５の利用可能金額から乗車料金を差し引いた後の利用可能金額）の情報を、非接触型ＩＣ決済カード５に記録する。また、非接触ＩＣカード決済処理部３２０は、決済処理が完了した非接触型ＩＣ決済カード５による非接触ＩＣカード決済ログを非接触ＩＣカード決済ログ記憶部３４０に記憶する。
【００５５】
上記の処理手順のように、非接触型ＩＣ決済カード５による決済処理においては、ネガデータをネガデータ記憶部３６０に記憶しておき、ネガデータと非接触型ＩＣ決済カード５のカード情報との照合を決済端末２００内で行うことができる。このことにより、決済処理のたびに、決済センター１との通信を毎回行う必要がないため、決済センター１との通信に係る時間を短縮することができ、非接触型ＩＣ決済カード５による決済処理の時間を短縮している。その後、決済端末システム１０は、決済処理の締め処理または決済ログの集計処理のときに以下の手順を行うことによって、非接触型ＩＣ決済カード５による決済処理が完了する。
【００５６】
（手順６）：非接触ＩＣカード決済処理部３２０は、非接触ＩＣカード決済ログ記憶部３４０に記憶している非接触ＩＣカード決済ログを決済処理部２２０に出力する。続いて、決済処理部２２０は、非接触ＩＣカード決済処理部３２０から入力された非接触ＩＣカード決済ログを、移動体通信モジュール１００に出力する。そして、移動体通信モジュール１００は、決済処理部２２０から入力された非接触ＩＣカード決済ログを、移動体通信網２を介して決済センター１に送信する。
（手順７）：決済センター１は、送信されてきた非接触ＩＣカード決済ログに基づいて、カード会社に決済に関する情報を送信し、これを受けてカード会社が決済端末システム１０を使用しているタクシー会社への入金処理を行う。
【００５７】
上記の処理手順のように、非接触型ＩＣ決済カード５による決済処理では、毎回決済センター１と通信することによってネガデータとの照合を行うのではなく、ネガデータ記憶部３６０に記憶しているネガデータとの照合を行うことによって、決済処理に係る時間が短縮される。
【００５８】
決済端末システム１０内に記憶したネガデータとの照合を行うことによって決済処理を行う場合、確実に入金処理が行われるようにするためには、ネガデータ記憶部３６０に記憶しているネガデータは、新しいデータである必要がある。また、このネガデータは、決済処理を実施していないときに、別途決済センター１から取得する。
【００５９】
次に、本発明の実施形態の決済端末システムにおいて、決済センターとの通信によってデータを送受信する処理手順について説明する。図３は、本実施形態の決済端末システム１０の起動時の処理手順を示したフローチャートである。なお、決済端末システム１０が起動されたときの起動処理においては、決済センター１と通信することによって、複数のデータの送受信を行う場合があるが、以下の説明においては、最新のネガデータを取得するときの処理手順を例にとって説明する。
【００６０】
決済端末システム１０が起動されると、まず、ステップＳ１００において、決済処理部２２０は、メーターＩ／Ｆ部２７０がタクシーメーター装置３から取得したタクシー運転情報に基づいて、今回の起動がタクシーの本日の始業によるものであるか否かを確認する。より具体的には、タクシーが始業することを表す出庫通知によって、タクシーが始業することを確認することができる。今回の起動がタクシーの本日の始業によるものである場合は、ステップＳ２００に進む。そして、ステップＳ２００において、決済処理部２２０は、ネガデータ取得のステータス（状態）を初期化する。
より具体的には、リトライステータスを、リトライが必要であることを示す値である「リトライ要」とし、リトライ回数を「０回」とし、リトライ開始時間をリトライ時間テーブルの初期値（例えば、「５分」）とする。なお、これらのステータスは、タクシーの１日の営業における初期値となる。また、これらのステータスの値は、タクシーの営業時間内に決済端末システム１０の電源がＯＦＦされた場合でも設定値を保持するために、図示しない不揮発性メモリ（以後、「リトライステータス記憶部」という）に記憶する。なお、リトライ時間テーブルに関しては、後述する。
【００６１】
また、ステップＳ１００において、今回の起動がタクシーの本日の始業によるものでない場合は、ステップＳ３００において、起動時のリトライ処理を行う設定がされているか否かを確認し、起動時のリトライ処理を行う設定がされていない場合は、リトライステータス記憶部に記憶されているリトライステータス、リトライ回数、リトライ時間を読み出し、ステップＳ４００に進んでデータの取得処理を行う。なお、起動時のリトライ処理の設定に関しては、後述する。
【００６２】
続いて、ステップＳ４００において、決済処理部２２０は、現在決済センター１から取得しようとしているネガデータが、今回の起動処理における最後のデータであるか否かを確認する。決済センター１から取得しようとしているネガデータが最後のデータである場合は、処理を完了し、現状のリトライステータス、リトライ回数、リトライ時間をリトライステータス記憶部に記憶する。決済センター１から取得しようとしているネガデータが最後のデータでない場合は、ステップＳ５００に進む。
【００６３】
続いて、ステップＳ５００において、決済処理部２２０は、現在決済センター１から取得しようとしているネガデータのリトライステータスが「リトライ要」であるか否かを確認する。リトライステータスが「リトライ要」でない、すなわち、リトライは不要であることを示す値である「リトライ不要」である場合は、ステップＳ９００に進む。また、リトライステータスが「リトライ要」である場合は、ステップＳ６００に進んで、データの受信処理を行う。
【００６４】
続いて、ステップＳ７００において、決済処理部２２０は、データの受信処理が成功したか、すなわち、正常にデータを取得することができたか否かを確認し、データの受信処理が成功した場合は、ステップＳ８００において、受信処理が成功したネガデータのリトライステータスを「リトライ不要」とする。そして、決済処理部２２０は、ステップＳ９００において、決済センター１から取得しようとしているデータを、今回取得した次のデータとし、ステップＳ４００に戻ってデータを取得する処理を繰り返す。
【００６５】
また、ステップＳ７００において、データの受信処理が成功しなかった場合は、ステップＳ１０００において、決済処理部２２０は、最大リトライ回数を算出する。なお、最大リトライ回数を算出する処理手順に関しては、後述する。
【００６６】
続いて、ステップＳ１１００において、決済処理部２２０は、現在決済センター１から取得しようとしているネガデータのリトライ回数が、ステップＳ１０００において算出した最大リトライ回数未満であるか否かを確認し、最大リトライ回数未満である場合は、ステップＳ１２００において、次にリトライを開始するまでのリトライ開始時間を算出する。なお、リトライ開始時間を算出する処理手順に関しては、後述する。そして、ステップＳ１３００において、決済処理部２２０は、ネガデータのリトライステータスを「リトライ要」とし、処理を完了し、現状のリトライステータス、リトライ回数、リトライ時間をリトライステータス記憶部に記憶する。
【００６７】
また、ステップＳ１１００において、最大リトライ回数未満でない、すなわち、ネガデータを取得するために行ったリトライ回数が最大リトライ回数以上である場合、ステップＳ１４００において、決済処理部２２０は、ネガデータのリトライステータスを「リトライ不要」として、処理を完了し、現状のリトライステータス、リトライ回数、リトライ時間をリトライステータス記憶部に記憶する。
【００６８】
上述のように、決済センター１から取得しようとしているデータを正常に取得することができた場合は、リトライステータスを「リトライ不要」とする。また、データを正常に取得することができなかった場合は、最大リトライ回数の算出結果に基づいて以降のリトライ回数を決定し、リトライ回数が最大リトライ回数未満である場合にのみ、リトライを繰り返す。また、次にリトライを開始するまでのリトライ開始時間を設定することによって、リトライの繰り返しによる通信処理の占有と、通信料金の増大を抑えることができる。これにより、例えば、ネガデータや更新プログラムのような、データ量が大量であることが予想されるデータを決済センター１から受信する際に、例えば、接触型決済カード４による決済処理時に必要な決済センター１との通信時間を確保し、データの取得以外の他の通信処理に影響をおよぼさないようにすることができる。
【００６９】
なお、図３に示した決済端末システム１０の起動時の処理手順において、複数のデータを決済センター１から取得または決済センター１に送信しようとした場合に、取得または送信しようとする複数データの内１つでも取得または送信に失敗したデータがあったときは、起動時の処理を完了する。このデータ取得の失敗は、今回決済端末システム１０が起動されたときの通信状態が、安定して決済センターと通信を行うことができる環境ではないことが原因と考えられる。決済端末システム１０の起動時の処理においては、通信状態が良くない環境で次のデータ取得または送信を行っても失敗する可能性が高く、通信料金のみが増大する可能性が高いと判断する。そして、タクシーが移動することによって通信状態が改善されている可能性が高い状態でのリトライ処理によって、取得または送信に失敗したデータを含めて、以降のデータ取得または送信を行うという考えに基づいたものである。
【００７０】
なお、上述の説明では、決済に必要な情報としてネガデータを取得する例について説明したが、その他の決済に必要な情報である設定データや更新プログラムなどのデータを取得する場合も同様に考えることができる。また、決済センター１での処理まで含めた決済を考慮した場合には、決済ログのように決済端末システム１０から送信する情報も決済に必要な情報と解釈できる。よって、決済ログのデータを決済センター１に送信する場合も同様に考えることができる。この場合、図３に示した決済端末システム１０の起動時のフローチャートにおいて、ステップＳ１００で、メーターＩ／Ｆ部２７０がタクシーメーター装置３から取得したタクシー運転情報から、本日の終業であるか否かを確認する。より具体的には、タクシーが終業することを表す入庫通知によって、タクシーが終業することを確認する。そして、ステップＳ６００において、データの送信処理を行うことによって、決済ログのデータを決済センター１に送信することができる。
【００７１】
また、本実施形態の決済端末システム１０が、タクシーに搭載されたタクシー決済端末である例について説明したが、タクシーメーター装置３から取得するタクシー運転情報や乗車料金の情報と同様な情報を取得することによって、タクシー決済端末以外にも適用することができる。例えば、タクシー運転情報における出庫通知や入庫通知に代わって、キー操作によって起動時の状態を示すことができるレジスターや、端末自体にキーと移動体通信モジュールとを備え、キー操作による金額入力等ができる携帯可能な決済端末などにも適用することができる。
【００７２】
次に、本発明の実施形態の決済端末システムにおける決済センターとの通信のリトライの処理手順について説明する。図４は、本実施形態の決済端末システム１０のリトライ時の処理手順を示したフローチャートである。以下に説明するリトライ処理は、例えば、図３に示した起動時の受信処理においてネガデータの受信処理が成功しなかった場合、すなわち、正常にデータを取得することができなかった場合に、リトライ処理部２２１によってデータを再度取得する処理である。また、このリトライ処理は、リトライ開始時間が経過した後に開始される。
なお、決済端末システム１０がタクシーに搭載されたタクシー決済端末においては、タクシーの営業に影響しないよう、例えば、タクシー運転情報における空車通知がタクシーメーター装置３から通知されたときにもリトライ処理が実行されるが、空車時のリトライ処理に関しては、後述する。なお、以下の説明においては、決済センター１と通信することによって、決済端末システム１０がネガデータを取得するときの処理手順を例にとって説明する。
【００７３】
リトライ処理が開始されると、まず、ステップＳ２０００において、決済処理部２２０内のリトライ処理部２２１は、リトライステータス記憶部の情報に基づいて、現在決済センター１からのデータ取得をリトライしようとしているネガデータのリトライステータスが「リトライ要」であるか否かを確認する。リトライステータスが「リトライ要」でない、すなわち、「リトライ不要」である場合は、処理を完了する。リトライステータスが「リトライ要」である場合は、ステップＳ２１００に進む。
【００７４】
続いて、ステップＳ２１００において、リトライ処理部２２１は、現在決済センター１からの取得をリトライしようとしているネガデータのリトライ回数が、最大リトライ回数未満であるか否かを確認する。リトライ回数が最大リトライ回数未満である場合は、ステップＳ２２００において、リトライ回数を、現在のリトライ回数に「１回」に相当する値を加算したリトライ回数に更新する。そして、ステップＳ２３００に進んで、データの受信処理を行う。
【００７５】
また、ステップＳ２１００において、現在決済センター１からの取得をリトライしようとしているネガデータのリトライ回数が、最大リトライ回数未満でない、すなわち、ネガデータを取得するために最大リトライ回数以上のリトライを繰り返している場合は、処理を完了する。
【００７６】
続いて、ステップＳ２４００において、リトライ処理部２２１は、データの受信処理が成功したか、すなわち、正常にデータを取得することができたか否かを確認し、データの受信処理が成功した場合は、ステップＳ２９００において、受信処理が成功したネガデータのリトライステータスを「リトライ不要」とし、処理を完了する。
【００７７】
また、ステップＳ２４００において、データの受信処理が成功しなかった場合は、ステップＳ２５００において、リトライ処理部２２１は、最大リトライ回数を算出する。なお、最大リトライ回数を算出する処理手順に関しては、後述する。
【００７８】
続いて、ステップＳ２６００において、リトライ処理部２２１は、現在決済センター１からの取得をリトライしようとしているネガデータのリトライ回数が、ステップＳ２５００において算出した最大リトライ回数未満であるか否かを確認し、最大リトライ回数未満である場合は、ステップＳ２７００において、次にリトライを開始するまでのリトライ開始時間を算出する。なお、リトライ開始時間を算出する処理手順に関しては、後述する。そして、ステップＳ２８００において、リトライ処理部２２１は、ネガデータのリトライステータスを「リトライ要」とし、処理を完了し、現状のリトライステータス、リトライ回数、リトライ時間をリトライステータス記憶部に記憶する。
【００７９】
また、ステップＳ２６００において、現在決済センター１からの取得をリトライしようとしているネガデータのリトライ回数が、ステップＳ２５００において算出した最大リトライ回数未満でない、すなわち、ネガデータを取得するために行ったリトライ回数が最大リトライ回数以上である場合、ステップＳ２９００において、リトライ処理部２２１は、ネガデータのリトライステータスを「リトライ不要」として、処理を完了し、現状のリトライステータス、リトライ回数、リトライ時間をリトライステータス記憶部に記憶する。
【００８０】
上述のように、決済センター１からの取得をリトライしようとしているデータを正常に取得することができた場合は、リトライステータスを「リトライ不要」とする。また、データを正常に取得することができなかった場合は、最大リトライ回数の算出結果に基づいて以降のリトライ回数を決定し、リトライ回数が最大リトライ回数未満である場合にのみ、リトライを繰り返す。また、次にリトライを開始するまでのリトライ開始時間を設定することによって、リトライの繰り返しによる通信処理の占有と、通信料金の増大を抑えることができる。これにより、例えば、ネガデータや更新プログラムのような、データ量が大量であることが予想されるデータを決済センター１から受信する際に、例えば、接触型決済カード４による決済処理時に必要な決済センター１との通信時間を確保し、データの取得以外の他の通信処理に影響をおよぼさないようにすることができる。
【００８１】
なお、上述の説明では、ネガデータを取得する例について説明したが、設定データや更新プログラムなどのデータを取得する場合も同様に考えることができる。また、決済センター１への決済ログのデータの送信をリトライする場合も同様に考えることができる。この場合、図４に示した決済端末システム１０のリトライ時のフローチャートにおいて、ステップＳ２３００で、データの送信処理を行うことによって、決済ログのデータを決済センター１に再送信することができる。
【００８２】
また、本実施形態の決済端末システム１０が、タクシーに搭載されたタクシー決済端末である例について説明したが、タクシーメーター装置３から取得するタクシー運転情報と同様な情報を取得することによって、タクシー決済端末以外にも適用することができる。例えば、タクシー運転情報における空車通知に代わって、キー操作によってリトライ処理を実行するか否かを選択することができるレジスターなどに適用し、リトライ処理を実行することが選択されたときにリトライ処理を実行することもできる。
【００８３】
なお、図３に示した起動時の送受信処理、または図４に示したリトライ処理におけるデータの送受信処理において、データの送受信中に他の通信処理を含む処理が実行される場合には、データの送受信処理を中止または中断し、他の処理に影響をおよぼさないようにすることができる。例えば、タクシー決済端末の場合では、データの送受信中に客がタクシーに乗車したことによって、賃走通知または実車通知がタクシーメーター装置３から通知されたときに、データの送受信処理を中止または中断する。また、賃走通知または実車通知がされているときには、次のリトライ処理も行わないようにすることができる。
【００８４】
次に、本発明の実施形態の決済端末システムにおいて、最大リトライ回数を算出する処理手順について説明する。図５は、本実施形態の決済端末システム１０において最大リトライ回数を算出する処理手順を示したフローチャートである。以下に説明する最大リトライ回数算出処理は、例えば、図３に示した起動時の送受信処理、または図４に示したリトライ処理におけるデータの送受信処理が成功しなかった場合、すなわち、正常にデータを取得または送信することができなかった場合に、取得または送信しようとするデータのデータ量（データサイズ）に応じて最大のリトライ回数を決定する処理である。
【００８５】
まず、ステップＳ３０００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成されるデータサイズ保存領域から、現在決済センター１から取得または決済センター１に送信しようとしているデータのデータサイズを取り出す。なお、データサイズ保存領域に記憶するデータサイズの算出方法に関しては、後述する。
【００８６】
続いて、ステップＳ３１００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成されるリトライ回数決定テーブルから、現在決済センター１から取得または決済センター１に送信しようとしているデータのデータサイズに対応するリトライ回数を取り出す。なお、リトライ回数決定テーブルは、図５に示すようにデータサイズに応じたリトライ回数が記憶されたテーブルデータである。このリトライ回数決定テーブルによって、データサイズ毎のリトライ回数を設定することができる。例えば、リトライ回数決定テーブル内のリトライ回数を「０回」とすることによって、リトライ処理を行わない設定にすることもできる。
【００８７】
続いて、ステップＳ３２００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成される最大リトライ回数保存領域に、ステップＳ３１００において取り出したリトライ回数を保存する。
【００８８】
上述のように、決済センター１から取得または決済センター１に送信しようとしているデータのデータサイズに応じてリトライ回数を決定することができる。これにより、リトライの繰り返しによって通信処理を占有する時間が短いデータサイズの小さいデータは、リトライ回数を多くすることによって、確実に取得することができる。また、リトライの繰り返しによって通信処理を占有する時間が長いデータサイズの大きいデータは、リトライ回数を少なくすることによって、例えば、接触型決済カード４による決済処理のような他の処理に必要な通信時間を確保することができる。
【００８９】
なお、上記の説明において、データサイズ保存領域、リトライ回数決定テーブル、および最大リトライ回数保存領域は、それぞれ異なるメモリで構成されている例で説明したが、データサイズ保存領域、リトライ回数決定テーブル、および最大リトライ回数保存領域を同一のメモリとし、メモリ内の記憶領域をそれぞれ分けることによって構成することもできる。また、例えば、決済端末２００内の設定データ記憶部（設定データ記憶部２３０、非接触カード設定データ記憶部３３０）や、プログラム記憶部（決済処理部用プログラム記憶部、非接触ＩＣカード決済処理部用プログラム記憶部）と同一のメモリとすることもできる。この場合、決済センター１からデータを取得することによって、その内容を変更することもできる。
【００９０】
次に、本発明の実施形態の決済端末システムにおいて、リトライ開始時間を算出する処理手順について説明する。図６は、本実施形態の決済端末システム１０においてリトライ開始時間を算出する処理手順を示したフローチャートである。以下に説明するリトライ開始時間算出処理は、例えば、図３に示した起動時の送受信処理、または図４に示したリトライ処理におけるデータの送受信処理が成功しなかった場合、すなわち、正常にデータを取得または送信することができなかった場合に、取得または送信しようとするデータのデータ量（データサイズ）に応じて次にリトライを開始するまでのリトライ開始時間を決定する処理である。
【００９１】
まず、ステップＳ４０００において、決済処理部２２０は、データサイズ保存領域から、現在決済センター１から取得または決済センター１に送信しようとしているデータのデータサイズを取り出す。なお、データサイズ保存領域に記憶するデータサイズの算出方法に関しては、後述する。
【００９２】
続いて、ステップＳ４１００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成されるリトライ回数保存領域から、現在決済センター１から取得または決済センター１に送信しようとしているデータのリトライ回数を取り出す。このリトライ回数保存領域に記憶されているリトライ回数は、図４に示したリトライ処理のステップＳ２２００において更新されたリトライ回数である。
【００９３】
続いて、ステップＳ４２００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成されるリトライ時間決定テーブルから、現在決済センター１から取得または決済センター１に送信しようとしているデータのデータサイズおよびリトライ回数に対応するリトライ時間を取り出す。なお、リトライ時間決定テーブルは、図６に示すようにデータサイズおよびリトライ回数に応じて、次にリトライを開始するまでの時間が記憶されたテーブルデータである。このリトライ時間決定テーブルによって、データサイズおよびリトライ回数毎に、次にリトライを開始するまでの時間を設定することができる。なお、リトライ時間決定テーブルは、次にリトライを開始するまでの時間を決定するのみであり、実際に次のリトライ処理を行うか否かは、リトライステータスの値と、リトライ回数の値とによって判断される。
【００９４】
上述のように、決済センター１から取得または決済センター１に送信しようとしているデータのデータサイズおよびリトライ回数に応じて次にリトライを開始するまでの時間を決定することができる。これにより、リトライの繰り返しによって通信処理を占有する時間が短いデータサイズの小さいデータは、リトライ間隔を狭くすることによって、確実に取得することができる。また、リトライの繰り返しによって通信処理を占有する時間が長いデータサイズの大きいデータは、リトライ間隔を広くすることによって、例えば、接触型決済カード４による決済処理のような他の処理に必要な通信時間を確保することができる。また、これまでに実施したリトライ処理の処理回数が少ない場合は、リトライ間隔を狭くすることによって、データサイズの大きいデータでも確実に取得することができる可能性を高くすることができる。
【００９５】
なお、リトライ時間決定テーブルは、図３に示した起動時の送受信処理のステップＳ２００において、リトライ開始時間の初期化が記憶されたリトライ時間テーブルに対して、リトライ回数に関するデータが追加された構成である。従って、リトライ時間テーブルとリトライ時間決定テーブルとを同一のテーブルとし、リトライ開始時間を初期化する際には、リトライ時間決定テーブルのデータサイズおよびリトライ回数が最小の値（例えば、図６に示したリトライ時間決定テーブルでは、「５分」）を初期値とすることもできる。
【００９６】
なお、上記の説明において、リトライ回数保存領域およびリトライ時間決定テーブルは、それぞれ異なるメモリで構成されている例で説明したが、リトライ回数保存領域およびリトライ時間決定テーブルを同一のメモリとし、メモリ内の記憶領域をそれぞれ分けることによって構成することもできる。
また、リトライ回数保存領域およびリトライ時間決定テーブルを、データサイズ保存領域、リトライ回数決定テーブル、および最大リトライ回数保存領域を記憶しているメモリと同一のメモリとし、メモリ内の記憶領域をそれぞれ分けることによって構成することもできる。
また、例えば、決済端末２００内の設定データ記憶部（設定データ記憶部２３０、非接触カード設定データ記憶部３３０）や、プログラム記憶部（決済処理部用プログラム記憶部、非接触ＩＣカード決済処理部用プログラム記憶部）と同一のメモリとすることもできる。この場合、決済センター１からデータを取得することによって、その内容を変更することもできる。
【００９７】
次に、本発明の実施形態の決済端末システムにおいて、送受信処理を行うデータのデータサイズを算出する方法について説明する。図７は、本実施形態の決済端末システム１０が送受信する通信信号におけるデータ構造の例を示したデータ構成図である。なお、図７に示した通信信号は、決済端末システム１０が取得するネガデータの例を示している。なお、以下の説明においては、決済センター１と通信することによって、決済端末システム１０がネガデータを取得するときを例にとって説明する。
【００９８】
図７に示すように、決済端末システム１０が取得するネガデータの通信信号は、複数の電文（電文＃１〜電文＃ｎ＋１）によって構成されている。なお、この電文の数は、送受信するデータサイズによって異なり、データサイズの大きいデータを送受信するときほど、多くの電文を送受信することが必要となる。従って、通信状態が良くない環境における送受信処理では、電文の数に伴ってデータの送受信処理が失敗する確率が高くなる。
【００９９】
図７に示すように、各電文は、ヘッダーとデータ部とに分かれている。電文のヘッダーには、例えば、日付の情報など、自電文に関する情報が含まれている。また、電文のデータ部には、送受信するデータが含まれている。
【０１００】
まず、最初に受信する電文＃１のヘッダーには、電文＃１のデータ部のサイズを表す情報が含まれている。そして、電文＃１のデータ部にはデータ１からデータ３のデータが含まれており、データ２は、電文＃１以降に送信されてくるネガデータのデータサイズの情報を表している。
【０１０１】
次に受信する電文＃２（最初のネガデータ）のヘッダーには、電文＃２のデータ部のサイズ、すなわち、ネガデータ＃１のデータサイズを表す情報が含まれている。そして、電文＃２のデータ部にはネガデータ＃１が含まれている。決済端末システム１０は、この電文＃２に含まれるネガデータ＃１を取得する。以降、電文を受信する毎に、受信した電文に含まれるネガデータを取得する。そして、最後に受信する電文＃ｎ＋１（最後のネガデータ）に含まれるネガデータ＃ｎを取得することによって、決済端末システム１０が決済処理で使用する１つのネガデータの取得が完了する。
【０１０２】
図７に示したように、電文内にデータサイズを表す情報が含まれている場合は、このデータサイズの情報を、送受信処理を行う際のデータのデータサイズとして、データサイズ保存領域に記憶する。
【０１０３】
また、電文内にデータサイズを表す情報が含まれていない場合は、各電文に含まれるデータを取得した際のデータのサイズに基づいて、送受信処理を行う際のデータサイズを算出する。図８は、本実施形態の決済端末システム１０においてデータサイズを算出する処理手順を示したフローチャートである。以下に説明するデータサイズ算出処理は、例えば、図３に示した起動時の送受信処理、または図４に示したリトライ処理において、送受信処理と並行して実行される処理である。なお、このデータサイズ算出処理は、電文内にデータサイズを表す情報が含まれている場合においても実行することができる。また、以下の説明においては、決済センター１と通信することによって、決済端末システム１０がネガデータを取得するときを例にとって説明する。
【０１０４】
まず、ステップＳ５０００において、決済処理部２２０は、データサイズ保存領域から、現在決済センター１から取得しようとしているネガデータのデータサイズを取り出し、現状のデータサイズとする。なお、電文内にデータサイズを表す情報が含まれていない場合、最初にデータサイズ保存領域に記憶されているデータサイズの値は、「０ＫＢ（キロバイト）」である。
【０１０５】
続いて、ステップＳ５１００において、決済処理部２２０は、電文を受信する都度、現状のデータサイズの値と、受信した電文に含まれるネガデータを取得した際のデータサイズの値とを加算（累積）し、加算したデータサイズの値を現状のデータサイズの値とする。これにより、例えば、図７に示したネガデータ＃１〜ネガデータ＃ｎのデータサイズを全て累計した値が、ネガデータのデータサイズとなる。
【０１０６】
続いて、受信した全ての電文に含まれるネガデータの取得が完了すると、ステップＳ５２００において、決済処理部２２０は、最後に取得したネガデータのデータサイズの値を加算した後のネガデータのデータサイズ（全て累計したデータサイズ）を、送受信処理を行う際のデータのデータサイズとして、データサイズ保存領域に記憶する。
なお、データサイズ保存領域には、電文内の情報から取得したデータサイズと、電文内のデータに基づいて算出したデータサイズとを記憶することができる。
【０１０７】
上述のように、電文に含まれるデータサイズを表す情報、または受信した電文に含まれるデータを取得した際のデータサイズの値に基づいて、送受信処理を行う際のデータのデータサイズを取得することができる。これにより、データの送受信処理における最大リトライ回数や、次にリトライを開始するまでのリトライ開始時間を決定することができる。そして、データサイズに応じたリトライ処理を行うことができる。
【０１０８】
また、上述の説明では、最初にデータサイズ保存領域に記憶されているデータサイズの値が「０ＫＢ」、すなわち、初めて取得するデータのデータサイズを算出する例について説明したが、例えば、リトライ処理部におけるデータの取得に対しては、以下のように適用することができる。
【０１０９】
まず、ステップＳ５０００においてデータサイズ保存領域からネガデータのデータサイズを取り出した際に、取り出したデータサイズを現状のデータサイズとせず、別の記憶領域に記憶しておく。
そして、ステップＳ５２００において全て累計したデータサイズをデータサイズ保存領域に記憶する際に、別の記憶領域に記憶してあるデータサイズと、全て累計したデータサイズとを比較し、その値が大きい方のデータサイズを、送受信処理を行う際のデータのデータサイズとして、データサイズ保存領域に記憶（更新）する。
【０１１０】
このようにすることによって、前回よりも取得したデータサイズが少ない場合でも、データサイズ保存領域が少ないデータサイズの値に更新されことがない。これにより、現在決済センター１から取得しようとしているデータにおける最大リトライ回数や、次にリトライを開始するまでのリトライ開始時間を正しく決定することができる。
【０１１１】
なお、上述の説明では、ネガデータを取得する例について説明したが、設定データや更新プログラムなどのデータを取得する場合も同様に考えることができる。また、決済ログのデータを決済センター１に送信する場合も同様に考えることができる。
【０１１２】
次に、本発明の実施形態の決済端末システムにおける空車処理の処理手順について説明する。図９は、本実施形態の決済端末システム１０の空車時のリトライ処理の処理手順を示したフローチャートである。以下に説明する空車処理は、例えば、図３に示した起動時の処理においてデータの送受信処理が成功しなかったデータ、すなわち、正常にデータを取得または送信することができなかったデータを、タクシーが空車のときに再度取得する処理である。なお、以下の説明においては、決済センター１と通信することによって、決済端末システム１０がデータを取得するときの処理手順を例にとって説明する。
【０１１３】
タクシーメーター装置３から空車通知が通知されると、まず、ステップＳ６０００において、決済処理部２２０は、現在決済センター１からのデータ取得をリトライしようとしているデータを、前回までに決済センター１からデータを取得することができなかった最初のデータとする。
【０１１４】
続いて、ステップＳ６１００において、決済処理部２２０は、現在決済センター１からのデータ取得をリトライしようとしているデータの送受信が未完了であるか否かを確認する。これは、例えば、取得しようとしているデータが、決済ログであれば接触カード決済ログ記憶部２４０や非接触ＩＣカード決済ログ記憶部３４０を、ネガデータであればネガデータ記憶部３６０を、設定データであれば設定データ記憶部２３０や非接触カード設定データ記憶部３３０を、更新プログラムであれば決済処理部用プログラム記憶部を確認し、データの送受信が未完了であるデータが存在する場合は、ステップＳ６２００に進む。また、データの送受信が未完了でない、すなわち、データの送受信が完了している場合は、ステップＳ６６００に進む。
【０１１５】
続いて、ステップＳ６２００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成される空車時リトライ実施判定テーブルから、現在決済センター１からのデータ取得をリトライしようとしているデータに対応したリトライ処理を行うか否かの情報を取り出す。そして、現在データ取得をリトライしようとしているデータが、空車時のリトライ処理が必要なデータであるか否かを確認する。空車時のリトライ処理が必要なデータである場合は、ステップＳ６３００に進んで、データ取得のリトライ処理を行う。また、空車時のリトライ処理が必要なデータでない場合は、ステップＳ６６００に進む。
【０１１６】
なお、空車時リトライ実施判定テーブルは、図９に示すようにデータの種別に対応してリトライを実施するか否かの情報が記憶されたテーブルデータである。この空車時リトライ実施判定テーブルによって、現在決済センター１からのデータ取得をリトライしようとしているデータ種別毎に、空車時のリトライ処理を行うか否かを確認することができる。なお、この空車時リトライ実施判定テーブルに記録する、リトライ処理を行うか否かの情報を記録する際は、決済処理において必須となるデータやデータサイズが小さいデータなどを、リトライ処理を行うデータであるとして記録すると効率がよいと考えられる。例えば、決済センター１から取得するネガデータまたは設定データや、決済センター１に送信する決済ログのデータは、空車時のリトライ処理を行うデータとする。また、例えば、決済センター１から取得する更新プログラムは、空車時のリトライ処理を行わないデータとすることによって、より確実に決済処理が行えるようになる。
【０１１７】
続いて、ステップＳ６４００において、決済処理部２２０は、データのリトライ処理が成功したか、すなわち、正常にデータを取得することができたか否かを確認し、データの受信処理が成功した場合は、ステップＳ６５００において、リトライ処理が成功したデータのリトライステータスを「リトライ不要」とする。また、データの受信処理が成功しなかった場合は、ステップＳ６６００に進む。
【０１１８】
続いて、ステップＳ６６００において、決済処理部２２０は、決済センター１からのデータ取得をリトライしようとしているデータを、今回データ取得をリトライした次のデータとする。なお、このステップＳ６６００の処理は、今回データ取得をリトライしたデータの受信処理が成功したか否かに係わらず、次のデータ取得をリトライする。
【０１１９】
続いて、ステップＳ６７００において、決済処理部２２０は、次に決済センター１からのデータ取得をリトライしようとしているデータがあるか否かを確認し、次にリトライするデータがある場合は、ステップＳ６１００に戻って、データ取得をリトライするための処理を繰り返す。また、次にリトライするデータがない場合は、処理を完了する。
【０１２０】
上述のように、決済センター１からの取得をリトライしようとしているデータを正常に取得することができた場合は、リトライステータスを「リトライ不要」とする。また、タクシーメーター装置３から空車通知が通知されるたびに、正常に取得することができなかったデータ取得のリトライ処理を繰り返す。また、空車通知が通知されるたびに繰り返されるリトライ処理では、データの種別毎に、空車時のリトライ処理を行うか否かが決定されるため、例えば、重要性の低いデータのリトライを繰り返すことによる通信処理の増大を抑えることによって、通信料金の増大を抑えることができる。
【０１２１】
また、空車通知が通知されるたびに繰り返されるリトライ処理は、リトライ回数保存領域に記憶されているリトライ回数が、最大リトライ回数保存領域に記憶されている最大リトライ回数以上となっている場合でも、空車時リトライ実施判定テーブルに記憶されているデータに基づいて行われる。例えば、ネガデータのデータサイズが「５００ＫＢ超」であり、決済端末システム１０が決済センター１からのネガデータの取得が失敗している場合を考える。このとき、図５に示したリトライ回数決定テーブルでは、リトライ回数が「０回」となっているため、リトライ処理を行わない設定である。しかし、空車時リトライ実施判定テーブルには、ネガデータは空車時のリトライ処理を行うデータであることが記憶されているため、空車時のリトライ処理は実施されることとなる。
【０１２２】
また、空車時リトライ実施判定テーブルは、図３に示した起動時の送受信処理のステップＳ３００において、起動時のリトライ処理を行う設定がされているか否かの確認において使用されるテーブルとすることもできる。これにより、起動時および空車時のデータ受信処理において取得することができなかったネガデータの取得を行うようにすることができる。例えば、タクシー決済端末においては、図３に示した起動時の送受信処理は、当日のタクシーの始業および終業時のみではなく、タクシーの運転手が休憩を取るなどによってタクシーの営業を一時中断していた状態から、タクシーの営業を再開するときにも実施される。このような営業再開のときに、図３に示した起動時の送受信処理のステップＳ３００が実行されることによって、起動時の送受信処理が再度実行される。
【０１２３】
なお、上述の説明では、データを取得する例について説明したが、決済センター１へのデータの送信をリトライする場合も同様に考えることができる。
【０１２４】
また、本実施形態の決済端末システム１０がタクシーに搭載されたタクシー決済端末である例について説明したが、タクシーメーター装置３から取得するタクシー運転情報と同様な情報を取得することによって、タクシー決済端末以外にも適用することができる。例えば、タクシー運転情報における空車通知に代わって、休止状態を通知することができるレジスターなどに適用し、休止状態が通知されたときに図９に示した空車時のリトライ処理と同様のリトライ処理を実行することもできる。
【０１２５】
なお、図９に示した空車時のリトライ処理において、データの送受信中に客がタクシーに乗車したことによって、賃走通知または実車通知がタクシーメーター装置３から通知されたときには、データの送受信処理を中止または中断することもできる。また、この場合でもデータの送受信処理を中止または中断せず、客が支払いを行ってタクシーから下車しようとすることによって通知される支払通知がタクシーメーター装置３から通知されたときに、データの送受信処理を中止または中断することもできる。これにより、タクシーの乗車料金の精算時に、例えば、接触型決済カード４による決済処理時に必要な決済センター１との通信時間を確保し、データの送受信処理以外の他の通信処理に影響をおよぼさないようにすることができる。なお、データの送受信処理を中止または中断した場合であっても、以降の空車時のリトライ処理によって、送受信処理を中止または中断したデータのリトライ処理は再開される。
【０１２６】
なお、上記の説明において、空車時リトライ実施判定テーブルは、決済端末２００内で異なるメモリで構成されている例で説明したが、空車時リトライ実施判定テーブルを、データサイズ保存領域、リトライ回数決定テーブル、最大リトライ回数保存領域、リトライ回数保存領域、およびリトライ時間決定テーブルを記憶しているメモリと同一のメモリとし、メモリ内の記憶領域をそれぞれ分けることによって構成することもできる。また、例えば、決済端末２００内の設定データ記憶部（設定データ記憶部２３０、非接触カード設定データ記憶部３３０）や、プログラム記憶部（決済処理部用プログラム記憶部、非接触ＩＣカード決済処理部用プログラム記憶部）と同一のメモリとすることもできる。この場合、決済センター１からデータを取得することによって、その内容を変更することもできる。
【０１２７】
次に、本発明の実施形態の決済端末システムにおける締めまたは集計の処理手順について説明する。図１０は、本実施形態の決済端末システム１０の締めまたは集計時の処理手順を示したフローチャートである。以下に説明する締めまたは集計処理は、例えば、タクシーメーター装置３から取得したタクシー運転情報によって、タクシーが終業することを表す入庫通知が通知されたとき（締め処理）、またはタクシー営業における途中集計を指示する通知がなされたとき（集計処理）に行われる処理である。なお、以下の説明においては、タクシーが終業することを表す入庫通知が通知されたときの締め処理を例にとって説明する。
【０１２８】
タクシーメーター装置３から入庫通知が通知されると、まず、ステップＳ７０００において、決済処理部２２０は、本日行われた決済センター１との通信によって送受信処理が完了していないデータがあるか否かを確認する。送受信処理が完了していないデータがない場合は、処理を完了する。また、送受信処理が完了していないデータがある場合は、ステップＳ７１００において、決済処理部２２０は、タクシー運転手に送受信処理が完了していないデータの通信指示の操作を促す表示を行う。
【０１２９】
続いて、ステップＳ７２００において、決済処理部２２０は、タクシー運転手から通信を実施する指示の選択がされたか否かを確認し、通信を実施する指示の選択がされていない場合は、ステップＳ７０００に戻って、再度送受信処理が完了していないデータがあるか否かの確認を繰り返す。また、通信を実施する指示の選択がされた場合は、ステップＳ７３００において、決済処理部２２０は、送受信処理が完了していないデータの送受信処理を行う。
【０１３０】
上述のように、決済センター１から取得または決済センター１に送信によってデータを正常に取得または送信することができた場合に締めまたは集計処理を完了する。また、タクシー運転手によってデータの送受信処理が不要と判断されたデータのみ、決済センター１との通信を行わないようにすることができる。このように、送受信処理が必要なデータのみを決済センター１との通信処理することによって、例えば、重要性の高いデータは確実に送受信処理を行うことができる。また、例えば、重要性の低いデータの送受信処理を行わないことによって、通信料金の増大を抑えることができる。
【０１３１】
なお、上記の説明では、送受信処理が完了していないデータがある場合に、タクシー運転手からの指示に基づいて送受信処理を行う例で説明したが、タクシー運転手の判断によらず送受信処理が必須であるデータの送受信処理が完了していない場合は、データの通信指示の操作を促す表示を行わずに自動で送受信処理を行うようにすることもできる。
【０１３２】
また、本実施形態の決済端末システム１０が、タクシーに搭載されたタクシー決済端末である例について説明したが、タクシーメーター装置３から取得するタクシー運転情報と同様な情報を取得することによって、タクシー決済端末以外にも適用することができる。例えば、タクシー運転情報における入庫通知および途中集計を指示する通知に代わって、締めまたは集計の状態を通知することができるレジスターなどに適用し、締めまたは集計の状態が通知されたときに図１０に示した締めまたは集計処理を実行することもできる。
【０１３３】
次に、本発明の実施形態の決済端末システムにおける決済処理の処理手順について説明する。図１１は、本実施形態の決済端末システム１０における決済開始時の処理手順を示したフローチャートである。以下に説明する決済開始処理は、特定の決済処理が指示された場合に行われる処理である。なお、以下の説明においては、特定の決済処理として、非接触型ＩＣ決済カード５による決済処理が指示されたときの処理手順を例にとって説明する。
【０１３４】
例えば、タクシー運転手による決済端末システム１０の操作によって非接触型ＩＣ決済カード５による決済処理が指示されると、まず、ステップＳ８０００において、決済処理部２２０は、最新のネガデータを取得済みであるか否かを確認する。最新のネガデータを取得済みである場合は、ステップＳ８２００に進む。また、最新のネガデータを取得済みでない、すなわち、ネガデータが古く、決済を行う時点で使用不可能である非接触型ＩＣ決済カード５による決済処理を行ってしまうという可能性がある場合は、ステップＳ８１００に進む。
【０１３５】
続いて、ステップＳ８１００において、決済処理部２２０は、例えば、ＲＡＭやＦｌａｓｈＲＯＭなどの書き込み可能なメモリによって構成される最新ネガデータ無し決済可否設定領域から、現在決済を行おうとしている非接触型ＩＣ決済カード５に対応した決済可否の設定情報を取り出す。そして、現在決済を行おうとしている非接触型ＩＣ決済カード５が、最新のネガデータ無しの状態での決済処理が可能であるか否かを確認する。最新のネガデータ無しの状態での決済処理が可能である場合は、ステップＳ８２００において、決済処理を実施する。
【０１３６】
また、最新のネガデータ無しの状態での決済処理が可能でない場合は、別の決済方法の選択を促す表示や、決済処理が不可能であるため現金による精算を促す表示を行って、処理を完了する。
【０１３７】
上述のように、決済センター１から最新のネガデータを取得済みであるか否かを確認し、さらに、最新のネガデータ無しの状態での決済処理が可能であるか否かを確認することによって、非接触型ＩＣ決済カード５による決済処理を確実に行うことができる。これにより、決済を行う時点で使用不可能である非接触型ＩＣ決済カード５による決済処理を行ってしまうというリスクを回避することができる。
【０１３８】
なお、上記の説明では、最新のネガデータ無しの状態での決済処理が可能でない場合には決済処理を行わない例で説明したが、例えば、接触型決済カード４による決済処理と同様に、読み取った非接触型ＩＣ決済カード５のカード情報を決済センター１に送信し、決済センター１による最新のネガデータとの照合結果に基づいて決済処理を行えるようにすることもできる。
また、最新のネガデータ無しの状態での決済処理が可能であるか否かは、当日のネガデータ（最新のネガデータ）から、何日間か前のネガデータが無くても決済処理が可能であると判定させるようにすることもできる。これにより、例えば、予め定められた日数以内のネガデータを取得済みである場合には、決済処理を行うことができる。
【０１３９】
なお、上述の説明では、非接触型ＩＣ決済カード５による決済処理の例について説明したが、その他、自決済端末２００に記憶したネガデータに基づいて決済処理を行う場合も同様に考えることができる。
【０１４０】
なお、上記の説明において、最新ネガデータ無し決済可否設定領域は、決済端末２００内で異なるメモリで構成されている例で説明したが、最新ネガデータ無し決済可否設定領域を、データサイズ保存領域、リトライ回数決定テーブル、最大リトライ回数保存領域、リトライ回数保存領域、リトライ時間決定テーブル、および空車時リトライ実施判定テーブルを記憶しているメモリと同一のメモリとし、メモリ内の記憶領域をそれぞれ分けることによって構成することもできる。また、例えば、決済端末２００内の設定データ記憶部（設定データ記憶部２３０、非接触カード設定データ記憶部３３０）や、プログラム記憶部（決済処理部用プログラム記憶部、非接触ＩＣカード決済処理部用プログラム記憶部）と同一のメモリとすることもできる。この場合、決済センター１からデータを取得することによって、その内容を変更することもできる。
【０１４１】
上記に述べたとおり、本発明では、送受信処理が失敗したデータのデータサイズ（伝送データサイズ）と、リトライ回数（送受信回数）とに基づいて、次にリトライを行うか否かの判断をすることによって、必要なデータのみをリトライすることができる。また、送受信をリトライするデータにおいても、リトライする間隔を制御することができる。例えば、データサイズが小さいデータは、予め定めた一定のリトライ回数のリトライ処理を行い、データサイズが大きいデータは、予め定めた一定のリトライ回数よりもリトライ回数を少なくすることや、リトライ処理を中止または中断することができる。
これにより、特定のデータのリトライ処理の繰り返しによる通信処理の占有と、通信料金の増大を抑えることができる。
【０１４２】
また、例えば、従来の決済端末では、データの送受信が失敗したことをユーザに通知し、この通知を受けたユーザが決済端末を操作してリトライを指示することによってリトライ処理を行うというものがある。このような決済端末では、自動的にリトライを行わないため、必要なデータの送受信が行われない可能性が高いという問題がある。より具体的には、ネガデータの取得が失敗した場合には、決済を行う時点で使用不可能である非接触型ＩＣ決済カードによる決済処理を行ってしまうというリスクが高まる。また、決済ログの送信が失敗した場合には、入金がされなかったり遅れたりする可能性が高くなる。また、更新プログラムの取得が失敗した場合には、決済端末が正しく動作しないなどのリスクが高まる。
本発明では、リトライ回数決定テーブル、リトライ時間決定テーブル、空車時リトライ実施判定テーブルなどのリトライ処理を行うための設定を、決済端末システム１０を使用するユーザ、またはユーザの使用環境に合わせて変更することができるため、必要なデータの送受信処理を自動で確実に行うことができ、従来の決済端末におけるリスクを軽減することができる。また、リトライ処理を行うための設定を、決済センター１から取得またはユーザによって変更することができるため、決済端末システム１０を使用するユーザの使用環境に合わせてより適切な値に設定することができる。
【０１４３】
また、リトライ処理を中止または中断することもできるため、他の通信処理が必要とする通信時間を確保することができるため、他の通信処理に影響をおよぼさないようにすることができる。例えば、データ量が大量であることが予想され、数日間更新されなくても決済処理を行う上では問題がないデータであれば、決済端末システム１０の当日最初の起動時における送受信処理でデータの送受信が失敗した場合でも、その後繰り返されるリトライ処理を中止する。そして、当日の締め処理のときなどに、データの通信指示の操作を促す表示を行うことによって、決済処理で行う通信処理に影響しない状況で送受信処理をリトライすることによって、翌日に行われるデータの送受信処理を完了させることができる。また、当日に送受信処理が完了しなかった場合でも、翌日の最初の起動時に送受信処理を行うことができる。
【０１４４】
また、当日最初の起動時における送受信処理でデータの送受信が失敗したデータに対して行われるリトライ処理の回数が、設定した最大リトライ回数以上である場合でも、図９に示した空車時のリトライ処理のように、データの種別毎にリトライを行うことができるので、決済処理のリスクを軽減することができる。また、図１１に示した決済開始処理のように、別の決済方法での決済処理を促すことによっても、決済処理のリスクを軽減することができる。
【０１４５】
なお、本実施形態においては、決済処理部２２０がデータの送受信処理の制御を行う例で説明したが、データの送受信処理の制御は、非接触ＩＣカード決済処理部３２０が行う構成とすることもできる。また、決済処理部２２０および非接触ＩＣカード決済処理部３２０がそれぞれ対応する決済処理に関するデータの送受信処理の制御を行う構成とすることもできる。例えば、非接触型ＩＣ決済カード５による決済処理を行う際に必要なネガデータを取得する場合を考える。このとき、非接触ＩＣカード決済処理部３２０がネガデータの取得要求を決済処理部２２０に出力し、決済処理部２２０がネガデータを取得するための通信処理のみを行う。そして、決済処理部２２０は、受信したネガデータの電文をそのまま非接触ＩＣカード決済処理部３２０に転送する。非接触ＩＣカード決済処理部３２０は、転送されてきた電文によってネガデータが正常に取得できたか否かを判断し、リトライが必要な場合は、決済処理部２２０にリトライ要求を出力する。リトライ要求が入力された決済処理部２２０は、ネガデータのリトライ処理のための通信処理のみを行い、受信したネガデータのリトライ処理の電文をそのまま非接触ＩＣカード決済処理部３２０に転送するという構成とすることができる。
【０１４６】
なお、上記のように、データの送受信処理の制御を非接触ＩＣカード決済処理部３２０または決済処理部２２０と非接触ＩＣカード決済処理部３２０とが共同して行う構成とした場合、本実施形態において説明したデータサイズ保存領域、リトライ回数決定テーブル、最大リトライ回数保存領域、リトライ回数保存領域、リトライ時間決定テーブル、空車時リトライ実施判定テーブル、および最新ネガデータ無し決済可否設定領域は、決済処理部２２０および非接触ＩＣカード決済処理部３２０にそれぞれ接続された異なるメモリで構成することもできる。また、決済処理部２２０および非接触ＩＣカード決済処理部３２０にそれぞれ接続された異なるメモリは、決済処理部２２０に接続されている設定データ記憶部２３０および非接触ＩＣカード決済処理部３２０に接続されている非接触カード設定データ記憶部３３０と同一のメモリとすることもできる。また、決済処理部２２０および非接触ＩＣカード決済処理部３２０にそれぞれ接続された異なるメモリは、決済処理部２２０に接続されている決済処理部用プログラム記憶部および非接触ＩＣカード決済処理部３２０に接続されている非接触ＩＣカード決済処理部用プログラム記憶部と同一のメモリとすることもできる。
【０１４７】
以上、本発明の実施形態について、図面を参照して説明してきたが、具体的な構成はこの実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲においての種々の変更も含まれる。
【符号の説明】
【０１４８】
１・・・決済センター
２・・・移動体通信網
３・・・タクシーメーター装置
４・・・接触型決済カード
５・・・非接触型ＩＣ決済カード
１０，２０・・・決済端末システム
１００・・・移動体通信モジュール
２００・・・決済端末
２１０・・・センターＩ／Ｆ（インタフェース）部
２２０・・・決済処理部
２２１・・・リトライ処理部
２３０・・・設定データ記憶部
２４０・・・接触カード決済ログ記憶部
２５０・・・接触カードＩ／Ｆ（インタフェース）部
２６０・・・リーダライターＩ／Ｆ部
２７０・・・メーターＩ／Ｆ（インタフェース）部
３００・・・非接触ＩＣカードリーダライター
３１０・・・決済端末Ｉ／Ｆ部
３２０・・・非接触ＩＣカード決済処理部
３２１・・・非接触ＩＣリトライ処理部
３３０・・・非接触カード設定データ記憶部
３４０・・・非接触ＩＣカード決済ログ記憶部
３５０・・・非接触ＩＣカードＩ／Ｆ（インタフェース）部
３６０・・・ネガデータ記憶部
【図１】
0005457139.tif 000002
【図２】
0005457139.tif 000003
【図３】
0005457139.tif 000004
【図４】
0005457139.tif 000005
【図５】
0005457139.tif 000006
【図６】
0005457139.tif 000007
【図７】
0005457139.tif 000008
【図８】
0005457139.tif 000009
【図９】
0005457139.tif 000010
【図１０】
0005457139.tif 000011
【図１１】
0005457139.tif 000012