JP2013030175A - 小面積装置において実行時環境特権を使用してコンテキスト障壁を横断するアクセスを許可する技術 - Google Patents

Abstract

【課題】スマート・カードなどの小面積装置において、プログラムの実行を隔離するコンテキスト障壁を含むことにより、関係の無いベンダーからの複数のプログラムを安全に実行する構成を提供する。
【解決手段】コンテキスト障壁が、プリンシパル及びオブジェクトが同じコンテキスト内にあるか、又は要求されたアクションが操作されるべきオブジェクトに対して認証されているかを検査するセキュリテイ検査を実行する。各プログラム又は１組のプログラムは分離されたコンテキスト内で実行される。しかし、１つのコンテキストがコンテキスト障壁の制約無く、全てのプログラム・モジュールにアクセスできる。
【選択図】図１４

Description

関連出願の相互参照
本出願は、１９９７年４月１５日に出願された米国特許出願シリアル番号０８／８３９．６２１、発明の名称「セキュリテイ分配バイト・コード確証を有する仮想マシン」、発明者モシュ・レビイとジュデイ・シュワブ（ドケット番号５０２５３−２２１／Ｐ３２６３）の関連出願である。

本出願は、１９９９年１月２２日に出願された米国特許出願シリアル番号０９／２３５．１５８、発明の名称「小面積装置においてコンテキスト障壁を使用してセキュリテイを実施する技術」、発明者ジョシュア・スーサーとミシェル・ビー・バットラー及びアンデイ・ストレイヒ（ドケット番号５０２５３−２１６／Ｐ３７０８）の関連出願でもある。

本出願は、１９９９年１月２２日に出願された米国特許出願シリアル番号０９／２３５．１５５、発明の名称「小面積装置において入口点オブジェクトを使用してコンテキスト障壁を横断するアクセスを許可する技術」、発明者ジョシュア・スーサーとミシェル・ビー・バットラー及びアンデイ・ストレイヒ（ドケット番号５０２５３−２１７／Ｐ３７０９）の関連出願でもある。

本出願は、１９９９年１月２２日に出願された米国特許出願シリアル番号０９／２３５．１５６、発明の名称「小面積装置においてグローバル・データ構造を使用してコンテキスト障壁を横断するアクセスを許可する技術」、発明者ジョシュア・スーサーとミシェル・ビー・バットラー及びアンデイ・ストレイヒ（ドケット番号５０２５３−２１９／Ｐ３７１１）の関連出願でもある。

本出願は、１９９９年１月２２日に出願された米国特許出願シリアル番号０９／２３５．１５９、発明の名称「小面積装置において共有可能インターフエイスを使用してコンテキスト障壁を横断するアクセスを許可する技術」、発明者ジョシュア・スーサーとミシェル・ビー・バットラー及びアンデイ・ストレイヒ（ドケット番号５０２５３−２２０／Ｐ３７１２）の関連出願でもある。

発明の背景
発明の属する技術分野
本発明は、コンピュータ・セキュリテイに関し、より詳細には、スマート・カードなどの小面積装置にセキュリテイを施す技術に関する。

従来の技術
いくつかのオブジェクト指向プログラミング言語が、当業者に良く知られている。これらの例は、Ｃ＋＋言語及びスモールトーク言語を含む。

別のこのようなオブジェクト言語は、ジャバ（ＪＡＶＡ）（登録商標）言語である。この言語は、アディソン−ウェズレイから出版されたジェームス・ゴスリング等による本、「ジャバ（商標）言語仕様」に記載されている。ジャバ（商標）言語は特に、ジャバ（商標）仮想マシン上で動作するのに適している。このようなマシンが同じくアディソン−ウェズレイから出版されたティム・リンドホルム及びフランク・イェリンによる本、「ジャバ（商標）仮想マシン」に記載されている。

いくつかの小面積装置が当業者には良く知られている。これらの小面積装置は、スマート・カード、セルラー・ホン、及びその他の小面積又はミニアチュアの装置を含む。

スマート・カードは、形と大きさがクレジット・カードに似ているが、典型的に、カード中にデータ処理機能及びそれを介してスマート・カードとプログラム、データ、その他の通信を達成する１組の接点を含む。典型的に、１組の接点は、クロック入力、リセット入力及びそれを介してデータ通信が達成できるデータ・ポートと、電源接続と、戻りとを含む。

カード受入装置を使用して、情報がスマート・カードに書込まれ、そしてスマート・カードから読み出される。カード受入装置は典型的に、ホスト・コンピュータに取付けられた周辺装置であり、スマート・カードがその中に挿入できるスロットなどのカード・ポートを含む。一旦、挿入されると、コネクターからの接点又はブラシがスマート・カードの表面接続領域に当接して、電源を供給し、そして、スマート・カード上に典型的に見出されるプロセッサー及びメモリとの通信を許容する。

スマート・カード及びカード受入装置（ＣＡＤ）は、広範囲な標準化努力、例えば、ＩＳＯ７８１６、の主題である。

フアイヤウォールを使用して、認証されたユーザを認証されていないユーザから分離することは、ネットワーク環境では良く知られている。このようなフアイヤウォールは、発明者デビッド・ブランウェルの名前で１９９８年１２月１日に出願された米国特許出願シリアル番号０９／２０３，７１９、名称「認証されたフアイヤウォール通過フレームワーク」（ドケット番号５０４３５−０２３／Ｐ２７８９／ＴＪＣ）に記載されている。

完全なジャバ（商標）プラットホームの能力の小組が、スマート・カードなどの小面積装置のために定義されている。この小組は、ジャバ・カード（商標）プラットホームと呼ばれている。ジャバ・カード（商標）プラットホームの使用は以下の刊行物に記載されている。

ジャバ・カード（商標）２．０−−言語セット及び仮想マシン仕様 ジャバ・カード（商標）２．１−−アプリケーション・プログラミング・インターフエイス ジャバ・カード（商標）２．０−−プログラミング・コンセプト ジャバ・カード（商標）アプレット開発者ガイド ＩＳＯ７８１６−−部分１１の作業ドラフトが、批評を受けるため回覧されている。そのドラフトは、スマート・カード上で動作するための別の実行コンテキストを可能にする標準を特定している。

実行コンテキストの一般概念はコンピュータ科学では良く知られている。一般に、計算環境内で複数実行コンテキストを使用することは、各々が他から不適当な干渉無しに動作できるように、互いに異なるプログラム・モジュール又はプロセスを分離又は隔離するための方法を提供する。異なるコンテキスト間の相互作用はもしあれば、偶然というよりは熟考されて、各コンテキストの完全性を保全するために注意深く制御される。複数コンテキストの一例が、複数の仮想マシンが定義されて、各仮想マシンがそれ自身の実行コンテキストを有すメインフレームなどのより大きなハードウェア装置に見られる。別の例として、発明者デジョングの米国特許番号第５，８０２，５１９号が、スマート・カード上での複数実行テキストの使用を開示している。当業者には理解されるように、複数実行コンテキストを提供する計算環境はさらにある与えられた実行コードとそれに対応するコンテキストとを関連付けるための機構を与える必要がある。

現在コンテキストも周知の一般概念である。複数コンテキストを支援するある計算環境は、いかなる時点において、１つのコンテキストを特に計算の能動的集中として取扱う。このコンテキストは「現在コンテキスト」と呼ばれる。その他のあるコンテキストが現在コンテキストとなるために、現在コンテキストが変化する時、「コンテキスト切換え」が発生すると言われる。当業者には理解されるように、これらの計算環境は、コンテキスト切換えを容易にするため、どのコンテキストが現在のものであるかを記録するための機構を提供する。

従来技術において、小面積装置の世界、特に、スマート・カードの世界においては、小面積装置上で動作するコンテキスト間の相互動作は存在しなかった。各コンテキストは完全に分離されて動作し、そして異なるコンテキスト中の他のアプリケーション又はプロセスに影響を与えることなく、そのコンテキスト空間内で動作又は故障する。

ジャバ（商標）プラットホームに用いられるセキュリテイ保護の１つの層は普通、砂箱モデルと呼ばれる。信用されないコードは「砂箱」内に置かれて、完全なジャバ（商標）環境又は「現実世界」にどんな損傷も与えることなく、安全に「遊ぶ」ことができる。このような環境において、ジャバ（商標）アプレットは通信をせず、しかし、各々はそれ自身の名前の空間を有する。

いくつかのスマート・カードのオペレーティング・システムは実行コンテキストが直接に通信することを許さず、オペレーティング・システム又はサーバーを介しての通信を許す。

問題
小面積装置上にコンピュータ・プログラム及び他の情報を置くことを試みる時、いくつかの問題が存在する。１つの大きな問題は大変に制限されたメモリ空間の存在である。これはしばしば必要な機能をメモリ空間内に与えるために非常に大きな努力を要する。

小面積装置に関連した第２の問題は、異なる小面積装置の製造業者は異なるオペレーテイング・システムを使用することができるという事実である。この結果、１つのオペレーテイング・システムのために開発されたアプリケーションは必ずしも、異なる製造業者により製造された小面積装置にポータブルではない。

もし、複数のプログラム・ソース（製造業者又はベンダー）からのプログラムが１つの小面積装置に適用されるならば、セキュリテイが、新しいプログラムをその小面積装置にロードする時に、既存のプログラム及びデータの劣化を回避する１つの試みとしてのファクターとなる。同じ関心が、ハッカー又は悪意ある人間がプログラム及びデータをアクセスすることを防ぐ時に、存在する。

スマート・カードなどの小面積装置は、分離した仮想マシンを実現するために必要な資源を有しないことは明らかである。それにもかかわらず、別個の実行コンテキスト間で厳格なセキュリテイを維持することが望まれる。

従来は、セキュリテイが、スマート・カード又はその他の小面積装置上に同じソース又は既知の信頼されるソースからのアプリケーションのみがロードされることにより与えられていた。

従って、プログラマーに不適当な重荷を課さない高速で効率的なピア・ツー・ピア通信を介した安全な方法のみにより選択された実行コンテキスト間のオブジェクト指向相互作用を可能にし、しかし、信用できないソースにより異なる時に書かれたアプレットの動的なローディングを容易にすることが望まれる。

発明の開示
本発明は、１つのコンテキストを他から隔離及び分離を与えるためのコンテキスト障壁（時々、フアイヤウォールと呼ばれる）を提供し、必要な時に障壁を横断して制御されたアクセスを提供することに関する。

本発明によれば、例えば、各々が１又は複数のアプレットを含み、同じ論理（すなわち、仮想又は現実）マシンで実行され、互いに保護された、２つの実行コンテキストが、オブジェクト指向言語機構などの言語機構を使用して、制御された安全な方法で情報を共有できる。例えば、セキュリテイはオブジェクトごとにできる。このように、第１実行コンテキスト内のメソッドは第２実行コンテキスト内の第１オブジェクトＡにアクセスすることができるが、第２実行コンテキスト内の第２オブジェクトＢには選択的なベースでアクセスできない。

１つの例示的な実施の形態によれば、増強されたジャバ（商標）仮想マシン（ＶＭ）は、ＶＭ内で実行コンテキストを横断するアクセスの試みについてある実行時検査を提供する。検査は、ＶＭにより自動化され、又はＶＭからの支援でもってプログラマによりコード化できる。これは言語レベル通信機構を使用して達成できる。この方法では、作られている言語を使用して他のオブジェクトへアクセスするのと同じ方法で実行テキストを横断するオブジェクトのアクセスを表現できる。これらの実行時検査は、ジャバ（商標）言語及びプラットホームが既に提供するものを越えた防御／セキュリテイの第二次元を提供する。

これらの機構は、例えば、プログラミング・バグ（全てのコンテキストがアクセス可能であるべきでない時に、データを「パブリック（公）」（グローバル）と宣言するような）に起因するセキュリテイ・ホールに対する保護を提供する。それらはまた、細かい単位で共有の制御を可能にする（共有されるべきオブジェクト及び共有されるべきアプレットの選択など）。

本発明はまた、コンピュータ・プログラム製品及び本発明の別の観点に関係する搬送波に関する。

本発明の上述又はその他の特徴、観点、及び利点は、以下の本発明の詳細な説明を添付図面と共に参照することにより、明らかとなる。

スマート・カードのカード受入装置を装備されたカード受入装置と一緒に使用するためのコンピュータを示す図。 ネットワークに接続されカード受入装置を装備されたコンピュータを示す図。 従来技術のスマート・カードなどの小面積装置の例示的なハードウェア・アーキテクチャを示す図。 従来技術で使用される原理によりアクセスされるオブジェクトを示す図。 本発明のさまざまな実施の形態を説明するのに使用できる例示的なセキュリテイ・モデルを示す図。 本発明の１つの観点によるコンテキスト障壁又はフアイヤ・ウォールによる実行コンテキストの分離を示すブロック図。 本発明を実行するのに有用なソフトウェア・アーキテクチャを示す図。 本発明の１つの観点によるフアイヤウォールを実現するセキュリテイ増強プロセスのフロー・チャート。 本発明の１つの観点によるフアイヤウォールを横断するオブジェクトのアクセスを示すブロック図。 フアイヤウォールを横断するカスケードされたオブジェクトを示すブロック図。 １つのコンテキスト中の主成分によるフアイヤウォールを横断して別のコンテキストへのアクセスを許可するプロセスのフロー・チャート。 フアイヤウォールを横断したアクセスを許可するための入口点オブジェクトの使用を声明するブロック図。 フアイヤウォールを横断するアクセスのための配列などのグローバル・データ構造の使用を説明するブロック図。 フアイヤウォールを横断するアクセスを許可するためのスーパーコンテキストの使用を説明するブロック図。 フアイヤウォールを横断するアクセスを許可するための共有可能インターフェイス・オブジェクトの使用を説明するブロック図。 フアイヤウォールを横断したアクセスを許可するセキュリテイ増強プロセスのフロー・チヤート。 ブロック１６２０の詳細を示す図１６のフローチャート。 図１７のブロック１６２９の例示的実現を示すフローチャート。

表記法及び命名法
以下の詳細な説明は、コンピュータ又はコンピュータ・ネットワーク上で実行されるプログラム手順の言葉で説明される。これらの手続的記述及び表現は、当業者が彼等の仕事の本旨を最も効果的に他の当業者に伝えるのに使用される手段である。

手順は、ここでは一般に、所望の結果に導くステップの首尾一貫した順序で説明される。これらステップは物理的量の物理的操作を必要とするステップである。必ずではないが、これらの量は普通、記憶、移送、結合、比較、又はその他の操作が可能な電気的又は磁気的信号の形を取る。主として共通の使用のため、これらの信号は、ビット、値、要素、シンボル、文字、言葉、数など、又は同等なものとして呼ぶことが便利であることが示される。しかし、これらの全ての及び類似の言葉は、適当な物理量に関連付けられるへきであり、そしてこれらの量に適用される単なる便利なラベルにすぎないことに注意すべきである。

さらに、実行される操作は、時々、人間の操作者により実行される精神的な操作と共通に関連付けられる加算又は比較などの言葉で呼ばれる。本発明の一部を形成するここで記述されたどんな操作においても、大部分の場合は、人間の操作者のこのような能力は必要ではなく、又は望まれない。操作は機械的操作である。本発明の操作を実行するために有用な機械は、汎用デジタル・コンピュータ又は他の計算装置を含む。

本発明はまた、これらの操作を実行するための装置に関する。これらの装置は所望の目的のために特別に構成されてよい。又は、選択的に活性化される又はコンピュータに記憶されたコンピュータ・プログラムにより再構成される汎用コンピュータを含んでもよい。ここで説明される手続は特定のコンピュータ又は他の装置に固有的に関係するものではない。ここでの教示に従って書かれたプログラムと一緒にさまざまな汎用機械が使用でき、又は、所望のメソッドのステップを実行するためにより専門化された装置を構成することがより便利であろう。これらのマシンのさまざまについての必要な構成が、以下の記述から明らかとなる。

詳細な説明
付録として明細書に添付したものは、未刊行のジャバ・カード実行時環境２．１仕様という名称の書類の草案である。この草案書類は本発明の特定の実施の形態のさらに詳細な説明を与える。

本発明の技術は以降、スマート・カードの例の文脈で記載されるが、例は単なる例示であり、本発明の範囲を制限するものではない。

図１は、カード受入装置１１０を具備したコンピュータ１２０及びカード受入装置１１０と共に使用するスマート・カード１００を示す図である。動作においては、スマート・カード１００はカード受入装置１１０内に挿入されて、そして、スマート・カード１００の表面上でアクセス可能な１組の接点１０５を介して電源又はデータ接続が与えられる。カードが挿入される時、カード受入装置１１０からの嵌入接点が、表面接点１０５と相互接続してカードに電源を与え、そしてボード上のプロセッサ及びメモリ記憶との通信を可能にする。

図２は、ネットワーク２００に接続された、図１中の１２０などに示されるカード受入装置を具備したコンピュータを示す。さらに、ネットワークに接続されるのは、サーバー２１０などの複数の他の計算装置である。カードを具備した装置１２０を使用してネットワーク２００を介してスマート・カード上にデータ及びソフトウェアをロードすることが可能である。この種のダウンロードされるものは、さまざまな電子商取引及び他のさまざまなアプリケーションに従って使用されるデジタル・キャッシュ及び他の情報、及びスマート・カード上にロードされるべきアプレット又は他のプログラムも含むことができる。カード受入装置及びスマート・カードの処理要素の制御に使用されるデータ及び命令は、揮発性又は不揮発性メモリ内に記憶することができ、若しくは、例えば、命令及び／又はデータを含む搬送波などの通信リンク上で直接に受信することが可能である。さらに、例えば、ネットワークはＬＡＮ又はインターネットなどのＷＡＮ又は他のネットワークであってよい。

