図面 (/)

技術 映像通信サーバ、システム、方法及びプログラム

出願人 株式会社東芝東芝インフラシステムズ株式会社
発明者 町田淳
出願日 2018年9月19日 (2年2ヶ月経過) 出願番号 2018-174533
公開日 2020年3月26日 (7ヶ月経過) 公開番号 2020-048052
状態 未査定
技術分野 双方向TV,動画像配信等 広域データ交換 計算機間の情報転送
主要キーワード 完了期間 映像速度 アラーム発報 自動接続処理 監視管 アラーム装置 各監視エリア 回答信号
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年3月26日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

通信帯域混雑している場合でも高解像映像通信するための通信帯域を確保する。

解決手段

本実施形態の映像通信サーバは、接続部と、帯域制御部と、送信部を備える。接続部は、ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする。帯域制御部は、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する。送信部は、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する。

概要

背景

近年、例えば、店舗内に設置したカメラを使用した監視ステムでは、ネットワークを使用する映像通信システムが利用される。映像通信システムは、カメラにより撮影された映像をネットワーク経由で監視システムの端末装置に送信する。監視システムの端末装置は、一般的には、ネットワークに接続されたパーソナルコンピュータ(PC)であり、当該PCのWebブラウザ上で映像を受信できる。また、映像通信システムは、映像だけでなく、マイクから入力された音声もネットワーク経由で送信できる。

監視システムでは、監視管理者等のユーザが確実に、PCのWebブラウザで受信した映像をディスプレイ画面上で確認し、受信した音声をPCのスピーカ聴取できることが必要である。このような確実な監視処理を実現するためには、監視システムに適用する映像通信システムにおいては、映像を安定的に送信するための映像通信帯域の確保と長時間のセッションの確保が要求される。

概要

通信帯域混雑している場合でも高解像映像通信するための通信帯域を確保する。 本実施形態の映像通信サーバは、接続部と、帯域制御部と、送信部を備える。接続部は、ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする。帯域制御部は、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する。送信部は、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する。

目的

本発明が解決しようとする課題は、通信帯域が混雑している場合でも高解像映像を通信するための通信帯域を確保することができる映像通信サーバ、システム、方法及びプログラムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする接続部と、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する帯域制御部と、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する送信部と、を備える映像通信サーバ

請求項2

前記帯域制御部は、第1宛先端末への映像データの通信帯域を拡大する場合に、前記第1宛先端末の優先度より低い優先度を有する第2宛先端末が使用している通信帯域を縮小し、縮小した分の通信帯域を前記第1宛先端末に割り当てる請求項1に記載の映像通信サーバ。

請求項3

前記送信部が、指定した大きさを有する通信帯域を他の映像通信サーバが融通することが可能であるかどうかの回答を前記他の映像通信サーバへ依頼する依頼データを送信し、前記帯域制御部が、融通することが可能である場合には可能である回答信号を前記他の映像通信サーバから受け付け、前記通信帯域を制御する、請求項1に記載の映像通信サーバ。

請求項4

前記映像データに関する属性情報を含む属性データを、前記ネットワークを経由して取得する取得部と、前記属性データに基づいて前記映像データに対応する第1宛先端末に第1映像データを送信するために必要な第1通信帯域を算出する第1算出部と、前記第1宛先端末の優先度が前記第1通信帯域を許容するかどうかを判定する判定部と、をさらに備え、前記判定部が前記第1通信帯域を許容すると判定した場合に、前記帯域制御部が前記第1宛先端末用に前記第1通信帯域を確保し、他の宛先端末の映像データは前記第1通信帯域以外に割り当てる、請求項1乃至3のいずれか1項に記載の映像通信サーバ。

請求項5

前記第1映像データの属性データと前記第1通信帯域とに応じて、前記第1宛先端末に前記第1映像データの送信が完了する送信完了時刻を算出する第2算出部をさらに備え、前記送信部は、前記送信完了時刻を含む完了時刻データを前記宛先端末に送信する、請求項4に記載の映像通信サーバ。

請求項6

前記接続部はリアルタイムで前記映像データを送信可能にし、前記判定部が前記第1通信帯域を許容すると判定した場合に、前記接続部は、前記映像データの送信を不可能にし、前記複数の映像ソースのうちの少なくとも1つと宛先端末との間を接続し、前記第1映像データを送信可能にし、前記送信部は、前記第1通信帯域を使用して、前記第1映像データを前記第1宛先端末に送信する、請求項4または5に記載の映像通信サーバ。

請求項7

前記第1映像データは、既に記録されている映像データである、請求項4に記載の映像通信サーバ。

請求項8

前記取得部は、前記属性情報として、映像データのデータ量、映像データの宛先端末情報映像再生時間、及びリアルタイム映像であるか過去の映像であるかを示す映像識別情報、のうちの少なくとも1以上を含む、請求項4乃至7のいずれか1項に記載の映像通信サーバ。

請求項9

ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする接続部と、高いほど広い通信帯域を使用可能であり映像通信サーバに対応づけて設定される優先度に応じて映像通信サーバごとの通信帯域を制御する帯域制御部と、前記複数の映像データのそれぞれに対応する宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する送信部と、を備える映像通信サーバ。

請求項10

前記帯域制御部は、第1宛先端末への映像データの第1通信帯域を拡大する場合に、前記第1通信帯域を提供している第1映像通信サーバの優先度より低い優先度の第2映像通信サーバが使用している通信帯域を縮小するように指示し、縮小した分の通信帯域を、第1映像通信サーバを経由する前記第1宛先端末に割り当てる請求項9に記載の映像通信サーバ。

請求項11

前記映像データは、WebRTC方式適合した映像データである、請求項1乃至10のいずれか1項に記載の映像通信サーバ。

請求項12

映像データをそれぞれ出力する複数の映像ソースと複数の宛先端末とをネットワークを経由して常時接続するための第1映像通信サーバ及び第2映像通信サーバを備えるシステムにおいて、前記第1映像通信サーバは、映像データの送信用に第1通信帯域に通信帯域を拡大する場合に、第1映像通信サーバで前記第1通信帯域を確保することができるかどうかを判定する第1判定部と、前記第1判定部が前記第1通信帯域を確保することができないと判定した場合には、第2映像通信サーバが前記第1通信帯域を融通することが可能であるかどうかの回答を、前記第2映像通信サーバへ依頼する依頼データを送信する送信部と、を備え、前記第2映像通信サーバは、前記依頼データを受信し、前記第1通信帯域を融通することが可能であるかどうかを判定する第2判定部と、前記第2判定部が前記第1通信帯域を融通することが可能であると判定した場合に、前記第1通信帯域を融通することが可能である回答信号を前記第1映像通信サーバへ送信し、前記第1通信帯域を開放する帯域制御部と、前記第1映像通信サーバは、前記回答信号を受信し、前記第1通信帯域を確保する帯域制御部をさらに備える、システム。

請求項13

映像データをそれぞれ出力する複数の映像ソースと複数の宛先端末とをネットワークを経由して常時接続し、高いほど広い通信帯域を使用可能である優先度を付与された第1映像通信サーバ及び第2映像通信サーバを備えるシステムにおいて、前記第1映像通信サーバは、映像データの送信用に第1通信帯域に通信帯域を拡大する場合に、第1映像通信サーバで前記第1通信帯域を確保することができるかどうかを判定する第1判定部と、前記第1判定部が前記第1通信帯域を確保することができないと判定した場合には、前記第1通信帯域を融通することと第1映像通信サーバの優先度とを含む依頼データを前記第2映像通信サーバへ送信する送信部と、を備え、前記第2映像通信サーバは、前記依頼データを受信し、前記第1映像通信サーバの優先度が前記第2映像通信サーバの優先度より高いかどうかを判定する第2判定部と、前記第1映像通信サーバの優先度が前記第2映像通信サーバの優先度より高いと判定した場合に、前記第1通信帯域を融通することが可能である回答信号を前記第1映像通信サーバへ送信し、前記第1通信帯域を開放する帯域制御部と、前記第1映像通信サーバは、前記回答信号を受信し、前記第1通信帯域を確保する帯域制御部をさらに備える、システム。

