JP6311726B2 - データ伝送システム、端末装置、プログラムおよびデータ伝送方法 - Google Patents

Description

本発明は、データ伝送システム、端末装置、プログラムおよびデータ伝送方法に関する。

従来、通信ネットワークを介して接続された複数の拠点間で映像や音声を共有して会議を行うための遠隔会議システムが提供されているところ、従来のシステムには、通信ネットワークの通信状態の悪化による音質や画質の劣化が頻繁に発生するという問題があった。音質や画質の劣化は、会議の参加者に大きなストレスを与え、酷い場合は、会議を継続することができなくなる。

この点につき、特開２０１０―０９３５０５号公報（特許文献１）は、どのような場合でも会議の参加者が少なくとも互いの発言内容を把握することができるようにするために、通信ネットワークの通信状態が悪化したことに応答して、音声通信用の帯域幅の割合を画像通信用のそれよりも大きくすることによって音質の劣化を回避する通信システムを開示する。

しかしながら、音質や画質の劣化は、通信ネットワークの伝送遅延だけに依るものではなく、データ受信側の内部処理遅延（データを受信してから出力信号を生成するまでの処理時間）がその原因になっている場合も少なからずあり、特許文献１のように通信ネットワークの通信状態だけに着目したのでは、期待する効果を得られない場合がある。

本発明は、上記従来技術における課題に鑑みてなされたものであり、本発明は、出力品質の劣化原因の如何にかかわらず、優先順位の高いデータに係る出力をできる限り品質が高い状態で維持することを可能にする新規なデータ伝送システムを提供することを目的とする。

本発明者は、出力品質の劣化原因の如何にかかわらず、優先順位の高いデータに係る出力をできる限り品質が高い状態で維持することを可能にするデータ伝送システムの構成につき鋭意検討した結果、以下の構成に想到し、本発明に至ったのである。

すなわち、本発明は、コンテンツデータを送信または受信する複数の端末装置が通信ネットワーク上に配置されてなるデータ伝送システムであって、前記複数の端末装置のうち、他の端末装置から送信されたコンテンツデータを受信する少なくとも１つの端末装置は自身を宛先とする２以上のコンテンツデータの優先順位を管理する受信優先順位管理部と、受信中の２以上のコンテンツデータのうち、前記受信優先順位管理部によって管理される優先順位が高い優先データに対応する出力信号の出力時間間隔に基づいて、前記優先データよりも優先順位が低いコンテンツデータの送信を止めるように制御する旨を当該優先順位が低いコンテンツデータを送信する送信元に対して要求するデータ受信制御部と、を備えることを特徴とする。

上述したように、本発明によれば、出力品質の劣化原因の如何にかかわらず、優先順位の高いデータに係る出力をできる限り品質が高い状態で維持することができるという効果を奏する。

図１は、本実施形態の遠隔会議システムの通信ネットワーク構成図である。 図２は、本実施形態の端末装置の外観図である。 図３は、本実施形態の端末装置のハードウェア構成図である。 図４は、本実施形態の情報処理装置（中継装置、伝送管理装置）のハードウェア構成図である。 図５は、本実施形態の端末装置および中継装置の機能ブロック図である。 図６は、受信データ管理テーブルの生成手順を示すシーケンス図である。 図７は、本実施形態における中継データ管理テーブルを示す図である。 図８は、本実施形態における受信データ管理テーブルを示す図である。 図９は、本実施形態の伝送管理装置の機能ブロック図である。 図１０は、本実施形態における端末認証管理テーブルを示す図である。 図１１は、本実施形態における端末管理テーブルを示す図である。 図１２は、本実施形態における宛先リスト管理テーブルを示す図である。 図１３は、本実施形態で実施される相互認証処理を示すシーケンス図である。 図１４は、本実施形態における宛先リストを示す図である。 図１５は、本実施形態の端末装置および中継装置の機能ブロック図である。 図１６は、本実施形態の遠隔会議システムにおいて実施される処理を示すシーケンス図である。 図１７は、本実施形態における削減要求履歴管理テーブルを示す図である。 図１８は、本実施形態の遠隔会議システムにおけるデータ中継の状態を概念的に示す図である。 図１９は、本実施形態におけるデータ受信制御部が実行する処理を表すフローチャートである。 図２０は、本実施形態における受信データ管理テーブルを示す図である。 図２１は、本実施形態における中継データ管理テーブルを示す図である。 図２２は、本実施形態における受信データ管理テーブルを示す図である。

以下、本発明を、実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。なお、以下に参照する各図においては、共通する要素について同じ符号を用い、適宜、その説明を省略するものとする。

以下においては、本発明のデータ伝送システムを、その好適な適用例である“遠隔会議システム”に基づいて説明する。

図１は、本発明の実施形態である遠隔会議システム１の通信ネットワーク構成を示す。図１に示すように、本実施形態の遠隔会議システム１においては、４つの拠点（東京事業所、大阪事業所、ニューヨーク事業所、ワシントンＤＣ事業所）が通信ネットワークを介して接続されている。

本実施形態の遠隔会議システム１は、複数の端末装置１０（１０ａ，１０ｂ，１０ｃ，１０ｄ…）と、複数の中継装置３０（３０ａ，３０ｂ，３０ｃ，３０ｄ）と、伝送管理装置５０とを含んで構成されている。各端末装置１０は、設置された拠点の映像や音声を取得して他の拠点の端末装置１０に送信し、また、他の拠点の映像や音声をそこに設置された端末装置１０から受け取って出力する情報処理装置である。また、各中継装置３０は、複数の端末装置１０の間に介在してコンテンツデータの中継を行う情報処理装置である。一方、伝送管理装置５０は、システムの運行に必要な処理（端末装置のログイン認証や通信ネットワークの通信状態の監視など）や各種管理情報を一元的に管理する情報処理装置である。

ここで、東京事業所内に構築されたＬＡＮ２ａはルータ７０ａを含み、東京事業所に設置された端末装置１０ａは、ルータ７０ａを介してＬＡＮ２ａに接続されている。同様に、大阪事業所内に構築されたＬＡＮ２ｂはルータ７０ｂを含み、大阪事業所に設置された端末装置１０ｂは、ルータ７０ｂを介してＬＡＮ２ｂに接続されている。さらに、ＬＡＮ２ａおよびＬＡＮ２ｂは、ルータ７０ａｂを含む専用線２ａｂに接続されている。

一方、ニューヨーク事業所内に構築されたＬＡＮ２ｃはルータ７０ｃを含み、ニューヨーク事業所に設置された端末装置１０ｃは、ルータ７０ｃを介してＬＡＮ２ｃに接続されている。同様に、ワシントンＤＣ事業所内に構築されたＬＡＮ２ｄはルータ７０ｄを含み、ワシントンＤＣ事業所に設置された端末装置１０ｄは、ルータ７０ｄを介してＬＡＮ２ｄに接続されている。さらに、ＬＡＮ２ｃおよびＬＡＮ２ｄは、ルータ７０ｃｄを含む専用線２ｃｄに接続されている。

ここで、日本の専用線２ａｂと米国の専用線２ｃｄは、それぞれ、ルータ７０ａｂおよびルータ７０ｃｄを介してインターネット８０に接続され、伝送管理装置５０は、インターネット８０を介して、各端末装置１０および各中継装置３０と通信可能に接続されている。そして、上述した複数のルータ（７０ａ，７０ｂ，７０ｃ，７０ｄ，７０ａｂ，７０ｃｄ）によって、コンテンツデータ（画像データおよび音声データ）の最適な経路が選択される。なお、専用線は必ずしも専用である必要はなく共用であってもよい。また、専用線を介さずにインターネットに直接接続してよい。

本実施形態においては、各端末装置１０の間に伝送管理装置５０を介した管理情報用セッションＳ_ｉが確立され、各端末装置１０は、当該セッションＳ_ｉを使用して各種管理情報を相互に送受信する。

また、本実施形態においては、各端末装置１０の間に中継装置３０を介したデータ用セッションＳ_ｄが確立され、各端末装置１０は、当該セッションＳ_ｄを使用してコンテンツデータを相互に送受信する。ここで、各端末装置１０は、複数のコンテンツデータを同時に伝送することができるように構成されており、各データは個別に確立した固有のセッションＳ_ｄで伝送される。本実施形態においては、例えば、画像データ（動画・静止画）と音声データを同時に伝送するように構成してもよく、解像度の異なる複数の画像データ（高解像度・中解像度・低解像度）を同時に伝送するように構成してもよい。なお、コンテンツデータは、テキストデータを含んでいてもよい。

以上、本実施形態の遠隔会議システム１の通信ネットワーク構成について概説したが、続いて、遠隔会議システム１を構成する各装置について説明する。

最初に、本実施形態の端末装置１０の構成について説明する。図２は、本実施形態の端末装置１０の外観図である。なお、図２に示す外観はあくまで例示であることに留意されたい。図２に示すように、端末装置１０は、筐体１１００、アーム１２００およびカメラハウジング１３００を備えている。筐体１１００の前側壁面１１１０には、複数の吸気孔によって形成された吸気面（不図示）が設けられており、筐体１１００の後側壁面１１２０には、複数の排気孔が形成された排気面１１２１が設けられている。これにより、筐体１１００に内蔵された冷却ファンの駆動によって、吸気面（不図示）を介して端末装置１０の後方の外気を取り込み、排気面１１２１を介して端末装置１０の後方へ排気することができる。筐体１１００の右側壁面１１３０には、音声を収音するための収音用孔１１３１が形成されており、この収音用孔１１３１を介して内蔵型のマイク（後述する）が会議の音声を収音する。

筐体１１００の右側壁面１１３０側には、操作パネル１１５０が形成されており、操作パネル１１５０には、後述の複数の操作ボタン（１０８ａ〜１０８ｅ）、後述の電源スイッチ１０９およびアラームランプ１１９が設けられている。さらに、操作パネル１１５０には、後述の内蔵型のスピーカー１１５からの出力音を通すための複数の音声出力孔によって形成された音出面１１５１が形成されている。また、筐体１１００の左側壁面１１４０側には、アーム１２００およびカメラハウジング１３００を収容するための凹部としての収容部１１６０が形成されている。筐体１１００の右側壁面１１３０には、後述の外部機器接続Ｉ／Ｆ１１９に対して電気的にケーブルを接続するための複数の接続口（１１３２ａ〜１１３２ｃ）が設けられている。一方、筐体１１００の左側壁面１１４０には、後述の外部機器接続Ｉ／Ｆ１１９に対してディスプレイ１２０用のケーブル１２０ｃを接続するための接続口（不図示）が設けられている。

