"方法であって、第二の実行環境を有する第二のオペレーティングシステムによって、第一のオペレーティングシステムのためにコンパイルされ、前記第一のオペレーティングシステムの第一の実行環境内にロードされたアプリケーションのリストを前記第一のオペレーティングシステムに問い合わせることであって、前記第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、前記問い合わせること、前記第二のオペレーティングシステムにおいて、アプリケーションオブジェクトのリストを受け取ることであって、各アプリケーションオブジェクトがアプリケーションパッケージを含む、前記受け取ること、前記第二のオペレーティングシステムのメニューにおいて、前記アプリケーションオブジェクトのリストの中の1つのアプリケーションオブジェクトに対応する第一のメニューアイテムのインスタンスを作成すること、前記第一のメニューアイテムが、選択された時に、前記第二のオペレーティングシステムのコンソールアプリケーションを実行するように、前記第一のメニューアイテムを前記第二のオペレーティングシステムの前記コンソールアプリケーションに関連付けること、前記アプリケーションオブジェクトに対応する前記第一のOSの中の前記アプリケーションパッケージを示すパラメータを、前記第一のメニューアイテムに関連付けること含む、方法。請求項1に記載の方法であって、前記第一のオペレーティングシステムの第一のグラフィクスサーバが、前記第二のオペレーティングシステムの第二のグラフィクスサーバと非互換的である、方法。請求項1に記載の方法であって、第一のグラフィクスサーバがAndroid用グラフィクスサーバを含み、第二のグラフィクスサーバがXウィンドウ型のグラフィクスサーバを含む、方法。請求項1に記載の方法であって、前記第二のオペレーティングシステムのグラフィクスサーバがXウィンドウ型のグラフィクスサーバであり、前記第一のオペレーティングシステムの、前記アプリケーションオブジェクトに対応するアプリケーションが、前記第二のオペレーティングシステムの前記Xウィンドウ型のグラフィクスサーバと非互換的なグラフィクスライブラリを使用する、方法。請求項1に記載の方法であって、前記アプリケーションオブジェクトが、アプリケーション名、アプリケーションパッケージ名、およびアプリケーションアイコンを含む、方法。請求項1に記載の方法であって、前記第一のメニューアイテムが、選択されると、アプリケーションパッケージ名を実行パラメータとして前記コンソールアプリケーションに送る、方法。請求項1に記載の方法であって、前記第二のオペレーティングシステムのメニューが、第二のアプリケーションに対応する第二のメニューアイテムを含み、前記第二のアプリケーションが前記第二の実行環境のためにコンパイルされ、前記第二の実行環境内にロードされている、方法。請求項1に記載の方法であって、前記第一のオペレーティングシステムがモバイルオペレーティングシステムを含み、前記第二のオペレーティングシステムがデスクトップオペレーティングシステムを含む、方法。方法であって、第一のオペレーティングシステムのためにコンパイルされ、前記第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを、前記第一のオペレーティングシステムにおいて起動させるための要求を、前記第一のオペレーティングシステムによって、第二のオペレーティングシステムから受け取ることであって、前記第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、前記受け取ること、前記第一のオペレーティングシステムによって仮想ディスプレイを割り当てること、前記第一のオペレーティングシステム内のプロセスにおいて前記第一のアプリケーションを起動させること、前記第一のアプリケーションのためのリフレッシュ通知を前記仮想ディスプレイに関連付けること、前記第一のアプリケーションのためのアプリケーショングラフィクスを、前記第一のオペレーティングシステムによって、前記第一のアプリケーションのアプリケーショングラフィクス情報をモニタするステップと、前記アプリケーショングラフィクス情報が更新された時に、前記第二のオペレーティングシステムのコンソールアプリケーションに通知するステップとを繰り返し実行することによって維持することを含む、方法。請求項9に記載の方法であって、前記第二のオペレーティングシステムのコンソールアプリケーションに通知するステップが、ファイル記述子を前記コンソールアプリケーションに送ることを含み、前記ファイル記述子は、前記アプリケーショングラフィクス情報が共有メモリ位置において利用可能であることを示しており、前記共有メモリ位置が前記第一のオペレーティングシステムと前記第二のオペレーティングシステムとによってアクセス可能である、方法。請求項10に記載の方法であって、前記ファイル記述子が、プロセス間通信チャネルを通じて送られる、方法。請求項11に記載の方法であって、前記プロセス間通信チャネルが、ローカルソケットを含む、方法。請求項11に記載の方法であって、前記プロセス間通信チャネルが、Unixドメインソケットを含む、方法。請求項11に記載の方法であって、前記プロセス間通信チャネルが、Binderインタフェースを含む、方法。請求項14に記載の方法であって、前記アプリケーショングラフィクス情報が、前記第一のアプリケーションのサーフェス情報を含む、方法。請求項14に記載の方法であって、前記アプリケーショングラフィクス情報が、前記第一のアプリケーションの、レンダリングされたグラフィクス情報を含む、方法。請求項14に記載の方法であって、前記第二のオペレーティングシステムが、ユーザが前記第二のオペレーティングシステムのメニューのメニューアイテムを選択したことに応答して、前記第一のアプリケーションを起動させる要求を発行する、方法。方法であって、第一のオペレーティングシステムのためにコンパイルされ、前記第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを起動させる要求を、前記第一のオペレーティングシステムによって、第二のオペレーティングシステムのコンソールアプリケーションから受け取ることであって、前記第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、前記受け取ること、前記第一のオペレーティングシステム上の第一のプロセス内で前記第一のアプリケーションを実行することであって、前記第一のアプリケーションが、前記第一のオペレーティングシステムのサーフェスマネージャによって維持されるグラフィクス情報を含む、前記実行すること、前記第一のオペレーティングシステムによって、前記コンソールアプリケーションを前記第一のオペレーティングシステムの仮想ディスプレイ識別子に関連付けること、前記コンソールアプリケーションを登録して、前記第一のアプリケーションの前記グラフィクス情報に関するリフレッシュ通知を受け取ることを含む、方法。請求項18に記載の方法であって、前記サーフェスマネージャにより、グラフィクスフレームを前記第一のオペレーティングシステムのフレームバッファメモリにレンダリングすること、前記第一のアプリケーションに関するグラフィクス情報が更新されたら、前記コンソールアプリケーションに通知することをさらに含む、方法。本発明の実施形態は、1つのモバイルコンピューティングデバイスにおいて、スマートフォンのモバイルコンピューティング体験と第二の端末環境の適切なユーザ体験を提供することに関する。第二の端末環境は、有線例えば、USB、Firewire、Thunderbolt等または無線例えば、Bluetooth、WiFi等接続によりコンピューティングデバイスに接続された視覚的レンダリングデバイス例えば、モニタやディスプレイ、入力デバイス例えば、マウス、タッチパッド、タッチスクリーン、キーボード等、及びその他のコンピューティング周辺機器例えば、HDD、光ディスクドライブ、メモリスティック、カメラ、プリンタ等のいくつかの組合せであってもよい。実施形態では、モバイル環境のユーザ体験に関連するモバイルオペレーティングシステムと第二の端末環境のユーザ体験に関連するデスクトップオペレーティングシステムが、共有カーネル上で同時に独立して動作する。各種の実施形態と適合する1つの態様によれば、異環境間リダイレクションは、方法であって、第二の実行環境を有する第二のオペレーティングシステムによって、第一のオペレーティングシステムのためにコンパイルされ、第一のオペレーティングシステムの第一の実行環境内にロードされたアプリケーションのリストを第一のオペレーティングシステムに問い合わせることであって、第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、問い合わせること、第二のオペレーティングシステムにおいて、アプリケーションオブジェクトのリストを受け取ることであって、各アプリケーションオブジェクトがアプリケーションパッケージを含む、受け取ること、第二のオペレーティングシステムのメニューにおいて、アプリケーションオブジェクトのリストの中の1つのアプリケーションオブジェクトに対応する第一のメニューアイテムのインスタンスを作成すること、第一のメニューアイテムが、選択された時に、第二のオペレーティングシステムのコンソールアプリケーションを実行するように、第一のメニューアイテムを第二のオペレーティングシステムのコンソールアプリケーションに関連付けること、アプリケーションオブジェクトに対応する第一のOSの中のアプリケーションパッケージを示すパラメータを、第一のメニューアイテムに関連付けること含む、方法により提供される。各種の実施形態と適合する他の態様によれば、第一のオペレーティングシステムの第一のグラフィクスサーバが、第二のオペレーティングシステムの第二のグラフィクスサーバと非互換的であってもよい。第一のグラフィクスサーバは、Android用グラフィクスサーバであってよく、第二のグラフィクスサーバは、Xウィンドウ型のグラフィクスサーバであってよい。第二のオペレーティングシステムのグラフィクスサーバがXウィンドウ型のグラフィクスサーバであり、第一のオペレーティングシステムの、アプリケーションオブジェクトに対応するアプリケーションが、第二のオペレーティングシステムのXウィンドウ型のグラフィクスサーバと非互換的なグラフィクスライブラリを使用してもよい。各種の実施形態と適合する他の態様によれば、アプリケーションオブジェクトが、アプリケーション名、アプリケーションパッケージ名、およびアプリケーションアイコンを含んでもよい。第一のメニューアイテムが、選択されると、アプリケーションパッケージ名を実行パラメータとしてコンソールアプリケーションに送ってもよい。第二のオペレーティングシステムのメニューが、第二のアプリケーションに対応する第二のメニューアイテムを含み、第二のアプリケーションが第二の実行環境のためにコンパイルされ、第二の実行環境内にロードされていてもよい。第一のオペレーティングシステムがモバイルオペレーティングシステムを含んでもよく、第二のオペレーティングシステムがデスクトップオペレーティングシステムを含んでもよい。各種の実施形態と適合する他の態様によれば、アプリケーションまたはグラフィクスコンテキストの異環境間リダイレクションのための方法であって、第一のオペレーティングシステムのためにコンパイルされ、第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを、第一のオペレーティングシステムにおいて起動させるための要求を、第一のオペレーティングシステムによって、第二のオペレーティングシステムから受け取ることであって、第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、受け取ること、第一のオペレーティングシステムによって仮想ディスプレイを割り当てること、第一のオペレーティングシステム内のプロセスにおいて第一のアプリケーションを起動させること、第一のアプリケーションのためのリフレッシュ通知を仮想ディスプレイに関連付けること、第一のアプリケーションのためのアプリケーショングラフィクスを、第一のオペレーティングシステムによって、第一のアプリケーションのアプリケーショングラフィクス情報をモニタするステップと、アプリケーショングラフィクス情報が更新された時に、第二のオペレーティングシステムのコンソールアプリケーションに通知するステップとを繰り返し実行することによって維持することを含む、方法が提供される。各種の実施形態と適合する他の態様によれば、第二のオペレーティングシステムのコンソールアプリケーションに通知するステップが、ファイル記述子をコンソールアプリケーションに送ることを含んでよく、ファイル記述子は、アプリケーショングラフィクス情報が共有メモリ位置において利用可能であることを示しており、共有メモリ位置が第一のオペレーティングシステムと第二のオペレーティングシステムとによってアクセス可能である。ファイル記述子が、プロセス間通信チャネルを通じて送られてもよく、プロセス間通信チャネルは、Unixドメインソケット、またはBinderインタフェースであってよい。アプリケーショングラフィクス情報が、第一のアプリケーションのサーフェス情報を含んでよい。代替的に、アプリケーショングラフィクス情報が、第一のアプリケーションの、レンダリングされたグラフィクス情報を含んでもよい。第二のオペレーティングシステムが、ユーザが第二のオペレーティングシステムのメニューのメニューアイテムを選択したことに応答して、第一のアプリケーションを起動させる要求を発行してもよい。各種の実施形態と適合する他の態様によれば、アプリケーションまたはグラフィクスコンテキストの異環境間リダイレクションのための方法であって、第一のオペレーティングシステムのためにコンパイルされ、第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを起動させる要求を、第一のオペレーティングシステムによって、第二のオペレーティングシステムのコンソールアプリケーションから受け取ることであって、第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、受け取ること、第一のオペレーティングシステム上の第一のプロセス内で第一のアプリケーションを実行することであって、第一のアプリケーションが、第一のオペレーティングシステムのサーフェスマネージャによって維持されるグラフィクス情報を含む、実行すること、第一のオペレーティングシステムによって、コンソールアプリケーションを第一のオペレーティングシステムの仮想ディスプレイ識別子に関連付けること、コンソールアプリケーションを登録して、第一のアプリケーションのグラフィクス情報に関するリフレッシュ通知を受け取ることを含む、方法が提供される。方法は、サーフェスマネージャにより、グラフィクスフレームを第一のオペレーティングシステムのフレームバッファメモリにレンダリングすること、第一のアプリケーションに関するグラフィクス情報が更新されたら、コンソールアプリケーションに通知することをさらに含み得る。本発明の実施形態が図面の参照図に示されており、図の説明全体を通じて、同様の参照番号は同様の要素を指す。コンピューティング能力を含む携帯電話機すなわち、スマートフォン、ハンドセット、モバイルステーション、携帯通信機器等の人気はますます高まっている。これらのスマートフォンの多くは、モバイルプロセッサ上で動作するモバイルオペレーティングシステムOSを含む。モバイルプロセッサとモバイルOSによってこれらのデバイスの能力は増大しているが、スマートフォンがデスクトップやノートブックコンピュータのようなパーソナルコンピュータPC環境すなわち、Windows、MacOSX、Linuxに取って代わる傾向は見られず、これは少なくとも提供されるユーザ体験が限られていることによる。特に、スマートフォンに見られるユーザインタフェースデバイスは一般に、モバイル環境に合わせて作られている。例えば、スマートフォンでは一般に、小さい親指式QWERTYキーボード、タッチスクリーンディスプレイ、クリックホイール、及び/またはスクロールホイールがユーザインタフェースデバイスとして使用される。モバイルOSのほか、モバイルOS用に開発されたアプリケーションすなわち、アプリは一般に、モバイルデバイス上にあるモバイルプロセッサとユーザインタフェースデバイスを含むモバイル環境の制約に合わせて設計されている。そのため、PCオペレーティングシステム用に開発された多くのアプリケーションは、モバイルOSでは利用できないすなわち、モバイルOS用にはコンパイルされず、その上では動作しない。これに加えて、文書の作成や編集等、一部の作業については、フルサイズのキーボードや大型ディスプレイのほうが、スマートフォンで一般的に見られるユーザインタフェースコンポーネントより使いやすい。従って、ユーザは一般に、コンピューティング体験ごとに別のコンピューティングデバイス、例えばスマートフォン、タブレットコンピュータ、ラップトップコンピュータ及び/またはデスクトップコンピュータを使用する。この場合、デバイスによってCPU、メモリ、ファイル記憶装置、OSが異なる。スマートフォンと他のデバイスの間の接続とファイル共有のためには、1つのデバイス例えば、モバイルOSを実行するスマートフォンを第二の、完全に異種のデバイス例えば、デスクトップOSを実行するノートブック、デスクトップまたはタブレットに、無線または有線接続を通じて連結する。情報はデバイス間で、各デバイスで別々に動作するアプリケーション間でデータを同期させることによって共有される。このプロセスは一般に同期と呼ばれ、面倒であり、通常、ユーザによる積極的な管理が必要となる。図1は、各種の実施形態による、別々のユーザ操作空間すなわち、ユーザ環境に関連する複数のオペレーティングシステムを含む1つのモバイルデバイスで複数のユーザコンピューティング体験を提供するコンピューティング環境100を示す。コンピューティング環境100の第一のユーザ操作空間115には、モバイルコンピューティングデバイス110のディスプレイ116とI/Oデバイス118が含まれる。モバイルコンピューティングデバイス110が独立したモバイルデバイスとして操作されると、モバイルOS130は、ユーザ操作空間115を通じて一般的なモバイルコンピューティングユーザ体験を提供する。モバイルOS130によって提供されるモバイルコンピューティング体験には一般に、携帯電話機能や、ディスプレイ116とI/Oデバイス118とを含むユーザ操作空間115に適したグラフィカルユーザインタフェースGUIが含まれる。例えば、ティスプレイ116はタッチスクリーンディスプレイであってもよく、モバイルOS130上で動作するアプリケーションプログラムすなわち、アプリは主として、タッチスクリーンディスプレイ116を用いたモバイルOS130のジェスチャ認識GUIを通じて制御されてもよい。コンピューティング環境100の中で、モバイルコンピューティングデバイス110は、I/Oデバイス144、146及び/または148を含む第二の端末環境140とドッキングされてもよい。実施形態では、モバイルコンピューティングデバイス110は第二の端末環境140に、モバイルコンピューティングデバイス110のポート120を第二の端末環境140のポート142に接続することによってドッキングされている。この場合、第二の端末環境140はコンピューティング環境100の第二のユーザ操作空間を提供する。いくつかの例において、第二のユーザ操作空間のほうがデスクトップコンピューティング体験により適していてもよい。このような場合、デスクトップOS160を第二の端末環境140に関連付け、第二のユーザ操作空間を通じて、ノートブック、タブレットまたはデスクトップコンピュータ環境のすべての能力を提供することができる。実施形態では、モバイルOS130とデスクトップOS160は、モバイルコンピューティングデバイス110のプロセッサの共有カーネル上で同時に動作する。共有カーネルでのモバイルOSとデスクトップOSの同時動作は、2011年8月24日に出願された、MULTI-OPERATINGSYSTEMと題する米国特許出願第13/217,108号明細書においてより詳しく説明されており、同出願を参照によって本願に援用する。このように、1つのモバイルコンピューティングデバイスは、第一のユーザ操作空間を通じたモバイルコンピューティング体験と第二のユーザ操作空間を通じたデスクトップコンピューティング体験を提供できる。別々のユーザ操作空間を通じて複数のオペレーティングシステムを同時に実行可能な1台のモバイルデバイスを携帯できることは、ユーザにとっての多くの問題を解決するが、同時動作するモバイルOSとデスクトップOSを通じた各ユーザ操作空間により通常提供される利用可能なアプリケーションとユーザ機能の集合は、それぞれ異なる。本発明の実施形態は、第一のOS例えば、モバイルOS130で動作するアプリケーションを、見かけ上、第二のOS例えば、デスクトップOS160の中で実行しやすくすることに関し、この場合、第一と第二のOSは共有のカーネル上で同時動作中である。特に、ユーザに第一の例えば、非互換的なOSのためにコンパイルされ、その中で動作するアプリケーションに関する、第二のOSにおける入力例えば、入力デバイスと出力例えば、ディスプレイ、オーディオ等をサポートする中で、多くの問題がアドレスされる。同時動作中の複数のアプリケーションの表示と双方向性に対処する場合は、また別の問題も発生し得る。例えば、第一と第二のアプリケーションがどちらも第一のOSのためにコンパイルされ、第一のOS上で同時動作中である場合を考える。しかしながら、ユーザは、一方のOSに関連する入力/出力デバイスを通じて例えば、モバイルコンピューティング環境のタッチスクリーンディスプレイを使って第一のアプリケーションのグラフィクス出力を見て、その第一のアプリケーションを操作し、また第二のOSに関連する入力/出力デバイスを通じて例えば、デスクトップコンピューティング環境のディスプレイ、キーボード、マウスを使って第二のアプリーションのグラフィクス出力を見て、その第二のアプリケーションを操作したいと望む。このようなシナリオに対処するには、複数のディスプレイ環境でのグラフィクスの同時操作と、異なるアプリケーションに関する複数の入力/出力ストリームの同時処理を、すべて別々の例えば、非互換性のオペレーティングシステム上で行う必要がある。従って、実施形態は、第二のOSのユーザ操作空間内で第一のOSのアプリケーションにアクセスし、第二のOSのユーザ操作空間内で第一のOSで実行中のアプリケーションを表示し、第二のOSのユーザ操作空間を通じてこれらのアプリケーションのユーザ操作を扱うための各種の新規な方式を提供する。実施形態は、異環境間アプラケーションの各種のディスプレイとユーザ操作機能をサポートする第二のOSのコンソールアプリケーションを含む。1つの実施形態群は、いわゆる非拡張レンダリングコンテキストを使って、複数のOSによるコンピューティング環境間の同時ユーザインタフェースをサポートするための技術を提供する。別の実施形態群は、いわゆる拡張レンダリングコンテキストを使って、複数のOSによるコンピューティング環境間の同時ユーザインタフェースをサポートするための技術を提供する。また別の実施形態群は、いわゆるミラーリングされたコンテキストを使って、複数のOSによるコンピューティング環境間の同時ユーザインタフェースをサポートするための技術を提供する。さらに別の実施形態群は、第二のOSのユーザ操作空間から第一のOS上で利用可能なアプリケーションにアクセスできるようにする。これらの実施形態群の各々を、以下により詳しく説明する。前述のように、コンピューティング環境100は、複数のオペレーティングシステムを同時に実行しているモバイルデバイスに関連する複数のユーザ操作空間を通じて、複数のユーザコンピューティング体験を提供する。具体的には、モバイルコンピューティングデバイス110が、各々特定のコンピューティング環境に適した複数のOSを含んでいるため、モバイルコンピューティングデバイス110を、1つのモバイルコンピューティングデバイスで様々なユーザ体験を提供するための外部I/Oデバイスに適合させてもよい。例えば、ユーザは、モバイルコンピューティングデバイス110と、キーボード、ディスプレイ及び/またはポインティングデバイスをラップトップ型筐体の中に有する第二の端末環境140を有し得る。モバイルコンピューティングデバイス110がこのラップトップ型の第二の端末環境にドッキングされると、デスクトップOS160のすべての機能が第二の端末環境140を通じて利用可能となる。図2は、各種の実施形態による、モバイルコンピューティングデバイス110のためのハードウェアシステムアーキテクチャの一例を示す。モバイルコンピューティングデバイスハードウェア112は、1つまたは複数のCPUコア204と外部ディスプレイインタフェース220を内蔵するモバイルプロセッサ114を含む。通常、モバイルコンピューティングデバイスハードウェア112はまた、I/Oデバイス118、メモリ206、記憶デバイス208、タッチスクリーンディスプレイ116に接続されたタッチスクリーンディスプレイコントローラ210、バッテリ216に接続された電源管理IC214、セルラーモデム218、通信デバイス222及び/または、各種の通信信号やインタフェースを通じてプロセッサ114に接続されたその他のデバイス224を含む。I/Oデバイス118は通常、ボタン及び、モバイルコンピューティングデバイス110で使用可能なその他のユーザインタフェースコンポーネントを含む。例えば、I/Oデバイス118は、1組のボタン例えば、後退、メニュー、ホーム、検索等、オフスクリーンジェスチャエリア、クリックホイール、スクロールホイール、QWERTYキーボード等を含んでいてもよい。その他のデバイス224は、例えばGPSデバイス、LAN接続、マイクロフォン、スピーカ、カメラ、加速度計及び/またはMS/MMC/SD/SDIOカードインタフェース等であってもよい。外部ディスプレイインタフェース220は、何れの適当なディスプレイインタフェース例えば、VGA、DVI、HDMI等であってもよい。プロセッサ114は、ARMベースのモバイルプロセッサであってもよい。実施形態では、モバイルプロセッサ114は、TexasInstrumentsOMAP3430、MarvellPXA320、FreescaleiMX51、またはQualcommQSD8650/8250等のモバイルARMベースプロセッサである。しかしながら、モバイルプロセッサ114は、他の好適なARMベースのモバイルプロセッサや、別のプロセッサアーキテクチャ、例えばx86ベースのプロセッサアーキテクチャまたはその他のRISCベースのプロセッサアーキテクチャ等に基づくプロセッサであってもよい。図2はモバイルコンピューティングデバイス110の1つの例示的なハードウェア実装112を示しているが、これ以外のアーキテクチャも本発明の範囲内として考えられる。例えば、図2ではモバイルプロセッサ114の外部に示されている各種のコンポーネントは、モバイルプロセッサ114の中に統合してもよい。任意選択的には、図2にモバイルプロセッサ114に統合された状態で示されている外部ディスプレイインタフェース220は、モバイルプロセッサ114の外にあってもよい。これに加えて、システムバス、ディスクリートグラフィクスプロセッサ及び/またはその他のアーキテクチャ面の変化形を使用する、他のコンピュータアーキテクチャも、本発明の態様を利用するのに適している。図3は、各種の実施形態による、モバイルコンピュータデバイス110でモバイルOS130とデスクトップOS160を同時に実行するために利用可能なOSアーキテクチャ300を示す。図3に示されるように、モバイルOS130とデスクトップOS160は、独立したオペレーティングシステムである。具体的には、モバイルOS130とデスクトップOS160は、相互に独立した、非互換的なユーザライブラリ、グラフィクスシステム及び/またはフレームワーク層を有していてもよい。OSアーキテクチャ300のための機能と命令は、モバイルコンピューティングデバイス110の有形のコンピュータ読取可能媒体上にコンピュータプログラムコードとして記憶されていてもよい。例えば、OSアーキテクチャ300のための命令は、モバイルコンピューティングデバイスハードウェア112の記憶デバイス208の中に記憶されていてもよい。OSアーキテクチャ300において、モバイルOS130とデスクトップOS160は、共有カーネル320で同時に動作する。これは、モバイルOS130とデスクトップOS160が共有カーネル320上で同じ時点で動作中であることを意味する。具体的には、モバイルOS130とデスクトップOS160はどちらも、同じカーネルインタフェース322を通じて、例えば共有カーネル320にシステムコールを行うことによって、共有カーネル320とインタフェースする。共有カーネル320は、モバイルOS130とデスクトップOS160の両方のプロセスに関するタスクスケジューリングを管理する。この点で、モバイルOS130とデスクトップOS160は、共有カーネル320で独立して、同時に動作中である。これに加えて、共有カーネル320は、ハードウェアインタフェース312により示されているように、直接、モバイルコンピューティングデバイスハードウェア112のモバイルプロセッサ114で動作する。具体的には、共有カーネル320はモバイルコンピューティングデバイスハードウェア112のコンピューティングリソース、例えばCPUスケジューリング、メモリアクセス、I/Oを直接管理する。この点で、ハードウェアリソースは仮想化されず、すなわち、モバイルOS130とデスクトップOS160は、仮想化されたメモリまたはI/Oアクセスを使用せずに、カーネルインタフェース322を通じてシステムコールを行う。図3に示されるように、モバイルOS130は、ライブラリ層330、アプリケーションフレームワーク層340、アプリケーション層350を有する。モバイルOS130では、アプリケーション352と354が、モバイルOS130のアプリケーションフレームワーク層340によってサポートされるアプリケーション層350の中で動作する。アプリケーションフレームワーク層340には、モバイルOS130上で動作するアプリケーションにより使用されるマネージャ342とサービス344が含まれる。例えば、アプリケーションフレームワーク層340には、ウィンドウマネージャ、アクティビティマネージャ、パッケージマネージャ、リソースマネージャ、電話マネージャ、ジェスチャコントローラ及び/または、モバイル環境のためのその他のマネージャとサービスが含まれていてもよい。アプリケーションフレームワーク層340には、モバイルOS130のために開発されたアプリケーションを実行するモバイルアプリケーションランタイム環境が含まれていてもよい。モバイルアプリケーションランタイム環境は、より低い処理能力及び/または限られたメモリスペース等、モバイルコンピューティングリソースに合わせて最適化されていてもよい。モバイルアプリケーションランタイム環境では、プロセス分離、メモリ管理、スレッディングサポートがカーネルに依存して行われてもよい。ライブラリ層330には、I/Oとストリング操作等の一般的な機能、グラフィクス機能、データベース能力、通信能力及び/またはその他の機能や能力を実行するユーザライブラリ332が含まれる。図3に示されているように、デスクトップOS160は、ライブラリ層360、フレームワーク層370、アプリケーション層380を有する。デスクトップOS160では、アプリケーション382と384が、デスクトップOS160のアプリケーションフレームワーク層370によってサポートされるアプリケーション層380の中で動作する。アプリケーションフレームワーク層370には、デスクトップOS160上で動作するアプリケーションにより使用されるマネージャ372とサービス374が含まれる。例えば、アプリケーションフレームワーク層370には、ウィンドウマネージャ、アクティビティマージャ、パッケージマネージャ、リソースマネージャ及び/または、デスクトップ環境に一般的なその他のマネージャとサービスが含まれていてもよい。ライブラリ層360には、I/Oとストリング操作等の一般的な機能、グラフィクス機能、データベース能力、通信能力及び/またはその他の機能や能力を実行するユーザライブラリ362が含まれていてもよい。本発明の各種の実施形態において、デスクトップOS160は、モバイルOS130とは別の実行環境で動作する。例えば、モバイルOS130はルート実行環境で動作してもよく、デスクトップOS160は、ルート実行環境下で確立された第二の実行環境で動作してもよい。モバイルOS130上で動作するプロセスとアプリケーションは、ルート実行環境の中でユーザライブラリ332、マネージャ342及びサービス344にアクセスする。デスクトップOS160上で動作するプロセスとアプリケーションは、第二の実行環境の中で、ユーザライブラリ362、マネージャ372及びサービス374にアクセスする。実施形態では、モバイルOS130とデスクトップ160は、非互換性のユーザライブラリ、グラフィクスシステム及び/またはアプリケーションフレームワークを有する独立したオペレーティングシステムである。従って、モバイルOS130のために開発されたアプリケーションは、直接、デスクトップOS160では動作できず、デスクトップOS160のために開発されたアプリケーションは、直接、モバイルOS130上では動作できない。例えば、モバイルOS130のアプリケーション層350で動作するアプリケーション352は、デスクトップOS160と非互換的であってもよく、すなわち、アプリーション352をデスクトップOS160で実行できない。具体的には、アプリケーション352は、デスクトップOS160のマネージャ372、サービス374及び/またはライブラリ362では利用できない、またはこれらと互換性のないモバイルOS130のマネージャ342、サービス344及び/またはライブラリ332に依存していてもよい。その結果、モバイルOS130とデスクトップOS160で利用できるアプリケーションの集合はそれぞれ異なっていてもよい。この点で、OSアーキテクチャ300のモバイルOS130とデスクトップOS160は、別々のユーザ操作空間からアクセス可能な別々のアプリケーション集合を通じて、別々のユーザ体験を提供する。ユーザは、モバイルOS130に関連する第一のユーザ操作空間を通じて、モバイルOS130上で利用可能なすなわち、そのためにコンパイルされ、その実行環境内にロードされたアプリケーションにアクセスし、デスクトップOS160に関連する第二のユーザ操作空間を通じて、デスクトップOS160上で利用可能なアプリケーションにアクセスしてもよい。前述のように、モバイルオペレーティングシステムは一般に、デスクトップオペレーティングシステムと同じグラフィクス環境を使用しない。デスクトップOS用のグラフィクス環境は、フレキシビリティと高性能性のために設計された。例えば、一部のデスクトップOSで使用されるXウィンドウシステムは、処理及びシステムリソースをより多く使用することと引き換えに、プラットフォームとネットワークの独立性を提供する。これに対して、モバイルOS用のグラフィクス環境の設計は、効率性とモバイルコンピューティング環境の特定のユーザ入力デバイスのほうにより重点を置き、フレキシビリティはそれより軽視されている。モバイル及びデスクトップOSのグラフィクス環境は異なることが多いため、モバイルOS上で動作するアプリケーションは、モバイルOSのグラフィクスサーバからデスクトップOSのグラフィクスサーバにグラフィクス情報をリダイレクトすることによって、デスクトップOSのユーザ空間内で表示されるようにリダイレクトできない。最も広く採用されているモバイルOSはGoogleのAndroidである。AndroidはLinuxに基づいているが、モバイル環境とモバイルプロセッサのために、カーネル及びその他のOS層に変更が加えられている。特に、LinuxカーネルはPCすなわち、x86CPUアーキテクチャ用に設計されているが、AndroidカーネルはARMベースのモバイルプロセッサに合わせて変更されている。Androidデバイスドライバはまた、タッチスクリーン、モバイル接続GSM/EDGE、CDMA、Wi-Fi等、バッテリ管理、GPS、加速度計及びカメラモジュール等、モバイルハードウェアアーキテクチャの中に一般的にあるデバイスやその他のデバイスに特に合わせて作られている。これに加えて、AndroidはネイティブのXWindowSystemを持っていなければ、フルセットの標準GNUライブラリもサポートしておらず、これによって、既存のGNU/LinuxアプリケーションまたはライブラリをAndroidにポートすることが難しい。AppleのiOSオペレーティングシステムiPhoneで動作とMicrosoftのWindowsPhone7も同様に、モバイル環境とモバイルハードウェアアーキテクチャ用に変更されている。例えば、iOSはMacOSXデスクトップOSから派生しているが、一般的なMacOSX用アプリケーションは、iOS上ではネイティブとして動作しない。具体的には、iOS用アプリケーションは、標準開発キットSDKを通じて、iOSのCocoaTouchランタイム環境で動作するように開発されており、これによってタッチベースの入力、プッシュ通知及びシステムサービス等の重要なiOS機能のための基本的なアプリケーションインフラストラクチャとサポートが提供される。そのため、MacOSXのために書かれたアプリケーションは、ポートしないとiOSで動作しない。これに加えて、MacOSX用アプリケーションをiOSにポートすることは、2つのOS間のユーザライブラリ及び/またはアプリケーションフレームワークの違い、及び/またはモバイルとデスクトップハードウェアのシステムリソースの違いによって、難しいかもしれない。OSアーキテクチャ300に適合する1つの実施形態において、AndroidモバイルOSとフルLinuxOSは、変更されたAndroidカーネル上で独立して、同時に動作する。この実施形態では、AndroidOSは変更型Androidディストリビューションであってもよく、その一方で、LinuxOSHydroidは変更型DebianLinuxデスクトップOSであってもよい。図4~6は、各種の実施形態による、OSアーキテクチャ300で使用可能なAndroidモバイルOS430、Androidカーネル520、HydroidOS660をより詳細に示す。図4に示されるように、AndroidOS430は、ライブラリ層432の中にC/Cライブラリの集合を含み、これらはアプリケーションフレームワーク層440を通じてアクセスされる。ライブラリ層432には、glibcLinuxCライブラリより小型で高速となるようにAndroidのために特に開発されたbionicシステムCライブラリ439が含まれる。ライブラリ層432にはまた、プロセス間通信IPCライブラリ436が含まれ、これにはAndroidOSのBinderIPCメカニズムの基本クラスが含まれる。Binderは特にAndroidのために、プロセス間及びサービス間の通信を可能にするために開発された。図4のライブラリ層432に示されている他のライブラリとしては、媒体フォーマットの記録と再生をサポートするメディアライブラリ435、ディスプレイサブシステムへのアクセスを管理し、複数のアプリケーションからのグラフィクス層を合成するサーフェスマネージャ434、2D及び3Dグラフィクスエンジン438、軽量リレーショナルデータベースエンジン437がある。ライブラリ層432に含めることができるが、図4には示されていないその他のライブラリには、ビットマップ及びベクトルフォントレンダリングライブラリ、ユーティリティライブラリ、ブラウザツールすなわち、WebKit等及び/または秘匿通信ライブラリすなわち、SSL等がある。AndroidOS430のアプリケーションフレームワーク層440は、開発者がデバイスハードウェアのコンポーネントを使用し、位置情報にアクセスし、背景サービスを実行し、アラームをセットし、ステイタスバーに通知を加えること等を可能にする開発プラットフォームを提供する。フレームワーク層440により、アプリケーションがその能力を公開し、他のアプリケーションの公開された能力を利用することも可能となる。AndoroidモバイルOS430のアプリケーションフレームワーク層440のコンポーネントは、アクティビティマネージャ441、リソースマネージャ442、ウィンドウマネージャ443、ドックマネージャ444、ハードウェア及びシステムサービス445、デスクトップモニタサービス446、マルチディスプレイマネージャ447及びリモート通信サービス448を含む。AndroidモバイルOS430のフレームワーク層440に含めることのできるその他のコンポーネントには、ビューシステム、電話マネージャ、パッケージマネージャ、位置マネージャ及び/または通知マネージャのほか、その他のマネージャとサービスがある。AndroidOS430で動作するアプリケーションは、Androidオブジェクト指向アプリケーションフレームワークの上のAndroidランタイム環境433のDalvik仮想マシン431の中で動作する。Dalvik仮想マシン431はレジスタベースの仮想マシンであり、メモリ使用量と処理要求を削減するために設計されたコンパクトな実行可能フォーマットを実行する。AndroidOS430で動作するアプリケーションには、ホーム画面451、電子メールアプリーション452、写真アプリケーション453、ブラウザアプリケーション454、及び/またはその他のアプリケーションアプリ455がある。AndroidOSグラフィクスシステムは、クライアント/サーバモデルを使用する。サーフェスマネージャSurfaceFlingerはグラフィクスサーバであり、アプリケーションはクライアントである。SurfaceFlingerは、ディスプレイIDのリストを維持し、ディスプレイIDへのアプリケーションの割当を常に追跡する。1つの実施形態では、モバイルコンピューティングデバイス110は複数のタッチスクリーンディスプレイ116を有する。この実施形態において、ディスプレイID0がタッチスクリーンディスプレイ116の1つに関連付けられ、ディスプレイID1が他方のタッチスクリーンディスプレイ116に関連付けられる。ディスプレイID2は両方のタッチスクリーンディスプレイ116に関連付けられるすなわち、このアプリケーションが両方のディスプレイで同時に表示される。2より大きいディスプレイIDは仮想ディスプレイであり、すなわち、これらはモバイルコンピューティングデバイスハードウェア112の上に物理的に存在するディスプレイには関連付けられない。Androidアプリケーション用のグラフィクス情報には、ウィンドウ、ビュー、及びキャンバスがある。各ウィンドウ、ビュー及び/またはキャンバスには、基本となるサーフェスオブジェクトが含められる。サーフェスオブジェクトは、2つのバッファフロント及びバックバッファに格納され、描画のためのプロセス間で同期される。SurfaceFlingerは、すべてのサーフェスを共通のメモリプールの中に維持し、これによって、Android内のすべてのプロセスがこれらにアクセスし、その中に描画することができ、コストのかかるコピー動作が不要となり、またXウィンドウ等のサーバ側の描画プロトコルを使用する必要もない。アプリケーションは、SurfaceFlingerがフロントバッファから読み出している間は常にバックバッファの中に描画する。SurfaceFlingerは、各サーフェスオブジェクトを作成し、すべてのサーフェスオブジェクトを維持し、また、各アプリケーションに関するサーフェスオブジェクトリストを維持する。アプリケーションは、バックバッファへの描画を完了すると、SurfaceFlingerにイベントをポストし、これがバックバッファをフロントバッファにスワップして、サーフェス情報をフレームバッファにレンダリングする作業を待ち行列に入れる。SurfaceFlingerは、すべてのウィンドウ変更イベントをモニタする。1つまたは複数のウィンドウ変更イベントが発生すると、SurfaceFlingerはサーフェス情報を1つまたは複数のディスプレイのためのフレームバッファにレンダリングする。レンダリングには、サーフェスを合成すること、すなわちサーフェスの寸法、透明度、Zオーダ、可視性に基づいて最終的な画像フレームを構成することが含まれる。レンダリングはまた、ハードウェア加速例えば、グラフィクス処理ハードウェアのためのOpenGL2D及び/または3Dインタフェースを含んでいてもよい。SurfaceFlingerは、すべてのサーフェスオブジェクトをループさせて、それらのフロントバッファをそのZオーダでフレームバッファにレンダリングする。図5は、各種の実施形態による変更型Androidカーネル520をより詳しく示す。変更型Androidカーネル520には、タッチスクリーンディスプレイドライバ521、カメラドライバ522、Bluetoothドライバ523、共有メモリアロケータ524、IPCドライバ525、USBドライバ526、WiFiドライバ527、I/Oデバイスドライバ528及び/または電源管理モジュール530が含まれる。I/Oデバイスドライバ528には、ポート120を通じてモバイルコンピューティングデバイス110に接続可能な外部I/Oデバイスのためのデバイスドライバが含まれる。変更型Androidカーネル520には、lowmemorykiller、カーネルデバッガ、ログ機能及び/またはその他のハードウェアデバイスドライバを含むその他のドライバや機能ブロックが含まれていてもよい。図6は、各種の実施形態によるHydroidOS660をより詳しく示す。HydroidはフルLinuxOSであり、標準的なLinuxディストリビューション用に開発されたほとんどすべてのアプリケーションを実行できる。特に、HydroidOS660のライブラリ層662には、ネットワーキング、グラフィクス処理、データベース管理及びその他の一般的なプログラム機能をサポートするLinuxライブラリが含まれる。例えば、ユーザライブラリ662には、glibcLinuxCライブラリ664、Linuxグラフィクスライブラリ662例えば、GTK、OpenGL等、Linuxユーティリティライブラリ661、Linuxデータベースライブラリ、及び/またはその他のLinuxユーザライブラリが含まれていてもよい。アプリケーションは、Hydroid上では、Xサーバ674、ウィンドウマネージャ673及び/またはデスクトップ環境672を用いてXWindowLinuxグラフィカル環境内で動作する。図のアプリケーションには、ワードプロセッサ681、電子メールアプリケーション682、スプレッドシートアプリケーション683、ブラウザ684及びその他のアプリケーション685が含まれている。LinuxOSグラフィクスシステムは、XウィンドウまたはX11グラフィクスシステムに基づいている。Xウィンドウは、プラットフォームに依存しないネットワーク式のグラフフィクスフレームワークである。Xウィンドウはクライアント/サーバモデルを利用しており、Xサーバがグラフィクスサーバ、アプリケーションがクライアントである。Xサーバは、ディスプレイ、タッチスクリーンディスプレイ、キーボード、ポインティングデバイス等、LinuxOSに関連する入力/出力ハードウェアを制御する。この点で、Xウィンドウはサーバ側の描画グラフィクスアーキテクチャを提供し、すなわち、Xサーバがウィンドウやピクセルマップを含むDrawableのためのコンテンツを維持する。XクライアントはXサーバと、通信チャネル上で描画動作を説明するデータパケットを交換することによって通信する。Xクライアントは、標準ルーチンのライブラリXlibを通じてX通信プロトコルにアクセスする。例えば、XクライアントはXサーバに対し、クライアントウィンドウに三角形を描画するように要求を送信してもよい。XサーバはXクライアントに入力イベント、例えばキーボードまたはポインティングデバイスの入力、及び/またはウィンドウの移動またはリサイジングを送信する。入力イベントはクライアントウィンドウに関連しており、例えば、ユーザがあるウィンドウ内にあるポインタをクリックすると、Xサーバはその入力イベントを含むパケットを、そのウィンドウに関連するXクライアントに送り、その中にはそのウィンドウに関係のあるイベントの動作と位置が含まれる。オペレーティングシステムのフレームワーク、グラフィクスシステム及び/またはライブラリの違いによって、Android用に書かれたアプリケーションは通常、HydroidOS660では動作せず、標準的なLinuxディストリビューション用に書かれたアプリケーションは通常、AndroidOS430では動作しない。この点に関して、AndroidOS430とHydroidOS660のためのアプリケーションにはバイトコード互換性がなく、すなわち、一方のためにコンパイルされた実行可能なプログラムは、他方では動作しない。1つの実施形態において、HydroidOS660は、共有カーネル520を通じてAndroidOS430との通信を容易にする異環境間通信フレームワークのコンポーネントを含む。これらのコンポーネントとしては、AndroidOSのBinderIPCメカニズムのための基本クラスと遠隔通信サービス671を含むIPCライブラリ663がある。1つの実施形態において、HydroidOS660は、Androidルート環境内で作られた、chrootされたchrootコマンドで作られた第二の実行環境の中で実行される。HydroidOS660の中のプロセスとアプリケーションは、第二の実行環境の中で、これらのプロセスとアプリケーションから見た見かけ上のルートディレクトリが第二の実行環境のルートディレクトリとなるように実行される。このようにして、HydroidOS660は、標準Linuxディストリビューションのために書かれたプログラムを変更せずに実行でき、それは、chrootされた第二の実行環境においてHydroidOS660上で実行されるプロセスにLinuxユーザライブラリ662を利用できるからである。図3に戻ると、モバイルOS130とデスクトップ160は、モバイルデバイスの共有カーネル320上でアクティブに同時動作中である。モバイルOS130とデスクトップOS160は、ユーザライブラリ、グラフィクスシステム及び/またはアプリケーションフレームワークに関して非互換的であってもよい。そのため、モバイルOS130とデスクトップOS160で利用可能なアプリケーションの集合はそれぞれ異なり、すなわち、モバイルOS130上で利用可能な少なくとも一部のアプリケーションはデスクトップOS160では利用できず、またその逆でもある。従って、OSアーキテクチャ300のモバイルOS130とデスクトップOS160は、別々のユーザ操作空間からアクセス可能な別々のアプリケーション集合を通じて、別々のユーザ体験を提供する。ユーザは、モバイルOS130に関連するユーザ操作空間を通じてモバイルOS130上で利用可能なすなわち、そのためにコンパイルされ、その実行環境内にロードされたアプリケーションにアクセスし、デスクトップOS160に関連するユーザ操作空間を通じてデスクトップOS160上で利用可能なアプリケーションにアクセスしてもよい。本発明の実施形態は、OSアーキテクチャ300の機能性を拡張して、複数のOSに基づくコンピューティング環境における、よりシームレスなコンピューティング体験を提供する。実施形態には、第二のオペレーティングシステムのユーザ操作空間内におけるアプリケーション及び/または第一のオペレーティングシステムのユーザ操作空間の異環境間レンダリングが含まれ、これは第一と第二のオペレーティングシステムのグラフィクス環境に互換性がなくても行われる。実施形態にはさらに、異環境間アプリケーションのためのユーザ操作のサポートと、第二のオペレーティングシステムのユーザ操作空間からの第一のオペレーティングシステムのアプリケーションへのアクセスが含まれる。この機能によって、例えば、モバイルOS130上で動作するモバイルOS用アプリケーションを、デスクトップOS160に関連するユーザ操作空間を通じて表示し、操作することが可能となる。例えば、ユーザがデスクトップOS160に関連するユーザ操作空間を通じてデスクトップOS160を操作している間に、そのユーザは、デスクトップOS160では利用できないすなわち、そのためにコンパイルされておらず、そこでは実行されないモバイルOS130の特定のアプリケーションにアクセスしたいと希望してもよい。後述の各種の実施形態を用いれば、ユーザは、デスクトップOS160に関連するユーザ操作空間を通じて、モバイルOS130のためにコンパイルされ、その上で実行されるアプリケーションにアクセスし、これを表示し、操作できる。特に、実施形態は、モバイルOSの何れのアプリケーションでの異環境間操作もサポートしており、すなわち、モバイルOS用アプリケーションを下記の実施形態を使用するのに、特定の異環境間サポートを含めるように変更する必要がない。第二のOS例えば、デスクトップOS160のユーザ操作空間内からアプリケーション及び/または第一のOS例えば、モバイルOS130のユーザ操作空間への、シームレスな異環境間ユーザ操作をサポートするために、アプリケーション及び/またはユーザ操作空間のグラフィクスデータすなわち、グラフィクスコンテキストまたはアクティブディスプレイを、第二のOSのユーザ操作空間の中にリアルタイムで表示されるようにレンダリングすることが望ましいかもしれない。リアルタイムまたは即時レンダリングとは、この文脈において、アプリケーションのグラフィクスデータが第二のOSのユーザ操作空間に十分に素早くレンダリングされ、グラフィクス情報の伝送に伴う遅延によってアプリケーションのパフォーマンスに気付くほどの、または実質的な低下を発生させずに、ユーザがそのアプリケーションを操作できることを意味する。この点に関して、本明細書に記載されているようなリアルタイムまたは即時異環境間レンダリングの技術により、例えばグラフィクス情報が迅速に転送され、第一のOSから第二のOSにグラフィクス情報をコピーまたは転送することに伴うフレーム遅延やその他の遅延が減る。しかしながら、これはグラフィクスの転送にまったく時間がかからないことを意味するのではなく、本明細書に記載の異環境間レンダリング方式は、グラフィクス情報が第二のOSのユーザ操作空間上で表示されるまでに限定的な時間がかかったとしても、即時またはリアルタイムとみなしてよい。アプリケーションの異環境間レンダリングを実現するために、第一のオペレーティングシステムで動作中のアプリケーションから第二のオペレーティングシステムのグラフィクスシステムに、おそらく大量のグラフィクスデータが転送されることがある。既存のメカニズムでは、必要なグラフィクスデータを転送すると、ディスプレイの更新またはフレームレートに必ず影響が及ぶ。例えば、グラフィクスデータを直接転送することは、モバイルコンピューティング環境の制約の中では現実的ではないであろう。圧縮技術を使って転送データの総量を減らすことは可能であるが、その代わりに、情報の圧縮と解凍に必要な処理が増える。リモートのデスクトップ型システムを使って、ベクトルグラフィクスやグラフィクス更新情報を送ることはできるが、この場合もまた一般に、大量のグラフィクスデータを転送する際、またはグラフィクスコンテンツの急速な変化の際に速度が低下する。図7は各種の実施形態によるOSアーキテクチャ構成300aを示し、これは第二のOSのユーザ操作空間内でアプリケーション及び/または第一のOSのユーザ操作空間を異環境間レンダリングするために使用でき、この場合、第一と第二のOSは共有カーネル上で同時動作中であり、別々のディスプレイデバイスを含む別々のユーザ操作空間に関連付けられている。OSアーキテクチャ構成300aのコンポーネントにより、モバイルOS130上で動作するアプリケーションとモバイルOS130のグラフィクスコンテキストを、デスクトップOS160のユーザ操作空間内にレンダリングすることができ、OS130とデスクトップOS160は共有カーネル320上で同時動作する。各種の実施形態において、アプリケーションは、デスクトップOS160のコンソールアプリケーション782を通じて、デスクトップOS160のユーザ操作空間内のコンソールウィンドウに表示される。1つの実施形態において、コンソールアプリケーション782は、Xウィンドウ型アプリケーションであり、これはデスクトップOS160のXウィンドウ型グラフィクスシステムを通じてデスクトップOS160のユーザ操作空間内に表示される。OSアーキテクチャ構成300aにおいて、モバイルOS130には、グラフィクスサーバ734が含まれ、これはモバイルOS130のアプリケーション例えば、アプリケーション752と754に関するサーフェス情報例えば、サーフェス726、727、728の割当と管理を行う。1つの実施形態において、グラフィクスサーバ734は、匿名共有メモリすなわち、そのカーネルを解放できるプロセス間で共有される名前付きメモリブロックを使ってグラフィクスサーフェスのメモリを割り当てる。グラフィクスサーバ734はまた、モバイルOS130のディスプレイの割当と追跡も行い、これにはモバイルコンピューティングデバイスハードウェア112すなわち、ローカルディスプレイに内蔵されるディスプレイと、モバイルOS130が遠隔的にすなわち、他のOSのユーザ操作空間内で表示されるかもしない、いわゆる仮想ディスプレイが含まれる。モバイルOS130はまた、モバイルOS130に関連するディスプレイ画面上に同時に複数のアプリケーションを表示するためのウィンドウシステムを含んでいてもよい。1つの実施形態において、モバイルOS130には、デスクトップOS160からモバイルOS130のコンポーネントにアクセスするための遠隔通信チャネルを提供するサービスが含まれる。OSアーキテクチャ構成300aには、モバイルOS130上で動作中であり、モバイルOS130に関連する第一のユーザ操作空間内に表示される第一のアプリケーション752が含まれる。OSアーキテクチャ構成300aには、やはりモバイルOS130上で動作中であるが、後述の実施形態による異環境間レンダリングを通じて、デスクトップOS160に関連する第二のユーザ操作空間内に表示される第二のアプリケーション754が含まれる。1つの実施形態において、アプリケーション754は、デスクトップOS160上で動作するコンソールアプリケーション782を通じて第二のユーザ操作空間のコンソールウィンドウ内に表示される。通常、モバイルOS130のアプリケーションは、ユーザがアプリケーションを操作する際に使用するビューのインスタンスを作成する。例えば、アプリケーションは、アプリケーションウィンドウを構成する1つのビューを有し得る。ビューの中で、アプリケーションは、アプリケーションインタフェースの特定の領域に関する描画オブジェクトのインスタンスを作る。描画オブジェクトは、キャンバスまたは描画層と呼ばれることがあり、アプリケーションがグラフィクス情報を描画する際に使用するオブジェクトである。アプリケーションがキャンバスまたは層のインスタンスを作成すると、グラフィクスサーバ734がそのキャンバスまたは層に関連するサーフェス情報にメモリを割り当て、その描画オブジェクトをアプリケーションに戻し、すると、アプリケーションがこれを使ってキャンバスまたは層のサーフェスに関するグラフィクス情報を描画する。その後、グラフィクスサーバ734はサーフェス情報をモニタし、サーフェス情報が更新されると、このサーフェス情報をフレームバッファ例えば、フレームバッファ716にレンダリングする。一般に、ユーザはまた、ビューオブジェクトを通じてアプリケーションを操作する。ビューンオブジェクトはイベントリスナを含み、これは、ユーザがそのビューオブジェクトに対して動作を起こした際に、モバイルOSの入力待ち行列736によりコールされる。OSアーキテクチャ300aに示されているように、サーフェス726、727及び/または728は、グラフィクスサーバ734によって共有メモリ724に割り当てられる。共有メモリ724は、共有カーネル320によって管理され、モバイルOS130とデスクトップOS160上で動作中のすべてのプロセスによりアクセス可能である。前述のように、共有メモリ724は名前付き共有メモリであってもよい。名前付き共有メモリは、共有カーネル320上で動作中のすべてのプロセスによってアクセス可能であるが、それ以外のプロセスは名前によって名前付き共有メモリの領域にアクセスすることができない。従って、名前付き共有メモリの各領域に関するファイル記述子を、プロセス間通信メカニズムを通じて送り、プロセスの境界を越えて名前付き共有メモリを参照できるようにしなければならない。共有カーネル320にはまた、IPCドライバ725が含まれ、これによって、モバイルOS130とデスクトップOS160の中のプロセスはプロセスの境界を越えて相互に通信できる。IPCドライバ725は、例えば、Unixドメインソケットドライバ、AndroidBinderドライバ、及び/またはネットワークソケットドライバであってもよい。OSアーキテクチャ構成300aのデスクトップOS160には、コンソールアプリケーション782とウィンドウシステム774が含まれる。コンソールアプリケーション782は、デスクトップOS160のためにコンパイルされ、その上で動作し、デスクトップOS160に関連するユーザ操作空間のコンソールウィンドウの中に表示される。ウィンドウシステム774には、ウィンドウマネージャ、グラフィクスサーバ及び/または、グラフィクスオブジェクトを表現し、デスクトップOSフレームバッファ718を通じてこれらをディスプレイデバイスに転送するための基盤となるグラフィクスデバイスインタフェースが含まれる。例えば、ウィンドウシステム774は、デスクトップOSフレームバッファ718を通じて、デスクトップOS160のユーザ操作空間内にコンソールアプリケーション782を表示してもよい。ウィンドウシステム774はまた、コンソールアプリケーション782に関連するデスクトップOS160のユーザ環境からの入力イベントをコンソールアプリケーション782に提供する。例えば、ウィンドウシステム774は、デスクトップOS160に関連するユーザ操作空間からのポインティングデバイスの位置またはジェスチャ情報をコンソールアプリケーション782に提供してもよい。図7において、共有メモリ724、モバイルOSフレームバッファ716、デスクトップOSフレームバッファ718を含むメモリブロックが、わかりやすいように、共有カーネル320の中にあるように示されている。しかしながら、これらのメモリブロックは、モバイルコンピュータデバイス110の有形のメモリ要素の中に物理的に設置され、共有カーネル320によって管理される。例えば、これらのメモリブロックは、図2に示されるように、プロセッサ114のRAMの中、及び/またはモバイルコンピューティングデバイスハードウェア112のメモリデバイス206のRAMの中に設置されてもよい。OSアーキテクチャ構成300aは、第二のオペレーティングシステムに関連するユーザ操作空間内に共有カーネル上で動作中の第一のオペレーティングシステムのアプリケーションを異環境間レンダリングすることをサポートし、この場合、第一と第二のオペレーティングシステムは共有カーネル上で同時動作中である。OSアーキテクチャ構成300aは、複数のユーザ操作空間を通じて複数のユーザコンピューティング体験を提供するコンピューティング環境における異環境間レンダリングをサポートするために使用してもよい。例えば、OSアーキテクチャ構成300aは、図1に示されるようなコンピューティング環境100の中で使用してもよい。図8は、各種の実施形態によるコンピューティング環境800を示す。コンピューティング環境800は、モバイルコンピューティングデバイスハードウェア112のタッチスクリーンディスプレイ116とその他のI/Oデバイス118を含む第一のユーザ環境を有する。このユーザ環境は第一のユーザ操作空間を提供し、ユーザはここからモバイルOS130を操作する。コンピューティング環境800の第二のユーザ環境は、ディスプレイモニタ844、キーボード846及び/またはポインティングデバイス848を含む。ユーザ環境840は、ドックコネクタ841とドックケーブル843を通じて、モバイルコンピューティングデバイス110に接続されてもよい。ドックコネクタ841とドックケーブル843は、図1に示されるように、ドックインタフェース122を通じてモバイルコンピューティングデバイス110のポート120とインタフェースするポートを含んでいてもよい。この点に関して、ユーザ環境840は、モバイルコンピューティングデバイス110に対して、ドッキングされた第二の端末環境を提供する。コンピューティング環境800において、デスクトップOS160はドッキングされた第二の端末環境840に関連付けられてもよく、これによって、ユーザは第二の端末環境840によって提供されるユーザ操作空間を通じてデスクトップOS160を操作できる。第二の端末環境840は、一般的なデスクトップ型コンピューティング環境として示されているが、デスクトップOS160は、他のタイプのコンピューティング環境、例えばラップトップ、タブレット及び/またはその他のタイプのコンピューティング環境を通じて第二のユーザ操作空間を提供してもよい。OSアーキテクチャ構成300aをコンピューティング環境800で使用して、第一のOSすなわち、モバイルOS上で動作し、第二のOSのユーザ環境すなわち、デスクトップOS160に関連するユーザ環境840の中に表示されるアプリケーションの異環境間レンダリングを提供してもよい。例えば、モバイルOS130上で動作中のアプリケーション754は、デスクトップOS160のユーザ操作空間880のコンソールウィンドウ882の中に表示されてもよい。ウィンドウ884と886を含む、ユーザ操作空間880内のその他のウィンドウは、デスクトップOS160で動作中の他のアプリケーションのウィンドウであってもよい。ユーザに対しては、コンピューティング環境800はアプリケーション754に関するシームレスなコンピューティング体験を提供し、これは、アプリケーション754がデスクトップOS160のユーザ操作空間の中で、実際にはアプリケーション754はモバイルOS130で動作しているが、デスクトップOS160上で実行されているかのように使用できるからである。図8は、デスクトップ型の第二の端末環境840を示している。この例では、ユーザは、第二の端末環境840のキーボード846とマウス848を使うことにより、コンソールウィンドウ882を通じてすなわち、主としてポインティングデバイスに基づくGUI、モバイルOSのアプリケーション及び/またはユーザ操作空間を操作してもよい。しかしながら、アプリケーションの異環境間レンダリング及び/またはモバイルOSユーザ操作空間のミラーリングを、他の第二の端末環境で使用してもよい。例えば、デスクトップOS160は、タッチスクリーンディスプレイを含むタブレット型の第二の端末環境に関連付けることができる。この場合、ユーザは、ユーザが一般的にモバイルOS130のユーザ操作空間を操作するのとほとんど同じ方法ですなわち、主としてジェスチャベースのGUI、モバイルOS130の異環境間アプリケーションまたはミラーリングされたユーザ操作空間を操作してもよい。前述のように、本発明の実施形態は、複数のOSに基づくコンピューティング環境において、異環境間アプリケーション及び/またはミラーリングされたユーザ操作空間のユーザによる同時インタフェースをサポートすることに関する。一例において、ユーザインタフェースのサポートは、異環境間アプリケーションのために提供され、それによって第一のOS上で動作中のアプリケーションを、実質的にもともと第二のオペレーティングシステム上で動作しているかのように、第二のOSのユーザ操作空間を通じて表示し、操作することができる。非拡張レンダリングコンテキストによる実施形態いくつかの実施形態は、第一のオペレーティングシステムのグラフィクスレンダリングコンテキストを拡張せずに、複数のOSにわたる同時ユーザインタフェースをサポートすることに関する。第一のOS例えば、モバイルOSであるAndroidは一般に、単独の、アクティブなユーザ操作空間となるように構成される。このユーザ操作空間には、アクティブディスプレイ例えば、解像度等、関連する特徴を有すると、ユーザがアクティブディスプレイ上で表示される要素を操作できるような1つまたは複数のアクティブ入力デバイスが含まれる。従って、第一のOSは、アクティブディスプレイに表示するために実行されるアプリケーションに関するサーフェス情報をレンダリングする際に使用できるレンダリングコンテキストを作成する。しかしながら、前述のように、本明細書には同時に使用中の複数のユーザ操作空間中に第一のOSを有効にフーリングするための新規の技術が記載される。さらに、この技術によれば、複数のユーザ操作空間を、複数のコンピューティング環境上の異なる例えば、非互換性のオペレーティングシステムに関連付けることが可能となる。いくつかの実施形態には、異環境間リモートレンダリングを通じてディスプレイ出力を処理するための技術が関わる。その他の実施形態は、このような場合のユーザの操作を扱うための技術に関する。異環境間リモートレンダリングにおいて、第一のOS上で動作し、第二のOSに関連するコンピューティング環境内で表示されるアプリケーションに関するアプリケーショングラフィクスは、第二のOS内からレンダリングされる。1つの実施形態において、第二のOS上で動作中のコンソールアプリケーションは、共有メモリからのそのアプリケーションに関するサーフェス情報にアクセスし、第二のOSに関連するコンピューティング環境のコンソールウィンドウ内にこのアプリケーションをレンダリングする。カレンダアアプリケーションとワードプロセシングアプリケーションがどちらもモバイルデバイス上の第一のOS例えば、モバイルOS130用にコンパイルされ、同時動作していると仮定する。第二のOS例えば、デスクトップOS160のようなノンモバイルOSが共有カーネルを使ってモバイルデバイス上で同時に動作している。ユーザは、モバイルデバイスを第二の、デスクトップコンピューティング環境にドッキングしており、このデスクトップコンピューティング環境を通じてワートプロセシングアプリケーションを操作したいと望んでいる。モバイルコンピューティング環境すなわち、モバイルデバイスの第二のOSを使って、デスクトップコンピューティング環境のユーザ操作空間を、ユーザにとってよくわかる方法で扱うことが望ましい。図9は、各種の実施形態による異環境間リモートレンダリングの態様を示す。図9に示されるアプリケーションレンダリングの概略図900において、第一のアプリケーション910例えば、カレンダアプリケーションは第一のOS内の第一のサーフェス912に関する更新を計算する。第一のサーフェス912は、第一のオペレーティングシステムによって共有メモリ空間内の第一のメモリ位置に格納される。例えば、第一のメモリ位置は、名前付きの共有メモリの1領域であってもよい。第一のアプリケーション910は、第一のサーフェス912のバックバッファ914を更新する。同様に、第二のアプリケーション930例えば、ワードプロセシングアプリケーションは、第一のOSを使って、第二のサーフェス932の更新を計算する。第二のサーフェス932は、第一のOSによって共有メモリ空間の第二のメモリ位置例えば、名前付きの共有メモリの第二の領域に格納される。第一のOSは、いつレンダリングシーケンスを開始するか判断する。例えば、第一のOSは、サーフェス912及び/または932に関するサーフェス情報が変更された時にレンダリングシーケンスを開始してもよい。第一のOSは、特定のアプリケーションに関連するサーフェス情報が変化したかどうかを判断し、第一のサーフェス912と第二のサーフェス932を含むすべてのサーフェスについて1ループを実行してもよい。レンダリングシーケンスの中で、サーフェス912に関するサーフェス情報が変化すると、第一のOSはフロントバッファ916とバックバッファ914をスワップして、バックバッファ914の中にあったサーフェス情報が今度はフロントバッファ916にあるようにする。第一のオペレーティングステムは、第一のサーフェス912を第三のメモリ位置920にレンダリングして、第一のOSに関連する第一のユーザ操作空間内で表示されるべき最終画像918を作る。第二のサーフェス932に関するサーフェス情報が変化すると、第一のOSは第二のOSに対し、第二のサーフェス932に関するサーフェス情報が変化したことを通知する。具体的には、第一のOSは第二のOSのコンソールアプリケーションに対し、サーフェス932がアップデートされたことを示す描画通知を、プロセス間通信チャネルを通じて送信する。描画通知は、フロント画像936のファイル記述子及び/またはフロント画像936のための共有メモリ空間に関するその他の特徴、例えばバッファの大きさ、層の順序等を含んでいてもよい。コンソールアプリケーションは、ファイル記述子をそのプロセス空間にマッピングして、第二のメモリ位置の参照を取得する。第二のメモリ位置の参照を通じて、第二のOSのコンソールアプリケーションは、フロント画像バッファ936からサーフェス情報を直接読み出し、第二のサーフェス932のフロント画像936に関するサーフェス情報を、第二のOSに関連する第二のユーザ操作空間内のコンソールウィンドウ940にレンダリングする。このようにして、コンソールアプリケーションは、第二のアプリケーション930をリアルタイムでコンソールウィンドウ940の中にレンダリングすることができ、プロセス間でグラフィクスフレームまたはサーフェス情報をコピーすることは不要となる。その代わりに、コンソールアプリケーションは、プロセス間通信を通じて送られたファイル記述子を使って、第二のサーフェス932の共有メモリをそれ自身のプロセス空間にマッピングすることにより、サーフェス情報を直接読み出す。図10は、各種の実施形態による、非拡張レンダリングコンテキストでの異環境間リモートレンダリングの例示的方法のフロー1000を示す。実施形態では、どちらも第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに同時動作中の第一のアプリケーション例えば、カレンダアプリケーションと第二のアプリケーション例えば、ワードプロセシングアプリケーションのアプリケーショングラフィクスの表示が維持される。方法1000はブロック1004で、第一のオペレーティングシステムを使って第一のアプリケーションのサーフェスの更新を計算することから始まる。サーフェスの更新の計算では、アプリケーションデータを使って、どのサーフェスがどのように変化したかが判断される。例えば、ユーザの操作により、いくつかのサーフェスが位置、順序例えば、1つの層が部分的に他の層の前にあっても、他の層により完全に隠れていても、その他でもよい、大きさ、色、テクスチャ等が変化した可能性がある。ブロック1008で、第一のアプリケーションのこれらの更新後のサーフェスが、第一のオペレーティングシステムを使ってレンダリングされ、第一のメモリ位置に第一のグラフィクスフレームが生成される。例えば、第一のOSのレンダリングエンジンはそれ以前に、ディスプレイに関連するレンダリングコンテキストを作成した。すると、グラフィクスフレームは、更新されたサーフェス情報を繰り返し処理することによってレンダリングし、そのレンダリングコンテキストに関連するディスプレイの特徴例えば、解像度に従って、第一のアプリケーションから見えるサーフェス部分の全体または部分画像が有効に描画される。このグラフィクスフレームは第一のメモリ位置にレンダリングされる。メモリ位置は、フレームバッファメモリ、共有メモリ、またはその他の有益なメモリ位置とすることができる。いくつかの実施形態において、ブロック1012では、レンダリングされた第一のグラフィクスフレームが、第一のメモリ位置から第一のオペレーティングシステムに関連する第一のコンピューティング環境のディスプレイに表示される。例えば、第一のグラフィクスフレームは、モバイルデバイスのフレームバッファのバックバッファ部分にレンダリングされる。その後、フレームバッファが反転しすなわち、バックバッファ部分がフロントバッファ部分となる、フレームバッファの、新たにフロントになったバッファ部分がモバイルデバイスのディスプレイに表示される。ブロック1016で、第一のオペレーティングシステムを使って、第二のアプリケーションのサーフェスの更新が計算される。これは、ブロック1004の第一のアプリケーションのサーフェスに関する計算と実質的に同じように行われてもよい。しかしながら、第一のアプリケーションの更新後のサーフェスデータと異なり、第二のアプリケーションの更新後のサーフェス情報は第一のOSではレンダリングされない。そうではなく、ブロック1020で、第二のアプリケーションの更新後のサーフェスは第二のメモリ位置に格納される。第二のメモリ位置は、モバイルデバイスの共有カーネル上で同時動作中の第一と第二のOSの両方によりアクセス可能な共有メモリ位置である。ブロック1024で、第二のアプリケーションの更新後のサーフェスは、第二のオペレーティングシステムのコンソールアプリケーションを使ってレンダリングされ、第三のメモリ位置の中に第二のグラフィクスフレームが生成される。例えば、図7のコンソールアプリケーション782は、アプリケーション754の更新後のサーフェスを第二のOSのフレームバッファメモリ例えば、第二のコンピューティング環境のディスプレイに関連付けられているにレンダリングしてもよい。いくつかの実施形態において、ブロック1028で、第二のグラフィクスフレームは、第三のメモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティング環境のディスプレイに表示される。例えば、デスクトップコンピューティング環境のディスプレイドライバは、そのフレームバッファメモリにアクセスし、第二のグラフィクスフレームにアクセスしてこれを表示する。特定の実施例においては、コンソールアプリケーションがコンソール操作空間を有し、第二のグラフィクスフレームがコンソール操作空間の中にレンダリングされる。例えば、コンソールアプリケーションは、デスクトップディスプレイ上に1つまたは複数のウィンドウをレンダリングし、第二のアプリケーションのグラフィクスがこれらのウィンドウの1つに表示される。いくつかの実施形態において、方法1000はブロックを繰り返し処理して、両方のアプリケーションのグラフィクス環境を同時に維持する。例えば、モバイルOSは、第一のアプリケーションのグラフィクスの更新を計算して、これらの更新をモバイルフレームバッファメモリにレンダリングする。その後、モバイルOSは第二のアプリケーションのグラフィクスの更新を計算し、これらの更新を共有メモリに格納し、そこから、デスクトップOSのコンソールアプリケーションがこれらの更新をデスクトップのフレームバッファメモリにレンダリングする。その後、方法1000が次の一連の更新について繰り返される。特にいくつかの実施例は、特定のステップを異なる順序で、及び/または並行して行う。例えば、第一と第二のアプリケーションのサーフェスの更新を実質的に同時に計算することも可能であるすなわち、ブロック1004と1016を実質的に並行して行うが、これらの更新後のサーフェスは、一部だけがローカルでレンダリングされ例えば、ブロック1008、更新後のサーフェスの他の部分は、リモートレンダリングのために格納される例えば、ブロック1020と1024。1つの実施形態において、AndroidモバイルOSとフルLinuxOS例えば、Hydroidは、モバイルデバイス上の共有カーネルで同時動作中である。AndroidアプリケーションがHydroidOS660から起動されると、コンソールアプリケーションがHydroidOS660上で起動し、AndroidOS430がAndroidアプリケーションを起動させて、Androidアプリケーションに関する描画通知をコンソールアプリケーションに送信するように要求する。AndoidOS430はAndoroidアプリケーションを起動させ、このアプリケーションを仮想ディスプレイIDに関連付けて、コンソールアプリケーションを登録し、そのアプリケーションに関する描画通知を受け取るようにする。例えば、Androidグラフィクスサーバすなわち、SurfaceFlingerは、使用されていない仮想ディスプレイIDを割り当てて、アプリケーションオブジェクトリストを通じてそのアプリケーションを仮想ディスプレイIDに関連付ける。SurfaceFlingerは、共有メモリの中でAndroidアプリケーションのサーフェス情報のためのメモリを割り当て、コンソールアプリケーションを登録して、Androidアプリケーションに関する描画通知を受け取るようにする。SurfaceFlingerが、サーフェス情報が更新されたと判断すると、SurfaceFlingerはプロセス間通信チャネルを通じてコンソールアプリケーションに描画通知を送信する。例えば、SurfaceFlingerはunixドメインソケット、Binderインタフェース及び/またはネットワークソケットを通じて描画通知を送信してもよい。描画通知には、サーフェス情報の第一の記述子が含まれる。ファイル記述子は、SurfaceFlingerにより、そのサーフェスの名前付き共有メモリ領域に関する名前空間に基づいて生成されてもよい。描画通知にはまた、データフォーマット、バッファサイズ、サーフェス位置情報が含まれていてもよい。コンソールアプリケーションは、ファイル記述子をそのプロセス空間にマッピングし、マッピングされたファイル記述子を通じて、共有メモリから読み出す。コンソールアプリケーションは次に、そのアプリケーションに関する他のグラフィクスフレームを、サーフェス情報から直接レンダリングする。すると、レンダリングされたグラフィクスフレームはデスクトップOSグラフィクスシステムによってすなわち、HydroidOS660のXウィンドウグラフィクスシステムを通じて表示される。図11は、各種の実施形態による、異環境間リモートレンダリングのための登録及び描画プロセスフロー1100をより詳しく示している。まず、HydroidOS660上で動作中のコンソールアプリケーション1102は、ステップ1106で、共有カーネル520のIPCチャネル525を通じて、AndroidアプリケーションがHydroidOS660のユーザ環境で起動され、表示されるか、AndroidOS430のユーザ環境からHydroidOS660のユーザ環境に移動されるように要求する。Androidは、ステップ1108、1110、1112で、SufaceFlinger434にそのアプリケーションのための仮想ディスプレイIDを要求し、アプリケーションを起動させ、仮想ディスプレイのパラメータを設定する。ステップ1114で、Androidは、IPCチャネル525を通じてディスプレイIDをコンソールアプリケーションに返す。ステップ1116で、アプリケーションは新しいサーフェスを要求し、ステップ1118でこれがSurfaceFlinger434により、サーフェスクラス1104のインスタンスを作ることによって作成される。ステップ1120で、コンソールアプリケーション1102はレンダラオブジェクトのインスタンスを作り、これがHydroidOS660のXウィンドウシステムを通じてAndroidサーフェス情報をレンダリングする。ステップ1122で、コンソールアプリケーション1102は、レンダラオブジェクト1124のリモート処理可能なインタフェースをSurfaceFligner434に登録し、Androidアプリケーションに関するサーフェス情報の描画通知を受け取るようにする。1つの実施形態において、レンダラオブジェクトとリモート処理可能なインタフェースには、draw及びclearメソッドが含まれ、これはIPCチャネル525を通じてコールすることができる。ステップ1126と1128で、SurfaceFlingerは、IPCオブジェクトをサーフェスに貼付し、サーフェス情報が更新された時に、リモート処理可能なインタフェースを通じてコンソールアプリケーション1102に通知が行われるようにする。ステップ1130と1132は、プロセスフロー1100のレンダリングループの一部である。レンダリングループの中で、SurfaceFlingerはコンソールアプリケーション1102に対し、サーフェス情報が更新されたことを通知し、IPCチャネル525を通じて、そのサーフェス情報のファイル記述子を送る。例えば、コンソールアプリケーションレンダラの描画メソッドがコールされ、そのサーフェスのファイル記述子が送られてもよい。コンソールアプリケーション1102は、ファイル記述子をそのプロセス空間にマッピングし、参照された共有メモリ位置にアクセスして、サーフェス情報を読み出し、HydroidOS660に関連する第二のコンピューティング環境のディスプレイ上に表示されるべきグラフィクスフレームをレンダリングする。図12は、各種の実施形態による、非拡張レンダリングコンテキストでの異環境間レンダリングの他の例示的方法のフロー1200を示す。図10の方法1000と同様に、実施形態では、どちらも第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに同時動作中の第一のアプリケーションと第二のアプリケーションのアプリケーショングラフィクスの表示が維持される。方法1200はブロック1204で、第一のオペレーティングシステムの第一のレンダリングコンテキストを作成することから始まる。レンダリングコンテキストは、それが関連するディスプレイに固有のものであってもよい。例えば、モバイルOSの実行は、特定の解像度を有するモバイルデバイスディスプレイに関連付けることができる。レンダリングコンテキストは、関連するディスプレイの解像度にマッチするように作成してもよく、それによってグラフィクスはその解像度に合わせて適正にレンダリングされる。ブロック1208で、方法1200は、第一のオペレーティングシステムを使って、第一のアプリケーションのサーフェスの更新を計算する。前述のように、サーフェスの更新を計算するには、アプリケーションのデータを使って、どのサーフェスがどのように変化したかが判断される。第一のアプリケーションの更新後のサーフェスは、次にブロック1212で、第一のオペレーティングシステムを使ってレンダリングされ、第一のメモリ位置に第一のグラフィクスフレームが生成される。レンダリングでは一般に、グラフィクスプリミティブが、表示されるグラフィクスフレームを形成するビット例えば、ビットマップに変換される。例えば、サーフェス情報は形状、大きさ、色、層の重なり順すなわち、その前または後ろに、他の何れのサーフィスがあるか、透明度等、各サーフェスの特性を数学的に定義する。OSのレンダリングエンジンは、サーフェスデータを解釈し、レンダリングコンテキストの中の各位置例えば、X、Y位置においてどのビットを表示するかを、全サーフェス情報のレンダリングに応じて例えば、繰り返しによる合成、レイトレーシング、及び/またはその他の手法を使用して判断できる。第一のアプリケーションの更新後のサーフェスを、第一のレンダリングコンテキストを使ってビットマップの中にレンダリングし、第一のメモリ位置例えば、フレームバッファメモリ、共有メモリ、またはその他の有益なメモリ位置の中に格納されるようにすることができる。いくつかの実施形態において、ブロック1216で、第一のグラフィクスフレームが第一のメモリ位置から第一のオペレーティングシステムに関連する第一のコンピューティング環境のディスプレイに表示される。例えば、モバイルデバイスディスプレイのためのディスプレイドライバが、関連するフレームバッファメモリにアクセスして、第一のレンダリングコンテキストで生成されたビットマップを表示する。ブロック1220において、第一のレンダリングコンテキストは解体される例えば、破壊される。ブロック1224で、第一のオペレーティングシステムの第二のレンダリングコンテキストが作成される。いくつかの実施例で、第二のレンダリングコンテキストは、第一のレンダリングコンテキストと同じである。しかしながら、第二のレンダリングコンテキストはまた、第二のコンピューティング環境のディスプレイ例えば、デスクトップディスプレイの特徴に応じて作成されてもよい。ブロック1228で、第二のアプリケーションのサーフェスの更新が、第一のオペレーティングシステムを使って計算される。ブロック1232で、これらの更新が次に第一のオペレーティングシステムの第二のレンダリングコンテキストでレンダリングされ、第二のメモリ位置に第二のグラフィクスフレームが生成される。特に、第二のメモリ位置は、モバイルデバイスの共有カーネル上で同時動作中の第一のオペレーティングシステムと第二のオペレーティングシステムの両方によりアクセス可能な共有メモリ位置である。いくつかの実施形態において、ブロック1236で、第二のグラフィクスフレームが第二のメモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティング環境のディスプレイに表示される。特筆すべき点として、図10とは異なり、両方のアプリケーションの更新されたグラフィクスフレームは、第一のOSのレンダリングエンジンを使ってレンダリングされる。例えば、第二のOSのコンソールアプリケーションは、第二の共有メモリ位置にアクセスして、第二のコンピューティング環境のディスプレイに表示するためにレンダリングされたビットマップを直接呼び出すことができる。ブロック1240で、第二のレンダリングコンテキストが解体される。いくつかの実施形態において、方法1200はブロックを繰り返し処理して、両方のアプリケーションのためのグラフィクス環境を同時に維持する。例えば、モバイルOSは、第一のアプリケーションに関するレンダリングコンテキストの作成、使用、破壊を繰り返し、その後、第二のアプリケーションに関するレンダリングコンテキストを作成し、使用し、破壊する。この技術を使用して、すべてのレンダリングを1つのOSによってすなわち、第一のOSのレンダリングエンジンによって実行することができ、もう一方のOSのレンダリング機能を提供または使用する必要がない。しかしながら、この技術では、レンダリングコンテキストを繰り返し作成し、破壊することに伴う追加の間接費が発生する。異環境間レンダリングの上記の実施形態は、非拡張レンダリングコンテキストを使用して、第一のOS上で動作中のアプリケーションに関するグラフィクスフレームが、複数のOSに基づくコンピューティング環境の中の第二のOSのユーザ操作空間のコンソールウィンドウに表示される方法を説明している。このような異環境間アプリケーションのユーザ操作をサポートするために、実施形態では、入力イベントを第二のOSのユーザ操作空間から第一OSにリダイレクトし、異環境間アプリケーションが入力イベントを、それが第一のOSのユーザ操作空間から送られているかのように受け取るようにするすなわち、アプリケーションは入力イベントを、それが第一のOSのユーザ操作空間内で表示された場合にユーザ入力の受け取りに使用するものと同じイベントハンドラ及び/またはビューを通じて受け取る。図7と8に戻ると、デスクトップOS160は、デスクトップコンピューティング体験に適した第二の端末環境840を通じて、第二のユーザ操作空間を提供するように構成される。前述のように、上記の異環境間レンダリングの実施形態を用いれば、アプリケーション752はモバイルOS130のユーザ操作空間に表示されてもよく、その一方で、モバイルOS130上で動作中のアプリケーション754は、デスクトップOS160上で動作中のコンソールアプリケーション782を通じて第二のユーザ操作空間のコンソールウィンドウ882に表示される。特に、アプリケーション752と754は、モバイルOSランタイム環境内で動作中であり、モバイルOSフレームワークを通じて入力イベントを受け取る、モバイルOS130のためにコンパイルされたどのようなアプリケーションであってもよく、表示するため、または遠隔的にモバイルOS130のユーザ操作空間以外で操作するために変更を加える必要がない。図13は、各種の実施形態による、異環境間アプリケーションのユーザ操作をサポートするためのOSアーキテクチャ構成300bを示す。OSアーキテクチャ構成300bにおいて、共有カーネル320のデバイスドライバは、第二の端末環境840を構成するI/Oデバイス844、846及び/または848のためのハードウェアインタフェースを実装する。デバイスドライバを通じて、これらのデバイスの入力イベントが、共有カーネル320のI/Oデバイス1360のデバイス1364、1366及び/または1368に現れる。共有カーネル320のシステムリソースは、モバイルOS130とデスクトップOS160の両方で利用できることから、モバイルOSは、入力デバイス1364、1366及び/または1368の入力イベントがモバイルOS130に対するものであるか否かを判断する。デスクトップOS160が第二のユーザ操作空間を提供するように構成されているすなわち、モバイルコンピューティングデバイス110が第二の端末環境840にドッキングされている場合、モバイルOS130は、第二のユーザ操作空間に関連する入力デバイスからの入力イベントを無視する。OSアーキテクチャ構成300bにおいて、モバイルOS130は、デバイス1364、1366及び/または1368からの入力イベントを無視する。この場合、デスクトップOS160がデバイス1364、1366及び/または1368からの入力イベントを受け入れる。デスクトップOS160は、デバイス1364、1366及び/または1368からの入力イベントを処理し、このイベントをデスクトップOS160内の各種のウィンドウまたはGUI要素にどのように分配するかを判断する。例えば、デスクトップOS160のウィンドウシステム774は、デバイス1364、1366及び/または1368からの入力イベントを受け入れてもよい。1つの実施形態において、デスクトップOS160のグラフィクスシステムは、Xウィンドウグラフィクスシステムである。1つの例において、ユーザは、コンソールアプリケーション782のコンソールウィンドウ882の中の画面位置でポインティングデバイスのボタンをクリックする。これに対応する入力イベントがデバイス1368に現れ、デスクトップOS160はこの入力イベントを受け取って、処理する。ウィンドウシステム774は、入力イベントをコンソールアプリケーション782に送り、これを通じて、モバイルOS130上で動作中のアプリケーション754が、異環境間レンダリングの実施形態を使って表示される。前述のように、アプリケーション754はモバイルアプリケーションであり、モバイルOS130の入力待ち行列736からの入力を受け取るモバイルOS130のライブラリを使って、ビューとその他のイベントハンドラのインスタンスを作成し、ユーザ入力を受け取る。入力イベントをアプリケーション754に、アプリケーション754がその入力イベントを適正に解釈できるような方法で提示するために、コンソールアプリケーション782は、入力イベントをモバイルOS130のグラフィクスコンテキストにマッピングし、仮想入力デバイス1370を通じてこのイベントをモバイルOS130の入力待ち行列736に送る。仮想入力デバイス1370はモバイルOS130にとって、モバイルOS130のための適正な入力イベントプロトコルを有する入力デバイスに見える。これに加えて、入力イベントは、コンソールアプリケーション782によって、モバイルOS130のグラフィクスコンテキストに関連するようにフォーマットされる。モバイルOS130は、仮想入力デバイス1370をアプリケーション754に関連付け、アプリケーション754がモバイルOSのイベント待ち行列から入力イベントを受け取るようにする。例えば、モバイルOS130は、仮想入力デバイス1370をアプリケーション754の仮想ディスプレイIDに関連付けてもよい。このようにして、アプリケーション754は、アプリケーション754がモバイルOS130のユーザ操作空間を通じて表示、操作されるかのように、入力イベントを受け取り、処理する。図14は、各種の実施形態による、非拡張グラフィクスコンテキストを使ってレンダリングされる異環境間アプリケーションのためのユーザ操作をサポートする態様を示す。方法1400は、ブロック1402で、入力イベントをモバイルコンピューティングデバイス110に接続された入力デバイス例えば、キーボード846、ポインティングデバイス848から受け取ることから始まる。前述のように、入力イベントは共有カーネル内の入力デバイスに現れてもよい。ブロック1404で、モバイルOSは、モバイルコンピューティングデバイス110がドッキングされ、デスクトップOSが入力デバイスに関連付けられているか否かを判断する。例えば、モバイルコンピューティングデバイス110が第二の端末環境にドッキングされておらず、デスクトップOSが一時停止している場合、モバイルOSは、デスクトップが入力デバイスに関連付けられていないと判断することができる。デスクトップOSが一時停止しているか、入力デバイスがデスクトップOSに関連する第二の端末環境の一部ではない場合、ブロック1406で、モバイルOSが入力デバイスからの入力コマンドを受け入れる。デスクトップOSが一時停止しておらず、入力デバイスがデスクトップOSに関連する第二の端末環境の一部である場合、ブロック1408で、モバイルOSは入力デバイスの入力イベントを無視し、デスクトップOSがその入力イベントを受け入れる。ブロック1410で、デスクトップOSは入力イベントを、デスクトップOS内の適当なウィンドウかGUI要素に分配する。入力イベントがコンソールウィンドウに送られなければ、ブロック1412で、この入力イベントは他のウィンドウまたはGUI要素に送られる。入力イベントがコンソールウィンドウに送られた場合例えば、ユーザがポインティングデバイスをコンソールウィンドウ領域の中でクリックする、ブロック1414で、この入力イベントが入力イベントとしてコンソールアプリケーションに送られる。ブロック1416で、仮想入力デバイスが、コンソールアプリケーションからの入力イベントのために生成される。仮想入力デバイスは共有カーネルの中に生成されてもよく、または入力イベントがモバイルOS入力デバイスの中に直接書き込まれてもよい。ブロック1418で、コンソールアプリケーションは入力イベントをモバイルOSのグラフィクスコンテキストにマッピングする。例えば、コンソールアプリケーションは、コンソールアプリケーションのコンソールウィンドウの中の入力イベントの位置を、モバイルOSのグラフィクスコンテキストの中の位置にマッピングしてもよい。コンソールアプリケーションは、その入力イベントを、モバイルOSのための入力フォーマットまたは入力モードステートに変換してもよい。例えば、入力フォーマットは、デスクトップOSとモバイルOSの間で異なっていてもよい。共通の入力フォーマットであっても、デスクトップOSとモバイルOSは異なる入力モードステートを有していてもよい。例えば、デスクトップOSは、ノンタッチモードの入力ステートを使って入力イベントを処理していてもよく、その一方で、モバイルOSはタッチモード入力ステートである。この場合、デスクトップOSのユーザ操作空間内でポインティングデバイスにより生成された入力イベントは、仮想入力デバイスにジェスチャベースイベントとして現れるように変換されてもよい。ブロック1420で、仮想入力デバイスは、モバイルOSの中で、コンソールウィンドウに表示されるそのアプリケーションのための仮想ディスプレイデバイスに関連付けられる。例えば、複数のアプリケーションがモバイルOS上で動作中であり、デスクトップOSのユーザ操作空間の異なるコンソールウィンドウに表示されていてもよい。デスクトップOSのユーザ操作空間の中の別々のコンソールウィンドウに表示された各アプリケーションには、モバイルOS内の仮想ディスプレイIDが割り当てられる。そのため、モバイルOSが仮想デバイスを通じてデスクトップOSのコンソールアプリケーションから入力イベントを受け取ると、モバイルOSは、仮想ディスプレイIDを通じて、その仮想デバイスを正しいアプリケーションにマッピングすることができる。ブロック1422で、入力イベントは仮想ディスプレイに関連するアプリケーションに送られ、このアプリケーションはその入力イベントを、それがモバイルOSのユーザ空間を通じて発生したかのように処理することができる。特に、上記の方法は、モバイルOS130の何れのアプリケーションにも利用でき、アプリケーションは、デスクトップOSのコンソールアプリケーションを通じて入力イベントを受け入れるように特に設計されている必要がない。拡張レンダリングコンテキストによる実施形態いくつかの実施形態は、第一のオペレーティングシステムの中で拡張レタリングコンテキストを作成することによって、複数のOSにまたがる同時ユーザインタフェースのサポートを扱う。前述のように、第一のOS例えば、モバイルOSであるAndroidは一般に、単独のアクティブレンダリングコンテキストで、単独のアクティブユーザ操作空間を定義するように構成される。本明細書では、多数のいわゆるコンテキスト空間を1つの拡張レンダリング空間にタイリングし、各コンテキスト空間を異なるディスプレイに関連付けることによって、第一のOSを、同時に扱われる複数のユーザ操作空間に有効にフーリングするための新規な技術を説明する。実施形態には、複数のユーザ操作空間へのディスプレイ出力を処理するための技術と、これらのコンテキストでユーザ操作を処理する技術が含まれる。非拡張レンダリングコンテキストによる実施形態に関して上述した例に戻り、再び、カレンダアプリケーションとワードプロセシングアプリケーションがどちらも第一のOS例えば、モバイルOSであるAndroidOSのためにコンパイルされ、どちらもモバイルデバイスの第一のOS内で同時動作中であると仮定する。第二のOS例えば、Hydroidのような非モバイルOSは、共有カーネルを使って、モバイルデバイス上で同時に動作している。ユーザは、モバイルデバイスを第二のデスクトップコンピューティング環境にドッキングしており、デスクトップコンピューティング環境は、第二のOSのためのユーザ操作空間に関連付けられ、このユーザ操作空間を表示している。ユーザは、第二のOSのデスクトップコンピューティング環境を通じて、第一のOS上で動作中のワードプロセシングアプリケーションを操作したいと希望する。デスクトップコンピューティング環境のユーザ操作空間を、モバイルコンピューティング環境例えば、モバイルデバイスの第二のOSを使って、ユーザにとってわかりやすい方法で扱うことが望ましい。図15は、各種の実施形態による、拡張レンダリングコンテキストを使って複数のOSにまたがる同時ユーザインタフェースをサポートする態様を示す。図15に示されるアプリケーションレンダリングの概略図1500において、第一のアプリケーション1510例えば、カレンダアプリケーションは、第一のOS内の第一のサーフェス1512の更新を計算する。第一のサーフェス1512は、第一のOSによって共有メモリ空間内の第一メモリ位置に格納される。具体的には、第一のアプリケーション1510は、第一のサーフェス1512のバックバッファ1514を更新する。同様に、第二のアプリケーション1530例えば、ワードプロセシングアプリケーションは、第一のオペレーティングシステムを使って第二のサーフェス1532の更新を計算する。ここでも、第二のアプリケーション1530による第二のサーフェス1532への更新がバックバッファ1534に対して行われる。第二のサーフェス1532は、第一のOSによって共有のメモリ空間の中の第二のメモリ位置に格納される。第一のOSは、いつサーフェス情報が変化したかを判断し、レンダリングシーケンスを開始する。第一のOSは、特定のアプリケーションに関連するサーフェス情報がいつ変化したかを判断して、第一のサーフェス1512と第二のサーフェス1532を含む全サーフェスについて1ループを実行してもよい。レンダリングシーケンスの中で、第一のOSは、いつサーフェス情報が変化したかを判断し、第一のサーフェス1512のフロントバッファ1516とバックバッファ1514及び第二のサーフェス1532のフロントバッファ136とバックバッファ1534をスワップする。第一のOSは、共有メモリ空間の中の第三のメモリ位置で拡張レンダリングコンテキスト1520を作成し、第一のサーフェス1512を拡張レンダリングコンテキスト1520の第一のコンテキスト空間1522の中にレンダリングする。第一のOSは、第二のサーフェス1533を拡張レンダリングコンテキスト1520の第二のコンテキスト空間1524の中にレンダリングする。実施形態において、拡張レンダリングコンテキスト1520は、メモリ空間の中で第一のOSのフレームバッファと重複してもよい。例えば、拡張レンダリングコンテキスト1520の第一のコンテキスト空間1522のメモリ位置は、第一のOSのフレームバッファと同じ範囲を占めていてもよい。第一のOSは、最終的な画像が第三のメモリ位置にレンダリングされたという通知を第二のOSに送る。例えば、第一のOSは、拡張コンテキスト1520の第二のコンテキスト空間1524の共有メモリ位置のファイル記述子を、プロセス間通信チャネルを通じて第二のOSのコンソールアプリケーションに送ってもよい。第二のOSは第三のメモリ位置の拡張グラフィクスコンテキストの第二の部分にアクセスして、レンダリングされたグラフィクスフレーム1538を呼び出し、第二のOSのコンソールウィンドウ1540の中に表示されるようにする。例えば、第二のOSのコンソールアプリケーションは、ファイル記述子をそのプロセス空間にマッピングし、第三のメモリ位置からレンダリングされたグラフィクスフレームを読み出し、第二のOSのユーザ操作空間内で表示されるようにする。このようにして、第二のOSは、第二のアプリケーションのレンダリングされたグラフィクスフレームを、そのユーザ操作空間内にリアルタイムで表示する。図16は、各種の実施形態による、拡張レンダリングコンテキストを用いて異環境間レンダリングを行う例示的な方法のフロー1600を示す。実施形態では、第一のアプリケーション例えば、カレンダアプリケーションと第二のアプリケーション例えば、ワードプロセシングアプリケーションのアプリケーショングラフィクスの表示が維持される。どちらのアプリケーションも、第一のオペレーティングシステム例えば、AndroidOSのためにコンパイルされ、その中でアクティブに同時動作中であるが、ユーザは、第二のOSに関連する第二のコンピューティング環境を通じて、第二のアプリケーションを操作したいと望んでいると仮定する。特に、これらの技術は、2つのOSが非互換的である例えば、第一のOS用にコンパイルされたアプリケーションは、直接第二のOSで実行できない環境に利用できる。いくつかの実施例では、前述のように、2つのOSはモバイルデバイスの共有カーネル上で独立して、同時に動作している。方法1600は、ブロック1604で、第一のOSの拡張レンダリングコンテキストを作成することから始まる。前述のように、レンダリングコンテキストは一般に、1つのアクティブディスプレイの特徴に合わせて作成される。しかしながら、拡張レンダリングコンテキストは、第一のアプリケーションに関連する第一のコンテキスト空間と第二のアプリケーションに関連する第二のコンテキスト空間を有するように作成される。第一と第二のコンテキスト空間は重複しない。いくつかの実施形態において、拡張レンダリングコンテキストは、ローカルデバイスのアクティブディスプレイ例えば、共有カーネルを有するモバイルデバイスのティスプレイと何れかの仮想ディスプレイすなわち、第二のOSのユーザ操作空間内で表示されるコンソールウィンドウに関連する第一のOSのディスプレイをタイリングして、第一のOSにとって、1つの大きなディスプレイに見えるものを形成することによって生成される。拡張レンダリングコンテキストの中の領域は、重複しないコンテキスト空間として指定され、その各々の物理的または仮想ディスプレイとの関連付けが維持される。特に、いくつかの実施形態において、異なるコンテキスト空間は、異なる解像度またはその他の特徴を有していてもよい。また、特定の実施形態において、コンテキスト空間は連続していない。例えば、拡張レンダリングコンテキストは、各コンテキスト空間の間に、どのコンテキスト空間にも割り当てられない空間が残されるような方法で作成される。ブロック1608で、第一のオペレーティングシステムを使って、第一のアプリケーションと第二のアプリケーションのサーフェスの更新が計算される。更新後のサーフェスは次に、ブロック1612で、第一のオペレーティングシステムを使ってレンダリングされ、第一のオペレーティングシステムと第二のオペレーティングシステム例えば、共有カーネル上で同時動作中であってもよいによってアクセス可能な共有メモリ位置で拡張グラフィクスフレームが生成される。拡張グラフィクスフレームの第一の部分は第一のアプリケーションに関連する第一のコンテキスト空間に関連付けられ、拡張グラフィクスフレームの第二の部分は第二のアプリケーションに関連する第二のコンテキスト空間に関連付けられる。ブロック1608でレンダリングが行われる際、第一のアプリケーションの更新後のサーフェスは、拡張グラフィクスフレームの第一の部分にレンダリングされ、第二のアプリケーションの更新後のサーフェスは、拡張グラフィクスフレームの第二の部分にレンダリングされる。特筆すべき点として、このようにして、拡張グラフィクスフレームには、その適当なコンテキスト空間の中にタイリングされた両方のアプリケーションのレンダリングされたサーフェスが有効に含まれる。いくつかの実施形態において、ブロック1616で、拡張グラフィクスフレームのうち、第一のコンテキスト空間に関連する第一の部分が、共有メモリ位置から第一のOSに関連する第一のコンピューティング環境のディスプレイに表示される。例えば、前述のように、共有メモリ位置はモバイルデバイスのフレームバッファメモリでありまたはフレームバッファメモリにコピーされ、モバイルデバイスのディスプレイデバイスドライバがそのフレームバッファメモリにアクセスして、拡張グラフィクスフレームの第一の部分をそのディスプレイに表示する。さらに、いくつかの実施形態において、ブロック1620で、拡張グラフィクスフレームのうち、第二のモーション空間に関連する第二の部分が、共有メモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティングデバイスのディスプレイに表示される。例えば、前述のように、共有メモリ位置は第二の例えば、デスクトップコンピューティング環境に関連する第二のOSのフレームバッファメモリの中にコピーされ、ディスプレイデバイスドライバは、拡張グラフィクスフレームの第二の部分を第二のコンピューティング環境のディスプレイに表示する。図12に関して説明した実施形態において、第二のアプリケーションの更新後のグラフィクスのレンダリングは、第二のOSによって遠隔的に行われる。図15に関して説明した実施形態において、両方のアプリケーションのレンダリングがモバイルデバイスのレンダリングエンジンによってローカルで実行されるが、レンダリングコンテキストは継続的に作成され、解体される。図16に関して説明した実施形態によれば、両方のアプリケーションのレンダリングがモバイルデバイスのレンダリングエンジンによってローカルで実行され、その一方で、拡張はされているが、単独のレンダリングコンテキストが維持されるすなわち、レンダリングコンテキストが解体されない。図17は、各種の実施形態による、拡張レンダリングコンテキストを使用する異環境間レンダリングの他の例示的な方法のフロー1700を示す。図16の方法1600と同様に、実施形態では、どちらも第一のオペレーティングシステムのためにコンパイルされ、アクティブに同時動作中の第一のアプリケーションと第二のアプリケーションのためのアプリケーショングラフィクスのディスプレイが維持される。方法1700は、ブロック1704で、第一のオペレーティングシステムの拡張レンダリングコンテキストを作成することから始まり、ブロック1708で、第一のオペレーティングシステムを使って、第一のアプリケーションと第二のアプリケーションのサーフェスの更新が計算される。前述のように、拡張レンダリングコンテキストは、第一のアプリケーションに関連する第一のコンテキスト空間と第二のアプリケーションに関連する第二のコンテキスト空間を有するように作成される。第一と第二のコンテキスト空間は重複しない。いくつかの実施例では、ブロック1704と1708はそれぞれ、ブロック1604と1608と実質的に同じ方法で実行される。ブロック1712で、第一のアプリケーションの更新後のサーフェスが、第一のオペレーティングシステムを使って、第一のコンテキスト空間に従ってレンダリングされ、第一のオペレーティングシステムのフレームバッファに第一のグラフィクスフレームが生成される。たとえは、第一のコンテキスト空間は、特定の解像度、特定のタイリングオフセット例えば、X位置から始まる等に関連付けられてもよい。いくつかの実施形態において、第一のグラフィクスフレームは、図16の方法1600の拡張グラフィクスフレームのそれぞれの部分の生成と実質的に同じ方法で生成される。いくつかの実施形態において、ブロック1716で、第一のコンテキスト空間に関連する第一のグラフィクスフレームが、フレームバッファから第一のオペレーティングシステムに関連する第一のコンピューティング環境のディスプレイに表示される。ブロック1720で、第二のアプリケーションの更新後のサーフェスが、第一のオペレーティングシステムを使ってレンダリングされ、共有メモリ位置に第二のグラフィクスフレームが生成される。前述のように、共有メモリ位置は第一のオペレーティングシステムと第二のオペレーティングシステム例えば、これらは共有カーネル上で同時動作中であってもよいによってアクセス可能である。いくつかの実施形態において、ブロック1724で、第二のモーション空間に関連する第二のグラフィクスフレームが、共有メモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティング環境のディスプレイに表示される。特に、図16と17の両方の実施形態では、各アプリケーションのコンテキスト空間を有する拡張レンダリングコンテキストが作成される。しかしながら、図16の方法1600は、すべてのグラフィクスの更新を1つの拡張ビットマップにレンダリングするが、図17の方法1700は、グラフィクスの更新を別のビットマップにレンダリングする。一方または他方の技術のどちらが望ましいかは、例えばメモリの管理及び/またはアクセス方法によって異なる。図12の実施形態と同様に、図16と17の実施形態においては、両方のアプリケーションの更新後のグラフィクスフレームが第一のOSのレンダリングエンジンを使ってレンダリングされる。第一のOSのレンダリングエンジンを使用することにより、両方のアプリケーションに第一のOSで利用可能なモバイルデバイスのハードウェア加速機能を使用できる。例えば、図12、16及び/または17の実施形態において、第一と第二のアプリケーションの何れかまたは両方を、2Dまたは3Dハードウェア支援レンダリングを使って、第一のOSによりレンダリングしてもよい。拡張レンダリングコンテキストを使って第一のOSすなわち、モバイルOSであるAndroid上で動作するアプリケーションのためのグラフィクスフレームを遠隔的に表示することにより、第一のOSが1つのレンダリングコンテキストを使って、複数のユーザ操作空間内で表示するように、複数のアプリケーションのためのレンダリングを提供できる。しかしながら、拡張レンダリングコンテキストでは、拡張レンダリングコンテキストを通じて表示されるアプリケーションに関する入力イベントの取扱いに関する問題が発生する。具体的には、第一のOSの入力待ち行列は、拡張レンダリングコンテキストの別の仮想ディスプレイを通じて表示される複数のアプリケーションからの複数の入力イベントを取り扱うように構成しなければならない。異環境間ユーザ操作のサポートの実施形態は、第一のOS上で動作し、第一のOSの拡張レンダリングコンテキストを通じて複数の別々のユーザ操作空間すなわち、モバイルデバイスユーザ操作空間とデスクトップOSのユーザ操作空間で表示される複数のアプリケーションに関するユーザ入力イベントを処理することに関する。実施形態には拡張入力待ち行列が含まれ、そこでは遠隔的に表示されるアプリケーションのための仮想入力デバイスからの入力イベントがその入力待ち行列の中の別々のモーション空間にマッピングされる。例えば、第一のアプリケーション例えば、カレンダアプリケーションが第一のOS上で動作中であり、第一のデバイスに関連する第一のディスプレイ例えば、第一のOSが動作中のモバイルデバイスのディスプレイに表示されている。第二のアプリケーション例えば、ワードプロセシングアプリケーションも、第一のアプリケーションと同時動作中であるが、拡張レンダリングコンテキストのコンテキスト空間例えば、仮想ディスプレイの中でレンダリングされ、モバイルデバイスの共有カーネル上で第一のOSと同時動作中の第二のOSの第二のユーザ操作空間に表示されている。第一のOSは、第一のコンテキスト空間すなわち、モバイルデバイスディスプレイの中の第一のアプリケーションと第二のコンテキスト空間の第二のアプリケーションの両方に関するアプリケーショングラフィクスを含む拡張レンダリングコンテキストを通じて、グラフィクスフレームをレンダリングする。第二のコンテキスト空間は、第二のOS上で動作中のコンソールアプリケーションを通じて第二のOSのユーザ操作空間に表示される。拡張レンダリングコンテキストを通じて遠隔的に表示されるアプリケーションに関する入力イベントは、非拡張グラフィクスコンテキストに関して上述したものと同じ方法で、第二のOSすなわち、デスクトップOSであるHydroidによって受け取られ、第二のOSのコンソールアプリケーションによって仮想入力デバイスに送られる。しかしながら、前述のように、仮想入力デバイスからモバイルOSで受け取られた入力イベントは、第二のOSのユーザ操作空間内に表示されるコンソールウィンドウに関係する。仮想入力デバイスは、拡張入力待ち行列の中の、遠隔的に表示されたアプリケーションに対応する仮想ディスプレイに関連するモーション空間にマッピングされる。拡張入力待ち行列によって、第一のOSは、1つの入力待ち行列を使って、同時動作する複数のアプリケーション用として意図された複数のローカル及び仮想入力デバイスからの入力を正しく処理することができる。図18aと18bは、各種の実施形態による、拡張レンダリングコンテキストを用いた異環境間アプリケーションのユーザ操作サポートの態様を示す。図18aは、第一のOS上で動作中のアプリケーションを遠隔的に表示しているユーザ操作空間1810例えば、第一のOSで動作中のアプリケーションを表示している第二のOSのGUIを示している。例えば、第一と第二と第三のアプリケーションが第一のOS上で動作していてもすなわち、第一のOSでアクティブに同時動作中であってもよい。第一のOSは、上述の実施形態により、第一と第二と第三のアプリケーションを、第一のOSの拡張レンダリングコンテキストの第一と第二と第三のコンテキスト空間に表示してもよい。ユーザ操作空間1810のコンソールウィンドウ1812と1814はそれぞれ、第一のOSの中で動作中の第二のアプリケーションと第三のアプリケーションを表示していてもよい。図18bは、第一のOS上で動作中の各アプリケーションのためのユーザ操作をサポートする、第一のOSの拡張入力待ち行列1840を示す。拡張入力待ち行列1840には、第一のモーション空間1842、第二のモーション空間1844、第三のモーション空間1846が含まれる。第一のモーション空間は第一のOSの拡張レンダリングコンテキストの第一のコンテキスト空間に関連付けられ、これは一般に、第一のOSの非仮想ディスプレイ1852を表示するために使用されるすなわち、モバイルコンピューティングデバイス110のディスプレイ116に関連するコンテキスト空間。第二と第三のモーション空間はそれぞれ、仮想ディスプレイ1854、1856に関連付けられ、これらは第二と第三のコンテキスト空間を通じてレンダリングされる。遠隔的に表示されているアプリケーションのコンソールウィンドウに送られる入力イベントが発生すると、この入力イベントは、そのアプリケーションが表示される仮想ディスプレイに関連するモーション空間へと送られる。例えば、ユーザが、入力イベント1820によって示されるように、ユーザ操作空間1810のコンソールウィンドウ1812でポインティングデバイスをクリックすると、第二のOSのウィンドウシステムがその入力イベントを、コンソールウィンドウ1812に関連するコンソールアプリケーションに送る。前述のように、コンソールアプリケーションは入力デバイスを仮想入力デバイスにマッピングする。しかしながら、この入力イベントはコンソールウィンドウ1812に関係している。この入力イベントが第一のOSの入力待ち行列に直接供給された場合、この入力イベントは正しいアプリケーションイベントハンドラに送られないであろう。そのため、仮想入力デバイスからの入力イベント1820は第二のモーション空間1844にマッピングしなおされる。このようにして、拡張入力待ち行列はその入力イベントを第二のアプリケーションのイベントハンドラに送り、これが入力イベント1820を受け取り、処理する。実施形態において、仮想ディスプレイはモバイルOSの入力待ち行列の中でオフセットされる。例えば、図18bにおいて、仮想ディスプレイ1854と1856は、モバイルOSの入力待ち行列1840の中の仮想ディスプレイオフセット1858の分だけオフセットされる。仮想ディスプレイオフセット1858は、仮想ディスプレイが入力待ち行列内で隣接して現れるのを防止するものであり、隣接して現れた場合、1つの仮想ディスプレイ用として意図されたある入力イベントが、別のアプリケーションに関連するモーション空間内で解釈される可能性がある。仮想ディスプレイのオフセットは、実際の仮想ディスプレイの解像度のパラメータとして使用されないように、十分に大きくするべきである。1つ実施形態において、仮想ディスプレイのオフセット1858は10000ピクセルと選択される。図19は、各種の実施形態による、拡張レンダリングコンテキストを通じて表示される異環境間アプリケーションに関する入力イベントを受け取る方法1900を示す。例えば、方法1900は、第一のOS内で動作中の第一のアプリケーションと第二のアプリケーションに関する入力イベントを処理するために使用してもよく、第一のOSの拡張レンダリングコンテキストを通じて、第一のアプリケーションは第一のOSのユーザ操作空間にローカルで表示され、第二のアプリケーションは第二のOSのユーザ操作空間に遠隔的に表示される。方法1900は、ブロック1902で、第一のユーザ入力が第一のOSで受け取られることから始まり、この時、第一のアプリケーションと第二のアプリケーションは第一のOS内でアクティブに同時動作中であり、第一のアプリケーションが第一のOSに関連する第一のユーザ環境内で表示され、第二のアプリケーションが第二のOSに関連する第二のユーザ環境内で表示され、第一と第二のオペレーティングシステムは共有カーネル上で同時動作中であり、第一のOSは、拡張レンダリングコンテキストの第一の仮想ディスプレイを通じて第二のアプリケーションに関するグラフィクスフレームをレンダリングすることにより、第二のアプリケーションに関するアプリケーショングラフィクスを維持する。ブロック1904で、第一のOSは第一のモーション空間と第二のモーション空間を含む拡張入力待ち行列を作成し、第二のモーション空間は第一の仮想ディスプレイに対応する。例えば、第一のオペレーティングシステムは第二のアプリケーションのための第一の仮想ディスプレイを割り当て、第一のコンテキスト空間と第二のコンテキスト空間を有する拡張レンダリングコンテキストを作成し、第一の仮想ディスプレイを第二のコンテキスト空間に関連付け、上述の方法を用いて、拡張レンダリングコンテキストの第二のコンテキスト空間を通じて、第二のアプリケーションに関するグラフィクスフレームをレンダリングする。ブロック1906で、第一のユーザ入力イベントが、第一のOSにより、第一の仮想入力デバイスにおいて、第二のOSを通じて第二のアプリケーションに関するレンダリングされたグラフィクスフレームを表示している、第二のOSで動作中の第一のコンソールアプリケーションから受け取られる。ブロック1908で、第一の仮想入力デバイスは、第一のオペレーティングシステムの拡張入力待ち行列の第二のモーション空間にマッピングされる。第一の仮想入力デバイスを第二のモーション空間にマッピングすることによって、第一のOSの拡張入力待ち行列は、第一の仮想入力デバイスからの入力イベントを第二のアプリケーションのビューの中のイベントハンドラに正しく関連付けることができる。具体的には、入力イベントが第二のモーション空間にマッピングされると、第一のOSはこの入力イベントを、拡張入力待ち行列の中の第二のアプリケーションに関連する位置で発生したものとして扱う。ブロック1910で、第一のOSは第一のユーザ入力イベントを、マッピングされた第一の仮想入力デバイスから第二のアプリケーションに送る。拡張入力待ち行列は、拡張レンダリングコンテキストがタイリングされるという性質を利用して、入力待ち行列が複数のユーザ操作空間からの複数の入力イベントを処理し、入力イベントを所期のアプリケーションの適当なイベントハンドラに送ることができるようにする。ミラーリングされたコンテキストによる実施形態拡張及び非拡張レンダリングコンテキストの実施形態を、複数のオペレーティングシステム上の複数のアプリケーションにわたる同時ユーザ操作空間を維持するという内容で説明した。多くの場合、1つのユーザ操作空間のためにコンテキストをミラーリングすることが望ましい。第二のOSに関連する第二のコンピューティング環境例えば、HydroidOSに関連するデスクトップ環境の中で同時に第一のOSを見て、これを操作することすなわち、操作空間をミラーリングすることが望ましい。ミラーリングされたユーザ操作空間を通じて、ユーザは第一のOSを、ローカルデバイスを通じて操作するかのように操作できるすなわち、ユーザは、利用可能なアプリケーションをブラウズし、アプリケーションを開始、停止し、第一のOSの検索機能を使用すること等ができる。第一のOS例えば、モバイルOSであるAndroidは一般に、単独のアクティブなユーザ操作空間を画定するように構成される。ユーザ操作空間は、アクティブディスプレイ例えば、解像度等、関連する特徴を有すると、ユーザがアクティブディスプレイ上に表示された要素を操作できるようにする1つまたは複数のアクティブ入力デバイスを含む。異環境間レンダリングを使って、複数のOSにわたって1つまたは複数のミラーリングされたユーザ操作空間を提供する新規な方法を提示する。前述のように、実施形態は、複数のOSが非互換的であり、及び/または共有カーネル上で独立して、並行動作している場合も動作できる。ミラーリングされたコンテキストにより同時ユーザ操作のサポートを維持することは、異環境間アプリケーションのための同時ユーザ操作をサポートすることに関して上述したものと同じシステム要素の多くを用いて実現できる。例えば、図7を参照すると、モバイルOS130のためのグラフィクスコンテキストは、モバイルOS130のアプリケーション例えば、アプリケーション752及び/または754及び/またはホーム画面例えば、AndroidOS430のホーム画面アプリケーション451をアクティブに表示していてもよい。アクティブに表示されるモバイルOSのアプリケーション及び/またはホーム画面に関するサーフェス情報は、共有メモリ724の中に格納されてもよい。モバイルOS130のミラーリングされたコンテキストは、コンソールアプリケーション782を通じて、デスクトップOS160のユーザ操作空間に表示されてもよい。図20は、様々な実施形態による、ミラーリングされたユーザ操作空間を提供するためのグラフィクスコンテキストの異環境間レンダリングの例示的な方法のフロー2000を示す。方法2000はブロック2004で、第一のオペレーティングシステムを使って、第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに動作中の第一のアプリケーションのサーフェス集合の更新を計算することから始まる。例えば、計算は、サーフェスの形状、大きさ、テクスチャ、レイヤリング等の変化を判断するために行われる。次に、ブロック2008で、サーフェスの更新が第一のオペレーティングシステムを使ってレンダリングされ、グラフィクスフレームが生成される。グラフィクスフレームは、そのアプリケーションに関する更新後のグラフィクス情報を反映するビットマップであってもよい。ブロック2012で、グラフィクスフレームは、第一のオペレーティングシステムと第二のオペレーティングシステムの両方によりアクセス可能な共有メモリ位置に格納される。いくつかの実施形態において、第一と第二のOSは、共有カーネル上で同時動作中である。ブロック2016で、グラフィクスフレームは第一のオペレーティングシステムを使って、第一のコンピューティング環境の第一のディスプレイ上の第一のアプリケーションの第一のアプリケーションディスプレイに表示されてもよい。例えば、共有メモリの位置はフレームバッファメモリであってもよく、または第一のオペレーティングシステムのフレームバッファにコピーされてもよい。ローカルデバイス例えば、共有カーネル上で動作中のディスプレイデバイスドライバは、そのフレームバッファメモリにアクセスし、ビットマップを表示する。ブロック2012で共有メモリ位置にグラフィクスフレームを格納した後、第二のOSに、更新されたグラフィクス情報が利用可能であると知らせることが望ましい。ブロック2020で、共有メモリ位置を特定するファイル記述子が、第二のOSのためにコンパイルされ、その中でアクティブに動作中のコンソールアプリケーションに送られる。いくつかの実施例において、ファイル記述子には、共有メモリ位置の識別が含まれる。他の実施例では、ファイル記述子には、ミラーリングされるアプリケーションに関する更新後のグラフィクス情報が利用可能であることを示すフラッグのような追加の情報が含まれる。前述のように、コンソールアプリケーションは、Xウィンドウまたは、第二のコンピューティング環境のディスプレイのウィンドウ内に表示されるその他の種類のアプリケーションであってもよい。ブロック2024で、コンソールアプリケーションは、ファイル記述子による共有メモリ位置の更新後のグラフィクス情報例えば、ビットマップにアクセスし、そのグラフィクスフレームを共有メモリ位置から第二のコンピューティング環境の第二のディスプレイ上の第一のアプリケーションの第二のアプリケーションディスプレイに表示する。いくつかの実施形態において、アプリケーションに関する更新後のグラフィクス情報は、第一と第二のコンピューティング環境の両方のディスプレイで実質的に同時に表示される。図21は、様々な実施形態による、ミラーリングされたユーザ操作空間を提供するためのグラフィクスコンテキストの異環境間レンダリングの他の例示的な方法のフロー2100を示す。図20と同様に、方法2100はブロック2104で、第一のオペレーティングシステムを使って、第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに動作中の第一のアプリケーションのサーフェス集合の更新を計算することから始まる。フロック2108で、更新後のサーフェス集合が、第一のオペレーティングシステムと第二のオペレーティングシステム例えば、共有カーネル上で同時動作中の両方によってアクセス可能な共有メモリ位置に格納される。ブロック2112で、更新後のサーフェス集合は第一のオペレーティングシステムでレンダリングされ、第一のグラフィクスフレームが生成される。次に、ブロック2116で、第一のグラフィクスフレームを、第一のオペレーティングシステムを使って、第一のコンピューティング環境の第一のディスプレイ上の第一のアプリケーションの第一のアプリケーションディスプレイに表示することができる。例えば、モバイルOS130は、更新後のアプリケーショングラフィクスをレンダリングして、更新後のグラフィクスをモバイルデバイス110のディスプレイ116に表示する。ブロック2108で更新後のサーフェス集合を共有メモリに格納した後、何れかの時点で、第二のOSに対して、更新後のグラフィクス情報が利用可能であると通知することが望ましい。ブロック2120で、共有メモリ位置を特定するファイル記述子が、第二のオペレーティングシステムのためにコンパイルされ、その中でアクティブに動作中のコンソールアプリケーションに送られる。特に、共有メモリ内に格納された情報は、図20の方法2000のようなレンダリングされたビットではなく、レンダリングされていないサーフェス情報例えば、幾何プリミティブである。従って、ブロック2124で、更新後のサーフェス集合は、第二のオペレーティングシステムによって例えば、ファイル記述子によるコンソールアプリケーションを介して共有メモリ位置からレンダリングされ、第一のグラフィクスフレームと実質的に同じ第二のグラフィクスフレームが生成される。ブロック2128で、第二のグラフィクスフレームは、第二のオペレーティングシステムのコンソールアプリケーションを介して、第二のコンピューティング環境の第二のディスプレイ上の第一のアプリケーションの第二のアプリケーションディスプレイに表示され、それによって、第二のアプリケーションディスプレイは第一のアプリケーションディスプレイと実質的に同じとなる。特筆すべき点として、第一と第二のオペレーティングシステムシステムの両方でレンダリングを複製することから、追加の間接費が発生し得る。しかしながら、このような追加の間接費には、数多くの状況において、相応の価値がある可能性がある。例えば、異なるコンピューティング環境のディスプレイの特徴が顕著に異なる場合、各々がそれぞれのディスプレイに適した別々のレンダリングコンテキストで更新後のグラフィクス情報をレンダリングすることが望ましい場合がある。図20と21の方法は、ミラーリングされたグラフィクスコンテキストの中での、第一のOSで動作中のアプリケーションのアクティブディスプレイによるグラフィクスコンテキストの異環境間ミラーリングを説明している。しかしながら、この方法は、グラフィクスコンテキストの中でアクティブに表示されているアプリーションがない場合にも使用できる。例えば、グラフィクスコンテキストは、第一のOSのホーム画面またはその他の機能例えば、検索画面等を表示していてもよい。このような場合、グラフィクスコンテキストに関するサーフェス情報は第一のOSのコンポーネントによって更新され、図20と21の方法のその他のステップは、第二のアプリケーションディスプレイの中にミラーリングされたグラフィクスコンテキストを提供するために実行されてもよい。特に、グラフィクスコンテキストの異環境間ミラーリングは、アプリケーションの異環境間レンダリングと同時に利用してもよい。例えば、図20または21による方法は、前述のアプリケーションの異環境間レンダリングの方法を使って、第一のOSで動作中のアプリケーションが第二のユーザ環境内で表示されるのと同時に、モバイルデバイスのユーザ操作空間のアクティブグラフィクスコンテキストを第二のユーザ環境にミラーリングするために使用してもよい。説明のために図8を参照すると、モバイルOS用アプリケーションがディスプレイ844の上のデスクトップOSのユーザ操作空間内の第二のコンソールウィンドウ884に表示されている間に、モバイルOSのユーザ操作空間を第一のコンソールウィンドウ882の中に表示してもよい。ミラーリングされたグラフィクスコンテキストのためのユーザ操作のサポートは、図13、14、18及び/または19に示される異環境間アプリケーションのためのユーザインタフェースをサポートするのと実質的に同じ方法で行われてもよい。具体的には、入力イベントは、第二のOSのコンソールアプリケーションから仮想入力デバイスに提供されてもよい。第一のOSは、拡張または非拡張入力待ち行列を通じて、仮想入力デバイスからの入力イベントを受け入れてもよい。異環境間レンダリングの実施形態上記の方法は、第二のオペレーティングシステムのユーザ操作空間を通じた第一のオペレーティングシステムのアプリケーションとグラフィクスコンテキストのための異環境間ユーザ操作をサポートする。わかりやすい異環境間使用モデルとするために、実施形態は、第二のオペレーティングシステムのユーザ操作空間から、第一のオペレーティングシステムのアプリケーション及び/またはミラーリングされたコンテキストにアクセスできるようにすることに関する。再び図8を参照すると、ユーザは、モバイルデバイス上の操作コンポーネントすなわち、タッチスクリーンディスプレイ116、その他のI/Oデバイス118を含む第一のユーザ操作空間を通じて、第一のOSすなわち、モバイルOSであるAndroidを操作できる。ユーザはまた、第二のOSすなわち、デスクトップOSであるHydroidを、第二の端末環境840のディスプレイ844を含む第二のユーザ操作空間を通じて操作できる。前述のように、デスクトップOS160で利用可能なすなわち、そのためにコンパイルされ、その実行環境内にロードされたアプリケーションの集合は、モバイルOS130で利用可能なものとは異なるかもしれない。実施形態は、デスクトップOS160のユーザ操作空間のメニューの中にモバイルOS130で利用可能なアプリケーションのためのメニューアイコンまたはメニューリストアイテムを設けることによって、モバイルOS130のアプリケーションにデスクトップOS160のユーザ操作空間内でアクセスできるようにすることに関する。図22は、各種の実施形態による異環境間リダイレクションの態様を示す。図22に示されるコンピューティング環境2200の中で、ユーザは、デスクトップOSのユーザ操作空間2202を通じてデスクトップOS160を操作する。デスクトップOSのユーザ操作空間2202の中で、メニューバー2220には、利用可能なアプリケーションのアイコンまたはリストが含まれる。あるアプリケーションを起動させるには、ユーザはそのアプリケーションの名前またはアイコンをメニューバーから、またはメニューバー2220のドロップダウンまたはポップアップリストから選択する。従来、メニューバー2220には、デスクトップOS160で利用可能なアプリケーションのメニューアイテムまたはアイコンのみが含まれている。例えば、メニューアイテム2222、2224、2226及び/または2228は、デスクトップOS160で利用可能なすなわち、そのためにコンパイルされ、その実行環境の中にロードされたアプリケーションであってもよい。本発明の実施形態は、デスクトップOSのユーザ操作空間2202からのモバイルOS130のアプリケーション及び/またはグラフィクスコンテキストへの異環境間アクセスを提供することに関する。例えば、メニューアイテム2232、2234、2236、2237及び/または2238はモバイルOS130で利用可能なアプリケーション及び/またはモバイルOS130のグラフィクスコンテキストを示していてもよい。デスクトップOSのユーザ操作空間2202は、デスクトップOS160に関連するユーザ操作空間例えば、第二の端末環境840の中のディスプレイに表示される。デスクトップOS160のメニューバー2220には、デスクトップOS160のためにコンパイルされ、そこにロードされた例えば、Hydroid/Linuxのためにコンパイルされ、HydroidOSの実行環境内にロードされたアプリケーションに関連するメニューアイテム2222、2224、2226及び/または2228が含まれる。メニューバー2220はまた、モバイルOS130のためにコンパイルされ、そこにロードされた例えば、Androidのためにコンパイルされ、Androidの実行環境内にロードされたアプリケーションに関連するメニューアイテム2234、2236、2237及び/または2238が含まれる。ユーザがメニューアイテム2234、2236及び/または2238の1つを選択すると、関連するアプリケーションがモバイルOS130上で起動され、デスクトップOS160のコンソールウィンドウ内、例えばデスクトップOSのユーザ操作空間2202のウィンドウ2216の中に表示される。メニューアイテム2232は、モバイルOSグラフィクスコンテキストに関連付けられていてもよく、これによって、メニューアイテム2232が選択されると、モバイルOSのグラフィクスコンテキストがデスクトップOS160のコンソールウィンドウ内に表示される。図23は、デスクトップOS160のメニューバー2220を構築するために使用できるプロセスフロー2300を示す。プロセスフロー2300のステップ2302で、デスクトップOS160は、モバイルOS130に利用可能なアプリケーションのリストを問い合わせる。一実施形態において、デスクトップOS160のシステムサービスまたは起動アプリケーションは、モバイルOS130のサービスにすべての起動可能なモバイルOS用アプリケーションのショートカットを問い合わせる。モバイルOS130は、利用可能なアプリケーションのリストすなわち、利用可能なモバイルOS用アプリケーションの起動可能なショートカットを返す。利用可能なアプリケーションのリストには、モバイルOS130で利用可能なすべてのアプリケーションモバイルOS130にロードされ、実行可能なすべてのアプリケーションまたは、利用可能なモバイルOS用アプリケーションのサブセットが含まれていてもよい。例えば、リストには、モバイルOSGUIのアプリケーションメニュー画面上に現れるすべてのアプリケーションが含まれていてもよい。ステップ2304で、デスクトップOS160は、モバイルOS130からアプリケーションのリストを受け取る。モバイルOS130から返されたアプリケーションのリストには、リストに挙げられた各アプリケーションのアプリケーションパッケージ名が含まれ、また、リストに挙げられた各アプリケーションのアプリケーション名とアイコンが含まれていてもよい。デスクトップOS160は、メニューバー2220の中に、アプリケーションのリストの中の各アプリケーションのメニューアイテムを、ブロック2306、2308、2310を繰り返すことによって作成する。各アプリケーションについて、デスクトップOS160は、ブロック2306でメニューバー2220の中にアプリケーションのアイコンのインスタンスを作成し、ブロック2308でそのアイコンをデスクトップOS160のコンソールアプリケーションに関連付け、ブロック2310でそのアプリケーションのパッケージ名を示すパラメータをそのアイコンに関連付ける。コンソールアプリケーションはデスクトップOS160上で動作し、上述の異環境間レンダリングの実施形態を使って、デスクトップOS160内にそのアプリケーションに関するグラフィクス情報を表示する。このようにして、ユーザがメニューアイテムを選択すると、コンソールアプリケーションがデスクトップOS160上で動作し、そのアプリケーションのパッケージ名がコンソールアプリケーションに送られる。デスクトップOS160は、多様な方法で、モバイルOS130のアプリケーションに関連するメニューアイテムを表示してもよい。メニューアイテムは、メニューバー2220または、そのモバイルOS用アプリケーションが利用可能であることを示すメニューアイテムが選択された時に現れるドロップダウンメニューの中に表示されてもよい。メニューアイテムは、メニューバー2220またはドロップダウンメニューの中でアイコンまたはアプリケーション名のみを使って表示されてもよい。1つの実施形態において、デスクトップOS160は、モバイルOS用アプリケーションごとに別のメニューバーを表示する。他の実施形態では、モバイルOS用アプリケーションに関連するメニューアイテムが、デスクトップOS用アプリケーションのメニューアイテムに沿って、または混ざって、デスクトップOSのメニューバー2220の中に表示される。任意選択的に、モバイルOSのメニューアイテムは、メニューバー2220の中の、デリミタ2240によって仕切られた、またはその他の方法でモバイルOSのメニューアイテムが含まれることを特定できるようにされた領域2230の中に表示されてもよい。メニューバー2220は、モバイルデバイスそのもののアクティブディスプレイ用のメニューアイテム、すなわちユーザが、図20及び/または21の方法に従ってデスクトップOSのユーザ環境内でモバイルOSのユーザ操作空間を表示するために選択できるメニューアイテムを含んでいてもよい。1つの実施形態において、モバイルOSのホーム画面のアプリケーションは、利用可能なアプリケーションのリストの中に返され、関連するメニューアイテムが提供される。ユーザがモバイルOS用アプリケーションに関連するメニューアイテムを選択すると、デスクトップOS160がそのニューアイテムに関連するコンソールアプリケーションを起動させ、そのアプリケーションのパッケージ名をコンソールアプリケーションに送る。コンソールアプリケーションは、デスクトップOSのユーザ操作空間2202の中にウィンドウを1つ表示するすなわち、デスクトップOSのグラフィクスシステムの中のコンソールアプリケーションディスプレイ。コンソールアプリケーションは、モバイルOS130に、そのアプリケーションを起動させる要求を送りすなわち、モバイルOS130に対して、実行パラメータとしてコンソールアプリケーションに提供されたアプリケーションパッケージ名を起動するように要求し、コンソールアプリケーションを通じてそのアプリケーションに関するグラフィクスフレームを表示する。アプリケーションは、その時点でモバイルOS130で動作中であっても、そうでなくてもよい。アプリケーションがモバイルOS130上で動作中であれば、そのアプリケーションの表示はモバイルOS130からデスクトップOSのユーザ操作空間2202に移動されても、またはモバイルデバイスのディスプレイとユーザ操作空間2202の両方で同時に表示されてもよい。アプリケーショングラフィクスの表示とユーザ操作のサポートは、上述の異環境間レンダリングと異環境間ユーザインタフェースのサポートの方法の何れを使用したアプリケーションについても実行できる。図24は、ユーザがデスクトップOSのGUI880のメニューバー2220でモバイルOS用アプリケーションに関するメニューアイテムを選択したことに応答して、モバイルOS130がアプリケーションを起動させるために実行するプロセスフロー2400を示す。プロセスフロー2400はブロック2402で、モバイルOS130がデスクトップOS160から、モバイルOSのためにコンパイルされ、モバイルOSの実行環境内にロードされたアプリケーションを、デスクトップOSで表示するように起動させる要求を受け取ることから始まる。ブロック2404で、モバイルOSは使用されていない仮想ディスプレイIDを割り当てる。例えば、モバイルOSのグラフィクスシステムは、仮想ディスプレイIDのリストをつけておき、使用されていない仮想ディスプレイIDを第一のアプリケーションのプロセスに割り当ててもよい。ブロック2406で、モバイルOSはモバイルOS内で第一のアプリケーションを起動させるすなわち、モバイルOS上で動作中となる。ブロック2408で、モバイルOS130は、第一のアプリケーションに関するリフレッシュ通知を仮想ディスプレイに関連付ける。例えば、モバイルOSのグラフィクスサーバは、アプリケーションとそれに関連する仮想ディスプレイのリストをつけていてもよい。ブロック2410と2412で、モバイルOSは、第一のアプリケーションに関するアプリケーショングラフィクスをモニタし、第一のアプリケーションに関するアプリケーショングラフィクス情報が更新された時にデスクトップOSのコンソールアプリケーションに通知することによって、第一のアプリケーションに関するグラフィクス情報を維持する。ブロック2410と2412は、図10、12、16及び/または17の方法によって異環境間アプリケーションに関するアプリケーショングラフィクスを維持することに対応していてもよい。上記の説明は、例示と説明を目的としている。さらに、この説明は本発明の実施形態を本明細書で開示されている形態に限定することを意図していない。多数の例示的な態様と実施形態を上で説明したが、当業者であれば、そのいくつかの変更、改良、置換、追加、サブコンビネーションに気付くであろう。上述の方法の各種の操作は、それに対応する機能を果たすことのできる、どのような適当な手段で実行してもよい。この手段としては、各種のハードウェア及び/またはソフトウェアコンポーネント及び/またはモジュール等があり、これには回路、特定用途集積回路ASICまたはプロセッサが含まれるが、これらに限定されない。前述の種々の例示的な論理ブロック、モジュール、回路は、本明細書に記載の機能を実行するように設計された、汎用プロセッサ、デジタル信号プロセッサDSP、ASIC、フィールドプログラマブルゲートアレイ信号FPGAまたはその他のプログラム可能論理デバイスPLD、ディスクリートゲート、またはトランジスタロジック、ディスクリートハードウェアコンポーネントまたはこれらのどのような組合せにより実装または実行されてもよい。汎用プロセッサは、マイクロプロセッサであってもよく、あるいは、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラまたはステートマシンであってもよい。プロセッサまた、コンピューティングデバイスの組合せ、例えばDSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと併用される1つまたは複数のマイクロプロセッサ、またはその他の同様の構成として実装されてもよい。本明細書に関連して説明した方法またはアルゴリズムのステップは、ハードウェアで直接でも、プロセッサにより実行されるソフトウェアモジュールでも、またはこれら2つの組合せでも実施してよい。ソフトウェアモジュールは、どのような形態の有形記憶媒体の中に記憶されてもよい。使用できる記憶媒体の例としては、ランダムアクセスメモリRAM、リードオンリメモリROM、フラッシュメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM等がある。記憶媒体はプロセッサに、プロセッサがその記憶媒体から情報を読み出し、そこに情報を書き込むことができるように接続されてもよい。あるいは、記憶媒体はプロセッサに内蔵されてもよい。ソフトウェアモジュールは1つの命令でも、多くの命令でもよく、いくつかの異なるコードセグメント上で、異なるプログラム間で、及び複数の記憶媒体間で分散されていてもよい。本明細書に記載の方法は、記載された方法を実現するための1つまたは複数の動作を含む。この方法及び/または動作は、他の方法や動作と交換してもよく、特許請求の範囲から逸脱しない。換言すれば、動作の特定の順序が明示されていないかぎり、特定の動作の順序及び/または用途を変更でき、これも本特許請求の範囲から逸脱しない。説明した機能は、ハードウェア、ソフトウェア、ファームウェアまたはそれらの組合せによって実施してもよい。ソフトウェアで実行される場合、その機能は1つまたは複数の命令として有形のコンピュータ読取可能媒体に記憶されてもよい。記憶媒体は、コンピュータがアクセス可能な任意の利用可能な有形の記憶媒体であってもよい。例えば、これらに限定されないが、このようなコンピュータ読取可能媒体は、RAM、ROM、EEPROM、CD-ROMまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または、命令またはデータ構造の形態で所望のプログラムコードを担持または記憶するために使用可能であり、コンピュータによりアクセス可能な任意の有形の媒体であってもよい。本明細書において、ディスクdisk,discとは、コンパクトディスクCD、レーザーディスク登録商標、光ディスク、デジタル多用途ディスクDVD、フロッピー登録商標ディスク、Blu-ray登録商標ディスクを含み、diskは通常、磁気的にデータを再生するのに対し、discはレーザを使って光学的にデータを再生する。それゆえ、コンピュータプログラム製品が本明細書に記載された動作を実行してもよい。例えば、このようなコンピュータブログラム製品はコンピュータ読取可能な有形の媒体であってもよく、そこに命令が有形の状態で格納され及び/または暗号され、命令は1つまたは複数のプロセッサによって実行可能で、本明細書に記載された動作が行われる。コンピュータプログラム製品には、パッケージング材料が含まれていてもよい。ソフトウェアまたは命令はさらに、伝送媒体上で伝送されてもよい。例えば、ソフトウェアは、ウェブサイト、サーバまたは、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、デジタル加入者線DSL等の伝送媒体または、赤外線、無線またはマイクロ波等の無線技術を用いて他の遠隔提供源から伝送されてもよい。さらに、本明細書に記載された方法と方式を実行するためのモジュール及び/またはその他の適当な手段は、場合に応じてユーザ端末及び/または基地局によりダウンロードし、及び/またはその他の方法で取得することが可能である。例えば、このようなデバイスをサーバにつないで、本明細書に記載された方法を実行するための手段を伝送しやすくすることができる。あるいは、本明細書に記載された各種の方法は、記憶手段例えば、RAM、ROM、CDやフロッピーディスク等の物理的記憶媒体等を介して提供することができ、それによってユーザ端末及び/または基地局は、記憶手段をデバイスにつなぐか提供した時に、各種の方法を取得できる。さらに、本明細書に記載された方法と方式をデバイスに提供するために、他の適当な技術を利用することができる。その他の例及び実施例も、本明細書と付属の特許請求の範囲の範囲及び主旨の中に含まれる。例えば、ソフトウェアの性質から、上述の機能は、プロセッサ、ハードウェア、ファームウェア、ハードワイヤリングまたはそれらの組み合わせによって実行されるソフトウェアを使って実施できる。機能を実施する特徴はまた、様々な位置に物理的に配置されていてもよく、例えば、機能の各部分が異なる物理的場所で実行されるように分散される。また、特許請求の範囲を含む本明細書において、少なくともに続いて羅列される項目の中で使用されるまたはという用語は、離接的な一覧を示しており、例えば、少なくともA、BまたはCとは、AまたはBまたはCまたはABまたはACまたはBCまたはABCすなわち、AとBとCを意味する。さらに、例示的という用語は、説明された例が他の例より好ましい、またはよりよいこと意味しない。本明細書で説明した方式について、各種の変更、代替、改良を行うことができ、これも付属の特許請求の範囲により定義される教示内容の方式から逸脱しない。さらに、明細書と特許請求の範囲の範囲は、上述の工程、機械、製品、物体の組成、手段、方法、動作の特定の態様に限定されない。本明細書で説明したものと実質的に同じ機能を果たし、あるいはそれと実質的に同じ結果を達成する、既存の、または今後開発される工程、機械、製品、物体の組成、手段、方法または動作を利用してもよい。従って、付属の特許請求の範囲は、このような工程、機械、製品、物体の組成、手段、方法または動作をその範囲内に包含する。"