"複数の仮想マシンで一の物理NICデバイスを共有する方法であって、コンピューティングシステムにおいて顧客仮想マシンで実行されている顧客オペレーティングシステムOSの仮想ネットワークインターフェースカードNICドライバによって、前記コンピューティングシステムに結合されているネットワークを介して物理NICドライバによって送信されるべき顧客OS要求パケットを受信する段階と、前記顧客OS要求パケットのうち少なくとも一部を前記コンピューティングシステムの共有メモリの空いているブロックに複製して、前記ブロックを前記共有メモリ内の送信待ち行列に付加する段階と、サービス仮想マシンで実行されているサービスOSの仮想NICドライバによって前記送信待ち行列から前記ブロックをフェッチして、前記一部をサービスOS要求パケットにパッケージングする段階と、前記サービスOSのサービスOSネットワークスタック部に前記サービスOS要求パケットを渡す段階と、前記サービスOSネットワークスタック部のブリッジドライバによって前記サービスOS要求パケットを前記物理NICドライバにルーティングする段階と、前記物理NICドライバによって、前記物理NICデバイスを介して前記ネットワークで前記サービスOS要求パケットを送信する段階とを備える方法。前記顧客OSの仮想NICドライバによってVMCALL命令を呼び出して、前記コンピューティングシステムの仮想マシンマネージャVMMから前記サービスOSの仮想NICドライバに対して顧客OS要求パケットが利用可能である旨を通知させて、前記VMMに前記サービスOSの仮想NICドライバに割り込みを発行させる段階をさらに備える請求項1に記載の方法。前記サービスOSは、前記コンピューティングシステムのプロセッサによって提供されるセキュアエンクレーブセッションにおいて実行される請求項1に記載の方法。前記コンピューティングシステムにおいて第2の顧客仮想マシンで実行されている第2の顧客オペレーティングシステムOSの第2の仮想ネットワークインターフェースカードNICドライバによって、前記物理NICドライバが送信すべき第2の顧客OS要求パケットを受信して、前記第2の顧客OS要求パケットの少なくとも一部を前記コンピューティングシステムの共有メモリの空いているブロックに複製して、前記ブロックを前記共有メモリの前記送信待ち行列に付加する段階をさらに備え、前記第2の顧客仮想マシンは、前記第1の顧客仮想マシンと同時に前記コンピューティングシステムで実行されている請求項1に記載の方法。前記第1の顧客OSおよび前記第2の顧客OSは異なるOSである請求項4に記載の方法。前記VMMは、共有メモリのうち一の領域を、前記顧客OSおよび前記サービスOSがアクセス可能な前記送信待ち行列に割り当てる請求項2に記載の方法。複数の機械命令を有する機械可読媒体を備える物品であって、前記命令は、コンピューティングシステム内のプロセッサで実行されると、コンピューティングシステムにおいて顧客仮想マシンで実行されている顧客オペレーティングシステムOSの仮想ネットワークインターフェースカードNICドライバによって、前記コンピューティングシステムに結合されているネットワークを介して物理NICドライバによって送信されるべき顧客OS要求パケットを受信して、前記顧客OS要求パケットのうち少なくとも一部を前記コンピューティングシステムの共有メモリの空いているブロックに複製して、前記ブロックを前記共有メモリ内の送信待ち行列に付加して、サービス仮想マシンで実行されているサービスOSの仮想NICドライバによって前記送信待ち行列から前記ブロックをフェッチして、前記一部をサービスOS要求パケットにパッケージングして、前記サービスOSのサービスOSネットワークスタック部に前記サービスOS要求パケットを渡して、前記サービスOSネットワークスタック部のブリッジドライバによって前記サービスOS要求パケットを前記物理NICドライバにルーティングして、前記物理NICドライバによって、一の物理NICデバイスを介して前記ネットワークで前記サービスOS要求パケットを送信することによって、複数の仮想マシンによる前記物理NICデバイスの共有を実現する物品。前記顧客OSの仮想NICドライバによってVMCALL命令を呼び出して、前記コンピューティングシステムの仮想マシンマネージャVMMから前記サービスOSの仮想NICドライバに対して顧客OS要求パケットが利用可能である旨を通知させ、前記VMMに前記サービスOSの仮想NICドライバに対して割り込みを発行させる命令をさらに備える請求項7に記載の物品。前記サービスOSのための前記命令は、前記コンピューティングシステムのプロセッサによって提供されるセキュアエンクレーブセッションにおいて実行される請求項7に記載の物品。複数の仮想マシンで一の物理NICデバイスを共有するためのコンピューティングシステムであって、顧客オペレーティングシステムOSを実行する顧客仮想マシンと、サービスOSを実行するサービス仮想マシンとを備え、前記顧客OSは、前記コンピューティングシステムに結合されているネットワークを介して前記物理NICデバイスによって送信されるべき顧客OS要求パケットを受信し、前記顧客OS要求パケットのうち少なくとも一部を前記コンピューティングシステムの共有メモリの空いているブロックに複製して、前記ブロックを前記共有メモリ内の送信待ち行列に付加する顧客OS仮想ネットワークインターフェースカードNICドライバを有しており、前記サービスOSは、前記送信待ち行列から前記ブロックをフェッチして、前記一部をサービスOS要求パケットにパッケージングするサービスOS仮想NICドライバと、前記サービスOS仮想NICドライバから前記サービスOS要求パケットを受信するサービスOSネットワークスタック部と、前記サービスOSネットワークスタック部から前記サービスOS要求パケットを受信して、前記サービスOS要求パケットを前記物理NICデバイスに送信する物理NICドライバとを有しているコンピューティングシステム。仮想マシンマネージャVMMをさらに備え、前記顧客OSの仮想NICドライバがVMCALL命令を前記VMMに呼び出して、顧客OS要求パケットが利用可能である旨を前記サービスOS仮想NICドライバに通知して、前記VMMは、前記サービスOS仮想NICドライバに割り込みを発行する請求項10に記載のコンピューティングシステム。前記サービスOSは、前記コンピューティングシステムのプロセッサによって提供されるセキュアエンクレーブセッションにおいて実行される請求項10に記載のコンピューティングシステム。前記コンピューティングシステムにおいて第2の顧客仮想マシンで実行されている第2の顧客オペレーティングシステムOSをさらに備え、前記第2の顧客OSは第2の仮想NICドライバを有し、前記第2の顧客仮想マシンは、前記第1の顧客仮想マシンと同時に前記コンピューティングシステムにおいて実行され、前記第2の仮想NICドライバは、前記物理NICドライバによって送信されるべき第2の顧客OS要求パケットを受信して、前記コンピューティングシステムの共有メモリの空いているブロックに前記第2の顧客OS要求パケットの少なくとも一部を複製して、前記ブロックを前記共有メモリ内の前記送信待ち行列に付加する請求項10に記載のコンピューティングシステム。前記VMMは、共有メモリのうち一の領域を、前記顧客OSおよび前記サービスOSがアクセス可能な前記送信待ち行列に割り当てる請求項11に記載のコンピューティングシステム。複数の仮想マシンで一の物理NICデバイスを共有する方法であって、コンピューティングシステムにおいてサービス仮想マシンで実行されているサービスオペレーティングシステムOSの物理ネットワークインターフェースカードNICドライバによって、前記コンピューティングシステムに結合されているネットワークを介して前記物理NICデバイスによって受信するネットワークパケットを受信する段階と、サービスOSネットワークスタック部のブリッジドライバ部によって、前記ネットワークパケットをサービスOS仮想NICドライバにルーティングする段階と、前記サービスOS仮想NICドライバによって、前記コンピューティングシステムの共有メモリの空いているブロックに前記ネットワークパケットの少なくとも一部を複製して、前記ブロックを前記共有メモリ内の受信待ち行列に付加する段階と、顧客仮想マシンで実行されている顧客OSの仮想NICドライバによって、前記受信待ち行列から前記ブロックをフェッチして、前記一部を顧客OS要求パケットにパッケージングする段階と、前記顧客OSの仮想NICドライバによって、前記顧客OS要求パケットを顧客OSネットワークスタック部に渡す段階とを備える方法。前記サービスOSの仮想NICドライバによってVMCALL命令を呼び出して、前記コンピューティングシステムの仮想マシンマネージャVMMから前記顧客OSの仮想NICドライバに対してネットワークパケットが利用可能である旨を通知させ、前記VMMに前記顧客OSの仮想NICドライバに対して割り込みを発行させる段階をさらに備える請求項15に記載の方法。前記サービスOSは、前記コンピューティングシステムのプロセッサによって提供されるセキュアエンクレーブセッション内で実行される請求項15に記載の方法。複数の仮想マシンで一の物理ネットワークインターフェースカードNICデバイスを共有するコンピューティングシステムであって、サービスオペレーティングシステムOSを実行しているサービス仮想マシンと、顧客OSを実行している顧客仮想マシンとを備え、前記サービスOSは、前記コンピューティングシステムに結合されているネットワークを介して前記物理NICデバイスが受信するネットワークパケットを受信する物理ネットワークインターフェースカードNICドライバと、前記ネットワークパケットをルーティングするサービスOSネットワークスタック部のブリッジドライバ部と、前記ブリッジドライバ部から前記ネットワークパケットを受信して、前記ネットワークパケットの少なくとも一部を前記コンピューティングシステムの共有メモリの空いているブロックに複製して、前記共有メモリ内の受信待ち行列に前記ブロックを付加するサービスOS仮想NICドライバとを有し、前記顧客OSは、前記受信待ち行列から前記ブロックをフェッチして、前記一部を顧客OS要求パケットにパッケージングする顧客OS仮想NICドライバと、前記顧客OS仮想NICドライバから前記顧客OS要求パケットを受信する顧客OSネットワークスタック部とを有するコンピューティングシステム。仮想マシンマネージャVMMをさらに備え、前記サービスOS仮想NICドライバは、VMCALL命令を前記VMMに呼び出して、要求パケットが利用可能である旨を前記顧客OS仮想NICドライバに通知し、前記VMMは前記顧客OS仮想NICドライバに割り込みを発行する請求項18に記載のコンピューティングシステム。前記サービスOSは、前記コンピューティングシステムのプロセッサによって提供されるセキュアエンクレーブセッション内で実行される請求項19に記載のコンピューティングシステム。本発明の実施形態は、コンピューティングシステムにおいて複数の仮想マシンVMで一の物理ネットワークインターフェースカードNICデバイスを共有するためのシステムおよび方法を含む。本発明の実施形態によると、サービスOSと呼ばれ、且つ、第1のVMで実行される一のオペレーティングシステムOSが、物理NICへのアクセスを制御すると共に、消費側OSと呼ばれる1以上の他のOSからの通信要求を処理する。顧客OSは、別のVMで実行され、アプリケーションプログラムを介してコンピュータシステムのユーザとやり取りする。アプリケーションプログラムは、顧客OSと同じVMで実行される。顧客OSは、物理NICデバイスを介して通信を行う必要がある場合、サービスOSにネットワーク要求パケットを送信する。サービスOSは、ネットワーク要求パケットを解釈して、物理NICに当該パケットを転送する。このため、サービスOSは顧客OSのためにNICを仮想化して、コンピューティングシステムが顧客OS毎に一の物理NICを含む必要はない。本明細書において本発明の一実施形態または実施形態という表現を用いるが、これは当該実施形態に関連付けて説明する特定の特徴、構造、または特性が本発明の少なくとも1つの実施形態に含まれることを意味する。このため、一実施形態という表現は本明細書において繰り返し用いられるが、必ずしも全てが同じ実施形態を意味するものではない。本発明の実施形態は、物理NICの仮想化を保護することを目的として、サービスOSを実行している第1のVMを、コンピューティングシステムのプロセッサパッケージ内のセキュアエンクレーブSEセッション内で実行するとしてよい。図1は、本発明の実施形態に係るコンピューティングシステムにおいてセキュアエンクレーブセッションを示す図である。説明を目的として、コンピューティングシステム100の一部を簡単に図1に示す。プロセッサパッケージ102は、セキュリティペリメータ内に1以上のプロセッシングコアを有する。一実施形態によると、セキュリティペリメータは、プロセッサパッケージの境界であってよい図1では太線で示す。プロセッサパッケージは、メモリ104およびプラットフォームコントロールハブPCH106と接続している。PCHは、1以上のI/Oデバイス108と接続している。セキュアエンクレーブ機能を実現するべく、セキュアエンクレーブを作成して、強制的に分離を行い、命令実行およびデータアクセスを保護するプロセッサ命令を複数提供する。プロセッサパッケージの外部にあるデータおよびコードは、暗号化されて、インテグリティをチェックするとしてよい。プロセッサパッケージの内部にあるデータおよびコードは、暗号化されておらず、モードおよびキャッシュ保護メカニズムで保護されているとしてよい。実施形態によると、データがセキュアエンクレーブから漏れることはない。プロセッサパッケージ内のマイクロコードは、割り込み、例外、トラップ、および、仮想マシンマネージャVMM終了のために、エンクレーブ内にエンクレーブ状態情報を保存する。セキュアエンクレーブ機能は、PCT特許出願発明の名称:セキュアにアプリケーションを実行するための方法および装置、発明者:フランシスX.,マキーンFrancisX.McKeen他、出願日:2009年12月22日、出願番号:PCT/US2009/069212に記載されている。当該出願の内容は参照により本願に組み込まれる。図2は、本発明の実施形態に係る複数の仮想マシンを備えるコンピューティングシステムを示す図である。当該コンピューティングシステムは、図1のプロセッサパッケージ102、メモリ104、PCH106、およびI/Oデバイス108、ならびに、図示していないがその他の従来素子を有するコンピューティングプラットフォーム200を備える。I/Oデバイスのうち1つがNICであってよい。ベーシックインプット/アウトプットシステムBIOS202として知られるシステムファームウェアは、コンピューティングプラットフォームで実行され、システムブート時間においてコンピューティングプラットフォームの構成要素の特定、試験、および初期化を開始すると共に、コンピューティングプラットフォームのハードウェアとコンピューティングシステムのソフトウェア素子との間のインターフェースを提供する。公知の仮想化技術をサポートする本発明の実施形態によると、BIOSがコンピューティングプラットフォームの初期化を完了した直後に仮想マシンマネージャVMMが実行されるとしてよい。VMMは、コンピューティングプラットフォームにおいて複数の仮想マシンを同時に実行する構成をサポートする。VMMは、仮想プラットフォームでゲストオペレーティングシステムを提示して、ゲストオペレーティングシステムの実行を監視する。このようにして、同じオペレーティングシステムの複数のインスタンスを含む複数のオペレーティングシステムは、ハードウェアリソースを共有することができるようになる。マルチタスキングでも複数のアプリケーションがハードウェアリソースを共有するが、これとは異なり、VMMを用いた仮想マシン方式では、一のオペレーティングシステムのエラーを、ハードウェアを共有しているほかのオペレーティングシステムから分離させる。VMMは、システム内のVMのための実行環境を準備する。VMMは、必要に応じて、1以上のVMを起動する。本発明の実施形態によると、複数のVMを同時に起動および実行するとしてよく、VMには少なくとも2種類あるとしてよい。最初の種類のVMは、サービスOSSOS216を実行しているサービスVM214である。サービスOSは通常、他のVMで実行されている他のOSに対してサービスを提供し、そのようなサービスを提供するためにVMM204とやり取りする。二番目の種類のVMは、顧客VM206で実行されている顧客OSCOS210ゲストOSとも呼ばれるである。顧客OSは、コンピューティングシステムのユーザとやり取りを行なうアプリケーションプログラム図2では不図示をサポートしている。顧客OSは、VMM204およびサービスOS216が提供するサービスに依存している。顧客VMで実行されているアプリケーションプログラムは、サービスVMで実行されているサービスOSと直接やり取りすることはできない。本発明の実施形態によると、複数の顧客VM1206~N-1208は、起動されて顧客OS1210~N-1212をそれぞれ実行するとしてよい。図3は、本発明の実施形態に係る仮想マシンのためのネットワークスタックを備えるコンピューティングシステムを示す図である。実施形態によると、顧客VM1206で実行されているCOS1304等の顧客OSのうちいずれか1つがサポートしているアプリケーションプログラム304にネットワークサービスを提供するべく、VMM204図3には不図示はCOS仮想NICデバイス310を作成する。顧客OSにとって、この仮想化NICデバイスは物理NICデバイスと同様に機能する。COS仮想NICドライバ部308が顧客OS1304内に作成されるとしてよい。COS仮想NICドライバ308は、上位レベルのCOSネットワークスタック306からのネットワーク要求を処理し、要求の結果を返す役割を持つとしてよい。アプリケーションプログラム304が物理NICデバイスでのI/Oを要求すると、当該要求はCOSネットワークスタック306、COS仮想NICドライバ308、およびCOS仮想NICデバイス310で処理されるとしてよい。COS仮想NICデバイス310が処理する応答が、COS仮想NICドライバ308およびCOSネットワークスタック306を介してアプリケーションプログラムに転送されて返ってくるとしてよい。対応するサービスOSSOS仮想NICデバイス320が、サービスVM214によるアクセスのために作成されるとしてよい。また、サービスVM214で実行されるサービスOS216内に、対応するSOS仮想NICドライバ316も作成されるとしてよい。顧客VM206に結合されているCOS仮想NICデバイス310が発行する要求は、処理のために、サービスVM214に結合されているSOS仮想NICデバイス320に転送されるとしてよい。当該要求は、SOS仮想NICデバイス320と、サービスOS内のSOSネットワークスタック314とによって処理されるとしてよい。サービスOSは、物理NICデバイス322とやり取りを行なっているので、物理NICドライバ318および物理NICデバイス322による当該要求の実行を制御するとしてよい。当該要求に対する応答は、逆方向に流れるとしてよく、物理NICデバイス322から物理NICドライバ318に流れ、SOSネットワークスタック314、SOS仮想NICドライバ316、およびSOS仮想NICデバイス320を通過して、サービスOSに戻るとしてよい。このため、顧客OS210は物理NICデバイス322と通信していると錯覚する。サービスOS216がセキュアエンクレーブセッション内で実行される場合、物理NICデバイス322が関連するI/O要求は、顧客VM内のアプリケーションプログラムまたは顧客OS内で実行されるほかのプログラムによる悪意ある処理から保護されるとしてよい。システム初期化時点、または、物理NICデバイスがコンピューティングシステムに追加される任意の時点において、物理NICデバイスに対するアクセスを保護するべくセキュアエンクレーブセッションが開始されるとしてよい。I/O要求は、ネットワーク要求パケットとしてアプリケーションプログラム304からCOSネットワークスタック306を介してCOS仮想NICドライバ308に到達すると、トランスミッションコントロールプロトコルTCP、ユーザデータグラムプロトコルUDPおよびインターネットプロトコルIPといったネットワークプロトコル層によって処理されている。ネットワーク要求パケットは、ネットワークを介した送信に必要な情報を含むので、物理NICデバイスに送信されるべく物理NICドライバに供給されるとしてよい。図4は、本発明の実施形態に係るネットワーク要求パケットを示す図である。ネットワーク要求パケット400は、OS関連情報402および媒体アクセス制御MACフレーム情報404を備える。OS関連情報402は、ネットワークスタックドライバまたはNICデバイスドライバが利用する情報および/またはパラメータを含む。この部分は、物理NICデバイスのネットワークインターフェースには送信されず、サービスOSに理解されない可能性もあるので、ネットワーク要求パケットのこの部分は無視するとしてよい。MACフレーム情報が、ネットワークインターフェース例えば、イーサネット登録商標ネットワーク媒体の基本送信部に実際に送信される内容である。本発明の実施形態によると、顧客OSが直接利用可能な物理NICデバイスはないので、COS仮想NICドライバ308はサービスVMおよびVMMの構成要素にパケットの送信を依存する。VMMは、処理すべきパケットがある場合にサービスOSに通知して、顧客VMとサービスVMとの間でデータを交換する際に利用される共有メモリ領域を作成する。共有メモリ領域は、顧客OSおよびサービスOSの両方に可視の領域であるので、各VMの仮想NICドライバはパケットにアクセスが可能でパケットを適宜処理可能であるとしてよい。一実施形態によると、共有メモリはメモリ104内で実現されるとしてもよい。図5は、本発明の実施形態に係る仮想マシン間で共有されるメモリおよび実行される通信を示す図である。COS仮想NICドライバ308は、ネットワーク要求パケットからMACフレーム404を抽出して、共有メモリ内でメモリブロックを割り当てて、MACフレームを共有メモリのブロックに複製して、このブロックを指定された送信TX待ち行列506に付加するとしてよい。TX待ち行列506は、出力用MACフレームの管理を支援する共有メモリ内にある。逆方向の経路では、物理NICデバイス322がパケットを受信して、サービスOSが当該パケットを管理している場合、サービスOSの構成要素つまり、物理NICドライバ318、SOSネットワークスタック314、および、SOS仮想NICドライバ316はMACフレームを抽出して、MACフレームの内容を共有メモリ内の空いたメモリブロックに複製して、当該ブロックを受信RX待ち行列508に付加する。COS仮想NICドライバ308は、以下の手順で、送信が必要なMACフレームがある旨をサービスOSに通知するとしてよい。本発明の実施形態によると、公知の仮想化技術に基づくメッセージ通知メカニズムを利用するとしてよい。VMM204は、顧客OSとサービスOSとの間で媒介役として動作するとしてよく、必要に応じて適切なOSに通知するとしてよい。例えば、顧客OS1210は、サービスOS216との通信を希望する場合、VMCALL510という名称の特権命令を実行するとしてよい。VMCALL命令は、現在のVM環境を終了して、VMM204における選択サービスを呼び出すための命令である。このようなサービスは、VMM内のVMCALL命令処理部によって提供されるとしてよい。VMCALL処理部は図5では不図示、VMCALLの入力パラメータを確認して、VMMからサービスOSに通知すべきか否かを判断するとしてよい。VMMは、通知すべきである場合、メッセージを記録して、顧客OSに制御を戻す。VMMは、常にコンピューティングシステム内で実行中のプロセスであるので、サービスOS実行用のタイムスロットを利用する場合、割り込み516を利用してサービスOSに通知しようと試みる。同様に、サービスOSは、顧客OSとの通信を希望する場合、VMCALL514を実行してVMMは顧客OSに割り込み512を用いて通知するとしてよい。サービスOS側を見ると、サービスOSは顧客OSのネットワーク送受信用エージェントであるので、本発明の実施形態はこのエージェント構成をサポートするべく2つのドライバ部を提供している。一方は、SOS仮想NICドライバ316である。他方は、ブリッジドライバ部502である。サービスOS内のSOS仮想NICドライバ316は、共有メモリ504内の送信TX待ち行列506によって顧客OSから出力用MACフレームを収集して、収集した出力用MACフレームをブリッジドライバを介して物理NICドライバ318に渡す役割を持つ。また、ブリッジドライバは、顧客OS宛の入力パケットを物理NICドライバ318から受信して、顧客OSがアクセスできるように当該パケットを共有メモリ504内の受信RX待ち行列508に入れる。詳細に説明すると、送信TX待ち行列506に出力用パケットがある旨の通知をSOS仮想NICドライバ316がVMM204から受けると、サービスOS内のSOS仮想NICドライバは、送信TX待ち行列からMACフレームを抽出して、当該フレームを新しいネットワーク要求パケットへとパッケージングし直して、新しいパケットをSOSネットワークスタック314にコミットする。他方、SOS仮想NICドライバ316は、顧客OS宛のパケットをSOSネットワークスタックから受信すると、OS関連部分を除外して、顧客OSがアクセスできるようにMACフレームを受信RX待ち行列508に入れる。上述したメッセージ通知方法は、顧客OSに入力パケットを処理するように通知する場合に用いられるとしてもよい。本発明の実施形態によると、ブリッジドライバ502は、IPプロトコル層でフィルタドライバを実現するので、物理NICドライバ318を介して物理NICデバイスから入力されるパケットを全て確認して、正しい宛先にルーティングする。例えば、ブリッジドライバは、SOS仮想NICドライバ316から受信したパケットを見つけると、当該パケットを物理NICドライバ318に転送する。ブリッジドライバは、物理NICドライバ318から受信したパケットを見つけると、当該パケット内のIPアドレス情報を確認して、当該パケットが顧客OS210またはサービスOS216のいずれに送信されるべきかを判断する。ブリッジドライバは、当該パケットが顧客OS210に送信されるべきと判断すると、当該パケットをSOS仮想NICドライバ308に転送して、当該情報をさらに顧客OSへと転送させる。物理NICドライバ318から受信したパケットの宛先が顧客OSおよびサービスOSのいずれであるかを識別する方法は少なくとも2つ考えられるとしてよい。最初の方法は、顧客OSおよびサービスOSが異なるIPアドレスを利用するので、ブリッジドライバ502は受信したネットワークパケット内のIPアドレス情報を参照して、どのOSがパケットの受信者であるかを判断する方法である。二番目の方法として、顧客OSおよびサービスOSが同じIPアドレスを用いるが、使用するTCPポートまたはUDPポートの範囲が異なる方法がある。最初の方法は、パケットルーティングロジックが簡単であるが、IPアドレスリソースのコストが高くなる場合がある。二番目の方法は、IPアドレスリソースを節約できるが、ブリッジドライバ内のパケットルーティングロジックがより複雑になってしまう場合がある。これら2つの方法のうちいずれを選択するかは、目的とする利用モデルに応じて変わり、実施例毎に決まる。図6および7は、本発明の実施形態に係るネットワーク要求パケット送信処理を示すフローチャートである。ブロック600において、物理NICデバイスへ送信されるべきネットワーク要求パケットを顧客OSCOSネットワークスタック306から受信すると、ブロック602において、COS仮想NICドライバ308は、サービスOSSOS216およびVMM204が準備できているか否かを判断するとしてよい。サービスOSおよびVMMの一方または両方が準備できていない場合、ブロック604に進み、エラーメッセージを報告して、顧客OSに制御を戻すとしてよい。ブロック602においてサービスOSおよびVMMが準備できている場合、ブロック612において、共有メモリに空いているブロックがあるか否かを確認するとしてよい。空いているブロックがない場合、ブロック604に進み、エラーが報告されるとしてよい。空いているブロックがある場合、図7のブロック702に進む。図7のブロック702では、COS仮想NICドライバ308が、ネットワーク要求パケットのMACフレームを共有メモリ504内の空いているブロックに複製する。ブロック704では、新たにMACフレームが入れられたブロックを送信待ち行列TX506に付加するとしてよい。この後、ブロック706において、COS仮想NICドライバ308は、VMCALL命令510を呼び出して、VMM204を介してサービスOS216に通知を行なう。ブロック708において、VMMはサービスOSに対する割り込み516を発行する。これに応じて、サービスOS内のSOS仮想NICドライバ316は、ブロック710において割り込みを受信して、ブロック712において送信待ち行列TX506の次のノードをフェッチする。ブロック714において、SOS仮想NICドライバ316は、送信待ち行列TX内の次のノードが含むMACフレーム情報を新しいサービスOS要求パケットにパッケージングする。この後、ブロック716において、SOS仮想NICドライバ316は、新しいサービスOS要求パケットをサービスOSネットワークスタック314に渡す。続いて、ブロック718において、ブリッジドライバ502は、新しいサービスOS要求パケットを物理NICドライバ318にルーティングする。ブロック720において、新しいサービスOS要求パケットは、物理NICドライバによってネットワークインターフェースを介して送信される。図8および図9は、本発明の実施形態に係るネットワーク要求パケット受信処理を示すフローチャートである。ブロック800において、物理NICドライバ318は、物理NICデバイス322から少なくとも1つのネットワークパケットを受信して、当該ネットワークパケットをサービスOS216内のSOSネットワークスタック314に渡す。ブロック802において、ネットワークスタック内のブリッジドライバ502は、入力されたパケットを、サービスOS内のSOS仮想NICドライバ316にルーティングする。ブロック804において、SOS仮想NICドライバ316は、顧客OSCOS210およびVMM204が準備できているか否かを判断するとしてよい。顧客OSおよびVMMの一方または両方が準備できていない場合、ブロック806に進み、エラーメッセージを報告して、サービスOSに制御を戻すとしてよい。ブロック814において顧客OSおよびVMMが準備できている場合、共有メモリに空いているブロックがあるか否かを確認するとしてよい。空いているブロックがない場合、ブロック806に進み、エラーメッセージが報告されるとしてよい。空いているブロックがある場合、図9のブロック902に進む。図9のブロック902では、SOS仮想NICドライバ316が、受信したネットワークパケットのMACフレームを共有メモリ504内の空いているブロックに複製する。ブロック904では、新たにMACフレームが入れられたブロックを受信待ち行列RX508に付加するとしてよい。この後、ブロック906において、SOS仮想NICドライバ316は、VMCALL命令514を呼び出して、VMM204を介して顧客OS210に通知を行なう。ブロック908において、VMMは顧客OSに対する割り込み512を発行する。これに応じて、顧客OS内のCOS仮想NICドライバ308は、ブロック910において割り込みを受信して、ブロック912において受信待ち行列RX508の次のノードをフェッチする。ブロック914において、COS仮想NICドライバ308は、受信待ち行列RX内の次のノードが含むMACフレーム情報を新しい顧客OS要求パケットにパッケージングする。この後、ブロック916において、COS仮想NICドライバ308は、新しい応答パケットを顧客OSネットワークスタック306に、そして、アプリケーションプログラム304に渡す。このように、本発明の実施形態は、顧客OSで実行されているユーザのアプリケーションプログラムがネットワークにアクセスする必要がある場合、複数の仮想マシンで一の物理NICデバイスを共有するとしてよい。物理NICデバイスを追加するべくインストールする必要はない。当業者であれば、本発明の範囲を逸脱することなく、別の方式を採用して一の物理NICデバイスに複数の仮想マシンがセキュアにアクセスできるようにする選択肢があるものと認めるであろう。また、当業者であれば、本明細書に開示した発明は、ソフトウェアのみで構成されるか、ハードウェアのサポートを含むかに関わらず、コンピュータシステムまたはプログラミング環境の部分仮想化または完全仮想化に基づく他の種類の仮想化環境および仮想化システムにも利用され得るものと認めるであろう。また、当業者は、顧客OSの数および対応する顧客VMの数は3以上であり、実施例毎に決まるものと認めるであろう。さらに、2以上の顧客VMが同時に実行されている場合、一の顧客VMがある種類のOSを実行しており例えば、MicrosoftWindows登録商標7、別の顧客VMが別の種類のOS例えば、Linux登録商標を実行するとしてよい。さらに、当業者であれば、本発明の実施形態は別の方式およびさまざまなプログラミング言語を用いて実施し得るものと認めるであろう。本明細書に記載した技術は、任意の特定のハードウェア構成またはソフトウェア構成に限定されるものではなく、任意のコンピューティング環境または処理環境で利用可能であるとしてよい。本明細書に記載した技術は、ハードウェア素子、ソフトウェア素子あるいはファームウェア素子、または、これらの組み合わせで具現化されるロジックに実装されるとしてよい。本明細書に記載した技術は、携帯型または固定型のコンピュータ、携帯情報端末、セットトップボックス、携帯電話およびポケベル、ならびにその他の電子機器等、プロセッサと、プロセッサから読出可能な格納媒体揮発性および不揮発性のメモリおよび/または格納素子を含むと、少なくとも1つの入力デバイスと、1以上の出力デバイスとを備えるプログラミング可能な機械で実行されるプログラムに実装されるとしてよい。入力デバイスを用いて入力されたデータにプログラムコードを適用して、上述した機能を実行して、出力情報を生成する。出力情報は、1以上の出力デバイスに適用されるとしてよい。当業者であれば、本発明はさまざまなコンピュータシステム構成、例えば、マルチコアプロセッサ、マルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ等で実施し得ることを認めるであろう。本発明はさらに、通信ネットワークを介して接続される複数の遠隔プロセッシングデバイスでタスクを実行する分散型コンピューティング環境でも実施可能である。各プログラムは、プロセッシングシステムと通信するべく高級プロシージャ言語またはオブジェクト指向型プログラミング言語で実装されるとしてよい。しかし、所望の場合は、アセンブリ言語または機械言語でプログラムを実装するとしてもよい。いずれにしても、コンパイル型言語またはインタプリタ型言語のいずれを用いるとしてもよい。プログラム命令を用いて、命令がプログラミングされている汎用プロセッシングシステムまたは特定用途向けプロセッシングシステムに、本明細書に記載した処理を実行させるとしてよい。これに代えて、本明細書に記載した処理を実行するハードワイヤードロジックを含む特定のハードウェア素子で、または、プログラミングされたコンピュータ素子およびカスタマイズされたハードウェア素子を任意に組み合わせて、本明細書に記載した処理を実行するとしてもよい。本明細書に記載した方法は、当該方法を実行するようにプロセッシングシステムまたはその他の電子機器をプログラミングする際に利用される命令を格納している機械可読媒体を含むコンピュータプログラム製品として提供されるとしてよい。機械可読媒体という用語は、本明細書で用いられる場合、機械によって実行される命令列を格納または符号化することが可能で、且つ、本明細書に記載した方法のうちいずれか1つを機械に実行させる任意の媒体を含むものとする。したがって、機械可読媒体という用語は、これらに限定されないが、ソリッドステートメモリ、光ディスク、および、磁気ディスクを含むとする。さらに、関連技術分野ではソフトウェアに言及する際に、処理を行なうものまたは結果を生じさせるものとして、さまざまな用語例えば、プログラム、プロシージャ、プロセス、アプリケーション、モジュール、ロジック等を用いることが一般的である。このような表現は単に、プロセッサに処理を実行させるか、または、結果を生じさせるためのプロセッシングシステムによるソフトウェアの実行を簡潔に記載する方法に過ぎない。本発明を実施形態例を参照しつつ説明してきたが、上記の説明は本発明を限定するものと解釈されるべきではない。本発明の実施形態例のさまざまな変形例および本発明の上記以外の実施形態は、本発明の関連技術分野の当業者には明らかであるが、本発明の範囲に含まれるものとする。"