JP4850073B2 - コンフィギュラブルファイヤウォールを利用するシステム、方法、及びコンピュータ読み取り可能な記憶媒体 - Google Patents

Description

本発明は、コンピューティングシステムに関し、特に、安全なコンピューティングシステムを提供する手法に関する。

通常のデスクトップと異なり、他のコンピューティング機器は携帯型であり、特定の用途に高度に特化しており、相対的に少ないメモリ、および／または処理制約と共に動作する。一例として、スマートカードは、特定の用途（例えば、セキュリティ）に高度に特化可能な携帯コンピューティング機器を代表するものである。スマートカードは、提供可能なメモリ量および処理能力が一般にデスクトップ（例えば、パーソナルコンピュータ）環境のものほど多くないコンピューティング環境の例でもある。そのため、スマートカードは、好例となり得るものであり、以下に説明する。

スマートカードは、重要情報を格納するために使用されるメモリカード（例えば、フォンカード）の形態で約２０年前に導入された。しかしながら、現在のスマートカードは、最初に導入されたものに比べ、遙かに高度化している。現在、スマートカードは、埋め込み集積回路（ＩＣ）を有することができる。スマートカードは、例えば、埋め込み集積回路（ＩＣ）を含むプラスチックカードである。スマートカードは、クレジットカードのようにすることができる。さらに、機密性の高い用途（例えば、バンキング、セキュリティ）にも使用できる。その結果として、安全なスマートカードを開発するために、多数の団体が広範な活動を行っている。

スマートカードは、国際標準化機構（ＩＳＯ）および国際電気標準会議（ＩＥＣ）の第１合同技術委員会（ＪＴＣ１）により定義および管理されている業界標準である。１９８７年に導入され、２００３年に最新の更新が行われた一連の国際規格ＩＳＯ／ＩＥＣ７８１６では、スマートカードの様々な態様を定義しており、これには物理的特徴、物理的接触、電子信号および伝送プロトコル、コマンド、セキュリティアーキテクチャ、アプリケーション識別子、共通データ要素が含まれる。

一部の使用領域において、スマートカードは、単に保護された不揮発性ストレージを提供するメモリカードに過ぎない。しかしながら、さらに進んだスマートカードは、マイクロプロセッサとメモリとの両方を有し、安全な処理およびストレージのために使用できる。スマートカードは、電池なしで動作できる（即ち、カードリーダに接続された時のみアクティブとなる）。接続時、リセットシーケンスの後、カードは、受動状態を維持し、クライアント（ホスト）アプリケーションからのコマンド要求受領のため待機する。名称が示すとおり、接触スマートカードは、カードリーダとスマートカードの８ピン接点との間の物理的接触を介して通信することで機能し、一方、非接触スマートカードは、通常２フィート未満の範囲で高周波信号を用いて通信する。非接触スマートカードの無線通信は、盗難防止および在庫追跡のために店舗で使用される高周波ＩＤ（ＲＦＩＤ）タグに類似する技術に基づいている。図１は、接触および非接触スマートカードを表している。図１Ａおよび１Ｂは、それぞれ、接触および非接触スマートカードを表している。

現在の携帯機器の普及を考慮すると、より携帯機器に適したプログラミング環境を開発することが望ましい。こうしたプログラミング環境は、何よりも、安全であるべきである。

上述のように、携帯機器の普及を考慮すると、より携帯機器に適したプログラミング環境を開発することが望ましい。こうしたプログラミング環境は、通常、相対的に限定されたリソース（処理能力および／またはメモリ）での動作、および／または、高度に特化した機能の提供を行う。

プラットフォーム非依存プログラミング環境として、特にＪａｖａ（登録商標、以下において登録商標を“ＴＭ”と表記する）技術は、こうした環境に適している。Ｊａｖａ^TMは、分散環境（例えば、インターネット）での使用に適したプログラミング言語である。Ｃ＋＋言語の「外観および感じ」を有するように設計されているが、Ｃ＋＋よりも使用が容易であり、オブジェクト指向プログラミングモデルを実現する。Ｊａｖａ^TMは、単一のコンピュータで実行し得る、あるいは、ネットワーク内のサーバおよびクライアント間で分散させ得る、完全なアプリケーションを作成するために使用できる。Ｗｅｂページの一部として使用される小さなアプリケーションモジュールであるアプレットを構築するためにも使用できる。アプレットにより、Ｗｅｂページユーザは、ページとの情報のやりとりが可能となる。

Ｊａｖａ^TMプラットフォームは、Ｊａｖａ Ｃａｒｄ^TM技術を含む。Ｊａｖａ Ｃａｒｄ^TM技術により、Ｊａｖａ^TMプログラミングプラットフォームは、高度に特化した環境、および／または、例えばデスクトップコンピューティング環境に比べて厳しいメモリおよび／または処理制約で動作する環境を有するスマートカードその他の携帯機器での使用に適したものとなる。Ｊａｖａ Ｓｍａｒｔ Ｃａｒｄ^TMは、数多くの異なる領域で有用となる。また、高レベルのセキュリティを必要とする情報システムに認証と安全なアクセスとを追加するために使用できる。Ｊａｖａ Ｓｍａｒｔ Ｃａｒｄ^TMに格納された情報は、携帯可能である。Ｊａｖａ Ｃａｒｄ^TM技術により、病歴、クレジットカード番号、または電子マネー残高といった、重要かつ機密の個人情報を、コンパクトだが安全な媒体において持ち運ぶことが可能となる

Ｊａｖａ Ｃａｒｄ^TM技術は、スマートボタンおよびＵＳＢトークン（図１Ｃおよび１Ｄに例示）のように、スマートカード以外の形態でも存在する。スマートカードと同様に、スマートボタンおよびＵＳＢトークンも、例えば、ユーザの認証または機密情報の持ち運びに使用できる。スマートボタンは、電池を内蔵可能で、通常は接触に基づき、一方、ＵＳＢトークンは、ＰＣのＵＳＢポートに直接差し込み可能で、接触または非接触リーダを必要としない。いずれの場合も、こうした他の形態は、スマートカードと同様のプログラミング能力を提供可能であり、不正改変防止特性を有する。

Ｊａｖａ^TMプログラミング環境が提供する保護に加え、Ｊａｖａ^TMカード技術は、追加されたランタイム実行の保護手段として、アプリケーション（またはアプレット）ファイヤウォールを提供する。ファイヤウォールは、基本的には、Ｊａｖａ^TMカードプラットフォームを別個の保護オブジェクト空間（または「コンテキスト」）に区分する。言い換えると、ファイヤウォールは、あるコンテキストと別のコンテキストとの間に境界を提供する。この環境において、別個の保護空間（またはコンテキスト）は、互いにアクセスできない場合がある。