アーム１２００は、トルクヒンジ１２１０を介して筐体１１００に取り付けられており、アーム１２００が筐体１１００に対して、１３５度のチルト角θ１の範囲で、上下方向に回転可能に構成されている。図２は、チルト角θ１が９０度の状態を示している。

カメラハウジング１３００には、内蔵型のカメラ（後述する）が設けられており、この内蔵型カメラが会議の様子を撮像する。そして、カメラハウジング１３００は、トルクヒンジ１３１０を介してアーム１２００に取り付けられており、カメラハウジング１３００がアーム１２００に対して、図２で示されている状態を０度として±１８０度のパン角θ２の範囲で、且つ、±４５度のチルト角θ３の範囲で、上下左右方向に回転可能に構成されている。

以上、本実施形態の端末装置１０をその外観から説明したが、続いて、端末装置１０のハードウェア構成について説明する。

図３は、本実施形態の端末装置１０のハードウェア構成図である。図３に示すように、端末装置１０は、装置全体の動作を制御するＣＰＵ１０１、ＩＰＬ等のＣＰＵ１０１の駆動に用いられるプログラムを記憶したＲＯＭ１０２、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ１０３、端末用プログラム、画像データおよび音声データ等の各種データを記憶するフラッシュメモリ１０４、ＣＰＵ１０１の制御にしたがってフラッシュメモリ１０４に対する各種データの読み出し／書き込みを制御するＳＳＤ１０５、フラッシュメモリ等の記録メディア１０６に対するデータの読み出し／書き込みを制御するメディアドライブ１０７、端末装置１０の宛先を選択する場合などに操作される操作ボタン１０８、端末装置１０の電源のＯＮ／ＯＦＦを切り換えるための電源スイッチ１０９、通信ネットワークを利用してデータ伝送をするための通信ネットワークＩ／Ｆ１１１、および各構成要素を接続するアドレスバスやデータバス等のバスライン１１０を備えている。

また、端末装置１０は、会議の様子を撮像して画像データを取得するための画像入力装置として、レンズ光学系および固体撮像素子（ＣＭＯＳやＣＣＤ等）を含む内蔵型のカメラ１１２を備えており、撮像素子Ｉ／Ｆ１１３がカメラ１１２の駆動を制御する。

また、端末装置１０には、画像出力装置として、外付けのディスプレイ１２０が接続されており、ディスプレイ１２０は、ディスプレイＩ／Ｆ１１８が出力する画像信号（ＶＧＡ信号、ＨＤＭＩ（登録商標）信号、ＤＶＩ信号など）に基づいて、他の拠点の会議の様子や操作入力画面などを表示する。なお、ディスプレイは内蔵されていてもよい。

さらに、端末装置１０は、音声入力装置として、内蔵型のマイク１１４を備えており、音声入力Ｉ／Ｆ１１６がマイク１１４からの音声信号の入力を制御する。また、端末装置１０は、音声出力装置として、内蔵型のスピーカー１１５を備えており、スピーカー１１５は、音声出力Ｉ／Ｆ１１７が出力する音声信号に基づいて、他の拠点の会議の音声などを出力する。

各種の外部機器を接続するための外部機器接続Ｉ／Ｆ１１９には、ＵＳＢケーブル等によって、外付けカメラ、外付けマイク、および外付けスピーカー等の外部機器が接続可能に構成されており、本実施形態においては、外付けカメラが接続された場合には、内蔵型のカメラ１１２に優先して外付けカメラが駆動し、外付けマイクや外付けスピーカーが接続された場合には、内蔵型のマイク１１４や内蔵型のスピーカー１１５に優先して、外付けマイクや外付けスピーカーが駆動するように構成することができる。もしくは、カメラ、スピーカーおよびマイクの全てを外付けのみにしてもよい。

以上、本実施形態の端末装置１０のハードウェア構成について説明したが、続いて、本実施形態における中継装置３０および伝送管理装置５０のハードウェア構成について説明する。なお、中継装置３０および伝送管理装置５０は、いずれも、Ｗｅｂサーバとして参照される汎用の情報処理装置であるので、以下においては、これらのハードウェア構成をまとめて説明する。

図４は、本実施形態の情報処理装置（中継装置３０、伝送管理装置５０）のハードウェア構成図である。図４に示すように、本実施形態の情報処理装置３０，５０は、装置全体の動作を制御するＣＰＵ２０１、ＩＰＬ等のＣＰＵ２０１の駆動に用いられるプログラムを記憶したＲＯＭ２０２、ＣＰＵ２０１のワークエリアとして使用されるＲＡＭ２０３、各種データ（データ中継用プログラムや伝送管理用プログラム等）を記憶するＨＤ２０４、ＣＰＵ２０１の制御にしたがってＨＤ２０４に対する各種データの読み出し／書き込みを制御するＨＤＤ２０５、フラッシュメモリ等の記録メディア２０６に対するデータの読み出し／書き込みを制御するメディアドライブ２０７、各種情報を表示するディスプレイ２０８、ＬＡＮやインターネットなどの通信ネットワークを介してデータ伝送をするための通信ネットワークＩ／Ｆ２０９、入力装置としてのキーボード２１１およびマウス２１２、ＣＤ−ＲＯＭ２１３に対する各種データの読み出し／書き込みを制御するＣＤ−ＲＯＭドライブ２１４、および、上記各構成要素を接続するためのアドレスバスやデータバス等のバスライン２１０を備えている。

以上、本実施形態の端末装置１０、中継装置３０および伝送管理装置５０のハードウェア構成について説明してきたが、続いて、各装置の機能ブロックについて説明する。

図５は、本実施形態の端末装置１０および中継装置３０の機能ブロックを示す。図５に示すように、本実施形態においては、端末装置１０ａの送受信部１５と中継装置３０ａの中継制御部３２との間でコンテンツデータの送受信が実施される。本実施形態においては、所定のプログラムによって実現されるデータ受信制御部１２、受信優先順位管理部１３および最終出力時刻更新部１４の各機能部が協働して端末装置１０ａにおけるコンテンツデータの受信状態を制御する。

以下においては、図５に示した各機能部が実行する具体的な処理の内容を、図１における、東京事業所、大阪事業所、ニューヨーク事業所およびワシントンＤＣ事業所の各拠点に設置された端末装置１０ａ、端末装置１０ｂ、端末装置１０ｃおよび端末装置１０ｄのそれぞれが、自分以外の端末装置１０（３拠点）との間で２種類のコンテンツデータ（画像データおよび音声データ）を送受信するシナリオに基づいて説明する。なお、以下の説明においては、適宜、図５を参照するものとする。

本実施形態の遠隔会議システム１においては、ユーザが本システムのアカウントを作成し、またその際に、送信する予定のコンテンツデータを伝送管理装置５０に登録する。このとき、端末装置１０は、伝送管理装置５０から、システム内で端末を一意に識別するための識別子（以下、端末ＩＤという）、ならびに、システム内でコンテンツデータを一意に識別するための識別子（以下、データＩＤという）を付与される。

さらに、本実施形態の遠隔会議システム１においては、ユーザは、伝送管理装置５０を介して遠隔会議を行う予定の相手先に対して事前に承認を要求する。その際、各端末装置１０は、伝送管理装置５０から相手先の端末装置１０の端末ＩＤを取得する。

［受信データ管理テーブル生成例（１）］
上述した事項を前提として、本実施形態においては、遠隔会議の開始に先立ち、端末装置１０が受信データ管理テーブルを生成する。以下、受信データ管理テーブルの生成手順を図６に示すシーケンス図に基づいて説明する。なお、以下においては、東京事業所に設置される端末装置１０ａにフォーカスを当てて説明するものとする。

東京事業所のユーザが遠隔会議システム１へのログインに成功すると、端末装置１０ａの受信優先順位管理部１３は、送信を希望するコンテンツデータ（以下、データという）とその宛先を入力するための入力画面をディスプレイ１２０ａに表示する。ユーザは、当該入力画面を介して、送信を希望するコンテンツデータとその宛先を選択する。

これを受けて、受信優先順位管理部１３は、端末装置１０ａの端末ＩＤ、送信するデータのデータＩＤ（音声データのデータＩＤ“TKS0001A”および画像データのデータＩＤ“TKS0002V”）、ならびに、当該データの宛先となる端末装置１０（１０ｂ，１０ｃ，１０ｄ）の端末ＩＤを含む参加要求を生成し、これを伝送管理装置５０に送信する（Ｓ１．１）。以下、同様に、他の拠点（大阪事業所、ニューヨーク事業所、ワシントンＤＣ事業所）の端末装置１０（１０ｂ，１０ｃ，１０ｄ）は、自身の端末ＩＤ、送信するデータのデータＩＤおよび宛先の端末ＩＤを含む参加要求を伝送管理装置５０に送信する（Ｓ１．２）。

各拠点の端末装置１０から参加要求を受領した伝送管理装置５０は、参加要求に含まれる端末ＩＤから割り出した各装置のＩＰアドレスに基づいて、各拠点を宛先とするデータを中継する上で最適な中継装置３０を選択する（Ｓ２）。図１に示す例においては、東京事業所の端末装置１０ａを宛先とするデータの中継担当として中継装置３０ａが選択され、以下、同様に、大阪事業所、ニューヨーク事業所およびワシントンＤＣ事業所を宛先とするデータの中継担当として、それぞれ、中継装置３０ａ、中継装置３０ｂおよび中継装置３０ｃが選択される。

伝送管理装置５０は、中継装置３０ａが担当する中継データの一覧（以下、中継データ一覧という）を生成し（Ｓ３）、生成した中継データ一覧を中継装置３０ａに送信する（Ｓ４）。この中継データ一覧には、東京事業所の端末装置１０ａの端末ＩＤと、当該端末装置１０ａを宛先とするデータのデータＩＤが含まれる。

