JP2000514584A

JP2000514584A - 高級プログラミング言語を用いたマイクロコントローラ

Info

Publication number: JP2000514584A
Application number: JP10520562A
Authority: JP
Inventors: ジェイ．ウィルキンソンティモシー; ビー．グスレイスコット; クリシュナクシーラブディ; エイ．モントゴメリーマイケル
Original assignee: シュルンベルジェシステーム
Priority date: 1996-10-25
Filing date: 1997-10-22
Publication date: 2000-10-31
Also published as: DE69714752C5; PT932865E; DE69714752T2; US8726247B2; US20140245272A1; US20030023954A1; US9400668B2; JP2003141488A; US7117485B2; US20110126178A1; US7818727B2; MY126363A; CN1183449C; EP0932865A1; KR100329063B1; HK1021762A1; US20120254843A1; US6308317B1; US20080115117A1; BR9713267A

Abstract

(57)【要約】端末装置と共に利用されるＩＣカードである。当該ＩＣカードは、インタプリタと高級プログラミング言語形式を持つアプリケーションが記憶されたメモリを含んでいる。カードのプロセッサは、実行するアプリケーションをインタプリタ処理するためインタプリタを利用するように構成され、また、端末装置と通信するため通信部を利用するように構成されている。

Description

【発明の詳細な説明】高級プログラミング言語を用いたマイクロコントローラこの特許出願の開示内容の一部には著作権保護を受けるものが含まれている。著作権所有者は、特許庁への特許出願書類または記録として使用されるものに限り、何人でも当該特許出願書類の複製を行なうことに関して異議を持たないが、その他の場合にはすべての著作権の権利の保有する。米国法３５条セクション１１９（ｅ）に基づき、本特許出願は１９９６年１０月２５日に受理された先行する米国特許出願番号６０／０２９,０５７の優先権利益を要求する。発明の背景この発明は主にプログラミング技術に関し、特に、スマートカードまたはマイクロコントローラに使用する高級プログラミング言語に関する。高級プログラミング言語Ｊａｖａで記述されたソフトウェアアプリケーションは、そのままで多種多様なコンピュータブランド、多種多様なコンピュータプラットフォーム上で動作できるように作られている。これは以下の手続きによって達成される。アプリケーションがＪａｖａ言語によって記述された場合、当該アプリケーションは、Ｊａｖａ仮想マシンと呼ばれる仮想コンピュータに対する命令コードであるバイトコードを含む“クラス”ファイルにコンパイルされる。サポートされる各々のプラットフォームに対しては当該仮想マシンの実装プログラムが用意されている。利用者が使用するプラットフォームにおいて特定のＪａｖａアプリケーションを動作させたい場合、動作したいアプリケーションからコンパイルして生成したクラスファイルを当該プラットフォームにロードする。使用プラットフォーム上で構築されるＪａｖａ仮想マシンが動作し、クラスファイル中のバイトコードをインタプリタ実行し、Ｊａｖａアプリケーションが効率的に実行される。Ｊａｖａは、以下の参考文献において説明されている。（１）アーノルド、ケン、およびジェームス・ゴスリング「Ｊａｖａプログラミング言語」、アディソン -ウェズレー、１９９６；（２）ジェームスゴスリング、ビル・ジョイ、ガイ・スティール「Ｊａｖａ言語仕様」、サン・マイクロシステムズ、１９９６（ウェブサイト：http://java.sun.com/doc/language specification）；（３）ジェームス・ゴスリング、ヘンリーマックギルトン「Ｊａｖａ言語使用環境：ホワイトペーパー」、サン・マイクロシステムズ、１９９５（ウェブサイト：http://ja va.sun.com/doc/language environment/）；（４）ティム・リンドホルム、フランク・イェリン「Ｊａｖａ仮想マシン仕様」、アディソン-ウェズレー１９９７；これらのテキストその他多くのテキストにおいてＪａｖａを用いたプログラム作成方法が記述されている。特定プラットフォームにおいてＪａｖａアプリケーションを実行するために、プラットホームの制約条件下において動作しうるＪａｖａ仮想マシン実装プログラムが記述されていなければならず、また、当該プラットフォーム上に使用するＪａｖａアプリケーションを当該プラットホームの制約条件下においてロードできる仕組みが提供されていなければならない。Ｊａｖａをサポートする従来のプラットホームは、比較的容量の大きいメモリとハードディスクを利用する通常のマイクロプロセッサベースのコンピュータである。そのようなマイクロプロセッサ実装は、デスクトップコンピュータ、パーソナルコンピュータにおいて広く用いられている。しかしながら、スマートカードに使用されているようなマイクロコントローラ上で動作するＪａｖａ実装は従来にはなかった。マイクロコントローラは多く点においてマイクロプロセッサとは異なっている。例えば、マイクロプロセッサは典型的には、中央演算処理装置（ＣＰＵ）を備えており、ＣＰＵは正常な動作をするためには外部周辺装置（例えばメモリ、入力制御装置、出力制御装置）を必要とする。典型的なマイクロプロセッサは、メガバイトからギガバイトのメモリアクセスが可能であり、１命令で１６ビット、３２ビット、６４ビットまたはそれ以上の情報が処理できる。マイクロプロセッサとは対照的に、マイクロコントローラは、中央演算処理装置(ＣＰＵ)、メモリ、その他の機能要素すべてを１枚の半導体基板または１つのＩＣ回路（ＩＣチップ）として備えている。マイクロプロセッサが比較的大容量である外部メモリにアクセスするのに対して、典型的なマイクロコントローラはかなり小容量のメモリにアクセスする。典型的なマイクロコントローラは、１キロバイト〜１６キロバイトの内蔵メモリにアクセス可能であり、特に１６キロバイト内蔵メモリのものが広く使われている。一般的には、３つの異なるタイプのメモリ、ランダムアクセスメモリ(ＲＡＭ) 、リードオンリーメモリ(ＲＯＭ)、電気的に消去可能なプログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）が使われている。マイクロコントローラにおいて、利用可能な上記各種のメモリの容量は、当該メモリに割り当て可能なＩＣチップの面積容量の制限を受ける。典型的には、ＲＡＭは多くの面積を必要とし、供給されるメモリ容量はもっとも少なくなる。ＲＯＭはもっとも少ない面積で済み、供給容量は大きくなる。ＥＥＰＲＯＭは、ＲＡＭよりも供給容量は大きくなるが、ＲＯＭより供給容量は小さくなる。それぞれのメモリ種類の適する用途は異なっている。ＲＯＭはもっとも安価であるが、例えば、オペレーティングシステムのコードなど書き換えの必要のないデータの記憶用途に適している。ＥＥＰＲＯＭは、印加電圧がオフされた後も保持する必要のあるデータの記憶用途に適しているが、書き込み時間が非常に遅い。ＲＡＭはデータ書き込み、読み出しとも高速に実行できるが、高価であり、かつ印加電圧除去により記憶データが失われてしまう。マイクロプロセッサは、典型的には、比較的少容量のＲＯＭとＥＥＰＲＯＭを持ち、さらに１〜１２８メガバイトのＲＡＭを備えている。それは１つのＩＣデバイス上に何を搭載するかに関して制約がないからであり、また、ＥＥＰＲＯＭ (より)低コスト、大容量、書き換え可能、不揮発性の記憶媒体となる外部ディスクメモリにアクセスすることが可能であるからである。しかしながら、マイクロコントローラは、典型的には、０．１〜２．０キロバイトの小容量のＲＡＭと、２〜８キロバイトのＥＥＰＲＯＭと、８〜５６キロバイトのＲＯＭを備えている。外部コンポーネントが少なくかつサイズが小さいため、マイクロコントローラはスマートカードなどのＩＣカードに広く用いられている。このようなスマートカードには、使用時にカードリーダに挿入する必要がある接触式カードや、カードリーダに挿入する必要のない非接触式カードなど多様な形態がある。実際に、非接触式通信を行なうマイクロコントローラは、時計や指輪など特別な形状物に埋め込まれることがあり、エルゴノミックス性が高くかつ魅力的な方法でスマートカードの機能をそれら形状物に統合させている。リソース環境の制約のため、スマートカード用のアプリケーションは、典型的には低レベルプログラミング言語（例えばアセンブリ言語）により記述され、メモリに格納される。ＩＣカードは、ロバスト性、タンパー耐性、格納データの可搬性が確保されなければならない。ＩＣカードは、そのサイズの小型性、ＩＣカードならではのハード的とソフト的なセキュリティの高さによって、パーソナルコンピュータ中のもっともパーソナル用途のものと位置付けられている。ＩＣカードおよびＩＣカードのマイクロコントローラの最重要なタスクは、カードに記録されたデータの保護である。それゆえ、１９７４年のＩＣカードの発明以来、セキュリティを理由にＩＣカード技術は閉鎖的にガードされてきた。ＩＣカードは、最初にフランスの銀行によりデビットカード（即時決済方式カード）として利用された。このアプリケーションでは、ＩＣカードをベースとした金融関係のトランザクションが認証されるためには、ＩＣカード利用者は当該ＩＣカードを所有しているという事実に加え、さらにＩＣカード内に記録されている４桁の個人認証番号（ＰＩＮ）を示さなければならない。紛失または盗難されたＩＣカードのＰＩＮ番号を割り出すために役立ちうるあらゆる情報は、公開されないように秘密に付されている。事実、誰もどんな情報がＰＩＮ番号割り出しに役立つ情報か分からないし、ＩＣカードに関するすべての情報は秘密にされている。セキュリティを考慮して、ＩＣカード用のアプリケーションは独自仕様で記述されている。例えば、各々のアプリケーションは典型的には、特定のカード所有者、特定のＩＤにより識別される。アプリケーションがアセンブリ言語などの低レベルプログラミング言語で記述されているため、アプリケーションは特定種類のマイクロコントローラを対象として記述されている。低レベルプログラミング言語の性質により、権限のないアプリケーションであってもＩＣカード内の格納データにアクセスすることができる。ＩＣカード用に記述されたプログラムは特定のＩＤ識別子により識別されているので、２つの主体が同じプログラミング機能を利用を所望した場合、ＩＣカードのマイクロコントローラ上にアプリケーションの該当部分が２つコピーされてしまうことになる。ＩＣカードシステムは、ずっとクローズドシステムとして発展してきた。ＩＣカードは、特定端末のアプリケーションとともに動作するように手作りされた専用アプリケーションを含んでおり、ＩＣカードが使用されるときのセキュリティチェックは、主にカードアプリケーションと端末アプリケーションが対応するものであるかの確認およびＩＣカード上のデータが有効であるかの確認により行なっていた。ＩＣカードの利用が広まるにつれて、利用者がＩＣカードアプリケーションごとに異なるＩＣカードを持ち歩くことを敬遠することが明らかになってきた。それゆえ、単一プロバイダのＩＣカードを用いた多目的共用アプリケーションが提供され始めている。例えば、現金自動処理装置（ＡＴＭ）用のカード、デビットカードが、１枚のＩＣカードプラットフォームが共用される。しかしながら、端末とカードのすべてのアプリケーションが、他のプロバイダに関する正確な情報のもと、単一のプロバイダによって作成されるため、依然クローズドシステムとなっていた。このように、ＩＣカードに関する情報、ＩＣカードと端末との通信方法およびプログラム方法に関し、公開された情報が少なく、ＩＣカード用の汎用アプリケーションの広がりを阻害していた。しかし、公衆デジタルネットワーク網（例えば、インターネット、ワールドワイドウェブ）の出現により、ＩＣカード用のアプリケーションに対する新たな領域が開かれた。特に、公衆デジタルネットワーク網の広がりにより、他のプロバイダに関する明確な知識なしに、かつＩＣカードのセキュリティ低下の可能性を許すことなく、ＩＣカード上に新しいアプリケーションのロードをすることが必要となった。しかしながら、低レベルプログラミング言語を用いてプログラミングされた従来のＩＣカードを用いた場合は上記課題解決の実現が困難であった。発明の開示一面において、本発明は、端末で利用されるＩＣカードを開示する。本発明のＩＣカードは、インタプリタを格納するメモリと、高級プログラミング言語形式を持っているアプリケーションとを含んでいる。ＩＣカードのプロセッサは、アプリケーションをインタプリタ処理するためのインタプリタを利用するように構成され、また、端末と通信するためのカードの通信部（communicator）を利用するように構成されている。本発明の優位点として、以下のものが含まれている。本発明によれば、スマートカードのセキュリティ低下を招くことなく新しいアプリケーションのダウンロードが可能となる。これらアプリケーションは、様々な会社により提供され、様々な端末装置を利用して様々なタイミングでロードされうる。アプリケーションは、Ｊａｖａ仮想マシンにより提供されるセキュリティ機能により、如何なるアプリケーションコードやデータへの権限なきアクセスに対して保護されているので、カードのセキュリティは構成されない。スマートカードアプリケーションは、強力で主流となっているプログラム開発ツールを用いてＪａｖａやＥｉｆｆｅｌなどの高級プログラミング言語により作成される。新しいアプリケーションは、ソフトマスクを施すことなく数時間により即座にプロトタイプが作成され、スマートカードにダウンロードされる。マイクロコントローラを使用するシステムは、新しいアプリケーションのダウンロード、高レベルなプログラミング開発、迅速なプロトタイプ作成に関して、これらの多くの優位点を得ることができる。本発明の実装には、以下のものが含まれうる。アプリケーションの高級プログラミング言語形式は、クラスファイル形式を持ち、Ｊａｖａプログラミング言語形式を持ちうる。プロセッサはマイクロコントローラで良い。少なくとも一部のメモリがプロセッサに内蔵されうる。アプリケーションは、キャラクタストリングである第２のアプリケーションから生成され、当該キャラクタストリングは第１のアプリケーションにおいて識別子（例えば、整数）により表現されている。プロセッサは、要求元(requester)（例えば、プロセッサまたは端末）からＩＣカード要素（例えば、メモリに格納されているアプリケーション、メモリに格納されたデータ、通信部）の要求を受け付けるように構成されており、要求を受けた後、要求元のＩＤ(identification)を確認するため要求元と交信し、ＩＤに応じてアクセスを許すカード要素を選定する。メモリは、各要素へのアクセス制御リストを格納している。アクセス制御リストは、当該ＩＤに許すアクセス型の指示情報を含み、当該アクセス制御リストに基づいて、プロセッサは、カードアクセスに関する特定の型（例えば、データ読み出し、データ書きこみ、データ付加、データ生成、データ消去、アプリケーション実行）を選択的に許可する。アプリケーションは、メモリに格納された複数のアプリケーションのうちの一つであれば良い。プロセッサはさらに、要求元から複数あるアプリケーションのうちの１つにアクセスする要求を受け付ける構成を持っており、当該要求を受け付けた後、当該複数あるアプリケーションのうちの１つを所定のルールセットに基づいてコンパイルするか否かを決定し、当該決定に基づいて要求元に対して当該複数のアプリケーションのうちの１つへのアクセス許可を選択的に与える。当該所定のルールは、当該１つのアプリケーションが所定のメモリ領域へアクセスできるか否かを決定する情報を提供する。プロセッサはさらに、要求元主体を認証できるように構成され、当該主体に応じて複数アプリケーションのうち１つのアプリケーションに対するアクセスを許可する。プロセッサは、ＩＤを認証するために通信部を介して端末と交信し、ＩＤが認証されたか否かの決定を行ない、当該決定に基づいて端末とＩＣカードとの間の通信を選択的に許可するように構成されていても良い。通信部と端末装置は通信チャンネルを介して交信しうる。プロセッサは、プロセッサが端末装置とＩＣカード間の通信を許可した場合に、通信チャンネルの一つを当該主体に割り当てるように構成されていても良い。プロセッサは、当該割り当てた通信チャンネルに対してセッションキーを割り当て、当該割り当て通信チャンネルを介してプロセッサと端末装置が通信するときに、当該セッションキーを利用するように構成されていても良い。端末装置は、カードリーダを備え、通信部は、カードリーダとの通信コンタクトを含みうる。端末装置は、無線通信デバイスを備え、通信部は、当該無線通信デバイスと通信するための無線受信部を備えうる。端末装置は、無線通信デバイスを備え、通信部は当該無線通信デバイスと通信するための無線送信部を備えうる。一面において、本発明は、ＩＣカードおよび端末において使用される方法を開示する。当該方法には、インタプリタと少なくとも１つの高級プログラミング言語形式で記述されたアプリケーションとをＩＣカードのメモリに格納する方法が含まれている。ＩＣカードのプロセッサは、少なくとも１つのアプリケーションを実行するためにインタプリタを使用し、プロセッサと端末装置間の通信を行なうときにはＩＣカードの通信部を使用する。一面において、本発明は、スマートカードを開示する。スマートカードは、Ｊａｖａインタプリタを格納するメモリと、Ｊａｖａアプリケーションをインタプリタ実行するため当該インタプリタを利用できるように構成されているプロセッサを含んでいる。一面において、本発明は、半導体基板と当該基板上に形成されたメモリを備えたマイクロコントローラを開示する。プログラミング言語インタプリタは、当該メモリ上に格納され、セキュリティチェックを実行するように構成される。中央演算処理装置は、当該基板上に形成され、メモリと結合されている。本発明の実装においては、以下のものが含まれうる。インタプリタは、Ｊａｖａバイトコードインタプリタであっても良い。セキュリティチェック処理は、ファイアウォールを確立すること、また、サンドボックスセキュリティモデルを実現することを含みうる。一面において、本発明は、ＩＣカード上のメモリに格納されたプログラミング言語インタプリタを備えたスマートカードを開示する。インタプリタは、セキュリティチェック処理が実行できるように構成されている。ＩＣカード上の中央演算処理装置は、メモリと結合されている。一面において、本発明は、端末装置と共に使用されるＩＣカードを開示する。ＩＣカードは、通信部と、インタプリタと第１のアプリケーション用の第１の命令セットを格納するメモリとを含んでいる。第１の命令セットは、第２のアプリケーションの第２の命令セットから変換されたものである。ＩＣカードは、プロセッサを含んでおり、当該プロセッサは、メモリに結合され、また、第１の命令セットを実行するためのインタプリタを使用でき、通信部を介して端末と通信できるように構成されている。本発明の実装においては、以下のものが含まれうる。第１、第２アプリケーションの双方、またはそのうち１つは、クラスファイル形式を持っている。第１、第２アプリケーションの双方、またはそのうち１つは、Ｊａｖａバイトコードなどのバイトコードを含んでいる。第１の命令セットは、第２の命令セットの汎用化バージョンまたは番号を付け換えたバージョンでありうる。第２の命令セットは、定数参照値(constant references)を含み、第１の命令セットは、第２の命令セットの定数参照値に代入される定数を含んでいる。第２の命令セットは、参照値を含みうるもので、当該参照値は、第２の命令セットから第１の命令セットへ変換される間にその格納場所(location)が移動しうるものである。第１の命令セットでは参照値の格納場所が移動した後、当該参照値が再び結び付けられる。第１の命令セットは、仮想マシンの第１の型のバイトコードを含みうるもので、第２の命令セットは仮想マシンの第２の型のバイトコードを含みうる。ここで、上記の第１の型は第２の型とは異なるものである。一面において、本発明は、ＩＣカード上で使用される方法について開示する。本発明の方法は、第２のアプリケーションの第２の命令セットを第１のアプリケーションの第１の命令セットに変換し、ＩＣカードのメモリに第１の命令セットを格納し、第１の命令セットを実行するためＩＣカード上のインタプリタを利用するものである。一面において、本発明は、端末装置と共に使用するＩＣカードを開示する。ＩＣカードは、端末装置と通信するように構成された通信部と、キャラクタストリングを持つ第２のアプリケーションから生成された第１のアプリケーションを格納するメモリを備えている。キャラクタストリングは、第１のアプリケーションにおいて識別子によって表わされている。ＩＣカードは、メモリに結合されたプロセッサを含んでいる。一面において、本発明は、ＩＣカードと端末装置において用いる方法を開示する。本発明の方法は、第２のアプリケーションを処理して第１のアプリケーションを生成する方法を含んでいる。第２のアプリケーションはキャラクタストリングを持っている。キャラクタストリングは、第２のアプリケーションの識別子により表わされている。インタプリタと第１のアプリケーションは、ＩＣカードのメモリに格納されている。プロセッサは、第１のアプリケーションのインタプリタ実行のためインタプリタを使用する。一面において、本発明は、アプリケーションとインタプリタを格納するメモリを含むマイクロコントローラを開示している。ここで、アプリケーションは、クラスファイル形式を持っている。マイクロコントローラのプロセッサは、メモリに結合され、アプリケーションのインタプリタ実行のためインタプリタを使用できるように構成されている。本発明の実装においては、マイクロコントローラは端末装置と通信できるように構成された通信部を含みうる。一面において、本発明は、ＩＣカードにおいて利用される方法を開示している。本発明の方法は、ＩＣカードのメモリに第１のアプリケーションを格納し、ＩＣカードのメモリに第２のアプリケーションを格納し、第２のアプリケーションが第１のアプリケーションもしくは第１のアプリケーションに関連するデータのいずれにもアクセスできないように、第１及び第２のアプリケーションを相互に隔離するためのファイアウォールを生成する方法である。一面において、本発明は、端末装置において利用するＩＣカードを開示している。ＩＣカードは、端末装置、メモリおよびプロセッサと通信するために構成された通信部を含んでいる。当該メモリはアプリケーションを格納し、それぞれのアプリケーションは、高級プログラミング言語形式を持っている。当該メモリは、インタプリタを格納している。当該プロセッサは、メモリと結合されており、ａ）アプリケーションをインタプリタ実行するためインタプリタを使用でき、ｂ）アプリケーションを相互に隔離するためのファイアウォールを生成するためインタプリタを使用でき、ｃ）端末装置と通信するための通信部が使用できるように構成されている。他の優位点および特徴は、以下の説明と特許請求の範囲の記載により明らかにされている。図面の簡単な説明図１は、ＩＣカードシステムのブロック図である。図２は、ＪａｖａアプリケーションをＩＣカードにダウンロードする準備の手順を示すフロー図である。図３は、カードクラスファイルコンバータから生成され、使用されるファイルのブロック図である。図４は、アプリケーションクラスファイルをカードクラスファイルへ変換する手順を示すブロック図である。図５は、クラスファイルコンバータの動作を示すフロー図である。図６は、バイトコードの変更手順を示すフロー図である。図７は、スペシフィックバイトコードをジェネリックバイトコードへの変換を示すブロック図である。図８は、定数参照値の定数への置き換えを示すブロック図である。図９は、参照値の更新値への置き換えを示すブロック図である。図１０は、元のバイトコードのリナンバリング手順を示すブロック図である。図１１は、元のバイトコードを異なる仮想マシンのアーキテクチャ用へ変換する様子を示すブロック図である。図１２は、アプリケーションをＩＣカードにロードする様子を示すブロック図である。図１３は、ＩＣカード上のアプリケーションを実行する様子を示すブロック図である。図１４は、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭのメモリ構造を示す図である。図１５は、カードＪａｖａ仮想マシンのアーキテクチャ全体像を示すフロー図である。図１６は、セキュリティチェックを伴うカードＪａｖａ仮想マシンの実行方法を示すフロー図である。図１７は、カードＪａｖａ仮想マシン上でバイトコードを実行する様子を示すフロー図である。図１８は、セキュリティチェックを伴わないカードＪａｖａ仮想マシンの実行方法を示すフロー図である。図１９は、カードアプリケーションと識別子との対応付けを示すブロック図である。図２０は、特定の実行アプリケーションへのアクセス権限を示すブロック図である。図２１は、スマートカードに用いられたマイクロコントローラの斜視図である。図２２は、電話機に用いられたマイクロコントローラの斜視図である。図２３は、かぎ型リングに用いられたマイクロコントローラの斜視図である。図２４は、指輪に用いられたマイクロコントローラの斜視図である。図２５は、車に用いられたマイクロコントローラの斜視図である。好ましい実施の形態図１を参照しつつ、好ましい実施形態を詳しく説明する。ＩＣカード１０（スマートカードなど）は、Ｊａｖａベースのマルチアプリケーション高級プログラミング言語および実行環境を提供するように構成されている。ＩＣカード１０は、端末装置１４の通信部１２ｂと通信できるように構成されている通信部１２ａを有している。いくつかの実施形態において、ＩＣカード１０は、８ビットマイクロコントローラ、５１２バイトのＲＡＭ、４ＫバイトのＥＥＰＲＯＭ、２０ＫバイトのＲＯＭを持つスマートカードであり、端末装置の通信部１２ｂは、従来タイプのスマートカードリーダであり、端末装置１４は、パーソナルコンピュータスマートカード（ＰＣ／ＳＣ）標準仕様をサポートし、またＪａｖａ開発サポート環境を提供できるウィンドウＮＴオペレーティングシステムが動作する従来タイプのパーソナルコンピュータである。いくつかの実施形態において、マイクロコントローラとメモリと通信部は、典型的なクレジットカードと実質的に同じ形状を持つプラスティックカードに埋め込まれている。他の実施形態において、マイクロコントローラとメモリと通信部は、貴重品類(例えば、時計、指輪、ブレスレット)、車類、通信機器類(例えば、加入者携帯モジュール(ＳＩＭ)カード)、セキュリティデバイス類(例えば、暗号モジュール)、器具類など、プラスティックカード以外の基板上に搭載されることもある。端末装置１４は、端末装置の通信部１２ｂを用いて、ＪａｖａアプリケーションをＩＣカード１０に対して取り揃えて、ダウンロードする。端末装置の通信部１２ｂは、ＩＣカード１０と端末装置１４の間に通信チャンネルを確立することができる通信デバイスである。通信機器オプションとして、接触型カードリーダ、無線周波数帯を用いた無線通信、または赤外線通信技術、シリアル通信プロトコル、パケット通信プロトコル、ＩＳＯ７８１６通信プロトコルを用いた機器が含まれる。端末装置１４は、また、ＩＣカード１０上で動作するアプリケーションと連携動作することができる。いくつかのケースにおいて、目的に応じて異なる端末装置が用いられうる。例えば、ある種の端末装置が、アプリケーションを取り揃えるために利用され、他の端末装置が、アプリケーションをダウンロードするために利用され、また他の端末装置が多様なアプリケーションを実行するために利用される。端末装置は、現金自動処理装置(ＡＴＭｓ)、販売時点管理端末(ＰＯＳ端末)、入退出管理システム、有料道路料金徴収システム、アクセス管理システム、ＩＣカードやマイクロコントローラと通信可能な他のシステムでありうる。ＩＣカード１０は、ＩＣカード１０上にあるアプリケーションをインタプリタ実行するように、カードＪａｖａ仮想マシン（カードＪＶＭ）１６を備えている。図２の例では、Ｊａｖａアプリケーション２０は、３つのＪａｖａソースコードファイルＡ(Ｊａｖａ２０ａ)、ファイルＢ(Ｊａｖａ２０ｂ)、ファイルＣ（Ｊａｖａ２０ｃ）を含んでいる。これらのソースコードファイルは取り揃えられ、Ｊａｖａアプリケーション開発環境２２の中でコンパイルされる。Ｊａｖａアプリケーション２０が開発環境２２によりコンパイルされたとき、アプリケーションクラスファイル２４が生成され、また、Ｊａｖａソースコード２０ａ、２０ｂ、２０ｃのそれぞれに対応するクラスファイルＡ(クラス２４ａ)、ファイルＢ( クラス２４ｂ)、ファイルＣ（クラス２４ｃ）が生成される。アプリケーションクラスファイル２４は、ティム・リンドホルムとフランク・イェリン著書の「Ｊａｖａ仮想マシン仕様」アディソン-ウェズレー1996年版の第４章に記載されているスタンダードクラスファイル形式に従って記述されている。これらアプリケーションクラスファイル２４は、ファイルを集約し、圧縮して単一のカードクラスファイル２７を生成するカードクラスファイルコンバータ２６に渡される。カードクラスファイル２７は、通常のカードローダ２８によりＩＣカード１０にロードされる。図３の例では、カードクラスファイルコンバータ２６は、クラスファイルのポストプロセッサであり、標準Ｊａｖａクラスファイル形式にコード化されたクラスファイル２４を処理し、オプションとしてＩＤインプットマップファイルのストリング３０を利用し、Ｊａｖａカードクラスファイル２７をカードクラスファイル形式で生成する。上記のカードクラスファイル形式の１つを、後述する付属ドキュメント(Appendix)Ａにおいて示している。さらに、いくつかの実施形態において、カードクラスファイルコンバータ２６は、カードクラスファイルコンバータを引き続き使用するための入力として利用されるＩＤアウトプットマップファイルのストリング３２を生成する。いくつかの実施形態において、ＩＤマッピングのストリングが、以前に生成されたカードクラスファイル（マルチプルクラスファイルが同一のストリングを参照している場合）と一致するように、カードクラスファイルコンバータ２６は、以前に定義されたインプットマップファイルのストリング３０からＩＤマッピングのストリングを受け入れる。このようなファイルがない場合、ＩＤはカードクラスファイルコンバータ２６から生成される。付属ドキュメントＢは、ＩＤインプットマップファイルのストリング３０とアウトプットマップファイルのストリング３２を生成する実現可能な方法の１つを示し、例を通じてマッピングの様子を示している。図４の例では、典型的なアプリケーションクラスファイル２４ａは、クラスファイル情報４１、クラスコンスタントプール(class constant pool 42)４２、クラスとフィールド生成とインタフェースとメソッドに関する情報４３、様々な属性情報４４を含み、前記したＪａｖａ仮想マシン仕様として詳述されている。ここで、属性情報４４の多くは、この実施形態には必要ではなく、カードクラスファイルコンバータ２６による除去部分４５となっている。除去される属性は、ソースファイル、定数値、例外処理、ライン番号テーブル、ローカル変数テーブル、その他のオプションのベンダ属性を含んでいる。付属ドキュメントＡとして記述されている典型的なカードクラスファイル２７は、以下のアプリケーションクラスファイル２４から生成される。カードクラスファイル情報４６は、全てのアプリケーションクラスファイル２４ａ、２４ｂ、２４ｃのクラスファイル情報４１の集合から生成される。カードクラスファイルコンスタントプール４７(card class file constant pool 47)は、全てのアプリケーションクラスファイル２４ａ、２４ｂ、２４ｃのクラスコンスタントプール４２の集合から生成される。カードクラスとフィールド生成と参照インタフェースとメソッドに関する情報４８は、全てのアプリケーションクラスファイル２４ａ、２４ｂ、２４ｃのクラスとフィールド生成と参照インタフェースとメソッドに関する情報４３の集合から生成される。この実施形態のカード属性情報４９は、全てのアプリケーションクラスファイル２４ａ、２４ｂ、２４ｃの属性情報４４の集合のコード属性のみから生成される。カード内でのダイナミックリンキングを避けるため、アプリケーション２４からＪａｖａクラスファイル２４ａ、２４ｂ、２４ｃをまたがって配布されるすべての情報は、図５に示すフローチャートに示されたプロセスにより、１つのカードクラスファイル２７内に隠蔽されている。まず、処理される第１のクラスファイルとして選択される(５１ａ)。コンスタントプール４２は、以下の方法によりコンパクト化される(５１ｂ)。Ｊａｖａクラスファイル２４ａにおいて参照されるすべてのオブジェクト、クラス、フィールド、メソッドは、クラスファイル２４ａのコンスタントプール４２にあるストリングを利用することにより、特定される。カードクラスファイルコンバータ２６は、Ｊａｖａクラスファイル２４ａにあるコンスタントプール４２をコンパクト処理し、最適化したものとする。コンパクト処理は、クラスファイルコンスタントプール４２にある全てのストリングを整数にマッピング処理することにより達成される(当該整数の大きさはマイクロコントローラと採用アーキテクチャに依存する)。この整数が、ＩＤ識別子として参照される。各ＩＤ識別子は、アプリケーション２０の特定オブジェクト、クラス、フィールド、メソッドをユニークに特定する。このように、カードクラスファイルコンバータ２６は、Ｊａｖａクラスファイルコンスタントプール４２のストリングを、対応するユニークなＩＤ識別子に置き換える。付属ドキュメントＢは、ハロースマートカードＪａｖａ(HollowSmartCard.java)というアプリケーション例を、以下の本アプリケーションのクラスファイルのコンスタントプールに見られるストリングに対応するＩＤ識別子を説明するテーブルと共に示している。ＩＤ識別子は、本実施形態では１６ビットの符号無し整数として使用されている。次に、カードクラスファイルコンバータ２６は、入力されたＪａｖａクラスファイル２４ａのコード属性に、未サポートの部分５１Ｃがあるか否かをチェックする。カードＪＶＭ１６は、付属ドキュメントＣに示すように、Ｊａｖａバイトコード全体のうちのサブセットのみサポートしている。このため、カードクラスファイルコンバータ２６は、未サポートのバイトコードがＪａｖａクラスファイル２４ａのコード属性の中にあるか否かをチェックする。もし、未サポートのバイトコードが見つかった場合５２は、カードクラスファイルコンバータはエラーフラグを立て、変換５３を停止する。付属ドキュメントＤにおいて“Ａ”とマークされたプログラムコードフラグメントは、これら未サポートのバイトコードが如何に検出されるかを示している。他のレベルのチェックは、標準Ｊａｖａ開発環境２２の要求に応じて、アプリケーション２０は“-ｇ”フラグとともにコンパイルして実行される。上記したＪａｖａ仮想マシン仕様に基づいて、このオプション処理は、クラスファイル２４ａのローカル変数テーブル属性中にあってＪａｖａアプリケーション２０において使用される変数に関する情報を定めるためにＪａｖａコンパイラを必要とする。カードクラスファイルコンバータ２６は、Ｊａｖａクラスファイル２４ａがＪａｖａカードによりサポートされていないデータ型を参照しているか否かをチェックするために、この情報を使用する。次に、カードクラスファイルコンバータ２６は、Ｊａｖａクラスファイル２４ａのうちインタプリタ実行に必要とされないすべての不必要な部分を破棄する。Ｊａｖａクラスファイル２４ａは、Ｊａｖａクラスファイルの属性セクション４４のクラスファイル中のバイトコードに含まれている情報を格納する。ソースファイル、定数値、例外処理、ライン番号テーブル、ローカル変数テーブルなどのカードＪＶＭによるインタプリタ実行に必要とされない属性情報は、安全な方法により破棄される４５。結局、保持される属性は、コード属性のみとなる。コード属性は、Ｊａｖａクラスファイル２４ａのメソッドに対応するバイトコードを含んでいる。バイトコード５４の変更処理は、クラスファイルのそれぞれのメソッドのコード属性情報４４の検査処理および、カードクラスファイルのコンスタントプール (card class file constant pool)４７のエントリを反映するＪａｖａクラスファイルコンスタントプール４２のエントリを参照するバイトコードのオペランドの変更処理を含んでいる。いくつかの実施形態において、バイトコードも以下に説明されるように変更される。バイトコード５４の変更処理は、図６のフローチャートにより説明されるように、５つのパス（２つのオプションパスもある）を含んでいる。オリジナルバイトコード６０は、処理中のＪａｖａクラスファイル２４ａのコード属性４４中に見られる。第１のパス６１は、オリジナルバイトコードのすべてのジャンプとそのジャンプ先を記録する。後続のバイトコードの変換において、いくつかのシングルバイトコードは、デュアルバイトもしくはトリプルバイトに変換される。図７は、バイトコードＩＬＯＡＤ０が２つのバイト、バイトコードＩＬＯＡＤと引数０に置きかえられる例を示している。この置き換え処理が実行された場合には、コードサイズが変更されることとなり、影響を受けるすべてのジャンプ先の調整が要求される。それゆえ、これらの変換が実行される前に、オリジナルバイトコード６０は解析され、あらゆるジャンプバイトコードと、ボジションと行き先のノート(note)が調べられる。付属ドキュメントＤの中で“Ｂ”でマークされているプログラムコードの部分(fragment)は、如何にこれらジャンプが記録されるかを示している。ひとたびジャンプが記録されると、オプションのバイトコードの変換処理が実行されない場合６２でも、カードクラスファイルコンバータ２６は、第３のパス６４に進む。バイトコードの変換処理が実行される場合は、カードクラスファイルコンバータは、スペシフィックバイトコード(specific byte codes)をジェネリックバイトコード(generic byte codes)に変換する。典型的には、変換されたバイトコードは、カードＪＶＭ１６ではインタプリタ実行されないが、変換されたバイトコードは、当該バイトコードがカードＪＶＭ１６でインタプリタ実行できる等価なバイトコードに変換されることによりサポートされる。バイトコード７０は、セマンティック的に等価であるが異なるバイトコード７２に置きかえられる。この処理は、一般的に、ＩＬＯＡＤ０などの短い単一のスペシフィックバイトコードをより一般的なバイトコードへの変換処理を伴う。例えば、ＩＬＯＡＤ０は、バイトコードＩＬＯＡＤと引数０に置きかえられうる。この変換は、カードＪＶＭ１６により変換されるバイトコード数を減らすために実行され、結果として、複雑さ及びカードＪＶＭ１６に要求されるコード領域を減らしている。付属ドキュメントＤの中に“Ｃ”でマークされたプログラムコード部分(fragment)は、如何にこれらの変換が実行されるかを示している。このような変換処理は、生成されるバイトコードのサイズを増やし、影響されるあらゆるジャンプの再演算を実行することとなることに注意する必要がある。第３のパス６４において、カードクラスファイルコンバータは、これら定数を定義するために使われるストリングの削除を通じて定数参照を再構築する。図８では、Ｊａｖａクラスファイル２４ａのコンスタントプール４２のインデックスに見られる定数１８を参照するバイトコードＬＤＣ８０は、ＢＩＰＵＳＨバイトコード８２に変換されている。このパスにおいて、カードクラスファイルコンバータ２６は、カードクラスファイルコンスタントプール４７内の新しいロケーションを示すＪａｖａクラスファイルコンスタントプール４２のエントリを参照するすべてのバイトコードのオペランドを変更する。図９は、バイトコードの引数の例を示している。インボークスタティック(INVOKESTATIC)９０は、Ｊａｖａクラスファイルコンスタントプール４２のエントリを参照しているが、当該エントリはカードクラスファイルコンスタントプール４７内の新しいロケーションを反映するように変更されている。変更されたオペランド９４は、この変換処理を示している。付属ドキュメントＤの中に“Ｄ”でマークされたプログラムコード部分は、如何にこれら変換が実行されるかを示している。ひとたび、定数参照がリンク付けされると、オプションのバイトコード変更処理が実行されない場合は、カードクラスファイルコンバータは、最後の第５のパス６７に進む。オプションバイトコード変更処理がされた場合は、カードクラスファイルコンバータは、オリジナルバイトコードを、利用されている特定のカードＪＶＭ１６でサポートできる異なるバイトコードセットに変換する。１つの想定される変更処理は、オリジナルバイトコード６０をカードＪＶＭ１６のバイトコードにリナンバリングする処理である(図１０参考)。このリナンバリング処理は、オリジナルバイトコード６０のバイトコード１００をリナンバリングバイトコード１０２へ変換する処理である。値２１により識別されるバイトコードＩＬＯＡＤは、値５０によって識別されるようにリナンバリングされる。この変更処理は、カードＪＶＭ１６の中での型テスト（第３パスのチェックとしても知られている）を最適化するように実行される。付属ドキュメントＤの中で“Ｅ”マークで示されるプログラムコードの部分は、この実施形態の実装を示している。この変更処理は、カードＪＶＭ１６がバイトコードをインタプリタ実行するために必要となるプログラム領域を減らすために実行される。本質的に、この変更処理は、似通ったオペランドを持つバイトコードが同じグループになるようにバイトコードをカードＪＶＭ１６バイトコードにグループ分けし、カードＪＶＭ１６バイトコード間にギャップが生じないようにする。この処理により、カードＪＶＭ１６が、効率的にカードＪＶＭ１６バイトコードと有効な型のチェックが実行できる。いくつかの実施形態において、図１１に示すように、カードクラスファイルコンバータは、オリジナルバイトコード６０を異なる仮想マシンアーキテクチャ用に用意された異なるバイトコードセットに変換する。ワードスタック１１４で利用できるように生成されたＪａｖａバイトコードＩＬＯＡＤ１１２は、バイトスタック１１８で利用できるようにカードＪＶＭ１６のバイトコードＩＬＯＡＤＢ１１６に置きかえられる。ワードスタック１１４のエレメントは、４バイトのスタック領域の割り当てを必要とし、バイトスタック１１８のエレメントは１バイトのスタック領域を必要とする。しかし、このオプションは、実行処理速度を増すことができるが、オリジナルバイトコードの状態で得ることができたセキュリティ特性を失うというリスクを負う。先行するステップ６３、ステップ６４またはステップ６６では、バイトコード６０のサイズが変更されうるので、カードクラスファイルコンバータ２６は影響されるあらゆるジャンプを再リンク６７しておかなければならない。そこで、ジャンプ処理は、カードクラスファイルコンバータ２６の第１ステップ６１において記録され、ジャンプ先を適当な値に固定することで調整を実行する。付属ドキュメントＤの中で“Ｆ”でマークされたプログラムコードの部分は、如何にこれらジャンプの固定が実行されるかを示している。この段階で、カードクラスファイルコンバータは、オリジナルバイトコード６０と等価であるバイトコード６８を生成し、ロードできる状態に用意できた。これにより、Ｊａｖａクラスファイル２４ａをカードクラスファイル２７への変換が完了する。図５に戻り、処理するべきクラスファイル２４が残っている場合５５には、当該残っているそれぞれのクラスファイルに対してステップ５１ａ、５１ｂ、５１ｃ、５２、５４を繰り返して実行処理する。カードクラスファイルコンバータ２６は、処理されて生成されたクラスファイル２４のマップと変更したバイトコードを収集５６し、カードクラスファイル２７を生成する５７。もし必要であれば、カードクラスファイルコンバータ２６は、ＩＤアウトプットマップファイル３２のストリングを生成する。これには、変換処理中にＪａｖａクラスファイル２４のコンスタントプール４２に対応するストリングとして割り当てられるすべての新しいＩＤ識別子のリストを含んでいる。図１２を参照して説明する。端末装置１４にあるカードローダ２８は、ＩＳＯ７８１６規格のコマンドを利用して、カードクラスファイルをＩＣカード１０のローディング・実行制御部１２０に送る。ローディング・実行制御部１２０は、カードオペレーティングシステム１２２と共に、複数のカードアプリケーション１２６を格納するために使われる。このカードオペレーティングシステム１２２は、カードファイルシステム１２４のサポートを含み必須のシステムリソースを提供するものである。通常のカードローダの多くは、低レベル言語で記述され、カードオペレーティングシステム１２２によってサポートされている。好ましい実施形態において、ブートストラップローダは、Ｊａｖａ言語で記述され、ＩＣカード１０は、当該アプリケーションを実行できるようにＪａｖａ仮想マシンが含まれている。ローディング・実行制御部１２０のＪａｖａ実装は、付属ドキュメントＥに示されている。ローディング・実行制御部１２０は、カードクラスファイル２６を受け取って、ＩＣカード１０のＥＥＰＲＯＭのカードファイルシステムに格納されるＪａｖａカードアプリケーション１２６Ｘを生成する。このように、複数のＪａｖａカードアプリケーション１２６Ｘ、１２６Ｙ、１２６Ｚは１枚のカードに格納することができる。ローディング・実行制御部１２０は、端末装置１４がＪａｖａカードアプリケーションを選択して速やかに実行でき、カードリセットができるコマンドをサポートしている。図１３に示すように、ローディング・実行制御部１２０からリセットコマンドを受け取るか、実行コマンドを受け取ると、カードＪａｖａ仮想マシン（カードＪＶＭ）１６は、選択されたＪａｖａカードアプリケーション１２６Ｚの選択されたクラスの所定のメソッド（例えば、メインメソッド）で実行する。カードＪＶＭ１６は、Ｊａｖａカードアプリケーション１２６Ｚが、カードオペレーティングシステム１２２にアクセスできるようにし、付属ドキュメントＦに示すように、Ｉ／Ｏ、ＥＥＰＲＯＭサポート、ファイルシステム、アクセス制御、他のネイティブＪａｖａメソッドを利用するシステム機能の利用を可能とする。選択したＪａｖａカードアプリケーション１２６Ｚは、端末装置１４との通信チャンネルを確立するための通信部１２ａを利用して端末装置１４にある適切なアプリケーションと通信する。通信部１２ａから端末装置１４へ入力されるデータは、端末装置の通信ドライバ１３２を介して端末装置１４へ渡される。当該通信ドライバ１３２は、通信部１２ａが利用する通信プロトコルが扱えるように記述されている。当該データは、利用されているＩＣカード１０の機能の規定が記述されたＩＣカードドライバ１３４に渡され、端末装置アプリケーション１３６に対して高レベルなソフトウェアサービスを提供する。好ましい実施形態では、このドライバは、ＰＣ／ＳＣスマートカードサービスプロバイダ（ＳＳＰ）ソフトウェアである。データは、その後、端末装置アプリケーション１３６に渡される。端末装置アプリケーション１３６は、特定のカードアプリケーション１２６Ｚの実行処理ができるように提供されている機能を扱えるものとなっている。このように、コマンドとレスポンスが、端末装置アプリケーション１３６と選択したカードアプリケーション１２６Ｚの間を行き来する。端末装置アプリケーションは、ユーザとのやり取りにより、ユーザから入力されるコマンドを受け取り、そのうちいくつかは、Ｊａｖａカードアプリケーション１２６Ｚに渡され、ユーザに返されるＪａｖａカードアプリケーション１２６Ｚからのレスポンスを受け取る。図１４に示すように、カードＪＶＭ１６は、カードアプリケーション１２６Ｘをインタプリタ実行するインタプリタである。カードＪＶＭに影響を与えるマイクロコントローラのメモリリソースは、カードＲＯＭ１４０、カードＲＡＭ１４１、カードＥＥＰＲＯＭにある。カードＲＯＭ１４０は、カードＪＶＭ１６とカードオペレーティングシステム１２２を格納するために利用される。カードＲＯＭ１４０は、ＲＯＭに固定記憶するカードアプリケーション１４０ａとクラスライブラリ１４０ｂを格納するために利用される。ロード可能なアプリケーション１４１ａ、１４１ｂ、ライブラリ１４１ｃは、カードＲＡＭ１４１に格納されうる。カードＪＶＭ１６は、カードアプリケーション１４１ａ、１４１ｂ、１４０ａをインタプリタ実行する。カードＪＶＭ１６は、カードＲＡＭを使って、ＶＭスタック１４４ａとシステム状態変数１４４ｂを記憶する。カードＪＶＭ１６は、ＶＭスタック１４４ａにより実行される処理過程を記憶する。カードＪＶＭ１６により生成されたオブジェクトは、ＲＡＭヒープ１４４ｃ、ＥＥＰＲＯＭヒープ１４６ａ、ファイルシステム１４７のいずれかに格納される。カードＪＶＭ１６により扱われるすべてのヒープは、ＲＡＭヒープ１４４ｃとしてカードＲＡＭ１４１に格納されるか、ＥＥＰＲＯＭヒープ１４６ａとしてカードＥＥＰＲＯＭ１４２に渡され格納される。カードＲＡＭ１４１は、システムスタック１４８の状態を記録するために使われる。システムスタック１４８はマイクロコントローラのネイティブコードで記述されたルーチンによって利用される。カードＪＶＭ１６は、カードＥＥＰＲＯＭ１４２を利用してアプリケーションデータを、ＥＥＰＲＯＭヒープ１４６ａまたはファイルシステム１４７のいずれかに格納される。ファイルに格納されたアプリケーションデータは、カードオペレーティングシステム１２２のインタフェースを介して扱うことができる。このインタフェースは、カードＲＯＭ１４０に格納されるクラスライブラリ１４０ｂ、またカードＥＥＰＲＯＭ１４２に格納されるロード可能なクラスライブラリ１４１ｃにより提供される。インタフェースの一例を、付属ドキュメントＦに示す。カード内のアプリケーションとデータはファイアウォール機構１４９により互いに隔離される。マイクロコントローラの限られた利用可能なリソースによって動作させるために、カードＪＶＭ１６は、Ｊａｖａプログラミング言語の絞り込んだサブセットを実装している。したがって、Ｊａｖａアプリケーション２０は、Ｊａｖａバイトコードの絞り込んだサブセットを含んだクラスファイルとしてコンパイルされることとなる。このサブセットにより、アプリケーションプログラマーは、絞り込んだＪａｖａのサブセットによりプログラムを作成することができ、現行のＪａｖａ仮想マシンと互換性を維持することができる。カードＪＶＭ１６によりインタプリタ実行されるＪａｖａバイトコードのセマンティックは、上述したＪａｖａ仮想マシン仕様により記述される。カードＪＶＭ１６によりインタプリタ実行されるバイトコードのサブセットを付属ドキュメントＣに示されている。カードクラスファイルコンバータ２６は、Ｊａｖａアプリケーション２０をチェックし、当該サブセットにおいて利用可能な特性(features)のみを使用するものであるか確かめ、カードＪＶＭ１６により理解され、インタプリタ実行できる形式に変換する。いくつかの実施形態において、カードＪＶＭ１６は、異なるサブセットまたはバイトコード１１６の引数セットをインタプリタ実行できるようにデザインされている。Ｊａｖａの絞り込んだサブセットは、オリジナルＪａｖａバイトコードにより提供されるセキュリティの観点、または、主流のＪａｖａ開発ツールとの互換性の観点からは好ましくないが、異なるバイトコードセットを使用することは、いくつかの処理性能の改善をもたらしうる。すべてのカードＪＶＭ１６のアプリケーション１２６は、クラスとクラスのメソッドにより定義されるエントリポイントを持っている。エントリポイントは、ＩＤインプットマップ３０のストリングとしてマッピングされ、カードクラスファイルコンバータ２６により割り当てられる。Ｊａｖａアプリケーション２０内のクラス、メソッド、フィールドは、カードクラスファイルコンバータ２６によりＩＤ識別子が割り当てられる。例えば、メインアプリケーションクラスに対応するＩＤ識別子は、Ｆ００１として定義され、“main( )V”などのメインメソッドに対応するＩＤ識別子は、Ｆ００２として定義される。カードＪＶＭの実行アーキテクチャ全体は図１５のフローチャートに記述されている。カードＪＶＭにおける実行は、実行制御１２０において開始され、実行するカードアプリケーション１２６Ｚを選択する。カードＪＶＭ１６のカードアプリケーションでインタプリタ処理されるエントリポイント（メソッド）を見つけ出し、割り当てる(１５２)。カードＪＶＭ１６は、メソッドをインタプリタ処理する(１５３)。インタプリタ処理がうまく成功すると(１５４)、カードＪＶＭ１６は成功を報告し(１５５)、実行制御１２０に制御を返す。インタプリタ処理１５３において、カードＪＶＭ１６が処理できないエラーや例外処理（典型的には、リソース制限、セキュリティ違反）が発生すると、カードＪＶＭは停止し１５６、端末装置１４に適切なエラー報告を行なう。カードＪＶＭ１６の本質的部分は、バイトコードの実行を処理するサブルーチンである。このサブルーチンは、図１６により示されている。与えられたメソッド１６０は、バイトコードを当該メソッド中で実行する。サブルーチンは、メソッドのパラメタが準備されると開始される(１６１)。この処理は、ＶＭスタック１４４ａポインタおよびＶＭスタック１４４ａフレームリミットの設定処理、メソッドの第１のバイトコードのプログラムカウンタの設定処理を含む。次に、メソッドフラグがチェックされる(１６２)。もし、メソッドのフラグがネイティブであると、メソッドは実際にネイティブメソッドコード（マイクロコントローラのネイティブプロセッサコードで記述されたサブルーチン）をコールする。この場合、カードＪＶＭ１６は、実行効率の高いコールを用意し(１６３) 、ネイティブコードサブルーチンに戻る。ネイティブメソッドのパラメタは、直接またはシステムスタック１４８を介してＶＭスタック１４４ａに渡される。適切なセキュリティチェックが実行され、ネイティブメソッドサブルーチンがコールされる。ネイティブメソッドサブルーチン処理の結果（もし結果があれば）は、次の実行処理されるバイトコードがアクセスできるようにＶＭスタック１４４ａに入れられる。次に、カードＪＶＭ１６のディスパッチループに入る(１６４)。バイトコードディスパッチループは、それぞれのバイトコードの実行準備、実行、終了処理を行なう。メソッド１６０におけるバイトコードのインタプリタ処理が終了したとき、またはカードＪＶＭ１６においてリソース制限、セキュリティ違反が発生した場合、ループ処理が終了する。先行処理されるバイトコードが、分岐処理１６５を必要としている場合、カードＪＶＭ１６は分岐処理の準備をする(１６５ａ)。次のバイトコードが検索される(１６５ｂ)。それぞれのバイトコードを処理する処理コストを低く抑えるため、バイトコード引数、長さ、型などの多くの共通する要素が抽出され、格納される。プログラミング言語のセキュリティモデルによって提唱されているセキュリティを構築するため、クラスファイルのバイトコードは、当該モデルの構成内容を確認して決定されなければならない。これらのチェックは典型的に、公知であるバイトコードベリファイアに関するプログラムにより実行される。これらバイトコードベリファイアはＪａｖａ仮想マシン仕様に記述される４つのパスを実行処理する。バイトコードベリファイアにより保証されるランタイムセキュリティを提供するため、カードＪＶＭ１６はベリファイアの第３パスおよび第４パスに含まれるチェック処理を実行する。カードＪＶＭ１６によりインタプリタ処理されたバイトコード６０のセキュリティが保証されれば(ほとんど不可能であるが)、このチェック処理は、カードＪＶＭ１６によって省略できる。最小限の処理として、オブジェクトリファレンスが偽物ではなく、ＶＭスタック１４４ａとローカル変数境界が監視できる限り、コードセキュリティが維持される。この処理には、実行処理されたバイトコードに関するＶＭスタック１４４ａの状態のチェック処理が要求される。プログラミング言語のセキュリティモデルを強化するため、付属ドキュメントＧに示す２５６バイトテーブルが生成される。このテーブルは、バイトコード番号によりインデックス化されている。このテーブルは、バイトコードインデックスに関する型情報とレングス情報を含んでいる。コード化された最初の５ビットは、型を表わし、最後の３ビットはレングスを表わしている。バイトコードの型情報とレングス情報は、バイトコード番号によりテーブルから直接インデックス化される。この型情報とレングス情報は、付属ドキュメントＨに示すチェック処理に用いられる。付属ドキュメントＨにおいて、チェック処理は、付属ドキュメントＧのテーブルから得られるレングス情報と型情報のデコード処理により開始される。レングス情報は、プログラムカウンタをカウントアップするために利用される。型情報は、実行しようとするバイトコードを扱うＶＭスタック１４４ａのデータ型が正しいものであることを保証するための実行前チェックに利用される。テーブル格納に用いる２５６バイトのＲＯＭは、カードＪＶＭ１６上で実行するオリジナルＪａｖａバイトコードに割り当てられ、カードにロードされるＪａｖａクラスファイルに要求される変更を最小限にする。追加Ｊａｖａバイトコードは、比較的適切にテーブルエントリを更新するのが簡単であるので、サポートしやすい。他の実施形態において、図１０に示すように、メソッドにおけるＪａｖａバイトコードは、再配置処理において付属ドキュメントＨのテーブルに格納されるバイトコード型情報、レングス情報を暗示するようにリナンバリングされる。付属ドキュメントＨを参照して説明する。その結果、ＶＭスタック１４４ａの状態と処理されたバイトコードに関して行なわれるチェック処理は、テーブルルックアップを含む必要はない。チェック処理は、付属ドキュメントＩに示されるように単純比較のセットにより実行される。この実施形態は、２５６バイトのテーブルを設けないので、ＲＯＭ容量の面で有利である。しかし、新たなバイトコードを、サポートするバイトコードセットに加えることは、注意して行なう必要がある。なぜなら新たなバイトコードをサポートするバイトコードの暗示ナンバリング処理スキーム（implicit numbering scheme）に適合させる必要があるためである。他の実施形態において、カードＪＶＭ１６は、実行スピードを考慮してあらゆるセキュリティチェックを実行しないものとすることができる。この処理は、図１８のフローチャートにより示される。図１８のフローチャートは、図１６のフローチャートからセキュリティチェック処理を除いたものと同じものとなっている。このオプションは、バイトコードのセキュリティが保証されていない場合には、セキュリティの面からは好ましいものではない。カードＪＶＭ１６は、他のセキュリティチェックを強化する。バイトコードがローカル変数を参照する場合、カードＪＶＭ１６は、当該参照が有効なものであるか否かをチェックし、有効でない場合はエラーを返す。参照が有効である場合、カードＪＶＭ１６は、その後のチェック処理に用いるローカル変数の型を格納する。ＶＭスタック１４４ａのポインタは、参照がまだ有効範囲にあるか否かチェックする。もし有効範囲にない場合は、例外処理を実行する。バイトコード番号をチェックする。もし、サポートされていないものであれば、例外処理を実行する。最後に、バイトコード自体がディスパッチされる１６５ｄ。カードＪＶＭ１６により変換されたバイトコードは、付属ドキュメントＣにリストアップされている。バイトコードのセマンティックは、バイトコードのディスパッチ処理前後のＶＭスタック１４４ａの状態とともに、上述のＪａｖａ仮想マシン仕様に記述されている。いくつかのバイトコード（INVOKESTATIC、INVOKESPECIAL、INVOKENON VIRTUAL、INVOKEVIRTUALのバイトコード）は、カードＪＶＭ１６にリエントリされ、要求する処理が開始されるサブルーチン１６１にエントリされる。図１７は、バイトコード実行ルーチンのフローチャートを示している。このルーチンは、与えられたバイトコード１７１を実行する。カードＪＶＭ１６は、バイトコードが要求するインストラクションを実行する(１７２)。カードＪＶＭ１６は実行処理される中でルーチン制限が発生すると(１７３)、エラーを返す(１５６)。エラーがカードＪＶＭ１６により端末装置に返される。もし、バイトコード実行が正常処理されると、正常(success)を返す(１７５)。実行後、ＶＭスタック１４４ａ状態を正しく設定するために結果の型が正しく利用され、適切にＶＭスタック１４４ａのデータ型のフラグ処理が行なわれる。バイトコード情報テーブルから先行処理１６５ｂで集められたバイトコード情報は、当該実行直後のバイトコードに関するＶＭスタック１４４ａの状態を設定するために利用される。他の実施形態において、実行されたバイトコードに関するＶＭスタック１４４ａの出力状態の設定処理は、バイトコードがリナンバリング処理されると簡単になる。この処理は、付属ドキュメントＩによって示されている。さらに、他の実施形態において、カードＪＶＭ１６は、カードＪＶＭ１６の実行スピードを考慮して、ＶＭスタック１４４ａの出力状態の設定処理を省略することができる。このオプションは、バイトコードのセキュリティが保証されていない場合には、セキュリティ面から好ましいものではない。バイトコードが実行された後、バイトコード１６５ｆは破棄される。この処理は、引数をＶＭスタック１４４ａから除去する処理を含む。ひとたび、バイトコード処理が完了すると、次のメソッドのバイトコード処理のループ１６４が繰り返される。ひとたび、ディスパッチループ１６４が終了すると、ＶＭスタック１４４ａの内容がクリアされる(１６６)。これにより、あらゆるオブジェクトリファレンスが他のカードＪＶＭ１６インボケーションに対してアクセスすることを防ぎ、カードＪＶＭ１６のセキュリティを破ることを防いでいる。バイトコードのディスパッチループ１６４の終了（１６７）は、カードＪＶＭ１６が要求されたメソッド実行が完了したことを意味する。ＩＣカード１０のデータとアプリケーションを相互に隔離するために、ＩＣカード１０はカードＪＶＭ１６が提供するファイアウォール機構１４９を利用する。カードＪＶＭ１６には標準パス３とパス４のベリファイアチェックが実装されているので、アプリケーションが他のアプリケーションのデータ領域、コード領域を参照しようとすれば検知することができ、セキュリティエラー１５６フラグを立てる。例えば、通常の低レベルアプリケーションは、非参照データ型であっても参照データとして扱うことができて、その結果、権限のないメモリ領域へのアクセスを可能とし、セキュリティ違反を起こすことができる。本発明によれば、カードアプリケーション１２６Ｚが非参照型データを参照データとして使おうとすると、セキュリティエラー１５６を起こしてしまうこととなる。通常のＪａｖａによれば、この保護アプリケーション環境は、サンドボッスクアプリケーション−インタプリタ実行環境として規定されている。しかし、これらファイアウォール構成は、独立した動作はしない。事実、このファイアウォール構成は、通常のアクセス制御リストおよび暗号機構とオーバラップし、また、相互に強化し合う関係にあり、以下のテーブルに示されるものである。これらを併せて利用することにより、ＩＣカードのデータとアプリケーションを隔離し、カードアプリケーション１２６が権限を持つＩＣカード１０のリソースのみにアクセスできるようにする。図１９に示すように、カードアプリケーション１２６Ｘ、１２６Ｙ、１２６Ｚはカードアプリケーション１２６が実行されるときに特定の特権を与えられる。例えば、これら特権は、カードアプリケーション１２６がどのデータファイルにアクセスでき、カードアプリケーション１２６がファイルシステム１４７においてどの処理が実行できるかを規定するものである。カードアプリケーション１２６に認められる特権は、通常は、特定のカードアプリケーション１２６Ｚが端末装置１４を介してユーザにより開始されときに設定される。ＩＣカード１０は、暗号ＩＤ識別認証メソッド(cryptographic identificatio n verification methods)が、ＩＤ１９０（例えば、１９０ａ、１９０ｂ、１９０ｃ）と関係付けられ、カードアプリケーション１２６を実行する特権のセットが設定される。特定のＩＤ１９０ｃのカードアプリケーション１２６Ｚとの関連性は、カードアプリケーション１２６Ｚの実行が開始されると設定され、それゆえ図２０に示すように特定の実行アプリケーション２００が生成される。ＩＤ１９０は、ＩＤトークンと関連付けられた、ユニークで読みやすいテキストストリングである。ＩＤトークン（例えば、個人認証番号(personal identification number(PI N))、または、ＲＳＡ暗号方式の秘密鍵）は、暗号方式の鍵である。図２０に示すように、特定のカードアプリケーション１２６Ｚを実行するため、カードアプリケーション１２６ＺのＩＤ１９０ｃは、認証されなけらばならない。ＩＤ１９０ｃは、ＩＤ１９０ｃと関連付けられたＩＤトークンのデモンストレーション知識(demonstrating knowledge)により認証される。カードアプリケーション１２６Ｚが実行されるためには、エージェント（例えば、カードホルダー、その他アプリケーションを実行したい者）は、アプリケーションのＩＤ暗号鍵を所有していること、または知っていることを示さなければならない。暗号鍵を所有していることをデモンストレーションする一つの方法は、単にその鍵自体を提示すれば良い。ＰＩＮ認証方式が、この認証方式の例である。実際に鍵自体を提示することなく暗号鍵を所有していることをデモンストレーションする他の方法は、平文を当該鍵により暗号化または復号化することができることを示せば良い。このように、ＩＣカード１０上の特定の実行アプリケーション２００は、カードアプリケーション１２６Ｚに加えて認証されたＩＤ１９０ｃを含んでいる。カードアプリケーション１２６は、これらの要素すべてが揃っていないと実行することができない。カードアプリケーション１２６Ｚは、実行するデータ処理を定義し、権限を与えられたＩＤ１９０ｃが、どのオブジェクトのオペレーションを実行するのかを規定する。例えば、特定のアプリケーション１２６Ｚは、特定のＩＤ１９０ｃに関連付けられたファイルシステム１４７のＩＤ“Ｃ”のファイル２０２のみをアクセスでき、特定のカードアプリケーション１２６Ｚは、ＩＤ体１９０ｃ以外のＩＤに関連付けられた他のファイル２０４に対してはアクセスできない。ＩＣカード１０は、アプリケーションとデータの隔離を確実にするための追加ステップを採りうる。ＩＣカード１０は、３つのソフトウェア機能のステップを備えている。認証されたＩＤのアクセス制御リストに関するステップ、Ｊａｖａベースの仮想マシンに関するステップ、データファイルとアプリケーション実行とコミュニケーションチェンネルを保護するワンタイムセッション暗号鍵に関するステップである。まとめると、一つの実施形態では、これらソフトウェア機能セットにより、当該実施形態におけるアプリケーションデータのファイアウォール１４９を提供する。以下は、それぞれのソフトウェア機能セットについて説明し、３つのソフトウェア機能セットが、ＩＣカード１０におけるアプリケーションとデータの隔離の確保のため、如何に協同しているかを示している。アクセス制御リスト（ＡＣＬ）は、アクセスが制御されて保護されているＩＣカード１０上のそれぞれのオブジェクト（例えば、データファイルまたは通信チャンネル）と関連付けられている。ＡＣＬ上のエントリ（例えば、特定のオブジェクト）は、ｅテュプルを参照するデータ形式である。型、ＩＤ、許可（type：identity：permissions）型フィールドは、以下のＩＤ（ＩＤフィールド内）、例えば、ユーザ(ジョンスミスなど)、グループなどのＩＤ型を示している。許可フィールドは、オブジェクトを利用するＩＤが実行できる処理のリスト（例えば、読み取り、付加、更新など）を示している。例として、ＡＣＬエントリを持つデータファイルは、 “USER、AcmeAirlines、RAU” であるので、ＩＤが“AcmeAirlines”であるあらゆるアプリケーションは、データファイルの読み取り“Ｒ”、付加“Ａ”、更新“Ｕ”を実行することができる。加えて、ＡＣＬは、データファイルの生成と消去を選択的に許可できる。さらに、ＡＣＬは、アプリケーションの実行を選択的に許可できる。オブジェクトは実行アプリケーション２００によってアクセスするときにはいつでも、アクセスは、カードＪＶＭ１６により遮断でき、カードオペレーションシステム１２２に渡され、オブジェクトに関連付けられたＡＣＬがあるかないかが決定される。もし、関連付けられたＡＣＬが存在する場合には、実行アプリケーション２００と関連付けられたＩＤ１９０ｃがＡＣＬによりマッチングが採られる。もし、ＩＤが見つからない場合、または、要求されているアクセスの型が許可できないものである場合には、アクセスが拒否される。それ以外は、アクセスが認められ、処理が実行される。図１３に示すように、ＩＣカード１０と端末装置１４の間の単一のデータパスが形成されることによる潜在的な問題を回避するため、通信チャンネルの隔離化が、カードアプリケーション１２６Ｚと端末装置アプリケーション１３６間で実施されるワンタイムセッションキーの交換によるＩＤ認証プロセスによって達成される。当該キー２０９は、後続の認証する端末装置１３６と認証されるアプリケーション１２６Ｚ間のトラフィックを暗号化するために利用される。ワンタイムセッションキー２０９が設定されると、不正な端末装置アプリケーションは、認証された端末装置１４とＩＣカード間の通信を“読み込む”ことも、認証を受けていない処理をカードアプリケーション上で実行させるように“だます”こともできない。カード・端末間トラフィックの暗号化と復号化は、カードオペレーティングシステム１２２、カードアプリケーション１２６Ｚ自体のいずれによっても扱うことができる。前者のケースでは、端末装置１４との通信では、アプリケーションに対してトランスペアレント（復号可能）に暗号化されており、メッセージトラフィックは複合化されて、アプリケーションのデータ領域に渡される。後者のケースでは、カードアプリケーション１２６Ｚは、セキュリティ用のエクストラ階層を提供する暗号化、複合化を実行するか否かを選択でき、アプリケーションにより、データ生成されれば即座に暗号化しておき、当該データが利用される場面になったときのみに複合化する。それ以外は、データが、セッションキー２０９をもって暗号化されたままの状態である。このように、アプリケーションのファイアウォールは、３つのソフトウェア機能セットにより相互強化が図られている。データファイルは、認証されたＩＤアクセス制御リストにより保護されている。アプリケーション実行領域は、カードＪＶＭ１６により保護されている。通信チャンネルは、ワンタイムセッションキー２０９の暗号処理により保護されている。他の実施形態において、上記技術は、マイクロコントローラ（プロセッサ１２）で利用され、ＩＣカード以外の各種デバイス（例えば、車のエンジン）の制御を実行できる。これらアプリケーションにおいては、マイクロコントローラが高級プログラミング言語の格納と実行を行なうための小規模なプラットフォーム（例えば、半導体基板上に配置された中央演算処理ユニット、メモリ）を提供することとなる。マイクロコントローラを利用する、現存するデバイスの多く、新しく作られるデバイスは、本発明を利用して、高級プログラミング言語を用いてマイクロコントローラのプログラムをすることができ、これらデバイスのアプリケーションを含めることができる。端末装置アプリケーションは、Ｊａｖａアプリケーション、Ｊａｖａアプレット(applets)、Ｊａｖａアグレット(aglets)、Ｊａｖａサーブレット(servlets) 、Ｊａｖａコムレット(commlets)、以下に示されるクラスファイルの結果であるＪａｖａコンポーネントと、他の非Ｊａｖａプログラムなどあらゆるプログラムが含まれる。クラスファイルは、Ｊａｖａプログラムファイル以外のソースファイルを含んでいる。Ｊａｖａ以外のいくつかのプログラミング言語は、それぞれのソースファイルからクラスファイルを生成するためのコンパイラまたはアセンブリを備えている。例えば、プログラミング言語ＥＩＦＦＥＬは、ＪＶＭバイトコードを生成するＥＩＦＦＥＬコンパイラであるＰＩＲＭＩＮカルベラ(kalberer)の“Ｊ− ＥＩＦＦＥＬ”を利用してクラスファイルを生成することができる(ウェブサイト：http//www.spin.ch/〜kalberer/jive/index.htm)。Ａｄａ９５からＪａｖａバイトコードへのトランスレータは、以下の参考文献（Taft,S.Tucker，“Progr amming the Internet in Ada 95”proceedings of Ada Europe 96,1996）に記述されている。ジャスミン(Jasmin)は、Ｊａｖａバイトコードアセンブラであり、クラスファイルを生成するために利用される。ジャスミン(Jasmin)は、以下の参考文献に記述されている。“Meyer,Jon and Troy Downing,"Java Virtual Machi ne",O'Reilly,1997。クラスファイルのソースにかかわらず、インタプリタ処理されるためのコードを生成するため、上記の記述は、Ｊａｖａ以外の言語に適用される。図２１に示すように、マイクロコントローラ２１０を含むＩＣカード、スマートカードは、プラスティックカード２１２上に搭載されている。このプラスティックカード２１２は、典型的なクレジットカードと同様の形状を持つものである。通信部１２ａは、通信チャンネルを確立するための接触式パッド２１４か、または、無線通信システムを備えている。他の実施形態において、図２２に示すように、マイクロコントローラ２１０は、携帯電話または設置型電話２２０に搭載され、電話にスマートカードの機能を効率的に持たせることができる。他の実施形態において、マイクロコントローラ２１０は、図２３に示すように、キーリング２３０に組み込まれる。これにより、キーリング２３０のマイクロコントローラ２１０と関連付けられているＩＤを認識するための仕組みが装備されている自動車に対して、高いセキュリティのもと、アクセスすることが可能となる。時計や指輪などの貴重品類２４０は、図２４に示すように、高いエルゴノミックス性をもってマイクロコントローラ２１０を埋め込むことができる。これら実施形態は、典型的には、通信チャンネルを確立するため無線通信システムを利用し、また、ユーザに対して最小限の手間でアクセス制御のための実装を可能とする方法を提供する。図２５は、自動車２５４の電気回路サブシステム２５２に搭載されるマイクロコントローラ２１０を示している。この実施形態では、マイクロコントローラは、自動車へのアクセス制御処理(例えば、ＩＤチェック、自動車のイグニッションシステムの起動制御など)、無線通信による有料道路料金徴収システム、自動車の通行位置を検知する位置決めシステム（ＧＰＳ）のインタフェース提供など、多様な目的に利用される。本発明の特定の実施形態を説明したが、本発明の開示に基づいて、他の様々な変更や置換が、当業者にとって明らかである。このような変更や置換は、本発明の範疇に入るものであり、特許請求の範囲に記載された内容に基づいて、本発明の技術的範囲に含まれる。付属ドキュメントＡ（APPENDIX A）好ましい実施形態におけるカードクラスファイル形式カードクラスファイルは、オリジナルクラスファイルの圧縮形式である。カードクラスファイルは、オリジナルクラスファイルからＪａｖａプログラムをインタプリタ処理するために必要とされるセマンティック情報のみを含んでいる。オリジナルクラスファイルの間接参照は、コンパクト表現の結果、直接参照により置き換えられる。カードクラスファイル形式は、以下の原則に基づいている。標準クラスファイル形式に近づけること。カードクラスファイル形式は、標準クラスファイル形式に可能な限り近づけるべきである。クラスファイルのＪａｖａバイトコードを変更しない。バイトコードを変更せず、バイトコードに対する構造的、静的な制約条件がそのままであることを確実にする。実装を容易にすること。カードクラスファイル形式を、Ｊａｖａ仮想マシンの実装を行なうものに対して十分シンプルなものとする。異なるが等価に振舞う実装を認める。フィージビリティカードクラスファイル形式が、スマートカード技術に適合するためにコンパクトにされたものでなければならない。現在の技術的制約に適合し、さらに、将来の技術革新の適合性を失わないものであること。この記載は、「Ｊａｖａ仮想マシン仕様“The JavaTM Virtual Machine Speci fication”[1](以下、レッドブックと呼ぶ)」というタイトルの本の第４章「クラスファイル形式」に基づいている。このドキュメントは、レッドブックに記載された標準クラスファイル形式に基づいているので、ここでは、レッドブックにはない情報のみ提示する。レッドブックは、すべての規則の最終的な権原として扱われる。標準クラス形式との主な違いは、以下である。コンスタントプール(constant pool)が、１６ビットのＩＤ識別子のみを含むように最適化され、可能な限り間接参照が直接参照に置き換えられている。オリジナルクラスファイルの属性情報は、削除され、または、再グループされている。Ｊａｖａカードクラスファイル形式（Java Card class File Format）当該セクションは、Ｊａｖａカードクラスファイル形式を記載している。各カードクラスファイルは、１つまたは複数のＪａｖａ型を含んでいる。この型は、クラスまたはインタフェースである。カードクラスファイルは、８ビットバイトストリームにより構成される。１６ビット、３２ビット、６４ビット量データは、それぞれ、連続する８ビットバイトデータを２つ、４つ、８つ読み込むことにより構成される。マルチバイトデータは、常に、ビックエンディアンで格納され、大きなバイトから順になっている。Ｊａｖａでは、この形式は、java.i o.Datainput、java.io.DataOutputのインタフェース、java.io.DatainputStream 、java.io.DataOutputStreamなどのクラスによりサポートされている。Ｊａｖａクラスファイルデータを表わすデータ型と同じセットを定義して用いる。Ｕ１、Ｕ２、Ｕ４の型は、それぞれ、割り当てられていない１、２、４バイト量を表わしている。Ｊａｖａにおいて、これら型は、リードアンサインドバイト(readUns ignedByte)、リードアンサインドショート(readUnsignedByte)、“java.io.Data input”のインタフェースのリードイント(readint)などのメソッドにより読み込みされる。カードクラスファイル形式は、Ｃ言語のような構造分類記号法で書かれている擬構造を使用して表現される。Ｊａｖａカード仮想マシンのクラスとクラスインスタンスのフィールドの混乱を避けるために、カードクラスファイル形式を記述する構造内容はアイテムと呼ばれる。Ｃ構造のフィールドとは異なって、連続したアイテムはカードクラスファイルの中にパディングもアライメントもなしで連続して格納されている。変数サイズのアイテムから成る変数サイズのテーブルは、いくつかのクラスファイル構造で使用されるている。Ｃ言語のようなテーブルアイテムを参照する配列シンタックスを使っても、テーブルが可変サイズ構造のストリームであるという事実は、テーブルインデックスをテーブルのバイトオフセットとして直接変換できることを意味する。ここで配列と呼んでいるデータ構造は、文字通り配列構造を持っている。カードクラスファイル構造と標準のクラスファイル構造を見分けるために、大文字を加える。例えば、オリジナルのクラスファイルの中のfield infoをカードクラスファイルの中では、FieldInfoに改名する。カードクラスファイル（Card Class File）カードクラスファイルは単一のCardClassFile構造を含んでいる: CardClassFile構造のアイテムは以下の通りである： minor_version,major_version minor_versionとmajor_versionアイテムの値は、このカードクラスファイルを作り出した、オフカードＪａｖａカード仮想マシン(off-card Java card virtual machine)のマイナーおよびメジャーバージョンの番号である。通常、Ｊａｖａカード仮想マシンの実装は、与えられたメジャーバージョン番号と、０から幾つかの特定番号のマイナーバージョン番号を持っているカードクラスファイルをサポートする。Ｊａｖａカードフォーラムのみが、カードクラスファイルバージョン番号の意味を定義することができる。 name_index name_indexアイテムの値は、有効なＪａｖａクラス名を表さなければならない。 name_indexによって表されたＪａｖａクラス名は、カードを実行するメインアプリケーションに対応するちょうど同じＪａｖａクラス名でなければならない。カードクラスファイルは、カードにおいて実行されるアプリケーションを構成するクラスまたはインタフェースを含んでいる。Ｊａｖａでは、各クラスがメインメソッドを含むことが許容されるので、カードアプリケーションに対応するメインメソッドを含んでいるクラスファイルを区別する方法がある。 const_size const_sizeの値は、カードクラスファイルコンスタントプールの中のエントリの番号を与える。constant_poolインデックスは、ゼロ以上、const_sizeより以下ならば有効であるとされる。 max_class この値は、カードクラスファイルの中に存在しているクラスの番号を参照する。ネームリゾリューション(name resolution)と、Ｊａｖａカードのリンキングは、オフカードＪａｖａ仮想マシンにより実行されるので、全てのクラスファイルとアプリケーションに要求されるクラスは、１つのカードクラスファイルにまとめられる。 constant_pool[] constant_poolは、CardClassFile構造とそのサブ構成内で参照される様々なストリング定数、クラスネーム、フィールドネーム、他の定数を表す可変長の構造() のテーブルである。カードクラスファイルにおける最初のエントリはconstant_P ool[0]である。インデックス０からconst_sizeまでの各constant_Poolのテーブルのエントリは、可変長の構造()を持っている。 class[] クラスは、カードにロードされるアプリケーションを構成するmax_classクラスのテーブルである。コンスタントプール（Constant Pool）すべてのconstant_poolのテーブルのエントリには，以下の一般形式がある： constant_poolテーブルの中の各アイテムは、cp_infoエントリの種類を示す１バイトのタグで始めなければならない。info配列の内容はタグの値に従って異なる。有効なタグとそれらの値はレッドブックで指定されたものと同じである。それぞれのタグバイトの後には、特定の定数に関する情報を与える２またはそれ以上のバイトが続く。追加情報の形式はタグ値に従って異なる。現時点で含まれる必要があるのタグは、CONSTANT_Class、CONSTANT_FieldRef、C ONSTANT_MethodRefおよびCONSTANT_InterfaceRefのみである。そのままの形で追加される他のタグのサポートは、仕様書に含まれている。 CONSTANT_Class CONSTANT_Class_info構造は、クラスまたはインタフェースを表現するために使用される: CONSTANT_Class_info構造のアイテムは以下である: tag タグアイテムには、CONSTANT_Class(7)の値を持っている。 name_index name_indexアイテムの値は、有効なＪａｖａクラス名を表さなければならない。 name_indexによって表されたＪａｖａクラス名は、オリジナルクラスファイルの constant_Poolの対応するCONSTANT Classエントリによって記述されるＪａｖａクラス名とまったく同じものである。CONSTANT_Fieldref，CONSTANT_Methodref, CONSTANT_InterfaceMethodref Fields，メソッド，およびインタフェースメソッドは、同様の構造によって表される: これらの構造のアイテムは以下の通りである: tag CONSTANT_FieldrefInfo構造のタグアイテムは、CONSTANT_Fieldref(9)の値を持っている。 CONSTANT_MethodrefInfo構造のタグアイテムは、CONSTANT_Methodref(10)の値を持っている。 CONSTANT_Interface MethodrefInfo構造のタグアイテムは、 CONSTANT_InterfaceMethodref(11)の値を持っている。 classs_index class_indexアイテムの値は、有効なＪａｖａクラスまたはインタフェース名を表さなければならない。class_indexによって表された名前はオリジナルのクラスファイルのccnstant_Poolの対応するCONSTANT_Class_infoエントリによって記述される名前とまったく同じものである。 name_sig_index name_sig_indexアイテムの値は、有効なＪａｖａ名と型を表さなければならない。name_sig_indexによって表わされた名前と型は、オリジナルクラスファイルの constant_pool構造のCONSTANT_NameAndType_infoエントリによって記述される名前と型とまったく同じものである。クラス（Class）各クラスは固定長レコードClassInfo構造によって記述される。この構造の形式は以下の通りである． ClassInfo構造のアイテムは以下の通りである: name_index name_indexアイテムの値は、有効なＪａｖａクラス名を表さなければならない。 name_indexによって表されたＪａｖａクラス名は、オリジナルクラスファイルの対応するClassFile構造で記述されるＪａｖａクラス名とまったく同じものである。 max_field max_fieldアイテムの値は、このクラスまたはインタフェース型によって宣言されたインスタンス変数を表すフィールドテーブルの中のFieldInfo()構造の番号を与える。この値は、カードクラスファイルの非静的フィールドの番号を参照する。クラスがインタフェースを表すならば、max_fieldの値は０である。 max_sfield max_sfieldアイテムの値は、このクラスまたはインタフェース型によって宣言されたクラス変数を表すフィールドテーブルの中のFieldInfo構造の番号を与える。この値は、カードクラスファイルの静的フィールドの番号を参照する。 max_method max_methodアイテムの値は、メソッドテーブルの中のMethodInfo()構造の番号を与える。 max_interface max_interfaceアイテムの値は、このクラスまたはインタフェース型のダイレクトスーパーインタフェースの番号を与える。 superclass クラスのために、スーパークラスアイテムの値は、有効なＪａｖａクラス名を表さなければならない。スーパークラスによって表されたＪａｖａクラス名は、オリジナルクラスファイルの対応するClassFile構造で記述されるＪａｖａクラス名とまったく同じものである。スーパークラス、またそのスーパークラスのいずれもは、最終的なクラスではない。スーパークラスの値が０ならば、このクラスは、class java.lang.Objectであり、クラスまたはインタフェースをスーパークラスなしで表わさなければならない。インタフェースに関しては、スーパークラスの値はいつも、Java class java.lang.Objectを表さなければならない。 access_flags access_flagsアイテムの値は、クラスとインタフェース宣言とともに利用される変更子(modifier)のマスクである。access_flags変更子とそれらの値は、オリジナルクラスファイルの対応するClassFile構造のaccess_flags変更子と同様のものである。 field[] フィールドテーブルの中の各値は、クラスまたはインタフェース型のフィールドの完全な記述を与える固定長レコード、FieldInfo()構造でなければならない。フィールドテーブルは、このクラスまたはインタフェースによって宣言されるそれらのフィールドのみを含む。スーパークラスまたはスーパーインタフェースから引き継がれるフィールドを表すアイテムを含まれていない。 interface[] インタフェース配列における各値は、有効なインタフェース名を表さなければならない。各エントリで表されるインタフェース名は、オリジナルクラスファイルの対応するインタフェース配列において記述されるインタフェース名とまったく同じものでなければならない。 method[] メソッドテーブルの各値は、クラスまたはインタフェースのメソッドに対するＪａｖａ仮想マシンのコードの完全な記述を与える可変長MethodInfo()構造を持っている。MethodInfo構造は、このクラスまたはインタフェース型によって宣言されるすべてのメソッド、インスタンスメソッド、クラス、クラス（静的）メソッドを表わしている。メソッドテーブルは、このクラスによって明らかに宣言されるメソッドを含むのみである。インタフェースには、単一のメソッド<clinit>、インタフェース初期化メソッドのみがある。メソッドテーブルは、スーパークラスまたはスーパーインタフェースから引き継がれたメソッドを表わすアイテムが含まれていない。フィールド（Fields）各フイールドは、固定長レコードfield info構造によって記述されている。この構造の形式は以下のようになっている。 FieldInfo構造のアイテムは以下の通りである: name_index name_indexアイテムの値は、有効なＪａｖａフィールド名を表さなければならない。 name_indexによって表されたＪａｖａフィールド名はオリジナルクラスファイルの対応するfield_info構造で記述されるＪａｖａフィールド名とまったく同じものである。 signature_index signature_indexアイテムの値は、有効なＪａｖａフィールドディスクリプタを表さなければならない。署名(signature)インデックスによって表されるＪａｖａフィールドディスクリプタはオリジナルクラスファイルの対応するfield_info 構造で記述されるＪａｖａフィールドディスクリプタとまったく同じもである。 access_flags access_flagsアイテムの値は、アクセス許可を記述することに使用された変更子のマスクとフィールドのプロパティである。access_flags変更子とそれらの値は、access_flags変更子とオリジナルクラスファイルの対応するfield_info構造のものと同じである。メソッド（Methods）各メソッドは、可変長のMethodInfo構造によって記述される。 MethodInfo構造は、Ｊａｖａ仮想マシンのインストラクションと、単一のＪａｖａメソッド、インスタンス初期化メソッド、クラスまたはインタフェース初期化メソッドの補助情報を含む可変長データ構造である。構造は、以下の形式を持つ: MethodInfo構造のアイテムは以下の通りである: name_index name_indexアイテムの値は、特別な内部のメソッド名(<init>か<clinit>のどちらかの１つ)か、有効なＪａｖａメソッド名のどちらかを表さなければならない。name_indexによって表されたＪａｖａメソッド名はオリジナルクラスファイルの対応するmethod_info構造で記述されるＪａｖａメソッド名とまったく同じものである。 signature_index signature_indexアイテムの値は、有効なＪａｖａメソッドディスクリプタを表さなければならない。signature_indexによって表されたJavaメソッドディスクリプタはオリジナルクラスファイルの対応するmethod_info構造で記述されるＪａｖａメソッドディスクリプタとまったく同じものである。 max_local インボケーション(invocation)においてメソッドに渡されたパラメータを除いて、max_localsアイテムの値は、このメソッドによって使用されるローカル変数の数を与える。第１のローカル変数のインデックスが０である。１ワード値のもっとも大きなローカル変数のインデックスは、max_locals-1である。 max_arg max_argアイテムの値は、引数の最大の数をこのメソッドに与える。 max_stack max_stackアイテムの値は、このメソッド実行中のあらゆるポイントにおけるオペランドスタックのワードの最大数を与える。 access_flags access_flagsアイテムの値は、アクセス許可を記述することに使用された変更子のマスクと、メソッドまたはインスタンス初期化メソッドのプロパティである。 access_flags変更子とそれらの値は、access_flags変更子とオリジナルクラスファイルの対応するmethod_info構造と同じものである。 code_length code_lengthアイテムの値は、このメソッドのためのコード配列におけるバイト数を与える。code_lengthの値は、ゼロ以上でなければならず、コード配列は空ではない。 exception_length exception_lengthアイテムの値は、exception_infoテーブルの中のエントリの数を与える。 code[] コード配列はメソッドを実現するＪａｖａ仮想マシンコードの実際のバイトを与える。コード配列がバイトアドレス可能なマシンのメモリに読み込まれるとき、もし配列の第１バイトが４バイト境界で並べられるならば、テーブルスイッチ(t ableswitch)とルックアップスイッチ(lookupswitch)の３２ビットオフセットは４バイトに並べられ、コード配列配置の結果に関するさらなる情報のインストラクションの記述を参照する。コード配列の内容の詳細な制約条件は大規模であり、Ｊａｖａ仮想マシン仕様で記述されるものと同じである。 einfo[] einfo配列における各エントリは、コード配列における１つの例外処理ハンドラを記述する。それぞれのeinfoエントリは以下のアイテムを含んでいる: start_pc,end_pc ２つのアイテム、start_pcおよびend_pcの値は例外処理ハンドラがアクティブとなるコード配列における範囲を示す。start_pcの値はインストラクションのオペコードのコード配列の有効なインデックスでなければならない。end_pcの値は、インストラクションのオペコードのコード配列の有効なインデックスでなければならず、またはcode_lengthのコード配列の長さに等しいものでなければならない。start_pcの値はend_pcの値以下でなければならない。 start_pcは包括的で、end_pcは排他的である。すなわち、プログラムカウンタが star_pc、end_pcのインターバルにある間は、例外処理ハンドラはアクティブである。 handler_pc handler_pcアイテムの値は、例外処理ハンドラの始まりを示す。アイテムの値は、コード配列への有効なインデックスでなければならず、インストラクションのオペコードのインデックスでなければならず、code_length item 値以下でなければならない。 catch_type catch_typeアイテムの値がノンゼロならば、それは有効なＪａｖａクラス型を表現しなければならない。catch_typeによって表わされたＪａｖａクラス型は、オリジナルクラスファイルの対応するmethod_info構造のcatch_typeによって記述されるＪａｖａクラス型とまったく同じでなければならない。このクラスはクラスThrowableまたはそのサブクラスの１つに違いない。例外処理ハンドラは、投げられた例外処理が与えられたクラスのインスタンスまたはそのサブクラスの１つであれば、コールされる。catch_typcアイテムの値がゼロならば、この例外処理ハンドラはすべての例外処理のためにコールされる。これは、最後に実装される。属性（Attributes）オリジナルクラスファイルの中で使用された属性は、コンパクションのために消去されるかまたは再グループ化される。Ｊａｖａバイトコードのインタプリタ処理に必要であるどんな情報も犠牲にすることなく、事前に定義された属性であるSourceFile、ConstantValue、Exceptions、LineNumberTableおよびLocal-Vari ableTableは消去されうる。特定のメソッドのためバイトコードを含む事前に定義された属性Codeが、対応するMethodInfo構造に移動される。Ｊａｖａカード仮想マシンコードの制約条件（Constraints on Java Card Vir tual Machine Code）Ｊａｖａカード仮想マシンコードのメソッド、インスタンス初期化メソッド，クラスまたはインタフェース初期化メソッドがカードクラスのMethodInfo構造の配列コードに格納される。このコード配列の静的と構造的な制約条件の両方とも、レッドブックで記述したものと同じものである。Ｊａｖａカード仮想マシンとＪａｖａカードクラスファイル形式の制限（Limi tations of the Java Card Virtual Machine and Java Card class File Format ）Ｊａｖａカード仮想マシンでの以下の制限は、Java Card Virtual Machine仕様書のこのバージョンによって規定されている。カードクラスファイルコンスタントプールあたり、CardClassFiIe構造()の１６ビット定数サイズフィールドによって６５５３５のエントリ数に制限される。これは、単一のカードクラスファイルの総合複雑度(total complexity)に対する内部制限として機能する。また、このカウントは、カードのアプリケーションに利用可能なクラス階層のコンスタントプールに対応するエントリを含む。メソッドあたりのコード量は、MethodInfo構造のインデックスのサイズによって６５５３５バイトに制限される。メソッドにおけるローカル変数の数は、MethodInfo構造()の最大ローカルアイテムのサイズによって２５５に制限される。クラスのフィールドの数は、最大フィールドのサイズとClassInfo構造()のmax sfieldアイテムによって５１０に制限される。クラスのメソッドの数は、ClassInfo構造()の最大メソッドアイテムのサイズによって２５５に制限される．オペランドスタックのサイズは、MethodInfo構造()のmax_stackフィールドによって２５５ワードに制限される。参考文献（Bibliography） [1]Tim Lindholm and Frank Yellin,The Java Virtual Machine Specification, Addison-Wesley,1996．付属ドキュメントＢ（APPENDIX B）ＩＤインプットとアウトプットのストリングカードＪＶＭの訂正処理において、宣言され生成されたＩＤ識別子が正しく管理されることは、非常に重要である。この管理は、ＩＤインプットファイルStri ng-ID INMapの定義によって制御される。このテキストファイルは、以下に示されたものを基礎として、ネーム領域(namespace)の領域が何の目的を使用されるかを宣言している。このマップの１つの可能なアレンジメントは、カードＪＶＭインタプリタによる内部利用のためにいくつかのＩＤ識別子をリザーブすることができることであり、残りはカードＪＶＭアプリケーションに割り当てられる。本質的には、スマートカードにロードされることになっているすべてのアプリケーションは自らのＩＤ識別子を、Ox4000からOx7FFFの間に割り当てる。如何なるロードされたアプリケーションも他のアプリケーションにアクセスするのは許可されていないので、この領域は各アプリケーションが自由に利用できる。プリロードされたクラスライブラリのためにＩＤ識別子を管理するときには注意を要する。これらのＩＤ識別子の管理は、ＩＤ識別アウトプットファイルStri ng-ID OUTMapのオプション生成により補助される。このマップは、新しいString -ID割り付け処理(bindings)により増えて行くString-ID INMapである。これら割り付け処理(bindings)は、カードクラスファイルコンバータのアプリケーションが終了したときに生成される。String-ID OUTMapは、カードにロードされたサポートライブラリとＯＳインタフェースのために生成される。このマップは、カードにロードされたサポートライブラリとＯＳインタフェースを使用するスマートカードのアプリケーション用のString-1D INMapとして使用される。新しいアプリケーションを割り当てるとき、一般にこのファイルは破棄される。例として、以下のＪａｖａプログラム、HelloSmartCard.javaを考える。コンパイルされると、HelloSmartCard.classのクラスファイルが生成される。このクラスファイルは、それにクラス名、メソッドおよび型情報を表すストリングが埋め込まれている。上記されたString-ID INMapに基づいて、カードクラスファイルコンバータは、カードクラスファイルコンバータによってＩＤ識別子が割り当てられたクラスファイル中のストリングと置き換えるカードクラスファイルを生成する。テーブル１は、HelloSmartCard.classの定数プールの中にあるストリングを、カードクラスファイルコンバータが割り当てたＩＤ識別子とともに、リストアップしている。いくつかのストリング(“java/lang/Object”など)は、事前割り当てされている値(F002)であり、いくつかのストリング(“()V”など)は、新しい値(4004)となっている。付属ドキュメントＣ（APPENDIX C）好ましい実施形態におけるカードＪＶＭがサポートするバイトコード好ましい実施形態においてサポートされるバイトコードに対する標準Ｊａｖａバイトコード番号付属ドキュメントＤ（APPENDIX D）カードクラスファイルコンバータのバイトコード変換プロセス付属ドキュメントＥ（APPENDIX E）ローディング・実行制御プログラムの例付属ドキュメントＦ（APPENDIX F）好ましい実施形態におけるカードオペレーティングシステム機能へのアクセスメソッド付属ドキュメントＧ（APPENDIX G）バイトコード属性テーブルＪａｖａバイトコードの型グループ分け各バイトコードは、型に関して５ビットが割り当てられている。これは、似通った動作をするコードをセットとしてグループ化するために使われる。一般にこの動作は、バイトコードの型がスタック上でどのように処理されるかを反映しているが、型０、１３、１４、１５は、コメントセクションで定義された特定種類のインストラクションを反映するものである。下記のテーブルは、各インストラクション型の実行前後のスタックの状態を示したものである。使用する標準Ｊａｖａバイトコード（再配置なし）−属性ルックアップテーブル／＊＊バイトコードデコード情報テーブル。これは、バイトコード型とバイトコード長を含んでいる。コード０から２０１（２０２のコードがある）の現時点のすべてのバイトコードをサボートしている(例、no quicks)。＊／付属ドキュメントＨ（APPENDIX H）型ごとのＪａｖａバイトコードに行なわれるチェック処理インストラクションのデコード。これは、次のＰＣ(プログラムカウンティング) の長さとインストラクション型を与えるものである。下記に基づくいくつかの先実行のチェック処理を実装する。最後に、いくつかの後実行のチェック処理を実装する付属ドキュメントＩ（APPENDIX I）再番号づけされたＪａｖａバイトコードに行なわれるチェック処理インストラクションを獲得する。インストラクションの数値はインストラクション型の中に暗示的に含まれている。下記に基づくいくつかの先実行のチェック処理を実装する。／＊＊インプットスタックの状態をチェックする。バイトコードをリナンバリングし、バイトコードの値（以下、バイトコード）が正しいグループに属しているか否かをテストすることにより、必要なセキュリティチェックが実行できる。最後に、いくつかの後実行のチェック処理を実装する。サポートされたＪａｖａバイトコードの型ごとの再配置

