JP6318898B2 - 決済システム - Google Patents

Description

本明細書で開示する技術は、電子マネー決済を実行するための決済システムに関する。

特許文献１には、ＩＣカードを用いて決済を行うための決済システムが開示されている。特許文献１の決済システムは、ＩＣカードとの間で決済を行うための改札機と、改札機と通信可能に接続され、ＩＣカードに関する各種情報（ＩＣカード識別情報、ユーザ情報、プリペイド残高情報、等）を管理するサーバとを備える。

特開２００５−１６５７９７号公報

特許文献１の決済システムでは、ＩＣカードと改札機との間で決済が行われる際に、ＩＣカードと改札機の間の通信状態が悪化する等して、ＩＣカードに正しい決済結果（例えば、正確なプリペイド残高）が記憶されない決済エラーが発生する場合がある。特許文献１の決済システムでは、このような決済エラーが発生した場合、ＩＣカードのユーザが、係員に決済エラーが発生したことを知らせ、係員による修正処理を受ける必要がある。しかしながら、ＩＣカードのユーザが、決済実行時に決済エラーが発生したことを認識することができない場合がある。その場合、ユーザは、自身のＩＣカードに発生した決済エラーを修正する機会を得られないまま、不正確な決済結果（例えば、不正確なプリペイド残高）が記憶されたままのＩＣカードを継続して使用することになり、不利益を被る可能性がある。

本明細書では、決済媒体について発生した決済エラーを適切に修正することができる技術を提供する。

本明細書が開示する決済システムは、決済媒体との間で決済を行うための決済端末と、決済端末と通信可能に接続され、決済端末で実行された決済に関する決済実績情報を管理するサーバと、を備える。決済端末は、決済媒体を検出可能であると共に決済媒体と通信可能な通信インターフェースを有しており、検出された決済媒体との間で通信インターフェースを介して決済を実行し、実行された決済に関する決済実績情報をサーバに送信する。サーバは、決済端末から決済実績情報を受信して記憶し、記憶した決済実績情報に１以上の決済エラーが含まれる場合は、それら１以上の決済エラーのそれぞれについて、当該決済エラーが発生した決済媒体を示す識別情報と、当該決済エラーが発生した決済の正しい決済結果に関係する修正情報と、が対応付けられたエラー修正テーブルを生成し、生成されたエラー修正テーブルを決済端末に送信する。決済端末は、サーバからエラー修正テーブルを受信して記憶し、記憶したエラー修正テーブルに含まれる１以上の識別情報のうちのいずれかと一致する識別情報を有する決済媒体が検出される場合に、エラー修正テーブルにおいて当該識別情報に対応付けられている修正情報に基づいて、当該決済媒体の記憶内容を修正する。

上記の決済システムでは、決済端末は、サーバから送信されたエラー修正テーブルに含まれる１以上の識別情報のいずれかと一致する識別情報を有する決済媒体が検出される場合に、エラー修正テーブルにおいて当該識別情報に対応付けられている修正情報に基づいて、当該決済媒体の記憶内容を修正する。そのため、上記の決済システムでは、決済媒体のユーザが、決済実行時に決済エラーが発生したことを認識できなかった場合においても、以後の決済の際に、当該決済エラーを解消することができる。従って、上記の決済システムによると、決済媒体について発生した決済エラーを適切に修正することができる。

決済システムの構成を模式的に示す図。 決済実績情報群の例を示す図。 エラー修正テーブルの例を示す図。 第１実施例のサーバの制御部が実行するサーバ処理を示すフローチャート。 第１実施例の決済端末の制御部が実行する端末処理を示すフローチャート。 第１実施例の決済システムが実行する処理の例を示すシーケンスチャート。 第２実施例のサーバの制御部が実行するサーバ処理を示すフローチャート。 第２実施例の決済端末の制御部が実行する端末処理を示すフローチャート。 第２実施例の決済システムが実行する処理の例を示すシーケンスチャート。

以下に説明する実施例の主要な特徴を列記しておく。なお、以下に示す技術要素は、それぞれ独立した技術要素であって、単独であるいは各種の組み合わせによって技術的有用性を発揮するものであり、出願時請求項記載の組み合わせに限定されるものではない。

（特徴１）サーバは、ユーザが指示を入力するための入力手段をさらに備えてもよい。サーバは、ユーザが入力手段を介して入力する指示に従って、記憶された決済実績情報に基づいてエラー修正テーブルを生成してもよい。

この構成によると、ユーザの指示に従って決済エラーを修正することが可能となる。サーバに記憶された決済実績情報からは自動的に検出されない態様の決済エラーを修正することも可能となるため、決済媒体について発生した決済エラーをより適切に修正することができる。

（特徴２）決済システムは、複数個の決済端末を備えてもよい。複数個の決済端末のそれぞれは、サーバと通信可能に接続されていてもよい。サーバは、生成されたエラー修正テーブルを記憶すると共に複数個の決済端末のそれぞれに送信してもよい。複数個の決済端末のうちのいずれかが、エラー修正テーブルに含まれる識別情報と一致する識別情報を有する決済媒体を検出し、その決済媒体の記憶内容を修正した場合に、当該決済端末は、エラー修正テーブルから、記憶内容が修正された決済媒体に関する識別情報及び修正情報を削除すると共に、当該識別情報及び修正情報に対応する決済エラーの修正が完了したことを示す完了情報をサーバに送信してもよい。サーバは、決済端末から完了情報を受信すると、当該完了情報に関する識別情報及び修正情報をエラー修正テーブルから削除すると共に、当該完了情報を、当該完了情報をサーバに送信した決済端末以外の複数個の決済端末のそれぞれに送信してもよい。サーバから完了情報を受信した複数個の決済端末のそれぞれは、当該完了情報に関する識別情報及び修正情報をエラー修正テーブルから削除してもよい。

この構成によると、複数個の決済端末のうちのいずれにおいても、決済媒体について発生した決済エラーを修正することができる。また、特定の決済端末で決済エラーが修正された場合に、特定の決済端末、サーバ、及び、特定の決済端末以外の複数個の決済端末のそれぞれにおけるエラー修正テーブルから、修正された決済エラーに関する識別情報及び修正情報が削除される。そのため、決済エラーの修正が重複して行われることも防止することができる。

（特徴３）決済システムは、複数個の決済端末を備えていてもよい。複数個の決済端末のそれぞれは、サーバと通信可能に接続されていてもよい。サーバは、生成されたエラー修正テーブルと、特定の決済端末にのみ特定の決済媒体に関する決済エラーの修正を許可することを示す許可情報と、を複数個の決済端末のそれぞれに送信してもよい。特定の決済端末は、特定の決済媒体を検出すると、特定の決済媒体の記憶内容を修正してもよい。特定の決済端末以外の複数個の決済端末のそれぞれは、特定の決済媒体を検出しても、特定の決済媒体の記憶内容を修正しなくてもよい。

決済システムにおいて、各決済端末とサーバとが、決済実績情報の通信を常時実行しない構成が採用される場合がある。そのような場合でも、この構成を採用することで、決済エラーの修正が重複して行われることを防止するとともに、適切に決済エラーを修正することができる。

（特徴４）特定の決済端末以外の複数個の決済端末のそれぞれは、特定の決済媒体が検出される場合に、特定の決済端末で決済エラーの修正が可能であることを特定の決済媒体のユーザに報知するための報知動作を行ってもよい。

この構成によると、特定の決済端末で決済エラーの修正が可能であることを決済媒体のユーザに知らせることができる。