アプレットは、通常、Ｊａｖａ^TMパッケージと呼び得るものの中で、共にパッケージされることに留意されたい。さらに、単一のＪａｖａ^TMパッケージ内の全アプレットは、同じコンテキストを共有することに留意されたい。これは、同じパッケージ内のアプレット間にファイヤウォールが存在しないことを意味する。さらに、ファイヤウォール境界は、アプレットがどのようにパッケージされるかに依存する。これは、個々のアプレットに基づいてファイヤウォール境界を定義できない場合があることを意味する。こうしたファイヤウォールの実装は、パッケージに基づくファイヤウォール環境と呼ぶことができる。

パッケージに基づくファイヤウォール環境において、同じパッケージ内に存在しないアプレット同士のアクセスを可能にするには、比較的複雑な手法が必要となる。一例として、他のアプレットによりアクセス可能なアプレットのために、共有可能なインタフェースを実装する必要がある（例えば、ＪＣＳｙｓｔｅｍ．ｇｅｔＡｐｐｌｅｔＳｈａｒｅａｂｌｅＩｎｔｅｒｆａｃｅＯｂｊｅｃｔ（）メソッド）。その結果、第１のアプレットは、第２のアプレットの共有可能インタフェースへのアクセスを要求できる。次に、第１のアプレットの代わりに、Ｊａｖａ^TMカードランタイム環境（ＪＣＲＥ）は、メソッド（例えば、ｇｅｔＳｈａｒａｂｌｅＩｎｔｅｒｆａｃｅＯｂｊｅｃｔ（）メソッド）を呼び出すことで、第２のアプレットに、共有可能インタフェースを要求することができる。第２のアプレットによりアクセスが許可された場合、第１のアプレットは、第２のアプレットに対する参照を取得する必要がある。

上記を考慮すると、安全なコンピューティング環境を提供するための代替手法は、有用である。本発明の上記その他の目的を達成するために、コンフィギュラブルファイヤウォールを提供するための枠組みを開示する。コンフィギュラブルファイヤウォールは、コンピューティング環境の様々な構成要素間でのアクセス権を実装および制御する機構として使用可能な制御ブロックを提供する。そのため、ファイヤウォール制御ブロックは、コンピューティング環境において、ある構成要素が別の構成要素にアクセス可能かを判定するために使用できる。

一例として、制御ブロックは、本発明の一実施形態によるＪａｖａ^TMカードコンピューティング環境内の各Ｊａｖａ^TMアプリケーション（またはアプレット）に対して提供できる。これにより、ファイヤウォール境界を個別のアプレット毎に選択的に構成および定義できる柔軟な環境が可能となる。これにより、各アプレットが所定のアプレットセットに対するアクセスを許可できると共に、その逆も可能となるような形でファイヤウォール境界を定義できる、柔軟な環境が提供される。

加えて、異なるシステム要件（例えば、処理速度、メモリ）に対して適切となり得る様々な手法を使用して、ファイヤウォール制御ブロックを実装可能であることが例示される。そのため、コンフィギュラブルファイヤウォールは、様々なコンピューティングシステム、特に、相対的に限定された処理能力での動作、および／または高度に特化した機能の提供を行うもの（例えば、スマートカード）に対してセキュリティを実装するのに有用である。さらに例示されるように、多数の形態のファイヤウォール制御ブロックにおいて、様々な手法を使用してセキュリティを実装できる。本発明の他の態様は、様々なファイヤウォール制御ブロックを使用してセキュリティを実装するのに使用可能な手法を提供する。

本発明は、システム、装置、方法、またはコンピュータ読み取り可能な媒体を含む、多数の方法として実装できる。本発明のいくつかの実施形態について、下で説明する。

コンピューティング環境として、本発明の一実施形態は、オペレーティングシステムと、オペレーティングシステム上で動作するバーチャルマシンと、バーチャルマシン上で動作する第１および第２のアプリケーションとを含む。加えて、ファイヤウォール制御ブロックが、コンピューティング環境に提供される。

ファイヤウォール制御ブロックは、第２のアプリケーションに対する第１のアプリケーションのアクセス権を定義し、さらに、第１のアプリケーションに対する第２のアプリケーションのアクセス権を定義する。このファイヤウォール制御ブロックは、例えば、携帯機器用に実装できる。一例として、Ｊａｖａ^TMスマートカードは、本発明によるファイヤウォール制御ブロックを使用して実装可能である。

さらに別の実施形態では、Ｊａｖａ^TM対応コンピューティング環境にセキュリティを提供する方法として実装できる。Ｊａｖａ^TM対応コンピューティング環境は、Ｊａｖａ^TMバーチャルマシンと、Ｊａｖａ^TMバーチャルマシン上で動作する複数のＪａｖａ^TM対応アプレットとを含む。最初に、第１のＪａｖａ^TM対応アプレットからの要求が受領される。この要求は、第２のＪａｖａ^TM対応アプレットにアクセスするための要求である。次に、第２のＪａｖａ^TM対応アプレットに関連するファイヤウォール制御ブロックが読み出される。その後、ファイヤウォール制御ブロックに基づいて、第１のＪａｖａ^TM対応アプレットが第２のＪａｖａ^TM対応アプレットにアクセスするのを許可するべきかが決定される。以下で説明するように、この決定は、様々な異なる基準に基づくものにできる。したがって、第１のＪａｖａ^TM対応アプレットは、アクセスを許可するべきであると決定された場合のみ、アクセスを認められる。同様に、コンピュータプログラムコードを含むコンピュータ読み取り可能な媒体も実装可能である。

本発明は、同様の参照符号が同様の構成要素を示す添付図面と併せて、以下の詳細な説明から容易に理解されよう。

背景の節で説明したように、携帯機器の普及を考慮すると、より携帯機器に適したプログラミング環境を開発することが望ましい。こうしたプログラミング環境は、通常、相対的に限定されたリソース（処理能力および／またはメモリ）での動作、および／または、高度に特化した機能の提供を行う。

プラットフォーム非依存プログラミング環境として、特にＪａｖａ^TM技術は、こうした環境に適している。Ｊａｖａ^TMは、分散環境（例えば、インターネット）での使用に適したプログラミング言語である。Ｃ＋＋言語の「見た目(look and feel)」を有するように設計されているが、Ｃ＋＋よりも使用が容易であり、オブジェクト指向プログラミングモデルを実現する。Ｊａｖａ^TMは、単一のコンピュータで実行し得る、あるいはネットワーク内のサーバおよびクライアント間で分散させ得る、完全なアプリケーションを作成するために使用できる。Ｗｅｂページの一部として使用される、小さなアプリケーションモジュールであるアプレットを構築するためにも使用できる。アプレットにより、Ｗｅｂページユーザは、ページとの情報のやりとりが可能となる。

