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

Abstract

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

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 0201310
023及び0201310031 ・ＩＳＯ７８１６仕様１−６部分 ・支払いシステム用ＥＭＶ‘９６集積回路カード仕様

【００７７】 １．導入 ジャバ・カード実行時環境（ＪＣＲＥ）２．１は、ジャバ・カード仮想マシン
（ＶＭ）、ジャバ・カード・アプリケーション・プログラミング・インターフエ
イス（ＡＰＩ）クラス（及び業界特有拡張）及びサポート・サービスを含む。

【００７８】 この書類、ＪＣＲＥ２．１仕様は、ジャバ・カード技術により要求されるＪＣ
ＲＥ機能を詳述する。ジャバ・カード技術のどんな実現もこの必要な行動と環境
を与える。

【００７９】 ２．ジャバ・カード仮想マシンの一生 ＰＣ又はワークステーションで、ジャバ仮想マシンはオペレーテイング・シス
テム・プロセスとして実行する。ＯＳプロセスが終了する時、ジャバ・アプリケ
ーションとそれらのオブジェクトは自動的に破壊される。 ジャバ・カード技術において、仮想マシン（ＶＭ）の実行の一生は、カードの
一生である。カードに記憶された情報の大部分は電源がカードから外されても保
存される。持続性メモリ技術（ＥＥＰＲＯＭなど）は、スマート・カードが電源
から外された時に情報の記憶を可能にする。カード上に生成されたＶＭ及びオブ
ジェクトは、持続性のアプリケーション情報を表すのに使用されるため、ジャバ
・カードＶＭは永久に動作するように見える。電源が外された時、ＶＭは単に一
時的に停止する。カードが次にリセットされる時、ＶＭは再び開始して、持続性
記憶から前のオブジェクト群を回復する。 持続性の特徴は別として、ジャバ・カード仮想マシンは、ジャバ仮想マシンと
同様である。 カード初期化時は、マスキング後の時間であり、カードの個性化と発行の時間
の前である。カード初期化時に、ＪＣＲＥが初期化される。ＪＣＲＥにより生成
されたフレームワーク・オブジェクトは仮想マシンの一生の間、存在する。仮想
マシン及びＪＣＲＥフレームワークの実行の一生は、カードのＣＡＤセッション
に及ぶため、アプレットにより生成されたオブジェクトの一生もまたＣＡＤセッ
ションに及ぶ。（ＣＡＤは、カード受入装置、又はカード読取り器。カード・セ
ッションはカードがＣＡＤ内に挿入されて、電源が投入され、そしてＣＡＤとＡ
ＰＤＵのストリームを交換する期間である。カード・セッションはカードがＣＡ
Ｄから取外される時に終了する。）この特性を有するオブジェクトを持続性オブ
ジェクトと呼ぶ。 ＪＣＲＥ実現者は、以下の時にオブジェクトを持続性にする。 ・Applet.registerメソッドがコールされる時。ＪＣＲＥはアプレット・オブジ
ェクトのインスタンスへの参照を記憶する。ＪＣＲＥ実現者は、クラス・アプレ
ットのインスタンスが持続性であることを保証しなければならない。 ・オブジェクトへの参照がクラスの静的フイールド又はその他の持続性オフジェ
クトのフイールドに記憶される時。この要件は、ＪＣＲＥ内部データ構造の完全
性を保存するための必要性から派生する。

【００８０】 ３．ジャバ・カード・アプレットの一生 この仕様の目的のため、ジャバ・カード・アプレットの一生は、それが正しく
カード・メモリにロードされて、リンクされ、又は、その他、実行のために準備
された時点で開始する。（この仕様の以降において、アプレットとはジャバ・カ
ード・プラットホームのために書かれたアプレットを言う。）Applet.register
メソッドに登録されたアプレットは、カードの一生の間、存在する。ＪＣＲＥは
アプレットのパブリック・メソッド、インストール、セレクト、デセレクト、及
びプロセスを介してアプレットと相互作用をする。アプレットは静的インストー
ル・メソッドを実現する。もしインストール・メソッドが実現されなければ、ア
プレットのオブジェクトは生成又は初期化できない。ＪＣＲＥ実現はアプレット
のインストール、セレクト、デセレクト、及びプロセス・メソッドを以下に説明
するようにコールする。 アプレットがスマート・カード上にインストールされる時、静的インストール
・メソッドがＪＣＲＥにより生成された各アプレット・インスタンスのために１
度、コールされる。ＪＣＲＥはアプレットのコンスラクターを直接コールしては
いけない。

【００８１】 ３．１メソッド・インストール インストールがコールされる時、アプレットのオブジェクトは存在しない。ア
プレット内のインストール・メソッドの主な仕事は、アプレット・クラスのイン
スタンスを生成し、インスタンスを登録することである。アプレットがその一生
の間に必要とする全ての他のオブジェクトはそれが可能な時に生成できる。その
他のアプレットがＣＡＤにより選択されてアクセスされるのに必要な準備は可能
な時に行なうことができる。インストール・メソッドは入力するバイト配列パラ
メータの内容から初期化パラメータを獲得する。 典型的に、アプレットは、さまざまなオブジェクトを生成し、それらを所定値
で初期化し、いくつかの内部状態変数を設定し、そしてそれを選択するのに使用
するためにＡＩＤ（ＩＳＯ７８１６−５に定義されるアプレット識別子）を指定
するためにApplet.registerメソッドをコールする。このインストールは、Apple
t.registerメソッドのコールが例外なしに完了した時に成功と見なされる。もし
インストール・メソッドがApplet.registerメソッドをコールしない場合、又は
、もしApplet.registerメソッドがコールされる前にインストール・メソッド内
から例外が投げられる場合、又は、もしApplet.registerメソッドが例外を投げ
る場合、にはインストールは不成功と見なされる。もしインストールが不成功な
らば、ＪＣＲＥはそれが制御を再獲得する時に全てのクリーン・アップを実行し
なければならない。すなわち、全ての持続性オブジェクトは、インストール・メ
ソッドがコールされる前に持っていた状態に戻される。もしインストールが成功
したならば、ＪＣＲＥはアプレットを選択可能と印を付けることができる。

【００８２】 ３．２メソッド・セレクト アプレットはそれらが明示的に選択されるまで、停止状態に留まる。ＪＣＲＥ
が名前データがアプレットのＡＩＤと一致するＳＥＬＥＣＴ ＡＰＤＵを受取る
時に、選択は発生する。選択はアプレットを現在選択されたアプレットとする。 ＳＥＬＥＣＴをコールする前、ＪＣＲＥは前に選択されたアプレットの選択を
解除しなければならない。ＪＣＲＥはこれをアプレットのデセレクト・メソッド
を呼出すことでアプレットに支持する。 ＪＣＲＥは、アプレットにそのセレクト・メソッドを呼出すことにより選択を
知らせる。 アプレットは、コールから誤りを返すことにより、又は例外を投げることによ
り、選択されることを拒否することができる。もしアプレットが真を返すと、現
実のＳＥＬＥＣＴ ＡＰＤＵ命令が以後のそのプロセス・メソッドへのコールで
アプレットに供給されて、アプレットがＡＰＤＵ内容を検査できる。それはＳＥ
ＬＥＣＴ ＡＰＤＵに対してデータ（詳細はプロセス・メソッドを参照）でもっ
て返答でき、又は、適当なＳＷ（状態ワードの返却）を有するＩＳＯＥｘｃｅｐ
ｔｉｏｎを投げることでエラーのフラグを立てることができる。ＳＷ及び選択的
な応答データはＣＡＤへ戻される。 Applet.selectingAppletメソッドは、セレクト・メソッド中にコールされる時
に真を返答する。Applet.selectingAppletメソッドは、ＳＥＬＥＣＴ ＡＰＤＵ
命令を処理するためにコールされる以降のプロセス・メソッド中に真を返答し続
ける。 もしアプレットが選択されることを拒否すると、ＪＣＲＥはＣＡＤにISO.SW_A
PPLET_SELECT_FAILEDのＡＰＤＵ応答状態ワードを戻す。選択の失敗の際、ＪＣ
ＲＥ状態はアプレットが選択されていないことを示すように設定される。 選択が成功した後、全ての以降のＡＰＤＵはプロセス・メソッドを経由して現
在選択されたアプレットへ配達される。

【００８３】 ３．３メソッド・プロセス 全てのＡＰＤＵは、ＪＣＲＥにより受取られ、ＡＰＤＵクラスのインスタンス
を現在選択されたアプレットのプロセス・メソッドに送る。 注−ＳＥＬＥＣＴ ＡＰＤＵは、プロセス・メソッドのコール前に、現在選択
されたアプレット内に変化を生ずるかもしれない。 正常な返答の際、ＪＣＲＥはアプレットにより既に送られたどんなデータにも
完了応答ＳＷとして、0x9000、を自動的に付ける。 プロセス中のどんな時にも、アプレットは適当なＳＷと共にISOExceptionを投
げることが可能であり、この場合、ＪＣＲＥはその例外を受取り、そしてＳＷを
ＣＡＤに戻す。 プロセス中に、もしその他の例外が投げられた場合、ＪＣＲＥはその例外を受
取り、状態ワード、ISO7816.Sw_UNKNOWN、をＣＡＤへ戻す。

【００８４】 ３．４メソッド・デセレクト ＪＣＲＥが、アプレットのＡＩＤと一致する名前のＳＥＬＥＣＴ ＡＰＤＵ命
令を受取る時、ＪＣＲＥは現在選択されているアプレットのデセレクト・メソッ
ドをコールする。これは他のアプレットの実行を可能にするために必要なクリー
ン・アップ操作をアプレットが実行することを可能にする。 Applet.selectingAppletメソッドは、デセレクト・メソッド中にコールされた
時、誤りを戻す。デセレクト・メソッドにより投げられた例外はＪＣＲＥにより
受取られる。しかし、アプレットは選択が解除される。

