JP2018120518A - 電子情報記憶媒体、ｉｃカード、通知方法、及び通知処理プログラム - Google Patents

Abstract

【課題】設定変更の通知中に電源供給遮断が発生したとしても、不整合が発生することなくアプリケーションの動作を保障することを可能とする電子情報記憶媒体、ＩＣカード、通知方法、及び通知処理プログラムを提供する。
【解決手段】携帯端末に搭載された電子情報記憶媒体は、選択中の少なくとも何れか１つのアプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して設定変更されたことを示す情報を通知する通知処理を実行し、且つ通知状況を記録する。そして、電子情報記憶媒体は、上記通知処理中に電源供給が遮断され、当該遮断後に電源供給が復旧した場合、上記通知状況にしたがって、通知処理を再実行する。
【選択図】図７

Description

複数のアプリケーションを搭載するＩＣカード等の技術分野に関する。

複数のアプリケーションを搭載することが可能なＵＩＭ（User Identity Module）カードは、Java（登録商標）Card仕様、及びGlobalPlatform（登録商標）仕様に準拠した製品が事実上のデファクトスタンダードになっている。また、近年、ＵＩＭカードは、従来のＩＣカードで使用されてきた、ISO7816に準拠するインターフェース（ＩＦ）に加え、ＳＷＰ（Single Wire Protocol）のインターフェースを備えたＮＦＣ（Near Field radio Communication）対応ＵＩＭカード（以下、特段の記載が無い場合、本明細書内のＵＩＭカードはＮＦＣ対応ＵＩＭカードを意味する）が普及している。一方、携帯端末においてもＮＦＣ対応携帯端末が普及してきた。ＮＦＣ対応携帯端末（以下、特段の記載が無い場合、本明細書内の携帯端末はＮＦＣ対応携帯端末を意味する）は、ＣＬＦ（ContactLess Front-end）と呼ばれるチップを内蔵しており、ＵＩＭカードとはＳＷＰのインターフェースを介して接続されている。加えて、ＣＬＦには、非接触通信に用いるアンテナが接続され、ＣＬＦは、非接触通信プロトコル処理を担当する。これにより、非接触ＩＣカードリーダにとって、ＵＩＭカードと携帯端末の組合せは、あたかも１枚の非接触ＩＣカードのように振舞う。加えて、ＣＬＦが搬送波を出力することで、ＵＩＭカードと携帯端末の組み合わせで非接触ＩＣカードリーダとして動作し、非接触ＩＣカードと通信することもできる。

このような背景から、ＵＩＭカード内には従来から搭載されていたモバイル通信用の認証アプリケーションに加え、非接触通信を使用するアプリケーション（例えば、決済アプリケーション）を複数搭載し、携帯端末と組み合わせて様々なサービスに用いられつつある。特許文献１には、複数のアプリケーションを切り替えて使用可能なＩＣカードにおいて、TCP/IPとISO7816-4のどちらのプロトコルでも複数アプリケーションを選択できる技術が開示されている。なお、ＵＩＭカードと携帯端末の組合せで、非接触ＩＣカードのように振舞う機能は、カードエミュレーションモードと呼ばれる。

特許第４１８４７５１号

ところで、上述したように、カードエミュレーションモードにおいて、ＵＩＭカードは、アプリケーション毎の通信プロトコル設定を勘案して携帯端末としての通信プロトコル設定を決定する。この携帯端末としての通信プロトコルは、ＵＩＭカード上のアプリケーション毎の設定によって決定されるため、各アプリケーションの設定が変更される度に再設定（再構築）されることになる。このように、あるアプリケーションの設定が他のアプリケーションに影響する可能性があるため、アプリケーションによっては設定が変更された場合の通知を要求する場合がある。しかしながら、設定変更の通知中に、ＵＩＭカードへの電源供給が遮断された場合、あるアプリケーションには通知されたものの、他のアプリケーションには通知されないといった不整合が発生しうる。このような不整合が発生することで、各アプリケーションでは意図した動作が保障されない可能性がある。また、ＵＩＭカードに搭載されるアプリケーションの増加によって通知対象のアプリケーションも増えると、当該通知中に電源供給が遮断されるリスクが高まることも懸念される。

そこで、本発明は、このような点に鑑みてなされたものであり、設定変更の通知中に電源供給遮断が発生したとしても、不整合が発生することなくアプリケーションの動作を保障することを可能とする電子情報記憶媒体、ＩＣカード、通知方法、及び通知処理プログラムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行う電子情報記憶媒体であって、少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録する実行手段と、前記通知処理中に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行する再実行手段と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載の電子情報記憶媒体において、少なくとも何れか１つの前記アプリケーションの設定が変更される場合、設定変更された前記アプリケーションを含む前記複数のアプリケーションの設定に基づいて、それぞれの前記アプリケーションの再設定を行う再設定手段を更に備え、前記実行手段は、前記再設定手段により再設定された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録することを特徴とする。

請求項３に記載の発明は、請求項１または２に記載の電子情報記憶媒体において、前記設定変更から前記通知処理の実行前までの間に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記アプリケーションの設定を変更前の状態に戻す復帰手段を更に備えることを特徴とする。

請求項４に記載の発明は、請求項１乃至３の何れか一項に記載の電子情報記憶媒体において、前記実行手段は、前記通知処理において通知が完了した前記アプリケーションの情報に対応付けて通知完了情報を、前記通知処理の状況として記録し、前記再実行手段は、前記通知完了情報が対応付けられていない前記アプリケーションに対して前記通知処理を再実行することを特徴とする。

請求項５に記載の発明は、請求項１乃至３の何れか一項に記載の電子情報記憶媒体において、前記実行手段は、前記通知処理において通知が完了した前記アプリケーションの情報を、前記通知処理の状況として記録し、前記再実行手段は、前記アプリケーションの情報が記録されていない前記アプリケーションに対して前記通知処理を再実行することを特徴とする。

請求項６に記載の発明は、請求項１乃至３の何れか一項に記載の電子情報記憶媒体において、前記実行手段は、通知対象となるアプリケーションの情報を登録するリストから、前記通知処理において前記通知が完了した前記アプリケーションの情報を削除し、前記再実行手段は、前記リストから前記情報が削除されていないアプリケーションに対して前記通知処理を再実行することを特徴とする。

請求項７に記載の発明は、請求項１乃至３の何れか一項に記載の電子情報記憶媒体において、前記実行手段は、前記通知処理の状況として、前記通知処理の開始時に通知未完了情報を記録し、前記通知処理の完了時に通知完了情報を記録し、前記再実行手段は、前記通知未完了情報が記録され、且つ前記通知完了情報が記録されていない場合に限り、前記通知処理を再実行することを特徴とする。

請求項８に記載の発明は、請求項１乃至３の何れか一項に記載の電子情報記憶媒体において、前記実行手段は、前記アプリケーションの設定変更の基点となるイベントを記録し、前記再実行手段は、前記記録されたイベントに基づいて前記通知処理により通知対象となる前記アプリケーションを特定し、特定した前記アプリケーションに対して前記通知処理を再実行することを特徴とする。

請求項９に記載の発明は、オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行うＩＣカードであって、少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録する実行手段と、前記通知処理中に前記ＩＣカードへの電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行する再実行手段と、を備えることを特徴とする。

請求項１０に記載の発明は、オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行う電子情報記憶媒体が備えるプロセッサにより実行される通知方法であって、少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録するステップと、前記通知処理中に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行するステップと、を含むことを特徴とする。

請求項１１に記載の発明は、オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行う電子情報記憶媒体が備えるプロセッサに、少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録するステップと、前記通知処理中に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行するステップと、を実行させることを特徴とする。

本発明によれば、設定変更の通知中に電源供給遮断が発生したとしても、不整合が発生することなくアプリケーションの動作を保障することができる。

本実施形態に係る携帯端末の概要構成例を示すブロック図である。 接触型ＩＣチップ１２ａのハードウェア構成例を示す図である。 接触型ＩＣチップ１２ａに搭載される可能性のあるアプリケーションの例を事業者ごとに示す図である。 各サービス提供者の管理アプリ及びアプリケーション間で形成される階層構造の一例を示す図である。 ＵＩＭカード１２がベースバンドプロセッサ１３から設定変更コマンドを受信したときの処理を示すシーケンス図である。 実施例１〜実施例６で実行される通知事前処理の内容、及び通知処理における通知状況の記録のタイミング及び内容の一覧を示す図である。 （Ａ）は、実施例１において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 実施例１における通知アプリケーションリストの登録内容の一例を示す図である。 （Ａ）は、実施例２において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 （Ａ）は、実施例３において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 実施例３における通知アプリケーションリストの登録内容の一例を示す図である。 （Ａ）は、実施例４において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 実施例４における通知アプリケーションリストの登録内容の一例を示す図である。 （Ａ）は、実施例５において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 実施例５における通知イベントリストの登録内容の一例を示す図である。 （Ａ）は、実施例６において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 （Ａ），（Ｂ）は、変形例において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、（Ｃ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。 設定変更されるアプリケーションと、当該設定変更がされたときに通知対象となるアプリケーションとの対応関係を示すリストの例を示す図である。

以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、携帯端末に対して本発明を適用した場合の実施の形態である。