Ｊａｖａ^TMプラットフォームは、Ｊａｖａ Ｃａｒｄ^TM技術を含む。Ｊａｖａ Ｃａｒｄ^TM技術により、Ｊａｖａ^TMプログラミングプラットフォームは、高度に特化した環境、および／または、例えばデスクトップコンピューティング環境に比べて、厳しいメモリおよび／または処理制約で動作する環境を有するスマートカードその他の携帯機器での使用に適したものとなる。Ｊａｖａ Ｓｍａｒｔ Ｃａｒｄ^TMは、数多くの異なる領域で有用となる。また、高レベルのセキュリティを必要とする情報システムに認証と安全なアクセスとを追加するために使用できる。Ｊａｖａ Ｓｍａｒｔ Ｃａｒｄ^TMに格納された情報は、携帯可能である。Ｊａｖａ Ｃａｒｄ^TM技術により、病歴、クレジットカード番号、または電子マネー残高といった、重要かつ機密の個人情報を、コンパクトだが安全な媒体において持ち運ぶことが可能となる。

Ｊａｖａ Ｃａｒｄ^TM技術は、スマートボタンおよびＵＳＢトークン（図２Ａおよび２Ｂに例示）のように、スマートカード以外の形態でも存在する。これらも、スマートカードと同様に、例えば、ユーザの認証または機密情報の持ち運びに使用できる。スマートボタンは、電池を含み、接触に基づいており、一方、ＵＳＢトークンは、ＰＣのＵＳＢポートに直接差し込み可能で、接触または非接触リーダを必要としない。両方とも、スマートカードと同様のプログラミング能力を提供し、不正改変防止特性を有する。

Ｊａｖａ^TMプログラミング環境が提供する保護に加え、Ｊａｖａ Ｃａｒｄ^TM技術は、追加されたランタイムの実行保護手段として、アプリケーション（またはアプレット）ファイヤウォールを提供する。ファイヤウォールは、基本的には、Ｊａｖａ Ｃａｒｄ^TMプラットフォームを別個の保護オブジェクト空間（または「コンテキスト」）に区分する。言い換えると、ファイヤウォールは、あるコンテキストと別のコンテキストとの間に境界を提供する。この環境において、別個の保護空間（またはコンテキスト）は、互いにアクセスできない場合がある。

アプレットは、通常、Ｊａｖａ^TMパッケージと呼び得るものの中で、共にパッケージされることに留意されたい。さらに、単一のＪａｖａ^TMパッケージ内の全アプレットは、同じコンテキストを共有することに留意されたい。これは、同じパッケージ内のアプレット間にファイヤウォールが存在しないことを意味する。さらに、ファイヤウォール境界は、アプレットがどのようにパッケージされるかに依存する。これは、アプレット毎にファイヤウォール境界を定義できない場合があることを意味する。こうしたファイヤウォールの実装は、パッケージに基づくファイヤウォール環境と呼ぶことができる。

パッケージに基づくファイヤウォール環境において、同じパッケージ内に存在しないアプレット同士のアクセスを可能にするには、比較的複雑な手法が必要となる。一例として、他のアプレットによりアクセス可能なアプレットのために、共有可能なインタフェースを実装する必要がある（例えば、ＪＣＳｙｓｔｅｍ．ｇｅｔＡｐｐｌｅｔＳｈａｒｅａｂｌｅＩｎｔｅｒｆａｃｅＯｂｊｅｃｔ（）メソッド）。その結果、第１のアプレットは、第２のアプレットの共有可能インタフェースへのアクセスを要求できる。次に、第１のアプレットの代わりに、Ｊａｖａカードランタイム環境（ＪＣＲＥ）は、メソッド（例えば、ｇｅｔＳｈａｒａｂｌｅＩｎｔｅｒｆａｃｅＯｂｊｅｃｔ（）メソッド）を呼び出すことで、第２のアプレットに、共有可能インタフェースを要求することができる。第２のアプレットによりアクセスが許可された場合、第１のアプレットは、第２のアプレットに対する参照を取得する必要がある。

上記を考慮すると、安全なコンピューティング環境を提供するための代替手法は、有用である。本発明の上記その他の目的を達成するために、コンフィギュラブルファイヤウォールを提供するための枠組みを開示する。コンフィギュラブルファイヤウォールは、コンピューティング環境の様々な構成要素間でのアクセス権を実装および制御する機構として、制御ブロックを提供する。そのため、ファイヤウォール制御ブロックは、コンピューティング環境において、ファイヤウォール制御ブロックにおいて定義されたアクセス権に基づいて、ある構成要素が別の構成要素にアクセス可能かを決定するために使用できる。

一例として、制御ブロックは、本発明の一実施形態によるＪａｖａ Ｃａｒｄ^TMコンピューティング環境内の各Ｊａｖａ^TMアプリケーション（またはアプレット）に対して提供できる。これにより、各アプレットが所望のアプレットセットにアクセスできるように、ファイヤウォール境界を各アプレットの周囲に構成できる。加えて、例示されるように、ファイヤウォール制御ブロックは、異なるシステム要件（例えば、処理速度、メモリ）において適切となり得る様々な手法を使用して実装できる。そのため、コンフィギュラブルファイヤウォールは、様々なコンピューティングシステム、特に、相対的に限定された処理能力での動作、および／または高度に特化した機能の提供を行うもの（例えば、スマートカード）において、セキュリティを実装するのに有用である。さらに例示されるように、多数の形態のファイヤウォール制御ブロックを、互いに連動させて、あるいは組み合わせて、セキュリティを実装できる。本発明の他の態様は、様々なファイヤウォール制御ブロックを使用してセキュリティを実装するのに使用可能な手法を提供する。

本発明の実施形態について、図１ないし図５を参照して下で説明する。しかしながら、これらの図に関して本明細書に記載する詳細な説明が例示的な目的のみを有し、こうした限定された実施形態の範囲を本発明が超えることは、当業者に容易に理解されよう。

図２は、本発明の一実施形態による、例示的なコンピューティング環境２００を示している。コンピューティング環境２００は、カード側２０２と、リーダ側２０４と、バックエンドアプリケーションおよびシステム２０６とを含む。

説明する実施形態において、カード側２０２は、多重アプリケーション環境を提供するＪａｖａ Ｃａｒｄ^TMプラットフォーム２０２として実装される。図２に示したように、複数のＪａｖａ Ｃａｒｄ^TMアプリケーション（またはアプレット）Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧが、Ｊａｖａ Ｃａｒｄ^TMプラットフォーム２０２（またはＪａｖａ Ｃａｒｄ^TM）に常駐してよい。こうしたＪａｖａ Ｃａｒｄ^TMアプリケーション（またはアプレット）は、Ｊａｖａカードランタイム環境（ＪＣＲＥ）２０８によってサポートされる。Ｊａｖａカードランタイム環境（ＪＣＲＥ）２０８は、Ｊａｖａ Ｃａｒｄ^TMフレームワーク、アプリケーションプログラムインタフェース（ＡＰＩ）、およびセキュリティ２１０を含む。Ｊａｖａカードランタイム環境（ＪＣＲＥ）２０８は、カードオペレーティングシステム（ＯＳ）２１４がサポートするＪａｖａ^TMバーチャルマシン２１２上で動作する。Ｊａｖａ Ｃａｒｄ^TMアプレットＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、およびＨは、ロード時にインスタンス化可能であり、電源をオフにした時も存在し続ける。そのため、カードのアプレットは、サーバと同じように振る舞い、受動状態を維持できる。言い換えると、カードプラットフォーム２０２の電源を入れた後、アプレットは、選択されるまで非アクティブを維持し、選択時に初期化を行ってもよい。