【００８５】 ３．５電源喪失及びリセット カードがＣＡＤから取出される時又はその他の機械的又は電気的故障が存在す
る場合、電源が喪失する。カードに電源が再び加えられる時及びカード・リセッ
ト（ウアーム又はコールド）時、ＪＣＲＥは以下を保証する。 ・一時データはデフォルト値にリセットされる。 ・電源が喪失した（又はリセットが発生した）時に進行中のトランザクションが
あれば、中止される。 ・電源が喪失した（又はリセットが発生した）時に選択されたアプレットは黙示
的に選択が解除される（この場合、デセレクト・メソッドはコールされない）。 ・もしＪＣＲＥがデフォルト・アプレット選択を実現する場合は（パラグラフ５
．１参照）、デフォルト・アプレットが現在選択されたアプレットとして選択さ
れ、そして、デフォルト・アプレットのセレクト・メソッドがコールされる。そ
れ以外は、ＪＣＲＥはその状態をアプレットが選択されていないことを示すもの
に設定する。

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

【００８７】 ４．１一時的オブジェクトをクリアする出来事 持続性オブジェクトはカード・リセットをわたって持続されるべき状態を維持
するために使用される。一時的オブジェクトが生成される時、そのフイールドを
クリアするための１つ又は２つの出来事が指定される。クリア・オン・リセット
一時的オブジェクトは、アプレット・セッションをわたって持続されるがカード
・リセットをわたって持続されない状態を維持するために使用される。クリア・
オン・デセレクト一時的オブジェクトは、アプレットが選択されている間は持続
されるが、アプレット選択又はカード・リセットをわたっては持続しない状態を
維持するために使用される。 ２つのクリア出来事の詳細は以下の通りである。 ・クリア・オン・リセット・オブジェクトのフイールドは、カードがリセットさ
れる時にクリアされる。カードに電源が投入される時、これはカード・リセット
を生ずる。 注−電源がカードから取除かれる前に一時的オブジェクトのフイールドをクリ
アする必要はない。しかし、このようなフイールドの内容は一旦電源が喪失する
と回復できないことを保証する必要がある。 ・クリア・オン・デセレクト・オブジェクトのフイールドは、アプレットの選択
が解除された時には常にクリアされる。カード・リセットは黙示的に現在選択さ
れたアプレットの選択を解除するため、クリア・オン・デセレクト・オブジェク
トのフイールドはまた、クリア・オン・リセットのために指定された同じ出来事
によりクリアされる。 現在選択されているアプレットは、選択命令が処理される時のみに明示的に選
択が解除される。現在選択されたアプレットは選択が解除され、そして全てのク
リア・オン・デセレクト一時的オブジェクトのフイールドは、選択命令が以下の
状態にかかわらず、クリアされる。 ・アプレットの選択に失敗。 ・異なるアプレットを選択。 ・同じアプレットを再選択。

【００８８】 ５．選択 カードは、ＡＰＤＵの形式でＣＡＤからサービスの要求を受取る。ＳＥＬＥＣ
Ｔ ＡＰＤＵはＪＣＲＥにより現在選択されているアプレットを指定するのに使
用される。一旦、選択されると、アプレットは選択が解除されるまで、全ての以
降のＡＰＤＵを受取る。

【００８９】 以下のいずれかが発生する時、現在選択されているアプレットは存在しない。 ・カードがリセットされ、そしてアプレットがデフォルト・アプレットとして前
もって指定されていない。 ・アプレットの選択を試みた時、選択命令が失敗する。

【００９０】 ５．１デフォルト・アプレット 普通、アプレットは成功した選択命令を介してのみ選択される。しかし、ある
スマート・カードＣＡＤアプリケーションは、各カード・リセット後に、黙示的
に選択されるデフォルト・アプレットの存在を必要とする。その振舞いは、 １．カード・リセット（又は、リセットの形式の電源投入）後、ＪＣＲＥはその
初期化を行ない、その内部状態が特定のアプレットがデフォルト・アプレットで
あると示しているかを検査する。もしそうならば、ＪＣＲＥはこのアプレットを
現在選択されたアプレットとし、そのアプレットのセレクト・メソッドがコール
される。もしアプレットのセレクト・メソッドが例外を投げ又は誤りを返すと、
ＪＣＲＥはその状態をアプレットが選択されないことを示す状態に設定する。（
デフォルト・アプレット選択中にはＳＥＬＥＣＴ ＡＰＤＵが無いため、アプレ
ットのプロセス・メソッドはコールされない。）デフォルト・アプレットがカー
ド・リセットにおいて選択される時、そのプロセス・メソッドがコールされる必
要はない。 ２．ＪＣＲＥはＡＴＲが送られることを保証し、そしてカードは現在ＡＰＤＵ命
令を受取るための用意ができている。 もしデフォルト・アプレットが成功的に選択されると、ＡＰＤＵ命令はこのア
プレットに直接的に送られることができる。もしデフォルト・アプレットが選択
されなければ、選択命令のみが処理できる。 デフォルト・アプレットを指定するための機構はジャバ・カードＡＰＩ２．１
には定義されていない。それはＪＣＲＥ実現の詳細であり、個々のＪＣＲＥ実現
者に任されている。

【００９１】 ５．２選択命令処理 ＳＥＬＥＣＴ ＡＰＤＵ命令はアプレットを選択するのに使用される。その振
舞いは、 １．アプレットがもしあれば活動的かどうかにかかわらず、ＪＣＲＥによりＳＥ
ＬＥＣＴ ＡＰＤＵは常に処理される。 ２．ＪＣＲＥは一致したＡＩＤについて内部テーブルを探す。ＪＣＲＥは選択命
令中に完全なＡＩＤがある場合、アプレットの選択を支援する。 ＪＣＲＥ実現者は、他の選択基準を支援するために彼等のＪＣＲＥを増強する
ことは自由である。この一例は、ＩＳＯ７８１６−１４に説明されるように部分
的なＡＩＤ一致を介しての選択である。特別な要件は以下の通りである。 注−星印はＩＳＯ７８１６内の２進値ビット番号を示す。最上位ビット＝ｂ８、
最下位ビット＝ｂ１である。 ａ）アプレット選択命令は、CLA=0x00,INS=0xA4、を使用する。 ｂ）アプレット選択命令は、「ＤＦ名による選択」を使用する。従って、P1=0
x04である。 ｃ）P1の他の値はアプレット選択を示唆しない。ＡＰＤＵは現在選択されたア
プレットにより処理される。 ｄ）ＪＣＲＥは、正確なＤＦ名（ＡＩＤ）選択、すなわち、P2=%b0000xx00(b4
,b3*は無視)、を支援する。 ｅ）全ての他の部分ＤＦ名選択オプション(b2,b1*)は、ＪＣＲＥ実現に依存す
る。 ｆ）全てのフアイル制御情報オプション・コード(b4,b3*)は、ＪＣＲＥにより
支援され、そしてアプレットにより解釈されそして処理される。 ３．もしＡＩＤ一致が見つからなければ、 ａ．もし現在選択されたアプレットが存在しなければ、ＪＣＲＥは選択命令に
状態コード0x6999(SW_APPLET_SELECT_FAILED)でもって返答する。 ｂ．それ以外は、選択命令は、現在選択されたアプレットのプロセス・メソッ
ドに送られる。この点で、アプレットのコンテキストへのコンテキスト切換えが
発生する。（アプレット・コンテキストはパラグラフ６．１．１．で定義される
。）アプレットは、それら自身の内部選択処理のためにＳＥＬＥＣＴ ＡＰＤＵ
命令を使用できる。 ４．もし一致したＡＩＤが見つかれば、ＪＣＲＥは新しいアプレットを選択する
準備をする。もし現在選択されたアプレットが存在すれば、そのデセレクト・メ
ソッドへのコールを介して選択解除される。この時点で選択解除されたアプレッ
トのコンテキストへのコンテキスト切換えが生ずる。ＪＣＲＥコンテキストはデ
セレクトからの出口において回復される。 ５．ＪＣＲＥは、新たに現在選択されたアプレットを設定する。新しいアプレッ
トは、そのセレクト・メソッドへのコールを介して選択される。そして新しいア
プレットのコンテキストへのコンテキスト切換えが発生する。 ａ．もしアプレットのセレクト・メソッドが例外を投げる又は誤りを戻すと、
ＪＣＲＥ状態はアプレットが選択されないように設定される。ＪＣＲＥは選択命
令に対して状態コード0x6999(SW_APPLET_SELECT_FAILED)でもって返答する。 ｂ．新たに現在の選択されたアプレットのプロセス・メソッドは、入力パラメ
ータとしてＳＥＬＥＣＴ ＡＰＤＵと共にコールされる。アプレットのコンテキ
ストへのコンテキスト切換えが発生する。 注−もし一致するＡＩＤが存在しなければ、選択命令は通常のアプレットＡＰＤ
Ｕ命令として処理するために現在選択されたアプレット（もし有れば）に送られ
る。 もし、一致するＡＩＤが存在し、そして選択命令が失敗すると、ＪＣＲＥは常
にアプレットが選択されない状態にはいる。 もし、一致するＡＩＤが現在選択されたアプレットと同じならば、ＪＣＲＥは
アプレットの選択を解除するプロセスを経過して、そしてそれを選択する。再選
択は失敗することがあり、カードをアプレットが選択されない状態にする。

