マルチメディアデータを含むイベントを転送する方法およびシステム
【課題】 イベントを、サーバからリモートクライアントに転送する方法（７００）およびシステム（１１０、１２０）を提供する。
【解決手段】 イベントがドライバから受け取られる（７１０）。イベントは、イベントタイプに従ってイベントキューに送られる（７２０）。イベントは、イベントタイプに従って処理される（７３０）。処理は、イベントがマルチメディアデータを含む場合、イベントをエンコードすることを含む。イベントは、トリガされると、リモートクライアントに転送される（７４０）。転送は、イベントタイプに対応するプロトコルに従って行われる。
【解決手段】 イベントがドライバから受け取られる（７１０）。イベントは、イベントタイプに従ってイベントキューに送られる（７２０）。イベントは、イベントタイプに従って処理される（７３０）。処理は、イベントがマルチメディアデータを含む場合、イベントをエンコードすることを含む。イベントは、トリガされると、リモートクライアントに転送される（７４０）。転送は、イベントタイプに対応するプロトコルに従って行われる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、コンピュータシステムネットワークに関する。
より詳細には、本発明の実施形態は、ネットワーク環境におけるマルチメディアストリーミングに関する。
【背景技術】
【０００２】
コンピュータシステムネットワークは、リモートクライアント装置からのローカル資源（たとえば、サーバ上のソフトウェアアプリケーション、データ、ウェブページ等）へのアクセスを提供する。
仮想ネットワークコンピューティング等のアプリケーションは、この概念をさらに拡張した。
仮想コンピューティングネットワークでは、サーバは、ソフトウェアアプリケーションおよびデータのみならず、クライアント装置からアクセスし制御することが可能なデスクトップ環境をも供給する。
本質的には、クライアント装置のユーザに、サーバにおいて生成され、次いでクライアントに転送されて再現された表示（グラフィカルユーザインタフェースまたはデスクトップ）が提示される。
したがって、クライアントが維持する状態量を削減することができ、「薄い」クライアントと呼ばれるものになる。
また、単一のデスクトップを、いくつかの異なるクライアントから同時にアクセスして見ることができる。
これは、一群の協同工学ワークステーションを実施する場合に特に有用であり得る。
【０００３】
従来技術による仮想ネットワークコンピューティングシステムは、通常、リモートフレームバッファ（ＲＦＢ）プロトコル等のプロトコルを使用して、サーバ生成のグラフィカルユーザインタフェースへのクライアントアクセスを提供する。
コンピュータシステムのモニタに表示する画像は、サーバ上のフレームバッファに保持される。
極端な場合、フレームバッファの内容全体が、周期的にクライアント装置に転送され、表示される。
この極端な場合に対する改良策には、前の転送以来、フレームバッファ（ひいては表示）に対して行われた変更のみを送信することが含まれる。
【０００４】
通常、クライアントへの転送速度は、毎秒約１０〜１５フレームである。
この速度はかなり高いが、ビデオデータまたはマルチメディアデータ（ビデオデータおよびオーディオデータ）をサーバからクライアントに満足のいくように転送するには不十分であるとみなされる。
したがって、従来技術によるシステムはこの点で制限される。
【０００５】
したがって、ビデオ／マルチメディアデータをサーバからクライアントに仮想ネットワークコンピューティングシステムにおいて転送するより満足のいく方法が望ましい。
本発明の実施形態は、このような改良を提供する。
【特許文献１】米国特許第６１６６７３４号
【特許文献２】国際公開第００／３９６７８号
【特許文献３】米国特許第６２５９４４３号
【非特許文献１】CHIA-CHEN KUO ET AL: "Design and implementation of a network application architecture for thin clients" PROCEEDINGS OF THE 26TH. ANNUAL INTERNATIONAL COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE. COMPSAC 2002. OXFORD, ENGLAND, AUG. 26 - 29, 2002, ANNUAL INTERNATIONAL COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE, LOS ALAMITOS, CA: IEEE COMP. SOC, US, vol. CONF. 26, 26 August 2002 (2002-08-26), pages 193-198, XP010611116 ISBN: 0-7695-1727-7 the whole document
【発明の開示】
【課題を解決するための手段】
【０００６】
［発明の開示］
本発明の実施形態は、イベントをサーバからリモートクライアントに転送する方法およびシステムに関する。
イベントがドライバから受け取られる。
イベントは、イベントタイプに従ってイベントキューに送られる。
イベントは、イベントタイプに従って処理される。
処理は、イベントがマルチメディアデータを含む場合、イベントをエンコードすることを含む。
イベントは、トリガされると、リモートクライアントに転送される。
転送は、イベントタイプに対応するプロトコルに従って行われる。
【０００７】
本明細書において援用され、かつ本明細書の一部を構成する添付の図面は、本発明の実施形態を例示しており、その記述とともに、本発明の原理を説明するのに有用である。
【０００８】
本明細書において参照される図面は、具体的に述べられる場合を除いて、縮尺どおりに描かれているものと理解されるべきではない。
【発明を実施するための最良の形態】
【０００９】
ここで本発明の種々の実施形態が詳細に参照されることになり、その数々の例が添付の図面に示される。
本発明はこれらの実施形態とともに説明されることになるが、本発明をこれらの実施形態に限定することは意図していないことは理解されよう。
それどころか、本発明は、添付の特許請求の範囲によって規定されるような、本発明の精神および範囲内に含まれる場合がある、代替形態、変更形態および同等形態を網羅することが意図されている。
さらに、本発明の以下の説明では、本発明を完全に理解してもらうために、数多くの具体的な細部が述べられる。
他の事例では、既知の方法、手順、構成要素および回路は、本発明の態様を不必要に曖昧にしないように詳細には説明されていない。
【００１０】
図１は、本発明の一実施形態による、ネットワーク１００に結合されたサーバ１０１およびクライアント１０２のブロック図である。
ネットワーク１００は図示の要素以外の要素も含み得ることが理解される。
ネットワーク１００はまた、図示の様々な要素を２つ以上含むことができ、たとえば、サーバ１０１に複数のクライアントが結合されてもよく、複数のサーバがあってもよい。
サーバ１０１およびクライアント１０２の機能については以下に考察（少なくとも図２および図６を参照して）するが、これら要素は考察する機能以外の機能も実施し得ることが理解される。
【００１１】
通信は、図１のサーバ１０１とクライアント１０２の間で直接行われる場合もあり、または中間装置もしくはノード（図示せず）を通して間接的に行われる場合もある。
また、通信は有線であっても、または無線であってもよく、または有線と無線の組み合わせであってもよい。
一実施形態では、通信はワールドワイドウェブ（すなわちインターネット）を介して行われる。
【００１２】
一実施形態では、サーバ１０１およびクライアント１０２は、処理能力およびメモリ能力を提供するコンピュータシステムである。
さらに、本発明の実施形態によれば、サーバ１０１はデスクトップストリーミングサーバ１１０を実装し、クライアント１０２はデスクトップストリーミングクライアント１２０を実装する。
この実施形態では、デスクトップストリーミングサーバ１１０およびデスクトップストリーミングクライアント１２０は、サーバ１０１が表示（たとえば、グラフィカルユーザインタフェース、特に「デスクトップ」表示）をクライアント１０２に供給できるようにする。
分かるように、サーバ側制御およびクライアント側制御の両方が、同時に、または排他的に可能である。
【００１３】
本発明の実施形態によれば、「イベント」は、デスクトップストリーミングサーバ１１０およびデスクトップストリーミングクライアント１２０を使用して、サーバ１０１からクライアント１０２に、またこの逆にそれぞれ転送される。
本明細書において使用するイベントは一般に、キーボードドライバ、マウスドライバ、ビデオドライバ、またはオーディオドライバ等のソフトウェアドライバの出力である。
したがって、イベントとしては、マウスボタンのクリックやキーボードのキーの押下等の検出可能なアクションまたは発生が挙げられる。
イベントは、クライアント１０２が表示する表示（グラフィカルユーザインタフェース）を変更させ得るアクションまたは発生を指すこともできる。
たとえば、テキスト（文書処理中の）文書をスクロールすることにより、または文書の或るページを別のページに変更することにより生じる表示の変更がイベントを構成し得る。
表示中のウィンドウが移動することもイベントを構成し得る。
ビデオ動画表示もイベントを構成し得る。
オーディオサンプルもイベントを構成し得る。
【００１４】
まとめると、本明細書において使用するイベントは、サーバ１０１またはクライアント１０２が使用するドライバの出力であり、サーバ１０１またはクライアント１０２上の表示を変更させる可能性があり、かつ／またはクライアント１０２にオーディオ出力を発生させ得る。
イベントは一般に、制御イベントおよびデータイベントに分類することができる。
制御イベントは、他の構成要素の実行の振る舞いをローカルに、またはリモートに変更させる制御情報を伝える。
データイベントは、他の構成要素に内容の変更を通知する内容データを伝える。
【００１５】
考察を簡単にするために、「マウス」という用語を本明細書において用いるが、マウスに代えて、またはマウスと併せて、他のカーソル制御手段を使用し得ることが理解される。
無数のカーソル制御機構が当該技術分野において既知であり、これらのそれぞれを本発明により使用し得る。
「キーボード」という用語も本明細書において用いられる。
この場合でも、音声認識システムを含め、キーボードの機能を提供する無数の機構が、当該技術分野において既知であり、これらのそれぞれを本発明により使用し得る。
したがって、本発明の実施形態はマウスおよびキーボードの場合について説明するが、本発明はそのように限定されるものではない。
むしろ、上述したように、「イベント」という用語およびこの用語が本明細書においてどのように用いられるかに集中すべきである。
この文脈の中では、キーボードおよびマウスのイベントはイベントの単なる例にすぎず、本発明の実施形態は、略すべてのタイプのイベントとの併用に適している。
【００１６】
一実施形態では、サーバ側において、ドライバから受け取ったイベントが、イベントタイプに従ってイベントキューに送られる。
次いで、イベントはそれぞれのイベントタイプに従って処理され、たとえば、マルチメディアイベントをエンコードすることができる。
次いで、イベントは、イベントタイプに対応するプロトコルに従ってサーバ１０１からクライアント１０２に転送される。
一実施形態では、キーボードドライバおよびマウスドライバからのイベントは、伝送制御プロトコル（ＴＣＰ）等のプロトコルを使用してクライアント１０２に転送されるが、ビデオドライバおよびオーディオドライバからのイベントは、リアルタイムプロトコル（ＲＴＰ）等のプロトコルを使用してクライアント１０２に転送される。
これらプロセスについて、図２と併せてさらに詳細に以下説明する。
【００１７】
ＴＣＰおよびＲＴＰは当該技術分野において既知である。
ＴＣＰは、信頼性の高いプロトコルを提供し、ＲＴＰは、マルチメディアデータオブジェクトのビデオ部分およびオーディオ部分を同期させるのに有用なタイミング機能を提供する。
したがって、ＴＣＰは、制御イベント（たとえば、キーボードイベントおよびマウスイベント）、ならびにグラフィックスアプリケーションの変更等、他の高い正確性が要求されるイベントを正確に転送するために使用することができ、ＲＴＰは、フレームバッファ（ビデオバッファ）およびサウンドバッファの更新をストリーミングするために使用することができる。
これらまたは同様の機能を提供することができる他のプロトコルも、代わりに使用することが可能である。
【００１８】
クライアント側においては、一実施形態では、イベントは、キーボードドライバおよびマウスドライバから受け取られ、ＴＣＰ等のプロトコルを使用して図１のサーバ１０１に転送される。
このプロセスについては、図６と併せてさらに以下説明する。
本実施形態では、サーバ１０１とクライアント１０２の間の関係には、クライアントがオーディオドライバおよびビデオドライバからイベントをサーバに送ることがないが、本発明はそのように限定されるものではない。
【００１９】
図２は、本発明の一実施形態によるデスクトップストリーミングサーバ１１０のブロック図である。
デスクトップストリーミングサーバ１１０は、図１のサーバ１０１に、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせとして実装される。
図２に示すように、デスクトップストリーミングサーバ１１０は、説明および考察を明確にするために別個に表される複数の要素を備えるが、これら要素はデスクトップストリーミングサーバ１１０内の別個のエンティティとして存在しなくてもよいことが理解される。
一般に、本発明の各種実施形態によれば、デスクトップストリーミングサーバ１１０は、図２の各種要素によって提供される能力および機能を提供する。
さらに、デスクトップストリーミングサーバ１１０は、本明細書に述べる能力および機能に加えて他の能力および機能を提供し得る。
【００２０】
本実施形態では、ドライバインタフェース２１０が、キーボードドライバ２０１、マウスドライバ２０２、ビデオドライバ２０３、および／またはオーディオドライバ２０４等であるがこれらに限定されない複数のドライバから入力（イベント）を受け取る。
したがって、ウィンドウ変更、キーボード入力、およびカーソル移動等のより従来的なイベントをインターセプトすることに加えて、ドライバインタフェース２１０はまた、ビデオドライバ２０３からビデオデータを、またオーディオドライバ２０４からオーディオデータをサンプリングする。
【００２１】
一般に、ドライバ２０１〜２０４は、土台をなすオペレーティングシステムの構成要素である。
たとえば、Ｗｉｎｄｏｗｓ（登録商標）環境のキーボードドライバは、Ｌｉｎｕｘ環境のキーボードドライバと異なり得る。
本実施形態によれば、ドライバインタフェース２１０は、デスクトップストリーミングサーバ１１０の下流部分への固定インタフェース（たとえば、イベントフィルタ２２０への固定インタフェース）を提供しながら、各種タイプのドライバと通信する能力を提供する。
【００２２】
図３は、本発明の一実施形態によるドライバインタフェース２１０のブロック図である。
この実施形態では、ドライバインタフェース２１０は、各ドライバとのインタフェースに適したモジュールがあるように、インタフェース３０１および３０２により具現される複数のインタフェースモジュールを備える。
これは、１つのドライバにつき１つのインタフェースモジュールがあると言っているわけではないが、その場合もあり得る。
【００２３】
本実施形態では、ドライバインタフェース２１０は、インタフェース３０１および３０２等に共通のアプリケーションプログラムインタフェース（ＡＰＩ）３０５も備える。
ＡＰＩ３０５は、無数のドライバが可能であるにも拘わらず、デスクトップストリーミングサーバ１１０の残りの部分に単一のインタフェースを提供し、したがって、デスクトップストリーミングサーバ１１０を、土台をなすオペレーティングシステムから切り離す。
【００２４】
図２に戻ると、本実施形態では、ドライバインタフェース２１０からのイベントはイベントフィルタ２２０に提供される（受け取られる）。
この実施形態では、イベントフィルタ２２０は、イベントタイプに従ってイベントを識別し、イベントをイベントタイプに従って各イベントキューに送る。
イベントキューは、イベントタイプに適した処理（もしあれば）の後、イベントタイプに適したプロトコル（たとえば、ＴＣＰまたはＲＴＰ）を使用してデスクトップストリーミングクライアント１２０（図１）に転送することができる同様のタイプのイベントをバッファリングするために使用される。
【００２５】
本実施形態では、図２のイベントフィルタ２２０は、イベントを以下のタイプに分類する。
すなわち、１）たとえばキーボード入力またはカーソル（たとえば、マウス）移動によって生成される制御イベント、２）ウィンドウの内容に変更がない、ウィンドウ移動によって生成されるウィンドウ移動イベント、３）ウィンドウ内容の変更によって生成されるウィンドウ更新、４）オーディオドライバ２０４のサウンドバッファの変更から取り込まれるオーディオサンプル。
この実施形態では、制御イベントは制御イベントキュー２３１に転送され、ウィンドウ移動はウィンドウ移動キュー２３２に転送され、ウィンドウ更新はウィンドウ更新キュー２３３に転送され、オーディオサンプルはオーディオサンプルキュー２３４に転送される。
【００２６】
本実施形態では、制御イベントキュー２３１内の制御イベントは、マウスまたはカーソルの座標変更を記録する。
たとえば、特定のカーソル移動の場合、移動の開始座標および終了座標のみを図１のデスクトップストリーミングクライアント１２０に転送するだけでよい。
制御イベントは、デスクトップストリーミングエンジン２５０によってさらに最適化することができる。
【００２７】
引き続き図２を参照すると、本実施形態では、ウィンドウ移動キュー２３２は、移動中のウィンドウの座標変更を（ウィンドウの内容は変更せずに）記録する。
ウィンドウの内容がすでに図１のデスクトップストリーミングクライアント１２０に転送されている場合、ウィンドウの座標の変更のみをクライアントに転送するだけでよい。
次いで、クライアントは、すでに受け取っていたウィンドウの内容および新しいウィンドウ座標を使用してデスクトップ表示を表現することができる。
【００２８】
本実施形態によれば、図２のウィンドウ更新キュー２３３は、ウィンドウ内容の更新を記録する。
これら更新は、ビデオフレームバッファから取り込むことができる。
一実施形態では、適切なエンコーダおよび転送プロトコルの選択に役立つように、ウィンドウ更新は３つのタイプに分類される。
すなわち、１）グラフィックスウィンドウ更新、２）ビデオウィンドウ更新、および３）他のウィンドウ更新。
ここで、グラフィックスは相対的に静的な画像（たとえば、ビデオと比較して相対的に低い更新率を有する画像）を指すために使用され、ビデオは相対的に高い更新率を有する動画を指し、他のウィンドウ更新は、文書処理中の文書内のテキスト等、相対的に静的なウィンドウ内容を指す。
概して、ウィンドウ更新は、画像の複雑性および更新頻度に従って分類に分けることができる。
【００２９】
図４は、本発明の一実施形態によるウィンドウ更新の分化を示すブロック図である。
この実施形態では、ウィンドウ更新分化器４１０が、ウィンドウを上記カテゴリにフィルタリングする。
ウィンドウ更新分化器４１０は、表示アプリケーションタイプ、ならびにウィンドウの座標および画面サイズ等の情報を用いてこれを実現することができる。
表示アプリケーションタイプは、たとえば、新しいウィンドウが作成されたとき、ウェブサイトのユニフォームリソースロケータ（ＵＲＬ）がクリックされたとき、またはアプリケーションが実行されたときにドライバインタフェース２１０（図２）から得ることができる。
座標および画面サイズは、ビデオフレームバッファへの更新のどの部分がどのウィンドウに属するかを見つけるのに役立つ。
【００３０】
グラフィックスウィンドウ更新はグラフィックスウィンドウ更新キュー４２１に転送され、ビデオウィンドウ更新はビデオウィンドウ更新キュー４２２に転送され、他のウィンドウ更新は他のウィンドウ更新キュー４２３に転送される。
【００３１】
図２に戻ると、本実施形態では、イベントの各キュー２３１〜２３４からデスクトップストリーミングエンジン２５０への転送は、各レギュレータ２４１、２４２、２４３、および２４４によってトリガされる。
同様に、図４の実施形態では、キュー４２１〜４２３は各レギュレータ４３１、４３２、および４３３の制御下にある。
【００３２】
一実施形態では、図２のレギュレータ２４１〜２４４（および図４のレギュレータ４３１〜４３３）は、しきい値に達したこと、または或る時間間隔が経過したことに基づいて、それぞれの各キューからイベントをトリガする（促す）。
しきい値は、各イベントキュー内のイベントの数に基づく。
キュー内のイベントの数が予め定められたしきい値に達すると、イベントのいくつかの部分またはイベントのすべてをキューから転送することができる。
しきい値メカニズムはイベントをバースト処理する能力を提供し、タイムアウト信号に応答してイベントが転送される前に、キューに蓄積されるイベントが多くなりすぎないようにする。
しきい値は、各キュー２３１〜２３４および４２１〜４２３ごとに異なってもよい。
しきい値はまた、デスクトップストリーミングクライアント１２０（図１）へのチャネルのモニタリングに基づいて、またはデスクトップストリーミングクライアント１２０からのフィードバックに基づいて、デスクトップストリーミングエンジン２５０によって変更することも可能である。
【００３３】
その他の場合、本実施形態によれば、イベントの各イベントキューからの転送は、指定された時間間隔が経過した後で行われる。
したがって、一実施形態では、図２のレギュレータ２４１〜２４４および図４のレギュレータ４３１〜４３３はタイマを含むことができる。
時間間隔は、各キュー２３１〜２３４（図２）および４２１〜４２３（図４）ごとに異なってもよい。
時間間隔はまた、デスクトップストリーミングクライアント１２０（図１）へのチャネルのモニタリングに基づいて、またはデスクトップストリーミングクライアント１２０からのフィードバックに基づいて、デスクトップストリーミングエンジン２５０（図２）によって変更することも可能である。
これについて、図５および図６と併せてさらに以下説明する。
【００３４】
図５は、本発明の一実施形態によるデスクトップストリーミングエンジン２５０のブロック図である。
図５に示すように、デスクトップストリーミングエンジン２５０は、説明および考察を明確にするために別個に表された複数の要素を備えるが、これら要素はデスクトップストリーミングエンジン２５０内の別個のエンティティとして存在しなくてもよいことが理解される。
一般に、本発明の各種実施形態によれば、デスクトップストリーミングエンジン２５０は、図５の各種要素によって提供される能力および機能を提供する。
さらに、デスクトップストリーミングエンジン２５０は、本明細書において述べる能力および機能に加えて他の能力および機能も提供し得る。
【００３５】
本実施形態では、スケジューラ５１０がレギュレータ５８０（たとえば、図２および図４のそれぞれのレギュレータ２４１〜２４４および４３１〜４３３）に結合され、レギュレータ５８０は次いでキュー５９０（たとえば、図２および図４のそれぞれのキュー２３１〜２３４および４２１〜４２３）に結合される。
スケジューラ５１０はモニタ５３０にも結合される。
一実施形態では、モニタ５３０は、チャネル５７１、５７２、および５７３の空き帯域幅を定期的に測定する。
３つのチャネルしか示していないが、３つ以外の或る数のチャネルがあり得ることが理解される。
別の実施形態では、モニタ５３０はまた、クライアントの作業負荷ならびにクライアント装置の属性（たとえば、画面サイズおよび解像度等の装置の表示能力、プロセッサ速度等の装置の処理能力、装置の空きメモリ容量等）に関する情報を、デスクトップストリーミングクライアント１２０（図１）から集める。
モニタ５３０からの情報に基づいて、スケジューラ５１０は、各種イベントキューからのイベントの転送の開始に使用するトリガ（たとえば、時間間隔、しきい値、または他のメカニズム）を設定または調節することができる。
上で述べたように、各キューごとに、異なる時間間隔、しきい値等を指定することができる。
【００３６】
制御イベントキュー２３１およびウィンドウ移動キュー２３２（図２）内のイベントを転送するスケジュールは、これらタイプのイベントで必要な通信オーバーヘッドが低く、したがって即座にではないにせよ略即座に転送することができるため、比較的単純である。
イベントをウィンドウ更新キュー２３３およびオーディオサンプルキュー２３４から転送するスケジュールは、クライアント１０２（図１）に満足のいく表示を提供するために、モニタ５３０（またクライアントのモニタ６３０から、図６参照）からの情報に従って適合させることができる。
【００３７】
引き続き図５を参照するとともに、図２および図４も参照すると、転送エンジン５４０が、イベントタイプに基づいて、イベントをイベントキュー５９０から適切なチャネルに転送する。
たとえば、一実施形態では、制御イベントキュー２３１、ウィンドウ移動キュー２３２、グラフィックスウィンドウ更新キュー４２１、および他のウィンドウ更新キュー４２３からのイベントはＴＣＰチャネルに転送することができ、オーディオサンプルキュー２３４およびビデオウィンドウ更新キュー４２２からのイベントはＲＴＰチャネルに転送することができる。
【００３８】
図５を参照すると、本実施形態では、ビデオおよび／またはオーディオ内容はエンコーダ５５０を使用してエンコード（圧縮）することができる。
エンコードの程度は通常、クライアント１０２（図１）の属性に応じるが、クライアント１０２とサーバ１０１（図１）の間の接続（チャネル）の帯域幅によっても影響を受け得る。
【００３９】
本実施形態では、図５のシンクロナイザ５６０がオーディオを他の関連するメディア部分と同期させる。
オーディオに関連するメディア部分は、テキスト、グラフィックス、またはビデオであり得る。
一実施形態では、オーディオおよび関連する部分は、別個のチャネル（たとえば、ＲＴＰチャネル）を介して送信される。
この実施形態では、シンクロナイザ５６０は、スケジューラ５１０に、対応するサンプルキュー（図２のオーディオサンプルキュー２３４、ウィンドウ更新キュー２３３、および／またはウィンドウ移動キュー２３２）からデータを同期して得るように要求する。
たとえば、１秒に値するオーディオパケットが得られる場合、１秒に値するビデオパケットも得るべきである。
このタイプの手法は、オーディオパケットおよびビデオパケットがクライアント１０２（図１）に同時に、または互いに短い間隔以内で到着することを確実にするのに役立つ。
クライアント１０２は、到着時間のいずれの不一致も解決するために小容量バッファを利用し得る。
【００４０】
別の実施形態では、図５を参照すると、同期は、メディア部分（たとえば、ビデオデータ）がエンコードされるか否かに関係なくエンコーダ５５０によって行われる。
この実施形態では、エンコーダ５５０は、オーディオおよび関連するメディア部分を多重化し、その後、データを通信マネージャ５７０に転送し、通信マネージャは次いで、１つのチャネル（たとえば、ＲＴＰチャネル）を介して、多重化パケットを転送することができる。
クライアント１０２（図１、以下図６も参照）上のデコーダが、多重化データを同期して再生することができる。
たとえば、実際の時間の１秒以内で、デコーダは１秒に値するオーディオデータをデコードし、これをオーディオバッファに配置することができる。
実際の時間の１秒の残りの時間中に、デコーダは可能な限り多くのビデオフレームをデコードすることができる。
このようにして、図２のデスクトップストリーミングサーバ１１０は、クライアント側で利用可能な資源を利用することができる。
【００４１】
引き続き図５を参照すると、本実施形態では、通信マネージャ５７０が通信チャネル５７１〜５７３を管理する。
また本実施形態では、クライアントイベント受信器５２０が、制御イベント（たとえば、キーボードイベントおよびマウスイベント）をデスクトップストリーミングクライアント１２０（図１）から受け取る。
クライアントイベント受信器５２０は、これらイベントをドライバインタフェース２１０に転送し、ドライバインタフェース２１０は、一実施形態では、これらイベントをビデオドライバ２０３（図２）に転送する。
【００４２】
まとめると、一実施形態では、デスクトップストリーミングサーバ１１０（図２）は、イベントを各種ドライバからインターセプトしてフィルタリングし、イベントタイプに基づいて適したイベントキューに送り、オプションとして、選択されたビデオデータおよびオーディオデータをエンコードし、ＲＴＰチャネル等のチャネルを介してそのデータをクライアントにストリーミングし、クライアントから受け取るイベントに対応する。
【００４３】
図６は、本発明の一実施形態によるデスクトップストリーミングクライアント１２０のブロック図である。
図６に示すように、デスクトップストリーミングクライアント１２０は、説明および考察を明確にするために別個に表される複数の要素を備えるが、これら要素はデスクトップストリーミングクライアント１２０内の別個のエンティティとして存在しない場合もあることが理解される。
一般に、本発明の各種実施形態によれば、デスクトップストリーミングクライアント１２０は、図６の各種要素によって提供される能力および機能を提供する。
さらに、デスクトップストリーミングクライアント１２０は、本明細書に述べる能力および機能に加えて他の能力および機能を提供し得る。
【００４４】
本実施形態では、デスクトップストリーミングクライアント１２０は、エージェント６１０（デーモンと呼ばれる場合もある）を備える。
この実施形態では、エージェント６１０は、サーバ１０１、具体的にはデスクトップストリーミングサーバ１１０（図１）とのチャネル接続を確立し、維持する。
述べたように、これらチャネルはＴＣＰプロトコルおよびＲＴＰプロトコルを利用し得る。
エージェント６１０はまた、チャネルを介して受け取ったデータを処理エンジン６２０に転送する。
エージェント６１０はまた、空きチャネル帯域幅に関するデスクトップストリーミングサーバ１１０からの問い合わせに答えることができる。
さらに、セッション開始時に、エージェント６１０は、デスクトップストリーミングサーバ１１０にクライアントのデコード能力、ならびにプロセッサ速度、表示画面サイズ、および解像度等の他のクライアント属性を通知することができる。
【００４５】
本実施形態では、図６のエージェント６１０はモニタ６３０に結合され、情報をモニタ６３０から図１のデスクトップストリーミングサーバ１１０に提供することができる。
この実施形態では、モニタ６３０はクライアント１０２（図１）の作業負荷をモニタリングすることができ、また、空きメモリ容量に関する情報も提供することができる。
また、モニタ６３０は、表示がデスクトップストリーミングサーバ１１０から受け取ったイベントに基づいて生成されることの効率に関するフィードバックを提供することができ、それによって、たとえばストリーミングレートをフィードバックに従って調節することができる。
したがって、たとえば、図５のスケジューラ５１０がモニタ６３０からの（およびエージェント６１０からも）情報を使用して、デスクトップストリーミングサーバ１１０の各種イベントキューからのイベントの転送を開始するために使用されるトリガ（たとえば、時間間隔、しきい値、または他のメカニズム）を設定または調節することができる。
【００４６】
図６を参照すると、本実施形態では、エージェント６１０は処理エンジン６２０にも結合される。
エージェント６１０が受け取ったイベントは、処理エンジン６２０に転送される。
一実施形態では、処理エンジン６２０は、データがエンコードされる場合はデータ（イベント）をデコード（圧縮解除）するデコーダ６２２を備える。
処理エンジン６２０からのイベントはドライバインタフェース６４０に転送され、ドライバインタフェース６４０は、ドライバインタフェース２１０（図２）に関して上で説明した様式と同様に機能し、イベントをビデオドライバ６６３および／またはオーディオドライバ６６４に転送する。
【００４７】
本実施形態では、ドライバインタフェース６４０は、クライアント装置のキーボードドライバ６６１およびマウスドライバ６６２からもイベントを受け取る。
これらイベントはクライアントイベントプロセッサ６５０に転送され、クライアントイベントプロセッサ６５０は、重要ではないイベントをなくすことによってこれらイベントを最適化し、次いでエージェント６１０を介して重要なイベントをデスクトップストリーミングサーバ１１０（図２）に転送する。
すなわち、たとえば、特定のカーソル移動の場合、クライアントイベントプロセッサ６５０が、移動の開始座標および終了座標のみを識別して保持し、デスクトップストリーミングサーバ１１０に転送して、カーソル移動に関連する中間座標をなくすことができる。
【００４８】
したがって、まとめると、一実施形態では、デスクトップストリーミングクライアント１２０（図６）は、サーバから転送されたイベントをデコードし（イベントがエンコードされている場合）、イベントに基づいて表示を更新し、イベントがオーディオサンプルを含む場合はオーディオ再生を提供し、デスクトップストリーミングサーバ１１０（図２）からの問い合わせに答え、モニタリング情報をデスクトップストリーミングサーバ１１０に定期的に提供し、制御イベントをインターセプトしてデスクトップストリーイングサーバ１１０に送信する。
【００４９】
図７は、本発明の一実施形態による、イベントをサーバからクライアントに転送する方法のフローチャート７００である。
特定のステップをフローチャート７００に開示するが、係るステップは例示的なものである。
すなわち、本発明の実施形態は、他の各種ステップまたはフローチャート７００に記したステップの変形の実行にも適している。
フローチャート７００におけるステップは、提示される順序とは別の順序で実行することも可能であり、またフローチャート７００におけるステップをすべて実行しなくてもよいことが理解される。
フローチャート７００で説明される方法のすべて、または一部は、たとえば、コンピュータシステム等のコンピュータ使用可能媒体に常駐するコンピュータ可読かつコンピュータ実行可能な命令を使用して実装することができる。
一般に、フローチャート７００は、図１のサーバ１０１等の装置によって実装される。
【００５０】
図７のステップ７１０において、本実施形態では、イベントがドライバから受け取られる。
イベントは、キーボードイベント、カーソル制御（たとえば、マウス）イベント、ビデオイベント、またはオーディオイベントであり得る。
【００５１】
ステップ７２０において、本実施形態では、イベントは、イベントタイプに従ってイベントキューに送られる。
すなわち、同じタイプのイベントが特定のキューに転送される。
一実施形態では、イベントはフィルタリングされてイベントタイプが識別される。
【００５２】
ステップ７３０において、本実施形態では、イベントはイベントタイプに従って処理される。
たとえば、イベントがマルチメディアデータ（たとえば、ビデオデータおよび／またはオーディオデータ）を含む場合、イベントをエンコードすることができる。
カーソル移動の場合、開始点および終了点のみの座標を保持し、開始点と終了点の間のポイントの座標をなくすことができる。
【００５３】
ステップ７４０において、本実施形態では、イベントは、トリガされたときにクライアントに転送される。
クライアントへの転送は、イベントのタイプに対応するプロトコルに従って行われる。
一実施形態では、イベント転送は、指定された時間間隔の経過によってトリガされる。
別の実施形態では、イベント転送は、イベントキュー内のイベントの数が指定されたしきい値に達したときにトリガされる。
【００５４】
こうして、本発明の実施形態が説明されてきた。
本発明は特定の実施形態において説明されてきたが、本発明はそのような実施形態に限定されるものと解釈されるべきではなく、むしろ添付の特許請求の範囲に従って解釈されるべきであることは理解されたい。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態による、ネットワークに結合されたサーバおよびクライアントのブロック図である。
【図２】本発明の一実施形態によるデスクトップストリーミングサーバのブロック図である。
【図３】本発明の一実施形態によるドライバインタフェースのブロック図である。
【図４】本発明の一実施形態によるウィンドウ更新の分化を示すブロック図である。
【図５】本発明の一実施形態によるデスクトップストリーミングエンジンのブロック図である。
【図６】本発明の一実施形態によるデスクトップストリーミングクライアントのブロック図である。
【図７】本発明の一実施形態による、リモートクライアントにイベントを転送する方法のフローチャートである。
【符号の説明】
【００５６】
１１０・・・デスクトップストリーミングサーバ，
１２０・・・デスクトップストリーミングクライアント，
２０１・・・キーボードドライバ，
２０２・・・マウスドライバ，
２０３・・・ビデオドライバ，
２０４・・・オーディオドライバ，
２１０・・・ドライバインタフェース，
２２０・・・イベントフィルタ，
２３１・・・制御イベントキュー，
２３２・・・ウィンドウ移動キュー，
２３３・・・ウィンドウ更新キュー，
２３４・・・オーディオサンプルキュー，
２４１〜２４４・・・レギュレータ，
２５０・・・デスクトップストリーミングエンジン，
３０１、３０２・・・インタフェース，
３０５・・・共通アプリケーションプログラムインタフェース，
２５０・・・デスクトップストリーミングエンジン，
４１０・・・ウィンドウ更新分化器，
４２１・・・グラフィックスウィンドウ更新キュー，
４２２，４２３・・・ビデオウィンドウ更新キュー，
４３１〜４３３・・・レギュレータ，
５１０・・・スケジューラ，
５２０・・・クライアントイベント受信器，
５３０・・・モニタ，
５４０・・・転送エンジン，
５５０・・・エンコーダ，
５６０・・・シンクロナイザ，
５７０・・・通信マネージャ，
５７１〜５７３・・・チャネル，
５８０・・・レギュレータ，
５９０・・・キュー，
６１０・・・エージェント，
６２０・・・処理エンジン，
６２２・・・デコーダ，
６３０・・・モニタ，
６４０・・・ドライバインタフェース，
６５０・・・クライアントイベントプロセッサ，
６６１・・・キーボードドライバ，
６６２・・・マウスドライバ，
６６３・・・ビデオドライバ，
６６４・・・オーディオドライバ，
【技術分野】
【０００１】
本発明の実施形態は、コンピュータシステムネットワークに関する。
より詳細には、本発明の実施形態は、ネットワーク環境におけるマルチメディアストリーミングに関する。
【背景技術】
【０００２】
コンピュータシステムネットワークは、リモートクライアント装置からのローカル資源（たとえば、サーバ上のソフトウェアアプリケーション、データ、ウェブページ等）へのアクセスを提供する。
仮想ネットワークコンピューティング等のアプリケーションは、この概念をさらに拡張した。
仮想コンピューティングネットワークでは、サーバは、ソフトウェアアプリケーションおよびデータのみならず、クライアント装置からアクセスし制御することが可能なデスクトップ環境をも供給する。
本質的には、クライアント装置のユーザに、サーバにおいて生成され、次いでクライアントに転送されて再現された表示（グラフィカルユーザインタフェースまたはデスクトップ）が提示される。
したがって、クライアントが維持する状態量を削減することができ、「薄い」クライアントと呼ばれるものになる。
また、単一のデスクトップを、いくつかの異なるクライアントから同時にアクセスして見ることができる。
これは、一群の協同工学ワークステーションを実施する場合に特に有用であり得る。
【０００３】
従来技術による仮想ネットワークコンピューティングシステムは、通常、リモートフレームバッファ（ＲＦＢ）プロトコル等のプロトコルを使用して、サーバ生成のグラフィカルユーザインタフェースへのクライアントアクセスを提供する。
コンピュータシステムのモニタに表示する画像は、サーバ上のフレームバッファに保持される。
極端な場合、フレームバッファの内容全体が、周期的にクライアント装置に転送され、表示される。
この極端な場合に対する改良策には、前の転送以来、フレームバッファ（ひいては表示）に対して行われた変更のみを送信することが含まれる。
【０００４】
通常、クライアントへの転送速度は、毎秒約１０〜１５フレームである。
この速度はかなり高いが、ビデオデータまたはマルチメディアデータ（ビデオデータおよびオーディオデータ）をサーバからクライアントに満足のいくように転送するには不十分であるとみなされる。
したがって、従来技術によるシステムはこの点で制限される。
【０００５】
したがって、ビデオ／マルチメディアデータをサーバからクライアントに仮想ネットワークコンピューティングシステムにおいて転送するより満足のいく方法が望ましい。
本発明の実施形態は、このような改良を提供する。
【特許文献１】米国特許第６１６６７３４号
【特許文献２】国際公開第００／３９６７８号
【特許文献３】米国特許第６２５９４４３号
【非特許文献１】CHIA-CHEN KUO ET AL: "Design and implementation of a network application architecture for thin clients" PROCEEDINGS OF THE 26TH. ANNUAL INTERNATIONAL COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE. COMPSAC 2002. OXFORD, ENGLAND, AUG. 26 - 29, 2002, ANNUAL INTERNATIONAL COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE, LOS ALAMITOS, CA: IEEE COMP. SOC, US, vol. CONF. 26, 26 August 2002 (2002-08-26), pages 193-198, XP010611116 ISBN: 0-7695-1727-7 the whole document
【発明の開示】
【課題を解決するための手段】
【０００６】
［発明の開示］
本発明の実施形態は、イベントをサーバからリモートクライアントに転送する方法およびシステムに関する。
イベントがドライバから受け取られる。
イベントは、イベントタイプに従ってイベントキューに送られる。
イベントは、イベントタイプに従って処理される。
処理は、イベントがマルチメディアデータを含む場合、イベントをエンコードすることを含む。
イベントは、トリガされると、リモートクライアントに転送される。
転送は、イベントタイプに対応するプロトコルに従って行われる。
【０００７】
本明細書において援用され、かつ本明細書の一部を構成する添付の図面は、本発明の実施形態を例示しており、その記述とともに、本発明の原理を説明するのに有用である。
【０００８】
本明細書において参照される図面は、具体的に述べられる場合を除いて、縮尺どおりに描かれているものと理解されるべきではない。
【発明を実施するための最良の形態】
【０００９】
ここで本発明の種々の実施形態が詳細に参照されることになり、その数々の例が添付の図面に示される。
本発明はこれらの実施形態とともに説明されることになるが、本発明をこれらの実施形態に限定することは意図していないことは理解されよう。
それどころか、本発明は、添付の特許請求の範囲によって規定されるような、本発明の精神および範囲内に含まれる場合がある、代替形態、変更形態および同等形態を網羅することが意図されている。
さらに、本発明の以下の説明では、本発明を完全に理解してもらうために、数多くの具体的な細部が述べられる。
他の事例では、既知の方法、手順、構成要素および回路は、本発明の態様を不必要に曖昧にしないように詳細には説明されていない。
【００１０】
図１は、本発明の一実施形態による、ネットワーク１００に結合されたサーバ１０１およびクライアント１０２のブロック図である。
ネットワーク１００は図示の要素以外の要素も含み得ることが理解される。
ネットワーク１００はまた、図示の様々な要素を２つ以上含むことができ、たとえば、サーバ１０１に複数のクライアントが結合されてもよく、複数のサーバがあってもよい。
サーバ１０１およびクライアント１０２の機能については以下に考察（少なくとも図２および図６を参照して）するが、これら要素は考察する機能以外の機能も実施し得ることが理解される。
【００１１】
通信は、図１のサーバ１０１とクライアント１０２の間で直接行われる場合もあり、または中間装置もしくはノード（図示せず）を通して間接的に行われる場合もある。
また、通信は有線であっても、または無線であってもよく、または有線と無線の組み合わせであってもよい。
一実施形態では、通信はワールドワイドウェブ（すなわちインターネット）を介して行われる。
【００１２】
一実施形態では、サーバ１０１およびクライアント１０２は、処理能力およびメモリ能力を提供するコンピュータシステムである。
さらに、本発明の実施形態によれば、サーバ１０１はデスクトップストリーミングサーバ１１０を実装し、クライアント１０２はデスクトップストリーミングクライアント１２０を実装する。
この実施形態では、デスクトップストリーミングサーバ１１０およびデスクトップストリーミングクライアント１２０は、サーバ１０１が表示（たとえば、グラフィカルユーザインタフェース、特に「デスクトップ」表示）をクライアント１０２に供給できるようにする。
分かるように、サーバ側制御およびクライアント側制御の両方が、同時に、または排他的に可能である。
【００１３】
本発明の実施形態によれば、「イベント」は、デスクトップストリーミングサーバ１１０およびデスクトップストリーミングクライアント１２０を使用して、サーバ１０１からクライアント１０２に、またこの逆にそれぞれ転送される。
本明細書において使用するイベントは一般に、キーボードドライバ、マウスドライバ、ビデオドライバ、またはオーディオドライバ等のソフトウェアドライバの出力である。
したがって、イベントとしては、マウスボタンのクリックやキーボードのキーの押下等の検出可能なアクションまたは発生が挙げられる。
イベントは、クライアント１０２が表示する表示（グラフィカルユーザインタフェース）を変更させ得るアクションまたは発生を指すこともできる。
たとえば、テキスト（文書処理中の）文書をスクロールすることにより、または文書の或るページを別のページに変更することにより生じる表示の変更がイベントを構成し得る。
表示中のウィンドウが移動することもイベントを構成し得る。
ビデオ動画表示もイベントを構成し得る。
オーディオサンプルもイベントを構成し得る。
【００１４】
まとめると、本明細書において使用するイベントは、サーバ１０１またはクライアント１０２が使用するドライバの出力であり、サーバ１０１またはクライアント１０２上の表示を変更させる可能性があり、かつ／またはクライアント１０２にオーディオ出力を発生させ得る。
イベントは一般に、制御イベントおよびデータイベントに分類することができる。
制御イベントは、他の構成要素の実行の振る舞いをローカルに、またはリモートに変更させる制御情報を伝える。
データイベントは、他の構成要素に内容の変更を通知する内容データを伝える。
【００１５】
考察を簡単にするために、「マウス」という用語を本明細書において用いるが、マウスに代えて、またはマウスと併せて、他のカーソル制御手段を使用し得ることが理解される。
無数のカーソル制御機構が当該技術分野において既知であり、これらのそれぞれを本発明により使用し得る。
「キーボード」という用語も本明細書において用いられる。
この場合でも、音声認識システムを含め、キーボードの機能を提供する無数の機構が、当該技術分野において既知であり、これらのそれぞれを本発明により使用し得る。
したがって、本発明の実施形態はマウスおよびキーボードの場合について説明するが、本発明はそのように限定されるものではない。
むしろ、上述したように、「イベント」という用語およびこの用語が本明細書においてどのように用いられるかに集中すべきである。
この文脈の中では、キーボードおよびマウスのイベントはイベントの単なる例にすぎず、本発明の実施形態は、略すべてのタイプのイベントとの併用に適している。
【００１６】
一実施形態では、サーバ側において、ドライバから受け取ったイベントが、イベントタイプに従ってイベントキューに送られる。
次いで、イベントはそれぞれのイベントタイプに従って処理され、たとえば、マルチメディアイベントをエンコードすることができる。
次いで、イベントは、イベントタイプに対応するプロトコルに従ってサーバ１０１からクライアント１０２に転送される。
一実施形態では、キーボードドライバおよびマウスドライバからのイベントは、伝送制御プロトコル（ＴＣＰ）等のプロトコルを使用してクライアント１０２に転送されるが、ビデオドライバおよびオーディオドライバからのイベントは、リアルタイムプロトコル（ＲＴＰ）等のプロトコルを使用してクライアント１０２に転送される。
これらプロセスについて、図２と併せてさらに詳細に以下説明する。
【００１７】
ＴＣＰおよびＲＴＰは当該技術分野において既知である。
ＴＣＰは、信頼性の高いプロトコルを提供し、ＲＴＰは、マルチメディアデータオブジェクトのビデオ部分およびオーディオ部分を同期させるのに有用なタイミング機能を提供する。
したがって、ＴＣＰは、制御イベント（たとえば、キーボードイベントおよびマウスイベント）、ならびにグラフィックスアプリケーションの変更等、他の高い正確性が要求されるイベントを正確に転送するために使用することができ、ＲＴＰは、フレームバッファ（ビデオバッファ）およびサウンドバッファの更新をストリーミングするために使用することができる。
これらまたは同様の機能を提供することができる他のプロトコルも、代わりに使用することが可能である。
【００１８】
クライアント側においては、一実施形態では、イベントは、キーボードドライバおよびマウスドライバから受け取られ、ＴＣＰ等のプロトコルを使用して図１のサーバ１０１に転送される。
このプロセスについては、図６と併せてさらに以下説明する。
本実施形態では、サーバ１０１とクライアント１０２の間の関係には、クライアントがオーディオドライバおよびビデオドライバからイベントをサーバに送ることがないが、本発明はそのように限定されるものではない。
【００１９】
図２は、本発明の一実施形態によるデスクトップストリーミングサーバ１１０のブロック図である。
デスクトップストリーミングサーバ１１０は、図１のサーバ１０１に、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせとして実装される。
図２に示すように、デスクトップストリーミングサーバ１１０は、説明および考察を明確にするために別個に表される複数の要素を備えるが、これら要素はデスクトップストリーミングサーバ１１０内の別個のエンティティとして存在しなくてもよいことが理解される。
一般に、本発明の各種実施形態によれば、デスクトップストリーミングサーバ１１０は、図２の各種要素によって提供される能力および機能を提供する。
さらに、デスクトップストリーミングサーバ１１０は、本明細書に述べる能力および機能に加えて他の能力および機能を提供し得る。
【００２０】
本実施形態では、ドライバインタフェース２１０が、キーボードドライバ２０１、マウスドライバ２０２、ビデオドライバ２０３、および／またはオーディオドライバ２０４等であるがこれらに限定されない複数のドライバから入力（イベント）を受け取る。
したがって、ウィンドウ変更、キーボード入力、およびカーソル移動等のより従来的なイベントをインターセプトすることに加えて、ドライバインタフェース２１０はまた、ビデオドライバ２０３からビデオデータを、またオーディオドライバ２０４からオーディオデータをサンプリングする。
【００２１】
一般に、ドライバ２０１〜２０４は、土台をなすオペレーティングシステムの構成要素である。
たとえば、Ｗｉｎｄｏｗｓ（登録商標）環境のキーボードドライバは、Ｌｉｎｕｘ環境のキーボードドライバと異なり得る。
本実施形態によれば、ドライバインタフェース２１０は、デスクトップストリーミングサーバ１１０の下流部分への固定インタフェース（たとえば、イベントフィルタ２２０への固定インタフェース）を提供しながら、各種タイプのドライバと通信する能力を提供する。
【００２２】
図３は、本発明の一実施形態によるドライバインタフェース２１０のブロック図である。
この実施形態では、ドライバインタフェース２１０は、各ドライバとのインタフェースに適したモジュールがあるように、インタフェース３０１および３０２により具現される複数のインタフェースモジュールを備える。
これは、１つのドライバにつき１つのインタフェースモジュールがあると言っているわけではないが、その場合もあり得る。
【００２３】
本実施形態では、ドライバインタフェース２１０は、インタフェース３０１および３０２等に共通のアプリケーションプログラムインタフェース（ＡＰＩ）３０５も備える。
ＡＰＩ３０５は、無数のドライバが可能であるにも拘わらず、デスクトップストリーミングサーバ１１０の残りの部分に単一のインタフェースを提供し、したがって、デスクトップストリーミングサーバ１１０を、土台をなすオペレーティングシステムから切り離す。
【００２４】
図２に戻ると、本実施形態では、ドライバインタフェース２１０からのイベントはイベントフィルタ２２０に提供される（受け取られる）。
この実施形態では、イベントフィルタ２２０は、イベントタイプに従ってイベントを識別し、イベントをイベントタイプに従って各イベントキューに送る。
イベントキューは、イベントタイプに適した処理（もしあれば）の後、イベントタイプに適したプロトコル（たとえば、ＴＣＰまたはＲＴＰ）を使用してデスクトップストリーミングクライアント１２０（図１）に転送することができる同様のタイプのイベントをバッファリングするために使用される。
【００２５】
本実施形態では、図２のイベントフィルタ２２０は、イベントを以下のタイプに分類する。
すなわち、１）たとえばキーボード入力またはカーソル（たとえば、マウス）移動によって生成される制御イベント、２）ウィンドウの内容に変更がない、ウィンドウ移動によって生成されるウィンドウ移動イベント、３）ウィンドウ内容の変更によって生成されるウィンドウ更新、４）オーディオドライバ２０４のサウンドバッファの変更から取り込まれるオーディオサンプル。
この実施形態では、制御イベントは制御イベントキュー２３１に転送され、ウィンドウ移動はウィンドウ移動キュー２３２に転送され、ウィンドウ更新はウィンドウ更新キュー２３３に転送され、オーディオサンプルはオーディオサンプルキュー２３４に転送される。
【００２６】
本実施形態では、制御イベントキュー２３１内の制御イベントは、マウスまたはカーソルの座標変更を記録する。
たとえば、特定のカーソル移動の場合、移動の開始座標および終了座標のみを図１のデスクトップストリーミングクライアント１２０に転送するだけでよい。
制御イベントは、デスクトップストリーミングエンジン２５０によってさらに最適化することができる。
【００２７】
引き続き図２を参照すると、本実施形態では、ウィンドウ移動キュー２３２は、移動中のウィンドウの座標変更を（ウィンドウの内容は変更せずに）記録する。
ウィンドウの内容がすでに図１のデスクトップストリーミングクライアント１２０に転送されている場合、ウィンドウの座標の変更のみをクライアントに転送するだけでよい。
次いで、クライアントは、すでに受け取っていたウィンドウの内容および新しいウィンドウ座標を使用してデスクトップ表示を表現することができる。
【００２８】
本実施形態によれば、図２のウィンドウ更新キュー２３３は、ウィンドウ内容の更新を記録する。
これら更新は、ビデオフレームバッファから取り込むことができる。
一実施形態では、適切なエンコーダおよび転送プロトコルの選択に役立つように、ウィンドウ更新は３つのタイプに分類される。
すなわち、１）グラフィックスウィンドウ更新、２）ビデオウィンドウ更新、および３）他のウィンドウ更新。
ここで、グラフィックスは相対的に静的な画像（たとえば、ビデオと比較して相対的に低い更新率を有する画像）を指すために使用され、ビデオは相対的に高い更新率を有する動画を指し、他のウィンドウ更新は、文書処理中の文書内のテキスト等、相対的に静的なウィンドウ内容を指す。
概して、ウィンドウ更新は、画像の複雑性および更新頻度に従って分類に分けることができる。
【００２９】
図４は、本発明の一実施形態によるウィンドウ更新の分化を示すブロック図である。
この実施形態では、ウィンドウ更新分化器４１０が、ウィンドウを上記カテゴリにフィルタリングする。
ウィンドウ更新分化器４１０は、表示アプリケーションタイプ、ならびにウィンドウの座標および画面サイズ等の情報を用いてこれを実現することができる。
表示アプリケーションタイプは、たとえば、新しいウィンドウが作成されたとき、ウェブサイトのユニフォームリソースロケータ（ＵＲＬ）がクリックされたとき、またはアプリケーションが実行されたときにドライバインタフェース２１０（図２）から得ることができる。
座標および画面サイズは、ビデオフレームバッファへの更新のどの部分がどのウィンドウに属するかを見つけるのに役立つ。
【００３０】
グラフィックスウィンドウ更新はグラフィックスウィンドウ更新キュー４２１に転送され、ビデオウィンドウ更新はビデオウィンドウ更新キュー４２２に転送され、他のウィンドウ更新は他のウィンドウ更新キュー４２３に転送される。
【００３１】
図２に戻ると、本実施形態では、イベントの各キュー２３１〜２３４からデスクトップストリーミングエンジン２５０への転送は、各レギュレータ２４１、２４２、２４３、および２４４によってトリガされる。
同様に、図４の実施形態では、キュー４２１〜４２３は各レギュレータ４３１、４３２、および４３３の制御下にある。
【００３２】
一実施形態では、図２のレギュレータ２４１〜２４４（および図４のレギュレータ４３１〜４３３）は、しきい値に達したこと、または或る時間間隔が経過したことに基づいて、それぞれの各キューからイベントをトリガする（促す）。
しきい値は、各イベントキュー内のイベントの数に基づく。
キュー内のイベントの数が予め定められたしきい値に達すると、イベントのいくつかの部分またはイベントのすべてをキューから転送することができる。
しきい値メカニズムはイベントをバースト処理する能力を提供し、タイムアウト信号に応答してイベントが転送される前に、キューに蓄積されるイベントが多くなりすぎないようにする。
しきい値は、各キュー２３１〜２３４および４２１〜４２３ごとに異なってもよい。
しきい値はまた、デスクトップストリーミングクライアント１２０（図１）へのチャネルのモニタリングに基づいて、またはデスクトップストリーミングクライアント１２０からのフィードバックに基づいて、デスクトップストリーミングエンジン２５０によって変更することも可能である。
【００３３】
その他の場合、本実施形態によれば、イベントの各イベントキューからの転送は、指定された時間間隔が経過した後で行われる。
したがって、一実施形態では、図２のレギュレータ２４１〜２４４および図４のレギュレータ４３１〜４３３はタイマを含むことができる。
時間間隔は、各キュー２３１〜２３４（図２）および４２１〜４２３（図４）ごとに異なってもよい。
時間間隔はまた、デスクトップストリーミングクライアント１２０（図１）へのチャネルのモニタリングに基づいて、またはデスクトップストリーミングクライアント１２０からのフィードバックに基づいて、デスクトップストリーミングエンジン２５０（図２）によって変更することも可能である。
これについて、図５および図６と併せてさらに以下説明する。
【００３４】
図５は、本発明の一実施形態によるデスクトップストリーミングエンジン２５０のブロック図である。
図５に示すように、デスクトップストリーミングエンジン２５０は、説明および考察を明確にするために別個に表された複数の要素を備えるが、これら要素はデスクトップストリーミングエンジン２５０内の別個のエンティティとして存在しなくてもよいことが理解される。
一般に、本発明の各種実施形態によれば、デスクトップストリーミングエンジン２５０は、図５の各種要素によって提供される能力および機能を提供する。
さらに、デスクトップストリーミングエンジン２５０は、本明細書において述べる能力および機能に加えて他の能力および機能も提供し得る。
【００３５】
本実施形態では、スケジューラ５１０がレギュレータ５８０（たとえば、図２および図４のそれぞれのレギュレータ２４１〜２４４および４３１〜４３３）に結合され、レギュレータ５８０は次いでキュー５９０（たとえば、図２および図４のそれぞれのキュー２３１〜２３４および４２１〜４２３）に結合される。
スケジューラ５１０はモニタ５３０にも結合される。
一実施形態では、モニタ５３０は、チャネル５７１、５７２、および５７３の空き帯域幅を定期的に測定する。
３つのチャネルしか示していないが、３つ以外の或る数のチャネルがあり得ることが理解される。
別の実施形態では、モニタ５３０はまた、クライアントの作業負荷ならびにクライアント装置の属性（たとえば、画面サイズおよび解像度等の装置の表示能力、プロセッサ速度等の装置の処理能力、装置の空きメモリ容量等）に関する情報を、デスクトップストリーミングクライアント１２０（図１）から集める。
モニタ５３０からの情報に基づいて、スケジューラ５１０は、各種イベントキューからのイベントの転送の開始に使用するトリガ（たとえば、時間間隔、しきい値、または他のメカニズム）を設定または調節することができる。
上で述べたように、各キューごとに、異なる時間間隔、しきい値等を指定することができる。
【００３６】
制御イベントキュー２３１およびウィンドウ移動キュー２３２（図２）内のイベントを転送するスケジュールは、これらタイプのイベントで必要な通信オーバーヘッドが低く、したがって即座にではないにせよ略即座に転送することができるため、比較的単純である。
イベントをウィンドウ更新キュー２３３およびオーディオサンプルキュー２３４から転送するスケジュールは、クライアント１０２（図１）に満足のいく表示を提供するために、モニタ５３０（またクライアントのモニタ６３０から、図６参照）からの情報に従って適合させることができる。
【００３７】
引き続き図５を参照するとともに、図２および図４も参照すると、転送エンジン５４０が、イベントタイプに基づいて、イベントをイベントキュー５９０から適切なチャネルに転送する。
たとえば、一実施形態では、制御イベントキュー２３１、ウィンドウ移動キュー２３２、グラフィックスウィンドウ更新キュー４２１、および他のウィンドウ更新キュー４２３からのイベントはＴＣＰチャネルに転送することができ、オーディオサンプルキュー２３４およびビデオウィンドウ更新キュー４２２からのイベントはＲＴＰチャネルに転送することができる。
【００３８】
図５を参照すると、本実施形態では、ビデオおよび／またはオーディオ内容はエンコーダ５５０を使用してエンコード（圧縮）することができる。
エンコードの程度は通常、クライアント１０２（図１）の属性に応じるが、クライアント１０２とサーバ１０１（図１）の間の接続（チャネル）の帯域幅によっても影響を受け得る。
【００３９】
本実施形態では、図５のシンクロナイザ５６０がオーディオを他の関連するメディア部分と同期させる。
オーディオに関連するメディア部分は、テキスト、グラフィックス、またはビデオであり得る。
一実施形態では、オーディオおよび関連する部分は、別個のチャネル（たとえば、ＲＴＰチャネル）を介して送信される。
この実施形態では、シンクロナイザ５６０は、スケジューラ５１０に、対応するサンプルキュー（図２のオーディオサンプルキュー２３４、ウィンドウ更新キュー２３３、および／またはウィンドウ移動キュー２３２）からデータを同期して得るように要求する。
たとえば、１秒に値するオーディオパケットが得られる場合、１秒に値するビデオパケットも得るべきである。
このタイプの手法は、オーディオパケットおよびビデオパケットがクライアント１０２（図１）に同時に、または互いに短い間隔以内で到着することを確実にするのに役立つ。
クライアント１０２は、到着時間のいずれの不一致も解決するために小容量バッファを利用し得る。
【００４０】
別の実施形態では、図５を参照すると、同期は、メディア部分（たとえば、ビデオデータ）がエンコードされるか否かに関係なくエンコーダ５５０によって行われる。
この実施形態では、エンコーダ５５０は、オーディオおよび関連するメディア部分を多重化し、その後、データを通信マネージャ５７０に転送し、通信マネージャは次いで、１つのチャネル（たとえば、ＲＴＰチャネル）を介して、多重化パケットを転送することができる。
クライアント１０２（図１、以下図６も参照）上のデコーダが、多重化データを同期して再生することができる。
たとえば、実際の時間の１秒以内で、デコーダは１秒に値するオーディオデータをデコードし、これをオーディオバッファに配置することができる。
実際の時間の１秒の残りの時間中に、デコーダは可能な限り多くのビデオフレームをデコードすることができる。
このようにして、図２のデスクトップストリーミングサーバ１１０は、クライアント側で利用可能な資源を利用することができる。
【００４１】
引き続き図５を参照すると、本実施形態では、通信マネージャ５７０が通信チャネル５７１〜５７３を管理する。
また本実施形態では、クライアントイベント受信器５２０が、制御イベント（たとえば、キーボードイベントおよびマウスイベント）をデスクトップストリーミングクライアント１２０（図１）から受け取る。
クライアントイベント受信器５２０は、これらイベントをドライバインタフェース２１０に転送し、ドライバインタフェース２１０は、一実施形態では、これらイベントをビデオドライバ２０３（図２）に転送する。
【００４２】
まとめると、一実施形態では、デスクトップストリーミングサーバ１１０（図２）は、イベントを各種ドライバからインターセプトしてフィルタリングし、イベントタイプに基づいて適したイベントキューに送り、オプションとして、選択されたビデオデータおよびオーディオデータをエンコードし、ＲＴＰチャネル等のチャネルを介してそのデータをクライアントにストリーミングし、クライアントから受け取るイベントに対応する。
【００４３】
図６は、本発明の一実施形態によるデスクトップストリーミングクライアント１２０のブロック図である。
図６に示すように、デスクトップストリーミングクライアント１２０は、説明および考察を明確にするために別個に表される複数の要素を備えるが、これら要素はデスクトップストリーミングクライアント１２０内の別個のエンティティとして存在しない場合もあることが理解される。
一般に、本発明の各種実施形態によれば、デスクトップストリーミングクライアント１２０は、図６の各種要素によって提供される能力および機能を提供する。
さらに、デスクトップストリーミングクライアント１２０は、本明細書に述べる能力および機能に加えて他の能力および機能を提供し得る。
【００４４】
本実施形態では、デスクトップストリーミングクライアント１２０は、エージェント６１０（デーモンと呼ばれる場合もある）を備える。
この実施形態では、エージェント６１０は、サーバ１０１、具体的にはデスクトップストリーミングサーバ１１０（図１）とのチャネル接続を確立し、維持する。
述べたように、これらチャネルはＴＣＰプロトコルおよびＲＴＰプロトコルを利用し得る。
エージェント６１０はまた、チャネルを介して受け取ったデータを処理エンジン６２０に転送する。
エージェント６１０はまた、空きチャネル帯域幅に関するデスクトップストリーミングサーバ１１０からの問い合わせに答えることができる。
さらに、セッション開始時に、エージェント６１０は、デスクトップストリーミングサーバ１１０にクライアントのデコード能力、ならびにプロセッサ速度、表示画面サイズ、および解像度等の他のクライアント属性を通知することができる。
【００４５】
本実施形態では、図６のエージェント６１０はモニタ６３０に結合され、情報をモニタ６３０から図１のデスクトップストリーミングサーバ１１０に提供することができる。
この実施形態では、モニタ６３０はクライアント１０２（図１）の作業負荷をモニタリングすることができ、また、空きメモリ容量に関する情報も提供することができる。
また、モニタ６３０は、表示がデスクトップストリーミングサーバ１１０から受け取ったイベントに基づいて生成されることの効率に関するフィードバックを提供することができ、それによって、たとえばストリーミングレートをフィードバックに従って調節することができる。
したがって、たとえば、図５のスケジューラ５１０がモニタ６３０からの（およびエージェント６１０からも）情報を使用して、デスクトップストリーミングサーバ１１０の各種イベントキューからのイベントの転送を開始するために使用されるトリガ（たとえば、時間間隔、しきい値、または他のメカニズム）を設定または調節することができる。
【００４６】
図６を参照すると、本実施形態では、エージェント６１０は処理エンジン６２０にも結合される。
エージェント６１０が受け取ったイベントは、処理エンジン６２０に転送される。
一実施形態では、処理エンジン６２０は、データがエンコードされる場合はデータ（イベント）をデコード（圧縮解除）するデコーダ６２２を備える。
処理エンジン６２０からのイベントはドライバインタフェース６４０に転送され、ドライバインタフェース６４０は、ドライバインタフェース２１０（図２）に関して上で説明した様式と同様に機能し、イベントをビデオドライバ６６３および／またはオーディオドライバ６６４に転送する。
【００４７】
本実施形態では、ドライバインタフェース６４０は、クライアント装置のキーボードドライバ６６１およびマウスドライバ６６２からもイベントを受け取る。
これらイベントはクライアントイベントプロセッサ６５０に転送され、クライアントイベントプロセッサ６５０は、重要ではないイベントをなくすことによってこれらイベントを最適化し、次いでエージェント６１０を介して重要なイベントをデスクトップストリーミングサーバ１１０（図２）に転送する。
すなわち、たとえば、特定のカーソル移動の場合、クライアントイベントプロセッサ６５０が、移動の開始座標および終了座標のみを識別して保持し、デスクトップストリーミングサーバ１１０に転送して、カーソル移動に関連する中間座標をなくすことができる。
【００４８】
したがって、まとめると、一実施形態では、デスクトップストリーミングクライアント１２０（図６）は、サーバから転送されたイベントをデコードし（イベントがエンコードされている場合）、イベントに基づいて表示を更新し、イベントがオーディオサンプルを含む場合はオーディオ再生を提供し、デスクトップストリーミングサーバ１１０（図２）からの問い合わせに答え、モニタリング情報をデスクトップストリーミングサーバ１１０に定期的に提供し、制御イベントをインターセプトしてデスクトップストリーイングサーバ１１０に送信する。
【００４９】
図７は、本発明の一実施形態による、イベントをサーバからクライアントに転送する方法のフローチャート７００である。
特定のステップをフローチャート７００に開示するが、係るステップは例示的なものである。
すなわち、本発明の実施形態は、他の各種ステップまたはフローチャート７００に記したステップの変形の実行にも適している。
フローチャート７００におけるステップは、提示される順序とは別の順序で実行することも可能であり、またフローチャート７００におけるステップをすべて実行しなくてもよいことが理解される。
フローチャート７００で説明される方法のすべて、または一部は、たとえば、コンピュータシステム等のコンピュータ使用可能媒体に常駐するコンピュータ可読かつコンピュータ実行可能な命令を使用して実装することができる。
一般に、フローチャート７００は、図１のサーバ１０１等の装置によって実装される。
【００５０】
図７のステップ７１０において、本実施形態では、イベントがドライバから受け取られる。
イベントは、キーボードイベント、カーソル制御（たとえば、マウス）イベント、ビデオイベント、またはオーディオイベントであり得る。
【００５１】
ステップ７２０において、本実施形態では、イベントは、イベントタイプに従ってイベントキューに送られる。
すなわち、同じタイプのイベントが特定のキューに転送される。
一実施形態では、イベントはフィルタリングされてイベントタイプが識別される。
【００５２】
ステップ７３０において、本実施形態では、イベントはイベントタイプに従って処理される。
たとえば、イベントがマルチメディアデータ（たとえば、ビデオデータおよび／またはオーディオデータ）を含む場合、イベントをエンコードすることができる。
カーソル移動の場合、開始点および終了点のみの座標を保持し、開始点と終了点の間のポイントの座標をなくすことができる。
【００５３】
ステップ７４０において、本実施形態では、イベントは、トリガされたときにクライアントに転送される。
クライアントへの転送は、イベントのタイプに対応するプロトコルに従って行われる。
一実施形態では、イベント転送は、指定された時間間隔の経過によってトリガされる。
別の実施形態では、イベント転送は、イベントキュー内のイベントの数が指定されたしきい値に達したときにトリガされる。
【００５４】
こうして、本発明の実施形態が説明されてきた。
本発明は特定の実施形態において説明されてきたが、本発明はそのような実施形態に限定されるものと解釈されるべきではなく、むしろ添付の特許請求の範囲に従って解釈されるべきであることは理解されたい。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態による、ネットワークに結合されたサーバおよびクライアントのブロック図である。
【図２】本発明の一実施形態によるデスクトップストリーミングサーバのブロック図である。
【図３】本発明の一実施形態によるドライバインタフェースのブロック図である。
【図４】本発明の一実施形態によるウィンドウ更新の分化を示すブロック図である。
【図５】本発明の一実施形態によるデスクトップストリーミングエンジンのブロック図である。
【図６】本発明の一実施形態によるデスクトップストリーミングクライアントのブロック図である。
【図７】本発明の一実施形態による、リモートクライアントにイベントを転送する方法のフローチャートである。
【符号の説明】
【００５６】
１１０・・・デスクトップストリーミングサーバ，
１２０・・・デスクトップストリーミングクライアント，
２０１・・・キーボードドライバ，
２０２・・・マウスドライバ，
２０３・・・ビデオドライバ，
２０４・・・オーディオドライバ，
２１０・・・ドライバインタフェース，
２２０・・・イベントフィルタ，
２３１・・・制御イベントキュー，
２３２・・・ウィンドウ移動キュー，
２３３・・・ウィンドウ更新キュー，
２３４・・・オーディオサンプルキュー，
２４１〜２４４・・・レギュレータ，
２５０・・・デスクトップストリーミングエンジン，
３０１、３０２・・・インタフェース，
３０５・・・共通アプリケーションプログラムインタフェース，
２５０・・・デスクトップストリーミングエンジン，
４１０・・・ウィンドウ更新分化器，
４２１・・・グラフィックスウィンドウ更新キュー，
４２２，４２３・・・ビデオウィンドウ更新キュー，
４３１〜４３３・・・レギュレータ，
５１０・・・スケジューラ，
５２０・・・クライアントイベント受信器，
５３０・・・モニタ，
５４０・・・転送エンジン，
５５０・・・エンコーダ，
５６０・・・シンクロナイザ，
５７０・・・通信マネージャ，
５７１〜５７３・・・チャネル，
５８０・・・レギュレータ，
５９０・・・キュー，
６１０・・・エージェント，
６２０・・・処理エンジン，
６２２・・・デコーダ，
６３０・・・モニタ，
６４０・・・ドライバインタフェース，
６５０・・・クライアントイベントプロセッサ，
６６１・・・キーボードドライバ，
６６２・・・マウスドライバ，
６６３・・・ビデオドライバ，
６６４・・・オーディオドライバ，
【特許請求の範囲】
【請求項１】
イベントをサーバからリモートクライアントに転送する方法（７００）であって、
イベントを、ドライバから受け取ることと（７１０）、
前記イベントを、イベントタイプに従って、イベントキューに送ること（７２０）と、
前記イベントを、前記イベントタイプに従って処理すること（７３０）であって、前記イベントが、マルチメディアデータを含むときには、前記イベントをエンコードすることと
を含む処理すること（７３０）と、
トリガされたときに、前記イベントを、前記イベントタイプに対応するプロトコルに従って、前記リモートクライアントに転送することと（７４０）
を含む方法。
【請求項２】
前記イベントは、キーボードイベント、マウスイベント、ビデオイベントまたはオーディオイベントであり、
前記ドライバは、キーボードドライバ、マウスドライバ、ビデオドライバまたはオーディオドライバである
請求項１記載の方法。
【請求項３】
前記プロトコルは、
キーボードイベント、マウスイベントおよびグラフィックスイベントの場合は、伝送制御プロトコル（ＴＣＰ）であり、
ビデオイベントおよびオーディオイベントの場合は、リアルタイムプロトコル（ＲＴＰ）である
請求項２記載の方法。
【請求項４】
前記送ることは、
前記イベントをフィルタリングし、前記イベントタイプを識別すること（７２０）
を含む
請求項１記載の方法。
【請求項５】
前記マルチメディアデータを処理することは、
前記エンコード中に、前記マルチメディアデータのオーディオ部分および関連するメディア部分を同期させること（７３０）
をさらに含み、
前記関連するメディア部分は、テキスト、グラフィックスおよびビデオからなる群から選択される
請求項１記載の方法。
【請求項６】
前記転送することは、タイマによってトリガされる
請求項１記載の方法。
【請求項７】
前記転送することは、前記イベントキュー内のイベントの数が、しきい値に達したときにトリガされる
請求項１記載の方法。
【請求項８】
前記リモートクライアントから、イベントを受け取ること（５２０）
をさらに含む請求項１記載の方法。
【請求項９】
イベントをリモートクライアントに転送するシステム（１１０）であって、
異なるタイプのイベントを、複数のドライバ（２０１〜２０４）から受け取るドライバインタフェース（２１０）と、
前記ドライバインタフェースに結合されたイベントフィルタ（２２０）であって、イベントタイプによってイベントを識別し、前記イベントを、前記イベントタイプに従ってイベントキュー（２３１〜２３４、４２１〜４２３）に入れるイベントフィルタ（２２０）と、
前記イベントキューに結合されたレギュレータ（２４１〜２４４、４３１〜４３３）であって、前記イベントが、マルチメディアを含むときには、前記イベントを、前記イベントキューから、前記イベントをエンコードする処理エンジンに促すレギュレータ（２４１〜２４４、４３１〜４３３）と、
前記処理エンジンに結合されたチャネル（１００）であって、前記イベントタイプに対応するプロトコルに従って、前記イベントを前記リモートクライアントに転送するチャネル（１００）と
を備えたシステム。
【請求項１０】
イベントをリモートサーバから受け取るシステム（１２０）であって、
異なるタイプのイベントを、前記リモートサーバから受け取るために使用される複数のチャネルを管理するエージェント（６１０）であって、各チャネルは複数の異なるプロトコルのうちの１つに関連し、前記チャネルのうちの１つは、マルチメディアデータをストリーミングするエージェント（６１０）と、
前記チャネルに結合された処理エンジン（６２０）であって、前記イベントがエンコードされたマルチメディアデータを含むときに、イベントをデコードする処理エンジン（６２０）と、
前記処理エンジンに結合されたドライバインタフェース（６４０）であって、前記イベントを、イベントタイプに従って、オーディオドライバおよびビデオドライバに転送し、前記イベントは、表示装置に表示することが可能であるドライバインタフェース（６４０）と
を備えたシステム。
【請求項１】
イベントをサーバからリモートクライアントに転送する方法（７００）であって、
イベントを、ドライバから受け取ることと（７１０）、
前記イベントを、イベントタイプに従って、イベントキューに送ること（７２０）と、
前記イベントを、前記イベントタイプに従って処理すること（７３０）であって、前記イベントが、マルチメディアデータを含むときには、前記イベントをエンコードすることと
を含む処理すること（７３０）と、
トリガされたときに、前記イベントを、前記イベントタイプに対応するプロトコルに従って、前記リモートクライアントに転送することと（７４０）
を含む方法。
【請求項２】
前記イベントは、キーボードイベント、マウスイベント、ビデオイベントまたはオーディオイベントであり、
前記ドライバは、キーボードドライバ、マウスドライバ、ビデオドライバまたはオーディオドライバである
請求項１記載の方法。
【請求項３】
前記プロトコルは、
キーボードイベント、マウスイベントおよびグラフィックスイベントの場合は、伝送制御プロトコル（ＴＣＰ）であり、
ビデオイベントおよびオーディオイベントの場合は、リアルタイムプロトコル（ＲＴＰ）である
請求項２記載の方法。
【請求項４】
前記送ることは、
前記イベントをフィルタリングし、前記イベントタイプを識別すること（７２０）
を含む
請求項１記載の方法。
【請求項５】
前記マルチメディアデータを処理することは、
前記エンコード中に、前記マルチメディアデータのオーディオ部分および関連するメディア部分を同期させること（７３０）
をさらに含み、
前記関連するメディア部分は、テキスト、グラフィックスおよびビデオからなる群から選択される
請求項１記載の方法。
【請求項６】
前記転送することは、タイマによってトリガされる
請求項１記載の方法。
【請求項７】
前記転送することは、前記イベントキュー内のイベントの数が、しきい値に達したときにトリガされる
請求項１記載の方法。
【請求項８】
前記リモートクライアントから、イベントを受け取ること（５２０）
をさらに含む請求項１記載の方法。
【請求項９】
イベントをリモートクライアントに転送するシステム（１１０）であって、
異なるタイプのイベントを、複数のドライバ（２０１〜２０４）から受け取るドライバインタフェース（２１０）と、
前記ドライバインタフェースに結合されたイベントフィルタ（２２０）であって、イベントタイプによってイベントを識別し、前記イベントを、前記イベントタイプに従ってイベントキュー（２３１〜２３４、４２１〜４２３）に入れるイベントフィルタ（２２０）と、
前記イベントキューに結合されたレギュレータ（２４１〜２４４、４３１〜４３３）であって、前記イベントが、マルチメディアを含むときには、前記イベントを、前記イベントキューから、前記イベントをエンコードする処理エンジンに促すレギュレータ（２４１〜２４４、４３１〜４３３）と、
前記処理エンジンに結合されたチャネル（１００）であって、前記イベントタイプに対応するプロトコルに従って、前記イベントを前記リモートクライアントに転送するチャネル（１００）と
を備えたシステム。
【請求項１０】
イベントをリモートサーバから受け取るシステム（１２０）であって、
異なるタイプのイベントを、前記リモートサーバから受け取るために使用される複数のチャネルを管理するエージェント（６１０）であって、各チャネルは複数の異なるプロトコルのうちの１つに関連し、前記チャネルのうちの１つは、マルチメディアデータをストリーミングするエージェント（６１０）と、
前記チャネルに結合された処理エンジン（６２０）であって、前記イベントがエンコードされたマルチメディアデータを含むときに、イベントをデコードする処理エンジン（６２０）と、
前記処理エンジンに結合されたドライバインタフェース（６４０）であって、前記イベントを、イベントタイプに従って、オーディオドライバおよびビデオドライバに転送し、前記イベントは、表示装置に表示することが可能であるドライバインタフェース（６４０）と
を備えたシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００６−５１４３５３（Ｐ２００６−５１４３５３Ａ）
【公表日】平成１８年４月２７日（２００６．４．２７）
【国際特許分類】
【出願番号】特願２００４−５５７１８２（Ｐ２００４−５５７１８２）
【出願日】平成１５年１１月７日（２００３．１１．７）
【国際出願番号】ＰＣＴ／ＵＳ２００３／０３５８２１
【国際公開番号】ＷＯ２００４／０５１９６２
【国際公開日】平成１６年６月１７日（２００４．６．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
Ｌｉｎｕｘ
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公表日】平成１８年４月２７日（２００６．４．２７）
【国際特許分類】
【出願日】平成１５年１１月７日（２００３．１１．７）
【国際出願番号】ＰＣＴ／ＵＳ２００３／０３５８２１
【国際公開番号】ＷＯ２００４／０５１９６２
【国際公開日】平成１６年６月１７日（２００４．６．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
Ｌｉｎｕｘ
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]