(57)【特許請求の範囲】
【請求項１】
マイクロプロセッサ、該マイクロプロセッサに結合された揮発性メモリ、該マイクロプロセッサに結合された不揮発性メモリ、および該不揮発性メモリに格納された複数のアプリケーションを備えた集積回路カードであって、
該アプリケーションの各々の実行中に、該マイクロプロセッサは、実行アプリケーションの各々を関連するデータメモリ空間に割り当て、
該データメモリ空間は、少なくとも、一時的なデータを参照するための揮発性メモリセグメントおよびスタティックデータを参照するための不揮発性メモリセグメントを備え、該揮発性メモリセグメントの各々は、少なくとも２つの領域に分割され、該少なくとも２つの領域は、パブリック領域およびダイナミック領域を含み、該パブリック領域の各々は、実行アプリケーションとインタフェース装置との間でデータをやり取りするため、かつアプリケーション間でデータをやり取りするために使用でき、該ダイナミック領域の各々は、実行されている特定のアプリケーションによってのみ読み出しまたは書き込み可能であり、
該集積回路カードは、第１の実行アプリケーションから第２の実行アプリケーションへ機能の実施を、委任コマンドを実行することと、該第１のアプリケーションのパブリック領域から該第２のアプリケーションのパブリック領域へとデータを送信することとによって、委任するための手段をさらに備える、集積回路カード。
【請求項２】
前記ダイナミック領域が、アプリケーションの実行中に利用される一時的なデータを参照するために使用される、請求項１に記載の集積回路カード。
【請求項３】
前記セグメントの各々の開始位置を判定するために使用される、前記マイクロプロセッサに結合された少なくとも１つのレジスタを更に備える、請求項１に記載の集積回路カード。
【請求項４】
前記セグメントの各々の上位位置を判定するために使用される、前記マイクロプロセッサに結合された少なくとも１つのレジスタを更に備える、請求項３に記載の集積回路カード。
【請求項５】
ローカルダイナミックポインタとして使用される、前記マイクロプロセッサに結合された少なくとも１つのレジスタを更に備える、請求項４に記載の集積回路カード。
【請求項６】
前記アプリケーションの各々が、複数のプログラム命令を備え、該プログラム命令の少なくとも１つが実行された場合、前記揮発性メモリセグメントによって参照される前記メモリがアクセスされる、請求項１に記載の集積回路カード。
【請求項７】
前記揮発性メモリセグメントがＲＡＭを参照し、前記揮発性メモリセグメントがＥＥＰＲＯＭを参照する、請求項１に記載の集積回路カード。
【請求項８】
データスタック上の前記第１のアプリケーションに関連する識別子を格納する手段を更に含む、請求項１に記載の集積回路カード。
【請求項９】
前記第１のアプリケーションに関連する前記識別子の調査のための手段を更に含む、請求項８に記載の集積回路カード。
【請求項１０】
前記第２のアプリケーションから前記集積回路カード上に格納された第３のアプリケーションへ機能の実施を委任するための手段を更に含む、請求項１に記載の集積回路カード。
【請求項１１】
集積回路のメモリ中に格納された複数のアプリケーションを処理するための方法であって、該方法が、
実行する第１のアプリケーションを選択する工程と、
少なくとも２つのメモリセグメントを含む該第１のアプリケーションのためのデータ空間を割り当てる工程であって、該少なくとも２つのメモリセグメントが、一時的なデータを参照するための第１の揮発性メモリセグメントおよびスタティックデータを参照するための第１の不揮発性メモリセグメントを備え、該第１の揮発性メモリセグメントは、パブリック領域およびダイナミック領域を含み、該パブリック領域は、実行アプリケーションとインタフェース装置との間でデータをやり取りするため、かつアプリケーション間でデータをやり取りするために使用でき、該ダイナミック領域は、該アプリケーションによってのみ読み出しまたは書き込み可能である他の一時的なデータを参照する、工程と、
該第１のアプリケーションを実行する工程と、
該第１のアプリケーション内の委任コマンドを実行することによって、該第１のアプリケーションの実行を中断する工程と、
該第１の揮発性メモリセグメントによって参照されたデータを保存する工程と、
少なくとも２つのメモリセグメントを含む第２のアプリケーションのためのデータ空間を割り当てる工程であって、該少なくとも２つのメモリセグメントが、一時的なデータを参照するための第２の揮発性メモリセグメントおよびスタティックデータを参照するための第２の不揮発性メモリセグメントを備え、該第２の揮発性メモリセグメントは、パブリック領域およびダイナミック領域を含む、工程と、
該第１のアプリケーションのパブリック領域から該第２のアプリケーションのパブリック領域へとデータを送信する工程と、
該第２のアプリケーションを実行する工程と、
該第１のアプリケーションの実行のために該揮発性メモリセグメントから該保存されたデータを利用する工程と、
該第１のアプリケーションの該実行を完了する工程と
を含む、方法。
【請求項１２】
前記第１のアプリケーションのアイデンティティが、委任工程中にデータスタック中に格納される、請求項１１に記載の方法。
【請求項１３】
前記データスタックが、前記第２のアプリケーションの前記完了に引き続いてアクセスされる、請求項１２に記載の方法。
【請求項１４】
前記委任側スタックをアクセスすることによって前記第１のアプリケーションのアイデンティティを調査する工程を更に含む、請求項１３に記載の方法。
【請求項１５】
前記第１の揮発性メモリの前記ダイナミック領域によって参照されるデータが、該第１のアプリケーションの実行中に利用される、請求項１１に記載の方法。
【請求項１６】
前記第２のアプリケーションのダイナミック領域によって参照される前記データが、該第２のアプリケーションの実行中に利用される、請求項１１に記載の方法。
【請求項１７】
前記第２のアプリケーションから前記集積回路カード上に格納された第３のアプリケーションに前記マイクロプロセッサの使用を委任する工程を更に含む、請求項１１に記載の方法。
【請求項１８】
前記第３のアプリケーションのための第３のデータ空間が、一時的なデータを参照するための揮発性メモリセグメントおよびスタティックデータを参照するための不揮発性メモリセグメントを含むように割り当てられ、該第３のアプリケーションの揮発性メモリセグメントが、パブリックおよびダイナミック部を含む、請求項１７に記載の方法。
【発明の詳細な説明】
発明の背景
集積回路（「ＩＣ」）カードは、今日世界中で、多くの異なる目的のためにますます多く使用されている。ＩＣカード（スマートカードとも呼ばれる）は、典型的に、従来のクレジットカードの大きさであり、コンピュータチップを有している。このコンピュータチップには、マイクロプロセッサ、リードオンリーメモリ（ＲＯＭ）、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、入力／出力（Ｉ／Ｏ）メカニズム、および、動作中にマイクロプロセッサをサポートするその他の回路が含まれている。ＩＣカードは、そのメモリ内に、単一のアプリケーションを有していてもよいし、あるいは、複数の独立したアプリケーションを有していてもよい。ＭＵＬＴＯＳTMは、他のプラットフォームの中でもとりわけＩＣカード上で動作し、そのカード上で複数のアプリケーションの実行を可能にするマルチアプリケーションオペレーティングシステムである。これにより、カードユーザは、そのカードを使用するために挿入した端末（即ち、ＡＴＭ、電話および／またはＰＯＳ）の種類に関わらず、そのカードに保存された多数のプログラム（例えば、クレジット／デビット、電子マネー／財布、および／またはロイヤリティアプリケーション）を実行することができるようになる。
テレフォンカードおよび電子キャッシュカードのような従来の単一アプリケーションＩＣカードは、カードユーザに与えられる前に、その製造の時点で、単一のアプリケーションを付与される。しかし、たとえカードユーザまたはカード発行者がアプリケーションの改変を望んだとしても、カード発行後にアプリケーションを改変または変更することはできない。さらに、あるカードユーザが、そのユーザに対して発行されたＩＣカードに、様々なアプリケーション機能、例えば、電子財布およびクレジット／デビット機能の両方を果たして欲しい場合、カードユーザは複数の物理的カードを持ち運ばなければならない。これは、非常に煩雑で不便である。アプリケーション開発者（application developer）またはカードユーザが、２つの異なるアプリケーション間での相互作用またはデータ交換、例えば、財布機能がフリークエントフライヤーロイヤリティアプリケーションと相互作用することを望んだ場合、カードユーザは、カードを入れる端末に複数のカードを代わる代わる出し入れしなければならず、処理が、困難で、時間がかかり、不便なものになる。
従って、同じＩＣカード上に複数アプリケーションを保存することは有益である。例えば、カードユーザは、同じカード上に財布アプリケーションおよびクレジット／デビットアプリケーションの両方を有し、買物を行うときにどちらの種類の支払い（電子キャッシュまたはクリジットカード）を使用するのかを選択し得る。十分なメモリが存在し、且つ、複数のアプリケーションをサポートできるオペレーティングシステムがカード上にあれば、１枚のＩＣカードに複数のアプリケーションを付与することができる。複数のアプリケーションを予め選択して、それらを製造段階でカードのメモリ内に入れておくことも可能であるが、必要に応じて、製造後に、そのカードのアプリケーションをロードおよび削除できるようにすることも有益であろう。
１枚のカード上に複数のアプリケーションを保存する向上した柔軟性および性能は、個々のカードとアプリケーション提供者との間で交換され、また、アプリケーション間で情報を通信する際に全システム内で交換される情報（アプリケーションコードおよび関連するデータを含む）の完全性および安全性に関して克服すべき新たな課題を生み出す。
例えば、同じカード上での複数のアプリケーションの存在は、２つのアプリケーション間のデータの交換を（内１つのアプリケーションが実行されている間）可能にする。上述のように、フリークエントフライヤ（frequent flyer）ロイヤリティプログラムは、電子パース（purse）アプリケーションの実行中にアクセスされる必要があり得る。データがアプリケーション間において安全でない方法でパスされた場合、トランザクションを監視する第三者にとって、送信されるデータのコンテンツ、あるいは他の１つまたは両方のアプリケーションに関連した個人的なデータのコンテンツさえをも決定することが可能となり得る。よって、アプリケーションアーキテクチャ、およびメモリ組織（ＩＣカード上に存在する他のアプリケーションと交換可能であるときに、アプリケーションのデータが、第三者により発見されることから保護する）を提供することは有益である。
従って、本発明による実施形態の目的は、アプリケーションアーキテクチャ、および向上したセキュリティを有するアプリケーション間におけるデータ相互作用を提供し、複数のアプリケーションが、所望のタスクまたは機能を行う間、アクセスされることを可能にするメモリ組織を提供することである。
発明の要旨
本発明は、アプリケーションアブストラクトマシン（application abstract machine）（ＡＡＭ）と呼ばれるＩＣカード用の多数のアプリケーションアーキテクチャ、およびそのアーキテクチャを実現するための方法を提供する。複数のアプリケーションを処理することは、少なくとも１つのアプリケーション（「第１のアプリケーション」）、少なくとも２つのセグメントを含むデータメモリスペース、揮発性メモリセグメントおよび非揮発性メモリセグメントを生成すること、第１のアプリケーションの指示（第１のアプリケーションから委任されるアプリケーションへの実行を委任または切り換え、それを行う際に第１のアプリケーションに関連した論理データメモリスペース内の第１のアプリケーションにより生成される任意のデータを保存する指示）を開始すること、第２のアプリケーションの指示を実行することと、保存されたデータを取り出すこと、ならびにこのデータと共に第１のアプリケーションの指示の実行を完了することにより達成される。
追加の委任コマンドは、第２のアプリケーションまたは他の後に続くアプリケーションにより発せられ得る。委任されたコマンドは、端末から直接的に発せられた選択コマンドと同じ様式において、委任されたアプリケーションにより解釈される。従って各アプリケーションは、端末がコマンドを発している場合と同じレベルにおいて、セキュリティ機能を行う。
揮発性メモリセグメントは、さらにパブリック（“Public”）およびダイナミック（“Dynamic”）部分へと分割され得る。データは、データメモリのパブリック領域に格納された場合、複数のアプリケーションおよび／または端末間において交換可能である。ダイナミックメモリ領域は、実行されている特定のアプリケーションにおける一時的なワークスペースとして単独的に用いられ得る。
【図面の簡単な説明】
本発明の例示的な実施形態を示す添付の図面に関連して以下の詳細な説明を読むことにより、本発明のさらなる目的、特徴および利点が明らかになるであろう。
図１は、データメモリスペースセグメント、およびＡＡＭ組織を用いるＩＣカードアプリケーション用の関連したレジスタ示すブロック図であり、
図２は、コードメモリおよびＡＡＭアーキテクチャを用いたＩＣカードアプリケーション用のデータメモリスペースを示すブロック図であり、
図３は、１つのアプリケーションから別のアプリケーションへの委任機能の要求を行う工程を示すフロー図であり、
図４は、委任アプリケーションにおける、委任側（delegator）アプリケーションへの返還委任制御機能を行う工程を示すフロー図であり、
図５は、委任機能の照会委任者ＩＤ要求を行う工程を示すフロー図であり、
図６は、本発明によるプラットフォームとして用いられ得るＩＣカードチップのブロック図であり、
図７Ａ、７Ｂおよび７Ｃは、３つのアプリケーション間においてなされる複数の委任呼出しを図示する。
そうでないことが記載されている場合を除き、全図面を通して、同じ参照番号および文字は、例示された各実施形態において同じ特徴部、部材、構成要素および部分を示すために用いられている。さらに、以下で図面を参照しながら本発明を説明するが、これは例示的な実施形態に関する説明である。添付のクレームによって規定される本発明の真の範囲および趣旨から逸脱することなく、記載された実施形態に変更および改変を加えることが可能であることが意図されている。
本発明の詳細な説明
本発明の実施形態は、アクセスおよび実行され得るＩＣカードに格納された関連したデータを備える複数のアプリケーションプログラムを処理する方法および装置を提供する。カードに格納されたアプリケーションは、端末により、もしくは他のインターフェースデバイス、または別のアプリケーションにより選択され得る。実行されるときにＩＣカードに格納される各アプリケーションプログラムは、プログラムのソフトウェアコード（ＩＣカード上に位置したプロセッサにより実行される指示）、およびプログラムの実行中にアプリケーションが格納し、使用する関連データにより組織化されたメモリスペースを割り当てられる。
例えば、マルチアプリケーションカードは、パースアプリケーションあるいは電子マネーアプリケーション、ならびにフリークエントフライや賞などの特定の得意客アプリケーション（loyalty application）を格納し得る。各アプリケーションは、ソフトウェアコードおよびそのソフトウェアコードの実行をサポートする付随データを有している。各アプリケーションには、実行時においてメモリ空間が割り当てられる。この例においては、カード上に格納された２つのアプリケーション間にインタラクションが存在する。購入を行うために電子的に支払われたドル毎につき、ユーザにはフリークエントフライヤマイルが１つ与えられ得、フリークエントフライヤプログラムによって格納され処理され得る。パースアプリケーションはカード上に格納された特定の得意客プログラムを認識している必要はなく、代わりに、カード上に格納された任意の得意客プログラムと連絡するための命令を含み得る。得意客プログラムは、カードのユーザについての現在のフリークエントフライヤマイルの、自身の格納データを更新できるように、特定の電子値の量を表す入力データを要求する。
同じトランザクション中に２つのアプリケーションが連絡する必要があるときには、両方のアプリケーションを効率的かつ安全な方法で処理するためのシステムアーキテクチャが必要である。１つのアプローチとしては、両方のアプリケーションが同時に実行され得る、ウィンドウズタイプのモデルがあり得る。しかし、現在は、ＩＣカードプラットフォームは同時に複数のプログラムを効率的に動作させるほどパワフルではない。また、転送されたデータは第３者による望まれないアクセスにさらされ得る。この問題に対処するために、以下により詳細に説明する本発明に基づく実施形態は、安全な方法でアプリケーションの実行を選択的に中断する。これにより、アプリケーションのデータの完全性を維持する事が可能にされ、ＩＣカード上の利用可能なメモリ空間の至適な利用を可能にする。
ＩＣカードにおけるマルチアプリケーションを処理するための効率的なアーキテクチャは、アプリケーションアブストラクトマシン（ＡＡＭ）アーキテクチャと呼ばれ、本明細書において説明している。ＡＡＭアーキテクチャは、ハードウェアに関係なく任意のプラットフォームに適用し、多くの異なるタイプのプラットフォームを渡って移動可能なＩＣカード（例えば、異なる製造者によって異なるプロセッサ構成で構築されたＩＣカード）上に格納するアプリケーションを、そのプラットフォームの特定のハードウェアに関する知識を必要とすることなしに開発者が書くことを可能にする。
格納され各アプリケーションによって使用されるデータのためのメモリ割り当ておよび組織化を指す用語である、アプリケーションアブストラクトマシン（ＡＡＭ）は、ＩＣカード上に格納されカード上のプロセッサによって実行される各アプリケーションに対して作成される。データがＩＣカード上で実行されるアプリケーション間を転送される際のデータの完全性およびセキュリティを完全にするために、ＩＣカード上の１つのアプリケーションのみが同時に実行可能である。各アプリケーションは、ＩＣカードメモリ中で利用可能な物理メモリアドレス上に仮想的に割り当てされてマッピングされる、データメモリ空間を有する。次にデータは、外部端子またはＩＣカードが安全にインタラクトしているデバイスへのデータの転送と整合性のある方法で、特定されたメモリ位置内の２つ以上のアプリケーション間で渡される。一般的なレベルでは、実行中の各アプリケーションについて作成される各ＡＡＭ空間は２つの別々のアドレス空間、すなわちプログラムコード自体に１つと、格納されているおよび／またはアプリケーションに用いられるプログラムデータに１つを含んでいる。プログラムデータアドレス空間は実効的に、スタティックセグメント、ダイナミックセグメント、およびパブリックセグメントの３つのセグメントに分割されている。これらのセグメントを図１を参照して詳述する。前述のように、スタティックセグメント、ダイナミックセグメント、およびパブリックセグメントは、物理メモリに論理的にマッピングされる。これらは、物理メモリセグメントではなく、仮想メモリセグメントである。ＡＡＭデータアドレス空間は好ましくは、７つの異なるアドレスレジスタおよび２つの制御レジスタを用いて、アドレスおよび処理される。
図１は、本発明とともに用いられるアプリケーションに対して作成される論理データ空間割り当て１０１の例示図である。ＡＡＭデータ部分１０１は、スタティックデータ空間１０３、パブリックデータ空間１０５、および、ダイナミックデータ空間１０７を有している。また、以下の一連のアドレスレジスタを示している：スタティックベースアドレスレジスタ１０９、スタティック先頭アドレスレジスタ１１１、パブリックベースアドレスレジスタ１１３、パブリック先頭アドレスレジスタ１１５、ダイナミックベースアドレスレジスタ１１７、ダイナミック先頭アドレスレジスタ１２１、および、アプリケーションの実行中においてダイナミックデータ空間中のローカルスタックフレームポインタとして機能するローカルベースアドレスレジスタ１１９である。アドレスレジスタは、物理メモリアドレスを含み得るが、好ましくはハードウェア独立的にするために様々なデータアドレス空間のためのオフセットアドレスを含んでいる。全アドレス空間の一例は６４Ｋバイトであるが、サイズは、適用可能なプラットフォームおよび利用可能なメモリサイズに応じて変化する。レジスタはポインタとしても考えられるし、その他の任意の従来のアドレシング機構であってもよい。
割り付けられたＡＡＭデータ空間１０１内において、メモリのスタティック部分は、ＩＣカードからパワーを取り外した後に消去されない不揮発性であり（ＥＥＰＲＯＭ等）、ダイナミック空間は、カードからパワーを取り外した後に消去され得る揮発性であり（ＲＡＭ等）、パブリック空間も揮発性のである（ＲＡＭ等）。ＩＣカードは、電源が端末と接続された後に端末からパワーを受け取る。ＩＣカードは、メモリおよび回路のためにある程度の電力を維持するためのバッテリを含み得るが、典型的に、揮発性メモリはＩＣカードがその電源から取り外された後に消去される。
このように定義されたＡＭＭデータ空間は、アプリケーションがポインタおよびオフセット演算を行うことができるように、各セグメント内に連続する複数のバイトを有する。例えば、セグメントアドレス「１５１５」および「１５１６」、または任意の他のシーケンシャルな数の対が両方共有効であり且つ同じセグメント内に存在する場合、それらのセグメントアドレスは隣接するバイトをアドレシングする。これにより、レジスタに格納されたオフセット値から所望のメモリアドレスの位置を決定することが可能になる。スタティックセグメントの１番目のバイトのセグメントアドレスはゼロであり、スタティック領域内の所与の位置のセグメントアドレスはそのオフセットに等しい。
スタティックデータの他の特定の領域に対するポインタは、スタティックデータ内に格納され得る。なぜなら、スタティック領域は不揮発性だからである。例えば、カードユーザの名前がクレジット／デビッドアプリケーションのスタティックメモリ内に格納されている場合、カードユーザの名前が常に、メモリのスタティック部分の開始位置上の５番目のメモリ位置に格納されていることが、アプリケーションには分かる。この位置は、ＳＢ［５］、即ちスタティックボトム上の５番目のバイト、として表記され得る。スタティックメモリは不揮発性なので、各トランザクションの後に消去されることはなく、スタティックセグメントアドレスレジスタに対するそのアプリケーションの相対位置がアプリケーションには常に分かる。
一方、ダイナミックまたはパブリックセグメント内の任意の位置のセグメントアドレスは、それらのセグメントの内容は各オペレーション毎に異なるので、各セグメントの開始位置からの特定のオフセットに常に等しいわけでわない。ダイナミックセグメントの４番目の位置は、アプリケーションによって行われる各オペレーション毎に異なる。好ましくは、ダイナミックまたはパブリックセグメントにおけるあるメモリ位置のアドレスは、１対のコマンド−応答オペレーションの間だけ固定される。ダイナミックまたはパブリックにおけるセグメントアドレスは固定されていないので、ＭＵＬＴＯＳ実行可能言語（ＭＥＬ）TM命令（または、任意の他のプログラム命令）は、セグメントアドレスのみを用いてデータを参照することはできない。好ましくは、ＩＣカードシステムで取出し、操作、転送および／または格納すべきデータを特定するために、標識付きアドレスが用いられる。
標識付きアドレスは、３ビットの標識（アドレス登録番号）と１６ビットのオフセットとからなる１９ビットの値である。そのＡＡＭデータ空間用の７個のアドレスレジスタは、それぞれ、セグメント物理アドレスを含む。例えば、アドレスレジスタＳＢ１０９およびＳＴ１１１は、スタティックの境界を指し、アドレスレジスタＰＢ１１３およびＰＴ１１５は、パブリックの境界を指し、アドレスレジスタＤＢ１１７およびＤＴ１２１は、ダイナミックの境界を指している。各セグメントについて、一番上のレジスタは、最終有効バイトの直後のバイトを指す。例えば、スタティックの最終有効バイトはＳＴ［−１］である。レジスタＬＢは、スタックフレームポインタとして機能する。これは、ダイナミックセグメント内のある位置を指し、これにより、現在実行中のアプリケーションの特定のローカルデータバイトを示す。
図１を参照して、割り付けられたスタティックセグメント１０３は、アプリケーションの不揮発性データを含む。スタティックデータは、カードユーザの名前、口座番号、ＰＩＮ値およびアドレス等、各トランザクションについて各アプリケーションに関連付けられたデータを含む。スタティックデータは、そのアプリケーションを用いた将来のトランザクションのために格納される可変データをも含む。例えば、パーストランザクションの場合、電子的値データは、スタティックセグメントから読み出され、その後そのトランザクションの最後にスタティックセグメント内にセーブされる。さらに、クレジット／デビッドアプリケーションの場合、トランザクション情報データまたは利用可能なクレジット限度がスタティックデータに格納される。
スタティックデータは、レジスタＳＢ（スタティックベース）およびレジスタＳＴ（スタティックトップ）をオフセットレジスタとして用いてアドレシングされる。これらのレジスタは、ＩＣカード上のメモリ内の物理的アドレスからのオフセット値を有する。その後、個々のメモリ位置は、ＳＢ［３］またはＳＴ［−５］のような開始地点からさらにオフセットされる。ＳＢはゼロと規定され、ＳＴは、アプリケーションをＩＣカード上にロードする際に設定されるそのアプリケーションのスタティックデータの大きさに等しい。マルチアプリケーションオペレーティングシステムは、特定のアプリケーションのスタティックセグメント内に格納されたデータを他のいかなるアプリケーションも読み出したり書き込んだりできないことを確実にする。現在の技術を用いる場合、スタティックセグメントは、好ましくは、不揮発性であるＥＥＰＲＯＭ（電気的消去可能読出し専用メモリ）上にマッピングされる。
ダイナミックセグメント１０７は、アプリケーションの揮発性すなわち一時的データを含む。ダイナミックデータは、演算または計算用変数に用いられる中間値などの、アプリケーションの実行中に一時的に用いられるデータを含む。例えば、パースのアプリケーションは一時的に、パース内の値を低下させるためにトランザクションの値を格納し得る。一時的データは、ほぼ、従来のコンピュータプログラムが、割り当てられた動作を実行するためにＲＡＭを用いた様式で用いられる。ダイナミックセグメントは、好適には、２つの部分、すなわち、セッションデータ部分とスタックデータ部分とに分割される。セッションデータのサイズは、各アプリケーション毎に一定であり、アプリケーションがロードされたときに決定される。スタックは、実行中の特定のトランザクションに独自の可変データを保持する。スタックデータ部分は、後入れ先出し様式で、データを格納する。スタックは初期には空であるが、アプリケーションの実行中に拡大収縮する。
ダイナミックデータは、レジスタＤＢ１１７からレジスタＤＴ１２１にアドレスされる。レジスタＬＢ１１９は、委任コマンドまたは機能呼出し用の、ダイナミックセグメント内の特定のメモリ位置へのローカルスタックフレームポインタとして作用する。レジスタＬＢ１１９は、最上位のフレーム、すなわち、現在実行中の機能のセッションデータのフレームをアドレスするために用いられる。レジスタＤＴ１２１は、スタックポインタ用のアドレスオフセットとして作用する。スタックの上の１バイトデータアイテムは、ＤＴ［−１］としてアドレスされ、その下のバイトは、ＤＴ［−２］としてアドレスされ、以下同様である。プッシュ動作は、すスタック上の各アイテム用のＤＴの相対的値をインクリメントし、ポップ動作は、スタック上の各アイテム用のＤＴの相対的値をデクリメントする。例えば、ＤＴ［−５］に位置するデータエレメントは、追加のデータアイテムがスタック上に置かれた後に、ＤＴ［−６］に位置する。
アプリケーションが実行されているとき、そのアプリケーションのために作成されたダイナミックセグメントは、割り当てられたタスクまたは動作を実行する際に用いられるアプリケーションのセッションデータをも含む。複数アプリケーション動作システムは、特定のアプリケーションのダイナミックセグメント内に格納されたデータを読出し得る、または書込み得るアプリケーションは他にないことを保証する。セッションデータは、アプリケーションの実行が開始されると、ゼロに設定される。アプリケーションがタスクまたは動作を別のアプリケーションに委任した場合、スタックデータは、スタック内に保存される。
１つのアプリケーションが、それ自体でコマンドを処理するかわりに、コマンドを処理する別のアプリケーションを選択すると、委任機能が発生する。委任機能の例は、委任側アプリケーションが、それ自体が認識しない、または処理するようにプログラムされていないコマンドを受け取ったときに発生する。選択されたアプリケーションは、コマンドを拒否してインターフェースデバイス（ＩＦＤ）にエラー応答を供給するべきではなく、コマンドを適切な受信部または委任されたアプリケーションにパスすべきである。委任を行うため、委任側は委任プリミティブを呼び出す。委任プリミティブは、動作システムが委任命令を遮断したときに実行される、複数アプリケーション動作システムによって認識されるサブルーチンである。プリミティブは、動作システムがインストールされたときに、動作システム自体の一部として格納され得、別のルーチンとしてロードされ得る。プリミティブは好適には、より高いレベルの言語で書かれ得るが、迅速に実行され得るように、コンピュータで実行可能な言語で書かれる。委任コマンドが実行されると、委任するアプリケーションの実行が中断され、代わりに委任されたアプリケーションが実行される。委任されたアプリケーションはその後、ＡＡＭアーキテクチャに従って、それ自体のデータメモリ空間を生成する。データがアプリケーション間でパスされ得るように、第１のアプリケーションのパブリックメモリ空間（ＲＡＭに格納された）内に格納されたデータは、第２のアプリケーションのパブリックメモリ空間（各アプリケーション間で物理的には同一のメモリであり得るが別々に割り当てられている）に送信される。ダイナミックデータは秘密であるためデータは委任側および委任されたアプリケーションが実行される前に初期化された他の部分のためのスタック内に保存されるが、ダイナミックメモリ空間はさらにシェアもされる。
大抵の場合において、委任されたアプリケーションは、コマンドが恰もインターフェイスデバイスから直接到着したかのように、コマンドを処理する。委任されたアプリケーションは、コマンドを処理し終え、割り当てられた公開メモリセグメント内に応答を書き込み終えたとき、ノーマル状態に抜け出る。次に、委任側は、委任プリミティブと呼ばれる実行命令に続いて、委任アドレスにおいて実行を再開する。委任されたアプリケーションにより生成される応答は、割り当てられた公開メモリスペースから取り出されるか、またはアクセスされる。続いて、委任側アプリケーションは、単に抜け出して応答をＩＦＤに送信し得るか、または抜け出す前にさらなる処理を実行し得る。
委任処理の別の例は、二つのアプリケーションがデータを共有しなければならないときに起こる。コマンドＢを処理するときに、アプリケーションＡが常にデータアイテムＮを返す場合、コマンドに応答して同様にデータアイテムＮを返す別のアプリケーションは、ＩＣカード上に格納されているコードを複製する必要を低減するために、アプリケーションＡに機能Ｂを委任し得る。例えば、アプリケーションが実行される前に、ＰＩＮがチェックされなければならない場合、カード上に格納されたアプリケーションは、格納された汎用ＰＩＮをカードに対して返すＰＩＮアプリケーションに、「ＰＩＮ検索機能」を委任し得る。
好適には、例えば端末などのＩＦＤが、アプリケーションを首尾良く選択するときは常に、たとえトランザクション中にそのアプリケーションが前もって選択されていたとしても、新規のセッションが開始する。例えば、カードユーザが端末に行き、パースアプリケーションを用いて２０ドルの電子キャッシュを伝送して、クレジット／デビットカードアプリケーションを用いて３０ドルを支払うので、再びパースアプリケーションを用いて１０ドルを伝送する場合、全体のトランスアクションの間には、２つのアプリケーションしか使用されなかったのに、３度の個別セッションが起こっている。アプリケーションがタスクまたは機能を別のアプリケーションに委任する毎に、委任されたアプリケーションは、恰もＩＦＤデバイスがそのタスクまたは機能を実行するためのアプリケーションを選択したかのように、委任機能を取り扱う。しかしながら、以下に述べるような委任機能を実行することは、セッションデータ上で異なった効果を有する。
以下の例は、セッションデータが、初期化される（即ち消去される）ときと、さらなる処理において格納されるときとの対比を説明する手助けとなる。ＩＦＤデバイスにアプリケーションＡが選択され、端末からコマンドＸ、Ｙ、およびＺを受け取った場合、アプリケーションＡは、３つのコマンドすべてをアプリケーションＢに委任し得る。例えば、委任は、プログラムコード内の委任コマンドに応答して起こり得る。アプリケーションＡおよびＢの両方は、コマンドＸを受け取るとき、それぞれのダイナミックセグメント内のセッションおよびスタックデータを初期化されて（０に設定されて）有するが、後続のコマンドＹおよびＺを受け取るとき、スタックは初期化されない。
第２の例では、アプリケーションＡが選択され、端末からコマンドＸ、Ｙ、およびＺを受け取る。アプリケーションＡはＸ自体を処理するが、ＹおよびＺをアプリケーションＢに委任する。アプリケーションＡは、コマンドＸを受け取るとき、セッションおよびスタックデータを初期化されて有するが、後続のコマンドＹおよびＺを受け取るときは初期化されない。アプリケーションＢは、コマンドＹを受け取るとき、セッションおよびスタックデータを初期化されて有するが、Ｚを受け取るときは初期化されない。
セッションデータの使用の一例として、セッション個人識別番号（PIN）の使用をサポートすることが挙げられる。アプリケーションは１バイトのセッションデータを確保（reserve）して、PIN受け取りフラッグをサポートする。PINチェックコマンドを受け取ると、選択された委任アプリケーション（delegated application）は、以下のようにフラグを更新し得る。PINコマンドが受け取られ、入力されたPINコマンドが格納されたピンに等しい場合、セッションデータＤＢ［0］が１に設定される。そうでない場合には、アプリケーションは、ＤＢ［0］の値をチェックすることにより、PINフラグが既に設定されているかどうかをチェックする。上記いずれの場合においても、PINは検証済みなので、アプリケーションはセッション内の残りのコマンドを処理する。いずれの場合にも該当しないならば、PINは適切ではないので、アプリケーションはコマンドを処理する。PINチェック機能は、選択されたアプリケーションからPINチェックアプリケーションに委任された機能であり得る。
公用セグメント（Public segment）１０５は、IFDとアプリケーションとの間でやりとりされるコマンドおよび応答のために用いられる。委任コマンドの間、公用セグメントは、２つのアプリケーションと、デリゲータ（委任を始めるアプリケーション）と、委任アプリケーション（委任機能を実行するアプリケーション）との間でやりとりされるデータを含む。アプリケーションはまた、必要な場合には、さらなる一時機能格納空間として公用セグメントを用い得る。公用データは、開始アドレスとしてレジスタＰＢ１１３に格納されたオフセットを用いて、終了アドレスとしてレジスタＰＴ１１５へとアドレスされる。コマンド応答対（command-response pair）がIFDまたはデリゲータによって初期化される期間、レジスタＰＢ１１３およびレジスタＰＴ１１５が固定される。公用データは、ＩＣカード上に存在するアプリケーションによって要求または使用された取引金額（transaction amount）、ベンダ識別データ、端子情報、伝送フォーマット、または他のデータ等の端子に入力されたデータ、またはその端子によって供給されたデータを含み得る公用データはまた、IFDデバイス、もしくは、端子または他の委任アプリケーションによって要求または使用された電子ドル値、カードユーザ情報伝送フォーマット、または他のデータ等の他のアプリケーションに伝送されるデータを含み得る。
多重アプリケーションオペレーティングシステムは、公用セグメントに格納されたデータが、アプリケーションが終了するまたは委任するまで、アプリケーションに対して秘密の状態を確実に維持する。好適には、公用セグメント内のデータは、以下のように、他のエンティティに対して利用可能になる。（１）アプリケーションが委任すると、委任アプリケーションに対して、公用セグメント全体が利用可能になる。（２）アプリケーションが終了し、かつ、それ自体が他のアプリケーションによって委任された場合、デリゲータに対して、公用セグメント全体が利用可能になる。（３）アプリケーションが終了し、かつ、それ自体が委任されない場合、IFDに対して、Ｉ／Ｏ応答パラメータおよびデータを含む公用セグメントの一部分が利用可能になる。
アプリケーションの実行の間、アプリケーションは秘密データを公用メモリセグメントに書き込み得るが、アプリケーションは、委任または終了の前に、公用セグメントの秘密部分に確実に上書きする必要がある。アプリケーションが異常終了（アベンド）した場合、好適には、ＩＣカード上のオペレーティングシステムが、望ましくないエンティティが秘密データにアクセスできないように、公用セグメント内の全データに自動的に上書きを行う。MULTOSキャリアデバイス（ＭＣＤ）がリセットされた場合、秘密データが明らかにならないように、オペレーティングシステムは、公用セグメント内のデータに自動的に上書きを行う。公用メモリセグメントの一部分は、通信バッファとしても使用される。Ｉ／Ｏプロトコルデータおよびパラメータは、好適には、公用メモリ空間の先頭に格納される。別の好適な実施形態において、先頭の１７バイトは、IFDデバイスとＩＣカードアプリケーションとの間の通信プロトコルのために確保される。しかし、より多いバイトまたはより少ないバイトが、初期化された特定のアプリケーションおよびオペレーティングシステムに基づいて使用され得る。
図１におけるメモリセグメント間の空間は、特定のアプリケーションおよび処理されるコマンドによって変化する。メモリセグメント間にメモリ空間はなく、それによりメモリセグメントは連続する。
図２は、ＡＡＭ実施アーキテクチャの拡大図を示す。データメモリ空間２０１は、前述した３つのセグメントであるスタティック、パブリック、およびダイナミックを含む。コードメモリ空間２０３は、ＩＣカード上に格納されるアプリケーションのためのプログラム命令を含む。アプリケーション命令は、好ましくは、常駐オペレーティングシステムによって解釈され得る実行可能な形式で格納され得るが、マシン実行可能な形式でも格納される。命令２０５は、コードメモリ空間２０３における１つの位置で格納される。追加の命令は、メモリ空間２０３の他の位置に格納される。２つの追加のレジスタ２０７および２０９は、ＡＡＭアーキテクチャで使用される。コードポインタ（ＣＰ）レジスタ２０７は、次に実行される特別なコード命令を示す。図において、レジスタは、例えばオフセットまたはポインタ手段によって命令２０５が次に実行されることを示す。状態制御レジスタ２０９は、８つのビットを含み、その内の４つが個々のアプリケーションに依って使用されるためにあり、その内の４つは命令の実行の結果に依存して設定またはクリアされる。これらの状態コードは、ブランチ、コール、またはジャンプといった状態命令によって使用される。それらの状態コードは、キャリービット、オーバーフロービット、ネガティブビット、およびゼロビットを含む。
全てのアドレスおよび制御レジスタは、選択された、または委任されたアプリケーションを実行する前に、規定された値に設定される。その値は、アプリケーションがまずカード上にロードされ、コードおよび不揮発性データのサイズが割り当てられ得る時、またはアプリケーションがそのアプリケーションに対して制御をパスする時のいずれかで設定される。アプリケーションがロードされると、ＳＢはゼロに設定され、ＳＴはアプリケーションのスタティックデータベースにおけるバイト数と等しく設定される。アプリケーションが制御を与えられると、他のアドレスレジスタは初期化される。ＣＰ２０７は、ゼロに設定され、ＣＣＲ２０９における全ての８つのビットは、アプリケーションの実行開始時にクリアされる。
通信インタフェースメカニズムは、ＩＦＤとコマンド応答パラメータ用通信バッファとしてのパブリックデータセグメントの使用を含むアプリケーションとの間に存在する。コマンド応答パラメータは、アプリケーションが実施するコマンドを与えられることを意味し、且つコマンドを発行するエンティティを応答を返す。アプリケーションは、ＩＦＤ−アプリケーションインタフェースにわたってコマンドを受け取ること、それらを処理すること、および応答を返すことによってＩＦＤと相互作用する。アプリケーションがコマンドの実行を完了した場合、アプリケーションは、ＩＦＤ装置によって読み出され得るＰＢ［０］で開始するパブリックセグメント中に応答を配置し、ＰＴ［０］に関して、確保されたパブリック空間における適切なインタフェースパラメータを設定する。
アプリケーションがＩＦＤから直接呼び出され得、且つＩＦＤに直接応答を返し得る場合、アプリケーションは要求を適切な場所にある別のアプリケーションに委任し得る。次に、引き続いて呼び出されるアプリケーションは、その要求を第１のアプリケーションに代わって処理する。委任は、受け取られたコマンドに直接応答し得、そこで委任側は、他の適切なアプリケーションに対してコマンドまたはサブコマンドを委任するためのコントローラとして作用する。あるいは、第１のアプリケーションが、フリークエントフライヤマイルの更新、またはＰＩＮの検証といったアプリケーションの実行中に別のアプリケーションと相互作用する必要がある場合、委任されたコマンドは、プロセッサの制御を委任するアプリケーションコード中に組み込まれ得る。
図３は、委任要求が実行された場合に実施されるステップのフローチャートを示す。ステップ３０１では、delegator_application_id（委任側ＩＤ）と名付けられたパラメータをselected_file.application_id（選択されたＩＤ）と等しく設定する。選択されたＩＤは、選択されており、かつ現在実行中である現在のアプリケーションを示す。委任側ＩＤは、ＩＣカードに格納された別の委任されたアプリケーションに機能を委任するアプリケーションを示す。次に、ステップ３０３では、委任側ＩＤをdelegate_id_stack（委任スタック）の上位にプッシュ（格納）する。割り当てメモリのダイナミック部で参照されたデータは、委任された機能が完了された後に現在のアプリケーションが実行を完了し得るように保存される。委任されたアプリケーションと共有されるデータは、割り当てメモリのパブリック部で参照される。委任スタックは、好ましくはアプリケーションのＡＡＭメモリ空間の外部に格納され、アプリケーションが委任された機能を有していることを憶えておく。各アプリケーションは、アプリケーションが機能を委任する場合に中断され、複数のアプリケーションが委任要求のために中断された場合、適切なアプリケーションが正しい順序で開始されるようなラストインファーストアウト（ＬＩＦＯ）方式で委任スタックが動作する。従って、多層化された委任機能が実施される場合に、委任スタックは、アプリケーションが最後の委任側であることを憶えている。委任スタックは、異なるスタックスキームが適切に使用され得るけれども、好ましくはＬＩＦＯ方式で動作する。
次に、ステップ３０５では、選択されたＩＤをdelegate_request.delegate_application_id（委任ＩＤ）値に設定する。このステップでは、委任された機能または複数の機能を実施するように呼び出されるアプリケーションを選択する。委任されたアプリケーションのアイデンティティは、委任側アプリケーションによって詳細に呼び出されるか、または特定の機能がルックアップテーブルにおけるアプリケーションと整合され得る。例えばＰＩＮ整合動作は、アプリケーションがカード上に存在することに依存して、異なるアプリケーションに委任され得る。次に、ステップ３０７では、application_commandパラメータをdelegate_request.application_commandパラメータに格納された値に設定する。このステップは、委任アプリケーションに委任されるコマンドを特定する。アプリケーションは典型的に、多くの異なるコマンドを処理する能力を有している。あるいは、全体のアプリケーションは１つ以上の機能を実施するように実行され得る。委任側アプリケーションは、別のアプリケーションに委任されているコマンドを選び得る。次に、ステップ３０９では、application_commandを被委任側アプリケーションによる実行用のＡＡＭオペレーティングシステムに送る。次に、委任側アプリケーションは、中断される（すなわち割り込まれる）。アプリケーション間をパスするように要求される任意のデータは、パブリックメモリ空間を介して転送される。
図４は、被委任側アプリケーションにより「リターン委任制御」コマンドを実施するためのステップのフローチャートである。委任されたアプリケーションがその委任された機能を完了した場合に、このコマンドはオペレーティングシステムにより実行される。ステップ４０１では、委任されたＡＡＭのパブリックメモリ空間からapplication_responsesを取得する。応答データは、被委任側ＡＡＭのパブリックメモリセグメント中にパスされる。次に、ステップ４０３では、delegate_response.status変数をサクセス状態に設定する。これは、委任動作が、成功に完了したことを意味する。ステップ４０５では、delegate_response.application_responsesパラメータを被委任側アプリケーションのパブリックセグメントに格納されているapplication_responses値に設定する。
ステップ４０７では、delegate_response.delegate_application_idパラメータをselected_file.application_id（委任アプリケーションＩＤ）に設定する。ステップ４０９では、delegate_id_stackから上位delegate_application_idをポップする（すなわちスタックに格納された最後のデータを読み出す）。この情報は、まさに委任され、委任されたアプリケーションにより完了されようとしているコマンドのための委任側アプリケーションのアイデンティティを示す。ステップ４１１は、select_file.application_id値をdelegator_application_id値に設定する。これは、実行を再開する現在のアプリケーションとして委任側ＩＤスタックから識別された委任側アプリケーションを選択する。委任側アプリケーション用のダイナミックデータは、その格納された位置から委任側アプリケーションのために取り出され、アプリケーションは実行し続ける。それによりアプリケーションはすべてのデータを元のまま残すが、また委任された機能からの応答情報を有する。ステップ４１３において、delegate_responseデータは、さらなる処理のため現在のアプリケーションに送られる。応答データは、全てのアプリケーションは物理揮発性メモリ空間を共有するため同一の物理ＲＡＭメモリ位置であるパブリックデータ空間をパスされる。
図５は、委任コマンドが委任されたアプリケーションにより受け取られた場合、委任側ＩＤについて調査するために必要とされるステップのフローチャートである。委任されたアプリケーションは、異なる委任側アプリケーションのための動作を別々に実施し得るので、委任側のアイデンティティを知ることを必要とし得る。例えば、エアラインロイヤリティプログラムは、与えられたフリークエントフライヤが実際のドルに基づいているか、またはランプの合計が、勘定支払動作を実施するようないくつかの他の活動性のために与えているかを知ることを必要とし得る。この情報は、委任されたアプリケーションに変数としてパスされ得るか、または調査を使用することを確実にされ得る。委任側調査動作は、前述のプリマティブとして実施され得る。
ステップ５０１では、ＡＡＭオペレーティングシステムからdelegator_id_enq_requestを受け取る。その要求は、委任側のアイデンティティを識別するために使用される。ステップ５０３では、delegate_id_stackが空であるかをチェックする。スタックが空であれば、委任動作は起こらず、アプリケーションは中断されない。従って、ステップ５１１は、delegator_id_enq_response.statusパラメータを失敗インジケータに設定する。次に、ステップ５１３では、delegator_is_enq_request.error_causeの値を「委任側アプリケーションなし」を示す値に設定する。委任側アプリケーションは無い。次に、処理はステップ５０９に続く。
delegate_id_stackが空でないならば、１以上の委任が起こる。その場合、ステップ５０５では、delegator_id_enq_response.statusパラメータを「成功」を示す値に設定する。次に、ステップ５０７では、delegator_id_enq_response.delegator_application_idパラメータをdelegate_id_stack.delegator_application_idに格納された値に設定する。これは、スタックの上位で委任側アプリケーションＩＤを示すことに応答する調査を設定する。前記で説明したように、スタックの上位での格納されたデータは、最後の委任側アプリケーションを示し、委任機能を呼び出す。次に、ステップ５０９では、delegator_id_enq_responseを情報を要求するアプリケーションまたはＩＦＤエンティティを配送するＡＡＭオペレータシステムに送り返す。
図６は、本発明と関連して使用され得るＩＣカードチップ上に配置された集積回路のブロック図の例を示す。集積回路チップは、カードにあるチップ上に配置されている。ＩＣチップは好ましくは、中央処理ユニット６０１、ＲＡＭ６０３、ＥＥＰＲＯＭ６０５、ＲＯＭ６０７、タイマ６０９、制御ロジック６１１、Ｉ／Ｏポート６１３、およびセキュリティ回路６１５を含む。それらは、従来のデータバス６１７または他の従来の手段により互いに接続されている。
スマートカードにおける制御ロジック６１１は、十分なシーケンシングおよびスイッチングを提供し、カードのメモリに入力／出力ポート６１２を介してアクセスする読み出し−書き込みを取り扱う。制御ロジック６１１に関連するＣＰＵ６０１は、計算の実施、メモリ位置へのアクセス、メモリ内容の改変、および入力／出力ポートの管理を含む多くの異なる機能を実施し得る。暗号アルゴリズムのような複雑な演算を処理するためのコプロセッサを含むＩＣカードもある。入力／出力ポート６１３は、カードと、情報をカードに転送し、かつ情報をカードから転送するＩＦＤとの間の通信に使用される。タイマ６０９（クロックパルスを発生および／または提供する）は、制御ロジック６１１、ＣＰＵ６０１、およびメモリアクセス、メモリ読み出しおよび／または書き込み、処理、およびデータ通信を含む機能を達成するステップのシーケンスにわたってクロック信号を必要とする他の構成要素を駆動する。セキュリティ回路６１５（オプションである）は好ましくは、入力／出力ラインを製造段階での試験のために必要とされるが、後のアクセスを防ぐために試験の終了をもって破壊される内部回路に接続する可溶性のリンクを含む。スタティックメモリ空間は好ましくは、不揮発性であるＥＥＰＲＯＭ６０５におけるメモリ位置にマッピングされる。ダイナミックメモリ空間は好ましくは、素早くアクセスできる揮発性メモリであるＲＡＭ６０３にマッピングされる。パブリックメモリ空間もまた好ましくは、揮発性メモリであるＲＡＭ６０３にマッピングされる。ダイナミックデータおよびパブリックデータは、ＲＡＭ６０３の異なる部分に格納される。ここでＲＡＭは好ましい不揮発性メモリとして識別され、ＥＥＰＲＯＭは好ましい揮発性メモリとして識別される。他のタイプのメモリもまた、同じ特性で使用され得る。
図７Ａ、７Ｂおよび７Ｃは、ＩＣカードにある複数のアプリケーションを処理するために実施される委任機能の例を示す。図７Ａは、２重丸７０１で示されるように実行される第１のアプリケーションを示す。第１のアプリケーションの実行中のある時点で、委任機能７０２は呼び出され、動作を丸７０３で示されるアプリケーションに委任する。図７Ａはまた、空の委任側ＩＤスタック７０５を示している。スタックは空であるので、スタックに関連するデータは無く、図示のためだけに示している。
複数のアプリケーションオペレーティングシステムは、委任コマンドを受け取り、第１のアプリケーション７０１に割り込み、集積回路の制御を図７Ｂで示すアプリケーション７０３に与える。第２のアプリケーション７０３の実行は、２重丸で示される。用語「制御を与える」は、カードにあるマイクロプロセッサおよび他の回路が、命令を処理し、委任されたアプリケーションにメモリ空間を割り当てることを意味する。委任コマンドが処理されると、委任側ＩＤ７０７がスタック７０５の上位に配置される。委任側ＩＤスタックは、ＬＩＦＯ方式で動作される。図７Ｂには、カード上に位置する第３のアプリケーション７０９をしめす。第２のアプリケーションの実行中のある時点で、委任機能７１１は呼び出され、動作を第３のアプリケーションに委任する。
複数のアプリケーションオペレーティングシステムは、図７Ｂに示される委任コマンド７１１を受け取り、第２のアプリケーション７０３の実行に割り込み、集積回路の制御を図７Ｃで示される第３のアプリケーション７０９に与える。委任コマンドが処理されると、第２のアプリケーションの委任側７１３は委任側ＩＤスタック７０５にプッシュされる。その実行が未だ割り込まれている第１のアプリケーションの委任側ＩＤ７０７は、ＬＩＦＯスタック管理と一致したスタック中にプッシュされる。従って、第３のアプリケーションがその実行を終えた場合、スタックの上位での委任側ＩＤはポップされ、第２のアプリケーションの実行がまず再開されることを示す。次に、第１のアプリケーションからの委任側ＩＤ７０７はスタックの上部にあり、それにより、第２のアプリケーションが実行を終えた場合に、第１のアプリケーションはその実行を再開する。
追加的なアプリケーションは、同様の方式で委任側ＩＤスタックにより管理され得る。アプリケーションの実行に割り込むことによって、委任コマンドが処理され、委任の順序を憶えていた場合に、個々のアプリケーションのためのデータのセキュリティおよび整合性が、重要なものとして維持され得る。それは、ＩＣカードが口座番号、社会保険番号、住所、および他の個人情報のようなカードユーザにとって秘密であるアプリケーションのためのデータを格納しているからである。
上記内容は、本願発明の原理を単に例示したものである。従って、本明細書には明示的に図示または記載しないが、本発明の原理を実施し、それにより、本発明の精神および範囲内にある多数のシステムおよび方法を、当業者が考案できることは理解される。
本開示の範囲は、請求された発明に関連するか否か、あるいは本発明で対処される課題の一部または全てを緩和するか否かに関わりなく、明示的または黙示的に開示された新規の特徴または特徴の組み合わせあるいはそれを一般化したものを含む。本出願は、本出願または本出願に由来する任意のさらなる出願の手続中に、そのような特徴に関する新しい請求項が作成され得ることの注意を促すものである。特に、付属の請求項に関しては、従属項に由来する特徴は、請求の範囲に挙げた特定の組み合わせのみならず、任意の適切な方法で独立項の特徴と組み合わせ得る。
【図１】
0004181641.tif 000002
【図２】
0004181641.tif 000003
【図３】
0004181641.tif 000004
【図４】
0004181641.tif 000005
【図５】
0004181641.tif 000006
【図６】
0004181641.tif 000007
【図７Ａ】
0004181641.tif 000008
【図７Ｂ】
0004181641.tif 000009
【図７Ｃ】
0004181641.tif 000010