［１．携帯端末の構成及び機能概要］
先ず、図１等を参照して、本実施形態に係る携帯端末の構成及び機能概要について説明する。図１は、本実施形態に係る携帯端末の概要構成例を示すブロック図である。図１に示すように、携帯端末１は、ＮＦＣ対応端末であり、ＣＬＦ１１、ＵＩＭカード１２、ベースバンドプロセッサ１３、及びバッテリー１４等を備えて構成されている。その他、携帯端末１は、図示しないが、移動体無線通信部、操作・表示部、及び記憶部等を備える。移動体無線通信部は、移動体通信ネットワークを利用した無線通信機能を有する。移動体通信ネットワークは、例えば、電話用回線交換ネットワーク、及びインターネットに接続するためのデータ通信用パケット交換ネットワークを含む。移動体無線通信部は、図示しないアンテナを介して、最寄りの基地局との間で無線通信を行い、当該基地局及び移動体通信ネットワークを介して他の携帯端末やサーバとの間で通信を行う。操作・表示部は、例えば、ユーザの指やペン等による操作指示を受け付ける入力機能と、情報を表示する画面を有するタッチパネルとを備える。操作・表示部は、ユーザからの操作指示を受け付け、その操作指示に応じた信号をベースバンドプロセッサ１３へ出力する。記憶部は、例えば不揮発性メモリから構成され、オペレーティングシステム（Operating System、以下、「ＯＳ」という）、アプリケーションプログラム、及びブラウザプログラム等が記憶される。携帯端末１は、音声処理部及びスピーカを備えてもよい。なお、携帯端末１には、携帯電話機やスマートフォン等を適用できる。

ＣＬＦ１１は、ＮＦＣの規格で規定される非接触通信を行う非接触型ＩＣチップであり、図示しないが、ＣＰＵ（Central Processing Unit）、所定のプログラムを記憶する不揮発性メモリ（例えばフラッシュメモリ等）、データを一時記憶するＲＡＭ（Random Access Memory）、ＵＩＭカード１２との間のインターフェースを担うＩ／Ｏポート（ＳＷＩＯ（Single Wire protocol Input/Output））、及びベースバンドプロセッサ１３との間のインターフェースを担うＩ／Ｏポート等を備えている。また、ＣＬＦ１１には、非接触のフィールド内で、非接触ＩＣカードリーダを備える外部装置２との間で非接触通信を行うためのアンテナ１１ａが接続されており、ＣＬＦ１１は、非接触通信プロトコル処理を担う。ＣＬＦ１１における非接触通信プロトコルは、携帯端末１が外部装置２と非接触で通信を行うための通信プロトコル（つまり、携帯端末１としての通信プロトコル）であり、ＵＩＭカード１２からの設定指示により設定される。

ＵＩＭカード１２は、ＵＩＣＣ（Universal Integrated Circuit Card）の一つであり、従来のＳＩＭ（Subscriber Identity Module）カードをベースに機能を拡張された接触型ＩＣチップ１２ａを搭載する。なお、ＵＩＭカード１２は、ＮＦＣ対応ＵＩＭカードであり、本発明のＩＣカードの一例である。また、接触型ＩＣチップ１２ａは、本発明の電子情報記憶媒体の一例である。図２は、ＵＩＭカード１２に搭載される接触型ＩＣチップ１２ａのハードウェア構成例を示す図である。なお、接触型ＩＣチップ１２ａは、携帯端末１の回路基板上に直接組み込まれて構成されるようにしてもよく、例えばeUICC（Embedded Universal Integrated Circuit Card）として、携帯端末１から容易に取り外しや取り換えができないように携帯端末１と一体的に搭載されてもよい。

図２は、接触型ＩＣチップ１２ａのハードウェア構成例を示す図である。図２に示すように、接触型ＩＣチップ１２ａは、ＣＰＵ１２１、ＲＡＭ１２２、ＲＯＭ（Read Only Memory）１２３、不揮発性メモリ１２４、及びＩ／Ｏ回路１２５を備えて構成される。ＣＰＵ１２１は、ＲＯＭ１２３または不揮発性メモリ１２４に記憶された各種プログラムを実行するプロセッサ（コンピュータ）であり、本発明における再設定手段、実行手段、再実行手段、及び復帰手段の一例である。不揮発性メモリ１２４には、例えばフラッシュメモリが適用される。不揮発性メモリ１２４に記憶される各種プログラム及びデータの一部は、ＲＯＭ１２３に記憶されてもよい。なお、不揮発性メモリ１２４は、「Electrically Erasable Programmable Read-Only Memory」であってもよい。本実施形態において、ＲＯＭ１２３または不揮発性メモリ１２４との何れかに記憶されるプログラムには、ＯＳ、本発明の通知処理プログラム、複数（つまり、複数種類）のアプリケーションプログラム、及び複数のＳＤプログラム等が含まれる。なお、本発明の通知処理プログラムは、ＯＳまたはＳＤプログラム内に組み込まれてもよいし、或いは、ＯＳ及びＳＤプログラムとは独立したミドルウェアとしてインストールされてもよい。

ここで、アプリケーションプログラムは、ＵＩＭカード１２においてアプリケーションインスタンス（これを、「アプリケーション」という）の機能を実現するためのプログラムである。アプリケーションは、アプリケーションプログラム等をメモリに展開して実行可能な状態にインストール（搭載）されたモジュールである。なお、アプリケーションは、アプリケーションプログラムを指す場合もある。本実施形態では、接触型ＩＣチップ１２ａに搭載されたＯＳ上で、複数のアプリケーションが動作可能に設定される。これにより、ＵＩＭカード１２は、例えばそれぞれのアプリケーションにしたがってＣＬＦ１１を介して外部装置２と通信を行う。なお、それぞれのアプリケーションには、固有の識別子（アプリケーションの情報の一例）が付与されている。

ＳＤプログラムは、ＵＩＭカード１２においてＳＤ（Security Domain）の機能を実現するためのプログラムである。ＳＤとは、例えば事業者が提供するサービスを実現するうえで必要となるＵＩＭカード１２内のカードコンテントを管理するための機能を提供する管理アプリケーションである。以下、ＳＤを、「管理アプリ」という。カードコンテントとは、アプリケーションプログラムやアプリケーションプログラムから生成されたアプリケーションである。また、カードコンテントを管理するための機能とは、例えば、アプリケーションプログラムのロード、アプリケーションインスタンスの生成（インストール）、アプリケーションプログラムやアプリケーションインスタンスの削除、アプリケーションインスタンスへのデータの書込み（パーソナライズ）などである。なお、管理アプリには、ＩＳＤ（Issuer Security Domain）とＳＳＤ（Supplementary Security Domains）とがある。ＩＳＤは、上記機能をサポートすることで、ＵＩＭカード１２のカードコンテントに対して、ＵＩＭカード１２上でサービスを提供するサービス提供者等の管理及びセキュリティポリシーを実現する。

ところで、従来の非接触ＩＣカードは、基本的に１つの事業者に基づくサービスを提供するのに対し、本実施形態の携帯端末１は、複数の事業者に基づくサービスを提供可能である。例えば、クレジットブランド（クレジットカード会社）Ａ兼クレジットブランドＢのクレジットカード機能を持ち合わせた１枚の非接触ＩＣカードは存在しないが、本実施形態では、接触型ＩＣチップ１２ａに搭載された複数のアプリケーションにより、当該機能を実現することが可能となる。

図３は、接触型ＩＣチップ１２ａに搭載される可能性のあるアプリケーションの例を事業者ごとに示す図である。図３の例では、クレジットブランドＡのアプリケーションとして、クレジットアプリＡ１、クレジットアプリＡ２、及びクレジットアプリＡ３があり、クレジットブランドＢのアプリケーションとして、クレジットアプリ（クレジット決済用のアプリケーション）Ｂ１、クレジットアプリＢ２、及びクレジットアプリＢ３がある。また、鉄道会社Ｃのアプリケーションとして、電子マネーアプリ（電子マネー決済用のアプリケーション）Ｃ１、及びポイントアプリ（ポイント決済用のアプリケーション）Ｃ２があり、鉄道会社Ｄのアプリケーションとして、電子マネーアプリＤ１、及びポイントアプリＤ２がある。さらに、総合サービス会社Ｅのアプリケーションとして、ポイントアプリＥ１、チケットアプリ（チケット取得用のアプリケーション）Ｅ２、クーポンアプリ（クーポン取得用のアプリケーション）Ｅ３、及び電子マネーアプリＥ４がある。このように１つの接触型ＩＣチップ１２ａ上に、様々なサービス提供者（事業者）が様々なアプリケーションを搭載することが可能となることで、ＵＩＭカード１２には従来の非接触ＩＣカードには必要なかったアプリケーション管理機能を有する管理アプリが搭載され、各サービス提供者の管理アプリ及びアプリケーション間で階層構造を形成する。

図４は、各サービス提供者の管理アプリ及びアプリケーション間で形成される階層構造の一例を示す図である。図４の例では、クレジットブランドＡと鉄道会社Ｃのそれぞれに対応する管理アプリが階層構造における最上位に位置（存在）しており、それぞれの管理アプリの配下には、それぞれのサービス提供者のアプリケーションが位置している。このため、クレジットブランドＡのクレジットアプリＡ１及びクレジットアプリＡ２は、クレジットブランドＡの管理アプリのセキュリティポリシーが適応される。一方、鉄道会社Ｃの電子マネーアプリＣ１及びポイントアプリＣ２は、鉄道会社Ｃの管理アプリのセキュリティポリシーが適応される。鉄道会社Ｃの管理アプリにより、電子マネーアプリＣ１とポイントアプリＣ２とが連携することができる。例えば、鉄道会社Ｃが提供する鉄道の利用回数が増えるたびにポイントが貯まり、貯まったポイントにより乗車が可能となったり、買い物ができるようになったりする。

また、不揮発性メモリ１２４には、接触型ＩＣチップ１２ａに搭載された複数のアプリケーションの設定が保存される。例えば複数のアプリケーションのそれぞれに対応する通信プロトコル設定、及びActivated/Deactivated（活性化又は非活性化）の状態設定などが保存される。例えば、それぞれの通信プロトコルには、最大通信速度、１ユニット（例えば、APDU（Application data unit））で送信可能なデータの最大サイズ、フレーム（コマンドを配送するためのパケット）待ち時間、及び仮固有ＰＵＩＣＣ識別子などの通信パラメータが含まれる。このような通信パラメータは、アプリケーション間で同一の場合もあるし、異なる場合もある。ここで、フレーム待ち時間は、ＵＩＭカード１２が外部装置２へデータ送信後、無応答と判断するまでの時間である。ＵＩＭカード１２は、このフレーム待ち時間までに応答を準備できなければ、待ち時間延長要求を外部装置２へ返送する必要がある。仮固有PUICC識別子は、衝突防止処理中で、ＵＩＭカード１２を識別するのに使われる値である。

