JP2010520528A - 複数のブート可能装置間のブートネゴシエーション - Google Patents

Abstract

第１の装置が第２の装置の能力を発見する。第１の装置は、第１の装置及び第２の装置の能力の少なくとも一部に基づいて、第１の装置及び第２の装置のいずれが制御ブートイメージを実行するのかを判別する。第１の装置が制御ブートイメージを実行すると判別されたとき、第１のブートイメージは第１の装置によって実行され、第２の装置が第１のブートイメージ用のリソースとされる。第２の装置が制御ブートイメージを実行すると、判別されたとき第１の装置は第１の装置に記憶された第２のブートイメージを第２の装置に送信し、第１の装置が第２のブートイメージ用のリソースとされる。

Description

モバイル装置は他の計算装置に度々接続される。従来の装置間の関係は、装置が接続される前に仮定される。例えば、ユーザが携帯電話機をパーソナルコンピュータに接続するとき、パーソナルコンピュータは、しばしば携帯電話機に対するホストとして動作すると想定される。現在のシステムは、装置の能力に基づく装置の役割についてネゴシエーションを行わない。

基本的な理解を与えるために開示技術の簡単な概略を次に示す。この概略は開示技術の広範囲に亘る概要ではなく、発明の主要／重要な要素を示したり、或いは発明の範囲の輪郭を描くものではない。その１つの目的はこの後に示される、発明を実施するための形態の前置きとして本明細書に開示された概念を簡単な形式で表すことである。

発明の実施形態は複数のブート可能装置に対してどの装置がブートネゴシエーションに基づいて制御ブートイメージを実行するか決定させることができる。残りの装置はその制御ブートイメージ用のリソースとして作用しても良い。そのブート決定は各装置のリソース、予め定められた方針、及び／又はユーザインタラクションに基づいても良い。

添付図面と関連して考慮される以下の詳細な説明を参照してより理解されるのと同様に、多くの付随する特徴がより容易に理解される筈である。

同一の参照番号は添付図面の同一部品を指し示すために用いられる。

本発明の実施形態に応じたモバイル装置に接続されるドックのブロック図である。 本発明の実施形態に応じたモバイル装置のブロック図である。 本発明の実施形態に応じたブートネゴシエーションを行うモバイル装置とドックとのロジック及び動作を示すフローチャートである。 本発明の実施形態に応じた図３のフローチャートの続きである。 本発明の実施形態に従って仮想マシンブートイメージを与える移動電話機のブロック図である。 本発明の実施形態に応じたブートネゴシエーションを行う移動電話機とラップトップとのブロック図である。 本発明の実施形態に応じた能力報告テーブルである。 本発明の実施形態に応じたブートネゴシエーションを行う移動電話機とパーソナルコンピュータとのブロック図である。 本発明の実施形態を実行する計算装置の例のブロック図である。

添付図面と関連して以下に与えられる詳細な説明は本例の説明とされ、本例を構成又は利用する形態だけを表しているのではない。説明は例の機能、及び例を構成し実行するためのステップのシーケンスを示している。しかしながら、同一又は均等の機能及びシーケンスを他の例で達成しても良い。

以下の詳細な説明及び特許請求の範囲においては、用語「連結した」及びその派生語が用いられる。「連結した」は２以上のエレメントが（物理的に、電気的に、磁気的に、光学的に等）接触状態にあることを意味する。また、「連結した」は２以上のエレメントが互いに接触状態になく、互いに協同又は作用すること（例えば、通信上で連結した）を意味しても良い。

図１及び次の議論は、本発明の実施形態を実行するために適切なコンピューティング環境の簡潔で一般的な説明を与える。図１の動作環境は適切な動作環境の単なる１例であり、使用の範囲又は動作環境の機能性に関するいかなる限定の示唆も意図していない。必須ではないが、本発明の実施形態は１以上の計算装置によって実行される「コンピュータ可読命令」の一般的なコンテキストにて説明される。コンピュータ可読命令はコンピュータ可読媒体を介して分配されても良い。コンピュータ可読命令は、特定のタスクを行い、又は特定のアブストラクトデータタイプを実行する機能、オブジェクト、アプリケーションプログラミングインターフェース（ＡＰＩ）、データ構造等のプログラムモジュールとして実行されても良い。通常は、コンピュータ可読命令の機能性は、様々な環境で望まれるように組み合わせたり又は分配することができる。

図１は、接続１１６を介してモバイル装置１２０に接続されたドック１０２を示している。本明細書に用いられたように、ドックはモバイル装置１２０等のモバイル装置に接続可能な計算装置を示す。本発明の実施形態では、ドックの性能と、モバイル装置１２０に記憶されたブートイメージから起動するドックの能力とを判断する。例えば、ドック１０２はモバイル装置クレードル等の「ダム」ドックを含む。モバイル装置クレードルは他の計算装置との接続を容易にするモバイル装置ポートを単に再現する。他の例では、ドック１０２はラップトップ等の「スマート」ドックを含む。ラップトップは処理ユニット、メモリ、記憶装置等を有する。

ドック１０２は、処理ユニット１０４及びメモリ１０６を含む。また、ドック１０２は、モバイル装置１２０からデータを入力／出力する通信接続部１１４を含む。ドック１０２はハードディスクドライブ又はフラッシュメモリ等の記憶装置１０８を含む。