【００９２】 ５．３非選択命令処理 非選択ＡＰＤＵが受取られ、そして現在選択されたアプレットが存在しない時
、ＪＣＲＥはＡＰＤＵに状態コード0x6999(SW_APPLET_SELECT_FAILED)でもって
返答する。 非選択ＡＰＤＵが受取られ、そして現在選択されたアプレットが存在する時、
ＪＣＲＥは現在選択されたアプレットのプロセス・メソッドを呼出して、ＡＰＤ
Ｕをパラメータとして送る。これは、ＪＣＲＥコンテキストから現在選択された
アプレットのコンテキストへのコンテキスト切換えを生ずる。プロセス・メソッ
ドが存在する時、ＶＭはＪＣＲＥコンテキストへ戻される。ＪＣＲＥは返答をＡ
ＰＤＵへ送る。そして次の命令ＡＰＤＵを待つ。

【００９３】 ６．アプレット隔離及びオブジェクト共有 ＪＣＲＥのどんな実現もコンテキスト及びアプレットの隔離を支援する。隔離
とは、他のアプレットが明示的にアクセスのためのインターフエイスを与えなけ
れば、アプレットは別のコンテキスト内のアプレットのオブジェクト又はフイー
ルドにアクセスすることができないことを意味する。

【００９４】 ６．１アプレット・フアイヤウォール ジャバ・カード技術内のアプレット・フアイヤウォールは実行時実施保護であ
り、ジャバ技術保護とは別である。ジャバ言語保護はジャバ・カード・アプレッ
トへ適用される。ジャバ言語は強いタイピングと保護属性を実施することを保証
する。 アプレット・フアイヤウォールは常にジャバ・カードＶＭ内で実施される。こ
れらは、ＶＭを実行時に自動的に追加のセキュリテイ検査を実行することを可能
にする。

【００９５】 ６．１．１コンテキスト及びコンテキスト切換え フアイヤウォールは本質的にジャバ・カード・プラットホームのオブジェクト
・システムを、コンテキストと呼ばれる分離した保護されたオブジェクト空間に
区分する。フアイヤウォールは、１つのコンテキストと別の間の境界である。Ｊ
ＣＲＥはカード上にインストールされている各アプレットに対するアプレット・
コンテキストを割当てそして管理する（しかし、グループ・コンテキストの議論
について下のパラグラフ６．１．１．２を参照）。 これに加え、ＪＣＲＥはそれ自身のＪＣＲＥコンテキストを維持する。このコ
ンテキストはアプレット・コンテキストと大変似ている。しかし、それはアプレ
ット・コンテキストには否定された操作を実行することができるように特別なシ
ステム特権を有する。 どの時点においても、ＶＭ内には１つのみの活動的なコンテキスト存在する。
（これが現在活動的なコンテキストと呼ばれる。）オブジェクトにアクセスする
全てのバイトコードは、アクセスが許可されるかどうかを決定するために、現在
活動的なコンテキストに対して実行時に検査される。アクセスが不許可の時、ja
va.lang.SecurityExceptionが投げられる。 パラグラフ６．２．８に記述するように、呼出しタイプ・バイトコードの実行
中に、ある良く定義された条件が満足される時、ＶＭはコンテキスト切換えを実
行する。前のコンテキストは、内部ＶＭスタックに押し込められて、新しいコン
テキストが現在活動的なコンテキストとなり、呼出されたメソッドがこの新しい
コンテキスト内で実行する。メソッドから出る時、ＶＭはコンテキスト切換えの
回復を実行する。元のコンテキスト（メソッドをコールした）はスタックから取
出されて、現在活動的なコンテキストとして回復される。コンテキスト切換えは
ネストできる。最大の深さは、利用可能なＶＭスタック空間の量に依存する。 ジャバ・カード技術内での大部分のメソッドの呼出しは、コンテキスト切換え
を生じない。コンテキスト切換えは、あるメソッドからの戻りと呼出し中及びそ
れらのメソッドからの例外出口中のみに生ずる（６．２．８参照）。 コンテキスト切換えメソッド呼出し中、現在活動的なコンテキストを示すデー
タの追加の部分が戻りスタック内に押し込まれる。メソッドが出る時にこのコン
テキストが回復される。 この章の以下の部分においてコンテキスト及びコンテキスト切換えのさらなる
詳細が与えられる。

【００９６】 ６．１．１．１ グループ・コンテキスト 普通、ジャバ・カード・アプレットの各インスタンスは別のコンテキストを定
義する。しかし、ジャバ・カード２．１技術では、グループ・コンテキストの概
念が導入される。もし２以上のアプレットが、１つのジャバ・パッケージ内に含
まれる時、それらは同じコンテキストを共有する。これに加え、同じアプレット
・クラスの全てのインスタンスは同じコンテキストを共有する。換言すれば、グ
ループ・コンテキスト内の２つのアプレット・インスタンス間にフアイヤウォー
ルは存在しない。 節６．１．１内の上記コンテキスト及びコンテキスト切換えの説明は、各アプ
レット・インスタンスが別のコンテキストと関連していると仮定している。ジャ
バ・カード２．１技術では、フアイヤウォールを実施するためにコンテキストが
比較される。そしてインスタンスＡＩＤがスタック内に押し込まれる。これに加
えて、これはコンテキスト切換えの時だけではなく、１つのアプレット・インス
タンスにより所有されたオブジェクトから同じパッケージ内の別のインスタンス
により所有されたオブジェクトへの制御切換えの時にも生ずる。

【００９７】 ６．１．２オブジェクト所有 新しいオブジェクトが生成される時、それは現在活動的なコンテキストと関連
付けられる。しかし、オブジェクトは、オブジェクトが具体化される時に現在活
動的なコンテキスト内のアプレット・インスタンスにより所有される。オブジェ
クトはアプレット・インスタンス又はＪＣＲＥにより所有される。

【００９８】 ６．１．３オブジェクト・アクセス 一般に、オブジェクトはその所有するコンテキストによりのみアクセスできる
。すなわち、所有コンテキストが現在活動的なコンテキストである時。フアイヤ
ウォールが異なるコンテキスト内の別のアプレットによりオブジェクトがアクセ
スされることを防ぐ。 実現の観点では、オブジェクトがアクセスされる時は何時でも、オブジェクト
の所有コンテキストが現在活動的なコンテキストと比較される。もしこれらが一
致しなければ、アクセスは実行されず、SecurityExceptionが投げられる。 オブジェクトの参照を使用して、以下のバイトコードの１つが実行される時、
オブジェクトがアクセスされる。 Getfield, putfield, invokevirtual, invokeinterface, athrow, <T>aload, <T>astore, arraylength, checkcast, instanceof, <T> は、baload、sastore等、さまざまなタイプのバイトコード配列を言う。 このリストは、getfield_b, sgetfield_s_this,等、ジャバ・カードＶＭ内で
実現されるこれらのバイトコードの特別な又は最適化された形を含む。

【００９９】 ６．１．４フアイヤウォール保護 ジャバ・カード・フアイヤウォールは、最もしばしば予期されるセキュリテイ
問題、大切なデータを別のアプレットに「漏らす」ような開発者の誤り及び設計
の見過ごし、に対して保護を与える。アプレットは公にアクセス可能な場所から
オブジェクトの参照を得ることができるかもしれないが、しかし、オブジェクト
が異なるアプレットに所有されていると、フアイヤウォールはセキュリテイを保
証する。 フアイヤウォールはまた、間違ったコードに対して保護を与える。もしカード
に誤ったコードがロードされると、フアイヤウォールはこのコードからオブジェ
クトがアクセスされることを保護する。 ジャバ・カードＡＰＩ２．１は、これらの特徴がアプレット開発者には透明で
はない方法で支援されるため、フアイヤウォール及びコンテキストの基本的な最
小保護要件を説明する。開発者は、ＡＰＩ、フアイヤウォールに関する例外、及
び、オブジェクトの振舞いについて知らなければならない。 ＪＣＲＥ実現は、これらの機構がアプレットに透明で且つＶＭの外部に見える
操作を変更しない限り、これらのアプレット・フアイヤウォールを越えて、追加
のセキュリテイ機構を実現することは自由である。

【０１００】 ６．１．５静的フイールド及びメソッド クラスはコンテキストにより所有されないことに注意すべきである。クラス静
的フイールドがアクセスされる時、実行される実行時コンテキスト検査はない。
静的メソッドが呼出される時、コンテキスト切換えはない。（同様に、invokesp
ecialはコンテキスト切換えを生じない） パブリック静的フイールド及びパブリック静的メソッドは、どんなコンテキス
トからもアクセス可能である。静的メソッドはそれらを呼出したのと同じコンテ
キスト内で実行される。 静的フイールド内で参照されるオブジェクトは普通のオブジェクトである。こ
れらはこれらを生成したものより所有され、標準のフアイヤウォール・アクセス
規則が適用される。もしそれらが複数のアプレット・コンテキストに横断して共
有される必要があるならば、これらは共有可能インターフエイス・オブジェクト
（ＳＩＯ）である必要がある。（以下のパラグラフ６．２．４参照） もちろん、通常のジャバ技術保護が静的フイールド及びメソッドに対して実施
できる。これに加え、アプレットがインストールされる時、インストーラは外部
の静的フイールド又はメソッドへのリンクの各試みが許可されることを確証する
。インストレーションとリンケージについての仕様はこの仕様の範囲外である。

【０１０１】 ６．１．５．１選択的静的アクセス検査 ＪＣＲＥは、確証者により実施される制約と冗長なオプショナルな実行時検査
を実行できる。ジャバ・カードＶＭは、コードが別のクラスのプライベートなメ
ソッドの呼出しなど、基本的な言語制限に違反する時、検出して、報告し、又は
違反に対処する。

【０１０２】 ６．２コンテキストを横断するオブジェクトへのアクセス アプレットが互いに相互作用し、又は、ＪＣＲＥと相互作用することを可能に
するため、１つのコンテキストが別のコンテキストに属するオブジェクトにアク
セスすることができる、良く定義され且つ安全な機構が提供される。 これらの機構は、ジャバ・カードＡＰＩ２．１において与えられ、そして以下
の節で説明される。 ・ＪＣＲＥ入口点オブジェクト ・グローバル配列 ・ＪＣＲＥ特権 ・共有可能インターフエイス

