JP2024028555A - システム、通信方法及びプログラム - Google Patents

Abstract

【課題】拍手音等の音を発しようとする複数のユーザが互いの音を共有することを可能にする。【解決手段】第１端末と第２端末とがサーバを介してリアルタイムに通信可能であり、前記第１端末によって、第１音の発生を指示する第１イベントデータを前記サーバに送信し、前記第２端末によって、第２音の発生を指示する第２イベントデータを前記サーバに送信し、前記サーバによって、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータを前記第１端末に送信し、前記第１端末によって、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御することを含む通信方法である。【選択図】図１

Description

この発明は、互いに離れて所在する複数のユーザがサーバを介して情報交換を行うシステム、通信方法及びプログラムに関する。
この出願は、２０２０年１０月９日に出願された日本国特願２０２０－１７１１１６号を基礎とする優先権を主張し、その開示の全てをここに取り込む。

演劇や楽曲演奏の鑑賞、講演の視聴、スポーツ観戦、カラオケ等、複数のユーザが共通の対象を楽しむ場面において、拍手音等、ユーザが発する音は、場を盛り上げる有効な手段である。そこで、特許文献１は、拍手音をカラオケ曲とともに記録媒体に記録し、記録媒体からカラオケ曲とともに拍手音を再生する技術を開示している。

日本国特開平９－２６７９６号公報

しかしながら、特許文献１に記載の技術において、カラオケ曲とともに再生される拍手音は予め記録された固定的な音であり、場を盛り上げる手段としては、物足りない。共通の対象を楽しむ複数のユーザが、各ユーザがリアルタイムに発する拍手音の共有を望む可能性がある。しかし、演劇、楽曲演奏、講演、スポーツ等の対象に関しては、互いに離れて所在する複数のユーザが共通の対象を鑑賞して楽しむ場合がある。そのような場合、各ユーザは、互いに離れているので、互いの拍手音を共有することができない。

この発明は以上のような事情に鑑みてなされた。この発明の目的の一例は、拍手音等の音を発しようとする複数のユーザが互いの音を共有することを可能にする技術的手段を提供することである。

本発明の実施態様によるシステムは、第１端末と、第２端末と、サーバとを備えるシステムであって前記第１端末と前記第２端末とが前記サーバを介してリアルタイムに通信可能であり、前記第１端末は、第１音の発生を指示する第１イベントデータを前記サーバに送信に送信し、前記第２端末は、第２音の発生を指示する第２イベントデータを前記サーバに送信し、前記サーバは、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータを前記第１端末に送信し、前記第１端末は、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御する。
本発明の実施態様による通信方法は、第１端末と第２端末とがサーバを介してリアルタイムに通信可能であり、前記第１端末によって、第１音の発生を指示する第１イベントデータを前記サーバに送信し、前記第２端末によって、第２音の発生を指示する第２イベントデータを前記サーバに送信し、前記サーバによって、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータを前記第１端末に送信し、前記第１端末によって、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御することを含む。
本発明の実施態様によるプログラムは、第１端末と第２端末とがサーバを介してリアルタイムに通信可能なシステムにおける第１端末として機能するコンピュータに、第１音の発生を指示する第１イベントデータを前記サーバに送信し、前記第１イベントデータを含むデータと、前記第２端末から前記サーバに送信された、第２音の発生を指示する第２イベントデータとを含むデータを前記サーバから受信し、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御することを実行させる。

この発明の実施形態による通信システムの構成を示すブロック図である。 この発明の実施形態端末の構成を示すブロック図である。 図２に示す端末の表示画面を示す図である。 図２に示す端末において生成される第１イベントデータを示す図である。 この発明の実施形態によるサーバの構成を示す図である。 この発明の実施形態による第１端末および第２端末のイベント再生部の処理内容を示すフローチャートである。 この発明の実施形態による動作例を示すタイムチャートである。 この発明の実施形態による動作例を示すタイムチャートである。 この発明の実施形態による動作例を示す図である。

以下、図面を参照し、この発明の実施形態について説明する。

図１はこの発明の実施形態である通信システム１の構成を示すブロック図である。図１に示すように、通信システム１は、インターネット等のネットワーク３０に接続された第１端末１０＿１および第２端末１０＿２と、サーバ２０とを含む。

この通信システム１において、サーバ２０は、第１端末１０＿１および第２端末１０＿２に対し、演劇、楽曲演奏、講演等の各種の生放送番組の動画データ（音データを含む）を送信する。

第１端末１０＿１は、サーバ２０からのデータを受信して生放送番組を再生する。第１端末１０＿１は、この再生中に、ユーザからの操作に応じて、拍手音の発音を指示する第１イベントデータＥＶ＿１を生成し、サーバ２０に送信する。同様に、第２端末１０＿２は、サーバ２０からのデータを受信して生放送番組を再生する。第２端末１０＿２は、この再生中に、ユーザからの操作に応じて、拍手音の発音を指示する第２イベントデータＥＶ＿２を生成し、サーバ２０に送信する。

サーバ２０は、第１端末１０＿１から受信される第１イベントデータＥＶ＿１と、第２端末１０＿２から受信される第２イベントデータＥＶ＿２とを含む第３イベントデータＥＶ＿３を生成し、この第３イベントデータＥＶ＿３を第１端末１０＿１および第２端末１０＿２に送信する。

第１端末１０＿１および第２端末１０＿２の各々は、サーバ２０から受信される第３イベントデータＥＶ＿３に従って拍手音を発音する。このように通信システム１では、第１端末１０＿１のユーザおよび第２端末１０＿２のユーザは、共通の生放送番組を視聴しつつ、各々が発音を指示した拍手音を共有することができる。

以上が本実施形態による通信システム１の概略である。なお、図１では、図面が煩雑になるのを防止するために２台の端末１０＿１および１０＿２のみを示したが、サーバ２０から生放送番組の提供を受け、拍手音の発音を指示するイベントデータをサーバ２０に送信する端末は３台以上であってもよい。

図２は本実施形態における第１端末１０＿１の構成例を示すブロック図である。なお、図示は省略したが、第２端末１０＿２も、第１端末１０＿１と同様な構成を有する。第１端末１０＿１は、パーソナルコンピュータ、スマートフォン等の通信機能を備えたコンピュータである。図２に示すように、第１端末１０＿１は、プロセッサ１００と、操作部１１０と、表示部１２０と、音入力部１３０と、音出力部１４０と、記憶部１５０と、通信部１６０とを有する。

