(57)【要約】  開示したシステムは、例えば、多人数参加型ゲームの音声データの複数のストリームの送信及び再生を調整し、聞き手が他のストリームを聞いている間にバッファリングされ、必要であれば、時間圧縮された音声の順次的な再生を提供する。すなわち、システムは、（１）音声チャンネルへのアクセスを調整し、（２）発話された音声を個別のブロックとして扱い、例えば、複数のチャンネルからのメッセージ又は単一のチャンネル内の複数のユーザからのメッセージをユーザに順次的に再生することによって、「互いに発話を重ならせる」ユーザの問題を解決する。メッセージは、時間圧縮レートで後に再生してもよく、ユーザによる又は個別の自動処理による指示に基づいて、中断させてもよい。【選択図】  図６
2010507353.tif 000002
【特許請求の範囲】
【請求項１】
マルチユーザシステムにおけるメッセージの送信を調整する方法において、
ａ．前記マルチユーザシステムの少なくとも２人の話し手からメッセージを送信する要求を受信するステップと、
ｂ．前記要求を、優先度システムに基づいて待ち行列に加えるステップと、
ｃ．要求が前記待ち行列の先頭にある場合、対応する話し手がメッセージを送信することを許可するステップとを有する方法。
【請求項２】
ユーザインタフェース上の指示を介して、送信が許可されたことを対応するユーザに通知するステップを更に有する請求項１記載の方法。
【請求項３】
前記各話し手は、関連する優先度を有し、前記送信の要求は、その要求に対応する話し手の優先度に少なくとも部分的に基づいて、前記待ち行列内に配置される請求項１記載の方法。
【請求項４】
前記話し手は、複数のチャンネルのいずれでも送信の要求を送ることができ、各チャンネルは、キーボード上のキー又は話し手が開始する他のイベントに関連付けられている請求項１記載の方法。
【請求項５】
前記メッセージの少なくとも１つに添付メッセージを加えるステップを更に有する請求項１記載の方法。
【請求項６】
前記添付メッセージは、ユーザインタフェース上のビジュアルキュー又はオーディオキューを含む請求項５記載の方法。
【請求項７】
前記送信の要求は、ユーザインタフェースを介して、システム内の他のユーザに表示される請求項１記載の方法。
【請求項８】
コンピュータに請求項１記載の方法を実現させる命令を格納したコンピュータにより読取可能な媒体。
【請求項９】
マルチユーザシステムにおけるメッセージの送信を調整する方法において、
ａ．前記マルチユーザシステムの少なくとも２人のユーザからメッセージを送信する要求を受信するステップと、
ｂ．前記要求を、システムの状態に少なくとも部分的に基づいて待ち行列に加えるステップとを有する方法。
【請求項１０】
前記システムは、大規模多人数参加型ゲームであり、前記状態は、クエスト、通常のゲームプレイ、トレードスキル又はオーバラップするメッセージの数に関連する請求項９記載の方法。
【請求項１１】
マルチ話者環境における複数の話し手が生成するメッセージの再生を調整する方法において、
ａ．時間に関して少なくとも部分的にオーバラップする少なくとも２つのメッセージを受信するステップと、
ｂ．前記少なくとも２つのメッセージを順次的に再生するステップとを有する方法。
【請求項１２】
前記再生は、少なくとも複数のメッセージを受信し、受信したメッセージを保存しながら行われる請求項１１記載の方法。
【請求項１３】
前記順次的な再生の順序は、ユーザによって決定される請求項１１記載の方法。
【請求項１４】
ａ．第１のメッセージを再生している間に、前記第１のメッセージの再生を停止するユーザ入力を受信するステップと、
ｂ．前記第１のメッセージに順次的に続く第２のメッセージを再生するステップとを有する請求項１１記載の方法。
【請求項１５】
前記第２のメッセージは、時間圧縮レートで再生される請求項１４記載の方法。
【請求項１６】
前記ユーザ入力は、キーボード入力又は他のユーザフィードバックメカニズムである請求項１４記載の方法。
【請求項１７】
前記順次的な再生の順序は、どのメッセージが先に受信されたかによって決定される請求項１１記載の方法。
【請求項１８】
前記順次的な再生の順序は、優先度システムによって決定される請求項１１記載の方法。
【請求項１９】
前記メッセージは、それぞれが関連する優先度レベルを有する１つ以上のチャンネルから受信され、前記優先度システムは、優先度がより高いチャンネルからのメッセージを、優先度がより低いチャンネルからのメッセージより先に再生する請求項１１記載の方法。
【請求項２０】
前記メッセージは、それぞれが関連する優先度レベルを有する１つ以上のチャンネルから受信され、
ａ．第１のチャンネルからの第１のメッセージを再生している間に、前記第１のメッセージの再生を停止するユーザ入力を受信するステップと、
ｂ．第２のメッセージを再生するステップと、
ｃ．前記第１のチャンネルより低い優先度レベルを有するチャンネルに前記第１のメッセージを割り当てるステップとを有する請求項１１記載の方法。
【請求項２１】
前記複数の話し手のうちの少なくとも１人の話し手は、関連する優先度レベルを有し、前記優先度システムは、優先度がより高い話し手からのメッセージを、優先度がより低い話し手からのメッセージより先に再生する請求項１１記載の方法。
【請求項２２】
前記メッセージの少なくとも１つを時間圧縮するステップを更に有する請求項１１記載の方法。
【請求項２３】
前記時間圧縮は、ピッチが実質的に維持されるように行われる請求項２２記載の方法。
【請求項２４】
前記時間圧縮は、メッセージ内の予め指定された長さ以上の無音部分を除去することによって、又はオーバラップするメッセージの密度が高いことによって定義されるタイムフレーム内に生じるメッセージのサブセットを除去することによって達成される請求項２２記載の方法。
【請求項２５】
前記第２のメッセージ及び後に受信する全てのメッセージは、再生が略々リアルタイムで行われるようになるまで、時間圧縮レートで再生される請求項１９記載の方法。
【請求項２６】
再生の前にメッセージの少なくとも１つに添付メッセージを加えるステップを更に有する請求項１１記載の方法。
【請求項２７】
メッセージの少なくとも１つをテキストに変換するステップを更に有する請求項１１記載の方法。
【請求項２８】
コンピュータに請求項１１記載の方法を実現させる命令を格納したコンピュータにより読取可能な媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
標準のマルチユーザボイスオーバＩＰ（voice-over-IP：ＶＯＩＰ”）システム、例えば、大規模多人数参加型オンラインゲーム（massive multiplayer online game：）で採用されているＶＯＩＰシステムでは、２人以上のユーザ又はプレーヤが同じチャンネルで同時に通話する際に問題が生じる。ユーザが「互いに発話が重なる」ことを回避することを試みても、伝送及び再生の生来的な遅延によって、このような試みが困難になる。マルチチャンネルシステムでは、異なるチャンネルの音声を聞き、異なるチャンネルで送信を行う複数の話し手が、互いに気付くことなく発話を重ならせ、両方のチャンネルを同時に聞く聞き手がこれを聞くために、問題が深刻になる。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
一例として、図１に示すシステム１０では、ゲームサーバ１２が複数のゲームクライアント１４、１６、１８にサービスを提供している。ゲームサーバ１２は、ゲームエンジンアプリケーションを実行し、総合的なゲーム仮想環境を維持し、プレーヤのキャラクタ及びクライアントにとってローカルな環境に関する情報をゲームクライアントに送信する。
【０００３】
ゲームクライアントは、メッセージを互いに送信することができ、メッセージには、テキスト又は音声を含ませることができる。図２は、従来のメディアメッセージ、具体的には、音声メッセージ２１を示しており、音声メッセージ２２は、時間軸２０によって測定される時間的な幾らかの長さを有している。複数のメッセージが到着し、同時に再生された場合、又は部分的にオーバラップした場合、同時に再生され、少なくともオーバーラップする２つのメッセージは、聞き手にとって聞き取りづらく、紛らわしいものとなる。例えば、図３は、マルチメディアメッセージ、すなわち、部分的にオーバラップする音声メッセージ２２、２４、２６を示している。ここに示す全てのメッセージは、単一のチャンネルＸ内に含まれている。時刻２８では、チャンネルＸの聞き手には、音声メッセージ２２のみが聞こえる。時刻３２では、チャンネルＸの聞き手には、音声メッセージ２２、２４がオーバラップして聞こえる。時刻３４では、チャンネルＸの聞き手には、同時に再生された音声メッセージ２２、２４、２６が聞こえる。３つのメッセージを１度に聞くことは、聞き手にとって非常に紛らわしい。図４は、図３と同様であるが、複数のチャンネルが存在している状況を示している。この場合、例えば、メッセージ３６、３８は、それらのチャンネルＸ内ではオーバラップしていないが、メッセージ３６は、チャンネルＹからのメッセージ４２、４４とオーバラップし、チャンネルＸのメッセージ３８は、チャンネルＹからのメッセージ４４とオーバラップしている。
【課題を解決するための手段】
【０００４】
ここに開示するシステムは、例えば、多人数参加型ゲームのためのＶＯＩＰシステムにおいて、音声データの複数のストリームの送信及び再生を調整する。また、システムは、音声の順次的な再生を提供し、音声は、聞き手が１つのストリームを聞いている間に次のストリームが到着した場合、バッファリングできる。また、音声は、時間圧縮してもよい。すなわち、システムは、（１）音声チャンネルへのアクセスを調整し、（２）発話された音声を個別のブロック（「メッセージ」）として扱い、例えば、複数のチャンネルからのメッセージ又は単一のチャンネル内の複数のユーザからのメッセージをユーザ（「聞き手」）に順次的に再生することによって、「互いに発話を重ならせる」ユーザ（「話し手」）の問題を解決する。包括的に言えば、できるだけリアルタイムに近い状態で、すなわち、話し手がメッセージを送信した時刻にできるだけ近い時刻において、聞き手が話し手のメッセージを聞くようにすることが目的である。
【０００５】
ＭＭＯの実施の形態では、例示的なチャンネルは、レイドチャンネル、ギルドチャンネル、グループチャンネル等を含んでいてもよい。メッセージは、高い圧縮レートで後に再生してもよく、ユーザによる又は個別の自動処理による指示に基づいて、中断させてもよい。
【０００６】
更に詳細に述べれば、第１の主要な側面は、チャンネルへのアクセスを調整する所定のチャンネルのための記録待ち行列メカニズム（recording queue mechanism）である。包括的に言えば、話し手は、待ち行列（queue）システムを介してのみチャンネルにアクセスできる。また、優先度がより高い話し手により速やかなアクセス及び制御を与えるように、優先度システムを介して、話し手にアクセス権を与えてもよい。他の実施の形態においては、アクセスの要求を、話し手又は全てのユーザにブロードキャストし、これにより、所定の話し手が、必要ならば、チャンネルを放棄して、要求を行った話し手に渡すようにしてもよい。また、チャンネルは、調整されていない手法又は部分的に調整された手法で動作するように構成してもよく、ここでは、現在、送信権が与えられている話し手からの音声は、再生システムにメッセージブロックを特定する目的のために、単一のストリームに混合される共通のストリームに混合される。
【０００７】
第２の主要な側面は、１つのチャンネル内の複数話し手から発せられ、又は複数のチャンネル上の１又は複数の話し手から発せられるメッセージのための再生待ち行列メカニズム（playback queue mechanism）である。包括的に言えば、聞き手は、記録待ち行列に基づいてメッセージを聞いてもよく、自らの好みに基づいて待ち行列を定義してもよい。複数のチャンネルの場合、再生のためにデフォルトのチャンネル順序を定めてもよく、聞き手が自らチャンネル順序を定義してもよい。いずれの場合も、再生は、時間圧縮してもよく、これによって、メッセージが話された直後にメッセージを聞くことができ、聞き手は、時間圧縮されていない再生の場合に比べてより多くのメッセージを聞くことを選択できる。例えば、他のメッセージを蓄積しながら、あるメッセージをリアルタイムに再生してもよい。一旦再生が完了すると、時間圧縮されたメッセージの再生がリアルタイム再生に「追いつく」まで、蓄積されたメッセージが時間圧縮レートで自動的に再生される。例えば、優先度がより高いチャンネル上でメッセージが検出された場合等には、聞き手は、チャンネルを切り替えることができる。これによって、聞き手は、優先度がより高いチャンネルに切り替え、優先度がより低いチャンネル上のメッセージを蓄積し、必要であれば、後で、このメッセージを時間圧縮レートで再生することができる。
【０００８】
音声又は他方のフィードバックをメッセージの先頭に挿入（プレフィックス）し、話し手に関する情報、話し手が記録しているチャンネルに関する情報等を提供してもよい。また、異なるソースから供給されるデータについて、動的に優先度が付された順次的なレビューを必要とするビデオアプリケーション又は他のアプリケーションにも、同様のシステムを適用できる。
【０００９】
一側面においては、本発明は、マルチユーザシステムにおけるメッセージの送信を調整する方法を提供する。方法は、マルチユーザシステムの少なくとも２人の話し手からメッセージを送信する要求を受信するステップと、要求を、優先度システムに基づいて待ち行列に加えるステップと、要求が待ち行列の先頭にある場合、対応する話し手がメッセージを送信することを許可するステップとを有する。他の側面として、本発明は、コンピュータにこの方法を実現させる命令を格納したコンピュータにより読取可能な媒体を提供する。
【００１０】
本発明の具体例は、以下の１つ以上を含むことができる。更なるステップとして、ユーザインタフェース上の指示を介して、送信が許可されたことを対応するユーザに通知してもよい。送信の要求は、キーボード入力又は話し手が開始する他のイベントによって生成してもよい。各話し手は、関連する優先度を有していてもよく、送信の要求は、その送信の要求に対応する話し手の優先度に少なくとも部分的に基づいて、待ち行列内に配置してもよい。優先度レベルの１つは、リーダ又は司会者レベルであってもよく、リーダ又は司会者レベルを有する話し手からのメッセージは、待ち行列の先頭に配置してもよい。リーダレベルの話し手からの入力に基づいて、リーダレベルではない話し手からの送信の要求を待ち行列の先頭に引き上げてもよい。システムは、大規模多人数参加型ゲーム、テレビ会議システム等であってもよい。話し手は、複数のチャンネルのいずれでも送信の要求を送ることができ、各チャンネルは、キーボード上のキーに関連付けられている。メッセージの少なくとも１つに添付メッセージを加えてもよく、添付メッセージは、メッセージの先頭の前に挿入してもよく、メッセージの末尾の後に追加してもよい。添付メッセージのコンテンツは、話し手又は聞き手が選択してもよく、アプリケーションが提供してもよく、話し手のアイデンティティを示す情報であってもよい。添付メッセージは、ユーザインタフェース上のビジュアルキュー（cue）又はオーディオキューを含んでいてもよい。システムがテレビ会議システムである場合、送信の要求は、動き又は音声検出システムによって生成してもよい。システムが大規模多人数参加型ゲームである場合、送信の要求は、音声検出システムによって生成してもよい。送信の要求は、ユーザインタフェースを介してシステム内の他のユーザに表示してもよい。マルチユーザシステムは、それぞれが対応する待ち行列を有する少なくとも２つのチャンネルを含んでいてもよい。
【００１１】
更なる側面として、本発明は、マルチユーザシステムにおけるメッセージの送信を調整する方法において、マルチユーザシステムの少なくとも２人のユーザからメッセージを送信する要求を受信するステップと、要求を、システムの状態に少なくとも部分的に基づいて待ち行列に加えるステップとを有する方法を提供する。一具体例においては、システムは、大規模多人数参加型ゲームであり、状態は、クエスト、通常のゲームプレイ、トレードスキル又はオーバラップするメッセージの数に関連していてもよい。
【００１２】
更に他の側面として、本発明は、マルチ話者環境における複数の話し手が生成するメッセージの再生を調整する方法を提供する。この方法のステップは、時間に関して少なくとも部分的にオーバラップする少なくとも２つのメッセージを受信するステップと、少なくとも２つのメッセージを順次的に再生するステップとを含む。他の側面として、本発明は、コンピュータにこの方法を実現させる命令を格納したコンピュータにより読取可能な媒体を提供する。
【００１３】
本発明の具体例は、以下の１つ以上を含むことができる。再生は、少なくとも他のメッセージを受信している間、又は複数のメッセージを蓄積し、蓄積されたメッセージを保存している間に行ってもよい。順次的な再生の順序は、ユーザが決定してもよい。第１のメッセージが再生されている間に、第１のメッセージの再生を停止するためのユーザ入力を受け付けてもよく、この場合、第１のメッセージに後続する第２のメッセージが再生される。第２のメッセージは、時間圧縮レートで再生してもよい。第１のメッセージは、削除してもよく、後に再生し直してもよい。ユーザ入力は、キーボード入力であってもよく、他のフィードバックメカニズム又はユーザが開始する他のイベントであってもよい。順次的な再生の順序は、どのメッセージが先に受信されたかによって決定してもよい。各メッセージは、対応する開始タイムスタンプ及び終了タイムスタンプを有していてもよく、順次的な再生の順序は、どのメッセージがより早い開始タイムスタンプを有しているか、又はどのメッセージがより早い終了タイムスタンプを有しているかによって決定してもよい。また、順次的な再生の順序は、優先度システムによって決定してもよい。メッセージは、それぞれが関連する優先度レベルを有する１つ以上のチャンネルから受信してもよく、優先度システムは、優先度がより高いチャンネルからのメッセージを、優先度がより低いチャンネルからのメッセージより先に再生してもよい。メッセージは、それぞれが関連する優先度レベルを有する１つ以上のチャンネルから受信してもよく、更なるステップは、第１のチャンネルからの第１のメッセージを再生している間に、第１のメッセージの再生を停止するユーザ入力を受信するステップを含んでもよく、この場合、第２のメッセージが再生され、第１のメッセージは、第１のチャンネルより低い優先度レベルを有するチャンネルに割り当てられる。この場合、第１のメッセージは、先頭から再生してもよく、再生が停止された時点から再生してもよい。優先度がより低いチャンネルから受信したメッセージは、時間圧縮レートで再生してもよい。複数の話し手のうちの少なくとも１人の話し手は、関連する優先度レベルを有していてもよく、優先度システムは、優先度がより高い話し手からのメッセージを、優先度がより低い話し手からのメッセージより先に再生するようにしてもよい。優先度がより低い話し手から受信したメッセージは、時間圧縮レートで再生してもよい。メッセージは、音声データ又はビデオデータを含んでいてもよく、大規模多人数参加型ゲーム、テレビ会議システム、ボイスオーバＩＰアプリケーション等に関係していてもよい。メッセージの少なくとも１つは、例えば、ピッチ（音高）が維持されるように時間圧縮してもよい。時間圧縮は、メッセージ内の予め指定された長さ以上の無音部分を除去することによって行ってもよい。この場合、除去された無音部分は、オーディオキュー又はユーザインタフェース内のビデオキューによって指示してもよい。これに代えて、時間圧縮は、オーバラップするメッセージの密度が高いことによって定義されるタイムフレーム内に生じるメッセージのサブセットを取り除くことによって達成してもよい。時間圧縮のレベルは、ユーザによって調整できるようにしてもよい。順次的に再生される第１のメッセージは、通常レートで再生し、順次的に再生される第２のメッセージは、時間圧縮レートで再生してもよい。これに代えて、両方のメッセージを時間圧縮してもよい。第２のメッセージ及び後に受信する全てのメッセージは、再生が略々リアルタイムで行われるようになるまで、時間圧縮レートで再生してもよい。時間圧縮のレベルは、受信しているがまだ再生されていないメッセージの累積的なファイルサイズに直接的に関連付けてもよい。再生の前にメッセージの少なくとも１つに添付メッセージを加えてもよく、メッセージの少なくとも１つに添付メッセージを加えてもよく、添付メッセージは、メッセージの先頭の前に挿入してもよく、メッセージの末尾の後に追加してもよく、添付メッセージのコンテンツは、話し手又は聞き手が選択してもよく、アプリケーションが自動的に選択してもよい。添付メッセージのコンテンツは、話し手のアイデンティティを示す情報であってもよい。少なくとも２つのメッセージは、単一のチャンネルからのメッセージであってもよく、少なくとも２つの複数の異なるチャンネルからのメッセージであってもよい。この方法は、マルチユーザアプリケーションを実行するサーバ上で実現してもよい。メッセージの少なくとも１つをテキストに変換してもよい。メッセージは、それぞれが関連する優先度レベルを有する１又は複数のチャンネル又は話し手から受信してもよく、優先度システムは、優先度がより高いメッセージを再生し、優先度がより低いメッセージをテキストに変換するようにしてもよい。
【図面の簡単な説明】
【００１４】
【図１】従来のゲームサーバ／ゲームクライアントシステムを示す図である。
【図２】ここでは、音声メッセージとして示す従来のメディアメッセージを示す図である。
【図３】全てのメッセージが１つのチャンネルに含まれ、時間的に部分的にオーバラップする一組の従来のメディアメッセージを示す図である。
【図４】異なるチャンネルに含まれ、時間的に部分的にオーバラップするメッセージ一組の従来のメディアメッセージを示す図である。
【図５】本発明の方法を実現できるゲームサーバ／ゲームクライアントシステムを示す図である。
【図６】本発明の第１の実施の形態に基づく方法を示す図である。
【図７】図６の方法の詳細を示す図である。
【図８】本発明の第２の実施の形態に基づく方法を示す図である。
【図９】図８の方法の詳細を示す図である。
【図１０】図８の方法の更なる詳細を示す図である。
【図１１】図８の方法のより更なる詳細を示す図である。
【図１２】本発明の第２の実施の形態に基づく例示的な方法の結果を示す図である。
【図１３】本発明の第２の実施の形態に基づく他の例示的な方法の結果を示す図である。
【発明を実施するための形態】
【００１５】
オーバラップするメディアメッセージを調整するシステム及び方法の説明において用いられる定義を以下に示す。
【００１６】
「話し手」とは、メディアメッセージのコンテンツを提供する個人である。一方、「聞き手」とは、メディアメッセージのコンテンツが提供される個人である。聞き手は、メディアメッセージを実際に聞く必要はなく、聞き手は、再生をスキップすることを選択してもよく、又はメッセージを自動的にフィルタリングすることによって、メッセージをスキップし、削除し、後で再生し、ある再生レートで再生し、テキスト化（text transcription）の対象とする等してもよい。
【００１７】
「メッセージ」又は「メディアメッセージ」とは、時間的にある長さを有するコンテンツの個別のブロックである。メディアメッセージは、通常、話し手によって提供されるが、メディアメッセージは、マシンによって自動的に、例えば、プレーヤではないキャラクタによって提供してもよい。多くの場合、メッセージは、話し手が自らのコンピュータのキーを押し、発話し、次にキーを離すことによって生成される。このデータのパッケージは、分割されず、又は他の音声に混合されない限定された数秒の音声を表す。このようなメッセージは、サーバに送信され、必要ならば、遅延を短縮するためにストリーミングされ、次に、クライアントに配信されることがある。また、システムは、ピアツーピアアーキテクチャで動作させてもよい。ここでは、音声メッセージについて説明するが、本発明は、如何なる種類のコンテンツにも適用できることは明らかである。
【００１８】
「添付メッセージ」とは、メッセージに追加され、多くの場合、メッセージのソースに関する情報を提供するコンテンツを意味する。添付メッセージは、話し手又は聞き手が提供してもよく、アプリケーションが自動的に提供してもよい。また、添付メッセージは、他の種類の情報を提供してもよい。
【００１９】
「プレフィックス」とは、メディアメッセージの先頭の前に挿入される一種の添付メッセージである。「サフィックス」とは、メディアメッセージの末尾の後に追加される一種の添付メッセージであり、プレフィックスと同様の情報を提供することができる。
【００２０】
「キューメッセージ（cue message）」とは、話し手がメッセージを送信してもよいことを話し手に通知した後に話し手に提供される一種のメッセージである。例えば、キューメッセージは、話し手が送信を行おうとしているチャンネルの名称を話し手に通知するために用いてもよい。キューメッセージは、通常、システムによって提供されるが、キューメッセージは、話し手又はユーザによって変更又はカスタマイズしてもよい。
【００２１】
「リアルタイム」とは、話し手が発話した単語が、発話されてからできるだけ速やかに聞き手に聞こえる通信を意味する。通常、送信の遅延のため、最善でも、話し手が発話した単語が発話された直後に聞き手に聞こえ、この場合、「略々リアルタイムで」又は「リアルタイムに近い」、若しくは同様の句を用いて、再生が行われたと表現する。
【００２２】
「順次的」とは、メッセージが１つずつ、すなわち、オーバラップしないように再生されることを意味する。但し、順次的なメッセージは、互いに対して区切ってもよく、例えば、順次的なメッセージの再生の間に無音の期間又は他のコンテンツを挿入してもよい。
【００２３】
本発明の殆どの実施の形態では、話し手のクライアントからサーバにメッセージの先頭がストリーミングされ始めたとき、メッセージが「送信された」と言う。同様に、サーバから聞き手のクライアントにメッセージの先頭が到着し始めたとき、メッセージが「受信された」と言う。幾つかの実施の形態では、これらの用語は、単なる先頭ではなく、メッセージの全体が送信又は受信されたときに適用することができ、このような実施の形態では、多くの場合、メッセージの末尾の受信と同等の意味を有する。ここで、可能な限りリアルタイム通信に近い通信を実現するために、ストリーミング技術を用いてもよい。この場合、上述の用語は、メッセージの先頭の受信に適用される。
【００２４】
図５は、本発明のある方法を実現できるシステム４６を示している。サーバ４８は、クライアントコンピュータＳ１、Ｓ２、Ｌ１と通信を行う。ここでは、説明のため、Ｓ１及びＳ２は、話し手クライアントを表し、Ｌ１は、聞き手クライアントを表すものとする。もちろん、これらの役割は、随時、切り替え又は結合することができる。
【００２５】
図６に示すフローチャートは、本発明の第１の実施の形態を実施する方法５０を示している。この方法は、話し手によるチャンネルへのアクセスを調整する手法を提供する。包括的に言えば、話し手は、待ち行列システムを介してチャンネルにアクセスするが、この方法は、優先度がより高い話し手により速やかなアクセス及び制御を与えるように、優先度システムを介して、話し手にアクセスを与えることによって改善することができる。これらの技術の詳細を以下に説明する。
【００２６】
まず、話し手Ｓ１は、サーバに送信の要求（Request to Transmit：ＲＴＴ）を送る（ステップ５２）。ＲＴＴは、マウスクリック、キーボード入力又はこれらに類する他のメカニズムによって生成することができる。次に、ＲＴＴは、チャンネルの全てのユーザに表示され（ステップ５７）、これにより、他のユーザ、特に現在の話し手は、必要ならば、チャンネルを放棄できる。また、ＲＴＴは、チャンネルユーザのサブセットのみ、例えば、現在、発話のためのアクセスを有するユーザのみに表示するようにしてもよい。
【００２７】
そして、サーバは、後に詳細に説明するように、現在有効な一組の規則に基づいて、待ち行列を順序付けし及び／又は更新する（ステップ５８）。サーバは、待ち行列の先頭の名称をチェックし（ステップ６２）、対応する話し手に対し、その話し手がチャンネルへのアクセスを許可されたことを通知する。このとき、或いは話し手が送信ボタン（TRANSMIT button）を押した後、キューを提供できる（ステップ６６）。このようなキューは、適切なＵＩを介して、音声又はビデオの形式で行ってもよく、例えば、話し手が送信を行おうとしているチャンネルの名称を話し手に通知してもよい。話し手による送信の開始（ステップ６８）に続いて、サーバは、待ち行列の先頭から名称を取り除き（ステップ７２）、処理を繰り返す。
【００２８】
図７は、待ち行列を順序付けるステップ（ステップ５８）を更に詳細に示している。なお、この図に示す各ステップは、方法のあらゆる実施の形態において、如何なる順序で実行してもよく、必ずしも全てを実行しなくてもよい。
【００２９】
待ち行列を順序付ける手法の１つとして、話し手によって選択された優先度の考慮を含ませる手法がある（ステップ７４）。あるチャンネルの話し手は、そのチャンネルに発信するあるメッセージを、他のメッセージより高い優先度を有するメッセージとして指示することができる。例えば、ＭＭＯロールプレイングゲームにおいて、「敵接近（enemy approaching）」メッセージに、通常の会話メッセージより高いチャンネル優先度を与えてもよい。これを実現する一手法として、メッセージの優先度に影響を及ぼすために話し手が使用できる異なるキーを設けてもよい。プレーヤは、送信前、送信中又は送信後にキーを押すことによって、メッセージの優先度に影響を及ぼすことができる。これにより、プレーヤは、重要なイベントが発生した際、チャンネルにおける会話に潜在的に割り込みをかけることができる。
【００３０】
ＲＴＴの待ち行列を順序付ける他の手法として、話し手の優先度に基づいて、例えば、レベル又は他の優先度スキームによって、待ち行列を配列する（ステップ８２）手法がある。この手法では、優先度がより高い話し手は、チャンネルへのアクセスをより容易に得ることができる。この方法の特別なケースでは、チャンネルのリーダ、チャンネル司会者、又はアクセスを優先させることが適切な他の話し手からのＲＴＴを待ち行列の先頭に直ちに置く（ステップ７６）。これに対応して、このような個人は、例えば、限定的な期間、優先度がより低い話し手にこのようなアクセス権を与えることもできる（ステップ７８）。
【００３１】
より包括的に言えば、「許可された話し手」リストを使用し、このリストに含まれている話し手を常に優先させ、このような話し手に対してクロストークを許可してもよく、或いは、このような話し手が、ここに開示する方法に基づいて、メッセージを待ち行列に加えてもよい。
【００３２】
逆に、ＲＴＴが確認されているスパムのソースからのものである場合、そのＲＴＴを削除し、又は低い優先度を与えてもよい。
【００３３】
ＲＴＴの待ち行列を順序付ける更なる手法として、単純に、要求の時刻によってこれを行ってもよい（ステップ８４）。各ＲＴＴがサーバによって受信されると、ＲＴＴには、タイムスタンプが付与され、このタイムスタンプは、待ち行列内でメッセージを順序付けるために使用される。多くの場合、他のステップをこのステップに完全に置き換えてもよいが、ある目的では、様々なステップを組み合わせることが特に有益である。
【００３４】
システムの状態に基づいて、待ち行列に自動的に影響を及ぼしてもよい。例えば、多人数参加型ゲームの実施の形態において、多数のＲＴＴが一度に受信された場合、ハイレベルのアクションが発生していると推定でき、この方法は、あるＲＴＴの受け付けを自動的に拒否してもよく、この拒否は、所定の基準に基づき、例えば、システムは、ある優先度レベルより低い優先度のプレーヤからのＲＴＴを拒否できる。
【００３５】
また、上の説明は、マルチチャンネルシステムにも適用できる。話し手は、各チャンネルに関連付けられた入力キーを用いて、１つ以上のチャンネルを介してメッセージを送信することできる。各チャンネルは、個別のキーを有していてもよく、このキーは、キーボード上のキーであってもよく、仮想キー、すなわちＵＩ上のボタンであってもよく、キーの押下によって、キーに対応するチャンネルを介してＲＴＴが送られる。
【００３６】
図８に示すフローチャートは、本発明の第２の実施の形態に基づく方法を示している。この実施の形態は、１つのチャンネル内の複数話し手から、又は複数のチャンネルに亘る１又は複数の話し手からの複数のオーバラップするメッセージのための再生待ち行列メカニズムを含む。このシステムは、図６の方法と組み合わせて用いることができるが、必ずしもその必要はない。すなわち、図８のシステムは、独自に採用してもよい。
【００３７】
この方法の第１のステップでは、２つ以上のオーバラップするメッセージを受信する（ステップ８６）。これらのメッセージは、メモリ、バッファ、又は他の適切な種類の記憶装置に保存してもよい（ステップ８８）。なお、このステップは、ステップの完了の前にメッセージの全体を保存することを必要とはしない。メッセージがストリーミングメディアとして伝送される場合、メッセージの残りの部分を受信しながら、メッセージのポインタ又は他のインジケータを保存してもよい。
【００３８】
そして、メッセージは、聞き手によって選択された配列に基づいて再生待ち行列（playback queue）に配置される（ステップ９２）。以下、このような配列の詳細について説明する。
【００３９】
待ち行列の先頭のメッセージに対して、送信の前に、オプションの準備ステップを行ってもよい（ステップ９４）。準備の一例は、添付メッセージの追加である。添付メッセージは、メッセージの送信の直前又は直後に送信されるメッセージである。添付メッセージは、直前に送信される場合、「プレフィックス」と呼ばれ、直後に送信される場合、「サフィックス」と呼ばれる。添付メッセージは、通常、話し手を特定するために使用でき、添付メッセージは、話し手又はシステムが生成してもよく、或いは聞き手が生成してもよい。話し手は、特別な識別音声コード、例えば、話し手の名称が重ねられた短い音楽、又はこれに類する他の識別情報を有していてもよい。同様に、聞き手が、聞き手のグループの各プレーヤについて、カスタマイズされた個別の添付メッセージをアップロードしてもよい。
【００４０】
幾つかの実施の形態では、音声メッセージをテキストに変換するオプションのステップ（ステップ９６）を行ってもよく、音声メッセージは、単一の画像、又は動画のための一連の単一の画像等のデータの他の表現に変換してもよい。これは、優先度が低い話し手又は優先度が低いチャンネルからの優先度が低いメッセージ、又は聞き手がテキストとして記録することを望むメッセージについて特に適切である。また、あるメッセージは、自動的に保存してもよく、後に、例えば、ユーザがオフラインのときに、聞き手の選択に応じて、非順次的に再生するようにしてもよい。
【００４１】
このステップに続いて、メッセージを時間圧縮し（ステップ９８）、聞き手によって部分的に配列された順序である待ち行列の順序に基づいて、メッセージのストリーミングを開始する（ステップ１０２）。これらのステップの詳細については、図９〜図１１を参照して後に説明する。
【００４２】
幾つかの実施の形態では、メッセージの再生中に、ユーザは、再生を止めることができ、メッセージの残りの部分を無視し（ステップ１０４）、代わりに、待ち行列内の次のメッセージを聞く（ステップ１０４）ことを選択できる。ユーザが、通常のケースとして、再生を止めない場合、ステップ１０４のＮＯ分岐に進み、方法は、ステップ８６から繰り返される。ユーザがメッセージをスキップすることを選択した場合、ステップ１０４のＹＥＳ分岐に進み、再生を停止する（ステップ１０６）。このメッセージは、削除してもよく（ステップ１０８）、後の再生のために保存してもよい（ステップ１１２）。メッセージを保存する場合、そのメッセージがより低い優先度で後に再生されるように、そのメッセージの優先度レベルを調整してもよい。このようなメッセージの再生は、メッセージの先頭から始まるように、又は聞き手が再生を止めた時点から始まるように、聞き手によって設定できる。
【００４３】
図９は、ステップ８６をより詳細に示している。メッセージ受信ステップ（ステップ８６）は、メッセージストリームの先頭が受信されると始まる（ステップ１１６）。次に、メッセージの先頭を受信した時刻に対応する開始タイムスタンプをメッセージに割り当てる（ステップ１１８）。そして、メッセージの末尾を受信した時刻に対応する終了タイムスタンプをメッセージに割り当てる（ステップ１２２）。但し、このステップは、図９における他の如何なるステップを実行した後に実行してもよい。実際、このオプションのステップは、聞き手にメッセージを送信し始めた後に行ってもよい。メッセージには、メッセージが生成されたチャンネルに基づいて優先度レベルを割り当て（ステップ１２４）、及び話し手の優先度レベルに基づいて優先度レベルを割り当てる（ステップ１２６）。ステップ８６には、これらの順序付けステップ１１６〜１２６の何れか又は全てを含ませることができる。例えば、多くの場合、タイムスタンプステップ１１８／１２２の一方のみが必要とされる。
【００４４】
図１０は、ステップ９２をより詳細に示している。メッセージ配列ステップ（ステップ９２）は、チャンネルの優先度が最も高いものから最も低いものへの順に、オーバラップするメッセージを順序付けすることによって開始してもよい（ステップ１２８）。この順序付けに続いて、いずれかのチャンネルについて、オーバラップするメッセージを、話し手の優先度が最も高いものから最も低いものへ順序付けてもよい（ステップ１３２）。最終的に、いずれかのチャンネル及び話し手の優先度レベルについて、メッセージの開始タイムスタンプに基づいてメッセージを順序付けしてもよく（ステップ１３４）、すなわち、最も早くサーバが受信したメッセージを最初に送信し、後続するメッセージを次に送信するようにしてもよい。
【００４５】
これまで、順序付けの例示的な方法について説明したが、この方法は、デフォルトの配列に適用してもよい。しかしながら、この方法をカスタマイズして、聞き手が待ち行列を任意に配列できるようにしてもよい。
【００４６】
図１１は、ステップ９８をより詳細に示している。再生メッセージの何れか又は全ては、時間的に圧縮してもよく、これにより、聞き手は、圧縮しない場合に比べて、より多くの数のメッセージを聞くことができる。更に、この手法によって、再生メッセージは、圧縮がない場合に比べて、発話された後により早く聞くことができる。
【００４７】
包括的に言えば、他のメッセージを蓄積しながら、あるメッセージをリアルタイムに再生してもよい。一実施の形態においては、一旦再生が完了すると、時間圧縮されたメッセージの再生がリアルタイム再生に「追いつく」まで、蓄積されたメッセージが時間圧縮レートで自動的に再生される（ステップ１３６）。
【００４８】
時間圧縮技術は、周知である。ここで、これらの実施の形態について、幾つかのポイントについて説明する。第１に、多くの聞き手にとって、話し手のピッチを維持する時間圧縮技術を用いることが望ましい場合がある（ステップ１３８）。すなわち、これによって、圧縮されたメッセージがより理解しやすくなることがある。メッセージを圧縮する他の手法として、単語間の無音部分を削除する手法がある（ステップ１４２）。同様の技術として、周期的なセクション、例えば、数ミリ秒毎のセクションを削除する手法もある。このような処理を行っても、理解のしやすさへの影響は無視できる程度であることが知られている。いずれの場合も、圧縮が行われていることを聞き手に通知するオプションのオーディオキュー又は他のフィードバックメカニズムを使用してもよい（ステップ１４４）。
【００４９】
聞き手ができるだけ多くの重要なメッセージを聞いて理解できるようにするために使用できる他の技術として、騒ぎ（flurry）が起きている間に発生した所定数のメッセージを削除する手法がある（ステップ１４６）。具体的には、多くの状況において、特に多人数参加型ゲームに関連する状況において、特定のイベントによって、同時に多数のメッセージが生成されることがある。例えば、敵戦闘員（enemy combatant）の出現によって、多くの場合、レイド又はクエストグループ内のプレーヤに／から、多くの警告コール（warning call）が発せられる。システムは、同時又は略々同時に多数のメッセージが生成されたことを感知し、ある優先度レベルを超える話し手からのメッセージ、又は聞き手が設定又は選択した配列基準を含む他の何らかの種類のふるい分け基準を用いて選別されたメッセージのみを再生することを選択する。
【００５０】
システムは、保存されたメッセージの数が多くなるにつれて、自動的に又はユーザによる選択によって、圧縮のレベルを高めてもよい（ステップ１４８）。これにより、リアルタイム再生に戻るまでに必要な時間が短縮される。なお、多くの場合、圧縮のレベルは、時間圧縮された全てのメッセージを理解可能な音声として再生できる範囲内で、最高のレベルに設定することが望ましい場合も多い。
【００５１】
例えば、優先度がより高いチャンネル上でメッセージが検出された場合等には、聞き手は、時間圧縮されたメッセージを聞いている間であっても、チャンネルを切り替えることができる。これによって、聞き手は、優先度がより高いチャンネルに切り替え、優先度がより低いチャンネル上の又は優先度がより低い話し手からのメッセージを蓄積し、必要であれば、後に、このメッセージを時間圧縮レートで再生することができる。便利な手法として、聞き手は、あるチャンネルを「優先度が低いおしゃべり（Low Priority Chatter）」チャンネルとして指定し、ユーザが評価を低めたメッセージの優先度を変更し、又はこのチャンネルに分類してもよい。
【００５２】
いずれの場合も、このような圧縮方式の１つ又は組合せを使用して、任意の望まれる量の圧縮を行ってもよい。
【００５３】
図１２は、本発明の第２の実施の形態に基づく例示的な方法の結果を示している。この図では、第１のメッセージ１５２は、時間軸２０上での位置を維持しているが、第２のメッセージ１５４は、時間的にシフトされ、シフトされたメッセージをメッセージ１５４’として示し、メッセージ１５４’は、第１のメッセージ１５２のストリーミングの末尾の直後にストリーミングを開始する。
【００５４】
図１３は、本発明の第２の実施の形態に基づく他の例示的な方法の結果を示している。ここでは、あるレベルの圧縮を採用し、メッセージ１５４をシフトさせ、これを圧縮する。シフトされ、圧縮されたメッセージを１５４”として示す。
【００５５】
図１３では、第１のメッセージ１５２は、長さＭ１を有し、圧縮比ｒ＝ｒ１＝１（unity）であり、第２のメッセージ１５４”は、長さＭ２を有し、圧縮比ｒ＝ｒ２＜１である。ここで、ｒは、圧縮されたメッセージを再生するために必要な時間を圧縮されていないメッセージを再生するために必要な時間で除算した比を表す。
【００５６】
一般化して言えば、聞き手Ｌが合計時間Ｔｃｏｍｐｒｅｓｓｅｄの間、メッセージを聞いた場合、本発明の実施の形態によって、聞き手は、以下の関係が成立する限り、Ｎ個のメッセージを聞くことができる。
【数１】
2010507353.tif 000003
【００５７】
圧縮のレベルが高くなると、より多くのメッセージを聞くことができるが、個々のメッセージの明瞭さが低下する。圧縮されていない場合、メッセージを聞くために必要な時間は、時間Ｔｕｎｃｏｍｐｒｅｓｓｅｄである。
【数２】
2010507353.tif 000004
【００５８】
これは、本発明の方法のこの実施の形態によって１単位時間あたりに得ることができる付加的なメッセージ、音声又はスピーチのパーセンテージに等しい。
【００５９】
この教示に基づいて、他の様々な具体例を定式化することができる。
【００６０】
更に、これまで、主に、多人数参加型ゲームの音声メッセージの基礎に作用するものとして本発明を説明したが、本発明は、これより広範囲に亘って適用できることは明らかである。幾つかの場合、このシステムは、オーバラップするメッセージが混乱を引き起こすことがあり、したがって、順序付けを行うことが望ましいビデオ会議システム及び他のシステムに適用できる。
【００６１】
以上に完全に説明したように、本発明によれば、例えば、多人数参加型ゲームのために、データの複数のストリームの送信及び再生を調整し、聞き手が他のストリームを聴いている間、バッファリングされ、オプションとして圧縮されるメッセージの順次的な再生を実現するシステムが提供される。この結果、システムは、ユーザ（「話し手」）が「互いに発話を重ならせる」問題を解決する。
【００６２】
例えば、ＭＭＯ等のゲームの文脈で本発明を説明したが、この教示から、本発明は、ここに示した実施の形態より遙かに広いことは、当業者にとって明らかである。具体的には、ここで説明したシステムは、ロールプレイングゲームに関連するが、非ロールプレイングゲーム又は実際に全く異なるアプリケーションも、本発明の利益を享受することができる。例えば、本発明は、テレビ会議及び他の状況において複数のオーバラップするメッセージを調整するために使用することができる。本発明は、ゲームサーバ上で実施してもよく、又は再生処理を含むある側面をクライアントマシンに委ねてもよい。本発明は、部分的に、発話の重なり（overtalk）又はクロストークを低減させることを意図するが、一実施の形態では、これらが生じることが許容されることもある。具体的には、「ミックスダウンされた」又は「部分的に調整された」チャンネルを用いて、様々な目的のために、許可された話し手からのメッセージを共に混合してもよい。更に、本発明は、新たなアプリケーションにおいて実施されるだけではなく、既にコード化されているアプリケーション又は旧型のアプリケーションに統合してもよい。本発明は、如何なるプログラミング言語によって実現してもよい。
【００６３】
したがって、本発明の範囲は、添付の特許請求の範囲によってのみ制限される。
【図１】
2010507353.tif 000005
【図２】
2010507353.tif 000006
【図３】
2010507353.tif 000007
【図４】
2010507353.tif 000008
【図５】
2010507353.tif 000009
【図６】
2010507353.tif 000010
【図７】
2010507353.tif 000011
【図８】
2010507353.tif 000012
【図９】
2010507353.tif 000013
【図１０】
2010507353.tif 000014
【図１１】
2010507353.tif 000015
【図１２】
2010507353.tif 000016
【図１３】
2010507353.tif 000017
【国際調査報告】
2010507353.tif 000018
2010507353.tif 000019