JP6095796B2 - 「ブリング・ユア・オウン」管理のための起動機構 - Google Patents

Description

本発明は一般的に、コンピュータを起動するために用いられるユーザ・ポータブル・デバイスの分野に関する。加えて本発明は、いわゆる「ブリング・ユア・オウン（ｂｒｉｎｇ ｙｏｕｒ ｏｗｎ）」（ＢＹＯ）コンピューティング作業環境に関する。

ＢＹＯは一般的に、「ブリング・ユア・オウン・デバイス（Ｂｒｉｎｇ ｙｏｕｒ ｏｗｎ ｄｅｖｉｃｅ）」（ＢＹＯＤ）、「ブリング・ユア・オウン・テクノロジ（ｂｒｉｎｇ ｙｏｕｒ ｏｗｎ ｔｅｃｈｎｏｌｏｇｙ）」（ＢＹＯＴ）、または密接に関係する「ブリング・ユア・オウン・ビヘイビア（ｂｒｉｎｇ ｙｏｕｒ ｏｗｎ ｂｅｈａｖｉｏｒ）」（ＢＹＯＢ）に関するものである。ＢＹＯＤまたはＢＹＯＴは、従業員が仕事に個人のモバル・デバイスを持ち込んで使用し、雇用者のｅメール、データベースおよびファイルにアクセスし、一方でこうしたデバイスを家庭でも用いるために、同じデバイスを通じて個人のアプリケーション／データにアクセスすることをいかにしてなし得るかという企業／ビジネス・ポリシに関わるものである。ＢＹＯＢは、このことをハードウェアを越えてデバイス上で用いられるソフトウェアにも広げたものである。

現在、多くの従業員は、自身のホーム・コンピュータ（例、ラップトップ）と、雇用者によって割り当てられたコンピュータとの両方を有する。従業員が自身のホーム・コンピュータの維持に慣れてきているため、雇用者は単一のコンピュータのみを必要とするコンピュータ所有権のモデルに移行している。従業員は、仕事に彼／彼女のホーム・コンピュータを使用するよう命じられることがある。コンピュータのシステム管理の大部分が従業員に委ねられて節約につながるため、これは雇用者にとって魅力的である。従業員にとっても、自分自身の好みに従って選択できる単一のコンピュータしか必要ないため、これは魅力的である。加えて、従業員はしばしば雇用者から補償を受取る。

しかし、同じマシン上で企業の計算と個人の計算とを混合することは、何が雇用者に属し、何が従業員に属するものかの境界を曖昧にする。もしこのコンピュータで実行されるソフトウェアに制約が設けられていなければ、企業の機密情報が損なわれるおそれがある。なぜなら、非企業のアプリケーションがそれを分散または破損するためである。もし雇用者がコンピュータを厳格に制御する必要があれば、従業員に対する魅力が失われ、従業員は企業のモニタリング・ツールによって自身のプライバシが損なわれることを懸念するだろう。何が誰に属するものかを容易に識別できるようにした、事項の明確な分離が必要である。

この分離を規定するために、仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ：ＶＭ）を使用することがしばしば行われ、ここでＶＭは実行可能環境全体をカプセル化する。ＶＭはしばしばゲスト・オペレーティング・システムと呼ばれ、それが実行されているオペレーティング・システム（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ：ＯＳ）はホストＯＳと呼ばれる。簡単な動作モードの１つにおいて、会社は企業イメージを規定し、これをＶＭの形で従業員に利用可能にする。次いでそのＶＭが従業員のホーム・マシンで実行される。ＶＭ内で実行されるものは会社によって規定される一方で、好適なＶＭマネージャ（例、ＶＭＷａｒｅ（Ｒ）、バーチャル・ボックス（Ｖｉｒｔｕａｌ Ｂｏｘ））が存在する限り、従業員が物理的マシンで何を実行するかに関しては従業員の自由が保たれる。

しかし、これは雇用者から従業員を保護するものであるが、逆は当てはまらない。本発明は、従業員から雇用者を保護することも行う解決策を提供することを目的とする。

加えて、外部起動媒体がしばしば（セキュアな耐タンパ・デバイスを含む）トラステッド・デバイス上に提供され、このタイプのデバイスは一般的に公知である。たとえば、オンラインのトランザクションに対して開発された解決策は、いわゆるゾーン・トラステッド情報チャネル（Ｚｏｎｅ Ｔｒｕｓｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）（または略してＺＴＩＣ）である。ＺＴＩＣは、トランザクション・データの認証のためのセキュアな非プログラマブル・デバイスである。ＺＴＩＣはサーバに対するセキュアなエンド・ツー・エンドのネットワーク接続を維持するため、ＺＴＩＣ自体が悪意あるソフトウェアの攻撃に対して耐タンパであり、かつＺＴＩＣはそれが接続するホストとは独立した自身の入力および出力コンポーネントを有するため、ＺＴＩＣディスプレイに示されるデータは本物である。より詳細なことは、たとえば非特許文献１などに見出され得る。

"Ｔｈｅ Ｚｕｒｉｃｈ Ｔｒｕｓｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ−Ａｎ Ｅｆｆｉｃｉｅｎｔ Ｄｅｆｅｎｃｅ ａｇａｉｎｓｔ Ｍａｎ−ｉｎ−ｔｈｅ−Ｍｉｄｄｌｅ ａｎｄ Ｍａｌｉｃｉｏｕｓ Ｓｏｆｔｗａｒｅ Ａｔｔａｃｋｓ"，Ｔｈｏｍａｓ Ｗｅｉｇｏｌｄ，Ｔｈｏｒｓｔｅｎ Ｋｒａｍｐ，Ｒｅｔｏ Ｈｅｒｍａｎｎ，Ｆｒａｎｋ Ｈｏｅｒｉｎｇ，Ｐｅｔｅｒ Ｂｕｈｌｅｒ，Ｍｉｃｈａｅｌ Ｂａｅｎｔｓｃｈ．Ｉｎ Ｐ．Ｌｉｐｐ，Ａ．−Ｒ．ＳａｄｅｇｈｉおよびＫ．−Ｍ．Ｋｏｃｈ（編）：ＴＲＵＳＴ ２００８，ＬＮＣＳ ４９６８，ｐ．７５−９１，２００８．Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ Ｂｅｒｌｉｎ Ｈｅｉｄｅｌｂｅｒｇ ２００８

本発明は、従業員から雇用者を保護することも行う解決策を提供することを目的とする。

第１の局面に従うと、本発明はユーザ・ポータブル・デバイス、好ましくはセキュアな耐タンパ・デバイスとして具現化され、このユーザ・ポータブル・デバイスは、
コンピュータとの接続を可能にする接続インタフェースと、
永続的メモリと、
前記永続的メモリ、好ましくはデバイスのセキュア・メモリに保存されたブートローダとを含み、
このブートローダは、
前記接続インタフェースを介したデバイスと前記コンピュータとの接続の際に、コンピュータのファームウェアによって検出可能であり、かつ
前記ファームウェアがブートローダを以後の実行のためにコンピュータのメモリにロードするための命令と、
コンピュータにおける実行の際にファームウェアと対話することによって、
第１のホスト・オペレーティング・システムおよび第２のホスト・オペレーティング・システムをそれぞれ第１の部分および第２の部分に保存する前記コンピュータの物理記憶媒体において、前記物理記憶媒体の区画情報から前記第２の部分を定めることであって、この区画情報は第１のホスト・オペレーティング・システムは知らせるが第２のホスト・オペレーティング・システムは知らせない、定めることと、
第２の部分内の第２のホスト・オペレーティング・システムの一部分を位置付けることと、
前記部分を実行することによって、ホスト・オペレーティング・システムのうち第２のものだけがユーザ・ポータブル・デバイスから起動し得るようにすることとを行うための命令とを含む。

実施形態において、ユーザ・ポータブル・デバイスはさらに、前記セキュア・メモリに保存された保全性チェック・データを含み、ブートローダはさらに、前記保全性チェック・データに基づいて前記部分の保全性をチェックするように構成される。

好ましくは、ブートローダは、前記部分の内容をハッシュし、結果として得られたハッシュ値を前記保全性チェック・データに対してチェックすることによって第２のホスト・オペレーティング・システムの前記部分の保全性をチェックするように構成される。

好ましい実施形態において、ブートローダはさらに、前記コンピュータにおける実行の際に、前記物理記憶媒体に保存される、第１のオペレーティング・システムによって使用される最終セクタの後、好ましくは直後に始まる物理記憶媒体の所与のセクタから前記部分を探索することによって、前記部分を位置付けるように構成される。

好ましくは、ブートローダはさらに、前記コンピュータにおける実行の際に、物理記憶媒体の区画情報に基づいて第１の部分のサイズを算出し、かつどのセクタが第１のオペレーティング・システムによって使用される最終セクタであるかを推定するように構成される。

実施形態において、ブートローダはさらに、前記コンピュータにおける実行の際に、
−前記所与のセクタと、
−前記第２の部分に保存された前記第２のホスト・オペレーティング・システム内の前記部分の相対的位置のデータと
に基づいて、間接的に前記部分を位置付けるように構成される。

ブートローダはさらに、前記コンピュータにおける実行の際に、第１のホスト・オペレーティング・システムによって占有された前記物理記憶媒体の部分をマスクするために、前記物理記憶媒体の上にオーバーレイ・ディスクを構築させるように構成され、このオーバーレイ・ディスクは、前記物理記憶媒体によって支えられた物理記憶媒体のソフトウェア表現であり、
ブートローダはさらに、前記コンピュータにおける実行の際に、オーバーレイ・ディスクが第１のホスト・オペレーティング・システムによって占有された最終セクタの後、直後の物理記憶媒体のセクタから始まるようにオーバーレイ・ディスクを構築させるように構成される。

本発明の局面はさらに、上記の実施形態のいずれか１つに従うユーザ・ポータブル・デバイスと、前記接続インタフェースを介してユーザ・ポータブル・デバイスを接続可能なコンピュータとを含むシステムに関し、このコンピュータは、前記第１の部分および第２の部分にそれぞれ保存された第１のホスト・オペレーティング・システムおよび第２のホスト・オペレーティング・システムを有し、コンピュータの物理記憶媒体の区画情報は、第１のホスト・オペレーティング・システムは知らせるが第２のホスト・オペレーティング・システムは知らせない。

好ましくは、第２のホスト・オペレーティング・システムの前記部分は、
第２のオペレーティング・システムのカーネル、および
前記コンピュータを起動する際に関与するソフトウェアのみを含む。

別の局面に従うと、本発明は、上記の実施形態のいずれかに従うシステムにおいてコンピュータを起動する方法として具現化され、この方法は、ユーザ・ポータブル・デバイスとコンピュータとの接続の際に、
ホスト・コンピュータのファームウェアによってユーザ・ポータブル・デバイスのブートローダが検出されるようにすることによって、ファームウェアに対するブートローダの命令に従って、ブートローダがコンピュータに移ってコンピュータにおいて実行することによって、
第２のホスト・オペレーティング・システムが起動し、かつ前記ホスト・オペレーティング・システムのうち第２のものだけがユーザ・ポータブル・デバイスから起動し得るように、
第２のホスト・オペレーティング・システムの一部分を位置付けし、かつ実行するステップを含む。