ドック１０２は、ＲＯＭやフラッシュメモリ等の不揮発性記憶装置（ＮＶＳ：Non-Volatile Storage)１１０を含む。ＮＶＳ１１０は処理ユニット１０４上の実行のためにファームウエア（Ｆ／Ｗ）１１２を記憶している。１の実施形態では、ファームウエア１１２は、オペレーションシステム（ＯＳ）のロード前にプリブートルーチンのための命令及びドック１０２の実行を含む。ファームウエア１１２は、ＯＳ実行中の間、ドック１０２の装置と通信するためのローレベル入力／出力命令を含む。また、ファームウエア１１２は基本入力／出力システム（ＢＩＯＳ）を示しても良い。

典型的なアーキテクチャにおいては、計算装置の初期化及び環境設定はプリブートフェーズとして通常称される。プリブートフェーズは、プロセッサリセットとオペレーションシステム（ＯＳ）ローダの第１命令との間に実行するファームウエアとして一般的に定められている。プリブートの間に実行する命令は、基本入力／出力システム（ＢＩＯＳ）として度々称される。プリブートの開始の際には、システムをハードディスク等の媒体のＯＳの読み込みオフが引き継ぎできるポイントに初期化するかどうかは、ファームウエアにおける命令によって決まる。ＯＳロードの開始は、ＯＳ実行中と共通に参照される期間に起きる。ＯＳ及び／又はアプリケーションを実行するための命令はブートイメージと称される。

ＯＳ実行中の間、ＢＩＯＳはコンピュータシステムのソフトウエア及びハードウエアのコンポーネント間のインターフェースとして作用しても良い。ＯＳレベルとハードウエアレベルとの間の動作環境はＢＩＯＳと一般に称される（時々ファームウエア環境と称される）。また、ＡＣＰＩ（Advanced Configuration and Power Interface）仕様書で定義されているスリープ状態等のスリープ状態にＯＳが入ったときには、ＯＳの活動を停止しても良い。ＢＩＯＳは、ＯＳをスリープ状態から復帰することに関係しても良い。

モバイル装置１２０を参照すると、１の実施形態において、モバイル装置１２０は移動電話機、メディアプレーヤ等の独立した計算装置を含んでも良い。他の実施形態では、モバイル装置はＵＳＢ(Universal Serial Bus)、フラッシュドライブ、メモリカード、スマートカード等のホスト依存のモバイル装置を含んでも良い。本明細書に用いられたように、「ホスト依存」は、ホストに接続されない限り利用されないモバイル装置に関係する。

モバイル装置１２０は、記憶装置１２６に接続されたコントローラ１２４を含む。コントローラ１２４は記憶装置１２６のデータの読み取り／書き込みを管理すると共に他の機能を行う。記憶装置１２６は磁気ディスクドライブ、光ドライブ、フラッシュメモリ等の不揮発性記憶装置、及びその他を含む。また、モバイル装置１２０は、モバイル装置１２０を他の計算装置と接続するための１以上の通信接続部１２２を含む。

接続１１６は、通信接続部１１４でのドック１０２と、通信接続部１２２でのモバイル装置１２０との間における有線又は無線接続を含む。１の実施形態では、ドック１０２とモバイル装置１２０とは、ユーザのパーソナルエリアネットワーク（Personal Area Network: PAN)の一部として互いに近接している。接続１１６の例は、ＵＳＢ（有線又は無線）、ｆｉｒｅｗｉｒｅ(IEEE 1394)、無線周波数（例えば、ブルートゥース（登録商標）、Ｗｉ−Ｆｉ等）、赤外線等を含む。

図２を参照すると、モバイル装置１２０の実施形態が示されている。コントローラ１２４は処理ユニット２０２と不揮発性記憶装置（ＮＶＳ）２０４とを含む。処理ユニット２０２は、３２ビットの縮小命令セットコンピュータ(Reduced Instruction Set Computer: RISC)等の一般のプロセッサを含む。単一処理ユニット２０２を示したが、モバイル装置１２０の実施形態は多重プロセッサ、多重コア等の多重処理ユニットを含んでも良い。１の実施形態において、コントローラ１２４は、暗号技術、ディジタル権限管理、ディジタル信号処理等の専門動作を実行する専用回路（図示せず）を含んでも良い。

１の実施形態においては、ＮＶＳ２０４は、処理ユニット２０２によって実行されるファームウエア２０６を記憶している。ファームウエア２０６は、装置ブートイメージを含むことができる。装置ブートイメージは、モバイル装置１２０上での実行のために、（リアルタイムオペレーティングシステム(Real-Time Operating System: RTOS)等のオペレーティングシステムや１以上のアプリケーション等を含むことができる。また、ファームウエア２０６は、本発明の実施形態を実行する命令を含むことができる。

図２の実施形態は、区分２３０及び区分２４０に分割された記憶装置１２６を示している。この説明についての利益を持つ分野の当業者は、記憶装置１２６が２つの以上の区分を含んでも良いことを理解できるだろう。区分２３０は、装置データ２３１等のモバイル装置１２０用の命令及び／又はデータを含む。モバイル装置１２０は、固有の又は仮想マシン内のソフトウエアを実行することができる。ドック１０２等の接続された計算装置によって、区分２３０へのアクセスを保護するために安全対策が用いられても良い。

区分２４０は、ドック１０２等の他の計算装置による使用のための命令及び／又はデータを含むことができる。図２は、ブートイメージ２４１，２４２及び２４３を有する区分２４０を示している。ブートイメージは、計算装置上のＯＳ及び／又はアプリケーションを実行するための命令を含む。ブートイメージの例としては、マイクロソフトウインドウズ（登録商標）ＯＳ及び／又はオフィスアプリケーション、.NET Framework環境、Java（登録商標）環境等を含む。後述するように、モバイル装置１２０は、ドック１０２上での実行のためにドック１０２にブートイメージを送信することができる。１の実施形態において、区分２４０へのアクセスを信頼できるドックの範囲に制限しても良い。