プロセッサ１００は、第１端末１０＿１の各部を制御する制御中枢である。操作部１１０は、プロセッサ１００に対して各種の指示を行うための操作を受け付ける手段であり、キーボード、マウス等の各種の操作子からなる。表示部１２０は、各種の情報を表示する手段であり、例えば液晶表示パネルからなる。第１端末１０＿１がスマートフォン等の端末である場合、操作部１１０および表示部１２０は、各々の機能を併有するタッチパネルであってもよい。音入力部１３０は、外界から音を収音してプロセッサ１００に与える手段であり、マイクロホン１３０－１により構成されている。音出力部１４０は、プロセッサ１００から与えられる電気信号を音として外界に出力する手段であり、スピーカ１４０－１により構成されている。記憶部１５０は、ＲＡＭ等の揮発性記憶部と、ＲＯＭ、ハードディスク等の不揮発性記憶部とを有する。揮発性記憶部は、プロセッサ１００によりワークエリアとして使用される。不揮発性記憶部には、プロセッサ１００により実行される各種のプログラムやプロセッサにより使用される各種の制御データが記憶される。通信部１６０は、プロセッサ１００とネットワーク３０に接続された他の装置との通信を制御する手段である。

本実施形態において、第１端末１０＿１は、サーバ２０にアクセスして生放送番組の動画データの受信を開始する場合に、動画データの受信を開始する前に、番組再生プログラム１５１をサーバ２０からダウンロードし、記憶部１５０の揮発性記憶部に格納する。プロセッサ１００は、この番組再生プログラム１５１を実行することにより番組再生部１０１、イベント生成部１０２およびイベント再生部１０３として機能する。

番組再生部１０１は、サーバ２０から通信部１６０を介して生放送番組の動画データを受信し、動画データに基づいて生放送番組を生成（再生）する。さらに詳述すると、番組再生部１０１は、受信した動画データが示す画像を表示部１２０に表示し、動画データが示す音を音出力部１４０により放音する。

イベント生成部１０２は、生放送番組の再生中、操作部１１０に対する操作に応じて、拍手音の発音を指示する第１イベントデータＥＶ＿１を生成する。本実施形態では、拍手音の発音指示等の各種の指示を受け付けるために、図３に示す画面が表示部１２０に表示される。

図３において、番組表示エリア１２１には、番組再生部１０１によって再生される生放送番組の画像が表示される。表示部１２０の表示画面において、番組表示エリア１２１の右側には、拍手ボタン１２２ａ、１２２ｂ、１２２ｃおよび１２２ｄと、第１ミュートボタン１２３ａおよび第２ミュートボタン１２３ｂが表示される。

拍手ボタン１２２ａ、１２２ｂ、１２２ｃおよび１２２ｄは、音波形あるいは発音態様が互いに異なった拍手音ａ、ｂ、ｃおよびｄが各々対応付けられている。例えば拍手音ａは、短い時間間隔で多数回鳴る拍手音であってもよい。拍手音ｂは長い時間間隔で小数回鳴る拍手音であってもよい。ユーザは、マウス等のポインティングデバイスによって拍手ボタン１２２ａ～１２２ｄのいずれかを指示（選択）することにより、所望の拍手音の発音指示をイベント生成部１０２に与えることができる。

図４はイベント生成部１０２によって生成される第１イベントデータＥＶ＿１を例示している。図４に示すように、１個の第１イベントデータＥＶ＿１は、発生時刻データＤ１と、音種類データＤ２と、端末識別データＤ３とを含むテキストデータである。第１イベントデータＥＶ＿１は、拍手音の音データは含まない。同様に、第２イベントデータＥＶ＿１および第３イベントデータＥＶ＿３も拍手音の音データは含まない。

発生時刻データＤ１は、発音指示の発生時刻、すなわち、拍手ボタン１２２ａ～１２２ｄのいずれかが選択された時刻を示すデータである。本実施形態において、発音指示の発生時刻は、サーバ２０によって提供される番組が進行する時間軸上における時刻、すなわち、番組内時刻（番組の開始時刻を基準とした現在の時刻、番組の経過時間を示す時刻）である。

このような番組内時刻を決定するための手段として、各種の態様の手段を用いてよい。ある好ましい態様において、サーバ２０は、番組の生放送の開始タイミングにおいて、番組開始を示す情報を第１端末１０＿１および第２端末１０＿２に送信する。第１端末１０＿１および第２端末１０＿２の各々は、この情報を受信することにより、各々の番組内時刻を初期化する。その後、第１端末１０＿１および第２端末１０＿２の各々は、時間経過に従って各々の番組内時刻を更新する。

他の好ましい態様において、サーバ２０は、生放送番組を放送（送信）する際に、生放送番組の動画データに番組内時刻を多重化して第１端末１０＿１および第２端末１０＿２に送信する。第１端末１０＿１および第２端末１０＿２の各々は、現在再生中の番組の動画データから番組内時刻のデータを取り出して第１イベントデータＥＶ＿１の生成に利用する。本実施形態では、この態様により番組内時刻を決定する。イベント生成部１０２は、拍手ボタン１２２ａ～１２２ｄのいずれかが選択されたとき、その時点における番組内時刻を示す発生時刻データＤ１を生成する。

音種類データＤ２は、発音が指示された拍手音の種類を示すデータである。拍手ボタン１２２ａが選択された場合、音種類データＤ２は拍手音ａを示すデータとなる。拍手ボタン１２２ｂが選択された場合、音種類データＤ２は拍手音ｂを示すデータとなる。拍手ボタン１２２ｃが選択された場合、音種類データＤ２は拍手音ｃを示すデータとなる。拍手ボタン１２２ｄが選択された場合、音種類データＤ２は拍手音ｄを示すデータとなる。

端末識別データＤ３は、発音の指示が発生した端末を識別するための情報である。第１イベントデータＥＶ＿１は、第１端末１０＿１に対する発音指示により生成されるので、その端末識別データＤ３は、第１端末１０＿１の識別情報であるＩＤ１となる。また、第２イベントデータＥＶ＿２は、第２端末１０＿２に対する発音指示により生成されるので、その端末識別データＤ３は、第２端末１０＿２の識別情報であるＩＤ２となる。

