(57)【要約】【課題】通信帯域が混雑している場合でも高解像映像を通信するための通信帯域を確保する。【解決手段】  本実施形態の映像通信サーバは、接続部と、帯域制御部と、送信部を備える。接続部は、ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする。帯域制御部は、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する。送信部は、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する。【選択図】図４
2020048052.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする接続部と、
前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する帯域制御部と、
前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する送信部と、
を備える映像通信サーバ。
【請求項２】
前記帯域制御部は、第１宛先端末への映像データの通信帯域を拡大する場合に、前記第１宛先端末の優先度より低い優先度を有する第２宛先端末が使用している通信帯域を縮小し、縮小した分の通信帯域を前記第１宛先端末に割り当てる請求項１に記載の映像通信サーバ。
【請求項３】
前記送信部が、指定した大きさを有する通信帯域を他の映像通信サーバが融通することが可能であるかどうかの回答を前記他の映像通信サーバへ依頼する依頼データを送信し、
前記帯域制御部が、融通することが可能である場合には可能である回答信号を前記他の映像通信サーバから受け付け、前記通信帯域を制御する、請求項１に記載の映像通信サーバ。
【請求項４】
前記映像データに関する属性情報を含む属性データを、前記ネットワークを経由して取得する取得部と、
前記属性データに基づいて前記映像データに対応する第１宛先端末に第１映像データを送信するために必要な第１通信帯域を算出する第１算出部と、
前記第１宛先端末の優先度が前記第１通信帯域を許容するかどうかを判定する判定部と、をさらに備え、
前記判定部が前記第１通信帯域を許容すると判定した場合に、前記帯域制御部が前記第１宛先端末用に前記第１通信帯域を確保し、他の宛先端末の映像データは前記第１通信帯域以外に割り当てる、請求項１乃至３のいずれか１項に記載の映像通信サーバ。
【請求項５】
前記第１映像データの属性データと前記第１通信帯域とに応じて、前記第１宛先端末に前記第１映像データの送信が完了する送信完了時刻を算出する第２算出部をさらに備え、
前記送信部は、前記送信完了時刻を含む完了時刻データを前記宛先端末に送信する、請求項４に記載の映像通信サーバ。
【請求項６】
前記接続部はリアルタイムで前記映像データを送信可能にし、
前記判定部が前記第１通信帯域を許容すると判定した場合に、前記接続部は、前記映像データの送信を不可能にし、前記複数の映像ソースのうちの少なくとも１つと宛先端末との間を接続し、前記第１映像データを送信可能にし、
前記送信部は、前記第１通信帯域を使用して、前記第１映像データを前記第１宛先端末に送信する、請求項４または５に記載の映像通信サーバ。
【請求項７】
前記第１映像データは、既に記録されている映像データである、請求項４に記載の映像通信サーバ。
【請求項８】
前記取得部は、前記属性情報として、映像データのデータ量、映像データの宛先端末情報、映像再生時間、及びリアルタイム映像であるか過去の映像であるかを示す映像識別情報、のうちの少なくとも１以上を含む、請求項４乃至７のいずれか１項に記載の映像通信サーバ。
【請求項９】
ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする接続部と、
高いほど広い通信帯域を使用可能であり映像通信サーバに対応づけて設定される優先度に応じて映像通信サーバごとの通信帯域を制御する帯域制御部と、
前記複数の映像データのそれぞれに対応する宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する送信部と、
を備える映像通信サーバ。
【請求項１０】
前記帯域制御部は、第１宛先端末への映像データの第１通信帯域を拡大する場合に、前記第１通信帯域を提供している第１映像通信サーバの優先度より低い優先度の第２映像通信サーバが使用している通信帯域を縮小するように指示し、縮小した分の通信帯域を、第１映像通信サーバを経由する前記第１宛先端末に割り当てる請求項９に記載の映像通信サーバ。
【請求項１１】
前記映像データは、ＷｅｂＲＴＣ方式に適合した映像データである、請求項１乃至１０のいずれか１項に記載の映像通信サーバ。
【請求項１２】
映像データをそれぞれ出力する複数の映像ソースと複数の宛先端末とをネットワークを経由して常時接続するための第１映像通信サーバ及び第２映像通信サーバを備えるシステムにおいて、
前記第１映像通信サーバは、
映像データの送信用に第１通信帯域に通信帯域を拡大する場合に、第１映像通信サーバで前記第１通信帯域を確保することができるかどうかを判定する第１判定部と、
前記第１判定部が前記第１通信帯域を確保することができないと判定した場合には、第２映像通信サーバが前記第１通信帯域を融通することが可能であるかどうかの回答を、前記第２映像通信サーバへ依頼する依頼データを送信する送信部と、を備え、
前記第２映像通信サーバは、
前記依頼データを受信し、前記第１通信帯域を融通することが可能であるかどうかを判定する第２判定部と、
前記第２判定部が前記第１通信帯域を融通することが可能であると判定した場合に、前記第１通信帯域を融通することが可能である回答信号を前記第１映像通信サーバへ送信し、前記第１通信帯域を開放する帯域制御部と、
前記第１映像通信サーバは、
前記回答信号を受信し、前記第１通信帯域を確保する帯域制御部をさらに備える、システム。
【請求項１３】
映像データをそれぞれ出力する複数の映像ソースと複数の宛先端末とをネットワークを経由して常時接続し、高いほど広い通信帯域を使用可能である優先度を付与された第１映像通信サーバ及び第２映像通信サーバを備えるシステムにおいて、
前記第１映像通信サーバは、
映像データの送信用に第１通信帯域に通信帯域を拡大する場合に、第１映像通信サーバで前記第１通信帯域を確保することができるかどうかを判定する第１判定部と、
前記第１判定部が前記第１通信帯域を確保することができないと判定した場合には、前記第１通信帯域を融通することと第１映像通信サーバの優先度とを含む依頼データを前記第２映像通信サーバへ送信する送信部と、を備え、
前記第２映像通信サーバは、
前記依頼データを受信し、前記第１映像通信サーバの優先度が前記第２映像通信サーバの優先度より高いかどうかを判定する第２判定部と、
前記第１映像通信サーバの優先度が前記第２映像通信サーバの優先度より高いと判定した場合に、前記第１通信帯域を融通することが可能である回答信号を前記第１映像通信サーバへ送信し、前記第１通信帯域を開放する帯域制御部と、
前記第１映像通信サーバは、
前記回答信号を受信し、前記第１通信帯域を確保する帯域制御部をさらに備える、システム。
【請求項１４】
ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にし、
前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御し、
前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信すること、
を備える映像通信方法。
【請求項１５】
コンピュータを、請求項１乃至１１のいずれか１項に記載の映像通信サーバが備える各部として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、映像通信サーバ、システム、方法及びプログラムに関する。
【背景技術】
【０００２】
近年、例えば、店舗内に設置したカメラを使用した監視システムでは、ネットワークを使用する映像通信システムが利用される。映像通信システムは、カメラにより撮影された映像をネットワーク経由で監視システムの端末装置に送信する。監視システムの端末装置は、一般的には、ネットワークに接続されたパーソナルコンピュータ（ＰＣ）であり、当該ＰＣのＷｅｂブラウザ上で映像を受信できる。また、映像通信システムは、映像だけでなく、マイクから入力された音声もネットワーク経由で送信できる。
【０００３】
監視システムでは、監視管理者等のユーザが確実に、ＰＣのＷｅｂブラウザで受信した映像をディスプレイの画面上で確認し、受信した音声をＰＣのスピーカで聴取できることが必要である。このような確実な監視処理を実現するためには、監視システムに適用する映像通信システムにおいては、映像を安定的に送信するための映像通信の帯域の確保と長時間のセッションの確保が要求される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−８２４１９号公報
【特許文献２】特表２０１６−５１７６４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
監視システム等に適用する映像通信システムには、映像を安定的に送信するための映像通信の帯域の確保と長時間のセッションの確保が要求されるため、映像や音声を送信するための専用回線や、専用の映像再生用のソフトウェアが実装されることが望ましい。しかし、いわば監視処理専用のような映像通信システムを利用する場合には、監視システムの構築に高いコストが要求される。近年では、ネットワーク上において、リアルタイムでの映像通信（音声通信も含む）が可能なＷｅｂＲＴＣ方式等を適用した映像通信システムが注目されている。しかし、この映像通信システムを監視システム等に適用することは容易ではない。
【０００６】
このように、ＷｅｂＲＴＣ方式等を適用した映像通信システムは、専用回線や専用の映像再生用のソフトウェアを使用することなく、監視システム等に適用可能である。
【０００７】
しかしながら、ネットワークを使用して、高解像度の映像データを通信する必要が生じたときに、通信帯域が混雑していて高解像映像を通信するための通信帯域の確保ができない場合がある。特に、重要かつ緊急性のある映像データを管理者等の端末装置へ急遽送信しなければならなくなった場合に、このような映像データがいつでも必ず管理者等の端末装置に送信されることが保証されているかどうかは非常に重要な問題である。さらに、このような映像データがリアルタイム映像データでなく過去の映像データである場合には、この映像データのダウンロードをできるだけ早急に完了することも重要である。
【０００８】
本発明が解決しようとする課題は、通信帯域が混雑している場合でも高解像映像を通信するための通信帯域を確保することができる映像通信サーバ、システム、方法及びプログラムを提供することである。
【課題を解決するための手段】
【０００９】
本実施形態の映像通信サーバは、接続部と、帯域制御部と、送信部を備える。接続部は、ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする。帯域制御部は、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する。送信部は、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する。
【図面の簡単な説明】
【００１０】
【図１】実施形態に係る映像通信システムの構成を説明するためのブロック図。
【図２】図１に示すシステムのうち、１つの映像ソースと、複数のＷｅｂＲＴＣサーバと、１つの宛先端末とを示す図。
【図３】図２に示す映像通信サーバのハードウェアの構成の一例を示すブロック図。
【図４】図３に示す制御部のソフトウェアの構成の一例を示すブロック図。
【図５】実施形態に係る映像通信システム内の動作の一例を示すシーケンス図。
【図６】実施形態に係る映像通信サーバが通信帯域を確保するための動作の一例を示すフローチャート。
【図７】実施形態に係る映像通信サーバが映像送信完了時刻を宛先端末へ送信する動作の一例を示すフローチャート。
【図８】実施形態に係る映像通信システム内の、図５とは異なる動作の一例を示すシーケンス図。
【図９】実施形態に係る映像通信サーバが通信帯域を確保するための図８に対応した動作の一例を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、本発明の一側面に係る実施の形態（以下、「本実施形態」とも表記する）を、図面に基づいて説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
【００１２】
［システムの構成］  
まず、図１を参照して、実施形態に係る映像通信サーバが適用されるシステム全体について説明する。図１は、映像及び／または音声を取得して映像データを作成及び／または蓄積している映像ソース１０１、本実施形態に係るＷｅｂＲＴＣ（Web-based real-time communication）サーバ１０３、ＷｅｂＲＴＣサーバ１０３を経由して映像データを受信する宛先端末１０４の適用場面の一例を示す。ＷｅｂＲＴＣサーバ１０３で採用されているＷｅｂＲＴＣ方式（「ＷｅｂＲＴＣプロトコル」とも称することがある）は、Ｗｅｂを使用してリアルタイムなコミュニケーションをやり取りする技術である。例えば、ＷｅｂＲＴＣ方式を使用すれば、リアルタイムな映像を送信することができる。
【００１３】
ＷｅｂＲＴＣサーバ１０３は、ネットワーク１０２を経由して、特定の映像ソース１０１と特定の宛先端末１０４との間にセッションを確立し、この映像ソース１０１とこの宛先端末１０４との間を常時接続し、映像ソース１０１から宛先端末１０４への通信帯域を確保して、映像通信及びデータ通信を可能にする。また、ＷｅｂＲＴＣ方式には一般的に、メディアチャネルと、データチャネルとがある。メディアチャネルは、映像と音声のデータ通信方式を示し、このチャネルではリアルタイムに映像データや音声データを送信するプロトコルが採用されている。データチャネルは、任意のデータを送信することができる通信方式を示し、低遅延で文字列やバイナリデータ（映像データ以外のデータ）を送信する。また、ＷｅｂＲＴＣサーバ１０３は、映像ソース１０１と宛先端末１０４との間で常時接続する際に、シグナリング処理を行い、この処理を受けて映像ソース１０１と宛先端末１０４との間にセッションが確立される。本実施形態では、ＷｅｂＲＴＣ方式に適合している映像データを扱う。
【００１４】
ネットワーク１０２は、複数の映像ソース１０１、複数のＷｅｂＲＴＣサーバ１０３、複数の宛先端末１０４に接続し、それぞれの通信を仲介する。
【００１５】
映像ソース１０１は、動画像及び静止画像（以下まとめて「映像」とも称す）を撮影することができるビデオカメラと、撮影した動画像及び静止画像を記憶するレコーダと、これらから動画像データ及び静止画像データをネットワーク１０２と通信するための中継装置とを備えている。ビデオカメラは、例えば、マイクを付属し音声情報も取得する。ここでは、音声データは映像データに含まれてもよいとする。すなわち、本実施形態では、送受信する映像には音声も含まれてもよい。
【００１６】
宛先端末１０４は、ネットワーク１０２との間で通信可能な一般的なコンピュータであり、例えば、パーソナルコンピュータ、スマートフォン、スマートウォッチ等、ブラウザを有してネットワーク１０２に接続可能な端末である。
【００１７】
次に、図２を参照して、映像ソース１０１と宛先端末１０４とについて主に説明する。図２は、本実施形態に係る図１に示すシステムのうち、１つの映像ソースと、複数のＷｅｂＲＴＣサーバと、１つの宛先端末とを示す。図１に示すように、本実施形態の映像通信システムは、例えば、監視システムに適用し、ＷｅｂＲＴＣサーバ１０３、及びインターネット等のネットワーク１０２を主要部として映像データ及び制御データ等を送受信する。
【００１８】
ネットワーク１０２には、監視対象側（ここでは、映像ソース１０１）の中継装置２０１と、管理側（ここでは、宛先端末１０４）のクライアント端末２５１と、が接続される。
【００１９】
監視対象側（映像ソース１０１）は、例えばコンビニエンスストアなどの店舗であり、監視システムを構成する複数のビデオカメラ２０２、ビデオレコーダ２０３及びアラーム装置２０４を有する。なお、監視対象側（映像ソース１０１）は、本実施形態では店舗の内部エリアとするが、各種の建物や施設等としてもよく、適用範囲は任意である。また、アラーム装置２０４は例えば、警報用のボタン２０５やペダル２０６を備える。
【００２０】
管理側（ここでは、宛先端末１０４）は、例えば店舗を運営する管理者の事務所や自宅等であり、クライアント端末２５１、及び／またはモバイル端末２５２を有する。クライアント端末２５１は、例えば、パーソナルコンピュータ（ＰＣ）であり、ネットワーク１０２に接続し、ＷｅｂＲＴＣサーバ１０３との連携により、監視対象側（映像ソース１０１）から送信される映像を受信する。モバイル端末２５２は、ネットワーク１０２とは無線通信を確立することがクライアント端末２５１とは異なるが、実行する動作はクライアント端末２５１と本質的に同様である。宛先端末１０４が受信する映像データは、複数のビデオカメラ２０２から受け取ったものであり、クライアント端末２５１またはモバイル端末２５２の画面がビデオカメラ２０２の数に応じて４分割または８分割等されて、映像が端末の画面に表示されてもよい。
【００２１】
複数のビデオカメラ２０２はそれぞれ、店舗内の各監視エリアを撮影できる箇所に配置されて、撮影した映像を有線または無線経由で映像データとして出力する。なお、図示していないが、ビデオカメラ２０２や店舗内のレジスタの近傍に配置されたマイクや、ビデオカメラ２０２に内蔵されたマイクから、映像と共に音声も有線または無線経由で映像データに含め出力される。
【００２２】
ビデオレコーダ２０３は、ビデオカメラ２０２から出力された映像を記録（録画及び録音）する記憶装置であり、例えばハードディスクドライブ、またはソリッドステートドライブを有する。ビデオレコーダ２０３は、主に過去に撮影され記録された映像データを記憶している。この過去の映像データは、通常、高解像度の映像（「高精細な映像」とも称す）を含むデータであり、宛先端末１０４からのリクエストまたはＷｅｂＲＴＣサーバ１０３からのリクエスト、またはアラーム装置２０４のリクエストによって要求される。この本実施形態のビデオレコーダ２０３は、いわゆるサーバ機能を含み、ビデオカメラ２０２から出力された映像データを、中継装置２０１を経由してネットワーク１０２に送信することができる。具体的には、ビデオレコーダ２０３は、ビデオカメラ２０２により撮影された映像のライブ送信（例えば、ＷｅｂＲＴＣ方式を使用）を実行することができ、または、記憶されている映像データから所望の映像データ（典型的には、高解像映像データ）を取り出して送信することができる。
【００２３】
アラーム装置２０４は、中継装置２０１からネットワーク１０２を経由して、ＷｅｂＲＴＣサーバ１０３に対してアラーム通知を実行する。アラーム装置２０４は、例えば、店舗内のレジスタの近傍に配置された警報用のボタン２０５やペダル２０６の操作に応じて、緊急時または非常時におけるアラーム（警報）信号を出力して、ＷｅｂＲＴＣサーバ１０３へ（すなわち、対応する宛先端末１０４へ）アラーム通知を実行する。
【００２４】
なお、アラーム装置２０４は、ビデオカメラ２０２により撮影された映像に基づいて異常検知した場合に、アラーム信号を出力する構成でもよい。具体的には、アラーム装置２０４は、通常では、特定エリアでのビデオカメラ２０２により撮影される映像には変化が発生しない状況において、当該特定エリアでの映像に変化が発生した場合には、異常が発生したと検知する。例えば、通常では当該特定エリアが人の存在しないエリアの場合に、ビデオカメラ２０２により撮影される映像に人が含まれている場合には、異常が発生したと検知する。この異常検知は、ソフトウェアでも実現することができるので、アラーム装置２０４以外に、ＷｅｂＲＴＣサーバ１０３及び／または宛先端末１０４で実行されることも可能である。異常検知は、アラーム装置２０４、ＷｅｂＲＴＣサーバ１０３、及び宛先端末１０４のうちの少なくとも２つに基づいて総合的に異常であるかどうかを判定してもよい。
【００２５】
また、本実施形態では、店舗等の監視対象側（映像ソース１０１）でのアラームの発報に応じて、ＷｅｂＲＴＣ方式等の映像通信接続を自動的に実行する構成であるが、アラームの発報に限定することなく、所定のイベントの発生に応じて、通信接続を自動的に実行する構成でもよい。
【００２６】
以下、具体的に異常検知の一例を示す。  
監視対象側（映像ソース１０１）において、店舗内の緊急時に、担当者により警報用のボタン２０５またはペダル２０６が操作されてアラーム発報があると、アラーム装置２０４はアラーム信号を出力する。アラーム装置２０４からのアラーム信号は中継装置２０１によりネットワーク１０２に送信されて、ＷｅｂＲＴＣサーバ１０３に対してアラーム通知が実行される。監視対象側（映像ソース１０１）において、店舗内の緊急時に、担当者により警報用のボタン２０５またはペダル２０６が操作されてアラーム発報があると、アラーム装置２０４はアラーム信号を出力する。アラーム装置２０４からのアラーム信号は中継装置２０１によりネットワーク１０２に送信されて、ＷｅｂＲＴＣサーバ１０３に対してアラーム通知が実行される。
【００２７】
ＷｅｂＲＴＣサーバ１０３は、このアラーム通知を受信すると、予め登録されている管理側（宛先端末１０４）のクライアント端末２５１に対して、自動接続処理を実行する。すなわち、ＷｅｂＲＴＣサーバ１０３は、クライアント端末２５１のブラウザを起動させて、ネットワーク１０２を経由するＷｅｂＲＴＣ方式の通信接続処理を実行する。ＷｅｂＲＴＣサーバ１０３の自動接続処理により、クライアント端末２５１に対するＷｅｂＲＴＣ方式の通信接続が確保されると、セッションが確保されて、ＷｅｂＲＴＣ方式のリアルタイムな映像通信が可能となる。これにより、監視対象側（映像ソース１０１）のビデオレコーダ２０３は、中継装置２０１及びネットワーク１０２を経由して、クライアント端末２５１に対して映像をリアルタイムに送信できる。
【００２８】
また、ＷｅｂＲＴＣサーバ１０３は、選択したモバイル端末２５２に対して、自動接続処理を実行することもできる。すなわち、上記のクライアント端末２５１の場合と同様な動作によってモバイル端末２５２は、監視対象側（映像ソース１０１）のビデオレコーダ２０３から、中継装置２０１及びネットワーク１０２を経由して、映像データをリアルタイムに受信することができる。
【００２９】
クライアント端末２５１は、例えば、ＷｅｂＲＴＣサーバ１０３からダウンロードされて、ＷｅｂＲＴＣ方式により、ネットワーク１０２に接続してリアルタイムな映像及び／または音声の通信を可能とするソフトウェアがインストールされている。なお、クライアント端末２５１は、予めブラウザに当該ソフトウェアが実装されている構成でもよい。クライアント端末２５１は、ネットワーク１０２を経由して、監視対象側（映像ソース１０１）からＷｅｂＲＴＣ方式によりリアルタイムで送信される映像を、Ｗｅｂブラウザ（以下「ブラウザ」と称す）で受信し、ディスプレイの画面上で再生することができる。
【００３０】
モバイル端末２５２は、スマートフォンを代表とする携帯端末であり、クライアント端末２５１と同様のソフトウェアがインストールされている。管理者は、モバイル端末２５２を操作することにより、クライアント端末２５１と同様に、ネットワーク１０２を経由して、監視対象側（映像ソース１０１）からＷｅｂＲＴＣ方式によりリアルタイムで送信される映像を、Ｗｅｂブラウザで受信し、ディスプレイの画面上で再生することができる。
【００３１】
管理側（宛先端末１０４）では、ＷｅｂＲＴＣ方式の通信接続が確保されると、管理者は、クライアント端末２５１のブラウザ上において、店舗内のビデオカメラ２０２により撮影されたライブ映像（音声も含む）を含む映像データを受信し、ディスプレイの画面上で確認できる。音声は、クライアント端末２５１のスピーカから出力できる。また、管理者は、クライアント端末２５１のブラウザ上において、ビデオレコーダ２０３に記録された映像データ（すなわち、過去に記録された映像データ）を受信し、ディスプレイの画面上で確認することもできる。通常は、クライアント端末２５１が過去に記録された映像データ（ライブ映像より高解像映像である）をダウンロードして、ダウンロード完了後にクライアント端末２５１のディスプレイ上に再生して確認することができる。また、クライアント端末２５１が過去に記録された映像データを、通常のライブ映像時の通信帯域よりも広い通信帯域によって映像データを受信しつつクライアント端末２５１の画面上で再生（ストリーム再生）して確認してもよい。ストリーム再生の場合には受信すると同時に確認することができる。一方、ダウンロードした映像データを再生する場合には、任意の撮影フレームに移動することが可能である。
【００３２】
管理側（宛先端末１０４）のクライアント端末２５１の動作について簡単に説明する。クライアント端末２５１は、電源がオン状態でブラウザ等の機能が起動している場合には、ＷｅｂＲＴＣサーバ１０３の自動接続処理により、ＷｅｂＲＴＣ方式の通信接続が確保される。すなわち、クライアント端末２５１は、監視対象側（映像ソース１０１）に対してＷｅｂＲＴＣ方式のリアルタイムな映像通信が可能となる。
【００３３】
クライアント端末２５１は、中継装置２０１及びネットワーク１０２を経由して、監視対象側（映像ソース１０１）のビデオレコーダ２０３からリアルタイムに送信される映像データを受信して再生できる。なお、音声はクライアント端末２５１に内蔵されたスピーカにより出力される。具体的には、クライアント端末２５１は、ブラウザ上において、店舗内のビデオカメラ２０２により撮影されたライブ映像を含む映像データを受信し、ディスプレイの画面上に映像を再生できる。また、クライアント端末２５１は、ブラウザ上において、ビデオレコーダ２０３に記録された映像（録音された音声も含む）を受信し、ディスプレイの画面上に映像を再生することができる。
【００３４】
［映像通信サーバのハードウェアの構成］  
次に、図３を用いて、本実施形態に係るＷｅｂＲＴＣサーバ１０３のハードウェアの構成の一例について説明する。  
図３に示される通り、本実施形態に係るＷｅｂＲＴＣサーバ１０３は、通信インタフェース３０１、記憶部３０２、入力装置３０３、出力装置３０４、制御部３０５、計時装置３０６、電源部３０７、及び外部インタフェース３０８、が電気的に接続されたコンピュータを含む。なお、図３では、通信インタフェース及び外部インタフェースをそれぞれ、「通信Ｉ／Ｆ」及び「外部Ｉ／Ｆ」と記載している。
【００３５】
制御部３０５は、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等を含み、情報処理に応じて各構成要素の制御を行う。記憶部３０２は、例えば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置であり、制御部３０５で実行される、ＷｅｂＲＴＣサーバ１０３での通信帯域を確保するための通信帯域確保実行プログラム、映像ソース１０１のビデオレコーダ２０３から取得する高解像映像データを宛先端末１０４へ送信する処理が完了する時刻を算出するための送信完了時刻算出プログラム、及び／またはＷｅｂＲＴＣサーバ１０３が取得した制御データ、映像及び音声データ等を記憶してもよい。
【００３６】
通信帯域確保のための通信帯域確保実行プログラムは、（例えば、高解像映像データを通信する目的で）特定のデータを送信する通信帯域を確保するために、他の映像データを送信している通信帯域を縮小するための処理（図６）、または他のＷｅｂＲＴＣサーバ１０３から通信帯域を融通してもらうための処理（図９）を実行させるためのプログラムである。また、送信完了時刻算出プログラムは、映像ソース１０１のビデオレコーダ２０３に格納されている高解像映像データを宛先端末１０４に送信して高解像映像データの送信が完了する時刻を算出するための処理（図７）を実行させるためのプログラムである。
【００３７】
通信インタフェース３０１は、例えば、近距離無線通信（例えば、ブルートゥース（登録商標））モジュール、有線ＬＡＮ（Local Area Network）モジュール、無線ＬＡＮモジュール等であり、ネットワーク１０２を介した有線または無線通信を行うためのインタフェースである。通信インタフェース３０１は、ＷｅｂＲＴＣサーバ１０３を、映像ソース１０１（例えば、中継装置２０１、ビデオカメラ２０２、ビデオレコーダ２０３、及びアラーム装置２０４）と、宛先端末１０４（例えば、クライアント端末２５１、及び／またはモバイル端末２５２）とに接続するためのインタフェースである。通信インタフェース３０１は、制御部３０５によって制御される。通信インタフェース３０１は、ネットワークを介して受信した外部装置（例えば、映像ソース１０１）からの情報を制御部３０５へ受け渡す。このネットワーク１０２を介した通信は、無線または有線のいずれでもよい。なお、通信インタフェース３０１は、ネットワークを介して、情報を外部装置へ送信することができてもよい。ネットワークは、インターネットを含むインターネットワークでもよいし、ＷＡＮ（Wide Area Network）のような他の種類のネットワークであってもよい。
【００３８】
記憶部３０２は、コンピュータその他の装置、及び機械等が、記録されたプログラム等の情報を読み取り可能なように、当該プログラム等の情報を、電気的、磁気的、光学的、機械的または化学的作用によって蓄積する媒体である。ＷｅｂＲＴＣサーバ１０３は、この記憶部３０２から、通信帯域確保のための通信帯域確保実行プログラム、送信完了時刻算出プログラム、及びＷｅｂＲＴＣサーバ１０３が取得した制御データ等を取得してもよい。
また、記憶部３０２は、宛先端末１０４ごとに、通信帯域を優先的に使用する権限を示す優先度を記憶しておく。例えば、優先度が高いほど広い通信帯域を使用可能である。この優先度は、例えば、宛先端末１０４の管理者との契約によって予め設定される。もちろん、管理者とこの通信サービスの事業者との間で契約をリアルタイムで変更して優先度を上げ下げすることも可能である。また、優先度は、ＷｅｂＲＴＣサーバ１０３ごとに設定されていてもよく、記憶部３０２はこの優先度を記憶しておいてもよい。さらに、この２種類の優先度を適応的に選択して使用するように、例えば記憶部３０２で設定されていてもよい。
【００３９】
他に、記憶部３０２は、ＷｅｂＲＴＣサーバ１０３がリアルタイム映像を監視して異常であると判定する判定基準を記憶する。この判定基準は、宛先端末１０４ごとに設定することが可能であり、宛先端末１０４の管理者がネットワーク１０２を経由して記憶部３０２にアップロードしてもよい。
【００４０】
入力装置３０３は、外部から入力を受け付ける装置であり、例えば、タッチパネル、物理ボタン、マウス、キーボード等である。出力装置３０４は、外部へ出力を行う装置であり、音声（識別できれば単なる音でもよい）、表示等で情報を出力し、例えば、ディスプレイ、スピーカ等である。外部インタフェース３０８は、外部と本体との媒介をするためのものであり、例えば、ＵＳＢポート等であり、外部装置と接続するためのインタフェースである。
【００４１】
計時装置３０６は、時間を計測する装置であり、日時を計測できる。例えば、計時装置３０６はカレンダーを含む時計であり、現在の日時の情報を制御部３０５へ渡す。
【００４２】
電源部３０７は、電力を供給可能なものであれば何でもよく、例えば、充電可能な２次電池または通常のコンセントから取得可能な交流電源からのエネルギー供給を受けるものである。電源部３０７は、ＷｅｂＲＴＣサーバ１０３本体に搭載されている各要素へ電力を供給する。電源部３０７は、例えば、通信インタフェース３０１、記憶部３０２、入力装置３０３、出力装置３０４、制御部３０５、計時装置３０６、及び外部インタフェース３０８へ電力を供給する。
【００４３】
なお、ＷｅｂＲＴＣサーバ１０３の具体的なハードウェア構成に関して、実施形態に応じて、適宜、構成要素の省略、置換及び追加が可能である。例えば、制御部３０５は、複数のプロセッサを含んでもよい。ＷｅｂＲＴＣサーバ１０３は、複数台の情報処理装置で構成されてもよい。
［ＷｅｂＲＴＣサーバ１０３のソフトウェアの構成］  
次に、図４を用いて、本実施形態に係るＷｅｂＲＴＣサーバ１０３のソフトウェア構成の一例を説明する。  
ＷｅｂＲＴＣサーバ１０３の制御部３０５は、必要なプログラムを実行する際に、記憶部３０２に記憶された、通信帯域確保実行プログラム、及び／または送信完了時刻算出プログラムをＲＡＭに展開する。そして、制御部３０５は、ＲＡＭに展開された、通信帯域確保実行プログラム、及び／または送信完了時刻算出プログラムをＣＰＵにより解釈及び実行して、各構成要素を制御する。これによって、図４に示される通り、本実施形態に係るＷｅｂＲＴＣサーバ１０３は、映像取得部４０１、送信部４０２、映像監視部４０３、属性取得部４０４、帯域算出部４０５、完了時刻算出部４０６、判定部４０７、及び帯域制御部４０８を備える。
【００４４】
映像取得部４０１は、通信インタフェース３０１を介して、ネットワーク１０２を介して映像ソースと宛先端末との間を常時接続し、映像ソースから宛先端末への映像データを送信可能にしつつ、映像データを参照または取得する。映像取得部４０１は、ネットワーク１０２を経由して通信する複数の映像ソース１０１から送信されるそれぞれの映像データを取得する。この映像データは、ＷｅｂＲＴＣ方式で通信され、リアルタイム映像データ、または、映像ソース１０１が過去に取得した（リアルタイム映像ではない）高解像映像データである。また、映像取得部４０１は、受け取った映像データを送信部４０２へ渡し、宛先端末１０４へ映像データを送信させる。
【００４５】
映像取得部４０１は、映像データよりも先にこの映像データに関する情報を含んだデータを受け取る。なお、このデータは、映像データのヘッダに含めてあってもよい。この映像データに関する情報は、例えば、受け取る映像データが低解像の映像データ（例えば、リアルタイム映像データ）であるのか、高解像度の映像データであるのかの識別情報を含んでいる。例えば、映像データがリアルタイム映像データである場合には、映像監視部４０３が高解像映像データの通信開始を指示し、帯域制御部４０８が通信帯域を制御した後に、映像ソース１０１へリクエスト信号を送信するまで（もしくはリクエスト信号を送信して高解像映像データを受信するまで）、リアルタイム映像データを映像ソース１０１から受信し、宛先端末１０４へ送信し続ける。
【００４６】
また、映像取得部４０１は、宛先端末１０４からのリクエスト信号を受信して、そのリクエスト内容を記憶部３０２が記憶してもよい。このリクエストは、例えば、宛先端末１０４の管理者が、特定の映像ソース１０１が撮影した特定の日時及び／または場所の高解像映像データを要求することであり、宛先端末１０４からこのリクエストを含むリクエスト信号を映像取得部４０１が受け取ってもよい。このリクエスト信号は、例えば、映像ソース１０１のうちの特定のビデオカメラ２０２が取得した特定の日時に撮影された高解像映像データを要求すること等でもよい。また、このリクエスト信号は、リクエスト内容が実行されるべき時刻前であればいつ送信されてもよい。
【００４７】
さらに、映像取得部４０１は、映像ソース１０１からのリクエスト信号を受信して、その内容を判定部４０７へ渡すことも行う。映像取得部４０１は、受信したリクエスト信号を記憶部３０２に記憶させ、記憶させた旨を判定部４０７へ知らせ、その後、判定部４０７は記憶部３０２からリクエスト信号の内容を取得してもよい。
【００４８】
送信部４０２は、通信インタフェース３０１を介して、ネットワーク１０２経由で映像ソース１０１から映像取得部４０１を通過した映像データを宛先端末１０４へ送信する。例えば、リアルタイム映像データである場合には、映像データは高解像映像データではなく低解像映像データであるので、映像取得部４０１を通過した映像データをそのまま送信部４０２が受け取り、通信インタフェース３０１を介してネットワーク１０２を経由して宛先端末１０４へ送信する。映像データが高解像映像データである場合には、帯域制御部４０８が宛先端末１０４と宛先端末１０４との間の通信帯域を適切に拡張した後で、拡張された通信帯域を使用して映像ソース１０１から映像取得部４０１が取得した高解像映像データを送信部４０２が宛先端末１０４へ送信する。また、送信部４０２は、映像監視部４０３及び判定部４０７からのリクエスト信号（「要求信号」とも称す）、依頼データ等を映像ソース１０１、他のＷｅｂＲＴＣサーバ１０３に送信する。
【００４９】
映像監視部４０３は、映像取得部４０１が取得した低解像の映像データ（例えば、リアルタイム映像データ）を受け取り、この映像データの内容を監視し、高解像映像データを映像ソース１０１へリクエストする必要があるかどうかを判定し、リクエストする必要がある場合にはリクエスト信号を映像ソース１０１へ向けて送信するように送信部４０２へ指示する。
映像監視部４０３は、例えば、予め設定されている判定基準を参照して、取得した映像データが判定基準を満たしているかどうかを判定し、判定基準を満たしている場合にはリクエスト信号を送信するように送信部４０２に指示する。判定基準は、例えば、特定の場所に特定の撮影角度で設置されたビデオカメラ２０２により撮影される映像に人が含まれる画像があることである。この場合、映像監視部４０３がこの判定基準を満たす映像データを発見した場合には、高解像映像データを宛先端末１０４へリクエストするリクエスト信号を送信するように送信部４０２に指示する。
なお、この判定基準は、管理者及び／または映像ソース１０１でのビデオカメラ２０２の配置等にも依存する。また、判定基準に音声の大きさを含めてもよい。例えば、ビデオカメラ２０２が音声も同時に録音していて、この音声の出力値（単位は例えば、ｄＢ）がしきい値以上に大きい場合に判定基準を満たす、としてもよい。
【００５０】
属性取得部４０４は、通信インタフェース３０１を介して映像ソース１０１から受け取る映像データの属性情報を取得して帯域算出部４０５へ渡す。映像データの属性情報は、映像データの属性を示す情報であれば何でもよく、例えば、映像データのデータ量、映像データの宛先端末、映像撮影日時、映像撮影期間、及びリアルタイム映像であるか過去の映像であるかを示す映像識別情報がある。なお、映像識別情報は、映像データのヘッダに含まれている場合には不要である。本実施形態では、この映像データの属性情報は高解像映像データの通信が開始されるよりも前に属性取得部４０４が受け取り、この属性情報に基づいて制御部３０５が高解像映像データの通信帯域を確保するための制御を開始する。
【００５１】
帯域算出部４０５は、属性取得部４０４が取得した属性情報から、属性情報に対応する高解像映像データのデータ量に基づいて、この高解像映像データが必要とする通信帯域を算出する。通信帯域は、通常は、属性情報に含まれるデータ量と、再生期間（映像撮影期間に対応）とによって決まる。もし、後に判定部４０７で通信帯域を確保できないと判定した場合には、再生期間に相当する高解像映像データの送信期間を増やして通信帯域が狭くても送信を完了することができるように送信期間を調整してもよい。この場合は通信帯域が必要な通信帯域より狭いので、高解像映像データをストリーム再生する場合には送信期間を変えずに、高解像映像データの画質はオリジナルの画質より下がることになり、一方、高解像映像データをダウンロードする場合には、画質は変わらないがダウンロードを完了する時間が長くなる。また、通信帯域が必要な通信帯域より狭い状態でストリーム再生をする場合には、送信期間を長くしてオリジナル画質を保つこともできるが、この場合は再生速度が通常より低速になる。
【００５２】
なお、高解像映像データをダウンロードする場合には、データ量によってダウンロードする期間はほぼ決定されるので、帯域算出部４０５はデータ量だけで通信帯域を決定してもよい。通信帯域が広いほどダウンロードする期間は短くなるが、特定の期間（例えば、５秒）で終了する程度を目安に通信帯域を確保するように帯域算出部４０５は通信帯域を算出してもよい。また、完了時刻算出部４０６で算出する時刻（ダウンロード期間でもよい）が所望の期間内になるまで、完了時刻算出部４０６の結果を帯域算出部４０５へフィードバックして帯域算出部４０５で再計算してもよい。
【００５３】
完了時刻算出部４０６は、帯域算出部４０５が算出した通信帯域と、属性取得部４０４が取得した高解像映像データのデータ量とに基づいて、リクエストした高解像映像データを全て宛先端末１０４に送信するまでにかかる期間を算出し、計時装置３０６から時刻を参照して、この期間と時刻に基づいてリクエストした高解像映像データを全て宛先端末１０４へ送信完了する時刻を算出する。その後、完了時刻算出部４０６は、算出した時刻を、送信部４０２を介して宛先端末１０４に送信する。宛先端末１０４では、ポップアップ等で高解像映像データがいつ送信完了するかを管理者は知ることができる。送信完了時刻を管理者に告知する方法は様々であり、画面に時刻を表示するだけでなく、スピーカを使用して音声で時刻を知らせてもよい。
【００５４】
また、完了時刻算出部４０６は、属性情報が映像撮影期間を含み、通信帯域とデータ量とからこの映像撮影期間内に高解像映像データの送信完了を実現できると判定した場合には、映像撮影期間内に高解像映像データが送信完了になるように通信帯域を調整してもよい。この場合には映像撮影時と同様な映像速度（ビデオレコーダ２０３での高解像映像データの再生速度と同一）で宛先端末１０４の管理者は閲覧することになる。なお、宛先端末１０４が高解像映像データをダウンロードする場合には、通信帯域が広いほど短時間で完了時刻が早くなるので、映像撮影期間は重要ではなく属性情報に含まれていなくてもよい。
【００５５】
判定部４０７は、ＷｅｂＲＴＣサーバ１０３で確保している通信帯域を調整することによって、帯域算出部４０５が算出した通信帯域を確保することができるかどうかを判定する。判定部４０７は、通信帯域を提供する宛先端末１０４の優先度と、現在の通信帯域の占有状態と、高解像映像データが必要とする通信帯域と、完了時刻算出部４０６が算出した送信完了時刻と、に基づいて、通信帯域を確保することができるかどうかを判定する。なお、判定部４０７は、今後予定されている通信帯域の使用状態も考慮して、通信帯域を確保することができるかどうかを判定してもよい。
【００５６】
判定部４０７が、自サーバではこの通信帯域を確保することができないと判定した場合には、例えば、ストリーム再生をする場合にはデータ量を減少させて送信可能かどうかを判定してもよい。この場合、判定部４０７は、例えば、必要とする高解像映像データの映像撮影期間を少なくしたものでもよいかどうかを判定し、この場合に拡張された通信帯域の占有時間を保ちつつ通信帯域を縮小させて、通信帯域が確保できるかを判定する手順を繰り返す。また、高解像映像データをダウンロードする場合には、通信帯域を確保することができないと判定されたとき、ダウンロード時間（「ダウンロード期間」とも称す）が長くなるがそれでもよいかどうかを予め決めた判定基準を参照して判定する。もしくは、ダウンロード時間を宛先端末１０４に示し、管理者がダウンロード時間の可否を判断してもよい。
【００５７】
また、判定部４０７は、自サーバでは通信帯域を確保することができないと判定した場合には、他のＷｅｂＲＴＣサーバ１０３から通信帯域を融通してもらえないかを依頼する依頼データを、送信部４０２を介して送信する。依頼データは、例えば、必要な通信帯域とその通信帯域を使用したい時間帯（開始及び終了時刻）との情報を含む。
【００５８】
さらに、判定部４０７は、宛先端末１０４から送信された、高解像映像データの閲覧を要求するリクエスト信号を受信して、この閲覧要求に応えることができるかどうかを判定してもよい。また、判定部４０７は、映像ソース１０１から送信された、高解像映像データを宛先端末１０４へ閲覧させることを要求する（例えば、アラーム装置２０４がアラームを発した場合）リクエスト信号を受信して、閲覧要求に応えるかどうかを判定してもよい（アラームの場合には通常閲覧させる）。
【００５９】
帯域制御部４０８は、判定部４０７が通信帯域を確保することができると判定した場合には、ＷｅｂＲＴＣサーバ１０３が扱うことができる通信帯域を、優先度を考慮して宛先端末１０４間で調整するように制御する。また、帯域制御部４０８は、通信帯域を確保することができると判定した場合には、高解像映像データを送信開始するように映像ソース１０１へ要求する要求信号を送信部４０２へ指示する。
【００６０】
＜その他＞  
ＷｅｂＲＴＣサーバ１０３の動作に関しては後述する動作例で詳細に説明する。なお、本実施形態では、ＷｅｂＲＴＣサーバ１０３の制御部３０５はいずれも汎用のＣＰＵによって実現されてもよい。しかしながら、以上の機能の一部または全部が、１または複数の専用のプロセッサにより実現されてもよい。また、ＷｅｂＲＴＣサーバ１０３の構成に関して、実施形態に応じて、適宜、省略、置換及び追加が行われてもよい。
【００６１】
［動作例］  
次に、図５、図６、図７、図８、及び図９を用いて、ＷｅｂＲＴＣサーバ１０３の動作例を中心に説明する。
【００６２】
図５は、２つの映像ソース１０１と、１つのＷｅｂＲＴＣサーバ１０３と、２つの宛先端末１０４との間の一連の動作の一例を示すシーケンス図である。なお、以下に記載のシーケンス図で説明する処理手順は一例に過ぎず、各処理は可能な限り変更されてよい。また、以下で説明する処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。
【００６３】
（ステップＳ５０１、Ｓ５０２）  
ステップＳ５０１では映像ソース１ １０１が対応する宛先端末１ １０４へＷｅｂＲＴＣサーバ１０３を経由してリアルタイム映像データを送信し、ステップＳ５０２では映像ソース２ １０１が対応する宛先端末２ １０４へＷｅｂＲＴＣサーバ１０３を経由してリアルタイム映像データを送信している。
【００６４】
（ステップＳ５０３）  
ステップＳ５０３では、ＷｅｂＲＴＣサーバ１０３が映像ソース１ １０１及び映像ソース２ １０１のリアルタイム映像データに含まれる映像を監視する。ＷｅｂＲＴＣサーバ１０３は、予め設定されている判定基準に基づいて、映像が判定基準を満たすかどうかを監視する。この例では、ステップＳ５０３で映像が判定基準を満たしたと判定される。
【００６５】
（ステップＳ５０４、Ｓ５０５）  
ステップＳ５０４では、ＷｅｂＲＴＣサーバ１０３が高解像映像データを送信するように映像ソース１ １０１へ要求することを決定する。
【００６６】
そして、ステップＳ５０５では、ＷｅｂＲＴＣサーバ１０３が映像ソース１ １０１へ、高解像映像データを送信する旨の要求信号を送信する。
【００６７】
（ステップＳ５０６、Ｓ５０７）  
ステップＳ５０６、ステップＳ５０７では、映像ソース１ １０１が要求信号をＷｅｂＲＴＣサーバ１０３から受信したことを受けて、映像ソース１ １０１が記憶している高解像映像データの属性を含む属性情報をＷｅｂＲＴＣサーバ１０３へ送信する。
【００６８】
（ステップＳ５０８）  
ステップＳ５０８では、ＷｅｂＲＴＣサーバ１０３がステップＳ５０７で受け取った属性情報に基づいて、ＷｅｂＲＴＣサーバ１０３が扱っている通信帯域を制御して、ステップＳ５０４で要求した高解像映像データの通信帯域を確保する。この結果、映像ソース１ １０１と宛先端末１ １０４との間の通信帯域は拡大され、映像ソース２ １０１と宛先端末２ １０４との間の通信帯域はこの拡大された分だけ縮小される。
【００６９】
（ステップＳ５０９、Ｓ５１０）  
ステップＳ５０９では、通信帯域を確保したので、高解像映像データの送信を開始するように映像ソース１ １０１へ指示することを決定する。
【００７０】
そして、ステップＳ５１０では、ＷｅｂＲＴＣサーバ１０３が高解像映像データの送信を開始するように映像ソース１ １０１へ指示する指示信号を映像ソース１ １０１へ送信する。
【００７１】
（ステップＳ５１１、Ｓ５１２）  
ステップＳ５１１では、ＷｅｂＲＴＣサーバ１０３からの要求信号を受けて、映像ソース１ １０１は、ＷｅｂＲＴＣサーバ１０３を経由して宛先端末１ １０４との間で、ステップＳ５０８で確保された通信帯域を使用して高解像映像データを宛先端末１ １０４へ送信する。
【００７２】
また、ステップＳ５１２では、ステップＳ５０８で確保された通信帯域を使用して低解像映像データ（例えば、リアルタイム映像データ）を映像ソース２ １０１が宛先端末２ １０４へ送信する。なお、ステップＳ５１１では、宛先端末１ １０４が高解像映像データをダウンロードする場合と、ストリーム再生する場合とがある。ダウンロードするかまたはストリーム再生するかの取り決めは、予め契約時に決定されて記憶部３０２が記憶していてもよいし、高解像映像データが送信されるときに宛先端末１０４へどちらを選択するかの選択データを送信し管理者が選択してもよい。
【００７３】
図６は、ＷｅｂＲＴＣサーバ１０３が通信帯域を確保するための処理手順の一例を例示するフローチャートである。なお、以下に記載のフローチャートで説明する処理手順は一例に過ぎず、各処理は可能な限り変更されてもよい。また、以下で説明する処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。
【００７４】
（起動）  
まず、ＷｅｂＲＴＣサーバ１０３は管理者等に入力装置２１２を介して起動され、さらに初期の設定等の入力を受け付ける。ＷｅｂＲＴＣサーバ１０３の制御部３０５は、以下の処理手順にしたがって、処理を進める。
【００７５】
（ステップＳ６０１）  
ステップＳ６０１では、制御部３０５は、映像取得部４０１、送信部４０２として動作し、映像取得部４０１が映像ソースと宛先端末との間を常時接続し、映像ソース１０１からリアルタイム映像データを送信可能にし、送信部４０２がリアルタイム映像データを宛先端末１０４へ送信する。
【００７６】
（ステップＳ６０２）  
ステップＳ６０２では、制御部３０５は、映像監視部４０３及び／または判定部４０７として動作し、高解像映像データを宛先端末１０４へ送信する要求があるかどうかを判定する。制御部３０５は、送信する要求があると判定された場合には処理はステップＳ６０３へ進み、送信する要求があると判定されなかった場合にはステップＳ６０１へ戻るように動作を制御する。送信する要求があると映像監視部４０３が判定する場合は、例えば、映像取得部４０１が取得した映像データを分析することによって、より精細な映像データを閲覧する必要が生じる場合がある。また、より精細な映像データを送信する要求があると判定部４０７が判定する場合は、例えば、宛先端末１０４からの高解像映像データの送信依頼を判定部４０７が通信インタフェース３０１を介して受信した場合、映像ソース１０１から高解像映像データの送信依頼が発生する場合（例えば、アラーム装置２０４がアラームを発する場合）がある。
【００７７】
（ステップＳ６０３）  
ステップＳ６０３では、制御部３０５は、属性取得部４０４、帯域算出部４０５、完了時刻算出部４０６として動作し、映像ソース１０１から送信予定の高解像映像データの属性情報を属性取得部４０４が取得し、この高解像映像データが必要とする通信帯域を属性情報から帯域算出部４０５が算出する。また、この通信帯域を使用してこの高解像映像データの送信を完了する完了時刻を完了時刻算出部４０６が算出する。
【００７８】
（ステップＳ６０４）  
ステップＳ６０４では、制御部３０５は、判定部４０７として動作し、判定部４０７が算出された通信帯域を、必要とされる時間帯に確保することが可能であるかどうかを判定する。判定部４０７が通信帯域を確保することが可能であると判定した場合にはステップＳ６０５へ進み、可能であると判定しなかった場合にはステップＳ６０７へ進む。
【００７９】
（ステップＳ６０５）  
ステップＳ６０５では、制御部３０５は、帯域制御部４０８として動作し、高解像映像データを送信する宛先端末１０４が使用する通信帯域を確保し、その他の宛先端末１０４が使用する通信帯域を縮小する。
【００８０】
（ステップＳ６０６）  
ステップＳ６０６では、制御部３０５は、送信部４０２として動作し、確保した通信帯域を使用して映像ソース１０１から取得した高解像映像データを宛先端末１０４へ送信部４０２が送信する。
【００８１】
（ステップＳ６０７）  
ステップＳ６０７では、制御部３０５は、判定部４０７として動作し、高解像映像データのデータ量を減少させて送信することが可能かどうかを判定する。データ量を減少させるためには、例えば、高解像映像データの再生時間を短くすることがある。もし、解像度を落とした映像データがあれば、その映像データを送信してもよいかを判定してもよい。データ量を減少させる映像データ、解像度を落とした映像データを送信してもよいかどうかは、例えば、ＷｅｂＲＴＣサーバ１０３の事業者と宛先端末１０４の管理者との契約による設定に依存し、この設定は記憶部３０２に記憶されている。また、この他に、宛先端末１０４が高解像映像データをダウンロードする場合には、例えば、完了時刻算出部４０６が計算したダウンロード時間がしきい値よりも小さい場合には送信可能とする、としてもよい。
【００８２】
（ステップＳ６０８）  
ステップＳ６０８では、制御部３０５は、判定部４０７、送信部４０２として動作し、判定部４０７がデータ量を落として送信することは不可能であると判定した場合には、現在通信不可である旨を送信部４０２が高解像映像データを送信する予定の宛先端末１０４へ通知する。また、ダウンロード時間がしきい値よりも大きくなり送信不可能と判定される場合もある。
【００８３】
（ステップＳ６０９）  
ステップＳ６０９では、制御部３０５は、判定部４０７として動作し、計時装置３０６を使用して経過する時間を計測し、予め設定された時間が経過したら、ステップＳ６０４へ戻る。
【００８４】
図７は、ＷｅｂＲＴＣサーバ１０３が、映像送信が完了する時刻を算出するための処理手順の一例を例示するフローチャートである。
【００８５】
（起動）起動は図６の場合と同様である。
【００８６】
（ステップＳ７０１）  
ステップＳ７０１では、制御部３０５は、完了時刻算出部４０６として動作し、属性取得部４０４は、映像ソース１０１から送信される高解像映像データの属性情報と、ステップＳ６０３で算出された通信帯域とに基づいて、高解像映像データの通信が完了する期間を算出する。
【００８７】
（ステップＳ７０２）  
ステップＳ７０２では、制御部３０５は、判定部４０７として動作し、送信開始時刻を設定する。属性取得部４０４が取得した属性情報から送信開始時刻を取得して判定部４０７が設定する。また、宛先端末１０４の管理者等から送信開始時刻情報を含んだ指示信号が送信されて、判定部４０７が通信インタフェース３０１を介して送信開始時刻情報を受信して設定してもよい。
【００８８】
（ステップＳ７０３）  
ステップＳ７０３では、制御部３０５は、完了時刻算出部４０６として動作し、完了時刻算出部４０６は、ステップＳ７０１で算出された通信完了期間と、ステップＳ７０２で算出された送信開始時刻とから、送信完了時刻を算出する。
【００８９】
（ステップＳ７０４）  
ステップＳ７０４では、制御部３０５は、送信部４０２として動作し、送信部４０２は、完了時刻算出部４０６から送信完了時刻を受け取り、この送信完了時刻を含んだ送信完了時刻データを、高解像映像データの宛先端末１０４に送信する。この宛先端末１０４はこの送信完了時刻データを受け取り、画面に送信完了時刻情報を表示させる。送信完了時刻は例えば、ポップアップ等で表示され、この時刻が表示される表示枠は画面内で容易に移動できるような仕様であることが望ましい。
【００９０】
図８は、２つの映像ソース１０１と、２つのＷｅｂＲＴＣサーバ１０３と、２つの宛先端末１０４との間の一連の動作の一例を示すシーケンス図である。この例は、ＷｅｂＲＴＣサーバ１ １０３単独では高解像映像データを通信するための通信帯域を確保することができない場合である。
【００９１】
（ステップＳ８０１）  
ステップＳ８０１では、ＷｅｂＲＴＣサーバ１ １０３が、高解像映像データの属性情報と、自サーバの通信帯域使用状況とに基づいて、要求されている高解像映像データの通信帯域を確保することができるかどうかを判定し、確保することが可能であると判定した場合にはステップＳ５０８へ進み、自サーバでは通信帯域の確保が不可能であると判定した場合にはステップＳ８０２へ進む。
【００９２】
（ステップＳ８０２、Ｓ８０３、Ｓ８０４）  
ステップＳ８０２では、ＷｅｂＲＴＣサーバ１ １０３が、自サーバでは通信帯域を確保することができないと判定した場合には、通信帯域を融通してもらえないかを他のＷｅｂＲＴＣサーバ１０３へ依頼する。
【００９３】
そして、ステップＳ８０３では、ＷｅｂＲＴＣサーバ１ １０３が依頼データを生成し、他のＷｅｂＲＴＣサーバ１０３宛てへ送信部４０２を介して依頼データを送信または配信する。この送信または配信は、例えば、マルチキャストまたはブロードキャストで依頼データが送られる。依頼データは、例えば、高解像映像データに必要な通信帯域とその通信帯域を使用したい時間帯（開始及び終了時刻）との情報を含む。
【００９４】
ステップＳ８０４では、依頼データに含まれる情報に対応する通信帯域を融通することが可能であると判定したＷｅｂＲＴＣサーバ１０３から、融通可能である旨の回答信号がＷｅｂＲＴＣサーバ１ １０３へ送信される。
【００９５】
（ステップＳ８０５、Ｓ８０６）  
ステップＳ８０５では、ＷｅｂＲＴＣサーバ１ １０３がステップＳ８０３で依頼した依頼データの内容に基づいて、通信帯域を制御してＷｅｂＲＴＣサーバ２ １０３に融通してもらった通信帯域を確保する。
【００９６】
このステップＳ８０５と同時にステップＳ８０６では、ＷｅｂＲＴＣサーバ２ １０３がステップＳ８０３で依頼した依頼データの内容に基づいて、通信帯域を制御してＷｅｂＲＴＣサーバ１ １０３に通信帯域を融通する。この結果、映像ソース１ １０１と宛先端末１ １０４との間のＷｅｂＲＴＣサーバ１ １０３を経由する通信帯域は拡大され、映像ソース２ １０１と宛先端末２ １０４との間のＷｅｂＲＴＣサーバ２ １０３を経由する通信帯域はこの拡大された分だけ縮小されることになる。
【００９７】
（ステップＳ８０７）  
ステップＳ８０７では、ＷｅｂＲＴＣサーバ１ １０３は通信帯域を確保しているので、高解像映像データの送信を開始するように映像ソース１ １０１へ指示することを決定する。そして、次のステップＳ５１０では、高解像映像データの送信を開始するように映像ソース１ １０１へ指示する指示信号をＷｅｂＲＴＣサーバ１ １０３が映像ソース１ １０１へ送信する。
【００９８】
上述した手順は、例えば、以下の様に一般化されてもよい。ＷｅｂＲＴＣサーバ１ １０３では、判定部４０７が、第１映像データの送信用に第１通信帯域に通信帯域を拡大する場合に、第１映像通信サーバで前記第１通信帯域を確保することができるかどうかを判定する。判定部４０７が前記第１通信帯域を確保することができないと判定した場合には、第２映像通信サーバが前記第１通信帯域を融通することが可能であるかどうかの回答を、送信部４０２がＷｅｂＲＴＣサーバ２ １０３へ依頼する依頼データを送信する。そして、ＷｅｂＲＴＣサーバ２ １０３では、依頼データを受信し、判定部４０７が、第１通信帯域を融通することが可能であるかどうかを判定する。判定部４０７が第１通信帯域を融通することが可能であると判定した場合に、第１通信帯域を融通することが可能である回答信号をＷｅｂＲＴＣサーバ１ １０３へ送信し、帯域制御部４０８が第１通信帯域を開放する。その後、ＷｅｂＲＴＣサーバ１ １０３では、回答信号を受信し、帯域制御部４０８が第１通信帯域を確保する。
【００９９】
また、図８の一例とは別に、ＷｅｂＲＴＣサーバ１０３ごとに優先度が割り当てられて、第１宛先端末への映像データの通信帯域を拡大する場合に、この通信帯域を提供しているＷｅｂＲＴＣサーバ１ １０３の優先度より低い優先度のＷｅｂＲＴＣサーバ２ １０３が使用している通信帯域を縮小するように指示し、縮小した分の通信帯域をＷｅｂＲＴＣサーバ１ １０３を経由する第１宛先端末に割り当ててもよい。さらに、優先度の低いＷｅｂＲＴＣサーバ２ １０３へは、通信帯域を縮小するように指示信号をＷｅｂＲＴＣサーバ１ １０３が送信し、ＷｅｂＲＴＣサーバ２ １０３が通信帯域を縮小可能であるとの回答信号をＷｅｂＲＴＣサーバ１ １０３が受信した場合に、縮小した分の通信帯域をＷｅｂＲＴＣサーバ１ １０３を経由する第１宛先端末に割り当てるという処理でもよい。
【０１００】
例えば、ＷｅｂＲＴＣサーバ１ １０３では、判定部４０７が、第１映像データの送信用に第１通信帯域に通信帯域を拡大する場合に、第１映像通信サーバで第１通信帯域を確保することができるかどうかを判定する。送信部４０２が、この判定部４０７が第１通信帯域を確保することができないと判定した場合には、第１通信帯域を融通することとＷｅｂＲＴＣサーバ１ １０３の優先度とを含む依頼データを、ＷｅｂＲＴＣサーバ２ １０３へ送信する。そして、ＷｅｂＲＴＣサーバ２ １０３では、判定部４０７が、通信インタフェース３０１を経由して依頼データを受信し、ＷｅｂＲＴＣサーバ１ １０３の優先度がＷｅｂＲＴＣサーバ２ １０３の優先度より高いかどうかを判定する。帯域制御部４０８が、ＷｅｂＲＴＣサーバ１ １０３の優先度がＷｅｂＲＴＣサーバ２ １０３の優先度より高いと判定した場合に、第１通信帯域を融通することが可能である回答信号をＷｅｂＲＴＣサーバ１ １０３へ送信し、第１通信帯域を開放する。その後、ＷｅｂＲＴＣサーバ１ １０３では、帯域制御部４０８が、通信インタフェース３０１を経由して回答信号を受信し、第１通信帯域を確保することができる。
【０１０１】
図９は、ＷｅｂＲＴＣサーバ１ １０３が、ＷｅｂＲＴＣサーバ１ １０３単独では高解像映像データを通信するための通信帯域を確保することができず、他のＷｅｂＲＴＣサーバ１０３へ通信帯域の融通を依頼する場合のフローチャートである。
【０１０２】
（起動）起動は図６の場合と同様である。
【０１０３】
（ステップＳ９０１）  
ステップＳ９０１では、制御部３０５は、判定部４０７として動作し、ＷｅｂＲＴＣサーバ１ １０３が、自サーバでは通信帯域を確保することができないと判定した場合には、通信帯域を融通してもらえないかを他のＷｅｂＲＴＣサーバ１０３へ依頼する。そして、ステップＳ９０１では、ＷｅｂＲＴＣサーバ１ １０３が依頼データを生成し、他のＷｅｂＲＴＣサーバ１０３宛てへ送信部４０２を介して依頼データを送信または配信する。
【０１０４】
（ステップＳ９０２）  
ステップＳ９０２では、制御部３０５は、判定部４０７として動作し、判定部４０７はステップＳ９０１で送信または配信した依頼データの回答信号を受信したかどうかを判定する。回答信号を受信した場合にはこの信号の送信元のＷｅｂＲＴＣサーバ１０３が通信帯域を融通可能であると判定してステップＳ９０３へ進み、回答信号を受信しなかった場合には通信帯域を融通可能なＷｅｂＲＴＣサーバ１０３がなかったと判定してステップＳ６０７へ進む。
【０１０５】
（ステップＳ９０３）  
ステップＳ９０３では、制御部３０５は、判定部４０７、帯域制御部４０８として動作し、回答信号に基づいて、帯域制御部４０８は高解像映像データのために通信帯域を確保する。この結果、通信帯域を提供したＷｅｂＲＴＣサーバ１０３は、この通信帯域を提供する間（高解像映像データの送信期間）では扱う通信帯域が縮小されることになる。  
ステップＳ９０３が終了したら、ステップＳ６０６へ進む。
【０１０６】
以上のように本実施形態によれば、ネットワークを経由して複数の映像ソースと宛先端末との間を常時接続する映像通信サーバ（ＷｅｂＲＴＣサーバ１０３）は、宛先端末に付与される通信帯域の優先度に従って、優先度が高い宛先端末への高解像映像データの通信が必要になった場合には、優先度の低い宛先端末が使用している通信帯域を縮小することによって、優先度が高い宛先端末が使用する通信帯域を拡大することが可能になる。また、高解像映像データの属性情報を取得することによって、高解像映像データの通信が必要とする通信帯域及び期間を算出することができるので、宛先端末での管理者はいつになれば高解像映像データがダウンロード完了になるか（ストリームで映像が再生されている場合には、高解像映像データの再生が終了するか）を事前に知ることが可能になる。
【０１０７】
本実施形態のサーバは、コンピュータとプログラムによっても実現でき、プログラムを記録媒体（または記憶媒体）に記録することも、ネットワークを通して提供することも可能である。  
また、以上の各装置及びそれらの装置部分は、それぞれハードウェア構成、またはハードウェア資源とソフトウェアとの組み合せ構成のいずれでも実施可能となっている。組み合せ構成のソフトウェアとしては、予めネットワークまたはコンピュータ読み取り可能な記録媒体（または記憶媒体）からコンピュータにインストールされ、当該コンピュータのプロセッサに実行されることにより、各装置の動作（または機能）を当該コンピュータに実現させるためのプログラムが用いられる。
【０１０８】
また、「及び／または」とは、「及び／または」でつながれて列記される事項のうちの任意の１つ以上の事項という意味である。具体例を挙げると、「ｘ及び／またはｙ」とは、３要素からなる集合｛（ｘ）,（ｙ）,（ｘ,ｙ）｝のうちのいずれかの要素という意味である。もう１つの具体例を挙げると、「ｘ，ｙ，及び／またはｚ」とは、７要素からなる集合｛（ｘ）,（ｙ）,（ｚ）,（ｘ,ｙ）,（ｘ,ｚ）,（ｙ,ｚ）,（ｘ,ｙ,ｚ）｝のうちのいずれかの要素という意味である。
【０１０９】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【０１１０】
１０１…映像ソース、１０２…ネットワーク、１０３…ＷｅｂＲＴＣサーバ、１０４…宛先端末、２０１…中継装置、２０２…ビデオカメラ、２０３…ビデオレコーダ、２０４…アラーム装置、２０５…ボタン、２０６…ペダル、２１２…入力装置、２５１…クライアント端末、２５２…モバイル端末、３０１…通信インタフェース、３０２…記憶部、３０３…入力装置、３０４…出力装置、３０５…制御部、３０６…計時装置、３０７…電源部、３０８…外部インタフェース、４０１…映像取得部、４０２…送信部、４０３…映像監視部、４０４…属性取得部、４０５…帯域算出部、４０６…完了時刻算出部、４０７…判定部、４０８…帯域制御部。
【図１】
2020048052.tif 000003
【図２】
2020048052.tif 000004
【図３】
2020048052.tif 000005
【図４】
2020048052.tif 000006
【図５】
2020048052.tif 000007
【図６】
2020048052.tif 000008
【図７】
2020048052.tif 000009
【図８】
2020048052.tif 000010
【図９】
2020048052.tif 000011