図３は、本発明の実施形態に応じてモバイル装置のロジック及び動作とブートネゴシエーションを行うドックとを示すフローチャート３００である。１の実施形態において、フローチャート３００のロジックの少なくとも一部は、モバイル装置１２０の装置ＯＳによって処理することができる。モバイル装置及びドックは、それらの関係について又は互いの能力について認識せずに互いに近づく。どの装置が制御ブートイメージを実行するかの決定は、ネゴシエーションが完了した後まで行われない。

本明細書に用いられたように、「制御ブートイメージ」は、他の計算装置のリソースの少なくとも一部を管理する計算装置で実行するブートイメージを示す。例えば、ドックがモバイル装置によって与えられたブートイメージから起動するとき、ドックは記憶装置等のモバイル装置のリソースを用いることができる。モバイル装置が制御ブートイメージ（例えば、モバイル装置ＯＳ）を実行するとき、モバイル装置は、モバイル装置への人間の入力／出力のためにキーボード、ビデオモニタ、及びマウス（ＫＶＭ）等のドックのリソースを用いることができる。

ブートネゴシエーションは、ネゴシエーションプロトコルを用いて処理することができる。１の実施形態において、ネゴシエーションプロトコルは、周知の物理レベルプロトコル上で実行するロジックレベルを含む。ネゴシエーションプロトコルは、リソース及びそれらの能力を報告し、そのネゴシエーションセッションを確保し、装置からドックにブートイメージを送信する等のネゴシエーション通信のために用いることができる。１の実施形態において、モバイル装置とドックとの間のブートネゴシエーションはドックのＢＩＯＳとモバイル装置のＯＳとの間で生じる（図８との関連で後述する）。

ブロック３０２におけるフローチャート３００の開始において、装置及びドックは初期接続を行う。例えば、装置及びドックは、ワイヤによって物理的に接続されるか、無線接続のために互いに物理的に接近させられ、又は無線接続が可能にされる。ブロック３０２において、装置及びドックは初期接続を達成するためにハンドシェーキングを行うことができる。１の実施形態において、初期接続を行うことはモバイル装置とドックとの間の安全な接続を達成することを含む。

判別ブロック３０４に進んで、装置は本明細書で説明されるように、ドックがブートネゴシエーションをサポートするか否かを判別するためにドックに問い合わせる。１の実施形態において、この問い合わせ（クエリ）は、装置及びドックの両方によって理解されるネゴシエーションプロトコルを用いて処理される。１の実施形態において、ドックＢＩＯＳは、モバイル装置ＯＳと共にブートネゴシエーションを処理する。このように、ブートネゴシエーションは、ドック上でのＯＳ実行の必要なしにドックのプリブートの間に亘って処理され得る。ドックＢＩＯＳのブートネゴシエーションタスクは、接続されたモバイル装置の発見を含んでおり、通信（いくつかの場合では安全な通信）を達成し、ドックの能力を報告する。

装置とドックとは、接続されたときそれらの役割を仮定しない点に留意すべきである。いくつかの通信システム（例えば、ＵＳＢ）においては、接続された装置は常に他の計算装置に対する装置（すなわち、スレーブ）であると仮定される。同様に、ラップトップコンピュータ等の計算装置は、ＵＳＢ装置に接続されたときホスト（すなわち、マスタ）であると仮定する。ブートネゴシエーションをサポートするために、計算装置のＢＩＯＳ及びハードウエアのコンポーネントは、接続した装置が制御することを可能にする。本明細書の実施形態においては、ハードウエア通信（例えば、チップセット）及び計算装置のＢＩＯＳは、他の計算装置に接続しているとき、それらの役割（例えば、マスタとスレーブ）についていかなる仮定も行わない。後述するように、本発明の実施形態では、不良装置が他の計算装置の安全を損なわないように安全対策を含んでも良い。

判別ブロック３０４の答えがＮＯならば、ロジックはブロック３０６に進む。ブロック３０６においては、ドック及び装置はデフォルト時の仮定（assumption）を用いて互いにインターラクションを行う。例えば、装置がスレーブ装置としてデフォルト設定されていれば、装置はネゴシエーションなしにスレーブ装置のデフォルト役割をとる。ドックは記憶されたデフォルトブートイメージを実行する。

判別ブロック３０４の答えがＹＥＳならば、ロジックはブロック３０８に続く。ブロック３０８では、装置及びドックは互いに認証する。代替的実施形態においては、認証は一方向だけでも良い。例えば、装置だけがドックを認証するか、ドックだけが装置を認証する。認証は署名、証明書、又は周知の認証法を用いて実行しても良い。

ブロック３１０では、装置及びドックは能力発見を行う。１の実施形態において、装置は上記したように、ネゴシエーションプロトコルを用いてドックにそのリソース及びリソース能力を報告することを求める。能力の例としては処理能力（例えば、プロセッサの種類、プロセッサ速度等）、及びメモリ能力（例えば、メモリサイズ、メモリ速度等）が含まれる。また、能力は記憶装置、それらの種類、容量、利用可能な記憶空間、ファイルシステム等を含んでも良い。また、能力はドックのビデオ及び／又はオーディオ能力を含んでも良い。また、能力は通信接続及びそのような接続の帯域幅を含んでも良い。

図７を参照すると、本発明の実施形態に従う能力報告テーブル７００が示されている。１の実施形態においては、ドックＢＩＯＳはテーブル７００を生成し、ネゴシエーションテーブルを用いてモバイル装置にテーブル７００を送信する。モバイル装置はドックから受信したテーブルとの比較のためにそれ自身の能力報告テーブルを生成する。

