JP2016152506A - 通信システム、通信方法およびプログラム - Google Patents

Abstract

【課題】サーバ負荷やアプリケーション開発にかかる負荷を低減してユーザ端末同士の通信を行なう。
【解決手段】実施形態における通信システムは、第１及び第２のユーザ端末からの、ネットワークアドレス変換又はファイアウォール設備を超えて通信ネットワークに接続された第１及び第２のユーザ端末を接続する機能を有するＷｅｂＲＴＣ（Web Real-time Communications）を使用するためのＷｅｂＲＴＣ ＰＦ（Platform）利用者識別子の発行要求に従って、各ユーザ端末に対応する上記識別子を発行する識別子発行手段と、この発行した識別子を管理する識別子管理手段と、第１のユーザ端末からの、通信相手としてのユーザ端末の設定要求に従い、通信相手として第２のユーザ端末が設定された場合に、第２のユーザ端末に対応する識別子を第１のユーザ端末に送信する送信手段とを有する。
【選択図】図１

Description

本発明の実施形態は、通信システム、通信方法およびプログラムに関する。

従来から、インターネット等のネットワークを介し、クライアント同士が通信対戦をするネットワーク対戦型ゲームが提案されている。
ネットワーク対戦型ゲームの通信形態は大きく２種類に分類することができ、図６のようなクライアントのデータをサーバで処理・中継するクライアント・サーバ（C/S）型のもの（従来技術Ａ）と、図７のようなクライアント同士で直接通信するＰ２Ｐ型のもの（従来技術Ｂ）がある。

図６に示したシステムは、通信ネットワーク１０には、ユーザ端末１１（＃１）、・・・、１１（＃ｎ）のように複数のユーザ端末１１が接続されている。また、このシステムは、サービス提供部６１およびユーザ情報管理部６２を有する。
ユーザ情報管理部６２は、ユーザ情報ＤＢ（データベース）６９とユーザ認証機能７０を有する。ユーザ認証機能７０は、ユーザ情報ＤＢ６９に予め登録されたユーザの情報に基づき、ユーザの認証を行い、登録ユーザであるか否か判定する。サービス提供部６１は、コンテンツに関する情報を提供するＷｅｂページ等をホストするＷｅｂサーバ機能７１を有し、ユーザ端末１１（＃１）、・・・、１１（＃ｎ）からの配信要求に対して要求されるコンテンツを提供する。

また、図７に示したシステムは、図６に示したユーザ端末１１、サービス提供部６１およびユーザ情報管理部６２を有する他、各ユーザ端末１１には、Ｐ２Ｐ通信を行なうためのアプリケーション（アプリ）がインストールされている。このシステムは、ユーザ端末１１同士がサーバなどを利用して中継せずに直接通信する。

特許第４３６３６４８号公報

しかしながら、上記の従来技術Ａのように、C/S型の通信形態だと、クライアント（ユーザ端末）の数が増加すればするほどサーバに処理・中継負荷がかかり、サーバがボトルネックとなって遅延が生じる。あるいは、サーバダウンによってゲームを続行できないといった課題が生じる。

一方で、従来技術Ｂのように、Ｐ２Ｐ型の通信で互いのゲームデータをユーザ同士で交換しようとすると、Ｐ２Ｐ型の通信を実現するアプリケーションの開発が煩雑という課題がある。これは、Ｐ２Ｐ通信を実現するためには、ＮＡＴ／ＦＷ（Network Address Translation/Firewall（ネットワークアドレス変換またはファイアウォール））越え問題を解決しなければならないからである。現在、通信機器が通信網に接続する際に、ルータと呼ばれる機器に接続する構成が一般的になっている。

このルータはＬＡＮ（Local Area Network）側の通信機器のIP（Internet Protocol）アドレスやポート番号を、ＷＡＮ（Wide Area Network）側のＩＰアドレスやポート番号に変更する機能を有し、さらに、ＬＡＮ側からＷＡＮ側への通信を検知して初めて、ＷＡＮ側からパケットを中継するＦＷ機能を有している。
そのため、異なるルータの配下にある通信端末同士が通信をしようとしても、パケットがルータで破棄されるため、お互い通信を開始できない。

この課題を解決するために、ＵＰｎＰ（Universal Plug and Play）やピアのグローバルＩＰアドレスとポート番号を知らせてＵＤＰホールパンチング技術によりＮＡＴ／ＦＷ通過を実現するＳＴＵＮ（Simple Traversal of UDP through NATs）、メディアやアプリの配信サーバを介さずにリレーサーバを配備するＴＵＲＮ（Traversal Utilities for NAT）、さらに、ＳＴＵＮとＴＵＲＮを組み合わせ、体系立ててＮＡＴ／ＦＷを通過するためのプロシージャ手順としてまとめたＩＣＥ（Interactive Connectivity Establishment）等の方法が知られている。しかし、いずれの仕組みを用いても、これらの仕組みを利用できるようにアプリケーションを開発しなければならず、その作業は非常に煩雑となる。

本発明が解決しようとする課題は、サーバ負荷やアプリケーション開発にかかる負荷を低減してユーザ端末同士の通信を行なうことを可能とする通信システム、方法及びプログラムを提供することである。