請求項14

ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にし、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御し、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信すること、を備える映像通信方法

請求項15

コンピュータを、請求項1乃至11のいずれか1項に記載の映像通信サーバが備える各部として機能させるためのプログラム

技術分野

0001

本発明の実施形態は、映像通信サーバ、システム、方法及びプログラムに関する。

背景技術

0002

近年、例えば、店舗内に設置したカメラを使用した監視システムでは、ネットワークを使用する映像通信システムが利用される。映像通信システムは、カメラにより撮影された映像をネットワーク経由で監視システムの端末装置に送信する。監視システムの端末装置は、一般的には、ネットワークに接続されたパーソナルコンピュータ(PC)であり、当該PCのWebブラウザ上で映像を受信できる。また、映像通信システムは、映像だけでなく、マイクから入力された音声もネットワーク経由で送信できる。

0003

監視システムでは、監視管理者等のユーザが確実に、PCのWebブラウザで受信した映像をディスプレイ画面上で確認し、受信した音声をPCのスピーカ聴取できることが必要である。このような確実な監視処理を実現するためには、監視システムに適用する映像通信システムにおいては、映像を安定的に送信するための映像通信帯域の確保と長時間のセッションの確保が要求される。

先行技術

0004

特開2016−82419号公報
特表2016−517642号公報

発明が解決しようとする課題

0005

監視システム等に適用する映像通信システムには、映像を安定的に送信するための映像通信の帯域の確保と長時間のセッションの確保が要求されるため、映像や音声を送信するための専用回線や、専用の映像再生用ソフトウェア実装されることが望ましい。しかし、いわば監視処理専用のような映像通信システムを利用する場合には、監視システムの構築に高いコストが要求される。近年では、ネットワーク上において、リアルタイムでの映像通信(音声通信も含む)が可能なWebRTC方式等を適用した映像通信システムが注目されている。しかし、この映像通信システムを監視システム等に適用することは容易ではない。

0006

このように、WebRTC方式等を適用した映像通信システムは、専用回線や専用の映像再生用のソフトウェアを使用することなく、監視システム等に適用可能である。

0007

しかしながら、ネットワークを使用して、高解像度の映像データを通信する必要が生じたときに、通信帯域混雑していて高解像映像を通信するための通信帯域の確保ができない場合がある。特に、重要かつ緊急性のある映像データを管理者等の端末装置へ急遽送信しなければならなくなった場合に、このような映像データがいつでも必ず管理者等の端末装置に送信されることが保証されているかどうかは非常に重要な問題である。さらに、このような映像データがリアルタイム映像データでなく過去の映像データである場合には、この映像データのダウンロードをできるだけ早急に完了することも重要である。

0008

本発明が解決しようとする課題は、通信帯域が混雑している場合でも高解像映像を通信するための通信帯域を確保することができる映像通信サーバ、システム、方法及びプログラムを提供することである。

課題を解決するための手段

0009

本実施形態の映像通信サーバは、接続部と、帯域制御部と、送信部を備える。接続部は、ネットワークを経由して複数の映像ソースと複数の宛先端末との間を常時接続し前記複数の映像ソースから前記複数の宛先端末へ複数の映像データを送信可能にする。帯域制御部は、前記複数の映像データのそれぞれに対応する宛先端末ごとに、高いほど広い通信帯域を使用可能であり宛先端末に対応づけて設定される優先度に応じて宛先端末ごとの通信帯域を制御する。送信部は、前記宛先端末ごとの通信帯域に応じて前記複数の映像データを対応する宛先端末に送信する。

図面の簡単な説明

0010

実施形態に係る映像通信システムの構成を説明するためのブロック図。
図1に示すシステムのうち、1つの映像ソースと、複数のWebRTCサーバと、1つの宛先端末とを示す図。
図2に示す映像通信サーバのハードウェアの構成の一例を示すブロック図。
図3に示す制御部のソフトウェアの構成の一例を示すブロック図。
実施形態に係る映像通信システム内の動作の一例を示すシーケンス図。
実施形態に係る映像通信サーバが通信帯域を確保するための動作の一例を示すフローチャート
実施形態に係る映像通信サーバが映像送信完了時刻を宛先端末へ送信する動作の一例を示すフローチャート。
実施形態に係る映像通信システム内の、図5とは異なる動作の一例を示すシーケンス図。
実施形態に係る映像通信サーバが通信帯域を確保するための図8に対応した動作の一例を示すフローチャート。

実施例

0011

以下、本発明の一側面に係る実施の形態(以下、「本実施形態」とも表記する)を、図面に基づいて説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。

0012

[システムの構成]
まず、図1を参照して、実施形態に係る映像通信サーバが適用されるシステム全体について説明する。図1は、映像及び/または音声を取得して映像データを作成及び/または蓄積している映像ソース101、本実施形態に係るWebRTC(Web-based real-time communication)サーバ103、WebRTCサーバ103を経由して映像データを受信する宛先端末104の適用場面の一例を示す。WebRTCサーバ103で採用されているWebRTC方式(「WebRTCプロトコル」とも称することがある)は、Webを使用してリアルタイムなコミュニケーションをやり取りする技術である。例えば、WebRTC方式を使用すれば、リアルタイムな映像を送信することができる。

0013

WebRTCサーバ103は、ネットワーク102を経由して、特定の映像ソース101と特定の宛先端末104との間にセッションを確立し、この映像ソース101とこの宛先端末104との間を常時接続し、映像ソース101から宛先端末104への通信帯域を確保して、映像通信及びデータ通信を可能にする。また、WebRTC方式には一般的に、メディアチャネルと、データチャネルとがある。メディアチャネルは、映像と音声のデータ通信方式を示し、このチャネルではリアルタイムに映像データや音声データを送信するプロトコルが採用されている。データチャネルは、任意のデータを送信することができる通信方式を示し、低遅延文字列やバイナリデータ(映像データ以外のデータ)を送信する。また、WebRTCサーバ103は、映像ソース101と宛先端末104との間で常時接続する際に、シグナリング処理を行い、この処理を受けて映像ソース101と宛先端末104との間にセッションが確立される。本実施形態では、WebRTC方式に適合している映像データを扱う。

0014

ネットワーク102は、複数の映像ソース101、複数のWebRTCサーバ103、複数の宛先端末104に接続し、それぞれの通信を仲介する。

0015

映像ソース101は、動画像及び静止画像(以下まとめて「映像」とも称す)を撮影することができるビデオカメラと、撮影した動画像及び静止画像を記憶するレコーダと、これらから動画像データ及び静止画像データをネットワーク102と通信するための中継装置とを備えている。ビデオカメラは、例えば、マイクを付属音声情報も取得する。ここでは、音声データは映像データに含まれてもよいとする。すなわち、本実施形態では、送受信する映像には音声も含まれてもよい。

0016

宛先端末104は、ネットワーク102との間で通信可能な一般的なコンピュータであり、例えば、パーソナルコンピュータ、スマートフォンスマートウォッチ等、ブラウザを有してネットワーク102に接続可能な端末である。

0017

