JP2002512715A - 安全なマルチアプリケーションカードシステムおよびプロセス - Google Patents

Abstract

(57)【要約】 証明機関およびパーソナル化機関を用いた、安全なローディングおよび削除能力を有する、安全なマルチアプリケーションカードシステムおよびプロセスが提供される。証明機関は、ＩＣカードにその公開鍵および各カードをユニークに識別するためのカード識別子が注入されることを要求し、各カードにパーソナル化データブロックを供給し、ＩＣカードにロードされまたは削除される全てのアプリケーションにそのプライベート鍵で署名をすることにより、システムのセキュリティを維持する。

Description

【発明の詳細な説明】 安全なマルチアプリケーションカードシステムおよびプロセス 発明の背景 集積回路（「ＩＣ」）カードは、今日世界中で、多くの異なる目的のためにま すます多く使用されている。ＩＣカード（スマートカードとも呼ばれる）は、典 型的に、従来のクレジットカードの大きさであり、コンピュータチップを有して いる。このコンピュータチップには、マイクロプロセッサ、リードオンリーメモ リ（ＲＯＭ）、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲ ＯＭ）、入力／出力（Ｉ／Ｏ）メカニズム、および、動作中にマイクロプロセッ サをサポートするその他の回路が含まれている。ＩＣカードは、そのメモリ内に 、単一のアプリケーションを有していてもよいし、あるいは、複数の独立したア プリケーションを有していてもよい。ＭＵＬＴＯＳ^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カードデバイス発行者製品識別番号を意味する。各カード発行者 は、それら発行者が区別すること望み得る、異なるクラスの製品またはカードを 有し得る。例えば、銀行は１つの製品ＩＤを備えた通常のクレジットカード、別 の製品ＩＤを備えたゴールドクレジットカード、およびまた別の製品ＩＤを備え たプ ラチナカードを発行し得る。カード発行者は、クレジットカードの１つのクラス のみに所定のアプリケーションをロードすることを望み得る。年会費を支払って いるゴールドクレジットカードユーザは、年会費を支払わっていない通常のクレ ジットカードユーザよりも多様なアプリケーションの権利が与えられ得る。製品 ＩＤフィールドは、特定のクラスとしてカードを識別し、後にカード発行者が製 品ＩＤをチェックし、所望のクラスに一致したカード上にのみアプリケーション をロードすることを可能にする。 製品を区別する別の方法は、アプリケーションタイプによるものである。例え ば、アプリケーションを財政、法的、医学的、および／または娯楽用としてカテ ゴリー化すること、または特定のアプリケーションを一群のカードに割り当てる ことなどである。例えば、１つのカード発行者は、異なる複数の企業から異なる 複数のセットのカードユーザに利用可能な、異なるロイヤリティプログラムを有 し得る。例えば、ある銀行は、飛行機の飛ぶ地域に依存したその国の異なる地域 イヤリティプログラムを有し得る。製品タイプは、発行者がパーソナル化プロセ ス中にカードの製品類別を固定することを可能にする。カード上にアプリケーシ ョンをロードする際、各カード上の製品タイプ識別番号は、発行者がロードする ことを望むカード上のカードタイプと一致していることを確実にするようにチェ ックされる。製品タイプデータ構造は、好ましくは（図５Ａの５０５Ａにおいて 示すように）８ビットの指標機構(indexing mechanism)（従って他のパーソナル 化データ構造とは異なる）であるが、カードシステムのニーズに応じて任意の長 さであり得る。図示する実施形態において、結果として生じる指示は、検索され るアレイ中の第２のビット（バイトの表示値が２であるため）を見つけ出すこと である（以下の工程８０９の説明を参照のこと）。 工程５０７は、データ構造「msm_mcd_permissions_mcd_controls_data_date」 と呼ばれる、アイデンティティフィールドデータ用のデータ構造をロードする。 この用語は、MULTOSカードデバイスがデータ日付を制御することを意味する。こ のデータ日付を言い換えると、例えばアプリケーションローダが、（例えばアプ リケーション更新日のような）任意の日付よりも後の日付のついたカードのみを ロードする、任意の日付よりも前のカードをロードする、あるいは特定のデータ 日付を備えるカードをロードすることができるように、カードがパーソナル化さ れた日付である。この情報は、パーソナル化の年、月、および日を含み得、また は所望であればより少ない情報を含み得る。ｄａｔａ＿ｄａｔｅデータ構造は、 好ましくは１バイトの長さ（図５Ａの５０７Ａを参照のこと）であるが、使用さ れる特定のカードシステムのニーズに応じて任意の長さであり得る。 全てのパーソナル化データ構造が、一旦カード内にロードされ、記憶されると 、カードは発行者、製品クラス、日付および識別番号（および所望であれば、他 のデータフィールド）によりすでに識別されている。そしてカードはそのアイデ ンティティを変更することはできず、よってそれらのフィールドはカードのメモ リ内で変更され得ない。カードユーザが別の製品タイプに利用可能な異なるアプ リケーションへのアクセスを得るために、カード上に記憶されたｐｒｏｄｕｃｔ ｉｄの変更を望む場合には、正しいパーソナル化データを包含する新しいカード がそのユーザに発行されなければならない。このシステムは、類別がプラチナに 変更されたときに、ゴールドカードメンバーが新しいカードを受け取ることと矛 盾していない。 個別のカードの鍵セット、図３に示すようなＭＳＭパーソナル化特性およびイ ネーブル化ビットを記憶することにより、カードがイネーブル化され、パーソナ ル化された後、カードはそのメモリ内へアプリケーションをロードされてもよい 状態になる。アプリケーションのローディング アプリケーションローディングプロセスは、意図されたＩＣカート上への安全 かつ適切なアプリケーションのローディングを確実にするために、複数のセキュ リティおよびカード構成チェックを包含する。アプリケーションローディングプ ロセスは、カードが発行されるときに、カードが１つ以上のアプリケーションを 包含するように、好ましくはパーソナル化機関において行われる。カードは、例 えば、電子預金アプリケーションまたはクレジット／デビットアプリケーション などの発行者が発送する全カード上に存在する、所定の共通アプリケーションを 含み得る。あるいは、パーソナル化機関は、イネーブルされたカードを第三者に 発送し、アプリケーションのローディングプロセスを行わせ得る。各カードのＲ ＯＭおよびカードＭＳＭパーソナル化データに記憶されたマルチアプリケーショ ンオペレーティングシステムは、カードが特定のカードユーザおよび責任のある カード発行者の要望により発行された後の、アプリケーションの将来的なローデ ィングおよび消去を可能にするように設計される。従って、ＩＣカード上に記憶 されたアプリケーションのより古いバージョンは、アプリケーションの新しいバ ージョンに置き換えられ得る。そのアプリケーションが新しく利用可能になった ため、もしくはユーザが新しいアプリケーションを利用することを望んでいると いう理由で、追加のロイヤリティアプリケーションもまた、カードが最初にカー ドユーザへ発送された後にカードに追加され得る。アプリケーション用のこれら のローディングおよび消去機能は、端末により直接的に行われ得るか、あるいは 電話線、データライン、インターネットもしくは２つのエンティティ間でデータ を送信する任意の他の方法のようなネットワークを介して行われてもよい。現在 のＩＣカードシステムにおいて、アプリケーションプログラムおよびデータを送 信するプロセスは、適切なパーソナル化データを包含し、アプリケーション許可 プロフィールに適合するＩＣカードのみが資格を与えられ、対応するアプリケー ションプログラムおよびデータを受信する。 図６は、MULTOSＩＣカードシステム内のＩＣカード上にアプリケーションをロ ードする際に行われる好ましい工程を示す。この例において、パーソナル化機関 はアプリケーションを同じカードをイネーブルした端末からロードしている。工 程６０１は、カードが特定のアプリケーションのローディングを受け入れる資格 が与えられることを確実にするためにカードをプレビューする端末により開始さ れる「オープンコマンド」を行う。オープンコマンドは、アプリケーションの許 可データ、アプリケーションのサイズを備えたカードを供給し、カードに（１） イネーブル化ビットが、カードがパーソナル化され終えたことを表示するように 設定されているか否か、（２）アプリケーションコードおよび関連したデータが 、カード上に存在するメモリスペース内に収まるか否か、および（３）アプリケ ーションがロードされるように割り当てられたパーソナル化データが、問題とす る特定のカードへのアプリケーションのローディングを可能にするか否か、を決 定 するよう指示する。オープンコマンドはまた、カードシステムから要求されたと きに、追加のチェックを行い得る。オープンコマンド実行中のこれらのチェック 工程は、図７と合わせて詳細に説明する。 オープンコマンドが実行された後、カードが適切な識別パーソナル化データを 含んでいるか否か、ならびにカードのメモリ中にアプリケーションコードおよび 関連データのためのスペースが十分にあるか否かに関して、アプリケーションロ ーダは端末を介して知らされる(advise)。メモリが十分になければ、カードから ネガティブ応答が返され、プロセスを異常終了(abend)される。識別パーソナル 化データがアプリケーション許可データに合致しなければ、ステップ６０３にお いて警告応答が与えられるが、プロセスはロードおよびクリエイト(load and cr eate)ステップに続く。あるいは、合致しない場合には、プロセスは自動的に異 常終了されてもよい。ステップ６０５においてカードから端末にポジティブ応答 が返された場合は、アプリケーションローダは好ましくは次のステップに進む。 オープンコマンドは、コードおよびデータの転送が開始される前に、アプリケー ションがカードをプレビューすることを可能にする。 次にステップ６０７は、アプリケーションコードおよびデータをＩＣカード上 のEEPROMへロードする。実際のローディングは、クリエイトステップ６０９と関 連して起こる。クリエイトステップ６０９はローディングプロセスを完了させ、 ロード後にアプリケーションがＩＣカード上で実行されることを可能にする。ア プリケーションローディングプロセスを行うために、オープン、ロードおよびク リエイトコマンドの組み合わせが、端末またはその他のアプリケーションプロバ イダソースによって、ＩＣカードに送られる。ＩＣカード中のオペレーティング システムは、これらのコマンドの各々に対して特定の命令のセットを実行するよ うにプログラムされており、ＩＣカードが端末からの命令と連絡をとりこれを適 切に実行する。 ステップ６０９は、クリエイトコマンドを実行する。クリエイトコマンドは少 なくとも、(1)アプリケーションロード証明にはＣＡによる署名（暗号化）がな されていることにより、アプリケーションがシステムにとって適切なアプリケー ションであることを認証しているか否かをチエックし、(2)カード上に格納さ れたカードパーソナル化データを、ロードされるべきアプリケーションのための 許可プロフィールに照らしてチェックすることにより、カードにローディング資 格を与える。必要に応じて他のチェックを行ってもよい。チェックのうちの１つ が失敗すれば、失敗応答６１０が与えられ、プロセスはアボートされる。これら のチェックを通った後のアプリケーションは、カードのメモリにロードされる。 図７は、図６のオープンステップ６０１の様々なステップをより詳細に示して いる。ステップ７０１は、イネーブル化（すなわちコントロール）ビットが設定 されているか否かを決定する。このビットは、カードがそのパーソナル化プロセ スを完了してパーソナル化データを割り当てられたときに、設定される。アプリ ケーションは、カードがパーソナル化データを含んでいる場合にのみ、カードシ ステム中のＩＣカード上にロードされ得る。イネーブル化ビットが設定されてい ない場合は、カードのパーソナル化はまだであるため、カードはネガティブ応答 ７０３を端末に返す。イネーブル化ビットが設定されていれば、カードはイネー ブルされており、テスト条件はステップ７１１に続く。 ステップ７１１は、カード上のメモリに、アプリケーションコードおよびそれ に付随するデータを格納するための十分なスペースがあるか否かをチェックする 。アプリケーションは典型的には、その機能に関連するデータが付随している。 このデータは、アプリケーションが実行されるときに用いられ、操作される(man ipulate)。EEPROMに必要となる比較的大きい物理的スペースおよび、クレジット カードサイズのカード上に納まるように小さいことが望まれる集積回路内にそれ をどのように納めるかということから、ＩＣカードのメモリ中の格納スペースは 継続的な問題である。ＩＣカード上のプリセットEEPROMのサイズの一例は１６Ｋ バイトであるが、実際のサイズは変動する。アプリケーションは、非常に単純な アプリケーションの場合の１Ｋバイト以下から、より高度なアプリケーションの 場合の利用可能なメモリサイズまでというように、様々であり得る。アプリケー ションに付随するデータは、カードメモリに全くデータが格納されていない状態 から、利用可能なメモリ量によって制約を受けるサイズまで、様々であり得る。 これら様々なサイズのアプリケーションコードおよびデータは、アプリケーショ ンがより進歩し多様化するにつれて、増加し続ける。 オペレーティングシステムとしてのMULTOSは、カード上に格納し得るアプリケ ーションの数および付随データによっては、制限されない。従って、５つのアプ リケーションがカードの利用可能メモリ中に納まるならば、カードユーザは、１ つまたは２つのアプリケーションがカード上に格納されている場合よりも、大き く増大した機能性を有することになる。しかし、カードのメモリが容量いっぱい になると、十分なサイズのコードおよびデータを含む別のアプリケーションを削 除することが出来ないかぎり、新しいアプリケーションをカードにロードするこ とは不可能である。従って、カード上の利用可能スペースの量をチェックするこ とは、重要なステップである。十分なスペースが存在しなければ、不十分スペー ス応答７１３が端末に返される。すると、アプリケーションローダは、新しいア プリケーションに空間を作るためにカード上の別の既存のアプリケーションを削 除すべきか否かを決定し得る。削除は、カード発行者がＣＡからのアプリケーシ ョン削除証明を有するか否かに依存する。カード上に十分なスペースが存在すれ ば、プロセスはステップ７１５に続く。 次に、ステップ７１１におけるメモリスペースのテストの一例を説明する。こ の例において用いられる数は、発明の範囲を何ら限定するものではなく、メモリ スペース要求を例示するために用いているだけである。ＩＣカードは、最初の製 造時において、１６Ｋの利用可能EEPROMを有し得る。オペレーティングシステム に必要とされるオペレーティングシステムデータは、最大２Ｋのメモリスペース を占め得る。従って、１４Ｋが残ることになる。電子預金アプリケーションのコ ードはEEPROMに格納され、８Ｋのメモリスペースを占め得る。財布アプリケーシ ョンの必要なデータは、EEPROM中においてさらに４Ｋのメモリスペースを占め得 る。他のアプリケーションが自由に使い得るメモリスペースは従って、２Ｋ（１ ６Ｋ−２Ｋ−８Ｋ−４Ｋ＝２Ｋ）である。この例において、コードのサイズが６ Ｋのクレジット／デビットアプリケーションをカード発行者がカードにロードし たい場合、アプリケーションはＩＣカードのメモリ内に納まらない。従って、ア プリケーションは、まず財布アプリケーションをカードから除去することなしに は新しいアプリケーションをロードすることができない。もし新しいクレジット ／デビットアプリケーションがＩＣカードのEEPROMにロードされると、その他の アプリケーションのコードまたはデータを上書きしなければならなくなる。アプ リケーションローダは、これを行うことを防止される。 図８は、カードのパーソナル化データが、問題とするアプリケーションがロー ドされてもよい許可カードのセット(permissible set of cards)内にあるか否か を決定するために、実行されるステップを示している。これらのステップは好ま しくは、「クリエイト」コマンドの実行中に実行される。しかし、これらのステ ップは、アプリケーションのローディングまたは削除中の任意の時刻に行われ得 る。前述のように、カードは、個々のカードに特異的なカードＩＤ指定、カード の発行者を示すカード発行者番号、カードの製品タイプ（ゴールドカードである かプラチナカードであるかなど）、およびカードがパーソナル化された日付を含 む、カードに特異的なデータ（ＭＳＭパーソナル化データ）を格納することによ ってパーソナル化される。このデータは、カードを、システム中の他の全てのＩ Ｃカードからユニークに識別する。 従ってアプリケーションは、次のものを含む実質的にあらゆる基準によって、 ＩＣカード中の個々のカード上に選択的に格納され得る。アプリケーションは、 １つ以上の特定のカード番号を含むカードに選択的にロードされてもよい。アプ リケーションは、特定されたカード発行者ＩＤを含む１つ以上のカードに選択的 にロードされてもよい。さらに、アプリケーションは、特定のカード発行者によ って特定される１つの製品タイプのみにロードされてもよく、および／または、 アプリケーションは、特定されたある１つのまたは一連のパーソナル化日付を有 するカードにのみロードされてもよい。パーソナル化データの各々は、アプリケ ーションが、あるカードまたはカード群に選択的にロードされることを可能にし 、また、適切な許可を有さないカードはアプリケーションを受け取らないことを 確実にする。示した４つに加えて、パーソナル化データタイプもまた必要に応じ て用いられ得る。 特定のアプリケーションがロードされてもよいＩＣカードの選択は、アプリケ ーションに割り当てられ、アプリケーションがロードされてもよいカードの少な くとも１つのセットを表す、「アプリケーション許可データ」の使用によって可 能になる。セットは、カード番号、カード発行者、製品タイプまたはパーソナル 化データのうちの１つ以上を含む、実質的にあらゆるファクタに基づき得る。個 々のカードのパーソナル化データは典型的には１つの特定の番号、１つのカード 発行者、１つの製品タイプ、および１つの日付を識別するが、アプリケーション の許可データは、カード番号または包括的許可(blanket permission)、カード発 行者または包括的許可、および複数の製品タイプおよび日付を示してもよい。 例えば、得意客(frequent loyalty)プログラムは、１つのカード発行者に属す る異なる製品クラスのカード上において、その使用およびローディングを可能に するように構成されてもよい。また、アプリケーション許可データは、カードが 1998年５月以降に発行されたものであればゴールドまたはプラチナの製品タイプ 上でロイヤリティプログラムが使用可能であることを示してもよい。このように 、ＭＳＭ許可チェックは、カードの個々のパーソナル化データが、アプリケーシ ョンがロードされてもよい許可カードのセット中に含まれるか否かを決定する。 比較プロセスを促進するために、別の実施形態は、１つ以上の許可データを、 その特定のデータについての包括的許可を表すゼロに設定することを包含し得る 。例えば、アプリケーション許可データの「カード番号」エントリにゼロを入れ ることにより、あるいは全てのカードを番号によらずロードを行ってよいことを 示す、その他の値を入れることによって、システムは、カード番号に基づいてい かなるカードを否定することもしてはならないことを知る。さらに、アプリケー ションの許可データカード「発行者ＩＤ」にゼロが入れられると、全てのカード は同様に「発行者」テスト比較をパスする。この特徴により、カード群を選択す る際においてより大きな柔軟性を可能にする。ゼロインジケータはまた、必要に 応じて他の許可データのためにも用いられ得る。 図８を参照して、許可データの各々は図示した順にチェッタされるが、許可の うち１つが失敗した場合、アプリケーションは、チェック中のＩＣカード上にロ ードされることを禁止されるため、他の順序で行ってもよい。許可は、好ましく は図示された順序でチェックされる。ステップ８０１は、アプリケーション許可 製品タイプセットが、カードのメモリ中に格納されたカードの製品タイプ番号を 包含するか否かを決定する。各カード製品タイプには、システムオペレータによ ってある番号が割り当てられる。異なるカード発行者は異なる製品タイプを有す るであろうから、製品タイプは各カード発行者について特定される。承認された 製品タイプのカードにのみアプリケーションがロードされることを確実にするた め、カードは選択的にチェックされる。アプリケーション許可製品タイプセット は、複数の容認可能な製品タイプを含む３２バイト長であってもよく、あるいは 、システムのニーズに応じて異なる長さであり得る。データ構造５０５Ａを一例 として用いると、オペレーティングシステムは、３２バイト長のアプリケーショ ン許可データ構造から得られる、２５６ビットアレイ（３２バイト×８ビット／ バイト）中のビット番号２をチェックすることになる。許可チェックが失敗する と、ステップ８０３においてカードは失敗メッセージを端末に返す。製品タイプ チェックがパスすると（例えば第２ビットの値が１であれば）、プロセスはステ ップ８０５に続く。 ステップ８０５は、アプリケーション許可許容カード発行者番号セットが、カ ードのメモリ中に格納されたカード発行者番号を包含するか否か、あるいは、ア プリケーション許可発行者データがゼロである（全てのカードがこの個別許可チ ェックをパスすることを示す）か否かをチェックする。システムオペレータによ って各カード発行者に番号が割り当てられ、承認されたカード発行者によって配 布されたカードにのみアプリケーションがロードされるようにするために、カー ドを選択的にチェックする。アプリケーション許可カード発行者番号セットは、 １つのカード発行者が指定される場合は４バイト長であってもよく、あるいは、 システムのニーズに応じてこれより長くてもよい。発行者チェックが失敗すると 、ステップ８０７においてカードは失敗メッセージを端末に返す。チェックがパ スすると、プロセスはステップ８０９に続く。 ステップ８０９は、アプリケーション許可データセットが、カードのメモリに 格納されたカードのデータ日付を包含するか否かをチェックする。ＩＣカードが パーソナル化された日付は格納され、好ましくは少なくとも月および年を含む。 承認されたパーソナル化日付を有するカードにのみアプリケーションがロードさ れるようにするために、カードを選択的にチェックする。アプリケーション許可 日付セットは、複数の日付を含む３２バイト長であってもよく、あるいは、シス テムのニーズに応じて異なる長さであってもよい。日付許可チェックが失敗する と、ステップ８１１においてカードは失敗メッセージを端末に返す。日付チェッ クがパスすると、プロセスはステップ８１３に続く。 ステップ８１３は、アプリケーション許可許容カード番号セットが、カードの メモリに格納されたカードのＩＤ番号を包含するか否か、あるいは、アプリケー ション許可許容カード番号データがゼロである（全てのカードがこの個別許可チ ェックをパスすることを示す）か否かをチェックする。許可のテストは、オープ ン、ロード、およびクリエイトコマンドの実行中に、カードに対して行われる。 アプリケーション許可カード番号データセットは、１つの番号が指定される場合 は８バイト長であってもよく、あるいは、システムのニーズに応じてこれより長 くてもよい。カード番号チェックが失敗すると、ステップ８１５においてカード は失敗メッセージを端末に返す。日付チェックがパスすると、プロセスはステッ プ８１７に続く。 ＩＣカードシステムのプロセスの概略 図９は、安全なマルチアプリケーションＩＣカードシステム中のＩＣカードの 、カード初期化プロセスのための、システムアーキテクチャの要素を示す。シス テムはカード製造者１０２、パーソナル化機関１０４、アプリケーションローダ １０６、初期化中のＩＣカード１０７、カードユーザ１０９、およびマルチアプ リケーション安全システム全体のための証明機関１１１を含む。カードユーザ１ ３１は、ＩＣカード上の格納されたアプリケーションを用いる者あるいはエンテ ィティである。例えば、カードユーザは、同一ＩＣカード上に電子キャッシュ（ 例 MVアプリケーション）とを含んだ電子預金ＩＣカードを好み得る。以下に、カー ドユーザが、安全な方法で所望のアプリケーションを含んだＩＣカードを取得す るための一方法を説明する。 カードユーザは、ＩＣカードを配布する銀行などのカード発行者１１３にコン タクトを取り、単一のＩＣカードのメモリ中に常駐した２つのアプリケーション を備えたＩＣカードを要求する。ＩＣカードの集積回路チップは製造者１０２に よって製造され、カード上のＩＣチップの形でカード発行者１１３（またはそれ を代表するエンティティ）に送付される。前述のように（ステップ２０１〜２０ ９を参照）、製造プロセス中において、データは、製造者１０２からデータ路を 介してカード１０７に転送１１５され、ＩＣカード１０７のメモリに格納される 。（この図に説明したデータ路のうちのいずれも、電話線、インターネット接続 、あるいはその他の転送媒体であり得る）。システム全体のための暗号化／復号 化鍵を維持している証明機関１１１は、データ路を介してセキュリティデータ（ すなわちグローバル公開鍵）を製造者に送信１１７し、製造者によってセキュリ ティデータは他のデータ（例えばカードイネーブル化鍵およびカード識別子など ）とともにカード上に置かれる。カードのマルチアプリケーシヨンオペレーティ ングシステムもまたＲＯＭ中に格納されており、製造者によってカード上に置か れる。カードは初期処理を施された後、パーソナル化およびアプリケーションロ ーディングのためにカード発行者に送られる。 カード発行者１１３は２つの別々の機能を行うか、あるいは別のエンティティ によって行わせる。第１に、パーソナル化機関１０４は、上述した方法でＩＣカ ード１０７をパーソナル化し、第２に、アプリケーションローダ１０６は、上述 のようにカードが資格を与えられている場合において、アプリケーションをロー ドする。 パーソナル化に関して、個別化されたカード鍵セットがＣＡによって生成され 、カードに格納される（図３を参照）。さらに、ＭＳＭパーソナル化を用いて、 カードＩＤ番号、カードを処理したカード発行者を識別する発行者ＩＤ番号、カ ード発行者によって特定されるカード製品タイプ番号、およびパーソナル化が行 われた日付を含む、特定のアイデンティティがカードに与えられる（図３のステ ップ３０７および図５を参照）。カードがパーソナル化された後、カードが所望 の機能を実行できるようにアプリケーションがカードにロードされる必要がある 。 アプリケーションローダ１０６（パーソナル化機関１０４と同じ端末またはデ ータ路を用い得る）はまず、カードがアプリケーションを受け入れる資格を有し ているか否かを決定する必要がある。この比較プロセスは、許可情報を用いて（ オペレーティングシステムの命令に従って）カード自体の上で起こる。カードは 、資格を与えられていれば、カードのアイデンティティおよびカード発行者の 命令に基づいて選択的にアプリケーションを自身にロードする。アプリケーショ ンローダは端末またはその他のデータ路を介してＩＣカードと連絡１１９する。 アプリケーションがカードにロードされた後、カードはカードユーザ１０９に送 達されて使用される。 本明細書に説明した安全なマルチアプリケーションＩＣカードシステムは、カ ードがパーソナル化された後、ＩＣカードのライフサイクル中の任意の時点にお いて、アプリケーションの選択的なローディングおよび削除を可能にする。従っ て、カードユーザはまた、アプリケーションを有さないパーソナル化カードを受 け取ってから、電話線またはインターネット接続などの共通の送信線を介して、 所望のアプリケーションを選択し得る。 図１０は、パーソナル化されてから後のＩＣカードの使用に関与するエンティ ティのシステム図である。システムはＩＣカード１５１、端末１５３，アプリケ ーションロード／削除エンティティ１５５、証明機関１５７、カード発行者１７ １、およびシステム中の他のＩＣカード１５９を含む。矢印は、各エンティティ 間の通信を表す。ＣＡ１５７は、アプリケーションのローディングおよび削除を 容易にする。カードイネーブル化中においてＭＳＭ許可データおよびカード特異 的な鍵セットをカードに提供した後、ＣＡは、好ましくはアプリケーション証明 (application certificate)を発行することによってアプリケーションを後にロ ードまたは削除することを可能にする。アプリケーション特異的な鍵は、カード と端末との間の通信を認証するために必要とされる。ＩＣカード１５１はまた、 他のＩＣカード１５９とも通信可能である。カード発行者１７１は、発行したカ ードに対するアプリケーションのローディングおよび削除の全ての決定に関与す る。全ての通信は認証され、システム内を安全に送信される。 例えば、ＩＣカード１５１は以下の手順を用いて、新しいアプリケーションを カードにロードする。ＩＣカード１０１が端末１５３に接続され、端末はアプリ ケーションのロードを要求する。端末１５３はアプリケーションロード／削除エ ンティティ１５５にコンタクトを取り、アプリケーションロード／削除エンティ ティ１５５はその結果カード発行者１７１とともに、アプリケーションコード、 データ、およびアプリケーション許可データ（ならびに他の任意の必要なデー タ）を端末１５３に送る。端末１５３は、カード１５１に問い合わせて(query) それがアプリケーションをロードしてもよい正しいカードであることを確実にす る。ＩＣカードが上記のチェックをパスすれば、アプリケーションはカード１５ １にロードされる。ＣＡ１５７は、アプリケーションがカードにロードされまた はカードから削除されることを可能にする、アプリケーションロードまたは削除 証明を供給する。この例は、アプリケーションをロードするための一法を示して いるが、他の変形例もまた同じ原則を用いて実施することができる。例えば、ア プリケーションロード／削除エンティティ１５５において直接アプリケーション をロードすることなどである。 上記は本発明の原則を例示したに過ぎない。従って、当業者は、本明細書にお いて明示的に示しあるいは説明されなくとも本発明の原則を体現しており従って 本発明の趣旨および範囲内にある、多くのシステムおよび方法を考案することが 可能であることが、理解される。 例えば、ＭＳＭパーソナル化および許可データは、アプリケーションをＩＣカ ードにロードするためだけのみならず、そのカードからアプリケーションを削除 するためにも用い得ることが理解される。ＭＳＭ許可およびアプリケーションの ローディングを含む同様のチェックが、アプリケーションの削除についても行わ れる。アプリケーションの削除を承認するＣＡからの削除証明は、どのカードか らアプリケーションを削除してもよいかを制御する。これは、本明細書に説明し たように、各ＩＣカード上に格納されたパーソナル化データおよび許可チェック を通して達成される。 さらに、カード上に物理的にはロードされない、アプリケーションがロードさ れ得るパーソナルコンピュータまたはその他のユニットにも、データは適用可能 である。また、アプリケーションの許可データは実際には、含まれるべきではな く除外されるべきカード−−すなわちアプリケーションをロードされ得ないカー ドのセット（単数または複数）を表すデータを有していてもよい。 本開示の範囲は、請求された発明に関連するか否か、あるいは本発明で対処さ れる課題の一部または全てを緩和するか否かに関わりなく、明示的または黙示的 に開示された新規の特徴または特徴の組み合わせあるいはそれを一般化したもの を含む。本出願は、本出願または本出願に由来する任意のさらなる出願の手続中 に、そのような特徴に関する新しい請求項が作成され得ることの注意を促すもの である。特に、付属の請求項に関しては、従属項に由来する特徴は、請求の範囲 に挙げた特定の組み合わせのみならず、任意の適切な方法で独立項の特徴と組み 合わせ得る。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｋ 19/07 Ｇ０７Ｇ 1/12 ３２１Ｐ Ｇ０７Ｆ 7/10 Ｇ０９Ｃ 1/00 ６６０Ａ Ｇ０７Ｇ 1/12 ３２１ Ｈ０４Ｌ 9/00 ６７５Ｂ Ｇ０９Ｃ 1/00 ６６０ ６２１Ａ Ｈ０４Ｌ 9/10 Ｇ０６Ｆ 9/06 ６６０Ｆ 9/32 Ｇ０６Ｋ 19/00 Ｎ (31)優先権主張番号 ０９／０２３，０５７ (32)優先日 平成10年２月12日(1998．2．12) (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ０９／０７６，５５１ (32)優先日 平成10年５月12日(1998．5．12) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ， ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，Ｌ Ｓ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ， ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，Ｅ Ｅ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，Ｍ Ｄ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ， ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，Ｖ Ｎ，ＹＵ，ＺＷ (72)発明者 ミラー，スチュアート ジェイムズ イギリス国 アールジー12 ９ワイキュー バークス，ブラックネル，ザ ワレン, ウッドフォード グリーン ９ (72)発明者 ピーチャム，アンソニー デイビッド イギリス国 ティーエヌ３ ９エルエック ス ケント，タンブリッジ ウェルズ，グ ルームブリッジ，リンウッド ４ (72)発明者 シモンズ，イアン ステファンズ イギリス国 ピーイー17 ３エイティー カムズ，ブルートン，スクール ロード, ザ エルムス（番地なし) (72)発明者 リチャード，ティモシー フィリップ イギリス国 ダブリューディー７ ７エル ダブリュー ハーツ，ラドレット，クレイ グ マウント 32 (72)発明者 バイナー，ジョン チャールズ イギリス国 ウィンドゥルシャム，ウッド ランズ レーン，ハイズ（番地なし)