上記目的を達成するために、この発明の実施形態における通信システムの第１の態様は、通信ネットワークに接続された第１のユーザ端末と第２のユーザ端末との間で通信するシステムであって、前記第１および第２のユーザ端末からの、ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて前記通信ネットワークに接続された前記第１および第２のユーザ端末を接続する機能を有するＷｅｂＲＴＣ（Web Real-time Communications）を使用するためのＷｅｂＲＴＣ ＰＦ（Platform）利用者識別子の発行要求に従って、前記第１のユーザ端末に対応する第１のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に発行し、前記第２のユーザ端末に対応する第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第２のユーザ端末に発行する識別子発行手段と、前記識別子発行手段により発行した、前記第１および第２のＷｅｂＲＴＣ ＰＦ利用者識別子を管理する識別子管理手段と、前記第１のユーザ端末からの、通信相手としてのユーザ端末の設定要求にしたがい、前記通信相手として前記第２のユーザ端末が設定された場合に、前記識別子管理手段が管理する、前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する送信手段とを具備するシステムを提供する。

上記構成の通信システムの第２の態様は、第１の態様において、前記第２のユーザ端末は、前記第２のユーザ端末に対応するユーザの識別情報を前記識別子管理手段に送信し、前記識別子管理手段は、前記第２のユーザ端末から送信された識別情報を管理し、前記第１のユーザ端末は、前記通信相手の候補としての前記第２のユーザ端末に対応するユーザの識別情報とともに、通信相手設定の要求を前記識別子管理手段に送信し、前記送信手段は、前記第１のユーザ端末からの前記通信相手設定の要求を受けて、前記第１のユーザ端末から送信された前記第２のユーザ端末に対応するユーザの識別情報を前記識別子管理手段が管理している場合に、前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する。

上記構成の通信システムの第３の態様は、第１の態様において、前記第１のユーザ端末による通信状態を示すネットワーク情報を前記第１のＷｅｂＲＴＣ ＰＦ利用者識別子と関連付けて管理し、また、前記第２のユーザ端末による通信状態を示すネットワーク情報を前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子と関連付けて管理するネットワーク情報管理手段をさらに備え、前記第１のユーザ端末は、前記通信相手として適切な前記ネットワーク情報の条件とともに、通信相手設定の要求を前記識別子管理手段に送信し、前記送信手段は、前記第１のユーザ端末からの前記通信相手設定の要求を受けて、前記条件を満たす前記第２のユーザ端末の前記ネットワーク情報について前記ネットワーク情報管理手段が管理している場合に、このネットワーク情報と関連付けられる前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する。

本発明の実施形態における通信方法の態様は、通信ネットワークに接続された第１のユーザ端末と第２のユーザ端末との間で通信するシステムに適用される方法であって、前記第１および第２のユーザ端末からの、ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて前記通信ネットワークに接続された前記第１および第２のユーザ端末を接続する機能を有するＷｅｂＲＴＣ（Web Real-time Communications）を使用するためのＷｅｂＲＴＣ ＰＦ（Platform）利用者識別子の発行要求に従って、前記第１のユーザ端末に対応する第１のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に発行し、前記第２のユーザ端末に対応する第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第２のユーザ端末に発行し、前記発行した、前記第１および第２のＷｅｂＲＴＣ ＰＦ利用者識別子を管理し、前記第１のユーザ端末からの、通信相手としてのユーザ端末の設定要求にしたがい、前記通信相手として前記第２のユーザ端末が設定された場合に、前記管理する、前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する。

本発明の実施形態における通信処理プログラムの態様は、通信システムの一部分として動作するコンピュータに用いられるプログラムであって、前記コンピュータを、前記識別子発行手段、前記識別子管理手段、および前記送信手段として機能させるための通信処理プログラムを提供する。

本発明によれば、サーバ負荷やアプリケーション開発にかかる負荷を低減してユーザ端末同士の通信を行なうことが可能になる。

本発明の第１の実施形態におけるゲームシステムの構成例を示す図。 本発明の第１の実施形態におけるゲームシステムのネットワーク情報管理ＤＢに格納されるネットワーク情報の一例を表形式で示す図。 本発明の第１の実施形態におけるゲームシステムの処理シーケンスの一例を示す図。 本発明の第１の実施形態におけるゲームシステムの処理シーケンスの一例を示す図。 本発明の第２の実施形態におけるゲームシステムの構成例を示す図。 本発明の第２の実施形態におけるゲームシステムの処理シーケンスの一例を示す図。 本発明の第２の実施形態におけるゲームシステムの処理シーケンスの一例を示す図。 従来のクライアント・サーバ（C/S）型の通信システムの一例を示す図。 従来のＰ２Ｐ型の通信システムの一例を示す図。

以下、図面を参照して、この発明に係わる実施形態を説明する。
（第１の実施形態）
まず、第１の実施形態について説明する。

図１は、本発明の第１の実施形態におけるゲームシステムの構成例を示す図である。
本発明の第１の実施形態では、ブラウザ上でリアルタイム通信を実現するフレームワークであるＷｅｂＲＴＣ（Web Real-time Communications）という技術を利用し、対戦ユーザ同士に対応するユーザ端末同士の通信を確立するまでの制御信号（C-plane）をＷｅｂＲＴＣ ＰＦ（Platform）部経由でやり取りし、実際のゲームデータ（U-plane）をＰ２Ｐ通信によりユーザ端末同士で交換することで、従来のクライアント・サーバ（C/S）型の通信システムで生じていたサーバ負荷の課題を解決する。
また、ＷｅｂＲＴＣはＩＣＥ技術を利用することが定められており、ブラウザやブラウザコンポーネントにＩＣＥ機能が標準的に実装されることにより、従来のＰ２Ｐ型の通信システムのように煩雑なアプリケーションを実装することなく、ブラウザを利用するだけでＰ２Ｐ通信を実現できる。

