JP2022041553A - 通信制御方法 - Google Patents

Abstract

【課題】複数の通信拠点間の状況に応じて、通信方式を切り替えること【解決手段】一実施形態における通信制御方法は、第１通信方式により第１端末から送信される第１ストリーミングデータにおける第１特徴量と、第１通信方式により第２端末から送信される第２ストリーミングデータにおける第２特徴量との比較結果を取得し、比較結果に基づいて第１特徴量と第２特徴量とが第１関係を有する場合に、第１端末と第２端末との間において第１通信方式により送信される通信制御対象のストリーミングデータを、第１通信方式による送信から第１通信方式とは異なる第２通信方式による送信に切り替えるための第１切替信号を、第１端末および第２端末に送信することを含む。【選択図】図４

Description

本発明は、通信を制御する技術に関する。

楽器が演奏される複数の通信拠点がネットワークを介して接続されることにより、離れた場所においても合奏を可能とする技術が開発されている。ネットワーク接続により生じる通信遅延は、合奏を困難にする。したがって、通信遅延を小さくする環境を構築することが望ましいが、通信遅延を無くすことはできない。そのため、通信遅延が存在する前提において遅延の影響を少なくするための技術が、例えば特許文献１に開示されている。

特開２００５－１９５９８２号公報

複数の通信拠点間（複数の通信端末間）での通信をリアルタイムに行う方法は、例えばＰｅｅｒ ｔｏ Ｐｅｅｒ型通信（以下、Ｐ２Ｐ型通信という）およびクライアントサーバ型通信を含む。Ｐ２Ｐ型通信は、各通信拠点の通信端末が対等に接続する方式である。クライアントサーバ型通信は、各通信拠点の通信端末がサーバを介して接続する方式である。このような通信方式の違いにより、Ｐ２Ｐ型通信では、通信遅延を小さくすることができるが、通信端末の処理負荷および通信量が増加しやすい。一方、クライアントサーバ型通信では、通信端末の負荷および通信量の増加を抑えることができるが、通信遅延が大きくなる。このようなサーバは、例えば、ＳＦＵ（Ｓｅｌｅｃｔｉｖｅ Ｆｏｒｗａｒｄｉｎｇ Ｕｎｉｔ）およびＭＣＵ（Ｍｕｌｔｉｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）という機能を有する。

上述した合奏においては通信遅延を非常に小さくする必要がある。そのため、合奏を行うときの通信方法は、Ｐ２Ｐ型通信を用いることが望ましい。しかしながら、通信端末における処理負荷が大きくなると、その処理負荷のために結果的に遅延が大きくなってしまったり、通信端末における他の処理へ影響を及ぼしたりする可能性がある。一方、各通信拠点の状況によって、必ずしもＰ２Ｐ型通信を用いなくてもよいこともあり得る。

本発明の目的の一つは、複数の通信拠点間の状況に応じて、通信方式を切り替えることにある。

本発明の一実施形態によれば、第１通信方式により第１端末から送信される第１ストリーミングデータにおける第１特徴量と、前記第１通信方式により第２端末から送信される第２ストリーミングデータにおける第２特徴量との比較結果を取得し、前記比較結果に基づいて前記第１特徴量と前記第２特徴量とが第１関係を有する場合に、前記第１端末と前記第２端末との間において前記第１通信方式により送信される通信制御対象のストリーミングデータを、前記第１通信方式による送信から当該第１通信方式とは異なる第２通信方式による送信に切り替えるための第１切替信号を、前記第１端末および前記第２端末に送信する、通信制御方法が提供される。

本発明によれば、複数の通信拠点間の状況に応じて、通信方式を切り替えることができる。

本発明の一実施形態における通信システムの構成を説明する図である。 本発明の一実施形態における通信制御テーブルを説明する図である。 本発明の一実施形態における通信端末の通信切替方法を説明するフローチャートである。 本発明の一実施形態における管理サーバの通信制御方法を説明するフローチャートである。 本発明の一実施形態における合奏状態の検出方法を説明する図である。 本発明の一実施形態における合奏状態の検出方法を説明する図である。 本発明の一実施形態における通信モードの制御方法を説明する図である。 通信拠点間のデータの流れを説明する図である。 各データの同期方法を説明する図である。 動画データＤｖを同期しないときの各データの同期方法を説明する図である。 特定モードのときの各データの同期方法を説明する図である。

以下、本発明の一実施形態における通信システムについて、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定して解釈されるものではない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号（数字の後にＡ、Ｂ等を付しただけの符号）を付し、その繰り返しの説明は省略する場合がある。

［１．通信システムの構成］
図１は、本発明の一実施形態における通信システムの構成を説明する図である。通信システムは、インターネットなどのネットワークＮＷに接続された通信管理サーバ１を含む。通信管理サーバ１は、ネットワークＮＷに接続された複数の通信拠点間の通信を、各通信拠点の状況に応じて制御する。後述する通信管理サーバ１の機能は、複数のサーバによって協働して実現されてもよい。この例では、通信拠点間の通信は、２つの通信方式が用いられる。２つの通信方式は、Ｐ２Ｐ型通信およびクライアントサーバ型通信である。図１では、３つの通信拠点Ｔ１、Ｔ２、Ｔ３が例示されているが、この数に限られない。通信拠点Ｔ１、Ｔ２、Ｔ３を区別せず説明する場合には、単に通信拠点という。ＳＦＵサーバ８０は、クライアントサーバ型通信により用いられ、各通信拠点を仲介するサーバである。

各通信拠点には、通信端末２０が配置されている。通信端末２０には、電子楽器３０、収音装置４０、撮像装置５０、放音装置６０および表示装置７０が接続されている。各通信拠点において通信端末２０は必ず存在するが、電子楽器３０、収音装置４０、撮像装置５０、放音装置６０および表示装置７０の少なくとも一つが通信端末２０に接続されていなくてもよい。電子楽器３０、収音装置４０、撮像装置５０、放音装置６０および表示装置７０の少なくとも１つと通信端末２０とが一体の装置として構成されてもよい。

電子楽器３０は、演奏操作子、演奏操作子への操作に応じて音データＤａを出力する音源、およびこの操作に対応する発音制御データＤｃを出力するデータ出力部を含む。電子楽器３０は、この例では、演奏操作子として鍵を有する電子ピアノである。音データＤａおよび発音制御データＤｃは通信端末２０に出力される。音データＤａは、音波形信号を示すデータであり、放音装置６０に出力されてもよい。発音制御データＤｃは、例えばＭＩＤＩ規格等の所定の規格にしたがって音源を制御するためのデータである。この場合、発音制御データＤｃは、発音開始タイミングに関する情報（ノートオン）および発音終了タイミングに関する情報（ノートオフ）などの発音内容を規定する情報を含む。

音源は発音制御データＤｃの制御によっても音データＤａを出力することができる。電子楽器３０は、外部から入力された発音制御データＤｃに応じて演奏操作子を駆動するソレノイド等の駆動部を含んでもよい。他の通信拠点から発音制御データＤｃを受信したときには、このような音源または駆動部に発音制御データＤｃが供給されればよい。演奏操作子が駆動されることによって電子楽器３０において演奏が行われたことと同じ状況となるため、発音制御データＤｃに応じた音データＤａが生成される。