テーブル７００は、コンポーネント７０２、コンポーネントについての属性７０４、及びそれら属性についての値７０６の各々の列を含む。例えば、プロセッサでの元では、クロック速度、Ｌ２キャッシュ及びバス速度の属性が報告される。１の実施形態においては、テーブル７００の情報は、ドックとモバイル装置との間でリソース情報を渡すための１以上のスキーマに整理しても良い。スキーマは、ドック及びモバイル装置によって使用されるネゴシエーションプロトコルの一部であっても良い。

ブロック３１０の後、ロジックはブロック３１２に進んで、報告されたドックの能力を用いて装置に記憶されたブートイメージとドックとが適合するか（compatible）否かを判別する。例えば、図１及び図２において、ロジックは、ドック１０２がモバイル装置１２０に記憶されたブートイメージ２４１〜２４３のいずれかを実行し得るかを判別する。判別ブロック３１２の答えがＮＯであるならば、ロジックはブロック３１４に進む。１の実施形態においては、ブートイメージの適合性（compatibility）はドックのプロセッサ速度、メモリサイズ、ビデオ能力等に基づいている。

ブロック３１４において、装置は制御ブートイメージを実行する。１の実施形態においては、既に実行中のモバイル装置ＯＳはドックのハードウエアリソースを用いる。例えば、ドックがＨＤＤ等の記憶装置を有しているならば、ドックのＨＤＤはモバイル装置ＯＳによってアクセス可能である。他の例では、ラップトップ（すなわち、ドック）のＫＶＭは携帯電話装置とインターラクションを行うために用いることができる。

判別ブロック３１２の答えがＹＥＳであるならば、ロジックはブロック３１６に進む。ブロック３１６において、ロジックは、ブロック３１８におけるブート方針の適用の前に、モバイル装置に記憶されたブート方針を更新する。１の実施形態においては、モバイル装置は、マイクロソフトウインドウズアップデート（Microsoft Windows（登録商標） Update)等の中央更新サイトと接触する。モバイル装置は、更新のチェックのためにそれ自身の通信接続部又はドック上の通信接続部を用いることができる。

ブロック３１８では、ロジックはブート方針を適用する。方針は、モバイル装置からの１以上の適合するブートイメージでドックを起動することが方針と合うか否かを判別する。方針は、ユーザ及び／又はシステム管理者によって修正可能でも良い。１の実施形態において、方針は装置に記憶されている。他の実施形態においては、ドックに記憶された方針はブートネゴシエーションの間に亘って装置に連絡される。装置及びドックからの方針を組み合わせて適用しても良い。

１の実施形態において、ドック又はモバイル装置が制御ブートイメージを実行するか否かを決定するために、装置及びドックの能力を比較する。例えば、より高速のプロセッサを有する計算装置が常に制御することを方針で示してもよい。他の方針として、制御マシンを決定する際に、能力（プロセッサ速度、メモリサイズ、バンド幅能力等）の範囲を分析するようにしてもよい。例えば、装置及びドック用のテーブル７００からの情報を、様々なコンポーネント及びそれらの属性値にポイントを割り当てる式に入れてもよい。その式において、いくつかのコンポーネント属性は重み付けされても良い。最も高い点数の計算装置（モバイル装置又はドック）が、制御ブートイメージを実行する計算装置であるべきと判別される。

他の実施形態において、ドック又はモバイル装置が制御ブートイメージを実行するか否かを判別するために、方針に過去のユーザの活動を参照することを含むことができる。例えば、ドックが装置のブートイメージから以前起動したならば、そのドックはそのブートイメージから再度ブートされる。

また、方針は、複数の適合したブートイメージが装置に記憶されているとき、ドックがどのブートイメージから起動するのかを判別することを含んでも良い。１の実施形態において、ロジックはどのブートイメージがペストパフォーマンスを与えるか判別する。例えば、ドックのプロセッサ速度及びメモリ容量に基づいてペストパフォーマンスを与えるブートイメージが選択されても良い。

代替的実施形態においては、全ての適合したブートイメージがユーザに対して表示される。ユーザは、ドック用の望ましいブートイメージを選択できる。１の実施形態において、ブートイメージのユーザ選択は、後述するように判別ブロック３２０で行うことができる。

判別ブロック３２０において、ロジックは、装置又はドックが制御ブートイメージを実行するか否かの判別をユーザが確認するか否かを判別する。１の実施形態において、ユーザは、ブロック３１８で行われた判別をユーザインターフェースによって確認することができる。ユーザインターフェースは、装置、ドック又は両方に表示され得る。１の実施形態において、方針に従って、ドックがモバイル装置からブートイメージを実行すると判別された場合、装置はドックを起動するブートイメージの名称を表示することができる。更に他の実施形態においては、複数のブートイメージがドックと適合するとき、複数の適合するブートイメージを表示して、ユーザがドック用の望ましいブートイメージを選択できる。

ブロック３２０では、ユーザがドックを起動することを確認しないならば、ロジックはブロック３１４に進む。ユーザが判別ブロック３２０でドックを起動することを確認するならば、ロジックはブロック３２２に続く。

代替的実施形態においては、判別ブロック３２０で説明したようなユーザの確認を利用しない。この特定の実施形態では、ネゴシエーション処理はユーザには明らかにされないだろう。例えば、ユーザは、携帯電話機からパーソナルコンピュータに接続し、携帯電話機の「ネゴシエーション」ボタンを押してネゴシエーションを開始することができる。ネゴシエーション処理が行われる。ユーザは、パーソナルコンピュータのＫＭＶを使用して用事を済ませることができる。ユーザにとって、どの計算装置が制御ブートイメージを実行しているのかを理解する必要はない。ブートネゴシエーションはユーザに分かり易く行なうことができる。

