TWI536290B

TWI536290B - Management devices, management methods, and programs

Info

Publication number: TWI536290B
Application number: TW104113284A
Authority: TW
Inventors: Wataru SUZUKAKE
Original assignee: Rakuten Inc
Priority date: 2014-04-25
Filing date: 2015-04-24
Publication date: 2016-06-01
Also published as: JPWO2015162799A1; TW201606665A; JP5814493B1; WO2015162799A1

Description

管理裝置、管理方法、以及程式

本發明係有關於對保持電子貨幣之餘額的可攜裝置補充餘額或管理該當可攜裝置所致之支付的管理裝置、該當管理裝置所執行的管理方法、以及該當管理裝置上所被執行的程式。

藉由支付對價以接受商品或服務之提供的交易中，利用電子貨幣的系統已被提出許多種。在電子貨幣系統中，不是將現金放入錢包而攜行，改為與可攜裝置(相當於錢包)建立對應，藉由以電子資訊所表現的電子額值(相當於錢包中的現金)，來進行支付。

電子額值的支付之際，支付者係將可攜裝置，接近於商品或服務之提供者所操作的讀寫機，藉此，僅需要靠上去很短的時間，在可攜裝置與讀寫機之間就會建立NFC(Near Field Communication；近場通訊)，藉由該通訊，就可使與可攜裝置建立對應的電子額值，減少掉支付的量。在NFC中，雖然不需要使可攜裝置與讀寫機接觸，但典型上必須要使距離靠近到數mm左右。

作為可攜裝置，在現金卡或信用卡中內嵌NFC用之電子電路而成者，係被廣泛使用。該電子電路，一般而言，係藉由從讀寫機所發出的NFC用之電波所致之電磁感應所產生的電力而動作。

另一方面，在行動電話或智慧型手機等之攜帶型終端中，和上記同樣地在內部內嵌有NFC用之電子電路者已被廣泛利用，除此以外，也有提案要在電話通訊用之SIM(Subscriber Identity Card)卡內設置NFC用之通訊機能。這些情況下，除了可以把讀寫機所發出之電波當作電力源，還可從攜帶型終端之本體所具備的電池，接受電力之供給。

可攜裝置所被建立對應的電子額值之餘額，係被可攜裝置內的電子電路、或是電子貨幣伺服器所管理，隨應於與可攜裝置之通訊所交換的指令或電子貨幣伺服器中的處理而增減。

而在電子額值之餘額比支付之額度還少時，不會向可攜裝置之擁有者進行明示性詢問而自動地，對可攜裝置所被建立對應的帳戶進行所定額之授信，若授信成功，則令電子額值之餘額增加該當所定額的技術，已被提出(專利文獻1)。如此，在特定的條件下，以可攜裝置所被建立對應的帳戶中的課金為代價，使電子額值之餘額自動增加的機能，稱為「自動入金」或「自動加值」。

專利文獻1中係提出了：在欲自動加值時，對管理帳戶的信用卡公司每次都委託授信的手法(段落 0041)；將登錄有無法授信之信用卡之帳戶的授信清單，配送給POS(Point Of Sales)終端，在欲自動加值時，將可攜裝置所被建立對應之信用卡之帳戶和拒絕清單進行比對的手法(段落0054)；在可攜裝置中登錄最近的信用卡利用日期時間，基於欲自動加值的時點和已被登錄的利用日期時間的差，決定是否可自動加值的手法(段落0062)。

[先前技術文獻] [專利文獻]

[專利文獻1]日本特開2002-366862號公報

然而，每次都要從信用卡公司取得授信的手法中，通訊以及授信之判斷上需要時間，因此會損及電子貨幣所致之支付的即時性。在藉由授信清單的手法中，若授信清單變得巨大，則會壓迫POS終端的記憶領域，此外，判定上也會更花時間。在利用信用卡之利用日期時間的手法中，會欠缺信賴性，此外，支付只能專屬利用電子貨幣，對於以信用卡為主而利用自動加值的使用者等來說，難以適用。

