JP6365284B2 - 決済システム - Google Patents

Description

本明細書で開示する技術は、決済システムに関する。

一般的に、自動販売機等の機器では、当該機器で販売された商品に関する情報（商品種類、販売数量等）が管理される。特許文献１には、自動販売機と、携帯電話と、センタ装置とを備える自動販売機の情報収集システムが開示されている。自動販売機は、当該自動販売機で販売された商品に関する情報を含む画像情報を生成し、自動販売機に設けられた画像情報表示部に表示させる。携帯電話は、内蔵の撮像装置によって画像情報を撮像し、撮像した画像情報をセンタ装置に供給する。センタ装置は、携帯電話から取得した画像情報に所定の処理を施し、画像情報に含まれる情報を抽出する。これによって、センタ装置は、自動販売機で販売された商品に関する情報を管理する。

特開２００３−８５６２５号公報

自動販売機のような商品を販売する機器には、商品販売の決済（即ち電子決済）を行うための決済端末が搭載される場合がある。決済端末が搭載された機器では、商品情報の管理とは別に、決済端末に特有の問題が生じる。すなわち、決済端末が搭載された機器においては、特定の条件下で、決済端末が決済を実行不可能なエラー状態となることがある。このため、決済端末がエラー状態であるか否かを判断し、決済端末がエラー状態である場合に、そのエラー状態を解消する必要がある。特許文献１の技術では、自動販売機等に決済端末が搭載されることを想定していない。即ち、特許文献１には、決済端末がエラー状態であるか否かをどのように判断し、決済端末がエラー状態である場合に、そのエラー状態をどのように解消するのか、については開示も示唆もされていない。

本明細書では、商品を販売する機器に搭載された決済端末のエラー状態を適切に検知して解消することができる技術を提供する。

本明細書が開示する決済システムは、商品を販売する機器に搭載され、商品販売の決済を行うための決済端末と、決済端末を管理するための管理装置とを備える。管理装置は、決済端末から、決済端末における決済実績を示す情報を含む決済端末情報を取得し、決済端末情報に基づいて、決済端末が、決済を実行不可能な状態であるエラー状態であるか否かを判断し、決済端末がエラー状態であると判断する場合に、決済端末にエラー状態の解消のための第１処理を実行させるための第１指示情報を決済端末に供給する。決済端末は、第１指示情報に従って第１処理を実行する。

この構成によると、管理装置は、決済端末から取得した決済端末情報に基づいて、決済端末がエラー状態であると判断すると、決済端末に第１指示情報を供給する。決済端末は、管理装置から供給された第１指示情報に従って第１処理を実行する。従って、決済端末は、決済端末情報を出力するが、決済端末（即ち商品を販売する機器側）自身がエラー状態であることを判断することはない。このため、決済端末に不正（例えば故意に自機をエラー状態であると判断させる、エラー状態であることを不正な手順により解消する（例えば、決済情報のメモリからの不正な削除）等）が行われるリスクは低減される。また、管理装置は、決済端末情報に基づいてエラー状態であると判断する場合、決済端末のエラー状態を解消するための第１指示情報を決済端末に供給するため、決済端末はエラー状態を適切に検知して解消することができる。

決済システム２の構成を模式的に示す図。 決済端末１０の制御部１２が実行する決済端末処理を示すフローチャート。 携帯端末３０の制御部３２が実行する携帯端末処理を示すフローチャート。 サーバ５０の制御部５２が実行するサーバ処理を示すフローチャート。 決済システム２が実行する処理の具体例を示すシーケンスチャート。

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

（特徴１）決済端末は、決済端末側表示部を有していてもよい。決済端末は、決済端末情報を記録した情報コードを決済端末側表示部に表示させてもよい。管理装置は、決済端末側表示部に表示された情報コードを読み取ることによって決済端末情報を取得してもよい。

この構成によると、管理装置は、決済端末と通信を行うことなく、決済端末情報を取得することができる。管理装置は、決済端末と管理装置との間の通信環境に関わらず、決済端末情報を取得することができる。

（特徴２）管理装置は、決済端末との間で無線通信を行うことによって決済端末情報を取得してもよい。

この構成によると、管理装置は、決済端末との間で有線通信を実行可能な環境が存在しない場合であっても、決済端末情報を取得することができる。

（特徴３）管理装置は、ユーザが携帯する携帯端末と、携帯端末と通信可能なサーバとを含んでいてもよい。携帯端末は、決済端末情報を取得し、決済端末情報に基づいて、決済端末がエラー状態であるか否かを判断してもよい。サーバは、携帯端末によって、決済端末がエラー状態であると判断される場合に第１指示情報を決済端末に供給してもよい。

この構成によると、携帯端末とサーバとに管理装置の機能を分散させることができる。この構成では、携帯端末が第１指示情報を記憶していなくてもよい。そのため、仮に無関係の第三者が携帯端末を持ち去る等の事態が生じた場合であっても、第１指示情報が第三者に不正に利用されることを防止することができる。

（特徴４）携帯端末は、携帯端末側表示部を備えていてもよい。携帯端末は、決済端末情報に基づいて、決済端末が、決済を実行不可能な状態に近い状態であるエラー予備状態であるか否かをさらに判断し、決済端末がエラー予備状態であると判断する場合に、携帯端末側表示部に、エラー予備状態を解消するか否かをユーザに選択させるための選択画面を表示させてもよい。サーバは、選択画面が携帯端末側表示部に表示されている間に、ユーザによって、エラー予備状態を解消することが選択される場合に、決済端末にエラー予備状態の解消のための第２処理を実行させるための第２指示情報を決済端末に供給してもよい。決済端末は、第２指示情報に従って第２処理を実行してもよい。

