JP2013542515A - 異環境間リダイレクション - Google Patents

Abstract

仮想化されることなく共有カーネル上で同時に独立して動作するモバイルオペレーティングシステムとデスクトップオペレーティングシステムを有するモバイルコンピューティングデバイス。異環境間レンダリングは、モバイルオペレーティングシステムのレンダリングエンジンを用いて行なわれ、非拡張または拡張レンダリングコンテキストを作成し得る。透過的な異環境間使用モデルを容易にするために、モバイルオペレーティングシステムのアプリケーション及び／またはミラーリングされたコンテキストへの、デスクトップオペレーティングシステムに関連するユーザ環境からのアクセスが提供される。モバイルオペレーティングシステムのアプリケーション及び／またはミラーリングされたコンテキストへのアクセスは、デスクトップオペレーティングシステムのユーザ環境のメニュー内のメニューアイコンまたはメニューリストアイテムにより提供される。

Description

本願は、概して、モバイルコンピューティング環境の分野、より詳しくは、１つのモバイルコンピューティングデバイスにおいて複数のオペレーティングシステムの使用を通じた複数のユーザ環境をサポートすることに関する。

モバイルコンピューティングデバイスは、今日の社会において遍在化しつつある。例えば、２００８年末の時点で、米国人の９０パーセントがモバイル無線デバイスを有していた。同時に、モバイルデバイスの能力は急速に進化しており、その一例が、携帯電話機能とともに高度なコンピュータ機能も備えたスマートフォンである。モバイルプロバイダは、過去３年間に数種類のプラットフォームに基づく何百機種もの新型スマートフォンを発売した（例えば、Ａｐｐｌｅ ｉＰｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ、Ｐａｌｍ、Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ）。米国では、スマートフォンの普及率は２０１０年半ばまでに２３％近くに到達し、ある年齢層では３５％を超えた。欧州では、スマートフォン市場は２００９年から２０１０年の間に４１％成長し、２０１０年７月現在、欧州主要５カ国だけでも加入件数は６，０００万件以上に上った。

スマートフォンはますます人気を博し、コンピューティング能力も向上しつつあるが、それによって提供されるユーザ体験は限定的である。具体的には、これらは一般にモバイルデバイスのハードウェア用に変更されたオペレーティングシステムを搭載しており、変更されたオペレーティングシステムでは限られた数のアプリケーションしか利用できない。例えば、多くのスマートフォンはＧｏｏｇｌｅのＡｎｄｒｏｉｄオペレーティングシステムを実行する。Ａｎｄｒｏｉｄが実行できるのは、Ｊａｖａベースの仮想マシンランタイム環境内で動作するように特に開発されたアプリケーションだけである。これに加えて、Ａｎｄｒｏｉｄは変更されたＬｉｎｕｘカーネルに基づいているものの、Ｌｉｎｕｘとは異なる規格のＣライブラリ、システムマネージャ及びサービスを使用する。従って、Ｌｉｎｕｘ用に書かれたアプリケーションは、変更またはポートしないかぎり、Ａｎｄｒｏｉｄでは動作しない。同様に、ＡｐｐｌｅのｉＰｈｏｎｅではｉＯＳモバイルオペレーティングシステムが採用されている。この場合も、ｉＯＳはＭａｃ ＯＳ Ｘから派生しているが、ＯＳ Ｘ用に開発されたアプリケーションはｉＯＳでは動作しない。そのため、ＡｎｄｒｏｉｄやｉＯＳ等のモバイルオペレーティングシステムには多くのアプリケーションを利用できるが、ＬｉｎｕｘやＭａｃ ＯＳ Ｘ等、デスクトップオペレーティングシステム用の他の多数の一般的なアプリケーションは、モバイルプラットフォームでは利用できない。

従って、スマートフォンは一般に、限られた数のユーザ体験に適し、主にモバイル環境用に設計されたアプリケーションを提供する。特に、スマートフォンは、適当なデスクトップユーザ体験を提供せず、また、一般的なデスクトップアプリケーションを実行しない。その結果、多くのユーザはスマートフォン、ラップトップ、及び／またはタブレットコンピュータ等、複数のコンピューティングデバイスを持ち、使用する。この場合、デバイスごとにＣＰＵ、メモリ、ファイル記憶装置及びオペレーティングシステムが異なる。

スマートフォンと他のコンピューティングデバイスの間の接続とファイル共有を可能にするには、１つのデバイス（例えば、モバイルＯＳを実行するスマートフォン）を第二の、完全に異種のデバイス（例えば、デスクトップＯＳを実行するノートブック、デスクトップ、またはタブレット）に無線または有線接続を通じて連結する。情報はデバイス間で、各デバイスで別々に動作するアプリケーション間でデータを同期させることによって共有される。このプロセスは一般に「同期」と呼ばれ、面倒であり、通常、ユーザによる積極的な管理が必要となる。

本発明の実施形態は、１つのモバイルコンピューティングデバイスにおいて、スマートフォンのモバイルコンピューティング体験と第二の端末環境の適切なユーザ体験を提供することに関する。第二の端末環境は、有線（例えば、ＵＳＢ、Ｆｉｒｅｗｉｒｅ、Ｔｈｕｎｄｅｒｂｏｌｔ等）または無線（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ等）接続によりコンピューティングデバイスに接続された視覚的レンダリングデバイス（例えば、モニタやディスプレイ）、入力デバイス（例えば、マウス、タッチパッド、タッチスクリーン、キーボード等）、及びその他のコンピューティング周辺機器（例えば、ＨＤＤ、光ディスクドライブ、メモリスティック、カメラ、プリンタ等）のいくつかの組合せであってもよい。実施形態では、モバイル環境のユーザ体験に関連するモバイルオペレーティングシステムと第二の端末環境のユーザ体験に関連するデスクトップオペレーティングシステムが、共有カーネル上で同時に独立して動作する。

各種の実施形態と適合する１つの態様によれば、異環境間リダイレクションは、方法であって、第二の実行環境を有する第二のオペレーティングシステムによって、第一のオペレーティングシステムのためにコンパイルされ、第一のオペレーティングシステムの第一の実行環境内にロードされたアプリケーションのリストを第一のオペレーティングシステムに問い合わせることであって、第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、問い合わせること、第二のオペレーティングシステムにおいて、アプリケーションオブジェクトのリストを受け取ることであって、各アプリケーションオブジェクトがアプリケーションパッケージを含む、受け取ること、第二のオペレーティングシステムのメニューにおいて、アプリケーションオブジェクトのリストの中の１つのアプリケーションオブジェクトに対応する第一のメニューアイテムのインスタンスを作成すること、第一のメニューアイテムが、選択された時に、第二のオペレーティングシステムのコンソールアプリケーションを実行するように、第一のメニューアイテムを第二のオペレーティングシステムのコンソールアプリケーションに関連付けること、アプリケーションオブジェクトに対応する第一のＯＳの中のアプリケーションパッケージを示すパラメータを、第一のメニューアイテムに関連付けること含む、方法により提供される。

各種の実施形態と適合する他の態様によれば、第一のオペレーティングシステムの第一のグラフィクスサーバが、第二のオペレーティングシステムの第二のグラフィクスサーバと非互換的であってもよい。第一のグラフィクスサーバは、Ａｎｄｒｏｉｄ用グラフィクスサーバであってよく、第二のグラフィクスサーバは、Ｘウィンドウ型のグラフィクスサーバであってよい。第二のオペレーティングシステムのグラフィクスサーバがＸウィンドウ型のグラフィクスサーバであり、第一のオペレーティングシステムの、アプリケーションオブジェクトに対応するアプリケーションが、第二のオペレーティングシステムのＸウィンドウ型のグラフィクスサーバと非互換的なグラフィクスライブラリを使用してもよい。

各種の実施形態と適合する他の態様によれば、アプリケーションオブジェクトが、アプリケーション名、アプリケーションパッケージ名、およびアプリケーションアイコンを含んでもよい。第一のメニューアイテムが、選択されると、アプリケーションパッケージ名を実行パラメータとしてコンソールアプリケーションに送ってもよい。第二のオペレーティングシステムのメニューが、第二のアプリケーションに対応する第二のメニューアイテムを含み、第二のアプリケーションが第二の実行環境のためにコンパイルされ、第二の実行環境内にロードされていてもよい。第一のオペレーティングシステムがモバイルオペレーティングシステムを含んでもよく、第二のオペレーティングシステムがデスクトップオペレーティングシステムを含んでもよい。

各種の実施形態と適合する他の態様によれば、アプリケーションまたはグラフィクスコンテキストの異環境間リダイレクションのための方法であって、第一のオペレーティングシステムのためにコンパイルされ、第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを、第一のオペレーティングシステムにおいて起動させるための要求を、第一のオペレーティングシステムによって、第二のオペレーティングシステムから受け取ることであって、第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、受け取ること、第一のオペレーティングシステムによって仮想ディスプレイを割り当てること、第一のオペレーティングシステム内のプロセスにおいて第一のアプリケーションを起動させること、第一のアプリケーションのためのリフレッシュ通知を仮想ディスプレイに関連付けること、第一のアプリケーションのためのアプリケーショングラフィクスを、第一のオペレーティングシステムによって、第一のアプリケーションのアプリケーショングラフィクス情報をモニタするステップと、アプリケーショングラフィクス情報が更新された時に、第二のオペレーティングシステムのコンソールアプリケーションに通知するステップとを繰り返し実行することによって維持することを含む、方法が提供される。

各種の実施形態と適合する他の態様によれば、第二のオペレーティングシステムのコンソールアプリケーションに通知するステップが、ファイル記述子をコンソールアプリケーションに送ることを含んでよく、ファイル記述子は、アプリケーショングラフィクス情報が共有メモリ位置において利用可能であることを示しており、共有メモリ位置が第一のオペレーティングシステムと第二のオペレーティングシステムとによってアクセス可能である。ファイル記述子が、プロセス間通信チャネルを通じて送られてもよく、プロセス間通信チャネルは、Ｕｎｉｘドメインソケット、またはＢｉｎｄｅｒインタフェースであってよい。アプリケーショングラフィクス情報が、第一のアプリケーションのサーフェス情報を含んでよい。代替的に、アプリケーショングラフィクス情報が、第一のアプリケーションの、レンダリングされたグラフィクス情報を含んでもよい。第二のオペレーティングシステムが、ユーザが第二のオペレーティングシステムのメニューのメニューアイテムを選択したことに応答して、第一のアプリケーションを起動させる要求を発行してもよい。

各種の実施形態と適合する他の態様によれば、アプリケーションまたはグラフィクスコンテキストの異環境間リダイレクションのための方法であって、第一のオペレーティングシステムのためにコンパイルされ、第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを起動させる要求を、第一のオペレーティングシステムによって、第二のオペレーティングシステムのコンソールアプリケーションから受け取ることであって、第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、受け取ること、第一のオペレーティングシステム上の第一のプロセス内で第一のアプリケーションを実行することであって、第一のアプリケーションが、第一のオペレーティングシステムのサーフェスマネージャによって維持されるグラフィクス情報を含む、実行すること、第一のオペレーティングシステムによって、コンソールアプリケーションを第一のオペレーティングシステムの仮想ディスプレイ識別子に関連付けること、コンソールアプリケーションを登録して、第一のアプリケーションのグラフィクス情報に関するリフレッシュ通知を受け取ることを含む、方法が提供される。方法は、サーフェスマネージャにより、グラフィクスフレームを第一のオペレーティングシステムのフレームバッファメモリにレンダリングすること、第一のアプリケーションに関するグラフィクス情報が更新されたら、コンソールアプリケーションに通知することをさらに含み得る。

本発明の実施形態が図面の参照図に示されており、図の説明全体を通じて、同様の参照番号は同様の要素を指す。

各種の実施形態による、複数のユーザコンピューティング体験を提供するコンピューティング環境を示す図である。 各種の実施形態による、モバイルコンピューティングデバイスのための例示的なシステムアーキテクチャを示す図である。 各種の実施形態による、コンピューティング環境のためのオペレーティングシステムアーキテクチャを示す図である。 実施形態の各種の態様を利用する例示的なコンピューティング環境を示す図である。 各種の実施形態による、コンピューティング環境のためのオペレーティングシステムの態様を示す図である。 各種の実施形態による、モバイルコンピューティングデバイスのオペレーティングシステムアーキテクチャの構成に使用できる例示的なブート手順をより詳細に示す図である。 各種の実施形態による、アプリケーションの異環境間レンダリング及び／またはユーザ操作空間を提供するためのオペレーティングシステムアーキテクチャの構成を示す図である。 各種の実施形態による、複数のユーザ環境を備えるコンピューティング環境を示す図である。 各種の実施形態による異環境間リモートレンダリングの態様を示す図である。 各種の実施形態による、非拡張レンダリングコンテキストでの異環境間リモートレンダリングの例示的な方法のフロー図である。 各種の実施形態による、異環境間リモートレンダリングのための登録及び描画プロセスを示す図である。 各種の実施形態による、非拡張レンダリングコンテキストでの異環境間レンダリングの別の例示的な方法のフロー図である。 各種の実施形態による、異環境間アプリケーションのためのユーザ操作をサポートするオペレーティングシステムアーキテクチャ構成３００ｂを示す図である。 各種の実施形態による、非拡張グラフィクスコンテキストを用いてレンダリングされる異環境間アプリケーションに関するユーザ操作をサポートする態様を示す図である。 各種の実施形態による、拡張レンダリングコンテキストを用いた複数のＯＳ間での同時ユーザインタフェースをサポートする態様を示す図である。 各種の実施形態による、拡張レンダリングコンテキストでの異環境間リモートレンダリングの例示的な方法のフロー図である。 各種の実施形態による、拡張レンダリングコンテキストでの異環境間レンダリングの他の例示的な方法のフロー図である。 各種の実施形態による、拡張レンダリングコンテキストでの異環境間レンダリングに使用可能なユーザ環境を示す図である。 各種の実施形態による、拡張レンダリングコンテキストでの異環境間レンダリングに使用可能な拡張入力待ち行列を示す図である。 各種の実施形態による、拡張レンダリングコンテキストでの異環境間レンダリングに使用可能な入力イベントの受取方法を示す図である。 各種の実施形態による、ミラーリングされたコンテキストを提供するための異環境間レンダリングの例示的な方法のフロー図である。 各種の実施形態による、ミラーリングされたコンテキストを提供するための異環境間レンダリングの別の例示的な方法のフロー２１００を示す図である。 各種の実施形態による、異環境間リダイレクトの態様を示す図である。 各種の実施形態による、異環境間リダイレクトの態様を実行するために使用可能な例示的な方法のフロー図である。 各種の実施形態による、異環境間リダイレクトの態様を実行するために使用可能な他の例示的な方法のフロー図である。

コンピューティング能力を含む携帯電話機（すなわち、スマートフォン、ハンドセット、モバイルステーション、携帯通信機器等）の人気はますます高まっている。これらのスマートフォンの多くは、モバイルプロセッサ上で動作するモバイルオペレーティングシステム（「ＯＳ」）を含む。モバイルプロセッサとモバイルＯＳによってこれらのデバイスの能力は増大しているが、スマートフォンがデスクトップやノートブックコンピュータのようなパーソナルコンピュータ（「ＰＣ」）環境（すなわち、Ｗｉｎｄｏｗｓ、Ｍａｃ ＯＳ Ｘ、Ｌｉｎｕｘ）に取って代わる傾向は見られず、これは少なくとも提供されるユーザ体験が限られていることによる。特に、スマートフォンに見られるユーザインタフェースデバイスは一般に、モバイル環境に合わせて作られている。例えば、スマートフォンでは一般に、小さい親指式ＱＷＥＲＴＹキーボード、タッチスクリーンディスプレイ、クリックホイール、及び／またはスクロールホイールがユーザインタフェースデバイスとして使用される。モバイルＯＳのほか、モバイルＯＳ用に開発されたアプリケーション（すなわち、「アプリ」）は一般に、モバイルデバイス上にあるモバイルプロセッサとユーザインタフェースデバイスを含むモバイル環境の制約に合わせて設計されている。そのため、ＰＣオペレーティングシステム用に開発された多くのアプリケーションは、モバイルＯＳでは利用できない（すなわち、モバイルＯＳ用にはコンパイルされず、その上では動作しない）。これに加えて、文書の作成や編集等、一部の作業については、フルサイズのキーボードや大型ディスプレイのほうが、スマートフォンで一般的に見られるユーザインタフェースコンポーネントより使いやすい。

従って、ユーザは一般に、コンピューティング体験ごとに別のコンピューティングデバイス、例えばスマートフォン、タブレットコンピュータ、ラップトップコンピュータ及び／またはデスクトップコンピュータを使用する。この場合、デバイスによってＣＰＵ、メモリ、ファイル記憶装置、ＯＳが異なる。スマートフォンと他のデバイスの間の接続とファイル共有のためには、１つのデバイス（例えば、モバイルＯＳを実行するスマートフォン）を第二の、完全に異種のデバイス（例えば、デスクトップＯＳを実行するノートブック、デスクトップまたはタブレット）に、無線または有線接続を通じて連結する。情報はデバイス間で、各デバイスで別々に動作するアプリケーション間でデータを同期させることによって共有される。このプロセスは一般に「同期」と呼ばれ、面倒であり、通常、ユーザによる積極的な管理が必要となる。

図１は、各種の実施形態による、別々のユーザ操作空間（すなわち、ユーザ環境）に関連する複数のオペレーティングシステムを含む１つのモバイルデバイスで複数のユーザコンピューティング体験を提供するコンピューティング環境１００を示す。コンピューティング環境１００の第一のユーザ操作空間１１５には、モバイルコンピューティングデバイス１１０のディスプレイ１１６とＩ／Ｏデバイス１１８が含まれる。モバイルコンピューティングデバイス１１０が独立したモバイルデバイスとして操作されると、モバイルＯＳ １３０は、ユーザ操作空間１１５を通じて一般的なモバイルコンピューティングユーザ体験を提供する。モバイルＯＳ １３０によって提供されるモバイルコンピューティング体験には一般に、携帯電話機能や、ディスプレイ１１６とＩ／Ｏデバイス１１８とを含むユーザ操作空間１１５に適したグラフィカルユーザインタフェース（「ＧＵＩ」）が含まれる。例えば、ティスプレイ１１６はタッチスクリーンディスプレイであってもよく、モバイルＯＳ １３０上で動作するアプリケーションプログラム（すなわち、「アプリ」）は主として、タッチスクリーンディスプレイ１１６を用いたモバイルＯＳ １３０のジェスチャ認識ＧＵＩを通じて制御されてもよい。

コンピューティング環境１００の中で、モバイルコンピューティングデバイス１１０は、Ｉ／Ｏデバイス１４４、１４６及び／または１４８を含む第二の端末環境１４０とドッキングされてもよい。実施形態では、モバイルコンピューティングデバイス１１０は第二の端末環境１４０に、モバイルコンピューティングデバイス１１０のポート１２０を第二の端末環境１４０のポート１４２に接続することによってドッキングされている。この場合、第二の端末環境１４０はコンピューティング環境１００の第二のユーザ操作空間を提供する。いくつかの例において、第二のユーザ操作空間のほうがデスクトップコンピューティング体験により適していてもよい。このような場合、デスクトップＯＳ １６０を第二の端末環境１４０に関連付け、第二のユーザ操作空間を通じて、ノートブック、タブレットまたはデスクトップコンピュータ環境のすべての能力を提供することができる。

実施形態では、モバイルＯＳ １３０とデスクトップＯＳ １６０は、モバイルコンピューティングデバイス１１０のプロセッサの共有カーネル上で同時に動作する。共有カーネルでのモバイルＯＳとデスクトップＯＳの同時動作は、２０１１年８月２４日に出願された、“ＭＵＬＴＩ−ＯＰＥＲＡＴＩＮＧ ＳＹＳＴＥＭ”と題する米国特許出願第１３／２１７，１０８号明細書においてより詳しく説明されており、同出願を参照によって本願に援用する。このように、１つのモバイルコンピューティングデバイスは、第一のユーザ操作空間を通じたモバイルコンピューティング体験と第二のユーザ操作空間を通じたデスクトップコンピューティング体験を提供できる。別々のユーザ操作空間を通じて複数のオペレーティングシステムを同時に実行可能な１台のモバイルデバイスを携帯できることは、ユーザにとっての多くの問題を解決するが、（同時動作するモバイルＯＳとデスクトップＯＳを通じた）各ユーザ操作空間により通常提供される利用可能なアプリケーションとユーザ機能の集合は、それぞれ異なる。

