JP3766052B2

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

Info

Publication number: JP3766052B2
Application number: JP2002263319A
Authority: JP
Inventors: ジェイ．ウィルキンソンティモシー; ビー．グスレイスコット; クリシュナクシーラブディ; エイ．モントゴメリーマイケル
Original assignee: シュルンベルジェシステーム
Priority date: 1996-10-25
Filing date: 2002-09-09
Publication date: 2006-04-12
Anticipated expiration: 2017-10-22
Also published as: MY126363A; US7818727B2; US6308317B1; JP2000514584A; EP0932865B1; US20080115117A1; US20120254844A1; US7117485B2; AU4911897A; CN1242086A; TW476914B; EP0932865A1; US9400668B2; PT932865E; US20110126178A1; US8881118B2; US20120254843A1; JP2003141488A; ES2184066T3; KR20000052759A

Description

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

【０１１２】
これらを併せて利用することにより、ＩＣカードのデータとアプリケーションを隔離し、カードアプリケーション１２６が権限を持つＩＣカード１０のリソースのみにアクセスできるようにする。
【０１１３】
図１９に示すように、カードアプリケーション１２６Ｘ、１２６Ｙ、１２６Ｚはカードアプリケーション１２６が実行されるときに特定の特権を与えられる。例えば、これら特権は、カードアプリケーション１２６がどのデータファイルにアクセスでき、カードアプリケーション１２６がファイルシステム１４７においてどの処理が実行できるかを規定するものである。カードアプリケーション１２６に認められる特権は、通常は、特定のカードアプリケーション１２６Ｚが端末装置１４を介してユーザにより開始されときに設定される。
【０１１４】
ＩＣカード１０は、暗号ＩＤ識別認証メソッド(cryptographic identification verification methods)が、ＩＤ１９０（例えば、１９０ａ、１９０ｂ、１９０ｃ）と関係付けられ、カードアプリケーション１２６を実行する特権のセットが設定される。特定のＩＤ１９０ｃのカードアプリケーション１２６Ｚとの関連性は、カードアプリケーション１２６Ｚの実行が開始されると設定され、それゆえ図２０に示すように特定の実行アプリケーション２００が生成される。ＩＤ１９０は、ＩＤトークンと関連付けられた、ユニークで読みやすいテキストストリングである。ＩＤトークン（例えば、個人認証番号(personal identification number (PIN))、または、ＲＳＡ暗号方式の秘密鍵）は、暗号方式の鍵である。
【０１１５】
図２０に示すように、特定のカードアプリケーション１２６Ｚを実行するため、カードアプリケーション１２６ＺのＩＤ１９０ｃは、認証されなけらばならない。ＩＤ１９０ｃは、ＩＤ１９０ｃと関連付けられたＩＤトークンのデモンストレーション知識(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, “Programming the Internet in Ada 95”proceedings of Ada Europe 96, 1996）に記述されている。ジャスミン(Jasmin)は、Ｊａｖａバイトコードアセンブラであり、クラスファイルを生成するために利用される。ジャスミン(Jasmin)は、以下の参考文献に記述されている。“Meyer, Jon and Troy Downing, "Java Virtual Machine", O'Reilly, 1997。クラスファイルのソースにかかわらず、インタプリタ処理されるためのコードを生成するため、上記の記述は、Ｊａｖａ以外の言語に適用される。
【０１２９】
図２１に示すように、マイクロコントローラ２１０を含むＩＣカード、スマートカードは、プラスティックカード２１２上に搭載されている。このプラスティックカード２１２は、典型的なクレジットカードと同様の形状を持つものである。通信部１２ａは、通信チャンネルを確立するための接触式パッド２１４か、または、無線通信システムを備えている。
【０１３０】
他の実施形態において、図２２に示すように、マイクロコントローラ２１０は、携帯電話または設置型電話２２０に搭載され、電話にスマートカードの機能を効率的に持たせることができる。
【０１３１】
他の実施形態において、マイクロコントローラ２１０は、図２３に示すように、キーリング２３０に組み込まれる。これにより、キーリング２３０のマイクロコントローラ２１０と関連付けられているＩＤを認識するための仕組みが装備されている自動車に対して、高いセキュリティのもと、アクセスすることが可能となる。
【０１３２】
時計や指輪などの貴重品類２４０は、図２４に示すように、高いエルゴノミックス性をもってマイクロコントローラ２１０を埋め込むことができる。これら実施形態は、典型的には、通信チャンネルを確立するため無線通信システムを利用し、また、ユーザに対して最小限の手間でアクセス制御のための実装を可能とする方法を提供する。
【０１３３】
図２５は、自動車２５４の電気回路サブシステム２５２に搭載されるマイクロコントローラ２１０を示している。この実施形態では、マイクロコントローラは、自動車へのアクセス制御処理（例えば、ＩＤチェック、自動車のイグニッションシステムの起動制御など）、無線通信による有料道路料金徴収システム、自動車の通行位置を検知する位置決めシステム（ＧＰＳ）のインタフェース提供など、多様な目的に利用される。
【０１３４】
本発明の特定の実施形態を説明したが、本発明の開示に基づいて、他の様々な変更や置換が、当業者にとって明らかである。このような変更や置換は、本発明の範疇に入るものであり、特許請求の範囲に記載された内容に基づいて、本発明の技術的範囲に含まれる。
付属ドキュメントＡ（APPENDIX A）
好ましい実施形態におけるカードクラスファイル形式
カードクラスファイルは、オリジナルクラスファイルの圧縮形式である。カードクラスファイルは、オリジナルクラスファイルからＪａｖａプログラムをインタプリタ処理するために必要とされるセマンティック情報のみを含んでいる。オリジナルクラスファイルの間接参照は、コンパクト表現の結果、直接参照により置き換えられる。カードクラスファイル形式は、以下の原則に基づいている。
標準クラスファイル形式に近づけること。
【０１３５】
カードクラスファイル形式は、標準クラスファイル形式に可能な限り近づけるべきである。クラスファイルのＪａｖａバイトコードを変更しない。バイトコードを変更せず、バイトコードに対する構造的、静的な制約条件がそのままであることを確実にする。
実装を容易にすること。
【０１３６】
カードクラスファイル形式を、Ｊａｖａ仮想マシンの実装を行なうものに対して十分シンプルなものとする。異なるが等価に振舞う実装を認める。
フィージビリティ
カードクラスファイル形式が、スマートカード技術に適合するためにコンパクトにされたものでなければならない。現在の技術的制約に適合し、さらに、将来の技術革新の適合性を失わないものであること。
この記載は、「Ｊａｖａ仮想マシン仕様“The JavaTM Virtual Machine Specification”[1]（以下、レッドブックと呼ぶ）」というタイトルの本の第４章「クラスファイル形式」に基づいている。このドキュメントは、レッドブックに記載された標準クラスファイル形式に基づいているので、ここでは、レッドブックにはない情報のみ提示する。レッドブックは、すべての規則の最終的な権原として扱われる。
標準クラス形式との主な違いは、以下である。
【０１３７】
コンスタントプール(constant pool)が、１６ビットのＩＤ識別子のみを含むように最適化され、可能な限り間接参照が直接参照に置き換えられている。
【０１３８】
オリジナルクラスファイルの属性情報は、削除され、または、再グループされている。
【０１３９】
Ｊａｖａカードクラスファイル形式（Java Card class File Format）
当該セクションは、Ｊａｖａカードクラスファイル形式を記載している。
【０１４０】
各カードクラスファイルは、１つまたは複数のＪａｖａ型を含んでいる。この型は、クラスまたはインタフェースである。カードクラスファイルは、８ビットバイトストリームにより構成される。１６ビット、３２ビット、６４ビット量データは、それぞれ、連続する８ビットバイトデータを２つ、４つ、８つ読み込むことにより構成される。マルチバイトデータは、常に、ビックエンディアンで格納され、大きなバイトから順になっている。Ｊａｖａでは、この形式は、java.io.Datainput、 java.io.DataOutputのインタフェース、java.io.DatainputStream、java.io.DataOutputStreamなどのクラスによりサポートされている。Ｊａｖａクラスファイルデータを表わすデータ型と同じセットを定義して用いる。Ｕ１、Ｕ２、Ｕ４の型は、それぞれ、割り当てられていない１、２、４バイト量を表わしている。Ｊａｖａにおいて、これら型は、リードアンサインドバイト(readUnsignedByte)、リードアンサインドショート(readUnsignedByte)、“java.io.Datainput”のインタフェースのリードイント(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_Pool [0]である。インデックス０からconst_sizeまでの各constant_Poolのテーブルのエントリは、可変長の構造()を持っている。
class[]
クラスは、カードにロードされるアプリケーションを構成するmax_classクラスのテーブルである。
コンスタントプール（Constant Pool）
すべてのconstant_poolのテーブルのエントリには, 以下の一般形式がある:

constant_poolテーブルの中の各アイテムは、cp_infoエントリの種類を示す１バイトのタグで始めなければならない。info 配列の内容はタグの値に従って異なる。有効なタグとそれらの値はレッドブックで指定されたものと同じである。
それぞれのタグバイトの後には、特定の定数に関する情報を与える２またはそれ以上のバイトが続く。追加情報の形式はタグ値に従って異なる。
現時点で含まれる必要があるのタグは、CONSTANT_Class、CONSTANT_FieldRef、CONSTANT_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_InterfaceMethodrefInfo構造のタグアイテムは、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 [ u2 name_index; u2 signature_index; ul max_local; ul max_arg; ul max_stack; ul access_flags; u2 code_length; u2 exception_length; u1 code[code_length]; [ u2 start_pc; u2 end_pc; u2 handle_pc; u2 catch_type;]einfo[exception_length];] MethodInfo構造のアイテムは以下の通りである:
name_index
name_indexアイテムの値は、特別な内部のメソッド名(<init>か<clinit>のどちらかの1つ)か、有効なＪａｖａメソッド名のどちらかを表さなければならない。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[]
コード配列はメソッドを実現するＪａｖａ仮想マシンコードの実際のバイトを与える。コード配列がバイトアドレス可能なマシンのメモリに読み込まれるとき、もし配列の第１バイトが４バイト境界で並べられるならば、テーブルスイッチ(tableswitch)とルックアップスイッチ(lookupswitch)の３２ビットオフセットは４バイトに並べられ、コード配列配置の結果に関するさらなる情報のインストラクションの記述を参照する。コード配列の内容の詳細な制約条件は大規模であり、Ｊａｖａ仮想マシン仕様で記述されるものと同じである。
einfo[]
einfo配列における各エントリは、コード配列における1つの例外処理ハンドラを記述する。それぞれのeinfoエントリは以下のアイテムを含んでいる:
start_pc, end_pc
２つのアイテム、start_pcおよびend_pcの値は例外処理ハンドラがアクティブとなるコード配列における範囲を示す。start_pcの値はインストラクションのオペコードのコード配列の有効なインデックスでなければならない。end_pcの値は、インストラクションのオペコードのコード配列の有効なインデックスでなければならず、またはcode_lengthのコード配列の長さに等しいものでなければならない。start_pcの値はend_pcの値以下でなければならない。
start_pcは包括的で、end_pcは排他的である。すなわち、プログラムカウンタがstart_pc、end_pcのインターバルにある間は、例外処理ハンドラはアクティブである。
handler_pc
handler_pcアイテムの値は、例外処理ハンドラの始まりを示す。
アイテムの値は、コード配列への有効なインデックスでなければならず、インストラクションのオペコードのインデックスでなければならず、code_length item値以下でなければならない。
catch_type
catch_typeアイテムの値がノンゼロならば、それは有効なＪａｖａクラス型を表現しなければならない。catch_typeによって表わされたＪａｖａクラス型は、オリジナルクラスファイルの対応するmethod_info構造のcatch_typeによって記述されるＪａｖａクラス型とまったく同じでなければならない。このクラスはクラスThrowableまたはそのサブクラスの１つに違いない。例外処理ハンドラは、投げられた例外処理が与えられたクラスのインスタンスまたはそのサブクラスの１つであれば、コールされる。catch_typeアイテムの値がゼロならば、この例外処理ハンドラはすべての例外処理のためにコールされる。これは、最後に実装される。
【０１４６】
属性（Attributes）
オリジナルクラスファイルの中で使用された属性は、コンパクションのために消去されるかまたは再グループ化される。Ｊａｖａバイトコードのインタプリタ処理に必要であるどんな情報も犠牲にすることなく、事前に定義された属性であるSourceFile、ConstantValue、Exceptions、LineNumberTableおよびLocal-VariableTableは消去されうる。特定のメソッドのためバイトコードを含む事前に定義された属性Codeが、対応するMethodInfo構造に移動される。
【０１４７】
Ｊａｖａカード仮想マシンコードの制約条件（Constraints on Java Card Virtual Machine Code）
Ｊａｖａカード仮想マシンコードのメソッド、インスタンス初期化メソッド, クラスまたはインタフェース初期化メソッドがカードクラスのMethodInfo構造の配列コードに格納される。このコード配列の静的と構造的な制約条件の両方とも、レッドブックで記述したものと同じものである。
【０１４８】
Ｊａｖａカード仮想マシンとＪａｖａカードクラスファイル形式の制限（Limitations of the Java Card Virtual Machine and Java Card class File Format）
Ｊａｖａカード仮想マシンでの以下の制限は、Java Card Virtual Machine仕様書のこのバージョンによって規定されている。
【０１４９】
カードクラスファイルコンスタントプールあたり、CardClassFile構造()の１６ビット定数サイズフィールドによって６５５３５のエントリ数に制限される。これは、単一のカードクラスファイルの総合複雑度(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）
ＩＤインプットとアウトプットのストリング
カードＪＶＭの訂正処理において、宣言され生成されたＩＤ識別子が正しく管理されることは、非常に重要である。この管理は、ＩＤインプットファイルString-ID INMapの定義によって制御される。このテキストファイルは、以下に示されたものを基礎として、ネーム領域(namespace)の領域が何の目的を使用されるかを宣言している。このマップの１つの可能なアレンジメントは、カードＪＶＭインタプリタによる内部利用のためにいくつかのＩＤ識別子をリザーブすることができることであり、残りはカードＪＶＭアプリケーションに割り当てられる。
【０１５５】
【数１】

【０１５６】
【数２】

【０１５７】
本質的には、スマートカードにロードされることになっているすべてのアプリケーションは自らのＩＤ識別子を、Ox4000からOx7FFFの間に割り当てる。如何なるロードされたアプリケーションも他のアプリケーションにアクセスするのは許可されていないので、この領域は各アプリケーションが自由に利用できる。
【０１５８】
プリロードされたクラスライブラリのためにＩＤ識別子を管理するときには注意を要する。これらのＩＤ識別子の管理は、ＩＤ識別アウトプットファイルString-ID OUTMapのオプション生成により補助される。このマップは、新しいString-ID割り付け処理(bindings)により増えて行くString-lD INMapである。これら割り付け処理(bindings)は、カードクラスファイルコンバータのアプリケーションが終了したときに生成される。String-ID OUTMapは、カードにロードされたサポートライブラリとＯＳインタフェースのために生成される。このマップは、カードにロードされたサポートライブラリとＯＳインタフェースを使用するスマートカードのアプリケーション用のString-lD 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）
再番号づけされたＪａｖａバイトコードに行なわれるチェック処理
インストラクションを獲得する。インストラクションの数値はインストラクション型の中に暗示的に含まれている。
【０２０８】
【数４０】

【０２０９】
下記に基づくいくつかの先実行のチェック処理を実装する。
／＊
＊インプットスタックの状態をチェックする。バイトコードをリナンバリングし、バイトコードの値（以下、バイトコード）が正しいグループに属しているか否かをテストすることにより、必要なセキュリティチェックが実行で
きる。
【０２１０】
【数４１】

【０２１１】
最後に、いくつかの後実行のチェック処理を実装する。
【０２１２】
【数４２】

【０２１３】
【数４３】

【０２１４】
サポートされたＪａｖａバイトコードの型ごとの再配置
【０２１５】
【数４４】

【０２１６】
【数４５】

【０２１７】
【数４６】

【０２１８】
【数４７】

【０２１９】
【数４８】

【図面の簡単な説明】
【図１】ＩＣカードシステムのブロック図である。
【図２】ＪａｖａアプリケーションをＩＣカードにダウンロードする準備の手順を示すフロー図である。
【図３】カードクラスファイルコンバータから生成され、使用されるファイルのブロック図である。
【図４】アプリケーションクラスファイルをカードクラスファイルへ変換する手順を示すブロック図である。
【図５】クラスファイルコンバータの動作を示すフロー図である。
【図６】バイトコードの変更手順を示すフロー図である。
【図７】スぺシフィックバイトコードをジェネリックバイトコードへの変換を示すブロック図である。
【図８】定数参照値の定数への置き換えを示すブロック図である。
【図９】参照値の更新値への置き換えを示すブロック図である。
【図１０】元のバイトコードのリナンバリング手順を示すブロック図である。
【図１１】元のバイトコードを異なる仮想マシンのアーキテクチャ用へ変換する様子を示すブロック図である。
【図１２】アプリケーションをＩＣカードにロードする様子を示すブロック図である。
【図１３】ＩＣカード上のアプリケーションを実行する様子を示すブロック図である。
【図１４】ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭのメモリ構造を示す図である。
【図１５】カードＪａｖａ仮想マシンのアーキテクチャ全体像を示すフロー図である。
【図１６】セキュリティチェックを伴うカードＪａｖａ仮想マシンの実行方法を示すフロー図である。
【図１７】カードＪａｖａ仮想マシン上でバイトコードを実行する様子を示すフロー図である。
【図１８】セキュリティチェックを伴わないカードＪａｖａ仮想マシンの実行方法を示すフロー図である。
【図１９】カードアプリケーションと識別子との対応付けを示すブロック図である。
【図２０】特定の実行アプリケーションへのアクセス権限を示すブロック図である。
【図２１】スマートカードに用いられたマイクロコントローラの斜視図である。
【図２２】電話機に用いられたマイクロコントローラの斜視図である。
【図２３】かぎ型リングに用いられたマイクロコントローラの斜視図である。
【図２４】指輪に用いられたマイクロコントローラの斜視図である。
【図２５】車に用いられたマイクロコントローラの斜視図である。
【符号の説明】
１０ＩＣカード
１２ａ，１２ｂ通信部
１４端末装置
１６カードＪａｖａ仮想マシン（カードＪＶＭ）
２０Ｊａｖａアプリケーション
２０ａ，２０ｂ，２０ｃＪａｖａコード
２２Ｊａｖａアプリケーション開発環境
２４アプリケーションクラスファイル
２４ａ，２４ｂ，２４ｃコンパイルコード
２６カードクラスファイルコンバータ
２７カードクラスファイル
２８カードローダ
３０ＩＤインプットマップのストリング
３２ＩＤアウトプットマップのストリング
７０，７２，８０，８２，１００バイトコード
９０インボークスタティック
９４オペランド
１０２リナンバリングバイトコード
１１２ＪａｖａバイトコードＩＬＯＡＤ
１１４ワードスタック
１１６バイトコードＩＬＯＡＤＢ
１１８バイトスタック
１２０ローディング実行制御部
１２２カードオペレーティングシステム
１２６，１２６ａ，１２６ｂ，１２６ｃカードアプリケーション
１３２通信ドライバ
１３４ＩＣカードドライバ
１３６端末装置アプリケーション
１４０カードＲＯＭ
１４０ａ固定化されたアプリケーション
１４０ｂクラスライブラリ
１４１カードＲＡＭ
１４１ａロード可能アプリケーションＡ
１４１ｂロード可能アプリケーションＢ
１４１ｃロード可能クラスライブラリ
１４２カードＥＥＰＲＯＭ
１４４ａＶＭスタック
１４４ｂシステム変数
１４４ｃＲＡＭヒープ
１４５ランタイムサポート
１４６ａＥＥＰＲＯＭヒープ
１４７ファイルシステム
１４８システムスタック
１５０インストラクションディスパッチループ
１６５ｄインストラクションサポート
２０９セッションキー
２１０マイクロコントローラ
２１２プラスティックカード
２１４接触式パッド
２２０携帯電話または設置型電話
２３０キーリング
２４０貴重品類
２５２電気回路サブシステム
２５４自動車

Claims

第１のインストラクションと前記第１のインストラクションを実行するインタプリタとを記憶するメモリを有するＩＣカードを備えたＩＣカードシステムであって、
第２のアプリケーションの第２のインストラクションを、第１のアプリケーションの第１のインストラクションに変換するコンバータを有する端末を備え、
前記コンバータが、前記第２のインストラクションから第１のインストラクションを形成するリナンバリング処理を実行することを特徴とするＩＣカードシステム。
第１のインストラクションと前記第１のインストラクションを実行するインタプリタとを記憶するメモリを有するＩＣカードを備えたＩＣカードシステムであって、
第２のアプリケーションの第２のインストラクションを、第１のアプリケーションの第１のインストラクションに変換するコンバータを有する端末を備え、
前記第２のインストラクションが、定数への参照を含み、
前記コンバータが、前記第２のインストラクションの定数への参照を定数に置き換えることを特徴とするＩＣカードシステム。
第１のインストラクションと前記第１のインストラクションを実行するインタプリタとを記憶するメモリを有するＩＣカードを備えたＩＣカードシステムであって、
第２のアプリケーションの第２のインストラクションを、第１のアプリケーションの第１のインストラクションに変換するコンバータを有する端末を備え、
前記第２のインストラクションが、参照を含み、
前記コンバータが、前記参照の位置をシフトする処理を実行し、そのシフト処理後の参照に対して前記第１のインストラクションの再リンク付けを実行することを特徴とするＩＣカードシステム。
インタプリタが記憶されたメモリを有するＩＣカードと、コンバータを有する端末との動作方法であって、
前記端末が、前記コンバータにより、第２のアプリケーションの第２のインストラクションを第１のアプリケーションの第１のインストラクションに変換するステップと、
前記端末が前記ＩＣカードへ前記第１のインストラクションを送り、前記ＩＣカードが受け取った第１のインストラクションを前記メモリに格納するステップと、
前記ＩＣカードが、前記インタプリタに前記第１のインストラクションを実行させるステップとを含み、
前記コンバータが、前記第２のインストラクションをリナンバリングすることにより前記第１のインストラクションを生成することを特徴とする動作方法。
インタプリタが記憶されたメモリを有するＩＣカードと、コンバータを有する端末との動作方法であって、
前記端末が、前記コンバータにより、第２のアプリケーションの第２のインストラクションを第１のアプリケーションの第１のインストラクションに変換するステップと、
前記端末が前記ＩＣカードへ前記第１のインストラクションを送り、前記ＩＣカードが受け取った第１のインストラクションを前記メモリに格納するステップと、
前記ＩＣカードが、前記インタプリタに前記第１のインストラクションを実行させるステップとを含み、
前記第２のインストラクションが、定数への参照を含み、
前記コンバータが、前記第２のインストラクションの定数への参照を定数に置き換えることを特徴とする動作方法。
インタプリタが記憶されたメモリを有するＩＣカードと、コンバータを有する端末との動作方法であって、
前記端末が、前記コンバータにより、第２のアプリケーションの第２のインストラクションを第１のアプリケーションの第１のインストラクションに変換するステップと、
前記端末が前記ＩＣカードへ前記第１のインストラクションを送り、前記ＩＣカードが受け取った第１のインストラクションを前記メモリに格納するステップと、
前記ＩＣカードが、前記インタプリタに前記第１のインストラクションを実行させるステップとを含み、
前記第２のインストラクションが、参照を含み、
前記コンバータが、前記参照の位置をシフトする処理を実行し、そのシフト処理後の参照に対して前記第１のインストラクションの再リンク付けを実行することを特徴とする動作方法。
高級言語で書かれたプログラムを実行可能なマイクロコントローラ（１０）であって、
メモリと、
前記メモリにロードされて動作するインタプリタ（１６）を備え、
前記インタプリタ（１６）は、以下のａ）およびｂ）を備えるプログラミング環境によって生成されて前記メモリにロードされたアプリケーションプログラムをインタプリタ処理できることを特徴とする。
ａ）高級言語ソースコードであるアプリケーションソースプログラミング（２０）をコンパイル形式（２４）にコンパイルするコンパイラ（２２）、
ｂ）前記コンパイル形式（２４）を前記インタプリタ（１６）によりインタプリタ処理するのに適した形式（２７）へと変換する後処理をするコンバータ（２６）。
前記コンパイル形式（２４）が、属性情報を含み、前記コンバータ（２６）が、前記インタプリタ（１６）が必要とする属性情報を含める手段と前記インタプリタ（１６）が必要としない属性情報を含めない手段を備えた請求項７に記載のマイクロコントローラ（１０）。
前記コンパイル形式（２４）が、標準Ｊａｖａクラスファイル形式であり、前記コンバータ（２６）が、入力を前記標準Ｊａｖａクラスファイル形式の入力コンパイル形式（２４）として受け入れ、前記インタプリタ（１６）によるインタプリタ処理に適する形式の出力（２７）に変換する請求項７又は８に記載のマイクロコントローラ（１０）。
前記コンパイル形式（２４）が、オブジェクト、クラス、フィールド、メソッドを特定するために利用されるストリングの情報を含み、前記コンバータは、前記ストリングをユニークなＩＤ識別子（５１ｂ）にマッピング処理する手段を含む請求項７から９のいずれか一項に記載のマイクロコントローラ（１０）。
前記それぞれのユニークなＩＤ識別子が整数である請求項１０に記載のマイクロコントローラ（１０）。
前記マッピング処理は、ストリングのＩＤ識別子マップファイル（３０、３２）への格納である請求項１０又は１１に記載のマイクロコントローラ（１０）。
前記高級言語は、バイトコードのセットをサポートし、前記インタプリタ（１６）は、前記バイトコードのセットのサブセットをサポートし、前記コンバータ（２６）は、前記コンパイル形式（２４）が前記バイトコードのセットのサブセットのバイトコードのみを含んでいることをベリファイする（５１ｃ、５２）請求項１０から１２のいずれか一項に記載のマイクロコントローラ（１０）。
前記コンパイル形式（２４）が、バイトコード形式であり、前記コンバータ（２６）が、下記のステップを含む処理ステップのうちの少なくとも１つの処理ステップを用いて、前記コンパイル形式（２４）のバイトコードを前記インタプリタ（１６）によりインタプリタ処理するために適したバイトコード（２７）に変換する手段（５４）を備えた請求項１０から１３のいずれか一項に記載のマイクロコントローラ（１０）。
ａ）オリジナルバイトコードのすべてのジャンプ処理とそのジャンプ先を記録する処理（６１）、
ｂ）スぺシフィックバイトコードを意味的に等価なジェネリックバイトコードに変換する処理（６３）、
ｃ）バイトコードオペランドを、ＩＤストリングを用いた参照からユニークなＩＤ識別子を用いた参照に変更する処理（６４）
ｄ）コンパイル形式（２４）のバイトコードをインタプリタ処理に適した形式の等価なバイトコードにリナンバリングする処理（６６）、
ｅ）ステップａ）、ｂ）、ｃ）、ｄ）の変換処理により影響を受けるジャンプ処理のジャンプ先アドレスに再リンク付けする処理（６７）
前記コンパイル形式（２４）が、多様なコンピュータプラットフォームへの移植性があるように規定された請求項１０から１４のいずれか一項に記載のマイクロコントローラ（１０）。
前記インタプリタ（１６）が、さらに、バイトコードから構成されたアプリケーションのインタプリタ処理中に、下記（ａ）および（ｂ）のうち少なくとも１つのセキュリティ基準に引っかかったか否かを決定するように構成され、
前記インタプリタが、前記バイトコードの実行がセキュリティ基準の違反を起こさないことを確認するチェック処理を当該バイトコードの実行処理に先行して少なくとも１回実行するように構成された請求項１０から１５のいずれか一項に記載のマイクロコントローラ（１０）。
（ａ）前記アプリケーションが権限のないメモリ領域にアクセスすることを認めない、
（ｂ）前記アプリケーションがアクセス権限のないマイクロコントローラのリソースへにアクセスすることを認めない。
少なくとも１つのアプリケーションプログラムが、
前記アプリケーションのローディング処理に先立って、前記アプリケーションが前記セキュリティ基準に違反しないことを確認する処理ステップと、
セキュリティを維持してローディング処理を行なう処理ステップと、
を含んでいるプロセスにより生成されたアプリケーションである請求項１０から１６のいずれか一項に記載のマイクロコントローラ（１０）。
前記セキュリティを維持してローディング処理を行う処理ステップが、ローディングキーを利用してロードされるアプリケーションを暗号化する処理ステップを含む請求項１７に記載のマイクロコントローラ（１０）。
メモリとプロセッサを持つマイクロコントローラをプログラミングする方法であって、前記方法が、
第１のプログラミング言語で記述されたアプリケーションプログラム（２０）をコンパイラへ入力する処理と、
前記コンパイラが、前記第１のプログラミング言語で記述されたアプリケーションプログラム（２０）を、前記第１のプログラミング言語に対応し、第１の中間コード仮想マシンによりインタプリタ処理できる第１の中間コード（２４）にコンパイルする処理（２２）と、
前記第１の中間コード（２４）をコンバータへ入力し、前記マイクロコントローラ上の第２の中間コード仮想マシン（１６）によりインタプリタ処理できる第２の中間コード（２７）に変換する変換処理（２６）と、
前記第２の中間コードを前記マイクロコントローラ（１０）のメモリにロードする処理とを含み、
前記変換処理がさらに、
オブジェクト、クラス、フィールド、メソッドのＩＤストリングの関連付け処理と、
それらストリングをユニークなＩＤ識別子（５１ｂ）にマッピングするマッピング処理とを含むことを特徴とする方法。
前記マッピング処理が、ストリングを整数にマッピングする処理を含む請求項１９に記載の方法。
前記変換処理が、
少なくとも以下のａ）〜ｄ）ステップのうちの１つを実行する処理と、
ステップａ）、ｂ）、ｃ）、またはｄ）の処理により影響を受けるジャンプ処理のジャンプ先アドレスに再リンク付けする処理（６７）とを含む、請求項１９または２０に記載の方法。
ａ）オリジナルバイトコードのすべてのジャンプ処理とそのジャンプ先を記録する処理（６１）、
ｂ）スぺシフィックバイトコードを意味的に等価なジェネリックバイトコードに変換する処理（６３）、
ｃ）バイトコードオペランドを、ＩＤストリングを用いた参照からユニークＩＤ識別子を用いた参照に変更する処理（６４）、
ｄ）コンパイル形式のバイトコードをインタプリタ処理に適した形式の意味的に等価なバイトコードにリナンバリングする処理（６６）。
前記第２の中間コード（２７）を前記マイクロコントローラ（１０）のメモリにロードする処理を備えたことを特徴とする方法が、さらに、前記第２の中間コード（２７）のロード処理に先立って、前記第２の中間コード（２７）が前記第１のプログラム言語に対して定義されたセキュリティモデルに適合するものであるかおよび当該ロード処理がセキュリティプロトコルに従って実行されるものであるかを認証するため前記第２の中間コード（２７）をチェックする処理を含む請求項１９から２１のいずれか一項に記載の方法。
さらに復号鍵の供給処理を含み、前記セキュリティプロトコルが、ロードされた前記復号鍵に対応する鍵を使って前記第２の中間コード（２７）が暗号化されていることを要求する請求項１９から２２のいずれか一項に記載の方法。
メモリと前記メモリにロードされたインタプリタ（１６）を備え、インタプリタ処理可能なプログラミング言語により記述されたプログラム（２４）を変換することにより得られた変換プログラム（２７）を実行しうるマイクロコントローラ（１０）であって、前記マイクロコントローラ（１０）が以下の（ａ）および（ｂ）の特徴を持つもの。
（ａ）前記マイクロコントローラは、インタプリタ処理できるプログラミング言語で記述されたプログラム（２４）をインタプリタ処理するためには不十分な容量のメモリを用いて動作するものである、
（ｂ）前記メモリが、インタプリタ処理可能な言語のサブセットにより記述された変換プログラム（２７）をインタプリタ処理できるインタプリタを含むメモリであって、変換プログラム（２７）が、下記の（１）〜（４）のうち少なくとも１つの規則を適用してインタプリタ処理可能なプログラミング言語により記述されたプログラムから得られたもの。
（１）ストリングを識別子にマッピングすること、
（２）セキュリティチェック処理を実行すること、
（３）構造チェックを実行すること、
（４）セマンティックチェックを実行すること。
前記変換プログラム（２７）がクラスファイルまたはクラスファイルの変換により得られる、請求項２４に記載のマイクロコントローラ（１０）。
前記メモリが１メガバイトより少ないことを特徴とする請求項２４又は２５に記載のマイクロコントローラ（１０）。
変換プログラムの使用を要求する要求元が前記変換プログラム（２７）へのアクセス件を持つか否かをアクセス制御リストに基づいて決定する回路を持ち、前記決定に基づいて、前記要求元に対して、前記変換プログラムに対するアクセスを選択的に認める、請求項２４から２６のいずれか一項に記載のマイクロコントローラ（１０）。
前記変換プログラム（２７）がアクセスしようとするメモリの特定領域へのアクセス権限を前記変換プログラム（２７）が持っているか否かを決定する回路をさらに備えた請求項２７に記載のマイクロコントローラ（１０）。
さらに前記マイクロコントローラ（１０）が下記の（ａ）〜（ｃ）のうち少なくとも１つのセキュリティチェックを実行するように構成された請求項２４から２８のいずれか一項に記載のマイクロコントローラ（１０）。
（ａ）前記変換プログラム（２７）がインタプリタ処理されている間にアクセスセキュリティ規則を実行し、前記変換プログラム（２７）が権限の無いメモリ領域または他の権限の無いマイクロコントローラリソースにアクセスすることを防止すること、
（ｂ）各バイトコードが正しく実行されているか決定する処理に先立って少なくとも１回各バイトコードがチェックされるように前記インタプリタ（１６）が構成されていること、
（ｃ）前記マイクロコントローラにロードされる前に前記変換プログラムの完全性がチェックされ、ロード処理がセキュリティプロトコルに応じて実行されること。
前記セキュリティプロトコルは、復号鍵を持っており、ロードされた変換プログラム（２７）が前記復号鍵に対応する鍵により暗号化されていることを要求することを特徴とする請求項２９に記載のマイクロコントローラ（１０）。
ファイルシステムを持ち、下記の（ａ）〜（ｃ）のいずれかの手段を介して前記ファイルシステムへアクセスできるように構成された請求項２４から３０のいずれか一項に記載のマイクロコントローラ（１０）。
（ａ）前記マイクロコントローラが、ファイルからの読み出し処理、ファイルへの書き込み処理またはファイルの消去処理の権限に対するアクセス制御リストを備えていること、
（ｂ）前記マイクロコントローラが、ファイルへのアクセス権限を確立するための鍵有効化が実行できること、
（ｃ）前記マイクロコントローラが、ファイルへのアクセス権限を確立するための主体を認証できること。