JP6748700B2 - 携帯端末、プログラム、処理方法、情報処理装置 - Google Patents

Description

本発明は携帯端末、プログラム、電子マネー使用停止方法、情報処理装置に係り、電子マネーサービスで適用できる電子マネーの使用停止のための技術に関する。

例えばスマートフォンなどの携帯端末内に電子マネー使用のためのＩＣチップが装備され、これによって携帯端末のユーザが電子マネーサービスを享受できるようにすることが従来行われている。
このような電子マネーサービスでは、ユーザがチャージした金額がＩＣチップに残高として記憶され、使用に伴って残高が更新されていく。この場合、もし携帯端末を紛失したときは、ユーザにとっては残高として記憶されている金額をなくしたことと同様となり、また、残高として記憶されている金額を、他人によって不正使用される恐れがある。
このため携帯端末を紛失したときなどの補償や不正使用を防止するための技術が、例えば下記特許文献１などに提案されている。

特許第５３５１９５３号公報

上記特許文献１においては、ユーザが予め設定したＰＩＮ（Personal Identification Number：認証情報）コードを用いることによって、紛失した携帯端末内に内蔵されるＩＣチップにロックをかけ、ロックをかけた直前からロック解除時までの残高を読み取ることでリアルタイムに残高を把握し、補償額を決定することについての記載がある。
また、不正使用防止については、例えばユーザの申請に応じて、店舗側で携帯端末を用いた決済を不可とする仕組みがある。例えば電子マネーサービスによる支払いができない携帯端末について、その電子マネーサービスで用いる識別情報（電子マネーＩＤ）を特定して店舗側に提供する。リーダ／ライタ側では該当する電子マネーＩＤの端末装置を検知した場合は支払い処理ができないものとする。
もちろん不正使用をより確実に防止するためには、店舗側だけでなく携帯端末側でも使用不可状態とすることが望ましく、このためにＩＣチップにおいて当該電子マネーサービスに関する情報を全て消去することで、使用できないようにすることも行われている。

ここで、紛失時等における携帯端末側の処理を考えると、より迅速に使用停止のための処理を行うことが望ましい。さらには、ＩＣチップを完全に当該電子マネーサービスで使用できないものとしてしまうことは資源の無駄に繋がる。例えば紛失した携帯端末がその後に見つかった場合などに、電子マネーサービスを再開できないことは適切とはいえない。

そこで本発明では、携帯端末側の処理として、迅速に使用停止状態とすることができ、かつＩＣチップを再使用できるようにもしておく技術を提案する。

本発明に係る携帯端末は、電子マネーサービスにおける識別情報と、残高情報と、使用可否を示すステータス情報を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップと、外部の電子マネーサービス管理サーバからの停止指示を受信することに応じて、スリープ中に前記ＩＣチップにおけるステータス情報を使用不可に書き換える第１停止処理を行う第１停止処理部と、前記ＩＣチップにおける識別情報と残高情報を初期化する第２停止処理を行う第２停止処理部とを備える。
即ち第１停止処理では使用不可とするために単にステータス情報を更新するのみとし、第２停止処理において情報の初期化を行う。初期化とは記憶された情報を消去して再使用可能な初期の状態に戻すことである。

上記した携帯端末においては、前記停止指示は前記電子マネーサービス管理サーバ側からのプッシュ通知により送信されてくることが考えられる。
即ち電子マネーサービス管理サーバが例えばＰＮＰ（Push Notification Platform）を用いて該当する携帯端末にプッシュ通知を送信する。

上記した携帯端末においては、スリープ中に前記停止指示が受信された場合は前記第１停止処理を行い、スリープ中には前記第２停止処理は実行しないことが考えられる。
つまりスリープ中に停止指示があったら、取り急ぎ第１停止処理のみを行い、第２停止処理は、少なくともスリープ解除による電源オン後の処理として実行を待機する

上記した携帯端末においては、電子マネー用アプリケーションプログラムがインストールされることで前記第１停止処理部、前記第２停止処理部の一方又は両方が具備されるものとされ、前記第１停止処理は、前記電子マネー用アプリケーションプログラムがユーザ操作に応じて起動された状態でなくてもバックグラウンド処理により実行可能とされていることが考えられる。
例えばスリープ中や、電源オンで電子マネー用アプリケーションプログラムが起動されていない時であっても、少なくとも第１停止処理は実行されるようにする。

上記した携帯端末においては、前記第２停止処理は、前記電子マネー用アプリケーションプログラムがユーザ操作に応じて起動された状態で実行されることが考えられる。
例えばスリープ中などに第１停止処理が行われた後は、電子マネー用アプリケーションプログラムが起動されることで、第２停止処理が行われるようにする。

上記した携帯端末においては、前記電子マネー用アプリケーションプログラムがユーザ操作に応じて起動されているときに前記停止指示が受信された場合は、前記第１停止処理と前記第２停止処理を実行することが考えられる。
例えば第１停止処理と第２停止処理を連続して実行する。

本発明に係るプログラムは、電子マネーサービスにおける識別情報と、残高情報と、使用可否を示すステータス情報を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップが装備される携帯端末における制御部に、上記のように第１停止処理と第２停止処理を実行させるプログラムである。
このようなプログラムを例えば電子マネーサービスに用いるアプリケーションプログラムなどとして携帯端末に提供することで、携帯端末の紛失時等に適切な処理を実行させることができる。

本発明に係る電子マネー使用停止のための処理方法は、携帯端末における制御部が実行する電子マネー使用停止方法として、上記の第１停止処理としてのステップと第２停止処理としてのステップを行う。
例えば上述のプログラムに従って携帯端末の制御部が第１停止処理、第２停止処理を実行する。

本発明に係る情報処理装置は、電子マネーサービスの使用停止要請に応じて、使用停止の対象となる電子マネーサービスにおける識別情報を特定する特定部と、電子マネーサービスにおける識別情報と、残高情報と、使用可否を示すステータス情報を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップを備えた携帯端末であって、前記特定部が特定した識別情報が記憶された携帯端末に対して、停止指示を送信する停止指示送信部と、を備え、前記停止指示は、前記ＩＣチップにおけるステータス情報を使用不可に書き換える第１停止処理と、前記ＩＣチップにおける識別情報と残高情報を初期化する第２停止処理と、を指示する情報であるとする。
即ち電子マネーサービスを提供するサービス管理サーバとして、上述の携帯端末、プログラムに適切な停止指示を与える管理を行う。

