(57)【要約】  本発明は、一般的に、データをソースからモニタへ無線でリアルタイムで送信するための方法及びシステムに関する。本発明は、更に、一般的に、無線デバイスの実質的な自動構成に関する。例示の実施の形態において、本発明は、ビデオ及び音声データをソースからキャプチャし、このデータを無線送信する方法であり、データを再生するステップ、ミラーディスプレイドライバを利用して当該ビデオデータをキャプチャするステップ、入力ソースから当該音声データをキャプチャするステップ、キャプチャされた音声及びビデオデータを圧縮するステップ、及び、圧縮された音声及びビデオデータを送信機を利用して送信するステップからなる。  【選択図】      図５
2008539614.tif 000002
【特許請求の範囲】
【請求項１】
ソースからメディアをキャプチャし、前記メディアを無線で送信する方法において、
計算デバイス上に、少なくとも音声データ及びビデオデータからなる前記メディアを再生するステップ、
ミラーディスプレイドライバを利用して前記ビデオデータをキャプチャするステップ、
入力ソースから前記音声データをキャプチャするステップ、
前記キャプチャされた音声及びビデオデータを圧縮するステップ、及び、
送信機を利用して前記圧縮された音声及びビデオデータを送信するステップ
からなることを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項２】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記メディアを受信機で受信し、前記キャプチャされた音声及びビデオデータを解凍し、及び、前記解凍された音声及びビデオデータを、前記ソースからリモートのディスプレイ上に再生するステップと
からなることを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項３】
請求項２に記載のメディアのキャプチャ及び無線送信方法において、
前記送信機及び受信機は、ＴＣＰを利用して接続を確立し、前記送信機は、ＵＤＰを利用してビデオデータのパケットを送信する
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項４】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記メディアは、更に、グラフィック及びテキストデータからなり、及び、
前記グラフィック及びテキストデータは、ミラーディスプレイドライバを利用して前記ビデオデータと一緒にキャプチャされる
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項５】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記ビデオデータをＣＯＤＥＣを利用して処理するステップ
からなることを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項６】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記ＣＯＤＥＣは、動き推定ブロックを利用して、前記ビデオデータから、時間冗長性を取り除く
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項７】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記ＣＯＤＥＣは、ＤＣＴブロックを利用して、ビデオデータのフレームを、８＊８ブロックのピクセルに変換する
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項８】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記ＣＯＤＥＣは、ＶＬＣコーディング回路を利用して、ビデオコンテンツを短いワードに符号化する
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項９】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記ＣＯＤＥＣは、ＩＤＣＴブロックを利用して、前記ビデオデータの空間周波数をピクセルドメインに戻して変換する
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項１０】
請求項１に記載のメディアのキャプチャ及び無線送信方法において、
前記ＣＯＤＥＣは、メディア送信の速度向上用に、レート制御メカニズムからなる
ことを特徴とするメディアのキャプチャ及び無線送信方法。
【請求項１１】
少なくともビデオデータからなるメディアをソースからキャプチャし、前記メディアを無線送信するためのもので、コンピュータ読取可能な基板上に格納されたプログラムは、
前記ビデオデータをキャプチャするためにカーネルモードで動作するミラーディスプレイドライバ、
前記ビデオデータを処理するためのＣＯＤＥＣ、及び、
前記処理されたビデオデータを送信するための送信機
からなることを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１２】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
バーチャルディスプレイドライバ
からなることを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１３】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記送信機は、受信機との接続をＴＣＰを利用して確立し、前記送信機は、ビデオデータのパケットをＵＤＰを利用して送信する
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１４】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記メディアは、更に、グラフィック及びテキストデータからなり、
前記ミラーディスプレイドライバは、グラフィック及びテキストデータを前記ビデオデータと一緒にキャプチャする
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１５】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記ＣＯＤＥＣは、前記ビデオデータから時間冗長性を取り除くための、動き推定ブロックからなる
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１６】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記ＣＯＤＥＣは、ビデオデータのフレームを８＊８ブロックのピクセルに変換するためのＤＣＴブロックからなる
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１７】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記ＣＯＤＥＣは、ビデオコンテンツを短いワードに符号化するために、ＶＬＣコーディング回路からなる
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１８】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記ＣＯＤＥＣは、前記ビデオデータの空間周波数をピクセルドメインに戻して変換するために、ＩＤＣＴブロックからなる
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【請求項１９】
請求項１に記載のメディアのキャプチャ及び無線送信用のプログラムにおいて、
前記ＣＯＤＥＣは、メディア送信の速度向上用に、レート制御メカニズムからなる
ことを特徴とするメディアのキャプチャ及び無線送信用のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、一般的に、ソースからモニタへデータを無線及びリアルタイムで送信する方法及びシステムに関する。また、本発明は、一般に、無線デバイスの実質的な自動構成に関する。
【背景技術】
【０００２】
発明の背景
個人は、限定されないが、グラフィック、テキスト、ビデオ、イメージ、及び、音声を含むメディアの格納、記録、送信、受信、及び再生に、パーソナルコンピュータ、ストレージデバイス、モバイル電話機、パーソナルデータアシスタント、及びサーバを含む計算デバイスを利用する。そのようなメディアは、限定されないが、インターネット、ＣＤ、ＤＶＤ、他のネットワーク、又は、他の記録デバイスを含むたくさんのソースから取得されることが可能である。
【０００３】
特に、個人は、時間、地理、価格、コンテンツのレンジ、他の制限を常に受けないで、オープンネットワークを通してメディアを迅速及び大量に分散し、それにアクセスすることが可能である。しかしながら、個人は、常に、１名、２名を上回る人数の観客に適さない小さな画面上に、取得したメディアを表示することを余儀なくされる。
【０００４】
メディアを格納、記録、送信、受信、及び、再生する計算デバイスの利用の急成長及びフレキシビリティにもかかわらず、世界全体の圧倒的多数の人間は、テレビを、音声／ビデオ送信を受信する基本手段としてまだ使っている。特に、大気、衛星、及び、ケーブルを媒体したテレビへの送信は、個人への連絡、及び、個人が体験する音声／ビデオメディアの主要手段を今なお代表している。しかし、これらの送信は、コスト、コンテンツのレンジ、アクセス時間、及び、地理によって、非常に制限されている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
メディアの格納、記録、送信、受信、及び再生に利用されている個別計算デバイスのユビキティを考えると、メディアを迅速及び柔軟に取得し、そのメディアの体験に各自のテレビを利用することを個人に可能にするためには、非常に広く普及しているテレビの基盤と連動して同じ計算デバイスが利用できることが好ましい。
【０００６】
計算デバイスをテレビと統合可能にする従来の試みは、ａ）テレビを、インターネットに直接アクセスしてメディアを取得するネットワーク化された計算家電に変換し、ｂ）計算デバイスからメディアを受信し、これを格納し、かつ、無線接続を通して、テレビへ転送する専用ハードウェアデバイスを作り出し、及び／又は、ｃ）メモリスティック等のストレージデバイスを許可する手段をテレビへ統合する、ことに集中している。しかしながら、これらの従来のアプローチは、既存の計算デバイス及び／若しくはテレビの取り替え等の既存機器の実質的な修正、又は、高価な新しいハードウェアの購入に悩まされている。
【０００７】
追加して、両方のアプローチは、一般に、複数の物理的な配線接続を利用して、グラフィック、テキスト、音声及びビデオを送信することを要求する。そのような物理接続は、デバイスの利用を一台のテレビに限定し、機器の取替えを家庭内の特定エリアに限定し、及び、見苦しい配線網の結果をもたらす。最後に、メディアをメモリスティック等の格納要素に物理的に格納してからテレビに入力する要求は、使いにくくて、柔軟ではないだけではなく、転送できるデータ量を大きく制限する。
【０００８】
個人が既存の計算デバイスを利用してメディアを受信、送信、格納、及び、再生し、既存のテレビを利用してメディアを体験することを可能にする方法、デバイス、及びシステムの必要性が求められている。また、メディアを計算デバイスからテレビへ容易に低価格で無線送信し、よって、テレビをリモートモニタに変える必要性も求められている。テキスト、グラフィック、ビデオ、及び音声の送信に応用可能な数々の異なる規格が、シングル、ユニバーサルの無線メディア送信システムによって運用されることが更に望ましい。最後に、使い易さの面で、無線デバイスの構成を自動化する必要性がある。
【課題を解決するための手段】
【０００９】
発明の要約
本発明は、一般的に、ソースからモニタへデータを無線及びリアルタイムで送信するための方法及びシステムに関する。本発明は、更に、一般的に、無線デバイスの実質的な自動構成に関する。
【００１０】
一つの実施の形態において、本発明は、メディアをソースからキャプチャし、前記メディアを無線送信する方法であり、この方法は、
少なくとも音声データ及びビデオデータからなる前記メディアを計算デバイス上に再生するステップ、
前記ビデオデータをミラーディスプレイドライバを利用してキャプチャするステップ、
入力ソースから前記音声データをキャプチャするステップ、
前記キャプチャされた音声及びビデオデータを圧縮するステップ、及び、
前記圧縮された音声及びビデオデータを送信機を利用して送信するステップ
からなる。
【００１１】
オプションとして、この方法は、更に、前記メディアを受信機で受信し、前記キャプチャされた音声及びビデオデータを解凍し、及び、前記解凍された音声及びビデオデータを、前記ソースからリモートされるディスプレイ上に再生するステップからなる。オプションとして、この送信機と受信機は、ＴＣＰを利用して接続確立をし、この送信機は、ＵＤＰを利用してビデオデータを送信する。
【００１２】
オプションとして、メディアは、更に、グラフィック及びテキストデータからなり、このグラフィック及びテキストデータは、前述のビデオデータと一緒にミラーディスプレイドライバを利用してキャプチャされることを特徴とする。オプションとして、この方法は、更に、ＣＯＤＥＣを利用して前述のビデオデータを処理するステップからなる。オプションとして、ＣＯＤＥＣは、ビデオデータから時間冗長性を、動き推定ブロックを利用して、取り除く。
【００１３】
オプションとして、ＣＯＤＥＣは、ＤＣＴ変換ブロックを利用して、ビデオデータのフレームを８＊８ブロック又は４＊４ブロックのピクセルに変換する。オプションとして、ＣＯＤＥＣは、ＶＬＣコーディング回路を利用して、ビデオコンテンツを、短いワードに符号化する。オプションとして、ＣＯＤＥＣは、ＩＤＣＴブロックを利用して、ビデオデータの空間周波数をピクセルドメインに戻して変換する。オプションとして、ＣＯＤＥＣは、メディア送信の高速化用に、レート制御メカニズムからなる。
【００１４】
他の実施の形態において、本発明は、少なくともビデオデータからなるメディアを、ソースからキャプチャし、このメディアを無線送信するために、コンピュータ読取可能な基板に格納されたプログラムからなり、このプログラムは、前述のビデオデータをキャプチャするためにカーネルモードで動作するミラーディスプレイドライバ、前述のビデオデータの処理用のＣＯＤＥＣ、及び、この処理されたビデオデータの送信用の送信機からなる。
【００１５】
オプションとして、プログラムは、更に、バーチャルディスプレイドライバからなる。オプションとして、送信機は、受信機と、ＴＣＰを利用して接続確立をし、及び、送信機は、ＵＤＰを利用して、ビデオデータのパケットを送信する。オプションとして、メディアは、更に、グラフィック及びテキストデータからなり、前述のミラーディスプレイドライバは、グラフィック及びテキストデータを、前述のビデオデータと一緒にキャプチャする。オプションとして、ＣＯＤＥＣは、ビデオデータから時間冗長性を取り除くために、動き推定ブロックからなる。
【００１６】
オプションとして、ＣＯＤＥＣはビデオデータのフレームを８＊８又は４＊４ブロックのピクセルに変換するＤＣＴブロックからなる。オプションとして、ＣＯＤＥＣは、ビデオコンテンツを短いワードに符号化するためのＶＬＣコーディング回路からなる。オプションとして、ＣＯＤＥＣは、ビデオデータの空間周波数をピクセルドメインに戻して変換するためのＩＤＣＴブロックからなる。オプションとして、ＣＯＤＥＣは、メディア送信の速度を向上させるために、レート制御メカニズムからなる。
【００１７】
これらの、及び他の実施の形態は、図面の簡単な説明を参照しながら、詳細な説明の中に、明瞭に説明される。
【発明を実施するための最良の形態】
【００１８】
詳細な説明
本発明は、一つのデバイスから他のデバイスへメディアを無線でリアルタイムで送信するための統合無線システムである。後述の図面を参考して、本発明を説明する。ここで説明される実施の形態は、本発明を、開示された正確な形式へ限定又は制限するものではない。それらは、本発及びその応用を説明するために、及び当業者が本発明を利用することを可能にするために、選択されたものである。
【００１９】
図１に示すように、従来のパーソナルコンピュータ、デスクトップ、ラップトップ、ＰＤＡ、携帯電話器、ゲームステーション、セットトップボックス、衛生受信機、ＤＶＤプレイヤ、パーソナルビデオ録画機、又は、本発明の新規システムで動作する他のデバイス等の計算デバイス１０１は、無線ネットワーク１０２を通してリモートモニタ１０３と通信する。計算デバイス１０１とリモートモニタ１０３は、更に、複数の規格でエンコードされたグラフィック、音声、テキスト、及びビデオを無線で送受信できる処理システムオンチップからなることが好ましい。
【００２０】
リモートモニタ１０３は、グラフィック、音声、及びビデオをレンダリングできる、周知のテレビ、プラズマディスプレイデバイス、フラットパネルＬＣＤ、ＨＤＤ、プロジェクタ、又は、周知の任意の他の電子ディスプレイデバイスであることができる。処理システムオンチップは、リモートモニタ１０３と計算デバイス１０１へ統合されたもの、又は、リモートモニタ１０３又は計算デバイス１０１と有線通信しているスタンドアローンデバイスへ組み込まれたものであることができる。例示の処理システムオンチップは、本出願の所有者に譲渡された出願ＰＣＴ／ＵＳ２００６／００６２２に記載され、参照することによりここに組み込まれている。
【００２１】
図２には、本発明の計算デバイス２００が図示されている。計算デバイス２００は、本発明の新規ソフトウェアシステム２０２を実行できるオペレーティングシステム２０１と、送受信機２０３からなっている。オペレーティングシステム２０１は、限定されないが、MS Windows 2000（登録商標）、MS Windows NT（登録商標）、MS Windows XP（登録商標）、Linux（登録商標）、OS/2（登録商標）、Palm（登録商標）ベースのオペレーティングシステム、セルフォーンオペレーティングシステム、iPOD（登録商標）オペレーティングシステム、及びMAC  OS（登録商標）を含む任意のオペレーティングシステムであることができる。
【００２２】
計算デバイス２００は、グラフィック、テキスト、ビデオ、及び音声信号の伝送用に、例えば、特に、IEEE 802.11a、802.11g、Bluetooth2.0、HomeRF 2.0、HiperLAN/2、及びUltra Wideband、そして、これらの規格の任意の独自仕様の適当な無線規格を利用して、メディアを送信する。
【００２３】
図３には、本発明の新規ソフトウェアシステムのモジュール３００を図示している。ソフトウェア３００は、メディアのリアルタイムキャプチャ用のモジュール３０１、キャプチャされたメディアの格納用のバッファをマネージするためのモジュール３０２、メディアの圧縮、解凍用のＣＯＤＥＣ３０３、及び、処理されたメディアを伝送用にパッケージ化するモジュール３０４からなる。
【００２４】
一つの実施の形態において、インターネットからダウンロードされた、インターネットからリアルタイムでストリーム送信された、ケーブルまたは衛星局から送信された、ストレージデバイスから転送された、又は他のソースにかかわらず、計算デバイスは、ソースからメディアを受信する。メディアは、計算デバイス上にインストールされた適当なプレイヤを介して、計算デバイス上に再生される。メディアが計算デバイス上に再生されるとき、ソフトウェアモジュール３０１は、データをリアルタイムでキャプチャし、ＣＯＤＥＣに送信する前にバッファに一時的に格納する。ＣＯＤＥＣ３０３は、これを圧縮し、送信用に準備する。
【００２５】
図４には、本発明の受信機を図示している。受信機４０４は、送受信機４０１、ＣＯＤＥＣ４０２、ビデオとグラフィックデータのレンダリング用の表示デバイス４０３、及び、音声データのレンダリング用の音声デバイス４０４からなる。送受信機４０１は、好ましくは、本発明に利用された新規の送信プロトコルを通して、圧縮されたメディアデータを受信する。一つの例において、この新規送信プロトコルは、ＴＣＰ／ＵＤＰハイブリッドプロトコルである。
【００２６】
パケットのリアルタイム送信用のＴＣＰ／ＵＤＰハイブリッドプロトコルは、ＴＣＰのセキュリティサービスを、ＵＤＰの簡易及び低処理要求に、結合する。コンテンツは、受信機によって受信され、そして、ＣＯＤＥＣ４０２へ解凍用に送信される。ＣＯＤＥＣは、メディアを解凍し、レンダリング用に表示デバイス４０３とスピーカ４０４へ送信されるビデオと音声信号を用意する。
【００２７】
図５に示すように、フローチャートは、本発明の統合無線システムの例示の動作を図示している。パーソナルコンピュータは、メディアをこれのコンソール上の適当なメディアプレイヤを利用して再生する（ステップ５０１）。そのようなメディアプレイヤは、Apple (iPod)（登録商標）、RealNetworks(RealPlayer)（登録商標）、Microsoft (Windows Media Player)（登録商標）からのプレイヤ、又は他の任意のメディアプレイヤを含むことができる。
【００２８】
本発明のソフトウェアは、リアルタイムビデオをビデオバッファから直接キャプチャする（ステップ５０２）。そして、キャプチャされたビデオは、ＣＯＤＥＣを利用して、圧縮される（ステップ５０３）。同様に、音声は、計算デバイス上に動作する音声ソフトウェアを利用してキャプチャされ（ステップ５０４）、ＣＯＤＥＣを利用して圧縮される。
【００２９】
一つの実施の形態において、本発明のソフトウェアは、ビデオを、ミラーディスプレイドライバとバーチャルビデオドライバからなるソフトウェアモジュールの実行を通してキャプチャする。一つの実施の形態において、このミラーディスプレイドライバとバーチャルディスプレイドライバは、コンピュータ上に実行し、本発明のソフトウェアをホストするオペレーティングシステムのカーネルモードのコンポネントとしてインストールされる。
【００３０】
バーチャルデバイス用のミラーディスプレイドライバは、物理ディスプレイデバイスドライバの動作をミラーすることによって、物理ディスプレイデバイスドライバの動作をミラーする。一つの実施の形態において、「拡張ディスクトップ」又はコンピュータと連携された第２ディスプレイデバイスのコンテンツのキャプチャに、バーチャルディスプレイドライバが利用されると同時に、ミラーディスプレイドライバは、コンピュータと連携されたプライマリディスプレイのコンテンツのキャプチャに利用される。
【００３１】
使用中、オペレーティングシステムは、グラフィックとビデオコンテンツを、バーチャルディスプレイドライバとミラーディスプレイドライバのビデオメモリ上にレンダーリングする。従って、例えば、メディアプレイヤを利用してコンピュータによって再生されている任意のメディアも、これらのドライバの１つの上にレンダーリングされる。本発明のソフトウェアのアプリケーションコンポネントは、バーチャルディスプレイドライバ及びミラーディスプレイドライバのビデオメモリを、アプリケーション空間にマップする。
【００３２】
このように、本発明のアプリケーションは、ビデオメモリへのポインターを取得する。本発明のアプリケーションは、マップされたビデオメモリからローカルに割り当てられたメモリへメモリをコピーすることで、ディスプレイに映されたリアルタイムイメージ（及び、従って、表示されているリアルタイムグラフィック又はビデオコンテンツ）をキャプチャする。
【００３３】
一つの実施の形態において、ミラーディスプレイドライバ及びバーチャルディスプレイドライバは、Windows 2000/NT互換性のオペレーティングシステム等のMicrosoftオペレーティングシステムのカーネル空間に動作する。図１７に示すように、ディスプレイドライバ開発用のMicrosoft Windowsフレームワーク１７００が図示されている。コンピュータ上に実行しているアプリケーション１７０１は、Ｗｉｎ３２  ＧＤＩ(Graphics Display Interface)1702と呼ばれるグラフィックディスプレイインターフェースへコールを発行する。
【００３４】
ＧＤＩ１７０２は、グラフィック出力要求を発行する。これらの要求は、カーネルモードＧＤＩ１７０５を含め、カーネル空間内に動作しているソフトウェアへルートされる。カーネルモードＧＤＩ１７０５は、カーネルモードグラフィックドライバ１７０６とアプリケーション１７０１の間を中間サポートする。カーネルモードＧＤＩ１７０５は、これらの要求を、ディスプレイドライバ１７０６又はプリンタドライバ（図示せず。）等の適当なミニポート１７０９又はグラフィックドライバへ送信する。
【００３５】
各ディスプレイドライバ（ＤＤＩ）に対応するビデオミニポート１７０９がある。ミニポートドライバ１７０９は、一つのグラフィックアダプタ（又はアダプタのファミリ）用に書かれている。ディスプレイドライバ１７０６は、共通描画インターフェースを共有する任意の数のアダプタ用に書かれることができる。
【００３６】
これは、ミニポートドライバがモード設定等の動作を行ない、ハードウェア情報をドライバへ提供する間に、ディスプレイドライバが描画するためのである。１以上のディスプレイドライバは、特定のミニポートドライバを使って動作することも可能である。このアーキテクチャのアクティブコンポネントは、Ｗｉｎ３２−ＧＤＩプロセス１７０２とアプリケーション１７０１である。残りのコンポネント１７０５〜１７１０は、Ｗｉｎ３２−ＧＤＩプロセス１７０２から呼び出される。
【００３７】
ビデオミニポートドライバ１７０９は、一般的に、他のカーネルコンポネント１７０３と相互作用する動作を扱う。例えば、ハードウェア初期化やメモリマッピング等の動作は、NT I/Oサブシステムによるアクションを要求する。ビデオミニポートドライバ１７０９の責任範囲は、ハードウェア構成、及び物理デバイスメモリマッピング等のソースマネジメントを含む。ビデオミニポートドライバ１７０９は、ビデオハードウェア専用のものである。
【００３８】
ディスプレイドライバ１７０６は、高頻度で要求されない動作、例えば、リソース管理、物理デバイスメモリマッピング、レジスタ出力が近い間隔で起きないことの保証、又は割り込みへの応答、には、ビデオミニポートドライバ１７０９を利用する。ビデオミニポートドライバ１７０９は、複数のハードウェア種類（ディスプレイドライバ内のハードウェア種依存性を最小化）のグラフィックカードとの相互作用でのモード設定、及び、ディスプレイドライバ１７０６のアドレス空間へのビデオレジスタのマッピングもハンドルする。
【００３９】
ミニポートへ書き込むために、ドライバライターが実行しなければならない特定機能がある。これらの機能は、ミニポートが相互作用するビデオポートに出力される。ミニポートにおいて、ドライバライターは、ビデオカード上のビデオメモリとレジスタの絶対アドレスを特定する。これらのアドレスは、最初は、バス相対的アドレスに変換され、そして、コールプロセスのアドレス空間内のバーチャルアドレスに変換される。
【００４０】
ディスプレイドライバ１７０６の主な仕事は、レンダーリングである。アプリケーションがデバイス・インデペンデント・グラフィック要求と一緒にＷｉｎ３２機能をコールするとき、グラフィック・デバイス・インターフェース（ＧＤＩ）１７０５は、これらの命令を翻訳し、ディスプレイドライバ１７０６をコールする。ディスプレイドライバ１７０６は、そして、これらの要求を、ビデオハードウェア用のコマンドに翻訳し、スクリーン上にグラフィックを図示する。
【００４１】
ディスプレイドライバ１７０６は、ハードウェアに直接アクセスできる。デフォルトでは、ＧＤＩ１７０５は、フレームバッファを含むハードウェア等の上に、標準フォーマットビットマップの描画動作をハンドルする。ディスプレイドライバ１７０６は、ハードウェアが特定サポートのオファー用の任意の描画機能をフックでき、及び実装できる。グラフィックアダプタによってサポートされていない少ないタイムクリティカルな動作ともっと複雑な動作用に、ドライバ１７０６は、機能をＧＤＩ１７０５へ戻してプッシュでき、ＧＤＩ１７０５が動作をすることを許可する。
【００４２】
特に、タイムクリティカルな動作のために、ディスプレイドライバ１７０６は、ビデオハードウェアレジスタへの直接アクセスを備えている。例えば、一部の図示及びテキスト動作用に、ｘ８６システム用のＶＧＡディスプレイドライバは、ハードウェアレジスタへの直接アクセスの実行に、最適化されたアセンブリコードを利用する。
【００４３】
レンダーリングは別として、ディスプレイドライバ１７０６は、サーフェースマネジメント及びパレットマネジメント等の他のオペレーションを行なう。図１８に示すように、ＧＤＩとディスプレイドライバの間の複数の入力と出力を図示している。一つの実施の形態において、ＧＤＩ１８０１は、DrvEnableDriverコマンド１８１０をディスプレイドライバ１８０２へ発行する。そして、ＧＤＩ１８０１は、DrvEnablePDEVコマンド１８１１をディスプレイドライバ１８０２へ発行する。
【００４４】
そして、ＧＤＩ１８０１は、ディスプレイドライバ１８０２からEngCreatePaletteコマンド１８１２を受信する。そして、ＧＤＩ１８０１は、ディスプレイドライバ１８０２へDrvCompletePDEVコマンド１８１３を発行する。そして、ＧＤＩ１８０１は、ディスプレイドライバ１８０２へDrvEnableSurfaceコマンド１８１４を発行する。そして、ＧＤＩ１８０１は、ディスプレイドライバ１８０２からEngCreateDeviceSurfaceコマンド１８１５を受信し、ディスプレイドライバ１８０２からEngModifySurfaceコマンド１８１６を受信する。
【００４５】
図１９に示すように、グラフィック生成システム用のソフトウェアアーキテクチャを図示している。ソフトウェアアーキテクチャ１９００は、次のコンポネントを含むMicrosoftのDirectDraw（登録商標）を表す。
１．ユーザモードDirectDraw。これは、ロードされ、DirectDrawアプリケーションから呼び出されるものである。このコンポネントは、様々なDirectDrawオブジェクトをマネージするハードウェアエミュレーションを提供し、及び、ディスプレイメモリとディスプレイ・ハードウェア・マネジメント・サービスを提供する。
【００４６】
２．カーネルモードDirectDraw。これは、カーネルモードディスプレイドライバによってロードされるシステム提供のグラフィックエンジンである。DirectDrawのこの部分は、ドライバ用のパラーメータの検証を行ない、もっとロバストなドライバを実装することを容易にする。カーネルモードDirectDrawは、ＧＤＩとの同期化、及び、全てのクロスプロセスステートもハンドルする。
【００４７】
３．ディスプレイドライバのDirectDraw部分。これは、残りのディスプレイドライバと一緒に、グラフィックカードハードウェアベンダーによって実装されている。ディスプレイドライバの他の部分は、ＧＤＩと他の非DirectDraw関連コールをハンドルする。
【００４８】
DirectDraw１９００は読み出されたら、DirectDrawドライバ１９０２を通してグラフィックカードに直接アクセスする。DirectDraw１９００は、サポートされたハードウェア機能用にDirectDrawドライバ１９０２をコールし、又はソフトウェア内にエミュレートされなければならない機能用に、ハードウェアエミュレーションレイヤ（ＨＥＬ）１９０３をコールする。ＧＤＩ１９０５コールは、ドライバへ送信される。
【００４９】
初期化及びモード変換中に、ディスプレイドライバは、DirectDraw１９００へキャパビリティビットを返す。これは、使用可能なドライバ機能、それらのアドレス、及びディスプレイカードとドライバの性能（伸ばし、トランスペアレントビット、ディスプレイピッチ、及び他の詳細な特徴等）についての情報へDirectDraw１９００がアクセスすることを可能にする。
【００５０】
DirectDraw１９００がいったんこの情報を持つと、ＧＤＩコールをしないで又はディスプレイドライバのＧＤＩ特定部分を利用しないで、ディスプレイカードへの直接アクセスにDirectDrawドライバを利用できる。アプリケーションからビデオバッファへ直接アクセスするために、ビデオメモリを、コール処理のバーチャルアドレス空間へ、マップすることが必要である。
【００５１】
一つの実施の形態において、バーチャルディスプレイドライバとミラーディスプレイドライバは、通常のディスプレイドライバのアーキテクチャに由来し、ミニポートドライバ及び対応ディスプレイドライバを含む。従来のディスプレイドライバには、ＰＣＩバス又はＡＧＰスロットにアタッチされた物理デバイスがある。ビデオメモリとレジスタは、ＧＤＩプロセスのアドレス空間にマップされた、又は、DirectDrawを利用してアプリケーションをキャプチャしている、ビデオカード上に物理的に表される。
【００５２】
しかし、本実施の形態において、物理ビデオメモリがない。オペレーティングシステムは、物理デバイスの存在（バーチャルデバイスと言う。）、及び、ビデオメモリとレジスタを表すもので、メインメモリ内の割り当てられたそのメモリに責任を負う。本発明のミニポートがロードされたとき、２．５MBのようなメモリのチャンクは、非ページ化プールメモリから予約される。このメモリは、ビデオメモリとしての役割をする。
【００５３】
このメモリは、そして、ＧＤＩプロセス（グラフィックの場合は、アプリケーションはオペレーションを描画する。）のバーチャルアドレス空間内にマップされる。本発明のディスプレイドライバは、メモリへのポインタを要求し、ミニポートは、ＲＡＭ内に予約されたビデオメモリへポインタを返す。従って、ビデオメモリがＲＡＭ上に又はビデオカード上にあるかが、ＧＤＩ及びディスプレイデバイスインターフェース（ＤＤＩ）（又はDirectDrawの場合は、アプリケーション）にとってトランスペアレントである。
【００５４】
ＤＤＩ又はＧＤＩは、このメモリロケーション上にレンダーリングを行なう。また、本発明のミニポートは、オーバーレイ用に別途のメモリを割り当てる。Power DVD、Win DVD等のような特定アプリケーションとビデオ再生ソフトは、ビデオレンダーリング用にオーバーレイメモリを利用する。
【００５５】
一つの従来の実施の形態において、レンダーリングは、ＤＤＩとＧＤＩによって行なわれる。ＤＤＩがデバイス特有の動作を行うと共に、ＧＤＩは、一般デバイス・インデペンデント・レンダーリング動作を提供する。ディスプレイアーキテクチャは、ＧＤＩをＤＤＩの上の層にし、ＤＤＩが権限をＧＤＩへ移すという便利さを提供する。本発明の一つの実施の形態において、物理デバイスが無いので、デバイス特有の動作は無い。
【００５６】
従って、本発明のディスプレイドライバは、レンダーリング動作をＧＤＩへ移す。ＤＤＩは、ビデオメモリポインタを有するＧＤＩを提供し、ＧＤＩは、Ｗｉｎ３２  ＧＤＩプロセスからの受信した要求に基いて、レンダーリングを行なう。同様に、本発明がDirectDrawと互換性がある場合は、レンダーリング動作は、ＤＤＩによってＨＥＬ（Hardware Emulation Layer）へ移される。
【００５７】
一つの実施の形態において、本発明は、ロードされたとき、自身をプライマリディスプレイドライバへアタッチするミラードライバからなる。従って、プライマリディスプレイドライバへの全てのレンダーリングコールは、ミラードライバへルートされ、プライマリディスプレイドライバのビデオメモリ上にレンダーリングされたいかなるデータは、ミラードライバのビデオメモリ上にレンダーリングされる。このように、ミラードライバは、コンピュータディスプレイの複製用に利用される。
【００５８】
一つの実施の形態において、本発明は、ロードされたとき、拡張バーチャルドライバとして動作するバーチャルドライバからなる。バーチャルドライバがインストールされたとき、コンピュータのディスプレイプロパティ内の第２のドライバとして表れ、ユーザは、このディスプレイドライバへこのディスプレイを拡張するオプションをオンにする。
【００５９】
一つの実施の形態において、ミラードライバとバーチャルドライバは、次の解像度をサポートする。６４０＊４８０、８００＊６００、１０２４＊７６８、及び１２８０＊１０２４。これらの解像度それぞれのために、ドライバは、８、１６、２４、３２ビットのカラーの深み、及び６０と７５Ｈｚのリフレッシュレートをサポートする。オーバーレイサーフェース上のレンダーリングは、ＹＵＶ４２０フォーマットでされる。
【００６０】
一つの実施の形態において、ソフトウェアライブラリは、ミラー又はバーチャルデバイスドライバを利用して、コンピュータディスプレイのキャプチャをサポートするのに利用される。このライブラリは、これが初期化されたとき、アプリケーション空間内のミラーとバーチャルデバイスドライバ内に割り当てられたビデオメモリをマップする。キャプチャ機能において、ライブラリは、アプリケーションバッファに、マップされたビデオバッファをコピーする。このように、アプリケーションは、その特有の場合、コンピュータディスプレイのコピーを持つ。
【００６１】
オーバレイサーフェースをキャプチャするために、ライブラリは、ビデオバッファをアプリケーション空間にマップする。追加して、最後にレンダーリングされたオーバーレイサーフェースのアドレスを持つポインタも、アプリケーション空間にマップされる。このポインタは、ドライバ内にアップデートされる。オーバーレイメモリ上のレンダーリングが開始されるとき、ライブラリは、バーチャルディスプレイドライバから通知を取得する。
【００６２】
ディスプレイドライバは、カラーキー値のキャプチャライブラリを知らせる。メインビデオメモリのコピー後、ソフトウェアモジュール、ＣＡＰＩは、ドライバ空間からマップされたポインタを利用してレンダーリングされた最後のオーバーレイサーフェースをコピーする。カラーキー値が存在するメインビデオメモリの長方形の領域上、要求次元へ引き伸ばした後、ＹＵＶからＲＧＢへの変換し、ＲＧＢデータをペーストする。
【００６３】
カラーキー値は、ＧＤＩによってメインビデオメモリ上にペーストされた特別な値であり、オーバーレイでコピーされなければならないデータがレンダーリングされたリージョンを表す。現在のWindows/NTオペレーティングシステムで動作するコンピュータ上の利用において、オーバレイは、拡張バーチャルデバイスドライバのみに応用でき、ミラードライバにはできない。その理由は、ミラードライバがアタッチされているとき、DirectDrawは自動的に無効になる。
【００６４】
ビデオとグラフィックのキャプチャ方法とシステムは、Microsoftオペレーティングシステムに関して詳細に説明されたが、同様なミラーディスプレイドライバとバーチャルディスプレイドライバアプローチが他のオペレーティングシステムで動作しているコンピュータに利用できることは明らかである。
【００６５】
一つの実施の形態において、音声は、従来コンピュータベースのオーディオプレイヤによって利用されるインターフェースを通してキャプチャされ、音声データを再生する。一つの実施の形態において、音声は、Microsoft WindowsとNTオペレーティングシステムと互換性のソフトウェアモジュールであるMicrosoft Windows Multimedia APIを利用してキャプチャされる。Microsoft Windowsマルチメディアライブラリは、アプリケーションへのインターフェースを提供し、waveOutコールを利用して音声デバイス上に音声データを再生する。
【００６６】
同様に、音声デバイスから音声データを録音するインターフェースを提供する。録音デバイス用のソースは、ラインイン、マイクロフォン、又は任意の他の指定ソースであることができる。アプリケーションは、データを録音しようとするとき、フォーマット（サンプリング周波数、サンプルビット）を指示できる。Windows/NT互換性のオペレーティングシステム計算環境内の、音声キャプチャ用の例示のステップは、次の通りである。
【００６７】
１．アプリケーションは、音声デバイスをwavelnOpen()機能を利用してオープンする。これは、録音する音声フォーマット、一度にキャプチャする音声データのサイズ、及び、音声データへの特定サイズが利用可能であるとき、コールするコールバック機能を指示する。
２．アプリケーションは、空の音声バッファの数をwavelnAddBuffer()コールを利用してwindows音声サブシステムへ渡す。
【００６８】
３．アプリケーションはwavelnStart()をコールし、キャプチャの開始を指示する。
４．特定サイズの音声データが利用可能なとき、Windows音声サブシステムは、アプリケーションによって渡された音声データを音声バッファの１つのアプリケーションへ渡して、コールバック機能をコールする。
【００６９】
５．アプリケーションは、音声データをこれのローカルバッファにコピーし、必要であれば、キャプチャを継続し、空の音声バッファをwavelnAddBuffer()を通してWindows音声サブシステムへ渡す。
６．アプリケーションがキャプチャを停止させる必要があるとき、アプリケーションは、wavelnClose()をコールする。
【００７０】
一つの実施の形態において、メディアプレイバックアプリケーションにステレオミックスオプションが選択され、音声が進行中にキャプチャされる。音声デバイスは、一般的に、出力ピンに再生されている音声を入力ピンへ戻して、音声をルートする性能を備えている。異なるシステムに異なる名前が付けられているが、一般に「ステレオミックス」と呼ばれる。
【００７１】
プレイバックオプションにステレオミックスオプションが選択されたら、デフォルト音声デバイスから、wavelnコールを利用して、音声が録音され、そして、システム上の再生されている音声がキャプチャできる等、システム上に再生されるもの全てが録音できる。特定アプローチが、利用されている特定音声デバイスの性能に依存することは明らかであり、上に教えたことに従って音声ストリームをどのようにキャプチャするかは当業者ができる。コンピュータとリモートデバイスからの音声の並列再生を防ぐために、入力ピンへルーティングされている音声をミュートしないで、（コンピュータ上の）ローカル音声がミュートされることも明らかである。
【００７２】
他の実施の形態において、バーチャル音声ケーブル（ＶＡＣ）と呼ばれるバーチャル音声ドライバは、デフォルトの再生及び／又は録音デバイスとして選択できるノーマル音声ドライバとしてインストールされる。ＶＡＣの特徴は、デフォルトで、その音声出力ピンへ行く全ての音声をその入力ピンへルートする。従って、もし、ＶＡＣがデフォルト再生デバイスとして選択されたら、システム上に再生されている全ての音声は、ＶＡＣの出力ピンへ行き、従って、その入力ピンへ行く。
【００７３】
任意のアプリケーションが音声を、waveln API等の適当なインターフェースを利用して、ＶＡＣの入力ピンからキャプチャするとき、そして、そのシステム上に再生されている全てをキャプチャすることが可能である。ＶＡＣを利用して音声をキャプチャするために、デフォルト音声デバイスとして選択されていなければならない。ＶＡＣがいったんデフォルト音声デバイスとして選択されると、そして、ローカルスピーカ上の音声は聞こえない。
【００７４】
前述したように、メディアは、受信機へ同期で同時に無線で送信される（ステップ５０５）。リモート監視デバイスとデータ通信している受信機は、圧縮されたメディアデータを受信する（ステップ５０６）。メディアデータは、そして、ＣＯＤＥＣを利用して、解凍される（ステップ５０７）。データは、最後に、ディスプレイデバイス上にレンダーリングされる（ステップ５０８）。
【００７５】
任意の送信プロトコルを用いて、メディアを送信することが可能である。しかし、クロック又はカウンタを利用して同期化されたビデオと音声データストリームを別々に、ハイブリッドＴＣＰ／ＵＤＰプロトコルに従って、送信することが好ましい。特に、クロック又はカウンタの列は転送され、各データストリームが時間順序付けられたことを示す。
【００７６】
図６に示すように、上述のＴＣＰ／ＵＤＰハイブリッドプロトコルの実施の形態が図示されている。ＴＣＰ／ＵＤＰハイブリッドプロトコル６００は、２０ＴＣＰ、２０ＩＰ、及び物理レイヤヘッダのサイズと等しいＴＣＰパケットヘッダ６０１、並びに、８ＵＤＰ、２０ＩＰ、及び物理レイヤヘッダのサイズと等しいＵＤＰパケットヘッダ６０２からなる。
【００７７】
図７は、本発明に実装されたＴＣＰ／ＵＤＰリアルタイム（ＲＴ）送信プロトコルの機能ステップを図示したフローダイアグラムである。前に説明された送信機と受信機は、ＴＣＰを利用して接続を確立し（ステップ７０１）、送信機は、ＴＣＰを利用して、全ての参照フレームを送信する（ステップ７０２）。その後、リアルタイムパケットの残りを送信するのに、送信機は、ステップ７０１での接続確立に利用されたのと同じＴＣＰポートを利用（ステップ７０３）するが、トランスポートプロトコルとしてＵＤＰへスイッチする（ステップ７０４）。
【００７８】
ＵＤＰを利用してリアルタイムパケットを送信する間に、送信機は、更に、送信の期限切りになったＲＴパケットの存在をチェックする。送信機は、ＩＰとＭＡＣ間の送信機自身での期限切りフレームを処分する（ステップ７０５）。しかし、期限切り参照フレーム／パケットは、いつも送信される。このように、ＴＣＰ／ＵＤＰプロトコルは、ＲＴトラフィックとネットワークスループットのパフォーマンスを実質的に増やして、衝突をかなり低減する。
【００７９】
追加して、ＴＣＰ／ＵＤＰプロトコルは、無線ネットワークを介してＲＴ送信用の混雑信号法としてＡＣＫスプーフィングを利用するように適合される。無線ネットワークを介したＲＴトラフィックの送信は、遅くできる。これの一つの理由は、従来、各データブロックの送信後、次のブロック又はフレームの送信を再開する前に、ＴＣＰは、ＡＣＫ信号の受信をあて先／受信機から要求する。
【００８０】
ＩＰネットワークに、特に無線ネットワークに、ネットワーク混雑による、高い確率のＡＣＫ信号損失があり、特にＲＴトラフィックにも同様である。このように、ＴＣＰはフロー制御及び混雑制御の両方をするので、受信機からのＡＣＫ信号の非受理等のシナリオのせいで、この混雑制御は、無線ネットワーク上の接続切断をまねく。
【００８１】
接続切断を解決するには、一つの実施の形態において、本発明は、ネットワークに送信されたＲＴトラヒック用のＡＣＫスプーフィングを利用する。ＡＣＫスプーフィングを実装することで、もし受信機が特定の時間間隔内にいかなるＡＣＫを受診しないとき、送信機は、送信プロセスが再開できるように、ＴＣＰ用に偽のＡＣＫを生成する。
【００８２】
代替の実施の形態において、混雑及びネットワークスループットの低減による低品質送信の場合に、送信機と受信機の間の接続が切れ、及び、新しいＴＣＰ接続が同じ受信機へオープンされる。これは、前の接続に関係した混雑問題をキレイに解決する。この送信方法は、複数の送信方法の単に一つであることは明らかであり、利用され、動作例で説明される。
【００８３】
図８に示すように、統合無線システムのＣＯＤＥＣのコンポネントを図示したブロックダイアグラムである。ＣＯＤＥＣ８００は、ストリーミングコンテンツから時間冗長性を取り除く動き推定ブロック８０１、フレームを８＊８ブロックピクセルに変換してＤＣＴを行なうＤＣＴブロック８０２、コンテンツを更に短いワードに符号化するＶＬＣコーディング回路８０３、空間周波数をピクセルドメインへ戻して変換するＩＤＣＴブロック８０４、及び、メディア送信の高速化用のレート制御メカニズム８０５からなる。
【００８４】
ビデオの隣接フレーム間の時間冗長性を利用することで、動き推定ブロック８０１を利用して、ビデオを圧縮する。動き推定に利用されたアルゴリズムは、ベストマッチングブロックを取得するのに、参照フレームの各ブロックは、現在フレームと比較されるフルサーチアルゴリズムであることが好ましい。このフルサーチアルゴリズムは、その用語通り、チェックポイントとしてサーチ領域の各ポイントを取り、参照フレームの全てのチェックポイントに対応するブロックと、現在フレームのブロックの間の全てのピクセルを比較する。そして、ベストチェックポイントが判定され、動作ベクトル値を取得する。
【００８５】
例えば、図９は、動き推定ブロックの一つの実施の形態の機能ステップを図示している。図に示したチェックポイントAとA１は、参照フレームのブロック９０２と９０４にそれぞれ対応する。もしチェックポイントAは、左下へ１ピクセル移動した場合、これがチェックポイントA１になる。このように、ブロック９０２は、左下へ１ピクセルシフトされたとき、ブロック９０４になる。
【００８６】
比較技術は、全ての対応するピクセルイメージ情報内の差異を計算し、そして、イメージ情報内の差異の絶対値の合計することによって行なわれる。最後に、絶対値の合計（ＳＡＤ）が行なわれる。そして、全チェックポイント中、最小のＳＡＤを有するチェックポイントは、ベストチェックポイントとして、判定される。ベストチェックポイントに対応するブロックは、エンコードされる現在フレームのブロックと最も一致する参照フレームのブロックである。この２つのブロックは、動きベクトルを取得する。
【００８７】
もどって図８に示すように、動き推定がいったん実行すると、ピクチャーは、ＤＣＴブロック８０２を介して、離散コサイン変換(ＤＣＴ)を利用して符号化される。ＤＣＴコーディングスキームは、ピクセル（又はエラーターム）を特定コサイン基底ファンクションの強度に対応する係数セットに変換する。この離散コサイン変換（ＤＣＴ）は、一般的に、ビデオ圧縮用のもっとも効率的な変換コーディング技術とみなされており、連続波形に比べ、ディジタルイメージデータのようなサンプルされたデータに応用されている。
【００８８】
変換は、ピクセルの行と列の形のN（ポイント）の高度相関入力空間ベクトルを、高周波数係数が一般にゼロ値になった、ＤＣＴ係数の行と列を含むNポイントＤＣＴ係数ベクトルへ変換するので、イメージ圧縮にＤＣＴを利用することは都合が良い。ベクトルの各要素の二乗値によって定義された空間ベクトルのエネルギーは、ＤＣＴ変換によって、保存される。低周波数及び高度相関空間イメージは、最低周波数ＤＣＴ係数に圧縮され、象徴的全てのエネルギーも同様に保存される。
【００８９】
なおその上、人間の心理視覚系は、次のように、高周波数信号に対して低い感受性を持っている。高周波数ＤＣＴ係数の式の正確な減少は、受け取られるイメージ品質に最小縮小をもたらす。一つの実施の形態において、ＤＣＴブロックの結果である８＊８ブロックは、量子化行列によって分割され、ＤＣＴ係数の大きさを低減する。そのような場合、人間の視覚に見えにくい傾向を持つもっとも高い周波数に関連する情報は、取り除かれる。結果は、整理し直されて、可変長コーディングブロック８０３へ送信される。
【００９０】
可変長コーディング（ＶＬＣ）ブロック８０３は、コードワードをエンコードされる値に割り当てる、統計的コーディングブロックである。発生の高い周波数値は、短いコードワードに割り当てられ、それらの少ない発生は、長いコードワードに割り当てられる。平均で、もっと頻繁な短いコードワードは、コードストリングが元のデータより短いように、そろえる。
【００９１】
仕上がったＤＣＴ係数値レベルのコードと、ノンゼロＤＣＴ係数間のピクセル数の実行長さを生成するＶＬＣコーディングは、ゼロ値ＤＣＴ係数の数が最大のとき、高圧縮コードを生成する。ＶＬＣコーディングブロックから取得されたデータは、送信機へ適当なビットレートで転送される。毎秒転送されたデータの量は、ビットレートとして知られている。
【００９２】
図１０は、例示のディジタル信号波形及びデータ転送を図示している。垂直軸１００１は、電圧を表し、水平軸１００２は、時間を表す。Ｎがパルスのビット時間を表すとき、ディジタル波形は、パルス幅Ｎ及び、２Ｎの周期（又は繰り返し）を有する（例えば、情報が転送される間の時間）。パルス幅Nは、ナノ秒、マイクロ秒、ピコ秒等のような任意の単位時間であることが可能である。
【００９３】
このように送信されることが可能な最大のデータレートは、毎秒１／Ｎ転送、又は半サイクルごとにデータの１ビット（時間ラベルの量N）である。ディジタル波形の基本周波数は、１／２Ｎヘルツである。一つの実施の形態において、簡易化されたレート制御は、採用され、MPEG２（登録商標）を利用する上述の方法に比べて、データのビットレートを５０％増加させる。
より短い時間の結果、送信機へ転送されているデータの大きなチャンクは、処理をリアルタイムにしている。
【００９４】
圧縮されたデータは、上述の送信プロトコルに従って、送信され、受信機によって無線で受信される。動きビデオ性能を提供するために、圧縮されたビデオ情報は、速く及び効率的にデコードされなければならない。好ましい実施の形態に利用されているデコーディング処理の態様は、逆離散コサイン変換（ＩＤＣＴ）である。逆離散コサイン変換（ＩＤＣＴ）は、変換ドメインデータを、空間ドメインの形式へ戻して変換する。
【００９５】
コーディング効率とハードウェア複雑の間の妥当を与える、一般に利用される２時限データブロックのサイズは、８＊８ピクセルである。逆ＤＣＴ回路は、ブロックバイブロックに基づいて、デコードされたビデオ信号の逆離散コサイン変換を行い、解凍されたビデオ信号を提供する。
【００９６】
図１１に示すように。ＩＤＣＴブロックの処理及び選択的最適化のダイアグラムが図示されている。回路１１００は、前処理ＤＣＴ係数ブロック（以下、ＰＤＣＴという。）１１０１、評価係数ブロック１１０２、選択ＩＤＣＴブロック１１０３、計算ＩＤＣＴブロック１１０４、監視フレームレートブロック１１０５、及び、調整ＩＤＣＴパラーメータブロック１１０６を含む。動作において、送信機から受信された無線送信されたメディアは、PＤＣＴブロック１１０１へルートされた様々なコード化されたＤＣＴ係数を含む。
【００９７】
ＰＤＣＴブロック１１０１は、様々なＤＣＴ係数をゼロ値へ選択的にセットして、ビデオ品質をわずかに低下させ又は低下なしで、逆離散コサイン変換手順の処理速度を増加させる。そして、ＤＣＴ係数評価ブロック１１０２は、前処理されたＤＣＴ係数をＰＤＣＴ１１０１から受信する。評価回路１１０２は、逆離散コサイン変換オペレーションの計算の前に、ＤＣＴ係数ブロック内の係数を調べる。ノンゼロ係数の数に基づいて、逆離散コサイン変換（IＤＣＴ）選択回路１１０３は、係数処理のために、最適ＩＤＣＴ手順を選択する。
【００９８】
係数計算は、計算ＩＤＣＴブロック１１０４によって行われる。一つの実施の形態において、いくつかの逆離散コサイン変換（ＩＤＣＴ）エンジンは、選択回路１１０３によって、選択的に有効にされ、利用できる。一般的に、逆離散コサイン変換された係数は、表示前に他のデータと結合される。その後、監視フレームレートブロック１１０５は、ビデオシステムの適当なフレームレートを判定する。
【００９９】
この判定は、例えば、システムブロックレジスタ（図示せず。）を読み込み、及び、経過時間を望ましいフレームレートに対応する事前格納されたフレーム間隔と比較することによって行なわれる。そして、この調整ＩＤＣＴパラーメータブロック１１０６は、望ましい又は適切なフレームレートに従って、ノンゼロ係数閾値、周波数、及び、大きさを含むパラーメータを調整する。
【０１００】
上述のＩＤＣＴブロックは、選択された適当なIＤＣＴ方法に従って、逆離散コサイン変換を計算する。例えば、８＊８順方向離散コサイン変換（ＤＣＴ）は、次の式で定義される。
【数１】
2008539614.tif 000003
ここで、ｘ（ｉ，ｊ）は、空間ドメインｉとｊの８＊８イメージブロックのピクセル値で、X(u,v)は、変換ドメインｕ，ｖ内に８＊８変換ブロックに変換された係数である。C(O)は、１／.ｓｑｒｏｏｔ．２であり、C(u)=C(v)=1である。
【０１０１】
逆離散コサイン変換（ＩＤＣＴ）は、次の式で定義される。
【数２】
2008539614.tif 000004
【０１０２】
８＊８ＩＤＣＴは、それぞれ２次元周波数（ｖ，ｕ）の１基底行列の６４直交ＤＣＴ基底行列の組み合わせとみなされている。更に、各基底行列は、各シングル変換係数を１にセットした２次元ＩＤＣＴ変換であるとみなされている。８＊８ＩＤＣＴに６４変換係数があるため、６４基底行列がある。
【０１０３】
ＩＤＣＴカーネルＫ（ｖ，ｕ）は、次の式に従う周波数（v,u）での変換係数を表す、ＤＣＴ基底行列とも呼ばれる。
［数３］
K(v,u)=.nu.(u).nu.(v)cos((2m+1).pi.u/16)cos((2n+1).pi.v/16)
ここで、.nu.(u)と.nu.(v)は、u=0のとき.nu.(u)=1/.sqroot.8、u>0のとき.nu.(u)=1/2として定義された規格化係数である。IＤＣＴは、その場所で係数を変換して、各カーネルをスケーリングし、スケールされたカーネルの合計を持って、計算される。
【０１０４】
空間ドメイン行列Ｓは、次の式を利用して取得される。
【数４】
2008539614.tif 000005
なお、４＊４変換ブロックが利用されることは明らかである。
【０１０５】
前に議論したように、様々なメディアストリームは、多重化され、シングルストリームとして送信されることが可能であると同時に、メディアデータストリームを同期して別々に送信することが好ましい。図１２に示すように、統合無線システムの同期メディアデータの同期化回路のコンポネントを図示したブロックダイアグラムが図示されている。
【０１０６】
同期化回路１２００は、送信機１２０６では、ビデオと音声メディアを有するバッファ１２０１、ビデオ送信用の第１ソケット１２０２、音声送信用の第２ソケット１２０３、第１カウンタ１２０４、及び第２カウンタ１２０５、並びに、受信端１２１３では、ビデオデータ用の第１受信機１２０７、音声データ用の第２受信機１２０８、第１カウンタ１２０９、第２カウンタ１２１０、ミクサー１２１１及びバッファ１２１２からなる。
【０１０７】
動作的に、圧縮後、送信機１２０６でバッファされた音声及びビデオデータ１２０１は、第１ソケット１２０２及び第２ソケット１２０３に別々に送信される。カウンタ１２０４、１２０５は、送信前に、ビデオと音声データの両方に同一シーケンス番号を付加する。一つの実施の形態において、音声データは、ユーザー・データグラム・プロトコル（ＵＤＰ）を介して、ビデオデータは、伝送制御プロトコル（ＴＣＰ）を介して、ルートされることが好ましい。
【０１０８】
受信端１２１３では、音声受信機ブロック１２０８とビデオ受信機ブロック１２０７によって実装されたＵＤＰプロトコルとＴＣＰプロトコルは、音声及びビデオ信号を受信する。カウンタ１２０９、１２１０は、音声及びビデオ信号からのシーケンス番号を判定し、これをミクサー１２１１へ提供して、信号の正確なミキシングを可能にする。ミックスされたデータは、バッファ１２１２に格納され、そして、リモートモニタによってレンダーリングされる。
【０１０９】
図１３に示すように、フローチャートは、本発明の統合無線システムの音声及びビデオ信号の同期化の他の実施の形態を図示している。最初は、受信機は、エンコードされたビデオデータとエンコードされた音声データのストリームを無線で受信する（ステップ１３０１）。そして、エンコードされたストリームのビデオの部分と音声の部分を処理するために、受信機は、要求時間を確かめる（ステップ１３０２）。
【０１１０】
その後、受信機は、エンコードされたストリームのビデオの部分の処理時間を、エンコードされたストリームの音声の部分の処理時間と比較して、時間の差異を判定する（ステップ１３０３）。受信機は、どの処理時間が大きい（例えば、ビデオ処理時間又は音声処理時間）かを続いて確立する（ステップ１３０４）。
【０１１１】
もし、音声処理時間が大きいとき、ビデオプレゼンテーションは、判定による差異時間で遅延され（ステップ１３０５）、従って、デコードされたビデオデータをデコードされた音声データと同期化する。しかし、もし、ビデオ処理時間が大きいとき、音声プレゼンテーションは、遅延されないで、その固定レートで再生される（ステップ１３０６）。
【０１１２】
一定間隔で、ビデオフレームを処分することによって、ビデオプレゼンテーションは、音声プレゼンテーションに追い付くことを試みる。そして、データは、最後に、リモートモニタ上にレンダーリングされる（ステップ１３０７）。従って、音声がビデオを「リードする」の意味は、ビデオはそれ自身を音声と同期化することである。
【０１１３】
特定の実施の形態において、デコードされたビデオデータは、デコードされた音声データと実質的に同期化されている。この実質的に同期化されたの意味は、ビデオデータのプレゼンテーションと、それに対応する音声データのプレゼンテーションの間には、微小な、理論的に測定可能な差異があることは可能であるが、音声とビデオデータのプレゼンテーションのそのような小さな差異は、上演されているビデオと音声データを視聴しているユーザに気づかれる可能性は低い。
【０１１４】
一般的なトランスポートストリームは、実質的に固定レートで受信される。この場合、ビデオプレゼンテーション又は音声プレゼンテーションに適用した遅延は、頻繁に変更される可能性は低い。このように、ビデオプレゼンテーション又は音声プレゼンテーションに現在適用された遅延が特定の閾値内(例えば、視覚的に又は音声的に認識できない。)にあることを確かめるために、上述の手順が定期的に（例えば、数秒毎に、又は受信した３０ビデオフレーム毎に）行なわれることが可能である。代替的に、この手順は、トランスポートストリームから受信したビデオデータの新しいフレーム毎に行なわれることが可能である。
【０１１５】
図１４に示すように、音声とビデオ同期化回路の他の実施の形態が図示されている。送信端１４０１での同期化回路１４００は、メディアデータを有するバッファ１４０２、グラフィック、テキスト、音声、及び、ビデオ信号等のメディアデータ信号の合成用の多重機１４０３、及び、同期化用にメディアコンテンツへタイムスタンプを提供する
クロック１４０４からなる。
【０１１６】
受信端１４０５では、分離器１４０６は、クロック１４０７を利用して、データストリームを個別のメディアデータストリームへ分離する。クロックによって提供されたタイムスタンプは、受信端で音声及びビデオの同期化に役立つ。クロックは、受信機での周波数と、同じ周波数に設定される。分離された音声とビデオは、レンダーリング用にスピーカ１４０８及び表示デバイス１４０９へルートされる。
【０１１７】
一つの実施の形態において、本発明は、本発明の新規ソフトウェアを、計算デバイス又はリモートモニタ上に、自動的にダウンロード、インストール、及びアップデータするシステム及び方法を提供する。リモートモニタ、リモートモニタ内の受信機、計算デバイス、又は計算デバイス内の送信機上に、ソフトウェアプログラムをインストールするのに、ソフトウェアCDは、要求されない。
【０１１８】
例としては、無線プロジェクタと通信しているパーソナルコンピュータが提供され、一般的な機種であるが、計算デバイスとリモートモニタの任意の組み合わせに応用できる。パーソナルコンピュータと無線プロジェクタの両方は、上述したような処理システムオンチップとデータ通信していると、仮定する。
【０１１９】
開始時、無線プロジェクタ(ＷＰ−ＡＰ)は、アクセスポイントとして自身を構成するために、スクリプトを実行する。ＷＰ−ＡＰは、「ｘｘｘｘｘｘ」がＡＰのＭＡＣアドレスの下６バイトであるとき、QWPxxxxxxとしてＳＳＩＤを設定する。ＷＰ−ＡＰは、そのＩＰアドレスを10.0.0.1として設定する。ＷＰ−ＡＰは、ＨＴＴＰサーバを開始する。
【０１２０】
ＷＰ−ＡＰは、次のコンフィグレーションファイル内の設定でＤＨＣＰサーバを開始する。
開始アドレス：  10.0.0.3
終了アドレス：  10.0.0.254
ＤＮＳ：  10.0.0.1
デフォルトゲートウェイ：  10.0.0.1
［アドレスの第２及び第３オクテットは、設定可能である。］
【０１２１】
ＷＰ−ＡＰは、任意のＤＮＳクエリー用に10.0.0.1（ＷＰ−ＡＰのアドレス等）を返信するように構成された、小さなＤＮＳサーバを開始する。ＷＰ−ＡＰのＩＰアドレスが変化すると、応答のＩＰアドレスが変化される。ＨＴＴＰサーバのデフォルトページは、ソフトウェアの自動アップデータを行なう、Java Appletのような小さなソフトウェアプログラムを備えている。
【０１２２】  デフォルトページが任意の種類のＨＴＴＰ要求でいつもアクセスされていることを確認するために、ＨＴＴＰサーバのエラーページは、デフォルトページへリダイレクトする。これは、ブラウザ上のデフォルトページが、例えば、次のようなディレクトリを有するとき、起こりえる。    （公序良俗違反につき、不掲載）isapi/redir.dll?prd=ie&pver=6&=msnhome【０１２３】
自身のシステムオンチップ及び送信機を通してＷＰ−ＡＰは、アクセスポイントとしての自身の存在を知らせる。ユーザの計算デバイスは、既存の無線通信プロトコルと規格に従って無線で情報の送信と受信ができる送受信機を備えている。ユーザの計算デバイスは、アクセスポイントとして、無線プロジェクタの存在を認識する。ユーザは、計算デバイスに、当業者に知られたグラフィカルユーザインターフェースを通して、アクセスポイントに参加するように、指示する。
【０１２４】
無線プロジェクタのアクセスポイントに参加した後、ユーザは、計算デバイス上のウェブブラウザアプリケーションをオープンし、ダイアログボックスへ、任意のＵＲＬをタイプし、又は、デフォルトＵＲＬへブラウザを戻すことを許可する。ウェブブラウザのオープニングは、ＷＰ−ＡＰ  ＨＴＴＰサーバのデフォルトページにアクセスし、ソフトウェアプログラム（Java Aｐｐlet等）の初期化をもたらす。
【０１２５】
一つの実施の形態において、ソフトウェアプログラムは、ユーザのブラウザがこれをサポートしているかをチェックし、ソフトウェアの自動アップデータを処理する。残りの例は、Javaとの関係で説明されるが、任意のソフトウェアプログラム言語が利用できることが明らかである。
【０１２６】
ブラウザにJavaがサポートされているとき、appletは、ここで説明されたメディア送信方法を実行するに必要なソフトウェアとドライバがすでにインストールされたかをチェックする。すでに存在するとき、Java Appletは、バージョンを比較し、そして、計算デバイスソフトウェアバージョンがリモートモニタ上のバージョンより古いとき、インストールを自動的に初期化する。
【０１２７】
ブラウザにJavaがサポートされないとき、ユーザのウェブページは、インストール実行へリダイレクトされ、ユーザにこれを保存又は実行するプロンプトを表す。このページは、また、インストールをどのように保存し、実行するかの説明も表示する。インストールプログラムは、また、ユーザがソフトウェアをすでにインストールしている、及び必要なバージョンがアップデータされたか否かをチェックする。この場合は、ユーザがJavaをインストールするように薦める。
【０１２８】
第１の実施の形態において、ＷＰ−ＡＰのＤＮＳ用の開始アドレスは、10.0.0.2である。ＷＰ−ＡＰは、イーサネット接続用にＤＨＣＰクライアントを実行し、ローカルエリアネットワーク上のＤＨＣＰサーバからＩＰ、ゲートウェイ、サブネット、及びＤＮＳのアドレスを取得する。ＤＨＣＰが無効のとき、スタティック値を利用する。インストールプログラムは、アプリケーション、アンインストール、及びドライバをインストールする。
【０１２９】
アプリケーションは、自動的にランチされる。接続時、アプリケーションは、ＷＰ−ＡＰのイーサネットポートのＤＮＳアドレスを取得し、これをローカルマシン上に設定する。接続確立後、ＷＰ−ＡＰは、ＩＰ転送を可能にし、ファイアウォールを次のように設定する。これは、接続されたアプリケーションからのパケットのみを、イーサネット及びその逆に転送する。これらの設定は、ユーザをＷＰ−ＡＰのイーサネットローカルエリアネットワークへアクセスすること、インターネットへのアクセスすることを可能にする。
【０１３０】
アプリケーションがＷＰ−ＡＰへ接続されたユーザのみがＬＡＮ／イーサネットへアクセスできることを、ファイアウォールが確認する。切断時、ＷＰ−ＡＰは、ＩＰ転送を無効にし、ファイアウォール設定をリストールする。ユーザシステム上に実行しているアプリケーションは、ＤＮＳ設定を10.0.0.1に設定する。アプリケーションの終了時、ＤＮＳ設定はＤＨＣＰに設定される。
【０１３１】
他の実施の形態において、インストール時、ユーザは、計算デバイスがゲートウェイとして振舞うか否かを選ぶように、プロンプトされる。応答に依存して、適当なドライバ、ソフトウェア、及び、スクリプトがインストールされる。
【０１３２】
今度、図１５に示すように、本発明のソフトウェアの自動ダウンロード、アップデート用の他の例示の構成が図示されている。無線プロジェクタアクセスポイントは、10.A.B.1に設定されたＩＰアドレスを有し、ゲートウェイシステムは、10.A.B.2に設定されたＩＰアドレスを有する。ここで、ＡとＢのオクテットは、ユーザによって変更できる。
【０１３３】
ＷＰ−ＡＰは、ブートされる。ユーザの計算デバイスは、利用可能な無線ネットワークをスキャンし、QWPxxxxxxを選択する。計算デバイスの無線構成は、有効な自動ＴＣＰ／ＩＰ構成を有しなければならない。例えば、「ＩＰアドレスを自動的に取得」と、「ＤＮＳサーバアドレスを自動的に取得」のオプションはチェックされなければならない。計算デバイスは、10.0.0.3から10.0.0.254までアドレスからＩＰアドレスを自動的に取る。デフォルトゲートウェイとＤＮＳは、10.0.0.1として設定される。
【０１３４】
ユーザは、ブラウザをオープンし、Javaがサポートされているとき、ソフトウェアのアップデータが自動的に開始される。Javaがサポートされていないとき、ユーザは、インストールを保存するようプロンプトされ、これを手動で実行する。もし、計算デバイスが、インターネット等のネットワークへのゲートウェイとして動作しないとき、インストール中、ユーザは、ゲートウェイオプションに「いいえ」を選択する。
【０１３５】
インストールは、スクリプトを実行して、ＤＮＳを10.0.0.2に設定する。次のＤＮＳクエリーは、適当にリダイレクトされるようにする。アプリケーションリンクは、デスクトップ上に作成される。ユーザは、アプリケーションを実行する。アプリケーションは、プロジェクタへユーザの画面の正確なコンテンツの送信を開始する。要求されたら、ユーザは、ＷＰ−ＡＰ構成（ＳＳＩＤ、チャネル、ＩＰアドエス設定：第２及び第３オクテットは、10.0.0.xに変更できる。）を変更できる。
【０１３６】
もし、計算デバイスは、インターネット等のネットワークへのゲートウェイとして動作するとき、インストール中、ユーザは、プロンプトされたとき、ゲートウェイオプションの「はい」を選択する。インストールは、イーサネットインターフェース（共有は、Windows 2000及びWindows XPの両方に、ネットワークインターフェースのプロパーティ内のオプションである。）上にインターネット共有（ＩＰ転送）を可能にし、システムの無線インターフェースＩＰを10.0.0.2に設定、システムの無線インターフェースネットマスクを255.255.255.0に設定、及び、システムの無線インターフェースゲートウェイを10.0.0.1に設定する。
【０１３７】
アプリケーションリンクは、デスクトップ上に作成される。ユーザは、アプリケーションを次のように実行する。アプリケーションは、プロジェクタへユーザの画面の正確なコンテンツの送信を開始する。要求されたら、ユーザは、ＷＰ−ＡＰ構成（ＳＳＩＤ、チャネル、ＩＰアドレスの設定：第２と第３オクテットは、10.0.0.xに変更できる。）は変更できる。
【０１３８】
本発明は、計算デバイスから、１以上のリモートモニタリングデバイス又は他の計算デバイスへ、メディアのリアルタイム送信を可能にすることは明らかである。図１６に示すように、本発明の統合無線マルチメディアシステムの他のアレンジメントは図示されている。この特定の実施の形態において、送信機１６０１及び複数の受信機１６０２、１６０３、１６０４の間の通信が図示されている。
【０１３９】
送信機１６０１は、メディアを、リアルタイムレンダーリング用に、複数のデバイス１６０１、１６０２、及び１６０３へ統合された、又は、データ通信している、受信機へ無線で送信する。代替の実施の形態において、上述のソフトウェアは、ミラーキャプチャモードと拡張モードの両方に利用されることができる。ミラーキャプチャモードにおいて、コンテンツのリアルタイムストリーミングは、送信端及び受信端の両方で表示されている同一コンテンツで行なわれる。しかし、拡張モードにおいては、ユーザは、送信側で多少他のアプリケーション上に作業でき、送信は、バックエンドプロセスとして継続できる。
【０１４０】
上の例は、本発明のシステムのたくさんの応用の単に実例に過ぎない。本発明のほんのわずかな実施の形態がここで説明されたが、本発明の精神と範囲から逸脱することなく、他の特定の形式で実施されることが可能である。例えば、本発明の範囲と趣旨内にあれば、送信機、ネットワーク、及び受信機の他の構成が利用できる。従って、本実例及び実施の形態は、限定ではなく、実例と考えられ、本発明は、ここで示された詳細内容に制限されないが、添付請求項の範囲内に修正可能である。
【図面の簡単な説明】
【０１４１】
【図１】図１は、本発明の統合無線メディア送信システムのブロックダイアグラムを図示した図である。
【図２】図２は、本発明の一つの実施の形態の送信機のコンポネントを図示した図である。
【図３】図３は、本発明のソフトウェア実装の一つの実施の形態からなる複数のソフトウェアモジュールを図示した図である。
【図４】図４は、本発明の一つの実施の形態の受信機のコンポネントを図示した図である。
【図５】図５は、本発明の例示動作を図示したフローチャートである。
【図６】図６は、本発明のＴＣＰ／ＵＤＰ  ＲＴハイブリッドプロトコルヘッダ構造の一つの実施の形態を図示した図である。
【図７】図７、本発明のＴＣＰ／ＵＤＰ  ＲＴ送信プロトコルの例示の機能ステップを図示したフローチャートである。
【図８】図８は、本発明に利用された例示のＣＯＤＥＣのブロックダイアグラムを図示した図である。
【図９】図９は、本発明に利用された例示の動き推定ブロックの機能ダイアグラムを図示した図である。
【図１０】図１０は、ディジタル信号波形の一つの実施の形態、及び対応するデータ転送を図示した図である。
【図１１】図１１は、本発明のＩＤＣＴブロックの例示のビデオ処理及び選択的最適化のブロックダイアグラムを図示した図である。
【図１２】図１２は、本発明の音声及びビデオデータ同期化用の同期回路のコンポネントを図示したブロックダイアグラムである。
【図１３】図１３は、本発明の音声及びビデオ信号の同期化用の他の実施の形態を図示したフローチャートである。
【図１４】図１４は、本発明の音声及びビデオ信号同期化回路の他の実施の形態を図示した図である。
【図１５】図１５は、本発明のソフトウェアの自動ダウンロード及びアップデータ用のエンタープライズ構成を図示した図である。
【図１６】図１６は、送信機と複数の受信機の間の通信を図示した概要図である。
【図１７】図１７は、ディスプレイドライバ開発用のMicrosoft Windowsフレームワークのブロックダイアグラムを図示した図である。
【図１８】図１８は、ＧＤＩとディスプレイドライバの間の相互作用のブロックダイアグラムを図示した図である。
【図１９】図１９は、DirectDrawアーキテクチャのブロックダイアグラムを図示した図である。
【図１】
2008539614.tif 000006
【図２】
2008539614.tif 000007
【図３】
2008539614.tif 000008
【図４】
2008539614.tif 000009
【図５】
2008539614.tif 000010
【図６】
2008539614.tif 000011
【図７】
2008539614.tif 000012
【図８】
2008539614.tif 000013
【図９】
2008539614.tif 000014
【図１０】
2008539614.tif 000015
【図１１】
2008539614.tif 000016
【図１２】
2008539614.tif 000017
【図１３】
2008539614.tif 000018
【図１４】
2008539614.tif 000019
【図１５】
2008539614.tif 000020
【図１６】
2008539614.tif 000021
【図１７】
2008539614.tif 000022
【図１８】
2008539614.tif 000023
【図１９】
2008539614.tif 000024
【国際調査報告】
2008539614.tif 000025