Ｉ／Ｏ回路１２５には、ISO7816等によって定められたＣ１〜Ｃ８の８個の端子が備えられている。或いは、Ｉ／Ｏ回路１２５には、Ｃ４とＣ８の端子を除く６個の端子が備えられている。Ｃ１端子は電源端子（ＶＣＣ）であり、Ｃ５端子はグランド端子（ＧＮＤ）である。また、Ｃ２端子は、リセット端子（ＲＳＴ）であり、ベースバンドプロセッサ１３とのインターフェースのリセット信号を入力するために用いられる。また、Ｃ３端子は、クロック端子（ＣＬＫ）であり、ベースバンドプロセッサ１３とのインターフェースのクロックを入力するために用いられる。また、Ｃ７端子は、ベースバンドプロセッサ１３との間のインターフェースを担う端子であり、ＵＩＭカード１２とベースバンドプロセッサ１３との間の通信のために用いられる。また、Ｃ６端子は、ＣＬＦ１１との間のインターフェースを担う端子（ＳＷＩＯ）であり、ＣＬＦ１１との間の通信のために用いられる。なお、ＣＬＦ１１とＵＩＭカード１２間のインターフェースには上述したように、ＳＷＰが適用される。

ＣＰＵ１２１は、接触型ＩＣチップ１２ａに搭載された複数のアプリケーションの設定に基づいて、当該複数のアプリケーションに共通する設定を行う。なお、それぞれのアプリケーションに共通する設定が不要な場合もある。設定対象の例として、通信プロトコル、Activated/Deactivatedの状態などが挙げられる。複数のアプリケーションに共通する設定を行う場合、通信プロトコル設定では、例えばＯＳは、接触型ＩＣチップ１２ａに搭載されたアプリケーションのうちから例えば携帯端末１のユーザにより選択された複数のアプリケーションのそれぞれに対応する通信プロトコル（つまり、それぞれのアプリケーションの通信プロトコル設定）に基づいて、上述した非接触通信プロトコル（携帯端末１としての通信プロトコル）を設定する。すなわち、ＯＳは、アプリケーション毎の通信プロトコルを勘案して、当該複数のアプリケーションに共通する１つの非接触通信プロトコルを設定する。例えば、電子マネーアプリＣ１とポイントアプリＣ２とが選択されている場合、携帯端末１が非接触ＩＣカードリーダに翳されたときの１セッション中に電子マネーアプリＣ１とポイントアプリＣ２が何れも動作できるように最大公約数となる通信プロトコルが設定される。より具体的には、電子マネーアプリＣ１に対応する最大通信速度が212kbpsであり、ポイントアプリＣ２に対応する最大通信速度が106kbpsであると仮定した場合、非接触通信プロトコル（つまり、電子マネーアプリＣ１とポイントアプリＣ２に共通する通信プロトコル）における最大通信速度は106kbpsに設定される。また、別の例として、電子マネーアプリＣ１に対応するフレーム待ち時間が30msであり、ポイントアプリＣ２に対応するフレーム待ち時間が50msであると仮定した場合、電子マネーアプリＣ１とポイントアプリＣ２に共通する非接触通信プロトコルにおけるフレーム待ち時間は30msに設定される。また、別の例として、電子マネーアプリＣ１に対応する仮固有PUICC識別子が“22”（h）（つまり、binaryでで、0010 0010(b)）であり、ポイントアプリＣ２に対応する仮固有PUICC識別子が“41”（h）（0100 0001(b)）であると仮定した場合、電子マネーアプリＣ１とポイントアプリＣ２に共通する非接触通信プロトコルにおける仮固有PUICC識別子は、それぞれの仮固有PUICC識別子をマージ（XOR演算）した値である“63”(h)（0110 0011(b)）に設定される。

一方、Activated/Deactivatedの状態設定では、例えばＯＳは、接触型ＩＣチップ１２ａに搭載されたアプリケーションのうちから例えば携帯端末１のユーザにより選択された複数のアプリケーションのそれぞれに対応するActivated/Deactivatedの状態（つまり、それぞれのアプリケーションのActivated/Deactivatedの状態設定）に基づいて、当該複数のアプリケーションに共通するActivated/Deactivatedの状態を設定する。例えばあるアプリケーション（例えば、クレジットアプリ）の状態がDeactivatedであり、そのアプリケーションの配下にあるアプケーションの状態がActivatedであると仮定した場合、複数のアプリケーションに共通するActivated/Deactivatedの状態は、上位のアプリケーション（例えば、クレジットアプリ）に依存されるため、Deactivatedに設定される。

なお、接触型ＩＣチップ１２ａ内に、例えば同一のクレジットブランドのクレジットアプリが複数搭載されている場合（例えば、クレジットアプリＡ１及びクレジットアプリＡ２が搭載されている場合）、携帯端末１が店頭ＰＯＳレジで非接触ＩＣカードリーダに翳されたとき、ユーザは何れのアプリケーションが決済処理を行うか事前に選択できる必要がある。これを実現するために、接触型ＩＣチップ１２ａ内の各アプリケーションには優先度が割り振られ、携帯端末１のユーザからの操作指示にしたがって何れかのアプリケーションが事前に選択される。また、設定された非接触通信プロトコルの設定指示は、接触型ＩＣチップ１２ａからＣＬＦ１１へ送信され、ＣＬＦ１１において非接触通信プロトコルが設定される。ＣＬＦ１１へ非接触通信プロトコルの設定指示を送信するタイミングは、レスポンス送信前であってもよいし、レスポンス送信後であってもよい。また、当該設定指示を送信するタイミングは、ＣＬＦ１１との通信に利用されるＳＷＰが非活性化状態であってもなくてもよく、また、次回活性化時などであってもよい。

上述したように、非接触通信プロトコルが設定された後、選択中の少なくとも何れか１つのアプリケーションの設定が変更される場合、ＣＰＵ１２１は、設定変更されたアプリケーションを含む複数のアプリケーションの設定に基づいて、上記設定時と同じように、それぞれのアプリケーションに共通する再設定（再構築）を行う。例えばＯＳは、設定変更されたアプリケーションを含む複数のアプリケーションのそれぞれに対応する通信プロトコル（つまり、それぞれのアプリケーションの通信プロトコル設定）に基づいて、当該複数のアプリケーションに共通する非接触通信プロトコルの再設定を行う。例えば、電子マネーアプリＣ１に対応する最大通信速度が212kbpsであり、ポイントアプリＣ２に対応する最大通信速度が106kbpsであると仮定した場合において、ポイントアプリＣ２に対応する最大通信速度が86kbpsに設定変更された場合、それぞれのアプリケーションに共通する非接触通信プロトコルにおける最大通信速度が106kbpsから86kbpsに再設定（設定変更）される。一方、Activated/Deactivatedの状態設定では、例えばＯＳは、設定変更されたアプリケーションを含む複数のアプリケーションのそれぞれに対応するActivated/Deactivatedの状態（つまり、それぞれのアプリケーションのActivated/Deactivatedの状態設定）に基づいて、当該複数のアプリケーションに共通するActivated/Deactivatedの状態を設定する。例えば、あるアプリケーション（例えば、クレジットアプリ）の状態がActivatedであり、そのアプリケーションの配下にあるアプケーションの状態もActivatedであると仮定した場合において、あるアプリケーション（例えば、クレジットアプリ）の状態がDeactivatedに設定変更された場合、上記再設定により、そのアプリケーションの配下にあるアプリケーションの状態もDeactivatedに設定変更される。つまり、この場合、あるアプリケーションのActivated/Deactivatedの状態が変化すると、上記再設定により、そのアプリケーションと連動する他のアプリケーションのActivated/Deactivatedの状態も合わせて設定変更される。

なお、上記再設定により非接触通信プロトコルが設定変更される場合もあるし設定が維持される場合もある。また、それぞれのアプリケーションに共通する再設定が実施されない場合もある。少なくとも何れか１つのアプリケーションの設定が変更された場合、ＯＳは、複数のアプリケーションのうち通知対象となるアプリケーション（複数のアプリケーションのうち少なくとも何れか１つのアプリケーション）に対して設定変更（例えば、アプリケーションの通信プロトコル設定変更、またはアプリケーションのActivated/Deactivatedの状態変更）されたことを示す設定変更情報を通知する通知処理を実行し、且つ当該通知処理の状況（以下、「通知状況」という）を記録する。また、アプリケーションの再設定が行われた場合（例えば、非接触通信プロトコルが再設定された場合）、ＯＳは、設定変更後の複数のアプリケーションのうち通知対象となるアプリケーション（複数のアプリケーションのうち少なくとも何れか１つのアプリケーション）に対して設定変更（例えば、あるアプリケーションの通信プロトコルの設定変更により非接触通信プロトコルが再設定）されたことを示す設定変更情報（この場合、「設定変更情報」は、「再設定情報」ということもできる）を通知する通知処理を実行し、且つ当該通知処理の状況（以下、「通知状況」という）を記録する。ここで、通知状況の記録は、例えば、通知処理の開始時（通知処理の先頭）、通知処理の途中、及び通知処理の完了（終了）時（通知処理の末尾）のうち何れかの１以上のタイミングで、所定の情報（例えば、通知未完了フラグまたは通知完了フラグ）が不揮発性メモリ１２４に記憶されたり（つまり、書き込まれたり）、或いは所定の情報（例えば、アプリケーションの識別子）が不揮発性メモリ１２４から削除（例えば、“00...0”(h)や“FF...F”(h)で上書き）されることより行われる。そして、ＯＳは、上記通知処理中にＵＩＭカード１２への電源供給が遮断（電源断）され、当該遮断後に電源供給が復旧（再開）した場合、上記通知状況にしたがって、通知処理を再実行する。これにより、設定変更の通知中に電源供給遮断が発生したとしても、不整合が発生することなくアプリケーションの動作を保障することができる。