リーダ側２０４は、ホストアプリケーション２２０と、カードアクセプタンスデバイス（ＣＡＤ）２２４とを含む。ホストアプリケーション２２０は、例えば、ＰＣ、電子決済端末、携帯電話、またはセキュリティサブシステム等のデスクトップまたは端末に常駐可能である。いずれの場合も、ホストアプリケーション２２０は、バックエンドアプリケーションおよびシステム２０６とＪａｖａ Ｃａｒｄ^TMアプレットＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧとの間の通信を円滑化できる。カードアクセプタンスデバイス（ＣＡＤ）２２４は、例えば、ホストアプリケーション２２０とＪａｖａ Ｃａｒｄ^TMプラットフォーム２０２との間に位置するインタフェースデバイスにすることができる。加えて、カードアクセプタンスデバイス（ＣＡＤ）２２４は、カードへ電力を提供し、および／または、カード側２０２との電気または（高周波）ＲＦ通信の円滑化を行うことができる。ＣＡＤ２２４は、例えば、シリアルポートを使用してデスクトップコンピュータに取り付けたカードリーダにすることが可能であり、レストランまたはガソリンスタンドの電子決済端末等の端末に統合してもよい。さらに、ＣＡＤ２２４は、例えば、ホストアプリケーション２２０からＪａｖａ Ｃａｒｄ^TMプラットフォーム２０２へアプリケーションプロトコルデータユニット（ＡＰＤＵ）コマンドを転送できることに留意されたい。さらに、アプリケーションプロトコルデータユニット（ＡＰＤＵ）を使用して、Ｊａｖａ Ｃａｒｄ^TMプラットフォーム２０２からホストアプリケーション２２０へ応答を転送することもできる。

したがって、リーダ側２０４により、Ｊａｖａ Ｃａｒｄ^TMプラットフォーム２０２のユーザは、ホストアプリケーション２２０および／またはバックエンドアプリケーションおよびシステム２０６によって提供されるサービスにアクセスできる。バックエンドアプリケーションおよびシステム２０６は、Ｊａｖａ^TMアプレットＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧをサポートするサービスを提供する。例えば、バックエンドアプリケーション２０６は、電子決済システムとの接続を提供する。そのため、バックエンドアプリケーションおよびシステム２０６は、例えば、クレジットカードおよび／またはその他の支払い情報へのアクセスを提供できる。

理解されるように、Ｊａｖａカードランタイム環境（ＪＣＲＥ２０８）は、Ｊａｖａ^TMアプレットＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧにファイヤウォール保護を提供できる。さらに、ランタイム環境（ＪＣＲＥ２０８）によって提供されるファイヤウォール保護は、コンフィギュラブルである。これは、特に、１個以上のＪａｖａ^TMアプレットを含むパッケージ境界に基づいてファイヤウォール保護を定義する必要がないことを意味する。言い換えると、ファイヤウォール保護は、パッケージ２３０、２３２、３２４に基づいて定義する必要がない。ファイヤウォール保護は、さらに説明するファイヤウォール制御ブロック（例えば、図３参照）を使用して構成可能だが、最初に、コンフィギュラブルファイヤウォールについてさらに説明する。

図２に示したように、パッケージ２３０は、Ｊａｖａ^TMアプレットＡおよびＢを含む。同様に、パッケージ２３２は、Ｊａｖａ^TMアプレットＣおよびＤを含む。パッケージ２３４は、Ｊａｖａ^TMアプレットＥ、Ｆ、およびＧを含む。しかしながら、ファイヤウォール境界は、Ｊａｖａ^TMアプレット毎に独立して定義できる。言い換えると、Ｊａｖａ^TMアプレットＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧのそれぞれについて、Ｊａｖａ^TMアプレットを含むパッケージに依存せずにファイヤウォール境界を定義できる。一例として、パッケージ２３０のＪａｖａ^TMアプレットＡには、ファイヤウォール境界部２４０を介して、パッケージ２３２のＪａｖａ^TMアプレットＣへのアクセスを許可できる。しかしながら、ファイヤウォール部２４０は、パッケージ２３０のＪａｖａ^TMアプレットＢがパッケージ２３２のＪａｖａ^TMアプレットＣへのアクセスを試みた時には、そのアクセスを拒否し得る。

更なる説明のために、図２では、Ｊａｖａ^TMアプレットＤの周囲にファイヤウォール境界部２４２を示している。ファイヤウォール境界部２４２は、例えば、同じパッケージ２３２内に含まれるＪａｖａ^TMアプレットＣを含む他の全てのＪａｖａ^TMアプレットによるアクセスを拒否できる。しかしながら、Ｊａｖａ^TMアプレットＤは、他のアプレット（例えば、Ｊａｖａ^TMアプレットＢ）へのアクセスが可能であってもよいことに留意されたい。さらに、ファイヤウォールは、パッケージ境界に関係なく１個以上のＪａｖａ^TMアプレットおよび／またはパッケージによってアクセス可能なライブラリを実装するために使用できることに留意されたい。一例として、Ｊａｖａ^TMアプレットＥおよびＦは、ライブラリ２５０として実装できる。ライブラリ２５０は、Ｊａｖａ^TMアプレットＡ、Ｂ、Ｃ、およびＤのいずれかによってアクセスできる。

上記のように、ファイヤウォール境界は、ファイヤウォール制御ブロックを使用して実装できる。このファイヤウォール制御ブロックは、本発明の一態様により、Ｊａｖａ^TMアプレットおよび／またはＪａｖａ^TMパッケージ毎に定義できる。ファイヤウォール制御は、Ｊａｖａ^TMアプレットに別のＪａｖａ^TMアプレットおよび／またはＪａｖａ^TMパッケージへのアクセスを認めるべきかを決定するのに使用できる。

図３は、本発明の一実施形態によるファイヤウォール制御ブロック３００を示している。ファイヤウォール制御ブロック３００は、ファイヤウォール制御値３０２およびファイヤウォール制御インジケータ３０４を含む。ファイヤウォール制御値３０２は、アクセス権の定義を提供する。ファイヤウォール制御インジケータ３０４は、ある構成要素が別の構成要素にアクセスするべきかを決定するために、定義をどのように解釈するべきかを示す。

