JP5545295B2 - シンクライアントセッションの確立方法 - Google Patents

Description

本発明は、遠隔通信分野に関し、ＩＭＳのようなＳＩＰベースのフレームワーク上にて稼働するシンクライアントシステムを稼働するための新しいセッション記述に関する。

より詳細には、本発明は、セッション開始プロトコル（ＳＩＰ）ベースのフレームワーク上のセッションネゴシエーション中にハンドシェイキング及びイニシャライゼーションメッセージを交換し、シンクライアント装置とシンクライアントサーバー間のシンクライアントコネクションの確立を改善するための方法に関する。

本発明は、上記方法を実行するために適応されるシンクライアントデバイス及びシンクライアントサーバーにも関する。
本発明は、上記方法を実行するために適応化されたシンクライアント装置及びシンクライアントサーバーにも関する。

セッション記述プロトコル（ＳＤＰ）［ＩＥＴＦ ＲＦＣ４５６６］は、セッションアナウンスメント、セッションインビテーション、及びその他態様のマルチメディアセッションイニシエーションを目的とする、マルチメディアセッションを記述するためのものである。ＳＤＰは、リアルタイムトランスポートプロトコル（ＲＴＰ）［ＩＥＴＦ ＲＦＣ３５５０］上で転送されるメディアストリームを記述するために最も一般的に用いられ、最小制御による音声及びビデオ会議のためのＲＴＰプロファイル［ＩＥＴＦ ＲＦＣ３５５１］にて定義される、音声及びビデオメディアのためのプロファイルを用いる。加えて、ＲＴＰペイロードフォーマット［ＩＥＴＦ ＲＦＣ３５５５］のＭＩＭＥタイプ登録は、音声及びビデオ会議用のＲＴＰペイロードフォーマットをＭＩＭＥサブタイプとして定義する。

一方、ＳＤＰは、リアルタイムトランスポートプロトコル（ＲＴＰ）上において転送可能な音声及びビデオ以外の他のメディアプロファイルを記述することにも使用され得る。

ＳＤＰは、エンドポイント間で共通のメディア記述について同意するため、一般にセッション開始プロトコル（ＳＩＰ）［ＩＥＴＦ ＲＦＣ３２６１］内で伝送される。セッション記述プロトコル（ＳＤＰ）［ＩＥＴＦ ＲＦＣ３２６４］のオファー／アンサーモデルは、フレームワークを定義し、これにより、２つのエンドポイントは、ＳＤＰメディア記述を交換し、そのメディアが関連するパラメーターに従って、どのメディアストリームを使用すべきかについて同意することになる。

典型的なシンクライアントセッションにおいては、パケットまたは回線交換のベアラコネクションに関する制御イベント用はもちろん、リモートデスクトップ／アプリケーション表示用のメディアストリームを構成及び確立することが要求される。そのようなセッションは、通常、リモートフレームバッファ（ＲＦＢ）プロトコル又はリモートデスクトッププロトコル（ＲＤＰ）、これ以外にもインディペンデントコンピューティングアーキテクチャプロトコル（ＩＣＡ）、Ｘ１１プロトコルに基づく、仮想ネットワークコンピューティング（ＶＮＣ）のようなシンクライアントプロトコルを用いて実現される。加えて、ピクセル（画素）は、リアルタイムトランスポートプロトコル（ＲＴＰ）を用いてストリームされ得るものであり、そのようなグラフィックプリミティブ（画像要素）は、ＲＴＰパケットにて搬送される。

モビリティー、次世代ネットワーク、及びリッチメディアアプリケーションに照らすと、サービス品質（ＱｏＳ）、適応性（適用性）、及び認証は、キーポイントである。そしてメディア形式の検出は、リソース予約プロセスにおいてはもちろん、オペレータがＩＰフローと同様に無線ベアラトラフィックを管理する（例えば、所定のポリシー、ユーザーサブスクリプション、又はサービスプロファイルに基づいて適当なリソース配分を適用する）ために重要である。第三世代パートナーシッププロジェクト［３ＧＰＰ ＴＳ ２３．２２８］によって定義されているようなＩＰマルチメディアサブシステム（ＩＭＳ）−ＳＩＰに基づきコアネットワーク上にオーバーレイネットワークを提供する−は、ＱｏＳリソースを承認する能力を含む「ポリシーと課金制御のアーキテクチャ」［３ＧＰＰ ＴＳ ２３．２０３］と相互接続されることも可能である。

アプリケーションは、単純なテキスト及び／又はグラフィックベースのアプリケーションから、ネットワーク遅延及び高いジーグ率に悩まされ得る音声及び／又はビデオベースのアプリケーションにまで範囲するため、リモートデスクトップコントロールセッション内の相異なるタイプのトラフィックに相応しい方法が要求される。

サービスの見地から、リモートデスクトップアクセスを通話確立やプッシュ−トゥ−Ｘサービスのような他のサービスと結合することが予想される。ＳＩＰを活用することで、従来のリモートデスクトップコントロールの使用態様を拡張できる。

ＱｏＳの見地からは、シンクライアントメディア記述上でＱｏＳ制御を可能とすることも望ましい。例えば、メディアのグラフック及びイベントタイプは、予め決められたＱｏＳプロファイルを割り当てられ、パケットまたは回線交換方式のベアラコネクション上をストリームされ得る。加えて、シンクライアント装置が移動しているとき、アクセスネットワーク環境が変化すると、適当なクオリティーセッティングの再割り当て（リソース配分、コーデックや転送プロトコル等のようなメディアパラメーターの再ネゴシエーション）が求められるだろう。

しかしながら、承認の見地からは、良く知られたシンクライアントプロトコルは、シンクライアント装置とシンクライアントサーバー間の接続を承認及び確立するために、それら独自の一揃いのルール及びメカニズム（つまり、組み込まれた交渉方法）を使用する。

関連分野の技術は、ＳＩＰフレームワーク上において、リモートデスクトップ制御機能と／に対して音声／ビデオといったマルチメディア転送を混合及び適応化する手段を提供していない。

本発明の典型的な目的は、ＳＩＰセッション内でメディアをネゴシエートするため既存機能にリモートデスクトップ制御を加え、リモートデスクトップ制御のセッションに適応したメディア転送（すなわち、ビデオ転送、音声転送、...）を可能とすることである。

本発明の典型的な態様によれば、ＳＩＰベースフレームワーク上のセッションネゴシエーション中にハンドシェイキング及びイニシャライゼーションメッセージを交換するシンクライアント装置とシンクライアントサーバー間において、シンクライアントセッションを確立する方法が提供される。ここで、前記シンクライアント装置及び前記シンクライアントサーバーは、前記シンクライアントセッションの間に、少なくとも一つのリモートアプリケーションの表示における複数のメディアストリームの結合及び適応化した転送を可能とする、シンクライアントコンテキストを示す追加情報を交換する。

