(57)【特許請求の範囲】
【請求項１】
公開鍵および秘密鍵の対を生成する証明機関と、
少なくとも１つの集積回路カードであって、該少なくとも１つの集積回路カードのそれぞれは、製造時において、該証明機関の該公開鍵と該少なくとも１つの集積回路カードのそれぞれを一意に識別するためのカード識別子とを含み、該少なくとも１つの集積回路カードに含まれる該証明機関の該公開鍵は、該少なくとも１つの集積回路カードが該証明機関の該秘密鍵を用いて署名されたデータをベリファイすることを可能にする、少なくとも１つの集積回路カードと、
該証明機関に設けられた手段であって、該少なくとも１つの集積回路カードのそれぞれに対応する該カード識別子に対して一意であるデータブロックを作成し、該データブロックをビューローに送る手段と、
該ビューローに設けられた手段であって、該データブロックに対応するカード識別子を有する該少なくとも１つの集積回路カードに該データブロックをロードする手段と、
該少なくとも１つの集積回路カードのうちの１つに設けられた手段であって、少なくとも該データブロックと特定のアプリケーションの許可プロフィールとの対応に基づいて、該少なくとも１つの集積回路カードのうちの１つが該特定のアプリケーションをロードすることを受け入れる資格を有するか否かを決定する手段と、
該少なくとも１つの集積回路カードのうちの該１つに設けられた手段であって、該手段は、該特定のアプリケーションを該カードにロードするために、該特定のアプリケーションに対するアプリケーションロード証明を認証し、該アプリケーションロード証明は署名を有し、該アプリケーションロード証明を認証することは、該証明機関の該公開鍵と該アプリケーションロード証明の該署名との間の対応をチェックすることによって、該特定のアプリケーションに対する該アプリケーションロード証明の該署名が該証明機関によって署名されたか否かをチェックすることによって行われる、手段と、
該ビューローに設けられたロード手段であって、該ロード手段は、該特定のアプリケーションを安全に該カードにロードし、該ロード手段は、該決定する手段および該認証する手段に応答する、ロード手段と
を有し、
該証明機関は、該少なくとも１つの集積回路カードへの情報の転送を証明する機関である、マルチアプリケーションカードシステム。
【請求項２】
前記ビューローに設けられた手段であって、前記少なくとも１つの集積回路カード上にアプリケーションが安全にロードされることを可能にする手段をさらに有する、請求項１に記載のマルチアプリケーションカードシステム。
【請求項３】
前記少なくとも１つの集積回路カードは、前記決定する手段と前記認証する手段と前記ロード手段に命令するオペレーティングシステムを格納するためのメモリ手段をさらに有する、請求項１または請求項２に記載のマルチアプリケーションカードシステム。
【請求項４】
前記少なくとも１つの集積回路カードは、各集積回路カードの機密性を実現するための各集積回路カードに対して一意であるカードイネーブル鍵をさらに含み、１つの集積回路カードに対して実現される機密性は、その他の任意の集積回路カードに対して実現される機密性とは異なっている、請求項１から３のうちのいずれかに記載のマルチアプリケーションカードシステム。
【請求項５】
前記少なくとも１つの集積回路カード上にアプリケーションが安全にロードされることを可能にする手段は、前記カード識別子のリストを作成する手段と、該リストを前記証明機関に送る手段とを有する、請求項２あるいは請求項２に従属するいずれかの請求項に記載のマルチアプリケーションカードシステム。
【請求項６】
前記データブロックは、カードデータと、前記少なくとも１つの集積回路カードのそれぞれに対して一意であるカード公開鍵およびカード秘密鍵の対とを含み、該カード公開鍵および該カード秘密鍵の対は、前記証明機関の前記公開鍵および前記秘密鍵の対とは異なっている、請求項１から５のうちのいずれかに記載のマルチアプリケーションカードシステム。
【請求項７】
前記少なくとも１つの集積回路カードに設けられたチェック手段であって、前記カードイネーブルビットが設定されているか否かをチェックするチェック手段をさらに有し、前記データブロックをロードする手段は、該カードイネーブルビットが設定されていない場合にのみ該ブロックをロードし、該カードイネーブルビットは、該データブロックをロードした際に該少なくとも１つの集積回路カードにおいて設定される、請求項４あるいは請求項４に従属するいずれかの請求項に記載のマルチアプリケーションカードシステム。
【請求項８】
１以上の集積回路カードであって、該１以上の集積回路カードのそれぞれは、製造時において、対応する秘密鍵を保持する証明機関からの任意のメッセージの源を認証するための公開鍵と、各集積回路カードの機密性を実現するための各集積回路カードに対して一意であるカードイネーブル鍵と、各集積回路カードを一意に識別するためのカード識別子と、オペレーティングシステムを格納するためのメモリとを含み、該１以上の集積回路カードに含まれる該証明機関の該公開鍵は、該１以上の集積回路カードが該証明機関の該秘密鍵を用いて署名されたデータをベリファイすることを可能にする、１以上の集積回路カードと、
ビューローに設けられた手段であって、該手段は、該１以上の集積回路カード上にアプリケーションが安全にロードされることを可能にし、該手段は、該カード識別子のリストを作成する手段と、該リストを該証明機関に送る手段とを含む、手段と、
該証明機関に設けられた手段であって、該手段は、該証明機関に送られた各カード識別子に対してデータブロックを作成し、該データブロックを該ビューローに送り、該データブロックは、該１以上の集積回路カードのそれぞれについてカードデータとカード公開鍵およびカード秘密鍵の対とを含み、該カード公開鍵および該カード秘密鍵の対は、該証明機関の該公開鍵および該秘密鍵とはそれぞれ異なるカード公開鍵およびカード秘密鍵を含む、手段と、
該１以上の集積回路カードに設けられた手段であって、該カードイネーブルビットが設定されているか否かをチェックし、設定されていなければ、該カード識別子を該データブロックとリンクし、該データブロックをそのリンクした対応する集積回路カードにロードし、該１以上の集積回路カードに該カードイネーブルビットを設定する手段と、
該１以上の集積回路カードのうちの１つの集積回路カードに設けられた手段であって、少なくとも該データブロックと特定のアプリケーションに対する許可プロフィールとの間の対応に基づいて、該１つの集積回路カードが該特定のアプリケーションをロードすることを受け入れる資格を有するか否かを決定する手段と、
該１つの集積回路カードに設けられたチェック手段であって、該チェック手段は、該１つの集積回路カードにロードされるべき該特定のアプリケーションに対するアプリケーションロード証明を認証し、該アプリケーションロード証明は、署名を有し、該アプリケーションロード証明を認証することは、該証明機関の該公開鍵と該アプリケーションロード証明の該署名との間の対応をチェックすることによって、該特定のアプリケーションに対する該アプリケーションロード証明の該署名が該証明機関によって署名されたか否かをチェックすることによって行われる、チェック手段と、
該決定する手段およびチェック手段に応答して、該特定のアプリケーションをロードする手段と
を有するマルチアプリケーションカードシステム。
【請求項９】
１以上のアプリケーションを集積回路カードにロードする方法であって、該集積回路カードは、製造手段によって製造され、該製造手段が、証明機関の公開鍵を含むセキュリティデータを集積回路カードに送信し、該証明機関に設けられた手段が、該集積回路カードに対するデータブロックを作成し、該データブロックをビューローに送り、該ビューローに設けられた手段が、該データブロックを該集積回路カードにロードし、
該方法は、
該集積回路カードに設けられた手段が、少なくとも該データブロックと特定のアプリケーションに対する許可プロフィールとの間の対応に基づいて、該集積回路カードが該特定のアプリケーションをロードすることを受け入れる資格を有するか否かを決定するステップと、
該集積回路カードに設けられた手段が、該特定のアプリケーションを該集積回路カードにロードするためのアプリケーションロード証明を認証するステップであって、該アプリケーションロード証明は、署名を有し、該アプリケーションロード証明を認証することは、該公開鍵と該アプリケーションロード証明の該署名との間の対応をチェックすることによって、該特定のアプリケーションに対する該アプリケーションロード証明の該署名が該証明機関によって署名されたか否かをチェックすることによって行われる、ステップと、
該ビューローに設けられたロード手段が、該集積回路カードが資格を有し、かつ、該特定のアプリケーションが認証された場合に、該特定のアプリケーションをロードするステップと
を包含し、
該証明機関は、該集積回路カードへの情報の転送を証明する機関である、方法。
【請求項１０】
集積回路カードから１以上のアプリケーションを削除する方法であって、該集積回路カードは、製造手段によって製造され、該製造手段が、証明機関の公開鍵を含むセキュリティデータを集積回路カードに送信し、該証明機関における手段が、該集積回路カードに対するデータブロックを作成し、該データブロックをビューローに送り、該ビューローにおける手段が、該データブロックを該集積回路カードにロードし、
該方法は、
該集積回路カードにおける手段が、少なくとも該データブロックと特定のアプリケーションに対する許可プロフィールとの間の対応に基づいて、該集積回路カードが該特定のアプリケーションを削除することを受け入れる資格を有するか否かを決定するステップと、
該ビューローにおける削除手段が、該集積回路カードが資格を有する場合に、該特定のアプリケーションを削除するステップと
を包含し、
該証明機関の公開鍵は、該集積回路カードに転送されロードされるべきデータブロックが該証明機関の秘密鍵によって署名されているか否かを決定するために用いられ、該データブロックが該証明機関の秘密鍵によって署名されていることは、該データブロックがロードされることが該証明機関によって許可されていることを示し、該データブロックが該証明機関の秘密鍵によって署名されているか否かを決定することによって、該集積回路カードへの転送およびロードのために該データブロックが認証されているか否かが決定される、方法。
【発明の詳細な説明】
発明の背景
集積回路（「ＩＣ」）カードは、今日世界中で、多くの異なる目的のためにますます多く使用されている。ＩＣカード（スマートカードとも呼ばれる）は、典型的に、従来のクレジットカードの大きさであり、コンピュータチップを有している。このコンピュータチップには、マイクロプロセッサ、リードオンリーメモリ（ＲＯＭ）、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、入力／出力（Ｉ／Ｏ）メカニズム、および、動作中にマイクロプロセッサをサポートするその他の回路が含まれている。ＩＣカードは、そのメモリ内に、単一のアプリケーションを有していてもよいし、あるいは、複数の独立したアプリケーションを有していてもよい。ＭＵＬＴＯＳTMは、他のプラットフォームの中でもとりわけＩＣカード上で動作し、そのカード上で複数のアプリケーションの実行を可能にするマルチアプリケーションオペレーティングシステムである。これにより、カードユーザは、そのカードを使用するために挿入した端末（即ち、ＡＴＭ、電話および／またはＰＯＳ）の種類に関わらず、そのカードに保存された多数のプログラム（例えば、クレジット／デビット、電子マネー／財布、および／またはロイヤリティアプリケーション）を実行することができるようになる。
テレフォンカードおよび電子キャッシュカードのような従来の単一アプリケーションＩＣカードは、パーソナル化の段階で単一アプリケーションがロードされる。しかし、たとえカードユーザまたはカード発行者がアプリケーションの改変を望んだとしても、カード発行後にアプリケーションを改変または変更することはできない。さらに、あるカードユーザが、そのユーザに対して発行されたＩＣカードに、様々なアプリケーション機能、例えば、電子財布およびクレジット／デビット機能の両方を果たして欲しい場合、カードユーザは複数の物理的カードを持ち運ばなければならない。これは、非常に煩雑で不便である。アプリケーション開発者（application developer）またはカードユーザが、２つの異なるアプリケーション間での相互作用またはデータ交換、例えば、財布機能がフリークエントフライヤーロイヤリティアプリケーションと相互作用することを望んだ場合、カードユーザは、カードを入れる端末に複数のカードを代わる代わる出し入れしなければならず、処理が、困難で、時間がかかり、不便なものになる。
従って、同じＩＣカード上に複数アプリケーションを保存することは有益である。例えば、カードユーザは、同じカード上に財布アプリケーションおよびクレジット／デビットアプリケーションの両方を有し、買物を行うときにどちらの種類の支払い（電子キャッシュまたはクリジットカード）を使用するのかを選択し得る。十分なメモリが存在し、且つ、複数のアプリケーションをサポートできるオペレーティングシステムがカード上にあれば、１枚のＩＣカードに複数のアプリケーションを付与することができる。複数のアプリケーションを予め選択して、それらを製造段階でカードのメモリ内に入れておくことも可能であるが、必要に応じて、製造後に、そのカードのアプリケーションをロードおよび削除できるようにすることも有益であろう。
１枚のカード上に複数のアプリケーションを保存する向上した柔軟性および性能は、個々のカードとアプリケーション提供者との間で交換され、また、アプリケーションをロードおよび削除する際に全システム内で交換される情報（アプリケーションコードおよび関連するデータを含む）の完全性および安全性に関して克服すべき新たな技術的課題を生み出す。カード、カード発行者、システムオペレータおよびアプリケーション提供者間で安全にデータを交換できる能力、ならびに、ローカル端末から、または、電話線、インターネット、イントラネット接続、もしくはその他のデータ経路上で遠隔的に、何時でも安全にアプリケーションをロードおよび削除できる能力をＩＣカードシステム内に持つことは有益であろう。典型的にこれらのデータ送信線は安全な線ではないので、これらの送信線上で送られるアプリケーションが意図したカード上にのみロードされることを確実にするためには、複数のセキュリティおよびエンティティ認証技術を確立しなければならない。
特に、カード所有者が利用できる新たなアプリケーションが増え続けている状況では、上記のように、発行後にＩＣカード上にアプリケーションを追加する能力をシステムに持たせることが重要である。このことは、ＩＣカードの寿命の長さを守るために必要である。さもなくば、アプリケーションが古くなったときに、そのカードが無用になってしまう。この点に関して、ＩＣカードへの不適切な、または不要なアプリケーションのローディングに対する保護のために、システム内のＩＣカードにとってアプリケーションが「選択的に使用可能」となるように、ローディングプロセスを制御し、かつ（必要もしくは所望の場合に）限られた群または数のカードに対して所定のアプリケーションの使用を制限する性能を有することはＩＣカードシステムにとって有益である。この「選択能力」は、例えば、カードのライフサイクル中の所望の時点において、アプリケーションのローディングおよび消去を可能にする。またそのことにより、選択されたアプリケーションを受け取るように選ばれたカードのみにアプリケーションのローディングを可能にもする。
従って、本発明の実施形態の１つの目的は、これらの重要な特徴、および特にスマートカードアプリケーションの選択能力（これはＩＣカード上にロードされ得る）を可能にする、改善されたセキュリティを有するＩＣカードシステムを提供することである。
発明の要旨
本発明による実施形態により、これらの、および他の目的が達成される。これらの実施形態は、少なくとも１つの集積回路カードを備え、そして証明機関およびパーソナル化機関（personalization bureau）を有するＩＣカードシステムを提供する。証明機関（“ＣＡ”）は、全システム用の暗号鍵および復号鍵を維持し、カード製造者に、製造時においてカード上に配置されるセキュリティデータを提供する。従って、安全なマルチアプリケーションカードシステムが提供されるという利点を有する。
詳細には、好ましい実施形態において、ＩＣカードはＣＡの公開鍵、およびそれぞれのカードを独自に識別するためのカード識別子が製造時に注入される。製造後、好ましくはカードは、カード発行者であり得るパーソナル化機関（“ＰＢ”）へ、カードをイネーブルするために提供される。ＰＢは、カードから識別子を取得し、カード識別子のリストをＣＡへ転送する。
ＣＡ自体は、パーソナル化データブロックを各カード識別子用に作製する。各データブロックは好ましくは、カードパーソナル化データおよび個別の鍵セットを含む。データブロックは、暗号化され、そしてＰＢへ返送される。カード識別子を使用することにより、ＰＢはその後、カードを暗号化されたデータブロックカードと照合させ、各データブロックを一致したカードへ別々にロードし、そして好ましくは、カードがイネーブルされて、アプリケーションローディングの準備ができたことを表示するイネーブル化ビットを設定する。
アプリケーションローディングプロセスは、好ましくはＰＢにおいて行われる。初めに、システムはロードされるカードが特定のアプリケーションのローディングを受け入れる資格（後に説明するように）があるか否かをチェックする。アプリケーションローダは、端末を介してカードに資格があるかを知らされ、そして資格がある場合、ＣＡの公開鍵を用いて、ロードされようとするアプリケーションがＣＡの秘密鍵（ロードされようとするアプリケーションがＣＡにより認められているかを表示する）により署名されているか否かを決定するチェックが行われる。
【図面の簡単な説明】
本発明による実施形態のさらなる目的、特徴および利点は、本発明の例示的な実施形態を示す添付の図面と合わせて、ただ例として挙げられる、以下の詳細な説明から明らかとなる。
図１は、安全システムにおけるマルチアプリケーションＩＣのライフタイムの３段階を示すブロック図であり、
図２は、カード製造プロセスの工程を示すブロック図であり、
図３は、安全システムにおける各ＩＣカードをイネーブル化に関わる工程を示すフローチャートであり、
図４は、本発明に従って使用され得るＩＣカードチップのブロック図であり、
図５は、図３のブロック３０７において表示されるように、ＩＣカード上に記憶されたデータを示すブロック図であり、
図５Ａは、ＩＣカード上に常駐し、そしてパーソナル化データを表すデータ構造の模式図であり、
図６は、安全システムにおいてＩＣカードにアプリケーションをロードする工程を示すフローチャートであり、
図７は、図６のブロック６０１において示されるようなチェック工程を示すフローチャートであり、
図８は、アプリケーションのローディングを進めてもよいかを決定する際に行われる工程を示すフローチャートであり、
図９は、安全マルチアプリケーションＩＣカードシステムにおいて、ＩＣカードのイネーブル化プロセスのためのシステムアーキテクチャの構成要素を示すブロック図であり、
図１０は、パーソナル化された後のＩＣカードの使用に関るエンティティのシステム図である。
そうでないことが記載されている場合を除き、全図面を通して、同じ参照番号および文字は、例示された各実施形態において同じ特徴部、部材、構成要素および部分を示すために用いられている。さらに、以下で図面を参照しながら本発明を説明するが、これは例示的な実施形態に関する説明である。添付の特許請求の範囲によって規定される本発明の真の範囲および趣旨から逸脱することなく、記載された実施形態に変更および改変を加えることが可能であることが意図されている。
発明の詳細な説明
本発明による実施形態は、ＩＣカードシステムおよびプロセスを提供し、これらは、マルチアプリケーションＩＣカードのライフタイムの間、カードユーザ、カード発行者および／またはアプリケーション開発者のニーズまたは要望に合わせて、選択されたアプリケーションをロードし、消去することができる柔軟性を可能にする。このようなカードを有するカードユーザは、カード発行者ならびにシステムオペレータまたは証明機関（“ＣＡ”）に許可された場合、所望に応じてアプリケーションを選択的にロードし、消去し得る。証明機関（“ＣＡ”）は、ローディングおよび消去プロセスを、そのプロセスに関する情報の転送を認証することにより制御する。
アプリケーションが選択的にカードからロードおよび消去されることを可能にすることにより、カード発行者は、新たなカードを発行することなくさらなる機能性を個々のＩＣカード上に拡張し得る。さらに、アプリケーション開発者は、古いアプリケーションを新しく強化したバージョンと置換できる。そして共通の複数のアプリケーションオペレーティングシステムを用いて同じカード上に常駐しているアプリケーションは、安全な方法で相互作用し得、データを交換し得る。例えば、お得意乗客（frequent flyer）ロイヤリティプログラムは、Mondex預金にて、またはクレジット／デビットアプリケーションにて支払った１ドル毎に、１お得意乗客マイルをカードユーザの内部アカウントに自動的にクレジットし得る。選択的にアプリケーションをロードおよび消去し得る性能により、カードユーザはまた（カード発行者の要求によるが）、所望に応じてロイヤリティプログラム変更のオプションをも有する。
カード発行者またはアプリケーション開発者は、特定のアプリケーションが、カードシステム中のある特定のカードユーザ用の１つのカード上にのみロードされることを意図することがある。ある地域の銀行は、独自のアプリケーションがその銀行が発行したカード上にのみ常駐することを望むことがある。本発明の実施形態は、この選択的ローディングを可能にし、そして特に、他者から発行された権限のないカード上への独自のアプリケーションのローディングを阻止することを可能にする。
これらの所望の目的を達成するために、本発明による実施形態は、カード上に「カードパーソナル化データ」を記憶することにより、各カードに特定のアイデンティティを与える。さらに、システム内の１枚以上のカード上にロードまたは消去される各アプリケーションは、アプリケーションがロードされ得るカードを特定する「アプリケーション許可データ」が割り当てられる。
パーソナル化データのタイプは、カードシステムのニーズおよび要求によって多様化し得る。以下でより詳細に説明する好ましい実施形態において、パーソナル化データはユニークなカード識別指定データと、カード発行者と、製品クラスもしくはタイプ（これはカード発行者により規定される）と、パーソナル化の日付とを含む。しかし、これらのデータ要素の全てが、使用のために要求されるわけではなく、またさらなる要素も含まれ得る。
アプリケーションに関連したアプリケーション許可データ（やはり詳細に後述）は、アイデンティティフィールド内の単一の値であり得、あるいはそのアイデンティティフィールド内において複数の値を含み得る。例えば、カード発行者フィールド内のアプリケーション許可データは、所定のバンクＸからの製品クラスＡおよびＢの両方を表すことにより、アプリケーションが、バンクＸから発行された製品クラスＡおよびＢとして指定されたカード上にロードされ得ることを（カードのパーソナル化データのカード製品ＩＤフィールド内の表示に従って）示し得る。
加えて、「グローバル値」を、アプリケーション許可データの発行者フィールド（または他のフィールド）に記憶することにより、このアプリケーション許可データは誰がそのカードを発行したかに関わらず、システム内の全てのＩＣカードがこの許可フィールドに一致することを示し得る。例えば、この場合、アプリケーション許可カード発行フィールドにおいて記憶されたゼロのデータ値は、カードのパーソナル化カード発行フィールドの全てと一致する。
図１は、安全システム内の機能的なマルチアプリケーションＩＣカードを提供する際の３つの工程を示す。第１の工程は、カード製造工程１０１である。第２の工程は、カードパーソナル化データ（エンティティ認証データとも呼ばれる）がカード上にロードされるパーソナル化工程１０３である。第３の工程は、カードがアプリケーションを受信する資格があるか否かをチェックする、アプリケーションローディング工程１０５であり、すなわちパーソナル化データが、ロードされるアプリケーションに関するアプリケーション許可データに対してチェックされる。これら３つの工程の各々を以下に詳細に説明する。
カード製造
図２は、安全システムにおけるＩＣカードを製造する際に必要な工程を示す。工程２０１は、シリコン上の集積回路を作製し、それをカード上に配置することにより、物理的なＩＣカードを製造する。集積回路チップは、ＲＡＭ、ＲＯＭおよびＥＥＰＲＯＭメモリを含む。カードが最初に製造されるときに、システムオペレータ（この場合においては、証明機関（ＣＡ）と呼ばれる）のグローバル公開鍵が、工程２０３において各カードのＲＯＭ内に記憶される。このことによりカードは、カードへのあらゆるメッセージのソースはＣＡからのものであることを認証し得る。なぜならカード上の公開鍵がＣＡの秘密鍵に対応するためである。
より詳細には、このカード上に記憶された公開鍵により、個々のカードがＣＡの秘密鍵で署名されたデータを検証し得る。カード上に記憶されているＣＡの公開鍵は、カードに送信されたデータが適切なＣＡ秘密鍵で署名されたか否かを決定するためだけに使用される。このことにより、カードはＣＡから入る任意のメッセージのソースを検証し得る。
工程２０５は、カード内のＥＥＰＲＯＭの機密性部分にカードイネーブル化鍵を挿入し、イネーブル化中のカードの特定の機密性を高め、工程２０７は、カード識別子をカードのＥＥＰＲＯＭに挿入する。任意の端末によりアクセスされ得る識別子は、システムがカードのアイデンティティを後のプロセスにおいて決定することを可能にする。識別子は、自由に使用可能であり、そしてメッセージを認証するために使用されない。
工程２０９は、カード上のＲＯＭにオペレーティングシステムコード（オペレーティングシステムにより呼出しまたはサポートされる任意のプリミティブを含む）を記憶する。プリミティブはネイティブ言語コード（例えば、アセンブリ言語）で書かれ、そしてＲＯＭに記憶される。プリミティブはサブルーチン（オペレーティングシステムにより、あるいは演算機能（乗算もしくは除算）、データ検索、データ操作または暗号化アルゴリズムのような、カード上に常駐しているアプリケーションにより呼び出され得る）である。プリミティブはプロセッサのネイティブ言語で書かれているため、非常に速く実行され得る。ＩＣカードが製造された後、それらはパーソナル化機関（“ＰＢ”）へ送られ、カードのメモリにカードパーソナル化データを記憶することにより、カードをイネーブル化し、パーソナル化する。イネーブル化と、パーソナル化は本明細書中において互換可能に用いられ、カード上にアプリケーションが安全にロードされることを可能にするためにとられる準備工程を示す。個別のカードは、好ましくはバッチにて製造され、そしてパーソナル化機関へ処理用に一群にして送られる。
カードイネーブル化／パーソナル化
図３は、カードがパーソナル化機関に届いた際のカードイネーブル化プロセスの工程を示す。パーソナル化機関は、カード発行者（例えば、銀行もしくは他の金融機関）であり得、またはカード発行者のためにそのサービスを行う第三者であり得る。パーソナル化機関は、カードを特定のユーザまたはユーザクラスに設定する。
図３は、システム内で機能する各ＩＣカードをイネーブル化し、パーソナル化するために行われる工程を詳細に示す。カードはＩＣカードと通信し、カードの識別子データ（これは製造プロセス中に前もってカード上に配置されている−−工程２０７参照）を読み出す端末内に配置され得る。このカード識別データは、工程３０１においてカードから読み出される。端末は、「識別データ取得」コマンドを効果的にカードへ送り、そしてカードは識別データを端末へ返す。
ＰＢは典型的には、一群のカードを同時に処理し、まずその一群のカード用のＩＣカード識別データのリストをコンパイルし、パーソナル化する。次にＰＢは、電子的に（あるいは他の方法で）この識別データのリストを証明機関（“ＣＡ”）へ送信し、証明機関はパーソナル化（またはイネーブル化）データブロックを各カード識別子用に作製する。データブロックは、カードパーソナル化データを含む。カードパーソナル化データは、そのカード用の複数の識別フィールド、および個別の鍵セットとして組織化される（後述）。これらのデータブロックはその後、工程３０２において暗号化され、ＰＢへ送信される。カード識別データの使用により、ＰＢはそのカードを暗号化されたデータブロックと照合し、各データブロックを一致したカード上へ別々にロードする。ＣＡがカードのアイデンティティおよびシステムの完全性を制御することを確実にするために、ＰＢは決して転送されたデータブロックのコンテンツの知識を得ることはない。カード発行者が発行したカードの管理にその発行者の好みを反映させるために、パーソナル化のいくつかの局面が、その発行者からＣＡに要望される。以下のさらなる工程が行われる。
工程３０３は、まずカードのＥＥＰＲＯＭに記憶されたイネーブルビットがすでに設定されているか否かをチェックする。イネーブルビットがすでに設定されている場合、カードはすでに構成され、パーソナル化されており、そしてイネーブル化プロセスは、工程３０４に示されるように終了する。カードは二度とイネーブルおよびパーソナル化され得ない。ビットが設定されていないならば、プロセス工程３０５へ続く。
工程３０５において、イネーブルされているカード用の個別化されたカードの鍵セット（この鍵セットはＣＡにより生成される）は、カード上に記憶される。これらの鍵は、カード外検証（off-card verification）（カードが認証されたカードであることを検証するための）において、後に使用され得る。この検証は、そのカードをアプリケーションが意図されているカードとしてさらに認証するために必要である。
工程３０７は、カード用に４つの異なるMULTOSセキュリティマネージャ（ＭＳＭ）特徴的データ要素（characteristic data element）（本明細書中においては、パーソナル化データとも呼ばれる）を、ＣＡにおいて生成する。これらの要素は、特定のカードからアプリケーションを安全に、かつ正確にロードし、消去するために用いられる。ＭＳＭ特性はまた、識別された特定のクラスのカード上へのアプリケーションのローディングを可能にする。（これらＭＳＭ特性は、図５を参照しながらさらに説明する。）
アドレステーブルまたは追加のサブルーチンのようなシステム設計に必要とされれば、他のデータもまたこの時点でカード上に記憶され得る。
工程３１１は、特定のカードにおけるイネーブル化プロセスが完了したことを示す、カードのＥＥＰＲＯＭ内のイネーブル化ビットを設定する。このビットが設定されるときに、別のイネーブル化プロセスはそのカード上に起こり得ない。このことは、１つのパーソナル化およびイネーブル化プロセスのみがカードに起こり、よってカードの不法な改ざん、もしくは誤作動によるカードの変化を阻止する。好ましい実施形態において、イネーブル化ビットは、カードが製造されるときに初めから設定されるわけではなく、イネーブル化プロセスの最後に設定される。
図４は、すでに製造され、パーソナル化されたＩＣカードチップのブロック図の一例を示す。ＩＣカードチップは、使用されるＩＣカード上に位置する。ＩＣカードは、好ましくは中央処理ユニット４０１、ＲＡＭ４０３、ＥＥＰＲＯＭ４０５、ＲＯＭ４０７、タイマー４０９、制御論理４１１、Ｉ／Ｏポート４１３、およびセキュリティ回路機構４１５を含み、これらは従来のデータバスにより共に接続される。
メモリカード内の制御論理４１１は、入力／出力ポートを介してカードのメモリへの読み出し−書き込みアクセスを取り扱うために十分なシーケンシングおよびスイッチングを提供する。ＣＰＵ４０１はその制御論理を用いて、計算、メモリ位置アクセス、メモリコンテンツ変更、および入力／出力ポート管理を行い得る。いくつかのカードは、暗号化アルゴリズムのような複雑な演算処理を取り扱うコプロセッサを有する。入力／出力ポート４１３は、ＣＰＵおよび制御論理単独の制御のもとで、カードとカード受容デバイスとの間の通信に用いられる。タイマー４０９（これはクロックパルスを生成、または供給する）は、メモリアクセス、メモリ読み出しまたは書き込み、処理、およびデータの通信を達成する工程のシーケンスを通して、制御論理４１１およびＣＰＵ４０１を駆動する。タイマーは、呼出し期間のようなアプリケーションの特徴を提供するために用いられ得る。セキュリティ回路機構４１５は、ヒュージブルリンク（fusible link）を含む。このリンクは、製造中に試験する際に要求される、入力／出力ラインを内部回路機構に接続するものであるが、後からのアクセスを防ぐために試験の完了に伴い破壊（“ブロー”）される。カードに資格を与えるパーソナル化データは、ＥＥＰＲＯＭ４０５中に確保された位置に記憶される。パーソナル化データのアプリケーション許可データとの比較は、ＣＰＵ４０１により行われる。
図５は、４つの要素のカードパーソナル化データを生成し、そしてＩＣカードのメモリ内にロードする工程を示す。図５Ａは、本発明によるパーソナル化データを包含するＩＣカードのメモリ内に常駐する各アイデンティティフィールド用ビットマップの模式図を示す。各アイデンティティフィールド用の各データ構造は、それ自身の解読器コードを有する。工程５０１は、「msm_mcd_permissions_mcd_no」と呼ばれる、アイデンティティフィールド「カードＩＣ」用のデータ構造をロードする。この用語は、ＭＵＬＴＯＳ  ｓｙｓｔｅｍ  ｍａｎａｇｅｒ＿ＭＵＬＴＯＳ  ｃａｒｄ  ｄｅｖｉｃｅ＿ｐｅｒｍｉｓｓｉｏｎｓ＿ＭＵＬＴＯＳ  ｃａｒｄ  ｄｅｖｉｃｅ  ｎｕｍｂｅｒを意味する。この番号は、図５Ａに示すように通常８バイトの長さであるが、データはそのカード用にユニークな番号を表示する任意の長さであり得る。好ましい実施形態において、２バイトが単一のインジケータとして専用化され、２バイトは製造されたときに、どのセキュリティモジュールが、カードが製造されたときにその注入鍵を注入したかを表示するMULTOS注入セキュリティモジュールＩＤ（MISM ID）を備える。そして４バイトは特定のＭＩＳＭにおいて生産された個別のカードを識別する集積回路カード（ＩＣＣ）シリアルナンバーを備える。
工程５０３は、「msm_mcd_permissions_mcd_issuer_id」と呼ばれる、アイデンティティフィールド「発行者ＩＤ」用のデータ構造をロードする。この用語は、MULTOSカードデバイス発行者識別番号を意味する。各カード発行者（例えば、特定の銀行、金融機関、またはアプリケーションに携わる他の企業）は、カードシステムにおいてユニークな番号を割り当てられる。MULTOSシステム内の各ＩＣカードは、カードをパーソナル化したか、もしくはカードに対して責任を有するカード発行者についての情報を含んでいる。カード発行者は、製造者から所定の数のカードを注文し、本明細書中に記載されるようにパーソナル化プロセスを行う（あるいは行わせる）。例えば、ある地域の銀行がその顧客に配布するための5,000枚のカードを注文するかもしれない。これらのカード上の「mcd_issuer_id」データ構造は、どの発行者がそのカードを発行したかを表示する。好ましい実施形態において、データ構造は、システム内における多くの異なる発行者を可能にし、４バイトの長さ（図５Ａの５０３Ａにおいて示すように）であるが、データ構造の長さはカードシステムのニーズにより変更可能である。
工程５０５は、「msm_mcd_permissions_mcd_issuer_product_id」と呼ばれる、アイデンティティフィールド「製品ＩＤ」用のデータ構造をロードする。この用語は、MULTOSカードデバイス発行者製品識別番号を意味する。各カード発行者は、それら発行者が区別すること望み得る、異なるクラスの製品またはカードを有し得る。例えば、銀行は１つの製品ＩＤを備えた通常のクレジットカード、別の製品ＩＤを備えたゴールドクレジットカード、およびまた別の製品ＩＤを備えたプラチナカードを発行し得る。カード発行者は、クレジットカードの１つのクラスのみに所定のアプリケーションをロードすることを望み得る。年会費を支払っているゴールドクレジットカードユーザは、年会費を支払わっていない通常のクレジットカードユーザよりも多様なアプリケーションの権利が与えられ得る。製品ＩＤフィールドは、特定のクラスとしてカードを識別し、後にカード発行者が製品ＩＤをチェックし、所望のクラスに一致したカード上にのみアプリケーションをロードすることを可能にする。
製品を区別する別の方法は、アプリケーションタイプによるものである。例えば、アプリケーションを財政、法的、医学的、および／または娯楽用としてカテゴリー化すること、または特定のアプリケーションを一群のカードに割り当てることなどである。例えば、１つのカード発行者は、異なる複数の企業から異なる複数のセットのカードユーザに利用可能な、異なるロイヤリティプログラムを有し得る。例えば、ある銀行は、飛行機の飛ぶ地域に依存したその国の異なる地域用に、American Airlines▲Ｒ▼ロイヤリティプログラムおよびBritish Airways▲Ｒ▼ロイヤリティプログラムを有し得る。製品タイプは、発行者がパーソナル化プロセス中にカードの製品類別を固定することを可能にする。カード上にアプリケーションをロードする際、各カード上の製品タイプ識別番号は、発行者がロードすることを望むカード上のカードタイプと一致していることを確実にするようにチェックされる。製品タイプデータ構造は、好ましくは（図５Ａの５０５Ａにおいて示すように）８ビットの指標機構（indexing mechanism）（従って他のパーソナル化データ構造とは異なる）であるが、カードシステムのニーズに応じて任意の長さであり得る。図示する実施形態において、結果として生じる指示は、検索されるアレイ中の第２のビット（バイトの表示値が２であるため）を見つけ出すことである（以下の工程８０９の説明を参照のこと）。
工程５０７は、データ構造「msm_mcd_permissions_mcd_controls_data_data」と呼ばれる、アイデンティティフィールドデータ用のデータ構造をロードする。この用語は、MULTOSカードデバイスがデータ日付を制御することを意味する。このデータ日付を言い換えると、例えばアプリケーションローダが、（例えばアプリケーション更新日のような）任意の日付よりも後の日付のついたカードのみをロードする、任意の日付よりも前のカードをロードする、あるいは特定のデータ日付を備えるカードをロードすることができるように、カードがパーソナル化された日付である。この情報は、パーソナル化の年、月、および日を含み得、または所望であればより少ない情報を含み得る。ｄａｔａ＿ｄａｔｅデータ構造は、好ましくは１バイトの長さ（図５Ａの５０７Ａを参照のこと）であるが、使用される特定のカードシステムのニーズに応じて任意の長さであり得る。
全てのパーソナル化データ構造は、一旦カード内にロードされ、記憶されると、カードは発行者、製品クラス、日付および識別番号（および所望であれば、他のデータフィールド）によりすでに識別されている。そしてカードはそのアイデンティティを変更することはできず、よってそれらのフィールドはカードのメモリ内で変更され得ない。カードユーザが別の製品タイプに利用可能な異なるアプリケーションへのアクセスを得るために、カード上に記憶されたｐｒｏｄｕｃｔ＿ｉｄの変更を望む場合には、正しいパーソナル化データを包含する新しいカードがそのユーザに発行されなければならない。このシステムは、類別がプラチナに変更されたときに、ゴールドカードメンバーが新しいカードを受け取ることと矛盾していない。
個別のカードの鍵セット、図３に示すようなＭＳＭパーソナル化特性およびイネーブル化ビットを記憶することにより、カードがイネーブル化され、パーソナル化された後、カードはそのメモリ内へアプリケーションをロードされてもよい状態になる。
アプリケーションのローディング
アプリケーションローディングプロセスは、意図されたＩＣカード上への安全かつ適切なアプリケーションのローディングを確実にするために、複数のセキュリティおよびカード構成チェックを包含する。アプリケーションローディングプロセスは、カードが発行されるときに、カードが１つ以上のアプリケーションを包含するように、好ましくはパーソナル化機関において行われる。カードは、例えば、電子預金アプリケーションまたはクレジット／デビットアプリケーションなどの発行者が発送する全カード上に存在する、所定の共通アプリケーションを含み得る。あるいは、パーソナル化機関は、イネーブルされたカードを第三者に発送し、アプリケーションのローディングプロセスを行わせ得る。各カードのＲＯＭおよびカードＭＳＭパーソナル化データに記憶されたマルチアプリケーションオペレーティングシステムは、カードが特定のカードユーザおよび責任のあるカード発行者の要望により発行された後の、アプリケーションの将来的なローディングおよび消去を可能にするように設計されている。従って、ＩＣカード上に記憶されたアプリケーションのより古いバージョンは、アプリケーションの新しいバージョンに置き換えられ得る。そのアプリケーションが新しく利用可能になったため、もしくはユーザが新しいアプリケーションを利用することを望んでいるという理由で、追加のロイヤリティアプリケーションもまた、カードが最初にカードユーザへ発送された後にカードに追加され得る。アプリケーション用のこれらのローディングおよび消去機能は、端末により直接的に行われ得るか、あるいは電話線、データライン、インターネットもしくは２つのエンティティ間でデータを送信する任意の他の方法のようなネットワークを介して行われてもよい。現在のＩＣカードシステムにおいて、アプリケーションプログラムおよびデータを送信するプロセスは、適切なパーソナル化データを包含し、アプリケーション許可プロフィールに適合するＩＣカードのみが資格を与えられ、対応するアプリケーションプログラムおよびデータを受信する。
図６は、MULTOSＩＣカードシステム内のＩＣカード上にアプリケーションをロードする際に行われる好ましい工程を示す。この例において、パーソナル化機関はアプリケーションを同じカードをイネーブルした端末からロードしている。工程６０１は、カードが特定のアプリケーションのローディングを受け入れる資格が与えられることを確実にするためにカードをプレビューする端末により開始される「オープンコマンド」を行う。オープンコマンドは、アプリケーションの許可データ、アプリケーションのサイズを備えたカードを供給し、カードに（１）イネーブル化ビットが、カードがパーソナル化され終えたことを表示するように設定されているか否か、（２）アプリケーションコードおよび関連したデータが、カード上に存在するメモリスペース内に収まるか否か、および（３）アプリケーションがロードされるように割り当てられたパーソナル化データが、問題とする特定のカードへのアプリケーションのローディングを可能にするか否か、を決定するよう指示する。オープンコマンドはまた、カードシステムから要求されたときに、追加のチェックを行い得る。オープンコマンド実行中のこれらのチェック工程は、図７と合わせて詳細に説明する。
オープンコマンドが実行された後、カードが適切な識別パーソナル化データを含んでいるか否か、ならびにカードのメモリ中にアプリケーションコードおよび関連データのためのスペースが十分にあるか否かに関して、アプリケーションローダは端末を介して知らされる（advise）。メモリが十分になければ、カードからネガティブ応答が返され、プロセスを異常終了（abend）される。識別パーソナル化データがアプリケーション許可データに合致しなければ、ステップ６０３において警告応答が与えられるが、プロセスはロードおよびクリエイト（load and create）ステップに続く。あるいは、合致しない場合には、プロセスは自動的に異常終了されてもよい。ステップ６０５においてカードから端末にポジティブ応答が返された場合は、アプリケーションローダは好ましくは次のステップに進む。オープンコマンドは、コードおよびデータの転送が開始される前に、アプリケーションがカードをプレビューすることを可能にする。
次にステップ６０７は、アプリケーションコードおよびデータをＩＣカード上のEEPROMへロードする。実際のローディングは、クリエイトステップ６０９と関連して起こる。クリエイトステップ６０９はローディングプロセスを完了させ、ロード後にアプリケーションがＩＣカード上で実行されることを可能にする。アプリケーションローディングプロセスを行うために、オープン、ロードおよびクリエイトコマンドの組み合わせが、端末またはその他のアプリケーションプロバイダソースによって、ＩＣカードに送られる。ＩＣカード中のオペレーティングシステムは、これらのコマンドの各々に対して特定の命令のセットを実行するようにプログラムされており、ＩＣカードが端末からの命令と連絡をとりこれを適切に実行する。
ステップ６０９は、クリエイトコマンドを実行する。クリエイトコマンドは少なくとも、（1）アプリケーションロード証明にはＣＡによる署名（暗号化）がなされていることにより、アプリケーションがシステムにとって適切なアプリケーションであることを認証しているか否かをチェックし、（2）カード上に格納されたカードパーソナル化データを、ロードされるべきアプリケーションのための許可プロフィールに照らしてチェックすることにより、カードにローディング資格を与える。必要に応じて他のチェックを行ってもよい。チェックのうちの１つが失敗すれば、失敗応答６１０が与えられ、プロセスはアボートされる。これらのチェックを通った後のアプリケーションは、カードのメモリにロードされる。
図７は、図６のオープンステップ６０１の様々なステップをより詳細に示している。ステップ７０１は、イネーブル化（すなわちコントロール）ビットが設定されているか否かを決定する。このビットは、カードがそのパーソナル化プロセスを完了してパーソナル化データを割り当てられたときに、設定される。アプリケーションは、カードがパーソナル化データを含んでいる場合にのみ、カードシステム中のＩＣカード上にロードされ得る。イネーブル化ビットが設定されていない場合は、カードのパーソナル化はまだであるため、カードはネガティブ応答７０３を端末に返す。イネーブル化ビットが設定されていれば、カードはイネーブルされており、テスト条件はステップ７１１に続く。
ステップ７１１は、カード上のメモリに、アプリケーションコードおよびそれに付随するデータを格納するための十分なスペースがあるか否かをチェックする。アプリケーションは典型的には、その機能に関連するデータが付随している。このデータは、アプリケーションが実行されるときに用いられ、操作される（manipulate）。EEPROMに必要となる比較的大きい物理的スペースおよび、クレジットカードサイズのカード上に納まるように小さいことが望まれる集積回路内にそれをどのように納めるかということから、ＩＣカードのメモリ中の格納スペースは継続的な問題である。ＩＣカード上のプリセットEEPROMのサイズの一例は１６Ｋバイトであるが、実際のサイズは変動する。アプリケーションは、非常に単純なアプリケーションの場合の１Ｋバイト以下から、より高度なアプリケーションの場合の利用可能なメモリサイズまでというように、様々であり得る。アプリケーションに付随するデータは、カードメモリに全くデータが格納されていない状態から、利用可能なメモリ量によって制約を受けるサイズまで、様々であり得る。これら様々なサイズのアプリケーションコードおよびデータは、アプリケーションがより進歩し多様化するにつれて、増加し続ける。
オペレーティングシステムとしてのMULTOSは、カード上に格納し得るアプリケーションの数および付随データによっては、制限されない。従って、５つのアプリケーションがカードの利用可能メモリ中に納まるならば、カードユーザは、１つまたは２つのアプリケーションがカード上に格納されている場合よりも、大きく増大した機能性を有することになる。しかし、カードのメモリが容量いっぱいになると、十分なサイズのコードおよびデータを含む別のアプリケーションを削除することが出来ないかぎり、新しいアプリケーションをカードにロードすることは不可能である。従って、カード上の利用可能スペースの量をチェックすることは、重要なステップである。十分なスペースが存在しなければ、不十分スペース応答７１３が端末に返される。すると、アプリケーションローダは、新しいアプリケーションに空間を作るためにカード上の別の既存のアプリケーションを削除すべきか否かを決定し得る。削除は、カード発行者がＣＡからのアプリケーション削除証明を有するか否かに依存する。カード上に十分なスペースが存在すれば、プロセスはステップ７１５に続く。
次に、ステップ７１１におけるメモリスペースのテストの一例を説明する。この例において用いられる数は、発明の範囲を何ら限定するものではなく、メモリスペース要求を例示するために用いているだけである。ＩＣカードは、最初の製造時において、１６Ｋの利用可能EEPROMを有し得る。オペレーティングシステムに必要とされるオペレーティングシステムデータは、最大２Ｋのメモリスペースを占め得る。従って、１４Ｋが残ることになる。電子預金アプリケーションのコードはEEPROMに格納され、８Ｋのメモリスペースを占め得る。財布アプリケーションの必要なデータは、EEPROM中においてさらに４Ｋのメモリスペースを占め得る。他のアプリケーションが自由に使い得るメモリスペースは従って、２Ｋ（１６Ｋ−２Ｋ−８Ｋ−４Ｋ＝２Ｋ）である。この例において、コードのサイズが６Ｋのクレジット／デビットアプリケーションをカード発行者がカードにロードしたい場合、アプリケーションはＩＣカードのメモリ内に納まらない。従って、アプリケーションは、まず財布アプリケーションをカードから除去することなしには新しいアプリケーションをロードすることができない。もし新しいクレジット／デビットアプリケーションがＩＣカードのEEPROMにロードされると、その他のアプリケーションのコードまたはデータを上書きしなければならなくなる。アプリケーションローダは、これを行うことを防止される。
図８は、カードのパーソナル化データが、問題とするアプリケーションがロードされてもよい許可カードのセット（permissible set of cards）内にあるか否かを決定するために、実行されるステップを示している。これらのステップは好ましくは、「クリエイト」コマンドの実行中に実行される。しかし、これらのステップは、アプリケーションのローディングまたは削除中の任意の時刻に行われ得る。前述のように、カードは、個々のカードに特異的なカードＩＤ指定、カードの発行者を示すカード発行者番号、カードの製品タイプ（ゴールドカードであるかプラチナカードであるかなど）、およびカードがパーソナル化された日付を含む、カードに特異的なデータ（ＭＳＭパーソナル化データ）を格納することによってパーソナル化される。このデータは、カードを、システム中の他の全てのＩＣカードからユニークに識別する。
従ってアプリケーションは、次のものを含む実質的にあらゆる基準によって、ＩＣカード中の個々のカード上に選択的に格納され得る。アプリケーションは、１つ以上の特定のカード番号を含むカードに選択的にロードされてもよい。アプリケーションは、特定されたカード発行者ＩＤを含む１つ以上のカードに選択的にロードされてもよい。さらに、アプリケーションは、特定のカード発行者によって特定される１つの製品タイプのみにロードされてもよく、および／または、アプリケーションは、特定されたある１つのまたは一連のパーソナル化日付を有するカードにのみロードされてもよい。パーソナル化データの各々は、アプリケーションが、あるカードまたはカード群に選択的にロードされることを可能にし、また、適切な許可を有さないカードはアプリケーションを受け取らないことを確実にする。示した４つに加えて、パーソナル化データタイプもまた必要に応じて用いられ得る。
特定のアプリケーションがロードされてもよいＩＣカードの選択は、アプリケーションに割り当てられ、アプリケーションがロードされてもよいカードの少なくとも１つのセットを表す、「アプリケーション許可データ」の使用によって可能になる。セットは、カード番号、カード発行者、製品タイプまたはパーソナル化データのうちの１つ以上を含む、実質的にあらゆるファクタに基づき得る。個々のカードのパーソナル化データは典型的には１つの特定の番号、１つのカード発行者、１つの製品タイプ、および１つの日付を識別するが、アプリケーションの許可データは、カード番号または包括的許可（blanket permission）、カード発行者または包括的許可、および複数の製品タイプおよび日付を示してもよい。
例えば、得意客（frequent loyalty）プログラムは、１つのカード発行者に属する異なる製品クラスのカード上において、その使用およびローディングを可能にするように構成されてもよい。また、アプリケーション許可データは、カードが1998年５月以降に発行されたものであればゴールドまたはプラチナの製品タイプ上でロイヤリティプログラムが使用可能であることを示してもよい。このように、ＭＳＭ許可チェックは、カードの個々のパーソナル化データが、アプリケーションがロードされてもよい許可カードのセット中に含まれるか否かを決定する。
比較プロセスを促進するために、別の実施形態は、１つ以上の許可データを、その特定のデータについての包括的許可を表すゼロに設定することを包含し得る。例えば、アプリケーション許可データの「カード番号」エントリにゼロを入れることにより、あるいは全てのカードを番号によらずロードを行ってよいことを示す、その他の値を入れることによって、システムは、カード番号に基づいていかなるカードを否定することもしてはならないことを知る。さらに、アプリケーションの許可データカード「発行者ＩＤ」にゼロが入れられると、全てのカードは同様に「発行者」テスト比較をパスする。この特徴により、カード群を選択する際においてより大きな柔軟性を可能にする。ゼロインジケータはまた、必要に応じて他の許可データのためにも用いられ得る。
図８を参照して、許可データの各々は図示した順にチェックされるが、許可のうち１つが失敗した場合、アプリケーションは、チェック中のＩＣカード上にロードされることを禁止されるため、他の順序で行ってもよい。許可は、好ましくは図示された順序でチェックされる。ステップ８０１は、アプリケーション許可製品タイプセットが、カードのメモリ中に格納されたカードの製品タイプ番号を包含するか否かを決定する。各カード製品タイプには、システムオペレータによってある番号が割り当てられる。異なるカード発行者は異なる製品タイプを有するであろうから、製品タイプは各カード発行者について特定される。承認された製品タイプのカードにのみアプリケーションがロードされることを確実にするため、カードは選択的にチェックされる。アプリケーション許可製品タイプセットは、複数の容認可能な製品タイプを含む３２バイト長であってもよく、あるいは、システムのニーズに応じて異なる長さであり得る。データ構造５０５Ａを一例として用いると、オペレーティングシステムは、３２バイト長のアプリケーション許可データ構造から得られる、２５６ビットアレイ（３２バイト×８ビット／バイト）中のビット番号２をチェックすることになる。許可チェックが失敗すると、ステップ８０３においてカードは失敗メッセージを端末に返す。製品タイプチェックがパスすると（例えば第２ビットの値が１であれば）、プロセスはステップ８０５に続く。
ステップ８０５は、アプリケーション許可許容カード発行者番号セットが、カードのメモリ中に格納されたカード発行者番号を包含するか否か、あるいは、アプリケーション許可発行者データがゼロである（全てのカードがこの個別許可チェックをパスすることを示す）か否かをチェックする。システムオペレータによって各カード発行者に番号が割り当てられ、承認されたカード発行者によって配布されたカードにのみアプリケーションがロードされるようにするために、カードを選択的にチェックする。アプリケーション許可カード発行者番号セットは、１つのカード発行者が指定される場合は４バイト長であってもよく、あるいは、システムのニーズに応じてこれより長くてもよい。発行者チェックが失敗すると、ステップ８０７においてカードは失敗メッセージを端末に返す。チェックがパスすると、プロセスはステップ８０９に続く。
ステップ８０９は、アプリケーション許可データセットが、カードのメモリに格納されたカードのデータ日付を包含するか否かをチェックする。ＩＣカードがパーソナル化された日付は格納され、好ましくは少なくとも月および年を含む。承認されたパーソナル化日付を有するカードにのみアプリケーションがロードされるようにするために、カードを選択的にチェックする。アプリケーション許可日付セットは、複数の日付を含む３２バイト長であってもよく、あるいは、システムのニーズに応じて異なる長さであってもよい。日付許可チェックが失敗すると、ステップ８１１においてカードは失敗メッセージを端末に返す。日付チェックがパスすると、プロセスはステップ８１３に続く。
ステップ８１３は、アプリケーション許可許容カード番号セットが、カードのメモリに格納されたカードのＩＤ番号を包含するか否か、あるいは、アプリケーション許可許容カード番号データがゼロである（全てのカードがこの個別許可チェックをパスすることを示す）か否かをチェックする。許可のテストは、オープン、ロード、およびクリエイトコマンドの実行中に、カードに対して行われる。アプリケーション許可カード番号データセットは、１つの番号が指定される場合は８バイト長であってもよく、あるいは、システムのニーズに応じてこれより長くてもよい。カード番号チェックが失敗すると、ステップ８１５においてカードは失敗メッセージを端末に返す。日付チェックがパスすると、プロセスはステップ８１７に続く。
ＩＣカードシステムのプロセスの概略
図９は、安全なマルチアプリケーションＩＣカードシステム中のＩＣカードの、カード初期化プロセスのための、システムアーキテクチャの要素を示す。システムはカード製造者１０２、パーソナル化機関１０４、アプリケーションローダ１０６、初期化中のＩＣカード１０７、カードユーザ１０９、およびマルチアプリケーション安全システム全体のための証明機関１１１を含む。カードユーザ１３１は、ＩＣカード上の格納されたアプリケーションを用いる者あるいはエンティティである。例えば、カードユーザは、同一ＩＣカード上に電子キャッシュ（例えばMONDEXTM）とクレジット／デビットアプリケーション（例えばMasterCard▲Ｒ▼EMVアプリケーション）とを含んだ電子預金ＩＣカードを好み得る。以下に、カードユーザが、安全な方法で所望のアプリケーションを含んだＩＣカードを取得するための一方法を説明する。
カードユーザは、ＩＣカードを配布する銀行などのカード発行者１１３にコンタクトを取り、単一のＩＣカードのメモリ中に常駐した２つのアプリケーションを備えたＩＣカードを要求する。ＩＣカードの集積回路チップは製造者１０２によって製造され、カード上のＩＣチップの形でカード発行者１１３（またはそれを代表するエンティティ）に送付される。前述のように（ステップ２０１〜２０９を参照）、製造プロセス中において、データは、製造者１０２からデータ路を介してカード１０７に転送１１５され、ＩＣカード１０７のメモリに格納される。（この図に説明したデータ路のうちのいずれも、電話線、インターネット接続、あるいはその他の転送媒体であり得る）。システム全体のための暗号化／復号化鍵を維持している証明機関１１１は、データ路を介してセキュリティデータ（すなわちグローバル公開鍵）を製造者に送信１１７し、製造者によってセキュリティデータは他のデータ（例えばカードイネーブル化鍵およびカード識別子など）とともにカード上に置かれる。カードのマルチアプリケーションオペレーティングシステムもまたＲＯＭ中に格納されており、製造者によってカード上に置かれる。カードは初期処理を施された後、パーソナル化およびアプリケーションローディングのためにカード発行者に送られる。
カード発行者１１３は２つの別々の機能を行うか、あるいは別のエンティティによって行わせる。第１に、パーソナル化機関１０４は、上述した方法でＩＣカード１０７をパーソナル化し、第２に、アプリケーションローダ１０６は、上述のようにカードが資格を与えられている場合において、アプリケーションをロードする。
パーソナル化に関して、個別化されたカード鍵セットがＣＡによって生成され、カードに格納される（図３を参照）。さらに、ＭＳＭパーソナル化を用いて、カードＩＤ番号、カードを処理したカード発行者を識別する発行者ＩＤ番号、カード発行者によって特定されるカード製品タイプ番号、およびパーソナル化が行われた日付を含む、特定のアイデンティティがカードに与えられる（図３のステップ３０７および図５を参照）。カードがパーソナル化された後、カードが所望の機能を実行できるようにアプリケーションがカードにロードされる必要がある。
アプリケーションローダ１０６（パーソナル化機関１０４と同じ端末またはデータ路を用い得る）はまず、カードがアプリケーションを受け入れる資格を有しているか否かを決定する必要がある。この比較プロセスは、許可情報を用いて（オペレーティングシステムの命令に従って）カード自体の上で起こる。カードは、資格を与えられていれば、カードのアイデンティティおよびカード発行者の命令に基づいて選択的にアプリケーションを自身にロードする。アプリケーションローダは端末またはその他のデータ路を介してＩＣカードと連絡１１９する。アプリケーションがカードにロードされた後、カードはカードユーザ１０９に送達されて使用される。
本明細書に説明した安全なマルチアプリケーションＩＣカードシステムは、カードがパーソナル化された後、ＩＣカードのライフサイクル中の任意の時点において、アプリケーションの選択的なローディングおよび削除を可能にする。従って、カードユーザはまた、アプリケーションを有さないパーソナル化カードを受け取ってから、電話線またはインターネット接続などの共通の送信線を介して、所望のアプリケーションを選択し得る。
図１０は、パーソナル化されてから後のＩＣカードの使用に関与するエンティティのシステム図である。システムはＩＣカード１５１、端末１５３，アプリケーションロード／削除エンティティ１５５、証明機関１５７、カード発行者１７１、およびシステム中の他のＩＣカード１５９を含む。矢印は、各エンティティ間の通信を表す。ＣＡ１５７は、アプリケーションのローディングおよび削除を容易にする。カードイネーブル化中においてＭＳＭ許可データおよびカード特異的な鍵セットをカードに提供した後、ＣＡは、好ましくはアプリケーション証明（application certificate）を発行することによってアプリケーションを後にロードまたは削除することを可能にする。アプリケーション特異的な鍵は、カードと端末との間の通信を認証するために必要とされる。ＩＣカード１５１はまた、他のＩＣカード１５９とも通信可能である。カード発行者１７１は、発行したカードに対するアプリケーションのローディングおよび削除の全ての決定に関与する。全ての通信は認証され、システム内を安全に送信される。
例えば、ＩＣカード１５１は以下の手順を用いて、新しいアプリケーションをカードにロードする。ＩＣカード１０１が端末１５３に接続され、端末はアプリケーションのロードを要求する。端末１５３はアプリケーションロード／削除エンティティ１５５にコンタクトを取り、アプリケーションロード／削除エンティティ１５５はその結果カード発行者１７１とともに、アプリケーションコード、データ、およびアプリケーション許可データ（ならびに他の任意の必要なデータ）を端末１５３に送る。端末１５３は、カード１５１に問い合わせて（query）それがアプリケーションをロードしてもよい正しいカードであることを確実にする。ＩＣカードが上記のチェックをパスすれば、アプリケーションはカード１５１にロードされる。ＣＡ１５７は、アプリケーションがカードにロードされまたはカードから削除されることを可能にする、アプリケーションロードまたは削除証明を供給する。この例は、アプリケーションをロードするための一法を示しているが、他の変形例もまた同じ原則を用いて実施することができる。例えば、アプリケーションロード／削除エンティティ１５５において直接アプリケーションをロードすることなどである。
上記は本発明の原則を例示したに過ぎない。従って、当業者は、本明細書において明示的に示しあるいは説明されなくとも本発明の原則を体現しており従って本発明の趣旨および範囲内にある、多くのシステムおよび方法を考案することが可能であることが、理解される。
例えば、ＭＳＭパーソナル化および許可データは、アプリケーションをＩＣカードにロードするためだけのみならず、そのカードからアプリケーションを削除するためにも用い得ることが理解される。ＭＳＭ許可およびアプリケーションのローディングを含む同様のチェックが、アプリケーションの削除についても行われる。アプリケーションの削除を承認するＣＡからの削除証明は、どのカードからアプリケーションを削除してもよいかを制御する。これは、本明細書に説明したように、各ＩＣカード上に格納されたパーソナル化データおよび許可チェックを通して達成される。
さらに、カード上に物理的にはロードされない、アプリケーションがロードされ得るパーソナルコンピュータまたはその他のユニットにも、データは適用可能である。また、アプリケーションの許可データは実際には、含まれるべきではなく除外されるべきカード−−すなわちアプリケーションをロードされ得ないカードのセット（単数または複数）を表すデータを有していてもよい。
本開示の範囲は、請求された発明に関連するか否か、あるいは本発明で対処される課題の一部または全てを緩和するか否かに関わりなく、明示的または黙示的に開示された新規の特徴または特徴の組み合わせあるいはそれを一般化したものを含む。本出願は、本出願または本出願に由来する任意のさらなる出願の手続中に、そのような特徴に関する新しい請求項が作成され得ることの注意を促すものである。特に、付属の請求項に関しては、従属項に由来する特徴は、請求の範囲に挙げた特定の組み合わせのみならず、任意の適切な方法で独立項の特徴と組み合わせ得る。
【図１】
0004327261.tif 000002
【図２】
0004327261.tif 000003
【図３】
0004327261.tif 000004
【図４】
0004327261.tif 000005
【図５】
0004327261.tif 000006
【図５Ａ】
0004327261.tif 000007
【図６】
0004327261.tif 000008
【図７】
0004327261.tif 000009
【図８】
0004327261.tif 000010
【図９】
0004327261.tif 000011
【図１０】
0004327261.tif 000012