イベント生成部１０２により生成される第１イベントデータＥＶ＿１は、通信部１６０を介してサーバ２０に送信されるとともに、イベント再生部１０３に与えられる。

イベント再生部１０３は、イベント生成部１０２によって生成される第１イベントデータＥＶ＿１に従って拍手音を発音する第１の機能と、サーバ２０から通信部１６０を介して受信される第３イベントデータＥＶ＿３に従って拍手音を発音する第２の機能とを有している。これら２つの機能は、記憶部１５０の揮発性記憶部に設定される第１ミュートフラグＭＵＴＥ１および第２ミュートフラグＭＵＴＥ２の状態に基づいて制御される。

第１ミュートフラグ（キャンセルフラグ、中止フラグ）ＭＵＴＥ１は、イベント再生部１０３が第１イベントデータＥＶ＿１に基づく拍手音の発音をミュート（キャンセル、中止）するか（ＭＵＴＥ１＝ＯＮ）、ミュートしないか（ＭＵＴＥ１＝ＯＦＦ）を指示するフラグである。拍手ボタン１２２ａ～１２２ｄのいずれかが選択され、第１イベントデータＥＶ＿１が生成されたとき、第１ミュートフラグＭＵＴＥ１に応じて、第１イベントデータＥＶ＿１に基づく拍手音の発音をミュートするかしないかが決定される。

第２ミュートフラグ（キャンセルフラグ、中止フラグ）ＭＵＴＥ２は、第３イベントデータＥＶ＿３に基づく拍手音の発音をミュート（キャンセル、中止）するか（ＭＵＴＥ２＝ＯＮ）、ミュートしないか（ＭＵＴＥ２＝ＯＦＦ）を指示するフラグである。イベント生成部１０２によって生成された第１イベントデータＥＶ＿１がサーバ２０に送信され、第１イベントデータＥＶ＿１が第３イベントデータＥＶ＿３となってサーバ２０から受信された場合に、第２ミュートフラグＭＵＴＥ２に応じて、この第３イベントデータＥＶ＿３に基づく拍手音の発音をミュートするかしないかが決定される。

図３に示す表示部１２０の表示画面において、第１ミュートボタン１２３ａは、第１ミュートフラグＭＵＴＥ１がＯＮであるときに点灯し、ＯＦＦであるときに消灯する。また、第２ミュートボタン１２３ｂは、第２ミュートフラグＭＵＴＥ２がＯＮであるときに点灯し、ＯＦＦであるときに消灯する。ユーザは、ポインティングデバイスによって第１ミュートボタン１２３ａを選択することにより、第１ミュートフラグＭＵＴＥ１のＯＮ／ＯＦＦを切り換えることができる。また、ユーザは、ポインティングデバイスによって第２ミュートボタン１２３ｂを選択することにより、第２ミュートフラグＭＵＴＥ２のＯＮ／ＯＦＦを切り換えることができる。

イベント再生部１０３において、第１ミュートフラグＭＵＴＥ１と第１の機能との関係は次の通りである。第１ミュートフラグＭＵＴＥ１がＯＦＦである場合、イベント再生部１０３は、イベント生成部１０２から第１イベントデータＥＶ＿１を受け取った時点において、その第１イベントデータＥＶ＿１によって指定された拍手音の音信号を生成し、音出力部１４０から拍手音として発音させる。第１ミュートフラグＭＵＴＥ１がＯＮである場合、イベント再生部１０３は、イベント生成部１０２から第１イベントデータＥＶ＿１を受け取ったとしても、その第１イベントデータＥＶ＿１によって指示された拍手音の発音を行わせない。

イベント再生部１０３において、第２ミュートフラグＭＵＴＥ２と第２の機能との関係は次の通りである。第２ミュートフラグＭＵＴＥ２がＯＦＦである場合、イベント再生部１０３は、サーバ２０から第３イベントデータＥＶ＿３が受信されたとき、その第３イベントデータＥＶ＿３が第１イベント生成部１０２によって生成された第１イベントデータＥＶ＿１であるか否かに拘わらず、その第３イベントデータＥＶ＿３によって指定された拍手音を音出力部１４０に発音させる。

第２ミュートフラグＭＵＴＥ２がＯＮである場合、イベント再生部１０３は、サーバ２０から第３イベントデータＥＶ＿３が受信されたとき、その第３イベントデータＥＶ＿３の端末識別データＤ３が第１端末１０＿１の識別情報ＩＤ１を示しているか否か、すなわち、その第３イベントデータＥＶ＿３が第１端末１０＿１によって生成された第１イベントデータＥＶ＿１であるか否かを判定する。そして、イベント再生部１０３は、第３イベントデータＥＶ＿３が第１イベントデータＥＶ＿１に該当しない場合は、その第３イベントデータＥＶ＿３によって指定された拍手音の発音を行わせる。イベント再生部１０３は、第３イベントデータＥＶ＿３が第１イベントデータＥＶ＿１に該当する場合は、その第３イベントデータＥＶ＿３によって指定された拍手音の発音を行わせない。

次にイベント再生部１０３が第３イベントデータＥＶ＿３に基づいて拍手音の発音を行わせる処理のタイミング制御について説明する。イベント再生部１０３は、現在時刻（番組内時刻）と、第３イベントデータＥＶ＿３が示す発音指示の発生時刻とに基づいて、第３イベントデータＥＶ＿３に基づく拍手音の発音のタイミングを制御する。さらに詳述すると、次の通りである。

イベント再生部１０３は、サーバ２０から受信される第３イベントデータＥＶ＿３を記憶部１５０に蓄積し、蓄積した複数の第３イベントデータＥＶ＿３を発生時刻データＤ１が示す発生時刻順にソートして、リストを作成する。そして、イベント再生部１０３は、ソート済の複数の第３イベントデータＥＶ＿３のリストの中から各第３イベントデータＥＶ＿３を発生時刻順に取り出し、取り出した第３イベントデータＥＶ＿３に従って拍手音を発音させる。この第３イベントデータＥＶ＿３に基づく拍手音の発音のタイミングの制御については、説明の重複を避けるため、本実施形態の動作説明において、その詳細を明らかにする。