本発明の典型的な態様によれば、シンクライアントサーバーとのシンクライアントセッションを確立するための方法を実行するために適応化されたシンクライアント装置が提供される。このシンクライアント装置は、シンクライアントセッションの間に、少なくとも一つのリモートアプリケーションの表示における複数のメディアストリームの結合及び適応化した転送を可能にする、シンクライアントコンテキストを示す追加情報を、前記シンクライアントサーバーと交換する手段を備え、前記追加情報は、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰ（セッション記述プロトコル）のオファー／アンサーメッセージ又はＸＭＬベースのオファー／アンサーメッセージを備える。

本発明の典型的な態様によれば、シンクライアント装置とシンクライアントセッションを確立するための方法を実行するために適応化されたシンクライアントサーバーが提供される。このシンクライアントサーバーは、前記シンクライアントセッションの間に、少なくとも一つのリモートアプリケーションの表示における複数のメディアストリームの結合及び適応化した転送を可能とする、シンクライアントコンテキストを示す追加情報を、前記シンクライアント装置と交換する手段を備える。

本発明によれば、ＳＩＰセッション内でメディアをネゴシエートするため既存機能にリモートデスクトップ制御を加え、リモートデスクトップ制御のセッションに適応したメディア転送（すなわち、ビデオ転送、音声転送、...）を可能とする。

上述の要約は、後述の詳細な説明と同様、本願発明の例示的な実施形態を示す添付図面に併せて読むことで、より良く理解されるだろう。
図１は、ＩＭＳ−ベースのアーキテクチャを概略的に示す。 図２は、動的に適応され得る複数のエリアから成るリモートデスクトップを示すシンクライアントビューアーを示す。 図３は、実施形態による方法のステップを記述したフローチャートを示す。 図４は、実施形態によるアプリケーションディスプレイリダイレクションの例を概略的に示す。

本実施形態によれば、セッション開始プロトコル（ＳＩＰ）ベースのフレームワーク上でセッションネゴシエーション中にハンドシェイキング及びイニシャライゼーションメッセージを交換するシンクライアント装置とシンクライアントサーバー間の、シンクライアントコネクションを確立するための方法が提供される。
本実施形態によれば、前記のシンクライアント装置及び前記のシンクライアントサーバーは、上述のシンクライアントセッション中における少なくとも一つのリモートアプリケーションの表示において、複数のメディアストリームの結合及び適応化した転送を可能とするために、シンクライアントコンテキストを示す追加情報を交換する。

追加情報は、マルチメディア転送及びリモートデスクトップ制御機能の両方を可能とし、ＳＩＰメッセージのボディーに埋め込まれＳＤＰ（セッション記述プロトコル）のオファー／アンサーメッセージ又はＸＭＬベースのオファー／アンサーメッセージにフォーマットされたシンクライアント情報を含んでもよい。

リモートデスクトップ制御機能は、第１デバイスから第２デバイスへの少なくとも１つのリモートアプリケーションのグラフィッカルなアップデートを、動的にダイレクト又はリダイレクトすることを含む機能を備える。

上述の第１デバイスは、モバイル通信装置であり、上述の第２デバイスは、固定された通信装置であるかもしれない。

本実施形態の他の態様によれば、上述のリモートデスクトップ制御機能は、ダウンリンクグラフィカルアップデートに用いられるものの外、最終的に異なる無線ベアラ及び／又は異なるＩＰ接続上でアップリンクイベントを転送することを含む機能を更に備える。無線ベアラは、３ＧＰＰの定義のように、ユーザー装置と無線アクセスネットワーク間にてユーザーデータを転送するために用いられる、レイヤー２サービスである。別のＩＰ接続は、異なるポート番号の割り当てによって、又は暗号化（つまり、ＩＰＳｅｃ）を伴わない／伴うＩＰトルネリングメカニズムを用いて実現され得る。

リモートデスクトップ制御機能は、リモートデスクトップ制御のセッション（すなわち、シンクライアントセッション）に対して少なくとも１つの音声／ビデオストリームを関連づけることを含む機能を更に備える。

本実施形態の一例によれば、前記の追加情報は、前記のシンクライアントセッションに関連付けて、前記の音声／ビデオストリームに対応するリモートディスプレイフレームバッファの座標及びサイズを備える。前記のフレームバッファの座標及びサイズは、装置のローカルスクリーン上のリモートデスクトップ表示上にレンダリングされるビデオを、適切に位置づけることを可能とする。

加えて、前記の追加情報は、フレームバッファ上の特定領域はアップデートを要しないことをサーバーに対して指示するクライアントリクエスト（フレームバッファフォーゲットリクエスト）の送信を可能とする。

本実施形態の他の例によれば、前記の追加情報は、ウィンドウＩＤ属性を備え、前記のウィンドウＩＤ属性によって特定されるグラフィカル領域がサイズ変更、移動又は両方がなされたことをサーバーに対して指示するクライアントリクエスト（ウィンドウアップデート）の送信を可能とする。

本実施形態の方法によれば、次の点が達成される：
−サービスの結合を可能とする
−モバイル装置から、リモートアプリケーションのディスプレイリダイレクトの制御を可能とする
−正確なセッション制御と同様の、サービス品質を可能とする
−広範囲の特定のシンクライアント認証とメディアネゴシエーションメカニズムを避けるため、一様なネゴシエーションの使用を可能とする。

実施形態によれば、ＲＦＢ又はＩＴＵ Ｔ．１２０（マルチメディア会議のためのデータプロトコル）等の知られたプロトコルのネゴシエーションステップは、部分的又は全体的にＳＤＰベースのネゴシエーションに置き換えられ、新しい情報が提供されることで、リモートディスプレイ接続のためのメディアトラフィックの混合が可能となる。ＳＤＰ及びＳＩＰフレームワークを使用したシンクライアントコネクションのネゴシエーションは、シンクライアントのシグナリング及びコントロールが前述のよく知られたシンクライアントプロトコルにより使用されるスクリーンアップデートの方策から区別される、という点において柔軟性を提供する。有利なことに、シンクライアントセッションは、セッションリダイレクト特性及び他のよく知られたＳＩＰ及びＳＤＰ拡張機能から利益を得ることができる。

加えて、シンクライアントコネクションは、第３世代パートナーシッププロジェクトによって標準化されたＩＰマルチメディアサブシステム［３ＧＰＰ ＴＳ ２３．２２８］仕様の中で正確に監視及び制御される。