ベースバンドプロセッサ１３は、携帯端末１のユーザからの操作指示（例えば、操作・表示部を介した操作指示）に応じて各種処理を実行する。また、ベースバンドプロセッサ１３は、ブラウザプログラムを実行することによりブラウザとして機能し、ユーザからの指示にしたがって移動体無線通信部及び移動体通信ネットワークを介して特定のサーバとの間で通信を行う。バッテリー１４は、携帯端末１の電源であり、携帯端末１を動作させるための電力を外部から充電可能になっている。ベースバンドプロセッサ１３は、バッテリー１４から供給された電力をＣＬＦ１１及びＵＩＭカード１２へ供給（電源供給）する。

［２．携帯端末１の動作］
次に、図５を参照して、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の概要について説明する。図５は、ＵＩＭカード１２がベースバンドプロセッサ１３から設定変更コマンドを受信したときの処理を示すシーケンス図である。ここで、設定変更コマンドは、選択中の少なくとも何れか１つのアプリケーションの設定変更を示すコマンドである。このような設定変更コマンドは、特定のサーバから送信され、移動体通信ネットワーク及び移動体無線通信部を介してベースバンドプロセッサ１３（ブラウザ）により受信される。或いは、このような設定変更コマンドは、携帯端末１のユーザからの操作指示にしたがって操作・表示部から送信され、ベースバンドプロセッサ１３により受信される。ベースバンドプロセッサ１３は、当該設定変更コマンドを受信すると、当該設定変更コマンドをＵＩＭカード３の管理アプリへ送信する（ステップＳ１）。

次いで、管理アプリは、当該設定変更コマンドを受信すると、当該設定変更コマンドをＯＳへ送信する（ステップＳ２）。これにより、管理アプリは、ＯＳに対して設定保存の依頼を行う。ＯＳは、当該設定変更コマンドを受信すると（つまり、設定保存の依頼を受けると）、当該設定変更コマンドで指定されたアプリケーションの設定を変更して保存し、選択中の複数のアプリケーションの再設定のための再設定処理（ステップＳ３）を実行する。この再設定処理では、例えば、上述したように、非接触通信プロトコルが再設定される。次いで、ＯＳは、通知事前処理（ステップＳ４）を行った後、通知対象となるアプリケーションに対する通知処理（ステップＳ５）を実行する。図５に示す通知処理では、通知対象となるアプリケーションであるアプリＡ１１、アプリＡ１２、アプリＡ１４、及びアプリＡ１８に対して、上記設定変更情報が通知されるようになっている。設定変更情報の通知を受けたアプリケーションは、当該アプリケーションが出力するデータを変更する。また、設定変更情報の通知を受けたアプリケーションは、使用可能な機能を制限したり、或いは当該制限を解除する場合もある。例えば、あるアプリケーションがActivatedとなったことなどを示す設定変更情報の通知を受けた場合、当該アプリケーションは、Activatedとなったアプリケーションと連携する連携コマンドを使用できるよう機能を解除する。また、設定変更情報の通知を受けたアプリケーションは、連携コマンドが使用可能であることを示す情報をSelectコマンドに対するレスポンスに含める場合もある。また、設定変更情報の通知を受けたアプリケーションが、Activatedであるアプリケーションの一覧を返すような機能を持っている場合、その一覧を更新する場合もある。また、設定変更情報の通知を受けたアプリケーションは、再設定された通信パラメータに応じて、使用できる機能を制限する場合もある。

そして、ＯＳは、上記通知に対する確認応答を上記通知対象となるアプリケーション全てから受けた場合、管理アプリに対して上記設定変更コマンドに対するレスポンスを送信する（ステップＳ６）。管理アプリは、ＯＳからのレスポンスを受けると、上記設定変更コマンドに対するレスポンスをベースバンドプロセッサ１３へ送信する（ステップＳ７）。なお、アプリケーションの設定変更は管理アプリが行ってもよく、この場合、管理アプリが、上記ステップＳ３〜ステップＳ５の処理を行ってもよい。なお、非接触通信プロトコルが再設定された場合、ＯＳは、当該再設定された非接触通信プロトコルの設定指示をＣＬＦ１１へ送信する。これにより、ＣＬＦ１１において非接触通信プロトコルが設定される。

次に、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の詳細、及び当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の詳細について、実施例１〜実施例６に分けて説明する。図６は、実施例１〜実施例６で実行される通知事前処理の内容、及び通知処理における通知状況の記録のタイミング及び内容の一覧を示す図である。図６に示すように、通知事前処理の内容、及び通知処理における通知状況の記録のタイミング及び内容は、実施例１〜実施例６間で少しずつ異なっている。なお、実施例１〜６では、通知アプリケーションリストが用いられ、実施例５及び６では、さらに、通知イベントリストが用いられる。通知アプリケーションリストは、通知対象となるアプリケーションの情報を登録（記録）するリストである。通知イベントリストは、アプリケーションの設定変更の基点となる通知イベントの情報を登録（記録）するリストである。実施例１〜４では、通知アプリケーションリストは不揮発性メモリ１２４に保存される（つまり、電源供給が遮断されても当該リストは消去されない）。一方、実施例５及び６では、通知アプリケーションリストは不揮発性メモリ１２４に保存されず（ＲＡＭ１２２に一時的に記憶される）、この代わりに、通知イベントリストが不揮発性メモリ１２４に保存される。

（実施例１）
図７（Ａ）は、実施例１において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図７（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。図７（Ａ），（Ｂ）の処理は、ＯＳにより行われるが、管理アプリにより行われてもよい。なお、図７（Ａ）に示す処理は、設定変更コマンドが受信されたときに開始される。

図７（Ａ）に示す処理が開始されると、ＯＳは、上述したように、再設定処理（ステップＳ３）を行う（ステップＳ１０１）。次いで、ＯＳは、通知事前処理（ステップＳ４）を開始し、接触型ＩＣチップ１２ａに搭載されているアプリケーションを１つ選定する（ステップＳ１０２）。次いで、ＯＳは、ステップＳ１０２で選定したアプリケーションの通知設定を取得する（ステップＳ１０３）。アプリケーションの通知設定は、アプリケーションの再設定があった場合に当該アプリケーションが通知を要求するか否かの設定であり、例えば不揮発性メモリ１２４に保存され、ＯＳにより管理される。なお、アプリケーションの通知設定は、例えばアプリケーションのインストール時に行われ、インストール後にも、外部からのコマンドに応じて変更可能になっている。

次いで、ＯＳは、ステップＳ１０３で取得した通知設定に基づいて、ステップＳ１０２で選定したアプリケーションへの通知の必要があるか否かを判定する（ステップＳ１０４）。ＯＳは、選定したアプリケーションへの通知の必要があると判定した場合（ステップＳ１０４：ＹＥＳ）、当該選定したアプリケーションを通知対象として、ステップＳ１０５へ進む。一方、ＯＳは、当該選定したアプリケーションへの通知の必要がないと判定した場合（ステップＳ１０４：ＮＯ）、ステップＳ１０６へ進む。

ステップＳ１０５では、ＯＳは、通知対象となるアプリケーションの情報を、不揮発性メモリ１２４に保存されている通知アプリケーションリストに登録し、ステップＳ１０６へ進む。なお、通知アプリケーションリスト（未登録）は、例えば上記通知事前処理の開始前に作成される。図８は、実施例１における通知アプリケーションリストの登録内容の一例を示す図である。図８に示す通知アプリケーションリストには、リスト番号、通知対象となるアプリケーションの識別子、通知理由、及び変更内容が対応付けられて登録されている。図８の例では、通知アプリケーションリストに登録されたアプリ１の識別子に対応付けられた通知理由は、管理アプリによる設定変更となっており、アプリ２、アプリ４、及びアプリ８の識別子のそれぞれに対応付けられた通知理由は、アプリ１の設定変更となっている。また、図８の例では、アプリ１、アプリ２、アプリ４、及びアプリ８の識別子のそれぞれに対応付けられた変更内容は、アプリ１の通信プロトコルの設定変更になっている。なお、リスト番号は、例えば通知アプリケーションリストへの登録順序に対応している。

ステップＳ１０６では、ＯＳは、接触型ＩＣチップ１２ａに搭載されているアプリケーションのうち、まだ選定されていないアプリケーションがあるか否かを判定する。ＯＳは、まだ選定されていないアプリケーションがある（つまり、残りがある）と判定した場合（ステップＳ１０６：ＹＥＳ）、ステップＳ１０２に戻り、まだ選定されていないアプリケーションを選定してステップＳ１０３以降の処理を行う。一方、ＯＳは、まだ選定されていないアプリケーションがない（つまり、全てのアプリケーションを選定した）と判定した場合（ステップＳ１０６：ＮＯ）、通知事前処理を終了し、ステップＳ１０７へ進む。

ステップＳ１０７では、ＯＳは、通知アプリケーションリストは空であるか（つまり、アプリケーションの情報が登録されていないか）否かを判定する。ＯＳは、通知アプリケーションリストは空でないと判定した場合（ステップＳ１０７：ＮＯ）、ステップＳ１０８へ進む。一方、ＯＳは、通知アプリケーションリストは空であると判定した場合（ステップＳ１０７：ＹＥＳ）、設定変更コマンドに対するレスポンス（通知対象となるアプリケーション無を示す）を管理アプリへ送信する。

