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

電子情報記憶媒体、ｉｃカード、削除処理方法、及び削除処理プログラム Download PDF

Info

Publication number
JP6822158B2
JP6822158B2 JP2017005316A JP2017005316A JP6822158B2 JP 6822158 B2 JP6822158 B2 JP 6822158B2 JP 2017005316 A JP2017005316 A JP 2017005316A JP 2017005316 A JP2017005316 A JP 2017005316A JP 6822158 B2 JP6822158 B2 JP 6822158B2
Authority
JP
Japan
Prior art keywords
application
executable file
deleted
requested
deletion
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017005316A
Other languages
English (en)
Other versions
JP2018116366A (ja
Inventor
龍平 渡辺
龍平 渡辺
満里子 野地
満里子 野地
深谷　宗志
宗志 深谷
裕文 上口
裕文 上口
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dai Nippon Printing Co Ltd
Original Assignee
Dai Nippon Printing Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Dai Nippon Printing Co Ltd filed Critical Dai Nippon Printing Co Ltd
Priority to JP2017005316A priority Critical patent/JP6822158B2/ja
Publication of JP2018116366A publication Critical patent/JP2018116366A/ja
Application granted granted Critical
Publication of JP6822158B2 publication Critical patent/JP6822158B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Credit Cards Or The Like (AREA)
  • Stored Programmes (AREA)

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）１２３、不揮発性メモリ１２４、及びＩ／Ｏ回路１２５を備えて構成される。なお、Ｉ／Ｏ回路１２５には、例えばISO7816等によって定められたＣ１〜Ｃ８の８個の端子が備えられている。Ｃ１端子は電源端子（ＶＣＣ）であり、Ｃ５端子はグランド端子（ＧＮＤ）である。また、Ｃ２端子は、リセット端子（ＲＳＴ）であり、ベースバンドプロセッサ１３とのインターフェースのリセット信号を入力するために用いられる。また、Ｃ３端子は、クロック端子（ＣＬＫ）であり、ベースバンドプロセッサ１３とのインターフェースのクロックを入力するために用いられる。また、Ｃ７端子は、ベースバンドプロセッサ１３との間のインターフェースを担う端子であり、ＵＩＭカード１２とベースバンドプロセッサ１３との間の通信のために用いられる。また、Ｃ６端子は、ＣＬＦ１１との間のインターフェースを担う端子（ＳＷＩＯ）であり、ＣＬＦ１１との間の通信のために用いられる。なお、ＣＬＦ１１とＵＩＭカード１２間のインターフェースには上述したように、ＳＷＰが適用される。
ＣＰＵ１２１は、ＲＯＭ１２３または不揮発性メモリ１２４に記憶された各種プログラムを実行するプロセッサ（コンピュータ）である。不揮発性メモリ１２４には、例えばフラッシュメモリが適用される。不揮発性メモリ１２４に記憶される各種プログラム、及びデータの一部は、ＲＯＭ１２３に記憶されてもよい。なお、不揮発性メモリ１２４は、「Electrically Erasable Programmable Read-Only Memory」であってもよい。本実施形態において、ＲＯＭ１２３または不揮発性メモリ１２４との何れかに記憶されるプログラムには、ＯＳ、仮想マシン、本発明の削除処理プログラム、複数のアプリケーションプログラム、及び複数のＳＤプログラム等が含まれる。なお、本発明の削除処理プログラムは、ＯＳまたはＳＤプログラム内に組み込まれてもよいし、或いは、ＯＳ及びＳＤプログラムとは独立したミドルウェアとしてインストールされてもよい。
アプリケーションプログラムは、ＵＩＭカード１２においてアプリケーションインスタンス（これを、「アプリケーション」という）の機能を実現するための複数種類の実行可能ファイル（言い換えれば、パッケージ）として記憶される。実行可能ファイルの例として、Java Card CAP（Converted Applet) Fileが挙げられ、アプリケーションの例として、Java Appletが挙げられる。実行可能ファイルは、ＵＩＭカード１２内へロードされ、ＵＩＭカード１２内の他の実行可能ファイルとリンクして使用される。アプリケーション（言い換えれば、アプレット）は、実行可能ファイルから生成（言い換えれば、インスタンス化）された複数のオブジェクトの集合であり、ＯＳからのコマンドを処理する実体である。つまり、オブジェクトは、アプリケーションの構成要素である。オブジェクトは、実行可能ファイルにおいて定義されたクラス（言い換えれば、アプレットクラス）に基づき生成される。クラスは、オブジェクトを一般化した雛形であり、メソッド、及びフィールド（つまり、インスタンスフィールド）を定義する。つまり、クラスは、数多くあるメソッド及びフィールドを種類ごとに分類して、適切な単位に分割するというモジュール化の役割を有する。メソッドは、そのクラスの動作（つまり、複数の処理をプログラムコード（例えば、バイトコード）で記述されたもの）を表し、フィールドは、そのクラスの属性を表す。そして、例えば、関連する複数のクラスが纏められることで１つの実行可能ファイルを生成することができる。なお、各クラスには、それぞれ固有の識別子としてクラスＩＤが付与される。また、ＵＩＭカード１２に記憶された各実行可能ファイル及び各アプリケーションには、それぞれ固有の識別子としてＡＩＤが付与される。
図３は、実行可能ファイルＦ１１の構成例を示す概念図である。図３に示す実行可能ファイルＦ１１は、インポートリスト、アプレットクラス情報、クラス情報、プログラムコード、スタティックフィールド情報、及びエクスポートリストを含む。ここで、インポートリストは、実行可能ファイルＦ１１から参照する他の実行可能ファイル（外部公開された他のパッケージ）のリストである。実行可能ファイルＦ１１から参照する他の実行可能ファイルとは、実行可能ファイルＦ１１がインポート（Import）する他の実行可能ファイルを意味する。これにより、実行可能ファイルＦ１１と当該他の実行可能ファイルとがリンクされる。アプレットクラス情報は、実行可能ファイルＦ１１からインタンス化可能なオブジェクトに関する情報である。なお、いわゆるライブラリパッケージの場合、アプレットクラス情報は存在しない。クラス情報は、実行可能ファイルＦ１１を構成する全てのクラスの情報であり、クラスの継承関係、メソッド構成、フールド構成、及びアドレス情報などを含む。プログラムコードは、実行可能ファイルＦ１１内の全てのメソッド（各クラスが定義するメソッド）のプログラムコードの集合である。スタティックフィールド情報は、実行可能ファイルＦ１１に属する全てのスタティックフィールドの情報である。エクスポートリストは、実行可能ファイルＦ１１の参照が許可された他の実行可能ファイルまたはアプリケーション（オブジェクト）のリストである。エクスポートリストでは、参照が許可された他の実行可能ファイルまたはアプリケーションに対して許可されるリソース（クラス、メソッド、フィールド等）の情報が対応付けられている。
ＳＤプログラムは、ＵＩＭカード１２においてＳＤ（Security Domain）の機能を実現するためのプログラムである。ＳＤとは、例えば事業者が提供するサービスを実現するうえで必要となるＵＩＭカード１２内のカードコンテント（つまり、接触型ＩＣチップ１２ａに搭載されたカードコンテント）を管理するための機能を提供する管理アプリケーションである。以下、ＳＤを、「管理アプリ」という。カードコンテントとは、上述した実行可能ファイルやアプリケーションである。管理アプリと、実行可能ファイル及びアプリケーションとの間で階層構造が形成される。管理者は、管理アプリにより、実行可能ファイル及びアプリケーションを管理することができる。管理者とは、管理アプリのＵＩＭカード１２外における実体であり、例えば、サービスを提供する事業者（サービス提供者）が該当する。また、カードコンテントを管理するための機能とは、例えば、実行可能ファイルのロード、アプリケーションの生成（インスタンス化）、実行可能ファイルやアプリケーションの削除、アプリケーションへのデータの書込み（パーソナライズ）などである。なお、管理アプリには、ＩＳＤ（Issuer Security Domain）とＳＳＤ（Supplementary Security Domains）とがある。例えば、ＩＳＤは、上記機能をサポートすることで、ＵＩＭカード１２のカードコンテントに対して、ＵＩＭカード１２上でサービスを提供する事業者等の管理及びセキュリティポリシーを実現する。なお、ＵＩＭカード１２に記憶された各管理アプリには、それぞれ固有の識別子としてＡＩＤが付与される。
１つのＵＩＭカード１２には、様々な事業者が様々なサービスを提供するために、それぞれの管理アプリにより管理されるカードコンテントが記憶されるようになっているが、この中には、参照関係を持つカードコンテントが存在する。参照関係は、同一の事業者のカードコンテント間ばかりでなく、異なる事業者のカードコンテンツ間でも生じる。参照関係には、依存（依存関係ともいう）、静的な参照関係、及び動的な参照関係がある。複数の実行可能ファイル間の参照関係を依存という。
図４は、管理アプリ、実行可能ファイル、及びアプリケーション間の階層構造における実行可能ファイル間の依存の一例を示す概念図である。図４の例では、管理アプリＳＤ１、及び管理アプリＳＤ２が、それぞれ階層構造における最上位に位置（存在）している。管理アプリＳＤ１の配下（管理下）には、実行可能ファイルＦ１、及び他の管理アプリＳＤ１１が位置している。この例では、管理アプリＳＤ１は、実行可能ファイルＦ１ばかりでなく、他の管理アプリＳＤ１１をも管理する。このため、実行可能ファイルＦ１、及び管理アプリＳＤ１１には、管理アプリＳＤ１のセキュリティポリシーが適応される。さらに、管理アプリＳＤ１１の配下には、実行可能ファイルＦ１１と、当該実行可能ファイルＦ１１から生成されたアプリケーションであるアプリＡ１１１及びアプリＡ１１２とが位置している。つまり、管理アプリＳＤ１１は、実行可能ファイルＦ１１、アプリＡ１１１、及びアプリＡ１１２を管理する。このため、実行可能ファイルＦ１１、アプリＡ１１１、及びアプリＡ１１２には、管理アプリＳＤ１１のセキュリティポリシーが適応される。一方、管理アプリＳＤ２の配下には、実行可能ファイルＦ２と、当該実行可能ファイルＦ２から生成されたアプリケーションであるアプリＡ２１及びアプリＡ２２と、上記実行可能ファイルＦ１１から生成されたアプリケーションであるアプリＡ１１３とが位置している。つまり、管理アプリＳＤ２は、実行可能ファイルＦ２、アプリＡ２１、アプリＡ２２、及びアプリＡ１１３を管理する。このため、実行可能ファイルＦ２、アプリＡ２１、アプリＡ２２、及びアプリＡ１１３のセキュリティポリシーが適応される。
図４に示す階層構造において、実行可能ファイルＦ１１は、実行可能ファイルＦ１を参照しているため、実行可能ファイルＦ１１は実行可能ファイルＦ１に直接的に依存する。一方、実行可能ファイルＦ２は、実行可能ファイルＦ１１を参照しているため、実行可能ファイルＦ２は、実行可能ファイルＦ１１に直接的に依存する。この場合、実行可能ファイルＦ１１は、実行可能ファイルＦ１に依存しているため、実行可能ファイルＦ２は、実行可能ファイルＦ１１を介して実行可能ファイルＦ１に間接的に依存するということになる。このように、依存には、直接的な依存と、間接的な依存とがある。
一方、実行可能ファイルとアプリケーションとの間の参照関係を静的な参照関係という。例えば、ＵＩＭカード１２内で実行可能ファイルから生成されたアプリケーションと生成元となった実行可能ファイルとの間に静的な参照関係が生じる。静的な参照は、例えば、実行可能ファイル内のインポートコンポーネント（要素）、または実行可能ファイルのリンク時に確保されるメモリ領域（スタティックフィールド)に記憶される。静的な参照の例として、コンテキストがある。コンテキストは、実行可能ファイルの識別子で、実行可能ファイルとアプリケーションの静的な参照関係を示すために用いられる。
図５は、管理アプリ、実行可能ファイル、及びアプリケーション間の階層構造における実行可能ファイルとアプリケーションとの間の静的な参照関係の一例を示す概念図である。図５に示す階層構造は、図４に示す階層構造と同様である。図５に示す階層構造において、アプリＡ２１が所有するオブジェクトＯ２１４は、実行可能ファイルＦ１１を参照（この例では、オブジェクトＯ２１４のクラスＩＤにより実行可能ファイルＦ１１に含まれるクラス情報を参照）しているため、アプリＡ２１と実行可能ファイルＦ１１との間には静的な参照関係がある。また、図５に示す階層構造において、実行可能ファイルＦ２は、アプリＡ１１１を参照しているため、実行可能ファイルＦ２とアプリＡ１１１との間には静的な参照関係がある。
一方、複数のアプリケーション間の参照関係を動的な参照関係という。ＵＩＭカード１２内でアプリケーションが他のアプリケーションと所有する情報や機能を相互に共有することにより、アプリケーション間に動的な参照関係が生じる。動的な参照は、例えば、参照型インスタンスフィールド、或いは配列の要素にオブジェクト参照が記憶される。動的な参照の例であるオブジェクト参照は、オブジェクトに対して与えられる識別子を他のオブジェクトが保持することで、アプリケーション間で共有されたオブジェクトを示す。オブジェクトを所有するアプリケーションの当該オブジェクトに対するオブジェクト参照を他のアプリケーションが保持する場合、アプリケーション間に動的な参照関係が生じる。
図６は、管理アプリ、実行可能ファイル、及びアプリケーション間の階層構造におけるアプリケーション間の動的な参照関係の一例を示す概念図である。図６に示す階層構造は、図４に示す階層構造と同様である。図６に示す階層構造において、アプリＡ２２が所有するオブジェクトＯ２２１は、アプリＡ１１２を参照（この例では、オブジェクトＯ２２１の参照型変数によりアプリＡ１１２が所有するオブジェクトＯ１１２１を参照）しているため、アプリＡ２２とアプリＡ１１２との間には動的な参照関係がある。
ＯＳは、例えばデータ通信やメモリへの読み書きなど、接触型ＩＣチップ１２ａの基本的な機能を担う。仮想マシンは、例えば、Java Card Virtual Machineであり、ＯＳ上でアプリケーションに含まれるバイトコードを解釈し、当該バイトコードに応じた命令を実行（つまり、アプリケーションを実行）する。ＯＳ上で仮想マシンがアプリケーションを実行するための環境を、ＲＥ（Runtime Environment）という。ＲＥは、ＯＳの一機能であり、本発明における第１受信手段、第２受信手段、変更手段、及び設定手段の一例である。
ここで、ＲＥにおけるＯＳ管理について説明する。図７は、ＲＥにおけるＯＳ管理を示す概念図である。図７に示すように、ＲＥは、メモリ管理領域Ｍ、レジストリＲ、及びオブジェクトテーブルＴを備える。メモリ管理領域Ｍは、ロード及びインストールされたカードコンテント（つまり、実行可能ファイル、及びアプリケーション）を記憶する領域である。
レジストリＲは、ＵＩＭカード１２内の全ての実行可能ファイル及び全てのアプリケーションの管理情報を保持する。実行可能ファイルの管理情報には、当該実行可能ファイルのＡＩＤ、当該実行可能ファイルを管理する管理アプリのＡＩＤ、及び実行可能ファイルの状態（内部状態）が含まれる。このように、実行可能ファイルは、自身の管理アプリと対応つけられてレジストリＲ内で管理される。なお、実行可能ファイルの状態は、実行可能ファイルのライフサイクル“Lifecycle”ともいう。図７の例では、“Lifecycle”が“LOADED”として記憶されている。すなわち、ＲＥは、それぞれの実行可能ファイルの状態を“Lifecycle”により管理する。アプリケーションの管理情報には、当該アプリケーションのＡＩＤ、当該アプリケーションを管理する管理アプリのＡＩＤ、当該アプリケーションの生成元となった実行可能ファイルのＡＩＤ、及び当該アプリケーションの状態（内部状態）が含まれる。このように、アプリケーションは、自身の管理アプリと対応づけられてレジストリＲ内で管理される。なお、アプリケーションの状態は、アプリケーションの“Lifecycle”ともいう。
オブジェクトテーブルＴは、ＵＩＭカード１２内の全てのオブジェクト、及び全てのオブジェクトの管理情報を保持する。オブジェクトの管理情報には、当該オブジェクトの所有者の識別子（例えば、オブジェクトを所有するアプリケーションのＡＩＤ）、及び当該オブジェクトを所有するアプリケーションの生成元となった実行可能ファイルのコンテキストなどが含まれる。つまり、オブジェクトテーブルＴは、全てのオブジェクトへの参照を持つ。
［２．ＵＩＭカード１２内のカードコンテントの削除］
次に、ＵＩＭカード１２内のカードコンテントの削除について説明する。管理者が自身の管理アプリにより管理されるカードコンテントを削除したい場合、ＵＩＭカード１２に対して削除要求（削除コマンド）を行うことができる。しかしながら、ＵＩＭカード１２内においてカードコンテントが参照関係を持つ場合、管理者は自身の管理アプリにより管理されるカードコンテントを即座に削除することができない。参照関係にあるカードコンテントの管理者が同一の場合、管理者は自身の管理アプリにより、参照する側（カードコンテント）を先に削除、或いは当該カードコンテントを参照するための参照情報を消去すればよいが、これを実現するためには参照関係を把握しながら、削除の順番を考慮して複数の削除コマンドを発行する必要があり、非常に時間と費用を要する。
一方、参照関係にあるカードコンテントの管理者が異なる場合、不要となったカードコンテントの管理者が参照関係を解消するためには、別の管理者の管理アプリにより管理されているカードコンテントを削除、或いはその参照情報を消去する必要があるが、これらの処理は管理者が異なるため直接実行することができない。よって、自身のカードコンテントの削除を望む管理者は、参照する側の管理者に対して、カードコンテントの削除或いはその参照情報の消去を依頼しなければならず、独力で削除することができない。ただし、このように依頼したとしても参照する側の管理者が上記削除及び消去を拒むことも考えられるため、直ぐに削除できない可能性がある。将来、参照する側が削除された場合、参照された側を削除することは可能だが、これを実現するためには、参照する側が削除されたことを通知してもらう必要があり、人為的な取り決め（例えば、契約）などにより実現するほかない。
また、カードコンテントの管理者がサービス運用中に変更されることで参照関係が生まれる場合がある。例えば、サービスの仕組み（実行可能ファイル）の作成者と、その仕組みを使った具体的なサービスを、ＵＩＭカードのユーザへ提供するサービス提供者が異なる場合である。この例では、作成者が実行可能ファイルの管理者であり、サービス提供者はアプリケーションの管理者となる。つまり、実行可能ファイルから生成されたアプリケーションは、当初作成者の管理下にあるが、その後、サービス提供者へ委譲され管理者が変更される。アプリケーションはインスタンスであり、サービスを実現するための機能は実行可能ファイルとして記憶されているため、アプリケーションが動作するためには実行可能ファイルが必要となり、これが参照関係となる。このような状況で、作成者がサービスの仕組みである実行可能ファイルを削除したい場合、参照関係があるため削除できない。一方、サービス提供者としても作成者より削除を依頼されてもサービスの可用性等の観点より直ぐに削除することは困難であることが予想される。
図８は、カードコンテントの管理者がサービス運用中に変更された場合の一例を示す概念図である。図８の例では、サービスの仕組みはポイントサービスであり、作成者はポイントサービス事業者Ｘであり、提供者はポイントサービスと自社のサービスを連携させた鉄道会社、コンビニエンスストア、及び百貨店である。ポイントサービス事業者Ｘがポイントサービスを何等か事情により中止するために、実行可能ファイルＦＸを削除するときに、鉄道会社がポイントサービス事業者Ｘの実行可能ファイルＦＸを基にインスタンス化されたポイントアプリＡＸ１によりポイントサービスを提供中であると、鉄道会社は即座にポイントアプリＡＸ１を削除するわけにはいかない。そのため、ポイントサービス事業者Ｘは自身の実行可能ファイルＦＸを即座に削除できない。また、実行可能ファイルＦＸがＵＩＭカード内に存在するため、他の提供者（例えば、コンビニエンスストア）が新たに実行可能ファイルＦＸを基にインスタンス化してポイントアプリＡＸ２を生成する可能性がある。これは、ポイントサービス事業者Ｘにとって、益々、実行可能ファイルＦＸを削除できない参照関係を生み出すことになる。このことは、ポイントサービス事業者Ｙの実行可能ファイルＦＹでも同様である。
上述した事情を踏まえ、本実施形態のＵＩＭカード１２は、削除対象が参照関係を実行可能ファイルやアプリケーションであっても、当該削除対象の削除要求に応じて、削除と同等の対応を効率良く図ることを可能とする削除処理を行う。なお、削除要求には、実行可能ファイルの削除要求、アプリケーションの削除要求、及び管理アプリの削除要求がある。
ここで、先ず、ＵＩＭカード１２が実行可能ファイルの削除要求を受信した場合の削除処理の概要について説明する。ＵＩＭカード１２内のＲＥは、当該ＵＩＭカード１２内の何れかの実行可能ファイル（削除対象）の削除要求を受信すると、当該削除要求された実行可能ファイルと参照関係にある削除対象外の実行可能ファイルまたはアプリケーションが記憶されている場合、レジストリＲ（管理手段の一例）により管理される実行可能ファイル（削除要求された実行可能ファイル）の状態を、当該実行可能ファイルに関係する処理を制限する論理削除状態に変更する。これにより、削除対象が参照関係を持つ実行可能ファイルであっても、削除と同等の対応を効率良く図ることが可能となる。ここで、「実行可能ファイルに関係する処理を制限する」例として、以下の(a),(b)が挙げられる。
(a)ＲＥは、ロード対象の実行可能ファイルが、論理削除状態にある場合、当該ロード対象の実行可能ファイルのロード処理を中止（制限の一例）する。
(b)ＲＥは、ロード対象の実行可能ファイルが、論理削除状態の実行可能ファイルに依存している場合、当該ロード対象の実行可能ファイルのロード処理を中止する。
なお、「実行可能ファイルに関係する処理を制限する」例として、上記(a),(b) 以外にも、「インストール（インスタンス化）対象の実行可能ファイルが論理削除状態にある場合、インストール処理を中止する」という例もある。想定されるシチュエーションは、実行可能ファイルからインスタンスを生成する場合である。この例でのインストール処理はアプリケーションに対するものであり、アプリケーションのインストール処理（インスタンス化）において、アプリケーションを生成する実行可能ファイルが論理削除状態にある場合、アプリケーションのインストール処理（インスタンス化）を中止することになる。
図９は、論理削除状態を考慮したロード処理の一例を示すフローチャートである。図９の例では、先ず、ベースバンドプロセッサ１３は、ロード対象の実行可能ファイルのロードコマンドを、ＵＩＭカード１２内の管理アプリへ送信する（ステップＳ１）。なお、ロードコマンドは、例えばユーザからの操作指示に応じて生成されるか、或いは特定のサーバから移動体無線通信部及び移動体通信ネットワークを介して受信される。管理アプリは、上記ロードコマンドを受信すると、ロード対象の実行可能ファイルのロード要求をＲＥへ送信する（ステップＳ２）。
ＲＥは、ロード要求を受信すると、ロード処理を開始し、先ず、ロード対象の実行可能ファイルが、論理削除状態にあるか否かを判定する（ステップＳ３）。例えば、ＲＥは、ロード対象の実行可能ファイルのＡＩＤが、論理削除状態の実行可能ファイルのＡＩＤと一致（重複）するか否かをチェックし、一致する場合、ロード対象の実行可能ファイルが論理削除状態にあると判定する。
そして、ＲＥは、ロード対象の実行可能ファイルが論理削除状態にあると判定した場合（ステップＳ３：ＹＥＳ）、ロード対象の実行可能ファイルのロード処理を中止し（ステップＳ４）、その処理結果を管理アプリに送信する。一方、ＲＥは、ロード対象の実行可能ファイルが論理削除状態にないと判定した場合（ステップＳ３：ＮＯ）、ロード対象の実行可能ファイルが他の実行可能ファイルに依存しているか否かを判定する（ステップＳ５）。例えば、ＲＥは、ロード対象の実行可能ファイルのインポートリストに他の実行可能ファイルのＡＩＤが登録されているか否かをチェックし、登録されていない場合、ロード対象の実行可能ファイルが他の実行可能ファイルに依存していないと判定する。
そして、ＲＥは、ロード対象の実行可能ファイルが他の実行可能ファイルに依存していないと判定した場合（ステップＳ５：ＮＯ）、ロード対象の実行可能ファイルをロードし（ステップＳ６）、その処理結果を管理アプリに送信して、ロード処理を終了する。一方、ＲＥは、ロード対象の実行可能ファイルが他の実行可能ファイルに依存していると判定した場合（ステップＳ５：ＹＥＳ）、当該他の実行可能ファイルが論理削除状態にあるか否かを判定する（ステップＳ７）。
そして、ＲＥは、当該他の実行可能ファイルが論理削除状態にあると判定した場合（ステップＳ７：ＹＥＳ）、ロード対象の実行可能ファイルのロード処理を中止し（ステップＳ４）、その処理結果を管理アプリに送信する。一方、ＲＥは、当該他の実行可能ファイルが論理削除状態にないと判定した場合（ステップＳ７：ＮＯ）、ロード対象の実行可能ファイルをロードし、ロードした実行可能ファイルと依存している実行可能ファイルとをリンクし（ステップＳ８）、その処理結果を管理アプリに送信して、ロード処理を終了する。
管理アプリは、上記処理結果を受信すると、当該処理結果を示すレスポンスを生成し（ステップＳ９）、生成したレスポンスをベースバンドプロセッサ１３へ送信する（ステップＳ１０）。こうして、ロードコマンドに対するレスポンスがベースバンドプロセッサ１３により受信される。
その後、ＲＥは、論理削除状態の実行可能ファイルに対する参照関係が解消された段階（例えば、論理削除状態の実行可能ファイルと参照関係にある削除対象外の実行可能ファイルまたはアプリケーションが何等かの理由で削除された場合）、論理削除状態の実行可能ファイルを削除する。これにより、実行可能ファイルの削除において、参照関係を解消するステップと、実行可能ファイルの削除要求を行うステップの実施順序を自由に設定することができる。つまり、複雑な参照関係を持つ実行可能ファイルやアプリケーションに対して、管理者が参照関係を考慮することなく実行可能ファイルやアプリケーションの削除タイミングを自由に制御することができる。
次に、ＵＩＭカード１２がアプリケーションの削除要求を受信した場合の削除処理の概要について説明する。ＲＥは、当該ＵＩＭカード１２内の何れかのアプリケーションの削除要求を受信すると、当該削除要求されたアプリケーションの構成要素であるオブジェクト（つまり、当該削除要求されたアプリケーションが所有するオブジェクト）を、削除対象外の実行可能ファイルまたはアプリケーションが参照している場合、当該削除要求されたアプリケーションの構成要素であるオブジェクトへの参照（上述したオブジェクト参照）を利用不可に設定する。これにより、削除対象が参照関係を持つ実行可能ファイルであっても、削除と同等の対応を効率良く図ることが可能となる。
次に、ＵＩＭカード１２が、管理アプリの削除要求を受信した場合の削除処理の概要について説明する。ＲＥは、当該ＵＩＭカード１２内の何れかの管理アプリの削除要求を受信したとき、当該削除要求された管理アプリが管理する実行可能ファイルが削除要求されたものとして、当該削除要求された（つまり、間接的に削除要求された）実行可能ファイルと参照関係にある削除対象外の実行可能ファイルまたはアプリケーションが記憶されている場合、当該削除要求された実行可能ファイルの状態を上記論理削除状態に変更する。また、このとき、当該削除要求された管理アプリが管理するアプリケーションが削除要求されたものとして、当該削除要求された（つまり、間接的に削除要求された）アプリケーションの構成要素であるオブジェクトを、削除対象外の実行可能ファイルまたはアプリケーションが参照している場合、当該削除要求されたアプリケーションの構成要素であるオブジェクトへの参照を利用不可に設定する。これにより、削除対象が参照関係を持つ実行可能ファイルであっても、削除と同等の対応を効率良く図ることが可能となり、なおかつ、複雑な参照関係を持つ複数の実行可能ファイルやアプリケーションを管理している管理アプリごと、１つの削除要求で当該削除と同等の対応を図ることが可能となる。
なお、ＲＥは、ＵＩＭカード１２内の何れかの管理アプリの削除要求を受信したとき、当該削除要求された管理アプリが管理する実行可能ファイルが削除要求されたものとし、且つ当該削除要求された実行可能ファイルから生成されたアプリケーション（当該削除要求された管理アプリにより管理されているアプリケーションであるか否かは問わない）が削除要求されたものとして、当該削除要求された（つまり、間接的に削除要求された）アプリケーションの構成要素であるオブジェクトを、削除対象外の実行可能ファイルまたはアプリケーションが参照している場合、当該削除要求されたアプリケーションの構成要素であるオブジェクトへの参照を利用不可に設定するとよい。これにより、１つの削除要求で削除と同等の対応を図る対象範囲を広げることが可能となる。
次に、ＵＩＭカード１２が、配下に他の管理アプリを持つ管理アプリの削除要求を受信した場合の削除処理の概要について説明する。ＲＥは、ＵＩＭカード１２内の何れかの管理アプリの削除要求を受信したとき、当該削除要求された管理アプリの配下に位置する他の管理アプリが削除要求されたものとし、且つ当該他の管理アプリが管理する実行可能ファイルが削除要求されたものとして、当該削除要求された（つまり、間接的に削除要求された）実行可能ファイルと参照関係にある削除対象外の実行可能ファイルまたはアプリケーションが記憶されている場合、当該削除要求された実行可能ファイルの状態を上記論理削除状態に変更する。これにより、１つの削除要求で削除と同等の対応を図る対象範囲を広げることが可能となる。なお、間接的に削除要求された管理アプリの配下にさらに他の管理アプリがある場合、上記論理削除状態に変更するための処理が再帰的に行われるとよい。
また、ＲＥは、ＵＩＭカード１２内の何れかの管理アプリの削除要求を受信したとき、当該削除要求された管理アプリの配下に位置する他の管理アプリが削除要求されたものとし、且つ当該削除要求された管理アプリが管理するアプリケーションが削除要求されたものとして、当該削除要求された（つまり、間接的に削除要求された）アプリケーションの構成要素であるオブジェクトを、削除対象外の実行可能ファイルまたはアプリケーションが参照している場合、当該削除要求されたアプリケーションの構成要素であるオブジェクトへの参照を利用不可に設定する。これにより、１つの削除要求で削除と同等の対応を図る対象範囲を広げることが可能となる。なお、間接的に削除要求された管理アプリの配下にさらに他の管理アプリがある場合、上記オブジェクトへの参照を利用不可に設定するための処理が再帰的に行われるとよい。
［３．ＵＩＭカード１２における削除処理の具体例］
次に、削除コマンドに応じてＵＩＭカード１２により実行される削除処理の具体例について、実施例１〜５に分けて説明する。
（実施例１）
先ず、実施例１では、図１０を参照して、削除要求された実行可能ファイルの削除処理について説明する。図１０は、実施例１における削除処理の一例を示すフローチャートである。図１０の例では、先ず、ベースバンドプロセッサ１３は、実行可能ファイルの削除コマンドを、ＵＩＭカード１２内の管理アプリへ送信する（ステップＳ１０１）。当該削除コマンドには、例えば、削除対象の実行可能ファイルを特定可能な情報（例えば、ＡＩＤ）が含まれる。なお、削除コマンドは、例えば特定のサーバから移動体無線通信部及び移動体通信ネットワークを介して受信される。
管理アプリは、例えばＳＣＰ（SecureChannel Protocol）で決められたアルゴリズムに従って認証された論理的通信路を通じ、実行可能ファイルの削除コマンドを受信すると、当該実行可能ファイルの削除要求をＲＥへ送信する（ステップＳ１０２）。当該削除要求には、例えば、削除対象の実行可能ファイルを特定可能な情報（例えば、ＡＩＤ）が含まれる。
ＲＥは、実行可能ファイルの削除要求を受信した場合、削除要求された実行可能ファイルを削除対象に加える（ステップＳ１０３）。なお、削除要求された実行可能ファイルが複数であってもよく、この場合、それぞれの実行ファイルについて以下の処理が行われる。次いで、ＲＥは、削除対象として加わえられた実行可能ファイル（削除対象の実行可能ファイル）に対する削除処理が実施可能であるか否かを判定（チェック）する（ステップＳ１０４）。例えば、削除要求を送信した管理アプリが、削除対象の実行可能ファイルを削除する権限を有さない場合、削除処理は実施不能であると判定される。このような権限は、例えばＯＳにより管理されている。
そして、ＲＥは、実行可能ファイルに対する削除処理が実施可能でない（実施不能である）と判定した場合（ステップＳ１０４：ＮＯ）、削除処理を中止し（ステップＳ１０５）、その処理結果を管理アプリに送信する。一方、ＲＥは、実行可能ファイルに対する削除処理が実施可能であると判定した場合（ステップＳ１０４：ＹＥＳ）、削除対象の実行可能ファイルから生成されたアプリケーションが存在し、且つ削除対象外（つまり、削除対象の実行可能ファイルから生成されたアプリケーションが削除対象外）であるか否かを判定する（ステップＳ１０６）。ここで、削除対象の実行可能ファイルから生成されたアプリケーションが削除対象に含まれない（つまり、削除対象に加えるステップを実行していない）場合、削除対象外であると判定される。
そして、ＲＥは、削除対象の実行可能ファイルから生成されたアプリケーションが存在しないか、或いは存在したとしても削除対象外でないと判定した場合（ステップＳ１０６：ＮＯ）、ステップＳ１０７へ進む。一方、ＲＥは、削除対象の実行可能ファイルから生成されたアプリケーションが存在し、且つ削除対象外であると判定した場合（ステップＳ１０６：ＹＥＳ）、つまり、削除要求された実行可能ファイルと参照関係にある削除対象外のアプリケーションが記憶されている場合、ステップＳ１０９へ進む。つまり、削除対象の実行可能ファイルから生成されたアプリケーションが削除対象外である場合、ＲＥは、削除対象の実行可能ファイルへの静的な参照が存在すると判定して、ステップＳ１０９へ進むことになる。なお、実施例１の場合、実行可能ファイルのみが削除対象であるので、インスタンス化によりアプリケーションが生成されている場合、必ず、「ステップＳ１０６：ＹＥＳ」になり、ステップＳ１０９へ進むことになる。
ステップＳ１０７では、ＲＥは、削除対象の実行可能ファイルに、削除対象外の実行可能ファイル（つまり、削除対象の実行可能ファイルに対して、ＵＩＭカード１２内の削除対象でない他の実行可能ファイル）が依存しているか否かを判定する。例えば、ＲＥは、ＵＩＭカード１２内の全ての実行可能ファイルに対し、実行可能ファイルのロード及びリンク時に利用するインポートコンポーネントを走査することで、削除対象の実行可能ファイルへの依存を確認する。
そして、ＲＥは、削除対象の実行可能ファイルに削除対象外の実行可能ファイルが依存していると判定した場合（ステップＳ１０７：ＹＥＳ）、つまり、削除要求された実行可能ファイルと参照関係にある削除対象外の実行可能ファイルが記憶されている場合、ステップＳ１０９へ進む。一方、ＲＥは、削除対象の実行可能ファイルに削除対象外の実行可能ファイルが依存していないと判定した場合（ステップＳ１０７：ＮＯ）、ステップＳ１０８へ進む。
ステップＳ１０８では、ＲＥは、削除対象の実行可能ファイルから生成されたオブジェクトが、削除対象外の実行可能ファイルまたはアプリケーションに所有されているか否かを判定する。例えば、ＲＥは、オブジェクトテーブルを参照し、全てのオブジェクトの情報からコンテキストを取得することで、削除対象のオブジェクトの存在を確認することができる。当該オブジェクトが存在した場合、ＲＥは実行可能ファイルへの静的な参照が存在すると判定する。
そして、ＲＥは、削除対象の実行可能ファイルから生成されたオブジェクトが、削除対象外の実行可能ファイルまたはアプリケーションに所有されていると判定した場合（ステップＳ１０８：ＹＥＳ）、ステップＳ１０９へ進む。一方、ＲＥは、削除対象の実行可能ファイルから生成されたオブジェクトが、削除対象外の実行可能ファイルまたはアプリケーションに所有されていないと判定した場合（ステップＳ１０８：ＮＯ）、ステップＳ１１１へ進む。
ステップＳ１０９では、ＲＥは、レジストリＲが保持する管理情報を更新することで、削除対象の実行可能ファイルの状態を論理削除状態に変更（例えば、Lifecycleが“LOADED”から“DELETEED”に変更）し、当該削除対象の実行可能ファイルを管理する管理アプリのＡＩＤを削除する。次いで、ＲＥは、論理削除状態に変更された実行可能ファイルを削除対象から外し（ステップＳ１１０）、ステップＳ１１１へ進む。
ステップＳ１１１では、ＲＥは、削除対象の実行可能ファイル、及び当該実行可能ファイルが所有する全てのオブジェクトとその管理情報を削除し、その処理結果を管理アプリに送信する。なお、複数の実行可能ファイルのうちの全てについてステップＳ１０９及びＳ１１０が実行された場合、削除対象はないので、ステップＳ１１１では、ＲＥは、実行可能ファイル等を削除することなく、その処理結果を管理アプリに送信することになる。一方、複数の実行可能ファイルのうちの一部についてステップＳ１０９及びＳ１１０が実行された場合、ステップＳ１１１では、ＲＥは、当該一部の実行可能ファイルを除く削除対象の実行可能ファイル等を削除し、その処理結果を管理アプリに送信することになる。
管理アプリは、上記処理結果を受信すると、当該処理結果を示すレスポンスを生成し（ステップＳ１１２）、生成したレスポンスをベースバンドプロセッサ１３へ送信する（ステップＳ１１３）。こうして、削除コマンドに対するレスポンスがベースバンドプロセッサ１３により受信され、例えば特定のサーバへ送信される。
実施例１によれば、参照関係にあるカードコンテントの管理者が異なる場合、さらには、参照関係にあるカードコンテントの管理者がサービス運用中に変更される場合であったとしても、削除と同等の対応を迅速かつ効率良く図ることができる。
（実施例２）
次に、実施例２では、図１１を参照して、削除要求されたアプリケーションの削除処理について説明する。図１１は、実施例２における削除処理の一例を示すフローチャートである。図１１の例では、先ず、ベースバンドプロセッサ１３は、アプリケーションの削除コマンドを、ＵＩＭカード１２内の管理アプリへ送信する（ステップＳ２０１）。当該削除コマンドには、例えば、削除対象のアプリケーションを特定可能な情報（例えば、ＡＩＤ）が含まれる。
管理アプリは、上述したように認証された論理的通信路を通じ、アプリケーションの削除コマンドを受信すると、当該アプリケーションの削除要求をＲＥへ送信する（ステップＳ２０２）。当該削除要求には、例えば、削除対象のアプリケーションを特定可能な情報（例えば、ＡＩＤ）が含まれる。
ＲＥは、アプリケーションの削除要求を受信した場合、削除要求されたアプリケーションを削除対象に加える（ステップＳ２０３）。次いで、ＲＥは、削除対象として加えられたアプリケーション（削除対象のアプリケーション）に対する削除処理が実施可能であるか否かを判定（チェック）する（ステップＳ２０４）。例えば、削除要求を送信した管理アプリが削除対象のアプリケーションを削除する権限を有さない場合、または当該アプリケーションが論理的通信路上で選択されている場合、削除処理は実施不能であると判定される。
そして、ＲＥは、アプリケーションに対する削除処理が実施可能でないと判定した場合（ステップＳ２０４：ＮＯ）、削除処理を中止し（ステップＳ２０５）、その処理結果を管理アプリに送信する。一方、ＲＥは、アプリケーションに対する削除処理が実施可能であると判定した場合（ステップＳ２０４：ＹＥＳ）、ステップＳ２０６へ進む。
ステップＳ２０６では、ＲＥは、削除対象のアプリケーションが所有するオブジェクト（チェック対象のオブジェクト）を、削除対象外の実行可能ファイルまたはアプリケーションが参照しているか否かを判定する。例えば、削除対象外の実行可能ファイルまたはアプリケーションが所有するオブジェクトのインスタンスフィールドまたは配列の要素が、削除対象のアプリケーションが所有するオブジェクトのオブジェクト参照を値として保持している場合、削除対象外の実行可能ファイルまたはアプリケーションが削除対象のアプリケーションが所有するオブジェクトを参照していると判定される。
そして、ＲＥは、削除対象のアプリケーションが所有するオブジェクトを削除対象外の実行可能ファイルまたはアプリケーションが参照していると判定した場合（ステップＳ２０６：ＹＥＳ）、ステップＳ２０７へ進む。一方、ＲＥは、削除対象のアプリケーションが所有するオブジェクトを削除対象外の実行可能ファイルまたはアプリケーションが参照していないと判定した場合（ステップＳ２０６：ＮＯ）、ステップＳ２０９へ進む。
ステップＳ２０７では、ＲＥは、削除対象のアプリケーションが所有するオブジェクトへの参照を利用不可に設定する。例えば、ＲＥは、削除対象外の実行可能ファイルまたはアプリケーションが所有するオブジェクトのインスタンスフィールドまたは配列の要素の値に、オブジェクトが利用できないことを示す特定の値を書き込む。この特定の値には、例えば、ＲＥ上でのNULL値、またはNULL値を表すオブジェクトへの参照が用いられる。
次いで、ＲＥは、削除対象のアプリケーションが所有するオブジェクトのフィールドを全てチェックしたか否かを判定する（ステップＳ２０８）。そして、ＲＥは、削除対象のアプリケーションが所有するオブジェクトのフィールドを全てチェックしていないと判定した場合（ステップＳ２０８：ＮＯ）、ステップＳ２０６へ戻り、まだチェックされていないオブジェクトについて上記と同様の処理を繰り返す（つまり、チェック対象のオブジェクトの参照型変数すべてに対し上記処理を繰り返す）。一方、ＲＥは、削除対象のアプリケーションが所有するオブジェクトのフィールドを全てチェックしたと判定した場合（ステップＳ２０８：ＹＥＳ）、ステップＳ２０９へ進む。
ステップＳ２０９では、ＲＥは、削除対象のアプリケーションが所有する全てのオブジェクトを削除対象に加える。次いで、ＲＥは、削除対象のアプリケーションが所有する全てのオブジェクトとその管理情報を削除し（ステップＳ２１０）、その処理結果を管理アプリに送信する。
なお、ステップＳ２１１及びＳ２１２の処理は、実施例１におけるステップＳ１１２及びＳ１１３の処理と同様である。
実施例２によっても、参照関係にあるカードコンテントの管理者が異なる場合、さらには、参照関係にあるカードコンテントの管理者がサービス運用中に変更される場合であったとしても、削除と同等の対応を迅速かつ効率良く図ることができる。
（実施例３）
次に、実施例３では、図１２及び図１３を参照して、削除要求された管理アプリとその管理下にある実行可能ファイル及びアプリケーションの削除処理について説明する。図１２は、実施例３における削除処理の一例を示すフローチャートである。図１３は、管理アプリ、実行可能ファイル、及びアプリケーション間の階層構造における実行可能ファイルとアプリケーションとの間の参照関係と、実施例３の削除処理結果の一例を示す概念図である。図１２の例では、先ず、ベースバンドプロセッサ１３は、管理アプリの削除コマンドを、ＵＩＭカード１２内の管理アプリへ送信する（ステップＳ３０１）。当該削除コマンドには、例えば、削除対象の管理アプリを特定可能な情報（例えば、ＡＩＤ）が含まれる。
管理アプリは、上述したように認証された論理的通信路を通じ、管理アプリの削除コマンドを受信すると、当該管理アプリの削除要求をＲＥへ送信する（ステップＳ３０２）。当該削除要求には、例えば、削除対象の管理アプリを特定可能な情報（例えば、ＡＩＤ）が含まれる。
ＲＥは、管理アプリの削除要求を受信した場合、削除要求された管理アプリを削除対象に加える（ステップＳ３０３）。次いで、ＲＥは、削除対象の管理アプリが管理するアプリケーションがある場合、当該アプリケーションを削除対象に加える（ステップＳ３０４）。つまり、削除要求された管理アプリにより管理されるアプリケーションは、削除要求されたものと見做されて削除対象に加えられる。次いで、ＲＥは、削除対象の管理アプリが管理する実行可能ファイルがある場合、当該実行可能ファイルを削除対象に加える（ステップＳ３０５）。つまり、削除要求された管理アプリにより管理される実行可能ファイルは、削除要求されたものと見做されて削除対象に加えられる。なお、削除対象の管理アプリが管理する実行可能ファイルが複数ある場合、それぞれの実行可能ファイルが削除対象に加えられる。
次いで、ＲＥは、ステップＳ３０４で削除対象として加えられたアプリケーションの削除処理を実行する（ステップＳ３０６）。この削除処理では、実施例２におけるステップＳ２０４〜Ｓ２０９の処理が行われる。次いで、ＲＥは、ステップＳ３０５で削除対象として加えられた実行可能ファイルの削除処理を実行する（ステップＳ３０７）。この削除処理では、実施例１におけるステップＳ１０４〜Ｓ１１０の処理が行われる。次いで、ＲＥは、削除対象の管理アプリ、削除対象の実行可能ファイル（ステップＳ３０７の削除処理において、削除対象から外された実行可能ファイルは除く）、削除対象のアプリケーション、及びこれらが所有する全てのオブジェクトの管理情報を削除し（ステップＳ３０８）、その処理結果を管理アプリに送信する。なお、ステップＳ３０９及びＳ３１０の処理は、実施例１におけるステップＳ１１２及びＳ１１３の処理と同様である。
図１３の例では、図１２に示す削除処理において、管理アプリＳＤ１１（削除要求された管理アプリ）、実行可能ファイルＦ１１、アプリＡ１１１、及びアプリＡ１１２が削除対象となり、このうち、管理アプリＳＤ１１、アプリＡ１１１、及びアプリＡ１１２が削除される。ここで、アプリＡ１１１が所有するオブジェクトへは、削除対象外の実行可能ファイルＦ２により参照されるが、当該実行可能ファイルＦ２内の当該参照は利用不可（例えば、NULL値）に設定されるため、当該アプリＡ１１１が削除されても影響はない。同様に、アプリＡ１１２が所有するオブジェクトへは、削除対象外のアプリＡ２２により参照されるが、当該アプリＡ２２内の当該参照は利用不可（例えば、NULL値）に設定されるため、当該アプリＡ１１２が削除されても影響はない。一方、実行可能ファイルＦ１１には、削除対象外の実行可能ファイルＦ２が依存するため、実行可能ファイルＦ１１は削除がされる代わりに論理削除状態となる（削除対象外の実行可能ファイルＦ２が依存している間、論理削除状態となる）。なお、アプリＡ１１１が所有するオブジェクトへはアプリＡ１１２により参照されるが、アプリＡ１１２も削除対象であるため問題はない。
実施例３によっても、参照関係にあるカードコンテントの管理者が異なる場合、さらには、参照関係にあるカードコンテントの管理者がサービス運用中に変更される場合であったとしても、削除と同等の対応を迅速かつ効率良く図ることができる。さらに、実施例３によれば、１つの削除コマンドで削除と同等の対応を図る対象範囲を広げることができ、時間と費用を低減することができる。
（実施例４）
次に、実施例４では、図１４及び図１５を参照して、削除要求された管理アプリとその管理下にある実行可能ファイル及びアプリケーション、並びに削除要求されていない管理アプリにより管理されるアプリケーションの削除処理について説明する。図１４は、実施例４における削除処理の一例を示すフローチャートである。図１５は、管理アプリ、実行可能ファイル、及びアプリケーション間の階層構造における実行可能ファイルとアプリケーションとの間の参照関係と、実施例４の削除処理結果の一例を示す概念図である。図１５の例では、実行可能ファイルＦ１１と、実行可能ファイルＦ１１から生成されたアプリＡ１１３とは、同一の管理者により管理されていたが、その後、アプリＡ１１３の管理者が変更された場合を想定している。つまり、実行可能ファイルＦ１１とアプリＡ１１３の管理者は異なる。なお、ステップＳ４０１〜Ｓ４０５の処理は、実施例３におけるステップＳ３０１〜Ｓ３０５の処理と同様である。
ステップＳ４０６では、ＲＥは、ステップＳ４０５で削除対象として加えられた実行可能ファイルから生成されたアプリケーションの一覧を取得し、取得できたアプリケーションを削除対象に加える。つまり、削除要求された管理アプリにより管理される実行可能ファイルから生成されたアプリケーションは、削除要求されたものと見做されて削除対象に加えられる。
次いで、ＲＥは、ステップＳ４０４で削除対象として加えられたアプリケーション、及びステップＳ４０６で削除対象として加えられたアプリケーションの削除処理を実行する（ステップＳ４０７）。この削除処理では、実施例２におけるステップＳ２０４〜Ｓ２０９の処理が行われる。次いで、ＲＥは、ステップＳ４０５で削除対象として加えられた実行可能ファイルの削除処理を実行する（ステップＳ４０８）。この削除処理では、実施例１におけるステップＳ１０４〜Ｓ１１０の処理が行われる。なお、ステップＳ４０９〜Ｓ４１１の処理は、実施例３におけるステップＳ３０８〜Ｓ３１０の処理と同様である。
図１５の例では、図１４に示す削除処理において、図１３と同様、管理アプリＳＤ１１、実行可能ファイルＦ１１、アプリＡ１１１、及びアプリＡ１１２が削除対象となり、このうち、実行可能ファイルＦ１１が論理削除状態となり、管理アプリＳＤ１１、アプリＡ１１１、及びアプリＡ１１２が削除されている。さらに、削除要求されていない管理アプリＳＤ２により管理されるアプリＡ１１３は、削除対象に加えられた実行可能ファイルから生成されたアプリケーションであるので、削除対象に加えられて削除されている。
実施例４によっても、参照関係にあるカードコンテントの管理者が異なる場合、さらには、参照関係にあるカードコンテントの管理者がサービス運用中に変更される場合であったとしても、削除と同等の対応を迅速かつ効率良く図ることができる。さらに、実施例４によれば、１つの削除コマンドで削除と同等の対応を図る対象範囲を広げることができ、時間と費用を低減することができる。
（実施例５）
次に、実施例５では、図１６及び図１７を参照して、削除要求された管理アプリの配下（管理下）にある管理アプリが管理するカードコンテントの削除処理について説明する。図１６は、実施例５における削除処理の一例を示すフローチャートである。図１７は、管理アプリ、実行可能ファイル、及びアプリケーション間の階層構造における実行可能ファイルとアプリケーションとの間の参照関係と、実施例５の削除処理結果の一例を示す概念図である。なお、ステップＳ５０１〜Ｓ５０５の処理は、実施例３におけるステップＳ３０１〜Ｓ３０５の処理と同様である。
ステップＳ５０６では、ＲＥは、削除要求された管理アプリ（削除対象として追加された管理アプリ）の配下に他の管理アプリがあるか否かを判定する。そして、ＲＥは、削除要求された管理アプリの配下に他の管理アプリがないと判定した場合（ステップＳ５０６：ＮＯ）、ステップＳ５０８へ進む。一方、ＲＥは、削除要求された管理アプリの配下に他の管理アプリがあると判定した場合（ステップＳ５０６：ＹＥＳ）、つまり、削除要求された管理アプリの配下に位置する他の管理アプリが記憶されている場合、当該配下の他の管理アプリを削除要求されたものとして特定し（ステップＳ５０７）、ステップＳ５０３に戻る。
ステップＳ５０３に戻ると、ＲＥは、ステップＳ５０７で特定した管理アプリを削除対象に加える。次いで、ＲＥは、ステップＳ５０７で特定した管理アプリが管理するアプリケーションがある場合、当該アプリケーションを削除対象に加え（ステップＳ５０４）、当該特定した管理アプリが管理する実行可能ファイルがある場合、当該実行可能ファイルを削除対象に加える（ステップＳ５０５）。そして、ＲＥは、当該特定した管理アプリの配下に更に他の管理アプリがあるか否かを判定し（ステップＳ５０６）、他の管理アプリがないと判定した場合（ステップＳ５０６：ＮＯ）、ステップＳ５０８へ進む。このように、削除対象が再帰的に特定され、特定された削除対象に対して、ステップＳ５０８〜Ｓ５１２の処理が、実施例３におけるステップＳ３０６〜Ｓ３１０の処理と同様に行われる。
図１７の例では、図１６に示す削除処理において、管理アプリＳＤ１（削除要求された管理アプリ）、実行可能ファイルＦ１、管理アプリＳＤ１１、実行可能ファイルＦ１１、アプリＡ１１１、及びアプリＡ１１２が削除対象となり、このうち、管理アプリＳＤ１、管理アプリＳＤ１１、アプリＡ１１１、及びアプリＡ１１２が削除される。ここで、実行可能ファイルＦ１に依存する実行可能ファイルＦ１１には削除対象外の実行可能ファイルＦ２が依存（間接的な依存）するため、実行可能ファイルＦ１は削除がされる代わりに論理削除状態となる。
実施例５によっても、参照関係にあるカードコンテントの管理者が異なる場合、さらには、参照関係にあるカードコンテントの管理者がサービス運用中に変更される場合であったとしても、削除と同等の対応を迅速かつ効率良く図ることができる。さらに、実施例５によれば、１つの削除コマンドで削除と同等の対応を図る対象範囲を広げることができ、時間と費用を低減することができる。
１ 携帯端末
１１ ＣＬＦ
１２ ＵＩＭカード
１２ａ 接触型ＩＣチップ
１３ ベースバンドプロセッサ
１４ バッテリー
１２１ ＣＰＵ
１２２ ＲＡＭ
１２３ ＲＯＭ
１２４ 不揮発性メモリ
１２５ Ｉ／Ｏ回路