（第１実施例）
（システムの概要；図１）
図１に示す決済システム２は、決済端末１０、３０と、サーバ５０と、決済媒体１００、２００とを備える。決済システム２は、例えば、商店内で利用されるシステムであって、商品の販売に伴う決済を行うシステムである。決済システム２を用いて決済を行う場合、まず、商店の店員が決済端末１０を操作し、顧客が購入を希望する商品の名称や、顧客が購入を希望する商品の金額（即ち、決済金額）等、決済に必要な決済情報を入力する。決済端末１０への決済情報の入力は、決済端末１０に接続されているＰＯＳ端末（図示省略）を介して行われてもよい。決済端末１０は、入力された決済情報を記憶する。その後、顧客が、自身が所有する決済媒体１００を決済端末１０に近づけると、決済端末１０とその決済媒体１００との間で通信が行われ、必要な決済が行われる。決済端末１０は、所定のタイミングで、決済端末１０で行われた決済の内容（例えば、決済媒体ＩＤ、決済番号、決済時刻、商品名、商品の定価、決済前残高、決済後残高等）を示す決済実績情報をサーバ５０に送信する。サーバ５０は、決済実績情報を記憶する。

（決済端末１０、３０）
決済端末１０は、操作部１２と、表示部１４と、有線インターフェース１６と、ＮＦＣ（Near Field Communicationの略）インターフェース１７と、制御部１８と、メモリ２０とを備える。以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。

操作部１２は、複数のキーを備える。決済端末１０のユーザ（例えば、店員、顧客等）は、操作部１２を操作することによって、様々な指示を決済端末１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。

有線Ｉ／Ｆ１６は、サーバ５０と有線通信を行うためのインターフェースである。決済端末１０は、有線Ｉ／Ｆ１６を介して、サーバ５０と有線通信可能に接続されている。

ＮＦＣＩ／Ｆ１７は、決済媒体１００、２００と近距離無線通信を実行するためのインターフェースである。ＮＦＣＩ／Ｆ１７は、決済媒体１００、２００を検出可能であると共に決済媒体１００、２００と通信可能である。

制御部１８は、メモリ２０内のプログラム２１に従って、様々な処理を実行する。制御部１８が実行する処理の内容は後で詳しく説明する。

メモリ２０は、プログラム２１と、エラー修正テーブル７０とを記憶している。エラー修正テーブル７０は、サーバ５０から供給されるテーブルであって、決済エラーが発生した決済媒体のＩＤ、当該決済エラーが発生した決済を正しい決済結果に修正するための修正情報等が対応付けられているテーブルである。エラー修正テーブル７０の詳しい内容は後で説明する（図３参照）。また、メモリ２０は、決済端末１０で行われた決済の内容（例えば、決済媒体ＩＤ、決済番号、決済時刻、商品名、商品の定価、決済前残高、決済後残高等）を示す決済実績情報、決済エラーの修正が完了したことを示す完了情報等の各種情報を一時的に記憶するための記憶領域も有している。なお、図１では、メモリ２０内に許可情報８０がさらに図示されているが、許可情報８０は、後述の第２実施例で利用される。

決済端末３０は、決済端末１０と同様の構成を有する。即ち、決済端末３０も、操作部３２と、表示部３４と、有線Ｉ／Ｆ３６と、ＮＦＣＩ／Ｆ３７と、制御部３８と、メモリ４０とを備える。メモリ４０は、プログラム４１と、エラー修正テーブル７０とを記憶している。プログラム４１及びエラー修正テーブル７０は、決済端末１０のメモリ２０に記憶されているものと同じである。

（サーバ５０）
サーバ５０は、各決済端末１０、３０から決済実績情報を収集し、収集した決済実績情報を管理するためのサーバである。サーバ５０は、操作部５２と、表示部５４と、有線Ｉ／Ｆ５６と、制御部５８と、メモリ６０とを備える。

操作部５２は、キーボード及びマウスを備える。表示部５４は、様々な情報を表示するためのディスプレイである。有線Ｉ／Ｆ５６は、決済端末１０、３０と有線通信を行うためのインターフェースである。制御部５８は、メモリ６０内のプログラム６１に従って様々な処理を実行する。制御部５８が実行する処理の内容は後で詳しく説明する。

メモリ６０は、プログラム６１と、決済実績情報群６４と、エラー修正テーブル７０と、を記憶している。決済実績情報群６４は、決済端末１０、３０から取得した決済実績情報を含む。即ち、決済実績情報群６４には、決済端末１０、３０で行われたすべての決済の内容を示す決済実績情報が含まれる。決済実績情報群６４の詳しい内容は後で説明する（図２参照）。エラー修正テーブル７０は、決済端末１０、３０のメモリ２０、４０に記憶されているものと同じである。

（決済媒体１００、２００）
決済媒体１００は、例えば、顧客が所持するＩＤカード、携帯電話端末等、決済端末１０、３０と近距離無線通信を実行可能な媒体である。決済媒体１００は、図示しないＩＣチップを内蔵している。ＩＣチップには、決済媒体１００のＩＤ、電子マネーの残高を示す残高情報などを含む媒体情報が記憶されている。本実施例の決済媒体１００には、ＩＤ「Ｃ１」が割り当てられている。

決済媒体２００も、決済媒体１００と同様の構成を有している。決済媒体２００には、ＩＤ「Ｃ２」が割り当てられている。なお、図１では、２つの決済媒体１００、２００のみを図示しているが、決済システム２は、決済媒体１００、２００以外の１以上の他の決済媒体を有している。

（決済実績情報群；図２）
図２を参照して決済実績情報群６４の内容を説明する。上記の通り、決済実績情報群６４には、決済端末１０、３０から取得した複数個の決済実績情報５００、５１０、５２０が含まれる。図２に示す通り、各決済実績情報には、決済媒体ＩＤ、決済番号、決済時刻、商品名、定価、決済前残高、決済後残高、の各情報が対応付けられている。決済媒体ＩＤは、決済媒体のＩＤ（例えば、決済媒体１００のＩＤ「Ｃ１」等）を示す。決済番号は、決済エラーが発生した決済を識別するためのユニークな番号である。決済時刻は、当該決済が行われた時刻を示す。商品名は、当該決済において顧客が購入を希望した商品の名称を示す。定価は、商品名が示す商品の価格を示す。決済前残高は、当該決済が行われる前における決済媒体ＩＤが示す決済媒体に記憶されている電子マネー残高を示す。決済後残高は、当該決済が行われた後における決済媒体ＩＤが示す決済媒体に記憶されている電子マネー残高を示す。

例えば、決済実績情報５００は、決済媒体ＩＤ「Ｃ１」、決済番号「０００１」、決済時刻「１０：１０」、商品名「ＸＸＸＸ」、定価「３５０」、決済前残高「１５００」、決済後残高「１０５０」の各情報を含む。即ち、決済実績情報５００は、決済媒体ＩＤ「Ｃ１」の決済媒体１００との間で行われた決済番号「０００１」の決済において、１０時１０分に、定価３５０円の商品「ＸＸＸＸ」の決済が行われたこと、及び、決済媒体１００の決済前残高が１５００円であり、決済後残高が１０５０円になったことを意味する。決済実績情報５００から明らかな通り、決済前残高が１５００円である場合に、定価３５０円の商品の決済を行った後の決済後残高は本来１１５０円であるべきである。即ち、この決済では、１００円分の過減額が行われている。従って、サーバ５０の制御部５８は、後で説明するサーバ処理（図４参照）において、決済実績情報５００が示す決済について決済エラー（過減額）が発生していると判断するとともに、決済媒体１００に１００円返金すべき旨の修正情報を含むエラー修正テーブル７０を作成する。なお、過減額が行われた後の決済媒体１００は、その後、過減額が修正されるまでの間に、別の決済を行うこともできる。

また、決済実績情報５１０は、決済媒体ＩＤ「Ｃ３」、決済番号「０００５」、決済時刻「１２：１０」、商品名「ＹＹＹＹ」、定価「４００」、決済前残高「２０００」、決済後残高「１６００」の各情報を含む。即ち、決済実績情報５００は、決済媒体ＩＤ「Ｃ３」の決済媒体（図示しない）との間で行われた決済番号「０００５」の決済において、１２時１０分に、定価４００円の商品「ＹＹＹＹ」の決済が行われたこと、及び、当該決済媒体の決済前残高が２０００円であり、決済後残高が１６００円になったことを意味する。決済実績情報５１０では、決済前残高が２０００円である場合に、決済定価４００円の商品の決済を行った後の決済後残高が１６００円であるため、正しい決済が行われている。そのため、制御部５８は、後で説明するサーバ処理において、決済実績情報５１０が示す決済について決済エラーが発生していないと判断する。