図５はサーバ２０の構成を示すブロック図である。サーバ２０は、第１端末１０＿１および第２端末１０＿２のものと同様なプロセッサ２００と、操作部２１０と、表示部２２０と、音入力部２３０と、音出力部２４０と、記憶部２５０と、通信部２６０とを有する。

記憶部２５０の不揮発性記憶部には番組放送プログラム２５１が記憶されている。プロセッサ２００は、この番組放送プログラム２５１を実行することにより、番組放送部２０１、イベント併合部２０２およびイベント再生部２０３として機能する。

番組放送部２０１は、生放送番組の放送の受信を要求する第１端末１０＿１および第２端末１０＿２に対し、上述した番組再生プログラム１５１を送信し、次いで生放送番組の動画データを送信する。

イベント併合部２０２は、番組の放送を受信する第１端末１０＿１および第２端末１０＿２から送られてくる第１イベントデータＥＶ＿１および第２イベントデータＥＶ＿２を併合し、第３イベントデータＥＶ＿３を生成する。

イベント再生部２０３は、第３イベントデータＥＶ＿３に基づく拍手音の発音を制御する手段である。

本実施形態では、操作部２１０の操作により、あるいはネットワーク３０に接続された端末からの指示により、拍手音再生モードをサーバ２０に設定し、あるいは設定された拍手音再生モードを解除することができる。拍手音再生モードとは、第１端末１０＿１および第２端末１０＿２から送信される第１イベントデータＥＶ＿１および第２イベントデータＥＶ＿２に従ってサーバ２０が拍手音を発音するモードである。

この拍手音再生モードがサーバ２０に設定された状態において、イベント再生部２０３は、第３イベントデータＥＶ＿３に従って音出力部２４０に拍手音を発音させる。さらに詳述すると、イベント再生部２０３は、第３イベントデータＥＶ＿３を記憶部２５０に蓄積し、蓄積した複数の第３イベントデータＥＶ＿３を発生時刻データＤ１が示す発生時刻順にソートする。そして、イベント再生部２０３は、ソート済の第３イベントデータＥＶ＿３の中から第３イベントデータＥＶ＿３を各々の発生時刻順に取り出し、取り出した第３イベントデータＥＶ＿３に従って拍手音を発音させる。さらに詳述すると、音入力部２３０は、複数のマイクロホン、具体的には、マイクロホン２３０－１とマイクロホン２３０－２とにより構成されている。音入力部２３０は、一つのマイクロホン、すなわち、マイクロホン２３０－１のみにより構成されていてもよい。音出力部２４０は、複数のスピーカ、具体的には、スピーカ２４０－１とスピーカ２４０－２とにより構成されている。音出力部２４０は、一つのスピーカ、すなわち、スピーカ２４０－１のみにより構成されていてもよい。第１の例として、一つマイクロホン（マイクロホン２３０－１）と一つのスピーカ（スピーカ２４０－１）とを利用する場合について説明する。この場合、スピーカ２４０－１は、各第３イベントデータＥＶ＿３の拍手音を発音する。マイクロホン２３０－１がスピーカ２４０－１により発音された拍手音を収音することにより、音入力部２３０が拍手音を含む音データを生成する。通信部２６０は、その音データを第１端末１０＿１および第２端末１０＿２に送信する。第１端末１０＿１および第２端末１０＿２は、音データに基づいて拍手音を再生する。ここで、スピーカ２４０－１により拍手音を発生させることにより、残響音が発生する。よって、音データは残響音を含む。したがって、第１端末１０＿１および第２端末１０＿２は、自然な拍手音を再生可能となる。次に、第２の例として、一つマイクロホン（マイクロホン２３０－１）と複数のスピーカ（スピーカ２４０－１および２４０－２）とを利用する場合について説明する。この場合、スピーカ２４０－１およびスピーカ２４０－１は、各第３イベントデータＥＶ＿３に従った拍手音を発音する。別例として、スピーカ２４０－１が端末識別データＤ３が識別情報ＩＤ１を示す第３イベントデータＥＶ＿３に従った拍手音のみを発音し、スピーカ２４０－２が端末識別データＤ３が識別情報ＩＤ２を示す第３イベントデータＥＶ＿３に従った拍手音のみを発音してもよい。マイクロホン２３０－１がスピーカ２４０－１により発音された拍手音およびスピーカ２４０－２により発音された拍手音を収音することにより、音入力部２３０が拍手音を含む音データを生成する。通信部２６０は、その音データを第１端末１０＿１および第２端末１０＿２に送信する。第１端末１０＿１および第２端末１０＿２は、音データに基づいて拍手音を再生する。ここで、スピーカ２４０－１および２４０－２により拍手音を発生させることにより、スピーカ２４０－１および２４０－２の位置の違いに対応した残響音が発生する。したがって、第１端末１０＿１および第２端末１０＿２は、そのような残響音を含む拍手音を再生可能となる。よって、ユーザは、より自然な拍手音を共有することができる。次に、第３の例として、複数のマイクロホン（マイクロホン２３０－１および２３０－２）と複数のスピーカ（スピーカ２４０－１および２４０－２）とを利用する場合について説明する。この場合、音入力部２３０は、マイクロホン２３０－１によって収音された音に基づく音データと、マイクロホン２３０－２によって収音された音に基づく音データとを生成する。通信部２６０は、第１端末１０＿１にマイクロホン２３０－１によって収音された音に基づく音データを送信する。また、通信部２６０は、第２端末１０＿２にマイクロホン２３０－２によって収音された音に基づく音データを送信する。よって、第１端末１０＿１および第２端末１０＿２は、マイクロホン２３０－１および２３０－２の位置の違いに対応してそれぞれ異なる拍手音を再生可能となる。第１～第３の例において、マイクロホン２３０－１および／または２３０－２と、スピーカ２４０－１および／または２４０－２とが、環境ノイズが入る場所に設置されていてもよい。この場合、音データには環境ノイズが含まれることになる。したがって、第１端末１０＿１および第２端末１０＿２は、拍手音とともに環境ノイズを再生可能となる。よって、ユーザは、より自然な拍手音を共有することができる。