収音装置４０は、例えばマイクロフォンまたは音波形信号の入力端子を有し、マイクロフォンに入力された音または入力端子に入力された音波形信号を音データＤａとして通信端末２０に出力する。

撮像装置５０は、例えばカメラを有し、カメラによって撮像された画像に応じた動画データＤｖを通信端末２０に出力する。以下の説明において、画像とは静止画像および動画像の双方を含む。

放音装置６０は、例えばスピーカを有し、通信端末２０から供給された音データＤａが示す音をスピーカから出力する。放音装置６０に供給される音データＤａは、他の通信拠点から送信された音データＤａであるが、自身の通信拠点で生成された音データＤａが含まれてもよい。

表示装置７０は、例えば液晶ディスプレイを有し、通信端末２０から供給された動画データＤｖが示す画像を液晶ディスプレイに表示する。表示装置７０に供給される動画データＤｖは、他の通信拠点から送信された動画データＤｖであるが、自身の通信拠点で生成された動画データＤｖが含まれてもよい。

［２．通信端末の構成］
通信端末２０は、制御部２１、記憶部２３、通信部２５および操作部２７を含む。制御部２１は、ＣＰＵ、ＲＡＭおよびＲＯＭ等を含む。制御部２１は、記憶部２３に記憶されたプログラムをＣＰＵにより実行することによって、プログラムに規定された命令にしたがった処理を行う。この例では、通信を切り替える方法（通信切替方法）を実現する処理を行うためのプログラムが記憶部２３に記憶されている。通信切替方法は、通信管理サーバ１からの指示に基づいて、データの送信を行うための通信方式を切り替えるための処理を含む。

通信部２５は、通信モジュールを含み、ネットワークＮＷに接続して、通信管理サーバ１、他の通信拠点の通信端末２０およびＳＦＵサーバ８０などの外部装置と各種データの送受信を行う。通信部２５（通信端末２０）と通信管理サーバ１以外の外部装置との間で送信されるデータは、発音制御データＤｃ、音データＤａおよび動画データＤｖを含み、ストリーミングデータとして送信される。これらデータの送信を行うときの通信方式は、制御部２１の制御によって設定される。上述したように、通信方式は、この例では、Ｐ２Ｐ型通信およびクライアントサーバ型通信を含む。

操作部２７は、マウス、キーボード等の操作装置を含み、操作装置に対するユーザの操作を受け付け、その操作に応じた信号を制御部２１に出力する。

記憶部２３は、不揮発性メモリなどの記憶装置を含み、制御部２１によって実行されるプログラムを記憶する。その他にも通信端末２０において用いる様々なデータが記憶される。記憶部２３に記憶されるデータは、通信制御テーブルを含む。このプログラムは、コンピュータにより実行可能であればよく、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記憶された状態で通信端末２０に提供されてもよい。この場合には、通信端末２０は、記録媒体を読み取る装置を備えていればよい。また、このプログラムは、通信部２５を介してダウンロードすることによって提供されてもよい。

図２は、本発明の一実施形態における通信制御テーブルを説明する図である。通信制御テーブルは、複数の通信モードのそれぞれにおいて、発音制御データＤｃ、音データＤａおよび動画データＤｖの送信に用いられる通信方式を規定する。複数の通信モードは、モードＡ、Ｂ、Ｃ、Ｄを含む。通信方式は、クライアントサーバ型通信（ＳＦＵ）およびＰ２Ｐ型通信（Ｐ２Ｐ）を含む。

モードＡでは、全てのデータがクライアントサーバ型通信（ＳＦＵ）で送信される。モードＤでは、全てのデータがＰ２Ｐ型通信（Ｐ２Ｐ）で送信される。一方、モードＢでは、発音制御データＤｃがＰ２Ｐ型通信（Ｐ２Ｐ）で送信され、音データＤａおよび動画データＤｖがクライアントサーバ型通信（ＳＦＵ）で送信される。モードＣでは、発音制御データＤｃおよび音データＤａがＰ２Ｐ型通信（Ｐ２Ｐ）で送信され、動画データＤｖがクライアントサーバ型通信（ＳＦＵ）で送信される。

通信端末２０は、通信管理サーバ１から通信モードの設定が指示されると、制御部２１は、その通信モードに対応する各データの送信における通信方式を決定するために、この通信制御テーブルを参照する。このようにして、制御部２１は、指示された通信モードに対応する通信方式を通信部２５に設定する。通信管理サーバ１による通信モードの設定については、後述する。

［３．通信切替方法］
続いて、通信端末２０における通信切替方法について説明する。上述したように通信切替方法における各処理は、制御部２１によって実行される。以下に説明する通信切替方法の処理は、例えば、操作部２７に入力されたユーザの指示によって開始される。

図３は、本発明の一実施形態における通信端末の通信切替方法を説明するフローチャートである。通信端末２０は、通信管理サーバ１に接続する（ステップＳ１１０）。このとき、通信端末２０は、接続対象の通信拠点が参加するためのセッションルームを指定する。新たなセッションルームを通信管理サーバ１において開設することもできる。このセッションルームに参加する複数の通信拠点における通信端末２０が、互いにデータの送信を行う対象の端末である。

通信端末２０は、特徴量情報、通信負荷情報および処理負荷情報を通信管理サーバ１に送信することを開始する（ステップＳ１２０）。通信端末２０は、通信管理サーバ１に接続している期間において、特徴量情報、通信負荷情報および処理負荷情報を、所定時間毎（例えば１００ミリ秒毎）に通信管理サーバ１に送信する。

特徴量情報は、ストリーミングデータとして送信される発音制御データＤｃおよび音データＤａの特徴量を含む。特徴量は、この例では、送信される時刻において発音がされているか否かを示す情報である。そのため、音データＤａに関する特徴量情報は、その音データＤａから得られる音量レベルが所定値を超えている期間に発音がされ、それ以外の期間は発音がされていないことを示すことにより、音データＤａの発音期間を示す。発音制御データＤｃに関する特徴量情報は、その発音制御データＤｃが示すノートオンからノートオフまでの期間に発音がされ、それ以外の期間は発音されていないことを示すことにより、発音制御データＤｃの発音期間を示す。発音制御データＤｃに関する特徴量情報は、発音制御データＤｃを音源により音データＤａに変換してから、その音データＤａから得られる音量レベルが所定値を超えている場合に発音がされていることを示すようにしてもよい。

通信負荷情報は、通信端末２０がデータを送信するときに用いる通信回線の負荷を示す情報である。通信負荷は、例えば、通信端末２０と他の通信端末２０とのＰ２Ｐ型通信における往復遅延時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）の測定によって得られる。一般的に、クライアントサーバ型通信よりもＰ２Ｐ型通信の方が、送受信されるデータ量が増えるため、通信負荷が大きくなる。したがって、通信回線に余裕がない場合、Ｐ２Ｐ型通信でも低遅延を実現できなくなる。