【手続補正書】特許法第１８４条の８第１項【提出日】平成１０年１１月１６日（１９９８．１１．１６）【補正内容】１命令で［１６ビット、３２ビット、６４(訳注：当該部分は第２頁末尾部分より)］ビットまたはそれ以上の情報が処理できる。マイクロプロセッサとは対照的に、マイクロコントローラは、中央演算処理装置(ＣＰＵ)、メモリ、その他の機能要素すべてを１枚の半導体基板または１つのＩＣ回路（ＩＣチップ）として備えている。マイクロプロセッサが比較的大容量である外部メモリにアクセスするのに対して、典型的なマイクロコントローラはかなり小容量のメモリにアクセスする。典型的なマイクロコントローラは、１キロバイト〜１６キロバイトの内蔵メモリにアクセス可能であり、特に１６キロバイト内蔵メモリのものが広く使われている。一般的には、３つの異なるタイプのメモリ、ランダムアクセスメモリ(ＲＡＭ) 、リードオンリーメモリ(ＲＯＭ)、電気的に消去可能なプログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）が使われている。マイクロコントローラにおいて、利用可能な上記各種のメモリの容量は、当該メモリに割り当て可能なＩＣチップの面積容量の制限を受ける。典型的には、ＲＡＭは多くの面積を必要とし、供給されるメモリ容量はもっとも少なくなる。ＲＯＭはもっとも少ない面積で済み、供給容量は大きくなる。ＥＥＰＲＯＭは、ＲＡＭよりも供給容量は大きくなるが、ＲＯＭより供給容量は小さくなる。それぞれのメモリ種類の適する用途は異なっている。ＲＯＭはもっとも安価であるが、例えば、オペレーティングシステムのコードなど書き換えの必要のないデータの記憶用途に適している。ＥＥＰＲＯＭは、印加電圧がオフされた後も保持する必要のあるデータの記憶用途に適しているが、書き込み時間が非常に遅い。ＲＡＭはデータ書き込み、読み出しとも高速に実行できるが、高価であり、かつ印加電圧除去により記憶データが失われてしまう。マイクロプロセッサは、典型的には、比較的少容量のＲＯＭとＥＥＰＲＯＭを持ち、さらに、１〜１２８メガバイトのＲＡＭを備えている。それは、１つのＩＣデバイス上に何を搭載するかに関して制約がないからであり、また、ＥＥＰＲＯＭより低コストで大容量、書き換え可能、不揮発性の記憶媒体である外部ディスクメモリにアクセスすることが可能であるからである。しかしながら、マイクロコントローラは、典型的には、０．１〜２．０キロバイトの小容量のＲＡＭと、２〜８キロバイトのＥＥＰＲＯＭと、８〜５６キロバイトのＲＯＭを備えている。外部コンポーネントが少なくかつサイズが小さいため、マイクロコントローラはスマートカードなどのＩＣカードに広く用いられている。このようなスマートカードには、使用時にカードリーダに挿入する必要がある接触式カードや、カードリーダに挿入する必要のない非接触式カードなど多様な形態がある。実際に、非接触式通信を行なうマイクロコントローラは、時計や指輪など特別な形状物に埋め込まれることがあり、エルゴノミックス性が高くかつ魅力的な方法でスマートカードの機能をそれら形状物に統合させている。リソース環境の制約のため、スマートカード用のアプリケーションは、典型的には低レベルプログラミング言語（例えばアセンブリ言語）により記述され、メモリに格納される。高級プログラミング言語を用いてスマートカードをプログラミングする１つの方法は、フランスの特許出願番号９０１１８１８号、発明の名称「簡単にプログラムが可能なマイクロ回路用の携帯型サポート媒体および前記マイクロ回路をプログラムする方法(Potable support medium for an easily programmable micro circuit and programming procedure for said maicrocircuit)」、公開番号２６６７１７１号に記載されている。しかし、この特許出願には、データセキュリティに関する記載、スマートカード上のデータと情報に関する権限のないアクセスを如何に防ぐか、プログラマがＪａｖａなどの表現豊かなプログラミング言語を用いてスマートカード用のプログラムを作ることができるプログラミング環境を如何に提供するか、さらに、スマートカードの実行制約条件内で動作するインタプリタを使ってプログラムを如何に実行するかについて記載されていない。ＩＣカードは、ロバスト性、タンパー耐性、格納データの可搬性が確保されなければならない。ＩＣカードは、そのサイズの小型性、ＩＣカードならではのハード的とソフト的なセキュリティの高さによって、パーソナルコンピュータ中のもっともパーソナル用途のものと位置付けられている。ＩＣカードおよびＩＣカードのマイクロコントローラの最重要なタスクは、カードに記録されたデータの保護である。それゆえ、１９７４年のＩＣカードの発明以来、セキュリティを理由にＩＣカード技術は閉鎖的にガードされてきた。ＩＣカードは、最初にフランスの銀行によりデビットカード（即時決済方式カード）として利用された。このアプリケーションでは、ＩＣカードをベースとした金融関係のトランザクションが認証されるためには、ＩＣカード利用者は当該ＩＣカードを所有しているという事実に加え、さらにＩＣカード内に記録されている４桁の個人認証番号（ＰＩＮ）を示さなければならない。紛失または盗難されたＩＣカードのＰＩＮ番号を割り出すために役立ちうるあらゆる情報は、公開されないように秘密に付されている。事実、誰もどんな情報がＰＩＮ番号割り出しに役立つ情報か分からないし、ＩＣカードに関するすべての情報は秘密にされている。セキュリティを考慮して、ＩＣカード用のアプリケーションは独自仕様で記述されている。例えば、各々のアプリケーションは典型的には、特定のカード所有者、特定のＩＤ識別主体により識別される。アプリケーションがアセンブリ言語などの低レベルプログラミング言語で記述されているため、アプリケーションは特定種類のマイクロコントローラを対象として記述されている。低レベルプログラミング言語の性質により、権限のないアプリケーションであってもＩＣカード内の格納データにアクセスすることができる。ＩＣカード用に記述されたプログラムは特定のＩＤ識別子により識別されているので、２つの主体が同じプログラミング機能を利用を所望した場合、ＩＣカードのマイクロコントローラ上にアプリケーションの当該部分が２つコピーされてしまうことになる。ＩＣカードシステムは、ずっとクローズドシステムとして発展してきた。ＩＣカードは、特定端末のアプリケーションとともに動作するように手作りされた専用アプリケーションを含んでおり、ＩＣカードが使用されるときのセキュリティチェックは、主にカードアプリケーションと端末アプリケーションが対応するものであるかの確認およびＩＣカード上のデータが有効であるかの確認により行なっていた。ＩＣカードの利用が広まるにつれて、利用者がＩＣカードアプリケーションごとに異なるＩＣカードを持ち歩くことを敬遠することが明らかになってきた。それゆえ、単一プロバイダのＩＣカードを用いた多目的共用アプリケーションが提供され始めている。例えば、様々な端末装置を利用して［様々なタイミングでロードされうる(訳注：当該部分は第６頁末尾部分より)」。アプリケーションは、Ｊａｖａ仮想マシンにより提供されるセキュリティ機能により、如何なるアプリケーションコードやデータへの権限なきアクセスに対して保護されているので、カードのセキュリティを低下を招くことがない。スマートカードアプリケーションは、強力で主流となっているプログラム開発ツールを用いてＪａｖａやＥｉｆｆｅｌなどの高級プログラミング言語により作成される。新しいアプリケーションは、ソフトマスクを施すことなく数時間により即座にプロトタイプが作成され、スマートカードにダウンロードされる。マイクロコントローラを使用するシステムは、新しいアプリケーションのダウンロード、高レベルなプログラミング開発、即座のプロトタイプ作成について、これらの多くの優位点を得ることができる。本発明の実装には、以下のものが含まれうる。アプリケーションの高級プログラミング言語形式は、クラスファイル形式を持ち、Ｊａｖａプログラミング言語形式を持ちうる。プロセッサはマイクロコントローラで良い。少なくとも一部のメモリがプロセッサに内蔵されうる。アプリケーションは、キャラクタストリングである第２のアプリケーションから生成され、当該キャラクタストリングは第一のアプリケーションにおいて識別子（例えば、整数）により表現されている。プロセッサは、要求元(requester)（例えば、プロセッサまたは端末）からＩＣカード要素（例えば、メモリに格納されているアプリケーション、メモリに格納されたデータ、通信部）の要求を受け付けるように構成されており、要求を受けた後、要求元のＩＤ(identification)を確認するため要求元と交信し、ＩＤに応じてアクセスを許すカード要素を選定する。メモリは、各要素へのアクセス制御リストを格納している。アクセス制御リストは、当該ＩＤに許すアクセスタイプの指示情報を含み、当該アクセス制御リストに基づいて、パーソナルコンピュータスマートカード（ＰＣ／ＳＣ）標準仕様をサポートし、またＪａｖａ開発サポート環境を提供できるウィンドウＮＴオペレーティングシステムが動作する従来タイプのパーソナルコンピュータである。いくつかの実施形態において、マイクロコントローラとメモリと通信部は、典型的なクレジットカードと実質的に同じ形状を持つプラスティックカードに埋め込まれている。他の実施形態において、マイクロコントローラとメモリと通信部は、貴重品類(例えば、時計、指輪、ブレスレット)、車類、通信機器類(例えば、加入者携帯モジュール(ＳＩＭ)カード)、セキュリティデバイス類(例えば、暗号モジュール)、器具類など、プラスティックカード以外の基板上に搭載されることもある。端末装置１４は、端末装置の通信部１２ｂを用いて、ＪａｖａアプリケーションをＩＣカード１０に対して取り揃えて、ダウンロードする。端末装置の通信部１２ｂは、ＩＣカード１０と端末装置１４の間に通信チャンネルを確立することができる通信デバイスである。通信機器オプションとして、接触型カードリーダ、無線周波数帯を用いた無線通信、または赤外線通信技術、シリアル通信プロトコル、パケット通信プロトコル、ＩＳＯ７８１６通信プロトコルを用いた機器が含まれる。端末装置１４は、また、ＩＣカード１０上で動作するアプリケーションと連携動作することができる。いくつかのケースにおいて、目的に応じて異なる端末装置が用いられうる。例えば、ある種の端末装置が、アプリケーションを取り揃えるために利用され、他の端末装置が、アプリケーションをダウンロードするために利用され、また他の端末装置が多様なアプリケーションを実行するために利用される。端末装置は、現金自動処理装置(ＡＴＭ)、販売時点管理端末(ＰＯＳ端末)、入退出管理システム、有料道路料金徴収システム、アクセス管理システム、ＩＣカードやマイクロコントローラと通信可能な他のシステムでありうる。全てのアプリケーションクラスファイル２４ａ、２４ｂ、２４ｃの属性情報４４の集合のコード属性のみから生成される。カード内でのダイナミックリンキングを避けるため、アプリケーション２４からＪａｖａクラスファイル２４ａ、２４ｂ、２４ｃをまたがって配布されるすべての情報は、図５に示すフローチャートに示されたプロセスにより、１つのカードクラスファイル２７内に隠蔽されている。まず、処理される第１のクラスファイルとして選択される(５１ａ)。コンスタントプール４２は、以下の方法によりコンパクト化される(５１ｂ)。Ｊａｖａクラスファイル２４ａにおいて参照されるすべてのオブジェクト、クラス、フィールド、メソッドは、クラスファイル２４ａのコンスタントプール４２にあるストリングを利用することにより、特定される。カードクラスファイルコンバータ２６は、Ｊａｖａクラスファイル２４ａにあるコンスタントプール４２をコンパクト処理し、最適化したものとする。コンパクト処理は、クラスファイルコンスタントプール４２にある全てのストリングを整数にマッピング処理することにより達成される(当該整数の大きさはマイクロコントローラと採用アーキテクチャに依存する)。この整数が、ＩＤ識別子として参照される。各ＩＤ識別子は、アプリケーション２０の特定オブジェクト、クラス、フィールド、メソッドをユニークに特定する。このように、カードクラスファイルコンバータ２６は、Ｊａｖａクラスファイルコンスタントプール４２のストリングを、対応するユニークなＩＤ識別子に置き換える。付属ドキュメントＢは、ハロースマートカードＪａｖａ(HollowSmartCard.java)というアプリケーション例を、以下の本アプリケーションのクラスファイルのコンスタントプールに見られるストリングに対応するＩＤ識別子を説明するテーブルと共に示している。ＩＤ識別子は、本実施形態では１６ビットの符号無し整数として使用されている。次に、カードクラスファイルコンバータ２６は、入力されたＪａｖａクラスファイル２４ａのコード属性に、未サポートの部分５１Ｃがあるか否かをチェックする。カードＪＶＭ１６は、付属ドキュメントＣに示すように、Ｊａｖａバイトコード全体のうちのサブセットのみサポートしている。このため、カードクラスファイルコンバータ２６は、未サポートのバイトコードがＪａｖａクラスファイル２４ａのコード属性の中にあるか否かをチェックする。もし、未サポートのバイトコードが見つかった場合５２は、カードクラスファイルコンバータはエラーフラグを立て、変換５３を停止する。１０６．リソース制約条件セットを持ったマイクロコントローラ（１０）であって、メモリと、前記メモリにロードされ、前記リソース制約条件内で動作するインタプリタ（１６）を備え、前記マイクロコントローラ（１０）は、前記インタプリタによりインタプリタ処理するために前記メモリにロードされた少なくとも１つのアプリケーションを持ち、前記少なくとも１つのアプリケーションが以下のプログラミング環境により生成されたもの。ａ）高級言語ソースコードであるアプリケーションソースプログラミング（２０）をコンパイル形式（２４）にコンパイルするコンパイラ（２２）、ｂ）前記コンパイラ形式（２４）を前記インタプリタ（１６）によりインタプリタ処理するために最適化した最小化形式(minimized form)（２７）に後処理するコンバータ(２６)。１０７．前記コンパイル形式（２４）が、属性情報を含み、前記コンバータ（２６）が、前記インタプリタ（１６）が必要とする属性情報を含める手段と前記インタプリタ（１６）が必要としない属性情報を含めない手段を備えた請求項１０６に記載のマイクロコントローラ(１０)。１０８．前記コンパイル形式（２４）が、標準Ｊａｖａクラスファイル形式であり、前記コンバータ（２６）が、入力を前記標準Ｊａｖａクラスファイル形式の入力コンパイル形式（２４）として受け入れ、前記インタプリタ（１６）によるインタプリタ処理に適する形式の出力に変換する請求項１０６または１０７に記載のマイクロコントローラ(１０)。１０９．前記コンパイル形式（２４）が、オブジェクト、クラス、フィールド、メソッドを認証するストリングの関連情報を含み、前記コンバータは、前記ストリングをユニークなＩＤ識別子（５１ｂ）にマッピング処理する手段を含む、先行する請求項のいずれかに記載されたマイクロコントローラ(１０)。１１０．前記それぞれのユニークなＩＤ識別子が整数である請求項１０９に記載のマイクロコントローラ(１０)。１１１．前記ストリングのユニークなＩＤ識別子へのマッピングは、ストリングのＩＤ識別子マップファイル（３０、３２）への格納である請求項１０９または１１０に記載のマイクロコントローラ(１０)。１１２．前記高級言語は、特性(feature)の第１のセットとデータ型の第１のセットをサポートし、前記インタプリタ（１６）は、前記特性(feature)の第１のサブセットと前記データ型の第１のサブセットをサポートし、前記コンバータ（２６）は、前記コンパイル形式（２４）が前記特性(feature)の第１のセットのサブセットの特性(feature)のみを含んでいることおよび前記データ型の第１のセットのサブセットのデータ型のみを含んでいることをベリファイする(５１ｃ、５２)、先行するいずれかの請求項に記載されたマイクロコントローラ(１０) 。１１３．前記コンパイル形式（２４）が、バイトコード形式であり、前記コンバータ（２６）が、下記のステップを含む処理ステップのうちの少なくとも１つの処理ステップを用いて、前記コンパイル形式（２４）のバイトコードを前記インタプリタ（１６）によりインタプリタ処理するために適したバイトコードに変換する手段（５４）を備えた請求項１０９、１１０、１１１、１１２のいずれかに記載のマイクロコントローラ(１０)。ａ）オリジナルバイトコードのすべてのジャンプ処理とそのジャンプ先を記録する処理(６１)、ｂ）スペシフィックバイトコードを等価なジェネリックバイトコードに、またはその逆方向に変換する処理(６３)、ｃ）バイトコードオペランドを、ＩＤストリングを用いた参照からユニークなＩＤ識別子を用いた参照に変更する処理（６４）ｄ）コンパイル形式（２４）のバイトコードをインタプリタ処理に適した形式の等価なバイトコードにリナンバリングする処理(６６)、ｅ）ステップａ)、ｂ)、ｃ)、ｄ）の変換処理により影響を受けるジャンプ処理のジャンプ先アドレスに再リンク付けする処理（６７）１１４．前記アプリケーションプログラムが、当該コンパイル形式（２４）の実行およびインタプリタ処理のために必要とされるリソースが前記マイクロコントローラ上で利用可能なリソースを超えるコンパイル形式（２４）にコンパイルされた、先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。１１５．前記コンパイル形式（２４）が、多様なコンピュータプラットフォームへの移植性(portability)があるように規定された、先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。１１６．前記インタプリタ（１６）が、さらに、アプリケーションのインタプリタ処理中に、下記セットから選ばれた少なくとも１つの規則を含む規則セットから定められたセキュリティ基準に引っかかったか否かを決定するように構成された先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。前記アプリケーションが権限のないメモリ領域にアクセスすることを認めないか否か、前記アプリケーションがアクセス権限のないマイクロコントローラのリソースへにアクセスすることを認めないか否かであり、ここで、前記アプリケーションが、バイトコードから構成され、バイトコードの実行がセキュリティ制約条件の違反を起こさないことを確認する実行処理を少なくとも１回先行して複数のバイトコードのチェック処理をするように構成されているもの。１１７．少なくとも１つのアプリケーションプログラムが、前記アプリケーションのローディング処理に先立って、前記アプリケーションがあらゆるセキュリティ制約条件に違反しないことを確認する処理ステップと、セキュリティを維持してローディング処理を行なう処理ステップと、を含んでいるプロセスにより生成されたアプリケーションである、先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。１１８．前記セキュリティを維持してローディング処理する処理ステップが、ローディングする主体がアプリケーションをマイクロコントローラ上にロードする許可を持つことを確認する処理ステップを含む請求項１１７に記載のマイクロコントローラ(１０)。１１９．前記セキュリティを維持してローディングするステップが、ローディングキーを利用してロードされるアプリケーションを暗号化する処理ステップを含む請求項１１７または１１８に記載のマイクロコントローラ(１０)。１２０．メモリと、リソース制限のセットによって動作するプロセッサを持つマイクロコントローラをプログラミングする方法であって、前記方法が、アプリケーションプログラム（２０）を第１のプログラミング言語により入力する処理と、前記第１のプログラミング言語のアプリケーションプログラム（２０）を前記第１のプログラミング言語に対応する第１の中間コード（２４）にコンパイルする処理（２２）であって、ここで、前記第１の中間コード（２４）が、少なくとも１つの第１の中間コード仮想マシンによりインタプリタ処理できるものであり、ここで、前記マイクロコントローラをプログラミングする方法が、前記第１の中間コード（２４）を第２の中間コード（２７）に変換する処理（２６）であって、ここで、前記第２の中間コード（２７）が少なくとも１つの第２の中間コード仮想マシン（１６）によりインタプリタ処理できるもの、である処理と、前記第２の中間コードを前記マイクロコントローラ（１０）のメモリにロードする処理と、を備えたことを特徴とする方法。１２１．前記変換処理ステップがさらに、オブジェクト、クラス、フィールド、メソッドのＩＤストリングの関連付け処理と、それらストリングをユニークなＩＤ識別子（５１ｂ）にマッピングする処理と、を含む請求項１２０に記載のマイクロコントローラ（１０）をプログラミングする方法。１２２．前記マッピング処理が、ストリングを整数にマッピングする処理を含む請求項１２０または１２１に記載の方法。１２３．前記変換処理が少なくとも以下のステップのうちの１つを含む請求項１２０、１２１または１２２のいずれかに記載の方法。ａ）オリジナルバイトコードのすべてのジャンプ処理とそのジャンプ先を記録する処理(６１)、ｂ）スペシフィックバイトコードを等価なジェネリックバイトコードに、またはその逆方向に変換する処理(６３)、ｃ）バイトコードオペランドを、ＩＤストリングを用いた参照からユニークＩＤ識別子を用いた参照に変更する処理（６４）ｄ）コンパイル形式のバイトコードをインタプリタ処理に適した形式の等価なバイトコードにリナンバリングする処理(６６)、ｅ）ステップａ)、ｂ)、ｃ)、ｄ）の変換処理により影響を受けるジャンプ処理のジャンプ先アドレスに再リンク付けする処理(６７)。【図４】【手続補正書】【提出日】平成１２年２月７日（２０００．２．７）【補正内容】（１）明細書の特許請求の範囲を別紙の通り訂正します。（２）明細書５頁２７行〜１０頁２８行の「発明の開示………図面の簡単な説明」を以下のように訂正します。「発明の開示一面において、本発明は、マイクロコントローラ、例えば、ＩＣカードやスマートカードを開示する。説明の便宜上、この発明の開示の欄に続く詳細な説明の欄において、本発明を端末と共に用いられるＩＣカードのアプリケーション例として記述した。しかしながら、本発明は他のスモールコンピュータプロセッサに関するアプリケーションに適用できるものである。例えば、マイクロコントローラを埋め込んだシステムなどである。本発明のマイクロコンローラのマイクロプロセッサは、インタプリタを格納するメモリと、高級プログラミング言語形式を持っている少なくとも一つのアプリケーションとを含んでいる。メモリの少なくとも一部分はマイクロプロセッサ内に設けられている。マイクロプロセッサは、アプリケーションをインタプリタ処理するためのインタプリタを利用するように構成されている。本発明の優位点として、以下のものが含まれている。本発明によれば、スマートカードやマイクロコントローラのセキュリティ低下を招くことなくスマートカードやマイクロコントローラを持つ他のシステムへの新しいアプリケーションのダウンロードが可能となる。これらアプリケーションは、様々な会社により提供され、様々な端末装置を利用して様々なタイミングでロードされうる。アプリケーションは、Ｊａｖａ仮想マシンにより提供されるセキュリティ機能により、如何なるアプリケーションコードやデータへの権限なきアクセスに対して保護されているので、カードのセキュリティは構成されない。アプリケーションは、強力で主流となっているプログラム開発ツールを用いてＪａｖａやＥｉｆｆｅｌなどの高級プログラミング言語により作成される。新しいアプリケーションは、ソフトマスクを施すことなく数時間により即座にプロトタイプが作成され、スマートカードにダウンロードされる。マイクロコントローラが埋め込まれたシステムは、新しいアプリケーションのダウンロード、高レベルなプログラミング開発、迅速なプロトタイプ作成に関して、これらの多くの優位点を得ることができる。マイクロコントローラにおいてＪａｖａやＥｉｆｆｅｌなど高級言語を用いる際の困難性は、インタプリタやこれら言語により作成されたコンパイル形式のアプリケーションプログラム双方がメモリを大容量に必要とすることによる。本発明は、この困難性を、処理の一環としてコンバータをアプリケーションプログラムに導入することにより解決している。本発明の実装には、以下のものが含まれうる。アプリケーションの高級プログラミング言語形式は、クラスファイル形式を持ち、Ｊａｖａプログラミング言語形式を持ちうる。アプリケーションはＪａｖａバイトコードなどのバイトコードを含む。本発明を適用したシステムは、高級プログラミング言語で記述されたアプリケーションソースプログラムをコンパイル形式にコンパイルするためのコンパイラを含んでいる。本発明は、さらに、コンパイル形式からインタプリタによるインタプリタ処理に適した形式に変換するコンバータを含んでいる。一面において、本発明において、コンバータは、インタプリタが要求したアプリケーションプログラム属性を含ませ、インタプリタが要求しない属性を含ませないように動作することができる。コンバータは、さらに、標準高級言語形式におけるコンパイル形式を入力データとして受け付けることができ、インタプリタによるインタプリタ処理に適した形式の出力データを生成することができる。一面において、コンバータは、ＩＤストリングをユニークなＩＤ識別子に、例えば整数に、マッピングする手段を含んでいる。このマッピング処理は、ストリング −ＩＤマップファイルに記録されうる。本発明のインタプリタは、さらに、高級言語の特徴とデータタイプのフルセットのうちのサブセットをサポートするように制限することができる。この場合、コンバータはさらに、アプリケーションプログラムのコンパイル形式がそれらサポートされている特徴とデータタイプのみ含むように確認する。一つの実施形態として、コンバータは、次の処理、つまり、ジャンプと行き先を記録する処理、特殊バイトコードをジェネリックバイトコードに変換する処理またはその逆の処理、ＩＤストリングの代わりにユニークなＩＤ識別子を用いるためのリファレンスからバイトコードのオペランドを変更する処理、バイトコードを等価なバイトコードへリナンバリングする処理、それら変換ステップにより影響をうけるディスティネーションアドレスへのジャンプを再リンキングする処理のうち、少なくとも一つの処理ステップを用いて、コンパイル形式のバイトコードをマイクロコントローラのインタプリタによるインタプリタ処理に適した形式のバイトコードに変換する手段を含んでいる。インタプリタは、セキュリティチェックを実装した構成とすることができる。セキュリティチェックは、ファイヤウォールの構築処理を含み、サンドボックスセキュリティモデルの構築処理を含みうる。例えば、インタプリタは、アプリケーションが、メモリのアクセス権限のない領域へのアクセスを許さない処理、アクセス権限のないマイクロプロセッサのリソースへのアクセスを許可しない処理、バイトコードの実行がセキュリティ制限に違反しないものかをチェックする処理などを含む処理セットから選ばれたセキュリティ基準を満たしているものであるか否かを決定できる。本発明の一つの実施形態において、アプリケーションのロードに先立ち、アプリケーションがどのセキュリティ制限にも違反していないかを確認し、セキュリティ基準に従ってアプリケーションをロードする処理を含むことができる。後者のステップの例は、ロードしたＩＤが、当該アプリケーションをマイクロプロセッサ上にロードする許可を持っているかを確認し、ロードしたキーを用いてロードされるアプリケーションを暗号化する処理を含んでいる。他の一面において、本発明は、マイクロコントローラをプログラミングする方法を開示しており、第１のプログラミング言語で記述されたアプリケーションを、コンパイラによって生成され第１のバーチャルマシンによってインタプリタ処理されるように意図された第１の中間コードから、第２のバーチャルマシンによってインタプリタ処理可能な第２の中間コードに変換し、第２の中間コードをマイクロコントローラのメモリ上にロードする処理ステップを備えている。本発明の方法によれば、変換処理は、さらに、ＩＤストリングをオブジェクト、クラス、フィールド、メソッドに関連付け、それらストリングをユニークなＩＤ識別子、例えば整数にマッピングする処理を含んでいる。一つの実施形態において、本発明の方法は、次の処理、つまり、ジャンプと行き先を記録する処理、特殊バイトコードをジェネリックバイトコードに変換する処理またはその逆の処理、ＩＤストリングの代わりにユニークなＩＤ識別子を用いるためのリファレンスからバイトコードのオペランドを変更する処理、バイトコードを等価なバイトコードへリナンバリングする処理、それら変換ステップにより影響をうけるディスティネーションアドレスへのジャンプを再リンキングする処理のうち、少なくとも一つの処理ステップを含んでいる。本発明の他の一面において、本発明のマイクロコントローラは、インタプリタ可能なプログラミング言語で記述されたプログラムのインタプリタ処理を許容するには不十分な容量しかないメモリという制限のあるリソースセットで稼動するものである。メモリは、高級プログラム言語から派生したプログラムをインタプリタ処理するインタプリタと、ＩＤ識別子にストリングをマッピングする処理、インタプリタ処理に先立ちまたはインタプリタ処理中にセキュリティチェックを実行する処理、インタプリタ処理に先立ちまたはインタプリタ処理中に構造チェックを実行する処理、インタプリタ処理に先立ちまたはインタプリタ処理中にセマンティックチェックを実行する処理を含む規則セットから選ばれた少なくとも一つの規則を適用することにより派生した派生プログラムとを含んでいる。これらセキュリティチェックは、複数の派生プログラムの一つにアクセスする者からリクエストを受け取るためのロジックを持っている。リクエストの受領により、派生プログラムが所定のルールセットでコンパイルされているか否か決定され、この決定に従って、派生プログラムにアクセスする者を選択的に許可する。派生プログラムがアクセスしようとするメモリの特別領域へのアクセス権限を派生プログラムが持っているか否かを決定することにより、当該派生プログラムがインタプリタ処理される間にインタプリタによって当該所定ルールが用いられる。マイクロコントローラは、さらに、派生プログラムがインタプリタ処理される間、用いられているセキュリティルールから選ばれた少なくとも一つのセキュリティチェックを実行するように構成されており、インタプリタは、バイトコードが実行前チェックおよび実行後チェックに応じて実行されるか否かを決定するための処理に先立って少なくとも一度、各バイトコードをチェックするように構成されており、派生プログラムは、マイクロコントローラにロードされる処理に先立って少なくとも一度、セキュリティプロトコルに応じて派生プログラムの統合とロードが実行されたことを確認するチェックが実行される。セキュリティプロトコルは、派生プログラムのカード上へのロードが許可されるように特別のＩＤが有効化されていなければならないことを要求する。セキュリティプロトコルはさらに復号キーを含み、ロードされる派生プログラムが復号キーに応じがローディングキーを用いて暗号化されていることを要求する。マイクロコントローラは、さらに、暗号化処理、復号化処理、署名処理、署名認証処理、相互認証処理、鍵配送処理、鍵セッション処理のセットから選ばれた暗号関連サービスを提供するように構成されている。マイクロコントローラは、ファイルシステムを備えており、ファイルを読み取る権限、ファイルに書き込む権限、ファイルを消去する権限に対するアクセスコントロールリストを持つマイクロコントローラによる当該ファイルシステムへの安全なアクセス手段を提供するように構成されている。さらに、マイクロコントローラは、ファイルへのアクセス権限を確立するため、または、カード保有者がファイルにアクセスする権限を得る認証を確認するための鍵有効化を実行する。他の優位点および特徴は、以下の説明と特許請求の範囲の記載により明らかにされている。図面の簡単な説明」（３）図面の第１６図を別紙の通り訂正します（４）図面の第１８図を別紙の通り訂正します別紙特許請求の範囲１０６．リソース制約条件セットを持ったマイクロコントローラ（１０）であって、メモリと、前記メモリにロードされ、前記リソース制約条件内で動作するインタプリタ( １６)を備え、前記マイクロコントローラ（１０）は、前記インタプリタによりインタプリタ処理するために前記メモリにロードされた少なくとも１つのアプリケーションを持ち、前記少なくとも１つのアプリケーションが以下のプログラミング環境により生成されたもの。ａ）高級言語ソースコードであるアプリケーションソースプログラミング（２０）をコンパイル形式（２４）にコンパイルするコンパイラ(２２)、ｂ）前記コンパイラ形式（２４）を前記インタプリタ（１６）によりインタプリタ処理するために最適化した最小化形式(minimized form)（２７）に後処理するコンバータ(２６)。１０７．前記コンパイル形式（２４）が、属性情報を含み、前記コンバータ（２６）が、前記インタプリタ（１６）が必要とする属性情報を含める手段と前記インタプリタ（１６）が必要としない属性情報を含めない手段を備えた請求項１０６に記載のマイクロコントローラ(１０)。１０８．前記コンパイル形式（２４）が、標準Ｊａｖａクラスファイル形式であり、前記コンバータ（２６）が、入力を前記標準Ｊａｖａクラスファイル形式の入力コンパイル形式（２４）として受け入れ、前記インタプリタ（１６）によるインタプリタ処理に適する形式の出力（２７）に変換する請求項１０６または１０７に記載のマイクロコントローラ(１０)。１０９．前記コンパイル形式（２４）が、オブジェクト、クラス、フィールド、メソッドを認証するストリングの関連情報を含み、前記コンバータは、前記ストリングをユニークなＩＤ識別子（５１ｂ）にマッピング処理する手段を含む、先行する請求項のいずれかに記載されたマイクロコントローラ(１０)。１１０．前記それぞれのユニークなＩＤ識別子が整数である請求項１０９に記載のマイクロコントローラ(１０)。１１１．前記ストリングのユニークなＩＤ識別子へのマッピングは、ストリングのＩＤ識別子マップファイル（３０、３２）への格納である請求項１０９または１１０に記載のマイクロコントローラ(１０)。１１２．前記高級言語は、特性(feature)の第１のセットとデータ型の第１のセットをサポートし、前記インタプリタ（１６）は、前記特性(feature)の第１のサブセットと前記データ型の第１のサブセットをサポートし、前記コンバータ（２６）は、前記コンパイル形式（２４）が前記特性(feature)の第１のセットのサブセットの特性(feature)のみを含んでいることおよび前記データ型の第１のセットのサブセットのデータ型のみを含んでいることをベリファイする(５１ｃ、５２)、先行するいずれかの請求項に記載されたマイクロコントローラ(１０) 。１１３．前記コンパイル形式（２４）が、バイトコード形式であり、前記コンバータ（２６）が、下記のステップを含む処理ステップのうちの少なくとも１つの処理ステップを用いて、前記コンパイル形式（２４）のバイトコードを前記インタプリタ（１６）によりインタプリタ処理するために適したバイトコード（２７）に変換する手段（５４）を備えた請求項１０９、１１０、１１１、１１２のいずれかに記載のマイクロコントローラ(１０)。ａ）オリジナルバイトコードのすべてのジャンプ処理とそのジャンプ先を記録する処理(６１)、ｂ）スペシフィックバイトコードを等価なジェネリックバイトコードに、またはその逆方向に変換する処理(６３)、ｃ）バイトコードオペランドを、ＩＤストリングを用いた参照からユニークなＩＤ識別子を用いた参照に変更する処理（６４）ｄ）コンパイル形式（２４）のバイトコードをインタプリタ処理に適した形式の等価なバイトコードにリナンバリングする処理(６６)、ｅ）ステップａ)、ｂ)、ｃ)、ｄ）の変換処理により影響を受けるジャンプ処理のジャンプ先アドレスに再リンク付けする処理（６７）１１４．前記アプリケーションプログラムが、当該コンパイル形式（２４）の実行およびインタプリタ処理のために必要とされるリソースが前記マイクロコントローラ上で利用可能なリソースを超えるコンパイル形式（２４）にコンパイルされた、先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。１１５．前記コンパイル形式（２４）が、多様なコンピュータプラットフォームへの移植性(portability)があるように規定された、先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。１１６．前記インタプリタ（１６）が、さらに、アプリケーションのインタプリタ処理中に、下記セットから選ばれた少なくとも１つの規則を含む規則セットから定められたセキュリティ基準に引っかかったか否かを決定するように構成された先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。前記アプリケーションが権限のないメモリ領域にアクセスすることを認めないか否か、前記アプリケーションがアクセス権限のないマイクロコントローラのリソースへにアクセスすることを認めないか否かであり、ここで、前記アプリケーションが、バイトコードから構成され、バイトコードの実行がセキュリティ制約条件の違反を起こさないことを確認する実行処理を少なくとも１回先行して複数のバイトコードのチェック処理をするように構成されているもの。１１７．少なくとも１つのアプリケーションプログラムが、前記アプリケーションのローディング処理に先立って、前記アプリケーションがあらゆるセキュリティ制約条件に違反しないことを確認する処理ステップと、セキュリティを維持してローディング処理を行なう処理ステップと、を含んでいるプロセスにより生成されたアプリケーションである、先行するいずれかの請求項に記載されたマイクロコントローラ(１０)。１１８．前記セキュリティを維持してローディング処理する処理ステップが、ローディングする主体がアプリケーションをマイクロコントローラ上にロードする許可を持つことを確認する処理ステップを含む請求項１１７に記載のマイクロコントローラ(１０)。１１９．前記セキュリティを維持してローディングするステップが、ローディングキーを利用してロードされるアプリケーションを暗号化する処理ステップを含む請求項１１７または１１８に記載のマイクロコントローラ(１０)。１２０．メモリと、リソース制限のセットによって動作するプロセッサを持つマイクロコントローラをプログラミングする方法であって、前記方法が、アプリケーションプログラム（２０）を第１のプログラミング言語により入力する処理と、前記第１のプログラミング言語のアプリケーションプログラム（２０）を前記第１のプログラミング言語に対応する第１の中間コード（２４）にコンパイルする処理（２２）であって、ここで、前記第１の中間コード（２４）が、少なくとも１つの第１の中間コード仮想マシンによりインタプリタ処理できるものであり、ここで、前記マイクロコントローラをプログラミングする方法が、前記第１の中間コード（２４）を第２の中間コード（２７）に変換する処理（２６）であって、ここで、前記第２の中間コード（２７）が少なくとも１つの第２の中間コード仮想マシン（１６）によりインタプリタ処理できるもの、である処理と、前記第２の中間コードを前記マイクロコントローラ（１０）のメモリにロードする処理と、を備えたことを特徴とする方法。１２１．前記変換処理ステップがさらに、オブジェクト、クラス、フィールド、メソッドのＩＤストリングの関連付け処理と、それらストリングをユニークなＩＤ識別子（５１ｂ）にマッピングする処理と、を含む請求項１２０に記載のマイクロコントローラ（１０）をプログラミングする方法。１２２．前記マッピング処理が、ストリングを整数にマッピングする処理を含む請求項１２０または１２１に記載の方法。１２３．前記変換処理が少なくとも以下のステップのうちの１つを含む請求項１２０、１２１または１２２のいずれかに記載の方法。ａ）オリジナルバイトコードのすべてのジャンプ処理とそのジャンプ先を記録する処理(６１)、ｂ）スペシフィックバイトコードを等価なジェネリックバイトコードに、またはその逆方向に変換する処理(６３)、ｃ）バイトコードオペランドを、ＩＤストリングを用いた参照からユニークＩＤ識別子を用いた参照に変更する処理（６４）ｄ）コンパイル形式のバイトコードをインタプリタ処理に適した形式の等価なバイトコードにリナンバリングする処理(６６)、ｅ）ステップａ)、ｂ)、ｃ)、ｄ）の変換処理により影響を受けるジャンプ処理のジャンプ先アドレスに再リンク付けする処理(６７)。１２４．前記第２の中間コード（２７）を前記マイクロコントローラ（１０）のメモリにロードする処理を備えたことを特徴とする方法が、さらに、前記第２の中間コード（２７）のロード処理に先立って、前記第２の中間コード（２７）があらかじめ定義したチェック内容を満たすものであるかおよび当該ロード処理がセキュリティプロトコルに従って実行されるものであるかを認証するため前記第２の中間コード（２７）をチェックする処理を含む請求項１２０〜１２３のいずれか１項に記載の方法。１２５．前記セキュリティプロトコルが、前記第２の中間コード（２７）のロード処理に先立ち、特定のＩＤ識別主体がロード処理を許可するために有効化されていることを要求する請求項１２０〜１２４のいずれか１項に記載の方法。１２６．さらに復号鍵の供給処理を含み、前記セキュリティプロトコルが、ロードされた前記復号鍵に対応する鍵を使って前記第２の中間コード（２７）が暗号化されていることを要求する請求項１２０〜１２５のいずれか１項に記載の方法。１２７．メモリと前記メモリにロードされたインタプリタ（１６）を備え、インタプリタ処理可能なプログラミング言語により記述されたプログラム（２４）から派生した派生プログラム（２７）を実行しうるマイクロコントローラ（１０）であって、前記マイクロコントローラ（１０）が以下の特徴を持つもの。（ａ）前記マイクロコントローラは、メモリがインタプリタ処理できるプログラミング言語で記述されたプログラム（２４）のインタプリタ処理するためには不十分な容量である場合を含む、リソース制約条件セット内で動作するものである（ｂ）前記メモリが、インタプリタ処理可能な言語の派生により記述された派生プログラム（２７）をインタプリタ処理できるインタプリタを含むメモリであって、インタプリタ処理可能なプログラミング言語により記述された派生プログラム（２７）が、下記の規則を含む規則セットから選ばれた少なくとも１つの規則を適用してインタプリタ処理可能なプログラミング言語により記述されたプログラム（２４）から派生したもの。（１）ストリングを識別子にマッピングすること（２）インタプリタ処理に先立ってまたはインタプリタ処理中にセキュリティチェック処理を実行すること（３）インタプリタ処理に先立ってまたはインタプリタ処理中に構造チェックを実行すること（４）インタプリタ処理に先立ってまたはインタプリタ処理中にセマンティックチェックを実行すること１２８．前記派生プログラム（２７）がクラスファイルまたはクラスファイルの派生である請求項１２７に記載のマイクロコントローラ(１０)。１２９．前記メモリが１メガバイトより少ないことを特徴とする請求項１２７または１２８に記載のマイクロコントローラ(１０)。１３０．前記マイクロコントローラのセキュリティチェックが、さらに以下の特徴を持つ請求項１２７〜１２９のいずれか１項に記載のマイクロコントローラ（１０）（ｃ）要求元から複数の派生プログラム（２７）のうちの１つに対するアクセス要求を受け取るロジックを持つこと（ｄ）前記要求を受け取った後、複数の派生プログラム（２７）のうちの１つがあらかじめ決められた規則セットと適合するか否かを決定すること（ｅ）前記決定に基づいて、前記要求元に対して、複数のアプリケーションのうちの１つに対するアクセスを選択的に認めること１３１．前記派生プログラム（２７）がアクセスしようとするメモリの特定領域へのアクセス権限を前記派生プログラム（２７）が持っているか否かを決定することにより前記派生プログラム（２７）がインタプリタ処理される間に前記あらかじめ決められた規則が前記インタプリタ（１６）によって実行される請求項１３０に記載のマイクロコントローラ(１０)。１３２．さらに前記マイクロコントローラ（１０）が下記のものを含むセットから選ばれた少なくとも１つのセキュリティチェックを実行するように構成された請求項１２７〜１３１のいずれか１項に記載のマイクロコントローラ（１０）（ａ）前記派生プログラム（２７）がインタプリタ処理されている間にあらかじめ決められたセキュリティ規則を実行し、前記派生プログラム（２７）が権限の無いメモリ領域または他の権限の無いマイクロコントローラリソースにアクセスすることを防止すること（ｂ）各バイトコードが前処理チェックおよび後処理チェックに従って実行されているか決定する処理に先立って少なくとも１回各バイトコードがチェックされるように前記インタプリタ（１６）が構成されていること（ｃ）前記派生プログラム（２７）の統合を確認するために前記マイクロコントローラにロードされる前に前記派生プログラムの完全性がチェックされ、ロード処理がセキュリティプロトコルに応じて実行されること１３３．前記セキュリティプロトコルは、派生プログラム（２７）をカード上にロードできるように特定のＩＤ識別主体が有効化されていることを要求する請求項１３２に記載のマイクロコントローラ(１０)。１３４．前記セキュリティプロトコルは、復号鍵を持っており、ロードされた派生プログラム（２７）が前記復号鍵に対応する鍵により暗号化されていることを要求することを特徴とする請求項１３２に記載のマイクロコントローラ(１０)。１３５．暗号処理、復号処理、署名処理、署名照合処理、相互認証、鍵配送および鍵セッション処理を含む処理セットから選ばれた暗号サービスが供給できるように構成されたことを特徴とする請求項１２７〜１３４のいずれか１項に記載のマイクロコントローラ(１０)。１３６．ファイルシステムを持ち、下記のものを含む処理セットから選ばれた手段を介して前記ファイルシステムへアクセスできるように構成された請求項１２７〜１３５のいずれか１項に記載のマイクロコントローラ（１０）（ａ）前記マイクロコントローラが、ファイルからの読み出し処理、ファイルへの書き込み処理またはファイルの消去処理の権限に対するアクセス制御リストを備えていること（ｂ）前記マイクロコントローラが、ファイルへのアクセス権限を確立するための鍵有効化が実行できること（ｃ）前記マイクロコントローラが、ファイルへのアクセス権限を確立するためのカード保有者主体を認証できること【図１６】【図１８】

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者クシーラブディクリシュナアメリカ合衆国、テキサス州78613、セダーパーク、リトルエルムトレイル2831 (72)発明者マイケルエイ．モントゴメリーアメリカ合衆国、テキサス州78613、セダーパーク、ネルソンランチロード906