また、決済実績情報５２０は、決済媒体ＩＤ「Ｃ２」、決済番号「５００１」、決済時刻「１５：１５」、商品名「ＺＺＺＺ」、定価「５００」、決済前残高「２０００」、決済後残高「ＡＸＢＹＺＣ」の各情報を含む。即ち、決済実績情報５００は、決済媒体ＩＤ「Ｃ２」の決済媒体２００との間で行われた決済番号「５００１」の決済において、１５時１５分に、定価５００円の商品「ＺＺＺＺ」の決済が行われたこと、及び、決済媒体１００の決済前残高が２０００円であり、決済後残高が正しく書き込まれず（本来は金額を示す数字が書き込まれる）、データが破損したことを意味する。決済後残高のデータが破損する原因は、例えば、決済実行中の通信環境が悪化すること等が考えられる。なお、残高のデータが破損している決済媒体２００は、その後、データ破損が修正されるまでの間に別の決済を行うことはできない。決済実績情報５２０から明らかな通り、決済前残高が２０００円である場合に、定価５００円の商品の決済を行った後の決済後残高は本来１５００円であるべきであるが、決済実績情報５２０では、決済後残高のデータが破損している。従って、サーバ５０の制御部５８は、後で説明するサーバ処理（図４参照）において、決済実績情報５２０が示す決済について決済エラー（データ破損）が発生していると判断するとともに、決済媒体２００の残高を１５００円に戻すべき旨の修正情報を含むエラー修正テーブル７０を作成する。

（エラー修正テーブル７０；図３）
図３を参照してエラー修正テーブル７０の内容を説明する。エラー修正テーブル７０は、サーバ５０のメモリ６０に記憶されている決済実績情報群６４の中に１以上の決済エラーが含まれる場合に、制御部５８によって生成されるテーブルである。エラー修正テーブル７０は、決済媒体ＩＤ、決済番号、エラー内容、修正情報、の各情報が対応付けられた組み合わせ情報３００、３１０等を含む。決済媒体ＩＤは、決済媒体のＩＤ（例えば、決済媒体１００のＩＤ「Ｃ１」等）を示す。決済番号は、決済エラーが発生した決済を識別するためのユニークな番号である。エラー内容は、発生した決済エラーの内容を示す。修正情報は、当該決済エラーを修正し、決済媒体ＩＤが示す決済媒体に正しい決済結果を反映させるために、行われるべき修正処理の内容を示す。

例えば、組合せ情報３００は、図２の決済実績情報５００が示す決済において発生した決済エラーを修正するための各情報を含む。具体的には、組合せ情報３００は、決済媒体ＩＤ「Ｃ１」、決済番号「０００１」、エラー内容「過減額」、修正情報「１００円返金」の各情報を含む。即ち、組合せ情報３００は、決済媒体ＩＤ「Ｃ１」の決済媒体１００との間で行われた決済番号「０００１」の決済において、決済媒体１００の残高を過大に減額するエラー（過減額）が発生したこと、及び、正しい決済結果の反映のためには、決済媒体１００の残高を１００円加算（即ち、過大に減額した分の１００円が返金）すべきであることを意味する。

また、組合せ情報３１０は、図２の決済実績情報５２０が示す決済において発生した決済エラーを修正するための各情報を含む。具体的には、組合せ情報３１０は、決済媒体ＩＤ「Ｃ２」、決済番号「５００１」、エラー内容「データ破損」、修正情報「残高１５００円」の各情報を含む。即ち、組合せ情報３１０は、決済媒体ＩＤ「Ｃ２」の決済媒体２００との間で行われた決済番号「５００１」の決済において、決済媒体２００の残高を表すデータが決済実行中に破損するエラー（データ破損）が発生したこと、及び、正しい決済結果の反映のためには、決済媒体２００の残高を１５００円に戻すべきであることを意味する。

（サーバ５０の制御部５８が実行するサーバ処理；図４）
続いて、図４を参照して、サーバ５０の制御部５８が実行するサーバ処理について説明する。サーバ５０の電源がＯＮされている間、制御部５８は、Ｓ１０、Ｓ２０の各監視を同時に実行する。

Ｓ１０では、制御部５８は、いずれかの決済端末から、決済実績情報を受信することを監視する。本実施例では、例えば、決済端末１０が決済媒体１００との間で決済を行うと、決済端末１０は、実行した決済の内容を示す決済実績情報を、決済完了後すぐにサーバ５０に送信する。制御部５８は、有線Ｉ／Ｆ５６を介して決済実績情報を受信すると、Ｓ１０でＹＥＳと判断してＳ１２に進む。

Ｓ２０では、制御部５８は、いずれかの決済端末から、完了情報を受信することを監視する。本実施例では、例えば、決済端末１０は、エラー修正テーブル７０に含まれるいずれかの組合せ情報が示す決済エラーを修正すると、サーバ５０に対して、当該決済エラーの修正が完了したことを示す完了情報をサーバ５０に送信する。完了情報には、修正された決済エラーに対応する決済媒体ＩＤ及び決済番号が含まれる。制御部５８は、有線Ｉ／Ｆ５６を介して完了情報を受信すると、Ｓ２０でＹＥＳと判断してＳ２２に進む。

Ｓ１２では、制御部５８は、受信した決済実績情報を、メモリ６０に記憶させる。この結果、メモリ６０内の決済実績情報群６４に新たに決済実績情報が追加される。

次いで、Ｓ１４では、制御部５８は、Ｓ１２でメモリ６０に記憶された決済実績情報に決済エラーが含まれるか否かを判断する。制御部５８は、決済実績情報を参照し、受信した決済実績情報に決済エラーが含まれるか否かを判断する。決済エラーには、「過減額」と「データ破損」の２種類がある。

「過減額」は、商店で本来設定していた商品価格に対して減額された金額が過大であった場合や、決済実行中の通信環境の悪化等によって、１回の決済で複数回減額処理を行った場合が該当する。例えば、上記の図２の決済実績情報５００が示す決済では、決済前残高が１５００円である場合に、定価３５０円の商品の決済を行った後の決済後残高が、本来１１５０円であるべきであるところ、１０５０円になっている。即ち、この決済では、１００円分の過減額の決済エラーが発生している。そのため、Ｓ１２でメモリ６０に記憶された決済実績情報が図２の決済実績情報５００であった場合、制御部５８は、Ｓ１４でＹＥＳと判断する。

また、「データ破損」は、決済実行中の通信環境の悪化等によって、決済媒体に記録されていた残高を表すデータが破損した場合が該当する。例えば、上記の図２の決済実績情報５２０が示す決済では、決済前残高が２０００円である場合に、定価５００円の商品の決済を行った後の決済後残高は本来１５００円であるべきであるが、決済実績情報５２０では、決済後残高のデータが破損している。即ち、この決済では、データ破損の決済エラーが発生している。そのため、Ｓ１２でメモリ６０に記憶された決済実績情報が図２の決済実績情報５２０であった場合、制御部５８は、Ｓ１４でＹＥＳと判断する。

上記の通り、制御部５８は、Ｓ１２でメモリ６０に記憶された決済実績情報が示す決済において決済エラーが発生している場合には、Ｓ１４でＹＥＳと判断し、Ｓ１６に進む。

一方、受信した決済実績情報が示す決済において決済エラーが発生していない場合（例えば、Ｓ１２でメモリ６０に記憶された決済実績情報が図２の決済実績情報５１０である場合）、制御部５８は、Ｓ１４でＮＯと判断する。この場合、制御部５８は、Ｓ１０及びＳ２０に戻って再び監視を行う。