ファイヤウォール制御値３０２は、例えば、Ｊａｖａ^TMアプレットに対するファイヤウォールアクセス値を定義するために使用できる。言い換えると、制御値３０２は、第１のＪａｖａ^TMアプレットおよび／またはパッケージに対するアクセス権を定義できる。ファイヤウォール制御インジケータ３０４は、他のＪａｖａ^TMアプレットが第１のＪａｖａ^TMアプレットおよび／またはＪａｖａ^TMパッケージにアクセスできるかを決定するために使用できる。理解されるように、ファイヤウォール制御値３０２および３０４は、例えば、それぞれバイトの配列（即ち、１バイト以上の配列）として実装できる。図３Ｂは、ファイヤウォール制御ブロック３１０の実装を例示している。ファイヤウォール制御ブロック３１０は、Ｍ個のバイトの配列として表されるファイヤウォール制御値を含む。Ｎ個のバイトの配列は、ファイヤウォール制御インジケータを表す。Ｎは、通常Ｍより小さい（即ち、通常、ファイヤウォール制御インジケータに必要なバイト数は少ない）ことに留意されたい。

更なる説明のために、図４は、図２のアプレットＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧに対してそれぞれ実装可能な、簡略化ファイヤウォール制御ブロックＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧを示している。そのため、ファイヤウォール制御ブロックＡは、例えば、どのＪａｖａ^TMアプレットがＪａｖａ^TMアプレットＡによってアクセス可能かを決定するために使用できる。加えて、ファイヤウォール制御ブロックＡは、別のアプレットがＪａｖａ^TMアプレットＡにアクセス可能かを決定するために使用できる。図４に示したように、ファイヤウォール制御ブロックＡは、ファイヤウォール制御値４０２およびファイヤウォール制御インジケータ４０４を含む。ファイヤウォール制御値４０２は、一連の数値（例えば、バイト値｛１，２，３，４，５，６｝）として表現される。

ファイヤウォール制御値４０２（｛１，２，３，４，５，６｝）は、例えば、Ｊａｖａ^TMアプレットＡがＪａｖａ^TMアプレットＣにアクセス可能かを決定するために使用できる。この決定を行うために、ファイヤウォール制御ブロックＣのファイヤウォール制御インジケータ４０８を使用できる。ファイヤウォール制御インジケータ４０８は｛３｝の値を示す。このインジケータ値は、例えば、ファイヤウォール制御ブロックＣのファイヤウォール制御値４０６（｛１，２，３，７，８，９｝）の最初の３個の値に一致するＪａｖａ^TMアプレット（またはパッケージ）へのアクセスを可能にするものと解釈できる。

これは、ファイヤウォール制御値４０２（｛１，２，３，４，５，６｝）の最初の３個の値を、ファイヤウォール制御値４０６（｛１，２，３，７，８，９｝）の最初の３個の値と比較できることを意味する。ファイヤウォール制御値４０２（｛１，２，３，４，５，６｝）の最初の３個の値は、ファイヤウォール制御値４０６（｛１，２，３，７，８，９｝）の最初の３個の値と一致することに留意されたい。したがって、アプレットＡについて、アプレットＣへのアクセスを許可できる。

一方、アプレットＣは、アプレットＡにアクセスできず、これはファイヤウォール制御値４０６（｛１，２，３，７，８，９｝）の最初の４個の値がファイヤウォール制御値４０２（｛１，２，３，４，５，６｝）と一致するべきであることをファイヤウォール制御インジケータ４０４｛４｝が示しているためである。しかしながら、第４の値は、一致していない（即ち、７は、４と等しくない）。したがって、アプレットＣは、アプレットＡへのアクセスを拒否される。

同様に、ファイヤウォール制御値４１０（｛１，９，４，３，５，６｝）の第２の値（または第３の値）がファイヤウォール制御値４０６（｛１，２，３，７，８，９｝）の第２の値（または第３の値）と一致しないため、Ｊａｖａ^TMアプレットＢは、Ｊａｖａ^TMアプレットＣへのアクセスを許可されない。ファイヤウォール制御ブロックＤのファイヤウォール制御インジケータ４１２は、｛４０｝の値を示す。｛４０｝の値は、例えば、他の全てのＪａｖａ^TMアプレットがＪａｖａ^TMアプレットＤにアクセスできない（Ｊａｖａ Ｃａｒｄ^TM管理システムのみがＪａｖａ^TMアプレットＤにアクセスできる）ことを示し得る。しかしながら、Ｊａｖａ^TMアプレットＤは、他のＪａｖａ^TMアプレット（例えば、Ｊａｖａ^TMアプレットＢ）にアクセス可能であってよい。一方、Ｊａｖａ^TMアプレットＥおよびＦにそれぞれ提供されたファイヤウォール制御インジケータ４１４および４１６は、例えば、最初のファイヤウォール制御値が値｛１｝に等しい全てのＪａｖａ^TMアプレット（例えば、アプレットＡ、Ｂ、Ｃ、Ｄ、およびＧ）とのアクセスを可能にするものと解釈可能な｛１｝の値を示し得る。そのため、アプレットＥおよびＦは、例えば、別の選択されたアプレットに対して提供可能なライブラリを表現できる。

図３Ｃは、本発明の別の実施形態による制御ブロック３２０を示している。図３Ｃに示したように、単一のバイトを使用してファイヤウォール制御値３０２を実装し、ファイヤウォール制御値３００をバイトの配列として実装できる。

さらに、本発明の別の実施形態により、追加の単一バイトを使用して、ファイヤウォール制御ブロックを実装できることに留意されたい。この単一バイトは、通常既に利用可能なデータに対して追加できる。説明のため、図３Ｄは、本発明の別の実施形態による、ファイヤウォールコンテキストの実装３３０を表している。ファイヤウォールコンテキストの実装３３０は、通常Ｊａｖａ Ｃａｒｄ^TM環境に提供される、コンテキスト識別情報（ＩＤ）３３２およびアプリケーション識別子データ（ＡＩＤ）を含む。これらに加え、ＡＩＤのバイトインジケータ３３６が提供される。ＡＩＤのバイトインジケータ３３６は、ファイヤウォール制御インジケータ（例えば、図４に示した４０４、４０８）と同様に使用可能であり、一方、アプリケーション識別子データ（ＡＩＤ）は、ファイヤウォール制御値（例えば、図４に示した４０２、４０６）として使用できる。

理解されるように、既存のＪａｖａ Ｃａｒｄ^TM環境と同様に、アプリケーション識別子データ（ＡＩＤ）は、ＩＳＯ７８１６規格に基づいて定義できる。ＩＳＯ７８１６は、スマートカードシステムを構築するための広範な技術について記述したマルチパート規格である。ＩＳＯ７８１６−５は、カードアプリケーション（およびカードファイルシステム内の特定の種類のファイル）を一意に識別するために使用するべきＡＩＤ（アプリケーション識別子）データ形式を定義している。Ｊａｖａ Ｃａｒｄ^TMプラットフォームは、ＡＩＤデータ形式を使用して、アプレットおよびパッケージを特定する。ＡＩＤは、国際標準化機構（ＩＳＯ）によって管理されているため、一意の識別子として使用できる。