Claims (12)

  1. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能な電子情報記憶媒体であって、
    それぞれの前記実行可能ファイルの状態を管理する管理手段と、
    何れかの前記実行可能ファイルの削除要求を受信する第１受信手段と、
    前記削除要求された前記実行可能ファイルと参照関係にある削除対象外の前記実行可能ファイルまたは前記アプリケーションが記憶されている場合、前記管理手段により管理される、前記削除要求された前記実行可能ファイルの状態を、当該実行可能ファイルに関係する処理を制限する論理削除状態に変更する変更手段と、
    何れかの前記アプリケーションの削除要求を受信する第２受信手段と、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定する設定手段と、
    を備えることを特徴とする電子情報記憶媒体。
  2. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能な電子情報記憶媒体であって、
    何れかの前記アプリケーションの削除要求を受信する第２受信手段と、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定する設定手段と、
    を備えることを特徴とする電子情報記憶媒体。
  3. 前記電子情報記憶媒体は、前記実行可能ファイルと前記アプリケーションとの両方を管理する管理アプリケーションを記憶し、
    前記第２受信手段により前記管理アプリケーションの削除要求が受信されたとき、前記変更手段は、当該削除要求された前記管理アプリケーションが管理する前記実行可能ファイルが削除要求されたものとして、当該削除要求された前記実行可能ファイルと参照関係にある削除対象外の前記実行可能ファイルまたは前記アプリケーションが記憶されている場合、当該削除要求された前記実行可能ファイルの状態を前記論理削除状態に変更し、
    前記設定手段は、前記削除要求された前記管理アプリケーションが管理する前記アプリケーションが削除要求されたものとして、当該削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、当該削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定することを特徴とする請求項１に記載の電子情報記憶媒体。
  4. 前記設定手段は、前記削除要求された前記管理アプリケーションが管理する前記実行可能ファイルが削除要求されたものとし、且つ当該削除要求された前記実行可能ファイルから生成されたアプリケーションが削除要求されたものとして、当該削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、当該削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定することを特徴とする請求項３に記載の電子情報記憶媒体。
  5. 前記電子情報記憶媒体は、前記管理アプリケーションの配下に位置する他の管理アプリケーションを記憶し、
    前記変更手段は、前記削除要求された前記管理アプリケーションの配下に位置する前記他の管理アプリケーションが削除要求されたものとし、且つ当該他の管理アプリケーションが管理する前記実行可能ファイルが削除要求されたものとして、当該削除要求された前記実行可能ファイルと参照関係にある削除対象外の前記実行可能ファイルまたは前記アプリケーションが記憶されている場合、当該削除要求された前記実行可能ファイルの状態を前記論理削除状態に変更することを特徴とする請求項３または４に記載の電子情報記憶媒体。
  6. 前記電子情報記憶媒体は、前記管理アプリケーションの配下に位置する他の管理アプリケーションを記憶し、
    前記設定手段は、前記削除要求された前記管理アプリケーションの配下に位置する前記他の管理アプリケーションが削除要求されたものとし、且つ当該削除要求された前記管理アプリケーションが管理する前記アプリケーションが削除要求されたものとして、当該削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、当該削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定することを特徴とする請求項３または４に記載の電子情報記憶媒体。
  7. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能なＩＣカードであって、
    それぞれの前記実行可能ファイルの状態を管理する管理手段と、
    何れかの前記実行可能ファイルの削除要求を受信する第１受信手段と、
    前記削除要求された前記実行可能ファイルと参照関係にある削除対象外の前記実行可能ファイルまたは前記アプリケーションが記憶されている場合、前記管理手段により管理される、前記削除要求された前記実行可能ファイルの状態を、当該実行可能ファイルに関係する処理を制限する論理削除状態に変更する変更手段と、
    何れかの前記アプリケーションの削除要求を受信する第２受信手段と、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定する設定手段と、
    を備えることを特徴とするＩＣカード。
  8. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能なＩＣカードであって、
    何れかの前記アプリケーションの削除要求を受信する第２受信手段と、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定する設定手段と、
    を備えることを特徴とするＩＣカード。
  9. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能な電子情報記憶媒体が備えるプロセッサにより実行される削除処理方法であって、
    それぞれの前記実行可能ファイルの状態を管理するステップと、
    何れかの前記実行可能ファイルの削除要求を受信するステップと、
    前記削除要求された前記実行可能ファイルと参照関係にある削除対象外の前記実行可能ファイルまたは前記アプリケーションが記憶されている場合、前記管理される、前記削除要求された前記実行可能ファイルの状態を、当該実行可能ファイルに関係する処理を制限する論理削除状態に変更するステップと、
    何れかの前記アプリケーションの削除要求を受信するステップと、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定するステップと、
    を含むことを特徴とする削除処理方法。
  10. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能な電子情報記憶媒体が備えるプロセッサにより実行される削除処理方法であって、
    何れかの前記アプリケーションの削除要求を受信するステップと、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定するステップと、
    を含むことを特徴とする削除処理方法。
  11. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能な電子情報記憶媒体が備えるプロセッサに、
    それぞれの前記実行可能ファイルの状態を管理するステップと、
    何れかの前記実行可能ファイルの削除要求を受信するステップと、
    前記削除要求された前記実行可能ファイルと参照関係にある削除対象外の前記実行可能ファイルまたは前記アプリケーションが記憶されている場合、前記管理される、前記削除要求された前記実行可能ファイルの状態を、当該実行可能ファイルに関係する処理を制限する論理削除状態に変更するステップと、
    何れかの前記アプリケーションの削除要求を受信するステップと、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定するステップと、
    を実行させることを特徴とする削除処理プログラム。
  12. 所定の機能を実現するための複数の実行可能ファイル及びそれぞれの実行可能ファイルから生成されたアプリケーションを記憶可能な電子情報記憶媒体が備えるプロセッサに、
    何れかの前記アプリケーションの削除要求を受信するステップと、
    前記削除要求された前記アプリケーションの構成要素であるオブジェクトを、削除対象外の前記実行可能ファイルまたは前記アプリケーションが参照している場合、前記削除要求された前記アプリケーションの構成要素であるオブジェクトへの前記参照を利用不可に設定するステップと、
    を実行させることを特徴とする削除処理プログラム。