中継装置３０ａは、伝送管理装置５０から受領した中継データ一覧に基づいて、中継データ管理テーブルを生成する（Ｓ５）。中継データ管理テーブルは、中継装置３０ａがデータ中継を制御するために使用するテーブルであり、“宛先端末ＩＤ”、“送信データＩＤ”および“送信状態”を格納するための３つの列フィールドを備える。Ｓ５では、“宛先端末ＩＤ”フィールドに、中継装置３０ａが担当する中継データの宛先の端末装置１０の端末ＩＤが格納され、“送信データＩＤ”フィールドに、当該端末装置１０を宛先とするデータのデータＩＤが格納される。

図７（ａ）は、この時点で生成される中継データ管理テーブル３６を示す。図７（ａ）に示す例では、“宛先端末ＩＤ”フィールドに、端末装置１０ａの端末ＩＤ“TK0001”が格納され、“送信データＩＤ”フィールドには、ニューヨーク事業所の音声データのデータＩＤ“NY0011A”、同事業所の画像データのデータＩＤ“NY0012V”、大阪事業所の音声データのデータＩＤ“OS0031A”、同事業所の画像データのデータＩＤ“OS0032V”、ワシントンＤＣ事業所の音声データのデータＩＤ“WA0021A”、同事業所の画像データのデータＩＤ“WA0022V”が最上行から順番に格納されている。

続いて、伝送管理装置５０は、東京事業所の端末装置１０ａに対して、データ中継を担当する中継装置３０ａ（ＩＰアドレス）を通知する（Ｓ６）。これを受けて、端末装置１０ａは、中継装置３０ａを自身の中継担当として登録する（Ｓ７）。

次に、端末装置１０ａの受信優先順位管理部１３は、受信可能なデータの一覧（以下、受信可能データ一覧という）を中継装置３０ａに対して要求する（Ｓ８）。具体的には、自身の端末ＩＤ“TK0001”を含む受信可能データ一覧取得要求を生成し、これを中継装置３０ａに送信する。

これを受けて、中継装置３０ａは、受信可能データ一覧取得要求に含まれる端末ＩＤ“TK0001”をキーとして、図７(ａ)に示す中継データ管理テーブル３６を検索し、端末装置１０ａを宛先とするデータのデータＩＤの一覧（受信可能データ一覧）を生成し（Ｓ９）これを端末装置１０ａに送信する（Ｓ１０）。

端末装置１０ａの受信優先順位管理部１３は、中継装置３０ａから取得した受信可能データ一覧に基づいて、受信を希望するデータを選択するための入力画面を生成し、ディスプレイ１２０ａに表示する（Ｓ１１）。ここでは、６つのデータの名称（「ニューヨーク：画像」、「ニューヨーク：音声」、「ワシントンＤＣ：画像」、「ワシントンＤＣ：音声」、「大阪：画像」、「大阪：音声」）が選択可能に画面に表示されるものとする。

ユーザは、当該入力画面を介して、受信を希望するデータを選択する（Ｓ１２）。これを受けて、受信優先順位管理部１３は、受信データ管理テーブルを生成する（Ｓ１３）。受信データ管理テーブルは、端末装置１０ａがデータの受信を制御するために使用するテーブルであり、受信データ管理テーブル１６は、“優先度”、“受信データＩＤ”、“最終出力時刻”、“受信状態”および、“受信休止原因”を格納するための５つの列フィールドを備えている。

図８（ａ）は、東京事業所のユーザが受信を希望するデータを選択した時点で生成される受信データ管理テーブル１６を示す。図８（ａ）に示す例では、“受信データＩＤ”フィールドには、Ｓ１０で取得した受信可能データ一覧に含まれる６つのデータＩＤ（ニューヨーク事業所の音声データのデータＩＤ“NY0011A”、同事業所の画像データのデータＩＤ“NY0012V”、大阪事業所の音声データのデータＩＤ“OS0031A”、同事業所の画像データのデータＩＤ“OS0032V”、ワシントンＤＣ事業所の音声データのデータＩＤ“WA0021A”、同事業所の画像データのデータＩＤ“WA0022V”）が格納されている。

一方、“受信状態”フィールドには、各データの受信に関するステータスが格納される。具体的には、ユーザが選択したデータの“受信状態”フィールドには、そのステータスとして“受信要”がセットされ、ユーザが選択しなかったデータの“受信状態”フィールドには、そのステータスとして“受信不要”がセットされる。図８（ａ）に示す例では、ワシントンＤＣ事業所の画像データの“受信状態”フィールドに“受信不要”がセットされ、それ以外の“受信状態”フィールドの全てに“受信要”がセットされている。このことから、東京事業所のユーザが５つのデータ（「ニューヨーク：画像」、「ニューヨーク：音声」、「ワシントンＤＣ：音声」、「大阪：画像」、「大阪：音声」）の受信を希望していることが見て取れる。

一方、受信優先順位管理部１３は、ユーザが受信データを選択すると直ちに、受信データ管理テーブル１６の“受信データＩＤ”フィールドおよび“受信状態”フィールドの値ならびに自信の端末ＩＤを含む“受信データ情報”を生成し、これを中継装置３０ａに送信する（Ｓ１４）。これを受けて、中継装置３０ａは、中継データ管理テーブル３６を更新する（Ｓ１５）。具体的には、中継装置３０ａは、受領した受信データ情報に含まれる端末ＩＤとデータＩＤをキーとして中継データ管理テーブル３６の“宛先端末ＩＤ”フィールドと“中継データＩＤ”フィールドを検索して対応する中継データを特定し、“受信要“のデータについては、その”送信状態“フィールドに送信可“をセットし、“受信不要“のデータについては、その“送信状態”フィールドに“送信不可”をセットする。

図７（ｂ）は、Ｓ１５で更新された後の中継データ管理テーブル３６を示す。図７（ｂ）に示すように、この時点で、ユーザ選択した５つのデータ（「ニューヨーク：画像」、「ニューヨーク：音声」、「ワシントンＤＣ：音声」、「大阪：画像」、「大阪：音声」）に対応する“送信状態”フィールドに“送信可”がセットされ、それ以外のデータ（「ワシントンＤＣ：画像」）に対応する“送信状態”フィールドに“送信不可”がセットされている。

続いて、端末装置１０ａの受信優先順位管理部１３は、受信データの優先順位を設定するための入力画面を生成し、ディスプレイ１２０ａに表示する（Ｓ１６）。ここでは、５つのデータの名称（「ニューヨーク：画像」、「ニューヨーク：音声」、「ワシントンＤＣ：音声」、「大阪：画像」、「大阪：音声」）の順番を設定できるような画面が表示されるものとする。

ユーザは、当該入力画面を介して、５つのデータの受信に関して優先順位を設定する（Ｓ１７）。このとき、ユーザは、国内事業所よりも海外事業所を優先するとか、画像データよりも音声データを優先するといった考えに基づいて優先順位を設定する。

これを受けて、受信優先順位管理部１３は、受信データ管理テーブル１６の“優先度”フィールドに対して、優先順位番に応じた優先度をセットする（Ｓ１８）。ここで“優先度”は、「１」以上の整数で表現され、値が小さいほど優先度が高いことを意味する。従って、ここでは、優先順位の高いデータほど“優先度”フィールドに小さい値がセットされる。

図８（ｂ）は、東京事業所のユーザが受信データの優先順位を決定した時点の受信データ管理テーブル１６を示す。図８（ｂ）に示す例では、優先度に基づく昇順ソートの結果、ニューヨーク事業所の音声データ（ID=NY0011A）、同事業所の画像データ(ID=NY0012V)、ワシントンＤＣ事業所の音声データ(ID=WA0021A)、大阪事業所の音声データ(ID=OS0031A)、同事業所の画像データ(ID=OS0032V)の各行が最上行から順番に並んでおり、受信が選択されなかった最下行のワシントンＤＣ事業所の画像データ(ID=WA0022V)の“優先度”フィールドが空欄になっている。

以上、端末装置１０の受信優先順位管理部１３が受信データ管理テーブルを生成する手順について説明した。上述した例では、ユーザが受信データの優先順位を直接的に設定する態様を説明したが、本発明は、上述した態様に限定されるものでなく、例えば、優先順位を決定するアルゴリズムを実装したプログラムを使用してもよい。この場合、ウィザードを使って、「国内と外国のどちらを優先しますか？」、「画像と音声のどちらを優先しますか？」といった質問をユーザに投げかけて条件を設定させ、専用のプログラムが設定された条件から優先順位を導出して自動的に設定する。この場合、「現在の話者を優先する」といった条件に対応する実装にすれば、話者が変わる度に優先順位が動的に変化するといったユースケースも可能になる。また、会議の参加者とコンテンツデータの優先順位が決まっているような利用シーンでは、装置の起動と同時にプリセットの受信データ管理テーブルが読み出されるような構成にしてもよい。

［伝送管理装置５０の機能構成］
図９は、本実施形態の伝送管理装置５０の機能ブロックを示す。図９に示すように、本実施形態の伝送管理装置５０は、送受信部５１、端末認証部５２、端末管理部５３、抽出部５４、端末状態確認部５６、宛先リスト管理部５７、記憶・読出処理部５９および記憶装置５８を含んで構成される。

送受信部５１は、ネットワーク８０を介して端末装置１０および中継装置３０と各種データの送受信を行う。端末認証部５２は、送受信部５１を介して受信されたログイン要求情報に含まれている端末ＩＤおよびパスワードを検索キーとし、記憶装置５８に格納された端末認証管理テーブル５００（図１０参照）を検索し、端末認証管理テーブル５００に同一の組の端末ＩＤおよびパスワードが管理されているかを判断することによって端末認証を行う。