次に本実施形態の動作例について説明する。図６は、第１端末１０＿１および第２端末１０＿２のイベント再生部１０３の処理内容を示すフローチャートである。イベント再生部１０３は、番組再生が行われる間、図６に示す処理を繰り返し実行する。上述したようにイベント再生部１０３は、ソート済の第３イベントデータＥＶ＿３を各々の発生時刻順に記憶部１５０から取り出して拍手音の発音の制御を行う。そして、イベント再生部１０３は、記憶部１５０内に残った最も発生時刻が早い第３イベントデータＥＶ＿３を取り出そうとする際、その第３イベントデータＥＶ＿３の発生時刻データＤ１が示す時刻が現在の番組内時刻に対して許容範囲ＴＡ内にあるか否かを判断する（ステップＳ１）。この判断結果が否定的である場合、イベント再生部１０３は、その第３イベントデータＥＶ＿３をリストから取り出して廃棄する（ステップＳ２）。すなわち、イベント再生部１０３は、その第３イベントデータＥＶ＿３に基づく拍手音の発音を行わせない。

一方、上記判断の結果が肯定的である場合、イベント再生部１０３は、取り出そうとしている第３イベントデータＥＶ＿３に先行し、拍手音の発音を行った第３イベントデータＥＶ＿３があるか否かを判断する（ステップＳ３）。先行する第３イベントデータＥＶ＿３がない場合、イベント再生部１０３は、直ちにその第３イベントデータＥＶ＿３をリストから取り出してその第３イベントデータＥＶ＿３に基づく拍手音の発音を行わせる（ステップＳ４）。

先行する第３イベントデータＥＶ＿３がある場合、イベント再生部１０３は、先行する第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発生時刻ｔ１と取り出そうとしている第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発生時刻ｔ２との差の時間ｔ２－ｔ１を求める。さらに、イベント再生部１０３は、先行する第３イベントデータＥＶ＿３に基づく拍手音の発生時刻ｔ１′から時間ｔ２－ｔ１だけ後の時刻ｔ２′を取り出そうとしている第３イベントデータＥＶ＿３に基づく拍手音の発生時刻に仮設定する（ステップＳ５）。

次にイベント再生部１０３は、取り出そうとしている第３イベントデータＥＶ＿３の発生時刻ｔ２が仮設定した発生時刻ｔ２′に対して許容範囲ＴＡ内にあるか否かを判断する（ステップＳ６）。すなわち、イベント再生部１０３は、取り出そうとしている第３イベントデータＥＶ＿３の発生時刻ｔ２と仮設定した発生時刻ｔ２′との時間差が許容範囲ＴＡ内にあるか否かを判断する。この判断結果が肯定的である場合、イベント再生部１０３は、番組内時刻が発生時刻ｔ２′になるまで待機し、発生時刻ｔ２′においてその第３イベントデータＥＶ＿３をリストから取り出し、その第３イベントデータＥＶ＿３に基づく拍手音の発音を行わせる（ステップＳ７）。

一方、取り出そうとしている第３イベントデータＥＶ＿３の発生時刻ｔ２が仮設定した発生時刻ｔ２′に対して許容範囲ＴＡ内にない場合、イベント再生部１０３は、発生時刻ｔ２が発生時刻ｔ２′に対して許容範囲ＴＡ内に収まるように発生時刻ｔ２′を早める（ステップＳ８）。そして、イベント再生部１０３は、番組内時刻がこの早めた発生時刻ｔ２′になるまで待機し、発生時刻ｔ２′においてその第３イベントデータＥＶ＿３をリストから取り出し、その第３イベントデータＥＶ＿３に基づく拍手音の発音を行わせる（ステップＳ９）。

図７および図８は本実施形態の動作例を示すタイムチャートである。この動作例において、サーバ２０から第１端末１０＿１までの伝送遅延時間は、サーバ２０から第２端末１０＿２までの伝送遅延時間よりも長い。このため、第１端末１０＿１では、第２端末１０＿２よりも遅れて、生放送番組の再生が開始される。なお、図６および図７では、本実施形態の動作の理解を容易にするため、サーバ２０と第１端末１０＿１および第２端末１０＿２の各々との伝送遅延が、第１イベントデータＥＶ＿１、第２イベントデータＥＶ＿２および第３イベントデータＥＶ＿３の各々が発生する時間間隔よりも誇張されて図示されている。

図７において、第２端末１０＿２では、番組再生開始後、発生時刻（番組内時刻）ｔ１において第２イベントデータＥＶ＿２が発生し、この第２イベントデータＥＶ＿２はサーバ２０を経由することにより第３イベントデータＥＶ＿３となって第１端末１０＿１に送信される。この第３イベントデータＥＶ＿３の発生時刻データＤ１は発生時刻ｔ１を示している。

第１端末１０＿１では、この第３イベントデータＥＶ＿３が発生時刻（番組内時刻）ｔ１を過ぎた時刻において記憶部１５０に蓄積される。この動作例では、この第３イベントデータＥＶ＿３に先行する第３イベントデータＥＶ＿３がない。また、この第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発生時刻ｔ１が、現在の発生時刻（番組内時刻）ｔ１′に対して許容範囲ＴＡ内にある。このため、イベント再生部１０３は、第３イベントデータＥＶ＿３の記憶部１５０への蓄積直後の発生時刻（番組内時刻）ｔ１′において、この第３イベントデータＥＶ＿３を記憶部１５０から取り出し、第３イベントデータＥＶ＿３に基づく拍手音の発音を行わせる。

その後、第２端末１０＿２では、発生時刻（番組内時刻）ｔ２において第２イベントデータＥＶ＿２が発生し、この第２イベントデータＥＶ＿２はサーバ２０を経由することにより第３イベントデータＥＶ＿３となって第１端末１０＿１に送信される。この第３イベントデータＥＶ＿３の発生時刻データＤ１は発生時刻ｔ２を示している。

第１端末１０＿１では、この第３イベントデータＥＶ＿３が発生時刻（番組内時刻）ｔ２を過ぎた時刻において記憶部１５０に蓄積される。ここで、この第３イベントデータＥＶ＿３に先行する第３イベントデータＥＶ＿３に基づく拍手音の発音が時刻ｔ１′において行われている。そして、時刻ｔ１′から時間ｔ２－ｔ１だけ後の時刻ｔ２′が発生時刻として仮設定される。この動作例では、第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発生時刻ｔ２は、仮設定された発生時刻ｔ２′に対して許容範囲ＴＡ内にある。そこで、イベント再生部１０３は、発生時刻ｔ２’において、この第３イベントデータＥＶ＿３を記憶部１５０から取り出し、第３イベントデータＥＶ＿３に基づく拍手音の発音を行わせる。