図１は、本発明の第１の実施形態における通信システムの構成例を示す図である。
図１に示すように、本発明の第１の実施形態におけるゲームシステム１２は、ＷｅｂＲＴＣ ＰＦ部１３、ユーザ情報管理部１４、サービス提供部１５、ネットワーク情報管理部３０を有し、例えばインターネットやキャリア網のような通信ネットワーク１０を介してユーザ端末１１（＃１）、・・・、１１（＃ｎ）同士で通信が可能である。

ユーザ情報管理部１４はユーザ認証機能２４とユーザ情報ＤＢ２５を有し、登録ユーザと未登録の匿名ユーザの両方に対応する。ユーザ認証機能２４は、ユーザ情報ＤＢ２５に予め登録されたユーザの情報に基づき、ユーザの認証を行ない、登録ユーザであると判定した場合、認証キーの発行を行う。
一方で、ユーザ認証機能２４は、ユーザ情報ＤＢ２５に予め登録されたユーザの情報に基づき、未登録の匿名ユーザであると判定した場合、一時的なユーザ識別子を払い出す。例えばユーザ情報管理部１４は、未登録の匿名ユーザに一時的なユーザ識別子を割り当てる。なお、この際、ユーザがブラウザを閉じる等でＰ２Ｐ等の通信ネットワーク１０から離脱し、ユーザ端末１１と通信ネットワーク１０との接続が解除された場合、未登録の匿名ユーザに付与した一時的なユーザ識別子はリセットされる。
サービス提供部１５は、ゲームファイルや（World-Wide Web）Ｗｅｂページ等をホストするＷｅｂサーバ機能２６を有する。

上記のＷｅｂＲＴＣ ＰＦ部１３は、ＩＣＥ機能１７、シグナリング機能１８、ＷｅｂＲＴＣ ＰＦ利用者ＤＢ１９、サービス認証機能２０、ＩＤ管理機能２２を有する。
ＩＣＥ機能１７は、ＳＴＵＮとＴＵＲＮを組み合わせ、ＮＡＴ／ＦＷを通過する機能を有する。

シグナリング機能１８は、通信ネットワーク１０に接続されているユーザ端末１１に、ＷｅｂＲＴＣ ＰＦを利用するためのＷｅｂＲＴＣ ＰＦ利用者識別子を払い出し、また、ユーザ端末１１同士をＰ２Ｐ接続するためのユーザ端末の情報（ＩＰアドレス、ポート番号、コーデック情報等）を交換する。
ＷｅｂＲＴＣ ＰＦ利用者ＤＢ１９は、ＷｅｂＲＴＣ ＰＦ利用者識別子を格納する。

サービス認証機能２０は、ＷｅｂＲＴＣ ＰＦを使用できるサービス事業者（例：ゲーム事業者）の認証を実施する。
サービス事業者ＤＢ２１は、ＷｅｂＲＴＣ ＰＦを使用できるサービス事業者の情報を格納する。

ＩＤ管理機能２２は、サービス事業者が管理しているＩＤとＷｅｂＲＴＣ ＰＦを使用するためのＩＤとをマッピングする。
ＩＤ管理ＤＢ２３は、サービス事業者が管理しているＩＤとＷｅｂＲＴＣを使用するためのＩＤのリストを管理する。

このようなＷｅｂＲＴＣ ＰＦ部１３によって、ユーザＡのユーザ端末１１（例えば、ユーザ端末１１（＃ｎ））とユーザＢのユーザ端末１１（例えば、ユーザ端末１１（＃１））と間でＰ２Ｐ通信を可能とする。

ネットワーク情報管理部３０は、ネットワーク情報管理機能３１とネットワーク情報管理ＤＢ３２とを有する。
ネットワーク情報管理機能３１は、各ユーザ端末１１のネットワーク情報（遅延、揺らぎ、スループット、回線情報等）を管理する。ネットワーク情報管理ＤＢ３２は、各ユーザ端末１１のネットワーク情報を格納する。
図２は、本発明の第１の実施形態におけるゲームシステムのネットワーク情報管理ＤＢに格納されるネットワーク情報の一例を表形式で示す図である。
図２に示すように、ネットワーク情報管理ＤＢ３２の構造は、例えば、サービス事業者識別子ａ、ＷｅｂＲＴＣ ＰＦ利用者識別子ｂ、回線タイプｃ、下り通信速度ｄ、下り通信速度ｅ、遅延（遅延時間）ｆ、パケット損失率ｇ、ジッタｈのフィールドを有し、各行のフィールドが各ユーザに対応する各ユーザ端末１１にかかるネットワーク情報を示す。

サービス事業者識別子ａは、各ユーザ端末１１が契約しているサービス事業者の識別子を示している。
ＷｅｂＲＴＣ ＰＦ利用者識別子ｂは、ＷｅｂＲＴＣ ＰＦを利用する際にピアを一意に識別するためのＩＤであり、各ユーザ端末１１に対して１つのＷｅｂＲＴＣ ＰＦ利用者識別子が関連づけられている。ＷｅｂＲＴＣ ＰＦ利用者識別子は、ネットワーク情報管理ＤＢ３２の中でユニークである必要がある。