この方法はさらに、
第１のホスト・オペレーティング・システムによって占有された前記物理記憶媒体の部分をマスクするために、前記物理記憶媒体の上にオーバーレイ・ディスクを構築するステップであって、前記物理記憶媒体は物理ディスクであり、このオーバーレイ・ディスクは前記物理記憶媒体によって支えられた物理記憶媒体のソフトウェア表現である、ステップと、
構築されたオーバーレイ・ディスクにおいて第２のホスト・オペレーティング・システムを実行するステップと、
実行中の第２のホスト・オペレーティング・システムにおいてソフトウェアを実行するステップとを含む。

好ましい実施形態において、この方法はさらに、オーバーレイ・ディスクを構築するステップの前に、
物理記憶媒体の区画情報を読取るステップと、
前記区画情報から、好ましくは前記物理記憶媒体における第１のホスト・オペレーティング・システムによって占有された第１の部分のサイズを算出することによって、前記物理記憶媒体のどこに第２のホスト・オペレーティング・システムが位置するかを推定するステップと、
オーバーレイ・ディスクが
第１のホスト・オペレーティング・システムによって占有された最終セクタの後、好ましくは直後の物理記憶媒体のセクタから始まり、かつ
好ましくは物理記憶媒体の端部まで続く
ようにオーバーレイ・ディスクを構築するステップとを含む。

好ましくは、第２のホスト・オペレーティング・システムにおいてソフトウェアを実行するステップはさらに、
第２のホスト・オペレーティング・システムにおいて仮想マシンをゲスト・オペレーティング・システムとして実行するステップを含み、このゲスト・オペレーティング・システムは実行可能環境をカプセル化する。

実施形態において、第１のホスト・オペレーティング・システムは個人のオペレーティング・システムであり、第２のオペレーティング・システムは企業のオペレーティング・システムであり、仮想マシンを実行するステップの結果として、所与のユーザに属するデスクトップを表示するステップが得られる。

最後の局面に従うと、本発明は、ともに具現化されるブートローダを有するコンピュータ読取り可能記憶媒体を含むコンピュータ・プログラム製品として具現化され、このブートローダは、
コンピュータのファームウェアによって検出可能であり、かつ
前記ファームウェアがブートローダを以後の実行のためにコンピュータのメモリにロードするための命令と、
コンピュータにおける実行の際にファームウェアと対話することによって、
第１のホスト・オペレーティング・システムおよび第２のホスト・オペレーティング・システムをそれぞれ第１の部分および第２の部分に保存する前記コンピュータの物理記憶媒体において、前記物理記憶媒体の区画情報から前記第２の部分を定めることであって、この区画情報は第１のホスト・オペレーティング・システムは知らせるが第２のホスト・オペレーティング・システムは知らせない、定めることと、
第２の部分内の第２のホスト・オペレーティング・システムの一部分を位置付けることと、
前記部分を実行することによって、コンピュータにおけるブートローダの実行の際に第２のホスト・オペレーティング・システムだけが起動し得るようにすることとを行うための命令とを含む。

添付の図面を参照して、限定的でない実施例として、本発明を具現化するデバイス、システムおよび方法を説明する。

本発明の実施形態を実装するのに好適な、一般的コンピュータ・システムを概略的に表す図である。 実施形態に従うユーザ・ポータブル・デバイスの選択されたコンポーネント、およびこれらのコンポーネントが機能的に相互関係する様子を簡略化して表す図である。 図１のコンピュータ・システムの選択されたコンポーネントを、実施形態に従う方法のステップを示す流れ図とともに概略的に示す図である。 実施形態に従う、コンピュータがユーザ・デバイスからセキュアに起動することを可能にするための方法の高レベル・ステップを示す流れ図である。 実施形態に含まれる、物理記憶媒体の上に構築されたオーバーレイ・ディスクの構成を概略的に示す図である。

以下の説明は、次のように構成されている。最初に一般的な実施形態および高レベルの変形について説明する（セクション１）。次のセクションは、より特定的な実施形態および技術的実装の詳細に向けられたものである（セクション２）。

１．一般的な実施形態および高レベルの変形
導入部において考察したとおり、家庭／仕事環境の分離を規定するために、ＶＭがしばしば用いられる。しかし、もしホストＯＳが損なわれれば、企業ＶＭも損なわれることが認識され得る。ＶＭ内で実行される管理ツールは（少なくともすばやく）これを検出できず、したがってそれらはなおもホストＯＳで実行される必要がある。そのため、雇用者は従業員の環境においてソフトウェアを制御する必要がある。よって、雇用者はＶＭだけでなく、それが実行されるホストＯＳも制御しなければならない。よって、雇用者に対するものと従業員に対するものとの２つのホストＯＳが必要とされる。各々のホストＯＳはディスク上の区画に割り当てられてもよいし、まったく別の２つのディスクが用いられてもよい。

しかし、これでは問題を解決するために十分ではないことも認識され得る。なぜなら、各ＯＳが他方のディスクにアクセスできるため、いずれかのホストＯＳが他方によって損なわれ得るためである。暗号化ディスクは、キーを所有する者のみによって読取られ得る。しかし、ＯＳのディスク内容全体を暗号化することはできない。なぜなら、ＯＳのある部分はユーザからパスワードが得られる時点までに実行される必要があるからである。ディスクのこの部分の内容は「ブート・イメージ」と呼ばれる。暗号化されないブート・イメージは、たとえばブートローダによって読取られて実行されてもよい。次いでブート・イメージは、キーを入手して復号化することにより、残りのディスクへのアクセスを可能にする。そのコンピュータを得た者はそれを起動できるが、適切なパスワードなしにデータを含むディスクを読取ることはできない。しかし、彼女がディスクを再フォーマットしてそこに別のＯＳをインストールすることは可能であり、もしそれが前のＯＳと類似のものであれば、検出されないままとなる可能性がある。同じマシン上で２つのホストＯＳを実行させることは、第三者がマシンを得る状況と類似の状況である。一方のＯＳが他方のディスクを上書きするかもしれない。結果として、損なわれたホームＯＳが次いで企業ＯＳを損なうおそれがある。

本発明は、企業環境がホームＯＳによって損なわれ得ないこと、より一般的には第１のホストＯＳが第２のＯＳを損なうことができないことを確実にすることによって、この問題を解決するものである。同時に、設計された解決策は、第１の（ホーム、ネイティブ）ＯＳにおいて何が実行されるかに制限を設けない。それは第１のＯＳにおける、たとえばデュアル・ブート能力の追加または区画テーブルの変更などのいかなる変更も必要としない。

本発明者らによる以下の本発明のアプローチは、次のように要約できる。
−コンピュータ管理の古典的ＢＹＯモデルのほとんどは、家庭／仕事環境の分離を規定するためにＶＭに依拠することを提案する。
−損なわれたホストＯＳが企業ＶＭを損ない得るため、このアプローチは満足できるものではないことが見出されていた。
−よって、各々がディスク上の区画またはまったく別の２つのディスクに割り当てられた２つのホストＯＳに同時に依拠する試みがなされた。
−しかし、これらのＯＳのうちの一方が他方のディスクを上書きし得るために、損なわれたホームＯＳが企業ＯＳを損ない得るため、発明者らは、このアプローチにも欠点があることを認識した。
−したがって本発明者らのアイデアは、第１のＯＳに対して第２のＯＳを「隠す」ことであり、たとえば第１のＯＳが第２のＯＳを見ることができないためにそれを損なうことができないように、記憶媒体の区画情報において企業ＯＳが知らされない。
−しかし次いで次の問題が起こる。どのようにして第２のＯＳを起動するか？実際のところ、第２のＯＳは自己を意識していないために、単純に起動できない。
−よって本発明者らの別のアイデアは、それを外部デバイスから（セキュアに）起動させることであり、そのデバイスは、（区画情報に第２のＯＳのトレースが見出されないために）このＯＳがどこにあるかを知ることなくＯＳを位置付けるという課題に直面する。
−次の手法のおかげでこの困難を克服できる。区画情報は第１のＯＳの特性を知らせるため、記憶媒体のどこに第１のＯＳが位置するかを定めることができ、したがって第２のＯＳは第１のＯＳによって空のまま残された部分に位置するものと想定できる。
−よって、たとえば第２のＯＳのブート・イメージなどの実行可能な部分を位置付けることができ、起動プロセスを開始できる。
−よって最初に必要とされることは、区画テーブルから第１のＯＳに関する情報を抽出して、そこから第２のＯＳの位置を推定することだけである。
−より効果的に、第２のＯＳによって占有された部分の上にオーバーレイ・ディスクが構築されることによって、第１のＯＳに対する危険なしにこのオーバーレイ・ディスクにおいて第２のＯＳが実行され得るようにしてもよい。

本発明のこれらの態様（およびさらに多くの態様）を以下に詳細に説明する。最初に図１は、本発明の実施形態を実装するのに好適な、一般的コンピュータ・システムを表す。

本明細書に記載される方法はほとんど非対話型であり、たとえばユーザ・デバイス、パーソナル・コンピュータ、サーバ、もしくは埋込みシステム、またはその組み合わせなどのコンピュータ・システムによって自動化されることが認識されるだろう。例示的実施形態において、本明細書に記載される方法は、部分的に対話型または非対話型のシステムにおいて実装されてもよい。さらに、これらの方法はソフトウェア（例、ファームウェア）、ハードウェア、またはその組み合わせにおいて実装されてもよい。例示的実施形態において、本明細書に記載される方法は、実行可能プログラムとしてソフトウェアにおいて実装され、特定目的または汎用のデジタル・コンピュータ、たとえばパーソナル・コンピュータ、ワークステーション、ミニコンピュータ、またはメインフレーム・コンピュータなどによって実行される。したがって、最も一般的なシステム１００は、たとえばパーソナル・コンピュータ１０１などの汎用コンピュータを含む。

図１に示されるとおりのハードウェア・アーキテクチャに関する例示的実施形態において、コンピュータ１０１はプロセッサ１０５と、メモリ・コントローラ１１５に結合されたメモリ１１０と、ローカル入力／出力コントローラ１３５を介して通信的に結合された１つまたはそれ以上の入力もしくは出力またはその両方の（ｉｎｐｕｔ ａｎｄ／ｏｒ ｏｕｔｐｕｔ）（Ｉ／Ｏ）デバイス（または周辺装置）１０、１４５とを含む。当該技術分野において公知であるとおり、入力／出力コントローラ１３５は、１つもしくはそれ以上のバス、またはその他の有線もしくはワイヤレス接続であってもよいが、それに限定されない。入力／出力コントローラ１３５は、通信を可能にするために、たとえばコントローラ、バッファ（キャッシュ）、ドライバ、リピータおよび受信機などの付加的な構成要素を有してもよく、それらは簡潔のために省略されている。さらに、ローカル・インタフェースは、前述のコンポーネント間の適切な通信を可能にするためのアドレス、制御、もしくはデータ接続、またはその組み合わせを含んでもよい。本明細書に記載されるとおり、Ｉ／Ｏデバイス１０、１４５は一般的に、当該技術分野において公知である任意の汎用暗号カードまたはスマート・カードを含んでもよい。こうしたデバイスの１つは、特に図２を参照して以下に詳細に考察されるユーザ・トラステッド・デバイス１０である。