ある典型的な使用状態では、キー及びマウスイベントのようなアップリンクユーザーイベントを、グラフィカルアップデートが送信されるものとは別の無線ベアラ及び／又はＩＰコネクションにおいて送信することが望ましいこともあるだろう。このようにすることで、サービス品質の適用が可能となり、システムの応答性を調整するような方策が可能となる。例えば、イベントベアラに対して非常に高い優先順位を保証することによってである。

更に、移動性に照らすと、モバイル装置は、広帯域のパケット交換ベアラが利用可能な無線ネットワークエリアから、狭帯域の無線ローカルエリアネットワーク（ＷＬＡＮ）接続しか利用できない他のエリアへ移動することがあるかもしれない。それゆえ、グラフィックメディアは、遅延及びバンド幅変動から障害を被る可能性がある。従って、セッションパラメーターを再ネゴシエートすることが望ましく、これは、ＳＩＰ及びＳＤＰオファー／アンサーモデル及びＩＭＳモビリティー管理手順を用いることによって可能となる。

提案された実施例を用いることによって、ユーザーイベントを送信するためのアップリンクベアラとグラフィカルアップデートを受信するためのダウンリンクベアラを、確立することが可能となる。シンクライアント装置においては、ＲＦＢプロトコルを用いて定期的に背景がアップデートされる間に、代替となる転送プロトコルを定義し、ビューアー送信モードに適応するビューアーを用意し（つまり、ＴＣＰ上のＲＦＢ／ＶＮＣプロトコルからＲＴＰプロトコルへ切り替える）、映像が再生されるスクリーンディスプレイの一部分を有効化し、ＲＴＰを用いてストリームすることも可能である。ビューアーが代替のメカニズムをサポートしない場合、ネゴシエーションフェーズにおいて、それは、ただ受け付けられないだけである。

本実施形態による方法は、本願発明のスコープから逸脱しない範囲内にて、他のＳＩＰ及びＳＤＰ拡張機能（ＲＦＣ３１０８、ＲＦＣ４９７５、ｄｒａｆｔ−ｇａｒｃｉａ−ｍｍｕｓｉｃ−ｓｄｐ−ｃｓ−０１、）を用いて実行可能である。

本実施形態による方法は、シンクライアント装置及びシンクライアントサーバーにより実行される。これらは、シンクライアントサーバーとシンクライアントコンテキストを示す追加情報を交換する手段を有し、これにより、前記シンクライアントセッションの間、少なくとも１つのリモートアプリケーションの表示において、複数のメディアストリームの結合及び適応化した転送を可能とする。前記の追加情報は、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰ（セッション記述プロトコル）のオファー／アンサーメッセージ又はＸＭＬベースのオファー／アンサーメッセージを含む。

上述のシンクライアント装置は、メディアリダイレクトの受信の通知を受けるために、及びリダイレクトアンサーを送信するために、メディアリダイレクトに関する意向をユーザーが登録することを可能とするインターフェイスを備えるモバイルユーザー装置であってもよい。

更に、上述のモバイルユーザー装置は、アップリンクイベントのために異なるＩＰ接続を確立するために適応化され、異なる無線ベアラの配置を引き起こすために適応化され、ダウンリンクグラフィカルアップデートのために使用されるものとは異なる別の無線ベアラにおいて前記のアップリンクイベントを転送するために適応化され、かつそのスクリーンに関するリモートディスプレイフレームバッファに音声／ビデオストリームのレンダリングをマッピングするために適応化される。

前記のモバイルユーザー装置は、メディアリダイレクトの受信の報告を受けるために、及びリダイレクトアンサーを送信するために、メディアリダイレクトに関する意向をユーザーが登録することを可能とするインターフェイスを備える。

本実施形態は、シンクライアント装置とシンクライアントセッションを確立するための方法の実行に適応化されたシンクライアントサーバーにも関する。前記シンクライアントサーバーは、前記のシンクライアントセッション中における少なくとも一つのリモートアプリケーションの表示において、複数のメディアストリームの結合及び適応化した転送を可能とするために、シンクライアントコンテキストを示す追加情報を前記シンクライアント装置と交換する手段を備える。

本実施形態によれば、進行中のワーク［ｄｒａｆｔ−ｇａｒｃｉａ−ｍｍｕｓｉｃ−ｓｄｐ−ｃｏｌｌａｂｏｒａｔｉｏｎ−００］の中で定義されたメディアタイプの拡張を可能とし、新しいメディアタイプ及び属性を定義する。

このようにすることで、本実施形態は、コントロールイベントメディアタイプを定義することを提示する。現在存在する"コントロール"メディアタイプは、あるセッション用の追加会議コントロールチャネルを規定するために用いられる。我々は、ポインター又はキーイベントのようなユーザーイベントのためのコントロールチャネルを正確なものにするため、別のメディアタイプを用いる必要がある。

最後に、本実施形態は、マルチメディアストリームをシンクライアントリモートディスプレイストリームに混合する方法を提供する。"ＳＤＰにおけるメディアラインのグルーピング" ［ＩＥＴＦ ＲＦＣ３３８８］は、メディアストリームをグループ化し、あるセッション内における相異なる複数のメディアストリームが、お互いどのように関連しているのかを表現するための手段を提供する。より端的には、リップ同期又はフロー識別の目的のためである。なお、グルーピングのメカニズムは、"ａ＝グループ"セッションレベル属性のセマンテックに依存する点に留意すべきである。従って、我々は、シンクライアント（"ＴＣ"）コンテキストのために新しいセマンテックを提示する。

ＲＦＢプロトコルに基づいて実行態様を説明する。

＜第１の例示的な実施形態＞
例示的な実施形態は、ＩＰマルチメディアサービスをモバイル装置に提供するために第３世代パートナーシッププロジェクト［３ＧＰＰ ＴＳ ２３．２２８］によって定義されたＩＭＳアーキテクチャフレームワークを示す、図１を参照して説明される。このアーキテクチャは、シンクライアント装置として振る舞うモバイルユーザー装置２、シンクライアントサーバー４、ＩＭＳコアシステム６、ポリシー決定機能モジュール８（ＰＤＦ）、３ＧＰＰパケットスイッチ（ＰＳ）コアネットワーク１０を備える。
ＩＭＳコアシステム６は、主に、通話セッション制御機能（ＣＳＣＦ）から成り、そこにはプロキシ−ＣＳＣＦ（Ｐ−ＣＳＣＦ）、サービング−ＣＳＣＦ（Ｓ−ＣＳＣＦ）、及びインターロゲイティング−ＣＳＣＦ（Ｉ−ＣＳＣＦ）が含まれる。
ＣＳＣＦは、ＩＭ（ＩＰ マルチメディア）コアシステム６内のサービスにアクセスする加入者向けにセッション制御を提供する。本質的には、ＣＳＣＦは、ＳＩＰサーバーである。これは、モビリティー用のＨＳＳ及びセキュリティー用のＡＡＡ（アクセス、認証及び会計）サーバーのようなネットワークデータベースと連携する役割を担う。これらのモジュールは、ＩＭＳにおいてＳＩＰシグナリングパケットを処理することを要求される。