処理負荷情報は、通信端末２０における処理負荷を示す情報である。処理負荷は、例えばＣＰＵの負荷に相当する。一般的に、クライアントサーバ型通信よりもＰ２Ｐ型通信の方が、送受信されるデータ量が増えるため、エンコードおよびデコード等により処理負荷が大きくなる。したがって、通信端末２０のデータ処理能力に余裕がない場合、Ｐ２Ｐ型通信でも低遅延を実現できなくなる。この処理負荷は、通信端末２０において並行して実行される他のプログラムに起因するものも含んでもよい。

通信端末２０は、通信管理サーバ１に接続すると、通信管理サーバ１から通信モードの設定指示を受信して、通信モードを設定する（ステップＳ１３０）。通信管理サーバ１によって指定される通信モードは、通信端末２０によって指定されたセッションルームに設定された通信モードである。新たにセッションルームが開設された場合など、このセッションルームに通信モードが設定されていない場合には、通信管理サーバ１によって通信モードＡの設定が指示される。既に開設されているセッションルームであれば、後述する通信制御方法によって別の通信モード（モードＢ、モードＣまたはモードＤ）が設定されている場合がある。

通信端末２０は、通信制御テーブルを参照して、設定された通信モードに応じて、各データの送信を行う。続いて、通信端末２０は、通信管理サーバ１から切替信号Ｓ（Ｘ）を受信するまで待機する（ステップＳ１４０；Ｎｏ）。ここで、Ｘは、Ａ、Ｂ、Ｃ、Ｄのいずれかを示す。Ａ、Ｂ、Ｃ、Ｄは、それぞれモードＡ、モードＢ、モードＣ、モードＤに対応している。切替信号Ｓ（Ｘ）を受信すると（ステップＳ１４０；Ｙｅｓ）、通信端末２０は、この切替信号Ｓ（Ｘ）に応じた通信モードＸを設定することによって、通信モードを切り替える（ステップＳ１５０）。そして、通信端末２０は、切替信号Ｓ（Ｘ）を受信するまで待機する（ステップＳ１４０；Ｎｏ）。

通信端末２０は、発音制御データＤｃ、音データＤａおよび動画データＤｖのそれぞれの送信に用いる通信方式を変更するように、通信管理サーバ１から制御される。

［４．通信管理サーバの構成］
通信管理サーバ１は、制御部１１、記憶部１３および通信部１５を含む。制御部１１は、ＣＰＵ、ＲＡＭおよびＲＯＭ等を含む。制御部１１は、記憶部１３に記憶されたプログラムをＣＰＵにより実行することによって、プログラムに規定された命令にしたがった処理を行う。このプログラムには、通信端末２０の通信を制御する方法（通信制御方法）を実現する処理を行うためのプログラムが含まれる。通信制御方法は、データの送信を行うための通信方式を切り替えることを通信端末２０に指示するための処理を含む。この処理の詳細については後述する。通信部１５は、通信モジュールを含み、ネットワークＮＷに接続して、各通信拠点の通信端末２０と各種データの送信を行う。

記憶部１３は、ハードディスクなどの記憶装置を含み、制御部１１によって実行されるプログラムを記憶する。その他にも通信管理サーバ１において用いる様々なデータが記憶される。このプログラムは、コンピュータにより実行可能であればよく、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記憶された状態で通信管理サーバ１に提供されてもよい。この場合には、通信管理サーバ１は、記録媒体を読み取る装置を備えていればよい。また、このプログラムは、通信部１５を介してダウンロードすることによって提供されてもよい。

［５．通信制御方法］
続いて、通信管理サーバ１における通信制御方法について説明する。上述したように通信制御方法における各処理は、制御部１１によって実行される。以下に説明する通信制御方法の処理は、例えば、セッションルームに複数の通信拠点が参加すると開始される。このとき、演奏モードは、モードＡとして設定される。そのため、各通信拠点間における発音制御データＤｃ、音データＤａおよび動画データＤｖの送信が、全てクライアントサーバ型通信として設定される。

図４は、本発明の一実施形態における管理サーバの通信制御方法を説明するフローチャートである。通信管理サーバ１は、複数の通信拠点における通信端末２０から受信する特徴量情報を比較して、合奏状態が検出されるまで待機する（ステップＳ２１０；Ｎｏ）。

合奏状態とは、複数の通信拠点において演奏が行われている状態をいう。各通信拠点における演奏は、例えば、電子楽器３０を用いた演奏であったり、アコースティック楽器を用いた演奏であったりする。電子楽器３０を用いた演奏の場合、発音制御データＤｃおよび音データＤａの少なくとも一方が通信端末２０に供給される。アコースティック楽器を用いた演奏の場合、アコースティック楽器の発音が収音装置４０に入力されて音データＤａが通信端末２０に供給される。

各通信拠点の通信端末２０から送信される特徴量情報は、上述したように、ストリーミングデータとして送信される発音制御データＤｃおよび音データＤａが各時刻において発音がされているか否かを示す情報を含む。したがって、この特徴量情報を時間軸に沿って比較することによって、複数の通信拠点において同時に発音がされているかどうかを検出することができる。ただし、特徴量情報により発音があったことが検出できたとしても、必ずしも演奏によらない発音の可能性もある。この例における合奏状態の検出方法は、演奏によらない発音をできるだけ除外する方法である。

図５および図６は、本発明の一実施形態における合奏状態の検出方法を説明する図である。これらの図は、通信拠点Ｔ１、Ｔ２、Ｔ３のそれぞれの通信端末２０から送信される特徴量情報に基づいて、各通信拠点における発音期間（図においてメッシュ部分）を時刻ｔに沿って示している。特徴量は、通信拠点Ｔ１では発音制御データＤｃの発音を示し、通信拠点Ｔ２、Ｔ３では音データＤａの発音を示している。図６は、図５の状況から少し時間が経過した後の状況に対応する。

合奏の検出方法の具体例について説明する。合奏検出の判定時点ＤＰ（現在時刻）の５秒前から判定時点ＤＰまでの期間を１秒間ずつ区切ることによって、５つの区間Ｗ１～Ｗ５が定義される。通信管理サーバ１は、各区間（判定期間）において複数の通信拠点での発音期間があったかどうかを判定する。

実際の合奏では発音期間が重複しない、すなわち、同時の発音がないこともある。したがって、複数の通信拠点での発音期間が重複していなくても１つの区間において発音期間が存在すれば、その区間は合奏音があった区間として判定される。ここでいう複数の通信拠点とは、セッションルームに参加する全ての通信拠点とは異なってもよく、すなわち、セッションルームに参加する通信拠点のうち、少なくとも２つの通信拠点のことを示す。通信管理サーバ１は、区間Ｗ１～Ｗ５において合奏音があったと判定した場合に、これらの通信拠点が参加するセッションルームが合奏状態になったことを検出する。