本発明によれば、例えば携帯端末の紛失時などに、携帯端末側において迅速に使用停止状態とすることができ、かつＩＣチップを再使用できる状態にしておくことができるという効果がある。

本発明の実施の形態の電子マネーサービスのシステム構成の説明図である。 実施の形態の携帯端末及びサービス管理サーバの機能構成のブロック図である。 実施の形態の携帯端末のハードウエア構成のブロック図である。 実施の形態のサービス管理サーバ及び店舗端末のハードウエア構成のブロック図である。 実施の形態のサービス管理サーバ及び携帯端末の処理のフローチャートである。 実施の形態のＩＣチップ内の情報更新の説明図である。 実施の形態の携帯端末のスリープ中の処理のフローチャートである。 実施の形態の携帯端末の電源オンでアプリケーション未起動時の処理のフローチャートである。 実施の形態の携帯端末のアプリケーション起動時の処理のフローチャートである。

以下、実施の形態を説明するが、携帯端末とは、例えばスマートフォン等、ユーザが携帯して使用する機器であり、その携帯端末の状態として「スリープ」「電源オン」及びプログラム（アプリケーション）の「起動」の用語は次の意味で用いる。

「スリープ」とは、携帯端末が完全に電源オフとされずにいわゆるスリープモードの状態にあることを指す。例えば携帯端末の画面表示を停止させ、意図しないタッチ操作や、余計なバッテリー消費を抑える状態である。スリープ中でも、必要な処理や通信はバックグラウンドで継続して実行される。
「電源オン」は、上記のスリープを解除して通常の使用状態にすることを指すこととする。
プログラムの「起動」とは、ユーザがアプリケーションプログラムを使用するために行う起動操作や何らかのプログラムによる自動的な起動指示などに応じて当該プログラムによる処理が開始されることを言う。例えばアプリケーションプログラムによる画面表示や各種処理が実行される。スリープに移行する前に起動されていたことなどにより電源オンとされたときにすでに起動されている場合も含む。これは本明細書での説明上の区別のためのもので、バックグラウンド処理はプログラムがユーザの操作により「起動」されていなくても行われるという意味を明確にするための用語定義である。

＜システム構成＞
図１により実施の形態の電子マネーサービスシステムの構成を説明する。
電子マネーサービスシステムは、電子マネーサービス管理サーバ（以下「サービス管理サーバ」ともいう）１、ネットワーク２、店舗端末３、携帯端末５、各種データベース６（以下、データベースについては「ＤＢ」と表記する）を有する。
サービス管理サーバ１、店舗端末３、携帯端末５はネットワーク２により相互に通信可能とされている、

ネットワーク２の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
またネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。

サービス管理サーバ１は、例えば電子マネーサービスを提供する組織が運営するサーバであり、電子マネーサービスシステムを統括管理するための各種処理を行う情報処理装置である。
例えばサービス管理サーバ１は、電子マネーサービスに参加する店舗の管理や通信処理、電子マネーサービスを利用するユーザの申請等の受付や登録や管理のための処理、電子マネーにおける残高情報であるバリューの流通を管理する処理、各ユーザの電子マネーによる支払いに対応した決済のための処理などを行う。
本実施の形態の場合、サービス管理サーバ１は後述するように、携帯端末５を紛失等したユーザからの要請に応じて、携帯端末５による電子マネーの使用停止のための処理を行うことになる。

またサービス管理サーバ１は例えばＰＮＰを用いてサービスを利用する携帯端末５にプッシュ通知を送信することができる。

サービス管理サーバ１は電子マネーサービスのための処理において、各種のＤＢ６の情報の参照や更新を行う。図では管理ＤＢ６Ａ、決済用ＤＢ６Ｂを例示している。
管理ＤＢ６Ａは、電子マネーサービスの利用ユーザや参加店舗の情報を格納する。

本例の場合、電子マネーサービスにおいてユーザからの一の使用申し込み（一の使用エントリ）に対して固有に発行される識別情報として電子マネーＩＤ（Identification）が用いられるが、管理ＤＢ６Ａには、この電子マネーＩＤとユーザＩＤを紐づける情報が記憶される。ユーザＩＤは、ユーザの個人情報を管理する識別情報である。個人情報とは、例えば氏名、住所、年齢、性別、連絡先（電話番号やメールアドレス等）、クレジットカード番号、口座番号、決済方法、使用する端末（携帯端末５や他の端末）の情報などである。これにより、例えば携帯端末５を紛失したユーザがユーザＩＤを用いて他の端末や電話連絡などにより使用停止を申請してきたときに、サービス管理サーバ１はユーザＩＤから、使用停止すべき電子マネーＩＤを特定することができる。

決済ＤＢ６Ｂは、電子マネーの使用に対する決済処理のために必要な情報を格納している。例えば決済ＤＢ６Ｂには、各ユーザや店舗に対応して、決済のための使用ログ、決済額、決済履歴、その他各種の必要な情報が格納され、サービス管理サーバ１が参照や更新できるようにしている。

図示以外にも各種の必要なＤＢが用いられる。例えばバリューの更新に関するＤＢ、サービス管理サーバ１や店舗端末３側で使用停止処理を行った電子マネーＩＤの管理を行うＤＢなどである。

これらの各ＤＢ６は、サービス管理サーバ１がアクセス可能とされていればどのような形態で実現されていてもよい。例えばサービス管理サーバ１と同一システム内の記憶部に各ＤＢ６のすべてが形成されていてもよいし、各ＤＢ６の一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢ６が一つの装置（例えば一つのＨＤＤ（Hard Disk Drive）等）内に形成されている必要はない。また各ＤＢ６のそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えば管理ＤＢ６Ａとして記憶される情報が、複数のＤＢにより記憶管理されてもよい。上記の各ＤＢ６は、実施の形態の処理に関連する情報の記憶部を、それぞれ１つのＤＢとして例示したものに過ぎない。

店舗端末３は、電子マネーサービスに参加する店舗（加盟店）の情報処理装置である。
加盟店は、小売店舗や飲食店等のユーザから対価を取って商品やサービスを提供する事業者である。これらの加盟店は、サービス管理サーバ１が提供する電子マネーサービスを利用する連合体に加盟しており、単数又は複数の店舗端末３を備えている。