図３は、従来技術のスマート・カードなどの小面積装置の例示的なハードウェア・アーキテクチャである。図３に示すように、プロセッサ３００は、読出し専用メモリ３１５及び／又はランダム・アクセス・メモリ３１６を含むことができる主記憶３１０と相互接続される。プロセッサはまた、ＥＥＰＲＯＭなどの二次記憶３２０及びシリアル・ポートなどの入力／出力３３０に接続される。この種の小面積装置は大変に単純にできることが理解できる。

図４は、従来技術によるプリンシパルによりアクセスされるオブジェクトを示す。図４に示すように、小面積装置などの物理装置４００は、実行コンテキスト４２０を実行する１つ又は複数の処理マシン（仮想又は物理的）をその中に含む。実行コンテキストは、例えば、特定のアプレットと関連したコンテキストである。実行コンテキスト中の１つ又は複数のプリンシパル４３０（例えば、アプレット又はアプリケーション）は、実行コンテキスト中の他のオブジェクトのアクセスを求めることができる。実行コンテキスト中でアクセスが発生する限り、アクセスは許可されて、全てが通常に機能するであろう。

図５は、本発明のさまざまな実施の形態を説明するのに使用できる例示的なセキュリテイ・モデルである。これは単に使用できる多くのモデルの１つにすぎないが、この目的には便利なモデルである。このモデルにおいて、プリンシパル（時々、エンティテイと呼ばれる）は、オブジェクト５２０などの１つのオブジェクトについてアクション５１０を取ることを提案する。セキュリテイ検査が、プリンシパル、オブジェクト、及び／又は取られることが提案されたアクション上に課せられる。

図５において、２つのタイプのオブジェクトが示され、その上にプリンシパルによりアクションが取られる。これらは、データ・オブジェクト（例えば、データ１及びデータ２（５２０、５２０”））とエンティテイ５３０を含む。プリンシパルはこれらのオブジェクトのいずれについても動作し又は動作を試みる。

データは受動的であるが、エンティテイ５３０は能動的である。プリンシパルから能動的エンティテイへの対角線も「アクション」とラベルが付けられているが、しかし、これはデータ・オブジェクトへのアクションと比較して、機能を実行し、又は、メソッドをコールし、又は、メッセージを送信するなどのより洗練され且つ任意に複雑なアクションであることができる。データと同じく、オペレーテイング・システムにより実行されるセキュリテイ検査は、プリンシパルの識別、エンティテイの識別、及び／又はアクションのタイプを使用することができる。さらに、能動的であるエンティテイは、それ自身の追加的なセキュリテイ検査を実行できる。これらは、所望ならば任意に複雑にすることができ、そしてプレンシパルの識別、エンティテイ自身の識別、アクション及び／又は利用可能な他の情報も使用できる。

オブジェクト指向システムにおいて（ジャバ・カード（商標）プラットホームなど）、「オブジェクト」は典型的にデータ及びエンティテイの組合せである。プリンシパルが、オブジェクトのフィールドをアクセスすることを試みる時、これはデータ・アクセス−−かなり単純なセキュリテイ検査により保護されるかなり単純なアクション、である。プリンシパルがオブジェクトのメソッドのアクセスを試みる時、これは、アクション及びセキュリテイ検査の両方を任意に複雑できるエンティテイ・アクセスである。

図６は、本発明の１つの観点によるコンテキスト障壁又はフアイヤウォールによる実行テキストの分離を示すブロック図である。物理装置４００及びマシン４１０は、図４に示される同じアイテムに対応する。実行コンテキスト４２０は、コンテキスト内でオブジェクト４４０にアクセスすることを試みる１つのプリンシパル４３０を示す。このアクセスは普通成功する。しかし、実行コンテキスト４２０はまた、コンテキスト障壁６００を横断して、実行コンテキスト６２０のオブジェクト６４０にアクセスすることを試みるプリンシパル６３０を示す。普通、このアクセスはアクション６３５がコンテキスト障壁６００を横断する所のＸ６３６に示されるように禁止される。

図７は、本発明を実行するのに有用なソフトウェア・アーキテクチヤを表している。このソフトウェア・アーキテクチャは実行時環境７００として示されている。小面積装置についてオペレーテイング・システム７１０が普通、使用される。本発明の例示的な実施の形態中の仮想マシン７２０が、オペレーティング・システム上で実現される。仮想マシンは、ジャバ・カード（商標）仮想マシン又は他の仮想マシンである。標準の仮想マシンの能力がここに記載される追加の機能を与えるために拡張できる。又は、機能は別個のモジュールとして提供できる。仮想マシン７２０は、インタープリータ又は実行時システム７４０へのアクセスを与えるネイテイブ処理系７３０を含む。実行時システムは、オブジェクト指向処理系のオブジェクトを管理するためのオブジェクト・システム７５０を含む。３つのコンテキスト７６０、７７０、及び７８０が示される。各コンテキストが、実行コンテキスト間のコンテキスト障壁（時々、フアイヤウォールと呼ばれる）により他から分離される。１つの特定の実施の形態において、コンテキスト７６０はスーパーコンテキストである。すなわち、コンテキスト７６０は、下位のコンテキスト７７０及び７８０には利用できない特権及び能力を有する。それは入口点オブジェクト又はグローバル・データ構造を生成し、そして下位コンテキスト７７０及び７８０内のオブジェクトにアクセスする特権を潜在的に含む。

各オブジェクトは１つの特定のコンテキストに関連付けられている。そのコンテキストはそれと関連付けられた各オブジェクトを所有すると言われる。実行時システム７４０は、コンテキストを独特に識別するための手段と現在実行されているコンテキスト識別し指定するための手段を与える。オブジェクト・システム７５０は、オブジェクトをそれらが所有するコンテキストと関連付けるための機構を与える。

例えば、実行時７４０は、独特な名前でもってコンテキストを識別でき、そして、オブジェクト・システム７５０はコンテキストの名前をオブジェクトのヘッダー内に記録することにより、オブジェクトをコンテキストと対応して関連付けることができる。オブジェクトのヘッダー内の情報は、オブジェクト指向言語により書かれたプログラムによりアクセスできないが、仮想マシン７２０自身のみに利用可能である。代替的に、実行時システム７４０は、メモリ空間を各々が特定のコンテキストのための分離領域に分割することによりコンテキストを識別できる。そして、オブジェクト・システム７５０はコンテキストのメモリ空間内にオブジェクトの記憶を割当てることによりオブジェクトをそのコンテキストに対応して関連付けることができる。

図８は、本発明の１つの観点によるコンテキスト障壁を実現するセキュリテイ実施プロセスのフローチャートである。プリンシパルがオブジェクト（８００）上のアクションを呼出すと、オブジェクトがプリンシパル（８１０）のコンテキスト内にあるかどうかを決定するための検査が作られる。もしなければ、アクションは不許可となる（８４０）。それ以外は、アクションは許可される（８３０）。これはコンテキスト障壁又はフアイヤウォールの最も単純な形である。１つの特定の実施の形態では、もしオブジェクトが名前空間の外側にあるか又はコンテキストがアクセスを要求するメモリ空間の外側にあれば、セキュリテイ例外を投げることにより、アクションが不許可とされる（８４０）。

図９は、本発明の１つの観点によるフアイヤウォールを横断してアクセスするオブジェクトを示すブロック図である。図９は図６と実質的に同じである。しかし、図９は、オブジェクト９１０上にアクション９０５を実行するためにオブジェクト９１０のアクセスを求めるプリンシパル９００も示す。本発明によれば、アクション６３５が阻止された方法でアクセスがフアイヤウォール６００により阻止されるというよりは、プリンシパルとオブジェクトが異なる実行コンテキスト内にあるという事実にかかわらず、プリンシパル９００がオブジェクト９１０上のアクション９０５を実行できるように、アクション９０５がアクセス・ポイント９２０を介してフアイヤウォールを横断して生ずることを許可する。アクセス・ポイント９２０の背後の機構は図１２−１８を参照して以下に説明される。アクセス・ポイント９２０は、Ｘ６３６などの阻止されたアクセスと共に存在できることに注意する。このように、アクセス・ポイント９２０は、コンテキスト障壁６００を横断して細かい単位の制御（オブジェクト単位のセキュリテイ）の共有を与える。

オブジェクト・アクセス９００が開始される時、現在コンテキスト設定はコンテキスト４２０である。もしオブジェクト９１０がデータ・オブジェクトであれば、アクション９０５は単純なデータ・アクセスであり、第２コンテキストではコードは実行されない。もしオブジェクト９１０がエンティテイ・オブジェクトであれば、アクション９０５は実行されるそのオブジェクトのコードを生ずる。そのコードは第２コンテキスト６２０内で実行される。正しいコンテキスト６２０内でオブジェクト９１０のコードを実行するため、仮想マシン４１０はコンテキスト切換えを実行する。コンテキスト切換えは、現在コンテキスト設定をコンテキスト６２０に変えて、現在コンテキスト設定の前の値を後で再開できるように記憶する。この点から、コードは新しい現在コンテキスト内で実行される。アクション９０５が完了した時、制御はアクセス９００後の点に戻される。復帰中、仮想マシン４１０は現在コンテキスト設定の値をその前の値に回復しなければならない。

図１０は、フアイヤウォールを横断してアクセスするカスケードされたオブジェクトを示すブロック図である。図１０は、３つの実行コンテキスト、１０００、１０１０及び１０２０を示す。実行コンテキスト１内のプリンシパル１０３０は、実行コンテキスト２内のオブジェクト１０５０上のアクション１０３５を呼出すことを求め、コンテキスト障壁６００内のアクセス・ポイント１０７０を介してそれを行なう。実行コンテキスト２内のオブジェクト１０５０は、実行コンテキスト３内のオブジェクト１０６０上のアクション１０４５の実行を求めるオブジェクト・アクセス１０４０を有する。それは、実行コンテキスト２及び３を分離するコンテキスト障壁６００’内のアクセス・ポイント１０８０を使用してこれを達成する。実行コンテキスト２内のオブジェクト１０５０はまた、同じ実行コンテキスト内で、すなわち、実行コンテキスト２内で、オブジェクト１０９９上でアクション１０９５を呼出す別のオブジェクト・アクセス１０９０を有する。両方のアクション１０３５及び１０４５は図９の説明で開示されたようなコンテキスト切換えを生ずる。しかし、アクション１０９５はコンテキスト障壁を横断しないため、コンテキスト切換えはその実行に必要ではなく、従って発生しない。

図１１は、１つのコンテキスト中のプリンシパルがフアイヤウォールを横断して別のコンテキスト内にアクセスすることを許可するプロセスのフローチャートである。このプロセスには本質的に３つのステップが存在する。実行コンテキスト２において、アクセスされるべきオブジェクトが生成されて共有されるものとして指定される（１１００）。実行コンテキスト１中において、プリンシパルが実行コンテキスト２内のオブジェクトについての参照を得る（１１１０）。そして、実行コンテキスト１中のプリンシパルは、コンテキスト２中で共有として指定されたオブジェクト上のアクションを呼出す（１１２０）。

図１１の項目１１００中で説明したように共有可能と生成されたオブジェクトを指定又は識別することについては、本発明によれば、これはオブジェクトの表現のヘッダー内に共有可能な属性を含むことにより、行なわれる。オブジェクトのヘッダー内の情報はオブジェクト指向言語により書かれたプログラムによりアクセスすることはできないが、ＶＭ自身のみにより利用可能である。

別のコンテキスト中のオブジェクトへの参照を獲得することは、別のコンテキスト中のオブジェクトにアクセスする特別の場合である。別のコンテキスト内の１つのオブジェクトへのアクセスを与える機構は、別のオブジェクトをまた利用可能にする。例えば、別のコンテキスト中のオブジェクト上のメソッドを呼出すことは、異なるコンテキスト中に第２のオブジェクトへの参照を戻す。追加の機構が、異なるテキスト中のオブジェクトへの初期参照の獲得を可能にするため必要とされる。特定の実施の形態においては、ある周知の入口点オブジェクトへの参照が公のＡＰＩを使用して獲得できる。一旦、異なるコンテキスト内のオブジェクトに対する初期参照が獲得されると、そのオブジェクトからさらなる参照が獲得でき、さらに続けられる。

本発明によれば、コンテキスト障壁を横断して情報を獲得するために、４つの一般的な手法が存在する。これらの手法は、コンテキスト障壁を横断してオブジェクトをアクセスするため、又は、コンテキスト障壁を横断してアクセスされるべきオブジェクトの参照を獲得するために、個別に又は組合せで使用できる（１１１０）。これらの手法は図１２−１８により説明される。

図１２は、コンテキスト障壁を横断してアクセスを許可するための入口点オブジェクトの使用を説明するブロック図である。図１２に示すように、コンテキスト７７０（コンテキスト１）内のあるオブジェクト１２００は、スーパーコンテキスト７６０内の情報にアクセスすることを望む。特定の実施の形態において、スーパーコンテキスト７６０は少なくとも１つの入口点オブジェクト１２１０を含む。入口点オブジェクト１２１０は、スーパーコンテキストの下位の各コンテキストがスーパーコンテキストの入口点オブジェクトと通信できるようにするため、公のＡＰＩの一部として刊行されるか、又は、刊行されたＡＰＩを通じて間接的に利用可能にできる（例えば、図１１を参照して前に説明した機構に従い）。（他の実施の形態では、入口定オブジェクトはスーパーコンテキスト以外のコンテキストにより収納される。）
図１３は、フアイヤウォールを横断してアクセスを許可するためにグローバル・データ構造の使用を説明するブロック図である。この手法において、スーパーコンテキスト７６０は、グローバル配列などのグローバル・データ構造を生成する。特定の実施の形態では、スーパーコンテキスト７６０はこのようなグローバル・データ構造を生成することを許可された唯一のコンテキストである。（別の実施の形態では、グローバル・データはスーパーコンテキスト以外のコンテキストにより収納されてよいことが理解される。）このグローバル状態のため、コンテキスト７７０及び７８０の各々は、グローバル・データ構造を読書きすることができる。このように、１つのコンテキストによりグローバル・データ構造内に書込まれた情報は、別のコンテキストにより読み出すことができる。例えば、この機構はコンテキスト間でオブジェクトへの参照又は２進値データを送るために使用できる。

図１４は、コンテキスト障壁を横断してアクセスを許可するためにスーパーコンテキスト特権を使用することを説明するブロック図である。図１４において、スーパーコンテキスト７６０におけるオブジェクトは２つに分離するコンテキスト障壁を横断してコンテキスト７８０へのアクセスを求める。スーパーコンテキスト７６０は、スーパーコンテキストに関連した特権により、コンテキスト７８０のどんなメソッドも呼出すことができ、そしてコンテキスト７８０内に含まれるどんなデータもアクセスすることができる。

図１５は、フアイヤウォールを横断してアクセスすることを許容するため、共有可能インターフエイス・オブジェクトの使用を説明するブロック図である。共有可能インターフエイスは共有可能インターフエイス・メソッドの１組を定義する。共有可能インターフエイス・オブジェクトは共有可能インターフエイス内に定義されたメソッドの組を少なくとも実現するオブジェクトである。図１５において、コンテキスト２（７８０）内のオブジェクト１２１０は共有可能インターフエイス・オブジェクトである。別のコンテキスト７７０中のオブジェクト・アクセス１２００は、もしオブジェクト・アクセス１２００のプリンシパルがオブジェクト１２１０自身によりそのようにすることが認証されているならば、オブジェクト１２１０上のどんな共有可能なインターフエイス・メソッドをも呼出すことができる。この認証は以下の図１８を参照してさらに説明する。

本発明による仮想マシンは、「ジャバ（商標）仮想マシン仕様」に記載される仮想マシンなどの初期の仮想マシンを越えた機能を提供することが理解される。特に、本発明によれば、仮想マシンはフアイヤウォールを横断したアクセスを許可するセキュリテイ実施プロセスを実現又は容易にするための機能を与える。このプロセスが次に図１６−１８を参照して説明される。それは、上記の図１２−１５を参照して説明された４つの手法を限定的ではなく含む、フアイヤウォールを横断するアクセスを提供するどんな手法にも適用できることに注意する。

図１６は、フアイヤウォールを横断してアクセスを許可するセキュリテイ実施プロセスのフローチャートである。プリンシパルがオブジェクト１６００上のアクションの呼出しを試みる時、オブジェクトがプリンシパルのコンテキスト内にあるかどうかを決定するための検査が作成される（１６１０）。もしそうであるならば（１６１０−Ｙ）、アクションが許可される（１６３０）。もしそうでなければ（１６１０−Ｎ）、プリンシパルによるアクションがオブジェクトに対して許可されるているかどうかを見るための検査が生成される（１６２０）。もしそうであるならば（１６２０−Ｙ）、アクションが許可される（１６３０）。もしそうでなければ（１６２０−Ｎ）、アクションは許可されない。この特定の実施の形態では、セキュリテイ例外が投げられる（１６４０）。