この構成によると、決済端末がエラー予備状態である場合に、ユーザが、選択画面において、エラー予備状態を解消することを選択することによって、決済端末のエラー予備状態を解消することができる。ユーザの選択に従って適切にエラー予備状態を解消することができる。

（第１実施例）
（システム構成；図１）
図１に示す決済システム２は、自動販売機４において電子マネーを用いた決済を行うためのシステムである。決済システム２は、自動販売機４と、中継局８と、携帯端末３０と、サーバ５０と、マネーセンタ６０、７０を備える。

（自動販売機４の構成）
自動販売機４は、商品を販売するための機器である。自動販売機４には、電子決済に対応可能な決済端末１０が搭載されている。決済端末１０は、制御部１２と、操作部１４と、メモリ１６と、ＮＦＣ（Near Field Communicationの略）インターフェース（Ｉ／Ｆ）１８と、表示部２０と、無線Ｉ／Ｆ２２を備える。図１では、自動販売機４を１台のみ図示しているが、実際は、自動販売機４は複数台備えられている。

制御部１２は、メモリ１６内のプログラムに従って様々な処理（例えば図２の決済端末処理等）を実行する。制御部１２が実行する処理の内容は後で詳しく説明する。

メモリ１６は、様々なプログラムを記憶している。また、メモリ１６は、決済端末１０に固有の識別情報（例えば、決済端末１０の製造番号）を記憶している。メモリ１６は、識別情報の他に、自動販売機４の設置場所を示す場所情報、決済端末１０でこれまでに行った決済実績に関係する実績情報等を記憶している。実績情報は、複数種類の電子マネーのそれぞれについて、電子マネー種類（Ｍ１、Ｍ２等）、決済時刻、決済金額、決済件数、決済累計額、決済上限値（即ち、上限決済回数）、電子マネー有効期限、等の各情報を含む。以下では、上記の識別情報、場所情報、実績情報等を含む各情報のことを「決済端末情報」と呼ぶ場合がある。

操作部１４は、複数のキーを備える。自動販売機４の利用者（例えば、自動販売機４で販売する商品を補充する作業員）は、操作部１４を操作して、決済端末１０に様々な情報を入力することができる。表示部２０は、様々な情報（例えば、上記の決済端末情報を記録した情報コード等）を表示する。

ＮＦＣＩ／Ｆ１８は、電子マネーを利用可能なＩＣカードや携帯電話機等の決済媒体８０や、その他のＮＦＣ通信（近距離無線通信）対応機器との間でＮＦＣ通信を実行するためのインターフェースである。

無線Ｉ／Ｆ２２は、中継局８を介して、インターネット６に接続されている各装置（即ちサーバ５０、マネーセンタ６０、７０等）との間で無線通信を実行するためのインターフェースである。

（携帯端末３０の構成）
携帯端末３０は、例えば、自動販売機４で販売する商品を自動販売機４に補充する作業員によって携帯される端末である。携帯端末３０は、制御部３２と、操作部３４と、メモリ３６と、読取部３８と、無線Ｉ／Ｆ４０と、表示部４２を備える。なお、図１では、携帯端末３０に破線で図示されたＮＦＣＩ／Ｆ４４が備えられているように図示されているが、本実施例の携帯端末３０には備えられていない。ＮＦＣＩ／Ｆ４４は、後述の第２実施例の携帯端末３０に備えられる。図１では、携帯端末３０を１台のみ図示しているが、携帯端末３０は、複数台備えられていてもよい。

制御部３２は、メモリ３６内のプログラムに従って様々な処理（例えば図３の携帯端末処理等）を実行する。制御部３２が実行する処理の内容は後で詳しく説明する。メモリ３６は、様々なプログラムを記憶している。

操作部３４は、複数のキーを備える。携帯端末３０の利用者（例えば、作業者）は、操作部３４を操作して、携帯端末３０に様々な情報を入力することができる。表示部４２は、様々な情報を表示する。

読取部３８は、情報コード（例えば、決済端末１０の表示部２０に表示された情報コード）を読み取り可能である。読取部３８には、情報コードを撮影するための撮影装置が内蔵されている。携帯端末３０の使用者（例えば作業者）は、操作部３４を操作し、情報コード（例えば、決済端末１０の表示部２０に表示された情報コード）を読み取るための読取操作を行うことができる。読取操作が行われると、読取部３８は、情報コードを撮影する。読取部３８が撮影した情報コードのパターンを制御部３２が解析することによって、制御部３２は、情報コードに記録された情報を取得することができる。

無線Ｉ／Ｆ４０は、中継局８を介して、インターネット６に接続されている各装置（即ちサーバ５０、マネーセンタ６０、７０等）との間で無線通信を実行するためのインターフェースである。

（中継局８の構成）
中継局８は、インターネット６に接続されている。中継局８は、決済端末１０及び携帯端末３０と、インターネット６に接続されている各装置（即ちサーバ５０、マネーセンタ６０、７０等）との間の無線通信を仲介する。中継局８が無線通信を仲介することにより、決済端末１０及び携帯端末３０がインターネット６と有線接続できない環境にある場合であっても、決済端末１０及び携帯端末３０は、サーバ５０、マネーセンタ６０、７０等との間で適切に通信を実行することができる。