本發明係為了解決上記課題，目的在於提供一種，考慮到即時性、信賴性以及POS終端之負荷，同時適切判定對於管理電子貨幣之餘額的可攜裝置可否進行餘額之補充或該當可攜裝置所致之支付的管理裝置、該當管理裝置所執行之管理方法、以及該當管理裝置上所被執行的程式。

於本發明所述之管理裝置，其中，保持部，係將會被清單伺服器所更改的判定清單，予以保持；控制部，係藉由通訊部而與可攜裝置進行通訊以控制前記可攜裝置；一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記控制部，係從前記可攜裝置，取得前記可攜裝置之ID、餘額以及更新時刻；一旦前記所被取得之餘額所涉及之第1條件被滿足，前記所被取得之更新時刻所涉及之第2條件被滿足，前記所被取得之ID與前記所被保持之判定清單所涉及之第3條件被滿足，則前記控制部係：(a)從前記所被取得之餘額及所定之增量額進行前記支付而將前記可攜裝置之餘額予以更新，將前記可攜裝置之更新時刻，更新成表示現在的基準時刻；(b)生成用來令管理伺服器對前記所被取得之ID所被建立對應的帳戶進行相應於前記所定之增量額的課金所需之課金報告。

11‧‧‧電子貨幣系統

12‧‧‧清單伺服器

13‧‧‧管理伺服器

14‧‧‧管理裝置

15‧‧‧電腦通訊網

16‧‧‧可攜裝置

18‧‧‧課金中心

61‧‧‧檢查清單

62‧‧‧ID欄

63‧‧‧日期時間欄

71‧‧‧判定清單

102‧‧‧保持部

103‧‧‧控制部

104‧‧‧通訊部

271‧‧‧報告

272‧‧‧種類欄

273‧‧‧ID欄

274‧‧‧日期時間欄

275‧‧‧額值欄

276‧‧‧備註欄

[圖1]本發明的實施例所述之POS終端及讀寫機之概要的說明圖。

[圖2]本發明的實施例所述之系統之概要的說明圖。

[圖3]本發明的實施例所述之可攜裝置之記憶裝置中所被確保之記憶領域之樣子的說明圖。

[圖4]本發明的實施例所述之判定清單之更改處理的流程的流程圖。

[圖5A]用來說明檢查清單的更改前之樣子的說明圖。

[圖5B]用來說明檢查清單更改中之樣子的說明圖。

[圖5C]用來說明檢查清單的更改後之樣子的說明圖。

[圖6A]用來說明判定清單的更改前之樣子的說明圖。

[圖6B]用來說明判定清單的更改後之樣子的說明圖。

[圖7]本實施例所述之管理裝置之概要構成的說明圖。

[圖8]本實施例所述之管理裝置中所執行之處理的流程的流程圖。

[圖9]用來說明從讀寫機被送往管理伺服器的報告之樣子的說明圖。

[圖10]令管理伺服器進行課金而對可攜裝置進行加值的處理之流程的流程圖。

[圖11]隨應於可攜裝置不良之理由，而改變對可攜裝置之限制的處理之流程的流程圖。

以下說明本發明的實施形態。此外，本實施形態係用於說明，並非限制本案發明的範圍。因此，只要是當業者自然可以採用這些各要素或全要素做均等置換的實施形態，但這些實施形態仍包含在本發明之範圍中。

[實施例1]

電子貨幣系統中的電子額值，係具有類似於現金的價值。電子額值，係可和現金相互或是從一方往另一方交換，可用相同的通貨單位來管理，也可採用獨自之單位而在交換之際做換算。又，隨應於使用者之行動(商品之購入或對問卷之回答、光臨店舖等)而被賦予的各種點數，也可當成電子額值來利用。

圖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)傳輸媒體，而進行配送。又，該程式，係可記錄在CD、軟碟、硬碟、光磁碟、DVD、磁帶、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)。

