JP5814493B1 - 管理装置、管理方法、ならびに、プログラム - Google Patents

Abstract

管理装置(14)において、保持部(102)は、リストサーバにより更改される判定リストを保持する。制御部(103)は、可搬デバイスと通信部(104)を介して通信することにより可搬デバイスを制御する。支払に供される可搬デバイスと通信部(104)が通信可能となると、制御部(103)は、可搬デバイスから、可搬デバイスのID、残額ならびに更新時を取得する。取得された残額に係る第1条件が満たされ、取得された更新時に係る第2条件が満たされ、前記取得されたIDと前記保持された判定リストとに係る第3条件が満たされると、制御部(103)は、現在を表す基準時を定め、取得された残額および所定の増分額から支払を行って可搬デバイスの残額を更新し、可搬デバイスの更新時を定められた基準時に更新し、取得されたIDに対応付けられるアカウントに対して所定の増分額に相応する課金を管理サーバに行わせるための課金レポートを生成する。

Description

本発明は、電子マネーの残額を保持する可搬デバイスに対する残額の補充や当該可搬デバイスによる支払を管理する管理装置、当該管理装置が実行する管理方法、ならびに、当該管理装置で実行されるプログラムに関する。

対価を支払うことで商品やサービスの提供を受ける取引において、電子マネーを利用するシステムが種々提案されている。電子マネーシステムでは、現金を財布に入れて持ち歩くかわりに、可搬デバイス(財布に相当する。)に対応付けられ、電子情報により表現される電子バリュー(財布の中の現金に相当する。)により、支払を行う。

電子バリューの支払の際には、支払者は、可搬デバイスを、商品やサービスの提供者が操作するリーダ/ライタに近接させることにより、短時間だけ翳して、可搬デバイスとリーダ/ライタの間でNFC(Near Field Communication;近接場通信)を確立し、この通信によって、可搬デバイスに対応付けられる電子バリューを、支払分だけ減少させる。NFCでは、可搬デバイスとリーダ/ライタは接触する必要はないが、距離を典型的には数mm程度まで近付ける必要がある。

可搬デバイスとしては、キャッシュカードやクレジットカードにNFC用の電子回路を組み込んだものが広く使われている。この電子回路は、一般的には、リーダ/ライタから発せられるNFC用の電波による電磁誘導で生じる電力によって動作する。

一方、携帯電話やスマートフォンなどの携帯端末では、上記と同様にNFC用の電子回路を内部に組み込むものも広く利用されているほか、電話通信用のSIM(Subscriber Identity Card)カード内にNFC用の通信機能を設けたものも提案されている。これらの場合には、リーダ/ライタが発した電波を電力源とすることができるほか、携帯端末の本体が備えるバッテリから電力の供給を受けることができる。

可搬デバイスに対応付けられる電子バリューの残額は、可搬デバイス内の電子回路、あるいは、電子マネーサーバにより管理され、可搬デバイスとの通信でやりとりされるコマンドや電子マネーサーバにおける処理に応じて増減する。

さて、電子バリューの残額が支払の額よりも少ないときに、可搬デバイスの所有者に明示的な問い合わせを行うことなく自動的に、可搬デバイスに対応付けられるアカウントに対して所定額の与信を行い、与信が成功したら、電子バリューの残額を当該所定額だけ増加させる技術が提案されている(特許文献1)。このように、特定の条件下で、可搬デバイスに対応付けられるアカウントにおける課金と引き換えに、電子バリューの残額を自動的に増加させる機能を「自動入金」あるいは「オートチャージ」と呼ぶ。

特許文献1では、オートチャージをしようとするときに、アカウントを管理するクレジットカード会社に対して毎回与信を依頼する手法(段落0041)、与信ができないクレジットカードのアカウントが登録された与信リストをPOS(Point Of Sales)端末に配信しておき、オートチャージをしようとするときに、可搬デバイスに対応付けられるクレジットカードのアカウントと拒否リストを対比する手法(段落0054)、可搬デバイスに直近のクレジットカードの利用日時を登録し、オートチャージをしようとする時点と登録された利用日時との差に基づいて、オートチャージの可否を決定する手法(段落0062)が提案されている。

特開2002-366862号公報

しかしながら、毎回クレジットカード会社から与信をとる手法では、通信ならびに与信の判断に時間を要するため、電子マネーによる支払の即時性が損われる。与信リストによる手法では、与信リストが巨大になれば、POS端末の記憶領域を圧迫するほか、判定に時間を要するようになってしまう。クレジットカードの利用日時を利用する手法では、信頼性に欠けることがあるほか、支払には電子マネーを専ら利用し、クレジットカードは主としてオートチャージに利用するユーザなどでは、適用が難しいこともある。

本発明は、上記のような課題を解決するもので、即時性、信頼性ならびにPOS端末の負荷を考慮しつつ、電子マネーの残額を管理する可搬デバイスに対する残額の補充や当該可搬デバイスによる支払の可否を、適切に判定する管理装置、当該管理装置が実行する管理方法、ならびに、当該管理装置で実行されるプログラムを提供することを目的とする。

本発明に係る管理装置において、
保持部は、リストサーバにより更改される判定リストを保持し、
制御部は、可搬デバイスと通信部を介して通信することにより前記可搬デバイスを制御し、
支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記制御部は、前記可搬デバイスから、前記可搬デバイスのID、残額ならびに更新時を取得し、
前記取得された残額に係る第1条件が満たされ、前記取得された更新時に係る第2条件が満たされ、前記取得されたIDと前記保持された判定リストとに係る第3条件が満たされると、前記制御部は、
(a)前記取得された残額および所定の増分額から前記支払を行って前記可搬デバイスの残額を更新し、現在を表す基準時に前記可搬デバイスの更新時を更新し、
(b)前記取得されたIDに対応付けられるアカウントに対して前記所定の増分額に相応する課金を管理サーバに行わせるための課金レポートを生成する。

本発明の実施例に係るPOS端末およびリーダ/ライタの概要を示す説明図である。 本発明の実施例に係るシステムの概要を示す説明図である。 本発明の実施例に係る可搬デバイスの記憶装置に確保された記憶領域の様子を示す説明図である。 本発明の実施例に係る判定リストの更改の処理の流れを示すフローチャートである。 チェックリストの更改前の様子を説明するための説明図である。 チェックリストが更改中の様子を説明するための説明図である。 チェックリストの更改後の様子を説明するための説明図である。 判定リストの更改前の様子を説明するための説明図である。 判定リストの更改後の様子を説明するための説明図である。 本実施例に係る管理装置の概要構成を示す説明図である。 本実施例に係る管理装置にて実行される処理の流れを示すフローチャートである。 リーダ/ライタから管理サーバへ送られるレポートの様子を説明するための説明図である。 管理サーバに課金をさせて可搬デバイスにチャージする処理の流れを示すフローチャートである。 可搬デバイスの不具合の理由に応じて、可搬デバイスに対する制限を変化させる処理の流れを示すフローチャートである。

以下に本発明の実施形態を説明する。なお、本実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

電子マネーシステムにおける電子バリューは、現金に類する価値を有するものである。電子バリューは、現金と相互もしくは一方から他方へ交換が可能なように、同じ通貨単位で管理されることもあるし、独自の単位を採用して交換の際に換算することもある。また、ユーザのアクション(商品の購入やアンケートへの回答、店舗への来店等)に応じて付与される各種のポイントを、電子バリューとして利用することも可能である。

図1は、本発明の実施例に係るPOS端末およびリーダ/ライタの概要を示す説明図である。以下、本図を参照して説明する。

本実施例では、取引対象の提供者が店頭にて、被提供者との間で電子バリューのやりとりをするために、POS端末1に接続されるリーダ/ライタ2を利用する。

このほか、POS端末1には、バーコードリーダ3、キーボード4、店員用ディスプレイ5、客用ディスプレイ6、ドロワ7が備えられている。

取引の際には、まず、店員がPOS端末1のバーコードリーダ3により、商品の価格を読み取るか、あるいは、キーボード4から金額等を直接入力する。ドロワ7は、現金の支払の際の出し入れに利用される。

被提供者が電子バリューでの支払をする場合や、電子バリューを可搬デバイスに補充する際には、POS端末1は、入力された額の電子バリューの取引を行うよう、リーダ/ライタ2に対して指示を出す。

すると、リーダ/ライタ2は、可搬デバイスとの近接場通信を行い、当該可搬デバイスに紐付けられた電子バリューの額を調べたり、電子バリューの出し入れを行う。

電子バリューによる支払が成功すると、リーダ/ライタ2からPOS端末1にその旨が通知され、POS端末1は、店舗側の会計処理を行う。現金による支払があった場合には、POS端末1が単独で、店舗側の会計処理を行う。

本実施例のリーダ/ライタ2は、不揮発性の記憶領域が用意されている。この記憶領域には、可搬デバイスに対して行った電子バリューの出納処理の履歴が蓄積されるほか、リーダ/ライタ2にて動作するプログラムや当該プログラムが利用する各種のデータが格納される。

リーダ/ライタ2に記録された出納処理の履歴は、提供者と被提供者の間でやりとりされた電子マネーの額を電子マネーシステム全体の運営者に管理させるため、リーダ/ライタ2は、たとえば、1日に1回等、定期的に、この履歴をレポートとして、電子マネーシステムの運営者に伝達する。

このように、支払を行うべき額が指示されると、可搬デバイスとNFCを行って当該額の電子バリューの支払の決済を行い、その旨を運営者に知らせる処理を、単独で行うことが可能なリーダ/ライタ2は、リッチクライアントと呼ばれる。サイズやコストの観点から、リッチクライアントが持つ不揮発性の記憶領域は、容量が限られることが多い。