図３Ｅに示したように、Ｊａｖａ Ｃａｒｄ^TMプラットフォームで使用するＡＩＤ形式は、２つの別個の部分として解釈されるバイトの配列にすることができる。第１の部分は、ＲＩＤ（リソース識別子）として知られる５バイトの値である。第２の部分は、ＰＩＸ（固有アプリケーション識別子拡張）として知られる可変長の値である。ＰＩＸは、０ないし１１バイトの長さにできる。したがって、ＡＩＤは、全長５ないし１６バイトにできる。ＩＳＯは、企業へのＲＩＤの割り当てを制御しており、各企業はＩＳＯから固有のＲＩＤを取得している。企業は、独自のＲＩＤを使用して、ＡＩＤに対するＰＩＸの割り当てを管理している。Ｊａｖａ^TMプラットフォームにおいて、パッケージは、Ｕｎｉｃｏｄｅ文字列と、インターネットドメイン名に基づく命名体系とを使用して一意に特定される。Ｊａｖａ Ｃａｒｄ^TMプラットフォームにおいて、パッケージおよびアプレットは、ＡＩＤを使用して特定できる。そのため、Ｊａｖａ Ｃａｒｄ^TM技術に対応した装置にインストールされる各アプレットは、一意のＡＩＤを有する。このＡＩＤは、パッケージＡＩＤと同様に構築される。通常は、アプレットプロバイダのＲＩＤと、そのアプレットのＰＩＸとの連結である。

図３Ｆは、本発明のさらに別の実施形態による、ファイヤウォール制御ブロック３５０の実装を示している。ファイヤウォール制御ブロック３５０は、例えば、図３Ｄの制御ブロック３３０の実装に相当する。いずれの場合も、既存のＪａｖａ Ｃａｒｄ^TM環境と同様に、バイト配列を使用して、ＡＩＤを表現し、短い値を使用して、コンテキスト（またはオブジェクト空間）を表現するのに一般的に使用されるコンテキストＩＤを表現する。理解されるように、ＡＩＤバイトインジケータは、単一のバイト値として実装される。そのため、制御ブロック３５０は、ファイヤウォールの実装によるオーバヘッドを最小化する必要がない状況に適したものとなり得る。しかしながら、上記と同様の形で、ＡＩＤバイトインジケータは、ファイヤウォール制御インジケータとして使用可能であり、ＡＩＤは、ファイヤウォール制御値として使用できる。

図３Ｇは、本発明のさらに別の実施形態による、制御ブロック３６０を示している。説明する実施形態において、制御ブロック３６０は、ＲＩＤ値を意味する単一のバイト配列を使用して実装される。これは、Ｊａｖａ^TMアプレット（またはパッケージ）が別のＪａｖａ^TMアプレット（またはパッケージ）にアクセス可能かを決定するために、ＲＩＤ値のみが使用されることを意味する。一例として、ＲＩＤ値が一致する場合にアクセスを許可できる。ＲＩＤ値は、Ｊａｖａ Ｃａｒｄ^TM環境において一般的に提供される。したがって、制御ブロック３６０も、ファイヤウォール制御ブロック情報を格納および処理するための大量のオーバヘッドを必要とすることなく実装できる。ＲＩＤ値と同様に、ＡＩＤ値を使用して、ファイヤウォール制御ブロックを実装できる。

上記に基づき、本発明において、多数の異なるファイヤウォール制御ブロックの実施形態が考えられることは明らかであろう。こうした実施形態の一つ以上は、特定のシステム要件（例えば、メモリストレージ、速度、その他）に適したものになり得る。例えば、図３Ｇの制御ブロック３６０は、ファイヤウォールに指定されたメモリおよびオーバヘッドを最小化するべき環境に適したものになり得る。

さらに、様々な実施形態を組み合わせてよいことにも留意されたい。一例として、図３Ｈは、本発明のさらに別の実施形態による、制御ブロック３７０を示している。制御ブロック３７０は、例えば、制御ブロック３２０および３５０の組み合わせを表現できる。説明する実施形態では、ＡＩＤ、ファイヤウォール制御値、およびファイヤウォール制御インジケータが提供される。下で例示するように、制御ブロック３７０は、Ｊａｖａ^TMカード環境においてコンフィギュラブルファイヤウォールを実装するために様々な手法を使用する柔軟性を提供する。加えて、制御ブロック３７０は、こうした手法のいくつかを例示するのに有用なツールの役割を果たしうる。

したがって、図５は、本発明の一実施形態による、Ｊａｖａ^TMカード環境においてファイヤウォールを提供する方法５００を示している。方法５００は、例えば、ＡＩＤ、ファイヤウォール制御値、およびファイヤウォール制御インジケータが全て提供された図３Ｈの制御ブロック３７０と共に使用できる。最初に、ステップ５０２において、第１のＪａｖａ^TMアプレットの第１のバイトコード命令を読み出す。次に、ステップ５０４において、第１のＪａｖａ^TMアプレットのバイトコードが別の（または第２の）Ｊａｖａ^TMアプレット内のオブジェクトにアクセスを試みているかについて判定する。ステップ５０４において、第１のＪａｖａ^TMアプレットのバイトコードが第２のＪａｖａ^TMアプレット内のオブジェクトにアクセスを試みていないと判定された場合、方法５００は、ステップ５０６へ進み、最後のバイトコード命令に到達したかを判定する。そうである場合、方法５００は終了する。しかしながら、ステップ５０６において、最後のバイトコード命令に到達していないと判定された場合、方法５００は、ステップ５０８へ進み、第１のＪａｖａ^TMアプレットの次のバイトコード命令を読み出す。その後、方法５００は、ステップ５０４へ進み、第１のＪａｖａ^TMアプレットのバイトコードが第２のＪａｖａ^TMアプレット内のオブジェクトにアクセスを試みているかを判定する。

ステップ５０４において、第１のＪａｖａ^TMアプレットのバイトコードが第２のＪａｖａ^TMアプレット内のオブジェクトにアクセスを試みていると判定された場合、方法５００は、ステップ５１０へ進み、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータを読み出す。これに応じて、ステップ５１２では、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第１の値（例えば、０ｘ８０）に等しいかを判定する。ステップ５１２において、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第１の値に等しいと判定された場合、方法５００は、ステップ５１４へ進み、制御ブロックのファイヤウォール保護を迂回できる（例えば、パッケージ境界に基づいて、ファイヤウォール保護を提供できる）。方法５００は、ステップ５１４の後で終了する。しかしながら、ステップ５１２において、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第１の値に等しくないと判定された場合、方法５００は、ステップ５１６へ進み、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第２の値に等しいかを判定する。第２の値は、第１および第２のＪａｖａ^TMアプレットのＰＩＸ値（例えば、図３Ｅ参照）が一致するか比較するべきであることを示唆できる。したがって、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第２の値に等しい場合、ステップ５１８において、第１および第２のアプレットのＰＩＸ値を比較できる。その後、方法５００は、ステップ５２０へ進み、これらの値が一致するかを判定する。これらの値が一致しない場合、方法５００は、ステップ５２２へ進み、アクセスが拒否される。加えて、ステップ５２４において、エラーを出力できる（例えば、「Ｊａｖａ．ｌａｎｇ．ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ」をスローできる）。方法５００は、ステップ５２４の後で終了する。