プロセッサ１０５は、ソフトウェア、特にメモリ１１０に保存（またはロード）されるソフトウェアを実行するためのハードウェア・デバイスである。プロセッサ１０５は、任意の特注プロセッサまたは商業的に入手可能なプロセッサ、中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＣＰＵ）、コンピュータ１０１に関連するいくつかのプロセッサの中の補助プロセッサ、（マイクロチップまたはチップ・セットの形の）半導体に基づくマイクロプロセッサ、マクロプロセッサ、または一般的にソフトウェア命令を実行するための任意のデバイスであってもよい。よってそれはいくつかのコア／プロセッサからなっていてもよい。

メモリ１１０は、揮発性記憶素子（例、ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）（ＲＡＭ、たとえばＤＲＡＭ、ＳＲＡＭ、ＳＤＲＡＭなど））および不揮発性（永続的）記憶素子（例、ＲＯＭ、消去可能プログラマブル・リード・オンリ・メモリ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：ＥＰＲＯＭ）、電気的消去可能プログラマブル・リード・オンリ・メモリ（ｅｌｅｃｔｒｏｎｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：ＥＥＰＲＯＭ）、プログラマブル・リード・オンリ・メモリ（ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：ＰＲＯＭ）、テープ、コンパクト・ディスク・リード・オンリ・メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：ＣＤ−ＲＯＭ）、ディスク、ディスケット、カートリッジ、カセットまたはその類似物など）のいずれか１つまたはその組み合わせを含んでもよい。さらに、メモリ１１０は電子、磁気、光学、もしくはその他のタイプの記憶媒体、またはその組み合わせを組み込んでもよい。なおメモリ１１０は、さまざまなコンポーネントが互いに離れた位置にあるがプロセッサ１０５によってアクセス可能であるような分散型アーキテクチャを有してもよい。特に、メモリ１１０は所与のメモリ部分１２１を含み、そのメモリ部分１２１にブートローダ１６（およびおそらくは外部デバイス１０に最初に保存されていたその他のモジュール）が以後の実行のために移されてもよい。

メモリ１１０内のソフトウェアは１つまたはそれ以上の別個のプログラムを含んでもよく、そのプログラムの各々は、論理関数、特に本発明の実施形態に関与する関数を実装するために実行可能な命令のリストを含む。図１の実施例において、いくつかの条件が満たされたときにコンピュータ１０１がユーザ・トラステッド・デバイス１０からの起動を開始および完了することを可能にするための命令がメモリ１１０にロードされてもよい。

以下に考察される実施形態において、メモリ１１０にはさらに、別様にたとえば物理ディスクなどの物理記憶媒体１２０に保存された２つの好適なオペレーティング・システム（ＯＳ）１１１−１および１１１−２の一方がロードされてもよい。しかし、本明細書において考察される新規の方法は、ホスト１０１のいずれのＯＳよりも「前に」少なくとも部分的に動作することに留意されたい（それらはハードウェアにより近い別のレベルで動作し、それによってコンピュータ１０１の正常な挙動が影響を受ける）。典型的に、２つのオペレーティング・システムが存在する。すなわち、たとえば主に家庭で用いられることが意図されたネイティブＯＳなどの第１のＯＳ１１１−１と、たとえば企業ＯＳなどの第２のＯＳ１１１−２とである。一旦（もし）ロードされると、ＯＳ１１１−１または１１１−２は他のコンピュータ・プログラムの実行を本質的に制御して、スケジューリング、入力−出力制御、ファイルおよびデータ管理、メモリ管理、ならびに通信制御および関連するサービスを提供する。これら２つのＯＳは典型的に、特に他のコンピュータ・プログラムのどれを制御するか、ならびにどの程度のファイルおよびデータ管理が可能かに関して異なっている。

本明細書に記載される方法の少なくとも一部は、ソース・プログラム、実行可能プログラム（オブジェクト・コード）、スクリプト、または実行されるべき命令のセットを含むあらゆるその他のエンティティの形であってもよい。ソース・プログラムのとき、次いでそのプログラムは、デバイス１０もしくはホスト１０１またはその両方のメモリ（単数または複数）に含まれても含まれなくてもよいコンパイラ、アセンブラ、またはインタープリタなどを介して変換される必要がある。さらに、これらの方法は、データおよび方法のクラスを有するオブジェクト指向プログラミング言語として書かれてもよいし、ルーチン、サブルーチン、もしくは関数、またはその組み合わせを有する手続き型プログラミング言語として書かれてもよい。すべての場合に、本明細書において考察される新規の方法は、ファームウェア１２２に関連し、かつ必要に応じてデバイスのＣＰＵ１１に関連して適切に動作するように設計される。

例示的実施形態において、入力／出力コントローラ１３５には従来のキーボード１５０およびマウス１５５が結合されてもよい。たとえばＩ／Ｏデバイス１４５などのその他の出力デバイスは、たとえばプリンタ、スキャナ、およびマイクロホンなどであるがそれに限定されない入力デバイスを含んでもよい。最後に、Ｉ／Ｏデバイス１０、１４５は入力および出力の両方と通信するデバイスをさらに含んでもよく、それはたとえば（他のファイル、デバイス、システムまたはネットワークにアクセスするための）ネットワーク・インタフェース・カード（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ：ＮＩＣ）または変調器／復調器、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ：ＲＦ）またはその他のトランシーバ、電話インタフェース、ブリッジ、およびルータなどであるが、これらに限定されない。本明細書において説明されるとおり、Ｉ／Ｏデバイス１０、１４５は、当該技術分野において公知である任意の汎用暗号カードまたはスマート・カードであってもよい。システム１００はさらに、ディスプレイ１３０に結合されたディスプレイ・コントローラ１２５を含んでもよい。例示的実施形態において、システム１００はさらに、ネットワーク１６５に結合するためのネットワーク・インタフェース１２４（例、ＮＩＣ）を含んでもよい。ネットワーク１６５は、コンピュータ１０１と、任意の外部サーバおよびクライアントなどとの間の広帯域接続を介した通信のための、ＩＰに基づくネットワークであってもよい。ネットワーク１６５は、コンピュータ１０１と、たとえばサーバ３０などの外部システムとの間でデータを送受信する。例示的実施形態において、ネットワーク１６５は、サービス・プロバイダによって管理されるマネージドＩＰネットワークであってもよい。ネットワーク１６５は、たとえばＷｉＦｉ（Ｒ）、ＷｉＭａｘ（Ｒ）などのワイヤレス・プロトコルおよび技術を用いるなどして、ワイヤレス方式で実現されてもよい。加えてネットワーク１６５は、たとえばローカル・エリア・ネットワーク、広域ネットワーク、メトロポリタン・エリア・ネットワーク、インターネット・ネットワーク、またはその他の類似のタイプのネットワーク環境などのパケット交換ネットワークであってもよい。ネットワーク１６５は、固定ワイヤレス・ネットワーク、ワイヤレス・ローカル・エリア・ネットワーク（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＬＡＮ）、ワイヤレス広域ネットワーク（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＡＮ）、パーソナル・エリア・ネットワーク（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＰＡＮ）、仮想プライベート・ネットワーク（ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ：ＶＰＮ）、イントラネット、またはその他の好適なネットワーク・システムであってもよく、信号を受信および送信するための機器を含む。

コンピュータ１０１がＰＣ、ワークステーション、またはインテリジェント・デバイスなどであるとき、メモリ１１０内のソフトウェアは、基本入出力システム（ｂａｓｉｃ ｉｎｐｕｔ ｏｕｔｐｕｔ ｓｙｓｔｅｍ：ＢＩＯＳ）１２２をさらに含んでもよい。ＢＩＯＳは、始動時にハードウェアを初期化およびテストし、ＯＳを始動し、ハードウェア・デバイス間でデータを移すことを支援する基本的ソフトウェア・ルーチンのセットである。コンピュータ１０１が活動化されるときにＢＩＯＳが実行され得るように、ＢＩＯＳは典型的にＲＯＭに保存される。

本明細書に記載される方法を実現する目的のために、ＢＩＯＳ１２２は隠されたＯＳを定めるようブートローダに促されて、そのためにブートローダと対話する。しかしより一般的には、その目的のために、あらゆる好適なファームウェア１２２またはファームウェアに対するインタフェース（すなわち、ソフトウェア・スタックにおいて任意のオペレーティング・システムの「下で」動作する、永続的メモリならびにそこに保存されるプログラム・コードおよびデータの組み合わせ）が用いられてもよい。これは典型的にはＢＩＯＳである。しかし、好適なファームウェア１２２またはそれに対するインタフェースの例は、いわゆるエクステンシブル・ファームウェア・インタフェース（Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ：ＥＦＩ）ＢＩＯＳ、またはユニファイド・エクステンシブル・ファームウェア・インタフェース（Ｕｎｉｆｉｅｄ Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ：ＵＥＦＩ）を含む。後者は、オペレーティング・システムとプラットフォーム・ファームウェアとの間のソフトウェア・インタフェースを規定する仕様である。ＵＥＦＩはＢＩＯＳファームウェア・インタフェースに取って代わることが意図されており、今日すべてのＩＢＭ（ＩＢＭ社の登録商標）のＰＣ準拠コンピュータに存在する。実際には、ほとんどのＵＥＦＩイメージがＢＩＯＳサービスに対するレガシ・サポートを有する。より一般的には、ＢＩＯＳサービスまたは同等のサービスに対するレガシ・サポートを有するあらゆるファームウェアが、本明細書に記載される方法を実装する目的のために予期され得る。さらにより一般的には、ソフトウェア・スタックにおいてオペレーティング・システムの下で動作するあらゆる初期化ファームウェアは、本発明を実装する目的のために集められ得る。

コンピュータ１０１が動作中であるとき、プロセッサ１０５は、メモリ１１０内に保存されたソフトウェアを実行し、メモリ１１０とデータを通信し、かつソフトウェアに従ってコンピュータ１０１の動作を広く制御するように構成される。本明細書に記載される方法の全体または一部、典型的に後者は、プロセッサ１０５によって読取られ、おそらくはプロセッサ１０５内にバッファされ、次いで実行される。

ソフトウェアにおいて実装され得る、本明細書に記載される方法の部分は、任意のコンピュータ関連のシステムもしくは方法による使用、またはそれに関連する使用のための任意のコンピュータ読取り可能媒体に保存されてもよい。

当業者に認識されるとおり、本発明の局面はシステム、方法またはコンピュータ・プログラム製品として具現化されてもよい。したがって本発明の局面は、完全にハードウェアの実施形態、完全にファームウェアもしくはソフトウェアまたはその両方の実施形態（ファームウェア／ソフトウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはファームウェア／ソフトウェアおよびハードウェアの局面を組み合わせた実施形態の形を取ってもよく、本明細書においてこれらはすべて一般的に「モジュール」、「システム」、または「プロセス」、「スキーム」などと呼ばれることがある。さらに、本発明の局面は、コンピュータ読取り可能プログラム・コードが具現化されている１つまたはそれ以上のコンピュータ読取り可能媒体（単数または複数）において具現化されるコンピュータ・プログラム製品の形を取ってもよい。