Ｓ１６では、制御部５８は、エラー修正テーブル７０の内容を変更する。具体的には、制御部５８は、受信した決済実績情報に基づいて、決済エラーが発生した決済媒体のＩＤ、決済番号、エラー内容（過減額又はデータ破損）、及び、修正情報を含む組合せ情報を生成する（図３の組合せ情報３００、３１０参照）。制御部５８は、生成した組合せ情報を含む新たなエラー修正テーブル７０（図３参照）を生成する。制御部５８は、生成した新たなエラー修正テーブル７０をメモリ６０に記憶させる。

続くＳ１８では、制御部５８は、有線Ｉ／Ｆ５６を介して、Ｓ１６で変更された新たなエラー修正テーブル７０を、決済端末１０、３０のそれぞれに送信する。これにより、各決済端末において、新たなエラー修正テーブル７０が記憶される。Ｓ１８を終えると、制御部５８は、Ｓ１０及びＳ２０に戻って再び監視を行う。

Ｓ２２では、制御部５８は、受信した完了情報に含まれる決済媒体ＩＤ及び決済番号に対応する組合せ情報を、エラー修正テーブル７０から削除する。

続くＳ２４では、制御部５８は、有線Ｉ／Ｆ５６を介して、受信した完了情報と同じ完了情報を、完了情報の送信元の決済端末（例えば、決済端末１０）以外の決済端末（例えば、決済端末３０）に対して送信する。これにより、各決済端末１０、３０及びサーバ５０において、修正の完了が反映される。Ｓ２４を終えると、制御部５８は、Ｓ１０及びＳ２０に戻って再び監視を行う。

（決済端末１０の制御部１８が実行する端末処理；図５）
続いて、図５を参照して、決済端末１０の制御部１８が実行する端末処理について説明する。なお、以下では、決済端末１０の制御部１８の端末処理を例として説明するが、決済端末３０の制御部３８も同様の端末処理を実行する。決済端末１０の電源がＯＮされている間、制御部１８は、Ｓ４０、Ｓ５４、及び、Ｓ５８の各監視を同時に実行する。

Ｓ４０では、制御部１８は、顧客が購入を希望する商品の名称や、顧客が購入を希望する商品の金額（即ち、決済金額）等、決済に必要な決済情報が入力されることを監視する。例えば、商店の店員が操作部１２を介して決済情報を入力する場合、制御部１８はＳ４０でＹＥＳと判断し、Ｓ４２に進む。他の例では、商店の店員が図示しないＰＯＳ端末を介して決済情報を入力する場合にも、制御部１８はＳ４０でＹＥＳと判断してもよい。

Ｓ５４では、制御部１８は、サーバ５０から完了情報を受信することを監視する。上記の通り、サーバ５０は、一の決済端末（例えば、決済端末３０）が送信した完了情報を受信すると、他の決済端末（例えば、決済端末１０）に対して完了情報を送信する（図４のＳ２４参照）。制御部１８は、サーバ５０から完了情報を受信すると、Ｓ５４でＹＥＳと判断し、Ｓ５６に進む。

Ｓ５８では、制御部１８は、サーバ５０からエラー修正テーブル７０を受信することを監視する。上記の通り、サーバ５０は、エラー修正テーブル７０の内容を変更した場合（図４のＳ１６参照）、新たなエラー修正テーブル７０を各決済端末に対して送信する（図４のＳ１８参照）。制御部１８は、サーバ５０から新たなエラー修正テーブル７０を受信すると、Ｓ５８でＹＥＳと判断し、Ｓ６０に進む。

Ｓ４２では、制御部１８は、ＮＦＣＩ／Ｆ１７を介して、決済媒体（例えば、決済媒体１００）を検出することを監視する。例えば、顧客が決済媒体１００を決済端末１０にかざすと、ＮＦＣＩ／Ｆ１７は、決済媒体１００を検出する。ＮＦＣＩ／Ｆ１７が決済媒体を検出すると、制御部１８は、Ｓ４２でＹＥＳと判断し、Ｓ４４に進む。

Ｓ４４では、制御部１８は、検出された決済媒体のＩＤが、エラー修正テーブル７０内に含まれるか否かを判断する。ＮＦＣＩ／Ｆ１７が決済媒体を検出すると、制御部１８は、ＮＦＣＩ／Ｆ１７を介して、検出された決済媒体のＩＤを受信する。受信したＩＤがエラー修正テーブル７０に含まれている場合、制御部１８は、Ｓ４４でＹＥＳと判断し、Ｓ４６に進む。例えば、検出された決済媒体が決済媒体１００であれば、制御部１８は、ＮＦＣＩ／Ｆ１７を介して、ＩＤ「Ｃ１」を受信する。受信したＩＤ「Ｃ１」は、図３のエラー修正テーブル７０に含まれている（組合せ情報３００参照）。このような場合、制御部１８は、Ｓ４４でＹＥＳと判断する。一方、受信したＩＤがエラー修正テーブル７０に含まれていない場合、制御部１８は、Ｓ４４でＮＯと判断し、Ｓ４６、Ｓ４８、Ｓ４９をスキップしてＳ５０に進む。

Ｓ４６では、制御部１８は、受信したＩＤに対応する決済エラーの修正を、検出された決済媒体に対して実行する。具体的には、制御部１８は、エラー修正テーブル７０を参照し、受信したＩＤを含む組合せ情報を特定する。次いで、制御部１８は、特定した組合せ情報に含まれる修正情報が示す修正内容に従って、決済媒体の記憶内容（具体的には、残高）を修正する。例えば、受信したＩＤに対応する修正情報が「１００円返金」を示す場合（図３の組合せ情報３００参照）、制御部１８は、検出された決済媒体（例えば決済媒体１００）に対して、残高を１００円加算する処理を行う。また、例えば、修正情報が「残高１５００円」を示す場合（図３の組合せ情報３１０参照）、制御部１８は、検出された決済媒体（例えば決済媒体２００）に対して、残高「１５００円」を書き込む処理を行う。

続くＳ４８では、制御部１８は、完了情報をサーバ５０に送信する。完了情報には、Ｓ４６で修正を行った決済媒体のＩＤ、及び、そのＩＤに対応する決済番号を含む完了情報をサーバ５０に送信する。受信したＩＤに対応する決済番号は、エラー修正テーブル７０に含まれている。

続くＳ４９では、制御部１８は、修正を行った決済媒体のＩＤに対応する組合せ情報を、エラー修正テーブル７０から削除する。

続くＳ５０では、制御部１８は、Ｓ４０でＹＥＳの場合に入力された決済情報に従って、検出中の決済媒体との間で決済を実行する。具体的には、制御部１８は、決済媒体から読み取った電子マネーの残高を決済金額分だけ減じたうえで、変更後の残高情報を決済媒体に書き込む処理を行う。なお、このタイミングで決済エラーが発生する可能性もあるが、制御部１８は、決済エラーの発生を検出しない。

続くＳ５２では、制御部１８は、Ｓ５０で実行された決済の内容を示す決済実績情報を生成し、サーバ５０に送信する。Ｓ５２を終えると、制御部１８は、Ｓ４０、Ｓ５４、Ｓ５８に戻って再び監視を行う。

Ｓ５６では、制御部１８は、受信した完了情報が示す決済媒体ＩＤ及び決済番号を含む組合せ情報を、エラー修正テーブル７０から削除する。これにより、他の決済端末において修正が完了したことを、決済端末１０にも反映させることができる。Ｓ５６を終えると、制御部１８は、Ｓ４０、Ｓ５４、Ｓ５８に戻って再び監視を行う。

Ｓ６０では、制御部１８は、受信した新たなエラー修正テーブル７０を、現在のエラー修正テーブル７０に置き換えてメモリ２０に記憶させる。Ｓ６０を終えると、制御部１８は、Ｓ４０、Ｓ５４、Ｓ５８に戻って再び監視を行う。

（具体例；図６）
続いて、図６を参照して、決済媒体１００、決済端末１０、３０、及び、サーバ５０の間で実行される処理の具体例を説明する。図６の例では、決済媒体１００と決済端末１０との間で決済（第１の決済）が行われた際に決済エラーが発生し、その後、決済端末３０が決済媒体１００のエラーを修正し、決済媒体１００と決済端末３０との間で別の決済（第２の決済）がさらに行われる場合について説明する。