本発明の実施形態は、第一のＯＳ（例えば、モバイルＯＳ １３０）で動作するアプリケーションを、見かけ上、第二のＯＳ（例えば、デスクトップＯＳ １６０）の中で実行しやすくすることに関し、この場合、第一と第二のＯＳは共有のカーネル上で同時動作中である。特に、ユーザに第一の（例えば、非互換的な）ＯＳのためにコンパイルされ、その中で動作するアプリケーションに関する、第二のＯＳにおける入力（例えば、入力デバイス）と出力（例えば、ディスプレイ、オーディオ等）をサポートする中で、多くの問題がアドレスされる。同時動作中の複数のアプリケーションの表示と双方向性に対処する場合は、また別の問題も発生し得る。

例えば、第一と第二のアプリケーションがどちらも第一のＯＳのためにコンパイルされ、第一のＯＳ上で同時動作中である場合を考える。しかしながら、ユーザは、一方のＯＳに関連する入力／出力デバイスを通じて（例えば、モバイルコンピューティング環境のタッチスクリーンディスプレイを使って）第一のアプリケーションのグラフィクス出力を見て、その第一のアプリケーションを操作し、また第二のＯＳに関連する入力／出力デバイスを通じて（例えば、デスクトップコンピューティング環境のディスプレイ、キーボード、マウスを使って）第二のアプリーションのグラフィクス出力を見て、その第二のアプリケーションを操作したいと望む。このようなシナリオに対処するには、複数のディスプレイ環境でのグラフィクスの同時操作と、異なるアプリケーションに関する複数の入力／出力ストリームの同時処理を、すべて別々の（例えば、非互換性の）オペレーティングシステム上で行う必要がある。

従って、実施形態は、第二のＯＳのユーザ操作空間内で第一のＯＳのアプリケーションにアクセスし、第二のＯＳのユーザ操作空間内で第一のＯＳで実行中のアプリケーションを表示し、第二のＯＳのユーザ操作空間を通じてこれらのアプリケーションのユーザ操作を扱うための各種の新規な方式を提供する。実施形態は、異環境間アプラケーションの各種のディスプレイとユーザ操作機能をサポートする第二のＯＳのコンソールアプリケーションを含む。

１つの実施形態群は、いわゆる「非拡張」レンダリングコンテキストを使って、複数のＯＳによるコンピューティング環境間の同時ユーザインタフェースをサポートするための技術を提供する。別の実施形態群は、いわゆる「拡張」レンダリングコンテキストを使って、複数のＯＳによるコンピューティング環境間の同時ユーザインタフェースをサポートするための技術を提供する。また別の実施形態群は、いわゆる「ミラーリングされた」コンテキストを使って、複数のＯＳによるコンピューティング環境間の同時ユーザインタフェースをサポートするための技術を提供する。さらに別の実施形態群は、第二のＯＳのユーザ操作空間から第一のＯＳ上で利用可能なアプリケーションにアクセスできるようにする。これらの実施形態群の各々を、以下により詳しく説明する。

前述のように、コンピューティング環境１００は、複数のオペレーティングシステムを同時に実行しているモバイルデバイスに関連する複数のユーザ操作空間を通じて、複数のユーザコンピューティング体験を提供する。具体的には、モバイルコンピューティングデバイス１１０が、各々特定のコンピューティング環境に適した複数のＯＳを含んでいるため、モバイルコンピューティングデバイス１１０を、１つのモバイルコンピューティングデバイスで様々なユーザ体験を提供するための外部Ｉ／Ｏデバイスに適合させてもよい。例えば、ユーザは、モバイルコンピューティングデバイス１１０と、キーボード、ディスプレイ及び／またはポインティングデバイスをラップトップ型筐体の中に有する第二の端末環境１４０を有し得る。モバイルコンピューティングデバイス１１０がこのラップトップ型の第二の端末環境にドッキングされると、デスクトップＯＳ １６０のすべての機能が第二の端末環境１４０を通じて利用可能となる。

図２は、各種の実施形態による、モバイルコンピューティングデバイス１１０のためのハードウェアシステムアーキテクチャの一例を示す。モバイルコンピューティングデバイスハードウェア１１２は、１つまたは複数のＣＰＵコア２０４と外部ディスプレイインタフェース２２０を内蔵するモバイルプロセッサ１１４を含む。通常、モバイルコンピューティングデバイスハードウェア１１２はまた、Ｉ／Ｏデバイス１１８、メモリ２０６、記憶デバイス２０８、タッチスクリーンディスプレイ１１６に接続されたタッチスクリーンディスプレイコントローラ２１０、バッテリ２１６に接続された電源管理ＩＣ ２１４、セルラーモデム２１８、通信デバイス２２２及び／または、各種の通信信号やインタフェースを通じてプロセッサ１１４に接続されたその他のデバイス２２４を含む。Ｉ／Ｏデバイス１１８は通常、ボタン及び、モバイルコンピューティングデバイス１１０で使用可能なその他のユーザインタフェースコンポーネントを含む。例えば、Ｉ／Ｏデバイス１１８は、１組のボタン（例えば、後退、メニュー、ホーム、検索等）、オフスクリーンジェスチャエリア、クリックホイール、スクロールホイール、ＱＷＥＲＴＹキーボード等を含んでいてもよい。その他のデバイス２２４は、例えばＧＰＳデバイス、ＬＡＮ接続、マイクロフォン、スピーカ、カメラ、加速度計及び／またはＭＳ／ＭＭＣ／ＳＤ／ＳＤＩＯカードインタフェース等であってもよい。外部ディスプレイインタフェース２２０は、何れの適当なディスプレイインタフェース（例えば、ＶＧＡ、ＤＶＩ、ＨＤＭＩ等）であってもよい。

プロセッサ１１４は、ＡＲＭベースのモバイルプロセッサであってもよい。実施形態では、モバイルプロセッサ１１４は、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ ＯＭＡＰ３４３０、Ｍａｒｖｅｌｌ ＰＸＡ３２０、Ｆｒｅｅｓｃａｌｅ ｉＭＸ５１、またはＱｕａｌｃｏｍｍ ＱＳＤ８６５０／８２５０等のモバイルＡＲＭベースプロセッサである。しかしながら、モバイルプロセッサ１１４は、他の好適なＡＲＭベースのモバイルプロセッサや、別のプロセッサアーキテクチャ、例えばｘ８６ベースのプロセッサアーキテクチャまたはその他のＲＩＳＣベースのプロセッサアーキテクチャ等に基づくプロセッサであってもよい。

図２はモバイルコンピューティングデバイス１１０の１つの例示的なハードウェア実装１１２を示しているが、これ以外のアーキテクチャも本発明の範囲内として考えられる。例えば、図２ではモバイルプロセッサ１１４の外部に示されている各種のコンポーネントは、モバイルプロセッサ１１４の中に統合してもよい。任意選択的には、図２にモバイルプロセッサ１１４に統合された状態で示されている外部ディスプレイインタフェース２２０は、モバイルプロセッサ１１４の外にあってもよい。これに加えて、システムバス、ディスクリートグラフィクスプロセッサ及び／またはその他のアーキテクチャ面の変化形を使用する、他のコンピュータアーキテクチャも、本発明の態様を利用するのに適している。

図３は、各種の実施形態による、モバイルコンピュータデバイス１１０でモバイルＯＳ １３０とデスクトップＯＳ １６０を同時に実行するために利用可能なＯＳアーキテクチャ３００を示す。図３に示されるように、モバイルＯＳ １３０とデスクトップＯＳ １６０は、独立したオペレーティングシステムである。具体的には、モバイルＯＳ １３０とデスクトップＯＳ １６０は、相互に独立した、非互換的なユーザライブラリ、グラフィクスシステム及び／またはフレームワーク層を有していてもよい。ＯＳアーキテクチャ３００のための機能と命令は、モバイルコンピューティングデバイス１１０の有形のコンピュータ読取可能媒体上にコンピュータプログラムコードとして記憶されていてもよい。例えば、ＯＳアーキテクチャ３００のための命令は、モバイルコンピューティングデバイスハードウェア１１２の記憶デバイス２０８の中に記憶されていてもよい。

ＯＳアーキテクチャ３００において、モバイルＯＳ １３０とデスクトップＯＳ １６０は、共有カーネル３２０で同時に動作する。これは、モバイルＯＳ １３０とデスクトップＯＳ １６０が共有カーネル３２０上で同じ時点で動作中であることを意味する。具体的には、モバイルＯＳ １３０とデスクトップＯＳ １６０はどちらも、同じカーネルインタフェース３２２を通じて、例えば共有カーネル３２０にシステムコールを行うことによって、共有カーネル３２０とインタフェースする。共有カーネル３２０は、モバイルＯＳ １３０とデスクトップＯＳ １６０の両方のプロセスに関するタスクスケジューリングを管理する。この点で、モバイルＯＳ １３０とデスクトップＯＳ １６０は、共有カーネル３２０で独立して、同時に動作中である。これに加えて、共有カーネル３２０は、ハードウェアインタフェース３１２により示されているように、直接、モバイルコンピューティングデバイスハードウェア１１２のモバイルプロセッサ１１４で動作する。具体的には、共有カーネル３２０はモバイルコンピューティングデバイスハードウェア１１２のコンピューティングリソース、例えばＣＰＵスケジューリング、メモリアクセス、Ｉ／Ｏを直接管理する。この点で、ハードウェアリソースは仮想化されず、すなわち、モバイルＯＳ １３０とデスクトップＯＳ １６０は、仮想化されたメモリまたはＩ／Ｏアクセスを使用せずに、カーネルインタフェース３２２を通じてシステムコールを行う。

図３に示されるように、モバイルＯＳ １３０は、ライブラリ層３３０、アプリケーションフレームワーク層３４０、アプリケーション層３５０を有する。モバイルＯＳ １３０では、アプリケーション３５２と３５４が、モバイルＯＳ １３０のアプリケーションフレームワーク層３４０によってサポートされるアプリケーション層３５０の中で動作する。アプリケーションフレームワーク層３４０には、モバイルＯＳ １３０上で動作するアプリケーションにより使用されるマネージャ３４２とサービス３４４が含まれる。例えば、アプリケーションフレームワーク層３４０には、ウィンドウマネージャ、アクティビティマネージャ、パッケージマネージャ、リソースマネージャ、電話マネージャ、ジェスチャコントローラ及び／または、モバイル環境のためのその他のマネージャとサービスが含まれていてもよい。アプリケーションフレームワーク層３４０には、モバイルＯＳ １３０のために開発されたアプリケーションを実行するモバイルアプリケーションランタイム環境が含まれていてもよい。モバイルアプリケーションランタイム環境は、より低い処理能力及び／または限られたメモリスペース等、モバイルコンピューティングリソースに合わせて最適化されていてもよい。モバイルアプリケーションランタイム環境では、プロセス分離、メモリ管理、スレッディングサポートがカーネルに依存して行われてもよい。ライブラリ層３３０には、Ｉ／Ｏとストリング操作等の一般的な機能、グラフィクス機能、データベース能力、通信能力及び／またはその他の機能や能力を実行するユーザライブラリ３３２が含まれる。

図３に示されているように、デスクトップＯＳ １６０は、ライブラリ層３６０、フレームワーク層３７０、アプリケーション層３８０を有する。デスクトップＯＳ １６０では、アプリケーション３８２と３８４が、デスクトップＯＳ １６０のアプリケーションフレームワーク層３７０によってサポートされるアプリケーション層３８０の中で動作する。アプリケーションフレームワーク層３７０には、デスクトップＯＳ １６０上で動作するアプリケーションにより使用されるマネージャ３７２とサービス３７４が含まれる。例えば、アプリケーションフレームワーク層３７０には、ウィンドウマネージャ、アクティビティマージャ、パッケージマネージャ、リソースマネージャ及び／または、デスクトップ環境に一般的なその他のマネージャとサービスが含まれていてもよい。ライブラリ層３６０には、Ｉ／Ｏとストリング操作等の一般的な機能、グラフィクス機能、データベース能力、通信能力及び／またはその他の機能や能力を実行するユーザライブラリ３６２が含まれていてもよい。

本発明の各種の実施形態において、デスクトップＯＳ １６０は、モバイルＯＳ １３０とは別の実行環境で動作する。例えば、モバイルＯＳ １３０はルート実行環境で動作してもよく、デスクトップＯＳ １６０は、ルート実行環境下で確立された第二の実行環境で動作してもよい。モバイルＯＳ １３０上で動作するプロセスとアプリケーションは、ルート実行環境の中でユーザライブラリ３３２、マネージャ３４２及びサービス３４４にアクセスする。デスクトップＯＳ １６０上で動作するプロセスとアプリケーションは、第二の実行環境の中で、ユーザライブラリ３６２、マネージャ３７２及びサービス３７４にアクセスする。

実施形態では、モバイルＯＳ １３０とデスクトップ１６０は、非互換性のユーザライブラリ、グラフィクスシステム及び／またはアプリケーションフレームワークを有する独立したオペレーティングシステムである。従って、モバイルＯＳ １３０のために開発されたアプリケーションは、直接、デスクトップＯＳ １６０では動作できず、デスクトップＯＳ １６０のために開発されたアプリケーションは、直接、モバイルＯＳ １３０上では動作できない。例えば、モバイルＯＳ １３０のアプリケーション層３５０で動作するアプリケーション３５２は、デスクトップＯＳ １６０と非互換的であってもよく、すなわち、アプリーション３５２をデスクトップＯＳ １６０で実行できない。具体的には、アプリケーション３５２は、デスクトップＯＳ １６０のマネージャ３７２、サービス３７４及び／またはライブラリ３６２では利用できない、またはこれらと互換性のないモバイルＯＳ １３０のマネージャ３４２、サービス３４４及び／またはライブラリ３３２に依存していてもよい。

その結果、モバイルＯＳ １３０とデスクトップＯＳ １６０で利用できるアプリケーションの集合はそれぞれ異なっていてもよい。この点で、ＯＳアーキテクチャ３００のモバイルＯＳ １３０とデスクトップＯＳ １６０は、別々のユーザ操作空間からアクセス可能な別々のアプリケーション集合を通じて、別々のユーザ体験を提供する。ユーザは、モバイルＯＳ １３０に関連する第一のユーザ操作空間を通じて、モバイルＯＳ １３０上で利用可能な（すなわち、そのためにコンパイルされ、その実行環境内にロードされた）アプリケーションにアクセスし、デスクトップＯＳ １６０に関連する第二のユーザ操作空間を通じて、デスクトップＯＳ １６０上で利用可能なアプリケーションにアクセスしてもよい。

前述のように、モバイルオペレーティングシステムは一般に、デスクトップオペレーティングシステムと同じグラフィクス環境を使用しない。デスクトップＯＳ用のグラフィクス環境は、フレキシビリティと高性能性のために設計された。例えば、一部のデスクトップＯＳで使用されるＸウィンドウシステムは、処理及びシステムリソースをより多く使用することと引き換えに、プラットフォームとネットワークの独立性を提供する。これに対して、モバイルＯＳ用のグラフィクス環境の設計は、効率性とモバイルコンピューティング環境の特定のユーザ入力デバイスのほうにより重点を置き、フレキシビリティはそれより軽視されている。モバイル及びデスクトップＯＳのグラフィクス環境は異なることが多いため、モバイルＯＳ上で動作するアプリケーションは、モバイルＯＳのグラフィクスサーバからデスクトップＯＳのグラフィクスサーバにグラフィクス情報をリダイレクトすることによって、デスクトップＯＳのユーザ空間内で表示されるようにリダイレクトできない。

最も広く採用されているモバイルＯＳはＧｏｏｇｌｅのＡｎｄｒｏｉｄである。ＡｎｄｒｏｉｄはＬｉｎｕｘに基づいているが、モバイル環境とモバイルプロセッサのために、カーネル及びその他のＯＳ層に変更が加えられている。特に、ＬｉｎｕｘカーネルはＰＣ（すなわち、ｘ８６）ＣＰＵアーキテクチャ用に設計されているが、ＡｎｄｒｏｉｄカーネルはＡＲＭベースのモバイルプロセッサに合わせて変更されている。Ａｎｄｒｏｉｄデバイスドライバはまた、タッチスクリーン、モバイル接続（ＧＳＭ／ＥＤＧＥ、ＣＤＭＡ、Ｗｉ−Ｆｉ等）、バッテリ管理、ＧＰＳ、加速度計及びカメラモジュール等、モバイルハードウェアアーキテクチャの中に一般的にあるデバイスやその他のデバイスに特に合わせて作られている。これに加えて、ＡｎｄｒｏｉｄはネイティブのＸ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍを持っていなければ、フルセットの標準ＧＮＵライブラリもサポートしておらず、これによって、既存のＧＮＵ／ＬｉｎｕｘアプリケーションまたはライブラリをＡｎｄｒｏｉｄにポートすることが難しい。

ＡｐｐｌｅのｉＯＳオペレーティングシステム（ｉＰｈｏｎｅで動作）とＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ Ｐｈｏｎｅ ７も同様に、モバイル環境とモバイルハードウェアアーキテクチャ用に変更されている。例えば、ｉＯＳはＭａｃ ＯＳ ＸデスクトップＯＳから派生しているが、一般的なＭａｃ ＯＳ Ｘ用アプリケーションは、ｉＯＳ上ではネイティブとして動作しない。具体的には、ｉＯＳ用アプリケーションは、標準開発キット（「ＳＤＫ」）を通じて、ｉＯＳの「Ｃｏｃｏａ Ｔｏｕｃｈ」ランタイム環境で動作するように開発されており、これによってタッチベースの入力、プッシュ通知及びシステムサービス等の重要なｉＯＳ機能のための基本的なアプリケーションインフラストラクチャとサポートが提供される。そのため、Ｍａｃ ＯＳ Ｘのために書かれたアプリケーションは、ポートしないとｉＯＳで動作しない。これに加えて、Ｍａｃ ＯＳ Ｘ用アプリケーションをｉＯＳにポートすることは、２つのＯＳ間のユーザライブラリ及び／またはアプリケーションフレームワークの違い、及び／またはモバイルとデスクトップハードウェアのシステムリソースの違いによって、難しいかもしれない。

ＯＳアーキテクチャ３００に適合する１つの実施形態において、ＡｎｄｒｏｉｄモバイルＯＳとフルＬｉｎｕｘ ＯＳは、変更されたＡｎｄｒｏｉｄカーネル上で独立して、同時に動作する。この実施形態では、Ａｎｄｒｏｉｄ ＯＳは変更型Ａｎｄｒｏｉｄディストリビューションであってもよく、その一方で、Ｌｉｎｕｘ ＯＳ（「Ｈｙｄｒｏｉｄ」）は変更型Ｄｅｂｉａｎ ＬｉｎｕｘデスクトップＯＳであってもよい。図４〜６は、各種の実施形態による、ＯＳアーキテクチャ３００で使用可能なＡｎｄｒｏｉｄモバイルＯＳ ４３０、Ａｎｄｒｏｉｄカーネル５２０、Ｈｙｄｒｏｉｄ ＯＳ ６６０をより詳細に示す。

図４に示されるように、Ａｎｄｒｏｉｄ ＯＳ ４３０は、ライブラリ層４３２の中にＣ／Ｃ＋＋ライブラリの集合を含み、これらはアプリケーションフレームワーク層４４０を通じてアクセスされる。ライブラリ層４３２には、「ｇｌｉｂｃ」Ｌｉｎｕｘ Ｃライブラリより小型で高速となるようにＡｎｄｒｏｉｄのために特に開発された「ｂｉｏｎｉｃ」システムＣライブラリ４３９が含まれる。ライブラリ層４３２にはまた、プロセス間通信（ＩＰＣ）ライブラリ４３６が含まれ、これにはＡｎｄｒｏｉｄ ＯＳの「Ｂｉｎｄｅｒ」ＩＰＣメカニズムの基本クラスが含まれる。Ｂｉｎｄｅｒは特にＡｎｄｒｏｉｄのために、プロセス間及びサービス間の通信を可能にするために開発された。図４のライブラリ層４３２に示されている他のライブラリとしては、媒体フォーマットの記録と再生をサポートするメディアライブラリ４３５、ディスプレイサブシステムへのアクセスを管理し、複数のアプリケーションからのグラフィクス層を合成するサーフェスマネージャ４３４、２Ｄ及び３Ｄグラフィクスエンジン４３８、軽量リレーショナルデータベースエンジン４３７がある。ライブラリ層４３２に含めることができるが、図４には示されていないその他のライブラリには、ビットマップ及びベクトルフォントレンダリングライブラリ、ユーティリティライブラリ、ブラウザツール（すなわち、ＷｅｂＫｉｔ等）及び／または秘匿通信ライブラリ（すなわち、ＳＳＬ等）がある。