判定時点ＤＰから遡る時間（区間Ｗ１～Ｗ５の合計の時間）、区切られた区間の数、各区間の時間は一例であって、様々な値として設定されてもよい。区間Ｗ１～Ｗ５のそれぞれの長さが異なってもよい。この場合には、判定時点ＤＰから離れた区間ほど短くてもよいし、判定時点ＤＰに近い区間ほど短くてもよい。区間Ｗ１～Ｗ５は連続して並んでいなくてもよい。すなわち、隣接する区間の間が時間的に離れてもよい。

図５では、区間Ｗ１において通信拠点Ｔ１のみ発音があるため、区間Ｗ１には合奏音がないと判定される。一方、区間Ｗ２～Ｗ５には合奏音があると判定される。上述したように、通信拠点Ｔ１の発音期間と通信拠点Ｔ２の発音期間とが重複していない区間Ｗ２においても、合奏音があると判定される。この時点では、区間Ｗ１において合奏音がないと判定されているため、通信拠点Ｔ１～Ｔ３が参加するセッションルームが合奏状態になったことを検出していない。

図６では、区間Ｗ１～Ｗ５において合奏音があると判定される。したがって、通信管理サーバ１は、通信拠点Ｔ１～Ｔ３が参加するセッションルームが合奏状態になったことを検出する。合奏状態が検出されると、上記の条件を満たさなくなったとしても、後述する非合奏状態が検出されるまでは、セッションルームが合奏状態として維持される。

図４に戻って説明を続ける。合奏状態が検出されると（ステップＳ２１０；Ｙｅｓ）、通信管理サーバ１は、各通信拠点の通信端末２０に切替信号Ｓ（Ｄ）を送信する（ステップＳ２３０）。上述したように通信端末２０によって切替信号Ｓ（Ｄ）が受信されると、通信モードがモードＡからモードＤに切り替えられる。すなわち、各通信拠点間における発音制御データＤｃ、音データＤａおよび動画データＤｖの送信が、全てクライアントサーバ型通信からＰ２Ｐ型通信に切り替えられる。

通信管理サーバ１は、複数の通信拠点における通信端末２０から受信する特徴量情報を比較して、非合奏状態が検出されるまで、通信モード切替処理を行う（ステップＳ３１０；Ｎｏ、ステップＳ４００）。非合奏状態とは、全ての通信拠点において演奏が行われていない状態、または１つの通信拠点のみで演奏が行われている状態をいう。

非合奏状態の検出方法の具体例は、合奏状態の検出方法と反対である。すなわち、判定時点ＤＰに対応する区間Ｗ１～Ｗ５において、いずれも合奏音がないと判定された場合に、非合奏状態が検出される。

非合奏状態が検出されると（ステップＳ３１０；Ｙｅｓ）、通信管理サーバ１は、各通信拠点の通信端末２０に切替信号Ｓ（Ａ）を送信する（ステップＳ９００）。上述したように通信端末２０によって切替信号Ｓ（Ａ）が受信されると、通信モードがモードＡとして設定される。すなわち、各通信拠点間における発音制御データＤｃ、音データＤａおよび動画データＤｖの送信が、全てクライアントサーバ型通信として設定される。そして、通信管理サーバ１は、再び合奏状態が検出されるまで待機する（ステップＳ２１０；Ｎｏ）。

通信モード切替処理（ステップＳ４００）は、負荷値Ｌｄに応じて通信モードを切り替える処理である。負荷値Ｌｄは、各通信端末２０から送信される通信負荷情報および処理負荷情報に基づいて、通信管理サーバ１によって算出される負荷の大きさの指標である。この例では、複数の通信端末２０に対応する通信負荷および処理負荷をそれぞれ０％から１００％までの範囲とし、最も大きい値を負荷値Ｌｄとする。

図７は、本発明の一実施形態における通信モードの制御方法を説明する図である。図７は、通信モード切替処理において、通信モードが負荷値Ｌｄに応じて切り替わるときの条件を示している。

例えば、通信モードがモードＤであるときに、負荷値Ｌｄが閾値ＴＣ１より大きくなると、通信管理サーバ１は、通信モードをモードＣに切り替えるように各通信端末２０に切替信号Ｓ（Ｃ）を送信する。通信モードがモードＣであるときに、負荷値Ｌｄが閾値ＴＢ１より大きくなると、通信管理サーバ１は、通信モードをモードＢに切り替えるように各通信端末２０に切替信号Ｓ（Ｂ）を送信する。一方、通信モードがモードＣであるときに、負荷値Ｌｄが閾値ＴＣ２１より小さくなると、通信管理サーバ１は、通信モードをモードＤに切り替えるように各通信端末２０に切替信号Ｓ（Ｄ）を送信する。

ここで、ＴＣ１＞ＴＣ２である。このようにすることで、ＬｄがＴＣ１より大きくなって通信モードがモードＣに切り替わった直後にＬｄがＴＣ１より小さくなったとしてもすぐにモードＤには切り替わらないようになっている。他の閾値の関係も同様に、ＴＢ１＞ＴＢ２であり、ＴＡ１＞ＴＡ２である。モードＡの負荷はモードＢの負荷より少なく、モードＢの負荷はモードＣの負荷より少なく、モードＣの負荷はモードＤの負荷より少ない。したがって、ＴＡ１、ＴＢ１およびＴＣ１は、同じ閾値として設定されていてもよい。ＴＡ２＝ＴＢ２＝ＴＣ２は、同じ閾値として設定されていてもよい。

このように、通信モード切替処理（ステップＳ４００）では、通信管理サーバ１は、負荷値Ｌｄが大きくなると、通信モードを現在のモードより負荷が軽くなるモードに変更し、負荷値Ｌｄが小さくなると通信モードを現在のモードよりも通信遅延が少なくなるモードに変更する。上述した非合奏状態が検出されるまでは、この通信モード切替処理が継続される。

［６．データの送受信例］
続いて、上述のような通信制御方法および通信切替方法により、各通信拠点間における発音制御データＤｃ、音データＤａおよび動画データＤｖの送信に適用される通信方法について一例を説明する。

図８は、通信拠点間のデータの流れを説明する図である。各拠点において演奏が行われていない場合には、通信モードがモードＡとして設定された状態が維持される。この場合、発音制御データＤｃ、音データＤａおよび動画データＤｖの全てが、ＳＦＵサーバ８０を介して通信拠点間で送受信される（図８において破線で示す経路）。すなわち全てのデータに対して、クライアントサーバ型通信が適用される。この状況では、通信遅延は大きくても合奏を行っていないので特に問題は生じないため、通信負荷および処理負荷を少なくすることが優先される。

通信拠点Ｔ１において演奏が行われた場合を想定する。この状態では、通信モードはモードＡのままである。ここで、さらに通信モードＴ２において演奏が行われた場合、合奏状態が検出される。これにより、通信モードはモードＤに切り替えられる。したがって、発音制御データＤｃ、音データＤａおよび動画データＤｖの全てが、Ｐ２Ｐ型通信となり、通信拠点間で直接送受信される（図８において実線で示す経路）。

