(57)【要約】  本発明によれば、単一のクライアントのみによるアクセスのための専用物理デバイスと、複数のクライアントによる共有アクセスのための共有物理デバイスと、専用物理デバイスと関係付けられる第１の型のパーティションであって、単一のクライアント及び専用物理デバイスにアクセスするための第１のデバイス・ドライバを備える第１の型のパーティションと、共有物理デバイスと関係付けられる第２の型のパーティションであって、共有物理デバイスにアクセスするための第２のデバイス・ドライバ、及び第２のデバイス・ドライバにアクセスするためのバックエンド・ドライバを備える第２の型のパーティションと、複数のクライアントの各々１つ及び第２の型のパーティションを介して共有物理デバイスにアクセスするためのフロントエンド・ドライバを、それぞれ備える複数の第３の型のパーティションと、を備えるデータ処理システムが提供される。また、標準領域においてユーザ・アプリケーションを実行するステップと、信頼性領域において、ユーザ・アプリケーションに関連する１つ以上の既定の動作、サービス及び／又は機能を実行するステップとを備えるデータ処理システムを動作させる方法が提供される。
2010514028.tif 000002
【特許請求の範囲】
【請求項１】
単一のクライアントのみによるアクセスのための専用物理デバイスと、
複数のクライアントによる共有アクセスのための共有物理デバイスと、
前記専用物理デバイスと関係付けられる第１の型のパーティションであって、前記単一のクライアント及び前記専用物理デバイスにアクセスするための第１のデバイス・ドライバを備える第１の型のパーティションと、
前記共有物理デバイスと関係付けられる第２の型のパーティションであって、前記共有物理デバイスにアクセスするための第２のデバイス・ドライバ、及び前記第２のデバイス・ドライバにアクセスするためのバックエンド・ドライバを備える第２の型のパーティションと、
前記複数のクライアントの各々１つ及び前記第２の型のパーティションを介して前記共有物理デバイスにアクセスするためのフロントエンド・ドライバを、それぞれ備える複数の第３の型のパーティションと
を備える、データ処理システム。
【請求項２】
１つの物理デバイスについて所与の型の任意のパーティションが、別の物理デバイスについて異なる型であるように適合される、請求項１に記載のデータ処理システム。
【請求項３】
前記異なる型のパーティション上に前記データ処理システムのハードウェア資源を送り出し、それにより各型のパーティションにおいて独立の実行環境を提供するためのバーチャライザをさらに備える、請求項１又は２に記載のデータ処理システム。
【請求項４】
前記第１の型のパーティション、前記第２の型のパーティション、及び／又は前記第３の型のパーティションが、ハードウェア資源へのアクセスを有することを承認されていないクライアントによるこのようなアクセスを妨げるためのアイソレータを備える、請求項１〜３のいずれか１項に記載のデータ処理システム。
【請求項５】
各々の第３の型のパーティションが、前記複数のクライアントの各々１つによるアクセス用に前記物理デバイスのイメージを表す仮想デバイスを備える、請求項１〜４のいずれか１項に記載のデータ処理システム。
【請求項６】
前記バックエンド・ドライバが、前記複数のクライアントの各々に対する１つの前記仮想デバイスの実行を提供する、請求項５に記載のデータ処理システム。
【請求項７】
各々の第３の型のパーティションが、前記仮想デバイスを介する場合を除いて、前記第３の型のパーティションと前記第２の型のパーティションとの間の通信を妨げるためのアイソレータを備える、請求項５又は６に記載のデータ処理システム。
【請求項８】
第３の型のパーティションにおける各々のアイソレータが、バックエンド・ドライバへのアクセスを有することを承認されていないフロントエンド・ドライバによるこのようなアクセスを妨げるためのブリッジ・ドライバを備える、請求項７に記載のデータ処理システム。
【請求項９】
前記第２の型のパーティションにおける前記アイソレータが、前記第２のデバイス・ドライバ及び／又は前記バックエンド・ドライバによるフロントエンド・ドライバへの非承認のアクセスを妨げるためのブリッジ・ドライバを備える、請求項４に記載のデータ処理システム。
【請求項１０】
前記バックエンド・ドライバが、前記複数のクライアントの中の異なるクライアントからの前記物理デバイスへのアクセス間を切り替えるように配置される、請求項１〜９のいずれか１項に記載のデータ処理システム。
【請求項１１】
複数の前記パーティションが、アクセスが制限される信頼性領域を形成し、且つ複数の前記パーティションが、汎用ソフトウェアが動作可能である少なくとも１つの標準領域を形成し、前記アイソレータ及び／又は前記バーチャライザが、前記信頼性領域で動作させられ、且つ前記デバイス及び／又はフロントエンド・ドライバが、前記標準領域で動作させられる、請求項３、４又は８に記載のデータ処理システム。
【請求項１２】
前記信頼性領域においては特権化実行モードに対応し、且つ前記標準領域は非特権化実行モードに対応する、請求項１１に記載のデータ処理システム。
【請求項１３】
複数の保護リングを備え、前記信頼性領域が、最信頼性の保護リングにおける実行モードに対応する、請求項１１又は１２に記載のデータ処理システム。
【請求項１４】
前記少なくとも１つの共有及び／又は専用物理デバイスが、入力デバイス、出力デバイス、記憶デバイス、及び／又はネットワーク・デバイスを含む、請求項１〜１３のいずれか１項に記載のデータ処理システム。
【請求項１５】
任意の型の少なくとも１つのパーティションが、ユーザ・インターフェースと関係付けられ、且つ任意の型の少なくとも１つの他のパーティションが、アプリケーション又はサービスと関係付けられ、前記ユーザ・インターフェースのパーティション及び前記アプリケーション／サービスのパーティションが、インターネット・ウェブ・サービス・プロトコルを介して互いに相互作用するように配置される、請求項１〜１４のいずれか１項に記載のデータ処理システム。
【請求項１６】
前記標準領域においてユーザ・アプリケーションを実行するステップと、
前記信頼性領域において、前記ユーザ・アプリケーションに関連する１つ以上の既定の動作、サービス及び／又は機能を実行するステップと
を備える、請求項１１に記載のデータ処理システムを動作させる方法。
【請求項１７】
前記信頼性領域内から前記データ処理システムのＩ／Ｏインターフェースを制御するステップを備える、請求項１６に記載の方法。
【請求項１８】
非承認アクセスから前記標準領域を保護するために前記信頼性領域においてファイアウォールを動作させるステップを備える、請求項に１６記載の方法。
【請求項１９】
サービスを提供する前記標準領域において実行されるサービス・アプリケーションの動作を監視するステップと、前記標準領域における前記サービス・アプリケーションの故障時に、同一又は類似のサービスを提供する前記信頼性領域におけるアプリケーションを開始することにより、サービスの継続性を維持するステップとを備える、請求項に１６記載の方法。
【請求項２０】
前記標準領域において実行される動作により要求されるユーザからのパスワード又はコードを受信するために、前記信頼性領域に制御を渡すステップを備える、請求項に１６記載の方法。
【請求項２１】
デジタル著作権管理（ＤＲＭ）に従うデータをダウンロードするために前記標準領域において前記アプリケーションを実行するステップと、
前記ダウンロードされたデータへのアクセスを許可するために前記信頼性領域へ制御を渡すステップと
を備える、請求項に１６記載の方法。
【請求項２２】
前記標準領域において３Ｇ、ＷｉＦｉ及び／又はＷｉＭＡＸのような技術を使用して接続アプリケーションを動作させるステップと、前記信頼性領域内から接続アクセスを制御するステップとを備える、請求項に１６記載の方法。
【請求項２３】
前記信頼性領域において１つ以上の管理エージェントを動作させるステップであって、前記管理エージェントは、管理サーバと相互作用し、それにより前記標準領域において実行される一般のオペレーティング・システム及び／又は前記アプリケーションを管理するように適合され、前記標準領域において実行される前記一般のオペレーティング・システム及び／又はアプリケーションを提供し、構成し、更新し、監視し、再起動させること、安全なユーザ認証、並びに／又は事故の処理及び前記管理サーバへ報告することを含むステップを備える、請求項１６に記載の方法。
【請求項２４】
前記データ処理システムが、移動体通信デバイス、特に携帯電話である、請求項１６〜２３のいずれか１項に記載の方法。
【請求項２５】
前記標準領域において実行されるアプリケーションによって引き起こされるテキスト・メッセージの送信又は電話呼出の開始の前記移動体通信デバイスのユーザによる確認を要求するために、前記信頼性領域へ制御を渡すステップ
をさらに備える、請求項２４に記載の方法。
【請求項２６】
前記ユーザによる確認を要求する前に、前記テキスト・メッセージの送信及び前記電話呼出の開始と関係付けられる費用を前記ユーザに表示するステップをさらに備える、請求項２５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、単一データ処理システムを共有するために複数の実行環境を有効化するシステムに関する。
【背景技術】
【０００２】
新世代の接続デバイス及び他の組み込みシステム並びに最近のネットワーク処理又はデータ処理デバイスに要求されるソフトウェアは、各々が特定のサービスを提供するのに専用である複数の実行環境の組合せである。このような組合せの典型的な例は、（１）困難なリアルタイム・タスクをサポートするレガシー・カスタム環境又はリアルタイム・オペレーティング・システム（ＲＴＯＳ）並びに多様なアプリケーションをサポートする例えばリナックス又はウィンドウズ（登録商標）等の豊かな環境（リッチＯＳ）、（２）セキュリティの重大なタスク及びネットワーク（オープンＯＳ）又は他の入力周辺デバイスからの攻撃を受け易い及び汎用環境を実行する信頼性実行環境（ＴＴＥ）、又は（３）オープン・オペレーティング・システム（オープン／リッチＯＳ）によりサポートされる個々のアプリケーション実行環境のプロビジョニング、障害検出及び回復、符号完全性、ソフトウェア・アップグレード等を制御するデバイス管理（ＤＭ）環境である。
【０００３】
（複数の実行環境を統合する方法）  
複数の実行環境を統合する１つの方法は、各々にそれ自身の専用ハードウェアを提供することである。次に、各環境は、それ自身の専用プロセッサ及び関連ハードウェアを独立して実行する。この方法は、ほとんど又は全くソフトウェアの修正を必要とせず、ある環境で実行されているソフトウェアが他で実行されているソフトウェアから分離されることを保証し、リアルタイム・アプリケーションがそれ自身のリアルタイムＯＳで実行され、且つ各々が正しく動作するために必要なプライベート資源にアクセスすることを確保する。従来、こうした環境は、独立したハードウェア・ブロックを接続する、例えばシリアル回線、バス又はデュアル・アクセス・メモリ等の物理リンクに加えて多量のソフトウェア・プロトコルを介して通信する。
【０００４】
このような方法は、以下の理由で魅力的である。  
−  それは、追加のプロセッサ、いくらかの余分のメモリ及び恐らくは少数の余分のＩ／Ｏデバイス「のみ」を必要とする。結果として生ずる設計は、より少ない機能を有する製品が、追加のプロセッサ無しで現在のものから得られ得るという点で幾分モジュール式である。
【０００５】
−  環境が別々に動作するので、ソフトウェアの統合及び検証が容易である。ソフトウェアは、低費用で且つ適時に開発され得る。
【０００６】
しかし、この方法は、いくつかの重要な欠点を有する。  
−  それは、複雑な基板設計を必要とする。ソフトウェア開発サイクルで節約される時間が、ハードウェア設計で失われる可能性がある。
【０００７】
−  基板上の追加のプロセッサは、より高費用の部品表（ＢｏＭ）を暗示する。デバイス装置の費用、追加のメモリ、或いは幾分のデュアル・ポート・メモリを配備する要件によっても悪影響を受け、２つの独立したプロセッサからそれらにアクセスすることが非常に複雑であり得るので、様々なデバイスが複製される必要があり得る。
【０００８】
−  より多くの処理能力、デバイス及びメモリは、より多くの空間を占有し、さらに重要なことにより多くの電力を消費して、バッテリー駆動式デバイスの充電間隔を減少させる、より大きく且つ重量のあるデバイスを意味する。
【０００９】
−  さらに、独立したハードウェア／ソフトウェア・スタック間の共同及び相互作用は、慎重な注意を要求するだけでなく、これらが保護及び／又は制御しようとするソフトウェアとは別のハードウェアで実行されるときに、セキュリティ又はデバイス管理については扱いにくく又は不可能な場合さえある。
【００１０】
ハードウェアの拡張に代えて、別の方法はソフトウェアの統合である。この方法は、単一のオペレーティング・システム（ＯＳ）内において同一のプロセッサ上で同時に実行される異なるソフトウェア環境を合併又は移植することに関する。
【００１１】
多くのアプリケーションが、ＯＳと相互作用するためによく定義されかつ完全に移植可能なインターフェースを使用する。それ故に、アプリケーションは、レガシーの組込みＲＴＯＳから汎用環境に、又はその逆に移植される場合がある。エミュレーション・ライブラリが、１方のＯＳからのアプリケーションを別のＯＳで実行可能にするために生成される場合がある。セキュリティ及びデバイス管理サービスもまた、汎用又はリッチ・オペレーティング・システム内で統合され得る。
【００１２】
この方法には、以下の利点がある。  
−  ハードウェア設計が、先述のハードウェア拡張方法のものよりも非常に単純である。それ故、ハードウェア開発時間がより短く、且つ部品表が縮小される。
【００１３】
−  一旦統合されると、全てのソフトウェアは単一の環境で実行され、複数環境の負担を回避する。さらに、選択される環境がリッチ・オペレーティング・システム（リッチＯＳ）である場合、その発展（特にインターネット・プロトコル・スタック）の追跡記録が非常に容易である。
【００１４】
残念ながら、このようなソフトウェア統合の方法には多くの欠点が存在する。  
−  異なるソフトウェア環境を合併するには、多くの再設計、移植、及び検証の労力が要求される。これは、開発費用及び製品化までの時間を増加させる。
【００１５】
−  レガシーＯＳ環境は、リアルタイム保証を提供するように適合される場合が多いが、リッチＯＳは通常適合されない。エミュレーション・ライブラリの使用は、タイミング及び性能に不利な条件を与える場合がある。リッチＯＳは、リッチ・ファイル・システム又はユーザ・インターフェースのサポートのためによく適合される。しかし、レガシーＯＳは、この点について非常に制限的である。それ故、この種類の単一の環境は、アプリケーションの双方の組によって必要とされる保証及びサービスの質（ＱＯＳ）を同時に提供することが出来ない。
【００１６】
−  このような統合化ソフトウェア・スタックは、リッチＯＳアプリケーション及びサービスが全て必要でなくてもよい、より小型のハードウェア構成で縮小版が実行され得るように構成可能であるべきである。
【００１７】
−  システム全体の可用性、信頼性及びセキュリティは、単一障害点として動作する単一実行環境に依存する。それがオープン及びリッチな、それ故に複雑である、オペレーティング・システム環境により提供される場合、可用性、信頼性、及びセキュリティの観点から、システムを完全に検証し、評価し且つ認証することは不可能であろう。
【００１８】
（本発明により解決される課題を示す使用事例）  
オペレーティング・システム合併  
例えば、移動体通信の分野では、従来の携帯電話は、より高レベルのアプリケーション用の無線プロトコル・スタック、基本電話通信アプリケーション及びアプリケーション・フレームワークの上位層をサポートするリアルタイム・オペレーティング・システム（ＲＴＯＳ）を実行する、いわゆるベースバンド・プロセッサ（又はモデム）を中心に現在は構築されている。他方で、高性能スマートフォンは、複数のプロセッサ（アプリケーション・プロセッサ及びモデム）及びその関連ハードウェアに基づき、且つアプリケーション・プロセッサ上で無線プロトコル・スタック及びオープン・リッチ・オペレーティング・システム（リッチＯＳ）をサポートするモデム上でＲＴＯＳを実行する。アプリケーション及びベースバンド・プロセッサの役割を組合せて、ＲＴＯＳ及びリッチＯＳに単一のプロセッサを、共有させることが出来ることは、スマートフォンの高性能サービスを大量市場の従来のハンドセットに至らすことを可能にするであろう。
【００１９】
ネットワーク基盤設備の分野では、レガシーの、多くの場合、リアルタイム・オペレーティング・システムは、最新のマルチコア・プロセッサ及び巨大な６４ビット・アドレス可能メモリ空間をサポートしない。それらをこうした新しいハードウェア機能に適合させることは、相当量の時間及び労力並びに多くの場合、完全な再設計を要するであろう。このようなレガシーの動作環境に依存し且つ現在では完全に検証され、安定し且つ完全に機能するアプリケーションに、長年にわたって相当な投資が入れられてきた。このような新しいハードウェア機能をサポートする最新のオペレーティング・システムにより提供されるような新しい動作環境にそれらを移植することは、多くのリスクを伴う大きな投資である。既存のソフトウェア・スタックにおける変化無しで、マルチコア・ハードウェア・プラットフォーム上のこのようなレガシー・オペレーティング・システム及びアプリケーション・スタックの複数のインスタンスを合併可能なことは、こうした、そうでなければ必要とされる投資及びリスクを排除し、しかし一方で最新のハードウェア機能の完全な恩恵を受けるであろう。
【００２０】
セキュリティ管理  
セキュリティ管理の分野において、ネットワーク環境におけるリッチ且つオープンなソフトウェア動作は、任意の個数の巨大且つ複雑なソフトウェアにおいて避けることの出来ない符号誤り、設計上の欠陥又は任意の故障を利用する攻撃を受け易い。（１）オープン環境を分離し、且つ「マルウェア」の攻撃の潜在的な影響を制限し、（２）クローズの又は信頼性の実行環境において重要なデータ操作及びセキュリティ関連ソフトウェアを実行し、並びに（３）独立した信頼性のソフトウェアの部品から全て、上記の完全性及び動作を監視及び制御することが可能なことは、こうしたデバイスの中への信頼性を、その資産所有者、例えばエンドユーザ、つまり企業及び顧客、コンテンツ・プロバイダ、オペレータ、製造業者並びにソフトウェア開発者の各々に提供する上での大きな前進であろう。
【００２１】
１例は、「クローズ」又は「信頼性」の実行環境が、「重要な」又は「信頼性の」アプリケーションを実行するように配置される場合であり、一方でオープンＯＳは、「非重要な」又は「非信頼性の」アプリケーションを実行するように提供される。「重要な」アプリケーションは、携帯電話の「コア・サービス」（例えば、音声呼出、ＳＭＳ、アドレス帳）を含み、「信頼性の」アプリケーションは、セキュリティ・エージェント及びデバイス・プラットフォーム管理タスクを含む。セキュリティ及びデバイス管理エージェントは、プロビジョニング、起動、認証、アクセス制御、ＳＩＭロック、フィルタリング、暗号解読、会計監査、ロギング、更新等に関連する。非信頼性アプリケーションは、例えば一般的には、音声及び映像データ（音楽、映画）、ゲーム、又はインターネット・アプリケーションのダウンロード等のマルチメディア・アプリケーションを一般に含む。オープンＯＳの例は、ウィンドウズ（登録商標）、リナックス及びシンビアンである。
【００２２】
オープンＯＳと関係付けられる１つの問題は、そのソフトウェアが非常に大きく且つ非常に複雑であるため、基本的に「敵意」があり且つ「マルウェア」が回避できないネットワーク環境において動作する場合に、信頼することが出来ないということである。
【００２３】
例えば、オープンＯＳは、信頼性のデジタル著作権管理（ＤＲＭ）を実行するにはあまり適していない。ＤＲＭとは、ソフトウェア、音楽、映画、又は他のデジタルデータへのアクセス、特にコピー防止を制御する所定の規定を実施するために使用される技術のことを言う。
【００２４】
ネットワーク・アクセス及び記憶装置を含む、全てのデバイス資源を制御するオープンＯＳは、ＤＲＭに従ってダウンロード、暗号解読及びデジタル・データの表示を提供する。従って、オープンＯＳは、ある時点で一部の「マルウェア」がオープンＯＳの保護機構を回避出来るという高いリスクが存在するので、信頼出来る方法でのＤＲＭ保護デジタルデータへの無制限のアクセスを禁止することが出来ない。この段階で、ユーザは既に、もはや制限を受けていないデジタル・データの保存及び／又は配布をすることが可能であり得る。
【００２５】
可動式ハンドセットのオープン・ソフトウェアと関係付けられる問題の別の例は、本人が気付くことなくテキスト・メッセージ（ＳＭＳ）を送信し又は課金すること含む任意の他の動作を開始する「マルウェア」アプリケーションからのユーザの限定的保護である。このような状況を回避するための１つの方法は、課金を引き起こす動作の承認のためにユーザを促すことであろう。しかし、「マルウェア」が、ユーザを促す一連の流れを迂回できないということを、どうやって保証するかが問題である。
【００２６】
別の例は、「非信頼性」のオープン実行環境の制御下にある入力／出力周辺デバイス上での、例えばクレジットカード番号、ＰＩＮコード、ユーザ識別、パスワード、生体データ等のユーザ機密データの入力／出力に関連する。本人の秘密コードの入力を本人に要請する「プロンプト」のメッセージが「マルウェア」によって偽造されていないこと、及び入力されると、「秘密コード」が非承認アクセスに対して安全に保護されるであろうということを、どうやってユーザが信頼出来るかが問題である。
【００２７】
別の例は、例えば非承認アクセス、ウイルス、ワーム、トロイの木馬、スパム、望ましくないコンテンツ等の「マルウェア」を伝送する疑いがある、ネットワークからデバイスに入って来る又はデバイスからネットワークへ出て行く全てのデータを調査し且つ拒絶するためにデバイスにインストールされるフィルタリング・ソフトウェアに関連する。これは、「ファイアウォール」又は「インテーネット・セキュリティ」ソフトウェアと呼ばれることがある。このような「保護」ソフトウェアが、「非信頼性」のオープン環境内で実行されるときに、「マルウェア」に対してそれ自身保護されるということを、どうやってユーザが信頼できるかが問題である。
【００２８】
こうした全ての例及び本明細書に記載されない他の多くは、以下の問題に要約される。敵意のあるオープン・ネットワーク環境において、望ましくない複雑且つリッチなオープン・ソフトウェアを利用しつつ、どうやってユーザが、デバイスに要求される「信頼性コード」の量を最小化し、且つ全体の信頼性の性質を保証することができるかである。
【００２９】
デバイス・プラットフォーム管理及び高可用性  
デバイス・プラットフォーム管理は、ユーザレベルのアプリケーション及びサービスのための動作環境を制御するシステム・サービスを実行する。それは、例えばソフトウェア・プロビジョニング、安全な起動、認証、アクセス制御、監視、会計監査、ロギング、システム・ソフトウェア・アップグレード、遠隔管理サービスとの通信等のサービスを提供する。それはまた、動作環境が、継続して且つ適切に動作し、並びに障害時に迅速な回復行動（例えばそれの自動再始動等）を行うことを確実にするべきである。こうしたサービスの１つの基本的性質は、主要オペレーティング・システムが破損し又は動作不能なときであっても、実行されていることが要求されるということである。実際に、その主な役割は、動作環境の故障の場合を制御し、それを最小ユーザレベルのサービス中断で動作状態に戻すことである。その役割は、その完全性及び適切な機能を保証するために動作環境の性質を監視することでもある。
【００３０】
本発明は、ユーザレベルのアプリケーション及びサービスをサポートする動作環境を適切に制御することが出来るように、どのようなソフトウェア・アーキテクチャ及び内部方法をこのようなデバイス管理ソフトウェアをサポートするために実装することが必要とされるかに関係する。
【００３１】
より一般的には、上記の問題を解決することが、本発明の目的である。
【発明の概要】
【００３２】
本発明は、請求項１により説明される。好ましい特徴は、従属する請求項により説明される。
【００３３】
本発明によれば、
単一のクライアントのみによるアクセスのための専用物理デバイスと、
複数のクライアントによる共有アクセスのための共有物理デバイスと、
専用物理デバイスと関係付けられる第１の型のパーティションであって、前記単一のクライアント及び専用物理デバイスにアクセスするための第１のデバイス・ドライバを備える第１の型のパーティションと、
共有物理デバイスと関係付けられる第２の型のパーティションであって、共有物理デバイスにアクセスするための第２のデバイス・ドライバ、及び第２のデバイス・ドライバにアクセスするためのバックエンド・ドライバを備える第２の型のパーティションと、
複数のクライアントの各々１つ及び第２の型のパーティションを介して共有物理デバイスにアクセスするためのフロントエンド・ドライバを、それぞれ備える複数の第３の型のパーティションと
を備えるデータ処理システムが提供される。
【００３４】
また本発明によれば、
標準領域においてユーザ・アプリケーションを実行するステップと、
信頼性領域において、ユーザ・アプリケーションに関連する１つ以上の規定の動作、サービス及び／又は機能を実行するステップと
を備えるデータ処理システムを動作させる方法が提供される。
【００３５】
従って、本発明の実施形態は、２つのクラスのデバイスに適用されてもよい。第１のクラスは、非共有デバイスである。第２のクラスのデバイスは、共有デバイスである。バックエンド・ドライバは、共有デバイスへの共有アクセスを提供することに関与する。共有デバイスへのアクセスを提供するためにバックエンド・ドライバを使用する１つの利点は、ネイティブ・デバイス・ドライバを書き換える必要が無いことである。
【００３６】
バックエンド・ドライバは、実デバイスのイメージを表す仮想デバイスのイメージを「顕在化」させる。クライアントは、フロントエンド・ドライバを介して、仮想デバイスにアクセスする。物理デバイスは、各クライアントに対して１つの、複数の仮想デバイス間で「多重化」される。この多重化は、バックエンド・ドライバによって実行される。各フロントエンド・ドライバは、バックエンド・ドライバへのアクセスを提供する。
【００３７】
ハイパービジョンが知られている。ハイパービジョンは、通常、パーティション化並びにパーティション間の共有及び分離を実行する。本発明の実施形態によれば、共有及び分離は、切り離され且つ異なるパーティションと関係付けられる。特に、仮想デバイス及びアイソレータは、第３の型のパーティションと関係付けられる。
【００３８】
本発明の実施形態は、次に、例示のみの目的で、添付の図面を参照して記載される。
【図面の簡単な説明】
【００３９】
【図１】本発明の実施形態によるデータ処理システムのハードウェア・プラットフォームのパーティション化を例示する概略的なブロック図である。
【図２】本発明の実施形態によるデータ処理システムのハードウェア・プラットフォームのパーティション化を例示する概略的なブロック図である。
【図３】本発明の実施形態によるデータ処理システムのハードウェア・プラットフォームのパーティション化を例示する概略的なブロック図である。
【図４】本発明の実施形態によるデータ処理システムのハードウェア・プラットフォームのパーティション化を例示する概略的なブロック図である。
【図５】本発明の実施形態による信頼性領域及び標準領域の提供を例示する概略的なブロック図である。
【図６】本発明の実施形態による機能的信頼性実行ハードウェアを例示する概略的なブロック図である。
【図７】本発明の実施形態による信頼性領域からのＩ／Ｏインターフェースのアクセスの制御を例示する概略的なブロック図である。
【図８】本発明の実施形態による信頼性領域からの共有ユーザ入力デバイスへのアクセスの制御を例示する概略的なブロック図である。
【図９】本発明の実施形態による信頼性領域からの共有ユーザ出力デバイスへのアクセスの制御を例示する概略的なブロック図である。
【図１０】本発明の別の実施形態による信頼性領域からの共有ユーザ出力デバイスへのアクセスの制御を例示する概略的なブロック図である。
【図１１】本発明の実施形態による信頼性領域からの共有記憶装置へのアクセスの制御を例示する概略的なブロック図である。
【図１２】本発明の実施形態による信頼性領域からの共有ネットワーク・インターフェースへのアクセスの制御を例示する概略的なブロック図である。
【図１３】本発明の別の実施形態による信頼性領域からの共有ネットワーク・インターフェースへのアクセスの制御を例示する概略的なブロック図である。
【図１４】本発明の実施形態による信頼性領域からの仮想ブロック・デバイス・アーキテクチャを例示する概略的なブロック図である。
【図１５】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図１６】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図１７】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図１８】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図１９】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図２０】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図２１】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図２２】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図２３】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図２４】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【図２５】本発明の実施形態による仮想化使用事例を例示する概略的なブロック図である。
【発明を実施するための形態】
【００４０】
（定義）
実行環境  −  アプリケーション及び／又はサービスを実行することが出来る環境を提供するハードウェア及び／又はソフトウェア。例、オペレーティング・システム、デバイス・ドライバ。
【００４１】
パーティション  −  実行環境に割り当てられる、データ処理システムのハードウェア資源のサブセット。
【００４２】
バーチャライザ  −  異なるパーティションにデータ処理システムのハードウェア資源を割り当てる。
【００４３】
アイソレータ  −  仮想デバイスを介する場合を除いて、パーティション間での通信を阻害し、それにより互いからパーティションを分離するソフトウェア。
【００４４】
仮想デバイス  −  実際の物理デバイスの「イメージ」。
【００４５】
信頼性実行機関  −  信頼性サービスを実行するための実行環境。このような実行機関は、セキュリティ関連タスク等をサポートするために、例えばスケジューリング、同期化、タイマ、メモリ管理等のサービスを提供する。
【００４６】
（序論）
リアルタイム仮想化技術
本発明の実施形態は、同一のシングルコア若しくはマルチコア・プロセッサ又は対照型マルチプロセッサ（ＳＭＰ）構成において、同時に複数の実行環境を実行することを可能にするリアルタイム仮想化技術を提供する。こうした実行環境は、互いから独立しているが、有効な通信機構を介して共同することが出来る。ユーザレベルのサービス及びアプリケーションを含む、完全なオペレーティング・システムを実行している実行環境は、通常、ゲストＯＳと呼ばれる。
【００４７】
ＩＴサーバ空間におけるような仮想化が知られている。しかし、組み込み及びリアルタイム環境において要求されるアーキテクチャ及び設計事項は、異なる設計方法をもたらしている。
【００４８】
例えば図１−４に示されるように、シン（ｔｈｉｎ）抽象化層（バーチャライザ）は、それが基本ハードウェアからの実行環境に割り当てる重要なシステム資源を管理する。より正確には、本発明の実施形態の仮想化技術は、実行環境間の資源のパーティション化及びパーティション化されない資源の仮想化に主に依存する。
【００４９】
典型的には、単一のＣＰＵ、ＦＰＵ、ＭＭＵ又は例えばリアルタイム・クロック及び割り込みコントローラ等のいくつかの他のシステム部品が仮想化される一方で、物理メモリが実行環境間でパーティション化される。
【００５０】
この方法によれば、実行環境が、数キロバイトのメモリで単一のデバイス・ドライバを実行することが要求されるほどに単純なものから、汎用ゲストＯＳを遂行するために決定性性質を用いるリアルタイム・オペレーティング・システム（ＲＴＯＳ）にまで及ぶことが許容される。このような設計方法は、仮想化技術を組み込み及びリアルタイム・システムに適用することを可能にする。
【００５１】
パーティション化  
パーティションは、２つのパーティションに割り当てられる資源が全く重複しない、実行環境に割り当てられるデータ処理システムのハードウェア資源のサブセットである。２つのパーティションは、各々に直接アクセス可能な物理メモリの範囲が重複しないように、一般的なメモリチップから割り当てられたメモリであってもよい。１つのパーティションは、メモリ上で第２のパーティションの処理が直接動作するように命令することによってのみ、第２のパーティションのメモリを間接的に制御してもよい。
【００５２】
図１及び２は、３つの型のパーティションを例示する。第１の型のパーティションは、クライアント（アプリケーション）及び専用物理デバイスにアクセスするためのネイティブ・ドライバを備える。よって、第１の型のパーティションにおいて、周辺デバイスへのアクセスは、同一のパーティションにおけるアプリケーションに専用である。
【００５３】
第２及び第３の型のパーティションは、周辺デバイスへの共有アクセスを提供する。第２の型のパーティションは、第３の型のパーティションがデバイス・クライアントを備える一方で、デバイス・サーバを備える。
【００５４】
図３は、本発明の実施形態に従って、１つ以上のユーザ・インターフェース並びにアプリケーション及びサービスが、異なるパーティションにおいて（信頼性又は非信頼性の、異なるＯＳ上で）実行され且つインターネット・ウェブ・サービス・プロトコルにより相互作用することが出来るように、それらの間の相互作用を概略的に例示する。この実施形態は、デバイスへのローカルなサービスとネットワークを介してアクセスされる遠隔サービスとの間の区別をしないことを可能にする。デバイス製造業者がデバイス（オフライン・モード）でローカルに、又はネットワーク・サーバ（オンライン・モード）で遠隔に、又は両方（断続的オン／オフライン・モード）でデバイスサービスを実行する場所を決定することは、完全な柔軟性を提供する。これは、「軽量級」に対する同一のユーザ・インターフェース及びＳＷアーキテクチャ、ＵＩのみがローカルである低費用デバイス、並びに遠隔にアクセスされるアプリケーション（しかし常に接続される必要がある）、及びそれらの全てのアプリケーションをローカルに実行するより「重量級」、高費用でしかしより自律的な装置の使用を許容する。
【００５５】
図４は、ユーザ・インターフェースのパーティション、サービス／アプリケーションのパーティション、及び共有デバイス・アクセスのパーティションの間の相互作用の配置を概略的に例示する。
【００５６】
分離及びセキュリティ  
例えば、内部又は外部の脅威にさらされ得る「非信頼性」ソフトウェアを実行するパーティションから「信頼性」ソフトウェアを含むパーティションを保護するために、いくつかのソフトウェア構成及びアプリケーションは、データ処理システムのハードウェアの単純なパーティション化により提供される分離よりも強度の分離を要求してもよい。この目的を達成するために、選択的なアイソレータ・モジュールは、例えばパーティション間のハードウェア制御の分離を提供するために、メモリ管理装置によって提供されるような、基本ハードウェア制御の資源を利用する。
【００５７】
分離はそれ自体でセキュリティなのではないが、安全なシステムの生成には必須条件である。本発明の実施形態による仮想化技術は、アイソレータ・モジュールによってサンドボックス化パーティションで実行するために作成される非信頼性実行環境の完全な分離を可能にする。信頼性実行環境は、信頼性エージェントにプラットフォームのコア・セキュリティ・サービスを管理させるように構成され得る。このような信頼性エージェントは、システム全体による必要に応じて、ＤＲＭ規定を実行し、キーを保存し又はマルチレベル・セキュリティ・プラットフォームを実行するように構成され且つ使用されてもよい。
【００５８】
仮想化技術は、開発者が要求されるレベルの分離と所望のレベルの性能との間で明白なトレードオフを行うことを可能にするモジュラー・アーキテクチャに沿って設計されている。
【００５９】
パーティション化及び分離は、安全な、信頼性ゾーン又は環境を、１組の非信頼性、オープン又はクローズ、標準又は商用ゾーン若しくは環境から分離するために使用されてもよい。信頼性ゾーンは、例えば仮想化ソフトウェア自身、制御プログラム、セキュリティ・エージェント、管理エージェント等の、信頼性ソフトウェアとして実装されるコア・サービスが実行されるデータ処理デバイスのハードウェア及び／又はソフトウェア・アーキテクチャのその部分により形成され、且つ信頼性（リアルタイム）実行機関を備えてもよい。信頼性ゾーンは、デバイスの持続性メモリに組み込まれてもよい。オープン・ゾーンは、オペレーティング・システム（ゲストＯＳ）が、例えばデータのダウンロード又は対話型ユーザ・サービスの提供等の、サービス及びアプリケーションを実行するように動作するデバイスのハードウェア及び／又はソフトウェア・アーキテクチャのその部分により形成される。オープン・ゾーン及び信頼性ゾーンは、共に単一のプロセッサを共有してもよい。
【００６０】
オープン・ゾーンで実行されているアプリケーションの所定の動作は、他方のパーティションに、例えば信頼性ゾーンへ転送されてもよい。それにより、オープン・ゾーンにおけるこうした動作の実行と関係付けられ得るリスク、例えばセキュリティ・リスク（その「オープン」の性質が原因であり得る）は、排除される。
【００６１】
単一の所与の実行環境によってのみ使用される、例えばメモリ等のパーティション化資源は、その実行環境によって排他的に所有される。よって、各ゲストＯＳは、他のゲストＯＳと干渉せずに、例えばメモリ管理等のそれ自身の生来の機構及び規定を使用してもよい。
【００６２】
本発明の実施形態によれば、単一の実行環境によって使用されるＩ／Ｏデバイスは、その実行環境に割り当てられ、よって、ネイティブ・デバイス・ドライバは、何らの修正も加えずに、再使用され得る。
【００６３】
仮想化  
例えばＣＰＵ及びリアルタイム・クロック等の１つより多くの実行環境に共通のコア・ハードウェア資源は、このような資源にアクセスする必要があるこうした実行環境の間で共有することが出来るように、仮想化される。
【００６４】
効率性を確保するために、ゲストＯＳカーネルの一部の適合が行われることを意味する、準仮想化技術が用いられてもよい。こうした変更は、基本ハードウェアに非常に似たハードウェアにそのＯＳを移植する労力及び範囲と同程度である。従って、新しいＯＳに対するサポートを追加することは、容易である。
【００６５】
本発明の実施形態によれば、ＣＰＵ、ＦＰＵ及びＭＭＵ（存在する場合）資源は、常に仮想化される。ＣＰＵは、リアルタイムＯＳがより高い優先順位を得ることを保証するスケジューリング規定に基づいて選択される実行環境にプロセッサを割り当てるスケジューラによって共有される。
【００６６】
ゲストＯＳが、ＣＰＵアクセスを与えられている場合、それはなお、そのアプリケーションのためにそれ自身のネイティブ・スケジューリング・アルゴリズムを使用する。
【００６７】
存在する場合、ＭＭＵは、各ゲストＯＳがそれをそれ自身の目的で使用し得るように仮想化される。１つのゲストＯＳによるＭＭＵの使用は、別のゲストＯＳによるＭＭＵの使用から独立している。
【００６８】
デバイス仮想化  
同一のプロセッサ上で同時に異なるＯＳを実行することは、問題の小さな一部に過ぎない。デバイス又は資源と通信し又は共有もしないＯＳを実行することは、ほとんど無価値であろう。
【００６９】
一般的に、本発明の実施形態によれば、複数のアプリケーションをサポートし、それらにメモリを割り当て且つアプリケーション・スケジューリング・アルゴリズムを提供するＯＳ環境が提供される。
【００７０】
また、本発明の実施形態による仮想化技術は、各ゲストＯＳに同期化（クロス割り込み機構）、例えばディスク・コントローラ等のデバイスへの共有アクセス、ネットワーク・インターフェース、シリアル回線及び例えば仮想イーサネット（登録商標）又は仮想ＵＡＲＴ等を介するＯＳ間通信機構を提供する。
【００７１】
共有Ｉ／Ｏデバイス  
例えばイーサネット（登録商標）・コントローラ等のデバイス、シリアル回線、又は記憶デバイスは、単一より多くのゲストＯＳによってアクセスされる必要がある。このような標準Ｉ／Ｏデバイスに関して、物理ハードウェア・デバイスを管理し且つ対応するデバイスを仮想化する「バックエンド」デバイス・ドライバ、並びに他のゲストＯＳにそのデバイスの仮想ビューをエクスポートする「フロントエンド」デバイス・ドライバが含まれる。この方法は、こうしたゲストＯＳに物理デバイスへの実際のアクセス無しで各「仮想」デバイスの機能へのアクセスを提供する。
【００７２】
共有Ｉ／Ｏデバイスへのアクセスは、優先順位及び／又は公平性を考慮し且つ他のＯＳの共有資源へのアクセスを潜在的に妨害し得る１つのゲストＯＳからのサービス妨害（ＤｏＳ）を回避する規定に従ってゲストＯＳに与えられる。
【００７３】
仮想通信デバイス  
異なるゲストＯＳ間の通信は、仮想通信デバイスによって提供される。異なる型のこうしたデバイスは、通信アプリケーションの必要に応じて構成され得る。例えば、システムは、マシンの完全に内側に設置されるローカル・プライベート・ネットワークを実装する仮想イーサネット（登録商標）を使用してもよく、且つ／又は一方のゲストＯＳから他方へＡＴモデム・コマンドを渡す仮想ＵＡＲＴデバイスを使用してもよい。
【００７４】
モジュラー方式、性能、設置面積  
全ての製品の問題を適切に解決し得る汎用的一意の解決法は存在しない。本発明の実施形態による仮想化技術は、設置面積、性能、分離及びセキュリティの間の要求される製品固有のトレードオフに合致するカスタム製品固有の仮想化解決法を開発者に構成可能にするモジュラー・アーキテクチャを使用する。
【００７５】
特に、デフォルト構成は、それ自身の物理メモリを各ゲストＯＳに与えて、ほとんどのメモリ・アクセス・エラーを捕捉する個々のゲストＯＳ間の十分なメモリ分離を提供する。このようなデフォルト構成は、ＭＭＵを備えるハードウェア上でより強度の分離サービスを提供するためにアイソレータ・モジュールを用いて選択的に補完され得る。
【００７６】
（特定の実施形態の詳細な説明）  
信頼性システムの概念  
概念的に、本発明の実施形態によれば、単一のハードウェア・プラットフォームにおける複数の実行環境が提供される。
【００７７】
図５を参照すると、プラットフォーム全体は、論理的に複数の領域（ゾーン）に分けられる。各「領域」は、複数の「パーティション」を利用することが出来る。信頼性（認定）ソフトウェアが実行される１つの信頼性領域が存在する。さらに、選択的に、複数の標準領域が、同一のプラットフォームに共存することが出来る。標準領域は汎用（一般的には非認定）オペレーティング・システム、又は任意の他の非信頼性ソフトウェアを実行するために設けられる。プラットフォーム上で利用可能な任意のハードウェア資源（例えば、ＣＰＵ、ＦＰＵ、ＭＭＵ、ＲＡＭ、Ｉ／Ｏデバイス）は、排他的に１つの領域のみに加えられる。
【００７８】
全ての利用可能なハードウェア資源は、静的及び動的の２つのカテゴリに分けられる。静的資源（ＲＡＭ又はＩ／Ｏデバイス等）は、一般的に起動時に加えられ、且つ通常その所有者が経時的に変化することは（ほとんど）ない。他方、動的資源（例えば、ＣＰＵ、ＦＰＵ及びＭＭＵ）は、要求に応じて加えられ、従って、異なる領域によって代替的に所有される。信頼性ソフトウェアは、信頼性ソフトウェア自身に関して及び他方の標準領域に関して安全である各標準領域内で実行環境を提供する。このような安全な実行環境内で実行されるソフトウェアは、信頼性ソフトウェアのセキュリティ、完全性及び可用性を危険にさらすことが出来ない。さらに、信頼性ソフトウェアは、異なる標準領域間での相互保護を提供する。特に、信頼性ソフトウェアは、所与の標準領域によって所有されない資源が、この領域内で実行される標準ソフトウェアからアクセス出来ないことを保証する。領域間通信を提供するために、信頼性ソフトウェアは仮想デバイスを生成する。このようなデバイスは、安全な実行環境の役割を果たす。ハードウェアＩ／Ｏデバイスと類似して、仮想デバイスは、標準領域に利用可能な追加の資源とみなされ得る。仮想デバイスは、信頼性領域と標準領域との間で並びに２つの標準領域の間で（信頼性ソフトウェアによって許可される場合）通信するために使用され得る。例えば、信頼性領域（例えば、ハードディスク・パーティション）によって所有される信頼性デバイスは、専用仮想デバイス（仮想ブロック・デバイス）を介して標準領域に利用可能にされ得る。別の例は、所定の標準領域を接続する仮想ネットワーク（例えば、仮想イーサネット（登録商標）ＬＡＮ）である。
【００７９】
実施形態において、信頼性システム設計は、信頼性領域内で実行される３つのソフトウェア構成要素に基づく。  
−  バーチャライザ  
−  アイソレータ  
−  「信頼性実行機関」
いくつかのこうした構成要素の組合せは、「ハイパーバイザ」とも呼ばれることがある仮想マシン・モニタの機能を提供する。
【００８０】
図６及び７は、本発明の実施形態による概略的な「信頼性実行」機構を例示する。
【００８１】
バーチャライザは、異なるパーティションを横断してプラットフォーム上で利用可能な全てのハードウェア資源を送出することに責任を負う。特に、最も重要なバーチャライザの役割は、パーティション間に動的資源（例えば、ＣＰＵ、ＦＰＵ、ＭＭＵ）を送出して各パーティション間に独立した実行環境を提供することである。静的資源分配は、バーチャライザがグローバル資源レポジトリ及び静的資源割り当てを管理するための共通フレームワークを提供する共同的方法にほぼ基づく。このようなバーチャライザのサービスを使用して、静的資源は、各領域で実行されるソフトウェアによって協同的に分配される。
【００８２】
「信頼性実行機関」は、信頼性エージェントを実行するための安全な実行環境を提供する。「信頼性実行機関」は、他の信頼性エージェントに必要とされるコア・セキュリティ機能（例えば、暗号文、計測、証明、認証、信頼性デバイスのアクセス）をサポートするために存在することに留意すべきである。「信頼性実行機関」は、例えばマルチタスク・スケジューリング、同期命令、タイマ、メモリ管理等の基本カーネルサービスを提供する。
【００８３】
アイソレータは、安全領域及び他の標準領域に対して安全である標準領域内で実行環境を提供することに責任を負う。主なアイソレータの役割は、領域内で実行される標準ソフトウェアによってアクセスされることから標準領域によって所有されないハードウェア資源を保護する「ブリック・ウォール」を構築することである。さらに、アイソレータは、仮想デバイスを提供して安全な通信リンクが領域間で確立されることを可能にする。言い換えれば、アイソレータは、安全なトンネルを越えて相互接続され得るブリック・ウォールにおいて安全なドアを提供する。
【００８４】
バーチャライザ及び「信頼性実行機関」の構成要素が、プラットフォームで一意である一方で、同時に実行される複数のアイソレータのインスタンス、すなわち標準ドメインごとに１つのアイソレータのインスタンスが存在する。同一のプラットフォームで実行されるアイソレータのインスタンスは、必ずしも同質の実行環境を提供するとは限らないことに留意するべきである。同質の実行環境を提供する異なる領域に対して異なる性質の「アイソレータ」を実行することが可能である。特に、アーキテクチャは、異なる標準領域において異なるオペレーティング・システム（例えば、リナックス及びウィンドウズ（登録商標））を実行することを妨げない。
【００８５】
バーチャライザ  
バーチャライザは、単一のハードウェアを複数のパーティションに、例えば、１つのプライマリ・パーティションと（選択的に）複数のセカンダリ・パーティションとに分割する。単一のハードウェア・プラットフォームは、バーチャライザによって１組のハードウェア資源（例えば、ＣＰＵ、ＭＭＵ、ＲＡＭ、Ｉ／Ｏデバイス）とみなされ、且つバーチャライザの主要な役割は、こうした資源をパーティション間に送出することである。
【００８６】
各パーティションは、パーティションに割り当てられる資源を管理する実行環境を実行するために設けられる。既存のオペレーティング・システムは、ゲストＯＳとしてパーティション内で実行されるバーチャライザ上で移植される必要があることに留意するべきである。言い換えれば、既存のオペレーティング・システム・カーネルのソースは、バーチャライザによって生成されるパーティション内で実行するために修正される必要がある。バーチャライザ自身は、高レベルの特権で実行される。利用可能なハードウェア機能によっては、オペレーティング・システム・カーネルは、特権モードで実行されることも可能である。このような場合、このようなパーティション間の絶対の保護は存在しない。バーチャライザ・アーキテクチャは、個々のパーティション内で特権モードで実行されるオペレーティング・システム・カーネルの正確な動作及び共同に依存する。
【００８７】
信頼性システムにおいて、非信頼性オペレーティング・システム・カーネルは、以下により詳細に記載されるアイソレータを用いて達成される。信頼性システムにおいて、オペレーティング・システム・カーネルは、他のパーティションに安全な実行環境を提供する非特権実行モードで、アイソレータの上部で実行されている。これは、システムの完全性、セキュリティ及び可用性が、このようなオペレーティング・システムによって危険にさらされ得ないことを保証するアイソレータの上部で実行されるオペレーティング・システム・カーネルから、正確且つ共同の動作が、もはや要求されないことを意味する。
【００８８】
実施形態によれば、信頼性及び標準ソフトウェア領域（「信頼性システム」）とプライマリ及びセカンダリ実行パーティションとの間には特定の位相的関係が存在する。信頼性バーチャライザは、信頼性領域と関係付けられ、且つ複数の実行パーティション、例えば、１つのプライマリ及び複数のセカンダリ・パーティションを提供する。プライマリ・パーティションは、信頼性領域からソフトウェアを排他的に実行する。これが、「信頼性実行機関」及び信頼性エージェントである。セカンダリ・パーティションは、非信頼性実行環境をサポートする追加の信頼性ソフトウェア又はアイソレータのインスタンスを実行することが出来る。１つの標準領域は、通常、オペレーティング・システム・カーネルのインスタンス及びカーネルの上部で実行される複数のユーザ・プロセスから構成される１つのセカンダリ・パーティションに関係付けられる。
【００８９】
プラットフォームで利用可能な全てのハードウェア資源は、静的及び動的の２つの基本カテゴリに分けられる。
【００９０】
ほとんどのハードウェア資源は静的であり（例えば、ＲＡＭ、Ｉ／Ｏデバイス）、且つ一般的には所与のパーティションの起動（又はさらに構築）時に割り当てられ、従ってその所有者は、決して（又はほとんど）変更されない。よって、静的資源の分配は、非常に容易であり、且つ個々のパーティションで実行されるオペレーティング・システム・カーネルに関する共同方法にほぼ基づいている。バーチャライザは、基本的にグローバルの静的資源レポジトリ及び資源割当を管理する共通のフレームワークを提供する。バーチャライザのツールを使用して、静的資源は、各個のパーティションで実行されるソフトウェアによって共同的に分配される。
【００９１】
ハードウェア・プラットフォームで利用可能な主要な動的資源は、中央演算装置（ＣＰＵ）並びにコプロセッサ（例えば、浮動小数点演算装置（ＦＰＵ））及び／又はメモリ管理装置（ＭＭＵ）等の選択的ＣＰＵ補助デバイスである。バーチャライザの主要な役割は、既定のスケジューリング規定を使用してパーティション間でＣＰＵ資源を動的に共有することである。バーチャライザは、一方のパーティションから他方への切り替えを行って各個のパーティションに仮想ＣＰＵ（並びに関連補助デバイス：ＦＰＵ及びＭＭＵ）を提供する。パーティション切り替え時間で、バーチャライザは、ＣＰＵ、ＦＰＵ及びＭＭＵデバイスの状態を保存及び復元してオペレーティング・システム・カーネルに対してこのようなパーティション切り替えを透過的にする。
【００９２】
バーチャライザ・スケジューラ  
実施形態において、ＣＰＵ資源配分は、プライマリ及びセカンダリ・パーティションの型に対して不均等である。基本的に、プライマリ・パーティションは、ＣＰＵ資源に関して特権を与えられる。デフォルトでは、バーチャライザ・スケジューラは、ＣＰＵ資源をプライマリ・パーティションに与える。プライマリ・オペレーティング・システムが、明示的にＣＰＵ資源を解放してバーチャライザを呼び出す場合にのみ、ＣＰＵ資源はセカンダリ・パーティションに利用可能になる。この瞬間に、既定のスケジューリング規定を使用して、バーチャライザ・スケジューラは、実行の準備が出来ているセカンダリ・パーティションを選択し、且つパーティション切り替えを行ってこのようなセカンダリ・パーティションを作動させる。
【００９３】
セカンダリ・パーティションの作動中にハードウェアの割り込みが発生すると、ＣＰＵ資源はプライマリ・パーティションに無条件に返還される。言い換えれば、セカンダリ・パーティションがＣＰＵを所有するときにハードウェアの割り込みが発生する場合、バーチャライザはプライマリ・パーティションに切り替え且つ割り込みを処理するためにプライマリ・オペレーティング・システム・カーネルの割り込み処理ルーチン（ＩＳＲ）を呼び出す。割り込まれたセカンダリ・パーティションの実行は、プライマリ・オペレーティング・システムが全ての関連する行動を完了し且つＣＰＵを解放するためにバーチャライザを呼び出す場合にのみ、継続され得る。
【００９４】
言い換えれば、バーチャライザ・スケジューラ規定は、セカンダリ・パーティションをスケジュールするためにのみ使用される。よって、バーチャライザ・スケジューラは、プライマリ・オペレーティング・システムによって明示的に作動させされる第２のレベルのスケジューラである。
【００９５】
一般的な方法は、プライマリ・カーネルのアイドル・ループでＣＰＵ資源を解放すること（従って、バーチャライザ・スケジューラを作動させること）である。これは、セカンダリ・パーティションの行動をプライマリ・オペレーティング・システムの一種のバックグラウンド・レベルに配置する。しかし、中間の優先順位で実行される専用スレッドにおける、より一般的には、所与のスケジューリング・クラスに属するスレッドにおけるようなＣＰＵの解放を実行することによりセカンダリ・パーティション行動の優先順位を上げることも可能である。アイドル・ループに類似して、このような特別なスレッドは、ＣＰＵを解放し且つバーチャライザ・スケジューラを作動させるためにバーチャライザを呼び出すことが出来る。この場合、プライマリ・オペレーティング・システムは、割り込みが発生するか又は全てのセカンダリ・パーティションがアイドルであるかどちらかの場合に、元通りにスケジュールされるであろう。このような技術は、バーチャライザ・スケジューラをプライマリ・オペレーティング・システムの所与のスケジューリング・クラスに関連付け、従って、プライマリ・スケジューリング階層の中央にそれを置くことを可能にする。
【００９６】
セカンダリ・パーティションをスケジュールするために、バーチャライザ実行機関は、標準的な優先順位ベースのスケジューラを提供する。さらに、バーチャライザ実行機関は、所与のＣＰＵ資源の割合を所与のセカンダリ・パーティションに割り当てさせるフェアシェア・スケジューリング規定をサポートする。セカンダリ・パーティション間においてフェアシェア方式でＣＰＵ資源を配分する場合、バーチャライザ・スケジューラは、プライマリパーティションにより消費されるＣＰＵ資源を、ＣＰＵバジェットに含み又はＣＰＵバジェットから排除することが出来る。フェアシェア・スケジューリング規定は、優先順位ベースのスケジューラの上部で実行される。それは、消費ＣＰＵ資源によりセカンダリ・パーティションの優先順位を動的に調整する。
【００９７】
Ｉ／Ｏデバイス  
バーチャライザは、通常、コンソール／デバッグ・リンクに専用のシリアル回線を除いてＩ／Ｏデバイスを管理しない。これは、バーチャライザ構成要素が、デバイス・ドライバを全く含まないことを意味する。プラットフォームで利用可能なハードウェア・デバイスは、プライマリ又はセカンダリ・パーティションのどちらかで実行される適切なオペレーティング・システム・ドライバによって常に管理される。バーチャライザの上部で実行される任意のオペレーティング・システムは、パーティションにより所有されていないデバイスのためにドライバを立ち上げることを回避する責任を負う。これは、所与のデバイスが異なるパーティションで実行される複数のデバイス・ドライバにより同時にサービスを提供されないことを確実にする。排他的なデバイス・アクセスは、任意の（プライマリ及びセカンダリ）パーティションにおいてネイティブ・オペレーティング・システム・ドライバを実行することを可能にする。
【００９８】
バーチャライザの上部でオペレーティング・システムを移植するときに、通常はデバイス・ドライバの修正は必要とされないということを明確にすることが重要である。
【００９９】
仮想デバイス  
１つのパーティションのみによって排他的に使用されるＩ／Ｏデバイスの大部分と対照的に、オペレーティング・システムを機能させるために各パーティションにおいて利用可能であるべき少数のシステム・デバイスも存在する。このようなシステム・デバイスの一般的なリストは以下の通りである。  
−  チック・タイマ（ＴＩＣＫ）
−  リアルタイム・クロック（ＲＴＣ）
−  プログラム可能割り込みコントローラ（ＰＩＣ）
【０１００】
実施形態において、上記のシステム・デバイスは、プライマリ・パーティションに加えられ、従って、プライマリ・オペレーティング・システムのネイティブ・バックエンド・ドライバにより管理される。
【０１０１】
任意のセカンダリ・パーティション内においてもシステム・デバイスを利用可能にするために、バーチャライザは、実際のシステム・デバイスを仮想フロントエンド・デバイスに置換する。バーチャライザは、このようなデバイス自身を実行しない。むしろ、それは、デバイスのインターフェースを特定し、且つデバイスを実行するのを支援するフレームワークを提供する。プライマリ・オペレーティング・システムは、セカンダリ・パーティションに対して利用可能な仮想デバイスを実行するバックエンド・ドライバを提供することを担当する。明らかに、プライマリ・オペレーティング・システムにおいて、これは、仮想化されているシステム・デバイスにサービスを提供する既存のネイティブ・ドライバにある程度の変更（又は拡張）を要求する。セカンダリ・オペレーティング・システムにおいて、これは、実システム・デバイス・ドライバを、仮想システム・デバイスを管理する新しい仮想フロントエンド・ドライバに置換することを要求する。
【０１０２】
仮想バス  
バーチャライザは、全てのパーティションを接続し、異なるオペレーティング・システム間にパーティション間通信チャネルが確立されることを可能にする一種の仮想バス（ＶＢＵＳ）を提供する。仮想システム・デバイスに類似して、バーチャライザは、それ自身で通信ドライバを実行しない。むしろ、それは標準通信プロトコルを指定し、且つプライマリ及びセカンダリ・オペレーティング・システムにおいて通信ドライバを実行するフレームワークを提供する。
【０１０３】
信頼性システムにおいて、以下の通信プロトコルが利用可能である。  
−  ベーシック・ロー・プロトコル（ＢＵＳＲＡＷ）
−  イーサネット（登録商標）・プロトコル（ＢＵＳＥＴＨ）
−  シリアル回線プロトコル（ＢＵＳＴＴＹ）
−  ブロック・デバイス・プロトコル（ＢＵＳＢＬＫ）
【０１０４】
ベーシック・ロー・プロトコル（ＢＵＳＲＡＷ）を使用して、異なるパーティションにおいて実行されるオペレーティング・システムは、片方向（例えば、１方向）通信パイプ上で通信をすることが出来る。このようなＶＢＵＳパイプは、様々なフレームサイズを受け入れる信頼できる接続を提供する。所与のパイプによって受け入れられたフレームの最大サイズは、パイプ生成時間で特定される。
【０１０５】
ＢＵＳＲＡＷプロトコルの上部で、バーチャライザは、仮想イーサネット（登録商標）（ＢＵＳＥＴＨ）、仮想シリアル回線（ＢＵＳＴＴＹ）及び仮想ブロック・デバイス（ＢＵＳＢＬＫ）プロトコルを指定する。
【０１０６】
ＢＵＳＥＴＨプロトコルは、所定のパーティションを接続する仮想ローカル・イーサネット（登録商標）・リンクを提供する。
【０１０７】
ＢＵＳＴＴＹプロトコルは、２つの所与のパーティション間で仮想シリアル回線を提供する。
【０１０８】
ＢＵＳＢＬＫプロトコルは、２つの異なるパーティションで実行されるバックエンドとフロントエンドのブロック・デバイス・ドライバを接続する。
【０１０９】
アイソレータ  
ＩＡ−３２のためのアイソレータ  
アイソレータは、特権化ＣＰＵレベルで（例えば保護リング０で）信頼性領域において実行されている。安全な実行環境を提供するために、アイソレータは、リング１の非特権化ＣＰＵ保護レベルにおいてゲストＯＳカーネルを実行する。特権化命令（例えば、制御レジスタへ／からのＣＬＩ、ＳＴＩ、ＭＯＶＥ等）はもはやリング１で利用出来ないが、この実行レベルは、ＭＭＵの観点からそれでもスーパーバイザとみなされる。このような特権化命令を実行する試みは、一般保護違反例外がアイソレータに送られることを引き起こす。
【０１１０】
アイソレータは、利用不能特権化ＣＰＵ命令を同等の巨視的サービスに置換する。アイソレータの上部で実行されるゲストＯＳカーネルは、特権化命令の使用を回避するために修正される。その代わり、カーネルは、特権化動作を実行するために、アイソレータ・サービスを明示的に呼び出す。全てのこうした動作は、アイソレータによって完全に制御され、ＣＰＵ資源への非承認／誤アクセスを回避する。
【０１１１】
アイソレータは、ゲストＯＳカーネルによるＭＭＵ変換ツリーの直接の修正を許可しない。ＭＭＵ変換ツリーにおいて使用される全ての物理ページ（すなわち、ページ・テーブル及びページ・ディレクトリ）は、常に読み取り専用でマッピングされて、カーネルをページ・テーブル／ディレクトリ・エントリ（ＰＴＥ）の非承認の修正から防ぐ。カーネルが仮想から物理への変換（すなわち、ＰＴＥ）を修正する唯一の方法は、適切なアイソレータ・サービスを呼び出すことである。新しい変換（仮想アドレス空間から物理アドレス空間への）が確立されると、アイソレータは、ＲＡＭ及びＩ／Ｏ資源への非承認アクセスを回避する物理アドレスを確認する。保護属性を変更して、アイソレータはまた、ページ・テーブル／ディレクトリの書込み保護がカーネルにより危険にさらされていないことを確認する。
【０１１２】
割り込み可能フラグ（ＩＦ）に基づくハードウェア割り込みマスク機構の代わりに、アイソレータは、カーネルとアイソレータの間で共有されるグローバル・データに基づいてソフトウェア割り込みマスクを実行する。
【０１１３】
アイソレータはまた、マシン（実）アドレスにマッピングされる仮想化隣接物理アドレス空間をカーネルに提供する。このようなマシン及び物理アドレス間の中間マッピングは、カーネルによって所有されるマシン・ページをオンザフライで透過的に置換することを可能にする。
【０１１４】
アイソレータは、タスク状態セグメント（ＴＳＳ）のＩ／Ｏビットマップ・ストリングを使用して、カーネルのアクセスをＩＳＡ  Ｉ／Ｏポートに制限する。デフォルトでは、全てのＩＳＡ  Ｉ／Ｏポートは、カーネルに利用不能である。他方で、リング１から所与のＩ／Ｏポートに任意にアクセス可能にすることが可能である。メモリにマッピングされるＩ／Ｏレジスタへのカーネルのアクセス（例えば、ＰＣＩバス上で）は、上述のＭＭＵマッピングを介して制御される。デフォルトでは、全てのこのようなアクセスは、使用不能にされ、しかし、アイソレータは、カーネルに所定のＩ／Ｏ範囲をその仮想空間にマッピングさせることが出来る。これにより、アイソレータの上部でネイティブ・デバイス・ドライバを実行することが可能になる。デバイスに関するいくつかの要件は、システムの完全性及び可用性を危険にさらさないために満たされるべきである。さらに、アイソレータは、カーネルにいくつかの仮想デバイスを提供する。このような仮想デバイスは、一般に、チック・タイマ等の必須システム・デバイスに取って代わる。
【０１１５】
安全化仮想デバイス  
アイソレータで実行されるバックエンド仮想デバイス・ドライバは、信頼性領域の外側で実行される基本ゲストＯＳカーネルへの仮想デバイス・インターフェースを提供する。この仮想デバイスは、この仮想デバイス・インターフェースのために専用に開発されるゲストＯＳフロントエンド・ドライバによって管理される。安全な実行環境を提供するために、リナックス・カーネルによって所有されない物理メモリへのアクセスを禁止するために、アイソレータ・バックエンド・ドライバは、ゲストＯＳフロントエンド・ドライバから入って来る全ての要求を確認する。アイソレータ・バックエンド・ドライバの実装は、プライマリ・パーティションで実行される「信頼性実行機関」のバックエンド・ドライバに接続されるアイソレータ・フロントエンド・ドライバに基づく。「信頼性実行機関」のバックエンド・ドライバは、基本ハードウェアにアクセスするために実デバイス・ドライバを使用する。
【０１１６】
「信頼性実行機関」のバックエンド及びアイソレータのフロントエンド・ドライバの連携は、現在のデバイス状態を維持するために共有デバイス記述子を一般的には使用し、一方でパーティション間割り込みは、デバイス状態の変化を信号で伝えるために通常使用される。仮想バス上のデバイス固有プロトコルはまた、パーティション上でペイロード・データを転送するために使用されてもよい。
【０１１７】
所与のバックエンド・ドライバからの所与の物理デバイスへのアクセス権は、「信頼性実行機関」のセキュリティ・エージェントにより制御される。
【０１１８】
実デバイス  
ＩＳＡ又はＰＣＩバスのどちらかに存在する実Ｉ／ＯデバイスへのゲストＯＳのアクセスは、アイソレータによって可能にされ得る。さらに、仮想化ハードウェア割り込みは、専用イベント・チャネル上でゲストＯＳカーネルに送られ得る。よって、理論上、アイソレータの上部で実Ｉ／Ｏデバイスのためにネイティブ・ドライバを実行することが可能である。しかし、実際には、このようなドライバのほとんどは、信頼性システムの完全性及びセキュリティを共に危険にさらすであろう。このようなドライバに関連する２つの潜在的な問題が存在する。
【０１１９】
第１に、デバイスは、非常に多くのハードウェア資源を消費することにより通常のシステム動作を混乱させるようにプログラムされ得る。一般に、プロセッサ割り込みとバス・トランザクションという、デバイスによって使用される２種類のハードウェア資源が存在する。誤ってプログラムされたデバイスは、高頻度（又はスタック）割り込みを生成する可能性があり、且つこれは同一の割り込み回線を共有する他のデバイスを混乱させ得る。さらに、保留の割り込みは、ドライバによって確認されることが出来ず（従って、再度使用可能にされず）、且つこれは、この回線上の任意の将来の割り込みがプロセッサに送られることを妨げるであろう。デバイスが、バス上でマスタ能力を有する場合、基本バス上で非常に多くのトランザクションを生成するために誤ってプログラムされて、他のピア・デバイスを混乱させ得る。後者の場合は、バス・アービタ規定を制御させるいくつかのバス上で妨げられ得る。
【０１２０】
第２に、デバイスが、直接メモリ・アクセス（ＤＭＡ）可能である場合、デバイスは、バスからアクセス可能な任意の物理メモリへ／からＩ／Ｏ転送を実行するようにプログラムされ得る。通常、全ての物理メモリは、ＤＭＡ転送のためにＩ／Ｏバスからアクセス可能である。よって、このような機能は、システムの完全性（信頼性領域に属する物理メモリは、ＤＭＡを使用するドライバによって破損され得る）だけでなく、システムのセキュリティ（信頼性領域に属する物理メモリは、ＤＭＡを使用するドライバによって読み取られ得る）をも危険にさらす。
【０１２１】
従って、信頼性システムの完全性及びセキュリティを危険にさらさないために、デバイスの性質が以下の要件に適合しさえすれば、アイソレータは、信頼性領域の外側の実Ｉ／Ｏデバイスへのアクセスを許容することが出来る。  
−  デバイスが、割り込みを全く使用しないか、或いはデバイスによって使用される割り込みが全て排他的である
−  デバイスが、バス上でマスタとして動作できない
【０１２２】
最後の要件は、全てのＤＭＡ可能デバイスを自動的に除外する。
【０１２３】
安全化共有デバイス・ドライバ  
セキュリティの重要なデバイスは、信頼性デバイス・ドライバを使用して管理される。ワークステーション環境では、信頼性デバイスは、基本的に４つのグループに分けられ得る。  
−  ヒューマン・インターフェース・デバイス
−  ネットワーク・デバイス
−  記憶デバイス
【０１２４】
安全化ヒューマン・インターフェース・デバイス  
以下の入力ヒューマン・デバイスは、本発明の実施形態によってサポートされる。
【０１２５】
−  キーボード（ＰＳ／２及びＵＳＢ）
−  ポインタ（ＰＳ／２及びＵＳＢ）
【０１２６】
ヒューマン出力デバイスとして、「信頼性実行機関」は、ＶＧＡ及びＶＥＳＡモードでグラフィック・アダプタをサポートする。
【０１２７】
信頼性システムは、システムのセキュリティ及び完全性を危険にさらすことなく、ユーザがパーティション間でヒューマン・インターフェース・デバイスを動的に切り替えることを可能にする。一般に、切り替えコマンドは、規定の順序のスキャン・コードとしてキーボードから入り、且つ全てのヒューマン・インターフェース・デバイスは、通常は同時に切り替えられる。信頼性システムにおいて、ヒューマン・インターフェース・デバイスは、セキュリティ上重要であり、従ってドライバによって信頼性領域において管理される。ゲストＯＳからこうしたデバイスをアクセス可能にするために、信頼性アーキテクチャは、デバイスを仮想化して、各々、プライマリ・パーティション及びゲストＯＳ（セカンダリ・パーティション）で実行される１組のフロントエンド及びバックエンド・ドライバを提供する。こうしたドライバは、上述の安全化仮想化スキーマに従う。特に、仮想化入力データ経路は、このような仮想化デバイスを安全な態様でゲストＯＳに提供する「信頼性実行機関」の中間フロントエンド及びバックエンド・ドライバを通過する。
【０１２８】
キーボード及びマウスは、プライマリ・パーティションのバックエンド・ドライバによって、主に管理され、且つ入力は、ヒューマン・インターフェース・デバイスを現在所有しているパーティションで実行されるプライマリ・パーティションのアプリケーション又は仮想フロントエンド・ドライバのどちらかにルーティングされる。
【０１２９】
ゲストＯＳの視点から、全てのヒューマン・インターフェース・デバイスは、現時点においてパーティションによって所有されていない場合であっても、常に存在し且つ動作可能である。言うまでも無く、入力デバイスは、切断状態において如何なる入力も提供しない。他方で、ディスプレイ上での出力を妨げることが不可能であるので、フレーム・バッファ・メモリは、切断状態であっても常にビデオ・ドライバに利用可能であるべきである。
【０１３０】
安全なデバイス共有の例  
図１０−１２は、本発明の実施形態による安全なデバイス共有の例を示す。特に、図１０は、安全な映像共有の例を示す。図１１は、安全なディスク共有の例を示す。図１２は、安全なネットワーク共有の例を示す。
【０１３１】
安全化仮想キーボード及びマウス  
図８は、仮想キーボードが、その個々のパーティションにおいて実行される各ゲストＯＳに提供される方法を例示する。
【０１３２】
仮想キーボード・モジュール（ＶＫＢＤ）は、物理キーボード・インターフェースを管理する低レベル・ドライバの上部で実行される。この低レベル・ドライバは、ＶＫＢＤにキーボード・インターフェースへ／からスキャン・コードを送信／受信させる。各パーティション（プライマリ・パーティションを含む）に対して、ＶＫＢＤは、キーボード・プロトコル・エミュレーション・エンジンを提供する。このようなエンジンは、ゲストＯＳにより発行される構成コマンドでＰＳ／２キーボード応答をエミュレートする。
【０１３３】
さらに、エミュレーション・エンジンは、仮想キーボード状態を保存するために全ての受信構成コマンドを記憶する。キーボードが、一方のパーティションから他方のパーティションに切り替えられる場合、エミュレーション・エンジンは、キーボード物理状態を仮想状態に従って設定する。このような同期化を実行するために、物理キーボードを初期化して、次に以前に記憶された構成コマンドをキーボードに再送信する。
【０１３４】
一度に１つのエミュレーション・エンジンのみが、物理キーボードに接続される。このような起動エンジンは、オペレーティング・システムから受信される構成コマンドを記憶するだけでなく、いくつかのコマンドを物理キーボードに転送する。キーボードの可用性を危険にさらし得るいくつかの構成コマンド（例えば、キーボード無効コマンド）は取り除かれ、且つ物理キーボードに転送されることは無い。その代わり、このようなコマンドは、ゲストＯＳの適切な確認コードに応答し、且つ仮想キーボード状態をそれに従って変更するために仮想的に実行（すなわち、エミュレート）される。
【０１３５】
入力について、起動エンジンによって物理キーボードから受信される任意のスキャン・コードは、通常、ゲストＯＳに送り返される。言うまでも無く、起動していないエンジンは、その関連付けられるゲストＯＳに如何なる入力スキャン・コードも報告しない。言い換えれば、起動していない状態では、仮想キーボードのキーが押されることは無い。
【０１３６】
専用のシリアルＩ／Ｏフロントエンド・ドライバが、各ゲストＯＳカーネルに仮想キーボードを接続するために提供される。各ドライバは、ゲストＯＳカーネルの上位層に標準的なシリアルＩ／Ｏインターフェース（例えば、ＡＴキーボード・モジュール）を提供して、キーボードの仮想化機構を透過的にする。
【０１３７】
シリアルＩ／Ｏフロントエンド・ドライバは、シリアルＩ／Ｏバックエンド／フロントエンド・ピア・ドライバによって確立されるチャネル上で、順にＶＫＢＤと通信するアイソレータのバックエンド・ドライバと通信する。言い換えれば、アイソレータは、信頼性の、バーチャライザベースの、シリアルＩ／Ｏ通信チャネルの上部でゲストＯＳカーネルに安全なシリアルＩ／Ｏインターフェースを提供する。
【０１３８】
一方のパーティションから他方へヒューマン・インターフェース・デバイス（ＨＩＤ）を切り替えるために、ＶＫＢＤは、規定のコード順序を入力スキャン・コードと比較する。一致が検出されると、物理キーボードは、現在のエミュレーション・エンジンを停止することにより且つキーボードを所有するパーティションに対応するエミュレーション・エンジンを起動することにより切り替えられる。さらに、システム全体のＨＩＤ＿ＳＷＩＴＣＨイベントがブロードキャストされる。このイベントは、同一のパーティションに切り替えることによってキーボードに従うために、ＨＩＤ仮想化ドライバ（マウス及び映像）により受信される。このような方法で、全てのＨＩＤが互いに切り替えられ、且つ切り替えはＶＫＢＤによって駆動される。
【０１３９】
マウス・デバイスの仮想化アーキテクチャは、キーボードのそれに非常に類似している。主な相違は、仮想マウス・モジュール（ＶＭＯＵＳＥ）が、基本ＰＳ／２マウス・プロトコルの複数の拡張機能をサポートすることである。初期化時において、ＶＭＯＵＳＥは、利用可能なマウスの拡張機能を検出するために、物理マウス・デバイスを調査する。調査結果によっては、マウス・プロトコル・エミュレーション・エンジンは、次に、物理マウス・デバイス上で利用可能な拡張機能のエミュレーションを開始する。
【０１４０】
安全化仮想ＶＧＡ  
図９は、仮想ＶＧＡがそれ自身のパーティションで実行される各ゲストＯＳに提供される方法を例示する。
【０１４１】
仮想ＶＧＡモジュール（ＶＶＧＡ）が、プライマリ・パーティション及び各アイソレータ・インスタンスで実行されている。ＶＶＧＡの主要タスクは、ゲストＯＳアクセスを物理ＶＧＡハードウェア（レジスタ及びメモリ）又はそのシャドウ・イメージのどちらかにルーティングすることである。ＶＶＧＡインスタンスが起動している（例えば、それが物理ＶＧＡハードウェアに接続される）場合、対応ゲストＯＳは、ＶＧＡメモリ及びレジスタに直接アクセスする。或いは、ＶＧＡインスタンスが起動していない場合、ゲストＯＳアクセスは、シャドウ・メモリ・イメージにリダイレクトされる。
【０１４２】
言い換えれば、ＶＶＧＡは、物理ＶＧＡが対応ゲストＯＳから切断されるときに使用される仮想ＶＧＡコントローラを管理する。
【０１４３】
物理ＶＧＡが、ゲストＯＳによって確保される場合、ＶＶＧＡは、物理ＶＧＡコントローラを仮想のものと同期化し、ＶＧＡハードウェアへの直接アクセスを可能にする。物理ＶＧＡが、ゲストＯＳによって解放されるとき、ＶＶＧＡは、仮想ＶＧＡコントローラを物理のものと同期化し、且つ任意の追加のアクセスをシャドウＶＧＡレジスタ及びメモリにリダイレクトして対応ゲストＯＳからＶＧＡハードウェアに直接アクセスが行われることを妨げる。
【０１４４】
ＶＶＧＡモジュールは、ＶＧＡハードウェア抽象化層インターフェース（ＨＡＬ）を上位層ソフトウェア、特にＶＧＡドライバに提供する。ＶＧＡレジスタへの全てのアクセスは、こうしたアクセスを物理ＶＧＡレジスタ又はシャドウ・レジスタのどちらかにルーティングするＶＶＧＡのＶＧＡ  ＨＡＬインターフェースを介して実行される。
【０１４５】
ＶＧＡメモリはまた、その仮想基準アドレスをエクスポートするＶＧＡ  ＨＡＬインターフェースの役割も果たす。同一の仮想アドレスを保持して、ＶＶＧＡは、ＶＧＡハードウェア所有者により物理ＶＧＡ又はシャドウ・メモリのどちらかをこうした仮想アドレスに再マッピングする。
【０１４６】
ゲストＯＳ側では、ＶＶＧＡドライバが、アイソレータによって提供される。ネイティブ（非修正）ＶＧＡコンソール・ドライバは、ゲストＯＳカーネルで実行されている。ゲストＯＳのＶＧＡコンソール・ドライバは、ＶＧＡレジスタにアクセスするためにイン／アウト命令を発行し、ＶＧＡプレーンにアクセスするためにＶＧＡ物理メモリをカーネル仮想空間にマッピングする。アイソレータは、ゲストＯＳカーネルが実行されているリング１からのＶＧＡポートへのアクセスを無効化する。よって、ゲストＯＳのＶＧＡコンソールによって発行されるイン／アウト命令は、アイソレータによって決定される一般保護違反を生ずる。一般保護違反ハンドラの内部で、ＶＶＧＡドライバは、ＶＧＡハードウェア所有者により物理ＶＧＡレジスタ又はそのシャドウ・イメージのどちらかを使用してこのような違反命令をエミュレートする。命令がエミュレートされると、ゲストＯＳコードの実行は継続される。
【０１４７】
ＶＶＧＡは、通常のＲＡＭ内にシャドウ映像メモリ・バッファを保持する。ＶＧＡビデオ・メモリは、ＶＧＡハードウェアがパーティションによって所有されないときに、シャドウ・レジスタによって置換される。このような置換は、ゲストＯＳのＶＧＡコンソール・ドライバに透過的である。
【０１４８】
パーティションをＶＧＡハードウェアから切断する場合、ＶＧＡ映像メモリの代わりにシャドウ・メモリ・バッファをマッピングするために、アイソレータは、ＭＭＵ変換ツリーを修正し、且つ映像メモリは、シャドウ・バッファにコピーされる。接続が回復すると、アイソレータは、ＶＧＡ映像メモリへＭＭＵ変換を復元し、且つシャドウ・バッファを映像メモリにコピーする。これは、アイソレータにおいて、ゲストＯＳによって確立される全てのＭＭＵ変換をＶＧＡ映像メモリに追跡記録することを必要とする。
【０１４９】
一般に、ＶＧＡコントローラでの単一の動作は、異なるＶＧＡレジスタへ行われる複数のアクセスを必要とする。１つの例は、パレット・データ・レジスタ（読取り用に、それぞれ緑及び青の色値）への３つの後続の書き込みアクセスが続かなければならないパレット・インデックス・レジスタに行われる１つの書き込みアクセスを必要とするＶＧＡ  ＤＡＣカラー・パレット更新である。ＶＧＡ切り替えは、カラー・パレットを保存／復元し、従ってＶＧＡ  ＤＡＣ状態マシンを初期化するので、ＶＧＡハードウェアがこのような更新の最中に切り替えられ得ないということが理解されるべきである。
【０１５０】
より一般的には、ＶＧＡコントローラは、有限状態マシンであり、且つＶＧＡハードウェアは、所定の状態において正確に切り替えることが出来ない。このようなＶＧＡマシン状態遷移の状態及び他の全ての状態は、「最終状態」とみなされてもよい。従って、ＶＧＡコントローラは、最終状態に置いて一方のパーティションから他方へのみ切り替えられ得る。ＶＧＡマシンの最終状態だけが、ＶＧＡコントローラが正確に保存され且つ復元されることを可能にする。
【０１５１】
従って、ＶＶＧＡは、ＶＧＡレジスタのトランザクションの更新を実行する。このような技術は、最終状態に到達するまで、ＶＧＡレジスタへのアクセスを延期することに存する。ＶＧＡマシンが最終状態にある場合、ＶＶＧＡは、ＶＧＡコントローラへの全ての延期アクセスを自動的に、すなわちＶＧＡ切り替えが無効化されるコードの重要部分内で発行する。
【０１５２】
上記の所与のカラー・パレットの例において、ＶＧＡマシンの最終状態は、最後の青色がパレット・データ・レジスタに書き込まれるときに到達される。３つの先行する書き込みアクセス（パレット・インデックス、赤及び緑色）は、ＶＧＡマシンの遷移状態である。上記の遷移技術に従って、青色の書き込みが傍受されると、ＶＶＧＡは極小の１回で適切なＶＧＡ  ＤＡＣパレット・カラー・レジスタを更新して、コードの重要部分内でＶＧＡレジスタへの４つの後続の書き込みアクセスを発行する。
【０１５３】
１方のパーティションから他方へのＶＧＡハードウェアの切り替えは、アイソレータの上部で実行されるＶＧＡバックエンド／フロントエンド・ピア・ドライバを使用してＶＶＧＡモジュールにより調整される。ＫＢＤ＿ＳＷＩＴＣＨイベントが、ＶＶＧＡモジュールによって受信されると、仮想ＶＧＡ切り替え処理は、以下のステップを経由する。  
−  ＶＧＡコントローラの状態（メモリ・プレーン及びレジスタ）が、現在のＶＧＡ所有者のシャドウ・データ構造に保存される。  
−  ＶＧＡ＿ＲＥＬＥＡＳＥイベントが、現在のＶＧＡ所有者に送信される。このようなイベントを受信すると、現在のＶＧＡ所有者は、上述のように、シャドウＶＧＡに切り替わる。
【０１５４】
−  ＶＧＡコントローラの状態（メモリ・プレーン及びレジスタ）は、新しいＶＧＡ所有者のシャドウ・データ構造から復元される。
【０１５５】
−  ＶＧＡ＿ＡＣＱＵＩＲＥイベントが、ＶＧＡ所有者に送信される。このようなイベントを受信すると、新しいＶＧＡ所有者は、上述のように、物理ＶＧＡに切り替わる。
【０１５６】
安全化仮想ＶＥＳＡ  
図１０を参照すると、仮想ＶＥＳＡが、それ自身のパーティションで実行される各ゲストＯＳに提供される。
【０１５７】
仮想ＶＥＳＡモジュール（ＶＶＥＳＡ）は、プライマリ・パーティション及び各アイソレータ・インスタンスにおいて実行されている。ＶＶＥＳＡの主要タスクは、物理映像メモリ又はそのシャドウ・イメージのどちらかにゲストＯＳアクセスをルーティングすることである。ＶＶＥＳＡインスタンスが、起動している（すなわち、グラフィック・アダプタに接続される）場合、対応ゲストＯＳは、映像メモリに直接アクセスする。或いは、ＶＶＥＳＡインスタンスが起動していない場合、ゲストＯＳアクセスは、映像メモリのシャドウＲＡＭイメージへリダイレクトされる。
【０１５８】
言い換えれば、ＶＶＥＳＡは、グラフィック・アダプタが対応インスタンスから切断されるときに使用されるシャドウ映像メモリを管理する。
【０１５９】
グラフィック・アダプタが、インスタンスによって確保される場合、ＶＶＥＳＡは、物理映像メモリをシャドウのものと同期化し、且つグラフィック・アダプタの映像メモリへの直接アクセスを可能にする。グラフィック・アダプタが、インスタンスにより解放される場合、ＶＶＥＳＡは、シャドウ映像メモリを物理のものと同期化し、且つシャドウ映像メモリに任意の追加のアクセスをリダイレクトし、直接アクセスが、グラフィック・アダプタの映像メモリの対応インスタンスから行われることを妨げる。
【０１６０】
ＶＶＥＳＡドライバは、アイソレータによって各ゲストＯＳに提供される。ＶＶＥＳＡは、通常のＲＡＭ内のシャドウ映像メモリ・バッファを管理する。物理映像メモリは、グラフィック・アダプタがパーティションによって所有されないときに、シャドウ・メモリによって置換される。このような置換は、ゲストＯＳ映像ドライバに透過的である。
【０１６１】
パーティションからグラフィック・アダプタを切断すると、アイソレータは、物理映像メモリに代えてシャドウ映像メモリをマッピングするために、ＭＭＵ変換ツリーを修正し、且つ映像メモリは、シャドウ・バッファにコピーされる。接続が回復すると、アイソレータは、ＭＭＵ変換を物理映像メモリに記憶し、且つシャドウ・バッファを映像メモリにコピーする。これは、アイソレータにおいて、ゲストＯＳ映像ドライバによって確立される全てのＭＭＵ変換をグラフィック・アダプタ映像メモリに追跡記録することを必要とする。
【０１６２】
専用のフレーム・バッファのフロントエンド・ドライバは、仮想ＶＥＳＡをゲストＯＳカーネルに接続するために各ゲストＯＳに提供される。ドライバは、標準フレーム・バッファ・デバイス・ドライバのインターフェースをゲストＯＳカーネル・モジュール（例えば、フレーム・バッファ・コンソール）及びユーザ空間アプリケーション（例えば、Ｘ１１  ｆｂｄｅｖドライバ）に提供して、映像仮想化機構を透過的にする。
【０１６３】
ゲストＯＳフレーム・バッファのフロントエンド・ドライバは、バーチャライザの上部で実行されるＶＥＳＡバックエンド／フロントエンド・ピア・ドライバによって確立される回線上で、同様にＶＶＥＳＡと通信するアイソレータのバックエンド・ドライバ上でＶＶＥＳＡと通信する。
【０１６４】
ＶＢＥドライバを実行するために設けられる、いわゆるＶＥＳＡ  ＢＩＯＳエクステンション（ＶＢＥ）と呼ばれる特別なパーティションが存在する。このようなＶＢＥドライバは、アイソレータの上部で実行され、且つその主要な役割は、グラフィック・アダプタに存在するＰＲＯＭに設置される映像ＢＩＯＳコードを呼び出すために必要な実行環境を生成することである。
【０１６５】
一般的なＶＢＥインターフェースは、グラフィック・アダプタが、画面解像度及び色の深みにおいて異なる様々なＶＥＳＡモードで構成されることを許容する。ＶＢＥ３．０インターフェースは、アイソレータによって直接サポートされるインテルＩＡ−３２保護モードにおける映像ＢＩＯＳコードの実行を可能にする。映像ＢＩＯＳコードは、信頼性システムのセキュリティ及び完全性を危険にさらすことなく、信頼性領域の外側のＣＰＵによって直接に実行され得る。実際に、映像ＢＩＯＳコードは、ゲストＯＳカーネル・コードと同じ条件の下で実行されている。特に、映像ＢＩＯＳコードは、（保護）プロセッサのリング１で実行されている。
【０１６６】
ＶＢＥフロントエンド／バックエンド・ピア・ドライバは、プライマリ・パーティションからＶＢＥドライバへの遠隔インターフェースを提供する。このインターフェースは、グラフィック・アダプタを所有する仮想ＶＥＳＡインスタンスによって必要とされる映像モードにグラフィック・アダプタを構成するためにＶＶＥＳＡドライバによって排他的に使用される。
【０１６７】
グラフィック・アダプタ切り替えは、バーチャライザの上部で実行されるＶＥＳＡ及びＶＢＥバックエンド／フロントエンド・ピア・ドライバを使用して、ＶＶＥＳＡモジュールによって調整される。ＫＢＤ＿ＳＷＩＴＣＨイベントがＶＶＥＳＡモジュールによって受信されると、仮想ＶＥＳＡ切り替え処理は、以下のステップを経由する。  
−  映像メモリが、現在のグラフィック・アダプタの所有者のシャドウ・バッファに保存される。
【０１６８】
−  ＶＶＥＳＡ＿ＲＥＬＥＡＳＥイベントが、現在のグラフィック・アダプタ所有者に送信される。このようなイベントを受信すると、現在のグラフィック・アダプタ所有者は、上述のように、シャドウ映像メモリに切り替わる。
【０１６９】
−  グラフィック・アダプタの映像モードは、必要に応じて変更される。
【０１７０】
−  映像メモリが消去される。
【０１７１】
−  ＶＢＥバックエンド・ドライバを実行するパーティションが、再開される。
【０１７２】
−  映像モードが変更されると、ＶＢＥパーティションが一時停止される。
【０１７３】
−  映像メモリが、新しいグラフィック・アダプタ所有者のシャドウ・バッファから復元される。
【０１７４】
−  ＶＶＥＳＡ＿ＡＣＱＵＩＲＥイベントが、新しいグラフィック・アダプタ所有者に送信される。このようなイベントを受信すると、新しいグラフィック・アダプタ所有者は、上述のように、グラフィック・アダプタ映像メモリに切り替わる。
【０１７５】
安全化仮想ネットワーク  
図１３は、仮想イーサネット（登録商標）・リンクが、それ自身のパーティションで実行される個々のゲストＯＳごとに提供される方法を例示する。
【０１７６】
「信頼性実行機関」において及び各ゲストＯＳにおいて実行される仮想イーサネット（登録商標）・ドライバを使用して、仮想イーサネット（登録商標）・リンクが、個々のゲストＯＳごとに提供され得る。仮想イーサネット（登録商標）・リンクが、仮想ネットワーク・インターフェースを介してリナックス・カーネルに接続される。
【０１７７】
バーチャライザは、仮想イーサネット（登録商標）・リンク・インターフェースを安全な仮想ネットワーク・インターフェースに変換する接着層を提供する。
【０１７８】
多くの独立イーサネット（登録商標）・リンクが生成されて、既定の組のゲストＯＳ（すなわち、リナックス・インスタンス）を接続することが出来る。一般的な信頼化構成において、イーサネット（登録商標）・リンクは、「信頼性実行機関」と各リナックス・インスタンスとの間のピア・ツー・ピア接続を提供するために使用される。次に、仮想イーサネット（登録商標）・インターフェースが、「信頼性実行機関」の物理イーサネット（登録商標）・コントローラにブリッジされる。
【０１７９】
このようなイーサネット（登録商標）・ブリッジは、ブリッジ化仮想イーサネット（登録商標）・インターフェースごとに（すなわち、一般的な信頼化構成のゲストＯＳごとに）１つのスレッドが生成される、マルチスレッド・サーバである。イーサネット（登録商標）・ブリッジは、それらに関係付けられるセカンダリ・パーティションの優先順位を反映させるために、システム管理者が、このようなサーバ・スレッドの優先順位を設定することを可能にする。
【０１８０】
安全化仮想ブロック・デバイス
図１４は、仮想ブロック・デバイスが、それ自身のパーティションにおいて実行される各ゲストＯＳに提供される方法を例示する。
【０１８１】
仮想ディスク・モジュール（ＶＤＩＳＫ）が、低レベルＡＴＡディスク・ドライバの上部で実行されている。遠隔ブロック・デバイスのバックエンド／フロントエンド・ピア・ドライバを使用して、仮想ブロック・デバイスが、それ自身のパーティションで実行される個々のゲストＯＳごとに提供され得る。遠隔ブロック装置は、仮想ブロック・デバイスのインターフェースを介してリナックス・カーネルに接続される。バーチャライザは、遠隔ブロック・デバイスのインターフェース（信頼性領域の「信頼性実行機関」の上部で直接実行される）を変換する接着層を安全な仮想ブロック・デバイスのインターフェースに提供する。
【０１８２】
ＶＤＩＳＫは、仮想ビューを物理ディスク・パーティションに提供するために設定される。基本的に、各物理ディスク・パーティションは、所与のオペレーティング・システムから隠されるか、読み取り／書き込み若しくは読み取り専用モードでアクセス可能であり得る。さらに、複数のディスク・パーティション（異なるディスク上の可能性がある）は、単一の仮想ブロック・デバイスを提供するために結合され得る。
【０１８３】
図１４は、４つの物理ディスク・パーティションが、２つのゲストＯＳにエクスポートされる場所の例を示す。第１のゲストＯＳは、／ｄｅｖ／ｈｄａ１及び／ｄｅｖ／ｈｄａ２のリナックス・デバイスに１対１でマッピングされる２つのプライマリ・ディスク・パーティションにのみアクセスすることが出来る。全ての他の物理ディスクは、第１のオペレーティング・システムから隠される。第２のオペレーティング・システムは、／ｄｅｖ／ｈｄａ１及び／ｄｅｖ／ｈｄａ２のリナックス・デバイスにマッピングされる２つの論理（拡張）ディスク・パーティションにのみアクセスすることが出来る。他の全ての物理ディスク・パーティションは、第２のオペレーティング・システムから隠される。この例では、ゲストＯＳは共に、物理的に別個のディスク・パーティションに同一の仮想ビューを有する。
【０１８４】
ＶＤＩＳＫは、ゲストＯＳごとに１つのスレッドが生成されるマルチスレッド・サーバである。ＶＤＩＳＫは、システム管理者に、このようなサーバ・スレッドの優先順位を設定させて、それらに関係付けられるセカンダリ・パーティションの優先順位を反映する。
【０１８５】
仮想化使用事例  
図１５から２５は、本発明の実施形態による仮想化使用事例を示す。図１５は、一般に、本発明の実施形態による同一のハードウェア・プラットフォーム上でのオープン及びクローズの実行環境の共存を例示する。
【０１８６】
図１６は、信頼性領域からネットワーク・アクセスを制御するセキュリティ・ファイアウォールを備える使用事例を示す。この実施形態は、以下の特徴を備える。  
−  ネットワーク・アクセスは、フィルタ処理ソフトウェアを実行する信頼性パーティションで実行される
−  リナックスとＱＴｏｐｉａ電話版は、直接のネットワーク・アクセスを有しないサンドボックス化コンテナで実行される
−  ファイアウォール  
−  リナックス／アプリケーションをネットワークから入ってくるマルウェアから保護する
−  リナックス／アプリケーションのマルウェアがネットワークにアクセスするのを防ぐ
−  システム監視は、リナックスの故障時に音声用のサービスの継続を維持する。「ＯＳ監視」は、リナックスを監視して、それが動作しており且つ危険にさらされていないことを確認する
−  ＲＴＯＳがまだ緊急ダイアル装置を介して音声呼出の受信及び呼出を許容する一方で、「ＯＳ監視」は、自動的にリナックスを再起動する
−  「ＯＳ監視」は、管理サーバに報告し、且つ必要に応じて段階的に増大する。
【０１８７】
図１８は、信頼性領域からＶｏＩＰ及びセキュリティ・ファイアウォール・サービスを提供するための使用事例を示す。この実施形態は、以下の特徴を備える。
【０１８８】
−  ＶｏＩＰサービス・エージェントは、アプリケーションＯＳがオーバーロード又はクラッシュする場合にサービスの質を保証するために、主要「アプリケーションＯＳ」から独立した「サービスＯＳ」上で実行される
−  セキュリティ・ファイアウォール・サービスは、デバイスに行き且つデバイスから入ってくるマルウェアからデバイス及びネットワークを共に保護するために、「サービスＯＳ（ＶｏＩＰサービスとは異なる可能性がある）」上で実行される
−  セキュリティ・ファイアウォールが、ユーザとは独立して、遠隔セキュリティ管理コンソールからプロビジョニングされ、設定され且つ制御される
図１９は、例えばＰＩＮコードを入力するために、信頼性領域からユーザとの安全な相互作用を提供するための使用事例を示す。
【０１８９】
図２０は、標準領域と信頼性領域との間を切り替える安全なユーザＩ／Ｏに関する使用事例を示す。
【０１９０】
図２１は、クローズ・パーティションにおいて、すなわちネットワーク又は記憶装置へのアクセス無しで、復号化ＤＲＭ保護コンテンツを表示するための使用事例を示す。
【０１９１】
図２２は、異なる周辺デバイス・アクセス及び信頼実行レベルで複数のパーティションを使用する、ユーザに再生される前の、ＤＲＭ保護コンテンツの完全なデータ経路を例示する。
【０１９２】
図２３は、信頼性領域からＶｏＩＰ及びＷｉＦｉサービスへのアクセスを制御するための使用事例を示す。
【０１９３】
図２４は、信頼性領域からのハードウェア／ソフトウェア・プラットフォームを管理するための使用事例を示す。この実施形態は、以下の特徴を備える。  
−  アプリケーションＯＳから分離されて、管理エージェントが「信頼性ＳＷコンテナ」で実行される。  
−  ＯＳスタックの監視及び制御：ＳＷ監視機構、「ホット・リスタート」
−  プロビジョニング、設定、再設定
−  更新、パッチあて、故障時における以前のバージョンへのフォール・バックを有するＯＳ更新
−  事故処理及び管理サーバへの報告
−  安全な認証及び管理機能の動作
【０１９４】
−  管理サーバが、以下のために管理エージェントと相互作用する。  
−  電話ＯＳ及びアプリケーションＳＷのプロビジョニング、設定、再設定
−  デバイスの適切な安全規定の保証
図２５は、信頼性領域からユーザ・プロンプトを処理するための使用事例を示す。この実施形態は、以下の特徴を備える。  
−  リナックス・アプリケーションから発生する呼出／ＳＭＳが、ユーザによって安全に調査され且つ確認される
−  不正使用が制御され且つロギングされ、並びに管理サーバへの警告が生成される。
【０１９５】
以下において、この安全なアーキテクチャによって提供されるアイソレーションが、ＤＲＭ及びＳＭＳ／呼出制御と関連してより詳細に記載される。
【０１９６】
ＤＲＭ及びＳＭＳ／呼出制御
本発明のこの実施形態は、携帯電話アーキテクチャの信頼性及び標準（「オープン」）領域の分離に属する。オープン領域で実行されるアプリケーションは、デジタル著作権管理（ＤＲＭ）に従うデータのダウンロードを含んでもよい。しかし、ダウンロードされたデータにアクセスするための動作は、信頼性領域においてのみ実行されてもよい。それにより、例えば非承認コピーによる、ダウンロードされたデータの潜在的な不正使用が、防止される。より詳細には、ダウンロードされたデータは、デジタル画像から構成されてもよい。画像の表示は、オープン領域内から制御されるスクリーンから信頼性領域内から制御されるスクリーンへのディスプレイ・スクリーンの切り替えを備えてもよい。画像表示が終了すると、スクリーン制御は、元のようにオープン領域に切り替えられる。このようにして、画像データは、オープン領域の如何なるキャッシュ又はスクリーン・メモリ（例えば、ＤＲＭ保護を回避するためにそれがコピーされる可能性がある）にも記憶されない。
【０１９７】
別の実施形態において、携帯電話のオープン領域で実行されるアプリケーションは、ユーザにテキスト・メッセージを送信し又は電話呼出を開始するように促してもよい。この場合において、テキスト・メッセージの送信又は電話呼出の開始を（手動で）確認するように携帯電話のユーザに促すために、使用制御は、オープン領域から信頼性領域へと渡される。それにより、ユーザは、望ましくないテキスト・メッセージを送信し又は望ましくない電話呼出を開始することから保護され、又は少なくともこのようなテキスト・メッセージ又は呼出と関係付けられる費用を知ることが出来る。
【０１９８】
信頼性領域において、リアルタイム・オペレーティング・システム（ＲＴＯＳ）及びセキュリティ・エージェントは、携帯電話のコア及びセキュリティ関連のアプリケーションを実行する。オープン領域において、オープン・オペレーティング・システム（オープンＯＳ）は、例えば映像及び音声データのダウンロード等のユーザ相互作用アプリケーションを実行する。
【０１９９】
バーチャライザは、例えば、図２１、２２及び２５に示されるように、オープン及び信頼性領域間で制御を渡す。
【０２００】
図２１は、オープン領域において実行されるアプリケーションによってダウンロードされた映像データを表示するために、オープン領域から信頼性領域へと制御プログラムが制御を渡す実施形態を例示する。そうすることで、表示制御は、オープン領域から信頼性領域へと切り替えられる。映像データの表示が終了すると、表示制御は、元のようにオープン領域に渡される。結果として、表示映像データは、オープン領域の如何なるスクリーン・メモリ又はキャッシュ（より簡単にアクセスされる可能性がある）にも含まれず、こうしてデータの非承認の使用及びＤＲＭの不正使用を防ぐ。
【０２０１】
図２５は、オープン領域で実行される相互作用アプリケーション内からのテキスト・メッセージの送信を確認するようにユーザに促すために、制御プログラムが、オープン領域から信頼性領域へと制御を渡す実施形態を例示する。それにより、ユーザは、オープン領域で実行されるアプリケーションによって生成されるテキスト・メッセージを意図せずに送信することから保護され、又は少なくともそのこと及びこのような行動の費用を知る。
【０２０２】
他の側面及び実施形態  
以上より、上述の実施形態は例示に過ぎず、他の実施形態が請求項から決定される発明の範囲内で可能であり且つ含まれることが明らかであろう。
【図１】
2010514028.tif 000003
【図２】
2010514028.tif 000004
【図３】
2010514028.tif 000005
【図４】
2010514028.tif 000006
【図５】
2010514028.tif 000007
【図６】
2010514028.tif 000008
【図７】
2010514028.tif 000009
【図８】
2010514028.tif 000010
【図９】
2010514028.tif 000011
【図１０】
2010514028.tif 000012
【図１１】
2010514028.tif 000013
【図１２】
2010514028.tif 000014
【図１３】
2010514028.tif 000015
【図１４】
2010514028.tif 000016
【図１５】
2010514028.tif 000017
【図１６】
2010514028.tif 000018
【図１７】
2010514028.tif 000019
【図１８】
2010514028.tif 000020
【図１９】
2010514028.tif 000021
【図２０】
2010514028.tif 000022
【図２１】
2010514028.tif 000023
【図２２】
2010514028.tif 000024
【図２３】
2010514028.tif 000025
【図２４】
2010514028.tif 000026
【図２５】
2010514028.tif 000027
【国際調査報告】
2010514028.tif 000028
2010514028.tif 000029
2010514028.tif 000030
2010514028.tif 000031
2010514028.tif 000032