Ａｎｄｒｏｉｄ ＯＳ ４３０のアプリケーションフレームワーク層４４０は、開発者がデバイスハードウェアのコンポーネントを使用し、位置情報にアクセスし、背景サービスを実行し、アラームをセットし、ステイタスバーに通知を加えること等を可能にする開発プラットフォームを提供する。フレームワーク層４４０により、アプリケーションがその能力を公開し、他のアプリケーションの公開された能力を利用することも可能となる。ＡｎｄｏｒｏｉｄモバイルＯＳ ４３０のアプリケーションフレームワーク層４４０のコンポーネントは、アクティビティマネージャ４４１、リソースマネージャ４４２、ウィンドウマネージャ４４３、ドックマネージャ４４４、ハードウェア及びシステムサービス４４５、デスクトップモニタサービス４４６、マルチディスプレイマネージャ４４７及びリモート通信サービス４４８を含む。ＡｎｄｒｏｉｄモバイルＯＳ ４３０のフレームワーク層４４０に含めることのできるその他のコンポーネントには、ビューシステム、電話マネージャ、パッケージマネージャ、位置マネージャ及び／または通知マネージャのほか、その他のマネージャとサービスがある。

Ａｎｄｒｏｉｄ ＯＳ ４３０で動作するアプリケーションは、Ａｎｄｒｏｉｄオブジェクト指向アプリケーションフレームワークの上のＡｎｄｒｏｉｄランタイム環境４３３のＤａｌｖｉｋ仮想マシン４３１の中で動作する。Ｄａｌｖｉｋ仮想マシン４３１はレジスタベースの仮想マシンであり、メモリ使用量と処理要求を削減するために設計されたコンパクトな実行可能フォーマットを実行する。Ａｎｄｒｏｉｄ ＯＳ ４３０で動作するアプリケーションには、ホーム画面４５１、電子メールアプリーション４５２、写真アプリケーション４５３、ブラウザアプリケーション４５４、及び／またはその他のアプリケーション（「アプリ」）４５５がある。

Ａｎｄｒｏｉｄ ＯＳグラフィクスシステムは、クライアント／サーバモデルを使用する。サーフェスマネージャ（「ＳｕｒｆａｃｅＦｌｉｎｇｅｒ」）はグラフィクスサーバであり、アプリケーションはクライアントである。ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、ディスプレイＩＤのリストを維持し、ディスプレイＩＤへのアプリケーションの割当を常に追跡する。１つの実施形態では、モバイルコンピューティングデバイス１１０は複数のタッチスクリーンディスプレイ１１６を有する。この実施形態において、ディスプレイＩＤ ０がタッチスクリーンディスプレイ１１６の１つに関連付けられ、ディスプレイＩＤ １が他方のタッチスクリーンディスプレイ１１６に関連付けられる。ディスプレイＩＤ ２は両方のタッチスクリーンディスプレイ１１６に関連付けられる（すなわち、このアプリケーションが両方のディスプレイで同時に表示される）。２より大きいディスプレイＩＤは仮想ディスプレイであり、すなわち、これらはモバイルコンピューティングデバイスハードウェア１１２の上に物理的に存在するディスプレイには関連付けられない。

Ａｎｄｒｏｉｄアプリケーション用のグラフィクス情報には、ウィンドウ、ビュー、及びキャンバスがある。各ウィンドウ、ビュー及び／またはキャンバスには、基本となるサーフェスオブジェクトが含められる。サーフェスオブジェクトは、２つのバッファ（フロント及びバックバッファ）に格納され、描画のためのプロセス間で同期される。ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、すべてのサーフェスを共通のメモリプールの中に維持し、これによって、Ａｎｄｒｏｉｄ内のすべてのプロセスがこれらにアクセスし、その中に描画することができ、コストのかかるコピー動作が不要となり、またＸウィンドウ等のサーバ側の描画プロトコルを使用する必要もない。アプリケーションは、ＳｕｒｆａｃｅＦｌｉｎｇｅｒがフロントバッファから読み出している間は常にバックバッファの中に描画する。ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、各サーフェスオブジェクトを作成し、すべてのサーフェスオブジェクトを維持し、また、各アプリケーションに関するサーフェスオブジェクトリストを維持する。アプリケーションは、バックバッファへの描画を完了すると、ＳｕｒｆａｃｅＦｌｉｎｇｅｒにイベントをポストし、これがバックバッファをフロントバッファにスワップして、サーフェス情報をフレームバッファにレンダリングする作業を待ち行列に入れる。

ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、すべてのウィンドウ変更イベントをモニタする。１つまたは複数のウィンドウ変更イベントが発生すると、ＳｕｒｆａｃｅＦｌｉｎｇｅｒはサーフェス情報を１つまたは複数のディスプレイのためのフレームバッファにレンダリングする。レンダリングには、サーフェスを合成すること、すなわちサーフェスの寸法、透明度、Ｚオーダ、可視性に基づいて最終的な画像フレームを構成することが含まれる。レンダリングはまた、ハードウェア加速（例えば、グラフィクス処理ハードウェアのためのＯｐｅｎＧＬ ２Ｄ及び／または３Ｄインタフェース）を含んでいてもよい。ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、すべてのサーフェスオブジェクトをループさせて、それらのフロントバッファをそのＺオーダでフレームバッファにレンダリングする。

図５は、各種の実施形態による変更型Ａｎｄｒｏｉｄカーネル５２０をより詳しく示す。変更型Ａｎｄｒｏｉｄカーネル５２０には、タッチスクリーンディスプレイドライバ５２１、カメラドライバ５２２、Ｂｌｕｅｔｏｏｔｈドライバ５２３、共有メモリアロケータ５２４、ＩＰＣドライバ５２５、ＵＳＢドライバ５２６、ＷｉＦｉドライバ５２７、Ｉ／Ｏデバイスドライバ５２８及び／または電源管理モジュール５３０が含まれる。Ｉ／Ｏデバイスドライバ５２８には、ポート１２０を通じてモバイルコンピューティングデバイス１１０に接続可能な外部Ｉ／Ｏデバイスのためのデバイスドライバが含まれる。変更型Ａｎｄｒｏｉｄカーネル５２０には、ｌｏｗ ｍｅｍｏｒｙ ｋｉｌｌｅｒ、カーネルデバッガ、ログ機能及び／またはその他のハードウェアデバイスドライバを含むその他のドライバや機能ブロックが含まれていてもよい。

図６は、各種の実施形態によるＨｙｄｒｏｉｄ ＯＳ ６６０をより詳しく示す。ＨｙｄｒｏｉｄはフルＬｉｎｕｘ ＯＳであり、標準的なＬｉｎｕｘディストリビューション用に開発されたほとんどすべてのアプリケーションを実行できる。特に、Ｈｙｄｒｏｉｄ ＯＳ ６６０のライブラリ層６６２には、ネットワーキング、グラフィクス処理、データベース管理及びその他の一般的なプログラム機能をサポートするＬｉｎｕｘライブラリが含まれる。例えば、ユーザライブラリ６６２には、「ｇｌｉｂｃ」Ｌｉｎｕｘ Ｃライブラリ６６４、Ｌｉｎｕｘグラフィクスライブラリ６６２（例えば、ＧＴＫ、ＯｐｅｎＧＬ等）、Ｌｉｎｕｘユーティリティライブラリ６６１、Ｌｉｎｕｘデータベースライブラリ、及び／またはその他のＬｉｎｕｘユーザライブラリが含まれていてもよい。アプリケーションは、Ｈｙｄｒｏｉｄ上では、Ｘサーバ６７４、ウィンドウマネージャ６７３及び／またはデスクトップ環境６７２を用いてＸ Ｗｉｎｄｏｗ Ｌｉｎｕｘグラフィカル環境内で動作する。図のアプリケーションには、ワードプロセッサ６８１、電子メールアプリケーション６８２、スプレッドシートアプリケーション６８３、ブラウザ６８４及びその他のアプリケーション６８５が含まれている。

Ｌｉｎｕｘ ＯＳグラフィクスシステムは、Ｘウィンドウ（または「Ｘ１１」）グラフィクスシステムに基づいている。Ｘウィンドウは、プラットフォームに依存しないネットワーク式のグラフフィクスフレームワークである。Ｘウィンドウはクライアント／サーバモデルを利用しており、Ｘサーバがグラフィクスサーバ、アプリケーションがクライアントである。Ｘサーバは、ディスプレイ、タッチスクリーンディスプレイ、キーボード、ポインティングデバイス等、Ｌｉｎｕｘ ＯＳに関連する入力／出力ハードウェアを制御する。この点で、Ｘウィンドウはサーバ側の描画グラフィクスアーキテクチャを提供し、すなわち、Ｘサーバがウィンドウやピクセルマップを含むＤｒａｗａｂｌｅのためのコンテンツを維持する。ＸクライアントはＸサーバと、通信チャネル上で描画動作を説明するデータパケットを交換することによって通信する。Ｘクライアントは、標準ルーチンのライブラリ（「Ｘｌｉｂ」）を通じてＸ通信プロトコルにアクセスする。例えば、ＸクライアントはＸサーバに対し、クライアントウィンドウに三角形を描画するように要求を送信してもよい。ＸサーバはＸクライアントに入力イベント、例えばキーボードまたはポインティングデバイスの入力、及び／またはウィンドウの移動またはリサイジングを送信する。入力イベントはクライアントウィンドウに関連しており、例えば、ユーザがあるウィンドウ内にあるポインタをクリックすると、Ｘサーバはその入力イベントを含むパケットを、そのウィンドウに関連するＸクライアントに送り、その中にはそのウィンドウに関係のあるイベントの動作と位置が含まれる。

オペレーティングシステムのフレームワーク、グラフィクスシステム及び／またはライブラリの違いによって、Ａｎｄｒｏｉｄ用に書かれたアプリケーションは通常、Ｈｙｄｒｏｉｄ ＯＳ ６６０では動作せず、標準的なＬｉｎｕｘディストリビューション用に書かれたアプリケーションは通常、Ａｎｄｒｏｉｄ ＯＳ ４３０では動作しない。この点に関して、Ａｎｄｒｏｉｄ ＯＳ ４３０とＨｙｄｒｏｉｄ ＯＳ ６６０のためのアプリケーションにはバイトコード互換性がなく、すなわち、一方のためにコンパイルされた実行可能なプログラムは、他方では動作しない。

１つの実施形態において、Ｈｙｄｒｏｉｄ ＯＳ ６６０は、共有カーネル５２０を通じてＡｎｄｒｏｉｄ ＯＳ ４３０との通信を容易にする異環境間通信フレームワークのコンポーネントを含む。これらのコンポーネントとしては、Ａｎｄｒｏｉｄ ＯＳのＢｉｎｄｅｒ ＩＰＣメカニズムのための基本クラスと遠隔通信サービス６７１を含むＩＰＣライブラリ６６３がある。

１つの実施形態において、Ｈｙｄｒｏｉｄ ＯＳ ６６０は、Ａｎｄｒｏｉｄルート環境内で作られた、ｃｈｒｏｏｔされた（「ｃｈｒｏｏｔ」コマンドで作られた）第二の実行環境の中で実行される。Ｈｙｄｒｏｉｄ ＯＳ ６６０の中のプロセスとアプリケーションは、第二の実行環境の中で、これらのプロセスとアプリケーションから見た見かけ上のルートディレクトリが第二の実行環境のルートディレクトリとなるように実行される。このようにして、Ｈｙｄｒｏｉｄ ＯＳ ６６０は、標準Ｌｉｎｕｘディストリビューションのために書かれたプログラムを変更せずに実行でき、それは、ｃｈｒｏｏｔされた第二の実行環境においてＨｙｄｒｏｉｄ ＯＳ ６６０上で実行されるプロセスにＬｉｎｕｘユーザライブラリ６６２を利用できるからである。

図３に戻ると、モバイルＯＳ １３０とデスクトップ１６０は、モバイルデバイスの共有カーネル３２０上でアクティブに同時動作中である。モバイルＯＳ １３０とデスクトップＯＳ １６０は、ユーザライブラリ、グラフィクスシステム及び／またはアプリケーションフレームワークに関して非互換的であってもよい。そのため、モバイルＯＳ １３０とデスクトップＯＳ １６０で利用可能なアプリケーションの集合はそれぞれ異なり、すなわち、モバイルＯＳ １３０上で利用可能な少なくとも一部のアプリケーションはデスクトップＯＳ １６０では利用できず、またその逆でもある。従って、ＯＳアーキテクチャ３００のモバイルＯＳ １３０とデスクトップＯＳ １６０は、別々のユーザ操作空間からアクセス可能な別々のアプリケーション集合を通じて、別々のユーザ体験を提供する。ユーザは、モバイルＯＳ １３０に関連するユーザ操作空間を通じてモバイルＯＳ １３０上で利用可能な（すなわち、そのためにコンパイルされ、その実行環境内にロードされた）アプリケーションにアクセスし、デスクトップＯＳ １６０に関連するユーザ操作空間を通じてデスクトップＯＳ １６０上で利用可能なアプリケーションにアクセスしてもよい。

本発明の実施形態は、ＯＳアーキテクチャ３００の機能性を拡張して、複数のＯＳに基づくコンピューティング環境における、よりシームレスなコンピューティング体験を提供する。実施形態には、第二のオペレーティングシステムのユーザ操作空間内におけるアプリケーション及び／または第一のオペレーティングシステムのユーザ操作空間の異環境間レンダリングが含まれ、これは第一と第二のオペレーティングシステムのグラフィクス環境に互換性がなくても行われる。実施形態にはさらに、異環境間アプリケーションのためのユーザ操作のサポートと、第二のオペレーティングシステムのユーザ操作空間からの第一のオペレーティングシステムのアプリケーションへのアクセスが含まれる。この機能によって、例えば、モバイルＯＳ １３０上で動作するモバイルＯＳ用アプリケーションを、デスクトップＯＳ １６０に関連するユーザ操作空間を通じて表示し、操作することが可能となる。例えば、ユーザがデスクトップＯＳ １６０に関連するユーザ操作空間を通じてデスクトップＯＳ １６０を操作している間に、そのユーザは、デスクトップＯＳ １６０では利用できない（すなわち、そのためにコンパイルされておらず、そこでは実行されない）モバイルＯＳ １３０の特定のアプリケーションにアクセスしたいと希望してもよい。後述の各種の実施形態を用いれば、ユーザは、デスクトップＯＳ １６０に関連するユーザ操作空間を通じて、モバイルＯＳ １３０のためにコンパイルされ、その上で実行されるアプリケーションにアクセスし、これを表示し、操作できる。特に、実施形態は、モバイルＯＳの何れのアプリケーションでの異環境間操作もサポートしており、すなわち、モバイルＯＳ用アプリケーションを下記の実施形態を使用するのに、特定の異環境間サポートを含めるように変更する必要がない。

第二のＯＳ（例えば、デスクトップＯＳ １６０）のユーザ操作空間内からアプリケーション及び／または第一のＯＳ（例えば、モバイルＯＳ １３０）のユーザ操作空間への、シームレスな異環境間ユーザ操作をサポートするために、アプリケーション及び／またはユーザ操作空間のグラフィクスデータ（すなわち、グラフィクスコンテキストまたはアクティブディスプレイ）を、第二のＯＳのユーザ操作空間の中にリアルタイムで表示されるようにレンダリングすることが望ましいかもしれない。リアルタイム（または即時）レンダリングとは、この文脈において、アプリケーションのグラフィクスデータが第二のＯＳのユーザ操作空間に十分に素早くレンダリングされ、グラフィクス情報の伝送に伴う遅延によってアプリケーションのパフォーマンスに気付くほどの、または実質的な低下を発生させずに、ユーザがそのアプリケーションを操作できることを意味する。この点に関して、本明細書に記載されているようなリアルタイム（または即時）異環境間レンダリングの技術により、例えばグラフィクス情報が迅速に転送され、第一のＯＳから第二のＯＳにグラフィクス情報をコピーまたは転送することに伴うフレーム遅延やその他の遅延が減る。しかしながら、これはグラフィクスの転送にまったく時間がかからないことを意味するのではなく、本明細書に記載の異環境間レンダリング方式は、グラフィクス情報が第二のＯＳのユーザ操作空間上で表示されるまでに限定的な時間がかかったとしても、即時またはリアルタイムとみなしてよい。

アプリケーションの異環境間レンダリングを実現するために、第一のオペレーティングシステムで動作中のアプリケーションから第二のオペレーティングシステムのグラフィクスシステムに、おそらく大量のグラフィクスデータが転送されることがある。既存のメカニズムでは、必要なグラフィクスデータを転送すると、ディスプレイの更新またはフレームレートに必ず影響が及ぶ。例えば、グラフィクスデータを直接転送することは、モバイルコンピューティング環境の制約の中では現実的ではないであろう。圧縮技術を使って転送データの総量を減らすことは可能であるが、その代わりに、情報の圧縮と解凍に必要な処理が増える。リモートのデスクトップ型システムを使って、ベクトルグラフィクスやグラフィクス更新情報を送ることはできるが、この場合もまた一般に、大量のグラフィクスデータを転送する際、またはグラフィクスコンテンツの急速な変化の際に速度が低下する。

図７は各種の実施形態によるＯＳアーキテクチャ構成３００ａを示し、これは第二のＯＳのユーザ操作空間内でアプリケーション及び／または第一のＯＳのユーザ操作空間を異環境間レンダリングするために使用でき、この場合、第一と第二のＯＳは共有カーネル上で同時動作中であり、別々のディスプレイデバイスを含む別々のユーザ操作空間に関連付けられている。ＯＳアーキテクチャ構成３００ａのコンポーネントにより、モバイルＯＳ １３０上で動作するアプリケーションとモバイルＯＳ １３０のグラフィクスコンテキストを、デスクトップＯＳ １６０のユーザ操作空間内にレンダリングすることができ、ＯＳ １３０とデスクトップＯＳ １６０は共有カーネル３２０上で同時動作する。各種の実施形態において、アプリケーションは、デスクトップＯＳ １６０のコンソールアプリケーション７８２を通じて、デスクトップＯＳ １６０のユーザ操作空間内のコンソールウィンドウに表示される。１つの実施形態において、コンソールアプリケーション７８２は、Ｘウィンドウ型アプリケーションであり、これはデスクトップＯＳ １６０のＸウィンドウ型グラフィクスシステムを通じてデスクトップＯＳ １６０のユーザ操作空間内に表示される。

ＯＳアーキテクチャ構成３００ａにおいて、モバイルＯＳ １３０には、グラフィクスサーバ７３４が含まれ、これはモバイルＯＳ １３０のアプリケーション（例えば、アプリケーション７５２と７５４）に関するサーフェス情報（例えば、サーフェス７２６、７２７、７２８）の割当と管理を行う。１つの実施形態において、グラフィクスサーバ７３４は、匿名共有メモリ（すなわち、そのカーネルを解放できるプロセス間で共有される名前付きメモリブロック）を使ってグラフィクスサーフェスのメモリを割り当てる。グラフィクスサーバ７３４はまた、モバイルＯＳ １３０のディスプレイの割当と追跡も行い、これにはモバイルコンピューティングデバイスハードウェア１１２（すなわち、ローカルディスプレイ）に内蔵されるディスプレイと、モバイルＯＳ １３０が遠隔的に（すなわち、他のＯＳのユーザ操作空間内で）表示されるかもしない、いわゆる仮想ディスプレイが含まれる。モバイルＯＳ １３０はまた、モバイルＯＳ １３０に関連するディスプレイ画面上に同時に複数のアプリケーションを表示するためのウィンドウシステムを含んでいてもよい。１つの実施形態において、モバイルＯＳ １３０には、デスクトップＯＳ １６０からモバイルＯＳ １３０のコンポーネントにアクセスするための遠隔通信チャネルを提供するサービスが含まれる。

ＯＳアーキテクチャ構成３００ａには、モバイルＯＳ １３０上で動作中であり、モバイルＯＳ １３０に関連する第一のユーザ操作空間内に表示される第一のアプリケーション７５２が含まれる。ＯＳアーキテクチャ構成３００ａには、やはりモバイルＯＳ １３０上で動作中であるが、後述の実施形態による異環境間レンダリングを通じて、デスクトップＯＳ １６０に関連する第二のユーザ操作空間内に表示される第二のアプリケーション７５４が含まれる。１つの実施形態において、アプリケーション７５４は、デスクトップＯＳ １６０上で動作するコンソールアプリケーション７８２を通じて第二のユーザ操作空間のコンソールウィンドウ内に表示される。