その後、負荷値Ｌｄが増加した場合には、通信モードがモードＣに切り替わる。これによって、発音制御データＤｃおよび音データＤａはＰ２Ｐ型通信による送信が維持されるもの、動画データＤｖのみＳＦＵサーバ８０を介した送信に切り替えられる。負荷値Ｌｄが変化すると、その変化に従って通信モードが切り替わり、それぞれのデータの通信方式が切り替わる。

通信遅延を小さくするデータとして、動画データＤｖの優先順位が最も低く、発音制御データＤｃの優先順位が最も高い。動画データＤｖが遅延しても音の遅延が小さければ合奏を行うことには大きな支障がない。そのため、通信モードがモードＤからモードＣに切り替えられた段階で、動画データＤｖの送信は、クライアントサーバ型通信に切り替えられる。発音制御データＤｃは、データ量が少ないためＰ２Ｐ型通信を維持しても、負荷を増加する要因にはなりにくい。そのため、モードＡ以外の通信モードでは、発音制御データＤｃの送信は、Ｐ２Ｐ型通信を用いる。

通信拠点Ｔ１、Ｔ２の少なくとも一方で演奏が中断されると、非合奏状態が検出される。これにより、通信モードはモードＡに切り替えられて、発音制御データＤｃ、音データＤａおよび動画データＤｖの全てが、Ｐ２Ｐ型通信となり、通信拠点間で直接送信される。

［７．各データ間の同期］
続いて、発音制御データＤｃ、音データＤａおよび動画データＤｖを受信した通信拠点において、放音装置６０から出力される音と表示装置７０で表示される映像とを同期する方法について説明する。ここでいう同期は、データ送信側におけるデータの各部の時間的な関係を、データ受信側においても維持することを示す。以下の説明は、データ送信側が通信拠点Ｔ１であり、データ受信側が通信拠点Ｔ２であることを想定する。

図９は、各データの同期方法を説明する図である。図９において、時刻ｔｐは通信拠点Ｔ１から各データの特定の部分が送信されたタイミングを示し、時刻ｔｅは通信拠点Ｔ２において受信したデータを同期して出力するタイミングを示す。

時間ｄｃは発音制御データＤｃの通信遅延に相当する時間である。そのため、通信拠点Ｔ２は、時刻ｔｐから時間ｄｃの経過後に発音制御データＤｃを受信する。時間ｄａは音データＤａの通信遅延に相当する時間である。そのため、通信拠点Ｔ２は、時刻ｔｐから時間ｄａの経過後に音データＤａを受信する。時間ｄｖは動画データＤｖの通信遅延に相当する時間である。そのため、通信拠点Ｔ２は、時刻ｔｐから時間ｄｖの経過後に動画データＤｖを受信する。

この例では、最も通信遅延が大きい動画データＤｖに同期させるため、時刻ｔｅは、動画データＤｖの受信時刻に対応する。そのため、通信拠点Ｔ２では、通信端末２０は、発音制御データＤｃを受信してから時間ｈｔｃ（＝時間ｄｖ－時間ｄｃ）の経過後に、その発音制御データＤｃを電子楽器３０に供給する。発音制御データＤｃは、時間ｈｔｃの経過までは、通信端末２０においてバッファされる。電子楽器３０は、音源によって発音制御データＤｃを音データＤａに変換して、放音装置６０に供給する。これによって、発音制御データＤｃに応じた音が放音装置６０から出力される。

通信拠点Ｔ２では、通信端末２０は、音データＤａを受信してから時間ｈｔａ（＝時間ｄｖ－時間ｄａ）の経過後に、その音データＤａを放音装置６０に供給する。音データＤａは、時間ｈｔａの経過までは、通信端末２０においてバッファされる。これによって、音データＤａに応じた音が放音装置６０から出力される。通信拠点Ｔ２では、通信端末２０は、動画データＤｖを受信すると、その動画データＤｖを表示装置７０に供給する。これによって、動画データＤｖに応じた画像が表示装置７０において表示される。このようにして、発音制御データＤｃに応じた音、音データＤａに応じた音および動画データＤｖに応じた画像が、同期される。

時間ｈｔｃおよび時間ｈｔａは、各通信拠点の関係（図９の例では通信拠点Ｔ１から通信拠点Ｔ２との関係）において、公知の技術によって予め取得されたものを用いてもよいし、それぞれのデータに送信時刻に対応するタイムスタンプが付与されることによって順次取得されるタイムスタンプの時間のずれから取得されてもよい。

これらとは別の方法で時間ｈｔｃおよび時間ｈｔａが取得されてもよい。例えば、通信拠点Ｔ１において、演奏者による特定の動作が撮像されるとともに、その特定の動作と同時に特定の音が録音される。これによって得られた音データＤａおよび動画データＤｖが通信拠点Ｔ２において受信され、その特定の動作と特定の音とのずれに基づいて時間ｈｔａが取得されてもよい。通信拠点Ｔ１において、電子楽器３０の演奏によって発音制御データＤｃと音データＤａとが得られる。この発音制御データＤｃと音データＤａとが通信拠点Ｔ２において受信され、発音制御データＤｃに含まれるノートオンと音データＤａの発音開始タイミングとのずれ（図１０に示す時間ｈｔｘに相当）と、時間ｈｔａとに基づいて時間ｈｔｃが取得されてもよい。

動画データＤｖが大きく遅延する場合、特に通信モードがモードＣである場合などにおいては、動画データＤｖを同期の対象外としてもよい。

図１０は、動画データＤｖを同期しないときの各データの同期方法を説明する図である。図９に示す例とは異なり、通信拠点Ｔ２は、時刻ｔｐに送信された動画データＤｖを時刻ｔｅよりも後に受信する。この例では、同期対象のデータのうち最も通信遅延が大きい音データＤａに同期させるため、時刻ｔｅは、音データＤａの受信時刻に対応する。そのため、通信拠点Ｔ２では、通信端末２０は、発音制御データＤｃを受信してから時間ｈｔｘ（＝時間ｄａ－時間ｄｃ）の経過後に、その発音制御データＤｃを電子楽器３０に供給する。電子楽器３０は、音源によって発音制御データＤｃを音データＤａに変換して、放音装置６０に供給する。これによって、発音制御データＤｃに応じた音が放音装置６０から出力される。

通信拠点Ｔ２では、通信端末２０は、音データＤａを受信すると、その音データＤａを放音装置６０に供給する。これによって、音データＤａに応じた音が放音装置６０から出力される。このようにして、発音制御データＤｃに応じた音および音データＤａに応じた音が、同期される。一方、動画データＤｖは、これらのデータに同期されない。

続いて、通信拠点Ｔ２における電子楽器３０が、発音制御データＤｃに基づいて演奏操作子を駆動する駆動部を有することを想定する。この場合、電子楽器３０に発音制御データＤｃが供給されてから、演奏操作子を駆動するまでの駆動時間を要する。その駆動時間を考慮して各データが同期されてもよい。このような同期においては、特定モードとして設定される。

図１１は、特定モードのときの各データの同期方法を説明する図である。図１１に示す時間ｄｍは、発音制御データＤｃが供給されてから演奏操作子を駆動するまでに必要な駆動時間に対応する。時間ｄｍは、電子楽器３０の駆動部の特性として予め設定されてもよいし、事前に測定されてもよい。