店舗端末３には、携帯端末５に装備されている、後述するＩＣチップ７０と近距離無線通信を行い、電子マネーにより支払いのための処理を行うリーダ／ライタ３１が装備又は接続されている。
携帯端末５を所持するユーザは、買い物や食事の際に、携帯端末５をレジ付近に置かれたリーダ／ライタ３１に近接させることで、支払いを済ますことができる。この際、携帯端末５内のＩＣチップ７０に記憶された電子マネーＩＤやバリューがリーダ／ライタ３１に読み取られ、また使用金額に応じてバリューが更新される。

携帯端末５は、例えばスマートフォン等の携帯型の情報処理装置であり、特に本実施の形態の場合、携帯端末５は後述のように電子マネーサービス用のＩＣチップ７０が内蔵され、サービス管理サーバ１への登録申請によって電子マネーＩＤが発行されることで、電子マネー媒体として用いることができる機器である。
携帯端末５は、ネットワーク６を通じてサービス管理サーバ１と通信を行うことができ、また内蔵のＩＣチップ７０により上述のようにリーダ／ライタ３１との非接触近距離無線通信を行う。

図２に携帯端末５及びサービス管理サーバ１の機能構成を示す。
携帯端末５は、端末機能部１０とＩＣチップ機能部２０を備える。
端末機能部１０は、情報処理装置としての携帯端末５の主たる機能を包括的に示しており、ＯＳ（Operating System）や各種のアプリケーションプログラムに基づいて各種の処理を行う機能を示している。
特に本実施の形態の場合、電子マネー用アプリケーションプログラム１１（以下、単に「アプリケーション１１」と表記する）がインストールされており、端末機能部１０はこのアプリケーション１１に従った処理を行う。
ユーザは携帯端末５においてアプリケーション１１を起動することで、電子マネーの残高（バリュー）を確認したり、チャージやポイント変換等の操作を行ったり、電子マネーに関する情報提供を受けたりすることができる。

また本実施の形態の場合、アプリケーション１１により端末機能部１０で発現される機能として、第１停止処理部１１ａ、第２停止処理部１１ｂとしての機能がある。これらは携帯端末５内でＩＣチップ機能部２０による電子マネーの支払いを不能とする処理を行う機能である。
即ち第１停止処理部１１ａは、サービス管理サーバ１からの停止指示を受信することに応じて、ＩＣチップ機能部２０に記憶されたステータスを使用不可に書き換える第１停止処理を行う機能である。
第２停止処理部１１ｂは、ＩＣチップ機能部２０に記憶された電子マネーＩＤとバリューを初期化し、ステータスを使用可能に書き換える第２停止処理を行う機能である。
詳しい処理例は後述する。
なお第１停止処理部１１ａの機能は、ここではアプリケーション１１により実現される機能として示しているが、携帯端末５のＯＳにより実現される機能とすることも考えられる。第２停止処理部１１ｂも同様である。

ＩＣチップ機能部２０は、後に図３で説明するＩＣチップ７０により実現される機能を示すものである。
ＩＣチップ機能部２０はチップ処理部２１、チップ記憶部２２としての機能を有する。
チップ記憶部２２には、電子マネーの使用に必要な情報が記憶される。具体的には例えば図６Ａに示すように、固有の識別情報である電子マネーＩＤ、残高情報であるバリュー、使用可否の状態を示すフラグ情報であるステータスが記憶される。
チップ処理部２１は、リーダ／ライタ３１との通信において、電子マネーＩＤ、バリュー、ステータスを送信したり、リーダ／ライタ３１によるバリューの更新要求に応じてバリューの更新処理を行う。またチップ処理部２１はアプリケーション１１の指示に応じてチップ記憶部２２の情報を読み出したり、更新したり、管理する処理を行う。

携帯端末５にインストールされたアプリケーション１１は、チップ記憶部２２に記憶させた電子マネーＩＤを用いてサービス管理サーバ１と通信を行い、当該電子マネーＩＤで特定されるエントリ（ユーザ及び携帯端末５の組）について使用履歴やバリューの情報、ステータスの情報を逐次サービス管理サーバ１に送信することもできる。

図２においてサービス管理サーバ１については、受付部８１、特定部８２、停止指示送信部８３としての機能を示している。
受付部８１は携帯端末５のユーザからのサービス利用に関する各種申請等を受け付ける処理を行う。本実施の形態においては受付部８１は、電子マネーの使用停止の申請を受け付ける処理を行う。例えば電子マネーサービスのウェブサイトを用いたユーザからの申請に応じて、申請内容の情報の取得やユーザＩＤの特定などの処理を行う。あるいは電話等によるオフラインの申請に関して、オペレータによる情報入力の受付処理を行う。

特定部８２は、上記の申請により使用停止する電子マネーＩＤを特定する処理を行う。例えば管理ＤＢ６Ａを参照して、使用停止申請に係るユーザＩＤに対応する電子マネーＩＤを取得する。

停止指示送信部８３は、特定部８２が特定する電子マネーＩＤが使用停止となるように、携帯端末５側での処理を実行させるための停止指示を、携帯端末５に送信する処理を行う。具体的にはＰＮＰを用いてプッシュ通知を該当の携帯端末５に送信する。

図３には携帯端末５としてのハードウエア構成例を示している。
携帯端末５は、主な物理的な構成要素としてＣＰＵ（Central Processing Unit）５１、ＲＡＭ（Random Access Memory）５２、ＲＯＭ（Read Only Memory）５３、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）５４、入力部５６、出力部５７、無線通信部５８、ＩＣチップ７０を有する。
これらの各部はバス６０を介して通信可能とされている。

ＣＰＵ５１は、ＲＯＭ５２に記憶されているプログラム、またはＥＥＰ−ＲＯＭ５４等からＲＡＭ５３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ５３にはまた、ＣＰＵ５１が各種の処理を実行する上において必要なデータなども適宜記憶される。

入力部５６は携帯端末５に設けられたボタン操作子や表示画面に配置されたタッチパネルなどとして実現される。
出力部５７は、例えばＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどにより構成される。
無線通信部５８はネットワーク２を介しての通信処理や機器間通信を行う。