図８において、第１端末１０＿１では、発生時刻（番組内時刻）ｔ３において第１イベントデータＥＶ＿１が発生し、この第１イベントデータＥＶ＿１はサーバ２０を経由することにより第３イベントデータＥＶ＿３となって第２端末１０＿２に送信される。この第３イベントデータＥＶ＿３の発生時刻データＤ１は発生時刻（番組内時刻）ｔ３を示している。また、第１端末１０＿１では、発生時刻（番組内時刻）ｔ３の後の、発生時刻（番組内時刻）ｔ４において第１イベントデータＥＶ＿１が発生し、この第１イベントデータＥＶ＿１も第３イベントデータＥＶ＿３となって第２端末１０＿２に送信される。この第３イベントデータＥＶ＿３の発生時刻データＤ１は発生時刻ｔ４を示している。

第２端末１０＿２では、第３イベントデータＥＶ＿３が発生時刻（番組内時刻）ｔ３を過ぎた時刻において記憶部１５０に蓄積される。この第３イベントデータＥＶ＿３に対する処理は、図７の例において、第１端末１０＿１のイベント再生部１０３が時刻ｔ１を過ぎた時刻に受信した第３イベントデータＥＶ＿３に対して行った処理と同様である。

この動作例では、第２端末１０＿２の番組再生開始時刻は、第１端末１０＿１の番組再生開始時刻よりも早い。このため、第２端末１０＿２により受信される第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発生時刻と、第２端末１０＿２によりその第３イベントデータＥＶ＿３が受信される番組内時刻との時間差は、第１端末１０＿１により受信される第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発生時刻と、第１端末１０＿１によりその第３イベントデータＥＶ＿３が受信される番組内時刻との時間差よりも大きくなる。このため、第２端末１０＿２では、第３イベントデータＥＶ＿３に基づく拍手音の発生時刻の仮設定を行った場合に、第１端末１０＿１の場合よりも、発生時刻の修正が必要になる可能性が高くなる。

図８において、発生時刻ｔ４を示す発生時刻データＤ１を含む第３イベントデータＥＶ＿３を第２端末１０＿２が受信したとき、先行する第３イベントデータＥＶ＿３に基づく拍手音の発生時刻ｔ３′から時間ｔ４－ｔ３だけ後の時刻ｔ４′が、その第３イベントデータＥＶ＿３（発生時刻ｔ４）に基づく拍手音の発生時刻として仮設定される。しかし、この動作例において、その第３イベントデータＥＶ＿３が示す発生時刻ｔ４は、この仮設定された発生時刻ｔ４′に対して許容範囲ＴＡ内にない。そこで、この動作例において、イベント再生部１０３は、発生時刻ｔ４′を通常よりも早めた時刻、すなわち、その第３イベントデータＥＶ＿３が示す発生時刻ｔ４から許容範囲（許容時間）ＴＡだけ後の時刻に修正する。この場合、「ｔ４′－ｔ３′＜ｔ４－ｔ３」を満たす発生時刻ｔ４′において、第３イベントデータＥＶ＿３に基づく拍手音の発音が行われる。

このように本実施形態において、第２端末１０＿２では、第１端末１０＿１が発した発音指示にほぼ同期してその発音指示に基づく拍手音の発音が行われる。また、第１端末１０＿１では、第２端末１０＿２が発した発音指示にほぼ同期してその発音指示に基づく拍手音の発音が行われる。従って、第１端末１０＿１および第２端末１０＿２のユーザは各々が発音を指示した拍手音を共有することができる。

図示は省略したが、図７および図８において、第１端末１０＿１が送信した第１イベントデータＥＶ＿１は、サーバ２０を経由することにより、第３イベントデータＥＶ＿３となって第１端末１０＿１に送信される。また、第２端末１０＿２が送信した第２イベントデータＥＶ＿２は、サーバ２０を経由することにより、第３イベントデータＥＶ＿３となって第２端末１０＿２に送信される。このようにして第１端末１０＿１および第２端末１０＿２に受信される第３イベントデータＥＶ＿３に対する処理は、第２ミュートフラグＭＵＴＥ２のＯＮ／ＯＦＦ状態により異なる。

第２ミュートフラグＭＵＴＥ２がＯＦＦである場合、第１端末１０＿１のイベント再生部１０３は、第３イベントデータＥＶ＿３に含まれる端末識別データＤ３が第１端末１０＿１の識別情報ＩＤ１を示すか否かに拘わらず、全ての第３イベントデータＥＶ＿３に基づいて拍手音の発音を行わせる。第２端末１０＿２も同様である。

第２ミュートフラグＭＵＴＥ２がＯＮである場合、第１端末１０＿１のイベント再生部１０３は、第３イベントデータＥＶ＿３に含まれる端末識別データＤ３が第１端末１０＿１の識別情報ＩＤ１を示すか否かを判定する。第１端末１０＿１のイベント再生部１０３は、端末識別データＤ３が識別情報ＩＤ１を示す第３イベントデータＥＶ＿３については拍手音の発音を行わせず、端末識別データＤ３が識別情報ＩＤ１を示さない第３イベントデータＥＶ＿３についてのみ拍手音の発音を行わせる。

図９はこの場合の第１端末１０＿１の動作例を示す図である。図９には第１端末１０＿１により受信された第３イベントデータＥＶ＿３のリストが示されている。第２ミュートフラグＭＵＴＥ２がＯＮである場合には、図９に示すように、端末識別データＤ３が識別情報ＩＤ１を示す第３イベントデータＥＶ＿３が、拍手音の発音の対象から除外される。図９の例において、「Ｘ」は、除外を意味する。

次のような比較例を想定すると、この態様の効果が分かり易い。比較例において、サーバは、複数の端末から拍手音の発音指示を受け、これら複数の拍手音をミキシングして複数の端末に送信する。この比較例においても、複数の端末のユーザは、各端末からの発音指示に従って発音される拍手音を共有することができる。しかしながら、比較例において、複数の端末の各々は、ユーザからの発音指示に応じて拍手音の発音を行った場合に、拍手音を２度、すなわち、ユーザからの発音指示に応じこの拍手音と、サーバから送信される指示に応じた拍手音と発する。このような拍手音の発音はユーザに違和感を与える。