この例では、発音制御データＤｃにより電子楽器３０で音データＤａが出力されるまでの時間が最も大きい。したがって、時刻ｔｅは、発音制御データＤｃに応じて演奏操作子が駆動される電子楽器３０から音データＤａが出力されるタイミングに対応する。そのため、通信拠点Ｔ２では、通信端末２０は、音データＤａを受信してから時間ｈｔｙ（＝時間ｄｃ＋時間ｄｍ－時間ｄａ）の経過後に、その音データＤａを放音装置６０に供給する。これによって、音データＤａに応じた音が放音装置６０から出力される。

通信拠点Ｔ２では、通信端末２０は、動画データＤｖを受信してから時間ｈｔｖ（＝時間ｄｃ＋時間ｄｍ－時間ｄｖ）の経過後に、その動画データＤｖを表示装置７０に供給する。これによって、動画データＤｖに応じた画像が表示装置７０において表示される。このようにして、発音制御データＤｃに応じた音、音データＤａに応じた音および動画データＤｖに応じた画像が、同期される。

発音制御データＤｃにより電子楽器３０で音データＤａが出力されるまでの時間が最も大きい場合、すなわち時間ｄｍが大きい場合には、時間ｄａおよび時間ｄｖによっては、音データＤａおよび動画データＤｖの送信をＰ２Ｐ型通信で行わなくてもよい。例えば、音データＤａおよび動画データＤｖがクライアントサーバ型通信で通信拠点Ｔ１から送信されても、時刻ｔｅよりも前に通信拠点Ｔ２において受信される場合には、音データＤａおよび動画データＤｖの送信をＰ２Ｐ型通信で行う必要がない。したがって、この場合には、通信モードがモードＣ、ＤであってもモードＢとして設定されてもよい。

以上のとおり、一実施形態における通信システムでは、複数の通信拠点間の状況に応じて、通信方式を切り替えることができる。したがって、複数の通信拠点における演奏が合奏状態であるときに通信遅延を小さくする通信方式を適用し、非合奏状態であるときに通信負荷および処理負荷を小さくする通信方式を適用する、というように通信を制御することもできる。通信負荷または処理負荷が大きくなった場合には、データの種類毎に通信方式を制御することもできる。

＜変形例＞
以上、本発明の一実施形態について説明したが、本発明の一実施形態は、以下のように様々な形態に変形することもできる。また、上述した実施形態および以下に説明する変形例は、それぞれ互いに組み合わせて適用することもできる。

（１）通信管理サーバ１が、ＳＦＵサーバ８０の機能を有していてもよい。この場合には、通信管理サーバ１は、特徴量情報の代わりにクライアントサーバ型通信により送信されるデータを用いて、合奏状態を検出してもよい。

（２）通信管理サーバ１から通信端末２０に送信される切替信号は、演奏モードを切り替えるための信号であるが、切り替え後の演奏モードを指定する代わりに、各データの通信方式を指定する信号であってもよい。この場合、通信方式を変更する必要のあるデータを指定する形式であってもよい。このようにすると、通信端末２０は通信制御テーブルを有していなくてもよい。

（３）各通信拠点間を接続するＰ２Ｐ型通信が確立されるタイミングは、通信モードに応じてＰ２Ｐ型通信が必要になったタイミングであってもよいし、合奏状態の検出を開始する前のタイミングであってもよい。Ｐ２Ｐ型通信で送信するデータがないときには、Ｐ２Ｐ型通信の確立が解除されてもよい。

（４）通信方式を切り替えた場合に、通信端末２０は、切替後の通信方式でデータを受信するまでは、切替前の通信方式で受信してから通信端末２０でバッファしているデータを電子楽器３０、放音装置６０および表示装置７０に出力してもよい。

（５）実施形態では通信拠点Ｔ１と通信拠点Ｔ２とが合奏していることにより、セッションルームが合奏状態であると検出され、検出時の比較対象とはならなかった通信拠点Ｔ３については、設定される通信モードとは異なる処理が実行されてもよい。例えば、通信拠点Ｔ３から送信されるデータは、通信遅延を小さくする必要がないから、クライアントサーバ型通信が用いられるようにしてもよい。

（６）通信モードは、モードＡ、Ｄのみとしてもよい。この場合には、通信負荷および処理負荷に応じて通信モードを切り替える処理は不要である。

（７）動画データＤｖは全ての通信モードにおいてクライアントサーバ型通信により送信されるようにして、通信方式の制御対象のストリーミングデータから除外されてもよい。

（８）通信端末２０は、通信負荷および処理負荷が所定の値を超えた場合には、これらの負荷が低減するような処理を実行してもよい。通信端末２０は、例えば、動画サイズを小さくする処理、動画解像度を低くする処理、動画フレーム周波数を低くする処理、音のサンプリング周波数を低くする処理、圧縮率を増加する処理およびオーディオチャンネルを削減する処理（ステレオをモノラルにする処理）によって、負荷を低減すればよい。これらの処理は、調整範囲が予め定められている。このように負荷を低減する処理を行う場合には、調整範囲内での調整ができなくなるまで、上述した負荷値Ｌｄが増加しなくなる。

（９）合奏状態は、動画データＤｖを比較することにより検出されてもよい。この場合には、特徴量情報は、動画データＤｖに関する特徴量を含む。この特徴量は、例えば、動画データＤｖが示す画像を解析した結果として、楽器が画像に含まれているか否かを示す情報であってもよいし、動いている人が画像に含まれているか否かを示す情報であってもよい。合奏状態は、実施形態における発音期間に代えて、楽器が画像に含まれている期間または動いている人が画像に含まれている期間を用いることによって検出されればよい。このように、各通信拠点の状況に応じて通信拠点間の通信方式を制御するのであれば、各通信拠点の状況の検出には様々な方法が適用可能である。

この場合であっても、上記の変形例（７）のように動画データＤｖが通信方式の制御対象のストリーミングデータから除外されてもよい。このように、合奏状態の検出のように各通信拠点の状況を検出するためのストリーミングデータと、通信方法の制御対象となるストリーミングデータとは一致していなくてもよい。

合奏状態は、本変形例による画像に関する特徴量を比較することと、実施形態による音に関する特徴量を比較することとを併用することによって検出されるようにしてもよい。併用する場合には、いずれか一方の条件を満たした場合に合奏状態が検出されてもよいし、双方の条件を満たした場合に合奏状態が検出されてもよい。

（１０）電子楽器３０による演奏が行われた場合には、電子楽器３０から出力される発音制御データＤｃおよび音データＤａのうち、いずれか一方が通信端末２０から送信されるようにしてもよい。例えば、通信拠点Ｔ１において電子楽器３０による演奏が行われた場合、通信拠点Ｔ２、Ｔ３において、発音制御データＤｃを音データＤａに変換できる機能を有する場合（例えば電子楽器３０を備える場合）には、通信拠点Ｔ１の通信端末２０は、電子楽器３０で生成された音データＤａを送信しない。一方、通信拠点Ｔ２、Ｔ３において、発音制御データＤｃを音データＤａに変換できる機能を有しない場合には、通信拠点Ｔ１の通信端末２０は、電子楽器３０で生成された発音制御データＤｃを送信しない。発音制御データＤｃを音データＤａに変換できる機能を有しているか否かの情報は、各通信拠点から通信管理サーバ１に予め送信されていればよい。このようにすることで、不要なストリーミングデータが各通信拠点から送信されなくなる。