ＩＭＳアプリケーションサーバーは、サービスを実行し、Ｓ−ＳＣＳＦとインターフェイスする。図１には幾つかのインターフェイスが示されており、［３ＧＰＰ ２３．２２８］に定義されているとおりである：ＩＳＣインターフェイスは、ＣＳＣＦとシンクライアントサーバー４間でメッセージを交換するために用いられる。

Ｇｍインターフェイスは、ＵＥ２とＣＳＣＦ間でＳＩＰベースの情報を交換するために用いられる。

ＧＱインターフェイスは、ＣＳＣＦとポリシー決定機能（ＰＤＦ）間でポリシー決定情報を交換するために用いられている。

インターフェイスＣｘは、ＣＳＣＦとホームサブスクリプションサーバー（ＨＳＳ）間の通信のために意図され、インターフェイスＤｘは、マルチ−ＨＳＳ環境において正しいＨＳＳを探索するためのものである。

インターフェイスＳｈは、ＨＳＳ又はＳＩＰ／ＯＳＡサービス機能サーバー（ＯＳＡ／ＳＣＳ）と情報通信するために、シンクライアントサーバー４により使用される。

インターフェイスＧｏは、サービス品質の制御及び承認、そしてＩＭＳと３ＧＰＰポリシーと課金制御（ＰＣＣ）アーキテクチャ［３ＧＰＰ ＴＳ ２３．２０３］間の相互関係情報の交換を行うために用いられる。

インターフェイスＵｔは、アプリケーションサーバーの制御のために用いられ、ＨＴＴＰプロトコルに準拠する。

ＩＭＳ ＳＩＰシグナリングプロトコルを用いるとき、シンクライアントＵＥ２は、ＳＩＰセッションの確立によって、図１に示すように、ＩＭＳシンクライアントアプリケーションサーバー（ＴＣＡＳ）４に接続され得る。この過程において、シンクライアントＵＥ２とＴＣＡＳ４は、ＱｏＳ及びメディアパラメーターをネゴシエートできる。ＵＥ２は、Ｕｔインターフェイスを介して、このＴＣＡＳ４について幾つかのコンフィグレーションも実行してよい。例えば、デスクトップ環境のコンフィグレーションである。アプリケーションによって生成されたピクセルは、Ｕｔ^＊インターフェイスを介して、エンド−トゥ−エンドの態様にてＵＥ２へストリームされる。そしてビデオ又は音声メディアも、ＵＥ２へストリームされる。

本例示的な実施形態に係る方法は、シンクライアントセッション、関連するメディア、及びリモート制御イベントを記述するためにＳＤＰを拡張する。オプションは、Ｗ３Ｃエクステンシブルマークアップ言語（ＸＭＬ）１．０（第４版）によって定義されているようなＸＭＬシンタックスを使用して前記の記述を提供することであろう。

端的には、ＲＦＢのようなシンクライアントプロトコルメカニズムによって表されるＩＰフローの関連付けられた、リモートデスクトップコントロールのＳＩＰセッションに、音声及び／又はビデオＩＰフローを動的にかつ適応化して付加する、というようなやりかたにて、本方法は、少なくとも１つの音声／ビデオストリームを、ＳＩＰシグナリングを用いてネゴシエートされたシンクライアントコネクションに関連づけることができる。

以降の説明は、ＳＤＰにおいてシンクライアントセッションの記述を提供するために必要とされる拡張機能の、シンタックス及びセマンテックを提供する。

ＳＤＰ［ＩＥＴＦ ＲＦＣ４５６６］によれば、ＳＤＰのコネクションデータ行は、次のシンタックスを有する：
ｃ＝＜ｎｅｔｔｙｐｅ＞＜ａｄｄｒｔｙｐｅ＞＜ｃｏｎｎｅｃｔｉｏｎ−ａｄｄｒｅｓｓ＞
なお、＜ｎｅｔｔｙｐｅ＞はネットワークタイプを示し、＜ａｄｄｒｔｙｐｅ＞はアドレスタイプを示し、そして＜ｃｏｎｎｅｃｔｉｏｎ−ａｄｄｒｅｓｓ＞はコネクションアドレスを示し、これはアドレスタイプに依存する。

基本的に、ＳＤＰアナウンスメントは、ＳＤＰ［ＩＥＴＦ ＲＦＣ２３２７］に記載されているように、一つのセッションレベルセクションと、それに続く１以上のメディアレベルセクションから成る。セッション−レベル情報は初期値を提供するため、コネクションデータ行がセッション−レベルに存在する場合には、コネクションデータ行がメディア記述にて搬送されない限り、それはメディア−レベルセクションに適用される。注意すべきは、全てのメディアにコネクションデータ行が存在する場合、それは、セッションレベルでは要求されないことである。

メディア記述は、"ｍ＝"行により開始し、次のメディア記述又は全セッション記述の最後まで続く。ＩＥＴＦ ＲＦＣ４５６６に定義された"ｍ＝"メディア行は、次のとおりである。
ｍ＝＜ｍｅｄｉａ＞＜ｐｏｒｔ＞＜ｔｒａｎｓｐｏｒｔ＞＜ｆｍｔ ｌｉｓｔ＞
ここで、＜ｍｅｄｉａ＞はメディアタイプであり、＜ｐｏｒｔ＞はメディアストリームが送付される転送ポートであり、＜ｔｒａｎｓｐｏｒｔ＞は"ｃ＝"フィールドに値が依存する転送プロトコルであり、＜ｆｍｔ ｌｉｓｔ＞はメディアフォーマットを指す。音声及びビデオのために、メディアフォーマットは、通常、ＲＴＰ音声／ビデオプロファイルに定義されているように、メディアペイロードタイプである。

現在のところ、音声、ビデオ、アプリケーション、データ及び制御のためにメディアタイプが定義される。

シンクライアントメディアタイプ。

我々は、最初に、ディスプレイアップデートの制御のために用いることができ、かつそれに向けて様々なエンコーディングを利用可能なリモートフレームバッファ（ＲＦＢ）プロトコルを検討する。