これに対し、本実施形態では、第１端末１０＿１において、第１ミュートフラグＭＵＴＥ１をＯＦＦ、第２ミュートフラグＭＵＴＥ２をＯＮにすると、第１端末１０＿１に対して発音指示が与えられた場合、この発音指示に基づく拍手音の発音は、この発音指示の時点において第１端末１０＿１において行われるのみであり、この発音指示に基づく第１イベントデータＥＶ＿１がサーバ２０を経由して第３イベントデータＥＶ＿３となって第１端末１０＿１に戻ってきたとしても、この第３イベントデータＥＶ＿３に基づく拍手音の発音は行われない。従って、本実施形態によれば、上記比較例において発生する拍手音が２回発音されるという事態を回避することができる。

以上説明したように、本実施形態によれば、第１端末１０＿１が、拍手音の発音を指示する第１イベントデータＥＶ＿１をサーバ２０に送信する。第２端末１０＿２が、拍手音の発音を指示する第２イベントデータＥＶ＿２をサーバ２０に送信する。サーバ２０が、第１イベントデータＥＶ＿１と第２イベントデータＥＶ＿２を含む第３イベントデータＥＶ＿３を第１端末１０＿１に送信する。第１端末１０＿１が、第３イベントデータＥＶ＿３に従って拍手音の発音を行う。このため、第１端末１０＿１のユーザは、第２端末１０＿２のユーザと拍手音を共有することができる。また、本実施形態では、サーバ２０から第１端末１０＿１に対し、データ量の少ない第３イベントデータＥＶ＿３を送るので、拍手音の音データを送る場合に比べて、サーバ２０から第１端末１０＿１へのデータの伝送遅延が短くなる。従って、第１端末１０＿１では、第２端末１０＿２における発音指示の発生時刻からの遅れが少ない適切なタイミングにおいて拍手音を発音させることができる。

また、上記実施形態において、サーバ２０は、第１端末１０＿１および第２端末１０＿２に番組を放送（送信）する。第１イベントデータＥＶ＿１、第２イベントデータＥＶ＿２および第３イベントデータＥＶ＿３は、番組が進行する時間軸における発音指示の発生時刻を示す発生時刻データＤ１を含む。第１端末１０＿１のイベント再生部１０３は、現在時刻と、第３イベントデータＥＶ＿３の発生時刻データＤ１が示す発音指示の発生時刻とに基づいて、第３イベントデータＥＶ＿３に基づく拍手音の発音のタイミングを制御する。従って、本実施形態によれば、第１端末１０＿１のイベント再生部１０３は、第２端末１０＿２における発音指示の発生にほぼ同期させて当該発音指示に基づく拍手音の発音を行わせることができる。

また、本実施形態において、第１端末１０＿１のイベント再生部１０３は、第３イベントデータＥＶ＿３のうち第１端末１０＿１から送信された第１イベントデータＥＶ＿１に対応したイベントデータに基づく発音の処理を第１端末１０＿１に対する操作に従って制御する。具体的には、第１端末１０＿１のイベント再生部１０３は、操作部１１０の操作により第２ミュートフラグＭＵＴＥ２がＯＮに設定された場合に、第３イベントデータＥＶ＿３のうち第１端末１０＿１から送信された第１イベントデータＥＶ＿１に対応したイベントデータについては発音の対象から除外する。従って、本実施形態によれば、第１端末１０＿１において、同じ発音指示に基づいて拍手音が２回に亙って発音される事態を回避することができる。

また、本実施形態において、サーバ２０のイベント再生部２０３は、拍手音再生モードが設定されている場合に、イベント併合部２０２によって生成される第３イベントデータＥＶ＿３に従って拍手音を発音させる。従って、サーバ２０のユーザは、第１端末１０＿１および第２端末１０＿２の各ユーザと拍手音を共有することができる。

以上、この発明の実施形態について説明したが、この発明の実施形態はこれらに限定されない。この発明の別の実施形態について説明する。

（１）ユーザにとって好ましくない拍手音が端末において発音されるのを回避する手段を端末に設けてもよい。例えばサーバ２０が講演の番組を各端末に放送する場合において、講演者が発話をしている期間等、多くのユーザが拍手音を発しないタイミングで拍手音を発するユーザがいた場合、そのユーザの拍手音を端末において発音させないようにする。それには、好ましくない拍手音を発するユーザの端末を特定する手段が必要になる。この手段に関しては次のような態様を採用してもよい。

＜態様１＞
イベント再生部１０３は、表示部１２０の表示画面に各端末に対応付けられたドットを表示する。イベント再生部１０３は、第３イベントデータＥＶ＿３に従って拍手音の発音を行わせる際に、その第３イベントデータＥＶ＿３の端末識別データＤ３により特定される端末に対応付けられたドットを点灯させる。ユーザが、好ましくないタイミングにおいて点灯するドットをポインティングデバイスにより指示する。以後、イベント再生部１０３は、指示されたドットに対応した端末の端末識別データＤ３を含む第３イベントデータＥＶ＿３を拍手音の発音対象から除外する。

＜態様２＞
イベント再生部１０３は、第３イベントデータＥＶ＿３に基づく拍手音の発音タイミングを一定期間解析する。多数の拍手音は、ほぼ同じ時刻に密集して発生する。他方で、それら多数の拍手音の発生時刻から離れた時刻において発生する少数派の拍手音（所定数未満の発音指示）があり得る。そのような少数派の拍手音の発音指示の発生元である端末を判定する。その端末の端末識別データＤ３を含む第３イベントデータＥＶ＿３を拍手音の発音対象から除外する。

（２）上記実施形態において、サーバ２０は生放送番組を第１端末１０＿１および第２端末１０＿２に提供する例を説明したが、このような実施形態に限定されない。番組を提供する態様として、録画された番組を端末からの要求に応じて提供する態様を採用してもよい。