図１７は、ブロック１６２０のさらに詳細を示す図１６のフローチャートである。もしオブジェクトがプリンシパル（１６１０−Ｎ）のコンテキスト内になければ、プリンシパルによるアクションがオブジェクト上で許可されるかどうかを見るために複数のテスト１６２１、１６２２、１６２３…１６２９が引受けられる。これらのテストは仮想マシン・オブジェクト指向実現の中で、仮想マシンのみで、又は、仮想マシンとオブジェクトとを加えて、行なわれる。もしどんなテストにおいて合格ならば、アクションは許可される（１６３０）。しかし、もし全てのテストが否定的決定（１６２Ｘ−ノー）を生ずる場合は、アクションは許可されない。特定の実施の形態では、セキュリテイ例外が投げられる（１６４０）。これらテストは図１２−１５と関連して説明された許可されたアクセスに関係する。

図１８は、図１５において説明されたアクセス・メソッドに使用される図１７のブロック１６２９の例示的な実現を示すフローチャートである。８２９又は１６２９などのテストにおいて、仮想マシンはオブジェクトが共有されたオブジェクト１８１０かどうかを検査する。もしそうでなければ（１８１０−ノー）、このテストは失敗する。しかし、もしそうであれば（１８１０−イエス）、仮想マシンはオブジェクトＯ上のメソッドＡを呼出す（１８２０）。もし、オフジェクトＯ上のメソッドＡがプリンシパルが認証されていると決定すれば（１８３０）、テストは合格であり（１８４０）、そしてアクセスは許可される。それ以外は、テストは失敗である（１８５０）。これは、認証テキストをオブジェクト自身のコード内にプログラムすることを可能にする。

本発明がスマート・カードの実現と関連して説明されたが、本発明はスマート・カードに限らず、他の小面積の装置にも適用できる。小面積の装置は一般に、メモリ、計算能力又は速度において制限又は限界があるものと考えられる。このような小面積装置は、境界走査装置、フイールド・プログラム可能装置、ページャー、及びセルラー・ホンなどの多くの装置を含む。

一般に、小面積装置は、実行コンテキストの安全な相互操作に問題がある、資源の制約を受ける計算装置及びシステムである。このような小面積装置はそれらの制限された資源のためにセキュリテイ手段の実現に制約が課せられる。資源の制約のため仮想マシン構成においては、単一の仮想又は物理的マシンが、複数の仮想マシンと対比して、使用されなければならない。

本発明はまた、本発明の特徴が有利なより大型の装置にも適用できる。例えば、本発明は、サーブレットを使用する時、もしこれらの間でオブジェクトの共有があれば、有利であることが確かめられる。いくつかのデスクトップ・システムにおいてさえも、本発明の技術を有利に使用できる。

ジャバ（商標）言語及びプラットホームが本発明に適しているが、ある特性を有する言語又はプラットホームが本発明を実現するのに良く適しているであろう。これらの特性は、タイプ安全性、ポインター安全性、オブジェクト指向、動的リンク、及び仮想マシンに基づくことを含む。これらの特性の全てが特定の実現において存在する必要はない。いくつかの実施の形態では、これらの特性の一つ又は複数を欠く言語又はプラットホームが使用できる。「仮想マシン」は、ビット（仮想マシン）又はシリコン（現実／物理的マシン）のいずれかで実現できる。

本発明は、オブジェクト単位のセキュリテイを示して説明されたが、クラス単位のセキュリテイなどの他の手法も使用できる。

本発明が詳細に説明されたが、説明は例示であり、限定するものではないことは明らかである。本発明の範囲と精神は特許請求の範囲の記載とその均等物のみにより限定される。
ジャバ（商標）カード（商標）実行時環境（ＪＣＲＥ）２．１仕様
草案２
Copyright(c)1998 Sun Microsystems,Inc.
901 San Antonio Road, Pal Alto, CA 94303 USA
全ての権利を留保。この書類の著作権はサン・マイクロシステムズ社が所有する。

サン・マイクロシステムズ社（ＳＵＮ）は、あなたに、内部評価目的に限り使用するために、ジャバ（商標）カード（商標）実行時環境（ＪＣＲＥ）２．１仕様（仕様）を実施するために必要なＳＵＮの知的所有権の非独占、移転不可、世界的、制限ライセンス（サブライセンス無し）を無料で許諾する。この制限ライセンス以外には、あなたは仕様について権利や利益を有せず、仕様を生産又は商業的使用に使用する権利を有しない。

制限的権利標章
サンは、このソフトウェアの適当性について、非侵害性又は特定の目的の適合性又は商品可能性の黙示的保証を限定的ではなく含む、一切の明示又は黙示の保証又は表示をしない。サンはこのソフトウエア及び二次的著作物の使用、修正、又は配布の結果としてライセンシーが受けた損害については責任を持たない。

商標
サン、サン・ロゴ、サン・マイクロシステムズ、ジャバソフト、ジャバビーンズ、ＪＤＫ、ジャバ、ジャバカード、ホットジャバ、ホットジャバ・ビュウズ、ビジュアル・ジャバ、ソラリス、ＮＥＯ、ジョー、ネトラ、ＮＦＣ、ＯＮＣ、ＯＮＣ＋、オープン・ウインドウズ、ＰＣ−ＮＦＳ、エンベデッド・ジャバ、パーソナル・ジャバ、ＳＮＭ、サンネット・マネージャ、ソラリス・サンバースト・デザイン、ソルステイス、サンコア、ソーラーネット、サンウェブ、サン・ワークステーション、ザ・ネットワーク・イズ・ザ・コンピュータ、ツールトーク、ウルトラ、ウルトラコンピューテイング、ウルトラサーバ、ホェア・ザ・ネットワーク・イズ・ゴーイング、サン・ワークショツプ、エックス・ビュー、ジャバ・ワークショップ、ジャバ・コーヒー・カップ・ロゴ、及びビジュアル・ジャバは、サン・マイクロシステムズ社の米国または他の国での商標又は登録商標である。

この文献は、そのまま提供されて、非侵害性又は特定の目的の適合性又は商品可能性の黙示的保証を限定的ではなく含む、明示又は黙示のいかなる種類の保証を含まない。

この文献は、技術的不正確さタイプ誤りを含み得、この情報への変更は定期的に行なわれる。これらの変更はこの文献の新しい版に組み込まれる。サン・マイクロシステムズ社はこの文献に記載されたプログラム又は製品の改良又は変更を何時でも行なうであろう。
目次
前書
１． 導入
２． ジャバ・カード仮想マシンの一生
３． ジャバ・カード・アプレットの一生
３．１ メソッド・インストール
３．２ メソッド・セレクト
３．３ メソッド・プロセス
３．４ メソッド・デセレクト
３．５ 電源喪失及びリセット
４． 一時的オブジェクト
４．１ 一時的オブジェクトをクリアする出来事
５． 選択
５．１ デフォルト・アプレット
５．２ 選択命令処理
５．３ 非選択命令処理
６． アプレット隔離及びオブジェクト共有
６．１ アプレット・フアイヤウォール
６．１．１ コンテキスト及びコンテキスト切換え
６．１．２ オブジェクト所有
６．１．３ オブジェクト・アクセス
６．１．４ フアイヤウォール保護
６．１．５ 静的フイールド及びメソッド
６．２ コンテキストを横断したオブシェクト・アクセス
６．２．１ ＪＣＲＥ入口点オブジェクト
６．２．２ グローバル配列
６．２．３ ＪＣＲＥ特権
６．２．４ 共有可能インターフエイス
６．２．５ 前のコンテキストの決定
６．２．６ 共有可能インターフエイスの詳細
６．２．７ 共有可能インターフエイス・オブシェクトの獲得
６．２．８ オブジェクト・アクセス振舞い
６．３ 一時的オブジェクト及びアプレット・コンテキスト
７． トランザクション及びアトミシテイ
７．１ アトミシテイ
７．２ トランザクション
７．３ トランザクション期間
７．４ ネストされたトランザクション
７．５ テスト及びリセット・トランザクション故障
７．６ トランザクションの中止
７．６．１ プログラム的中止
７．６．２ ＪＣＲＥによる中止
７．６．３ ＪＣＲＥのクリーンアップ責任
７．７ 一時的オブジェクト
７．８ コミット容量
８． ＡＰＩトピックス
８．１ ＡＰＤＵクラス
８．１．１ 外向きデータ転送のＴ＝０詳細
８．１．２ 外向きデータ転送のＴ＝１詳細
８．２ セキュリテイ及び暗号パッケージ
８．３ ＪＣＳｙｓｔｅｍクラス
９． 仮想マシン・トピックス
９．１ 資源故障
１０． アプレット・インストーラ
１０．１ インストーラ
１０．１．１ インストーラ実現
１０．１．２ インストーラＡＩＤ
１０．１．３ インストーラＡＰＤＵ
１０．１．４ インストーラ振舞い
１０．１．５ インストーラ特権
１０．２ 新にインストールされたアプレット
１０．２．１ インストーレイション・パラメータ
１１． ＡＰＩ定数
前書
ジャバ（商標）カード（商標）技術は、ジャバ・プログラミング言語の一部と、スマート・カード及び関連する小メモリ埋め込み装置に最適化された実行時環境とを結合する。ジャバカード技術の目標は、ジャバ・ソフトウェア・プログラミングの多くの利点を資源を、制約されたスマート・カードの世界へ持って来ることである。

この書類は、ジャバ・カード実行時環境（ＪＣＲＥ）２．１の仕様である。ジャバ・カード可能化装置のベンダーはＪＣＲＥの実現を提供する。この仕様の文脈内でのＪＣＲＥの実現とは、ジャバ・カード仮想マシン（ＶＭ）、ジャバ・カード・アプリケーション・プログラミング・インターフエイス（ＡＰＩ）、又はジャバ・カード技術仕様に基づいた他の部品のベンダーの実現を言う。参照実現とは、サン・マイクロシステムズ社により作られた実現である。ジャバ・カードに対して書かれたアプレットはジャバ・カード・アプレットと呼ぶ。

誰がこの仕様は使用すべきか？
この仕様は、ジャバ・カード技術仕様を拡張する仕様を開発、実現を作成する際、又はジャバ・カード実行時環境（ＪＣＲＥ）の拡張を作る際にＪＣＲＥ実現を補助することを意図している。この仕様はさらに、ジャバ・カード技術仕様の理解を深めたいシャバ・カード・アプレット開発者に対して意図している。

この仕様を読む前に
このガイドを読む前に、あなたはジャバ・プログラミング言語、ジャバ・カード技術仕様、及びスマート・カードに明るくなければならない。ジャバ技術及びジャバ・カード技術に明るくなるための良い材料が、サン・マイクロシステムズ社のウェブ・サイト、http://java.sun.comにある。

この仕様は、どのように構成されているか
１章、「ＪＣＲＥの範囲と責任」はＪＣＲＥ実現に必要とされるサービスの概観を与える。
２章、「仮想マシンの一生」は仮想マシンの一生を定義する。
３章、「アプレットの一生」はアプレットの一生を定義する。
４章、「短期オブジェクト」は短期オブジェクトの概観を与える。
５章、「選択」はＪＣＲＥがどのようにアプレット選択を処理するかを説明する。
６章、「アプレット隔離及びオブジェクト共有」はアプレット隔離とオブジェクト共有を説明する。
７章、「トランザクションとアトミシテイ」はトランザクション中のアトミシテイの概観を与える。
８章、「ＡＰＩトピックス」はＪＣＲＥに必要だがシャバ・カード２．１ＡＰＩ仕様には完全に特定されていないＡＰＩ機能を説明する。
９章、「仮想マシン・トピックス」は仮想マシンの詳細を説明する。
１０章、「アプレット・インストーラ」はアプレット・インストーラの概観を与える。
１１章、「ＡＰＩ定数」はシャバ・カード２．１ＡＰＩ仕様に特定されていない定数の数値を与える。

用語は、この本を使用するのに役立つ言葉とそれらの定義のリストである。
関連の書類及び刊行物
このマニュアル内ではさまざまな書類及び製品に言及する。以下の書類が入手可能である。
・シャバ・カード２．１ＡＰＩ草案２仕様、サン・マイクロシステムズ社
・ジャバ・カード２．０言語サブセット及び仮想マシン仕様、１９９７年１０月１３日、改訂１．０最終、サン・マイクロシステムズ社
・ジャバ・カード・アプレット開発者ガイド、サン・マイクロシステムズ社
・ジャバ言語使用、ジェームズ・ゴスリング、ビル・ジョイ、及びゲイ・エル・ステイール著、アデイソン−ウエズレイ、１９９６年、ISBN 0-201-63451-1
・ジャバ仮想マシン仕様（ジャバ・シリーズ）、ティム・リインデホルム及びフランク・イェリン著、アディソン−ウエズレイ、１９９６年、ISBN 0-201-63452-X
・ジャバ・クラス・ライブラリイ：注解参考書（ジャバ・シリーズ）パトリック・チェン及びロザンナ・リー著、アディソン−ウエズレイ、２巻、ISBN 0201310023及び0201310031
・ＩＳＯ７８１６仕様１−６部分
・支払いシステム用ＥＭＶ‘９６集積回路カード仕様
１． 導入
ジャバ・カード実行時環境（ＪＣＲＥ）２．１は、ジャバ・カード仮想マシン（ＶＭ）、ジャバ・カード・アプリケーション・プログラミング・インターフエイス（ＡＰＩ）クラス（及び業界特有拡張）及びサポート・サービスを含む。

この書類、ＪＣＲＥ２．１仕様は、ジャバ・カード技術により要求されるＪＣＲＥ機能を詳述する。ジャバ・カード技術のどんな実現もこの必要な行動と環境を与える。
２． ジャバ・カード仮想マシンの一生
ＰＣ又はワークステーションで、ジャバ仮想マシンはオペレーテイング・システム・プロセスとして実行する。ＯＳプロセスが終了する時、ジャバ・アプリケーションとそれらのオブジェクトは自動的に破壊される。

ジャバ・カード技術において、仮想マシン（ＶＭ）の実行の一生は、カードの一生である。カードに記憶された情報の大部分は電源がカードから外されても保存される。持続性メモリ技術（ＥＥＰＲＯＭなど）は、スマート・カードが電源から外された時に情報の記憶を可能にする。カード上に生成されたＶＭ及びオブジェクトは、持続性のアプリケーション情報を表すのに使用されるため、ジャバ・カードＶＭは永久に動作するように見える。電源が外された時、ＶＭは単に一時的に停止する。カードが次にリセットされる時、ＶＭは再び開始して、持続性記憶から前のオブジェクト群を回復する。

持続性の特徴は別として、ジャバ・カード仮想マシンは、ジャバ仮想マシンと同様である。

カード初期化時は、マスキング後の時間であり、カードの個性化と発行の時間の前である。カード初期化時に、ＪＣＲＥが初期化される。ＪＣＲＥにより生成されたフレームワーク・オブジェクトは仮想マシンの一生の間、存在する。仮想マシン及びＪＣＲＥフレームワークの実行の一生は、カードのＣＡＤセッションに及ぶため、アプレットにより生成されたオブジェクトの一生もまたＣＡＤセッションに及ぶ。（ＣＡＤは、カード受入装置、又はカード読取り器。カード・セッションはカードがＣＡＤ内に挿入されて、電源が投入され、そしてＣＡＤとＡＰＤＵのストリームを交換する期間である。カード・セッションはカードがＣＡＤから取外される時に終了する。）この特性を有するオブジェクトを持続性オブジェクトと呼ぶ。

ＪＣＲＥ実現者は、以下の時にオブジェクトを持続性にする。
・Applet.registerメソッドがコールされる時。ＪＣＲＥはアプレット・オブジェクトのインスタンスへの参照を記憶する。ＪＣＲＥ実現者は、クラス・アプレットのインスタンスが持続性であることを保証しなければならない。
・オブジェクトへの参照がクラスの静的フイールド又はその他の持続性オフジェクトのフイールドに記憶される時。この要件は、ＪＣＲＥ内部データ構造の完全性を保存するための必要性から派生する。
３． ジャバ・カード・アプレットの一生
この仕様の目的のため、ジャバ・カード・アプレットの一生は、それが正しくカード・メモリにロードされて、リンクされ、又は、その他、実行のために準備された時点で開始する。（この仕様の以降において、アプレットとはジャバ・カード・プラットホームのために書かれたアプレットを言う。）Applet.registerメソッドに登録されたアプレットは、カードの一生の間、存在する。ＪＣＲＥはアプレットのパブリック・メソッド、インストール、セレクト、デセレクト、及びプロセスを介してアプレットと相互作用をする。アプレットは静的インストール・メソッドを実現する。もしインストール・メソッドが実現されなければ、アプレットのオブジェクトは生成又は初期化できない。ＪＣＲＥ実現はアプレットのインストール、セレクト、デセレクト、及びプロセス・メソッドを以下に説明するようにコールする。

アプレットがスマート・カード上にインストールされる時、静的インストール・メソッドがＪＣＲＥにより生成された各アプレット・インスタンスのために１度、コールされる。ＪＣＲＥはアプレットのコンスラクターを直接コールしてはいけない。
３．１ メソッド・インストール
インストールがコールされる時、アプレットのオブジェクトは存在しない。アプレット内のインストール・メソッドの主な仕事は、アプレット・クラスのインスタンスを生成し、インスタンスを登録することである。アプレットがその一生の間に必要とする全ての他のオブジェクトはそれが可能な時に生成できる。その他のアプレットがＣＡＤにより選択されてアクセスされるのに必要な準備は可能な時に行なうことができる。インストール・メソッドは入力するバイト配列パラメータの内容から初期化パラメータを獲得する。