通常、モバイルＯＳ １３０のアプリケーションは、ユーザがアプリケーションを操作する際に使用するビューのインスタンスを作成する。例えば、アプリケーションは、アプリケーションウィンドウを構成する１つのビューを有し得る。ビューの中で、アプリケーションは、アプリケーションインタフェースの特定の領域に関する描画オブジェクトのインスタンスを作る。描画オブジェクトは、キャンバスまたは描画層と呼ばれることがあり、アプリケーションがグラフィクス情報を描画する際に使用するオブジェクトである。アプリケーションがキャンバスまたは層のインスタンスを作成すると、グラフィクスサーバ７３４がそのキャンバスまたは層に関連するサーフェス情報にメモリを割り当て、その描画オブジェクトをアプリケーションに戻し、すると、アプリケーションがこれを使ってキャンバスまたは層のサーフェスに関するグラフィクス情報を描画する。その後、グラフィクスサーバ７３４はサーフェス情報をモニタし、サーフェス情報が更新されると、このサーフェス情報をフレームバッファ（例えば、フレームバッファ７１６）にレンダリングする。一般に、ユーザはまた、ビューオブジェクトを通じてアプリケーションを操作する。ビューンオブジェクトはイベントリスナを含み、これは、ユーザがそのビューオブジェクトに対して動作を起こした際に、モバイルＯＳの入力待ち行列７３６によりコールされる。

ＯＳアーキテクチャ３００ａに示されているように、サーフェス７２６、７２７及び／または７２８は、グラフィクスサーバ７３４によって共有メモリ７２４に割り当てられる。共有メモリ７２４は、共有カーネル３２０によって管理され、モバイルＯＳ １３０とデスクトップＯＳ １６０上で動作中のすべてのプロセスによりアクセス可能である。前述のように、共有メモリ７２４は名前付き共有メモリであってもよい。名前付き共有メモリは、共有カーネル３２０上で動作中のすべてのプロセスによってアクセス可能であるが、それ以外のプロセスは名前によって名前付き共有メモリの領域にアクセスすることができない。従って、名前付き共有メモリの各領域に関するファイル記述子を、プロセス間通信メカニズムを通じて送り、プロセスの境界を越えて名前付き共有メモリを参照できるようにしなければならない。共有カーネル３２０にはまた、ＩＰＣドライバ７２５が含まれ、これによって、モバイルＯＳ １３０とデスクトップＯＳ １６０の中のプロセスはプロセスの境界を越えて相互に通信できる。ＩＰＣドライバ７２５は、例えば、Ｕｎｉｘドメインソケットドライバ、Ａｎｄｒｏｉｄ Ｂｉｎｄｅｒドライバ、及び／またはネットワークソケットドライバであってもよい。

ＯＳアーキテクチャ構成３００ａのデスクトップＯＳ １６０には、コンソールアプリケーション７８２とウィンドウシステム７７４が含まれる。コンソールアプリケーション７８２は、デスクトップＯＳ １６０のためにコンパイルされ、その上で動作し、デスクトップＯＳ １６０に関連するユーザ操作空間のコンソールウィンドウの中に表示される。ウィンドウシステム７７４には、ウィンドウマネージャ、グラフィクスサーバ及び／または、グラフィクスオブジェクトを表現し、デスクトップＯＳフレームバッファ７１８を通じてこれらをディスプレイデバイスに転送するための基盤となるグラフィクスデバイスインタフェースが含まれる。例えば、ウィンドウシステム７７４は、デスクトップＯＳフレームバッファ７１８を通じて、デスクトップＯＳ １６０のユーザ操作空間内にコンソールアプリケーション７８２を表示してもよい。ウィンドウシステム７７４はまた、コンソールアプリケーション７８２に関連するデスクトップＯＳ １６０のユーザ環境からの入力イベントをコンソールアプリケーション７８２に提供する。例えば、ウィンドウシステム７７４は、デスクトップＯＳ １６０に関連するユーザ操作空間からのポインティングデバイスの位置またはジェスチャ情報をコンソールアプリケーション７８２に提供してもよい。

図７において、共有メモリ７２４、モバイルＯＳフレームバッファ７１６、デスクトップＯＳフレームバッファ７１８を含むメモリブロックが、わかりやすいように、共有カーネル３２０の中にあるように示されている。しかしながら、これらのメモリブロックは、モバイルコンピュータデバイス１１０の有形のメモリ要素の中に物理的に設置され、共有カーネル３２０によって管理される。例えば、これらのメモリブロックは、図２に示されるように、プロセッサ１１４のＲＡＭの中、及び／またはモバイルコンピューティングデバイスハードウェア１１２のメモリデバイス２０６のＲＡＭの中に設置されてもよい。

ＯＳアーキテクチャ構成３００ａは、第二のオペレーティングシステムに関連するユーザ操作空間内に共有カーネル上で動作中の第一のオペレーティングシステムのアプリケーションを異環境間レンダリングすることをサポートし、この場合、第一と第二のオペレーティングシステムは共有カーネル上で同時動作中である。ＯＳアーキテクチャ構成３００ａは、複数のユーザ操作空間を通じて複数のユーザコンピューティング体験を提供するコンピューティング環境における異環境間レンダリングをサポートするために使用してもよい。例えば、ＯＳアーキテクチャ構成３００ａは、図１に示されるようなコンピューティング環境１００の中で使用してもよい。

図８は、各種の実施形態によるコンピューティング環境８００を示す。コンピューティング環境８００は、モバイルコンピューティングデバイスハードウェア１１２のタッチスクリーンディスプレイ１１６とその他のＩ／Ｏデバイス１１８を含む第一のユーザ環境を有する。このユーザ環境は第一のユーザ操作空間を提供し、ユーザはここからモバイルＯＳ １３０を操作する。コンピューティング環境８００の第二のユーザ環境は、ディスプレイモニタ８４４、キーボード８４６及び／またはポインティングデバイス８４８を含む。ユーザ環境８４０は、ドックコネクタ８４１とドックケーブル８４３を通じて、モバイルコンピューティングデバイス１１０に接続されてもよい。ドックコネクタ８４１とドックケーブル８４３は、図１に示されるように、ドックインタフェース１２２を通じてモバイルコンピューティングデバイス１１０のポート１２０とインタフェースするポートを含んでいてもよい。この点に関して、ユーザ環境８４０は、モバイルコンピューティングデバイス１１０に対して、ドッキングされた第二の端末環境を提供する。コンピューティング環境８００において、デスクトップＯＳ １６０はドッキングされた第二の端末環境８４０に関連付けられてもよく、これによって、ユーザは第二の端末環境８４０によって提供されるユーザ操作空間を通じてデスクトップＯＳ １６０を操作できる。第二の端末環境８４０は、一般的なデスクトップ型コンピューティング環境として示されているが、デスクトップＯＳ １６０は、他のタイプのコンピューティング環境、例えばラップトップ、タブレット及び／またはその他のタイプのコンピューティング環境を通じて第二のユーザ操作空間を提供してもよい。

ＯＳアーキテクチャ構成３００ａをコンピューティング環境８００で使用して、第一のＯＳ（すなわち、モバイルＯＳ）上で動作し、第二のＯＳのユーザ環境（すなわち、デスクトップＯＳ １６０に関連するユーザ環境８４０）の中に表示されるアプリケーションの異環境間レンダリングを提供してもよい。例えば、モバイルＯＳ １３０上で動作中のアプリケーション７５４は、デスクトップＯＳ １６０のユーザ操作空間８８０のコンソールウィンドウ８８２の中に表示されてもよい。ウィンドウ８８４と８８６を含む、ユーザ操作空間８８０内のその他のウィンドウは、デスクトップＯＳ １６０で動作中の他のアプリケーションのウィンドウであってもよい。ユーザに対しては、コンピューティング環境８００はアプリケーション７５４に関するシームレスなコンピューティング体験を提供し、これは、アプリケーション７５４がデスクトップＯＳ １６０のユーザ操作空間の中で、実際にはアプリケーション７５４はモバイルＯＳ １３０で動作しているが、デスクトップＯＳ １６０上で実行されているかのように使用できるからである。

図８は、デスクトップ型の第二の端末環境８４０を示している。この例では、ユーザは、第二の端末環境８４０のキーボード８４６とマウス８４８を使うことにより、コンソールウィンドウ８８２を通じて（すなわち、主としてポインティングデバイスに基づくＧＵＩ）、モバイルＯＳのアプリケーション及び／またはユーザ操作空間を操作してもよい。しかしながら、アプリケーションの異環境間レンダリング及び／またはモバイルＯＳユーザ操作空間のミラーリングを、他の第二の端末環境で使用してもよい。例えば、デスクトップＯＳ １６０は、タッチスクリーンディスプレイを含むタブレット型の第二の端末環境に関連付けることができる。この場合、ユーザは、ユーザが一般的にモバイルＯＳ １３０のユーザ操作空間を操作するのとほとんど同じ方法で（すなわち、主としてジェスチャベースのＧＵＩ）、モバイルＯＳ １３０の異環境間アプリケーションまたはミラーリングされたユーザ操作空間を操作してもよい。

前述のように、本発明の実施形態は、複数のＯＳに基づくコンピューティング環境において、異環境間アプリケーション及び／またはミラーリングされたユーザ操作空間のユーザによる同時インタフェースをサポートすることに関する。一例において、ユーザインタフェースのサポートは、異環境間アプリケーションのために提供され、それによって第一のＯＳ上で動作中のアプリケーションを、実質的にもともと第二のオペレーティングシステム上で動作しているかのように、第二のＯＳのユーザ操作空間を通じて表示し、操作することができる。
非拡張レンダリングコンテキストによる実施形態
いくつかの実施形態は、第一のオペレーティングシステムのグラフィクスレンダリングコンテキストを拡張せずに、複数のＯＳにわたる同時ユーザインタフェースをサポートすることに関する。第一のＯＳ（例えば、モバイルＯＳであるＡｎｄｒｏｉｄ）は一般に、単独の、アクティブなユーザ操作空間となるように構成される。このユーザ操作空間には、アクティブディスプレイ（例えば、解像度等、関連する特徴を有する）と、ユーザがアクティブディスプレイ上で表示される要素を操作できるような１つまたは複数のアクティブ入力デバイスが含まれる。従って、第一のＯＳは、アクティブディスプレイに表示するために実行されるアプリケーションに関するサーフェス情報をレンダリングする際に使用できるレンダリングコンテキストを作成する。

しかしながら、前述のように、本明細書には同時に使用中の複数のユーザ操作空間中に第一のＯＳを有効にフーリングするための新規の技術が記載される。さらに、この技術によれば、複数のユーザ操作空間を、複数のコンピューティング環境上の異なる（例えば、非互換性の）オペレーティングシステムに関連付けることが可能となる。いくつかの実施形態には、異環境間リモートレンダリングを通じてディスプレイ出力を処理するための技術が関わる。その他の実施形態は、このような場合のユーザの操作を扱うための技術に関する。

異環境間リモートレンダリングにおいて、第一のＯＳ上で動作し、第二のＯＳに関連するコンピューティング環境内で表示されるアプリケーションに関するアプリケーショングラフィクスは、第二のＯＳ内からレンダリングされる。１つの実施形態において、第二のＯＳ上で動作中のコンソールアプリケーションは、共有メモリからのそのアプリケーションに関するサーフェス情報にアクセスし、第二のＯＳに関連するコンピューティング環境のコンソールウィンドウ内にこのアプリケーションをレンダリングする。

カレンダアアプリケーションとワードプロセシングアプリケーションがどちらもモバイルデバイス上の第一のＯＳ（例えば、モバイルＯＳ １３０）用にコンパイルされ、同時動作していると仮定する。第二のＯＳ（例えば、デスクトップＯＳ １６０のようなノンモバイルＯＳ）が共有カーネルを使ってモバイルデバイス上で同時に動作している。ユーザは、モバイルデバイスを第二の、デスクトップコンピューティング環境にドッキングしており、このデスクトップコンピューティング環境を通じてワートプロセシングアプリケーションを操作したいと望んでいる。モバイルコンピューティング環境（すなわち、モバイルデバイス）の第二のＯＳを使って、デスクトップコンピューティング環境のユーザ操作空間を、ユーザにとってよくわかる方法で扱うことが望ましい。

図９は、各種の実施形態による異環境間リモートレンダリングの態様を示す。図９に示されるアプリケーションレンダリングの概略図９００において、第一のアプリケーション９１０（例えば、カレンダアプリケーション）は第一のＯＳ内の第一のサーフェス９１２に関する更新を計算する。第一のサーフェス９１２は、第一のオペレーティングシステムによって共有メモリ空間内の第一のメモリ位置に格納される。例えば、第一のメモリ位置は、名前付きの共有メモリの１領域であってもよい。第一のアプリケーション９１０は、第一のサーフェス９１２のバックバッファ９１４を更新する。同様に、第二のアプリケーション９３０（例えば、ワードプロセシングアプリケーション）は、第一のＯＳを使って、第二のサーフェス９３２の更新を計算する。第二のサーフェス９３２は、第一のＯＳによって共有メモリ空間の第二のメモリ位置（例えば、名前付きの共有メモリの第二の領域）に格納される。

第一のＯＳは、いつレンダリングシーケンスを開始するか判断する。例えば、第一のＯＳは、サーフェス９１２及び／または９３２に関するサーフェス情報が変更された時にレンダリングシーケンスを開始してもよい。第一のＯＳは、特定のアプリケーションに関連するサーフェス情報が変化したかどうかを判断し、第一のサーフェス９１２と第二のサーフェス９３２を含むすべてのサーフェスについて１ループを実行してもよい。レンダリングシーケンスの中で、サーフェス９１２に関するサーフェス情報が変化すると、第一のＯＳはフロントバッファ９１６とバックバッファ９１４をスワップして、バックバッファ９１４の中にあったサーフェス情報が今度はフロントバッファ９１６にあるようにする。第一のオペレーティングステムは、第一のサーフェス９１２を第三のメモリ位置９２０にレンダリングして、第一のＯＳに関連する第一のユーザ操作空間内で表示されるべき最終画像９１８を作る。

第二のサーフェス９３２に関するサーフェス情報が変化すると、第一のＯＳは第二のＯＳに対し、第二のサーフェス９３２に関するサーフェス情報が変化したことを通知する。具体的には、第一のＯＳは第二のＯＳのコンソールアプリケーションに対し、サーフェス９３２がアップデートされたことを示す描画通知を、プロセス間通信チャネルを通じて送信する。描画通知は、フロント画像９３６のファイル記述子及び／またはフロント画像９３６のための共有メモリ空間に関するその他の特徴、例えばバッファの大きさ、層の順序等を含んでいてもよい。コンソールアプリケーションは、ファイル記述子をそのプロセス空間にマッピングして、第二のメモリ位置の参照を取得する。第二のメモリ位置の参照を通じて、第二のＯＳのコンソールアプリケーションは、フロント画像バッファ９３６からサーフェス情報を直接読み出し、第二のサーフェス９３２のフロント画像９３６に関するサーフェス情報を、第二のＯＳに関連する第二のユーザ操作空間内のコンソールウィンドウ９４０にレンダリングする。このようにして、コンソールアプリケーションは、第二のアプリケーション９３０をリアルタイムでコンソールウィンドウ９４０の中にレンダリングすることができ、プロセス間でグラフィクスフレームまたはサーフェス情報をコピーすることは不要となる。その代わりに、コンソールアプリケーションは、プロセス間通信を通じて送られたファイル記述子を使って、第二のサーフェス９３２の共有メモリをそれ自身のプロセス空間にマッピングすることにより、サーフェス情報を直接読み出す。

図１０は、各種の実施形態による、非拡張レンダリングコンテキストでの異環境間リモートレンダリングの例示的方法のフロー１０００を示す。実施形態では、どちらも第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに同時動作中の第一のアプリケーション（例えば、カレンダアプリケーション）と第二のアプリケーション（例えば、ワードプロセシングアプリケーション）のアプリケーショングラフィクスの表示が維持される。

方法１０００はブロック１００４で、第一のオペレーティングシステムを使って第一のアプリケーションのサーフェスの更新を計算することから始まる。サーフェスの更新の計算では、アプリケーションデータを使って、どのサーフェスがどのように変化したかが判断される。例えば、ユーザの操作により、いくつかのサーフェスが位置、順序（例えば、１つの層が部分的に他の層の前にあっても、他の層により完全に隠れていても、その他でもよい）、大きさ、色、テクスチャ等が変化した可能性がある。

ブロック１００８で、第一のアプリケーションのこれらの更新後のサーフェスが、第一のオペレーティングシステムを使ってレンダリングされ、第一のメモリ位置に第一のグラフィクスフレームが生成される。例えば、第一のＯＳのレンダリングエンジンはそれ以前に、ディスプレイに関連するレンダリングコンテキストを作成した。すると、グラフィクスフレームは、更新されたサーフェス情報を繰り返し処理することによってレンダリングし、そのレンダリングコンテキストに関連するディスプレイの特徴（例えば、解像度）に従って、第一のアプリケーションから見えるサーフェス部分の全体または部分画像が有効に描画される。このグラフィクスフレームは第一のメモリ位置にレンダリングされる。メモリ位置は、フレームバッファメモリ、共有メモリ、またはその他の有益なメモリ位置とすることができる。

いくつかの実施形態において、ブロック１０１２では、レンダリングされた第一のグラフィクスフレームが、第一のメモリ位置から第一のオペレーティングシステムに関連する第一のコンピューティング環境のディスプレイに表示される。例えば、第一のグラフィクスフレームは、モバイルデバイスのフレームバッファのバックバッファ部分にレンダリングされる。その後、フレームバッファが反転し（すなわち、バックバッファ部分がフロントバッファ部分となる）、フレームバッファの、新たにフロントになったバッファ部分がモバイルデバイスのディスプレイに表示される。

ブロック１０１６で、第一のオペレーティングシステムを使って、第二のアプリケーションのサーフェスの更新が計算される。これは、ブロック１００４の第一のアプリケーションのサーフェスに関する計算と実質的に同じように行われてもよい。しかしながら、第一のアプリケーションの更新後のサーフェスデータと異なり、第二のアプリケーションの更新後のサーフェス情報は第一のＯＳではレンダリングされない。そうではなく、ブロック１０２０で、第二のアプリケーションの更新後のサーフェスは第二のメモリ位置に格納される。第二のメモリ位置は、モバイルデバイスの共有カーネル上で同時動作中の第一と第二のＯＳの両方によりアクセス可能な共有メモリ位置である。

ブロック１０２４で、第二のアプリケーションの更新後のサーフェスは、第二のオペレーティングシステムのコンソールアプリケーションを使ってレンダリングされ、第三のメモリ位置の中に第二のグラフィクスフレームが生成される。例えば、図７のコンソールアプリケーション７８２は、アプリケーション７５４の更新後のサーフェスを第二のＯＳのフレームバッファメモリ（例えば、第二のコンピューティング環境のディスプレイに関連付けられている）にレンダリングしてもよい。いくつかの実施形態において、ブロック１０２８で、第二のグラフィクスフレームは、第三のメモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティング環境のディスプレイに表示される。例えば、デスクトップコンピューティング環境のディスプレイドライバは、そのフレームバッファメモリにアクセスし、第二のグラフィクスフレームにアクセスしてこれを表示する。特定の実施例においては、コンソールアプリケーションがコンソール操作空間を有し、第二のグラフィクスフレームがコンソール操作空間の中にレンダリングされる。例えば、コンソールアプリケーションは、デスクトップディスプレイ上に１つまたは複数のウィンドウをレンダリングし、第二のアプリケーションのグラフィクスがこれらのウィンドウの１つに表示される。

いくつかの実施形態において、方法１０００はブロックを繰り返し処理して、両方のアプリケーションのグラフィクス環境を同時に維持する。例えば、モバイルＯＳは、第一のアプリケーションのグラフィクスの更新を計算して、これらの更新をモバイルフレームバッファメモリにレンダリングする。その後、モバイルＯＳは第二のアプリケーションのグラフィクスの更新を計算し、これらの更新を共有メモリに格納し、そこから、デスクトップＯＳのコンソールアプリケーションがこれらの更新をデスクトップのフレームバッファメモリにレンダリングする。その後、方法１０００が次の一連の更新について繰り返される。特にいくつかの実施例は、特定のステップを異なる順序で、及び／または並行して行う。例えば、第一と第二のアプリケーションのサーフェスの更新を実質的に同時に計算することも可能である（すなわち、ブロック１００４と１０１６を実質的に並行して行う）が、これらの更新後のサーフェスは、一部だけがローカルでレンダリングされ（例えば、ブロック１００８）、更新後のサーフェスの他の部分は、リモートレンダリングのために格納される（例えば、ブロック１０２０と１０２４）。