【０１０３】 ６．２．１ＪＣＲＥ入口点オブジェクト 安全なコンピュータ・システムは、非特権ユーザ・プロセス（資源の一部に限
定された）が、特権的な「システム」ルーチンにより実行されるシステム・サー
ビスを要求するための方法を持たなければならない。 ジャバ・カードＡＰＩ２．１では、これはＪＣＲＥ入口点オブジェクトを使用
して達成される。これらはＪＣＲＥコンテキストにより所有されるオフジェクト
であるが、しかしそれらは入口点メソッドを含むとしてフラグが立てられている
。 フアイヤウォールは、これらのオブジェクトをアプレットによるアクセスから
保護する。入口点指定はこれらのオブジェクトのメソッドがどんなコンテキスト
からも呼出されることを可能にする。それが発生する時、ＪＣＲＥコンテキスト
へのコンテキスト切換えが実行される。これらのメソッドは、アプレットが特権
ＪＣＲＥシステム・サービスを要求するゲートである。 ＪＣＲＥ入口点オブジェクトには２つの分類がある。 ・一時的ＪＣＲＥ入口点オブジェクト 全てのＪＣＲＥ入口点オブジェクトと同様に、一時的ＪＣＲＥ入口点オブジェ
クトのメソッドは、どんなアプレットのコンテキストから呼出されることができ
る。しかし、これらのオブジェクトへの参照は、クラス変数、インスタンス変数
、又は配列要素内には記憶することができない。ＪＣＲＥは、これらのオブジェ
クトへの参照の記憶の試みを、認証されない再使用を防ぐために、フアイヤウォ
ール機能の一部として検出して制限する。 ＡＰＤＵオブジェクト及び全てのＪＣＲＥ所有例外オブジェクトは、一時的Ｊ
ＣＲＥ入口点オブジェクトの例である。 ・永久ＪＣＲＥ入口点オブジェクト 全てのＪＣＲＥ入口点オブジェクトと同様に、永久ＪＣＲＥ入口点オブジェク
トのメソッドは、どんなアプレットのコンテキストから呼出されることができる
。これに加えて、これらのオブジェクトへの参照は記憶でき、自由に再使用でき
る。 ＪＣＲＥ所有ＡＩＤインスタンスは、永久ＪＣＲＥ入口点ポイントの例である
。 ＪＣＲＥは、以下の責任を有する。 ・どんな特権的サービスがアプレットに提供できるかを決定する。 ・それらのサービスへの入口点メソッドを含むクラスを定義する。 ・それらのクラスの１又は複数のオブジェクト・インスタンスを生成する。 ・それらのインスタンスをＪＣＲＥ入口点オブジェクトと指定する。 ・ＪＣＲＥ入口点オブジェクトを一時的又は永久と指定する。 ・必要に応じてこれらのオブジェクトへの参照をアプレットに利用可能にする。
注−これらのオブジェクトのメソッドのみがフアイヤウォールを通じてアクセス
可能にする。これらのオブジェクトのフイールドはフアイヤウォールにより保護
されていて、ＪＣＲＥコンテキストのみによりアクセス可能である。 ＪＣＲＥ自身のみが入口点オブジェクト及びそれらが一時的又は永久かを指定
できる。ＪＣＲＥ実現者は、ＪＣＲＥ入口点オブジェクトが指定されそしてそれ
らがどのように一時的又は永久的になるかの機構の実現に責任を有する。

【０１０４】 ６．２．２グローバル配列 いくつかのオブジェクトのグローバル性質はそれらがどんなアプレット・コン
テキストからもアクセス可能であることを要求する。フアイヤウォールは通常、
これらオブジェクトが柔軟な態様で使用されることを防ぐ。ジャバ・カードＶＭ
はオブジェクトがグローバルとして指定されることを可能にする。 全てのグローバル配列は一時的グローバル配列オブジェクトである。これらオ
ブジェクトはＪＣＲＥコンテキストにより所有されるが、どんなアプレット・コ
ンテキストからもアクセスできる。しかし、これらのオブジェクトへの参照はク
ラス変数、インスタンス変数又は配列要素内には記憶できない。ＪＣＲＥはこれ
らのオブジェクトへの参照の記憶の試みを、認証されない再使用を防ぐためにフ
アイヤウォール機能の一部として検出して制限する。 追加のセキュリテイのため、配列のみがグローバルと指定でき、そしてＪＣＲ
Ｅ自身のみがグローバル配列を指定できる。アプレットがそれらを生成できない
ため、ＡＰＩメソッドは定義されない。ＪＣＲＥ実現者はグローバル配列が指定
される機構を実現する責任がある。 この仕様の刊行時に、ジャバ・カードＡＰＩ２．１に要求されるグローバル配
列は、ＡＰＤＵバッフア及びアプレットのインストール・メソッドへのバイト配
列入力パラメータ（ｂ配列）のみである。 注−そのグローバル地位のため、アプレットが選択される時は常に、ＪＣＲＥが
新しいＡＰＤＵ命令を受取る前に、ＡＰＤＵバッフアがゼロにクリアされること
をＡＰＩは指定する。これは、アプレットの潜在的な重要なデータがグローバル
ＡＰＤＵバッフアを経由して他のアプレットへ「漏れる」ことを防止する。ＡＰ
ＤＵバッフアは、共有インターフエイス・オブジェクト・コンテキストからアク
セスでき、アプレット・今テキストを横断してデータを送るのに適している。ア
プレットは、ＡＰＤＵバッフアからアクセスされる秘密データを保護する責任が
ある。

【０１０５】 ６．２．３ＪＣＲＥ特権 「システム」コンテキストであるため、ＪＣＲＥコンテキストは特別な特権を
有する。それはカード上のどんなオブジェクトのメソッドも呼出すことができる
。例えば、オブジェクトＸがアプレットＡにより所有されていると仮定すると、
普通、コンテキストＡのみがフイールド及びＸのメソッドをアクセスできる。し
かし、ＪＣＲＥコンテキストはＸのどんなメソッドも呼出すことができる。この
ような呼出し中、コンテキスト切換えが、ＪＣＲＥコンテキストからＸを所有す
るアプレット・コンテキストへ生ずる。 注−ＪＣＲＥは、Ｘのメソッド及びフイールドの両方をアクセスできる。メソッ
ドのアクセスはＪＣＲＥがアプレット・コンテキストに入るための機構である。
ＪＣＲＥはフアイヤウォールを介してどんなメソッドも呼出すことができるが、
アプレット・クラスで定義された、select,process,deselect,getShareableInte
rfaceObjectメソッド（６．２．７．１参照）のみを呼出すべきである。 ＪＣＲＥコンテキストは、ＶＭがカード・リセット後に実行を開始する時の現
在活動的なコンテキストである。ＪＣＲＥコンテキストは「ルート」コンテキス
トであり、常に現在活動的なコンテキスト又はスタックに記憶された底コンテキ
ストのいずれかである。

【０１０６】 ６．２．４共有可能インターフエイス 共有可能インターフエイスは、アプレット相互作用を可能にするためのジャバ
・カードＡＰＩ２．１の新しい特徴である。共有可能インターフエイスは、１組
の共有されたインターフエイス・メソッドを定義する。これらのインターフエイ
ス・メソッドは、もしそれらを実現するオブジェクトが別のアプレット・コンテ
キストにより所有されていても、１つのアプレット・コンテキストから呼出すこ
とができる。 この仕様では、共有可能インターフエイスを実現するクラスのオブジェクト・
インターフエイスは、共有可能インターフエイス・オブジェクト（ＳＩＯ）と呼
ばれる。 所有コンテキストには、ＳＩＯはそのフイールド及びメソッドがアクセスでき
る普通のオブジェクトである。その他のコンテキストには、ＳＩＯは共有可能な
インターフエイスのインスタンスであり、共有可能インターフエイス内で定義さ
れたメソッドのみがアクセス可能である。ＳＩＯのその他の全てのフイールド及
びメソッドはフアイヤウォールにより保護される。 共有可能インターフエイスは、アプレット間通信のための安全な機構を以下の
様に与える。 １．オブジェクトを別のアプレットに利用可能にするため、アプレットＡは最初
に共有可能インターフエイスＳＩを定義する。共有可能インターフエイスはイン
ターフエイス、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.beginTransactio
nメソッドへのコールと共に更新のアトミックな組の始まりを指定することがで
きるトランザクション・モデルを支援する。この点の後の各オブジェクト更新は
、条件付きで更新される。フイールド又は配列成分は更新されたかのように見え
る。フイールド／配列成分を読み返すとその最新の条件付き値が生ずる。しかし
、更新はまだコミットされていない。 アプレットが、JCSystem.commitTransactionをコールする時、全て条件付きの
更新が持続性記憶にコミットされる。JCSystem.commitTransactionの完了前に電
源喪失又はその他のシステム故障が発生すると、全ての条件付更新フイールド又
は配列成分はそれらの前の値に回復される。もしアプレットが、内部的問題に出
会う又はトランザクションを取消すと決定した場合、それは、JCSystem.abortTr
ansactionをコールすることにより条件付き更新をプログラム的に元に戻すこと
ができる。

【０１２８】 ７．３トランザクション期間 トランザクションは、ＪＣＲＥがアプレットのセレクト、デセレクト、プロセ
ス、又はインストール・メソッドからの戻りの際にプログラム的制御を再獲得す
る時に、常に終了する。これは、トランザクションがアプレットのcommitTransa
ctionへのコールでもって、又は、トランザクションの中止（アプレットにより
プログラム的に又はＪＣＲＥによるデフォルトによるかのいずれか）でもって正
常に終了するかにかかわらず、真である。トランザクション中止のさらなる詳細
はパラグラフ７．６を参照。 トランザクション期間は、JCSystem.beginTransactionへのコールとcommitTra
nsactionへのコール若しくはトランザクションの中止の間のトランザクションの
一生である。

