コンフィギュラブルファイヤウォールを利用するシステム、方法、携帯コンピューティング機器、及びコンピュータ読み取り可能な媒体
【課題】コンピューティング環境の様々な構成要素間でのアクセス権を実装および制御する機構として使用可能なコンフィギュラブルファイヤウォールを提供する。
【解決手段】ファイヤウォール制御ブロックは、コンピューティング環境２００において、ある構成要素（例えば、アプレット）が別の構成要素にアクセス可能かを判定し、各アプレットが所定の他のアプレットセットに対するアクセスを許可できるような形でファイヤウォール境界２４０を構成する。ファイヤウォール制御ブロックは、異なるシステム要件（例えば、処理速度、メモリ）に対して実装できるため、相対的に限定された処理能力での動作、および／または高度に特化した機能性の提供を行うコンピューティングシステム（例えば、スマートカード）に対してコンフィギュラブルファイヤウォールを実装できる。
【解決手段】ファイヤウォール制御ブロックは、コンピューティング環境２００において、ある構成要素（例えば、アプレット）が別の構成要素にアクセス可能かを判定し、各アプレットが所定の他のアプレットセットに対するアクセスを許可できるような形でファイヤウォール境界２４０を構成する。ファイヤウォール制御ブロックは、異なるシステム要件（例えば、処理速度、メモリ）に対して実装できるため、相対的に限定された処理能力での動作、および／または高度に特化した機能性の提供を行うコンピューティングシステム（例えば、スマートカード）に対してコンフィギュラブルファイヤウォールを実装できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティングシステムに関し、特に、安全なコンピューティングシステムを提供する手法に関する。
【背景技術】
【０００２】
通常のデスクトップと異なり、他のコンピューティング機器は携帯型であり、特定の用途に高度に特化しており、相対的に少ないメモリ、および／または処理制約と共に動作する。一例として、スマートカードは、特定の用途（例えば、セキュリティ）に高度に特化可能な携帯コンピューティング機器を代表するものである。スマートカードは、提供可能なメモリ量および処理能力が一般にデスクトップ（例えば、パーソナルコンピュータ）環境のものほど多くないコンピューティング環境の例でもある。そのため、スマートカードは、好例となり得るものであり、以下に説明する。
【０００３】
スマートカードは、重要情報を格納するために使用されるメモリカード（例えば、フォンカード）の形態で約２０年前に導入された。しかしながら、現在のスマートカードは、最初に導入されたものに比べ、遙かに高度化している。現在、スマートカードは、埋め込み集積回路（ＩＣ）を有することができる。スマートカードは、例えば、埋め込み集積回路（ＩＣ）を含むプラスチックカードである。スマートカードは、クレジットカードのようにすることができる。さらに、機密性の高い用途（例えば、バンキング、セキュリティ）にも使用できる。その結果として、安全なスマートカードを開発するために、多数の団体が広範な活動を行っている。
【０００４】
スマートカードは、国際標準化機構（ＩＳＯ）および国際電気標準会議（ＩＥＣ）の第１合同技術委員会（ＪＴＣ１）により定義および管理されている業界標準である。１９８７年に導入され、２００３年に最新の更新が行われた一連の国際規格ＩＳＯ／ＩＥＣ７８１６では、スマートカードの様々な態様を定義しており、これには物理的特徴、物理的接触、電子信号および伝送プロトコル、コマンド、セキュリティアーキテクチャ、アプリケーション識別子、共通データ要素が含まれる。
【０００５】
一部の使用領域において、スマートカードは、単に保護された不揮発性ストレージを提供するメモリカードに過ぎない。しかしながら、さらに進んだスマートカードは、マイクロプロセッサとメモリとの両方を有し、安全な処理およびストレージのために使用できる。スマートカードは、電池なしで動作できる（即ち、カードリーダに接続された時のみアクティブとなる）。接続時、リセットシーケンスの後、カードは、受動状態を維持し、クライアント（ホスト）アプリケーションからのコマンド要求受領のため待機する。名称が示すとおり、接触スマートカードは、カードリーダとスマートカードの８ピン接点との間の物理的接触を介して通信することで機能し、一方、非接触スマートカードは、通常２フィート未満の範囲で高周波信号を用いて通信する。非接触スマートカードの無線通信は、盗難防止および在庫追跡のために店舗で使用される高周波ＩＤ（ＲＦＩＤ）タグに類似する技術に基づいている。図１は、接触および非接触スマートカードを表している。図１Ａおよび１Ｂは、それぞれ、接触および非接触スマートカードを表している。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
現在の携帯機器の普及を考慮すると、より携帯機器に適したプログラミング環境を開発することが望ましい。こうしたプログラミング環境は、何よりも、安全であるべきである。
【０００７】
上述のように、携帯機器の普及を考慮すると、より携帯機器に適したプログラミング環境を開発することが望ましい。こうしたプログラミング環境は、通常、相対的に限定されたリソース（処理能力および／またはメモリ）での動作、および／または、高度に特化した機能の提供を行う。
【０００８】
プラットフォーム非依存プログラミング環境として、特にＪａｖａ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は、分散環境（例えば、インターネット）での使用に適したプログラミング言語である。Ｃ＋＋言語の「見た目(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技術は、こうした環境に適している。Ｊａｖａ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は、分散環境（例えば、インターネット）での使用に適したプログラミング言語である。Ｃ＋＋言語の「見た目(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対応コンピューティング環境であり、
前記第１および第２のアプリケーションは、Ｊａｖａ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対応アプレットに関連する第２のＡＩＤを読み出すためのコンピュータプログラムコードと、
前記第１のＡＩＤが前記第２のＡＩＤに一致するかを判定するためのコンピュータプログラムコードと、
前記判定により前記第１のＡＩＤが前記第２のＡＩＤに一致すると判定された場合のみ、アクセスを許可するためのコンピュータプログラムコードと、
を備えるコンピュータ読み取り可能な媒体。
【図１Ａ】
【図１Ｂ】
【図１Ｃ】
【図１Ｄ】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図３Ｄ】
【図３Ｅ】
【図３Ｆ】
【図３Ｇ】
【図３Ｈ】
【図４】
【図５】
【図１Ｂ】
【図１Ｃ】
【図１Ｄ】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図３Ｄ】
【図３Ｅ】
【図３Ｆ】
【図３Ｇ】
【図３Ｈ】
【図４】
【図５】
【公開番号】特開２０１１−１５０７０９（Ｐ２０１１−１５０７０９Ａ）
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願番号】特願２０１１−３７０００（Ｐ２０１１−３７０００）
【出願日】平成２３年２月２３日（２０１１．２．２３）
【分割の表示】特願２００６−５４７０７８（Ｐ２００６−５４７０７８）の分割
【原出願日】平成１６年１２月９日（２００４．１２．９）
【出願人】（５９７００４７２０）オラクル・アメリカ・インコーポレイテッド (23)
【Ｆターム（参考）】
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願日】平成２３年２月２３日（２０１１．２．２３）
【分割の表示】特願２００６−５４７０７８（Ｐ２００６−５４７０７８）の分割
【原出願日】平成１６年１２月９日（２００４．１２．９）
【出願人】（５９７００４７２０）オラクル・アメリカ・インコーポレイテッド (23)
【Ｆターム（参考）】
[ Back to top ]