１つの実施形態において、ＡｎｄｒｏｉｄモバイルＯＳとフルＬｉｎｕｘ ＯＳ（例えば、Ｈｙｄｒｏｉｄ）は、モバイルデバイス上の共有カーネルで同時動作中である。ＡｎｄｒｏｉｄアプリケーションがＨｙｄｒｏｉｄ ＯＳ ６６０から起動されると、コンソールアプリケーションがＨｙｄｒｏｉｄ ＯＳ ６６０上で起動し、Ａｎｄｒｏｉｄ ＯＳ ４３０がＡｎｄｒｏｉｄアプリケーションを起動させて、Ａｎｄｒｏｉｄアプリケーションに関する描画通知をコンソールアプリケーションに送信するように要求する。Ａｎｄｏｉｄ ＯＳ ４３０はＡｎｄｏｒｏｉｄアプリケーションを起動させ、このアプリケーションを仮想ディスプレイＩＤに関連付けて、コンソールアプリケーションを登録し、そのアプリケーションに関する描画通知を受け取るようにする。例えば、Ａｎｄｒｏｉｄグラフィクスサーバ（すなわち、ＳｕｒｆａｃｅＦｌｉｎｇｅｒ）は、使用されていない仮想ディスプレイＩＤを割り当てて、アプリケーションオブジェクトリストを通じてそのアプリケーションを仮想ディスプレイＩＤに関連付ける。ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、共有メモリの中でＡｎｄｒｏｉｄアプリケーションのサーフェス情報のためのメモリを割り当て、コンソールアプリケーションを登録して、Ａｎｄｒｏｉｄアプリケーションに関する描画通知を受け取るようにする。

ＳｕｒｆａｃｅＦｌｉｎｇｅｒが、サーフェス情報が更新されたと判断すると、ＳｕｒｆａｃｅＦｌｉｎｇｅｒはプロセス間通信チャネルを通じてコンソールアプリケーションに描画通知を送信する。例えば、ＳｕｒｆａｃｅＦｌｉｎｇｅｒはｕｎｉｘドメインソケット、Ｂｉｎｄｅｒインタフェース及び／またはネットワークソケットを通じて描画通知を送信してもよい。描画通知には、サーフェス情報の第一の記述子が含まれる。ファイル記述子は、ＳｕｒｆａｃｅＦｌｉｎｇｅｒにより、そのサーフェスの名前付き共有メモリ領域に関する名前空間に基づいて生成されてもよい。描画通知にはまた、データフォーマット、バッファサイズ、サーフェス位置情報が含まれていてもよい。コンソールアプリケーションは、ファイル記述子をそのプロセス空間にマッピングし、マッピングされたファイル記述子を通じて、共有メモリから読み出す。コンソールアプリケーションは次に、そのアプリケーションに関する他のグラフィクスフレームを、サーフェス情報から直接レンダリングする。すると、レンダリングされたグラフィクスフレームはデスクトップＯＳグラフィクスシステムによって（すなわち、Ｈｙｄｒｏｉｄ ＯＳ ６６０のＸウィンドウグラフィクスシステムを通じて）表示される。

図１１は、各種の実施形態による、異環境間リモートレンダリングのための登録及び描画プロセスフロー１１００をより詳しく示している。まず、Ｈｙｄｒｏｉｄ ＯＳ ６６０上で動作中のコンソールアプリケーション１１０２は、ステップ１１０６で、共有カーネル５２０のＩＰＣチャネル５２５を通じて、ＡｎｄｒｏｉｄアプリケーションがＨｙｄｒｏｉｄ ＯＳ ６６０のユーザ環境で起動され、表示されるか、Ａｎｄｒｏｉｄ ＯＳ ４３０のユーザ環境からＨｙｄｒｏｉｄ ＯＳ ６６０のユーザ環境に移動されるように要求する。Ａｎｄｒｏｉｄは、ステップ１１０８、１１１０、１１１２で、ＳｕｆａｃｅＦｌｉｎｇｅｒ ４３４にそのアプリケーションのための仮想ディスプレイＩＤを要求し、アプリケーションを起動させ、仮想ディスプレイのパラメータを設定する。ステップ１１１４で、Ａｎｄｒｏｉｄは、ＩＰＣチャネル５２５を通じてディスプレイＩＤをコンソールアプリケーションに返す。ステップ１１１６で、アプリケーションは新しいサーフェスを要求し、ステップ１１１８でこれがＳｕｒｆａｃｅＦｌｉｎｇｅｒ ４３４により、サーフェスクラス１１０４のインスタンスを作ることによって作成される。

ステップ１１２０で、コンソールアプリケーション１１０２はレンダラオブジェクトのインスタンスを作り、これがＨｙｄｒｏｉｄ ＯＳ ６６０のＸウィンドウシステムを通じてＡｎｄｒｏｉｄ サーフェス情報をレンダリングする。ステップ１１２２で、コンソールアプリケーション１１０２は、レンダラオブジェクト１１２４のリモート処理可能なインタフェースをＳｕｒｆａｃｅＦｌｉｇｎｅｒ ４３４に登録し、Ａｎｄｒｏｉｄアプリケーションに関するサーフェス情報の描画通知を受け取るようにする。１つの実施形態において、レンダラオブジェクトとリモート処理可能なインタフェースには、ｄｒａｗ（）及びｃｌｅａｒ（）メソッドが含まれ、これはＩＰＣチャネル５２５を通じてコールすることができる。ステップ１１２６と１１２８で、ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、ＩＰＣオブジェクトをサーフェスに貼付し、サーフェス情報が更新された時に、リモート処理可能なインタフェースを通じてコンソールアプリケーション１１０２に通知が行われるようにする。

ステップ１１３０と１１３２は、プロセスフロー１１００のレンダリングループの一部である。レンダリングループの中で、ＳｕｒｆａｃｅＦｌｉｎｇｅｒはコンソールアプリケーション１１０２に対し、サーフェス情報が更新されたことを通知し、ＩＰＣチャネル５２５を通じて、そのサーフェス情報のファイル記述子を送る。例えば、コンソールアプリケーションレンダラの描画メソッドがコールされ、そのサーフェスのファイル記述子が送られてもよい。コンソールアプリケーション１１０２は、ファイル記述子をそのプロセス空間にマッピングし、参照された共有メモリ位置にアクセスして、サーフェス情報を読み出し、Ｈｙｄｒｏｉｄ ＯＳ ６６０に関連する第二のコンピューティング環境のディスプレイ上に表示されるべきグラフィクスフレームをレンダリングする。

図１２は、各種の実施形態による、非拡張レンダリングコンテキストでの異環境間レンダリングの他の例示的方法のフロー１２００を示す。図１０の方法１０００と同様に、実施形態では、どちらも第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに同時動作中の第一のアプリケーションと第二のアプリケーションのアプリケーショングラフィクスの表示が維持される。

方法１２００はブロック１２０４で、第一のオペレーティングシステムの第一のレンダリングコンテキストを作成することから始まる。レンダリングコンテキストは、それが関連するディスプレイに固有のものであってもよい。例えば、モバイルＯＳの実行は、特定の解像度を有するモバイルデバイスディスプレイに関連付けることができる。レンダリングコンテキストは、関連するディスプレイの解像度にマッチするように作成してもよく、それによってグラフィクスはその解像度に合わせて適正にレンダリングされる。ブロック１２０８で、方法１２００は、第一のオペレーティングシステムを使って、第一のアプリケーションのサーフェスの更新を計算する。前述のように、サーフェスの更新を計算するには、アプリケーションのデータを使って、どのサーフェスがどのように変化したかが判断される。

第一のアプリケーションの更新後のサーフェスは、次にブロック１２１２で、第一のオペレーティングシステムを使ってレンダリングされ、第一のメモリ位置に第一のグラフィクスフレームが生成される。レンダリングでは一般に、グラフィクスプリミティブが、表示されるグラフィクスフレームを形成するビット（例えば、ビットマップ）に変換される。例えば、サーフェス情報は形状、大きさ、色、層の重なり順（すなわち、その前または後ろに、他の何れのサーフィスがあるか）、透明度等、各サーフェスの特性を数学的に定義する。ＯＳのレンダリングエンジンは、サーフェスデータを解釈し、レンダリングコンテキストの中の各位置（例えば、「Ｘ、Ｙ」位置）においてどのビットを表示するかを、全サーフェス情報のレンダリングに応じて（例えば、繰り返しによる合成、レイトレーシング、及び／またはその他の手法を使用して）判断できる。第一のアプリケーションの更新後のサーフェスを、第一のレンダリングコンテキストを使ってビットマップの中にレンダリングし、第一のメモリ位置（例えば、フレームバッファメモリ、共有メモリ、またはその他の有益なメモリ位置）の中に格納されるようにすることができる。

いくつかの実施形態において、ブロック１２１６で、第一のグラフィクスフレームが第一のメモリ位置から第一のオペレーティングシステムに関連する第一のコンピューティング環境のディスプレイに表示される。例えば、モバイルデバイスディスプレイのためのディスプレイドライバが、関連するフレームバッファメモリにアクセスして、第一のレンダリングコンテキストで生成されたビットマップを表示する。ブロック１２２０において、第一のレンダリングコンテキストは解体される（例えば、破壊される）。

ブロック１２２４で、第一のオペレーティングシステムの第二のレンダリングコンテキストが作成される。いくつかの実施例で、第二のレンダリングコンテキストは、第一のレンダリングコンテキストと同じである。しかしながら、第二のレンダリングコンテキストはまた、第二のコンピューティング環境のディスプレイ（例えば、デスクトップディスプレイ）の特徴に応じて作成されてもよい。ブロック１２２８で、第二のアプリケーションのサーフェスの更新が、第一のオペレーティングシステムを使って計算される。ブロック１２３２で、これらの更新が次に第一のオペレーティングシステムの第二のレンダリングコンテキストでレンダリングされ、第二のメモリ位置に第二のグラフィクスフレームが生成される。特に、第二のメモリ位置は、モバイルデバイスの共有カーネル上で同時動作中の第一のオペレーティングシステムと第二のオペレーティングシステムの両方によりアクセス可能な共有メモリ位置である。

いくつかの実施形態において、ブロック１２３６で、第二のグラフィクスフレームが第二のメモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティング環境のディスプレイに表示される。特筆すべき点として、図１０とは異なり、両方のアプリケーションの更新されたグラフィクスフレームは、第一のＯＳのレンダリングエンジンを使ってレンダリングされる。例えば、第二のＯＳのコンソールアプリケーションは、第二の共有メモリ位置にアクセスして、第二のコンピューティング環境のディスプレイに表示するためにレンダリングされたビットマップを直接呼び出すことができる。ブロック１２４０で、第二のレンダリングコンテキストが解体される。

いくつかの実施形態において、方法１２００はブロックを繰り返し処理して、両方のアプリケーションのためのグラフィクス環境を同時に維持する。例えば、モバイルＯＳは、第一のアプリケーションに関するレンダリングコンテキストの作成、使用、破壊を繰り返し、その後、第二のアプリケーションに関するレンダリングコンテキストを作成し、使用し、破壊する。この技術を使用して、すべてのレンダリングを１つのＯＳによって（すなわち、第一のＯＳのレンダリングエンジンによって）実行することができ、もう一方のＯＳのレンダリング機能を提供または使用する必要がない。しかしながら、この技術では、レンダリングコンテキストを繰り返し作成し、破壊することに伴う追加の間接費が発生する。

異環境間レンダリングの上記の実施形態は、非拡張レンダリングコンテキストを使用して、第一のＯＳ上で動作中のアプリケーションに関するグラフィクスフレームが、複数のＯＳに基づくコンピューティング環境の中の第二のＯＳのユーザ操作空間のコンソールウィンドウに表示される方法を説明している。このような異環境間アプリケーションのユーザ操作をサポートするために、実施形態では、入力イベントを第二のＯＳのユーザ操作空間から第一ＯＳにリダイレクトし、異環境間アプリケーションが入力イベントを、それが第一のＯＳのユーザ操作空間から送られているかのように受け取るようにする（すなわち、アプリケーションは入力イベントを、それが第一のＯＳのユーザ操作空間内で表示された場合にユーザ入力の受け取りに使用するものと同じイベントハンドラ及び／またはビューを通じて受け取る）。

図７と８に戻ると、デスクトップＯＳ １６０は、デスクトップコンピューティング体験に適した第二の端末環境８４０を通じて、第二のユーザ操作空間を提供するように構成される。前述のように、上記の異環境間レンダリングの実施形態を用いれば、アプリケーション７５２はモバイルＯＳ １３０のユーザ操作空間に表示されてもよく、その一方で、モバイルＯＳ １３０上で動作中のアプリケーション７５４は、デスクトップＯＳ １６０上で動作中のコンソールアプリケーション７８２を通じて第二のユーザ操作空間のコンソールウィンドウ８８２に表示される。特に、アプリケーション７５２と７５４は、モバイルＯＳランタイム環境内で動作中であり、モバイルＯＳフレームワークを通じて入力イベントを受け取る、モバイルＯＳ １３０のためにコンパイルされたどのようなアプリケーションであってもよく、表示するため、または遠隔的に（モバイルＯＳ １３０のユーザ操作空間以外で）操作するために変更を加える必要がない。

図１３は、各種の実施形態による、異環境間アプリケーションのユーザ操作をサポートするためのＯＳアーキテクチャ構成３００ｂを示す。ＯＳアーキテクチャ構成３００ｂにおいて、共有カーネル３２０のデバイスドライバは、第二の端末環境８４０を構成するＩ／Ｏデバイス８４４、８４６及び／または８４８のためのハードウェアインタフェースを実装する。デバイスドライバを通じて、これらのデバイスの入力イベントが、共有カーネル３２０のＩ／Ｏデバイス１３６０のデバイス１３６４、１３６６及び／または１３６８に現れる。共有カーネル３２０のシステムリソースは、モバイルＯＳ １３０とデスクトップＯＳ １６０の両方で利用できることから、モバイルＯＳは、入力デバイス１３６４、１３６６及び／または１３６８の入力イベントがモバイルＯＳ １３０に対するものであるか否かを判断する。デスクトップＯＳ １６０が第二のユーザ操作空間を提供するように構成されている（すなわち、モバイルコンピューティングデバイス１１０が第二の端末環境８４０にドッキングされている）場合、モバイルＯＳ １３０は、第二のユーザ操作空間に関連する入力デバイスからの入力イベントを無視する。ＯＳアーキテクチャ構成３００ｂにおいて、モバイルＯＳ １３０は、デバイス１３６４、１３６６及び／または１３６８からの入力イベントを無視する。この場合、デスクトップＯＳ １６０がデバイス１３６４、１３６６及び／または１３６８からの入力イベントを受け入れる。

デスクトップＯＳ １６０は、デバイス１３６４、１３６６及び／または１３６８からの入力イベントを処理し、このイベントをデスクトップＯＳ １６０内の各種のウィンドウまたはＧＵＩ要素にどのように分配するかを判断する。例えば、デスクトップＯＳ １６０のウィンドウシステム７７４は、デバイス１３６４、１３６６及び／または１３６８からの入力イベントを受け入れてもよい。１つの実施形態において、デスクトップＯＳ １６０のグラフィクスシステムは、Ｘウィンドウグラフィクスシステムである。

１つの例において、ユーザは、コンソールアプリケーション７８２のコンソールウィンドウ８８２の中の画面位置でポインティングデバイスのボタンをクリックする。これに対応する入力イベントがデバイス１３６８に現れ、デスクトップＯＳ １６０はこの入力イベントを受け取って、処理する。ウィンドウシステム７７４は、入力イベントをコンソールアプリケーション７８２に送り、これを通じて、モバイルＯＳ １３０上で動作中のアプリケーション７５４が、異環境間レンダリングの実施形態を使って表示される。前述のように、アプリケーション７５４はモバイルアプリケーションであり、モバイルＯＳ １３０の入力待ち行列７３６からの入力を受け取るモバイルＯＳ １３０のライブラリを使って、ビューとその他のイベントハンドラのインスタンスを作成し、ユーザ入力を受け取る。入力イベントをアプリケーション７５４に、アプリケーション７５４がその入力イベントを適正に解釈できるような方法で提示するために、コンソールアプリケーション７８２は、入力イベントをモバイルＯＳ １３０のグラフィクスコンテキストにマッピングし、仮想入力デバイス１３７０を通じてこのイベントをモバイルＯＳ １３０の入力待ち行列７３６に送る。仮想入力デバイス１３７０はモバイルＯＳ １３０にとって、モバイルＯＳ １３０のための適正な入力イベントプロトコルを有する入力デバイスに見える。これに加えて、入力イベントは、コンソールアプリケーション７８２によって、モバイルＯＳ １３０のグラフィクスコンテキストに関連するようにフォーマットされる。モバイルＯＳ １３０は、仮想入力デバイス１３７０をアプリケーション７５４に関連付け、アプリケーション７５４がモバイルＯＳのイベント待ち行列から入力イベントを受け取るようにする。例えば、モバイルＯＳ １３０は、仮想入力デバイス１３７０をアプリケーション７５４の仮想ディスプレイＩＤに関連付けてもよい。このようにして、アプリケーション７５４は、アプリケーション７５４がモバイルＯＳ １３０のユーザ操作空間を通じて表示、操作されるかのように、入力イベントを受け取り、処理する。

図１４は、各種の実施形態による、非拡張グラフィクスコンテキストを使ってレンダリングされる異環境間アプリケーションのためのユーザ操作をサポートする態様を示す。方法１４００は、ブロック１４０２で、入力イベントをモバイルコンピューティングデバイス１１０に接続された入力デバイス（例えば、キーボード８４６、ポインティングデバイス８４８）から受け取ることから始まる。前述のように、入力イベントは共有カーネル内の入力デバイスに現れてもよい。ブロック１４０４で、モバイルＯＳは、モバイルコンピューティングデバイス１１０がドッキングされ、デスクトップＯＳが入力デバイスに関連付けられているか否かを判断する。例えば、モバイルコンピューティングデバイス１１０が第二の端末環境にドッキングされておらず、デスクトップＯＳが一時停止している場合、モバイルＯＳは、デスクトップが入力デバイスに関連付けられていないと判断することができる。デスクトップＯＳが一時停止しているか、入力デバイスがデスクトップＯＳに関連する第二の端末環境の一部ではない場合、ブロック１４０６で、モバイルＯＳが入力デバイスからの入力コマンドを受け入れる。

デスクトップＯＳが一時停止しておらず、入力デバイスがデスクトップＯＳに関連する第二の端末環境の一部である場合、ブロック１４０８で、モバイルＯＳは入力デバイスの入力イベントを無視し、デスクトップＯＳがその入力イベントを受け入れる。ブロック１４１０で、デスクトップＯＳは入力イベントを、デスクトップＯＳ内の適当なウィンドウかＧＵＩ要素に分配する。入力イベントがコンソールウィンドウに送られなければ、ブロック１４１２で、この入力イベントは他のウィンドウまたはＧＵＩ要素に送られる。入力イベントがコンソールウィンドウに送られた場合（例えば、ユーザがポインティングデバイスをコンソールウィンドウ領域の中でクリックする）、ブロック１４１４で、この入力イベントが入力イベントとしてコンソールアプリケーションに送られる。

ブロック１４１６で、仮想入力デバイスが、コンソールアプリケーションからの入力イベントのために生成される。仮想入力デバイスは共有カーネルの中に生成されてもよく、または入力イベントがモバイルＯＳ入力デバイスの中に直接書き込まれてもよい。ブロック１４１８で、コンソールアプリケーションは入力イベントをモバイルＯＳのグラフィクスコンテキストにマッピングする。例えば、コンソールアプリケーションは、コンソールアプリケーションのコンソールウィンドウの中の入力イベントの位置を、モバイルＯＳのグラフィクスコンテキストの中の位置にマッピングしてもよい。コンソールアプリケーションは、その入力イベントを、モバイルＯＳのための入力フォーマットまたは入力モードステートに変換してもよい。例えば、入力フォーマットは、デスクトップＯＳとモバイルＯＳの間で異なっていてもよい。共通の入力フォーマットであっても、デスクトップＯＳとモバイルＯＳは異なる入力モードステートを有していてもよい。例えば、デスクトップＯＳは、ノンタッチモードの入力ステートを使って入力イベントを処理していてもよく、その一方で、モバイルＯＳはタッチモード入力ステートである。この場合、デスクトップＯＳのユーザ操作空間内でポインティングデバイスにより生成された入力イベントは、仮想入力デバイスにジェスチャベースイベントとして現れるように変換されてもよい。