図４を参照すると、装置はブロック３２２において、ドックへブートイメージを送る前に実行のためブートイメージを更新する。１の実施形態においては、装置は自身の通信接続部を用いて更新のチェックのためにインターネット等のネットワークに接続する。他の実施形態においては、装置はドックの通信接続部を用いてブートイメージの更新をチェックすることができる。

ブロック３２２の後、ロジックは、モバイル装置がブートイメージをドックに送るブロック３２４へと続く。次に、ブロック３２６では、ドックはブートイメージから起動する。ドックがブートイメージから起動されると、装置はドックに対して利用可能になる。例えば、ラップトップ（ドック）は接続された携帯電話機（装置）に記憶されたブートイメージから起動した後、そのラップトップは携帯電話機のリソースを管理する。例えば、携帯電話機の記憶装置はドックに使用される。安全対策として、装置の区画２３０等に記憶されたデータへドックがアクセスすることを制限することができる。

次に、ブロック３２８では、モバイル装置のＯＳがスリープ状態となる。ドックとの接続が切断されたとき、及び／又は特定の閾値の後に接続を再確立できなかったとき、モバイル装置のＯＳは起動して装置の制御を再び行うことができる。閾値には、再接続の試行回数又は予め定められた時間を含めることができる。

図５を参照すると、仮想マシン（ＶＭ）環境の実施形態が示されている。図５において、携帯電話機５０２として示されたモバイル装置は、ブートイメージ５０３をドック５０４に送信することができる。ドック５０４はＶＭ環境を実現している。ドック５０４において、ドックハードウエア５１２は仮想マシンマネージャ（ＶＭＭ）５１０によって管理される。ＶＭＭ５１０は、ＶＭ５０６及びＶＭ５０８等の１以上のＶＭをサポートすることができる。ＶＭ５０６はゲストＯＳ５０５を実行する。一般に、ＶＭは、ＶＭ環境において望まれるように作成され、壊される。また、各ＶＭは、動作システムのクラッシュ等の１つのＶＭにおけるシステムエラーが他のＶＭに影響しないように、独立して動作する。

本明細書の実施形態によれば、ドック５０４がＶＭ環境で動作している間に、携帯電話機５０２とドック５０４との間でネゴシエーションを行なうことができる。携帯電話機５０２は、ＶＭ５０８における実行のためにブートイメージ５０３をドック５０４に送信することができる。ブートイメージ５０３の実行は、ゲストＯＳ５０７の如く示されている。

１の例では、ＶＭ環境を使用することで、ドック５０４の全てを起動することなく、携帯電話機５０２からブートイメージを使用することができる。ＶＭ５０８は、ブートイメージ５０３を実行するためにドック５０４で生成される。更に、ユーザがゲストＯＳ５０７を使い終わったとき、ＶＭ５０８は壊されるが、ＶＭ５０６はそのまま残すことができる。

図６には、ブートネゴシエーションを行う携帯電話機６０２（装置）とラップトップ６０４（ドック）との実施形態が示されている。１の実施形態においては、ブートネゴシエーションはネゴシエーションプロトコルを用いて行われる。６１０では、携帯電話機６０２はラップトップ６０４にネゴシエーションが可能かどうか問い合わせる。ラップトップ６０４は、携帯電話機６０２に肯定的な応答６１１を提供する。６１２では、携帯電話機６０２及びラップトップ６０４が互いに認証し合う。

６１３では、携帯電話機６０２はラップトップ６０４にその能力を問い合わせる。６１４では、ラップトップ６０４はその能力を報告することにより応答する。ラップトップ６０４は、テーブル７００の実施形態を用いてその能力を報告しても良い。

６１５では、携帯電話機６０２は、携帯電話機６０２で実行されるブートイメージとラップトップ６０４で実行されるブートイメージとのいずれが制御を行うかを判別する。エクスチェンジ６１６では、モバイル装置６０２が（６１７で示した）ブートイメージをラップトップ６０４に送信する。１の実施形態においては、モバイル装置６０２は、ブートイメージをラップトップ６０４に送信する前に、ブートイメージに対して更新のためのチェックを行う。６１８では、ラップトップ６０４は携帯電話機６０２からのブートイメージを実行する。１の実施形態においては、ブートイメージはラップトップ６０４のＶＭ環境にて実行される。

６１９では、携帯電話機６０２のＯＳは、ブートイメージをラップトップ６０４に送信した後、スリープ状態になる。よって、携帯電話機６０２とラップトップ６０４との間の接続が切断されたときには、携帯電話機６０２は携帯電話機ＯＳを再起動することなくそれ自身のＯＳを用いて動作を継続することができる。

或いは、エクスチェンジ６２０において、携帯電話機６０２のＯＳは（６２１に示した）ラップトップ６０４のリソースを管理する。携帯電話機６０２は、そのソフトウエアの状態を切り替えて携帯電話機ＯＳを再起動することなくラップトップ６０４の周辺機器にアクセスしても良い。例えば、携帯電話機６０２は（６２２で示した）ラップトップ６０４のＫＶＭを用いることができる。携帯電話機６０２とラップトップ６０４との間の接続が終了したときには、携帯電話機６０２はそれ自身の入力／出力装置を用いて元に戻っても良い。携帯電話機６０２の再起動は必要ない。