これらのサーバ/データベース/アプリケーションは独立したエンティティとして記載を行ったが、いずれの組み合わせにおいても同一エンティティとしての実装を制限するものではない。また、図１において、図示はしていないが多数のユーザ端末１１がある。

また、この通信ネットワーク１０は、イーサネット(登録商標)等のＬＡＮ、あるいは公衆回線や専用回線を介して複数のＬＡＮが接続されるＷＡＮ等からなる。ＬＡＮの場合には、必要に応じてルータを介した多数のサブネットから構成される。また、ＷＡＮの場合には、公衆回線に接続するためのファイアウォール等を適宜備えているが、ここではその図示及び詳細説明を省略する。

また、本実施形態のゲームシステム１２は、例えば、磁気ディスク等の記録媒体に記録されたプログラムや、インターネット等の通信ネットワーク１０を介してダウンロードしたプログラムを読み込み、このプログラムによって動作が制御されるサーバ等のコンピュータによって実現される。

図３Ａおよび図３Ｂは、本発明の第１の実施形態におけるゲームシステムの処理シーケンスの一例を示す図である。
この処理シーケンスは、シーケンスＡ、Ｂ、Ｃ、Ｄ、Ｅに大別される。
シーケンスＡはユーザＡのＷｅｂＲＴＣ ＰＦ利用準備のためのシーケンスである。
ユーザ端末Ａおよびユーザ端末Ｂは、ユーザ端末１１（＃１）乃至１１（＃ｎ）の何れかのユーザ端末である。また、以下、単にユーザ端末と記載した場合、そのユーザ端末は、ユーザ端末１１（＃１）乃至１１（＃ｎ）の何れかのユーザ端末である。

次に、シーケンスＡの詳細について説明する。
ユーザ端末Ａは、URLを指定するための入力を受け付ける等して、ゲーム事業者が提供しているＷｅｂページをサービス提供部１５のＷｅｂサーバ機能２６に要求する（ステップＡ−１）。
ユーザ端末Ａは、ゲーム事業者が提供しているＷｅｂページをＷｅｂサーバ機能２６からダウンロードする（ステップＡ−２）。

ユーザ端末Ａは、ログインＩＤ、パスワード等の、ユーザ端末Ａ（例：UserName001）を認証するためのユーザ情報をＷｅｂサーバ機能２６に送信する（ステップＡ−３）。なお、ユーザ端末Ａが匿名ユーザの場合、このＡ−３の処理は実施する必要はない。

ユーザ情報管理部１４のユーザ認証機能２４は、ユーザ端末Ａ（例：UserName001）に対応するユーザＡによってユーザ端末Ａを介してＷｅｂサーバ機能２６へ送信されたユーザ情報と、ユーザ情報ＤＢ２５に予め登録されているユーザ端末Ａ（例：UserName001）の認証情報を照合しユーザ端末Ａ（例：UserName001）に対してユーザ認証を行い、ユーザ認証に成功した場合、ユーザ端末Ａに対して認証キーの発行を行う（ステップＡ−４）。なお、ユーザ認証機能２４は、ユーザ端末Ａが匿名ユーザの場合、ステップＡ−４の処理を実施する必要はない。

Ｗｅｂサーバ機能２６は、接続Tokenを生成する（ステップＡ−５）。ここで、接続TokenはユーザＩＤと部屋ＩＤとの組み合わせであると仮定するが、この限りではない。また、ユーザ端末Ａが匿名ユーザの場合、ステップＡ−３、Ａ−４の処理を実施する必要はなく、Ｗｅｂサーバ機能２６は、ユーザ端末Ａを一意に識別できる一時的なＩＤに基づいて接続Tokenを生成する。

Ｗｅｂサーバ機能２６は、ユーザ認証機能２４によって発行されたユーザ端末Ａの認証キーと、サービス事業者を示すサービス事業者識別子（事業者の事業者識別ＩＤ等）とをユーザ端末Ａ（例：UserName001）に通知する（ステップＡ−６）。ここで、認証が成功した場合、Ｗｅｂサーバ機能２６は、ユーザ認証機能２４で発行された認証キーとゲームファイル、ユーザ端末Ａの接続Token、対戦相手情報（対戦相手のユーザＩＤ一覧など）をユーザ端末Ａに通知する。

ユーザ端末Ａは、サービス事業者がユーザ端末Ａ（例：UserName001）を一意に識別するためのユーザＩＤ、サービス事業者識別子、ＷｅｂＲＴＣ ＰＦを利用するためのＡＰＩ ｋｅｙ等の情報をシグナリング機能１８に送信し、ＷｅｂＲＴＣ ＰＦ利用者識別子の発行を要求する（ステップＡ−７）。なお、ここでは、ＡＰＩ ｋｅｙはユーザ端末Ａによって事前に申請され発行されている場合を想定している。

すると、サービス認証機能２０は、ステップＡ−７でユーザ端末Ａ（例：UserName001）からシグナリング機能１８に送信された情報と、ＷｅｂＲＴＣ利用者ＤＢ１９に予め登録されている情報を照会し、ユーザ認証を行い、ユーザ認証に成功した場合、ユーザ端末Ａに対して、ユーザ認証キーの発行を行う（ユーザ認証）（ステップＡ−８）。