一方、ステップ５２０において、一致すると判定された場合、方法５００は、ステップ５２６へ進み、第１のＪａｖａ^TMアプレットは、第２のＪａｖａ^TMアプレットへのアクセスを許可される。理解されるように、このアクセスは、共有可能なインタフェースを実装する必要なく提供できる。一実施形態において、呼び出し可能なメソッドによって、第２のアプレットに対する参照が提供される。このメソッドは、例えば、Ｊａｖａ^TMカード管理（またはシステム）環境の一部として実装された比較的単純な参照取得メソッドにできる（例えば、ｇｅｔＡｐｐｌｅｔＲｅｆｅｒｅｎｃｅ（）メソッド）。当業者が理解するように、この参照取得メソッドに対して、パートナーメソッドを提供することもできる。このパートナーメソッドは、例えば、Ｊａｖａ^TMアプレットクラスとして実装されるメソッドにできる。

図５を再び参照すると、ステップ５１６において、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第２の値に等しくないと判定された場合、方法５００は、ステップ５２８へ進み、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第３の値に等しいかを判定する。そうである場合、方法５００は、ステップ５３０へ進み、第１および第２のアプレットのＡＩＤ（例えば、図３Ｅ参照）値を比較する。その後、方法５００は、上記と同様の形でステップ５２０へ進む。

しかしながら、ステップ５２８において、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第３の値に等しくないと判定された場合、方法５００は、ステップ５３２へ進み、第４の値に等しいかを判定する。第４の値は、Ｊａｖａ Ｃａｒｄ^TM管理のみに対してアクセスが確保されることを示めすことができる。したがって、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第４の値に等しい場合、方法５００は、ステップ５３４へ進み、Ｊａｖａ Ｃａｒｄ^TM管理コンテキストの下で、バイトコードが実行されているかを判定する（例えば、コンテキストＩＤがＪａｖａ Ｃａｒｄ^TM管理のものかを判定する）。この判定に応じて、方法５００は、上記と同様に、アクセスが拒否されるステップ５２２か、あるいはアクセスが許可されるステップ５２６へ進む。

最後に、ステップ５３２において、第２のＪａｖａ^TMアプレットのファイヤウォール制御インジケータが第４の値に等しくないと判定された場合、方法５００は、ステップ５３６へ進み、ファイヤウォール制御インジケータが解釈される。一例として、ファイヤウォール制御インジケータは、図４に例示したものと同様の形で解釈可能であり、第１および第２のアプレットにそれぞれ割り当てられたファイヤウォール制御値の１バイト以上を、ファイヤウォール制御インジケータの値に基づいて比較する。いずれの場合も、解釈に基づいて、ステップ５３８で、適切な制御値を決定し、一致するかを比較できる。したがって、方法５００は、ステップ５２０へ進み、値が一致するかを判定する。方法５００は、上記と同様な形で進み、ステップ５２６においてアクセスを許可し、あるいはステップ５２２において拒否する。方法５００は、エラーが出力されるステップ５２４、あるいは第１のＪａｖａ^TMアプレットが第２のＪａｖａ^TMアプレットへのアクセスを許可されるステップ５２６の何れかに続いて終了する。

本発明の多くの特徴および利点について、記載の説明から明らかであり、したがって、付記した請求項は、こうした本発明の全ての特徴および利点を網羅するものである。さらに、多数の変形例および変更例が当業者によって容易に発案されるため、本発明を例示および説明された厳密な構成および動作に限定することは望ましくない。したがって、全ての適切な変形例および等価物は、本発明の範囲に含まれるものとして分類し得る。

携帯コンピューティング機器を表す図である。 携帯コンピューティング機器を表す図である。 携帯コンピューティング機器を表す図である。 携帯コンピューティング機器を表す図である。 本発明の一実施形態による、例示的なコンピューティング環境を示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、ファイヤウォール制御ブロックを示す図である。 Ｊａｖａアプレットとして実装可能な簡略化ファイヤウォール制御ブロックを示す図である。 本発明の一実施形態による、Ｊａｖａ^TMカード環境において、ファイヤウォールを提供する方法を例示する図である。

Claims (9)

1. コンピューティングシステムであって、
   オペレーティングシステムと、
   前記オペレーティングシステム上で動作するバーチャルマシンと、
   前記バーチャルマシン上で動作する第１のアプリケーションと、
   前記バーチャルマシン上で動作する第２のアプリケーションと、
   前記第１のアプリケーションのための第１のファイヤウォール制御ブロックと、
   前記第２のアプリケーションのための第２のファイヤウォール制御ブロックと、
   を備え、
   前記第１のファイヤウォール制御ブロックは、複数の第１のファイヤウォール制御値と、第１のファイヤウォール制御インジケータとを含み、前記第１のファイヤウォール制御インジケータは、前記複数の第１のファイヤウォール制御値のうちで前記第１のアプリケーションへのアクセス制御に使用されるファイヤウォール制御値の第１の個数を示し、
   前記第２のファイヤウォール制御ブロックは、複数の第２のファイヤウォール制御値と、第２のファイヤウォール制御インジケータとを含み、前記第２のファイヤウォール制御インジケータは、前記複数の第２のファイヤウォール制御値のうちで前記第２のアプリケーションへのアクセス制御に使用されるファイヤウォール制御値の第２の個数を示し、
   前記第２のファイヤウォール制御ブロックは、前記複数の第１のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列が、前記複数の第２のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列と同一の場合にのみ、前記第１のアプリケーションに対して前記第２のアプリケーションへのアクセスを許可する、
   コンピューティングシステム。
2. 請求項１に記載のコンピューティングシステムであって、
   前記コンピューティングシステムは、Ｊａｖａ（登録商標）カード対応コンピューティングシステムであり、
   前記第１のファイヤウォール制御ブロックは、ランタイムシステムとして実装される、
   コンピューティングシステム。
