JPWO2014033939A1 - 携帯端末、携帯端末の制御方法、プログラム及び記録媒体 - Google Patents
携帯端末、携帯端末の制御方法、プログラム及び記録媒体 Download PDFInfo
- Publication number
- JPWO2014033939A1 JPWO2014033939A1 JP2014532703A JP2014532703A JPWO2014033939A1 JP WO2014033939 A1 JPWO2014033939 A1 JP WO2014033939A1 JP 2014532703 A JP2014532703 A JP 2014532703A JP 2014532703 A JP2014532703 A JP 2014532703A JP WO2014033939 A1 JPWO2014033939 A1 JP WO2014033939A1
- Authority
- JP
- Japan
- Prior art keywords
- balance
- chip
- electronic money
- stored
- instruction
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3226—Use of secure elements separate from M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
Abstract
所定の条件が整ってからチャージが完了するまでの時間を短縮する。携帯端末５から電子マネーサーバ２に直接チャージの要求を受けて電子マネーサーバ２は、原資を確保したうえで、チャージのためのコマンド群を生成して、生成したコマンド群をＩＣチップに記憶させる保存命令を携帯端末５に送信する。携帯端末５は、直ちに当該コマンド群を実行せず、一旦汎用ＩＣチップ２５に保存する。これで、チャージの準備段階が完了する。その後、一定の要件のもと（例えば、ユーザの操作）で、汎用ＩＣチップ２５の側で、保存していたコマンド群を実行する。こうしてチャージが行われ、バリュー残高が更新される。
Description
本発明は、携帯端末、携帯端末の制御方法、プログラム及び記録媒体に関し、例えば、電子マネーを用いて携帯端末にチャージをするものに関する。
近年、電子マネーの利用が広く普及してきている。電子マネーでは、バリューと呼ばれる金額情報を貨幣価値に対応させ、バリュー残高を増減することにより資金決済を行う。
図１５は、従来の電子マネーシステムを説明するための図である。
電子マネーカード９０は、ユーザが所持しているＩＣカードであり、内蔵するＩＣチップにバリューの残高、ＩＣチップを特定するＩＣチップＩＤ、電子マネー番号などが記録されている。また、当該ＩＣチップを内蔵した携帯電話などの携帯端末５も存在する。
このようにユーザ側のＩＣチップでバリューを保持する方式はストアードバリュー型と呼ばれている。
図１５は、従来の電子マネーシステムを説明するための図である。
電子マネーカード９０は、ユーザが所持しているＩＣカードであり、内蔵するＩＣチップにバリューの残高、ＩＣチップを特定するＩＣチップＩＤ、電子マネー番号などが記録されている。また、当該ＩＣチップを内蔵した携帯電話などの携帯端末５も存在する。
このようにユーザ側のＩＣチップでバリューを保持する方式はストアードバリュー型と呼ばれている。
非同期決済端末７は、店舗や自動販売機などに設置されており、電子マネーカード９０や携帯端末５のＩＣチップと近距離の無線通信を行い、ＩＣチップに記憶されたバリュー残高を減額することによりバリューによる決済を実行する。
非同期決済端末７は、電子マネーサーバ２に接続せずに、決済処理をユーザのＩＣチップとの間でローカルに完結し、取引履歴をログデータとして記録しておく。
そして、非同期決済端末７は、後ほど、定期、又は不定期にログデータを一括して電子マネーサーバ２に送信する。
非同期決済端末７が「非同期」と呼ばれる所以は、電子マネーサーバ２に同期せずにローカルに決済処理を完結させる点にある。
このような、ストアードバリュー型電子マネーのシステムでは、予めＩＣチップにバリュー残高を記憶しており、決済時にこれを減額するため、バリューが不足していると、決済が行えないこととなる。そのため、ＩＣチップが記憶するバリューの残高を増額するチャージと呼ばれる処理が必要となる。通常は、店頭で貨幣と交換でこのチャージが行われ、バリューの交換価値が担保されている。
非同期決済端末７は、電子マネーサーバ２に接続せずに、決済処理をユーザのＩＣチップとの間でローカルに完結し、取引履歴をログデータとして記録しておく。
そして、非同期決済端末７は、後ほど、定期、又は不定期にログデータを一括して電子マネーサーバ２に送信する。
非同期決済端末７が「非同期」と呼ばれる所以は、電子マネーサーバ２に同期せずにローカルに決済処理を完結させる点にある。
このような、ストアードバリュー型電子マネーのシステムでは、予めＩＣチップにバリュー残高を記憶しており、決済時にこれを減額するため、バリューが不足していると、決済が行えないこととなる。そのため、ＩＣチップが記憶するバリューの残高を増額するチャージと呼ばれる処理が必要となる。通常は、店頭で貨幣と交換でこのチャージが行われ、バリューの交換価値が担保されている。
特許文献１では、携帯端末から電子マネーサーバにアクセスすることで、貨幣のやり取りを介さずに携帯端末側のＩＣチップに直接チャージする技術が開示されている。
図１６を参照して、この処理手順を説明する。
まず、携帯電話をインターネット接続モードとし、電子マネーサーバのサービスサイトにアクセスする（ステップ４０５）。これに対して電子マネーサーバは、メインメニュー画面を表示するための画面データを携帯電話に送信する（ステップ４５０）。
携帯電話はこれを受信し、ディスプレイにメインメニュー画面を表示する。ここでは、モバイルチャージを選択するものとし、携帯電話は、モバイルチャージを選択した旨の情報を電子マネーサーバに送信する（ステップ４１０）。電子マネーサーバは、これを受けて、携帯電話にパスワード入力画面を表示するための画面データを送信する（ステップ４５５）。携帯電話は、この画面データを受信してディスプレイにパスワード入力画面を表示する。ユーザは、この画面に対してパスワードを入力し、電子マネーサーバに送信する（ステップ４１５）。電子マネーサーバは、このパスワードを認証した後、金額入力画面を表示するための画面データを携帯電話に送信する（ステップ４６０）。
図１６を参照して、この処理手順を説明する。
まず、携帯電話をインターネット接続モードとし、電子マネーサーバのサービスサイトにアクセスする（ステップ４０５）。これに対して電子マネーサーバは、メインメニュー画面を表示するための画面データを携帯電話に送信する（ステップ４５０）。
携帯電話はこれを受信し、ディスプレイにメインメニュー画面を表示する。ここでは、モバイルチャージを選択するものとし、携帯電話は、モバイルチャージを選択した旨の情報を電子マネーサーバに送信する（ステップ４１０）。電子マネーサーバは、これを受けて、携帯電話にパスワード入力画面を表示するための画面データを送信する（ステップ４５５）。携帯電話は、この画面データを受信してディスプレイにパスワード入力画面を表示する。ユーザは、この画面に対してパスワードを入力し、電子マネーサーバに送信する（ステップ４１５）。電子マネーサーバは、このパスワードを認証した後、金額入力画面を表示するための画面データを携帯電話に送信する（ステップ４６０）。
携帯電話は、この画面データを受信してディスプレイに金額入力画面を表示する。ユーザは、この画面にチャージする金額を入力して電子マネーサーバに送信する（ステップ４２０）。電子マネーサーバは、このユーザに対してバリューを発行するための許可を認証機関サーバに要求し（ステップ４６５）、認証機関サーバは審査結果を電子マネーサーバに送信する（ステップ４９０）。
許可が発行されなかった場合は（ステップ４７０；Ｎ）、電子マネーサーバは、不許可メッセージを携帯電話に送信して（ステップ４７３）、ステップ４５０に戻る。一方、許可が発行された場合（ステップ４７０；Ｙ）、電子マネーサーバは、携帯電話と通信してバリューの書き込み処理を行う（ステップ４７５、ステップ４２５）。携帯電話では、バリューの書き込みが終了するとユーザがこれを確認し、確認した旨の信号を電子マネーサーバに送信する（ステップ４３０）。電子マネーサーバは、これを受け、モバイルチャージが終了した旨を示す結果表示画面を表示するための画面データを携帯電話に送信し（ステップ４８０）、処理を終了する。
携帯電話では、これを用いてディスプレイに結果表示画面を表示して処理を終了する（ステップ４３５）。
許可が発行されなかった場合は（ステップ４７０；Ｎ）、電子マネーサーバは、不許可メッセージを携帯電話に送信して（ステップ４７３）、ステップ４５０に戻る。一方、許可が発行された場合（ステップ４７０；Ｙ）、電子マネーサーバは、携帯電話と通信してバリューの書き込み処理を行う（ステップ４７５、ステップ４２５）。携帯電話では、バリューの書き込みが終了するとユーザがこれを確認し、確認した旨の信号を電子マネーサーバに送信する（ステップ４３０）。電子マネーサーバは、これを受け、モバイルチャージが終了した旨を示す結果表示画面を表示するための画面データを携帯電話に送信し（ステップ４８０）、処理を終了する。
携帯電話では、これを用いてディスプレイに結果表示画面を表示して処理を終了する（ステップ４３５）。
特許文献１に記載の技術では、チャージを行うための処理手順に携帯電話と電子マネーサーバとの間のデータのやり取りが組み込まれている。そのため、ユーザがチャージをしようとしてからチャージが完了するまでに相応の時間がかかる。
本発明が解決しようとする課題は、所定の条件が整ってからチャージが完了するまでの時間を短縮することである。
請求項１に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末であって、前記残高記憶手段に記憶される残高を増額させる残高変更情報をＩＣチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得手段と、前記取得手段により取得される保存命令に従い前記残高変更情報が前記ＩＣチップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送手段と、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示手段と、を具備することを特徴とする携帯端末を提供する。
請求項２に記載の発明では、前記指示手段が、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させるとともに該ＩＣチップ側記憶手段に記憶される残高変更情報を無効化させる実行指示を、所定のタイミングで前記ＩＣチップに出力する、ことを特徴とする請求項１に記載の携帯端末を提供する。
請求項３に記載の発明では、前記転送手段により転送される保存命令に従い前記残高変更情報が前記ＩＣチップ側記憶手段に記憶されない場合に、該残高変更情報を携帯端末側記憶手段に記憶させる保存手段をさらに具備し、前記指示手段が、さらに、前記携帯端末側記憶手段に記憶される残高変更情報を前記ＩＣチップに出力する、ことを特徴とする請求項１又は請求項２に記載の携帯端末を提供する。
請求項４に記載の発明では、前記ＩＣチップを一時的に無効化する無効化手段と、前記無効化手段による前記ＩＣチップの一時的な無効化を解除する解除手段と、をさらに具備し、前記保存手段が、前記ＩＣチップが前記無効化手段により無効化されている場合に、前記取得手段により取得される保存命令において指定される残高変更情報を前記携帯端末側記憶手段に記憶させ、前記指示手段が、前記解除手段により前記ＩＣチップの無効化が解除されたタイミングで前記実行指示を出力する、ことを特徴とする請求項３に記載の携帯端末を提供する。
請求項５に記載の発明では、前記取得手段により取得される残高変更情報を用いた変更処理により変更されるべき金額に対応付けられたオブジェクトを表示画面に表示させる手段をさらに具備し、前記指示手段が、前記実行指示を、前記表示画面に表示されたオブジェクトに対する所定の操作が検出されたタイミングで、前記ＩＣチップに出力する、ことを特徴とする請求項１〜４のいずれか１項に記載の携帯端末を提供する。
請求項６に記載の発明では、前記取得手段により取得される残高変更情報を用いた変更処理により変更されるべき金額を含む通知データを通知領域に表示させる手段をさらに具備し、前記指示手段が、前記実行指示を、前記通知領域に表示された通知データに対する所定の操作が検出されたタイミングで、前記ＩＣチップに出力する、ことを特徴とする請求項１〜４のいずれか１項に記載の携帯端末を提供する。
請求項７に記載の発明では、前記ＩＣチップが、前記残高変更手段による変更処理の実行結果を含むログデータを前記ＩＣチップ側記憶手段に記憶させる手段と、前記ＩＣチップ側記憶手段に記憶されるログデータを前記情報処理サーバに送信する手段と、をさらに具備する、ことを特徴とする請求項１〜６のいずれか１項に記載の携帯端末を提供する。
請求項８に記載の発明では、前記残高変更情報が、前記残高記憶手段に記憶される残高に加算されるべき加算金額と、前記残高記憶手段に記憶される残高を取得するコマンドと、前記取得される残高に前記加算金額を加算させた値に前記残高記憶手段に記憶される残高を変更させるコマンドと、を含む、ことを特徴とする請求項１〜７のいずれか１項に記載の携帯端末を提供する。
請求項９に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末の制御方法であって、前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得ステップと、前記取得ステップにおいて取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送ステップと、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示ステップと、を具備することを特徴とする携帯端末の制御方法を提供する。
請求項１０に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末に、前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得機能と、前記取得機能により取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送機能と、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示機能と、を実現させるためのプログラムを提供する。
請求項１１に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末に、前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得機能と、前記取得機能により取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送機能と、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示機能と、を実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体を提供する。
請求項２に記載の発明では、前記指示手段が、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させるとともに該ＩＣチップ側記憶手段に記憶される残高変更情報を無効化させる実行指示を、所定のタイミングで前記ＩＣチップに出力する、ことを特徴とする請求項１に記載の携帯端末を提供する。
請求項３に記載の発明では、前記転送手段により転送される保存命令に従い前記残高変更情報が前記ＩＣチップ側記憶手段に記憶されない場合に、該残高変更情報を携帯端末側記憶手段に記憶させる保存手段をさらに具備し、前記指示手段が、さらに、前記携帯端末側記憶手段に記憶される残高変更情報を前記ＩＣチップに出力する、ことを特徴とする請求項１又は請求項２に記載の携帯端末を提供する。
請求項４に記載の発明では、前記ＩＣチップを一時的に無効化する無効化手段と、前記無効化手段による前記ＩＣチップの一時的な無効化を解除する解除手段と、をさらに具備し、前記保存手段が、前記ＩＣチップが前記無効化手段により無効化されている場合に、前記取得手段により取得される保存命令において指定される残高変更情報を前記携帯端末側記憶手段に記憶させ、前記指示手段が、前記解除手段により前記ＩＣチップの無効化が解除されたタイミングで前記実行指示を出力する、ことを特徴とする請求項３に記載の携帯端末を提供する。
請求項５に記載の発明では、前記取得手段により取得される残高変更情報を用いた変更処理により変更されるべき金額に対応付けられたオブジェクトを表示画面に表示させる手段をさらに具備し、前記指示手段が、前記実行指示を、前記表示画面に表示されたオブジェクトに対する所定の操作が検出されたタイミングで、前記ＩＣチップに出力する、ことを特徴とする請求項１〜４のいずれか１項に記載の携帯端末を提供する。
請求項６に記載の発明では、前記取得手段により取得される残高変更情報を用いた変更処理により変更されるべき金額を含む通知データを通知領域に表示させる手段をさらに具備し、前記指示手段が、前記実行指示を、前記通知領域に表示された通知データに対する所定の操作が検出されたタイミングで、前記ＩＣチップに出力する、ことを特徴とする請求項１〜４のいずれか１項に記載の携帯端末を提供する。
請求項７に記載の発明では、前記ＩＣチップが、前記残高変更手段による変更処理の実行結果を含むログデータを前記ＩＣチップ側記憶手段に記憶させる手段と、前記ＩＣチップ側記憶手段に記憶されるログデータを前記情報処理サーバに送信する手段と、をさらに具備する、ことを特徴とする請求項１〜６のいずれか１項に記載の携帯端末を提供する。
請求項８に記載の発明では、前記残高変更情報が、前記残高記憶手段に記憶される残高に加算されるべき加算金額と、前記残高記憶手段に記憶される残高を取得するコマンドと、前記取得される残高に前記加算金額を加算させた値に前記残高記憶手段に記憶される残高を変更させるコマンドと、を含む、ことを特徴とする請求項１〜７のいずれか１項に記載の携帯端末を提供する。
請求項９に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末の制御方法であって、前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得ステップと、前記取得ステップにおいて取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送ステップと、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示ステップと、を具備することを特徴とする携帯端末の制御方法を提供する。
請求項１０に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末に、前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得機能と、前記取得機能により取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送機能と、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示機能と、を実現させるためのプログラムを提供する。
請求項１１に記載の発明では、電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末に、前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得機能と、前記取得機能により取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送機能と、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示機能と、を実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体を提供する。
本発明の携帯端末は、予めチャージ実行直前の、チャージ可能な状態を作出し、所定の条件が整った時点で情報処理サーバにアクセスすることなくチャージを完結させる。
よって、本発明によれば、所定の条件が整ってからチャージが完了するまでの時間が短縮される。
よって、本発明によれば、所定の条件が整ってからチャージが完了するまでの時間が短縮される。
（１）実施形態の概要
携帯端末５(図１)から電子マネーサーバ２に直接チャージの要求をする。これを受けて電子マネーサーバ２は、例えば、クレジット会社サーバ３００などにアクセスして、原資を確保したうえで、チャージのためのコマンド群を生成する。そして、電子マネーサーバ２は、生成したコマンド群をＩＣチップに記憶させる保存命令を携帯端末５に送信する。保存命令を受信した携帯端末５は、受信した保存命令において指定されるコマンド群を汎用ＩＣチップ２５に保存する。これで、チャージの準備段階が完了する。
その後、一定の要件のもと（例えば、ユーザの操作（手動）又は自動）で、汎用ＩＣチップ２５の側で、保存していたコマンド群を実行する。
こうしてチャージが行われ、バリュー残高が更新される。
このように、チャージの準備段階を予め行っておくことで、所定の条件が整った時点で、直ちにチャージを実行することができる。
携帯端末５(図１)から電子マネーサーバ２に直接チャージの要求をする。これを受けて電子マネーサーバ２は、例えば、クレジット会社サーバ３００などにアクセスして、原資を確保したうえで、チャージのためのコマンド群を生成する。そして、電子マネーサーバ２は、生成したコマンド群をＩＣチップに記憶させる保存命令を携帯端末５に送信する。保存命令を受信した携帯端末５は、受信した保存命令において指定されるコマンド群を汎用ＩＣチップ２５に保存する。これで、チャージの準備段階が完了する。
その後、一定の要件のもと（例えば、ユーザの操作（手動）又は自動）で、汎用ＩＣチップ２５の側で、保存していたコマンド群を実行する。
こうしてチャージが行われ、バリュー残高が更新される。
このように、チャージの準備段階を予め行っておくことで、所定の条件が整った時点で、直ちにチャージを実行することができる。
第１の実施形態では、チャージを行う際、上限値を超える場合、とりあえずチャージの準備段階を行っておき、チャージを行っても上限値を超えないこととなった場合に、直ちにチャージを実行することができる。
第２の実施形態では、チャージの準備段階を自動で行い（オートチャージと同様の処理）、最終的なチャージの実行のみをユーザの意思（操作）としている。そのため、オートチャージによる利便性を確保すると同時に、ユーザが関知しないでチャージが行われてしまうことのリスクを回避することができる。
第３の実施形態では、チャージの準備段階を自動で行い、且つ汎用ＩＣチップ２５のロックの解除を検知すると自動的に準備しておいたチャージを実行する。そのため、決済のために、汎用ＩＣチップ２５のロックを解除したら、直ちにチャージが完了するので、決済時にバリュー残高が不足していて、決済不能となることを防止できる。
第２の実施形態では、チャージの準備段階を自動で行い（オートチャージと同様の処理）、最終的なチャージの実行のみをユーザの意思（操作）としている。そのため、オートチャージによる利便性を確保すると同時に、ユーザが関知しないでチャージが行われてしまうことのリスクを回避することができる。
第３の実施形態では、チャージの準備段階を自動で行い、且つ汎用ＩＣチップ２５のロックの解除を検知すると自動的に準備しておいたチャージを実行する。そのため、決済のために、汎用ＩＣチップ２５のロックを解除したら、直ちにチャージが完了するので、決済時にバリュー残高が不足していて、決済不能となることを防止できる。
（２）実施形態の詳細
図１は、第１の実施形態に係る電子マネーシステム１のネットワーク構成を説明するための図である。
電子マネーシステム１は、電子マネーサーバ２、インターネット３、携帯端末５、決済端末６、非同期決済端末７、通信回線８、クレジット会社サーバ３００などを用いて構成されている。
図１は、第１の実施形態に係る電子マネーシステム１のネットワーク構成を説明するための図である。
電子マネーシステム１は、電子マネーサーバ２、インターネット３、携帯端末５、決済端末６、非同期決済端末７、通信回線８、クレジット会社サーバ３００などを用いて構成されている。
電子マネーサーバ２は、バリューによる貨幣価値の移動を管理するサーバである。ここで、バリューとは、貨幣価値に対応させた電子情報であり、電子マネーシステム１は、バリューの残高（以下、バリュー残高）を増減することにより貨幣価値を移動させる。
そして、電子マネーシステム１の事業体は、バリューの移動に対応させて実際の貨幣を移動させることによりバリューと実際の貨幣の移動を対応させる。
そして、電子マネーシステム１の事業体は、バリューの移動に対応させて実際の貨幣を移動させることによりバリューと実際の貨幣の移動を対応させる。
電子マネーサーバ２は、管理のため、携帯端末５に対応づけてバリュー残高の管理値を記憶している。後述するように携帯端末５は、携帯端末５の内部にバリュー残高を記憶している。
両者は、常に同期を取って、同一の値であることが望ましい。しかし、現実には電子マネーサーバ２とリアルタイムで接続できない、非同期決済端末７も多数存在する。そのため、生成したログデータを後にバッチ処理で電子マネーサーバ２に送り、事後的に同期を取るようにしている。
両者は、常に同期を取って、同一の値であることが望ましい。しかし、現実には電子マネーサーバ２とリアルタイムで接続できない、非同期決済端末７も多数存在する。そのため、生成したログデータを後にバッチ処理で電子マネーサーバ２に送り、事後的に同期を取るようにしている。
携帯端末５は、例えば、スマートフォン、携帯電話、ゲーム機、タブレット型コンピュータなどで構成された携帯端末であって、スマートフォン、携帯電話の場合は、携帯電話網を経由して、ゲーム機、タブレット型コンピュータの場合は、例えば無線ＬＡＮ（ローカル・エリア・ネットワーク）を経由して、インターネット３を介して電子マネーサーバ２に接続する機能と、決済端末６や非同期決済端末７と近距離無線通信により接続する機能とを備えている。
携帯端末５は、汎用ＩＣチップ２５を内蔵しており、これに電子マネー番号とバリュー残高を記憶している。
決済端末６は、携帯端末５と近距離無線通信を行うと共に通信回線８を介して電子マネーサーバ２とも通信し、電子マネーサーバ２に決済金額などの情報を送信したり、電子マネーサーバ２と携帯端末５の通信を中継したりする。決済端末６は、携帯端末５を用いた決済時にリアルタイムで電子マネーサーバ２とオンライン通信する同期決済端末である。
決済端末６は、コンビニエンスストアなどのリアル店舗(不動産店舗などで物理的に営業している実店舗)の会計カウンタや自動販売機などに設置されている。
通信回線８は、電子マネーサーバ２と決済端末６を接続する回線である。通信回線８として専用回線を用いることもできるし、インターネット３などの汎用の回線を用いてもよい。
携帯端末５は、汎用ＩＣチップ２５を内蔵しており、これに電子マネー番号とバリュー残高を記憶している。
決済端末６は、携帯端末５と近距離無線通信を行うと共に通信回線８を介して電子マネーサーバ２とも通信し、電子マネーサーバ２に決済金額などの情報を送信したり、電子マネーサーバ２と携帯端末５の通信を中継したりする。決済端末６は、携帯端末５を用いた決済時にリアルタイムで電子マネーサーバ２とオンライン通信する同期決済端末である。
決済端末６は、コンビニエンスストアなどのリアル店舗(不動産店舗などで物理的に営業している実店舗)の会計カウンタや自動販売機などに設置されている。
通信回線８は、電子マネーサーバ２と決済端末６を接続する回線である。通信回線８として専用回線を用いることもできるし、インターネット３などの汎用の回線を用いてもよい。
非同期決済端末７は、例えば、ネットワーク設備の不便な店舗や自動販売機などに設置されており、携帯端末５と近距離無線通信する機能を備えている。
非同期決済端末７は、携帯端末５と近距離無線通信を行って、バリュー残高により決済を行う。非同期決済端末７は、通常は電子マネーサーバ２と接続しておらず(そのため、サーバ管理型電子マネーの決済ができない)、携帯端末５との決済内容をとりあえずログデータとして記憶しておく。
そして、非同期決済端末７は、１日に一回程度、通信回線８を用いて電子マネーサーバ２に接続し、電子マネーサーバ２にログデータを送信する。ネットワーク通信設備がない環境では、ログデータを記録した記録媒体を担当者が手動で収集する場合もある。
電子マネーサーバ２は、バリュー残高に関しては決済端末６や非同期決済端末７でのログデータによって資金移動を管理する。
クレジット会社サーバ３００は、クレジット会社がクレジットカードによる支払を管理するためのサーバである。このクレジット会社サーバ３００は、電子マネーサーバ２が汎用ＩＣチップ２５にチャージする際に、その代金をユーザのクレジット番号にて決済する。
非同期決済端末７は、携帯端末５と近距離無線通信を行って、バリュー残高により決済を行う。非同期決済端末７は、通常は電子マネーサーバ２と接続しておらず(そのため、サーバ管理型電子マネーの決済ができない)、携帯端末５との決済内容をとりあえずログデータとして記憶しておく。
そして、非同期決済端末７は、１日に一回程度、通信回線８を用いて電子マネーサーバ２に接続し、電子マネーサーバ２にログデータを送信する。ネットワーク通信設備がない環境では、ログデータを記録した記録媒体を担当者が手動で収集する場合もある。
電子マネーサーバ２は、バリュー残高に関しては決済端末６や非同期決済端末７でのログデータによって資金移動を管理する。
クレジット会社サーバ３００は、クレジット会社がクレジットカードによる支払を管理するためのサーバである。このクレジット会社サーバ３００は、電子マネーサーバ２が汎用ＩＣチップ２５にチャージする際に、その代金をユーザのクレジット番号にて決済する。
図２は、携帯端末５のハードウェア的な構成を示した図である。ここでは、一例として携帯端末５をスマートフォンであるとするが、携帯電話も同様である。
携帯端末５は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、入力部１４、出力部１５、通信制御部１６、近距離通信制御部１７、記憶部１８、汎用ＩＣチップ２５などがバスライン１９によって接続している。
携帯端末５は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、入力部１４、出力部１５、通信制御部１６、近距離通信制御部１７、記憶部１８、汎用ＩＣチップ２５などがバスライン１９によって接続している。
ＣＰＵ１１は、ＲＯＭ１２や記憶部１８に記録したプログラムを実行して各種の情報処理や携帯端末５全体の制御を行う。本実施形態では、例えば、後述の電子マネーアプリケーションプログラムの提供する機能により電子マネーサーバ２と協働してバリュー残高による決済処理を支援する。
ＲＯＭ１２は、読み取り専用のメモリであって、携帯端末５が動作するための基本的なプログラム、パラメータ、データなどが記録されている。
ＲＡＭ１３は、読み書きが可能なメモリであって、ＣＰＵ１１が情報処理を行う際のワーキングメモリを提供する。
ＲＯＭ１２は、読み取り専用のメモリであって、携帯端末５が動作するための基本的なプログラム、パラメータ、データなどが記録されている。
ＲＡＭ１３は、読み書きが可能なメモリであって、ＣＰＵ１１が情報処理を行う際のワーキングメモリを提供する。
出力部１５は、ユーザに対して情報を出力する機能部であって、例えば、画面表示用の液晶ディスプレイ、音声を出力するスピーカなどを備えている。液晶ディスプレイには、例えば、電子マネーアプリケーションプログラムを起動するためのアイコンなどが表示される。
入力部１４は、外部からの情報を入力する機能部であって、例えば、液晶ディスプレイ上に設置されたタッチパネル、音声を入力するマイクロフォン、被写体を撮影するカメラなどを備えている。ユーザは、液晶ディスプレイ上の表示に対応してタッチパネルにタッチすることにより情報を入力することができる。
入力部１４は、外部からの情報を入力する機能部であって、例えば、液晶ディスプレイ上に設置されたタッチパネル、音声を入力するマイクロフォン、被写体を撮影するカメラなどを備えている。ユーザは、液晶ディスプレイ上の表示に対応してタッチパネルにタッチすることにより情報を入力することができる。
記憶部１８は、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）やハードディスクなどの記録媒体を用いて構成されており、携帯端末５を制御する基本的なプログラムであるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やバリューによる決済を支援する電子マネーアプリケーションプログラム、その他のプログラムやデータを記録している。
通信制御部１６は、携帯電話網の基地局アンテナと無線通信するためのアンテナを備えており、携帯端末５をインターネット３や電話回線に接続する。携帯端末５は、通信制御部１６を介してインターネット３経由で電子マネーサーバ２と通信することができる。
なお、ゲーム機、タブレット型コンピュータは、通常携帯電話網の基地局アンテナを無線通信する機能を備えてなく、無線ＬＡＮのアクセスポイントと無線通信する機能のみを備えている場合が多い。
また、スマートフォンも無線ＬＡＮのアクセスポイントと無線通信するための機能を備えている。
近距離通信制御部１７は、決済端末６や非同期決済端末７のリーダライタと近距離無線通信するためのアンテナを備えており、汎用ＩＣチップ２５を決済端末６や非同期決済端末７に接続する。汎用ＩＣチップ２５は、近距離通信制御部１７を介して決済端末６と通信する他、携帯端末５を経由して電子マネーサーバ２と通信することができる。
通信制御部１６は、携帯電話網の基地局アンテナと無線通信するためのアンテナを備えており、携帯端末５をインターネット３や電話回線に接続する。携帯端末５は、通信制御部１６を介してインターネット３経由で電子マネーサーバ２と通信することができる。
なお、ゲーム機、タブレット型コンピュータは、通常携帯電話網の基地局アンテナを無線通信する機能を備えてなく、無線ＬＡＮのアクセスポイントと無線通信する機能のみを備えている場合が多い。
また、スマートフォンも無線ＬＡＮのアクセスポイントと無線通信するための機能を備えている。
近距離通信制御部１７は、決済端末６や非同期決済端末７のリーダライタと近距離無線通信するためのアンテナを備えており、汎用ＩＣチップ２５を決済端末６や非同期決済端末７に接続する。汎用ＩＣチップ２５は、近距離通信制御部１７を介して決済端末６と通信する他、携帯端末５を経由して電子マネーサーバ２と通信することができる。
汎用ＩＣチップ２５は、汎用のアプリケーションを記憶したＩＣチップであり、携帯端末５に内蔵されている。汎用ＩＣチップ２５には、ユーザがアプリケーションをダウンロードして記憶することができる。
汎用ＩＣチップ２５は、ＣＰＵ、ＲＡＭ、ＲＯＭなどによって構成され、各種プログラムに従って情報処理を行う情報処理部２６と不揮発性のメモリで構成された記憶部２７を備えている。
記憶部２７には、電子マネー番号とバリュー残高、図示しないが、情報処理部２６によってバリュー残高を操作するためのバリュー操作プログラム、及び電子マネーサーバ２が汎用ＩＣチップ２５を認証する認証データなどが記憶されている。
電子マネー番号は、電子マネーサーバ２が、当該携帯端末５（汎用ＩＣチップ２５）が、何れのユーザのものであるかを識別するための番号である。
汎用ＩＣチップ２５は、ＣＰＵ、ＲＡＭ、ＲＯＭなどによって構成され、各種プログラムに従って情報処理を行う情報処理部２６と不揮発性のメモリで構成された記憶部２７を備えている。
記憶部２７には、電子マネー番号とバリュー残高、図示しないが、情報処理部２６によってバリュー残高を操作するためのバリュー操作プログラム、及び電子マネーサーバ２が汎用ＩＣチップ２５を認証する認証データなどが記憶されている。
電子マネー番号は、電子マネーサーバ２が、当該携帯端末５（汎用ＩＣチップ２５）が、何れのユーザのものであるかを識別するための番号である。
汎用ＩＣチップ２５におけるバリュー残高に関する減額処理、及び増額処理は外部からの命令により汎用ＩＣチップ２５内の情報処理部２６に形成されたバリュー操作プログラムが行う。これは、バリュー残高の処理を汎用ＩＣチップ２５内に限定することによりセキュリティを高めるためである。
なお、バリュー残高の処理に関しては、汎用ＩＣチップ２５に入力される情報は暗号化されており、汎用ＩＣチップ２５の内部で復号化され、汎用ＩＣチップ２５から出力される情報は、これらチップ内で暗号化してから出力される。
図３は、携帯端末５の機能を説明するための図である。
電子マネーアプリケーションプログラムを実行すると携帯端末５に電子マネーアプリケーション２９が形成される。
決済端末６を備えたリアル店舗での決済の場合は、近距離通信制御部１７は、決済端末６と通信すると共に決済端末６を介して電子マネーサーバ２と通信する。
非同期決済端末７を備えたリアル店舗での決済の場合は、近距離通信制御部１７は、非同期決済端末７と通信する。
また、電子マネーアプリケーション２９は、汎用ＩＣチップ２５にアクセスすることができる。
電子マネーアプリケーションプログラムを実行すると携帯端末５に電子マネーアプリケーション２９が形成される。
決済端末６を備えたリアル店舗での決済の場合は、近距離通信制御部１７は、決済端末６と通信すると共に決済端末６を介して電子マネーサーバ２と通信する。
非同期決済端末７を備えたリアル店舗での決済の場合は、近距離通信制御部１７は、非同期決済端末７と通信する。
また、電子マネーアプリケーション２９は、汎用ＩＣチップ２５にアクセスすることができる。
リアル店舗での決済の場合、近距離通信制御部１７は、汎用ＩＣチップ２５でバリュー操作プログラムを動作させて、バリュー残高を増減させたり、電子マネー番号を読み出したりすることができる。
そして、決済処理を行う際、汎用ＩＣチップ２５は、近距離通信制御部１７を介して、非同期決済端末７からバリュー残高を更新（減額）するようにとの要求を受けて、バリュー残高を更新（減額）する。
そして、決済処理を行う際、汎用ＩＣチップ２５は、近距離通信制御部１７を介して、非同期決済端末７からバリュー残高を更新（減額）するようにとの要求を受けて、バリュー残高を更新（減額）する。
ここで行うバリュー残高更新処理には、次のような方式が考えられる。
（方式１）バリュー残高更新要求として上書き命令を送信する場合。
この場合、非同期決済端末７は、携帯端末５の汎用ＩＣチップ２５のＣＰＵから受信したバリュー残高に対して決済金額による減算を行い、減算後の残高を算出する。そして、非同期決済端末７は、バリュー残高更新要求として、当該算出後の残高に上書きする上書き命令を送信する。携帯端末５の汎用ＩＣチップ２５のＣＰＵは、当該上書き命令に従ってバリュー残高を上書きして更新する。
その後、汎用ＩＣチップ２５は、バリュー残高を更新した旨を非同期決済端末７に通知する。
（方式１）バリュー残高更新要求として上書き命令を送信する場合。
この場合、非同期決済端末７は、携帯端末５の汎用ＩＣチップ２５のＣＰＵから受信したバリュー残高に対して決済金額による減算を行い、減算後の残高を算出する。そして、非同期決済端末７は、バリュー残高更新要求として、当該算出後の残高に上書きする上書き命令を送信する。携帯端末５の汎用ＩＣチップ２５のＣＰＵは、当該上書き命令に従ってバリュー残高を上書きして更新する。
その後、汎用ＩＣチップ２５は、バリュー残高を更新した旨を非同期決済端末７に通知する。
（方式２）バリュー残高更新要求として減算命令を送信する場合。
この場合、非同期決済端末７は、決済金額分だけバリュー残高を減算する減算命令をバリュー残高更新要求として携帯端末５の汎用ＩＣチップ２５のＣＰＵに送信する。携帯端末５の汎用ＩＣチップ２５のＣＰＵは、当該命令に従ってバリュー残高から決済金額を減算してバリュー残高を更新する。
その後、汎用ＩＣチップ２５は、バリュー残高を更新した旨を非同期決済端末７に通知する。
この場合、非同期決済端末７は、決済金額分だけバリュー残高を減算する減算命令をバリュー残高更新要求として携帯端末５の汎用ＩＣチップ２５のＣＰＵに送信する。携帯端末５の汎用ＩＣチップ２５のＣＰＵは、当該命令に従ってバリュー残高から決済金額を減算してバリュー残高を更新する。
その後、汎用ＩＣチップ２５は、バリュー残高を更新した旨を非同期決済端末７に通知する。
一方、リアル店舗でチャージ処理を行う際、汎用ＩＣチップ２５は、近距離通信制御部１７を介して非同期決済端末７からバリュー残高を更新（増額）するようにとの要求を受けて、バリュー残高を更新（増額）する。
その後、汎用ＩＣチップ２５は、バリュー残高を更新した旨を非同期決済端末７に通知する。
なお、このチャージを行うのは、前提として、チャージを行うバリューに相当する貨幣を非同期決済端末７を設置する店舗の店員が受け取っている場合である。
その後、汎用ＩＣチップ２５は、バリュー残高を更新した旨を非同期決済端末７に通知する。
なお、このチャージを行うのは、前提として、チャージを行うバリューに相当する貨幣を非同期決済端末７を設置する店舗の店員が受け取っている場合である。
このチャージには、非同期決済端末７を介さずに、直接電子マネーサーバ２からチャージを行うこともできる。この場合、携帯端末５の通信制御部１６を介して電子マネーサーバ２にアクセスし、ユーザの認証処理、クレジット会社サーバ３００などの認証機関サーバの許可などの手順を経る。そして、電子マネーサーバ２から、金額変更（増額）情報を携帯端末５が受信し、汎用ＩＣチップ２５は、バリュー残高を更新（増額）する。
この電子マネーサーバ２からのチャージは一連の処理として行われる。
この電子マネーサーバ２からのチャージを一定の要件（例えば、バリュー残高が所定値以下となった場合）に自動的に行うよう設定することをオートチャージと呼ぶ。
この電子マネーサーバ２からのチャージは一連の処理として行われる。
この電子マネーサーバ２からのチャージを一定の要件（例えば、バリュー残高が所定値以下となった場合）に自動的に行うよう設定することをオートチャージと呼ぶ。
図４は、電子マネーサーバ２の構成を説明するための図である。
電子マネーサーバ２は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信制御部３４、記憶部３５などがバスライン３６によって接続している。
ＣＰＵ３１は、ＲＯＭ３２や記憶部３５に記録したプログラムを実行して各種の情報処理や電子マネーサーバ２全体の制御を行う。本実施形態では、携帯端末５からチャージの要求を受けてチャージの実行を行う。
非同期決済端末７での決済では、電子マネーサーバ２は、非同期決済端末７がバリュー残高を更新したログデータを後ほど非同期決済端末７から受信して処理する。
電子マネーサーバ２とオンラインで接続できる決済端末６の場合、通信しながらバリュー残高をリアルタイムで更新することによりバリューによる決済処理を行うことができる。
電子マネーサーバ２は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信制御部３４、記憶部３５などがバスライン３６によって接続している。
ＣＰＵ３１は、ＲＯＭ３２や記憶部３５に記録したプログラムを実行して各種の情報処理や電子マネーサーバ２全体の制御を行う。本実施形態では、携帯端末５からチャージの要求を受けてチャージの実行を行う。
非同期決済端末７での決済では、電子マネーサーバ２は、非同期決済端末７がバリュー残高を更新したログデータを後ほど非同期決済端末７から受信して処理する。
電子マネーサーバ２とオンラインで接続できる決済端末６の場合、通信しながらバリュー残高をリアルタイムで更新することによりバリューによる決済処理を行うことができる。
ＲＯＭ３２は、読み取り専用のメモリであって、電子マネーサーバ２が動作するための基本的なプログラム、パラメータ、データなどが記録されている。
ＲＡＭ３３は、読み書きが可能なメモリであって、ＣＰＵ３１が情報処理を行う際のワーキングメモリを提供する。
通信制御部３４は、電子マネーサーバ２が通信回線８を介して決済端末６、非同期決済端末７、携帯端末５との間で行う通信や、電子マネーサーバ２がインターネット３を介して携帯端末５との間で行うと通信を制御する。
記憶部３５は、例えば、大容量のハードディスクで構成されており、ＣＰＵ３１がバリューによる決済処理を行なったり、チャージを行うための電子マネー管理プログラムやその他のプログラム、ユーザのバリュー残高を管理したり、チャージの履歴を管理するユーザＤＢ（データベース）、加盟店のバリュー決済を管理する加盟店ＤＢ、各決済処理を記録したログデータを格納するログデータＤＢなどを記録している。
なお、この図４の例では、単一の電子マネーサーバ２を説明したが、この電子マネーサーバ２が、機能を分散することにより複数のサーバから構成されるようにしてもよい。
ＲＡＭ３３は、読み書きが可能なメモリであって、ＣＰＵ３１が情報処理を行う際のワーキングメモリを提供する。
通信制御部３４は、電子マネーサーバ２が通信回線８を介して決済端末６、非同期決済端末７、携帯端末５との間で行う通信や、電子マネーサーバ２がインターネット３を介して携帯端末５との間で行うと通信を制御する。
記憶部３５は、例えば、大容量のハードディスクで構成されており、ＣＰＵ３１がバリューによる決済処理を行なったり、チャージを行うための電子マネー管理プログラムやその他のプログラム、ユーザのバリュー残高を管理したり、チャージの履歴を管理するユーザＤＢ（データベース）、加盟店のバリュー決済を管理する加盟店ＤＢ、各決済処理を記録したログデータを格納するログデータＤＢなどを記録している。
なお、この図４の例では、単一の電子マネーサーバ２を説明したが、この電子マネーサーバ２が、機能を分散することにより複数のサーバから構成されるようにしてもよい。
次に、図５の各図を用いて電子マネーサーバ２の有するデータベースについて説明する。
図５（１）は、ユーザＤＢの論理的な構成を説明するための図である。
本実施形態では、ユーザＩＤに対応して、電子マネー番号が記憶されている。図示しないが汎用ＩＣチップ２５の認証データなどの項目も記憶されている。
項目「ユーザＩＤ」は、ユーザの識別情報である。
項目「電子マネー番号」は、バリュー残高を他のユーザのバリュー残高から識別するための口座番号である。
項目「バリュー残高の管理値」は、項目「電子マネー番号」で特定される口座のバリュー残高である。このバリュー残高は、受信したログデータを用いて更新する。
項目「チャージの設定」は、電子マネーサーバ２からのチャージの設定を行っているか否かを登録する項目である。
「氏名」、「住所」、「生年月日」、「電話番号」、「メールアドレス」は、各々ユーザを特定するための情報である。これらの全ての事項が必須登録項目でなく、場合によっては、設けなくてもよい。
図５（１）は、ユーザＤＢの論理的な構成を説明するための図である。
本実施形態では、ユーザＩＤに対応して、電子マネー番号が記憶されている。図示しないが汎用ＩＣチップ２５の認証データなどの項目も記憶されている。
項目「ユーザＩＤ」は、ユーザの識別情報である。
項目「電子マネー番号」は、バリュー残高を他のユーザのバリュー残高から識別するための口座番号である。
項目「バリュー残高の管理値」は、項目「電子マネー番号」で特定される口座のバリュー残高である。このバリュー残高は、受信したログデータを用いて更新する。
項目「チャージの設定」は、電子マネーサーバ２からのチャージの設定を行っているか否かを登録する項目である。
「氏名」、「住所」、「生年月日」、「電話番号」、「メールアドレス」は、各々ユーザを特定するための情報である。これらの全ての事項が必須登録項目でなく、場合によっては、設けなくてもよい。
図５（２）は、チャージ登録ＤＢの論理的な構成を説明するための図である。
チャージ登録ＤＢは、「電子マネー番号」、「オートチャージの設定」、「クレジットカード番号」、「１回のチャージ金額」、「日額限度」、「月額限度」、「チャージを行う日時」、その他の項目から構成されている。
項目「電子マネー番号」は、ユーザＤＢに登録されているユーザを検索するキーとなる。
項目「オートチャージの設定」は、当該ユーザが電子マネーサーバ２からのチャージだけでなく、「オートチャージ」の設定も行っていることを登録する項目である。
「クレジットカード番号」は、チャージ原資の調達先を示す項目である。そのため、場合によっては、「金融機関の口座番号」や「電話料金を請求する電話会社が決定したＩＤ」の場合もある。
複数の決済手段（クレジットカード、預貯金口座など）を用いる場合は、決済手順を記憶することもできる。
銀行口座からの引落の場合、当該ユーザと銀行との間で、電子マネーサーバ２からの請求に対して引落を行う旨の契約がなされることが前提である。
「１回のチャージ金額」、「日額限度」、「月額限度」、「チャージを行う日時」、「基準バリュー残高」は、任意的設定項目である。ユーザから設定の要求があった場合、項目に記録する。
ここで、１回のチャージ金額とは、１回のチャージで携帯端末５の汎用ＩＣチップ２５にチャージする金額である。これを設定しておけば、チャージの都度金額を設定する必要がなくなる。
チャージ登録ＤＢは、「電子マネー番号」、「オートチャージの設定」、「クレジットカード番号」、「１回のチャージ金額」、「日額限度」、「月額限度」、「チャージを行う日時」、その他の項目から構成されている。
項目「電子マネー番号」は、ユーザＤＢに登録されているユーザを検索するキーとなる。
項目「オートチャージの設定」は、当該ユーザが電子マネーサーバ２からのチャージだけでなく、「オートチャージ」の設定も行っていることを登録する項目である。
「クレジットカード番号」は、チャージ原資の調達先を示す項目である。そのため、場合によっては、「金融機関の口座番号」や「電話料金を請求する電話会社が決定したＩＤ」の場合もある。
複数の決済手段（クレジットカード、預貯金口座など）を用いる場合は、決済手順を記憶することもできる。
銀行口座からの引落の場合、当該ユーザと銀行との間で、電子マネーサーバ２からの請求に対して引落を行う旨の契約がなされることが前提である。
「１回のチャージ金額」、「日額限度」、「月額限度」、「チャージを行う日時」、「基準バリュー残高」は、任意的設定項目である。ユーザから設定の要求があった場合、項目に記録する。
ここで、１回のチャージ金額とは、１回のチャージで携帯端末５の汎用ＩＣチップ２５にチャージする金額である。これを設定しておけば、チャージの都度金額を設定する必要がなくなる。
日額限度額は、チャージによる１日当たりのチャージ合計値の上限値である。
月額限度額は、１チャージによる１ヶ月当たりのチャージ合計値の上限値である。また、１日当たりの限度回数、１ヶ月当たりの限度回数を設定するように構成してもよい。
現実にチャージを行う日時とは、チャージ可能な時刻を設定したい場合その日時である。
基準バリュー残高とは、この基準バリュー残高を下回ったら新たなチャージを実行するバリュー残高である。例えば、この基準バリュー残高を下回ったら電子マネーサーバ２から電子メールでチャージの処理を促すようにすることもできる。
また、オートチャージを設定する場合は、この基準バリュー残高を下回ったら自動的にチャージ行うこととなる。
月額限度額は、１チャージによる１ヶ月当たりのチャージ合計値の上限値である。また、１日当たりの限度回数、１ヶ月当たりの限度回数を設定するように構成してもよい。
現実にチャージを行う日時とは、チャージ可能な時刻を設定したい場合その日時である。
基準バリュー残高とは、この基準バリュー残高を下回ったら新たなチャージを実行するバリュー残高である。例えば、この基準バリュー残高を下回ったら電子マネーサーバ２から電子メールでチャージの処理を促すようにすることもできる。
また、オートチャージを設定する場合は、この基準バリュー残高を下回ったら自動的にチャージ行うこととなる。
ここで、チャージ原資を電話料金に合算する場合を説明する。
携帯端末５が電話機能を備えており、ユーザが携帯電話会社と契約を結んでいる場合、チャージ金額を電話料金と合算して請求先のユーザに請求することも可能である。
この手法は、例えば、デジタルコンテンツの購入代金を電話料金と合算する場合と同様である。
この場合、電子マネーサーバ２は、クレジット会社サーバ３の代わりに携帯電話事業者のサーバにアクセスし、オートチャージ金額の徴収を依頼する。このとき、携帯電話事業者から予め通知されていたＩＤも通知するようにする。
携帯端末５が電話機能を備えており、ユーザが携帯電話会社と契約を結んでいる場合、チャージ金額を電話料金と合算して請求先のユーザに請求することも可能である。
この手法は、例えば、デジタルコンテンツの購入代金を電話料金と合算する場合と同様である。
この場合、電子マネーサーバ２は、クレジット会社サーバ３の代わりに携帯電話事業者のサーバにアクセスし、オートチャージ金額の徴収を依頼する。このとき、携帯電話事業者から予め通知されていたＩＤも通知するようにする。
図６は、携帯端末５に表示される電子マネーサーバ２からのチャージ設定画面を示した図である。本実施形態に係る電子マネーサーバ２からのチャージは、電子マネーサーバ２に事前にユーザ登録をしておくことが前提である。店頭での現金（貨幣）に基づくチャージと異なり、チャージの原資をどのように調達するのかを予め明らかにしておく必要があるからである。
この電子マネーサーバ２からのチャージ設定画面は、電子マネーアプリケーション２９が電子マネーサーバ２にアクセスして表示したものである。
なお、電子マネーサーバ２が携帯端末５に提供する画面には、この他に、ユーザ登録画面、チャージ要求画面など各種のものがある。
この電子マネーサーバ２からのチャージ設定画面は、電子マネーアプリケーション２９が電子マネーサーバ２にアクセスして表示したものである。
なお、電子マネーサーバ２が携帯端末５に提供する画面には、この他に、ユーザ登録画面、チャージ要求画面など各種のものがある。
電子マネーサーバ２からの「チャージ設定」画面では、「１．チャージ資金の調達先を設定してください」との表示の下に、「ａ.クレジットカード」、「ｂ.銀行口座引落」、「ｃ.電話料金に合算」が表示されている。
これ以外に原資を確保する方法があれば、それも表示する。そして、この中からユーザの選択を受信する。この中から複数を選択させて、優先順位を設定するようにしてもよい。
次に、「２．１回のチャージ金額を設定する場合には設定してください」が表示される。
これは任意の設定事項である。設定しておけば、電子マネーサーバ２にチャージを要求する都度、チャージ金額を入力する手間を省くことができる。
この欄（以下の３、４も同様）ドロップダウンメニューとなっており、ユーザがそれぞれ、金額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。
これ以外に原資を確保する方法があれば、それも表示する。そして、この中からユーザの選択を受信する。この中から複数を選択させて、優先順位を設定するようにしてもよい。
次に、「２．１回のチャージ金額を設定する場合には設定してください」が表示される。
これは任意の設定事項である。設定しておけば、電子マネーサーバ２にチャージを要求する都度、チャージ金額を入力する手間を省くことができる。
この欄（以下の３、４も同様）ドロップダウンメニューとなっており、ユーザがそれぞれ、金額を選択するようになっている。なお、ユーザが任意の金額を入力するように構成することもできる。
次に、「３．所定の期間内のチャージ金額の上限を設定する場合は設定してくだ下さい」が表示される。これも任意の設定事項である。例えば、「１日、１０，０００円以内」、「１月、５０，０００円以内」等と設定する。
この設定をしておくことで、携帯端末５を盗取されたとしても、次々とチャージをされて被害が拡大することを防止することができる。
次に、「４．チャージを開始するバリュー残高の下限値を設定してください」が表示される。これも任意の設定事項である。
バリュー残高が設定した下限値を下回ったら、例えば、電子マネーサーバ２から電子メールで通知するようにしてもよいし、電子マネーアプリケーション２９が携帯端末５の表示画面にその旨を表示するようにしてもよい。
更に、上記各欄の下側には、設定ボタン２３４と戻るボタン２３５が表示されている。
設定ボタン２３４は、ユーザが選択した内容を電子マネーサーバ２に通知するためのボタンであり、設定ボタン２３４が選択されると、電子マネーアプリケーション２９は、ユーザが設定した内容を電子マネーサーバ２に送信する。
戻るボタン２３５は、チャージ設定画面を表示する前に表示していた画面に戻るためのボタンである。
この設定をしておくことで、携帯端末５を盗取されたとしても、次々とチャージをされて被害が拡大することを防止することができる。
次に、「４．チャージを開始するバリュー残高の下限値を設定してください」が表示される。これも任意の設定事項である。
バリュー残高が設定した下限値を下回ったら、例えば、電子マネーサーバ２から電子メールで通知するようにしてもよいし、電子マネーアプリケーション２９が携帯端末５の表示画面にその旨を表示するようにしてもよい。
更に、上記各欄の下側には、設定ボタン２３４と戻るボタン２３５が表示されている。
設定ボタン２３４は、ユーザが選択した内容を電子マネーサーバ２に通知するためのボタンであり、設定ボタン２３４が選択されると、電子マネーアプリケーション２９は、ユーザが設定した内容を電子マネーサーバ２に送信する。
戻るボタン２３５は、チャージ設定画面を表示する前に表示していた画面に戻るためのボタンである。
図７は、電子マネーサーバ２からのチャージ利用の登録を行う手順を説明するためのフローチャートである。
以下の処理は、携帯端末５の汎用ＩＣチップ２５に実装されたＣＰＵ、携帯端末５に実装されたＣＰＵ１１、電子マネーサーバ２のＣＰＵ３１が、それぞれ、電子マネー処理用のアプリケーションプログラム、電子マネーアプリケーション２９のプログラム、及び電子マネーサーバ用のプログラムに従って行うものである。
以下の処理は、携帯端末５の汎用ＩＣチップ２５に実装されたＣＰＵ、携帯端末５に実装されたＣＰＵ１１、電子マネーサーバ２のＣＰＵ３１が、それぞれ、電子マネー処理用のアプリケーションプログラム、電子マネーアプリケーション２９のプログラム、及び電子マネーサーバ用のプログラムに従って行うものである。
まず、電子マネーアプリケーション２９は、ユーザの操作により、電子マネーサーバ２にアクセスする。すると、電子マネーサーバ２は、電子マネーアプリケーション２９にトップ画面データを送信し、電子マネーアプリケーション２９は、これを用いてトップ画面を表示する。トップ画面には、チャージ設定用のボタンが表示されている。
ユーザがチャージ設定用のボタンを選択すると、電子マネーアプリケーション２９は、ディスプレイに認証画面を表示する（ステップ５）。
なお、携帯端末５が電子マネーサーバ２に認証画面データを要求し、これに対して電子マネーサーバ２が送信してきた認証画面データを用いて認証画面を表示するように構成することもできる。
認証画面には、パスワード入力欄と送信ボタンが設けられており、ユーザがパスワード入力欄にパスワードを入力すると、電子マネーアプリケーション２９は、当該パスワードを受け付けてＲＡＭ１３などに一時記憶する（ステップ１５）。
なお、携帯端末５が電子マネーサーバ２に認証画面データを要求し、これに対して電子マネーサーバ２が送信してきた認証画面データを用いて認証画面を表示するように構成することもできる。
認証画面には、パスワード入力欄と送信ボタンが設けられており、ユーザがパスワード入力欄にパスワードを入力すると、電子マネーアプリケーション２９は、当該パスワードを受け付けてＲＡＭ１３などに一時記憶する（ステップ１５）。
そして、ユーザが送信ボタンを選択すると電子マネーアプリケーション２９は、汎用ＩＣチップ２５にＩＤ参照コマンドを入力して汎用ＩＣチップ２５から電子マネー番号を読み出し、ＲＡＭ１３に記憶しておいたパスワードと電子マネー番号を認証情報として電子マネーサーバ２に送信する（ステップ２０）。
電子マネーサーバ２は、電子マネーアプリケーション２９から認証情報を受信すると、これをユーザＤＢに記憶してあるパスワードと電子マネー番号とを対比することにより認証を行い（ステップ２５）、電子マネーアプリケーション２９に認証結果を送信する（ステップ３０）。
電子マネーアプリケーション２９は、電子マネーサーバ２から認証結果を受信すると、これを用いて認証結果画面を表示する。
電子マネーアプリケーション２９は、電子マネーサーバ２から認証結果を受信すると、これを用いて認証結果画面を表示する。
電子マネーサーバ２がユーザの認証に失敗した場合、認証結果画面には、認証エラーを通知する内容が表示され、ユーザは、チャージの設定を行うことができない。
一方、電子マネーサーバ２がユーザの認証に成功した場合、認証結果画面には、チャージのサービスを受けるに際しての規約と、当該規約に同意する旨を入力する同意ボタンが表示される。
なお、規約表示とその同意は、初回時や規約改訂時に行うように構成することができる。
一方、電子マネーサーバ２がユーザの認証に成功した場合、認証結果画面には、チャージのサービスを受けるに際しての規約と、当該規約に同意する旨を入力する同意ボタンが表示される。
なお、規約表示とその同意は、初回時や規約改訂時に行うように構成することができる。
ユーザが同意ボタンを選択すると、電子マネーアプリケーション２９は、図６に示したチャージ設定画面を表示する（ステップ３５）。
なお、携帯端末５が電子マネーサーバ２にチャージ設定画面データを要求し、これに対して電子マネーサーバ２が送信してきたチャージ設定画面データを用いてチャージ設定画面を表示するように構成することもできる。
なお、携帯端末５が電子マネーサーバ２にチャージ設定画面データを要求し、これに対して電子マネーサーバ２が送信してきたチャージ設定画面データを用いてチャージ設定画面を表示するように構成することもできる。
電子マネーアプリケーション２９は、ユーザがチャージ設定画面から各種条件を選択することにより登録情報（チャージ資金調達先、１回のチャージ金額、チャージの上限設定、バリュー残高の下限値）の入力を受け付ける（ステップ４５）。
ユーザが、設定ボタン２３４（図６）を選択すると電子マネーアプリケーション２９は、登録情報を電子マネーサーバ２に送信する（ステップ５０）。この際に、電子マネーアプリケーション２９は、後にバリュー残高の確認で用いるためにバリュー残高の下限値をＲＡＭ１３などに記憶する。
ユーザが、設定ボタン２３４（図６）を選択すると電子マネーアプリケーション２９は、登録情報を電子マネーサーバ２に送信する（ステップ５０）。この際に、電子マネーアプリケーション２９は、後にバリュー残高の確認で用いるためにバリュー残高の下限値をＲＡＭ１３などに記憶する。
電子マネーサーバ２は、電子マネーアプリケーション２９から登録情報を受信し、これをチャージ登録ＤＢに記録することにより登録処理を行う（ステップ５５）。
以上のようにして、チャージサービスに関する登録処理が完了する。
以上のようにして、チャージサービスに関する登録処理が完了する。
図８は、携帯端末５の画面に表示されるチャージ要求の画面の１例を示した図であり、図９、図１０は、チャージ処理の手順を説明するためのフローチャートである。
まず、電子マネーアプリケーション２９は、ユーザからの要求に応じて、図８に示すようなチャージ要求画面を表示する。ここで、ユーザが「すぐにチャージしてください」を選択していたとする。
そして、ユーザが「設定」ボタン２３６をクリックすることで、電子マネーアプリケーション２９は、ユーザから電子マネーサーバ２からのチャージ要求を受信する（ステップ１００）。このときチャージ金額（Ｘ円）も同時に受信する。但し、予め１回のチャージ金額が設定されている場合は、受信する必要はない。
そして、電子マネーアプリケーション２９は、汎用ＩＣチップ２５に残高参照コマンドを入力することによりバリュー残高の通知を要求する（ステップ１０５）。
まず、電子マネーアプリケーション２９は、ユーザからの要求に応じて、図８に示すようなチャージ要求画面を表示する。ここで、ユーザが「すぐにチャージしてください」を選択していたとする。
そして、ユーザが「設定」ボタン２３６をクリックすることで、電子マネーアプリケーション２９は、ユーザから電子マネーサーバ２からのチャージ要求を受信する（ステップ１００）。このときチャージ金額（Ｘ円）も同時に受信する。但し、予め１回のチャージ金額が設定されている場合は、受信する必要はない。
そして、電子マネーアプリケーション２９は、汎用ＩＣチップ２５に残高参照コマンドを入力することによりバリュー残高の通知を要求する（ステップ１０５）。
汎用ＩＣチップ２５は、電子マネーアプリケーション２９から残高参照コマンドの入力を受け付けると、記憶部２７からバリュー残高（Ｙ円）を読み出して電子マネーアプリケーション２９に送信する（ステップ１１０）。
電子マネーアプリケーション２９は、汎用ＩＣチップ２５からバリュー残高を取得すると、ステップ１００でチャージ要求金額と合算した値を取得し、所定のチャージ可能な上限値と比較する。この比較で、（Ｘ円＋Ｙ円）が上限値を超過することを確認する（ステップ１１５）。そして、その結果を例えばＲＡＭ１３に記憶しておく。（Ｘ円＋Ｙ円）が上限値を超過していない場合は、従来と同様の処理でチャージを実行する。
ここで、上限値とは、電子マネーのシステムにおいて、各汎用ＩＣチップにチャージしておくことが可能な最高値のことである。単一の汎用ＩＣチップにあまりの多額な金額をチャージしておくことのリスクを考慮してこの上限値が設けられている。例えば、２万円、５万円である。
仮に、上限値が５万円の場合、バリュー残高が４万２千円で、１万円チャージをしようとすると、上限値をオーバーし、チャージができないこととなる。この例では、ユーザが「すぐにチャージしてください」との選択を受けていたが、合算した値が上限値を超えているため、すぐにチャージ行うことができないものとする。
電子マネーアプリケーション２９は、汎用ＩＣチップ２５からバリュー残高を取得すると、ステップ１００でチャージ要求金額と合算した値を取得し、所定のチャージ可能な上限値と比較する。この比較で、（Ｘ円＋Ｙ円）が上限値を超過することを確認する（ステップ１１５）。そして、その結果を例えばＲＡＭ１３に記憶しておく。（Ｘ円＋Ｙ円）が上限値を超過していない場合は、従来と同様の処理でチャージを実行する。
ここで、上限値とは、電子マネーのシステムにおいて、各汎用ＩＣチップにチャージしておくことが可能な最高値のことである。単一の汎用ＩＣチップにあまりの多額な金額をチャージしておくことのリスクを考慮してこの上限値が設けられている。例えば、２万円、５万円である。
仮に、上限値が５万円の場合、バリュー残高が４万２千円で、１万円チャージをしようとすると、上限値をオーバーし、チャージができないこととなる。この例では、ユーザが「すぐにチャージしてください」との選択を受けていたが、合算した値が上限値を超えているため、すぐにチャージ行うことができないものとする。
次に、電子マネーアプリケーション２９は、電子マネーサーバ２にアクセスしてステップ１００で受信した金額のチャージを要求すると共に電子マネー番号を電子マネーサーバ２に送信する（ステップ１２０）。この電子マネー番号は、バリュー残高を取得する際、同時に取得しておく。
なお、チャージコマンドとして上書きコマンドを用いる場合は、電子マネーサーバ２が上書きコマンドを生成するために、電子マネーアプリケーション２９は、バリュー残高を読み出して電子マネーサーバ２に送信する。
また、本実施形態では、チャージの登録の際に認証処理を行っているため、実際にチャージを行う際には認証を行わないが、チャージの度にパスワードの入力を求めて認証するように構成してもよい。
なお、チャージコマンドとして上書きコマンドを用いる場合は、電子マネーサーバ２が上書きコマンドを生成するために、電子マネーアプリケーション２９は、バリュー残高を読み出して電子マネーサーバ２に送信する。
また、本実施形態では、チャージの登録の際に認証処理を行っているため、実際にチャージを行う際には認証を行わないが、チャージの度にパスワードの入力を求めて認証するように構成してもよい。
チャージ要求を受信した電子マネーサーバ２は、受信した電子マネー番号をキーとしてチャージ登録ＤＢからユーザが設定したクレジットカード番号を特定する（ステップ１２５）。
次いで、電子マネーサーバ２は、特定したクレジットカード番号からチャージのための原資を確保する（ステップ１３０）。具体的には、登録されているクレジットカード番号から、クレジット会社サーバ３００から与信の承諾を得る、または銀行口座からチャージ金額分の口座振替を行うことである。
そして、チャージのためのコマンド群を生成し、電子署名を行う（ステップ１３５）。
ここで、電子署名を行うのは、当該コマンド群が電子マネーサーバ２で生成されたものであること、及び改竄がなされていないことを証明するためである。
ここで、コマンド群に含まれるデータについて説明する。このコマンド群の一例としては、チャージ金額を示すデータ、現在の残高を取得するコマンド、残高を「現在の残高＋チャージ金額」に書き換えるコマンド（上書き又は加算）、書換確認コマンド、ログ書込コマンドである。
次いで、電子マネーサーバ２は、特定したクレジットカード番号からチャージのための原資を確保する（ステップ１３０）。具体的には、登録されているクレジットカード番号から、クレジット会社サーバ３００から与信の承諾を得る、または銀行口座からチャージ金額分の口座振替を行うことである。
そして、チャージのためのコマンド群を生成し、電子署名を行う（ステップ１３５）。
ここで、電子署名を行うのは、当該コマンド群が電子マネーサーバ２で生成されたものであること、及び改竄がなされていないことを証明するためである。
ここで、コマンド群に含まれるデータについて説明する。このコマンド群の一例としては、チャージ金額を示すデータ、現在の残高を取得するコマンド、残高を「現在の残高＋チャージ金額」に書き換えるコマンド（上書き又は加算）、書換確認コマンド、ログ書込コマンドである。
次に、電子マネーサーバ２は、生成したコマンド群をＩＣチップに記憶させる保存命令を電子マネーアプリケーション２９に送信する（ステップ１４０）。
電子マネーアプリケーション２９は、電子マネーサーバ２から保存命令を受信して、これを汎用ＩＣチップ２５に転送（入力）する（ステップ１４５）。このとき、電子マネーアプリケーション２９は、ステップ１１５の判断でチャージを行うと上限値を超えると判断されていた場合、同時に当該コマンド群に基づくチャージを直ちに行わず、一旦当該コマンド群を記憶部２７に保存するように要求する。この例では、上限値を超えていたので、一旦当該コマンド群を記憶部２７に保存するように要求する。
汎用ＩＣチップ２５は、電子マネーアプリケーション２９から保存命令の転送を受けると、それらに付されている電子署名を検証する（ステップ１５０）。この検証後、当該コマンド群を一旦記憶部２７に保存する（ステップ１５５）。
ここで、コマンド群の実行処理について説明する。一例としてまず、汎用ＩＣチップ２５からバリュー残高を取得し、この取得したバリュー残高＋チャージ金額でこのバリュー残高を書き換え、書換後のバリュー残高を確認することである。
電子マネーアプリケーション２９は、電子マネーサーバ２から保存命令を受信して、これを汎用ＩＣチップ２５に転送（入力）する（ステップ１４５）。このとき、電子マネーアプリケーション２９は、ステップ１１５の判断でチャージを行うと上限値を超えると判断されていた場合、同時に当該コマンド群に基づくチャージを直ちに行わず、一旦当該コマンド群を記憶部２７に保存するように要求する。この例では、上限値を超えていたので、一旦当該コマンド群を記憶部２７に保存するように要求する。
汎用ＩＣチップ２５は、電子マネーアプリケーション２９から保存命令の転送を受けると、それらに付されている電子署名を検証する（ステップ１５０）。この検証後、当該コマンド群を一旦記憶部２７に保存する（ステップ１５５）。
ここで、コマンド群の実行処理について説明する。一例としてまず、汎用ＩＣチップ２５からバリュー残高を取得し、この取得したバリュー残高＋チャージ金額でこのバリュー残高を書き換え、書換後のバリュー残高を確認することである。
この段階で、本実施形態の処理は、一旦終了する。すなわち、この時点でのチャージは行わないが、実行を指示すれば、直ぐにチャージ実行可能な状態を意図的に作出する。そして、チャージの指示があれば、チャージのための一連の前段階の手順を省いて、直ちにチャージを行えるようにする。
次に、電子マネーアプリケーション２９は、定期的に汎用ＩＣチップ２５に残高参照コマンドを入力することによりバリュー残高の通知を要求する（ステップ１６０）。これに対して、汎用ＩＣチップ２５は、記憶部２７からバリュー残高を読み出して電子マネーアプリケーション２９に送信する（ステップ１６５）。
そして、電子マネーアプリケーション２９は、汎用ＩＣチップ２５からバリュー残高（Ｙ円）を取得すると、ステップ１００で受信したチャージ要求金額（Ｘ円）と合算した値を取得し、所定のチャージ可能な上限値と比較する（ステップ１７０）。
その結果、当該バリュー残高（Ｙ円）とステップ１００でステップ１００で受信したチャージ要求金額（Ｘ円）と合算した値が上限値を下回った場合（ステップ１７０；Ｙ）、電子マネーアプリケーション２９は、ステップ１５５で保存しておいたコマンド群の実行及び当該コマンド群の無効化を指示する（ステップ１７５）。ここで、バリュー残高が減少したということは、この間にバリュー残高が何らかの決済処理に用いられたことを意味している。また、無効化の態様として、データそのものを消去する、所定の無効フラグを有意化する、等が好適である。
なお、当該バリュー残高とチャージ要求金額とを合算した値が上限値を下回らなかった場合（ステップ１７０；Ｎ）、ステップ１６０に戻り、定期的に汎用ＩＣチップ２５にバリュー残高の通知を要求する。
そして、電子マネーアプリケーション２９は、汎用ＩＣチップ２５からバリュー残高（Ｙ円）を取得すると、ステップ１００で受信したチャージ要求金額（Ｘ円）と合算した値を取得し、所定のチャージ可能な上限値と比較する（ステップ１７０）。
その結果、当該バリュー残高（Ｙ円）とステップ１００でステップ１００で受信したチャージ要求金額（Ｘ円）と合算した値が上限値を下回った場合（ステップ１７０；Ｙ）、電子マネーアプリケーション２９は、ステップ１５５で保存しておいたコマンド群の実行及び当該コマンド群の無効化を指示する（ステップ１７５）。ここで、バリュー残高が減少したということは、この間にバリュー残高が何らかの決済処理に用いられたことを意味している。また、無効化の態様として、データそのものを消去する、所定の無効フラグを有意化する、等が好適である。
なお、当該バリュー残高とチャージ要求金額とを合算した値が上限値を下回らなかった場合（ステップ１７０；Ｎ）、ステップ１６０に戻り、定期的に汎用ＩＣチップ２５にバリュー残高の通知を要求する。
コマンド群の実行の指示を受けた汎用ＩＣチップ２５は、当該コマンド群の実行処理を行い（ステップ１８０）、記憶部２７に記憶されているバリュー残高をＸ円分更新（増額）する（ステップ１８５）。
その後、バリュー残高の更新が完了した旨を電子マネーアプリケーション２９に通知する（ステップ１９０）。
そして、電子マネーアプリケーション２９は、バリュー残高更新通知を電子マネーサーバ２に送り（ステップ１９５）、電子マネーサーバ２は、汎用ＩＣチップ２５に対してログデータを要求する（ステップ１９７）。これに対して、汎用ＩＣチップ２５が、電子マネーサーバ２に、ログデータを送信して（ステップ１９９）、処理を終了する。
この例では、チャージ要求の際、ユーザが「すぐにチャージしてください」を選択したが、上限値の関係ですぐにチャージができない状態だったので、結果として「とりあえずチャージの準備をしてください」を選択したのと同様の処理となった。
この例では、図９に示した処理がチャージの準備段階、図１０に示した処理がチャージの実行段階である。
こうすることで、予めチャージの準備段階を行っておけば、チャージが必要になった時に直ちにチャージを実行することができる。
その後、バリュー残高の更新が完了した旨を電子マネーアプリケーション２９に通知する（ステップ１９０）。
そして、電子マネーアプリケーション２９は、バリュー残高更新通知を電子マネーサーバ２に送り（ステップ１９５）、電子マネーサーバ２は、汎用ＩＣチップ２５に対してログデータを要求する（ステップ１９７）。これに対して、汎用ＩＣチップ２５が、電子マネーサーバ２に、ログデータを送信して（ステップ１９９）、処理を終了する。
この例では、チャージ要求の際、ユーザが「すぐにチャージしてください」を選択したが、上限値の関係ですぐにチャージができない状態だったので、結果として「とりあえずチャージの準備をしてください」を選択したのと同様の処理となった。
この例では、図９に示した処理がチャージの準備段階、図１０に示した処理がチャージの実行段階である。
こうすることで、予めチャージの準備段階を行っておけば、チャージが必要になった時に直ちにチャージを実行することができる。
ここでは、チャージの準備段階をユーザの意思で、すなわち手動で行い、チャージの実行を自動で行っている。
このような実施形態が有用な場合として、上限値を上回る決済が短期間に行われることが事前に予想されるとき、具体的には高額商品の購入、多数の商品、サービスへの支払が予定されているときである。
また、この実施形態では、コマンド群を携帯端末５に内蔵された汎用ＩＣチップ２５に保存しているので、携帯端末５が電波の届かない場所にいても、また、ゲーム機、タブレット型コンピュータのように、携帯電話網の基地局アンテナを無線通信する機能を備えていなくても、図１０に示したコマンド群実行処理（ステップ１８０）が可能である。
よって、予めオンラインでチャージを行うことが困難なことが想定できる場合、予めチャージの準備段階を行っておくことで、チャージが必要になった時に直ちにチャージを実行することができる。
これらの例は、チャージの実行を図１０のフローチャートに示したように、自動で実行することを前提としていたが、図１０のステップ１７５のコマンド群実行処理指示を電子マネーアプリケーション２９がユーザからの入力に基づいて行う構成とすれば、ユーザの意思（手動）で行うようにすることもできる。
このような実施形態が有用な場合として、上限値を上回る決済が短期間に行われることが事前に予想されるとき、具体的には高額商品の購入、多数の商品、サービスへの支払が予定されているときである。
また、この実施形態では、コマンド群を携帯端末５に内蔵された汎用ＩＣチップ２５に保存しているので、携帯端末５が電波の届かない場所にいても、また、ゲーム機、タブレット型コンピュータのように、携帯電話網の基地局アンテナを無線通信する機能を備えていなくても、図１０に示したコマンド群実行処理（ステップ１８０）が可能である。
よって、予めオンラインでチャージを行うことが困難なことが想定できる場合、予めチャージの準備段階を行っておくことで、チャージが必要になった時に直ちにチャージを実行することができる。
これらの例は、チャージの実行を図１０のフローチャートに示したように、自動で実行することを前提としていたが、図１０のステップ１７５のコマンド群実行処理指示を電子マネーアプリケーション２９がユーザからの入力に基づいて行う構成とすれば、ユーザの意思（手動）で行うようにすることもできる。
また、特定の時期が到来するまで当該バリューを使用できないようにしておきたい場合、例えば、一定の期日に渡すことが決まっている小遣いの準備があげられる。また、浪費してしまうことを防止する場合もあげられる。例えば、昼食代、帰りの交通費などである。この例では、図１０のステップ１７０で、電子マネーアプリケーション２９が記憶している時期が到来したか否かを判断し、到来していればステップ１７５のコマンド群実行処理指示を行うようにする。
この例は、図９に示したように、ユーザの意思（手動）でチャージの準備段階を開始してもよいが、オートチャージのように、一定の要件のもと自動でチャージの準備段階を開始するようにしてもよい。この場合も、電子マネーアプリケーション２９が記憶している時期が到来したか否かを判断し、到達すればステップ１７５のコマンド群実行処理指示を行うようにする。すなわち、ユーザの意思（手動）でなく、自動でチャージを行う。
この例は、図９に示したように、ユーザの意思（手動）でチャージの準備段階を開始してもよいが、オートチャージのように、一定の要件のもと自動でチャージの準備段階を開始するようにしてもよい。この場合も、電子マネーアプリケーション２９が記憶している時期が到来したか否かを判断し、到達すればステップ１７５のコマンド群実行処理指示を行うようにする。すなわち、ユーザの意思（手動）でなく、自動でチャージを行う。
次に、第２の実施形態を説明する。
図１１、図１２は、第２の実施形態の処理手順を示したフローチャートである。
この実施形態では、チャージの準備段階を自動で行い、チャージの実行段階をユーザの意思（手動）で行う。
電子マネーアプリケーション２９は、定期的に汎用ＩＣチップ２５に残高参照コマンドを入力することによりバリュー残高の通知を要求し（ステップ２０５）、これに対して、汎用ＩＣチップ２５は、電子マネーアプリケーション２９から残高参照コマンドの入力を受け付けると、記憶部２７からバリュー残高を読み出して電子マネーアプリケーション２９に送信する（ステップ２１０）。
図１１、図１２は、第２の実施形態の処理手順を示したフローチャートである。
この実施形態では、チャージの準備段階を自動で行い、チャージの実行段階をユーザの意思（手動）で行う。
電子マネーアプリケーション２９は、定期的に汎用ＩＣチップ２５に残高参照コマンドを入力することによりバリュー残高の通知を要求し（ステップ２０５）、これに対して、汎用ＩＣチップ２５は、電子マネーアプリケーション２９から残高参照コマンドの入力を受け付けると、記憶部２７からバリュー残高を読み出して電子マネーアプリケーション２９に送信する（ステップ２１０）。
電子マネーアプリケーション２９は、汎用ＩＣチップ２５からバリュー残高を取得すると、基準バリュー残高と比較し、バリュー残高が基準バリュー残高を下回っていないか否かを判断する（ステップ２１５）。その結果、下回っていなければ（ステップ２１５；Ｎ）、ステップ２０５に戻り、バリュー残高のチェックを継続する。
一方、下回っていれば（ステップ２１５；Ｙ）、電子マネーアプリケーション２９は、電子マネーサーバ２にアクセスして、所定の金額のチャージを要求すると共に電子マネー番号を電子マネーサーバ２に送信する（ステップ２２０）。この電子マネー番号は、バリュー残高を取得する際、同時に取得しておく。なお、所定の金額は、この処理を自動で行うため、予め決められている金額である。
なお、チャージコマンドとして上書きコマンドを用いる場合は、電子マネーサーバ２が上書きコマンドを生成するために、電子マネーアプリケーション２９は、バリュー残高を読み出して電子マネーサーバ２に送信する。
また、本実施形態では、チャージの登録の際に認証処理を行っているため、実際にチャージを行う際には認証を行わないが、チャージの度にパスワードの入力を求めて認証するように構成してもよい。
一方、下回っていれば（ステップ２１５；Ｙ）、電子マネーアプリケーション２９は、電子マネーサーバ２にアクセスして、所定の金額のチャージを要求すると共に電子マネー番号を電子マネーサーバ２に送信する（ステップ２２０）。この電子マネー番号は、バリュー残高を取得する際、同時に取得しておく。なお、所定の金額は、この処理を自動で行うため、予め決められている金額である。
なお、チャージコマンドとして上書きコマンドを用いる場合は、電子マネーサーバ２が上書きコマンドを生成するために、電子マネーアプリケーション２９は、バリュー残高を読み出して電子マネーサーバ２に送信する。
また、本実施形態では、チャージの登録の際に認証処理を行っているため、実際にチャージを行う際には認証を行わないが、チャージの度にパスワードの入力を求めて認証するように構成してもよい。
チャージ要求を受信した電子マネーサーバ２は、受信した電子マネー番号をキーとしてチャージ登録ＤＢからユーザが設定したクレジットカード番号を特定する（ステップ２２５）。
次いで、電子マネーサーバ２は、特定したクレジットカード番号からチャージのための原資を確保する（ステップ２３０）。具体的には、登録されているクレジットカード番号から、クレジット会社サーバ３００から与信の承諾を得る、または銀行口座からチャージ金額分の口座振替を行うことである。
そして、チャージのためのコマンド群を生成し、電子署名を行う（ステップ２３５）。
次いで、電子マネーサーバ２は、特定したクレジットカード番号からチャージのための原資を確保する（ステップ２３０）。具体的には、登録されているクレジットカード番号から、クレジット会社サーバ３００から与信の承諾を得る、または銀行口座からチャージ金額分の口座振替を行うことである。
そして、チャージのためのコマンド群を生成し、電子署名を行う（ステップ２３５）。
次に、電子マネーサーバ２は、生成したコマンド群を汎用ＩＣチップ２５に記憶させる保存命令を電子マネーアプリケーション２９に送信する（ステップ２４０）。
電子マネーアプリケーション２９は、電子マネーサーバ２から保存命令を受信して、これを汎用ＩＣチップ２５に転送（入力）する（ステップ２４５）。
このとき、電子マネーアプリケーション２９は、一旦当該コマンド群を記憶部２７に保存するように要求する。
汎用ＩＣチップ２５は、電子マネーアプリケーション２９からチャージのコマンド群の入力を受けると、それらに付されている電子署名を検証する（ステップ２５０）。この検証後、当該コマンド群を一旦記憶部２７に保存する（ステップ２５５）。
電子マネーアプリケーション２９は、電子マネーサーバ２から保存命令を受信して、これを汎用ＩＣチップ２５に転送（入力）する（ステップ２４５）。
このとき、電子マネーアプリケーション２９は、一旦当該コマンド群を記憶部２７に保存するように要求する。
汎用ＩＣチップ２５は、電子マネーアプリケーション２９からチャージのコマンド群の入力を受けると、それらに付されている電子署名を検証する（ステップ２５０）。この検証後、当該コマンド群を一旦記憶部２７に保存する（ステップ２５５）。
この段階で、本実施形態の処理は、一旦終了する。すなわち、この時点でのチャージは行わないが、実行を指示すれば、直ぐにチャージ実行可能な状態を意図的に作出する。そして、チャージの指示があれば、チャージのための一連の前段階の手順を省いて、直ちにチャージを行えるようにする。
次に、電子マネーアプリケーション２９は、ユーザからの所定の操作があったか否かを判断する（ステップ２７０）。所定の操作とは、例えばパスワードの入力、指紋認証の実施などである。
このユーザの所定の操作があれば（ステップ２７０；Ｙ）、電子マネーアプリケーション２９は、ステップ２５５で保存しておいたコマンド群の実行及び当該コマンド群の無効化を指示する（ステップ２７５）。無効化の態様としては、データそのものを消去する、所定の無効フラグを有意化する、等が好適である。
コマンド群の実行の指示を受けた汎用ＩＣチップ２５は、当該コマンド群の実行処理を行い（ステップ２８０）、記憶部２７に記憶されているバリュー残高をＸ円分更新（増額）する（ステップ２８５）。
その後、バリュー残高の更新が完了した旨を電子マネーアプリケーション２９に、通知する（ステップ２９０）。
そして、電子マネーアプリケーション２９は、バリュー残高更新通知を電子マネーサーバ２に送り（ステップ２９５）、電子マネーサーバ２は、汎用ＩＣチップ２５に対してログデータを要求する（ステップ２９７）。これに対して、汎用ＩＣチップ２５が、電子マネーサーバ２に、ログデータを送信して（ステップ２９９）、処理を終了する。
このユーザの所定の操作があれば（ステップ２７０；Ｙ）、電子マネーアプリケーション２９は、ステップ２５５で保存しておいたコマンド群の実行及び当該コマンド群の無効化を指示する（ステップ２７５）。無効化の態様としては、データそのものを消去する、所定の無効フラグを有意化する、等が好適である。
コマンド群の実行の指示を受けた汎用ＩＣチップ２５は、当該コマンド群の実行処理を行い（ステップ２８０）、記憶部２７に記憶されているバリュー残高をＸ円分更新（増額）する（ステップ２８５）。
その後、バリュー残高の更新が完了した旨を電子マネーアプリケーション２９に、通知する（ステップ２９０）。
そして、電子マネーアプリケーション２９は、バリュー残高更新通知を電子マネーサーバ２に送り（ステップ２９５）、電子マネーサーバ２は、汎用ＩＣチップ２５に対してログデータを要求する（ステップ２９７）。これに対して、汎用ＩＣチップ２５が、電子マネーサーバ２に、ログデータを送信して（ステップ２９９）、処理を終了する。
この第２の実施形態では、チャージの準備段階を自動で行うので、オートチャージと同様の処理であり、最終的なチャージの実行のみをユーザの意思（操作）としている。そのため、オートチャージによる利便性を確保すると同時に、ユーザが関知しないでチャージが行われてしまうことのリスクを回避することができる。
次に、第３の実施形態を説明する。
この第３の実施形態は、電子マネーサーバ２から受信したコマンド群を汎用ＩＣチップ２５に保存しないで、電子マネーアプリケーション２９の側で保存することを特徴としている。この第３の実施形態は、汎用ＩＣチップ２５にロックがかかっていることを前提としている。ここでロックがかかるとは、汎用ＩＣチップ２５に対する電源供給によりこの
汎用ＩＣチップ２５が稼働するという仕組みのもとで、この汎用ＩＣチップ２５に対する電源供給を断つことをいう。
ロックをかけることで、当該携帯端末５が紛失した場合、盗取された場合等に、電子マネーが使用されてしまうことを防止できる。なお、ロックの解除には、所定の暗証番号等による認証が必要となる。
この第３の実施形態は、電子マネーサーバ２から受信したコマンド群を汎用ＩＣチップ２５に保存しないで、電子マネーアプリケーション２９の側で保存することを特徴としている。この第３の実施形態は、汎用ＩＣチップ２５にロックがかかっていることを前提としている。ここでロックがかかるとは、汎用ＩＣチップ２５に対する電源供給によりこの
汎用ＩＣチップ２５が稼働するという仕組みのもとで、この汎用ＩＣチップ２５に対する電源供給を断つことをいう。
ロックをかけることで、当該携帯端末５が紛失した場合、盗取された場合等に、電子マネーが使用されてしまうことを防止できる。なお、ロックの解除には、所定の暗証番号等による認証が必要となる。
図１３、図１４は、この第３の実施形態の処理手順を示したフローチャートである。
電子マネーアプリケーション２９は、チャージを開始する所定の要件を充足したか否かを判断する（ステップ３１５）。この所定の要件とは、例えば、バリュー残高が基準バリュー残高を下回るといった条件である。
その結果、所定の要件を充足していれば（ステップ３１５；Ｙ）、電子マネーアプリケーション２９は、電子マネーサーバ２にアクセスして、所定の金額のチャージを要求すると共に電子マネー番号を電子マネーサーバ２に送信する（ステップ３２０）。
チャージ要求を受信した電子マネーサーバ２は、受信した電子マネー番号をキーとしてチャージ登録ＤＢからユーザが設定したクレジットカード番号を特定する（ステップ３２５）。
次いで、電子マネーサーバ２は、特定したクレジットカード番号からチャージのための原資を確保する（ステップ３３０）。
そして、チャージのためのコマンド群を生成し、電子署名を行う（ステップ３３５）。
電子マネーアプリケーション２９は、チャージを開始する所定の要件を充足したか否かを判断する（ステップ３１５）。この所定の要件とは、例えば、バリュー残高が基準バリュー残高を下回るといった条件である。
その結果、所定の要件を充足していれば（ステップ３１５；Ｙ）、電子マネーアプリケーション２９は、電子マネーサーバ２にアクセスして、所定の金額のチャージを要求すると共に電子マネー番号を電子マネーサーバ２に送信する（ステップ３２０）。
チャージ要求を受信した電子マネーサーバ２は、受信した電子マネー番号をキーとしてチャージ登録ＤＢからユーザが設定したクレジットカード番号を特定する（ステップ３２５）。
次いで、電子マネーサーバ２は、特定したクレジットカード番号からチャージのための原資を確保する（ステップ３３０）。
そして、チャージのためのコマンド群を生成し、電子署名を行う（ステップ３３５）。
次に、電子マネーサーバ２は、生成したコマンド群を汎用ＩＣチップ２５に記憶させる保存命令を電子マネーアプリケーション２９に送信する（ステップ３４０）。
電子マネーアプリケーション２９は、電子マネーサーバ２からチャージのコマンド群を受信して、汎用ＩＣチップ２５への転送を試みる。しかし、汎用ＩＣチップ２５にロックがかかっている等、コマンド群を汎用ＩＣチップ２５に記憶させることが難しい場合は、このコマンド群をＲＡＭ１３に保存する（ステップ３４５）。
これで、自動で行うチャージの準備段階が完了する。この実施形態では、第１の実施形態、第２の実施形態と異なり、受信したコマンド群を汎用ＩＣチップ２５に保存しない。これは、汎用ＩＣチップ２５にロックがかかっており、働かない状態となっているからである。
電子マネーアプリケーション２９は、電子マネーサーバ２からチャージのコマンド群を受信して、汎用ＩＣチップ２５への転送を試みる。しかし、汎用ＩＣチップ２５にロックがかかっている等、コマンド群を汎用ＩＣチップ２５に記憶させることが難しい場合は、このコマンド群をＲＡＭ１３に保存する（ステップ３４５）。
これで、自動で行うチャージの準備段階が完了する。この実施形態では、第１の実施形態、第２の実施形態と異なり、受信したコマンド群を汎用ＩＣチップ２５に保存しない。これは、汎用ＩＣチップ２５にロックがかかっており、働かない状態となっているからである。
その後、電子マネーアプリケーション２９は、汎用ＩＣチップ２５のロック状態を監視する（ステップ３７０）。そして、汎用ＩＣチップ２５のロック状態の解除を検出すると（ステップ３７０；Ｙ）、電子マネーアプリケーション２９は、ステップ３４５で保存しておいたコマンド群を汎用ＩＣチップ２５に送り、その実行及び当該コマンド群の無効化を指示する（ステップ３７５）。無効化の態様としては、データそのものを消去する、所定の無効フラグを有意化する、等が好適である。
コマンド群の実行の指示を受けた汎用ＩＣチップ２５は、当該コマンド群の署名検証を行う（ステップ３８０）。そして、当該の実行処理を行い（ステップ３８５）、記憶部２７に記憶されているバリュー残高をＸ円分更新（増額）する（ステップ３９０）。このように、ここでは、コマンド群の署名検証をコマンド群の実行処理の直前に行っている。
その後、バリュー残高の更新が完了した旨を電子マネーアプリケーション２９に通知すする（ステップ３９５）。
そして、電子マネーアプリケーション２９は、バリュー残高更新通知を電子マネーサーバ２に送り（ステップ３９６）、電子マネーサーバ２は、汎用ＩＣチップ２５に対してログデータを要求する（ステップ３９７）。これに対して、汎用ＩＣチップ２５が、電子マネーサーバ２に、ログデータを送信して（ステップ３９９）、処理を終了する。
この実施形態では、チャージの準備段階を自動で行い、且つ汎用ＩＣチップ２５のロックの解除を検知すると準備しておいたチャージを自動的に実行する。そのため、決済のために、汎用ＩＣチップ２５のロックを解除したら、直ちにチャージが完了するので、決済時にバリュー残高が不足していて、決済不能となることを防止できる。
この実施形態において、電子マネーアプリケーション２９が、汎用ＩＣチップ２５のロック状態の解除を検出するには、電子マネーアプリケーション２９が、定期的に汎用ＩＣチップ２５にアクセスを試みる、汎用ＩＣチップ２５のロック／解除を制御する、携帯端末５のアプリケーションからロック解除の通知を受けるといった方法があげられる。
コマンド群の実行の指示を受けた汎用ＩＣチップ２５は、当該コマンド群の署名検証を行う（ステップ３８０）。そして、当該の実行処理を行い（ステップ３８５）、記憶部２７に記憶されているバリュー残高をＸ円分更新（増額）する（ステップ３９０）。このように、ここでは、コマンド群の署名検証をコマンド群の実行処理の直前に行っている。
その後、バリュー残高の更新が完了した旨を電子マネーアプリケーション２９に通知すする（ステップ３９５）。
そして、電子マネーアプリケーション２９は、バリュー残高更新通知を電子マネーサーバ２に送り（ステップ３９６）、電子マネーサーバ２は、汎用ＩＣチップ２５に対してログデータを要求する（ステップ３９７）。これに対して、汎用ＩＣチップ２５が、電子マネーサーバ２に、ログデータを送信して（ステップ３９９）、処理を終了する。
この実施形態では、チャージの準備段階を自動で行い、且つ汎用ＩＣチップ２５のロックの解除を検知すると準備しておいたチャージを自動的に実行する。そのため、決済のために、汎用ＩＣチップ２５のロックを解除したら、直ちにチャージが完了するので、決済時にバリュー残高が不足していて、決済不能となることを防止できる。
この実施形態において、電子マネーアプリケーション２９が、汎用ＩＣチップ２５のロック状態の解除を検出するには、電子マネーアプリケーション２９が、定期的に汎用ＩＣチップ２５にアクセスを試みる、汎用ＩＣチップ２５のロック／解除を制御する、携帯端末５のアプリケーションからロック解除の通知を受けるといった方法があげられる。
この第３の実施形態では、チャージの準備段階で、電子マネーサーバ２から受信したコマンド群を、汎用ＩＣチップ２５でなく、電子マネーアプリケーション２９で保存することとした。この処理は、第１の実施形態、第２の実施形態にも適用することができる。
上記説明した各実施形態では、電子マネーサーバ２から送信されたコマンド群を一旦保存して、チャージの準備段階を完了した。しかし、チャージが実際に行われない場合も想定できる。このような場合のために、コマンド群に有効期限を設け、この間にチャージが実行されなかった場合は、当該コマンド群を無効とし、原資を各金融機関へ返還するようにしてもよい。
ゲーム機、タブレット型コンピュータのように、携帯電話網の基地局アンテナを無線通信する機能を備えていない携帯端末５を用いるときは、例えば、自宅、職場などの無線ＬＡＮ経由で、チャージ予約処理（図９のステップ１００からステップ１５５、図１１のステップ２０５からステップ２５５）を行っておき、出先でチャージ実行処理（図９のステップ１６０からステップ１９０、図１１のステップ２７０からステップ２９０を行うようにしてもよい。
上記した各実施形態では、電子マネーアプリケーション２９が、汎用ＩＣチップ２５からバリュー残高を確認するようにしていた。これに対して、電子マネーサーバ２が、定期的にログをチェックし、バリュー残高が所定値以下又は未満となっている電子マネー番号を特定し、この特定された電子マネー番号に対応する携帯端末５、例えばスマートフォンに対して、その通知機能を利用して残高確認を指示するように構成してもよい。
この通知を受けた携帯端末５は、電子マネーアプリケーション２９が、図１１に示すフローチャートのステップ２０５以下に沿った処理を行う。
このような構成とすることで、電子マネーアプリケーション２９が、定期的に汎用ＩＣチップ２５を監視する必要がなくなり、携帯端末５のバッテリーの消耗を抑制することができる。
この通知を受けた携帯端末５は、電子マネーアプリケーション２９が、図１１に示すフローチャートのステップ２０５以下に沿った処理を行う。
このような構成とすることで、電子マネーアプリケーション２９が、定期的に汎用ＩＣチップ２５を監視する必要がなくなり、携帯端末５のバッテリーの消耗を抑制することができる。
また、他の例として、チャージ予約処理（図９のステップ１００からステップ１５５、図１１のステップ２０５からステップ２５５）が行われた場合、電子マネーアプリケーション２９が、このチャージ予約に対応付けられたことを示すアイコン（例えば、「１０，０００円チャージ」等の文言を含む）を携帯端末５の表示画面に表示するようにする。このアイコンは、複数のチャージ予約がある場合は、複数個表示するようにしてもよい。このアイコンは、電子マネーアプリケーション２９を起動するためのショートカットに相当する。
そして、このアイコンに対するユーザの操作を電子マネーアプリケーション２９が、検知した後、当該予約されたチャージを実行するようにする。
こうすることで、ユーザに確実にチャージ予約の存在を認識させることができ、且つ簡単な操作で当該チャージを実行することができる。
そして、このアイコンに対するユーザの操作を電子マネーアプリケーション２９が、検知した後、当該予約されたチャージを実行するようにする。
こうすることで、ユーザに確実にチャージ予約の存在を認識させることができ、且つ簡単な操作で当該チャージを実行することができる。
また、他の例として、チャージ予約処理（図９のステップ１００からステップ１５５、図１１のステップ２０５からステップ２５５）が行われた場合、電子マネーアプリケーション２９が、このチャージ予約に対応付けられた通知データ（例えば「１０，０００円チャージ」等の文言を含む）を、携帯端末５の通知領域に表示するようにする。この通知データは、複数のチャージ予約がある場合は、複数個表示するようにしてもよい。この通知データには、電子マネーアプリケーション２９を起動する起動タグが含まれているとよい。
そして、この通知データに対するユーザの操作を電子マネーアプリケーション２９が、検知した後、当該予約されたチャージを実行するようにする。
こうすることで、ユーザに確実にチャージ予約の存在を認識させることができ、且つ簡単な操作で当該チャージを実行することができる。
そして、この通知データに対するユーザの操作を電子マネーアプリケーション２９が、検知した後、当該予約されたチャージを実行するようにする。
こうすることで、ユーザに確実にチャージ予約の存在を認識させることができ、且つ簡単な操作で当該チャージを実行することができる。
１ 電子マネーシステム
２ 電子マネーサーバ
３ インターネット
４ 電子マネーカード
５ 携帯端末
６ 決済端末
７ 非同期決済端末
８ 通信回線
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 入力部
１５ 出力部
１６ 通信制御部
１７ 近距離通信制御部
１８ 記憶部
１９ バスライン
２１ 契約者情報ＩＣチップ
２２ 情報処理部
２３ 記憶部
２５ 汎用ＩＣチップ
２６ 情報処理部
２７ 記憶部
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３４ 通信制御部
３５ 記憶部
３６ バスライン
９０ 電子マネーカード
３００ クレジット会社サーバ
２ 電子マネーサーバ
３ インターネット
４ 電子マネーカード
５ 携帯端末
６ 決済端末
７ 非同期決済端末
８ 通信回線
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 入力部
１５ 出力部
１６ 通信制御部
１７ 近距離通信制御部
１８ 記憶部
１９ バスライン
２１ 契約者情報ＩＣチップ
２２ 情報処理部
２３ 記憶部
２５ 汎用ＩＣチップ
２６ 情報処理部
２７ 記憶部
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３４ 通信制御部
３５ 記憶部
３６ バスライン
９０ 電子マネーカード
３００ クレジット会社サーバ
Claims (11)
- 電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末であって、
前記残高記憶手段に記憶される残高を増額させる残高変更情報をＩＣチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得手段と、
前記取得手段により取得される保存命令に従い前記残高変更情報が前記ＩＣチップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送手段と、
前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示手段と、
を具備することを特徴とする携帯端末。
- 前記指示手段が、前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させるとともに該ＩＣチップ側記憶手段に記憶される残高変更情報を無効化させる実行指示を、所定のタイミングで前記ＩＣチップに出力する、ことを特徴とする請求項１に記載の携帯端末。
- 前記転送手段により転送される保存命令に従い前記残高変更情報が前記ＩＣチップ側記憶手段に記憶されない場合に、該残高変更情報を携帯端末側記憶手段に記憶させる保存手段をさらに具備し、
前記指示手段が、さらに、前記携帯端末側記憶手段に記憶される残高変更情報を前記ＩＣチップに出力する、
ことを特徴とする請求項１又は請求項２に記載の携帯端末。
- 前記ＩＣチップを一時的に無効化する無効化手段と、
前記無効化手段による前記ＩＣチップの一時的な無効化を解除する解除手段と、
をさらに具備し、
前記保存手段が、前記ＩＣチップが前記無効化手段により無効化されている場合に、前記取得手段により取得される保存命令において指定される残高変更情報を前記携帯端末側記憶手段に記憶させ、
前記指示手段が、前記解除手段により前記ＩＣチップの無効化が解除されたタイミングで前記実行指示を出力する、
ことを特徴とする請求項３に記載の携帯端末。
- 前記取得手段により取得される残高変更情報を用いた変更処理により変更されるべき金額に対応付けられたオブジェクトを表示画面に表示させる手段をさらに具備し、
前記指示手段が、前記実行指示を、前記表示画面に表示されたオブジェクトに対する所定の操作が検出されたタイミングで、前記ＩＣチップに出力する、
ことを特徴とする請求項１〜４のいずれか１項に記載の携帯端末。
- 前記取得手段により取得される残高変更情報を用いた変更処理により変更されるべき金額を含む通知データを通知領域に表示させる手段をさらに具備し、
前記指示手段が、前記実行指示を、前記通知領域に表示された通知データに対する所定の操作が検出されたタイミングで、前記ＩＣチップに出力する、
ことを特徴とする請求項１〜４のいずれか１項に記載の携帯端末。
- 前記ＩＣチップが、前記残高変更手段による変更処理の実行結果を含むログデータを前記ＩＣチップ側記憶手段に記憶させる手段と、
前記ＩＣチップ側記憶手段に記憶されるログデータを前記情報処理サーバに送信する手段と、
をさらに具備する、
ことを特徴とする請求項１〜６のいずれか１項に記載の携帯端末。
- 前記残高変更情報が、
前記残高記憶手段に記憶される残高に加算されるべき加算金額と、
前記残高記憶手段に記憶される残高を取得するコマンドと、
前記取得される残高に前記加算金額を加算させた値に前記残高記憶手段に記憶される残高を変更させるコマンドと、
を含む、
ことを特徴とする請求項１〜７のいずれか１項に記載の携帯端末。
- 電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末の制御方法であって、
前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得ステップと、
前記取得ステップにおいて取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送ステップと、
前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示ステップと、
を具備することを特徴とする携帯端末の制御方法。
- 電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末に、
前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得機能と、
前記取得機能により取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送機能と、
前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示機能と、
を実現させるためのプログラム。
- 電子バリューの残高を記憶する残高記憶手段と、残高変更情報を用いて前記残高記憶手段に記憶される残高を変更する変更処理を実行する残高変更手段と、を有するＩＣチップに接続可能な携帯端末に、
前記残高記憶手段に記憶される残高を増額させる残高変更情報をチップ側記憶手段に記憶させる保存命令を情報処理サーバから取得する取得機能と、
前記取得機能により取得される保存命令に従い前記残高変更情報が前記チップ側記憶手段に記憶されるよう、該保存命令を前記ＩＣチップに転送する転送機能と、
前記ＩＣチップ側記憶手段に記憶される残高変更情報を用いて変更処理を実行させる実行指示を、所定のタイミングで前記ＩＣチップに出力する指示機能と、
を実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2012/072275 WO2014033939A1 (ja) | 2012-08-31 | 2012-08-31 | 携帯端末、携帯端末の制御方法、プログラム及び記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2014033939A1 true JPWO2014033939A1 (ja) | 2016-08-08 |
| JP6069328B2 JP6069328B2 (ja) | 2017-02-01 |
Family
ID=50182785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014532703A Active JP6069328B2 (ja) | 2012-08-31 | 2012-08-31 | 携帯端末、携帯端末の制御方法、プログラム及び記録媒体 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US10977625B2 (ja) |
| JP (1) | JP6069328B2 (ja) |
| WO (1) | WO2014033939A1 (ja) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9002322B2 (en) | 2011-09-29 | 2015-04-07 | Apple Inc. | Authentication with secondary approver |
| US9324067B2 (en) | 2014-05-29 | 2016-04-26 | Apple Inc. | User interface for payments |
| JP6398561B2 (ja) * | 2014-10-02 | 2018-10-03 | 凸版印刷株式会社 | 移動端末装置、無線通信システム、及び無線通信方法 |
| US9940637B2 (en) | 2015-06-05 | 2018-04-10 | Apple Inc. | User interface for loyalty accounts and private label accounts |
| US20160358133A1 (en) | 2015-06-05 | 2016-12-08 | Apple Inc. | User interface for loyalty accounts and private label accounts for a wearable device |
| US20190096155A1 (en) * | 2016-03-10 | 2019-03-28 | Nec Corporation | Electronic value management apparatus, electronic value management system, electronic value management method, and non-transitory storage medium |
| DK179186B1 (en) | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
| US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
| DK201670622A1 (en) | 2016-06-12 | 2018-02-12 | Apple Inc | User interfaces for transactions |
| US9842330B1 (en) * | 2016-09-06 | 2017-12-12 | Apple Inc. | User interfaces for stored-value accounts |
| US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| US11221744B2 (en) | 2017-05-16 | 2022-01-11 | Apple Inc. | User interfaces for peer-to-peer transfers |
| KR102594156B1 (ko) | 2017-05-16 | 2023-10-26 | 애플 인크. | 피어 투 피어 전송들을 위한 사용자 인터페이스들 |
| WO2019026442A1 (ja) | 2017-08-02 | 2019-02-07 | フェリカネットワークス株式会社 | 情報処理装置、および情報処理方法 |
| KR102143148B1 (ko) | 2017-09-09 | 2020-08-10 | 애플 인크. | 생체측정 인증의 구현 |
| KR102185854B1 (ko) | 2017-09-09 | 2020-12-02 | 애플 인크. | 생체측정 인증의 구현 |
| US11100498B2 (en) | 2018-06-03 | 2021-08-24 | Apple Inc. | User interfaces for transfer accounts |
| KR102634632B1 (ko) | 2018-06-03 | 2024-02-08 | 애플 인크. | 트랜스퍼 계정들을 위한 사용자 인터페이스들 |
| US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
| CN109285001A (zh) * | 2018-08-31 | 2019-01-29 | 阿里巴巴集团控股有限公司 | 可支付交通费用的设备、组合设备、系统及方法 |
| US11328352B2 (en) | 2019-03-24 | 2022-05-10 | Apple Inc. | User interfaces for managing an account |
| US11169830B2 (en) | 2019-09-29 | 2021-11-09 | Apple Inc. | Account management user interfaces |
| EP4300277A3 (en) | 2019-09-29 | 2024-03-13 | Apple Inc. | Account management user interfaces |
| JP7287243B2 (ja) * | 2019-11-08 | 2023-06-06 | トヨタ自動車株式会社 | ウォレットシステムおよびウォレットプログラム |
| US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09330365A (ja) * | 1996-06-11 | 1997-12-22 | Toshiba Software Eng Kk | 電子マネーカードシステム |
| JP2006221462A (ja) * | 2005-02-10 | 2006-08-24 | Ntt Docomo Inc | サービス利用者装置、サービス提供者装置、課金管理装置、ネットワーク接続サービスシステム、及びネットワーク接続サービスにおける課金方法。 |
| JP2008041025A (ja) * | 2006-08-10 | 2008-02-21 | Bitwallet Inc | アクセス端末、管理サーバ、アクセス方法、及び無効端末ｉｄ送信方法 |
| JP2010009432A (ja) * | 2008-06-27 | 2010-01-14 | Kyocera Corp | 決済システムおよび携帯端末 |
| JP2012043329A (ja) * | 2010-08-23 | 2012-03-01 | Nippon Signal Co Ltd:The | 電子決済システム |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4334247B2 (ja) | 2003-03-07 | 2009-09-30 | ビットワレット株式会社 | 携帯端末装置および電子マネーサーバ |
| CA2430456C (en) * | 2003-05-30 | 2012-10-09 | Coinamatic Canada Inc. | Offline code based reloading system |
| JP3924555B2 (ja) | 2003-07-04 | 2007-06-06 | 株式会社みずほ銀行 | 電子バリュー管理方法 |
| US7324976B2 (en) * | 2004-07-19 | 2008-01-29 | Amazon Technologies, Inc. | Automatic authorization of programmatic transactions |
| JP2006221295A (ja) * | 2005-02-09 | 2006-08-24 | Sharp Corp | 電子マネーシステム、携帯端末装置、及びプログラム |
| JP2007079821A (ja) * | 2005-09-13 | 2007-03-29 | Daiichikosho Co Ltd | 電子マネー決済端末、自動入金管理装置 |
| US8879986B2 (en) * | 2005-12-31 | 2014-11-04 | Michelle Fisher | Wireless bidirectional communications between a mobile device and associated secure element using inaudible sound waves |
| JP4483891B2 (ja) * | 2007-04-02 | 2010-06-16 | フェリカネットワークス株式会社 | 情報処理端末、データ移動方法、およびプログラム |
| JP5156254B2 (ja) * | 2007-04-17 | 2013-03-06 | 楽天株式会社 | 情報処理装置、情報処理方法、及び情報処理プログラム |
| JP5130506B2 (ja) * | 2007-05-16 | 2013-01-30 | ネッツエスアイ東洋株式会社 | 電子マネー決済システム、及び電子マネー決済方法 |
| JP2009237831A (ja) * | 2008-03-26 | 2009-10-15 | Dainippon Printing Co Ltd | Ｉｃカードチャージシステム、サーバ、プログラム |
| US8181867B1 (en) * | 2009-01-06 | 2012-05-22 | Sprint Communications Company L.P. | Transit card credit authorization |
| JP5573103B2 (ja) * | 2009-10-30 | 2014-08-20 | 大日本印刷株式会社 | 電子マネーシステム |
| US8600882B2 (en) * | 2011-03-18 | 2013-12-03 | Bank Of America Corporation | Prepaid card budgeting |
-
2012
- 2012-08-31 JP JP2014532703A patent/JP6069328B2/ja active Active
- 2012-08-31 WO PCT/JP2012/072275 patent/WO2014033939A1/ja active Application Filing
- 2012-08-31 US US14/424,083 patent/US10977625B2/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09330365A (ja) * | 1996-06-11 | 1997-12-22 | Toshiba Software Eng Kk | 電子マネーカードシステム |
| JP2006221462A (ja) * | 2005-02-10 | 2006-08-24 | Ntt Docomo Inc | サービス利用者装置、サービス提供者装置、課金管理装置、ネットワーク接続サービスシステム、及びネットワーク接続サービスにおける課金方法。 |
| JP2008041025A (ja) * | 2006-08-10 | 2008-02-21 | Bitwallet Inc | アクセス端末、管理サーバ、アクセス方法、及び無効端末ｉｄ送信方法 |
| JP2010009432A (ja) * | 2008-06-27 | 2010-01-14 | Kyocera Corp | 決済システムおよび携帯端末 |
| JP2012043329A (ja) * | 2010-08-23 | 2012-03-01 | Nippon Signal Co Ltd:The | 電子決済システム |
Also Published As
| Publication number | Publication date |
|---|---|
| US20150324763A1 (en) | 2015-11-12 |
| JP6069328B2 (ja) | 2017-02-01 |
| US10977625B2 (en) | 2021-04-13 |
| WO2014033939A1 (ja) | 2014-03-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6069328B2 (ja) | 携帯端末、携帯端末の制御方法、プログラム及び記録媒体 | |
| US11004061B2 (en) | Method and apparatus for payments between two mobile devices | |
| JP5595434B2 (ja) | 情報処理サーバ、情報処理方法、情報処理プログラム及び情報処理プログラムを記録した記録媒体 | |
| JP5788610B2 (ja) | 携帯端末、携帯端末の制御方法、及び記録媒体 | |
| JP5156254B2 (ja) | 情報処理装置、情報処理方法、及び情報処理プログラム | |
| JP5492181B2 (ja) | 電子マネーサーバ、電子マネーサーバプログラム、記録媒体、及び、紛失処理方法 | |
| JP6062441B2 (ja) | 貨幣端末、貨幣端末の制御方法及びプログラム | |
| JP6182527B2 (ja) | 決済端末、情報処理サーバ、決済端末の制御方法、及びプログラム | |
| WO2014103543A1 (ja) | 情報アクセス装置、コンピュータプログラム、情報処理システム、アクセス制御システム、携帯端末、携帯端末の制御方法、及び携帯端末の制御プログラム | |
| JP5815139B2 (ja) | 情報配信装置、情報配信方法、プログラム及び記録媒体 | |
| JP6211619B2 (ja) | 情報処理装置、情報処理装置の制御方法及びプログラム | |
| JP5178267B2 (ja) | Ｉｃカードおよびｉｃカードに用いられるアプリケーションプログラムの制御方法 | |
| JP5608308B1 (ja) | 情報アクセス装置、コンピュータプログラム、アクセス制御システム、携帯端末、携帯端末の制御方法、及び携帯端末の制御プログラム | |
| US20080272187A1 (en) | Electronic Money System, Information Storage Medium, and Mobile Terminal Device | |
| JP4957483B2 (ja) | 電子マネーチャージシステム、電子マネーチャージ管理サーバおよび携帯情報端末 | |
| JP2008107891A (ja) | 金額変更情報送信装置、貨幣端末、金額変更情報送信方法、及び金額変更方法 | |
| JP5586287B2 (ja) | 決済システムおよび決済方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20150831 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160426 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160627 |
|
| 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: 20161202 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20161226 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6069328 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| 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 |
|
| 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 |