シグナリング機能１８は、サービス認証機能２０で発行されたユーザ認証キーと、ＷｅｂＲＴＣ ＰＦを利用する際にピアを一意に識別するためのＩＤ（以下、ＷｅｂＲＴＣ ＰＦ利用者識別子と称す。）（例：PeerID001）と、をユーザ端末Ａ（例：UserName001）に対して発行し、発行したユーザ認証キーとＷｅｂＲＴＣ ＰＦ 利用者識別子をユーザ端末Ａに送信する（ステップＡ−９）。

ユーザ端末Ａは、Ｗｅｂサーバ機能２６から通知されたサービス事業者識別子とシグナリング機能１８から送信されたＷｅｂＲＴＣ ＰＦ利用者識別子とをネットワーク情報管理機能３１に送信する（ステップＡ−１０）。これにより、ネットワーク情報管理機能３１はユーザ端末Ａを一意に識別することができ、ネットワーク情報管理ＤＢ３２にユーザ毎に対応するユーザ端末毎のネットワーク情報を収集することができる。

ネットワーク情報管理機能３１は、ネットワーク情報を収集して、ステップＡ−１０でユーザ端末Ａから通知された、ユーザ端末Ａに対応するサービス事業者識別子とユーザ端末Ａに対応するＷｅｂＲＴＣ ＰＦ利用者識別子と関連付けてネットワーク情報管理ＤＢ３２に書き込んで管理する（ステップＡ−１１）。この時、ユーザ端末Ａからネットワーク情報管理機能３１に定期的にポーリング等してネットワーク情報を収集する方法もあれば、ＩＣＥ機能１７へ定期的に送信されるＳＴＵＮバインディングリクエストからネットワークを収集する方法や、別のシステムで取得したネットワーク情報を流用する方法が考えられるが、ここではその方法を限定しない。

ネットワーク情報管理機能３１は、サービス事業者識別子、ＷｅｂＲＴＣ ＰＦ利用者識別子をユーザ端末Ａから受けとると、ネットワークＡのネットワーク情報を収集開始したことをユーザ端末Ａに通知する（ステップＡ−１２）。

ユーザ端末Ａは、ステップＡ−６で通知されたサービス事業者識別子、ステップＡ−６で通知されたユーザ端末Ａの接続Token、ステップＡ−９で通知されたＷｅｂＲＴＣ ＰＦ利用者識別子（例：PeerID001）をＩＤ管理機能２２に送信する（ステップＡ−１３）。これにより、ユーザＡが対戦ユーザ（例えばユーザＢ）を指定した時に、Ｗｅｂサーバ機能２６に再度問い合わせることなく、ＷｅｂＲＴＣ ＰＦ部１３のみでユーザＢとの通信を確立することが可能となる。

ＩＤ管理機能２２は、ステップＡ−１３で送信されたＷｅｂＲＴＣ ＰＦ利用者識別子（例：PeerID001）およびサービス事業者識別子をＩＤ管理ＤＢ２３に書き込んで管理し、また、ユーザ端末Ａからサービス事業者識別子、ユーザＡの接続Token、ＷｅｂＲＴＣ ＰＦ利用者識別子を受けとったことをユーザ端末Ａに通知する（ステップＡ−１４）。

シーケンスＢはユーザＢのＷｅｂＲＴＣ ＰＦ利用準備のためのシーケンスである。このシーケンスＢは、ユーザ端末Ａの代わりにユーザ端末Ｂを使用し、Ａ−１からＡ−14と同様の処理を行うので説明を省略する。

次にシーケンスＣ、Ｄについて説明する。これらのシーケンスＣ、Ｄは、ユーザＡによる対戦ユーザの選択方法である。
ここで、シーケンスＣはユーザが対戦相手を直接指定して対戦ユーザを選択するためのシーケンスであり、シーケンスＤは、ネットワーク情報管理機能３１を用いて、ネットワークの混雑状況（通信速度、遅延、スループット、ジッタ等）に基づいて対戦相手を選出するためのシーケンスである。ここで、シーケンスＣ、Ｄのどちらを実行するかはユーザが選択することができる。

シーケンスＣにおいて、ユーザ端末Ａは、ユーザＡによる、対戦相手（ユーザＡが対戦相手の候補としたユーザ）のＩＤ（例えばユーザＢのＩＤ：UserName002）情報の入力操作を受け付けて、このＩＤを含む通信相手設定要求をＩＤ管理機能２２に送信する（ステップＣ−１）。

ＩＤ管理機能２２は、通信相手設定要求を受けて、ＩＤ管理ＤＢ２３にアクセスし、ステップＣ−１で送信された対戦相手のＩＤに基づいて、対戦相手のＷｅｂＲＴＣ ＰＦ利用者識別子を検索する（ステップＣ−２）。

ＩＤ管理機能２２は、対戦相手のＩＤがＩＤ管理ＤＢ２３に存在し、かつ、このＩＤに対応するユーザが他のユーザと対戦中でなければ、この対戦相手のＷｅｂＲＴＣ ＰＦ利用者識別子をユーザ端末Ａに通知する（ステップＣ−３）。この時、ＩＤ管理機能２２は、ステップＣ−１で送信されたＩＤに対応する対戦相手が存在しない、あるいは、この対戦相手が他のユーザと対戦中である場合、そのステータスをユーザ端末Ａに通知する。