（サーバ５０の構成）
サーバ５０は、決済端末１０を管理するためのサーバである。サーバ５０は、例えば、決済端末１０及び携帯端末３０のベンダによって設置される。サーバ５０は、インターネット６と有線接続されている。

サーバ５０は、制御部５２とメモリ５４を備えている。制御部５２は、メモリ５４内のプログラムに従って様々な処理を実行する。制御部５２が実行する処理の内容は後で詳しく説明する。メモリ５４は、様々なプログラムを記憶している。

（マネーセンタ６０、７０の構成）
マネーセンタ６０、７０は、電子マネーの種類（Ｍ１、Ｍ２等）毎に、当該電子マネーを用いた電子決済に関する各種情報を管理するサーバである。マネーセンタ６０、７０は、電子マネーの種類（Ｍ１、Ｍ２等）毎に設置されており、互いに同様の構成を有している。マネーセンタ６０、７０は、それぞれ、インターネット６に有線接続されている。図１の例では、マネーセンタ６０、７０のみを図示しているが、他の例では、決済システム２は、マネーセンタ６０、７０以外の他のマネーセンタ（図示しない）を有していてもよい。本実施例では、マネーセンタ６０、７０は、それぞれ、電子マネーの種類Ｍ１、Ｍ２に対応している。即ち、例えば、マネーセンタ６０は、決済端末１０との間で、中継局８を介して、決済端末１０で行われる電子マネー（種類Ｍ１）を用いた決済に関する情報を通信可能である。なお、本明細書では、種類Ｍ１の電子マネー、種類Ｍ２の電子マネーのことを、それぞれ、電子マネーＭ１、電子マネーＭ２、と呼ぶ場合がある。

次いで、図２〜図４を参照して、決済端末１０のメンテナンスのために、決済端末１０の制御部１２、携帯端末３０の制御部３２、及び、サーバ５０の制御部５２、のそれぞれが実行する処理の内容を説明する。なお、本実施例において「決済端末１０のメンテナンス」とは、決済端末１０における電子決済を実行可能な状態を保全することを意味する。

（決済端末１０の制御部１２が実行する決済端末処理；図２）
図２を参照して、決済端末１０のメンテナンスのために、決済端末１０の制御部１２が実行する決済端末処理の内容を説明する。決済端末１０の電源がＯＮされている間、制御部１２は、Ｓ１０において、所定のメンテナンス開始操作が入力されることを監視する。決済端末１０の使用者（例えば作業者）は、操作部１４を操作し、メンテナンス開始操作を入力することができる。メンテナンス開始操作が入力されると、制御部１２は、Ｓ１０でＹＥＳと判断し、Ｓ１２に進む。

Ｓ１２では、制御部１２は、メモリ１６に記憶されている決済端末情報（即ち、識別情報、場所情報、実績情報等）が記録された情報コードを生成し、生成した情報コードを表示部２０に表示させる。

次いで、Ｓ１４、Ｓ１５において、制御部１２は、Ｓ１２で情報コードを表示させてから所定期間が経過するまでの間に、サーバ５０からシナリオファイルを取得することを監視する。

後で詳しく説明するように、決済端末１０が決済を実行不可能な状態であるエラー状態である場合（図３のＳ３４でＹＥＳ）、又は、決済端末１０が決済を実行不可能な状態に近い状態であるエラー予備状態であって、作業者によってエラー予備状態を解消することが選択された場合（図３のＳ３４でＮＯ、Ｓ３６でＹＥＳ、Ｓ４０でＹＥＳ）のいずれかの場合、サーバ５０は、エラー状態若しくはエラー予備状態を解消するためのシナリオファイルを決済端末１０に供給する（図４のＳ６４）。このため、制御部１２は、Ｓ１４、Ｓ１５において、サーバ５０からシナリオファイルを受信するか否かを監視する。

ここで、エラー状態及びエラー予備状態について説明する。エラー状態は、上記の通り、決済端末１０が決済を実行不可能な状態である。例えば、メモリ１６に記憶されている電子マネーＭ１の決済件数が決済上限値を超える場合（いわゆる「ログフル状態」）、決済端末１０は電子マネーＭ１を用いた決済をこれ以上実行することができない。また、例えば、メモリ１６に記憶されている電子マネーＭ１の有効期限を徒過している場合（いわゆる「有効期限切れ状態」）も、決済端末１０は電子マネーＭ１を用いた決済を実行することができない。上記の各例のような状態をエラー状態と呼ぶ。

エラー予備状態は、上記の通り、決済端末１０が決済を実行不可能な状態に近い状態である。例えば、メモリ１６に記憶されている電子マネーＭ１の決済件数が決済上限値の７０％を超えている場合（いわゆる「ニアフル状態」）、決済端末１０は電子マネーＭ１を用いた決済を実行できない状態に近づいていると言える。また、例えば、メモリ１６に記憶されている電子マネーＭ１の有効期限が残り３日以下である場合（いわゆる「有効期限間近状態」）も、決済端末１０は電子マネーＭ１を用いた決済を実行できない状態に近づいていると言える。上記の各例のような状態をエラー予備状態と呼ぶ。

制御部１２は、Ｓ１２で情報コードを表示させてから所定期間が経過するまでの間に、サーバ５０からシナリオファイルを取得すると、Ｓ１４でＹＥＳと判断し、Ｓ１６に進む。一方、制御部１２は、サーバ５０からシナリオファイルを取得することなく、Ｓ１２で情報コードを表示させてから所定期間が経過する場合、Ｓ１５でＹＥＳと判断し、図２の決済端末処理を終了する。ここで、Ｓ１５でＹＥＳと判断される場合は、決済端末１０がエラー状態とエラー予備状態のいずれでもない場合（図３のＳ３６でＮＯ）と、決済端末１０がエラー予備状態であるが、作業者によってこの時点ではエラー予備状態を解消しないことが選択された場合（図３のＳ３６でＹＥＳ、Ｓ４０でＮＯ）と、のいずれかの場合である。

Ｓ１６では、制御部１２は、取得したシナリオファイルに含まれる指示に従って、エラー状態及びエラー予備状態を解消するためのリカバリ処理を実行する。

例えば、決済端末１０が、電子マネーＭ１がログフル状態であることに起因するエラー状態である場合、シナリオファイルには、電子マネーＭ１のログ報告処理を行うための指示が含まれている。この場合、制御部１２は、シナリオファイルに含まれる指示に従って、マネーセンタ６０と通信を行い、メモリ１６内の電子マネーＭ１を用いた決済に関する情報（決済時刻、決済金額、決済件数、決済累計額等）をマネーセンタ６０に供給する。その後、制御部１２は、メモリ１６に記憶されている電子マネーＭ１を用いた決済に関する情報をメモリ１６から削除する。これにより、決済端末１０は再び電子マネーＭ１を用いた決済を実行可能な状態に戻る。この場合、制御部１２が実行する上記の一連の処理（即ちログ報告処理）がリカバリ処理の一例である。

同様に、例えば、決済端末１０が、電子マネーＭ１がニアフル状態であることに起因するエラー予備状態である場合にも、シナリオファイルには、電子マネーＭ１のログ報告処理を行うための指示が含まれている。この場合も、制御部１２は上記のログ報告処理を実行する。この場合に実行されるログ報告処理もリカバリ処理の一例である。

また、例えば、決済端末１０が、電子マネーＭ２が有効期限切れ状態であることに起因するエラー状態である場合、シナリオファイルには、電子マネーＭ２の有効期限更新処理を行うための指示が含まれている。この場合、制御部１２は、シナリオファイルに含まれる指示に従って、マネーセンタ７０と通信を行い、電子マネーＭ２の有効期限の更新リクエストをマネーセンタ７０に供給する。次いで、制御部１２は、マネーセンタ７０から、電子マネーＭ２の新たな有効期限を示す情報を取得する。制御部１２は、メモリ１６に記憶されている有効期限を、マネーセンタ７０から取得した情報が示す新たな有効期限に書き換える。これにより、決済端末１０は再び電子マネーＭ２を用いた決済を実行可能な状態に戻る。この場合、制御部１２が実行する上記の一連の処理（即ち有効期限更新処理）がリカバリ処理の一例である。

同様に、例えば、決済端末１０が、電子マネーＭ２が有効期限間近状態であることに起因するエラー予備状態である場合にも、シナリオファイルには、電子マネーＭ２の有効期限更新処理を行うための指示が含まれている。この場合も、制御部１２は上記の有効期限更新処理を実行する。この場合に実行される有効期限更新処理もリカバリ処理の一例である。

また、例えば、決済端末１０が、電子マネーＭ１がログフル状態であることに起因するエラー状態であるとともに、電子マネーＭ２が有効期限切れ状態であることに起因するエラー状態でもある場合には、シナリオファイルには、電子マネーＭ１のログ報告処理を行うための指示と、電子マネーＭ２の有効期限更新処理を行うための指示と、が含まれる。このような場合、制御部１２は、電子マネーＭ１のログ報告処理を行うとともに、電子マネーＭ２の有効期限更新処理を行う。この場合に実行される各処理もリカバリ処理の一例である。

Ｓ１６でリカバリ処理を実行すると、Ｓ１８に進む。Ｓ１８では、制御部１２は、リカバリ処理の結果を表示部２０に表示する。Ｓ１６で実行されたリカバリ処理（即ち、ログ報告処理、有効期限更新処理）が成功した場合、Ｓ１８では、制御部１２は、リカバリ処理が成功したことを示す情報を表示部２０に表示する。一方、Ｓ１６で実行されたリカバリ処理が失敗した場合、Ｓ１８では、制御部１２は、リカバリ処理が失敗したことを示す情報を表示部２０に表示する。リカバリ処理が失敗する場合とは、例えば、決済端末１０と中継局８との間の通信状態が悪く、決済端末１０がマネーセンタ６０、７０等との間で通信を完全に行うことができないために、リカバリ処理を行うことができなかった場合である。Ｓ１８を終えると、制御部１２は、再びＳ１０に戻り、メンテナンス開始操作が入力されることを監視する。