【０１２９】 ７．４ネストされたトランザクション 現在のモデルは、ネストされたトランザクションは可能でないと仮定する。一
時には１つのトランザクションだけが存在できる。もしトランザクションが既に
進行中に、JCSystem.beginTransactiontがコールされると、TransactionExcepti
onが投げられる。 トランザクションが進行中がどうかを決定することができるように、JCSystem
.transactionDepthメソッドが提供される。

【０１３０】 ７．５トランザクション故障のリセット又はテイア トランザクションが進行中に、電源が喪失（テイア）し、又は、カードがリセ
ットされ、又は、その他のシステム故障が発生した場合、ＪＣＲＥは前のJCSyst
em.beginTransactionをコール以降の全てのフイールド及び配列の成分の条件付
き更新をそれらの前の値に回復する。 この動作は、ＪＣＲＥにより自動的にカードを電源喪失、リセット、又は故障
から回復した後に再初期化する時に、実行される。ＪＣＲＥはそれらのオブジェ
クトのどれが（もしあれば）条件付きで更新されたかを決定し、それらを回復す
る。 注−電源喪失又はカード・リセットにより失敗したトランザクション中に生成さ
れたインスタンスにより使用されたオブジェクト空間は、ＪＣＲＥにより回復で
きる。

【０１３１】 ７．６トランザクションの中止 トランザクションはアプレット又はＪＣＲＥのいずれかにより中止できる。

【０１３２】 ７．６．１プログラム的中止 もしアプレットが内部的問題に出会い又はトランザクションを取消す決定をし
た場合、それはJCSystem.abortTransactionをコールすることにより、条件付き
更新をプログラム的に元に戻すことができる。もしこのメソッドがコールされる
と、前のJCSystem.beginTransactionのコール以来の全ての条件付き更新された
フイールド又は配列成分はそれらの前の値に回復され、そして、JCSystem.trans
actionDepth値は０にリセットされる。

【０１３３】 ７．６．２ＪＣＲＥによる中止 もしアプレットが進行中のトランザクションの際にセレクト、デセレクト、プ
ロセス又はインストール・メソッドから戻ると、ＪＣＲＥは自動的にトランザク
ションを中止する。もしトランザクションの進行中にセレクト、デセレクト、プ
ロセス、又はインストール・メソッドからの戻りが発生すると、ＪＣＲＥはあた
かも例外が投げなれたように動作する。

【０１３４】 ７．６．３ＪＣＲＥのクリーンアップ責任 中止されたトランザクションの際に生成されたオブジェクト・インスタンスは
、もしこれらのオブジェクトについての全ての参照が探すことができて無効に変
換できれば、削除できる。ＪＣＲＥは中止されたトランザクション中に生成され
たオブジェクトについての参照は無効の参照に等しいことを保証する。

【０１３５】 ７．７一時的オブジェクト 持続性オブジェクトの更新のみがトランザクションに参加する。一時的オブジ
ェクトの更新は、それらが「内部トランザクション」がどうかにかかわらず決し
て、元に回復されない。

【０１３６】 ７．８コミット容量 プラットホーム資源が制限されるため、トランザクション中に蓄積できる条件
付き更新データのバイト数は制限される。ジャバ・カード技術は、実現の際にど
れだけのコミット容量が利用可能かを決定するメソッドを与える。コミット能力
は、利用可能な条件付きバイト更新の数の上限を表す。マネージメント・オーバ
ーヘッドのために利用できる条件付きバイト更新の実際の数はそれよりも少ない
。 トランザクション中に、もしコミット容量を越えると、例外が投げられる。

【０１３７】 ８．ＡＰＩトピックス この章のトピックスは、ジャバ・カード２．１ＡＰＩ草案２仕様に詳述された
要件を補足する。第１トピックはＡＰＤＵクラス内に完全に実現されるジャバ・
カードＩ／Ｏ機能である。第２トピックはＡＰＩ支援ジャバ・カード・セキュリ
テイと暗号である。JCSystem classはＡＰＩバージョン・レベルをカプセル化す
る。 ＡＰＩ内部のトランザクション ジャバ・カード２．１ＡＰＩ仕様で特別に表示されなければ、ＡＰＩクラスの
実現はトランザクションを開始したり、又は進行中であれば、トランザクション
の状態を変更したりしない。 ＡＰＩ内部の資源の使用 ジャバ・カード２．１ＡＰＩ仕様で特別に表示されなければ、実現はオブジェ
クト・インスタンスの所有者が現在選択されたアプレットでない時でさえ、ＡＰ
Ｉインスタンス・メソッドの呼出しを支援する。換言すれば、特に表示されなけ
れば、実現はクリア・オン・デセレクト・タイプの一時的オブジェクトなどの資
源を使用しない。 ＡＰＩクラスにより投げられた例外 ＡＰＩ実現により投げられた全ての例外オブジェクトは、一時的ＪＣＲＥ入口
点オブジェクトである。一時的ＪＣＲＥ入口点オブジェクトは、クラス変数、イ
ンスタンス変数、又は配列成分内に記憶することができない（参照６．２．１）
。

【０１３８】 ８．１ＡＰＤＵクラス ＡＰＤＵクラスは、ＩＳＯ７８１６−４に基づいたカード・シリアル線を横断
するＩ／Ｏへのアクセスをカプセル化する。ＡＰＤＵクラスは、下にあるＩ／Ｏ
トランスポート・プロトコルに独立に設計されている。 ＪＣＲＥは、Ｔ＝０又はＴ＝１トランスポート・プロトコル又は両方を支援す
る。

【０１３９】 ８．１．１外向きデータ転送ためＴ＝０詳細 ブロック連鎖機構を支援しない旧式のＣＡＤ／ターミナルとの互換性のため、
ＡＰＤＵクラスは、setOutgoingNoChainingメソッドを介してモード選択を可能
にする。

【０１４０】 ８．１．１．１連鎖無しの制約された転送 setOutgoingNoChainingメソッドをコールすることによりアプレットにより要
求された出力転送の無連鎖モードの時、以下のプロトコル順序が続く。 注−無連鎖モードが使用される時、waitExtensionメソッドへのコールは理由コ
ード、ILLEGAL_USE、と共に、APDUException、を投げる。 表記 Ｌｅ＝ＣＡＤが期待する長さ。 Ｌｒ＝setOutgoingLengthメソッドを介して設定されたアプレット返答長さ。 ＜ＩＮＳ＞＝次に転送される全データ・バイトを示す、入力ヘッダーＩＮＳバイ
トに等しいプロトコル・バイト。 ＜〜ＩＮＳ＞＝次に転送される約１データ・バイトを示す、入力ヘッダーＩＮＳ
バイトの補数であるプロトコル・バイト。 ＜ＳＷ１，ＳＷ２＞＝ＩＳＯ７８１６−４内のような応答状態バイト。 ＩＳＯ７８１６−４ケース２ Ｌｅ＝＝Ｌｒ １．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用
して、Ｌｒバイトの出力データを送信する。 ２．カードが、Applet.processメソッドの完了時に＜ＳＷ１，ＳＷ２＞完了状態
を送信する。 Ｌｒ＜Ｌｅ １．カードが、＜０ｘ６１，Ｌｒ＞完了状態バイトを送信する。 ２．ＣＡＤが、Ｌｅ＝ＬｒでもってＧＥＴ ＲＥＳＰＯＮＳＥ命令を送信する。 ３．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用
して、Ｌｒバイトの出力データを送信する。 ４．カードが、Applet.processメソッドの完了時に＜ＳＷ１，ＳＷ２＞完了状態
を送信する。 Ｌｒ＞Ｌｅ １．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用
して、Ｌｅバイトの出力データを送信する。 ２．カードが、＜０ｘ６１，（Ｌｒ−Ｌｅ）＞完了状態バイトを送信する。 ３．ＣＡＤが、新Ｌｅ＜＝Ｌｒで持つＧＥＴ ＲＥＳＰＯＮＳＥ命令を送信する
。 ４．カードが、標準のＴ＝０＜ＩＮＳ＞又は＜〜ＩＮＳ＞手順バイト機構を使用
して、（新）Ｌｅバイトの出力データを送信する。 ５．要求されるならば残りの出力データ・バイト（Ｌｒ）を送るのに必要なステ
ップ２−４を繰返す。 ６．カードが、Applet.processメソッドの完了時に＜ＳＷ１，ＳＷ２＞完了状態
を送信する。 ＩＳＯ７８１６−４ケース４ ケース４において、Ｌｅは以下の初期交換後に決定される。 １．カードが、＜０ｘ６１，Ｌｒ状態バイト＞を送信する。 ２．ＣＡＤが、Ｌｅ＜＝Ｌｒを持つＧＥＴ ＲＥＳＰＯＮＳＥ命令を送信する。 プロトコル順序の残りは、上記のケース２と同じ。 もし、アプレットが早く中止してＬｅバイトよりも少なく送信すると、ＣＡＤが
期待する転送長を満たすためにゼロが代りに送られてもよい。

【０１４１】 ８．１．１．２通常の出力転送 アプレットにより出力転送の無連鎖モードが要求されない時（すなわち、setO
utgoing方法が使用される）、以下のプロトコル順序が続く。 どんなＩＳＯ−７８１６−３／４準拠Ｔ＝０プロトコル転送順序が使用できる
。 注−sendBytes又はsendBytesLongメソッドの連続したコール間でアプレットによ
り、waitExtensionメソッドを呼出すことができる。waitExtensionメソッドは、
0x60手順バイトを使用して追加の作業時間を要求する（ＩＳＯ−７８１６−３）
。