3. 携帯コンピューティング機器であって、
   オペレーティングシステムと、
   前記オペレーティングシステム上で動作するＪａｖａ（登録商標）対応バーチャルマシンと、
   前記Ｊａｖａ（登録商標）対応バーチャルマシン上で動作する第１のＪａｖａ（登録商標）対応アプレットと、
   前記Ｊａｖａ（登録商標）対応バーチャルマシン上で動作する第２のＪａｖａ（登録商標）対応アプレットと、
   前記第１のＪａｖａ（登録商標）対応アプレットのための第１のファイヤウォール制御ブロックと、
   前記第２のＪａｖａ（登録商標）対応アプレットのための第２のファイヤウォール制御ブロックと、
   を備え、
   前記第１のファイヤウォール制御ブロックは、複数の第１のファイヤウォール制御値と、第１のファイヤウォール制御インジケータとを含み、前記第１のファイヤウォール制御インジケータは、前記複数の第１のファイヤウォール制御値のうちで前記第１のＪａｖａ（登録商標）対応アプレットへのアクセス制御に使用されるファイヤウォール制御値の第１の個数を示し、
   前記第２のファイヤウォール制御ブロックは、複数の第２のファイヤウォール制御値と、第２のファイヤウォール制御インジケータとを含み、前記第２のファイヤウォール制御インジケータは、前記複数の第２のファイヤウォール制御値のうちで前記第２のＪａｖａ（登録商標）対応アプレットへのアクセス制御に使用されるファイヤウォール制御値の第２の個数を示し、
   前記第２のファイヤウォール制御ブロックは、前記複数の第１のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列が、前記複数の第２のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列と同一の場合にのみ、前記第１のＪａｖａ（登録商標）対応アプレットに対して前記第２のＪａｖａ（登録商標）対応アプレットへのアクセスを許可する、
   携帯コンピューティング機器。
4. 請求項３記載の携帯コンピューティング機器であって、
   前記携帯機器は、Ｊａｖａ（登録商標）対応スマートカードである、
   携帯コンピューティング機器。
5. 請求項４に記載の携帯コンピューティング機器であって、
   ファイヤウォール制御ブロックは、Ｊａｖａ（登録商標）対応アプレット毎に定義される、携帯コンピューティング機器。
6. Ｊａｖａ（登録商標）バーチャルマシンと、前記Ｊａｖａ（登録商標）バーチャルマシン上で動作する複数のＪａｖａ（登録商標）対応アプレットとを含むＪａｖａ（登録商標）対応コンピューティングシステムにセキュリティを提供する方法であって、
   前記Ｊａｖａ（登録商標）バーチャルマシンが、前記Ｊａｖａ（登録商標）バーチャルマシン上で動作する第１のＪａｖａ（登録商標）対応アプレットから、第２のＪａｖａ（登録商標）対応アプレットにアクセスするための要求を受領する工程と、
   前記Ｊａｖａ（登録商標）バーチャルマシンが、前記第１のＪａｖａ（登録商標）対応アプレットに関連する第１のファイヤウォール制御ブロックと、前記第２のＪａｖａ（登録商標）対応アプレットに関連する第２のファイヤウォール制御ブロックを読み出す工程と、
   前記Ｊａｖａ（登録商標）バーチャルマシンが、前記第１と第２のファイヤウォール制御ブロックに基づいて、前記第１のＪａｖａ（登録商標）対応アプレットが前記第２のＪａｖａ（登録商標）対応アプレットにアクセスするのを許可するべきかを判定する工程と、
   前記Ｊａｖａ（登録商標）バーチャルマシンが、前記判定する工程によりアクセスを許可するべきであると判定された場合、前記第１のＪａｖａ（登録商標）対応アプレットが前記第２のＪａｖａ（登録商標）対応アプレットにアクセスするのを許可する工程と、
   を備え、
   前記第１のファイヤウォール制御ブロックは、複数の第１のファイヤウォール制御値と、第１のファイヤウォール制御インジケータとを含み、前記第１のファイヤウォール制御インジケータは、前記複数の第１のファイヤウォール制御値のうちで前記第１のＪａｖａ（登録商標）対応アプレットへのアクセス制御に使用されるファイヤウォール制御値の第１の個数を示し、
   前記第２のファイヤウォール制御ブロックは、複数の第２のファイヤウォール制御値と、第２のファイヤウォール制御インジケータとを含み、前記第２のファイヤウォール制御インジケータは、前記複数の第２のファイヤウォール制御値のうちで前記第２のＪａｖａ（登録商標）対応アプレットへのアクセス制御に使用されるファイヤウォール制御値の第２の個数を示し、
   前記Ｊａｖａ（登録商標）バーチャルマシンは、前記複数の第１のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列が、前記複数の第２のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列と同一の場合にのみ、前記第１のＪａｖａ（登録商標）対応アプレットに対して前記第２のＪａｖａ（登録商標）対応アプレットへのアクセスを許可する、
   方法。
7. 請求項６記載の方法であって、さらに、
   前記判定する工程によりアクセスを許可するべきであると判定された場合、前記Ｊａｖａ（登録商標）バーチャルマシンが、前記第１のＪａｖａ（登録商標）対応アプレットに、前記第２のＪａｖａ（登録商標）対応アプレットに対する参照を提供する工程を備える方法。
8. 請求項６に記載の方法であって、
   前記参照を提供する工程は、
   前記Ｊａｖａ（登録商標）バーチャルマシンが、前記Ｊａｖａ（登録商標）対応コンピューティングシステムの一部として実装される第１のメソッドを呼び出す工程と、
   前記Ｊａｖａ（登録商標）バーチャルマシンが、前記第１のメソッドを呼び出した結果として、アプレットクラスとして実装された第２のメソッドを呼び出す工程と、
   を備える方法。
9. コンピューティングシステムにセキュリティを提供するためのコンピュータプログラムコードを含むコンピュータ読み取り可能な記憶媒体であり、
   第１のアプリケーションから、第２のアプリケーションにアクセスするための要求を受領するためのコンピュータプログラムコードと、
   前記第１のアプリケーションに関連する第１のファイヤウォール制御ブロックと、前記第２のアプリケーションに関連する第２のファイヤウォール制御ブロックを読み出すためのコンピュータプログラムコードと、
   前記第１と第２のファイヤウォール制御ブロックに基づいて、前記第１のアプリケーションが前記第２のアプリケーションにアクセスするのを許可するべきかを判定するコンピュータプログラムコードと、
   前記判定するステップによりアクセスを許可するべきであると判定された場合、前記第１のアプリケーションが前記第２のアプリケーションにアクセスするのを許可するコンピュータプログラムコードと、
   を前記コンピューティングシステムに実行させるコンピュータ読み取り可能な記憶媒体であり、
   前記第１のファイヤウォール制御ブロックは、複数の第１のファイヤウォール制御値と、第１のファイヤウォール制御インジケータとを含み、前記第１のファイヤウォール制御インジケータは、前記複数の第１のファイヤウォール制御値のうちで前記第１のアプリケーションへのアクセス制御に使用されるファイヤウォール制御値の第１の個数を示し、
   前記第２のファイヤウォール制御ブロックは、複数の第２のファイヤウォール制御値と、第２のファイヤウォール制御インジケータとを含み、前記第２のファイヤウォール制御インジケータは、前記複数の第２のファイヤウォール制御値のうちで前記第２のアプリケーションへのアクセス制御に使用されるファイヤウォール制御値の第２の個数を示し、
   前記第２のファイヤウォール制御ブロックは、前記複数の第１のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列が、前記複数の第２のファイヤウォール制御値のうちの前記第２の個数のファイヤウォール制御値の配列と同一の場合にのみ、前記第１のアプリケーションに対して前記第２のアプリケーションへのアクセスを許可する、
   コンピュータ読み取り可能な記憶媒体。

Images