まず、店員は、決済媒体１００を用いた第１の決済を行うために、決済端末１０に決済情報（商品名、決済金額等）を入力する（図５のＳ４０でＹＥＳ）。次いで、顧客が、決済媒体１００を決済端末１０にかざすと、決済端末１０が決済媒体１００を検出する（Ｓ４２でＹＥＳ）。決済端末１０が決済媒体１００を検出すると、決済端末１０は、決済媒体１００との間で第１の決済を実行する（Ｓ４４でＮＯ、Ｓ５０）。ただし、この例では、第１の決済時に、決済媒体１００の残高を１００円分余計に減額するという決済エラー（即ち、過減額）が発生している。第１の決済が完了すると、決済端末１０は、第１の決済の内容を示す決済実績情報（即ち、図２の決済実績情報５００）をサーバ５０に送信する（Ｓ５２）。

サーバ５０は、決済実績情報５００を受信する（図４のＳ１０でＹＥＳ）と、決済実績情報５００を記憶する（Ｓ１２）。次いで、サーバ５０は、受信した決済実績情報が決済エラー（過減額）を含むと判断する（Ｓ１４でＹＥＳ）。サーバ５０は、受信した決済実績情報５００に基づいて、決済エラーが発生した決済端末のＩＤ「Ｃ１」、決済番号、エラー内容「過減額」、及び、修正情報「１００円返金」を含む組合せ情報（図３の組合せ情報３００参照）を生成し、生成した組合せ情報を含む新たなエラー修正テーブル７０（図３参照）を生成する（図４のＳ１６）。サーバ５０は、新たなエラー修正テーブル７０を、決済端末１０、３０に送信する（Ｓ１８）。

決済端末１０、３０は、新たなエラー修正テーブル７０を受信すると、エラー修正テーブル７０を記憶する（図５のＳ６０）。

その後、店員は、決済媒体１００を用いた第２の決済を行うために、決済端末３０に決済情報（商品名、決済金額等）を入力する（図５のＳ４０でＹＥＳ）。次いで、顧客が、決済媒体１００を決済端末３０にかざすと、決済端末３０が決済媒体１００を検出する（Ｓ４２でＹＥＳ）。この時点で、決済媒体１００のＩＤ「Ｃ１」は、エラー修正テーブル７０（図３参照）に含まれている（図３の組合せ情報３００参照）（図５のＳ４４でＹＥＳ）。そのため、決済端末３０は、組合せ情報３００に含まれる修正情報「１００円返金」が示す修正を行う（Ｓ４６）。即ち、決済端末３０は、決済媒体１００の残高を１００円加算する処理を行う。決済端末３０は、修正が完了すると、完了情報をサーバ５０に送信する（図５のＳ４８）。

サーバ５０は、完了情報を受信すると（図４のＳ２０でＹＥＳ）、完了情報に含まれるＩＤ「Ｃ１」及び決済番号に対応する組合せ情報３００をエラー修正テーブル７０から削除する（図４のＳ２２）。また、サーバ５０は、決済端末１０に対して完了情報を送信する（Ｓ２４）。

決済端末１０は、サーバ５０から完了情報を受信すると（図５のＳ５４でＹＥＳ）、完了情報に含まれるＩＤ「Ｃ１」及び決済番号に対応する組合せ情報３００をエラー修正テーブル７０から削除する（Ｓ５６）。

続いて、決済媒体１００を検出している決済端末３０は、決済媒体１００との間で第２の決済を実行する（図５のＳ５０）。第２の決済は正常に完了する。第２の決済が完了すると、決済端末３０は、第２の決済の内容を示す決済実績情報をサーバ５０に送信する（Ｓ５２）。

サーバ５０は、決済実績情報を受信すると（図４のＳ１０でＹＥＳ）、決済実績情報を記憶する（Ｓ１２）。この場合、サーバ５０は、受信した決済実績情報が決済エラーを含まないと判断する（Ｓ１４でＮＯ）。

以上、本実施例の決済システム２について説明した。図６に示すように、本実施例の決済システム２では、決済端末３０は、エラー修正テーブルに含まれるＩＤ「Ｃ１」と一致するＩＤ「Ｃ１」を有する決済媒体１００を検出する場合に、エラー修正テーブル７０において当該ＩＤに対応付けられている修正情報「１００円返金」に基づいて、決済媒体１００の残高を修正する。そのため、本実施例の決済システム２では、決済端末１０のユーザである店員が、決済端末１０における第１の決済の際に決済エラーが発生したことを認識できなかった場合においても、以後の第２の決済の際に、当該決済エラーを解消することができる。従って、本実施例の決済システム２によると、決済媒体１００について発生した決済エラーを適切に修正することができる。

また、本実施例の決済システム２では、複数個の決済端末１０、３０が、第１の決済の際に発生した決済エラーを修正するための修正情報「１００円返金」を含むエラー修正テーブル７０を記憶する。そのため、本実施例の決済システム２では、複数個の決済端末１０、３０のうちのいずれにおいても、決済媒体１００について発生した決済エラーを修正することができる。また、図６に示すように、決済端末３０で決済エラーが修正された場合に、決済端末３０、サーバ５０、及び、決済端末３０以外の決済端末１０におけるエラー修正テーブル７０から、修正された決済エラーに関する組合せ情報３００が削除される。そのため、決済エラーの修正が重複して行われることも防止することができる。

（第２実施例）
第２実施例について、第１実施例と異なる点を中心に説明する。本実施例の決済システム２の構成も、第１実施例の決済システム２の構成（図１参照）と基本的に共通する。ただし、第１実施例の決済システム２では、サーバ５０と決済端末１０、３０とが常時通信可能であり、決済実績情報、完了情報、エラー修正テーブル等の各種情報の変更が即時反映される方式（いわゆるリアルタイム方式）を採用しているのに対し、本実施例の決済システム２では、サーバ５０と決済端末１０、３０とが、特定のタイミングにおいてのみ通信可能となる方式（いわゆるオフライン方式）を採用している点が異なる。即ち、本実施例では、サーバ５０と決済端末１０、３０との間で、決済実績情報、完了情報、エラー修正テーブル等の各種情報の変更を即時に行うことはできない。そのため、本実施例では、決済エラーの修正を実行可能な決済端末（以下では、「特定端末」と呼ぶ場合がある）が決済端末１０、３０のうちのいずれか一つに限られており、それ以外の決済端末では、決済エラーの修正を実行できない。特定端末以外の決済端末のことを、以下では「通常端末」と呼ぶ場合がある。本実施例では、各決済端末１０、３０は、特定端末の識別情報を含む許可情報８０（図１参照）を記憶している。後で説明するように、許可情報８０は、サーバ５０から、エラー修正テーブル７０とともに受信される。

（サーバ５０の制御部５８が実行するサーバ処理；図７）
続いて、図７を参照して、本実施例のサーバ５０の制御部５８が実行するサーバ処理について説明する。

Ｓ７０では、制御部５８は、決済端末から、決済実績情報と完了情報とを受信することを監視する。決済端末において特定のタイミングが到来する場合（後述の図８のＳ１１０参照）に、その決済端末は、特定のタイミングが到来するまでに当該決済端末で行われた各決済の内容を示す決済実績情報を、サーバ５０に送信する（図８のＳ１１２参照）。また、特定端末である決済端末１０は、決済実績情報に加えて、特定のタイミングが到来するまでに決済端末１０で行われた決済エラーの修正を示す完了情報を、サーバ５０に送信する。制御部５８は、決済実績情報、又は、決済実績情報及び完了情報（以下では「決済実績情報等」と呼ぶ場合がある）を受信すると、Ｓ７０でＹＥＳと判断し、Ｓ７２に進む。

Ｓ７２では、制御部５８は、受信した決済実績情報等をメモリ６０に記憶させる。この結果、メモリ６０内の決済実績情報群６４に新たに決済実績情報が追加される。

