JP6455863B2 - 受付装置、受付装置の制御方法、及びプログラム - Google Patents
受付装置、受付装置の制御方法、及びプログラム Download PDFInfo
- Publication number
- JP6455863B2 JP6455863B2 JP2013169569A JP2013169569A JP6455863B2 JP 6455863 B2 JP6455863 B2 JP 6455863B2 JP 2013169569 A JP2013169569 A JP 2013169569A JP 2013169569 A JP2013169569 A JP 2013169569A JP 6455863 B2 JP6455863 B2 JP 6455863B2
- Authority
- JP
- Japan
- Prior art keywords
- payment
- frequency
- remaining frequency
- remaining
- replenishment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 132
- 230000008859 change Effects 0.000 claims description 76
- 230000004044 response Effects 0.000 claims description 48
- 238000012508 change request Methods 0.000 claims description 24
- 230000001502 supplementing effect Effects 0.000 claims description 15
- 239000013589 supplement Substances 0.000 claims description 10
- 230000000153 supplemental effect Effects 0.000 claims description 6
- 238000012937 correction Methods 0.000 claims description 3
- 238000012545 processing Methods 0.000 description 75
- 230000008569 process Effects 0.000 description 70
- 238000004891 communication Methods 0.000 description 29
- 230000006870 function Effects 0.000 description 23
- 230000005540 biological transmission Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 9
- 230000015654 memory Effects 0.000 description 7
- 230000010365 information processing Effects 0.000 description 6
- 238000013500 data storage Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000003936 working memory Effects 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000010923 batch production Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Landscapes
- Cash Registers Or Receiving Machines (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
Description
本発明は、受付装置、受付装置の制御方法、及びプログラムに関する。
近年、電子マネーの使用が広く普及してきている。電子マネーでは、バリューと呼ばれる金額情報を貨幣価値に対応させ、バリュー残高を増減することにより資金決済を行う。
電子マネーカード１００は、ユーザが所持しているＩＣカードであり、内蔵又は装着する汎用ＩＣモジュール２５にバリューの残高、汎用ＩＣモジュール２５を特定するＩＣモジュールＩＤ、電子マネー番号などが記録されている。また、当該汎用ＩＣモジュール２５を内蔵又は装着した携帯電話などの携帯端末も存在する。
このようにユーザ側の汎用ＩＣモジュール２５でバリューを保持する方式はストアードバリュー型と呼ばれている。
電子マネーカード１００は、ユーザが所持しているＩＣカードであり、内蔵又は装着する汎用ＩＣモジュール２５にバリューの残高、汎用ＩＣモジュール２５を特定するＩＣモジュールＩＤ、電子マネー番号などが記録されている。また、当該汎用ＩＣモジュール２５を内蔵又は装着した携帯電話などの携帯端末も存在する。
このようにユーザ側の汎用ＩＣモジュール２５でバリューを保持する方式はストアードバリュー型と呼ばれている。
このストアードバリュー型の電子マネーの決済を受け付ける決済端末７は、実店舗や自動販売機などに設置されており、電子マネーカード１００や携帯端末の汎用ＩＣモジュール２５と近距離の無線通信を行い、汎用ＩＣモジュール２５に記憶されたバリュー残高を減額することによりバリューによる決済を実行する。
決済端末７は、電子マネーサーバ２に接続せずに、決済処理をユーザの汎用ＩＣモジュール２５との間でローカルに完結させ、取引履歴をログデータとして記録しておき、後ほど、定期、又は不定期にログデータを一括して電子マネーサーバ２に送信する。
このような、ストアードバリュー型電子マネーのシステムでは、予め汎用ＩＣモジュール２５にバリュー残高を記憶しており、決済時にこれを減額するため、バリューが不足していると、決済が行えないこととなる。
決済端末７は、電子マネーサーバ２に接続せずに、決済処理をユーザの汎用ＩＣモジュール２５との間でローカルに完結させ、取引履歴をログデータとして記録しておき、後ほど、定期、又は不定期にログデータを一括して電子マネーサーバ２に送信する。
このような、ストアードバリュー型電子マネーのシステムでは、予め汎用ＩＣモジュール２５にバリュー残高を記憶しており、決済時にこれを減額するため、バリューが不足していると、決済が行えないこととなる。
ところで、決済端末７は、ＰＯＳ端末等の上位端末１１と当該上位装置による制御のもと、支払装置である汎用ＩＣモジュール２５にアクセスする電子マネーモジュール１３とから構成されている。
従来、決済時にバリューが不足して決済不能と判断された際、ＰＯＳ端末等の上位装置が動作することにより、通信ネットワークを介して与信が容認されれば、汎用ＩＣモジュール２５に記憶されているバリュー残高を増加させる技術が知られている(特許文献１）。
しかし、この特許文献１記載の技術を導入する場合、ＰＯＳ端末等の上位装置が動作することが前提となっており、ＰＯＳ端末等の上位装置の処理手順を大きく変更させることが不可避である。そのため、例えば既に各店舗に設置されている決済端末７にこの技術を導入するには、障害が大きい。
従来、決済時にバリューが不足して決済不能と判断された際、ＰＯＳ端末等の上位装置が動作することにより、通信ネットワークを介して与信が容認されれば、汎用ＩＣモジュール２５に記憶されているバリュー残高を増加させる技術が知られている(特許文献１）。
しかし、この特許文献１記載の技術を導入する場合、ＰＯＳ端末等の上位装置が動作することが前提となっており、ＰＯＳ端末等の上位装置の処理手順を大きく変更させることが不可避である。そのため、例えば既に各店舗に設置されている決済端末７にこの技術を導入するには、障害が大きい。
本発明が解決しようとする課題は、ＰＯＳ端末等の上位装置の処理手順を大きく変更させることなく、決済時にバリュー残高不足により決済不能となる可能性を軽減するという点である。
請求項１記載の発明では、支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置からの残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する変更手段と、を具備し、前記通常条件は、前記当初の残度数が前記支払装置に対して予め規定されている閾値以下又は未満の場合に少なくとも該支払装置に対して予め規定されている前記補充度数分だけ補充すると判定される条件であり、前記通常条件を満たす場合に、補充後の残度数が前記加算後の残度数になるように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答し、前記指示装置から取得されるデータにより特定される当該指示装置の区分に応じて、前記所定の閾値と前記支払装置に対して予め規定されている前記補充度数との少なくともいずれかを上方修正する修正手段をさらに具備した、ことを特徴とする受付装置を提供する。
請求項２記載の発明では、前記修正手段は、前記通常条件の判定時点が所定の時間帯に含まれる場合に限り、前記所定の閾値と前記補充度数との少なくともいずれかを上方修正する、ことを特徴とする請求項１に記載の受付装置を提供する。
請求項３記載の発明では、支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置からの残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する変更手段と、を具備し、前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記当初の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答し、前記変更手段は、データを一時的に保持する保持手段に支払度数が記憶されていない場合に限り、前記残度数変更要求に付加される支払度数を該保持手段に保持させるとともに、前記指示装置から前記残度数参照要求を再度受けるため該残度数変更要求に対してエラーを返し、前記参照手段は、前記保持手段に支払度数が記憶されている場合に限り、該支払度数を用いて前記特殊条件を満たすか否かを判定するとともに、該保持手段から支払度数を消去させる、ことを特徴とする受付装置を提供する。
請求項４記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備したことを特徴とする受付装置を提供する。
請求項５記載の発明では、前記参照手段は、前記残度数参照要求を受けた後に前記通常条件を満たすか否かを判定する、ことを特徴とする請求項４記載の受付装置を提供する。
請求項６記載の発明では、前記通常条件は、前記当初の残度数が前記支払装置に対して予め規定されている閾値以下又は未満の場合に少なくとも該支払装置に対して予め規定されている前記補充度数分だけ補充すると判定される条件であり、前記通常条件を満たす場合に、補充後の残度数が前記加算後の残度数になるように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、ことを特徴とする請求項４又は請求項５記載の受付装置を提供する。
請求項７記載の発明では、前記変更手段により前記支払装置に記憶される残度数が変更された後に、前記当初の残度数に前記補充度数を加算したことを示す入金ログデータと、前記加算後の残度数から前記支払度数を減算したことを示す出金ログデータと、をそれぞれ生成する生成手段をさらに具備した、ことを特徴とする請求項４又は請求項５記載の受付装置を提供する。
請求項８記載の発明では、前記生成される入金ログデータと出金ログデータとを該支払装置にそれぞれ書き込む書込手段をさらに具備した、ことを特徴とする請求項７記載の受付装置を提供する。
請求項９記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記当初の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、ことを特徴とする受付装置を提供する。
請求項１０記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記加算後の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、ことを特徴とする受付装置を提供する。
請求項１１記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記参照手段は、前記残度数参照要求を受けた後に前記通常条件を満たすか否かを判定し、且つ前記参照手段は、前記残度数参照要求の内容又はこれに付加されるデータに基づき該残度数参照要求に前記残度数変更要求が続かないと判定される場合に、該残度数参照要求に対して、前記加算後の残度数に代えて、前記支払装置から取得される当初の残度数を応答する、ことを特徴とする受付装置を提供する。
請求項１２記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記支払度数が付加された前記残度数変更要求を受けた場合に、補充後の残度数が該支払度数を下回らないように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、前記変更手段は、支払後の残度数が前記補充後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する、ことを特徴とする受付装置を提供する。
請求項１３記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照ステップと、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更ステップと、を含む、受付装置の制御方法を提供する。
請求項１４記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照機能と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更機能と、をコンピュータに実現させるためのプログラムを提供する。
請求項２記載の発明では、前記修正手段は、前記通常条件の判定時点が所定の時間帯に含まれる場合に限り、前記所定の閾値と前記補充度数との少なくともいずれかを上方修正する、ことを特徴とする請求項１に記載の受付装置を提供する。
請求項３記載の発明では、支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置からの残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する変更手段と、を具備し、前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記当初の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答し、前記変更手段は、データを一時的に保持する保持手段に支払度数が記憶されていない場合に限り、前記残度数変更要求に付加される支払度数を該保持手段に保持させるとともに、前記指示装置から前記残度数参照要求を再度受けるため該残度数変更要求に対してエラーを返し、前記参照手段は、前記保持手段に支払度数が記憶されている場合に限り、該支払度数を用いて前記特殊条件を満たすか否かを判定するとともに、該保持手段から支払度数を消去させる、ことを特徴とする受付装置を提供する。
請求項４記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備したことを特徴とする受付装置を提供する。
請求項５記載の発明では、前記参照手段は、前記残度数参照要求を受けた後に前記通常条件を満たすか否かを判定する、ことを特徴とする請求項４記載の受付装置を提供する。
請求項６記載の発明では、前記通常条件は、前記当初の残度数が前記支払装置に対して予め規定されている閾値以下又は未満の場合に少なくとも該支払装置に対して予め規定されている前記補充度数分だけ補充すると判定される条件であり、前記通常条件を満たす場合に、補充後の残度数が前記加算後の残度数になるように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、ことを特徴とする請求項４又は請求項５記載の受付装置を提供する。
請求項７記載の発明では、前記変更手段により前記支払装置に記憶される残度数が変更された後に、前記当初の残度数に前記補充度数を加算したことを示す入金ログデータと、前記加算後の残度数から前記支払度数を減算したことを示す出金ログデータと、をそれぞれ生成する生成手段をさらに具備した、ことを特徴とする請求項４又は請求項５記載の受付装置を提供する。
請求項８記載の発明では、前記生成される入金ログデータと出金ログデータとを該支払装置にそれぞれ書き込む書込手段をさらに具備した、ことを特徴とする請求項７記載の受付装置を提供する。
請求項９記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記当初の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、ことを特徴とする受付装置を提供する。
請求項１０記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記加算後の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、ことを特徴とする受付装置を提供する。
請求項１１記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記参照手段は、前記残度数参照要求を受けた後に前記通常条件を満たすか否かを判定し、且つ前記参照手段は、前記残度数参照要求の内容又はこれに付加されるデータに基づき該残度数参照要求に前記残度数変更要求が続かないと判定される場合に、該残度数参照要求に対して、前記加算後の残度数に代えて、前記支払装置から取得される当初の残度数を応答する、ことを特徴とする受付装置を提供する。
請求項１２記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、前記支払度数が付加された前記残度数変更要求を受けた場合に、補充後の残度数が該支払度数を下回らないように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、前記変更手段は、支払後の残度数が前記補充後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する、ことを特徴とする受付装置を提供する。
請求項１３記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照ステップと、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更ステップと、を含む、受付装置の制御方法を提供する。
請求項１４記載の発明では、決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照機能と、前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更機能と、をコンピュータに実現させるためのプログラムを提供する。
本発明によれば、電子マネーによる決済の手順においてバリュー残高が十分に残っているか否かを上位端末が判定するステップより前に電子マネーモジュールにより実行される処理の手順そのものを変更することで、ＰＯＳ端末等の上位装置の処理手順を大きく変更することなく、決済時にバリュー残高不足により決済不能となる可能性を軽減させることができる。
（１）実施形態の概要
リアル店舗（不動産店舗などで物理的に営業している実店舗）に設置された決済端末７は、ＰＯＳ端末等の上位端末１１と、この上位端末１１の制御により、電子マネーカード１００に内蔵又は装着された汎用ＩＣモジュール２５にアクセスする電子マネーモジュール１３により構成されている。決済処理において、上位端末１１が、決済金額を取得すると、電子マネーモジュール１３に対して、汎用ＩＣモジュール２５からバリュー残高を取得するよう要求する。これを受けて、電子マネーモジュール１３は、リーダライタ部１３９を介して、バリュー残高を取得する。このとき、当該汎用ＩＣモジュール２５に、オートチャージの条件が設定されている場合は、その条件も取得する。そして、取得したバリュー残高と、オートチャージの条件から、直ちにオートチャージが可能であれば、電子マネーモジュール１３主導でオートチャージを実行する。
リアル店舗（不動産店舗などで物理的に営業している実店舗）に設置された決済端末７は、ＰＯＳ端末等の上位端末１１と、この上位端末１１の制御により、電子マネーカード１００に内蔵又は装着された汎用ＩＣモジュール２５にアクセスする電子マネーモジュール１３により構成されている。決済処理において、上位端末１１が、決済金額を取得すると、電子マネーモジュール１３に対して、汎用ＩＣモジュール２５からバリュー残高を取得するよう要求する。これを受けて、電子マネーモジュール１３は、リーダライタ部１３９を介して、バリュー残高を取得する。このとき、当該汎用ＩＣモジュール２５に、オートチャージの条件が設定されている場合は、その条件も取得する。そして、取得したバリュー残高と、オートチャージの条件から、直ちにオートチャージが可能であれば、電子マネーモジュール１３主導でオートチャージを実行する。
そして、オートチャージにより増額されたバリュー残高を上位端末１１に返す。
上位端末１１は、先に取得した決済金額と増額されたバリュー残高を比較して、決済可能か否かを判断する。決済可能であれば、上位端末１１は、決済金額を電子マネーモジュール１３に送信し、汎用ＩＣモジュール２５のバリュー残高を決済金額分減額することにより、決済を行うよう要求する。これを受けて、電子マネーモジュール１３は、汎用ＩＣモジュール２５にアクセスし、バリュー残高を減額することで決済処理を行う。
この処理によれば、一連の決済手続において、上位端末１１における決済可能か否かの判断が、オートチャージ後の増額されたバリュー残高に基づいて行われるため、バリュー残高不足で決済不能となる可能性が減少する。また、上位端末１１の処理手順を変更する必要がないため、各リアル店舗への導入を行いやすい。
上位端末１１は、先に取得した決済金額と増額されたバリュー残高を比較して、決済可能か否かを判断する。決済可能であれば、上位端末１１は、決済金額を電子マネーモジュール１３に送信し、汎用ＩＣモジュール２５のバリュー残高を決済金額分減額することにより、決済を行うよう要求する。これを受けて、電子マネーモジュール１３は、汎用ＩＣモジュール２５にアクセスし、バリュー残高を減額することで決済処理を行う。
この処理によれば、一連の決済手続において、上位端末１１における決済可能か否かの判断が、オートチャージ後の増額されたバリュー残高に基づいて行われるため、バリュー残高不足で決済不能となる可能性が減少する。また、上位端末１１の処理手順を変更する必要がないため、各リアル店舗への導入を行いやすい。
また、汎用ＩＣモジュール２５から取得したオートチャージの条件が、決済金額に依存するもの（例えば、決済金額をオートチャージする）であった場合、電子マネーモジュール１３は、バリュー残高として仮のバリュー残高（例えば、各電子マネーで規定されているチャージの限度額）を上位端末１１に返す。そして、決済許可と決済金額の送信を受け、決済金額に基づくオートチャージを行った後、決済処理を行うようにするようにしてもよい。こうすることで、確実に、バリュー残高不足で決済不能となることを回避できる。また、上位端末１１の処理手順を変更する必要もない。
（２）実施形態の詳細
図１は、第１の実施形態に係る電子マネーシステム１のネットワーク構成を説明するための図である。
電子マネーシステム１は、電子マネーサーバ２、リアル店舗に設置された決済端末７、通信回線８、クレジット会社サーバ３００並びに汎用ＩＣモジュール２５を搭載した電子マネーカード１００などを用いて構成されている。
図１は、第１の実施形態に係る電子マネーシステム１のネットワーク構成を説明するための図である。
電子マネーシステム１は、電子マネーサーバ２、リアル店舗に設置された決済端末７、通信回線８、クレジット会社サーバ３００並びに汎用ＩＣモジュール２５を搭載した電子マネーカード１００などを用いて構成されている。
電子マネーサーバ２は、バリューによる貨幣価値の移動を管理するサーバである。ここで、バリューとは、貨幣価値に対応させた電子情報であり、電子マネーシステム１は、バリューの残高（以下、バリュー残高）を増減することにより貨幣価値を移動させる。
そして、電子マネーシステム１の事業体は、バリューの移動に対応させて実際の貨幣を移動させることによりバリューと実際の貨幣の移動を対応させる。
そして、電子マネーシステム１の事業体は、バリューの移動に対応させて実際の貨幣を移動させることによりバリューと実際の貨幣の移動を対応させる。
電子マネーサーバ２は、各汎用ＩＣモジュール２５に対応づけてバリュー残高を記憶している。
両者は、常に同期を取って、同一の値であることが望ましい。しかし、現実には電子マネーサーバ２とリアルタイムで接続できない、非同期に決済を行う決済端末も多数存在する。そのため、生成したログデータを後にバッチ処理で電子マネーサーバ２に送り、事後的に同期を取るようにしている。
この実施形態では、電子マネーカード１００（又は携帯端末）側でバリューを管理するストアードバリュー型の電子マネーシステムについて説明するが、電子マネーサーバ２の側でバリューを管理するサーバ管理型電子マネーも存在している。
両者は、常に同期を取って、同一の値であることが望ましい。しかし、現実には電子マネーサーバ２とリアルタイムで接続できない、非同期に決済を行う決済端末も多数存在する。そのため、生成したログデータを後にバッチ処理で電子マネーサーバ２に送り、事後的に同期を取るようにしている。
この実施形態では、電子マネーカード１００（又は携帯端末）側でバリューを管理するストアードバリュー型の電子マネーシステムについて説明するが、電子マネーサーバ２の側でバリューを管理するサーバ管理型電子マネーも存在している。
電子マネーカード１００は、汎用ＩＣモジュール２５を内蔵又は装着しており、これに電子マネー番号とバリュー残高を記憶している。この汎用ＩＣモジュール２５と決済端末７のリーダライタ部１３９とを近接させることで、近距離無線通信を行い、データの送受信が可能となっている。
また、この電子マネーカード１００と同様に、汎用ＩＣモジュール２５を内蔵又は装着した、例えば、スマートフォン、携帯電話、ゲーム機、タブレット型コンピュータなどで構成された携帯端末も広く使用されている。この携帯端末は、インターネットに接続する機能と、汎用ＩＣモジュール２５により、決済端末７と近距離無線通信により接続する機能とを備えている。
また、この電子マネーカード１００と同様に、汎用ＩＣモジュール２５を内蔵又は装着した、例えば、スマートフォン、携帯電話、ゲーム機、タブレット型コンピュータなどで構成された携帯端末も広く使用されている。この携帯端末は、インターネットに接続する機能と、汎用ＩＣモジュール２５により、決済端末７と近距離無線通信により接続する機能とを備えている。
決済端末７は、例えば、ネットワーク設備の不便なリアル店舗の会計カウンタや自動販売機などに設置されており、電子マネーカード１００（又は携帯端末）と近距離無線通信を行う機能を備えている。
決済端末７は、電子マネーカード１００と近距離無線通信を行って、バリュー残高により決済を行う。決済端末７は、通常は電子マネーサーバ２と接続しておらず、電子マネーカード１００との決済内容を一時的にログデータとして記憶しておく。
そして、決済端末７は、１日に一回程度、通信回線８を用いて電子マネーサーバ２に接続し、電子マネーサーバ２にログデータを送信する。ネットワーク通信設備がない環境では、ログデータを記録した記録媒体を担当者が手動で収集する場合もある。
なお、決済端末には、通信回線８を介して電子マネーサーバ２と常時接続し、決済時にリアルタイムで電子マネーサーバ２とオンライン通信する同期決済端末も使用されている。
決済端末７は、電子マネーカード１００と近距離無線通信を行って、バリュー残高により決済を行う。決済端末７は、通常は電子マネーサーバ２と接続しておらず、電子マネーカード１００との決済内容を一時的にログデータとして記憶しておく。
そして、決済端末７は、１日に一回程度、通信回線８を用いて電子マネーサーバ２に接続し、電子マネーサーバ２にログデータを送信する。ネットワーク通信設備がない環境では、ログデータを記録した記録媒体を担当者が手動で収集する場合もある。
なお、決済端末には、通信回線８を介して電子マネーサーバ２と常時接続し、決済時にリアルタイムで電子マネーサーバ２とオンライン通信する同期決済端末も使用されている。
この決済端末７は、上位端末１１、電子マネーモジュール１３及びリーダライタ部１３９により構成されている。
上位端末１１は、ＰＯＳレジ、改札機に相当し、決済金額を取得する、電子マネーモジュール１３に電子マネーカード１００（又は携帯端末）の汎用ＩＣモジュール２５からバリュー残高を取得させる、取得した決済金額とバリュー残高を比較して決済の可否を判定する、判定の結果決済可の場合、電子マネーモジュール１３に汎用ＩＣモジュール２５のバリュー残高を減額させる、判定の結果決済不可の場合、その旨をユーザに通知するといった処理を行う。
この上位端末１１における処理手順に変更をもたらそうとすると、この上位端末１１のファームウェアや各店舗の会計オペレーションをも変更する必要が生じる場合があるため、可能な限りこの上位端末１１における処理手順は変更しないことが望ましい。
この上位端末１１は、決済端末７の中で指示装置として機能している。
上位端末１１は、ＰＯＳレジ、改札機に相当し、決済金額を取得する、電子マネーモジュール１３に電子マネーカード１００（又は携帯端末）の汎用ＩＣモジュール２５からバリュー残高を取得させる、取得した決済金額とバリュー残高を比較して決済の可否を判定する、判定の結果決済可の場合、電子マネーモジュール１３に汎用ＩＣモジュール２５のバリュー残高を減額させる、判定の結果決済不可の場合、その旨をユーザに通知するといった処理を行う。
この上位端末１１における処理手順に変更をもたらそうとすると、この上位端末１１のファームウェアや各店舗の会計オペレーションをも変更する必要が生じる場合があるため、可能な限りこの上位端末１１における処理手順は変更しないことが望ましい。
この上位端末１１は、決済端末７の中で指示装置として機能している。
電子マネーモジュール１３は、電子マネーカード１００（又は携帯端末）からの決済を受け付ける受付装置であり、上位端末１１からの指示に基づき、リーダライタ部１３９を介して電子マネーカード１００（又は携帯端末）の汎用ＩＣモジュール２５からバリュー残高を取得し、決済を行う場合、バリュー残高を減額させるといった処理を行う。
また、上位端末１１からの指示によらず、独自に後述するオートチャージの処理を行う。
この電子マネーモジュール１３は、他の処理に影響を大きく与えず、比較的容易に処理手順を変更することができる。
すなわち、電子マネーモジュール１３は、処理を行う機能毎にプログラムが別個となっている。そのため、特定の機能を実現するプログラムを変更しても他の機能への影響がない。
また、各機能は、上位端末１１からＡＰＩ（Applicaton Programing Interface）により、呼び出されることにより、当該機能を実現している。そのため、呼び出される側の機能を変更しても、呼び出す側（上位端末１１）への影響がない。
よって、電子マネーモジュール１３は、大きな障害なしに、処理手順を変更することができる。
この電子マネーモジュール１３は、決済端末７において受付装置として機能している。
また、上位端末１１からの指示によらず、独自に後述するオートチャージの処理を行う。
この電子マネーモジュール１３は、他の処理に影響を大きく与えず、比較的容易に処理手順を変更することができる。
すなわち、電子マネーモジュール１３は、処理を行う機能毎にプログラムが別個となっている。そのため、特定の機能を実現するプログラムを変更しても他の機能への影響がない。
また、各機能は、上位端末１１からＡＰＩ（Applicaton Programing Interface）により、呼び出されることにより、当該機能を実現している。そのため、呼び出される側の機能を変更しても、呼び出す側（上位端末１１）への影響がない。
よって、電子マネーモジュール１３は、大きな障害なしに、処理手順を変更することができる。
この電子マネーモジュール１３は、決済端末７において受付装置として機能している。
通信回線８は、電子マネーサーバ２と決済端末７を接続する回線である。通信回線８として専用回線を用いることもできるし、インターネット３などの汎用の回線を用いてもよい。
クレジット会社サーバ３００は、クレジット会社がクレジットカードによる支払を管理するためのサーバである。このクレジット会社サーバ３００は、電子マネーモジュール１３が汎用ＩＣモジュール２５にオートチャージした場合、電子マネーサーバ２を介してその代金をユーザのクレジットカード番号にて決済する。
クレジット会社サーバ３００は、クレジット会社がクレジットカードによる支払を管理するためのサーバである。このクレジット会社サーバ３００は、電子マネーモジュール１３が汎用ＩＣモジュール２５にオートチャージした場合、電子マネーサーバ２を介してその代金をユーザのクレジットカード番号にて決済する。
図２は、電子マネーカード１００のハードウェア的な構成の一例を示したブロック図である。
電子マネーカード１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２１、高周波回路１２２、アンテナ１２６、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２４、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｏｎｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）１２５などを備えている。
これらの素子は、汎用ＩＣモジュール２５上に形成されており、この汎用ＩＣモジュール２５は、貨幣価値（バリュー）の残高（バリュー残高）を記憶した支払装置として機能している。
ただし、アンテナ１２６は、電子マネーカード１００内部の外縁部付近、又は電子マネーカード１００の対角線を軸とする楕円曲線上に張り巡らされた空中線により構成され、端部が汎用ＩＣモジュール２５に接続されている。
電子マネーカード１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２１、高周波回路１２２、アンテナ１２６、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２４、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｏｎｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）１２５などを備えている。
これらの素子は、汎用ＩＣモジュール２５上に形成されており、この汎用ＩＣモジュール２５は、貨幣価値（バリュー）の残高（バリュー残高）を記憶した支払装置として機能している。
ただし、アンテナ１２６は、電子マネーカード１００内部の外縁部付近、又は電子マネーカード１００の対角線を軸とする楕円曲線上に張り巡らされた空中線により構成され、端部が汎用ＩＣモジュール２５に接続されている。
ＣＰＵ１２１は、ＲＯＭ１２３やＥＥＰＲＯＭ１２５に記憶されている各種プログラムに従って情報処理を行う中央処理装置であり、決済処理、チャージなど、記憶されているバリュー残高の金額を変更する金額変更処理を行う。
ＣＰＵ１２１は、高周波回路１２２、アンテナ１２６を介して、決済端末７のリーダライタ部１３９と近距離の無線通信を行うことができる。
アンテナ１２６は、決済端末７のリーダライタ部１３９に内蔵されたアンテナと電波による送受信を行うためのアンテナであり、各種情報の送受信を行うほか、リーダライタ部１３９からの電波により汎用ＩＣモジュール２５を駆動するための電力を発電する。
ＣＰＵ１２１は、高周波回路１２２、アンテナ１２６を介して、決済端末７のリーダライタ部１３９と近距離の無線通信を行うことができる。
アンテナ１２６は、決済端末７のリーダライタ部１３９に内蔵されたアンテナと電波による送受信を行うためのアンテナであり、各種情報の送受信を行うほか、リーダライタ部１３９からの電波により汎用ＩＣモジュール２５を駆動するための電力を発電する。
高周波回路１２２は、リーダライタ部１３９からアンテナ１２６に送信されてきた高周波をデジタル信号に変換してＣＰＵ１２１に出力したり、逆にＣＰＵ１２１が出力したデジタル信号を高周波に変換してアンテナ１２６からリーダライタ部１３９に送出したりする。
ＲＡＭ１２４は、ＣＰＵ１２１が情報処理を行う際のワーキングメモリを提供する随時書き込み読み出し可能なメモリである。
本実施の形態では、ＣＰＵ１２１が金額変更処理を行う際に、一時的な記憶領域として使用される。
ＲＯＭ１２３は、電子マネーカード１００を機能させるための基本的なプログラムやパラメータ、データなどを記憶した読み出し専用メモリである。
ＲＡＭ１２４は、ＣＰＵ１２１が情報処理を行う際のワーキングメモリを提供する随時書き込み読み出し可能なメモリである。
本実施の形態では、ＣＰＵ１２１が金額変更処理を行う際に、一時的な記憶領域として使用される。
ＲＯＭ１２３は、電子マネーカード１００を機能させるための基本的なプログラムやパラメータ、データなどを記憶した読み出し専用メモリである。
ＥＥＰＲＯＭ１２５は、情報の書込消去が可能なＲＯＭである。ＥＥＰＲＯＭ１２５に記憶してある情報は、電子マネーカード１００への電力の供給が無い場合でも保たれる。
ＥＥＰＲＯＭ１２５には、電子マネーカード１００に電子マネーカードとしての機能を発揮させるための電子マネー処理プログラムが記憶されているほか、バリュー残高やログデータ、汎用ＩＣモジュール２５を識別するＩＤ情報である電子マネー番号などの各種データを格納する電子マネー記憶部１２９が形成されている。
この電子マネー記憶部１２９には、電子マネー番号、バリュー残高、オートチャージの条件、コマンド群及びログデータなどが記憶されている。オートチャージの条件については、後述する。
ＥＥＰＲＯＭ１２５には、電子マネーカード１００に電子マネーカードとしての機能を発揮させるための電子マネー処理プログラムが記憶されているほか、バリュー残高やログデータ、汎用ＩＣモジュール２５を識別するＩＤ情報である電子マネー番号などの各種データを格納する電子マネー記憶部１２９が形成されている。
この電子マネー記憶部１２９には、電子マネー番号、バリュー残高、オートチャージの条件、コマンド群及びログデータなどが記憶されている。オートチャージの条件については、後述する。
図３は、電子マネーカード１００のＣＰＵ１２１で電子マネー処理プログラムを実行した場合に形成される電子マネーカード１００の機能的な構成を模式的に表したブロック図である。
ＥＥＰＲＯＭ１２５に形成された電子マネー記憶部１２９には、電子マネー番号、バリュー残高、オートチャージの条件、コマンド群、ログデータなどを記憶している。
バリュー残高は、現在記憶しているバリューの残高であり、電子マネーカード１００は、このバリュー残高を減額することにより決済処理を行うことができる。
このように、電子マネー記憶部１２９は、貨幣価値の金額を電子データ（バリュー）として残高を記憶する機能を有している。
ログデータは、決済端末７や電子マネーサーバ２と通信を行った処理内容を記録したデータであり、処理した日時分秒、チャージ金額、決済金額、処理した決済端末７のＩＤ情報である端末ＩＤなどから構成されている。
ＥＥＰＲＯＭ１２５に形成された電子マネー記憶部１２９には、電子マネー番号、バリュー残高、オートチャージの条件、コマンド群、ログデータなどを記憶している。
バリュー残高は、現在記憶しているバリューの残高であり、電子マネーカード１００は、このバリュー残高を減額することにより決済処理を行うことができる。
このように、電子マネー記憶部１２９は、貨幣価値の金額を電子データ（バリュー）として残高を記憶する機能を有している。
ログデータは、決済端末７や電子マネーサーバ２と通信を行った処理内容を記録したデータであり、処理した日時分秒、チャージ金額、決済金額、処理した決済端末７のＩＤ情報である端末ＩＤなどから構成されている。
端末通信部１２７は、アンテナ１２６や高周波回路１２２などを用いて構成され、決済端末７のリーダライタ部１３９から金額変更情報やその他のコマンドなどを受信してバリュー処理部１２８に入力するなど、決済端末７とバリュー処理部１２８の通信を仲介する。
バリュー処理部１２８は、各種コマンドを実行する情報処理部である。
コマンドには、金額変更情報、ＩＤ参照コマンド、残高参照コマンドなどがある。
金額変更情報は、バリュー処理部１２８に金額変更処理を行わせるコマンドである。
バリュー処理部１２８は、金額変更処理を実行すると、金額変更情報で指定された金額分だけバリュー残高を増減させ、決済端末７に対して完了応答（決済処理の場合は決済完了通知の送信、チャージの場合はチャージ完了通知の送信）を行い、更にログデータの作成を行う。
このように、バリュー処理部１２８は、決済端末７から受信した金額変更情報を用いて電子マネー記憶部１２９に記憶した金額に対して金額変更処理を行い、金額変更処理が完了した旨の応答を行う機能を有している。
バリュー処理部１２８は、各種コマンドを実行する情報処理部である。
コマンドには、金額変更情報、ＩＤ参照コマンド、残高参照コマンドなどがある。
金額変更情報は、バリュー処理部１２８に金額変更処理を行わせるコマンドである。
バリュー処理部１２８は、金額変更処理を実行すると、金額変更情報で指定された金額分だけバリュー残高を増減させ、決済端末７に対して完了応答（決済処理の場合は決済完了通知の送信、チャージの場合はチャージ完了通知の送信）を行い、更にログデータの作成を行う。
このように、バリュー処理部１２８は、決済端末７から受信した金額変更情報を用いて電子マネー記憶部１２９に記憶した金額に対して金額変更処理を行い、金額変更処理が完了した旨の応答を行う機能を有している。
ところで、金額変更情報は、例えば、加算コマンド、減算コマンド、上書きコマンドなどを用いて構成することができる。
加算コマンドは、バリュー残高を加算コマンドに付随するパラメータで指定される金額分だけ増額させるコマンドである。
一方、減算コマンドは、バリュー残高を減算コマンドに付随するパラメータで指定される金額分だけ減額させるコマンドである。
例えば、バリュー残高が５０００円で決済金額が１０００円の場合、決済端末７は、１０００円を減額する減算コマンドを生成して電子マネーカード１００に送信する。
電子マネーカード１００では、バリュー処理部１２８がこの減算コマンドを実行して、バリュー残高を５０００円−１０００円＝４０００円に更新する。加算コマンドの場合も同様である。
加算コマンドは、バリュー残高を加算コマンドに付随するパラメータで指定される金額分だけ増額させるコマンドである。
一方、減算コマンドは、バリュー残高を減算コマンドに付随するパラメータで指定される金額分だけ減額させるコマンドである。
例えば、バリュー残高が５０００円で決済金額が１０００円の場合、決済端末７は、１０００円を減額する減算コマンドを生成して電子マネーカード１００に送信する。
電子マネーカード１００では、バリュー処理部１２８がこの減算コマンドを実行して、バリュー残高を５０００円−１０００円＝４０００円に更新する。加算コマンドの場合も同様である。
上書きコマンドは、バリュー残高を上書きコマンドに付随するパラメータで指定される金額で上書きさせるコマンドである。
金額変更情報として上書きコマンドを使用する場合は、決済端末７が決済・チャージ後のバリュー残高を計算し、この金額でバリュー処理部１２８に電子マネー記憶部１２９のバリュー残高を上書きさせる。
例えば、バリュー残高が５０００円で決済金額が１０００円の場合を考える。
決済端末７は、電子マネーカード１００から現在のバリュー残高５０００円を読み取り、決済後の残高５０００円−１０００円＝４０００円を計算する。
そして、決済端末７は、バリュー残高を４０００円に上書きさせる上書きコマンドを生成して電子マネーカード１００に送信する。
電子マネーカード１００では、バリュー処理部１２８がこの上書きコマンドを実行してバリュー残高を４０００円に更新する。
金額変更情報として上書きコマンドを使用する場合は、決済端末７が決済・チャージ後のバリュー残高を計算し、この金額でバリュー処理部１２８に電子マネー記憶部１２９のバリュー残高を上書きさせる。
例えば、バリュー残高が５０００円で決済金額が１０００円の場合を考える。
決済端末７は、電子マネーカード１００から現在のバリュー残高５０００円を読み取り、決済後の残高５０００円−１０００円＝４０００円を計算する。
そして、決済端末７は、バリュー残高を４０００円に上書きさせる上書きコマンドを生成して電子マネーカード１００に送信する。
電子マネーカード１００では、バリュー処理部１２８がこの上書きコマンドを実行してバリュー残高を４０００円に更新する。
金額変更情報は、加算コマンドと減算コマンドによって構成してもよいし、チャージの場合は上書きコマンドを用い、決済の場合は減算コマンドを用いて構成してもよいし、チャージの場合は加算コマンドを用い、減算の場合は上書きコマンドを用いて構成してもよいし、あるいは、チャージ、決済のいずれも上書きコマンドを用いるように構成してもよい。
ＩＤ参照コマンドは、バリュー処理部１２８に電子マネー番号を読み出させるコマンドであり、バリュー処理部１２８は、ＩＤ参照コマンドが入力されると、電子マネー記憶部１２９から電子マネー番号を読み出して出力する。
残高参照コマンドは、バリュー処理部１２８にバリュー残高を読み出させるコマンドであり、バリュー処理部１２８は残高参照コマンドが入力されると電子マネー記憶部１２９からバリュー残高を読み出して出力する。
以上、電子マネーカード１００の構成について説明したが、電子マネーカード１００に組み込んだ汎用ＩＣモジュール２５と同様の汎用ＩＣモジュールを携帯電話やその他の携帯端末に搭載したものも一般に広く用いられている。これら携帯端末は、電子マネーカード１００と同様に決済端末７を用いて決済処理やチャージを行うことができる。
残高参照コマンドは、バリュー処理部１２８にバリュー残高を読み出させるコマンドであり、バリュー処理部１２８は残高参照コマンドが入力されると電子マネー記憶部１２９からバリュー残高を読み出して出力する。
以上、電子マネーカード１００の構成について説明したが、電子マネーカード１００に組み込んだ汎用ＩＣモジュール２５と同様の汎用ＩＣモジュールを携帯電話やその他の携帯端末に搭載したものも一般に広く用いられている。これら携帯端末は、電子マネーカード１００と同様に決済端末７を用いて決済処理やチャージを行うことができる。
図４は、決済端末７のハードウェア的な構成の一例を示した図である。
決済端末７は、ＣＰＵ１３１、ＲＯＭ１３３、ＲＡＭ１３４、通信制御部１３５、記憶部１３６、入力部１３７、出力部１３８、リーダライタ部１３９などがバスラインで接続されて構成されており、決済処理装置としての機能を有している。
ＣＰＵ１３１は、所定のプログラムに従って情報処理を行うほか、決済端末７全体の制御などを行う。本実施の形態では、ＣＰＵ１３１は、金額変更情報を電子マネーカード１００に送信して、電子マネーカード１００に金額変更処理を行わせる。
ＲＯＭ１３３は、決済端末７を動作させるための基本的なプログラムやパラメータなどを記憶した読み出し専用メモリである。
ＲＡＭ１３４は、ＣＰＵ１３１のワーキングメモリを提供したり、記憶部１３６に記憶されたプログラムやデータをロードして記憶したりなどする随時書き込み読み出し可能なメモリである。
通信制御部１３５は、ネットワークを介して決済端末７を電子マネーサーバ２に接続する接続装置である。
決済端末７は、ＣＰＵ１３１、ＲＯＭ１３３、ＲＡＭ１３４、通信制御部１３５、記憶部１３６、入力部１３７、出力部１３８、リーダライタ部１３９などがバスラインで接続されて構成されており、決済処理装置としての機能を有している。
ＣＰＵ１３１は、所定のプログラムに従って情報処理を行うほか、決済端末７全体の制御などを行う。本実施の形態では、ＣＰＵ１３１は、金額変更情報を電子マネーカード１００に送信して、電子マネーカード１００に金額変更処理を行わせる。
ＲＯＭ１３３は、決済端末７を動作させるための基本的なプログラムやパラメータなどを記憶した読み出し専用メモリである。
ＲＡＭ１３４は、ＣＰＵ１３１のワーキングメモリを提供したり、記憶部１３６に記憶されたプログラムやデータをロードして記憶したりなどする随時書き込み読み出し可能なメモリである。
通信制御部１３５は、ネットワークを介して決済端末７を電子マネーサーバ２に接続する接続装置である。
入力部１３７は、決済端末７が店舗に設置されたものである場合、例えば、キーボード、バーコードリーダなどの入力装置を備えており、操作担当者が商品コードや決済金額やチャージ金額などを入力できるようになっている。
また、決済端末７が、通過ゲートに設置されたものである場合、入力部１３７は、例えば、通過ゲートの制御装置に接続されており、通過ゲートの制御装置から決済金額の入力を受け付けるようになっている。
また、決済端末７が、通過ゲートに設置されたものである場合、入力部１３７は、例えば、通過ゲートの制御装置に接続されており、通過ゲートの制御装置から決済金額の入力を受け付けるようになっている。
出力部１３８は、決済端末７が店舗に設置されたものである場合、例えば、液晶表示装置、プリンタ、音声出力装置などに接続されており、顧客や加盟店の操作担当者に情報を提示するようになっている。例えば、決済が完了した場合、決済不能な場合に決められた音を出し、ユーザに決済の結果を知らせる。
また、決済端末７が、通過ゲートに設置されたものである場合、例えば、出力部１３８はゲート扉を駆動する駆動装置や、通過ゲートに設置された警告灯や音声出力装置などに接続されており、ゲート扉を開閉したり、ゲート扉の開閉に同期して警告灯を点滅させたり警告音を発生させたりする。
また、決済端末７が、通過ゲートに設置されたものである場合、例えば、出力部１３８はゲート扉を駆動する駆動装置や、通過ゲートに設置された警告灯や音声出力装置などに接続されており、ゲート扉を開閉したり、ゲート扉の開閉に同期して警告灯を点滅させたり警告音を発生させたりする。
リーダライタ部１３９は、アンテナを内蔵しており、電子マネーカード１００（又は携帯端末）の汎用ＩＣモジュール２５と無線通信を行う。
決済端末７が、店舗に設置されるものである場合、リーダライタ部１３９は、キャッシュレジスタ近辺に設置され、ユーザが商品の決済時に、電子マネーカード１００をリーダライタ部１３９に近接させることができるようになっている。
また、決済端末７が、通過ゲートに設置されるものである場合、リーダライタ部１３９は、通過ゲート上面の、ゲート扉よりも手前側に設置され、ユーザが通過ゲートを通過する際に、電子マネーカード１００をリーダライタ部１３９に近接させることができるようになっている。
決済端末７が、店舗に設置されるものである場合、リーダライタ部１３９は、キャッシュレジスタ近辺に設置され、ユーザが商品の決済時に、電子マネーカード１００をリーダライタ部１３９に近接させることができるようになっている。
また、決済端末７が、通過ゲートに設置されるものである場合、リーダライタ部１３９は、通過ゲート上面の、ゲート扉よりも手前側に設置され、ユーザが通過ゲートを通過する際に、電子マネーカード１００をリーダライタ部１３９に近接させることができるようになっている。
記憶部１３６は、例えばハードディスクやその他の記憶媒体と、これらを駆動する駆動装置から構成されており、各種プログラムを格納したプログラム格納部１４２、データを格納したデータ格納部１４４などから構成されている。
プログラム格納部１４２には、決済端末７を機能させるための基本的なプログラムであるＯＳや、電子マネーカード１００に金額変更処理を行わせたり、不足金額を電子マネーサーバ２にチャージさせたりするためのプログラムなどが記憶されている。
データ格納部１４４には、決済端末７のＩＤ情報である端末ＩＤや、電子マネーカード１００との取引履歴であるログデータなどを記憶している。このログデータは、ＣＰＵ１３１が行うバッチ処理にて電子マネーサーバ２に送信される。
プログラム格納部１４２には、決済端末７を機能させるための基本的なプログラムであるＯＳや、電子マネーカード１００に金額変更処理を行わせたり、不足金額を電子マネーサーバ２にチャージさせたりするためのプログラムなどが記憶されている。
データ格納部１４４には、決済端末７のＩＤ情報である端末ＩＤや、電子マネーカード１００との取引履歴であるログデータなどを記憶している。このログデータは、ＣＰＵ１３１が行うバッチ処理にて電子マネーサーバ２に送信される。
図５は、電子マネーサーバ２の構成を説明するための図である。
電子マネーサーバ２は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信制御部３４、記憶部３５などがバスライン３６によって接続している。
ＣＰＵ３１は、ＲＯＭ３２や記憶部３５に記録したプログラムを実行して各種の情報処理や電子マネーサーバ２全体の制御を行う。
決済端末７での決済では、電子マネーサーバ２は、決済端末７がバリュー残高を更新したログデータを後ほど決済端末７から受信して処理する。
なお、電子マネーサーバ２とオンラインで接続できる決済端末の場合、通信しながらバリュー残高をリアルタイムで更新することによりバリューによる決済処理を行うことができる。
電子マネーサーバ２は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信制御部３４、記憶部３５などがバスライン３６によって接続している。
ＣＰＵ３１は、ＲＯＭ３２や記憶部３５に記録したプログラムを実行して各種の情報処理や電子マネーサーバ２全体の制御を行う。
決済端末７での決済では、電子マネーサーバ２は、決済端末７がバリュー残高を更新したログデータを後ほど決済端末７から受信して処理する。
なお、電子マネーサーバ２とオンラインで接続できる決済端末の場合、通信しながらバリュー残高をリアルタイムで更新することによりバリューによる決済処理を行うことができる。
ＲＯＭ３２は、読み取り専用のメモリであって、電子マネーサーバ２が動作するための基本的なプログラム、パラメータ、データなどが記録されている。
ＲＡＭ３３は、読み書きが可能なメモリであって、ＣＰＵ３１が情報処理を行う際のワーキングメモリを提供する。
通信制御部３４は、電子マネーサーバ２が通信回線８を介して決済端末７と通信したり、インターネット３を介して携帯端末と通信したりすることもできる。
記憶部３５は、例えば、大容量のハードディスクで構成されており、ＣＰＵ３１がバリューによる決済処理を行ったり、チャージを行うための電子マネー管理プログラムやその他のプログラム、ユーザのバリュー残高を管理したり、チャージの履歴を管理するユーザＤＢ（データベース）、オートチャージ設定ＤＢ、加盟店のバリュー決済を管理する加盟店ＤＢ、各決済処理を記録したログデータを格納するログデータＤＢなどを記録している。
なお、この図５の例では、単一の電子マネーサーバ２を説明したが、この電子マネーサーバ２が、機能を分散することにより複数のサーバから構成されるようにしてもよい。
ＲＡＭ３３は、読み書きが可能なメモリであって、ＣＰＵ３１が情報処理を行う際のワーキングメモリを提供する。
通信制御部３４は、電子マネーサーバ２が通信回線８を介して決済端末７と通信したり、インターネット３を介して携帯端末と通信したりすることもできる。
記憶部３５は、例えば、大容量のハードディスクで構成されており、ＣＰＵ３１がバリューによる決済処理を行ったり、チャージを行うための電子マネー管理プログラムやその他のプログラム、ユーザのバリュー残高を管理したり、チャージの履歴を管理するユーザＤＢ（データベース）、オートチャージ設定ＤＢ、加盟店のバリュー決済を管理する加盟店ＤＢ、各決済処理を記録したログデータを格納するログデータＤＢなどを記録している。
なお、この図５の例では、単一の電子マネーサーバ２を説明したが、この電子マネーサーバ２が、機能を分散することにより複数のサーバから構成されるようにしてもよい。
次に、図６の各図を用いて電子マネーサーバ２の有するデータベースについて説明する。
図６（１）は、ユーザＤＢの論理的な構成を説明するための図である。
本実施形態では、ユーザＩＤに対応して、電子マネー番号が記憶されている。図示しないが汎用ＩＣモジュール２５の認証データなどの項目も記憶されている。
項目「ユーザＩＤ」は、ユーザの識別情報である。
項目「電子マネー番号」は、バリュー残高を他のユーザのバリュー残高から識別するための口座番号である。
項目「バリュー残高の管理値」は、項目「電子マネー番号」で特定される口座のバリュー残高である。このバリュー残高は、ログデータをバッチ処理で受信して更新する。
図６（１）は、ユーザＤＢの論理的な構成を説明するための図である。
本実施形態では、ユーザＩＤに対応して、電子マネー番号が記憶されている。図示しないが汎用ＩＣモジュール２５の認証データなどの項目も記憶されている。
項目「ユーザＩＤ」は、ユーザの識別情報である。
項目「電子マネー番号」は、バリュー残高を他のユーザのバリュー残高から識別するための口座番号である。
項目「バリュー残高の管理値」は、項目「電子マネー番号」で特定される口座のバリュー残高である。このバリュー残高は、ログデータをバッチ処理で受信して更新する。
項目「オートチャージの設定」は、決済端末７の電子マネーモジュール１３の主導によるオートチャージの設定を行っているか否かを登録する項目である。
「氏名」、「住所」、「生年月日」、「電話番号」、「メールアドレス」の項目は、各々ユーザを特定するための情報である。これらの全ての事項が必須登録項目でなく、場合によっては、設けなくともよい。
「氏名」、「住所」、「生年月日」、「電話番号」、「メールアドレス」の項目は、各々ユーザを特定するための情報である。これらの全ての事項が必須登録項目でなく、場合によっては、設けなくともよい。
図６（２）は、オートチャージ設定ＤＢの論理的な構成を説明するための図である。
オートチャージ設定ＤＢは、「電子マネー番号」、「オートチャージの条件」、「オートチャージの条件変更」、「クレジットカード番号（金融機関の口座番号）」、「日額限度」、「月額限度」、その他の項目から構成されている。
項目「電子マネー番号」は、ユーザＤＢに登録されているユーザを検索するキーとなる。
項目「オートチャージの条件」は、どのような条件下でどれだけの金額をチャージするかを設定する項目である。
例えば、「バリュー残高がＸ円以下になったらＹ円チャージ」である。具体的には、「バリュー残高が１０００円以下になったら５０００円チャージする」である。本実施形態では、このような方式をタイプＡ方式と呼ぶ。
オートチャージ設定ＤＢは、「電子マネー番号」、「オートチャージの条件」、「オートチャージの条件変更」、「クレジットカード番号（金融機関の口座番号）」、「日額限度」、「月額限度」、その他の項目から構成されている。
項目「電子マネー番号」は、ユーザＤＢに登録されているユーザを検索するキーとなる。
項目「オートチャージの条件」は、どのような条件下でどれだけの金額をチャージするかを設定する項目である。
例えば、「バリュー残高がＸ円以下になったらＹ円チャージ」である。具体的には、「バリュー残高が１０００円以下になったら５０００円チャージする」である。本実施形態では、このような方式をタイプＡ方式と呼ぶ。
他のオートチャージの条件として、「当該決済に必要な金額をチャージする」である。具体的には、「決済金額が１５００円であり、バリュー残高が９００円の場合、６００円チャージする」である。本実施形態では、このような方式をタイプＢ方式と呼ぶ。
「オートチャージの条件変更」は、特定の条件の場合、前記したオートチャージの条件を変更する項目である。
例えば、タイプＡ方式で「バリュー残高が１０００円以下になったら５０００円チャージする」と設定した場合において、「列車の改札を通過した場合又は、現時刻が午前７時から午前９時３０分のラッシュアワーの時間帯のみバリュー残高が２０００円以下になったら５０００円チャージ」とする。この場合、通常時は決済直前の残高が１０００円を下回らない設定となっているが、特定の場所、時間帯には決済直前の残高が２０００円を下回らないことが保証される。
このように、電子マネーカード１００の使用場所、使用時間帯によりオートチャージの条件を変更可能とすることにより、残高不足のために決済不能と判定される可能性がさらに軽減される。特に、交通機関の改札や運賃支払機など、改札がストップする可能性がさらに軽減される。その結果、円滑な人の流れを妨げる要因を可能な限り排除することができる。
「オートチャージの条件変更」は、特定の条件の場合、前記したオートチャージの条件を変更する項目である。
例えば、タイプＡ方式で「バリュー残高が１０００円以下になったら５０００円チャージする」と設定した場合において、「列車の改札を通過した場合又は、現時刻が午前７時から午前９時３０分のラッシュアワーの時間帯のみバリュー残高が２０００円以下になったら５０００円チャージ」とする。この場合、通常時は決済直前の残高が１０００円を下回らない設定となっているが、特定の場所、時間帯には決済直前の残高が２０００円を下回らないことが保証される。
このように、電子マネーカード１００の使用場所、使用時間帯によりオートチャージの条件を変更可能とすることにより、残高不足のために決済不能と判定される可能性がさらに軽減される。特に、交通機関の改札や運賃支払機など、改札がストップする可能性がさらに軽減される。その結果、円滑な人の流れを妨げる要因を可能な限り排除することができる。
「クレジットカード番号（金融機関の口座番号）」は、チャージ原資の調達先を示す項目である。そのため、場合によっては、「銀行の口座番号」や「電話料金を請求する電話会社が決定したＩＤ」の場合もある。
また、複数の決済手段（クレジットカード、預貯金口座など）を用いる場合は、決済手順を記憶することもできる。
銀行口座からの引落の場合、当該ユーザと銀行との間で、電子マネーサーバ２からの請求に対して引落を行う旨の契約がなされることが前提である。
「日額限度」、「月額限度」は、任意的設定項目である。ユーザから設定の要求があった場合、項目に記録する。この限度を設定しておくことで、電子マネーカード１００を紛失した場合に、不正使用による損害をその限度額内に止めることができる。
日額限度額は、チャージによる１日当たりのチャージ合計値の上限値である。
月額限度額は、チャージによる１ヶ月当たりのチャージ合計値の上限値である。また、１日当たりの限度回数、１ヶ月当たりの限度回数を設定するように構成してもよい。
また、複数の決済手段（クレジットカード、預貯金口座など）を用いる場合は、決済手順を記憶することもできる。
銀行口座からの引落の場合、当該ユーザと銀行との間で、電子マネーサーバ２からの請求に対して引落を行う旨の契約がなされることが前提である。
「日額限度」、「月額限度」は、任意的設定項目である。ユーザから設定の要求があった場合、項目に記録する。この限度を設定しておくことで、電子マネーカード１００を紛失した場合に、不正使用による損害をその限度額内に止めることができる。
日額限度額は、チャージによる１日当たりのチャージ合計値の上限値である。
月額限度額は、チャージによる１ヶ月当たりのチャージ合計値の上限値である。また、１日当たりの限度回数、１ヶ月当たりの限度回数を設定するように構成してもよい。
ここで、チャージ原資を電話料金に合算する場合を説明する。
携帯端末が電話機能を備えており、ユーザが携帯電話会社と契約を結んでいる場合、チャージ金額を電話料金と合算してユーザに請求することも可能である。
この手法は、例えば、デジタルコンテンツの購入代金を電話料金と合算する場合と同様である。
この場合、電子マネーサーバ２は、クレジット会社サーバ３００の代わりに携帯電話事業者のサーバにアクセスし、チャージ予約で設定された金額の徴収を依頼する。このとき、携帯電話事業者から予め通知されていたＩＤも通知するようにする。
携帯端末が電話機能を備えており、ユーザが携帯電話会社と契約を結んでいる場合、チャージ金額を電話料金と合算してユーザに請求することも可能である。
この手法は、例えば、デジタルコンテンツの購入代金を電話料金と合算する場合と同様である。
この場合、電子マネーサーバ２は、クレジット会社サーバ３００の代わりに携帯電話事業者のサーバにアクセスし、チャージ予約で設定された金額の徴収を依頼する。このとき、携帯電話事業者から予め通知されていたＩＤも通知するようにする。
図７は、オートチャージの設定を行う際、表示されるオートチャージの設定画面を示した図である。
電子マネーカード１００の汎用ＩＣモジュール２５に記憶されたバリュー残高を増加させる処理をチャージと呼ぶ。このチャージは、リアル店舗で貨幣と交換で行うチャージと電子マネーカードを使用した際、一定の要件に該当した場合、自動的に行うオートチャージがある。
まず、リアル店舗でのチャージについて説明する。
このチャージを行うのは、前提として、チャージを行うバリューに相当する貨幣を決済端末７を操作する店員が受け取っていることである。そして、チャージ処理を行う際、汎用ＩＣモジュール２５は、近距離通信制御部を介して決済端末７からバリュー残高を更新（増額）するようにとの要求を受けて、バリュー残高を更新（増額）する。
その後、汎用ＩＣモジュール２５は、バリュー残高を更新した旨を決済端末７に通知する。
電子マネーカード１００の汎用ＩＣモジュール２５に記憶されたバリュー残高を増加させる処理をチャージと呼ぶ。このチャージは、リアル店舗で貨幣と交換で行うチャージと電子マネーカードを使用した際、一定の要件に該当した場合、自動的に行うオートチャージがある。
まず、リアル店舗でのチャージについて説明する。
このチャージを行うのは、前提として、チャージを行うバリューに相当する貨幣を決済端末７を操作する店員が受け取っていることである。そして、チャージ処理を行う際、汎用ＩＣモジュール２５は、近距離通信制御部を介して決済端末７からバリュー残高を更新（増額）するようにとの要求を受けて、バリュー残高を更新（増額）する。
その後、汎用ＩＣモジュール２５は、バリュー残高を更新した旨を決済端末７に通知する。
一方、オートチャージは、事前に各電子マネーカード１００の汎用ＩＣモジュール２５に設定してあることが前提となる。
この設定は、例えば、非接触型リーダライタを有するＰＣ（パーソナルコンピュータ）を介して、当該電子マネーカード１００と電子マネーサーバ２を接続することで行うことができる。また、リーダライタ機能を有する携帯端末を介して当該電子マネーカード１００と電子マネーサーバ２を接続することで行うこともできる。この場合は、どこに居ても処理が可能である。
さらに、所定の店舗において、店員（オペレータ）が操作する画面において、希望する設定をユーザが画面をタッチすることにより行うこともできる。
本実施形態に係る電子マネーサーバ２からのチャージは、電子マネーサーバ２に事前にユーザ登録をしておくことが前提である。店頭での現金（貨幣）に基づくチャージと異なり、チャージの原資をどのように調達するのかを予め明らかにしておく必要があるからである。
この設定は、例えば、非接触型リーダライタを有するＰＣ（パーソナルコンピュータ）を介して、当該電子マネーカード１００と電子マネーサーバ２を接続することで行うことができる。また、リーダライタ機能を有する携帯端末を介して当該電子マネーカード１００と電子マネーサーバ２を接続することで行うこともできる。この場合は、どこに居ても処理が可能である。
さらに、所定の店舗において、店員（オペレータ）が操作する画面において、希望する設定をユーザが画面をタッチすることにより行うこともできる。
本実施形態に係る電子マネーサーバ２からのチャージは、電子マネーサーバ２に事前にユーザ登録をしておくことが前提である。店頭での現金（貨幣）に基づくチャージと異なり、チャージの原資をどのように調達するのかを予め明らかにしておく必要があるからである。
この図７に示した画面の例は、例えば、ユーザ自宅にある非接触型リーダライタを有するＰＣ（パーソナルコンピュータ）の画面に表示されたものである。
まず、「オートチャージの設定」画面では、「１．オートチャージ資金の調達先を設定してください」との表示の下に、「クレジットカード」、「銀行口座引落」、「電話料金に合算」が表示されている。
これ以外に原資を確保する方法があれば、それも表示する。そして、この中からユーザの選択を受け付ける。この中から複数を選択させて、優先順位を設定するようにしてもよい。なお、クレジットカードが選択された場合、この後クレジット会社とクレジットカード番号が要求される。銀行口座引落を選択した場合は、銀行名と口座番号が、電話料金に合算を選択した場合は、電話会社と電話番号が要求される。
また、後日、電子マネー運営会社などから、正式な契約書に押印を要求される場合もある。
まず、「オートチャージの設定」画面では、「１．オートチャージ資金の調達先を設定してください」との表示の下に、「クレジットカード」、「銀行口座引落」、「電話料金に合算」が表示されている。
これ以外に原資を確保する方法があれば、それも表示する。そして、この中からユーザの選択を受け付ける。この中から複数を選択させて、優先順位を設定するようにしてもよい。なお、クレジットカードが選択された場合、この後クレジット会社とクレジットカード番号が要求される。銀行口座引落を選択した場合は、銀行名と口座番号が、電話料金に合算を選択した場合は、電話会社と電話番号が要求される。
また、後日、電子マネー運営会社などから、正式な契約書に押印を要求される場合もある。
次に、「２．１回のチャージ金額を設定してください」が表示される。これは、タイプＡ方式の場合に必須の設定事項である。
この欄（以下の「３．」や「６．」も同様）はドロップダウンメニューとなっており、ユーザがそれぞれ、金額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。
この欄（以下の「３．」や「６．」も同様）はドロップダウンメニューとなっており、ユーザがそれぞれ、金額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。
次に、「３．チャージを開始するバリュー残高の下限値を設定してください」が表示される。これもタイプＡ方式の場合に必須の設定事項である。「２．」及び「３．」を設定することで、「Ｘ円以下（未満）になったらＹ円チャージ」との希望するオートチャージのやり方が設定される。
次に、「４．決済の状況に応じて、２．３．で設定した条件を変更可とすることに同意する」が表示される。
この設定をしておくことで、可能な限り「決済不可」を避けたい場所、事前に多めの支払があることが予想されるような場面において、バリュー残高不足で決済不可となる可能性をさらに軽減することができる。
「同意する」５００をクリックすると、詳細な設定画面に移行する。一方、「同意しない」５０２をクリックすると、この設定はスキップされる。
次に、「４．決済の状況に応じて、２．３．で設定した条件を変更可とすることに同意する」が表示される。
この設定をしておくことで、可能な限り「決済不可」を避けたい場所、事前に多めの支払があることが予想されるような場面において、バリュー残高不足で決済不可となる可能性をさらに軽減することができる。
「同意する」５００をクリックすると、詳細な設定画面に移行する。一方、「同意しない」５０２をクリックすると、この設定はスキップされる。
次に、「５．決済金額に応じたチャージ金額に設定してください（設定した場合、上記２．〜４．の設定はクリアされます）」が表示される。
これは、タイプＢ方式の設定である。この例では、タイプＡ方式とタイプＢ方式は両立させないこととしているので、タイプＢ方式を選択すると自動的にタイプＡ方式の設定はキャンセルされる。
但し、タイプＡ方式とタイプＢ方式を併存させるようにすることもできる。例えば、決済端末７毎に優先するタイプを設定しておいて、当該決済端末７が設定されている方のタイプを優先的に選択するようにしてもよい。
「設定する」５０４をクリックすると、詳細な設定画面に移行する。一方、「設定しない」５０６をクリックすると、この設定はスキップされる。
これは、タイプＢ方式の設定である。この例では、タイプＡ方式とタイプＢ方式は両立させないこととしているので、タイプＢ方式を選択すると自動的にタイプＡ方式の設定はキャンセルされる。
但し、タイプＡ方式とタイプＢ方式を併存させるようにすることもできる。例えば、決済端末７毎に優先するタイプを設定しておいて、当該決済端末７が設定されている方のタイプを優先的に選択するようにしてもよい。
「設定する」５０４をクリックすると、詳細な設定画面に移行する。一方、「設定しない」５０６をクリックすると、この設定はスキップされる。
次に、「６．所定の期間内のチャージ金額の上限を設定する場合は設定してください」が表示される。これは任意の設定事項である。例えば、１日、１０，０００円、又は１月、５０，０００円と設定することができる。
この設定をしておくことで、電子マネーカード１００を紛失したとしても、次々とチャージをされて被害が拡大することを防止することができる。
設定ボタン５０８は、ユーザが選択した内容を確定したことを通知するためのボタンであり、設定ボタン５０８が選択されると、決済端末７は、リーダライタ部１３９を介してその内容を電子マネーカード１００の汎用ＩＣモジュール２５（電子マネー記憶部１２９）に記憶させる。一方、通信回線を介して電子マネーサーバ２に送信し、オートチャージ設定ＤＢに記録する。
戻るボタン５１０は、オートチャージ設定画面を表示する前に表示していた画面に戻るためのボタンである。
この設定をしておくことで、電子マネーカード１００を紛失したとしても、次々とチャージをされて被害が拡大することを防止することができる。
設定ボタン５０８は、ユーザが選択した内容を確定したことを通知するためのボタンであり、設定ボタン５０８が選択されると、決済端末７は、リーダライタ部１３９を介してその内容を電子マネーカード１００の汎用ＩＣモジュール２５（電子マネー記憶部１２９）に記憶させる。一方、通信回線を介して電子マネーサーバ２に送信し、オートチャージ設定ＤＢに記録する。
戻るボタン５１０は、オートチャージ設定画面を表示する前に表示していた画面に戻るためのボタンである。
なお、オートチャージには、携帯端末の通信機能を用いて、電子マネーサーバ２に直接アクセスして、電子マネーサーバ２から、金額変更（増額）情報を携帯端末が受信し、汎用ＩＣモジュール２５のバリュー残高を更新（増額）することにより行う方法もある。
このようなオートチャージを設定しておくことで、決済時に、バリュー残高不足で決済ができないということを防止することができる。
このようなオートチャージを設定しておくことで、決済時に、バリュー残高不足で決済ができないということを防止することができる。
図８は、決済端末７の電子マネーモジュール１３が主導して行うオートチャージの手順を説明するためのフローチャートである。
以下の処理は、電子マネーカード１００（又は携帯端末）の汎用ＩＣモジュール２５のＣＰＵ１２１、決済端末７のＣＰＵ１３１が、それぞれ、電子マネー処理用のアプリケーションプログラム、電子マネーモジュール用のプログラムに従って行うものである。
なお、ここで説明する例では、電子マネーカード１００の汎用ＩＣモジュール２５と電子マネーモジュール１３とが、リーダライタ部１３９を介して、データの送受信可能に接続されている。
以下の処理は、電子マネーカード１００（又は携帯端末）の汎用ＩＣモジュール２５のＣＰＵ１２１、決済端末７のＣＰＵ１３１が、それぞれ、電子マネー処理用のアプリケーションプログラム、電子マネーモジュール用のプログラムに従って行うものである。
なお、ここで説明する例では、電子マネーカード１００の汎用ＩＣモジュール２５と電子マネーモジュール１３とが、リーダライタ部１３９を介して、データの送受信可能に接続されている。
まず、電子マネーモジュール１３が、電子マネーカード１００の汎用ＩＣモジュール２５にアクセスし、電子マネー記憶部１２９に記憶されているオートチャージの条件の送信を要求する（ステップ４０）。
これに対して、汎用ＩＣモジュール２５は、電子マネー記憶部１２９に記憶されているオートチャージの条件、電子マネー番号及びクレジットカードの番号を送信する(ステップ５０）。
ここに示す例では、クレジットカード会社から与信を受けることで、オートチャージを行う。なお、ここで、クレジットカード番号を送信せずに、後に電子マネー番号に紐付けて、電子マネーサーバ２のオートチャージ設定ＤＢに登録されているクレジットカード番号に基づいて、クレジットカード会社に請求するようにしてもよい。
ここで、送信されてきたオートチャージの条件は、前述したタイプＡ方式の「バリュー残高がＸ円以下ならＹ円チャージ」というものであったとする。具体的には、「バリュー残高が１０００円以下なら５０００円チャージ」であったとする。
これに対して、汎用ＩＣモジュール２５は、電子マネー記憶部１２９に記憶されているオートチャージの条件、電子マネー番号及びクレジットカードの番号を送信する(ステップ５０）。
ここに示す例では、クレジットカード会社から与信を受けることで、オートチャージを行う。なお、ここで、クレジットカード番号を送信せずに、後に電子マネー番号に紐付けて、電子マネーサーバ２のオートチャージ設定ＤＢに登録されているクレジットカード番号に基づいて、クレジットカード会社に請求するようにしてもよい。
ここで、送信されてきたオートチャージの条件は、前述したタイプＡ方式の「バリュー残高がＸ円以下ならＹ円チャージ」というものであったとする。具体的には、「バリュー残高が１０００円以下なら５０００円チャージ」であったとする。
次に、電子マネーモジュール１３は、汎用ＩＣモジュール２５にバリュー残高の送信を要求し（ステップ６０）、汎用ＩＣモジュール２５は、当該時点でのバリュー残高を電子マネーモジュール１３に返送する（ステップ７０）。
ここで、電子マネーモジュール１３は、ステップ４０で取得したオートチャージの条件と、ステップ７０で取得したバリュー残高を用いて、オートチャージの条件に合致しているか否かを判断する（ステップ８０）。
ここで、取得したバリュー残高が８００円であったとする。バリュー残高が１０００円以下なので、設定されているオートチャージの条件に合致することとなる（ステップ８０；Ｙ）。なお、電子マネーモジュール１３が主導して行うオートチャージを行う場合、クレジットカードの有効期限チェック、ネガリストチェック等が後に電子マネーサーバ２にて行われるため、ここで、チェックを行うようにしてもよい。また、一定時間内にＮ回（Ｎは適当な自然数）以上オートチャージが行われた場合、オートチャージ不可とするようにしてもよい。
ここで、電子マネーモジュール１３は、ステップ４０で取得したオートチャージの条件と、ステップ７０で取得したバリュー残高を用いて、オートチャージの条件に合致しているか否かを判断する（ステップ８０）。
ここで、取得したバリュー残高が８００円であったとする。バリュー残高が１０００円以下なので、設定されているオートチャージの条件に合致することとなる（ステップ８０；Ｙ）。なお、電子マネーモジュール１３が主導して行うオートチャージを行う場合、クレジットカードの有効期限チェック、ネガリストチェック等が後に電子マネーサーバ２にて行われるため、ここで、チェックを行うようにしてもよい。また、一定時間内にＮ回（Ｎは適当な自然数）以上オートチャージが行われた場合、オートチャージ不可とするようにしてもよい。
そこで、電子マネーモジュール１３は、オートチャージを行うための金額変更情報を生成し、汎用ＩＣモジュール２５に送信する（ステップ９０）。この例では、バリュー残高を５０００円増額する金額変更情報を送信する。一方、オートチャージの条件に合致しない場合（ステップ８０；Ｎ）、例えば、バリュー残高が１５００円だった場合、オートチャージを行わず、処理を終了する。
この金額変更情報の送信を受けて、汎用ＩＣモジュール２５は、金額変更処理（オートチャージ）を実行し、バリュー残高を５０００円分増額させる処理を実行する（ステップ１００）。そして、この処理が完了した後、金額変更（オートチャージ）完了情報を電子マネーモジュール１３に送信する（ステップ１１０）。
ここで、金額変更情報を構成するコマンド群について説明する。このコマンド群の一例としては、チャージ金額を示すデータ、現在の残高を取得するコマンド、残高を「現在の残高＋チャージ金額」に書き換えるコマンド（上書き又は加算）、書換確認コマンド、ログデータ書込コマンドである。
その後、電子マネーモジュール１３は、オートチャージログデータを生成する（ステップ６００）。
この生成したオートチャージログデータは、都度上位端末１１へ送信するようにしてもよいし、電子マネーモジュール１３側で記録しておき、後に処理するようにしてもよい。
上位端末１１は、所定の時期に、通信回線８を介して、バッチ処理で電子マネーサーバ２にオートチャージログデータを送信する。
この金額変更情報の送信を受けて、汎用ＩＣモジュール２５は、金額変更処理（オートチャージ）を実行し、バリュー残高を５０００円分増額させる処理を実行する（ステップ１００）。そして、この処理が完了した後、金額変更（オートチャージ）完了情報を電子マネーモジュール１３に送信する（ステップ１１０）。
ここで、金額変更情報を構成するコマンド群について説明する。このコマンド群の一例としては、チャージ金額を示すデータ、現在の残高を取得するコマンド、残高を「現在の残高＋チャージ金額」に書き換えるコマンド（上書き又は加算）、書換確認コマンド、ログデータ書込コマンドである。
その後、電子マネーモジュール１３は、オートチャージログデータを生成する（ステップ６００）。
この生成したオートチャージログデータは、都度上位端末１１へ送信するようにしてもよいし、電子マネーモジュール１３側で記録しておき、後に処理するようにしてもよい。
上位端末１１は、所定の時期に、通信回線８を介して、バッチ処理で電子マネーサーバ２にオートチャージログデータを送信する。
これを受けて、電子マネーサーバ２は、クレジットカード番号で特定されるカード会社に付与した与信の回収を依頼する。
なお、この例では、ステップ５０でオートチャージの条件を取得した後に、ステップ７０でバリュー残高を取得するようにしたが、この処理を逆にして、先にバリュー残高を取得するようにしてもよい。
この図８に示すフローチャートから明らかなように、電子マネーモジュール１３は、上位端末１１からの指示なしで、独自にオートチャージを行う。
なお、この例では、ステップ５０でオートチャージの条件を取得した後に、ステップ７０でバリュー残高を取得するようにしたが、この処理を逆にして、先にバリュー残高を取得するようにしてもよい。
この図８に示すフローチャートから明らかなように、電子マネーモジュール１３は、上位端末１１からの指示なしで、独自にオートチャージを行う。
次に、図９から図１４のフローチャートを参照して、本実施形態の処理手順を説明する。
まず、汎用ＩＣモジュール２５に設定されているオートチャージには、タイプＡ方式とタイプＢ方式の２種類のタイプがあるものとする。
タイプＡ方式は、決済金額に依存せずに、独自にオートチャージの条件と金額を規定するタイプである。図８に示した「バリュー残高がＸ円以下ならＹ円チャージ」というものである。このタイプＡ方式のオートチャージでは、図８に示したように、電子マネーモジュール１３は、決済金額とは無関係に、決済処理の前に、予め設定された条件に基づいてオートチャージを行う。したがって、決済処理が行われる時点で、バリュー残高が常に、オートチャージの条件判定に利用されるＸ円以上となっていることが保証されることになる。
タイプＢ方式は、上位端末１１から取得した決済金額に応じてオートチャージの要否を判定するとともに、オートチャージが必要と判定された場合はオートチャージの金額を動的に決定するタイプである。このタイプＢ方式では、決済処理の時点でバリュー残高が決済金額以上になるように必要な金額分を事前にオートチャージしておくので、バリュー残高不足で決済不能となることがない。
まず、汎用ＩＣモジュール２５に設定されているオートチャージには、タイプＡ方式とタイプＢ方式の２種類のタイプがあるものとする。
タイプＡ方式は、決済金額に依存せずに、独自にオートチャージの条件と金額を規定するタイプである。図８に示した「バリュー残高がＸ円以下ならＹ円チャージ」というものである。このタイプＡ方式のオートチャージでは、図８に示したように、電子マネーモジュール１３は、決済金額とは無関係に、決済処理の前に、予め設定された条件に基づいてオートチャージを行う。したがって、決済処理が行われる時点で、バリュー残高が常に、オートチャージの条件判定に利用されるＸ円以上となっていることが保証されることになる。
タイプＢ方式は、上位端末１１から取得した決済金額に応じてオートチャージの要否を判定するとともに、オートチャージが必要と判定された場合はオートチャージの金額を動的に決定するタイプである。このタイプＢ方式では、決済処理の時点でバリュー残高が決済金額以上になるように必要な金額分を事前にオートチャージしておくので、バリュー残高不足で決済不能となることがない。
まず、オペレータ（店員）が、リアル店舗に設置された決済端末７を操作して、上位端末１１が、決済金額を取得する（ステップ１０）。そして、ユーザ（買い物客）が、電子マネーでの決済を希望した場合、オペレータ（店員）の操作に応じて、上位端末１１は、電子マネーによる決済に移行する(ステップ１５；Ｙ）。なお、電子マネーによる決済に移行しない場合(ステップ１５；Ｎ）、店頭において貨幣又はその他の決済方法による決済が行われる。
そして、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する(ステップ２０）。このとき、上位端末１１は、汎用ＩＣモジュール２５の状態情報取得の指示も出す。
この上位端末１１からの指示を受けて、電子マネーモジュール１３は、まず、汎用ＩＣモジュール２５に当該汎用ＩＣモジュール２５の状態情報取得要求を送信する（ステップ３０）。ここで、状態情報とは、ネガティブフラグ、前回取引で書き込みエラーが発生しているか否かを示すフラグなどである。これらの情報は、後に上位端末１１に送られ、上位端末１１が、電子マネーによる決済を行うか否かの判断に用いられる。そのため、上位端末１１から状態情報取得の指示を受けた際、電子マネーモジュール１３が、オートチャージを行うことも可能である。
そして、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する(ステップ２０）。このとき、上位端末１１は、汎用ＩＣモジュール２５の状態情報取得の指示も出す。
この上位端末１１からの指示を受けて、電子マネーモジュール１３は、まず、汎用ＩＣモジュール２５に当該汎用ＩＣモジュール２５の状態情報取得要求を送信する（ステップ３０）。ここで、状態情報とは、ネガティブフラグ、前回取引で書き込みエラーが発生しているか否かを示すフラグなどである。これらの情報は、後に上位端末１１に送られ、上位端末１１が、電子マネーによる決済を行うか否かの判断に用いられる。そのため、上位端末１１から状態情報取得の指示を受けた際、電子マネーモジュール１３が、オートチャージを行うことも可能である。
次に、汎用ＩＣモジュール２５が状態情報を送信すると(ステップ３５）、電子マネーモジュール１３は、汎用ＩＣモジュール２５にアクセスし、電子マネー記憶部１２９に記憶されているオートチャージの条件の送信を要求する（ステップ４０）。
これに対して、汎用ＩＣモジュール２５は、電子マネー記憶部１２９に記憶されているオートチャージの条件、電子マネー番号及びクレジットカードの番号を送信する(ステップ５０）。
なお、汎用ＩＣモジュール２５の状態情報取得要求送信とオートチャージの条件要求送信を１の処理として一体に行うようにしてもよい。
これに対して、汎用ＩＣモジュール２５は、電子マネー記憶部１２９に記憶されているオートチャージの条件、電子マネー番号及びクレジットカードの番号を送信する(ステップ５０）。
なお、汎用ＩＣモジュール２５の状態情報取得要求送信とオートチャージの条件要求送信を１の処理として一体に行うようにしてもよい。
次に、電子マネーモジュール１３は、汎用ＩＣモジュール２５にバリュー残高の送信を要求し（ステップ６０）、汎用ＩＣモジュール２５は、当該時点でのバリュー残高を電子マネーモジュール１３に返送する（ステップ７０）。
ここで、電子マネーモジュール１３は、ステップ５０で取得したオートチャージの条件が、タイプＡ方式かタイプＢ方式か、或いはどちらも設定されていないかを判断する(ステップ８２）。
ここで、電子マネーモジュール１３は、ステップ５０で取得したオートチャージの条件が、タイプＡ方式かタイプＢ方式か、或いはどちらも設定されていないかを判断する(ステップ８２）。
この判断によりタイプＢ方式のオートチャージであった場合は、図１１のステップ２１０へ進む。また、オートチャージの条件が設定されていない場合（どちらでもない）、又はタイプＡ方式のオートチャージの条件を満たしていない場合、ステップ１２０へ進む。
そして、オートチャージの条件がタイプＡ方式で、その規定する条件に合致していた場合、図８のステップ９０からステップ１１０と同様に、電子マネーモジュール１３は、オートチャージを行うための金額変更情報を生成し、汎用ＩＣモジュール２５に送信し（ステップ９０）、この金額変更情報の送信を受けて、汎用ＩＣモジュール２５は、金額変更処理（オートチャージ）を実行し、バリュー残高を増額させる処理を実行する（ステップ１００）。そして、この処理が完了した後、金額変更（オートチャージ）完了情報を電子マネーモジュール１３に送信する（ステップ１１０）。
そして、オートチャージの条件がタイプＡ方式で、その規定する条件に合致していた場合、図８のステップ９０からステップ１１０と同様に、電子マネーモジュール１３は、オートチャージを行うための金額変更情報を生成し、汎用ＩＣモジュール２５に送信し（ステップ９０）、この金額変更情報の送信を受けて、汎用ＩＣモジュール２５は、金額変更処理（オートチャージ）を実行し、バリュー残高を増額させる処理を実行する（ステップ１００）。そして、この処理が完了した後、金額変更（オートチャージ）完了情報を電子マネーモジュール１３に送信する（ステップ１１０）。
その後、電子マネーモジュール１３は、バリュー残高を上位端末１１に送信する(ステップ１２０）。オートチャージを行わなかったときは、ステップ７０で取得したバリュー残高をそのまま送信する。オートチャージを行ったときは、オートチャージ後のバリュー残高、すなわち、増額されたバリュー残高を送信する。このとき、ステップ３５で受信した当該汎用ＩＣモジュールの状態情報も送信する。
このバリュー残高の送信を受けた上位端末１１は、ステップ１０で取得した決済金額と、このバリュー残高を比較する(ステップ１３０）。
その結果、バリュー残高が決済金額に満たない場合(ステップ１３０；Ｎ）、電子マネーによる決済ができないので、その旨をユーザに報知して(ステップ１９０）、処理を終了する。
このバリュー残高の送信を受けた上位端末１１は、ステップ１０で取得した決済金額と、このバリュー残高を比較する(ステップ１３０）。
その結果、バリュー残高が決済金額に満たない場合(ステップ１３０；Ｎ）、電子マネーによる決済ができないので、その旨をユーザに報知して(ステップ１９０）、処理を終了する。
一方、電子マネーによる決済が可能な場合(ステップ１３０；Ｙ）、上位端末１１は、ステップ１０で取得した決済金額を電子マネーモジュール１３へ送信する(ステップ１４０）。
この決済金額の送信を受けた電子マネーモジュール１３は、決済金額に相当する金額変更情報を生成し、汎用ＩＣモジュール２５に送信する（ステップ１５０）。この金額変更情報は、決済金額に相当する金額を、汎用ＩＣモジュール２５が記憶しているバリュー残高から減額させるものである。
この金額変更情報を受けて、汎用ＩＣモジュール２５は、金額変更処理（決済）を実行し、バリュー残高を決済金額分減額させる処理を実行する（ステップ１６０）。そして、この処理が完了した後、金額変更（決済）完了情報を電子マネーモジュール１３に送信する（ステップ１７０）。
この決済金額の送信を受けた電子マネーモジュール１３は、決済金額に相当する金額変更情報を生成し、汎用ＩＣモジュール２５に送信する（ステップ１５０）。この金額変更情報は、決済金額に相当する金額を、汎用ＩＣモジュール２５が記憶しているバリュー残高から減額させるものである。
この金額変更情報を受けて、汎用ＩＣモジュール２５は、金額変更処理（決済）を実行し、バリュー残高を決済金額分減額させる処理を実行する（ステップ１６０）。そして、この処理が完了した後、金額変更（決済）完了情報を電子マネーモジュール１３に送信する（ステップ１７０）。
その後、電子マネーモジュール１３は、決済完了情報を上位端末１１へ通知する（ステップ１８０）。
そして、上位端末１１は、決済が完了した旨をユーザに例えば決済完了音を鳴らすことにより報知する（ステップ２００）。
その後、ユーザは、電子マネーカード１００をリーダライタ部１３９から取り去る。
なお、図８のステップ６００と同様に、電子マネーモジュール１３は、オートチャージログデータを生成する。
そして、上位端末１１は、決済が完了した旨をユーザに例えば決済完了音を鳴らすことにより報知する（ステップ２００）。
その後、ユーザは、電子マネーカード１００をリーダライタ部１３９から取り去る。
なお、図８のステップ６００と同様に、電子マネーモジュール１３は、オートチャージログデータを生成する。
次に、図１１から図１４を参照して、オートチャージの条件がタイプＢ方式であった場合の処理手順を説明する。
図９のステップ８２の判断で、オートチャージの条件がタイプＢ方式であった場合、処理は図１１に示すフローチャートのステップ２１０へ進む。
タイプＢ方式のオートチャージを行うには、上位端末１１から事前に決済金額を取得する必要がある。そこで、電子マネーモジュール１３は、上位端末１１へ仮のバリュー残高を送信する（ステップ２１０）。これは、ステップ７０で取得したバリュー残高をそのまま送信すると、上位端末１１で、ステップ１０で取得した決済金額との比較の結果、決済不能となる恐れがあるためである。
図９のステップ８２の判断で、オートチャージの条件がタイプＢ方式であった場合、処理は図１１に示すフローチャートのステップ２１０へ進む。
タイプＢ方式のオートチャージを行うには、上位端末１１から事前に決済金額を取得する必要がある。そこで、電子マネーモジュール１３は、上位端末１１へ仮のバリュー残高を送信する（ステップ２１０）。これは、ステップ７０で取得したバリュー残高をそのまま送信すると、上位端末１１で、ステップ１０で取得した決済金額との比較の結果、決済不能となる恐れがあるためである。
各電子マネーでは、例えば、２００００円、５００００円といったバリュー残高の上限値を設けている。そのため、このバリュー残高の上限値を仮のバリュー残高とすることで、ステップ２２０の判断で決済不能となることを防止できる。
また、後のオートチャージを考慮に入れ、現在のバリュー残高にオートチャージ可能な金額の上限値を加えた金額を仮のバリュー残高として送信するようにしてもよい。
また、後のオートチャージを考慮に入れ、現在のバリュー残高にオートチャージ可能な金額の上限値を加えた金額を仮のバリュー残高として送信するようにしてもよい。
そして、この仮のバリュー残高を受信した上位端末１１は、ステップ１０で取得した決済金額とこの仮のバリュー残高とを比較して、決済可能か否かを判断する(ステップ２２０）。この仮のバリュー残高は、現在のバリュー残高を上積みした値なので、かなりの確率で決済可能となる。
判断の結果、決済可能となった場合(ステップ２２０；Ｙ）、上位端末１１は、ステップ１０で取得した決済金額を電子マネーモジュール１３に送信する（ステップ２３０）。一方、判断の結果、決済不能となった場合(ステップ２２０；Ｎ）、上位端末１１は、決済が不能である旨をユーザに報知する(ステップ３５０）。
決済金額を受信した電子マネーモジュール１３は、一旦当該決済金額を記憶する(ステップ２４０）。
判断の結果、決済可能となった場合(ステップ２２０；Ｙ）、上位端末１１は、ステップ１０で取得した決済金額を電子マネーモジュール１３に送信する（ステップ２３０）。一方、判断の結果、決済不能となった場合(ステップ２２０；Ｎ）、上位端末１１は、決済が不能である旨をユーザに報知する(ステップ３５０）。
決済金額を受信した電子マネーモジュール１３は、一旦当該決済金額を記憶する(ステップ２４０）。
ここで、電子マネーモジュール１３は、リトライ処理が必要か否かを判断する(ステップ２５０）。
リトライ処理とは、エラー情報を送信して、一連のトランザクションの中で再度処理をやり直す処理をいう。ここで、リトライ処理が必要な場合とは、上位端末１１が、ステップ２１０で送信された仮のバリュー残高を記憶しておくタイプのときである。仮のバリュー残高を記憶しておくと、後に実際にオートチャージを行った場合のバリュー残高とに齟齬が生じるためである。
そのため、リトライ処理を行い、一旦送信した仮のバリュー残高を消去することが必要となる。リトライ処理が必要な場合(ステップ２５０；Ｙ）、図１３及び図１４に示すフローチャートの処理へ移行する。
リトライ処理とは、エラー情報を送信して、一連のトランザクションの中で再度処理をやり直す処理をいう。ここで、リトライ処理が必要な場合とは、上位端末１１が、ステップ２１０で送信された仮のバリュー残高を記憶しておくタイプのときである。仮のバリュー残高を記憶しておくと、後に実際にオートチャージを行った場合のバリュー残高とに齟齬が生じるためである。
そのため、リトライ処理を行い、一旦送信した仮のバリュー残高を消去することが必要となる。リトライ処理が必要な場合(ステップ２５０；Ｙ）、図１３及び図１４に示すフローチャートの処理へ移行する。
一方、上位装置１１が、ステップ２１０で送信された仮のバリュー残高を記憶しておかないタイプのとき（すなわち、仮のバリュー残高をステップ２２０の判断にのみ使用する場合）、リトライ処理が必要なく(ステップ２５０；Ｎ）、電子マネーモジュール１３は、ステップ２４０で記憶した決済金額に基づき、オートチャージのための金額変更情報を生成する。ここで、金額変更情報の生成の仕方として以下の方法があげられる。
（１）（決済金額）−（バリュー残高）で求められる値、すなわち、当該決済で最低限必要な金額をオートチャージする。
（２）決済金額をそのままオートチャージする。決済後もバリュー残高が変動しないようにする。
（３）決済後のバリュー残高が所定の値になるようにオートチャージする。
（１）（決済金額）−（バリュー残高）で求められる値、すなわち、当該決済で最低限必要な金額をオートチャージする。
（２）決済金額をそのままオートチャージする。決済後もバリュー残高が変動しないようにする。
（３）決済後のバリュー残高が所定の値になるようにオートチャージする。
具体例で説明すると、決済金額が１１００円、バリュー残高が８００円、バリュー残高の所定の値が１０００円とする。
（１）の場合、１１００円−８００円で、３００円分の金額変更情報を生成してオートチャージを行う。
（２）の場合、決済金額１１００円分の金額変更情報を生成してオートチャージを行う。
（３）決済金額１１００円分＋（所定の値１０００円分−バリュー残高８００円分）＝１３００円分の金額変更情報を生成してオートチャージを行う。
（１）の場合、１１００円−８００円で、３００円分の金額変更情報を生成してオートチャージを行う。
（２）の場合、決済金額１１００円分の金額変更情報を生成してオートチャージを行う。
（３）決済金額１１００円分＋（所定の値１０００円分−バリュー残高８００円分）＝１３００円分の金額変更情報を生成してオートチャージを行う。
その後、ステップ２６０で生成した金額変更情報を汎用ＩＣモジュール２５に送信する（ステップ２７０）。この金額変更情報の送信を受けて、汎用ＩＣモジュール２５は、金額変更処理（オートチャージ）を実行し、バリュー残高を増額させる処理を実行する（ステップ２８０）。そして、この処理が完了した後、金額変更（オートチャージ）完了情報を電子マネーモジュール１３に送信する（ステップ２９０）。
その後、電子マネーモジュール１３は、ステップ２４０で記憶した決済金額に基づき、金額変更情報を生成し、汎用ＩＣモジュール２５に送信する（ステップ３００）。この金額変更情報は、決済金額に相当する金額を、汎用ＩＣモジュール２５が記憶しているバリュー残高から減額させるものである。
この金額変更情報を受けて、汎用ＩＣモジュール２５は、金額変更処理（決済）を実行し、バリュー残高を決済金額分減額させる処理を実行する（ステップ３１０）。そして、この処理が完了した後、金額変更（決済）完了情報を電子マネーモジュール１３に送信する（ステップ３２０）。
この金額変更情報を受けて、汎用ＩＣモジュール２５は、金額変更処理（決済）を実行し、バリュー残高を決済金額分減額させる処理を実行する（ステップ３１０）。そして、この処理が完了した後、金額変更（決済）完了情報を電子マネーモジュール１３に送信する（ステップ３２０）。
その後、電子マネーモジュール１３は、決済完了情報を上位端末１１へ通知し（ステップ３３０）、ステップ２４０で記憶した決済金額を消去する（ステップ３４０）。
そして、上位端末１１は、決済が完了した旨をユーザに例えば決済完了音を鳴らすことにより報知する（ステップ３６０）。
その後、ユーザは、電子マネーカード１００をリーダライタ部１３９から取り去る。
なお、図８のステップ６００と同様に、電子マネーモジュール１３は、オートチャージログデータを生成する。
そして、上位端末１１は、決済が完了した旨をユーザに例えば決済完了音を鳴らすことにより報知する（ステップ３６０）。
その後、ユーザは、電子マネーカード１００をリーダライタ部１３９から取り去る。
なお、図８のステップ６００と同様に、電子マネーモジュール１３は、オートチャージログデータを生成する。
次に、リトライ処理を行う場合の処理手順を図１３及び図１４のフローチャートを参照して説明する。
まず、電子マネーモジュール１３は、エラー情報・リトライ要求を送信して（ステップ４１０）、再度決済処理を行うように要求する。このリトライ処理は、一連の決済処理を一旦終了して、再度処理を再開するものではなく、一連の決済処理を維持しつつ、処理をやり直す処理である。この場合、電子マネーカード１００のユーザは、当該電子マネーカード１００をかざしたままの状態でよく、再度電子マネーカードをリーダライタ部１３９に近接させる必要はない。
まず、電子マネーモジュール１３は、エラー情報・リトライ要求を送信して（ステップ４１０）、再度決済処理を行うように要求する。このリトライ処理は、一連の決済処理を一旦終了して、再度処理を再開するものではなく、一連の決済処理を維持しつつ、処理をやり直す処理である。この場合、電子マネーカード１００のユーザは、当該電子マネーカード１００をかざしたままの状態でよく、再度電子マネーカードをリーダライタ部１３９に近接させる必要はない。
このリトライ要求を受けて、上位端末１１は、エラー処理を行う（ステップ４２０）。具体的には、ステップ２１０で送信された仮のバリュー残高を消去し、一旦終了することなく再度最初からやり直すための処理である。
まず、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する(ステップ４３０）。
このバリュー残高要求送信を受けて、電子マネーモジュール１３は、ステップ２４０で記憶した決済金額に基づき、オートチャージのための金額変更情報を生成する（ステップ４４０）。ここで、金額変更情報の生成の仕方は、ステップ２６０で説明した例と同様である。
まず、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する(ステップ４３０）。
このバリュー残高要求送信を受けて、電子マネーモジュール１３は、ステップ２４０で記憶した決済金額に基づき、オートチャージのための金額変更情報を生成する（ステップ４４０）。ここで、金額変更情報の生成の仕方は、ステップ２６０で説明した例と同様である。
その後、ステップ４４０で生成した金額変更情報を汎用ＩＣモジュール２５に送信する（ステップ４５０）。この金額変更情報の送信を受けて、汎用ＩＣモジュール２５は、金額変更処理（オートチャージ）を実行し、バリュー残高を増額させる処理を実行する（ステップ４６０）。そして、この処理が完了した後、金額変更（オートチャージ）完了情報を電子マネーモジュール１３に送信する（ステップ４７０）。
その後、電子マネーモジュール１３は、オートチャージ後のバリュー残高を上位端末１１に送信する(ステップ４８０）。
このバリュー残高の送信を受けた上位端末１１は、ステップ１０で取得した決済金額と、このバリュー残高を比較する(ステップ４９０）。
ステップ４５０からステップ４７０で決済金額に基づいたオートチャージを行っているので、オートチャージが正常に完了していれば、ここでバリュー残高が不足することはない。仮に、バリュー残高が決済金額に満たない場合(ステップ４９０；Ｎ）、電子マネーによる決済ができないので、その旨をユーザに報知して(ステップ５６０）、処理を終了する。
このバリュー残高の送信を受けた上位端末１１は、ステップ１０で取得した決済金額と、このバリュー残高を比較する(ステップ４９０）。
ステップ４５０からステップ４７０で決済金額に基づいたオートチャージを行っているので、オートチャージが正常に完了していれば、ここでバリュー残高が不足することはない。仮に、バリュー残高が決済金額に満たない場合(ステップ４９０；Ｎ）、電子マネーによる決済ができないので、その旨をユーザに報知して(ステップ５６０）、処理を終了する。
一方、電子マネーによる決済が可能な場合(ステップ４９０；Ｙ）、上位端末１１は、ステップ１０で取得した決済金額を電子マネーモジュール１３へ送信する(ステップ５００）。
この決済金額の送信を受けた電子マネーモジュール１３は、決済金額に相当する金額変更情報を生成し、汎用ＩＣモジュール２５に送信する（ステップ５１０）。電子マネーモジュール１３は、ステップ２３０で決済金額を受信しているので、２度目の受信となる。この金額変更情報は、決済金額に相当する金額を、汎用ＩＣモジュール２５が記憶しているバリュー残高から減額させるものである。
この決済金額の送信を受けた電子マネーモジュール１３は、決済金額に相当する金額変更情報を生成し、汎用ＩＣモジュール２５に送信する（ステップ５１０）。電子マネーモジュール１３は、ステップ２３０で決済金額を受信しているので、２度目の受信となる。この金額変更情報は、決済金額に相当する金額を、汎用ＩＣモジュール２５が記憶しているバリュー残高から減額させるものである。
この金額変更情報を受けて、汎用ＩＣモジュール２５は、金額変更処理（決済）を実行し、バリュー残高を決済金額分減額させる処理を実行する（ステップ５２０）。そして、この処理が完了した後、金額変更（決済）完了情報を電子マネーモジュール１３に送信する（ステップ５３０）。
その後、電子マネーモジュール１３は、決済完了情報を上位端末１１へ通知する（ステップ５４０）。その後、記憶した決済金額を消去する(ステップ５５０）。
そして、上位端末１１は、決済が完了した旨をユーザに例えば決済完了音を鳴らすことにより報知する（ステップ５７０）。
なお、図８のステップ６００と同様に、電子マネーモジュール１３は、オートチャージログデータを生成する。
この図１１から図１４に示される処理によれば、上位端末１１の処理手順を変更させることなく、決済金額に基づくオートチャージを行うことができる。
その後、電子マネーモジュール１３は、決済完了情報を上位端末１１へ通知する（ステップ５４０）。その後、記憶した決済金額を消去する(ステップ５５０）。
そして、上位端末１１は、決済が完了した旨をユーザに例えば決済完了音を鳴らすことにより報知する（ステップ５７０）。
なお、図８のステップ６００と同様に、電子マネーモジュール１３は、オートチャージログデータを生成する。
この図１１から図１４に示される処理によれば、上位端末１１の処理手順を変更させることなく、決済金額に基づくオートチャージを行うことができる。
次に、決済を行う状況に応じて、オートチャージの条件の変更を行う場合の処理手順を図１５のフローチャートを参照して説明する。
まず、オペレータ（店員）が、リアル店舗に設置された決済端末７を操作して、上位端末１１が、決済金額を取得する（ステップ１０）。そして、ユーザ（買い物客）が、電子マネーでの決済を希望した場合、オペレータ（店員）の操作に応じて、上位端末１１は、電子マネーによる決済に移行する(ステップ１５；Ｙ）。電子マネーによる決済に移行しない場合(ステップ１５；Ｎ）、店頭において貨幣による決済が行われる。
そして、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する。このとき、当該上位端末１１の区分に関する情報も送信する(ステップ２２）。この例では、上位端末１１から当該上位端末１１の区分に関する情報を送信するようにしたが、予め電子マネーモジュール１３に区分を記憶させておくことで、決済の都度区分を送信しないようにすることもできる。
まず、オペレータ（店員）が、リアル店舗に設置された決済端末７を操作して、上位端末１１が、決済金額を取得する（ステップ１０）。そして、ユーザ（買い物客）が、電子マネーでの決済を希望した場合、オペレータ（店員）の操作に応じて、上位端末１１は、電子マネーによる決済に移行する(ステップ１５；Ｙ）。電子マネーによる決済に移行しない場合(ステップ１５；Ｎ）、店頭において貨幣による決済が行われる。
そして、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する。このとき、当該上位端末１１の区分に関する情報も送信する(ステップ２２）。この例では、上位端末１１から当該上位端末１１の区分に関する情報を送信するようにしたが、予め電子マネーモジュール１３に区分を記憶させておくことで、決済の都度区分を送信しないようにすることもできる。
ここで、区分に関する情報とは、例えば当該上位端末１１が、鉄道の駅に設置された改札機、バスの車内に設置された精算機、駅中の店舗端末であるといったバリュー残高不足で決済手順が停止すると、当該ユーザだけでなく、他のユーザにも影響が大きい環境に設置される上位端末１１が分類される区分である。
また、時刻に関する情報例えば、朝夕の通勤ラッシュアワーである旨を付加するようにしてもよい。
また、平均的な決済金額が相対的に高い店舗に設置される上位端末１１が分類される区分である。具体的には、客単価が相対的に高い店舗、ファミリーレストランのように複数名で来店し、代表者が一括して決済を行う店舗である。
このような区分に分類される上位端末１１である旨をバリュー残高要求とともに電子マネーモジュール１３に伝えること、若しくは予め電子マネーモジュール１３に区分を記憶させておくことで、オートチャージの条件を変更し（閾値をあげる又は１回のチャージの金額をあげる）、残高不足で決済不能となるのを可能な限り防止する。
また、時刻に関する情報例えば、朝夕の通勤ラッシュアワーである旨を付加するようにしてもよい。
また、平均的な決済金額が相対的に高い店舗に設置される上位端末１１が分類される区分である。具体的には、客単価が相対的に高い店舗、ファミリーレストランのように複数名で来店し、代表者が一括して決済を行う店舗である。
このような区分に分類される上位端末１１である旨をバリュー残高要求とともに電子マネーモジュール１３に伝えること、若しくは予め電子マネーモジュール１３に区分を記憶させておくことで、オートチャージの条件を変更し（閾値をあげる又は１回のチャージの金額をあげる）、残高不足で決済不能となるのを可能な限り防止する。
これを受けて、電子マネーモジュール１３は、図９のステップ３０からステップ７０と同一の処理を行い、ステップ５０で、オートチャージの条件及びその条件が変更可となっているか、ステップ７０で、バリュー残高を取得する。
そして、電子マネーモジュール１３は、オートチャージの条件変更が必要か否かを判断する（ステップ７５）。
具体的には、駅の改札機の場合、オートチャージ開始の閾値を１０００円から２０００円にする、客単価が相対的に高い店では、チャージ金額を５０００円から１００００円にするである。
そして、電子マネーモジュール１３は、オートチャージの条件変更が必要か否かを判断する（ステップ７５）。
具体的には、駅の改札機の場合、オートチャージ開始の閾値を１０００円から２０００円にする、客単価が相対的に高い店では、チャージ金額を５０００円から１００００円にするである。
オートチャージの条件変更が必要と判断された場合（ステップ７５；Ｙ）、オートチャージの条件変更を行い（ステップ７８）、変更後のオートチャージの条件に合致するか否かを判断する（ステップ８０）。一方、オートチャージの条件変更が必要ないと判断された場合（ステップ７５；Ｎ）、オートチャージの条件を変更せずに、オートチャージの条件に合致するか否かを判断する（ステップ８０）。
そして、オートチャージの条件に合致した場合（ステップ８０；Ｙ）、オートチャージを行う（ステップ９０〜ステップ１１０）。一方、オートチャージの条件に合致しない場合（ステップ８０；Ｎ）、ステップ１２０へ進む。
その後の処理は、図１０のステップ１２０からステップ２００と同一である。
この実施例に示す処理によれば、上位端末１１の区分の情報に応じて、オートチャージの条件を変更するので、バリュー残高不足で決済手順が停止する可能性をより減少させることができる。
そして、オートチャージの条件に合致した場合（ステップ８０；Ｙ）、オートチャージを行う（ステップ９０〜ステップ１１０）。一方、オートチャージの条件に合致しない場合（ステップ８０；Ｎ）、ステップ１２０へ進む。
その後の処理は、図１０のステップ１２０からステップ２００と同一である。
この実施例に示す処理によれば、上位端末１１の区分の情報に応じて、オートチャージの条件を変更するので、バリュー残高不足で決済手順が停止する可能性をより減少させることができる。
次に、上位端末１１から決済処理開始の段階で決済金額を通知された場合の処理手順を図１６、図１７のフローチャートを参照して説明する。
まず、オペレータ（店員）が、リアル店舗に設置された決済端末７を操作して、上位端末１１が、決済金額を取得する（ステップ１０）。そして、ユーザ（買い物客）が、電子マネーでの決済を希望した場合、オペレータ（店員）の操作に応じて、上位端末１１は、電子マネーによる決済に移行する(ステップ１５；Ｙ）。電子マネーによる決済に移行しなし場合(ステップ１５；Ｎ）、店頭において貨幣による決済が行われる。
そして、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する。このとき、ステップ１０で取得した決済金額も送信する(ステップ２４）。
これを受けて、電子マネーモジュール１３は、図９のステップ３０からステップ７０と同一の処理を行い、ステップ５０で、オートチャージの条件、ステップ７０で、バリュー残高を取得する。
まず、オペレータ（店員）が、リアル店舗に設置された決済端末７を操作して、上位端末１１が、決済金額を取得する（ステップ１０）。そして、ユーザ（買い物客）が、電子マネーでの決済を希望した場合、オペレータ（店員）の操作に応じて、上位端末１１は、電子マネーによる決済に移行する(ステップ１５；Ｙ）。電子マネーによる決済に移行しなし場合(ステップ１５；Ｎ）、店頭において貨幣による決済が行われる。
そして、上位端末１１は、電子マネーモジュール１３にバリュー残高要求を送信する。このとき、ステップ１０で取得した決済金額も送信する(ステップ２４）。
これを受けて、電子マネーモジュール１３は、図９のステップ３０からステップ７０と同一の処理を行い、ステップ５０で、オートチャージの条件、ステップ７０で、バリュー残高を取得する。
そして、ステップ５０で取得したオートチャージの条件がタイプＢ方式か否かを判断する（ステップ７９）。オートチャージの条件がタイプＡ方式の場合、又はオートチャージの条件が設定されていない場合、決済金額と処理が関係ないので、図９のステップ８２に進み、処理を継続する。但し、電子マネーモジュール１３が、既に決済金額を取得しているので、バリュー残高を上位端末１１に送信（ステップ１２０）せずに、独自に決済可能か否かの判断（ステップ１３０）を行うようにしてもよい。
一方、オートチャージがタイプＢ方式の場合（ステップ７９；Ｙ）、オートチャージの条件に合致しているか否かを判断し（ステップ８８）、合致していれば（ステップ８８；Ｙ）、オートチャージを行う（ステップ９０〜ステップ１１０）。
一方、オートチャージがタイプＢ方式の場合（ステップ７９；Ｙ）、オートチャージの条件に合致しているか否かを判断し（ステップ８８）、合致していれば（ステップ８８；Ｙ）、オートチャージを行う（ステップ９０〜ステップ１１０）。
オートチャージが完了した後、又はオートチャージの条件に合致しなかった場合（ステップ８８；Ｎ）、ステップ１５０からステップ２００の決済処理へ移行する。
なお、ステップ１１０のオートチャージ完了後、バリュー残高を上位端末１１に送信して、上位端末１１側で図１０のステップ１３０のように、決済可否の判断を行うようにしてもよい。
なお、ステップ１１０のオートチャージ完了後、バリュー残高を上位端末１１に送信して、上位端末１１側で図１０のステップ１３０のように、決済可否の判断を行うようにしてもよい。
この図１６、図１７に示す処理では、ステップ２４で電子マネーモジュール１３は、決済金額を取得しているので、ステップ８８でオートチャージの条件に合致していると判断したとき、直ちにオートチャージを行わず、オートチャージを行う金額と決済金額との差し引きを行い、その差額を一回の処理で汎用ＩＣモジュール２５のバリュー残高を書き換えるようにすることができる。
具体例で説明すると、決済金額が１１００円、チャージ金額が３００円の場合、１１００−３００で８００円分のバリュー残高を減額する金額変更情報を生成する。
また、決済金額１１００円分、チャージ金額が１３００円の場合、１３００−１１００で２００円分のバリュー残高を増額する金額変更情報を生成する。
こうして生成した金額変更情報を汎用ＩＣモジュール２５に送信することで、１回の処理でバリュー残高の書き換えを行うことができ、書き込みエラーによる決済処理が終了する可能性を減少させることができる。
但し、チャージのログデータと決済のログデータは、各々汎用ＩＣモジュール２５に書き込むようにする。入手金の履歴を明確にしておくためである。
また、チャージのログデータと決済のログデータを生成し、上位端末１１を介して、バッチ処理で電子マネーサーバ２へ送信するようにする。これも入手金の履歴を明確にしておくためである。
また、決済金額１１００円分、チャージ金額が１３００円の場合、１３００−１１００で２００円分のバリュー残高を増額する金額変更情報を生成する。
こうして生成した金額変更情報を汎用ＩＣモジュール２５に送信することで、１回の処理でバリュー残高の書き換えを行うことができ、書き込みエラーによる決済処理が終了する可能性を減少させることができる。
但し、チャージのログデータと決済のログデータは、各々汎用ＩＣモジュール２５に書き込むようにする。入手金の履歴を明確にしておくためである。
また、チャージのログデータと決済のログデータを生成し、上位端末１１を介して、バッチ処理で電子マネーサーバ２へ送信するようにする。これも入手金の履歴を明確にしておくためである。
図９に示す処理手順では、上位端末１１から、ステップ２０でバリュー残高要求送信を電子マネーモジュール１３が受信したことを契機として、オートチャージの可否を判断している。しかし、ステップ２０でバリュー残高要求送信は、決済を前提とせず、単にバリュー残高を確認するために行う場合もある。
そこで、ステップ２０でバリュー残高要求送信に、決済処理を前提としていることを示すフラグを付加し、このフラグが付加されている場合に限り、オートチャージの可否を判断するようにする。こうすることで、決済の直前にのみオートチャージがなされることとなる。そのため、例えば、リアル店舗で貨幣との交換でのチャージを行おうとして、バリュー残高の確認をした際、オートチャージが行われてしまうということを防止できる。
そこで、ステップ２０でバリュー残高要求送信に、決済処理を前提としていることを示すフラグを付加し、このフラグが付加されている場合に限り、オートチャージの可否を判断するようにする。こうすることで、決済の直前にのみオートチャージがなされることとなる。そのため、例えば、リアル店舗で貨幣との交換でのチャージを行おうとして、バリュー残高の確認をした際、オートチャージが行われてしまうということを防止できる。
以上説明した実施形態では、実社会で広く普及している電子マネーについて、説明したが、本発明は、これに限定されるものではない。
例えば、特定のアミューズメント施設でのみ利用されるＩＣを用いたシステムに応用することができる。すなわち、バーチャル貸し玉、貸しコインの量を（これらを（電子）バリューとみなして）ＩＣカードに記憶しておき、それらを利用する場合に、一定の条件の基にオートチャージを行い、バーチャル貸し玉、貸しコインの不足でゲーム等に参加できないということを極力防止することができる。
例えば、特定のアミューズメント施設でのみ利用されるＩＣを用いたシステムに応用することができる。すなわち、バーチャル貸し玉、貸しコインの量を（これらを（電子）バリューとみなして）ＩＣカードに記憶しておき、それらを利用する場合に、一定の条件の基にオートチャージを行い、バーチャル貸し玉、貸しコインの不足でゲーム等に参加できないということを極力防止することができる。
１ 電子マネーシステム
２ 電子マネーサーバ
７ 決済端末
８ 通信回線
１１ 上位端末
１３ 電子マネーモジュール
２５ 汎用ＩＣモジュール
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３４ 通信制御部
３５ 記憶部
３６ バスライン
１００ 電子マネーカード
１２１ ＣＰＵ
１２２ 高周波回路
１２３ ＲＯＭ
１２４ ＲＡＭ
１２５ ＥＥＰＲＯＭ
１２６ アンテナ
１２７ 端末通信部
１２８ バリュー処理部
１２９ 電子マネー記憶部
１３１ ＣＰＵ
１３３ ＲＯＭ
１３４ ＲＡＭ
１３５ 通信制御部
１３６ 記憶部
１３７ 入力部
１３８ 出力部
１３９ リーダライタ部
１４２ プログラム格納部
１４４ データ格納部
３００ クレジット会社サーバ
２ 電子マネーサーバ
７ 決済端末
８ 通信回線
１１ 上位端末
１３ 電子マネーモジュール
２５ 汎用ＩＣモジュール
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３４ 通信制御部
３５ 記憶部
３６ バスライン
１００ 電子マネーカード
１２１ ＣＰＵ
１２２ 高周波回路
１２３ ＲＯＭ
１２４ ＲＡＭ
１２５ ＥＥＰＲＯＭ
１２６ アンテナ
１２７ 端末通信部
１２８ バリュー処理部
１２９ 電子マネー記憶部
１３１ ＣＰＵ
１３３ ＲＯＭ
１３４ ＲＡＭ
１３５ 通信制御部
１３６ 記憶部
１３７ 入力部
１３８ 出力部
１３９ リーダライタ部
１４２ プログラム格納部
１４４ データ格納部
３００ クレジット会社サーバ
Claims (14)
- 支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置からの残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する変更手段と、
を具備し、
前記通常条件は、前記当初の残度数が前記支払装置に対して予め規定されている閾値以下又は未満の場合に少なくとも該支払装置に対して予め規定されている前記補充度数分だけ補充すると判定される条件であり、
前記通常条件を満たす場合に、補充後の残度数が前記加算後の残度数になるように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、
前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答し、
前記指示装置から取得されるデータにより特定される当該指示装置の区分に応じて、前記所定の閾値と前記支払装置に対して予め規定されている前記補充度数との少なくともいずれかを上方修正する修正手段をさらに具備した、
ことを特徴とする受付装置。 - 前記修正手段は、前記通常条件の判定時点が所定の時間帯に含まれる場合に限り、前記所定の閾値と前記補充度数との少なくともいずれかを上方修正する、
ことを特徴とする請求項１記載の受付装置。 - 支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置からの残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する変更手段と、
を具備し、
前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記当初の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、 前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、
前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答し、
前記変更手段は、データを一時的に保持する保持手段に支払度数が記憶されていない場合に限り、前記残度数変更要求に付加される支払度数を該保持手段に保持させるとともに、前記指示装置から前記残度数参照要求を再度受けるため該残度数変更要求に対してエラーを返し、
前記参照手段は、前記保持手段に支払度数が記憶されている場合に限り、該支払度数を用いて前記特殊条件を満たすか否かを判定するとともに、該保持手段から支払度数を消去させる、
ことを特徴とする受付装置。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、
を具備したことを特徴とする受付装置。 - 前記参照手段は、前記残度数参照要求を受けた後に前記通常条件を満たすか否かを判定する、
ことを特徴とする請求項４記載の受付装置。 - 前記通常条件は、前記当初の残度数が前記支払装置に対して予め規定されている閾値以下又は未満の場合に少なくとも該支払装置に対して予め規定されている前記補充度数分だけ補充すると判定される条件であり、
前記通常条件を満たす場合に、補充後の残度数が前記加算後の残度数になるように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、
前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、
ことを特徴とする請求項４又は請求項５記載の受付装置。 - 前記変更手段により前記支払装置に記憶される残度数が変更された後に、前記当初の残度数に前記補充度数を加算したことを示す入金ログデータと、前記加算後の残度数から前記支払度数を減算したことを示す出金ログデータと、をそれぞれ生成する生成手段をさらに具備した、
ことを特徴とする請求項４又は請求項５記載の受付装置。 - 前記生成される入金ログデータと出金ログデータとを該支払装置にそれぞれ書き込む書込手段をさらに具備した、
ことを特徴とする請求項７記載の受付装置。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、
前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記当初の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、
前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、
前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、
ことを特徴とする受付装置。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、
前記参照手段は、前記支払度数を用いることができる場合に限り、前記通常条件に代えて、前記加算後の残度数が該支払度数に対して不足する場合に少なくとも該不足する度数に相当する前記補充度数分だけ補充が必要と判定される特殊条件を満たすか否かを判定し、
前記特殊条件を満たす場合に、前記支払装置に記憶される残度数を少なくとも前記補充度数分だけ増加させる補充手段をさらに具備し、
前記参照手段は、前記残度数参照要求に対して、前記支払装置から取得される補充後の残度数を応答する、
ことを特徴とする受付装置。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、
前記参照手段は、前記残度数参照要求を受けた後に前記通常条件を満たすか否かを判定し、
且つ前記参照手段は、前記残度数参照要求の内容又はこれに付加されるデータに基づき該残度数参照要求に前記残度数変更要求が続かないと判定される場合に、該残度数参照要求に対して、前記加算後の残度数に代えて、前記支払装置から取得される当初の残度数を応答する、
ことを特徴とする受付装置。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算した加算後の残度数を応答する参照手段と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更手段と、を具備し、
前記支払度数が付加された前記残度数変更要求を受けた場合に、補充後の残度数が該支払度数を下回らないように前記支払装置に記憶される残度数を変更する補充手段をさらに具備し、
前記変更手段は、支払後の残度数が前記補充後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を変更する、
ことを特徴とする受付装置。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照ステップと、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更ステップと、
を含む、受付装置の制御方法。 - 決済金額を取得し、且つ支払装置に記憶される電子バリューの残度数を補充する通常条件を満たす場合に、支払度数と残度数との比較結果に基づき支払いの可否を判定する指示装置から、前記支払装置への残度数参照要求に対して、該支払装置から取得される当初の残度数に補充度数を加算し、該加算後の残度数を応答する参照機能と、
前記応答される加算後の残度数による支払いが可能と判定した前記指示装置からの残度数変更要求に応じて、支払後の残度数が前記加算後の残度数から前記支払度数を減算した値になるように前記支払装置に記憶される残度数を独自に変更する変更機能と、
をコンピュータに実現させるためのプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013169569A JP6455863B2 (ja) | 2013-08-19 | 2013-08-19 | 受付装置、受付装置の制御方法、及びプログラム |
| TW103128448A TWI659372B (zh) | 2013-08-19 | 2014-08-19 | Receiving device, control method of receiving device, and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013169569A JP6455863B2 (ja) | 2013-08-19 | 2013-08-19 | 受付装置、受付装置の制御方法、及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015038692A JP2015038692A (ja) | 2015-02-26 |
| JP6455863B2 true JP6455863B2 (ja) | 2019-01-23 |
Family
ID=52631729
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013169569A Active JP6455863B2 (ja) | 2013-08-19 | 2013-08-19 | 受付装置、受付装置の制御方法、及びプログラム |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP6455863B2 (ja) |
| TW (1) | TWI659372B (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6634792B2 (ja) * | 2015-11-27 | 2020-01-22 | 沖電気工業株式会社 | 情報処理装置、情報処理システム、及び情報処理方法 |
| JP7021534B2 (ja) * | 2017-12-25 | 2022-02-17 | オムロン株式会社 | カード処理端末、カード決済方法、およびカード決済プログラム |
| JP7251210B2 (ja) * | 2019-02-27 | 2023-04-04 | 日本電気株式会社 | 情報処理装置、サーバ、情報処理システム、情報処理方法、および情報処理プログラム |
| JP7421741B2 (ja) * | 2019-04-23 | 2024-01-25 | 株式会社Kyash | 法定通貨バリュー、電子マネー、その他ポイント等の各種バリューのチャージ、入金方法及びシステム |
| JP7483366B2 (ja) * | 2019-12-17 | 2024-05-15 | 東芝テック株式会社 | 情報処理装置及びその制御プログラム |
| JP7448713B1 (ja) | 2023-06-14 | 2024-03-12 | ＰａｙＰａｙ株式会社 | 決済管理装置、決済管理方法、アプリケーションプログラム、および決済管理システム |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002092706A (ja) * | 2000-09-13 | 2002-03-29 | Oki Electric Ind Co Ltd | 支払システム及び電子通貨取扱装置 |
| JP2002342680A (ja) * | 2001-04-27 | 2002-11-29 | Internatl Business Mach Corp <Ibm> | サーバ、端末、自動取引処理端末、電子マネー決済端末、処理システム、電子マネーの残高補充方法 |
| JP2007079821A (ja) * | 2005-09-13 | 2007-03-29 | Daiichikosho Co Ltd | 電子マネー決済端末、自動入金管理装置 |
| JP5396001B2 (ja) * | 2006-12-13 | 2014-01-22 | 楽天Ｅｄｙ株式会社 | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
| JP5189297B2 (ja) * | 2007-01-31 | 2013-04-24 | 楽天株式会社 | 決済処理装置、決済処理方法、及び決済処理プログラム |
| JP2010026811A (ja) * | 2008-07-18 | 2010-02-04 | Fuji Electric Holdings Co Ltd | Ｉｃカード・サービスシステム、そのサービス管理センタ、サービス端末、プログラム |
| JP2011013740A (ja) * | 2009-06-30 | 2011-01-20 | Toppan Printing Co Ltd | Ｉｃカードを用いたキャッシュレスシステム |
-
2013
- 2013-08-19 JP JP2013169569A patent/JP6455863B2/ja active Active
-
2014
- 2014-08-19 TW TW103128448A patent/TWI659372B/zh active
Also Published As
| Publication number | Publication date |
|---|---|
| TW201523474A (zh) | 2015-06-16 |
| TWI659372B (zh) | 2019-05-11 |
| JP2015038692A (ja) | 2015-02-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20190156308A1 (en) | Mobile telephone transfer of funds | |
| JP5189297B2 (ja) | 決済処理装置、決済処理方法、及び決済処理プログラム | |
| JP5595434B2 (ja) | 情報処理サーバ、情報処理方法、情報処理プログラム及び情報処理プログラムを記録した記録媒体 | |
| JP6455863B2 (ja) | 受付装置、受付装置の制御方法、及びプログラム | |
| KR101652840B1 (ko) | 정보 처리 서버, 정보 처리 방법, 정보 처리 프로그램이 기록된 기록 매체, 휴대 단말기, 휴대형 컴퓨터에 의한 정보 처리 방법, 및 휴대 단말기용 프로그램이 기록된 기록 매체 | |
| JP6062441B2 (ja) | 貨幣端末、貨幣端末の制御方法及びプログラム | |
| US20150262162A1 (en) | Mobile terminal, method for controlling mobile terminal, program product, and recording medium | |
| US10262361B2 (en) | Electronic money server, electronic money processing method, electronic money processing program product, and storage medium on which electronic money processing program product is stored | |
| JP5084306B2 (ja) | 決済システム、決済方法、決済処理サーバ並びにその制御方法及びプログラム | |
| JP5076093B2 (ja) | 情報処理装置、及び情報処理方法 | |
| JP2008139953A (ja) | 金額変更情報送信装置、及び金額変更情報送信方法 | |
| KR101503132B1 (ko) | 프로젝트 파이낸싱 대출 서비스 제공 방법 및 이를 실행하는 서버 | |
| KR100914662B1 (ko) | 의약품 구매에 대응하는 캐쉬백 제공 방법과 이를 위한 기록매체 | |
| KR100916967B1 (ko) | 의약품 구매 대출 처리 시스템 | |
| US11769133B2 (en) | Methods, systems and computer program products for prepayment towards goods or services at point-of-sale terminals | |
| JP2008181300A (ja) | 情報処理装置、貨幣端末、及び情報処理方法 | |
| KR100885167B1 (ko) | 총액한도 대출 자료 처리 방법 및 시스템과 이를 위한프로그램 기록매체 | |
| KR20140112842A (ko) | 프로젝트 파이낸싱 대출 서비스 제공 방법 및 이를 실행하는 서버 | |
| KR20090060241A (ko) | 의약품 구매 대출 처리 방법 | |
| KR20080022853A (ko) | 외환송금 처리 단말장치 | |
| KR20090060240A (ko) | 구매자금 대출 결제 처리방법 | |
| KR20090000798A (ko) | 체인점 물품 대금 결제 방법 및 시스템과 이를 위한기록매체 | |
| KR20080033025A (ko) | 의료비 입금계좌 관리 시스템과 이를 위한 기록매체 | |
| KR20090017681A (ko) | 의약품 구매에 대응하는 캐쉬백 제공 시스템 | |
| KR20090000801A (ko) | 구매자금 대출 결제 처리 단말장치와 이를 위한 프로그램기록매체 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160819 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170630 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170714 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170912 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180214 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20180413 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180614 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20181115 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20181126 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20181213 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6455863 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |