(57)【要約】【課題】ゲームデバイス上の複数プレーヤのリアルタイムな音声コミュニケーションの使用を実現する。【解決手段】他のゲームコンソールと通信できるゲームコンソール１０２が、各プレーヤのためのヘッドホン１０９ａ〜１０９ｄ及びマイクロホン２０２ａ〜２０２ｄを備える。１名または複数名のプレーヤに向けられた口頭のコミュニケーションが、ＰＣＭデジタルデータに変換され、リアルタイムで符号化され圧縮されて、別のゲームコンソール２１０、２１２、２１４に伝送されるデータパケットが生成される。圧縮されたデータパケットは、圧縮解除され復号化されて、宛先の受け手のヘッドホンを駆動するアナログ信号に変換されるＰＣＭデータが生成される。事前定義されたレベルの計算リソースが、音声コミュニケーションのために使用されてゲームプレーの品質に悪影響が及ぶことが回避される。【選択図】　　　　図５
2004024859.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのマルチプレーヤゲームコンソール上で行われる電子ゲームで使用するための、前記ゲームを行いながらリアルタイムにプレーヤが口頭でコミュニケーションできるようにする方法であって、
（ａ）前記マルチプレーヤゲームコンソールを使用している少なくとも１つのプレーヤにオーディオセンサを提供するステップであって、
前記オーディオセンサは、前記少なくとも１つのプレーヤによって生成されたサウンドに応答して前記ゲームコンソールへの入力信号を生成するステップと、（ｂ）出力信号に応答して前記ゲームの別のプレーヤに可聴なサウンドを生成するように適合された少なくとも１つのサウンドトランスデューサを提供するステップと、
（ｃ）符号化されたデジタル信号を生成するために、前記オーディオセンサからの前記入力信号を符号化するステップと、
（ｄ）前記別のプレーヤに関連する音声チャネルを介して前記符号化されたデジタル信号を伝送するステップと、
（ｅ）前記出力信号を生成するために、前記別のプレーヤの前記チャネルにおける前記符号化された信号を復号化するステップと、
（ｆ）前記１つのプレーヤによって生成された前記サウンドに対応する可聴サウンドを生成するために、前記サウンドトランスデューサに前記出力信号を提供するステップであって、前記１つのプレーヤによる口頭のコミュニケーションが、前記ゲームの前記別のプレーヤによって聞かれるようにするステップと
を備えたことを特徴とするプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２】
（ａ）前記別のプレーヤによって生成されたサウンドを検出する別のオーディオセンサを提供するステップであって、前記別のプレーヤによって生成された前記サウンドに応答して別の入力信号を生成するステップと、
（ｂ）別の出力信号に応答して前記ゲームの前記１つのプレーヤによって可聴なサウンドを生成するように適合された、前記１つのプレーヤのためのサウンドトランスデューサを提供するステップと、
（ｃ）前記別のオーディオセンサからの前記別の入力信号を符号化するステップであって、別の符号化されたデジタル信号を生成するステップと、
（ｄ）前記１つのプレーヤに関連するチャネルを介して前記別の符号化されたデジタル信号を伝送するステップと、
（ｅ）前記１つのプレーヤに関連する前記チャネルにおける前記別の符号化された信号を復号化するステップであって、前記別の出力信号を生成するステップと、
（ｆ）前記別のプレーヤによって生成された前記サウンドに対応する可聴サウンドを生成するために、前記別の出力信号を前記別のサウンドトランスデューサに提供するステップであって、前記別のプレーヤによる口頭のコミュニケーションが、前記ゲームの前記１つのプレーヤによって聞かれるようにするステップとをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項３】
前記１つのプレーヤ及び前記別のプレーヤは、コミュニケーションするように結合された異なるマルチプレーヤゲームコンソール上で前記電子ゲームを行い、前記符号化された信号が、前記１つのプレーヤの前記マルチプレーヤゲームコンソールと前記別のプレーヤの前記マルチプレーヤゲームコンソールとの間で伝送されるようになっていることを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項４】
前記１つのプレーヤを、前記１つのプレーヤが口頭でコミュニケーションをとる前記別のプレーヤを選択できるようにするステップをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項５】
前記１つのプレーヤ及び前記別のプレーヤは、チームのメンバであり、
別のチームのプレーヤに関してステップ（ａ）〜（ｆ）を繰り返すステップであって、前記別のチームの前記プレーヤが、互いに口頭でコミュニケーションできるようにするステップをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項６】
前記マルチプレーヤゲームコンソールを使用して前記電子ゲームを行うさらなるプレーヤに関してステップ（ａ）〜（ｆ）を繰り返すステップであって、前記さらなるプレーヤが、前記ゲームにおけるその他の選択されたプレーヤと口頭でコミュニケーションできるようにするステップをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項７】
前記電子ゲームの前記プレーヤ間で口頭のコミュニケーションを可能にするために前記電子ゲームコンソール上で割り振られる処理リソースに対する限度を事前定義するステップをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項８】
前記符号化された信号に可聴効果を適用するステップであって、前記可聴効果は、前記サウンドトランスデューサによって生成された前記可聴サウンドの特性を実質的に変化させて、前記可聴サウンドが、前記１つのプレーヤによって生成された前記サウンドとは異なるようにするステップをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項９】
前記可聴効果を適用する前記ステップは、前記１つのプレーヤによって生成された前記サウンドの個人を特定する特性を実質的に除去して、前記１つのプレーヤの音声が、別のプレーヤの音声と実質的に区別不可能であるようにすることを特徴とする請求項８に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１０】
前記可聴効果は、前記１つのプレーヤによって生成された前記サウンドの音調範囲から前記可聴サウンドの音調範囲を変化させることを特徴とする請求項８に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１１】
前記可聴効果は、前記１つのプレーヤによって生成された前記サウンドに関連する性別の変化に対応することを特徴とする請求項８に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１２】
前記出力信号に可聴効果を適用するステップであって、前記可聴サウンドが、前記１つのプレーヤによって生成された前記サウンドとは異なるようにするステップをさらに備えたことを特徴とする請求項１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１３】
前記可聴効果は、周波数帯域の均等化、残響、及び反響のうちの１つであることを特徴とする請求項１２に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１４】
請求項１に記載のステップを実行するための複数のマシン語命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１５】
ゲームのプレー中にゲームコンソールを介して、前記ゲームコンソール上の複数のプレーヤが口頭でコミュニケーションできるようにする方法であって、
（ａ）前記ゲームに参加している前記複数のプレーヤの各人に関して、前記プレーヤが使用するための前記ゲームコンソールに結合されたオーディオセンサ及びオーディオトランスデューサを提供するステップであって、前記オーディオセンサは、前記プレーヤによって生成された口頭の発言に応答して前記ゲームコンソールへの入力信号を生成し、前記オーディオトランスデューサは、前記ゲームコンソールからの出力信号に応答して前記プレーヤに可聴なサウンドを生成するステップと、
（ｂ）前記複数のプレーヤのなかから少なくとも１つの宛先の受け手に転送するため、前記ゲームコンソールによって使用される形式に各オーディオセンサからの前記入力信号を符号化するステップと、
（ｃ）各宛先の受け手に関して、前記宛先の受け手のための前記出力信号を生成するために、前記ゲームコンソールによって使用される前記形式から復号化するステップと、
（ｄ）各宛先の受け手に関して、前記宛先の受け手の前記オーディオトランスデューサを使用して、前記出力信号に対応する可聴信号を生成するステップであって、前記宛先の受け手が、前記ゲームの別のプレーヤからの口頭のコミュニケーションを聞くようにするステップと
を備えたことを特徴とするプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１６】
前記ゲームコンソール上の口頭のコミュニケーションを処理することに割り振られる計算リソースのレベルを事前定義するステップであって、前記レベルは、固定であり、前記ゲームを行っている際中に音声コミュニケーションを使用するプレーヤの数の変化とは独立であるステップをさらに備えたことを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１７】
直接リンク及びネットワークのうちの１つを介して前記少なくとも１つの宛先の受け手に前記形式でデータを通信するステップをさらに備え、前記少なくとも１つの宛先の受け手は、別のゲームコンソールを使用して前記ゲームを行い、前記形式の前記データを処理することを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１８】
各プレーヤが、前記プレーヤの口頭のコミュニケーションの前記宛先の受け手を選択できるようにするステップであって、前記宛先の受け手は、前記ゲームによって課されるあらゆる制約に従って前記ゲームの前記複数のプレーヤのなかから選択されるステップをさらに含むことを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項１９】
符号化するステップは、
（ａ）前記入力信号をアナログ信号からデジタル信号に変換するステップと、（ｂ）前記形式を有する圧縮されたデジタル信号を生成するために、前記デジタル信号を圧縮するステップと
を備えたことを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２０】
復号化する前記ステップは、
（ａ）圧縮解除されたデジタル信号を生成するため、前記形式を有する前記圧縮されたデジタル信号を圧縮解除するステップと、
（ｂ）前記圧縮解除されたデジタル信号を前記オーディオトランスデューサを駆動する前記出力信号に変換するステップと
を備えたことを特徴とする請求項１９に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２１】
前記形式は、少なくとも１つのオーディオ時間フレーム全体にそれぞれが広がる複数のデータパケットを含むことを特徴とする請求項１５に記載の複数のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２２】
事前定義された数の符号化インスタンスが、各オーディオ時間フレーム中に前記ゲームコンソール上で動作し、かつ前記事前定義された数は、口頭の発言を生成している前記ゲームコンソール上のプレーヤの総数より少ないことを特徴とする請求項２１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２３】
符号化するステップは、オーディオ時間フレーム中に前記ゲームコンソール上の単一の符号化インスタンス上で並列に複数のプレーヤに関する入力信号を符号化するステップを含むことを特徴とする請求項２１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２４】
前記ゲームコンソール上で、符号化インスタンスの前記事前定義された数より多くのプレーヤが連続するオーディオ時間フレームの中で話している場合、前記連続するオーディオ時間フレームの中で符号化される前記口頭の発言を選択する際にラウンドロビン選択が適用されるように、前記ゲームコンソール上のプレーヤの前記口頭の発言が符号化されることを特徴とする請求項２２に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２５】
ゲームが、一度にアクティブである符号化インスタンスの前記事前定義された数を判定することができるようにするステップをさらに備えたことを特徴とする請求項２２に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２６】
（ａ）復号化するステップの前に異なるマルチプレーヤゲームコンソールからのデータパケットのストリームをミキシングするステップと、
（ｂ）それぞれの異なる宛先の受け手のための前記出力信号を生成するために、異なるマルチプレーヤゲームコンソールからのデータパケットのストリームを復号化し、次に、復号化されたデジタル信号をミキシングするステップと
のうちの１つをさらに備えたことを特徴とする請求項２１に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２７】
ストリームを復号化するステップは、前記ストリームを並列で復号化するステップを含むことを特徴とする請求項２６に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２８】
（ａ）選択されたプレーヤをチャネルに割り当てるステップと、
（ｂ）共通チャネルに割り当てられたプレーヤが、互いに選択的に口頭でコミュニケーションできるようにするステップと
をさらに備えたことを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項２９】
（ａ）各プレーヤに、前記プレーヤが、少なくとも１つの他のプレーヤから口頭のコミュニケーションを受信することができる聴取者チャネルを割り当てるステップと、
（ｂ）口頭の発言を行う各プレーヤを前記口頭の発言が別のプレーヤに伝送される話者チャネルに割り当てるステップと、
（ｃ）特定のプレーヤの前記聴取者チャネルを口頭の発言を行う前記プレーヤの前記話者チャネルと論理的に結合することにより、前記口頭の発言が前記特定のプレーヤによって聞かれるかどうかを判定するステップと、
（ｄ）前記特定のプレーヤが、論理的に結合する前記ステップの結果に応じて前記口頭の発言を聞くことができるようにするステップと
をさらに備えたことを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項３０】
（ａ）口頭の発言を生成しているプレーヤによって制御される前記ゲームにおけるアニメーションのグラフィックキャラクタの口唇部分を制御するための口唇同期データを生成するステップと、
（ｂ）前記アニメーションのグラフィックキャラクタの前記口唇部分を制御して、前記アニメーションのグラフィックキャラクタに対応する前記プレーヤの前記口頭の発言と同期して動くようにするために、前記口唇同期データを使用するステップと
をさらに備えたことを特徴とする請求項１５に記載のプレーヤが口頭でコミュニケーションできるようにする方法。
【請求項３１】
請求項１５に記載のステップ（ｂ）〜（ｄ）を実行するためのマシン実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項３２】
ゲームを行うプレーヤ間で口頭のコミュニケーションを可能にするシステムであって、
（ａ）プロセッサと、該プロセッサに、ゲームのインスタンスを実行することを含む複数の機能を実行させるためのマシン語命令が記憶されているメモリとを含むマルチプレーヤゲームコンソールと、
（ｂ）ゲーム中に口頭でコミュニケーションをとる各プレーヤのための口頭コミュニケーション入出力デバイスであって、それぞれの口頭コミュニケーション入出力デバイスは、
（ｉ）入射するサウンドを示す入力信号を生成する入力センサと、
（ｉｉ）印加された出力信号に応答して可聴サウンドを生成するサウンドトランスデューサと
を含む口頭コミュニケーション入出力デバイスと、
（ｃ）サウンドトランスデューサから印加される前記入力信号を符号化して符号化された信号を生成するエンコーダと、
（ｄ）前記符号化された信号を復号化して、少なくとも１つのサウンドトランスデューサに印加される前記出力信号を生成するデコーダと
を備えたことを特徴とする口頭のコミュニケーションを可能にするシステム。
【請求項３３】
少なくとも１つの他のマルチプレーヤゲームコンソールと通信するように前記マルチプレーヤゲームコンソールを結合するように適合され、かつ前記マルチプレーヤゲームコンソールと前記他のマルチプレーヤゲームコンソールとの間で符号化されたデータのストリームを伝送して、前記マルチプレーヤゲームコンソール上で前記ゲームを行っている少なくとも１つのプレーヤと前記他のマルチプレーヤゲームコンソール上で前記ゲームを行っている少なくとも１つの他のプレーヤとの間で口頭のコミュニケーションを可能にするように適合されたインタフェースをさらに備えたことを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項３４】
前記プロセッサ及び前記インタフェースは協働して、直接リンク及びネットワークのうちの１つに亘る符号化されたデータの前記ストリームを含むパケットを生成し受信することを特徴とする請求項３３に記載の口頭のコミュニケーションを可能にするシステム。
【請求項３５】
前記マシン語命令は、前記プロセッサに、前記エンコーダの前記機能、及び前記デコーダの前記機能を実行させることを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項３６】
前記マシン語命令は、前記プロセッサに、前記デコーダへのシリアル入力のために、受信した符号化されたデータのキューを維持させることを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項３７】
前記マシン語命令は、前記プロセッサに、プレーヤがサウンドを変化させる効果を選択し適用して、前記入力信号を実質的に変化させることができるようにさせ、それにより、口頭のコミュニケーションの受け手である別のプレーヤの前記サウンドトランスデューサによって生成される前記可聴サウンドが、前記プレーヤの前記サウンドセンサに入射した前記サウンドから規定の仕方で変更されることを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項３８】
前記符号化された信号は複数の時間フレームを含み、かつ各エンコーダは、前記マルチプレーヤゲームコンソール上で符号化されるべきサウンドを生成するプレーヤより少ない数のエンコーダが存在する場合、ラウンドロビン技術を使用して、連続する時間フレームに関する入力信号を処理することを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項３９】
前記符号化されたデータは圧縮されたデータを含み、かつ各デコーダは、各データストリームが異なるプレーヤから受信される場合、前記符号化されたデータを含むデータストリームを並列に処理することを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項４０】
前記エンコーダは、複数のサウンドトランスデューサから前記エンコーダに並列に印加される入力信号を符号化することを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項４１】
（ａ）データストリームをミキシングして、前記デコーダに供給されるミキシングされたデータストリームを生成するミクサと、
（ｂ）前記デコーダから受け取られた復号化されたデータをミキシングするミクサと
のうちの１つをさらに備えたことを特徴とする請求項４０に記載の口頭のコミュニケーションを可能にするシステム。
【請求項４２】
前記マシン語命令は、前記プロセッサに、プレーヤを様々な音声チャネルに関連付けさせ、かつ、プレーヤが、前記様々な音声チャネルの中からある音声チャネルを選択して、選択された前記音声チャネルに関連するプレーヤと口頭でコミュニケーションできるようにさせることを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項４３】
前記マシン語命令は、前記プロセッサに、
（ａ）話者チャネルを、各プレーヤと、前記プレーヤが口頭のコミュニケーションを受信できる聴取者チャネルとに関連付けることと、
（ｂ）何らかの話者チャネルを介して口頭のコミュニケーションが受信されたとき、プレーヤの前記聴取者チャネルが前記話者チャネルと論理的に結合されて、前記口頭のコミュニケーションが前記プレーヤによって聞かれるかどうかを判定することと
を行わせることを特徴とする請求項３２に記載の口頭のコミュニケーションを可能にするシステム。
【請求項４４】
アクティブなオーディオチャネルにおけるオーディオ信号を符号化し、電子ゲームのプレーに参加する少なくとも１つの受け手に伝送するために対応するデータパケットを生成することをそれぞれが行う、少なくとも１つの、ただし、符号化されるべきオーディオチャネルの数より少ないエンコーダを使用して、前記電子ゲームの前記プレー中に複数のオーディオチャネルを符号化する方法であって、
（ａ）連続する処理間隔中に前記エンコーダによって符号化された前記オーディオチャネルのラウンドロビン履歴を作成するステップと、
（ｂ）１つのエンコーダ当り複数のオーディオチャネルが同時にアクティブである場合、前記ラウンドロビン履歴及びその時のアクティブな前記オーディオチャネルに基づいて各エンコーダで符号化するオーディオチャネルを選択するステップであって、アクティブであるオーディオチャネルが、スキップされ、１回おきの処理間隔を超える頻度で符号化されないようにするステップと、
（ｃ）前記処理間隔中に符号化された各オーディオチャネルを示すために、各処理間隔に関する前記ラウンドロビン履歴を更新するステップと
を備えたことを特徴とするオーディオチャネルを符号化する方法。
【請求項４５】
前記ラウンドロビン履歴を作成するステップは、現行の処理間隔中に符号化されたばかりの各オーディオチャネルを前記ラウンドロビン履歴の中でより低い優先順位で示すステップを含むことを特徴とする請求項４４に記載のオーディオチャネルを符号化する方法。
【請求項４６】
前記ラウンドロビン履歴は、最高の優先順位から最低の優先順位まで降順の優先順位のオーディオチャネルの指示を含み、かつ符号化するオーディオチャネルを選択するステップは、前記ラウンドロビン履歴の中の最高の優先順位から開始して前記位置で示される前記オーディオチャネルをチェックして示される前記オーディオチャネルがアクティブであるかどうかを判定し、アクティブである場合、任意の利用可能なエンコーダを使用して前記オーディオチャネルを符号化するステップであって、アクティブであり、かつ前記ラウンドロビン履歴の中でより高い優先順位を有するオーディオチャネルが、符号化のために初めに選択されるようにするステップを含むことを特徴とする請求項４５に記載のオーディオチャネルを符号化する方法。
【請求項４７】
まだアクティブである特定のオーディオチャネルに関するデータパケットが、処理間隔中に符号化されていない場合、直前の処理間隔中に前記特定のオーディオチャネルのために符号化され伝送されたデータパケットからオーディオデータを複製するステップであって、前記オーディオデータパケットが符号化されなかった前記処理間隔に関して、前記特定のオーディオチャネルのために再生されるべきオーディオデータを提供するステップをさらに備えたことを特徴とする請求項４４に記載のオーディオチャネルを符号化する方法。
【請求項４８】
前記オーディオデータを複製するステップは、前記特定のオーディオチャネルのために前記オーディオデータを再生する際、前記特定のオーディオチャネルのための前記データパケットの受け手によって行われることを特徴とする請求項４７に記載のオーディオチャネルを符号化する方法。
【請求項４９】
前記特定のオーディオチャネルのための前記複製のオーディオパケットは、どの受け手にも伝送されないことを特徴とする請求項４８に記載のオーディオチャネルを符号化する方法。
【請求項５０】
最大で２つのエンコーダ、及び最大で４つの符号化されるべきオーディオチャネルが存在し、各エンコーダは、各処理間隔中に１つしかデータパケットを符号化しないことを特徴とする請求項４４に記載のオーディオチャネルを符号化する方法。
【請求項５１】
請求項４４に記載のステップを行うためのマシン実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項５２】
電子ゲームのプレー中に複数のオーディオチャネルを符号化するためのシステムであって、
（ａ）プロセッサと、
（ｂ）前記プロセッサに、電子ゲームのインスタンスを実行することを含む複数の機能を行わせるためのマシン語命令を記憶する前記プロセッサに結合されたメモリと、
（ｃ）前記プロセッサに結合され、オーディオ信号の入出力のために使用されるオーディオ入力トランスデューサ及びオーディオ出力トランスデューサであって、符号化されて少なくとも１つの受け手に伝送されるようにオーディオ信号を対応するオーディオチャネルにそれぞれが提供するオーディオ入力トランスデューサ、及び電子ゲームの前記プレーに参加する別のプレーヤから受信されたオーディオ信号を再生するためにそれぞれが使用されるオーディオ出力トランスデューサと、
（ｄ）アクティブなオーディオチャネルにおけるオーディオ信号を符号化し、電子ゲームの前記プレーに参加する少なくとも１つの受け手に伝送するために対応するデータパケットを生成することをそれぞれが行う、少なくとも１つの、ただし、符号化されるべきオーディオチャネルの数より少ないエンコーダと
を備え、前記マシン語命令は、前記プロセッサに、
（ｉ）連続する処理間隔中に前記エンコーダによって符号化された前記オーディオチャネルのラウンドロビン履歴を作成することと、
（ｉｉ）１つのエンコーダ当り複数のオーディオチャネルが同時にアクティブである場合、前記ラウンドロビン履歴及びその時のアクティブな前記オーディオチャネルに基づいて各エンコーダで符号化するオーディオチャネルを選択することであって、それにより、アクティブであるオーディオチャネルが、スキップされ、１回おきの処理間隔を超える頻度で符号化されないようにすることと、
（ｉｉｉ）処理間隔中に符号化された各オーディオチャネルを示すために、各処理間隔に関する前記ラウンドロビン履歴を更新することと
を含む複数の機能を行わせることを特徴とするオーディオチャネルを符号化するためのシステム。
【請求項５３】
前記マシン語命令はさらに、前記プロセッサに、現行の処理間隔中に符号化されたばかりの各オーディオチャネルを前記ラウンドロビン履歴の中でより低い優先順位で示すようにさせることを特徴とする請求項５２に記載のオーディオチャネルを符号化するためのシステム。
【請求項５４】
前記ラウンドロビン履歴は、最高の優先順位から最低の優先順位まで降順の優先順位のオーディオチャネルの指示を含み、かつ前記マシン語命令は、前記プロセッサに、前記ラウンドロビン履歴の中の最高の優先順位から開始して順次の位置で示される前記オーディオチャネルをチェックして、示される前記オーディオチャネルがアクティブであるかどうかを判定し、アクティブである場合、任意の利用可能なエンコーダを使用して前記オーディオチャネルを符号化して、アクティブであり、かつ前記ラウンドロビン履歴の中でより高い優先順位を有するオーディオチャネルが、符号化のために初めに選択されるようにさせることを特徴とする請求項５３に記載のオーディオチャネルを符号化するためのシステム。
【請求項５５】
最大で２つのエンコーダ、及び最大で４つの符号化されるべきオーディオチャネルが存在し、各エンコーダは、各処理間隔中に１つしかデータパケットを符号化しないことを特徴とする請求項５２に記載のオーディオチャネルを符号化するためのシステム。
【請求項５６】
電子ゲームに参加する別のプレーヤからのオーディオ内容の受け手とされる少なくとも１つのプレーヤのために可聴オーディオ出力を生成するために、前記電子ゲームのプレー中にオーディオチャネルを復号化する方法であって、
（ａ）受信されたデータパケットを復号化するための選択された数のデコーダをインスタンス化するステップであって、前記データパケットによって伝送された前記オーディオ内容を回復し、各デコーダは異なる聴取チャネルに関連するステップと、
（ｂ）前記聴取チャネルに関連する前記デコーダによって復号化するための１つまたは複数のソースからのデータパケットをそれぞれが含む相異なる聴取チャネルにおける、オーディオソースから受信されたデータパケットのキューを生成するステップと、
（ｃ）あるオーディオソースに関するデータパケットが聴取チャネルにおけるデータパケットのストリームの中で欠落している場合、欠落していた前記データパケットの代わりに使用するため、前記オーディオソースに関する前のデータパケットの内容を複製するステップと、
（ｄ）復号化されるべきデータパケットを前記キューから、ただし、利用可能なデコーダの数を超えることなく選択するステップと、
（ｅ）選択された前記データパケットを、インスタンス化された前記デコーダを使用して復号化するステップと
を備えたことを特徴とするオーディオチャネルを復号化する方法。
【請求項５７】
選択するステップは、各プレーヤが、自身が聴取することを望まない任意の聴取チャネルにマスクをかけることができるようにするステップを含むことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項５８】
選択するステップは、各プレーヤが、キューの中にデータパケットを有する特定のソースを選択的にミュートできるようにするステップを含み、それにより、前記特定のソースからのデータパケットが、前記プレーヤ向けの復号化のために選択されないようにすることを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項５９】
選択するステップは、各プレーヤのために復号化される前記データパケットを前記データパケットのソースに関して前記プレーヤによって割り当てられた任意の優先順位に従ってソートするステップを含むことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項６０】
選択するステップは、各聴取チャネルに含まれる復号化されたときにプレーヤによって聞かれるべき前記データパケットを判定する際、行われている前記電子ゲームによって定義される優先順位を適用するステップを含むことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項６１】
前記データパケットの前記内容のボリュームに応じて前記データパケットを順序付けるステップをさらに備え、選択するステップは、順序付けられた前記キューの中の実質的に無音の内容を含む各データパケットを除去するステップを含むことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項６２】
復号化された前記データパケットを聴取する各プレーヤに関して、復号化するステップは、あらゆる存在しないデータパケットの代わりに聞かれる前記内容として無音の圧縮されたデータを使用して、順序付けられた最初の所定の数の前記データパケットを復号化するステップを含むことを特徴とする請求項６１に記載のオーディオチャネルを復号化する方法。
【請求項６３】
復号化するステップの前に複数のソースからのデータパケットをミキシングするステップをさらに備えたことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項６４】
復号化するステップの後、複数のソースからの内容をミキシングするステップをさらに備えたことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項６５】
（ａ）前記データパケットの前記内容を受信し聴取する各プレーヤ向けの順序付けられたリストを生成するために、前記データパケットを順序付けるステップと、
（ｂ）前記データパケットの前記順序付けられたリストの先頭のデータパケットを現行のプレーヤのために復号化されるように選択するステップであって、
（ｉ）所定の最大数の復号化されたデータパケットにまだ達していない場合に、
（ｉｉ）前記順序付けられたリストが空ではない場合に、及び
（ｉｉｉ）前記順序付けられたリストの先頭のデータパケットが前に選択されていなかった場合に
選択するステップと、
（ｃ）前記所定の最大数に達したかどうかを判定するのに使用される復号化されたデータパケットのカウンタを増分するステップと、
（ｄ）前記順序付けられたリストの前記先頭の前記データパケットを、前記データパケットが出現するそれぞれの順序付けられたリストの中で除去するステップと、
（ｅ）前記データパケットの前記内容を聴取するそれぞれの順次のプレーヤに関して、先行する３つのステップ（ｂ）〜（ｄ）を繰り返すステップと
をさらに備えたことを特徴とする請求項５６に記載のオーディオチャネルを復号化する方法。
【請求項６６】
復号化するステップは、デジタルシグナルプロセッサによって行われることを特徴とする請求項６５に記載のオーディオチャネルを復号化する方法。
【請求項６７】
請求項１３に記載のステップを行うためのマシン実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項６８】
電子ゲームのプレー中に複数の聴取チャネルにおけるデータパケットの中で伝送される圧縮されたデータを復号化するシステムであって、
（ａ）プロセッサと、
（ｂ）前記プロセッサに、電子ゲームのインスタンスを実行することを含む複数の機能を行わせるためのマシン語命令を記憶する前記プロセッサに結合されたメモリと、
（ｃ）前記プロセッサに結合され、オーディオ信号の入出力のために使用されるオーディオ入力トランスデューサ及びオーディオ出力トランスデューサであって、符号化されて少なくとも１つの受け手に伝送されるようにオーディオ信号を対応するオーディオチャネルにそれぞれが提供するオーディオ入力トランスデューサ、及び電子ゲームの前記プレーに参加する別のプレーヤを含むソースから受信されたオーディオ信号を再生するためにそれぞれが使用されるオーディオ出力トランスデューサと、
（ｄ）システムによって受信された前記データパケットを復号化して前記データパケットによって伝送された前記オーディオ内容を回復するために使用される、選択された数の、異なる聴取チャネルにそれぞれが関連するデコーダと
を備え、前記マシン語命令は、前記プロセッサに、
（ｉ）前記聴取チャネルに関連する前記デコーダによって復号化するための１つまたは複数のソースからのデータパケットをそれぞれが含む相異なる聴取チャネルにおける、オーディオソースから受信されたデータパケットのキューを生成することと、
（ｉｉ）あるオーディオソースに関するデータパケットが聴取チャネルにおけるデータパケットのストリームの中で欠落している場合、欠落していた前記データパケットの代わりに使用するため、前記オーディオソースに関する前のデータパケットの内容を複製することと、
（ｉｉｉ）復号化されるべきデータパケットを前記キューから、ただし、利用可能なデコーダの数を超えることなく選択することと、
（ｉｖ）選択された前記データパケットを前記デコーダを使用して復号化することと
を含む複数の機能を行わせることを特徴とする圧縮されたデータを復号化するシステム。
【請求項６９】
前記マシン語命令はさらに、前記プロセッサに、各プレーヤが、自身が聴取することを望まない任意の聴取チャネルにマスクをかけることができるようにさせることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７０】
前記マシン語命令はさらに、前記プロセッサに、各プレーヤがキューの中にデータパケットを有する特定のソースを選択的にミュートできるようにさせて、これにより、前記特定のソースからのデータパケットが、前記プレーヤ向けの復号化のために選択されないようにすることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７１】
前記マシン語命令はさらに、前記プロセッサに、各プレーヤのために復号化される前記データパケットを前記データパケットのソースに関して前記プレーヤによって割り当てられた任意の優先順位に従ってソートさせることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７２】
前記マシン語命令はさらに、前記プロセッサに、各聴取チャネルに含まれる復号化されたときにプレーヤによって聞かれるべき前記データパケットを判定する際、行われている前記電子ゲームによって定義される優先順位を適用させることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７３】
前記マシン語命令はさらに、前記プロセッサに、前記データパケットの前記内容のボリュームに応じて前記データパケットを順序付けさせ、順序付けられた前記キューの中の実質的に無音の内容を含む各データパケットを除去するようにさせることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７４】
復号化された前記データパケットを聴取する各プレーヤに関して、前記マシン語命令は、前記プロセッサに、あらゆる存在しないデータパケットの代わりに聞かれる前記内容として無音の圧縮されたデータを使用して、順序付けられた最初の所定の数の前記データパケットを復号化させることを特徴とする請求項７３に記載の圧縮されたデータを復号化するシステム。
【請求項７５】
前記マシン語命令はさらに、前記プロセッサに、データパケットを復号化する前に、複数のソースからの前記データパケットの内容をミキシングさせることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７６】
前記マシン語命令はさらに、前記プロセッサに、データパケットを復号化した後、複数のソースから受信された前記内容をミキシングさせることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７７】
前記マシン語命令はさらに、
（ａ）前記データパケットの前記内容を受信し聴取する各プレーヤ向けの順序付けられたリストを生成するために、前記データパケットを順序付けることと、（ｂ）前記データパケットの前記順序付けられたリストの先頭のデータパケットを現行のプレーヤのために復号化されるように選択することであって、
（ｉ）所定の最大数の復号化されたデータパケットにまだ達していない場合に、
（ｉｉ）前記順序付けられたリストが空ではない場合に、及び
（ｉｉｉ）前記順序付けられたリストの先頭のデータパケットが前に選択されていなかった場合に
選択することと、
（ｃ）前記所定の最大数に達したかどうかを判定するのに使用される復号化されたデータパケットのカウンタを増分することと、
（ｄ）前記順序付けられたリストの前記先頭の前記データパケットを、前記データパケットが出現するそれぞれの順序付けられたリストの中で除去することと、
（ｅ）前記データパケットの前記内容を聴取するそれぞれの順次のプレーヤに関して、先行する３つのステップ（ｂ）〜（ｄ）を繰り返すことと
を前記プロセッサに行わせることを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【請求項７８】
各デコーダは、デジタルシグナルプロセッサを含むことを特徴とする請求項６８に記載の圧縮されたデータを復号化するシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に、電子ゲームのプレーヤの間におけるコミュニケーションに係る、プレーヤが口頭でコミュニケーションできるようにする方法及び口頭のコミュニケーションを可能にするシステムに関する。
【０００２】
より具体的には、プレーヤがゲームに参加するのを可能にするように一緒に結合されたマルチプレーヤ電子ゲームデバイス間でデータを伝送するネットワークを介する音声コミュニケーションを含め、１つまたは複数のマルチプレーヤ電子ゲームデバイスを使用するプレーヤ間の音声コミュニケーションを円滑にするマルチプレーヤ電子ゲームシステムに関連した、プレーヤが口頭でコミュニケーションできるようにする方法、口頭のコミュニケーションを可能にするシステム、オーディオチャネルを符号化する方法、オーディオチャネルを符号化するためのシステム、オーディオチャネルを復号化する方法、圧縮されたデータを復号化するシステム、及び記録媒体に関する。
【０００３】
【従来の技術】
１名または複数名の他の人々で非電子ゲーム、例えば、ブリッジなどのカードゲームを行っているとき、ゲーム中にプレーヤ間の口頭のコミュニケーションを介して生じる社交的対話は、通常、ゲームの楽しみをずっと大きくする。また、口頭のコミュニケーションは、ゲームプレーの要素でもある。というのは、ゲーム中に相手に対してプレーヤによって行われるコメントにより、相手が集中力を失い、手際が悪くなることが引き起こされる効果があり、他方、チームメンバに対して行われたコメントが励ましを与え、チームメンバのプレーの質を増進させることが可能であるからである。したがって、ゲームをする個人間のコミュニケーションは、明らかにゲームをする体験の重要な要素である。
【０００４】
ゲームプレーにそれほど重要なプレーヤ間の口頭の言葉のやり取りは、プレーヤが、インターネット及びその他のネットワークリンクを介して電子ゲームを行い始めた当初、初めは欠如していた。異なるサイトにいるプレーヤは、一般に、互いにコミュニケーションをとることができなかった。というのは、プレーヤのパーソナルコンピュータ（ＰＣ）は、ゲームのプレーに関連するデータだけをネットワークを介して伝えたからである。このように、同じ場所で人々によってプレーされるゲームの大変重要な面である、口頭のコミュニケーション及び関連した社交的対話が失われることにより、インターネットを介して行われるゲームをそれほど面白くないものとしていた。この問題に対処するため、ゲームプレー中にインターネット又は他のネットワークを介するＰＣ間の音声コミュニケーションをサポートするハードウェア及びソフトウェアが開発された。ほぼ同じ頃に、インターネットまたはその他のネットワークを介して音声を伝送して（すなわち、ＶｏＩＰ（ｖｏｉｃｅ　ｏｖｅｒ　ＩＰ））、従来の電話機の長距離電話の費用を被ることなく、ネットワークで接続されたパーティ間のコミュニケーションを可能にする技術が開発された。この研究は、Ｈ．３２３規格、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）、及びＭＧＣＰ／ＭＥＧＡＣＯ（メディアゲートウェイ制御プロトコル／メディアゲートウェイコントローラ）仕様を含め、ＶｏＩＰ通信をサポートする様々なプロトコルの作成をもたらした。ＶｏＩＰ用に開発された技術は、ネットワーク上のＰＣ電子ゲームのプレーヤ間の口頭のコミュニケーションを可能にするスキームに一般に適用可能であり、またそのようなスキームにおいて使用されてきた。ゲームプレー中に接続されたＰＣ間の音声コミュニケーションを提供するシステムの例には、マイクロソフトコーポレーションのＳＩＤＥ　ＷＩＮＤＥＲ　ＧＡＭＥ　ＶＯＩＣＥ（商標）、マインドメーカ（Ｍｉｎｄｍａｋｅｒ）インコーポレーテッドのＧＡＭＥＣＯＭＭＡＮＤＥＲ　２（商標）のデバイス及びソフトウェア、ＴＥＡＭＳＯＵＮＤ（商標）ソフトウェア、ゲームスパイインダストリーズ（ＧａｍｅＳｐｙＩｎｄｕｓｔｒｉｅｓ）のＲＯＧＥＲ　ＷＩＬＣＯソフトウェア、及びエイリアンウェア　テクノロジー（Ａｌｉｅｎｗａｒｅ　Ｔｅｃｈｎｏｌｏｇｙ）のＦＩＲＳＴ　ＣＯＮＡＣＴソフトウェアが含まれる。以上の製品によって提供される音声コミュニケーションにより、インターネットまたはその他のネットワークを介して接続されたＰＣ上でゲームを行うことの楽しみが大幅に増す。以上のシステムの一部は、音声データがネットワークを介してＰＣ間で直接に転送されるピアツーピアモードで動作する一方、他の一部は、１つのゲームプレーヤのＰＣから音声データを受信し、その音声データをネットワークを介して、ゲームを行うためにそのネットワークに接続されている１つまたは複数の他のＰＣに転送する。
【０００５】
以上のシステムは、１つのＰＣ当り１名のプレーヤだけにコミュニケーションを提供するので、各ＰＣが、独自のネットワークストリームの音声データを生成し、このネットワークストリームが、互いのプレーヤの他のＰＣに送信される（または音声サーバに送信され、次に、このサーバが、その音声データを互いのプレーヤのＰＣに送信する）。したがって、この手法は、相当なネットワークデータオーバーヘッドをもたらす。
【０００６】
現在、ＰＣゲーム音声コミュニケーションのための従来技術のシステムで、インターネットまたは他のネットワークを介して行われるゲームにおいて１つのＰＣ当り複数名のプレーヤを可能にするものは存在せず、したがって、従来の技術は、１つのＰＣ当りマルチプレーヤの（ｍｕｌｔｉｐｌａｙｅｒ−ｐｅｒ−ＰＣ）音声コミュニケーション機能をサポートしていない。また、そのようなマルチプレーヤＰＣシステムは、あるＰＣ上の数名のプレーヤに関して既存の音声コミュニケーションプロトコルを使用して開発されたとすると、過大な量の計算リソースを必要とする可能性が高い。ＰＣ上のゲームのすべてのプレーヤに音声コミュニケーションに必要なリソースを割り振ることは、ＰＣが、非常に高速のプロセッサ、大量のメモリ、及び高速のビデオドライバカードを有しているのでない限り、ゲームプレーの質に悪影響を与えるであろう。
【０００７】
ＰＣとは対照的に、専用のゲームコンソールは、しばしば、高性能のＰＣの処理能力及び可用メモリを有さず、したがって、以上の問題は、各ゲームコンソール上で複数のプレーヤによる音声コミュニケーションをサポートするスキームを開発する際に、いっそう大きな問題である。音声処理に必要とされるリソースが、音声コミュニケーションに参加するプレーヤの数が変化するにつれて規定の限度を超えて増大することが許されないよう、ゲーム機能及びゲーム設計に適切なように、ゲームコンソール上で音声コミュニケーションが可能なプレーヤの数とは独立に、音声コミュニケーションに必要なメモリ及びその他のコンピュータリソースの要件に固定されたレベルを割り振ることが望ましい。また、サイトにおけるゲームの各インスタンスに関して複数のプレーヤ間の音声コミュニケーションを可能にし、各プレーヤが、自身が誰と口頭でコミュニケーションをとるか（話すことと聞くことの両方）を制御できるようにし、またマルチプレーヤゲームコンソール間の音声コミュニケーションに必要なネットワーク帯域幅を小さくするためにゲームのそのインスタンスからの音声データのすべてを結合して単一のネットワークデータストリームにすることも有利である。さらに、サイトにおける単一のゲームインスタンスに関して複数のプレーヤ間で、音声データのエンコーダまたはデコーダなどのあるリソースを共用することが望ましい。
【０００８】
ゲームグラフィックスの品質が向上するにつれ、現実感に関係する他の機能を維持することがより重要になる。１つのそのような機能は、ゲームプレー中にリップ同期（ｌｉｐ−ｓｙｎｃ）情報または他のビシーム（ｖｉｓｅｍｅ）（リップ位置）情報に音声データを提供して、ゲームにおいて表示されるグラフィックキャラクタのリップが、ゲーム表示におけるグラフィックキャラクタによって表されグラフィックキャラクタを制御するプレーヤの、語と同期して動くようにする機能である。ただし、既存の音声コミュニケーションシステムは、通常、リップ同期を可能にするデータを伝送せず、この結果、音声コミュニケーションを受け取るプレーヤには、話しているプレーヤに対応するゲームにおけるキャラクタのリップが、話し手の語に同期して動くのが見られない。
【０００９】
音声コミュニケーションは、一般に、望ましい機能であるが、特定のプレーヤによって乱用された場合、煩わしいものとなり、他のプレーヤが享受するゲームの楽しみを減じる可能性がある。また、従来の技術は、プレーヤが、迷惑なプレーヤによって使用されるゲームコンソールに関わらず、その迷惑なプレーヤが参加者であるあらゆるゲーム中にプレーヤに話しかける、またはプレーヤの声を聞くのをブロックすることも可能にしない。様々な人々が、他者の迷惑な挙動に対して様々な程度の許容度を有する。しかし、何らかの理由で特定の他のプレーヤの声を聞かない、または話しかけないことを選択したあらゆるプレーヤは、ゲームにおける他のプレーヤとコミュニケーションをとる能力を手放すことなく、その特定の他のプレーヤとのコミュニケーションを防止する能力を有さなければならない。プレーヤは、特定の他のプレーヤが過度の冒涜的な言葉または性的に露骨な言葉を使用する、または中傷である、または社会的に容認できないと自身が感じる言葉を使用する、またはそのようなコメントをすると感じるため、憤慨する可能性がある。
【００１０】
親はまた、子供が、ゲームプレー中に音声コミュニケーションに参加するのをブロックして、その子供が冒涜的な言葉にさらされるのを回避することを、または有害な目的でゲームプレーの範囲外で子供に接触しようと試みる可能性がある誰かとの口頭のコミュニケーションを除外することを、望む可能性がある。子供の音声コミュニケーションのこの親によるブロック処理は、オンラインゲームサービス上で記憶されなければならず、それでその子供が異なるゲームコンソールからそのオンラインサービスに接続した場合でも、有効なままでなければならない。従来技術のゲーム音声コミュニケーションシステムでは、マルチプレーヤゲームコンソールを使用してゲームに参加している、子供などの選択されたプレーヤによる口頭のコミュニケーションをブロックすることが可能ではない。
【００１１】
インターネットまたはその他のネットワークを介してゲームを行っている際中に、プレーヤの口頭の振舞いが（他のプレーヤから受け取られた苦情の数に基づき）あまりにもひどくなり、正当化される場合、オンラインゲームサービスは、そのプレーヤが、そのオンラインゲームサービスを介してゲームを行っている際中に音声のコミュニケーションに参加するのをある期間にわって防止することができなければならず、また、そのプレーヤの口頭の振舞いに関する苦情を引き続き受けることでさらに正当化される場合、そのプレーヤが音声コミュニケーションを使用するのを永久的に禁止処分にすることができなければならない。現行の音声コミュニケーションシステムでは、このレベルの制御を各オンラインゲームサービスにおいて適用して、使用されるエイリアス、またはプレーヤがオンラインゲームサービスを通じてゲームに参加するのに使用するゲームコンソールに関わらず、プレーヤを禁止処分にすることができない。
【００１２】
音声コミュニケーションシステムは、ゲームを行うＰＣ上の用途で周知であるが、ゲームコンソールは、異なるアーキテクチャを有し、可用システムリソースに対する明確な限界を伴う。ほとんどのゲームコンソールは、ゲームの単一のインスタンス上、すなわち、同一のコンソール上で複数のプレーヤを可能にする。ゲームコンソールは、インターネット、またはその他のネットワークを介して相互接続されたとき、好ましくは、ゲームコンソール上の複数のプレーヤの各人に音声コミュニケーションを提供することができなければならない。ＰＣ上のゲームプレー中の音声コミュニケーションを可能にするように開発された従来の技術の使用は、計算リソースがより限られており、かつ複数のプレーヤに関する音声コミュニケーションに対応する必要性があるため、ゲームコンソール上では受け入れることができない。したがって、前述した問題に対処する１つまたは複数のマルチプレーヤゲームコンソール上で行われるゲームに関して音声コミュニケーションを可能にする方法及びシステムの必要性が、明らかに存在する。
【００１３】
いくつかの文献に上述のような従来の技術に関連した技術内容が開示されている（例えば、非特許文献１参照）。
【００１４】
【非特許文献１】
Ｍｉｎｄｍａｋｅｒ，　Ｉｎｃ．、”Ｇａｍｅ　Ｃｏｍｍａｎｄｅｒ　２：　Ｅｘｐｅｒｉｅｎｃｅ　Ｔｈｅ　Ｍｏｓｔ　Ｐｏｗｅｒｆｕｌ　ａｎｄ　Ｆｌｅｘｉｂｌｅ　Ｖｏｉｃｅ　Ｓｏｌｕｔｉｏｎ　ｆｏｒ　Ｇａｍｅｓ．”、５ｐｐ．、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｇａｍｅｃｏｍｍａｎｄｅｒ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｇｃ２．ｈｔｍｌ＞
【００１５】
【発明が解決しようとする課題】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【００１６】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、ゲームデバイス上の複数プレーヤのリアルタイムな音声コミュニケーションの使用を実現する、プレーヤが口頭でコミュニケーションできるようにする方法及び口頭のコミュニケーションを可能にするシステムを提供することにある。
【００１７】
【課題を解決するための手段】
前述したとおり、ネットワークを介して接続されたＰＣ上でゲームを行う１名の個人と、別個のＰＣを各人が使用する１名または複数名のゲームの他のプレーヤとの間の音声コミュニケーションは、周知である。これに対して、本発明により、ゲームコンソール上でゲームを行う複数のプレーヤが、そのゲームを行う１名または複数名の他のプレーヤとローカルで、かつ／またはネットワークを介して口頭でコミュニケーションをとることができるようになる。より多くの人々がゲームに加わるにつれ、口頭のコミュニケーションをサポートするのに余りにも大きな計算リソースが要求されることになるのを回避するため、本発明は、ゲームの設計者が、ゲームのプレーヤ間の口頭のコミュニケーションをサポートするのに使用される計算リソースに対して事前定義された限度を確立することができるようにする。
【００１８】
ゲームのプレーヤ間の口頭のコミュニケーションをサポートするのに各マルチプレーヤゲームコンソールで使用するための特定のハードウェアが提供される。口頭でコミュニケーションをとる各プレーヤは、マイクロホン（より一般的には、オーディオセンサ）及びヘッドホン（より一般的には、オーディオトランスデューサ）を含むヘッドセットを備える。ヘッドセットは、音声コミュニケーションモジュールに結合され、このモジュールは、一実施形態においてゲームコントローラに接続されるか、または別の実施形態においてゲームコントローラの一部として内部に含まれる。マイクロホンからの入力信号が、マルチプレーヤゲームコンソール内部のエンコーダによって圧縮され、デジタル化される。次に、デジタル化され、圧縮された信号は、音声コミュニケーションチャネルを介して、宛先の受け手である別のプレーヤに伝送される。デコーダが、その圧縮された信号を圧縮解除して、その別のプレーヤのヘッドホンに印加される出力信号を生成して、元々生成された、音声コミュニケーションの伝送元であるプレーヤのマイクロホンに入射したサウンドに対応する可聴サウンドが生成される。本明細書で、また特許請求の範囲で使用する「音声コミュニケーション」という用語は、「口頭のコミュニケーション」という用語と同義であり、区別なく使用されるものとする。また、「口頭のコミュニケーション」または「音声コミュニケーション」は、ゲームに参加するプレーヤによって生成される話された語及び句、ならびにぶつぶつ言う声、叫び声などの他のサウンドまたは発声の伝達を包含するものとする。
【００１９】
マルチプレーヤゲームコンソール上で口頭のコミュニケーションを処理することに割り振られる計算リソースのレベルは、好ましくは、ゲームを行いながら音声コミュニケーションを使用するプレーヤの数とは独立であるように事前定義されており、固定されている。この特徴により、ゲーム中に口頭でコミュニケーションをとるプレーヤの数の増加が、ゲームプレーのその他の態様の品質に悪影響を与えないことが保証される。
【００２０】
デジタル圧縮信号を含むデータは、１つまたは複数のゲームコンソール上でゲームを行う１名または複数名の宛先の受け手に伝送されるとき、特定の形式になっている。デジタル圧縮信号は、直接リンク、またはインターネットなどのネットワークを介して伝送される。ゲームに依存して、各プレーヤが、ゲームのその他のプレーヤのなかから口頭のコミュニケーションの宛先の受け手を選択できるようにすることが可能である。例えば、チームのメンバが、互いに、またチームリーダと１つの音声チャネルを介して口頭でコミュニケーションをとることができるが、チームリーダは、それと同じ音声チャネルを介してチームメンバとコミュニケーションをとるか、または異なる音声チャネルを介して別のチームリーダとコミュニケーションをとるかを選択的に行うことができる。
【００２１】
好ましくは、符号化するステップは、アナログ信号をデジタル信号に変換し、そのデジタル信号を圧縮して適切な形式で圧縮されたデジタル信号を生成するステップを含む。同様に、復号化するステップは、好ましくは、圧縮された信号を圧縮解除して圧縮解除されたデジタル信号を生成し、その圧縮解除されたデジタル信号を、オーディオトランスデューサを駆動するのに使用される出力信号に変換するステップを含む。
【００２２】
圧縮された信号のために使用される形式は、複数のオーディオデータパケットを含む。各オーディオデータパケットは、オーディオ時間フレーム全体に広がる。好ましくは、事前定義された数の符号化インスタンスが、各オーディオ時間フレーム中にゲームコンソール上で動作している。事前定義された数は、好ましくは、ゲームコンソールを使用し、他のプレーヤと口頭でコミュニケーションをとるのに口頭の発言を生成しているプレーヤの総数より少ない。ゲームコンソール上のプレーヤの口頭の発言は、ゲームコンソール上で、事前定義された数の符号化インスタンスより多くのプレーヤが、連続するオーディオ時間フレームの中で話している場合、連続するオーディオ時間フレームの中で符号化される口頭の発言を選択する際にラウンドロビン選択が適用されるような仕方で符号化される。行われているゲームが、一度にアクティブである符号化インスタンスの事前定義された数を判定する。
【００２３】
他のマルチプレーヤゲームコンソールから受信された符号化されたデータストリームの並列復号化を１つまたは複数のミクサと連携して使用して、プレーヤのヘッドホンを駆動する出力信号を生成することができる。
【００２４】
選択されたプレーヤを１つまたは複数のチャネルに割り当てることが可能であり、また共通チャネルに割り当てられたプレーヤが、互いに選択的に口頭でコミュニケーションをとることができるようにされる。一実施形態では、各プレーヤは、そのプレーヤが他のプレーヤから口頭のコミュニケーションを受信することができる１つまたは複数の聴取者チャネルに割り当てられる。さらに、各プレーヤは、口頭の発言が他のプレーヤに伝送される１つまたは複数の話者チャネルに割り当てられる。マルチプレーヤゲームコンソール上の特定のプレーヤによって聞かれる口頭の発言は、その特定のプレーヤの聴取者チャネルを口頭の発言を行うプレーヤの話者チャネルと論理的に結合（すなわち、ＡＮＤにする）ことによって判定される。
【００２５】
また、この方法は、ゲームにおけるアニメーションのグラフィックキャラクタの口唇部分（ｏｒａｌ　ｐｏｒｔｉｏｎ）（例えば、口）を制御するための口唇同期データを提供するステップも含む。口唇同期データは、ゲーム中に表示されるアニメーションのグラフィックキャラクタの口唇部分を制御して、口唇部分が、アニメーションのグラフィックキャラクタを制御するプレーヤの口頭の発言と同期して動くようにするのに使用される。
【００２６】
プレーヤは、選択された他のプレーヤとの口頭のコミュニケーションを防止することができるようにされる。選択されたプレーヤとの口頭のコミュニケーションは、行われている現行のゲームだけにおいて、またはプレーヤと選択された他のプレーヤがともに参加するあらゆるゲームにおいて防止することが可能である。
【００２７】
本発明のさらなる態様は、ゲームを行っているプレーヤ間の口頭のコミュニケーションを可能にするシステムを対象とする。このシステムは、プロセッサ及びメモリを有するマルチプレーヤゲームコンソールを含む。メモリの中には、プロセッサが、ゲームのインスタンスを実行することを含め、複数の機能を実行するようにさせるためのマシン語命令が記憶される。口頭コミュニケーション入出力デバイスが、ゲーム中に口頭でコミュニケーションをとる各プレーヤに関して含まれ、各口頭コミュニケーション入出力デバイスは、サウンドセンサに入射するサウンドを示す入力信号を生成するサウンドセンサ、及び印加される出力信号に応答して可聴サウンドを生成するサウンドトランスデューサを有する。メモリの中のマシン語命令は、プロセッサに、口頭のコミュニケーションを可能にする前述した方法のステップと一般的に整合する機能を実行させる。
【００２８】
本発明の以上の態様及び付随する利点の多くは、添付の図面と併せて考慮されるとき、以下の詳細な説明を参照することによってよりよく理解されるにつれ、より明白となるであろう。
【００２９】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００３０】
本発明を実施するための例としてのゲームシステム
図１に示すように、例としての電子ゲームシステム１００は、ゲームコンソール１０２、及びコントローラ１０４ａ及び１０４ｂなどの最高で４つのユーザ入力デバイスをサポートする。ゲームコンソール１０２は、内部ハードディスクドライブ（この図では示さず）、及び光記憶ディスク１０８によって代表される様々な形態のポータブル光記憶媒体をサポートする。適切なポータブル記憶媒体の例には、ＤＶＤ（ｄｉｇｉｔａｌ　ｖｅｒｓａｔｉｌｅ　ｄｉｓｋ）ディスク、及びＣＤ（ｃｏｍｐａｃｔ　ｄｉｓｃ［ｄｉｓｋ］）−ＲＯＭ（ｒｅａｄ　ｏｎｌｙ　ｍｅｍｏｒｙ）ディスクが含まれる。このゲームシステムでは、ゲームプログラムが、好ましくは、ゲームコンソールで使用されるためにＤＶＤディスク上で配布されるが、他の記憶媒体が代わりに使用可能であること、または他のプログラムをインターネットまたはその他のネットワークを介してダウンロードするのが可能であることが企図される。
【００３１】
ゲームコンソール１０２の前面上には、コントローラに電気的に接続するために４つのコネクタ１１０ａ、１１０ｂ、１１０ｃ、１１０ｄが提供されている。他のタイプのコネクタまたは無線接続を代わりに使用することが可能なことも企図されている。また、電源ボタン１１２及びディスクトレイイジェクト（ｄｉｓｃ　ｔｒａｙ　ｅｊｅｃｔ）ボタン１１４も、ゲームコンソール１０２の前面上に配置されている。電源ボタン１１２は、ゲームコンソールへの電力の印加を制御し、またイジェクトボタン１１４は、ポータブル媒体ドライブ１０６のトレイ（図示せず）の開閉を交互に行って記憶ディスク１０８の挿入及び取出しを可能にし、そのディスク上のデジタルデータを読み取ってメモリにロードすること、またはゲームコンソールが使用するためにハードドライブ上に記憶することを可能にする。
【００３２】
ゲームコンソール１０２は、テレビジョン、またはその他の表示モニタ、またはスクリーン（図示せず）に、Ａ／Ｖ（ａｕｄｉｏ／ｖｉｓｕａｌ）インタフェースケーブル１２０を介して接続する。電力ケーブルプラグ１２２が、従来の交流ラインソース（図示せず）に接続されたとき、ゲームコンソールに電力を伝える。ゲームコンソール１０２は、イーサネット（登録商標）接続を介してネットワーク及び／またはインターネットに、またはブロードバンド接続を介して、データを転送するデータコネクタ１２４をさらに備えていることが可能である。あるいは、モデム（図示せず）を使用してデータをネットワーク及び／またはインターネットに転送することが可能であることが企図される。さらなる代案として、ゲームコンソールをイーサネット（登録商標）クロスオーバー（ｃｒｏｓｓ−ｏｖｅｒ）ケーブル（図示せず）を介して別のゲームコンソールに直接にリンクすることが可能である。
【００３３】
各コントローラ１０４ａ及び１０４ｂは、リード線を介して（または、別の企図される実施形態では、別法として、無線インタフェースを介して）ゲームコンソール１０２に結合される。図示した実施形態では、コントローラは、ユニバーサルシリアルバス（ＵＳＢ）対応であり、ＵＳＢケーブル１３０を介してゲームコンソール１０２に接続される。ゲームコンソール１０２は、ゲームソフトウェアと対話し、ゲームソフトウェアを制御するための多種多様なユーザデバイスのいずれかを備えていることが可能である。図１に示したとおり、各コントローラ１０４ａ及び１０４ｂは、親指スティック１３２ａ、１３２ｂ、１３２ｃ、Ｄパッド１３４、ボタン１３６、及び２つのトリガ１３８を備えている。以上のコントローラは、単に代表的なものであり、ゲームコンソール１０２を制御するために、他のゲーム入力機構及びゲーム出力機構を図１で示したものの代わりに用いること、あるいは図１で示したものに加えて使用することが可能である。
【００３４】
取外し可能な機能ユニットまたは機能モジュールをオプションとしてコントローラ１０４ａ、１０４ｂの中に挿入して追加の機能を提供することが可能である。例えば、ポータブルメモリユニット（図示せず）により、ユーザは、ゲームパラメータを記憶し、そのポータブルメモリユニットを他のコンソール上のコントローラの中に挿入することによって別のゲームコンソール上でゲームをするためにそのパラメータを搬送することができるようになる。コントローラで使用するために、他の取外し可能な機能ユニットが利用可能である。本発明に関連して、音声コミュニケーションモジュール１４０を備えた取外し可能な機能ユニットが使用されて、ユーザが、ローカルに、及び／またはネットワークを介して他のユーザと口頭でコミュニケーションをとることができるようになる。音声コミュニケーションモジュール１４０には、ヘッドセット１４２が接続され、ヘッドセット１４２は、好ましくは、入射するサウンドに応答して入力信号を生成するブーム（ｂｏｏｍ）マイクロホン１４４または他のタイプのオーディオセンサ、及びゲームコンソールからの出力信号に応答して可聴サウンドを生成するためのヘッドホン１４６または他のタイプのオーディオトランスデューサを含む。企図されている別の実施形態（図示せず）では、音声コミュニケーション能力は、他の点でコントローラ１０４ａ及び１０４ｂと全般的に同様であるコントローラ（図示せず）の欠くことのできない部分として含まれる。図１に示したコントローラは、２つの取外し可能な機能ユニットまたは機能モジュールを収容するように構成されている。ただし、２つより多い、または少ないモジュールを代わりに使用することも可能である。
【００３５】
ゲームシステム１００は、もちろん、ゲームを行うことができるが、ＣＤ及びＤＶＤ上の音楽及びビデオを再生することも可能である。ハードディスクドライブ上に記憶された、またはドライブ１０６において光記憶ディスク１０８から読み取られる、またはオンラインソースからの、または機能ユニットまたは機能モジュールからのデジタルデータを使用して、ゲームコントローラによって他の機能を実施するのが可能であることが企図されている。
【００３６】
本発明を実施するための機能構成要素
次に、図２を参照すると、機能ブロック図が、例として、どのように構成要素が提供されて、マルチプレーヤゲームコンソール上の電子ゲームのプレー中にプレーヤ間の音声コミュニケーションまたは口頭のコミュニケーションが容易になるかを示している。前述したとおり、ゲームコンソール１００のこの実施形態は、各コンソール上に最大で４名のプレーヤを有することが可能であり、また各プレーヤが、コントローラ及び音声コミュニケータを備えていることが可能である。音声コミュニケーションモジュール１４０ａの詳細を関連のコントローラ１０４ａに関連して示している。コントローラ１０４ｂ、１０４ｃ、及び１０４ｄ（ゲームコンソール１００に結合されている場合）が、オプションとして、それぞれ、コントローラ１０４ａに結合されているもののような対応する音声コミュニケーションモジュールを含むことが可能であることを理解されたい。現行の好適実施形態では、音声コミュニケーションモジュール１４０ａは、デジタル信号プロセッサ（ＤＳＰ）１５６、アナログ−デジタル変換器（ＡＤＣ）１５８、デジタル−アナログ変換器（ＤＡＣ）１６１、及びユニバーサルシリアルバス（ＵＳＢ）インタフェース１６３を含む。入射する環境におけるサウンドに応答して、マイクロホン１４４は、ＡＤＣ１５８に入力されるアナログ出力信号を生成し、ＡＤＣ１５８は、そのアナログ信号を対応するデジタル信号に変換する。ＡＤＣ１５８からのデジタル信号は、さらなる処理のためにＤＳＰ１５６に入力され、ＤＳＰの出力が、コントローラ１０４ａに接続するためにＵＳＢインタフェース１６３に印加される。この実施形態では、音声コミュニケーションモジュール１４０ａは、ＵＳＢ接続（別個に図示せず）を介してコントローラ１０４ａ上の機能ユニットポートまたは機能モジュールポートに接続する。同様に、ゲームコンソール１００から来るデジタルサウンドデータが、コントローラ１０４ａを介して伝送されて、ＵＳＢインタフェース１６３に印加され、インタフェース１６３が、そのデジタル信号をＤＳＰ１５６に伝送し、ＤＳＰ１５６がＤＡＣ１６１に伝送する。ＤＡＣ１６１は、そのデジタル信号をヘッドホン１４６を駆動するのに使用される対応するアナログ信号に変換する。
【００３７】
マルチプレーヤゲームコンソール１００を参照すると、いくつかの重要な機能構成要素が示されている。ただし、本発明に妥当な他の機能構成要素も含まれるが、図示していないことを理解されたい。具体的には、ゲームコンソール１００は、ＣＰＵ（ｃｅｎｔｒａｌ　ｐｒｏｃｅｓｓｉｎｇ　ｕｎｉｔ）１５０、ならびにＲＯＭとＲＡＭ（ｒａｎｄｏｍ　ａｃｃｅｓｓ　ｍｅｍｏｒｙ）をともに含むメモリ１５２を含む。また、ＤＳＰ１５４も提供されている。マイクロホン１４４からのアナログ信号に応答してＡＤＣ１５８によって生成されるデジタル信号が、コントローラ１０４ａを介してＣＰＵ１５０に伝送され、ＣＰＵ１５０は、ゲームコンソール上のイーサネット（登録商標）ポート（図２に示さず）を通じ、ブロードバンド接続を介して他のローカルな音声コミュニケーションモジュール及び他のゲームコンソールに伝送するため、その音声ストリーム信号の符号化を取り扱う。
【００３８】
代替の実施形態は、音声コミュニケーションモジュール１４０ａ内部のＤＳＰ１５６を使用して、マイクロホン１４４からのアナログ信号に応答してＡＤＣ１５８によって生成されたデジタル信号を符号化する。次に、符号化されたデータは、コントローラ１０４ａを介してＣＰＵ１５０に伝送され、ＣＰＵ１５０は、この場合も、ゲームコンソール上のブロードバンド接続を介する他のローカルな音声コミュニケーションモジュール及び他のゲームコンソールへの符号化されたデータの伝送を取り扱う。
【００３９】
マルチプレーヤゲームコンソール１００は、クロスオーバーイーサネット（登録商標）ケーブルを使用して別のゲームコンソールに直接に接続するか、あるいはハブ、スイッチ、またはその他の同様のデバイスを使用して、より従来どおりのネットワークを介して１つまたは複数の他のマルチプレーヤゲームコンソールに接続することが可能であり、かつ／または適切なケーブルモデム、デジタル加入者回線（ＤＳＬ）接続、またはその他の適切なインタフェースのブロードバンド接続を介してインターネットまたはその他のネットワークに接続することが可能である。マルチプレーヤゲームコンソール１００が、モデム（図示せず）を介してインターネットまたはその他のネットワークに接続される代替の実施形態も企図されている。直接接続またはネットワーク接続を介してパケットとして伝送されるデジタル信号が、ゲームコンソール１００上のイーサネット（登録商標）ポートを介して（または同じゲームコンソールに接続された他の音声コミュニケーションモジュール及びコントローラから）ＣＰＵ１５０に入力され、ＣＰＵによって処理されてデータパケットが復号化され、出力ミキシングのためにＤＳＰ１５４に印加されるデジタルサウンドデータが回復される。ＤＳＰ１５４からの信号は、ＵＳＢインタフェース１６３を介して入力するために、その音声コミュニケーションの受け手であるプレーヤのための宛先の音声コミュニケーションモジュールに伝送される。
【００４０】
代替の実施形態は、ＣＰＵを使用してコントローラ１０４ａを介して宛先の音声コミュニケーションモジュール１４０ａに符号化されたデータパケットを伝送する。次に、符号化されたデータパケットは、音声コミュニケーションモジュール１４０ａ内部のＤＳＰ１５６によって復号化され、結果の復号化された信号がＤＡＣ１６１に伝送され、ＤＡＣ１６１が、ヘッドホン１４６を駆動する対応するアナログ信号を生成する。
【００４１】
さらに別の企図される代替形態では、各プレーヤに関するヘッドホン及びマイクロホンが、ゲームコンソールに直接に結合され、音声コミュニケーションモジュールの機能が、ゲームコンソール内部のＣＰＵ、またはＤＳＰなどの他のプロセッサ、及び適切なＤＡＣモジュール及びＡＤＣモジュールによって行われることが可能である。したがって、サウンド信号を処理してプレーヤ間で伝送されるサウンドデータを生成する構成要素、及び各プレーヤのヘッドホンを駆動するアナログ信号を生成する構成要素の位置は、本発明に重要ではない。
【００４２】
また、ＣＰＵ１５０は、マイクロホン１４４に向かって話すプレーヤのサウンドの特性を変更する音声効果も適用し、また様々な効果の選択を使用してサウンドの性質を変更することができる。例えば、女性のプレーヤは、自分の音声が、男性の太い声のように聞こえるようにする音声効果、または音声に茶目っけ（ｅｌｆｉｎ　ｑｕａｌｉｔｙ）があるようにする音声効果、または音声が、いくつかの他の所望の異なる音調（ｔｏｎａｌ）特性及びピッチ特性を有するようにする音声効果を選択することができる。プレーヤが選択することができる利用可能な音声効果は、ゲームに依存する。そのような音声効果は、実質的にプレーヤの音声のサウンドを変更して、プレーヤを実質的に認識不可能であるようにすることが可能であり、またゲームの中であるキャラクタが別のキャラクタに話しかけるように見えるとき、プレーヤによって制御されているそのキャラクタにドラマチックな性質またはよりすぐれた現実感を加えることが可能である。したがって、音声効果により、ロールプレーイング（ｒｏｌｅ　ｐｌａｙｉｎｇ）が容易になり、プレーヤの真の身元が隠される。同一のゲームコンソール１００に接続されているプレーヤが、ゲームコンソールが配置されている部屋の中で数フィート（１フィートは、３０．４８ｃｍ）しか離れていないため、互いの声が直接に聞こえるときでさえ、適用される音声効果に起因するプレーヤの音声の変更により、ヘッドホンを介して口頭のコミュニケーションを受け取る他のプレーヤによって聞き取られるサウンドが大きく変更されて、室内でプレーヤたちに伝播するプレーヤの音声の局所的サウンドを容易に無視することが可能になる。
【００４３】
実際に、本発明における限定ではないが、ゲームコンソール１００の好適実施形態は、ネットワークを介して、またはオンラインゲームサービスを通してインターネットを介して行われるゲーム中の口頭のコミュニケーションに、最高で１６名のプレーヤが参加するのが可能であることを予期して設計されている。明らかに、プレーヤが一度に参加するのを予期することが可能な他のプレーヤからの口頭のコミュニケーションの数には、実際的な限界が存在する。したがって、プレーヤは、同時に話す４名を超える他のプレーヤからの口頭のコミュニケーションを理解することができないものと想定した。
【００４４】
ゲームプレーのシナリオ
ゲームのタイプ、及び音声コミュニケーション信号を符号化する要件及び復号化する要件に影響を与える所与のゲームに参加しているプレーヤの数に依存して、異なる適切なシナリオが存在する。例えば、音声コミュニケーションに関する要件に影響を与える３つの主要なシナリオが存在する。第１のシナリオは、「ポイントツーポイント」と呼ばれ、２つの相互接続されたゲームコンソールのそれぞれにおいて１名のプレーヤを含み、各プレーヤは、他のプレーヤとの音声コミュニケーションに参加している。「マルチポイント」と呼ばれる第２のシナリオでは、やはり、各ゲームコンソール上で音声コミュニケーションに参加している１名だけのプレーヤが存在するが、最高で１６名のプレーヤが参加するゲームを行うため、最高で１６のゲームコンソールが、ネットワークを介して相互接続される。第３のシナリオは、「ゲームコンソール上のマルチプレーヤ」と呼ばれる。というのは、１つのゲームコンソール当り最高で４名のプレーヤが、また最高で４つのゲームコンソールがネットワークを介して相互接続されて、最高で１６名のプレーヤが同時にゲームを行い、口頭でコミュニケーションをとることが可能になるからである。この最後のシナリオに関して、単一のゲームコンソール上の２名またはそれより多くのプレーヤが、同じ室内に物理的にいるものの、前述したとおり、音声効果オプションの使用によってもたらされる音声の変化により、各プレーヤによるゲーム及びロールプレーイングの楽しみが増すことが可能であるため、ゲーム中に音声コミュニケーションを使用することも可能である。さらに、以上３つのシナリオのそれぞれにおいて述べたゲームコンソール／プレーヤの総数の限度は、ソフトな限度と考えることができる。というのは、さらなるプレーヤまたはゲームコンソールが参加することを除外する固有のハードウェアの限界は存在しないからである。
【００４５】
以上の３つのシナリオの１つまたは複数に従ってゲームを設計することにより、ソフトウェア設計者が、音声コミュニケーションに割り振られる計算リソースに対して最大の事前定義された限度を設定して、音声コミュニケーションが、ゲームプレーの品質に悪影響を与えるのを回避することが可能である。また、マルチプレーヤゲームコンソール上で行われる特定のゲームが、ある人数のプレーヤだけによって行われるのが適切であるように独自の要件を有することも可能である。この場合、ゲームの性質により、必要とされる口頭コミュニケーションチャネルの数の限度が決まる。例えば、チェスなどのゲームは、通常、ポイントツーポイントシナリオを使用して行われる。というのは、チェスには、通常、２名のプレーヤだけが関与するからである。音声コミュニケーション機能により、その２名のプレーヤが、チェスゲームを行いながら互いに話すことが可能になる。このポイントツーポイントシナリオの場合、各ゲームコンソールは、１つのエンコーダ及び１つのデコーダを実装するだけでよい。というのは、複数のエンコーダ及びデコーダは必要ないからである。各音声フレーム更新中、ゲームコンソール上のＣＰＵが、必要に応じて符号化及び復号化を更新する。このポイントツーポイントシナリオにおいて１．５パーセントの事前定義された符号化ＣＰＵ使用率限度及び０．５パーセントの復号化ＣＰＵ使用率限度を使用すると、必要とされるＣＰＵ使用率の合計は、およそ２．０パーセントだけである。
【００４６】
図４の機能ブロック図に示すとおり、ゲームコンソール１０２は、ゲームコンソール１７２と音声コミュニケーションするように結合されている。マイクロホン１４４が、コンソール１０２を使用するプレーヤの音声に反応し、このマイクロホンに接続されている音声コミュニケーションモジュールが、シングルストリームエンコーダ１６０に入力されるＰＣＭ（ｐｕｌｓｅ　ｃｏｄｅ　ｍｏｄｕｌａｔｅｄ）データを生成する。ＰＣＭデータに応答して、エンコーダは、圧縮されたデータパケットを生成し、次に、このデータパケットが、ゲームコンソール１７２が接続されているネットワーク１７０を介して伝送される。
【００４７】
あるいは、シングルストリーム符号化が、音声コミュニケーションモジュールのＤＳＰによって行われることが可能である。この実施形態では、マイクロホン１４４が、ゲームコンソール１０２を使用するプレーヤの音声に反応し、ＤＳＰ１５６が、ＡＤＣ１５８に接続され、圧縮されたデータパケットを生成し、次に、このデータパケットが、ネットワーク１７０を介してゲームコンソール１７２に伝送するためにゲームコンソール１０２に送られる。
【００４８】
ゲームコンソール１０２からの圧縮されたデータは、ゲームコンソール１７２においてネットワークキュー１７４に入力される。コンソール１０２からのサウンドパケット圧縮データを受信するのにネットワークキューを使用する目的は、データがネットワーク１７０を介して送信される際に生じるジッタ及び他のタイミング異常を除去することである。シングルストリームデコーダの出力は、ＰＣＭデータであり、次に、このデータが、ゲームコンソール１７２を使用するプレーヤの音声コミュニケーションモジュール内部のＤＡＣに印加されて、ヘッドホン１７８を駆動するアナログ出力が生成される。
【００４９】
代替の実施形態では、圧縮されたデータは、ゲームコンソール１０２から音声コミュニケーションモジュール内部のＤＳＰ１５６に伝送される。ＤＳＰは、圧縮されたデータを復号化して、対応するＰＣＭ信号に変換し、このＰＣＭ信号が、ゲームコンソール１７２を使用するプレーヤの音声コミュニケーションモジュール内部のＤＡＣ１６１に印加されて、ヘッドホン１７８を駆動するのに使用される対応するアナログ出力信号が生成される。
【００５０】
同様に、コンソール１７２を使用するプレーヤからの口頭のコミュニケーションに関して、マイクロホン１８０が、入射するサウンドを、マイクロホン１８０が接続されているコミュニケーションモジュール内部のＡＤＣを使用してＰＣＭデータに変換し、このＰＣＭデータが、シングルストリームエンコーダ１８２に入力され、エンコーダ１８２が、ゲームコンソール１０２内部のネットワークキュー１６２にネットワーク１７０を介して伝送される圧縮されたデータを生成する。ネットワークキュー１６２からの圧縮されたデータは、シングルストリームデコーダ１６８に入力され、デコーダ１６８は、ヘッドホン１４６が接続されている音声コミュニケーションモジュール内部のＤＡＣ変換器に入力されるＰＣＭデータを生成する。ＤＡＣは、対応するアナログサウンド信号を生成する。したがって、ヘッドホン１４６が、コンソール１７２に接続されたプレーヤのサウンドに対応するアナログサウンド信号を（加えられた音声効果があれば、その効果を伴って）受け取る。
【００５１】
各コンソールに１名のプレーヤが存在するが、複数のゲームコンソールがゲームセッションに参加しているマルチポイントシナリオでは、ゲーム設計者は、すべてのプレーヤが、ゲームを行っている他のプレーヤのすべてと口頭でコミュニケーションをとることができるべきか、またはプレーヤのサブセットから成るチームが存在する場合、同一のチームにいるプレーヤだけが互いに話すことが可能であるようにするかを決定することが可能である。例えば、マルチポイントシナリオで行われているゲームが、カードゲームである場合、１つのゲームコンソール当り１名づつの４名の個人プレーヤが存在することが可能であるか、または各２名のプレーヤの２つのチームが存在することが可能である。４名の別々のプレーヤが存在する場合、各ゲームコンソールは、１つのエンコーダ及び１つの４対１デコーダ（以下に述べる）を実装する。音声フレーム更新中、各コンソールが、ゲームコンソールを使用する単一のプレーヤによる発話を伝送するために必要な符号化を更新し、またゲームに参加する他のゲームコンソール上の（最高で）３名の他のプレーヤのなかの任意のプレーヤからの発話データの復号化を更新する。このシナリオの場合、１．５パーセントのＣＰＵ使用率に関する事前定義された符号化限度、及び１．３パーセントのＣＰＵ使用率に関する４対１デコーダ限度を使用すると、カードゲームを行うのに使用されている４つのゲームコンソールのいずれにおいても、合計は、およそ２．８パーセントのＣＰＵ使用率である。
【００５２】
図３は、どのようにマルチポイントシナリオが、各ゲームコンソール上で機能的に実施されるかを示しているが、他のゲームコンソールを示していない。ただし、ネットワーク１７０は、図示したゲームコンソールと通信する他のゲームコンソールに結合するものと理解する。前述したとおり、ゲームコンソールは、プレーヤの音声コミュニケーションモジュール（図３に示さず）内部のＡＤＣによって生成されたＰＣＭデータを受け取るシングルストリームエンコーダ１６０を含む。ＰＣＭデータは、シングルストリームエンコーダ１６０に入力され、ネットワーク１７０を介して他のゲームコンソールに伝送するためにパケットの形態の圧縮されたデータの音声フレームが生成される。同様に、圧縮されたデータのパケットは、ネットワーク１７０を介して他のゲームコンソールから図示したゲームコンソールに伝送される。ゲーム（またはチャネル）に参加する各プレーヤは、データパケットが一時的に記憶されるゲームコンソール上のネットワークキューを有し、ミクサ１６６ａによるミキシングのため、またデコーダ１６８ａによる復号化のために選択エンジン１６４ａによって圧縮されたデータのパケットが選択されたとき、ジッタ及び他のタイミング問題が最小限に抑えられることを保証する。デコーダ１６８ａは、ＤＡＣに供給されるＰＣＭデータを生成し、ＤＡＣは、ヘッドホン１４６を駆動するアナログ信号を生成する。
【００５３】
代替の実施形態では、選択エンジン１６４ａが、ミキシング及び圧縮解除のために音声コミュニケーションモジュール（図２に示す）のＤＳＰ１５６に２つの選択された圧縮されたデータストリームを伝送する。ＤＳＰ１５６は、音声コミュニケーションモジュール内部のＤＡＣに供給される対応するＰＣＭ信号を生成し、ＤＡＣは、ヘッドホン１４６を駆動する対応するアナログ信号を生成する。
【００５４】
図３に示すとおり、ネットワークキュー１６２ａ、１６２ｂ、及び１６２ｃがそれぞれ、他のプレーヤの、すなわち、最高でＮ名のプレーヤの各人に提供される。
【００５５】
前述したマルチポイントシナリオでは、カードゲームに参加している３名だけの残りのプレーヤが存在するので、３つだけのネットワークキューが存在する。ミクサ１６６ａは、一度に２つの入力だけを結合するので、デコーダ１６８ａは、ヘッドホン１４６を装着しているプレーヤに、一度に２名のプレーヤに関する同時のＰＣＭデータだけしか提供することができない。これに対して、デコーダ１６８ｂが、選択エンジン１６４ｂからの４つのデータパケットを一度に結合してヘッドホン１４６に提供される出力を生成するミクサ１６６ｂを含む代替の実施形態も示している。この代替の実施形態では、プレーヤには、最高で４つの他の音声データパケットが同時に提供される。
【００５６】
あるいは、選択エンジン１６４ａを使用して、宛先の受け手の音声コミュニケーションモジュール内部のＤＳＰ１５６に４つの選択された圧縮されたデータストリームを伝送することが可能である。ＤＳＰ１５６は、この場合も、音声コミュニケーションモジュール内部のＤＡＣに供給される対応するＰＣＭ信号を生成し、ヘッドホン１４６を駆動する対応するアナログ信号が生成される。
【００５７】
「ゲームコンソール上のマルチプレーヤ」シナリオに関する機能上の詳細を図５に示す。図５では、ゲームコンソール１０２が、ネットワーク層２０６を介してネットワーク１７０に接続され、これにより、プレーヤ２１６ａ及び２１６ｂを有するゲームコンソール２１０、単一のプレーヤ２１８を有するゲームコンソール２１２、及び４名のプレーヤ２２０ａ、２２０ｂ、２２０ｃ、及び２２０ｄを有するゲームコンソール２１４に接続されている。ゲームコンソール１０２には、プレーヤ２００ａ、２００ｂ、２００ｃ、及び２００ｄが接続されており、各プレーヤは、音声コミュニケーションモジュールを有するゲームコントローラを備えている。このシナリオの場合、コンソール２１０、２１２、及び２１４のそれぞれにおけるプレーヤの全員が、圧縮されたデータパケットのシングルストリームを生成するように符号化される音声コミュニケーションを有する。ゲームコンソール１０２内部のネットワーク層２０６が、残り３つのゲームコンソールのそれぞれからのデータパケットを、第２のゲームコンソール２１０に関するネットワークキュー１６２、第３のゲームコンソール２１２に関するネットワークキュー１８４、及び第４のゲームコンソール２１４に関するネットワークキュー１８６を含む３つの別々のネットワークキューに入れる。ゲームコンソール１０２内部のこの３つのネットワークキューからの出力が、デコーダ１６８に入力され、デコーダ１６８の出力が、音声コミュニケーション１９０ａないし１９０ｄを受け取る特定のヘッドホンを決定する出力ルータ１８８に印加される。
【００５８】
代替の実施形態は、出力ルータ１８８を使用してデコーダ１６８を迂回し、ネットワークキュー１６２、１８４、及び１８６から直接にデータパケットを引き出す。出力ルータ１８８は、宛先の受け手の音声コミュニケーションモジュール内部のＤＳＰに圧縮されたデータを伝送して、そのプレーヤのヘッドホンが、音声コミュニケーション１９０ａないし１９０ｄを受け取るようにする。
【００５９】
したがって、プレーヤ２００ａないし２００ｄの各人は、そのプレーヤを宛先とする音声コミュニケーションだけを受け取る。同様に、ゲームコンソール１０２上の４名のプレーヤの各人の対応するマイクロホン２０２ａ、２０２ｂ、２０２ｃ、及び２０２ｄからのサウンド入力が、入力ルータ２０４に供給され、ルータ２０４は、ＰＣＭデータストリームをエンコーダ１６０に選択的に印加して、エンコーダ１６０の出力が、ネットワーク層２０６に結合される。ネットワーク層は、サウンドデータを搬送する圧縮されたデータパケットが、ネットワーク１７０を介してゲームコンソール２１０、２１２、及び２１４のなかの適切なものにトランスポートされることを保証する。複数名のプレーヤを有する各ゲームコンソール内部の出力ルータは、ゲームコンソール１０２を使用するプレーヤからの音声コミュニケーションを受け取るプレーヤを決定する。
【００６０】
別の実施形態は、話しているプレーヤの音声コミュニケーションモジュール内部のＤＳＰを使用して圧縮されたデータを符号化することにより、入力ルータ２０４及びエンコーダ１６０を迂回する。
【００６１】
符号化のための、優先順位付け／ラウンドロビン技術
図６は、ゲームを行うためにゲームコンソールを使用している最高で４名のプレーヤによる音声コミュニケーションを扱うゲームコンソール上の優先順位付けに関する機能上の態様を示している。各音声間隔中、４つのエンコーダインスタンスのうち２つだけがアクティブであり、したがって、ゲームコンソール上で、音声コミュニケーション能力を有するプレーヤの数よりも少ない数のエンコーダが存在する。したがって、４つのマイクロホン２１１ａ、２１１ｂ、２１１ｃ、及び２１１ｄが存在するが、このマイクロホンにそれぞれ接続される音声コミュニケーションモジュール内部のＡＤＣからのデジタルＰＣＭデータが、すべて同時に符号化されるわけではない。ＰＣＭデータの各ストリームは、ブロック２１３ａ、２１３ｂ、２１３ｃ、及び２１３ｄに示すとおり、音声活動化検出アルゴリズムに印加される。このアルゴリズムは、いつプレーヤがマイクロホンに向かって話し、ゲームにおける１名または複数名の他のプレーヤに伝送するために符号化されなければならないＰＣＭデータを生成しているかを判別する。最悪ケースのシナリオで、４名すべてのプレーヤが、同時に話しており、音声活動化検出アルゴリズムが、ゲームコンソールに接続されている４つすべてのマイクロホンからのＰＣＭデータが符号化される必要のあることを示す可能性がある。しかし、この好適実施形態では、２つ音声ストリームだけを一度に符号化することが可能であるので、ブロック２１５における優先順位付けアルゴリズムが、２つの並列エンコーダ１６０ａに入力されるＰＣＭデータのストリームを決定するか、または選択する。これらのエンコーダは、ネットワークを介して伝送されるパケット化されたフレームの中で圧縮されたデータを生成する（ゲームコンソールが、リンクまたはネットワークを介して１つまたは複数の他のゲームコンソールに接続されていると想定して）。図６に示した例では、優先順位付けアルゴリズムは、ネットワークを介して出力するために現行のフレームの中に符号化することに関して、最高の優先順位を有するものとして、ＰＣＭデータ２１７ｃ及び２１７ｄを含む２つのストリームのＰＣＭデータを選択している。これに対して、ストリーム２１７ａ及び２１７ｂの中のＰＣＭデータには、音声入力を有していないが、圧縮されたデータの次のフレームの中で、音声データを含む場合、符号化することに関して最高の優先順位を有するものとしてマークが付けられる。
【００６２】
ラウンドロビン符号化方法を使用して、２つの並列エンコーダが４名のプレーヤからの音声コミュニケーションを符号化することができるようにし、任意の所与の音声データフレームの間に話していることが可能なプレーヤの総数よりも少ない数のエンコーダが、ゲームコンソール上で必要とされるようにする。図１２は、開始ブロック３８０から始めて、音声フレームのラウンドロビン符号化を可能にするように実施される論理ステップに関する詳細を提供している。ステップ３８２で、４つのＰＣＭパケット（各プレーヤに１つ）のアレイが組み立てられる。プレーヤが音声コミュニケーションをとらない場合、ＰＣＭ無音パケットがそのアレイに挿入される。判定ステップ３８４が、ロジックが現行の音声フレームに関して第１のループを実行しているかどうかを判定する。実行している場合、ステップ３８６が、ｉが値０、１、２、または３を有することが可能な変数ｐｒｉｏｒｉｔｙ（ｉ）を使用してアレイにおける優先順位を準備することを提供する。その後、ロジックは、ステップ３９０に進む。
【００６３】
ロジックは、現行の音声フレームに関して第１のループを行っていない場合、ステップ３８８に進み、現行の音声フレームに関する前のループにおいて生成された優先順位アレイを使用する。その後、ロジックは、やはりステップ３９０に進む。ステップ３９０で、音声活動化の検出が行われて、ＰＣＭパケットに、そのパケットが音声内容を有するかどうかを示すマークが付けられるようになる。アルゴリズムは、現行のサウンドレベルが、平均（背景）レベルより相当に高いかどうかを検出し、相当に高いことは、マイクロホンを有するプレーヤが、多分、現在、マイクロホンに向かって話していることを示している。あるいは、ＰＣＭパケットを分析して、背景雑音の特性とは相当に異なる音声特性を検出することが可能である。次に、ステップ３９２が、変数ｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘをゼロに等しいものとして設定し、また変数ｅｎｃｏｄｅｏｐｓをゼロに等しいものとして初期設定する。
【００６４】
判定ステップ３９４が、ｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘ変数が４より小さいかどうか、かつｅｎｃｏｄｅｏｐｓ変数が２より小さいかどうかを判定する。判定ステップ３９４には、以上２つの変数がゼロに初期設定されたステップ３９２の直後に最初に到達するので、両方の基準が満たされ、ステップ４０２に進む。ステップ４０２で、変数ＰＣＭ　ｓｔｒｅａｍ　ｉｎｄｅｘが、変数ｐｒｉｏｒｉｔｉｅｓに等しく設定され、値ｉは、ｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘ変数に等しい。音声フレームに関する最初のパス（ｐａｓｓ）で、ＰＣＭ　ｓｔｒｅａｍ　ｉｎｄｅｘ変数がｐｒｉｏｒｉｔｉｅｓ［０］に等しく設定される。
【００６５】
次に、判定ステップ４０４が、ＰＣＭ　ｓｔｒｅａｍ　ｉｎｄｅｘに等しいｉｎｄｅｘでＰＣＭパケットに関して音声が検出されたかどうかを判定する。この場合も、音声フレームの間のこのロジックの最初のパスとともに、判定ステップが、ＰＣＭ　ｐａｃｋｅｔ［ＰＣＭ　ｓｔｒｅａｍ　ｉｎｄｅｘ］に関して音声が検出されたかどうかを判定する。検出された場合、ステップ４０６が、優先順位アレイの終りにある変数ｐｒｉｏｒｉｔｉｅｓ［ｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘ］を動かし、この変数の後のすべての他の要素の順位を１つ先に移動する。次に、ステップ４０８が、変数ｅｎｃｏｄｅｏｐｓを前の値に１を足したものに等しく設定し、これにより、この変数を増分する。判定ステップ４０４で音声が検出されなかった場合、ステップ４１０が、ｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘをｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘに１を足したものに等しく設定し、これにより、この変数を増分する。ステップ４０８またはステップ４１０の後、ロジックは、判定ステップ３９４に進む。
【００６６】
ｐｒｉｏｒｉｔｉｅｓ　ｉｎｄｅｘ変数が４に等しくなる、またはｅｎｃｏｄｅｏｐｓ変数が２に等しくなると、ロジックは、ステップ３９６に進む。このステップで、ロジックは、ＰＣＭ　Ｐａｃｋｅｔ［ｐｒｉｏｒｉｔｉｅｓ［０］］及びＰＣＭ　Ｐａｃｋｅｔ［ｐｒｉｏｒｉｔｉｅｓ［１］］に関する音声検出プロパティを偽に設定する。次に、ステップ３９８が、ＰＣＭ　Ｐａｃｋｅｔ［ｐｒｉｏｒｉｔｉｅｓ［２］］及びＰＣＭ　Ｐａｃｋｅｔ［ｐｒｉｏｒｉｔｉｅｓ［３］］の並列符号化を提供する。最後に、ステップ４００で、ロジックが、現行の音声フレームに関してネットワークを介して伝送するために４つの圧縮されたデータパケットのアレイを組み立てる。このロジックに基づき、４名すべてのプレーヤが実際に話している場合、音声コンソール上のプレーヤのすべてが、ゲームにおける他のプレーヤとコミュニケーションをとることができるように、ＰＣＭパケットが、このラウンドロビンアルゴリズムを使用して圧縮されたパケットを形成するように符号化されることが明白であろう。
【００６７】
プレーヤ１、２、３、及び４が全員、同時に話していると想定される例を辿ることが役立つかもしれない。符号化された最新の２つの音声または２名のプレーヤの履歴が保持されている。ロジックは、プレーヤ１に関する現行のマイクロホンパケットを調べることから開始する。音声がアルゴリズムによって検出された場合、その音声が符号化される。次に、同じ判定が、プレーヤ２に関して行われる。すなわち、音声が、プレーヤ２のマイクロホンにおいて存在する場合、その音声が、現行の音声フレームの中で符号化される。初期の履歴は、プレーヤに［１，２，３，４］という順序が付けられて開始するが、この時点で、順序がプレーヤ［３，４，１，２］であるように更新される。ロジックは、事前定義されたマイクロホン符号化間隔の後、ループバックして、前回、処理されなかった２名のプレーヤに関するオーディオデータを処理する。現在、履歴リストは、［３，４，１，２］であり、したがって、プレーヤ３の音声が、現在、プレーヤ３のマイクロホンに入力されているかどうかを判定する検査が行われ、入力されている場合、その音声が符号化される。しかし、プレーヤ３が、この時点でもはや話していない場合、ロジックは、代わりに、話しているものと想定されるプレーヤ４に進む。したがって、プレーヤ４に関するデジタルＰＣＭ音声パケットが符号化され、履歴が更新されて［３，１，２，４］になる。次に、ロジックは、プレーヤ１に進み、そのプレーヤの音声を符号化し、新しい履歴［３，２，４，１］を生成する。次に、ロジックは、プレーヤ３及び２で開始する。プレーヤ３がまだ話しておらず、したがって、そのプレーヤのマイクロホンにおいて音声が存在しないものと想定すると、ロジックは、プレーヤ２及び４に関するデジタルＰＣＭパケットを符号化し、履歴リスト［３，１，２，４］をもたらす。
【００６８】
一実施形態では、スキップされ、符号化されないプレーヤの各ＰＣＭパケットに関して、そのプレーヤの前のパケットが音声フレームに関して減衰させられ、再生される。起こりうる最悪の状態で、全プレーヤが話しており、実際に、異なるチームにいる４名の異なるプレーヤがゲームコンソール上に存在するとき、各プレーヤの１つおきのＰＣＭパケットがスキップされる。この手法は、各プレーヤの音声の品質に対してわずかな悪影響を与えるが、これは、最悪ケースのシナリオであり、このシナリオは、通常、ゲームプレー中に稀にしか生じない。
【００６９】
スキップされ、したがって、前のパケットを繰り返すことによって埋められなければならないプレーヤのＰＣＭパケットは、ネットワークを介して伝送されないことに留意されたい。代わりに、繰り返されるＰＣＭパケットは、そのパケットの宛先の受け手によって使用される受信側ゲームコンソールによって扱われる。したがって、任意の１つの音声フレーム中、最大で４つではなく、せいぜい２つのパケットが、ゲームコンソールから送信される。キューが、前のパケットをバッファに入れ、スキップされたパケットに取って代わるようにその前のパケットを提供する。あるいは、スキップされたパケットは、受信側ゲームコンソールによってキューに入れられず、代わりに、そのパケットが、伝送を行ったゲームコンソールによってスキップされたことを示す通知が、そのチャネルに関して受信側ゲームコンソールのネットワークキューの中に挿入される。
【００７０】
ラウンドロビン符号化技術は、一度に２つの音声フレームに対してしか動作せず、現在、符号化されていないストリームのその他のフレームを繰り返す。前述したとおり、これにより、あるゲームコンソール上の４名すべてのプレーヤが話しているとき、サウンドの劣化がもたらされる可能性があるが、この技術により、追加のＣＰＵリソースを使用して４名すべてのプレーヤの音声を別々に符号化することが回避される。追加のＣＰＵリソースを使用して４名すべてのプレーヤの音声を別々に符号化することは、ゲームプレーに悪影響を与える可能性がある。
【００７１】
代替の実施形態では、１名のプレーヤ当り１つのエンコーダが、発話を符号化するために割り振られる。ただし、この実施形態は、それほど望ましくない。というのは、前述した実施形態の２倍の計算リソースが必要とされるからである。
【００７２】
リンク／ネットワークを介する音声コミュニケーション
図１０は、リンクまたはネットワークを介する音声コミュニケーションを可能にするために適用される一般的なステップを示している。最初、ステップ３３０でゲームが開始される。次に、判定ステップ３３２が、プレーヤが他のプレーヤと音声でコミュニケーションをとることが止められたかどうかを判定する。この状態は、そのプレーヤが、行動規範または他のサービスポリシーの違反により、オンラインゲームサービスによって音声コミュニケーションをとることの禁止または停止処分を受けたためもたらされる可能性がある。音声がブロックされることが可能な別の理由は、親などの権限の付与された個人によって、未成年の子供がゲーム中に他のプレーヤとの音声コミュニケーションに関与することが許されるべきでないと決定したことによる。このオプションは、特定のプレーヤアカウントに関してゲームコンソール上で提供されるオプションを使用して利用可能であり、また設定することが可能である。設定されると、そのデータは、オンラインゲームサービス上に記憶され、そのプレーヤがサービスに接続するたびに音声コミュニケーションをブロックすることが実施される。現行のプレーヤの音声コミュニケーションがブロックされた場合、ステップ３３４が、ゲームコンソールが音声コミュニケーションを処理しなくてもよいことを判定し、ステップ３３６で、代わりに次の話し手に進む。次の話し手が、ゲームコンソール上の設定によって音声コミュニケーションをとることから除外されていないと想定すると、ロジックは、そのプレーヤのために音声コミュニケーションモジュール内部のＡＤＣからＰＣＭデータを取得するステップ３３８に進む。次に、ロジックは、ステップ３４０でそのＰＣＭ音声データを圧縮して圧縮されたデータにする。ステップ３４２が、現行のプレーヤのＰＣＭ音声データを圧縮する際、何らかの割り当てられた音声効果を適用して、そのプレーヤの音声の特性を変化させる。ステップ３４４で、圧縮されたデータが、ネットワーク３４６を介して宛先の受信側ゲームコンソールに伝送されて、音声コミュニケーションモジュールを有する宛先の受け手に届く。ステップ３４８が、圧縮されたデータを伝送しているゲームコンソール上の次の話し手を処理することを準備し、これにより、判定ステップ３３２に戻る。
【００７３】
ネットワーク３４６を介して音声コミュニケーションを受信したゲームコンソール上で、ステップ３５２が、圧縮されたデータをそのようなデータのネットワークキューに追加することを提供する。次に、ステップ３５４で、ゲームコンソールが、キューから引き出された圧縮されたデータを圧縮解除し、対応するＰＣＭデータを生成する。ステップ３５６が、オプションの環境効果があれば、それを追加することを提供する。そのような効果は、一般に、ゲームコンソール上で行われているゲームにおいて提供されるオプションによって決定される。例えば、環境効果には、反響を追加すること、またはゲームの環境が洞穴内部である場合、残響を導入することが含まれることが可能であり、あるいは環境効果は、例えば、小さいスピーカ上のオーディオデータの再生に関して低音ブースト（ｂａｓｓ　ｂｏｏｓｔ）を追加することによって周波数帯域の均等化を提供することに関わることが可能である。次に、ステップ３５８が、複数の異なるプレーヤから受信された音声ストリームをミキシングして、宛先の受け手のプレーヤに提供される１つの出力音声ストリームにする。この出力音声ストリームが、ステップ３６０で、ＰＣＭデータとして宛先の受け手のプレーヤのヘッドホンに関連するＤＡＣに伝送され、ＤＡＣが、ヘッドホンを駆動する対応するアナログ信号を生成する。したがって、プレーヤは、復号化され、ミキシングされて出力音声ストリームになったプレーヤの各人からの音声コミュニケーションを聞く。
【００７４】
プレーヤ間のミュートにされた音声コミュニケーション
特定のプレーヤが別のプレーヤによって音声コミュニケーションからミュートにされたときはいつでも、別の状況が生じる。このようにあるプレーヤがミュートにされると、その特定のミュートにされたプレーヤは、ミュート処理側のプレーヤの声を聞く、またはそのプレーヤに話すことができない。ミュート処理側のプレーヤは、音声コミュニケーションを元に戻すのに明示的にミュートにされたプレーヤをミュート解除しなければならない。
【００７５】
ネットワークデータパケットの扱い
図１１は、ネットワーク３４６を介して音声コミュニケーションデータをパケットとして受信することに関するさらなる詳細を示している。ブロック３５０ａ及び３５０ｂに示されるとおり、圧縮されたデータが、Ｎ個の他のゲームコンソールからネットワークを介して受信される。圧縮されたデータの各チャネルは、最初、Ｎ個のキュー３５１ａ〜３５１ｂの１つに入力され、接続されたゲームコンソール上の各プレーヤ（各ゲームコンソール上に１名または複数名のプレーヤ）に関して個別のキューが提供される。次に、ブロック３６４が、圧縮されたデータを受け取るように形成されているＮ個のキューを同期する。このステップで、現行の音声フレームに関してキューのすべてから、符号化された圧縮されたパケットが獲得される。次に、選択エンジン３６６が、ブロック３６８において復号化エンジンに入力するために組み立てられるべき圧縮されたパケットを決定する。復号化エンジンは、圧縮されたデータを圧縮解除して復号化し、そのデータをＰＣＭデータに変換して、次に、このＰＣＭデータが、接続された音声周辺コミュニケーションモジュール３７０ないし３７２のそれぞれに適用されて、その音声コミュニケーションモジュールをそれぞれ使用するプレーヤが、ネットワークを介して自身に伝送されたサウンドを聞くことができるようになる。
【００７６】
各キューから受け取られた符号化されたパケットの処理に関連する詳細を図７に示している。ブロック２２１で、ＣＰＵが、各キューをチェックして符号化された圧縮されたパケットを獲得するか、またはキューが、あるプレーヤからのパケットを有していないが、そのプレーヤに関するパケットがそのキューの中に存在すべきであったことをクライアントのＣＰＵに通知する。この場合、ＣＰＵは、そのキューからそのプレーヤに関して獲得された前のパケットが、実際に有効な符号化されたパケットであったかどうかを判定し、有効な符号化されたパケットであった場合、ＣＰＵは、そのプレーヤに関する前のパケットをコピーして、次のブロックにおけるさらなる処理のために提供することができるようにする。しかし、そのプレーヤに関する前のパケットも欠落していた場合、ＣＰＵは、そのプレーヤに関する前のパケットに減衰を行う。このステップの目的は、ラウンドロビン符号化中にパケットをスキップすること、及びネットワーク条件のためにドロップされたパケットからもたらされる欠落したパケットによって生じる無音の知覚を最小限に抑えることである。
【００７７】
次に、ブロック２２２で、ブロック２２１で獲得されたパケットが配列され、その配列の中のすべての無音パケットが除去される。その結果が、キューの中で元に提供されたパケットのサブセットである。前述した処理により、サブセットの中のすべてのパケットが有効な音声データを含む。
【００７８】
次に、ブロック２２４が、チャネルマスクを音声データに適用することを提供する。各プレーヤにチャネルが関連し、特定のチャネル上のすべてのプレーヤが、互いに音声でコミュニケーションをとることができる。例えば、１つのチャネルが、チームリーダとして指名されたプレーヤとチームメンバの間の音声コミュニケーションのために使用され、そのプレーヤが、チームのすべてのメンバとコミュニケーションをとることができるようにすることが可能である。さらに、チームリーダは、複数のチームリーダとコミュニケーションをとることができる指令者として指名された別のプレーヤと口頭でコミュニケーションをとるために別のチャネルを選択する、あるいはチームリーダが、他のチームリーダとだけコミュニケーションをとることができるようにするさらに別のチャネルを選択することも可能である。この実施形態では、話している各プレーヤに、そのプレーヤに関する「話者（ｔａｌｋｅｒ）チャネル」を定義する１６ビットワードが与えられる。ゲームは、話者チャネルに関するワードの個々のビットが何を意味するかを判定し、例えば、話者チャネルが、チーム用、チームリーダ用、指令者用等であることを示す。さらに、各プレーヤに、発話を受け取ることができる「聴取者（ｌｉｓｔｅｎｅｒ）チャネル」を割り当てることが可能である。音声コミュニケーションが、ネットワークを介して入ってきたとき、話者チャネルは、所与のプレーヤに関する聴取者チャネルと論理「ＡＮＤ」にされており、結果がゼロでない場合は、そのプレーヤが、音声コミュニケーションを聞くことができる。このようにして、行われているゲームが（またはゲームの制約の範囲内で各プレーヤが）、他のプレーヤと音声コミュニケーションするように結合されるプレーヤを判定する任意の順列（ｐｅｒｍｕｔａｔｉｏｎ）を選択することができる。
【００７９】
図７を再び参照すると、ブロック２２４により、各プレーヤが、一部のチャネルだけを聴取し、チャネルマスクを使用することを選択できるようになる。ゲームコンソール上の各プレーヤに関してチャネルマスクが適用され、最大で４つのサブセットの音声ストリーム、すなわち、聴取する各プレーヤに関して１つのサブセットが、プレーヤの個々の聴取者マスクに基づいてもたらされる。聴取している各個人は、異なる音声ストリームに含まれる候補パケットのリストを有する。
【００８０】
ブロック２２６で、ミュート処理マスク及びユーザによって定義された優先順位が提供される。好適実施形態により、プレーヤが、選択されたプレーヤとのさらなる音声コミュニケーションを選択的に除外することができるようになるが、プレーヤが、現行のゲームセッション中に特定のプレーヤとの音声コミュニケーションをミュートにすることだけを選択的に行うのが可能であることも企図される。この代替の実施形態では、ゲームコンソール上の各プレーヤが、聴取チャネル上である人々をミュートにするのを選択することが可能である。次に、そのプレーヤによってミュートにされたプレーヤからの音声ストリームが、ゲームコンソール上のそのプレーヤ向けの候補音声ストリームのリストから除去される。各プレーヤ向けのあらゆる残りの音声ストリームが、ユーザによって定義された優先順位でソートされる。このステップで、１つの音声ストリームが、常時、最高の優先順位を有することが可能である。例えば、ゲームが（またはゲームがそのオプションを許す場合、プレーヤが）、チームメンバがチームリーダと音声コミュニケーションをとるように結合するチャネルを選択的に設定して、そのチャネルが、チームメンバの各人に対して最高の優先順位を有するようにすることが可能である。また、着信する音声ストリームの音量も、所与のプレーヤ向けのチャネルの優先順位を判定する基準となり、そのプレーヤが、常時、最大音量の音声ストリームを聞くようにすることも可能である。あるいは、またはさらには、ある音声ストリームのレンダリングが開始された場合、ゲームは、後に開始した他の音声ストリームの音量に関わらず、その音声ストリームが終了するのを待ち、その音声ストリームが終了する前に文が「ストリーム途中（ｍｉｄ−ｓｔｒｅａｍ）」で中断されないようにする。さらなる別法として、または追加として、各音声チャネルに関して他の優先順位を定義することも可能である。例えば、ゲーム固有の役割に関連する優先順位を適用することが可能である。
【００８１】
ブロック２２６の後、ブロック２２８に示す復号化エンジンタイプ１、またはブロック２３０に示す復号化エンジンタイプ２を使用して、ミュート処理マスクとユーザ／ゲームによって定義された優先順位とを適用することからもたらされた音声ストリームに復号化を適用する。ブロック２２８で、復号化エンジンタイプ１が、デコーダを割り振り、各プレーヤのメソッドに関してミキシング及び復号化を行う。このアルゴリズムでは、各プレーヤに関して、配列されたパケットのリストの中の最初のＮ個のパケットが選択される。リストがＮ個より少ない要素を含む場合、存在しないパケットの代わりに無音の圧縮されたデータパケットを使用して、音声パケットのＣＰＵ処理においてスパイク（ｓｐｉｋｅ）が生じるのを回避する。
【００８２】
ブロック２３０で、エンジンタイプ２を使用して復号化を適用する際、ＤＳＰのメソッドで復号化及びミキシングを行うためにデコーダが割り振られる。このアルゴリズムに従って、最大数の復号化されたパケットに達するまで、または候補パケットの終りに達するまで、または候補パケットリストの終りに達するまで、パケットの配列されたリストから、リストが空でない場合、現行のプレーヤが獲得される。配列されたパケットのリストの先頭が、前に選択されていない場合は、リストの先頭が復号化されるように選択され、復号化されたパケットに関してカウンタが増分される。その後、リストの先頭は、配列されたリストから除去される。次に、アルゴリズムは、次のプレーヤに進み、そのプレーヤが現行のプレーヤとなる。例えば、プレーヤ４の後、プレーヤ１は次いで再び現行のプレーヤになる。さらなる音声パケットを復号化するために復号化スロットが残っている場合、無音パケットを並列デコーダに適用して音声パケットのＣＰＵ処理におけるスパイクを回避する。
【００８３】
復号化エンジン、タイプ１及び２
図８に、復号化エンジンタイプ１の機能上の態様に関する詳細を示している。図８に示すとおり、符号２４０、２４２、及び２４４で示される符号化されたストリーム１ないしＮが、各プレーヤのヘッドホンに関して復号化するための２つの符号化されたストリームを選択する選択エンジン２５７に圧縮されたデータを提供する。このケースでは、符号化されたストリーム１．１及び符号化されたストリーム１．２が、デコーダ１６８ａに入力するために選択され、デコーダ１６８ａにおいて、ストリームは、復号化に先立ってミクサ２５２によってミキシングされる。デコーダの出力は、ヘッドセット２４８に関して音声コミュニケーションモジュール内部のＤＡＣに供給されるＰＣＭデータである。同様に、他のプレーヤのヘッドホンのそれぞれに関して、別のデコーダ１６８ｂが、圧縮されたデータとして符号化された音声ストリームを受け取り、このストリームが、ミキシングされて復号化される。図示するとおり、第４のプレーヤに関するデコーダは、符号化された音声ストリーム４．１及び４．２をミキシングするミクサ２５４を含み、デコーダが、音声コンソール上の第４のプレーヤ用のヘッドホン２５０を駆動するアナログ信号を提供するＤＡＣに供給されるＰＣＭデータを生成するようになっている。もちろん、４名より少ないプレーヤがゲームコンソールを使用している場合が存在し、その場合、アクティブである必要があるデコーダは、４つより少ない。
【００８４】
復号化エンジンタイプ１と復号化エンジンタイプ２の両方に対する代替の実施形態は、（ブロック２２６における）優先順位の付けられた音声ストリームを、宛先の受け手の音声コミュニケーションモジュール内部のＤＳＰに直接に伝送する。
【００８５】
タイプ２復号化エンジンの機能上の態様を図９Ａに示している。この場合も、符号２４０、２４２、及び２４４で表される符号化されたストリーム１ないしＮが、選択エンジン２６０に入力され、エンジン２６０は、聴取を行っており自分に向けられた音声ストリームを有する各プレーヤに関して、最大で４つ、最小で１つのデコーダストリームを選択する。このケースでは、４つの並列デコーダ２６２が、４つの選択された符号化された音声ストリームの圧縮されたデータを受け取る。次に、デコーダは、その圧縮されたデータを復号化し、結果のＰＣＭデータを、音声ストリームが向けられた各プレーヤに関するミクサに供給する。このケースでは、第１のプレーヤが、符号２６４で識別されるミクサ内部のミクサ２７０によってミキシングされる他のプレーヤからの２つの音声ストリームを受け取る。図示していないが、ゲームにおいて他のプレーヤから音声コミュニケーションを受け取る他のプレーヤのそれぞれも、４つの並列デコーダの出力がミキシングのために印加される別個のミキシングビン（ｂｉｎ）を備えている。例えば、第４のプレーヤが、符号２６６で識別されるミクサ内部のミクサ２７２によってミキシングされる３つの音声ストリームを受け取る。次に、結果のＰＣＭデータが、第４のプレーヤ用のヘッドセット２５０に印加される。したがって、各プレーヤは、そのプレーヤに割り当てられた４つ１組（ｆｏｕｒ−ｉｎ−ｏｎｅ）ミキシングビンによってミキシングされた１つないし４つの音声ストリームを受け取ることができる。
【００８６】
（ブロック２６０における）別の実施形態は、デコーダ２６２、ならびにミクサ２６４及び２６６を迂回し、圧縮されたデータをヘッドホン２４８及び２５０にそれぞれ結合された音声コミュニケーションモジュールのＤＳＰに伝送する。
【００８７】
タイプ２の復号化エンジンで使用するための代替の手法を図９Ｂに示している。この実施形態では、デコーダとミクサの相対的配置が、図９Ａで示したものとは逆になっている。具体的には、各プレーヤが、ネットワークを介して着信する圧縮されたデータを受け取り、ミキシングするように結合された２ストリームミクサを備えている。２ストリームミクサ２８０がプレーヤ１に提供され、２ストリームミクサ２８２がプレーヤ２に提供され、２ストリームミクサ２８４がプレーヤ３に提供され、また２ストリームミクサ２８６がプレーヤ４に提供されている。したがって、最大で２つの音声ストリームの圧縮されたデータが、プレーヤごとの以上のミクサのそれぞれに入力され、ミキシングされて、４ストリーム並列デコーダ２８８に入力するために各ミクサから単一のミキシングされたストリームが提供される。次に、このデコーダは、圧縮されたデータを復号化して、別のプレーヤからの音声コミュニケーションの宛先の受け手である各プレーヤのヘッドホン２４８、２５２、２５３、及び２５０に供給されるＰＣＭデータを生成する。
【００８８】
さらに別の実施形態は、２ストリームミクサ２８０、２８２、２８４、及び２８６に伝送された圧縮されたデータが、ヘッドホン２４８、２５２、２５３、及び２５０にそれぞれ結合された音声コミュニケーションモジュールのＤＳＰによって復号化されるようにする。
【００８９】
他のプレーヤとの音声コミュニケーションの制御
前述したとおり、プレーヤは、挙動の問題を理由に、またはその他の理由で特定のプレーヤとのさらなる音声コミュニケーションを除外するオプションを有する。例えば、ある特定の別のプレーヤが、過度の冒涜的な言葉を使用する傾向にある場合、プレーヤは、その別のプレーヤとさらなるコミュニケーションをとらないことを選択することが可能である。各ゲームは、一般に、プレーヤが、現行のゲームセッション及び将来のゲームセッションに関して別のプレーヤとの音声コミュニケーションをミュートにするオプションを提供し、また、プレーヤが、現行のゲームセッションに限って別のプレーヤとの音声コミュニケーションをミュートにできるようにすることが可能であることも企図されている。図１３、１３Ａ、及び１３Ｂは、音声コミュニケーションのこの制御を、「マイゲーム（ＭＹ　ＧＡＭＥ）」と呼ばれるゲームにおいて実施できるようにする例としてのダイアログボックス４３０を示している。この架空のゲームは、プレーヤリストボックス４３２に示すとおり、プレーヤの各人をリストする。プレーヤリストボックス４３２は、選択バー４３４で示されるとおり、先頭にリストされるプレーヤが選択されている６名のプレーヤを含んでいる。「アベンジャ（Ａｖｅｎｇｅｒ）」というエイリアスを使用してゲームを行うこのプレーヤは、そのエイリアスと同じ行で、ダイアログの１つの列に示される話者記号４３６で示されるとおり、音声コミュニケーション能力を有する。「アイスマン（Ｉｃｅｍａｎ）」及び「レースオックス（Ｒａｃｅｏｘ）」というエイリアスをそれぞれ使用するプレーヤは、以上のエイリアスのどちらの同じ行にも、その列で話者記号４３６を欠いていることから明らかなとおり、音声コミュニケーション能力を有さない。プレーヤリストボックス４３２を見ている現行のプレーヤとの音声コミュニケーションから、リストされているプレーヤの任意のプレーヤをミュートにすることができるようにするラジオボタン４３８が提供されている。このケースでは、ラジオボタン４３８で示されるとおり、アベンジャが、プレーヤによって選択されている。プレーヤが選択されたとき、選択されたプレーヤを特定し、このプレーヤが、現在、ゲームの参加者の１人であり、音声コミュニケーションモジュールを有することを示すウインドウ４４０が開く。プレーヤリストボックス４３２を見ているプレーヤが、選択ボタン４４２をクリックした場合、異なる状態に切り替えることができるオプションバー４５２を含む音声コミュニケーションステータスセレクト４５０が開く。図１３Ａに示すとおり、オプションバー４５２は、選択されたプレーヤが、このオプションを選択しているプレーヤとの口頭のコミュニケーションをとることができるようになっていることを示す。図１３Ｂでは、オプションバーが、状態４５４に切り替えられており、このことは、その状態を見ているプレーヤが、選択されたプレーヤを現行のゲームセッションに関してミュートにするのを望むことを示す。プレーヤが行う選択に応じて、話者記号４３６が変化する。図１３に示したものの代わりに、プレーヤが、選択された特定のプレーヤをミュートにするオプションを選択した場合、図示した話者記号の周りにダッシュボックス（ｄａｓｈ　ｂｏｘ）が現れる。このタイプのミュート処理は、現行のゲームセッション後、終了する。他方、特定のプレーヤが選択的にロックアウトされた場合、ダッシュヘビーバーボックス（ｄａｓｈ　ｈｅａｖｙ−ｂａｒ　ｂｏｘ）がスピーカ記号４３６の周りに追加される。その場合、あるプレーヤをミュートにする決定は、ゲームセッション内からその決定を行ったプレーヤによって、またはゲームコンソールのシステムコントロールを使用することによってだけオフにすることができる。さらに別の記号（図示せず）が、ヘッドホンを介してではなく、受け手のプレーヤのゲームコンソールに接続されたラウドスピーカ（例えば、テレビジョンスピーカまたはモニタスピーカ）を介して対応するプレーヤに関する音声コミュニケーションが再生されることを示すのに使用される。このオプションは、ヘッドセットを着用しないことを好むプレーヤによって選択されることが可能であるが、それほど望ましくない。というのは、プレーヤが、他のプレーヤと口頭でコミュニケーションをとるのにマイクロホンを使用していないからである。
【００９０】
数名のプレーヤが、ある特定のプレーヤに関する否定的なフィードバックを、冒涜的な言葉の過度の使用、または性的に露骨な言葉の使用などの容認できないと見なされるそのプレーヤの口頭の挙動に基づいて提供した場合、オンラインゲームサービスが、受け取られた苦情の数がしきい値を超えたことを自動的に判定し、その特定のプレーヤが、さらなる音声コミュニケーションを禁止されるようにする。この禁止は、最初、１週間などの限られた期間にわたり、後に、しきい値を超えてさらなる苦情が受け取られた場合、その特定のプレーヤを永久に音声コミュニケーションから締め出すことが可能である。このように禁止処分を受けた特定のプレーヤには、最初、音声コミュニケーション能力の一時的な停止処分が通知され、次に、そのプレーヤの挙動が永久的な停止処分をもたらした場合、その結果が通知される。プレーヤが、ゲームコンソール上でオンラインゲームサービスにログインするたびに、サインインプロセスの一環として許可フラグがゲームコンソールにダウンロードされる。このフラグは、システムの様々な態様に関する情報を含む。フラグの１つが、特定のプレーヤが音声チャネルに参加する許可を有するかどうかを判定する。したがって、ある特定のプレーヤが、サービスの規定または行動規範に違反した場合、プレーヤが音声でコミュニケーションをとる能力を制御するビットが、そのような音声コミュニケーションを除外するように変更されることが可能である。
【００９１】
プレーヤが、ある特定のプレーヤを音声コミュニケーションから除外することを選択すると、その特定のプレーヤの身元が、好ましくは、オンラインゲームサービスに伝送され、その選択を行ったプレーヤの身元に関連して記憶され、あらゆるゲームの将来のセッションにおいて、そのような決定を行ったプレーヤが、その特定の他のプレーヤからの音声コミュニケーションを全く受け取らず、またその特定の他のプレーヤに対して音声コミュニケーションを全く伝送しないようにする。この決定は、その特定の他のプレーヤに明らかではない。というのは、ゲームにおけるプレーヤのステータスを示すダイアログボックスは、単に、その決定を行ったプレーヤが音声コミュニケーション能力を欠いていることの指示をその特定の他のプレーヤのビュー上で表示し、その決定を行ったプレーヤに表示されるダイアログにおいて、その特定の他のプレーヤのミュートにされたステータスが示されるからである。したがって、その特定のプレーヤが、使用するエイリアスを変更した、または異なるゲームコンソールを使用してサインオンしたとしても、プレーヤによって行われたその特定のプレーヤに関する音声コミュニケーションの禁止は、有効であり続ける。
【００９２】
また、ＰＣＭデータが、発話の各セグメントに関連するリップ位置情報も含むことも企図されている。リップ同期情報は、生成されて、ＰＣＭデータとともにエンコーダに伝送され、圧縮されたデータに変換され、受け手のプレーヤに伝送されて、あるプレーヤが話しているとき、ゲームにおいてそのプレーヤによって代表され、制御されるキャラクタが、そのプレーヤによって話されている語と同期して話しているように見えるようになる。話しているプレーヤを表すグラフィックキャラクタの性質に応じて、「口」の性質は、人間の体の通常の口唇部分のものとは異なる可能性がある。例えば、ゲームにおけるキャラクタは、そのキャラクタが話すときに動く大顎（ｍａｎｄｉｂｌｅｓ）を有するエイリアンである可能性がある。それでも、キャラクタの口唇部分を話される語と同期することにより、ゲームプレーの現実感が高まる。グラフィックキャラクタ及び話される語を使用してリップ同期を実現することの詳細が、本出願と同じ譲受人に譲渡された米国特許第６０６７０９５号明細書で開示されており、この特許の開示及び図面は、参照により明確に本明細書に組み込まれている。あるいは、リップ同期情報は、復号化中、圧縮されたデータから抽出することが可能である。
【００９３】
以下、米国特許第６０６７０９５号明細書で開示されている内容を説明する。
【００９４】
本実施形態は、話をするアニメーションのキャラクタの口唇の位置及び口の開きを決定するためのシステムを対象とする。より詳細には、本実施形態は、アニメーションのキャラクタまたは機械的キャラクタの口唇の位置及び口唇間の開きを、キャラクタが話している語と同期させるための方法及びシステムに関する。一実施形態では、本実施形態は、ワシントン州レッドモンドのマイクロソフトコーポレーションによって市販されるリアルメーション（Ｒｅａｌｍａｔｉｏｎ）システム（商標）に組み込まれる。
【００９５】
次に、いくつかの図のすべてで同様の符号が同様の要素を表す図面を参照し、本実施形態の態様、及び例としての動作環境を説明する。
【００９６】
例としての動作環境
本実施形態の態様を、無線周波数（ＲＦ）通信チャネルを介して１つまたは複数のスレーブデバイスと通信し、かつ制御するマスタデバイスを含むシステムの状況で説明する。より具体的には、本実施形態の態様は、「リアルメーション」システム内部で特に適用可能である。「リアルな（ｒｅａｌｉｓｔｉｃ）」という語と「アニメーション」という語を組み合わせることから由来する「リアルメーション」は、ワシントン州レッドモンドのマイクロソフトコーポレーションによって開発された技術を表すものである。リアルメーションシステムの例には、機械的キャラクタなどの１つまたは複数のスレーブデバイスと通信し、かつ制御する、ディスプレイを備えたコンピュータシステムなどのマスタデバイスが含まれる。マスタデバイスは、ディスプレイ上でアニメーションのオーディオ／ビデオプレゼンテーションのシーンを提供し、他方、それと同時に、１つまたは複数の機械的キャラクタに制御情報及び音声データを伝送する。機械的キャラクタは、制御情報及び音声データを受け取ることに応答して、アニメーションのオーディオ／ビデオプレゼンテーションの状況に沿って動き、話をする。
【００９７】
マイクロソフトコーポレーションの技術者が、次の２つの主な構成要素を含むリアルメーション製品を開発している。すなわち、マスタデバイスとして動作するリアルメーション制御システム、及びスレーブデバイスとして動作する１つまたは複数のリアルメーションパフォーマである。リアルメーションパフォーマには、産業目的、教育目的、研究目的、エンターテイメント目的、またはその他の同様な目的で有用な様々なデバイスが含まれる可能性がある。各リアルメーションパフォーマは、リアルメーション制御システムを送信元とする信号を受信し、復調し、復号化するためのＲＦトランシーバシステムを含む。リアルメーション制御システムを送信元とする信号は、制御情報及び音声データを含む。また、各リアルメーションパフォーマ内部のＲＦトランシーバは、信号を符号化し、変調し、リアルメーション制御システムに伝送することもできる。この伝送信号は、リアルメーションパフォーマに関するステータス情報をリアルメーション制御システムに搬送する。
【００９８】
リアルメーション制御システムは、アニメーションのオーディオ／ビデオプレゼンテーションを表示しながら、１つまたは複数のリアルメーションパフォーマの動作を統制する。リアルメーション制御システムは、リアルメーションデータソース、リアルメーションリンクマスタ、及び表示システムを含む。リアルメーションデータソースは、リアルメーションリンクマスタを制御し、リアルメーションデータの入力を提供するコンピュータシステムなどの能動的なデバイスであることが可能である。あるいは、リアルメーションデータソースは、リアルメーションリンクマスタにリアルメーションデータを送り込むコンピュータ、ＶＣＲ、またはＴＶチューナなどの受動的なデバイスであることが可能である。別の代替案には、リアルメーションデータソースをリアルメーションリンクマスタと結合して、「スマート」リアルメーションリンクマスタを形成することが含まれる。構成に関わらず、リアルメーションデータソースは、リアルメーションデータの入力を提供し、リアルメーションリンクマスタが、そのリアルメーションデータを１つまたは複数のリアルメーションパフォーマに伝送する。
【００９９】
リアルメーションリンクマスタの主な機能は、リアルメーションデータソースからリアルメーションデータを受け取り、そのリアルメーションデータを符号化し、符号化されたリアルメーションデータを１つまたは複数のリアルメーションパフォーマに伝送することである。さらに、リアルメーションリンクマスタは、リアルメーションパフォーマから応答信号を受け取り、その応答信号を復号化してリアルメーションデータを回復することができる。
【０１００】
リアルメーション製品の２つの例としての実施形態には、シンプレックス実施形態及びデュープレックス実施形態が含まれる。リアルメーション制御システム、リアルメーションリンクマスタ、及びリアルメーションパフォーマの例としての実施形態を、マイクロプロセッサベースのシステム上で実行されるプログラムの状況で一般的に説明する。本実施形態の実施態様は、様々なタイプのプログラムを含み、様々なプログラミング言語を使用し、また様々なタイプの計算機器で動作することが可能であることが、当業者には認められよう。さらに、例としての実施形態の説明では、リアルメーション制御システムは、ＲＦ通信チャネルを介してリアルメーションパフォーマを制御するものとして説明するが、ＲＦ通信チャネルに代用されるものには、光ファイバリンク、銅線、赤外線信号などの他の通信媒体が含まれる可能性があることが、当業者には理解されよう。
【０１０１】
一般に、本明細書で定義するプログラムには、特定のタスクを行う、または特定の抽象データ型を実装するルーチン、サブルーチン、プログラムモジュール、構成要素、データ構造等が含まれる。さらに、本実施形態の態様は、他のコンピュータシステム構成にも適用可能であることが、当業者には理解されよう。他のコンピュータシステム構成には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品、ミニコンピュータ、メインフレームコンピュータ等が含まれるが、以上には限定されない。また、本実施形態の態様は、通信網を介してリンクされたリモート処理デバイスによってタスクが行われることを含む分散コンピューティング環境の状況においても適用可能である。分散コンピューティング環境では、プログラムモジュールは、ローカルのメモリ記憶デバイスとリモートのメモリ記憶デバイスの両方の中に配置されていることが可能である。
【０１０２】
シンプレックス実施形態とデュープレックス実施形態の両方において、リアルメーションパフォーマは、子供たちに対話式の学習及びエンターテイメントの環境を提供することを目的とする費用の低いアニメーションの機械的キャラクタである。最低限、各リアルメーションパフォーマは、受信機システム、音声合成器、スピーカ、処理ユニット、及び１つまたは複数のサーボモータを含む。受信機システムがリアルメーションデータを受信したことに応答して、処理ユニットが、そのリアルメーションデータの内容によって決まる仕方で復号化、解釈、及び応答を行う。処理ユニットの応答には、１つまたは複数のサーボモータを作動させること、及び／または音声合成器に入力を提供することが含まれることが可能である。
【０１０３】
デュープレックス実施形態では、各リアルメーションパフォーマは、１つまたは複数のセンサデバイス、及び送信機システムをさらに含む。センサデバイスは、子供が手を握り締めたこと、目を覆ったこと、またはリアルメーションパフォーマの位置を変えたことなどのアクションを検出することができる。センサからの出力信号を監視することにより、処理ユニットは、ステータス情報を収集することができる。リアルメーション制御システムから要求を受け取ったとき、または自律的な判断を行うことにより、処理ユニットは、センサステータス情報をリアルメーション制御システムに伝送することができる。センサステータス情報を受信したことに応答して、リアルメーション制御システムは、その情報に相応する仕方でアニメーションのオーディオ／ビデオプレゼンテーションを変更することができる。例えば、子供がリアルメーションパフォーマの目を覆ったアクションに応答して、アニメーションのオーディオ／ビデオプレゼンテーションを「いないいないばあ」の遊びに切り替えることができる。
【０１０４】
したがって、デュープレックス実施形態では、リアルメーション制御システムは、１つまたは複数のリアルメーションパフォーマと双方向通信を行う。リアルメーション制御システムのこの例としての実施形態の説明では、パーソナルコンピュータ上で実行され、マイクロプロセッサベースの通信デバイス上で実行される別のプログラムと協働するプログラムを説明するが、独立型プラットフォーム上で実行される単一のプログラム、または無線通信機器を備えた分散コンピューティングデバイスなどの他の実施態様でも十分である可能性があることが、当業者には認められよう。
【０１０５】
シンプレックス実施形態では、リアルメーション制御システムは、１つまたは複数のリアルメーションパフォーマと単一方向通信を行う。リアルメーション制御システムのシンプレックス実施形態の説明では、マイクロプロセッサベースの通信デバイス上で実行されるプログラムとインターフェースを取るビデオカセットレコーダ（ＶＣＲ）、またはケーブルＴＶボックスを説明するが、直接放送信号、レーザディスクプレーヤ、ビデオテーププレーヤ、ＣＤ−ＲＯＭにアクセスする計算デバイスなどの他の実施態様でも十分である可能性があることが、当業者には認められよう。さらに、この実施形態には、独立型構成で動作させるためにＶＣＲ、または同様のデバイスをマイクロプロセッサベースの通信デバイスに統合することが含まれることが可能である。
【０１０６】
マスタデバイスとスレーブデバイスの間の通信を振幅変調（「ＡＭ」）技術に従って形成されるＲＦ信号伝送の状況で説明する。ＲＦ信号は、あるデバイスから別のデバイスにデジタル情報の記号表現を転送するのに使用される。ＲＦ信号は、デジタルデータの記号表現の値に基づき、搬送波信号の振幅を所定の仕方で変調することによって生成される。以上のデバイス間で情報を伝送するための様々な通信技術を利用することができ、ＡＭ技術の使用を説明することにより、本実施形態の何らかの態様の原理が制限されるわけではないことを理解されたい。
【０１０７】
次に、いくつかの図面のすべてで同様の符号が同様の要素を表している図面を参照すると、本実施形態の態様、及び例としての動作環境が記載されている。図１４〜２０は、以下の考察と併せて、本実施形態を実装することができる適切な環境の簡単な一般的説明を提供することを目的としている。
【０１０８】
デュープレックス実施形態：パーソナルコンピュータベースのシステム
図１４は、本実施形態のデュープレックス実施形態のための例としての環境を示している。この環境は、リアルメーションパフォーマ２００６０を制御し、リアルメーションパフォーマ２００６０と対話を行うリアルメーション制御システム２００１０を含む対話式学習状況を子供に提供する。リアルメーション制御システム２００１０は、従来のパーソナルコンピュータ２００２０、リアルメーションリンクマスタ２００８０、アンテナ２００８８、スピーカ２００４３、及び表示デバイス２００４７を含む。パーソナルコンピュータ２００２０は、ハードディスクドライブ２００２７、磁気ディスクドライブ２００２８、及び／または光ディスクドライブ２００３０を含むことが可能である。
【０１０９】
動作中、リアルメーション制御システム２００１０は、表示デバイス２００４７上、及びスピーカ２００４３上でオーディオ／ビデオプレゼンテーションを制御する。さらに、リアルメーション制御システム２００１０は、リアルメーションデータをリアルメーションパフォーマ２００６０に伝送する。リアルメーションデータは、リアルメーションパフォーマ２００６０の動作を制御するための制御データ及び音声データを含む。リアルメーションデータを伝送するプロセスは、リアルメーションデータを符号化すること、符号化されたリアルメーションデータで搬送波を変調すること、及び変調された搬送波をＲＦ信号としてアンテナ２００８８からＲＦ通信チャネル２００１５を介して送信することを含む。
【０１１０】
リアルメーションパフォーマ２００６０は、アンテナ２００６８でリアルメーション制御システムからのＲＦ信号を受信する。受信機システム２００６１〜２００６７が、受信されたＲＦ信号を処理してリアルメーションデータを回復する。リアルメーションパフォーマ２００６０は、受信されたリアルメーションデータを解釈し、リアルメーションパフォーマ２００６０内部に実現された、少なくとも１つの口サーボモータ２００６９ａを含む１つまたは複数のサーボモータ２００６９ａ〜２００６９ｆの動作を制御することにより、かつ／またはスピーカ２００７１で聞こえるように出力されるように音声データを提供することにより、そのリアルメーションデータに応答する。したがって、適切なリアルメーションデータをリアルメーションパフォーマ２００６０に伝送することにより、リアルメーションパフォーマ２００６０が動き、オーディオ／ビデオプレゼンテーションの延長であるかのように話すことを生じさせる。
【０１１１】
また、リアルメーションパフォーマ２００６０は、光センサ及びタッチセンサ２００７０ａ〜２００７０ｆも含む。子供が適切な仕方でリアルメーションパフォーマ２００６０に触れた、リアルメーションパフォーマ２００６０を握り締めた、または動かしたことに応答して、リアルメーションパフォーマ２００６０内部の光センサ及び／またはタッチセンサ２００７０が、ステータス情報を生成することができる。リアルメーション制御システム２００１０からのコマンドに応答して、リアルメーションパフォーマ２００６０は、ステータス情報をリアルメーション制御システム２００１０による処理のために、ＲＦ通信チャネル２００１５を介してリアルメーションリンクマスタ２００８０に伝送することができる。ステータス情報を受信し、それを解釈することにより、リアルメーション制御システム２００１０は、そのステータス情報に相応する仕方でオーディオ／ビデオプレゼンテーションの進行を変更することができる。
【０１１２】
図１５は、デュープレックス実施形態のリアルメーション制御システム２００１０を実装するための例としてのシステムを示す図である。この例としてのシステムは、処理ユニット２００２１、システムメモリ２００２２、及びシステムメモリを処理ユニット２００２１に結合するシステムバス２００２３を含む従来のパーソナルコンピュータ２００２０を含む。システムメモリ２００２２は、読取り専用メモリ（ＲＯＭ）２００２４及びランダムアクセスメモリ（ＲＡＭ）２００２５を含む。ＲＯＭ２００２４は、始動中などにパーソナルコンピュータ２００２０内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入力／出力システム２００２６（ＢＩＯＳ）のためのストレージを提供する。パーソナルコンピュータ２００２０は、ハードディスクドライブ２００２７、取外し可能なディスク２００２９に対して読取り及び書込みを行う目的の磁気ディスクドライブ２８、及びＣＤ−ＲＯＭディスク２００３１を読み取る、またはその他の光媒体に対して読取り及び書込みを行う目的の光ディスクドライブ２００３０をさらに含む。ハードディスクドライブ２００２７、磁気ディスクドライブ２００２８、及び光ディスクドライブ２００３０は、それぞれ、ハードディスクドライブインターフェース２００３２、磁気ディスクドライブインターフェース２００３３、及び光ドライブインターフェース２００３４を介してシステムバス２００２３とインターフェースを取る。以上のドライブ、及び関連するコンピュータ可読媒体により、パーソナルコンピュータ２００２０のための不揮発性ストレージが提供される。コンピュータ可読媒体の上記の説明は、ハードディスク、取外し可能な磁気ディスク、及びＣＤ−ＲＯＭディスクについて述べているが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ等の、コンピュータによって読取り可能な他のタイプの媒体も例としての動作環境において使用できることが、当業者には理解されよう。
【０１１３】
オペレーティングシステム２００３５ａ、２００３５ｂ、１つまたは複数のアプリケーションプログラム２００３６ａ、２００３６ｂ、その他のプログラムモジュール２００３７ａ、２００３７ｂ、及びプログラムデータ２００３８ａ、２００３８ｂを含むいくつかのプログラムモジュールが、ドライブ２００２７〜２００３０、及びＲＡＭ２００２５の中に記憶されることが可能である。ユーザは、キーボード２００４０、及びマウス２００４２などのポインティングデバイスを介してパーソナルコンピュータ２００２０にコマンド及び情報を入力することができる。他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、トラックボール、ライトペン、ゲームパッド、スキャナ、カメラ等が含まれることが可能である。以上の入力デバイス、及びその他の入力デバイスは、しばしば、システムバスに結合されたシリアルポートインターフェース２００４６を介して処理ユニット２００２１に接続されるが、ゲームポートまたはユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ　ｓｅｒｉａｌ　ｂｕｓ）（ＵＳＢ）などの他のインターフェースで接続してもよい。また、コンピュータモニタ２００４７、または他のタイプの表示デバイスも、ビデオアダプタ２００４８などのインターフェースを介してシステムバス２００２３に接続される。１つまたは複数のスピーカ２００４３が、オーディオアダプタ２００４４などのインターフェースを介してシステムバスに接続される。モニタ及びスピーカに加えて、パーソナルコンピュータは、通常、プリンタやプロッタ（ｐｌｏｔｔｅｒ）などの他の周辺出力デバイス（図示せず）も含む。
【０１１４】
パーソナルコンピュータ２００２０は、リモートコンピュータ２００４９のような１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することが可能である。リモートコンピュータ２００４９は、サーバ、ルータ、ピアデバイス、またはその他の一般的なネットワークノードであることが可能であり、通常、パーソナルコンピュータ２００２０に関連して説明した要素の多く、またはすべてを含むが、図１５では、メモリ記憶デバイス２００５０だけを示している。図１５に描いた論理接続は、ローカルエリアネットワーク（ＬＡＮ）２００５１、及びワイドエリアネットワーク（ＷＡＮ）２００５２を含む。以上のタイプのネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、及びインターネットにおいて一般的である。
【０１１５】
ＬＡＮネットワーキング環境で使用されるとき、パーソナルコンピュータ２００２０は、ネットワークインターフェース２００５３を介してＬＡＮ２００５１に接続される。ＷＡＮネットワーキング環境で使用されるとき、パーソナルコンピュータ２００２０は、通常、インターネットなどのＷＡＮ２００５２を介して通信を確立するためのモデム２００５４、または他の手段を含む。内部にあることも、外部にあることも可能なモデム２００５４は、シリアルポートインターフェース２００４６を介してシステムバス２００２３に接続される。ネットワーク化された環境では、パーソナルコンピュータ２００２０に関連して描いたプログラムモジュール、またはプログラムモジュールの部分が、リモートのメモリ記憶デバイスの中に記憶されることが可能である。図示したネットワーク接続は、例としてのものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることが理解されよう。
【０１１６】
パーソナルコンピュータ２００２０は、処理ユニット２００２１が、様々なＭＩＤＩ対応デバイス（すなわち、電子キーボード、シンセサイザ等）を制御する手段を提供するミュージカルインスツルメンテーションデジタルインターフェース（ｍｕｓｉｃａｌ　ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ　ｄｉｇｉｔａｌ　ｉｎｔｅｒｆａｃｅ）（「ＭＩＤＩ」）アダプタ２００３９を含む。また、ＭＩＤＩアダプタにより、処理ユニット２００２１がリアルメーションリンクマスタ２００８０を制御できるようになることが可能である。ＭＩＤＩアダプタは、システムバス２３を介してデータを受け取り、そのデータをＭＩＤＩプロトコルに従って形式設定し、そのデータをＭＩＤＩバス２００４５を介して伝送することで動作する。ＭＩＤＩバスに接続された機器が、ＭＩＤＩ形式のデータの伝送を検出し、そのデータを無視すべきか、または受け入れて処理すべきかを判定する。したがって、リアルメーションリンクマスタ２００８０が、ＭＩＤＩバス上のデータを検査し、リアルメーションリンクマスタ２００８０を宛先の受取り側として明示的に特定するデータを処理する。データを受け取ったことに応答して、リアルメーションリンクマスタ２００８０は、そのデータをＲＦ通信チャネル２００１５を介して伝送することができる。
【０１１７】
図１６は、リアルメーションリンクマスタ２００８０を定義する様々な構成要素及び／またはプロセスを示すブロック図である。最初、コンピュータ２００２０上で実行されているプログラムが、データを生成することにより、またはコンピュータ２００２０がアクセスすることのできる記憶媒体からデータを取得することによってリアルメーションデータを獲得する。さらに、プログラムは、リアルメーション特有のプロトコルに従ってそのリアルメーションデータを形式設定することができ、あるいは、プログラムは、事前に形式設定されたリアルメーションデータを記憶媒体から取得することができる。プログラムは、ＭＩＤＩアダプタ２００３９及び２００８１、ならびにＭＩＤＩバス２００４５を含むＭＩＤＩインターフェースを介して、そのリアルメーションデータをリアルメーションリンクマスタ２００８０に転送する。このプロセスは、リアルメーションデータをＭＩＤＩ形式にパッケージ化しなおすこと含む。ＭＩＤＩインターフェースは、コンピュータ２００２０とリアルメーションリンクマスタ２００８０の間でリアルメーションデータを転送するのに使用することができるいくつかの可能なインターフェースの１つに過ぎないことが、当業者には理解されよう。代替のインターフェースには、ＲＳ２３２、セントロニクス（Ｃｅｎｔｒｏｎｉｘ）、及びＳＣＳＩなどのインターフェースが含まれるが、以上には限定されない。
【０１１８】
プロトコルハンドラ（ｈａｎｄｌｅｒ）２００８３が、ＭＩＤＩアダプタ２００８１からＭＩＤＩ形式のデータを受け取り、ＭＩＤＩの形式設定を除去してリアルメーションデータを回復する。このプロセス中、プロトコルハンドラ２００８３は、リアルメーションデータ、及び／またはＭＩＤＩ形式のデータをデータバッファ２００８２の中に一時的に記憶することができる。また、プロトコルハンドラ２００８３は、データを伝送する準備としてリアルメーションデータに対して他の操作も行うことができる。リアルメーションデータを伝送する前に、データエンコーダプロセス２００８４が、リアルメーションデータを符号化して、符号化されたリアルメーションデータをＲＦ送信機２００８６に提供する。ＲＦ送信機は、符号化されたリアルメーションデータを使用して搬送波を変調した後、変調された搬送波をアンテナ２００８８からリアルメーションパフォーマ２００６０（図１７）にＲＦ通信チャネル２００１５を介して伝送する。
【０１１９】
また、リアルメーションリンクマスタ２００８０は、１つまたは複数のリアルメーションパフォーマ２００６０、または他のデバイスからのリアルメーションデータを搬送する信号も受信することができる。リアルメーションリンクマスタ２００８０は、その信号をアンテナ２００８８で検出し、その信号をＲＦ受信機８７に提供する。ＲＦ受信機２００８７は、受信された信号を復調し、符号化されたリアルメーションデータを回復し、その符号化されたリアルメーションデータをデータデコーダプロセス２００８５に提供する。データデコーダプロセス２００８５は、符号化されたリアルメーションデータを復号化し、復号化されたリアルメーションデータをプロトコルハンドラ２００８３に提供する。プロトコルハンドラ２００８３は、復号化されたリアルメーションデータをＭＩＤＩ形式にパッケージ化し、ＭＩＤＩインターフェース２００８１を介してそのＭＩＤＩ形式のデータをコンピュータ２００２０に転送する。プロトコルハンドラ２００８３、及び／またはＭＩＤＩインターフェース２００８１は、処理中、リアルメーションデータをデータバッファ２００８２の中に一時的に記憶することができる。
【０１２０】
ＭＩＤＩインターフェース２００３９で情報を受け取ると、コンピュータ２００２０は、そのＭＩＤＩ形式のデータからリアルメーションデータを回復し、次に、そのリアルメーションデータを処理する。
【０１２１】
シンプレックス実施形態：ビデオ信号ベースのシステム
図１７は、本実施形態のシンプレックス実施形態のための例としての環境を示している。この環境は、リアルメーションパフォーマ２００６０を制御するリアルメーション制御システム２００１１を含む学習状況を子供に提供する。リアルメーション制御システム２００１１は、オーディオ／ビデオ信号ソース２００５６、リアルメーションリンクマスタ２００９０、アンテナ２００９８、ならびにスピーカ２００５９を含む表示デバイス２００５７を含む。リアルメーション制御システム２００１１は、アンテナ２００９８、及びＲＦ通信チャネル２００１５を使用してリアルメーションデータをリアルメーションパフォーマ２００６０に伝送する。このタスクを達するため、リアルメーションリンクマスタ２００９０は、標準のビデオ接続を介してオーディオ／ビデオ信号ソース２００５６、及び表示デバイス２００５７とインターフェースを取る。この標準のビデオインターフェースを介して、リアルメーションリンクマスタ２００９０は、リアルメーションデータで符号化されたビデオ信号（「符号化されたビデオ」）をオーディオ／ビデオ信号ソース２００５６から受け取る。リアルメーションリンクマスタ２００９０は、ビデオ信号からリアルメーションデータを取り出し、次に、ＲＦ通信チャネル２００１５を介してそのリアルメーションデータをリアルメーションパフォーマ２００６０に転送する。さらに、リアルメーションリンクマスタ２００９０は、取出しの済んだビデオ信号（「ビデオ」）を表示デバイス２００５７に送る。オーディオ／ビデオ信号ソース２００５６は、表示デバイス２００５７におけるスピーカ２００５９ともインターフェースを取る。このインターフェースを介して、オーディオ／ビデオ信号ソース２００５６は、オーディオ／ビデオプレゼンテーションのためのオーディオ信号を提供する。したがって、子供は、リアルメーションリンクマスタ２００９０が、リアルメーションデータを１つまたは複数のリアルメーションパフォーマ２００６０に伝送している最中に、表示デバイス２００５６上、及びスピーカ２００５９上でオーディオ／ビデオプレゼンテーションを見る／聞くことができる。リアルメーションデータの受信により、リアルメーションパフォーマ２００６０が、オーディオ／ビデオプレゼンテーションの延長であるかのように動き、話すことが生じさせられる。
【０１２２】
ビデオカセットレコーダまたはビデオカセットプレーヤ、ケーブル受信ボックス、ＴＶチューナ、レーザディスクプレーヤ、サテライトブロードキャスト、マイクロ波ブロードキャスト、またはビデオ出力を備えたコンピュータを含むが、以上には限定されない様々なソースにより、符号化されたビデオが提供されることが可能である。図１８は、リアルメーションデータで符号化されたビデオ信号を生成するパラダイムシステムを示すブロック図である。図１８で、コンピュータシステム２００２０は、ビデオデータエンコーダ２００７６及びオーディオ／ビデオ信号ソース２００５６とインターフェースを取る。オーディオ／ビデオ信号ソース２００５６は、次の２つの出力信号を提供する。すなわち、ビデオ及びオーディオである。これらの出力信号は、ライブカメラフィード（ｌｉｖｅ　ｃａｍｅｒａ　ｆｅｅｄ）、事前録音の再生、ブロードキャスト受信等を含むことが可能である。コンピュータシステム２００２０は、制御信号（「制御」）を使用してオーディオ／ビデオソース２００５６の動作を制御する。制御信号は、オーディオ／ビデオ信号ソース２００５６からのビデオ信号及びオーディオ信号の出力をゲート制御する。
【０１２３】
また、コンピュータシステム２００２０は、ビデオ信号の上に符号化するためのリアルメーションデータも提供する。コンピュータシステム２００２０は、ビデオデータエンコーダ２００７６に対してリアルメーションデータを転送し、ビデオ信号のゲート制御を行う。ビデオデータエンコーダは、リアルメーションデータをビデオ信号の上に符号化し、リアルメーションの符号化されたビデオ信号（「符号化されたビデオ」）を生成することによってビデオ信号とリアルメーションデータを結合する。この符号化技術は、ビデオ信号の水平オーバースキャン（ｏｖｅｒｓｃａｎ）領域の輝度をラインごとに変調することを含む。この技術により、各ラインに単一のリアルメーションデータビットが符号化されることがもたらされる。さらに、ビデオ信号のフィールド境界により、各フレームが固定数のデータ語を含む、リアルメーションデータに関するフレーム構造が提供される。
【０１２４】
より具体的には、ビデオ信号の各フィールドが、４ビットから構成されるパターン識別語を含む。それぞれの隣接するフィールドの中の４ビットパターン識別語の値は、定義された１組の値を巡回する。各フィールドの中のパターン識別語により、符号化されたビデオ信号が通常のビデオ信号と区別される。通常のビデオ信号では、ランダムな「雑音」がパターン識別語の代わりに現れる。符号化されたビデオ信号からリアルメーションデータを回復しようと試みるデコーダは、このパターンの存在を検出しなければならない。したがって、パターン識別語により、簡単なチェックサム誤り検出の完全性を上回るさらなる層の完全性が回復されたリアルメーションデータに提供される。
【０１２５】
オーディオ／ビデオ信号ソース２００５６から符号化されたビデオ信号を受け取るリアルメーションリンクマスタ２００９０は、その符号化されたビデオ信号からリアルメーションデータを回復し、次に、そのリアルメーションデータをリアルメーションパフォーマ２００６０（図１７に示す）に伝送することができる。あるいは、ビデオブロードキャスト機器２００７９が、符号化されたビデオ信号をオーディオ信号とともに受け取り、次に、その信号を１つまたは複数の遠隔に配置されたリアルメーションリンクマスタにブロードキャストすることができる。別の代替案では、ビデオ記憶機器２００７８が、符号化されたビデオ信号をオーディオ信号とともに受け取った後、その信号を将来の取出しのために記憶媒体上に記憶することが可能である。
【０１２６】
図１９は、リアルメーションリンクマスタ２００９０を定義する様々な構成要素及び／またはプロセスを示すブロック図である。リアルメーションリンクマスタ２００９０の構成要素のそれぞれは、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実装することができる。リアルメーションリンクマスタ２００９０のビデオデータ検出器２００９１が、オーディオ／ビデオ信号ソース２００５６を起点とするビデオ信号を受け取り、そのビデオ信号が、符号化されたビデオ信号であるかどうかを識別する。ビデオデータ検出器２００９１が、受信されたビデオ信号の中でパターン識別語の存在を検出した場合、そのビデオ信号は、符号化されたビデオ信号である。ビデオデータ検出器２００９１は、符号化されたビデオ信号からリアルメーションデータを取り除くことに取りかかり、そのリアルメーションデータをデータ誤りプロセッサ２００９９に提供する一方で、符号化されていないビデオ信号を表示デバイス２００５７に提供する。
【０１２７】
データ誤りプロセッサ２００９９は、リアルメーションデータを分析して、リアルメーションデータの中に誤りが存在すれば、その誤りを検出して訂正する。リアルメーションデータの中の誤りが訂正された後、プロトコルハンドラ２００９３が、回復され、確認されたリアルメーションデータを受け取り、１つまたは複数のリアルメーションパフォーマ２００６０に伝送するためにメッセージパケットを組み立てる。メッセージパケットを組み立てると、プロトコルハンドラ２００９３は、そのメッセージパケットをデータエンコーダ２００９４に提供する。データエンコーダ２００９４は、そのデータを符号化し、符号化されたデータをＲＦ送信機２００９６に提供する。ＲＦ送信機２００９６は、符号化されたデータを受け取り、その符号化されたデータで搬送波信号を変調する。さらに、ＲＦ送信機は、その変調された搬送波をアンテナ２００９８を介して伝送する。リアルメーションデータの処理中、様々な構成要素が、リアルメーションデータをデータバッファ２００９２の中に一時的に記憶することができる。
【０１２８】
表示デバイス２００５７が、ビデオデータ検出器２００９１から符号化されていないビデオ信号を受け取り、またオーディオ／ビデオ信号ソース２００５６からオーディオ信号を受け取る。これらの信号を受け取ることにより、表示デバイス２００５７上、及びスピーカ２００５９上のオーディオ／ビデオプレゼンテーションがもたらされる。
【０１２９】
表示デバイス２００５７上のオーディオ／ビデオプレゼンテーションと、アンテナ２００９８から伝送されたリアルメーションデータの間に関係が存在することを理解されたい。リアルメーションデータを検出するプロセス、誤りを訂正するプロセス、リアルメーションデータを符号化するプロセス、及び搬送波を変調するプロセスにより、わずかな遅延が導入される可能性があるが、表示デバイス２００５７によって受け取られたビデオ信号、及びアンテナ２００９８から伝送されたリアルメーションデータは、元の符号化されたビデオ信号の同一の領域から獲得されている。この特性により、コンテキストに依存した（ｃｏｎｔｅｘｔ−ｓｅｎｓｉｔｉｖｅ）リアルメーションデータをビデオ信号の上に符号化することが可能になる。コンテキストに依存したリアルメーションデータを１つまたは複数のリアルメーションパフォーマに伝送することにより、リアルメーションパフォーマが、オーディオ／ビデオプレゼンテーションに関連する仕方で動き、かつ／または話すことが可能になる。
【０１３０】
リアルメーションパフォーマ
図２０は、リアルメーションパフォーマ２００６０を定義する様々な構成要素及び／またはプロセスを示す機能ブロック図である。構成要素のそれぞれは、ハードウェアで、ソフトウェアで、またはハードウェアとソフトウェアの組合せで実装することができる。一般に、リアルメーションパフォーマは、ＲＯＭ、または何らかの他の不揮発性ストレージ媒体からプログラムを取り出し、そのプログラムの命令を実行するためのマイクロプロセッサまたは他の処理ユニットを含む。さらに、リアルメーションパフォーマ２００６０は、ＲＦ無線受信機２００６７などのハードウェア構成要素、ならびに、場合により、送信機２００６６、アンテナ２００６８、読取り可能で書込み可能な記憶メモリ２００６２、センサ２００７０、サーボモータ２００６９、音声合成器２００６１、及びスピーカ２００７１を含む。
【０１３１】
ＲＦ受信機２００６７は、アンテナ６８から検出された信号を受け取る。ＲＦ受信機は、搬送波を復調し、符号化されたリアルメーションデータを回復することで、受け取られた信号に対して作用する。次に、データデコーダ２００６５が、符号化されたリアルメーションデータを受け取り、復号化する。プロトコルハンドラ２００６３が、デコーダ２００６５から出力される復号化されたリアルメーションデータを受け取り、そのリアルメーションデータを解釈する。リアルメーションデータの内容に基づき、このプログラムは、制御信号及び／または音声データを適切なデバイスに送る。したがって、リアルメーションデータが制御情報を含む場合、モーションサーボモータ２００６９の１つまたは複数が制御信号を受け取り、作動させられる。さらに、リアルメーションデータが音声データを含む場合、音声合成器２００６１が、その音声データを受け取り、その音声データをオーディオ信号に変換した後、そのオーディオ信号をスピーカ２００７１に提供する。リアルメーションデータは、様々なプロセスが行われている最中に、データバッファ２００６２の中に一時的に記憶することが可能である。
【０１３２】
また、リアルメーションパフォーマ２００６０は、光センサ及びタッチセンサ２００７０を含むことが可能である。センサ７０は、圧力、光、温度、またはその他のパラメータの変動に応答してステータス情報を生成することが可能である。リアルメーションパフォーマ２００６０は、このステータス情報をリアルメーション制御システム２００１０（図１４に示す）に伝送することができる。このプロセスは、プロトコルハンドラ２００６３においてステータス情報を形式設定すること、データエンコーダプロセス２００６４においてそのステータス情報を符号化すること、ＲＦ送信機２００６６においてその符号化されたステータス情報で搬送波を変調すること、及び次に、変調された搬送波をアンテナ２００６８を通じてＲＦ通信パス２００１５を介して伝送することを含む。
【０１３３】
人間音声生成
本実施形態の説明に取りかかる前に、人間音声生成に関する簡単な背景を提供することが役立つことが分かるであろう。音声の発声機構（ｐｈｏｎａｔｏｒｙｍｅｃｈａｎｉｓｍ）及び分節機構（ａｒｔｉｃｕｌａｔｏｒｙ　ｍｅｃｈａｎｉｓｍ）は、様々な横断面の寸法の管に類似の特性の音響システムと見なすことができる。管の下端、つまり声道には、声門としても知られる声帯間に開口がある。声道の上端は、口唇で終わる。声道は、咽頭（食道から口までのつながり）、及び口、つまり口腔から成る。
【０１３４】
音声生成プロセスを研究する際、現実感があるが、扱いやすい数学モデルをもたらすやり方で物理システムの重要な特徴を取り出すことが役立つ。声門下のシステムは、肺、気管支、及び気管を含む。この声門下のシステムが、音声の生成のためのエネルギー源の役割をする。音声は、単に、肺から空気が排出され、もたらされる空気の流れが声道のどこかの収縮によって乱されるときにこのシステムから放射される音波である。
【０１３５】
音声サウンドは、励振の様式に従って３つの別個のクラスに分類することができる。本実施形態は、そのクラスのうち２つ、有声クラス及び無声クラスをその他のパラメータとともに使用して、アニメーションのキャラクタ、または機械的キャラクタの適切な口唇の位置、及び口の開きを決定する。有声サウンドは、緩和振動で声帯が震えるように声帯の緊張が調整された状態で声門を通るように空気を強制し、これにより、声道を励振させる空気の準周期的なパルスを生成することによって生成される。英語の母音のほとんどすべて、及び子音の一部が有声である。
【０１３６】
無声サウンドは、声道の何らかの地点で、通常、口側の終端の方で収縮を形成し、乱流を生成するのに十分なだけ高い速度でその収縮を通るように空気を強制することによって生成される。無声サウンドの例は、単語、ｈａｔ、ｃａｐ、及びｓａｓｈにおける子音である。ささやいている最中、生成されるすべてのサウンドが、無声である。
【０１３７】
口唇の位置及び口の開きを決定すること
簡単に説明すると、本実施形態は、話をするアニメーションのキャラクタ、または機械的キャラクタの口の特徴、すなわち、口唇の位置、及び口の開きを決定するためのシステムを提供する。口唇の位置は、アニメーションのキャラクタ、または機械的キャラクタの口唇の形状及び位置を指すものとして使用する。例えば、様々な母音及び子音などの様々なサウンドを人間が発音するには、話者の口唇が、様々な形状または位置に置かれなければならない。本実施形態は、アニメーションのキャラクタ、または機械的キャラクタが話しているサウンドを発音するのに必要な口唇の位置、または口唇の形状を決定することができる。
【０１３８】
口の開きは、アニメーションのキャラクタ、または機械的キャラクタの口唇間の開きの量を指すものとして使用する。例えば、大声で話している人間は、一般に、ささやいている人間よりも大きい口唇間の開きを有する。口の開きの決定の基礎にあるのは、この理解である。したがって、本実施形態は、アニメーションのキャラクタ、または機械的キャラクタが話しているサウンドを生成するのに必要な口唇間の開きの量を決定するための方法も提供する。口唇の位置と口の開きを組み合わせることにより、本実施形態は、話しているアニメーションのキャラクタ、または機械的キャラクタと、そのキャラクタが話している音声の間で現実感のある同期を提供するのに必要な口の特徴を決定する。
【０１３９】
本実施形態は、プログラムモジュールによって提供される命令に応答してコンピュータによって行われるコンピュータによって実装されるプロセスであることが、当業者には理解されよう。一実施形態では、プロセスを実行するプログラムモジュールは、コンピュータ２００２０（図１４）上に実装される。ただし、図１７に関連して前述したシンプレックス実施形態などの他の実施形態では、プロセスを実行するプログラムモジュールは、リアルメーションリンクマスタ２００９０（図１７）、またはリアルメーションパフォーマ２００６０（図１７）において実装されることが可能である。この実施形態では、リアルメーションリンクマスタ２００９０、またはリアルメーションパフォーマ２００６０が、プログラムモジュールによって提供される命令を実行する適切なコンピュータ（図示せず）を含む。
【０１４０】
次に、図２１を参照すると、本実施形態の例としての実施形態によるアニメーションのキャラクタ、または機械的キャラクタに関する口唇の位置及び口の開きを決定するための方法２０８００を例示する流れ図が示されている。方法２０８００は、ステップ２０８０５で開始し、ステップ２０８１０に進んで、時間領域音声信号が、デジタル式にサンプリングされるか、またはデジタル式に記録される。好ましくは、音声信号は、１６ビットのサンプリング精度を有する４４．１ｋＨｚのＣＤ品質サンプリングレートでサンプリングされる。４４．１ｋＨｚが、好ましいサンプリングレートであり、また１６ビットが、好ましいサンプリング精度であるが、他のサンプリングレート及びサンプリング精度を使用してもよいことを理解されたい。
【０１４１】
一実施形態では、時間領域音声信号は、リアルメーションパフォーマ２００６０（図１４及び１７）によって話される、歌われる、または別の仕方で生成される語またはサウンドに対応する。さらに別の実施形態では、時間領域信号は、表示デバイス２００４７（図１４）上に表示されるアニメーションのキャラクタによって話される、歌われる、または別の仕方で生成される語またはサウンドに対応する。代替の実施形態では、時間領域信号は、前に説明した図で示されていない他のアニメーションのキャラクタ、または機械的キャラクタによって話される、歌われる、または別の仕方で生成される語またはサウンドに対応することが可能であることも、当業者には認められよう。
【０１４２】
次に、図２２Ａ及び２２Ｂを参照すると、時間領域音声信号をデジタル式にサンプリングすることの概略が提供されている。図２２Ａは、通常の時間領域音声信号２０９００を示す図である。ｘ軸が、時間を表し、ｙ軸が、音圧（ａｃｏｕｓｔｉｃ　ｐｒｅｓｓｕｒｅ）の変動を表している。図２２Ａに見られるとおり、サウンドが生成されると、話者の口における音圧が、時間とともに変化し、音響的な波、つまり音波がもたらされる。図２２Ｂは、一部分２０９０５を拡大し、拡大部分２０９１０として示した通常の時間領域音声信号２０９００を示す図である。拡大部分２０９１０は、時間領域音声信号２０９００がデジタル式にサンプリングされる仕方を示している。各デジタルサンプルは、拡大部分２０９１０において黒のドットで終わる垂直線で表されている。したがって、図２２Ｂから外挿することができるとおり、サンプリングレートが増加するにつれ、時間領域音声信号に関するサンプル数が増加し、これにより、元の時間領域音声信号のより正確なデジタル表現がもたらされる。
【０１４３】
ステップ２０８２０で、ステップ２０８１０からのサンプリングされた音声信号が、フレームに分けられる、つまり分割される。各フレームは、特定の期間中のデジタルサンプルを含む。好ましくは、各フレームの長さは、２０ミリ秒である。したがって、例えば、再サンプリングされた音声信号の長さが２秒であり、かつ各フレームの長さが２０ミリ秒である場合、フレームの数は、２秒を２０ミリ秒で割ったもの、すなわち、１００フレームに等しい。当業者には周知のとおり、ほとんどの音声処理スキームにおける基礎にある想定は、音声信号のプロパティが、時間とともに比較的ゆっくりと変化するということである。この想定は、短いセグメント、つまりフレームが、あたかも固定のプロパティを有する一様のサウンド（ｓｕｓｔａｉｎｅｄ　ｓｏｕｎｄ）からの短いセグメントであるかのように分離され、処理される様々な処理方法をもたらす。したがって、ステップ２０８２０で、再サンプリングされた音声信号をフレームに分割して、以下により詳細に説明するとおり、口唇の位置及び口の開きのより正確な表現を提供するように信号をさらに処理することができる。
【０１４４】
次に、図２２Ｃを参照すると、フレームに分割された時間領域信号９００の図が示されている。フレーム２０９１５、２０９２０、２０９２５、２０９３０、及び２０９３５は、ステップ２０８２０で時間領域信号２０９００をフレームに分割したときに生成されることが可能なフレームの一部を例示するものである。図２２Ｃは、アナログ音声信号を示しているが、ステップ２０８２０でフレームに分けられる、つまり分割される再サンプリングされた音声信号は、実際には、図２２Ｂの拡大部分２０９１０において示すようなデジタルサンプルから構成されることを認識されたい。
【０１４５】
図２１を再び参照すると、ステップ２０８２５で、再サンプリングされた音声信号の各フレームにウィンドウ（ｗｉｎｄｏｗｉｎｇ）関数が適用される。ウィンドウ関数は、当業者には周知のデジタル音声処理技術である。ステップ２０８２５で、各フレームにウィンドウ関数が適用されて、各フレームの境界条件の効果が強調されなくなる。好ましくは、フレームの中央のデジタルサンプルは、ウィンドウ関数による影響を受けず、他方、フレームの端に近いサンプルが減衰されて、そのサンプルが強調されなくなる。ハミングウインドウ（Ｈａｍｍｉｎｇｗｉｎｄｏｗ）が、好ましくは、ステップ８２５で適用されるウィンドウ関数である。ただし、ハニング（Ｈａｎｎｉｎｇ）ウィンドウ関数、または三角ウィンドウ関数などの、ただし、それらには限定されないその他のタイプのデジタル音声処理ウィンドウ関数もステップ２０８２５で適用することが可能であることを理解されたい。
【０１４６】
ステップ２０８２５で、フレームのそれぞれにウィンドウ関数が適用された後、ステップ２０８３０で、線形予測符号化（ＬＰＣ）技術が、フレームのそれぞれに適用される。ＬＰＣ技術は、人間の声帯、及び人間がサウンドを生成する仕方をモデル化する圧縮された形態の人間の音声をもたらす。ステップ２０８３０でフレームにＬＰＣ技術を適用することの一環として、各フレームに関していくつかの属性が判定される。この属性には、音声信号フレームの利得、つまりパワーが含まれる。また、この属性には、いくつかのｋ係数、つまり反射係数も含まれる。ｋ係数には、ピッチ係数、及び有声／無声係数が含まれる。ＬＰＣ技術、ならびにＬＰＣ技術を介して判定される属性は、音声認識の分野の技術者には周知である。
【０１４７】
パワー、つまり利得が、各フレームに関して判定される。このパワーは、語または音節が話される際に分散される空気の量を示すものである。パワーは、一般に、増加するにつれて口唇間の開きの量が増大するため、口の開きをよく近似するものである。平方自乗平均（ＲＭＳ）法、及び予測誤差法（ｐｒｅｄｉｃｔｉｏｎ　ｅｒｒｏｒ　ｍｅｔｈｏｄ）を含むが、それらには限定されない、利得を判定する多くのやり方が存在することが当業者には理解されよう。
【０１４８】
ピッチ係数は、いくつかの異なる相関法の１つを使用して判定することができる。この方法の中で最も一般的なのは、平均振幅差関数（ＡＭＤＦ）であるが、当業者は、その他の関数を選択することもできる。この相関結果を使用して、あるセグメントの音声が有声であるか、または無声であるかを判定することができる。信号の高い自己相関は、そのセグメントが有声であることを意味する。より低い自己相関は、そのセグメントが無声であることを意味する。
【０１４９】
ステップ２０８３５で、各フレームに関してステップ２０８３０で判定されたｋ係数が、ケプストラム（Ｃｅｐｓｔｒａｌ）領域にマップされて、各フレームに関していくつかのケプストラム係数がもたらされる。ＬＰＣ領域からケプストラム領域へのマッピングは、音声認識の分野の技術者には周知である。ｋ係数は、観察者によって聴き取られるものにはうまくマップされないため、ケプストラム領域にマップされる。ｋ係数は、人間の声道の横断面積をモデル化する。したがって、ｋ係数は、音声認識において有効である、すなわち、音声を再現するのに有効であるが、口唇の位置及び口の開きを決定するためにはそれほど有効でない。他方、ケプストラム係数は、どのように人間の音声が投射され、どのように人間の声が他者によって聴き取られるかに関するモデルを提供する。したがって、ケプストラム係数は、話者の口唇の位置に関するよりよいモデルを提供する。ステップ２０８３０で判定された各フレームに関する利得は、変更されないままである。
【０１５０】
ステップ８２０４０で、各フレームに関してステップ２０８３５で決定されたケプストラム係数がベクトル量子化されて、各フレームに関するベクトル量子化結果が達せられる。ベクトル量子化結果は、各フレームに関するキャラクタの口唇の位置に対応する。ベクトル量子化技術は、当業者には周知である。ステップ８４０におけるベクトル量子化は、ニューラルネットワーク（ｎｅｕｒａｌ　ｎｅｔｗｏｒｋ）、最小距離マッピング、または当業者に周知の他の技術を使用して達することができる。
【０１５１】
図２３を参照して、ステップ２０８４０で達せられるようなベクトル量子化の代表的な例について述べる。図２３は、有声／無声係数及びピッチ係数を表すケプストラム係数を利用したベクトル量子化技術を示す図である。図２３のｘ軸は、ピッチ係数を表し、ｙ軸は、有声／無声係数を表している。図２３に示すとおり、ベクトル２１００５、２１０１０、及び２１０１５は、そのフレームに関するピッチ係数及び有声／無声係数に基づいてマップされている。したがって、ベクトル２１００５は、あるフレームに関する有声／無声係数及びピッチ係数に対応する。同様に、ベクトル２１０１０及び２１０１５もそれぞれ、あるフレームに関する有声／無声係数及びピッチ係数に対応する。ベクトル量子化を介して、マップされたベクトルを、ベクトルのマッピングに基づく対応するベクトル量子化結果に量子化する、つまり変換することができる。図２３では、有声／無声係数及びピッチ係数を使用するマッピング及びベクトル量子化を示しているが、任意の数の様々な係数をマップし、ベクトル量子化することができることが、当業者には認められよう。さらに、ベクトル量子化を使用して、口唇の位置以外のパラメータも決定することができる。例えば、ベクトル量子化を使用して、生成されているサウンドを判定することができ、これは、音声認識アプリケーションにおいて役立つ。ただし、本実施形態の場合、ベクトル量子化結果は、各フレームに関するアニメーションのキャラクタ、または機械的キャラクタの口唇の位置に対応する。
【０１５２】
ベクトル量子化は、最小距離マッピングにより、ニューラルネットワークを使用することにより（以上のどちらも周知の技術である）、または別の周知のベクトル量子化技術を使用することによって達することができる。図２３に示したとおり、ベクトル量子化を介して、ベクトル２１００５、２１０１０、及び２１０１５が、文字「ａ」を話しているときに生成されるサウンドに対応することが判定される。というのは、この例では、以上のベクトルは、文字「ａ」を話しているときに生成されるベクトルの範囲に最も近いからである。したがって、ベクトル２１００５、２１０１０、及び２１０１５に対応するフレームに関して、アニメーションのキャラクタ、または機械的キャラクタの口唇は、文字「ａ」のサウンドを生成する位置に置かれなければならないことが判定された。前述したのと同様の仕方で、ベクトル２１０２０、２１０２５、及び２１０３０は、「ｋ」、「ｔ」、または「ｄ」などの硬い子音のどれかを話しているときに生成されるサウンドに対応することが判定される。同様に、ベクトル２１０３５、２１０４０、及び２１０４５は、「ｓｈ」のサウンドを話しているときに生成されるサウンドに対応することが判定される。したがって、ベクトル量子化を介して、ステップ２０８４０で、アニメーションのキャラクタ、または機械的キャラクタの口唇の位置を決定できることを見て取ることができる。ただし、キャラクタの口唇の位置は、口の特徴の一部に過ぎない。キャラクタの口の特徴には、ＬＰＣ技術を適用したことの結果としてステップ２０８３０で判定された利得に対応する口の開きも含まれる。ただし、ステップ２０８３０で判定された利得は、さらに説明するとおり、アニメーションのキャラクタ、または機械的キャラクタに関して滑らかな音声パターンを生成するようにさらに処理する必要がある。
【０１５３】
利得係数は、例としての句２１２９９のフレームから計算され、図２５Ａで時間に対してプロットされている。図２１を再び参照すると、ステップ２０８４５で、利得の極大及び極小が、所定の数のフレーム内に見出される。次に、図２５Ｂを参照すると、極大２１２０１、２１２０３、２１２０５、２１２０７、２１２０９、２１２１１、２１２１３、２１２１５、及び２１２１７が見出される。極小２１２００、２１２０２、２１２０４、２１２０６、２１２０８、２１２１０、２１２１２、２１２１４、２１２１６、及び２１２１８が見出される。最小の時間量を下回る利得の極大及び極小を含むすべてのフレームは、ステップ２０８４５で棄却される。例えば、図２５Ｃを参照すると、極大２１２０１及び２１２１５が棄却され、また極小２１２０２及び２１２１６が棄却されている。
【０１５４】
ステップ２０８５０で、極小を含むフレームに関する利得、及び極大を含むフレームに関する利得が調整される。極小を含むフレームに関する利得は、調整された利得により、極小においてキャラクタの口が完全に閉じていることが生じるように調整される。調整された利得が、極大を含むフレームに関しても決定され、その調整された利得により、極大を含むフレームに関してキャラクタの口が完全に開いていることが生じるようになる。残りのすべてのフレームに関して、すなわち、利得の極小または極大を含まないフレームに関して、利得は、ステップ２０８３０で計算された値からの最小利得レベルと最大利得レベルの間で基準化される。例えば、図２５Ｃを参照すると、極大２１２０３、２１２０５、２１２０７、２１２０９、２１２１１、及び２１２１７が、最大利得レベル２１２５０に調整されている。極小２１２００、２１２０４、２１２０６、２１２０８、２１２１０、２１２１２、２１２１４、及び２１２１８が、最小利得レベル２１２６０に調整されている。
【０１５５】
前述し、図２５Ｃに示したとおり、キャラクタの口が各極小で完全に閉じ、各極大で完全に開くように、ステップ２０８５０で調整された利得が計算されて、キャラクタにより自然な口の動きが与えられる。そうでなければ、キャラクタの口唇は、キャラクタの口が明確に開くこと、及び閉じることがないため、唇を震わせてぶつぶつ言っているように見えることになる。ユーザは、キャラクタの口が、所定の時間内に完全に開き、完全に閉じることを予期している。口が完全に開閉しない場合、キャラクタの口唇が決して触れ合わないため、唇を震わせているように見える。口が十分に開かない場合、キャラクタは、ぶつぶつ言っているように見える。利得に関する極小及び極大は、４フレームより少ない間隔で、または４フレームより多い間隔で決定することが可能であることを理解されたい。ただし、６０〜８０ミリ秒の範囲内で口を完全に開かせ、完全に閉じさせることにより、アニメーションのキャラクタ、または機械的キャラクタに滑らかな口の動きが提供されることが確認されている。
【０１５６】
したがって、例えば、図２５Ｂ及び２５Ｃを参照して、フレーム２１２００〜２１２０４が、第１の語に関する極大及び極小であるものと想定する。第１の極小１２００を見出した後、利得分析は、口の最大の開きに設定する次の極大を探す。極大２１２０１は、最後の極小２１２００に近すぎるため、棄却される。利得分析は、次の極大２１２０３を探索し、極大２１２０３を口の最大の開きとして割り当てる。利得分析は、極大及び極小を探索するこのプロセスを続ける。２１２０５と２１２０７のように、第１の極大が極小に近すぎ、かつ次の極大がその極小から離れすぎている場合、利得分析は、閉じの極小２１２０４と２１２０８の間の距離、つまり期間を極大の数で割り、極大をその割った距離の中央に移動し、また極小をその割った距離の両端に移動する。また、これは、極小及び極大２１２０８〜２１２１４に関しても行われる。極小間の距離が、２１２１４〜２１２１８のように、強い語または音節の区切りとしては小さすぎる場合、利得分析は、極大のなかの最大のものを最大の開きとして選択する。次に、そのセグメント全体が、完全に閉じていることから完全に開いていることまでの範囲の間で基準化される。
【０１５７】
図２１を参照すると、各フレームに関して、ステップ２０８３０からの利得、またはステップ２０８５０からの利得（フレームが、極大または極小を含む場合）、及びステップ２０８４０からのベクトル量子化結果が、ステップ２０８５５で、経験的に導出されたマッピング関数に適用される。前述したとおり、利得は、キャラクタの口唇間の空間の量、すなわち、どれだけ広く口が開いているかを表す。ベクトル量子化結果は、キャラクタが発しているサウンドに関する口唇の位置を表す。一実施形態では、経験的に導出されたマッピング関数に利得、及びベクトル量子化結果を適用することにより、リアルメーションパフォーマ２００６０の口を駆動するサーボモータ２００６９によって提示することができる最も似通った口の形状がもたらされる。
【０１５８】
次に、図２４を参照すると、口の形状を決定するのにステップ２０８５５で使用することが可能な経験的に導出されたマッピング関数２１１００の代表的な例が示されている。図２４に示すとおり、各行２１１０５〜２１１３０が、異なる口唇の位置を表し、また各列２１１３５〜２１１６０が、異なる利得値を表している。利得値は、列２１１３５で最低であり、列２１１６０で最高である。各フレームに関する口の特徴を決定するため、口唇の位置、すなわち、行が、口の開き、すなわち、列と組み合わされ、もたらされる口の特徴のセルが決まる。例えば、口唇の位置が、行２１１１０に対応し、かつ利得、つまり口の開きが、列２１１５５に対応するものと想定する。この仮定の場合、もたらされる口の特徴は、セル２１１６５に含まれる。
【０１５９】
機械的キャラクタの場合、経験的に導出されたマッピング関数は、口のサーボモータを駆動して適切な口の特徴にするようにコマンドが、機械的キャラクタに送られることをもたらすルックアップテーブルとして実装することが可能である。例えば、一実施形態では、このルックアップテーブルは、コンピュータ２００２０（図１５）のシステムメモリ２００２２の中に記憶することが可能である。ルックアップテーブルから判定された口の特徴がリアルメーションリンクマスタ２００８０によって制御データとしてリアルメーションパフォーマ２００６０に送られて、リアルメーションパフォーマの口の特徴を制御するサーボモータ２００６９ａを設定することが可能である。別の例として、アニメーションのキャラクタに関して、経験的に導出されたマッピング関数により、表示デバイス上で口の形状の表示がもたらされることが可能である。次に、セルアニメ製作者が、キャラクタの口の形状を描く際、その表示された口の形状をアニメーションセルに直接に組み込むこと、またはその表示された口の形状を基準として使用することが可能である。
【０１６０】
ステップ２０８５５で、利得、及びベクトル量子化結果が、経験的に導出されたマッピング関数に適用された後、ステップ２０８６０で、方法は終了する。
【０１６１】
以上の説明から、本実施形態が、機械的キャラクタとアニメーションのキャラクタの両方に関して口唇の位置及び口の開きを決定するための迅速で、効率的であり、かつ正確な方法を提供することが、当業者には明白であろう。さらに、本実施形態が、微細な細分性を有する口唇の位置及び口の開きを決定するための方法を提供する、すなわち、口唇の位置及び口の開きの正確な表現を提供することも明白であろう。また、本実施形態が、デジタル環境に適合する口唇の位置及び口の開きを決定するための方法を提供することも明白であろう。
【０１６２】
さらに、リアルメーションパフォーマ２００６０を含む実施形態においては、音声信号がリアルメーションパフォーマによって話されるには、まず、口の特徴のデータが、リアルメーションパフォーマに送られなければならないことが、当業者には理解されよう。これは、リアルメーションパフォーマ２００６０の口唇の位置及び口の開きを制御するサーボ６９が設定されるのに時間を要するからである。
【０１６３】
以上、米国特許第６０６７０９５号明細書で開示されている内容を説明した。
【０１６４】
本発明の利点の１つは、ゲームコンソール上のプレーヤの全員に関する音声ストリームを結合して単一の圧縮されたデータストリームにして、限られた帯域幅の範囲内でネットワークを介してデータをより効率的に伝送することである。したがって、同一のゲームコンソール上の複数のプレーヤが、ゲームに参加する他のプレーヤの全員に話しているとき、その複数のプレーヤに関する音声データが結合されて１つのネットワークストリームになる。そのゲームコンソールから複数の音声データストリームを送信する必要がない。
【０１６５】
本発明の別の利点は、ゲームコンソール上でゲームを行っている可能性があるプレーヤの数の半分である最大数のエンコーダを割り振ることができることである。したがって、ゲーム設計者は、音声コミュニケーションに割り振られるべきリソースの量を決定することができ、また例えば、２つのエンコーダだけを提供し、そのエンコーダが、前述したとおり、ラウンドロビン式に動作することを要求することにより、そのリソースを制限することができる。ラウンドロビン手法を実行する際、前に伝送されたパケットを使用することでわずかに悪影響が存在するが、音声コミュニケーションの質に対する悪影響より、音声コミュニケーションのための計算リソースの使用の制限の方がはるかに重要であり、ゲームプレーの質に対する悪影響が最小限に抑えられる。
【０１６６】
インターネットまたは他のネットワークを介してゲームに参加しているとき、プレーヤは、オプションとして、行われているゲームに応じて、音声コミュニケーションをとる際の特定の言葉遣いに合意したプレーヤとだけゲームを行うのを選択することが可能である。また、プレーヤは、オプションとしてゲームが唯一、音声コミュニケーション能力を有するプレーヤと行われることを選択することが可能である。同様に、音声コミュニケーション能力のないプレーヤは、やはり音声コミュニケーション能力を有さない他のプレーヤとだけ選択的にゲームに加わることが可能である。
【０１６７】
本発明をその好適実施形態に関連して説明してきたが、特許請求の範囲の内で本発明に多くの変更を加えるのが可能であることが、当業者には理解されよう。したがって、本発明の範囲は、以上の説明によって全く限定されるものではなく、すべて特許請求の範囲に関連して定められるものとする。
【０１６８】
【発明の効果】
以上説明したように本発明によれば、ゲームデバイス上の複数プレーヤのリアルタイムな音声コミュニケーションの使用を実現することができる。
【図面の簡単な説明】
【図１】本発明の実施形態のマルチプレーヤゲームコンソール及び音声コミュニケーションシステムの概略を示す図である。
【図２】本発明の実施形態の図１のマルチプレーヤゲームコンソール及び音声コミュニケーションモジュールを示すブロック図である。
【図３】本発明の実施形態の音声コミュニケーション能力を有するマルチプレーヤゲームコンソールを示す機能ブロック図である。
【図４】本発明の実施形態のネットワークを介するポイントツーポイント通信で結合された２つのマルチプレーヤゲームコンソールを示す機能ブロック図である。
【図５】本発明の実施形態のネットワークを介して３つの他のマルチプレーヤゲームコンソールと通信するように結合された第１のマルチプレーヤゲームコンソールを示すブロック図である。
【図６】本発明の実施形態の２つの並列エンコーダを有するゲームコンソール上の複数のプレーヤに関する優先順位付け符号化を示す機能ブロック図である。
【図７】本発明の実施形態のマルチプレーヤゲームコンソール上で復号化するパケットをキューから選択する際に本発明によって使用されるステップを示す論理図である。
【図８】本発明の実施形態のマルチプレーヤゲームコンソールにおいて使用されるタイプ１の復号化エンジンを示す機能ブロック図である。
【図９Ａ】本発明の実施形態のマルチプレーヤゲームコンソールにおいて使用されるタイプ２の復号化エンジンを示す機能ブロック図である。
【図９Ｂ】本発明の実施形態の図９Ａのミクサ及び４ストリーム並列デコーダの詳細を示すブロック図である。
【図１０】本発明の実施形態のネットワークを介してサウンドデータの符号化されたパケットを送受信するためのステップのさらなる詳細を示す論理図である。
【図１１】本発明の実施形態のマルチプレーヤゲームコンソール上の各プレーヤに関してどのように音声ストリームが受信され、キューに入れられ、復号化されるかを示す機能ブロック図である。
【図１２】本発明の実施形態のサウンドパケットのラウンドロビン符号化を実行するステップを示す流れ図である。
【図１３】本発明の実施形態のプレーヤ間の音声コミュニケーションを使用するゲームにおいて音声オプションを選択するための例としてのユーザインタフェースを示す図である。
【図１３Ａ】本発明の実施形態のマルチプレーヤゲームにおいて別のプレーヤとの音声コミュニケーションを制御する、または除外するのにプレーヤが選択することができる１つのオプションを示す図である。
【図１３Ｂ】本発明の実施形態のマルチプレーヤゲームにおいて別のプレーヤとの音声コミュニケーションを制御する、または除外するのにプレーヤが選択することができる別のオプションを示す図である。
【図１４】デュープレックス実施形態のための例としての環境を示す図である。
【図１５】図１４に示したデュープレックス実施形態のリアルメーション制御システム（Ｒｅａｌｍａｔｉｏｎ　Ｃｏｎｔｒｏｌ　Ｓｙｓｔｅｍ）を実装するための例としてのシステムを示す図である。
【図１６】図１４に示したデュープレックス実施形態のリアルメーションリンクマスタを定義する様々な構成要素及び／またはプロセスを示すブロック図である。
【図１７】シンプレックス実施形態のための例としての環境を示す図である。
【図１８】リアルメーションデータで符号化されたビデオ信号を生成するパラダイムシステム（ｐａｒａｄｉｇｍａｔｉｃ　ｓｙｓｔｅｍ）を示すブロック図である。
【図１９】図１７に示したシンプレックス実施形態のリアルメーションリンクマスタを定義する様々な構成要素及び／またはプロセスを示すブロック図である。
【図２０】例としての実施形態によるリアルメーションパフォーマ（Ｒｅａｌｍａｔｉｏｎ　Ｐｅｒｆｏｒｍｅｒ）を定義する様々な構成要素及び／またはプロセスを示すブロック図である。
【図２１】例としての実施形態による口の特徴（ｍｏｕｔｈ　ｆｅａｔｕｒｅ）を決定するための方法を示す流れ図である。
【図２２Ａ】通常の時間領域音声信号を示す図である。
【図２２Ｂ】デジタル式にサンプリングされた拡大部分を含む通常の時間領域音声信号を示す図である。
【図２２Ｃ】フレームに分割された時間領域信号を示す図である。
【図２３】有声／無声（ｖｏｉｃｅｄ／ｎｏｎｖｏｉｃｅｄ）係数及びピッチ係数を表すケプストラム係数（Ｃｅｐｓｔｒａｌ　ｃｏｅｆｆｉｃｉｅｎｔ）を利用するベクトル量子化技術を示す図である。
【図２４】アニメーションのキャラクタまたは機械的キャラクタの口の特徴を決定するのに使用することができる経験的に導出されたマッピング関数の代表的な例を示す図である。
【図２５Ａ】時間に対してプロットされた例としての句の利得係数を示す図である。
【図２５Ｂ】極小及び極大が示された時間に対してプロットされた例としての句の利得係数を示す図である。
【図２５Ｃ】極小及び極大が基準化された時間に対してプロットされた例としての句の利得係数を示す図である。
【符号の説明】
１００　電子ゲームシステム
１０２　ゲームコンソール
１０４ａ、１０４ｂ、１０４ｃ、１０４ｄ　コントローラ
１４０、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄ　音声コミュニケーションモジュール
１４４　マイクロホン
１４６　ヘッドホン
１５０　ＣＰＵ
１５２　メモリ
１５４、１５６　デジタル信号プロセッサ
１５８　アナログ−デジタル変換器
１６０　シングルストリームエンコーダ
１６０ａ　２つの並列エンコーダ
１６１　デジタル−アナログ変換器
１６２　ネットワークキュー
１６２ａ、１６２ｂ、１６２ｃ　ネットワークキュー
１６３　ＵＳＢインタフェース
１６４ａ、１６４ｂ　選択エンジン
１６６ａ、１６６ｂ　ミクサ
１６８　デコーダ
１６８ａ、１６８ｂ　デコーダ
１７０　ネットワーク
１７２　ゲームコンソール
１７４　ネットワークキュー
１７６　シングルストリームデコーダ
１７８　ヘッドホン
１８０　マイクロホン
１８２　エンコーダ
１８４、１８６　ネットワークキュー
１８８　出力ルータ
１９０ａ、１９０ｂ、１９０ｃ、１９０ｄ　音声コミュニケーション
２００ａ、２００ｂ、２００ｃ、２００ｄ　プレーヤ
２０２ａ、２０２ｂ、２０２ｃ　マイクロホン
２０４　ルータ
２０６　ネットワーク層
２１０　ゲームコンソール
２１１ａ、２１１ｂ、２１１ｃ、２１１ｄ　マイクロホン
２１２　ゲームコンソール
２１３ａ、２１３ｂ、２１３ｃ、２１３ｄ
２１４　ゲームコンソール
２１５　優先順位付けアルゴリズム
２１６ａ、２１６ｂ　プレーヤ
２１７ａ、２１７ｂ、２１７ｃ、２１７ｄ
２１８　プレーヤ
２２０ａ、２２０ｂ、２２０ｃ、２２０ｄ
２４０、２４２、２４４　ストリーム
２４８　ヘッドセット
２５０　ヘッドホン
２５２　ミクサ
２５３　ヘッドホン
２５４　ミクサ
２５７、２６０　選択エンジン
２６２　４つの並列デコーダ
２６４、２６６、２７０、２７２　ミクサ
２８０、２８２、２８４、２８６　２ストリームミクサ
２８８　４ストリーム並列デコーダ
【図１】
2004024859.tif 000003
【図２】
2004024859.tif 000004
【図３】
2004024859.tif 000005
【図４】
2004024859.tif 000006
【図５】
2004024859.tif 000007
【図６】
2004024859.tif 000008
【図７】
2004024859.tif 000009
【図８】
2004024859.tif 000010
【図９Ａ】
2004024859.tif 000011
【図９Ｂ】
2004024859.tif 000012
【図１０】
2004024859.tif 000013
【図１１】
2004024859.tif 000014
【図１２】
2004024859.tif 000015
【図１３】
2004024859.tif 000016
【図１３Ａ】
2004024859.tif 000017
【図１３Ｂ】
2004024859.tif 000018
【図１４】
2004024859.tif 000019
【図１５】
2004024859.tif 000020
【図１６】
2004024859.tif 000021
【図１７】
2004024859.tif 000022
【図１８】
2004024859.tif 000023
【図１９】
2004024859.tif 000024
【図２０】
2004024859.tif 000025
【図２１】
2004024859.tif 000026
【図２２Ａ】
2004024859.tif 000027
【図２２Ｂ】
2004024859.tif 000028
【図２２Ｃ】
2004024859.tif 000029
【図２３】
2004024859.tif 000030
【図２４】
2004024859.tif 000031
【図２５Ａ】
2004024859.tif 000032
【図２５Ｂ】
2004024859.tif 000033
【図２５Ｃ】
2004024859.tif 000034