端末管理部５３は、ログイン要求してきた要求元端末の稼動状態を管理すべく、端末管理テーブル５０２（図１１参照）に、この要求元端末の端末ＩＤ、要求元端末の稼動状態、伝送管理装置５０でログイン要求情報が受信された受信日時、および要求元端末のＩＰアドレスを関連付けて記憶して管理する。また、端末管理部５３は、利用者が端末装置１０の電源スイッチ１０９（図３参照）をＯＮの状態からＯＦＦにすることで、端末装置１０から送られてきた、電源をＯＦＦする旨の稼動状態情報に基づいて、端末管理テーブル５０２のオンラインを示す稼動状態をオフラインに変更する。

抽出部５４は、ログイン要求した要求元端末の端末ＩＤをキーとして、図１２に示す宛先リスト管理テーブル５０４を検索し、要求元端末と通話することができる宛先端末の候補の端末ＩＤを読み出すことで端末ＩＤを抽出する。ここで宛先リスト管理テーブル５０４は、遠隔会議システム１にアカウントを有する各端末装置１０間で事前に実施される相互認証処理に基づいて生成されるテーブルであり、送信元の端末装置１０の端末ＩＤと当該送信元の端末装置１０が承認を受けた宛先の端末装置１０の端末ＩＤを対応付けて管理する。

また、抽出部５４は、ログイン要求してきた要求元端末の端末ＩＤをキーとして、宛先リスト管理テーブル５０４を検索し、上記要求元端末の端末ＩＤを宛先端末の候補として登録している他の要求元端末の端末ＩＤも抽出する。また、抽出部５４は、この抽出部５４によって抽出された宛先端末の候補の端末ＩＤを検索キーとして、端末管理テーブル５０２を検索し、上記抽出部５４によって抽出された端末ＩＤ毎に稼動状態を読み出す。これにより、抽出部５４は、ログイン要求してきた要求元端末と通話することができる宛先端末の候補の稼動状態を取得することができる。また、抽出部５４は、この抽出部５４によって抽出された端末ＩＤを検索キーとして、端末管理テーブル５０２を検索し、ログイン要求してきた要求元端末の稼動状態も抽出する。

端末状態確認部５６は、端末ＩＤ又は宛先名を検索キーとして端末管理テーブル５０２を検索することにより、対応する稼動状態を確認する。

宛先リスト管理部５７は、宛先リスト管理テーブル５０４の各要求元端末の端末ＩＤ毎に、宛先端末の端末ＩＤを追加又は削除する。

記憶・読出処理部５９は、記憶装置５８に各種データを記憶し、記憶装置５８に記憶された各種データを読み出す処理を行う。

［会議の開催方法について］
端末装置１０が遠隔会議システム１にログインして会議に参加する際に実行される処理を図１３に示すシーケンス図に基づいて説明する。

まず、利用者が電源スイッチ１０９（図３参照）をＯＮにする（ステップＳ２１）。これに応答して、端末装置１０は、伝送管理装置５０に対して、端末ＩＤとパスワードを含むログイン要求を発行する（ステップＳ２２）。

伝送管理装置５０の端末認証部５２は、送受信部５１を介して受信したログイン要求に含まれている端末ＩＤおよびパスワードを検索キーとして、記憶装置５８の端末認証管理テーブル５００（図１０参照）を検索し、端末認証管理テーブル５００に同一の端末ＩＤおよび同一のパスワードが管理されているかを判断することによって端末認証を行う（ステップＳ２３）。認証に成功した場合、端末管理部５３は、端末管理テーブル５０２（図１２参照）に、ログイン要求元の端末装置１０の端末ＩＤおよび宛先名で示されるレコード毎に、稼動状態、上記ログイン要求が受信された受信日時、および端末装置１０のＩＰアドレスを関連付けて記憶する（ステップＳ２４）。その後、端末認証部５２は、送受信部５１を介して認証結果（認証成功）をログイン要求元の端末装置１０に送信する（ステップＳ２５）。

端末装置１０は、認証結果（認証成功）を受信すると、伝送管理装置５０に対して宛先リスト要求を発行する（ステップＳ２６）。これを受けて、伝送管理装置５０の抽出部５４は、宛先リスト要求元の端末装置１０の端末ＩＤを検索キーとして、宛先リスト管理テーブル５０４（図１２参照）を検索し、宛先リスト要求元の端末装置１０と通話することができる宛先端末の候補の端末ＩＤを抽出すると共に、この端末ＩＤに対応する宛先名を端末管理テーブル５０２（図１１参照）から読み出す（ステップＳ２７）。

次に、伝送管理装置５０の記憶・読出処理部５９は、記憶装置５８から宛先リスト枠のデータを読み出す（ステップＳ２８）と共に、この宛先リスト枠並びに抽出部５４が抽出した端末ＩＤおよび宛先名を含めた「宛先リスト情報（宛先リスト枠、端末ＩＤ、宛先名）」を、宛先リスト要求元の端末装置１０に送信する（ステップＳ２９）。これを受けて、要求元の端末装置１０は、受信した宛先リスト情報を管理情報記憶部に記憶する（ステップＳ３０）。

さらに、伝送管理装置５０の抽出部５４は、先に抽出した宛先端末の候補の端末ＩＤを検索キーとして、端末管理テーブル５０２（図１１参照）を検索し、宛先端末の候補の端末ＩＤ毎に、対応する稼動状態を読み出す（ステップＳ３１）。

次に、伝送管理装置５０の送受信部５１は、上記Ｓ１７で検索キーに使用した端末ＩＤと、対応する宛先端末の稼動状態を含む「端末の稼動状態情報」を要求元の端末装置１０に送信する（ステップＳ３２）。

これを受けて、要求元の端末装置１０は、受信した「端末の稼動状態情報」を管理情報記憶部に記憶する（ステップＳ３３）。このようにして、要求元の端末装置１０は、通話することができる宛先端末の候補の現時点における稼動状態を取得することができる。

次に、要求元の端末装置１０は、管理情報記憶部に記憶されている宛先リスト情報および端末の稼働状態情報に基づいて、宛先候補としての端末装置１０の状態を反映させた宛先リストを作成・表示する。図１４は、端末装置１０に接続されたディスプレイ１２０に表示された宛先リストを例示的に示す。

以上、端末装置１０が遠隔会議システム１にログインする際に実行される処理について説明してきたが、本実施形態では、利用者が表示された宛先リスト（図１４参照）から所望の端末装置１０を選択したこと応答して、その選択先との間でコンテンツデータの送受信がスタンバイされるように構成されている。利用者が選択した端末装置１０が既に他の端末装置１０と会議中であった場合には、当該利用者（の端末装置１０）は、その会議に参加している全ての端末装置１０との間でコンテンツデータの送受信がスタンバイされる。

［端末装置１０、中継装置３０の機能構成］
本実施形態の端末装置１０および中継装置３０機能ブロックについて説明する。

図１５は、本実施形態の端末装置１０および中継装置３０の機能ブロックを示す。図１５に示すように、本実施形態の端末装置１０は、符号量変更要求部１２、符号量変更部１３、最終出力時刻更新部１４、および送受信部１５を含んで構成されている。

符号量変更要求部１２は、利用者が選択した所定のコンテンツデータに係る出力遅延を検知したことに応答して、当該コンテンツデータの符号量の削減を要求する旨（以下、符号量削減要求という）を当該コンテンツデータの送信元宛に送信するための機能部である。また、符号量変更部１３は、他の端末装置１０を送信元とする符号量削減要求に応答して、送信データの符号量を削減する処理を実行するための機能部である。

最終出力時刻更新部１４は、利用者が選択した所定のコンテンツデータに係る最終出力時刻（後述する）を更新するため機能部である。また、送受信部１５は、中継装置３０を介して他の端末装置１０との間で各種データを送受信するための機能部である。

一方、本実施形態の中継装置３０は、中継制御部３２と削減要求履歴管理部３４を含んで構成されている。

中継制御部３２は、端末装置１０から受信した各種データを指定された宛先に転送するための機能部である。また、削減要求履歴管理部３４は、各端末装置１０から受信した符号量削減要求の履歴を管理するための機能部である。

［端末装置１０、中継装置３０の動作］
以上、端末装置１０および中継装置３０の機能ブロックについて概説したが、続いて、図１５に示した各機能部が実行する具体的な処理の内容を図１６に示すシーケンス図に基づいて説明する。なお、以下の説明においては、適宜、図１５を参照するものとする。

利用者は、端末装置１０ａのディスプレイ１２０に表示された宛先リスト（図１４参照）から所望の宛先を選択することによって会議に参加する。このとき、端末装置１０ａのＵＩ制御部（図示せず）は、送信を希望するコンテンツデータの登録・解除を受け付けるための入力画面をディスプレイ１２０に表示する。

［受信データ管理テーブル生成例（２）］
続いて、受信データ管理テーブルを生成する別の方法について具体的な処理の内容を図１６に示すシーケンス図に基づいて説明する。

利用者が入力画面を介して送信を希望するコンテンツデータを選択すると、ＵＩ制御部（図示せず）は、選択されたコンテンツデータの登録要求を中継装置３０に送信する（Ｓ４１）。

これを受けて中継装置３０は、端末装置１０ａから登録を要求された各コンテンツデータに対して、端末装置１０が現在参加する会議内でユニークなデータＩＤを付与するとともに、当該会議に参加する全ての端末装置１０（端末装置１０ａを含む）が登録したコンテンツデータのデータ名とデータＩＤの一覧であるコンテンツデータ登録情報を生成し（Ｓ４２）、これを端末装置１０ａに送信する（Ｓ４３）。

併せて、中継装置３０は、図１７（ａ）に示す中継データ管理テーブル６００を生成（既に生成済みの場合は内容を更新）する（Ｓ４４）。図１７（ａ）に示すように、中継データ管理テーブル６００は、中継装置３０が中継するコンテンツデータに関して、セッションＩＤを格納するためのフィールド６０２、データＩＤを格納するためのフィールド６０４、および、そのコンテンツデータの符号量削減要求の送信元となる端末装置１０の端末ＩＤを格納するためのフィールド６０６を備えており、各フィールドの値を対応付けて管理している。

