(57)【特許請求の範囲】
【請求項１】
メディアデータの送信元であるデバイスと、
前記メディアデータの送信先であるサーバと、
前記デバイスと前記サーバとの間に介在する転送ノードと、
を有するシステムであって、
前記メディアデータは、前記メディアデータの非暗号化領域にレイヤ情報を配置するよう構成されたメディアデータフォーマットを有し、
前記転送ノードは、前記メディアデータに対して取得された操作内容に対応した前記サーバからの一部又は全てのレイヤの削除を指示する制御命令に従って、前記メディアデータのレイヤを削除し、前記指示されたレイヤが削除されたメディアデータを前記サーバに転送するシステム。
【請求項２】
前記転送ノードは、前記メディアデータの暗号化領域を復号化することなく、前記非暗号化領域に配置されたレイヤ情報を確認し、前記レイヤ情報を利用して前記メディアデータを前記サーバに転送する、請求項１記載のシステム。
【請求項３】
前記レイヤ情報は、前記メディアデータフォーマットのペイロード領域の直前に配置される、請求項１又は２記載のシステム。
【請求項４】
前記レイヤ情報は、前記メディアデータフォーマットのヘッダ拡張領域に配置される、請求項１又は２記載のシステム。
【請求項５】
前記デバイスと前記転送ノードとの間に介在する変換ノードを更に有し、
前記変換ノードは、前記メディアデータフォーマットに対応しない非対応メディアデータフォーマットによるメディアデータを受信し、前記受信したメディアデータを前記非対応メディアデータフォーマットから前記メディアデータフォーマットに変換し、前記変換したメディアデータを前記転送ノードに転送する、請求項１乃至４何れか一項記載のシステム。
【請求項６】
デバイスからサーバにメディアデータを送信する方法であって、
前記デバイスが、転送ノードにメディアデータを送信するステップと、
前記転送ノードが、レイヤ情報を利用して前記メディアデータを前記サーバに転送するステップと、
を有し、
前記メディアデータは、前記メディアデータの非暗号化領域に前記レイヤ情報を配置するよう構成されたメディアデータフォーマットを有し、
前記転送ノードは、前記メディアデータに対して取得された操作内容に対応した前記サーバからの一部又は全てのレイヤの削除を指示する制御命令に従って、前記メディアデータのレイヤを削除し、前記指示されたレイヤが削除されたメディアデータを前記サーバに転送する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大量のデバイスから映像・音声等のメディアトラヒックがクラウド上などの装置に送信される通信において、セキュリティを保ったまま効率的な転送を実現する技術に関する。
【背景技術】
【０００２】
これまで、メディアトラヒックの効率的な転送方法に関して多数の技術開発が行われてきている。一例としてメディアカンファレンシングシステムが挙げられる。複数の参加者がいるメディアカンファレンスを実現するためには、各参加者の間でフルメッシュ接続を行う必要があるが、参加者数の増加に従って帯域や端末の処理能力などに限界が生じうる。このため、典型的には、より効率的な配送を目指してMultipoint Control Unit（MCU）などのメディア配送装置が利用される。
【０００３】
こうしたメディア配送装置を利用する際、セキュリティ側面では当該配送装置が信頼できるか否かが重要な指針となる。従来、IPベースのシステムで一般に利用されるReal-time Transport Protocol（RTP）において、セキュリティ機能を提供するSecure RTP（SRTP）プロファイルを利用しつつ、かつ同時にMCUを使う場合において、End-to-Endで完全性を保証する方法はなかった。このため、MCU等のメディア配送装置にはSRTPの鍵が譲渡されることが典型的な利用例となり、この場合、MCU等が信頼できるものであることが前提となっている。
【０００４】
このようなMCUの信頼性に関して、現在、標準化団体であるInternet Engineering Task Force（IETF）ではPrivacy Enhanced RTP Conferencing（PERC）と呼ばれるフレームワークが議論されており、MCU等が信頼できない第三者から提供されている場合であっても、セキュリティ機能を利用可能にするための拡張が進められている。PERCでは、MCU等がRTPヘッダを書き換えてもE2Eの完全性が担保されるように、End-to-Endの認証領域とHop-By-Hopの認証領域とを分けることが提案されている。これにより、MCU等が信頼できない第三者から提供されている場合でも、MCUをセキュアに利用することができるようになる。
【０００５】
一方、効率的なメディア配信を行うための技術としてスケーラブル符号化と呼ばれる技術がある。スケーラブル符号化の最大の特徴は、単一の映像/音声ストリームが複数のレイヤに分割されている点である。レイヤは下層であるベースラインレイヤだけを復号すると低解像度の映像が生成され、上層のエンハンスレイヤまで復号することで高解像度の映像を生成可能となるように設計されており、ネットワークの帯域に応じて必要なレイヤまでを送信することで伝送/蓄積コストおよび管理コストの削減が可能となっている。代表的な例として、H.264/SVC（Scalable Video Coding）がある。H.264/SVCでは、メディア分配装置と組み合わせることによって、配信元の処理内容に変更を与えることなく配信先の状況によって配信内容を変更するといった柔軟な利用が可能となる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】"RTP: A Transport Protocol for Real-Time Applications"RFC 3550
【非特許文献２】"The Secure Real-time Transport Protocol (SRTP)" RFC 3711
【非特許文献３】"A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing" draft-jones-perc-private-media-framework-01
【非特許文献４】H.264 : Advanced video coding for generic audiovisual services
【非特許文献５】"AVC/H.264スケーラブル拡張方式SVC(Scalable Video Coding)概説"、電子情報通信学会技術研究報告 ITS Vol.109 No.414 pp141-145
【発明の概要】
【発明が解決しようとする課題】
【０００７】
これまでのメディアトラヒックは、人間が利用する端末間で利用されることが多かった。しかしながら、今後はドローンなどのマルチコプタ、受付ロボット、監視ロボット、掃除ロボットなど、多くのロボットやInternet of Things（IoT）デバイスにカメラやマイクが搭載され、大量のメディアストリームが生成されることが予見される。これらロボット/デバイスが爆発的な普及をみせると、これまでの人間の利用を想定したマルチメディアトラヒックとは比較にならない大量のトラヒックが発生する可能性がある。
【０００８】
さらに、上記のトラヒックがインターネットなどのネットワークを介してクラウド上などのサーバに転送・保存されると、ネットワークの帯域、サーバの処理能力、ストレージ容量など、多くのボトルネックポイントが生じることが予見される。そのため、多数のロボット等を想定した効率的なメディア転送方法が必要となる。
【０００９】
一方、セキュリティの観点ではこれらロボットやデバイスはその特性に応じて上空や建物内、宅内の映像や音声を取り扱うこととなるため、企業や国、個人の機密情報（制限区域の情報、宅内の個人情報、建物の内部情報など）を多く含む映像・音声を取り扱う可能性があり、高いセキュリティ要件が必要となる。しかしながら、従来のメディアカンファレンスで行われているように、MCU等の装置に暗号鍵を渡してデータを復号可能な状態にすることは受け入れられないケースが多く存在すると考えられる。
【００１０】
上記の説明では、メディアの転送効率の向上のための具体例としてSVCとメディア分配装置の組み合わせと共に、セキュリティ向上のための具体例としてIETFにおけるPERCの取り組みとを取り上げた。これら二つの技術を組み合わせれば、上記のロボットやIoTデバイスにおけるセキュリティと転送効率との両立という課題を解決できるように考えられる。一方、現状では、これら二つの取り組みはそのままでは組み合わせることができない。すなわち、SVCのレイヤ情報はRTPのペイロード部に挿入されるが、SRTPではペイロード部が暗号化される。このため、復号化の鍵を持っていないメディア分配装置はレイヤを確認することができない。
【００１１】
また、従来のメディアカンファレンスでは任意の数のメディア分配装置に加え、メディア変換を行うトランスコーダなどの装置があらゆるトポロジーで接続可能であり、さらに双方向にメディアを送受信することを仮定している。そのため柔軟性に富む一方で、転送・通信の効率を向上させるうえでは冗長性があると考えられ、やはりそのままでは効率的な転送ができない。
【００１２】
上述した問題点を鑑み、本発明の課題は、セキュリティをEnd-to-Endで保ちつつ、効率的なメディア転送を実現するための技術を提供することである。
【課題を解決するための手段】
【００１３】
上記課題を解決するため、本発明の一態様は、メディアデータの送信元であるデバイスと、前記メディアデータの送信先であるサーバと、前記デバイスと前記サーバとの間に介在する転送ノードとを有するシステムであって、前記メディアデータは、前記メディアデータの非暗号化領域にレイヤ情報を配置するよう構成されたメディアデータフォーマットを有するシステムに関する。
【００１４】
本発明の他の態様は、デバイスからサーバにメディアデータを送信する方法であって、前記デバイスが、転送ノードにメディアデータを送信するステップと、前記転送ノードが、レイヤ情報を利用して前記メディアデータを前記サーバに転送するステップとを有し、前記メディアデータは、前記メディアデータの非暗号化領域に前記レイヤ情報を配置するよう構成されたメディアデータフォーマットを有する方法に関する。
【発明の効果】
【００１５】
本発明によると、セキュリティをEnd-to-Endで保ちつつ、効率的なメディア転送を実現することができる。
【図面の簡単な説明】
【００１６】
【図１】図１は、本発明の一実施例によるシステム構成を示す図である。
【図２】図２は、本発明の一実施例によるデバイスの構成を示すブロック図である。
【図３】図３は、本発明の一実施例によるサーバの構成を示すブロック図である。
【図４】図４は、本発明の一実施例による転送ノードの構成を示すブロック図である。
【図５】図５は、本発明の一実施例による変換ノードの構成を示すブロック図である。
【図６】図６は、本発明の一実施例によるメディアデータフォーマットを示す図である。
【図７】図７は、本発明の他の実施例によるメディアデータフォーマットを示す図である。
【図８】図８は、本発明の一実施例による登録・通信開始処理を示すフロー図である。
【図９】図９は、本発明の一実施例によるメディア転送変更処理を示すフロー図である。
【図１０】図１０は、本発明の一実施例による非対応デバイスのための登録・通信開始処理を示すフロー図である。
【発明を実施するための形態】
【００１７】
以下、図面に基づいて本発明の実施の形態を説明する。
【００１８】
後述される実施例では、セキュリティをEnd-to-Endで保ちつつ、効率的なメディア転送を実現するためのシステムが開示される。
【００１９】
まず、図１を参照して、本発明の一実施例によるシステムを説明する。図１は、本発明の一実施例によるシステム構成を示す図である。
【００２０】
図１に示されるように、システム１０は、デバイス１００、サーバ２００、転送ノード３００、変換ノード４００及び通信ネットワーク５００を有する。デバイス１００、サーバ２００、転送ノード３００及び変換ノード４００は、通信ネットワーク５００を介し通信接続される。
【００２１】
デバイス１００は、典型的には、システム１０と接続性のある各種ロボットやその他のデバイスとして実現され、映像や音声等のメディアデータを伝送可能な装置である。例えば、デバイス１００は、具備されたカメラやマイクを利用してメディアストリームを生成し、通信ネットワーク５００を介して転送ノード３００又は転送ノード３００と変換ノード４００との両方を経由してサーバ２００に送信する。送信先サーバ２００は一つであってもよいし複数であってもよい。例えば、デバイス１００は、以下に限定されることなく、カメラ、マイク、センサなどのセンシング機器、センシング機器により取得されたメディアデータを処理し、デバイス１００を制御するためのプロセッサ、メディアデータ及びプロセッサにより実行されるプログラムを記憶するためのメモリなどの記憶装置、通信ネットワーク５００を介してメディアデータを通信するための通信回路などを有するハードウェア構成によって実現される。
【００２２】
サーバ２００は、システム１０と接続性のあるデバイス１００によって生成されたメディアストリームを転送ノード３００経由で受信し、受信したメディアストリームに対して目的に応じた処理や蓄積を行う。さらに、サーバ２００は、変換ノード４００および転送ノード３００へ解像度やデバイス１００の指定などの処理指示を行う。一つのサーバ２００が複数の転送ノード３００からメディアストリームを受信してもよいし、一つの転送ノード３００からの情報を複数のサーバ２００が受信してもよい。例えば、サーバ２００は、以下に限定されることなく、通信ネットワーク５００を介してデータを通信するための通信回路、データを処理するためのプロセッサ、データを記憶するためのメモリやストレージなどの記憶装置などを有するハードウェア構成によって実現される。
【００２３】
転送ノード３００は、ルータ、スイッチなどにより実現され、デバイス１００とサーバ２００との間の通信を中継するための装置である。転送ノード３００は、デバイス１００から通信ネットワーク５００を介して受信したメディアストリームをサーバ２００に転送する。転送ノード３００は、秘匿化されているストリーム情報ではなく、確認可能なヘッダ情報とサーバ２００から送信される処理指示及び自律的な判断とに基づいてメディアストリームを転送する。
【００２４】
変換ノード４００は、システム１０と接続性のないデバイス１００やサーバ２００がシステム１０において利用可能になるための変換処理を実行する。変換ノード４００は、デバイス１００−転送ノード３００間、もしくはサーバ２００−転送ノード３００間で利用され、システム１０と接続性のないデバイス１００の収容を実現する。
【００２５】
次に、図２を参照して、本発明の一実施例によるデバイス１００の構成を説明する。図２は、本発明の一実施例によるデバイス１００の構成を示すブロック図である。
【００２６】
図２に示されるように、デバイス１００は、センシング部１１０、メディア生成部１２０、セキュリティ処理部１３０、記憶部１４０及び通信部１５０を有する。
【００２７】
センシング部１１０は、カメラやマイク等のセンシング機器を介し映像や音声等のデバイス１００の外部環境に関する外部環境情報（メディアストリーム）を取得する。
【００２８】
メディア生成部１２０は、センシング部１１０から受信した外部環境情報を後述するメディアデータフォーマットに変換する。
【００２９】
セキュリティ処理部１３０は、メディア生成部１２０から受信したメディアデータに対して、後述するように、セキュリティ処理によって暗号化すると共に、認証タグを生成する。
【００３０】
記憶部１４０は、生成したメディアデータを記憶装置に記憶する。
【００３１】
通信部１５０は、TCP/IPや通信ネットワーク５００に適合する通信方式に従って、セキュリティ処理部１３０から受信したセキュリティ処理（暗号化など）済みのメディアデータを転送ノード３００に送信する。また、通信部１５０は、当該送信を実現するのに必要な制御情報を送受信する。
【００３２】
次に、図３を参照して、本発明の一実施例によるサーバ２００の構成を説明する。図３は、本発明の一実施例によるサーバ２００の構成を示すブロック図である。
【００３３】
図３に示されるように、サーバ２００は、通信部２１０、セキュリティ処理部２２０、メディア処理部２３０、記憶部２４０、メディア解析部２５０、処理入力部２６０及び処理判断部２７０を有する。
【００３４】
通信部２１０は、通信ネットワーク５００を介して転送ノード３００からメディアデータを受信し、受信したメディアデータをセキュリティ処理部２２０に転送すると共に、処理判断部２７０から受信した制御命令を転送ノード３００に転送する。
【００３５】
セキュリティ処理部２２０は、通信部２１０から受信したメディアデータを後述するセキュリティ処理を利用して復号化すると共に、認証タグに基づく認証処理を実行する。
【００３６】
メディア処理部２３０は、セキュリティ処理部２２０から受信したメディアデータを後述するメディアデータフォーマットから映像・音声等の外部環境情報（メディアストリーム）に変換する。
【００３７】
記憶部２４０は、生成した映像・音声等の外部環境情報を記憶する。
【００３８】
メディア解析部２５０は、メディア処理部２３０から受信したメディアストリームを解析し、緊急状況や不具合、故障等のアラートを検出し、解析結果を処理判断部２７０に送信する。
【００３９】
処理入力部２６０は、メディア処理部２３０から受信したメディアストリームに対して、サーバ２００の提供者、サーバ２００上のアプリケーションを利用している利用者又はそのオペレータにより入力された操作内容を取得する。当該操作内容として、以下に限定することなく、特定のデバイス１００の映像を高/低画質に切り替える、転送を止める/開始する、などが考えられる。
【００４０】
処理判断部２７０は、メディア解析部２５０及び処理入力部２６０から取得した結果に基づき実行すべき処理を判断し、当該処理を指示するための制御命令を通信部２１０に送信する。この判断基準としては、以下に限定することなく、メディア解析部２５０もしくは処理入力部２６０のどちらかを優先させる、到着時間が早いものを優先する、制御内容（ストリームの転送依頼、停止依頼、解像度変更依頼など）によって優先度をつける、などの方法が考えられる。
【００４１】
次に、図４を参照して、本発明の一実施例による転送ノード３００の構成を説明する。図４は、本発明の一実施例による転送ノード３００の構成を示すブロック図である。
【００４２】
図４に示されるように、転送ノード３００は、通信部３１０、処理判断部３２０、セキュリティ処理部３３０、通信管理部３４０及び通信管理データベース（DB）３５０を有する。
【００４３】
通信部３１０は、通信ネットワーク５００を介してデバイス１００、サーバ２００及び変換ノード４００から受信したメディアデータを通信管理部３４０に転送すると共に、サーバ２００から受信した制御命令を処理判断部３２０に転送する。
【００４４】
処理判断部３２０は、サーバ２００から受信した制御命令に従ってメディアデータの転送判断を行い、判断結果を通信管理部３４０に転送する。受付可能な制御命令としては、以下に限定することなく、解像度の変更（特定のレイヤの削除）、メディアデータの停止（全レイヤの削除）、記憶の開始および終了などが考えられる。
【００４５】
セキュリティ処理部３３０は、通信管理部３４０から受信したメディアデータの認証タグを再計算し、再計算した認証タグを付与する。
【００４６】
通信管理部３４０は、転送ノード３００を利用しているサーバ２００及びデバイス１００を管理し、通信部３１０から転送されたメディアデータの宛先情報等を正しいものに変更し、セキュリティ処理部３３０に転送する。
【００４７】
通信管理DB３５０は、転送ノード３００を利用しているサーバ２００及びデバイス１００の情報を管理し、通信管理部３４０からの照会に応答する。
【００４８】
次に、図５を参照して、本発明の一実施例による変換ノード４００の構成を説明する。図５は、本発明の一実施例による変換ノード４００の構成を示すブロック図である。
【００４９】
図５に示されるように、変換ノード４００は、通信部４１０、メディア変換部４２０、セキュリティ処理部４３０及び記憶部４４０を有する。
【００５０】
通信部４１０は、システム１０と接続性のないデバイス１００やサーバ２００（以降非対応ノードとして参照する）から受信したメディアデータをメディア変換部４２０に転送すると共に、メディア変換部４２０から受信したメディアデータを転送ノード３００に送信する。
【００５１】
メディア変換部４２０は、通信部４１０から受信した非対応ノードのデータを後述されるメディアデータフォーマットに変換する。
【００５２】
セキュリティ処理部４３０は、メディア変換部４２０から受信したメディアデータに対して、後述するように、セキュリティ処理によって暗号化すると共に、認証タグを生成する。
【００５３】
記憶部４４０は、生成したメディアデータを記憶装置に記憶する。
【００５４】
なお、変換ノード４００を利用する場合、E2Eのセキュリティ（完全性）は担保されないが、変換ノード４００−サーバ２００間でのセキュリティは担保される。
【００５５】
次に、図６〜７を参照して、本発明の一実施例によるメディアデータフォーマットを説明する。図６は、本発明の一実施例によるメディアデータフォーマットを示す図である。
【００５６】
図６に示されるメディアデータフォーマットは、RTPをベースとして、SRTPとSVCとを併用することによってセキュリティと転送効率とを両立することを可能にするデータフォーマットである。既存のRTPベースのカンファレンシングシステムでは、複数のMCUやトランスコーダ等を通過してメディアストリームが混合されたとしても、どの参加者がどのメディアストリームに関わっているかを示すことができるように、Synchronization Source(SSRC)以外にも複数のContributing Source（CSRC）が記載できるようになっている。以下の実施例では、メディアデータは基本的にデバイス１００からサーバ２００に向けて一方向で送信され、さらに中間に介在する転送ノード３００は高々一つと仮定する。そのため、複数のCSRC情報は必要なく、高々一つが設定できるフィールドがあればよい。
【００５７】
また、RTPではPayload中にペイロードごとに規定されたヘッダを挿入することとなっている。このため、SVCとSRTPとを利用する場合、ヘッダに配置されるレイヤ情報は確認できないようになっていた。しかしながら、図６に示される実施例では、レイヤ情報（Layer Type, Layer code）を（暗号化対象とはならない）ペイロードの直前に挿入している。これにより、転送ノード３００は、ペイロード部の中身を見ることなく、すなわち、暗号化の鍵をデバイス１００やサーバ２００から取得して管理することなく、帯域やサーバ２００からの依頼に応じて、レイヤの変更などの転送の切り替えを実現することができるようになる。
【００５８】
また、従来はマーカビット（M）に１ビットのみが割り当てられていた。しかしながら、図示された実施例では、マーカビットに６ビットが割り当てられており、本発明におけるユースケースでは、デバイス１００のタイプによって多様な種類・レベルのマーキングが可能になる。このようにして、緊急性の高低や規模の大小によってデバイス１００−サーバ２００間であらかじめ決められた値をやり取りすることで、どのデータにどの情報が含まれているかをトレースすることが容易となる。
【００５９】
本実施例によるメディアデータフォーマットでは、従来のRTPで利用されていたプロファイルおよびペイロードフォーマットは、上記で削除した点に該当する部分を除きそのまま流用することで映像・音声の通信を実現することができる。完全性はIETFのPERCフレームワークを流用することで解決を図る。例えば、Short EKT（Encrypted Key Transport）等の適用によって完全性の確保が可能となるが、本発明はこれに限定されない。
【００６０】
図７は、本発明の他の実施例によるメディアデータフォーマットを示す図である。図７に示されるメディアデータフォーマットは、既存のSRTPプロファイルを利用したデータフォーマットである。図６ではトポロジーを考慮して不要なヘッダ領域を削除しつつSVCに必要なヘッダを挿入したが、図７ではRTPが有するヘッダ拡張領域を利用することで解決を図る。Xビットはヘッダ拡張の有無を示しており、Xに１をセットするとCSRC ID群の後に続くヘッダ拡張領域（header extension）を利用することができる。このヘッダ拡張領域（header extension）に、図６と同様のレイヤ情報（Layer Type, Layer code）を挿入する。これによって、SRTPを利用した場合でも、転送ノード３００は、ペイロード部の中身を見ることなく、すなわち、暗号化の鍵をデバイス１００やサーバ２００から取得して管理することなく、帯域やサーバ２００からの依頼に応じて、レイヤの変更などの転送の切り替えを実現することができるようになる。
【００６１】
図６の例ではトポロジーを考慮した最適化を実施しているため転送効率が高いことが期待できる一方で、既存端末との互換性は低くなる。図７の例では既存端末との互換性は高くなる一方で、転送効率は今まで通りとなることが予想される。
【００６２】
ここで、制御信号は既存のプロトコル（HTTP、SIP、RTSPなどのリクエストレスポンス型プロトコルでもよいし、MQTTなどのPublish/Subscribe型のプロトコルでもよい）を利用してもよいし、独自に規定されたプロトコルを利用することもできる。また、データフォーマットとしてはSDPなどの既存フォーマットを利用してもよいし、JSONなどの形式でデバイス１００−転送ノード３００−サーバ２００の間で取り決められたフォーマットを利用してもよい。
【００６３】
次に、図８を参照して、本発明の一実施例によるデバイス１００のための登録・通信開始処理を説明する。図８は、本発明の一実施例による登録・通信開始処理を示すフロー図である。
【００６４】
図８に示されるように、ステップＳ１０１において、デバイス１００は、所望の通信開始タイミングで通信開始リクエストをサーバ２００に送信する。宛先サーバ２００のFQDN/URI/IPアドレス等の指定方法は問わないが、デバイス１００のハードウェア/ソフトウェアにあらかじめ設定されているか、動的に取得できるものとする。
【００６５】
ステップＳ１０２において、サーバ２００は、転送ノード３００を利用することを所望する場合、転送ノード３００の情報をデバイス１００に通知し、リダイレクトを実施する。
【００６６】
ステップＳ１０３において、デバイス１００は、通知された転送ノード３００の情報に基づき、通信開始リクエストを当該転送ノード３００に送信する。
【００６７】
ステップＳ１０４において、転送ノード３００は、通信開始リクエストをサーバ２００に送信する。
【００６８】
ステップＳ１０５において、サーバ２００は、転送ノード３００からの情報に基づき送信可否を判断し、判定結果を転送ノード３００に通知する。本実施例では、判定結果は送信可能であり、サーバ２００は、許可を転送ノード３００に通知する。なお、判定結果が送信不可である場合、サーバ２００は、拒絶を転送ノード３００に通知し、当該処理を終了する。
【００６９】
ステップＳ１０６において、転送ノード３００は、サーバ２００から受信した判定結果に基づき送信可否を判断し、判定結果をデバイス１００に通知する。本実施例では、判定結果は送信可能であり、転送ノード３００は、許可をデバイス１００に通知する。
【００７０】
ステップＳ１０７において、デバイス１００は、上述したメディアデータフォーマットによるメディアデータを転送ノード３００に送信し、転送ノード３００は、レイヤ情報に従ってメディアデータをサーバ２００に転送する。上述したように、デバイス１００から受信したメディアデータでは、セキュリティのためペイロードは暗号化されているが、転送効率を向上させるためのレイヤ情報は非暗号化領域に配置される。従って、転送ノード３００は、暗号化を復号するための鍵を保持することなく、レイヤ情報を確認することが可能であり、当該レイヤ情報に示されたレイヤに対応した解像度によってメディアデータをサーバ２００に転送することが可能になる。
【００７１】
次に、図９を参照して、本発明の一実施例によるメディア転送変更処理を説明する。図９は、本発明の一実施例によるメディア転送変更処理を示すフロー図である。
【００７２】
図９に示されるように、ステップＳ２０１において、上述した登録・通信開始処理によって送信が許可された後、メディアデータが、デバイス１００から転送ノード３００を介しサーバ２００に送信されている。
【００７３】
ステップＳ２０２において、サーバ２００は、オペレータの入力、画像の解析結果等に基づいて転送ポリシーを決定し、転送変更リクエストを転送ノード３００に送信する。転送ポリシーは、例えば、デバイス１００の映像を高/低画質に切り替える、転送を止めるなどであってもよい。
【００７４】
ステップＳ２０３において、転送ノード３００は、受信した転送変更リクエストを解析し、該当する操作が有効であるか検証した上で当該変更要求が許可可能であるか判断する。許可可能である場合、転送ノード３００は、変更許可をサーバ２００に通知する。
【００７５】
ステップＳ２０４において、転送ノード３００は、転送変更リクエストに従って解像度の変更（特定のレイヤの削除/追加）やメディアデータの削除（全レイヤの削除）を実行する。その後、転送ノード３００は、変更後のレイヤに対応した解像度によって、デバイス１００から受信したメディアデータをサーバ２００に転送する。
【００７６】
次に、図１０を参照して、本発明の一実施例による非対応デバイス１００のための登録・通信開始処理を説明する。図８に示された実施例では、デバイス１００は、システム１０との接続性を有する対応デバイスであった。本実施例では、デバイス１００は、システム１０との接続性を有さない非対応デバイスであり、この場合、デバイス１００とサーバ２００との間の通信は、転送ノード３００と共に変換ノード４００を介して行われる。図１０は、本発明の一実施例による非対応デバイス１００のための登録・通信開始処理を示すフロー図である。
【００７７】
図１０に示されるように、ステップＳ３０１において、デバイス１００は、変換ノード４００に通信開始リクエストを送信する。非対応デバイス１００がシステム１０に接続する際、変換ノード４００は、静的にデバイス１００のハードウェア・ソフトウェアに設定されているか、若しくはDNSやUPnPなどを利用して動的に発見されるものとする。
【００７８】
ステップＳ３０２において、変換ノード４００は、受信した通信開始リクエストをシステム１０において利用可能なフォーマットに変換し、変換した通信開始リクエストを転送ノード３００に送信する。
【００７９】
ステップＳ３０３〜Ｓ３０５は、図８のステップＳ１０４〜Ｓ１０６と同様であり、これらの説明は省略する。
【００８０】
ステップＳ３０６において、変換ノード４００は、受信した許可を非対応デバイス１００が受信可能なフォーマットに変換し、変換した許可をデバイス１００に送信する。
【００８１】
ステップＳ３０７において、デバイス１００は、メディアデータを変換ノード４００に送信する。変換ノード４００は、受信したメディアデータを暗号化等することによって、上述したメディアデータフォーマットによるメディアデータに変換し、変換したメディアデータを転送ノード３００に送信する。転送ノード３００は、受信したメディアデータの非暗号化領域に配置されたレイヤ情報を確認し、当該レイヤ情報に示されたレイヤに対応した解像度によってメディアデータをサーバ２００に転送することが可能になる。
【００８２】
上述した実施例によると、ドローン等のロボットやその他IoTデバイスなどのデバイス１００が生成・送信する大量の映像・音声等の全てのメディアトラフィックをクラウド上のサーバ２００等に転送することなく、必要に応じて画質調整等を行えるようになることで効率的な転送が可能となる。さらに、転送ノード３００はデバイス１００やサーバ２００の提供者とは別の第三者であってもよく、End-to-Endのセキュリティを保ったまま効率的な転送を行うことができるようになる。
【００８３】
以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８４】
１０  システム
１００  デバイス
２００  サーバ
３００  転送ノード
４００  変換ノード
【図１】
0006543585.tif 000002
【図２】
0006543585.tif 000003
【図３】
0006543585.tif 000004
【図４】
0006543585.tif 000005
【図５】
0006543585.tif 000006
【図６】
0006543585.tif 000007
【図７】
0006543585.tif 000008
【図８】
0006543585.tif 000009
【図９】
0006543585.tif 000010
【図１０】
0006543585.tif 000011