典型的に、アプレットは、さまざまなオブジェクトを生成し、それらを所定値で初期化し、いくつかの内部状態変数を設定し、そしてそれを選択するのに使用するためにＡＩＤ（ＩＳＯ７８１６−５に定義されるアプレット識別子）を指定するためにApplet.registerメソッドをコールする。このインストールは、Applet.registerメソッドのコールが例外なしに完了した時に成功と見なされる。もしインストール・メソッドがApplet.registerメソッドをコールしない場合、又は、もしApplet.registerメソッドがコールされる前にインストール・メソッド内から例外が投げられる場合、又は、もしApplet.registerメソッドが例外を投げる場合、にはインストールは不成功と見なされる。もしインストールが不成功ならば、ＪＣＲＥはそれが制御を再獲得する時に全てのクリーン・アップを実行しなければならない。すなわち、全ての持続性オブジェクトは、インストール・メソッドがコールされる前に持っていた状態に戻される。もしインストールが成功したならば、ＪＣＲＥはアプレットを選択可能と印を付けることができる。
３．２ メソッド・セレクト
アプレットはそれらが明示的に選択されるまで、停止状態に留まる。ＪＣＲＥが名前データがアプレットのＡＩＤと一致するＳＥＬＥＣＴ ＡＰＤＵを受取る時に、選択は発生する。選択はアプレットを現在選択されたアプレットとする。

ＳＥＬＥＣＴをコールする前、ＪＣＲＥは前に選択されたアプレットの選択を解除しなければならない。ＪＣＲＥはこれをアプレットのデセレクト・メソッドを呼出すことでアプレットに支持する。

ＪＣＲＥは、アプレットにそのセレクト・メソッドを呼出すことにより選択を知らせる。

アプレットは、コールから誤りを返すことにより、又は例外を投げることにより、選択されることを拒否することができる。もしアプレットが真を返すと、現実のＳＥＬＥＣＴ ＡＰＤＵ命令が以後のそのプロセス・メソッドへのコールでアプレットに供給されて、アプレットがＡＰＤＵ内容を検査できる。それはＳＥＬＥＣＴ ＡＰＤＵに対してデータ（詳細はプロセス・メソッドを参照）でもって返答でき、又は、適当なＳＷ（状態ワードの返却）を有するＩＳＯＥｘｃｅｐｔｉｏｎを投げることでエラーのフラグを立てることができる。ＳＷ及び選択的な応答データはＣＡＤへ戻される。

Applet.selectingAppletメソッドは、セレクト・メソッド中にコールされる時に真を返答する。Applet.selectingAppletメソッドは、ＳＥＬＥＣＴ ＡＰＤＵ命令を処理するためにコールされる以降のプロセス・メソッド中に真を返答し続ける。

もしアプレットが選択されることを拒否すると、ＪＣＲＥはＣＡＤにISO.SW_APPLET_SELECT_FAILEDのＡＰＤＵ応答状態ワードを戻す。選択の失敗の際、ＪＣＲＥ状態はアプレットが選択されていないことを示すように設定される。

選択が成功した後、全ての以降のＡＰＤＵはプロセス・メソッドを経由して現在選択されたアプレットへ配達される。
３．３ メソッド・プロセス
全てのＡＰＤＵは、ＪＣＲＥにより受取られ、ＡＰＤＵクラスのインスタンスを現在選択されたアプレットのプロセス・メソッドに送る。

注−ＳＥＬＥＣＴ ＡＰＤＵは、プロセス・メソッドのコール前に、現在選択されたアプレット内に変化を生ずるかもしれない。

正常な返答の際、ＪＣＲＥはアプレットにより既に送られたどんなデータにも完了応答ＳＷとして、0x9000、を自動的に付ける。

プロセス中のどんな時にも、アプレットは適当なＳＷと共にISOExceptionを投げることが可能であり、この場合、ＪＣＲＥはその例外を受取り、そしてＳＷをＣＡＤに戻す。

プロセス中に、もしその他の例外が投げられた場合、ＪＣＲＥはその例外を受取り、状態ワード、ISO7816.Sw_UNKNOWN、をＣＡＤへ戻す。
３．４ メソッド・デセレクト
ＪＣＲＥが、アプレットのＡＩＤと一致する名前のＳＥＬＥＣＴ ＡＰＤＵ命令を受取る時、ＪＣＲＥは現在選択されているアプレットのデセレクト・メソッドをコールする。これは他のアプレットの実行を可能にするために必要なクリーン・アップ操作をアプレットが実行することを可能にする。

Applet.selectingAppletメソッドは、デセレクト・メソッド中にコールされた時、誤りを戻す。デセレクト・メソッドにより投げられた例外はＪＣＲＥにより受取られる。しかし、アプレットは選択が解除される。
３．５ 電源喪失及びリセット
カードがＣＡＤから取出される時又はその他の機械的又は電気的故障が存在する場合、電源が喪失する。カードに電源が再び加えられる時及びカード・リセット（ウアーム又はコールド）時、ＪＣＲＥは以下を保証する。
・一時データはデフォルト値にリセットされる。
・電源が喪失した（又はリセットが発生した）時に進行中のトランザクションがあれば、中止される。
・電源が喪失した（又はリセットが発生した）時に選択されたアプレットは黙示的に選択が解除される（この場合、デセレクト・メソッドはコールされない）。
・もしＪＣＲＥがデフォルト・アプレット選択を実現する場合は（パラグラフ５．１参照）、デフォルト・アプレットが現在選択されたアプレットとして選択され、そして、デフォルト・アプレットのセレクト・メソッドがコールされる。それ以外は、ＪＣＲＥはその状態をアプレットが選択されていないことを示すものに設定する。
４． 一時的オブジェクト
アプレットは時々、ＣＡＤセッションにわたって持続する必要の無い一時的（暫定）データを含むオブジェクトを必要とする。ジャバ・カードはジャバ・キーワード遷移をサポートしない。しかし、ジャバ・カード技術はオブジェクトへの参照又はプリミティブな成分を有する一時的配列を生成する方法を与える。

「一時的オブジェクト」の語は誤った名称である。これはオブジェクト自身が一時的という意味に誤解される。しかし、オブジェクトのフイールド（長さフイールドを除く）の内容のみが一時的な性格を有する。ジャバ・プログラミング言語内のその他のオブジェクトと同様に、ジャバ・カード・プラットホーム内の一時的オブジェクトは、以下から参照される限り、存在する。
・スタック
・ローカル変数
・クラス静的フイールド
・別の存在するオブジェクト内のフイールド
ジャバ・カード・プラットホーム内の一時的オブジェクトは以下の要求された振舞いを有する。
・一時的オブジェクトのフィールドは、ある出来事（以下を参照）の発生時に、フィールドのデフォルト値（ゼロ、誤り、又は無効）にクリアされる。
・セキュリテイの理由のため、一時的オブジェクトのフイールドは「持続性メモリ技術」内には絶対に記憶されない。例として現在のスマート・カード技術を用いれば、一時的オブジェクトの内容はＲＡＭに記憶できるが、ＥＥＰＲＯＭには決して記憶されない。この要件の目的は一時的オブジェクトがセッション・キーを記憶するのに使用できるようにするためである。
・一時的オブジェクトのフイールドへの書き込みは性能を悪くしてはいけない。（例として、現在のスマート・カード技術を取ると、一時的オブジェクトの内容はＲＡＭ内に記憶できるが、一時的でないオブジェクトの内容はＥＥＰＲＯＭ内に記憶できる。典型的に、ＲＡＭ技術はＥＥＰＲＯＭよりもずっと早い書込みサイクルを有する。）
・一時的オブジェクトのフアイルへの書込みは「トランザクション」により影響を受けない。すなわち、abortTransactionは決して一時的オブジェクト内のフイールドを前の値に回復しない。

この振舞いは、一時的オブジェクトを、しばしば修正されるがＣＡＤ又は選択セッションにわたって保存する必要の無い少量の一時的アプレット・データについて、理想的にする。
４．１ 一時的オブジェクトをクリアする出来事
持続性オブジェクトはカード・リセットをわたって持続されるべき状態を維持するために使用される。一時的オブジェクトが生成される時、そのフイールドをクリアするための１つ又は２つの出来事が指定される。クリア・オン・リセット一時的オブジェクトは、アプレット・セッションをわたって持続されるがカード・リセットをわたって持続されない状態を維持するために使用される。クリア・オン・デセレクト一時的オブジェクトは、アプレットが選択されている間は持続されるが、アプレット選択又はカード・リセットをわたっては持続しない状態を維持するために使用される。

２つのクリア出来事の詳細は以下の通りである。
・クリア・オン・リセット・オブジェクトのフイールドは、カードがリセットされる時にクリアされる。カードに電源が投入される時、これはカード・リセットを生ずる。

注−電源がカードから取除かれる前に一時的オブジェクトのフイールドをクリアする必要はない。しかし、このようなフイールドの内容は一旦電源が喪失すると回復できないことを保証する必要がある。
・クリア・オン・デセレクト・オブジェクトのフイールドは、アプレットの選択が解除された時には常にクリアされる。カード・リセットは黙示的に現在選択されたアプレットの選択を解除するため、クリア・オン・デセレクト・オブジェクトのフイールドはまた、クリア・オン・リセットのために指定された同じ出来事によりクリアされる。

現在選択されているアプレットは、選択命令が処理される時のみに明示的に選択が解除される。現在選択されたアプレットは選択が解除され、そして全てのクリア・オン・デセレクト一時的オブジェクトのフイールドは、選択命令が以下の状態にかかわらず、クリアされる。
・アプレットの選択に失敗。
・異なるアプレットを選択。
・同じアプレットを再選択。
５． 選択
カードは、ＡＰＤＵの形式でＣＡＤからサービスの要求を受取る。ＳＥＬＥＣＴ ＡＰＤＵはＪＣＲＥにより現在選択されているアプレットを指定するのに使用される。一旦、選択されると、アプレットは選択が解除されるまで、全ての以降のＡＰＤＵを受取る。

以下のいずれかが発生する時、現在選択されているアプレットは存在しない。
・カードがリセットされ、そしてアプレットがデフォルト・アプレットとして前もって指定されていない。
・アプレットの選択を試みた時、選択命令が失敗する。
５．１ デフォルト・アプレット
普通、アプレットは成功した選択命令を介してのみ選択される。しかし、あるスマート・カードＣＡＤアプリケーションは、各カード・リセット後に、黙示的に選択されるデフォルト・アプレットの存在を必要とする。その振舞いは、
１． カード・リセット（又は、リセットの形式の電源投入）後、ＪＣＲＥはその初期化を行ない、その内部状態が特定のアプレットがデフォルト・アプレットであると示しているかを検査する。もしそうならば、ＪＣＲＥはこのアプレットを現在選択されたアプレットとし、そのアプレットのセレクト・メソッドがコールされる。もしアプレットのセレクト・メソッドが例外を投げ又は誤りを返すと、ＪＣＲＥはその状態をアプレットが選択されないことを示す状態に設定する。（デフォルト・アプレット選択中にはＳＥＬＥＣＴ ＡＰＤＵが無いため、アプレットのプロセス・メソッドはコールされない。）デフォルト・アプレットがカード・リセットにおいて選択される時、そのプロセス・メソッドがコールされる必要はない。
２． ＪＣＲＥはＡＴＲが送られることを保証し、そしてカードは現在ＡＰＤＵ命令を受取るための用意ができている。

もしデフォルト・アプレットが成功的に選択されると、ＡＰＤＵ命令はこのアプレットに直接的に送られることができる。もしデフォルト・アプレットが選択されなければ、選択命令のみが処理できる。

デフォルト・アプレットを指定するための機構はジャバ・カードＡＰＩ２．１には定義されていない。それはＪＣＲＥ実現の詳細であり、個々のＪＣＲＥ実現者に任されている。
５．２ 選択命令処理
ＳＥＬＥＣＴ ＡＰＤＵ命令はアプレットを選択するのに使用される。その振舞いは、
１． アプレットがもしあれば活動的かどうかにかかわらず、ＪＣＲＥによりＳＥＬＥＣＴ ＡＰＤＵは常に処理される。
２． ＪＣＲＥは一致したＡＩＤについて内部テーブルを探す。ＪＣＲＥは選択命令中に完全なＡＩＤがある場合、アプレットの選択を支援する。

ＪＣＲＥ実現者は、他の選択基準を支援するために彼等のＪＣＲＥを増強することは自由である。この一例は、ＩＳＯ７８１６−１４に説明されるように部分的なＡＩＤ一致を介しての選択である。特別な要件は以下の通りである。
注−星印はＩＳＯ７８１６内の２進値ビット番号を示す。最上位ビット＝ｂ８、最下位ビット＝ｂ１である。

ａ）アプレット選択命令は、CLA=0x00,INS=0xA4、を使用する。
ｂ）アプレット選択命令は、「ＤＦ名による選択」を使用する。従って、P1=0x04である。

ｃ）P1の他の値はアプレット選択を示唆しない。ＡＰＤＵは現在選択されたアプレットにより処理される。

ｄ）ＪＣＲＥは、正確なＤＦ名（ＡＩＤ）選択、すなわち、P2=%b0000xx00(b4,b3*は無視)、を支援する。

ｅ）全ての他の部分ＤＦ名選択オプション(b2,b1*)は、ＪＣＲＥ実現に依存する。
ｆ）全てのフアイル制御情報オプション・コード(b4,b3*)は、ＪＣＲＥにより支援され、そしてアプレットにより解釈されそして処理される。
３． もしＡＩＤ一致が見つからなければ、
ａ．もし現在選択されたアプレットが存在しなければ、ＪＣＲＥは選択命令に状態コード0x6999(SW_APPLET_SELECT_FAILED)でもって返答する。

ｂ．それ以外は、選択命令は、現在選択されたアプレットのプロセス・メソッドに送られる。この点で、アプレットのコンテキストへのコンテキスト切換えが発生する。（アプレット・コンテキストはパラグラフ６．１．１．で定義される。）アプレットは、それら自身の内部選択処理のためにＳＥＬＥＣＴ ＡＰＤＵ命令を使用できる。
４． もし一致したＡＩＤが見つかれば、ＪＣＲＥは新しいアプレットを選択する準備をする。もし現在選択されたアプレットが存在すれば、そのデセレクト・メソッドへのコールを介して選択解除される。この時点で選択解除されたアプレットのコンテキストへのコンテキスト切換えが生ずる。ＪＣＲＥコンテキストはデセレクトからの出口において回復される。
５． ＪＣＲＥは、新たに現在選択されたアプレットを設定する。新しいアプレットは、そのセレクト・メソッドへのコールを介して選択される。そして新しいアプレットのコンテキストへのコンテキスト切換えが発生する。

ａ．もしアプレットのセレクト・メソッドが例外を投げる又は誤りを戻すと、ＪＣＲＥ状態はアプレットが選択されないように設定される。ＪＣＲＥは選択命令に対して状態コード0x6999(SW_APPLET_SELECT_FAILED)でもって返答する。

ｂ．新たに現在の選択されたアプレットのプロセス・メソッドは、入力パラメータとしてＳＥＬＥＣＴ ＡＰＤＵと共にコールされる。アプレットのコンテキストへのコンテキスト切換えが発生する。
注−もし一致するＡＩＤが存在しなければ、選択命令は通常のアプレットＡＰＤＵ命令として処理するために現在選択されたアプレット（もし有れば）に送られる。

もし、一致するＡＩＤが存在し、そして選択命令が失敗すると、ＪＣＲＥは常にアプレットが選択されない状態にはいる。

もし、一致するＡＩＤが現在選択されたアプレットと同じならば、ＪＣＲＥはアプレットの選択を解除するプロセスを経過して、そしてそれを選択する。再選択は失敗することがあり、カードをアプレットが選択されない状態にする。
５．３ 非選択命令処理
非選択ＡＰＤＵが受取られ、そして現在選択されたアプレットが存在しない時、ＪＣＲＥはＡＰＤＵに状態コード0x6999(SW_APPLET_SELECT_FAILED)でもって返答する。

非選択ＡＰＤＵが受取られ、そして現在選択されたアプレットが存在する時、ＪＣＲＥは現在選択されたアプレットのプロセス・メソッドを呼出して、ＡＰＤＵをパラメータとして送る。これは、ＪＣＲＥコンテキストから現在選択されたアプレットのコンテキストへのコンテキスト切換えを生ずる。プロセス・メソッドが存在する時、ＶＭはＪＣＲＥコンテキストへ戻される。ＪＣＲＥは返答をＡＰＤＵへ送る。そして次の命令ＡＰＤＵを待つ。
６． アプレット隔離及びオブジェクト共有
ＪＣＲＥのどんな実現もコンテキスト及びアプレットの隔離を支援する。隔離とは、他のアプレットが明示的にアクセスのためのインターフエイスを与えなければ、アプレットは別のコンテキスト内のアプレットのオブジェクト又はフイールドにアクセスすることができないことを意味する。
６．１ アプレット・フアイヤウォール
ジャバ・カード技術内のアプレット・フアイヤウォールは実行時実施保護であり、ジャバ技術保護とは別である。ジャバ言語保護はジャバ・カード・アプレットへ適用される。ジャバ言語は強いタイピングと保護属性を実施することを保証する。

アプレット・フアイヤウォールは常にジャバ・カードＶＭ内で実施される。これらは、ＶＭを実行時に自動的に追加のセキュリテイ検査を実行することを可能にする。
６．１．１ コンテキスト及びコンテキスト切換え
フアイヤウォールは本質的にジャバ・カード・プラットホームのオブジェクト・システムを、コンテキストと呼ばれる分離した保護されたオブジェクト空間に区分する。フアイヤウォールは、１つのコンテキストと別の間の境界である。ＪＣＲＥはカード上にインストールされている各アプレットに対するアプレット・コンテキストを割当てそして管理する（しかし、グループ・コンテキストの議論について下のパラグラフ６．１．１．２を参照）。