一方、端末装置１０ａの符号量変更要求部１２は、ＵＩ制御部（図示せず）が中継装置３０からコンテンツデータ登録情報を受領したことに応答して、図１８（ａ）に示す受信データ管理テーブル７００を生成する（Ｓ４５）。図１８（ａ）に示すように、受信データ管理テーブル７００は、他の端末装置１０（１０ｂ、１０ｃ、１０ｄ…）から受信するコンテンツデータに関して、データＩＤを格納するためのフィールド７０２、最終出力時刻を格納するためのフィールド７０４、および、符号量削減要求に係る状態を格納するためのフィールド７０６を備えている。

続いて、端末装置１０ａのＵＩ制御部（図示せず）は、中継装置３０から受信したコンテンツデータ登録情報に基づいて、端末装置１０ａがその会議において受信する予定のコンテンツデータの一覧を含む選択画面を生成し、ディスプレイ１２０に表示する（Ｓ４６）。利用者は、当該入力画面を介して、利用者が遅延なく出力したいと考える少なくとも１つのコンテンツデータを選択する。具体的には、会議において参加者の発言内容を最重要視する利用者が受信予定の複数のコンテンツデータの中から各拠点の音声データを選択するといったケースが考えられる。

ＵＩ制御部（図示せず）を介して利用者の選択入力を受けたことに応答して、符号量変更要求部１２は、受信データ管理テーブル１６（図８参照）のフィールドに対して、選択されたコンテンツデータのデータＩＤをセットする（Ｓ４７）。図１８（ｂ）は、データＩＤがセットされた受信データ管理テーブル７００を示す。

続いて、端末装置１０ａは、中継装置３０に対して受信データ情報を送信する（Ｓ４８）。その後、端末装置１０ａは、受信優先順位設定の画面を表示し（Ｓ４９）、ユーザによる受信優先順位の設定を受付け（Ｓ５０）、ここで設定された受信優先順位をセットする（Ｓ５１）。

すなわち、前述した実施形態と同様に、受信優先順位管理部１３は、受信データ管理テーブルを生成する。受信データ管理テーブルは、端末装置１０ａがデータの受信を制御するために使用するテーブルであり、受信データ管理テーブル１６は、“優先度”、“受信データＩＤ”、“最終出力時刻”、“受信状態”および、“受信休止原因”を格納するための５つの列フィールドを備えている。

上述した手順が済んだ時点で、端末装置１０ａは、他の端末装置１０（１０ｂ、１０ｃ、１０ｄ…）を宛先に指定した自身のコンテンツデータを中継装置３０に対して送信するとともに、自身が宛先として指定された他の端末装置１０（１０ｂ、１０ｃ、１０ｄ…）のコンテンツデータを中継装置３０から受信する。このとき、中継装置３０を介して送受信されるコンテンツデータのパケットにはデータＩＤが格納される。

したがって、このような動作により、受信データ管理テーブルを作成することができる。

上述したように、受信データ管理テーブルの準備が整った後、遠隔会議が開始される。遠隔会議の開始と同時に、３つの拠点の端末装置１０（１０ｂ、１０ｃ、１０ｄ）は、東京事業所の端末装置１０ａを宛先に指定したデータ（データストリーム）を中継装置３０ａに宛てて送信する。このとき、各端末装置１０は、送信するデータのパケットにデータＩＤを格納する。

各拠点からデータを受信した中継装置３０ａの中継制御部３２は、先に説明したように、中継データ管理テーブル３６を使用してデータの中継を制御する。図１８は、遠隔会議の開始当初のデータの中継状態を示す。中継制御部３２は、３つの拠点の端末装置１０（１０ｂ、１０ｃ、１０ｄ）から受信したデータのパケットに含まれるデータＩＤをキーとして、図７（ｂ）に示す中継データ管理テーブル３６の“中継データＩＤ”フィールドを検索し、一致したデータＩＤ対応する“送信状態”フィールドに“送信可”がセットされているデータについては、これを東京事業所の端末装置１０ａに転送し、一致したデータＩＤ対応する“送信状態”フィールドに“送信不可”がセットされているデータについては、これを破棄する。その結果、東京事業所の端末装置１０ａには、ユーザが希望した５つのデータ（ニューヨーク事業所の音声データおよび画像データ、ワシントンＤＣ事業所の音声データ、大阪事業所の音声データおよび画像データ）のみが転送される。

このとき、送信元の端末装置１０（１０ｂ、１０ｃ、１０ｄ）がデータを発送してから宛先の端末装置１０ａが当該データに対応する出力信号を自身の出力装置に出力するまでの時間が許容範囲を超えて長くなると、東京事業所において、ユーザが画像や音声の劣化（遅延）を感知するようになり、拠点間のコミュニケーションの質が低下する。

この点につき、本実施形態においては、ユーザが画像や音声の劣化（遅延）を感知する前に、優先順位の低いデータの受信を強制的に休止することによって、優先順位の高いデータに係る出力品質の低下を回避する。

ここで、出力品質の劣化（遅延）の原因は、通信ネットワークの通信状態に起因する“伝送遅延”と、データを受信してから出力信号を生成するまでの処理時間に起因する“内部処理遅延”に求められるところ、その原因の如何にかかわらず、出力品質の劣化（遅延）の兆候は、出力信号を出力する時間間隔の増大化として現れる。本実施形態では、この点に着目し、出力信号の出力時間間隔に基づいて出力品質を検知する。

以下では、出力品質を検知するために、本実施形態の端末装置１０の最終出力時刻更新部１４が実行する処理について説明する。最終出力時刻更新部１４は、受信したデータに対応する出力信号を対応する出力装置に最後に出力したシステム時刻（以下、最終出力時刻という）を受信データ管理テーブル１６の“最終出力時刻”のフィールドに格納し、新たな出力信号が出力される度にその値を更新する。

具体的には、最終出力時刻更新部１４は、音声出力Ｉ／Ｆ１１７（図３参照）が、他の端末装置１０を送信元とする音声データに基づいて生成した音声信号をスピーカー１１５（図３参照）に出力した最終出力時刻を、当該音声データに対応する“最終出力時刻”フィールドに格納し、新たに音声信号が出力される度にその値を更新する。また、最終出力時刻更新部１４は、ディスプレイＩ／Ｆ１１８が、他の端末装置１０を送信元とする画像データに基づいて生成した画像信号をディスプレイ１２０（図３参照）に出力した最終出力時刻を、当該画像データに対応する“最終出力時刻”フィールドに格納し、新たに出力信号が出力される度にその値を更新する。なお、最終出力時刻更新部１４は、描画データ（ネットワークを介して送信元から受信した画像データをデコードして得られるデータ）を描画モジュールに引き渡した時刻（タイムスタンプ）を最終出力時刻として更新してもよい。

図８（ｃ）は、東京事業所の端末装置１０ａがデータの受信を開始した後の受信データ管理テーブル１６を示す。端末装置１０ａがデータの受信を開始すると、図８（ｃ）に示すように、各データの“最終出力時刻”フィールドに最新の最終出力時刻がセットされる。

以上、最終出力時刻更新部１４が実行する処理について説明してきたが、続いて、データ受信制御部１２が実行する処理について説明する。本実施形態におけるデータ受信制御部１２は、出力信号の出力時間間隔の監視の結果、優先順位の高いデータに係る出力品質の劣化を事前に検知した場合に、優先順位の低いデータの受信を強制的に休止する処理を行う。

本実施形態においては、その前段階において、まず、出力品質の維持を希望するデータ（以下、優先データという）を定義する。具体的には、パラメータｎを用意し、受信データ管理テーブル１６において、優先順位が上位ｎ位以内（優先度がｎ以下）のデータを優先データとして定義する。なお、パラメータｎは、固定値としてもよいし、ユーザが任意の値を設定できるようにしてもよい。図８（ｃ）に示す受信データ管理テーブル１６において、パラメータｎ＝２に設定すると、優先度１であるニューヨーク事業所の音声データ（ID=NY0011A）と、優先度２である同事業所の画像データ(ID=NY0012V)）が優先データとして定義される。

以下においては、ニューヨーク事業所の音声データと画像データを優先データとして定義した場合において、ニューヨーク事業所の画像の遅延が増大化しつつある状況下でデータ受信制御部１２が実行する処理の内容を説明する。

図１９は、データ受信制御部１２が実行する処理を表すフローチャートである。図１９に示すように、データ受信制御部１２が実行するルーチンは、第１のループ処理（ステップ１００）と、これに後続する第２のループ処理（ステップ２００）からなり、データ受信制御部１２は、２つのループ処理からなるルーチンを所定のタイミングで繰り返し実行する。

第１のループ処理（ステップ１００）では、“優先データ”として定義されたｎ個のデータを対象にして、優先度の高い方から順番に以下のステップ１０１〜１０４を実行する。本ケースでは、まず、ステップ１０１において、優先度１のニューヨーク事業所の音声データ（ID=NY0011A）の最終出力時刻からの経過時間が第１の閾値Ｔ_１を超過しているか否かを判断する。具体的には、受信データ管理テーブル１６のデータＩＤ“NY0011A”に対応する“最終出力時刻”フィールドに格納された時刻と現在時刻との差分から経過時間を求め、当該経過時間が閾値Ｔ_１を超過しているか否かを判断する。

本ケースでは、ニューヨーク事業所の音声の出力状態は良好なので、ステップ１０１で、閾値Ｔ_１を超過していないと判断され（ステップ１０１、Ｎｏ）、ニューヨーク事業所の音声データに関する処理はここで終了する。その後、処理はステップ１０１に戻って、今度は、優先度２のニューヨーク事業所の画像データ(ID=NY0012V)の最終出力時刻からの経過時間が第１の閾値Ｔ_１を超過しているか否かを判断する。具体的には、受信データ管理テーブル１６のデータＩＤ“NY0012V”に対応する“最終出力時刻”フィールドに格納された時刻と現在時刻との差分から経過時間を求め、当該経過時間が閾値Ｔ_１を超過しているか否かを判断する。

ここで、ニューヨーク事業所の画像の遅延が増大化しつつある本ケースでは、ステップ１０で、閾値Ｔ_１を超過していると判断され（ステップ１０１、Ｙｅｓ）、処理はステップ１０２に進む。

ステップ１０２では、閾値Ｔ_１を超過していると判断された優先データの復帰カウンタが０クリアされる。具体的には、ニューヨーク事業所の画像データ(ID=NY0012V)のために専用の復帰カウンタを用意し、当該カウンタを０クリアする。