（携帯端末３０の制御部３２が実行する携帯端末処理；図３）
続いて、図３を参照して、決済端末１０のメンテナンスのために、携帯端末３０の制御部３２が実行する携帯端末処理の内容を説明する。携帯端末３０の電源がＯＮされている間、制御部１２は、Ｓ３０において、決済端末情報が取得されることを監視する。即ち、携帯端末３０の使用者（例えば作業者）は、操作部３４を操作し、決済端末１０の表示部２０に表示される情報コード（図２のＳ１２）を読み取るための読取操作を行うことができる。読取操作が行われると、読取部３８が、決済端末１０の表示部２０に表示されている情報コードを撮影する。制御部３２は、読取部３８が撮影した情報コードのパターンを解析し、情報コードに記録された決済端末情報を取得することができる。この場合、制御部３２は、Ｓ３０でＹＥＳと判断し、Ｓ３２に進む。

Ｓ３２では、制御部３２は、決済端末１０がエラー状態であるか否かを判断する。具体的には、制御部３２は、取得された決済端末情報に基づいて、電子マネーの種類毎に、エラー状態が発生しているか否かを判断する。例えば、電子マネーＭ１の決済件数が決済上限値を超えている場合（即ちログフル状態）や、電子マネーＭ１の有効期限が徒過している場合（即ち有効期限切れ状態）には、制御部３２は、決済端末１０はエラー状態であると判断し（即ちＳ３２でＹＥＳと判断し）、Ｓ４０に進む。一方、決済端末１０がエラー状態でない場合、制御部３２は、Ｓ３２でＮＯと判断し、Ｓ３４に進む。

Ｓ３４では、制御部３２は、決済端末１０がエラー予備状態であるか否かを判断する。具体的には、制御部３２は、取得された決済端末情報に基づいて、電子マネーの種類毎に、エラー予備状態が発生しているか否かを判断する。例えば、電子マネーＭ１の決済件数が決済上限値の７０％を超えている場合（即ちニアフル状態）や、電子マネーＭ１の有効期限が残り３日以下である場合（即ち有効期限間近状態）には、制御部３２は、決済端末１０はエラー予備状態であると判断し（即ちＳ３４でＹＥＳと判断し）、Ｓ３６に進む。一方、決済端末１０がエラー予備状態でない場合、制御部３２は、Ｓ３４でＮＯと判断し、再びＳ３０に戻り、決済端末情報を取得することを監視する。

Ｓ３６では、制御部３２は、携帯端末３０の使用者（即ち作業者）に、決済端末１０のエラー予備状態を解消するか否かを選択させるための選択画面を表示部２０に表示させる。携帯端末３０の使用者は、表示部２０に選択画面が表示されている間に、操作部３４を操作して、決済端末１０のエラー予備状態を解消するか、解消しないかを選択することができる。

続くＳ３８では、制御部３２は、選択画面において、決済端末１０のエラー予備状態を解消することが選択されたか否かを判断する。エラー予備状態を解消することが選択された場合、制御部３２は、Ｓ３８でＹＥＳと判断し、Ｓ４０に進む。一方、エラー予備状態を解消しないことが選択された場合、制御部３２は、Ｓ３８でＮＯと判断し、再びＳ３０に戻り、決済端末情報を取得することを監視する。

Ｓ４０では、制御部３２は、リクエストファイルを生成する。リクエストファイルには、決済端末１０の識別情報、場所情報に加え、エラー状態又はエラー予備状態の原因である電子マネーの種類（Ｍ１、Ｍ２等）を示す情報、及び、エラー状態又はエラー予備状態の内容（ログフル状態、有効期限切れ状態、ニアフル状態、有効期限間近状態等）を示す情報が含まれる。

Ｓ４２では、制御部３２は、Ｓ４０で生成したリクエストファイルを、サーバ５０に供給する。Ｓ４２を終えると、制御部３２は、再びＳ３０に戻り、決済端末情報を取得することを監視する。

（サーバ５０の制御部５２が実行するサーバ処理；図４）
続いて、図４を参照して、決済端末１０のメンテナンスのために、サーバ５０の制御部５２が実行するサーバ処理の内容を説明する。制御部５２は、Ｓ６０において、携帯端末３０からリクエストファイルを取得することを監視する。上記の通り、携帯端末３０は、所定の場合（図３のＳ３２でＹＥＳ、又は、Ｓ３８でＹＥＳ）において、サーバ５０にリクエストファイルを供給する。その場合、制御部５２は、リクエストファイルを取得し、Ｓ６０でＹＥＳと判断し、Ｓ６２に進む。

Ｓ６２では、制御部５２は、リクエストファイルに含まれる各情報に基づいて、シナリオファイルを生成する。シナリオファイルには、エラー状態又はエラー予備状態である決済端末１０がリカバリ処理を実行するための指示が含まれる。具体的に言うと、制御部５２は、リクエストファイルに含まれるエラー状態又はエラー予備状態の原因である電子マネーの種類（Ｍ１、Ｍ２等）を示す情報と、エラー状態又はエラー予備状態の内容（例えば、ログフル状態、有効期限切れ状態、ニアフル状態、有効期限間近状態等）を示す情報とに基づいて、決済端末１０にリカバリ処理（例えば、電子マネーＭ１のログ報告処理、電子マネーＭ２の有効期限更新処理、等）を実行させるための指示を生成する。次いで、制御部５２は、生成した指示を含むシナリオファイルを生成する。

続くＳ６４では、制御部５２は、Ｓ６２で生成したシナリオファイルを、エラー状態又はエラー予備状態である決済端末１０に供給する。具体的に言うと、制御部５２は、リクエストファイルに含まれる識別情報及び場所情報に基づいて、エラー状態又はエラー予備状態である決済端末１０を特定し、特定した決済端末１０を宛先として、シナリオファイルを供給する。Ｓ６４を終えると、制御部５２は、再びＳ６０に戻り、リクエストファイルを取得することを監視する。