ブロック１４２０で、仮想入力デバイスは、モバイルＯＳの中で、コンソールウィンドウに表示されるそのアプリケーションのための仮想ディスプレイデバイスに関連付けられる。例えば、複数のアプリケーションがモバイルＯＳ上で動作中であり、デスクトップＯＳのユーザ操作空間の異なるコンソールウィンドウに表示されていてもよい。デスクトップＯＳのユーザ操作空間の中の別々のコンソールウィンドウに表示された各アプリケーションには、モバイルＯＳ内の仮想ディスプレイＩＤが割り当てられる。そのため、モバイルＯＳが仮想デバイスを通じてデスクトップＯＳのコンソールアプリケーションから入力イベントを受け取ると、モバイルＯＳは、仮想ディスプレイＩＤを通じて、その仮想デバイスを正しいアプリケーションにマッピングすることができる。ブロック１４２２で、入力イベントは仮想ディスプレイに関連するアプリケーションに送られ、このアプリケーションはその入力イベントを、それがモバイルＯＳのユーザ空間を通じて発生したかのように処理することができる。特に、上記の方法は、モバイルＯＳ １３０の何れのアプリケーションにも利用でき、アプリケーションは、デスクトップＯＳのコンソールアプリケーションを通じて入力イベントを受け入れるように特に設計されている必要がない。
拡張レンダリングコンテキストによる実施形態
いくつかの実施形態は、第一のオペレーティングシステムの中で拡張レタリングコンテキストを作成することによって、複数のＯＳにまたがる同時ユーザインタフェースのサポートを扱う。前述のように、第一のＯＳ（例えば、モバイルＯＳであるＡｎｄｒｏｉｄ）は一般に、単独のアクティブレンダリングコンテキストで、単独のアクティブユーザ操作空間を定義するように構成される。本明細書では、多数のいわゆる「コンテキスト空間」を１つの拡張レンダリング空間にタイリングし、各コンテキスト空間を異なるディスプレイに関連付けることによって、第一のＯＳを、同時に扱われる複数のユーザ操作空間に有効にフーリングするための新規な技術を説明する。実施形態には、複数のユーザ操作空間へのディスプレイ出力を処理するための技術と、これらのコンテキストでユーザ操作を処理する技術が含まれる。

非拡張レンダリングコンテキストによる実施形態に関して上述した例に戻り、再び、カレンダアプリケーションとワードプロセシングアプリケーションがどちらも第一のＯＳ（例えば、モバイルＯＳであるＡｎｄｒｏｉｄ ＯＳ）のためにコンパイルされ、どちらもモバイルデバイスの第一のＯＳ内で同時動作中であると仮定する。第二のＯＳ（例えば、Ｈｙｄｒｏｉｄのような非モバイルＯＳ）は、共有カーネルを使って、モバイルデバイス上で同時に動作している。ユーザは、モバイルデバイスを第二のデスクトップコンピューティング環境にドッキングしており、デスクトップコンピューティング環境は、第二のＯＳのためのユーザ操作空間に関連付けられ、このユーザ操作空間を表示している。ユーザは、第二のＯＳのデスクトップコンピューティング環境を通じて、第一のＯＳ上で動作中のワードプロセシングアプリケーションを操作したいと希望する。デスクトップコンピューティング環境のユーザ操作空間を、モバイルコンピューティング環境（例えば、モバイルデバイス）の第二のＯＳを使って、ユーザにとってわかりやすい方法で扱うことが望ましい。

図１５は、各種の実施形態による、拡張レンダリングコンテキストを使って複数のＯＳにまたがる同時ユーザインタフェースをサポートする態様を示す。図１５に示されるアプリケーションレンダリングの概略図１５００において、第一のアプリケーション１５１０（例えば、カレンダアプリケーション）は、第一のＯＳ内の第一のサーフェス１５１２の更新を計算する。第一のサーフェス１５１２は、第一のＯＳによって共有メモリ空間内の第一メモリ位置に格納される。具体的には、第一のアプリケーション１５１０は、第一のサーフェス１５１２のバックバッファ１５１４を更新する。同様に、第二のアプリケーション１５３０（例えば、ワードプロセシングアプリケーション）は、第一のオペレーティングシステムを使って第二のサーフェス１５３２の更新を計算する。ここでも、第二のアプリケーション１５３０による第二のサーフェス１５３２への更新がバックバッファ１５３４に対して行われる。第二のサーフェス１５３２は、第一のＯＳによって共有のメモリ空間の中の第二のメモリ位置に格納される。

第一のＯＳは、いつサーフェス情報が変化したかを判断し、レンダリングシーケンスを開始する。第一のＯＳは、特定のアプリケーションに関連するサーフェス情報がいつ変化したかを判断して、第一のサーフェス１５１２と第二のサーフェス１５３２を含む全サーフェスについて１ループを実行してもよい。レンダリングシーケンスの中で、第一のＯＳは、いつサーフェス情報が変化したかを判断し、第一のサーフェス１５１２のフロントバッファ１５１６とバックバッファ１５１４及び第二のサーフェス１５３２のフロントバッファ１３６とバックバッファ１５３４をスワップする。第一のＯＳは、共有メモリ空間の中の第三のメモリ位置で拡張レンダリングコンテキスト１５２０を作成し、第一のサーフェス１５１２を拡張レンダリングコンテキスト１５２０の第一のコンテキスト空間１５２２の中にレンダリングする。第一のＯＳは、第二のサーフェス１５３３を拡張レンダリングコンテキスト１５２０の第二のコンテキスト空間１５２４の中にレンダリングする。

実施形態において、拡張レンダリングコンテキスト１５２０は、メモリ空間の中で第一のＯＳのフレームバッファと重複してもよい。例えば、拡張レンダリングコンテキスト１５２０の第一のコンテキスト空間１５２２のメモリ位置は、第一のＯＳのフレームバッファと同じ範囲を占めていてもよい。第一のＯＳは、最終的な画像が第三のメモリ位置にレンダリングされたという通知を第二のＯＳに送る。例えば、第一のＯＳは、拡張コンテキスト１５２０の第二のコンテキスト空間１５２４の共有メモリ位置のファイル記述子を、プロセス間通信チャネルを通じて第二のＯＳのコンソールアプリケーションに送ってもよい。第二のＯＳは第三のメモリ位置の拡張グラフィクスコンテキストの第二の部分にアクセスして、レンダリングされたグラフィクスフレーム１５３８を呼び出し、第二のＯＳのコンソールウィンドウ１５４０の中に表示されるようにする。例えば、第二のＯＳのコンソールアプリケーションは、ファイル記述子をそのプロセス空間にマッピングし、第三のメモリ位置からレンダリングされたグラフィクスフレームを読み出し、第二のＯＳのユーザ操作空間内で表示されるようにする。このようにして、第二のＯＳは、第二のアプリケーションのレンダリングされたグラフィクスフレームを、そのユーザ操作空間内にリアルタイムで表示する。

図１６は、各種の実施形態による、拡張レンダリングコンテキストを用いて異環境間レンダリングを行う例示的な方法のフロー１６００を示す。実施形態では、第一のアプリケーション（例えば、カレンダアプリケーション）と第二のアプリケーション（例えば、ワードプロセシングアプリケーション）のアプリケーショングラフィクスの表示が維持される。どちらのアプリケーションも、第一のオペレーティングシステム（例えば、Ａｎｄｒｏｉｄ ＯＳ）のためにコンパイルされ、その中でアクティブに同時動作中であるが、ユーザは、第二のＯＳに関連する第二のコンピューティング環境を通じて、第二のアプリケーションを操作したいと望んでいると仮定する。特に、これらの技術は、２つのＯＳが非互換的である（例えば、第一のＯＳ用にコンパイルされたアプリケーションは、直接第二のＯＳで実行できない）環境に利用できる。いくつかの実施例では、前述のように、２つのＯＳはモバイルデバイスの共有カーネル上で独立して、同時に動作している。

方法１６００は、ブロック１６０４で、第一のＯＳの拡張レンダリングコンテキストを作成することから始まる。前述のように、レンダリングコンテキストは一般に、１つのアクティブディスプレイの特徴に合わせて作成される。しかしながら、拡張レンダリングコンテキストは、第一のアプリケーションに関連する第一のコンテキスト空間と第二のアプリケーションに関連する第二のコンテキスト空間を有するように作成される。第一と第二のコンテキスト空間は重複しない。

いくつかの実施形態において、拡張レンダリングコンテキストは、ローカルデバイスのアクティブディスプレイ（例えば、共有カーネルを有するモバイルデバイスのティスプレイ）と何れかの仮想ディスプレイ（すなわち、第二のＯＳのユーザ操作空間内で表示されるコンソールウィンドウに関連する第一のＯＳのディスプレイ）をタイリングして、第一のＯＳにとって、１つの大きなディスプレイに見えるものを形成することによって生成される。拡張レンダリングコンテキストの中の領域は、重複しないコンテキスト空間として指定され、その各々の物理的または仮想ディスプレイとの関連付けが維持される。特に、いくつかの実施形態において、異なるコンテキスト空間は、異なる解像度またはその他の特徴を有していてもよい。また、特定の実施形態において、コンテキスト空間は連続していない。例えば、拡張レンダリングコンテキストは、各コンテキスト空間の間に、どのコンテキスト空間にも割り当てられない空間が残されるような方法で作成される。

ブロック１６０８で、第一のオペレーティングシステムを使って、第一のアプリケーションと第二のアプリケーションのサーフェスの更新が計算される。更新後のサーフェスは次に、ブロック１６１２で、第一のオペレーティングシステムを使ってレンダリングされ、第一のオペレーティングシステムと第二のオペレーティングシステム（例えば、共有カーネル上で同時動作中であってもよい）によってアクセス可能な共有メモリ位置で拡張グラフィクスフレームが生成される。拡張グラフィクスフレームの第一の部分は（第一のアプリケーションに関連する）第一のコンテキスト空間に関連付けられ、拡張グラフィクスフレームの第二の部分は（第二のアプリケーションに関連する）第二のコンテキスト空間に関連付けられる。ブロック１６０８でレンダリングが行われる際、第一のアプリケーションの更新後のサーフェスは、拡張グラフィクスフレームの第一の部分にレンダリングされ、第二のアプリケーションの更新後のサーフェスは、拡張グラフィクスフレームの第二の部分にレンダリングされる。特筆すべき点として、このようにして、拡張グラフィクスフレームには、その適当なコンテキスト空間の中にタイリングされた両方のアプリケーションのレンダリングされたサーフェスが有効に含まれる。

いくつかの実施形態において、ブロック１６１６で、拡張グラフィクスフレームのうち、第一のコンテキスト空間に関連する第一の部分が、共有メモリ位置から第一のＯＳに関連する第一のコンピューティング環境のディスプレイに表示される。例えば、前述のように、共有メモリ位置はモバイルデバイスのフレームバッファメモリであり（またはフレームバッファメモリにコピーされ）、モバイルデバイスのディスプレイデバイスドライバがそのフレームバッファメモリにアクセスして、拡張グラフィクスフレームの第一の部分をそのディスプレイに表示する。さらに、いくつかの実施形態において、ブロック１６２０で、拡張グラフィクスフレームのうち、第二のモーション空間に関連する第二の部分が、共有メモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティングデバイスのディスプレイに表示される。例えば、前述のように、共有メモリ位置は第二の（例えば、デスクトップ）コンピューティング環境に関連する第二のＯＳのフレームバッファメモリの中にコピーされ、ディスプレイデバイスドライバは、拡張グラフィクスフレームの第二の部分を第二のコンピューティング環境のディスプレイに表示する。

図１２に関して説明した実施形態において、第二のアプリケーションの更新後のグラフィクスのレンダリングは、第二のＯＳによって遠隔的に行われる。図１５に関して説明した実施形態において、両方のアプリケーションのレンダリングがモバイルデバイスのレンダリングエンジンによってローカルで実行されるが、レンダリングコンテキストは継続的に作成され、解体される。図１６に関して説明した実施形態によれば、両方のアプリケーションのレンダリングがモバイルデバイスのレンダリングエンジンによってローカルで実行され、その一方で、拡張はされているが、単独のレンダリングコンテキストが維持される（すなわち、レンダリングコンテキストが解体されない）。

図１７は、各種の実施形態による、拡張レンダリングコンテキストを使用する異環境間レンダリングの他の例示的な方法のフロー１７００を示す。図１６の方法１６００と同様に、実施形態では、どちらも第一のオペレーティングシステムのためにコンパイルされ、アクティブに同時動作中の第一のアプリケーションと第二のアプリケーションのためのアプリケーショングラフィクスのディスプレイが維持される。方法１７００は、ブロック１７０４で、第一のオペレーティングシステムの拡張レンダリングコンテキストを作成することから始まり、ブロック１７０８で、第一のオペレーティングシステムを使って、第一のアプリケーションと第二のアプリケーションのサーフェスの更新が計算される。前述のように、拡張レンダリングコンテキストは、第一のアプリケーションに関連する第一のコンテキスト空間と第二のアプリケーションに関連する第二のコンテキスト空間を有するように作成される。第一と第二のコンテキスト空間は重複しない。いくつかの実施例では、ブロック１７０４と１７０８はそれぞれ、ブロック１６０４と１６０８と実質的に同じ方法で実行される。

ブロック１７１２で、第一のアプリケーションの更新後のサーフェスが、第一のオペレーティングシステムを使って、第一のコンテキスト空間に従ってレンダリングされ、第一のオペレーティングシステムのフレームバッファに第一のグラフィクスフレームが生成される。たとえは、第一のコンテキスト空間は、特定の解像度、特定のタイリングオフセット（例えば、「Ｘ」位置から始まる）等に関連付けられてもよい。いくつかの実施形態において、第一のグラフィクスフレームは、図１６の方法１６００の拡張グラフィクスフレームのそれぞれの部分の生成と実質的に同じ方法で生成される。いくつかの実施形態において、ブロック１７１６で、第一のコンテキスト空間に関連する第一のグラフィクスフレームが、フレームバッファから第一のオペレーティングシステムに関連する第一のコンピューティング環境のディスプレイに表示される。

ブロック１７２０で、第二のアプリケーションの更新後のサーフェスが、第一のオペレーティングシステムを使ってレンダリングされ、共有メモリ位置に第二のグラフィクスフレームが生成される。前述のように、共有メモリ位置は第一のオペレーティングシステムと第二のオペレーティングシステム（例えば、これらは共有カーネル上で同時動作中であってもよい）によってアクセス可能である。いくつかの実施形態において、ブロック１７２４で、第二のモーション空間に関連する第二のグラフィクスフレームが、共有メモリ位置から第二のオペレーティングシステムに関連する第二のコンピューティング環境のディスプレイに表示される。

特に、図１６と１７の両方の実施形態では、各アプリケーションのコンテキスト空間を有する拡張レンダリングコンテキストが作成される。しかしながら、図１６の方法１６００は、すべてのグラフィクスの更新を１つの拡張ビットマップにレンダリングするが、図１７の方法１７００は、グラフィクスの更新を別のビットマップにレンダリングする。一方または他方の技術のどちらが望ましいかは、例えばメモリの管理及び／またはアクセス方法によって異なる。

図１２の実施形態と同様に、図１６と１７の実施形態においては、両方のアプリケーションの更新後のグラフィクスフレームが第一のＯＳのレンダリングエンジンを使ってレンダリングされる。第一のＯＳのレンダリングエンジンを使用することにより、両方のアプリケーションに第一のＯＳで利用可能なモバイルデバイスのハードウェア加速機能を使用できる。例えば、図１２、１６及び／または１７の実施形態において、第一と第二のアプリケーションの何れかまたは両方を、２Ｄまたは３Ｄハードウェア支援レンダリングを使って、第一のＯＳによりレンダリングしてもよい。

拡張レンダリングコンテキストを使って第一のＯＳ（すなわち、モバイルＯＳであるＡｎｄｒｏｉｄ）上で動作するアプリケーションのためのグラフィクスフレームを遠隔的に表示することにより、第一のＯＳが１つのレンダリングコンテキストを使って、複数のユーザ操作空間内で表示するように、複数のアプリケーションのためのレンダリングを提供できる。しかしながら、拡張レンダリングコンテキストでは、拡張レンダリングコンテキストを通じて表示されるアプリケーションに関する入力イベントの取扱いに関する問題が発生する。具体的には、第一のＯＳの入力待ち行列は、拡張レンダリングコンテキストの別の仮想ディスプレイを通じて表示される複数のアプリケーションからの複数の入力イベントを取り扱うように構成しなければならない。

異環境間ユーザ操作のサポートの実施形態は、第一のＯＳ上で動作し、第一のＯＳの拡張レンダリングコンテキストを通じて複数の別々のユーザ操作空間（すなわち、モバイルデバイスユーザ操作空間とデスクトップＯＳのユーザ操作空間）で表示される複数のアプリケーションに関するユーザ入力イベントを処理することに関する。実施形態には拡張入力待ち行列が含まれ、そこでは遠隔的に表示されるアプリケーションのための仮想入力デバイスからの入力イベントがその入力待ち行列の中の別々のモーション空間にマッピングされる。例えば、第一のアプリケーション（例えば、カレンダアプリケーション）が第一のＯＳ上で動作中であり、第一のデバイスに関連する第一のディスプレイ（例えば、第一のＯＳが動作中のモバイルデバイスのディスプレイ）に表示されている。第二のアプリケーション（例えば、ワードプロセシングアプリケーション）も、第一のアプリケーションと同時動作中であるが、拡張レンダリングコンテキストのコンテキスト空間（例えば、仮想ディスプレイ）の中でレンダリングされ、モバイルデバイスの共有カーネル上で第一のＯＳと同時動作中の第二のＯＳの第二のユーザ操作空間に表示されている。第一のＯＳは、第一のコンテキスト空間（すなわち、モバイルデバイスディスプレイ）の中の第一のアプリケーションと第二のコンテキスト空間の第二のアプリケーションの両方に関するアプリケーショングラフィクスを含む拡張レンダリングコンテキストを通じて、グラフィクスフレームをレンダリングする。第二のコンテキスト空間は、第二のＯＳ上で動作中のコンソールアプリケーションを通じて第二のＯＳのユーザ操作空間に表示される。

拡張レンダリングコンテキストを通じて遠隔的に表示されるアプリケーションに関する入力イベントは、非拡張グラフィクスコンテキストに関して上述したものと同じ方法で、第二のＯＳ（すなわち、デスクトップＯＳであるＨｙｄｒｏｉｄ）によって受け取られ、第二のＯＳのコンソールアプリケーションによって仮想入力デバイスに送られる。しかしながら、前述のように、仮想入力デバイスからモバイルＯＳで受け取られた入力イベントは、第二のＯＳのユーザ操作空間内に表示されるコンソールウィンドウに関係する。仮想入力デバイスは、拡張入力待ち行列の中の、遠隔的に表示されたアプリケーションに対応する仮想ディスプレイに関連するモーション空間にマッピングされる。拡張入力待ち行列によって、第一のＯＳは、１つの入力待ち行列を使って、同時動作する複数のアプリケーション用として意図された複数のローカル及び仮想入力デバイスからの入力を正しく処理することができる。

図１８ａと１８ｂは、各種の実施形態による、拡張レンダリングコンテキストを用いた異環境間アプリケーションのユーザ操作サポートの態様を示す。図１８ａは、第一のＯＳ上で動作中のアプリケーションを遠隔的に表示しているユーザ操作空間１８１０（例えば、第一のＯＳで動作中のアプリケーションを表示している第二のＯＳのＧＵＩ）を示している。例えば、第一と第二と第三のアプリケーションが第一のＯＳ上で動作していても（すなわち、第一のＯＳでアクティブに同時動作中であっても）よい。第一のＯＳは、上述の実施形態により、第一と第二と第三のアプリケーションを、第一のＯＳの拡張レンダリングコンテキストの第一と第二と第三のコンテキスト空間に表示してもよい。ユーザ操作空間１８１０のコンソールウィンドウ１８１２と１８１４はそれぞれ、第一のＯＳの中で動作中の第二のアプリケーションと第三のアプリケーションを表示していてもよい。

図１８ｂは、第一のＯＳ上で動作中の各アプリケーションのためのユーザ操作をサポートする、第一のＯＳの拡張入力待ち行列１８４０を示す。拡張入力待ち行列１８４０には、第一のモーション空間１８４２、第二のモーション空間１８４４、第三のモーション空間１８４６が含まれる。第一のモーション空間は第一のＯＳの拡張レンダリングコンテキストの第一のコンテキスト空間に関連付けられ、これは一般に、第一のＯＳの非仮想ディスプレイ１８５２を表示するために使用される（すなわち、モバイルコンピューティングデバイス１１０のディスプレイ１１６に関連するコンテキスト空間）。第二と第三のモーション空間はそれぞれ、仮想ディスプレイ１８５４、１８５６に関連付けられ、これらは第二と第三のコンテキスト空間を通じてレンダリングされる。