１つまたはそれ以上のコンピュータ読取り可能媒体（単数または複数）の任意の組み合わせが用いられてもよい。コンピュータ読取り可能媒体は、コンピュータ読取り可能信号媒体またはコンピュータ読取り可能記憶媒体であってもよい。コンピュータ読取り可能記憶媒体は、たとえば電子、磁気、光学、電磁気、赤外、または半導体のシステム、装置、もしくはデバイス、または前述のもののあらゆる好適な組み合わせなどであってもよいがそれに限定されない。コンピュータ読取り可能記憶媒体のより特定的な例（非網羅的なリスト）は以下を含む。すなわち、１つまたはそれ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、光学記憶装置、磁気記憶装置、または前述のもののあらゆる好適な組み合わせである。本文書の状況において、コンピュータ読取り可能記憶媒体は、命令実行システム、装置またはデバイスによる使用、またはそれに関連する使用のためのプログラムを含有または保存し得るあらゆる有形の媒体であってもよい。

コンピュータ読取り可能信号媒体は、たとえばベースバンド内で、または搬送波の部分などとして媒体内で具現化されるコンピュータ読取り可能プログラム・コードを有する伝播データ信号を含んでもよい。こうした伝播信号は、電磁気信号、光学信号、またはそのあらゆる好適な組み合わせを含むがそれに限定されないさまざまな形のいずれかを取ってもよい。コンピュータ読取り可能信号媒体は、コンピュータ読取り可能記憶媒体ではなく、かつ命令実行システム、装置またはデバイスによる使用、またはそれに関連する使用のためのプログラムを通信、伝播または移送できる任意のコンピュータ読取り可能媒体であってもよい。

コンピュータ読取り可能媒体において具現化されるプログラム・コードは、ワイヤレス、ワイヤライン、光ファイバ・ケーブル、ＲＦなど、または前述のもののあらゆる好適な組み合わせを含むがそれに限定されない任意の適切な媒体を用いて送信されてもよい。

本発明の局面のための動作を行うためのコンピュータ・プログラム・コードは、オブジェクト指向プログラミング言語、たとえばＪａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、またはＣ＋＋など、および従来の手続き型プログラミング言語、たとえば「Ｃ」プログラミング言語または類似のプログラミング言語などを含む、１つまたはそれ以上のプログラミング言語のあらゆる組み合わせで書かれていてもよい。プログラム・コードは、すべてがユーザのコンピュータで実行されてもよいし、（スタンド・アロン・ソフトウェア・パッケージとして）部分的にユーザのコンピュータで実行されてもよいし、さらに部分的に次のうちの２つまたはそれ以上で実行されてもよい。すなわち、ユーザのコンピュータ、ユーザ・トラステッド・デバイス、およびリモート・コンピュータである。ホスト・コンピュータおよびサーバは、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、外部コンピュータへの接続（インターネット・サービス・プロバイダを使用するインターネット）を含むあらゆるタイプのネットワークを通じて接続されてもよい。

本発明の実施形態に従う方法、装置（システム）およびコンピュータ・プログラム製品の流れ図もしくはブロック図またはその両方を参照して、本発明の局面を以下に説明する。流れ図もしくはブロック図またはその両方の各ブロック、および流れ図もしくはブロック図またはその両方におけるブロックの組み合わせは、コンピュータ・プログラム命令によって実装され得ることが理解されるだろう。これらのコンピュータ・プログラム命令が、コンピュータ（汎用コンピュータもしくは特定目的のコンピュータ、またはその他のプログラマブル・データ処理装置）、もしくはユーザ・ポータブル・デバイス、またはその両方のプロセッサ（単数または複数）に与えられることによって、前記プロセッサ（単数または複数）を介して実行された命令が、流れ図もしくはブロック図またはその両方の単数または複数のブロックにおいて指定された機能／動作を実装するための手段を作成するようにマシンを生成してもよい。

さらに、これらのコンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル・データ処理装置またはその他のデバイスに特定の態様で機能するよう指示できるコンピュータ読取り可能媒体に保存されることによって、コンピュータ読取り可能媒体に保存された命令が、流れ図もしくはブロック図またはその両方の単数または複数のブロックにおいて指定された機能／動作を実装する命令を含む製造品を生成するようにしてもよい。

さらに、コンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル・データ処理装置またはその他のデバイスにロードされて、コンピュータ・デバイスにおいて一連の動作ステップを行わせることにより、そのコンピュータ・デバイスにおいて実行された命令が、流れ図もしくはブロック図またはその両方の単数または複数のブロックにおいて指定された機能／動作を実装するような、コンピュータに実装されるプロセスを生成してもよい。

図面中の流れ図およびブロック図は、本発明のさまざまな実施形態に従うシステム、方法およびコンピュータ・プログラム製品の実装可能なアーキテクチャ、機能および動作を例示するものである。これに関して、流れ図またはブロック図における各ブロックは、指定された論理関数（単数または複数）を実装するための１つまたはそれ以上の実行可能な命令を含むモジュール、セグメント、またはコードの部分を表していてもよい。さらに、いくつかの代替的な実装においては、ブロック中に示される機能が図面に示される以外の順序で起こってもよいことに留意すべきである。たとえば、連続して示される２つのブロックは、伴われる機能に依存して、実際には実質的に同時に実行されてもよいし、それらのブロックがときには逆の順序で実行されてもよい。さらに、ブロック図もしくは流れ図またはその両方の各ブロック、およびブロック図もしくは流れ図またはその両方のブロックの組み合わせは、指定された機能もしくは動作を行う特定目的のハードウェアに基づくシステム、または特定目的のハードウェアとコンピュータ命令との組み合わせによって実装され得ることを注記する。

図１から図５を広く参照して、ユーザ・ポータブル・デバイス１０に関する本発明の局面を最初に説明する。このデバイスは本質的に以下を含む。
−パーソナル・コンピュータ１０１との接続を可能にする、たとえばＵＳＢ接続インタフェースなどの接続インタフェース１２、
−好ましくはセキュア・メモリ１４１を含む永続的メモリ１４、および
−新規のコンピュータ化された方法が提供され、かつ前記永続的メモリ１４に保存されるブートローダ１６。

ブートローダ１６は、たとえばコンピュータ１０１を再始動するときなど、前記接続インタフェース１２を介したデバイス１０とコンピュータ１０１との接続の際に、たとえばコンピュータ１０１のＢＩＯＳなどの初期化ファームウェア１２２によって検出可能であるように設計される。この機能はたとえば、それ自体が公知であるとおり、（簡便にはデバイス１０に保存された）ブートローダ自体のデータ構造に従って提供されてもよい。ブートローダはさらに、前記ファームウェア１２２に対して、ブートローダ（またはそのモジュールもしくはサブパート）１６を以後のコンピュータにおける実行のためにコンピュータ１０１のメモリ１２１にロードするよう指示するための命令を含む。

さらにブートローダ１６は、たとえ２つのＯＳのうちの一方が隠されていても、すなわちコンピュータ１０１の物理記憶媒体１２０の区画情報によって知らされなくても、コンピュータ１０１上に共存する２つのＯＳのうち前記一方のみがセキュア・デバイス１０から起動できることを確実にすることを目的としたいくつかの特殊なタスクを行うために、（コンピュータ１０１における実行中に）ファームウェア１２２と対話するように特定的に設計される。

想定される状況は以下のとおりである。コンピュータ１０１の物理記憶媒体１２０は、第１のホストＯＳ１１１−１、たとえばネイティブＯＳなど（「ホーム」ＯＳとも呼ばれる）と、第２のホストＯＳ１１１−２（例、「企業」ＯＳ）とを保存する。オペレーティング・システム１１１−１および１１１−２（または少なくともその一部）は、それぞれ物理記憶媒体１２０の第１の部分１２０−１および第２の部分１２０−２に保存される。加えて、媒体１２０の区画情報１１１−１ｐは、第２のＯＳ１１１−２を知らせないことが想定される。言換えると、第２のＯＳは（第１のＯＳに対して）隠される。この想定状況とは独立して、以下に説明される本ブートローダの特定の機能は、区画情報１１１−１ｐ内の第２のＯＳに関する何らかの情報がたとえ利用できたとしても（そうでないことが好ましいが）、こうした情報を利用しない（さらに好ましくは無視する）。

正確には、コンピュータ１０１における実行の際に、ブートローダ１６は以下の動作を行うように設計される。
−最初に、ブートローダ１６は媒体１２０の第２の部分１２０−２、すなわち第２のＯＳ１１１−２によって使用される部分、特に第２の部分が始まるところを定める。しかし、ブートローダが用いる区画情報１１１−１ｐは第２のＯＳ１１１−２を知らせない（一般的に知らせないことが想定される）ため、ブートローダは、ＯＳのうち第１のものだけを知らせるこの区画情報１１１−１ｐのみを用いて第２の部分を間接的に定める必要がある。
−２番目に、ブートローダは第２の部分１２０−２における第２のＯＳ１１１−２の所与の部分（添付の図面における「ＢＩ」）を位置付ける。この部分は好ましくはブート・イメージであり、より一般的には、実行の際に第２のＯＳに起動を継続させるために寄与する任意の実行可能部分である。
−最後に、位置付けられた部分ＢＩを実行することによって、ＯＳのうち第２のものだけがユーザ・ポータブル・デバイス１０から効果的に起動できる。

反対に、別の局面に従うと、本発明はパーソナル・コンピュータ１０１を起動する方法として具現化されてもよく、これは図３および図４に示される。最初のステップＳ１において、上述のものなどのポータブル・デバイス１０およびコンピュータ１０１が提供されると想定するとき、次いでこの方法は、ポータブル・デバイス１０とコンピュータ１０１との接続の際に（Ｓ２）、以下のステップを含む。
−ステップＳ３：ファームウェア１２２によってブートローダ１６を検出させることによって、ブートローダ１６のファームウェアに対する命令に従って、
○ブートローダがコンピュータ１０１に移り（ステップＳ４）、そこで実行される（ステップＳ５）ことによって、
■その後、第２のＯＳ１１１−２の部分ＢＩを位置付け（ステップＳ６）、それを実行する（Ｓ８）ことによって、
●第２のＯＳが起動し（ステップＳ８〜Ｓ１１）、かつ前記ＯＳのうち第２のものだけがユーザ・ポータブル・デバイス１０から起動し得るようにする。

ブートローダ１６は、さまざまな種類の動作を行うために、たとえばＢＩＯＳなどのファームウェア１２２と対話する。ファームウェアは基本的な動作を行うために必要であるため、ブートローダ１６はさらに何らかの形で継続的にファームウェアと対話する。

本発明は、上で考察されたユーザ・ポータブル・デバイス１０およびコンピュータ１０１を含むシステムに拡張される。