これに加え、ＪＣＲＥはそれ自身のＪＣＲＥコンテキストを維持する。このコンテキストはアプレット・コンテキストと大変似ている。しかし、それはアプレット・コンテキストには否定された操作を実行することができるように特別なシステム特権を有する。

どの時点においても、ＶＭ内には１つのみの活動的なコンテキスト存在する。（これが現在活動的なコンテキストと呼ばれる。）オブジェクトにアクセスする全てのバイトコードは、アクセスが許可されるかどうかを決定するために、現在活動的なコンテキストに対して実行時に検査される。アクセスが不許可の時、java.lang.SecurityExceptionが投げられる。

パラグラフ６．２．８に記述するように、呼出しタイプ・バイトコードの実行中に、ある良く定義された条件が満足される時、ＶＭはコンテキスト切換えを実行する。前のコンテキストは、内部ＶＭスタックに押し込められて、新しいコンテキストが現在活動的なコンテキストとなり、呼出されたメソッドがこの新しいコンテキスト内で実行する。メソッドから出る時、ＶＭはコンテキスト切換えの回復を実行する。元のコンテキスト（メソッドをコールした）はスタックから取出されて、現在活動的なコンテキストとして回復される。コンテキスト切換えはネストできる。最大の深さは、利用可能なＶＭスタック空間の量に依存する。

ジャバ・カード技術内での大部分のメソッドの呼出しは、コンテキスト切換えを生じない。コンテキスト切換えは、あるメソッドからの戻りと呼出し中及びそれらのメソッドからの例外出口中のみに生ずる（６．２．８参照）。

コンテキスト切換えメソッド呼出し中、現在活動的なコンテキストを示すデータの追加の部分が戻りスタック内に押し込まれる。メソッドが出る時にこのコンテキストが回復される。

この章の以下の部分においてコンテキスト及びコンテキスト切換えのさらなる詳細が与えられる。
６．１．１．１ グループ・コンテキスト
普通、ジャバ・カード・アプレットの各インスタンスは別のコンテキストを定義する。しかし、ジャバ・カード２．１技術では、グループ・コンテキストの概念が導入される。もし２以上のアプレットが、１つのジャバ・パッケージ内に含まれる時、それらは同じコンテキストを共有する。これに加え、同じアプレット・クラスの全てのインスタンスは同じコンテキストを共有する。換言すれば、グループ・コンテキスト内の２つのアプレット・インスタンス間にフアイヤウォールは存在しない。

節６．１．１内の上記コンテキスト及びコンテキスト切換えの説明は、各アプレット・インスタンスが別のコンテキストと関連していると仮定している。ジャバ・カード２．１技術では、フアイヤウォールを実施するためにコンテキストが比較される。そしてインスタンスＡＩＤがスタック内に押し込まれる。これに加えて、これはコンテキスト切換えの時だけではなく、１つのアプレット・インスタンスにより所有されたオブジェクトから同じパッケージ内の別のインスタンスにより所有されたオブジェクトへの制御切換えの時にも生ずる。
６．１．２ オブジェクト所有
新しいオブジェクトが生成される時、それは現在活動的なコンテキストと関連付けられる。しかし、オブジェクトは、オブジェクトが具体化される時に現在活動的なコンテキスト内のアプレット・インスタンスにより所有される。オブジェクトはアプレット・インスタンス又はＪＣＲＥにより所有される。
６．１．３ オブジェクト・アクセス
一般に、オブジェクトはその所有するコンテキストによりのみアクセスできる。すなわち、所有コンテキストが現在活動的なコンテキストである時。フアイヤウォールが異なるコンテキスト内の別のアプレットによりオブジェクトがアクセスされることを防ぐ。

実現の観点では、オブジェクトがアクセスされる時は何時でも、オブジェクトの所有コンテキストが現在活動的なコンテキストと比較される。もしこれらが一致しなければ、アクセスは実行されず、SecurityExceptionが投げられる。
オブジェクトの参照を使用して、以下のバイトコードの１つが実行される時、オブジェクトがアクセスされる。

Getfield, putfield, invokevirtual, invokeinterface, athrow,<T>aload, <T>astore, arraylength, checkcast, instanceof, <T> は、baload、sastore等、さまざまなタイプのバイトコード配列を言う。

このリストは、getfield_b, sgetfield_s_this,等、ジャバ・カードＶＭ内で実現されるこれらのバイトコードの特別な又は最適化された形を含む。
６．１．４ フアイヤウォール保護
ジャバ・カード・フアイヤウォールは、最もしばしば予期されるセキュリテイ問題、大切なデータを別のアプレットに「漏らす」ような開発者の誤り及び設計の見過ごし、に対して保護を与える。アプレットは公にアクセス可能な場所からオブジェクトの参照を得ることができるかもしれないが、しかし、オブジェクトが異なるアプレットに所有されていると、フアイヤウォールはセキュリテイを保証する。

フアイヤウォールはまた、間違ったコードに対して保護を与える。もしカードに誤ったコードがロードされると、フアイヤウォールはこのコードからオブジェクトがアクセスされることを保護する。

ジャバ・カードＡＰＩ２．１は、これらの特徴がアプレット開発者には透明ではない方法で支援されるため、フアイヤウォール及びコンテキストの基本的な最小保護要件を説明する。開発者は、ＡＰＩ、フアイヤウォールに関する例外、及び、オブジェクトの振舞いについて知らなければならない。

ＪＣＲＥ実現は、これらの機構がアプレットに透明で且つＶＭの外部に見える操作を変更しない限り、これらのアプレット・フアイヤウォールを越えて、追加のセキュリテイ機構を実現することは自由である。
６．１．５ 静的フイールド及びメソッド
クラスはコンテキストにより所有されないことに注意すべきである。クラス静的フイールドがアクセスされる時、実行される実行時コンテキスト検査はない。静的メソッドが呼出される時、コンテキスト切換えはない。（同様に、invokespecialはコンテキスト切換えを生じない）
パブリック静的フイールド及びパブリック静的メソッドは、どんなコンテキストからもアクセス可能である。静的メソッドはそれらを呼出したのと同じコンテキスト内で実行される。

静的フイールド内で参照されるオブジェクトは普通のオブジェクトである。これらはこれらを生成したものより所有され、標準のフアイヤウォール・アクセス規則が適用される。もしそれらが複数のアプレット・コンテキストに横断して共有される必要があるならば、これらは共有可能インターフエイス・オブジェクト（ＳＩＯ）である必要がある。（以下のパラグラフ６．２．４参照）
もちろん、通常のジャバ技術保護が静的フイールド及びメソッドに対して実施できる。これに加え、アプレットがインストールされる時、インストーラは外部の静的フイールド又はメソッドへのリンクの各試みが許可されることを確証する。インストレーションとリンケージについての仕様はこの仕様の範囲外である。
６．１．５．１ 選択的静的アクセス検査
ＪＣＲＥは、確証者により実施される制約と冗長なオプショナルな実行時検査を実行できる。ジャバ・カードＶＭは、コードが別のクラスのプライベートなメソッドの呼出しなど、基本的な言語制限に違反する時、検出して、報告し、又は違反に対処する。
６．２ コンテキストを横断するオブジェクトへのアクセス
アプレットが互いに相互作用し、又は、ＪＣＲＥと相互作用することを可能にするため、１つのコンテキストが別のコンテキストに属するオブジェクトにアクセスすることができる、良く定義され且つ安全な機構が提供される。

これらの機構は、ジャバ・カードＡＰＩ２．１において与えられ、そして以下の節で説明される。
・ＪＣＲＥ入口点オブジェクト
・グローバル配列
・ＪＣＲＥ特権
・共有可能インターフエイス
６．２．１ ＪＣＲＥ入口点オブジェクト
安全なコンピュータ・システムは、非特権ユーザ・プロセス（資源の一部に限定された）が、特権的な「システム」ルーチンにより実行されるシステム・サービスを要求するための方法を持たなければならない。

ジャバ・カードＡＰＩ２．１では、これはＪＣＲＥ入口点オブジェクトを使用して達成される。これらはＪＣＲＥコンテキストにより所有されるオフジェクトであるが、しかしそれらは入口点メソッドを含むとしてフラグが立てられている。

フアイヤウォールは、これらのオブジェクトをアプレットによるアクセスから保護する。入口点指定はこれらのオブジェクトのメソッドがどんなコンテキストからも呼出されることを可能にする。それが発生する時、ＪＣＲＥコンテキストへのコンテキスト切換えが実行される。これらのメソッドは、アプレットが特権ＪＣＲＥシステム・サービスを要求するゲートである。

ＪＣＲＥ入口点オブジェクトには２つの分類がある。
・一時的ＪＣＲＥ入口点オブジェクト
全てのＪＣＲＥ入口点オブジェクトと同様に、一時的ＪＣＲＥ入口点オブジェクトのメソッドは、どんなアプレットのコンテキストから呼出されることができる。しかし、これらのオブジェクトへの参照は、クラス変数、インスタンス変数、又は配列要素内には記憶することができない。ＪＣＲＥは、これらのオブジェクトへの参照の記憶の試みを、認証されない再使用を防ぐために、フアイヤウォール機能の一部として検出して制限する。

ＡＰＤＵオブジェクト及び全てのＪＣＲＥ所有例外オブジェクトは、一時的ＪＣＲＥ入口点オブジェクトの例である。
・永久ＪＣＲＥ入口点オブジェクト
全てのＪＣＲＥ入口点オブジェクトと同様に、永久ＪＣＲＥ入口点オブジェクトのメソッドは、どんなアプレットのコンテキストから呼出されることができる。これに加えて、これらのオブジェクトへの参照は記憶でき、自由に再使用できる。

ＪＣＲＥ所有ＡＩＤインスタンスは、永久ＪＣＲＥ入口点ポイントの例である。
ＪＣＲＥは、以下の責任を有する。
・どんな特権的サービスがアプレットに提供できるかを決定する。
・それらのサービスへの入口点メソッドを含むクラスを定義する。
・それらのクラスの１又は複数のオブジェクト・インスタンスを生成する。
・それらのインスタンスをＪＣＲＥ入口点オブジェクトと指定する。
・ＪＣＲＥ入口点オブジェクトを一時的又は永久と指定する。
・必要に応じてこれらのオブジェクトへの参照をアプレットに利用可能にする。
注−これらのオブジェクトのメソッドのみがフアイヤウォールを通じてアクセス可能にする。これらのオブジェクトのフイールドはフアイヤウォールにより保護されていて、ＪＣＲＥコンテキストのみによりアクセス可能である。

ＪＣＲＥ自身のみが入口点オブジェクト及びそれらが一時的又は永久かを指定できる。ＪＣＲＥ実現者は、ＪＣＲＥ入口点オブジェクトが指定されそしてそれらがどのように一時的又は永久的になるかの機構の実現に責任を有する。
６．２．２ グローバル配列
いくつかのオブジェクトのグローバル性質はそれらがどんなアプレット・コンテキストからもアクセス可能であることを要求する。フアイヤウォールは通常、これらオブジェクトが柔軟な態様で使用されることを防ぐ。ジャバ・カードＶＭはオブジェクトがグローバルとして指定されることを可能にする。

全てのグローバル配列は一時的グローバル配列オブジェクトである。これらオブジェクトはＪＣＲＥコンテキストにより所有されるが、どんなアプレット・コンテキストからもアクセスできる。しかし、これらのオブジェクトへの参照はクラス変数、インスタンス変数又は配列要素内には記憶できない。ＪＣＲＥはこれらのオブジェクトへの参照の記憶の試みを、認証されない再使用を防ぐためにフアイヤウォール機能の一部として検出して制限する。

追加のセキュリテイのため、配列のみがグローバルと指定でき、そしてＪＣＲＥ自身のみがグローバル配列を指定できる。アプレットがそれらを生成できないため、ＡＰＩメソッドは定義されない。ＪＣＲＥ実現者はグローバル配列が指定される機構を実現する責任がある。

この仕様の刊行時に、ジャバ・カードＡＰＩ２．１に要求されるグローバル配列は、ＡＰＤＵバッフア及びアプレットのインストール・メソッドへのバイト配列入力パラメータ（ｂ配列）のみである。
注−そのグローバル地位のため、アプレットが選択される時は常に、ＪＣＲＥが新しいＡＰＤＵ命令を受取る前に、ＡＰＤＵバッフアがゼロにクリアされることをＡＰＩは指定する。これは、アプレットの潜在的な重要なデータがグローバルＡＰＤＵバッフアを経由して他のアプレットへ「漏れる」ことを防止する。ＡＰＤＵバッフアは、共有インターフエイス・オブジェクト・コンテキストからアクセスでき、アプレット・今テキストを横断してデータを送るのに適している。アプレットは、ＡＰＤＵバッフアからアクセスされる秘密データを保護する責任がある。
６．２．３ ＪＣＲＥ特権
「システム」コンテキストであるため、ＪＣＲＥコンテキストは特別な特権を有する。それはカード上のどんなオブジェクトのメソッドも呼出すことができる。例えば、オブジェクトＸがアプレットＡにより所有されていると仮定すると、普通、コンテキストＡのみがフイールド及びＸのメソッドをアクセスできる。しかし、ＪＣＲＥコンテキストはＸのどんなメソッドも呼出すことができる。このような呼出し中、コンテキスト切換えが、ＪＣＲＥコンテキストからＸを所有するアプレット・コンテキストへ生ずる。
注−ＪＣＲＥは、Ｘのメソッド及びフイールドの両方をアクセスできる。メソッドのアクセスはＪＣＲＥがアプレット・コンテキストに入るための機構である。ＪＣＲＥはフアイヤウォールを介してどんなメソッドも呼出すことができるが、アプレット・クラスで定義された、select,process,deselect,getShareableInterfaceObjectメソッド（６．２．７．１参照）のみを呼出すべきである。

ＪＣＲＥコンテキストは、ＶＭがカード・リセット後に実行を開始する時の現在活動的なコンテキストである。ＪＣＲＥコンテキストは「ルート」コンテキストであり、常に現在活動的なコンテキスト又はスタックに記憶された底コンテキストのいずれかである。
６．２．４ 共有可能インターフエイス
共有可能インターフエイスは、アプレット相互作用を可能にするためのジャバ・カードＡＰＩ２．１の新しい特徴である。共有可能インターフエイスは、１組の共有されたインターフエイス・メソッドを定義する。これらのインターフエイス・メソッドは、もしそれらを実現するオブジェクトが別のアプレット・コンテキストにより所有されていても、１つのアプレット・コンテキストから呼出すことができる。

この仕様では、共有可能インターフエイスを実現するクラスのオブジェクト・インターフエイスは、共有可能インターフエイス・オブジェクト（ＳＩＯ）と呼ばれる。

所有コンテキストには、ＳＩＯはそのフイールド及びメソッドがアクセスできる普通のオブジェクトである。その他のコンテキストには、ＳＩＯは共有可能なインターフエイスのインスタンスであり、共有可能インターフエイス内で定義されたメソッドのみがアクセス可能である。ＳＩＯのその他の全てのフイールド及びメソッドはフアイヤウォールにより保護される。

共有可能インターフエイスは、アプレット間通信のための安全な機構を以下の様に与える。
１． オブジェクトを別のアプレットに利用可能にするため、アプレットＡは最初に共有可能インターフエイスＳＩを定義する。共有可能インターフエイスはインターフエイス、javacard.framework.Shareable、を拡張する。共有可能インターフエイスＳＩに定義されたメソッドは、アプレットＡが他のアプレットにアクセス可能にしたサービスを表す。
２． そして、アプレットＡは共有可能インターフエイスＳＩを実現するクラスＣを定義する。ＣはＳＩ内に定義されたメソッドを実現する。Ｃは他のメソッド及びフイールドも定義してもよいが、これらはアプレット・フアイヤウォールで保護されている。ＳＩ内で定義されているメソッドのみが他のアプレットにとりアクセス可能である。
３． アプレットＡは、クラスＣのオブジェクト・インスタンスＯを生成する。ＯはアプレットＡに属し、フアイヤウォールはＡがＯのどんなフイールド及びメソッドもアクセスすることを可能にする。
４． アプレットＡのオブジェクトＯにアクセスするために、アプレットＢはタイプＳＩのオブジェクト参照ＳＩＯを生成する。
５． アプレットＢは、アプレットＡから共有されたインターフエイス・オブジェクト参照を要求するために特別なメソッド（パラグラフ６．２．７．２に記載されたJCSystem.getAppletShareableInterfaceObject）を呼出す。
６． アプレットＡは、要求及びApplet.getShareableInterfaceObjectを経由して要求者（Ｂ）のＡＩＤを受取り、そしてそれがアプレットＢとオブジェクトＯを共有するかどうかを決定する。
７． もしアプレットＡが、アプレットＢと共有を同意すれば、ＡはＯへの参照と共に要求に応答する。この参照はＯのメソッド又はフイールドのいずれも見えないようにするために、Ｓｈａｒｅａｂｌｅをタイプするためのキャストである。
８． アプレットＢはアプレットＡからオブジェクト参照を受取り、それをＳＩをタイプするためにキャストし、それをオブジェクト参照ＳＩＯ内に記憶する。ＳＩＯは実際にＡのオブジェクトＯを参照するが、ＳＩＯはタイプＳＩである。ＳＩで定義された共有可能インターフエイス・メソッドのみがＢに見える。フアイヤウォールはＯの他のフイールド及びメソッドがＢによりアクセスされることを防止する。
９． アプレットＢは、ＳＩＯの共有可能なインフエイス・メソッドの１つを呼出すことにより、アプレットＡからのサービスを要求できる。呼出し中、ジャバ・カードＶＭはコンテキスト切換えを実行する。元の現在活動的なコンテキスト（Ｂ）はスタック上に記憶され、そして実際のオブジェクト（Ｏ）の所有者（Ａ）のコンテキストが新しく現在活動的なコンテキストとなる。共有可能インターフエイス・メソッド（ＳＩメソッド）のＡの実現がＡのコンテキスト中で実行される。
１０． ＳＩメソッドは、JCSystem.getPreviousContextAIDメソッドを介してそのクライアント（Ｂ）のＡＩＤを見付けることができる。これはパラグラフ６．３２．５内に記載されている。このメソッドはアプレットＢのためにサービスを実行するかどうかを決定する。
１１． コンテキスト切換えのため、フアイヤウォールは、ＳＩメソッドがオブジェクトＯの全てのメソッド及びフイールド及びＡにより所有されるその他のオブジェクトにアクセスすることを可能にする。同時に、フアイヤウォールはメソッドがＢにより所有された非共有オブジェクトをアクセスすることを防止する。
１２． ＳＩメソッドは、Ｂにより送られたパラメータをアクセスでき、そしてＢに戻り値を与えることができる。
１３． 戻る際に、ジャバ・カードＶＭはコンテキスト切換えの回復を実行する。元の現在活動的なコンテキスト（Ｂ）がスタックから押出されて、再び、現在のコンテキストとなる。
１４． コンテキスト切換えのため、フアイヤウォールは再び、Ｂがそのオブジェクトのいずれにもアクセスすることを可能にし、そしてＢがＡ所有の非共有オブジェクトにアクセスすることを防止する。
６．２．５ 前のコンテキストの決定
アプレットが、JCSystem.getPreviousContextAIDをコールする時、ＪＣＲＥは最後のコンテキスト切換えの時に活動的なアプレット・インスタンスのインスタンスＡＩＤを戻す。
６．２．５．１ ＪＣＲＥコンテキスト
ＪＣＲＥコンテキストはＡＩＤを持たない。アプレット・コンテキストがＪＣＲＥから直接に入った時、もしアプレットが、getPreviousContextAIDをコールすれば、このメソッドは無効を返答する。