Claims (1)

1. 【特許請求の範囲】 １．公開鍵およびプライベート鍵の対がこれに対して生成される、証明機関と； 該証明機関の該公開鍵と該各カードをユニークに識別するためのカード識別子 とを、製造時において含んでいる、少なくとも１つの集積回路カードと； 該証明機関において、少なくとも１つのカード識別子に対してパーソナル化デ ータブロックを作成する手段と、該パーソナル化データブロックを暗号化し該暗 号化されたデータブロックをパーソナル化機関に送る手段と； 該パーソナル化機関において、該暗号化されたデータブロックを、該暗号化さ れたパーソナル化データブロックに合致するカード識別子を有する該カードにロ ードする手段と； 少なくとも該暗号化されたパーソナル化データブロックに基づき、該集積回路 カードのうち１つが、特定のアプリケーションのローディングを受け入れる資格 を有するか否かを決定する手段と； 該証明機関の該公開鍵を用いて、該カードへロードされる該アプリケーション を認証する手段と； 該決定手段および認証手段に応答して、アプリケーションを安全に該カードに ロードするローディング手段と； を有するマルチアプリケーションカードシステム。 ２．前記カードのうち少なくとも１つを、前記パーソナル化機関においてイネー ブル化するパーソナル化手段をさらに有する、請求項１に記載のシステム。 ３．前記少なくとも１つの集積回路カードはさらに、前記決定手段、認証手段お よび前記ローディング手段に命令するオペレーティングシステムを格納するため のメモリ手段を有する、請求項１または２に記載のシステム。 ４．前記少なくとも１つの集積回路カードはさらに、カード特異的な機密性を容 易にするためのカードイネーブル化鍵を有する、請求項１から３のうちいずれか に記載のシステム。 ５．前記パーソナル化手段は、前記カード識別子のリストをコンパイルする手段 と、該リストを前記当局に送る手段とを有する、請求項２あるいは請求項２に従 属する任意の請求項に記載のシステム。 ６．前記パーソナル化データブロックは、カードパーソナル化データおよび個別 鍵セットを含む、請求項１から５のうちいずれかに記載のシステム。 ７．前記カードイネーブル化鍵が設定されているか否かをチェックする手段をさ らに有し、前記暗号化されたデータブロックをローディングするための前記手段 は、該イネーブル化鍵が設定されていない場合にのみ該ブロックをロードし、該 カードイネーブル化鍵は該暗号化データブロックをロードした際に設定される、 請求項４に従属する任意の請求項または請求項６に記載のシステム。 ８．対応する秘密鍵を保持する当局からの任意のメッセージの源を認証するため の公開鍵と、カード特異的な機密性を容易にするためのカードイネーブル化鍵と 、各カードをユニークに識別するためのカード識別子と、オペレーティングシス テムを格納するためのメモリとを製造時においてそれぞれ含んでいる、少なくと も１つの集積回路カードと； 前記カードをパーソナル化機関においてイネーブル化するパーソナル化手段で あって、該カード識別子のリストをコンパイルする手段と、該リストを該当局に 送る手段とを含むパーソナル化手段と； 該当局において、該当局に送られた各カード識別子に対してパーソナル化デー タブロックを作成する手段であって、該データブロックは該カードの各々につい てカードパーソナル化データおよび個別鍵セットを含んでいる、手段と； 該データブロックの各々を暗号化する手段と、該暗号化されたデータブロック を該パーソナル化機関に送る手段と； 該カードイネーブル化鍵が設定されているか否かをチェックし、設定されてい なければ、該カード識別子を該暗号化されたデータブロックと照合し、該暗号化 されたデータブロックをその合致する対応カードにロードし、該イネーブル化鍵 を設定する手段と； 該カードが、特定のアプリケーションのローディングを受け入れる資格を有す るか否かを決定する手段と；該アプリケーションが該当局によって署名された否 かをチェックすることにより、該ロードされるべき特定のアプリケーションを認 証するチェック手段と； 該決定手段およびチェック手段に応答して、該１つ以上の特定のアプリケーシ ョンをロードするローディング手段と； を有するマルチアプリケーションカードシステム。 ９．１つ以上のアプリケーションを集積回路にロードするための方法であって、 証明機関の公開鍵を含むセキュリティデータを集積回路カードに送信するステ ップと； 該証明機関において、該カードについてのパーソナル化データブロックを作成 し、該データブロックを暗号化し、該暗号化されたデータブロックをパーソナル 化機関に送るステップと； 該暗号化されたデータブロックを、該カードにロードするステップと； 少なくとも該暗号化されたデータブロックに基づき、該カードが、特定のアプ リケーションのローディングを受け入れる資格を有するか否かを決定するステッ プと； 該公開鍵を用いて、該カードへロードされる該アプリケーションを認証するス テップと； 該カードが資格を与えられており、該アプリケーションが認証された場合に、 該アプリケーションをロードするステップと； を包含する方法。 １０．集積回路から１つ以上のアプリケーションを削除するための方法であって 、 証明機関の公開鍵を含むセキュリティデータを集積回路カードに送信するステ ップと； 該証明機関において、該カードについてのパーソナル化データブロックを作成 し、該データブロックを暗号化し、該暗号化されたデータブロックをパーソナル 化機関に送るステップと； 該暗号化されたデータブロックを、該カードにロードするステップと； 少なくとも該暗号化されたデータブロックに基づき、該カードが、特定のアプ リケーションの削除を受け入れる資格を有するか否かを決定するステップと； 該カードが資格を与えられている場合に、該アプリケーションを削除するステ ップと； を包含する方法。