次いで、Ｓ７４では、制御部５８は、サーバ５０と通信可能なすべての決済端末から決済実績情報等を受信したか否かを判断する。本実施例では、メモリ６０には、サーバ５０と通信可能な各決済端末（即ち決済端末１０、３０）のＩＤが記憶されている。制御部５８は、受信した決済実績情報等の送信元の決済端末のＩＤを参照し、メモリ６０内の各ＩＤのうち、受信した決済実績情報等の送信元のＩＤに受信済みフラグを対応付ける。Ｓ７４の時点でメモリ６０内のすべてのＩＤに受信済みフラグが対応付けられていれば、制御部５８は、Ｓ７４でＹＥＳと判断し、Ｓ７６に進む。一方、Ｓ７４の時点で、メモリ６０内のすべてのＩＤに受信済みフラグが対応付けられていなければ、制御部５８は、Ｓ７４でＮＯと判断し、Ｓ７０に戻って再び監視を行う。

Ｓ７６では、制御部５８は、メモリ６０に記憶されている完了情報に含まれる決済媒体ＩＤ及び決済番号に対応する組合せ情報を、エラー修正テーブル７０から削除する。

次いで、Ｓ７８では、制御部５８は、メモリ６０内の決済実績情報群６４に決済エラーが含まれるか否かを判断する。決済エラーが含まれるか否かの判断手法は、第１実施例（図４のＳ１４参照）と同様である。制御部５８は、Ｓ７８でＹＥＳと判断すると、Ｓ８０に進む。一方、制御部５８は、Ｓ７８でＮＯと判断すると、Ｓ８０をスキップして、Ｓ８２に進む。

Ｓ８０では、制御部５８は、エラー修正テーブル７０の内容を変更する。制御部５８は、決済エラーが発生した決済媒体のＩＤ、決済番号、エラー内容（過減額又はデータ破損）、及び、修正情報を含む組合せ情報を生成する。制御部５８は、生成した組合せ情報を含む新たなエラー修正テーブル７０を生成する。制御部５８は、生成した新たなエラー修正テーブル７０をメモリ６０に記憶させる。

Ｓ８２では、制御部５８は、有線Ｉ／Ｆ５６を介して、この時点のエラー修正テーブル７０を、すべての決済端末に対して送信する。同時に、Ｓ８２では、制御部５８は、特定端末（例えば、決済端末１０）の識別情報を含む許可情報８０を、すべての決済端末に対して送信する。これにより、各決済端末において、新たなエラー修正テーブル７０及び許可情報８０が記憶される。各決済端末１０、３０において許可情報８０が記憶されることで、許可情報８０に自機の識別情報が含まれている決済端末が特定端末として動作し、それ以外の端末が通常端末として動作することができる。Ｓ８２を終えると、制御部５８は、Ｓ７０に戻って再び監視を行う。

（決済端末１０の制御部１８が実行する端末処理；図８）
続いて、図８を参照して、決済端末１０の制御部１８が実行する端末処理について説明する。なお、以下では、決済端末１０の制御部１８の端末処理を例として説明するが、決済端末３０の制御部３８も同様の端末処理を実行する。決済端末１０の電源がＯＮされている間、制御部１８は、Ｓ９０、Ｓ１１０、及び、Ｓ１１４の各監視を同時に実行する。

Ｓ９０では、制御部１８は、決済情報が入力されることを監視する。Ｓ９０の処理の内容は、図５のＳ４０と同様であるため、詳しい説明を省略する。決済情報が入力されると、制御部１８は、Ｓ９０でＹＥＳと判断し、Ｓ９２に進む。

Ｓ１１０では、制御部１８は、特定のタイミングが到来することを監視する。本実施例では、制御部１８は、予めプログラムされた特定のタイミング（例えば、毎日０時）が到来したことを検出すると、Ｓ１１０でＹＥＳと判断し、Ｓ１１２に進む。

Ｓ１１４では、制御部１８は、サーバ５０からエラー修正テーブル７０及び許可情報８０を受信することを監視する。上記の通り、サーバ５０は、新たなエラー修正テーブル７０と、特定端末の識別情報を含む許可情報８０とを各決済端末に対して送信する（図７のＳ８２参照）。制御部１８は、サーバ５０から新たなエラー修正テーブル７０及び許可情報８０を受信すると、Ｓ１１４でＹＥＳと判断し、Ｓ１１６に進む。

Ｓ９２では、制御部１８は、ＮＦＣＩ／Ｆ１７を介して、決済媒体（例えば、決済媒体１００）を検出することを監視する。ＮＦＣＩ／Ｆ１７が決済媒体を検出すると、制御部１８は、Ｓ９２でＹＥＳと判断し、Ｓ９４に進む。

Ｓ９４では、制御部１８は、検出された決済媒体のＩＤが、エラー修正テーブル７０内に含まれるか否かを判断する。Ｓ９４の処理の内容は、図５のＳ４４と同様であるため、詳しい説明は省略する。検出された決済媒体のＩＤがエラー修正テーブル７０内に含まれる場合、制御部１８は、Ｓ９４でＹＥＳと判断してＳ９６に進む。一方、検出された決済媒体のＩＤがエラー修正テーブル７０内に含まれていない場合、制御部１８は、Ｓ９４でＮＯと判断し、Ｓ１０４に進む。

Ｓ９６では、制御部１８は、自機（即ち、決済端末１０）が特定端末であるか否か判断する。具体的には、制御部１８は、メモリ２０内の許可情報８０が、自機の識別情報を含むか否かを判断する。許可情報８０が、自機の識別情報を含む場合、制御部１８は、Ｓ９６でＹＥＳと判断し、Ｓ９８に進む。一方、許可情報８０が、自機の識別情報を含まない場合、制御部１８は、Ｓ９６でＮＯと判断し、Ｓ１０８に進む。

Ｓ１０８では、制御部１８は、検出中の決済媒体において決済エラーが発生していること、及び、特定端末（即ち、他機）において当該エラーの修正が可能であることを、当該決済媒体のユーザ（例えば、顧客）に対して報知する報知動作を行う。具体的には、Ｓ１０８では、制御部１８は、表示部１４にメッセージを表示する。メッセージを見た顧客又は店員は、検出された決済媒体において決済エラーが発生していたこと、及び、特定端末で修正が可能であることを知ることができる。この場合、制御部１８は、Ｓ９０でＹＥＳの場合に入力された決済情報に従った決済を実行しない。Ｓ１０８を終えると、制御部１８は、Ｓ９０、Ｓ１１０、Ｓ１１４に戻って再び監視を行う。

Ｓ９８では、制御部１８は、受信したＩＤに対応する決済エラーの修正を、検出された決済媒体に対して実行する。Ｓ９８の処理の内容は、Ｓ４６と同様であるため、詳しい説明は省略する。

続くＳ１００では、制御部１８は、完了情報をメモリ２０に記憶させる。完了情報には、Ｓ９８で修正を行った決済媒体のＩＤ、及び、そのＩＤに対応する決済番号を含む。

続くＳ１０２では、制御部１８は、修正を行った決済媒体のＩＤに対応する組合せ情報を、エラー修正テーブル７０から削除する。

続くＳ１０４では、制御部１８は、Ｓ９０でＹＥＳの場合に入力された決済情報に従って、検出された決済媒体との間で決済を実行する。なお、このタイミングで決済エラーが発生する可能性もあるが、制御部１８は、決済エラーの発生を検出しない。

続くＳ１０６では、制御部１８は、Ｓ１０４で実行された決済の内容を示す決済実績情報を生成し、メモリ２０に記憶させる。Ｓ１０６を終えると、制御部１８は、Ｓ９０、Ｓ１１０、Ｓ１１４に戻って再び監視を行う。

Ｓ１１２では、制御部１８は、メモリ２０に記憶されている決済実績情報等（即ち、決済実績情報及び完了情報、又は、決済実績情報のみ）をサーバ５０に送信する。Ｓ１１２を終えると、制御部１８は、Ｓ９０、Ｓ１１０、Ｓ１１４に戻って再び監視を行う。