もしアプレットが、アプレット自身から又は共有可能インターフエイスを介してアクセスされている時に外部アプレットからアクセスされているメソッドから、getPreviousContextAIDをコールすれば、それは呼出し者ＡＩＤ認証を実行する前に、無効返答を検査する。
６．２．６ 共有可能インターフエイス詳細
共有可能インターフエイスは、単にタッギング・インターフエイス、javacard.framework.Shareable、を拡張（直接的又は間接的のいずれかで）したものである。この共有可能インターフエイスはＲＭＩフアシリテイにより使用された遠隔インターフエイスの概念的に類似していて、インターフエイス・メソッドへのコールは、ローカル／遠隔境界を横断して生ずる。
６．２．６．１ ジャバ・カード共有可能インターフエイス
共有可能タッギング・インターフエイスを拡張したインターフエイスはこの特別な性質を有する。インターフエイス・メソッドのコールはコンテキスト切換えによりジャバ・カードのアプレットのフアイヤウォール境界を横断して生ずる。

共有可能インターフエイスは全ての共有されたオブジェクトを識別する役割を有する。アプレット・フアイヤウォールを介して共有される必要のあるオブジェクトはこのインターフエイスを直接的に又は間接的に実現する。共有可能なインターフエイスに指定されたこれらの方法のみがフアイヤウォールを介して利用可能である。

実現クラスはどんな数の共有可能なインターフエイスも実現でき、その他の共有可能な実現クラスに拡張できる。

ジャバ・プラットホーム・インターフエイスと同じく、共有可能インターフエイスは単に１組のサービス・メソッドを定義する。サービス提供者クラスが共有可能インターフエイスを「実現」することを宣言し、インターフエイスのサービス・メソッドの各々の実現を提供する。サービス・クライアント・クラスが、オブジェクト参照を得て、もし必要ならば、共有可能インターフエイス・タイプにそれをキャストし、そしてインターフエイスのサービス・メソッドを呼び出すことにより、サービスにアクセスする。

ジャバ・カード技術内の共有可能インターフエイスは以下の性質を有する。
・共有可能インターフエイス内のメソッドが呼出された時、コンテキスト切換えがオブジェクト所有者のコンテキストへ生ずる。
・メソッドが出る時、コールしたもののコンテキストが回復される。
・例外が投げられた時に発生するスタック・フレームの巻き戻しの際に、現在活動的なコンテキストが正しく回復されるように、例外処理が増強される。
６．２．７ 共有可能インターフエイス・オブジェクトの獲得
アプレット間通信は、クライアント・アプレットがサーバー・アプレットに属するＳＩＯの共有可能インターフエイス・メソッドを呼出す時に達成される。これが動作するために、クライアント・アプレットが最初にサーバー・アプレットからＳＩＯを獲得するための方法がなければならない。ＪＣＲＥはこれを可能にする機構を与える。アプレット・クラス及びJCSystemクラスはクライアントがサーバーからサービスを要求することを可能にするメソッドを与える。
６．２．７．１ メソッド・アプレット.getShareableInterfaceObject
このメソッドは、サーバー・アプレット・インスタンスにより実現される。それは別のアプレットに属するオブジェクトを使用することを要求するクライアント・アプレットとオブジェクトを共有可能にするサーバー・アプレットとの間の調停をするため、ＪＣＲＥによりコールされなければならない。

デフォルトの振舞いは無効を返答する。これはアプレットはアプレット間通信に参加しないことを示す。

別のアプレットから呼出されることを意図されたサーバー・アプレットはこのメソッドを覆す必要が有る。このメソッドはクライアントＡＩＤとパラメータを検査する。もしクライアントＡＩＤが期待されたＡＩＤの１つでなければ、メソッドは無効を返答する。同様に、もしパラメータが認識されなければ、又は、もしそれがクライアントＡＩＤに許可されなければ、メソッドはまた無効を返す。それら以外は、アプレットはクライアントが要求した共有可能インターフエイス・タイプのＳＩＯを戻す。

サーバー・アプレットは、同じＳＩＯを全てのクライアントに返答する必要は無い。サーバーは異なる目的のために共有されたインターフエイスの複数のタイプを支援でき、クライアントへどの種類のＳＩＯを戻すかを決定するためにクライアントＡＩＤとパラメータを使用する。
６．２．７．２ メソッドJCSystem.getAppletShareableInterfaceObject
ＪＣＳｙｓｔｅｍクラスはメソッドgetAppletShareableInterfaceObjectを含む。これはサーバー・アプレットと通信するためにクライアント・アプレットにより呼出される。

ＪＣＲＥは以下の様に振舞うためにこのメソッドを実現する。
１． ＪＣＲＥはその内部アプレット・テーブル内でサーバーＡＩＤを持ったものを探す。見つからなければ、無効が戻される。
２． ＪＣＲＥは、このアプレットのgetShareableInterfaceObjectメソッドを呼出し、呼出したもののクライアントＡＩＤとパラメータを送る。
３． コンテキスト切換えがサーバー・アプレットへ生ずる。そして前記したようにgetShareableInterfaceObjectの実現が進行する。サーバー・アプレットはＳＩＯ（又は無効）を戻す。
４． GetAppletShareableInterfaceObjectは同じＳＩＯ（又は無効）をそのコールしたものに戻す。

増強されたセキュリテイのため、実現はクライアントが以下の状態のどれが無効値を戻したかを知ることが不可能にする。
・サーバーＡＩＤが見つからない。
・サーバー・アプレットはアプレット間通信に参加していない。
・サーバー・アプレットはクライアントＡＩＤ又はパラメータを認識しない。
・サーバー・アプレットはこのクライアントと通信しない。
・サーバー・アプレットはパラメータにより指定されたようにこのクライアントと通信しない。
６．２．８ クラス及びオブジェクト・アクセスの振舞い
静的クラス・フイールドは、以下の１つのジャバ・バイトコードが実行される時にアクセスされる。
getstatic, putstatic
オブジェクトは、以下の１つのジャバ・バイトコードがオブジェクト参照を使用して実行される時にアクセスされる。

Getfield, putfield, invokevirtual, invokeinterface, athrow,<T>aload, <T>astore, arraylength, checkcast, instanceof, <T> は、baload、sastore等、さまざまなタイプのバイトコード配列を言う。

このリストは、getfield_b, sgetfield_s_this,等、ジャバ・カードＶＭ内で実現されるこれらのバイトコードの特別な又は最適化された形を含む。

ジャバＶＭにより指定されたバイトコードの仕事を実行する前に、ジャバ・カードＶＭは参照されたオブジェクト上にアクセス検査を実行する。もしアクセスが否定されると、SecurityExceptionが投げられる。

ジャバ・カードＶＭにより実行されるアクセス検査は参照されたオブジェクト、バイトコード、及び現在活動的なコンテキストのタイプと所有者に依存する。それらは以降に説明される。
６．２．８．１ 静的クラス・フイールドへのアクセス
バイトコード：
getstatic, putstatic
・もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスが許可される。
・それ以外で、もしバイトコードがputstaticで、記憶されているフイールドが参照タイプで、記憶されている参照が一時ＪＣＲＥ入口点オブジェクト又はグローバル配列への参照であれば、アクセスは否定される。
・それ以外は、アクセスは許可される。
６．２．８．２ 配列オブジェクトへのアクセス
バイトコード：
<T>aload, <T>astore, arraylength, checkcast, instanceof
・もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスが許可される。
・それ以外は、もしバイトコードがaastoreで、記憶されている要素が参照タイプであり、記憶されている参照が一時ＪＣＲＥ入口点オブジェクト又はグローバル配列への参照であれば、アクセスは否定される。
・それ以外で、もし配列が現在活動的コンテキストにより所有されていれば、アクセスは許可される。
・それ以外で、配列がグローバルと指定されれば、アクセスは許可される。
・それ以外は、アクセスは否定される。
６．２．８．３ クラス・インスタンス・オブジェクト・フイールドへのアクセス
バイトコード：
getfield, putfield
・もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスが許可される。
・それ以外で、もしバイトコードがputfieldで、記憶されているフイールドが参照タイプで、記憶されている参照が一時ＪＣＲＥ入口点オブジェクト又はグローバル配列への参照であれば、アクセスは否定される。
・それ以外で、もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外は、アクセスは否定される。
６．２．８．４ クラス・インスタンス・オブジェクト・メソッドへのアクセス
バイトコード：
invokevirtual
・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。コンテキストはオブジェクトの所有者のコンテキストへ切り換えられる。
・それ以外で、もしオブジェクトがＪＣＲＥ入口点オブジェクトと指定されればアクセスは許可される。コンテキストはオブジェクトの所有者のコンテキスト（ＪＣＲＥの）へ切り換えられる。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスが許可される。コンテキストはオブジェクトの所有者のコンテキストへ切り換えられる。
・それ以外は、アクセスが否定される。
６．２．８．５ 標準インターフエイス・メソッドへのアクセス
バイトコード：
invokeinterface
・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスが許可される。コンテキストはオブジェクトの所有者のコンテキストへ切り換えられる。
・それ以外は、アクセスは拒否される。
６．２．８．６ 共有可能インターフエイス・メソッドへのアクセス
バイトコード：
invokeinterface・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外で、もしオブジェクトのクラスが共有可能インターフエイスを実現すれば、そしてもし呼出されるインターフエイスが共有可能インターフエイスを拡張すれば、アクセスは許可される。コンテキストはオブジェクトの所有者のコンテキストへ切り換えられる。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスが許可される。コンテキストはオブジェクトの所有者のコンテキストへ切り換えられる。
・それ以外は、アクセスは拒否される。
６．２．８．７ 例外オブジェクトを投げる
バイトコード：
athrow・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外で、もしオブジェクトがＪＣＲＥ入口点オブジェクトと指定されれば、アクセスは許可される。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスは許可される。
・それ以外は、アクセスは否定される。
６．２．８．８ クラス・インスタンス・オブジェクトへのアクセス
バイトコード
checkcast, instanceof
・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスは許可される。
・それ以外で、もしオブジェクトがＪＣＲＥ入口点オブジェクトと指定されれば、アクセスは許可される。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスは許可される。
・それ以外は、アクセスは否定される。
６．２．８．９ 標準インターフエイスへのアクセス
バイトコード
checkcast, instanceof
・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスは許可される。
・それ以外は、アクセスは否定される。
６．２．８．１０ 共有可能インターフエイスへのアクセス
バイトコード
checkcast, instanceof
・もしオブジェクトが現在活動的なコンテキストに所有されれば、アクセスは許可される。
・それ以外で、もしオブジェクトのクラスが共有可能インターフエイスを実現し、そしてもしオブジェクトが共有可能インターフエイスを拡張するインターフエイスにキャスト(checkcast)され又はそのインスタンス(instanceof)であれば、アクセスは許可される。
・それ以外で、もしＪＣＲＥが現在活動的なコンテキストであれば、アクセスは許可される。
・それ以外は、アクセスは否定される。
６．３ 一時的オブジェクト及びアプレット・コンテキスト
クリア・オン・リセット・タイプの一時的オブジェクトは、現在活動的なアプレット・コンテキストがオブジェクトの所有者（オブジェクトが生成された時に現在活動的なアプレット・コンテキスト）と同じ時のみにそれらがアクセスできるという点で、持続性オブジェクトと似た振舞いをする。

クリア・オン・デセレクト・タイプの一時的オフジェクトは、現在活動的なアプレット・コンテキストが現在選択されたアプレット・コンテキストである時のみに生成又はアクセスできる。もしどんなmakeTransientfactoryメソッドが、現在活動的なアプレット・コンテキストが現在選択されたアプレット・コンテキストでない時に、クリア・オン・デセレクト・タイプの一時的オブジェクトを生成するためにコールされると、メソッドは理由コード、ILLEGAL_TRANSIENT、と共に、SystemException、を投げる。もしクリア・オン・デセレクト・タイプの一時的オフジェクトへのアクセスが、現在活動的なアプレット・コンテキストが現在選択されたアプレット・コンテキストでない時に試みられた場合、ＪＣＲＥはSecurityExceptionを投げる。

同じパッケージの部分のアプレットは同じグループ・コンテキストを共有する。パッケージからの各アプレット・インスタンスは、同じパッケージからの全ての他のインスタンスと共に全てのそのオブジェクト・インスタンスを共有する。（これはこれらのアプレット・インスタンスにより所有されるクリア・オン・リセット・タイプ及びクリア・オン・デセレクト・タイプの両方の一時的オブジェクトを含む。）
同じパッケージ内のどんなアプレット・インスタンスにより所有されるクリア・オン・デセレクト・タイプの一時的オブジェクトは、このパッケージ内のいずれかのアプレット・インスタンスが現在選択されたアプレットである時に、アクセス可能である。
７． トランザクション及びアトミシテイ
トランザクションは、持続性データの更新の論理的組である。例えば、１つの口座から別の口座にある量のお金を移動することは銀行トランザクションである。トランザクションがアトミックであることが重要である。データ・フイールドの全てが更新されるか、又は全くされないかのいずれかである。ＪＣＲＥは、もしトランザクションが正常に終了しなければ、カードのデータはその元のトランザクション前状態に回復されるように、アトミック・トランザクションのための健全な支援を与える。この機構は、トランザクション中の電源喪失やプログラムエラーなどのもしトランザクションの全ステップが正常に終了しない場合にデータを壊すであろう出来事に対して、保護する。
７．１ アトミシテイ
アトミシテイは、１つのオブジェクト又はクラス・フイールド又は配列成分の更新中の停止、故障、又は致命的な例外の後に、持続性記憶の内容をカードがどのように処理するかを定義する。もし電源が更新中に喪失したならば、アプレット開発者は、電源が回復された時にフイールド又は配列成分が含むものに依存することができなければならない。

ジャバ・カード・プラットホームは、単一の持続性オブジェクト又はクラス・フイールドのどんな更新もアトミックであることを保証する。これに加えて、ジャバ・カード・プラットホームは、持続性配列に対して、単一成分レベル・アトミシテイを与える。すなわち、もしスマート・カードがＣＡＤセッションを横断して保存されるべきデータ要素（オブジェクト／クラス内のフイールド又は配列の成分）の更新中に電源を喪失すると、データ要素はその前の値に回復される。

いくつかのメソッドはまた、複数のデータ要素のブロック更新のためのアトミシテイを保証する。例えば、Util.arrayCopyメソッドのアトミシテイは、全てのバイトが正しくコピーされたか、又はそうでなければ宛先配列はその前のバイト値に回復されるかのいずれかを保証する。

アプレットは配列更新に対してアトミシテイを要求しないかもしれない。Util.arrayCopyNonAtomicメソッドは、この目的のために提供される。それは進行中のトランザクションと一緒にコールされた時でさえも、トランザクション・コミット・バッフアを使用しない。
７．２ トランザクション
アプレットは、いくつかの異なるオブジェクト内のいくつかの異なるフイールド又は配列成分を、アトミカリーに更新する必要があるかもしれない。全ての更新は、正確に且つ整合的に行なわれるか、そうでなければ、全てのフイールド／成分はそれらの前の値に回復されるかのいずれかである。

ジャバ・カード・プラットホームは、アプレットがJCSystem.beginTransactionメソッドへのコールと共に更新のアトミックな組の始まりを指定することができるトランザクション・モデルを支援する。この点の後の各オブジェクト更新は、条件付きで更新される。フイールド又は配列成分は更新されたかのように見える。フイールド／配列成分を読み返すとその最新の条件付き値が生ずる。しかし、更新はまだコミットされていない。