然後，作成用來令管理伺服器13對所被取得之ID所被建立對應的帳戶進行相當於增量額之課金所需之課金報告(步驟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，將其當作判定清單的態樣。即使在該態樣下，仍藉由設置臨界期間，來抑制判定清單之大小。

[實施例2]

在上記實施例中，於步驟S251中，是顯示無法支付之意旨的訊息而結束處理。

在本態樣中，管理裝置14，係取代該當訊息之顯示，改為進行以下之處理。

圖10係令管理伺服器進行課金而對可攜裝置進行加值的處理之流程的流程圖。以下參照本圖來說明。

首先，控制部103係決定用來使支付成為可能所需之加值額(步驟S301)。為了使支付成為可能，可攜裝置16的餘額與加值額之和，必須要為支付額以上。因此，加值額係必須至少要為，從支付額減去可攜裝置16的餘額所得的值以上。又，加值額，通常是設定成預定之單位、且為適當的額度(例如100日圓或1美金單位)。此情況下，從支付額減算可攜裝置16的餘額，將其結果往預定之單位做無條件進位即可。

在上記的例子中，若支付額是10圓，可攜裝置之餘額係為1圓，則加值額係最小也要9圓，若進行無條件進位則為100圓。

接下來，控制部103係向管理伺服器13下達指示，令其對可攜裝置16的ID所被建立對應的帳戶，進行所求出之加值額所致之課金(步驟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的持有者係只需要進行和自動加值相同程度的手續即可。

[實施例3]

在上記實施例中，雖然準備有使用可否之判定清單與自動加值用判定清單這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本身無效化，或僅略過自動加值等，可以改變限制之程度。

[實施例4]

在本實施例中，係在判定清單被更改為止之期間中，發生可攜裝置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中的不良情況被反映至判定清單為止之期間的被害。

[實施例5]

藉由可攜裝置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終端之負荷，同時適切判定對於管理電子貨幣之餘額的可攜裝置可否進行餘額之補充或該當可攜裝置所致之支付的管理裝置、該當管理裝置所執行之管理方法、以及該當管理裝置上所被執行的程式。

14‧‧‧管理裝置

102‧‧‧保持部

103‧‧‧控制部

104‧‧‧通訊部

Claims

一種管理裝置，其特徵為，具備：保持部，係將會被清單伺服器所更改的判定清單，予以保持；控制部，藉由通訊部而與可攜裝置進行通訊以控制前記可攜裝置；一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記控制部，係從前記可攜裝置，取得前記可攜裝置之ID、餘額以及更新時刻；一旦前記所被取得之餘額所涉及之第1條件被滿足，前記所被取得之更新時刻所涉及之第2條件被滿足，前記所被取得之ID與前記所被保持之判定清單所涉及之第3條件被滿足，則前記控制部係：(a)從前記所被取得之餘額及所定之增量額進行前記支付而將前記可攜裝置之餘額予以更新，將前記可攜裝置之更新時刻，更新成表示現在的基準時刻；(b)生成用來令管理伺服器對前記所被取得之ID所被建立對應的帳戶進行相應於前記所定之增量額的課金所需之課金報告；其中，若前記所被取得之更新時刻起至前記所被決定的基準時刻為止之間隔超過臨界期間，則前記第2條件係不被滿足，前記控制部係不進行對前記可攜裝置的更新以及課金報告之生成；若前記所被取得之ID與前記判定清單中所被登錄之ID之任一者一致，則前記第3條件係不被滿足，前記控制部係不進行對前記可攜裝置的更新以及課金報告之生成；前記清單伺服器，係基於前記判定清單被更改的時點而決定開始時點，將從前記所被決定的開始時點起至前記判定清單被更改的時點為止之期間中發生了不認可使用之事由的帳戶所被建立對應的ID，登錄至前記判定清單，藉此以更改前記判定清單；從前記開始時點起至前記判定清單被更改的時點為止之間隔，係相對於前記臨界期間而在所定之誤差範圍內。
如請求項1所記載之管理裝置，其中，一旦前記ID、前記餘額以及前記更新時刻被取得，則前記控制部係判定前記第1條件是否被滿足，在判定前記第1條件是被滿足後，判定前記第2條件是否被滿足，在判定前記第2條件是被滿足後，判定前記第3條件是否被滿足。
如請求項1所記載之管理裝置，其中，前記所被生成的課金報告，係被送往前記管理伺服器；由前記課金報告所被送達之前記管理伺服器，對該當課金報告所涉及之ID所被建立對應的帳戶，進行關於該當課金報告所涉及之課金的授信。
如請求項3所記載之管理裝置，其中，若前記第1條件被滿足，前記第2條件不被滿足，則前記控制部係向前記管理伺服器下達指示，使其對前記所被取得之ID所被建立對應的帳戶，進行關於其他課金的授信；對前記管理伺服器所指示的前記授信成功之後，從前記所被取得之餘額及前記其他課金之額度進行前記可攜裝置所致之支付，並更新前記可攜裝置之餘額。
如請求項1所記載之管理裝置，其中，一旦前記通訊部變成可和用於前記支付的前記可攜裝置進行通訊，則前記控制部係：(p)根據前記所被取得之餘額、前記所定之增量額、和前記支付之支付額，而求出新的餘額；(q)生成用來向前記管理伺服器告知，前記所被取得之ID所致之前記支付額之支付已被進行所需之支付報告。
如請求項1所記載之管理裝置，其中，具備：終端，其係透過電腦通訊網而與前記清單伺服器及前記管理伺服器進行通訊，並具有前記保持部以及前記通訊部；前記控制部係藉由前記終端執行程式而被實現。
如請求項1所記載之管理裝置，其中，若前記所被取得之更新時刻，是比前記清單伺服器最後更改前記判定清單的更改時刻還晚，則前記控制部係對前記可攜裝置所致之支付施加限制。
一種管理裝置，其特徵為，具備：保持部，係將會被清單伺服器所更改的判定清單，予以保持；控制部，藉由通訊部而與可攜裝置進行通訊以控制前記可攜裝置；一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記控制部，係從前記可攜裝置，取得前記可攜裝置之ID以及更新時刻，將前記所被取得之ID，與前記所被保持之判定清單進行比對，決定可否進行前記可攜裝置所致之前記支付；一旦前記可攜裝置所致之前記支付被決定成可能，且若前記所被取得之更新時刻，是比前記判定清單被前記清單伺服器最後更改之更改時刻還晚，則前記控制部係對前記可攜裝置所致之前記支付施加限制。
如請求項7或8所記載之管理裝置，其中，前記清單伺服器，係將前記判定清單，基於所定之時程表而加以更改；前記控制部，係在前記所定之時程表中被設成應更改前記判定清單的日期時間之中，將比現在還早的最新之日期時間，視為前記被最後更改之更改時刻。
如請求項7或8所記載之管理裝置，其中，前記限制，係隨應於從前記被最後更改之更改時刻起至前記所被取得之更新時刻為止之期間，而被決定。
如請求項7或8所記載之管理裝置，其中，前記判定清單，係按照前記清單伺服器針對該當判定清單中所被登錄之ID所被建立對應的帳戶所推定的風險之順序，而被排序；前記限制，係隨應於前記所被取得之ID在前記判定清單中所被登錄的位置，而被決定。
一種管理方法，係為控制保持有會被清單伺服器所更改之判定清單的保持部、以及可與可攜裝置進行通訊的通訊部的管理裝置所執行的管理方法，其特徵為，一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記管理裝置，係從前記可攜裝置，取得前記可攜裝置之ID、餘額以及更新時刻；一旦前記所被取得之餘額所涉及之第1條件被滿足，前記所被取得之更新時刻所涉及之第2條件被滿足，前記所被取得之ID與前記所被保持之判定清單所涉及之第3條件被滿足，則前記管理裝置係：(a)決定表示現在的基準時刻；(b)從前記所被取得之餘額及所定之增量額進行前記支付而將前記可攜裝置之餘額予以更新，將前記可攜裝置之更新時刻，更新成前記所被決定的基準時刻；(c)生成用來令管理伺服器對前記所被取得之ID所被建立對應的帳戶進行相應於前記所定之增量額的課金所需之課金報告；若前記所被取得之更新時刻起至前記所被決定的基準時刻為止之間隔超過臨界期間，則前記第2條件係不被滿足，前記管理裝置係不進行對前記可攜裝置的更新以及課金報告之生成；若前記所被取得之ID與前記判定清單中所被登錄之ID之任一者一致，則前記第3條件係不被滿足，前記管理裝置係不進行對前記可攜裝置的更新以及課金報告之生成；前記清單伺服器，係基於前記判定清單被更改的時點而決定開始時點，將從前記所被決定的開始時點起至前記判定清單被更改的時點為止之期間中發生了不認可使用之事由的帳戶所被建立對應的ID，登錄至前記判定清單，藉此以更改前記判定清單；從前記開始時點起至前記判定清單被更改的時點為止之間隔，係相對於前記臨界期間而在所定之誤差範圍內。
一種管理方法，係為控制保持有會被清單伺服器所更改之判定清單的保持部、以及可與可攜裝置進行通訊的通訊部的管理裝置所執行的管理方法，其特徵為，一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記管理裝置，係從前記可攜裝置，取得前記可攜裝置之ID以及該當可攜裝置之餘額所被更新之更新時刻，將前記所被取得之ID，與前記所被保持之判定清單進行比對，決定可否進行前記可攜裝置所致之前記支付；一旦前記可攜裝置所致之前記支付被決定成可能，且若前記所被取得之更新時刻，是比前記判定清單被前記清單伺服器最後更改之更改時刻還晚，則前記管理裝置係對前記可攜裝置所致之前記支付施加限制。
一種程式，係為令控制保持有會被清單伺服器所更改之判定清單的保持部、以及可與可攜裝置進行通訊的通訊部的電腦，成為控制部而發揮機能的程式，其特徵為，一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記控制部，係從前記可攜裝置，取得前記可攜裝置之ID、餘額以及更新時刻；一旦前記所被取得之餘額所涉及之第1條件被滿足，前記所被取得之更新時刻所涉及之第2條件被滿足，前記所被取得之ID與前記所被保持之判定清單所涉及之第3條件被滿足，則前記控制部係：(a)決定表示現在的基準時刻；(b)從前記所被取得之餘額及所定之增量額進行前記支付而將前記可攜裝置之餘額予以更新，將前記可攜裝置之更新時刻，更新成前記所被決定的基準時刻；(c)生成用來令管理伺服器對前記所被取得之ID所被建立對應的帳戶進行相應於前記所定之增量額的課金所需之課金報告；若前記所被取得之更新時刻起至前記所被決定的基準時刻為止之間隔超過臨界期間，則前記第2條件係不被滿足，前記控制部係不進行對前記可攜裝置的更新以及課金報告之生成；若前記所被取得之ID與前記判定清單中所被登錄之ID之任一者一致，則前記第3條件係不被滿足，前記控制部係不進行對前記可攜裝置的更新以及課金報告之生成；前記清單伺服器，係基於前記判定清單被更改的時點而決定開始時點，將從前記所被決定的開始時點起至前記判定清單被更改的時點為止之期間中發生了不認可使用之事由的帳戶所被建立對應的ID，登錄至前記判定清單，藉此以更改前記判定清單；從前記開始時點起至前記判定清單被更改的時點為止之間隔，係相對於前記臨界期間而在所定之誤差範圍內。
一種程式，係為令控制保持有會被清單伺服器所更改之判定清單的保持部、以及可與可攜裝置進行通訊的通訊部的電腦，成為控制部而發揮機能的程式，其特徵為，一旦用於支付的前記可攜裝置與前記通訊部變成可以通訊，則前記控制部，係從前記可攜裝置，取得前記可攜裝置之ID以及該當可攜裝置之餘額所被更新之更新時刻，將前記所被取得之ID，與前記所被保持之判定清單進行比對，決定可否進行前記可攜裝置所致之前記支付；一旦前記可攜裝置所致之前記支付被決定成可能，且若前記所被取得之更新時刻，是比前記判定清單被前記清單伺服器最後更改之更改時刻還晚，則前記控制部係對前記可攜裝置所致之前記支付施加限制。