この携帯端末５では、無線通信部５８による通信によりデータやプログラムのアップロード、ダウンロードが行われる。また図示していないがメモリカード等のリムーバブルメディアのスロットが設けられることで、メモリカードを介したデータやプログラムの受け渡しが可能である。

ＣＰＵ５１が各種のプログラムに基づいて処理動作を行うことで、図２に示した端末機能部１０としての必要な情報処理や通信が実行される。
同様にアプリケーション１１による機能もＣＰＵ５１の処理として実現される。即ちインストールされたアプリケーション１１が起動されてＣＰＵ５１がアプリケーション１１に基づく処理を実行することで、アプリケーション１１で規定された必要な機能が実現される。また起動されていなくともＣＰＵ５１によるバックグラウンド処理としてアプリケーション１１で規定される処理が行われる場合もある。

図３に示すようにＩＣチップ７０は、ＣＰＵ７１、ＲＯＭ７２、ＲＡＭ７３、ＥＥＰ−ＲＯＭ７４等を備えたコンピュータとしての機能を有している。
またＩＣチップ７０は近距離無線通信用のアンテナを含む非接触通信部７５を有している。
例えば図２のチップ記憶部２２は、例えば図３のＥＥＰ−ＲＯＭ７４の記憶領域を用いて実現される。

また図２のチップ処理部２１は図３のＣＰＵ７１による処理機能として実現される。
ＣＰＵ７１は非接触通信部７５によりリーダ／ライタ３１との無線通信を行い必要な情報の授受を行うとともに、ＥＥＰ−ＲＯＭ７４におけるチップ記憶部２２の情報の読出／書込（更新）を行う。
またＩＣチップ７０のＣＰＵ７１はＣＰＵ５１と通信することで各種の動作を行う。例えばＣＰＵ５１からの指示に応じてＥＥＰ−ＲＯＭ７４におけるチップ記憶部２２の情報の読出／書込（更新）を行う。

続いて図４はサービス管理サーバ１や店舗端末３として実現される情報処理装置（コンピュータ装置）のハードウエア構成例を示している。
図４において、情報処理装置のＣＰＵ１０１は、ＲＯＭ１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インタフェース１０５も接続されている。
入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９が接続されている。

入力部１０６はキーボード、マウス、タッチパネルなどにより構成される。
出力部１０７はＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどにより構成される。
記憶部１０８はＨＤＤやフラッシュメモリ装置などにより構成される。
通信部１０９はネットワーク２を介しての通信処理や機器間通信を行う。

入出力インタフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

なお店舗端末３としての情報処理装置の場合には、リーダ／ライタ３１が内蔵又は接続される。リーダ／ライタ３１は近距離無線通信により携帯端末５のＩＣチップ７０と通信可能とされる。

このような情報処理装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。またリムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、サービス管理サーバ１や店舗端末３としての必要な情報処理や通信が実行される。

なお、サービス管理サーバ１や店舗端末３としては、図４のような構成の情報処理装置が単一で構成されることに限らず、複数の情報処理装置がシステム化されて構成されてもよい。複数の情報処理装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群（クラウド）としての情報処理装置が含まれてもよい。

＜電子マネー使用停止の処理＞
本実施の形態の電子マネーサービスシステムでは、ユーザが携帯端末５を紛失した際などは、当該ユーザが申請することに応じて、その紛失した携帯端末５による電子マネーの使用ができなくなるようにする。

まず、この処理の概要を説明する。
サービス管理サーバ１は、ユーザからの申請に基づいて、ユーザＩＤを鍵に当該ユーザが有する電子マネーＩＤを特定する。そして当該電子マネーＩＤを有する携帯端末５に、ＰＮＰを用いてプッシュ通知を停止指示として送る。
携帯端末５では当該プッシュ通知に応じて、第１停止処理部１１ａの機能により、携帯端末５内のＩＣチップ７０に記憶されたステータスを使用不可の状態にする。
また何らかの方法により、紛失された携帯端末５内でアプリケーション１１が起動されると、第２停止処理部１１ｂの機能により、ＩＣチップ７０に記憶された電子マネーＩＤ及びバリューの情報を初期化し、ステータスを使用可能の状態に更新する。
これにより、当該携帯端末５（ＩＣチップ７０）は、新たな電子マネーＩＤを付与されることで、新たな電子マネーＩＤに紐付いた、残高０円のアクティブな電子マネー媒体として改めて使用することが可能となる。

なお携帯端末５を紛失したユーザが別の新たな携帯端末５で再度電子マネーサービスを利用する際には、新規の電子マネー媒体として新しく電子マネーＩＤを付与し、新しい電子マネーＩＤに対して、ユーザＩＤと旧電子マネーＩＤを照合し、当該ユーザの旧電子マネーＩＤに紐付いていた残高を充当することもできる。これによりユーザは紛失した携帯端末５に蓄積していた残高を引き継ぐことも可能である。

また、本実施の形態で停止指示としてプッシュ通知を送信するのは、携帯端末５内でＩＣチップ機能部２０の動作を不能とするためのものである。
これは携帯端末５の紛失等の際に、他人によって不正使用されることを、携帯端末５側で防止するためのものである。
紛失等に使用停止の申請があった場合、サービス管理サーバ１側では、例えば該当する電子マネーＩＤをネガティブリストに登録し、このリスト情報を店舗端末３等に配布したり、店舗端末３からの通信による問い合わせに応答することなどにより、店舗端末３側の処置もとられる。

このような店舗端末３側の対応だけでなく、携帯端末５側でも紛失に応じた措置を行うことで例えば携帯端末５を拾った第三者などによる不正使用を強固に防止できる。
以下では、携帯端末５側での不正使用防止、かつ再使用可能とするための処理に注目して説明を続ける。

図５はユーザから使用停止申請があった場合のサービス管理サーバ１の処理と、サービス管理サーバ１からのプッシュ通知に応じた携帯端末５の処理を示している。

サービス管理サーバ１はステップＳ１００でユーザからの使用停止申請の受付処理を行う。例えば当該申請に係るユーザのユーザＩＤの取得、ユーザ認証、その他必要な処理を行う。

ステップＳ１０１でサービス管理サーバ１は電子マネーＩＤを特定する処理を行う。即ちユーザＩＤに紐づけられている電子マネーＩＤを例えば管理ＤＢ６ａを参照して取得し、その電子マネーＩＤを使用停止の対象として特定する。