Ｓ１１６では、制御部１８は、受信したエラー修正テーブル７０及び許可情報８０をメモリ２０に記憶させる。この際、制御部１８は、受信したエラー修正テーブル７０及び許可情報８０を、メモリ２０に記憶されていたものと置き換えて記憶させる。Ｓ１１６を終えると、制御部１８は、Ｓ９０、Ｓ１１０、Ｓ１１４に戻って再び監視を行う。

（具体例；図９）
続いて、図９を参照して、決済媒体１００、決済端末１０、３０、及び、サーバ５０の間で実行される処理の具体例を説明する。図９では、決済端末１０が特定端末として機能し、決済端末３０が通常端末として機能する場合の例について説明する。図９の例では、決済媒体１００と決済端末１０との間で決済（第１の決済）が行われた際に決済エラーが発生し、その後、決済媒体１００と決済端末３０との間で別の決済（第２の決済）が行われようとする際に、決済端末３０が決済端末１０で決済エラーの修正が可能であることを報知し、その後、決済端末１０が決済媒体１００のエラーを修正し、決済媒体１００と決済端末１０との間で別の決済（第３の決済）がさらに行われる。

まず、店員は、決済媒体１００を用いた第１の決済を行うために、決済端末１０に決済情報を入力する（図８のＳ９０でＹＥＳ）。次いで、顧客が、決済媒体１００を決済端末１０にかざすと、決済端末１０が決済媒体１００を検出する（Ｓ９２でＹＥＳ）。決済端末１０が決済媒体１００を検出すると、決済端末１０は、決済媒体１００との間で第１の決済を実行する（Ｓ９４でＮＯ、Ｓ１０４）。ただし、この例でも、第１の決済時に、決済媒体１００の残高を１００円分余計に減額するという決済エラー（即ち、過減額）が発生している。第１の決済が完了すると、決済端末１０は、第１の決済の内容を示す決済実績情報をメモリ２０に記憶させる（Ｓ１０６）。

その後、決済端末１０において特定のタイミングが到来すると（図８のＳ１１０でＹＥＳ）、決済端末１０は、メモリ２０に記憶されている決済実績情報等（即ち、決済実績情報及び完了情報）をサーバ５０に送信する（Ｓ１１２）。

サーバ５０は、決済端末１０から決済実績情報等を受信すると、受信した決済実績情報等を記憶する（図７のＳ７０でＹＥＳ、Ｓ７２）。

また、決済端末３０においても特定のタイミングが到来すると（図８のＳ１１０でＹＥＳ）、決済端末３０は、メモリ４０に記憶されている決済実績情報をサーバ５０に送信する（Ｓ１１２）。

サーバ５０は、決済端末３０から決済実績情報を受信すると、受信した決済実績情報をメモリ６０に記憶させる（図７のＳ７０でＹＥＳ、Ｓ７２）。この時点で、サーバ５０は、すべての決済端末から決済実績情報等を受信したと判断する（Ｓ７４でＹＥＳ）。次いで、サーバ５０は、メモリ６０に記憶された完了情報に含まれるＩＤ及び決済番号に対応する組合せ情報をエラー修正テーブル７０から削除する（Ｓ７６）。次いで、サーバ５０は、メモリ６０内の決済実績情報群６４が決済エラー（過減額）を含むと判断する（Ｓ７８でＹＥＳ）。サーバ５０は、決済エラーが発生した決済端末のＩＤ「Ｃ１」、決済番号、エラー内容「過減額」、及び、修正情報「１００円返金」を含む組合せ情報（図３の組合せ情報３００参照）を生成し、生成した組合せ情報を含む新たなエラー修正テーブル７０（図３参照）を生成する（図７のＳ８０）。サーバ５０は、生成した新たなエラー修正テーブル７０と、決済端末１０の識別情報を含む許可情報８０とを、決済端末１０、３０に送信する（Ｓ８２）。

決済端末１０、３０は、新たなエラー修正テーブル７０と許可情報８０を受信すると、エラー修正テーブル７０及び許可情報８０を記憶する（図８のＳ１１６）。

その後、店員は、決済媒体１００を用いた第２の決済を行うために、決済端末３０に決済情報（商品名、決済金額等）を入力する（図８のＳ９０でＹＥＳ）。次いで、顧客が、決済媒体１００を決済端末３０にかざすと、決済端末３０が決済媒体１００を検出する（Ｓ９２でＹＥＳ）。この時点で、決済媒体１００のＩＤ「Ｃ１」は、エラー修正テーブル７０（図３参照）に含まれている（図３の組合せ情報３００参照）（図８のＳ９４でＹＥＳ）。次いで、決済端末３０は、自機は特定端末ではないと判断し、決済端末３０は、特定端末である決済端末１０で決済エラーの修正が可能である旨の報知動作を行う（Ｓ９６でＮＯ、Ｓ１０８）。この場合、決済端末３０では第２の決済は行われない。

その後、顧客は、決済媒体１００を持って決済端末１０のもとを訪れる。店員は、決済媒体１００を用いた第３の決済を行うために、決済端末１０に決済情報を入力する（図８のＳ９０でＹＥＳ）。次いで、顧客が、決済媒体１００を決済端末１０にかざすと、決済端末１０が決済媒体１００を検出する（Ｓ９２でＹＥＳ）。決済媒体１００のＩＤ「Ｃ１」は、エラー修正テーブル７０（図３参照）に含まれている（図３の組合せ情報３００参照）（図８のＳ９４でＹＥＳ）。決済端末１０は、自機が特定端末であると判断する（Ｓ９６でＮＯ）。次いで、決済端末１０は、組合せ情報３００に含まれる修正情報「１００円返金」が示す修正を行う（Ｓ９８）。即ち、決済端末１０は、決済媒体１００の残高を１００円加算する処理を行う。決済端末１０は、修正が完了すると、完了情報をメモリ２０に記憶する（Ｓ１００）。また、決済端末１０は、記憶するエラー修正テーブル７０から、組合せ情報３００を削除する（Ｓ１０２）。

続いて、決済媒体１００を検出している決済端末１０は、決済媒体１００との間で第３の決済を実行する（図８のＳ１０４）。第３の決済は正常に完了する。第３の決済が完了すると、決済端末１０は、第３の決済の内容を示す決済実績情報を記憶する（図８のＳ１０６）。

その後、決済端末１０において再び特定のタイミングが到来すると（図８のＳ１１０でＹＥＳ）、決済端末１０は、記憶している決済実績情報等（即ち、決済実績情報及び完了情報）をサーバ５０に送信する（図８のＳ１１２）。

サーバ５０は、決済端末１０から決済実績情報等を受信すると、受信した決済実績情報等を記憶する（図７のＳ７０でＹＥＳ、Ｓ７２）。

また、決済端末３０においても再び特定のタイミングが到来すると（図８のＳ１１０でＹＥＳ）、決済端末３０は、記憶している決済実績情報をサーバ５０に送信する（Ｓ１１２）。

サーバ５０は、決済端末３０から決済実績情報を受信すると、受信した決済実績情報を記憶する（図７のＳ７０でＹＥＳ、Ｓ７２）。この時点で、サーバ５０は、すべての決済端末から決済実績情報等を受信したと判断する（Ｓ７４でＹＥＳ）。サーバ５０は、メモリ６０に記憶された完了情報に含まれるＩＤ「Ｃ１」及び決済番号に対応する組合せ情報３００をエラー修正テーブル７０から削除する（Ｓ７６）。次いで、サーバ５０は、記憶する決済実績情報群６４が決済エラーを含まないと判断する（Ｓ７８でＮＯ）。次いで、サーバ５０は、その時点のエラー修正テーブル７０と、決済端末１０の識別情報を含む許可情報８０とを、決済端末１０、３０に送信する（Ｓ８２）。

決済端末１０、３０は、エラー修正テーブル７０及び許可情報８０を受信すると、エラー修正テーブル７０及び許可情報８０を更新する（図８のＳ１１６）。