ステップＳ１０８では、ＯＳは、通知処理（ステップＳ５）を開始し、通知状況として、通知未完了フラグ（通知未完了情報の一例）を記録する。なお、通知未完了フラグの記録では、例えば、通知未完了フラグを示す“F1”(h)が不揮発性メモリ１２４における所定の記憶領域に記憶される（言い換えれば、“00”(h)が“F1”(h)に書き換えられる）。次いで、ＯＳは、通知アプリケーションリストから、アプリケーションの情報を１つ取得する（ステップＳ１０９）。つまり、通知対象となるアプリケーションが特定される。次いで、ＯＳは、ステップＳ１０９で取得した情報に含まれる識別子に対応するアプリケーション（通知対象となるアプリケーション）に対して、上述したように、設定変更情報を通知する（ステップＳ１１０）。

次いで、ＯＳは、通知アプリケーションリスト内の全てのアプリケーションに通知したか否かを判定する（ステップＳ１１１）。ＯＳは、通知アプリケーションリスト内の全てのアプリケーションに通知していないと判定した場合（ステップＳ１１１：ＮＯ）、ステップＳ１０９に戻り、まだ通知していないアプリケーションの情報を１つ取得してステップＳ１１０以降の処理を行う。一方、ＯＳは、通知アプリケーションリスト内の全てのアプリケーションに通知したと判定した場合（ステップＳ１１１：ＹＥＳ）、所定時間内に上記通知対象のアプリケーション全てから上記通知に対する確認応答を受けたか否かを判定する（ステップＳ１１２）。

ＯＳは、所定時間内に上記通知対象のアプリケーション全てから上記通知に対する確認応答を受けたと判定した場合（ステップＳ１１２：ＹＥＳ）、通知状況として、通知完了フラグ（通知完了情報の一例）を記録して（ステップＳ１１３）当該通知処理を終了し、上記設定変更コマンドに対するレスポンス（例えば、正常に設定変更が完了したことを示す）を管理アプリへ送信する。これにより、当該レスポンスがベースバンドプロセッサ１３へ送信される。なお、通知完了フラグの記録では、例えば、通知完了フラグを示す“F2”(h)が不揮発性メモリ１２４における所定の記憶領域（通知未完了フラグが記憶される領域とは異なる記憶領域）に記憶される（言い換えれば、“00”(h)が“F2”(h)に書き換えられる）。或いは、通知完了フラグの記録では、例えば、通知完了フラグを示す“F2”(h)が、不揮発性メモリ１２４において通知未完了フラグが記憶される領域と同じ記憶領域に記憶される。この場合、例えば、“F1”(h)が“F2”(h)に書き換えられる。一方、ＯＳは、所定時間内に上記通知対象のアプリケーション全てから上記通知に対する確認応答を受けていないと判定した場合（ステップＳ１１２：ＮＯ）、エラー処理を行う。

一方、図７（Ｂ）に示す処理（起動処理）は、上記処理中に電源供給が遮断しその後に電源供給が復旧したときに開始される。図７（Ｂ）に示す処理が開始されると、ＯＳは、上記通知状況に基づいて、上記通知処理が未完了であるか否かを判定する（ステップＳ１１５）。例えば、通知未完了フラグ及び通知完了フラグが双方とも記録されているかどうかが判定され、双方とも記録されている場合、ＯＳは、上記通知処理が未完了でない（つまり、当該通知処理が完了した）と判定し（ステップＳ１１５：ＮＯ）、図７（Ｂ）に示す処理は終了する。一方、通知未完了フラグが記録されており、且つ通知完了フラグが記録されていない場合、ＯＳは、上記通知処理が未完了であると判定し（ステップＳ１１５：ＹＥＳ）、ステップＳ１１６へ進み、上記通知処理を再実行する。当該再実行される通知処理では、ステップＳ１１６〜Ｓ１２０の処理（図７（Ａ）に示すステップＳ１０９〜Ｓ１１３の処理と同様）が行われる。なお、通知未完了フラグが記憶される領域と、通知完了フラグが記憶される領域とが同じ記憶領域である場合の例では、ステップＳ１１５において、通知未完了フラグ“F1”(h)が記録されている場合、上記通知処理が未完了であると判定される（ステップＳ１１５：ＹＥＳ）一方、通知完了フラグ“F2”(h)が記録されている場合、上記通知処理が未完了でない（つまり、完了した）と判定される（ステップＳ１１５：ＮＯ）ことになる。

このように、実施例１によれば、通知未完了フラグ及び通知完了フラグを利用して電源供給遮断時の通知状況を迅速に判断することができ、当該判定された通知状況にしたがって、アプリケーションに対する通知を確実に行うことができる。

（実施例２）
図９（Ａ）は、実施例２において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図９（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。なお、図９（Ａ），（Ｂ）の処理は、図７（Ａ），（Ｂ）の処理と基本的には同様であるので、主に、図７（Ａ），（Ｂ）の処理と異なる部分について説明する。実施例２では、実施例１と同様、図８に示すように、通知アプリケーションリストに、通知対象となるアプリケーションの情報が登録される。

図９（Ａ）に示すステップＳ１２１〜Ｓ１２７の処理は、図７（Ａ）に示すステップＳ１０１〜Ｓ１０７の処理と同様に行われる。実施例１では、図７（Ａ）に示すステップＳ１０８（通知処理の開始時）において通知未完了フラグが記録されたが、実施例２では、通知未完了フラグが記録されずにステップＳ１２８〜Ｓ１３１の処理（図７（Ａ）に示すステップＳ１０９〜Ｓ１１２の処理と同様）が行われる。そして、ステップＳ１３２では、ＯＳは、通知アプリケーションリストから、ステップＳ１２９において通知が完了した全てのアプリケーションの情報を削除（例えば、通知アプリケーションを“0000・・・”(h)で上書き）することで、通知状況を記録する。これにより、通知アプリケーションリストが空になる。或いは、通知アプリケーションリスト自体が削除されてもよい。

一方、図９（Ｂ）に示す処理では、ＯＳは、上記通知状況に基づいて、上記通知処理が未完了であるか否かを判定する（ステップＳ１３５）。例えば、通知アプリケーションリストが空であるかどうかが判定され、空である場合、ＯＳは、上記通知処理が未完了でない（つまり、当該通知処理が完了した）と判定し（ステップＳ１３５：ＮＯ）、図９（Ｂ）に示す処理は終了する。一方、通知アプリケーションリストが空でない場合、ＯＳは、上記通知処理が未完了であると判定し（ステップＳ１３５：ＹＥＳ）、ステップＳ１３６へ進み、上記通知処理を再実行する。当該再実行される通知処理では、ステップＳ１３６〜Ｓ１４０の処理（図９（Ａ）に示すステップＳ１２８〜Ｓ１３２の処理と同様）が行われる。

このように、実施例２によれば、通知アプリケーションリストを利用して電源供給遮断時の通知状況を迅速に判定することができ、当該判定された通知状況にしたがって、アプリケーションに対する通知を確実に行うことができる。

（実施例３）
図１０（Ａ）は、実施例３において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図１０（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。図１０（Ａ），（Ｂ）の処理は、図７（Ａ），（Ｂ）の処理と基本的には同様であるので、主に、図７（Ａ），（Ｂ）の処理と異なる部分について説明する。

図１０（Ａ）に示すステップＳ１４１〜Ｓ１４７の処理は、図７（Ａ）に示すステップＳ１０１〜Ｓ１０７の処理と同様に行われる。実施例１では、図７（Ａ）に示すステップＳ１０８（通知処理の開始時）において通知未完了フラグが記録され、且つ図７（Ａ）に示すステップＳ１１３（通知処理の完了時）において通知完了フラグが記録されたが、実施例３では、通知処理の途中でアプリケーションに対する通知が行われる度に当該アプリケーションに対応する通知完了フラグが通知状況として記録される。

図１０（Ａ）に示ステップＳ１４８及びＳ１４９の処理は、図７（Ａ）に示すステップＳ１０９及びＳ１１０の処理と同様に行われる。そして、ステップＳ１５０では、ＯＳは、ステップＳ１４９で通知が完了したアプリケーションの情報に対応付けて通知完了フラグを通知状況として記録する。例えば、通知アプリケーションリストにおいて、通知が完了したアプリケーションの情報に対応付けられて通知完了フラグが登録される。その後、図１０（Ａ）に示ステップＳ１５１及びＳ１５２の処理（図７（Ａ）に示すステップＳ１１１及びＳ１１２の処理と同様）が行われる。このように、実施例３では、ステップＳ１４８〜Ｓ１５１のループ処理中に通知が完了したアプリケーションの通知完了フラグが順次記録（ステップＳ１５０）される（つまり、アプリケーション毎に通知完了フラグが記録）。図１１は、実施例３における通知アプリケーションリストの登録内容の一例を示す図である。図１１に示す通知アプリケーションリストには、通知が完了したアプリケーションの識別子等に対応付けられて通知完了フラグ“F0”(h)が登録されている。

なお、ステップＳ１５０において、ステップＳ１４９で通知が完了したアプリケーションのリスト番号（アプリケーションの情報の一例）が通知状況として記録（例えば、通知アプリケーションリストに対応付けられて不揮発性メモリ１２４に記憶）されてもよい。例えば、図１１において、アプリ４への通知が完了した場合、当該アプリ４のリスト番号「Ｎｏ．３」が記録される。この場合において、通知アプリケーションリストのリスト番号順にアプリケーションに対する通知が行われるとき、アプリケーションに対する通知が行われる毎にリスト番号が上書き保存されてもよい。例えば、図１１において、アプリ８への通知が完了した場合、当該アプリ８のリスト番号「Ｎｏ．４」により、アプリ４のリスト番号「Ｎｏ．３」が上書きされる。これにより、通知アプリケーションリストのどのアプリケーションまで通知が行われたかを判定することが可能となる。或いは、ステップＳ１５０において、ステップＳ１４９で通知が完了したアプリケーションの識別子（アプリケーションの情報の一例）が通知状況として記録（例えば、通知アプリケーションリストに対応付けられて不揮発性メモリ１２４に記憶）されてもよい。