次に、図2を参照して、映像ソース101と宛先端末104とについて主に説明する。図2は、本実施形態に係る図1に示すシステムのうち、1つの映像ソースと、複数のWebRTCサーバと、1つの宛先端末とを示す。図1に示すように、本実施形態の映像通信システムは、例えば、監視システムに適用し、WebRTCサーバ103、及びインターネット等のネットワーク102を主要部として映像データ及び制御データ等を送受信する。

0018

ネットワーク102には、監視対象側(ここでは、映像ソース101)の中継装置201と、管理側(ここでは、宛先端末104)のクライアント端末251と、が接続される。

0019

監視対象側(映像ソース101)は、例えばコンビニエンスストアなどの店舗であり、監視システムを構成する複数のビデオカメラ202、ビデオレコーダ203及びアラーム装置204を有する。なお、監視対象側(映像ソース101)は、本実施形態では店舗の内部エリアとするが、各種の建物施設等としてもよく、適用範囲は任意である。また、アラーム装置204は例えば、警報用のボタン205やペダル206を備える。

0020

管理側(ここでは、宛先端末104)は、例えば店舗を運営する管理者の事務所自宅等であり、クライアント端末251、及び/またはモバイル端末252を有する。クライアント端末251は、例えば、パーソナルコンピュータ(PC)であり、ネットワーク102に接続し、WebRTCサーバ103との連携により、監視対象側(映像ソース101)から送信される映像を受信する。モバイル端末252は、ネットワーク102とは無線通信を確立することがクライアント端末251とは異なるが、実行する動作はクライアント端末251と本質的に同様である。宛先端末104が受信する映像データは、複数のビデオカメラ202から受け取ったものであり、クライアント端末251またはモバイル端末252の画面がビデオカメラ202の数に応じて4分割または8分割等されて、映像が端末の画面に表示されてもよい。

0021

複数のビデオカメラ202はそれぞれ、店舗内の各監視エリアを撮影できる箇所に配置されて、撮影した映像を有線または無線経由で映像データとして出力する。なお、図示していないが、ビデオカメラ202や店舗内のレジスタの近傍に配置されたマイクや、ビデオカメラ202に内蔵されたマイクから、映像と共に音声も有線または無線経由で映像データに含め出力される。

0022

ビデオレコーダ203は、ビデオカメラ202から出力された映像を記録(録画及び録音)する記憶装置であり、例えばハードディスクドライブ、またはソリッドステートドライブを有する。ビデオレコーダ203は、主に過去に撮影され記録された映像データを記憶している。この過去の映像データは、通常、高解像度の映像(「高精細な映像」とも称す)を含むデータであり、宛先端末104からのリクエストまたはWebRTCサーバ103からのリクエスト、またはアラーム装置204のリクエストによって要求される。この本実施形態のビデオレコーダ203は、いわゆるサーバ機能を含み、ビデオカメラ202から出力された映像データを、中継装置201を経由してネットワーク102に送信することができる。具体的には、ビデオレコーダ203は、ビデオカメラ202により撮影された映像のライブ送信(例えば、WebRTC方式を使用)を実行することができ、または、記憶されている映像データから所望の映像データ(典型的には、高解像映像データ)を取り出して送信することができる。

0023

アラーム装置204は、中継装置201からネットワーク102を経由して、WebRTCサーバ103に対してアラーム通知を実行する。アラーム装置204は、例えば、店舗内のレジスタの近傍に配置された警報用のボタン205やペダル206の操作に応じて、緊急時または非常時におけるアラーム(警報)信号を出力して、WebRTCサーバ103へ(すなわち、対応する宛先端末104へ)アラーム通知を実行する。

0024

なお、アラーム装置204は、ビデオカメラ202により撮影された映像に基づいて異常検知した場合に、アラーム信号を出力する構成でもよい。具体的には、アラーム装置204は、通常では、特定エリアでのビデオカメラ202により撮影される映像には変化が発生しない状況において、当該特定エリアでの映像に変化が発生した場合には、異常が発生したと検知する。例えば、通常では当該特定エリアが人の存在しないエリアの場合に、ビデオカメラ202により撮影される映像に人が含まれている場合には、異常が発生したと検知する。この異常検知は、ソフトウェアでも実現することができるので、アラーム装置204以外に、WebRTCサーバ103及び/または宛先端末104で実行されることも可能である。異常検知は、アラーム装置204、WebRTCサーバ103、及び宛先端末104のうちの少なくとも2つに基づいて総合的に異常であるかどうかを判定してもよい。

0025

また、本実施形態では、店舗等の監視対象側(映像ソース101)でのアラームの発報に応じて、WebRTC方式等の映像通信接続を自動的に実行する構成であるが、アラームの発報に限定することなく、所定のイベントの発生に応じて、通信接続を自動的に実行する構成でもよい。

0026

以下、具体的に異常検知の一例を示す。
監視対象側(映像ソース101)において、店舗内の緊急時に、担当者により警報用のボタン205またはペダル206が操作されてアラーム発報があると、アラーム装置204はアラーム信号を出力する。アラーム装置204からのアラーム信号は中継装置201によりネットワーク102に送信されて、WebRTCサーバ103に対してアラーム通知が実行される。監視対象側(映像ソース101)において、店舗内の緊急時に、担当者により警報用のボタン205またはペダル206が操作されてアラーム発報があると、アラーム装置204はアラーム信号を出力する。アラーム装置204からのアラーム信号は中継装置201によりネットワーク102に送信されて、WebRTCサーバ103に対してアラーム通知が実行される。

0027

WebRTCサーバ103は、このアラーム通知を受信すると、予め登録されている管理側(宛先端末104)のクライアント端末251に対して、自動接続処理を実行する。すなわち、WebRTCサーバ103は、クライアント端末251のブラウザを起動させて、ネットワーク102を経由するWebRTC方式の通信接続処理を実行する。WebRTCサーバ103の自動接続処理により、クライアント端末251に対するWebRTC方式の通信接続が確保されると、セッションが確保されて、WebRTC方式のリアルタイムな映像通信が可能となる。これにより、監視対象側(映像ソース101)のビデオレコーダ203は、中継装置201及びネットワーク102を経由して、クライアント端末251に対して映像をリアルタイムに送信できる。

0028

また、WebRTCサーバ103は、選択したモバイル端末252に対して、自動接続処理を実行することもできる。すなわち、上記のクライアント端末251の場合と同様な動作によってモバイル端末252は、監視対象側(映像ソース101)のビデオレコーダ203から、中継装置201及びネットワーク102を経由して、映像データをリアルタイムに受信することができる。

0029

クライアント端末251は、例えば、WebRTCサーバ103からダウンロードされて、WebRTC方式により、ネットワーク102に接続してリアルタイムな映像及び/または音声の通信を可能とするソフトウェアがインストールされている。なお、クライアント端末251は、予めブラウザに当該ソフトウェアが実装されている構成でもよい。クライアント端末251は、ネットワーク102を経由して、監視対象側(映像ソース101)からWebRTC方式によりリアルタイムで送信される映像を、Webブラウザ(以下「ブラウザ」と称す)で受信し、ディスプレイの画面上で再生することができる。

0030

モバイル端末252は、スマートフォンを代表とする携帯端末であり、クライアント端末251と同様のソフトウェアがインストールされている。管理者は、モバイル端末252を操作することにより、クライアント端末251と同様に、ネットワーク102を経由して、監視対象側(映像ソース101)からWebRTC方式によりリアルタイムで送信される映像を、Webブラウザで受信し、ディスプレイの画面上で再生することができる。

0031