以上、本実施例の決済システム２について説明した。本実施例の決済システム２では、各決済端末１０、３０とサーバ５０とが、決済実績情報の通信を常時実行しないオフライン方式が採用されている。そのため、本実施例では、図９に示すように、特定端末である決済端末１０のみが、決済エラーが発生した決済媒体１００を検出した場合に、決済媒体１００の決済エラーを修正することができる。通常端末である決済端末３０が決済媒体１００を検出しても、決済媒体１００の決済エラーを修正しない。本実施例の決済システム２によると、オフライン方式が採用される場合であっても、決済エラーの修正が重複して行われることを防止するとともに、適切に決済エラーを修正することができる。

また、通常端末である決済端末３０が、決済エラーが発生した決済媒体１００を検出した場合に、決済端末３０は、特定端末である決済端末１０で決済エラーの修正が可能である旨の報知動作を行う。これにより、報知動作を見た決済媒体１００のユーザ（顧客）や、決済端末３０のユーザ（店員）に、決済端末１０で決済エラーの修正が可能であることを適切に知らせることができる。

（第３実施例）
第１、第２実施例と異なる点を中心に説明する。第１、第２実施例では、制御部５８が自動的に決済エラーを検出し、エラー修正テーブル７０を生成する。本実施例では、制御部５８は、自動的に決済エラーを検出してエラー修正テーブル７０を生成することに加えて、さらに、サーバ５０のユーザが操作部５２を介して入力する指示に従って、エラー修正テーブル７０を生成することもできる。

本実施例では、サーバ５０のユーザは、操作部５２を操作して、メモリ６０の決済実績情報群６４に含まれる各決済実績情報を閲覧するための閲覧操作を入力することができる。サーバ５０の制御部５８は、閲覧操作が行われると、決済実績情報群６４に含まれる各決済実績情報の内容を含む閲覧画面を表示部５４に表示させる。サーバ５０のユーザは、閲覧画面が表示されている間に、操作部５２を操作して、閲覧画面内の複数の決済実績情報のうちの１以上の決済実績情報が示す決済をエラー決済に指定するとともに、修正情報を入力する編集操作を行うことができる。制御部５８は、編集操作が行われる場合、編集操作に従って、エラー修正テーブル７０を生成することができる。第１、第２実施例と同様に、制御部５８は、生成したエラー修正テーブル７０を、各決済端末に送信する。

本実施例の決済システム２によると、ユーザの指示に従って決済エラーを修正することが可能となる。サーバ５０に記憶された決済実績情報からは自動的に検出されない態様の決済エラーを修正することも可能となるため、決済媒体について発生した決済エラーをより適切に修正することができる。

以上、本明細書で開示する技術の一実施例について詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例を含んでもよい。

（変形例１）サーバ５０の制御部５８が検出する決済エラーは、過減額及びデータ破損に限られず、他の任意のエラーを含んでもよい。例えば、誤って決済媒体に残高を加算した過加算等のエラーを含んでもよい。過加算のエラーが発生した場合、エラー修正テーブル７０に含まれる修正情報は、正しい決済結果に適合するように決済媒体の残高を減額する修正を行うことを指示する情報であってもよい。

（変形例２）第２実施例において、通常端末である決済端末３０が実行する報知動作の内容は、表示部３４へのメッセージの表示には限られない。決済端末３０は、他の任意の報知動作を行うことができる。例えば、決済端末３０は、特定端末である決済端末１０で修正が可能であることを音声で報知してもよい。

（変形例３）図１では、２つの決済端末１０、３０のみを図示しているが、決済システム２は、決済端末１０、３０以外の１以上の他の決済端末を有していてもよい。

本明細書または図面に説明した技術要素は、単独であるいは各種の組み合わせによって技術的有用性を発揮するものであり、出願時請求項記載の組み合わせに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。

２：決済システム
１０、３０：決済端末
１２、３２：操作部
１４、３４：表示部
１６、３６：有線Ｉ／Ｆ
１７、３７：ＮＦＣＩ／Ｆ
１８、３８：制御部
２０、４０：メモリ
２１、４１：プログラム
５０：サーバ
５２：操作部
５４：表示部
５６：有線Ｉ／Ｆ
５８：制御部
６０：メモリ
６１：プログラム
６４：決済実績情報群
７０：エラー修正テーブル
８０：許可情報
１００ 決済媒体
２００ 決済媒体
３００、３１０：組合せ情報

Claims (5)

1. 決済媒体との間で決済を行うための決済端末と、
   決済端末と通信可能に接続され、決済端末で実行された決済に関する決済実績情報を管理するサーバと、を備え、
   決済端末は、
   決済媒体を検出可能であると共に決済媒体と通信可能な通信インターフェースを有しており、
   検出された決済媒体との間で通信インターフェースを介して決済を実行し、
   実行された決済に関する決済実績情報をサーバに送信し、
   サーバは、
   決済端末から決済実績情報を受信して記憶し、
   記憶した決済実績情報に１以上の決済エラーが含まれる場合は、それら１以上の決済エラーのそれぞれについて、当該決済エラーが発生した決済媒体を示す識別情報と、当該決済エラーが発生した決済の正しい決済結果に関係する修正情報と、が対応付けられたエラー修正テーブルを生成し、
   生成されたエラー修正テーブルを決済端末に送信し、
   決済端末は、
   サーバからエラー修正テーブルを受信して記憶し、
   記憶したエラー修正テーブルに含まれる１以上の識別情報のうちのいずれかと一致する識別情報を有する決済媒体が検出される場合に、エラー修正テーブルにおいて当該識別情報に対応付けられている修正情報に基づいて、当該決済媒体の記憶内容を修正する、
   決済システム。
2. サーバは、
   ユーザが指示を入力するための入力手段をさらに備え、
   ユーザが入力手段を介して入力する指示に従って、記憶された決済実績情報に基づいてエラー修正テーブルを生成する、
   請求項１の決済システム。
3. 決済システムは、
   複数個の決済端末を備えており、
   複数個の決済端末のそれぞれは、サーバと通信可能に接続されており、
   サーバは、
   生成されたエラー修正テーブルを記憶すると共に複数個の決済端末のそれぞれに送信し、
   複数個の決済端末のうちのいずれかが、エラー修正テーブルに含まれる識別情報と一致する識別情報を有する決済媒体を検出し、その決済媒体の記憶内容を修正した場合に、
   当該決済端末は、
   エラー修正テーブルから、記憶内容が修正された決済媒体に関する識別情報及び修正情報を削除すると共に、当該識別情報及び修正情報に対応する決済エラーの修正が完了したことを示す完了情報をサーバに送信し、
   サーバは、
   決済端末から完了情報を受信すると、当該完了情報に関する識別情報及び修正情報をエラー修正テーブルから削除すると共に、当該完了情報を、当該完了情報をサーバに送信した決済端末以外の複数個の決済端末のそれぞれに送信し、
   サーバから完了情報を受信した複数個の決済端末のそれぞれは、
   当該完了情報に関する識別情報及び修正情報をエラー修正テーブルから削除する、
   請求項１又は２の決済システム。
4. 決済システムは、
   複数個の決済端末を備えており、
   複数個の決済端末のそれぞれは、サーバと通信可能に接続されており、
   サーバは、
   生成されたエラー修正テーブルと、特定の決済端末にのみ特定の決済媒体に関する決済エラーの修正を許可することを示す許可情報と、を複数個の決済端末のそれぞれに送信し、
   特定の決済端末は、特定の決済媒体を検出すると、特定の決済媒体の記憶内容を修正し、
   特定の決済端末以外の複数個の決済端末のそれぞれは、特定の決済媒体を検出しても、特定の決済媒体の記憶内容を修正しない、
   請求項１又は２の決済システム。
5. 特定の決済端末以外の複数個の決済端末のそれぞれは、特定の決済媒体が検出される場合に、特定の決済端末で決済エラーの修正が可能であることを特定の決済媒体のユーザに報知するための報知動作を行う、
   請求項４の決済システム。
   

Images