近年では、1つのリーダ/ライタ2が、複数の電子マネーシステムの決済に対応することも多い。このようなリーダ/ライタ2では、記憶領域を当該複数の電子マネーシステムにより分け合うことになるので、容量の制限はさらに厳しい。したがって、本実施形態では、記憶領域の使用量を抑制する技術を採用する。

このほか、可搬デバイスとのNFCのみを行う安価な通信機器や、スマートフォン等に組み込まれた電子決済用の通信機器をリーダ/ライタ2を実現するための部品として利用することも可能である。この態様では、NFC用通信機器は、単なる可搬デバイスとのインターフェースとして機能し、計算や判断などの処理は行わない。これらの処理や、可搬デバイスとのコマンドの生成、結果の吟味等は、NFC用通信機器をクライアントとするシンクライアント用サーバ(図示せず)が司る。すなわち、両者が協働してリーダ/ライタ2に相当する機能を実現する。

この形態では、シンクライアント用サーバは、店舗内LAN(Local Area Network)やWAN(Wide Area Network)等のコンピュータ通信網を介してPOS端末1に接続され、POS端末1から受け取った指示に基づいて通信機器を制御する。通信機器は、可搬デバイスとNFCを行うことにより、電子バリューの問い合わせや出し入れを行い、その結果を、シンクライアント用サーバに送る。シンクライアント用サーバは、この結果を、さらにPOS端末1へ送る。

この態様では、電子バリューに関する処理の履歴や、通信機器を制御するためのプログラム、当該プログラムが利用する各種のデータは、シンクライアント用サーバが有するハードディスク等の不揮発性記憶装置に保存するのが一般的であるが、通信機器が不揮発性記憶領域を有していれば、これを利用することも可能である。たとえば、NFC用通信機器と可搬デバイスとの通信の記録は、最も直接的な電子バリューの出納記録となるので、NFC用通信機器が備える不揮発性記憶領域に保持するが、プログラムはシンクライアント用サーバに保持する、という態様を採用することもできる。

シンクライアント方式で、記憶領域としてシンクライアント用サーバが有するハードディスク等を利用する態様では、リッチクライアント方式の場合に比べて、記憶領域の制限は緩和されることが多い。しかしながら、できるだけ記憶領域の使用量を抑制したいのは、リッチクライアント方式でもリッチクライアント方式でも変わらない。

さて、リッチクライアント方式では単体の装置をなすリーダ/ライタ2が有するCPU(Central Processing Unit)がプログラムを実行する。また、シンクライアント方式では、シンクライアント用サーバが有するCPUがプログラムを実行して、NFC用通信装置を制御する。

このプログラムは、電子マネーシステム全体の運営者、あるいは、当該運営者と店舗との仲立ちを行う事業者が管理する配布サーバから、コンピュータ通信網等の一時的(transitory)伝送媒体を介して、配布することができる。また、このプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、ROM(Read Only Memory)、EEPROM(Electrically Erasable Programmable ROM)、フラッシュメモリ、半導体メモリ等のコンピュータ読み取り可能な非一時的(non-transitory)情報記録媒体に記録することができる。この情報記録媒体は、リーダ/ライタ2やシンクライアント用サーバとは独立して配布・販売することもできる。

配布されたプログラムは、ダウンロードされた機器のフラッシュメモリやハードディスク等の非一時的(non-transitory)情報記録媒体に記録される。CPUは、このプログラムを一時的(temporary)記憶装置であるRAM(Random Access Memory)に読み出してから、プログラム内の指令を実行する。ただし、ROMとRAMを一つのメモリ空間にマッピングして実行することが可能なアーキテクチャでは、ROMに格納されたプログラムに含まれる指令を、直接CPUが読み出して実行する。

以下では、本実施例に係る管理装置がリーダ/ライタ2により実現される態様について説明する。この態様では、リーダ/ライタ2には、容量制限が厳しい記憶領域が用意されており、当該記憶領域には、リーダ/ライタ2自体を制御するためのプログラムならびに当該プログラムが利用するデータが記録されることを想定する。

図2は、本発明の実施例に係るシステムの概要を示す説明図である。以下、本図を参照して説明する。

本実施例に係るシステム11では、リーダ/ライタ2により実現される管理装置14が、管理サーバ13ならびにリストサーバ12と、インターネット等のコンピュータ通信網15を介して通信可能に接続されている。管理サーバ13とリストサーバ12は、電子マネーシステム全体の運営者もしくは運営者と提供者との仲介を行う事業者により管理される。管理サーバ13とリストサーバ12は、一体に構成されても良いし、複数のサーバコンピュータにより構成されても良い。

また、本実施例では、オートチャージがクレジットカードあるいはデビットカードにより行われることを想定している。そこで、リストサーバ12は、管理サーバ13のほか、クレジットカード会社やデビットカード会社が運営する課金センター18とも通信して、判定リストを更改する。

このほか、管理サーバ13は、クレジットカード会社やデビットカード会社が運営する課金センター18と通信して、アカウントの与信を受けたり、アカウントから引き落としを行ったりする。

上記のように、管理装置14は、現実の店舗や電子市場等において商品やサービス等の提供対象を販売する提供者により利用される。上記のように、本実施例では、管理装置14は、リーダ/ライタ2により実現され、NFCにより可搬デバイス16と通信して、可搬デバイス16から情報を取得したり、可搬デバイス16に情報を書き込んだりする。

本実施例は、ストアドバリュー(stored-value)型と呼ばれる電子マネーシステムに適用が可能である。ストアドバリュー型システムでは、ユーザが取引において対価として支払うことが可能な電子バリュー(「残高」とも称される。)を、電子回路を組み込んだカードや携帯電話、スマートフォンなどの各種の可搬デバイス16に対応付けて管理する。

ストアドバリュー型システムでは、可搬デバイス16が有する電子回路に、利用可能な電子バリューの数値を記憶させるのが一般的である。この態様は、財布に現金が入っている状態に相当する。以下では、可搬デバイス16に対応付けられるバリューを、「財布の中に残っている現金」になぞらえて、「残存バリュー(remaining value)」と呼ぶ。図3は、本発明の実施例に係る可搬デバイスの記憶装置に確保された記憶領域の様子を示す説明図である。以下、本図を参照して説明する。

本図に示すように、可搬デバイス16が有する電子回路の記憶装置51には、ID領域52、バリュー領域53、残額更新時領域54、チャージ更新時領域55、基準額領域57、増分額領域58が用意されている。ID領域52は、可搬デバイス16のIDを保持する領域で、書き換えが禁止されている。バリュー領域53には、残存バリューの数値が記録される。

ID領域52とバリュー領域53は、可搬デバイス16が電子マネーの財布として機能するための本質的な要素であるため、運営者に認定されたリーダ/ライタ2でなければ、内容を書き換えられないよう、暗号化およびロックがされている。一方、残額更新時領域54、チャージ更新時領域55、基準額領域57、増分額領域58等の領域は、可搬デバイスの所有者が、自分の持つパーソナルコンピュータに接続したICカード用のリーダ/ライタで情報を書き込むことで、オートチャージができるようにするため、ID領域52とバリュー領域53に比べて、セキュリティ上の制限が緩和されている。

商品やサービスの提供者は、可搬デバイス16と通信可能なリーダ/ライタ2が管理装置14として機能することにより、ユーザからの対価の支払を受け付ける。ユーザが可搬デバイス16を管理装置14を実現するリーダ/ライタ2に翳すと、可搬デバイス16とリーダ/ライタ2の間のNFCが可能となり、リーダ/ライタ2から可搬デバイス16へ、各種のコマンドを送信すると、そのコマンドの実行結果が可搬デバイス16からリーダ/ライタ2へ送信される。

たとえば、問い合わせコマンドを利用すると、実行結果として、ID領域52に保持された可搬デバイス16のIDや、バリュー領域53に保持されている残存バリューの数値を取得することができる。

減少コマンドでは、当該コマンドに指定された電子バリューだけ、可搬デバイス16に対応付けられている残存バリューを減少させる。これは、財布から現金を取り出したことに対応する。すなわち、減少コマンドは、商品やサービスの提供を受ける取引において、対価を支払う際、すなわち「課金」の際に利用される。以下では、減少コマンドに指定される電子バリューを、「対価バリュー(price value)」と呼ぶ。

増加コマンドは、当該コマンドに指定された電子バリューだけ、可搬デバイス16に対応付けられている残存バリューを増加させる。これは、財布に現金を入れることに対応する。増加コマンドは、たとえば店頭で、ユーザが店員に現金を支払うかわりに、当該現金に相当する電子バリューを可搬デバイス16に補充する際に利用される。

なお、減少コマンドや増加コマンドの送受の際には、リーダ/ライタ2が有するリアルタイムクロックから取得される時刻が可搬デバイスへ自動的に送られ、可搬デバイス16の残存バリューが更新される際には、増減に関らず、そのときの日時が、残額更新時領域54に書き込まれる。残額更新時領域54に保持された残額更新時は、問い合わせコマンドにより取得することができる。

オートチャージの設定がされていない可搬デバイス16では、出荷時の設定あるいは初期化により、増分額領域58には値0が記録されている。可搬デバイス16の所有者がオートチャージの設定を行うには、可搬デバイス16の基準額領域57に、オートチャージの可否を判定するための基準額を、増分額領域58に、オートチャージを行うときの増分額を、それぞれ書き込めば良い。なお、オートチャージの利用の可否設定を記録するフラグ領域を、別途、記憶装置51内に用意することとしても良い。