管理側(宛先端末104)では、WebRTC方式の通信接続が確保されると、管理者は、クライアント端末251のブラウザ上において、店舗内のビデオカメラ202により撮影されたライブ映像(音声も含む)を含む映像データを受信し、ディスプレイの画面上で確認できる。音声は、クライアント端末251のスピーカから出力できる。また、管理者は、クライアント端末251のブラウザ上において、ビデオレコーダ203に記録された映像データ(すなわち、過去に記録された映像データ)を受信し、ディスプレイの画面上で確認することもできる。通常は、クライアント端末251が過去に記録された映像データ(ライブ映像より高解像映像である)をダウンロードして、ダウンロード完了後にクライアント端末251のディスプレイ上に再生して確認することができる。また、クライアント端末251が過去に記録された映像データを、通常のライブ映像時の通信帯域よりも広い通信帯域によって映像データを受信しつつクライアント端末251の画面上で再生(ストリーム再生)して確認してもよい。ストリーム再生の場合には受信すると同時に確認することができる。一方、ダウンロードした映像データを再生する場合には、任意の撮影フレームに移動することが可能である。

0032

管理側(宛先端末104)のクライアント端末251の動作について簡単に説明する。クライアント端末251は、電源オン状態でブラウザ等の機能が起動している場合には、WebRTCサーバ103の自動接続処理により、WebRTC方式の通信接続が確保される。すなわち、クライアント端末251は、監視対象側(映像ソース101)に対してWebRTC方式のリアルタイムな映像通信が可能となる。

0033

クライアント端末251は、中継装置201及びネットワーク102を経由して、監視対象側(映像ソース101)のビデオレコーダ203からリアルタイムに送信される映像データを受信して再生できる。なお、音声はクライアント端末251に内蔵されたスピーカにより出力される。具体的には、クライアント端末251は、ブラウザ上において、店舗内のビデオカメラ202により撮影されたライブ映像を含む映像データを受信し、ディスプレイの画面上に映像を再生できる。また、クライアント端末251は、ブラウザ上において、ビデオレコーダ203に記録された映像(録音された音声も含む)を受信し、ディスプレイの画面上に映像を再生することができる。

0034

[映像通信サーバのハードウェアの構成]
次に、図3を用いて、本実施形態に係るWebRTCサーバ103のハードウェアの構成の一例について説明する。
図3に示される通り、本実施形態に係るWebRTCサーバ103は、通信インタフェース301、記憶部302、入力装置303、出力装置304、制御部305、計時装置306、電源部307、及び外部インタフェース308、が電気的に接続されたコンピュータを含む。なお、図3では、通信インタフェース及び外部インタフェースをそれぞれ、「通信I/F」及び「外部I/F」と記載している。

0035

制御部305は、CPU(Central Processing Unit)、RAM(Random Access Memory)、ROM(Read Only Memory)等を含み、情報処理に応じて各構成要素の制御を行う。記憶部302は、例えば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置であり、制御部305で実行される、WebRTCサーバ103での通信帯域を確保するための通信帯域確保実行プログラム、映像ソース101のビデオレコーダ203から取得する高解像映像データを宛先端末104へ送信する処理が完了する時刻を算出するための送信完了時刻算出プログラム、及び/またはWebRTCサーバ103が取得した制御データ、映像及び音声データ等を記憶してもよい。

0036

通信帯域確保のための通信帯域確保実行プログラムは、(例えば、高解像映像データを通信する目的で)特定のデータを送信する通信帯域を確保するために、他の映像データを送信している通信帯域を縮小するための処理(図6)、または他のWebRTCサーバ103から通信帯域を融通してもらうための処理(図9)を実行させるためのプログラムである。また、送信完了時刻算出プログラムは、映像ソース101のビデオレコーダ203に格納されている高解像映像データを宛先端末104に送信して高解像映像データの送信が完了する時刻を算出するための処理(図7)を実行させるためのプログラムである。

0037

通信インタフェース301は、例えば、近距離無線通信(例えば、ブルートゥース(登録商標))モジュール、有線LAN(Local Area Network)モジュール、無線LANモジュール等であり、ネットワーク102を介した有線または無線通信を行うためのインタフェースである。通信インタフェース301は、WebRTCサーバ103を、映像ソース101(例えば、中継装置201、ビデオカメラ202、ビデオレコーダ203、及びアラーム装置204)と、宛先端末104(例えば、クライアント端末251、及び/またはモバイル端末252)とに接続するためのインタフェースである。通信インタフェース301は、制御部305によって制御される。通信インタフェース301は、ネットワークを介して受信した外部装置(例えば、映像ソース101)からの情報を制御部305へ受け渡す。このネットワーク102を介した通信は、無線または有線のいずれでもよい。なお、通信インタフェース301は、ネットワークを介して、情報を外部装置へ送信することができてもよい。ネットワークは、インターネットを含むインターネットワークでもよいし、WAN(Wide Area Network)のような他の種類のネットワークであってもよい。

0038

記憶部302は、コンピュータその他の装置、及び機械等が、記録されたプログラム等の情報を読み取り可能なように、当該プログラム等の情報を、電気的、磁気的、光学的、機械的または化学的作用によって蓄積する媒体である。WebRTCサーバ103は、この記憶部302から、通信帯域確保のための通信帯域確保実行プログラム、送信完了時刻算出プログラム、及びWebRTCサーバ103が取得した制御データ等を取得してもよい。
また、記憶部302は、宛先端末104ごとに、通信帯域を優先的に使用する権限を示す優先度を記憶しておく。例えば、優先度が高いほど広い通信帯域を使用可能である。この優先度は、例えば、宛先端末104の管理者との契約によって予め設定される。もちろん、管理者とこの通信サービス事業者との間で契約をリアルタイムで変更して優先度を上げ下げすることも可能である。また、優先度は、WebRTCサーバ103ごとに設定されていてもよく、記憶部302はこの優先度を記憶しておいてもよい。さらに、この2種類の優先度を適応的に選択して使用するように、例えば記憶部302で設定されていてもよい。

0039

他に、記憶部302は、WebRTCサーバ103がリアルタイム映像を監視して異常であると判定する判定基準を記憶する。この判定基準は、宛先端末104ごとに設定することが可能であり、宛先端末104の管理者がネットワーク102を経由して記憶部302にアップロードしてもよい。

0040

入力装置303は、外部から入力を受け付ける装置であり、例えば、タッチパネル物理ボタンマウスキーボード等である。出力装置304は、外部へ出力を行う装置であり、音声(識別できれば単なる音でもよい)、表示等で情報を出力し、例えば、ディスプレイ、スピーカ等である。外部インタフェース308は、外部と本体との媒介をするためのものであり、例えば、USBポート等であり、外部装置と接続するためのインタフェースである。

0041

計時装置306は、時間を計測する装置であり、日時を計測できる。例えば、計時装置306はカレンダーを含む時計であり、現在の日時の情報を制御部305へ渡す。

0042

電源部307は、電力を供給可能なものであれば何でもよく、例えば、充電可能な2次電池または通常のコンセントから取得可能な交流電源からのエネルギー供給を受けるものである。電源部307は、WebRTCサーバ103本体に搭載されている各要素へ電力を供給する。電源部307は、例えば、通信インタフェース301、記憶部302、入力装置303、出力装置304、制御部305、計時装置306、及び外部インタフェース308へ電力を供給する。

0043