【０１４２】 ８．１．１．３追加的Ｔ＝０要件 何時でも、Ｔ＝０出力転送プロトコルが使用中で、そしてＡＰＤＵクラスがカ
ードからの＜０ｘ６１，ｘｘ＞の返答状態に応答してＣＡＤからのＧＥＴ ＲＥ
ＳＰＯＮＳＥ命令を待っている時、もしＣＡＤが異なる命令を送れば、sendByte
s又はsendBytesLongメソッドは理由コードNO_TO_GETRESPONSEと共にAPDUExcepti
onを投げる。 この点からのsendBytes又はsendBytesLongメソッドへのコールは、理由コード
ILLEGAL_USEと共にAPDUExceptionを生ずる。もし、NO_T0_GETRESPONSE例外が投
げられた後に、アプレットによりISOExceptionが投げられると、ＪＣＲＥはその
理由コードの返答状態を破棄する。ＪＣＲＥは新たに受取った命令と共にＡＰＤ
Ｕを再開し、ＡＰＤＵの発送を再開する。

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

【０１４４】 ８．１．２．２通常の出力転送 アプレットにより出力転送の無連鎖モードが要求されない時、すなわち、setO
utgoing方法が使用される時、以下のプロトコル順序が続く。 どんなＩＳＯ−７８１６−３／４準拠Ｔ＝１プロトコル転送順序が使用できる
。 注−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_RESOU
RCE、を持った、SystemException、を生ずる。一時的配列を生成するために使用
されるＪＣＳｙｓｔｅｍ内のフアクトリイ・メソッドは、一時的空間の不足を示
すために、理由コード、NO_TRANSIENT_SPACE、を持った、SystemException、を
投げる。 スタックのオーバーフローなどの全ての仮想マシン・エラー（回復不可能）は
、仮想マシン・エラーを生ずる。これらの状態は仮想マシンを停止させる。この
ような回復不可能な仮想マシン・エラーが発生する時、実現は選択的にカードを
ミュートにするか将来の使用を阻止することを要求できる。

【０１４８】 １０．アプレット・インストラー ジャバ・カード技術を使用したスマート・カード上のアプレット・インストレ
ーションは、複雑なトピックである。ジャバ・カードＡＰＩ２．１は、それらの
実現において可能な限りの多くの自由度を、ＪＣＲＥ実現者に与えることを意図
している。しかし、いくつかの基本的な共通仕様が、ジャバ・カード・アプレッ
トがインストールする特定のインストーラの実現の詳細を知ることなくインスト
ールすることを可能にするために、要求される。 この仕様は、インストーラの概念を定義し、そして広い範囲にわたり可能なイ
ンストーラの実現の相互操作を達成するために、最小のインストレーション要件
を詳細に示す。 アプレット・インストーラはＪＣＲＥ２．１仕様の選択的な部分である。すな
わち、ＪＣＲＥの実現は、発行後にインストーラを含むことは必ずしも必要でな
い。しかし、もし実現されれば、インストーラは節９．１に詳細に説明された振
舞いを支援することが要求される。

【０１４９】 １０．１インストーラ ジャバ・カード技術を使用してスマート・カード上にアプレットをインストー
ルするために必要な機構は、インストーラと呼ばれるカード上の部品に具体化さ
れている。 ＣＡＤに対して、インストーラはアプレットに見える。それはＡＩＤを持ち、
そしてこのＡＩＤがセレクト命令により成功的に処理された時に現在選択された
アプレットとなる。一旦、選択されると、インストーラは他のアプレットと同様
に振舞う。 ・その他の選択されたアプレットと同様に、それは全てのＡＰＤＵを受取る。 ・その設計仕様は、さまざまな前処理下でこれらの命令のセマテイックスと共に
受取るこてが期待されるＡＰＤＵのフォーマット及び様々な種類を規定する。 ・それが受取る全てのＡＰＤＵを処理して応答する。不正確なＡＰＤＵはある種
類のエラー状態を持って応答される。 ・別のアプレットが選択された時（又はカードがリセットされた時又は電源がカ
ードから取外された時）、インストーラは選択解除されて、それが選択される次
の時まで中止される。

【０１５０】 １０．１．１インストーラ実現 インストーラは、カード上にアプレットとして実現する必要はない。要件は、
インストーラの機能は選択可能であることだけである。この要件の結果として、
インストーラ成分は、非インストーラ・アプレットが選択された時又はアプレッ
トが選択されない時、呼出すことができない。 明らかに、ＪＣＲＥ実現者はインストーラをアプレットとして実現できること
を選択できる。もしそうならば、インストーラはアプレット・クラスを拡張する
ためにコードされて、セレクト、プロセス、及びデセレクト・メソッドの呼出し
に応答する。 しかし、ＪＣＲＥ実現者は、インストーラをそれが外界に対して選択可能な振
舞いを与える限り、別の方法で実現できる。この場合、ＪＣＲＥ実現者はＡＰＤ
Ｕがインストーラ・コード・モジュールに配達される別の機構を与える自由度を
有する。

【０１５１】 １０．１．２インストーラＡＩＤ インストーラは選択可能であるから、それはＡＩＤを有する。ＪＣＲＥ実現者
はそれらのインストーラが選択されるＡＩＤを自由に選択できる。複数のインス
トーラが実現できる。

【０１５２】 １０．１．３インストーラＡＰＤＵ ジャバ・カードＡＰＩ２．１は、インストーラに対してＡＰＤＵを指定しない
。ＪＣＲＥは実現者はそれらのインストーラに仕事を指示するためにＡＰＤＵ命
令を完全に自由に選択できる。 モデルは、カード上のインストーラがＣＡＤ上で走るインストレーション・プ
ログラムにより駆動される。インストレーションが成功するために、このＣＡＤ
インストレーション・プログラムは以下のことが可能でなければならない。 ・カードを認識する。 ・カード上のインストーラを選択する。 ・適当なＡＰＤＵをカード・インストーラに送ることにより、インストレーショ
ン・プロセスを駆動する。これらのＡＰＤＵは、以下を含む。 ＞インストレーションが認証されることを保証するための、認証情報。 ＞カード・メモリ内にロードされるべきアプレット・コード ＞カード上に既に存在するコードとアプレット・コードをリンクするためのリン
ケージ情報 ＞アプレットのインストール・メソッドに送られるべきインスタンス・イニシャ
ライゼーション・パラメータ・データ ジャバ・カードＡＰＩ２．１はＣＡＤインストーレイション・プログラムの詳
細を指定せず、また、ＡＰＤＵはそれとインストーラの間に送られない。

【０１５３】 １０．１．４インストーラ振舞い ＪＣＲＥ実現者は、以下を含むそれらのインストーラの他の振舞いを定義しな
ければならない。 ・インストーレイションが中止できるかどうか、そしてこれがいかになされたか
。 ・インストーレイション中に、もし例外、リセット、又は電源喪失が発生したら
、何が生ずるか。 ・インストーラがその仕事を終える前に、もし別のアプレットが選択されたら何
が生ずるか。 ＪＣＲＥは、以下の場合、アプレットが成功的にインストールされたと見なさ
れないことを保証する。 ・Applet.registerメソッドからの成功的な戻りの前に、アプレットのインスト
ール・メソッドが例外を投げる（パラグラフ９．２参照）。

【０１５４】 １０．１．５インストーラ特権 インストーラはアプレットとして実現できるが、インストーラは典型的に「他
のアプレット」に利用可能ではない特徴にアクセスする必要がある。例えば、Ｊ
ＣＲＥ実現者の実現に依存して、インストーラは次のことが必要である。 ・オブジェクト・システム及び／又は標準セキュリテイをバイパスして、直接に
メモリに読み書きする。 ・他のアプレット又はＪＣＲＥにより所有されたオブジェクトへのアクセス。 ・ＪＣＲＥの非入口点メソッドを呼出す。 ・新たにインストールされたアプレットのインストール・メソッドを呼出すこと
ができる。 再び、インスートラ実現を決定し、そしてインストーラを支援するのに必要な
ＪＣＲＥ実現内の特徴を供給することは、各ＪＣＲＥ実現者の責任である。ＪＣ
ＲＥ実現者は、普通のアプレットに利用できないようにするため、そのような特
徴のセキュリテイに責任を有する。

【０１５５】 １０．２新にインストールされたアプレット インストーラとインストールされているアプレットの間に単一のインターフエ
イスが存在する。インストーラが正しく実行（ローデイング及びリンキングなど
の実行されたステップ）するためのアプレットを準備した後に、インストーラは
アプレットのインストール・メソッドを呼出す。このメソッドはアプレット・ク
ラスと定義される。 インストーラからアプレットのインストール・メソッドが呼出される正確な機
構は、ＪＣＲＥ実現者定義の実現詳細である。しかし、インストール・メソッド
（新しいオブジェクトを生成するなど）により実行されたコンテキストに関係し
た操作が新アプレットのコンテキスト内でなされ、そしてインストーラのコンテ
キスト内でないようにするため、コンテキスト切換えがある。インストーラはア
プレット・クラス初期化（＜ｃｌｉｎｔ＞）メソッド中に生成された配列オブジ
ェクトが、新アプレットのコンテキストにより所有されることも保証する。 もし全てのステップが失敗又は例外が投げられることなく、実行するApplet.r
egisterメソッドからの成功的な戻りを含むまで、完了した場合、アプレットの
インストレーションは完全とみなされる。その点において、インストールされた
アプレットは選択可能である。 パラメータ・データの最大サイズは３２バイトである。セキュリテイの理由の
ため、ｂＡｒｒａｙパラメータは戻りの後にゼロにされる（ＡＰＤＵバッフアが
アプレットのプロセス・メソッドからの戻りの際にゼロにされるのと同様）。