（具体例；図５）
図５を参照して、決済端末１０のメンテナンスを行う場合における各装置の動作の具体例について説明する。この例では、決済端末１０が、電子マネーＭ１のログフル状態であることに起因するエラー状態である場合を想定して説明する。

決済端末１０のメンテナンスを行う場合、作業者は、決済端末１０の操作部１４を操作し、所定のメンテナンス開始操作を決済端末１０に入力する（図２のＳ１０でＹＥＳ）。

決済端末１０は、メンテナンス開始操作が入力されると、メモリ１６に記憶されている決済端末情報が記録された情報コードを表示部２０に表示させる（図２のＳ１２）。

次いで、作業者は、携帯端末３０の操作部３４を操作し、決済端末１０の表示部２０に表示された情報コードを読み取るための読取操作を行う。

読取操作が行われると、携帯端末３０は、決済端末１０の表示部２０に表示された情報コードを撮影する。携帯端末３０は、撮影された情報コードのパターンを解析し、情報コードに記録された決済端末情報を取得する（図３のＳ３０でＹＥＳ）。次いで、携帯端末３０は、取得した決済端末情報に基づいて、決済端末１０が、電子マネーＭ１のログフル状態であることに起因するエラー状態であると判断する（Ｓ３２でＹＥＳ）。次いで、携帯端末３０は、リクエストファイルを生成する。リクエストファイルには、決済端末１０の識別情報、場所情報に加え、エラー状態の原因である電子マネーの種類（即ちＭ１）を示す情報、及び、エラー状態の内容（即ちログフル状態）を示す情報が含まれる。次いで、携帯端末３０は、生成したリクエストファイルをサーバ５０に供給する（図３のＳ４２）。

サーバ５０は、携帯端末３０からリクエストファイルを取得する（図４のＳ６０でＹＥＳ）。次いで、サーバ５０は、取得したリクエストファイルに含まれる各情報に基づいて、シナリオファイルを生成する（Ｓ６２）。この例で生成されるシナリオファイルは、決済端末１０に電子マネーＭ１のログ報告処理（即ちリカバリ処理）を実行させるための指示を含む。次いで、サーバ５０は、生成したシナリオファイルを決済端末１０に供給する（Ｓ６４）。

決済端末１０は、サーバ５０からシナリオファイルを取得する（図２のＳ１４でＹＥＳ）。次いで、決済端末１０は、シナリオファイルに含まれる指示に従って、エラー状態を解消するためのリカバリ処理を実行する（Ｓ１６）。上記の通り、シナリオファイルには、決済端末１０に電子マネーＭ１のログ報告処理を実行させるための指示が含まれている。そのため、決済端末１０は、マネーセンタ６０と通信を行い、メモリ１６内の電子マネーＭ１を用いた決済に関する情報（決済時刻、決済金額、決済件数、決済累計額等）をマネーセンタ６０に供給する。

マネーセンタ６０は、決済端末１０から電子マネーＭ１を用いた決済に関する情報を取得すると、決済端末１０に完了通知を供給する。

決済端末１０は、完了通知を取得すると、メモリ１６に記憶されている電子マネーＭ１を用いた決済に関する情報をメモリ１６から削除する。これにより、決済端末１０は再び電子マネーＭ１を用いた決済を実行可能な状態に戻る。次いで、決済端末１０は、リカバリ処理が成功したことを示す情報を表示部２０に表示させる（図２のＳ１８）。

各装置が上記の各動作を行うことにより、決済端末１０のメンテナンスが完了する。

以上、本実施例の決済システム２について説明した。上記の通り、本実施例の決済システム２では、携帯端末３０は、情報コードを読み取ることによって決済端末１０から取得した決済端末情報に基づいて、決済端末１０がエラー状態であると判断すると（図３のＳ３２でＹＥＳ）、リクエストファイルを生成し、サーバ５０に供給する（Ｓ４０、Ｓ４２）。サーバ５０は、リクエストファイルを取得すると、リクエストファイルに含まれる各情報に基づいてシナリオファイルを生成し、決済端末１０に供給する（図４のＳ６２、Ｓ６４）。決済端末１０は、サーバ５０から供給されたシナリオファイルに含まれる指示に従ってリカバリ処理を実行する（図２のＳ１６）。従って、決済端末１０は、決済端末情報を出力するが、決済端末１０（即ち自動販売機４側）自身がエラー状態であることを判断することはない。そのため、決済端末１０に不正（例えば、故意に自機をエラー状態であると判断させる、エラー状態であることを不正な手順により解消する（例えば、決済情報のメモリからの不正な削除）等）が行われるリスクが低減される。また、携帯端末３０によって決済端末１０がエラー状態と判断される場合に、サーバ５０は、決済端末１０のエラー状態を解消するためのシナリオファイルを決済端末１０に供給するため、決済端末１０はエラー状態を適切に検知して解消することができる。

上記の実施例では、決済端末１０は、決済端末情報を記録した情報コードを表示部２０に表示させる（図２のＳ１２）。携帯端末３０は、表示部２０に表示された情報コードを読み取ることによって決済端末情報を取得する（図３のＳ３０でＹＥＳ）。そのため、携帯端末３０は、決済端末１０と通信を行うことなく、決済端末情報を取得することができる。携帯端末３０は、決済端末１０との間の通信環境に関わらず、決済端末情報を適切に取得することができる。