オートチャージの設定を初めて行ったときには、所有者のパーソナルコンピュータや店頭でのNFC端末等、設定を行う機器から読み出した現在日時が、チャージ更新時領域55に初期値として書き込まれる。この後、可搬デバイス16に対応付けられるオートチャージ用のアカウントから電子バリューのチャージをして、残額が更新されたときには、そのときの日時が、チャージ更新時として、チャージ更新時領域55に書き込まれる。また、店頭でオートチャージの設定を初めて行った際には、必ず可搬デバイス16に対応付けられるオートチャージ用のアカウントから電子バリューのチャージをすることとしても良い。チャージ更新時は、問い合わせコマンドにより取得することができる。

なお、本実施例においては、可搬デバイス16への電子バリューの補充が現金により行われた場合には、チャージ更新時領域55への書き込みは行わない。

一方で、オートチャージ用のアカウントから、オートチャージによらず、可搬デバイス16の所有者の明示的な指示によりチャージがされた場合にも、チャージ更新時を更新することが望ましい。たとえば、可搬デバイス16がクレジットカードにより構成されており、クレジットカードのアカウントから通常のクレジットカード支払の手順を踏んで与信を行い、直接ユーザが支払を行うことで、可搬デバイス16へ電子バリューを補充した場合である。

また、本実施例では、後述するように、クレジットカードのアカウントに対する課金が完了しないうちに、オートチャージを行うことがある。この場合には、可搬デバイス16に対して電子バリューの補充を行った日時がチャージ更新時となり、チャージ更新時より後に、クレジットカードのアカウントからの課金が行われる。

上記の態様では、リーダ/ライタ2を介して電子バリューの取引を行うことを想定していたが、可搬デバイス16が、コンピュータ通信網15を介した通信を行う機能を有する場合には、可搬デバイス16内で動作するアプリケーションが、コンピュータ通信網15を介して送られたコマンドに呼応して、可搬デバイス16に対応付けられる残存バリューの取得や増減を行うことも可能である。この場合には、リーダ/ライタ2を利用せずに、可搬デバイス16における対価の支払や残存バリューのチャージが可能となる。

減少コマンドや増加コマンドなどで、電子バリューの増減が行われる、ということは、支払者と提供者との間でバリューの移動が起きたことを意味する。提供者は、このバリューの移動を示すレポートを、管理装置14を実現するリーダ/ライタ2から管理サーバ13に伝達する。上記のように、管理サーバ13は、電子マネーサービス全体の運営者により運営されている。管理サーバ13に蓄積された決済情報を合算すれば、提供者がその期間内に得た、あるいは、失った電子バリューの総額が得られる。この総額は、提供者が所有する電子マネー決済用アカウントにより管理される。

提供者は、電子バリューを獲得しているのであれば、獲得した電子バリューを交換して、運営者から現金等を手に入れることができる。一方、電子バリューを失っているのであれば、提供者は、運営者に対して、当該電子バリューの額に相当する現金等の支払いをする責務を負う。

なお、上記のように、提供者と、運営者と、の間に、中間的な業者が介在することもある。この業者は、電子マネーサービスの事業者と呼ばれ、提供者が電子バリューによる支払を受けるために必要なインフラストラクチャの準備や電子バリューの取扱いについての助言やサポートを行う。

本実施例では、管理装置14を実現するリーダ/ライタ2と、その通信可能範囲に入っている可搬デバイス16と、の通信にはNFCを採用する。ただし、管理装置14と可搬デバイス16と、が、赤外線通信やブルートゥース(Bluetooth(登録商標))により通信を行う態様を採用しても良い。

なお、本実施例は、サーババリュー方式と呼ばれる電子マネーシステムに適用することも可能である。サーババリュー方式では、可搬デバイスからは、電子バリューの財布を区別するIDが取得され、運営者もしくは事業者の管理サーバ内において、当該アカウントと、当該アカウントにおける残存バリューと、が管理される。すなわち、サーババリュー方式では、可搬デバイスは、アカウントを識別するための識別タグとして機能するが、残存バリューそのものを記憶することはない。

上記のように、本実施例における管理装置14は、負荷の低い計算が可能なCPUと、当該CPUが一時的な処理経過を記録するためのRAMと、小容量の不揮発性記憶領域と、を有するリーダ/ライタ2により実現することが可能である。すなわち、CPUが、不揮発性記憶領域に記憶されたプログラムを実行することによって管理装置14が実現される。また、当該プログラムにより参照される判定リストや、管理サーバ13に送信されるレポートを生成するための可搬デバイスとの通信記録等もこの不揮発性記憶領域により保持される。

上記のように、リーダ/ライタ2は、管理サーバ13との間で、定期的に、レポート等、NFCの通信記録に基づく情報の交換を行う。これにより、管理サーバ13において、提供者が所有する電子バリューの総額が求められることになる。通信記録を保持するNFC用の通信機器とシンクライアント用サーバの組み合わせによりリーダ/ライタ2が実現される態様では、シンクライアント用サーバが通信記録をNFC用の通信機器から読み出してレポートを生成し、これを、管理サーバ13に定期的に送信する。

さて、可搬デバイス16に対するオートチャージは、可搬デバイス16に対応付けられるアカウントに対する課金を対価とすることにより行われる。たとえば、可搬デバイス16がクレジットカードにより実現されている場合、所定の増分だけオートチャージがされる際には、当該クレジットカードのアカウントに対して、当該所定の増分に相当する額の課金がされる。可搬デバイス16がキャッシュカード(デビットカード)により実現されている場合、所定の増分だけオートチャージがされる際には、当該キャッシュカード(デビットカード)の口座から引き出しが行われる。

なお、本実施例では、1回の支払においてオートチャージができる上限回数は、1回の固定値とすることを想定している。また、1日あたりのチャージ総額や支払総額に制限を設けたい場合に、これらの値を、可搬デバイス16の記憶装置51のユーザ書き込みが可能な領域に設定しておくこととしても良い。可搬デバイス16の利用の可否を決定する際に、管理装置14がこれらの設定を読み出して判定の材料とする。

さて、可搬デバイス16には、オートチャージや支払をすべきでない不具合が生じることがある。たとえば、可搬デバイス16そのものの紛失や盗難の届出が可搬デバイス16の所有者からあった場合には、可搬デバイス16による支払は禁止すべきである。

なお、可搬デバイス16がクレジットカードやデビットカードにより構成され、当該クレジットカードやデビットカードのアカウントから可搬デバイスへチャージがされる場合には、紛失や盗難の届出は、クレジットカード会社やデビットカード会社にされるのが一般的であり、これらの会社から、電子マネーシステムの運営者や事業者に、紛失や盗難の情報が伝達される。

また、可搬デバイス16がスマートフォンや携帯電話、他の決済機能を持たないICカード等により構成される場合には、電子マネーシステムの運営者や事業者に、紛失や盗難の届出がされる。

また、可搬デバイス16に対するオートチャージをすべきでない状況としては、可搬デバイス16に対応付けられるアカウントに何らかの事故が生じた場合が考えられる。たとえば、以下のような状況である。
(a)可搬デバイス16がスマートフォンや他の決済機能を持たないICカード等により構成されており、可搬デバイス16のチャージ用に設定されたクレジットカードやデビットカードについて紛失・盗難の届出があった場合。なお、この場合であっても、可搬デバイス16自体は紛失・盗難はされていないから、可搬デバイス16による電子バリューの支払や、現金等による可搬デバイス16へのチャージは可能である。
(b)可搬デバイス16に対応付けられるクレジットカードの今月の利用限度額に達してしまった場合、クレジットカード会社への支払を滞納している場合、クレジットカードの有効期限が切れた場合。
(c)可搬デバイス16に対応付けられるキャッシュカード(デビットカード)の口座の残高が一定額より少ない場合。
(d)可搬デバイス16に対応付けられるクレジットカードやキャッシュカード(デビットカード)の契約を解消した場合。

本実施例では、電子マネーサービスの運営者や事業者が管理するリストサーバ12が、クレジットカード会社やデビットカード会社が運営する課金センター18ならびに管理サーバ13から情報を取得して、上記のような不都合が生じている可搬デバイス16のIDを判定リストに登録し、この判定リストを管理装置14に配布する。管理装置14は、判定リストを参照して、可搬デバイス16に対するオートチャージの可否や可搬デバイス16による支払の可否を判定する。

本実施例では、可搬デバイス16そのものの使用の可否を判定するための判定リストと、可搬デバイス16へのオートチャージの可否を判定するための判定リストと、の2種類を利用することを想定する。これらの判定リストにおいては、いずれも、不都合が生じている可搬デバイス16のIDが列挙されていれば十分である。

また、本実施例では、オートチャージ用の判定リストのサイズを抑制するために、閾期間を利用する。閾期間は、たとえば、30日や60日、90日等、ある程度長い期間をあらかじめ定める。そして、現時点(リストサーバ12が判定リストを更改する時点)から閾期間だけ以前の開始時点を求め、開始時点から現時点までの間にオートチャージや支払をすべきでない理由が生じた可搬デバイス16のIDのみを、判定リストに登録するのである。

なお、可搬デバイス16自体の使用可否の判定リストについては、閾期間を設けず、使用が禁止されたすべての可搬デバイス16のIDを列挙することが望ましいが、可搬デバイス16を盗んだ者は、盗んだ直後に支払に利用するのが通例であり、長期間保有してから使用することは稀である。そこで、オートチャージ用の判定リストと同様に、使用可否の判定リストについても、閾期間を設定しても良い。また、オートチャージ用の判定リストと、使用可否の判定リストと、では、閾期間の長さを異なるものとしても良い。