次に、シーケンスＤにおいて、シーケンスＣのように対戦相手のＩＤを指定するのではなく、ユーザ端末Ａは、ユーザＡのＷｅｂＲＴＣ ＰＦ利用者識別子、および、対戦相手に要求するネットワーク情報（例えば遅延が8ms以上、10ms以下など）の入力を受け付けて、これらをＩＤ管理機能２２に送信することで、対戦相手のマッチングを要求する（ステップＤ−１）。

ＩＤ管理機能２２は、ＩＤ管理ＤＢ２３にアクセスし、ユーザＡのＷｅｂＲＴＣ ＰＦ利用者識別子に基づいて、ユーザＡのサービス事業者識別子を検索し、このユーザＡのサービス事業者識別子と、ユーザＡが対戦相手に要求するネットワーク情報（例えば遅延が8ms以上、10ms以下など）とをマッチング要求としてネットワーク情報管理機能３１に送信する（ステップＤ−２）。

ネットワーク情報管理機能３１は、マッチング要求を受けると、ＩＤ管理機能２２から受け取ったサービス事業者識別子と同じサービス事業者識別子に該当し、且つ、ユーザＡが対戦相手に要求するネットワーク情報（例えば遅延が8ms以上、10ms以下など）を満たすユーザのＷｅｂＲＴＣ ＰＦ利用者識別子をネットワーク情報管理ＤＢ３２から抽出する（ステップＤ−３）。

図２に示したネットワーク情報を例にとると、一番上の行のフィールドがユーザＡに対応する仮定した時に、ユーザＡのサービス事業者識別子は「Provider001」で、ＷｅｂＲＴＣ ＰＦ利用者識別子は「PeerID001」であることから、同じサービス事業者識別子であるユーザのＷｅｂＲＴＣ ＰＦ利用者識別子「PeerID002」、「PeerID004」、「PeerID005」のうち、遅延時間が8ms以上で10ms以下であるユーザのＷｅｂＲＴＣ ＰＦ利用者識別子は「PeerID005」であることから、この「PeerID005」が抽出る。

ネットワーク情報管理機能３１は、ステップＤ−３で抽出したユーザのＷｅｂＲＴＣ ＰＦ利用者識別子（例えばPeerID005）をＩＤ管理機能２２に通知する（ステップＤ−４）。この時、ネットワーク情報管理機能３１は、該当ユーザが複数居る場合、つまりＷｅｂＲＴＣ ＰＦ利用者識別子が複数ある場合は、これら複数ユーザのＷｅｂＲＴＣ ＰＦ利用者識別子をＩＤ管理機能２２通知し、該当ユーザが居ない場合は、該当ユーザが居ないことをＩＤ管理機能２２通知する。

ＩＤ管理機能２２は、ステップＤ−４より取得した１つ、もしくは複数のＷｅｂＲＴＣ ＰＦ利用者識別子の中からユーザＡ自身や現在対戦中のユーザに対応するＷｅｂＲＴＣ ＰＦ利用者識別子を除いた、ゲームに必要な数のＷｅｂＲＴＣ ＰＦ利用者識別子をＩＤ管理ＤＢ２３から抽出する（ステップＤ−５）。
ＩＤ管理機能２２は、この抽出したＷｅｂＲＴＣ ＰＦ利用者識別子をユーザ端末Ａに通知する（ステップＤ−６）。

次に、シーケンスＥについて説明する。
まず、ユーザ端末Ａの画面が対戦待ち画面に遷移すると（ステップＥ−１）、通信路を設定するためにステップＥ−２乃至Ｅ−５を実行する。具体的には、ユーザ端末Ａは、ステップＣ−３またはＤ−６で通知されたユーザＢのＷｅｂＲＴＣ ＰＦ利用者識別子を基に、通信路を設定するためのオファーをシグナリング機能１８を介してユーザ端末Ｂに対して行う（ステップＥ−２、Ｅ−３）。ユーザ端末Ｂは、通信路を設定するためのアンサーをシグナリング機能１８を介してユーザ端末Ａに対して行う（ステップＥ−４、Ｅ−５）。
ユーザ端末Ａは、この設定された通信路による接続性をユーザ端末Ｂとの間で確認する（ステップＥ−６、Ｅ−７）。

次に、接続確立まで、ステップＥ−８乃至Ｅ−１７を実行する。具体的には、ユーザ端末Ａは、ＩＣＥ候補の収集をＩＣＥ機能１７に要求し、ＩＣＥ機能１７はＩＣＥ候補を収集して、ユーザ端末Ａに返す（ステップＥ−８、Ｅ−９）。

次に、収集したＩＣＥ候補を用いて通信路を設定するためにステップＥ−１０乃至Ｅ−１５を実行する。具体的には、ユーザ端末Ａは、ステップＥ−９で返されたＩＣＥ候補を用いて通信路を設定するためのオファーをシグナリング機能１８を介してユーザ端末Ｂに対して行う（ステップＥ−１０、Ｅ−１１）。
ユーザ端末Ｂは、ＩＣＥ候補の収集をＩＣＥ機能１７に要求し、ＩＣＥ機能１７はＩＣＥ候補を収集して、ユーザ端末Ｂに返す（ステップＥ−１２、Ｅ−１３）。ユーザ端末Ｂは、収集したＩＣＥ候補を用いて通信路を設定するためのアンサーをシグナリング機能１８を介してユーザ端末Ａに対して行う（ステップＥ−１４、Ｅ−１５）。