【０１５６】 １０．２．１インストーレイション・パラメータ ３２バイトの最大サイズ以外に、ジャバ・カードＡＰＩ２．１インストーレイ
ション・パラメータ・バイト配列セグメントの内容について何ら指示しない。こ
りはアプレット設計者により完全に定義され、所望のどんなフオーマットででき
る。これに加え、これらインストレーション・パラメータはインストーラーに不
透明であることを意図している。 ＣＡＤ内で実行されるインストレーション・プログラムがインストーラに配達
されるべき任意のバイト配列を指定することを可能にするように、ＪＣＲＥ実現
者はそれらのインストーラを設計すべきである。インストーラは、単にこのバイ
ト配列をｂＡｒｒａｙパラメータ内の目標のアプレットのインストール・メソッ
ドヘ転送する。典型的な実現は、セマンテイック「付随するバイト配列の内容を
送るアプレットのインストール・メソッドをコール」を有するＪＣＲＥ実現者専
有ＡＰＤＵ命令を定義する。

【０１５７】 １１．ＡＰＩ定数 いくつかのＡＰＩクラスは、ジャバ・カードＡＰＩ２．１レファレンス内にそ
れらの定数を指定された値を有しない。もし、一定の値がこのＪＣＲＥ２．１仕
様の実現者により一貫して指定されない場合、業界全体の互換性は不可能である
。この章はジャバ・カードＡＰＩ２．１レファレンス内で指定されない必要な一
定の値を与える。

【０１５８】

【表１】

【０１５９】

【表２】

【０１６０】

【表３】

【０１６１】 用語集 ＡＩＤは、ＩＳＯ７８１６−５に定義されたアプリケーション識別子の略。 ＡＰＤＵは、ＩＳＯ７８１６−４に定義されたアプリケーション・プロトコル
・データ・ユニットの略。 ＡＰＩは、アプリケーション・プログラム・インターフエイスの略。ａｐｉは
アプリケーション・プログラムがオペーレーテイング・システム又はその他のサ
ービスをアクセスするときに呼ぶ約束事を定義する。 アプレットは、この書類の文脈内では、ジャバ・カード技術内の選択、コンテ
キスト、機能、及びセキュリテイの基本的単位である、ジャバ・カード・アプレ
ットである。 アプレット開発者は、ジャバ・カード技術仕様を用いてジャバ・カード・アプ
レットを生成する人を言う。 アプレット・フアイヤウォールは、ＶＭが他のアプレット・コンテキスト又は
ＪＣＲＥコンテキストにより所有されたオブジェクトへのアプレットの認証され
ないアクセスから防止し、そして違反を報告し又は対処するジャバ・カード技術
内の機構。 アトミック操作は、その全体が完了するか（もし操作が成功すると）、又は操
作のどの部分も全く完了しない（もし操作が失敗したら）のいずれかである操作
である。 アトミシテイは、特定の操作がアトミックであるか否か、そして電源が喪失、
又はカードがＣＡＤから予期されずに取外された場合の適当なデータ回復が必要
な操作を言う。 ＡＴＲは、リセットの返答の略。ＡＴＲは、リセット条件後にジャバ・カード
により送られる一連のバイトである。 ＣＡＤは、カード受入装置の略。ＣＡＤはカードが挿入される装置である。 キャストは、１つのデータ・タイプから別のタイプへの明示的な変換である。 ｃＪＣＫは、ジャバ・カード技術仕様の実現の許容性を確証するためのテスト
の一揃い。ｃＪＣＫはテストの一揃いを実行するためジャバ・テスト・ツールを
使用する。 クラスは、オブジェクト指向言語のオブジェクトの原型（プロトタイプ）であ
る。クラスは共通の構造と振舞いを共有する１組のオブジェクトとみなすことが
できる。クラスの構造は、そのクラスのオブジェクトの状態を表すクラス変数に
より定義され、その振舞いはクラスに関連する１組のメソッドにより与えられる
。 クラスは、クラス階層に関係する。１つのクラスは他のクラス（そのスーパー
クラス）の特別化（サブクラス）であってよい。それは他のクラスへの参照を有
し、そしてそれは他のクラスをクライアント−サーバー関係で使用してもよい。
コンテキスト（アプレット実行コンテキスト参照）。 現在活動的なコンテキスト。ＪＣＲＥは現在活動的なジャバ・カード・アプレ
ット・コンテキストの記録を残す。仮想メソッドがオブジェクト上で呼出され、
そしてコンテキスト切換えが必要とされ、そして許可される時、現在活動的なコ
ンテキストはそのオブジェクトを所有するアプレット・コンテキストに対応する
ために変化される。そのメソッドが戻る時、前のコンテキストが回復される。静
的メソッドの呼出しは現在活動的なコンテキストについて影響を与えない。オブ
ジェクトの現在活動的なコンテキスト及び共有状態は一緒に、オブジェクトへの
アクセスが許可されるかどうかを決定する。 現在選択されたアプレット。ＪＣＲＥは現在選択されたジャバ・カード・アプ
レットの記録を残す。このアプレットのＡＩＤを有する選択命令を受取る際、Ｊ
ＣＲＥはこのアプレットを現在選択されたアプレットとする。ＪＣＲＥは全ての
ＡＰＤＵ命令を現在選択されたアプレットに送る。 ＥＥＰＲＯＭは、電気的消去可能プログラム可能読み出し専用メモリの略。 フアイヤウォール（アプレット・フアイヤウォール参照）。 フレームワークは、ＡＰＩを実現する１組のクラス。これはコア及び拡張パッ
ケージを含む。責任は、ＡＰＤＵの発送、アプレット選択、アトミシテイ管理、
及びアプレット・インストーリングを含む。 ガーベッジ・コレクションは、プログラムの実行時に自動的に再クレームされ
る動的に割当てられた記憶によるプロセスを言う。 インスタンス変数はまたフイールドとして知られていて、オブジェクトの内部
状態の一部を表す。各オブジェクトはそれ自身のインスタンス変数の組を有する
。同じクラスのオブジェクトは同じインスタンス変数を有するが、各オブジェク
トは異なった値を持つことができる。 インスタンシエイションとは、オブジェクト指向プログラミングにおいて、そ
のクラス・テンプレートから特定のオブジェクトを生成することを意味する。こ
れはテンプレートにより指定されたタイプを持つデータ構造の割当てと、デフォ
ルト値又はクラス建設関数により与えられた値でインスタンス変数を初期化する
ことを含む。 ＪＡＲは、ジャバ・アーキテクチャの略。ＪＡＲは多くのフアイルを１つに結
合するプラットホームに依存しないフアイル・フオーマットである。 ジャバ・カード実行時環境（ＪＣＲＥ）は、ジャバ・カード仮想マシンねフレ
ームワーク、及び関連のネイテイブ・メソッドからなる。 ＪＣ２１ＲＩは、ジャバ・カード２．１レファレンス実行の略。 ＪＣＲＥ実現者は、ジャバ・カードＡＰＩを使用してベンダー固有の実現を作
成する人。 ＪＣＶＭは、ジャバ・カード仮想マシンの略。ＪＣＶＭは、ＯＰカード・アー
キテクチャの基礎である。ＪＣＶＭは、バイトコードを実行し、そしてクラス及
びオブジェクトを管理する。これはアプリケーション間の分離（フアイヤウォー
ル）を実施し及び安全なデータ共有を可能にする。 ＪＤＫは、ジャバ開発キットの略。ＪＤＫはジャバでプログラムするために必
要な環境を与えるサン・マイクロシステムズ社の製品。ＪＤＫはさまざまなプラ
ットホームで利用可能であるが、最も有名なのは、サン・ソラリス及びマイクロ
ソフト・ウインドウズ（商標）である。 メソッドは、オブジェクト指向言語において、１つ又は複数のクラスと関連し
た手順若しくはルーチンに与えられた名前である。 名前空間は、全ての名前が独特な１組の名前。 オブジェクト指向は、メソッドと呼ばれるデータを操作する１組のルーチンに
よりカプセル化されたデータ構造である、オブジェクトに基づいたプログラミン
グ方式である。 オブジェクトは、オブジェクト指向プログラミングにおいて、そのクラスによ
り与えられたテンプレートに従い定義されたデータ構造の独特なインスタンスで
ある。各オブジェクトは、そのクラスに属する変数についてそれ自身の値を有し
、そのクラスにより定義されたメッセージ（メソッド）に応答できる。 パッケージは、ジャバ・プログラミング言語内の名前空間であり、クラス及び
インターフエイスを有することができる。パッケージはジャバ・プログラミング
言語内の最小ユニットである。 持続性オブジェクトは、持続性オブジェクトとそれらの値が、無限に、１つの
ＣＡＤセッションから次に持続するものであるるオブジェクトはデフォルトで持
続性である。持続性オブジェクトの値はトランザクションによりアトミカリイに
更新される。持続性の語はカード上にオブジェクト指向データベースが存在する
ことを意味しない。又、オブジェクトが直列化／非直列化されることを意味しな
い。カードが電源を喪失する時にオブジェクトが失われないことを意味する。 共有可能インターフエイスは、共有されたインターフエイス・メソッドの１組
を定義する。これらのインターフエイス・メソッドは、それらを実現するオブジ
ェクトが別のアプレット・コンテキストにより所有されている時、１つのアプレ
ット・コンテキストにより呼出すことができる。 共有可能インターフエイス・オフジェクト（ＳＩＯ）は、共有可能インターフ
エイスを実現するオブジェクトである。 トランザクションは、開発者がプログラム・コード内にトランザクションの開
始及び終了を指示することにより操作の広がりを定義する、アトミック操作であ
る。 一時的オブジェクト。一時的オブジェクトの値は、１つのＣＡＤセッションか
ら次のセッションに持続せず、特定の間隔でデフォルト値にリセットされる。一
時的オブジェクトの値の更新はアトミックではなく、トランザクションにより影
響されない。