なお、WebRTCサーバ103の具体的なハードウェア構成に関して、実施形態に応じて、適宜、構成要素の省略、置換及び追加が可能である。例えば、制御部305は、複数のプロセッサを含んでもよい。WebRTCサーバ103は、複数台情報処理装置で構成されてもよい。
[WebRTCサーバ103のソフトウェアの構成]
次に、図4を用いて、本実施形態に係るWebRTCサーバ103のソフトウェア構成の一例を説明する。
WebRTCサーバ103の制御部305は、必要なプログラムを実行する際に、記憶部302に記憶された、通信帯域確保実行プログラム、及び/または送信完了時刻算出プログラムをRAMに展開する。そして、制御部305は、RAMに展開された、通信帯域確保実行プログラム、及び/または送信完了時刻算出プログラムをCPUにより解釈及び実行して、各構成要素を制御する。これによって、図4に示される通り、本実施形態に係るWebRTCサーバ103は、映像取得部401、送信部402、映像監視部403、属性取得部404、帯域算出部405、完了時刻算出部406、判定部407、及び帯域制御部408を備える。

0044

映像取得部401は、通信インタフェース301を介して、ネットワーク102を介して映像ソースと宛先端末との間を常時接続し、映像ソースから宛先端末への映像データを送信可能にしつつ、映像データを参照または取得する。映像取得部401は、ネットワーク102を経由して通信する複数の映像ソース101から送信されるそれぞれの映像データを取得する。この映像データは、WebRTC方式で通信され、リアルタイム映像データ、または、映像ソース101が過去に取得した(リアルタイム映像ではない)高解像映像データである。また、映像取得部401は、受け取った映像データを送信部402へ渡し、宛先端末104へ映像データを送信させる。

0045

映像取得部401は、映像データよりも先にこの映像データに関する情報を含んだデータを受け取る。なお、このデータは、映像データのヘッダに含めてあってもよい。この映像データに関する情報は、例えば、受け取る映像データが低解像の映像データ(例えば、リアルタイム映像データ)であるのか、高解像度の映像データであるのかの識別情報を含んでいる。例えば、映像データがリアルタイム映像データである場合には、映像監視部403が高解像映像データの通信開始を指示し、帯域制御部408が通信帯域を制御した後に、映像ソース101へリクエスト信号を送信するまで(もしくはリクエスト信号を送信して高解像映像データを受信するまで)、リアルタイム映像データを映像ソース101から受信し、宛先端末104へ送信し続ける。

0046

また、映像取得部401は、宛先端末104からのリクエスト信号を受信して、そのリクエスト内容を記憶部302が記憶してもよい。このリクエストは、例えば、宛先端末104の管理者が、特定の映像ソース101が撮影した特定の日時及び/または場所の高解像映像データを要求することであり、宛先端末104からこのリクエストを含むリクエスト信号を映像取得部401が受け取ってもよい。このリクエスト信号は、例えば、映像ソース101のうちの特定のビデオカメラ202が取得した特定の日時に撮影された高解像映像データを要求すること等でもよい。また、このリクエスト信号は、リクエスト内容が実行されるべき時刻前であればいつ送信されてもよい。

0047

さらに、映像取得部401は、映像ソース101からのリクエスト信号を受信して、その内容を判定部407へ渡すことも行う。映像取得部401は、受信したリクエスト信号を記憶部302に記憶させ、記憶させた旨を判定部407へ知らせ、その後、判定部407は記憶部302からリクエスト信号の内容を取得してもよい。

0048

送信部402は、通信インタフェース301を介して、ネットワーク102経由で映像ソース101から映像取得部401を通過した映像データを宛先端末104へ送信する。例えば、リアルタイム映像データである場合には、映像データは高解像映像データではなく低解像映像データであるので、映像取得部401を通過した映像データをそのまま送信部402が受け取り、通信インタフェース301を介してネットワーク102を経由して宛先端末104へ送信する。映像データが高解像映像データである場合には、帯域制御部408が宛先端末104と宛先端末104との間の通信帯域を適切に拡張した後で、拡張された通信帯域を使用して映像ソース101から映像取得部401が取得した高解像映像データを送信部402が宛先端末104へ送信する。また、送信部402は、映像監視部403及び判定部407からのリクエスト信号(「要求信号」とも称す)、依頼データ等を映像ソース101、他のWebRTCサーバ103に送信する。

0049

映像監視部403は、映像取得部401が取得した低解像の映像データ(例えば、リアルタイム映像データ)を受け取り、この映像データの内容を監視し、高解像映像データを映像ソース101へリクエストする必要があるかどうかを判定し、リクエストする必要がある場合にはリクエスト信号を映像ソース101へ向けて送信するように送信部402へ指示する。
映像監視部403は、例えば、予め設定されている判定基準を参照して、取得した映像データが判定基準を満たしているかどうかを判定し、判定基準を満たしている場合にはリクエスト信号を送信するように送信部402に指示する。判定基準は、例えば、特定の場所に特定の撮影角度で設置されたビデオカメラ202により撮影される映像に人が含まれる画像があることである。この場合、映像監視部403がこの判定基準を満たす映像データを発見した場合には、高解像映像データを宛先端末104へリクエストするリクエスト信号を送信するように送信部402に指示する。
なお、この判定基準は、管理者及び/または映像ソース101でのビデオカメラ202の配置等にも依存する。また、判定基準に音声の大きさを含めてもよい。例えば、ビデオカメラ202が音声も同時に録音していて、この音声の出力値(単位は例えば、dB)がしきい値以上に大きい場合に判定基準を満たす、としてもよい。

0050

属性取得部404は、通信インタフェース301を介して映像ソース101から受け取る映像データの属性情報を取得して帯域算出部405へ渡す。映像データの属性情報は、映像データの属性を示す情報であれば何でもよく、例えば、映像データのデータ量、映像データの宛先端末、映像撮影日時、映像撮影期間、及びリアルタイム映像であるか過去の映像であるかを示す映像識別情報がある。なお、映像識別情報は、映像データのヘッダに含まれている場合には不要である。本実施形態では、この映像データの属性情報は高解像映像データの通信が開始されるよりも前に属性取得部404が受け取り、この属性情報に基づいて制御部305が高解像映像データの通信帯域を確保するための制御を開始する。

0051

帯域算出部405は、属性取得部404が取得した属性情報から、属性情報に対応する高解像映像データのデータ量に基づいて、この高解像映像データが必要とする通信帯域を算出する。通信帯域は、通常は、属性情報に含まれるデータ量と、再生期間(映像撮影期間に対応)とによって決まる。もし、後に判定部407で通信帯域を確保できないと判定した場合には、再生期間に相当する高解像映像データの送信期間を増やして通信帯域が狭くても送信を完了することができるように送信期間を調整してもよい。この場合は通信帯域が必要な通信帯域より狭いので、高解像映像データをストリーム再生する場合には送信期間を変えずに、高解像映像データの画質オリジナルの画質より下がることになり、一方、高解像映像データをダウンロードする場合には、画質は変わらないがダウンロードを完了する時間が長くなる。また、通信帯域が必要な通信帯域より狭い状態でストリーム再生をする場合には、送信期間を長くしてオリジナル画質を保つこともできるが、この場合は再生速度が通常より低速になる。

0052

なお、高解像映像データをダウンロードする場合には、データ量によってダウンロードする期間はほぼ決定されるので、帯域算出部405はデータ量だけで通信帯域を決定してもよい。通信帯域が広いほどダウンロードする期間は短くなるが、特定の期間(例えば、5秒)で終了する程度を目安に通信帯域を確保するように帯域算出部405は通信帯域を算出してもよい。また、完了時刻算出部406で算出する時刻(ダウンロード期間でもよい)が所望の期間内になるまで、完了時刻算出部406の結果を帯域算出部405へフィードバックして帯域算出部405で再計算してもよい。

0053