以下では、閾期間を有する使用可否の判定リストならびに、オートチャージ用の判定リストに共通する判定リストの更改処理を説明する。

リストサーバ12は、たとえば1日に1回、定期的に、判定リストの更改処理を実行する。この作業を行うため、リストサーバ12のハードディスク等の不揮発性記憶装置には、チェックリストが用意される。

図5Aは、チェックリストの更改前の様子を説明するための説明図である。図6Aは、判定リストの更改前の様子を説明するための説明図である。以下、これらの図を参照して説明する。

本実施形態に係るチェックリスト61は、表形式で管理されている。上記の開始時点から更改時点までの間に不具合が確認された可搬デバイスのIDは、ID欄62に記録され、不具合が確認された日時は、当該IDと同じ行の日時欄63に記録される。なお、本実施例では、チェックリスト61の日時欄63に記録される日時は、日単位で記録される。

図5Aに示すチェックリスト61が、2013年8月11日未明に更改されたことを想定し、閾期間として90日を採用したとすると、開始時点は、日単位で、2013年5月13日となる。したがって、チェックリスト61のID欄62には、2013年5月13日から2013年8月11日未明までの日時に不具合が確認されたIDが記録されることになる。

本実施例に係る判定リスト71は、チェックリスト61から日時欄63を除去したものである。図6Aに示す判定リスト71には、2013年5月13日から2013年8月11日未明までの日時に不具合が確認されたIDのみが並んでいる。

図4は、本発明の実施例に係る判定リストの更改の処理の流れを示すフローチャートである。以下では、更改処理が翌日の2013年8月12日未明に実行された場合を例にあげて説明する。

更改処理が開始されると、まず、リストサーバ12は、現在時点を更改時点として取得する(ステップS81)。ついで、更改時点から閾期間前の開始時点を計算する(ステップS82)。

上記の例では、現在時点は、2013年8月12日未明であるから、更改時点および開始時点は、日単位で、2013年8月12日未明および2013年5月14日になる。

ついで、リストサーバ12は、チェックリスト61から、開始時点より前の日付が登録されている行を削除する(ステップS83)。図5Aに示すチェックリストのうち、開始時点より前の日付が登録されている行は「67890(2013/05/13)」である。図5Bは、チェックリストが更改中の様子を説明するための説明図である。本図に示す通り、ステップS83の処理により、チェックリスト61から、「67890(2013/05/13)」の行が削除される。

この後、リストサーバ12は、課金センター18から、新たに不具合が生じた旨が報告されたクレジットカードやデビットカードのカード番号等、不具合が生じているアカウントの識別情報を取得する(ステップS84)。たとえばここで、クレジットカード番号1111-2222-3333-4444および5555-6666-7777-8888が取得されたものとする。

そして、リストサーバ12は、取得された識別情報のアカウントの各々について、当該アカウントをチャージ元として設定している可搬デバイス16のIDを、管理サーバ13から取得する(ステップS85)。

管理サーバ13は、可搬デバイス16がクレジットカード等により構成されている場合には、当該クレジットカード等のアカウントに対応付けて、可搬デバイス16のIDを管理している。また、可搬デバイス16がスマートフォン等により構成されているときには、ユーザにより設定されたクレジットカード等のアカウントが、当該可搬デバイス16のIDに対応付けられて、管理される。そこで、管理サーバ13は、アカウントの識別情報がリストサーバ12から送られてくると、そのアカウントに対応付けられている可搬デバイス16のIDを検索して、見つかったIDを、リストサーバ12に送る。

たとえばここで、クレジットカード番号1111-2222-3333-4444に対しては対応付けられるIDとして89012が見つかったが、5555-6666-7777-8888に対してはIDは見つからなかったものとすると、管理サーバ13は、1111-2222-3333-4444に対しては89012をリストサーバ12に送り、5555-6666-7777-8888に対しては見つからない旨を送ることになる。IDが見つからない典型的な例は、可搬デバイス16がスマートフォン等により構成されている状況で、問題が生じているクレジットカードとの対応付けをユーザが自発的に解除して、新たなクレジットカードと対応付けた場合である。

さて、リストサーバ12は、管理サーバ13から送られたIDに、更改時点を日単位とした情報を対応付けて、チェックリストに追加する(ステップS86)。図5Cは、チェックリストの更改後の様子を説明するための説明図である。本図に示す通り、ステップS86の処理により、チェックリスト61へ、「89012(2013/08/12)」の行が追加される。

このようにして、チェックリスト61へ不具合が生じたIDがすべて追加されると、リストサーバ12は、チェックリスト61から、ID欄のみを抽出して判定リスト71を生成することにより(ステップS87)、判定リスト71を更改して、本処理を終了する。図6Bは、判定リストの更改後の様子を説明するための説明図である。本図に示す判定リスト71には、2013年5月14日から2013年8月12日未明までの日時に不具合が報告されたIDのみが並んでいる。

管理装置14は、このようにして更改された判定リスト71を、定期的にリストサーバ12から取得する。このため、取得できる判定リスト71は、最新の不具合情報から少々遅れた古い情報となってしまう。そこで、本発明では、後述するような技術により、オートチャージ等で不正使用が生じる可能性を、合理的に抑制するのである。

なお、特許文献1の技術では、オートチャージの課金に用いられるクレジットカードのアカウントを与信リストに登録していたが、本実施例では、不都合が生じている可搬デバイス16のID等、電子マネーサービスで利用されるIDを判定リストに登録する。すなわち、特許文献1では、オートチャージのチャージ元の識別情報により判定を行っていたが、本実施例では、チャージ先の識別情報により、判定を行うという違いがある。

なお、判定リストの更改時は、判定リストのファイルの更新日時から得ることができる。また、判定リストの更改があらかじめ定めたスケジュールに基づいて行われるのであれば、当該スケジュールにおいて更改がされるべきと定められている日時のうち、現在よりも以前の最新の日時を、更改時とみなすことができる。

本実施例では、判定リストに登録されたIDの可搬デバイス16を用いて支払をしようとすると、当該可搬デバイス16に対するオートチャージや当該可搬デバイス16による支払を制限する。以下では、使用可否の判定リストおよびオートチャージ用の判定リストを利用して、支払そのものを制限したり、オートチャージを制限する態様について、まず説明する。その後、支払額を制限する態様について説明する。

また、本実施例による判定リストの更改処理では、利用限度額超過により一時的にクレジットカードが利用できなくなってチェックリストに登録されてしまうと、その後利用可能になっても、チェックリストに登録されたままとなり、閾期間が経過するまでは、オートチャージ等ができないままとなる。これに対して、クレジットカード会社からの連絡に応じて、復活したクレジットカードのアカウントに対応するIDの行を、チェックリストから削除する態様を採用しても良い。

図7は、本実施例に係る管理装置の概要構成を示す説明図である。以下、本図を参照して説明する。

管理装置14は、保持部102、制御部103とを有し、制御部103は、通信部104を制御する。保持部102は、リーダ/ライタ、POS端末、あるいは、シンクライアント用サーバが有する不揮発性の記憶装置により実現される。制御部103は、POS端末のCPU、あるいは、シンクライアント用サーバのCPUにより実現される。通信部104は、リーダ/ライタにより実現される。

保持部102は、リストサーバ12により定期的に更改される判定リストを保持する。判定リストは、典型的には、1日に1回、管理サーバ13へレポートを送信するときに、あわせて、リストサーバ12からダウンロードされる。上記のように、判定リストには、使用可否を判定するためのものと、オートチャージ用のものの2種類を用意するが、その詳細や変形例については、後述する。

本実施例では、通信部104とNFCが可能となった可搬デバイス16に対するオートチャージの可否や、可搬デバイス16そのものによる支払の可否の判定を、制御部103が判定リストを参照して行う。制御部103によるオートチャージや支払の可否の判定の詳細ならびに変形例については、後述する。

ここで、管理装置14を実現するリーダ/ライタ2や、シンクライアント用サーバとNFC用通信機器の組み合わせには、記憶容量に制限があることも多い。そこで、本実施例では、判定リストのサイズを小さくすることで、記憶領域の圧迫を合理的に抑制しつつ、高速かつ高い信頼性で、判定を行う。

図8は、本実施例に係る管理装置にて実行される処理の流れを示すフローチャートである。以下、本図を参照して説明する。本処理は、商品やサービスの提供を受ける被提供者が支払うべき額が決まり、被提供者が電子マネーによる支払を選択することを契機として開始される。

本処理が開始されると、POS端末は、被提供者に対して、可搬デバイス16をリーダ/ライタに翳すよう促すメッセージを出力し(ステップS201)、制御部103は、通信部104にNFC可能な可搬デバイス16を検知させる(ステップS202)。NFC可能な可搬デバイス16が検知されなければ(ステップS203；No)、ステップS201に戻る。

NFC可能な可搬デバイス16が検知されれば(ステップS203；Yes)、制御部103は、通信部104により、可搬デバイス16に対して、問い合わせコマンドを送信して(ステップS204)、その結果を受信する(ステップS205)。

そして、制御部103は、受信された結果から、以下の情報を取得する(ステップS206)。
(1)可搬デバイス16のID。
(2)可搬デバイス16における電子マネーの残額(残存バリュー)。
(3)可搬デバイス16において最後に残額が更新された日時(残額更新時)。
(4)可搬デバイス16において最後に可搬デバイス16に対応付けられるアカウントからチャージがされ、残額が更新された日時(チャージ更新時)。
(5)オートチャージの可否を判定するための基準額。
(6)オートチャージを行うときの増分額。