ユーザ端末Ａは、この設定された通信路による接続性をユーザ端末Ｂとの間で確認する（ステップＥ−１６、Ｅ−１７）。

これらステップＥ−２〜Ｅ−１７は、ＷｅｂＲＴＣで使われているＴｒｉｃｌｅＩＣＥの標準規定通りであり、例えば「draft-ietf-mmusic-trickle-ice-02」
（http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02）に開示されている。

ユーザ端末Ｂは、ユーザＢに対戦許可を取り、このユーザＢが対戦許可を選択するための操作を行なった場合、ユーザ端末Ｂの画面がゲーム画面（対戦画面）へと遷移する（ステップＥ−１８）。

ユーザ端末Ｂは、ユーザ端末Ａに対戦許可を通知する（ステップＥ−１９）。
ユーザＢが対戦許可したため、ユーザ端末Ａの画面がゲーム画面（対戦画面）へと遷移する（ステップＥ−２０）。
そして、ユーザ端末Ａとユーザ端末Ｂとの間でＰ２Ｐ通信により、ゲームデータを交換する（ステップＥ−２１）。

以上のように、本発明の第１の実施形態では、ＷｅｂＲＴＣ（Web Real-time Communications）という技術を利用し、対戦ユーザ同士に対応するユーザ端末同士の通信を確立するまでの制御信号（C-plane）をＷｅｂＲＴＣ ＰＦ部経由でやり取りし、実際のゲームデータ（U-plane）をＰ２Ｐ通信によりユーザ端末同士で交換する。よって、ゲーム事業者は、ユーザ同士を対戦させるゲームであっても、サーバを用意してゲームデータをリレーさせたり、Ｐ２Ｐ通信を伴うアプリケーションを開発したりする必要がない。したがって、ゲームデータのリレーによって生じるサーバ負荷や、アプリケーション開発コストを低減させることができる。また、本発明の第１の実施形態におけるゲームシステムを用いることで、対戦ユーザのマッチングを最適化することができ、多様な対戦ユーザの選択方法をユーザに提供することができる。

また、ユーザは、サービスを利用するために、プラグインやアプリケーションのインストールが不要であり、即時にサービスを利用できる。また、上記のようにアプリをインストールが不要であるので、ユーザは、アプリのアップデートに伴う作業等を行う必要がなく、アプリのパージョンが異なることによる不具合を気にしなくて良い。

（第２の実施形態）
次に、第２の実施形態について説明する。なお、この実施形態における構成のうち第１の実施形態で説明した部分と同一部分の詳細な説明は省略する。
図４は、本発明の第２の実施形態におけるゲームシステムの構成例を示す図である。

図４に示すように、第２の実施形態におけるゲームシステムは、ＷｅｂＲＴＣ ＰＦ部１３、ユーザ情報管理部１４、サービス提供部１５を有し、例えばインターネットやキャリア網のような通信ネットワーク１０を介してユーザ端末１１（＃１）、・・・、１１（＃ｎ）同士で通信が可能である。また、この第２の実施形態におけるゲームシステムは、第１の実施形態で説明したネットワーク情報管理部３０は有しない。

図５Ａおよび図５Ｂは、本発明の第２の実施形態におけるゲームシステムの処理シーケンスの一例を示す図である。
この処理シーケンスは、シーケンスＡ、Ｂ、Ｃ、Ｅに大別される。
シーケンスＡはユーザＡのＷｅｂＲＴＣ ＰＦ利用準備のためのシーケンスである。
次に、シーケンスＡの詳細について説明する。
ユーザ端末Ａは、URLを指定するための入力を受け付ける等して、ゲーム事業者が提供しているＷｅｂページをサービス提供部１５のＷｅｂサーバ機能２６に要求する（ステップＡ−１）。

以降、第１の実施形態で説明したステップＡ−２〜ステップＡ−９が行われ、ユーザ認証が完了する。なお、第２の実施形態では、第１の実施形態で説明したステップＡ−９〜ステップＡ−１２は行われない。

次に、ユーザ端末Ａは、ステップＡ−６で通知されたサービス事業者識別子、ステップＡ−６で通知されたユーザ端末Ａの接続Token、ステップＡ−９で通知されたＷｅｂＲＴＣ ＰＦ利用者識別子（例：PeerID001）をＩＤ管理機能２２に送信する（ステップＡ−１３）。これにより、ユーザＡが対戦ユーザ（例えばユーザＢ）を指定した時に、Ｗｅｂサーバ機能２６に再度問い合わせることなく、ＷｅｂＲＴＣ ＰＦ部１３のみでユーザＢとの通信を確立することが可能となる。

ＩＤ管理機能２２は、サービス事業者識別子、ユーザＡの接続Token、ＷｅｂＲＴＣ ＰＦ利用者識別子を受けとったことをユーザ端末Ａに通知する（ステップＡ−１４）。

シーケンスＢはユーザＢのＷｅｂＲＴＣ ＰＦ利用準備のためのシーケンスである。このシーケンスＢは、ユーザ端末Ａの代わりにユーザ端末Ｂを使用し、ステップＡ−１からＡ−１４と同じ処理を行うので省略する。