メディアタイプを、シンクライアント技術に対して規定することできる。メディアタイプは、"ａｐｐｌｉｃａｔｉｏｎ／ｒｆｂ"、"ａｐｐｌｉｃａｔｉｏｎ／Ｔ１２０"であり得る。
ｍ＝ａｐｐｌｉｃａｔｉｏｎ＜ｐｏｒｔ＞＜ｔｒａｎｓｐｏｒｔ＞ＲＦＢ

我々は、本文書において、更に、リモートフレームバッファプロトコルに注目する。

シンクライアント制御イベントメディアタイプ。

リモートディスプレイのグラフィカルアップデートに加えて、アップリンクイベントのための特定のコネクションを確立することも可能である。本目的のために、メディアタイプ"ａｐｐｌｉｃａｔｉｏｎ／ｃｏｎｔｒｏｌ−ｅｖｅｎｔｓ"が定義され、メディア行は次のとおりとなる：ｍ＝ａｐｐｌｉｃａｔｉｏｎ＜ｐｏｒｔ＞＜ｔｒａｎｓｐｏｒｔ＞ｃｏｎｔｒｏｌ−ｅｖｅｎｔｓ。
ＲＦＢ特定属性。
属性バージョン"ｖ＝"が付与される必要があり、それは、ＲＦＢプロトコルバージョン番号を示す。
ａ＝ｖ：＜ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ＞
ここで、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは"３．８"と成り得るが、それはＲＦＢプロトコルバージョン３．８が適応することを意味する。

クライアントは、サポートされる符号化タイプを優先順に並べたリストを規定してもよい。符号化タイプは、シンクライアントサーバーにより送信されたフレームバッファアップデートメッセージにおいて示されている。それは、通常のＲＦＢ規定"セットエンコーディング"メッセージにおいて、クライアントからサーバーに対して要求され得る。サーバーは、要求されれば、この示唆を使用してもよいし、しなくてもよく、ピクセルデータは、常にローエンコーディングの状態で送信されてもよい。

エンコーディングスキーム属性は、次の形式である：
ａ＝ｅｎｃｏｄｉｎｇ−ｓｃｈｅｍｅ：＜ｅｎｃｏｄｉｎｇ ｓｃｈｅｍｅ ｖａｌｕｅ＞
ここで、＜ｅｎｃｏｄｉｎｇ ｓｃｈｅｍｅ ｖａｌｕｅ＞は、"ＲＡＷ"、"ＣＯＰＹＲＥＣＴ"、"ＲＲＥ"、"ＨＥＸＴＩＬＥ"、 "ＺＬＲＥ"、"ＣＵＲＳＯＲ"、"ＣＯＲＲＥ"、"ＺＬＩＢ"、...である。

ディスプレイ番号も規定されてもよい。それが示唆されていない場合、初期ポートが割り当てられる。実際には、ＲＦＢサーバー初期ポート番号は、通常、（５９００＋ｄｉｓｐｌａｙ＿ｎｕｍｂｅｒ）に等しい。ここでｄｉｓｐｌａｙ＿ｎｕｍｂｅｒは、通常、０〜６の範囲にあり、結果として６つのディスプレイへの接続が可能である。

ディスプレイ属性は、次の形式となる：
ａ＝ｄｐｙ：＜ｄｉｓｐｌａｙ＿ｎｕｍｂｅｒ＞
ＲＦＢプロトコルの場合、次の追加属性が提供される。

クライアントは、セッションがシェアされているか否かを示唆する。示唆されていない場合、そのセッションはシェアされてはいけない。
ａ＝ｓｈａｒｅｄ
サーバーは、フレームバッファサイズを示唆しなければならない：
ａ＝ｆｒａｍｅｂｕｆｆ−ｗ：＜幅値＞
ａ＝ｆｒａｍｅｂｕｆｆ−ｈ：＜高さ値＞

クライアントは、参考用として次の属性を示唆してもよく、サーバーは、これらの属性を示唆しなければならない。
。ａ＝ｐｉｘｆｏｒｍａｔ−ｂｐｐ：＜ビット−パー−ピクセル値＞
。ａ＝ｄｅｐｔｈ：＜深さ値＞
。ａ＝ｂｉｇ−ｅｎｄｉａｎ
。ａ＝ｔｒｕｅ−ｃｏｌｏｒ
。ａ＝ｒｅｄ−ｍａｘ：＜レッド−最大値＞
。ａ＝ｇｒｅｅｎ−ｍａｘ：＜グリーン−最大値＞
。ａ＝ｂｌｕｅ−ｍａｘ：＜ブルー−最大値＞
。ａ＝ｒｅｄ−ｓｈｉｆｔ：＜レッド−シフト値＞
。ａ＝ｇｒｅｅｎ−ｓｈｉｆｔ：＜グリーン−シフト値＞
。ａ＝ｂｌｕｅ−ｓｈｉｆｔ：＜ブルー−シフト値＞

相互運用性のために、これまでの属性の理解に関するクライアント及びサーバーの挙動は、ハンドシェィキングメッセージ及びイニシャライゼーションメッセージがＳＤＰオファー／アンサーメッセージに置き換えられている点を除いて、ＲＦＢ仕様３．８に規定されているものと同じである。

ＴＣセマンテック。

ＴＣセマンテックを使用して一緒にグループ化された複数の"ｍ"行を含むセッション記述を受信するビューアーアプリケーションは、表示し、ＲＴＰ音声／ビデオストリームのような対応するメディアストリームに対して、リモートデスクトップ制御プロトコル（ＲＦＢ）を関連付けなければならない。
ａ＝ｇｒｏｕｐ：ＴＣ

そして、メディア−レベルの属性"ａ＝ｍｉｄ："は、一つのグループに属する各メディア行において用いられなければならない。

リモートディスプレイの適切なレンダリングのために、ＲＴＰストリーム（例えば、ビデオ転送）に対応する１又は複数のメディア行は、更に、リモートディスプレイフレームバッファ座標及びサイズに関するディスプレイロケーションを示唆する。この情報によって、シンクライアント装置は、リモートデスクトップフレームバッファ上のどこにＲＴＰビデオストリームをレンダリングすべきか、の位置を検知することができる。クライアントは、これにより、フレームバッファアップデートの方策を適応化することができる。特に、フレームバッファアップデートがクライアントドリブンであるＲＦＢの場合には、ポーリング間隔は、リモートデスクトップディスプレイのどの部分がアップデートされるべきかと同様に調整され得る。
ａ＝ａｒｅａ−ｘ：＜ｘ位置値＞
ａ＝ａｒｅａ−ｙ：＜ｙ位置値＞
ａ＝ａｒｅａ−ｗ：＜幅値＞
ａ＝ａｒｅａ−ｈ：＜高さ値＞