（ｉ）第２のＯＳだけがユーザ・ポータブル・デバイス１０から起動し得ること、および（ｉｉ）そのプロセスに第１のＯＳは関与しないことから、本解決策はたとえば企業ＯＳなどの第２のＯＳを始動することを可能にし、かつ第２のＯＳがホーム・コンピュータにおいてネイティブＯＳを実行する必要なしに実行されることを可能にする。後で詳細に説明するとおり、必要な構成要素には区画情報からアクセスでき、この情報は本質的にネイティブＯＳとは独立のものである。よってネイティブＯＳを始動させる必要がないため、第２のＯＳが改ざんされる危険性が低くなる。

妥当な想定として、ディスク上に第２のＯＳを保存するために十分な空きスペースを利用可能にするために、ユーザはネイティブＯＳの区画を縮小させてもよい。これはたとえば、ウィンドウズ（Ｗｉｎｄｏｗｓ）（Ｒ）７およびＯＳＸなどのＯＳにおいて簡単なマウス・クリックによって達成できる。

ここで図２、図３および図４をより特定的に参照すると、実施形態において、ユーザ・ポータブル・デバイス１０はさらに、メモリ１４に保存された保全性チェック・データ１３を含んでもよい。ブートローダはさらに、前記保全性チェック・データ１３を用いて、先にブートローダによって位置付けられた部分ＢＩの保全性をチェックする（ステップＳ７）ように構成されてもよい。

部分ＢＩの保全性をチェックするステップは、トラストのチェーンの第１のステップとみなされてもよく、ここでトラステッド・ブートローダ１６は、予め定められて予め保存された情報を通じて、たとえばブート・イメージ（暗号化されていてもいなくても）など、位置付けられた部分の保全性を確認する。次に、当該技術分野における通常どおり、ブート・イメージがユーザとの対話を通じて残りのＯＳの保全性を確認してもよい。

その場合、デバイス１０は好ましくはセキュアな耐タンパ・デバイスであり、すなわち保全性チェック・データ１３はセキュア・メモリ１４１に保存されることが好ましい。実際に、位置付けられた部分ＢＩの保全性をセキュア・デバイスによって確認することに意味がある。なぜなら、そうでなければブートローダが改ざんされている危険があるためである。

実施形態において、ブートローダ１６は、前記部分の内容をハッシュして、結果として得られたハッシュ値を前記保全性チェック・データ１３に対してチェックすることによって、第２のホスト・オペレーティング・システム１１１−２の位置付け部分ＢＩの保全性をチェックするように構成されてもよい。その場合には、たとえば非暗号化ブート・イメージなどの部分ＢＩの内容のハッシュをデバイス１０に保存して、それを起動のたびにディスク上に見出されるものと比較することで十分である。なお、好ましくはブート・イメージはＯＳ１１１−２のカーネルおよび、たとえば起動プロセスの際に必要なものなどのいくつかのライブラリだけを含むため、ブート・イメージはかなり小さくてもよい。

代替的には、もし部分ＢＩが暗号化されていれば、前記保全性チェック・データに含まれるキー１３を用いて前記部分ＢＩを復号化することが要求されてもよく、それは位置付け部分の保全性をテストする別の手段を提供する。これは単純に内容の保全性を確実にすることよりも良好なセキュリティを提供するが、ソフトウェアの更新の複雑性を増大させる。

変形において、ブート・イメージはトラステッド・デバイスに保存されて、その位置付け（ステップＳ６）および実行（ステップＳ８）が行われる前にコンピュータ１０１に移されてもよい。これはブート・イメージの保全性を確実にするが、デバイス１０におけるより多くの記憶装置およびより頻繁な更新を必要とする。

ここで図５を参照すると、第２のＯＳ１１１−２は好ましくは隠されているため、ブートローダ１６は第１のＯＳ１１１−１の区画情報１１１−１ｐを読取る（ステップＳ１０ａ）ことによって、前記区画情報から物理記憶媒体１２０のどこに第２のＯＳ１１１−２が位置するかを推定（ステップＳ１０ｂ）してもよい。これは、前記物理記憶媒体１２０において第１のＯＳ１１１−１によって占有された第１の部分１２０−１のサイズｓ１を算出することを必要としてもよい。

たとえば、第１のホストＯＳ１１１−１および第２のホストＯＳ１１１−２が、コンピュータ１０１の同じ物理記憶媒体１２０、たとえば物理ディスクなどに存在すると想定すると、ブートローダ１６は前記コンピュータ１０１における実行の際に、物理記憶媒体１２０の所与のセクタｆｓ２から前記部分ＢＩを探索することによって前記部分ＢＩを位置付けるように構成されてもよく、このセクタｆｓ２は、（前記物理記憶媒体１２０に保存された）第１のＯＳ１１１−１によって使用される最終セクタ（ｌａｓｔ ｓｅｃｔｏｒ）ｌｓ１の後（例、直後）に始まる。どのセクタｌｓ１が第１のＯＳ１１１−１によって使用される最終セクタであるかは、少なくともいくつかの状況においては区画情報１１１−１ｐから直接入手可能であるか、または容易に計算できてもよく、この情報はステップＳ１０ａにおいてブートローダによって読取られる。第２のＯＳ１１１−２が第１のＯＳ１１１−１の後（例、直後）に保存されると想定するとき、図５に示されるとおり、ブートローダはそれをセクタｆｓ２から探索し始めてもよい、ステップＳ１０ｂ。

ここで、区画情報から入手可能なその他の構成情報に依存して、ブートローダは第２のＯＳ１１１−２の探索を、セクタｌｓ１の直後ではなく、ｌｓ１から離れたセクタｆｓ２から開始してもよい。なぜなら、いくつかの中間セクタが第１または第２のＯＳ以外の目的に使用されていることを区画情報が明らかにすることがあるためである。

デフォルト（コンテキスト依存）によって想定されるか、または区画情報１１１−１ｐから直接入手可能な情報の量に依存して、ブートローダはさらに、物理記憶媒体において第１のＯＳ１１１−１によって占有された第１の部分のサイズｓ１を算出する必要があってもよい。サイズｓ１を知ることによって、どのセクタｌｓ１が第１のＯＳによって使用される最終セクタであるかが容易に推定される。なぜなら、セクタのサイズは既知であるか、またはたとえばコンピュータの仕様などから入手可能だからである。なお、いくつかの特定の状況においては、ＯＳのサイズがデフォルトで既知になり得るように、いくつかのポリシ要求は許可されるネイティブＯＳの選択を１つまたはいくつかのＯＳバージョンに制限することがあり、そのために場合によっては第１のＯＳのサイズを算出するステップがスキップされ得る。

次に、部分ＢＩは、必ずしも第２のＯＳ１１１−２によって占有される第１のセクタに保存されていないため、ブートローダ１６は前記部分ＢＩを間接的に位置付ける必要があるかもしれない。これは、前記セクタｌｓ１を識別するデータに加えて、前記第２の部分１２０−２内の部分ＢＩの相対的位置（ｒｅｌａｔｉｖｅ ｌｏｃａｔｉｏｎ）ｒｌに関する情報のおかげで達成できる。部分ＢＩの相対的位置ｒｌは、デバイス１０によって既知であっても（そこに保存されていても）よいし、デバイス１０が接続し得るサーバ３０において（直接的または間接的に）別様に入手可能であってもよい。

これらの後ろ２つの実施形態はより特定的に、ＰＣ１０１に単一の記憶ディスクが設けられていて、両方のＯＳがこのディスクを共有する場合に関するものである。第２のＯＳの起動プロセスの間に第１の（ネイティブ）ＯＳを変更する必要がないように、ディスク上のどこに第２のＯＳが位置するかをブートローダから認識する必要がある。通常、この情報はディスク１２０の最初の区画テーブル１１１−１ｐ内に保存されるが、次いでこの情報はネイティブＯＳから通知される可能性があり、それは本発明の状況において望ましくない。よって本発明に従うシステムにおいては、反対にこの情報が存在することを避けることが好ましい。その代わりにブートローダは、ディスクの最初に見出されるネイティブＯＳの区画テーブルを読取り、たとえばネイティブＯＳがディスク上でどれほどのスペースを取っているかを算出する。本質的に、第１のＯＳのサイズは、既存の区画によってカバーされたディスクの部分である。次いでブートローダは、ディスクにおけるホームＯＳの後のセクタから第２のＯＳが始まることが見出されるものと想定する。次に、ブートローダは前述の機構を用いて部分ＢＩを位置付け、その保全性を定め、かつそれを実行してもよい。

興味深いことに、ブートローダはさらに、第１のＯＳ１１１−１によって占有された前記物理媒体１２０の部分をマスクするために、物理記憶媒体１２０（例、物理ディスク）
の上にオーバーレイ・ディスク１２０ｏを構築させる（ステップＳ１０ｃ）ように構成されてもよい。こうしたオーバーレイ・ディスクは、前記物理記憶媒体によって支えられた物理記憶媒体のソフトウェア表現であり、この物理記憶媒体は（ａ）実際の物理記憶装置、たとえばディスクなど、または（ｂ）複数のこうした記憶装置、または（ｃ）１つの物理記憶装置の一部であってもよい。

オーバーレイ・ディスクの構成は、すでに抽出された情報から利益を得てもよい。たとえばブートローダは、オーバーレイ・ディスクがセクタｆｓ２から、すなわちセクタｌｓ１の直後から始まるようにオーバーレイ・ディスクを構築してもよい。

したがって、本方法はさらに次のステップを含んでもよい。
−Ｓ１０ｃ：物理記憶媒体１２０の上にオーバーレイ・ディスク１２０ｏが構築される。
−Ｓ１１：構築されたオーバーレイ・ディスク１２０ｏにおいて、第２のホストＯＳ１１１−２ｅが実行される。これによって、
−Ｓ１２：第２のホストＯＳ１１１−２ｅの実行中に、第２のホストＯＳ１１１−２ｅのフレームワーク内でソフトウェア１１２が実行され得る。

なお、参照番号１１１−２は媒体１２０に保存された第２のＯＳを表すのに対し、参照番号１１１−２ｅは実行中の、すなわちメモリにロードされて実行されている第２のＯＳを示す。

オーバーレイ・ディスク構成がなければ、たとえば第２のＯＳに対する区画またはディスク全体が必要となる。しかし、どちらの場合にも第２のＯＳが第１のＯＳによって検出可能となり、よって第１のＯＳが第２のＯＳを損ない得ることとなる。そこでもし第２のＯＳが暗号化されれば、第１のＯＳは第２のＯＳにアクセスできなくなるが、なおもそれを上書きすることはできる。よって、オーバーレイ・ディスクを構築することが好ましい。

コンピュータ記憶装置の分野において公知であるとおり、大容量記憶装置のスペースを割り当てることを可能にする論理ボリューム管理（ｌｏｇｉｃａｌ ｖｏｌｕｍｅ ｍａｎａｇｅｍｅｎｔ）（すなわちＬＶＭ）の方法が公知である。こうした方法は、従来の分配スキームよりも柔軟である。特に、ボリューム・マネージャは複数の区画を連結するか、ともにストライプするか、または別様に組み合わせてより大きな仮想区画にすることができ、管理者はおそらくはシステム使用を妨げることなくそれをサイズ変更したり移動したりできる。たとえば、Ｗｉｋｉｐｅｄｉａ（Ｒ）のページｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｌｏｇｉｃａｌ＿ｖｏｌｕｍｅ＿ｍａｎａｇｅｍｅｎｔなどを参照されたい。本発明の場合、第２のＯＳがそのメイン「ディスク」として使用する仮想メモリ部分を作成するために、記憶媒体１２０の一部を割り当てるためにボリューム・マネージャが依拠されてもよい。それに関して用いられ得るいくつかのボリューム・マネージャ技術が利用可能である。