完了時刻算出部406は、帯域算出部405が算出した通信帯域と、属性取得部404が取得した高解像映像データのデータ量とに基づいて、リクエストした高解像映像データを全て宛先端末104に送信するまでにかかる期間を算出し、計時装置306から時刻を参照して、この期間と時刻に基づいてリクエストした高解像映像データを全て宛先端末104へ送信完了する時刻を算出する。その後、完了時刻算出部406は、算出した時刻を、送信部402を介して宛先端末104に送信する。宛先端末104では、ポップアップ等で高解像映像データがいつ送信完了するかを管理者は知ることができる。送信完了時刻を管理者に告知する方法は様々であり、画面に時刻を表示するだけでなく、スピーカを使用して音声で時刻を知らせてもよい。

0054

また、完了時刻算出部406は、属性情報が映像撮影期間を含み、通信帯域とデータ量とからこの映像撮影期間内に高解像映像データの送信完了を実現できると判定した場合には、映像撮影期間内に高解像映像データが送信完了になるように通信帯域を調整してもよい。この場合には映像撮影時と同様な映像速度(ビデオレコーダ203での高解像映像データの再生速度と同一)で宛先端末104の管理者は閲覧することになる。なお、宛先端末104が高解像映像データをダウンロードする場合には、通信帯域が広いほど短時間で完了時刻が早くなるので、映像撮影期間は重要ではなく属性情報に含まれていなくてもよい。

0055

判定部407は、WebRTCサーバ103で確保している通信帯域を調整することによって、帯域算出部405が算出した通信帯域を確保することができるかどうかを判定する。判定部407は、通信帯域を提供する宛先端末104の優先度と、現在の通信帯域の占有状態と、高解像映像データが必要とする通信帯域と、完了時刻算出部406が算出した送信完了時刻と、に基づいて、通信帯域を確保することができるかどうかを判定する。なお、判定部407は、今後予定されている通信帯域の使用状態も考慮して、通信帯域を確保することができるかどうかを判定してもよい。

0056

判定部407が、自サーバではこの通信帯域を確保することができないと判定した場合には、例えば、ストリーム再生をする場合にはデータ量を減少させて送信可能かどうかを判定してもよい。この場合、判定部407は、例えば、必要とする高解像映像データの映像撮影期間を少なくしたものでもよいかどうかを判定し、この場合に拡張された通信帯域の占有時間を保ちつつ通信帯域を縮小させて、通信帯域が確保できるかを判定する手順を繰り返す。また、高解像映像データをダウンロードする場合には、通信帯域を確保することができないと判定されたとき、ダウンロード時間(「ダウンロード期間」とも称す)が長くなるがそれでもよいかどうかを予め決めた判定基準を参照して判定する。もしくは、ダウンロード時間を宛先端末104に示し、管理者がダウンロード時間の可否を判断してもよい。

0057

また、判定部407は、自サーバでは通信帯域を確保することができないと判定した場合には、他のWebRTCサーバ103から通信帯域を融通してもらえないかを依頼する依頼データを、送信部402を介して送信する。依頼データは、例えば、必要な通信帯域とその通信帯域を使用したい時間帯(開始及び終了時刻)との情報を含む。

0058

さらに、判定部407は、宛先端末104から送信された、高解像映像データの閲覧を要求するリクエスト信号を受信して、この閲覧要求応えることができるかどうかを判定してもよい。また、判定部407は、映像ソース101から送信された、高解像映像データを宛先端末104へ閲覧させることを要求する(例えば、アラーム装置204がアラームを発した場合)リクエスト信号を受信して、閲覧要求に応えるかどうかを判定してもよい(アラームの場合には通常閲覧させる)。

0059

帯域制御部408は、判定部407が通信帯域を確保することができると判定した場合には、WebRTCサーバ103が扱うことができる通信帯域を、優先度を考慮して宛先端末104間で調整するように制御する。また、帯域制御部408は、通信帯域を確保することができると判定した場合には、高解像映像データを送信開始するように映像ソース101へ要求する要求信号を送信部402へ指示する。

0060

<その他>
WebRTCサーバ103の動作に関しては後述する動作例で詳細に説明する。なお、本実施形態では、WebRTCサーバ103の制御部305はいずれも汎用のCPUによって実現されてもよい。しかしながら、以上の機能の一部または全部が、1または複数の専用のプロセッサにより実現されてもよい。また、WebRTCサーバ103の構成に関して、実施形態に応じて、適宜、省略、置換及び追加が行われてもよい。

0061

[動作例]
次に、図5図6図7図8、及び図9を用いて、WebRTCサーバ103の動作例を中心に説明する。

0062

図5は、2つの映像ソース101と、1つのWebRTCサーバ103と、2つの宛先端末104との間の一連の動作の一例を示すシーケンス図である。なお、以下に記載のシーケンス図で説明する処理手順は一例に過ぎず、各処理は可能な限り変更されてよい。また、以下で説明する処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。

0063

(ステップS501、S502)
ステップS501では映像ソース1 101が対応する宛先端末1 104へWebRTCサーバ103を経由してリアルタイム映像データを送信し、ステップS502では映像ソース2 101が対応する宛先端末2 104へWebRTCサーバ103を経由してリアルタイム映像データを送信している。

0064

(ステップS503)
ステップS503では、WebRTCサーバ103が映像ソース1 101及び映像ソース2 101のリアルタイム映像データに含まれる映像を監視する。WebRTCサーバ103は、予め設定されている判定基準に基づいて、映像が判定基準を満たすかどうかを監視する。この例では、ステップS503で映像が判定基準を満たしたと判定される。

0065

(ステップS504、S505)
ステップS504では、WebRTCサーバ103が高解像映像データを送信するように映像ソース1 101へ要求することを決定する。

0066

そして、ステップS505では、WebRTCサーバ103が映像ソース1 101へ、高解像映像データを送信する旨の要求信号を送信する。

0067

(ステップS506、S507)
ステップS506、ステップS507では、映像ソース1 101が要求信号をWebRTCサーバ103から受信したことを受けて、映像ソース1 101が記憶している高解像映像データの属性を含む属性情報をWebRTCサーバ103へ送信する。

0068

(ステップS508)
ステップS508では、WebRTCサーバ103がステップS507で受け取った属性情報に基づいて、WebRTCサーバ103が扱っている通信帯域を制御して、ステップS504で要求した高解像映像データの通信帯域を確保する。この結果、映像ソース1 101と宛先端末1 104との間の通信帯域は拡大され、映像ソース2 101と宛先端末2 104との間の通信帯域はこの拡大された分だけ縮小される。

0069

(ステップS509、S510)
ステップS509では、通信帯域を確保したので、高解像映像データの送信を開始するように映像ソース1 101へ指示することを決定する。

0070

そして、ステップS510では、WebRTCサーバ103が高解像映像データの送信を開始するように映像ソース1 101へ指示する指示信号を映像ソース1 101へ送信する。

0071

(ステップS511、S512)
ステップS511では、WebRTCサーバ103からの要求信号を受けて、映像ソース1 101は、WebRTCサーバ103を経由して宛先端末1 104との間で、ステップS508で確保された通信帯域を使用して高解像映像データを宛先端末1 104へ送信する。

0072

また、ステップS512では、ステップS508で確保された通信帯域を使用して低解像映像データ(例えば、リアルタイム映像データ)を映像ソース2 101が宛先端末2 104へ送信する。なお、ステップS511では、宛先端末1 104が高解像映像データをダウンロードする場合と、ストリーム再生する場合とがある。ダウンロードするかまたはストリーム再生するかの取り決めは、予め契約時に決定されて記憶部302が記憶していてもよいし、高解像映像データが送信されるときに宛先端末104へどちらを選択するかの選択データを送信し管理者が選択してもよい。

0073