それは、ｗｉｎ−ｉｄ属性も示唆する。
ａ＝ｗｉｎ−ｉｄ：＜ウィンドウ 識別子＞
そのようなｗｉｎ−ｉｄは、リモートデスクトップ制御のためのユーザーセッション内においてユニークである必要がある。このｉｄの使用は、次のセクションにおいて更に説明される。

フレームバッファ上のウィンドウ仕様管理のためのＲＦＢプロトコル拡張機能。

ＲＦＢグラフィカルアップデートの方策は、クライアントドリブンのスクリーンアップデートである。ＲＦＢ仕様３．８において、クライアントは、バンド幅を節約するために、全スクリーンのうちの部分アップデートをリクエストできる。

フレームバッファアップデートに加えて、ビデオトラフィックの結合を導入することで、クライアントは、スクリーンの所定部分へのビデオを受信して、マッピングすることができる。

例えば、携帯電話のような限られたスクリーンデバイスにおいては、クライアントは、全モバイルデバイススクリーンに適合するようにビデオバッファのサイズ変更することを決定してもよい。このような場合、クライアントは、ＲＦＢフレームバッファアップデートメッセージ用に用いられるフレームバッファリフレシュを停止する。我々は、この仕様のフレームバッファを"デスクトップフレームバッファ"（デスクトップ ＦＢ）と呼ぶ。

他の予見される使用態様では、クライアントは、所定のウィンドウにて開かれたメディアプレーヤーのグラフィカルアップデートを受信する。次に、クライアントは、そのデバイス上のリモートデスクトップフレームバッファ最上部でローカルに、ビデオを自由に移動させるかもしれない。そのプレーヤーは、ユーザーリクエストに応じて、表示されたり、隠されたりするかもしれない。この状態における問題は、ウィンドウの動きは、適切なレンダリング及びスクリーンディスプレイ管理のために、サーバーに対して示唆される必要があるかもしれないということであり、より端的には、複数のユーザーによってデスクトップがシェアされている場合である。例えば、第１ユーザーに起因するアクションを他の参加者が単に見ている間は、第１ユーザーは、デスクトップを制御してもよい。

実際に、ＲＴＰビデオストリームは、受信され、異なるフレームバッファ上にてハンドリングされる。ビデオメディアをリモートデスクトップ機能に関連づける機能を導入し、かつｗｉｎ−ｉｄ情報を追加することで、クライアントは、同じユーザーセッションに関連付けられている間は、そのスクリーン上においてレンダリングされるビデオメディアを自由にハンドルすることができる（回転、フルスクリーンモードへの切り替え、等）。Ｗｉｎ−ｉｄは、必ずしも、ウィンドウに関するものである必要はなく、グラフィカルエリアを示すものであっても良い。しかしながら、実際には、ウィンドウを活用し、それを実行することの方がより容易であり、ウィンドウがサイズ変更又は移動されるような場合は特にそうである。２つの新しいクライアントリクエストが次に定義される：

フレームバッファフォーゲットリクエスト（メッセージ−タイプ、ウィンドウ−ｉｄ、ｘ−位置、ｙ−位置、幅、高さ）は、フレームバッファの特定エリアがアップデートを要しないことをサーバーに対して伝達する。これは、このエリアが他のメディアストリーム（例えば、ＲＴＰ上を転送され、Ｈ２６３エンコードされたビデオ）によって更新される場合には起こるだろう。

ウィンドウアップデート（メッセージ−タイプ、ウィンドウ−ｉｄ、ｘ−位置、ｙ−位置、幅、高さ）は、サーバー上に開かれたウィンドウ（またはグラフィカルエリア）に対応する受信メディアストリームが、サイズ変更された、移動された、又は両方が行われたことを、サーバーに伝達する。

ウィンドウ−ｉｄが存在しない場合、つまり、ウィンドウに対応する独立したメディアストリームが受信されていない場合、これらのクライアントリクエストは使用されてはならない。

これは、受信されたメディアストリームがサーバー上のウィンドウに適合するか否かを示すために、属性"ａ＝ｗｉｎ−ｉｄ"を送信することをサーバーに要求する。そうでなければ、ｗｉｎ−ｉｄ属性は、ゼロにセットされる。そしてその属性が存在しない場合は、クライアントは、メディアストリームにウィンドウを関連づけてはならない。

リモートサーバー上のどのウィンドウともメディアストリームが関連していない場合、クライアントはフレームバッファ上でメディアをサイズ変更又は移動してはならない。そしてウィンドウアップデートは使用されてはならない。しかしながら、ポールモデル（又は、クライアントドリブンのフレームバッファアップデート）においては、クライアントは、サーバーに対してリクエストで特定されたエリアをアップデートしないよう知らせるために、フレームバッファフォーゲットリクエストメッセージを使用してもよい。しかしながら、プッシュモデルにおいては、これは、要求されなくともよい。なぜなら、サーバーは、別のプロトコル及びエンコーディングを使用してこのエリアがアップデートされることを既に知っているはずであるからである。

リモートサーバー上のウィンドウにメディアストリームが関連している場合、上述のクライアントリクエスト（フレームバッファフォーゲットリクエスト及びウィンドウアップデート）は、リモートサーバー上のウィンドウの位置をアップデートするために用いられる。フレームバッファフォーゲットリクエストにおけるウィンドウ−ｉｄ情報によって、クライアントは、サーバーによりフレームバッファアップデートが送信されることがないようにするためのエリアの示唆を、修正することが可能となる。

図２は、動的に適応化可能な複数のエリアから成るリモートアプリケーション表示（リモートデスクトップ）をレンダリングする、シンクライアントビューアーを示す。エリアＡは、ＲＦＢプロトコルに基づいて画像がアップデートされる、リモートデスクトップの背景である。その余のエリアは、エリアＡに依存し、例えば、エリアＢが描かれている。

エリアＢは、エリアＡ（Ｘ，Ｙ基準の座標）に対して相対的な位置（ｘ，ｙ）に配置されたスクリーンのエリアである。それは、幅（ｗ）及び高さ（ｈ）の寸法によっても特徴づけられる。画像出力は、リアルタイムプロトコル（ＲＴＰ）上でストリームされ、例えば、Ｈ２６３コーデックを使用し符号化される。

従って、エリアＢ上のどのユーザーインタラクションも、リモートデスクトップ（背景）に関連付けられ、エリアＢからのポインターイベントは、あたかもそれらがエリアＡ上において実行されているかのように、リモートサーバーに送信され得る。これは、サーバーにおけるウィンドウのサイズ変更及び移動を必ず引き起こさずとも、シンクライアント装置のスクリーン上において、エリアＢがローカルにサイズ変更又は移動される場合に使用され得る。