Claims

【特許請求の範囲】１．端末装置に利用するＩＣカードであって、端末装置と通信する通信部と、高級プログラミング言語形式を持つアプリケーションと、インタプリタを格納したメモリ部と、前記メモリと結合したプロセッサであって、実行するアプリケーションをインタプリタ処理するために前記インタプリタを利用し、端末装置と通信するために通信部を利用するように構成されたものを備えたことを特徴とするＩＣカード。２．前記高級プログラミング言語形式が、クラスファイル形式を備えた請求項１に記載のＩＣカード。３．前記プロセッサがマイクロコントローラを備えた請求項１に記載のＩＣカード。４．少なくともメモリの一部が前記プロセッサ内に形成された請求項１に記載のＩＣカード。５．前記高級プログラミング言語形式が、Ｊａｖａプログラミング言語形式を備えた請求項１に記載のＩＣカード。６．前記アプリケーションが、キャラクタストリングを持つ第２のアプリケーションから生成され、第１のアプリケーションにおいて前記キャラクタストリングがＩＤ識別子(identifier)により表現されている請求項１に記載のＩＣカード。７．前記ＩＤ識別子が整数列を含む請求項６に記載のＩＣカード。８．前記プロセッサがさらに、前記カード要素に対してアクセスする要求を要求元から受け付け、前記要求を受け付けた後、前記要求元のＩＤ(identity)を認証するため前記要求元と対話型処理を行ない、前記ＩＤに基づいてアクセスする要素を選択的に許可するように構成された請求項１に記載のＩＣカード。９．前記要求元が、プロセッサを備えた請求項８に記載のＩＣカード。１０．前記要求元が、前記端末装置を備えた請求項８に記載のＩＣカード。１１．前記要素が、前記メモリに格納されたアプリケーションを含み、アクセスが許可されると前記要求元が前記アプリケーションを利用することができるように構成されている請求項８に記載のＩＣカード。１２．前記要素が、前記メモリに格納された他のアプリケーションを備えた請求項８に記載のＩＣカード。１３．前記要素が、前記メモリに格納されたデータを含む請求項８に記載のＩＣカード。１４．前記要素が、前記通信部を備えた請求項８に記載のＩＣカード。１５．前記メモリが、前記要素のためのアクセス制御リストを格納し、前記アクセス制御リストは、前記ＩＤに許可されるアクセスの型の表示を含み、前記プロセッサは、前記アクセス制御リストをベースとして、前記要求元へのアクセスの特定の型を選択的に許可するように構成されている請求項８に記載のＩＣカード。１６．前記アクセスの型が、データ読み出し型を含む請求項１５に記載のＩＣカード。１７．前記アクセスの型が、データ書き込み型を含む請求項１５に記載のＩＣカード。１８．前記アクセスの型が、データ付加型を含む請求項１５に記載のＩＣカード。１９．前記アクセスの型が、データ生成型を含む請求項１５に記載のＩＣカード。２０．前記アクセスの型が、データ消去型を含む請求項１５に記載のＩＣカード。２１．前記アクセスの型が、アプリケーション実行型を含む請求項１５に記載のＩＣカード。２２．前記アプリケーションが、前記メモリに格納された複数のアプリケーションのうちの１つであり、前記プロセッサが、前記複数のアプリケーションの１つに対するアクセス要求を受け付け、前記要求の受け付け後、前記複数のアプリケーションのうちの１つを所定の規則セットによりコンパイルするか否かを決定し、前記決定にしたがって、前記要求元に対して前記複数のアプリケーションのうちの１つへのアクセス要求を選択的に許可する請求項１に記載のＩＣカード。２３．前記所定の規則が、前記複数のアプリケーションのうちの１つが前記メモリの所定の領域にアクセスできるか否かを決定するガイドを提供する請求項２２に記載のＩＣカード。２４．前記プロセッサがさらに、要求元のＩＤを認証し、前記ＩＤに基づいて前記複数のアプリケーションのうちの１つへのアクセスを許可するように構成された請求項２２に記載のＩＣカード。２５．前記プロセッサがさらに、ＩＤを認証するために前記通信部を介して前記端末装置と対話型処理を行ない、前記ＩＤが認証されたか否かを決定し、前記決定に基づいて前記端末装置と前記ＩＣカード間の通信を選択的に許可する請求項１に記載のＩＣカード。２６．前記通信部と前記端末装置が通信チャンネルを介して通信し、前記プロセッサがさらに、前記プロセッサが前記端末装置と前記ＩＣカード間の通信を許可するときに、前記ＩＤに前記通信チャンネルの１つを割り当てるように構成された請求項２５に記載のＩＣカード。２７．前記プロセッサがさらに、前記通信チャンネルの１つにセッションキーを割り当て、前記通信チャンネルの１つを介して前記プロセッサと前記端末装置が通信する場合に、前記セッションキーを利用する請求項２６に記載のＩＣカード。２８．前記端末装置が、カードリーダを備え、前記通信部が前記カードリーダと通信するための接点(contact)を備えた請求項１に記載のＩＣカード。２９．前記端末装置が、無線通信デバイスを備え、前記通信部が、前記無線通信デバイスと通信するための無線受信部を備えた請求項１に記載のＩＣカード。３０．前記端末装置が、無線通信デバイスを備え、前記通信部が、前記無線通信デバイスと通信するための無線送信部を備えた請求項１に記載のＩＣカード。３１．ＩＣカードと端末装置において使われる方法であって、インタプリタと高級プログラミング言語形式を備えたアプリケーションを前記ＩＣカードのメモリに格納する処理と、実行する前記アプリケーションをインタプリタ処理する前記インタプリタを使用するために前記プロセッサを使用する処理と、前記プロセッサと前記端末装置と通信する場合に前記カードの通信部を使用する処理を備えたことを特徴とする方法。３２．前記高級プログラミング言語形式が、クラスファイル形式を備えている請求項３１に記載の方法。３３．前記プロセッサが、マイクロコントローラを備えている請求項３１に記載の方法。３４．少なくとも前記メモリの一部が前記プロセッサに設けられている請求項３１に記載の方法。３５．前記高級プログラミング言語形式が、Ｊａｖａプログラミング言語形式を備えている請求項３１に記載の方法。３６．前記アプリケーションが、キャラクタストリングを持つ第２のアプリケーションから生成され、第１のアプリケーションにおいて前記キャラクタストリングがＩＤ識別子により表現されている請求項３１に記載の方法。３７．前記ＩＤ識別子が、整数列を含んでいる請求項３６に記載の方法。３８．前記方法がさらに、前記カード要素に対してアクセスする要求を要求元から受け付ける処理と、前記要求を受け付けた後、前記要求元のＩＤを認証するため前記要求元と対話型処理を行なう処理と、前記ＩＤに基づいてアクセスする要素を選択的に許可する処理を含む請求項３１に記載の方法。３９．前記要求元が、プロセッサを備えた請求項３８に記載の方法。４０．前記要求元が、端末装置を備えた請求項３８に記載の方法。４１．前記要素が、前記メモリに格納されたアプリケーションを備え、さらに、アクセスが許可されると前記要求元が前記アプリケーションを利用する処理を含む請求項３８に記載の方法。４２．前記要素が、前記メモリに格納された他のアプリケーションを備えた請求項３８に記載の方法。４３．前記要素が、前記メモリに格納されたデータを含む請求項３８に記載の方法。４４．前記要素が、前記通信部を備えた請求項３８に記載の方法。４５．前記メモリが、前記要素のためのアクセス制御リストを格納し、前記アクセス制御リストは、前記ＩＤに許可されるアクセスの型の表示を含み、さらに、前記アクセス制御リストをベースとし、前記要求元へのアクセスの特定の型を選択的に許可するプロセッサを利用する処理を備えた請求項３８に記載の方法。４６．前記アクセスの型が、データ読み出し型を含む請求項４５に記載のＩＣカード。４７．前記アクセスの型が、データ書き込み型を含む請求項４５に記載のＩＣカード。４８．前記アクセスの型が、データ付加型を含む請求項４５に記載のＩＣカード。４９．前記アクセスの型が、データ生成型を含む請求項４５に記載のＩＣカード。５０．前記アクセスの型が、データ消去型を含む請求項４５に記載のＩＣカード。５１．前記アクセスの型が、アプリケーション実行型を含む請求項４５に記載のＩＣカード。５２．前記アプリケーションが前記メモリに格納された複数のアプリケーションのうちの１つであり、さらに、前記要求の受け付けに基づいて前記メモリに格納されている複数のアプリケーションのうちの１つにアクセスする要求を要求元から受け付ける処理と、前記複数のアプリケーションのうちの１つを所定の規則セットに基づいてコンパイルするか否かを決める処理と、前記決定に基づいて前記複数のアプリケーションのうちの１つにアクセスを選択的に許可する処理を備えた請求項３１に記載の方法。５３．前記所定の規則は、前記複数のアプリケーションのうちの１つのアプリケーションが前記メモリの所定の領域をアクセスできるか否かを決定するガイドを提供するものである請求項５２に記載の方法。５４．さらに、要求元のＩＤを認証する処理と、前記ＩＤに基づいて前記複数のアプリケーションのうちの１つへのアクセスを許可する処理を備えた請求項５２に記載の方法。５５．さらに、ＩＤを認証するため前記端末装置と通信する処理と、ＩＤが認証されたかを決定する処理と、前記決定処理にしたがって前記端末装置と前記ＩＣカードとの間の通信を選択的に許可する処理を備えた請求項３１に記載の方法。５６．さらに、通信チャンネルを介して前記端末装置と前記プロセッサ間で通信する処理と、前記許可処理が前記カードリーダと前記ＩＣカードとの間の通信を許可したときに、前記ＩＤへの通信チャンネルの１つを割り当てる手段を備えた請求項５５に記載の方法。５７．さらに、前記通信チャンネルの１つに対してセッションキーを割り当てる処理と、前記プロセッサと前記端末装置が前記通信チャンネルの１つを介して通信するときに、前記セッションキーを利用する処理を備えた請求項５６に記載の方法。５８．スマートカードであって、Ｊａｖａインタプリタを格納したメモリと、Ｊａｖａアプリケーションをインタプリタ処理するために前記インタプリタを利用するように構成されたプロセッサを備えたスマートカード。５９．マイクロコントローラであって、半導体基板と、前記半導体基板に配置されたメモリと、前記メモリに格納されセキュリティチェック処理を実装するように構成されたプログラミング言語インタプリタと、前記基板に配置され前記メモリに結合された中央演算処理装置を備えたことを特徴とするマイクロコントローラ。６０．前記インタプリタが、Ｊａｖａバイトコードインタプリタを備えた請求項５９に記載のマイクロコントローラ。６１．前記セキュリティチェック処理が、ファイアウォール構築処理を備えた請求項５９に記載のマイクロコントローラ。６２．前記セキュリティチェック処理が、サンドボックスセキュリティモデルの実施処理を備えた請求項５９に記載のマイクロコントローラ。６３．スマートカードであって、メモリと、前記メモリに格納されセキュリティチェック処理を実行するように構成されたプログラミング言語インタプリタと、前記メモリに結合された中央演算処理装置を備えたことを特徴とするスマートカード。６４．前記インタプリタが、Ｊａｖａバイトコードインタプリタを備えた請求項６３に記載のスマートカード。６５．前記セキュリティチェック処理が、ファイアウォール構築処理を備えた請求項６３に記載のスマートカード。６６．前記セキュリティチェック処理が、サンドボックスセキュリティモデルの実施処理を備えた請求項６３に記載のスマートカード。６７．端末装置を利用するＩＣカードであって、通信部と、インタプリタと第１のアプリケーションの第１のインストラクションを格納するメモリであって、前記第１のインストラクションは、第２のアプリケーションの第２のインストラクションから変換されたものと、前記メモリに結合され、前記第１のインストラクションを実行し、前記通信部を介して前記端末装置と通信するためのインタプリタを利用するように構成されたプロセッサを備えたことを特徴とするＩＣカード。６８．前記第１のアプリケーションが、クラスファイル形式を持つ請求項６７に記載のＩＣカード。６９．前記第２のアプリケーションが、クラスファイル形式を持つ請求項６７に記載のＩＣカード。７０．前記第１のインストラクションが、バイトコードを備えた請求項６７に記載のＩＣカード。７１．前記第２のインストラクションが、バイトコードを備えた請求項６７に記載のＩＣカード。７２．前記第１のインストラクションが、Ｊａｖａバイトコードを備えた請求項６７に記載のＩＣカード。７３．前記第２のインストラクションが、Ｊａｖａバイトコードを備えた請求項６７に記載のＩＣカード。７４．前記第１のインストラクションが、第２のインストラクションから生成されたものである請求項６７に記載のＩＣカード。７５．前記第１のインストラクションが、第２のインストラクションからリナンバリングされたものである請求項６７に記載のＩＣカード。７６．前記第２のインストラクションが、定数参照を含み、前記第１のインストラクションが、前記第２のインストラクションの定数参照と置き換える定数を含む請求項６７に記載のＩＣカード。７７．前記第２のインストラクションが、参照を含み、前記参照が、前記第２のインストラクションから前記第１のインストラクションへの変換処理中、格納位置をシフトし、前記第１のインストラクションが前記シフト後の参照と再びリンク付けられる請求項６７に記載のＩＣカード。７８．前記第１のインストラクションが、仮想マシンの第１の型のバイトコードを備え、前記第２のインストラクションが、仮想マシンの第２の型のバイトコードを備え、前記第１の型が前記第２の型とは異なるものである請求項６７に記載のＩＣカード。７９．ＩＣカードを使用する方法であって、第２のアプリケーションの第２のインストラクションを第１のアプリケーションの第１のインストラクションへ変換する処理と、ＩＣカードのメモリに前記第１のインストラクションを格納する処理と、前記第１のインストラクションを実行するため前記ＩＣカードのインタプリタを使用する処理を備えたことを特徴とする方法。８０．前記第１のアプリケーションが、クラスファイル形式を持つ請求項７９に記載の方法。８１．前記第２のアプリケーションが、クラスファイル形式を持つ請求項７９に記載の方法。８２．前記第１のインストラクションが、バイトコードを備えた請求項７９に記載の方法。８３．前記第２のインストラクションが、バイトコードを備えた請求項７９に記載の方法。８４．前記第１のインストラクションが、Ｊａｖａバイトコードを備えた請求項７９に記載の方法。８５．前記第２のインストラクションが、Ｊａｖａバイトコードを備えた請求項７９に記載の方法。８６．前記第１のインストラクションが、前記第２のインストラクションから生成されたものである請求項７９に記載の方法。８７．前記変換処理が、前記第２のインストラクションから第１のインストラクションを形成するリナンバリング処理を含む請求項７９に記載の方法。８８．前記第２のインストラクションが、定数参照を含み、前記変換処理が、前記第２のインストラクションの定数参照を定数に置き換える処理を含む請求項７９に記載の方法。８９．前記第２のインストラクションが、参照を含み、前記変換処理が、前記参照の格納位置をシフトする処理を含み、さらに、前記第１のインストラクションを前記変換処理後の参照に再リンク付けする請求項７９に記載の方法。９０．前記第１のインストラクションが、仮想マシンの第１の型のバイトコードを備え、前記第２のインストラクションが、仮想マシンの第２の型のバイトコードを備え、前記第１の型が前記第２の型と異なる請求項７９に記載の方法。９１．端末装置とともに利用するＩＣカードであって、前記端末装置と通信するように構成された通信部と、ストリングキャラクタを持つ第２のアプリケーションから生成された第１のアプリケーションを格納するメモリであって、前記ストリングキャラクタが、第１のアプリケーションにおいてＩＤ識別子により表現されているものと、前記メモリに結合されたプロセッサであって、前記プロセッサが、前記第１のアプリケーションをインタプリタ処理するインタプリタを使用するように構成され、前記端末装置と通信するため前記通信部を使用するように構成されているもの、を備えたことを特徴とするＩＣカード。９２．前記ＩＤ識別子が、整数列を備えた請求項９１に記載のＩＣカード。９３．ＩＣカードと端末装置を使用する方法であって、第２のアプリケーションから第１のアプリケーションを生成する処理であって、前記第２のアプリケーションがストリングキャラクタを持つ処理と、前記第２のアプリケーションのＩＤ識別子により前記第１のアプリケーションのストリングキャラクタを表わす処理と、インタプリタと前記第１のアプリケーションを前記ＩＣカードのメモリに格納する処理と、前記第１のアプリケーションをインタプリタ処理するインタプリタを使用するＩＣカードのプロセッサを使用する処理と、を備えたことを特徴とする方法。９４．前記ＩＤ識別子は、整数列を含む請求項９３に記載の方法。９５．マイクロコントローラであって、クラスファイル形式を持つアプリケーションとインタプリタとを格納しているメモリと、前記メモリに結合されたプロセッサであって、前記プロセッサは、前記アプリケーションを実行するためインタプリタを利用するように構成されているものを備えたことを特徴とするマイクロコントローラ。９６．さらに、端末装置と通信するように構成された通信部を備えた請求項９５に記載のマイクロコントローラ。９７．前記端末装置が、カードリーダを備え、前記通信部が、前記カードリーダと通信するように接点を備えた請求項９６に記載のマイクロコントローラ。９８．前記端末装置は、無線通信デバイスと備え、前記通信部は、前記無線通信デバイスと通信するための無線受信部を備えた請求項９６に記載のマイクロコントローラ。９９．前記端末装置は、無線通信デバイスを備え、前記通信部は、前記無線通信デバイスと通信するための無線送信部を備えた請求項９６に記載のマイクロコントローラ。１００．前記クラスファイル形式が、Ｊａｖａクラスファイル形式である請求項９５に記載のマイクロコントローラ。１０１．ＩＣカードを利用する方法であって、前記ＩＣカードのメモリに第１のアプリケーションを格納する処理と、前記ＩＣカードのメモリに第２のアプリケーションを格納する処理と、前記第２のアプリケーションが前記第１のアプリケーションおよび前記第１のアプリケーションが関連するデータのいずれにもアクセスできないように前記第１のアプリケーションと第２のアプリケーションを隔離するファイアウォールを生成する処理を備えたことを特徴とする方法。１０２．前記第１のアプリケーションと第２のアプリケーションが、Ｊａｖａバイトコードを含む請求項１０１に記載の方法。１０３．前記ファイアウォール生成方法が、Ｊａｖａインタプリタ利用を含む請求項１００に記載の方法。１０４．前記第１のアプリケーションの格納処理が、前記ＩＣカードの製造と関連して実行され、前記第２のアプリケーションの格納処理が、前記カード製造が完了した後に実行される請求項１０１に記載の方法。１０５．端末装置と共に利用されるＩＣカードであって、前記端末装置と通信するように構成された通信部と、高級プログラミング言語形式を持っているアプリケーションとインタプリタが格納されたメモリと、前記メモリに結合されたプロセッサであって、前記プロセッサが、ａ）実行するアプリケーションをインタプリタ処理するためのインタプリタを利用し、ｂ）前記アプリケーションそれぞれを隔離するファイアウォールを生成するためインタプリタを利用し、ｃ）前記端末装置と通信するため前記通信部を利用するように構成されているものを備えたことを特徴とするＩＣカード。