【文献】
森 美華 他,WebRTCデータチャネル接続機能を活用した複数サービス提供のための共通PFに関する一検討,電子情報通信学会2014年通信ソサイエティ大会講演論文集2,2014年 9月 9日,p.65(B-7-8)
【文献】
日紫喜 徹也 他,WebRTCの標準化動向,電子情報通信学会誌,2013年10月 1日,第96巻、第10号,pp.790-796
【文献】
Generation of peer ID,Google グループ,2014年 4月26日,URL,https://groups.google.com/forum/#!topic/peerjs/VhfaRK0bLlc
【文献】
WERNER, Max Jonas, VOGT, Christian, SCHMIDT, Thomas C,Let our browsers socialize: building user-centric content communities on WebRTC,In Distributed Computing Systems Workshops (ICDCSW), 2014 IEEE 34th International Conference on,IEEE,2014年,pp. 37-44
【文献】
古川聖, 坂谷精一,WebRTCにおける付加サービス実現方式の一検討,電子情報通信学会技術研究報告 Vol.114 No.28 NS2014−24,日本,一般社団法人電子情報通信学会,2014年 5月 8日,第1−4頁
(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、上記の従来技術Aのように、C/S型の通信形態だと、クライアント(ユーザ端末)の数が増加すればするほどサーバに処理・中継負荷がかかり、サーバがボトルネックとなって遅延が生じる。あるいは、サーバダウンによってゲームを続行できないといった課題が生じる。
【0007】
一方で、従来技術Bのように、P2P型の通信で互いのゲームデータをユーザ同士で交換しようとすると、P2P型の通信を実現するアプリケーションの開発が煩雑という課題がある。これは、P2P通信を実現するためには、NAT/FW(Network Address Translation/Firewall(ネットワークアドレス変換またはファイアウォール))越え問題を解決しなければならないからである。現在、通信機器が通信網に接続する際に、ルータと呼ばれる機器に接続する構成が一般的になっている。
【0008】
このルータはLAN(Local Area Network)側の通信機器のIP(Internet Protocol)アドレスやポート番号を、WAN(Wide Area Network)側のIPアドレスやポート番号に変更する機能を有し、さらに、LAN側からWAN側への通信を検知して初めて、WAN側からパケットを中継するFW機能を有している。
そのため、異なるルータの配下にある通信端末同士が通信をしようとしても、パケットがルータで破棄されるため、お互い通信を開始できない。
【0009】
この課題を解決するために、UPnP(Universal Plug and Play)やピアのグローバルIPアドレスとポート番号を知らせてUDPホールパンチング技術によりNAT/FW通過を実現するSTUN(Simple Traversal of UDP through NATs)、メディアやアプリの配信サーバを介さずにリレーサーバを配備するTURN(Traversal Utilities for NAT)、さらに、STUNとTURNを組み合わせ、体系立ててNAT/FWを通過するためのプロシージャ手順としてまとめたICE(Interactive Connectivity Establishment)等の方法が知られている。しかし、いずれの仕組みを用いても、これらの仕組みを利用できるようにアプリケーションを開発しなければならず、その作業は非常に煩雑となる。
【0010】
本発明が解決しようとする課題は、サーバ負荷やアプリケーション開発にかかる負荷を低減してユーザ端末同士の通信を行なうことを可能とする通信システム、方法及びプログラムを提供することである。
【課題を解決するための手段】
【0011】
上記目的を達成するために、この発明の実施形態における通信システムの第1の態様は、通信ネットワークに接続された第1のユーザ端末と第2のユーザ端末との間で通信するシステムであって、前記第1のユーザ端末からの、前記第1のユーザ端末に対応するユーザの識別情報
、および前記第1のユーザ端末が契約する事業者であって、ネットワークアドレス変換(NAT)またはファイアウォール(FW)設備を越えて前記通信ネットワークに接続された前記第1および第2のユーザ端末を接続する機能を有するWebRTC PF(Web Real-time Communications Platform)を使用する事業者の識別情報を含む要求である、
前記第1のユーザ端末が前記WebRTC
PFを使用するための
第1のWebRTC PF利用者識別子の発行要求に従って、前記第1のWebRTC PF利用者識別子を前記第1のユーザ端末に発行し、前記第2のユーザ端末からの、前記第2のユーザ端末に対応するユーザの識別情報
、および前記第2のユーザ端末が契約する事業者であって前記WebRTC PFを使用する事業者の識別情報を含む要求である、前記
第2のユーザ端末が前記WebRTC PFを使用するための第2のWebRTC PF利用者識別子の発行要求に従って、前記第2のWebRTC PF利用者識別子を前記第2のユーザ端末に発行する識別子発行手段と、前記識別子発行手段により発行した前記第
1のWebRTC PF利用者識別子を
前記第1のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報とともに管理
し、前記識別子発行手段により発行した前記第2のWebRTC PF利用者識別子を前記第2のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報とともに管理する識別子管理手段と、前記第1のユーザ端末からの、通信相手としてのユーザ端末の設定要求にしたがい、前記通信相手として前記第2のユーザ端末が設定された場合に、前記識別子管理手段が管理する、前記第2のWebRTC PF利用者識別子を前記第1のユーザ端末に送信する送信手段と
、前記第1のユーザ端末による通信状態を示すネットワーク情報を前記第1のWebRTC PF利用者識別子
および前記第1のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報とともにと関連付けて管理し、また、前記第2のユーザ端末による通信状態を示すネットワーク情報を前記第2のWebRTC PF利用者識別子
および前記第2のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報と関連付けて管理するネットワーク情報管理手段
とを具備し、前記第1のユーザ端末は、前記通信相手として適切な前記ネットワーク情報の条件とともに、通信相手設定の要求を前記
送信手段に送信し、前記送信手段は、前記第1のユーザ端末からの前記通信相手設定の要求を受けて、前記条件を満たす前記第2のユーザ端末の前記ネットワーク情報について前記ネットワーク情報管理手段が管理し
、かつ、前記第1のWebRTC PF利用者識別子に関連付けられる前記事業者の識別情報が、前記第2のWebRTC PF利用者識別子に関連付けられる前記事業者の識別情報と同じである場合に、
前記ネットワーク情報と関連付けられる前記第2のWebRTC PF利用者識別子を前記第1のユーザ端末に送信するシステムを提供する。
【0012】
上記構成の通信システムの第2の態様は、第1の態様において、前記第2のユーザ端末は、前記第2のユーザ端末に対応するユーザの識別情報を前記識別子管理手段に送信し、前記識別子管理手段は、前記第2のユーザ端末から送信された識別情報を管理し、前記第1のユーザ端末は、前記通信相手の候補としての前記第2のユーザ端末に対応するユーザの識別情報とともに、通信相手設定の要求を前記識別子管理手段に送信し、前記送信手段は、前記第1のユーザ端末からの前記通信相手設定の要求を受けて、前記第1のユーザ端末から送信された前記第2のユーザ端末に対応するユーザの識別情報を前記識別子管理手段が管理している場合に、前記第2のWebRTC PF利用者識別子を前記第1のユーザ端末に送信する。
【0013】
上記構成の通信システムの第3の態様は、第1の態様において、前記第1のユーザ端末による通信状態を示すネットワーク情報を前記第1のWebRTC PF利用者識別子と関連付けて管理し、また、前記第2のユーザ端末による通信状態を示すネットワーク情報を前記第2のWebRTC PF利用者識別子と関連付けて管理するネットワーク情報管理手段をさらに備え、前記第1のユーザ端末は、前記通信相手として適切な前記ネットワーク情報の条件とともに、通信相手設定の要求を前記識別子管理手段に送信し、前記送信手段は、前記第1のユーザ端末からの前記通信相手設定の要求を受けて、前記条件を満たす前記第2のユーザ端末の前記ネットワーク情報について前記ネットワーク情報管理手段が管理している場合に、このネットワーク情報と関連付けられる前記第2のWebRTC PF利用者識別子を前記第1のユーザ端末に送信する。
【0014】
本発明の実施形態における通信方法の態様は、通信ネットワークに接続された第1のユーザ端末と第2のユーザ端末との間で通信するシステムに適用される方法であって、前記第1のユーザ端末からの、前記第1のユーザ端末に対応するユーザの識別情報
、および前記第1のユーザ端末が契約する事業者であって、ネットワークアドレス変換(NAT)またはファイアウォール(FW)設備を越えて前記通信ネットワークに接続された前記第1および第2のユーザ端末を接続する機能を有するWebRTC PF(Web Real-time Communications Platform)を使用する事業者の識別情報を含む要求である、
前記第1のユーザ端末が前記WebRTC
PFを使用するための
第1のWebRTC PF利用者識別子の発行要求に従って、前記第1のWebRTC PF利用者識別子を前記第1のユーザ端末に発行し、前記第2のユーザ端末からの、前記第2のユーザ端末に対応するユーザの識別情報
、および前記第2のユーザ端末が契約する事業者であって前記WebRTC PFを使用する事業者の識別情報を含む要求である、前記
第2のユーザ端末が前記WebRTC PFを使用するための第2のWebRTC PF利用者識別子の発行要求に従って、前記第2のWebRTC PF利用者識別子を前記第2のユーザ端末に発行し、前記発行した前記第
1のWebRTC PF利用者識別子を
前記第1のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報とともに管理
し、前記識別子発行手段により発行した前記第2のWebRTC PF利用者識別子を前記第2のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報とともに管理し、前記第1のユーザ端末からの、通信相手としてのユーザ端末の設定要求にしたがい、前記通信相手として前記第2のユーザ端末が設定された場合に、前記管理する、前記第2のWebRTC PF利用者識別子を前記第1のユーザ端末に送信
し、前記第1のユーザ端末による通信状態を示すネットワーク情報を前記第1のWebRTC PF利用者識別子
および前記第1のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報とともにと関連付けて管理し、また、前記第2のユーザ端末による通信状態を示すネットワーク情報を前記第2のWebRTC PF利用者識別子
および前記第2のユーザ端末からの前記発行要求に含まれる前記事業者の識別情報と関連付けて管理するネットワーク情報管理手段
とを備え、前記第1のユーザ端末は、前記通信相手として適切な前記ネットワーク情報の条件とともに、通信相手設定の要求を送信し、前記第1のユーザ端末からの前記通信相手設定の要求を受けて、前記条件を満たす前記第2のユーザ端末の前記ネットワーク情報について前記ネットワーク情報管理手段が管理し
、かつ、前記第1のWebRTC PF利用者識別子に関連付けられる前記事業者の識別情報が、前記第2のWebRTC PF利用者識別子に関連付けられる前記事業者の識別情報と同じである場合に、
前記ネットワーク情報と関連付けられる前記第2のWebRTC PF利用者識別子を前記第1のユーザ端末に送信する。
【0015】
本発明の実施形態における通信処理プログラムの態様は、通信システムの一部分として動作するコンピュータに用いられるプログラムであって、前記コンピュータを、前記識別子発行手段、前記識別子管理手段、および前記送信手段として機能させるための通信処理プログラムを提供する。
【発明の効果】
【0016】
本発明によれば、サーバ負荷やアプリケーション開発にかかる負荷を低減してユーザ端末同士の通信を行なうことが可能になる。
【発明を実施するための形態】
【0018】
以下、図面を参照して、この発明に係わる実施形態を説明する。
(第1の実施形態)
まず、第1の実施形態について説明する。
【0019】
図1は、本発明の第1の実施形態におけるゲームシステムの構成例を示す図である。
本発明の第1の実施形態では、ブラウザ上でリアルタイム通信を実現するフレームワークであるWebRTC(Web Real-time Communications)という技術を利用し、対戦ユーザ同士に対応するユーザ端末同士の通信を確立するまでの制御信号(C-plane)をWebRTC PF(Platform)部経由でやり取りし、実際のゲームデータ(U-plane)をP2P通信によりユーザ端末同士で交換することで、従来のクライアント・サーバ(C/S)型の通信システムで生じていたサーバ負荷の課題を解決する。
また、WebRTCはICE技術を利用することが定められており、ブラウザやブラウザコンポーネントにICE機能が標準的に実装されることにより、従来のP2P型の通信システムのように煩雑なアプリケーションを実装することなく、ブラウザを利用するだけでP2P通信を実現できる。
【0020】
図1は、本発明の第1の実施形態における通信システムの構成例を示す図である。
図1に示すように、本発明の第1の実施形態におけるゲームシステム12は、WebRTC PF部13、ユーザ情報管理部14、サービス提供部15、ネットワーク情報管理部30を有し、例えばインターネットやキャリア網のような通信ネットワーク10を介してユーザ端末11(#1)、・・・、11(#n)同士で通信が可能である。
【0021】
ユーザ情報管理部14はユーザ認証機能24とユーザ情報DB25を有し、登録ユーザと未登録の匿名ユーザの両方に対応する。ユーザ認証機能24は、ユーザ情報DB25に予め登録されたユーザの情報に基づき、ユーザの認証を行ない、登録ユーザであると判定した場合、認証キーの発行を行う。
一方で、ユーザ認証機能24は、ユーザ情報DB25に予め登録されたユーザの情報に基づき、未登録の匿名ユーザであると判定した場合、一時的なユーザ識別子を払い出す。例えばユーザ情報管理部14は、未登録の匿名ユーザに一時的なユーザ識別子を割り当てる。なお、この際、ユーザがブラウザを閉じる等でP2P等の通信ネットワーク10から離脱し、ユーザ端末11と通信ネットワーク10との接続が解除された場合、未登録の匿名ユーザに付与した一時的なユーザ識別子はリセットされる。
サービス提供部15は、ゲームファイルや(World-Wide Web)Webページ等をホストするWebサーバ機能26を有する。
【0022】
上記のWebRTC PF部13は、ICE機能17、シグナリング機能18、WebRTC PF利用者DB19、サービス認証機能20、ID管理機能22を有する。
ICE機能17は、STUNとTURNを組み合わせ、NAT/FWを通過する機能を有する。
【0023】
シグナリング機能18は、通信ネットワーク10に接続されているユーザ端末11に、WebRTC PFを利用するためのWebRTC PF利用者識別子を払い出し、また、ユーザ端末11同士をP2P接続するためのユーザ端末の情報(IPアドレス、ポート番号、コーデック情報等)を交換する。
WebRTC PF利用者DB19は、WebRTC PF利用者識別子を格納する。
【0024】
サービス認証機能20は、WebRTC PFを使用できるサービス事業者(例:ゲーム事業者)の認証を実施する。
サービス事業者DB21は、WebRTC PFを使用できるサービス事業者の情報を格納する。
【0025】
ID管理機能22は、サービス事業者が管理しているIDとWebRTC PFを使用するためのIDとをマッピングする。
ID管理DB23は、サービス事業者が管理しているIDとWebRTC
PFを使用するためのIDのリストを管理する。
【0026】
このようなWebRTC PF部13によって、ユーザAのユーザ端末11(例えば、ユーザ端末11(#n))とユーザBのユーザ端末11(例えば、ユーザ端末11(#1))と間でP2P通信を可能とする。
【0027】
ネットワーク情報管理部30は、ネットワーク情報管理機能31とネットワーク情報管理DB32とを有する。
ネットワーク情報管理機能31は、各ユーザ端末11のネットワーク情報(遅延、揺らぎ、スループット、回線情報等)を管理する。ネットワーク情報管理DB32は、各ユーザ端末11のネットワーク情報を格納する。
図2は、本発明の第1の実施形態におけるゲームシステムのネットワーク情報管理DBに格納されるネットワーク情報の一例を表形式で示す図である。
図2に示すように、ネットワーク情報管理DB32の構造は、例えば、サービス事業者識別子a、WebRTC PF利用者識別子b、回線タイプc、下り通信速度d、下り通信速度e、遅延(遅延時間)f、パケット損失率g、ジッタhのフィールドを有し、各行のフィールドが各ユーザに対応する各ユーザ端末11にかかるネットワーク情報を示す。
【0028】
サービス事業者識別子aは、各ユーザ端末11が契約しているサービス事業者の識別子を示している。
WebRTC PF利用者識別子bは、WebRTC PFを利用する際にピアを一意に識別するためのIDであり、各ユーザ端末11に対して1つのWebRTC PF利用者識別子が関連づけられている。WebRTC PF利用者識別子は、ネットワーク情報管理DB32の中でユニークである必要がある。
【0029】
これらのサーバ/データベース/アプリケーションは独立したエンティティとして記載を行ったが、いずれの組み合わせにおいても同一エンティティとしての実装を制限するものではない。また、
図1において、図示はしていないが多数のユーザ端末11がある。
【0030】
また、この通信ネットワーク10は、イーサネット(登録商標)等のLAN、あるいは公衆回線や専用回線を介して複数のLANが接続されるWAN等からなる。LANの場合には、必要に応じてルータを介した多数のサブネットから構成される。また、WANの場合には、公衆回線に接続するためのファイアウォール等を適宜備えているが、ここではその図示及び詳細説明を省略する。
【0031】
また、本実施形態のゲームシステム12は、例えば、磁気ディスク等の記録媒体に記録されたプログラムや、インターネット等の通信ネットワーク10を介してダウンロードしたプログラムを読み込み、このプログラムによって動作が制御されるサーバ等のコンピュータによって実現される。
【0032】
図3Aおよび
図3Bは、本発明の第1の実施形態におけるゲームシステムの処理シーケンスの一例を示す図である。
この処理シーケンスは、シーケンスA、B、C、D、Eに大別される。
シーケンスAはユーザAのWebRTC PF利用準備のためのシーケンスである。
ユーザ端末Aおよびユーザ端末Bは、ユーザ端末11(#1)乃至11(#n)の何れかのユーザ端末である。また、以下、単にユーザ端末と記載した場合、そのユーザ端末は、ユーザ端末11(#1)乃至11(#n)の何れかのユーザ端末である。
【0033】
次に、シーケンスAの詳細について説明する。
ユーザ端末Aは、URLを指定するための入力を受け付ける等して、ゲーム事業者が提供しているWebページをサービス提供部15のWebサーバ機能26に要求する(ステップA−1)。
ユーザ端末Aは、ゲーム事業者が提供しているWebページをWebサーバ機能26からダウンロードする(ステップA−2)。
【0034】
ユーザ端末Aは、ログインID、パスワード等の、ユーザ端末A(例:UserName001)を認証するためのユーザ情報をWebサーバ機能26に送信する(ステップA−3)。なお、ユーザ端末Aが匿名ユーザの場合、このA−3の処理は実施する必要はない。
【0035】
ユーザ情報管理部14のユーザ認証機能24は、ユーザ端末A(例:UserName001)に対応するユーザAによってユーザ端末Aを介してWebサーバ機能26へ送信されたユーザ情報と、ユーザ情報DB25に予め登録されているユーザ端末A(例:UserName001)の認証情報を照合しユーザ端末A(例:UserName001)に対してユーザ認証を行い、ユーザ認証に成功した場合、ユーザ端末Aに対して認証キーの発行を行う(ステップA−4)。なお、ユーザ認証機能24は、ユーザ端末Aが匿名ユーザの場合、ステップA−4の処理を実施する必要はない。
【0036】
Webサーバ機能26は、接続Tokenを生成する(ステップA−5)。ここで、接続TokenはユーザIDと部屋IDとの組み合わせであると仮定するが、この限りではない。また、ユーザ端末Aが匿名ユーザの場合、ステップA−3、A−4の処理を実施する必要はなく、Webサーバ機能26は、ユーザ端末Aを一意に識別できる一時的なIDに基づいて接続Tokenを生成する。
【0037】
Webサーバ機能26は、ユーザ認証機能24によって発行されたユーザ端末Aの認証キーと、サービス事業者を示すサービス事業者識別子(事業者の事業者識別ID等)とをユーザ端末A(例:UserName001)に通知する(ステップA−6)。ここで、認証が成功した場合、Webサーバ機能26は、ユーザ認証機能24で発行された認証キーとゲームファイル、ユーザ端末Aの接続Token、対戦相手情報(対戦相手のユーザID一覧など)をユーザ端末Aに通知する。
【0038】
ユーザ端末Aは、サービス事業者がユーザ端末A(例:UserName001)を一意に識別するためのユーザID、サービス事業者識別子、WebRTC PFを利用するためのAPI key等の情報をシグナリング機能18に送信し、WebRTC PF利用者識別子の発行を要求する(ステップA−7)。なお、ここでは、API keyはユーザ端末Aによって事前に申請され発行されている場合を想定している。
【0039】
すると、サービス認証機能20は、ステップA−7でユーザ端末A(例:UserName001)からシグナリング機能18に送信された情報と、WebRTC利用者DB19に予め登録されている情報を照会し、ユーザ認証を行い、ユーザ認証に成功した場合、ユーザ端末Aに対して、ユーザ認証キーの発行を行う(ユーザ認証)(ステップA−8)。
【0040】
シグナリング機能18は、サービス認証機能20で発行されたユーザ認証キーと、WebRTC PFを利用する際にピアを一意に識別するためのID(以下、WebRTC PF利用者識別子と称す。)(例:PeerID001)と、をユーザ端末A(例:UserName001)に対して発行し、発行したユーザ認証キーとWebRTC PF 利用者識別子をユーザ端末Aに送信する(ステップA−9)。
【0041】
ユーザ端末Aは、Webサーバ機能26から通知されたサービス事業者識別子とシグナリング機能18から送信されたWebRTC PF利用者識別子とをネットワーク情報管理機能31に送信する(ステップA−10)。これにより、ネットワーク情報管理機能31はユーザ端末Aを一意に識別することができ、ネットワーク情報管理DB32にユーザ毎に対応するユーザ端末毎のネットワーク情報を収集することができる。
【0042】
ネットワーク情報管理機能31は、ネットワーク情報を収集して、ステップA−10でユーザ端末Aから通知された、ユーザ端末Aに対応するサービス事業者識別子とユーザ端末Aに対応するWebRTC PF利用者識別子と関連付けてネットワーク情報管理DB32に書き込んで管理する(ステップA−11)。この時、ユーザ端末Aからネットワーク情報管理機能31に定期的にポーリング等してネットワーク情報を収集する方法もあれば、ICE機能17へ定期的に送信されるSTUNバインディングリクエストからネットワークを収集する方法や、別のシステムで取得したネットワーク情報を流用する方法が考えられるが、ここではその方法を限定しない。
【0043】
ネットワーク情報管理機能31は、サービス事業者識別子、WebRTC PF利用者識別子をユーザ端末Aから受けとると、ネットワークAのネットワーク情報を収集開始したことをユーザ端末Aに通知する(ステップA−12)。
【0044】
ユーザ端末Aは、ステップA−6で通知されたサービス事業者識別子、ステップA−6で通知されたユーザ端末Aの接続Token、ステップA−9で通知されたWebRTC PF利用者識別子(例:PeerID001)をID管理機能22に送信する(ステップA−13)。これにより、ユーザAが対戦ユーザ(例えばユーザB)を指定した時に、Webサーバ機能26に再度問い合わせることなく、WebRTC PF部13のみでユーザBとの通信を確立することが可能となる。
【0045】
ID管理機能22は、ステップA−13で送信されたWebRTC PF利用者識別子(例:PeerID001)およびサービス事業者識別子をID管理DB23に書き込んで管理し、また、ユーザ端末Aからサービス事業者識別子、ユーザAの接続Token、WebRTC PF利用者識別子を受けとったことをユーザ端末Aに通知する(ステップA−14)。
【0046】
シーケンスBはユーザBのWebRTC PF利用準備のためのシーケンスである。このシーケンスBは、ユーザ端末Aの代わりにユーザ端末Bを使用し、A−1からA−14と同様の処理を行うので説明を省略する。
【0047】
次にシーケンスC、Dについて説明する。これらのシーケンスC、Dは、ユーザAによる対戦ユーザの選択方法である。
ここで、シーケンスCはユーザが対戦相手を直接指定して対戦ユーザを選択するためのシーケンスであり、シーケンスDは、ネットワーク情報管理機能31を用いて、ネットワークの混雑状況(通信速度、遅延、スループット、ジッタ等)に基づいて対戦相手を選出するためのシーケンスである。ここで、シーケンスC、Dのどちらを実行するかはユーザが選択することができる。
【0048】
シーケンスCにおいて、ユーザ端末Aは、ユーザAによる、対戦相手(ユーザAが対戦相手の候補としたユーザ)のID(例えばユーザBのID:UserName002)情報の入力操作を受け付けて、このIDを含む通信相手設定要求をID管理機能22に送信する(ステップC−1)。
【0049】
ID管理機能22は、通信相手設定要求を受けて、ID管理DB23にアクセスし、ステップC−1で送信された対戦相手のIDに基づいて、対戦相手のWebRTC PF利用者識別子を検索する(ステップC−2)。
【0050】
ID管理機能22は、対戦相手のIDがID管理DB23に存在し、かつ、このIDに対応するユーザが他のユーザと対戦中でなければ、この対戦相手のWebRTC PF利用者識別子をユーザ端末Aに通知する(ステップC−3)。この時、ID管理機能22は、ステップC−1で送信されたIDに対応する対戦相手が存在しない、あるいは、この対戦相手が他のユーザと対戦中である場合、そのステータスをユーザ端末Aに通知する。
【0051】
次に、シーケンスDにおいて、シーケンスCのように対戦相手のIDを指定するのではなく、ユーザ端末Aは、ユーザAのWebRTC PF利用者識別子、および、対戦相手に要求するネットワーク情報(例えば遅延が8ms以上、10ms以下など)の入力を受け付けて、これらをID管理機能22に送信することで、対戦相手のマッチングを要求する(ステップD−1)。
【0052】
ID管理機能22は、ID管理DB23にアクセスし、ユーザAのWebRTC PF利用者識別子に基づいて、ユーザAのサービス事業者識別子を検索し、このユーザAのサービス事業者識別子と、ユーザAが対戦相手に要求するネットワーク情報(例えば遅延が8ms以上、10ms以下など)とをマッチング要求としてネットワーク情報管理機能31に送信する(ステップD−2)。
【0053】
ネットワーク情報管理機能31は、マッチング要求を受けると、ID管理機能22から受け取ったサービス事業者識別子と同じサービス事業者識別子に該当し、且つ、ユーザAが対戦相手に要求するネットワーク情報(例えば遅延が8ms以上、10ms以下など)を満たすユーザのWebRTC PF利用者識別子をネットワーク情報管理DB32から抽出する(ステップD−3)。
【0054】
図2に示したネットワーク情報を例にとると、一番上の行のフィールドがユーザAに対応する仮定した時に、ユーザAのサービス事業者識別子は「Provider001」で、WebRTC PF利用者識別子は「PeerID001」であることから、同じサービス事業者識別子であるユーザのWebRTC PF利用者識別子「PeerID002」、「PeerID004」、「PeerID005」のうち、遅延時間が8ms以上で10ms以下であるユーザのWebRTC PF利用者識別子は「PeerID005」であることから、この「PeerID005」が抽出
される。
【0055】
ネットワーク情報管理機能31は、ステップD−3で抽出したユーザのWebRTC PF利用者識別子(例えばPeerID005)をID管理機能22に通知する(ステップD−4)。この時、ネットワーク情報管理機能31は、該当ユーザが複数居る場合、つまりWebRTC PF利用者識別子が複数ある場合は、これら複数ユーザのWebRTC PF利用者識別子をID管理機能22
に通知し、該当ユーザが居ない場合は、該当ユーザが居ないことをID管理機能22
に通知する。
【0056】
ID管理機能22は、ステップD−4より取得した1つ、もしくは複数のWebRTC PF利用者識別子の中からユーザA自身や現在対戦中のユーザに対応するWebRTC PF利用者識別子を除いた、ゲームに必要な数のWebRTC PF利用者識別子をID管理DB23から抽出する(ステップD−5)。
ID管理機能22は、この抽出したWebRTC PF利用者識別子をユーザ端末Aに通知する(ステップD−6)。
【0057】
次に、シーケンスEについて説明する。
まず、ユーザ端末Aの画面が対戦待ち画面に遷移すると(ステップE−1)、通信路を設定するためにステップE−2乃至E−5を実行する。具体的には、ユーザ端末Aは、ステップC−3またはD−6で通知されたユーザBのWebRTC PF利用者識別子を基に、通信路を設定するためのオファーをシグナリング機能18を介してユーザ端末Bに対して行う(ステップE−2、E−3)。ユーザ端末Bは、通信路を設定するためのアンサーをシグナリング機能18を介してユーザ端末Aに対して行う(ステップE−4、E−5)。
ユーザ端末Aは、この設定された通信路による接続性をユーザ端末Bとの間で確認する(ステップE−6、E−7)。
【0058】
次に、接続確立まで、ステップE−8乃至E−17を実行する。具体的には、ユーザ端末Aは、ICE候補の収集をICE機能17に要求し、ICE機能17はICE候補を収集して、ユーザ端末Aに返す(ステップE−8、E−9)。
【0059】
次に、収集したICE候補を用いて通信路を設定するためにステップE−10乃至E−15を実行する。具体的には、ユーザ端末Aは、ステップE−9で返されたICE候補を用いて通信路を設定するためのオファーをシグナリング機能18を介してユーザ端末Bに対して行う(ステップE−10、E−11)。
ユーザ端末Bは、ICE候補の収集をICE機能17に要求し、ICE機能17はICE候補を収集して、ユーザ端末Bに返す(ステップE−12、E−13)。ユーザ端末Bは、収集したICE候補を用いて通信路を設定するためのアンサーをシグナリング機能18を介してユーザ端末Aに対して行う(ステップE−14、E−15)。
【0060】
ユーザ端末Aは、この設定された通信路による接続性をユーザ端末Bとの間で確認する(ステップE−16、E−17)。
【0061】
これらステップE−2〜E−17は、WebRTCで使われているTricleICEの標準規定通りであり、例えば「draft-ietf-mmusic-trickle-ice-02」
(http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02)に開示されている。
【0062】
ユーザ端末Bは、ユーザBに対戦許可を取り、このユーザBが対戦許可を選択するための操作を行なった場合、ユーザ端末Bの画面がゲーム画面(対戦画面)へと遷移する(ステップE−18)。
【0063】
ユーザ端末Bは、ユーザ端末Aに対戦許可を通知する(ステップE−19)。
ユーザBが対戦許可したため、ユーザ端末Aの画面がゲーム画面(対戦画面)へと遷移する(ステップE−20)。
そして、ユーザ端末Aとユーザ端末Bとの間でP2P通信により、ゲームデータを交換する(ステップE−21)。
【0064】
以上のように、本発明の第1の実施形態では、WebRTC(Web Real-time Communications)という技術を利用し、対戦ユーザ同士に対応するユーザ端末同士の通信を確立するまでの制御信号(C-plane)をWebRTC PF部経由でやり取りし、実際のゲームデータ(U-plane)をP2P通信によりユーザ端末同士で交換する。よって、ゲーム事業者は、ユーザ同士を対戦させるゲームであっても、サーバを用意してゲームデータをリレーさせたり、P2P通信を伴うアプリケーションを開発したりする必要がない。したがって、ゲームデータのリレーによって生じるサーバ負荷や、アプリケーション開発コストを低減させることができる。また、本発明の第1の実施形態におけるゲームシステムを用いることで、対戦ユーザのマッチングを最適化することができ、多様な対戦ユーザの選択方法をユーザに提供することができる。
【0065】
また、ユーザは、サービスを利用するために、プラグインやアプリケーションのインストールが不要であり、即時にサービスを利用できる。また、上記のようにアプリをインストールが不要であるので、ユーザは、アプリのアップデートに伴う作業等を行う必要がなく、アプリのパージョンが異なることによる不具合を気にしなくて良い。
【0066】
(第2の実施形態)
次に、第2の実施形態について説明する。なお、この実施形態における構成のうち第1の実施形態で説明した部分と同一部分の詳細な説明は省略する。
図4は、本発明の第2の実施形態におけるゲームシステムの構成例を示す図である。
【0067】
図4に示すように、第2の実施形態におけるゲームシステムは、WebRTC PF部13、ユーザ情報管理部14、サービス提供部15を有し、例えばインターネットやキャリア網のような通信ネットワーク10を介してユーザ端末11(#1)、・・・、11(#n)同士で通信が可能である。また、この第2の実施形態におけるゲームシステムは、第1の実施形態で説明したネットワーク情報管理部30は有しない。
【0068】
図5Aおよび
図5Bは、本発明の第2の実施形態におけるゲームシステムの処理シーケンスの一例を示す図である。
この処理シーケンスは、シーケンスA、B、C、Eに大別される。
シーケンスAはユーザAのWebRTC PF利用準備のためのシーケンスである。
次に、シーケンスAの詳細について説明する。
ユーザ端末Aは、URLを指定するための入力を受け付ける等して、ゲーム事業者が提供しているWebページをサービス提供部15のWebサーバ機能26に要求する(ステップA−1)。
【0069】
以降、第1の実施形態で説明したステップA−2〜ステップA−9が行われ、ユーザ認証が完了する。なお、第2の実施形態では、第1の実施形態で説明したステップA−9〜ステップA−12は行われない。
【0070】
次に、ユーザ端末Aは、ステップA−6で通知されたサービス事業者識別子、ステップA−6で通知されたユーザ端末Aの接続Token、ステップA−9で通知されたWebRTC PF利用者識別子(例:PeerID001)をID管理機能22に送信する(ステップA−13)。これにより、ユーザAが対戦ユーザ(例えばユーザB)を指定した時に、Webサーバ機能26に再度問い合わせることなく、WebRTC PF部13のみでユーザBとの通信を確立することが可能となる。
【0071】
ID管理機能22は、サービス事業者識別子、ユーザAの接続Token、WebRTC PF利用者識別子を受けとったことをユーザ端末Aに通知する(ステップA−14)。
【0072】
シーケンスBはユーザBのWebRTC PF利用準備のためのシーケンスである。このシーケンスBは、ユーザ端末Aの代わりにユーザ端末Bを使用し、ステップA−1からA−14と同じ処理を行うので省略する。
【0073】
次にシーケンスCについて説明する。このシーケンスCは、第1の実施形態でも説明したように、ユーザAによる対戦ユーザの選択するためのであり、ステップC−1からC−3が行われて、対戦相手の選択が終了する。
次に、シーケンスEが行われる。このシーケンスEは、第1の実施形態と同じであるため、説明は省略する。
【0074】
以上のように、本発明の第2の実施形態では、第1の実施形態で説明したネットワーク情報管理部30を設けなくとも、WebRTC(Web Real-time Communications)という技術を利用し、対戦ユーザ同士に対応するユーザ端末同士の通信を確立するまでの制御信号(C-plane)をWebRTC PF部経由でやり取りし、実際のゲームデータ(U-plane)をP2P通信によりユーザ端末同士で交換することができる。
【0075】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【0076】
また、各実施形態に記載した手法は、計算機(コンピュータ)に実行させることができるプログラム(ソフトウエア手段)として、例えば磁気ディスク(フロッピー(登録商標)ディスク、ハードディスク等)、光ディスク(CD−ROM、DVD、MO等)、半導体メモリ(ROM、RAM、フラッシュメモリ等)等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段(実行プログラムのみならずテーブルやデータ構造も含む)を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。