(57)【要約】      （修正有）【課題】マルチメディア要素の処理、表示をその他のマルチメディア要素と相互動作可能なシステムを提供する。【解決手段】マルチメディアコンテンツをターゲットカンバスへ提供するように構成されたモバイル装置アプリケーションは、カンバスに対応する外部システムと通信リンクを確立する命令と、ターゲットカンバスによって再生されるマルチメディアコンテンツをレンダリングする命令と、レンダリングされたマルチメディアコンテンツを通信リンクを介してカンバスへ送る命令とを含む。マルチメディアコンテンツを提供するように構成されたシステム１００は、マルチメディアコンテンツを表示するように構成されたターゲットと、マルチメディアコンテンツを生成するように構成されたホストと、マルチメディアコンテンツの表示を少なくとも部分的に制御するように構成されたリモートサーバとを含む。【選択図】図１
2019057921.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアコンテンツをターゲットカンバスへ提供するように構成されたモバイル装置アプリケーションであって、該アプリケーションは、
前記ターゲットカンバスに対応する外部システムとの通信リンクを確立する命令と、
前記ターゲットカンバスによって再生されるマルチメディアコンテンツをレンダリングする命令と、
該レンダリングされたマルチメディアコンテンツを前記通信リンクを介して前記ターゲットカンバスへ送る命令とを含むモバイル装置アプリケーション。
【請求項２】
前記マルチメディアコンテンツをレンダリングすることは、前記モバイル装置のハードウェア符号化器を用いて前記マルチメディアコンテンツを処理することを含む請求項１のモバイル装置アプリケーション。
【請求項３】
さらに、マルチメディアコンテンツを前記外部システムの別のターゲットカンバスによる再生のためにレンダリングする命令と、
該レンダリングされたマルチメディアコンテンツを前記通信リンクを介して前記別のターゲットカンバスへ送る命令とを含む請求項１のモバイル装置アプリケーション。
【請求項４】
前記ターゲットカンバスによって再生されるマルチメディアコンテンツをレンダリングすることは、
前記通信リンク上の帯域幅を判定し、
主アプリケーションレンダリングレートを判定し
少なくとも部分的に前記帯域幅および前記主アプリケーションレンダリングレートのうちの少なくとも一方に基づいて前記マルチメディアコンテンツを符号化することを含む請求項１のモバイル装置アプリケーション。
【請求項５】
前記外部システムは車載表示装置である請求項１のモバイル装置アプリケーション。
【請求項６】
前記外部システムは医療装置である請求項１のモバイル装置アプリケーション。
【請求項７】
さらに、前記通信リンク上の前記外部システムからユーザ入力を受信する命令と、
少なくとも部分的に前記ユーザ入力に基づいて前記レンダリングされたマルチメディアコンテンツを変更する命令とを含む請求項１のモバイル装置アプリケーション。
【請求項８】
外部システムに対応するウェブブラウザにおいてウェブベースアプリケーションを実行するように構成されたモバイル装置アプリケーションであって、該アプリケーションは、
前記外部システムとの通信リンクを確立する命令と、
特定のウェブベースアプリケーションにアクセスする命令と、
該特定のウェブベースアプリケーションに対応するコンテンツをレンダリングする命令と、
該レンダリングされたコンテンツを表示のために前記外部システムへ送る命令とを含むモバイル装置アプリケーション。
【請求項９】
さらに、ユーザ入力を前記外部システムから受信する命令と、該入力を前記特定のウェブベースアプリケーションへ提供する命令とを含む請求項８のモバイル装置アプリケーション。
【請求項１０】
前記通信リンクは無線接続を含む請求項８のモバイル装置アプリケーション。
【請求項１１】
前記外部システムは車載表示装置である請求項８のモバイル装置アプリケーション。
【請求項１２】
スマートフォンによって実行されるように構成されている請求項８のモバイル装置アプリケーション。
【請求項１３】
前記特定のウェブベースアプリケーションは統一資源ロケータによってアクセスされる請求項８のモバイル装置アプリケーション。
【請求項１４】
前記特定のウェブベースアプリケーションは、少なくとも１つのセルラ通信ネットワークを介してアクセスされる請求項８のモバイル装置アプリケーション。
【請求項１５】
マルチメディアコンテンツをユーザへ提供するように構成されたシステムであって、該システムは、
マルチメディアコンテンツを表示するように構成されたターゲットと、
マルチメディアコンテンツを前記ターゲット要素による表示対象として生成するように構成されたホストと、
該ホスト要素と相互動作して、マルチメディアコンテンツの表示を少なくとも部分的に制御するように構成されたリモートサーバとを含むシステム。
【請求項１６】
前記ホストはモバイル装置である請求項１５のシステム。
【請求項１７】
前記ターゲットは車載表示装置である請求項１５のシステム。
【請求項１８】
前記ホストおよび前記リモートサーバは、少なくとも１つの無線接続を介して通信する請求項１５のシステム。
【請求項１９】
前記ホストおよび前記ターゲットは、少なくとも１つの無線接続を介して通信する請求項１５のシステム。
【請求項２０】
前記マルチメディアコンテンツはビデオコンテンツを含む請求項１５のシステム。
【発明の詳細な説明】
【関連出願への相互参照】
【０００１】
本出願は、２０１３年９月３０日付出願の米国特許出願シリアル番号第１４／０４２，３６５号および２０１２年１２月４日付出願の米国仮特許出願シリアル番号第６１／７３３，３６７号に対する優先権を主張する。
【発明の背景】
【０００２】
１つ以上のネットワーク（例えば、セルラネットワーク、ローカルエリア無線ネットワーク、インタネットなど）へアクセス可能なモバイル装置（例えば、スマートフォン、タブレット装置、ラップトップＰＣなど）は、社会においてユビキタスである。このような装置は、多様なローカルおよび／またはウェブベースアプリケーションを用いてマルチメディア要素（例えば、ビデオ、写真、音声など）の処理、表示および／またはその他マルチメディア要素と相互動作することが可能である。
【０００３】
多数の典型的なシステムおよび／または装置（例えば、表示画面を有する車載システム、医療システム、テレビジョン（ＴＶ）など）は、マルチメディア要素の処理、表示および／またはその他マルチメディア要素と相互動作することが可能なことがある。このような装置は、外部ネットワークへのアクセスを持たない場合がある。例えば、ヘッドユニット（ＨＵ）マルチメディア要素は、ビデオなどのマルチメディア要素をローカルソース（例えば、ＨＵへ接続されたＤＶＤプレーヤ）から表示可能なことがある。加えて、このような要素が外部ネットワークへアクセス可能な場合、アクセスは、そのローカル要素で利用可能なソフトウェアによって制限される場合がある（例えば、ネットワークへアクセスして、例えばマップデータを策出可能な要素でさえ、ウェブブラウザを提供することができない場合がある）。
【０００４】
このようなシステムおよび／または装置は、（特にモバイル装置と比較して）処理能力が制限される場合がある。さらに、これらのシステムおよび／または装置は、典型的なモバイル装置において利用可能になるソフトウェア更新ほどは頻繁に（または容易に）更新されない可能性のある装置固有のソフトウェアを実行することがある。同様に、このようなシステムまたは装置の更新は、物理的なハウジング、利用可能な電源、通信接続などによる制限に起因して非実際的な、または不可能な場合もある。
【０００５】
そのため、モバイル装置の処理能力を利用してネットワークアクセス、機能性およびマルチメディア性能の拡張および向上を既存のシステムに提供する容易に更新またはアップグレードされるアプローチを提供可能な解決策が必要とされている。
【発明の概要】
【０００６】
いくつかの実施形態によれば、スマートフォンなどのホスト装置へ接続された外部システムまたは装置は、適切な様々なウェブ技術（例えば、ＨＴＭＬ５、スクリプト記述言語（例えば、Ｊａｖａスクリプト、カスケーディングスタイルシート（ＣＳＳ）など）および／または自前のモバイル技術（例えば、Ｏｂｊｅｃｔｉｖｅ−Ｃ、Ｊａｖａ、Ｃ＃など）を用いて開発されたサードパーティアプリケーションを容易に実行することが可能になる。このような外部システムまたは装置を例示的に挙げると、例えば車載ヘッドユニット（ＨＵ）装置、医療装置、ＴＶなどがある。いくつかの実施形態によれば、これらの外部システムまたは装置は、単純で低コストかつ拡張性を保持したままサードパーティアプリケーションを用いることが可能になる。
【０００７】
いくつかの実施形態は、コアモバイル通信スタック（すなわち「ゲートウェイ」または「インタフェース」）トランスポートおよびＨＴＴプレーヤの上層に構築された１組の構成要素を含む。ゲートウェイの性能および柔軟性を利用し、これは、ダウンロードアプリケーション、管理アプリケーションおよびサーバアプリケーションを接続先ターゲット（すなわち「クライアント」）要素へ分配する構成可能な内部構造によって拡張することができる。いくつかの実施形態は、異なるアプリケーション配信およびレンダリングオプション（ターゲットへのＨＴＭＬコードの直接配信から、ホスト上でのレンダリング、およびレンダリングされた画面のターゲットへの配信まで）をサポートするように構成することができる。このようなアプローチは、能力が異なる様々な装置に対応している。いくつかの実施形態によって提供される共通のプログラミングインタフェースおよび内部構造により、開発者は、異なるターゲットを用いても実行可能なアプリケーションを作成することが可能になる。
【０００８】
いくつかの実施形態の解決策は拡張可能であり（すなわち、新規構成要素および機能の追加を主アーキテクチャの変更無く行うことができ）、構成可能であり（すなわち、構成要素を異なる構成に合わせて容易に設定することができ）、オペレーティングシステム（ＯＳ）とは独立し（すなわち、主要オペレーティングシステムのすべてで実行することができ）、また、帯域幅の効率が良く（すなわち、本解決策において圧縮、符号化、および／または帯域幅の使用を最小化する他の適切な技術を用いることができ）、また、応答性がよい（すなわち、本解決策において、クライアント装置上に継ぎ目のないユーザ経験を実現する効率的なプロトコルを用いることができる）。加えて、本解決策によりアプリケーションの可搬性が得られ、あるオペレーティングシステム用に書かれたアプリケーションを最小の変更で別のオペレーティングシステムまたはクライアント上において実行させることが可能になる。
【０００９】
本発明の第１の例示的な実施形態によれば、マルチメディアコンテンツをターゲットカンバスへ提供するように構成されたモバイル装置アプリケーションが提供される。このアプリケーションは、ターゲットカンバスに対応する外部システムとの通信リンクを確立する命令と、ターゲットカンバスによって再生されるマルチメディアコンテンツをレンダリングする命令と、レンダリングされたマルチメディアコンテンツを通信リンクを介してターゲットカンバスへ送る命令とを含む。
【００１０】
本発明の第２の例示的な実施形態によれば、外部システムに対応するウェブブラウザにおいてウェブベースアプリケーションを実行するように構成されたモバイル装置アプリケーションが提供される。このアプリケーションは、外部システムとの通信リンクを確立する命令と、特定のウェブベースアプリケーションにアクセスする命令と、特定のウェブベースアプリケーションに対応するコンテンツをレンダリングする命令と、レンダリングされたコンテンツを表示のために外部システムへ送る命令とを含む。
【００１１】
本発明の第３の例示的な実施形態によれば、マルチメディアコンテンツをユーザへ提供するように構成されたシステムが提供される。本システムは、マルチメディアコンテンツを表示するように構成されたターゲットと、マルチメディアコンテンツをターゲットによる表示対象として生成するように構成されたホストと、ホストと相互動作して、少なくとも一部がマルチメディアコンテンツの表示を制御するように構成されたリモートサーバとを含む。
【００１２】
上記の概要は、本発明のいくつかの例示的な実施形態の様々な特徴事項の簡単な説明とすることを企図している。他の実施形態も、本発明の意図から逸脱することなく他の特定の形で実現することが可能である。
【図面の簡単な説明】
【００１３】
本発明の新規な特徴事項は、添付の特許請求の範囲に記載されている。しかし、説明目的で本発明のいくつかの実施形態を以下の図面に記載する。
【図１】いくつかの実施形態の概念的システムの模式的ブロック図である。
【図２】本システムのいくつかの実施形態によって使用可能な接続方式の模式的ブロック図である。
【図３】いくつかの実施形態のホスト要素の模式的ブロック図である。
【図４】いくつかの実施形態のターゲット要素の模式的ブロック図である。
【図５】いくつかの実施形態によって用いられ、ウェブブラウザを実行可能なターゲットＩ／Ｏ部へサービスを提供するブラウザベースのシステムの模式的ブロック図である。
【図６】いくつかの実施形態によって用いられ、マルチメディアコンテンツを提供可能なターゲットＩ／Ｏ部へサービスを提供する画面投写システムの模式的ブロック図である。
【図７】いくつかの実施形態によって用いられ、マルチメディアコンテンツを提供可能なターゲットＩ／Ｏ部へサービスを提供するベクトル画面投写システムの模式的ブロック図である。
【図８】ハードウェア符号化および／または復号を用いてマルチメディアコンテンツを提供可能なターゲットＩ／Ｏ部へ最適化されたサービスを提供するいくつかの実施形態のシステムの模式的ブロック図である。
【図９】いくつかの実施形態によって使用可能な様々なデータ要素および経路を含むシステムのデータフロー図である。
【図１０】いくつかの実施形態によって用いられ、いくつかの実施形態においてホストアプリケーションを管理するバックエンドシステムの模式的ブロック図である。
【図１１】いくつかの実施形態によって用いられ、少なくとも１つのホストと少なくとも１つのターゲットの間の相互動作を可能にするホスト側（すなわち「サーバ側」）処理のフローチャートである。
【図１２】いくつかの実施形態によって用いられ、少なくとも１つのホストと少なくとも１つのターゲットの間の相互動作を可能にするターゲット側（すなわち「クライアント側」）処理のフローチャートである。
【図１３】いくつかの実施形態によって用いられ、ホストからターゲットへ送るデータを符号化する処理のフローチャートである。
【図１４】いくつかの実施形態によって用いられ、様々な属性を適応的に調整して現在の動作条件に基づいて最適化されたスループットおよび品質を達成する処理の概念的フローチャートである。
【図１５】いくつかの実施形態によって用いられ、ユーザ入力イベントのキャプチャおよびユーザ入力イベントへの応答を行うターゲット側の処理の概念的フローチャートである。
【図１６】いくつかの実施形態によって用いられ、ユーザ入力イベントのキャプチャとその応答を行うホスト側の処理の概念的フローチャートである。
【図１７】本発明のいくつかの実施形態の実現に用いることが可能なコンピュータシステムの模式的ブロック図である。
【発明の詳細な説明】
【００１４】
以下、本発明の例示的実施形態を実行する現時点で最適に企図される態様を詳細に説明する。本発明の範囲は添付の特許請求の範囲にて最良に定義されるため、以下の記載は、限定的に捉えるべきでなく、ひとえに本発明の一般的原理の例示目的のためのものである。
【００１５】
様々な本発明の特徴について以下に述べるが、それぞれは、相互に独立し、または他の特徴と組み合わせて用いることが可能である。
【００１６】
広くは、本発明の実施形態は全体として、適切な様々な様態で使用および構成可能な１組のサーバ、ホスト要素（例えば、スマートフォン、タブレット装置など）およびターゲット要素（例えば、車両ヘッドユニット、ＴＶ、医療装置など）を提供する。このような構成要素について、以下の第Ｉ節にて詳細に述べる。
【００１７】
第１の構成では、いくつかの実施形態において、ウェブブラウザを提供する１つ以上のターゲット要素を用いることができる。このようなアプローチにより、ウェブアプリケーションは、ターゲット要素（すなわち「クライアント」）によってローカルに蓄積しておくことが可能になり、これにより、何らのネットワーク接続が無くてもアプリケーションを利用することが可能になる。加えて、このような構成により、アプリケーションがローカルであるため迅速にレンダリングするので、高速応答も可能になる。このアプローチの場合、アプリケーションをレンダリングするには、比較的強力なハードウェアをターゲット要素が備える必要がある。加えて、ターゲット装置で用いるブラウザもすべて、定期的に更新して技術進展との適合性を維持する必要がある。いくつかの場合（例えば、車両ヘッドユニット）、ターゲット装置において適切な更新を得ることができず、かつ／またはユーザが容易にこれをインストールすることができない場合がある。
【００１８】
第２の構成では、モバイル装置は、アプリケーションを提供しレンダリングすることができ、ターゲット要素は、画面投写クライアントとして機能することができる。このようなレンダリングは、クライアント装置の画面解像度を利用してモバイル装置によってオフスクリーンで行うことができる。このようなアプローチによれば、必要な処理能力の大部分がモバイル装置から提供されるため、単純で廉価、かつ保守の容易なターゲット装置が可能になる。加えて、モバイル装置ブラウザソフトウェアへの更新を定期的に提供し、容易にインストールする（か、または自動的に更新する）ことができる。また、このアプローチにより、仮想ネットワークコンピューティング（ＶＮＣ）、標準ビデオ符号化フォーマットなどの標準的な技術の利用も可能になる。いくつかの場合において、この構成では、低速になる可能性のあるリンク（例えば、車載通信バス）を介して投写画面（および／または他の該当データ）を送ることがあるため、応答が低速になり得る。
【００１９】
第３の構成では、モバイル装置は、同様にアプリケーションを提供することができるが、データをベクトルフォーマットで作成してターゲット要素へ送ることができる。ターゲット要素は、画面投写クライアントとして機能することができる。クライアントは、共通リソースのキャッシュを維持することができるため、レンダリング向上と、モバイル装置およびクライアント装置間のトラフィック低減とが可能になり、性能が向上する。このようなアプローチにより、必要な処理能力の大部分がモバイル装置から得られるため、比較的単純で廉価、かつ保守の容易なターゲット装置が得られる。加えて、モバイル装置ブラウザソフトウェアの更新を定期的に提供し、容易にインストールする（か、または自動的に更新する）ことができる。
【００２０】
様々な構成を簡潔目的で論理的に分類したが、当業者であれば、様々な構成（または「態様」）を組み合わせて、複数の態様の裏付けを与えることが可能なことを認識しよう。よって、ホストおよび／またはターゲットの能力に応じて、ホストは、フル画面またはベクトルコマンドを適切に送ることができる。加えて、スクリーンキャスト技術などの他の技術を上記のＶＮＣまたはベクトルアプローチの代わりに用いることもできる。
【００２１】
別の実現例では、スマートフォンアプリケーションにより、ウェブ画面の有る、または無い自前の操作部を利用することができる。ホストは、クライアントの規模および解像度に応じたオフスクリーンバッファを設け、このバッファを用いてユーザインタフェース（ＵＩ）をレンダリングし、このインタフェースに対するユーザ入力イベントをシミュレートすることができる。
【００２２】
以下の各節において、本発明のいくつかのより詳細な実施形態について述べる。第Ｉ節では、いくつかの実施形態のハードウェアアーキテクチャの概念を説明する。そこで、第ＩＩ節では、いくつかの実施形態の概念的ソフトウェアアーキテクチャについて説明する。次に、第ＩＩＩ節において、いくつかの実施形態によって提供されるアプリケーションおよび方針管理の概念的説明を行う。そこで、第ＩＶ節では、いくつかの実施形態によって用いられる様々なアルゴリズムについて述べる。第Ｖ節では、本発明の実施形態のうちいくつかを実現する概念的コンピュータシステムについて述べる。
Ｉ．ハードウェアアーキテクチャ
【００２３】
第Ｉ節Ａ項において、いくつかの実施形態のシステムの概念的説明を行う。次に、第Ｉ節Ｂ項において、いくつかの実施形態の概念的制御要素について述べる。最後に、第Ｉ節Ｃ項において、いくつかの実施形態の概念的ターゲット要素について述べる。
Ａ．システム
【００２４】
図１は、いくつかの実施形態の概念的システム１００の模式的ブロック図である。具体的には、この図は、システム要素間の様々な通信経路を示す。図示のように、本システムはターゲットシステムまたは装置１１０を含んでよく、これは、１つ以上の入力／出力（Ｉ／Ｏ）要素１２０および通信バス１３０、１つ以上のホストシステムまたは装置１４０、１つ以上のネットワーク１５０、記憶装置１７０を備えた１組のリモートサーバ１６０、および記憶装置１９０を備えた１組のサードパーティサーバ１８０を含んでよい。
【００２５】
ターゲット要素１１０は、ホスト要素１４０と通信可能な何らかの１組のシステム、装置、構成要素および／または他の適切な要素でよい。Ｉ／Ｏ部１２０はそれぞれ、適切な様々な構成要素（例えば、表示画面、音声出力部、１組のユーザ操作部、タッチスクリーンなど）ならびに／または機能（例えば、オーディオビデオおよび／もしくは他のマルチメディアの符号化または復号、１つ以上のネットワークを通る通信など）を含んでよい。「ターゲット」という用語は、全体を通して各Ｉ／Ｏ部のうちのターゲット要素または１組のＩ／Ｏ要素を状況に応じて示す際に用いることができる。通信バス１３０は、状況に応じて様々なハードウェアおよび／またはソフトウェア要素を含んでよい。このようなバスは、有線または無線でよく、これによってターゲット要素１１０の様々な構成要素、ホスト要素１４０、および／または他の構成要素が通信することができる。
【００２６】
いくつかの実施形態において、ターゲット要素１１０は、車両（例えば、車、飛行機、バス、列車、レクリエーショナルビークル（ＲＶ）など）でよい。このようなシステムは、ヘッドユニット、モニタ、ＴＶ、ビデオ画面、オーディオ要素（例えば、スピーカ、ヘッドフォンジャックなど）、ユーザインタフェース（例えば、操作ボタン、タッチスクリーン、マイクロホンなど）、オーディオプレーヤ（例えば、ステレオシステム）、および／または他の適切な要素などのＩ／Ｏ部１２０を含んでよい。
【００２７】
各ホスト要素１４０は、ターゲット１１０（例えば、スマートフォン、タブレット装置、ノートブックコンピュータ、専用メディアプレーヤなど）との相互動作が可能な電子システムまたは装置でよい。ホスト１４０は、場合に応じて、ターゲットシステム１１０に含まれる１つ以上のＩ／Ｏ部１２０と相互動作することができる。例えば、いくつかの実施形態において、スマートフォンホスト１４０は、マルチメディアコンテンツを複数の車両ヘッドユニットＩ／Ｏ部１２０へ送ることができる。加えて、図２を参照して以下に述べるように、システム１００は、場合によっては複数のターゲット１１０および／またはホスト１４０を含んでよい。
【００２８】
ネットワーク１５０は、ホスト１４０（および／またはターゲット１１０）へアクセス可能な１つ以上の通信ネットワークを含んでよい。このようなネットワークを挙げると、例えば、セルラ通信ネットワーク、無線ネットワーク、有線ネットワーク、ネットワーク間ネットワーク（例えば、インタネット）、および／または他の適切なネットワークがある。このようなネットワークは、場合に応じてハードウェアおよび／またはソフトウェア要素の適切で多様な組合せを用いてアクセスすることができる。
【００２９】
リモートサーバ１６０は、ネットワーク１５０へアクセスしてホスト１４０と通信可能な１つ以上の装置を含んでよい。記憶装置１７０は、データおよび／または命令を蓄積可能なリモートサーバ１６０にアクセスできる１つ以上のデバイスを含んでよい。いくつかの実施形態において、リモートサーバ１６０は、ホスト１４０、ターゲット１１０および／または他の適切な要素の実行する対応のソフトウェアと通信するように構成されたソフトウェアを実行することができる。
【００３０】
サードパーティサーバ１８０は、ネットワーク１５０にアクセス可能な、したがってホスト１４０と通信可能な１つ以上の装置を含んでよい。記憶装置１９０は、データおよび／または命令を蓄積可能なサードパーティサーバ１８０にアクセスできる１つ以上のデバイスを含んでよい。いくつかの実施形態において、サードパーティサーバおよび／または記憶装置１９０は、１つ以上のＡＰＩを用いてアクセス可能である。
【００３１】
当業者であれば認識するように、システム１００は本質的に概念的なものであり、本発明の意図から逸脱することなく多様な異なる様態で実現することが可能である。例えば、様々な実施形態は、異なる特定の構成要素および／または各構成要素間の通信経路を含んでよい。別の例として、いくつかの実施形態は、図示したよりも多い、または少ない数の構成要素を含んでよい（例えば、いくつかの実施形態は、何らネットワークまたはサーバへアクセスしなくても動作することができる）。
【００３２】
図２は、システム１００のいくつかの実施形態で利用可能な例示的接続方式２００〜２１０の模式的ブロック図である。具体的には、この図は、利用可能な複数のターゲットおよび複数のホストの構成を示す。
【００３３】
図示のように、第１の例示的構成２００は、単一のホスト２３０と通信する複数のターゲット２２０を含んでよい。このような構成を用いて、例えば、スマートフォンから複数のＴＶへメディアをストリーミングすることができる。
【００３４】
第２の例示的構成２１０において、複数のＩ／Ｏ部２４５〜２６５を備えたターゲット２４０および複数のホスト２７０〜２８０を含んでよい。この例において、第１のホスト２７０は、（例えばマルチメディアコンテンツを複数の車両ヘッドユニットおよび／またはディスプレイへ送ることにより）複数のＩ／Ｏ部２４５〜２５０と相互動作することができる。別のＩ／Ｏ部２５５は、（例えば、Ｉ／Ｏ部が車両内でナビゲーションアプリケーションなどの自前のアプリケーションを実行する場合）どのホストとも相互動作することができない。第２のホスト２７５は、単一のＩ／Ｏ部２６０と相互動作することができる。さらなるホスト２８０および／またはＩ／Ｏ部２６５はそれぞれ、適切で多様な様態（例えば、１つのホストが１つのＩ／Ｏ部に対応し、１つのホストが複数のＩ／Ｏ部に対応し、あるＩ／Ｏ部はホストに対応していないなど）に構成することができる。
【００３５】
図２に示す例に加えて、当業者であれば、場合に応じて様々な他の適切な方式を使用可能なことを認識しよう。例えば、複数のホストが複数のターゲットと相互動作することができ、その場合、各ターゲットは、おのおのがこれらのホストのうちの１つと相互動作できる（か、またはできない）複数の別個のＩ／Ｏ部を含んでよい。別の例として、いくつかの実施形態において、複数のホストが各Ｉ／Ｏ部と相互動作することができる（例えば、第１のホストは、ビデオデータを１組のＩ／Ｏ部へ送ることができ、第２のホストは、音声データを別の１組のＩ／Ｏ部へ重複して送ることができる）。
Ｂ．ホスト
【００３６】
図３は、いくつかの実施形態のホスト要素３００の模式的ブロック図を示す。具体的には、この図は、ホストが用いることが可能な様々な概念的部分要素および通信経路を示す。図示のように、ホストシステムまたは装置３００は、１つ以上のプロセッサ３１０、１つ以上のハードウェア符号化器３２０、１組のＩ／Ｏ部３３０、１つ以上の通信モジュール３４０、および１つ以上の記憶装置３５０を含んでよい。このようなホスト要素の例を挙げると、携帯電話、スマートフォン、ＰＣ、タブレット装置、専用メディアプレーヤ（例えば、ＤＶＤプレーヤ、ブルーレイプレーヤ、ＣＤプレーヤ、ｍｐ３プレーヤ他）、および／または他の適切な構成要素の組がある。
【００３７】
各プロセッサ３１０は、データおよび／または命令のセットを用いて多様な動作を行うことができる。各ハードウェア符号化器３２０は具体的には、特定の種類の入力（例えば、カメラからのビデオ入力、マイクロホンからの音声入力など）を処理して、別のマルチメディア要素で利用するのに適したフォーマットでデータを生成するように構成されている。各Ｉ／Ｏ部３３０は、ユーザからの入力の受け、および／またはユーザへ出力を送るように構成してよい（例えば、タッチスクリーン、キーパッド、マウスおよび／または他のカーソル操作装置、表示画面、スピーカ、マイクロホンなど）。各通信モジュール３４０は、適切な様々なプロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、ＩＥＥＥ８０２．１１など）を用いて利用可能な様々な経路（例えば、有線接続、無線接続、ネットワーク接続など）にわたって１つ以上の他のシステムおよび／または装置と通信するように構成してよい。各記憶装置３５０は、データおよび／または命令を蓄積するように構成してよい。様々な構成要素３１０〜３５０は、バス、ネットワークなどの様々なローカル経路、その他を用いて相互に通信することができる。
【００３８】
ホスト３００は概念的には単一のシステムまたは装置としてみなしてよいが、いくつかの実施形態において、ホストは、個別要素の様々な組合せ（例えば、スマートフォンおよび外部マイクロホン／ヘッドフォンの組合せ、タブレット装置と外部スピーカの組合せなど）を含んでよい。このような構成要素は、様々な物理的要素（例えば、ケーブル、コネクタ、コンセントなど）および／または無線または仮想要素を用いて接続することができる。
【００３９】
いくつかの実施形態のホストは、適切で多様な様態で利用可能な様々なＵＩ要素（例えば、タッチスクリーン、ボタン、キーパッドなど）を含んでよい。例えば、いくつかの実施形態において、ユーザは、ホストから提供される様々な入力要素（例えば、タッチスクリーン上の操作機能、ボリューム操作ボタンなど）を用いてターゲット要素を少なくとも部分的に操作することができる。加えて、表示素子（例えば、タッチスクリーン、表示灯など）などの構成要素を用いて、情報をユーザへ提供することができる。
【００４０】
当業者であれば認識するように、ホスト３００は本質的に概念的なものであり、本発明の意図から逸脱することなく異なる多様な様態で実現可能である。例えば、異なる実施形態では、異なる特定の構成要素および／または構成要素間の通信経路を含んでよい。別の例として、いくつかの実施形態は、図示したよりも多い、または少ない数の構成要素を含んでよい（例えば、いくつかの実施形態では、ハードウェア符号化器を有さなくてよい）。
Ｃ．ターゲット
【００４１】
図４は、いくつかの実施形態のターゲット要素４００の模式的ブロック図である。具体的には、この図は、ターゲットが使用可能な様々な概念的部分要素および通信経路を示す。図示のように、ターゲットシステムまたは装置４００は、１つ以上のプロセッサ４１０、１つ以上のハードウェア復号器４２０、１組のＵＩ要素４３０、１組のマルチメディアＩ／Ｏ部４４０、１つ以上の通信モジュール４５０、および１つ以上の記憶装置３６０を含んでよい。このようなターゲット要素の例を挙げると、ＴＶ、車両ＨＵ、表示モニタ、スマートフォン、ＰＣ、タブレット装置および／または他の適切な構成要素の組がある。
【００４２】
各プロセッサ４１０は、データおよび／または命令のセットを用いて多様な動作を行うことができる。各ハードウェア復号器４２０は具体的には、特定の種類の受信データ（例えば、ビデオ、音声など）を処理し、様々なメディア出力要素（例えば、表示画面、音声出力など）に最適化された適切な出力を生成するように構成されている。各ＵＩ要素４３０は、ユーザ（例えば、タッチスクリーン、キーパッド、ボタン、ノブ、マウスおよび／または他のカーソル操作装置、表示画面、スピーカ、マイクロホンなど）からの入力の受信、および／またはそれらへの送信を行うように構成してよい。各マルチメディアＩ／Ｏ部４４０は、マルチメディアコンテンツをユーザ（例えば、ビデオ画面、スピーカセットなど）へ出力するように構成してよい。各通信モジュール４５０は、利用可能な様々な経路（例えば、有線接続、無線接続、ネットワーク接続など）を通して適切な様々なプロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、ＩＥＥＥ８０２．１１など）を用いて１つ以上の他のシステムおよび／または装置と通信するように構成してよい。各記憶装置４６０は、データおよび／または命令を蓄積するように構成してよい。様々な構成要素４１０〜４６０は、バス（例えば、コントローラエリアネットワーク（ＣＡＮ）バス）、ネットワークなどの様々なローカル経路、その他を用いて相互に通信することができる。
【００４３】
ターゲット４００は概念的には単一のシステムまたは装置としてみなしてよいが、いくつかの実施形態において、ターゲットは、別個の要素の様々な組合せ（例えば、表示画面およびヘッドフォンジャックの組合せ、タブレット装置および外部スピーカの組合せなど）を含んでよい。このような構成要素は、様々な物理的要素（例えば、ケーブル、コネクタ、コンセントなど）および／または無線または仮想要素を用いて接続することができる。
【００４４】
当業者であれば認識するように、ターゲット４００は本質的に概念的であり、本発明の意図から逸脱することなく様々な異なる様態で実現することが可能である。例えば、異なる実施形態を挙げると、異なる特定の構成要素、および／または構成要素間の通信経路がある。別の例として、いくつかの実施形態は、図示よりも多い、または少ない数の構成要素を含んでよい（例えば、いくつかの実施形態では、ハードウェア復号器を有さなくてよい）。
ＩＩ．ソフトウェアアーキテクチャ
【００４５】
第ＩＩ節Ａ項において、いくつかの実施形態のブラウザベースの構成の概念的説明を行う。そこで、第ＩＩ節Ｂ項において、いくつかの実施形態の画面投写の実現例について述べる。次に、第ＩＩ節Ｃ項において、いくつかの実施形態のベクトル画面投写の実現例について述べる。そこで、第ＩＩ節Ｄ項において、いくつかの実施形態において用いられるハードウェア符号化および復号について述べる。次に、第ＩＩ節Ｅ項において、いくつかの実施形態において用いられる概念的データフローおよびデータ要素について述べる。最後に、第ＩＩ節Ｆ項において、いくつかの実施形態において使用可能な例示的なプロトコルコマンドのセットについて述べる。
Ａ．ブラウザ
【００４６】
ターゲットシステムまたは装置が実行可能なブラウザを用いていくつかの実施形態を実現することができる。この構成では、ターゲットブラウザを用いて、サードパーティアプリケーションをターゲットＩ／Ｏ部上においてレンダリングおよび実行することができる。
【００４７】
図５は、いくつかの実施形態にて用いられるブラウザベースのシステム５００の模式的ブロック図であり、これは、ウェブブラウザを実行可能なターゲットＩ／Ｏ部へサービスを提供するものである。具体的には、この図は、様々なシステム要素で使用可能な様々なソフトウェアコンポーネントを示す。このようなソフトウェアシステムは、上記したハードウェアシステム１００を用いて実現することができる。図示のように、ターゲットＩ／Ｏ部（またはシステム）１２０は、対応するＡＰＩ５１５を備えたウェブブラウザホスト５１０、１組のサードパーティウェブアプリケーション５２０、コマンドインタフェース５３０、アプリケーションマネージャ５４０およびローカルデータ５５０を実行することができる。ホスト要素１４０は、ゲートウェイ５６０を実行することができる。各サードパーティサーバ１８０は、インタフェース５７０および様々なサードパーティデータ５８０を提供することができる。いくつかの実施形態のリモートサーバ１６０は、アプリケーションマネージャ５９０およびグローバルアプリケーションデータ５９５を提供することができる。
【００４８】
ウェブブラウザ５１０は、ターゲット装置により実行可能ないずれの適切なブラウザでもよい。ＡＰＩ５１５は、例えば、サードパーティウェブアプリケーションが同じやり方でアプリケーションマネージャ５４０およびターゲットシステムと通信可能なプラグインベース（例えば、Ｊａｖａスクリプト）のＡＰＩでよい。ＡＰＩ５１５はモジュール形式でよく、アプリケーションごとにアプリケーションマネージャ５４０によって定義されるセキュリティ方針に基づくものでよい。よって、ＡＰＩ５１５は、各アプリケーションがアクセス可能な要素および／またはそのアプリケーションが実行可能な動作を制限することができる。
【００４９】
各サードパーティウェブアプリケーション５２０は、ウェブブラウザホスト５１０を用いて動作するように構成されたアプリケーションでよい。コマンドインタフェース５３０により、ターゲットＩ／Ｏ部１２０はホスト１４０から提供されるゲートウェイ５６０と、したがってサードパーティサーバ１８０および／またはリモートサーバ１６０とも相互動作することが可能になる。サードパーティインタフェース５７０により、ゲートウェイ５６０は（したがってターゲット要素１２０およびリモートサーバ１６０も）、アプリケーションデータ（ならびに／または他の種類のデータおよび／もしくは命令）をサードパーティデータ５８０から策出することが可能になる。
【００５０】
各所で説明する様々なアーキテクチャにおいて、いくつかの実施形態のゲートウェイ５６０および／またはインタフェース５３０は、ターゲット（例えば、ＨＵ）とホスト（例えば、スマートフォン）との間の下層通信リンクとして用いることができる。このような通信リンクにより、異なる物理的リンク（例えば、Ｂｌｕｅｔｏｏｔｈ、ＵＳＢ、ＷｉＦｉ、将来のリンクタイプなど）のための均一の通信インタフェースが可能になる。
【００５１】
アプリケーションマネージャ５４０は、ローカルに実行されサードパーティウェブアプリケーション５２０を管理するターゲット構成要素でよい。このような管理を挙げると、ライフサイクル、ソフトウェア更新、および／またはマニフェストファイルを介した許可がある。アプリケーションマネージャ５４０は、サードパーティアプリケーション５２０が蓄積されたローカルデータ５５０を管理することができる。アプリケーションマネージャ５４０は、アプリケーションマネージャサービス５９０と通信して、最新の更新およびマニフェスト変更を得ることができる。アプリケーションマネージャ５４０は、いくつかの実施形態において、少なくとも部分的にターゲットシステム状態（例えば、車両が走行中か、停車中か、駐車中かなど）に基づいてより安全な運転経験のための実行方針を実施することができる。
【００５２】
アプリケーションは、リモートサーバ１６０から（アプリケーションマネージャサーバを用いて）更新することができる。アプリケーション５２０は、ローカルウェブブラウザホスト５１０によりレンダリングしてもよい。ローカルウェブブラウザホストは、サードパーティアプリケーションがアプリケーションマネージャ５４０および／または他のターゲットサービスとセキュアでかつ制御された様態で通信可能なＡＰＩ５１５に対応するＡＰＩライブラリを公開する。ターゲットは、コマンドインタフェース５３０および／またはゲートウェイ５６０を介してインタネットと通信することができる。サードパーティアプリケーション５２０は、対応するウェブサーバに対してゲートウェイ５６０を介して通信するか、または、いくつかの実施形態のアプリケーションルータの内部構造を介してモバイル装置アプリケーションと通信することができる。
【００５３】
アプリケーションマネージャ５９０は、ウェブサービスＡＰＩをローカルアプリケーションマネージャ５４０へ提供して、アプリケーションマニフェスト、新規アプリケーションおよび／またはアプリケーション更新を照会することができる。アプリケーションマネージャ５９０により、クライアントは、利用可能なアプリケーション、ダウンロードアプリケーションおよび／または更新アプリケーションを照会することができる。アプリケーションマネージャは、グローバルアプリケーションデータ５９５を管理することができる。グローバルアプリケーションデータ５９５は、利用可能なサードパーティアプリケーションをすべて含んでよい。アプリケーションは、タイプやターゲット要素モデルなどによって分類してよい。各アプリケーションは、セキュリティ方針を含む対応のマニフェストファイルを有してよい。
【００５４】
当業者であれば、システム５００は本発明の意図から逸脱することなく適切な様々な様態で実現可能なことを認識しよう。例えば、異なる実施形態が特定の異なる構成要素を含んでよい。別の例として、いくつかの実施形態は、より多くの、またはより少ない数の要素を含んでよい。加えて、システム５００は、場合に応じて特定の様々な種類のハードウェアコンポーネントを用いて実現することができる。
Ｂ．画面投写
【００５５】
いくつかの実施形態は、単純なリモートビューワおよびユーザ入力ハンドラを実現するターゲット装置で実現してよい。このような構成の場合、ターゲット装置がブラウザを提供することは不要である。
【００５６】
図６は、いくつかの実施形態にて用いられマルチメディアコンテンツを提供可能なターゲットＩ／Ｏ部へサービスを提供する画面投写システム６００の模式的ブロック図を示す。具体的には、この図は、様々なシステム要素によって使用可能な様々なソフトウェアコンポーネントを示す。このようなソフトウェアシステムは、上記したようなハードウェアシステム１００を用いて実現することができる。図示のように、システム５００を参照して上記した構成要素のいずれかに加えて（または、それに代えて）、システム６００は、ターゲット構成要素１２０によって提供されるビューワ６１０およびシステムアダプタ６２０と、（対応するＡＰＩ６４０を有する）ウェブブラウザホスト６３０と、サードパーティアプリケーション６５０および自前のアプリケーション６６０と、アプリケーションマネージャ６７０と、ホスト要素１４０によって提供されるローカルデータ６８０とを含んでよい。
【００５７】
この構成において、ターゲット側は、コマンドインタフェース５３０（例えば、ＡＰＩ）と、ホスト側にレンダリングされたウェブアプリケーションを表示可能な単純なリモート画面ビューワ６１０とを含んでよい。ターゲット要素１２０は、いくつかの実施形態のゲートウェイ層５６０を介してユーザ入力をホスト１４０へ送り、および／または画面ビットマップを受信することができる。加えて、ターゲット１２０は、次のようなシステムアダプタ６２０を１つ以上含んでよい。すなわちこれらのシステムアダプタは、外部システムから情報（例えば、位置、速度、車両状態などの車両情報）を策出し、策出した情報をＡＰＩ６４０（これはウェブブラウザホスト６３０を用いて実行するものでよい）へ提供して様々なサードパーティウェブアプリケーション６５０および／または自前のアプリケーション６６０からそのデータへのアクセスできるように構成されたものでよい。
【００５８】
ホスト１４０側では、アプリケーションマネージャ６７０およびローカルデータ６８０を用いて、サードパーティアプリケーション６５０および／または自前のアプリケーション６６０を管理することができる。このようなアプリケーションは、ホスト上においてターゲットに適した解像度で走行するウェブブラウザによりオフスクリーンでレンダリングしてもよい。ターゲット１２０からの入力は、いずれもゲートウェイ５６０によって受信することができる。ゲートウェイもまた、レンダリングされた画面をターゲットへ送信することができる。
【００５９】
ゲートウェイ５６０（すなわち「モバイルサーバ」）は、次のようなホスト構成要素でよい。すなわちこれは、自前のウェブ画面構成要素を「ラップ」してそのコンテンツをオフスクリーンでレンダリングし、効率的なリモート画面投写プロトコルを用いてこれをコマンドインタフェース５３０へ送るものである。コマンドインタフェースはまた、ターゲットからの入力を処理し、この入力をウェブ画面へ送こともできる。モバイルサーバ５６０は、ターゲットの画面解像度に対応するオフスクリーンカンバスを生成することができる。
【００６０】
当業者であれば、システム６００は、本発明の意図から逸脱することなく適切な様々な様態で実現可能なことを認識しよう。例えば、異なる実施形態が特定の異なる構成要素を含んでよい。別の例として、いくつかの実施形態は、より多くの、またはより少ない数の要素を含んでよい。加えて、システム６００は、場合に応じて特定の様々な種類のハードウェアコンポーネントを用いて実現することができる。
Ｃ．ベクトル画面投写
【００６１】
上記した画面投写構成と同様に、いくつかの実施形態は、レンダリングされた画面のビットマップに代わって、例えばスケーリングおよび算出したＨＴＭＬページに対応するベクトル情報を受信可能なターゲット装置で実現してもよい。
【００６２】
図７は、いくつかの実施形態で用いられマルチメディアコンテンツを提供可能なターゲットＩ／Ｏ部へサービスを提供するベクトル画面投写システム７００の模式的ブロック図を示す。具体的には、この図は、様々なシステム要素によって使用可能な様々なソフトウェアコンポーネントを示す。このようなソフトウェアシステムは、上記したハードウェアシステム１００を用いて実現できる。図示のように、システム５００および６００を参照して上記した構成要素のいずれかに加えて（またはそれに代えて）、システム７００は、専用のビューワ７１０、リソースキャッシュ７２０、およびモバイルベクトルサービス７３０を含んでよい。
【００６３】
この構成において、ホスト１４０は、ブラウザ６３０およびＡＰＩ６４０を含み、わざわざビットマップまでレンダリングしなくても、ホスト１４０は、例えばＪａｖａスクリプトを実行してベクトルグラフィックへ変換してもよい。このようなベクトルデータは、モバイルベクトルサービス７３０によってキャプチャすることができ、そこでモバイルベクトルサービスは、ゲートウェイ５６０およびコマンドインタフェース５３０を用いてこのデータをターゲット１２０へ送る。同様に、自前のアプリケーション６６０は、ホスト１４０によってレンダリングすることができ、個々のグラフィカルユーザインタフェース要素は、モバイルベクトルサービス７３０によってキャプチャされ、ターゲット１２０へ送ることができる。
【００６４】
ターゲット側は、ホストブラウザ６３０で受信したベクトルグラフィックを表示する専用のビューワ７１０を含んでよい。ビューワ７１０は、グラフィック、ビットマップなどの共通リソースをリソースキャッシュ７２０に蓄積することができる。このようにして、ホスト１４０とターゲット１２０との間のリンクを介して送られるデータ量が低減され、画面のレンダリングも高速化され得る。リソースキャッシュ７２０は、画面レンダリングの合間で再利用される共通リソースを蓄積可能なローカル記憶装置でよい。
【００６５】
モバイルベクトルサービス７３０は、ウェブブラウザエンジンを提供するホスト構成要素でよい。モバイルベクトルサービスは、通常はブラウザエンジンによって行われるレンダリング動作を管理することができ、このような動作をビットマップ（すなわち画面）へ指示するのに代えて、モバイルベクトルサービスは、画面のベクトル記述を組み立てて、この記述をターゲットへ送るようにしてもよい。このようなアプローチにおいて、ベクトルデータをブラウザ７２０から取得可能なアダプタを用いることができる。画像などの何らかのリソースがＩＤ（および／または他の適切な情報）と共に送られ、ターゲット１２０は、何らのリソースもリソースキャッシュ７２０に得られない場合は、リソースを要求するか否かを判定することができる。
【００６６】
当業者であれば、システム７００は本発明の意図から逸脱することなく適切な様々な様態で実現可能なことを認識しよう。例えば、異なる実施形態が特定の異なる構成要素を含んでよい。別の例として、いくつかの実施形態は、より多くの、またはより少ない数の要素を含んでよい。加えて、システム７００は、場合に応じて特定の様々な種類のハードウェアコンポーネントを用いて実現することができる。
Ｄ．ハードウェアの符号化および復号
【００６７】
いくつかのホスト装置もしくはシステムならびに／またはターゲット装置および／もしくはシステムは、いくつかの実施形態において使用可能な符号化器および／または復号器などの様々なハードウェアコンポーネントを含んでよく、汎用プロセッサ（および／または他の適切な構成要素）へ負担を与ることなく効率的なマルチメディア処理（例えば、レンダリング）を行うことができる。ハードウェア符号化および／または復号は、例えばビデオ、音声、汎用データ圧縮および／または通信コマンド処理をサポートすることができる。
【００６８】
図８は、ハードウェア符号化および／または復号を用いてマルチメディアコンテンツを提供可能なターゲットＩ／Ｏ部へ最適化されたサービスを提供するいくつかの実施形態のシステム８００の模式的ブロック図である。具体的には、この図は、多様なシステム要素で使用可能な様々なソフトウェアコンポーネントを示す。このようなソフトウェアシステムは、上述した、システム３００〜４００内に記載の部分要素を含むハードウェアシステム１００を用いて実現できる。図示のように、システム５００、６００および７００を参照して上記した構成要素のいずれかに加えて（またはそれに代わって）、システム８００は、ハードウェア復号器インタフェース８１０およびハードウェア符号化器インタフェース８２０を含んでよい。システム８００のアプローチは、例えば、図５〜図７を参照して上記した様々な解決策と共に（および／またはそれに代わって）用いてもよい。
【００６９】
ハードウェア復号器インタフェース８１０は、例えば、図４を参照して上記した復号器４２０などのハードウェア復号器と相互動作するように構成してよい。ハードウェア符号化器インタフェース８２０は、例えば（図３を参照して上記した符号化器３２０などのハードウェア符号化器と相互動作するように構成してよい。
【００７０】
この構成において、インタフェース８２０を介して専用のハードウェア符号化器を使用して様々なレンダリング（および／またはベクトル処理もしくは他の適切な動作）を行ってもよい。このようなアプローチにより、ホスト装置は、そのホスト装置に対応するプロセッサに他のシステム動作を自由に（またはより自由に）行わせながら必要な動作を効率的に処理することが可能になる。同様に、インタフェース８１０を介してハードウェア復号器を使用して、専用の復号器ハードウェアを用いる様々な処理動作を行ってターゲット要素１２０に対応する何らかのプロセッサが自由に（またはより自由に）他のシステム動作を行うようにしてもよい。加えて、このようなハードウェア復号器および／または符号化器によれば、非専用ハードウェア（例えば、プロセッサ）で達成される性能と比較して向上した性能（例えば、向上した速度、電力消費、出力品質など）が得られる。
【００７１】
当業者であれば、システム８００は本発明の意図から逸脱することなく適切な様々な様態で実現可能なことを認識しよう。例えば、異なる実施形態が特定の異なる構成要素を含んでよい。別の例として、いくつかの実施形態は、より多くの、またはより少ない数の要素を含んでよい。加えて、システム８００は、場合に応じて特定の様々な種類のハードウェアコンポーネントを用いて実現できる。
Ｅ．データフロー
【００７２】
図９は、いくつかの実施形態において使用可能で様々なデータ要素および経路を含むシステム９００のデータフロー図である。具体的には、この図は、様々なデータ要素間の様々な依存関係および／または参照関係を示す。図示のように、本システムは、ホスト９１０およびターゲット９２０を含んでよい。ホスト９１０は、例えば図１および図３を参照して上記したような適切なシステムまたは装置のいずれでもよい。ターゲットは、例えば図１および図４を参照して上記したような適切なシステムまたは装置のいずれでもよい。図示のように、ホスト９１０は、ウェブブラウザホスト９２５、ＯＳホスト９３０、１つ以上の他のホスト９３５、モバイルサーバ９４０、共通リソース９４５、およびゲートウェイ９５０を含んでよい。ターゲット９２０は、共通リソース９５５、通信インタフェース９６０、クライアントモジュール９６５、プレーヤ９７０、およびプレーヤフレームワーク９７５を含んでよい。
【００７３】
ウェブブラウザホスト９２５は、ブラウザ提供および画面（すなわち、コンテンツ）キャプチャを実行することができる。ウェブブラウザホストは、下層のモバイルサーバ９４０のパッケージを用いて、コンテンツをターゲットへ送信すること、および／またはユーザ入力またはコマンドを受信しブラウザ中の受信要素をシミュレートすることを行うことができる。
【００７４】
ＯＳホスト９３０は、ＯＳ画面をキャプチャすることができるアプリケーションホストのプレースホルダでよい。このようなコンポーネントが必要な場合、ＯＳに固有のものでよい。ここでは、ＯＳホストは、いくつかの実施形態によって提供されるフレームワークの拡張性を示すものとして図示されている。
【００７５】
ＯＳホストに加えて、いくつかの実施形態は他のホスト９３５を含んでよい。このようなホストは、下層のモバイルサーバ９４０のパッケージを用いて画面、音声および他のコンテンツをターゲットに送る自前のアプリケーションまたはモバイルサービスでよい。
【００７６】
モバイルサーバ９４０は、リモートアプリケーションをターゲットへ供給するための主コードを含むパッケージでよい。モバイルサーバは、コンテンツを提供する実際のアプリケーションとは別にしてもよい。ウェブブラウザホスト９２５もしくは（ＯＳ全体を管理する）ＯＳホスト９３０などの様々なアプリケーションホストでよく、または、いくつかの実施形態のホスト構成要素を含む他の任意のアプリケーションでもよいであろう。モバイルサーバ９４０は、ターゲットからのコマンドに応答し、ターゲットセッションを追跡し、および／またはそのターゲットに対応する状態を維持することができてもよい。モバイルサーバは、下層のゲートウェイパッケージ９５０を用いてターゲットと通信することができる。
【００７７】
共通リソース９４５または９５５は、ターゲット、ホストおよび／または他のリソース間に共通するクラスおよびコードを有するパッケージを含んでよい。共通リソースは、メッセージおよびイベントについての定義を含んでよい。
【００７８】
ゲートウェイ９５０により、様々なホスト９１０および様々なターゲット９２０間の通信が可能になる。各ターゲットも同様に、ゲートウェイ９５０と相互動作してデータ、命令、ユーザ入力および／または他の要素をホストおよびターゲット間で交換することができるコマンドインタフェース９６０を含んでよい。
【００７９】
クライアントモジュール９６５は、いくつかの実施形態のターゲットを表すパッケージでよい。クライアントモジュールは、モバイルサーバ９４０からイベントを取り扱う機能、および／またはレンダリングコマンドをプレーヤレジスタ９７０へ送る機能を有してよい。クライアントモジュール９６５はまた、入力イベントをプレーヤ９７０から受信し、モバイルサーバ９４０へのメッセージを組み立てる。クライアントモジュール９６５は、下層のインタフェース９６０を用いて、ゲートウェイ９５０を介してホスト９１０と通信することができる。
【００８０】
プレーヤ９７０は、適切なアプリケーションおよび／またはＵＩフレームワーク９７５（例えば、「Ｑｔ」フレームワーク）に基づいたプレーヤの一実現例でよい。異なるグラフィカルフレームワークを場合に応じて用いた他のプレーヤでもよい。プレーヤ９７０は、クライアントモジュール９６５に登録して、描画イベントを受け取り、また任意の入力イベントをプレーヤ９７０へ送ることができる。
【００８１】
図９のデータフロー図は様々な特定の詳細例を示しているが、当業者であれば、このようなシステムは、本発明の意図から逸脱することなく様々な別のやり方で実現可能なことを認識しよう。例えば、異なる実施形態は、異なる特定のデータ要素を含んでよい。別の例として、様々なデータ要素は、図示以外の異なる特定の関係を有してもよい（例えば、様々なデータ要素が様々な他のデータ要素に依存し、他のデータ要素を「認識」し、他のデータ要素への参照を含んでよいなど）。
Ｆ．例示的なプロトコルコマンド
【００８２】
いくつかの実施形態は、様々なシステム要素間の通信を可能にするＡＰＩを含んでよい。ＡＰＩは、様々な装置（例えば、ウェブブラウザを有する装置）にアクセス可能でよい。通信は、カスタム設定されたメッセージに基づくものでよい。このようなメッセージは、各ノード（例えば、ホスト、ターゲット、サーバなど）間において適切な通信リンク（例えば、Ｂｌｕｅｔｏｏｔｈ、シリアル回線、ＷｉＦｉ、ＬＡＮ、ＵＳＢなど）で転送可能である。メッセージは、いくつかの実施形態では受信確認しなくてもよい。いくつかの実施形態では、ノードは、受信したメッセージに応答して新規メッセージを生成し送信してもよい。
【００８３】
メッセージは、そのメッセージに備わるプロトコルバージョンを含んでよい。いくつかの実施形態において、ノード（例えば、サーバ）は、所期のバージョンを有する到来コマンドのみを受容するようにしてもよい。いくつかの実施形態において、メッセージヘッダは、対向方向のプロトコル適合性を与えるために、メッセージヘッダサイズを含んでよい。各メッセージは、ヘッダおよびメッセージコンテンツを含んでよい。メッセージヘッダは、以下の表１に記載のようないくつかの実施形態により実現してもよい。
【００８４】
【表１】
2019057921.tif 000003
【００８５】
メッセージコンテンツはメッセージに依存し得る。ノードが通信に用いる様々なメッセージを以下に示す。
【００８６】
ビデオ構成コマンドを以下の表２に示す。このコマンドは、ターゲットノードによって開始され、サポートされるフレーム復号器と所望のフレームサイズおよび／またはフォーマットについてもホストに通知することができる。ホストは、ターゲットでサポートされるフォーマットに基づいてフレーム符号化器を選択および初期化することができる。そこでホストは、別のビデオ構成コマンドで応答して、選択されたフレーム符号化についてターゲットに通知する。
【００８７】
【表２】
2019057921.tif 000004
【００８８】
矩形塗りつぶしコマンドを以下の表３に示す。このコマンドは、ホストによって送られ、選択された符号化器で符号化されたフレームを含み得る。
【００８９】
【表３】
2019057921.tif 000005
【００９０】
設定スクロールコマンドを以下の表４に示す。このコマンドは、新規ページが開かれ、または接続が確立されたときにホストから送ることができる。このコマンドの目的は、ウェブページの範囲についてターゲットに通知することである。ターゲットは、ウェブページをスクロールするためのスクロールバーを設定することを決定することができる。ホストは、ウェブページをスクロールすることができないため、ターゲットから支援を必要とする場合がある。このコマンドがホストから送られない場合、ホストは独自にページスクロールを操作できるようにするのが安全である。
【００９１】
【表４】
2019057921.tif 000006
【００９２】
スクロール更新コマンドを以下の表５に示す。このコマンドは、ターゲットおよびホストの両方から送ることができる。コマンドがホストから送られると、ターゲットは、スクロールバー位置を調整する。コマンドがターゲットから送られると、ホストは、ウェブページを指定位置にスクロールする。
【００９３】
【表５】
2019057921.tif 000007
【００９４】
待ち状態ライトコマンドを以下の表６に示す。このコマンドは、いくつかの高負荷処理が実行中であるか、または完了した旨をターゲットに通知するためにホストから送られる。これに応答して、ターゲットは、例えば待ち状態ライトを表示するか、または非表示にすることができる。
【００９５】
【表６】
2019057921.tif 000008
【００９６】
表示キーボードコマンドを以下の表７に示す。このコマンドは、テキスト要素が選択されてあるテキストを入力する旨をターゲットに通知するためにホストから送ることができる。これに応答して、ターゲットは、適切なキーボードを表示することができる。
【００９７】
【表７】
2019057921.tif 000009
【００９８】
非表示キーボードコマンドを以下の表８に示す。このコマンドは、キーボードが不要になった旨をターゲットに通知するためにホストから送ることができる。これに応答して、ターゲットはキーボードを閉じることができる。
【００９９】
【表８】
2019057921.tif 000010
【０１００】
マウスコマンドを以下の表９に示す。このコマンドは、ターゲット側のマウスイベント（または他の類似のカーソル操作入力要素）についてホストに通知するためにターゲットから送ることができる。ホストは、ロードされたウェブページ上のイベントを「再生」することができる。
【０１０１】
【表９】
2019057921.tif 000011
【０１０２】
キーボードコマンドを以下の表１０に示す。このコマンドは、ターゲット側のキーボードイベントについてホストに通知するためにターゲットから送ることができる。ホストは、ロードされたウェブページ上にイベントを再生する。
【０１０３】
【表１０】
2019057921.tif 000012
【０１０４】
ブラウザコマンドを以下の表１１に示す。このコマンドは、ホストに対して特定のブラウザ動作（例えば、ホームページへ戻る、戻る、進む、特定のアドレスへジャンプなど）を要求するために、ターゲットから送ることができる。
【０１０５】
【表１１】
2019057921.tif 000013
【０１０６】
現在のアプリケーションの設定コマンドを以下の表１２に示す。このコマンドは、特定のウェブアプリケーションへの切換えを要求するためにターゲットから送ることができる。
【０１０７】
【表１２】
2019057921.tif 000014
【０１０８】
再接続コマンドを以下の表１３に示す。このコマンドは、ホストが一時停止する旨をターゲットに通知するために、ホストから送ることができる。これに応答して、ターゲットは、ホストアドレスを保存し、できるだけ早期に再接続を試行する。
【０１０９】
【表１３】
2019057921.tif 000015
【０１１０】
１秒当たりのフレーム数の設定コマンドを以下の表１４に示す。このコマンドを用いて、フレームレートをターゲット負荷に応じて動的に調整することができる。これは、受信したフレームのレートがターゲットの処理可能なフレームレートを上回るか、または下回る場合に、ターゲットから送られることがある。
【０１１１】
【表１４】
2019057921.tif 000016
【０１１２】
音声開始コマンドを以下の表１５に示す。このコマンドはホストから送ることができる。このコマンドは、音声再生がまもなく開始する旨をターゲットに通知することができる。このコマンドは、オーディオ特性（例えば、コーデック、サンプリングレート、サンプル当たりのビット数など）についての情報を含んでよい。このコマンドをターゲットが受信すると、これに応答して、ターゲットは音声再生に備える。
【０１１３】
【表１５】
2019057921.tif 000017
【０１１４】
音声停止コマンドを以下の表１６に示す。このコマンドは、音声再生を停止する旨をターゲットに通知するためにホストから送ることができる。
【０１１５】
【表１６】
2019057921.tif 000018
【０１１６】
音声データコマンドを以下の表１７に示す。このコマンドはホストから送ることができる。コマンドは、所定のフォーマットに音声データ（例えば、音声開始コマンドによって規定されたもの）を含んでよい。
【０１１７】
【表１７】
2019057921.tif 000019
【０１１８】
音声一時停止コマンドを以下の表１８に示す。このコマンドは、音声再生を一時停止するか、または再開する場合にホストからターゲットへ送ることができる。このコマンドは、ホストが音声データ送信を一時停止または再開する場合にターゲットからホストへ送ってもよい。このターゲットは、音声バッファを維持することができる。音声バッファが満杯になると、「一時停止」コマンドを送ってもよい。バッファがほとんど空になると、「再開」コマンドを送ってもよい。
【０１１９】
【表１８】
2019057921.tif 000020
【０１２０】
当業者であれば、上記したメッセージ要素は、様々な異なる実施形態において異なる様態で実現可能なことを認識しよう。例えば、異なる実施形態において、異なる特定のメッセージＩＤを用いてもよい。別の例として、異なる実施形態は、上記したものとは異なる様々な長さのパラメータを含んでよい。さらに、異なる実施形態は、図示以外の様々なメッセージをさらに含んでよい。
ＩＩＩ．アプリケーション管理
【０１２１】
第ＩＩＩ節Ａ項において、いくつかの実施形態において用いられサポートされるアプリケーションを管理するシステムの概念的説明を行う。次に、第ＩＩＩ節Ｂ項において、アプリケーション管理に対応する概念的データベーススキーマを説明する。
Ａ．システム
【０１２２】
図１０は、いくつかの実施形態において用いられいくつかの実施形態においてホストアプリケーションを管理するバックエンドシステム１０００の模式的ブロック図である。図示のように、本システムは、１つ以上のリモートサーバ１００５および管理アプリケーション１０１０を含んでよい。バックエンドシステム１０００は、モバイル装置（例えば、スマートフォン、タブレットなど）上において走行するホスト１０１５と通信することができる。ホスト１０１５は、例えば図９を参照して上記したようなホスト９１０と同様でよい。
【０１２３】
図１０に戻って、リモートサーバ１００５には、ユーザアクセス制御（ＵＡＣ）モジュール１０２０、データベースアクセス部１０２５、記憶装置１０３０、アプリケーションカタログＡＰＩ１０３５、アプリケーション管理ＡＰＩ１０４０、およびクライアントＡＰＩ１０４５を設けてよい。
【０１２４】
ＵＡＣモジュール１０２０は、あるリソースをユーザが入手または操作する許可を得ているか否かを判定することができる。このモジュールは主に、アプリケーション管理モジュール１０４０によって用いられる。例えば、アプリケーションを削除せよとの要求がある場合、ＵＡＣは、この要求における提供されたユーザ詳細事項に基づいて、そのアクションが許可されているかを確認することができる。データベースアクセスインタフェース１０２５は、様々なデータベース管理システムを使用可能にするための包括的なものである。任意の適切なリレーショナルデータベース管理システムＲＤＢＭＳが利用可能である。アプリケーション管理ＡＰＩ１０４０は、アプリケーション管理にＲＥＳＴＡＰＩを提供することができる。このＡＰＩにより、アプリケーションの追加、削除および編集を要求可能になる。クライアントＡＰＩ１０４５により、サーバアプリケーションを得るのに必要な情報を許可にするＲＥＳＴＡＰＩが提供可能となる。このような情報は、システムアクセスキーを用いてアクセスすることができる。
【０１２５】
管理アプリケーション１０１０には、アプリケーションカタログマネージャ１０５０およびアプリケーションマネージャ１０５５を設けてよい。アプリケーションマネージャは、ユーザがアプリケーションをアップロード、編集または削除することが可能なウェブクライアントでよい。アプリケーションマネージャは、アプリケーションの状態を示しアプリケーション承認処理を管理可能なウェブアプリケーションとして実現してもよい。管理アプリケーション１０１０は、リモートサーバ１００５を介してバックエンドシステム１０００と相互動作可能なウェブブラウザまたは自前のアプリケーションを用いて実現してもよい。
【０１２６】
ホスト１０１５には、ホストアプリケーション１０６０、１組の自前のアプリケーション１０７０へリンクされたサーバライブラリ１０６５、および１組のＨＴＭＬアプリケーション１０７５を設けてよい。
【０１２７】
バックエンドシステム１０００の主な役割は、利用可能なアプリケーションのリストを提供することと、アプリケーションバンドル（例えば、ＨＴＭＬファイル、Ｊａｖａスクリプトファイル、ＣＳＳ、リソースなどを含む多量のＨＴＭＬアプリケーション）をホストアプリケーション１０６０へダウンロードするための内部構造を提供することである。加えて、本システムは、アプリケーションおよび／またはアプリケーションカタログの管理に使用可能な様々なウェブクライアントにＲＥＳＴＡＰＩを公開することができる。システムユーザは、様々なＡＰＩを介して様々な許可を有してもよい。
【０１２８】
ある「被管理」アプリケーション（すなわち、バックエンドシステム１０００を介して管理されホスト１０１５上において実行可能な任意のアプリケーション）は、多数の異なる形態を持ち得る。各アプリケーションはタイプが異なるかもしれない。例えば、あるアプリケーションは、あるプラットフォーム上では提供されたＨＴＭＬアプリケーションであり、別のプラットフォーム上では自前のアプリケーションであるかもしれない。アプリケーションは、接続されるターゲットシステムタイプ、選択される優先度および／または他の該当する要因に応じて異なるスタイルを持ち得る。アプリケーションは、接続されるターゲットシステムおよび／またはそれに含まれるＩ／Ｏ部に応じて異なる動作モードを持ち得る。例えば、高級車両は、廉価なモデルと比較して多くの機能を備え得る。同様に、ホストプラットフォームに応じて異なるアプリケーションバージョンがあり得る。あるアプリケーションの個別のインカネーションは、アプリケーション記述子によって定義されることがある。同一アプリケーションでも、多数の異なるアプリケーション記述子があり得る。接続される装置に応じて、リモートサーバ１００５は、最も関連するアプリケーション記述子を送ることができる。
【０１２９】
いくつかの実施形態は、ホスト側で様々なアプリケーションを機能させることができる。あるものはリモートサーバ１００５によって提供され、他のものはサードパーティサイトによって提供されるか、またはホスト上の自前のアプリケーションであり得る。タイプに関係無く、アプリケーションカタログに蓄積された各アプリケーション用の記述子があることがあり、これはホスト１０１５上のホストアプリケーション１０６０へ送ることができる。サポートされるアプリケーションタイプを挙げると、例えば、提供されるＨＴＭＬアプリケーション、ローカルＨＴＭＬアプリケーション（またはアプリケーションバンドル）、および自前のアプリケーションがある。
【０１３０】
提供されるＨＴＭＬアプリケーションは、リモートサーバ１００５または１つ以上のサードパーティウェブサーバ上で提供されるＨＴＭＬアプリケーションでよい。アプリケーションはＵＲＬとしてホストアプリケーション１０６０へ提供することができ、ホストアプリケーション１０６０はこれをホストブラウザに渡す。アプリケーションは、標準的なＨＴＴＰキャッシング機構によりホスト１０１５上に部分的に、または全体をキャッシュすることができる。
【０１３１】
ローカルＨＴＭＬアプリケーションは、アプリケーションバンドル内のＨＴＭＬ、Ｊａｖａスクリプト、ＣＳＳおよびリソースファイルをすべて有するＨＴＭＬアプリケーションでよい。バンドルは、ホストアプリケーション１０６０によってリモートサーバ１００５からダウンロードし、ホスト１０１５上に蓄積することができる。アプリケーションは、モバイルブラウザにロードしてもよい。アプリケーションはあるバージョンを有することが理、更新バンドルが利用可能である場合、ホストアプリケーション１０６０は、新規アプリケーションバンドルをダウンロードすることができる。
【０１３２】
自前のホストアプリケーション（例えば、スマートフォンアプリケーション）は、特別なサーバライブラリ１０６５とリンクしてもよい。これらのアプリケーションは、アプリケーション識別子を利用してリモートサーバ１００５に登録することができる。このアプローチにより、ユーザは、（ホストアプリケーション１０６０によってレンダリングされた）主ホーム画面から選択を行って、プラットフォームに固有の方法を用いて自前のアプリケーションへ切り換えることができる。このようなプラットフォーム固有の方法を挙げると、例えば、アプリケーションプロトコルＵＲＬの使用がある。
【０１３３】
各アプリケーションは、ターゲットシステムの種類、選択されたユーザ優先度および／または他の該当する要因に応じて、多数の異なるスタイルを持ち得る。ひとつの典型的なスタイルは、主機能の変更無しに「表層的」変更が必要なものである場合があり、これは、アプリケーションモードパラメータを介して制御することができる。これらのスタイルは、動的に変更可能であり、ホストにあらかじめロード（プリキャッシュ）してもよく、主にＣＳＳおよびリソース変更でよい。スタイルの例として、「昼／夜」スタイル、様々なパーソナルスタイルまたは様々な車両モデルスタイルがある。
【０１３４】
アプリケーションは、選択されたモード（例えば、スタイル、車種など）に応じて異なる機能を持ち得る。モードは、例えば、ターゲットタイプ、製造業者および／またはモデルを規定することができ、これらを用いてターゲットの既知の機能に基づいて特定の機能を有効および／または無効にすることができる。モードは典型的には、アプリケーション開始時に設定してよく、動的に変更しなくてよい。
【０１３５】
あるアプリケーションは、ホストプラットフォームに応じた多様な実現形態を有し得る。例えば、あるアプリケーションは、１つのモバイルプラットフォーム上では自前のアプリケーションとして、また他のプラットフォームでは提供されたＨＴＭＬアプリケーションとして実行することができる。これは、アプリケーション記述子に含まれるアプリケーションプラットフォームパラメータを介して行うことができる。
【０１３６】
提供されるＨＴＭＬアプリケーションなどのいくつかのアプリケーションは包括的なものでよく、いくつかの実施形態のシステム内での動作をサポートする若干の小さな変更を必要とすることがある。これは、１つ以上のアダプタモジュール（例えば、Ｊａｖａスクリプトコード）によって達成され、アダプタモジュールは、アプリケーションのロード時にホストアプリケーションによりウェブ画面へ注入することができる。各アダプタモジュールは、所与のアプリケーション記述子と対応させることができる。いくつかの実施形態において、アダプタは、各プラットフォームと対応させてよい。あるいは、アダプタは、エージェント文字列によってプラットフォームを検出することができ、適切なコードを実行することができる。
【０１３７】
高速アプリケーションローディングおよびオフラインアクセスをサポートするために、いくつかの実施形態は、ローカルＨＴＭＬアプリケーションをサポートしている。このようなアプリケーションは、ＨＴＭＬアプリケーション、スクリプトベースのアプリケーションなどでよい。すべてのアプリケーションファイル（例えば、ＨＴＭＬ、ＪＳ、ＣＳＳ、リソースなど）を組み合わせて圧縮ファイルとし、リモートサーバ１００５内に蓄積することができる。各アプリケーションバンドルは対応するバージョンを持ち得るため、ホストアプリケーションはローカルバンドルの更新が必要か否かを検出することが可能である。
【０１３８】
当業者であれば、システム１０００は、異なる実施形態において様々な異なる様態で実現可能なことを認識しよう。例えば、いくつかの実施形態では、モジュール数を増やし、またはモジュール数が少なくてもよい。別の例として、様々なモジュールを組み合わせて単一のモジュールを形成し、かつ／または様々な単一のモジュールをそれぞれ分割して１組のサブモジュールとすることができる。
Ｂ．データベーススキーマ
【０１３９】
このデータベーススキーマにおける主要な概念は、被管理アプリケーションである。このようなアプリケーションは、以下の表１９に示すアプリケーション表によって表される。この表は被管理アプリケーションを記述している。このようなアプリケーションは、名称、記述、カテゴリ、所有者および／または他の要素を有してよい。
【０１４０】
【表１９】
2019057921.tif 000021
【０１４１】
あるアプリケーションは、異なるプラットフォーム、ターゲットシステムモデルまたはスタイルなどに対して異なる「インカネーション」を持ち得る。ある場合は、アプリケーションがＨＴＭＬ５アプリケーションであり得ても、他の実施形態では、そのアプリケーションは自前でよい。これらの変形例は、以下の表２０に示されるアプリケーション記述子表によって記述される。この表は、アプリケーションに対応するアプリケーション記述子を記述している。アプリケーション記述子は、特定のアプリケーションバンドル、ＵＲＬまたはアプリＩＤを参照することができる。
【０１４２】
【表２０】
2019057921.tif 000022
【０１４３】
アプリケーションは、多様なクライアントシステムに対して様々な様態で配備することができる。所与の配備は、以下の表２１に示される配備記述子表によって規定することができる。この表は、様々な配備記述子を含んでよい。配備記述子は、対応するキーを有する特定の配備構成を規定することができる。いくつかの実施形態のホストアプリケーションを（例えばスマートフォンにより）実行すると、キーがリモートサーバへ送られて、利用可能なアプリケーションのリストが得られる。バックエンドシステムは、キーを用いて配備記述子を策出し、対応する配備アプリケーションのカタログを取り出することができる。
【０１４４】
【表２１】
2019057921.tif 000023
【０１４５】
配備アプリケーション表は、特定のアプリケーション記述子と所与の配備との間の対応を規定することができる。この表により、アプリケーション記述子と特定の配備記述子とが関連付けられる。この表は、ある配備構成、モード、スタイルおよびプラットフォームについて、ホーム画面に提示されるアプリケーションを特定のアイコンおよび名称を用いて規定する。配備アプリケーション表を以下の表２２に示す。
【０１４６】
【表２２】
2019057921.tif 000024
【０１４７】
本システムによって蓄積および管理される画像、アプリケーションバンドルなどのどのリソースも、以下の表２３に示されるリソース記述子表によって表される。これらの種類のリソースは、他の表からＩＤを用いて参照される。また、リソースは、当該リソースをアップロートしたユーザと関連付けられ、したがって認証されたユーザ（例えば、同じ会社のユーザ、システム管理者など）しか閲覧および編集することができない。この表は、バックエンドシステムで管理されるファイルなどのリソースを記述している。リソースは、アプリケーションバンドル、アダプタ、アプリケーションアイコンなどであり得る。各リソースは、これをアップロートしたユーザと関連付けることができる。
【０１４８】
【表２３】
2019057921.tif 000025
【０１４９】
以下の表２４に示すプラットフォーム表は、システムのサポートに利用可能なプラットフォームを規定している。
【０１５０】
【表２４】
2019057921.tif 000026
【０１５１】
以下の表２５に示す配備スタイル表は、ある配備構成に対する利用可能なアプリケーションスタイルを規定している。
【０１５２】
【表２５】
2019057921.tif 000027
【０１５３】
以下の表２６に示す配備スタイル表は、ある配備構成に対する利用可能なアプリケーションモードを規定している。
【０１５４】
【表２６】
2019057921.tif 000028
【０１５５】
いくつかの実施形態のバックエンドシステムは、異なる権限を有する多数の異なるユーザによって利用することができる。ユーザは、以下の表２７に示すユーザ表とユーザグループ表とによって管理される。リソース、アプリケーションおよび配備は、ユーザと関連付けられる。これにより、バックエンドシステムは、アプリケーションまたは配備を閲覧、編集および管理する権限を有する者を管理することが可能になる。ユーザ表は、ユーザについての情報を含んでよい。ユーザは、１つの会社（および／または他の同様の種類のエンティティ）ならびに１つ以上のユーザグループと関連付けてもよい。同じ会社の同じ権限を有するユーザは、同じの会社の別のユーザが作成したリソースにアクセスすることができる。
【０１５６】
【表２７】
2019057921.tif 000029
【０１５７】
以下の表２８に示すユーザグループ表は、共通の許可権限を有するユーザのグループを規定することができる。
【０１５８】
【表２８】
2019057921.tif 000030
【０１５９】
以下の表２９に示す会社表は、会社を規定することができる。１ユーザは１社のみと関連付けることができる。これにより、同じ会社の同一権限を有するユーザは、同じ会社の他のユーザが作成したリソースにアクセスすることが可能になる。
【０１６０】
【表２９】
2019057921.tif 000031
【０１６１】
当業者であれば、上記したデータベーススキーマは、ひとえに例示的なものであり、異なる実施形態を様々な異なるスキーマを用いて実現可能なことを認識しよう。例えば、異なる実施形態において、表以外の異なる構造を用いてもよい。別の例として、様々な異なる部分要素に別の名称を付し、またこれを様々な異なる表に入れ、異なるテータ型などを用いて実現してもよい。
ＩＶ．動作方法
【０１６２】
第ＩＶ節Ａ項において、いくつかの実施形態において用いられる様々な通信プロトコル概念的説明を行う。そこで、第ＩＶ節Ｂ項において、いくつかの実施形態において性能を最適化するために用いられる様々な符号化方法について述べる。次に、第ＩＶ節Ｃ項において、いくつかの実施形態において行われる様々な適応的調整について述べる。最後に、第ＩＶ節Ｄ項において、ターゲットから受信したターゲットシステム入力の利用について述べる。以下に述べる多様な方法は、第Ｉ節において上述したようなハードウェア要素の様々な組合せ、第ＩＩ節に上述したようなソフトウェア要素の様々な組合せ、ならびに／または他の適切な要素（および／もしくは要素の組合せ）を用いて実現してもよい。
Ａ．プロトコル
【０１６３】
いくつかの実施形態において、ターゲットにおけるリモート画面キャプチャ、送信および再生の様々なアプローチを用いることができる。いくつかの実施形態により、ホストとターゲットとの間（および／またはホストとリモートサーバとの間）で効率的なデータ交換が可能な拡張可能プロトコルが提供される。
【０１６４】
いくつかの実施形態において、ホストは、ターゲットの状態を認識せずに、画面要素を送信する要求がターゲットから送られるのを待つという「ステートレス」の実現形を用いてもよい。このような実現例のひとつとして、従来のＶＮＣプロトコルがある。このようなアプローチの利点として、ホストが単純になり、メモリ消費が低減し、また複数のターゲットとの相互動作が容易になることがある。しかし、ターゲットは更新を要求してホストにデータを送らせる必要があるため、応答待ち時間が問題になり得る。さらに、ホストはターゲットがどんなデータを利用可能か「知らない」ため、画像全体を送る必要があり、帯域幅を浪費することがある。
【０１６５】
いくつかの実施形態において、ホストは、ターゲットの状態を認識して変更のみを送ればよいという「ステートフル」実現形を用いてもよい。このようなアプローチにより、変更のみが送られるため、帯域幅条件が緩和され、またホストでの検出直後に変更が送られるため、待ち時間も低減する。このアプローチの場合、ホストは、少なくとも最新の情報のコピーをターゲットへ送り続ける必要がある。
【０１６６】
ステートフル実現形は、いくつかの実施形態において好適な通信モードであることがある。なぜなら、ステートフルモードは、主に２つの装置（例えば、スマートフォンおよび車載ＨＵ）間のピアツーピア通信を企図しているからである。しかし、いくつかの実施形態のコマンドベースのプロトコルを用いても、ステートフル実現形およびステートレス実現形の混合が可能になる。
【０１６７】
「組合せ」実現形により、あるターゲット装置については状態を保持し、他のターゲットではステートレスに動作することができる。このような構成は、例えば、スマートフォンが車載ヘッドユニット用のみならず１組の後部座席用娯楽ディスプレイ用のサーバとして機能する構成を実現する場合に利用してもよい。
【０１６８】
拡張可能で効率的とするために、いくつかの実施形態において、コマンドベースの通信プロトコルが用いられる。コマンドは、ホストから更新画面情報（例えば、新規画面、新規ビデオフレーム、新規ベクトル要素など）と共にターゲットへ送ってもよく、あるいは、コマンドは、ターゲットからユーザ入力情報（例えば、タッチスクリーン入力、キーボードもしくはキーパッドイベントなど）、装置情報（例えば、画面解像度、機能情報など）、または外部システム情報（例えば、ＧＰＳ、ＣＡＮバス情報など）などと共に送ることができる。これらのコマンドは、実際のデータと共にヘッダ情報、特性、およびペイロードを含んでよい。
【０１６９】
図１１は、いくつかの実施形態において用いられ少なくとも１つのホストと少なくとも１つのターゲットとの間の相互動作を可能にするホスト側（すなわち「サーバ側」）処理１１００のフローチャートを示す。このような処理は、例えばいくつかの実施形態のホストアプリケーションがホスト装置によって起動されると、開始することができる。
【０１７０】
次に、処理１１００は、ターゲットとの通信リンクを確立する（１１０５において）ことができる。このようなリンクは、適切な様々な方法で（例えば、様々なユーザ優先度、設定および／もしくは選択に基づいて、ならびに／または他の適切な方法で１組のメッセージをホストおよびターゲット間において自動転送することにより）確立することができる。リンクの確立に用いられる動作は、少なくとも一部がリンクの種類（例えば、ホストおよびターゲット間の有線接続、Ｂｌｕｅｔｏｏｔｈ接続など）に依存してよい。
【０１７１】
そこで、本処理は、プレーヤ情報をターゲットから受信する（１１１０において）ことができる。このような情報には、例えば、画面解像度、画面符号化方式、フレームレート、機能がある。
【０１７２】
次に、本処理は、コマンドをターゲットから受信したか否かを判定する（１１１５において）ことができる。このようなコマンドは、例えば、タッチスクリーンコマンド、ハードウェアボタン押下、フレームレート変更などを含んでよい。いくつかの実施形態において、ターゲット装置は、受動型装置でよい（すなわち、ホストは、何らかの応答を受信したか否かに関係無く、単にデータをターゲットへ送ることができる）。このような場合、動作１１２０を省略してよい（および／または受信したどんな情報も無視してよい）。
【０１７３】
本処理は、受信したコマンドが無いと判断する（１１１５において）と、動作１１３０に進むことができる。あるいは、本処理がコマンドを受信したと判定する（１１１５において）と、処理１１００は、この受信したコマンドを処理し（１１２０において）、ホスト状態を更新するか、または入力イベントをシミュレートする（１１２５において）。いくつかの実施形態において、通信リンクがホストおよびターゲットによって維持されている限り、動作１１１５〜１１２５を繰り返し行ってよい。
【０１７４】
ターゲットからコマンドを受信しなくなったと判断する（１１１５において）と、または（１１２５において）ホスト状態を更新した後、本処理は、ホスト状態が変わったか否かを判定する（１１３０において）ことができる。このような変更を挙げると、例えば、（更新を検出可能なシステム上で）更新を必要とする画面の変更、ストリーミングが可能な新規の音声フレーム、画面リフレッシュ時間の経過（例えば、ホストは、画面が変更されたか否かを判定できず、ターゲットから提供されたフレームレートに基づいて画面リフレッシュ情報を一定間隔で送る場合）などがある。
【０１７５】
本処理は、ホスト状態に変化が無いと判定する（１１３０において）と、終了することができる。あるいは、本処理は、ホスト状態が変化したと判定すると、ステートフル実現形を使用しているか否かを判定する（１１３５において）ことができる。このような判定は、適切な様々な方法で（例えば、ターゲットに問い合わせて、利用可能な通信リンク種別の判定、ターゲットへ送られる情報の種類などに基づいてターゲットの能力を判定することにより）行うことができる。
【０１７６】
本処理は、ステートレス実現形を用いるべきであると判定する（１１３５において）と、現在の情報でデータフレームを作成し（１１４０において）、動作１１５５へ進む。このような情報には、例えば、画像データ、ベクトルデータなどがある。
【０１７７】
本処理は、ステートフル実現形を利用中であると判定する（１１３５において）と、前回の情報と現在の情報（例えば、リモートサーバから受信した更新データに基づいた情報）の差を求め（１１４５において）、この差に基づいてデータフレームを作成する（１１５０において）。
【０１７８】
データフレームを作成する（１１４０または１１５０において）際、本処理は、（例えば、Ｈ２６４ビデオ符号化フォーマットを用いて）ビデオフレームを符号化し、（例えばｍｐ３フォーマット、先進的音響符号化（ＡＡＣ）フォーマットなどを用いて）音声ストリームを符号化し、画面レートを（例えば１４２０符号化を用いて）低減し、および／またはデータの汎用圧縮（例えば、ＺＬＩＢ圧縮、ＬＺ４圧縮など）を行う。ある符号化方式を用いる場合、ビデオデータは、前回のフレームからの差分のみを含むことがあり、そこで動作１１４５を省略してよい場合もある。
【０１７９】
データフレームを作成した（１１４０または１１５０において）後、本処理は、データフレームを含むコマンドをターゲットへ送って（１１５５において）、終了することができる。いくつかの実施形態において、通信リンクがホストおよびターゲットによって維持されている限り、動作１１３０〜１１５５を繰り返し行ってよい。
【０１８０】
いくつかの実施形態において、動作１１１５〜１１２５は、動作１１３０〜１１５５と並行して行うことができる。このような実施形態において、本処理は、ターゲットをモニタして、何らかのコマンドを受信したか否かを判定し、また、ホスト状態もモニタして、更新が必要か否かを判定することができる。
【０１８１】
当業者であれば、処理１１００は本質的に概念的なものであり、本発明の意図から逸脱することなく様々な異なる様態で実現可能なことを認識しよう。例えば、処理１１００の様々な動作は、異なる順序で行うことができる。加えて、場合に応じて様々な他の動作を行い、かつ／または様々な動作を省略することができる。本処理は、より大きなマクロ処理の一部として行ってもよいし、あるいは、複数の部分処理に分割してもよい。このような処理は、連続的に行ってもよいし、１組の条件を満たす場合は一定間隔で行ってもよいし、および／または、さもなければ場合に応じて行ってもよい。
【０１８２】
図１２は、いくつかの実施形態において用いられ少なくとも１つのホストと少なくとも１つのターゲットとの間の相互動作を可能にするターゲット側（すなわち「クライアント側」）処理１２００のフローチャートである。このような処理は、例えば、いくつかの実施形態において用いられるブラウザまたはプレーヤがターゲット装置によって起動されると開始することができる。次に、処理１２００は、ホストとの通信リンクを確立する（１２１０において）ことができる。このようなリンクは、適切な様々な方法で（例えば、様々なユーザ優先度、設定および／もしくは選択に基づいて、ならびに／または他の適切な方法で１組のメッセージをホストおよびターゲット間において自動転送することにより）確立することができる。リンクの確立に用いられる動作は、少なくとも一部がリンクの種類（例えば、ホストおよびターゲット間の有線接続、Ｂｌｕｅｔｏｏｔｈ接続など）に依存してよい。
【０１８３】
次に、処理１２００は、プレーヤ情報をホストへ送る（１２２０において）ことができる。このような情報は、ターゲット装置にて用いられるプレーヤに対応しコンテンツをユーザへ提供可能なものである。プレーヤ情報は、プレーヤに関連する様々な属性（例えば、画面解像度、画面符号化方式、フレームレート、機能など）を含んでよい。
【０１８４】
そこで、処理１２００は、コマンドをホストから受信したか否かを判定する（１２３０において）ことができる。このようなコマンドは、適切な様々なフォーマット、プロトコル、インタフェースなどを用いることができる。コマンドは、通信リンクを介して受信することができる。
【０１８５】
本処理は、コマンドをホストから受信したと判定する（１２３０において）と、処理１２００は、ホストコマンドを適切な様々な方法で処理する（１２４０において）ことができる。例えば、このような処理は、フレーム復号、ベクトル要素の抽出、音声フレーム処理などを含んでよい。
【０１８６】
ホストコマンドはデータフレームを含んでよい。このようなデータフレームは、（圧縮されていれば）解凍し、（ステートフル実現形において先行フレームへ適用可能な）ソフトウェアもしくはハードウェア復号器を用いて復号し、および／または様々な他の適切な方法で処理することができる。ホストコマンドはまた、アプリケーションに固有のコマンドに関する情報（例えば、編集フィールドをユーザが選択したと判定するとソフトウェアキーボードを表示する通知、アプリ開始通知、およびアクティブなアプリケーションのリストの作成とそれらをユーザに選択させるために使用可能な対応するＩＤなど）を含んでよい。
【０１８７】
そこで、本処理は、ホストコマンドに基づいてマルチメディア出力（例えば、ビデオ、音声、グラフィックなど）を更新する（１２５０において）ことができる。いくつかの実施形態において、通信リンクがホストおよびターゲットによって維持されている限り、動作１２３０〜１２５０を繰り返し行ってよい。
【０１８８】
マルチメディア出力を更新した（１２５０において）後、またはホストから受信するコマンドが無くなったと判定する（１２３０において）と、本処理は、ユーザ入力を受信したか否かを判定する（１２６０において）ことができる。ユーザ入力は、タッチスクリーン、ハードウェアボタン、音声入力などのターゲット要素を通して受信することができる。ユーザ入力は、通信リンクを介して受信してもよい。このようなユーザ入力は、ターゲット装置に提供されているアプリケーションまたはコンテンツに関する情報を含んでよい。例えば、ユーザが「次」キーを押下してプレイリスト中の次の曲へスキップすると、ユーザは、ターゲット装置などに表示されているアプリケーション（例えば、インタネットラジオアプリケーション）などへ入力を行うことができる。
【０１８９】
本処理は、ユーザ入力を受信したと判定する（１２６０において）と、ホストコマンドを作成し（１２７０において）、コマンドをホストへ送る（１２８０において）ことができる。いくつかの実施形態において、コマンドは、ターゲットにおいて符号化してもよい（例えば、マイクロホンからの音声をＡＡＣまたはＭＰ３フレームへ符号化する）。このようなコマンドは、適切な様々な方法でフォーマットし、様々な特定のデータ要素を含んでよい。このようなフォーマッティングは、ターゲットまたはホストの特性、ターゲットまたはホストの動作についてのユーザ優先度などに応じたものでよい。コマンドは通信リンクを介して送ることができる。
【０１９０】
コマンドをホストへ送った（１２８０において）後、または受信した利用入力が無いと判定した（１２６０において）後、本処理は終了することができる。いくつかの実施形態において、通信リンクがホストおよびターゲットによって維持されている限り、動作１２６０〜１２８０を繰り返し行ってよい。
【０１９１】
いくつかの実施形態において、動作１２３０〜１２５０は、動作１２６０〜１２８０と並行して行うことができる。このような実施形態において、本処理は、ホストをモニタして、何らかのコマンドを受信したか否かを判定し、また、ターゲットのユーザ入力をモニタして、ユーザ入力を受信したか否かを判定することができる。
【０１９２】
当業者であれば、処理１２００は本質的に概念的なものであり、本発明の意図から逸脱することなく様々な異なる様態で実現可能なことを認識しよう。例えば、処理１２００の様々な動作は異なる順序で行うことができる。加えて、場合に応じて様々な他の動作を行い、かつ／または様々な動作を省略することができる。本処理は、より大きなマクロ処理の一部として行ってもよいし、あるいは、複数の部分処理に分割してもよい。このような処理は、連続的に行ってもよいし、１組の条件を満たす場合は一定間隔で行ってもよいし、および／または、さもなければ場合に応じて行ってもよい。
【０１９３】
図１１〜図１２を参照して上記したアプローチと同様に、ホストおよびリモートサーバ（ならびに／またはサードパーティサーバ）は、通信リンクを確立し、かつ／または場合に応じてデータを送受信することができる。このような構成において、ホストおよびリモートサーバは、それぞれ他のシステム構成要素からのデータおよび／または命令を送受信することにより、様々な異なる機能（例えば、データ記憶および検索、要求、処理など）を別個に、または協働で行うことができる。
Ｂ．符号化
【０１９４】
最適なスループットを達成するため、いくつかの実施形態において、ターゲットへ送られるデータを符号化する様々な符号化方法が用いられる。このようなアプローチは、主にホストからターゲットへ送られる画面データに用いることがあるが、ホスト（および／またはリモートもしくはサードパーティサーバ）へ送られるデータにも用いることがある。コマンドベースのプロトコルがいくつかの実施形態において用いられているため、符号化方法はコマンドヘッダに記述され、これらを動的に切り換えて様々な性能パラメータ（例えば、利用可能な帯域幅、アプリケーション負荷など）および／または他の適切な要因（例えば、ユーザ選択、コンテンツに関する特性など）に適合させるようにしてもよい。
【０１９５】
図１３は、いくつかの実施形態においてホストからターゲットへ送られるデータの符号化に用いられる処理１３００のフローチャートである。このような処理は、例えば、ターゲットへ送るデータをホストが入手可能になると開始することができる。
【０１９６】
次に、処理１３００は、画面ＸＯＲ演算を行うか否かを判定する（１３０５において）ことができる。このような判定は、適切な様々な要因に基づいて適切な様々な方法で行うことができる。本処理は、画面ＸＯＲを行うと判定する（１３０５において）と、現在の画面と最新の画面との間でＸＯＲ演算を行い（１３１０において）、変化した画素を符号化する。
【０１９７】
ＸＯＲ演算を行うためには、ステートフル通信モードが必要になる。ホストは、各新規画面を最近に送られた画面と比較し、変化した画素のみを送るようにしてもよい。これらの変化は、例えば、変化した画素のみを送って、ギャップ（すなわち、変化していない画素）を単純計数値で符号化するランレングス符号化（ＲＬＥ）を用いて符号化してもよい。このようなアプローチは、画面変化が少ない場合に有用で、非常に効率的なことがある。
【０１９８】
本処理は、画面ＸＯＲを行わないと判定する（１３０５において）と、あるいはＸＯＲを行った（１３１０において）後は、ダウンサンプリング動作を行うか否かを判定する（１３１５において）ことができる。このような判定は、該当する様々な要因に基づいて適切な様々な方法で行うことができる。本処理は、ダウンサンプリング動作を行うと判定する（１３１５において）と、現在のデータをダウンサンプリングする（１３２０において）ことができる。
【０１９９】
典型的には、品質劣化、変換速度および画像サイズ間でバランスをとる必要がある。例えば、いくつかの実施形態によってサポートされる１つのダウンサンプリングフォーマットとして、「１４２０」があり、これは、画素あたり１２ビットを用い、ＹＵＶ色空間に（８ビットのＹ面に続いて各８ビットの２×２サブサンプルＵ面およびＶ面を用いて）画素を蓄積するものである。
【０２００】
本処理は、ダウンサンプリングを行わないと判定する（１３１５において）か、またはダウンサンプリングを行った（１３２０において）後、画像符号化を行うか否かを判定する（１３２５において）。このような判定は、該当する様々な要因に基づいて適切な様々な方法で行うことができる。本処理は、画像符号化動作を行うと判定する（１３２５において）と、標準フォーマットを用いて現在の画像データを符号化する（１３３０において）ことができる。
【０２０１】
このような符号化には、ＪＰＧまたはＰＮＧなどの標準画像フォーマットを用いることがでる。ＪＰＧはかなりコンパクトにできるが、特に品質が劣化する。しかし、画像を十分な高速で符号化することが問題である。このようなアプローチは、ホストＣＰＵを用いて行えば（しかもＣＰＵに十分な処理能力がないと）、毎秒２５〜３０フレームの速度を達成するには遅すぎる場合がある。しかし、専用のビデオハードウェアを用いて行えば、性能は、このようなスループットを達成するのに十分なものとなろう。いくつかの実施形態は、ＰＮＧ、ＪＰＧおよび／または他のフォーマットによって符号化されたフレームまたは画像をサポートしている。
【０２０２】
本処理は、画像符号化を行わないと判定する（１３２５において）と、または、画像符号化を行った（１３３０において）後は、ビデオ符号化を行うか否かを判定する（１３３５において）ことができる。このような決定は、該当する様々な要因に基づいて適切な様々な方法で行うことができる。本処理は、ビデオ符号化動作を行うか否かを判定する（１３３５において）と、標準フォーマットを用いて現在の画像データを符号化する（１３４０において）。
【０２０３】
標準ビデオ符号化フォーマットは非常に良好な圧縮を行うことができ、ストリーミングしてターゲットにより直接再生することができる。このようなビデオフォーマットの一例として、「Ｈ．２６４」（すなわち「ＭＰＥＧ−４」）がある。このようなアプローチの場合、ターゲットにビデオ復号器を設ける必要がある。別の利用可能なフォーマットとして、より良好な符号化速度が可能な「ＶＰ８」がある。画像符号化と同様に、ビデオ符号化を専用のビデオハードウェアを用いて最適化することができる。
【０２０４】
画像およびビデオ符号化技術を用いて、コンパクトで標準的な画像またはビデオストリームを生成することができる。これらをリアルタイムで符号化することは、ホスト装置ＣＰＩ上において非常に煩雑となることがあり、十分に高速のフレーム数／秒レートを達成するのに十分なＣＰＵ性能が無い可能性がある。この問題への解決策として、最近の装置（例えば、スマートフォン、タブレットなど）で典型的に利用可能な専用のビデオ符号化ハードウェアを利用することがある。多くのこのような装置はリアルタイム録画をサポートしている場合があり、これは、典型的には、このような高速のリアルタイムのハードウェア符号化を用いている。いくつかのシステムにより、ビデオ符号化ハードウェアへのアクセスと、（例えばＯＳを介する）入出力の制御が可能になり、これにより、いくつかの実施形態において、非常に効率的かつコンパクトなリモート画面投写方式が得られる。
【０２０５】
本処理は、ビデオ符号化を行わないと判定する（１３３５において）と、またはビデオ符号化を行った（１３４０において）後は、データを圧縮するか否かを判定する（１３４５において）ことができる。このような決定は、該当する様々な要因に基づいて適切な様々な方法で行うことができる。本処理は、圧縮動作を行うことを判定する（１３４５において）と、現在のデータを圧縮する（１３５０において）ことができる。
【０２０６】
いくつかの実施形態において、汎用圧縮アルゴリズムをデータへ適用することができる。１つのこのような選択肢として、比較的良好な圧縮を行う標準的な「ｚｌｉｂ」の利用があるが、実際の圧縮処理が非常に低速でＣＰＵに集約的なことがある。別のアプローチとして、より高速の「ＬＺ４」圧縮の使用がある。いくつかの実施形態では、両アルゴリズムがサポートされ、また他の圧縮タイプも追加し、利用することができる。
【０２０７】
本処理は、圧縮を行わないと判定する（１３４５において）と、または（圧縮を行った１３５０において）後は、データをターゲットへ送って（１３５５において）、終了することができる。
【０２０８】
当業者であれば、処理１３００は本質的に概念的なものであり、本発明の意図から逸脱することなく様々な異なる様態において実現可能なことを認識しよう。例えば、処理１３００の様々な動作は、異なる順序で行うことができる。加えて、場合に応じて様々な他の動作を行い、かつ／または様々な動作を省略することができる。本処理は、より大きなマクロ処理の一部として行ってもよいし、あるいは、複数の部分処理に分割してもよい。このような処理は、連続的に行ってもよいし、１組の条件を満たす場合は一定間隔で行ってもよいし、および／または、さもなければ場合に応じて行ってもよい。
Ｃ．適応的調整
【０２０９】
いくつかの実施形態の主要な特徴の１つとして、使用するデータ種別、その符号化方法、および使用する画質についての適応的アプローチの使用がある。コマンドベースのプロトコルが用いられるため、コマンドは、フォーマット、圧縮、符号化、フレームレート、品質および／または他の属性をオンザフライで変更することができる。
【０２１０】
図１４は、いくつかの実施形態において用いられ現在の動作条件に基づいて様々な属性を適応的に調整して最適化されたスループットおよび品質を達成する概念的処理１４００のフローチャートである。このような処理は、例えばいくつかの実施形態においてホストからターゲットへ送られるデータが得られると、開始することができる。図示のように、本処理は、利用可能な帯域幅（例えばフレーム数／秒で）を決定する（１４１０において）ことができる。このような決定は、適切な様々な方法で（例えば、ホストおよびターゲット間において前回送られたデータを調べたり、最大帯域幅を指定するシステム情報を索出したりするなどにより）行うことができる。
【０２１１】
次に、本処理は、主アプリケーションレンダリングレートを決定する（１４２０において）ことができる。このような決定は、適切な様々な方法で（例えば、アプリケーションに対応する性能情報を策出したり、主アプリケーションの実行に用いられる１つ以上のハードウェア要素について性能データを策出したりするなどにより）行うことができる。
【０２１２】
そこで、本処理は、決定したパラメータ（例えば、帯域幅、レンダリングレート、および／または他の適切な性能パラメータ）に少なくとも部分的に基づいてフレームレートを調整する（１４３０において）ことができる。このようにして、いくつかの実施形態は、決定したパラメータに基づいて、フレームレートを連続的に調整することができる（あるいは、場合に応じて、より小さい、または大きいデータパケットを生成するように画質を調整することができる）。加えて、ターゲットプレーヤは、プレーヤがサポート可能なフレームレートを判定し、このレートを特別なコマンドによってホストへ報告する。そこで、ホストは、ターゲットの好適なフレームレートと、ホストにてサポートするフレームレートがあればそれとの間の最小値として、ホストのフレームレートを設定することができる。このようにして、ホストは、ターゲットの処理可能なフレーム数を超えるフレーム数の処理および送信は行わない。
【０２１３】
次に、本処理は、決定したパラメータに少なくとも部分的に基づいて画面キャプチャレートを調整する（１４４０において）ことができる。例えば、主アプリケーションレンダリングが低化した場合、画面キャプチャ頻度を低減することができる。例えば、ウェブアプリケーションのロード中は、いくつかの実施形態のシステムにおいては、画面キャプチャは不要であり、ターゲットに対して待ち状態を指示することができる。その結果、ホストのＣＰＵは、実際のアプリケーション処理を行うことができる。
【０２１４】
そこで、本処理は、決定したパラメータに少なくとも部分的に基づいて画質を調整し（１４５０において）、終了することができる。上記したように、帯域幅を狭くすると、送信する画像の品質を低下させることができる。別の例として、より低品質の画像をより高品質の画像間に分散させることができる（例えば、アニメーションまたはビデオを生成するとき、ホストは、高品質画像を毎秒１回送って、残りの画像をより低品質で送って、利用帯域幅を低減することができる）。
【０２１５】
当業者であれば、処理１４００は本質的に概念的なものであり、本発明の意図から逸脱することなく様々な異なる様態で実現可能なことを認識しよう。例えば、処理１４００の様々な動作は異なる順序で行うことができる。加えて、場合に応じて様々な他の動作を行い、かつ／または様々な動作を省略することができる。本処理は、より大きなマクロ処理の一部として行ってもよいし、あるいは、複数の部分処理に分割してもよい。このような処理は、連続的に行ってもよいし、１組の条件を満たす場合は一定間隔で行ってもよいし、および／または、さもなければ場合に応じて行ってもよい。
Ｄ．ユーザおよびターゲットシステム入力
【０２１６】
いくつかの実施形態において、ターゲットは、クライアント側（例えば、ターゲットとして機能する車両ＨＵ）のユーザ入力イベントをキャプチャし、キャプチャしたイベントを現在実行中のアプリケーションによる処理対象として（ホストを介して）リモートサーバへ送る機能を有してもよい。いくつかの実施形態は拡張性を有するため、様々な種類の既存の、または今後開発されるユーザ入力ハードウェア要素（および対応するイベント）を含み得る。
【０２１７】
タッチスクリーンは、いくつかの実施形態においてユーザ入力イベントをキャプチャするために用いることが可能なハードウェア要素の一例である。任意のキャプチャされたタッチイベント（例えば、１回のタッチイベント、複数回のタッチイベントなど）を変換してホストへ送ることができる。ハードウェアボタン（またはキーパッドおよび／もしくは他の適切な素子などのボタンの集合をアプリケーション側で（ホスト、リモートサーバ、および／またはサードパーティサーバなどにおいて）ハードウェアキーイベントへ変換することができる。
【０２１８】
複数のモードのキーボード入力をいくつかの実施形態においてサポートしてもよい。例えば、キーボードをターゲット側にて自前でレンダリングしてもよい。キーボードは、入力要素をフォーカスすると表示するようにしてもよい。こうすれば、キーボードはターゲット上に直接レンダリングされるため、非常に応答性の高いＵＩが可能になり、また、送受信されるデータ量が最小限になる。あるいは、キーボードは、アプリケーションそのものによって（例えばＨＴＭＬを介して）レンダリングし、任意の他のＵＩ要素と同様の様態で扱ってもよい。
【０２１９】
いくつかのターゲットシステム（例えば、車両）は、ステアリングホイールボタン、回転ノブなどの特別な入力機能を有してもよい。このような入力は、１組の拡張可能ユーザ入力コマンドによってサポートすることがでる。これらの入力は、ハードウェアによってキャプチャし、システムアダプタ（例えば、上記したシステムアダプタ６２０）によってコマンドへ変換され、ホスト（および／またはリモートもしくはサードパーティサーバ）へ送ることができる。ホストおよび／またはサーバ上において、コマンドは、汎用ＵＩコマンド（例えば、スクロール、戻るなど）へ翻訳するか、またはシステム固有のＡＰＩによって処理してもよい。
【０２２０】
ユーザ入力に加えて、いくつかのターゲットシステム（例えば、車両）は、いくつかのアプリケーションにて利用できた他の入力源（例えば、ＧＰＳ、速度などに関するセンサ、ＣＡＮまたは他のバス情報など）を有する。いくつかの実施形態のコマンド構造によれば、このようなデータをターゲット、ホストおよびサーバ間にて送ることが可能になる。このようなデータは、記述通知機能を用いて、要求／応答メッセージを用いて、および／または他の適切な方法を用いてブロードキャストメッセージとして送ってもよい。このような入力源は、システムアダプタ構成要素によって取り扱ってもよい。
【０２２１】
図１５は、いくつかの実施形態において用いられユーザ入力イベントをキャプチャし応答するターゲット側の概念的処理１５００のフローチャートである。このような処理は、いくつかの実施形態において、例えばアプリケーションがターゲットによって起動されると、開始することができる。図示のように、本処理は、ユーザ作成の入力をターゲットにおいて受信する（１５１０において）ことができる。そこで、本処理は、受信した入力をホストへ送る（１５２０において）ことができる。このような入力は、少なくとも一部がターゲット要素、ホスト要素、各要素間の通信経路の構成、および／または他の該当する要因に基づいて、適切な様々な方法で受信し、フォーマットし、パッケージし、および／または送信することができる。
【０２２２】
当業者であれば、処理１５００は本質的に概念的なものであり、本発明の意図から逸脱することなく様々な異なる様態で実現可能なことを認識しよう。例えば、処理１５００の様々な動作は異なる順序で行うことができる。加えて、場合に応じて様々な他の動作を行い、および／または様々な動作を省略することができる。本処理は、より大きなマクロ処理の一部として行ってもよいし、あるいは、複数の部分処理に分割してもよい。このような処理は、連続的に行ってもよいし、１組の条件を満たす場合は一定間隔で行ってもよいし、および／または、さもなければ場合に応じて行ってもよい。
【０２２３】
図１６は、いくつかの実施形態において用いられユーザ入力イベントをキャプチャしイベントに応答するホスト側の概念的処理１６００のフローチャートである。このような処理は、例えばいくつかの実施形態においてアプリケーションがターゲットによって起動されると、開始することができる。図示のように、本処理は、ユーザ作成の入力をターゲットから受信する（１６１０において）ことができる。このようなユーザ入力は、上記した処理１５００などの処理を行っているターゲットから受信することができる。
【０２２４】
次に、処理１６００は、受信した入力に少なくとも部分的に基づいてユーザ入力イベントを生成する（１６２０において）ことができる。ユーザ入力イベントは、該当する場合、ホスト上で現在実行中のアプリケーションへ（例えばホスト上でイベントをシミュレートすることにより）提供してもよい。
【０２２５】
そこで、本処理は、リモートサーバに対してコマンドを生成して（１６３０において）、終了することができる。いくつかの実施形態において、受信した入力は、ホストによって完全に処理され、リモートサーバへコマンドは送られない（またはこの逆もある）。例えば、ユーザ入力コマンドは、ホストによってのみ処理し、現在アクティブの被管理アプリケーションへユーザ入力イベントとして送ってもよい。
【０２２６】
当業者であれば、処理１６００は本質的に概念的なものであり、本発明の意図から逸脱することなく様々な異なる様態で実現可能なことを認識しよう。例えば、処理１６００の様々な動作は、異なる順序で行うことができる。加えて、場合に応じて様々な他の動作を行い、および／または様々な動作を省略することができる。本処理は、より大きなマクロ処理の一部として行ってもよいし、あるいは、複数の部分処理に分割してもよい。このような処理は、連続的に行ってもよいし、１組の条件を満たす場合は一定間隔で行ってもよいし、かつ／または、さもなければ場合に応じて行ってもよい。
【０２２７】
図１５〜図１６を参照して上記した動作に加えて、いくつかの実施形態において、ホスト、リモートサーバ、および／またはサードパーティサーバを用いて、ターゲットから受信した入力に応動するようにしてもよい。ホスト、リモートサーバおよび／またはサードパーティサーバは、データおよび／または命令をそれぞれで、または協働して処理し、受信したターゲット入力に基づいて適切な動作を行うことができる。例えば、ユーザがターゲットメディアプレーヤ上の「次」ボタンを押下すると、ターゲットに接続されたホストへコマンドを送るようにしてもよい。ホストは、コマンドを受信および解読して要求を生成し、要求をリモートまたはサードパーティサーバへ送ることができる。リモートサーバは、受信した要求に基づいて、ある動作（例えば、リスト中の次のメディア要素に対応するデータの索出）を実行し、適切な応答をホストへ提供することができる。そこで、ホストは、受信した応答に基づいて、更新したコンテンツをターゲットへ送ることができる。
Ｖ．コンピュータシステム
【０２２８】
上記した処理およびモジュールの多くは、不揮発性記憶媒体に記録された１つ以上の命令セットとして指定されたソフトウェア処理として実現することができる。これらの命令が１つ以上の演算素子（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）など）によって実行されると、これらの命令によって、演算素子は命令に指定された動作を行う。
【０２２９】
図１７は、本発明のいくつかの実施形態を実現可能なコンピュータシステム１７００の模式的ブロック図を概念的に示す。例えば、図１を参照して上記したシステムは、コンピュータシステム１７００を用いて少なくとも一部を実現することができる。別の例として、図１１〜図１６を参照して上記した処理は、コンピュータシステム１７００を用いて実行される命令セットを用いて少なくとも一部を実現することができる。
【０２３０】
コンピュータシステム１７００は、適切な様々な装置を用いて実現することができる。例えば、コンピュータシステムは、１つ以上のパーソナルコンピュータ（「ＰＣ）、サーバ、モバイル装置（例えば、スマートフォン）、タブレット装置、および／または任意の他の適切な装置を用いて実現することができる。様々な装置は、単独で機能し（例えば、コンピュータシステムは、１台のＰＣとして実現してもよく）、あるいは協働して機能し（例えば、コンピュータシステムのいくつかの構成要素がモバイル装置によって提供され、他の構成要素はタブレット装置によって提供される）てもよい。
【０２３１】
図示のように、コンピュータシステム１７００は、少なくとも１つの通信バス１７０５、１つ以上のプロセッサ１７１０、システムメモリ１７１５、リードオンリーメモリ（ＲＯＭ）１７２０、固定記憶装置１７２５、入力装置１７３０、出力装置１７３５、様々な他の構成要素１７４０（例えば、グラフィック処理装置）、および１つ以上のネットワークインタフェース１７４５を含んでよい。
【０２３２】
バス１７０５は、コンピュータシステム１７００の要素間の全通信経路を示す。このような経路を挙げると、有線、無線、光学および／または他の適切な通信経路がある。例えば、無線接続プロトコルもしくはシステムを用いて入力装置１７３０および／または出力装置１７３５をシステム１７００へ接続することができる。
【０２３３】
プロセッサ１７１０は、いくつかの実施形態の処理を実行するために、実行すべき命令および／または処理すべきデータをシステムメモリ１７１５、ＲＯＭ１７２０、および固定記憶装置１７２５などの構成要素から取り出することができる。このような命令およびデータは、バス１７０５を介して送ることができる。
【０２３４】
システムメモリ１７１５は、ランダムアクセスメモリ（ＲＡＭ）などの揮発性読出し書込みメモリでよい。システムメモリは、プロセッサが実行時に用いる命令およびデータの一部を蓄積することができる。いくつかの実施形態の実現に用いられる命令セットおよび／またはデータは、システムメモリ１７１５、固定記憶装置１７２５および／またはリードオンリーメモリ１７２０に蓄積してもよい。ＲＯＭ１７２０は、プロセッサ１７１０および／またはコンピュータシステムの他の要素の使用し得る静的データおよび命令を蓄積することができる。
【０２３５】
固定記憶装置１７２５は、読出し書込みメモリデバイスでよい。固定記憶装置は、不揮発性メモリデバイスでよく、コンピュータシステム１７００がオフすなわち電源オフであっても、命令およびデータを保存している。コンピュータシステム１７００は、着脱可能な記憶装置および／またはリモート記憶装置１７６０を固定記憶装置として用いてもよい。
【０２３６】
入力装置１７３０は、ユーザが情報をコンピュータシステムへ通信し、および／またはシステムの様々な動作を操作することが可能なものでよい。入力装置は、キーボード、カーソル操作装置、音声入力装置および／またはビデオ入力装置を含んでよい。出力装置１７３５は、プリンタ、ディスプレイおよび／または音声装置を含んでよい。入力および／または出力装置の一部または全体をコンピュータシステムへ無線で、または光学的に接続することができる。
【０２３７】
他の構成要素１７４０は、様々な他の機能を行い得る。これらの機能を挙げると、特定の機能（例えば、グラフィック処理、音声処理など）を行うこと、記憶装置を提供すること、外部システムまたは構成要素とインタフェースすることなどがある。
【０２３８】
最後に、図１７に示すように、コンピュータシステム１７００は、１つ以上のネットワークインタフェース１７４５を通して１つ以上のネットワーク１７５０へ接続することができる。例えば、コンピュータシステム１７００はインタネット上のウェブサーバへ接続され、コンピュータシステム１７００上で実行されるウェブブラウザは、ユーザがそのウェブブラウザにおいて動作するインタフェースと対話するようにウェブサーバと相互動作することができる。コンピュータシステム１７００は、ネットワークインタフェース１７４５およびネットワーク１７５０を通して１つ以上のリモート記憶装置１７６０および１つ以上の外部構成要素１７６５にアクセスすることができる。ネットワークインタフェース１７４５は、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を含んでよく、これらによってコンピュータシステム１７００は、リモートシステムおよび／または記憶装置へアクセスすることができ、また、リモートシステムおよび／または記憶装置はコンピュータシステム１７００（またはその要素）へアクセスすることができる。
【０２３９】
本明細書および本出願のいずれの請求項でも用いられるように、用語「コンピュータ」、「サーバ」、「プロセッサ」および「メモリ」はすべて、電子装置を指す。これらの用語は、人間または人間のグループを排除する。本明細書および本出願のいずれの請求項でも用いられるように、「不揮発性記憶媒体」という用語は、電子装置で読み取り可能な形態で情報を蓄積する触知可能な物理的実体のみに限定される。これらの用語は、いずれの無線または他の一過性の信号も除外する。
【０２４０】
当業者であれば、コンピュータシステム１７００の構成要素の一部または全体を本発明に関連付けて使用可能なことを認識しよう。当業者であればさらに、他の多くのシステム構成を本発明または本発明の構成要素と関連付けて用いてもよいことを理解する。
【０２４１】
加えて、図示の例において多数の個々のモジュールを個別素子として示したが、当業者であれば、これらのモジュールを組み合わせて単一の機能ブロックまたは要素にしてもよいことを認識しよう。当業者であれば、単一のモジュールを分割して複数のモジュールにしてもよいことも認識しよう。
【０２４２】
もちろん、上記は、本発明の例示的な実施形態の例示的詳細事項に関するものであり、以下の特許請求の範囲によって定義されるような本発明の意図および範囲から逸脱することなく変更が可能である。
【図１】
2019057921.tif 000032
【図２】
2019057921.tif 000033
【図３】
2019057921.tif 000034
【図４】
2019057921.tif 000035
【図５】
2019057921.tif 000036
【図６】
2019057921.tif 000037
【図７】
2019057921.tif 000038
【図８】
2019057921.tif 000039
【図９】
2019057921.tif 000040
【図１０】
2019057921.tif 000041
【図１１】
2019057921.tif 000042
【図１２】
2019057921.tif 000043
【図１３】
2019057921.tif 000044
【図１４】
2019057921.tif 000045
【図１５】
2019057921.tif 000046
【図１６】
2019057921.tif 000047
【図１７】
2019057921.tif 000048
【手続補正書】
【提出日】平成30年12月7日(2018.12.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチメディアコンテンツをターゲットカンバスへ提供する自動化された方法であって、該自動化された方法は、
ホストモバイル装置から前記ターゲットカンバスに対応する外部システムへの通信リンクを確立することと、
前記ホストモバイル装置において、前記ターゲットカンバスによって再生されるマルチメディアコンテンツをレンダリングすることであって、前記マルチメディアコンテンツは複数のスクリーンバッファへレンダリングされ、各スクリーンバッファはフルスクリーンビットマップまたはベクトルコマンドのセットのうちの１つを含み、前記レンダリングは個々のグラフィカルユーザインタフェース要素および前記マルチメディアコンテンツの各スクリーンのコンテンツをホストコマンドへ抽出することを含む、レンダリングすることと、
前記スクリーンバッファをホストコマンドに符号化することと、
前記ホストモバイル装置から前記ホストコマンドを、前記通信リンクを介して前記外部システムへ送信することとを含む自動化された方法。
【請求項２】
前記マルチメディアコンテンツをレンダリングすることは、前記ホストモバイル装置のハードウェア符号化器を用いて前記マルチメディアコンテンツを処理することを含む請求項１の自動化された方法。
【請求項３】
さらに、前記マルチメディアコンテンツを前記外部システムの別のターゲットカンバスによる再生のためにレンダリングすることと、
該レンダリングされたホストコマンドを、前記通信リンクを介して前記別のターゲットカンバスへ送ることとを含む請求項１の自動化された方法。
【請求項４】
前記ターゲットカンバスによって再生されるマルチメディアコンテンツをレンダリングすることは、
前記通信リンク上の帯域幅を判定し、
主アプリケーションレンダリングレートを判定し
少なくとも部分的に前記帯域幅および前記主アプリケーションレンダリングレートのうちの少なくとも一方に基づいて前記マルチメディアコンテンツを符号化することを含む請求項１の自動化された方法。
【請求項５】
前記外部システムは車載表示装置または医療装置である請求項１の自動化された方法。
【請求項６】
さらに、前記外部システムにおいて、前記ホストモバイル装置から送信された前記ホストコマンドを受信することと、
前記ホストコマンドに含まれる前記レンダリングされたコンテンツを処理し、該レンダリングされたコンテンツを前記ターゲットカンバスに表示することとを含む請求項１の自動化された方法。
【請求項７】
さらに、前記外部システムからユーザ入力操作を受信することと、
前記ユーザ入力操作をクライアントコマンドに変換することと、
前記通信リンクを介して、前記クライアントコマンドを送信することと、
前記ホストモバイル装置において、前記クライアントコマンドを受信することと、
前記クライアントコマンドをユーザ操作に処理することと、
前記ユーザ操作を前記ホストモバイル装置上で実行するアプリケーションに提供することと、
前記ホストモバイル装置上で実行する前記アプリケーションの出力を生成することと、
少なくとも部分的に前記ホストモバイル装置上で実行する前記アプリケーションの前記出力に基づいて前記レンダリングされたマルチメディアコンテンツを変更することとを含む請求項６の自動化された方法。
【請求項８】
外部システムに対応するウェブブラウザにおいてウェブベースアプリケーションを実行するモバイル装置であって、該モバイル装置は、
命令セットを実行するためのプロセッサと、
前記命令セットを保存する非一過性の媒体とを含み、該命令セットは、
前記モバイル装置と前記外部システムとの間の第１の通信リンクを確立する命令と、
前記モバイル装置において、前記特定のウェブベースアプリケーションに対応するコンテンツをレンダリングする命令であって、前記レンダリングは、前記外部システムに対して適切な解像度により前記モバイル装置上で実行されるウェブブラウザを使用して、フルスクリーンビットマップまたはベクトルコマンドのセットのうちの１つを含むスクリーンバッファを生成することを含む、レンダリングする命令と、
前記スクリーンバッファをホストコマンドに符号化する命令と、
前記ホストコマンドを表示のために前記外部システムへ送る命令とを含むモバイル装置。
【請求項９】
前記命令セットは、さらに、
前記外部システムからユーザ入力操作を受信する命令と、
前記ユーザ入力操作をクライアントコマンドへ変換する命令と、
前記第１の通信リンクを介して前記クライアントコマンドを送信する命令と、
前記モバイル装置において前記クライアントコマンドを受信する命令と、
前記クライアントコマンドをユーザ操作に実行する命令と、
前記リモートサーバにおいて前記ユーザ操作を前記特定のウェブベースアプリケーションに提供する命令とを含む請求項８のモバイル装置。
【請求項１０】
前記第１の通信リンクは無線接続を含む請求項８のモバイル装置。
【請求項１１】
前記外部システムは車載表示装置であり、前記モバイル装置はスマートフォンである請求項８のモバイル装置。
【請求項１２】
さらに、前記モバイル装置とリモートサーバとの間の通信リンクを確立すること、および
前記モバイル装置で、前記リモートサーバを介して特定のウェブベースアプリケーションにアクセスすることを含む請求項８のモバイル装置。
【請求項１３】
前記特定のウェブベースアプリケーションは、ＨＴＭＬ（Hypertext Markup Language）、Ｊａｖａスクリプトおよびカスケーディングスタイルシートのうちの少なくとも一つを使用するブラウザによって実行されるアプリケーションである請求項８のモバイル装置。
【請求項１４】
前記特定のウェブベースアプリケーションは、少なくとも１つのセルラ通信ネットワークを介してアクセスされる請求項８のモバイル装置。
【請求項１５】
マルチメディアコンテンツをユーザへ提供するシステムであって、該システムは、
マルチメディアコンテンツを表示するターゲットディスプレイを含むターゲットと、
前記ターゲットディスプレイの解像度に少なくとも部分的に基づいて、前記マルチメディアコンテンツをレンダリングすることによって、マルチメディアコンテンツを前記ターゲットよる表示対象として生成するホストとを含み、
前記マルチメディアコンテンツは、前記ホストにおいて、複数のスクリーンバッファにレンダリングされ、各スクリーンバッファは、フルスクリーンビットマップまたはベクトルコマンドのセットのうちの１つを含み、
前記スクリーンバッファは、ホストコマンドに符号化され、
前記ホストコマンドは、通信リンクを介して前記ホストから前記ターゲットに送信され、
前記ターゲットは、前記通信リンクを通じて前記ホストと相互動作して、マルチメディアコンテンツの表示を少なくとも部分的に制御するシステム。
【請求項１６】
前記ホストはモバイル装置であり、前記ターゲットは車載表示装置である請求項１５のシステム。
【請求項１７】
前記ターゲットは、少なくとも１つのユーザインタフェース要素を含み、
ユーザ入力操作は、前記少なくとも１つのユーザインタフェース要素を介して受信され、
ユーザ入力操作は、クライアントコマンドに変換され、
クライアントコマンドは、前記通信リンクを介して送信され、前記ホストで受信され、
クライアントコマンドは、ユーザ操作に処理され、
ユーザ操作は、前記リモートサーバで前記特定のウェブベースアプリケーションに提供される請求項１５のシステム。
【請求項１８】
さらに、前記ホストと相互動作して、マルチメディアコンテンツの表示を少なくとも部分的に制御するリモートサーバを含み、
前記ホストおよび前記リモートサーバは、少なくとも１つの無線接続を介して通信する請求項１７のシステム。
【請求項１９】
前記ホストで受信された少なくとも１つのユーザコマンドは、応答のために前記リモートサーバへ送信される請求項１８のシステム。
【請求項２０】
前記マルチメディアコンテンツはビデオコンテンツを含む請求項１５のシステム。
【外国語明細書】
2019057921000001.pdf