一方、図１０（Ｂ）に示す処理では、ＯＳは、上記通知状況に基づいて、全てのアプリケーションの通知状況が完了になっているか否かを判定する（ステップＳ１５５）。例えば、通知アプリケーションリストにおいて全てのアプリケーションに対応付けられて通知完了フラグが登録されているかどうかが判定され、全てのアプリケーションに対応付けられて通知完了フラグが登録されている場合、ＯＳは、全てのアプリケーションの通知状況が完了になっていると判定し（ステップＳ１５５：ＹＥＳ）、図１０（Ｂ）に示す処理は終了する。一方、全てのアプリケーションに対応付けられて通知完了フラグが登録されていない場合（つまり、１つでも通知されていないアプリケーションがある場合）、ＯＳは、全てのアプリケーションの通知状況が完了になっていないと判定し（ステップＳ１５５：ＮＯ）、ステップＳ１５６へ進み、上記通知処理を再実行する。当該再実行される通知処理では、ＯＳは、先ず、通知完了フラグが対応付けられて登録されていないアプリケーション（つまり、未通知のアプリケーション）の情報を通知アプリケーションリストから１つ取得する（ステップＳ１５６）。次いで、ＯＳは、ステップＳ１５６で取得した情報に含まれる識別子に対応するアプリケーションに対して、上述したように、設定変更情報を通知し（ステップＳ１５７）、当該アプリケーションの情報に対応付けて通知完了フラグを通知状況として記録する（ステップＳ１５８）。そして、ステップＳ１５９及びＳ１６０の処理（図７（Ａ）に示すステップＳ１１８及びＳ１１９の処理と同様）が行われる。このように、実施例３では、ＯＳは、通知完了フラグが対応付けられていないアプリケーションに対して通知処理を再実行することになる。

なお、ステップＳ１５０において通知が完了したアプリケーションのリスト番号が通知状況として記録された場合、ステップＳ１５５では、例えば、通知状況として記録されたリスト番号が、通知アプリケーションリストにおいて最後のリスト番号（図１１の例では、アプリ８のリスト番号「Ｎｏ．４」）であるかどうかが判定され、記録されたリスト番号が当該最後のリスト番号である場合、ＯＳは、全てのアプリケーションの通知状況が完了になっていると判定する。一方、記録されたリスト番号が当該最後のリスト番号でない場合、ＯＳは、全てのアプリケーションの通知状況が完了になっていないと判定することになる。この場合に再実行される通知処理では、ＯＳは、記録されたリスト番号に基づき、アプリケーションのリスト番号が記録されなかった（例えば、上書きも含めて記録されなかった）アプリケーションの情報（つまり、未通知のアプリケーション）の情報を通知アプリケーションリストから１つ取得し（ステップＳ１５６）、ステップＳ１５７以降の処理を行うことになる。

或いは、ステップＳ１５０において通知が完了したアプリケーションの識別子が通知状況として記録された場合、ステップＳ１５５では、例えば、通知アプリケーションリストにおける全てのアプリケーションの識別子が記録されているかどうかが判定され、全てのアプリケーションの識別子が記録されている場合、ＯＳは、全てのアプリケーションの通知状況が完了になっていると判定する。一方、全てのアプリケーションの識別子が記録されていない場合、ＯＳは、全てのアプリケーションの通知状況が完了になっていないと判定することになる。この場合に再実行される通知処理では、ＯＳは、上記識別子が記録されていないアプリケーションの情報（つまり、未通知のアプリケーション）の情報を通知アプリケーションリストから１つ取得し（ステップＳ１５６）、ステップＳ１５７以降の処理を行うことになる。

このように、実施例３によれば、アプリケーション毎の通知完了フラグを利用して電源供給遮断時の通知状況を詳細に判定することができ、当該判定された通知状況にしたがって、重複する通知を防ぎつつ（このため、ＣＰＵ１２１の負荷低減を図りつつ）、アプリケーションに対する通知を確実に行うことができる。

（実施例４）
図１２（Ａ）は、実施例４において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図１２（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。図１２（Ａ），（Ｂ）の処理は、図１０（Ａ），（Ｂ）の処理と基本的には同様であるので、主に、図１０（Ａ），（Ｂ）の処理と異なる部分について説明する。

図１２（Ａ）に示すステップＳ１６１〜Ｓ１６９の処理は、図１０（Ａ）に示すステップＳ１４１〜Ｓ１４９の処理と同様に行われる。実施例３では、通知処理の途中でアプリケーションに対する通知が行われる度に当該アプリケーションに対応する通知完了フラグが記録されたが、実施例４では、通知処理の途中でアプリケーションに対する通知が行われる度に当該アプリケーションの情報が通知アプリケーションリストから削除されることで実質的に通知状況が記録される。

ステップＳ１７０では、ＯＳは、ステップＳ１６９で通知が完了したアプリケーションの情報を通知アプリケーションリストから削除する。その後、図１２（Ａ）に示ステップＳ１７１及びＳ１７２の処理（図１０（Ａ）に示すステップＳ１５１及びＳ１５２の処理と同様）が行われる。このように、実施例４では、ステップＳ１６８〜Ｓ１７１のループ処理中に通知が完了したアプリケーションの情報が順次削除（ステップＳ１７０）される。図１３は、実施例４における通知アプリケーションリストの登録内容の一例を示す図である。図１３（Ａ）〜（Ｄ）に示すように、通知が完了したアプリケーションの情報が通知アプリケーションリストから順次削除されている。なお、図１３（Ａ）〜（Ｄ）に示すように、通知アプリケーションリストの末尾から先頭に向かって（つまり、リスト番号が最も大きいアプリケーション（図１３（Ａ）の例では、アプリ８）からリスト番号が最も小さいアプリケーション（図１３（Ａ）の例では、アプリ１）に向かって）順番に通知して、通知が完了したアプリケーションの情報が削除されることが望ましい。

一方、図１２（Ｂ）に示す処理では、ＯＳは、上記通知状況に基づいて、全てのアプリケーションの通知状況が完了になっているか否かを判定する（ステップＳ１７５）。例えば、通知アプリケーションリストにアプリケーションの情報が登録されているかどうかが判定され、アプリケーションの情報が登録されていない場合（つまり、通知アクリケーションリストが空である場合）、ＯＳは、全てのアプリケーションの通知状況が完了になっていると判定し（ステップＳ１７５：ＹＥＳ）、図１２（Ｂ）に示す処理は終了する。一方、１つでもアプリケーションの情報が登録されている場合、ＯＳは、全てのアプリケーションの通知状況が完了になっていないと判定し（ステップＳ１７５：ＮＯ）、ステップＳ１７６へ進み、上記通知処理を再実行する。当該再実行される通知処理では、ＯＳは、先ず、通知アプリケーションリストからアプリケーションの情報を１つ取得する（ステップＳ１７６）。次いで、ＯＳは、ステップＳ１７６で取得した情報に含まれる識別子に対応するアプリケーションに対して、上述したように、設定変更情報を通知し（ステップＳ１７７）、当該アプリケーションの情報を通知アプリケーションリストから削除する（ステップＳ１７８）。そして、ステップＳ１７９及びＳ１８０の処理（図１０（Ａ）に示すステップＳ１５９及びＳ１６０の処理と同様）が行われる。このように、実施例４では、ＯＳは、通知アプリケーションリストから情報が削除されていないアプリケーションに対して通知処理を再実行することになる。

このように、実施例４によれば、通知アプリケーションリストへの登録有無を利用して電源供給遮断時の通知状況を詳細に判定することができ、当該判定された通知状況にしたがって、重複する通知を防ぎつつ（このため、ＣＰＵ１２１の負荷低減を図りつつ）、アプリケーションに対する通知を確実に行うことができる。

（実施例５）
図１４（Ａ）は、実施例５において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図１４（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。図１４（Ａ），（Ｂ）の処理は、図７（Ａ），（Ｂ）の処理と基本的には同様であるので、主に、図７（Ａ），（Ｂ）の処理と異なる部分について説明する。

図１４（Ａ）に示すステップＳ１８１の処理は、図７（Ａ）に示すステップＳ１０１の処理と同様に行われる。そして、ＯＳは、通知事前処理（ステップＳ４）を開始し、アプリケーションの設定変更の基点となる通知イベントを記録し（ステップＳ１８２）、通知事前処理を終了する。例えば、当該通知イベントの情報が通知イベントリストに登録される。なお、通知イベントリスト（未登録）は、例えば上記通知事前処理の開始前に作成される。図１５は、実施例５における通知イベントリストの登録内容の一例を示す図である。図１５（Ａ）に示す通知イベントリストには、リスト番号、通知対象となるアプリケーションの識別子、発生イベント（つまり、通知イベント）、及び変更内容が対応付けられて登録されている。つまり、通知イベントリストは、通知アプリケーションリストにおける先頭のアプリケーションの情報のみが登録される。ただし、発生イベントが複数存在する場合もある。この場合、図１５（Ｂ）に示すように、それぞれの発生イベントの情報が通知アプリケーションリストに登録される。なお、図１５（Ｂ）に示す“Activatedへ変更”は、アプリ１のActivated/Deactivatedの状態変更を示す。また、実施例１では、通知事前処理において通知対象となるアプリケーションの情報が通知アプリケーションリストに登録されたが、実施例５では、通知処理において通知対象となるアプリケーションの情報が通知アプリケーションリストに登録されることになる。