ステップＳ１０２でサービス管理サーバ１は当該特定した電子マネーＩＤを有する携帯端末５に対して、停止指示としてのプッシュ通知の送信をＰＮＰにより行う。

プッシュ通知は、携帯端末５がスリープ状態であっても受信可能である。またＰＮＰは、携帯端末５がプッシュ通知を受信した場合に送信してくる受信完了通知を確認できる。これによりサービス管理サーバ１側では、プッシュ通知が該当の携帯端末５に受信されたか否かを確認できる。
もし、プッシュ通知の受信が確認できない場合、サービス管理サーバ１はステップＳ１０３からＳ１０２に戻る。即ちサービス管理サーバ１側は、携帯端末５側での受信が確認されるまでプッシュ通知を繰り返し送信することになる。携帯端末５側での受信が確認できたらサービス管理サーバ１は処理を終える。
これにより、該当の携帯端末５にプッシュ通知を送信できる可能性を高める。

なお、プッシュ通知の受信確認及び再送信は、サービス管理サーバ１としての情報処理装置とは独立した情報処理装置に構成されるＰＮＰが行うことも想定されるが、そのようなＰＮＰもサービス管理サーバ１に含むものとして説明している。

プッシュ通知を送られた側の携帯端末５では、ステップＳ２００でプッシュ通知の受信処理を行う。例えばＣＰＵ５１（端末機能部１０）はプッシュ通知の情報内容を取り込み、その通知内容が停止指示であることを確認する。

そして携帯端末５はステップＳ２０１で第１停止処理部１１ａの機能による第１停止処理を実行する。
この第１停止処理では、ＩＣチップ７０に記憶されたステータスの値を使用不可の状態に更新する。
例えば紛失時の情報が図６Ａのように、電子マネーＩＤが「０１２３４５６７」、バリューが例えば１５０５円を表す「１５０５」、ステータスが「１」であったとする。ステータスは「１」が使用可能、「０」が使用不可を示すフラグ情報であるとする。
第１停止処理では、このような情報のうちのステータスを「０」に更新して、図６Ｂの状態とすることになる。

この第１停止処理は、スリープ中であっても実行される。即ちスリープ中にプッシュ通知を受信することに応じて、ＯＳ又はアプリケーション１１のバックグラウンド処理として、第１停止処理が実行される。
スリープが解除された電源オン状態であってアプリケーション１１が起動されていない時にプッシュ通知を受信した場合でも同様に、ＯＳ又はアプリケーション１１のバックグラウンド処理として、第１停止処理が実行される。
もちろんアプリケーション１１が起動されているときにプッシュ通知を受信した場合は、アプリケーション１１又はＯＳの機能として第１停止処理を行うことができる。

以上の第１停止処理を行った後に、ステップＳ２０２で携帯端末５は、第２停止処理部１１ｂの機能による第２停止処理を実行する。
この第２停止処理は、ＩＣチップ７０に記憶された内容を初期化しつつ、再使用可能とする処理である。
例えば図６Ｂのようにステータスが「０」とされた状態から、図６Ｃのように、電子マネーＩＤを初期化し、バリューを初期化し、さらにステータスを初期化する。

電子マネーＩＤ、バリュー、ステータスが初期化されることで、元のユーザのバリューは当該携帯端末５上において当然使用できない状態となる。これにより引き続き不正使用できない状態が維持される。
その後、例えばユーザが紛失していた携帯端末５をその後に見つけたとする。ユーザは再登録の申請により新たに電子マネーＩＤをサービス管理サーバ１に発行してもらうことで、その携帯端末５による電子マネーの使用が可能となる。その場合、情報は図６Ｄのように更新される。例えば電子マネーＩＤが新たに付与された「７６５４３２１０」とされ、バリューが「０」（あるいはクリアが「０」であればそのまま）とされる。ステータスは「１」とされる。これによりユーザがバリューをチャージすれば使用できる状態となる。

ステップＳ２０２の第２停止処理は、スリープ中にプッシュ通知を受信したときは行わないこととする。更新する項目が多く、スリープ中のバックグラウンド処理としての処理負担を過大にしないためである。例えばアプリケーション１１が起動されたときに実行するものとする。
なお、例えば第２停止処理により図６Ｃの状態とするときに、ステータスを「１」としておき、ＩＣチップ７０を電子マネー媒体として使用可能な状態としておいてもよい。

プッシュ通知に応じては携帯端末５において以上のように第１停止処理、第２停止処理が行われる。
但し、より詳細に述べると、プッシュ通知が受信されたときの携帯端末５の状態により、処理手順が異なることになる。以下、スリープ中、電源オンでアプリケーション１１が未起動のとき、アプリケーション１１の起動中に分けて、より具体的な処理例を説明する。

図７はスリープ中にプッシュ通知が受信された場合の処理例を示している。
携帯端末５のＣＰＵ５１はプッシュ通知の受信に応じて、処理をステップＳ３０１からＳ３０２に進め、プッシュ通知の受付処理を行う。即ちＣＰＵ５１はプッシュ通知の情報内容を取り込み、その通知内容が停止指示であることの確認、及びそれらの情報の記憶処理を実行する。

そしてＣＰＵ５１はステップＳ３０３で、バックグラウンド処理が可能であるか否かにより処理を分岐する。例えば携帯端末５の固有の事情、バッテリー状態、ＯＳの事情、スリープ中の動作制限などの何らかの要因で、当該プッシュ通知を受け取った携帯端末５において、現在、第１停止処理部１１ａの機能をバックグラウンド処理として実行できるか否かを確認する。
バックグラウンド処理として実行できなければ、ＣＰＵ５１はプッシュ通知の受付処理のみで処理を終える。
バックグラウンド処理として第１停止処理が実行できるのであれば、ＣＰＵ５１はステップＳ３０４に進み、第１停止処理を実行する。そして図７の処理を終える。

図８はスリープが解除され電源オンとなっているがアプリケーション１１が起動されていない時の処理例を示している。例えばＣＰＵ５１は定期的に図８の処理を繰り返す。この場合、既にプッシュ通知が受信されている場合と、この状態でプッシュ通知を受信する場合が考えられる。