（１１）合奏状態は、複数の通信拠点における発音期間の関係に基づいて検出されていたが、発音期間ではなく音の相関に基づいて検出されてもよい。この場合には、複数の通信拠点における音が、区間Ｗ１～Ｗ５のそれぞれにおいて所定の相関関係を有するか否かを判定すればよい。特徴量は、相関関係を取得するために必要な情報であればよく、音に関連する情報であればよい。例えば、音に関連する情報としての特徴量が音の強弱に基づいて算出されたＢＰＭ（Ｂｅａｔｓ Ｐｅｒ Ｍｉｎｕｔｅ）であってもよい。この場合には、各通信拠点におけるＢＰＭが区間Ｗ１～Ｗ５において１０％以下の誤差となった場合に、合奏状態が検出されればよい。

同じ内容の演奏が複数の通信拠点で行われるような状況を想定した場合、複数の通信拠点から送信された音データＤａにおける音波形信号を比較して、音波形信号の一致度を相関関係として取得してもよい。したがって、音に関連する情報としての特徴量は音波形信号である。通信遅延を考慮して、双方の信号の時間的な相対位置を所定範囲で変更しながら音波形信号の一致の程度を算出し、最も一致の程度が大きいときの値が一致度として採用される。この一致度が所定値より大きい場合に、合奏状態が検出されればよい。

通信遅延を考慮する方法の別の例として、通信管理サーバ１は、各通信拠点から音データＤａを受信するときの通信遅延時間を取得して、これらの通信遅延時間に基づいて通信拠点からの音データＤａの時間的な位置を、通信拠点から送信されたタイミングに調整するようにしてもよい。このようにして、各通信拠点に対応する音データＤａの時間的な位置を調整することによって、通信管理サーバ１で受信した時刻を基準とした音データＤａから、通信拠点から送信された時刻を基準とした音データＤａに変換することができる。

このように変換された音データＤａを用いて、音波形信号を比較することで、音波形信号の一致度を算出してもよい。これにより、通信遅延時間の影響を小さくすることができる。取得される通信遅延時間の精度によっては、上記の方法を併用し、変換された音データＤａに基づく双方の信号に対して、時間的な位置を所定範囲で変更しながら音波形信号の一致の程度を算出するようにしてもよい。

その他にも、音に関連する情報としての特徴量として、例えば、音高、音量、音色、奏法、コードなどの音楽的分析要素が用いられてもよい。合奏状態は、同一種類の要素を比較して検出される場合に限らず、異なる種類の要素を比較して検出される場合もある。例えば、コードと音高とを比較して、コードの構成音と調和性の高い音高であることを合奏状態の検出の条件としてもよい。

例えば、和音など複数の音を同時に発音できる楽器（例えば、ピアノなどの鍵盤楽器、ギターなどの弦楽器）ではコードを特徴量として用いる。一方、単音での発音となる楽器（例えば、バイオリンなどの弦楽器、サックスおよびトランペットなどの管楽器）では特徴量として音高を用いる。コードと音高とを比較することによって、双方の楽器の合奏状態が検出されてもよい。楽器ではなく人声において、合奏状態の検出における比較対象として用いられてもよい。一人の声であれば、単音での発音となる楽器に相当し、複数人の声であれば、複数の音を同時に発音できる楽器に相当する。

音高を用いる場合には、例えば、時間経過に伴う音高の変化、すなわちフレーズを用いて、合奏状態が検出されてもよい。このとき、比較される２つのフレーズにおいて、同一となる音高の割合が所定割合以上であることを条件として、合奏状態が検出されてもよい。

（１２）各データが送信される通信方式は、Ｐ２Ｐ型通信とクライアントサーバ型通信とのいずれかから選択される場合に限られず、通信遅延が異なる通信方式の組み合わせであれば、様々な組み合わせから選択されてもよい。

（１３）合奏状態の検出は、通信管理サーバ１で行われる場合に限らず、いずれかの通信拠点の通信端末２０で行われてもよい。この場合には、通信端末２０は、他の通信拠点から送信されるデータの比較に基づいて合奏状態を検出する。通信端末２０は、比較の結果として、合奏状態を検出した場合に、通信管理サーバ１に対して合奏状態を検出したという結果を通信管理サーバ１に送信すればよい。

以上が変形例に関する説明である。

本発明の一実施形態によれば、第１通信方式により第１端末から送信される第１ストリーミングデータにおける第１特徴量と、前記第１通信方式により第２端末から送信される第２ストリーミングデータにおける第２特徴量との比較結果を取得し、前記比較結果に基づいて前記第１特徴量と前記第２特徴量とが第１関係を有する場合に、前記第１端末と前記第２端末との間において前記第１通信方式により送信される通信制御対象のストリーミングデータを、前記第１通信方式による送信から当該第１通信方式とは異なる第２通信方式による送信に切り替えるための第１切替信号を、前記第１端末および前記第２端末に送信する、通信制御方法が提供される。さらに以下のように構成することもできる。

前記通信制御方法において、前記第１特徴量と前記第２特徴量とは、発音期間を規定する情報を含み、前記第１関係は、前記第１特徴量に規定される第１発音期間と前記第２特徴量に規定される第２発音期間とが、所定数の判定期間のそれぞれにおいて存在することを含み、前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第２ストリーミングデータを含む。

前記通信制御方法において、前記第１特徴量と前記第２特徴量とは、音に関連する情報を含み、前記第１関係は、前記第１特徴量と前記第２特徴量とが所定の相関関係を有することを含み、前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第２ストリーミングデータを含む。

前記通信制御方法において、前記音に関連する情報は音波形信号であり、前記第１関係は、前記第１特徴量に対応する音波形信号と前記第２特徴量に対応する音波形信号との時間的な相対位置を所定範囲で変更しながら得られる音の一致の程度が所定値より大きいことを含む。

前記通信制御方法において、前記音に関連する情報は音波形信号であり、前記第１関係は、前記第１端末に対する通信遅延時間に基づいて時間的な位置が調整された前記第１特徴量に対応する音波形信号と、前記第２端末に対する通信遅延時間に基づいて時間的な位置が調整された前記第２特徴量に対応する音波形信号とから得られる一致の程度が所定値より大きいことを含む。

前記通信制御方法において、前記第２通信方式の通信遅延は、前記第１通信方式の通信遅延よりも小さい。

前記通信制御方法において、前記第１通信方式では、前記第１端末と前記第２端末とは、サーバを介して互いに通信し、前記第２通信方式では、前記第１端末と前記第２端末とは、Ｐ２Ｐにより互いに通信する。