ブートローダには、オーバーレイ・ディスクを構築するための方法が備えられてもよい。しかし好ましくは、オーバーレイ・ディスクを直接構築するのはブートローダではなく、ブートローダが位置付けてメモリにロードするブート・イメージ、たとえば第２のＯＳのカーネルおよび初期ＲＡＭディスクなどである。すべての場合に、ブートローダは、コンピュータ１０１における実行の際に（例、ブート・イメージ（ｂｏｏｔ ｉｍａｇｅ）ＢＩに）物理記憶媒体１２０の上にオーバーレイ・ディスク１２０ｏを構築させるように設計されてもよい。

ソフトウェア１１２はたとえば、実行可能環境をカプセル化した、ゲストＯＳとして実行される仮想マシンであってもよい。これは、第１のホストＯＳ１１１−１がネイティブＯＳであり、第２のＯＳ１１１−２が企業ＯＳであるような本明細書で予期される状況において、セキュアなＢＹＯモデルの管理を可能にするために特に有利である。ゲストＯＳは特に、所与の企業ポリシに従って所与のユーザに属するデスクトップを表示するステップをもたらしてもよい。

デバイス１０を説明するときにすでに述べたとおり、好ましい方法は、オーバーレイ・ディスクを構築するステップの前に、さらに以下のステップを含んでもよい。
−Ｓ１０ａ：区画情報１１１−１ｐを読取るステップ、
−Ｓ１０ｂ：前記区画情報から、前記物理記憶媒体のどこに第２のホストＯＳ１１１−２が位置するかを推定するステップであって、これは好ましくは、前記物理記憶媒体１２０において第１のホストＯＳによって占有された第１の部分のサイズｓ１を算出することによって達成される、ステップ、および、
−Ｓ１０ｃ：オーバーレイ・ディスクが第１のホストＯＳによって占有された最終セクタｌｓ１の後、好ましくは直後に位置するセクタｆｓ２から始まるようにオーバーレイ・ディスクを構築するステップ。

オーバーレイ・ディスク構成のおかげで、第２のＯＳが起動を継続すること、すなわち第２のＯＳが自身のディスクを見出すこと、つまり自身が用いるディスクの部分を見出すことが容易に可能にされる。さらに、実行中の第２のＯＳは、ディスクの構成のために自身がディスク全体を有するものと「信じて」いる（オーバーレイ・ディスクは、好ましくは記憶媒体の端部まで続く）。こうしたオーバーレイ・ディスクを構築するさまざまなやり方が存在する。好ましい実施形態は、たとえばオーバーレイ・ディスクを作成するためにハイパーバイザによって利用可能なデバイス・マッパ構成を用いることである。しかし、ＶＭ内で第２のＯＳが実行される必要がない限り、ハイパーバイザは関与しないことを注記する（ハイパーバイザはオーバーレイとは無関係であり、オーバーレイはハイパーバイザの有無にかかわらずＯＳによって実装されてもよい）。

一方で、ネイティブＯＳは第２のＯＳが使用するスペースのことを、自身の使用範囲の外側の単なる空きスペースとして認識する。よって、ネイティブＯＳは第２のＯＳの存在をまったく知らない。第２のＯＳのすべてのトレースを除去するためには、この「空き」スペースを取り戻すことで十分である。

ここで図１、図２および図５をともに参照すると、前に触れたとおり、本発明はさらに、ポータブル・デバイス１０およびコンピュータ１０１を含むシステム１００として具現化されてもよい。第１のホストＯＳ１１１−１および第２のホストＯＳ１１１−２は、それぞれ記憶媒体１２０の第１の部分１２０−１および第２の部分１２０−２に保存される。パーソナル・コンピュータの物理記憶媒体の区画情報は、第１のホスト・オペレーティング・システム１１１−１は知らせるが、第２のホスト・オペレーティング・システム１１１−２は知らせない。

上に考察したとおり、好ましくは、第２のホストＯＳの部分ＢＩは、第２のオペレーティング・システムのカーネル、およびコンピュータを起動する際に関与するソフトウェアすなわち起動に必要なソフトウェア・ライブラリだけを含み、このソフトウェアはオーバーレイ・ディスクを構築するために必要なソフトウェアを含んでもよい。

加えて、前に述べたとおり、ファームウェア１２２は好ましくは次のうちの１つである。
−ＢＩＯＳ、
−エクステンシブル・ファームウェア・インタフェースＥＦＩ、または
−ユニファイド・エクステンシブル・ファームウェア・インタフェースＵＥＦＩ。

次に、図２に戻って、永続的メモリ１４は好ましくは以下を含む。
−好ましくはブートローダ１６の第１の部分１６１（または所与の部分）（もしくはデバイス１０の付加的なモジュール、またはその両方）を保存するセキュア・メモリ１４１、および
−ブートローダの第２の部分１６２（またはその他の部分）を保存する非セキュア・メモリ１４２、たとえばＳＤカードなど。

セキュア・メモリの存在によって、ユーザ・トラステッド・デバイスはセキュア・デバイスとなる。たとえば、モジュール１６の一部は暗号化されて非セキュア・メモリ１４２に存在してもよく、一方で対応する暗号化キーがセキュア・メモリ１４１に保存されてもよい。セキュア・メモリは典型的に、コスト上の理由から１２８ｋｏまたは２５６ｋｏに制限される。よってそれは、主にたとえばハッシュ／シグネチャ１３などの暗号化データを保存するために用いられることが好ましい。しかし、ブートローダの一部分１６１がセキュア・メモリ１４１に存在してもよく、一方でブートローダの他の部分１６２は暗号化されて非セキュア・メモリに存在してもよい。変形において、ブートローダ１６はセキュア・メモリ１４１に存在するシグネチャによって暗号化されて、ＳＤカードに存在する。コンピュータ１０１がブートローダ１６の所与のブロックまたは任意のデータ・チャンクを要求するとき、デバイスのＣＰＵ１１はメモリ１４内に存在するソフトウェアによって、たとえばセキュア・メモリ１４１に保存される暗号化データを用いるなどして要求されたブロックを復号化するように促されてもよい。

デバイス１０の接続インタフェース１２は、たとえば次のタイプのものであってもよい。
−ユニバーサル・シリアル・バス（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）すなわちＵＳＢ、
−外部の小型コンピュータ・システム・インタフェース（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）すなわちＳＣＳＩ、
−外部のシリアル・アドバンスト・テクノロジ・アタッチメント（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）すなわちＳＡＴＡ、
−Ｆｉｒｅｗｉｒｅ（Ｒ）、または
−Ｔｈｕｎｄｅｒｂｏｌｔ（Ｒ）。
しかし、より一般的にこれは、コンピュータが外部デバイス１０から起動することを可能にするあらゆる現行または将来のコネクタであってもよい。加えて、その同じインタフェース１２が、たとえばプロジェクタ、プリンタ、または任意のその他の出力デバイスなどの任意の外部デバイスと、ユーザ・トラステッド・デバイス１０とが通信することを可能にしてもよい。

通常どおり、ユーザ・トラステッド・デバイス１０には、メモリに結合されたたとえば暗号プロセッサなどの処理手段（またはコンピューティング手段、すなわちＣＰＵ）１１が提供されてもよく、メモリはより一般的には永続的メモリ１４を含み、好ましくは非永続的メモリも含む（明確に示されていないが、非永続的メモリは処理手段１１の一部と考えられ得る）。

この状況において、永続的メモリは特に、上述したブートローダを超えて、処理手段１１によって少なくとも部分的に実行されるコンピュータ化された方法を保存する。もちろん、本明細書に記載されるデバイスのさまざまな機能は、異なる機能が提供され、かつコンピュータ１０１において実行可能であるか、またはコンピュータ１０１およびデバイス１０において部分的に実行可能な１つの同じ（スーパー）モジュールとして考えられてもよい。

必要であれば、セキュア・デバイス１０は、たとえば非セキュア・メモリ１４２または任意のスマート・カードなどのメモリ・カードに保存されたユーザの信用証明を読取るためのカード・リーダを有する。好適な使用は、たとえばカードに保存されたユーザの信用証明などのこうしたデータから安全に行われ得る。特に、ホスト１０１を介し、かつこうしたデータを用いて、ユーザ（または厳密にいえばデバイス１０）と、たとえばサーバ３０などの第三者との間に信頼できる接続を確立できる。変形において、ユーザの信用証明はセキュア・デバイスに直接保存されてもよい。ユーザとの対話を可能にするために、さらなるインタフェース（制御ボタンおよびディスプレイなど）が提供されてもよい。

最後に、前に触れたとおり、デバイス１０またはブートローダ１６はさらに、たとえばサーバなどの外部エンティティ３０に接続するように設計されてもよい。この機能は、たとえばデバイス１０の特定の接続モジュールによって提供されてもよい。このモジュールは、好ましくはコンピュータ１０１を介してサーバ３０に接続するよう指示するために、デバイス１０またはコンピュータ１０１において実行されてもよい。サーバ３０への接続は、いくつかのやり方で実現され得る。最も有利なのは、第２のＯＳの助けを伴うか、または伴わずに、コンピュータ１０１を介してサーバ３０に接続することである。サーバに送られるデータはデバイス１０において暗号化され、サーバ３０から受信されるデータはデバイス１０によって復号される。これによって、通信チャネルのエンド−エンド・セキュリティが確実になる。

たとえば、接続モジュールはファームウェア１２２と対話することによって、その後コンピュータ１０１のネットワーク・カード１２４と対話してもよく、これはサーバ３０に接触できるようにネットワーク・カード１２４によって可能にされるネットワーク１６５を通じた通信を開始するためである。よってその場合、接続モジュールは外部エンティティとの通信を可能にするためにホスト・コンピュータのファームウェアに依拠するため、このデバイスは組み込みネットワーク・カードもネットワーク・イネーブル・デバイスも必要としないし、ホスト１０１のネットワーク・カード１２４に対するドライバを保存する必要もない。なお、ネットワーク・カード１２４を初期化するためにファームウェア１２２を用いる代わりに、接続モジュールはデバイス１０に保存されたネットワーク・カード・ドライバにアクセスして、ネットワーク・カード１２４と直接対話することによって、外部エンティティ３０と接触してもよい。しかし、その場合にはデバイス１０において好適なネットワーク・カード・ドライバを保存し、かつおそらくは更新する必要がある。さらに、より「根本的な」代替形として、たとえばサーバに直接接続するために、たとえばネットワーク・デバイス（有線またはワイヤレス）などを有するネットワーク・アクセス手段をデバイス１０に備えることが好ましいことがある。その場合、接続モジュールはデバイスにおいて実行される。こうした解決策は、多少高価になる。しかし、サーバに接触するためにコンピュータ１０１と付加的な対話を行う必要がないため、待ち時間が低減される。