ＣＰＵ５１はステップＳ３１０では、過去（スリープ中）に受信されたプッシュ通知が存在するか否かを確認する。即ちスリープ中に図７のステップＳ３０２の受付処理が行われたか否かの確認である。

もし電源オンの前のスリープ中にプッシュ通知が受信されていたら、ＣＰＵ５１はステップＳ３１２に進み、第１停止処理をすでに実行していたか否かを確認する。
スリープ中にバックグラウンド処理で第１停止処理を実行していたのであれば、ＣＰＵ５１はそのまま図８の処理を終える。
一方、スリープ中にプッシュ通知があっても何らかの理由で第１停止処理が行われていなかったのであれば、ＣＰＵ５１はステップＳ３１４に進み、第１停止処理を実行する。アプリケーション１１は起動していないため、バックグラウンド処理により第１停止処理を実行することになる。そして図８の処理を終える。

なお、実際には以上のステップＳ３１０、Ｓ３１２、Ｓ３１４の処理は電源オンとされたときに１回行えばよい。スリープ中のプッシュ通知の受信に対応する処理であるためである。

一方、スリープ中にプッシュ通知を受信していない場合は、図８の処理においてステップＳ３１１でプッシュ通知の受信を監視する。
プッシュ通知の受信が無ければ、特に処理は行われないが、プッシュ通知の受信があった場合、ＣＰＵ５１はステップＳ３１１からＳ３１３に処理を進め、プッシュ通知の受付処理を行う。図７のステップＳ３０２と同様の処理である。
そしてＣＰＵ５１はステップＳ３１４に進み第１停止処理を実行する。アプリケーション１１は起動していないため、バックグラウンド処理により第１停止処理を実行することになる。そして図８の処理を終える。

図９はアプリケーション１１が起動されている時の処理例を示している。例えばＣＰＵ５１はアプリケーション１１による処理として定期的に図９の処理を繰り返す。

ＣＰＵ５１はステップＳ３２０では、過去（スリープ中もしくは電源オンでアプリケーション１１が未起動のとき）に受信されたプッシュ通知が存在するか否かを確認する。

もしアプリケーション１１が未起動のときにプッシュ通知が受信されていたら、ＣＰＵ５１はステップＳ３２４に進み、第１停止処理をすでに実行していたか否かを確認する。
プッシュ通知が受信済であるのに第１停止処理が行われていなかったら、ＣＰＵ５１はステップＳ３２３に進み第１停止処理を実行する。そしてＣＰＵ５１は続いてステップＳ２５に進み、第２停止処理を実行する。この場合、例えば起動中のアプリケーション１１に基づく処理としてＣＰＵ５１が第１停止処理及び第２停止処理を連続して実行することになる。そして図９の処理を終える。

スリープ中もしくは電源オンでアプリケーション１１が未起動のときにバックグラウンド処理で第１停止処理を既に実行していたと、ステップＳ３２４で判定した場合は、ＣＰＵ５１はステップＳ３２５に進み、第２停止処理を実行する。即ち起動中のアプリケーション１１に基づく処理としてＣＰＵ５１が第２停止処理を実行する。そして図９の処理を終える。

なお、実際には以上のステップＳ３２０、Ｓ３２４、Ｓ３２５の処理は、電源オンでアプリケーション１１が起動されている状態になったときに１回行えばよい。既に受信されているプッシュ通知の受信に対応する処理であるためである。

一方、これまでプッシュ通知を受信していない場合は、図９の処理においてＣＰＵ５１はステップＳ３２１でプッシュ通知の受信を監視することになる。
プッシュ通知の受信が無ければ、特に処理は行われないが、プッシュ通知の受信があった場合、ＣＰＵ５１はステップＳ３２１からＳ３２２に処理を進め、プッシュ通知の受付処理を行う。図７のステップＳ３０２と同様の処理である。
そしてＣＰＵ５１はステップＳ３２３に進み第１停止処理を実行する。さらにＣＰＵ５１はステップＳ３２５に進み第２停止処理を実行する。これらの第１停止処理、第２停止処理は起動中のアプリケーション１１に基づく処理としてＣＰＵ５１が実行することになる。そして図９の処理を終える。

＜まとめ及び変形例＞
以上の実施の形態では次の効果が得られる。
実施の形態の携帯端末５は、電子マネーサービスにおける識別情報である電子マネーＩＤと、残高情報であるバリューと、使用可否を示す情報であるステータスを記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップ７０を備えている。そして携帯端末５は、外部サーバであるサービス管理サーバ１からの停止指示を受信することに応じて、ＩＣチップ７０におけるステータス情報を使用不可に書き換える第１停止処理を行う第１停止処理部１１ａと、ＩＣチップ７０における電子マネーＩＤとバリューとステータスを初期化する第２停止処理を行う第２停止処理部１１ａを備えている。この第１停止処理部１１ａ、第２停止処理部１１ｂとしての機能は例えばアプリケーション１１によりＣＰＵ５１において実現される。
そして、第１停止処理によっては、携帯端末５の状況としてアプリケーション１１が起動されていない状態（スリープ中や電源オンでアプリケーション１１の未起動時）でも、当該携帯端末５による電子マネーの使用ができない状態とすることができ、携帯端末５の紛失時等に迅速に電子マネーが不正使用できない状態にする処理として極めて有効である。
また実施の形態の場合、ステータスの更新は、例えばフラグの更新という簡易な処理としており、電力や時間をさほど要せずに可能である。従って携帯端末５の状態によらず迅速に電子マネーを使用不可状態とすることができる。例えば携帯端末５がスリープ中などでも十分に可能であり、不正使用防止のための緊急性を有する処置として非常に好適である。
また携帯端末５側で使用不可とする処理であるため、仮にリーダ／ライタ３１側が使用停止に対応できていない場合（例えばサービス管理サーバ１によるネガティブリストの提供がまにあわなかった場合など）があったとしても不正使用を防止できることになる。

