(57)【特許請求の範囲】
【請求項１】
マイクロプロセッサ（１１２）、読出し専用メモリ（１２４）、ランダムアクセスメモリ（１２６）、電気的に消去可能なプログラマブル読出し専用メモリ（１２８）、および該読出し専用メモリ中に格納されたプログラミング命令の１つ以上のセットを含む集積回路カード（１０８）を含むマルチプルアプリケーションカードシステム（１０６）であって、
該集積回路カード（１０８）に、該プログラミング命令の少なくとも１つのセットにアクセスする少なくとも１つのアプリケーションを格納する手段と、
該アプリケーションによりアクセスされる該プログラミング命令の少なくとも１つのセットのためのアクセスフラグをアプリケーション制御データと共に格納する手段と、
ロードされた該アプリケーションに応じて該プログラミング命令のセットへのアクセスをイネーブルするように該アクセスフラグを設定する手段と、
該アクセスフラグに応じて、該アプリケーションによる該プログラミング命令のセットへのアクセスを可能にする手段と
を備える、システム。
【請求項２】
前記アクセスフラグを格納する手段は、前記電気的に消去可能なプログラマブル読出し専用メモリ内に存在する、請求項１に記載のシステム。
【請求項３】
前記プログラミング命令の少なくとも１つのセットは、暗号プリミティブである、請求項１または２に記載のシステム。
【請求項４】
前記暗号プリミティブへのアクセスは、前記アクセスフラグの値が０に設定されているときに拒否され、１に設定されているときに許可される、請求項３に記載のシステム。
【請求項５】
マイクロプロセッサ（１１２）と、
該マイクロプロセッサに接続された少なくとも１つのメモリ（１１４）であって、プログラミング命令の１つ以上のセットにアクセスする少なくとも１つのアプリケーションプログラムと、該プログラミング命令の１つ以上のセットのうちの少なくとも１つに関連する、アプリケーション制御データと共に格納される少なくとも１つのアクセスフラグとを格納する少なくとも１つのメモリと、
該集積回路カードに格納され、かつ、該マイクロプロセッサにより実行されるマルチプルアプリケーションオペレーティングシステムであって、該関連するアクセスフラグの値に応答して該プログラミング命令の１つ以上のセットへのアクセスをイネーブルするマルチプルアプリケーションオペレーティングシステムと
を備える、集積回路カード。
【請求項６】
前記少なくとも１つのアクセスフラグは、読出し専用メモリ内に格納される、請求項５に記載の集積回路カード。
【請求項７】
前記プログラミング命令の１つ以上のセットは、前記読出し専用メモリ内に格納される、請求項５または６に記載の集積回路カード。
【請求項８】
前記少なくとも１つのアプリケーションは、電気的に消去可能なプログラマブル読出し専用メモリ内に格納される、請求項５から７のいずれかに記載の集積回路カード。
【請求項９】
前記アクセスフラグは、電気的に消去可能なプログラマブル読出し専用メモリ内に格納される、請求項５から８のいずれかに記載の集積回路カード。
【請求項１０】
前記プログラミング命令の少なくとも１つのセットは、暗号プリミティブである、請求項５から９のいずれかに記載の集積回路カード。
【請求項１１】
暗号プリミティブへのアクセスは、前記アクセスフラグの値が０に設定されているときに拒否され、１に設定されているときに許可される、請求項５から１０のいずれかに記載の集積回路カード。
【請求項１２】
マイクロプロセッサ（１０８）、読出し専用メモリ（１２４）、ランダムアクセスメモリ（１２６）、および電気的に消去可能なプログラマブル読出し専用メモリ（１２８）を含む集積回路カード（１０８）を含むマルチプルアプリケーションカードシステムにおいて、該読出し専用メモリ内に格納されているプログラミング命令の１つ以上のセットへのアクセスを制御する方法であって、
少なくとも１つのアプリケーションを該ＩＣカードに格納すること（５０１）であって、該アプリケーションは、該プログラミング命令の少なくとも１つのセットにアクセスする、ことと、
該ＩＣカードに、該少なくとも１つのアプリケーションによる該プログラミング命令の少なくとも１つのセットへのアクセスが許可されるかどうかを示す値を有するアクセスフラグをアプリケーション制御データと共に格納すること（５０３）と、
該格納されたアプリケーションに応じて、該プログラミング命令の少なくとも１つのセットへのアクセスをイネーブルするように、該アクセスフラグを設定することと、
該アクセスフラグに応じて、該プログラミング命令の１つ以上のセットへのアクセス（５０７）を可能とすることと、
を含む、方法。
【請求項１３】
前記アプリケーションは、前記電気的に消去可能なプログラマブル読出し専用メモリ内に存在する、請求項１２に記載の方法。
【請求項１４】
前記プログラミング命令の少なくとも１つのセットは、暗号プリミティブである、請求項１２または１３に記載の方法。
【請求項１５】
暗号プリミティブへのアクセスは、前記アクセスフラグの値が０に設定されているときに拒否され、１に設定されているときに許可される、請求項１２から１４のいずれかに記載の方法。
【発明の詳細な説明】
【０００１】
（優先権主張の基礎となる出願）
本出願は、「Ａｃｃｅｓｓ／Ｃｒｙｐｔｏ  Ｆｌａｇｓ」という名称の１９９８年２月３日付けで出願された米国特許仮出願第６０／０７３，５６６号に基づく優先権を主張する。
【０００２】
（関連出願）
本出願は、「Ｃｏｄｅｌｅｔｓ」という名称の１９９８年１月２２日付けで出願された米国特許仮出願第６０１０７２，５６１号および「Ｓｅｃｕｒｅ  Ｍｕｌｔｉｐｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｃａｒｄ  Ｓｙｓｔｅｍ  ａｎｄ  Ｐｒｏｃｅｓｓ」という名称の１９９８年５月１２日付けで出願された米国特許出願第０９／０７６，５５１号に関連する。本明細書中、これらの出願を参考のため援用する。本明細書中、米国特許出願第０９／０７６，５５１号が、Ａｎｎｅｘ  Ａとして含まれている。
【０００３】
（発明の背景）
集積回路カードは、多くの異なる目的のために、今日、世界でますます用いられるようになってきている。ＩＣカードは典型的には、コンピュータチップが埋め込まれた、従来のクレジットカードの大きさである。ＩＣカードは、マイクロプロセッサ、読出し専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読出し専用メモリ（ＥＥＰＲＯＭ）、入力／出力（Ｉ／Ｏ）機構およびマイクロプロセッサの動作をサポートする他の回路を含む。ＩＣカードは、１以上のアプリケーションをメモリ内に含み得る。アプリケーションローダは、アプリケーションをカードにロードするエンティティである。アプリケーションローダは、アプリケーションの実際の開発者または第三者であり得る。
【０００４】
ＭＵＬＴＯＳTMとは、様々なプラットフォームのなかでもＩＣカード上で動作するマルチプルアプリケーションオペレーティングシステムであり、複数のアプリケーションがカード自体上で実行されることを可能にする。このことは、カードが使用のために挿入される端末のタイプ（すなわち、ＡＴＭ、電話および／またはＰＯＳ）にかかわらず、カードユーザが、カード（例えば、クレジット／デビット、電子マネー／財布および／またはロイヤリティーアプリケーション）内に格納されている多くのプログラムを実行することを可能にする。このようなカードを使用する際に最も重要なことはセキュリティであり、カードシステムのオペレータが、カードが端末または他のカードとセキュアに通信することを可能にする。オペレータはさらに、アプリケーションのカードへのローディングおよびカードからの削除、ならびにシステムをセキュアにする暗号鍵を管理する。
【０００５】
ＩＣカードは典型的には、カード上にメモリを配置する際のサイズおよびコストに関する制限により、限られた格納容量を有する。マルチアプリケーションスマートカード用のアプリケーションは、プログラミング言語で書かれ、典型的には、カードの寿命期間中にコンテンツが変更され得るＥＥＰＲＯＭ内に格納される。ＩＣカードにおいて用いられるプログラミング言語の一例は、Ｍｕｌｔｏｓ  Ｅｘｅｃｕｔａｂｌｅ  Ｌａｎｇｕａｇｅ  ＭＥＬTMである。ＭＥＬプログラム命令は、実行される際にＥＥＰＲＯＭから読み出され、ＲＯＭ内に格納されているオペレーティングシステムにより解釈される。
【０００６】
ＩＣカード上のＲＯＭは、特定の集積回路構成用のアセンブラ言語コード（ネィティブ言語タイプのコード）で書かれたオペレーティングシステムを含む。ＲＯＭ内に格納されているオペレーティングコードは、ＲＯＭが初めて書き込まれたときに固定され、ＲＯＭ内に格納された情報は、カードの寿命期間中、変化しない。
【０００７】
ＲＯＭ内には、マイクロプロセッサ用のネィティブ言語で書かれた、プリミティブと呼ばれるサブルーチンもまた存在し得る。プリミティブは、実行される際、オペレーティングシステム自体またはアプリケーションのいずれかから呼び出され得る。プリミティブは、ネィティブ言語（すなわち、アセンブラ言語）で書かれており、そのため、極めて高速で実行可能であり、実行に必要な命令の解釈も最小限ですむ。これらのプリミティブは、典型的には、数学的機能または暗号機能などの、所望の機能を果たす命令の集合体である。これらの命令は、カードの寿命期間中、決して変更されることはない。プリミティブにより用いられる、またはアクセスされるあらゆるデータは、ＥＥＰＲＯＭ内に格納され、それにより、データ要素のコンテンツが、必要に応じて変更され得る。
【０００８】
ＭＵＬＴＯＳTMシステムにおいて、アプリケーションは、カードに格納されているプリミティブを呼び出し得、次いでプリミティブはオペレーティングシステムにより実行される。例えば、アプリケーションが２つの数を分割する必要がある場合、アプリケーションは、「分割」プリミティブを呼び出して、その機能用のオペランドを提供し得、プリミティブは計算を実行する。カード上のあらゆるアプリケーションは、「アクセス分割プリミティブ」命令を実行することにより分割プリミティブを呼び出す能力を有する。いくつかのプリミティブは、基本的数学式または基本的なデータ検索などの、ほとんどすべてのアプリケーションに必要である一方、いくつかのプリミティブは、オプションであり、いくつかのアプリケーションのみにより用いられように意図されている。例えば、データを暗号化／解読するセキュリティ関連プリミティブは、個々のアプリケーションの要求事項のために、いくつかのアプリケーション（例えば、銀行アプリケーション）によって用いられるが、他のアプリケーション（例えば、航空マイレージまたは娯楽アプリケーション）によっては用いられないということがあり得る。
【０００９】
さらに、外部の考慮すべき事項が、アプリケーションによるいくつかのプリミティブの許可された使用に影響を与え得る。これらの事項は、カードシステムのオペレータが、個々のアプリケーションによる、ある種のプリミティブへのアクセスを制御（すなわち、阻止）することを必要とする。このような事項のひとつは、あるタイプのアプリケーション用の強力な暗号化アルゴリズムが国内で用いられ、かつ国外に輸出されることに対する個々の国の懸念である。例えば、英国は、アルゴリズムが銀行機能のために用いられている場合、プリミティブの一部である暗号化アルゴリズムが国外に輸出されることを許可し得る。しかし、暗号化アルゴリズムが健康情報などの一般的なデータに用いられる場合、英国の公序良俗は、その暗号化アルゴリズムは英国外において使用することができないと指示し得る。従って、国の法律がこのようなタイプのデータが暗号化され輸出されることを禁じている場合、そのアプリケーション用の暗号化プリミティブをディセーブルすることは好都合である。個々のアプリケーション用のプリミティブをこのように選択的にイネーブルすることは、カードシステムを制御する強力な機構となる。
【００１０】
異なるプリミティブに対して選択的なアクセスを提供することには、別の理由がある。具体的には、カードシステム動作および／またはシステム上で動作するアプリケーションのプロバイダの必要性に応じて、プリミティブを選択的にイネーブルするために、異なるプリミティブ用のアクセスチェックを有することが望ましい。例えば、選択されたプリミティブが呼び出されると、Ｉ／Ｏポートの「アクセスフラグ」がチェックされ得る。ほとんどのＩＣカードは現在、カード上のＩ／Ｏポートと端末とを物理的に接続することにより、端末と情報を交換することができる。カード上に配置されたコンタクトは、端末コンタクトに物理的に押圧され、それにより、電気信号が、カードと端末との間を通過することが可能となる。近年の開発により、カードと端末との間の物理的コンタクトを確立することなく、ＩＣカードが端末と通信することが可能となっている。この情報交換は、無線周波数（ＲＦ）波、セルラー信号または他の伝送される信号により確立される。非接触型カードの場合、アンテナがカード上に存在し、それにより、伝送信号が送信または受信される。ＩＣカードは、物理的コンタクトと無線通信用のアンテナとの両方を含み得る。非接触または無線方式で情報を伝送することは、処理時間全体を短縮することによりカード所有者にとって有利であるが、伝送信号は、物理的接続がなされた場合よりも、第三者による妨害を受けやすい。その結果、カードシステムのオペレータは、金銭関係取引などの特定のアプリケーションプログラムを物理的接続に限定することを欲し得る。
【００１１】
従って、本発明の一実施形態の目的は、プリミティブへのアクセスを制御し、かつ、カードシステムのオペレータが特定のアプリケーション用のプリミティブへのアクセスをイネーブルまたはディセーブルまたは阻止することを可能にする能力を有するマルチアプリケーションカードを提供することである。
【００１２】
（発明の要旨）
本出願人らはこのようにして、コンピュータコードと、マルチプルアプリケーションＩＣカードに埋め込まれたプリミティブとに対するアクセスを制御するシステムおよび方法を発明した。上記プリミティブは特定の例であり、本発明はこれに限られない。本出願人らは、この目的を達成する１つの方法は、「アクセスフラグ」を使用することによると決定した。アクセスフラグは、以下により詳細に説明するように、ビットで設定され、プリミティブ（例えば、暗号化プリミティブ）が特定のアプリケーションにアクセス可能であるか（例えば、ビットが１に設定されている場合）、可能でないか（ビット＝０の場合）を表示する。暗号化関連のプリミティブの場合、「アクセスフラグ」は、「暗号フラグ」と呼ばれ得る。
【００１３】
Ｉ／Ｏに関連するアクセスフラグはまた、金融関係のアプリケーション用の非接触型プリミティブへのアクセスを阻止するためにも用いられ得る。Ｉ／Ｏアクセスフラグは、カードシステムオペレータにより制御および設定され、アプリケーションがカードにロードされるときに、アプリケーションローダによりカードにロードされる。このアクセスフラグは、カードシステムのオペレータが、金融関係の、または他の選択されたアプリケーションが非接触型プリミティブを用いることを阻止することを可能にし、そのため、端末通信用に物理的接続が必要となる。
【００１４】
カードに格納され、オペレーティングシステムによりチェックされるアクセスフラグは、カードシステムのオペレータが、選択的プリミティブまたは他のサブルーチンを実行する前にアクセスフラグの状態をチェックすることにより、これらの選択的プリミティブまたは他のサブルーチンへのアクセスを制御することを可能にする。コードレット（ＭＥＬなどの、アプリケーション言語で書かれたサブルーチン）、オペレーティングシステム自体内のサブルーチン、または他のタイプのサブルーチンなどの他のサブーチンもまた、関連するアクセスフラグを有し得る。アクセスフラグのチェックは好適には、アプリケーションまたは他の命令により特定のサブルーチン呼び出し命令が実行されたときに、オペレーティングシステムにより行われる。アプリケーションは、このアクセスフラグチェックの結果に応じて、該当するプリミティブまたはサブルーチンを実行するか、または、アクセスが拒否された場合には別の一連の命令を実行する。
【００１５】
アクセスフラグは、アプリケーションがカードにロードされるときに、ＥＥＰＲＯＭ内に格納されているアプリケーション制御データと共に格納される。好適には、フラグのデフォルト設定は、ローディング前には「イネーブルされていない」に設定されているが、所望であれば、カードシステムのオペレータが、フラグを論理「１」に設定して「イネーブルされた」を表示し得る。例えば、アプリケーションが、アルゴリズムが開発されたＡ国の国外にあるＢ国において強力な暗号化サブルーチンを呼び出すようにプログラムされている場合、アプリケーションプロバイダは、カードシステムオペレータによって、アプリケーションプロバイダがＡ国政府（輸出ライセンス）およびＢ国（使用ライセンス）から暗号化プリミティブを使用する許可を受けたことを示す、カード使用予定国からの証明書を提示するよう要求され得る。証明書が提示されると、カードオペレータは、アクセスフラグビットをイネーブルする。この場合、「アクセスフラグ」は、暗号化に関連するため、「暗号フラグ」と呼ばれ得る。
（好適な実施の形態の詳細な説明）
本発明のさらなる目的、特徴、および利点は、本発明の例示的実施形態を示す添付の図面と共に考慮すると、以下の詳細な説明から明らかになる。
【００１６】
図中、特に記載しない限り、説明されている実施形態の同様の特徴、要件、部品、または部分を示すために、同一の参照符号および記号が用いられる。さらに、本発明の実施形態をこれらの図面を参照しながら詳細に説明するが、この説明は、例示的実施形態と関連して行われる。添付の請求の範囲に規定されている本発明の真の範囲および精神を逸脱することなく、記載された実施形態に対する変更および改変がなされ得ることが意図される。
【００１７】
図１は、セキュアなシステムにおいて、動作可能マルチアプリケーションＩＣカードを堤供することに関連する３つのステップを示す。第１のステップは、カード製造ステップ１０１である。第２のステップは、カード個別化データ（エンティティ認証データとも呼ばれる）がカードにロードされる、個別化ステップ１０３である。第３のステップは、カードがアプリケーションを受け取る資格があるかどうかをチェックする、アプリケーションローディングステップ１０５である。すなわち、ステップ１０５において、個別化データが、ロードされるべきアプリケーションに関連するアプリケーション許可データに照らしてチェックされる。これらの３つのステップの各々は、参考のためＡｎｎｅｘ  Ａとして援用する、同時係属中の出願第０９／０７６，５５１号に詳細に記載されている。
【００１８】
図２は、本出願により特許請求されている発明の実施形態で用いられ得る集積回路技術を組み込んだカード１０６を示す。カード１０６は、従来のクレジットカードと同様に見えるが、集積回路（ＩＣ）１０８をも含む。集積回路（ＩＣ）１０８は、マイクロプロセッサ、およびＩＣ１０８とカード１０６の外部のデバイスとの間の通信のための電気的コンタクト１１０を含む。カード１０６は、例えば、クレジットカード、デビットカード、および／または電子キャッシュカード、すなわちカード所有者が買い物をしたときに転送され得る金額を含むカード、例えばＭＯＮＤＥＸTMキャッシュカードとして用いられ得る。
【００１９】
図３は、ＩＣ部１０８の機能ブロック図であり、少なくともプロセシングユニット１１２およびメモリユニット１１４を含む。好適には、ＩＣ１０８はさらに、制御論理１１６、タイマ１１８、および入力／出力ポート１２０を含む。ＩＣ部１０８はさらに、コプロセッサ１２２を含み得る。制御論理１１６は、プロセシングユニット１１２と共に、メモリユニット１１４（ＲＯＭ１２４，ＥＥＰＲＯＭ１２６、ＲＡＭ１２８および入力／出力ポート１２０を有する）間の通信を処理するために必要な制御を堤供する。タイマ１１８は、プロセシングユニット１１２および制御論理１１６にタイミング基準信号を堤供する。コプロセッサ１２２は、暗号アルゴリズムにより必要とされるような複雑な演算をリアルタイムで行う能力を堤供する。
【００２０】
図４は、ビットマップと呼ばれることもあるアプリケーション制御データ構造４０１の一例である。ビットマップは好適には、ＥＥＰＲＯＭ内に存在し、ＩＣカードにロードされた特定のアプリケーション用の複数のアクセスフラグを含む。ビットマップは、データがＲＯＭに書き込まれる前にアクセスフラグが決定された場合はＲＯＭ内に存在し得るが、好適にはアプリケーションと共にＥＥＰＲＯＭ内に存在する。データ４０１は、カードのメモリ内に格納された８ビット（１バイト）のデータを示す。ビットマップの長さは、特定のアプリケーションおよびアプリケーションが動作するシステムに応じて、使用可能なビット長により可変である。本実施例中、ビット４０３が、上記した暗号化プリミティブに関連する暗号フラグに対応する。この暗号フラグビットは、暗号化プリミティブが特定のアプリケーション用にイネーブルされる場合、「１」に設定され、暗号化プリミティブがイネーブルされない場合、「０」に設定される。好適な実施形態におけるデフォルト状態は、イネーブルされないように常時「０」である。このことは、選択されたプリミティブを実行する許可が、アプリケーションがロードされたときにカードシステムのオペレータにより明示的に設定されない限り与えられないことを確実にする。しかし、他のシステムにおいては、デフォルトは、カードシステムのオペレータがカードを明示的にディセーブルしない限り、「１」であるか、またはイネーブルされ得る。
【００２１】
これもまた上記に記載した非接触型Ｉ／Ｏアクセスフラグビットが、ビット４０５として示されている。このビットは、非接触型動作（例えばプリミティブ）がアプリケーションにより引き出されたときにチェックされる。この非接触型動作は、例えば、無線信号を送信および受信するために必要なすべての命令であり得るし、またはこれらの命令の必要な部分であり得る。非接触型ビット４０５が「１」に設定された場合、動作が実行され得、非接触型ビット４０５が「０」に設定された場合、非接触型動作は実行され得ない。
【００２２】
他の異なるＩ／Ｏポートもまた、アクセスフラグを有し得る。この非接触型アクセスフラグはさらに、より高度な制御のための追加のフラグ、ＲＦ信号アクセスフラグおよびセルラーアクセス信号を有し得る。例えば、図４に示す別のアクセスフラグビットは、アプリケーションプログラムインターフェース（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ、ＡＰＩ）ビット４０７である。このビットは、アプリケーションがカードに格納されている特定のＡＰＩにより動作され得るかどうかを制御し得る。例えば、カードは、ＭＥＬ  ＡＰＩおよび第２のオペレーティングシステムＡＰＩを含み得る。このＡＰＩビットは、アプリケーションをＭＥＬ  ＡＰＩを用いることに制限し得るし、または、第２のオペレータシステムＡＰＩを用いるようにカードをイネーブルし得る。特定のアプリケーションにより第２のオペレーティングシステムＡＰＩを用いることは、その第２のオペレーティングシステムの所有者からの発行されたライセンスを必要とし得える。ライセンスが得られない限り、ＡＰＩフラグは、カードが第２のＡＰＩを用いることを妨げることができる。他のアクセスフラグビット４０９は、システムオペレータにより規定され得る。
【００２３】
図４は、複数のアクセスフラグを示しているが、少なくとも１つのアクセスフラグの存在が有益であり、アクセスフラグの総数は、システムまたはユーザに合わせて加減され得る。加えて、暗号フラグは、本発明の実施の形態であるＩＣカードにとって重要な特徴であるが、暗号フラグがアクセスフラグのうちの１つである必要はない。各アクセスフラグが何を制御するかについての決定は、システムオペレータにより指示される。図４は、各アクセスフラグ用の１ビットの好適なビット表示を示すが、データ構成は、例えば、アクセスリストを指標レジスタとして用いて正しいフラグデータを示すなど、異なるものでもあり得る。
【００２４】
各アプリケーションは、図４に記載のように、独自の関連ビットマップリストデータを有する。アクセスフラグを含むビットマップデータは、アプリケーションロードプロセス中に、他のアプリケーションロード情報と共にカードにロードされる。ビットマップの長さを特定するフィールドは、アクセスリストに先行し得、それにより、可変長アクセスリストを簡素化する。ビットマップ上に値が一旦設定されると、フラグデータのあらゆる不法な干渉を最小にするために、これらの値は変更されない。
【００２５】
アプリケーションが関連アクセスフラグを用いてプリミティブを呼び出すことを試みたとき、オペレーティングシステムが、アクセスフラグビットが設定されているかどうかをいかにしてチェックするかを以下に述べる。本実施例において、関連フラグが「０」に設定されてプリミティブが呼び出された場合、実行は異常に終了する（異常終了）。本実施例は特に、暗号フラグの使用を説明する。
【００２６】
ここで必要となるのが、ＭＵＬＴＯＳTMをアプリケーションに用いることにより提供される暗号プリミティブへのアクセスを許可または制限することを可能にする、ビットマップ形式のメカニズムである。この「制限されたアクセス」ＭＵＬＴＯＳTM暗号プリミティブへのアクセスは、これらの暗号プリミティブにアクセスすることに対する許可を適切な政府当局から得た旨の文書をを堤供する開発者のみに与えられる。
【００２７】
マルチプルアプリケーションカードシステムにおける、カードとカード発行機関（典型的にはロードされるべきアプリケーションを求めるエンティティである）との間の相互作用は、アプリケーションロード証明書（Ａｐｐｌｉｃａｔｉｏｎ  Ｌｏａｄ  Ｃｅｒｔｉｆｉｃａｔｅ、ＡＬＣ；参考のため本明細書に援用するＡｎｎｅｘ  Ａとして記載されている）による。ＡＬＣは、図１を参照して説明した個別化プロセス期間中に、カードに供給される。このアプリケーションロード証明書は、ビットマップ（またはフラグ）とアプリケーションとを統合性が保護された状態で関連づける特定のアプリケーションのためのアクセスフラグデータを含み得る。
【００２８】
ＡＬＣにおいて、好適には「アクセスリスト」と標記されるデータ要素が、特定のプリミティブへのアクセスが使用可能かどうかを表示するために用いられる。より具体的には、ＩＣカードに格納されている「アクセスリスト」を表示するためにはシングルビットが好適に用いられるが、他のデータ構成も使用され得る。従って、アプリケーションが、制限されている（使用不可である）暗号プリミティブにアクセスすることを試みた場合（例えば、実行アプリケーションに対する、上記プリミティブ用の「アクセスリスト」値が０に等しい）、プロセスは異常終了する。プロセスが異常終了した場合、その時点で動作中のアプリケーションプログラムの実行は停止可能であり、ディスプレイ端末がＩＣカードに接続されている場合は、エラーメッセージがディスプレイ端末に送信され得る。そうでない場合は、アクセスは許可され、プリミティブのプログラミング命令のセットは実行され、アプリケーションは命令の実行により続行する。
【００２９】
図５は、ＩＣカード内のコンピュータコードへのアクセスを制御する方法を実行するためのステップのフローチャートを示す。ステップ５０１において、アプリケーションがＩＣカードに格納される。アプリケーションは、製造時に、または、好適には図１に示すように個別化プロセスの際に、カードに格納され得る。ＩＣカードは、カード上のマイクロプロセッサがカードに格納されている複数のアプリケーションを実行することを可能にする、マルチプルアプリケーションオペレーティングシステムを含む。
【００３０】
ステップ５０３において、ＩＣカードに格納されている１以上のアプリケーションのための、プリミティブ、またはいくつかの他のプログラミング命令のセットに関連するアクセスフラグが格納される。アクセスフラグは、アプリケーションがロードされる前に、アプリケーションがロードされると同時に、またはアプリケーションがロードされた後に、格納することができる。セキュリティを最大にするために、アクセスフラグは、製造の際に読出し専用メモリー内に格納され、変更不可能となる。あるいは、アクセスフラグは、プログラマブルメモリ内に格納され得る。プログラマブルメモリは、ＩＣカードにロードされた個々のアプリケーションに対してカードを個別化するため、およびアプリケーションがカードから削除されたときおよび削除された場合にアクセスフラグを除去する能力を有するために、書き換えられ得る。例えば、暗号アクセスフラグに関して、アプリケーションプロバイダは、アプリケーションがカードにロードされた後、プリミティブとして格納されている、ある種の暗号を輸出および輸入するための許可を受け取り得る。この場合、アクセスフラグを格納しているメモリが書換え可能である場合には、アクセスフラグは変更され得る。
【００３１】
ステップ５０５において、カードに格納されているアプリケーションプログラム（例えば、クレジット／デビットアプリケーション）のうちの１つが実行される。実行されたアプリケーション内のプログラム命令が、ステップ５０７においてプリミティブに対するアクセスが行われることを必要とする場合、ＩＣカード上に存在するオペレーティングシステムは、まず、特定のプリミティブまたは機能に関連するアクセスフラグをチェックする。各プリミティブは、各アプリケーションまたはアプリケーション群用に異なるアクセスフラグを有し得、それにより、１つのアプリケーションにはアクセスが許可され第２のアプリケーションにはアクセスが許可されないということになる。アクセスフラグは、マルチプルアプリケーションカードシステムの管理者に、選択されたプリミティブへのアクセスに対する重要な制御を与える。
【００３２】
ステップ５０９において、ステップ５０９における適切なアクセスフラグの状態がチェックされる。アクセスフラグが、アクセスが拒否されたという表示をした（例えば、アクセスフラグの値がゼロである）場合、実行中のアプリケーションは、ステップ５１１において異常に終了する（異常終了）。カードユーザに対して、異常終了の理由を示すエラーメッセージが表示され得る。あるいは、アプリケーションは、プログラミング命令によって、アクセスフラグチェックが正であるか負であるかをチェックするためにプログラムされ得、アクセスフラグの値に応答してアプリケーションの選択された部分を実行し得る。
【００３３】
アクセスフラグが正の値（例えば「１」）に設定されている場合、ステップ５１３において、アクセスされたプリミティブが実行される。プリミティブのプログラム命令が実行された後、ステップ５１５までプロセスが続行する。次いでステップ５１５において、ＩＣカード上のマイクロプロセッサにより実行中のアプリケーションの実行を続行する。
【００３４】
上記は、単に本発明の原理を示しているにすぎない。従って、当業者であれば、本明細書中に明示的に示されておらず記載もされていないが、本発明の原理を具現化し、従って本発明の精神および範囲に含まれる多くのシステムおよび方法を工夫することができることが理解される。
【００３５】
本開示の範囲は、特許請求の範囲に記載されているか否かにかかわらず、および本発明が取り組む問題点のいずれかまたはすべてを軽減するか否かにかかわらず、本明細書中に明示的もしくは暗示的に開示されているあらゆる新規な特徴もしくは特徴の組合せ、またはそれらを普遍化したものすべてを含む。これにより出願人は、本出願または本出願から派生する、全てのこのようなさらなる出願の審査過程において、このような特徴に対して新しい請求項が作成され得ることを通知する。特に、添付の請求の範囲に関して、従属請求項の特徴は、独立請求項の特徴と組み合わされ得、各独立請求項の特徴は、それらの請求項中に列挙された特定の組合せだけでなく、あらゆる適切な様式で組み合わされ得る。
【図面の簡単な説明】
【図１】  図１は、セキュアなシステムにおけるマルチプルアプリケーションＩＣカードの寿命期間中の３つの状態を示すブロック図である。
【図２】  図２は、本発明の実施形態と関連して用いられ得る集積回路カードを示す。
【図３】  図３は、図２に示す集積回路の機能ブロック図である。
【図４】  図４は、本発明の実施形態によるアプリケーション制御データ構造のビットマップである。
【図５】  図５は、コンピュータコードへのアクセスを制御する方法のフローチャートである。
【図１】
0004798844.tif 000002
【図２】
0004798844.tif 000003
【図３】
0004798844.tif 000004
【図４】
0004798844.tif 000005
【図５】
0004798844.tif 000006