通知事前処理が終了すると、ＯＳは、通知処理（ステップＳ５）を開始し、通知状況として、通知未完了フラグを記録する（ステップＳ１８３）。次いで、ＯＳは、通知アプリケーションリストをＲＡＭ１２２上で作成し、接触型ＩＣチップ１２ａに搭載されているアプリケーションを１つ選定する（ステップＳ１８４）。そして、ステップＳ１８５〜Ｓ１８９の処理（図７（Ａ）に示すステップＳ１０３〜Ｓ１０７の処理と同様）が行われる。この場合のステップＳ１８７では、ＯＳは、通知対象となるアプリケーションの情報を、ＲＡＭ１２２上で作成された通知アプリケーションリストに登録する。また、この場合のステップＳ１８９では、ＯＳは、通知アプリケーションリストは空でないと判定した場合（ステップＳ１８９：ＮＯ）、ステップＳ１９０へ進む一方、通知アプリケーションリストは空であると判定した場合（ステップＳ１８９：ＹＥＳ）、ステップＳ１９４へ進む。その後、ステップＳ１９０〜Ｓ１９４の処理（図７（Ａ）に示すステップＳ１０９〜Ｓ１１３の処理と同様）が行われる。なお、ステップＳ１９０において通知対象となるアプリケーションが特定され、ステップＳ１９１において当該通知対象となるアプリケーションに対して設定変更情報が通知されることになる。また、実施例５では、通知アプリケーションリストが空である場合（ステップＳ１８９：ＹＥＳ）、通知状況として通知完了フラグが記録される（ステップＳ１９４）ことになる。これは、上記再設定が行われた場合であっても、通知アプリケーションが１つも存在しないケースがあるためであり、この場合に、通知完了フラグを記録する必要がある。

一方、図１４（Ｂ）に示す処理では、図７（Ｂ）に示すステップＳ１１５と同様、ＯＳは、上記通知状況に基づいて、上記通知処理が未完了であるか否かを判定する（ステップＳ１９５）。ＯＳは、上記通知処理が未完了でないと判定した場合（ステップＳ１９５：ＮＯ）、図１４（Ｂ）に示す処理は終了する。一方、ＯＳは、上記通知処理が未完了であると判定した場合（ステップＳ１９５：ＹＥＳ）、ステップＳ１９６へ進み、上記通知処理を再実行する。当該再実行される通知処理では、ＯＳは、ステップＳ１８２で記録された通知イベントに基づいて通知処理により通知対象となるアプリケーションを特定し、特定したアプリケーションに対して、上述したように、設定変更情報を通知する。すなわち、当該再実行される通知処理では、図１４（Ａ）に示すステップＳ１８４〜Ｓ１９４の処理と同様に、ステップＳ１９６〜Ｓ２０６の処理が行われる。なお、ステップＳ２０２において通知対象となるアプリケーションが特定され、ステップＳ２０３において当該通知対象となるアプリケーションに対して設定変更情報が通知されることになる。

このように、実施例５によれば、通知未完了フラグ及び通知完了フラグを利用して電源供給遮断時の通知状況を迅速に判断することができ、当該判定された通知状況にしたがって、アプリケーションに対する通知を確実に行うことができる。さらに、実施例５では、アプリケーションの設定変更の基点となる通知イベントを不揮発性メモリ１２４に保存すればよいので、実施例１等のように通知アプリケーションリストを保存する構成に比べて必要となるメモリリソースの低減を図ることができる。

（実施例６）
図１６（Ａ）は、実施例６において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図１６（Ｂ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。図１６（Ａ），（Ｂ）の処理は、図１４（Ａ），（Ｂ）の処理と基本的には同様であるので、主に、図１４（Ａ），（Ｂ）の処理と異なる部分について説明する。実施例６では、実施例５と同様、図１５に示すように、通知イベントリストに、通知イベントの情報が登録される。

図１６（Ａ）に示すステップＳ２１１及びＳ２１２の処理は、図１４（Ａ）に示すステップＳ１８１及びＳ１８２の処理と同様に行われる。実施例５では、図１４（Ａ）に示すステップＳ１８３（通知処理の開始時）において通知未完了フラグが記録されたが、実施例６では、通知未完了フラグが記録されずにステップＳ２１３〜Ｓ２２２の処理（図１４（Ａ）に示すステップＳ１８４〜Ｓ１９３の処理と同様）が行われる。そして、ステップＳ２２３では、通知イベントが削除される。例えば、通知イベントリストから、通知イベントの情報が削除されることで、通知イベントリストが空になる。或いは、通知イベントリスト自体が削除されてもよい。

一方、図１６（Ｂ）に示す処理では、ＯＳは、上記通知状況に基づいて、上記通知処理が未完了であるか否かを判定する（ステップＳ２２５）。例えば、通知イベントリストが空であるかどうかが判定され、空である場合、ＯＳは、上記通知処理が未完了でないと判定し（ステップＳ２２５：ＮＯ）、図１６（Ｂ）に示す処理は終了する。一方、通知イベントリストが空でない場合、ＯＳは、上記通知処理が未完了であると判定し（ステップＳ２２５：ＹＥＳ）、ステップＳ２２６へ進み、上記通知処理を再実行する。当該再実行される通知処理では、図１６（Ａ）に示すステップＳ２１３〜Ｓ２２３の処理と同様に、ステップＳ２２６〜Ｓ２３６の処理が行われる。

このように、実施例６によれば、通知イベントリストを利用して電源供給遮断時の通知状況を迅速に判断することができ、当該判定された通知状況にしたがって、アプリケーションに対する通知を確実に行うことができる。さらに、実施例６では、実施例５と同様、必要となるメモリリソースの低減を図ることができる。

（変形例）
次に、図１７を参照して、実施例１〜実施例６に共通する変形例について説明する。変形例は、アプリケーションの設定変更から通知処理の実行前までの間に、ＵＩＭカード１２への電源供給が遮断された場合も考慮した実施例である。すなわち、アプリケーションの設定変更から通知処理の実行前までの間に、ＵＩＭカード１２への電源供給が遮断された場合、設定は変更されているが通知がされないといった不整合が生じうる。そのため、変形例では、このような場合、アプリケーションの設定を変更前の状態に戻すように構成される。図１７（Ａ），（Ｂ）は、変形例において、ＵＩＭカード１２が設定変更コマンドを受信したときの処理の一例を示すフローチャートであり、図１７（Ｃ）は、当該処理中に電源供給が遮断しその後に電源供給が復旧したときの処理の一例を示すフローチャートである。図１７（Ａ）に示す処理は、実施例１〜実施例４に対応し、図１７（Ｂ）に示す処理は、実施例５及び実施例６に対応する。また、図１７（Ｃ）に示す処理は、実施例１〜実施例６に対応する。

図１７（Ａ）に示す処理では、ＯＳは、先ず、設定変更中フラグ（設定変更中であることを示す情報）を記録する（ステップＳ３０１）。設定変更中フラグの記録では、例えば、設定変更中フラグを示す“F1”(h)が不揮発性メモリ１２４における所定の記憶領域（通知未完了フラグ及び通知完了フラグが記憶される領域とは異なる記憶領域）に記憶される（言い換えれば、“00”(h)が“F1”(h)に書き換えられる）。設定変更中フラグの記録後、ステップＳ３０２〜Ｓ３０７の処理（図７（Ａ）に示すステップＳ１０１〜Ｓ１０６の処理と同様）が行われる。そして、ＯＳは、ステップＳ３０７において、まだ選定されていないアプリケーションがない（つまり、全てのアプリケーションを選定した）と判定した場合（ステップＳ３０７：ＮＯ）、設定変更完了フラグ（設定変更完了であることを示す情報）を記録する（ステップＳ３０８）。設定変更完了フラグの記録では、例えば、設定変更完了フラグを示す“F2”(h)が不揮発性メモリ１２４における所定の記憶領域（通知未完了フラグ、通知完了フラグ、及び設定変更中フラグが記憶される領域とは異なる記憶領域）に記憶される（言い換えれば、“00”(h)が“F2”(h)に書き換えられる）。或いは、設定変更完了フラグの記録では、例えば、設定変更完了フラグを示す“F2”(h)が不揮発性メモリ１２４において設定変更中フラグが記憶される領域と同じ記憶領域）に記憶される。この場合、“F1”(h)が“F2”(h)に書き換えられる。設定変更完了フラグの記録後、実施例１のステップＳ１０７、実施例２のステップＳ１２７、実施例３のステップＳ１４７、または実施例４のステップＳ１６７へ移行して、上述した処理が行われる。

一方、図１７（Ｂ）に示す処理では、ＯＳは、図１７（Ａ）に示す処理と同様、設定変更中フラグを記録する（ステップＳ３１１）。設定変更中フラグの記録後、ステップＳ３１２及びＳ３１３の処理（図１４（Ａ）に示すステップＳ１８１及びＳ１８２の処理と同様）が行われる。次いで、ＯＳは、図１７（Ａ）に示す処理と同様、設定変更完了フラグを記録する（ステップＳ３１４）。設定変更完了フラグの記録後、実施例５のステップＳ１８３、または実施例６のステップＳ２１３へ移行して、上述した処理が行われる。

一方、図１７（Ｃ）に示す処理では、ＯＳは、設定変更中の電源断であるか否かを判定する（ステップＳ３１５）。例えば、設定変更中フラグ及び設定変更完了フラグが双方とも記録されているかどうかが判定され、双方とも記録されている場合、ＯＳは、設定変更中の電源断でないと判定し（ステップＳ３１５：ＮＯ）、実施例１のステップＳ１１５、実施例２のステップＳ１３５、実施例３のステップＳ１５５、実施例４のステップＳ１７５、実施例５のステップＳ１９５、または実施例６のステップＳ２２５へ移行し、上述した処理を行う。一方、設定変更中フラグが記録されており、且つ設定変更完了フラグが記録されていない場合（すなわち、アプリケーションの設定変更から通知処理の実行前までの間に、電源供給が遮断され、当該遮断後に電源供給が再開した場合）、ＯＳは、設定変更中の電源断であると判定し（ステップＳ３１５：ＹＥＳ）、設定変更されたそれぞれのアプリケーションの設定を変更前の状態に戻す（ステップＳ３１６）。これにより、例えば、非接触通信プロトコル、或いはActivated/Deactivatedの状態が再設定前の状態に戻される。なお、設定変更中フラグが記憶される領域と、設定変更完了フラグが記憶される領域とが同じ記憶領域である場合の例では、ステップＳ３１５において、設定変更中フラグ“F1”(h)が記録されている場合、設定変更中の電源断であると判定される（ステップＳ３１５：ＹＥＳ）一方、設定変更完了フラグ“F2”(h)が記録されている場合、設定変更中の電源断でないと判定される（ステップＳ３１５：ＮＯ）ことになる。