ここで、上述した閾値Ｔ_１は、求める出力品質に応じた出力信号の出力時間間隔の上限値として定義され、出力時間間隔が閾値Ｔ_１を超えると、ユーザは画像や音声の遅延を感知し始める。なお、閾値Ｔ_１は、音声データおよび画像データについて、共通の値を定義してもよいし、データの種類ごとに固有の値を定義してもよい。

続くステップ１０３では、現在、受信中のデータの中から、最も優先度の低いデータを選択する。具体的には、受信データ管理テーブル１６を参照して、“受信状態”が“受信要”となっているデータの中から、最も低い優先度がセットされているデータのデータＩＤを抽出する。

受信データ管理テーブル１６が図２０（ｄ）に示す状態にあった場合、ステップ１０３では、優先度５の大阪事業所の画像データのデータＩＤ“OS0032V”が抽出される。

続くステップ１０４では、選択したデータの受信休止処理を実行する。具体的には、ステップ１０３で抽出したデータＩＤ“OS0032V”を含む“送信休止要求”を生成し、これを中継装置３０ａに発行した後、受信データ管理テーブル１６を図２０（ｅ）に示す状態に更新する。すなわち、データＩＤ“OS0032V”に対応する“受信状態”フィールドの値を“受信要”から“受信休止”に変更するとともに、データＩＤ“OS0032V”に対応する“受信休止原因”フィールドにニューヨーク事業所の画像データのデータＩＤ“NY0012V”をセットする。本実施形態において、受信休止処理とは、“送信休止要求”を中継装置３０ａへ送信することによって、送信を止めるように制御する旨を中継装置３０ａに要求する処理を意味し、送信を止めるように制御する旨は、端末装置間のセッションが終わるまで送信を止めるように制御する旨であってもよい。

このとき、東京事業所の端末装置１０ａのデータ受信制御部１２から送信休止要求を受領した中継装置３０ａは、中継データ管理テーブル３６を図２１（ｃ）に示すように更新する。具体的には、中継装置３０ａは、受領した送信休止要求に含まれるデータＩＤ“OS0032V”をキーとして中継データ管理テーブル３６の“中継データＩＤ”フィールドを検索し、“OS0032V”に対応する“送信状態“フィールドの値を”送信可“から”送信不可“に更新する。中継データ管理テーブル３６が図２１（ｃ）のように更新されて以降、中継装置３０ａの中継制御部３２は、東京事業所の端末装置１０ａを宛先とする大阪事業所の画像データ(ID=OS0032V)を端末装置１０ａに転送することなくこれを破棄する。

ここまでで、“優先データ”として定義された２つのデータ（ニューヨーク事業所の音声データと画像データ）について、第１のループ処理（ステップ１００）が終了したので、処理は、後続する第２のループ処理（ステップ２００）に移る。第２のループ処理（ステップ２００）では、第１のループ処理（ステップ１００）で受信が休止状態になった１以上のデータ（以下、受信休止データという）を対象にして、優先度の高い方から順番に以下のステップ２０１〜２０７を実行する。

まず、ステップ２０１において、受信休止データ（本シナリオでは、大阪事業所の画像データ）につき、受信データ管理テーブル１６を参照して、その受信休止の原因となったデータ（以下、原因データという）を特定する。ここで、受信データ管理テーブル１６が図１１（ｅ）に示す状態であった場合ステップ２０１では、“受信状態”が“受信休止”となっている大阪事業所の画像データに対応する“受信休止原因”フィールドにセットされた値“NY0011V”が大阪事業所の画像データの受信休止の原因となったニューヨーク事業所の音声データのデータＩＤとして特定される。

続くステップ２０２では、ステップ２０１で特定した原因データ（ニューヨーク事業所の画像データ）の最終出力時刻からの経過時間が第２の閾値Ｔ_２未満であるか否かを判断する。具体的には、受信データ管理テーブル１６を参照して、ステップ２０１で特定したデータＩＤ“NY0011V”に対応する“最終出力時刻”フィールドに格納された時刻と現在時刻との差分から経過時間を求め、当該経過時間が閾値Ｔ_２を超過しているか否かを判断する。

ここで、上述した閾値Ｔ_２は、第１のループ処理のステップ１０１で使用した閾値Ｔ_１と同じく、求める出力品質に応じた出力信号の出力時間間隔として観念されるものであるが、閾値Ｔ_２の値は、閾値Ｔ_１よりも十分に小さいことが望ましく、且つ、当該出力信号に対応するデータを送信元が送信する時間間隔よりも大きい値でなければならない。なお、閾値Ｔ_２も閾値Ｔ_１と同様に、音声データおよび画像データに共通の値を定義してもよいし、データの種類（音声／画像）ごとに固有の値を定義してもよい。

ステップ２０２における判断の結果、経過時間が閾値Ｔ_２未満でないと判断した場合は（ステップ２０２、Ｎｏ）、処理はステップ２０８に進み、原因データの復帰カウンタを０クリアする。本ケースでは、大阪事業所の画像データの受信を休止したにもかかわらず、通信ネットワークの通信状態や端末装置１０ａ内部の高負荷状態が十分に改善していない場合、ステップ２０２において、経過時間が閾値Ｔ_２未満でないと判断され（ステップ２０２、Ｎｏ）、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが０クリアされる。この時点で、全ての受信休止データについて処理が終了したことになるので、第２のループ処理（ステップ２００）を終了する。

第２のループ処理（ステップ２００）が終了すると、次のタイミングを待って、再び、第１のループ処理（ステップ１００）が開始する。

ステップ１０１では、優先度１のニューヨーク事業所の音声データ（ID=NY0011A）の最終出力時刻からの経過時間が第１の閾値Ｔ_１を超過していないと判断され（ステップ１０１、Ｎｏ）、ニューヨーク事業所の音声データに関する処理が終了し、再び、ステップ１０１で、今度は、優先度２のニューヨーク事業所の画像データ(ID=NY0012V)の最終出力時刻からの経過時間が第１の閾値Ｔ_１を超過しているか否かを判断する。

この時点で、大阪事業所の画像データの受信を休止したにもかかわらず、通信ネットワークの通信状態や端末装置１０ａ内部の高負荷状態に実質的な改善が見られない場合、ステップ１０１で、閾値Ｔ_１を超過していると判断され（ステップ１０１、Ｙｅｓ）、処理はステップ１０２に進む。

ステップ１０２では、閾値Ｔ_１を超過していると判断されたニューヨーク事業所の画像データ(ID=NY0012V)の復帰カウンタが０クリアされた後、続くステップ１０３で、受信データ管理テーブル１６を参照して、現在、受信中のデータの中から、最も優先度の低いデータを選択する。ここで、受信データ管理テーブル１６が図２０（ｅ）に示す状態にあった場合、ステップ１０３では、優先度４の大阪事業所の音声データのデータＩＤ“OS0031A”が抽出される。

続くステップ１０４では、選択したデータの受信休止処理を実行する。具体的には、ステップ１０３で抽出したデータＩＤ“OS0031A”を含む“送信休止要求”を生成し、これを中継装置３０ａに発行した後、受信データ管理テーブル１６を図２０（ｆ）に示す状態に更新する。すなわち、データＩＤ“OS0031A”に対応する“受信状態”フィールドの値を“受信要”から“受信休止”に変更するとともに、データＩＤ“OS0031A”に対応する“受信休止原因”フィールドにニューヨーク事業所の画像データのデータＩＤ“NY0012V”をセットする。

このとき、東京事業所の端末装置１０ａのデータ受信制御部１２から送信休止要求を受領した中継装置３０ａは、中継データ管理テーブル３６を図２１（ｄ）に示すように更新する。具体的には、中継装置３０ａは、受領した送信休止要求に含まれるデータＩＤ“OS0031A”をキーとして中継データ管理テーブル３６の“中継データＩＤ”フィールドを検索し、“OS0031A”に対応する“送信状態“フィールドの値を”送信可“から”送信不可“に更新する。中継データ管理テーブル３６が図２１（ｄ）のように更新されて以降、中継装置３０ａの中継制御部３２は、東京事業所の端末装置１０ａを宛先とする大阪事業所の音声データ(ID=OS0031A)を端末装置１０ａに転送することなくこれを破棄する。

ここまでで、第１のループ処理（ステップ１００）が終了し、後続する第２のループ処理（ステップ２００）では、現在の受信休止データを対象にして、優先度の高い方から順番に以下のステップ２０１〜２０７を実行する。

まず、ステップ２０１において、最も優先度の高い受信休止データ（大阪事業所の音声データ）につき、その原因データであるニューヨーク事業所の音声データを取得し、続くステップ２０２では、原因データ（ニューヨーク事業所の画像データ）の最終出力時刻からの経過時間が第２の閾値Ｔ_２未満であるか否かを判断する。

大阪事業所の画像データに加えて音声データの受信を休止した結果、通信ネットワークの通信状態または端末装置１０ａ内部の高負荷状態が改善され、ニューヨーク事業所の画像が高品質に維持されている場合、ステップ２０２において、経過時間が閾値Ｔ_２未満であると判断され（ステップ２０２、Ｙｅｓ）、処理はステップ２０３に進む。ステップ２０３では、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが１増加された後、続くステップ２０４で、当該復帰カウンタの値が閾値Ｎに達したか否かが判断される。

ステップ２０４の判断の結果、復帰カウンタの値が閾値Ｎに達していないと判断された場合には、この時点で、大阪事業所の音声データ（受信休止データ）についての処理を終了し、再び、ステップ２０１に戻る。ステップ２０１では、２番目に優先度の高い受信休止データ（大阪事業所の画像データ）につき、その原因データ（ニューヨーク事業所の画像データ）を特定し、その最終出力時刻からの経過時間が第２の閾値Ｔ_２未満であるか否かを判断する（ステップ２０２）。

ニューヨーク事業所の画像が高品質に維持されているこの時点では、ステップ２０２で、経過時間が閾値Ｔ_２未満であると判断され（ステップ２０２、Ｙｅｓ）、続くステップ２０３で、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが１増加された後、当該復帰カウンタの値が閾値Ｎに達したか否かが判断される。