アプレットが、JCSystem.commitTransactionをコールする時、全て条件付きの更新が持続性記憶にコミットされる。JCSystem.commitTransactionの完了前に電源喪失又はその他のシステム故障が発生すると、全ての条件付更新フイールド又は配列成分はそれらの前の値に回復される。もしアプレットが、内部的問題に出会う又はトランザクションを取消すと決定した場合、それは、JCSystem.abortTransactionをコールすることにより条件付き更新をプログラム的に元に戻すことができる。
７．３ トランザクション期間
トランザクションは、ＪＣＲＥがアプレットのセレクト、デセレクト、プロセス、又はインストール・メソッドからの戻りの際にプログラム的制御を再獲得する時に、常に終了する。これは、トランザクションがアプレットのcommitTransactionへのコールでもって、又は、トランザクションの中止（アプレットによりプログラム的に又はＪＣＲＥによるデフォルトによるかのいずれか）でもって正常に終了するかにかかわらず、真である。トランザクション中止のさらなる詳細はパラグラフ７．６を参照。

トランザクション期間は、JCSystem.beginTransactionへのコールとcommitTransactionへのコール若しくはトランザクションの中止の間のトランザクションの一生である。
７．４ ネストされたトランザクション
現在のモデルは、ネストされたトランザクションは可能でないと仮定する。一時には１つのトランザクションだけが存在できる。もしトランザクションが既に進行中に、JCSystem.beginTransactiontがコールされると、TransactionExceptionが投げられる。

トランザクションが進行中がどうかを決定することができるように、JCSystem.transactionDepthメソッドが提供される。
７．５ トランザクション故障のリセット又はテイア
トランザクションが進行中に、電源が喪失（テイア）し、又は、カードがリセットされ、又は、その他のシステム故障が発生した場合、ＪＣＲＥは前のJCSystem.beginTransactionをコール以降の全てのフイールド及び配列の成分の条件付き更新をそれらの前の値に回復する。

この動作は、ＪＣＲＥにより自動的にカードを電源喪失、リセット、又は故障から回復した後に再初期化する時に、実行される。ＪＣＲＥはそれらのオブジェクトのどれが（もしあれば）条件付きで更新されたかを決定し、それらを回復する。
注−電源喪失又はカード・リセットにより失敗したトランザクション中に生成されたインスタンスにより使用されたオブジェクト空間は、ＪＣＲＥにより回復できる。
７．６ トランザクションの中止
トランザクションはアプレット又はＪＣＲＥのいずれかにより中止できる。
７．６．１ プログラム的中止
もしアプレットが内部的問題に出会い又はトランザクションを取消す決定をした場合、それはJCSystem.abortTransactionをコールすることにより、条件付き更新をプログラム的に元に戻すことができる。もしこのメソッドがコールされると、前のJCSystem.beginTransactionのコール以来の全ての条件付き更新されたフイールド又は配列成分はそれらの前の値に回復され、そして、JCSystem.transactionDepth値は０にリセットされる。
７．６．２ ＪＣＲＥによる中止
もしアプレットが進行中のトランザクションの際にセレクト、デセレクト、プロセス又はインストール・メソッドから戻ると、ＪＣＲＥは自動的にトランザクションを中止する。もしトランザクションの進行中にセレクト、デセレクト、プロセス、又はインストール・メソッドからの戻りが発生すると、ＪＣＲＥはあたかも例外が投げなれたように動作する。
７．６．３ ＪＣＲＥのクリーンアップ責任
中止されたトランザクションの際に生成されたオブジェクト・インスタンスは、もしこれらのオブジェクトについての全ての参照が探すことができて無効に変換できれば、削除できる。ＪＣＲＥは中止されたトランザクション中に生成されたオブジェクトについての参照は無効の参照に等しいことを保証する。
７．７ 一時的オブジェクト
持続性オブジェクトの更新のみがトランザクションに参加する。一時的オブジェクトの更新は、それらが「内部トランザクション」がどうかにかかわらず決して、元に回復されない。
７．８ コミット容量
プラットホーム資源が制限されるため、トランザクション中に蓄積できる条件付き更新データのバイト数は制限される。ジャバ・カード技術は、実現の際にどれだけのコミット容量が利用可能かを決定するメソッドを与える。コミット能力は、利用可能な条件付きバイト更新の数の上限を表す。マネージメント・オーバーヘッドのために利用できる条件付きバイト更新の実際の数はそれよりも少ない。

トランザクション中に、もしコミット容量を越えると、例外が投げられる。
８． ＡＰＩトピックス
この章のトピックスは、ジャバ・カード２．１ＡＰＩ草案２仕様に詳述された要件を補足する。第１トピックはＡＰＤＵクラス内に完全に実現されるジャバ・カードＩ／Ｏ機能である。第２トピックはＡＰＩ支援ジャバ・カード・セキュリテイと暗号である。JCSystem classはＡＰＩバージョン・レベルをカプセル化する。

ＡＰＩ内部のトランザクション
ジャバ・カード２．１ＡＰＩ仕様で特別に表示されなければ、ＡＰＩクラスの実現はトランザクションを開始したり、又は進行中であれば、トランザクションの状態を変更したりしない。

ＡＰＩ内部の資源の使用 ジャバ・カード２．１ＡＰＩ仕様で特別に表示されなければ、実現はオブジェクト・インスタンスの所有者が現在選択されたアプレットでない時でさえ、ＡＰＩインスタンス・メソッドの呼出しを支援する。換言すれば、特に表示されなければ、実現はクリア・オン・デセレクト・タイプの一時的オブジェクトなどの資源を使用しない。

ＡＰＩクラスにより投げられた例外 ＡＰＩ実現により投げられた全ての例外オブジェクトは、一時的ＪＣＲＥ入口点オブジェクトである。一時的ＪＣＲＥ入口点オブジェクトは、クラス変数、インスタンス変数、又は配列成分内に記憶することができない（参照６．２．１）。
８．１ ＡＰＤＵクラス
ＡＰＤＵクラスは、ＩＳＯ７８１６−４に基づいたカード・シリアル線を横断するＩ／Ｏへのアクセスをカプセル化する。ＡＰＤＵクラスは、下にあるＩ／Ｏトランスポート・プロトコルに独立に設計されている。
ＪＣＲＥは、Ｔ＝０又はＴ＝１トランスポート・プロトコル又は両方を支援する。
８．１．１ 外向きデータ転送のためのＴ＝０詳細
ブロック連鎖機構を支援しない旧式のＣＡＤ／ターミナルとの互換性のため、ＡＰＤＵクラスは、setOutgoingNoChainingメソッドを介してモード選択を可能にする。
８．１．１．１ 連鎖無しの制約された転送 setOutgoingNoChainingメソッドをコールすることによりアプレットにより要求された出力転送の無連鎖モードの時、以下のプロトコル順序が続く。
注−無連鎖モードが使用される時、waitExtensionメソッドへのコールは理由コード、ILLEGAL_USE、と共に、APDUException、を投げる。
表記
Ｌｅ＝ＣＡＤが期待する長さ。

Ｌｒ＝setOutgoingLengthメソッドを介して設定されたアプレット返答長さ。
＜ＩＮＳ＞＝次に転送される全データ・バイトを示す、入力ヘッダーＩＮＳバイトに等しいプロトコル・バイト。

＜〜ＩＮＳ＞＝次に転送される約１データ・バイトを示す、入力ヘッダーＩＮＳバイトの補数であるプロトコル・バイト。

＜ＳＷ１，ＳＷ２＞＝ＩＳＯ７８１６−４内のような応答状態バイト。
ＩＳＯ７８１６−４ ケース２
Ｌｅ＝＝Ｌｒ
１．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用して、Ｌｒバイトの出力データを送信する。

２．カードが、Applet.processメソッドの完了時に＜ＳＷ１，ＳＷ２＞完了状態を送信する。

Ｌｒ＜Ｌｅ
１．カードが、＜０ｘ６１，Ｌｒ＞完了状態バイトを送信する。

２．ＣＡＤが、Ｌｅ＝ＬｒでもってＧＥＴ ＲＥＳＰＯＮＳＥ命令を送信する。
３．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用して、Ｌｒバイトの出力データを送信する。

４．カードが、Applet.processメソッドの完了時に＜ＳＷ１，ＳＷ２＞完了状態を送信する。

Ｌｒ＞Ｌｅ
１．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用して、Ｌｅバイトの出力データを送信する。

２．カードが、＜０ｘ６１，（Ｌｒ−Ｌｅ）＞完了状態バイトを送信する。
３．ＣＡＤが、新Ｌｅ＜＝Ｌｒで持つＧＥＴ ＲＥＳＰＯＮＳＥ命令を送信する。

４．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用して、（新）Ｌｅバイトの出力データを送信する。

５．要求されるならば残りの出力データ・バイト（Ｌｒ）を送るのに必要なステップ２−４を繰返す。

６．カードが、Applet.processメソッドの完了時に＜ＳＷ１，ＳＷ２＞完了状態を送信する。
ＩＳＯ７８１６−４ ケース４
ケース４において、Ｌｅは以下の初期交換後に決定される。

１．カードが、＜０ｘ６１，Ｌｒ状態バイト＞を送信する。
２．ＣＡＤが、Ｌｅ＜＝Ｌｒを持つＧＥＴ ＲＥＳＰＯＮＳＥ命令を送信する。

プロトコル順序の残りは、上記のケース２と同じ。
もし、アプレットが早く中止してＬｅバイトよりも少なく送信すると、ＣＡＤが期待する転送長を満たすためにゼロが代りに送られてもよい。
８．１．１．２ 通常の出力転送
アプレットにより出力転送の無連鎖モードが要求されない時（すなわち、setOutgoing方法が使用される）、以下のプロトコル順序が続く。
どんなＩＳＯ−７８１６−３／４準拠Ｔ＝０プロトコル転送順序が使用できる。
注−sendBytes又はsendBytesLongメソッドの連続したコール間でアプレットにより、waitExtensionメソッドを呼出すことができる。waitExtensionメソッドは、0x60手順バイトを使用して追加の作業時間を要求する（ＩＳＯ−７８１６−３）。
８．１．１．３ 追加的Ｔ＝０要件
何時でも、Ｔ＝０出力転送プロトコルが使用中で、そしてＡＰＤＵクラスがカードからの＜０ｘ６１，ｘｘ＞の返答状態に応答してＣＡＤからのＧＥＴ ＲＥＳＰＯＮＳＥ命令を待っている時、もしＣＡＤが異なる命令を送れば、sendBytes又はsendBytesLongメソッドは理由コードNO_TO_GETRESPONSEと共にAPDUExceptionを投げる。

この点からのsendBytes又はsendBytesLongメソッドへのコールは、理由コードILLEGAL_USEと共にAPDUExceptionを生ずる。もし、NO_T0_GETRESPONSE例外が投げられた後に、アプレットによりISOExceptionが投げられると、ＪＣＲＥはその理由コードの返答状態を破棄する。ＪＣＲＥは新たに受取った命令と共にＡＰＤＵを再開し、ＡＰＤＵの発送を再開する。
８．１．２ 外向きデータ転送のためのＴ＝１詳細
８．１．２．１ 無連鎖転送の制約
setOutgoingNoChainingメソッドをコールすることによりアプレットにより要求された出力転送の無連鎖モードの時、以下のプロトコル順序が続く。
表記
Ｌｅ＝ＣＡＤが期待する長さ。

Ｌｒ＝setOutgoingLengthメソッドを介して設定されるアプレット返答長さ。
トランスポート・プロトコル順序ブロック連鎖を使用しない。転送中にＭビット（より多くのデータ・ビット）はＩブロックのＰＣＢ内に設定されない。換言すれば、外向きデータの全体（Ｌｒバイト）は１つのＩブロック内で転送される。
（もし、アプレットが早く中止してＬｅバイトよりも少なく送信すると、残りのブロックの長とを満たすためにゼロが代りに送られる。）
注−無連鎖モードが使用される時、waitExtensionメソッドへのコールは理由コード、ILLEGAL_USE、と共に、APDUException、を投げる。
８．１．２．２ 通常の出力転送
アプレットにより出力転送の無連鎖モードが要求されない時、すなわち、setOutgoing方法が使用される時、以下のプロトコル順序が続く。

どんなＩＳＯ−７８１６−３／４準拠Ｔ＝１プロトコル転送順序が使用できる。
注−sendBytes又はsendBytesLongメソッドの連続したコール間でアプレットにより、waitExtensionメソッドを呼出すことができる。waitExtensionメソッドは、Ｔ＝０モード内の追加の１作業時間を要求することに等しい、ＩＮＦユニットのＷＴＸ要求を有するＳブロック命令を送る（ＩＳＯ７８１６−３参照）。
８．２ セキュリテイ及び暗号パッケージ
次のクラス内のgetInstanceメソッドは、要求されたアルゴリズムをコールするアプレットのコンテキスト中に実現インスタンスを戻す。
Javacard.security.MessageDigest
Javacard.security.Signature
Javacard.security.RandomData
Javacardx.crypto.Cipher
ＪＣＲＥの実現は、ＡＰＩにリストされたアルゴリズムの０又は複数を実現する。実現されていないアルゴリズムが要求される時、このメソッドは理由コード、NO_SUCH_ALGORITHM、を持った、CryptoException、を投げる。

上記クラスの実現は、対応する基本クラスを拡張し、全てのアブストラクト・メソッドを実現する。実現インスタンスと関連された全てのデータ割当ては、アプレットのインストレーション中に要求された資源の不足を早期にフラグを立てることができることを保証するためにインスタンス構成の時に実行される。

同様に、javacard.security.keyBuilderクラスのbuildkey方法は、要求されたキー・タイプの実現インスタンスを戻す。ＪＣＲＥは、０又は複数のキー・タイプを実現する。実現されていないキー・タイプが要求される時、このメソッドは理由コード、NO_SUCH_ALGORITHM、を持った、CryptoException、を投げる。

キー・タイプの実現は関連したインターフエイスを実現する。キー実現インスタンスに関連した全てのデータ割当ては、アプレットのインストレーション中に要求された資源の不足を早期にフラグを立てることができることを保証するためにインスタンス構成の時に実行される。
８．３ ＪＣＳｙｓｔｅｍ Ｃｌａｓｓ
ジャバ・カード２．１において、getVersionメソッドは、0x0201、（短い）を戻す。
９． 仮想マシン・トピックス この章のトピックスは仮想マシンの詳細を説明する。
９．１ 資源故障
回復可能な資源状態（例えば、ヒープ空間）の枯渇は、理由コード、NO_RESOURCE、を持った、SystemException、を生ずる。一時的配列を生成するために使用されるＪＣＳｙｓｔｅｍ内のフアクトリイ・メソッドは、一時的空間の不足を示すために、理由コード、NO_TRANSIENT_SPACE、を持った、SystemException、を投げる。

スタックのオーバーフローなどの全ての仮想マシン・エラー（回復不可能）は、仮想マシン・エラーを生ずる。これらの状態は仮想マシンを停止させる。このような回復不可能な仮想マシン・エラーが発生する時、実現は選択的にカードをミュートにするか将来の使用を阻止することを要求できる。
１０． アプレット・インストーラ
ジャバ・カード技術を使用したスマート・カード上のアプレット・インストレーションは、複雑なトピックである。ジャバ・カードＡＰＩ２．１は、それらの実現において可能な限りの多くの自由度を、ＪＣＲＥ実現者に与えることを意図している。しかし、いくつかの基本的な共通仕様が、ジャバ・カード・アプレットがインストールする特定のインストーラの実現の詳細を知ることなくインストールすることを可能にするために、要求される。

この仕様は、インストーラの概念を定義し、そして広い範囲にわたり可能なインストーラの実現の相互操作を達成するために、最小のインストレーション要件を詳細に示す。

アプレット・インストーラはＪＣＲＥ２．１仕様の選択的な部分である。すなわち、ＪＣＲＥの実現は、発行後にインストーラを含むことは必ずしも必要でない。しかし、もし実現されれば、インストーラは節９．１に詳細に説明された振舞いを支援することが要求される。
１０．１ インストーラ
ジャバ・カード技術を使用してスマート・カード上にアプレットをインストールするために必要な機構は、インストーラと呼ばれるカード上の部品に具体化されている。

ＣＡＤに対して、インストーラはアプレットに見える。それはＡＩＤを持ち、そしてこのＡＩＤがセレクト命令により成功的に処理された時に現在選択されたアプレットとなる。一旦、選択されると、インストーラは他のアプレットと同様に振舞う。
・その他の選択されたアプレットと同様に、それは全てのＡＰＤＵを受取る。
・その設計仕様は、さまざまな前処理下でこれらの命令のセマテイックスと共に受取るこてが期待されるＡＰＤＵのフォーマット及び様々な種類を規定する。
・それが受取る全てのＡＰＤＵを処理して応答する。不正確なＡＰＤＵはある種類のエラー状態を持って応答される。
・別のアプレットが選択された時（又はカードがリセットされた時又は電源がカードから取外された時）、インストーラは選択解除されて、それが選択される次の時まで中止される。
１０．１．１ インストーラ実現
インストーラは、カード上にアプレットとして実現する必要はない。要件は、インストーラの機能は選択可能であることだけである。この要件の結果として、インストーラ成分は、非インストーラ・アプレットが選択された時又はアプレットが選択されない時、呼出すことができない。

