(57)【特許請求の範囲】
【請求項１】
ＩＣカードシステムであって、該ＩＣカードシステムは、少なくとも１つのＩＣカードと、該ＩＣカードにロードされるアプリケーションプログラムおよびデータと、該ＩＣカードを表すカード個人化データを該ＩＣカードにロードする個人化処理手段と、該ＩＣカードへの該アプリケーションプログラムおよびデータのロードを受け入れる資格が該ＩＣカードにあるか否かを決定する決定手段とを備えており、該アプリケーションプログラムおよびデータは、該アプリケーションプログラムおよびデータがロードされ得るＩＣカードの少なくとも１つのセットを示すアプリケーション許可データに関連づけられており、該決定手段は、該カード個人化データを該アプリケーション許可データと比較する、ＩＣカードシステム。
【請求項２】
前記アプリケーションプログラムおよびデータが前記ＩＣカードにロードされるか否かは、前記比較の結果に依存し、前記カード個人化データが前記アプリケーション許可データとマッチする場合に、該アプリケーションプログラムおよびデータが該ＩＣカードにロードされる、請求項１に記載のＩＣカードシステム。
【請求項３】
前記カード個人化データは、一意のカード識別名称を表すデータを含む、請求項１に記載のＩＣカードシステム。
【請求項４】
前記カード個人化データは、カード発行者を表すデータをさらに含む、請求項３に記載のＩＣカードシステム。
【請求項５】
前記カード個人化データは、製品分類を表すデータをさらに含む、請求項４に記載のＩＣカードシステム。
【請求項６】
前記カード個人化データは、日付を表すデータをさらに含む、請求項５に記載のＩＣカードシステム。
【請求項７】
ＩＣカードシステムであって、該ＩＣカードシステムは、少なくとも１つのＩＣカードと、該ＩＣカードを表すカード個人化データを該ＩＣカードにロードする個人化処理手段と、アプリケーションプログラムおよびデータとを備えており、該アプリケーションプログラムおよびデータは、該アプリケーションプログラムおよびデータがロードされ得る少なくとも１つのＩＣカードを示すアプリケーション許可データセットに関連づけられており、該システムは、該個人化データが該許可データセットの中に含まれるか否かを決定する決定手段をさらに備えている、ＩＣカードシステム。
【請求項８】
前記アプリケーションは、前記個人化データが前記セットの中に含まれると前記決定手段が決定した場合に、前記ＩＣカードにロードされる、請求項７に記載のＩＣカードシステム。
【請求項９】
前記個人化データは、カード識別名称および前記カードの発行者を表すデータを含む、請求項７に記載のＩＣカードシステム。
【請求項１０】
前記個人化データは、製品分類および日付を表すデータをさらに含む、請求項９に記載のＩＣカードシステム。
【請求項１１】
前記アプリケーション許可データセットは、複数のカード識別名称を含む、請求項７に記載のＩＣカードシステム。
【請求項１２】
前記アプリケーション許可データセットは、ＩＣカードの１つ以上の発行者を含む、請求項７に記載のＩＣカードシステム。
【請求項１３】
前記アプリケーション許可データセットは、１つ以上の製品分類を含む、請求項７に記載のＩＣカードシステム。
【請求項１４】
前記アプリケーション許可データセットは、日付の範囲を含む、請求項７に記載のＩＣカードシステム。
【請求項１５】
ＩＣカードにアプリケーションプログラムおよびデータをロードする方法であって、該方法は、カード個人化データを該ＩＣカードにロードする個人化処理のステップと、該ＩＣカードへの該アプリケーションプログラムおよびデータのロードを受け入れる資格が該ＩＣカードにあるか否かを決定するステップを包含し、該決定するステップは、
該ＩＣカードに、該アプリケーションプログラムおよびデータがロードされ得るＩＣカードの少なくとも１つのセットを示すアプリケーション許可データを提供するステップと、
該ＩＣカードに対して、該ＩＣカードを表す該カード個人化データと該アプリケーション許可データを比較するように命令するステップと、
該カード個人化データが、該アプリケーションプログラムおよびデータがロードされ得るカードのセットに含まれる場合に、該ＩＣカードに該アプリケーションプログラムおよびデータをロードするステップと
を包含する、方法。
【請求項１６】
前記カード個人化データは、カード識別名称を表すデータを含む、請求項１５に記載の方法。
【請求項１７】
前記カード個人化データは、カード発行者を表すデータをさらに含む、請求項１５に記載の方法。
【請求項１８】
前記カード個人化データは、製品分類を表すデータを含む、請求項１５に記載の方法。
【請求項１９】
前記カード個人化データは、日付を表すデータをさらに含む、請求項１８に記載の方法。
【請求項２０】
ＩＣカードからアプリケーションプログラムおよびデータを削除する方法であって、該方法は、カード個人化データを該ＩＣカードにロードする個人化処理のステップと、該アプリケーションプログラムおよびデータに関連づけられているアプリケーション許可データに基づいて、該アプリケーションプログラムおよびデータを削除する資格が該ＩＣカードにあるか否かを決定するステップを包含し、該決定するステップは、
該ＩＣカードに、該アプリケーションプログラムおよびデータがロードされ得るＩＣカードの少なくとも１つのセットを示すアプリケーション許可データを提供するステップと、
該ＩＣカードに対して、該ＩＣカードを表す該カード個人化データと該アプリケーション許可データを比較するように命令するステップと、
該カード個人化データが、該アプリケーションプログラムおよびデータが削除され得るカードのセットに含まれる場合に、該ＩＣカードから該アプリケーションプログラムおよびデータを削除するステップと
を包含する、方法。
【請求項２１】
前記カード個人化データは、カード識別名称を表すデータを含む、請求項２０に記載の方法。
【請求項２２】
前記カード個人化データは、カード発行者を表すデータをさらに含む、請求項２０に記載の方法。
【請求項２３】
前記カード個人化データは、製品分類を表すデータを含む、請求項２０に記載の方法。
【請求項２４】
前記カード個人化データは、日付を表すデータをさらに含む、請求項２０に記載の方法。
【請求項２５】
ＩＣカードシステムであって、該ＩＣカードシステムは、少なくとも１つのＩＣカードと、該ＩＣカードから削除されるアプリケーションプログラムおよびデータと、該ＩＣカードを表すカード個人化データを該ＩＣカードにロードする個人化処理手段と、該ＩＣカードから該アプリケーションプログラムおよびデータを削除する資格が該ＩＣカードにあるか否かを決定する決定手段とを備えており、該アプリケーションプログラムおよびデータは、該アプリケーションプログラムおよびデータが削除され得るＩＣカードの少なくとも１つのセットを示すアプリケーション許可データに関連づけられており、該決定手段は、該カード個人化データを該アプリケーション許可データと比較する、ＩＣカードシステム。
【請求項２６】
前記アプリケーションプログラムおよびデータが前記ＩＣカードから削除されるか否かは、前記比較の結果に依存し、前記カード個人化データが前記アプリケーション許可データとマッチする場合に、該カードに資格が与えられ、該アプリケーションプログラムおよびデータが削除される、請求項２５に記載のＩＣカードシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
集積回路（「IC」）カードは、今日世界で多くの様々な用途にますます利用されつつある。ICカード（スマートカードとも呼ばれる）は、一般的に従来のクレジッドカードの大きさを有し、マイクロプロセッサー、読み取り専用メモリ（ROM）、電気的に消去プログラム可能な読み取り専用メモリ（EEPROM）、入力/出力機構、およびその処理においてマイクロプロセッサーを補助する他の回路構成を有するコンピュータチップを含んでいる。ICカードは、メモリー内部に単一アプリケーションを有してもよく、あるいは複数の独立アプリケーションを有してもよい。MULTOSＴＭは、ICカード、他のプラットフォーム間上で動作する複数アプリケーション用オペレーティングシステムであり、カード本体上で複数のアプリケーションが実行し得る。これにより、カードユーザは、使用に際してカードが挿入される端末のタイプ（即ち、ATM、電話及び/又は、POS）によって、カード（例えば、クレジット/デビッド、電子マネー/パース、及び/又は、ロイヤルティアプリケーション）に記憶された多くのプログラムを実行し得る。
【０００２】
テレフォンカードまたは、電子キャッシュカードのような従来の単一アプリケーション用ICカードは、個人登録段階で、単一アプリケーションがロードされている。しかしそのアプリケーションは、カード発行後カードユーザまたは、カード発行者が修正を希望する場合でさえ、修正または、変更ができない。さらに、カードユーザが、ユーザ（him  or  her）に発行されたＩＣカードで、電子パース及びクレジット/デビッドの両方の機能のような、種々のアプリケーション機能を実行したい場合、カードユーザは、ユーザ自身が複数の物理カードを携帯する必要があり、非常に煩わしく不便である。アプリケーション開発者または、カードユーザが、マイレッジロイヤルティアプリケーションと相互に連携をとるパースアプリケーションのような、二つの異なるアプリケーションに対して相互にデータをやりとりまたは、交換したい場合、カードユーザはカード受け取り端末で複数のカードを出し入れして交換しなければならず、処理は複雑で面倒で、不便である。
【発明の開示】
【課題を解決するための手段】
【０００３】
従って、出願者は同じICカードに複数のアプリケーションを記憶するのが有益であると認識している。例えば、カードユーザはパースアプリケーション及び、クレジット/デビッドアプリケーションの両方を同じカード上に持ち得るので、カードユーザが、購買に際して使用する支払（電子キャッシュまたは、クレジットカード）のタイプを選択し得る。十分なメモリーがあり、オペレーティングシステムがカード上に存在する複数アプリケーションをサポートできるならば、複数のアプリケーションをICカード上に提供し得る。製造段階で、複数のアプリケーションは予め選択され、カードのメモリ内部に保持されるが、必要に応じて、カード製造後にアプリケーションをロードし、消去する機能を持つことも便利である。
【０００４】
増大する可撓性と単一カード上に複数アプリケーションを記憶する能力は、克服すべき新たな課題を生み出している。それは、アプリケーションのロード及び消去時において、システム全体内と同様、個人カードとアプリケーションプロバイダ間で交換される情報（アプリケーションコード及び関連するデータを含む）の統合とセキュリティに関するものである。カード、カード発行者、システムオペレータ及びアプリケーションプロバイダ間でデータを交換し、端末または電話回線を通した遠隔地、インターネットまたは、イントラネット接続または、他のデータ線のいずれかからいかなる時も安全にデータをロード及び消去できるICカードシステムの性能が有益であることを、出願者は一層認識している。これらのデータ伝送回線は一般的に、セキュリティが保証された回線ではないため、アプリケーションが伝送回線を介して目的とするカードだけにロードされることを保証するために、多くのセキュリティ及び独自の認証技術が実装されなければならない。
【０００５】
前述した様に、カード所有者に引き続き新しい、広範なアプリケーションの入手可能性がある場合、特に重要なのは、発行後のICカードへのアプリケーションの追加能力をシステムが有することである。これはICカードの存続期間を保護するために非常に有益である。さもなければ、いったんアプリケーションが古くなると、カードは役に立たなくなる。この点において、ICカードへの不適切または、必要とされないアプリケーションのロードを防ぐために、ロードプロセスを管理すること、必要または望まれる際に、アプリケーションがシステム内のICカードに対して「選択的に適用できる」ように限定されたグループまたはカード数に対して特定のアプリケーションの利用を制限する能力を有することは、ICカードシステムにとって有益であり、出願者はこれを一層認識している。この「選択的能力」によって、例えばカード存続期間の所望の時点において、アプリケーションのロード及び消去が可能となる。それによりまた、選択されたアプリケーションを受け取るよう選択されたカードに対してのみアプリケーションをロードし得る。
【０００６】
従って、本発明の望ましい実施態様の利点は、これらの重要な特徴を提供し、特に、ICカードにロードされ得るスマートカードアプリケーションの選択的適用性のための安全なICカードシステムを提供することにある。
【０００７】
これらの及び、他の利点は、少なくとも一つのICカードとカードにロードされるアプリケーションを含有するICカードシステムによって示される本発明の実施態様により達成され、ICカードはカード個人登録データを有し、どのアプリケーションがどのICカードまたは、ICカードのグループにロードされ得るかを指定するアプリケーション許可データが、アプリケーションに割り当てられる。アプリケーションの許可データによって指定された許容範囲内にカードの個人登録データが入っているかどうかを判断するために、システムはチェックを行う。もし、入っていればアプリケーションはカードにロードされる。
【０００８】
望ましい実施態様では、カード個人登録データは、カード製造後、個人登録事務所によってカードに伝送される。望ましくは、カード番号、発行者、製造クラス（即ち、ゴールドまたは、プラチナカードなどの）、及びカードが個人登録された日付を示すデータが含まれる。さらに望ましくは、カードは、カードが個人登録データを認可するかどうかを示す認可データを有する。
【０００９】
別の実施態様では、アプリケーションをロードする前に、カードが認可されているかどうかを判断するために、ICカード保証システムが認可データをチェックする。望ましくは、カードが認可されている場合、カード番号、発行者、製造クラス及び/又は、カードが個人登録された日付がアプリケーションの許可データで示される許容範囲内にあるかどうかをシステムはチェックする。認可されている場合に、アプリケーションはICカードにロードされ得る。
【００１０】
また別の望ましい実施態様では、アプリケーションの許可データは全てのカードがアプリケーションのロードを認めるような一括（branket）許可を表すデータを有してもよい。
【発明を実施するための最良の形態】
【００１１】
別の局面として、発明の実施態様の特徴及び利点は、発明の実施態様の概要を表す図に付随して示される以下の詳細な記述から明らかになる。
【００１２】
言い換えがない限り図を通して、同じ参照番号及び記号は、特徴、要素、構成または、示された実施態様の一部の表記に使用される。さらに、現在対象となる発明は関連図で詳細に示されるため、例示した実施態様に関しても同様である。これは添付した請求の範囲によって規定されるような対象となる発明の真の範囲及び精神から外れることなく、変更及び修正が詳述された実施態様に対してなされることを意図している。
【００１３】
本発明の実施態様は、カードユーザ、カード発行者及び/または、アプリケーション開発者のニーズまたは要望に対応して、マルチアプリケーションICカードの有効期限を通して選択されたアプリケーションを自由にロード及び、消去し得るICカードシステム及びプロセスを提供する。システムオペレータと連携をとるカード発行者または、プロセスに関する情報の伝達を認定することによりロード及び消去プロセスを制御する認証当局（“CA”）によって許可された場合、要求に応じて、このようなカードを有するカードユーザは、選択的にアプリケーションをロード及び消去し得る。
【００１４】
カードから選択的にアプリケーションがロードされ消去され得ることによって、カード発行者は、新たなカードを発行せずに個人ICカードに追加機能を拡張することができる。さらに、アプリケーション開発者は、古いアプリケーションを新たに改訂されたバージョンに置き換えることが可能となり、共通の複数アプリケーション用オペレーティングシステムを使用する同じカード上に存在するアプリケーションは安全で保証された方法でデータを相互利用及び交換し得る。例えば、マイレッジローヤリティプログラムは、Mondexパースなどの電子パースまたは、クレジット/デビッドアプリケーションで支払われた１ドル毎に対してカードユーザの内部アカウントにマイレッジ１マイルを自動的に計上してもよい。選択的にアプリケーションをロード及び消去する能力を許可することで、カード発行者の要求に従ってカードユーザはまた所望のローヤリティプログラムの変更オプションを有する。
【００１５】
カード発行者または、アプリケーション開発者は、カードシステムにおける特定のカードユーザに対する唯一のカードにのみ特定のアプリケーションがロードされ得ることを意図し得る。地方銀行は銀行が発行するカードにのみ存在する所有者アプリケーションを所持することを望んでもよい。本発明に従った実施態様は、この選択的ロードを可能にし、特に他者によって発行された認証されていないカードへの所有者アプリケーションのロードを防止し得る。
【００１６】
これらの所望の目的を達成するために、本発明の実施態様は、カードに「カード個人登録データ」を記憶することによって各カードに特定の識別を与える。さらに、システム内の一つまたは、複数のカードにロード及び消去される各アプリケーションには、アプリケーションがロードされ得るカードを特定する「アプリケーション許可データ」が割り当てられる。
【００１７】
個人登録されるデータのタイプはカードシステムのニーズ及び条件によって依存し得る。望ましい実施態様では、以下でさらに詳しく解説するが、個人登録されたデータには、固有のカード識別指定データ、カード発行者、製造クラスまたは、タイプ（カード発行者によって規定される）及び、個人登録の日付が含まれる。しかし、これらの全てデータ要素が使用の際に必要とされるのではなく、補足的要素もまた含まれ得る。
【００１８】
以下でさらに詳しく述べるが、アプリケーションに関するアプリケーション許可データはまた、識別フィールドにおける唯一の値であり得、または、識別フィールドにおける複数の値を持ち得る。例えば、カード発行者フィールドにおけるアプリケーション許可データは、特定の銀行Xからの製造クラスA及び、製造クラスBの両方を示し、銀行Xによって発行された製造クラスA及びBとして（カード個人登録データのカード製造IDフィールドに示されるように）指定されるカードにアプリケーションがロードされ得ることを意味する。
【００１９】
さらに、アプリケーション許可データの発行者フィールド（または他のフィールド）に「グローバルバリュー」が記憶され得、カード発行者にかかわらずシステム内の全ICカードがこの許可フィールドに適合することを示す。この場合、例えば、アプリケーション許可カード発行者フィールド内に記憶された値ゼロのデータはカードの個人登録カード発行者フィールドの全てに適合する。
【００２０】
保証されたシステムにおいて使用可能なマルチアプリケーションＩＣカードの提供に含まれる３つの工程を、図１に示す。第１の工程は、カード製造工程１０１である。第２の工程は、個人登録工程１０３であって、カードの個人登録データ（エンティティ認証（authentication）データとも呼ばれる）がカードにロードされる。第３の工程はアプリケーションのロード工程１０５であって、カードがアプリケーションを受けるのに適格であるかどうかを点検する。すなわち、この工程では、ロードされるアプリケーションに関連したアプリケーション許可データに対して個人登録データが確認される。以下、これら３つの工程のそれぞれを詳細に説明する。
【００２１】
カード製造
保証されたシステムにおけるＩＣカードの製造に必要な工程を、図２に示す。工程２０１では、シリコン上に集積回路を形成し、これをカード上に配置することにより、物理ＩＣカードを製造する。集積回路チップには、ＲＡＭ、ＲＯＭ、およびＥＥＰＲＯＭメモリが含まれる。最初にカードが製造されるとき、工程２０３において、システムオペレータ（この場合、証明機構（ＣＡ）と呼ばれる）のグローバル公開キーが各カードのＲＯＭに記憶される。これによりカードは、カードの公開キーがＣＡの極秘番号に一致するので、カードへのいかなる伝達もＣＡがソースであるよう認証され得る。
【００２２】
より詳細には、カードに記憶されるこの公開キーにより、個々のカードがＣＡの個人キーで署名されたデータを検証できるようになる。ＣＡの公開キーは、カードに記憶されており、カードに送られたデータが、適切なＣＡ個人キーで署名されているかどうかを判断することのみに用いられる。これにより、カードはＣＡから送られたいかなるメッセージのソースも検証できる。
【００２３】
工程２０５では、カードイネーブルメント（enablement）キーを、カードのＥＥＰＲＯＭの安全な部分に挿入し、イネーブルメント中におけるカード個別秘匿化を容易にし、工程２０７では、カード識別子をそのカードのＥＥＰＲＯＭ内に挿入する。識別子は、いかなる端末によってもアクセスでき、システムが後のプロセスでカードの識別を判定できるようにする。識別子は自由に利用でき、メッセージを認証するのには用いられない。
【００２４】
工程２０９では、オペレーティングシステムによって呼び出され、またはサポートされるいかなるプリミティブをも含めたオペレーティングシステムコードを、カードのＲＯＭに記憶する。プリミティブはネイティブ言語コード（例えば、アセンブリ言語）で書かれており、ＲＯＭに記憶されている。プリミティブは、オペレーティングシステムによって、あるいは、演算機能（乗算または除算）、データ検索、データ操作、または暗号化アルゴリズムなどカードに常駐するアプリケーションによって、呼び出され得るサブルーチンである。プリミティブはプロセッサのネイティブ言語で書かれているので非常に迅速に実行し得る。
【００２５】
ＩＣカードは製造されると、カードのメモリにカード個人登録データを記憶させることによりカードをイネーブルメントおよび個人登録するために、個人登録事務局（「ＰＢ」）に送られる。本明細書では、イネーブルメントおよび個人登録という用語を、カードに安全にアプリケーションをロードさせる準備工程を示すものとして交換可能に使用している。個々のカードは好ましくは、バッチ単位で製造され、個人登録事務局へまとめて送られ処理される。
【００２６】
カードイネーブルメント／個人登録
図３は、カードが個人登録事務局へ届いたときの、カードイネーブルメントプロセスを示す。個人登録事務局は、カードの発行者（例えば、銀行または他の金融機関）であり得るし、またはカード発行者のためのサービスを実行する第三者であり得る。個人登録事務局は、特定のユーザまたはユーザクラスにあわせてカードを設定する。
【００２７】
図３は、システム内で使用できる各ＩＣカードをイネーブルメントおよび個人登録するのに行われる工程を詳細に示している。カードは、ＩＣカードと通信する端末に置くことができ、端末がカード識別子データ（製造プロセスで予めカードに配置されたもの。工程２０７参照）を読み出す。このカード識別データは、工程３０１においてカードから読み出される。端末は、カードに対して「識別データ獲得」コマンドを有効に送り、カードは識別データを端末に返信する。
【００２８】
ＰＢは、典型的には一組のカードを同時にプロセスし、個人登録される一組のカードのＩＣカード識別データのリストを最初にコンパイルする。次に、ＰＢはこの識別データのリストを、各カード識別子ごとの個人登録（またはイネーブルメント）データブロックを作成する証明機構（「ＣＡ」）に、電気的に（または他の方法で）送る。データブロックは、以下に説明するカードのための多数の識別フィールドおよび個々のキーセットに組み込まれているカード個人登録データを含む。次に、これらのデータブロックは暗号化され、工程３０２においてＰＢに送られる。次にＰＢは、カード識別データを用いることにより、暗号化されたデータブロックとカードを照合し、一致したカードに各データブロックを個別にロードする。カードの同一性およびシステムの完全性がＣＡによって制御されることを確実にするために、ＰＢは転送されるデータブロック内容の知識を決して獲得しない。カードの発行者によって、その発行するカードの好適な管理に影響を及ぼすために、個人登録のいくつかの要点（aspects）がＣＡに要求される。以下の追加の工程が実行される。
【００２９】
工程３０３では、カードのＥＥＰＲＯＭに記憶されたイネーブルメントビットがすでにセットされているかどうかを最初に確認する。すでにビットがセットされていれば、カードはすでに設定および個人登録されており、工程３０４に示すようにイネーブルメントプロセスは終了する。カードは二度、イネーブルメントおよび個人登録され得ない。ビットが個人登録されていない場合、プロセスは工程３０５に続く。
【００３０】
工程３０５では、カードをイネーブルメントするための個別化されたカードキーセット（キーセットはＣＡで作成される）がカードに記憶される。後にこのキーは、オフカード検証（すなわちカードが正真のカードであるかどうかを検証すること）に利用し得る。この検証は、そのカードを、そのアプリケーションの対象として意図されたカードとしてさらに認証するために必要である。
【００３１】
工程３０７では、ＣＡにおいて、そのカードについて４つの異なるＭＵＬＴＯＳ安全管理（ＭＳＭ）特性データ要素（本明細書では個人登録データとも呼ばれる）を作成する。これらのデータ要素は、安全かつ正確に特定のカードに対してアプリケーションをロードおよび削除するのに用いられる。ＭＳＭ特性はまた、識別されたカードの特定のクラスに、アプリケーションをロードできるようにする（これらのＭＳＭ特性は、図５に関連してさらに説明する）。
【００３２】
この時点で、アドレステーブルやさらなるサブルーチンなどのシステム設計による必要に応じた他のデータも記憶され得る。
【００３３】
工程３１１では、特定のカードに対してイネーブルメントプロセスが終了したことを示すイネーブルメントビットをカードのＥＥＰＲＯＭにセットする。このビットがセットされると、そのカードに対して別のイネーブルメントプロセスは起こり得ない。これにより、カードに対して一回のみの個人登録およびイネーブルメントしか起こらないことが確実となるので、カードを違法に改変したり、誤ってカードの内容を変更してしまうことを防ぐ。好適な実施形態では、イネーブルメントビットは、カードが製造されるときに最初からセットされておらず、イネーブルメントプロセスの終了時にセットされる。
【００３４】
図４は、製造および個人登録中のＩＣカードチップのブロック図の例を示す。ＩＣカードチップは使用されるＩＣカード上に配置されている。ＩＣカードは、好ましくは、中央演算処理装置４０１、ＲＡＭ４０３、ＥＥＰＲＯＭ４０５、ＲＯＭ４０７、タイマー４０９、制御ロジック４１１、Ｉ／Ｏポート４１３、およびセキュリティ回路４１５を含み、これらが従来のデータバスで互いに接続されている。
【００３５】
メモリカードの制御ロジック４１１は、入力／出力ポートを介した読み出し−書き込みアクセスを処理するための十分なシーケンスとスイッチングを提供する。制御ロジックを有するＣＰＵ４０１は、演算を実行し、メモリ位置にアクセスし、メモリ内容を変更し、入力／出力ポートを管理する。いくつかのカードは、暗号化アルゴリズムのような複雑な演算を処理するための、コプロセッサを有する。入力／出力ポート４１３は、ＣＰＵおよび制御ロジックの制御下で用いられ、カードとカード受け入れデバイス間の通信を行う。（クロックパルスを生成し供給する）タイマー４０９は、メモリアクセス、メモリ読み出しまたは書き込み、処理、およびデータ通信を達成する一連の工程を介して、制御ロジック４１１およびＣＰＵ４０１を駆動する。タイマーは、呼び出し持続時間などのアプリケーションの特徴を供給するのに用いられ得る。セキュリティ回路４１５は、製造中におけるテストの必要に応じて、入力／出力配線を内部回路に接続する可融性の（fusible）接続を含んでいるが、この回路はテストの完了時に、その後のアクセスを防ぐために壊す（「破壊する」）。カードをに資格を与える個人登録データは、ＥＥＰＲＯＭ４０５中の安全な位置に記憶されている。個人登録データとアプリケーション許可データとの比較は、ＣＰＵ４０１が行う。
【００３６】
図５は、カード個人登録の４要素を作成してＩＣカードのメモリ内にロードする工程を示しており、図５Ａは、本発明による個人登録データを含むＩＣカードのメモリに常駐する各識別フィールドのためのビットマップ概略図を示す。各識別フィールドのための各データ構造は、固有の記述子コードを有する。工程５０１では、「ｍｓｍ＿ｍｃｄ＿ｐｅｒｍｉｓｓｉｏｎｓ＿ｍｃｄ＿ｎｏ」
と呼ばれる識別フィールド「カードＩＤ」のためのデータ構造をロードする。この名前は、ＭＵＬＴＯＳシステムマネジャー＿ＭＵＬＴＯＳカードデバイス＿パーミッション＿ＭＵＬＴＯＳカードデバイス番号を表している。図５Ａに示すように、この番号は典型的には８バイト長を有するが、データはカードの特定の番号を示すいかなる長さでもよい。好適な実施形態では、２バイトが一個のインジケータに当てられ、２バイトがカード製造時にどのセキュリティモジュールがカードとともにインジェクトされるかを示すＭＵＬＴＯＳインジェクションセキュリティモジュールＩＤ（ＭＩＳＭ  ＩＤ）であり、４バイトが、特定のＭＩＳＭにおいて製造される個々のカードを識別する集積回路カード（ＩＣＣ）シリアル番号を含む。
【００３７】
工程５０３では、「ｍｓｍ＿ｍｃｄ＿ｐｅｒｍｉｓｓｉｏｎｓ＿ｍｃｄ＿ｉｓｓｕｅｒ＿ｉｄ」と呼ばれる識別フィールド「発行者ＩＤ」のためのデータ構造がロードされる。この名前は、ＭＵＬＴＯＳカードデバイス発行者識別番号を表す。各カード発行者（特定の銀行、金融機関またはアプリケーションに関わる他の企業など）には、そのカードシステムの特定の番号が割り当てられる。ＭＵＬＴＯＳシステムの各ＩＣカードは、カードを個人登録した、またはカードに責任を持つカード発行者に関する情報を含んでいる。カード発行者は、製造業者に所定枚数のカードを注文し、本明細書に記載する個人登録プロセスを自ら行うか、もしくはこれを行わせる。例えば、地方銀行は、顧客に配布するために５，０００枚のカードを発注し得る。これらのカードの「ｍｃｄ＿ｉｓｓｕｅｒ＿ｉｄ」データ構造は、いずれの発行者がカードを発行したのかを示している。好適な実施形態では、そのシステム内に多くの異なる発行者が存在することを可能にするためにデータ構造は４バイト長であるが、データ構造の長さはカードシステムの必要に応じて異なり得る。
【００３８】
工程５０５では、「ｍｓｍ＿ｍｃｄ＿ｐｅｒｍｉｓｓｉｏｎｓ＿ｍｃｄ＿ｉｓｓｕｅｒ＿ｐｒｏｄｕｃｔ＿ｉｄ」と呼ばれる識別フィールド「製品ＩＤ」のためのデータ構造がロードされる。この名前は、ＭＵＬＴＯＳカードデバイス発行者製品識別番号を表す。各カード発行者は、異なった複数のクラスの製品またはカードを区別したいと考えるかもしれない。例えば、銀行はある製品ＩＤで一般のクレジットカードを、別の製品ＩＤでゴールドクレジットカードを、さらに別の製品ＩＤでプラチナカードを発行することができる。カードの発行者は、あるクラスのクレジットカードのみに所定のアプリケーションをロードしたいと考えるかもしれない。年会費を支払うゴールドクレジットカードのユーザは、年会費を支払わない一般クレジットカードのユーザより幅広い種類のアプリケーションを提供され得る。製品ＩＤフィールドは、カードを特定のクラスと見なし、後にカードの発行者が製品ＩＤをチェックし、所望のクラスに一致するアプリケーションのみをカードにロードするのを可能にする。
【００３９】
製品を区別する別の方法は、アプリケーションを金融、法律、医療および／または娯楽に分類するなどのアプリケーションタイプによるもの、または一組のカードに特定のアプリケーションを割り当てるものである。例えば、あるカード発行者は、異なる企業で異なる組のカードユーザに対して、異なるロイヤルティプログラムを用意し得る。例えば、銀行は、航空会社がどこを飛んでいるかによって異なる地域のために、Ａｍｅｒｉｃａｎ  Ａｉｒｌｉｎｅ(R)ロイヤルティプログラムおよびＢｒｉｔｉｓｈ  Ａｉｒｗａｙｓ(R)ロイヤルティプログラムを有し得る。製品タイプにより、発行者は個人登録プロセスにおいて製品分類を修正できる。カードにアプリケーションをロードするときは、各カードの製品タイプ識別番号を、発行者がロードを望んでいるカードのタイプと一致するかを確かめるためにチェックする。製品タイプデータ構造は、（他の個人登録データ構造とは異なり）好適には（図５Ａの５０５Ａに示すように）８ビットの索引機構であるが、カードシステムの必要に応じていかなる長さでもあり得る。図示した実施形態では、結果としての命令は、検索されるべきアレイ内の第２のビット（バイトの指示値が２なので）の位置を特定することであり得る（後述の工程８０９の説明参照）。
【００４０】
工程５０７では、「ｍｓｍ＿ｍｃｄ＿ｐｅｒｍｉｓｓｉｏｎｓ＿ｍｃｄ＿ｃｏｎｔｒｏｌｓ＿ｄａｔａ＿ｄａｔｅ」と呼ばれる識別フィールドデータのためのデータ構造がロードされる。この名前は、ＭＵＬＴＯＳカードデバイスが日付データを制御することを表している。日付データとは、換言すれば、例えばアプリケーションローダーが、特定の日付より後の日付を持つカードをロードしたり、（例えば、アプリケーションの更新のために）特定の日付より前の日付を持つカードをロードしたり、または、特定のデータ日付を持つカードをロードすることができるようにカードを個人登録した日付である。この情報には、個人登録の年月日を含むことができるが、所望であればより少ない情報を含み得る。データ＿日付データ構造は、好適には１バイト長（図５Ａの５０７Ａ参照）であるが、用いられる特定のカードシステムの必要に応じていかなる長さでもよい。
【００４１】
ひとたびすべての個人登録データ構造が、カードにロードされ記憶されれば、発行者、製品クラス、日付および識別番号（および所望であれば他のデータフィールド）により識別されたことになり、カードはその同一性を変更でない。これらのフィールドはカードのメモリ内では変更できない。カード識別が、別の製品タイプを利用できる異なったアプリケーションにアクセスを得るために、カードに記憶される製品＿ｉｄを変更したいのであれば、正しい個人登録データを含んだ新しいカードがユーザに発行されなければならない。このシステムは、ゴールドカードの会員が、分類をプラチナカードに変更したときに新しいカードを受け取る場合も一貫している。
【００４２】
図３において説明した個々のカードキーセット、ＭＳＭ個人登録特性、およびイネーブルメントビットを記憶させることで、カードがイネーブルメントされ個人登録された後で、カードはそのメモリにアプリケーションをロードする準備が整う。
【００４３】
アプリケーションのローディング
アプリケーションのローディングプロセスは、対象となるＩＣカードへのアプリケーションの安全かつ適切なローディングを確実にするために、多くのセキュリティおよびカード構成を含む。アプリケーションのローディングプロセスは、好適には個人登録事務局で実行され、それによりカードは発行時に一つ以上のアプリケーションを含む。カードには、電子パースアプリケーションまたはクレジット／デットアプリケーションなど、発行者が発送した各カードに存在する所定の共通アプリケーションを含み得る。これに代えて、個人登録事務局が、アプリケーションのローディングプロセスのために、イネーブルメントされたカードを第三者に送付し得る。各カードのＲＯＭに記憶されている複数のアプリケーションで使用可能なシステムおよびカードのＭＳＭ個人登録データは、特定のカードユーザおよびカードに責任を有する発行者の要求により、カードが発行された後での将来のローディングおよび削除が可能であるよう設計されている。従って、ＩＣカードに記憶されたアプリケーションの古いバージョンは、アプリケーションの新しいバージョンと置き換え可能である。追加のローヤリティアプリケーションも、アプリケーションが新しく利用できるようになったか、またはユーザが新しいアプリケーションの使用を欲したかの理由により、カードユーザに最初に送付された後でカードに追加でき得る。アプリケーションのこれらのローディングと削除の機能は、端末で直接実行できるか、または電話回線、データ回線、インターネットのようなネットワーク、または２つのエンティティ間のその他のいかなるデータ転送手段を介しても実行し得る。現在のＩＣカードシステムにおいて、アプリケーションプログラムおよびデータの転送プロセスは、適切な個人登録データを含み、アプリケーション許可のプロファイルに適合するＩＣカードのみが適格であり、対応するアプリケーションデータおよびプログラムを受け取ることを保証する。  
【００４４】
図６は、ＭＵＬＴＯＳ  ＩＣカードシステムにおいてＩＣカードにアプリケーションをロードする際に行われる好適な工程を示す。この実施例の場合、個人登録事務局（personalization  bureau）は、同じカードをイネーブルした端末からアプリケーションをロードしている。工程６０１で、端末により開始される「オープンコマンド」を行い、端末は、カードをプレビューして、カードに特定のアプリケーションのロードを受け入れるのに適していることを確かめる。オープンコマンドは、カードに、アプリケーション許可データ、即ち、アプリケーションのサイズを与え、カードに、以下のことを判定するように指示する。即ち、（１）カードが個人登録されている事を示すイネーブルメントビット（enablement  bit）がセットされたかどうか、（２）アプリケーションコードおよび関連データがカード上の既存のメモリ空間に適合するかどうか、および、（３）ロードされるアプリケーションに割り当てられた個人登録データが、問題の特定のカードへのアプリケーションのロードを可能にするかどうか、を判定するように指示する。オープンコマンドはまた、カードシステムによる必要に応じて、追加のチェックを行い得る。オープンコマンド実行中のこれらのチェック工程は、図７に関して詳細に説明される。
【００４５】
オープンコマンドが実行された後、端末を介するアプリケーションローダには、カードが適切な識別個人登録データを含むかどうか、および、カードのメモリ内にアプリケーションコードおよび関連データのための十分な空きがあるかどうかが知らされる。もしメモリが不十分であれば、カードから否定応答が戻され、プロセスはアベンドされる（abend）（異常終了される）。もし識別個人登録データがアプリケーション許可データと一致しなければ、工程６０３で警告応答が与えられるが、プロセスは、ロードおよび作成工程に続く。あるいは、もし一致がなければ、プロセスは自動的にアベンドされ得る。工程６０５でカードから端末に肯定応答が戻されると、アプリケーションローダは、好ましくは、次の工程に進む。オープンコマンドは、コードおよびデータのいかなる転送が始まる前にも、アプリケーションがカードをプレビューすることを可能にする。
【００４６】
次いで、工程６０７で、アプリケーションコードおよびデータを、ＩＣカード上のＥＥＰＲＯＭにロードする。実際のロードは、作成工程６０９とともに起こり、工程６０９は、ロードプロセスを完了し、アプリケーションがロードされた後に、アプリケーションがＩＣカード上で実行されることを可能にする。オープン、ロード、および作成コマンドの組み合わせは、アプリケーションロードプロセスを行うために、端末または別のアプリケーションプロバイダソースにより、ＩＣカードに送られる。ＩＣカード内のオペレーティングシステムは、これらのコマンドの各々に関して特定の命令セットを実行するようにプログラムされ、それにより、ＩＣカードは、端末と通信し、且つ、端末からの命令を適切に実行する。
【００４７】
工程６０９で、少なくとも以下のことを行う作成コマンドを実行する。（１）アプリケーションロード証明がＣＡにより署名（暗号化）されるかどうかをチェックし、従って、アプリケーションを、システムのための適切なアプリケーションとして認証する、および、（２）カードをロードに適したものにするために、カードに記憶されたカード個人登録データを、ロードされるアプリケーションについての許可プロファイルと照合することをチェックする。作成コマンドは、必要に応じて、その他のチェックも行い得る。これらのチェックのうちの１つが失敗すると、失敗応答６１０が与えられ、プロセスが中止される。これらのチェックをパスした後、アプリケーションは、カードのメモリにロードされる。
【００４８】
図７は、図６のオープン工程６０１の様々な工程をより詳細に示す。工程７０１で、イネーブルメント（即ち、制御）ビットがセットされるかどうかを判定する。このビットは、カードがその個人登録プロセスを完了し、且つ、カードにその個人登録データが割り当てられたときに、セットされる。アプリケーションは、カードが個人登録データを含んでいる場合にのみ、カードシステムにおいてＩＣカードにロードされ得る。イネーブルメントビットがセットされない場合、カードは個人登録されておらず、従って、カードは、端末に否定応答７０３を戻す。イネーブルメントビットがセットされる場合、カードはイネーブルされており、テスト条件は工程７１１に続く。
【００４９】
工程７１１で、カード上のメモリに、アプリケーションコードおよびその関連データを記憶するための十分な空間があるかどうかをチェックする。アプリケーションは、典型的には、アプリケーションの関数に関する関連データを有する。このデータは、アプリケーションが実行されるときに使用され且つ操作される。ＥＥＰＲＯＭに必要とされる比較的大きな物理的空間と、クレジットカードサイズのカード上に適合するのに十分に小さいことが望まれる集積回路内にこの物理的空間がどのように適合するのか、という点とのため、ＩＣカードのメモリ内の記憶空間は、継続して問題となっている。ＩＣカード上のプリセットＥＥＰＲＯＭのサイズの例は１６Ｋバイトであるが、実際のサイズは様々である。アプリケーションは、非常に単純なアプリケーションの場合の１Ｋバイト以下から、より高度なアプリケーションの場合の利用可能なメモリのサイズまでの範囲にわたり得る。アプリケーションに関連するデータは、カードメモリにデータが記憶されない場合から、利用可能なメモリの量により制約されるサイズまでの範囲にわたり得る。アプリケーションコードおよびデータのこのような様々なサイズは、アプリケーションがより進歩し且つより多様になるに従って、絶えず増大する。
【００５０】
オペレーティングシステムとしてのＭＵＬＴＯＳは、ＭＵＬＴＯＳがカードに記憶し得るアプリケーションおよび関連データの数により制限されない。従って、５つのアプリケーションがカードの利用可能なメモリ内に適合し得る場合、カードユーザは、１つまたは２つのアプリケーションがカードに記憶された場合よりも、大幅に増加した機能を有する。しかし、一旦カードのメモリがその容量まで満たされると、コードと十分なサイズのデータとを含む別のアプリケーションを削除することができない限り、新しいアプリケーションをカードにロードすることはできない。従って、カード上の利用可能な空間量をチェックすることは、重要な工程である。十分な空間がなければ、空間不足応答７１３が端末に戻される。次いで、アプリケーションローダは、新しいアプリケーションのための空きを作るためにカード上の別の既存のアプリケーションが削除されるべきかどうかを判定し得る。削除は、ＣＡからのアプリケーション削除証明を有するカード発行者に依存する。カード上に十分な空間がある場合、プロセスは工程７１５に続く。
【００５１】
ここで、工程７１１におけるメモリ空間のテストの実施例について説明する。この実施例で使用される数値は、発明の範囲をいかなる方法でも制限するものではなく、メモリ空間についての要求を例示しているにすぎない。ＩＣカードは、最初に製造されるとき、１６Ｋの利用可能なＥＥＰＲＯＭを有し得る。オペレーティングシステムに必要なオペレーティングシステムデータは、２Ｋのメモリ空間をとり得る。従って、１４Ｋが残る。電子パースアプリケーションのコードはＥＥＰＲＯＭに記憶され、８Ｋのメモリ空間をとり得る。パースアプリケーションの、必要とされるデータは、ＥＥＰＲＯＭ内のさらなる４Ｋのメモリ空間をとり得る。従って、他のアプリケーションのために空いているメモリ空間は、２Ｋ（１６Ｋ−２Ｋ−８Ｋ−４Ｋ＝２Ｋ）である。カード発行者が、コードのサイズが６Ｋバイトであるクレジット／デビットアプリケーションを、本実施例のカードにロードしたい場合、このアプリケーションは、ＩＣカードのメモリ内に適合しない。従って、カードからまずパースアプリケーションを取り除かなければ、アプリケーションは、新しいアプリケーションをロードすることができない。新しいクレジット／デビットアプリケーションをＩＣカードのＥＥＰＲＯＭ内にロードする場合、この新しいクレジット／デビットアプリケーションを、他のアプリケーションのコードまたはデータに上書きしなければならない。アプリケーションローダは、これを行わないようにされる。
【００５２】
図８は、カードの個人登録データが、アプリケーションがロードされ得るカードの許可可能な組の中に、カードの個人登録データがあるかどうか判定する際に行われる工程を示す。これらの工程は、好ましくは、「作成」コマンドの実行中に行われる。しかし、これらの工程は、アプリケーションのロードまたは削除の間いつでも行われ得る。以前に説明されたように、カードは、カードに固有のデータ（ＭＳＭ個人登録データ）を記憶することにより個人登録される。カードに固有のデータには、個々のカードに固有のカードＩＤ名称、カードの発行者を示すカード発行者番号、ゴールドまたはプラチナカードなどのカードの製品タイプ、および、カードが個人登録された日付、などがある。このデータは、システム内の他のすべてのＩＣカードとは別に、カードを一意的に識別する。
【００５３】
従って、アプリケーションは、ＩＣカードシステムにおいて、以下に示すような基準を含む実質的に任意の基準で、個々のカードに選択的に記憶され得る。アプリケーションは、１つ以上の特定のカード番号を含むカードに選択的にロードされ得る。アプリケーションは、特定のカード発行者ＩＤを含む１つ以上のカードに選択的にロードされ得る。さらに、アプリケーションは、特定のカード発行者により特定される１つの製品タイプにのみロードされ得、および／または、アプリケーションは、個人登録の特定の日付または日付の連続を有するカードにのみロードされ得る。個人登録データの各々は、アプリケーションが、ある特定のカード、またはカードのグループに、選択的にロードされることを可能にし、また、適切な許可のないカードがアプリケーションを受け取らないことを確実にする。上記４つに追加して、個人登録データタイプもまた、必要に応じて使用され得る。
【００５４】
特定のアプリケーションがロードされ得るＩＣカードの選択は、「アプリケーション許可データ」の使用により可能にされる。「アプリケーション許可データ」は、アプリケーションに割り当てられ、アプリケーションがロードされ得るカードの少なくとも１つの組を表す。この組は、カード番号、カード発行者、製品タイプ、または個人登録データ、などの１つ以上を含む実質的にいかなるファクタにも基づき得る。個々のカードの個人登録データは、典型的には、１つの特定の番号、１つのカード発行者、１つの製品タイプ、および一つの日付を識別するが、アプリケーションの許可データは、カード番号または一括許可（blanket  permission）、カード発行者または一括許可、ならびに、多数の製品タイプおよび日付を示し得る。
【００５５】
例えば、フリークエントロイヤルティプログラム（frequent  loyalty  program）は、１つのカード発行者に属する異なる製品分類のカードへのロードと、これらのカード上での使用とを可能にするように構成され得る。さらに、アプリケーション許可データは、カードが１９９８年５月よりも後に発行されている場合、ロイヤルティプログラムがゴールドおよびプラチナ製品タイプ上で使用され得ることを示し得る。従って、ＭＳＭ許可チェックは、カードの個々の個人登録データが、アプリケーションがロードされ得るカードの許可された組または許可可能な組に含まれるかどうかを判定する。含まれる場合、アプリケーションはロードされる。
【００５６】
比較プロセスを促進するために、別の実施形態は、１つ以上の許可データを、その特定のデータの一括許可を表すゼロで設定する工程を含み得る。例えば、アプリケーション許可データ中の「カード番号」エントリをゼロにするか、または、すべてのカードがそれらの番号に関わらずロードされ得ることを示す他の何らかの値にすることにより、システムは、いかなるカードもカード番号に基づいて拒絶しないことを知る。さらに、アプリケーションの許可データ「発行者ＩＤ」がゼロにされると、すべてのカードは同様に「発行者」テスト比較をパスする。この特徴は、カードのグループを選択する際により大きい柔軟性を可能にする。ゼロインジケータは、必要に応じて、他の許可データにも使用され得る。
【００５７】
図８を参照して、許可データの各々は、示される順序でチェックされるが、他の順序に従ってもよい。なぜなら、許可のいずれか１つが失敗すれば、アプリケーションは、チェックされているＩＣカードにロードされないようにされるからである。許可は、好ましくは、示される順序でチェックされる。工程８０１で、アプリケーション許可製品タイプセットが、カードのメモリに記憶された、カードの製品タイプ番号を含むかどうかをチェックする。各々のカード製品タイプには、システムオペレータにより番号が割り当てられる。異なるカード発行者は異なる製品タイプを有するため、製品タイプは、各々のカード発行者について特定される。認証された製品タイプのカードにのみアプリケーションがロードされることを確実にするために、カードは選択的にチェックされる。アプリケーション許可製品タイプセットは、多数の受け入れ可能な製品タイプを含む３２バイト長であり得、または、システムの要求に依存して異なる長さであり得る。データ構造５０５Ａを例として用いると、オペレーティングシステムは、３２バイト長アプリケーション許可データ構造から得られる２５６ビットアレイ（３２バイト×８ビット／バイト）中のビット番号２をチェックする。許可チェックが失敗すれば、工程８０３で、カードは、端末に失敗メッセージを戻す。製品タイプチェックがパスすると（例えば、ビット番号２の値が１である）、プロセスは工程８０５に続く。
【００５８】
工程８０５で、アプリケーション許可により許容可能なカード発行者番号セットが、カードのメモリに記憶される、カードの発行者番号を含むかどうか、または、アプリケーション許可発行者データがゼロ（すべてのカードがこの個々の許可チェックをパスすることを示す）であるかどうかをチェックする。各カード発行者には、システムオペレータにより番号が割り当てられ、認証されたカード発行者により配布されたカードにのみアプリケーションがロードされることを確実にするために、カードは選択的にチェックされる。アプリケーション許可カード発行者番号セットは、１つの発行者が指定されていれば４バイト長であり得る。あるいは、システムの要求に依存して、それより長くてもよい。発行者チェックが失敗すれば、工程８０７で、カードは、端末に失敗メッセージを戻す。チェックがパスすれば、プロセスは工程８０９に続く。
【００５９】
工程８０９で、アプリケーション許可日付セットが、カードのメモリに記憶された、カードのデータ日付を含むかどうかをチェックする。ＩＣカードが個人登録された日付は、記憶され、好ましくは、少なくとも月および年を含む。認証された個人登録日付を有するカードにのみアプリケーションがロードされることを確実にするために、カードは選択的にチェックされる。アプリケーション許可日付セットは、多数の日付を含む３２バイト長であり得る。あるいは、システムの要求に依存して、異なる長さであってもよい。日付許可チェックが失敗すれば、工程８１１で、カードは、端末に失敗メッセージを戻す。日付チェックがパスすれば、プロセスは工程８１３に続く。
【００６０】
工程８１３で、アプリケーション許可により許容可能なカード番号セットが、カードメモリに記憶された、カードのＩＤ番号を含むかどうか、または、アプリケーション許可により許容可能なカード番号データがゼロ（すべてのカードがこの個々の許可チェックをパスすることを示す）であるかどうかをチェックする。許可のテストは、オープン、ロード、および作成コマンドの実行中に、カードに対して行われる。アプリケーション許可カード番号データセットは、１つの番号が指定される場合には８バイト長であり得る。あるいは、システムの要求に依存して、それより長くてもよい。カード番号チェックが失敗すれば、工程８１５で、カードは、端末に失敗メッセージを戻す。チェックがパスすれば、プロセスは工程８１７に続く。
【００６１】
ＩＣカードシステムのプロセスの要旨
図９は、安全なマルチアプリケーションＩＣカードシステムにおけるＩＣカードのカード初期化プロセスのためのシステムアーキテクチャの構成要素を示す。システムは、カード製造業者１０２、個人登録事務局１０４、アプリケーションローダ１０６、初期化されているＩＣカード１０７、カードユーザ１０９、およびマルチアプリケーション安全システム全体についての証明機構（certification  authority）１１１を含む。カードユーザ１３１は、ＩＣカード上の記憶されたアプリケーションを使用する人またはエンティティである。例えば、カードユーザは、同じＩＣカードに、電子キャッシュ（MONDEXＴＭなど）を含む電子パースと、クレジット／デビットアプリケーション（MasterCard(R)ＥＭＶアプリケーションなど）との両方を含むＩＣカードを望んでもよい。以下の説明は、カードユーザが、安全な態様で、所望のアプリケーションを含むＩＣカードを得る１つの方法についての説明である。
【００６２】
カードユーザは、ＩＣカードを配布する銀行などのカード発行者１１３に連絡して、単一のＩＣカードのメモリ内に２つのアプリケーションの両方を有するＩＣカードを要求する。ＩＣカードの集積回路チップは、製造業者１０２により製造され、カード上のＩＣチップの形態で、カード発行者１１３（または、カード発行者のために行動するエンティティ）に送られる。上記のように（工程２０１〜２０９参照）、製造プロセスの間、データは、１１５で、製造業者１０２からデータコンジットを介してカード１０７に送られ、ＩＣカード１０７のメモリに記憶される。（この図において示されたデータコンジットのいずれも、電話線、インターネット接続、または他の任意の伝達媒体であり得る。）システム全体のための暗号化／解読キーを維持する証明機構１１１は、１１７で、データコンジットを介して、製造業者にセキュリティデータ（即ち、グローバル公開キー）を送る。このセキュリティデータは、製造業者により、カードイネーブルメントキーおよびカード識別子などの他のデータとともに、カード上に置かれる。カードのマルチアプリケーションオペレーティングシステムもまた、ＲＯＭに記憶され、製造者によりカード上に置かれる。カードは、最初に処理された後、個人登録およびアプリケーションロードのために、カード発行者に送られる。
【００６３】
カード発行者１１３は、別のエンティティにより２つの別個の機能を実行する。あるいは、カード発行者１１３は、別のエンティティにより、これらの２つの別個の機能を既に実行している。まず、個人登録事務局１０４が、上記の方法でＩＣカード１０７を個人登録し、第２に、上記のように、カードがアプリケーションのロードに適したものであれば、アプリケーションローダ１０６が、アプリケーションをロードする。
【００６４】
個人登録に関して、個別化されたカードキーセットが、ＣＡにより生成され、カードに記憶される（図３参照）。カードにはさらに、ＭＳＭ個人登録を用いて（図３の工程３０７および図５参照）、特定の識別が与えられる。この特定の識別には、カードＩＤ番号、カードを処理したカード発行者を識別する発行者ＩＤ番号、カード発行者により特定されるカード製品タイプ番号、および個人登録が起こった日付、などがある。カードが個人登録された後、カードが所望の機能を実行し得るように、カードにアプリケーションをロードする必要がある。
【００６５】
個人登録事務局１０４と同じ端末またはデータコンジットを使用し得るアプリケーションローダ１０６はまず、カードがアプリケーションを受け入れるのに適しているかどうかを判定していなければならない。この比較プロセスは、許可情報を用いて、（カードのオペレーティングシステムによる指示に従って）カード自体の上で起こる。従って、カードがアプリケーションを受け入れるのに適していれば、カードは、カードの識別およびカード発行者の指示に基づいて、カード自体にアプリケーションを選択的にロードする。アプリケーションローダは、１１９で、端末を介して、または、他の何らかのデータコンジットにより、ＩＣカードと通信する。アプリケーションがカードにロードされた後、カードは、使用ためにカードユーザ１０９に送達される。
【００６６】
本明細書において説明される安全なマルチアプリケーションＩＣカードシステムは、カードが個人登録された後、ＩＣカードのライフサイクルのいかなる時点でも、アプリケーションの選択的なロードおよび削除を可能にする。従って、カードユーザはまた、アプリケーションを有していない個人登録されたカードを受け取り得、その後に、電話線またはインターネット接続などの共通送信線を介して、所望のアプリケーションを選択し得る。
【００６７】
図１０は、ＩＣカードが個人登録された後のＩＣカードの使用に関わるエンティティのシステム図である。システムは、ＩＣカード１５１、端末１５３、アプリケーションロード／削除エンティティ１５５、証明機構１５７、カード発行者１７１、およびシステム内の他のＩＣカード１５９を含む。矢印は、それぞれのエンティティ間の通信を示す。ＣＡ１５７は、アプリケーションのロードおよび削除を容易にする。カードイネーブルの間に、ＭＳＭ許可データと、カードに固有のキーセットとをカードに与えた後、ＣＡは、好ましくはアプリケーション証明を発行することにより、アプリケーションが後にロードおよび削除されることを可能にする。アプリケーションに固有のキーは、カードと端末との間の通信を認証するために必要とされる。ＩＣカード１５１はまた、他のＩＣカード１５９と通信し得る。カード発行者１７１は、カード発行者１７１が発行したカードについてのアプリケーションのロードおよび削除のすべての決定に関わる。すべての通信は認証され、システム内で確実に送信される。
【００６８】
例えば、ＩＣカード１５１は、下記の手順を用いて、カードに新しいアプリケーションをロードする。ＩＣカード１０１は、端末１５３と接続され、端末は、アプリケーションがロードされるよう要求する。端末１５３は、アプリケーションロード／削除エンティティ１５５に連絡し、アプリケーションロード／削除エンティティ１５５は、その結果、カード発行者１７１とともに、アプリケーションコード、データ、およびアプリケーション許可データを（他の任意の必要なデータとともに）端末１５３に送る。次いで、端末１５３は、カード１５１について問い合わせをして、このカード１５１が、アプリケーションがロードされ得る正しいカードであることを確実にする。ＩＣカードが上記のチェックをパスすれば、カード１５１にアプリケーションがロードされる。ＣＡ１５７は、アプリケーションがカードにロードされるまたはカードから削除されることを可能にする、アプリケーションロードまたは削除証明を提供する。本実施例は、アプリケーションをロードする１つの方法を示しているが、アプリケーションロード／削除エンティティ１５５でアプリケーションを直接ロードするなど、同じ原理を用いた他の変形が行われてもよい。
【００６９】
以上の説明は、単に本発明の原理を示しているだけである。従って、当業者が、本発明の原理を実施する多くのシステムおよび方法であって、従って、本発明の精神および範囲内にある多くのシステムおよび方法を考案し得ることが認識されるが、これらのシステムおよび方法は、本明細書には、明確には図示または説明されていない。
【００７０】
例えば、ＭＳＭ個人登録および許可データは、ＩＣカードにアプリケーションをロードするためだけでなく、カードからアプリケーションを削除するためにも使用され得ることが認識される。ＭＳＭ許可およびアプリケーションのロードを含む、同じチェックが、アプリケーションの削除についても行われる。アプリケーションの削除を認可するＣＡからの削除証明は、どのカードからアプリケーションが削除され得るかを制御する。これは、各ＩＣカードに記憶された個人登録データ、および、本明細書において説明される許可チェックにより達成される。
【００７１】
さらに、データはまた、カードに物理的にロードされないアプリケーションがロードされ得る、パーソナルコンピューターまたは他のユニットにも応用され得る。加えて、アプリケーションの許可データは、実際には、含まれるのではなく除外されるカードの単数または複数の組、即ち、アプリケーションをロードすることができないカードの単数または複数の組を表すデータを含み得る。
【００７２】
本開示の範囲は、請求された発明に関係するものであるかどうか、または、本発明により取り組まれた問題点のいずれかまたはすべてを軽減するものであるかどうかに関係なく本明細書に明確にまたは暗に開示されたいかなる新規な特徴もしくは特徴の組み合わせ、または、その何らかの一般化を含む。これにより、出願人は、本願の審査中、または、本願から派生するいかなる別の出願の審査中にも、そのような特徴に対して新しい請求の範囲が作られ得ることを示す。特に、添付の請求の範囲を参照して、従属項からの特徴は、請求の範囲に示された特定の組み合わせだけではなく、独立項の特徴と任意の態様で組み合わせられてもよい。
【図面の簡単な説明】
【００７３】
【図１】図１は、保証されたシステムにおける複数アプリケーションICカードの存続期間の３つの段階を示すブロック図である。
【図２】図２は、カード製造プロセスの工程を示すブロック図である。
【図３】図３は、保証されたシステム内における各ICカードの認可に含まれる工程を示す流れ図である。
【図４】図４は、発明の実施態様に従って使用され得るICカードチップのブロック図である。
【図５】図５は、図３のブロック307で示されるようなICカードに記憶されたデータを表すブロック図である。
【図５Ａ】図5Aは、ICカードに属するデータ構造及び個人登録データを表す概略図である。
【図６】図６は、保証されたシステム内でICカードにアプリケーションをロードする工程を示すフローチャートである。
【図７】図７は、図６のブロック601で示されるような検査工程を示すフローチャートである。
【図８】図８は、アプリケーションのロードを行ってもよいかどうかを判断する場合に実行される工程を示したフローチャートである。
【図９】図９は、保証されたマルチアプリケーションICカードシステムにおけるICカードの認可プロセスのためのシステムアーキテクチャを示すブロック図である。
【図１０】図10は、いったん個人登録されたICカードの利用において必要とされるエンティティを示すシステム図である。
【図１】
0004405568.tif 000002
【図２】
0004405568.tif 000003
【図３】
0004405568.tif 000004
【図４】
0004405568.tif 000005
【図５】
0004405568.tif 000006
【図５Ａ】
0004405568.tif 000007
【図６】
0004405568.tif 000008
【図７】
0004405568.tif 000009
【図８】
0004405568.tif 000010
【図９】
0004405568.tif 000011
【図１０】
0004405568.tif 000012