ステップ２０４の判断の結果、復帰カウンタの値が閾値Ｎに達しないと判断された場合、大阪事業所の画像データ（受信休止データ）についての処理を終了する。この時点で、全ての受信休止データについて処理が終了したことになるので、第２のループ処理（ステップ２００）を終了する。

第２のループ処理（ステップ２００）が終了すると、次のタイミングを待って、再び、第１のループ処理（ステップ１００）が開始する。

ステップ１０１では、優先度１のニューヨーク事業所の音声データ（ID=NY0011A）および優先度２の画像データ(ID=NY0012V)について、順番に、最終出力時刻からの経過時間が第１の閾値Ｔ_１を超過しているか否かが判断される。ニューヨーク事業所の画像および音声とも高品質に維持されているこの時点では、いずれの経過時間も閾値Ｔ_１を超過していないので（ステップ１０１、Ｎｏ）、第１のループ処理（ステップ２００）をそのまま終了する。

後続する第２のループ処理（ステップ２００）では、現在の受信休止データを対象にして、優先度の高い方から順番に以下のステップ２０１〜２０７が実行される。

まず、ステップ２０１において、最も優先度の高い受信休止データ（大阪事業所の音声データ）につき、その原因データ（ニューヨーク事業所の画像データ）の最終出力時刻からの経過時間が第２の閾値Ｔ_２未満であるか否かを判断する。

ニューヨーク事業所の画像が高品質に維持されているこの時点では、ステップ２０２において、経過時間が閾値Ｔ_２未満であると判断され（ステップ２０２、Ｙｅｓ）、処理はステップ２０３に進む。ステップ２０３では、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが１増加された後、続くステップ２０４で、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタの値が閾値Ｎに達したか否かが判断される。

ステップ２０４の判断の結果、復帰カウンタの値が閾値Ｎに達していないと判断された場合、ここで、大阪事業所の音声データ（受信休止データ）についての処理を終了し、再び、ステップ２０１に戻る。ステップ２０１では、２番目に優先度の高い受信休止データ（大阪事業所の画像データ）につき、その原因データ（ニューヨーク事業所の画像データ）を特定し、その最終出力時刻からの経過時間が第２の閾値Ｔ_２未満であるか否かを判断する（ステップ２０２）。

同じく、ニューヨーク事業所の画像が高品質に維持されているこの時点では、経過時間が閾値Ｔ_２未満であると判断され（ステップ２０２、Ｙｅｓ）、続くステップ２０３で、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが１増加された後、当該復帰カウンタの値が閾値Ｎに達したか否かが判断される。

ステップ２０４の判断の結果、復帰カウンタの値が閾値Ｎに達していないと判断された場合、大阪事業所の画像データ（受信休止データ）についての処理を終了する。この時点で、全ての受信休止データについて処理が終了したことになるので、第２のループ処理（ステップ２００）を終了する。

第２のループ処理（ステップ２００）が終了すると、次のタイミングを待って、再び、第１のループ処理（ステップ１００）が開始し、それ以降、上述した処理が繰り返される。

以上の説明から、ニューヨーク事業所の画像の画質が十分に改善してから、第２のループ処理（ステップ２００）におけるステップ２０３がＮ回繰り返されるまでの間、受信データ管理テーブル１６が図２２（ｇ）に示す状態に維持されることが理解されるであろう。

つまり、本実施形態においては、動作の安定性に鑑みて、優先データの出力状態が改善した時点で直ちに受信休止データの受信を再開するのではなく、優先データの良好な出力状態が所定時間以上継続するのを待って、受信休止データの受信を再開する。したがって、ステップ２０４の判断において参照される閾値Ｎは、この動作安定性の目的に応じた適切な値を定義することが望ましい。

原因データ（ニューヨーク事業所の画像データ）につき、第２のループ処理（ステップ２００）のステップ２０３がＮ回繰り返された後のステップ２０４では、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタの値が閾値Ｎに達したと判断され（ステップ２０４、Ｙｅｓ）、処理はステップ２０５に進む。

ステップ２０５では、カウンタ値が閾値Ｎに達した復帰カウンタに対応する原因データ（すなわち、ニューヨーク事業所の音声データ）のために、現在、受信を休止している受信休止データの中から、最も優先度の高いデータを選択する。ここで、受信データ管理テーブル１６が図２２（ｇ）に示す状態にあった場合、ステップ２０５では、“受信状態”が“受信休止”となっているデータのうち、優先度４の大阪事業所の音声データのデータＩＤ”OS0031A”が抽出される。

続くステップ２０６では、選択した受信休止データの受信再開処理を実行する。具体的には、ステップ２０５で抽出したデータＩＤ“OS0031A”を含む“送信再開要求”を生成し、これを中継装置３０ａに発行した後、受信データ管理テーブル１６を図２２（ｈ）に示す状態に更新する。すなわち、データＩＤ“OS0031A”に対応する“受信状態”フィールドの値を“受信休止”から“受信要”に変更するとともに、データＩＤ“OS0031A”に対応する“受信休止原因”フィールドにセットされていた値“NY0011V”を削除する。

このとき、東京事業所の端末装置１０ａのデータ受信制御部１２から送信再開要求を受領した中継装置３０ａは、中継データ管理テーブル３６を図２１（ｅ）に示すように更新する。具体的には、中継装置３０ａは、受領した送信再開要求に含まれるデータＩＤ“OS0031A”をキーとして中継データ管理テーブル３６の“中継データＩＤ”フィールドを検索し、“OS0031A”に対応する“送信状態“フィールドの値を”送信不可“から”送信可“に更新する。中継データ管理テーブル３６が図２１（ｅ）のように更新されて以降、中継装置３０ａの中継制御部３２は、東京事業所の端末装置１０ａを宛先とする大阪事業所の音声データ(ID=OS0031A)の端末装置１０ａへの転送を再開する。

続くステップ２０７では、カウンタ値が閾値Ｎに達した原因データ（ニューヨーク事業所の画像データ）の復帰カウンタを０クリアする。この時点で、大阪事業所の音声データ（受信休止データ）についての処理が終了し、処理は、ステップ２０１に戻る。

ステップ２０１では、２番目に優先度の高い受信休止データ（大阪事業所の画像データ）につき、その原因データ（ニューヨーク事業所の画像データ）を特定し、その最終出力時刻からの経過時間が第２の閾値Ｔ_２未満であるか否かを判断する（ステップ２０２）。

同じく、ニューヨーク事業所の画像が高品質に維持されているこの時点では、経過時間が閾値Ｔ_２未満であると判断され（ステップ２０２、Ｙｅｓ）、続くステップ２０３で、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが１増加された後、当該復帰カウンタの値が閾値Ｎに達したか否かが判断される。

ここで、大阪事業所の音声データ（受信休止データ）について実施された前回のステップ２０７において、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタが０クリアされたので、この時点の復帰カウンタの値＝１となる。その結果、ステップ２０４では、閾値Ｎに達していないと判断される（ステップ２０４、Ｎｏ）。この時点で、大阪事業所の音声データ（受信休止データ）についての処理が終了し、第２のループ処理（ステップ２００）が終了する。

第２のループ処理（ステップ２００）が終了すると、次のタイミングを待って、再び、第１のループ処理（ステップ１００）が開始し、それ以降、上述した処理が繰り返される。

このように、上述した図１９では第１のループ処理（ステップ１００）について定期的に実施する方法を例にあげた。この方法以外に、優先度の高いデータをユーザに対して出力（映像であればレンダリング、音声ならスピーカー出力）するタイミングで実施する方法であってもよい。例えば、第１のループ処理（ステップ１００）において、出力した高優先度の受信中データ（これをデータＡとする）について、ステップＳ１０１〜Ｓ１０４の処理を実行する。上記データＡについて第１のループ処理を実行した後、データＡの最終出力時刻を現在値に更新して、第２のループ処理に移行する。

第１のループ処理例では、定期間隔でのチェックのみの場合には「閾値にすこしだけ遅れてデータを出力できた場合」に検出されないことが考えられる。このため、上述したように監視対象のデータを出力するたびに、最終出力時刻の更新“前”に定期チェックと同じ処理を実行する。これにより例えばブラックアウト判定の閾値が３秒に対して４秒でデータを出力できたという“状況悪化の兆候”で制御を働かせることができる。

以上の説明から、優先度４の受信休止データ（大阪事業所の音声データ）の受信が再開してから、第２のループ処理（ステップ２００）におけるステップ２０３がＮ回繰り返されるまでの間、受信データ管理テーブル１６が図２２（ｈ）に示す状態に維持されることが理解されるであろう。

つまり、本実施形態においては、動作の安定性に鑑みて、優先データの出力状態が改善した時点で直ちに、これを原因データとする全ての受信休止データの受信を一斉に再開するのではなく、１つの受信休止データの受信を再開した後に優先データの良好な出力状態が所定時間以上継続するのを待って、次の受信休止データの受信を再開する。

原因データ（ニューヨーク事業所の画像データ）につき、第２のループ処理（ステップ２００）のステップ２０３が、再度、Ｎ回繰り返された後のステップ２０４では、原因データ（ニューヨーク事業所の画像データ）の復帰カウンタの値が閾値Ｎに達したと判断され（ステップ２０４、Ｙｅｓ）、処理はステップ２０５に進む。

ステップ２０５では、カウンタ値が閾値Ｎに達した復帰カウンタに対応する原因データ（すなわち、ニューヨーク事業所の音声データ）のために、現在、受信を休止している受信休止データの中から、最も優先度の高いデータを選択する。ここで、受信データ管理テーブル１６が図２２（ｈ）に示す状態にあった場合、ステップ２０５では、“受信状態”が“受信休止”となっている優先度５の大阪事業所の画像データのデータＩＤ”OS0032V”が抽出される。

続くステップ２０６では、選択した受信休止データの受信再開処理を実行する。具体的には、ステップ２０５で抽出したデータＩＤ”OS0032V”を含む“送信再開要求”を生成し、これを中継装置３０ａに発行した後、受信データ管理テーブル１６を図２２（ｉ）に示す状態に更新する。すなわち、データＩＤ”OS0032V”に対応する“受信状態”フィールドの値を“受信休止”から“受信要”に変更するとともに、データＩＤ”OS0032V”に対応する“受信休止原因”フィールドにセットされていた値“NY0011V”を削除する。