上記の実施形態は添付の図面を参照しながら簡潔に説明されており、いくつかの変形に適応してもよい。上記の機能のいくつかの組み合わせが予期されてもよい。その例を次のセクションに示す。

２．特定的実施形態／技術的実装の詳細
本セクションにおいては特定的実施形態を説明し、ここでは以下の選択肢が想定される。
−第１のＯＳはネイティブ（ホーム）ＯＳであり、第２のＯＳは企業ＯＳである。かつ、
−ブートローダによって位置付けられる実行可能部分ＢＩはブート・イメージである。
前セクションで詳細に説明したとおり、本アプローチは外部デバイス１０に存在するブートローダ１６に依拠するものである。便利であるように、このデバイスはＵＳＢコネクタ１２を有する。なぜなら、現代のすべてのファームウェアはこうしたデバイスを認識できるからである。ブートローダは、デバイス上の耐タンパ記憶装置１４１に少なくとも部分的１６１に保存されており、これは許可されたエンティティ以外のエンティティには変更できないことを意味する。

ステップＳ１において、ユーザ・デバイス１０およびコンピュータ１０１が提供される。マシン１０１にトラステッド・デバイスが挿入され、マシンがオンにされる（ステップＳ２）。マシンのファームウェア１２２はトラステッド・デバイス１０を認識し、かつそれが起動可能であることを識別する（ステップＳ３）。ファームウェアによって、マシンのメモリ１２１にブートローダ１６がロードされ（ステップＳ４）、かつ実行される（ステップＳ５）。

前に考察したとおり、ブートローダは、コンピュータ１０１のディスク１２０のブート・イメージＢＩを含む部分にアクセスするように構成される。ディスクにおいてブート・イメージが位置付けられるとき（ステップＳ６）、ブートローダは単純に非暗号化ブート・イメージの内容の保全性をテストしてもよいし、トラステッド・デバイス１０に保存されたキー１３を用いてブート・イメージを復号してもよい（ステップＳ７）。

前者の場合には、完全なブート・イメージの内容のハッシュ１３をデバイス１０に保存して、起動のたびにディスクに見出されるものをこれと比較することで十分である。ブート・イメージは、ＯＳのカーネル、および起動の際に有用ないくつかのライブラリだけを含んでもよく、結果としてかなり小さくなる。

後者の場合には、ブートローダは保存されたキー１３を用いてブート・イメージを復号してもよい。これは単純に内容の保全性を確実にすることよりも良好なセキュリティを提供するが、ソフトウェアの更新の複雑性を増大させる。代替的に、ブート・イメージ自体がトラステッド・デバイスに保存されてもよい。これはブートローダの保全性を確実にするが、トラステッド・デバイスにおけるより多くの記憶装置を必要とし、加えて実際にはより頻繁な更新を必要とする。

デバイス１０には、好ましくはスクリーンと、要求を承認または拒絶する手段とが備えられる。よってユーザは、ブートローダもしくはキーまたはその両方が利用可能にされるべきであることを確認するように促されてもよい。その環境は２つのホストＯＳ１１１−１、１１１−２からなり、その一方は家庭（ホーム）用、他方は企業用である。しかし、（雇用者によって提供される）デバイス１０が存在するときには、第２のＯＳ１１１−２のみが起動可能である。もしホームＯＳがマシン１０１の第２のディスクに新たなＯＳをインストールすれば、これはトラステッド・デバイスによって起動可能にならない。本スキームはトラストのチェーンを含み、ここではトラステッド・ブートローダ１６が予め保存された情報または別様に取得可能な情報を通じてブート・イメージの保全性を確認し、さらにブート・イメージがユーザとの対話を通じて残りのＯＳの保全性を確認する。トラステッド・デバイスは、ブートローダ１６と、たとえばハッシュ値またはキー、すなわち保全性チェック・データなどの何らかの付加的情報１３とを保存することが要求される。それは数百キロバイトのデータに符号化されてもよく、めったに変化しないことが予期されてもよい。ディスクに存在するブート・イメージは、企業ＯＳのカーネルならびにいくつかの有用なドライバおよびアプリケーションを含む。それは数十メガバイトに符号化されてもよく、かつカーネルおよび重要なライブラリがパッチされる必要があるたびに変化することが予期されてもよい。これらのコンポーネントの更新はリモートに行われる。ステップＳ８において、ブート・イメージが実行される。トラステッド企業環境１１１−２ｅが実行されるとき（ステップＳ１１）、それらのコンポーネントが最新のものであるか、最新のものでない場合はそれらが変更され得ないかを確認してもよい。

好ましい実施形態においては、全従業員に単一の一意のイメージが配置され得るように、雇用者のホストＯＳ１１１−２は従業員によって変更不可能であり、これによってセキュリティが高められ、かつシステムの更新が単純化される。次いで、企業ホストＯＳ１１１−２は、従業員に割り当てられた企業ＶＭを安全に実行するための単純な手段となる。このＶＭは、それが実行するソフトウェアに関して従業員に対してカスタマイズされてもよく、かつ通常のデスクトップ・マシンと同じやり方でユーザによって変更されてもよい。そのマシンが家庭用に用いられるとき、マシンは単純にオンにされて、対応するディスクまたはディスク区画を起動する。そのマシンが会社用に用いられるとき、会社から供給されたトラステッド・デバイス１０がユーザによって挿入される。ファームウェアは、このデバイスに保存されたブートローダをメモリに読込み、このブートローダはディスクに保存されたブート・イメージを読取り、かつその保全性をテストする。もしブート・イメージが完全であれば、次いでブート・イメージは、会社ホストＯＳの暗号化ルート・ファイル・システムをマウントする。次いでＶＭはこのファイル・システムのファイルとして保存され、次いで実行されてもよい、ステップＳ１２。

企業ＶＭは企業ホストＯＳにおいて実行されるため、会社は、任意のＯＳが適切な仮想マシン・マネージャを支援してさえいればそれをホストＯＳとして自由に選択できる。たとえば、企業ＶＭはウィンドウズ（Ｒ）７デスクトップ・マシンであってもよく、一方で企業ホストＯＳはリナックス（Ｌｉｎｕｘ）（Ｒ）であってもよい。

好ましい実施形態において、ホストＯＳ１１１−２は明示的なブート・イメージＢＩを支援する。そうでない場合は、イメージが作成されるときに実行されるイメージ生成フェーズを用いてＯＳからブート・イメージが抽出されてもよいし、別のＯＳがブート・イメージとして使用されてもよい。

ブートローダには付加的な機能がさらに提供されてもよく、それらの機能は、マシン１０１が単一のディスク１２０を有し、ホームＯＳおよび企業ＯＳの両方がこのディスクを共有するときに特に有利である。企業ＯＳの起動プロセスの間にホームＯＳを変更しないためには、ディスクのどこに企業ＯＳが位置するかをブートローダから認識できる必要がある。通常この情報は、ディスクの最初の区画テーブルに保存されているが、これは次いでホームＯＳから通知され得るために、本発明の状況においては容認できない。代わりにブートローダは、ディスクの最初に見出されるホームＯＳの区画テーブルを読取って、ホームＯＳがディスク上でどれほどのスペースを取っているかを算出する（本質的に、ホームＯＳのサイズは既存の区画によってカバーされたディスクの部分である）。次いでブートローダは、ディスク上のホームＯＳの後のセクタから企業ＯＳが始まることが見出されるものと想定して、企業ＯＳを位置付ける（ステップＳ６）。ブートローダは前述のハッシュ機構を用いて、企業ＯＳのブート・イメージの保全性をチェックし（ステップＳ７）、起動のためにそれをメモリにロードする、ステップＳ８。ブート・イメージは、企業ＯＳディスク内の何らかの予め定められた位置に保存される。

加えて、企業ＯＳが自身のディスク（すなわちそれが使用するディスクの部分）を見出して起動を続けるために、起動プロセスはより効果的に実際の物理ディスク１２０の上にオーバーレイ・ディスク１２０ｏを構築し（ステップＳ１０ａ〜ｃ）、それによってネイティブ・ホームＯＳに使用されるディスクの部分をマスクする。これを行うために、起動プロセスはネイティブ区画テーブルを読取り（Ｓ１０ａ）、オーバーレイ・ディスクがネイティブＯＳによって使用される最終セクタの後のセクタから始まりかつディスクの端部まで続くように、オーバーレイ・ディスクを構築する（Ｓ１０ｃ）。企業ＯＳを保存するためにディスク上の十分な空きスペースが利用可能となるように、ユーザはネイティブＯＳの区画を縮小させたものと想定する。ネイティブＯＳは、企業ＯＳが使用するスペースのことを、自身の使用範囲の外側の単なる空きスペースとして認識する。さもなければ、ネイティブＯＳは企業ＯＳの存在をまったく知らない。企業ＯＳのすべてのトレースを除去するためには、この空きスペースを取り戻すことで十分である。オーバーレイ・ディスクの構成によって、実行時の企業ＯＳは、自身がディスク全体を有するものと信じている。オーバーレイ・ディスクの構成は図５に示される。

限られた数の実施形態、変形および添付の図面を参照して本発明を説明したが、本発明の範囲から逸脱することなく、さまざまな変更が加えられてもよいし、同等物が置換されてもよいことが当業者に理解されるだろう。特に、所与の実施形態、変形において述べられるか、または図面に示される特徴（デバイスまたは方法の形）は、本発明の範囲から逸脱することなく、別の実施形態、変形または図面における別の特徴と組み合わされるか、または置き換えられてもよい。したがって、上記の実施形態または変形のいずれかに関して記載された特徴のさまざまな組み合わせが予期されてもよく、それらは添付の請求項の範囲内にとどまる。加えて、本発明の範囲から逸脱することなく、特定の状況または材料を本発明の教示に適合させるために、多くの微細な修正が加えられてもよい。したがって、本発明は開示される特定の実施形態に限定されず、本発明は添付の請求項の範囲内にあるすべての実施形態を含むことが意図される。さらに、上記において明確に触れられたもの以外の多くのその他の変形が予期され得る。たとえば、デバイス１０は太陽電池またはあらゆるその他の好適なバッテリなどによって電力供給されてもよい。前に触れたとおり、本明細書に記載されるコンピュータ化された方法は、その主要な機能によって分類されている。すなわち、ブートローダをコンピュータ（１０１）に移し（ステップＳ４）、かつそこで実行させて（ステップＳ５）、第２のホスト・オペレーティング・システムの実行可能部分ＢＩを位置付け（ステップＳ６）、かつそれを実行する（ステップＳ８）。これらの主要な機能はブートローダに割り当てられるものとして記載されている。しかし、これらの機能のうちの１つまたはそれ以上を各々が提供することが意図された２つまたはそれ以上のモジュールに分散された同じ機能によって、本発明の実施形態が同等に説明され得る。