図８を参照して、本発明の実施形態に対応した使用シナリオを説明する。当然ながら、本発明の実施形態は下記のシナリオに限定されない。図８は、パーソナルコンピュータ（ＰＣ）８１０（すなわち、ドック）に接続された携帯電話機８０２（すなわち、モバイル装置）を示している。図８は、携帯電話機ＯＳ８０４とＰＣ ＢＩＯＳ８１２との間で生じるブートネゴシエーション処理を示している。

１つのシナリオにおいて、本発明の実施形態は公共のコンピューティング環境で用いることができる。いくつかの場合には、公共のコンピューティング環境は携帯電話機８０２及びＰＣ８１０の両方にサービスを提供する電話会社（「Ｔｅｌｃｏ」）によって管理される。ＰＣ８１０はモールキオスク、インターネットカフェ等における公共のコンピュータである。

例えば、ＯＳ実行中の携帯電話機８０２を有するユーザは、ＰＣ８１０にアプローチする。ＰＣ８１０は現在ｏｆｆである。ユーザは、無線接続のためにＰＣ８１０を近くに携帯電話機８０２を置くか、或いは有線接続用のケーブルで携帯電話機８０２とＰＣ８１０とを接続する。それで、ユーザはＰＣ８１０をオンにする。ブートネゴシエーション処理が、ＰＣ ＢＩＯＳ８１２と通信するモバイル装置ＯＳ８０４で開始する。ブートネゴシエーションの後、ユーザはＰＣ８１０のＫＶＭを用いてモバイル装置ＯＳ８０４とインターラクションを行うか、或いはユーザはＰＣ８１０のＫＶＭを用いて、ＰＣ８１０で起動された携帯電話機８０２から送られたブートイメージとインターラクションを行う。いずれの場合においても、ユーザは携帯電話機８０２をデータ記憶のために用いることができる。このようにして、ユーザは、公共のコンピュータ（すなわち、ＰＣ８１０）から離れているときでも、それらと共に容易に仕事をすることができる。

代替的実施形態においては、ユーザがネゴシエーション処理を開始したときＰＣ８１０がスリープ状態又はＯＳ実行時にあれば、ＰＣ８１０は携帯電話機８０２からのブートイメージを実行するために再起動されても良い。更に、他の実施形態では、ＰＣ８１０はＯＳ実行状態に留まり、仮想マシン環境において携帯電話機８０２から受信したブートイメージを実行しても良い。

Ｔｅｌｃｏ使用シナリオにおいて、ユーザは携帯電話機８０２及びＰＣ８１０で使用される数分のうちの１つのアカウントを有することができる。また、携帯電話機８０２及びＰＣ８１０は、同じＴｅｌｃｏネットワークの一部であるので、ブート方針に対する更新は携帯電話機８０２及び／又はＰＣ８１０にさせても良い。また、携帯電話機８０２のブートイメージに対する更新は、Ｔｅｌｃｏネットワークを介して携帯電話機８０２にさせても良い。

他のシナリオにおいては、本発明の実施形態は、企業ネットワーク等の組織が管理するネットワークでも使用できる。携帯電話機８０２及びＰＣ８１０は、企業ネットワークの一部である。この場合も、ユーザは携帯電話機８０２をＰＣ８１０に接続し、ブートネゴシエーション処理を開始する。それで、ユーザはＰＣ８１０のＫＶＭを使用して携帯電話機８０２又はＰＣ８１０の制御ブートイメージとインターラクションを行うことができる。

この企業ネットワークシナリオは様々な方法に利用することができる。従業員には携帯電話機８０２等のモバイル装置が支給される。従業員は、組織の中の様々なＰＣで使用可能な様々なブートイメージを保持することができる。また、ユーザのデータは、いくつものマシン（例えば、共同のモバイル装置や様々な共同のデスクトップ）に拡散される代わりに彼らのモバイル装置に集約されるので、ユーザは常にそれらのデータへアクセスする。加えて、ブート方針の更新及びブートイメージの更新を、携帯電話機８０２に容易に行わせることができる。

図９は、本発明の１以上の実施形態を実行するための計算装置９００の例を示している。計算装置９００の実施形態は、ドック１０２及び／又はモバイル装置１２０として使用することができる。１の構成において、計算装置９００は、少なくとも１つの処理ユニット９２０とメモリ９０４とを含む。計算装置の詳細な構成及び種類に応じて、メモリ９０４は、（ＲＡＭ等の）揮発性、（ＲＯＭ、フラッシュメモリ等の）不揮発性、又はその２つの組み合わせとしてもよい。この構成は、破線９０６により図９に示されている。

他の実施形態においては、装置９００は追加の特徴及び／又は機能を含むことができる。例えば、装置９００は、限定されないが、磁気記憶装置や光学記憶装置等の追加の記憶装置（例えば、リムーバブル及び／又は非リムーバブル）を含むことができる。それらの追加の記憶装置は、記憶装置９０８によって図９に示されている。また１の実施形態では、本発明の実施形態を実行させるコンピュータ可読命令を、記憶装置９０８内におくことができる。さらに、記憶装置９０８は、オペレーションシステム、アプリケーションプログラム及びその他を実行する他のコンピュータ可読命令を記憶することができる。

本明細書で使用されている「コンピュータ可読媒体」という用語は、コンピュータ記憶媒体を含む。コンピュータ記憶媒体は、コンピュータ可読命令又は他のデータ等の情報の記憶のために何らかの方法又は技術で行われる揮発性及び不揮発性、リムーバブル及び非リムーバブル媒体を含む。メモリ９０４及び記憶装置９０８は、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、限定されないが、所望の情報を記憶するために使用でき、かつ装置９００によってアクセスすることができるＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ディジタルバーサタイルディスク（ＤＶＤ）又は他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置又は他の磁気記憶装置、又は他の媒体を含む。そのようなコンピュータ記憶媒体は装置９００の一部である。