図３は、シンクライアント装置として動作するＵＥ２とシンクライアントサーバー４として動作するリモートデスクトップＰＣ間のシンクライアントコネクションの確立を示す。

ＵＥ２は、通信のためのＩＰアクセスネットワークを介してリモートデスクトップＰＣ４と接続し、グラフィクス符号化スキーム、転送設定（ＲＦＢ（リモートフレームバッファ）、ＲＤＰ（リモートデスクトッププロトコル）、ＩＣＡ（独立コンピューティングアーキテクチャープロトコル）、又はピクセル／ＲＴＰ（リアル−タイム転送プロトコル）、ＩＰアドレス及びポート番号及び無線ベアラセッティング（パケット交換または回線交換接続））を含むシンクライアントパラメーターを有するＳＤＰオファー／アンサーを開始する。

ステップ２０では、ＵＥ２は、シンクライアントセッション属性及びＳＩＰセッションの適切な確立に要求される更なるパラメーターを含むＳＤＰオファーを、デスクトップ４に発信する。

前記のＳＤＰオファーを受信すると、デスクトップ４は、ＵＥ２がＲＦＢプロトコルを使用してシンクライアントコネクションを確立することを希望していると判断し、ＵＥ２が配置されている環境に基づいて、ＲＦＢプロトコル及び提案された属性を受け入れることができることを判断し、ステップ２２で、ＲＦＢ及び属性が選択されたことを示すＳＤＰアンサーメッセージを返信する

ＵＥ２及びデスクトップ４は、グラフィカルアップデート及びイベントの転送のための仕様について同意する。加えて、それらは、シンクライアントコネクションがそれらの間で進行中のセッションに適することを識別する。

シンクライアントパラメーターが両者間で合意された後、デスクトップ４は、ステップ２４で、ＵＥ２に対してグラフィカルアップデートメッセージを送信し、他方、ＵＥ２は、ステップ２６で、アップリンクキー及びポインターイベントをデスクトップ４に送信する。

デスクトップ４は、ＩＥＴＦ ＲＦＣ３２６４に規定されているように、コネクションを拒否してもよく、それに関して、グラフィック又はイベントストリームに対応するポート番号をゼロに設定することができる。

幾つかのシンクライアントパラメーターがデスクトップ４によって知られていない場合、ＩＥＴＦ ＲＦＣ４５６６に規定されているように、後者は、沈黙して、そのようなパラメーターを無視する。

ステップ２８では、ＵＥ２とデスクトップ４は、ＲＦＢメディア及びイベントを交換する。

ステップ３０では、ユーザーは、ビデオを見るためにメディアプレーヤーを起動し、デスクトップ４は、２番目のＳＤＰオファーを送信する。ＵＥ２はそのＳＤＰオファーを受け入れるかもしれないし、又は受け入れないかもしれない。実際には、デスクトップ４は、例えば、ＲＴＰ上でビデオ送信することを望み、ネゴシエーションが、ビデオパラメーター情報を含む新しいＳＤＰオファーにより引き起こされる。ビデオ出力は、デスクトップメディアプレイヤーアプリケーションによって生成されるため、シンクライアントセッション識別子及び画像位置情報が与えられ、ＵＥ２は、正しい位置でビデオストリームを表示することができる。従って、ビデオストリームは、進行中のシンクライアントセッションに一体化される。

ステップ３２で、ＵＥ２は、オファーを認識し、アンサーを返信する。デスクトップ４は、ディスプレイアップデートを適応化し、これにより、ビデオがストリームされている領域は、シンクライアントプロトコルを介してアップデートされない。

図４は、アプリケーションディスプレイリダイレクションにおける例示的な実施形態による方法の利用を示す。

一例として、この状態は、ユーザーが、自身がモバイルＵＥ２で受信するビデオを、例えば、セット−トップ−ボックス又は他のバック−エンドＳＩＰサーバーといったサーバーにおいてＳＩＰ−接続され、その公開アドレスを介して到達可能であるＴＶ４０へリダイレクトすることを決定したときに、発生するかもしれない。

この場合、ステップ４２において、ＵＥ２は、リモートデスクトップＰＣ４と通信するためにＩＰアクセスネットワークを介して、リモートデスクトップ４に接続される。これは、図３のステップ２０、２２、２４、２６、及び２８にも関連する。

ＵＥ２は、キー及びマウスイベントを送信することでデスクトップと相互作用する。ある時間的瞬間に、ユーザーは、メディアプレーヤーを起動し、ビデオを再生することを決定する。

ステップ４４では、デスクトップ４は、ビデオのストリーミングを可能とするためにＳＤＰオファー／アンサーを送信する。この決定は、ローカルサーバーインターフェイスの実行に基づくことはもちろん、ローカルポリシー及び知識に基づく。第１実施形態では、サーバーによりホストされたアプリケーションが、シンクライアントサーバーモジュールに対して特定のメディア転送手段を要求することを意味する（我々は、このアプリケーションを、メディア転送目覚ましアダプテーションと呼ぶ）。第２実施形態では、シンクライアントサーバーモジュールが最も適切な転送手段を自律的に選択することを示す。

このリクエストを受信すると、ＵＥ２は、ステップ４６において、このビデオストリームを了解又は拒否するためのアンサーを返信する。この典型的な例として、ＵＥ２は、リダイレクト機能をサポートしている。ユーザーは、ＵＥ２のユーザーインターフェイスを介して、リダイレクトオプションを選択し、ＴＶ４０にビデオをリダイレクトすることを選択する。モバイルフォンは、ＴＶ ＳＩＰ公開アドレス又はＩＰアドレスを知っているものとする。これは、シンクライアント装置が、メディアフローを受け入れるか又はそれを別の装置にダイレクトするかどうかをユーザーに知らせるための、ユーザーインターフェイスを提供することを意味する。アンサーメッセージは、ＴＶのアドレス及びアプリケーションＩＤを含み、それらのために、リダイレクトが、ウェブブラウザ表示等をリダイレクトするように要求される。

この場合、リダイレクトは、アプリケーション（これは、ウェブブラウザ、インスタントメッセージアプリケーション、ビデオかもしれない）のディスプレイリダイレクトを意味する。

デスクトップ４は、このメッセージを受信し、このメッセージを解読し、メディアをＴＶ４０へリダイレクトする準備をする。ビデオ出力が位置しているエリアに対応するスクリーンアップデートは、ＵＥ２へ送信されない。これは、出力ストリームがまだモバイル装置に対してストリームされているか否かに関する示唆を含むことを、アンサーメッセージに要求する。

もしＳＩＰがサポートされていれば、メディアネゴシエーションは、ＳＩＰを介してＴＶ４０と続けられる。デスクトップ４は、他の手段を介して、ビデオ転送をネゴシエートすることも可能である。

