(57)【要約】      （修正有）【課題】ピアツーピア通信を伴うアプリケーション、サービス、システム等の構築を容易にするための技術を提供する。【解決手段】ネットワーク事業者により運営されるSTUNサーバ、TURNサーバ及び認証サーバを介しWebRTC(Web  Real-Time Communication)を利用してピアツーピア通信を実行する通信装置であって、STUNサーバ及びTURNサーバにアクセス可能であると判断した前記認証サーバにより発行された認証キーを管理する認証機能と、前記WebRTCに実装されたNAT/FW(Network Address Translation/Firewall)を通過するためのICE(Interactive Connectivity Establishment)を実行することによって、前記ピアツーピア通信のためのIPアドレスを取得するICE機能とを有する。【選択図】図１
2015153076.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク事業者により運営されるSTUNサーバ、TURNサーバ及び認証サーバを介しWebRTC (Web Real-Time Communication)を利用してピアツーピア通信を実行する通信装置であって、
前記認証サーバと通信することによって当該通信装置が前記STUNサーバ及び前記TURNサーバにアクセス可能であるか判断し、当該通信装置がSTUNサーバ及びTURNサーバにアクセス可能であると判断した前記認証サーバにより発行された認証キーを管理する認証機能と、
前記WebRTCに実装されたNAT/FW (Network Address Translation/Firewall)を通過するためのICE (Interactive Connectivity Establishment)を実行することによって、前記認証キーを用いて前記STUNサーバ又は前記TURNサーバにアクセスし、前記ピアツーピア通信のためのIPアドレスを取得するICE機能と、
を有する通信装置。
【請求項２】
前記認証キーに基づき前記STUNサーバにアクセスすることが許可されると、前記ICE機能は、前記STUNサーバからグローバルIPアドレスを受信し、前記受信したグローバルIPアドレスを用いて通信相手先の通信装置とのピアツーピア通信を実行する、請求項１記載の通信装置。
【請求項３】
前記STUNサーバは、当該通信装置が前記STUNサーバにアクセスした回数をカウントするコール数カウント機能を有し、
当該通信装置は、前記コール数カウント機能によりカウントされた回数に応じて課金される、請求項２記載の通信装置。
【請求項４】
前記認証キーに基づき前記TURNサーバにアクセスすることが許可されると、前記ICE機能は、前記TURNサーバからリレー用IPアドレスを受信し、前記受信したリレー用IPアドレスを用いて前記TURNサーバを介した通信相手先の通信装置とのピアツーピア通信を実行する、請求項１記載の通信装置。
【請求項５】
前記TURNサーバは、当該通信装置が前記TURNサーバにアクセスした回数をカウントするコール数カウント機能を有し、
当該通信装置は、前記コール数カウント機能によりカウントされた回数に応じて課金される、請求項４記載の通信装置。
【請求項６】
前記TURNサーバは、当該通信装置に割り当てられた利用帯域を測定する利用帯域測定機能を有し、
当該通信装置は、前記利用帯域測定機能により測定された利用帯域に応じて課金される、請求項４記載の通信装置。
【請求項７】
ネットワーク事業者により運営されるSTUNサーバ、TURNサーバ及び認証サーバを有する通信システムにおけるピアツーピア通信を実現するための方法であって、
前記ピアツーピア通信の要求元のアプリケーションから受信した前記認証サーバにより発行された認証キーに基づき、前記要求元のアプリケーションに対して前記STUNサーバ又は前記TURNサーバへのアクセスを許可するステップと、
前記STUNサーバからグローバルIPアドレス又は前記TURNサーバからリレー用IPアドレスを前記要求元のアプリケーションに送信するステップと、
前記グローバルIPアドレスを用いて要求先のアプリケーションと前記ピアツーピア通信を実行するか、又は前記リレー用IPアドレスを用いて前記要求先のアプリケーションと前記TURNサーバを経由して前記ピアツーピア通信を実行するステップと、
を有する方法。
【請求項８】
ネットワーク事業者により運営されるSTUNサーバ、TURNサーバ及び認証サーバを介しWebRTC (Web Real-Time Communication)を利用してピアツーピア通信を実行する通信装置のためのプログラムであって、
前記通信装置のプロセッサに、
前記認証サーバと通信することによって当該通信装置が前記STUNサーバ及び前記TURNサーバにアクセス可能であると判断し、当該通信装置が前記STUNサーバ及び前記TURNサーバにアクセス可能であるか判断した前記認証サーバにより発行された認証キーを管理する認証機能と、
前記WebRTCに実装されたNAT/FW (Network Address Translation/Firewall)を通過するためのICE (Interactive Connectivity Establishment)を実行することによって、前記認証キーを用いて前記STUNサーバ又は前記TURNサーバにアクセスし、前記ピアツーピア通信のためのIPアドレスを取得するICE機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピアツーピア通信システムに関する。
【背景技術】
【０００２】
サーバを介して通信が行われる場合、過大なトラフィックが生じ、いたずらに通信遅延やサーバ負荷を増大させる可能性がある。このため、ピアツーピア通信(P2P)の実現のための技術開発が行われてきた。ピアツーピア通信を利用するシステムの中には、全くサーバを必要としない完全にサーバレスなピアツーピア通信システムも存在するが、多くのシステムは相手のピア発見等を手助けするサーバを介して通信を開始し、その後ピアツーピア通信に切り替えるものが多い。
【０００３】
サーバを用いてサポートを行う場合、今日の典型的な通信環境では、NAT/FW(Network Address Translation/Firewall)が配備されているため、このNAT/FWを通過するための技術が必要となる。このようなNAT/FWを通過するための技術として、ピアのグローバルIPアドレスとポート番号を知らせてホールパンチング技術によりNAT/FW通過を実現する Session Traversal Utilities for NAT (STUN) 技術、メディアやアプリの配信サーバを介さずにリレーサーバを配備する Traversal Using Relay NAT (TURN) 技術、STUNとTURNを組み合わせ、体系立ててNAT/FWを通過するための手順としてまとめたInteractive Connectivity Establishment (ICE) などが存在する。
【０００４】
ICE技術を利用した実装の例として、ブラウザ上でリアルタイム通信を実現するフレームワークであるWebRTC (Web Real-Time Communication)が存在する。WebRTCはビデオチャット等を簡単に実現する技術として注目されている。ピアツーピア通信の実現のためにICE技術を利用することが定められており、ブラウザやブラウザコンポーネントにICE機能が標準的に実装されるようになることが予想される。
【０００５】
これらピアツーピア通信技術は通信の効率化のみならず、モバイルアドホックネットワークの構築などへの応用が期待されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2004-266653
【非特許文献】
【０００７】
【非特許文献１】RFC 5389, Session Traversal Utilities for NAT (STUN)
【非特許文献２】RFC 5766, Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
【非特許文献３】RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
【発明の概要】
【発明が解決しようとする課題】
【０００８】
サーバによるサポートを行いつつ、ピアツーピア通信を実現するための既存技術であるICEを用いることでアプリケーション開発者はピアツーピア通信を伴うアプリケーションの開発が可能となった。しかしながら、このようなICEを利用したピアツーピア通信を利用したアプリケーションの開発では、いくつかの問題がある。
【０００９】
第１に、アプリケーション開発者は、自身のアプリにICE機能を実装する必要があるため、ICE機能に関する一定の知識が必要であった。例えば、ICE機能を実装するためには非特許文献３に記載されるような技術を理解し、その規定通りに機能実装を行う必要があり、アプリケーション開発者自身で通信状態の管理やプロシージャまで含めて規程を行う必要がある。そのため、アプリケーション開発者には、ICE機能を利用するための前提となる非常に高い知識水準が要求された。
【００１０】
第２に、アプリケーション開発者は、ICE機能を提供するサーバを設ける必要がある。ICE機能はサーバ側との相互作用を通じてNAT/FW通過を実現するため、ピアツーピア通信を利用するためには、アプリケーション開発者自身がICE機能を提供するためのSTUNサーバやTURNサーバを用意する必要がある。このため、ICE機能を利用したアプリケーション開発にとって、利用の敷居が高かった。さらに、STUNサーバは、一回のリクエストに対してレスポンスを返すだけの簡易なシステムであるため、市中実装で利用可能なものが存在する一方、TURNサーバは、ピア間のデータが常にTURNサーバを通過するため、STUNに比べサーバ負荷が高く、市中実装も多くは存在していない。
【００１１】
上述した問題点を鑑み、本発明の１つの課題は、ピアツーピア通信を伴うアプリケーション、サービス、システム等の構築を容易にするための技術を提供することである。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、本発明の一態様は、ネットワーク事業者により運営されるSTUNサーバ、TURNサーバ及び認証サーバを介しWebRTC (Web Real-Time Communication)を利用してピアツーピア通信を実行する通信装置であって、前記認証サーバと通信することによって当該通信装置が前記STUNサーバ及び前記TURNサーバにアクセス可能であるか判断し、当該通信装置がSTUNサーバ及びTURNサーバにアクセス可能であると判断した前記認証サーバにより発行された認証キーを管理する認証機能と、前記WebRTCに実装されたNAT/FW (Network Address Translation/Firewall)を通過するためのICE (Interactive Connectivity Establishment)を実行することによって、前記認証キーを用いて前記STUNサーバ又は前記TURNサーバにアクセスし、前記ピアツーピア通信のためのIPアドレスを取得するICE機能とを有する通信装置に関する。
【発明の効果】
【００１３】
本発明によると、ピアツーピア通信を伴うアプリケーション、サービス、システム等の構築を容易に実現することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】図１は、本発明の一実施例による通信システムを示す概略図である。
【図２】図２は、本発明の一実施例によるネットワーク事業者、アプリケーション開発者及びサービス提供者の関係を示す概略図である。
【図３】図３は、本発明の一実施例によるSTUNサーバの構成を示すブロック図である。
【図４】図４は、本発明の一実施例によるTURNサーバの構成を示すブロック図である。
【図５】図５は、本発明の一実施例による認証サーバの構成を示すブロック図である。
【図６】図６は、本発明の一実施例によるデータベースの構成を示すブロック図である。
【図７】図７は、本発明の一実施例によるアプリケーションの構成を示すブロック図である。
【図８】図８は、本発明の一実施例によるM2Mデータ通信への適用例を示す概略図である。
【図９】図９は、従来の通信経路の情報フローを示すシーケンス図である。
【図１０】図１０は、本発明の一実施例による通信経路の情報フローを示すシーケンス図である。
【図１１】図１１は、本発明の一実施例による自律分散型コンピューティング基盤への適用例を示す概略図である。
【発明を実施するための形態】
【００１５】
以下、図面に基づいて本発明の実施の形態を説明する。
【００１６】
まず、図１〜２を参照して、本発明の一実施例による通信システムを説明する。本実施例による通信システムでは、ICE機能によるWebRTCを利用したピアツーピア通信が提供される。図１は、本発明の一実施例による通信システムを示す概略図である。
【００１７】
図１に示されるように、通信システム１０は、STUNサーバ１００、TURNサーバ２００、認証サーバ３００、データベース４００及び複数の通信装置に搭載されたアプリケーション５００１〜５００ｎ（以下、アプリケーション５００と総称する）を有する。
【００１８】
STUNサーバ１００は、非特許文献１に規定されたSTUN機能１１０と共に、以下で詳細に説明されるようなアクセス制限機能１２０、コール数カウント機能１３０及びデータベース連携機能１４０を有する。
【００１９】
TURNサーバ２００は、非特許文献２に規定されたTURN機能２１０と共に、以下で詳細に説明されるようなアクセス制限機能２２０、コール数カウント機能２３０、データベース連携機能２４０及び利用帯域測定機能２５０を有する。
【００２０】
認証サーバ３００は、以下で詳細に説明されるような認証機能３１０、認証キー発行機能３２０及びデータベース連携機能３３０を有する。認証サーバ３００は、これらの機能を利用して、アプリケーション５００からの情報に基づきアプリケーション５００によるSTUNサーバ１００及びTURNサーバ２００の利用可能性を判断し、認証キーを発行する。
【００２１】
STUNサーバ１００、TURNサーバ２００及び認証サーバ３００は、ネットワーク事業者により運営される。一例となるハードウェア構成として、各サーバは、バスＢを介し相互接続されるドライブ装置、補助記憶装置、メモリ装置、CPU (Central Processing Unit)及びインタフェース装置を有する。STUNサーバ１００、TURNサーバ２００及び認証サーバ３００における後述される各種機能及び処理を実現する各種プログラムは、光ディスクや半導体メモリなどの記録媒体によって提供されてもよい。プログラムを記憶した記録媒体がドライブ装置にセットされると、プログラムが記録媒体からドライブ装置を介して補助記憶装置にインストールされる。但し、プログラムのインストールは必ずしも記録媒体により行う必要はなく、ネットワーク（図示せず）を介し何れかの外部装置からダウンロードするようにしてもよい。補助記憶装置は、インストールされたプログラムを格納すると共に、必要なファイルやデータなどを格納する。メモリ装置は、プログラムの起動指示があった場合に、補助記憶装置からプログラムやデータを読み出して格納する。CPUは、情報を処理するプロセッサであって、メモリ装置に格納されたプログラムやプログラムを実行するのに必要なパラメータなどの各種データに従って、後述されるようなSTUNサーバ１００、TURNサーバ２００及び認証サーバ３００の各種機能及び処理を実行する。インタフェース装置は、ネットワーク又は外部装置に接続するための通信インタフェースとして用いられる。しかしながら、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００は、上述したハードウェア構成に限定されるものでなく、何れか適切な情報処理装置として実現されてもよい。
【００２２】
データベース４００は、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００に通信接続され、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００から提供される各種データ及び情報を格納すると共に、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００からの取得要求に応答して、格納されているデータ及び情報を要求元のサーバ１００、２００及び３００に提供する。データベース４００は、STUNサーバ１００、TURNサーバ２００、認証サーバ３００及びアプリケーション５００に対応してSTUN利用データベース４１０、TURN利用データベース４２０、ユーザデータベース４３０及びアプリケーションデータベース４４０を有する。STUN利用データベース４１０、TURN利用データベース４２０、ユーザデータベース４３０及びアプリケーションデータベース４４０はそれぞれ、以下で詳細に説明されるように、STUNサーバ１００、TURNサーバ２００、認証サーバ３００及びアプリケーション５００とやりとりすることによって、STUNサーバ１００の利用情報、TURNサーバ２００の利用情報、認証情報やユーザ情報及びアプリケーション情報を保持する。
【００２３】
データベース４００の一例となるハードウェア構成は、上述したSTUNサーバ１００、TURNサーバ２００及び認証サーバ３００と同様のものであってもよいし、あるいは、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００に接続された補助記憶装置として実現されてもよい。
【００２４】
アプリケーション５００は、各通信装置上で実行されるピアツーピア通信を伴うアプリケーションである。WebRTCでは、ICE機能の利用が必須とされているため、WebRTCのクライアントを用いることでICE機能を流用する。ここで、WebRTCクライアントは、ブラウザそのもの以外にもWebkit等のブラウザコンポーネントやWebRTC準拠のネイティブアプリ用コンポーネントを含む。通信システム１０では、２個以上の任意の数のアプリケーションを含むものとする。
【００２５】
アプリケーション５００が実行される通信装置は、典型的には、パーソナルコンピュータ、携帯電話、スマートフォン、タブレットなどの通信機能を備えた情報処理装置であり、図示されるように、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００に通信接続される。一例となるハードウェア構成として、通信装置は、バスＢを介し相互接続されるドライブ装置、補助記憶装置、メモリ装置、CPU、通信回路、表示装置及び入力装置を有する。通信ノードにおける後述される各種機能及び処理を実現するプログラムは、ネットワークを介してサーバなどからダウンロードされてもよいし、メモリカードやUSB (Universal Serial Bus)メモリなどの記録媒体によって提供されてもよい。プログラムを記憶した記録媒体がドライブ装置にセットされると、プログラムが記録媒体からドライブ装置を介して補助記憶装置にインストールされる。補助記憶装置は、インストールされたプログラムを格納すると共に、必要なファイルやデータなどを格納する。メモリ装置は、プログラムの起動指示があった場合に、補助記憶装置からプログラムやデータを読み出して格納する。CPUは、情報を処理するプロセッサであって、メモリ装置に格納されたプログラムやプログラムを実行するのに必要なパラメータなどの各種データに従って、後述されるような通信ノードの各種機能及び処理を実行する。通信回路は、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００に通信接続するための通信インタフェースとして用いられる。表示装置は、CPUによる処理結果などを表示するのに用いられ、例えば、液晶ディスプレイ、ブラウン管ディスプレイ(CRT)、プラズマディスプレイなどの各種ディスプレイにより実現される。入力装置は、ユーザが通信ノードに命令やデータなどを入力するのに用いられ、例えば、タッチパネル、キーボード、スタイラス、マイクロフォン、カメラ、スキャナなどにより実現される。
【００２６】
なお、STUNサーバ１００、TURNサーバ２００、認証サーバ３００、データベース４００及びアプリケーション５００は独立したエンティティとして図示及び記載されているが、本発明はこれに限定されるものでなく、これらのエンティティの何れか２個以上が組み合わされて実装されてもよい。また、他の実施例では、アプリケーション５００を提供するためのアプリケーションサーバが設けられてもよい。
【００２７】
本実施例による通信システム１０では、ICE機能によるWebRTCを利用したピアツーピア通信は、ネットワーク事業者、サービス提供者及びアプリケーション開発者などの各主体間の連携により提供される。図２は、本発明の一実施例によるネットワーク事業者、アプリケーション開発者及びサービス提供者の関係を示す概略図である。図２に示されるように、ネットワーク事業者は、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００を運営し、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００の上述した各種機能をサービス提供者及びアプリケーション開発者に提供する。これの対価として、ネットワーク事業者は、サービス提供者やアプリケーション開発者から利用料金を受け取り、あるいは、アプリケーション開発者のためのソフトウェア開発キット（SDK）の購入代金を受け取る。これらの利用料金は、STUNサーバ１００やTURNサーバ２００の各種機能の利用回数による課金、認証サーバ３００によって割り当てられるトランスポートアドレスの個数に応じた課金、TURNサーバ２００のTURN機能の利用時間に応じた課金、時間／日／月／年単位でのSTUNサーバ１００やTURNサーバ２００の利用可能性の提供による定額制の課金（ICE関連サーバのホスティングサービス）などが考えられる。課金の際、ネットワーク事業者は、必要に応じてデータベース４００上の利用情報を参照し、課金のために利用するようにしてもよい。
【００２８】
次に、図３〜７を参照して、本発明の一実施例による通信システム１０の上述した構成要素をより詳細に説明する。
【００２９】
図３は、本発明の一実施例によるSTUNサーバの構成を示すブロック図である。図３に示されるように、STUNサーバ１００は、STUN機能１１０、アクセス制限機能１２０、コール数カウント機能１３０及びデータベース連携機能１４０から構成され、データベース４００及びアプリケーション５００に通信接続される。
【００３０】
STUN機能１１０は、非特許文献１に記載されたSTUN機能に関するサーバ側に必要とされる機能を有し、アクセス制限機能１２０によってアクセスが許可されたアプリケーション５００に対してSTUN機能を提供する。
【００３１】
アクセス制限機能１２０は、アプリケーション５００によるSTUN機能１１０の利用可否を判断する。具体的には、アクセス制限機能１２０は、データベース連携機能１４０を介しデータベース４００にアクセスし、アクセス要求元のアプリケーション５００又はユーザが認証サーバ３００により認証されたアプリケーション又はユーザであるか判断する。アクセス要求元のアプリケーション５００又はユーザが認証サーバ３００により認証されたアプリケーション又はユーザである場合、アクセス制限機能１２０は、アクセス要求元のアプリケーション５００に対してSTUN機能１１０へのアクセスを許可する。他方、アクセス要求元のアプリケーション５００又はユーザが認証サーバ３００により認証されたアプリケーション又はユーザでない場合、アクセス制限機能１２０は、アクセス要求元のアプリケーション５００に対してSTUN機能１１０へのアクセスを拒絶する。
【００３２】
コール数カウント機能１３０は、アクセス制限機能１２０によりアクセス許可されたアプリケーション５００がSTUN機能１１０を利用すると、利用回数（コール数）をカウント又はインクリメントし、データベース連携機能１４０を介しSTUN利用データベース４１０に更新後の利用回数を保存する。
【００３３】
データベース連携機能１４０は、STUNサーバ１００とデータベース４００との間のやりとりを実行する。例えば、データベース連携機能１４０は、STUN機能１１０からの利用情報の読み書き要求、アクセス制限機能１２０からの認証可否判定のための認証情報の読み書き要求、コール数カウント機能１３０からの利用回数の読み書き要求などに応答して、データベース４００に対して要求された処理を実行する。
【００３４】
図４は、本発明の一実施例によるTURNサーバの構成を示すブロック図である。図４に示されるように、TURNサーバ２００は、TURN機能２１０、アクセス制限機能２２０、コール数カウント機能２３０、データベース連携機能２４０及び利用帯域測定機能２５０から構成され、データベース４００及びアプリケーション５００に通信接続される。
【００３５】
TURN機能２１０は、非特許文献２に記載されたTURN機能に関するサーバ側に必要とされる機能を有し、アクセス制限機能２２０によってアクセスが許可されたアプリケーション５００に対してTURN機能を提供する。
【００３６】
アクセス制限機能２２０は、アプリケーション５００によるTURN機能２１０の利用可否を判断する。具体的には、アクセス制限機能２２０は、データベース連携機能２４０を介しデータベース４００にアクセスし、アクセス要求元のアプリケーション５００又はユーザが認証サーバ３００により認証されたアプリケーション又はユーザであるか判断する。アクセス要求元のアプリケーション５００又はユーザが認証サーバ３００により認証されたアプリケーション又はユーザである場合、アクセス制限機能２２０は、アクセス要求元のアプリケーション５００に対してTURN機能２１０へのアクセスを許可する。他方、アクセス要求元のアプリケーション５００又はユーザが認証サーバ３００により認証されたアプリケーション又はユーザでない場合、アクセス制限機能２２０は、アクセス要求元のアプリケーション５００に対してTURN機能２１０へのアクセスを拒絶する。
【００３７】
コール数カウント機能２３０は、アクセス制限機能２２０によりアクセス許可されたアプリケーション５００がTURN機能２１０を利用すると、利用回数（コール数）をカウント又はインクリメントし、データベース連携機能２４０を介しTURN利用データベース４２０に更新後の利用回数を保存する。
【００３８】
データベース連携機能２４０は、TURNサーバ２００とデータベース４００との間のやりとりを実行する。例えば、データベース連携機能２４０は、TURN機能２１０からの利用情報の読み書き要求、アクセス制限機能２２０からの認証可否判定のための認証情報の読み書き要求、コール数カウント機能２３０からの利用回数の読み書き要求、利用帯域測定機能２５０からの測定された利用帯域の読み書き要求などに応答して、データベース４００に対して要求された処理を実行する。
【００３９】
利用帯域測定機能２５０は、アクセス制限機能２２０によりアクセス許可されたアプリケーション５００に対してTURNサーバ２００が割り当てた利用帯域を測定し、データベース連携機能２４０を介しTURN利用データベース４２０に測定された利用帯域を保存する。この利用帯域の測定方法として、例えば、SDP (Session Description Protocol)メッセージに記載された推定帯域幅を利用する方法、パケットダンプによって単位時間あたりの通信料を測定する方法などが考えられるが、これらに限定されるものでなく、他の何れか適切な測定方法が利用されてもよい。
【００４０】
図５は、本発明の一実施例による認証サーバの構成を示すブロック図である。認証サーバ３００は、アプリケーション５００によるSTUNサーバ１００及びTURNサーバ２００の利用可能性を制御し、認証されたアプリケーション５００に対してSTUNサーバ１００及びTURNサーバ２００へのアクセスを許可する。図５に示されるように、認証サーバ３００は、認証機能３１０、認証キー発行機能３２０及びデータベース連携機能３３０から構成され、データベース４００及びアプリケーション５００に通信接続される。
【００４１】
認証機能３１０は、アプリケーション５００に対して認証処理を実行し、アクセス要求元のアプリケーション５００がSTUNサーバ１００、TURNサーバ２００及びこれらを介したデータベース４００へのアクセスが可能であるか判断する。このアプリケーション５００に対する認証処理として、例えば、IDやパスワードを用いた認証、アクセスドメインに応じた認証キーの発行の判断、GPS (Global Positioning System)等の物理的なロケーション情報による認証、SIM (Subscriber Identity Module)カードやMacアドレス等のハードウェア情報を用いた認証などが考えられるが、これらに限定されるものでなく、他の何れか適切な認証方法が利用されてもよい。
【００４２】
認証キー発行機能３２０は、認証機能３１０がアプリケーション５００に対する認証処理を完了し、アプリケーション５００に対してSTUNサーバ１００やTURNサーバ２００へのアクセスを許可した場合、STUNサーバ１００やTURNサーバ２００へのアクセスに必要となる認証キーを発行する。認証キーの発行方法として、認証に用いた情報を種としたSHA (Secure Hash Algorithm)等のアルゴリズムによるハッシュ値の生成などが考えられるが、これらに限定されるものでなく、他の何れか適切な認証キー発行方法が利用されてもよい。
【００４３】
データベース連携機能３３０は、認証サーバ３００とデータベース４００との間のやりとりを実行する。例えば、データベース連携機能３３０は、認証機能３１０からの利用情報の読み書き要求、認証キー発行機能３２０からの各種情報の読み書き要求などに応答して、データベース４００に対して要求された処理を実行する。
【００４４】
図６は、本発明の一実施例によるデータベースの構成を示すブロック図である。データベース４００は、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００とやりとりすることによって書き込まれたデータ、契約時やデフォルトで設定されたデータなどを保持すると共に、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００からの取得要求に応答して保持されているデータを提供する。図６に示されるように、データベース４００は、STUN利用データベース４１０、TURN利用データベース４２０、ユーザデータベース４３０及びアプリケーションデータベース４４０から構成され、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００と通信接続される。
【００４５】
STUN利用データベース４１０は、STUNサーバ１００からアクセスされるデータベースであり、STUNサーバ１００の利用情報やコール数などを保持する。これらの情報は、ユーザデータベース４３０やアプリケーションデータベース４４０の認証情報と関連付けされる。
【００４６】
TURN利用データベース４２０は、TURNサーバ２００からアクセスされるデータベースであり、TURNサーバ２００の利用情報、コール数や利用帯域量などを保持する。これらの情報は、ユーザデータベース４３０やアプリケーションデータベース４４０の認証情報と関連付けされる。
【００４７】
ユーザデータベース４３０は、NAT/FWの通過に関連するICE機能などの各種機能を提供するSTUNサーバ１００及びTURNサーバ２００が利用可能なユーザに関するユーザ情報、認証状態及び認証キーを格納する。ユーザに対してSTUNサーバ１００及びTURNサーバ２００の利用が許可されている場合（ユーザIDとパスワードなどにより認証が行われる場合など）、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００は、ユーザデータベース４３０に格納されているユーザ情報や認証情報を参照して、ユーザがSTUNサーバ１００及びTURNサーバ２００にアクセス可能であるか判断する。一実施例では、STUNサーバ１００及びTURNサーバ２００は、アクセス要求元のユーザが認証サーバ３００により認証キーが発行されたユーザであるか判断するようにしてもよい。アクセス要求元のユーザに対する認証キーがユーザデータベース４３０に格納されている場合、STUNサーバ１００及びTURNサーバ２００は、アクセス要求元のユーザに対してSTUN機能１１０又はTURN機能２１０へのアクセスを許可するようにしてもよい。他方、アクセス要求元のユーザに対する認証キーがユーザデータベース４３０に格納されていない場合、STUNサーバ１００及びTURNサーバ２００は、アクセス要求元のユーザに対してSTUN機能１１０又はTURN機能２１０へのアクセスを拒絶するようにしてもよい。なお、ユーザデータベース４３０は、ユーザごとによる認証判断が行われない場合（例えば、アクセス元のドメインだけで認証判断が行われる場合など）、必要ではない。
【００４８】
アプリケーションデータベース４４０は、NAT/FWの通過に関連するICE機能などの各種機能を提供するSTUNサーバ１００及びTURNサーバ２００が利用可能なアプリケーション５００に関するアプリケーション情報、認証状態及び認証キーを格納する。アプリケーション５００に対してSTUNサーバ１００及びTURNサーバ２００の利用が許可されている場合（アクセス元のドメインだけで認証判断が行われる場合など）、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００は、アプリケーションデータベース４４０に格納されているアプリケーション情報や認証情報を参照して、アプリケーション５００がSTUNサーバ１００及びTURNサーバ２００にアクセス可能であるか判断する。一実施例では、STUNサーバ１００及びTURNサーバ２００は、アクセス要求元のアプリケーション５００が認証サーバ３００により認証キーが発行されたアプリケーションであるか判断するようにしてもよい。アクセス要求元のアプリケーションに対する認証キーがアプリケーションデータベース４４０に格納されている場合、STUNサーバ１００及びTURNサーバ２００は、アクセス要求元のアプリケーション５００に対してSTUN機能１１０又はTURN機能２１０へのアクセスを許可するようにしてもよい。他方、アクセス要求元のアプリケーション５００に対する認証キーがアプリケーションデータベース４４０に格納されていない場合、STUNサーバ１００及びTURNサーバ２００は、アクセス要求元のアプリケーション５００に対してSTUN機能１１０又はTURN機能２１０へのアクセスを拒絶するようにしてもよい。なお、アプリケーションデータベース４４０は、アプリケーションごとによる認証判断が行われない場合（例えば、ユーザIDとパスワードなどにより認証が行われる場合など）、必要ではない。
【００４９】
図７は、本発明の一実施例によるアプリケーションの構成を示すブロック図である。アプリケーション５００は、ピアツーピア通信を伴うアプリケーションであり、STUNサーバ１００、TURNサーバ２００及び認証サーバ３００とのやりとりなど、当該アプリケーション５００におけるICEの利用に関する処理を実行するICEクライアント５１０を有する。ICEクライアント５１０は、認証機能５２０及びICE機能５３０から構成される。
【００５０】
認証機能５２０は、アプリケーション５００がSTUNサーバ１００、TURNサーバ２００及びこれらを介したデータベース４００へのアクセスが可能であると判断された結果として、認証サーバ３００により発行された認証キーを以降の通信に利用するため管理する。アプリケーション５００の使用時やインストール時を含む任意のタイミングにおいて、認証機能５２０は、認証情報を認証サーバ３００に送信し、認証が成功すると、認証サーバ３００から認証キーを受信する。このアプリケーション５００に対する認証処理として、例えば、IDやパスワードを入力／送信することによる認証、アクセスドメイン情報を認証サーバ３００に渡して認証キーの発行を要求する方法、GPS等の物理的なロケーション情報を認証サーバ３００に渡して認証を受ける方法、SIMカードやMacアドレス等のハードウェア情報を認証サーバに渡して認証を受ける方法などが考えられるが、これらに限定されるものでなく、他の何れか適切な認証方法が利用されてもよい。
【００５１】
ICE機能５３０は、非特許文献３に記載されたICEに関するクライアント側に必要とされる機能である。ICE機能５３０は、ICEの実装を必須としているWebRTCに関連するコンポーネント、例えば、ブラウザ、Webkitなどのブラウザレンダリングエンジン、WebRTC仕様に基づくピアツーピア通信用ライブラリなどを利用するものとする。
【００５２】
次に、図８〜１０を参照して、本発明の一実施例によるM2M (Machine-to-Machine)データ通信を説明する。本実施例では、通信システム１０においてM2Mデータ通信が実行され、M2Mのゲートウェイ(GW)等にレンダリングエンジンやブラウザのネイティブコードを埋め込むことによってピアツーピア通信を実現できる。本実施例では、アプリケーション５００はM2M GWに対応する。
【００５３】
従来のM2M通信では、図８に示されるように、NAT/FWの存在によりM2M GW同士の通信が実現できないため、M2M GW６００Ａ及び６００ＢはM2Mサーバ６５０を介し通信を実現する必要があった。この場合、図９に示されるように、ステップＡ−１〜Ａ−２において、M2MアプリＡ５００Ａは自らをM2Mサーバ６５０に登録し、他方、ステップＡ−３〜Ａ−４において、M2MアプリＢ５００Ｂは自らをM2Mサーバ６５０に登録する。その後、ステップＢ−１〜Ｂ−５において、通信を開始したいM2MアプリＡ５００ＡがM2M GW A６００Ａに対して所望の情報を特定したラベル情報等を渡すと、M2M GW A６００Ａに、ラベル情報等に基づきM2Mサーバ６５０を介しM2MアプリＢ５００Ｂが収容されるM2M GW B６００Ｂが通知される。ステップＢ−６において、M2Mサーバ６５０を介しM2MアプリＡ５００ＡとM2MアプリＢ５００Ｂとの間で通信が開始される。M2Mサーバ６５０では、アプリケーションの検出と正しいゲートウェイへの振り分け（リターゲティング）が行われるため、M2Mアプリやゲートウェイの増加に従って、M2Mサーバ６５０における負荷が急激に増大する。
【００５４】
他方、上述した実施例による通信システム１０を利用することによって、M2M GW６００Ａ及び６００Ｂは、STUNサーバ１００によって通信経路が確立された場合には、図示されるように、直接的に通信することが可能になり、STUNサーバ１００によって通信経路が確立されなかった場合でも、図示されるように、TURNサーバ２００を介し通信することが可能になる。
【００５５】
図１０に示されるように、図９のステップＡ−１〜Ａ−４と同様に、ステップＡ−１〜Ａ−２において、M2MアプリＡ５００Ａは自らをM2Mサーバ６５０に登録し、他方、ステップＡ−３〜Ａ−４において、M2MアプリＢ５００Ｂは自らをM2Mサーバ６５０に登録する。
【００５６】
その後、ステップＢ−１〜Ｂ−３において、M2M GW A６００Ａは、認証サーバ３００による認証を受け、認証キーを取得する。認証サーバ３００は、認証されたM2M GW A６００Ａの認証情報をデータベース４００に登録する。同様に、ステップＢ−４〜Ｂ−６において、M2M GW B６００Ｂは、認証サーバ３００による認証を受け、認証キーを取得する。認証サーバ３００は、認証されたM2M GW B６００Ｂの認証情報をデータベース４００に登録する。
【００５７】
ステップＣ−１において、通信を開始したいM2MアプリＡ５００ＡがM2M GW A６００Ａに対して所望の情報を特定したラベル情報等を渡す。
【００５８】
STUNサーバ１００による通信経路を確立する場合、ステップＣ−２〜Ｃ−５において、M2M GW A６００Ａは、自らのSTUNサーバ１００の利用可能性を通知するため、STUNサーバ１００に認証キーを送信する。STUNサーバ１００は、受信した認証キーをデータベース４００に照会し、受信した認証キーと認証サーバ３００によりデータベース４００に登録された認証キーとを比較することによって、M2M GW A６００ＡがSTUNサーバ１００にアクセス可能であるか確認する。２つの認証キーが同一であり、M2M GW A６００ＡがSTUNサーバ１００にアクセス可能であると判断した場合、STUNサーバ１００は、M2M GW A６００ＡにグローバルIPアドレスとポート番号とを通知する。
【００５９】
他方、TURNサーバ２００による通信経路を確立する場合、ステップＣ−６〜Ｃ−１３において、M2M GW A６００Ａは、次に自らのTURNサーバ２００の利用可能性を通知するため、TURNサーバ２００に認証キーを送信する。TURNサーバ２００は、受信した認証キーをデータベース４００に照会し、受信した認証キーと認証サーバ３００によりデータベース４００に登録された認証キーとを比較することによって、M2M GW A６００ＡがTURNサーバ２００にアクセス可能であるか確認する。２つの認証キーが同一であり、M2M GW A６００ＡがTURNサーバ２００にアクセス可能であると判断した場合、TURNサーバ２００は、M2M GW A６００Ａにリレー用IPアドレスとポート番号とを通知する。
【００６０】
ステップＣ−１４〜Ｃ−１５において、M2M GW A６００Ａは、M2Mサーバ６５０にラベル情報等を渡すことによって、M2Mサーバ６５０を経由してM2M GW B６００Ｂを検出し、ステップＣ−２〜Ｃ−５において取得したグローバルIPアドレス、又はステップＣ−６〜Ｃ−１３において取得したリレー用IPアドレスを含む通信開始要求信号を検出したM2M GW B６００Ｂに送信する。
【００６１】
通信開始要求信号にグローバルIPアドレスが含まれていた場合、ステップＣ−１６〜Ｃ−１９において、M2M GW B６００Ｂは、自らのSTUNサーバ１００の利用可能性を通知するため、STUNサーバ１００に認証キーを送信する。STUNサーバ１００は、受信した認証キーをデータベース４００に照会し、受信した認証キーと認証サーバ３００によりデータベース４００に登録された認証キーとを比較することによって、M2M GW B６００ＢがSTUNサーバ１００にアクセス可能であるか確認する。２つの認証キーが同一であり、M2M GW B６００ＢがSTUNサーバ１００にアクセス可能であると判断した場合、STUNサーバ１００は、M2M GW B６００ＢにグローバルIPアドレスとポート番号とを通知する。
【００６２】
他方、通信開始要求信号にリレー用IPアドレスが含まれていた場合、ステップＣ−２０〜Ｃ−２３において、M2M GW B６００Ｂは、次に自らのTURNサーバ２００の利用可能性を通知するため、TURNサーバ２００に認証キーを送信する。TURNサーバ２００は、受信した認証キーをデータベース４００に照会し、受信した認証キーと認証サーバ３００によりデータベース４００に登録された認証キーとを比較することによって、M2M GW B６００ＢがTURNサーバ２００にアクセス可能であるか確認する。２つの認証キーが同一であり、M2M GW B６００ＢがTURNサーバ２００にアクセス可能であると判断した場合、TURNサーバ２００は、M2M GW B６００Ｂにリレー用IPアドレスとポート番号とを通知する。
【００６３】
ステップＣ−２４〜Ｃ−２５において、M2M GW B６００Ｂは、M2Mサーバ６５０を経由して取得したグローバルIPアドレス又はリレー用IPアドレスを含む通信応答信号をM2M GW A６００Ａに送信する。
【００６４】
このようにして、ステップＣ−２６において、M2M GW A６００ＡとM2M GW B６００Ｂとの間でピアツーピア通信の疎通性が確認される。
【００６５】
ステップＣ−２７において、STUNによるNAT/FWの通過が実現された場合、M2M GW A６００ＡとM2M GW B６００Ｂとの間にピアツーピアの通信路が確立され、TURNによるNAT/FWの通過が実現された場合、TURNサーバ２００を中継したM2M GW A６００ＡとM2M GW B６００Ｂとの間にピアツーピアの通信路が確立される。これにより、M2Mサーバ６５０を介すことなくM2M GW A６００ＡとM2M GW B６００Ｂとの間にピアツーピアの通信路を確立することが可能になる。
【００６６】
上述したフローは、M2Mサーバ６５０を介すことなくM2M GW A６００ＡとM2M GW B６００Ｂとの間にピアツーピアの通信路を確立する処理の単なる一例であり、登録・認証のタイミングや通信開始要求信号の送信などは異なる順序で又は並列的に行われてもよい。
【００６７】
従来は、M2Mサービスの開発者やサービス提供者がICE機能を利用したピアツーピア通信を実現するための前提となる一定水準以上の知識や設備が必要であった。しかしながら、本実施例によると、開発者やサービス提供者は、ネットワーク事業者が提供するサーバ機能を利用し、WebRTCのような市中のICEクライアント実装を流用することが可能になり、従来技術による知識や設備について高い要求を求めることなく、ネットワーク側とクライアント側との双方においてピアツーピア通信をより容易に実現することが可能になる。この結果、M2Mサーバの負荷を軽減することが可能になり、サーバの設備投資を低減したり、データの通信遅延やパケットロスを減少させることによる通信品質の向上などの効果を奏することが可能になる。また、ネットワーク事業者は、アプリケーション又はユーザによるサーバの利用に対してコール数や利用帯域幅などに応じて課金することによって、サーバの運営コストを賄うことが可能である。
【００６８】
次に、図１１を参照して、本発明の一実施例による自律分散型コンピューティングを説明する。本実施例では、アプリケーション５００は自律分散型コンピューティングアプリに対応する。図１１に示されるように、ICEクライアント５１０を有する自律分散型コンピューティングアプリ５００Ａ，Ｂは、従来はNAT/FWの存在によりコンピューティングアプリ同士の通信が実現できないため、管理サーバ７００を介し通信を実現する必要があった。この場合、管理サーバ７００では、アプリケーションの検出や自律分散型コンピューティングアプリ間の通信のため、自律分散型コンピューティングアプリの増加に従って、管理サーバ７００における負荷が急激に増大する。
【００６９】
他方、上述した実施例による通信システム１０を利用することによって、自律分散型コンピューティングアプリ５００Ａ，Ｂは、STUNサーバ１００によって通信経路が確立された場合には、図示されるように、直接的に通信することが可能になり、STUNサーバ１００によって通信経路が確立されなかった場合でも、図示されるように、TURNサーバ２００を介し通信することが可能になる。本実施例によると、開発者やサービス提供者は、ネットワーク事業者が提供するサーバ機能を利用し、WebRTCのような市中のICEクライアント実装を流用することが可能になり、従来技術による知識や設備について高い要求を求めることなく、ネットワーク側とクライアント側との双方においてピアツーピア通信をより容易に実現することが可能になる。この結果、管理サーバの負荷を軽減することが可能になり、サーバの設備投資を低減したり、データの通信遅延やパケットロスを減少させることによる通信品質の向上などの効果を奏することが可能になる。また、ネットワーク事業者は、アプリケーション又はユーザによるサーバの利用に対してコール数や利用帯域幅などに応じて課金することによって、サーバの運営コストを賄うことが可能である。
【００７０】
他の実施例として、上述した実施例を応用してオーバレイネットワーク、アドホックネットワーク、ファイル交換用ネットワーク、VPN (Virtual Private Network)アプリケーションを実現することも可能であろう。
【００７１】
このように、本発明によると、アプリケーション開発者やサービス提供者は、簡単にピアツーピア通信を含むアプリケーションを構築することが可能となる。ネットワーク事業者が、ICEのサーバ機能を提供してアプリケーション開発者と取引を行いつつ、WebRTCを利用してICEクライアントを構築することでアプリケーション開発者／提供者はICEのためのサーバを提供する必要がなくなるうえ、クライアント側の実装を行う必要もなくなる。
【００７２】
以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００７３】
１０  通信システム
１００  STUNサーバ
２００  TURNサーバ
３００  認証サーバ
４００  データベース
５００  アプリケーション
【図１】
2015153076.tif 000003
【図３】
2015153076.tif 000004
【図４】
2015153076.tif 000005
【図５】
2015153076.tif 000006
【図６】
2015153076.tif 000007
【図７】
2015153076.tif 000008
【図８】
2015153076.tif 000009
【図９】
2015153076.tif 000010
【図１０】
2015153076.tif 000011
【図１１】
2015153076.tif 000012
【図２】
2015153076.tif 000013