JP2016212874A - アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 - Google Patents
アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 Download PDFInfo
- Publication number
- JP2016212874A JP2016212874A JP2016093158A JP2016093158A JP2016212874A JP 2016212874 A JP2016212874 A JP 2016212874A JP 2016093158 A JP2016093158 A JP 2016093158A JP 2016093158 A JP2016093158 A JP 2016093158A JP 2016212874 A JP2016212874 A JP 2016212874A
- Authority
- JP
- Japan
- Prior art keywords
- application program
- rendering
- graphic
- texture
- parameter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Controls And Circuits For Display Device (AREA)
- Digital Computer Display Output (AREA)
- Image Generation (AREA)
Abstract
【課題】アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法の提供。【解決手段】アプリケーションプログラムのグラフィック（ｇｒａｐｈｉｃ）をレンダリング（ｒｅｎｄｅｒｉｎｇ）する方法において、アプリケーションプログラムはサーバーにおいて執行され、しかもグラフィックをユーザーエンドでレンダリングする。該方法は以下のステップを含む。サーバーはレンダリングコマンド、パラメーター及び／或いはテクスチャー（ｔｅｘｔｕｒｅ）を受け取り、レンダリングコマンド、パラメーター及び／或いはテクスチャーを、ユーザーエンドのドライバープログラムに伝送し、ユーザーエンドのグラフィクス処理ユニット（ＧＰＵ）により、グラフィックをレンダリングする。【選択図】図２Ｃ
Description
本発明はユーザーによるインプット、或いはハードウエアによるインプットを通してユーザーインターフェースを生じるシステムと方法で、特にバーチャルマシンに接続するアプリケーションプログラムにユーザーインターフェース或いはスクリーン画面を生じさせるアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法に関する。
アプリケーションプログラムＡｒｏｗｓｅｒ（以下「ＡｒｏｗｓｅｒTM」と呼称）は、特許文献１で初めて開示された。その名称は「ＭＥＴＨＯＤＳ ＡＮＤ ＳＹＳＴＥＭＳ ＦＯＲ ＩＮ-ＡＰＰＳ ＳＥＡＲＣＨ ＡＮＤ ＡＰＰ ＢＲＯＷＳＥＲＳ」で、２０１３年１０月７日に申請されている。
それは、アプリケーションプログラムをリモートエンドサーバーにおいて執行し、しかも該アプリケーションプログラムのスクリーン画面はその後、該リモートエンドサーバーからユーザーエンドへと伝送或いはストリームされ、ユーザーエンドインターフェース上に表示される（例えば、ＡｒｏｗｓｅｒTMに表示される）。ＡｒｏｗｓｅｒTM技術の協力により、ユーザーは、ストリームスクリーン画面とのインタラクティブにより、アプリケーションプログラムをリモート操作し、ローカルエンドにおいて、該アプリケーションプログラムをインストール必要はない。
従来は、リモートエンドサーバーは通常、グラフィクス処理ユニット（ＧＰＵ）を備えなければ、レンダリングし、イメージストリーム方式により、ユーザーエンドのａｐｐ画面に伝送しアウトプット（ｓｃｒｅｅｎ ｏｕｔｐｕｔ）することはできなかった。しかし、これでは、リモートエンドサーバーは、ディスプレイカード（ｄｉｓｐｌａｙ ｃａｒｄ）を搭載しなければならない。これにより、ハードウエアのコストが拡大するばかりか、ＧＰＵはリモートエンドサーバー上の他のハードウエアパーツに比べ、作動時により多くのエネルギーを消費するため、電力消費或いは散熱の面でも大きな問題を抱えている。
前記先行技術には、リモートエンドサーバーがディスプレイカードを搭載しなければならず、これによりハードウエアのコストが拡大し、さらにＧＰＵはリモートエンドサーバー上の他のハードウエアパーツに比べ、作動時により多くのエネルギーを消費するため、電力消費或いは散熱の面でも大きな問題があるという欠点がある。
本発明はアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法に関する。
本発明によるアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法のもう一つの実施形態は、アプリケーションプログラムのグラフィック（ｇｒａｐｈｉｃ）をレンダリング（ｒｅｎｄｅｒｉｎｇ）する方法を提供する。該アプリケーションプログラムは、サーバーにおいて執行され、しかも該グラフィックをユーザーエンドでレンダリングする。
該方法は以下のステップを含む。
該サーバーは、レンダリングコマンド、パラメーター及び／或いはテクスチャー（ｔｅｘｔｕｒｅ）を受け取る。
該レンダリングコマンド、該パラメーター及び／或いは該テクスチャーを、該ユーザーエンドのドライバープログラムに伝送し、該ユーザーエンドのグラフィクス処理ユニット（ＧＰＵ）により、該グラフィックをレンダリングする。
該サーバーは、レンダリングコマンド、パラメーター及び／或いはテクスチャー（ｔｅｘｔｕｒｅ）を受け取る。
該レンダリングコマンド、該パラメーター及び／或いは該テクスチャーを、該ユーザーエンドのドライバープログラムに伝送し、該ユーザーエンドのグラフィクス処理ユニット（ＧＰＵ）により、該グラフィックをレンダリングする。
本発明によるアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法のさらにもう一つの実施形態は、第一アプリケーションプログラムを提供する。
それはユーザーエンドにおいて執行され、サーバーの第二アプリケーションプログラムにおいて執行され、グラフィックをレンダリングする。
該第一アプリケーションプログラムは、レシーバーを有する。
該レシーバーは、該サーバーの一レンダリングコマンド、パラメーター及び／或いはテクスチャーを受け取り、しかも該レンダリングコマンド、該パラメーター及び／或いは該テクスチャーを、該ユーザーエンドのグラフィクス処理ユニットと関連するドライバープログラムに伝送し、該レンダリングコマンド、該パラメーター及び／或いは該テクスチャーに基づき、該グラフィックをレンダリングする。
それはユーザーエンドにおいて執行され、サーバーの第二アプリケーションプログラムにおいて執行され、グラフィックをレンダリングする。
該第一アプリケーションプログラムは、レシーバーを有する。
該レシーバーは、該サーバーの一レンダリングコマンド、パラメーター及び／或いはテクスチャーを受け取り、しかも該レンダリングコマンド、該パラメーター及び／或いは該テクスチャーを、該ユーザーエンドのグラフィクス処理ユニットと関連するドライバープログラムに伝送し、該レンダリングコマンド、該パラメーター及び／或いは該テクスチャーに基づき、該グラフィックをレンダリングする。
本発明のアプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法は、リモートエンドサーバーがディスプレイカードを搭載しなければならず、これによりハードウエアのコストが拡大し、さらにＧＰＵはリモートエンドサーバー上の他のハードウエアパーツに比べ、作動時により多くのエネルギーを消費するため、電力消費或いは散熱の面でも大きな問題があるという公知技術に存在する欠点を解決できる。
図１Ａは、Ａｎｄｒｏｉｄ（登録商標）オペレーションシステムのアーキテクチャーの模式図である。モバイルオペレーションシステム（モバイルオペレーションシステムは、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）等）を有し、スマート型デバイス上（スマートフォン等）で作動する。
該技術領域の習熟者は理解できるように、Ａｎｄｒｏｉｄ（登録商標）とは異なるランタイム（ｒｕｎｔｉｍｅ）を備えるいくつかのモバイルオペレーションシステム（Ａｎｄｒｏｉｄ（登録商標）のランタイムは、Ｄａｌｖｉｋバーチャルマシン或いはコアライブラリーを含み、異なるオペレーションシステムは、他のライブラリー或いはバーチャルマシンを有する）以外は、他のモバイルオペレーションシステムも、図１Ａの記述及び表示に類似の機能／構造を備える。
いくつかのモバイルオペレーションシステムは、異なるハードウエア設計に対して特殊化したハードウエア抽象化レイヤー（ＨＡＬ）を含まないかも知れない。該項技術領域への習熟者は理解できるように、これらモバイルオペレーションシステムの間の差異は、本発明が主張する特許請求の範囲に影響しない。
従来は、アプリケーション層（図１Ａでは「アプリケーションプログラム」）中のモバイルアプリケーションプログラム（ダウンロード、ネイティブ、Ｗｅｂバージョン或いは混合バージョンモバイルアプリケーションプログラムなど。以下では「Ａｐｐ」と呼称）は、アプリケーションプログラムを使用し、インターフェース（ＡＰＩ）を設計発展させて、スマート型デバイスのハードウエアリソースから、データを取得する。アプリケーションプログラムはインターフェースを設計発展させ、ユーザーのニーズ或いはインプットに基づき、ファイル或いはデータを産生し、ハードウエアデバイス（例えば、チップ、センサー或いはハードウエアモジュール）に送る。
本説明では、ハードウエアデータとは、ハードウエアリソースからの任意のデータ、或いはアプリケーションプログラムが設計発展させたインターフェースが産生しハードウエアリソースに送った任意のデータである。例えば、ユーザーは、スマート型デバイスのタッチスクリーン或いは他のインプット方式を通して、スマート型デバイスにおいて、Ａｐｐをインストール／執行／ラン／操作（以下では操作と総称）する。いわゆる他のインプット方式とは、ドライバープログラムインヴォーク（ｉｎｖｏｋｅ）を通して、対応するハードウエアデバイスの方式を言う。
Ａｐｐを操作すると、スマートフォンのカメラモジュールは、カメラＡｐｐを使用する。つまり、ハードウエアデバイスをインヴォーグする実施形態である。ユーザーがシャッターボタンをタッチ或いは押すと、カメラＡｐｐは、スマート型デバイスのカメラモジュールにイメージを取得する（例えば、ｒａｗ、ｊｐｇ、ｊｐｅｇ、ｐｎｇ或いは他のイメージフォーマット等のバイナリフォーマットイメージを産生する）よう指示する。しかも、イメージを、メモリ中（例えば、ランダム・アクセス・メモリ、フラッシュメモリ、キャッシュ、ＳＤカード或いはクラウド等の他の保存空間）に保存する。
図１Ｂは、グラフィックをレンダリング時にハードウエアデバイス（例えば、表示デバイス或いはグラフィクス処理ユニット）をインヴォーグする別種の実施形態の模式図である。１個のＡｐｐがグラフィックのレンダリングを執行している時、アプリケーションプログラムの開発者が、どの種のＡＰＩ（或いはレンダリングＡＰＩ）を使用していようが、イメージは画素データのバッファーにレンダリングされる。
これを「レイヤー」と呼ぶ。
従来は、Ａｐｐが他の内容をレンダリングすると、Ａｎｄｒｏｉｄ（登録商標）の１個のレイヤーは、１個のオフスクリーンバッファー（ｏｆｆ-ｓｃｒｅｅｎ ｂｕｆｆｅｒ）に対応する。
Ａｎｄｒｏｉｄ（登録商標）プラットフォームで作られたすべてのウィンドウは、１個のレイヤーにより復位（ｂａｃｋｅｄ）される。
正確に言えば、各ウィンドウはすべて１個のレイヤーの表示結果（ウィンドウを形成するすべての画素は、レイヤー／バッファーの保存される）。
これを「レイヤー」と呼ぶ。
従来は、Ａｐｐが他の内容をレンダリングすると、Ａｎｄｒｏｉｄ（登録商標）の１個のレイヤーは、１個のオフスクリーンバッファー（ｏｆｆ-ｓｃｒｅｅｎ ｂｕｆｆｅｒ）に対応する。
Ａｎｄｒｏｉｄ（登録商標）プラットフォームで作られたすべてのウィンドウは、１個のレイヤーにより復位（ｂａｃｋｅｄ）される。
正確に言えば、各ウィンドウはすべて１個のレイヤーの表示結果（ウィンドウを形成するすべての画素は、レイヤー／バッファーの保存される）。
すべての可視のレイヤーは、レンダリングを経て、ＳｕｒｆａｃｅＦｌｉｎｇｅｒを通して、ディスプレイ上に統合される。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、Ａｎｄｒｏｉｄ（登録商標）のレイヤー統合の管理に用いる一種のシステムサービス（或いはＡｎｄｒｏｉｄ（登録商標）フレームに常駐する一種の全システムレイヤー統合機能）である。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、異なるＡｐｐからデータ（つまり、レイヤー）を取り出す。
これらデータは、２Ｄ或いは３Ｄである。
それは統合を経た後、主要レイヤーを取得し、メモリ（フレームメモリを含み、或いはフレームメモリを含むよう設定することができる）をフィードインする。
この他、ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、オーバーラップしたパラメーターなどを計算でき、ＯｐｅｎＧＬ ＥＳをインヴォークする。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、Ａｎｄｒｏｉｄ（登録商標）のレイヤー統合の管理に用いる一種のシステムサービス（或いはＡｎｄｒｏｉｄ（登録商標）フレームに常駐する一種の全システムレイヤー統合機能）である。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、異なるＡｐｐからデータ（つまり、レイヤー）を取り出す。
これらデータは、２Ｄ或いは３Ｄである。
それは統合を経た後、主要レイヤーを取得し、メモリ（フレームメモリを含み、或いはフレームメモリを含むよう設定することができる）をフィードインする。
この他、ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、オーバーラップしたパラメーターなどを計算でき、ＯｐｅｎＧＬ ＥＳをインヴォークする。
１個のＡｐｐの観点から見ると、各Ａｐｐは、少なくとも１個の図形化インターフェースに対応でき、しかも各インターフェースは、その位置、容量、内容及び他の要素を備える１個のレイヤーとして見られる。
Ａｎｄｒｏｉｄ（登録商標） ３．０の紹介を見ると、そのＣａｎｖａｓ ＡＰＩに対するハードウエア加速は、ＯｐｅｎＧＬＲｅｎｄｅｒｅｒと呼ばれる新式ドローイングライブラリーを採用している。
該ドローイングライブラリーは、Ｃａｎｖａｓの操作を、ＯｐｅｎＧＬの操作に転換できるため、図形化処理ユニット（例えば、ハードウエアに加速されるＣａｎｖａｓ）において執行される。
Ａｎｄｒｏｉｄ（登録商標） ３．０の紹介を見ると、そのＣａｎｖａｓ ＡＰＩに対するハードウエア加速は、ＯｐｅｎＧＬＲｅｎｄｅｒｅｒと呼ばれる新式ドローイングライブラリーを採用している。
該ドローイングライブラリーは、Ｃａｎｖａｓの操作を、ＯｐｅｎＧＬの操作に転換できるため、図形化処理ユニット（例えば、ハードウエアに加速されるＣａｎｖａｓ）において執行される。
現在、ＯｐｅｎＧＬ ＥＳ ２．０を支援する図形化処理ユニットハードウエアは、信託管理され、これによりＡｎｄｒｏｉｄ（登録商標）デバイスはＡｎｄｒｏｉｄ（登録商標） ４．０或いはそのアップグレードバージョンを執行することができる。
Ａｎｄｒｏｉｄ（登録商標）は、Ａｎｄｒｏｉｄ（登録商標）．ｏｐｅｎｇｌパッケージ中で、ＯｐｅｎＧＬ ＥＳインターフェースを提供する。
これにより、Ａｐｐ開発者は、標準開発キット（ＳＤＫ）或いはＡｎｄｒｏｉｄ（登録商標）ネイティブ開発キット（ＮＤＫ）が提供するネイティブＡＰＩを利用し、これを開発者のＧＬ実装中に呼び出すことができる。
Ａｎｄｒｏｉｄ（登録商標）は、Ａｎｄｒｏｉｄ（登録商標）．ｏｐｅｎｇｌパッケージ中で、ＯｐｅｎＧＬ ＥＳインターフェースを提供する。
これにより、Ａｐｐ開発者は、標準開発キット（ＳＤＫ）或いはＡｎｄｒｏｉｄ（登録商標）ネイティブ開発キット（ＮＤＫ）が提供するネイティブＡＰＩを利用し、これを開発者のＧＬ実装中に呼び出すことができる。
図１Ｃに示す通り、グラフィックレンダリングに関わるパーツは、イメージストリームプロデューサー（ｉｍａｇｅ ｓｔｒｅａｍ ｐｒｏｄｕｃｅｒ）、イメージストリームコンシューマー（ｉｍａｇｅ ｓｔｒｅａｍ ｃｏｎｓｕｍｅｒ）、サーフェイステクスチャー、ウィンドウマネージャー（ｗｉｎｄｏｗｓ ｍａｎａｇｅｒ）、ハードウエアコンポーザー（ｈａｒｄｗａｒｅ ｃｏｍｐｏｓｅｒ）及びＧｒａｌｌｏｃを有する。
イメージストリームプロデューサーは、可包含一ＯｐｅｎＧＬ ＥＳゲーム、メディアサーバーからのビデオバッファ、１個のＣａｎｖａｓ２Ｄアプリケーションプログラム、或いは産生されたグラフィックを緩衝消費できる任意の他の物件を有する。
イメージストリームプロデューサーは、可包含一ＯｐｅｎＧＬ ＥＳゲーム、メディアサーバーからのビデオバッファ、１個のＣａｎｖａｓ２Ｄアプリケーションプログラム、或いは産生されたグラフィックを緩衝消費できる任意の他の物件を有する。
最もよく見られるイメージストリームのコンシューマーは、ＳｕｒｆａｃｅＦｌｉｎｇｅｒで、それは可視レイヤーを消費し、ウィンドウマネージャーが提供する情報を使用し、可視レイヤーをディスプレイに統合する。
他のＯｐｅｎＧＬ ＥＳ Ａｐｐも、イメージストリームを消費でき、例えば前記のカメラＡｐｐは、カメラプレビューイメージストリームの消費に用いられる。
他のＯｐｅｎＧＬ ＥＳ Ａｐｐも、イメージストリームを消費でき、例えば前記のカメラＡｐｐは、カメラプレビューイメージストリームの消費に用いられる。
サーフェイステクスチャーが含むロジックは、イメージストリームプロデューサーとイメージストリームコンシューマーをまとめ、しかも以下の三部分により構成される。
それは、サーフェイステクスチャーユーザーエンド（ＳｕｒｆａｃｅＴｅｘｔｕｒｅＣｌｉｅｎｔ）、Ｉサーフェイステクスチャー（ＩＳｕｒｆａｃｅＴｅｘｔｕｒｅ）及びサーフェイステクスチャー（ＳｕｒｆａｃｅＴｅｘｔｕｒｅ）である（本実施形態では、サーフェイステクスチャーは、Ｃ＋＋の実際のカテゴリー名称で、すべてのアセンブリの名称ではない）。
それは、サーフェイステクスチャーユーザーエンド（ＳｕｒｆａｃｅＴｅｘｔｕｒｅＣｌｉｅｎｔ）、Ｉサーフェイステクスチャー（ＩＳｕｒｆａｃｅＴｅｘｔｕｒｅ）及びサーフェイステクスチャー（ＳｕｒｆａｃｅＴｅｘｔｕｒｅ）である（本実施形態では、サーフェイステクスチャーは、Ｃ＋＋の実際のカテゴリー名称で、すべてのアセンブリの名称ではない）。
上述の三部分は、イメージプロデューサー（サーフェイステクスチャーユーザーエンド等）、合成（ｂｉｎｄｅｒ）（Ｉサーフェイステクスチャー等）、及びイメージコンシューマー（サーフェイステクスチャー等）等のサーフェイステクスチャー構成部材の作動を助ける。
例えば、Ｇｒａｌｌｏｃ（ハードウエア抽象化レイヤーの一部分）からメモリ空間、プログラムの境界を跨ぎメモリ空間をシェア、同期にバッファーにアクセス、及び適したコンシューマーとプロデューサーの組合せを提供するよう請求する。
例えば、Ｇｒａｌｌｏｃ（ハードウエア抽象化レイヤーの一部分）からメモリ空間、プログラムの境界を跨ぎメモリ空間をシェア、同期にバッファーにアクセス、及び適したコンシューマーとプロデューサーの組合せを提供するよう請求する。
サーフェイステクスチャーは、同期と非同期の二つのモードで同時に操作することができる。
非同期モード中では、イメージプロデューサーはブロッキングされず、しかもイメージコンシューマーはフレームを放棄或いは無視することができる。
同期モード中では、イメージプロデューサーは、ブロッキングされ、これによりイメージコンシューマーはテクスチャー処理を許される。
いくつかの例において、イメージプロデューサーは、カメラのハードウエア抽象化レイヤーを通して、産生されたプレビュー、或いは一種のＯｐｅｎＧＬ ＥＳゲームである。
非同期モード中では、イメージプロデューサーはブロッキングされず、しかもイメージコンシューマーはフレームを放棄或いは無視することができる。
同期モード中では、イメージプロデューサーは、ブロッキングされ、これによりイメージコンシューマーはテクスチャー処理を許される。
いくつかの例において、イメージプロデューサーは、カメラのハードウエア抽象化レイヤーを通して、産生されたプレビュー、或いは一種のＯｐｅｎＧＬ ＥＳゲームである。
ウィンドウマネージャーは、Ａｎｄｒｏｉｄ（登録商標）システムサービスで、ウィンドウのライフサイクル、インプットとフォーカスイベント、スクリーンガイド方向、トランジション、動画、位置、転換、Ｚ-オーダー、及びウィンドウの他の多くの方向（容器の角度により検視）をコントロールする。
１個のウィンドウは、いつも１個のレイヤーによりセットオフされ、ウィンドウマネージャーはすべてのウィンドウのメタデータ（ｍｅｔａｄａｔａ）をＳｕｒｆａｃｅＦｌｉｎｇｅｒに発送する。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒはこうして、それらデータを採用し、いかにしてレイヤーをディスプレイ上に統合するかを推測する。
１個のウィンドウは、いつも１個のレイヤーによりセットオフされ、ウィンドウマネージャーはすべてのウィンドウのメタデータ（ｍｅｔａｄａｔａ）をＳｕｒｆａｃｅＦｌｉｎｇｅｒに発送する。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒはこうして、それらデータを採用し、いかにしてレイヤーをディスプレイ上に統合するかを推測する。
ハードウエアシンセサイザーは、ディスプレイサブシステムに対してハードウエアアブストラクション（ｈａｒｄｗａｒｅ ａｂｓｔｒａｃｔｉｏｎ）とする（それは、ハードウエア抽象化レイヤーの一部分）。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、オーバーラップと２Ｄブリッター（ｂｌｉｔｔｅｒ）をアブストラクションでき、一部の統合作業を、ハードウエアシンセサイザーに委託し、ＯｐｅｎＧＬとグラフィクス処理ユニットからの作業をアンインストールする。
これは、ＳｕｒｆａｃｅＦｌｉｎｇｅｒを使用し、すべてのミッションを執行するより、統合は迅速である。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、オーバーラップと２Ｄブリッター（ｂｌｉｔｔｅｒ）をアブストラクションでき、一部の統合作業を、ハードウエアシンセサイザーに委託し、ＯｐｅｎＧＬとグラフィクス処理ユニットからの作業をアンインストールする。
これは、ＳｕｒｆａｃｅＦｌｉｎｇｅｒを使用し、すべてのミッションを執行するより、統合は迅速である。
この他、Ｇｒａｌｌｏｃは、グラフィックバッファーにメモリを分配する。
それは以下の二部分に分けられる。
一つは、ｐｍｅｍインターフェースが連続を担当するメモリを提供する。
もう一つは、フレームバッファーのリフォームを処理する。
このフレームバッファーは、ユーザーインターフェースが実質的にフレーム緩衝データを置く位置である。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、新表示ハードウエアのクリエイト作業を執行し、ローカルウィンドウフレームバッファーを確立し、データアウトプットデバイスインターフェースを決定する。
初期化ＯｐｅｎＧＬは、合成フレーム緩衝データのようで、及びすべてのレイヤーを合併することで、主要レイヤーをクリエイトする。
それは以下の二部分に分けられる。
一つは、ｐｍｅｍインターフェースが連続を担当するメモリを提供する。
もう一つは、フレームバッファーのリフォームを処理する。
このフレームバッファーは、ユーザーインターフェースが実質的にフレーム緩衝データを置く位置である。
ＳｕｒｆａｃｅＦｌｉｎｇｅｒは、新表示ハードウエアのクリエイト作業を執行し、ローカルウィンドウフレームバッファーを確立し、データアウトプットデバイスインターフェースを決定する。
初期化ＯｐｅｎＧＬは、合成フレーム緩衝データのようで、及びすべてのレイヤーを合併することで、主要レイヤーをクリエイトする。
バーチャルマシンは、モバイルＡｐｐを信託管理できるモバイルオペレーションシステム上において執行される。
一般的に、モバイルオペレーションシステムで作動されるバーチャルマシンは、図１Ａ或いは図１Ｂのスマート型デバイスが、パーソナルコンピューター或いはサーバーにより作動されるバーチャルマシンに置換されない限り、図１Ａ或いは図１Ｂに相同か、或いは近似したオペレーションシステムアーキテクチャーを有する。
よって、ハードウエアデータと関連するライブラリー或いはＡＰＩは、モバイルオペレーションシステムが支援するリアルハードウエアに接続しない。
一般的に、モバイルオペレーションシステムで作動されるバーチャルマシンは、図１Ａ或いは図１Ｂのスマート型デバイスが、パーソナルコンピューター或いはサーバーにより作動されるバーチャルマシンに置換されない限り、図１Ａ或いは図１Ｂに相同か、或いは近似したオペレーションシステムアーキテクチャーを有する。
よって、ハードウエアデータと関連するライブラリー或いはＡＰＩは、モバイルオペレーションシステムが支援するリアルハードウエアに接続しない。
一実施形態中では、グラフィクス処理ユニット（図３Ａと図３Ｂに示すハードウエアデバイス１２或いはＧＰＵ１２’参照）の使用を通して、第一計算デバイス１００上のユーザーインターフェース２１８において、グラフィック２２６をレンダリングし、しかも相互に対応するグラフィック１２６を、ユーザーインターフェース１１８に表示し、これによりユーザーはリモートエンドにおいて第二Ａｐｐ ２を操作する。
本実施形態では、第二計算デバイス２００或いはバーチャルマシン２１２は、グラフィクス処理ユニットを備えず、或いはグラフィクス処理ユニットを備える（図２Ｃと図２Ｄに示すグラフィクス処理ユニット２２）。
但し、バーチャルマシン２１２或いは第二Ａｐｐ ２を執行するモバイルオペレーションシステムからのレンダリングコマンドは、該グラフィクス処理ユニットとは互換性がない。
但し、バーチャルマシン２１２或いは第二Ａｐｐ ２を執行するモバイルオペレーションシステムからのレンダリングコマンドは、該グラフィクス処理ユニットとは互換性がない。
例えば、第二Ａｐｐ ２がＡｎｄｒｏｉｄ（登録商標）アプリケーションプログラムで、しかもバーチャルマシン２１２が、Ａｎｄｒｏｉｄ（登録商標）バーチャルマシンとして実施されれば、第二Ａｐｐ ２は、ライブラリー２０６を通して、ＯｐｅｎＧＬ ＥＳコマンド（例えば、レンダリングコマンド）をグラフィクス処理ユニットに賛成する。
例えば、ＥＧＬ／ＧＬインターフェース２０６ｇ（本発明の実施形態において、ＥＧＬ／ＧＬインターフェース２０６ｇはハードウエア抽象化レイヤー２０８の一部分）或いはＧＬＥＳライブラリー（図示なし）である。
しかし、第二計算デバイス２００（或いはサーバー）のグラフィクス処理ユニットは、ＯｐｅｎＧＬコマンドだけを受け入れられ、ＯｐｅｎＧＬ ＥＳコマンドではないため、ＯｐｅｎＧＬ ＥＳは、ローカルエンドグラフィクス処理ユニットに、グラフィックのレンダリングを直接指示することはできない。
しかし、第二計算デバイス２００（或いはサーバー）のグラフィクス処理ユニットは、ＯｐｅｎＧＬコマンドだけを受け入れられ、ＯｐｅｎＧＬ ＥＳコマンドではないため、ＯｐｅｎＧＬ ＥＳは、ローカルエンドグラフィクス処理ユニットに、グラフィックのレンダリングを直接指示することはできない。
図２Ｃ或いは図２Ｄに示す通り、レンダラー２８（バーチャルマシン２１２或いは第二計算デバイス２００上で実施されるが、バーチャルマシン２１２外部に位置する）は、ライブラリー２０６からのＯｐｅｎＧＬ ＥＳコマンド（該コマンドはＥＧＬ／ＧＬインターフェース２０６ｇ或いはｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉからで、受け取られ／ピックアップされ／取り戻される）を、レンダリングする。
これにより、ＯｐｅｎＧＬコマンドに変わり、ローカルエンドグラフィクス処理ユニット２２は、ＯｐｅｎＧＬ ＥＳコマンドに基づき、３Ｄグラフィックをレンダリングする。
これにより、ＯｐｅｎＧＬコマンドに変わり、ローカルエンドグラフィクス処理ユニット２２は、ＯｐｅｎＧＬ ＥＳコマンドに基づき、３Ｄグラフィックをレンダリングする。
一実施形態において、グラフィクス処理ユニット２２所レンダリングした３Ｄグラフィック可被保存在メモリ２０中（部分メモリ２０在本実施形態中可為フレームバッファー），しかもフレームバッファー中の３Ｄグラフィック可能接続地被ＴＳＲプログラム２６所アクセス，並伝送至第一Ａｐｐ １，しかも以アプリケーションプログラムストリームの形式而表示在ユーザーインターフェース１１８上，或いは者是表示於第一Ａｐｐ １のスクリーン画面，図２Ｃに示したとおりである。
別種の実施形態において、レンダリングした３Ｄグラフィックは、２Ｄグラフィックと共に同じ位置に保存される。
例えば、モジュールのコア２１０においては、「／ｄｅｖ／ｇｒａｐｈｉｃｓ／ｆｂ０ ２１０ｂ」と呼ばれる。
本実施形態においては、図２Ｄに示す通り、ＴＳＲプログラム２６は相同位置に保存され、２Ｄグラフィックと３Ｄグラフィックをユーザーエンドへと同時にストリームする。
図２Ｃと図２Ｄに示す実施形態では、アプリケーションプログラムストリーム（２Ｄ及び／或いは３Ｄグラフィックを含む）ユーザーエンドに伝送する時には、より広い帯域幅が必要である。
例えば、モジュールのコア２１０においては、「／ｄｅｖ／ｇｒａｐｈｉｃｓ／ｆｂ０ ２１０ｂ」と呼ばれる。
本実施形態においては、図２Ｄに示す通り、ＴＳＲプログラム２６は相同位置に保存され、２Ｄグラフィックと３Ｄグラフィックをユーザーエンドへと同時にストリームする。
図２Ｃと図２Ｄに示す実施形態では、アプリケーションプログラムストリーム（２Ｄ及び／或いは３Ｄグラフィックを含む）ユーザーエンドに伝送する時には、より広い帯域幅が必要である。
図２Ｂに示す通り、第二Ａｐｐ ２のグラフィックをレンダリングする時、レンダリングコマンドは第一計算デバイス１００に伝送され、第一Ａｐｐ １により、インターネットを通して受け取られる。
続いて、第一Ａｐｐ １は、レンダリングコマンドをローカルエンド（第一計算デバイス１００）の図形処裡ユニット１２’（或いはレンダリングコマンドを、ローカルエンド図形処裡ユニット１２’と互換性のあるフォーマットに転換可能）に発送し、フレームバッファー１０’（少なくともメモリ１０の一部分）上で、該レンダリングコマンドのグラフィックにレンダリング対応する。
続いて、第一Ａｐｐ １は、レンダリングコマンドをローカルエンド（第一計算デバイス１００）の図形処裡ユニット１２’（或いはレンダリングコマンドを、ローカルエンド図形処裡ユニット１２’と互換性のあるフォーマットに転換可能）に発送し、フレームバッファー１０’（少なくともメモリ１０の一部分）上で、該レンダリングコマンドのグラフィックにレンダリング対応する。
詳細な実施形態は、図３Ａ、図３Ｂ、図３Ｃ或いは図３Ｄに示す後続の実施形態に示す通り、本実施形態において、グラフィックは、第一計算デバイス１００に表示される。
一実施形態において、レンダリングコマンドは、レンダリングを待つグラフィックのメモリ（フレームバッファー）アドレス／エリア、値、カラーコード或いは物件の深度、或いはレンダリングする該グラフィックのエリア／位置／長さ／幅などのパラメーターと組み合わされる。
別種の実施形態において、グラフィックのレンダリングに用いるテクスチャーは、第一Ａｐｐ １に伝送される。
Ａｎｄｒｏｉｄ（登録商標）オペレーションシステムにおいて、レンダリングを指令されるグラフィック／フレームは、図２Ｂに示す部分をサンプルとすることができる。
そのうちの「ｇｌＢｉｎｄＴｅｘｔｕｒｅ」は、レンダリングコマンド（本実施形態中では、１個のＯｐｅｎＧＬ ＥＳコマンド）で、しかも第２１行の「０ｘ０００００ｄｅ１」と「６」はパラメーターである。
Ａｎｄｒｏｉｄ（登録商標）オペレーションシステムにおいて、レンダリングを指令されるグラフィック／フレームは、図２Ｂに示す部分をサンプルとすることができる。
そのうちの「ｇｌＢｉｎｄＴｅｘｔｕｒｅ」は、レンダリングコマンド（本実施形態中では、１個のＯｐｅｎＧＬ ＥＳコマンド）で、しかも第２１行の「０ｘ０００００ｄｅ１」と「６」はパラメーターである。
この他、第二パラメーター「６」を、一種のテクスチャーのレンダリング指示に用いる時には、第一パラメーター「０ｘ０００００ｄｅ１」は、「ターゲット」の指示に用いる。
この技術領域における習熟者なら分かるように、単一のグラフィック、物件或いはフレームをレンダリングする時、複数のレンダリングコマンドを処理しなければならないことがある（図２Ｂに示す通り、グラフィック／物件／フレームのレンダリングのみを執行可能）。
よって、本発明では、グラフィックのレンダリングについて、一個のレンダリングコマンドのみの使用に限定しな。
この技術領域における習熟者なら分かるように、単一のグラフィック、物件或いはフレームをレンダリングする時、複数のレンダリングコマンドを処理しなければならないことがある（図２Ｂに示す通り、グラフィック／物件／フレームのレンダリングのみを執行可能）。
よって、本発明では、グラフィックのレンダリングについて、一個のレンダリングコマンドのみの使用に限定しな。
上述と図２Ｂ（及び／或いは図３Ａ、図３Ｂ或いは図３Ｃ）関連の実施形態において、レンダリングコマンド及び／或いはパラメーター／テクスチャーだけが、ユーザーエンドに伝送されるため、第二Ａｐｐ ２のユーザーインターフェース／スクリーン画面全体をユーザーエンドにレンダリングする時、必要な帯域幅は、図２Ｃ或いは図２Ｄに示す実施形態より少ない。
一実施形態において、レンダリングコマンドは、ハードウエア設定中に含まれ（図３Ａ或いは図３Ｂに示すハードウエア設定モジュール２１４により産生される）、或いはそのものは伝送されて、第一Ａｐｐ １のハードウエア設定とされる。
ここにおいて、ハードウエア設定（或いはレンダリングコマンド）が受け入れられれば、第一Ａｐｐ １は、ハードウエア関連モジュール（図３Ｃに示すレンダリングモジュール１７’）をディスパッチし、該ハードウエア設定（或いはレンダリングコマンド）に基づき、レンダリングミッションを執行する。
ここにおいて、ハードウエア設定（或いはレンダリングコマンド）が受け入れられれば、第一Ａｐｐ １は、ハードウエア関連モジュール（図３Ｃに示すレンダリングモジュール１７’）をディスパッチし、該ハードウエア設定（或いはレンダリングコマンド）に基づき、レンダリングミッションを執行する。
本実施形態では、第二Ａｐｐ ２のスクリーン画面を、ユーザーインターフェース１１８／第一Ａｐｐ １のスクリーン画面に表示するため、複数のレンダリングコマンドの処理に用いるハードウエア関連モジュール（例えば、レンダリングモジュール１７’）は、該各レンダリングコマンドに基づき、グラフィックをレンダリングする必要がある。
別種の実施形態において、レンダリングコマンドが、ＥＧＬ／ＧＬインターフェース２０６ｇ（或いはｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉ）に産生されると、ハードウエア設定モジュール２１４は、ハードウエア設定の産生に用いられ、該ハードウエア設定と該レンダリングコマンド（必要時にはパラメーター／テクスチャーをさらに含む）をＴＳＲプログラム２６に発送し、第一Ａｐｐ １に伝送する。
本実施形態では、該ハードウエア設定（及び／或いはパラメーター／テクスチャー）を受け取った後、第一Ａｐｐ １は、ハードウエア関連モジュール（レンダリングモジュール１７’等）をディスパッチし、第一計算デバイス１００の図形処理ユニット１２’に接続させ、レンダリングコマンド（及び／或いはパラメーター／テクスチャー）を処理する。
第一Ａｐｐ １は、レンダリングコマンド（及び／或いはパラメーター／テクスチャー）を、そのローカルエンド図形処理ユニット１２’へと発送し、グラフィック１２６（それは対応し、第二Ａｐｐ ２のユーザーインターフェース２１８のグラフィック１１６に表示される）をレンダリングする。
本実施形態では、該ハードウエア設定（及び／或いはパラメーター／テクスチャー）を受け取った後、第一Ａｐｐ １は、ハードウエア関連モジュール（レンダリングモジュール１７’等）をディスパッチし、第一計算デバイス１００の図形処理ユニット１２’に接続させ、レンダリングコマンド（及び／或いはパラメーター／テクスチャー）を処理する。
第一Ａｐｐ １は、レンダリングコマンド（及び／或いはパラメーター／テクスチャー）を、そのローカルエンド図形処理ユニット１２’へと発送し、グラフィック１２６（それは対応し、第二Ａｐｐ ２のユーザーインターフェース２１８のグラフィック１１６に表示される）をレンダリングする。
本発明は、図形処理ユニット１２’により、グラフィック１２６を表示し、フレーム緩衝においてレンダリングする必要はなく、或いはバーチャルマシン２１２において、ユーザーインターフェース２１８及びグラフィック２２６を表示し、或いは第二計算デバイス２００に表示する。
ユーザーと第一計算デバイス１００のスクリーン上のユーザーインターフェース１１８（例えば、タッチスマートフォンのスクリーン）がインタラクティブである時には、ユーザーが、スクリーン／ユーザーインターフェース１１８にタッチする座標は、第一Ａｐｐ １によりＴＳＲプログラム２６に伝送される。
一実施形態において、ＴＳＲプログラム２６は、対応インプットイベントを、バーチャルマシン２１２に産生する。
別種の実施形態において、ＴＳＲプログラム２６は、それが受け取った座標を、バーチャルマシン２１２に発送し、しかもバーチャルインプットアウトプットモジュール／インターフェース（図３Ａ、図３Ｂ、図３Ａ或いは図３Ｂに示すｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃ等）は、対応インプットイベントを第二Ａｐｐ ２に産生する。
別種の実施形態において、ＴＳＲプログラム２６は、それが受け取った座標を、バーチャルマシン２１２に発送し、しかもバーチャルインプットアウトプットモジュール／インターフェース（図３Ａ、図３Ｂ、図３Ａ或いは図３Ｂに示すｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃ等）は、対応インプットイベントを第二Ａｐｐ ２に産生する。
一実施形態において、ｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃは、伝送／受け取り／緩衝一般インプット／アウトプットまで／第二Ａｐｐ ２からに用いることができる。
この他、一般インプット／アウトプットは、イメージ、音声或いは他のハードウエアデータを含む。
別種の実施形態において、ｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃは、擬似ドライバー（ｐｓｅｕｄｏ ｄｒｉｖｅｒ）である。
この他、一般インプット／アウトプットは、イメージ、音声或いは他のハードウエアデータを含む。
別種の実施形態において、ｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃは、擬似ドライバー（ｐｓｅｕｄｏ ｄｒｉｖｅｒ）である。
続いて、第二Ａｐｐ ２は、インプットイベントを受け取り、該インプットイベントに反応する（例えば、座標に基づき、シャッターボタン２１６が押されたとの通知を受け取り、バーチャルマシン２１２のカメラＡＰＩを使用して撮影する）。
こうして、第一計算デバイス１００の第一Ａｐｐ １を通した、バーチャルマシン２１２／サーバー上の第二Ａｐｐ ２のリモートエンド操作を達成する。
こうして、第一計算デバイス１００の第一Ａｐｐ １を通した、バーチャルマシン２１２／サーバー上の第二Ａｐｐ ２のリモートエンド操作を達成する。
ユーザーエンドにおけるグラフィックのレンダリング。
図３Ａ或いは図３Ｂに示す通り、図中のシステムは、第一Ａｐｐ １とサーバー或いはバーチャルマシン２１２とを通信させ、ユーザーエンドのハードウエア設備（つまり、ハードウエアデバイス１２或いは図形処理ユニット１２’）を使用して、サーバー或いはバーチャルマシン２１２上の第二Ａｐｐ ２のグラフィックをレンダリングする。
図３Ａ或いは図３Ｂに示す通り、図中のシステムは、第一Ａｐｐ １とサーバー或いはバーチャルマシン２１２とを通信させ、ユーザーエンドのハードウエア設備（つまり、ハードウエアデバイス１２或いは図形処理ユニット１２’）を使用して、サーバー或いはバーチャルマシン２１２上の第二Ａｐｐ ２のグラフィックをレンダリングする。
図３Ａ（図１Ｂを合わせて参照）に示す通り、ネイティブＡｎｄｒｏｉｄ（登録商標）オペレーションシステムが、第一計算デバイス１００において作動すると、レンダリングドライバープログラム及び／或いはインターフェースは、以下の通り表示される。
ドライバープログラム１１１’及び／或いは「ｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ」（「．ｓｏ」のコマンドは、スマート型デバイスによって異なる）１０６ｉは、図形処理ユニット１２’を駆動し、レンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）に基づき、グラフィックをレンダリングし、Ａｎｄｒｏｉｄ（登録商標）オペレーションシステムラン上において、Ａｐｐの使用を執行する（つまり、ローカルエンドグラフィクス処理ユニットを利用しレンダリングを行う）。
ドライバープログラム１１１’及び／或いは「ｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ」（「．ｓｏ」のコマンドは、スマート型デバイスによって異なる）１０６ｉは、図形処理ユニット１２’を駆動し、レンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）に基づき、グラフィックをレンダリングし、Ａｎｄｒｏｉｄ（登録商標）オペレーションシステムラン上において、Ａｐｐの使用を執行する（つまり、ローカルエンドグラフィクス処理ユニットを利用しレンダリングを行う）。
第二計算デバイス２００にはグラフィクス処理ユニットがなく、第二計算デバイス２００（或いはバーチャルマシン２１２）が産生したレンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）を理解できないため、１個のｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉは、レンダリングドライバープログラムの性格を代わって担うことができる。
しかも、ローカルエンドグラフィクス処理ユニットが存在しない、或いはレンダリングと互換性がないため、ｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉは、ＴＳＲプログラム２６の方向をガイドし、レンダリングコマンドを、第一Ａｐｐ １に伝送し（インターネット経由で）、レンダリングコマンドを、ローカルエンドグラフィクス処理ユニットに伝送するのではない。
しかも、ローカルエンドグラフィクス処理ユニットが存在しない、或いはレンダリングと互換性がないため、ｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉは、ＴＳＲプログラム２６の方向をガイドし、レンダリングコマンドを、第一Ａｐｐ １に伝送し（インターネット経由で）、レンダリングコマンドを、ローカルエンドグラフィクス処理ユニットに伝送するのではない。
図３Ａに示す通り、レンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）は、ＥＧＬ／ＧＬインターフェース２０６ｇ或いはｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉにおいて、キャプチャー／インターセプト／リード／レシーブされる。
一実施形態においては、該レンダリングコマンドのパラメーター及び／或いはテクスチャーに対応し、ＥＧＬ／ＧＬインターフェース ２０６ｇ或いはｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉにおいて、キャプチャー／インターセプト／リード／レシーブされる。
一実施形態においては、該レンダリングコマンドのパラメーター及び／或いはテクスチャーに対応し、ＥＧＬ／ＧＬインターフェース ２０６ｇ或いはｌｉｂＧＬＥＳ＿ＦＩＩＳＥＲ．ｓｏ ２０６ｉにおいて、キャプチャー／インターセプト／リード／レシーブされる。
本発明が属する技術領域の習熟者なら分かるように、レンダリングコマンド或いはパラメーター／テクスチャーは、第二Ａｐｐ ２、他の部分のライブラリー２０６（例えば、第二Ａｐｐ ２がＯｐｅｎＧＬ ＡＰＩ等を使用して、或いはグラフィック中の物件を描く、或いはコントロールする）或いは他の部分のコア２１０から、キャプチャー／インターセプト／リード／レシーブされ得る。
本発明の特許請求の範囲が主張するアーキテクチャーは、レンダリングコマンド及び／或いはパラメーター／テクスチャーがキャプチャー／インターセプト／リード／レシーブされる位置を限定しない。
本発明の特許請求の範囲が主張するアーキテクチャーは、レンダリングコマンド及び／或いはパラメーター／テクスチャーがキャプチャー／インターセプト／リード／レシーブされる位置を限定しない。
レンダリングコマンド及び／或いはパラメーター／テクスチャーは、ＴＳＲプログラム２６に発送され、しかもＴＳＲプログラム２６は、このコマンドを第一Ａｐｐ １に伝送する。
図３Ｂに示す通り、第一Ａｐｐ １とサーバー（第二計算デバイス２００或いはバーチャルマシン２１２）の通信システムは、ＴＳＲプログラム２６がバーチャルマシン２１２に設置できる他は図３Ａに示す実施形態に近似する。
図３Ｂに示す通り、第一Ａｐｐ １とサーバー（第二計算デバイス２００或いはバーチャルマシン２１２）の通信システムは、ＴＳＲプログラム２６がバーチャルマシン２１２に設置できる他は図３Ａに示す実施形態に近似する。
一実施形態において、ＴＳＲプログラム２６は、ライブラリー２０６に配置される。
別種の実施形態において、ＴＳＲプログラム２６は、コア２１０に配置される。
本発明が属する技術領域の習熟者なら分かるように、ＴＳＲプログラム２６は、第二計算デバイス２００中に配置され、或いは他のバーチャルマシン２１２に接続する計算デバイス（サーバー或いはクラウド等）は、レンダリングコマンドを受け取り、及び／或いはｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃと第一Ａｐｐ １とを通信させる。
別種の実施形態において、ＴＳＲプログラム２６は、コア２１０に配置される。
本発明が属する技術領域の習熟者なら分かるように、ＴＳＲプログラム２６は、第二計算デバイス２００中に配置され、或いは他のバーチャルマシン２１２に接続する計算デバイス（サーバー或いはクラウド等）は、レンダリングコマンドを受け取り、及び／或いはｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃと第一Ａｐｐ １とを通信させる。
レンダリングコマンド及び／或いはパラメーター／テクスチャーを受け取った後、第一Ａｐｐ １は、このコマンドを、ＥＧＬ／ＧＬインターフェース１０６ｇ（及び／或いはｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ １０６ｉ）に発送し、或いはドライバープログラム１１１’に発送する。
こうして、図形処理ユニット１２’を利用し、グラフィックをレンダリングする。
こうして、図形処理ユニット１２’を利用し、グラフィックをレンダリングする。
本発明が属する技術領域の習熟者なら分かるように、Ａｎｄｒｏｉｄ（登録商標）システム以外のＡｐｐ或いはモバイルオペレーションシステムには、ＥＧＬ／ＧＬインターフェース１０６ｇのようなインターフェースがない可能性がある。
だが、ユーザーエンドを駆動するグラフィクス処理ユニットのライブラリー或いはドライバープログラムが本発明を実現可能であるため、本発明は、ＥＧＬ／ＧＬインターフェース１０６ｇを通した、グラフィックのレンダリングに限定されない。
だが、ユーザーエンドを駆動するグラフィクス処理ユニットのライブラリー或いはドライバープログラムが本発明を実現可能であるため、本発明は、ＥＧＬ／ＧＬインターフェース１０６ｇを通した、グラフィックのレンダリングに限定されない。
図３Ｃは、第一Ａｐｐ １と第二計算デバイス２００或いはバーチャルマシン２１２の、本発明一実施形態に基づく通信アーキテクチャーを示す。
図３Ｃに示す通り、それは図３Ｃに近似し、第一Ａｐｐ １は、レシーバー１３、ディスパッチャー１５、トランスミッター１９及び複数のハードウエア関連モジュール１７を有する。
複数ハードウエア関連モジュール１７のうちの一つは、レンダリングモジュール１７’である。
レシーバー１３は、インターネットを通して、レンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）及び／或いはパラメーター／テクスチャーを受け取ることができる。
図３Ｃに示す通り、それは図３Ｃに近似し、第一Ａｐｐ １は、レシーバー１３、ディスパッチャー１５、トランスミッター１９及び複数のハードウエア関連モジュール１７を有する。
複数ハードウエア関連モジュール１７のうちの一つは、レンダリングモジュール１７’である。
レシーバー１３は、インターネットを通して、レンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）及び／或いはパラメーター／テクスチャーを受け取ることができる。
同原理で、ディスパッチャー１５は、ハードウエア関連モジュール１７のうちの一つ（本実施形態のレンダリングモジュール１７’等）をディスパッチでき、受け取ったレンダリングコマンドに基づき、グラフィックをレンダリングする。
レンダリングモジュール１７’は、ＴＳＲプログラム２６からＡＰＩを呼び出すレンダリングコマンドにおいてマップ（ｍａｐ）に用いることができる。
しかも、１個のマップのＡＰＩを産生して呼び出し、レンダリングＡＰＩ（ＯｐｅｎＧＬ ＥＳ １．０／１．１ ＡＰＩパッケージ、ＯｐｅｎＧＬ ＥＳ ２．０ ＡＰＩパッケージとＯｐｅｎＧＬ ＥＳ ３．０／３．１ ＡＰＩパッケージ等）を使用して、グラフィックのレンダリングを行う。
レンダリングモジュール１７’は、ＴＳＲプログラム２６からＡＰＩを呼び出すレンダリングコマンドにおいてマップ（ｍａｐ）に用いることができる。
しかも、１個のマップのＡＰＩを産生して呼び出し、レンダリングＡＰＩ（ＯｐｅｎＧＬ ＥＳ １．０／１．１ ＡＰＩパッケージ、ＯｐｅｎＧＬ ＥＳ ２．０ ＡＰＩパッケージとＯｐｅｎＧＬ ＥＳ ３．０／３．１ ＡＰＩパッケージ等）を使用して、グラフィックのレンダリングを行う。
言い換えれば、レンダリングモジュール１７’は、レンダリングＡＰＩ及び複数のＡＰＩの呼び出しに結合使用され、しかも任意のＡＰＩ呼び出しは、特定のレンダリングコマンド（ＴＳＲプログラム２６から受け取る）と対応する。
本実施形態では、ＴＳＲプログラム２６からのレンダリングコマンドは、新しいレンダリングコマンド（必要時にはパラメーター及び／或いはテクスチャーを組み合わせる）と相同或いは近似しており、レンダリングモジュール１７’において、それが受け取るレンダリングコマンドに基づき、レンダリング呼び出し／ＡＰＩを選択後、ユーザーエンドにおいて産生される。
ユーザーエンドにおいて産生されるレンダリングコマンドは、ドライバープログラム１１１’に伝送され（第一Ａｐｐ １がＡｎｄｒｏｉｄ（登録商標） Ａｐｐ、或いはモバイルオペレーションシステムがＡｎｄｒｏｉｄ（登録商標）であれば、ＥＧＬ／ＧＬインターフェース１０６ｇ及び／或いはｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ １０６ｉ等を通すことができる）、ローカルエンドの図形処理ユニット１２’等のハードウエアデバイスを駆動し、グラフィックをレンダリングする。
ユーザーエンドにおいて産生されるレンダリングコマンドは、ドライバープログラム１１１’に伝送され（第一Ａｐｐ １がＡｎｄｒｏｉｄ（登録商標） Ａｐｐ、或いはモバイルオペレーションシステムがＡｎｄｒｏｉｄ（登録商標）であれば、ＥＧＬ／ＧＬインターフェース１０６ｇ及び／或いはｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ １０６ｉ等を通すことができる）、ローカルエンドの図形処理ユニット１２’等のハードウエアデバイスを駆動し、グラフィックをレンダリングする。
本実施形態では、ＴＳＲプログラム２６からのレンダリングコマンドを一旦受け取ると、レンダリングモジュール１７’は、これに基づき、ユーザーエンドのレンダリングＡＰＩを選択し、レンダリングＡＰＩを使用し、第一計算デバイス１００の図形処理ユニット１２’を通して、グラフィックをレンダリングする。
図３Ｄに示す通り、本発明の一実施形態において、第一Ａｐｐ １’は、第二計算デバイス２００（サーバー）或いはバーチャルマシン２１２とコミュニケートする。
図３Ｄに示す通り、第一Ａｐｐ １’は、レシーバー１３’を有し、ＴＳＲプログラム２６からレンダリングコマンドを受け取る。
一実施形態において、第一Ａｐｐ １’或いはレシーバー１３’は、ネイティブエンコードライブラリー（或いは複数のネイティブエンコードライブラリー）を含み、ＥＧＬ／ＧＬインターフェース１０６ｇ或いはｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ １０６ｉのレンダリング方法／アプリケーションプログラムをディスパッチし、インターフェースを設計発展させて、グラフィックをレンダリングする。
図３Ｄに示す通り、第一Ａｐｐ １’は、レシーバー１３’を有し、ＴＳＲプログラム２６からレンダリングコマンドを受け取る。
一実施形態において、第一Ａｐｐ １’或いはレシーバー１３’は、ネイティブエンコードライブラリー（或いは複数のネイティブエンコードライブラリー）を含み、ＥＧＬ／ＧＬインターフェース１０６ｇ或いはｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ １０６ｉのレンダリング方法／アプリケーションプログラムをディスパッチし、インターフェースを設計発展させて、グラフィックをレンダリングする。
本実施形態では、第一Ａｐｐ １’（或いはレシーバー１３’）は、ＴＳＲプログラム２６からのレンダリングコマンドを受け取った後、レンダリングコマンドを、（ＥＧＬ／ＧＬ インターフェース１０６ｇ或いはｌｉｂＧＬＥＳ＿ＧＰＵＮＡＭＥ．ｓｏ １０６ｉ等を通して）ドライバープログラム１１１’に伝送する。
しかも、該グラフィックは、図形処理ユニット１２’により、このレンダリングコマンド基づき、レンダリングされる。
第一Ａｐｐ １’（レシーバー１３’或いはネイティブエンコードライブラリー）は、ディスパッチャー（図３Ｄには図示なし）を有し、レンダリングコマンドに基づき、対応する部分ＥＧＬ／ＧＬインターフェース１０６ｇをディスパッチする。
ディスパッチャーのソースコードは、例えば以下の通りである。
しかも、該グラフィックは、図形処理ユニット１２’により、このレンダリングコマンド基づき、レンダリングされる。
第一Ａｐｐ １’（レシーバー１３’或いはネイティブエンコードライブラリー）は、ディスパッチャー（図３Ｄには図示なし）を有し、レンダリングコマンドに基づき、対応する部分ＥＧＬ／ＧＬインターフェース１０６ｇをディスパッチする。
ディスパッチャーのソースコードは、例えば以下の通りである。
…… （ここ及び以下の「……」は、一部のソースコードは無視しても良いという意味である）
ｂｏｏｌ ｉｎｉｔ＿ｇｌ２＿ｄｉｓｐａｔｃｈ（）
｛ｃｏｎｓｔ ｃｈａｒ ＊ｌｉｂＮａｍｅ ＝ ｇｅｔｅｎｖ（"ＡＮＤＲＯＩＤ（登録商標）＿ＧＬＥＳｖ２＿ＬＩＢ"）；
ｉｆ （！ｌｉｂＮａｍｅ） ｌｉｂＮａｍｅ ＝ ＤＥＦＡＵＬＴ＿ＧＬＥＳ＿Ｖ２＿ＬＩＢ；
／／
／／ Ｌｏａｄ ｔｈｅ ＧＬＥＳ ｌｉｂｒａｒｙ
ｓ＿ｇｌｅｓ２＿ｌｉｂ ＝ ｏｓＵｔｉｌｓ：：ｄｙｎＬｉｂｒａｒｙ：：ｏｐｅｎ（ｌｉｂＮａｍｅ）；
ｉｆ （！ｓ＿ｇｌｅｓ２＿ｌｉｂ） ｒｅｔｕｒｎ ｆａｌｓｅ；
／／
／／ ｉｎｉｔ ｔｈｅ ＧＬＥＳ ｄｉｓｐａｔｃｈ ｔａｂｌｅ
ｓ＿ｇｌ２．ｉｎｉｔＤｉｓｐａｔｃｈＢｙＮａｍｅ（ ｇｌ２＿ｄｉｓｐａｔｃｈ＿ｇｅｔ＿ｐｒｏｃ＿ｆｕｎｃ， ＮＵＬＬ ）；
ｓ＿ｇｌ２＿ｅｎａｂｌｅｄ ＝ ｔｒｕｅ；
ｒｅｔｕｒｎ ｔｒｕｅ；｝
ｖｏｉｄ ＊ｇｌ２＿ｄｉｓｐａｔｃｈ＿ｇｅｔ＿ｐｒｏｃ＿ｆｕｎｃ（ｃｏｎｓｔ ｃｈａｒ ＊ｎａｍｅ， ｖｏｉｄ ＊ｕｓｅｒＤａｔａ）
｛ｉｆ （！ｓ＿ｇｌｅｓ２＿ｌｉｂ） ｛ｒｅｔｕｒｎ ＮＵＬＬ；｝
ｒｅｔｕｒｎ （ｖｏｉｄ ＊）ｓ＿ｇｌｅｓ２＿ｌｉｂ-＞ｆｉｎｄＳｙｍｂｏｌ（ｎａｍｅ）；｝
…
ｂｏｏｌ ｉｎｉｔ＿ｇｌ２＿ｄｉｓｐａｔｃｈ（）
｛ｃｏｎｓｔ ｃｈａｒ ＊ｌｉｂＮａｍｅ ＝ ｇｅｔｅｎｖ（"ＡＮＤＲＯＩＤ（登録商標）＿ＧＬＥＳｖ２＿ＬＩＢ"）；
ｉｆ （！ｌｉｂＮａｍｅ） ｌｉｂＮａｍｅ ＝ ＤＥＦＡＵＬＴ＿ＧＬＥＳ＿Ｖ２＿ＬＩＢ；
／／
／／ Ｌｏａｄ ｔｈｅ ＧＬＥＳ ｌｉｂｒａｒｙ
ｓ＿ｇｌｅｓ２＿ｌｉｂ ＝ ｏｓＵｔｉｌｓ：：ｄｙｎＬｉｂｒａｒｙ：：ｏｐｅｎ（ｌｉｂＮａｍｅ）；
ｉｆ （！ｓ＿ｇｌｅｓ２＿ｌｉｂ） ｒｅｔｕｒｎ ｆａｌｓｅ；
／／
／／ ｉｎｉｔ ｔｈｅ ＧＬＥＳ ｄｉｓｐａｔｃｈ ｔａｂｌｅ
ｓ＿ｇｌ２．ｉｎｉｔＤｉｓｐａｔｃｈＢｙＮａｍｅ（ ｇｌ２＿ｄｉｓｐａｔｃｈ＿ｇｅｔ＿ｐｒｏｃ＿ｆｕｎｃ， ＮＵＬＬ ）；
ｓ＿ｇｌ２＿ｅｎａｂｌｅｄ ＝ ｔｒｕｅ；
ｒｅｔｕｒｎ ｔｒｕｅ；｝
ｖｏｉｄ ＊ｇｌ２＿ｄｉｓｐａｔｃｈ＿ｇｅｔ＿ｐｒｏｃ＿ｆｕｎｃ（ｃｏｎｓｔ ｃｈａｒ ＊ｎａｍｅ， ｖｏｉｄ ＊ｕｓｅｒＤａｔａ）
｛ｉｆ （！ｓ＿ｇｌｅｓ２＿ｌｉｂ） ｛ｒｅｔｕｒｎ ＮＵＬＬ；｝
ｒｅｔｕｒｎ （ｖｏｉｄ ＊）ｓ＿ｇｌｅｓ２＿ｌｉｂ-＞ｆｉｎｄＳｙｍｂｏｌ（ｎａｍｅ）；｝
…
一実施形態において、ディスパッチに用いるソースコードテンプレートが対応する一部のＥＧＬ／ＧＬインターフェース１０６ｇは、レンダリングコマンドに基づき、グラフィック（或いは一部のグラフィック）をレンダリングする。
例えば、“ｇｌＢｉｎｄＴｅｘｔｕｒｅ，”は以下の通りである。
……
ｓｉｚｅ＿ｔ ｇｌ２＿ｄｅｃｏｄｅｒ＿ｃｏｎｔｅｘｔ＿ｔ：：ｄｅｃｏｄｅ（ｖｏｉｄ ＊ｂｕｆ， ｓｉｚｅ＿ｔ ｌｅｎ， ＩＯＳｔｒｅａｍ ＊ｓｔｒｅａｍ）
｛
ｓｉｚｅ＿ｔ ｐｏｓ ＝ ０；
ｉｆ （ｌｅｎ ＜ ８） ｒｅｔｕｒｎ ｐｏｓ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＊ｐｔｒ ＝ （ｕｎｓｉｇｎｅｄ ｃｈａｒ ＊）ｂｕｆ；
ｂｏｏｌ ｕｎｋｎｏｗｎＯｐｃｏｄｅ ＝ ｆａｌｓｅ；
……
ｂｒｅａｋ；
ｃａｓｅ ＯＰ＿ｇｌＢｉｎｄＴｅｘｔｕｒｅ：
｛
ｔｈｉｓ-＞ｇｌＢｉｎｄＴｅｘｔｕｒｅ（＊（ＧＬｅｎｕｍ ＊）（ｐｔｒ ＋ ８）， ＊（ＧＬｕｉｎｔ ＊）（ｐｔｒ ＋ ８ ＋ ４））；
ｐｏｓ ＋＝ ＊（ｉｎｔ ＊）（ｐｔｒ ＋ ４）；
ｐｔｒ ＋＝ ＊（ｉｎｔ ＊）（ｐｔｒ ＋ ４）；
｝
……
例えば、“ｇｌＢｉｎｄＴｅｘｔｕｒｅ，”は以下の通りである。
……
ｓｉｚｅ＿ｔ ｇｌ２＿ｄｅｃｏｄｅｒ＿ｃｏｎｔｅｘｔ＿ｔ：：ｄｅｃｏｄｅ（ｖｏｉｄ ＊ｂｕｆ， ｓｉｚｅ＿ｔ ｌｅｎ， ＩＯＳｔｒｅａｍ ＊ｓｔｒｅａｍ）
｛
ｓｉｚｅ＿ｔ ｐｏｓ ＝ ０；
ｉｆ （ｌｅｎ ＜ ８） ｒｅｔｕｒｎ ｐｏｓ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＊ｐｔｒ ＝ （ｕｎｓｉｇｎｅｄ ｃｈａｒ ＊）ｂｕｆ；
ｂｏｏｌ ｕｎｋｎｏｗｎＯｐｃｏｄｅ ＝ ｆａｌｓｅ；
……
ｂｒｅａｋ；
ｃａｓｅ ＯＰ＿ｇｌＢｉｎｄＴｅｘｔｕｒｅ：
｛
ｔｈｉｓ-＞ｇｌＢｉｎｄＴｅｘｔｕｒｅ（＊（ＧＬｅｎｕｍ ＊）（ｐｔｒ ＋ ８）， ＊（ＧＬｕｉｎｔ ＊）（ｐｔｒ ＋ ８ ＋ ４））；
ｐｏｓ ＋＝ ＊（ｉｎｔ ＊）（ｐｔｒ ＋ ４）；
ｐｔｒ ＋＝ ＊（ｉｎｔ ＊）（ｐｔｒ ＋ ４）；
｝
……
この実施形態において、レンダリングコマンド（「ｇｌＢｉｎｄＴｅｘｔｕｒｅ」等）、ターゲットと関連するパラメーター（つまり、「＊（ＧＬｅｎｕｍ ＊）（ｐｔｒ ＋ ８）」はターゲットがフレームバッファー或いはメモリ１０中でアクセスされる位置に定位される）或いはテクスチャーと関連（つまり、「＊（ＧＬｕｎｉｔ ＊）（ｐｔｒ ＋ ８ ＋ ４），」はターゲットがフレームバッファー或いはメモリ１０中でアクセスされる位置に定位される）はディスパッチされ、続いてＥＧＬ／ＧＬインターフェース１０６ｇに伝送され、グラフィックをレンダリングする。
一実施形態において、ネイティブエンコードライブラリーは、Ａｎｄｒｏｉｄ（登録商標）ネイティブ開発キットを使用して、第一Ａｐｐ １’のアプリケーションプログラムパッケージファイル（．ａｐｋ）において推進／執行される。
別種の実施形態において、ネイティブエンコードライブラリーは、別のアプリケーションプログラムパッケージファイル（以下ネイティブエンコードライブラリーａｐｋと呼称）で推進／執行され、しかもネイティブエンコードライブラリーを含むアプリケーションプログラム（以下ネイティブエンコードライブラリーａｐｐと呼称）は、アプリケーションプログラムパッケージファイルにおいて、第一計算デバイス１００をインストール後、第一計算デバイス１００上に形成される。
別種の実施形態において、ネイティブエンコードライブラリーは、別のアプリケーションプログラムパッケージファイル（以下ネイティブエンコードライブラリーａｐｋと呼称）で推進／執行され、しかもネイティブエンコードライブラリーを含むアプリケーションプログラム（以下ネイティブエンコードライブラリーａｐｐと呼称）は、アプリケーションプログラムパッケージファイルにおいて、第一計算デバイス１００をインストール後、第一計算デバイス１００上に形成される。
本実施形態では、２個のアプリケーションプログラムパッケージを共に、第一計算デバイス１００にインストールすると、第一Ａｐｐ １は、レンダリングコマンドを受け取り、ネイティブエンコードライブラリーａｐｐに伝送する（例えば、第一Ａｐｐ １とネイティブエンコードライブラリーａｐｐとの間のクロスプログラム通信或いは他の通信）。
続いて、ネイティブエンコードライブラリーａｐｐは、レンダリングコマンドを、ＥＧＬ／ＧＬインターフェース１０６ｇに伝送し、図形処理ユニット１２’を利用してレンダリングを行う。
よって、本発明が属する技術領域の習熟者なら分かるように、ネイティブエンコードライブラリーは、第一Ａｐｐ １’のアプリケーションプログラムパッケージファイルにおける推進／執行に制限されない。
よって、本発明が属する技術領域の習熟者なら分かるように、ネイティブエンコードライブラリーは、第一Ａｐｐ １’のアプリケーションプログラムパッケージファイルにおける推進／執行に制限されない。
同じ原理で、タッチスクリーンイベントを一旦受け取ると、第一Ａｐｐ １（或いは１’）は、タッチスクリーンイベントの座標（或いはタッチスクリーンイベントを直接伝送）をＴＳＲプログラム２６に伝送する。
しかも、第二Ａｐｐ ２は、バーチャルインプットアウトプットモジュール／インターフェース（ｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃ等）を通して、タッチスクリーンイベントに基づき、反応する。
しかも、第二Ａｐｐ ２は、バーチャルインプットアウトプットモジュール／インターフェース（ｖｒ＿ｉｏ＿ｉｎｔ ２１０ｃ等）を通して、タッチスクリーンイベントに基づき、反応する。
一実施形態において、第一Ａｐｐ １（或いは１’）は、表示グラフィックを第一Ａｐｐ １（或いは１’）のスクリーン画面のイベントにおいてさらに有する。
一実施形態において、レンダリングしたグラフィックの画素は、フレームバッファー１０’（或いはメモリ１０）に保存される。
一実施形態において、第二Ａｐｐ ２が、サーバー或いはバーチャルマシン２１２上のレンダリングＡＰＩに使用され、グラフィックをレンダリングする時には、少なくとも１個のレンダリングコマンド、パラメーター及び／或いはテクスチャーをリード／キャプチャーできる。
この他、トランスミッター１９は、ＴＳＲプログラム２６からのインプットイベント（タッチスクリーンイベント等）の座標を伝送でき、第一Ａｐｐ １は受け取る。
この他、本発明が属する技術領域の習熟者なら分かるように、第二計算デバイス２００或いはサーバーは、モバイルオペレーションシステムを作動させる（例えば、Ａｎｄｒｏｉｄ（登録商標）オペレーションシステム）計算デバイスを執行できる。
本実施形態では、上述のモバイルオペレーションシステムのドライバープログラム或いはライブラリーは、第二計算デバイス２００中で作動させられるため、バーチャルマシン２１２は必須ではなくなる。
本実施形態では、上述のモバイルオペレーションシステムのドライバープログラム或いはライブラリーは、第二計算デバイス２００中で作動させられるため、バーチャルマシン２１２は必須ではなくなる。
図４は、本発明の別種の実施形態における、第一Ａｐｐ １とサーバー或いはバーチャルマシン２１２との通信の方法を示す。
本実施形態では、該方法は、ユーザーエンドの第一Ａｐｐ １’を利用し、第二Ａｐｐ ２のグラフィックをレンダリングし、該第二Ａｐｐ ２は、サーバー或いはバーチャルマシン２１２において執行される。
本実施形態では、該方法は、ユーザーエンドの第一Ａｐｐ １’を利用し、第二Ａｐｐ ２のグラフィックをレンダリングし、該第二Ａｐｐ ２は、サーバー或いはバーチャルマシン２１２において執行される。
図５Ｃに示す通り、ステップ６２８中では、レシーバー１３’は、少なくとも１個のレンダリングコマンド（ＯｐｅｎＧＬ ＥＳコマンド等）、対応パラメーター（ＲＧＢ数ュネ／カラーコード、深度等）及び／或いはサーバー（第二計算デバイス２００、バーチャルマシン２１２或いはＴＳＲプログラム２６等）のテクスチャーを受け取る。
ステップ６３０中では、レシーバー１３’は、レンダリングコマンド、パラメーター及び／或いはテクスチャーを、ユーザーエンドのドライバープログラム１１１’に伝送し、図形処理ユニット１２’を利用して、グラフィックをレンダリングする。
ステップ６３０中では、レシーバー１３’は、レンダリングコマンド、パラメーター及び／或いはテクスチャーを、ユーザーエンドのドライバープログラム１１１’に伝送し、図形処理ユニット１２’を利用して、グラフィックをレンダリングする。
一実施形態において、レンダリングコマンド、パラメーター及び／或いはテクスチャーインターセプトは、バーチャルマシン２１２よりインターネットを通して第一Ａｐｐ １’に伝送される。
別種の実施形態においては、レンダリングコマンドをライブラリー２０６ｉ或いは擬似ドライバー（図示はないが、ライブラリー２０６ｉに接続）に伝送する前に、レンダリングコマンド及び／或いはパラメーターをブロッキングすることができる。
別種の実施形態においては、レンダリングコマンドをライブラリー２０６ｉ或いは擬似ドライバー（図示はないが、ライブラリー２０６ｉに接続）に伝送する前に、レンダリングコマンド及び／或いはパラメーターをブロッキングすることができる。
さらに一実施形態において、バーチャルマシン２１２外において、レンダリングコマンド及び／或いはパラメーターをブロッキングできるが、これはサーバー内でブロッキングを行う。
例えば、もしサーバーが、グラフィクス処理ユニットを有するなら、レンダリングコマンド及び／或いはパラメーターを、グラフィクス処理ユニットに発送する前に、レンダリングコマンド及び／或いはパラメーターをインターセプトすることができる。
例えば、もしサーバーが、グラフィクス処理ユニットを有するなら、レンダリングコマンド及び／或いはパラメーターを、グラフィクス処理ユニットに発送する前に、レンダリングコマンド及び／或いはパラメーターをインターセプトすることができる。
一実施形態において、第一Ａｐｐ １’は、レンダリングモジュール１７’をさらに有する。
レンダリングモジュール１７’は、一機能或いは一レンダリング方法である。
レンダリングモジュール１７’は、Ｃ或いはＣ＋＋によりコーディングされるネイティブエンコードライブラリーで、．ｓｏファイルにコンパイルされ、第一Ａｐｐ １’のアプリケーションプログラムパッケージファイル中に封入され、レシーバー１３’が受け取ったレンダリングコマンドに基づき、一部のレンダリングインターフェース（ＥＧＬ／ＧＬインターフェース１０６ｇ等）をディスパッチし、図形処理ユニット１２’を駆動して、グラフィックをレンダリングする。
レンダリングモジュール１７’は、一機能或いは一レンダリング方法である。
レンダリングモジュール１７’は、Ｃ或いはＣ＋＋によりコーディングされるネイティブエンコードライブラリーで、．ｓｏファイルにコンパイルされ、第一Ａｐｐ １’のアプリケーションプログラムパッケージファイル中に封入され、レシーバー１３’が受け取ったレンダリングコマンドに基づき、一部のレンダリングインターフェース（ＥＧＬ／ＧＬインターフェース１０６ｇ等）をディスパッチし、図形処理ユニット１２’を駆動して、グラフィックをレンダリングする。
本実施形態において、レンダリングモジュール１７’は、複数のハードウエア関連モジュール１７のうちの一つである。
別種の実施形態において、第一Ａｐｐ １’は、複数のハードウエア関連モジュール１７とディスパッチャー１５をさらに有し、レンダリングコマンドを受け取った時には、ディスパッチャー１５は複数のハードウエア関連モジュール１７中から、レンダリングモジュール１７’をディスパッチすることができる。
別種の実施形態において、第一Ａｐｐ １’は、複数のハードウエア関連モジュール１７とディスパッチャー１５をさらに有し、レンダリングコマンドを受け取った時には、ディスパッチャー１５は複数のハードウエア関連モジュール１７中から、レンダリングモジュール１７’をディスパッチすることができる。
一実施形態において、レンダリングモジュール１７’は、ユーザーエンドのレンダリングＡＰＩ（如 ＯｐｅｎＧＬ ＥＳ ＡＰＩ）に使用され、レンダリングコマンドに基づきグラフィックをレンダリングする。
レンダリングコマンド及び／或いはパラメーター／テクスチャーは、ドライバープログラム１１１’へと伝送され、しかもドライバープログラム１１１’は、図形処理ユニット１２’を駆動し、これに基づき、コマンドグラフィックをレンダリングする。
一実施形態において、該グラフィックは先ずフレームバッファー１０’に保存され、次に表示デバイスに表示される（第一計算デバイス１００と表示するが、集積回路或いは一般回路とでき、第一計算デバイス１００のスクリーンをコントロールする）。
レンダリングコマンド及び／或いはパラメーター／テクスチャーは、ドライバープログラム１１１’へと伝送され、しかもドライバープログラム１１１’は、図形処理ユニット１２’を駆動し、これに基づき、コマンドグラフィックをレンダリングする。
一実施形態において、該グラフィックは先ずフレームバッファー１０’に保存され、次に表示デバイスに表示される（第一計算デバイス１００と表示するが、集積回路或いは一般回路とでき、第一計算デバイス１００のスクリーンをコントロールする）。
本実施形態では、該方法は、表示ユーザーエンドのスクリーン画面のステップをさらに含み、該スクリーン画面は、レンダリングしたグラフィックを含む。
別種の実施形態では、レンダリングコマンド或いはパラメーターに関連するテクスチャーは、サーバーから発送され、しかもレシーバー１３’は、該サーバーからのこのテクスチャーを受け取ることができる。
本実施形態において、レンダリングをディスパッチする方法は、ユーザーエンドのレンダリングＡＰＩを使用でき、レンダリングコマンドに少なくとも１個の対応パラメーターとテクスチャーを組み合わせて、グラフィックをレンダリングする。
本実施形態において、レンダリングをディスパッチする方法は、ユーザーエンドのレンダリングＡＰＩを使用でき、レンダリングコマンドに少なくとも１個の対応パラメーターとテクスチャーを組み合わせて、グラフィックをレンダリングする。
一実施形態において、第二Ａｐｐ ２において、バーチャルマシン２１２のレンダリングＡＰＩ（例えば、ＥＧＬ／ＧＬインターフェース２０６ｇを通して）の使用を試し、グラフィックをレンダリングする時、少なくとも１個のレンダリングコマンドと対応パラメーターを取り戻す。
別種の実施形態において、レンダリングコマンド及び相互に対応するパラメーターの他に、テクスチャーは、第二Ａｐｐ ２において、レンダリングＡＰＩ使用時に取り戻される。
別種の実施形態において、レンダリングコマンド及び相互に対応するパラメーターの他に、テクスチャーは、第二Ａｐｐ ２において、レンダリングＡＰＩ使用時に取り戻される。
一実施形態において、バーチャルマシン２１２は、ＴＳＲプログラム２６に接続される。
本実施形態において、ユーザーインターフェース１１８或いは第一Ａｐｐ １のスクリーン画面（其可能包含グラフィックをレンダリングする）の一点がユーザーによりタッチされると、対応するタッチ点の座標は、ＴＳＲプログラム２６に伝送される。
続いて、座標に関連するインプットイベントは産生され、第二Ａｐｐ ２にインプットされる。
本実施形態において、ユーザーインターフェース１１８或いは第一Ａｐｐ １のスクリーン画面（其可能包含グラフィックをレンダリングする）の一点がユーザーによりタッチされると、対応するタッチ点の座標は、ＴＳＲプログラム２６に伝送される。
続いて、座標に関連するインプットイベントは産生され、第二Ａｐｐ ２にインプットされる。
本発明実施形態を説明する過程において、本説明書は本発明の方法及び／或いは過程ステップの特定の順序を記載した。
しかし、該方法或いは過程は、本文が述べるステップの特定順序に依頼するものではなく、該方法或いは過程は、ステップ記載の特定順序に制限されない。
本技術領域において通常の知識を持つ者なら理解できるように、ステップは他の順序により行うこともできる。
よって、本説明書が記載するステップ特定順序は、特許請求の範囲を制限するものではない。
さらに、本発明の特許請求の範囲において記載する方法とステップは、その記載の順序により本発明の実現を制限するものではなく、しかも本技術領域において通常の知識を持つ者なら理解できるように、順序の均等変化と修飾は、本発明の特許請求の範囲内に含まれる。
しかし、該方法或いは過程は、本文が述べるステップの特定順序に依頼するものではなく、該方法或いは過程は、ステップ記載の特定順序に制限されない。
本技術領域において通常の知識を持つ者なら理解できるように、ステップは他の順序により行うこともできる。
よって、本説明書が記載するステップ特定順序は、特許請求の範囲を制限するものではない。
さらに、本発明の特許請求の範囲において記載する方法とステップは、その記載の順序により本発明の実現を制限するものではなく、しかも本技術領域において通常の知識を持つ者なら理解できるように、順序の均等変化と修飾は、本発明の特許請求の範囲内に含まれる。
前述した本発明の実施形態は本発明を限定するものではなく、よって、本発明により保護される範囲は後述される特許請求の範囲を基準とする。
１ 第一アプリケーションプログラム
２ 第二アプリケーションプログラム
１０ メモリ
１０’ フレームバッファー
１１ 表示デバイス
１２ ハードウエアデバイス
１２’ 図形処理ユニット
１３ レシーバー
１５ ディスパッチャー
１７ ハードウエア関連モジュール
１７’ レンダリングモジュール
１９ トランスミッター
２０ メモリ
２２ グラフィクス処理ユニット
２６ ＴＳＲプログラム
２８ レンダラー
１００ 第一計算デバイス
１０２ アプリケーションプログラム層
１０４ アプリケーションプログラムフレーム
１０６ ライブラリー
１０８ ハードウエア抽象化レイヤー
１１０ コア
１１１、１１１’ ドライバープログラム
１１６ ボタン
１１８ ユーザーインターフェース
１２６ グラフィック
２００ 第二計算デバイス
２０２ アプリケーションプログラム層
２０４ アプリケーションプログラムフレーム
２０６ ライブラリー
２０８ ハードウエア抽象化レイヤー
２１０ コア
２１０ｃ ｖｒ＿ｉｏ＿ｉｎｔ
２１２ バーチャルマシン
２１４ ハードウエア設定モジュール
２１６ ボタン
２１８ ユーザーインターフェース
２２６ グラフィック
２ 第二アプリケーションプログラム
１０ メモリ
１０’ フレームバッファー
１１ 表示デバイス
１２ ハードウエアデバイス
１２’ 図形処理ユニット
１３ レシーバー
１５ ディスパッチャー
１７ ハードウエア関連モジュール
１７’ レンダリングモジュール
１９ トランスミッター
２０ メモリ
２２ グラフィクス処理ユニット
２６ ＴＳＲプログラム
２８ レンダラー
１００ 第一計算デバイス
１０２ アプリケーションプログラム層
１０４ アプリケーションプログラムフレーム
１０６ ライブラリー
１０８ ハードウエア抽象化レイヤー
１１０ コア
１１１、１１１’ ドライバープログラム
１１６ ボタン
１１８ ユーザーインターフェース
１２６ グラフィック
２００ 第二計算デバイス
２０２ アプリケーションプログラム層
２０４ アプリケーションプログラムフレーム
２０６ ライブラリー
２０８ ハードウエア抽象化レイヤー
２１０ コア
２１０ｃ ｖｒ＿ｉｏ＿ｉｎｔ
２１２ バーチャルマシン
２１４ ハードウエア設定モジュール
２１６ ボタン
２１８ ユーザーインターフェース
２２６ グラフィック
Claims (11)
- アプリケーションプログラムグラフィックのレンダリング方法において、アプリケーションプログラムは、サーバーにおいて執行され、ユーザーエンドにより、前記アプリケーションプログラムのグラフィックを表示し、
前記方法のステップは、以下を含み、
前記サーバーからのレンダリングコマンド、パラメーター及び／或いはテクスチャーを受け取り、
前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーを、前記ユーザーエンドのドライバープログラムに伝送し、前記ユーザーエンドのグラフィクス処理ユニット（ＧＰＵ）により、前記グラフィックをレンダリングすることを特徴とするアプリケーションプログラムグラフィックのレンダリング方法。 - 前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーを、前記ユーザーエンドの前記ドライバープログラムに伝送るステップは、以下をさらに含み、
前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーに基づき、レンダリングアプリケーションプログラムを使用し、インターフェース（ＡＰＩ）を設計発展させ、前記グラフィックをレンダリングすることを特徴とする請求項１に記載のアプリケーションプログラムグラフィックのレンダリング方法。 - 前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーは、前記アプリケーションプログラムにおいて、前記サーバー上でレンダリングアプリケーションプログラムを使用し、インターフェースを設計発展して、前記グラフィックをレンダリングする時、キャプチャーされることを特徴とする請求項１に記載のアプリケーションプログラムグラフィックのレンダリング方法。
- 前記ステップは、以下をさらに含み、
座標を前記サーバーに伝送し、
前記座標と関連するインプットイベントは産生され、前記アプリケーションプログラムにインプットされることを特徴とする請求項１に記載のアプリケーションプログラムグラフィックのレンダリング方法。 - 前記ステップは、以下をさらに含み、
前記ユーザーエンド上で、前記アプリケーションプログラムのスクリーン画面を表示し、
前記スクリーン画面は、前記表示グラフィックを含むことを特徴とする請求項１に記載のアプリケーションプログラムグラフィックのレンダリング方法。 - 第一アプリケーションプログラム，其は、ユーザーエンドにおいて執行され、第二アプリケーションプログラムのグラフィックをレンダリングし、前記第二アプリケーションプログラムは、サーバー上で執行され、
前記第一アプリケーションプログラムは、レシーバーを含み、
前記レシーバーは、前記サーバーのレンダリングコマンド、パラメーター及び／或いはテクスチャーを受け取り、前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーを、ドライバープログラムに伝送し、前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーに基づき、前記グラフィックをレンダリングし、前記ドライバープログラムは、前記ユーザーエンドのグラフィクス処理ユニットに関連することを特徴とする第一アプリケーションプログラム。 - 前記レシーバーは、ネイティブエンコードライブラリーを含み、前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーを前記ドライバープログラムに伝送することを特徴とする請求項６に記載の第一アプリケーションプログラム。
- 前記第一アプリケーションプログラムは、さらに以下を含み、
レンダリングモジュールは、前記ユーザーエンドのレンダリングアプリケーションプログラムを使用し、インターフェースを設計発展させ、前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーに基づき、前記グラフィックをレンダリングすることを特徴とする請求項６に記載の第一アプリケーションプログラム。 - 前記第一アプリケーションプログラムはさらに、前記レンダリングモジュールを含む複数のハードウエア関連モジュール、ディスパッチャーをさらに含み、
前記ディスパッチャーは、前記レンダリングコマンド、前記パラメーター及び／或いはテクスチャーに基づき、前記レンダリングモジュールをディスパッチし、前記グラフィックをレンダリングすることを特徴とする請求項８に記載の第一アプリケーションプログラム。 - 前記レンダリングコマンド、前記パラメーター及び／或いは前記テクスチャーは、前記サーバー上で、レンダリングアプリケーションプログラムを使用し、インターフェースを設計発展させ、前記グラフィックをレンダリングする時キャプチャーされることを特徴とする請求項６に記載の第一アプリケーションプログラム。
- 前記第一アプリケーションプログラムはさらに、トランスミッターを含み、
前記トランスミッターは、座標を前記サーバーに伝送し、
前記座標と関連するインプットイベントは産生され、前記第二アプリケーションプログラムにインプットされることを特徴とする請求項６に記載の第一アプリケーションプログラム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/707,008 US20160044139A1 (en) | 2014-08-07 | 2015-05-08 | Methods and systems for communications between apps and virtual machines |
| US14/707,008 | 2015-05-08 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2016212874A true JP2016212874A (ja) | 2016-12-15 |
Family
ID=57569852
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016093158A Pending JP2016212874A (ja) | 2015-05-08 | 2016-05-06 | アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2016212874A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2020504890A (ja) * | 2016-12-27 | 2020-02-13 | 深▲せん▼前海達闥雲端智能科技有限公司Ｃｌｏｕｄｍｉｎｄｓ （Ｓｈｅｎｚｈｅｎ） Ｒｏｂｏｔｉｃｓ Ｓｙｓｔｅｍｓ Ｃｏ．， Ｌｔｄ． | マルチオペレーティングシステム用の表示方法、装置及び電子設備 |
| CN110825467A (zh) * | 2018-08-09 | 2020-02-21 | 北京微播视界科技有限公司 | 渲染方法、装置、硬件装置和计算机可读存储介质 |
| JP2020507146A (ja) * | 2016-12-27 | 2020-03-05 | 深▲せん▼前海達闥雲端智能科技有限公司Ｃｌｏｕｄｍｉｎｄｓ （Ｓｈｅｎｚｈｅｎ） Ｒｏｂｏｔｉｃｓ Ｓｙｓｔｅｍｓ Ｃｏ．， Ｌｔｄ． | 映像表示方法、装置、電子機器及びコンピュータプログラム製品 |
| CN113254228A (zh) * | 2021-03-26 | 2021-08-13 | 西安神鸟软件科技有限公司 | 一种图像或视频数据分发方法及终端设备 |
| CN113313804A (zh) * | 2021-06-23 | 2021-08-27 | 深圳Tcl新技术有限公司 | 一种图像渲染方法、装置、电子设备和存储介质 |
| CN114756334A (zh) * | 2022-06-14 | 2022-07-15 | 海马云（天津）信息技术有限公司 | 服务器与基于服务器的图形渲染方法 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014067311A (ja) * | 2012-09-26 | 2014-04-17 | Fujitsu Ltd | システム、端末装置および画像取得方法 |
| JP2014203121A (ja) * | 2013-04-01 | 2014-10-27 | 株式会社ソニー・コンピュータエンタテインメント | 描画処理装置、描画処理システム、および描画処理方法 |
| WO2015038429A1 (en) * | 2013-09-10 | 2015-03-19 | Qualcomm Incorporated | Fault-tolerant preemption mechanism at arbitrary control points for graphics processing |
-
2016
- 2016-05-06 JP JP2016093158A patent/JP2016212874A/ja active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014067311A (ja) * | 2012-09-26 | 2014-04-17 | Fujitsu Ltd | システム、端末装置および画像取得方法 |
| JP2014203121A (ja) * | 2013-04-01 | 2014-10-27 | 株式会社ソニー・コンピュータエンタテインメント | 描画処理装置、描画処理システム、および描画処理方法 |
| WO2015038429A1 (en) * | 2013-09-10 | 2015-03-19 | Qualcomm Incorporated | Fault-tolerant preemption mechanism at arbitrary control points for graphics processing |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2020504890A (ja) * | 2016-12-27 | 2020-02-13 | 深▲せん▼前海達闥雲端智能科技有限公司Ｃｌｏｕｄｍｉｎｄｓ （Ｓｈｅｎｚｈｅｎ） Ｒｏｂｏｔｉｃｓ Ｓｙｓｔｅｍｓ Ｃｏ．， Ｌｔｄ． | マルチオペレーティングシステム用の表示方法、装置及び電子設備 |
| JP2020507146A (ja) * | 2016-12-27 | 2020-03-05 | 深▲せん▼前海達闥雲端智能科技有限公司Ｃｌｏｕｄｍｉｎｄｓ （Ｓｈｅｎｚｈｅｎ） Ｒｏｂｏｔｉｃｓ Ｓｙｓｔｅｍｓ Ｃｏ．， Ｌｔｄ． | 映像表示方法、装置、電子機器及びコンピュータプログラム製品 |
| JP7058658B2 (ja) | 2016-12-27 | 2022-04-22 | 深▲せん▼前海達闥雲端智能科技有限公司 | 映像表示方法、装置、電子機器及びコンピュータプログラム製品 |
| CN110825467A (zh) * | 2018-08-09 | 2020-02-21 | 北京微播视界科技有限公司 | 渲染方法、装置、硬件装置和计算机可读存储介质 |
| CN110825467B (zh) * | 2018-08-09 | 2023-10-24 | 北京微播视界科技有限公司 | 渲染方法、装置、硬件装置和计算机可读存储介质 |
| CN113254228A (zh) * | 2021-03-26 | 2021-08-13 | 西安神鸟软件科技有限公司 | 一种图像或视频数据分发方法及终端设备 |
| CN113313804A (zh) * | 2021-06-23 | 2021-08-27 | 深圳Tcl新技术有限公司 | 一种图像渲染方法、装置、电子设备和存储介质 |
| CN113313804B (zh) * | 2021-06-23 | 2024-03-12 | 深圳Tcl新技术有限公司 | 一种图像渲染方法、装置、电子设备和存储介质 |
| CN114756334A (zh) * | 2022-06-14 | 2022-07-15 | 海马云（天津）信息技术有限公司 | 服务器与基于服务器的图形渲染方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2016212874A (ja) | アプリケーションプログラムとバーチャルマシンとの間のコミュニケーションのシステムと方法 | |
| US10096083B2 (en) | Media content rendering method, user equipment, and system | |
| WO2018050003A1 (zh) | 3D canvas网页元素的渲染方法、装置及电子设备 | |
| EP3111318B1 (en) | Cross-platform rendering engine | |
| TW201706834A (zh) | 應用程式與虛擬機器通訊連接的系統與方法 | |
| US8629878B2 (en) | Extension to a hypervisor that utilizes graphics hardware on a host | |
| EP3138006B1 (en) | System and method for unified application programming interface and model | |
| CN107743636B (zh) | 用于高效实时渲染预先不知道的图形的图形引擎和环境 | |
| US20220398059A1 (en) | Multi-window display method, electronic device, and system | |
| EP2756481B1 (en) | System and method for layering using tile-based renderers | |
| CN101896940A (zh) | 用于硬件资源的动态配置的框架 | |
| AU2008311755A1 (en) | Methods and systems for remoting three dimensional graphical data | |
| JP2014135013A (ja) | 画像転送方法、サーバ機器及びプログラム | |
| CN104704468A (zh) | Web应用程序的跨系统安装 | |
| US9542715B2 (en) | Memory space mapping techniques for server based graphics processing | |
| CN106714920B (zh) | 对媒体内容的智能流传输 | |
| US20190080017A1 (en) | Method, system, and device that invokes a web engine | |
| US20170358055A1 (en) | Texture not backed by real mapping | |
| EP2924563A1 (en) | Methods and systems for communications between apps and virtual machines | |
| US20140156736A1 (en) | Apparatus and method for managing threads to perform divided execution of software | |
| CN114924837A (zh) | 数据处理方法、电子设备和可读存储介质 | |
| CN114090010A (zh) | X11系统的移植方法、装置、电子设备及可读存储介质 | |
| US10678553B2 (en) | Pro-active GPU hardware bootup | |
| CN116982069A (zh) | 用于灵活图形增强和执行的方法和系统 | |
| CN111813404B (zh) | 基于混合图形显示的应用方法、介质及客户端 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170424 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170509 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20171128 |