このように、変形例によれば、アプリケーションの設定変更から通知処理の実行前までの間に電源供給が遮断された場合であっても、設定は変更されているが通知がされないといった不整合を防止することができる。

以上説明したように、実施例１〜６及び変形例を含む実施形態によれば、携帯端末１に搭載されたＵＩＭカード１２は、選択中の少なくとも何れか１つのアプリケーションの設定が変更される場合、設定変更されたアプリケーションを含む複数のアプリケーションの設定に基づいて、それぞれのアプリケーションの再設定を行い、通知対象となるアプリケーションに対して再設定されたことを示す設定変更情報を通知する通知処理を実行し、且つ通知状況を記録する。そして、ＵＩＭカード１２は、上記通知処理中に電源供給が遮断され、当該遮断後に電源供給が復旧した場合、上記通知状況にしたがって、通知処理を再実行するように構成したので、設定変更の通知中に電源供給遮断が発生したとしても、不整合が発生することなくアプリケーションの動作を保障することができる。

なお、実施例１〜６及び変形例を含む実施形態では、設定変更されたアプリケーションを含む複数のアプリケーションの設定に基づいて、それぞれのアプリケーションに共通する再設定が行われた場合に、上記通知処理が実行され、当該通知処理中にＵＩＭカード１２への電源供給が遮断され、当該遮断後に電源供給が再開した場合、上記通知処理の状況にしたがって、当該通知処理が再実行される例について説明した。しかし、アプリケーションの設定が変更された場合に、複数のアプリケーションのうち通知対象となるアプリケーションに対して設定変更情報を通知する通知処理が実行され、当該通知処理中にＵＩＭカード１２への電源供給が遮断され、当該遮断後に電源供給が再開した場合、上記通知処理の状況にしたがって、当該通知処理が再実行されるように構成してもよい。つまり、共通の再設定の実施の有無、共通の再設定を実施した結果に関係なく、アプリケーションの設定変更のみを通知する通知処理が実行されてもよい。この場合の実施例を以下に説明する。

例えば、接触型ＩＣチップ１２ａには、ＳＤとして、ポイントサービス会社の管理アプリが搭載され、複数のアプリケーションとして、「ポイントカード一覧出力アプリ」、「ポイントカードアプリA」、「ポイントカードアプリB」、「ポイントカードアプリC」、及び「チケットアプリ」が搭載されているものとする。ここで、「ポイントカード一覧出力アプリ」は、Activated の状態にあるポイントカードアプリの一覧を出力する機能を持つ。なお、「ポイントカードアプリA」及び「ポイントカードアプリB」は、Activated の状態にある一方、「ポイントカードアプリC」は、Deactivatedの状態にあるものとする。

（通知ケース１）
「ポイントサービス会社の管理アプリ」が、「ポイントカードアプリA」をActivatedからDeactivatedの状態に変更（設定変更）した場合、上記通知処理では、関連するアプリケーションである「ポイントカードアプリA」と「ポイントカード一覧出力アプリ」が通知対象として選定され、選定された「ポイントカードアプリA」と「ポイントカード一覧出力アプリ」に対して上記設定変更情報が通知される。

（通知ケース２）
「ポイントサービス会社の管理アプリ」が、「ポイントカードアプリA」の通信速度を変更した場合、上記通知処理では、関連するアプリケーションである「ポイントカードアプリA」と「ポイントカード一覧出力アプリ」が通知対象として選定され、選定された「ポイントカードアプリA」と「ポイントカード一覧出力アプリ」に対して上記設定変更情報が通知される。

（通知ケース３）
「ポイントカードアプリA」が、「ポイントカードアプリA」をActivatedからDeactivatedの状態に自ら変更した場合、上記通知処理では、関連するアプリケーションである「ポイントカード一覧出力アプリ」が通知対象として選定され、選定された「ポイントカード一覧出力アプリ」に対して上記設定変更情報が通知される。この場合、「ポイントカードアプリA」は自ら設定変更したので、通知の必要はない。

なお、関連するかどうかは、例えば、設定変更されたアプリケーションかどうか、及び設定変更されたアプリケーションと紐付けられているかどうかの少なくとも何れか一方により決定される。また、設定変更されたアプリケーションとの紐付けは、コマンドによって指定することができる。例えば、設定変更されるアプリケーションと、当該設定変更がされたときに通知対象となるアプリケーションとの対応関係を示すリストを記憶しておくとよい。

図１８（Ａ）〜（Ｃ）は、設定変更されるアプリケーションと、当該設定変更がされたときに通知対象となるアプリケーションとの対応関係を示すリストの例を示す図である。なお、図１８の例では、設定変更されるアプリケーションを、「変更アプリ」と称しており、当該設定変更がされたときに通知対象となるアプリケーションを、「通知アプリ」と称している。図１８（Ａ）に示すように、アプリケーション単位で通知アプリを紐づけて設定してもよいし、図１８（Ｂ）に示すように、アプリケーションのデータ単位で紐づけて設定してもよい。また、図１８（Ｃ）に示すように、全てのアプリケーションに対して通知アプリを紐づけて設定してもよく、この場合、上記の通知ケース１〜３において「チケットアプリ」が通知対象として選定され、当該「チケットアプリ」にも上記設定変更情報が通知されることになる。

１ 携帯端末
１１ ＣＬＦ
１２ ＵＩＭカード
１２ａ 接触型ＩＣチップ
１３ ベースバンドプロセッサ
１４ バッテリー
１２１ ＣＰＵ
１２２ ＲＡＭ
１２３ ＲＯＭ
１２４ 不揮発性メモリ
１２５ Ｉ／Ｏ回路

Claims (11)

1. オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行う電子情報記憶媒体であって、
   少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録する実行手段と、
   前記通知処理中に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行する再実行手段と、
   を備えることを特徴とする電子情報記憶媒体。
2. 少なくとも何れか１つの前記アプリケーションの設定が変更される場合、設定変更された前記アプリケーションを含む前記複数のアプリケーションの設定に基づいて、それぞれの前記アプリケーションの再設定を行う再設定手段を更に備え、
   前記実行手段は、前記再設定手段により再設定された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録することを特徴とする請求項１に記載の電子情報記憶媒体。
3. 前記設定変更から前記通知処理の実行前までの間に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記アプリケーションの設定を変更前の状態に戻す復帰手段を更に備えることを特徴とする請求項１または２に記載の電子情報記憶媒体。
4. 前記実行手段は、前記通知処理において通知が完了した前記アプリケーションの情報に対応付けて通知完了情報を、前記通知処理の状況として記録し、
   前記再実行手段は、前記通知完了情報が対応付けられていない前記アプリケーションに対して前記通知処理を再実行することを特徴とする請求項１乃至３の何れか一項に記載の電子情報記憶媒体。
5. 前記実行手段は、前記通知処理において通知が完了した前記アプリケーションの情報を、前記通知処理の状況として記録し、
   前記再実行手段は、前記アプリケーションの情報が記録されていない前記アプリケーションに対して前記通知処理を再実行することを特徴とする請求項１乃至３の何れか一項に記載の電子情報記憶媒体。
6. 前記実行手段は、通知対象となるアプリケーションの情報を登録するリストから、前記通知処理において前記通知が完了した前記アプリケーションの情報を削除し、
   前記再実行手段は、前記リストから前記情報が削除されていないアプリケーションに対して前記通知処理を再実行することを特徴とする請求項１乃至３の何れか一項に記載の電子情報記憶媒体。
7. 前記実行手段は、前記通知処理の状況として、前記通知処理の開始時に通知未完了情報を記録し、前記通知処理の完了時に通知完了情報を記録し、
   前記再実行手段は、前記通知未完了情報が記録され、且つ前記通知完了情報が記録されていない場合に限り、前記通知処理を再実行することを特徴とする請求項１乃至３の何れか一項に記載の電子情報記憶媒体。
8. 前記実行手段は、前記アプリケーションの設定変更の基点となるイベントを記録し、
   前記再実行手段は、前記記録されたイベントに基づいて前記通知処理により通知対象となる前記アプリケーションを特定し、特定した前記アプリケーションに対して前記通知処理を再実行することを特徴とする請求項１乃至３の何れか一項に記載の電子情報記憶媒体。
9. オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行うＩＣカードであって、
   少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録する実行手段と、
   前記通知処理中に前記ＩＣカードへの電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行する再実行手段と、
   を備えることを特徴とするＩＣカード。
10. オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行う電子情報記憶媒体が備えるプロセッサにより実行される通知方法であって、
    少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録するステップと、
    前記通知処理中に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行するステップと、
    を含むことを特徴とする通知方法。
11. オペレーティングシステム及び前記オペレーティングシステム上で動作可能に設定される複数のアプリケーションを搭載し、外部装置と通信を行う電子情報記憶媒体が備えるプロセッサに、
    少なくとも何れか１つの前記アプリケーションの設定が変更された場合、前記複数のアプリケーションのうち少なくとも何れか１つのアプリケーションに対して前記設定変更されたことを示す情報を通知する通知処理を実行し、且つ当該通知処理の状況を記録するステップと、
    前記通知処理中に前記電子情報記憶媒体への電源供給が遮断され、当該遮断後に電源供給が再開した場合、前記通知処理の状況にしたがって、前記通知処理を再実行するステップと、
    を実行させることを特徴とする通知処理プログラム。

Images