この態様において、サーバ２０は、生放送番組を録画する際に、第１端末１０＿１から受信した第１イベントデータＥＶ＿１および第２端末１０＿２から受信した第２イベントデータＥＶ＿２を併合した第３イベントデータＥＶ＿３を保存する。そして、サーバ２０は、端末から録画再生の要求を受けた場合、その端末から受信される拍手音の発音指示のイベントデータと、保存した第３イベントデータＥＶ＿３とを併合して新たな第３イベントデータＥＶ＿３′を生成し、その端末に送信する。この態様によれば、録画再生の要求をしたユーザは、生放送番組を視聴したユーザと拍手音を共有することができる。

（３）上記実施形態において、複数のユーザは、拍手音を共有したが、共有の対象となる音は拍手音に限定されない。例えば複数のユーザが歌舞伎等の演劇を鑑賞する場合において、役者に対する掛け声を共有してもよい。

（４）第１端末１０＿１および第２端末１０＿２の各々において、拍手音ａ、ｂ、ｃおよびｄという音の種類毎に、音量バランス、定位、音色、時間長等、第３イベントデータＥＶ＿３に基づく発音処理の態様を操作部１１０の操作により制御してもよい。

（５）上記実施形態において第１端末１０＿１のイベント再生部１０３は、第３イベントデータＥＶ＿３のうち第１端末１０＿１から送信された第１イベントデータＥＶ＿１に対応したイベントデータを発音の対象から除外した。しかし、第１イベントデータＥＶ＿１に対応したイベントデータに基づく発音の制御の態様はこれに限定されない。例えば第１イベントデータＥＶ＿１に対応したイベントデータに基づいて発音する拍手音の音量を低下させるといった態様でもよい。

（６）サーバ２０は、第１端末１０＿１および第２端末１０＿２に対して、第３イベントデータＥＶ＿３として、拍手音の音データ（音信号）を含むデータを送信してもよい。この場合、第１端末１０＿１および第２端末１０＿２は、拍手音の音データに基づいて、拍手音を発生させる。

本発明は、通信方法に適用してもよい。

１０＿１……第１端末
１０＿２……第２端末
２０……サーバ
３０……ネットワーク
１００，２００……プロセッサ
１１０，２１０……操作部
１２０，２２０……表示部
１３０，２３０……音入力部
１４０，２４０……音出力部
１５０，２５０……記憶部
１６０，２６０……通信部
１５１……番組再生プログラム
１０１……番組再生部
１０２……イベント生成部
１０３，２０３……イベント再生部
２０１……番組放送部
２０２……イベント併合部
１２１……番組表示エリア
１２２ａ～１２２ｄ……拍手ボタン
１２３ａ……第１ミュートボタン
１２３ｂ……第２ミュートボタン

Claims (9)

1. 第１端末と、第２端末と、サーバとを備えるシステムであって、
   前記第１端末と前記第２端末とが前記サーバを介してリアルタイムに通信可能であり、
   前記第１端末は、第１音の発生を指示する第１イベントデータを前記サーバに送信に送信し、
   前記第２端末は、第２音の発生を指示する第２イベントデータを前記サーバに送信し、
   前記サーバは、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータを前記第１端末に送信し、
   前記第１端末は、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御する、
   システム。
2. 前記第１端末および前記第２端末は、共通の動画データを再生可能であり、
   前記第１端末は、前記動画データが再生されている際に、前記第１音および前記第２音の発生を制御する
   請求項１に記載のシステム。
3. 前記サーバは、前記第１端末および前記第２端末に対して番組を送信し、
   前記第１イベントデータは、前記第１音を発生させる時刻を示す情報として、前記番組の経過時間である第１の時刻を示す情報を含み、前記第２イベントデータは、前記第２音を発生させる時刻を示す情報として、前記番組の経過時間である第２の時刻を示す情報を含み、
   前記第１音および前記第２音の発生を制御することは、前記第１端末において再生されている前記番組の現在時刻と、前記第１の時刻および前記第２の時刻とに基づいて、前記第１音および前記第２音を発生させるタイミングを制御することを含む、
   請求項１または請求項２に記載のシステム。
4. 前記第１音および前記第２音の発生を制御することは、前記第１端末に対する操作に従って、前記第１音の発生を制御することを含む
   請求項１から請求項３のいずれか１項に記載のシステム。
5. 前記第１イベントデータを含むデータと前記第２イベントデータを含むデータを前記第１端末に送信することは、前記第１音の音声データと前記第２音の音声データとを前記サーバから前記第１端末に送信することを含み、
   前記第１音および前記第２音の発生を制御することは、
   前記第１音の音声データに基づいて前記第１音を発生させ、
   前記第２音の音声データに基づいて前記第２音を発生させる、ことを含む
   請求項１から請求項４のいずれか１項に記載のシステム。
6. 前記第１音および前記第２音の発生を制御することは、前記第１端末に対する操作に従って、前記第１音および前記第２音の発生の態様を制御することを含む
   請求項１から請求項５のいずれか１項に記載のシステム。
7. 前記第１イベントデータは、前記第１音の種類を示す情報を含み、前記第２イベントデータは、前記第２音の種類を示す情報を含み、
   前記第１音および前記第２音の発生を制御することは、
   前記第１音の種類に応じて前記第１音の発生の態様を制御することと、
   前記第２音の種類に応じて前記第２音の発生の態様を制御することと、を含む
   請求項１から請求項６のいずれか１項に記載のシステム。
8. 第１端末と第２端末とがサーバを介してリアルタイムに通信可能であり、
   前記第１端末によって、第１音の発生を指示する第１イベントデータを前記サーバに送信し、
   前記第２端末によって、第２音の発生を指示する第２イベントデータを前記サーバに送信し、
   前記サーバによって、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータを前記第１端末に送信し、
   前記第１端末によって、前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御する
   ことを含む通信方法。
9. 第１端末と第２端末とがサーバを介してリアルタイムに通信可能なシステムにおける第１端末として機能するコンピュータに、
   第１音の発生を指示する第１イベントデータを前記サーバに送信し、
   前記第１イベントデータを含むデータと、前記第２端末から前記サーバに送信された、第２音の発生を指示する第２イベントデータとを含むデータを前記サーバから受信し、
   前記第１イベントデータを含むデータと前記第２イベントデータを含むデータに基づいて、前記第１音および前記第２音の発生を制御する
   ことを実行させるプログラム。

Images