また、上記の実施例では、携帯端末３０が決済端末情報を取得し、決済端末情報に基づいて、決済端末１０がエラー状態であるか否かを判断する（図３参照）。サーバ５０は、携帯端末３０によって、決済端末１０がエラー状態であると判断される場合に、シナリオファイルを決済端末１０に供給する（図４参照）。即ち、決済端末情報を取得する機能と、決済端末１０がエラー状態であるか否かを判断する機能と、シナリオファイルを決済端末１０に供給する機能とが、携帯端末３０とサーバ５０とに分散されている。そのため、携帯端末３０がシナリオファイルを記憶していなくてもよい。そのため、仮に無関係の第三者が携帯端末を持ち去る等の事態が生じた場合であっても、シナリオファイルが第三者に不正に利用されることを防止することができる。

また、上記の実施例では、携帯端末３０は、決済端末情報に基づいて、決済端末１０がエラー状態であるか否かに加え、決済端末１０がエラー予備状態であるか否かをさらに判断する（図３のＳ３４）。携帯端末３０は、決済端末１０がエラー予備状態であると判断すると（Ｓ３４でＹＥＳ）、決済端末１０のエラー予備状態を解消するか否かを選択させるための選択画面を表示部４２に表示させる（Ｓ３６）。携帯端末３０は、エラー予備状態を解消することが選択された場合（Ｓ３８でＹＥＳ）に、リクエストファイルを生成してサーバ５０に供給する（Ｓ４０、Ｓ４２）。サーバ５０は、決済端末１０にエラー予備状態の解消のためのリカバリ処理を実行させるためのシナリオファイルを決済端末１０に供給する（図４のＳ６４）。そのため、決済端末１０がエラー予備状態である場合に、携帯端末３０の使用者（作業者）が、選択画面において、エラー予備状態を解消することを選択することによって、決済端末１０のエラー予備状態を解消することができる。ユーザの選択に従って適切にエラー予備状態を解消することができる。

上記の実施例と請求項の記載との対応関係を説明しておく。携帯端末３０とサーバ５０が「管理装置」の一例である。決済端末１０のエラー状態を解消するためのリカバリ処理が「第１処理」の一例である。決済端末１０がエラー状態である場合にサーバ５０が決済端末１０に供給するシナリオファイルが「第１指示情報」の一例である。決済端末１０のエラー予備状態を解消するためのリカバリ処理が「第２処理」の一例である。決済端末１０がエラー予備状態である場合にサーバ５０が決済端末１０に供給するシナリオファイルが「第２指示情報」の一例である。

（第２実施例）
第１実施例と異なる点を中心に説明する。本実施例では、図１に示すように、携帯端末３０は、ＮＦＣＩ／Ｆ４４をさらに備えている点が第１実施例とは異なる。即ち、本実施例では、携帯端末３０は、ＮＦＣＩ／Ｆ４４と決済端末１０のＮＦＣＩ／Ｆ１８を介して、決済端末１０との間でＮＦＣ通信を実行することができる。

上記の第１実施例では、携帯端末３０は、決済端末１０は、決済端末情報を記録した情報コードを表示部２０に表示させる（図２のＳ１２）。携帯端末３０は、表示部２０に表示された情報コードを読み取ることによって決済端末情報を取得する（図３のＳ３０でＹＥＳ）。これに代えて、本実施例では、携帯端末３０は、決済端末１０との間でＮＦＣ通信を実行することによって、決済端末１０から決済端末情報を取得する。携帯端末３０が決済端末情報を取得した後の各装置の動作は第１実施例と同様である。

本実施例によると、携帯端末３０は、決済端末１０との間で有線通信を実行可能な環境が存在しない場合であっても、決済端末情報を取得することができる。

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

（変形例１）上記の第１実施例では、携帯端末３０が、決済端末１０の表示部２０に表示された情報コードを読み取ることによって決済端末情報を取得し、決済端末情報に基づいて、決済端末１０がエラー状態であるか否かを判断する（図３参照）。これに限られず、携帯端末３０は、決済端末１０の表示部２０に表示された情報コードを撮影し、撮影した情報コードの画像をそのままサーバ５０に供給してもよい。サーバ５０は、携帯端末３０から情報コードの画像を取得し、情報コードのパターンを分析して決済端末情報を取得してもよい。さらに、サーバ５０が、決済端末情報に基づいて、決済端末１０がエラー状態であるか否かを判断してもよい。即ち、携帯端末３０は情報コードの撮影をのみを行い、サーバ５０が、決済端末情報の取得と決済端末１０がエラー状態であるか否かの判断をしてもよい。

（変形例２）また、携帯端末３０が、決済端末情報を取得した後、決済端末１０がエラー状態であるか否かの判断を行わずに、取得した決済端末情報をそのままサーバ５０に供給してもよい。サーバ５０は、携帯端末３０から決済端末情報を取得し、決済端末情報に基づいて、決済端末１０がエラー状態であるか否かを判断してもよい。

（変形例３）上記の各実施例では、携帯端末３０とサーバ５０が別個に設けられている。これに代えて、携帯端末３０の機能とサーバ５０の機能を両方備える一つの管理装置（例えば携帯型の管理装置）が設けられていてもよい。この変形例では、管理装置は、決済端末情報の取得、決済端末１０がエラー状態であるか否かの判断、シナリオファイルの生成及び供給を全て行ってもよい。