ステップ４８で、デスクトップ４は、ＳＤＰオファーをＴＶ４０に対して送信する。

ステップ５０で、ＳＤＰオファーはＴＶによって受け入れられ、ＴＶはＳＤＰアンサーを返信する。

ステップ５２で、ＵＥ２は、ＴＶ４０がリダイレクトを受け入れたことを知らされる。

最後に、ステップ５４で、ＴＶスクリーン４０にビデオが表示される。ユーザーは、リモートデスクトップ制御手段を用いて、リモートデスクトップ４と交信することを継続してもよい。

上述の例では、ＴＶ４０は、例えばセット−トップ−ボックス又は他のバック−エンドＳＩＰサーバーといった、サーバーに対してＳＩＰ−接続されていることが好ましい。それは、その公開アドレスを介して到達可能である。

本願発明は、その例示的な実施形態を参照して、端的に開示され説明されてきたが、本願発明は、これらの実施形態に限られるものではない。請求項により定義された本願発明の精神及び範囲から逸脱することなく、当業者をすれば、形式及び細部の様々な変形が理解されるだろう。

＜参照の組み込み＞
本願発明は、２００８年１０月８日に出願されたヨーロッパ特許出願ＮＯ．ＥＰ０８１６６１２２．５に基づき、かつそれからの優先権の利益を主張し、ここに、その開示の全てが参照として組み込まれる。

２ モバイルユーザー装置
４ シンクライアントサーバー
６ ＩＭＳコアシステム
８ ポリシー決定機能モジュール（ＰＤＦ）
１０ ３ＧＰＰ パケット交換（ＰＳ）コアネットワーク
４０ ＴＶ

Claims (15)

1. ＳＩＰベースフレームワーク上のセッションネゴシエーション中にハンドシェイキング及びイニシャライゼーションメッセージを交換する、シンクライアント装置とシンクライアントサーバーとの間のシンクライアントセッションの確立方法であって、
   前記シンクライアントサーバーから前記シンクライアント装置に、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰ（セッション記述プロトコル）のオファーメッセージ又はＸＭＬベースのオファーメッセージ、及び追加情報であるビデオパラメータ情報を送信し、前記シンクライアント装置から前記シンクライアントサーバーに、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰのアンサーメッセージ又はＸＭＬベースのアンサーメッセージを送信し、前記シンクライアントサーバーから前記シンクライアント装置へのメディアストリームの転送を可能とする。
2. 請求項１に記載の方法であって、
   前記シンクライアント装置から前記シンクライアントサーバーに送信される、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰのアンサーメッセージ又はＸＭＬベースのアンサーメッセージは、マルチメディア転送及びリモートデスクトップ制御を機能させるための情報を含む。
3. 請求項２に記載の方法であって、
   前記リモートデスクトップ制御は、前記シンクライアント装置から他のデバイスへのリモートアプリケーションのグラフィカルなアップデートを動的にダイレクト又はリダイレクトすることを備える。
4. 請求項３に記載の方法であって、
   前記シンクライアント装置は、モバイル通信装置であり、前記他のデバイスは、固定された通信装置である。
5. 請求項４に記載の方法であって、
   ダウンリンクグラフィカルアップデートに用いられるものとは異なる別の無線ベアラ上でアップリンクイベントを転送することを備える。
6. 請求項５に記載の方法であって、
   ダウンリンクグラフィカルアップデートに用いられるものとは異なる別のＩＰ接続上でアップリンクイベントを転送することを備える。
7. 請求項１に記載の方法であって、
   前記シンクライアントセッションに対して少なくとも一つの音声／ビデオストリームを関連づけることを備える。
8. 請求項７に記載の方法であって、
   前記追加情報は、前記シンクライアントセッションに対して関連付けられた前記音声／ビデオストリームに対応するリモートディスプレイフレームバッファ座標及びサイズを備える。
9. 請求項８に記載の方法であって、
   前記シンクライアント装置から前記シンクライアントサーバーに送信される、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰのアンサーメッセージ又はＸＭＬベースのアンサーメッセージは、フレームバッファ上の特定領域はアップデートを要しないことを前記シンクライアントサーバーに対して指示するクライアントリクエスト（フレームバッファフォーゲットリクエスト）を含む。
10. 請求項９に記載の方法であって、
    前記追加情報は、ウィンドウＩＤ属性を備える。
11. 請求項１０に記載の方法であって、
    前記シンクライアント装置から前記シンクライアントサーバーに送信される、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰのアンサーメッセージ又はＸＭＬベースのアンサーメッセージは、前記ウィンドウＩＤ属性によって特定されるグラフィカル領域がサイズ変更、移動又は両方がなされたことを前記シンクライアントサーバーに対して指示するクライアントリクエスト（ウィンドウアップデート）を含む。
12. シンクライアントサーバーとのシンクライアントセッションを確立するための請求項１に記載の方法を実行するためのシンクライアント装置であって、
    ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰ（セッション記述プロトコル）のオファーメッセージ又はＸＭＬベースのオファーメッセージ及び追加情報であるビデオパラメータ情報を前記シンクライアントサーバーから受信し、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰのアンサーメッセージ又はＸＭＬベースのアンサーメッセージを前記シンクライアントサーバーに送信し、前記シンクライアントサーバーからのメディアストリームを受信する手段を備える。
13. 請求項１２に記載のシンクライアント装置であって、
    メディアリダイレクトの受信の通知を受けるために、及びリダイレクトアンサーを送信するために、メディアリダイレクトに関する意向をユーザーが登録することを可能とするインターフェイスを備えるモバイルユーザー装置を備える。
14. 請求項１２に記載のシンクライアント装置は、
    アップリンクイベントのために異なるＩＰ接続を確立するために、異なる無線ベアラの配置を引き起こし、ダウンリンクグラフィカルアップデートのために使用されるものとは異なる別の無線ベアラにおいて、前記アップリンクイベントを転送し、
    且つ、そのスクリーンに関するリモートディスプレイフレームバッファに音声／ビデオストリームのレンダリングをマッピングする。
15. シンクライアント装置とシンクライアントセッションを確立するための請求項１に記載の方法を実行するために適応されるシンクライアントサーバーであって、
    ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰ（セッション記述プロトコル）のオファーメッセージ又はＸＭＬベースのオファーメッセージ及び追加情報であるビデオパラメータ情報を前記シンクライアント装置に送信し、ＳＩＰメッセージのボディーに埋め込まれた、ＳＤＰのアンサーメッセージ又はＸＭＬベースのアンサーメッセージを前記シンクライアント装置から受信し、前記シンクライアント装置にメディアストリームを転送する手段を備える。

Images