JP2017005316A 2017-01-16 2017-01-16 電子情報記憶媒体、ｉｃカード、削除処理方法、及び削除処理プログラム Active JP6822158B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017005316A JP6822158B2 (ja) 2017-01-16 2017-01-16 電子情報記憶媒体、ｉｃカード、削除処理方法、及び削除処理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017005316A JP6822158B2 (ja) 2017-01-16 2017-01-16 電子情報記憶媒体、ｉｃカード、削除処理方法、及び削除処理プログラム

Publications (2)

Publication Number Publication Date
JP2018116366A JP2018116366A (ja) 2018-07-26
JP6822158B2 true JP6822158B2 (ja) 2021-01-27

Family

ID=62985507

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017005316A Active JP6822158B2 (ja) 2017-01-16 2017-01-16 電子情報記憶媒体、ｉｃカード、削除処理方法、及び削除処理プログラム

Country Status (1)

Country Link
JP (1) JP6822158B2 (ja)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4548758B2 (ja) * 2000-09-05 2010-09-22 大日本印刷株式会社 共有アクセス管理機能を備えた携帯可能な情報処理装置
JP2006338311A (ja) * 2005-06-01 2006-12-14 Dainippon Printing Co Ltd 複数のアプリケーションを搭載したデバイスを処理するコンピュータシステム、デバイスおよびコンピュータプログラム
JP2009175847A (ja) * 2008-01-22 2009-08-06 Hitachi Information Systems Ltd アプリケーションプログラムのアンインストール管理システム
JP5795921B2 (ja) * 2011-09-21 2015-10-14 株式会社東芝 Ｉｃカード、携帯可能電子装置、ｉｃカードの制御方法
JP6426411B2 (ja) * 2014-09-10 2018-11-21 株式会社東芝 Ｉｃカード及び携帯可能電子装置