なお、基準額や増分額は、可搬デバイス16に格納するのではなく、契約等により一律に定めることとしても良い。また、残額更新時やチャージ更新時の精度は、秒、分、時、日のいずれとしても良い。

なお、サーババリュー方式では、受信された結果から可搬デバイス16のIDを取得した後、当該IDをキーとして、管理サーバ13等から、残額、残額更新時、チャージ更新時、基準額、増分額等を取得することとなる。

そして、取得されたIDが、使用可能か否かを調べる(ステップS230)。上記のように、使用可否の判定リストに含まれていれば、使用が禁止されており、含まれていなければ、使用が可能である。使用可能であれば(ステップS230;Yes)、オートチャージを行うときの増分額が0か非0かにより、オートチャージを利用する設定がされているか否かを調べる(ステップS231)。オートチャージを利用する設定がされていたら(ステップS231;Yes)、ステップS207に進む。

ついで、制御部103は、取得された残額が、取得された基準額と支払額との和以上であるか否かを調べる(ステップS207)。残額が和以上であれば(ステップS207;Yes)、制御部103は、通信部104により、可搬デバイス16に対して支払額を指定した減少コマンドとその結果を送受して、可搬デバイス16による支払を行わせる(ステップS208)。

さらに、取得されたIDによる支払額の支払がされたことを管理サーバ13に知らせるための支払レポートを作成して(ステップS209)、本処理を終了する。

一方、残額が和未満であれば(ステップS207；No)、取得された残額と取得された増分額の和が、支払額以上であるか否かを調べる(ステップS210)。和が支払額未満であれば(ステップS210；No)、当該可搬デバイス16に対して1回オートチャージを行っても、支払額には満たないことになる。そこで、「可搬デバイス16の現在の残額のままでは、支払はできない」旨のメッセージを出力して(ステップS251)、本処理を終了する。

この後は、提供者は、被提供者に、たとえば、以下のような他の支払方法を提示して、いずれかを選択させる。
(1)支払額全額を現金で支払う。
(2)可搬デバイス16の残額をすべて使った上で不足額を現金やクレジットカード、デビットカードにより支払う。
(3)支払前に、被提供者の指示に基づく明示的なチャージを現金、クレジットカード、デビットカード等により行う。
(4)他の可搬デバイス16を利用する。
(5)取引をやめる。

ここで、他の可搬デバイス16により支払を行うことが選択されたら、再度本処理が開始されることになる。

なお、明示的なチャージが、可搬デバイス16に対応付けられるアカウントからされたことが明らかである場合、たとえば、
(p)可搬デバイス16がクレジットカードにより構成されており、
(q)可搬デバイス16に対応付けられるアカウントが当該クレジットカードであり、
(r)当該クレジットカードのアカウントから、当該クレジットカードにより構成される可搬デバイス16の残存バリューへ、所有者の明示的な指示に基づいて、店頭等で電子バリューがチャージされた
場合には、当該可搬デバイス16に記録される残高更新時ならびにチャージ更新時が更新される。

明示的なチャージが現金によりされた場合には、上記のように、残高更新時は更新されるが、チャージ更新時は更新されない。

さて、和が支払額以上であれば(ステップS210；Yes)、オートチャージに係る第1条件が満たされたことになる。そこで、制御部103は、現在を表す基準時を定める(ステップS211)。この基準時としては、以下のようなものを採用することができる。
(a)現在の日時。
(b)最後に判定リストがダウンロードされた日時。
(c)最後に判定リストが更改された日時。
これらの日時は、POS端末やシンクライアント用サーバが備えるリアルタイムクロックを適宜参照すれば、取得することができる。また、基準時の精度は、可搬デバイス16の残額更新時やチャージ更新時の精度に合わせることとしても良い。

ついで、制御部103は、取得されたチャージ更新時から定められた基準時までの間隔が、判定リストの閾期間を超えているか否かを調べる(ステップS212)。基準時は現在日時に対応し、チャージ更新時は過去の日時であるから、基準時からチャージ更新時を減算した値が、閾時間を超えているか否かを判定することになる。

間隔が閾期間以下であれば(ステップS212；No)、オートチャージに係る第2条件が満たされたことになる。そこで、制御部103は、取得されたIDが、判定リストに含まれるか否かを調べる(ステップS213)。

IDが判定リストに含まれなければ(ステップS213；No)、オートチャージに係る第3条件が満たされたことになる。そこで、制御部103は、支払額が増分額以上であるか否かを調べる(ステップS214)。

支払額が増分額以上であれば(ステップS214;Yes)、制御部103は、通信部104により、可搬デバイス16に対して、支払額から増分額を減算した額を指定した減少コマンドを送信して、可搬デバイス16に対するオートチャージならびに可搬デバイス16による支払を行わせる(ステップS215)。

そして、取得されたIDに対応付けられるアカウントに対して増分額に相当する課金を管理サーバ13に行わせるための課金レポートを作成して(ステップS216)、ステップS209に進む。

一方、支払額が増分額未満であれば(ステップS214；No)、制御部103は、通信部104により、可搬デバイス16に対して、増分額から支払額を減算した額を指定した増加コマンドを送信して、可搬デバイス16に対するオートチャージならびに可搬デバイス16による支払を行わせ(ステップS217)、ステップS216に進む。

ステップS216で作成される課金レポートには、可搬デバイス16のIDと、当該IDに対する増分額とが1つのレコードとして指定されている。この課金レポートは、定期的に、典型的には1日に1回、管理サーバ13に送信され、その後、送信済みのデータは、管理装置14から削除される。

図9は、リーダ/ライタから管理サーバへ送られるレポートの様子を説明するための説明図である。以下、本図を参照して説明する。

本図に示すように、レポート271は、表形式にて構成される。各行が、一つの決済を意味する。種類欄272には、決済の種類を示す情報が、ID欄273には、当該決済がされる可搬デバイス16のIDが、日時欄274には、当該決済がされた日時が、バリュー欄275には、当該決済に係る額が、それぞれ記録される。

決済の種類が「支払」であれば、当該行は、支払レポートに相当し、可搬デバイス16から店舗(提供者)へ電子バリューによる支払がされたことを意味する。決済の種類が「補充」であれば、店舗(提供者)から可搬デバイス16へ電子バリューのチャージがされたことを意味する。これらは、たとえば、可搬デバイス16に対して、減少コマンドや増加コマンドを送信して、成功した場合に記録される。

減少コマンドや増加コマンドは、店舗(提供者)と可搬デバイス16(被提供者)との間で、電子バリューの移動があったことを表す。したがって、電子マネーシステムの運営者と店舗(提供者)の間の貸し借りを管理するための、店舗(提供者)の電子マネー決済用アカウントに着目すれば、当該電子マネー決済用アカウントの残額は、決済が「支払」であれば増加し、「補充」であれば減少する。すなわち、レポート271における「支払」の総計から「補充」の総計を減算すれば、レポート271に係る期間における「電子マネーシステム運営者から店舗(提供者)への売上」が得られることになる。

また、決済が「課金」であれば、当該行は、課金レポートに存在し、可搬デバイス16に対応付けられるアカウントへの課金を要することを意味する。「課金」の場合には、店舗(提供者)の電子マネー決済用アカウントの残額は、変化しない。

オートチャージの場合には、1つのコマンドで支払とチャージが行われるが、チャージに呼応する課金は、管理サーバ13にて行われる。したがって、ID欄273および日時欄274の値が等しい「支払」行および「課金」行が記録されることになる。なお、オートチャージの場合の電子バリューと対価のやりとりは、可搬デバイス16の利用者と、管理サーバ13と、の間で行われる。したがって、本実施形態では、レポート271に対してオートチャージに係る「補充」行を記録することはない。

なお、明示的なチャージの場合には、可搬デバイス16の利用者から店舗(提供者)へ、現金、クレジットカード、デビットカード等により支払が行われ、その対価として、店舗(提供者)から可搬デバイス16へ電子バリューのチャージがされる。したがって、この場合には、独立した日時の「補充」行が記録されることになる。なお、本実施形態では、備考欄276に、チャージ元が現金であればその旨が、クレジットカードやデビットカードであればそのアカウント情報が、それぞれ記録されることとしている。ただし、チャージ元と店舗(提供者)との取引の詳細については、必ずしも管理サーバ13への報告を要しないので、アカウント情報を記載する必要はない。

さて、管理サーバ13は、レポート271を受信すると、「課金」行を抽出して、各「課金」行のID欄273に記載されたIDを取得し、そのIDに紐付けられたオートチャージ用のアカウントを、管理データベースから取得する。そして、当該アカウントに対してバリュー欄275に記載された額の課金を行う。

したがって、課金レポートは、クレジットカードに対する課金やデビットカードからの引き落としを管理サーバ13に行わせるための命令書に相当する。

このように、本実施例では、店頭での支払時には、クレジットカードに対する即時の与信やデビットカードからの即時の引き落としは行わない。店頭では、オートチャージ時には、課金や引き落としの予約をするだけで、実際の課金や引き落としは、後程行われるため、処理の即時性を向上させることができる。

一方で、第1条件乃至第3条件によってオートチャージの可否を決めることで、可搬デバイス16へのオートチャージ時点から見て将来に行われるクレジットカードに対する課金やデビットカードからの引き落としが失敗する可能性を、合理的に極く低く抑えることができる。