このとき、東京事業所の端末装置１０ａのデータ受信制御部１２から送信再開要求を受領した中継装置３０ａは、中継データ管理テーブル３６を図２１（ｆ）に示すように更新する。具体的には、中継装置３０ａは、受領した送信再開要求に含まれるデータＩＤ“OS0032V”をキーとして中継データ管理テーブル３６の“中継データＩＤ”フィールドを検索し、“OS0032V”に対応する“送信状態“フィールドの値を”送信不可“から”送信可“に更新する。中継データ管理テーブル３６が図２１（ｆ）のように更新されて以降、中継装置３０ａの中継制御部３２は、東京事業所の端末装置１０ａを宛先とする大阪事業所の画像データ(ID=OS0032V)の端末装置１０ａへの転送を再開する。

以上、説明したように、本発明によれば、出力品質の劣化が伝送遅延または内部処理遅延あるいはこれらの複合に依るものであったとしても、優先順位の高いデータに係る出力をできる限り品質の高い状態で維持することが可能になる。

なお、上述した実施形態の各機能は、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）などで記述された装置実行可能なプログラムにより実現でき、本実施形態のプログラムは、ハードディスク装置、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、フレキシブルディスク、ＥＥＰＲＯＭ、ＥＰＲＯＭなどの装置可読な記録媒体に格納して頒布することができ、また他装置が可能な形式で通信ネットワークを介して伝送することができる。

以上、本発明について、遠隔会議システムの実施形態に基づいて説明してきたが、本発明は上述した実施形態に限定されるものではなく、本発明は、通信ネットワークを介して端末装置に複数のコンテンツデータを同時に伝送することを内容とするデータ伝送システムであれば、その用途を問わず、どのようなシステムにも適用することができる。また、その場合、端末装置は、その用途に応じて、スマートフォン、汎用ＰＣ、タブレット型端末、携帯電話、電子黒板、プロジェクタ等の投影装置、自動車に搭載されるカーナビゲーション端末などで構成することができる。その他、当業者が推考しうる実施態様の範囲内において、本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１ 遠隔会議システム
２ａ,２ｂ,２ｃ,２ｄ ＬＡＮ
２ａｂ,２ｃｄ 専用線
１０ 端末装置
１２ データ受信制御部
１３ 受信優先順位管理部
１４ 最終出力時刻更新部
１５ 送受信部
１６ 受信データ管理テーブル
３０ 中継装置
３２ 中継制御部
３６ 中継データ管理テーブル
５０ 伝送管理装置
７０ ルータ
８０ インターネット
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ フラッシュメモリ
１０５ ＳＳＤ
１０６ 記録メディア
１０７ メディアドライブ
１０８ 操作ボタン
１０９ 電源スイッチ
１１０ バスライン
１１２ カメラ
１１４ マイク
１１５ スピーカー
１１９ アラームランプ
１２０ ディスプレイ
１２０ｃ ケーブル
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０５ ＨＤＤ
２０６ 記録メディア
２０７ メディアドライブ
２０８ ディスプレイ
２１０ バスライン
２１１ キーボード
２１２ マウス
２１３ ＣＤ−ＲＯＭ
２１４ ＣＤ−ＲＯＭドライブ
１１００ 筐体
１１１０ 前側壁面
１１２０ 後側壁面
１１２１ 排気面
１１３０ 右側壁面
１１３１ 収音用孔
１１４０ 左側壁面
１１５０ 操作パネル
１１５１ 音出面
１１６０ 収容部
１２００ アーム
１２１０ トルクヒンジ
１３００ カメラハウジング
１３１０ トルクヒンジ

特開２０１０―０９３５０５号公報

Claims (17)

1. コンテンツデータを送信または受信する複数の端末装置が通信ネットワーク上に配置されてなるデータ伝送システムであって、
   前記複数の端末装置のうち、他の端末装置から送信されたコンテンツデータを受信する少なくとも１つの端末装置は、
   自身を宛先とする２以上のコンテンツデータの優先順位を管理する受信優先順位管理部と、
   受信中の２以上のコンテンツデータのうち、前記受信優先順位管理部によって管理される優先順位が高い優先データに対応する出力信号の出力時間間隔に基づいて、前記優先データよりも優先順位が低いコンテンツデータの送信を止めるように制御する旨を当該優先順位が低いコンテンツデータを送信する送信元に対して要求するデータ受信制御部と、
   を備えることを特徴とするデータ伝送システム。
2. 前記複数の端末装置間で送信または受信される２以上のコンテンツデータを中継する中継装置をさらに備えることを特徴とする請求項１に記載のデータ伝送システム。
3. データ受信制御部は、
   受信中の２以上のコンテンツデータのうち、優先順位が高い優先データに対応する出力信号の出力時間間隔が第１の閾値を超えた場合に、最も優先順位が低いコンテンツデータの送信を止めるように制御する旨を中継装置に対して要求する、
   ことを特徴とする請求項１に記載のデータ伝送システム。
4. 前記データ受信制御部は、
   前記優先データの前記出力時間間隔が前記第１の閾値よりも小さい第２の閾値未満になった場合に、送信休止を要求した前記コンテンツデータの送信再開を前記中継装置に対して要求する、
   ことを特徴とする請求項３に記載のデータ伝送システム。
5. 前記データ受信制御部は、
   前記優先データの前記出力時間間隔が前記第２の閾値未満の状態が所定時間以上継続するのを待って前記送信再開を要求する、
   ことを特徴とする請求項４に記載のデータ伝送システム。
6. 前記データ受信制御部は、
   送信休止を要求した２以上の前記コンテンツデータのうち、優先順位が高いコンテンツデータから順番に前記送信再開を要求する、
   ことを特徴とする請求項４に記載のデータ伝送システム。
7. 前記データ受信制御部は、
   前記優先順位の高いコンテンツデータの受信が再開した後、前記優先データの前記出力時間間隔が前記第２の閾値未満の状態が所定時間以上継続するのを待って、該コンテンツデータに次いで優先順位が高いコンテンツデータの前記送信再開を要求する、
   ことを特徴とする請求項６に記載のデータ伝送システム。
8. 前記コンテンツデータは、音声データまたは画像データの少なくとも一方を含むことを特徴とする請求項１に記載のデータ伝送システム。
9. 通信ネットワーク上にコンテンツデータを送信または受信する複数の端末装置が配置され、
   前記複数の端末装置のうち、他の端末装置から送信されたコンテンツデータを受信する少なくとも１つの端末装置は、
   自身を宛先とする２以上のコンテンツデータの優先順位を管理する受信優先順位管理部と、
   受信中の２以上のコンテンツデータのうち、前記受信優先順位管理部によって管理される優先順位が高い優先データに対応する出力信号の出力時間間隔に基づいて、前記優先データよりも優先順位が低いコンテンツデータの送信を止めるように制御する旨を当該優先順位が低いコンテンツデータを送信する送信元に対して要求するデータ受信制御部と、
   を備えることを特徴とする端末装置。
10. コンテンツデータを送信または受信する複数の端末装置が通信ネットワーク上に配置されてなるコンピュータであって、
    前記複数の端末装置のうち、他の端末装置から送信されたコンテンツデータを受信する少なくとも１つの端末装置を、
    自身を宛先とする２以上のコンテンツデータの優先順位を管理する受信優先順位管理ステップと、
    受信中の２以上のコンテンツデータのうち、前記受信優先順位管理ステップによって管理される優先順位が高い優先データに対応する出力信号の出力時間間隔に基づいて、前記優先データよりも優先順位が低いコンテンツデータの送信を止めるように制御する旨を当該優先順位が低いコンテンツデータを送信する送信元に対して要求するデータ受信制御ステップと、
    を前記コンピュータに実行させるためのプログラム。
11. データ受信制御ステップは、
    受信中の２以上のコンテンツデータのうち、優先順位が高い優先データに対応する出力信号の出力時間間隔が第１の閾値を超えた場合に、最も優先順位が低いコンテンツデータの送信を止めるように制御する旨を該コンテンツデータの送信元に対して要求する、
    請求項１０に記載のプログラム。
12. 前記データ受信制御ステップは、
    前記優先データの前記出力時間間隔が前記第１の閾値よりも小さい第２の閾値未満になった場合に、送信休止を要求した前記コンテンツデータの送信再開を前記送信元に対して要求する、
    請求項１１に記載のプログラム。
13. 前記データ受信制御ステップは、
    前記優先データの前記出力時間間隔が前記第２の閾値未満の状態が所定時間以上継続するのを待って前記送信再開を要求する、
    請求項１２に記載のプログラム。
14. 前記データ受信制御ステップは、
    送信休止を要求した２以上の前記コンテンツデータのうち、優先順位が高いコンテンツデータから順番に前記送信再開を要求する、
    請求項１２に記載のプログラム。
15. 前記データ受信制御ステップは、
    前記優先順位の高いコンテンツデータの受信が再開した後、前記優先データの前記出力時間間隔が前記第２の閾値未満の状態が所定時間以上継続するのを待って、該コンテンツデータに次いで優先順位が高いコンテンツデータの前記送信再開を要求する、
    請求項１４に記載のプログラム。
16. 前記コンテンツデータは、音声データまたは画像データの少なくとも一方を含む、請求項１０に記載のプログラム。
17. 通信ネットワークを介して外部から送信される２以上のコンテンツデータの受信状態を制御するデータ伝送方法であって、
    自身を宛先とする２以上のコンテンツデータの優先順位を管理する受信優先順位管理工程と、
    受信中の２以上のコンテンツデータのうち、前記受信優先順位管理工程によって管理される優先順位が高い優先データに対応する出力信号の出力時間間隔に基づいて、前記優先データよりも優先順位が低いコンテンツデータの送信を止めるように制御する旨を当該優先順位が低いコンテンツデータを送信する送信元に対して要求するデータ受信制御工程と、
    を含むことを特徴とするデータ伝送方法。

Images