JP3880384B2

JP3880384B2 - Ｉｃカード

Info

Publication number: JP3880384B2
Application number: JP2001373046A
Authority: JP
Inventors: 雅基田靡; 和生佐久嶋; 和紀井上; 隆文菊地
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2001-12-06
Filing date: 2001-12-06
Publication date: 2007-02-14
Anticipated expiration: 2021-12-06
Also published as: EP1318488A2; EP1318488A3; US6834799B2; US20030146277A1; JP2003173427A; CN1423232A

Description

【０００１】
【発明の属する技術分野】
本発明は、特権を持ったアプリケーションがダウンロードされるＩＣカードに関する。
【０００２】
【従来の技術】
現在、セキュリティデバイスとしてＩＣカードが着目されている。ユーザの利便性、ＩＣカードによるサービスを提供したい事業者の参入障壁を下げることを目的に、カード発行後にアプリケーションをダウンロードすることが可能なカードであるマルチアプリケーション対応カードの開発が行なわれている。
【０００３】
ここで、ＩＣカードのハードウェア構成について概観する。図１８は、ＩＣカードのハードウェアに関する機能ブロック図である。ＩＣカード１８００は、ＣＰＵ１８０１、ＲＯＭ１８０２、ＲＡＭ１８０３、ＥＥＰＲＯＭ１８０４、Ｉ／ＯＩＦ１８０５を備えている。ＣＰＵ１８０１は、演算を行なう。ＲＯＭ１８０２は、書き換えができない読み出し専用のメモリである。ＲＯＭ１８０２に格納される内容は、ＩＣカード１８００の製造時に決定され、その後変更することはできない。ＲＡＭ１８０３は読み書きが可能なメモリである。ＥＥＰＲＯＭ１８０４は、読み書き可能なメモリである。ＲＡＭ１８０３は、電源が切断されると内容が消えてしまうのに対し、ＥＥＰＲＯＭ１８０４は、電源が切断されても内容が保持されるようになっている。Ｉ／ＯＩＦ１８０５は、ＩＣカードの外部とのデータの交換を担当する。ＣＰＵ１８０１で実行されるプログラムは、通常「アプリケーション」と呼ばれる。アプリケーションの実行のためのコードは、ＲＯＭ１８０２やＥＥＰＲＯＭ１８０４に格納される。また、図１８に示す以外に、ＩＣカード１８００が暗号操作のための暗号用コプロセッサを備える場合もある。
【０００４】
図１９は、ＣＰＵ１８０１で実行されるアプリケーションの関係を説明する図であり、ＩＣカード１９００のＲＯＭ１９０１の中に、カードマネージャ１９０２というアプリケーションがあり、また、特権ＡＰＩ１９０６、一般ＡＰＩ１９０７がある。カードマネージャ１９０２は、ＩＣカード１９００の中で動作するアプリケーションの動作を制御するためのアプリケーションである。アプリケーションの動作の制御には、アプリケーションの起動や、終了、削除、ダウンロードなどがある。カードマネージャ１９０２はこれらの制御をＩＣカードのＶＭ（バーチャルマシン）やＯＳと協働して行なう。特権ＡＰＩ１９０６は、カードマネージャ１９０２が使用する特権操作を実行するためのアプリケーションインターフェースである。例えば、アプリケーションをダウンロード、起動、終了させるなどの制御するための操作が特権操作の例である。一般ＡＰＩ１９０７は、特権の必要のない操作を実行するためのアプリケーションインターフェースである。ＡＰ・１（１９０３）、ＡＰ・２（１９０４）、ＡＰ・３（１９０５）は、ＲＯＭ１８０２やＥＥＰＲＯＭ１８０４に格納され、カードマネージャの支配下で実行するアプリケーションである。これらのアプリケーションは、特権操作を実行することができないので、ＲＯＭ１８０２により提供されるアプリケーションインターフェースのうち、一般ＡＰＩ１９０７のみが使用できる。特権操作をカードマネージャ１９０２以外のアプリケーションが行なうことができないようにするために、特権ＡＰＩ１９０６は、カードマネージャ１９０２にのみ開放され、あるいは、他のアプリケーションにも開放されている場合であっても、次に述べる確認が行なわれるなどして、他のアプリケーションが特権操作を行なえないようにしている。すなわち、特権ＡＰＩ１９０６の内部において特権ＡＰＩ１９０６を利用しようとするアプリケーションの識別子やプログラムカウンタの指すメモリアドレスをチェックするなどしてカードマネージャ１９０２であることを確認する。
【０００５】
【発明が解決しようとする課題】
上述のマルチアプリケーション対応カードの開発においては、ダウンロードされたアプリケーションを管理するカードマネージャが種々検討され、様々な仕様を持つカードマネージャが提案されている。この傾向は、ＩＣカードの需要の高まりとともに、ますます高まり、より多くのカードマネージャの仕様が提案されると予想される。
【０００６】
しかしながら、従来のＩＣカードには、カードマネージャは一つしか搭載することができず、しかも、カードマネージャのコードは内容の書き換えが不可能なＲＯＭに格納されている。このため仕様ごとのカードマネージャを開発し、それをＲＯＭに格納してＩＣカードを製品化せざるを得ないが、金額、工数の観点から望ましくない。また、一般ユーザにとっても、何枚ものＩＣカードを持つことになり、不便を感じることになる。
【０００７】
【課題を解決するための手段】
上記の課題を解決するために、本発明は、特権を有するアプリケーションをダウンロードすることができるカードマネージャを有するＩＣカードを提供する。特権を有するアプリケーションをダウンロードして動作させ、その特権をもったアプリケーションの支配の下で別のアプリケーションのダウンロード、起動、終了などを行なわせることにより、特権を有するアプリケーションがカードマネージャとしての役割をすることになる。上述のように様々な仕様のカードマネージャが提案されても、そのようなカードマネージャを、特権を有するアプリケーションとしてダウンロードすることにより、ユーザは複数枚のＩＣカードを持つ必要がなくなる。また、ＲＯＭに格納されているカードマネージャのバージョンアップに相当することも行なえることになる。
【０００８】
このように特権を有するアプリケーションをダウンロードできるようにすると、一般のアプリケーションとの区別を行なう必要がある。そこで、本発明においては、ＲＯＭに格納されたカードマネージャが、ダウンロードされたアプリケーションが特権を有するか有しないかを判断する特権ＡＰ制御手段を有するようにした。また、一般のアプリケーションが特権ＡＰＩをアクセスして特権操作を行なえないようにした。なお、本明細書で言う「ＩＣカード」は、特定の大きさ、形状に限定されるものでなく集積回路を利用したカード状、チップ状、ブロック状、シート状の構造体を言う。また、本発明の趣旨を損なわない限り、ＩＣカードには、ＣＰＵが必ずしも含まれている必要はなく、含まれていても、含まれていなくともよい。
【０００９】
【発明の実施形態】
以下、本発明の実施形態について図を用いて説明する。なお、本発明はこれら実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。
【００１０】
（実施形態１）図１は、本発明の実施形態１に関するＩＣカードの動作状態における機能ブロック図を例示する。本実施形態におけるＩＣカードは、第一カードマネージャを有する。その第一カードマネージャは特権アプリケーションをダウンロードすることができる。
【００１１】
（実施形態１：構成）「第一カードマネージャ」は、ＩＣカード内のアプリケーションの動作を制御する。アプリケーションの動作の制御には、アプリケーションの起動や、実行中の制御、終了、削除、ダウンロードなどがある。これらの点は、従来の技術と同様である。
【００１２】
「アプリケーションの動作の制御」は、第一カードマネージャが、特権ＡＰＩ、や一般ＡＰＩを利用して行なう。
【００１３】
「ＡＰＩ」とは、アプリケーションインターフェースの略であり、アプリケーションから、そのアプリケーションの利用するモジュールを利用可能にするための入り口である。
【００１４】
「特権ＡＰＩ」とは、特定の権利を認められたもののみが利用可能なＡＰＩをいう。この特定の権利を認められたものの代表例が、本実施形態の第一カードマネージャであり、特権アプリケーションである。特権ＡＰＩは、ＲＯＭ１０１などに格納されたプログラムによって実現されるので、特権ＡＰＩを実現するステップを「特権ＡＰＩステップ」という。
【００１５】
「一般ＡＰＩ」とは、どのようなアプリケーションでも利用可能なＡＰＩをいう。この一般ＡＰＩは、ＩＣカード１００内で動作する全てのアプリケーションから使用できるようになっている。一般ＡＰＩにより利用できるのは、一般ライブラリの機能である。ここに「一般ライブラリ」の機能としては、例えば、文字列の操作（文字列の連接や文字列中における特定の文字のサーチなど）、データのコピー、構造を持ったデータのシリアライズ及びその逆操作、多倍長の整数演算などのための算術演算、などが挙げられる。
【００１６】
（実施形態１：特権アプリケーションをダウンロードする第一カードマネージャを有するＩＣカードの詳細）以下、本実施形態におけるＩＣカードであって、特権ＡＰＩ、一般ＡＰＩを利用して特権を有する特権アプリケーションをダウンロードする第一カードマネージャを有するＩＣカードについて図を用いて、詳細な説明を行なう。
【００１７】
図１は、特権アプリケーションをダウンロード可能な（ダウンロードした）ＩＣカードである。このダウンロードは第一カードマネージャによって行われる。第一カードマネージャは、プログラムによって実現される。したがって、そのプログラムは、特権アプリケーションをダウンロードするステップを計算機の一種であるＩＣカードに実行させるためのカードマネージャプログラムと言える。
【００１８】
「特権アプリケーション」１０３は、特権を有するアプリケーションをいう。ＲＯＭ１０１に格納されず、第一カードマネージャ１０２によりダウンロードされてＩＣカード１００の外部から導入されることとなる。
【００１９】
「ダウンロード」とは、ＩＣカードに対して、外部からアプリケーションを入力し、利用可能な状態に蓄積しておくことである。
【００２０】
ダウンロードの結果、アプリケーションは、ＥＥＰＲＯＭなど書き込みが可能なメモリに格納される。従来のＩＣカードにおいては、特権ＡＰＩ１０６は、ＩＣカード１００の製造時に格納されたアプリケーション、例えば、ＲＯＭ１０１内に格納された第一カードマネージャ１０２からしか使用することができないようになっているが、本発明においては、ＩＣカード１００の製造後にダウンロードされた特権アプリケーション１０３も、特権ＡＰＩ１０６を使用できるようにする。
【００２１】
そのために、例えば、従来のＩＣカードでは、特権ＡＰＩ１０６を利用するアプリケーションのプログラムカウンタの指すアドレスやアプリケーション識別子など（以下、「識別子など」と略する）を調べて第一カードマネージャ１０２のみが特権ＡＰＩ１０６を利用できるようにしていた点を改良し、以下のようにする。すなわち、第一カードマネージャ１０２が特権アプリケーション１０３をダウンロードし、特権アプリケーション１０３を起動すると、例えば、特権アプリケーション１０３が特権を使用することができるアプリケーションであるとして、その識別子などがＲＡＭ１８０３やＥＥＰＲＯＭ１８０４などに登録されるようにする。特権ＡＰＩ１０６においては、ＡＰＩを利用するアプリケーションの識別子などが特権を利用できるアプリケーションのものであることを確認して特権操作をアプリケーションに利用させるようにする。
【００２２】
（実施形態１：後発的にＩＣカードの設定の変更が可能となる例）従って、本発明においては、第一カードマネージャ１０２によりダウンロードされた特権アプリケーション２０１にも特権が利用可能となる。これにより、例えば、ＩＣカードの設定（例えば、省電力モードへの移行など）を変更することも可能となる。したがって、ＩＣカードの発行後に、特権アプリケーションをダウンロードすることにより、ＩＣカードの設定を変更することができる。
【００２３】
（実施形態１：後発アプリケーションでも機密情報へアクセス可能となる例）また、ＩＣカード１０１に格納された情報のうち、特に機密性の高いもの、例えば、銀行口座番号、暗証番号、残高、ＩＣカードの有効期限などへのアクセスが特権ＡＰＩ１０６により制御されている場合がある。本実施形態におけるＩＣカードにおいては、このような情報へアクセスして処理を行なうためのアプリケーションを、ＩＣカードの発行後にＩＣカードにダウンロードすることができる。
【００２４】
（実施形態１：ＩＣカード発行後の新プロトコルへの対応が可能となる例）さらに、新しいプロトコルに基づいて決済処理がされるようになった場合でも、その新しいプロトコルに基づいて動作する特権アプリケーションを本実施形態におけるＩＣカードにダウンロードすれば足り、新たにＩＣカードを発行する必要が無い。
【００２５】
（実施形態１：特権の説明）次に、前記「特権」は、カード特権管理手段の利用ができること、自身の削除が行われないこと、デフォルトアプリケーションとなれること、高レスポンスのための資源利用が可能であること、のうちいずれか一又は、二以上であるＩＣカードについて説明する。
【００２６】
ここに、特権アプリケーション１０３の有する「特権」とは、特権ＡＰＩ１０６を利用することができることである。特権ＡＰＩ１０６を利用することにより、例えば、カード特権管理手段の利用ができたり、自身の削除が行なわれないようにしたり、デフォルトアプリケーションとなれることができたり、高レスポンスのための資源利用が可能となるための機能が利用可能となる。
【００２７】
「カード特権管理手段」とは、アプリケーションを管理する種々の手段をいう。詳細については後述する。
【００２８】
「デフォルトアプリケーション」とは、ＩＣカードの動作が開始した時に最初に起動されるアプリケーション（あるいは、最初に起動される一連のアプリケーション）である。
【００２９】
「高レスポンスのための資源利用」とは、自動改札のゲートを開けるための処理を行なうように、リアルタイム性のある処理を行なうために、ＩＣカード内の資源を優先して利用することを意味する。
【００３０】
また、ここまでに挙げた機能が二以上同時に利用することもできるようになっていてもよい。
【００３１】
（実施形態１：カード特権管理手段の説明）次に、「カード特権管理手段」は、アプリケーションのライフサイクル管理機能、ダウンロード・削除機能、ダウンロードされるアプリケーションの署名検証機能、アプリケーションのファイアウオール提供機能、メモリ／通信制御機能を機能させるための特権ＡＰＩにより機能可能な機能のうちいずれか一又は、二以上を有するＩＣカードについて説明する。
【００３２】
「カード特権管理手段」とは、前述のように、アプリケーションを管理する種々の手段をいう。具体的には、アプリケーションのライフサイクル管理機能、ダウンロード・削除機能、ダウンロードされるアプリケーションの署名検証機能、アプリケーションのファイアウオール提供機能、メモリ／通信制御機能を機能などが該当する。
【００３３】
「アプリケーションのライフサイクル」とは、アプリケーションがダウンロードされた状態にあるかどうか、アプリケーションが起動されるための選択が可能な状態にあるかどうか、あるいは、選択が不可能な状態にあるかどうかなどを表わす。
【００３４】
「アプリケーションのライフサイクル管理機能」とは、アプリケーションの状態を管理するための機能であり、アプリケーションの選択が可能な状態から選択不可能な状態に遷移させ、また、逆方向の遷移を行なう。また、このような遷移に加え、本発明でのアプリケーションのライフサイクル管理機能においては、アプリケーションの起動から終了、削除までの状態の管理もすることができる。
【００３５】
「ダウンロード・削除機能」とは、アプリケーションをダウンロードしてＩＣカードに導入し、使用することができるようにする（例えばインストールする）機能、及び、ＩＣカードに導入されているアプリケーションを消し去り、アプリケーションの使用ができないようにする（例えばアンインストールする）機能である。この機能を用いることにより、例えば、アプリケーションをダウンロードし、それをインストールして利用可能とし、そのアプリケーションが必要でなくなれば、アンインストールしてインストール前の状態にＩＣカードを復帰させることができる。
【００３６】
「ダウンロードされるアプリケーションの署名検証機能」とは、ダウンロード機能によってＩＣカードに導入されるアプリケーションに付された署名が正しいかどうかを検証する機能をいう。この機能の具体例としては、例えば、アプリケーションが改ざんされていないかどうかを検証する機能である。署名検証機能により、ダウンロードされたアプリケーションが不正な動作をしないかどうかが検証されるため、ＩＣカードにとって重要な機能であるので、カード特権管理手段の機能とされる。
【００３７】
「アプリケーションのファイアウオール機能」とは、ＩＣカード内のアプリケーション間で、それぞれ悪影響を及ぼし合わないように制御する機能である。
【００３８】
メモリ／通信制御機能は、アプリケーションの使用するメモリを制御したり、Ｉ／ＯＩＦ１８０５を制御したりする機能である。
【００３９】
カード特権管理手段は、特権ＡＰＩ９０６によって利用可能であり、ＲＯＭ１０１などに格納されたプログラムによって実現される。そこで、カード特権管理手段を実現するステップを「カード特権管理ステップ」という。したがって、本実施形態の第一カードマネージャを実現するカードマネージャプログラムは、特権ＡＰＩ９０６を利用することにより、カード特権管理ステップの利用ができることになる。
【００４０】
（実施形態１：第二、第三のカードマネージャの導入が可能）また、ダウンロードされる特権アプリケーション１０３が、前述のように特権ＡＰＩを利用することができることから、ダウンロードされる特権アプリケーションは、アプリケーションの起動や、実行中の制御、終了、削除、ダウンロードなどをすることが可能となる。従って、ダウンロードされるアプリケーションにカードマネージャとしての機能を持つようにすることもできる。
【００４１】
即ち、あらかじめＩＣカードのＲＯＭに書き込まれていたオリジナルなカードマネージャの他に、第二、第三のカードマネージャを導入することができるのである。従って、カードマネージャ自体のバージョンアップや、アップデートがＩＣカード自体の交換なしに可能となる。
【００４２】
（実施形態１：ダウンロードされた特権アプリケーションが他のアプリケーションに特権ＡＰＩを提供：インターフェース）図２は、ダウンロードされた特権アプリケーション２０１が、他のアプリケーションＡＰ・１（２０２）、ＡＰ・２（２０３）などに特権ＡＰＩ１０６や一般ＡＰＩ１０７により提供される機能を提供していることを例示する。
【００４３】
従って、図１における特権アプリケーションがＡＰ・１（２０２）、ＡＰ・２（２０３）になんら関係なく単独に動作してもよい点で図２のものと異なる。
【００４４】
他方、図２においては、ダウンロードされた特権アプリケーション２０１は他のアプリケーションＡＰ・１（２０２）、ＡＰ・２（２０３）に特権ＡＰＩ１０６や一般ＡＰＩ１０７により提供される機能を提供し（言い換えれば、ダウンロードされた特権アプリケーション２０１が、インターフェース部（図示せず）を有しているようにするということ、ないしは、ダウンロードされた孫アプリケーションが特権アプリケーションであるということもできる。）、あるいは、これらのアプリケーションのライフサイクルを変更するなどして支配を行なったりする。なお、ＡＰ・１（２０２）、ＡＰ・２（２０３）は、一般ＡＰＩの機能を使用するときには、必ず特権アプリケーション２０１が提供する一般ＡＰＩの機能を利用しなければいけないわけではなく、一般ＡＰＩ１０７を直接利用することもできる。
【００４５】
（実施形態１：孫アプリケーションが特権アプリケーション例えば、カードマネージャとなりうる）さらに、ダウンロードされた特権アプリケーション２０１が、特権アプリケーションをダウンロードし、そのダウンロードされた特権アプリケーションが、特権アプリケーション２０１の提供する特権ＡＰＩにより、カードマネージャとして動作することも可能となる。
【００４６】
すなわち、カードマネージャとして動作する特権アプリケーション２０１が、別のカードマネージャをダウンロードし、特権アプリケーション２０１の支配下で動作させることも可能となる。つまり、第一カードマネージャ１０２からみて、特権アプリケーション２０１が子のアプリケーション（以下、「子アプリケーション」と略す）であるとすると、子アプリケーションである特権アプリケーション２０１がダウンロードしたアプリケーション（つまり、第一カードマネージャ１０２にとっては孫にあたるアプリケーション（以下、「孫アプリケーション」と略す））がカードマネージャとして動作することも実現できる。
【００４７】
（実施形態１：特権アプリケーションがダウンロードできることでアプリケーションのダウンロードの手順の違いが吸収できる）これにより、例えば、アプリケーションのダウンロードの手順の違いを吸収することができる。すなわち、ＩＣカードの発行後に、異なる手順でダウンロードする必要があるアプリケーションが提供されたとしても、その手順に対応したカードマネージャをダウンロードして動作させることにより、そのアプリケーションがダウンロード可能となる。
【００４８】
（実施形態１：特権ＡＰＩの仕様の変更に特権アプリケーションのダウンロードで対応可能）また、ＡＰ・１などの求めに応じて特権アプリケーションが特権ＡＰＩ１０６や一般ＡＰＩ１０７から得た結果は、特権アプリケーション２０１が受け取り、ＡＰ・１（２０２）などへ返される。結果として、特権アプリケーション２０１が、ＲＯＭ１０１に格納された一般ＡＰＩ１０７としてのＡＰＩを提供することができるようになる。これにより、新しい特権ＡＰＩの仕様や一般ＡＰＩの仕様が提案され、採用されても、その仕様に対応した特権アプリケーションをＩＣカードにダウンロードすれば、その仕様に対応できる。従って、特権ＡＰＩなどの仕様が変わるたびにＩＣカードを発行する必要がなくなる。
【００４９】
（実施形態１：第一カードマネージャが第二カードマネージャの配下のアプリケーションを制御する）次に、第一カードマネージャによってダウンロードされた子アプリケーションがさらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションである場合に、第一カードマネージャから孫アプリケーションのライフサイクルの変更、削除が可能であるＩＣカードについて説明する。
【００５０】
「第二カードマネージャを有する特権アプリケーション」とは、第一カードマネージャによってダウンロードされた特権アプリケーションであって、カードマネージャとして機能することが可能なアプリケーションである。すなわち、その特権アプリケーションは、他のアプリケーションをダウンロードし、そのアプリケーションを動作させるなどのアプリケーションのライフサイクルの変更や、そのアプリケーションを削除できる。
【００５１】
「アプリケーションのライフサイクルの変更、削除」とは、アプリケーションのライフサイクルの変更又は／及びアプリケーションの削除を意味する。「アプリケーションのライフサイクル」とは、上述したように、アプリケーションがダウンロードされた状態にあるかどうか、アプリケーションが起動されるための選択が可能な状態にあるかどうか、あるいは、選択が不可能な状態にあるかどうかなどを表わす。
【００５２】
なお、このような第一カードマネージャによってダウンロードされた特権アプリケーションであって、カードマネージャとして機能することが可能なアプリケーションを、「第二カードマネージャ」という。
【００５３】
（実施形態１：複数のカードマネージャが存在する場合の問題点）図２は、第一カードマネージャ１０２によってダウンロードされた子アプリケーションが、第二カードマネージャ２０１である場合、第二カードマネージャの管理下で孫アプリケーション（ＡＰ・１（２０２）など）が動作している状態を例示している。このような場合において、第一カードマネージャ１０２と第二カードマネージャ（特権アプリケーション２０１）との優越性が問題となる。
【００５４】
「優越性」とは、第一カードマネージャと第二カードマネージャとの管理権限の大小や管理内容の競合が考えられる場合の当該管理権限の是非であり、例えば、第一カードマネージャが、第二カードマネージャの管理下で動作するアプリケーションのライフサイクルの変更や削除をすることができるかどうかということを意味する。
【００５５】
この優越性が問題となる例としては、次の場合が挙げられる。すなわち、第二カードマネージャが、動作可能な日時に期限がついたアプリケーションをダウンロードして、そのアプリケーションを動作させているとする。もし動作可能な日時の期限が過ぎてしまったにもかかわらず、第二カードマネージャがそのアプリケーションを停止しない場合に、第一カードマネージャがそのアプリケーションを停止できるかどうかが問題となる。同様に、期限が過ぎた場合に、第一カードマネージャが、記憶容量を確保するなどのために、そのアプリケーションを削除できるかどうかも問題となる。
【００５６】
なお、期限が過ぎても第二カードマネージャがアプリケーションを停止しない場合の原因の一つとして、第二カードマネージャのバグがある。また、第一カードマネージャと第二カードマネージャの製作者が異なるが、第二カードマネージャと第二カードマネージャがダウンロードするアプリケーションの製作者が同じであることなどがある。この二番目の場合において、第二カードマネージャの製作者としては、ダウンロードしたアプリケーションをできるだけ長く動かそうとする意図を持ち、他方、第一カードマネージャの製作者としては、ＩＣカードの資源を適正に配分しようとする意図を持っていることがある。このようなときは、二つの意図が矛盾していることになり、この矛盾を解消する必要がある。
【００５７】
（実施形態１：上記問題点の解決手段）しかし、技術的には、孫アプリケーションは、ＩＣカードの第一カードマネージャ１０２を機能させているＶＭやＯＳの下で動作し、間接的ではあるが、第一カードマネージャ１０２の支配下にあるといえる。このため、第一カードマネージャ１０２が孫アプリケーションのライフサイクルの変更、孫アプリケーションの削除などを行なうことは不可能ではない。そこで、優劣の問題についての一つの解として、第一カードマネージャ１０２が孫アプリケーションのライフサイクルの変更、孫アプリケーションの削除を行なうようにしてもよい。もちろん、反対に、これらを禁止する構成にしてもよい。また、第二カードマネージャは、第一カードマネージャ１０２がダウンロードしたアプリケーションのライフサイクルの変更、削除が可能であってもよい。
【００５８】
（実施形態１：第一カードマネージャが第二カードマネージャの配下のアプリケーションを制御する詳細）第一カードマネージャ１０２が孫アプリケーションのライフサイクルの変更、孫アプリケーションの削除を行なうことの実現方法について、以下に詳細に説明する。これを実現する一つの方法は、以下の通りである。すなわち、特権アプリケーション２０１が孫アプリケーションをダウンロードすると、特権アプリケーション２０１は、第一カードマネージャ１０２に対して、孫アプリケーションをダウンロードしたという情報を出力し、孫アプリケーションがダウンロードされた領域のアドレス、サイズ、孫アプリケーションの名前など、孫アプリケーションを管理（例えば、ライフサイクルの変更や削除）するのに必要な情報を第一カードマネージャ１０２に通知する。
【００５９】
また、特権アプリケーション２０１が孫アプリケーションを起動すると、起動した孫アプリケーションに関する情報を第一カードマネージャ１０２に対して通知し、例えば、起動した孫アプリケーションに割り当てられたメモリ領域やアプリケーションを動作させるためのアプリケーション識別子などを通知する。特権アプリケーション２０１が、孫アプリケーションの動作を終了した時には、孫アプリケーションが終了したことを第一カードマネージャ１０２に通知する。同様に、特権アプリケーション２０１が孫アプリケーションを削除した場合には、削除したという情報を第一カードマネージャ１０２に通知する。
【００６０】
これにより、第一カードマネージャ１０２が特権アプリケーション２０１によるアプリケーションの管理の状況を知ることができ、特権アプリケーション２０１が孫アプリケーションのライフサイクルの変更や削除などの管理を行なうことができるようになる。これにより、第一カードマネージャ１０２によってダウンロードされた子アプリケーションがさらに孫アプリケーションをダウンロードすることができる特権を有する特権アプリケーション２０１である場合に、第一カードマネージャ１０２から孫アプリケーションのライフサイクルの変更、削除が可能であるようにすることができる。
【００６１】
なお、特権アプリケーション２０１が、第一カードマネージャ１０２に対して孫アプリケーションをダウンロードしたなどの情報は、特権アプリケーション２０１から直接的に第一カードマネージャ１０２に出力される必要はなく、特権ＡＰＩ１０６を介して特権アプリケーション２０１から間接的に第一カードマネージャ１０２に出力されるようになっていてもよい。
【００６２】
また、このような場合において、明示的に特権アプリケーション２０１が第一カードマネージャ１０２を出力先として指定する必要はない。例えば、特権アプリケーション２０１が特権ＡＰＩ１０６を用いて孫アプリケーションをダウンロードすると、特権ＡＰＩ１０６の中で、どのカードマネージャがダウンロードを行なったかが調べられ、もし、第二カードマネージャがダウンロードしたと判断されると、第一カードマネージャ１０２へダウンロードが行なわれたという情報が出力されるようになっていてもよい。また、アプリケーションの管理は、ＩＣカードのＶＭやＯＳにて行なわれ、第一カードマネージャが、全てのアプリケーションの管理のための情報を入手し、入手した情報に基づいてアプリケーションの管理を行なうことができるようになっていてもよい。
【００６３】
（実施形態１：第一カードマネージャが第二カードマネージャの配下のアプリケーションを制御できない）また、第二カードマネージャは、第一カードマネージャからの孫アプリケーションのライフサイクルの変更、削除を禁止することができるＩＣカードについても説明する。（主に請求項１関連）
【００６４】
（実施形態１：第一カードマネージャが第二カードマネージャの配下のアプリケーションを制御できない詳細）すなわち、以上述べたこととは反対に、第二カードマネージャは、第一カードマネージャからの孫アプリケーションのライフサイクルの変更、削除を禁止することもできる。これを実現する一つの方法は、次の通りである。すなわち、特権アプリケーション２０１が孫アプリケーションのダウンロードや、起動、終了、削除を行なっても、第一カードマネージャ１０２に何の情報も出力しないようにすることや、特権ＡＰＩ１０６の利用により、各アプリケーションがどのカードマネージャの支配下にあるかの情報がＩＣカード１００内に格納されるようにし、他のカードマネージャの支配下にあるアプリケーションのライフサイクルを変更できないように特権ＡＰＩ１０６を作成することにより実現することができる。
【００６５】
（実施形態１：第二カードマネージャが第一カードマネージャの支配下のアプリケーションが制御できる場合）また、第二カードマネージャは、第一カードマネージャがダウンロードしたアプリケーションのライフサイクルの変更、削除が可能であるようになっていてもよい（主に請求項２関連）。
【００６６】
（実施形態１：第二カードマネージャが第一カードマネージャの支配下のアプリケーションが制御できることを実現する方法）これを実現する一つの方法としては、第一カードマネージャがアプリケーションをダウンロードすると、第一カードマネージャは、そのダウンロードされたアプリケーションを管理するための情報を第二カードマネージャに通知する方法がある。
【００６７】
また、ＩＣカードにダウンロードされた全てのアプリケーションのライフサイクルなど、アプリケーションを管理するために必要な情報がＩＣカードのＶＭやＯＳに保持されている場合には、次のように管理してもよい。すなわち、第二カードマネージャがＶＭやＯＳに保持されている情報を読み出し、その情報に基づいて、第一カードマネージャがダウンロードしたアプリケーションのライフサイクルの変更や削除を行なう。このような方法を用いると、第二カードマネージャは、第一カードマネージャによってダウンロードされたアプリケーションに限らず、ＩＣカードで動作する全てのアプリケーションのライフサイクルの変更や削除などのアプリケーションの管理を行なうことができる。
【００６８】
（実施形態１：優位性の選択のための選択手段を備える形態）また、第一カードマネージャ１０２によってダウンロードされた子アプリケーションがさらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーション２０１である場合に、第一カードマネージャ１０２の有する特権と、第二カードマネージャの有する特権との優越性を選択することができる選択手段を有するようにしてもよい（主に請求項３関連）。
【００６９】
このような選択手段を実現するために、Ｉ／ＯＩＦ１８０５から優位性を選択するための信号を受理するアプリケーションをＩＣカード内で動作させておくようにしても良いし、あるいは、選択手段を実装する専用のハードウェアをＩＣカードに備えるようにしても良い。この選択手段による選択結果を特権ＡＰＩ１０６、一般ＡＰＩ１０７、第一カードマネージャ、特権アプリケーション２０１が参照することにより、選択された優越性に従った動作を実現することができるようになる。
【００７０】
（実施形態１：第一カードマネージャと第二カードマネージャの関係は、他のカードマネージャ間についても成り立つ）以上においては、第一カードマネージャと、その子アプリケーションが第二カードマネージャを有する特権アプリケーションとの関係について説明したが、このような場合に限定されるものではない。例えば、第二カードマネージャがさらに特権を有するアプリケーション（孫特権アプリケーションと呼ぶ）をダウンロードし、その孫特権アプリケーションが第三カードマネージャを有する場合における、第三カードマネージャと第一カードマネージャとの関係、あるいは、第三カードマネージャと第二カードマネージャとの関係、さらに、第四カードマネージャ、第五カードマネージャなどとの関係にも適用することができる。
【００７１】
（実施形態１：効果の簡単な説明）以上説明した実施形態において、第一カードマネージャ１０２が特権を有するアプリケーションである特権アプリケーションをダウンロードすることができる。これにより、ＩＣカードの発行後にＩＣカードの設定を行なう特権アプリケーションをダウンロードして設定の変更を行ない、あるいは、特権が無いと得られないデータを操作するアプリケーションをダウンロードすることができる。結果として、例えば、新しい商取引のプロトコルに対応することができる。また、そのような特権アプリケーションは、カードマネージャとして動作することができるので、アプリケーションのダウンロードの手順の違いを吸収することができ、あるいは、新しい規格のインターフェースを孫アプリケーションに提供することができる。すなわち、特権アプリケーションをＩＣカードにダウンロードすればよいので、新たにＩＣカードを発行する必要がなくなる。
【００７２】
また、第一カードマネージャが、第二カードマネージャのダウンロードした孫アプリケーションのライフサイクルの変更、削除が可能とすることで、例えば、孫アプリケーションの動作の期限が過ぎた場合に、第一カードマネージャより、そのアプリケーションの動作を終了させ、あるいは、削除することができる。また、第二カードマネージャが、第一カードマネージャからの孫アプリケーションのライフサイクルの変更、削除を禁止することにより、第二カードマネージャが第一カードマネージャより優越することになる。これにより、第二カードマネージャを第一カードマネージャの代わりに使用することができ、カードマネージャのバージョンアップや更新に相当することが実現できる。
【００７３】
（実施形態２）次に、第一カードマネージャは、アプリケーションが特権を有するか有しないかを判断するための特権ＡＰ制御手段を有するＩＣカードについて説明する。
【００７４】
（実施形態２：構成）図３は、本発明の実施形態２におけるＩＣカードの機能ブロック図を示す。本実施形態においては、実施形態１における図１の機能ブロック図に特権ＡＰ制御手段３０１が追加されている。本実施形態においては、第一カードマネージャ１０２が特権ＡＰ制御手段３０１を有している。特権ＡＰ制御手段３０１は、アプリケーションが特権を有するか有しないかを判断するための手段である。
【００７５】
（実施形態２：アプリケーションが特権を有するか有しないかを判断する方法）アプリケーションが特権を有するか有しないかを判断する方法の一つとしては、アプリケーションにそのアプリケーションの属性として、特権を有するかどうかを付加しておく方法がある。すなわち、アプリケーションをダウンロードした時には、アプリケーションの属性を調べ、特権を有する属性を持つアプリケーションに対して、特権を認めるようにする。
【００７６】
しかし、これでは、不正な動作をするアプリケーションに特権を有する属性を容易に付けることができるので、不正な動作をするアプリケーションにも特権を認めることになりかねない。
【００７７】
（実施形態２：判断する方法＝署名）それを防ぐ方法の一つとして、アプリケーションに署名を付加する方法がある。図４は、アプリケーション本体と署名との関係を示す。「アプリケーション本体」とは、アプリケーションの実行に必要な情報である。例えば、アプリケーションの実行コード、アプリケーションに渡すパラメータなどを格納するアプリケーション管理情報などである。図４において、署名４０２は、アプリケーション本体４０１からハッシュ値を求め、それを暗号化して得られることを示している。「ハッシュ値」とは、出力値が一致するような二つの異なるデータを見つけることが計算量的に困難な関数により得られる出力値のことである。このような関数としては、ＳＨＡ−１（ＳｅｃｕｒｅＨａｓｈＳｔａｎｄａｒｄ−１）、ＭＤ５（ＭｅｓｓａｇｅＤｉｇｅｓｔ５）などが知られており、ＳＨＡ−１は入力されたデータに１６０ビットのハッシュ値を対応付け、ＭＤ５は、１２８ビットのハッシュ値を対応付ける。
【００７８】
署名は、このようなハッシュ関数の出力値を暗号化したものである。暗号として公開鍵暗号化方式を用いる場合には、アプリケーションの動作を保証する者が、その秘密鍵によってハッシュ値を暗号化したものが署名となる。なお、暗号化に用いる秘密鍵は、アプリケーションの動作を保証する者のものである以外に、アプリケーションの作成を行った者や、アプリケーションの配布を行なう者などの秘密鍵である場合がある。誰の秘密鍵により暗号化されたかを知ることにより、アプリケーションの出所などを知ることができる。このように生成された署名の検証により、アプリケーション本体が不正動作をしないものであることを確認することができる。例えば、ＩＣカード１００の第一カードマネージャ１０２がアプリケーション本体４０１と署名４０２とをダウンロードし、署名４０２を生成した者の公開鍵によって復号し、一方、アプリケーション本体４０１に署名を生成するときに使用したハッシュ関数を適用してハッシュ値を得て、復号の結果とハッシュ値が等しいかどうかで、アプリケーション本体がその動作を保証されたものであるかどうかが判断できる。
【００７９】
（実施形態２：特権を有するかどうか、また、署名が正しいかどうかを検証した結果の管理）特権ＡＰ制御手段３０１は、第一カードマネージャ１０２がダウンロードしたアプリケーションが特権を有するかどうか、また、署名が正しいかどうかを検証した結果を図５のように表によって管理するようにしてもよい。図５の表において、左の列は、第一カードマネージャ１０２がダウンロードしたアプリケーションの識別子（例えば、名前など）であり、左の列がアプリケーションによる特権の利用を許可するかどうかを示す。例えば、「○」になっていればそのアプリケーションに対して特権の利用を許可し、「×」になっていれば特権の利用を許可しないことを表す。なお、署名の検証は、アプリケーションをダウンロードした時に行なったり、また、アプリケーションとその署名とを格納しておき、アプリケーションの起動時や、アプリケーションが特権ＡＰＩ１０６を利用しようとした時に署名の検証を行なったりすればよい。
【００８０】
特権ＡＰＩ１０６は、アプリケーションからアクセスがあった場合には、図５の表を参照して、特権の利用を許可されたアプリケーションからのアクセスかどうかを調べ、特権の利用を許可されたアプリケーションからのアクセスであれば、期待された動作を行ない、そうでなければ、エラーを返したりする。
【００８１】
（実施形態２：特権ＡＰ制御手段の処理フロー）図６は、本実施形態における第一カードマネージャ１０２の動作を説明するフローチャートである。ステップＳ６０１において、特権アプリケーションを署名と共にダウンロードする。ステップＳ６０２において、署名を検証する。署名の検証ができれば、ステップＳ６０３において、ダウンロードした特権アプリケーションの特権を許可する。なお、署名の検証は、特権アプリケーションをダウンロードした時に行なう必要はなく、特権アプリケーションが特権ＡＰＩ１０６にアクセスするまでに行なえばよい。例えば、特権アプリケーションが最初に特権ＡＰＩ１０６にアクセスしたときに署名を検証するようにしてもよい。
【００８２】
特権ＡＰ制御手段３０１は、第一カードマネージャを実現するカードマネージャプログラムによって実現される。そこで、カードマネージャプログラムの中で、特権ＡＰ制御手段３０１を実現するステップを「特権ＡＰ制御ステップ」という。
【００８３】
（実施形態２：特権アプリケーションが利用可能な関数との関連付け）次に、特権ＡＰＩに基づく機能は複数の関数からなり、特権ＡＰ制御手段は、特権アプリケーションごとに、特権アプリケーションが利用可能な関数と、その特権アプリケーションとを関連付ける特権ＡＰ識別情報管理機能を有するＩＣカードについて説明する。
【００８４】
「特権ＡＰＩ１０６に基づく機能」とは、特権ＡＰＩ１０６にアクセスすることにより実現できる機能である。
【００８５】
「特権ＡＰＩ１０６に基づく機能は複数の関数からなる」とは、特権ＡＰＩ１０６にアクセスすることにより実現できる機能は、複数の関数（またはメソッド）により提供されるということを意味する。
【００８６】
「特権ＡＰ識別情報管理機能」とは、特権アプリケーションごとに、特権アプリケーションが利用可能な関数と、その特権アプリケーションとを関連付ける機能である。この機能は、例えば、「アプリケーション」という名前の列と「利用可能関数」という名前の列からなる図１０に示すような表により実現できる。「アプリケーション」という名前の列には、特権アプリケーションを識別するための情報が格納され、「利用可能関数」という名前の列には、各特権アプリケーションが利用することができる関数を識別する情報が格納される。特権ＡＰＩ１０６がアクセスされた場合には、アクセスを行なったアプリケーションが特権を利用することが許可されたアプリケーションであることを確認するとともに、図１０の表を調べて、アプリケーションの利用しようとする関数が「利用可能関数」という名前の列に格納されていることを確認する。
【００８７】
（実施形態２：利用可能な関数がブロック単位）また、特権ＡＰＩ１０６にアクセスすることにより実現できる機能を提供する関数をいくつかの集合であるブロックに分けておき、図１０の表の「利用可能関数」という名前の列に、そのブロックを識別する情報を格納するようにしてもよい。このようにすれば、あるアプリケーションが利用可能な関数が多数存在する場合でも、ブロックを識別する情報を格納すればよいので、格納する情報量を少なくすることができる。したがって、このような手法は、記憶領域の容量が厳しいＩＣカードに好適である。
【００８８】
（実施形態２：効果の簡単な説明）本実施形態におけるＩＣカードは、ダウンロードされたアプリケーションが特権を有するかどうかを判断する特権ＡＰ制御手段を有する第一カードマネージャを有するので、例えば、不正な動作をするアプリケーションに特権を認めることがなくなる。また、ダウンロードされたアプリケーションごとに関数レベル、あるいは関数の集まりであるブロックレベルで、特権操作の許可を制御することができる。
【００８９】
（実施形態３）次に、第一カードマネージャは、アプリケーションから特権ＡＰＩの利用の要求である特権ＡＰＩ利用要求を受け付ける特権ＡＰＩ利用要求受付部を有し、特権ＡＰＩ利用要求に基づく第一カードマネージャの特権ＡＰ制御手段の判断結果が、アプリケーションが特権アプリケーションであるとの判断結果である場合に、特権アプリケーションに対して特権ＡＰＩを利用可能とするインターフェース部を有するＩＣカードについて説明する。
【００９０】
（実施形態３：構成）図７は、本発明の実施形態３にかかわるＩＣカードの機能ブロック図を示す。本実施形態におけるＩＣカード７００は、ＲＯＭ７０１を有し、ＲＯＭ７０１の中に、第一カードマネージャ７０２、特権ＡＰＩ７０６、一般ＡＰＩ７０８、カード特権管理手段７０７が存在する。第一カードマネージャ７０２、特権ＡＰＩ７０６、一般ＡＰＩ７０８、カード特権管理手段７０７は、実施形態１および実施形態２における第一カードマネージャ１０２、特権ＡＰＩ１０６、一般ＡＰＩ１０７、カード特権管理手段（図示せず）に相当する。
【００９１】
本実施形態の特徴は、第一カードマネージャ７０２が、特権ＡＰ制御手段７０９と、特権ＡＰＩ利用要求受付部７１０と、インターフェース部７１１を有する点である。
【００９２】
（実施形態３：実施形態２との違い）本実施形態に対応する図７と実施形態２に対応する図３との違いは、本実施形態においては、アプリケーションが特権ＡＰＩを利用しようとしたときに、そのアプリケーションに特権ＡＰＩの利用を許可してもよいかどうかの判断の仕方がより詳細になっている点である。
【００９３】
（実施形態３：想定しているＩＣカード）なお、本実施形態は、いわゆるＪａｖａ（登録商標）Ｃａｒｄ型のＩＣカードを主に想定したものであり、ＩＣカードのＯＳとＶＭとを設けるような構成のソフトウェア・アーキテクチャを有するＩＣカードに適している。
【００９４】
（実施形態３：構成）「特権ＡＰ制御手段」７０９は、アプリケーションが特権を有するかどうかを判断する。すなわち、実施形態２における特権ＡＰ制御手段３０１と同じ動作をし、例えば、図５に示すアプリケーションごとに特権の利用を許可するかどうかの表を管理する。
【００９５】
「特権ＡＰＩ利用要求受付部」７１０は、アプリケーションからの特権ＡＰＩの利用の要求である特権ＡＰＩ利用要求を受け付ける。したがって、アプリケーションが特権ＡＰＩ７０６を利用する場合には、直接的に特権ＡＰＩ７０６をアクセスするのではなく、特権ＡＰＩ利用要求受付部７１０に特権ＡＰＩ利用要求を出力することになる。
【００９６】
「インターフェース部」７１１は、特権ＡＰＩ利用要求に基づく第一カードマネージャの特権ＡＰ制御手段７０９の判断結果が、アプリケーションが特権アプリケーションであるとの判断結果である場合に、特権アプリケーションに対して特権ＡＰＩ７０６を利用可能とする。
【００９７】
「特権ＡＰＩ利用要求に基づく第一カードマネージャの特権ＡＰ制御手段７０９の判断結果」とは、特権ＡＰＩ利用要求受付部７１０に特権ＡＰＩ利用要求を出力したアプリケーションが特権を利用することが許可されているかどうかを、特権ＡＰ制御手段７０９により判断した結果である。
【００９８】
その判断した結果により、特権を利用することが許可されていることが判明した場合には、インターフェース部は、特権ＡＰＩ利用要求を出力したアプリケーションに対して特権ＡＰＩ７０６の利用を可能とする。例えば、特権ＡＰＩ利用要求受付部７１０に受け付けられた特権ＡＰＩ利用要求をインターフェース部より、特権ＡＰＩ７０６へ転送する。あるいは、特権ＡＰＩ７０６の利用を認めるチケット（許可証）を、特権ＡＰＩ利用要求受付部７１０に特権ＡＰＩ利用要求を出力したアプリケーションに発行し、アプリケーションは、特権ＡＰＩ７０６に対して、インターフェース部より発行されたチケットを提示して特権操作の利用を行なうようにしてもよい。
【００９９】
（実施形態３：第一カードマネージャの特権ＡＰ制御手段での判断結果に基づくＩＣカードの処理フロー）図８は、第一カードマネージャ７０９の動作を説明するフローチャートである。ステップＳ８０１において、特権ＡＰＩ利用要求を特権ＡＰＩ利用要求受付部７１０において受け付ける。ステップＳ８０２において、特権ＡＰＩ利用要求を出力したアプリケーションを特定する。ステップＳ８０３において、特定されたアプリケーションの特権利用が許可されているかどうかを、特権ＡＰ制御手段７０９により判断する。もし、特権利用が許可されている場合には、ステップＳ８０４において、特権ＡＰＩ利用要求を受け付けさせたアプリケーションに特権ＡＰＩ７０６を利用させる。特権利用が許可されていない場合には、特権ＡＰＩ７０６の利用をさせない。
【０１００】
（実施形態３：効果の簡単な説明）このような実施形態により、特権ＡＰＩ７０６がインターフェース部７０６を介してアプリケーションからアクセスされるようになっている場合には、特権ＡＰＩ７０６は、第一カードマネージャのみからアクセスがされるので、従来のＩＣカードの特権ＡＰＩがそのまま流用できる。また、インターフェース部７０６により特権ＡＰＩ７０６を利用するチケットが発行される場合には、チケットを入手したアプリケーションのみが特権ＡＰＩ７０６を利用することができるので、特権ＡＰ制御手段７０９により特権の利用が許可されていないアプリケーションが特権操作を行なうことができず、安全性が確保できる。
【０１０１】
（実施形態４）次に、第一カードマネージャの特権ＡＰ制御手段は、アプリケーションが直接的に特権ＡＰＩを利用しようとする場合に、特権ＡＰ制御手段の判断結果が、アプリケーションが特権アプリケーションであるとの判断結果である場合に、特権アプリケーションが特権ＡＰＩを直接的に利用可能とするＩＣカードについて説明する。
【０１０２】
（実施形態４：構成）図９は、本発明の実施形態４にかかわるＩＣカードの機能ブロック図を示す。図９においてＩＣカード９００は、ＲＯＭ９０１を有し、ＲＯＭ９０１の中に、第一カードマネージャ９０２、特権ＡＰＩ９０６、一般ＡＰＩ９０８、カード特権管理手段９０７が存在する。第一カードマネージャ９０２、特権ＡＰＩ９０６、一般ＡＰＩ９０８、カード特権管理手段９０７は、実施形態１および実施形態２における第一カードマネージャ１０２、特権ＡＰＩ１０６、一般ＡＰＩ１０７、カード特権管理手段（図示せず）に相当する。
【０１０３】
本実施形態の特徴は、第一カードマネージャ９０２が、特権ＡＰ制御手段９０９を有し、特権ＡＰＩ９０６がアクセスされた場合に、特権ＡＰ制御手段９０９により、特権ＡＰＩ９０６にアクセスを行なったアプリケーションが特権の利用を許可されているかどうかを判断する点である。本実施形態は、いわゆるＮａｔｉｖｅ型のＩＣカードを主に想定したものであり、ＯＳとアプリケーションの間にＶＭを設けず、アプリケーションが直接ＯＳにアクセスするような構成のソフトウェア・アーキテクチャを有するＩＣカードに適している。
【０１０４】
「特権ＡＰ制御手段」９０９は、アプリケーションが特権を有するかどうかを判断する。すなわち、実施形態２における特権ＡＰ制御手段３０１と同じ動作をし、例えば、図５に示すアプリケーションごとに特権の利用を許可するかどうかの表を管理する。また、本実施形態において、特権ＡＰ制御手段９０９は、アプリケーションが直接的に特権ＡＰＩ９０６を利用しようとする場合に、特権ＡＰ制御手段９０９の判断結果が、アプリケーションが特権アプリケーションであるときに、特権アプリケーションが特権ＡＰＩ９０９を直接的に利用可能とする。
【０１０５】
「アプリケーションが直接的に特権ＡＰＩ９０６を利用する」とは、図９に示すように特権アプリケーション９０３が、図７に示す場合と異なり、ＲＯＭ９０１に格納されている特権ＡＰＩ９０６を直接アクセスすることである。
【０１０６】
「特権ＡＰ制御手段９０９の判断結果」とは、特権ＡＰＩ９０６へアクセスしたアプリケーションが特権の利用を許可されているかどうかに関する特権ＡＰ制御手段９０９による判断結果である。
【０１０７】
「特権アプリケーションが特権ＡＰＩ９０９を直接的に利用可能とする」とは、特権ＡＰ制御手段９０９により特権の利用を許可されているアプリケーションである特権アプリケーションが特権ＡＰＩ９０９を直接的に利用することを、特権ＡＰ制御手段９０９が許可することである。
【０１０８】
したがって、本実施形態においては、特権ＡＰＩ９０６がアプリケーションから直接アクセスが行なわれた場合には、特権ＡＰＩ９０６は、アクセスを行なったアプリケーションが特権の利用を許可されたものであるかどうかを、特権ＡＰ制御手段９０９に判断を実行させる。特権ＡＰ制御手段９０９が、特権の利用を許可されたアプリケーションであると判断した場合には、特権ＡＰＩ９０６に対して、アクセスを行なったアプリケーションに対して特権ＡＰＩを利用させる信号を出力することになる。
【０１０９】
（実施形態４：効果の簡単な説明）このような実施形態により、特権の利用を許可されたアプリケーションのみが特権ＡＰＩ９０６を利用することができ、安全性が保持される。また、アプリケーションは、特権ＡＰＩ９０６を直接利用することが可能となり、途中に別のインターフェースを介して特権ＡＰＩ９０６を利用することによるオーバーヘッドを避けることができ、効率的に特権ＡＰＩ９０６を利用することができる。
【０１１０】
（実施形態５）次に、第一カードマネージャのインターフェース部は、アプリケーションが特権アプリケーションのインターフェース部を介した特権ＡＰＩの利用を不可とするＩＣカードについて説明する（特権ＡＰＩ用のインターフェースの又貸しの禁止）。
【０１１１】
（実施形態５：構成）図１１は、本発明の実施形態５を説明するためのＩＣカードの機能ブロック図である。図１１は、実施形態３の説明に使用した図７とほぼ同じであり、ＩＣカード１１００がＩＣカード７００に、ＲＯＭ１１０１がＲＯＭ７０１に、第一カードマネージャ１１０２が第一カードマネージャ７０２に、特権アプリケーション１１０３が特権アプリケーション７０３に、特権ＡＰＩ１１０５が特権ＡＰＩ７０６に、カード特権管理手段１１０７がカード特権管理手段７０７に、一般ＡＰＩ１１０６が一般ＡＰＩ７０８に、特権ＡＰ制御手段１１０８が特権ＡＰ制御手段７０９に、特権ＡＰＩ利用要求受付部１１０９が特権ＡＰＩ利用要求受付部７１０に、インターフェース部１１１０がインターフェース部７１１に、対応する。
【０１１２】
図１１において、特権アプリケーション１１０３は、第二カードマネージャとしての機能をＡＰ・１（１１０４）に提供しており、ＡＰ・１（１１０４）が第二カードマネージャの機能を利用する場合には、特権アプリケーション１１０３の有するインターフェース部１１１１をアクセスするとする。
【０１１３】
この場合において、ＡＰ・１（１１０４）がインターフェース部１１１１をアクセスし、特権操作を要求し、インターフェース部１１１１が、その要求をそのまま特権ＡＰＩ利用要求として特権ＡＰＩ利用要求受付部１１０９に対して出力すると、特権アプリケーションではない、ＡＰ・１（１１０４）が特権アプリケーション１１０３を介して特権操作を実行できてしまうという問題を生じることになる。
【０１１４】
本実施形態は、この点を解決するために、第一カードマネージャ１１０２のインターフェース部１１１０は、アプリケーションが特権アプリケーション１１０３のインターフェース部１１１１を介した特権ＡＰＩ１１０５の利用を不可とするものである。
【０１１５】
すなわち、インターフェース部１１１０は、特権アプリケーション以外のアプリケーションが、特権アプリケーション１１０３のインターフェース部１１１１を介して特権ＡＰＩ１１０５へアクセスしようとすることを検出し、もしそのようなことが検出されると、特権ＡＰＩ１１０５へのアクセスを不可とする。
【０１１６】
（実施形態５：インターフェース部を介している回数によって判断）このことを実現する方法としては、特権ＡＰＩ１１０５に至るまでのインターフェース部を経由した回数をチェックすることによる方法がある。例えばインターフェース部を二回以上経由した場合に特権ＡＰＩ１１０５へのアクセスが不可とされる。図１１を用いて例を挙げると次のようになる。アプリケーションが直接、特権ＡＰＩ利用要求受付部１１０９を経由してインターフェース部１１１０を利用すると、インターフェース部１１１０を一回だけ経由するので、インターフェース部を二以上の回数利用したという理由で特権ＡＰＩ１１０５へのアクセスが不可とされることはない（ただし、アプリケーションが特権アプリケーションでないという理由でアクセスが不可とされることはある）。
【０１１７】
それに対し、もし、アプリケーションが、特権アプリケーション１１０３の備えるインターフェース部１１１１を経由し、それからインターフェース部１１１０を経由して特権ＡＰＩ１１０５を利用しようとすると、インターフェース部１１１０は、特権アプリケーション１１０３から利用されているので、アクセスは許可される。しかし、この場合には、二つのインターフェース部、すなわち、インターフェース部１１１１とインターフェース部１１１０とを経由しており、特権ＡＰＩ１１０５へのアクセスが不可とされる。
【０１１８】
（実施形態５：スタックの内容によって判断）また、インターフェース部１１１０が、アプリケーションのスタックの内容を調べて特権ＡＰＩ１１０５へのアクセスを制御する方法もある。
【０１１９】
「スタック」とは、アプリケーションの動作のための一時作業領域であり、関数が呼ばれると、その関数が終了したときに戻るべきアドレス（関数の戻り番地）を記録することや、関数の内部で使用される局所変数の値を保持するために用いられる「後入れ先出し」の領域である。「後入れ先出し」とは、例えば、Ａ、Ｂの順にデータを入れると、入れた順の逆であるＢ、Ａの順にデータが取り出されることを意味する。
【０１２０】
図１２は、ＡＰ・１（１１０４）のスタックの一例を示している。符号１２０１を付した部分がＡＰ・１（１１０４）の実行部分にかかわる関数の戻り番地や局所変数の値を格納している部分である。ＡＰ・１（１１０４）がインターフェース部１１１１にアクセスし、インターフェース部１１１１における処理が行なわれると、スタックには、符号１２０２を付した部分が格納される。この部分には、インターフェース部１１１１における処理に伴う関数の戻り番地や局所変数の値が格納されることになる。
【０１２１】
インターフェース部１１１１が特権ＡＰＩ利用要求受付部１１０９にアクセスし、特権ＡＰＩ利用要求受付部１１０９の処理が行なわれると、符号１２０３を付した部分が格納される。この部分には、特権ＡＰＩ利用要求受付部１１０９における処理に伴う関数の戻り番地や局所変数の値が格納されることになる。インターフェース部１１１０は、このようなスタックの内容を調べることにより、ＡＰ・１（１１０４）が特権アプリケーション１１０３のインターフェース部１１１１を介して特権ＡＰＩ１１０５を利用しようとしているかどうかを判断することができる。スタックの内容を調べてこのような判断を行なうには、例えば、デバッガがスタックの内容を調べてバックトレースを行なう技術を使用すればよい。
【０１２２】
（実施形態５：メッセージパッシングの利用）また、ＡＰ・１（１１０４）が特権アプリケーション１１０３のインターフェース部１１１１にアクセスを要求するときや、特権アプリケーション１１０３が特権ＡＰＩ利用要求受付部１１０９に特権ＡＰＩ利用要求を出力するときに、そのアクセスの要求や特権ＡＰＩ利用要求をメッセージにして送るようにする実装例（メッセージパッシングによる実装例）もある。このような場合には、そのようなメッセージに、どこを経由したかの情報を付加するようにし、インターフェース部１１１０は、この付加された情報により、どのような経路により要求が送られてきたかを判断するようにすることも可能である。
【０１２３】
図１３は、メッセージに、どこを経由したかの情報を付加してインターフェース部１１１１へアクセスの要求を出力し、また、特権ＡＰＩ利用要求受付部１１０９に特権ＡＰＩ利用要求を出力する例を示している。ＡＰ・１（１１０４）は、特権アプリケーション１１０３に対して要求メッセージ１３０１を送る際に、要求メッセージ１３０１にＡＰ・１（１１０４）がメッセージの出所であることを示す情報を付加する。特権アプリケーション１１０３が要求メッセージ１３０１を特権ＡＰＩ利用要求として第一カードマネージャ１１０２に送る際には、要求メッセージ１３０１に特権アプリケーション１１０３を経由した情報を付加したメッセージ１３０２を生成して送る。インターフェース部１１１０は、このように送られたメッセージの内容を検査し、特権アプリケーションではないアプリケーションＡＰ・１（１１０４）からのメッセージが特権アプリケーション１１０３を経由して送られてきたかどうかを検出することができる。
【０１２４】
（実施形態５：効果の簡単な説明）このような実施形態により、特権アプリケーションでないアプリケーションが特権アプリケーションを介して特権操作を行なうことを防止することができ、安全性が高まる。
【０１２５】
（実施形態６）次に、第一カードマネージャによってダウンロードされた子アプリケーションがさらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションである場合に、第一カードマネージャ又は／及び、第二カードマネージャは、孫アプリケーションを含むアプリケーションが選択された回数をカウントするカウンター手段を有するＩＣカードについて説明する（主に請求項４関連）。
【０１２６】
本実施形態において、第一カードマネージャがカウンター手段を持ち、第二カードマネージャがカウンター手段を持たない形態や、第一カードマネージャはカウンターを持たず、第二カードマネージャのみがカウンター手段を持つ形態や、第一カードマネージャと第二カードマネージャの両方がカウンター手段を持つ形態を挙げることができる。以下においては、まず、第一カードマネージャのみがカウンター手段を持つ形態について説明する。
【０１２７】
（実施形態６：第一カードマネージャのみがカウンター手段を持つ形態の構成）図１４は、本発明の実施形態６に関するＩＣカードの機能ブロック図を示す。この図にあるように、本実施形態においては、第一カードマネージャ１４０２がアプリケーションの選択された回数を記録するカウンター手段１４０６を有する。
【０１２８】
「カウンター手段」１４０６は、内部にカウンターを備え、そのカウンターの値を１上げる操作や、カウンターの値を読み出すことができるようになっている。
【０１２９】
本実施形態は、カウンター手段によりアプリケーションが選択された回数に基づき、例えば、アプリケーションの利用の課金ができるようにするものである。
【０１３０】
図１４において、ＩＣカード１４００は、ＲＯＭ１４０１を有し、ＲＯＭ１４０１は、第一カードマネージャ１４０２を備えている。第一カードマネージャ１４０２によってダウンロードされた子アプリケーション１４０３が、さらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションであるとする。
【０１３１】
符号１４０４を付したＡＰ・１が、第二カードマネージャによってダウンロードされたアプリケーションであり、第一カードマネージャ１４０２にとっての孫アプリケーションとなる。
【０１３２】
「第一カードマネージャ」は、カウンター手段１４０６を備えている。このカウンター手段は、孫アプリケーションを含むアプリケーションが選択された回数をカウントする。
【０１３３】
「孫アプリケーションを含むアプリケーション」とは、第一カードマネージャが直接管理する子アプリケーションのみならず、第一カードマネージャによりダウンロードされた子アプリケーションである特権アプリケーションが有するカードマネージャによりダウンロードされたアプリケーション（つまり孫アプリケーション）、さらにその子孫などを含む。
【０１３４】
すなわち、その孫アプリケーションが特権アプリケーション（孫特権アプリケーションと呼ぶことにする）である場合に、その孫特権アプリケーションによりさらにダウンロードされたアプリケーション（つまり曾孫アプリケーション）などのように、第二カードマネージャの直接的、および間接的な支配が及ぶアプリケーションの全てである。
【０１３５】
「アプリケーションが選択された回数」とは、アプリケーションが起動された回数であり、さらに、「選択された回数」には、アプリケーションが休止状態から活動状態に移行した回数も含まれる場合もある。
【０１３６】
（実施形態６：第一カードマネージャが他のカードマネージャからアプリケーションの起動の情報を伝えられる場合の処理のフロー）図１６は、第一カードマネージャ１４０２の動作を例示するフローチャートであり、このフローチャートにおいて、「アプリケーションが選択された回数」をアプリケーションが起動された回数としている。ステップＳ１６０１において、他のカードマネージャよりアプリケーションを起動したことが受け付けられるまで待つことを行なう。他のカードマネージャよりアプリケーションを起動したことを受け付けると、ステップＳ１６０２へ移行し、カウンター手段１４０６のカウンターを１上げる。ステップＳ１６０２において、カウントを終了すべきか、あるいは、第一カードマネージャ１４０２の動作が終了すべきなのかどうかを判断し、もし、終了していなければステップＳ１６０１へ戻る。
【０１３７】
また、第一カードマネージャ１４０２がアプリケーションを起動した場合には、カウンター手段１４０６のカウンターを１上げることを行なう。
【０１３８】
（実施形態６：第一カードマネージャ以外の処理フロー）図１５は、第一カードマネージャ以外のカードマネージャ（例えば第二カードマネージャ（以下、「他のカードマネージャ」という）の動作を例示するフローチャートである。
【０１３９】
ステップＳ１５０１において、カードマネージャはアプリケーションを起動する。
【０１４０】
ステップＳ１５０２において、第一カードマネージャ１４０２にアプリケーションを起動したことを伝える。なお、第一カードマネージャが他のカードマネージャからの伝達なしに、他のカードマネージャでのアプリケーションの起動を知ることができる場合、例えば、特権ＡＰＩよりアプリケーションが起動されたことが第一カードマネージャ１４０２に通知されるような場合には、第二カードマネージャが第一カードマネージャにこれを伝達する操作を行なう必要はない。
【０１４１】
このような動作を第一カードマネージャ１４０２と第二カードマネージャとで行なうことにより、第一カードマネージャ１４０２のカウンター手段１４０６には、第一カードマネージャ１４０２自身が直接的に管理するアプリケーションや、孫アプリケーションを含むアプリケーションが選択された回数がカウントされる。
【０１４２】
（実施形態６：第二カードマネージャのみがカウンター手段を持つ形態）また、既に述べたように、第一カードマネージャ１４０２がカウンター手段１４０６を持たず、第二カードマネージャ１４０３がカウンター手段を持つ形態もある。このような形態においては、図１５のフローチャートの処理を第二カードマネージャ以外のカードマネージャで行なう（ただし、ステップＳ１５０２において、「第一カードマネージャ」を「第二カードマネージャ」と読み替えるものとする）。また、図１６のフローチャートの処理を第二カードマネージャで行なうようにすればよい。また、第二カードマネージャがアプリケーションを起動したときは、カウンター手段のカウンターを１上げることを行なう。
【０１４３】
（実施形態６：第一カードマネージャと第二カードマネージャの両方がカウンター手段を持つ形態）また、第一カードマネージャ１４０２と第二カードマネージャ１４０３の両方がカウンター手段を持つようになっていてもよい。
【０１４４】
（実施形態６：第一カードマネージャのカウンター手段のカウントの対象となるアプリケーション）なお、第一カードマネージャ１４０２がカウンター手段を持つ場合において、そのカウンター手段によりカウントされる対象は、ＩＣカード１４００内の全てのアプリケーションが選択された回数であってもよいし、一部のアプリケーションの選択された回数であってもよい。例えば、第一カードアプリケーションの子アプリケーションが選択された回数である場合や、特定の識別子を持つアプリケーションが選択された場合、特定のカードマネージャ（例えば、第二カードマネージャ）によって選択されたアプリケーションである場合や、あるいは、特定のカードマネージャ（例えば第二カードマネージャ）にとっての子アプリケーション、および、その特定のカードマネージャにとっての孫アプリケーションなどを含む子孫のアプリケーションが選択された場合に、カウンターが１上がるようになっていてもよい。
【０１４５】
（実施形態６：第一カードマネージャのカウンター手段のカウントの対象となるアプリケーション）同様に、第二カードマネージャ１４０３がカウンター手段を持つ場合においても、そのカウンター手段によりカウントされる対象は、ＩＣカード１４００内の全てのアプリケーションが選択された回数であってもよいし、一部のアプリケーションの選択された回数であってもよい。
【０１４６】
（実施形態６：第一カードマネージャと第二カードマネージャの両方がカウンター手段を持つ場合のカウント対象）また、第一カードマネージャ１４０２と第二カードマネージャ１４０３の両方がカウンター手段を持つ場合、両者のカウンター手段によりカウントされる対象が、同じであってもよいし、異なっていてもよい。異なっている場合には、カウントされる対象に共通部分があってもよいし、共通部分が無くてもよい。
【０１４７】
（実施形態６：カウント対象の共通部分が無い場合の例）カウントされる対象に共通部分が無い例としては、第一カードマネージャ１４０２は、自身（第一カードマネージャ１４０２）が直接的に管理するアプリケーション（例えば子アプリケーションが該当する。なお、孫アプリケーションを第一カードマネージャが直接的に管理する場合には、孫アプリケーションが該当する。）が選択された回数をカウントする。一方、第二カードマネージャ１４０３のカウンター手段は、第二カードマネージャ１４０３にとっての子アプリケーションや第二カードマネージャ１４０３が直接管理するアプリケーション、および、第二カードマネージャにとっての孫アプリケーションなどを含む子孫のアプリケーションが選択された回数（以下、「第二カードマネージャ１４０３の子孫選択回数」という）をカウントするようになっていてもよい。
【０１４８】
（実施形態６：第二カードマネージャの特権により第一カードマネージャにカウントさせない）また、第二カードマネージャ１４０３は、第二カードマネージャ１４０３の子孫選択回数を第一カードマネージャ１４０２のカウンター手段にカウントさせない特権を有するようにしたりもできる。また、第一カードマネージャ１４０２のカウンター手段に第二カードマネージャ１４０３の子孫選択回数をカウントさせることができるかどうかを選択することができるようにすることもできる。
【０１４９】
（実施形態６：第一カードマネージャ、第二カードマネージャ以外のカードマネージャがカウンター手段を持っていてよい）また、第一カードマネージャ、第二カードマネージャ以外にも、第二カードマネージャがダウンロードした第三カードマネージャなどもカウンター手段を有するようにしてもよい。
【０１５０】
（実施形態６：改札などでの応用例と効果の簡単な説明）このような実施形態により、アプリケーションが選択された回数を管理することが可能となり、選択された回数に応じた課金が可能となる。例えば、改札を通過するごとに起動されるアプリケーションの起動回数をカウントすることが可能となり、料金が定額制の場合には、支払うべき料金を求めることができる。また、アプリケーションの保守料金やサポート料金をアプリケーションの選択された回数に応じて課すことが可能となり、適正な保守料金やサポート料金を設定することができる。また、このようにアプリケーションが選択された回数をカウントするアプリケーションをダウンロードできるようにすることにより、例えば、特定のアプリケーションが選択された回数をカウントし、あるいは、カウントされた回数を特定のサーバに送信することができるアプリケーションをダウンロードすることができ、カウントの対象や、カウントの結果の扱いをＩＣカードの発行後に変更できることになる。
【０１５１】
（実施形態７）次に、第一カードマネージャによってダウンロードされた子アプリケーションがさらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションである場合に、第一カードマネージャは、自身が直接的に管理するアプリケーション及び、孫アプリケーションを含むアプリケーションの処理ログを管理する処理ログ管理手段を有し、第二カードマネージャは、第一カードマネージャが直接的に管理するアプリケーション又は／及び、孫アプリケーションを含むアプリケーションの処理ログを管理する処理ログ管理手段を有するＩＣカードについて説明する（主に請求項５関連）。
【０１５２】
（実施形態７：構成）図１７は、本発明の実施形態７に関するＩＣカードの機能ブロック図を示す。本実施形態においては、カードマネージャがアプリケーションのログを記録する処理ログ管理手段を有する。
【０１５３】
この処理ログ管理手段によりアプリケーションの処理ログを管理することができ、例えば、課金処理ができるようになる。
【０１５４】
図１７において、ＩＣカード１７００は、ＲＯＭ１７０１を有し、ＲＯＭ１７０１は、第一カードマネージャ１７０２を備えている。
【０１５５】
第一カードマネージャ１７０２によってダウンロードされた子アプリケーション１７０３がさらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションであるとする。
【０１５６】
図１４において、符号１４０４を付したＡＰ・１は、第二カードマネージャによってダウンロードされたアプリケーションであり、第一カードマネージャ１４０２にとっての孫アプリケーションとなる。
【０１５７】
「第一カードマネージャ」は、処理ログ管理手段１７０６を備えている。
【０１５８】
「処理ログ管理手段」は、自身が直接的に管理するアプリケーション及び、孫アプリケーションを含むアプリケーションの処理ログを管理する。
【０１５９】
「自身が直接的に管理するアプリケーション」とは、第一カードマネージャ１７０２により起動され、第一カードマネージャ１７０２の支配下にあるアプリケーションである。このようなアプリケーションは、図１７においては、符号として１７０３、１７０５が付されたアプリケーションである。
【０１６０】
「孫アプリケーションを含むアプリケーション」とは、第一カードマネージャによりダウンロードされた特権アプリケーションが有するカードマネージャによりダウンロードされたアプリケーション（つまり孫アプリケーション）、及び、その孫アプリケーションが特権アプリケーション（孫特権アプリケーションと呼ぶことにする）である場合に、その孫特権アプリケーションによりさらにダウンロードされたアプリケーションなどのように、第二カードマネージャの直接的、および間接的な支配が及ぶアプリケーションの全てである。
【０１６１】
「アプリケーションの処理ログ」とは、アプリケーションの処理により発生するログである。アプリケーションの特定の関数が呼ばれると、その関数が呼ばれたことを示す記録が例として挙げられる。また、関数にどのような引数が渡されたかを示す記録なども挙げることができる。
【０１６２】
「処理ログを管理する」とは、処理ログを最新の状態に更新し、後で読み出し可能なようにＩＣカード１７００内に格納することである。
【０１６３】
「第二カードマネージャ」（本実施形態におけるもの）は、第一カードマネージャが直接的に管理するアプリケーション又は／及び、孫アプリケーションを含むアプリケーションの処理ログを管理する処理ログ管理手段１７０７を有する。
【０１６４】
（実施形態７：アプリケーションが処理ログを出力する方法）ＩＣカード内で動作するアプリケーションが、処理ログ管理手段１７０６、処理ログ管理手段１７０７、に処理ログを出力する方法の一例としては、ＩＣカード１７００内に処理ログ管理手段を持ったカードマネージャを登録する手段を用意しておき、また、ＲＯＭ１７０１内の一般ＡＰＩとして、処理ログを受け付ける関数（あるいは、メソッド）を用意しておき、その関数（あるいはメソッド）は、受け付けた処理ログを登録されたカードマネージャに出力するようにしておくことが挙げられる。
【０１６５】
また、処理ログをその関数（あるいはメソッド）に受け付けさせたアプリケーションとカードマネージャとの関係が登録できるようにしておくことにより、特定のアプリケーションの処理ログは、特定のカードマネージャの処理ログ管理手段により管理されるようにすることができる。
【０１６６】
（実施形態７：改札などでの応用例と効果の簡単な説明）このような実施形態により、アプリケーションの処理ログを管理することが可能となり、例えば、処理ログの内容に応じた課金が可能となる。例えば、改札を通過するごとに、どの駅の改札機で入場したか、どの駅の改札機で出場したかを記録することができ、支払うべき料金を求めることができる。また、アプリケーションの保守料金やサポート料金をアプリケーションの処理ログの内容に応じて課すことが可能となり、高度な処理を行なう場合には、高い料金を徴収し、高度でない処理に対しては、低い料金を徴収することにすれば、適正な保守料金やサポート料金を設定することができる。また、このようにアプリケーション処理ログを管理するアプリケーションをダウンロードできるようにすることにより、例えば、特定のアプリケーションの処理ログを管理することや、あるいは、処理ログを特定のサーバに送信することができるアプリケーションをダウンロードすることができ、処理ログを管理する対象や、処理ログの扱いをＩＣカードの発行後に変更できることになる。
【０１６７】
【発明の効果】
以上のように、本発明によれば、ＩＣカードの発行後にも特権を持ったアプリケーションをダウンロードすることができるカードマネージャを有することにより、特権がないと取得できない情報を取得して動作するアプリケーションをＩＣカードに導入することが可能となる。
【０１６８】
また、ＩＣカードの発行後に、別の仕様を持つカードマネージャが提案されても、その仕様を持つカードマネージャを、特権を持ったアプリケーションとして、本発明のＩＣカードにダウンロードすることができるので、ＩＣカードの発行者にとって、新たなＩＣカードの発行の手間をかける必要が無くなる。また、ＩＣカードの利用者にとっても、複数枚のＩＣカードを持つ必要が無くなる。
【０１６９】
また、特権ＡＰＩにアクセスが行なわれる際には、アクセスを行なったアプリケーションが特権操作を許可されたアプリケーションであるかどうかの確認が行なわれるので、不正な動作をするアプリケーションによる特権操作を防止することができ、機密情報などの安全性が保たれる。
【０１７０】
また、アプリケーションの選択のカウントやアプリケーションの処理ログを管理することができるので、適正な課金処理などを行なうことができる。
【図面の簡単な説明】
【図１】実施形態１におけるＩＣカードの機能ブロック図
【図２】実施形態１においてダウンロードされた特権アプリケーションがカードマネージャを有する場合のＩＣカードの機能ブロック図
【図３】実施形態２におけるＩＣカードの機能ブロック図
【図４】アプリケーション本体と署名との関係を示す図
【図５】アプリケーションが特権を有するかどうかを判断するために使用される表の一例図
【図６】特権ＡＰ制御手段を用いてアプリケーションの特権を許可するかどうかを決定する処理のフローチャート
【図７】実施形態３におけるＩＣカードの機能ブロック図
【図８】実施形態３における第一カードマネージャの動作を説明するフローチャート
【図９】実施形態４におけるＩＣカードの機能ブロック図
【図１０】特権アプリケーションごとに利用可能な関数を関連付けた表の一例図
【図１１】実施形態５におけるＩＣカードの機能ブロック図
【図１２】アプリケーションのスタックの内容の一例図
【図１３】アプリケーションが特権ＡＰＩを利用するためのメッセージの流れを示す一例図
【図１４】実施形態６におけるＩＣカードの機能ブロック図
【図１５】第二カードマネージャの動作を説明するフローチャート
【図１６】第一カードマネージャの動作を説明するフローチャート
【図１７】実施形態７におけるＩＣカードの機能ブロック図
【図１８】ＩＣカードのハードウェア構成の一例図
【図１９】従来のＩＣカードにおけるアプリケーションの関係を示す図
【符号の説明】
１００ＩＣカード
１０１ＲＯＭ
１０２第一カードマネージャ
１０３特権アプリケーション
１０４ＡＰ・１
１０５ＡＰ・２
１０６特権ＡＰＩ
１０７一般ＡＰＩ