なお、ステップS215、S217におけるオートチャージおよび支払の際には、可搬デバイス16の残額更新時とチャージ更新時を基準時に更新するよう、コマンドに指定する。

一方、ステップS208における支払の際には、制御部103は、ステップS211と同様に基準時を定めて(フローチャート内には図示せず)、可搬デバイス16の残額更新時を当該基準時に更新するよう、コマンドに指定する。この際には、チャージ更新時は更新されない。

一方、IDが判定リストに含まれる場合(ステップS213；Yes)や、間隔が閾期間を超える場合(ステップS212；Yes)は、本実施例では、オートチャージも支払もできないこととして、ステップS251に進む。

さて、オートチャージを利用しない設定がされていたら(ステップS231;No)、すなわち、残額が支払額以上であるか否かを調べる(ステップS232)。残額が支払額以上であれば(ステップS232;Yes)、ステップS208に進み、残額が支払額未満であれば(ステップS232;No)、ステップS251に進む。これは、電子バリューによる通常のオートチャージを利用しない支払処理に相当する。

また、IDが使用可能でなければ(ステップS230;No)、ステップS251に進む。この際には、当該可搬デバイス16は使用できないので、被提供者は、現金、クレジットカード、デビットカード等で全額を支払うか、他の可搬デバイス16により支払うか、取引をやめることになる。

このように、本実施例によれば、閾期間を採用することにより判定リストのサイズを抑制して、管理装置14における記憶領域の圧迫を避けつつ高速な判定を可能とし、第1条件から第3条件を採用することにより、オートチャージを即時に行うとともにオートチャージの後に行われる課金が失敗される可能性を極く低くすることができ、適切にオートチャージを行うことができる。

また、リッチクライアント方式では、リーダ/ライタ2が有する不揮発性記憶装置の容量を増やすとコストが上昇してしまうが、本実施例によれば、判定リストのサイズを抑制することができるので、オートチャージを実現しつつ、リッチクライアントの導入コストを低減できるという利点がある。また、既に運用済みの低記憶容量のリッチクライアントに対しても、本実施例の判定リストを利用する技術を容易に適用することができる。

なお、上記の説明では、オートチャージと支払をまとめて行うことにより、可搬デバイス16に対する書き込みを1回で済ませることで、更新処理の高速化を図ることとし、書き込みエラーが生じる可能性を抑制していたが、NFCや可搬デバイス16の性能によっては、まず増加コマンドによりオートチャージを行い、その後に減少コマンドにより支払を行うこととしても良い。また、減少コマンドや増加コマンドで残額の変化量を指定するのではなく、新たな残額そのものを指定する更新コマンドを採用することとしても良い。

また、上記の説明では、閾期間をあらかじめ定めた固定の長さとしていたが、管理装置14における記憶容量に応じて判定リストのサイズに上限を定め、当該上限に至るまで、最近不具合の理由が生じた可搬デバイス16から順にIDを判定リストに登録していくこととしても良い。

この態様では、最後に判定リストに登録されたIDが、判定リスト中で最古に不具合が生じたIDということになる。そこで、このIDにおいて不具合が生じた日時から、判定リストの更改日時まで、の間隔を、閾期間とする。判定リストのダウンロード時には、この閾期間もリストサーバ12からダウンロードされる。

このほか、本実施例では、支払額、基準額、残額、増分額を参照して第1条件を判定した。すなわち、
(a)現在の残額から支払をすると、残額が基準額に満たなくなること、かつ、
(b)現在の残額に増分額を加算すると、支払ができること
を第1条件としていた。

より単純に、支払前の残額と基準額の大小により第1条件を判定することも可能である。

この態様では、一旦オートチャージが行われた後に、可搬デバイス16のみで支払が可能か否かが判定されることになる。

また、ストアドバリュー方式においては、チャージ更新時を、管理サーバ13やリーダ/ライタ2において管理されるレポートから取得することができる。

すなわち、レポート271から、可搬デバイス16のIDがID欄273に指定された「課金」行を検索すれば良い。「課金」行の日時欄274に記載された日時のうち最新の日時が、オートチャージがされた日時となる。また、レポート271が、可搬デバイス16のIDがID欄273に指定された「補充」行を検索し、備考欄276の情報が、当該IDの可搬デバイス16のチャージ元として対応付けられているアカウントと一致するものを検索する。検索された「補充」行の日時欄274に記載された日時のうち最新の日時が、オートチャージ用のアカウントから明示的なチャージがされた日時となる。これらの2つのうち最新のものが、この可搬デバイス16のチャージ更新時である。

この態様では、可搬デバイス16の所有者に気付かれないまま不正に取得した可搬デバイス16を閾期間以上放置して、判定リストから可搬デバイス16が消えるのを待った後、チャージ更新時を最近の日時に書き換える不正行為があったとしても、本当のチャージ更新時を取得することができるので、オートチャージを禁止することが可能である。

このほか、上記実施例では、判定リストをいわゆるブラックリスト方式により管理しているが、ホワイトリスト方式を採用することもできる。すなわち、オートチャージが設定され、最近の閾期間内に不具合が起きておらず、オートチャージが可能な可搬デバイス16のIDを、判定リストとする態様である。この態様においても、閾期間を設けることで、判定リストのサイズを抑制することができる。

上記実施例では、ステップS251において、支払ができない旨のメッセージを表示して処理を終了していた。

本態様では、管理装置14は、当該メッセージの表示にかえて、以下の処理を行う。

図10は、管理サーバに課金をさせて可搬デバイスにチャージする処理の流れを示すフローチャートである。以下、本図を参照して説明する。

まず、制御部103は、支払を可能にするための、チャージ額を定める(ステップS301)。支払を可能にするためには、可搬デバイス16の残額とチャージ額との和が、支払額以上でなければならない。したがって、チャージ額は、少なくとも、支払額から可搬デバイス16の残額を減算した値以上でなければならない。また、チャージ額は、あらかじめ定めた単位で、切りの良い額(たとえば100円や1ドル単位)とすることも多い。この場合には、支払額から可搬デバイス16の残額を減算し、その結果をあらかじめ定めた単位へ切り上げれば良い。

上記の例において、支払額が10円で、可搬デバイスの残額が1円であれば、チャージ額は、最小でも9円、切上げを行うならば100円となる。

ついで、制御部103は、可搬デバイス16のIDに対応付けられるアカウントに対して、求められたチャージ額による課金を行うよう、管理サーバ13に指示する(ステップS302)。当該アカウントがクレジットカードのものであれば、クレジットカード会社に対して直ちに与信を求め、あるいは、課金を行い、デビットカードのものであれば、銀行の口座からチャージ額を直ちに引き落とすことになる。

そして、制御部103は、管理サーバ13における課金が成功したか否かを判定する(ステップS303)。課金が成功していれば(ステップS303；Yes)、支払額がチャージ額以上であるか否かを調べる(ステップS304)。

支払額がチャージ額以上であれば(ステップS304；Yes)、制御部103は、通信部104により、可搬デバイス16に対して、支払額からチャージ額を減算した額を指定した減少コマンドを送信して、可搬デバイス16に対するチャージならびに可搬デバイス16による支払を行わせて(ステップS305)、支払レポートを作成してから(ステップS306)、本処理を終了する。

なお、補充および課金については、管理サーバ13と可搬デバイス16との間で完了した形となっており、管理装置14は、その仲介をしただけで、店舗(提供者)の電子マネー決済用アカウントにおける残額は変化しない。したがって、補充および課金については、レポート271への記録を要しない。

一方、支払額がチャージ額未満であれば(ステップS304；No)、制御部103は、通信部104により、可搬デバイス16に対して、チャージ額から支払額を減算した額を指定した増加コマンドを送信して、可搬デバイス16に対するチャージならびに可搬デバイス16による支払を行わせ(ステップS307)、ステップS306に進む。

なお、ステップS305、S307による可搬デバイス16の更新の際には、上記実施形態と同様に、可搬デバイス16の残額更新時とチャージ更新時を基準時に更新するよう、コマンドに指定する。

また、ステップS302において管理サーバ13が課金を済ませてしまっているので、課金レポートの生成は行わない。

一方、課金が失敗していれば(ステップS303；No)、チャージができないため支払ができない旨のメッセージを表示して(ステップS308)、本処理を終了する。

本実施例によれば、第1条件乃至第3条件が満たされない場合には、可搬デバイス16に対応付けられるアカウントに対して明示的な課金を行うことで、即時性には劣るものの、可搬デバイス16に対するチャージならびに可搬デバイス16による支払をすることができる。なお、本実施例では、可搬デバイス16の持ち主に対する明示的なチャージ額の確認は行わず、自動的にチャージ額を定める。したがって、通常のオートチャージよりも時間はかかるものの、可搬デバイス16の持ち主は、オートチャージと同程度の手間をかけるだけですむ。

上記実施例では、使用可否の判定リストとオートチャージ用判定リストの2つを用意していたが、本実施例では、判定リストの種々の態様を説明する。判定リストには、種々の理由により不具合が生じている可搬デバイス16のIDのみならず、その不具合の詳細な理由も、登録することができる。

このような判定リストに含まれる各要素の、最も単純な態様は、可搬デバイス16のIDを表すビット列と、不具合の理由を表すビット列と、を並べた整数値を、判定リストを表現する配列の要素とするものである。