１０ ユーザ・トラステッド・デバイス
１１ セキュア・デバイスのＣＰＵ
１２ 接続インタフェース
１４ 永続的メモリ
１６ ブートローダ／起動イネーブル・データ構造
３０ サーバ
１００ 一般的コンピュータ・システム
１０１ ホスト・コンピュータ
１０５ プロセッサ
１１０ メモリ
１１１ オペレーティング・システム（ＯＳ）
１１５ メモリ・コントローラ
１２０ 物理記憶媒体（物理ディスク）
１２０−１ 物理記憶媒体１２０の第１の部分
ｓ１ 物理記憶媒体の第１の部分のサイズ
ｌｓ１ 物理記憶媒体の第１の部分の最終セクタ
１２０−２ 物理記憶媒体の第２の部分
ｆｓ２ 物理記憶媒体の第２の部分の第１のセクタ
１２２ ホスト・コンピュータのファームウェア（ＢＩＯＳ）
１２４ ネットワーク・カード
１２５ ディスプレイ・コントローラ
１３０ ディスプレイ
１４１ セキュア・メモリ
１４２ 非セキュア・メモリ
１４５ Ｉ／Ｏデバイス（または周辺装置）
１５０ キーボード
１５５ マウス
１６１ ブートローダの第１の部分
１６２ ブートローダの第２の部分
１６５ ネットワーク

Claims (15)

1. ユーザ・ポータブル・デバイス（１０）であって、
   コンピュータ（１０１）との接続（Ｓ２）を可能にする接続インタフェース（１２）と、
   永続的メモリ（１４）と、
   前記永続的メモリ（１４）のセキュア・メモリ（１４１）に保存されたブートローダ（１６）とを含み、
   前記ブートローダ（１６）は、
   前記接続インタフェースを介した前記デバイス（１０）と前記コンピュータ（１０１）との接続（Ｓ２）の際に、前記コンピュータ（１０１）のファームウェア（１２２）によって検出可能（Ｓ３）であり、かつ
   前記ファームウェア（１２２）が前記ブートローダ（１６）を以後の実行（Ｓ５）のために前記コンピュータ（１０１）のメモリ（１２１）にロードする（Ｓ４）ための命令と、
   前記コンピュータ（１０１）における実行の際に前記ファームウェアと対話することによって、
   第１のホスト・オペレーティング・システム（１１１−１）および第２のホスト・オペレーティング・システム（１１１−２）をそれぞれ第１の部分（１２０−１）および第２の部分（１２０−２）に保存する前記コンピュータ（１０１）の物理記憶媒体（１２０）において、前記物理記憶媒体の区画情報（１１１−１ｐ）から前記第２の部分（１２０−２）を定めることであって、前記区画情報は前記第１のホスト・オペレーティング・システムは知らせるが前記第２のホスト・オペレーティング・システムは知らせない、定めることと、
   前記第２の部分（１２０−２）内の前記第２のホスト・オペレーティング・システム（１１１−２）の一部分（ブート・イメージ：ＢＩ）を位置付けることと、
   前記部分（ＢＩ）を実行することによって、前記ホスト・オペレーティング・システムのうち前記第２のものだけが前記ユーザ・ポータブル・デバイス（１０）から起動し得る（Ｓ６〜Ｓ８）ようにすることとを行うための命令とを含む、ユーザ・ポータブル・デバイス（１０）。
2. 前記ユーザ・ポータブル・デバイスはさらに、前記セキュア・メモリ（１４１）に保存された保全性チェック・データ（１３）を含み、前記ブートローダはさらに、前記保全性チェック・データ（１３）に基づいて前記部分（ＢＩ）の保全性をチェックする（Ｓ７）ように構成される、請求項１に記載のユーザ・ポータブル・デバイス（１０）。
3. 前記ブートローダ（１６）は、前記部分の内容をハッシュし、結果として得られたハッシュ値を前記保全性チェック・データ（１３）に対してチェックすることによって前記第２のホスト・オペレーティング・システム（１１１−２）の前記部分（ＢＩ）の前記保全性をチェックするように構成される、請求項２に記載のユーザ・ポータブル・デバイス。
4. 前記ブートローダはさらに、前記コンピュータ（１０１）における実行の際に、前記物理記憶媒体に保存される、前記第１のオペレーティング・システムによって使用される最終セクタ（ｌｓ１）の後、直後に始まる前記物理記憶媒体（１２０）の所与のセクタ（ｆｓ２）から前記部分（ＢＩ）を探索することによって、前記部分（ＢＩ）を位置付けるように構成される、請求項１から３のいずれか１項に記載のユーザ・ポータブル・デバイス（１０）。
5. 前記ブートローダはさらに、前記コンピュータ（１０１）における実行の際に、前記物理記憶媒体の区画情報（１１１−１ｐ）に基づいて前記第１の部分のサイズを算出し、かつどのセクタ（ｌｓ１）が前記第１のオペレーティング・システムによって使用される前記最終セクタであるかを推定するように構成される、請求項４に記載のユーザ・ポータブル・デバイス（１０）。
6. 前記ブートローダはさらに、前記コンピュータ（１０１）における実行の際に、
   前記所与のセクタ（ｌｓ１）と、
   前記第２の部分（１２０−２）に保存された前記第２のホスト・オペレーティング・システム（１１１−２）内の前記部分（ＢＩ）の相対的位置（ｒｌ）のデータと
   に基づいて、間接的に前記部分（ＢＩ）を位置付けるように構成される、請求項５に記載のユーザ・ポータブル・デバイス（１０）。
7. 前記ブートローダはさらに、前記コンピュータ（１０１）における実行の際に、前記第１のホスト・オペレーティング・システム（１１１−１）によって占有された前記物理記憶媒体の部分をマスクするために、前記物理記憶媒体（１２０）の上にオーバーレイ・ディスク（１２０ｏ）を構築させる（Ｓ１０ａ〜ｂ）ように構成され、前記オーバーレイ・ディスクは、前記物理記憶媒体によって支えられた物理記憶媒体のソフトウェア表現であり、
   前記ブートローダはさらに、前記コンピュータ（１０１）における実行の際に、前記オーバーレイ・ディスクが前記第１のホスト・オペレーティング・システムによって占有された最終セクタの後、直後の前記物理記憶媒体のセクタから始まるように前記オーバーレイ・ディスクを構築させるように構成される、請求項１から６のいずれか１項に記載のユーザ・ポータブル・デバイス（１０）。
8. 請求項１から７のいずれか１項に記載のユーザ・ポータブル・デバイス（１０）と、前記接続インタフェース（１２）を介して前記ユーザ・ポータブル・デバイスを接続可能な前記コンピュータ（１０１）とを含むシステム（１）であって、前記コンピュータ（１０１）は、前記第１の部分および第２の部分にそれぞれ保存された前記第１のホスト・オペレーティング・システム（１１１−１）および前記第２のホスト・オペレーティング・システム（１１１−２）を有し、前記コンピュータの前記物理記憶媒体の区画情報は、前記第１のホスト・オペレーティング・システム（１１１−１）は知らせるが前記第２のホスト・オペレーティング・システム（１１１−２）は知らせない、システム。
9. 前記第２のホスト・オペレーティング・システムの前記部分（ＢＩ）が非暗号化ブート・イメージであり、当該部分（ＢＩ）は、
   前記第２のオペレーティング・システムのカーネル、および
   前記コンピュータを起動する際に関与するソフトウェアのみを含む、請求項８に記載のシステム。
10. 請求項８または９に記載のシステムにおいてコンピュータ（１０１）を起動する方法であって、前記方法は、前記ユーザ・ポータブル・デバイスと前記コンピュータ（１０１）との接続（Ｓ２）の際に、
    前記コンピュータ（１０１）の前記ファームウェア（１２２）によって前記ユーザ・ポータブル・デバイス（１０）の前記ブートローダ（１６）が検出される（Ｓ３）ようにすることによって、前記ファームウェアに対する前記ブートローダ（１６）の命令に従って、前記ブートローダが前記コンピュータ（１０１）に移って（Ｓ４）前記コンピュータ（１０１）において実行する（Ｓ５）ことによって、
    前記第２のホスト・オペレーティング・システムが起動し、かつ前記ホスト・オペレーティング・システムのうち前記第２のものだけが前記ユーザ・ポータブル・デバイス（１０）から起動し得る（Ｓ８〜Ｓ１１）ように、
    前記第２のホスト・オペレーティング・システム（１１１−２）の一部分（ＢＩ）を位置付けし（Ｓ６）、かつ実行する（Ｓ８）ステップを含む、方法。
11. 前記第１のホスト・オペレーティング・システム（１１１−１）によって占有された前記物理記憶媒体の部分をマスクするために、前記物理記憶媒体（１２０）の上にオーバーレイ・ディスク（１２０ｏ）を構築するステップ（Ｓ１０ａ〜ｂ）であって、前記物理記憶媒体（１２０）は物理ディスクであり、前記オーバーレイ・ディスクは前記物理記憶媒体によって支えられた物理記憶媒体のソフトウェア表現である、ステップと、
    構築された前記オーバーレイ・ディスク（１２０ｏ）において前記第２のホスト・オペレーティング・システム（１１１−２ｅ）を実行するステップ（Ｓ１１）と、
    実行中の前記第２のホスト・オペレーティング・システム（１１１−２ｅ）においてソフトウェア（１１２）を実行するステップ（Ｓ１２）と
    をさらに含む、請求項１０に記載の方法。
12. 前記オーバーレイ・ディスクを構築するステップの前に、
    前記物理記憶媒体（１２０）の区画情報（１１１−１ｐ）を読取るステップ（Ｓ１０ａ）と、
    前記区画情報から、前記物理記憶媒体における前記第１のホスト・オペレー
    ティング・システムによって占有された第１の部分のサイズ（ｓ１）を算出することによって、前記物理記憶媒体のどこに前記第２のホスト・オペレーティング・システム（１１１−２）が位置するかを推定するステップ（Ｓ１０ｂ）と、
    前記オーバーレイ・ディスクが
    前記第１のホスト・オペレーティング・システムによって占有された最終セクタ（ｌｓ１）の後、直後の前記物理記憶媒体のセクタ（ｆｓ２）から始まり、かつ
    前記物理記憶媒体の端部まで続く
    ように前記オーバーレイ・ディスクを構築するステップ（Ｓ１０ｃ）と
    をさらに含む、請求項１１に記載の方法。
13. 前記第２のホスト・オペレーティング・システムにおいてソフトウェアを実行するステップはさらに、
    前記第２のホスト・オペレーティング・システム（１１１−２ｅ）において仮想マシン（１１２）をゲスト・オペレーティング・システムとして実行するステップ（Ｓ１２）を含み、前記ゲスト・オペレーティング・システムは実行可能環境をカプセル化する、請求項１１または１２に記載の方法。
14. 前記第１のホスト・オペレーティング・システム（１１１−１）は個人のオペレーティング・システムであり、
    前記第２のオペレーティング・システム（１１１−２）は企業のオペレーティング・システムであり、
    前記仮想マシン（１１２）を実行するステップの結果として、所与のユーザに属するデスクトップを表示するステップが得られる、請求項１３に記載の方法。
15. 請求項１０〜１４の何れか1項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。

Images