明らかに、ＪＣＲＥ実現者はインストーラをアプレットとして実現できることを選択できる。もしそうならば、インストーラはアプレット・クラスを拡張するためにコードされて、セレクト、プロセス、及びデセレクト・メソッドの呼出しに応答する。

しかし、ＪＣＲＥ実現者は、インストーラをそれが外界に対して選択可能な振舞いを与える限り、別の方法で実現できる。この場合、ＪＣＲＥ実現者はＡＰＤＵがインストーラ・コード・モジュールに配達される別の機構を与える自由度を有する。
１０．１．２ インストーラＡＩＤ
インストーラは選択可能であるから、それはＡＩＤを有する。ＪＣＲＥ実現者はそれらのインストーラが選択されるＡＩＤを自由に選択できる。複数のインストーラが実現できる。
１０．１．３ インストーラＡＰＤＵ
ジャバ・カードＡＰＩ２．１は、インストーラに対してＡＰＤＵを指定しない。ＪＣＲＥは実現者はそれらのインストーラに仕事を指示するためにＡＰＤＵ命令を完全に自由に選択できる。

モデルは、カード上のインストーラがＣＡＤ上で走るインストレーション・プログラムにより駆動される。インストレーションが成功するために、このＣＡＤインストレーション・プログラムは以下のことが可能でなければならない。
・カードを認識する。
・カード上のインストーラを選択する。
・適当なＡＰＤＵをカード・インストーラに送ることにより、インストレーション・プロセスを駆動する。これらのＡＰＤＵは、以下を含む。
＞インストレーションが認証されることを保証するための、認証情報。
＞カード・メモリ内にロードされるべきアプレット・コード＞カード上に既に存在するコードとアプレット・コードをリンクするためのリンケージ情報＞アプレットのインストール・メソッドに送られるべきインスタンス・イニシャライゼーション・パラメータ・データ
ジャバ・カードＡＰＩ２．１はＣＡＤインストーレイション・プログラムの詳細を指定せず、また、ＡＰＤＵはそれとインストーラの間に送られない。
１０．１．４ インストーラ振舞い
ＪＣＲＥ実現者は、以下を含むそれらのインストーラの他の振舞いを定義しなければならない。
・インストーレイションが中止できるかどうか、そしてこれがいかになされたか。
・インストーレイション中に、もし例外、リセット、又は電源喪失が発生したら、何が生ずるか。
・インストーラがその仕事を終える前に、もし別のアプレットが選択されたら何が生ずるか。

ＪＣＲＥは、以下の場合、アプレットが成功的にインストールされたと見なされないことを保証する。
・Applet.registerメソッドからの成功的な戻りの前に、アプレットのインストール・メソッドが例外を投げる（パラグラフ９．２参照）。
１０．１．５ インストーラ特権
インストーラはアプレットとして実現できるが、インストーラは典型的に「他のアプレット」に利用可能ではない特徴にアクセスする必要がある。例えば、ＪＣＲＥ実現者の実現に依存して、インストーラは次のことが必要である。
・オブジェクト・システム及び／又は標準セキュリテイをバイパスして、直接にメモリに読み書きする。
・他のアプレット又はＪＣＲＥにより所有されたオブジェクトへのアクセス。
・ＪＣＲＥの非入口点メソッドを呼出す。
・新たにインストールされたアプレットのインストール・メソッドを呼出すことができる。

再び、インスートラ実現を決定し、そしてインストーラを支援するのに必要なＪＣＲＥ実現内の特徴を供給することは、各ＪＣＲＥ実現者の責任である。ＪＣＲＥ実現者は、普通のアプレットに利用できないようにするため、そのような特徴のセキュリテイに責任を有する。
１０．２ 新にインストールされたアプレット
インストーラとインストールされているアプレットの間に単一のインターフエイスが存在する。インストーラが正しく実行（ローデイング及びリンキングなどの実行されたステップ）するためのアプレットを準備した後に、インストーラはアプレットのインストール・メソッドを呼出す。このメソッドはアプレット・クラスと定義される。

インストーラからアプレットのインストール・メソッドが呼出される正確な機構は、ＪＣＲＥ実現者定義の実現詳細である。しかし、インストール・メソッド（新しいオブジェクトを生成するなど）により実行されたコンテキストに関係した操作が新アプレットのコンテキスト内でなされ、そしてインストーラのコンテキスト内でないようにするため、コンテキスト切換えがある。インストーラはアプレット・クラス初期化（＜ｃｌｉｎｔ＞）メソッド中に生成された配列オブジェクトが、新アプレットのコンテキストにより所有されることも保証する。

もし全てのステップが失敗又は例外が投げられることなく、実行するApplet.registerメソッドからの成功的な戻りを含むまで、完了した場合、アプレットのインストレーションは完全とみなされる。その点において、インストールされたアプレットは選択可能である。

パラメータ・データの最大サイズは３２バイトである。セキュリテイの理由のため、ｂＡｒｒａｙパラメータは戻りの後にゼロにされる（ＡＰＤＵバッフアがアプレットのプロセス・メソッドからの戻りの際にゼロにされるのと同様）。
１０．２．１ インストーレイション・パラメータ
３２バイトの最大サイズ以外に、ジャバ・カードＡＰＩ２．１インストーレイション・パラメータ・バイト配列セグメントの内容について何ら指示しない。こりはアプレット設計者により完全に定義され、所望のどんなフオーマットでできる。これに加え、これらインストレーション・パラメータはインストーラーに不透明であることを意図している。

ＣＡＤ内で実行されるインストレーション・プログラムがインストーラに配達されるべき任意のバイト配列を指定することを可能にするように、ＪＣＲＥ実現者はそれらのインストーラを設計すべきである。インストーラは、単にこのバイト配列をｂＡｒｒａｙパラメータ内の目標のアプレットのインストール・メソッドヘ転送する。典型的な実現は、セマンテイック「付随するバイト配列の内容を送るアプレットのインストール・メソッドをコール」を有するＪＣＲＥ実現者専有ＡＰＤＵ命令を定義する。
１１． ＡＰＩ定数
いくつかのＡＰＩクラスは、ジャバ・カードＡＰＩ２．１レファレンス内にそれらの定数を指定された値を有しない。もし、一定の値がこのＪＣＲＥ２．１仕様の実現者により一貫して指定されない場合、業界全体の互換性は不可能である。この章はジャバ・カードＡＰＩ２．１レファレンス内で指定されない必要な一定の値を与える。

用語集
ＡＩＤは、ＩＳＯ７８１６−５に定義されたアプリケーション識別子の略。

ＡＰＤＵは、ＩＳＯ７８１６−４に定義されたアプリケーション・プロトコル・データ・ユニットの略。

ＡＰＩは、アプリケーション・プログラム・インターフエイスの略。ａｐｉはアプリケーション・プログラムがオペーレーテイング・システム又はその他のサービスをアクセスするときに呼ぶ約束事を定義する。

アプレットは、この書類の文脈内では、ジャバ・カード技術内の選択、コンテキスト、機能、及びセキュリテイの基本的単位である、ジャバ・カード・アプレットである。

アプレット開発者は、ジャバ・カード技術仕様を用いてジャバ・カード・アプレットを生成する人を言う。

アプレット・フアイヤウォールは、ＶＭが他のアプレット・コンテキスト又はＪＣＲＥコンテキストにより所有されたオブジェクトへのアプレットの認証されないアクセスから防止し、そして違反を報告し又は対処するジャバ・カード技術内の機構。

アトミック操作は、その全体が完了するか（もし操作が成功すると）、又は操作のどの部分も全く完了しない（もし操作が失敗したら）のいずれかである操作である。

アトミシテイは、特定の操作がアトミックであるか否か、そして電源が喪失、又はカードがＣＡＤから予期されずに取外された場合の適当なデータ回復が必要な操作を言う。

ＡＴＲは、リセットの返答の略。ＡＴＲは、リセット条件後にジャバ・カードにより送られる一連のバイトである。

ＣＡＤは、カード受入装置の略。ＣＡＤはカードが挿入される装置である。
キャストは、１つのデータ・タイプから別のタイプへの明示的な変換である。

ｃＪＣＫは、ジャバ・カード技術仕様の実現の許容性を確証するためのテストの一揃い。ｃＪＣＫはテストの一揃いを実行するためジャバ・テスト・ツールを使用する。

クラスは、オブジェクト指向言語のオブジェクトの原型（プロトタイプ）である。クラスは共通の構造と振舞いを共有する１組のオブジェクトとみなすことができる。クラスの構造は、そのクラスのオブジェクトの状態を表すクラス変数により定義され、その振舞いはクラスに関連する１組のメソッドにより与えられる。

クラスは、クラス階層に関係する。１つのクラスは他のクラス（そのスーパークラス）の特別化（サブクラス）であってよい。それは他のクラスへの参照を有し、そしてそれは他のクラスをクライアント−サーバー関係で使用してもよい。コンテキスト（アプレット実行コンテキスト参照）。

現在活動的なコンテキスト。ＪＣＲＥは現在活動的なジャバ・カード・アプレット・コンテキストの記録を残す。仮想メソッドがオブジェクト上で呼出され、そしてコンテキスト切換えが必要とされ、そして許可される時、現在活動的なコンテキストはそのオブジェクトを所有するアプレット・コンテキストに対応するために変化される。そのメソッドが戻る時、前のコンテキストが回復される。静的メソッドの呼出しは現在活動的なコンテキストについて影響を与えない。オブジェクトの現在活動的なコンテキスト及び共有状態は一緒に、オブジェクトへのアクセスが許可されるかどうかを決定する。

現在選択されたアプレット。ＪＣＲＥは現在選択されたジャバ・カード・アプレットの記録を残す。このアプレットのＡＩＤを有する選択命令を受取る際、ＪＣＲＥはこのアプレットを現在選択されたアプレットとする。ＪＣＲＥは全てのＡＰＤＵ命令を現在選択されたアプレットに送る。

ＥＥＰＲＯＭは、電気的消去可能プログラム可能読み出し専用メモリの略。
フアイヤウォール（アプレット・フアイヤウォール参照）。

フレームワークは、ＡＰＩを実現する１組のクラス。これはコア及び拡張パッケージを含む。責任は、ＡＰＤＵの発送、アプレット選択、アトミシテイ管理、及びアプレット・インストーリングを含む。

ガーベッジ・コレクションは、プログラムの実行時に自動的に再クレームされる動的に割当てられた記憶によるプロセスを言う。

インスタンス変数はまたフイールドとして知られていて、オブジェクトの内部状態の一部を表す。各オブジェクトはそれ自身のインスタンス変数の組を有する。同じクラスのオブジェクトは同じインスタンス変数を有するが、各オブジェクトは異なった値を持つことができる。

インスタンシエイションとは、オブジェクト指向プログラミングにおいて、そのクラス・テンプレートから特定のオブジェクトを生成することを意味する。これはテンプレートにより指定されたタイプを持つデータ構造の割当てと、デフォルト値又はクラス建設関数により与えられた値でインスタンス変数を初期化することを含む。

ＪＡＲは、ジャバ・アーキテクチャの略。ＪＡＲは多くのフアイルを１つに結合するプラットホームに依存しないフアイル・フオーマットである。
ジャバ・カード実行時環境（ＪＣＲＥ）は、ジャバ・カード仮想マシンねフレームワーク、及び関連のネイテイブ・メソッドからなる。

ＪＣ２１ＲＩは、ジャバ・カード２．１レファレンス実行の略。
ＪＣＲＥ実現者は、ジャバ・カードＡＰＩを使用してベンダー固有の実現を作成する人。

ＪＣＶＭは、ジャバ・カード仮想マシンの略。ＪＣＶＭは、ＯＰカード・アーキテクチャの基礎である。ＪＣＶＭは、バイトコードを実行し、そしてクラス及びオブジェクトを管理する。これはアプリケーション間の分離（フアイヤウォール）を実施し及び安全なデータ共有を可能にする。

ＪＤＫは、ジャバ開発キットの略。ＪＤＫはジャバでプログラムするために必要な環境を与えるサン・マイクロシステムズ社の製品。ＪＤＫはさまざまなプラットホームで利用可能であるが、最も有名なのは、サン・ソラリス及びマイクロソフト・ウインドウズ（商標）である。

メソッドは、オブジェクト指向言語において、１つ又は複数のクラスと関連した手順若しくはルーチンに与えられた名前である。

名前空間は、全ての名前が独特な１組の名前。
オブジェクト指向は、メソッドと呼ばれるデータを操作する１組のルーチンによりカプセル化されたデータ構造である、オブジェクトに基づいたプログラミング方式である。
オブジェクトは、オブジェクト指向プログラミングにおいて、そのクラスにより与えられたテンプレートに従い定義されたデータ構造の独特なインスタンスである。各オブジェクトは、そのクラスに属する変数についてそれ自身の値を有し、そのクラスにより定義されたメッセージ（メソッド）に応答できる。

パッケージは、ジャバ・プログラミング言語内の名前空間であり、クラス及びインターフエイスを有することができる。パッケージはジャバ・プログラミング言語内の最小ユニットである。

持続性オブジェクトは、持続性オブジェクトとそれらの値が、無限に、１つのＣＡＤセッションから次に持続するものであるるオブジェクトはデフォルトで持続性である。持続性オブジェクトの値はトランザクションによりアトミカリイに更新される。持続性の語はカード上にオブジェクト指向データベースが存在することを意味しない。又、オブジェクトが直列化／非直列化されることを意味しない。カードが電源を喪失する時にオブジェクトが失われないことを意味する。

共有可能インターフエイスは、共有されたインターフエイス・メソッドの１組を定義する。これらのインターフエイス・メソッドは、それらを実現するオブジェクトが別のアプレット・コンテキストにより所有されている時、１つのアプレット・コンテキストにより呼出すことができる。

共有可能インターフエイス・オフジェクト（ＳＩＯ）は、共有可能インターフエイスを実現するオブジェクトである。

トランザクションは、開発者がプログラム・コード内にトランザクションの開始及び終了を指示することにより操作の広がりを定義する、アトミック操作である。

一時的オブジェクト。一時的オブジェクトの値は、１つのＣＡＤセッションから次のセッションに持続せず、特定の間隔でデフォルト値にリセットされる。一時的オブジェクトの値の更新はアトミックではなく、トランザクションにより影響されない。

1/5/99 12:49PM Havnor: Stuff: JCRE D2 14DEC98: READ-ME-JCRE21-DF2.txt Page 1
日付：１９９８年１２月１６日
ジャバ・カード・ライセンシー殿
ＪＣＲＥ２１−ＤＦ２−１４ＤＥＣ９８．ｚｉｐは、ライセンシーの検討と意見のために、１９９８年１２月１４日の日付のジャバ・カード２．１実行時環境仕様の第２草案を含む。我々は今まで受取った検討フイードバックに基づいて書類を明確に組み込んで来た。

ｚｉｐのアーカイブの完全の内容は次の通りである。
ＲＥＡＤ−ＭＥ−ＪＣＲＥ２１−ＤＥ２．ｔｘｔ ‐このＲＥＡＤ ＭＥ文書フアイル。

ＪＣＲＥ２１−ＤＦ２．ｐｄｆ ‐「ジャバ・カード実行時環境（ＪＣＲＥ）２．１仕様」のＰＤＦフォーマット。

ＪＣＲＥ２１−ＤＦ２−ｃｈａｎｇｅｂａｒ．ｐｄｆ‐見やすくするために前のバージョンから変化バーを有する改訂バージョン。
変更の要約
１．これは第２草案のリリースであり、公開のウエブ・サイトに直ぐに公開される。

２．認証されないアクセスを制限するために、一時的ＪＣＲＥ入口点オブジェクトの新しい記述が導入された。フアイヤウォール章６．２．１
３．グローバル配列が一時的ＪＣＲＥ入口点オブジェクトと似たセキュリテイ関係の制限を追加する。フアイヤウォール章６．２．２
４．一時的ＪＣＲＥ入口点オブジェクト及びグローバル配列の記憶に関して、バイトコードの詳細な説明が追加された。章６．２．８
５．章８にＪＣＲＥ所有の例外オブジェクトの一般的説明が追加された。

６．一時的フアクトリイ・メソッド内の仮想マシン資源故障の修正された記述。章９．１
「ジャバ・カード２．１実行時環境仕様」は、ジャバ・カードＡＰＴ２．１及びジャバ・カード２．１仮想マシン仕様書類で言及されるような、ジャバ・カード２．１実現を完成するための最小の振舞いと実行時環境を詳述する。この仕様はジャバ・カード・アプレットの動作と互換性を保証する必要がある。この仕様書類の目的は、ジャバ・カード２．１仕様の一揃いの部分として、簡潔な方法で全てのＪＣＲＥ要素を一緒にすることである。

検討したコメントを<javaoem-javacard@sun.com>又は下の私のアドレスに送って下さい。ジャバ・カード・チームとして、ご意見を待っています。
よろしく。
ゴットフライ・デイジオルジ
Godfrey DiGiorgi - godfrey.digiorgi@eng.sun.com
OEM Licnesee Engineering
Sun Microsystems / Java Software
+1 408 343-1506 FAX +1 408 517-5460

Claims (1)

1. 小面積装置であって、
   ａ．少なくとも１つの処理要素と、
   ｂ．メモリと、
   ｃ．前記メモリ及び前記処理要素を使用して、プログラム・モジュールを互いに隔離するためのコンテキスト障壁と、
   ｄ．前記コンテキスト障壁の制約無しに全てのプログラム・モジュールへのアクセスを有する１つコンテキストと、
   を備えた小面積装置。