たとえば、16桁の整数からなるIDは、54ビットで表現できる。また、
(1)可搬デバイス16の紛失、
(2)可搬デバイス16の盗難、
(3)可搬デバイス16の脱会、
(4)可搬デバイス16に対応付けられるクレジットカード・デビットカードの紛失、
(5)可搬デバイス16に対応付けられるクレジットカード・デビットカードの盗難、
(6)可搬デバイス16に対応付けられるクレジットカード・デビットカードの脱会、
(7)可搬デバイス16に対応付けられるクレジットカードの滞納、
(8)可搬デバイス16に対応付けられるクレジットカードの利用限度額超過もしくはデビットカードの残額不足、
の8通りの理由を表現するには、3ビットが必要である。さらに、将来の拡張用に7ビットを利用することとし、54+3+7=64ビット=8バイトの整数で、可搬デバイス16のIDおよび不具合の理由を表現する。

なお、この態様は、使用可否の判定リストの閾期間と、オートチャージの判定リストの閾期間と、を、一致させる態様に相当する。

このほか、判定リストを、複数の配列により表現する、という態様もある。たとえば、上記のように8通りの理由がある場合には、理由の種類の数と同じ8個の配列を用意する。各配列には、不具合の理由が対応付けられており、対応付けられた理由に基づく不具合が生じたIDを、当該配列の要素とするのである。各配列は1つのファイルにより表現し、判定リストを複数のファイルで表現することとしても良い。

このように、不具合が生じている可搬デバイス16のIDと、その理由と、が判定リストから取得できれば、不適切な支払そのものを禁じることができる。図11は、可搬デバイスの不具合の理由に応じて、可搬デバイスに対する制限を変化させる処理の流れを示すフローチャートである。以下、本図を参照して説明する。

本実施例では、ステップS206において可搬デバイス16のIDが取得されたら、当該IDが、紛失あるいは盗難による不具合が生じた可搬デバイス16のIDとして、判定リストに登録されているか否かを調べる(ステップS401)。

これらの理由は、可搬デバイス16による支払そのものを禁ずるべきものであるから、登録されていれば(ステップS401；Yes)、当該可搬デバイス16によるオートチャージも支払も制限するため、ステップS251に進む。

一方、登録されていなければ(ステップS401；No)、ステップS207に進む。この後、ステップS213では、判定リスト全体を参照して可搬デバイス16のIDが含まれるか否かを調べても良いし、判定リストのうち、脱会、滞納あるいは利用限度額超過に係る部分のみを参照することとしても良い。

そして、ステップS213において、判定リストにIDが含まれている場合(ステップS213；Yes)には、可搬デバイス16の残額が、支払額以上か否かを調べる(ステップS402)。

残額が支払額以上であれば(ステップS402;Yes)、ステップS208に進み、オートチャージは行わずに、支払を行わせる。

残額が支払額未満であれば(ステップS402;No)、ステップS251に進み、当該可搬デバイス16によるオートチャージも支払も制限する。

なお、ステップS251に進むのにかえて、上記実施例のように、管理サーバに課金をさせてしまってからチャージをする試行をしてみても良い。

本態様によれば、不具合の理由によって、可搬デバイス16自体を無効化したり、オートチャージのみをスキップするなど、制限の度合を変化させることができる。

本実施例では、判定リストが更改されるまでの間に可搬デバイス16を紛失等したときの不正利用を防止しようとするものである。

すなわち、判定リストが最後に更改された日時が、可搬デバイス16から取得されたチャージ更新時より後であれば、当該チャージに呼応する課金は既に試行されており、課金に失敗していれば、当該課金に対する可搬デバイス16のIDが判定リストに登録されているはずである。また、可搬デバイス16に紐付くクレジットカード等の紛失・盗難等があれば、オートチャージをしようとする際の判定リストには反映されているはずである。したがって、判定リストによるチェックをパスしたのであれば、その課金は比較的安全と考えられる。

一方、可搬デバイス16から取得されたチャージ更新時が、判定リストが最後に更改された日時より後であるということは、当該チャージに呼応する課金がまだ行われていない、あるいは、当該チャージの課金の成否が判定リストに反映されていない、ということを意味する。したがって、残高不足や利用限度額超過等によりチャージの課金ができないことがある。また、可搬デバイス16に紐付くクレジットカード等の紛失や盗難等の届出がされていても、オートチャージをしようとする際の判定リストに反映されていない可能性がある。したがって、チャージ更新時が判定リストの更改時より後であるときは、リスクが高いと考えられる。そこで、本実施例では、可搬デバイス16に生じた不具合の理由に応じて、可搬デバイス16による支払に制限を課す、あるいは、制限の強さを変更することとする。

ここで、電子マネーシステムでは、小額決済を即時的に行うため、1回あたりの支払額や、1日あたりの支払総額に上限を設けることが多い。そこで、本実施例では、支払の上限を下げることにより、可搬デバイス16による支払に制限を課すこととする。

上限の下げ方には、種々の態様がある。たとえば、上限をあらかじめ定めた額に下げる手法(たとえば、1日あたり2万円の上限を、1日あたり5千円に下げる等)、上限に1未満の係数を乗じる手法(たとえば、1回あたりおよび1日あたりの上限を半分にする等)などが、簡易な手法である。

このほか、判定リストが最後に更改された日時から可搬デバイス16から取得されたチャージ更新時までの経過時間の長短に応じて、制限の大小を調整する、という手法もある。

たとえば、経過時間が長くなればなるほど、上限そのものを小さくしたり、上限に乗じる係数を小さくする、という手法である。

このように支払が制限されることによって可搬デバイス16による支払ができなかった場合には、上記の態様と同様に、ステップS251に進むこととしても良いし、リストサーバ12や管理サーバ13に個別に問い合わせ、その結果に応じて、支払額の制限を除去することとしても良い。

本実施例によれば、可搬デバイス16における不具合が判定リストに反映されるまでの間の被害を抑制することができる。

可搬デバイス16における不具合の理由によっては、当該不具合が解消される日時を予測することができる。たとえば、クレジットカードの利用限度額を超過している場合には、当該クレジットカードについての月々の口座引き落としがされる予定日には、不具合が解消されている可能性が高い。また、デビットカードの口座の残高不足の場合には、当該口座に給与の振込がなされる予定日には、不具合が解消されている可能性が高い。

また、電子マネーシステムでは、アカウントに対する課金は、管理装置14から管理サーバ13へ課金レポートが送信された後に行われるから、判定リストの更改とアカウントへの課金には、時間差がある。

したがって、判定リストにIDが登録されている場合であっても、状況によっては、当該IDに対応付けられるアカウントからの課金ができる可能性がある。

そこで、本実施例では、リストサーバ12は、判定リストに含まれるIDに対応付けられるアカウントからの課金がまったくできない(リスクが高い)のか、それとも、できる可能性がある(リスクが低い)のか、を上記のような履歴や契約の内容から推定する。

そして、本実施例では、判定リストにIDが含まれる場合であっても、単にオートチャージや支払を禁止するのではなく、オートチャージの増分額や支払の額に、リスクに応じた制限を課すこととする。

この際に、リストサーバ12は、判定リストの配列において、推定されたリスクの順(昇順もしくは降順)に、IDを並べる。リスクが昇順になるようにIDを並べた場合は、判定リストの先頭側のIDはリスクが低く、末尾側のIDはリスクが高いことになる。すなわち、IDが判定リストにおいて登録された位置に応じてリスクの大小を見積もることができるのである。

たとえば、上記の例では、以下のように制限を課す態様が考えられる。
(1)判定リストの先頭から先頭側8分の1までは、オートチャージの増分額や支払の限度額を、可搬デバイス16等から取得された既定値の0.4倍とし、
(2)先頭側8分の1から8分の2までは、0.2倍とし、
(3)先頭側8分の2から8分の3までは、0.1倍とし、
(4)先頭側8分の3から末尾までは、0倍とする。

このように、各IDに対するリスクの情報を個別に伝達せずに、判定リスト中におけるIDの位置に応じて、当該IDに対する制限の大きさを定めることができる。上記(1)-(4)のような判定リスト中における位置と制限との対応付けは、あらかじめ固定しておいても良いし、リストサーバ12からダウンロードされるようにしても良い。

本実施例によれば、可搬デバイス16のIDのリスクに応じて制限を課すことで、可搬デバイス16が利用できる局面を増やすとともに、リスクに応じた制限を簡易な計算によって即時的に求めることができる。しかも、リーダ/ライタ2等の記憶領域の使用量は、上記実施例と同程度で済み、容量を圧迫することがない。

本発明によれば、即時性、信頼性ならびにPOS端末の負荷を考慮しつつ、電子マネーの残額を管理する可搬デバイスに対する残額の補充や当該可搬デバイスによる支払の可否を、適切に判定する管理装置、当該管理装置が実行する管理方法、ならびに、当該管理装置で実行されるプログラムを提供することができる。

11 電子マネーシステム
12 リストサーバ
13 管理サーバ
14 管理装置
15 コンピュータ通信網
16 可搬デバイス
18 課金センター
61 チェックリスト
62 ID欄
63 日時欄
71 判定リスト
102 保持部
103 制御部
104 通信部
271 レポート
272 種類欄
273 ID欄
274 日時欄
275 バリュー欄
276 備考欄

Claims (15)