図6は、WebRTCサーバ103が通信帯域を確保するための処理手順の一例を例示するフローチャートである。なお、以下に記載のフローチャートで説明する処理手順は一例に過ぎず、各処理は可能な限り変更されてもよい。また、以下で説明する処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。

0074

(起動)
まず、WebRTCサーバ103は管理者等に入力装置212を介して起動され、さらに初期の設定等の入力を受け付ける。WebRTCサーバ103の制御部305は、以下の処理手順にしたがって、処理を進める。

0075

(ステップS601)
ステップS601では、制御部305は、映像取得部401、送信部402として動作し、映像取得部401が映像ソースと宛先端末との間を常時接続し、映像ソース101からリアルタイム映像データを送信可能にし、送信部402がリアルタイム映像データを宛先端末104へ送信する。

0076

(ステップS602)
ステップS602では、制御部305は、映像監視部403及び/または判定部407として動作し、高解像映像データを宛先端末104へ送信する要求があるかどうかを判定する。制御部305は、送信する要求があると判定された場合には処理はステップS603へ進み、送信する要求があると判定されなかった場合にはステップS601へ戻るように動作を制御する。送信する要求があると映像監視部403が判定する場合は、例えば、映像取得部401が取得した映像データを分析することによって、より精細な映像データを閲覧する必要が生じる場合がある。また、より精細な映像データを送信する要求があると判定部407が判定する場合は、例えば、宛先端末104からの高解像映像データの送信依頼を判定部407が通信インタフェース301を介して受信した場合、映像ソース101から高解像映像データの送信依頼が発生する場合(例えば、アラーム装置204がアラームを発する場合)がある。

0077

(ステップS603)
ステップS603では、制御部305は、属性取得部404、帯域算出部405、完了時刻算出部406として動作し、映像ソース101から送信予定の高解像映像データの属性情報を属性取得部404が取得し、この高解像映像データが必要とする通信帯域を属性情報から帯域算出部405が算出する。また、この通信帯域を使用してこの高解像映像データの送信を完了する完了時刻を完了時刻算出部406が算出する。

0078

(ステップS604)
ステップS604では、制御部305は、判定部407として動作し、判定部407が算出された通信帯域を、必要とされる時間帯に確保することが可能であるかどうかを判定する。判定部407が通信帯域を確保することが可能であると判定した場合にはステップS605へ進み、可能であると判定しなかった場合にはステップS607へ進む。

0079

(ステップS605)
ステップS605では、制御部305は、帯域制御部408として動作し、高解像映像データを送信する宛先端末104が使用する通信帯域を確保し、その他の宛先端末104が使用する通信帯域を縮小する。

0080

(ステップS606)
ステップS606では、制御部305は、送信部402として動作し、確保した通信帯域を使用して映像ソース101から取得した高解像映像データを宛先端末104へ送信部402が送信する。

0081

(ステップS607)
ステップS607では、制御部305は、判定部407として動作し、高解像映像データのデータ量を減少させて送信することが可能かどうかを判定する。データ量を減少させるためには、例えば、高解像映像データの再生時間を短くすることがある。もし、解像度を落とした映像データがあれば、その映像データを送信してもよいかを判定してもよい。データ量を減少させる映像データ、解像度を落とした映像データを送信してもよいかどうかは、例えば、WebRTCサーバ103の事業者と宛先端末104の管理者との契約による設定に依存し、この設定は記憶部302に記憶されている。また、この他に、宛先端末104が高解像映像データをダウンロードする場合には、例えば、完了時刻算出部406が計算したダウンロード時間がしきい値よりも小さい場合には送信可能とする、としてもよい。

0082

(ステップS608)
ステップS608では、制御部305は、判定部407、送信部402として動作し、判定部407がデータ量を落として送信することは不可能であると判定した場合には、現在通信不可である旨を送信部402が高解像映像データを送信する予定の宛先端末104へ通知する。また、ダウンロード時間がしきい値よりも大きくなり送信不可能と判定される場合もある。

0083

(ステップS609)
ステップS609では、制御部305は、判定部407として動作し、計時装置306を使用して経過する時間を計測し、予め設定された時間が経過したら、ステップS604へ戻る。

0084

図7は、WebRTCサーバ103が、映像送信が完了する時刻を算出するための処理手順の一例を例示するフローチャートである。

0085

(起動)起動は図6の場合と同様である。

0086

(ステップS701)
ステップS701では、制御部305は、完了時刻算出部406として動作し、属性取得部404は、映像ソース101から送信される高解像映像データの属性情報と、ステップS603で算出された通信帯域とに基づいて、高解像映像データの通信が完了する期間を算出する。

0087

(ステップS702)
ステップS702では、制御部305は、判定部407として動作し、送信開始時刻を設定する。属性取得部404が取得した属性情報から送信開始時刻を取得して判定部407が設定する。また、宛先端末104の管理者等から送信開始時刻情報を含んだ指示信号が送信されて、判定部407が通信インタフェース301を介して送信開始時刻情報を受信して設定してもよい。

0088

(ステップS703)
ステップS703では、制御部305は、完了時刻算出部406として動作し、完了時刻算出部406は、ステップS701で算出された通信完了期間と、ステップS702で算出された送信開始時刻とから、送信完了時刻を算出する。

0089

(ステップS704)
ステップS704では、制御部305は、送信部402として動作し、送信部402は、完了時刻算出部406から送信完了時刻を受け取り、この送信完了時刻を含んだ送信完了時刻データを、高解像映像データの宛先端末104に送信する。この宛先端末104はこの送信完了時刻データを受け取り、画面に送信完了時刻情報を表示させる。送信完了時刻は例えば、ポップアップ等で表示され、この時刻が表示される表示枠は画面内で容易に移動できるような仕様であることが望ましい。

0090

図8は、2つの映像ソース101と、2つのWebRTCサーバ103と、2つの宛先端末104との間の一連の動作の一例を示すシーケンス図である。この例は、WebRTCサーバ1 103単独では高解像映像データを通信するための通信帯域を確保することができない場合である。

0091

(ステップS801)
ステップS801では、WebRTCサーバ1 103が、高解像映像データの属性情報と、自サーバの通信帯域使用状況とに基づいて、要求されている高解像映像データの通信帯域を確保することができるかどうかを判定し、確保することが可能であると判定した場合にはステップS508へ進み、自サーバでは通信帯域の確保が不可能であると判定した場合にはステップS802へ進む。

0092

(ステップS802、S803、S804)
ステップS802では、WebRTCサーバ1 103が、自サーバでは通信帯域を確保することができないと判定した場合には、通信帯域を融通してもらえないかを他のWebRTCサーバ103へ依頼する。

0093

そして、ステップS803では、WebRTCサーバ1 103が依頼データを生成し、他のWebRTCサーバ103宛てへ送信部402を介して依頼データを送信または配信する。この送信または配信は、例えば、マルチキャストまたはブロードキャストで依頼データが送られる。依頼データは、例えば、高解像映像データに必要な通信帯域とその通信帯域を使用したい時間帯(開始及び終了時刻)との情報を含む。

0094

ステップS804では、依頼データに含まれる情報に対応する通信帯域を融通することが可能であると判定したWebRTCサーバ103から、融通可能である旨の回答信号がWebRTCサーバ1 103へ送信される。

0095

(ステップS805、S806)
ステップS805では、WebRTCサーバ1 103がステップS803で依頼した依頼データの内容に基づいて、通信帯域を制御してWebRTCサーバ2 103に融通してもらった通信帯域を確保する。

0096

このステップS805と同時にステップS806では、WebRTCサーバ2 103がステップS803で依頼した依頼データの内容に基づいて、通信帯域を制御してWebRTCサーバ1 103に通信帯域を融通する。この結果、映像ソース1 101と宛先端末1 104との間のWebRTCサーバ1 103を経由する通信帯域は拡大され、映像ソース2 101と宛先端末2 104との間のWebRTCサーバ2 103を経由する通信帯域はこの拡大された分だけ縮小されることになる。