Claims

他のアプリケーションを制御する権限である特権を有するアプリケーションである特権アプリケーションをダウンロードすることができる第一カードマネージャと、
前記第一カードマネージャによりダウンロードされた特権アプリケーションであって、さらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションである子アプリケーションと、
を有し、
前記第二カードマネージャは、前記第一カードマネージャからの孫アプリケーションのライフサイクルの変更、削除を禁止することが可能であるＩＣカード。
他のアプリケーションを制御する権限である特権を有するアプリケーションである特権アプリケーションをダウンロードすることができる第一カードマネージャと、
前記第一カードマネージャによってダウンロードされた特権アプリケーションであって、さらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションである子アプリケーションと、
を有し、
前記第二カードマネージャは、前記第一カードマネージャがダウンロードしたアプリケーションのライフサイクルの変更、削除をすることが可能であるＩＣカード。
他のアプリケーションを制御する権限である特権を有するアプリケーションである特権アプリケーションをダウンロードすることができる第一カードマネージャと、
前記第一カードマネージャによってダウンロードされた特権アプリケーションであって、さらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する特権アプリケーションである子アプリケーションと、
を有し、
さらに、前記第一カードマネージャの有する特権と、前記第二カードマネージャの有する特権との優越性を選択することができる選択手段を有するＩＣカード。
他のアプリケーションを制御する権限である特権を有するアプリケーションである特権アプリケーションをダウンロードすることができる第一カードマネージャと、
前記第一カードマネージャによってダウンロードされた特権アプリケーションであって、さらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する子アプリケーションと、
を有し、
さらに、前記第一カードマネージャ又は／及び、前記第二カードマネージャは、前記孫アプリケーションを含むアプリケーションが選択された回数をカウントするカウンター手段を有するＩＣカード。
他のアプリケーションを制御する権限である特権を有するアプリケーションである特権アプリケーションをダウンロードすることができる第一カードマネージャと、
前記第一カードマネージャによってダウンロードされた特権アプリケーションであって、さらに孫アプリケーションをダウンロードすることができる第二カードマネージャを有する子アプリケーションと、
を有し、
前記第一カードマネージャは、自身が直接的に管理するアプリケーション及び、孫アプリケーションを含むアプリケーションの処理ログを管理する処理ログ管理手段を有し、
前記第二カードマネージャは、第一カードマネージャが直接的に管理するアプリケーション又は／及び、孫アプリケーションを含むアプリケーションの処理ログを管理する処理ログ管理手段を有するＩＣカード。