次にシーケンスＣについて説明する。このシーケンスＣは、第１の実施形態でも説明したように、ユーザＡによる対戦ユーザの選択するためのであり、ステップＣ−１からＣ−３が行われて、対戦相手の選択が終了する。
次に、シーケンスＥが行われる。このシーケンスＥは、第１の実施形態と同じであるため、説明は省略する。

以上のように、本発明の第２の実施形態では、第１の実施形態で説明したネットワーク情報管理部３０を設けなくとも、ＷｅｂＲＴＣ（Web Real-time Communications）という技術を利用し、対戦ユーザ同士に対応するユーザ端末同士の通信を確立するまでの制御信号（C-plane）をＷｅｂＲＴＣ ＰＦ部経由でやり取りし、実際のゲームデータ（U-plane）をＰ２Ｐ通信によりユーザ端末同士で交換することができる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。

１０ 通信ネットワーク
１１ ユーザ端末
１２ ゲームシステム
１３ ＷｅｂＲＴＣ ＰＦ部
１４，６２ ユーザ情報管理部
１５，６１ サービス提供部
１７ ＩＣＥ機能
１８ シグナリング機能
２０ サービス認証機能
２２ ＩＤ管理機能
２４，７０ ユーザ認証機能
２５，６９ ユーザ情報ＤＢ
２６，７１ Ｗｅｂサーバ機能
３０ ネットワーク情報管理部
３１ ネットワーク情報管理機能

Claims (5)

1. 通信ネットワークに接続された第１のユーザ端末と第２のユーザ端末との間で通信するシステムであって、
   前記第１および第２のユーザ端末からの、ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて前記通信ネットワークに接続された前記第１および第２のユーザ端末を接続する機能を有するＷｅｂＲＴＣ（Web Real-time Communications）を使用するためのＷｅｂＲＴＣ ＰＦ（Platform）利用者識別子の発行要求に従って、前記第１のユーザ端末に対応する第１のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に発行し、前記第２のユーザ端末に対応する第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第２のユーザ端末に発行する識別子発行手段と、
   前記識別子発行手段により発行した、前記第１および第２のＷｅｂＲＴＣ ＰＦ利用者識別子を管理する識別子管理手段と、
   前記第１のユーザ端末からの、通信相手としてのユーザ端末の設定要求にしたがい、前記通信相手として前記第２のユーザ端末が設定された場合に、前記識別子管理手段が管理する、前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する送信手段と
   を備えたことを特徴とする通信システム。
2. 前記第２のユーザ端末は、前記第２のユーザ端末に対応するユーザの識別情報を前記識別子管理手段に送信し、
   前記識別子管理手段は、前記第２のユーザ端末から送信された識別情報を管理し、
   前記第１のユーザ端末は、前記通信相手の候補としての前記第２のユーザ端末に対応するユーザの識別情報とともに、通信相手設定の要求を前記識別子管理手段に送信し、
   前記送信手段は、前記第１のユーザ端末からの前記通信相手設定の要求を受けて、前記第１のユーザ端末から送信された前記第２のユーザ端末に対応するユーザの識別情報を前記識別子管理手段が管理している場合に、前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する
   ことを特徴とする請求項１に記載の通信システム。
3. 前記第１のユーザ端末による通信状態を示すネットワーク情報を前記第１のＷｅｂＲＴＣ ＰＦ利用者識別子と関連付けて管理し、また、前記第２のユーザ端末による通信状態を示すネットワーク情報を前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子と関連付けて管理するネットワーク情報管理手段をさらに備え、
   前記第１のユーザ端末は、前記通信相手として適切な前記ネットワーク情報の条件とともに、通信相手設定の要求を前記識別子管理手段に送信し、
   前記送信手段は、前記第１のユーザ端末からの前記通信相手設定の要求を受けて、前記条件を満たす前記第２のユーザ端末の前記ネットワーク情報について前記ネットワーク情報管理手段が管理している場合に、このネットワーク情報と関連付けられる前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する
   ことを特徴とする請求項１に記載の通信システム。
4. 通信ネットワークに接続された第１のユーザ端末と第２のユーザ端末との間で通信するシステムに適用される方法であって、
   前記第１および第２のユーザ端末からの、ネットワークアドレス変換（ＮＡＴ）またはファイアウォール（ＦＷ）設備を超えて前記通信ネットワークに接続された前記第１および第２のユーザ端末を接続する機能を有するＷｅｂＲＴＣ（Web Real-time Communications）を使用するためのＷｅｂＲＴＣ ＰＦ（Platform）利用者識別子の発行要求に従って、前記第１のユーザ端末に対応する第１のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に発行し、前記第２のユーザ端末に対応する第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第２のユーザ端末に発行し、
   前記発行した、前記第１および第２のＷｅｂＲＴＣ ＰＦ利用者識別子を管理し、
   前記第１のユーザ端末からの、通信相手としてのユーザ端末の設定要求にしたがい、前記通信相手として前記第２のユーザ端末が設定された場合に、前記管理する、前記第２のＷｅｂＲＴＣ ＰＦ利用者識別子を前記第１のユーザ端末に送信する
   ことを特徴とする通信方法。
5. 請求項１に記載の通信システムの一部分として動作するコンピュータに用いられるプログラムであって、
   前記コンピュータを、
   前記識別子発行手段、前記識別子管理手段、および前記送信手段
   として機能させるための通信処理プログラム。

Images