また第２停止処理によっては、識別情報である電子マネーＩＤと、残高情報であるバリューを初期化することで、完全に残高及び使用資格が抹消され、使用できないものとなるだけでなく、ＩＣチップ７０を再び使用可能とすることができる。
即ち、その後の新たな使用申し込みに応じて、電子マネーＩＤを書き込み、バリューを付与し、ステータスを更新することで、再使用ができる。つまり本実施の形態の処理は、ＩＣチップ７０を以後一切使用不能に情報を破壊するものではなく再使用できる状態にする処理である。
これにより、例えばユーザが携帯端末５を紛失して、一旦、電子マネーサービス会社に使用停止を申請し、これにより第１停止処理、第２停止処理が行われたとしても、その後、携帯端末５が見つかったような場合、再度のサービス利用申請で新たに電子マネーＩＤを取得することで、当該携帯端末５による電子マネーの使用を復活させることができる。
また携帯端末５が例えば中古端末として転売され、第三者が使用することとなった状況でも、当該第三者が電子マネーサービス会社に利用申請し、新たに電子マネーＩＤを取得することで、当該携帯端末５による電子マネーの使用が可能となる。
これらにより携帯端末５あるいはＩＣチップ７０としての資源が正当な使用において有効利用できるという効果ももたらすことになる。
なお第２停止処理については、アプリケーション１１が起動されたときや起動状態にあるときに実行される例を挙げたが、この例に限らず、例えば何らかのユーザアクションをトリガとして開始されるものとしてもよい。
また第２停止処理部１１ａによる第２停止処理の際に、ステータス情報を使用可能に書き換えるようにしてもよい。即ち第２停止処理によっては、識別情報である電子マネーＩＤと、残高情報であるバリューを初期化し、さらにステータスを使用可能に書き換えるようにすることで、その後、新たな使用申し込みに応じて、電子マネーＩＤを書き込み、バリューを付与することで再使用できることになる。

実施の形態ではサービス管理サーバ１からの停止指示はプッシュ通知により送信されてくるものとした。
携帯端末５ではプッシュ通知を受信して停止指示を検知する。プッシュ通知によるものとすることで、携帯端末５がたとえスリープ中であっても、これを受信し、対応して少なくとも第１停止処理が実行できる。即ちアプリケーション起動時、電源オンでアプリケーション非起動時、スリープ時のいずれであっても受信し対応できるため、不正使用防止のための迅速な使用停止が可能となる。
なお、プッシュ通知以外の通信手法により停止指示を送信することも考えられる。スリープ中に通知を行うことのできる通信手法であれば好適である。但し、電源オン中、もしくはアプリケーション１１の起動中にのみ通知を確認できる通信手法も、使用停止処理の迅速性の点では不利となるが、停止指示の送信手法として採用できないものではない。
また図５ではサービス管理サーバ１は、プッシュ通知を携帯端末５側の受信を確認するまで繰り返し行う例としたが、例えばプッシュ通知を１回のみ送信することも考えられる。その場合、サービス管理サーバ１側で第１停止処理の実行を制御するとよい。例えばプッシュ通知送信後においてサービス管理サーバ１は、当該携帯端末５においてアプリケーション１１が起動されることを検知した場合に第１停止処理を実行するように指示を送信する。これにより何らかの事情でのプッシュ通知の未達もしくはプッシュ通知に応じた第１停止処理が実行されていない状況となっていても、第１停止処理を実行させることができる。

実施の形態では、スリープ中に停止指示が受信された場合は第１停止処理を行い、第２停止処理はスリープ中には実行しない例を述べた。即ち第２停止処理は少なくともスリープ解除による電源オン後の処理（より具体的にはアプリケーション１１の起動中の処理）として実行する。
第１停止処理によるステータスの更新はフラグビットの書換という非常に容易かつ大きな電力消費を伴わない処理であるためスリープ中であっても実行するが、第２停止処理については、スリープ中は実行を待機する。これにより不正使用防止のための迅速な使用停止が可能となるとともにスリープ中の処理負担をむやみに増大させないことになる。

実施の形態の携帯端末５は、アプリケーション１１がインストールされることで第１停止処理部、前記第２停止処理部の一方又は両方が具備されるものとされ、第１停止処理は、アプリケーション１１がユーザ操作に応じて起動された状態でなくてもバックグラウンド処理により実行可能とされているものとした（図７、図８参照）。
例えばスリープ中などであっても、バックグラウンド処理により即座に第１停止処理を実行することで、不正使用防止のための迅速な使用停止が可能となる。上述のように第１停止処理によるステータスの更新は、単にフラグビットの書換という非常に容易かつ大きな電力消費を伴わない処理であることで、バックグラウンド処理にも適している。
また第１停止処理部１１ａ、第２停止処理部１１ｂとしての機能は、その両方がアプリケーション１１のインストールにより携帯端末５に組み込まれることが考えられる。これによりユーザは手持ちの携帯端末に、電子マネーサービスの利用に伴ってアプリケーション１１をインストールすることで、第１停止処理、第２停止処理が実行される実施の形態の携帯端末５とすることができる。

なお、例えば第１停止処理部１１ａとしての機能は携帯端末５のＯＳによる処理機能として予め組み込んでおくことも考えられる。また第１停止処理部１１ａ、第２停止処理部１１ｂとしての機能の一方又は両方をＯＳによる機能としたり、アプリケーション１１をプリインストールした携帯端末５をユーザに提供するような形態も考えられる。

実施の形態では、第２停止処理は、アプリケーション１１がユーザ操作に応じて起動された状態で実行されるものとした（図９参照）。
例えばスリープ中などであっても第１停止処理が実行されることで、緊急性を要する使用不可のための処理は完了していることになる。一方で第２停止処理は初期化の意味もあり、処理としては第１停止処理よりも複雑となるため、アプリケーション１１の起動時に実行させることが携帯端末５の処理上、好適となる。
なお、第２停止処理はアプリケーション１１の起動中に行う例を挙げたが、電源オンでアプリケーション１１が未起動のときに行うようにすることも考えられる。

実施の形態では、アプリケーション１１がユーザ操作に応じて起動されているときに停止指示が受信された場合は、第１停止処理と第２停止処理を実行する例を述べた（図９参照）。
アプリケーション１１の起動中であれば、ＩＣチップ７０に対して各種のアクセスや更新が容易に実現できるが、第１停止処理を行うことで、例えばプッシュ通知受信後に極めて迅速に使用不可状態とし、その後に初期化することで、不正使用の防止により好適となる。
なお、アプリケーション１１起動中にプッシュ通知により停止指示があった場合、第１停止処理を行わずに第２停止処理を行うようにする処理例も考えられる。第２停止処理であっても携帯端末５側での使用停止が実現できるためである。