Also Published As

Publication number Publication date
JP2018116366A (ja) 2018-07-26

Similar Documents

Publication Publication Date Title
JPWO2008050439A1 (ja) アプリケーション管理装置及びアプリケーション管理方法
US20060086785A1 (en) Portable electronic apparatus and method of updating application in portable electronic apparatus
US8807440B1 (en) Routing secure element payment requests to an alternate application
JP4850073B2 (ja) コンフィギュラブルファイヤウォールを利用するシステム、方法、及びコンピュータ読み取り可能な記憶媒体
US9158598B2 (en) Apparatus, method, program and system for processing information utilizing a multi-platform capable of managing a plurality of applications
US9390259B2 (en) Method for activating an operating system in a security module
US10803373B2 (en) Information processing apparatus and information processing method
US7665667B2 (en) System and method for updating access control mechanisms
CN109309662A (zh) 软件防火墙
JP2010534369A (ja) 独自のメモリ装置識別表示を管理する方法、サーバー及びモバイル通信装置
CN104462893A (zh) 多se模块管理方法和多se模块管理装置
CN111324357B (zh) 应用程序接入风控平台的方法及相关设备
JP6822158B2 (ja) 電子情報記憶媒体、ｉｃカード、削除処理方法、及び削除処理プログラム
JP6322967B2 (ja) データ保護装置、方法、および、プログラム
CN107315610B (zh) 实现密码功能的方法、装置及计算机可读存储介质
JP2006338311A (ja) 複数のアプリケーションを搭載したデバイスを処理するコンピュータシステム、デバイスおよびコンピュータプログラム
CN111310243A (zh) 一种具有多主安全域的智能ic卡片内操作系统
JP2020150473A (ja) ｅＵＩＣＣおよびｅＵＩＣＣのプロビジョニング方法
US11039318B2 (en) Multi-configuration secure element and associated method
CN101765854B (zh) 用于恢复mifare存储器的移动通信设备和方法
JP2019028602A (ja) 電子情報記憶媒体、ｉｃカード、電子情報記憶媒体によるアップデート方法及びアップデートプログラム
JP7010084B2 (ja) Ｉｃ決済で用いるトークンデバイス
JP2017021443A (ja) 電子情報記憶媒体、情報処理方法及び代表アプリケーション
JP7009844B2 (ja) 電子情報記憶媒体、ｉｃカード、電子情報記憶媒体によるアップデート方法及びアップデートプログラム
JP6515850B2 (ja) 情報処理装置、ｉｃチップ、情報処理方法、プログラム、及び情報処理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191127

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200909

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200915

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201112

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: 20201208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201221

R150 Certificate of patent or registration of utility model

Ref document number: 6822158

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150