(57)【要約】無線通信システム用の移動体端末のあるいは別の製品のプラットフォームへのアクセスを制御するための方法及びシステム。該システムは、ソフトウエア・サービス・コンポーネントとインタフェース・コンポーネントとを有しているプラットフォームを含んでおり、インタフェース・コンポーネントは、ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、プラットフォーム内で、インストールされ、ロードされ及び実行されるのを可能とする。アクセス・コントローラは、少なくとも１つのインタフェースを介した、アプリケーション・ドメイン・ソフトウエアによるソフトウエア・サービス・コンポーネントへのアクセスを制御する。該アクセス・コントローラは、ソフトウエア・サービス・コンポーネントへアクセスするためのアプリケーション・ドメイン・ソフトウエアからの要求を受信するインターセプション・モジュールと、その要求を許可すべきかどうかを決定するセキュリティ・アクセス・マネージャとを含んでいる。セキュリティ・アクセス・マネージャによって許可要求が許された場合、アプリケーション・ドメイン・ソフトウエアは、少なくとも１つのインタフェースを介したソフトウエア・サービス・コンポーネントへのアクセスを許可される。【特許請求の範囲】
【請求項１】
プラットフォームへのアクセスを制御するためのシステムであって、
ソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、前記プラットフォーム内において、インストールされ、ロードされ及び実行されるのを可能とするインタフェース・コンポーネントとを有するプラットフォームと、
前記少なくとも１つのインタフェースを介した、要求しているアプリケーション・ドメイン・ソフトウエアによる前記ソフトウエア・サービス・コンポーネントへのアクセスを制御するアクセス・コントローラとを備え、該アクセス・コントローラが、
前記要求しているアプリケーション・ドメイン・ソフトウエアからの前記ソフトウエア・サービス・コンポーネントへのアクセスの要求を受信するインターセプション・モジュールと、
前記要求を許可すべきかどうかを決定する判定エンティティと、を備え、
前記要求が許可された場合、前記要求しているアプリケーション・ドメイン・ソフトウエアは、前記少なくとも１つのインタフェースを介した、前記ソフトウエア・サービス・コンポーネントへのアクセスが許されることを特徴とするシステム。
【請求項２】
前記判定エンティティはセキュリティ・アクセス・マネージャであり、該セキュリティ・アクセス・マネージャはアクセス及び許可の方針を有していることを特徴とする請求項１に記載のシステム。
【請求項３】
前記要求が、前記要求しているアプリケーション・ドメイン・ソフトウエアの識別情報を含み、
前記セキュリティ・アクセス・マネージャが、前記識別情報に基づいて、前記要求を前記要求しているアプリケーション・ドメイン・ソフトウエアに許可すべきかどうかを決定するのに用いる、要求が認可されたアプリケーション・ドメイン・ソフトウエアの記録の収集物を含むことを特徴とする請求項２に記載のシステム。
【請求項４】
前記記録の収集物がアクセス制御の収集物を備え、
前記セキュリティ・アクセス・マネージャが関連した許可情報の収集物を含み、
前記関連した許可情報の収集物が、前記アクセス制御の収集物に含まれる要求しているアプリケーション・ドメイン・ソフトウエアについて、前記要求を許可すべきかどうかの決定に使用されることを特徴とする請求項３に記載のシステム。
【請求項５】
前記セキュリティ・アクセス・マネージャが、前記要求しているアプリケーション・ドメイン・ソフトウエアに以前許可判定が与えられたかどうかを求めるために、アプリケーション・ドメイン・ソフトウエアによる要求の記録を保守する、判定キャッシュを含むことを特徴とする請求項２に記載のシステム。
【請求項６】
前記セキュリティ・アクセス・マネージャは、要求しているアプリケーション・ドメイン・ソフトウエアの記録を有し、
前記セキュリティ・アクセス・マネージャが、前記記録に格納された識別情報に基づいて、前記要求を許可すべきかどうかを決定することを特徴とする請求項２に記載のシステム。
【請求項７】
前記要求が否認された場合、前記インターセプション・モジュールによって前記要求しているアプリケーション・ドメイン・ソフトウエアに拒否メッセージが送信されることを特徴とする請求項２に記載のシステム。
【請求項８】
前記アプリケーション・ドメイン・ソフトウエアが、非ネイティブ・アプリケーション・ドメイン・ソフトウエアを含むことを特徴とする請求項２に記載のシステム。
【請求項９】
前記非ネイティブ・アプリケーション・ドメイン・ソフトウエアが、Java（登録商標）アプリケーション・ソフトウエアを含むことを特徴とする請求項８に記載のシステム。
【請求項１０】
前記アプリケーション・ドメイン・ソフトウエアが、ネイティブ・アプリケーション・ソフトウエアを含むことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記インタフェース・コンポーネントが、ミドルウエア・サービス・レイヤを含むことを特徴とする請求項１に記載のシステム。
【請求項１２】
前記プラットフォームが、無線通信システム用の移動体端末のプラットフォームを含むことを特徴とする請求項２に記載のシステム。
【請求項１３】
前記判定エンティティが、前記インターセプション・モジュールであることを特徴とする請求項１に記載のシステム。
【請求項１４】
前記要求が、前記要求しているアプリケーション・ドメイン・ソフトウエアの識別情報を含み、
前記インターセプション・モジュールが、前記識別情報に基づいて、前記要求を前記要求しているアプリケーション・ドメイン・ソフトウエアに許可すべきかどうかを決定するのに用いる、要求が認可されたアプリケーション・ドメイン・ソフトウエアの記録の収集物を含むことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記インターセプション・モジュールが、前記要求しているアプリケーション・ドメイン・ソフトウエアに以前許可判定が与えられたかどうかを求めるために、ネイティブ・プラットフォーム・サービスによるアプリケーション・ソフトウエアの識別情報の記録を保守する、判定キャッシュを含むことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記インターセプション・モジュールが、前記プラットフォームの各プラットフォーム・サービスについての記録を有し、
前記インターセプション・モジュールが、前記記録に格納された識別情報に基づいて、前記要求を許可すべきかどうかを決定することを特徴とする請求項１３に記載のシステム。
【請求項１７】
前記アプリケーション・ドメイン・ソフトウエアが、非ネイティブ・アプリケーション・ソフトウエアを含むことを特徴とする請求項１３に記載のシステム。
【請求項１８】
前記アプリケーション・ドメイン・ソフトウエアが、ネイティブ・アプリケーション・ソフトウエアを含むことを特徴とする請求項１３に記載のシステム。
【請求項１９】
システム・アクセス・モジュールを更に備え、
該システム・アクセス・モジュールが、前記インターセプション・モジュールによって前記要求を許可するか否認するかの判定に使用される情報で、前記インターセプション・モジュールを更新するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項２０】
前記システム・アクセス・モジュールによる更新が周期的に行われることを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記システム・アクセス・モジュールによる更新が更新要求に応じて行われることを特徴とする請求項１９に記載のシステム。
【請求項２２】
ソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、プラットフォーム内において、インストールされ、ロードされ及び実行されるのを可能とするインタフェース・コンポーネントとを有する、プラットフォームへのアクセスを制御する方法であって、
要求しているアプリケーション・ドメイン・ソフトウエアからの前記ソフトウエア・サービス・コンポーネントへのアクセスの要求を受信するステップと、
前記要求を許可すべきかどうかを判定するステップと、
前記要求が許可された場合、前記少なくとも１つのインタフェースを介した、要求されたソフトウエア・サービス・コンポーネントへのアクセスを許可するステップと、を備えることを特徴とする方法。
【請求項２３】
前記要求が、前記要求しているアプリケーション・ドメイン・ソフトウエアの識別情報を含み、
前記要求を許可すべきかどうかを判定するステップで、要求する可能性のあるアプリケーション・ドメイン・ソフトウエアの収集物が使用されることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記収集物が、アクセス制御の収集物を備え、
前記判定するステップが、前記アクセス制御の収集物にアクセスするステップを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記判定するステップが、前記要求しているアプリケーション・ドメイン・ソフトウエアに以前判定が与えられたかどうかを求めるステップを含むことを特徴とする請求項２２に記載の方法。
【請求項２６】
前記プラットフォームの各プラットフォーム・サービスについての記録が格納され、
前記判定するステップが、前記記録に格納された識別情報に基づいて、前記要求しているアプリケーション・ドメイン・ソフトウエアに前記要求を許可すべきかどうかを判定するステップを含むことを特徴とする請求項２２に記載の方法。
【請求項２７】
前記要求が否認された場合、前記要求しているアプリケーション・ドメイン・ソフトウエアに拒否メッセージを送信することを特徴とする請求項２２に記載の方法。
【請求項２８】
前記アプリケーション・ドメイン・ソフトウエアが、非ネイティブ・アプリケーション・ドメイン・ソフトウエアを含むことを特徴とする請求項２２に記載の方法。
【請求項２９】
前記非ネイティブ・アプリケーション・ドメイン・ソフトウエアが、Java（登録商標）アプリケーション・ソフトウエアを含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記アプリケーション・ドメイン・ソフトウエアが、ネイティブ・アプリケーション・ソフトウエアを含むことを特徴とする請求項２２に記載の方法。
【請求項３１】
前記プラットフォームが、無線通信システム用の移動体端末のプラットフォームを含むことを特徴とする請求項２２に記載の方法。
【請求項３２】
前記要求を許可するか否認するかの判定に使用される情報を更新するステップを更に備えることを特徴とする請求項２２に記載の方法。
【請求項３３】
前記更新するステップが周期的に繰り返されることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記更新するステップが更新要求に応じて行われることを特徴とする請求項３２に記載の方法。
【請求項３５】
無線通信システム用の移動体端末のプラットフォームへのアクセスを制御するためのシステムであって、
ソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、非ネイティブ・アプリケーション・ソフトウエアが、前記プラットフォームで、インストールされ、ロードされ及び実行されるのを可能とするインタフェース・コンポーネントとを有するプラットフォームと、
前記非ネイティブ・アプリケーション・ソフトウエアによる前記ソフトウエア・サービス・コンポーネントへのアクセスを制御するアクセス・コントローラとを備え、該アクセス・コントローラが、
前記非ネイティブ・アプリケーション・ソフトウエアからの前記ソフトウエア・サービス・コンポーネントへのアクセスの要求を受信するインターセプション・モジュールと、
前記要求を許可すべきかどうかを決定する判定エンティティと、を備え、
前記要求が許可された場合、前記非ネイティブ・アプリケーション・ソフトウエアは、前記少なくとも１つのインタフェースを介した、前記ソフトウエア・サービス・コンポーネントへのアクセスが許されることを特徴とするシステム。
【請求項３６】
前記判定エンティティはインターセプション・モジュールであることを特徴とする請求項３５に記載のシステム。
【請求項３７】
前記判定エンティティはセキュリティ・アクセス・マネージャであることを特徴とする請求項３５に記載のシステム。
【請求項３８】
前記少なくとも１つのインタフェースが、ミドルウエア・サービス・レイヤを含むことを特徴とする請求項３５に記載のシステム。
【請求項３９】
前記非ネイティブ・アプリケーション・ソフトウエアが、Java（登録商標）アプリケーション・ソフトウエアを含むことを特徴とする請求項３５に記載のシステム。
【請求項４０】
ネイティブ・アプリケーション・ソフトウエアが、前記プラットフォームにロードされ、インストールされ、実行され得ることを特徴とする請求項３５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して無線通信に関し、より詳細には、無線通信システム用の移動体端末のプラットフォームへのアクセスを制御するための方法及びシステムに関する。
【背景技術】
【０００２】
１９８０年代にセルラ通信システムが最初に導入されてから、システムで使用される移動体端末（移動局）はますます複雑になってきている。最初は、移動体端末は主に音声の電話サービスを提供するため、すなわち、音声通信の受信及び送信のために設計された。後年、音声の電話呼のユーザデータには関連のないユーザデータを転送する能力も備えた移動体端末が開発された。そのようなユーザデータは、例えば、パーソナルコンピュータ（ＰＣ）を介して開始されたダイヤルアップ・ネットワーク接続によって転送されるべきデータを含んでいる。
【０００３】
現在、将来の移動通信システムのために、いわゆる「第３世代」（３Ｇ）システムが開発されている。３Ｇシステムは、高速インターネット・アクセスを従来の音声通信と組み合せ、音声通信に加えて、インターネットのブラウジング、音声／動画のストリーミング、位置決め、ビデオ会議及び他の多くの可能性への手段をユーザに提供するであろう。
【０００４】
第３世代のパートナーシップ・プロジェクト（３ＧＰＰ）は、世界中で開発されているいくつかの３Ｇシステム間の互換性を保証するために設立された。音声、データ及びマルチメディアを世界のあらゆるところに配信できる地上及び衛星システムを含む３Ｇシステムを提供するために、世界規模の移動体通信サービス（ＵＭＴＳ）が３ＧＰＰにより開発されている。
【０００５】
３ＧＰＰの標準化によってセルラ通信システムに含まれている機能は急激に増加し、システムで使用される端末の開発者に実質的な要求として課せられている。この要求は、移動体端末がサイズ、メモリ及びパワーが制限された「資源の乏しい」環境であるという事実により一層困難なものとなっている。
【０００６】
従来より、移動体端末の製造者は、彼等の市場の要求の認識に基づいて、端末の基本的動作に必要な全てのハードウエア及びソフトウエア、並びに製造者又は特定のユーザが望む機能及び能力を提供するのに必要なハードウエア及びソフトウエアを含む、実質的に完成した移動体端末システムを、設計し、製造し、市場に出してきた。そのような手法は、市場の要求の急速な変化に素早く適応する柔軟性、あるいは多数のユーザの多様な要求を満たす柔軟性を提供することはできない。
【０００７】
移動体端末の設計及び製造の従来の手順が不十分であることを認識して、複数のユーザにユニットとして販売され得るソフトウエアとハードウエアの機能補完ユニットを複数含む、移動体端末プラットフォーム・アセンブリが開発された。そして各ユーザは、ユーザ自身の特定の要求に合った移動体端末用の完成されたプラットフォーム・システムを得るために、アセンブリ内に彼自身のアプリケーション・ソフトウエアをロードし、インストールし、実行する。移動体端末プラットフォーム・アセンブリ及びプラットフォーム・システムは、本願と譲渡人が同じ米国特許出願第１０／３５９９１１号及び１０／３５９８３５号に詳細に記載されており、該出願を参照により本願明細書に組み込む。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
移動体端末プラットフォーム・アセンブリのソフトウエアとアプリケーション・ソフトウエアが別個に開発され、アプリケーション・ソフトウエアを移動体端末プラットフォーム・アセンブリ内にロードし、インストールし、実行することで後で組み合わされる、上記に記載したようなプラットフォーム・システムは、Java （登録商標）midlet のような、仮想マシン上で実行させるために非ネイティブ・アプリケーションを必要とする。仮想マシンは、例えば、不正なメモリアクセスが生じないことを保証する。しかしながら、そのような非ネイティブ・アプリケーションは、移動体端末プラットフォーム・アセンブリのネイティブ・コードによって提供される機能に依存している。例えば、プラットフォーム・ドメインあるいはアプリケーション・ドメインにおけるそのようなネイティブ機能に対する制限のないアクセスは、例えば、エンド・ユーザに通知なしにコストがかかるイベントを開始することによって、移動体端末の完全性（integrity）を危険にさらすかもしれない。
【０００９】
そこでは信頼できる範囲を決定するためにアプリケーションで発信元の証明情報が使用され、それにより非ネイティブ実行環境について、移動体端末プラットフォーム・アセンブリによるサービスのサブセットへのアクセス許可が入手可能となる。しかしながら、許された許可が移動体端末のエンド・ユーザによって実行時に変更されるかもしれないという事実によって、この状況は一層複雑になる。
【００１０】
従って、あらゆる時点（例えば実行時）における、許可の動的な登録並びに移動体端末プラットフォーム・アセンブリのネイティブ・コードへのアクセスの動的フィルタリングが、必要とされる。
【課題を解決するための手段】
【００１１】
プラットフォームへのアクセスを制御するためのシステムは、ソフトウエア・サービス・コンポーネントとインタフェース・コンポーネントとを含んでいる。インタフェース・コンポーネントは、ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、プラットフォーム内において、インストールされ、ロードされ及び実行されるのを可能とする。該システムはまた、少なくとも１つのインタフェースを介した、要求しているアプリケーション・ドメイン・ソフトウエアによるソフトウエア・サービス・コンポーネントへのアクセスを制御する、アクセス・コントローラを含んでいる。アクセス・コントローラは、ソフトウエア・サービス・コンポーネントへアクセスすることを要求しているアプリケーション・ドメイン・ソフトウエアからの要求を受信するインターセプション・モジュールと、その要求を許可すべきかどうかを決定する判定エンティティとを含んでいる。要求が許可された場合、要求しているアプリケーション・ドメイン・ソフトウエアは、少なくとも１つのインタフェースを介したソフトウエア・サービス・コンポーネントへのアクセスを許可される。
【００１２】
ソフトウエア・サービス・コンポーネント及びインタフェース・コンポーネントを有するプラットフォームへのアクセスを制御する方法は、ソフトウエア・サービスコンポーネントへアクセスすることを要求しているアプリケーション・ドメイン・ソフトウエアからの要求を受信することを含んでいる。インタフェース・コンポーネントは、ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、プラットフォーム上で、インストールされ、ロードされ及び実行されるのを可能とする。該方法はまた、要求を許可すべきかどうかを決定することと、要求が許可された場合、少なくとも１つのインタフェースを介して、要求されたソフトウエア・サービス・コンポーネントへのアクセスを許可することとを含んでいる。
【００１３】
無線通信システム用の移動体端末のプラットフォームへのアクセスを制御するためのシステムは、ソフトウエア・サービス・コンポーネントとインタフェース・コンポーネントとを有しているプラットフォームを含んでいる。インタフェース・コンポーネントは、ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、非ネイティブのアプリケーション・ソフトウエアが、プラットフォーム上で、インストールされ、ロードされ及び実行されるのを可能とする。該システムはまた、少なくとも１つのインタフェースを介した、非ネイティブのアプリケーション・ソフトウエアによるソフトウエア・サービス・コンポーネントへのアクセスを制御する、アクセス・コントローラを含んでいる。アクセス・コントローラは、ソフトウエア・サービス・コンポーネントへアクセスするための非ネイティブのアプリケーション・ソフトウエアからの要求を受信するインターセプション・モジュールと、その要求を許可すべきかどうかを決定する判定エンティティとを含んでいる。要求が許可された場合、非ネイティブのアプリケーション・ソフトウエアは、少なくとも１つのインタフェースを介したソフトウエア・サービス・コンポーネントへのアクセスを許可される。
【発明を実施するための最良の形態】
【００１４】
図１は、本発明の原理を説明するのに役立つ、無線通信システムの移動体端末用のプラットフォーム・システムの概略を示すブロック図である。全体を参照番号１０で示すプラットフォーム・システムは、移動体端末プラットフォーム・アセンブリ１２と、移動体端末プラットフォーム・アセンブリ内にロードされ、インストールされ、実行された１つ以上のアプリケーション（すなわち、アプリケーション・ソフトウエア）１４を含んでいる。プラットフォーム・システム１０は、全体を破線１６で示す移動体端末に組み込まれるように構成されている。
【００１５】
移動体端末プラットフォーム・アセンブリ１２は、ソフトウエア・サービス・コンポーネント２２、ハードウエア・コンポーネント２４及びインタフェース・コンポーネント２６を含んでいる。ソフトウエア・サービス・コンポーネント２２は、インタフェース・コンポーネント２６を介してユーザに提供されるサービスを供与する、複数のよく構成された機能的ソフトウエアユニットを含んでいる。図１に示した代表的なシステム１０では、複数のソフトウエアユニットは、複数の縦（垂直）方向の機能的スタック３０〜３８を備えている。ハードウエア・コンポーネント２４は、機能的ソフトウエア・スタック３０〜３８のそれぞれに関連しており、かつそれらによって制御されるハードウエア・ユニットを含んでいる。図１に示した代表的システム１０では、ハードウエア・ユニットは、ソフトウエア・スタック３０〜３８と関連する様々なハードウエア・ブロック４０〜４８である。
【００１６】
インタフェース・コンポーネント２６は、１つ以上のアプリケーション１４を移動体端末プラットフォーム・アセンブリ１２内にロードし、インストールし、実行するためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を少なくとも１つ含み、移動体端末プラットフォーム・アセンブリをそれを使用するアプリケーションから分離させ、かつアプリケーションに様々な他のサービスを提供する、ミドルウエア・サービス・レイヤを備えている。ミドルウエア・サービス・レイヤの特定の詳細事項は以下で説明する。
【００１７】
プラットフォーム・システム１０の移動体端末プラットフォーム・アセンブリ１２は、アプリケーション・ソフトウエア１４（本明細書で使用される“アプリケーション・ソフトウエア”という用語は、プラットフォーム・ソフトウエア・アセンブリに加え、ユーザ（例えば、製造者又はエンド・ユーザ）が利用できることを望む可能性がある機能を提供するあらゆるソフトウエアであってよい）から分離させ、完成されまとまったユニットとして、設計され、実現され、テストされる。従ってユーザは、彼等自身のアプリケーション・ソフトウエアを開発すること、そうでなければ取得することができ、プラットフォーム・システム１０を自分用に調整するために、後でそのソフトウエアを移動体端末プラットフォーム・アセンブリ１２に追加することができる。そのため移動体端末プラットフォーム・アセンブリ１２は、販売されるかそうでなければ複数の様々なユーザに譲渡され得、その各ユーザは、彼等自身のプラットフォーム・システムに対する特定の要件を満足させるべく、彼等自身のアプリケーション・ソフトウエアをアセンブリにロードし、インストールし、実行することによってプラットフォーム・システム１０を調整することができる。
【００１８】
図２は、本発明の原理を説明するのに更に役立つ、図１の移動体端末プラットフォーム・アセンブリ１２を展開した一例を概略的に示すブロック図である。図２に示されたように、移動体端末プラットフォーム・アセンブリ１２は、メインＣＰＵ５０内で実行されているソフトウエアによって制御される。メインＣＰＵ５０は、マイクロプロセッサ、マイクロプログラマブルプロセッサ、又はＤＳＰ（デジタル・シグナル・プロセッサ）のようなプロセッサを１つ以上含んでいてもよい。ソフトウエア・コンポーネント２２のソフトウエア・スタック３０〜３８のそれぞれは、各スタックに関連したハードウエア・ユニットを動作させるために、ハードウエア駆動ソフトウエア６０〜６８を含んでいる。移動体端末プラットフォーム・アセンブリ１２及びプラットフォーム・システム１０の更なる詳細事項は、上述の本願と譲渡人が同じ米国特許出願第１０／３５９８３５号に記載されている。移動体端末プラットフォーム・アセンブリ１２に組み込まれているソフトウエアは、好ましくはソフトウエアの構成が分かりやすくなるような方法で配置され、その結果、ソフトウエアの設計が一層容易となり、アップグレードあるいは修正が一層簡単になる。
【００１９】
図３は、本発明の原理を説明するのに更に役立つ、移動体端末プラットフォーム・アセンブリ１２のソフトウエア・アーキテクチャの概略を示すブロック図である。図３に示されているように、ソフトウエア・サービス・コンポーネント２２は、上記で説明したように、複数の縦の、機能的ソフトウエア・スタック３０〜３８に組織化されているのに加え、ミドルウエア・サービス・レイヤ２６のソフトウエアとソフトウエア・サービス・コンポーネント２２のソフトウエアとが共に、全体が参照番号７０で示される階層化アーキテクチャを画定するように複数の横（水平）のレイヤを画定するようにも配置されており、階層化アーキテクチャ７０において、高いレベルのサービス・レイヤから低いレベルのサービス・レイヤに降順でレイヤが配置されている。
【００２０】
このソフトウエア・アーキテクチャは、縦に区切られた複数のソフトウエア・レイヤを補完する横に区切られた複数の機能的ソフトウエア・ユニットを含む点で、ＩＳＯ／ＯＳＩ（ＩＳＯ開放型システム間相互接続）標準モデルと異なっている。横方向の区切りは、独立したモジュール型コンポーネントの生成に大きく寄与している。
【００２１】
階層化アーキテクチャの最も高いレベルのレイヤは、ミドルウエア・サービス・レイヤである。ソフトウエア・サービス・コンポーネント２２のレイヤは、アプリケーション・サービスを提供するアプリケーション・サーバ・レイヤ８０と、プラットフォームに特有のサービスをアプリケーションに提供するプラットフォーム・サービス・レイヤ８２と、セッション・プロトコル及びアプリケーション特有のプロトコルを提供するプラットフォーム・プロトコル・レイヤ８４と、音声アクセス／制御、データ通信転送プロトコル、メッセージ転送プロトコルなどを提供するトランスポート・レイヤ８６と、外部データＩＦアクセス、構造化記憶サービス及び他のローレベル・プラットフォーム・サポート・サービスを提供するデータ・アクセス・レイヤ８８と、論理ドライバ・レイヤ９０と、ハードウエアの依存性をまとめる物理ドライバ・レイヤ９２とを含んでいる。加えて、ソフトウエア・サービス・コンポーネント２２は、プラットフォーム・アセンブリによって要求される汎用的サービスを提供する、基本システムサービス・レイヤ９４を含んでいる。
【００２２】
下側の２つのレイヤ９０及び９２は、ソフトウエアとハードウエアとの間の依存性を分離させるハードウエア・アブストラクション・レイヤ（ＨＡＬ）を構成する。物理ドライバ・レイヤだけがハードウエアの詳細事項（例えば、ＡＳＩＣハードウエアのどのレジスタが割り当てられるか）と関連している。論理ドライバ・レイヤ９０は、ハードウエアについての論理マッピングを提供する。すなわち、このレイヤは、移動体端末プラットフォーム・アセンブリのハードウエア及びソフトウエアの部品間のブリッジを提供する。
【００２３】
ソフトウエア自体は、図３に明確に示された、モジュール１０２、１０４、１０６などの複数のソフトウエア・モジュールに組織化される。ソフトウエア・サービス・コンポーネント２２において、単一のモジュールは、１つの縦方向の機能的スタック内にだけあり、そのスタック内の１つの横方向レイヤにだけ存在し得る。各レイヤは１つから多数のモジュールを含んでいてもよく、特定のスタック内の特定のレイヤ内の全てのモジュールは、抽象化（abstraction）レベルが同じである。様々なモジュール間の通信は、ソフトウエアのモジュールからモジュールへのアクセスについての基本的規則のセットに従う、ソフトウエア・バックプレーン（ＳｗＢＰ）１１２によって達成される。これらの規則の概略は以下の通りである。
【００２４】
−ソフトウエア・モジュールは、自身のレイヤの下側をインタフェースする全てのレイヤの機能を呼び出してもよい。  
−シリアル化されたデータフローの方向についての制限は無い。それらはあらゆる方向に行ける。  
−ソフトウエア・モジュールは、モジュールが属するレイヤとは無関係に、自身のレイヤの上側をインタフェースする（ＳｗＢＰ  １１２において）レイヤの機能を呼び出すことは決してない。  
−ソフトウエア・モジュールは、同じ縦方向スタック内で自身のレイヤをインタフェースするレイヤの機能を呼び出してもよい。  
−ソフトウエア・モジュールは、別の縦方向スタック内の同じレイヤ内のソフトウエア・モジュールの機能を呼び出してもよい（この能力は、縦方向スタック内のレイヤの数を制限することを許可される）。
【００２５】
様々なモジュールとＳｗＢＰ  １１２内のインタフェースとの間には強い結合は無い。その結果、モジュール及び／又はインタフェースの実現を、インタフェースのクライアントに影響を与えることなく自由に変更できる。クライアントとは、例えば、アプリケーション、ユーティリティ、プラグイン、あるいは他のあらゆるプラットフォーム・サービスの使用者である。この強い結合が無いことで、プラットフォーム・アセンブリ内の他のモジュールに影響を与えずに、個々のモジュールの追加、削除又は変更が可能となるので、これは重要な能力である。
【００２６】
移動体端末プラットフォーム・アセンブリ内でのモジュール間の内部通信を可能とするＳｗＢＰソフトウエアの構造を含む、階層化アーキテクチャの更なる詳細事項は、上述の譲渡人が同じ米国特許出願第１０／３５９９１１号に記載されている。ミドルウエア・サービス・レイヤは、移動体端末プラットフォーム・アセンブリ１２と、プラットフォーム・アセンブリ内にロードされ、インストールされ、実行されるアプリケーション・ソフトウエアとの間に明確なインタフェースを提供し、加えて、移動体端末プラットフォーム・アセンブリ１２をまとまったものとし、該アセンブリ１２をミドルウエア・サービス・レイヤによってアプリケーションから分離させ、アプリケーション１４に様々な他のサービスを提供するよう働く。
【００２７】
図４Ａは、本発明の原理によるインタフェース・コンポーネント２６のミドルウエア・サービス・レイヤを詳細に示す論理ブロック図である。図４Ａに示されているように、ミドルウエア・サービス・レイヤは、非ネイティブ環境（例えば、Java（登録商標）実行（Java ExE）環境）ＡＰＩドメイン２０２、オープン・アプリケーション・フレームワーク（ＯＡＦ）ＡＰＩドメイン２０４、オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメイン２０６及びＵＩツールキットＡＰＩドメイン２０８を含む複数のＡＰＩドメインを備えている。
【００２８】
ミドルウエア・サービス・レイヤ内のＡＰＩ２０２〜２０８を通じて、移動体端末プラットフォーム・アセンブリ１２は、複数のアプリケーション環境をサポートする。図４Ａの代表的な実施形態では、ミドルウエア・サービス・レイヤは、ネイティブ・アプリケーション（すなわち、特定のプロセッサ及びその命令セットで動作するようにコンパイルされているアプリケーション）用と、非ネイティブ・アプリケーション（例えば、Java （登録商標）Ｊ２ＭＥ  ＣＬＤＣ／ＭＩＤＰ（Java 2 マイクロエディション接続制限された機器の構成／移動体情報機器プロファイル：Java 2 Micro Edition Connected Limited Device Configuration/Mobile Information Device Profile））用の環境をサポートする。各実行環境はそれ自体の特性を有し、以下に応じて定義される。
【００２９】
−アプリケーションが開発される方法（プログラミング言語のサポート、コンパイル及びリンク）。  
−アプリケーションが実行される方法（例えば、インタープリタあるいはネイティブ・コードの実行）。  
−提供される機能サービス。  
−使用の際の考えられる制限。
【００３０】
多数のアプリケーション環境の代替を提供することで、コスト、使用の容易さ、販売時期、機能セット、サイズ、携帯性などの要求が異なる幅広い製品への対応が容易となる。
【００３１】
図４Ｂは、実施例で見たシステムの様々な部分の間の関係を示す図である。主なドメインは、アプリケーション・ドメイン５００、ミドルウエア・ドメイン５０１、及びプラットフォーム・ドメイン５０２である。図４Ｂにおいて、高いレベルにあるモジュールは、より低いレベルにあるモジュールに依存していると見なされる。アプリケーション・ドメイン５００は、ネイティブ・アプリケーション５１６、並びに非ネイティブ環境内にカプセル化された非ネイティブ・アプリケーション５０６（１）−（Ｎ）を有していても良い。しかしながら、アプリケーション・ドメイン５００が、何らかの非ネイティブ・アプリケーションを必ず有している必要はない。アプリケーション５０６及び５１６からのサービス要求は、それらにローレベル・サービスが伝わる前にインターセプション・モジュール５０８を介したアクセス制御を受ける。このようなローレベル・サービスは、高レベルのグラフィカル・サポートを備えるプラグイン（例えば、ＵＩツールキット５１０）、並びにミドルウエア・ドメイン５０１内のオープン・プラットフォームＡＰＩ（ＯＰＡ）５１２によって代表される、より基本的なサービスを含んでいても良い。ＯＰＡ５１２を介して、アプリケーションは、アクセス許可の更新を要求するためにアプリケーション・マネージャ（ＡＭ）５１４と通信してもよい。代表的実施形態では、ＡＭ５１４は、セキュリティ・アクセス・マネージャ（ＳＡＭ）５１８にあらゆるそのような要求を通知する。ミドルウエア・サービス・コンポーネント２６の更なる詳細事項は、本願と譲渡人が同じ米国特許出願第１０／３５９７７２号に記載されている。
【００３２】
図５は、本発明の代表的実施形態による、オープン・アプリケーション・フレームワーク（ＯＡＦ）ＡＰＩドメイン２０４内の主なソフトウエア・モジュールを概略的に示す図である。図示されたように、モジュールにはＳＡＭ５１８及びアクセス・インターセプション・モジュール（ＩＭ）２２３が含まれている。ＳＡＭ５１８は、Java アプリケーションなどの非ネイティブ・アプリケーションによってなされたアプリケーションによるオープン・プラットフォームＡＰＩドメイン２０６へのアクセスを許可するのを受け持つが、これはそのようなアプリケーションをそれらの証明情報（credentials）に従って監視するためである。換言すれば、ＳＡＭ５１８は、非ネイティブ環境からの呼び出しを許可すべきか否かを判定するのに責任を持つ。ＳＡＭ５１８は、プラットフォーム・サービスのアクセスに関連したセキュリティ方針（ポリシー）を保持し保守する。これに関して、Java実行環境５０４によるネイティブ・プラットフォーム・サービスへのアクセスは、ネイティブ・アプリケーション環境５１６についてよりも限定的であろう。ＩＭ２２３は、非ネイティブ（例えば、Java）環境５０４内で実行中のアプリケーションからのサービス要求の監視を受け持ち、ネイティブ実行環境についてとも見なされるかもしれないいくつかの場合において監視を受け持つ。
【００３３】
概して、ＡＭ５１４は、全てのアプリケーションの登録、インストール、開始、停止、アンインストール、及び削除を処理する。ＩＭ２２３は、実行環境からネイティブ・プラットフォーム・サービスへの非ネイティブ・アプリケーション・サービスの要求をインターセプトし（インターセプトはJavaアプリケーションの場合にはJavaサポート・レイヤの境界で行われる）、ＳＡＭ５１８にアクセスの許可を依頼する。アクセスが許可された場合、非ネイティブ・アプリケーション・サービスの要求は、オープン・プラットフォームＡＰＩ（ＯＰＡ）に転送され、ネイティブ・アプリケーションと同様に扱われる。サービス要求は、アプリケーション２５０（例えば、図６Ａ、６Ｂを参照せよ）、又はアプリケーション・ドメイン５００内のあらゆるソフトウエアと、プラットフォーム・ドメイン５０２の間のトラフィックである。サービス要求は、プラットフォーム・ドメイン５０２のサービスにアクセスしているクライアントを表す。
【００３４】
ＳＡＭ５１８は、様々な方法でネイティブ・プラットフォーム・サービスへのアクセスを許可しても良く、その１例は図６及び７に示されている。詳細には、図６はサービス要求に関わるコンポーネント及びメッセージのブロック図であり、図７は本発明の代表的実施形態によるそれらに関連した方法を示すフローチャートである。
【００３５】
図６Ａ及び７を参照すると、ステップ２８０で、非ネイティブ・アプリケーション２５０は、ネイティブ・プラットフォーム・サービスへのアクセスを必要とするサービスを要求する。ステップ２８２で、ＩＭ２２３は、要求している非ネイティブ・アプリケーション２５０のＩＤタグを含むサービス要求をインターセプトする。ステップ２８４で、サービス要求に含まれるＩＤタグと共に、許可要求がＩＭ２２３からＳＡＭ５１８に送信される。ＩＭ２２３はまた、ＳＡＭ５１８に付加的アクセス情報及び非ネイティブ・アプリケーション２５０がアクセスを望むネイティブ・プラットフォーム・サービスの識別情報を送っても良い。ＳＡＭ５１８は、アクセスを非ネイティブ・アプリケーション２５０に許可するかどうかを決定するために、ネイティブ・プラットフォーム・サービスのセキュリティ方針を調査する。ステップ２８６で、ＳＡＭ５１８は許可の判定を行い、その判定結果をＩＭ２２３に転送する。許可要求が許可された場合、ステップ２８８で、サービス要求はネイティブ・プラットフォーム・サービス又は非ネイティブ・アプリケーション２５０によって要求されたサービスに転送される。そして要求されたサービスはステップ２９０で実行される。許可要求が否認された場合、ステップ２９６で、非ネイティブ・アプリケーション２５０に拒否応答が送信される。
【００３６】
ＩＤタグ３２０が探したアクセス記録３１８に含まれるＩＤタグ３２０のいずれかと一致しない場合、ステップ２９２で要求は拒否され、図７及び８Ａに示されるように、ステップ２９６で要求は中止され要求している非ネイティブ・アプリケーション２５０に返される。
【００３７】
更なるオプションでは、許可の判定は承認手順を必要とする。例えば、ステップ２９４で示されるように、ユーザがネイティブ・プラットフォーム・サービスへのアクセスの承認を頼まれても良い。ステップ２９４でユーザがネイティブ・プラットフォーム・サービスへのアクセスを承認した場合、ステップ２８８で要求はネイティブ・プラットフォーム・サービスに転送される。しかしながら、ステップ２９４でアクセスが否認された場合、ステップ２９２で要求は拒否され、ステップ２９６で要求は中止されその要求を発行したクライアントに返される。
【００３８】
図６Ｂ、８Ａ及び８Ｂは、インターセプション・モジュールが局所的に要求の許可又は否認の判定を行い、ＳＡＭ５１８がＩＭ内に格納された証明情報を更新する、別の例を示している。図６によれば、非ネイティブ・アプリケーション２５０はサービスを要求する。サービス要求はＩＭ２２３によってインターセプトされる。ＩＭ２２３はその要求を局所的に許可又は否認する。並行して、ＳＡＭ５１８は、要求毎のベースで又は一定間隔で、ＩＭ２２３によって保持されている記録の更新要求をＩＭ２２３に発行し、それに応じてＩＭ２２３は許可の基礎を置く。
【００３９】
図８Ａは、図６Ｂに示した例に従うサービス要求の許可又は否認の処理を詳細に示すフローチャートである。ステップ２８０及び２８２で示されるように、非ネイティブ・アプリケーション２５０はサービス要求を発行し、サービス要求はＩＤタグと共にＩＭ２２３でインターセプトされる。ＩＭ２２３からＳＡＭ５１８にＩＤタグと共に許可要求を送信する代わりに、ＩＭ２２３は局所的に判定を行う。この実施形態では、ＩＭ２２３はネイティブ・プラットフォーム・サービスについてのアクセス記録を保守している。各アクセス記録は、要求されたネイティブ・プラットフォーム・サービスへのアクセス許可を有する特定のアプリケーションのＩＤタグを含んでいる。ステップ３０１で、ＩＭ２２３は要求されたネイティブ・プラットフォーム・サービスのアクセス記録を調べ、ステップ３０３で、要求している非ネイティブ・アプリケーション２５０のＩＤタグがそれらと関連しているか、そしてその結果要求を許可すべきかを判定する。要求している非ネイティブ・アプリケーション２５０のＩＤタグがアクセス記録に見つかった場合、ステップ３０３で、非ネイティブ・アプリケーション２５０について要求されたネイティブ・プラットフォーム・サービスへのアクセス許可は許される。図７のステップ２８８と同様に、サービス要求は要求されたネイティブ・プラットフォーム・サービスへ転送され、ステップ２９０でサービスが実行される。要求されたネイティブ・プラットフォーム・サービスについてのアクセス記録内に要求している非ネイティブ・アプリケーション２５０のＩＤタグが見つからない場合、ステップ２９２で要求は拒否され、ステップ２９６で中止されその要求を発行したクライアントに返される。
【００４０】
更なるオプションでは、許可の判定は承認手順を必要とする。例えば、ステップ２９４で示されるように、ユーザがネイティブ・プラットフォーム・サービスへのアクセスの承認を頼まれても良い。ステップ２９４でユーザがアクセスを承認した場合、ステップ２８８のように要求はネイティブ・プラットフォーム・サービスに転送される。しかしながら、ステップ２９４でアクセスが否認された場合、ステップ２９２で要求は拒否され、ステップ２９６で要求は中止されその要求を発行したクライアントに返される。
【００４１】
ＳＡＭ５１８は、要求に応じて又は所定の間隔で許可の更新要求を少なくとも１つのＩＭ２２３に分配しても良い。図８Ｂに示されたように、そのような更新が行われるかも知れないときについての異なったシナリオがある。ステップ４１２で示されるように、ユーザは実行時にＡＭ５１４を介して、特定の非ネイティブ・アプリケーション２５０についての許可情報を変更しても良く、それにより、ステップ４１４で示されるように、ＳＡＭ５１８によって保守されるアクセス記録の更新が必要となる。そして更新された許可情報は、ステップ４１６で示されるように、ＳＡＭによってＩＭに転送される。ＳＡＭ及びＩＭの記録の更新が必要な他の場合には、ステップ４０４及び４０６によって示されるように、システムに新たなアプリケーションが追加されたとき、並びにステップ４０８及び４１０によって示されるように、システムから既存のアプリケーションが削除されたときが含まれる。許可の判定を一層促進するため、以下で説明するＩＭ２２３の実施形態によれば、判定キャッシュが利用されても良い。
【００４２】
ここで図９を参照すると、本発明の代表的実施形態によるＳＡＭ５１８の詳細が示されている。図示されたように、ＳＡＭ５１８は、特定のサービス要求に関連した許可の判定を見つけるために、最も頻繁な及び／又は最も新しい複数のサービス要求を記録する判定キャッシュ３１０を含んでいる。所与の非ネイティブ・アプリケーション２５０は、同じサービス要求を多数提出しても良い。従って、判定キャッシュ３１０は、頻繁なサービス要求の記録を保持し、特定のサービス要求に関連する許可判定を見つけるために以前の要求を用いて調べても良い。例えば、Javaアプリケーションは特定のネイティブ・プラットフォーム・サービスを何回か要求することがある。受信した許可要求は、要求している非ネイティブ・アプリケーション２５０のＩＤタグを含んでいる。
【００４３】
非ネイティブ・アプリケーション２５０がサービス要求を最初に行うとき、ＳＡＭ５１８は、要求されたネイティブ・プラットフォーム・サービスに対する許可を許すべきかを決定するために、アクセス制御リスト（ＡＣＬ）３１２にアクセスする。ＡＣＬ３１２は、例えば、発信元のアプリケーション証明情報から求めた、いくつかのアクセス記録を格納している。これらの記録３１４は、特定のJavaアプリケーションのような、登録されインストールされた非ネイティブ・アプリケーションそれぞれに関連している。ＳＡＭ５１８は、特定の要求しているアプリケーションと一致するのを見つけるために、要求しているアプリケーション３１４に関連していそうな記録をくまなく調べる。記録のセットの中に特定の要求しているアプリケーションが見つかった場合、要求されたネイティブ・プラットフォーム・サービスへのアクセスを許すべきかどうかを決定するために、許可情報３１６が調べられる。関連する格納された許可情報３１６に基づいて、許可の判定が与えられる。許可判定はＩＭ２２３に送信され、また許可要求と共に判定キャッシュ３１０内に記録されてもよい。次に同じ非ネイティブ・アプリケーション２５０からのサービス要求が、ＩＭ２２３によってインターセプトされてＳＡＭ５１８に転送されたときには、許可要求のために判定キャッシュ３１０が調べられる。許可要求が見つけられたとき、その許可要求に関連する許可判定がＩＭ２２３に転送される。判定キャッシュ３１０を利用することにより、ＳＡＭ５１８は許可判定をより効率的に行えるようになる。
【００４４】
図１０は、本発明の別の代表的実施形態によるＩＭ２２３の詳細を示す図である。この例ではＩＭ２２３内にＡＣＬ及び判定キャッシュが位置しているが、これらがＳＡＭ５１８内に位置していても同じ原理を適用できることに注意されたい。図１０では、ＡＣＬ３１２は図９に示されたのと異なる形式でアクセス記録を格納する。詳細には、図１０では、ＡＣＬ３１２は移動体端末のネイティブ・プラットフォーム・サービスについてアクセス記録３１８を格納する。移動体端末の各ネイティブ・プラットフォーム・サービス（又はサービスのグループ）について、１つのアクセス記録３１８が存在する。各アクセス記録３１８は、そのアクセス記録３１８に関連する特定のネイティブ・プラットフォーム・サービス（又はサービスのグループ）へのアクセスが許可された非ネイティブ・アプリケーション２５０のＩＤタグ３２０を含んでいる。ＳＡＭ５１８は、アクセスのリスト又は記録の更新が必要なときに、ＩＭ２２３に要求を送信する。更新要求は、更新に関連する非ネイティブ・アプリケーション２５０のＩＤタグと、許可情報を変更する必要がある１つ又は複数の要求されたネイティブ・プラットフォーム・サービスの識別情報を含んでいる。ＩＭ２２３は、要求されたネイティブ・プラットフォーム・サービスについてＡＣＬ３１２を調べる。見つかったら、ＩＭ２２３は見つけたアクセス記録３１８内に要求している非ネイティブ・アプリケーション２５０のＩＤタグが含まれているかどうかを判定する。要求している非ネイティブ・アプリケーション２５０のＩＤタグ３２０が見つけたアクセス記録３１８に含まれるＩＤタグ３２０の１つと一致した場合、要求している非ネイティブ・アプリケーションに許可が与えられ、サービス要求はネイティブ・プラットフォーム・サービス・ハンドラに転送される。図９を参照して説明したのと同様に、許可判定の結果は判定キャッシュ３１０にも格納されても良い。
【００４５】
ＩＤタグ３２０が見つけたアクセス記録３１８内に含まれるＩＤタグのいずれにも一致しない場合、図７及び８Ａに示したように、ステップ２９２で要求は拒否され、ステップ２９６で要求は中止されて要求している非ネイティブ・アプリケーション２５０に返送される。
【００４６】
要求に応じた並びに周期的な許可情報の更新要求は、たとえ実行中であってもＳＡＭ５１８からＩＭ２２３に送達されてもよい。ユーザが特定の非ネイティブ・アプリケーション２５０に与えられた許可情報を更新しても良く、このため、ＳＡＭ５１８内に無効で正しくない情報が存在する場合が生じる。従って、ＳＡＭ５１８は、ＡＣＬ３１２のアクセス記録３１８を更新して正しい許可情報及び／又はＩＤタグを保守するために、必要なときいつでも又は周期的な間隔で、許可情報更新要求をＩＭ２２３に発行する。ユーザによって非ネイティブ・アプリケーション２５０の許可情報が変更されたのに応じて、あるアクセス記録３１８に対して特定の非ネイティブ・アプリケーション２５０のＩＤタグを追加又は削除する必要があるだろう。
【００４７】
許可判定の手順を一層単純化するために、ＩＤタグ３２０、許可情報３１６などのタイプを、カテゴリにグループ分けし、ＩＭ２２３のＡＣＬ３１２（又はＳＡＭ５１８がＡＣＬを保持する場合にはＳＡＭ）の調査の効率を向上させても良い。例えば、各ネイティブ・プラットフォーム・サービスに、それぞれが特定の許可情報と関連する特定のセキュリティ・カテゴリを割り当てても良い。そして許可判定を、個々のネイティブ・プラットフォーム・サービスではなくセキュリティ・カテゴリに基づいて行う。通常の状況では、セキュリティ・カテゴリの数はネイティブ・プラットフォーム・サービスの数よりもかなり少なく、そのため許可判定を求めるのに関連する調査時間が減少するであろう。
【００４８】
以上本発明の代表的実施形態について記載したが、本発明はその範囲を逸脱せずに多くの方法で変更できることを理解されたい。例えば、本発明を無線通信システムの移動体端末のプラットフォームに関して主に説明したが、本発明は他の製品用のプラットフォームに関しても使用され得る。本発明は様々な方法で変更可能であるので、本発明は特許請求の範囲によって規定される程度に限定されるものであると理解されたい。
【図面の簡単な説明】
【００４９】
【図１】本発明の原理を説明するのに役立つ、無線通信システムの移動体端末用のプラットフォーム・システムの概略を示すブロック図である。
【図２】本発明の原理を説明するのに更に役立つ、図１のプラットフォーム・システムの移動体端末プラットフォーム・アセンブリの概略を示す展開ブロック図である。
【図３】本発明の原理を説明するのに更に役立つ、図１及び図２の移動体端末プラットフォーム・アセンブリのソフトウエア・アーキテクチャの概略を示すブロック図である。
【図４Ａ】本発明の代表的実施形態による、図１から３のミドルウエア・サービス・レイヤを詳細に示す論理ブロック図である。
【図４Ｂ】システムの様々な部分、すなわち、アプリケーション・ドメイン５００、ミドルウエア・ドメイン５０１及びプラットフォーム・ドメイン５０２の関係を示す実施例の図である。
【図５】本発明の別の代表的実施形態による、図４のミドルウエア・サービス・レイヤのオープン・アプリケーション・フレームワークＡＰＩドメインの詳細を示すブロック図である。
【図６Ａ】本発明の原理による、許可要求及び決定に関するメッセージの詳細を示すブロック図である。
【図６Ｂ】本発明の別の代表的実施形態による、許可要求及び決定に関するメッセージの詳細を示すブロック図である。
【図７】本発明の原理による、アクセスの要求及びＳＡＭ５１８からの許可結果の受信方法のステップを示すフローチャートである。
【図８Ａ】、
【図８Ｂ】本発明の別の代表的実施形態による、アクセスの要求及び許可結果の受信方法をより効率的に行うステップを示すフローチャートである。
【図９】本発明の原理によるセキュリティ・アクセス・マネージャの詳細を示すブロック図である。
【図１０】本発明の別の代表的実施形態による、インターセプション・モジュールの詳細を示すブロック図である。
【図１】
2006508424.tif 000002
【図２】
2006508424.tif 000003
【図３】
2006508424.tif 000004
【図４Ａ】
2006508424.tif 000005
【図４Ｂ】
2006508424.tif 000006
【図５】
2006508424.tif 000007
【図６Ａ】
2006508424.tif 000008
【図６Ｂ】
2006508424.tif 000009
【図７】
2006508424.tif 000010
【図８Ａ】
2006508424.tif 000011
【図８Ｂ】
2006508424.tif 000012
【図９】
2006508424.tif 000013
【図１０】
2006508424.tif 000014