前記通信制御方法において、前記第１端末から前記第２端末に、前記第１通信方式により音波形信号データを含む第３ストリーミングデータがさらに送信され、前記第１ストリーミングデータは、発音制御データを含み、前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータを含み、前記第１特徴量と前記第２特徴量とが第１関係を有する場合においても、前記第３ストリーミングデータは、前記第１通信方式により送信される。

前記通信制御方法において、前記第１端末から前記第２端末に、前記第１通信方式により音波形信号データを含む第３ストリーミングデータがさらに送信され、前記第１ストリーミングデータは、発音制御データを含み、前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第３ストリーミングデータを含み、前記第１端末または前記第１端末の通信負荷が所定の条件を満たすと、前記第３ストリーミングデータを前記第２通信方式による送信から前記第１通信方式による送信に切り替えるための第２切替信号を前記第１端末に送信する。

前記通信制御方法において、前記第１端末から前記第２端末に、前記第１通信方式により音波形信号データを含む第３ストリーミングデータがさらに送信され、前記第１ストリーミングデータは、発音制御データを含み、前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第３ストリーミングデータを含み、前記第１端末または前記第２端末の処理負荷が所定の条件を満たすと、前記第３ストリーミングデータを前記第２通信方式による送信から前記第１通信方式による送信に切り替えるための第２切替信号を前記第１端末に送信する。

前記通信制御方法において、前記比較結果に基づいて前記第１特徴量と前記第２特徴量とが第１関係を有した後において前記第１特徴量と前記第２特徴量とが第２関係を有する場合に、前記第２通信方式による通信確立を解除し、前記通信制御対象のストリーミングデータを前記第２通信方式による送信から前記第１通信方式による送信に切り替えるための第２切替信号を、前記第１端末および前記第２端末に送信する。

前記通信制御方法において、前記第１特徴量と前記第２特徴量とが第１関係を有する場合に、前記通信制御対象のストリーミングデータが前記第２通信方式により第３端末にさらに送信される。

１…通信管理サーバ、１１…制御部、１３…記憶部、１５…通信部、２０…通信端末、２１…制御部、２３…記憶部、２５…通信部、２７…操作部、３０…電子楽器、４０…収音装置、５０…撮像装置、６０…放音装置、７０…表示装置、８０…ＳＦＵサーバ

Claims (12)

1. 第１通信方式により第１端末から送信される第１ストリーミングデータにおける第１特徴量と、前記第１通信方式により第２端末から送信される第２ストリーミングデータにおける第２特徴量との比較結果を取得し、
   前記比較結果に基づいて前記第１特徴量と前記第２特徴量とが第１関係を有する場合に、前記第１端末と前記第２端末との間において前記第１通信方式により送信される通信制御対象のストリーミングデータを、前記第１通信方式による送信から当該第１通信方式とは異なる第２通信方式による送信に切り替えるための第１切替信号を、前記第１端末および前記第２端末に送信する、
   通信制御方法。
2. 前記第１特徴量と前記第２特徴量とは、発音期間を規定する情報を含み、
   前記第１関係は、前記第１特徴量に規定される第１発音期間と前記第２特徴量に規定される第２発音期間とが、所定数の判定期間のそれぞれにおいて存在することを含み、
   前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第２ストリーミングデータを含む、請求項１に記載の通信制御方法。
3. 前記第１特徴量と前記第２特徴量とは、音に関連する情報を含み、
   前記第１関係は、前記第１特徴量と前記第２特徴量とが所定の相関関係を有することを含み、
   前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第２ストリーミングデータを含む、請求項１に記載の通信制御方法。
4. 前記音に関連する情報は音波形信号であり、
   前記第１関係は、前記第１特徴量に対応する音波形信号と前記第２特徴量に対応する音波形信号との時間的な相対位置を所定範囲で変更しながら得られる音の一致の程度が、所定値より大きいことを含む、請求項３に記載の通信制御方法。
5. 前記音に関連する情報は音波形信号であり、
   前記第１関係は、前記第１端末からの通信遅延時間に基づいて時間的な位置が調整された前記第１特徴量に対応する音波形信号と、前記第２端末からの通信遅延時間に基づいて時間的な位置が調整された前記第２特徴量に対応する音波形信号と、から得られる一致の程度が、所定値より大きいことを含む、請求項３または請求項４に記載の通信制御方法。
6. 前記第２通信方式の通信遅延は、前記第１通信方式の通信遅延よりも小さい、請求項１から請求項５のいずれかに記載の通信制御方法。
7. 前記第１通信方式では、前記第１端末と前記第２端末とは、サーバを介して互いに通信し、
   前記第２通信方式では、前記第１端末と前記第２端末とは、Ｐ２Ｐにより互いに通信する、請求項１から請求項５のいずれかに記載の通信制御方法。
8. 前記第１端末から前記第２端末に、前記第１通信方式により音波形信号データを含む第３ストリーミングデータがさらに送信され、
   前記第１ストリーミングデータは、発音制御データを含み、
   前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータを含み、
   前記第１特徴量と前記第２特徴量とが第１関係を有する場合においても、前記第３ストリーミングデータは、前記第１通信方式により送信される、
   請求項１から請求項７のいずれかに記載の通信制御方法。
9. 前記第１端末から前記第２端末に、前記第１通信方式により音波形信号データを含む第３ストリーミングデータがさらに送信され、
   前記第１ストリーミングデータは、発音制御データを含み、
   前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第３ストリーミングデータを含み、
   前記第１端末または前記第１端末の通信負荷が所定の条件を満たすと、前記第３ストリーミングデータを前記第２通信方式による送信から前記第１通信方式による送信に切り替えるための第２切替信号を前記第１端末に送信する、
   請求項１から請求項７のいずれかに記載の通信制御方法。
10. 前記第１端末から前記第２端末に、前記第１通信方式により音波形信号データを含む第３ストリーミングデータがさらに送信され、
    前記第１ストリーミングデータは、発音制御データを含み、
    前記通信制御対象のストリーミングデータは、前記第１ストリーミングデータおよび前記第３ストリーミングデータを含み、
    前記第１端末または前記第２端末の処理負荷が所定の条件を満たすと、前記第３ストリーミングデータを前記第２通信方式による送信から前記第１通信方式による送信に切り替えるための第２切替信号を前記第１端末に送信する、
    請求項１から請求項７のいずれかに記載の通信制御方法。
11. 前記比較結果に基づいて前記第１特徴量と前記第２特徴量とが第１関係を有した後において前記第１特徴量と前記第２特徴量とが第２関係を有する場合に、前記第２通信方式による通信確立を解除し、前記通信制御対象のストリーミングデータを前記第２通信方式による送信から前記第１通信方式による送信に切り替えるための第２切替信号を、前記第１端末および前記第２端末に送信する、請求項１から請求項１０のいずれかに記載の通信制御方法。
12. 前記第１特徴量と前記第２特徴量とが第１関係を有する場合に、前記通信制御対象のストリーミングデータが前記第２通信方式により第３端末にさらに送信される、請求項１から請求項１１のいずれかに記載の通信制御方法。

Images