またアプリケーション１１の起動中の処理としては触れなかったが、実際には、第２停止処理を行う前の時点で、その時点のバリューを読み出し、サービス管理サーバ１に通知する処理を行うとよい。そしてその後に第２停止処理を行うようにする。
例えばＣＰＵ５１は、図９のステップＳ３２３の後、及びステップＳ３２４の後には、第１停止処理後において消去されていない電子マネーＩＤとバリューを読み出して、サービス管理サーバ１に送信する処理を行い、その後、ステップＳ３２５の第２停止処理を実行するようにする。
これにより携帯端末５を紛失したユーザにバリューの補償のための情報をサービス管理サーバ１が取得できる。この処理を行う場合、迅速に第１停止処理を行い、その後、第２停止処理を段階的に行うことは非常に好適となる。

実施の形態のサービス管理サーバ１は、電子マネーサービスの使用停止要請に応じて、使用停止の対象となる電子マネーＩＤを特定する特定部８２と、特定部８２が特定した電子マネーＩＤが記憶された携帯端末５に対して、停止指示のプッシュ通知を送信する処理を行う停止指示送信部８３とを備える。そして停止指示は、ＩＣチップ７０におけるステータスを使用不可に書き換える第１停止処理と、ＩＣチップ７０における電子マネーＩＤとバリューを初期化し、ステータスを使用可能に書き換える第２停止処理とを指示する情報である。
これにより、携帯端末５側での使用停止を指示することができ、不正使用の防止効果を高めることができる。またプッシュ通知を送信するという処理であり、処理負担が大きく増大するものでもない。

実施の形態では本発明のプログラムに相当するものとしてアプリケーション１１を示した。このアプリケーション１１は、電子マネーサービスにおける識別情報（電子マネーＩＤ）と、残高情報（バリュー）と、使用可否を示すステータス情報（ステータス）を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップ７０が装備される携帯端末５における制御部（ＣＰＵ５１）に処理を実行させるプログラムである。そしてアプリケーション１１は、ＣＰＵ５１に、サービス管理サーバからの停止指示を受信することに応じて、ＩＣチップ７０におけるステータスを使用不可に書き換える第１停止処理と、ＩＣチップ７０における電子マネーＩＤとバリューを初期化し、ステータスを使用可能に書き換える第２停止処理とを実行させるプログラムである。
即ちこのプログラムは、ＣＰＵ５１に対して図７，図８，図９で説明した処理を実行させるプログラムである。

このようなプログラムにより、汎用の携帯型情報処理装置において実施の形態の携帯端末５を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体から携帯型情報処理装置等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

１ サービス管理サーバ、２ ネットワーク、３ 店舗端末、５ 携帯端末、１０ 端末機能部、１１ アプリケーション、１１ａ 第１停止処理部、１１ｂ 第２停止処理部、２０ ＩＣチップ機能部、２１ チップ処理部、２２ チップ記憶部、３１ リーダ／ライタ、５１，７１，１０１ ＣＰＵ、５２，７２，１０２ ＲＯＭ、５３，７３，１０３ ＲＡＭ、５４，７４ ＥＥＰ−ＲＯＭ、７５ 非接触通信部

Claims (10)

1. 電子マネーサービスにおける識別情報と、残高情報と、使用可否を示すステータス情報を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップと、
   外部の電子マネーサービス管理サーバからの停止指示を受信することに応じて、スリープ中に前記ＩＣチップにおけるステータス情報を使用不可に書き換える第１停止処理を行う第１停止処理部と、
   前記ＩＣチップにおける識別情報と残高情報を初期化する第２停止処理を行う第２停止処理部と、を備えた
   携帯端末。
2. 前記停止指示は前記電子マネーサービス管理サーバ側からのプッシュ通知により送信されてくる
   請求項１に記載の携帯端末。
3. スリープ中に前記停止指示が受信された場合は前記第１停止処理を行い、スリープ中には前記第２停止処理は実行しない
   請求項１又は請求項２に記載の携帯端末。
4. 電子マネー用アプリケーションプログラムがインストールされることで前記第１停止処理部、前記第２停止処理部の一方又は両方が具備されるものとされ、
   前記第１停止処理は、前記電子マネー用アプリケーションプログラムがユーザ操作に応じて起動された状態でなくてもバックグラウンド処理により実行可能とされている
   請求項１から請求項３のいずれかに記載の携帯端末。
5. 前記第２停止処理は、前記電子マネー用アプリケーションプログラムがユーザ操作に応じて起動された状態で実行される
   請求項４に記載の携帯端末。
6. 前記電子マネー用アプリケーションプログラムがユーザ操作に応じて起動されているときに前記停止指示が受信された場合は、前記第１停止処理と前記第２停止処理を実行する
   請求項４又は請求項５に記載の携帯端末。
7. 電子マネーサービスにおける識別情報と、残高情報と、使用可否を示すステータス情報を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップが装備される携帯端末における制御部に処理を実行させるプログラムとして、
   外部の電子マネーサービス管理サーバからの停止指示を受信することに応じて、スリープ中に前記ＩＣチップにおけるステータス情報を使用不可に書き換える第１停止処理と、
   前記ＩＣチップにおける識別情報と残高情報を初期化し、ステータス情報を使用可能に書き換える第２停止処理と、
   を実行させるプログラム。
8. スリープ中に前記停止指示が受信された場合は、前記制御部に前記第１停止処理を実行させ、前記第２停止処理は少なくともスリープ解除による電源オン後の処理として実行を待機させる
   請求項７に記載のプログラム。
9. 電子マネーサービスにおける識別情報と、残高情報と、使用可否を示すステータス情報を記憶し、電子マネーによる支払いのための通信及び情報更新の処理を行うＩＣチップが装備される携帯端末における制御部が実行する電子マネー使用停止のための処理方法として、
   外部の電子マネーサービス管理サーバからの停止指示を受信することに応じて、スリープ中に前記ＩＣチップにおけるステータス情報を使用不可に書き換える第１停止ステップと、
   前記ＩＣチップにおける識別情報と残高情報を初期化する第２停止ステップと、
   を行う処理方法。
10. 前記制御部は、スリープ中に前記停止指示が受信された場合は前記第１停止ステップを行い、スリープ中には前記第２停止ステップは実行しない
    請求項９に記載の処理方法。

Images