装置９００は、装置９００が他の装置との通信することを可能にする通信接続部９１２を含む。通信接続部９１２は、限定されないが、計算装置９００を他の計算装置に接続するためのモデム、ネットワークインターフェースカード（ＮＩＣ）、ＵＳＢ接続部、赤外線ポート、又は他のインターフェースを含む。通信接続部９１２は有線接続又は無線接続を含む。通信接続部９１２は通信媒体を送信及び／又は受信しても良い。

「コンピュータ可読媒体」という用語は、通信媒体を含む。通信媒体はコンピュータ可読命令、又は搬送波等の「変調されたデータ信号」又は搬送手段における他のデータを一般に保有し、情報伝搬媒体を含む。「変調されたデータ信号」という用語は、信号内の情報を符号化するように定められ又は変化された１以上の特性を有する信号を意味する。例としては、限定されないが、通信媒体は有線ネットワーク又はダイレクト有線接続等の有線媒体と、音響媒体、無線周波数媒体、赤外線媒体、短距離無線通信（ＮＦＣ）等の無線媒体とを含む。

装置９００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、赤外線カメラ、ビデオ入力装置等の入力装置９１４、及び／又は他の入力装置を含む。１つ以上のディスプレイ、スピーカ、プリンタ等の出力装置９１６、及び／又は他の出力装置が装置９００には含まれる。入力装置９１４及び出力装置９１６は有線接続、無線接続、又はそれらの組み合わせを介して装置９００に接続される。１の実施形態においては、他の計算装置からの入力装置又は出力装置は、計算装置９００用の入力装置９１４又は出力装置９１６として用いられる。

計算装置９００のコンポーネントは、バス等の様々な相互接続によって接続される。そのような相互接続は、ＰＣＩ Ｅｘｐｒｅｓｓ等のＰＣＩ(Peripheral Component Interconnect)、ＵＳＢ(Universal Serial Bus)、Ｆｉｒｅｗｉｒｅ(IEEE 1394)、光学パス構造及びその他を含む。他の実施形態においては、計算装置９００のコンポーネントはネットワークによって相互接続される。例えば、メモリ９０４はネットワークによって相互接続された異なる物理的位置に配置された複数の物理的メモリユニットから構成されても良い。

この分野の当業者であれば、コンピュータ可読命令を記憶するために利用される記憶装置が、ネットワーク上に分散配置できることを理解するであろう。例えば、ネットワーク９２０を介してアクセス可能な計算装置９３０は、コンピュータ可読命令を記憶して本発明の１以上の実施形態を実行することができる。計算装置９００は、計算装置９３０にアクセスし、実行のためのコンピュータ可読命令の一部又は全てをダウンロードしても良い。或いは、計算装置９００はコンピュータ可読命令の断片を必要に応じてダウンロードしても良いし、又はいくつかの命令が計算装置９００で、そしていくつかの命令が計算装置９３０で実行されても良い。また、この分野の当業者は、コンピュータ可読命令の全て又は一部がＤＳＰ（ディジタル信号プロセッサ）、プログラム可能なロジックアレー等の専用回路によって実行できることを理解するであろう。

本発明の実施形態の様々な動作を本明細書で説明している。１の実施形態においては、説明した１以上の動作が１以上のコンピュータ可読媒体に記憶されたコンピュータ可読命令を構成し、これが計算装置によって実行されるときに、説明した動作を計算装置に行わせる。動作のいくつか又は全ての説明された順番は、それらの動作が依存する必要な順番であると解釈されるべきでない。その他の順番付けは、この明細書の利益を有する当該分野の当業者によって理解される。更に、全ての動作が本発明の各実施形態において必ずあるとは限らないことが理解されるだろう。

上記の本発明の実施形態の説明は、要約書に説明された事項を含むが、説明された正確な実施形態に徹底したり又はこれに限定することを意図していない。本発明の特定の実施形態及び例は、例示の目的で本明細書に説明されているが、関連分野の当業者が上記の詳細な説明について理解するように、種々の均等な変更が可能である。次の特許請求の範囲に用いられる用語は、明細書に示した特定の実施形態に本発明を限定するべきでない。むしろ、次の特許請求の範囲は請求項の解釈の確立した理論に応じて解釈されるべきである。

Claims (20)

1. 第１の装置によって第２の装置の能力を発見するステップ（３１０）と、
   前記第１の装置及び前記第２の装置の能力の少なくとも一部に基づいて、前記第１の装置及び前記第２の装置のいずれが制御ブートイメージを実行するのかを前記第１の装置によって判別するステップ（３１２，３１６，３１８）と、
   前記第１の装置が前記制御ブートイメージを実行すると判別されたとき、前記第１の装置によって第１のブートイメージを実行し、前記第２の装置を前記第１のブートイメージ用のリソースとするステップ（３１４）と、
   前記第２の装置が前記制御ブートイメージを実行すると判別されたとき、前記第１の装置に記憶された第２のブートイメージを前記第１の装置によって前記第２の装置に送信し、前記第１の装置を前記第２のブートイメージ用のリソースとするステップ（３２４）と、
   を備えることを特徴とする方法。
2. 前記第１の装置によって、前記第２のブートイメージが前記第２の装置と適合するか否かを判別するステップ
   を更に備えることを特徴とする請求項１に記載の方法。
3. 前記第１の装置によって、前記第２の装置で前記第２のブートイメージを実行することが前記第１の装置に記憶されたブート方針に従っているか否かを判別するステップ
   を更に備えることを特徴とする請求項１に記載の方法。