1. リストサーバにより更改される判定リストを保持する保持部、
   可搬デバイスと通信部を介して通信することにより前記可搬デバイスを制御する制御部、
   を備え、
   支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記制御部は、前記可搬デバイスから、前記可搬デバイスのID、残額ならびに更新時を取得し、
   前記取得された残額に係る第1条件が満たされ、前記取得された更新時に係る第2条件が満たされ、前記取得されたIDと前記保持された判定リストとに係る第3条件が満たされると、前記制御部は、
   (a)前記取得された残額および所定の増分額から前記支払を行って前記可搬デバイスの残額を更新し、現在を表す基準時に前記可搬デバイスの更新時を更新し、
   (b)前記取得されたIDに対応付けられるアカウントに対して前記所定の増分額に相応する課金を管理サーバに行わせるための課金レポートを生成する
   管理装置であって、
   前記取得された更新時から前記定められた基準時までの間隔が閾期間を超えていると、前記第2条件は満たされず、前記制御部は、前記可搬デバイスに対する更新ならびに課金レポートの生成を行わず、
   前記取得されたIDが、前記判定リストに登録されたIDのいずれかと一致すると、前記第3条件は満たされず、前記制御部は、前記可搬デバイスに対する更新ならびに課金レポートの生成を行わず、
   前記リストサーバは、前記判定リストが更改される時点に基づいて開始時点を定め、前記定められた開始時点から前記判定リストが更改される時点までの間に使用が認められない事由が生じたアカウントに対応付けられるIDを、前記判定リストに登録することにより、前記判定リストを更改し、
   前記開始時点から前記判定リストが更改される時点までの間隔は、前記閾期間に対して所定の誤差範囲内である
   ことを特徴とする管理装置。
2. 前記ID、前記残額ならびに前記更新時が取得されると、前記制御部は、前記第1条件が満たされるか否かを判定し、前記第1条件が満たされると判定された後に、前記第2条件が満たされるか否かを判定し、前記第2条件が満たされると判定された後に、前記第3条件が満たされるか否かを判定する
   ことを特徴とする請求項1に記載の管理装置。
3. 前記生成された課金レポートは、前記管理サーバへ送付され、
   前記課金レポートが送付された前記管理サーバにより、当該課金レポートに係る課金についての与信が、当該課金レポートに係るIDに対応付けられるアカウントに対して行われる
   ことを特徴とする請求項1に記載の管理装置。
4. 前記第1条件が満たされ、前記第2条件が満たされなければ、前記制御部は、
   他の課金についての与信を前記取得されたIDに対応付けられるアカウントに対して行うよう、前記管理サーバに指示し、
   前記管理サーバに指示された前記与信が成功してから、前記取得された残額および前記他の課金の額から前記可搬デバイスによる支払を行って前記可搬デバイスの残額を更新する、
   ことを特徴とする請求項3に記載の管理装置。
5. 前記通信部が前記支払に供される前記可搬デバイスと通信可能となると、前記制御部は、
   (p)新たな残額を、前記取得された残額と前記所定の増分額と前記支払の支払額とに基づいて求め、
   (q)前記取得されたIDによる前記支払額の支払がされたことを前記管理サーバに知らせるための支払レポートを生成する
   ことを特徴とする請求項1に記載の管理装置。
6. 前記リストサーバおよび前記管理サーバとコンピュータ通信網を介して通信し、前記保持部ならびに前記通信部を有する端末を備え、
   前記制御部は、前記端末がプログラムを実行することにより実現される
   ことを特徴とする請求項1に記載の管理装置。
7. 前記取得された更新時が、前記リストサーバにより前記判定リストが最後に更改された更改時より後であると、前記制御部は、前記可搬デバイスによる支払に制限を課す
   ことを特徴とする請求項1に記載の管理装置。
8. リストサーバにより更改される判定リストを保持する保持部、
   可搬デバイスと通信部を介して通信することにより前記可搬デバイスを制御する制御部、
   を備え、
   支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記制御部は、前記可搬デバイスから、前記可搬デバイスのIDならびに更新時を取得し、前記取得されたIDを、前記保持された判定リストと対比して、前記可搬デバイスによる前記支払の可否を決定し、
   前記可搬デバイスによる前記支払が可能と決定され、前記取得された更新時が、前記リストサーバにより前記判定リストが最後に更改された更改時より後であると、前記制御部は、前記可搬デバイスによる前記支払に制限を課す
   ことを特徴とする管理装置。
9. 前記リストサーバは、前記判定リストを、所定のスケジュールに基づいて更改し、
   前記制御部は、前記所定のスケジュールにおいて前記判定リストを更改すべきとされている日時のうち、現在よりも以前の最新の日時を、前記最後に更改された更改時とする
   ことを特徴とする請求項7または8に記載の管理装置。
10. 前記制限は、前記最後に更改された更改時から前記取得された更新時までの期間に応じて定められる
    ことを特徴とする請求項7または8に記載の管理装置。
11. 前記判定リストは、当該判定リストに登録されるIDに対応付けられるアカウントに対して前記リストサーバにより推定されたリスクの順にソートされ、
    前記制限は、前記取得されたIDが前記判定リストにおいて登録された位置に応じて定められる
    ことを特徴とする請求項7または8に記載の管理装置。
12. リストサーバにより更改される判定リストが保持される保持部、ならびに、可搬デバイスと通信可能な通信部を制御する管理装置が実行する管理方法であって、
    支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記管理装置は、前記可搬デバイスから、前記可搬デバイスのID、残額ならびに更新時を取得し、
    前記取得された残額に係る第1条件が満たされ、前記取得された更新時に係る第2条件が満たされ、前記取得されたIDと前記保持された判定リストとに係る第3条件が満たされると、前記管理装置は、
    (a)現在を表す基準時を定め、
    (b)前記取得された残額および所定の増分額から前記支払を行って前記可搬デバイスの残額を更新し、前記可搬デバイスの更新時を前記定められた基準時に更新し、
    (c)前記取得されたIDに対応付けられるアカウントに対して前記所定の増分額に相応する課金を管理サーバに行わせるための課金レポートを生成し、
    前記取得された更新時から前記定められた基準時までの間隔が閾期間を超えていると、前記第2条件は満たされず、前記管理装置は、前記可搬デバイスに対する更新ならびに課金レポートの生成を行わず、
    前記取得されたIDが、前記判定リストに登録されたIDのいずれかと一致すると、前記第3条件は満たされず、前記管理装置は、前記可搬デバイスに対する更新ならびに課金レポートの生成を行わず、
    前記リストサーバは、前記判定リストが更改される時点に基づいて開始時点を定め、前記定められた開始時点から前記判定リストが更改される時点までの間に使用が認められない事由が生じたアカウントに対応付けられるIDを、前記判定リストに登録することにより、前記判定リストを更改し、
    前記開始時点から前記判定リストが更改される時点までの間隔は、前記閾期間に対して所定の誤差範囲内である
    ことを特徴とする管理方法。
13. リストサーバにより更改される判定リストが保持される保持部、ならびに、可搬デバイスと通信可能な通信部を制御する管理装置が実行する管理方法であって、
    支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記管理装置は、前記可搬デバイスから、前記可搬デバイスのIDならびに当該可搬デバイスの残額が更新された更新時を取得し、前記取得されたIDを、前記保持された判定リストと対比して、前記可搬デバイスによる前記支払の可否を決定し、
    前記可搬デバイスによる前記支払が可能と決定され、前記取得された更新時が、前記リストサーバにより前記判定リストが最後に更改された更改時より後であると、前記管理装置は、前記可搬デバイスによる前記支払に制限を課す
    ことを特徴とする管理方法。
14. リストサーバにより更改される判定リストが保持される保持部、ならびに、可搬デバイスと通信可能な通信部を制御するコンピュータを、制御部として機能させるプログラムであって、
    支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記制御部は、前記可搬デバイスから、前記可搬デバイスのID、残額ならびに更新時を取得し、
    前記取得された残額に係る第1条件が満たされ、前記取得された更新時に係る第2条件が満たされ、前記取得されたIDと前記保持された判定リストとに係る第3条件が満たされると、前記制御部は、
    (a)現在を表す基準時を定め、
    (b)前記取得された残額および所定の増分額から前記支払を行って前記可搬デバイスの残額を更新し、前記可搬デバイスの更新時を前記定められた基準時に更新し、
    (c)前記取得されたIDに対応付けられるアカウントに対して前記所定の増分額に相応する課金を管理サーバに行わせるための課金レポートを生成し、
    前記取得された更新時から前記定められた基準時までの間隔が閾期間を超えていると、前記第2条件は満たされず、前記制御部は、前記可搬デバイスに対する更新ならびに課金レポートの生成を行わず、
    前記取得されたIDが、前記判定リストに登録されたIDのいずれかと一致すると、前記第3条件は満たされず、前記制御部は、前記可搬デバイスに対する更新ならびに課金レポートの生成を行わず、
    前記リストサーバは、前記判定リストが更改される時点に基づいて開始時点を定め、前記定められた開始時点から前記判定リストが更改される時点までの間に使用が認められない事由が生じたアカウントに対応付けられるIDを、前記判定リストに登録することにより、前記判定リストを更改し、
    前記開始時点から前記判定リストが更改される時点までの間隔は、前記閾期間に対して所定の誤差範囲内である
    ことを特徴とするプログラム。
15. リストサーバにより更改される判定リストが保持される保持部、ならびに、可搬デバイスと通信可能な通信部を制御するコンピュータを、制御部として機能させるプログラムであって、
    支払に供される前記可搬デバイスと前記通信部が通信可能となると、前記制御部は、前記可搬デバイスから、前記可搬デバイスのIDならびに当該可搬デバイスの残額が更新された更新時を取得し、前記取得されたIDを、前記保持された判定リストと対比して、前記可搬デバイスによる前記支払の可否を決定し、
    前記可搬デバイスによる前記支払が可能と決定され、前記取得された更新時が、前記リストサーバにより前記判定リストが最後に更改された更改時より後であると、前記制御部は、前記可搬デバイスによる前記支払に制限を課す
    ことを特徴とするプログラム。

Images