(57)【特許請求の範囲】
【請求項１】
アプリケーションのソースコードが書き込まれ、コンパイラ（８２）により擬似コードとしてコンパイルされ、チェッカー（９１）によりチェックされ、コンバータ（９２）によりコンバートされ、ローダ（９３、６８）によりロードされる局から、中間擬似コードタイプの言語のインタープリタを含む仮想マシンと、アプリケーションプログラミングインターフェース（ＡＰＩ）とを備えた実行環境を有する組込システムに、アプリケーションをローディングする方法であって、
組込システムの同一名前空間に記憶するように構成される、モジュールと呼ばれるパッケージの複数の集合のスタティックリンキングの実施をコンバートが含み、コンバータによって各モジュールに識別子（ＭＩＤ）を割り当て、モジュールのクラスに入る各クラス（ＮＣＩ）、各メソッド（ＮＭ）、および各属性（ＮＡ）に参照番号（ＮＣＩ）を割り当て、
モジュールにリンキングされる擬似コードにおけるメソッドまたは属性の参照は、モジュールの内部クラス（ＩＩ）または外部クラス（ＩＥ）の参照と、クラス番号（ＮＣＩ）と、メソッド番号（ＮＭ）または属性番号（ＮＡ）とを示すインジケータからなる３バイトで符号化され、
ロードされるモジュールは、それぞれが一つのアプリケーションに対応するシステムクラスまたはサービスモジュールを含む一つまたは複数のアプリケーションプログラミングモジュールであり、外部クラスの参照（ＩＥ）は、アプリケーションプログラミングインターフェースモジュールの参照として仮想マシンにより解釈されることを特徴とする方法。
【請求項２】
組込システムへのモジュールのロードが、一方ではモジュールを表すリスト（６９、１０１、１０３）の記憶を含み、前記リスト内でモジュールのインデックスがリンカにより前記モジュールに関連づけられる０〜ｎの間の番号（ＩＭｉ）により構成され、及び、前記モジュールの識別子（ＭＩＤ）の表示リストのインデックスの関連付けを記憶するテーブル（７０、１０２、１０４）の記憶を含み、前記リストおよびテーブルが、不揮発性プログラマブルメモリからなり、擬似コードにおける外部モジュールへの外部参照（ＩＥ）が、仮想マシンのインタープリタにより、モジュールのリストのインデックスと同等のインデックスを構成するものとして解釈されることを特徴とする請求項１に記載の組込システムへのアプリケーションのロード方法。
【請求項３】
ロードが、各モジュールについて、モジュールのインデックスの参照を含む、クラスの表示リスト（ＴＲＣ）の記憶を含み、各クラスについて、属性（ＴＲＡ）およびメソッド（ＴＲＭｅ）の表示リストの記憶とを含むことを特徴とする請求項２に記載の組込システムへのアプリケーションのロード方法。
【請求項４】
モジュールが、単一のモジュールリストで参照され、システムクラスが、単一のＡＰＩモジュールに含まれ、擬似コードにおいてｎとは異なる外部クラスへのあらゆる参照が、前記ＡＰＩモジュールの参照として仮想マシンにより解釈されることを特徴とする請求項２に記載の組込システムへのアプリケーションのロード方法。
【請求項５】
クラスが、パブリックであると宣言され、あるいはプライベートパッケージとして宣言され、属性およびメソッドが、プライベートパッケージまたはプライベートクラスとして保護されると宣言され、クラスの番号順が、パブリッククラス、次いでプライベートパッケージのクラスの順に行われ、属性またはメソッドの番号順が、パブリックの、プライベートパッケージによるプロテクテッドの、およびプライベートクラスによるプロテクテッドの属性またはメソッドの順に、コンバータ（９２）により行われることを特徴とする請求項４に記載の組込システムへのアプリケーションのロード方法。
【請求項６】
システムクラスが、別々にロード可能な複数のＡＰＩモジュールに含まれ、ローダ（６８）が、モジュールの２個の表示リストと対応する２個の関連づけテーブルＭＩＤ／Ｉｍｉとを、不揮発性プログラマブルメモリに保持し、一方がＡＰＩモジュールについてであり且つ他方が非ＡＰＩモジュールについてであり、ローダが、ヘッダに規定されたモジュールの性質に応じて２個のリストの内の一方、ＡＰＩモジュールのリスト又は非ＡＰＩモジュールのリスト、にモジュールをロードし、モジュールリストのモジュールのあらゆる外部参照が、ＡＰＩモジュールのインデックスの参照として解釈されることを特徴とする請求項２に記載の組込システムへのアプリケーションのロード方法。
【請求項７】
モジュールのスタティックリンキングは、ローダによって実行され、モジュールの擬似コードは現在のモジュールをリンクするのに使用された参照されたモジュールのリストを有するヘッダを含み、前記リストの各エントリはＡＰＩモジュールの識別子（ＭＩＤ）に対応し、中間擬似コードにおける非ＡＰＩモジュールの外部クラスの参照が、前記リストにおけるインデックスであり、ターゲットプラットフォームへの非ＡＰＩモジュールのローディングが、ＡＰＩモジュールのＭＩＤ／ＩＭｉ関連づけテーブルの識別子（ＭＩＤ）から得られるＡＰＩモジュールのインデックス番号による、前記参照のリプレースメントを含むことを特徴とする請求項６に記載の組込システムへのアプリケーションのロード方法。
【請求項８】
仮想マシンと、アプリケーションプログラミングインターフェースを含むＡＰＩプラットフォームと、不揮発性のＲＯＭと、不揮発性のプログラマブルまたは修正可能なメモリと、ＲＡＭとを含む組込システムであって、不揮発性のプログラマブルメモリが、システムクラスおよびサービスモジュールを含む少なくとも一つのＡＰＩモジュールと、モジュールにインデックスをつけた少なくとも一つのモジュール表示リスト（ＴＲＭ）と、前記モジュールの識別子（ＭＩＤ）に表示リストのモジュールのインデックス（ＩＭ）を関連付けるテーブル（７０、１０４）とを含み、各モジュールは、クラスにインデックスが付けられていて各クラスがそのモジュールのインデックス（ＩＭ）の参照を有するクラス表示リスト（ＴＲＣ）を含み、各クラスは、属性およびメソッドにインデックスを付けた属性（ＴＲＡ）およびメソッド（ＴＲＭｅ）の表示リストを含み、メソッドまたは属性の参照が、モジュールの内部クラス（ＩＩ）または外部クラス（ＩＥ）の参照に対応する少なくとも３バイトで符号化され、モジュールの外部参照が、モジュールリストでＡＰＩモジュールのインデックスを構成し、クラス番号（ＮＣＩ）が、モジュールのクラスの表示テーブルでクラスのインデックスに対応し、メソッド（ＮＭ）または属性（ＮＡ）の番号が、モジュールのクラスのメソッドまたは属性の表示テーブルにおけるメソッドまたは属性のインデックスに対応することを特徴とする組込システム。
【請求項９】
メソッドまたは属性への参照を符号化する３バイトの第一のバイトと、所定値ｎとを比較して、内部クラスに関するか、外部クラスに関するかを決定する比較手段を含むことを特徴とする請求項８に記載の組込システム。
【請求項１０】
システムの主要プログラムを含む主要モジュールを有することを特徴とする請求項８に記載の組込システム。
【請求項１１】
クラスが、パブリックのクラス、次いでプライベートパッケージのクラスの順にインデックスを付けられ、属性またはメソッドが、パブリックの属性またはメソッド、保護された属性またはメソッド、プライベートパッケージの属性またはメソッド、およびプライベートクラスにおける属性または方法の順にインデックスを付けられることを特徴とする請求項８に記載の組込システム。
【請求項１２】
システムクラスと、一方がＡＰＩモジュール用で他方が非ＡＰＩモジュールおよびメインモジュール用の２個のモジュール表示リスト（１０１、１０３）とを含む複数のＡＰＩモジュールと、それぞれがモジュール表示リストに対応する２個のＭＩＤ／ＩＭｉ関連づけテーブル（１０２、１０４）とを不揮発性のプログラマブルメモリが含むことを特徴とする請求項１１に記載の組込システム。
【請求項１３】
主要モジュールを介してサービスモジュールのインスタンスを生成可能なメソッドを含む、ＡＰＩモジュール（１０５）のアクセスマネージャクラス「アクセス・マネージャ」を含み、前記クラス「アクセス・マネージャ」は、前記クラス「アクセス・マネージャ」が１個より多くのインスタンスを有することを禁ずる保護を備えることを特徴とする請求項１０に記載の組込システム。
【請求項１４】
中間擬似コードタイプの言語のインタープリタを含む仮想マシンと、アプリケーションプログラミングインターフェース（ＡＰＩ）とを備えた実行環境を有する、マルチアプリケーション組込システムのアプリケーションの実行方法であって、モジュールの内部クラス（ＩＩ）または外部クラス（ＩＥ）への参照と、クラス番号（ＮＣＩ）と、メソッド（ＮＭ）または属性番号（ＮＡ）とに対応する少なくとも３バイトで符号化された、擬似コードにおけるメソッドまたは属性の参照を、モジュールリストで参照する、一つのアプリケーションに対応するサービスモジュールの中間擬似コードの実行時に、モジュールの外部参照が、仮想マシンにより、一つまたは複数のＡＰＩモジュールのリストのＡＰＩモジュールのインデックスの参照として解釈され、解釈された中間擬似コードはマイクロプロセッサにより実行されることを特徴とする方法。
【請求項１５】
識別子（ＭＩＤ）を有するサービスモジュールの実行要求を受信すると、実行環境が、システムの主要プログラムを含む主要モジュールの入力クラスにアクセスし、主要モジュールが、サービスモジュールへのアクセスを管理するＡＰＩモジュールの特別クラス「アクセス・マネジャー」のインスタンスをインストールし、このクラスのメソッドを使用することにより、モジュールが参照されるリストでモジュールのインデックスに識別子を関連づけるテーブルを介して、要求されたサービスモジュールの入力クラスのインスタンスを生成可能にし、インスタンスが、前記メソッドにより主要プログラムに戻されることを特徴とする請求項１４に記載のマルチアプリケーション組込システムのアプリケーション実行方法。
【発明の詳細な説明】
【０００１】
本発明は、データ処理リソースを備えたマルチアプリケーション組込システムにアプリケーションをローディングする方法、対応する組込システム、および、対応する組込システムのアプリケーション実行方法に関する。
【０００２】
本発明は、特に、中間擬似コードと、関連する仮想マシンとを使用する、マルチアプリケーション携帯オブジェクトに組込されるシステムで、同じメモリスペースを共有するモジュール間の分離（ＰＡＲＥ−ＦＥＵ）の実施に関する。
【０００３】
「Ｓｕｎ」社により導入された「Ｊａｖａ」（商標）技術は、「Ｊａｖａ」オブジェクトと関連仮想マシンとに向けられたプログラミング言語に基づいたものである。この技術は、パワーＣＰＵと、メガバイト単位の大型メモリとを有する局またはＰＣ（パーソナル・コンピュータ）（以下、「Ｊａｖａ」プラットフォームとする）で開発された。
【０００４】
数年前から、「Ｊａｖａ」技術の概念が手直しされ、携帯オブジェクトに組込されるシステムで作動するように、たとえばクレジットカード、マイクロプロセッサを組み込んだＳＩＭマイクロモジュール（一般に、チップカードと呼ばれる）、ＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）携帯電話、ＰＣＭＣＩＡカード、あるいは他のあらゆる携帯端末のフォーマットに適合されてきた。以下、これらの携帯オブジェクトの任意の一つを示すためにカードという表現を用いることにする。これまではアセンブラとして構成されてきた組込システムのプログラミングは、今後、「Ｊａｖａ」のような高級プログラミング言語で可能となり、クライアントアプリケーションの開発を容易にし、また加速することができる。
【０００５】
携帯オブジェクトの組込システムに固有のこうした新しいタイプのプラットフォーム（以下、特別プラットフォームとする）は、従来のプラットフォームのサブアセンブリである。組込システムの環境を小さくしたことによって相違が生じている。一般に、図４ａに示したように、チップカード（１０）は、マイクロプロセッサ（１４）に接続された入出力システム（１１）と、揮発性のＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）（１２）と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）（１３）からなる不揮発性メモリ（１５）と、フラッシュＲＡＭまたはＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）とを含む。これらの素子の集合が、接続ＢＵＳによりマイクロプロセッサに接続される。たとえば、チップカードは、最善の場合、既存の新しいコンポーネントを用いることによって、ＲＯＭと、３２キロバイトのＥＥＰＲＯＭと、２キロバイトのＲＡＭとを含む。
【０００６】
従来の「Ｊａｖａ」システムでは、アプリケーションは、局またはＰＣに書き込まれる。そのソースコードは、使用されているプラットフォームの装置コードとは独立した、「Ｊａｖａ  Ｂｙｔｅ  Ｃｏｄｅ」と呼ばれる中間擬似コードでコンパイルされる。次に、アプリケーションは、ターゲットプラットフォームまたは従来の「Ｊａｖａ」プラットフォームにダウンロードされる。ロードされたアプリケーションは、様々なメソッドを擬似コードにコンパイルしたクラス、いわゆるクライアントクラスの集合からなり、アプリケーションプログラミングインターフェースまたはアプリケーションプログラミング用のインターフェースＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）でサポートされる。アプリケーションプログラミングインターフェースは、ユーザインターフェースを均質化し、エディタ、キーボードまたはプリンタなどを制御することができる。従来のプアラットフォームの仮想マシンは、擬似コードチェッカーと、ダイナミッククラスローダと、装置コードへの翻訳を可能にする擬似コードインタープリタと、セーフティ管理プログラムとを含む。
【０００７】
従来の仮想マシンと組込システムの仮想マシン（以下、特別仮想マシンとする）との主な相違は、組込システムの仮想マシンが、２個の別々の部分に分解されることにある。図４ｂによれば、仮想マシンは、コンバータ（３２）を含んで、オフプラットフォーム（「ｏｆｆ−ｐｌａｔｆｏｒｍ」）の仮想マシンと呼ばれる、特別プラットフォーム（４０）外の部分（３０）と、擬似コードインタープリタを含んで、組込（「ｏｎ−ｐｌａｔｆｏｒｍ」）仮想マシン（４１）と呼ばれる、特別プラットフォーム（４０）を構成するカード内の部分（４１）とを含む。
【０００８】
かくして、特別プラットフォームの場合、アプリケーションのソースプログラム（２１）は、書き込まれ、コンパイラ（２２）により中間擬似コードとしてコンパイルされ、中間擬似コードのチェッカー（３１）により従来の局（２０）でチェックされてから、同じ局（２０）または別の局に配置されるコンバータ（３２）によりコンバートされる。その後、アプリケーションは、場合によっては、署名装置（３４）を通過した後で、携帯オブジェクトまたは特別プラットフォーム（４０）の揮発性プログラマブルメモリ、場合によってはＥＥＰＲＯＭ（１５）にダウンロードされる。こうしたローディングは、ダウンローダと呼ばれるプラットフォーム外の部分（３３）と、ローダと呼ばれる特別プラットフォームの一部（４２）とを含むローダによって行われる。局用に従来のプラットフォームで存在するものとは異なり、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）（４８）を備えたＲＯＭに配置される特別プラットフォーム（４０）の仮想マシン（４１）は、中間擬似コードチェッカーを含むことができない。このチェッカーは、携帯オブジェクトにおいて格納およびまたは実行するのに重たすぎるからである。特別プラットフォーム（４０）はまた、ダイナミッククラスローダも含まない。実際、本発明のアプリケーション領域の場合、オフプラットフォームの仮想マシン（３０）で、チェッカー（３１）は、コンパイルされたクラスが適切に形成されているかチェックし、特別プラットフォームの記述に特別な言語侵入があるかどうかチェックする。コンバータ（３２）は、クラスをローディングし、参照を分解するために必要な作業を行う。コンバータは、クラスのスタティックリンキングを実施し、カードに既に存在するクラス、メソッドおよび属性（アトリビュート）へのシンボル参照を解明する。コンバータは、ストレージを配分し、クラスを示すためのデータ構造を生成し、スタティックまたはネイティブのメソッドおよび属性を生成し、スタティック変数を初期化する。
【０００９】
特別プラットフォームの実行環境（Ｒｕｎｔｉｍｅ  ＥｎｖｉｒｏｎｍｅｎｔまたはＲＥ）は、インタープリタと、ＡＰＩプラットフォームと、いわゆる固有またはスタティックな関連メソッド（４３）とに限られた、組込仮想マシン（「ｏｎ−ｐｌａｔｆｏｒｍ」）（４１）を含む。ＡＰＩプラットフォームは、システムクラスと呼ばれるクラス（４５）の集合を決定するＡＰＩ（４４）と、アプリケーションが実行環境（ＲＥ）とスタティックメソッド（４３）とにアクセスする呼び出し協定（Ｃａｌｌ  Ｃｏｎｖｅｎｔｉｏｎ）とを含む。スタティックメソッド（４３）は、カードの入出力暗号メモリの割り当てサービスを実行する。
【００１０】
カード（４１）に組込された（ｏｎ−ｐｌａｔｆｏｒｍ）仮想マシンのインタープリタは、「Ｊａｖａ」言語をサポートする役割をし、中間擬似コードを命令毎に逐次読み込む。こうした中間擬似コードの各標準命令は、インタープリタによりマイクロプロセッサの言語で解釈されてから、マイクロプロセッサにより実行される。一般に、中間擬似コードの標準命令は、演算処理およびオブジェクト操作等の高級プログラミング言語を処理可能にする。オブジェクトの概念は、リスト、データリストまたは同等物等の情報オブジェクトに関する。アプリケーションのいわゆるクライアントクラス（４６）と、ＡＰＩのシステムクラス（４５）とは、全て同じメモリスペースにロードされ、クラステーブル（４７）を介して管理される。
【００１１】
仮想マシン（４１）は、また、クラスおよびオブジェクトを管理して、アプリケーション間の分離を遵守させることにより、属性、変数、またはフィールド（ｆｉｅｌｄｓ）とも呼ばれるデータの安全な共有を可能にする。
【００１２】
チップカードタイプの携帯オブジェクトの場合、特別プラットフォームのアプリケーションは、サービスまたは端末から送信される選択ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）がカードによって受信される場合、実行環境（ＲＥ）により直接作動可能である。
【００１３】
同じメモリスペースを共有するコード部分の間でデータへのアクセスを制限するために、従来のプラットフォームで一般的に行われている方法の一つは、ソースコードで宣言される可視性（ＶＩＳＩＢＩＬＩＴＥ）の明確な制限に基づいている。図４ｃによれば、メソッド（ＮＭ１、ＮＭ２；ＮＭ３、ＮＭ４）と属性（ＮＡ１、ＮＡ２；ＮＡ３、ＮＡ４）とは、それぞれクラス（ＮＣＩ３、ＮＣＩ２）に封入されている。クラスは、それ自体が、それぞれ複数のクラスをまとめたパッケージ（パッケージ１；パッケージｎ）の一部をなす。クラスは、パッケージに対して、（ＮＣＩ１またはＮＣＩ２）のようにパブリック（ｐｕｂｌｉｃ）であっても、（ＮＣＩ３）のようにプライベート（ｐｒｉｖａｔｅ）であってもよく、後者の場合、これは、同じパッケージのクラスだけがこのクラスにアクセス可能であることを意味する。クラス（ＮＣＩ３）のメソッド（例ＮＭ２）およびデータ（例ＮＡ１）は、クラス（ＮＭ２、ＮＡ１）に対してプライベートとすることができ、クラス自体が、パッケージ（パッケージ１）に対してプライベートであり、あるいはパッケージ（たとえばＮＭ１、ＮＡ２）またはクラス（たとえばＮＭ４、ＮＡ４）に対してパブリックである。こうした可視性の制限により、同じ名前空間で保存される様々なパッケージの集合（パッケージ１、パッケージｎ）の間でアクセスをフレキシブルにすることができる。だが、幾つかの欠点がある。従来の、または特別プラットフォームは、サブパッケージの概念を持つことができない。大型アプリケーションのクライアントクラスは、仮想マシンに対してだけは異なるパッケージを示す、様々なサブパッケージの間に配分しなければならない。これらのサブパッケージ間でリソースを共有するには、リソースがパブリックであると必ず宣言されることにより、他のあらゆるパッケージが、リソースを表示できるようにしなければならない。従って、大型アプリケーションに対して異なるアプリケーションのパッケージを明白に組織化し、アプリケーション間の分離を得ることは難しい。
【００１４】
局では、従来のプラットフォームの場合、ソースプログラムで宣言されたような、リソースの守秘性の遵守は、ダイナミックチェックに基づいている。こうしたダイナミックチェックを実行するには、仮想マシンが、各クラス、メソッドまたは属性に対するアクセス制限の宣言に関するあらゆる情報を持っていなければならない。これは、オフプラットフォームの仮想マシンの中間擬似コードまたは予め接続されたバイトコードを使用する組込（ｏｎｐｌａｔｆｏｒｍ）仮想マシンで利用可能なメモリスペースの場合、使用できない。携帯オブジェクトの特別プラットフォームの場合、アクセス制限は、コンパイル時にスタティックにチェック可能であり、オフプラットフォーム部分のチェッカーにより再びチェック可能である。実際、携帯オブジェクトの特別プラットフォームにロードされるものは正しいと仮定される。なぜなら、特別プラットフォームでは、コンバート段階時の情報ロスのために如何なるチェックも実行できないからである。しかも、パッケージが、外部のソースから送られる新しいクラスにより拡張または修正されないようにすることが保証されないので、プライベートパッケージの使用に基づくあらゆる安全性が損なわれる。
【００１５】
従来のプラットフォームの仮想マシンにより得られる第二の手段は、名前空間の分離という概念である。従来のプラットフォームのダイナミックリンキング構成では、クラスは、標準ＡＰＩプラットフォームを形成するシステムクラスの領域を構成するものとして予め宣言された「クラスパス（ＣｌａｓｓＰａｔｈ）」と呼ばれるローカルファイルシステムのディレクトリから、あるいは、ローカルファイルシステムまたは遠隔サーバの他のディレクトリから、ロード可能である。「クラスパス」外部のアプリケーションのクライアントクラスは、特別にプログラムされたクラスローダによりローディングされなければならない。この特徴は、有資格ブラウザ「Ｊａｖａ」によりアプリケーション「Ｊａｖａ」のローディングのために特に使用される。従って、様々なソースから送られるアプリケーションは、異なるクラスローダによりローディングされる。一般にＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）と呼ばれる各ロケータに対して、特別クラスインスタンス「アプリケーションクラスローダ」が使用される。クラスの外部の名称は、「パッケージの名称」＋「クラスの名称」の組み合わせである。クラスがロードされると、内部クラステーブルに保存され、このクラスをロードするために使用されたクラスローダに関する参照が、クラスのパッケージ名の接頭辞に付加される。クラスの名称は、その場合、「クラスローダの参照」＋「パッケージの名称」＋「クラスの名称」となる。かくして、同じパッケージに属していると宣言される一方で異なるクラスローダによりローディングされるクラスを、仮想マシンは、同じパッケージに属するものとして認識しない。
【００１６】
参照の解明時に、クラスローダの通常のやり方は、まずシステムクラスでサーチし、失敗した場合には、ローダがクラスをローディング可能な領域にあるクラスファイルの中をサーチすることである。ローダのこの動作原理によれば、アプリケーションは、異なるクラスローダによりローディングされた別のアプリケーションのクライアントクラスに直接アクセスすることができない。アプリケーションは、クラスパスのパブリッククラスのあらゆるパブリックリソースにアクセス可能である。しかし、クラスパスのクラスは、「クラスパス」で規定されるパブリックタイプとしてコンバートすることによりアプリケーションのクライアントクラスインスタンスに参照できるにもかかわらず、アプリケーションのクラスに直接アクセスできない。アプリケーションは、クラスパスのシステムクラスパッケージあるいは、異なるクラスローダによりローディングされた他のあらゆるアプリケーションパッケージを拡張もしくは修正することができない。「Ｊａｖａ」言語により供給される完全な類型化に加えて、クラスの名称にクラスローダの参照を挿入することにより名前空間の分離を使用すると、アプリケーション間の有効な分離が得られる。スペース名の元々の分離機構により、新しいアプリケーションを容易にローディングすることができる。アプリケーションは、このために特別にプログラミングされて「クラスパス」に配置されたクラスを介してオブジェクトを交換可能である。アプリケーションは、このオブジェクトが「クラスパス」で規定されるパブリックタイプに変更できる場合、異なるクラスローダによりローディングされる別のアプリケーションから送られたオブジェクトを使用することができる。
【００１７】
残念ながら、従来の仮想マシンとそのダイナミックリンキングプロセスとに基づいた、こうした名称分離機構は、特別なプラットフォームでしか実行することができない。特別プラットフォームの仮想マシンは、ダイナミックリンキングを実行することができないので、これは、解明されない参照を持った従来の「Ｊａｖａ」プラットフォームのクラスファイルを保存可能にするメモリスペースを要する。特別プラットフォームでは、ＡＰＩのシステムクラスと、アプリケーションのクライアントクラスは、個々の名前空間で分離されない。
【００１８】
本発明の目的は、スタティックリンキングの構成が、オフプラットフォーム部分で実行される、二つの部分からなる仮想マシンを備えた組込システムの範囲で名称分離の長所を得る解決方法を提案することにある。
【００１９】
支払い端末、マルチアプリケーション端末等の組込システムの状況では、各種の支払いシステム（ビザ、マスターカード．．．）等の様々なソースから供給される「Ｊａｖａ」アプリケーションの間で高性能の分離を有することが必要である。そのため、様々なソースから送られるアプリケーションの間でフレキシブルな協働を可能にすることが有効である。組込システムはまた、新しいアプリケーションまたは新しいユーティリティモジュールあるいは更新を、既にローディングされたアプリケーションを妨害せずにダウンロードすることにより容易に更新されなければならない。
【００２０】
本発明の第一の目的は、アプリケーションどうしを協働可能にし、アプリケーションを発達させ、あるいは他のアプリケーションをローディング可能にしながら、アプリケーション間をしっかりと分離し、ローディング方法を提案することにある。
【００２１】
この目的は、アプリケーションのソースコードが書き込まれ、コンパイラにより擬似コードとしてコンパイルされ、チェッカーによりチェックされ、コンバータによりコンバートされ、ローダによりロードされる局から、中間擬似コードタイプの言語のインタープリタを含む仮想マシンと、アプリケーションプログラミングインターフェース（ＡＰＩ）とを備えた実行環境を有する本発明による組込システムに、アプリケーションをローディングする方法により達せられ、
コンバートが、組込システムの同じ名前空間に保存するように構成された、モジュールと呼ばれる複数のパッケージの集合のスタティックリンキングの実施を含み、各モジュールに識別子（ＭＩＤ）を割り当て、モジュールのクラスに含まれる各クラス、各メソッド、および各属性に参照番号を割り当て、
モジュールにリンキングされる擬似コードにおけるメソッドまたは属性の参照が、モジュールの内部または外部クラスの参照と、クラス番号と、メソッド番号または属性番号とを示すインジケータからなる３バイトで符号化され、
モジュールは、それぞれが一つのアプリケーションに対応するシステムクラスまたはサービスモジュールを含む一つまたは複数のアプリケーションプログラミングモジュール（ＡＰＩモジュール）であり、外部クラスの参照が、アプリケーションプログラミングインターフェースモジュールの参照として仮想マシンにより系統的に解釈されることを特徴とする。
【００２２】
別の特徴によれば、組込システムへのモジュールのロードが、モジュールの少なくとも一つの表示リストの記憶を含み、０〜ｎのリンカにより番号を１個のモジュールに関連づけて、リストに前記モジュールのインデックスを構成し、また、前記モジュールの識別子（ＭＩＤ）への表示リストのインデックスの関連付けを記憶するテーブルの記憶を含み、前記リストおよびテーブルが、不揮発性プログラマブルメモリからなり、擬似コードにおける外部モジュールの外部参照が、仮想マシンのインタープリタにより、モジュールのリストのインデックスと同等のモジュールへのアクセスインデックスを構成するものとして解釈される。
【００２３】
別の特徴によれば、ロードが、各モジュールに対して、モジュールのインデックスの参照を含む、そのクラスの表示リストの記憶を含み、各クラスに対して、属性およびメソッドの表示リストとを含む。
【００２４】
別の特徴によれば、モジュールが、単一のモジュールリストで参照され、システムクラスが、単一のＡＰＩモジュールに含まれ、擬似コードにおいてｎとは異なる外部クラスへのあらゆる参照が、前記ＡＰＩモジュールの参照として擬似装置により解釈される。
【００２５】
別の特徴によれば、クラスが、パブリックであると宣言され、あるいはプライベートパッケージとして宣言され、属性およびメソッドが、プライベートパッケージまたはプライベートクラスとして保護されると宣言され、クラスの番号順が、パブリッククラス、次いでプライベートパッケージクラスの順に行われ、属性またはメソッドの番号順が、プライベートパッケージおよびプライベートクラスとして保護されるパブリックの属性またはメソッドの順に、コンバータにより行われる。
【００２６】
別の特徴によれば、システムクラスが、別々にロード可能な複数のＡＰＩモジュールに含まれ、ローダが、モジュールの２個の表示リストと、一方がＡＰＩモジュールに、他方が非ＡＰＩモジュールに対応する２個の関連づけテーブルＭＩＤ／Ｉｍｉとを、不揮発性プログラマブルメモリに保持し、ローダが、特別モジュールのヘッダにおける性質に応じて、２個のリストのうちの一方にモジュールをロードし、モジュールリストのモジュールのあらゆる外部参照が、ＡＰＩモジュールのインデックスの参照として解釈される。
【００２７】
別の特徴によれば、モジュールのスタティックリンキングは、中間擬似コードにおける非ＡＰＩモジュールの外部クラスへの参照が、モジュールのヘッダのリストにおけるインデックスであるように行われ、その各入力が、参照されたＡＰＩモジュールの識別子（ＭＩＤ）であり、ターゲットプラットフォームへの前記モジュールのローディングが、ＡＰＩモジュールの関連づけテーブルの識別子（ＭＩＤ）から得られるＡＰＩモジュールのインデックス番号による、前記参照の代替を含む。
【００２８】
本発明の別の特徴は、対応する組込システムを提案することにある。
【００２９】
この目的は、仮想マシンと、アプリケーションプログラミングインターフェースを含むＡＰＩプラットフォームと、不揮発性のＲＯＭと、不揮発性のプログラマブルまたは修正可能なメモリと、ＲＡＭとを含む本発明による組込システムにより達成され、不揮発性のプログラマブルメモリが、システムクラスおよびサービスモジュールを含む少なくとも一つのＡＰＩモジュールと、モジュールにインデックスをつけた少なくとも一つのモジュール表示リストと、前記モジュールの識別子に表示リストのモジュールのインデックスを関連づけるテーブルとを含み、各モジュールは、クラスにインデックスが付けられていて各クラスがそのモジュールのインデックスの参照を有するクラス表示リストを含み、各クラスは、属性およびメソッドにインデックスを付けた属性およびメソッドの表示リストを含み、メソッドまたは属性の参照が、モジュールの内部または外部クラスの参照に対応する少なくとも３バイトで符号化され、モジュールの外部参照が、モジュールリストでＡＰＩモジュールのインデックスを構成し、クラス番号が、モジュールのクラスの表示テーブルにおけるクラスのインデックスに対応し、メソッドまたは属性の番号が、モジュールのクラスのメソッドまたは属性の表示テーブルにおけるメソッドまたは属性のインデックスに対応する。
【００３０】
別の特徴によれば、メソッドまたは属性への参照を符号化する３バイトの第一のバイトと、所定値ｎとを比較して、内部クラスに関するか、外部クラスに関するかを決定する比較手段を含む。
【００３１】
別の特徴によれば、システムの主要プログラムを含む主要モジュールを有する。
【００３２】
別の特徴によれば、クラスが、パブリックのクラス、次いでプライベートパッケージクラスの順にインデックスを付けられ、属性またはメソッドが、パブリックの属性またはメソッド、保護された属性またはメソッド、プライベートパッケージの属性またはメソッド、およびプライベートクラスの順にインデックスを付けられる。
【００３３】
別の特徴によれば、不揮発性のプログラマブルメモリが、システムクラスと、一方がＡＰＩモジュール用で他方が非ＡＰＩモジュール用の２個のモジュール表示リストと、主要モジュールとを含む複数のＡＰＩモジュールと、それぞれがモジュール表示リストに対応する２個のＭＩＤ／ＩＭｉ関連づけテーブルとを含む。
【００３４】
別の特徴によれば、主要モジュールを介してサービスモジュールのインスタンスを生成可能なメソッドを含む、ＡＰＩモジュールのアクセス管理者クラス「アクセス・マネジャー」を含み、前記クラスが、１個以上のインスタンスを有することを禁ずる保護を備える。
【００３５】
本発明の別の目的は、マルチアプリケーション組込システムに存在するアプリケーションの実行方法を提案することにある。
【００３６】
この目的は、中間擬似コードタイプの言語のインタープリタを含む仮想マシンと、アプリケーションプログラミングインターフェース（ＡＰＩ）とを備えた実行環境を有する、マルチアプリケーション組込システムのアプリケーションの実行方法により達成され、モジュールの内部クラスまたは外部クラスと、クラス番号と、メソッドまたは属性番号との参照に対応する少なくとも３バイトで符号化された、擬似コードにおけるメソッドまたは属性の参照を、モジュールリストで参照する、一つのアプリケーションに対応するサービスモジュールの中間擬似コードの実行時に、モジュールの外部参照が、仮想マシンにより、一つまたは複数のＡＰＩモジュールのリストのＡＰＩモジュールのインデックスの参照として解釈されることを特徴とする。
【００３７】
別の特徴によれば、識別子を有するサービスモジュールの実行要求を受信すると、実行環境が、システムの主要プログラムを含む主要モジュールの入力クラスにアクセスし、主要モジュールが、サービスモジュールへのアクセスを管理するＡＰＩモジュールの特別クラス「アクセス・マネジャー」のインスタンスをインストールし、このクラスのメソッドを使用することにより、モジュールが参照されるリストでモジュールのインデックスに識別子を関連づけるテーブルを介して、要求されたサービスモジュールの入力クラスのインスタンスを生成可能にし、インスタンスが、このメソッドにより主要プログラムに戻される。
【００３８】
本発明の他の特徴および長所は、添付図面に関してなされた以下の説明を読めば、いっそう明らかになるであろう。
【００３９】
図１〜３に関して、限定的ではないが、たとえばチップカードまたは同様の携帯オブジェクトからなる特別なタイプの組込システムで本発明を実施する場合の方法について説明する。バイトコード表示またはバイトコードタイプのプログラムは、あらゆる擬似コードまたは中間プログラムをカバーする。
【００４０】
携帯オブジェクトは、たとえばチップカードを構成し、図４ａ、４ｂに関して先に説明した構造と同様の構造を有し、特に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭを含む。特別プラットフォーム（６０）および従来の局（８０）を図１に示した。特別プラットフォーム（６０）は、ＲＯＭに、ＡＰＩ（６２）と、組込された（「オンプラットフォーム」）仮想マシン（６１）とを含む、実行環境（ＲＥ）を有する。特別プラットフォーム（６０）は、ＲＯＭおよびＥＥＰＲＯＭの集合を含むものとして図１に示されている。特別プラットフォーム（６０）は、特に、実行環境（ＲＥ）と、ＥＥＰＲＯＭに存在する素子とを含むことに留意されたい。携帯オブジェクトは、ＲＯＭに、オペレーティングシステム（６３）を有する。ＲＯＭに存在するＡＰＩ（６２）は、ＡＰＩプラットフォームの基本ＡＰＩを構成し、組込された仮想マシンと共にローディングされ、仮想マシンを作動する。
【００４１】
仮想マシンの携帯オブジェクト外の部分（９０）は、中間擬似コードチェッカー（９１）、コンバータ（９２）、および場合によっては署名装置（９４）を含む。署名装置は、チェッカーおよびコンバータによる通過を有効にするために署名を送る。この署名は、ロードの瞬間に携帯オブジェクトによりチェックされる。基本ＡＰＩを補完するためのアプリケーションまたは新しいＡＰＩのＥＥＰＲＯＭへのローディングは、ローダにより行われる。ローダは、ダウンローダ（９３）と呼ばれる、携帯オブジェクト外の仮想マシン（９０）にインストール可能な携帯オブジェクト外の部分と、ローダ（６８）と呼ばれる特別プラットフォーム部分との二つの部分から構成可能である。
【００４２】
第一の実施形態によれば、特別プラットフォーム（６０）は、ＡＰＩモジュール（６５）と主要モジュール（６６）との二つの特別モジュールを含む。他のモジュールは、サービスモジュール（６７）と呼ばれる。各モジュールは、同じ名前空間に保存されるパッケージの集合に対応する。ＡＰＩプラットフォームは、基本ＡＰＩ（６２）と、ＡＰＩモジュール（６５）またはＡＰＩプラットフォームモジュールを決定するシステムクラスの集合とをさす。主要モジュールは、主要プログラムを決定する主要クラスを含む。ＡＰＩモジュール（６５）を除いた各モジュールは、モジュールへのアクセスポイントを構成する「エントリークラスＥｎｔｒｙ  Ｃｌａｓｓ」と呼ばれる特定の単独クラスを有する。主要モジュールに対しては、この「エントリークラス」が主要クラス（ＣＰ）であり、「メイン」と呼ばれるスタティックメソッドを含むクラスである。サービスモジュールに対しては、パラメータのない構成だけを有し、ＡＰＩプラットフォームで決定される「サービス」と呼ばれる特別パブリックインターフェースをインプリメントするクラスである。アプリケーションのローディングは、サービスモジュールのローディングに対応する。各モジュールは、特別識別子を受信する。ＭＩＤと呼ばれるこのような特別識別子は、たとえば数、文字列、またはリストとすることができる。例として、識別子は文字列である。
【００４３】
特別プラットフォームの仮想マシンとは異なるダウンロード機構によりプラットフォームにロードされる場合、モジュールは０〜ｎの数を受信する。かくして、この協定によれば、最大でもｎ＋１個のモジュールが、特別プラットフォームに存在することができる。ローダ（６８）を備えるモジュールのダウンローダ（９３）は、新しいサービスモジュールのローディング時に、モジュールの表示リスト（ＴＲＭ）（６９）を保持する。モジュールに関連づけられる番号は、リスト内のこのモジュールのインデックス（ＩＭ）である。ローダ（６８）はまた、各モジュールの識別子（ＭＩＤ）にインデックス（ＩＭ）を関連づけるテーブル（７０）を保持する。ＡＰＩモジュールは、インデックスＩＭ０に対して系統的に番号０を受信し、主要モジュールは、インデックスＩＭ１に対して番号１を受信する。各モジュールのヘッダ（ｈｅａｄｅｒ）は、モジュールの性質が、「主要」モジュールであるか、「サービス」モジュールであるか、あるいは「ＡＰＩ」モジュールであるか決定する。
【００４４】
ローダ（６８）は、携帯オブジェクトに留まることを許可されたモジュール、すなわち、携帯オブジェクトが知っている署名を持つモジュールだけをロードすることができる。従って、ローダ（６８）は、受信モジュールの署名をチェックし、携帯オブジェクトの既知の署名と比較し、比較が否定的である場合はローディングをブロックする手段を含む。
【００４５】
一般に、上記の従来技術で規定されたように、アプリケーションのソースプログラム（８１）が書き込まれ、次いでコンパイラ（８２）によりコンパイルされてから、チェッカー（９１）によりチェックされる。
【００４６】
コンバータ（９２）でコンバータのリンカーと呼ばれるコンポーネントにより実施されるスタティックリンキングは、
−モジュールの各クラスに番号（ＮＣＩ）を、
−クラスの各メソッドのために番号（ＮＭ）を、
−クラスの各属性のために番号（ＮＡ）を、割り当てることによってシンボル参照を解明する。
【００４７】
これらの番号（ＮＣＩ、ＮＭ、ＮＡ）は０〜ｎであり、バイトで示すことができる。たとえば、各数は０〜２５５（ｎ＝２５５）である。クラスのメソッドまたは属性の参照は、このように、２バイトでモジュールのメソッドにリンキングされる擬似コードで符号化される。擬似コードは、これらの２バイトのクラス用「ＮＣＩ」、属性用「ＮＡ」、あるいはメソッド用「ＮＭ」を含む。
【００４８】
図３によれば、ＡＰＩモジュール（６５）、主要モジュール（６６）またはサービスモジュール（６７）の内部表示が、クラス表示リスト（ＴＲＣ）を含む。組込システム外でリンカーにより各クラスに関連づけられる番号（ＮＣＩ）は、クラス表示リスト（ＴＲＣ）におけるこのクラスの表示のインデックス（ＩＣｉ）である。各クラスはまた、モジュールのインデックス（ＩＭｉ）への参照を有する。同様に、各クラスの表示は、メソッド表示リスト（ＴＲＭｅ）と、クラスに属する属性表示リスト（ＴＲＡ）とを含む。組込システム外でリンカーにより各メソッドに関連づけられる番号（ＮＭ）は、メソッド表示リスト（ＴＲＭｅ）におけるこのメソッドの表示のインデックス（ＩＭｉ）であり、組込システム外でリンカーにより各属性に関連づけられる番号（ＮＡ）は、属性表示リスト（ＴＲＡ）におけるこの属性の表示のインデックス（ＩＡｉ）である。
【００４９】
たとえば、システムクラスが、従来のプラットフォームの「クラスパス」のクラスに対応するとき、モジュールが、その固有のクラスと、ＡＰＩプラットフォームのシステムクラスとだけを参照できるようにしようとする。本発明によれば、モジュールの内部クラスの参照と、システムクラス（またはモジュールの外部クラス）の参照とを区別可能にするために、内部（ＩＩ）または外部（ＩＥ）インジケータが、メソッドまたは属性の参照に付加される。解明される参照は、その場合、「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＭ」または「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＡ」の３バイトで符号化される。
【００５０】
上記の協定によれば、第一のバイト「ＩＥ／ＩＩ」の値ｎに対して、例では２５５であるこの値が、モジュールの内部参照「ＩＩ」に対応し、第一のバイトのための他のあらゆる値が、モジュールの外部参照「ＩＥ」に対応する。
【００５１】
携帯オブジェクト外の仮想マシン（９０）のコンバータ（９２）のリンカーは、擬似コード内に外部参照「ＩＥ」を持たないＡＰＩモジュール（６５）を第一にリンキングし、クラスとメソッドおよび属性とのシンボル名のプランに対応して、配置または構成を生成する。他のモジュールのリンキング時には、この配置を用いて、ＡＰＩモジュール（６５）のシステムクラスへの外部参照を設定する。
【００５２】
参照をエンコードする本発明のバイト協定によれば、ＡＰＩモジュールには最大で２５６（ｎ＋１）個のクラスがあり、各追加モジュールには２５６個のクラスがある。
【００５３】
サービスモジュールの実行時には、仮想マシン（６１）が、参照があるクラス「ＮＣＩ」を知って、擬似コードにおけるメソッド「ＮＭ」または属性「ＮＡ」を参照するとき、仮想マシンは、関与するモジュールのインデックス「ＩＭｉ」を直接見つけることができ、このモジュールは、外部参照（ＩＥ）または内部参照（ＩＩ）に対応する。サービスモジュールの擬似コードにあるあらゆる外部参照（ＩＥ）は、ＡＰＩモジュールの参照として仮想マシンにより系統的に解釈される。サービスモジュールまたは主要モジュールは、ＡＰＩモジュールのクラスを除いて、他のあらゆるモジュールのクラスを参照することができない。このＡＰＩモジュールのシステムクラスは、サービスモジュールまたは主要モジュールのクラスを参照することができない。第一のバイトに対して値ｎに対応するモジュールのクラスの内部参照は、モジュールに割り当てられる名前空間を先験的に知っている必要は少しもない。コンバート段階の時に固定名前空間を先験的に決定しないことにより、参照の解明を加速し、コンバート段階後のローディング時にモジュールの名前空間を決定することができる。仮想マシンは、擬似コードにおける属性またはメソッドの参照の解釈時に、連続した３個のインデックス「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＭ」または「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＡ」を使用する。モジュールのメモリスペースは決定されているので、インデックス「ＮＣＩ」は、モジュールのクラスリスト（ＴＲＭ）における所望の入力を決定し、次いで、最後のインデックス「ＮＭ」または「ＮＡ」画、メソッドリスト（ＴＲＭｅ）または属性リスト（ＴＲＡ）に所望の入力を与える。
【００５４】
ＡＰＩモジュールは、「アクセスマネジャー」クラスと呼ばれる特別クラス（６４）を含み、このクラスは、モジュールの識別子（ＭＩＤ）から、要求されたサービスモジュールの入力クラスのインスタンスオブジェクトを返す役割をする固有のメソッド（ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ）を含む。このメソッドは、モジュールリスト（６９）で要求されるモジュールのインデックスを知るためにＭＩＤ／ＩＭｉ関連づけテーブル（７０）を使用し、次いで、このモジュールの入力クラスのインスタンスを生成し、このメソッドによってインスタンスを返す。本発明によれば、「Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ」クラス（６４）は、このクラスが１個以上のインスタンスを有することを禁ずることからなるメソッドにより、設計上、保護される。固有のメソッド（ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ）は、主要モジュールに含まれる主要プログラムに属する。携帯オブジェクトの使用時に最初に作動される主要モジュールは、１個のインスタンスと、１個の「アクセス・マネジャー」クラスとを生成するので、このモジュールは、ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅメソッドを使用可能であるが、他のあらゆるサービスに対しては、このメソッドを使用するための他のインスタンスの生成が禁じられる。
【００５５】
実行環境（ＲＥ）は、作動時に、従来のプラットフォームと同様に、主要モジュールの入力クラス（ＥＣ）にアクセスし、入力メソッド（メイン）を作動する。主要モジュールは、最初に作動されるので、他のあらゆるサービスより前に「アクセス・マネジャー」クラスのインスタンスをインストールする。何故なら、主要モジュールは、他のサービスを作動するために、アクセスクラスのこのようなインスタンスを既に持っていなければならないからである。
【００５６】
こうした単純な装置により、従来のプラットフォームの名前空間の概念に結合される保護効果を再生することができる。モジュールリストにサービスモジュールをローディングし、擬似コードにおける全ての外部参照の存在を仮想マシンがＡＰＩモジュールの参照として解釈するという簡単なことから、このモジュールは、他のモジュールから直接アクセスされることが全くなくなり、完全に分離される。
【００５７】
上記の第一の実施形態により、２つの部分からなる仮想マシンという状況で名前空間の分離により分離（ＰＡＲＥ−ＦＥＵ）が得られるいう長所が得られる。しかしながら、この実施形態は、フレキシブルでなく、次のような２つの欠点を有する。
【００５８】
第一に、既に予めリンキングされたモジュールにより、システムクラスのあらゆる修正または拡張が妨げられる。従来の「Ｊａｖａ」アーキテクチャは、追加モジュールの既にコンパイルされたクラスに影響を与えることなくＡＰＩプラットフォームのクラスを修正かつ拡張することができる。だが、上記の実施形態では、システムクラスのあらゆる修正は、異質のモジュールに対しては表示されないものであっても、ＡＰＩプラットフォームの構成を修正してしまい、構成の従来バージョンに既にリンキングされた各モジュールの、予めリンキングされた擬似コードを修正するので、従ってインタープリタを修正することが必要になる。
【００５９】
第二に、予めリンキングされたモジュールは、組込された様々なプラットフォームまたは端末間で携帯であると仮定されるので、これらのプラットフォームの各々が、ＡＰＩプラットフォームと同じ構成を持たなければならなくなり、あらゆる所有者の拡張使用が禁じられる。
【００６０】
これらの欠点を部分的に解消するために、第一の実施形態の変形実施形態は、配置の番号順において、最初にパブリッククラスがきて、プライベートパッケージクラスの前にくるように課すことからなる。さらに、パブリックのメソッドまたはパブリックの属性が、保護されるメソッドまたは属性と、プライベートパッケージおよびプライベートクラスにあるメソッドまたは属性の前に来る。これにより、ＡＰＩモジュール（６５）に新しいパブリッククラスを自由に付加することができる。
【００６１】
図２は、ＡＰＩプラットフォームを発展させることができる第二の実施形態を示す。ＡＰＩプラットフォームは、単一のＡＰＩモジュールから構成される代わりに、別々にロード可能な複数のＡＰＩモジュール（１００）から構成される。
【００６２】
この実施形態では、ダウンローダ（９３）と仮想マシンとが、１個につき１個ではなく、サービスモジュール（６７）および主要モジュール（６６）に対応して、ＡＰＩモジュールに対しては、リスト（１０１）および関連づけテーブル（１０２）、非ＡＰＩモジュールに対しては、リスト（１０３）および関連づけテーブル（１０４）の、２個のモジュールリストと、２個のＭＩＤ／インデックス関連づけテーブルとを共有している。
【００６３】
各モジュールは、そのヘッダに、性質を示すインジケータ「サービス」または「ＡＰＩ」を有し、ＡＰＩモジュールのリスト（１０１）または非ＡＰＩモジュールのリスト（１０３）にローダがモジュールをローディングできるようにする。このインジケータは、コンバータによるコンパイル段階の際に、モジュールのヘッダに配置される。
【００６４】
名前空間の分離からなる分離（ＰＡＲＥ−ＦＥＵ）は、非ＡＰＩモジュールの間にのみ存在する。サービスモジュールへのあらゆる外部参照は、ＡＰＩモジュールのリストのインデックスとして、組込された仮想マシンのインタープリタにより解釈される。
【００６５】
非ＡＰＩモジュールは、ｎ＝２５５の例では、０から最大２５５まで番号を付けられ、０は、たとえば主要モジュール（６６）のインデックスである。ＡＰＩモジュール（１００）は、０から最大２５４まで番号を付けられ、０は、たとえば、いわゆるプライマリＡＰＩモジュールのインデックスであり、あらゆる固有のメソッドを含む。上記の協定によれば、これにより、ＡＰＩプラットフォームでは、最大２５５（ｎ）個の異なるモジュールが容認される。擬似コードにおけるメソッドまたは属性の参照は、次のようになる。
【００６６】
「「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＭ／ＮＡ」」
第一のバイトに対する値２５５（ｎ）は、第一の実施形態と同様に、モジュールの内部参照を示す。２５５とは異なる各値は、ＡＰＩプラットフォームのＡＰＩモジュールリストの、特別モジュール（１００）の外部参照を示す。
【００６７】
オフプラットフォームのリンカー（９２）によりリンキングが実施された後で、モジュールの擬似コードは、現行のモジュールをリンキングするために使用される参照モジュールリストを有するヘッダを含む。参照モジュールリストは、最大２５５個の入力を含み、各入力が、ＡＰＩモジュール（１００）の識別子（ＭＩＤ）に対応する。その場合、擬似コードにおける外部参照の第一のバイトは、このリストにおけるインデックスである。非ＡＰＩモジュールのプラットフォーム（６７、６６）にローディングする際、ＡＰＩモジュール（１００）に関連づけられるインデックス番号は知られているので、外部参照の第一の各バイトは、ＡＰＩモジュール（１００）のＭＩＤ−ＩＭｉ関連づけテーブル（１０２）を使用することにより、参照されたＡＰＩモジュールに関連づけられるインデックス番号に代えられる。こうした代替は、特別プラットフォームでローダ（６８）により実施される単独リンキング操作であり、ＭＩＤ／ＩＭｉ関連づけテーブル（１０２）は、このリンキング操作を実施するためにのみ使用される。
【００６８】
たとえば、サービスモジュール「ＴＥＳＴ」の擬似コードにおいて、ＡＰＩモジュールのクラス番号７のメソッド番号５を参照し、識別子（ＭＩＤ）が「Ｆ００」であるとする。さらに、「Ｆ００」が、サービスモジュール「ＴＥＳＴ」で参照された第四のＡＰＩ外部モジュールの識別子であるとする。その場合、擬似コードにおける参照は、３つの値３、７、５から構成される。
【００６９】
番号３は、擬似コードの冒頭に送られる、モジュールのヘッダに存在する参照モジュールリストにおいて、第四のインデックスに対応し、この入力の値は識別子（ＭＩＤ）「ＦＯＯ」である。ＡＰＩモジュール「ＦＯＯ」のローディング時に、内部インデックス３４が、ＡＰＩモジュールの関連づけテーブル（１０２）でターゲットプラットフォームに割り当てられたものと仮定する。その場合、ローダ（６８）は、関連づけテーブル（１０２）を用いて、サービスモジュール「ＴＥＳＴ」の擬似コードで参照を修正し、３４、７、５になるようにする。
【００７０】
モジュールの擬似コードの実行時に、モジュールの外部リファレンスは、仮想マシンにより、ＡＰＩモジュールテーブルにおける入力として系統的に解釈される。非ＡＰＩモジュールリストのモジュールは、互いに、またＡＰＩモジュールに対して、非表示である。こうした単純な装置により、従来のプラットフォームの名前空間の概念に結合される保護効果を再生することができる。非ＡＰＩモジュールリストにモジュールをローディングするという簡単なことによって、このモジュールは、他のモジュールから直接アクセスされることが全くなくなり、完全に分離される。
【００７１】
ＡＰＩモジュールのリスト（１０１）は、「ＡＰＩアクセス」モジュールと呼ばれる特別モジュール（１０５）を含む。このモジュールは、要求されたサービスモジュールの入力クラスのインスタンスオブジェクトを返す役割をする固有のメソッド（ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ）を含む。このメソッドは、非ＡＰＩモジュールリスト（１０３）で要求されるサービスモジュールのインデックスを知るためにＭＩＤ／ＩＭｉ関連づけテーブル（１０４）を使用し、次いで、このモジュールの入力クラスのインスタンスを生成し、主要プログラムのメソッドにより、このインスタンスを返す。勧められる安全なやり方は、「アクセス・マネジャー」クラスから、設計者およびメソッドが保護されていると宣言される保護クラスを形成することにある。さらに、「ＡＰＩアクセス」モジュール（１０５）は、「アクセス・マネジャー」クラスが１個より多くのインスタンスを有することを禁ずることからなる保護を含む。このメソッドは、主要モジュール（６６）で得られる主要プログラム専用である。最初に作動される主要モジュールは、アクセスマネジャーモジュールのインスタンスを生成するので、このモジュールは、ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅメソッドを使用できるが、他のあらゆるサービスは、このメソッドを使用するための他のインスタンスの生成を禁じられる。かくして、主要モジュールは、サービスインスタンスを生成することができる。
【００７２】
「アクセス・マネジャー」クラスが１個のインスタンスしかもたないことを禁じることからなる、こうした保護を得るために、複数の方法が使用可能である。クラスの設計者は、たとえば既に一つが存在する場合、インスタンスの生成要求をブロック可能であり、安全例外をスタートする。実行環境（ＲＥ）は、動作上、主要モジュール（６６）の入力クラスにアクセスし、入力メソッド（メイン）を作動する。主要モジュールは、最初に作動されるので、他のあらゆるサービスの前に「アクセスマネジャー」クラスのインスタンスをインストールする。
【００７３】
サービスモジュールが、他のサービスモジュールを作動できるようにするために、こうした厳しい安全方策を変更して、ＡＰＩアクセスモジュール（１０５）の「アクセス・マネジャー」クラスにパブリッククラスを付加し、あらゆるモジュールがそこで要求を行えるようにしてもよい。これらのパブリッククラスは、特に、単一のインスタンスを得られるスタティックメソッドを含む。「アクセス・マネジャー」クラスのインスタンスオブジェクトにアクセスするモジュールは、別のサービスモジュールを作動し、これを使用することができるが、そのクラス、メソッドまたは属性を直接参照するには、仮想マシンによる参照が必要である。何故なら、擬似コードにおける全ての外部参照は、このモジュールの内部参照またはＡＰＩモジュールの外部参照であるからである。
【００７４】
この解決方法を簡単に実施するには、ＡＰＩモジュールの中で循環的な参照を持たないようにすることが必要である。従って、「に参照する（「ｒｅｆｅｒｓ  ｔｏ」）」という関係の一時的な閉鎖は、モジュールセットで部分的に逆の成り立たない順序でなければならない。従って、コンバータ（９２）のリンカーにおいて、まだリンキングされていない最低限の素子を最初に処理することによってＡＰＩモジュールの構成を結合および生成するための簡単な政策を、コンバータ（９２）のリンカで設計することができる。ＡＰＩモジュールのダウンロードに対しても、部分的な順序に基づいた同じ政策に従うことができるので、モジュールＭのダウンロード時に、参照する全てのモジュールが既に全てダウンロードされており、それらに番号が割り当てられている。ターゲットプラットフォームにおける内部インデックスの割り当ては、ｎ次のＡＰＩにインデックスｎ−１を割り当てることにより、モジュールのローダ（６８）によってなされる。ＡＰＩモジュールは、それよりも大きいインデックスを持つ別のＡＰＩモジュールを参照することができない。
【００７５】
モジュールリスト（１０１、１０３）および関連づけテーブル（１０２、１０４）を二重にしたこのシステムの使用により、単一のＡＰＩモジュールを別々にロード可能な複数のＡＰＩモジュールにより簡単に代替可能である。単一のＡＰＩモジュールを複数のＡＰＩモジュールに代えることにより、既にロードされたモジュールの組立を変えずに、また分離により提供される安全性を変えずに、新しいモジュールでＡＰＩプラットフォームを拡張することができる。もちろん、この二つの実施形態は、相容れるものではない。モジュールは、実施形態のいずれかに対して特別に、予めリンキングされていなければならず、一方の実施形態に関する擬似コードは、他方の実施形態をインプリメントするプラットフォームではサポートされない。しかも、仮想マシンのインタープリタは、実施形態どうして異なる。第一の実施形態では、仮想マシンが、１個のリストと１個の関連づけテーブルだけを操作する。参照の第一のバイトは、仮想マシンにより、ｎに等しい全ての値に対して内部参照として解釈され、ｎとは異なる全ての値に対して単独ＡＰＩモジュールの外部参照として解釈される。第二の実施形態では、仮想マシンは、２個のリストと２個の関連づけテーブルとを操作する。擬似コードにおける参照の第一のバイトは、仮想マシンにより、ｎに等しい全ての値に対して内部参照として解釈され、ｎとは異なる全ての値は、ＡＰＩモジュールリストにおけるインデックスとして直接考慮される。二つの実施形態では、仮想マシンのインタープリタが、一つのメソッドまたは属性の参照を符号化した３バイトの第一のバイトと、所定値ｎとを比較し、モジュールの内部クラスに関するか、外部クラスに関するかを決定する。ＡＰＩモジュールの番号順は、ローディング次に決定され、それによって、最終的に、またきわめて簡単に、擬似コード内の外部参照を固定することができる。
【００７６】
使用されるメソッドおよび得られる安全性が全く異なるが、二つのタイプのモジュールを操作するために同じ機構が使用される。全てのモジュールは、クラスがシステムクラスであるのでＡＰＩモジュールに自由にアクセスできる。モジュールで構成されたアプローチの使用は、あらゆる直接アクセスからこれらのモジュールを保護する厳密な分離を得るために、サービスモジュールと共に使用される。
【００７７】
本発明による方法は、たとえば１６ｋｏのＲＯＭ、８ｋｏのＥＥＰＲＯＭ、２５６ｋのＲＡＭといった、リソースの小さいあらゆるタイプの形態オブジェトで実現可能である。
【００７８】
当業者が理解できる他の修正が、同様に、本発明の意図の一部をなす。
【図面の簡単な説明】
【図１】  第一の実施形態による形態オブジェクトのローディングに必要な各種の素子を概略的に示す図である。
【図２】  第一の実施形態による形態オブジェクトのローディングに必要な各種の素子を概略的に示す図である。
【図３】  モジュールの内部を示す図である。
【図４ａ】  チップカードの従来の構成を示す図である。
【図４ｂ】  従来技術によりチップカードに組込した仮想マシンの構成に必要なシステムを示す図である。
【図４ｃ】  アプリケーションのクラスの構造を示す図である。
【図１】
0003689368.tif 000002
【図２】
0003689368.tif 000003
【図３】
0003689368.tif 000004
【図４ａ】
0003689368.tif 000005
【図４ｂ】
0003689368.tif 000006
【図４ｃ】
0003689368.tif 000007