4. 前記第２の装置で前記第２のブートイメージを実行することが前記第１の装置に記憶されたブート方針に従っているか否かを判別する前に、前記第１の装置によって、中央サイトに接続することにより前記ブート方針を更新するステップ
   を更に備えることを特徴とする請求項３に記載の方法。
5. 前記第２のブートイメージを前記第２の装置に送信する前に、前記第１の装置によって前記第２のブートイメージを更新するステップ
   を更に備えることを特徴とする請求項１に記載の方法。
6. 前記第２のブートイメージを前記第２の装置に送信した後に、前記第１の装置で実行するオペレーティングシステムによってスリープ状態に入るステップと、
   前記第１の装置と前記第２の装置との間の接続が切断されたとき、前記スリープ状態から起動するステップと、
   を更に備えることを特徴とする請求項１に記載の方法。
7. 前記第１の装置と前記第２の装置との間の接続を確立するステップであって、前記第１の装置はオペレーティングシステムが実行中であり、前記第２の装置はプリブートにあるステップ
   を更に備えることを特徴とする請求項１に記載の方法。
8. 前記第２の装置の能力を発見するステップは、前記第１の装置からの能力のクエリに応答して前記第２の装置から能力報告データを前記第１の装置で受信するステップを含む
   ことを特徴とする請求項１に記載の方法。
9. 前記第１の装置によって前記第２の装置を認証するステップ
   を更に備えることを特徴とする請求項１記載の方法。
10. 前記第１の装置及び前記第２の装置のいずれが制御ブートイメージを実行するかを判別するステップは、ユーザから当該判別の確認を前記第１の装置で受信するステップを含む
    ことを特徴とする請求項１に記載の方法。
11. モバイル装置とドックとの間の接続を行うステップ（３０２）であって、前記モバイル装置は第１のブートイメージを実行中で、前記ドックはプリブートにある、ステップと、
    前記モバイル装置及び前記ドックの能力の少なくとも一部に基づいて、前記モバイル装置及び前記ドックのいずれが制御ブートイメージを実行するのかを判別するステップ（３１０，３１２，３１６，３１８）と、
    前記ドックが前記制御ブートイメージを実行するとき、前記モバイル装置から前記ドックに第２のブートイメージを送信し、前記ドックで前記第２のブートイメージを実行するステップ（３２４）であって、前記第２のブートイメージは前記制御ブートイメージを含む、ステップと、
    前記モバイル装置が前記制御ブートイメージを実行するとき、前記第１のブートイメージを前記モバイル装置で実行するステップ（３１４）であって、前記第１のブートイメージは前記制御ブートイメージを含む、ステップと
    を備えることを特徴とする方法。
12. 前記モバイル装置及び前記ドックのいずれが制御ブートイメージを実行するのかを判別するステップは、前記ドックが前記モバイル装置に記憶された１以上のブートイメージと適合するか否かを判別するステップを含む
    ことを特徴とする請求項１１に記載の方法。
13. 前記第２のブートイメージは前記ドックの仮想マシン環境で実行される
    ことを特徴とする請求項１１に記載の方法。
14. 前記第２のブートイメージを前記ドックでの実行のために前記ドックに送信する前に、前記モバイル装置によって前記第２のブートイメージを更新するステップ
    を更に備えることを特徴とする請求項１１に記載の方法。
15. 前記ドックが前記制御ブートイメージを実行するとき、前記モバイル装置で実行する前記第１のブートイメージによってスリープ状態に入るステップ
    を更に備えることを特徴とする請求項１１に記載の方法。
16. 前記モバイル装置からの能力のクエリに応答して前記ドックから能力報告データを前記モバイル装置で受信するステップ
    を更に備えることを特徴とする請求項１１に記載の方法。
17. 第２の計算装置と接続される第１の計算装置を備え、前記第１の計算装置は、第１の計算装置によって実行されるときに処理を実行するコンピュータ可読命令を記憶したシステムであって、
    前記第２の計算装置の能力を発見するステップ（３１０）と、
    前記第１の計算装置及び前記第２の計算装置の能力の少なくとも一部に基づいて、前記第１の計算装置及び前記第２の計算装置のいずれが制御ブートイメージを実行するかを判別するステップ（３１２，３１６，３１８）と、
    前記第１の計算装置が前記制御ブートイメージを実行すると判別されたとき、前記第１の計算装置によって第１のブートイメージを実行し、前記第２の計算装置を前記第１のブートイメージ用のリソースとするステップ（３１４）と、
    前記第２の計算装置が前記制御ブートイメージを実行すると判別されたとき、前記第１の計算装置に記憶された第２のブートイメージを前記第２の計算装置に送信し、前記第１の計算装置を前記第２のブートイメージ用のリソースとするステップ（３２４）と、
    を備えた動作を行うことを特徴とするシステム。
18. 前記第１の計算装置と前記第２の計算装置とのいずれが制御ブートイメージを実行するかを判別するステップは、前記第２の計算装置が前記第１の計算装置に記憶された１以上のブートイメージと適合するか否かの判別を含む
    ことを特徴とする請求項１７に記載のシステム。
19. 前記第１の計算装置と前記第２の計算装置とのいずれが制御ブートイメージを実行するかを判別するステップは、前記第１の計算装置に記憶された方針を適用することを含む
    ことを特徴とする請求項１７記載のシステム。
20. 前記第１の計算装置と前記第２の計算装置とのいずれが制御ブートイメージを実行するかを判別するステップは、ユーザから当該判別の確認を受信するステップを含む
    ことを特徴とする請求項１７記載のシステム。

Images