遠隔的に表示されているアプリケーションのコンソールウィンドウに送られる入力イベントが発生すると、この入力イベントは、そのアプリケーションが表示される仮想ディスプレイに関連するモーション空間へと送られる。例えば、ユーザが、入力イベント１８２０によって示されるように、ユーザ操作空間１８１０のコンソールウィンドウ１８１２でポインティングデバイスをクリックすると、第二のＯＳのウィンドウシステムがその入力イベントを、コンソールウィンドウ１８１２に関連するコンソールアプリケーションに送る。前述のように、コンソールアプリケーションは入力デバイスを仮想入力デバイスにマッピングする。しかしながら、この入力イベントはコンソールウィンドウ１８１２に関係している。この入力イベントが第一のＯＳの入力待ち行列に直接供給された場合、この入力イベントは正しいアプリケーションイベントハンドラに送られないであろう。そのため、仮想入力デバイスからの入力イベント１８２０は第二のモーション空間１８４４にマッピングしなおされる。このようにして、拡張入力待ち行列はその入力イベントを第二のアプリケーションのイベントハンドラに送り、これが入力イベント１８２０を受け取り、処理する。

実施形態において、仮想ディスプレイはモバイルＯＳの入力待ち行列の中でオフセットされる。例えば、図１８ｂにおいて、仮想ディスプレイ１８５４と１８５６は、モバイルＯＳの入力待ち行列１８４０の中の仮想ディスプレイオフセット１８５８の分だけオフセットされる。仮想ディスプレイオフセット１８５８は、仮想ディスプレイが入力待ち行列内で隣接して現れるのを防止するものであり、隣接して現れた場合、１つの仮想ディスプレイ用として意図されたある入力イベントが、別のアプリケーションに関連するモーション空間内で解釈される可能性がある。仮想ディスプレイのオフセットは、実際の仮想ディスプレイの解像度のパラメータとして使用されないように、十分に大きくするべきである。１つ実施形態において、仮想ディスプレイのオフセット１８５８は１００００ピクセルと選択される。

図１９は、各種の実施形態による、拡張レンダリングコンテキストを通じて表示される異環境間アプリケーションに関する入力イベントを受け取る方法１９００を示す。例えば、方法１９００は、第一のＯＳ内で動作中の第一のアプリケーションと第二のアプリケーションに関する入力イベントを処理するために使用してもよく、第一のＯＳの拡張レンダリングコンテキストを通じて、第一のアプリケーションは第一のＯＳのユーザ操作空間にローカルで表示され、第二のアプリケーションは第二のＯＳのユーザ操作空間に遠隔的に表示される。

方法１９００は、ブロック１９０２で、第一のユーザ入力が第一のＯＳで受け取られることから始まり、この時、第一のアプリケーションと第二のアプリケーションは第一のＯＳ内でアクティブに同時動作中であり、第一のアプリケーションが第一のＯＳに関連する第一のユーザ環境内で表示され、第二のアプリケーションが第二のＯＳに関連する第二のユーザ環境内で表示され、第一と第二のオペレーティングシステムは共有カーネル上で同時動作中であり、第一のＯＳは、拡張レンダリングコンテキストの第一の仮想ディスプレイを通じて第二のアプリケーションに関するグラフィクスフレームをレンダリングすることにより、第二のアプリケーションに関するアプリケーショングラフィクスを維持する。ブロック１９０４で、第一のＯＳは第一のモーション空間と第二のモーション空間を含む拡張入力待ち行列を作成し、第二のモーション空間は第一の仮想ディスプレイに対応する。例えば、第一のオペレーティングシステムは第二のアプリケーションのための第一の仮想ディスプレイを割り当て、第一のコンテキスト空間と第二のコンテキスト空間を有する拡張レンダリングコンテキストを作成し、第一の仮想ディスプレイを第二のコンテキスト空間に関連付け、上述の方法を用いて、拡張レンダリングコンテキストの第二のコンテキスト空間を通じて、第二のアプリケーションに関するグラフィクスフレームをレンダリングする。

ブロック１９０６で、第一のユーザ入力イベントが、第一のＯＳにより、第一の仮想入力デバイスにおいて、第二のＯＳを通じて第二のアプリケーションに関するレンダリングされたグラフィクスフレームを表示している、第二のＯＳで動作中の第一のコンソールアプリケーションから受け取られる。ブロック１９０８で、第一の仮想入力デバイスは、第一のオペレーティングシステムの拡張入力待ち行列の第二のモーション空間にマッピングされる。第一の仮想入力デバイスを第二のモーション空間にマッピングすることによって、第一のＯＳの拡張入力待ち行列は、第一の仮想入力デバイスからの入力イベントを第二のアプリケーションのビューの中のイベントハンドラに正しく関連付けることができる。具体的には、入力イベントが第二のモーション空間にマッピングされると、第一のＯＳはこの入力イベントを、拡張入力待ち行列の中の第二のアプリケーションに関連する位置で発生したものとして扱う。ブロック１９１０で、第一のＯＳは第一のユーザ入力イベントを、マッピングされた第一の仮想入力デバイスから第二のアプリケーションに送る。拡張入力待ち行列は、拡張レンダリングコンテキストがタイリングされるという性質を利用して、入力待ち行列が複数のユーザ操作空間からの複数の入力イベントを処理し、入力イベントを所期のアプリケーションの適当なイベントハンドラに送ることができるようにする。
ミラーリングされたコンテキストによる実施形態
拡張及び非拡張レンダリングコンテキストの実施形態を、複数のオペレーティングシステム上の複数のアプリケーションにわたる同時ユーザ操作空間を維持するという内容で説明した。多くの場合、１つのユーザ操作空間のためにコンテキストをミラーリングすることが望ましい。第二のＯＳに関連する第二のコンピューティング環境（例えば、Ｈｙｄｒｏｉｄ ＯＳに関連するデスクトップ環境）の中で同時に第一のＯＳを見て、これを操作すること（すなわち、操作空間を「ミラーリング」すること）が望ましい。ミラーリングされたユーザ操作空間を通じて、ユーザは第一のＯＳを、ローカルデバイスを通じて操作するかのように操作できる（すなわち、ユーザは、利用可能なアプリケーションをブラウズし、アプリケーションを開始、停止し、第一のＯＳの検索機能を使用すること等ができる）。

第一のＯＳ（例えば、モバイルＯＳであるＡｎｄｒｏｉｄ）は一般に、単独のアクティブなユーザ操作空間を画定するように構成される。ユーザ操作空間は、アクティブディスプレイ（例えば、解像度等、関連する特徴を有する）と、ユーザがアクティブディスプレイ上に表示された要素を操作できるようにする１つまたは複数のアクティブ入力デバイスを含む。異環境間レンダリングを使って、複数のＯＳにわたって１つまたは複数のミラーリングされたユーザ操作空間を提供する新規な方法を提示する。前述のように、実施形態は、複数のＯＳが非互換的であり、及び／または共有カーネル上で独立して、並行動作している場合も動作できる。

ミラーリングされたコンテキストにより同時ユーザ操作のサポートを維持することは、異環境間アプリケーションのための同時ユーザ操作をサポートすることに関して上述したものと同じシステム要素の多くを用いて実現できる。例えば、図７を参照すると、モバイルＯＳ １３０のためのグラフィクスコンテキストは、モバイルＯＳ１３０のアプリケーション（例えば、アプリケーション７５２及び／または７５４）及び／またはホーム画面（例えば、Ａｎｄｒｏｉｄ ＯＳ ４３０のホーム画面アプリケーション４５１）をアクティブに表示していてもよい。アクティブに表示されるモバイルＯＳのアプリケーション及び／またはホーム画面に関するサーフェス情報は、共有メモリ７２４の中に格納されてもよい。モバイルＯＳ １３０のミラーリングされたコンテキストは、コンソールアプリケーション７８２を通じて、デスクトップＯＳ １６０のユーザ操作空間に表示されてもよい。

図２０は、様々な実施形態による、ミラーリングされたユーザ操作空間を提供するためのグラフィクスコンテキストの異環境間レンダリングの例示的な方法のフロー２０００を示す。方法２０００はブロック２００４で、第一のオペレーティングシステムを使って、第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに動作中の第一のアプリケーションのサーフェス集合の更新を計算することから始まる。例えば、計算は、サーフェスの形状、大きさ、テクスチャ、レイヤリング等の変化を判断するために行われる。次に、ブロック２００８で、サーフェスの更新が第一のオペレーティングシステムを使ってレンダリングされ、グラフィクスフレームが生成される。グラフィクスフレームは、そのアプリケーションに関する更新後のグラフィクス情報を反映するビットマップであってもよい。

ブロック２０１２で、グラフィクスフレームは、第一のオペレーティングシステムと第二のオペレーティングシステムの両方によりアクセス可能な共有メモリ位置に格納される。いくつかの実施形態において、第一と第二のＯＳは、共有カーネル上で同時動作中である。ブロック２０１６で、グラフィクスフレームは第一のオペレーティングシステムを使って、第一のコンピューティング環境の第一のディスプレイ上の第一のアプリケーションの第一のアプリケーションディスプレイに表示されてもよい。例えば、共有メモリの位置はフレームバッファメモリであってもよく、または第一のオペレーティングシステムのフレームバッファにコピーされてもよい。ローカルデバイス（例えば、共有カーネル上で動作中）のディスプレイデバイスドライバは、そのフレームバッファメモリにアクセスし、ビットマップを表示する。

ブロック２０１２で共有メモリ位置にグラフィクスフレームを格納した後、第二のＯＳに、更新されたグラフィクス情報が利用可能であると知らせることが望ましい。ブロック２０２０で、共有メモリ位置を特定するファイル記述子が、第二のＯＳのためにコンパイルされ、その中でアクティブに動作中のコンソールアプリケーションに送られる。いくつかの実施例において、ファイル記述子には、共有メモリ位置の識別が含まれる。他の実施例では、ファイル記述子には、ミラーリングされるアプリケーションに関する更新後のグラフィクス情報が利用可能であることを示すフラッグのような追加の情報が含まれる。

前述のように、コンソールアプリケーションは、Ｘウィンドウまたは、第二のコンピューティング環境のディスプレイのウィンドウ内に表示されるその他の種類のアプリケーションであってもよい。ブロック２０２４で、コンソールアプリケーションは、ファイル記述子による共有メモリ位置の更新後のグラフィクス情報（例えば、ビットマップ）にアクセスし、そのグラフィクスフレームを共有メモリ位置から第二のコンピューティング環境の第二のディスプレイ上の第一のアプリケーションの第二のアプリケーションディスプレイに表示する。いくつかの実施形態において、アプリケーションに関する更新後のグラフィクス情報は、第一と第二のコンピューティング環境の両方のディスプレイで実質的に同時に表示される。

図２１は、様々な実施形態による、ミラーリングされたユーザ操作空間を提供するためのグラフィクスコンテキストの異環境間レンダリングの他の例示的な方法のフロー２１００を示す。図２０と同様に、方法２１００はブロック２１０４で、第一のオペレーティングシステムを使って、第一のオペレーティングシステムのためにコンパイルされ、その中でアクティブに動作中の第一のアプリケーションのサーフェス集合の更新を計算することから始まる。フロック２１０８で、更新後のサーフェス集合が、第一のオペレーティングシステムと第二のオペレーティングシステム（例えば、共有カーネル上で同時動作中）の両方によってアクセス可能な共有メモリ位置に格納される。

ブロック２１１２で、更新後のサーフェス集合は第一のオペレーティングシステムでレンダリングされ、第一のグラフィクスフレームが生成される。次に、ブロック２１１６で、第一のグラフィクスフレームを、第一のオペレーティングシステムを使って、第一のコンピューティング環境の第一のディスプレイ上の第一のアプリケーションの第一のアプリケーションディスプレイに表示することができる。例えば、モバイルＯＳ １３０は、更新後のアプリケーショングラフィクスをレンダリングして、更新後のグラフィクスをモバイルデバイス１１０のディスプレイ１１６に表示する。

ブロック２１０８で更新後のサーフェス集合を共有メモリに格納した後、何れかの時点で、第二のＯＳに対して、更新後のグラフィクス情報が利用可能であると通知することが望ましい。ブロック２１２０で、共有メモリ位置を特定するファイル記述子が、第二のオペレーティングシステムのためにコンパイルされ、その中でアクティブに動作中のコンソールアプリケーションに送られる。特に、共有メモリ内に格納された情報は、図２０の方法２０００のようなレンダリングされたビットではなく、レンダリングされていないサーフェス情報（例えば、幾何プリミティブ）である。

従って、ブロック２１２４で、更新後のサーフェス集合は、第二のオペレーティングシステムによって（例えば、ファイル記述子によるコンソールアプリケーションを介して）共有メモリ位置からレンダリングされ、第一のグラフィクスフレームと実質的に同じ第二のグラフィクスフレームが生成される。ブロック２１２８で、第二のグラフィクスフレームは、第二のオペレーティングシステムのコンソールアプリケーションを介して、第二のコンピューティング環境の第二のディスプレイ上の第一のアプリケーションの第二のアプリケーションディスプレイに表示され、それによって、第二のアプリケーションディスプレイは第一のアプリケーションディスプレイと実質的に同じとなる。

特筆すべき点として、第一と第二のオペレーティングシステムシステムの両方でレンダリングを複製することから、追加の間接費が発生し得る。しかしながら、このような追加の間接費には、数多くの状況において、相応の価値がある可能性がある。例えば、異なるコンピューティング環境のディスプレイの特徴が顕著に異なる場合、各々がそれぞれのディスプレイに適した別々のレンダリングコンテキストで更新後のグラフィクス情報をレンダリングすることが望ましい場合がある。

図２０と２１の方法は、ミラーリングされたグラフィクスコンテキストの中での、第一のＯＳで動作中のアプリケーションのアクティブディスプレイによるグラフィクスコンテキストの異環境間ミラーリングを説明している。しかしながら、この方法は、グラフィクスコンテキストの中でアクティブに表示されているアプリーションがない場合にも使用できる。例えば、グラフィクスコンテキストは、第一のＯＳのホーム画面またはその他の機能（例えば、検索画面等）を表示していてもよい。このような場合、グラフィクスコンテキストに関するサーフェス情報は第一のＯＳのコンポーネントによって更新され、図２０と２１の方法のその他のステップは、第二のアプリケーションディスプレイの中にミラーリングされたグラフィクスコンテキストを提供するために実行されてもよい。

特に、グラフィクスコンテキストの異環境間ミラーリングは、アプリケーションの異環境間レンダリングと同時に利用してもよい。例えば、図２０または２１による方法は、前述のアプリケーションの異環境間レンダリングの方法を使って、第一のＯＳで動作中のアプリケーションが第二のユーザ環境内で表示されるのと同時に、モバイルデバイスのユーザ操作空間のアクティブグラフィクスコンテキストを第二のユーザ環境にミラーリングするために使用してもよい。説明のために図８を参照すると、モバイルＯＳ用アプリケーションがディスプレイ８４４の上のデスクトップＯＳのユーザ操作空間内の第二のコンソールウィンドウ８８４に表示されている間に、モバイルＯＳのユーザ操作空間を第一のコンソールウィンドウ８８２の中に表示してもよい。

ミラーリングされたグラフィクスコンテキストのためのユーザ操作のサポートは、図１３、１４、１８及び／または１９に示される異環境間アプリケーションのためのユーザインタフェースをサポートするのと実質的に同じ方法で行われてもよい。具体的には、入力イベントは、第二のＯＳのコンソールアプリケーションから仮想入力デバイスに提供されてもよい。第一のＯＳは、拡張または非拡張入力待ち行列を通じて、仮想入力デバイスからの入力イベントを受け入れてもよい。
異環境間レンダリングの実施形態
上記の方法は、第二のオペレーティングシステムのユーザ操作空間を通じた第一のオペレーティングシステムのアプリケーションとグラフィクスコンテキストのための異環境間ユーザ操作をサポートする。わかりやすい異環境間使用モデルとするために、実施形態は、第二のオペレーティングシステムのユーザ操作空間から、第一のオペレーティングシステムのアプリケーション及び／またはミラーリングされたコンテキストにアクセスできるようにすることに関する。

再び図８を参照すると、ユーザは、モバイルデバイス上の操作コンポーネント（すなわち、タッチスクリーンディスプレイ１１６、その他のＩ／Ｏデバイス１１８）を含む第一のユーザ操作空間を通じて、第一のＯＳ（すなわち、モバイルＯＳであるＡｎｄｒｏｉｄ）を操作できる。ユーザはまた、第二のＯＳ（すなわち、デスクトップＯＳであるＨｙｄｒｏｉｄ）を、第二の端末環境８４０のディスプレイ８４４を含む第二のユーザ操作空間を通じて操作できる。前述のように、デスクトップＯＳ １６０で利用可能な（すなわち、そのためにコンパイルされ、その実行環境内にロードされた）アプリケーションの集合は、モバイルＯＳ １３０で利用可能なものとは異なるかもしれない。実施形態は、デスクトップＯＳ １６０のユーザ操作空間のメニューの中にモバイルＯＳ １３０で利用可能なアプリケーションのためのメニューアイコンまたはメニューリストアイテムを設けることによって、モバイルＯＳ １３０のアプリケーションにデスクトップＯＳ １６０のユーザ操作空間内でアクセスできるようにすることに関する。

図２２は、各種の実施形態による異環境間リダイレクションの態様を示す。図２２に示されるコンピューティング環境２２００の中で、ユーザは、デスクトップＯＳのユーザ操作空間２２０２を通じてデスクトップＯＳ １６０を操作する。デスクトップＯＳのユーザ操作空間２２０２の中で、メニューバー２２２０には、利用可能なアプリケーションのアイコンまたはリストが含まれる。あるアプリケーションを起動させるには、ユーザはそのアプリケーションの名前またはアイコンをメニューバーから、またはメニューバー２２２０のドロップダウンまたはポップアップリストから選択する。従来、メニューバー２２２０には、デスクトップＯＳ １６０で利用可能なアプリケーションのメニューアイテムまたはアイコンのみが含まれている。例えば、メニューアイテム２２２２、２２２４、２２２６及び／または２２２８は、デスクトップＯＳ １６０で利用可能な（すなわち、そのためにコンパイルされ、その実行環境の中にロードされた）アプリケーションであってもよい。本発明の実施形態は、デスクトップＯＳのユーザ操作空間２２０２からのモバイルＯＳ １３０のアプリケーション及び／またはグラフィクスコンテキストへの異環境間アクセスを提供することに関する。例えば、メニューアイテム２２３２、２２３４、２２３６、２２３７及び／または２２３８はモバイルＯＳ １３０で利用可能なアプリケーション及び／またはモバイルＯＳ １３０のグラフィクスコンテキストを示していてもよい。

デスクトップＯＳのユーザ操作空間２２０２は、デスクトップＯＳ １６０に関連するユーザ操作空間（例えば、第二の端末環境８４０）の中のディスプレイに表示される。デスクトップＯＳ １６０のメニューバー２２２０には、デスクトップＯＳ １６０のためにコンパイルされ、そこにロードされた（例えば、Ｈｙｄｒｏｉｄ／Ｌｉｎｕｘのためにコンパイルされ、Ｈｙｄｒｏｉｄ ＯＳの実行環境内にロードされた）アプリケーションに関連するメニューアイテム２２２２、２２２４、２２２６及び／または２２２８が含まれる。メニューバー２２２０はまた、モバイルＯＳ １３０のためにコンパイルされ、そこにロードされた（例えば、Ａｎｄｒｏｉｄのためにコンパイルされ、Ａｎｄｒｏｉｄの実行環境内にロードされた）アプリケーションに関連するメニューアイテム２２３４、２２３６、２２３７及び／または２２３８が含まれる。ユーザがメニューアイテム２２３４、２２３６及び／または２２３８の１つを選択すると、関連するアプリケーションがモバイルＯＳ １３０上で起動され、デスクトップＯＳ １６０のコンソールウィンドウ内、例えばデスクトップＯＳのユーザ操作空間２２０２のウィンドウ２２１６の中に表示される。メニューアイテム２２３２は、モバイルＯＳグラフィクスコンテキストに関連付けられていてもよく、これによって、メニューアイテム２２３２が選択されると、モバイルＯＳのグラフィクスコンテキストがデスクトップＯＳ １６０のコンソールウィンドウ内に表示される。