【０１６２】 1/5/99 12:49PM Havnor: Stuff: JCRE D2 14DEC98: READ-ME-JCRE21-DF2.txt Pa
ge 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

【図面の簡単な説明】

【図１】 スマート・カードのカード受入装置を装備されたカード受入装置と一緒に使用
するためのコンピュータを示す図。

【図２】 ネットワークに接続されカード受入装置を装備されたコンピュータを示す図。

【図３】 従来技術のスマート・カードなどの小面積装置の例示的なハードウェア・アー
キテクチャを示す図。

【図４】 従来技術で使用される原理によりアクセスされるオブジェクトを示す図。

【図５】 本発明のさまざまな実施の形態を説明するのに使用できる例示的なセキュリテ
イ・モデルを示す図。

【図６】 本発明の１つの観点によるコンテキスト障壁又はフアイヤ・ウォールによる実
行コンテキストの分離を示すブロック図。

【図７】 本発明を実行するのに有用なソフトウェア・アーキテクチャを示す図。

【図８】 本発明の１つの観点によるフアイヤウォールを実現するセキュリテイ増強プロ
セスのフロー・チャート。

【図９】 本発明の１つの観点によるフアイヤウォールを横断するオブジェクトのアクセ
スを示すブロック図。

【図１０】 フアイヤウォールを横断するカスケードされたオブジェクトを示すブロック図
。

【図１１】 １つのコンテキスト中の主成分によるフアイヤウォールを横断して別のコンテ
キストへのアクセスを許可するプロセスのフロー・チャート。

【図１２】 フアイヤウォールを横断したアクセスを許可するための入口点オブジェクトの
使用を声明するブロック図。

【図１３】 フアイヤウォールを横断するアクセスのための配列などのグローバル・データ
構造の使用を説明するブロック図。

【図１４】 フアイヤウォールを横断するアクセスを許可するためのスーパーコンテキスト
の使用を説明するブロック図。

【図１５】 フアイヤウォールを横断するアクセスを許可するための共有可能インターフェ
イス・オブジェクトの使用を説明するブロック図。

【図１６】 フアイヤウォールを横断したアクセスを許可するセキュリテイ増強プロセスの
フロー・チヤート。

【図１７】 ブロック１６２０の詳細を示す図１６のフローチャート。

【図１８】 図１７のブロック１６２９の例示的実現を示すフローチャート。

【手続補正書】

【提出日】平成１４年４月２５日（２００２．４．２５）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正の内容】

【特許請求の範囲】

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ， ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＲ，ＫＺ，ＬＣ，Ｌ Ｋ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，Ｔ Ｊ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ ，ＹＵ，ＺＡ，ＺＷ (72)発明者 サッサー ジョシュア アメリカ合衆国 カリフォルニア州 94114 サン フランシスコ セヴンティ ーンス ストリート ＃11 4150 (72)発明者 バトラー ミッチェル ビー アメリカ合衆国 カリフォルニア州 94087 サニーヴェイル ノース カスケ イド テラス 522 (72)発明者 ストレイチ アンディー アメリカ合衆国 カリフォルニア州 94404 フォスター シティー ビーチ パーク ブールヴァード 693 Ｆターム(参考） 5B017 AA01 BA06 CA15 5B035 AA06 BB09 CA11 CA29 5B098 GA02 GA04 GA07

Claims (24)

【特許請求の範囲】
1. 【請求項１】 小面積装置であって、 ａ．少なくとも１つの処理要素と、 ｂ．メモリと、 ｃ．前記メモリ及び前記処理要素を使用して、プログラム・モジュールを互い
   に隔離するためのコンテキスト障壁と、 ｄ．前記コンテキスト障壁の制約無しに全てのプログラム・モジュールへのア
   クセスを有する１つコンテキストと、 を備えた小面積装置。
2. 【請求項２】 前記コンテキストが、コンテキスト障壁を横断して少なくと
   も１つのプログラム・モジュールへのアクセスに使用される請求項１に記載の小
   面積装置。
3. 【請求項３】 前記コンテキストが各プログラム・モジュールに別の名前空
   間を割当てる請求項１に記載の小面積装置。
4. 【請求項４】 前記コンテキストが、異なる名前空間に位置する少なくとも
   １つの他のプログラム・モジュールにアクセスできる請求項３に記載の小面積装
   置。
5. 【請求項５】 前記コンテキストが各プログラム・モジュールに別のメモリ
   空間を割当てる請求項１に記載の小面積装置。
6. 【請求項６】 前記コンテキストが、異なるメモリ空間に位置する少なくと
   も１つのプログラム・モジュールにアクセスできる請求項５に記載の小面積装置
   。
7. 【請求項７】 前記コンテキスト障壁が、プリンシパル、オブジェクト及び
   アクションの少なくとも１つについて少なくとも１つのセキュリテイ検査を実施
   する請求項１に記載の小面積装置。
8. 【請求項８】 少なくとも１つのセキュリテイ検査がプリンシパル及びオブ
   ジェクトの間の部分的な名前の一致に基づいている請求項７に記載の小面積装置
   。
9. 【請求項９】 前記コンテキストが前記少なくとも１つのセキュリテイ検査
   無しに少なくとも１つの他のコンテキストにアクセス可能な請求項８に記載の小
   面積装置。
10. 【請求項１０】 少なくとも１つのセキュリテイ検査がプリンシパル及びオ
    ブジェクトの間のメモリ空間の一致に基づいている請求項７に記載の小面積装置
    。
11. 【請求項１１】 前記コンテキストが前記少なくとも１つのセキュリテイ検
    査無しに少なくとも１つの他のコンテキストにアクセス可能な請求項１０に記載
    の小面積装置。
12. 【請求項１２】 コンテキスト障壁を使用してプログラム・モジュールを分
    離し、１つのコンテキストをコンテキスト障壁の制約無しに少なくとも１つの他
    のコンテキストにアクセスを許可するステップを含む、小面積装置を操作する方
    法。
13. 【請求項１３】 コンテキスト障壁は、もしプリンシパルが前記１つのコン
    テキスト部分ではなく、又は、プリンシパル及びオブジェクトの両方が同じコン
    テキストの部分でなければ、プリンシパルがオブジェクトへのアクションを実行
    することを許可しない請求項１２に記載の方法。
14. 【請求項１４】 小面積装置上において、コンテキスト障壁により分離され
    た第１プログラム・モジュールから第２プログラム・モジュールへ情報をアクセ
    スすることを許可する方法であって、コンテキスト障壁の制約無くして全てのプ
    ログラム・モジュールにアクセスできる１つのコンテキストを生成するステップ
    を含む方法。
15. 【請求項１５】 前記コンテキストが、スーパーコンテキストである請求項
    １４に記載の方法。
16. 【請求項１６】 小面積装置上において、プログラム・モジュールを分離す
    るコンテキスト障壁を横断して通信する方法であって、 ａ．コンテキスト障壁の制約無くして全てのプログラム・モジュールにアクセ
    スできる１つのコンテキストを生成し、 ｂ．他のプログラムの情報へ前記コンテキスト障壁を横断してアクセスするこ
    とを前記コンテキストに許可する、 各ステップを含む方法。
17. 【請求項１７】 小面積装置上において、プログラム・モジュールを分離す
    るコンテキスト障壁を横断して通信する方法であって、 ａ．コンテキスト障壁の制約無くして全てのプログラム・モジュールにアクセ
    スできる１つのコンテキストを生成し、 ｂ．前記コンテキストを使用して、他のプログラムの情報へ前記コンテキスト
    障壁を横断してアクセスすることを、少なくとも１つのプログラム・モジュール
    に許可する、 各ステップを含む方法。
18. 【請求項１８】 コンピュータ・プログラム製品であって、 ａ．メモリ媒体と、 ｂ．小面積装置上にコンテキスト障壁を実現し、そしてひとつのコンテキスト
    に前記コンテキスト障壁の制約無くして全てのプログラム・モジュールへのアク
    セスを与える命令を含むコンピュータ制御要素と、 を含むコンピュータ・プログラム製品。
19. 【請求項１９】 前記媒体が、搬送波である請求項１８に記載のコンピュー
    タ・プログラム製品。
20. 【請求項２０】 コンピュータ・プログラム製品であって、 ａ．メモリ媒体と、 ｂ．小面積装置において、それぞれのコンテキスト内で複数のプログラムを実
    行することにより複数のプログラムを分離し、そして１つのコンテキストにコン
    テキスト障壁の制約無しに全てのプログラム・モジュールへのアクセスを許可す
    るための命令を含むコンピュータ制御要素と、 を含むコンピュータ・プログラム製品。
21. 【請求項２１】 前記媒体が、搬送波である請求項２０に記載のコンピュー
    タ・プログラム製品。
22. 【請求項２２】 通信リンクを介して小面積装置上にコンテキスト障壁の制
    約無しに全てのプログラム・モジュールへのアクセスを有するコンテキストを実
    現するための命令を運ぶ搬送波。
23. 【請求項２３】 小面積装置上においてそれぞれのコンテキスト内で複数の
    プログラムを実行することにより複数のプログラムを分離するコンテキスト障壁
    を実現し、そして１つのコンテキストにコンテキスト障壁の制約無くして全ての
    プログラムにアクセスを許可するための命令を、通信リンクを介して運ぶ搬送波
    。
24. 【請求項２４】 ネットワークを介してコードを送信する方法であって、サ
    ーバーからコードのブロックを送信するステップを含み、前記コードのブロック
    はコンテキスト障壁を横断してアクセスするために全てのプログラム・モジュー
    ルに対してアクセスを有するコンテキストを実現するための命令を含む方法。