0097

(ステップS807)
ステップS807では、WebRTCサーバ1 103は通信帯域を確保しているので、高解像映像データの送信を開始するように映像ソース1 101へ指示することを決定する。そして、次のステップS510では、高解像映像データの送信を開始するように映像ソース1 101へ指示する指示信号をWebRTCサーバ1 103が映像ソース1 101へ送信する。

0098

上述した手順は、例えば、以下の様に一般化されてもよい。WebRTCサーバ1 103では、判定部407が、第1映像データの送信用に第1通信帯域に通信帯域を拡大する場合に、第1映像通信サーバで前記第1通信帯域を確保することができるかどうかを判定する。判定部407が前記第1通信帯域を確保することができないと判定した場合には、第2映像通信サーバが前記第1通信帯域を融通することが可能であるかどうかの回答を、送信部402がWebRTCサーバ2 103へ依頼する依頼データを送信する。そして、WebRTCサーバ2 103では、依頼データを受信し、判定部407が、第1通信帯域を融通することが可能であるかどうかを判定する。判定部407が第1通信帯域を融通することが可能であると判定した場合に、第1通信帯域を融通することが可能である回答信号をWebRTCサーバ1 103へ送信し、帯域制御部408が第1通信帯域を開放する。その後、WebRTCサーバ1 103では、回答信号を受信し、帯域制御部408が第1通信帯域を確保する。

0099

また、図8の一例とは別に、WebRTCサーバ103ごとに優先度が割り当てられて、第1宛先端末への映像データの通信帯域を拡大する場合に、この通信帯域を提供しているWebRTCサーバ1 103の優先度より低い優先度のWebRTCサーバ2 103が使用している通信帯域を縮小するように指示し、縮小した分の通信帯域をWebRTCサーバ1 103を経由する第1宛先端末に割り当ててもよい。さらに、優先度の低いWebRTCサーバ2 103へは、通信帯域を縮小するように指示信号をWebRTCサーバ1 103が送信し、WebRTCサーバ2 103が通信帯域を縮小可能であるとの回答信号をWebRTCサーバ1 103が受信した場合に、縮小した分の通信帯域をWebRTCサーバ1 103を経由する第1宛先端末に割り当てるという処理でもよい。

0100

例えば、WebRTCサーバ1 103では、判定部407が、第1映像データの送信用に第1通信帯域に通信帯域を拡大する場合に、第1映像通信サーバで第1通信帯域を確保することができるかどうかを判定する。送信部402が、この判定部407が第1通信帯域を確保することができないと判定した場合には、第1通信帯域を融通することとWebRTCサーバ1 103の優先度とを含む依頼データを、WebRTCサーバ2 103へ送信する。そして、WebRTCサーバ2 103では、判定部407が、通信インタフェース301を経由して依頼データを受信し、WebRTCサーバ1 103の優先度がWebRTCサーバ2 103の優先度より高いかどうかを判定する。帯域制御部408が、WebRTCサーバ1 103の優先度がWebRTCサーバ2 103の優先度より高いと判定した場合に、第1通信帯域を融通することが可能である回答信号をWebRTCサーバ1 103へ送信し、第1通信帯域を開放する。その後、WebRTCサーバ1 103では、帯域制御部408が、通信インタフェース301を経由して回答信号を受信し、第1通信帯域を確保することができる。

0101

図9は、WebRTCサーバ1 103が、WebRTCサーバ1 103単独では高解像映像データを通信するための通信帯域を確保することができず、他のWebRTCサーバ103へ通信帯域の融通を依頼する場合のフローチャートである。

0102

(起動)起動は図6の場合と同様である。

0103

(ステップS901)
ステップS901では、制御部305は、判定部407として動作し、WebRTCサーバ1 103が、自サーバでは通信帯域を確保することができないと判定した場合には、通信帯域を融通してもらえないかを他のWebRTCサーバ103へ依頼する。そして、ステップS901では、WebRTCサーバ1 103が依頼データを生成し、他のWebRTCサーバ103宛てへ送信部402を介して依頼データを送信または配信する。

0104

(ステップS902)
ステップS902では、制御部305は、判定部407として動作し、判定部407はステップS901で送信または配信した依頼データの回答信号を受信したかどうかを判定する。回答信号を受信した場合にはこの信号の送信元のWebRTCサーバ103が通信帯域を融通可能であると判定してステップS903へ進み、回答信号を受信しなかった場合には通信帯域を融通可能なWebRTCサーバ103がなかったと判定してステップS607へ進む。

0105

(ステップS903)
ステップS903では、制御部305は、判定部407、帯域制御部408として動作し、回答信号に基づいて、帯域制御部408は高解像映像データのために通信帯域を確保する。この結果、通信帯域を提供したWebRTCサーバ103は、この通信帯域を提供する間(高解像映像データの送信期間)では扱う通信帯域が縮小されることになる。
ステップS903が終了したら、ステップS606へ進む。

0106

以上のように本実施形態によれば、ネットワークを経由して複数の映像ソースと宛先端末との間を常時接続する映像通信サーバ(WebRTCサーバ103)は、宛先端末に付与される通信帯域の優先度に従って、優先度が高い宛先端末への高解像映像データの通信が必要になった場合には、優先度の低い宛先端末が使用している通信帯域を縮小することによって、優先度が高い宛先端末が使用する通信帯域を拡大することが可能になる。また、高解像映像データの属性情報を取得することによって、高解像映像データの通信が必要とする通信帯域及び期間を算出することができるので、宛先端末での管理者はいつになれば高解像映像データがダウンロード完了になるか(ストリームで映像が再生されている場合には、高解像映像データの再生が終了するか)を事前に知ることが可能になる。

0107

本実施形態のサーバは、コンピュータとプログラムによっても実現でき、プログラムを記録媒体(または記憶媒体)に記録することも、ネットワークを通して提供することも可能である。
また、以上の各装置及びそれらの装置部分は、それぞれハードウェア構成、またはハードウェア資源とソフトウェアとの組み合せ構成のいずれでも実施可能となっている。組み合せ構成のソフトウェアとしては、予めネットワークまたはコンピュータ読み取り可能な記録媒体(または記憶媒体)からコンピュータにインストールされ、当該コンピュータのプロセッサに実行されることにより、各装置の動作(または機能)を当該コンピュータに実現させるためのプログラムが用いられる。

0108

また、「及び/または」とは、「及び/または」でつながれて列記される事項のうちの任意の1つ以上の事項という意味である。具体例を挙げると、「x及び/またはy」とは、3要素からなる集合{(x),(y),(x,y)}のうちのいずれかの要素という意味である。もう1つの具体例を挙げると、「x,y,及び/またはz」とは、7要素からなる集合{(x),(y),(z),(x,y),(x,z),(y,z),(x,y,z)}のうちのいずれかの要素という意味である。

0109

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

0110

101…映像ソース、102…ネットワーク、103…WebRTCサーバ、104…宛先端末、201…中継装置、202…ビデオカメラ、203…ビデオレコーダ、204…アラーム装置、205…ボタン、206…ペダル、212…入力装置、251…クライアント端末、252…モバイル端末、301…通信インタフェース、302…記憶部、303…入力装置、304…出力装置、305…制御部、306…計時装置、307…電源部、308…外部インタフェース、401…映像取得部、402…送信部、403…映像監視部、404…属性取得部、405…帯域算出部、406…完了時刻算出部、407…判定部、408…帯域制御部。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