図２３は、デスクトップＯＳ １６０のメニューバー２２２０を構築するために使用できるプロセスフロー２３００を示す。プロセスフロー２３００のステップ２３０２で、デスクトップＯＳ １６０は、モバイルＯＳ １３０に利用可能なアプリケーションのリストを問い合わせる。一実施形態において、デスクトップＯＳ １６０のシステムサービスまたは起動アプリケーションは、モバイルＯＳ １３０のサービスにすべての起動可能なモバイルＯＳ用アプリケーションのショートカットを問い合わせる。モバイルＯＳ １３０は、利用可能なアプリケーションのリスト（すなわち、利用可能なモバイルＯＳ用アプリケーションの起動可能なショートカット）を返す。利用可能なアプリケーションのリストには、モバイルＯＳ １３０で利用可能なすべてのアプリケーション（モバイルＯＳ １３０にロードされ、実行可能なすべてのアプリケーション）または、利用可能なモバイルＯＳ用アプリケーションのサブセットが含まれていてもよい。例えば、リストには、モバイルＯＳ ＧＵＩのアプリケーションメニュー画面上に現れるすべてのアプリケーションが含まれていてもよい。ステップ２３０４で、デスクトップＯＳ １６０は、モバイルＯＳ １３０からアプリケーションのリストを受け取る。モバイルＯＳ １３０から返されたアプリケーションのリストには、リストに挙げられた各アプリケーションのアプリケーションパッケージ名が含まれ、また、リストに挙げられた各アプリケーションのアプリケーション名とアイコンが含まれていてもよい。

デスクトップＯＳ １６０は、メニューバー２２２０の中に、アプリケーションのリストの中の各アプリケーションのメニューアイテムを、ブロック２３０６、２３０８、２３１０を繰り返すことによって作成する。各アプリケーションについて、デスクトップＯＳ １６０は、ブロック２３０６でメニューバー２２２０の中にアプリケーションのアイコンのインスタンスを作成し、ブロック２３０８でそのアイコンをデスクトップＯＳ １６０のコンソールアプリケーションに関連付け、ブロック２３１０でそのアプリケーションのパッケージ名を示すパラメータをそのアイコンに関連付ける。コンソールアプリケーションはデスクトップＯＳ １６０上で動作し、上述の異環境間レンダリングの実施形態を使って、デスクトップＯＳ １６０内にそのアプリケーションに関するグラフィクス情報を表示する。このようにして、ユーザがメニューアイテムを選択すると、コンソールアプリケーションがデスクトップＯＳ １６０上で動作し、そのアプリケーションのパッケージ名がコンソールアプリケーションに送られる。

デスクトップＯＳ １６０は、多様な方法で、モバイルＯＳ １３０のアプリケーションに関連するメニューアイテムを表示してもよい。メニューアイテムは、メニューバー２２２０または、そのモバイルＯＳ用アプリケーションが利用可能であることを示すメニューアイテムが選択された時に現れるドロップダウンメニューの中に表示されてもよい。メニューアイテムは、メニューバー２２２０またはドロップダウンメニューの中でアイコンまたはアプリケーション名のみを使って表示されてもよい。１つの実施形態において、デスクトップＯＳ １６０は、モバイルＯＳ用アプリケーションごとに別のメニューバーを表示する。他の実施形態では、モバイルＯＳ用アプリケーションに関連するメニューアイテムが、デスクトップＯＳ用アプリケーションのメニューアイテムに沿って、または混ざって、デスクトップＯＳのメニューバー２２２０の中に表示される。任意選択的に、モバイルＯＳのメニューアイテムは、メニューバー２２２０の中の、デリミタ２２４０によって仕切られた、またはその他の方法でモバイルＯＳのメニューアイテムが含まれることを特定できるようにされた領域２２３０の中に表示されてもよい。メニューバー２２２０は、モバイルデバイスそのもののアクティブディスプレイ用のメニューアイテム、すなわちユーザが、図２０及び／または２１の方法に従ってデスクトップＯＳのユーザ環境内でモバイルＯＳのユーザ操作空間を表示するために選択できるメニューアイテムを含んでいてもよい。１つの実施形態において、モバイルＯＳのホーム画面のアプリケーションは、利用可能なアプリケーションのリストの中に返され、関連するメニューアイテムが提供される。

ユーザがモバイルＯＳ用アプリケーションに関連するメニューアイテムを選択すると、デスクトップＯＳ １６０がそのニューアイテムに関連するコンソールアプリケーションを起動させ、そのアプリケーションのパッケージ名をコンソールアプリケーションに送る。コンソールアプリケーションは、デスクトップＯＳのユーザ操作空間２２０２の中にウィンドウを１つ表示する（すなわち、デスクトップＯＳのグラフィクスシステムの中のコンソールアプリケーションディスプレイ）。コンソールアプリケーションは、モバイルＯＳ １３０に、そのアプリケーションを起動させる要求を送り（すなわち、モバイルＯＳ １３０に対して、実行パラメータとしてコンソールアプリケーションに提供されたアプリケーションパッケージ名を起動するように要求し）、コンソールアプリケーションを通じてそのアプリケーションに関するグラフィクスフレームを表示する。アプリケーションは、その時点でモバイルＯＳ １３０で動作中であっても、そうでなくてもよい。アプリケーションがモバイルＯＳ １３０上で動作中であれば、そのアプリケーションの表示はモバイルＯＳ １３０からデスクトップＯＳのユーザ操作空間２２０２に移動されても、またはモバイルデバイスのディスプレイとユーザ操作空間２２０２の両方で同時に表示されてもよい。アプリケーショングラフィクスの表示とユーザ操作のサポートは、上述の異環境間レンダリングと異環境間ユーザインタフェースのサポートの方法の何れを使用したアプリケーションについても実行できる。

図２４は、ユーザがデスクトップＯＳのＧＵＩ ８８０のメニューバー２２２０でモバイルＯＳ用アプリケーションに関するメニューアイテムを選択したことに応答して、モバイルＯＳ １３０がアプリケーションを起動させるために実行するプロセスフロー２４００を示す。プロセスフロー２４００はブロック２４０２で、モバイルＯＳ １３０がデスクトップＯＳ １６０から、モバイルＯＳのためにコンパイルされ、モバイルＯＳの実行環境内にロードされたアプリケーションを、デスクトップＯＳで表示するように起動させる要求を受け取ることから始まる。ブロック２４０４で、モバイルＯＳは使用されていない仮想ディスプレイＩＤを割り当てる。例えば、モバイルＯＳのグラフィクスシステムは、仮想ディスプレイＩＤのリストをつけておき、使用されていない仮想ディスプレイＩＤを第一のアプリケーションのプロセスに割り当ててもよい。ブロック２４０６で、モバイルＯＳはモバイルＯＳ内で第一のアプリケーションを起動させる（すなわち、モバイルＯＳ上で動作中となる）。ブロック２４０８で、モバイルＯＳ １３０は、第一のアプリケーションに関するリフレッシュ通知を仮想ディスプレイに関連付ける。例えば、モバイルＯＳのグラフィクスサーバは、アプリケーションとそれに関連する仮想ディスプレイのリストをつけていてもよい。ブロック２４１０と２４１２で、モバイルＯＳは、第一のアプリケーションに関するアプリケーショングラフィクスをモニタし、第一のアプリケーションに関するアプリケーショングラフィクス情報が更新された時にデスクトップＯＳのコンソールアプリケーションに通知することによって、第一のアプリケーションに関するグラフィクス情報を維持する。ブロック２４１０と２４１２は、図１０、１２、１６及び／または１７の方法によって異環境間アプリケーションに関するアプリケーショングラフィクスを維持することに対応していてもよい。

上記の説明は、例示と説明を目的としている。さらに、この説明は本発明の実施形態を本明細書で開示されている形態に限定することを意図していない。多数の例示的な態様と実施形態を上で説明したが、当業者であれば、そのいくつかの変更、改良、置換、追加、サブコンビネーションに気付くであろう。

上述の方法の各種の操作は、それに対応する機能を果たすことのできる、どのような適当な手段で実行してもよい。この手段としては、各種のハードウェア及び／またはソフトウェアコンポーネント及び／またはモジュール等があり、これには回路、特定用途集積回路（ＡＳＩＣ）またはプロセッサが含まれるが、これらに限定されない。

前述の種々の例示的な論理ブロック、モジュール、回路は、本明細書に記載の機能を実行するように設計された、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ＡＳＩＣ、フィールドプログラマブルゲートアレイ信号（ＦＰＧＡ）またはその他のプログラム可能論理デバイス（ＰＬＤ）、ディスクリートゲート、またはトランジスタロジック、ディスクリートハードウェアコンポーネントまたはこれらのどのような組合せにより実装または実行されてもよい。汎用プロセッサは、マイクロプロセッサであってもよく、あるいは、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラまたはステートマシンであってもよい。プロセッサまた、コンピューティングデバイスの組合せ、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと併用される１つまたは複数のマイクロプロセッサ、またはその他の同様の構成として実装されてもよい。

本明細書に関連して説明した方法またはアルゴリズムのステップは、ハードウェアで直接でも、プロセッサにより実行されるソフトウェアモジュールでも、またはこれら２つの組合せでも実施してよい。ソフトウェアモジュールは、どのような形態の有形記憶媒体の中に記憶されてもよい。使用できる記憶媒体の例としては、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、フラッシュメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ等がある。記憶媒体はプロセッサに、プロセッサがその記憶媒体から情報を読み出し、そこに情報を書き込むことができるように接続されてもよい。あるいは、記憶媒体はプロセッサに内蔵されてもよい。ソフトウェアモジュールは１つの命令でも、多くの命令でもよく、いくつかの異なるコードセグメント上で、異なるプログラム間で、及び複数の記憶媒体間で分散されていてもよい。

本明細書に記載の方法は、記載された方法を実現するための１つまたは複数の動作を含む。この方法及び／または動作は、他の方法や動作と交換してもよく、特許請求の範囲から逸脱しない。換言すれば、動作の特定の順序が明示されていないかぎり、特定の動作の順序及び／または用途を変更でき、これも本特許請求の範囲から逸脱しない。

説明した機能は、ハードウェア、ソフトウェア、ファームウェアまたはそれらの組合せによって実施してもよい。ソフトウェアで実行される場合、その機能は１つまたは複数の命令として有形のコンピュータ読取可能媒体に記憶されてもよい。記憶媒体は、コンピュータがアクセス可能な任意の利用可能な有形の記憶媒体であってもよい。例えば、これらに限定されないが、このようなコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または、命令またはデータ構造の形態で所望のプログラムコードを担持または記憶するために使用可能であり、コンピュータによりアクセス可能な任意の有形の媒体であってもよい。本明細書において、ディスク（ｄｉｓｋ，ｄｉｓｃ）とは、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスクを含み、ｄｉｓｋは通常、磁気的にデータを再生するのに対し、ｄｉｓｃはレーザを使って光学的にデータを再生する。

それゆえ、コンピュータプログラム製品が本明細書に記載された動作を実行してもよい。例えば、このようなコンピュータブログラム製品はコンピュータ読取可能な有形の媒体であってもよく、そこに命令が有形の状態で格納され（及び／または暗号され）、命令は１つまたは複数のプロセッサによって実行可能で、本明細書に記載された動作が行われる。コンピュータプログラム製品には、パッケージング材料が含まれていてもよい。

ソフトウェアまたは命令はさらに、伝送媒体上で伝送されてもよい。例えば、ソフトウェアは、ウェブサイト、サーバまたは、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、デジタル加入者線（ＤＳＬ）等の伝送媒体または、赤外線、無線またはマイクロ波等の無線技術を用いて他の遠隔提供源から伝送されてもよい。

さらに、本明細書に記載された方法と方式を実行するためのモジュール及び／またはその他の適当な手段は、場合に応じてユーザ端末及び／または基地局によりダウンロードし、及び／またはその他の方法で取得することが可能である。例えば、このようなデバイスをサーバにつないで、本明細書に記載された方法を実行するための手段を伝送しやすくすることができる。あるいは、本明細書に記載された各種の方法は、記憶手段（例えば、ＲＡＭ、ＲＯＭ、ＣＤやフロッピーディスク等の物理的記憶媒体等）を介して提供することができ、それによってユーザ端末及び／または基地局は、記憶手段をデバイスにつなぐか提供した時に、各種の方法を取得できる。さらに、本明細書に記載された方法と方式をデバイスに提供するために、他の適当な技術を利用することができる。

その他の例及び実施例も、本明細書と付属の特許請求の範囲の範囲及び主旨の中に含まれる。例えば、ソフトウェアの性質から、上述の機能は、プロセッサ、ハードウェア、ファームウェア、ハードワイヤリングまたはそれらの組み合わせによって実行されるソフトウェアを使って実施できる。機能を実施する特徴はまた、様々な位置に物理的に配置されていてもよく、例えば、機能の各部分が異なる物理的場所で実行されるように分散される。また、特許請求の範囲を含む本明細書において、「少なくとも」に続いて羅列される項目の中で使用される「または」という用語は、離接的な一覧を示しており、例えば、「少なくともＡ、ＢまたはＣ」とは、ＡまたはＢまたはＣまたはＡＢまたはＡＣまたはＢＣまたはＡＢＣ（すなわち、ＡとＢとＣ）を意味する。さらに、「例示的」という用語は、説明された例が他の例より好ましい、またはよりよいこと意味しない。

本明細書で説明した方式について、各種の変更、代替、改良を行うことができ、これも付属の特許請求の範囲により定義される教示内容の方式から逸脱しない。さらに、明細書と特許請求の範囲の範囲は、上述の工程、機械、製品、物体の組成、手段、方法、動作の特定の態様に限定されない。本明細書で説明したものと実質的に同じ機能を果たし、あるいはそれと実質的に同じ結果を達成する、既存の、または今後開発される工程、機械、製品、物体の組成、手段、方法または動作を利用してもよい。従って、付属の特許請求の範囲は、このような工程、機械、製品、物体の組成、手段、方法または動作をその範囲内に包含する。

Claims (19)

1. 方法であって、
   第二の実行環境を有する第二のオペレーティングシステムによって、第一のオペレーティングシステムのためにコンパイルされ、前記第一のオペレーティングシステムの第一の実行環境内にロードされたアプリケーションのリストを前記第一のオペレーティングシステムに問い合わせることであって、前記第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、前記問い合わせること、
   前記第二のオペレーティングシステムにおいて、アプリケーションオブジェクトのリストを受け取ることであって、各アプリケーションオブジェクトがアプリケーションパッケージを含む、前記受け取ること、
   前記第二のオペレーティングシステムのメニューにおいて、前記アプリケーションオブジェクトのリストの中の１つのアプリケーションオブジェクトに対応する第一のメニューアイテムのインスタンスを作成すること、
   前記第一のメニューアイテムが、選択された時に、前記第二のオペレーティングシステムのコンソールアプリケーションを実行するように、前記第一のメニューアイテムを前記第二のオペレーティングシステムの前記コンソールアプリケーションに関連付けること、
   前記アプリケーションオブジェクトに対応する前記第一のＯＳの中の前記アプリケーションパッケージを示すパラメータを、前記第一のメニューアイテムに関連付けること
   含む、方法。
2. 請求項１に記載の方法であって、前記第一のオペレーティングシステムの第一のグラフィクスサーバが、前記第二のオペレーティングシステムの第二のグラフィクスサーバと非互換的である、方法。
3. 請求項１に記載の方法であって、第一のグラフィクスサーバがＡｎｄｒｏｉｄ用グラフィクスサーバを含み、第二のグラフィクスサーバがＸウィンドウ型のグラフィクスサーバを含む、方法。
4. 請求項１に記載の方法であって、前記第二のオペレーティングシステムのグラフィクスサーバがＸウィンドウ型のグラフィクスサーバであり、前記第一のオペレーティングシステムの、前記アプリケーションオブジェクトに対応するアプリケーションが、前記第二のオペレーティングシステムの前記Ｘウィンドウ型のグラフィクスサーバと非互換的なグラフィクスライブラリを使用する、方法。
5. 請求項１に記載の方法であって、前記アプリケーションオブジェクトが、アプリケーション名、アプリケーションパッケージ名、およびアプリケーションアイコンを含む、方法。
6. 請求項１に記載の方法であって、前記第一のメニューアイテムが、選択されると、アプリケーションパッケージ名を実行パラメータとして前記コンソールアプリケーションに送る、方法。
7. 請求項１に記載の方法であって、前記第二のオペレーティングシステムのメニューが、第二のアプリケーションに対応する第二のメニューアイテムを含み、前記第二のアプリケーションが前記第二の実行環境のためにコンパイルされ、前記第二の実行環境内にロードされている、方法。
8. 請求項１に記載の方法であって、前記第一のオペレーティングシステムがモバイルオペレーティングシステムを含み、前記第二のオペレーティングシステムがデスクトップオペレーティングシステムを含む、方法。
9. 方法であって、
   第一のオペレーティングシステムのためにコンパイルされ、前記第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを、前記第一のオペレーティングシステムにおいて起動させるための要求を、前記第一のオペレーティングシステムによって、第二のオペレーティングシステムから受け取ることであって、前記第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、前記受け取ること、
   前記第一のオペレーティングシステムによって仮想ディスプレイを割り当てること、
   前記第一のオペレーティングシステム内のプロセスにおいて前記第一のアプリケーションを起動させること、
   前記第一のアプリケーションのためのリフレッシュ通知を前記仮想ディスプレイに関連付けること、
   前記第一のアプリケーションのためのアプリケーショングラフィクスを、
   前記第一のオペレーティングシステムによって、前記第一のアプリケーションのアプリケーショングラフィクス情報をモニタするステップと、
   前記アプリケーショングラフィクス情報が更新された時に、前記第二のオペレーティングシステムのコンソールアプリケーションに通知するステップと
   を繰り返し実行することによって維持すること
   を含む、方法。
10. 請求項９に記載の方法であって、前記第二のオペレーティングシステムのコンソールアプリケーションに通知するステップが、ファイル記述子を前記コンソールアプリケーションに送ることを含み、前記ファイル記述子は、前記アプリケーショングラフィクス情報が共有メモリ位置において利用可能であることを示しており、前記共有メモリ位置が前記第一のオペレーティングシステムと前記第二のオペレーティングシステムとによってアクセス可能である、方法。
11. 請求項１０に記載の方法であって、前記ファイル記述子が、プロセス間通信チャネルを通じて送られる、方法。
12. 請求項１１に記載の方法であって、前記プロセス間通信チャネルが、ローカルソケットを含む、方法。
13. 請求項１１に記載の方法であって、前記プロセス間通信チャネルが、Ｕｎｉｘドメインソケットを含む、方法。
14. 請求項１１に記載の方法であって、前記プロセス間通信チャネルが、Ｂｉｎｄｅｒインタフェースを含む、方法。
15. 請求項１４に記載の方法であって、前記アプリケーショングラフィクス情報が、前記第一のアプリケーションのサーフェス情報を含む、方法。
16. 請求項１４に記載の方法であって、前記アプリケーショングラフィクス情報が、前記第一のアプリケーションの、レンダリングされたグラフィクス情報を含む、方法。
17. 請求項１４に記載の方法であって、前記第二のオペレーティングシステムが、ユーザが前記第二のオペレーティングシステムのメニューのメニューアイテムを選択したことに応答して、前記第一のアプリケーションを起動させる要求を発行する、方法。
18. 方法であって、
    第一のオペレーティングシステムのためにコンパイルされ、前記第一のオペレーティングシステムの第一の実行環境内にロードされた第一のアプリケーションを起動させる要求を、前記第一のオペレーティングシステムによって、第二のオペレーティングシステムのコンソールアプリケーションから受け取ることであって、前記第一及び第二のオペレーティングシステムが共有カーネル上で同時動作中である、前記受け取ること、
    前記第一のオペレーティングシステム上の第一のプロセス内で前記第一のアプリケーションを実行することであって、前記第一のアプリケーションが、前記第一のオペレーティングシステムのサーフェスマネージャによって維持されるグラフィクス情報を含む、前記実行すること、
    前記第一のオペレーティングシステムによって、前記コンソールアプリケーションを前記第一のオペレーティングシステムの仮想ディスプレイ識別子に関連付けること、
    前記コンソールアプリケーションを登録して、前記第一のアプリケーションの前記グラフィクス情報に関するリフレッシュ通知を受け取ること
    を含む、方法。
19. 請求項１８に記載の方法であって、
    前記サーフェスマネージャにより、グラフィクスフレームを前記第一のオペレーティングシステムのフレームバッファメモリにレンダリングすること、
    前記第一のアプリケーションに関するグラフィクス情報が更新されたら、前記コンソールアプリケーションに通知すること
    をさらに含む、方法。