（変形例４）上記の各実施例では、携帯端末３０は、決済端末１０がエラー予備状態であると判断すると（Ｓ３４でＹＥＳ）、決済端末１０のエラー予備状態を解消するか否かを選択させるための選択画面を表示部４２に表示させる（Ｓ３６）。携帯端末３０は、エラー予備状態を解消することが選択された場合（Ｓ３８でＹＥＳ）に、リクエストファイルをサーバ５０に供給する（Ｓ４２）。これに代えて、携帯端末３０は、決済端末１０がエラー予備状態であると判断する場合に、選択画面を表示部４２に表示させることなく、リクエストファイルをサーバ５０に供給してもよい。

（変形例５）また、携帯端末３０は、決済端末１０がエラー状態であるか否かの判断のみを行い、決済端末１０がエラー予備状態であるか否かの判断を行わないようにしてもよい。

（変形例６）上記の各実施例では、サーバ５０は、決済端末１０がエラー状態又はエラー予備状態である場合に、当該決済端末１０にシナリオファイルを供給する。これに限られず、サーバ５０は、決済端末１０がエラー状態又はエラー予備状態である場合に、当該決済端末１０に加えて、決済端末１０の設置場所に近い設置場所に存在する他の決済端末に対してもシナリオファイルを供給するようにしてもよい。サーバ５０は、決済端末１０の識別情報及び場所情報に基づいて、決済端末１０と設置場所が近い他の決済端末を特定することにより、シナリオファイルを供給することができる。決済端末１０と設置場所が近い他の決済端末では、決済端末１０と同様のエラー状態又はエラー予備状態が発生している可能性がある。そのため、サーバ５０は、決済端末１０に加えて、決済端末１０の設置場所に他の決済端末に対してもシナリオファイルを供給することにより、他の決済端末で発生しているエラー状態又はエラー予備状態も解消し得る。

（変形例７）上記の各実施例では、ログフル状態、ニアフル状態の判断の基準となる決済上限値は、各電子マネーの決済件数の上限値である。これに限られず、決済上限値は、各電子マネーの決済金額の累計額の上限値であってもよい。

（変形例８）また、決済端末１０の「エラー状態」は、上記のログフル状態、有効期限切れ状態に限られず、他の任意の状態を含んでもよい。同様に、決済端末１０の「エラー予備状態」も、上記のニアフル状態、有効期限間近状態に限られず、他の任意の状態を含んでもよい。

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

２：決済システム
４：自動販売機
６：インターネット
８：中継局
１０：決済端末
１２：制御部
１４：操作部
１６：メモリ
１８：ＮＦＣＩ／Ｆ
２０：表示部
２２：無線Ｉ／Ｆ
３０：携帯端末
３２：制御部
３４：操作部
３６：メモリ
３８：読取部
４０：無線Ｉ／Ｆ
４２：表示部
４４：ＮＦＣＩ／Ｆ
５０：サーバ
５２：制御部
５４：メモリ
６０：マネーセンタ
７０：マネーセンタ
８０：決済媒体

Claims (5)

1. 商品を販売する機器に搭載され、商品販売の決済を行うための決済端末と、
   決済端末を管理するための管理装置と、
   を備える決済システムであって、
   管理装置は、
   決済端末から、決済端末における決済実績を示す情報を含む決済端末情報を取得し、
   決済端末情報に基づいて、決済端末が、決済を実行不可能な状態であるエラー状態であるか否かを判断し、
   決済端末がエラー状態であると判断する場合に、決済端末にエラー状態の解消のための第１処理を実行させるための第１指示情報を決済端末に供給し、
   決済端末は、
   第１指示情報に従って第１処理を実行する、
   決済システム。
2. 決済端末は、決済端末側表示部を有しており、決済端末情報を記録した情報コードを決済端末側表示部に表示させ、
   管理装置は、決済端末側表示部に表示された情報コードを読み取ることによって決済端末情報を取得する、
   請求項１の決済システム。
3. 管理装置は、決済端末との間で無線通信を行うことによって決済端末情報を取得する、
   請求項１の決済システム。
4. 管理装置は、ユーザが携帯する携帯端末と、携帯端末と通信可能なサーバとを含み、
   携帯端末は、決済端末情報を取得し、決済端末情報に基づいて、決済端末がエラー状態であるか否かを判断し、
   サーバは、携帯端末によって決済端末がエラー状態であると判断される場合に第１指示情報を決済端末に供給する、
   請求項１から３のいずれか一項に記載の決済システム。
5. 携帯端末は、携帯端末側表示部を備えており、
   携帯端末は、
   決済端末情報に基づいて、決済端末が、決済を実行不可能な状態に近い状態であるエラー予備状態であるか否かをさらに判断し、
   決済端末がエラー予備状態であると判断する場合に、携帯端末側表示部に、エラー予備状態を解消するか否かをユーザに選択させるための選択画面を表示させ、
   サーバは、
   選択画面が携帯端末側表示部に表示されている間に、ユーザによって、エラー予備状態を解消することが選択される場合に、決済端末にエラー予備状態の解消のための第２処理を実行させるための第２指示情報を決済端末に供給し、
   決済端末は、
   第２指示情報に従って第２処理を実行する、
   請求項４に記載の決済システム。

Images