確認システム、通信システム、確認サーバ装置、確認方法、ならびに、プログラム
【課題】端末装置が利用できる通信プロトコルを適切に判断する確認サーバ装置等を提供する。
【解決手段】端末装置がＴＣＰ予告パケットを送信し（３０１）、確認サーバ装置が確認パケットを返送してから（３０２）、端末装置がＵＤＰ試行パケットを送信する（３０３）。確認サーバ装置は、予告パケットを受信してから一定期間の間に試行パケットが受信できれば、端末装置は外部の通信機器へＵＤＰパケットを送信可能であると判定する。確認サーバ装置が第１のＩＰアドレスから予告パケットを送信し（３０４）、端末装置が確認パケットを返送してから（３０５）、確認サーバが第２のＩＰアドレスからＵＤＰ試行パケットを送信する（３０６）。端末装置は、予告パケットを受信してから一定期間の間に試行パケットが受信できれば、端末装置は外部の通信機器からのＵＤＰパケットを受信可能であると判定する。
【解決手段】端末装置がＴＣＰ予告パケットを送信し（３０１）、確認サーバ装置が確認パケットを返送してから（３０２）、端末装置がＵＤＰ試行パケットを送信する（３０３）。確認サーバ装置は、予告パケットを受信してから一定期間の間に試行パケットが受信できれば、端末装置は外部の通信機器へＵＤＰパケットを送信可能であると判定する。確認サーバ装置が第１のＩＰアドレスから予告パケットを送信し（３０４）、端末装置が確認パケットを返送してから（３０５）、確認サーバが第２のＩＰアドレスからＵＤＰ試行パケットを送信する（３０６）。端末装置は、予告パケットを受信してから一定期間の間に試行パケットが受信できれば、端末装置は外部の通信機器からのＵＤＰパケットを受信可能であると判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置による通信がＮＡＴ（Network Address Translation）やＮＡＰＴ（Network Address Port Translation）等において制約を受けているかを適切に確認して、できるだけ高速な通信を可能とするのに好適な確認システム、通信システム、確認サーバ装置、確認方法、ならびに、これらをコンピュータにて実現するプログラムに関する。
【背景技術】
【０００２】
従来から、ネットワーク通信機能を持ったコンピュータやゲーム装置を用いて、動画チャットや通信対戦ゲームなどを行う通信システムが提案されている。このような通信システムでは、通信を始めようとする際に、通信相手のＩＰ（Internet Protocol）アドレスがサーバ装置によって紹介され、その後は、紹介されたＩＰアドレスを用いて直接ピアツーピア通信を行う技術も採用されている。
【０００３】
この際に用いられる通信プロトコルとしては、到着確認が行われるが通信効率が低いコネクション型プロトコルと、到着確認が行われないが通信効率が高いコネクションレス型プロトコルと、のいずれかを適宜利用するのが一般的であり、前者としてはＴＣＰ（Transfer Control Protocol）、後者としてはＵＤＰ（User Datagram Protocol）が広く用いられている。
【０００４】
さて、後に掲げる特許文献１においては、端末装置がファイアウォールやルータなどを介してインターネットに接続される場合に、ピアツーピア通信を行うためのアドレスやポート番号を適切に通知する技術が開示されている。
【０００５】
一方、非特許文献１においては、ＮＡＴやＮＡＰＴを使ったプライベートネットワーク内にある端末装置同士がＵＤＰコネクションを確立するための、ＵＤＰホールパンチング（UDP hole punching）という手法が開示されている。
【０００６】
ここで一般に、あらかじめ用意された中継ホストを利用して通信を中継させれば、ファイアウォール越しであっても端末装置同士のＴＣＰ通信は可能となることが多い。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−２６６８６３号公報
【非特許文献】
【０００８】
【非特許文献１】ウィキペディア，「UDP hole punching」の項，http://en.wikipedia.org/wiki/UDP_hole_punching，２００９年１月２８日
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、ピアツーピア通信が可能か否かを適切に判断するとともに、ピアツーピア通信ができない場合には、通信プロトコルや通信形態を適切に変更して、できるだけ高速な通信を可能としたい、との要望は大きい。
【００１０】
本発明は、上記のような課題を解決するもので、端末装置による通信がＮＡＴやＮＡＰＴ等において制約を受けているかを適切に確認して、できるだけ高速な通信を可能とするのに好適な確認システム、通信システム、確認サーバ装置、確認方法、ならびに、これらをコンピュータにて実現するプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
以上の目的を達成するため、本発明の原理にしたがって、下記の発明を開示する。
【００１２】
本発明の第１の観点に係る確認システムは、サーバ装置、端末装置と、を備える。
【００１３】
ここで、サーバ装置は、第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能であり、サーバ側予告受信部、サーバ側試行受信部、サーバ側判定部、サーバ側予告送信部、サーバ側試行送信部を備える。
【００１４】
一方、端末装置は、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能であり、端末側予告送信部、端末側試行送信部、端末側予告受信部、端末側試行受信部、端末側判定部を備える。
【００１５】
そして、サーバ装置と、端末装置と、が、コネクション型プロトコル通信可能に接続される。
【００１６】
コネクション型プロトコルとしては、典型的にはＴＣＰが利用され、コネクションレス型プロトコルとしては、典型的にはＵＤＰが利用される。一般に、コネクション型プロトコルは、コネクションレス型プロトコルよりも通信効率が低いが、セキュリティを考慮した場合、コネクションレス型プロトコルが利用できなくとも、コネクション型プロトコルが利用できるように、ファイアウォール等で設定されていることが多い。
【００１７】
そこで、本発明では、これらのプロトコルの利用可能性を、以下のように判定する。
【００１８】
まず、端末装置において、端末側予告送信部は、第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信し、端末側試行送信部は、第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する。
【００１９】
サーバ装置と端末装置とはコネクション型プロトコル通信が可能に接続されているので、予告パケットは、ほぼ確実に、サーバ装置に到着する。
【００２０】
一方、サーバ装置と端末装置とは、コネクションレス型プロトコル通信が可能か否かは不明である。したがって、試行パケットがサーバ装置に到着するか否かはわからない。
【００２１】
典型的には、端末装置は、予告パケットを送信し、当該予告パケットがサーバ装置に到着したことを確認してから、試行パケットを送信する。
【００２２】
一方、サーバ装置において、サーバ側予告受信部は、第１のアドレスを介して、端末装置から送信された予告パケットを受信し、サーバ側試行受信部は、予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、第１のアドレスを介して、端末装置から送信された試行パケットの受信を試みる。
【００２３】
上記のように、端末装置は、予告パケットと試行パケットを第１のアドレスに宛に送信するが、予告パケットは、ほぼ確実にサーバ装置に到着する。そこで、サーバ装置は、予告パケットが到着すると、サーバ側タイムアウト期間が経過するか、試行パケットが到着するまで、待機する。
【００２４】
そして、サーバ側判定部は、試行パケットが受信された場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定する。
【００２５】
コネクションレス型プロトコル通信によるパケットの送信が不可能である典型的な場合は、端末装置がファイアウォールを介してサーバ装置に接続されており、ファイアウォールにおいて、コネクションレス型プロトコル通信によるパケットの送出が禁止されている場合である。
【００２６】
本発明において、端末装置が通信を行う際の「外部」すなわち「他の通信機器」には、サーバ装置のほか、他の端末装置等がありうる。本発明では、サーバ装置との通信が可能か否かの判断結果を、そのまま、「外部」すなわち「他の通信機器」との通信可能か否かの推定結果とする。
【００２７】
すなわち、本発明では、「他の通信機器」のひとつであるサーバ装置との通信が可能であれば、「外部」「他の通信機器」のひとつである他の端末装置との通信も可能であると判断する。
【００２８】
一方、本発明では、「他の通信機器」のひとつであるサーバ装置との通信ができなければ、「外部」「他の通信機器」のひとつである他の端末装置との通信もできない、と判断するのである。
【００２９】
なお、後述するように、本発明では、外部から端末装置への通信の可否と、端末装置から外部への通信の可否と、を、区別して確認する点にも、特徴がある。
【００３０】
さらに、サーバ側予告送信部は、第１のアドレスから端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信する。
【００３１】
上記のように、サーバ装置と端末装置とは、コネクション型プロトコル通信が可能に接続されているので、当該予告パケットは、端末装置に、ほぼ確実に到着する。
【００３２】
そして、サーバ側試行送信部は、第２のアドレスから端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信する。
【００３３】
典型的には、サーバ装置から送信した予告パケットが端末装置に到着したことを確認してから、試行パケットを送信する。
【００３４】
なお、予告パケットを送信するアドレスと、試行パケットを送信するアドレスと、が、異なる点が、本発明の特徴である。
【００３５】
すると、端末装置において、端末側予告受信部は、サーバ装置から第１のアドレスを介して送信された予告パケットを受信し、端末側試行受信部は、予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、サーバ装置から第２のアドレスを介して送信された試行パケットの受信を試みる。
【００３６】
これらの処理は、上記のサーバ装置における処理と同様であるが、予告パケットの送信元と試行パケットの送信元のアドレスが異なる点が特徴である。
【００３７】
ＵＤＰホールパンチングの技術等では、ＬＡＮの内部から外部へパケットを送出することがあった場合に、その送出先をある程度信頼できるものと仮定して、当該送出先から送信されたパケットの流入を、一定期間認める手法があるが、このような手法は、セキュリティ上の問題があり、採用できないことも多い。そこで、より一層きめ細かい分析を可能とするため、サーバ装置が配置されている外部から端末装置が配置されている内部へのパケットの流入が可能かどうかを、異なるアドレスを用いて調べるのである。
【００３８】
そこで、端末側判定部は、試行パケットが受信された場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する。
【００３９】
すなわち、端末装置は、第２のアドレスからのパケットの流入が可能か否かによって、任意のアドレスからのパケットの流入が可能か否かを判定する。本手法では、サーバ装置から予告パケットが送信される以前は、端末装置もサーバ装置も第２のアドレスを用いた通信は行っていない。したがって、第２のアドレスからのパケットの受信ができれば、任意のアドレスからのパケットの受信ができる可能性は、極めて高いものと考えられる。
【００４０】
本発明によれば、端末装置からのコネクションレス型プロトコル通信によるパケットの送信が可能か否か、他の通信機器からのコネクションレス型プロトコル通信によるパケットの受信が端末装置で可能か否か、を適切に判定することができるようになる。
【００４１】
また、本発明の確認システムにおいて、端末装置は、第１のアドレスもしくは第２のアドレスに対して、コネクション型プロトコル通信により、端末側判定部による判定結果を指定する判定結果パケットを送信する端末側結果送信部をさらに備え、サーバ装置は、第１のアドレスもしくは第２のアドレスを介して、端末装置から送信された判定結果パケットを受信するサーバ側結果受信部をさらに備えるように構成することができる。
【００４２】
本発明は、コネクションレス型通信の端末装置での送信ならびに受信が可能か否かの情報をサーバ装置に集めるものである。
【００４３】
本発明を、たとえば、対戦ゲームのマッチングサーバに適用する場合、紹介する端末装置がどのようなプロトコルで通信可能か、を調べることにより、紹介する端末装置のそれぞれに、送受に利用するプロトコルを知らせれば、両端末装置は、効率の良いプロトコルで通信ができるようになる。
【００４４】
したがって、本発明によれば、端末装置の送受の状況を、サーバ装置において確認することができるようになる。
【００４５】
また、本発明の確認システムにおいて、サーバ装置の第１のアドレスならびに第２のアドレス、および、端末装置のアドレスは、いずれもＩＰ（Internet Protocol）アドレスであり、コネクション型プロトコルは、ＴＣＰ（Transmission Control Protocol）であり、コネクションレス型プロトコルは、ＵＤＰ（User Datagram Protocol）であるように構成することができる。
【００４６】
本発明は、上記発明の好適実施形態であり、広く利用されている通信プロトコルを採用するものである。
【００４７】
また、本発明においては、通信に用いるポート番号は、各プロトコルについて、定数とするのが典型的である。ポート番号を定数とすることによって、ファイアウォールの設定が容易になる。また、ポート番号を定数とすれば、外部からの流入を認めるポート番号を狭い範囲に抑制することができるので、広範なポートを開放しなければならないＵＰｎＰ（Universal Plug and Play）に比べて、セキュリティを向上させることができる。
【００４８】
本発明のその他の観点に係る確認システムは、サーバ装置と、第１の端末装置と、第２の端末装置と、を備え、以下のように構成する。
【００４９】
すなわち、サーバ装置ならびに第１の端末装置は、上記の確認システムにおけるサーバ装置ならびに端末装置として機能する。また、サーバ装置ならびに第２の端末装置は、上記の確認システムにおけるサーバ装置ならびに端末装置として機能する。
【００５０】
これらの機能によって、サーバ装置は、第１の端末装置と第２の端末装置のそれぞれにおいて、コネクションレス型プロトコル通信によるパケットの送受のそれぞれが可能であるか否かを知得することができる。
【００５１】
そして、サーバ装置は、第１の端末装置と第２の端末装置との間のパケットの送受について、
（ａ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が可能であると判定され、かつ、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクションレス型プロトコル通信を介して行い、
（ｂ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が不可能であると判定され、もしくは、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が不可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクション型プロトコル通信を介して行う
ように、第１の端末装置と第２の端末装置とに指示する。
【００５２】
すなわち、第１の端末装置と第２の端末装置の間でコネクションレス型プロトコル通信が可能か否かを片道ごとに判定し、可能である場合は、効率は良いが確実性の低いコネクションレス型プロトコル通信を採用し、不可能である場合には、効率は良くないが確実性の高いコネクション型プロトコル通信を採用するのである。
【００５３】
本発明によれば、通信可能性に基づいて、端末装置同士の通信を効率良く設定することができるようになる。
【００５４】
また、本発明の通信システムにおいて、第１の端末装置と第２の端末装置との間のパケットの送受が、直接コネクション型プロトコル通信を介して行うことができない場合、当該パケットの送受を、サーバ装置もしくは所定のプロキシサーバ装置に中継させてコネクション型プロトコル通信により行うように構成することができる。
【００５５】
すなわち、第１の端末装置と第２の端末装置との間のパケットの送受の片道もしくは往復において、コネクション型プロトコル通信を採用することとなった場合に、直接端末装置同士の通信ができないことがありうる。
【００５６】
たとえば、端末装置から他の通信機器に情報を問い合わせるプル型の通信は可能であるが、端末装置へ他の通信機器から情報を流し込むプッシュ型の通信の受入が不可能である場合である。
【００５７】
このような場合には、当該サーバ装置やプロキシサーバ装置により実現される中継サーバを利用し、パケットを受け入れる側の端末装置から中継サーバに問い合わせを行って、パケットを入手する形態で、パケットの送受を行うのである。
【００５８】
本発明によれば、パケットの送受の態様をより一層きめ細かく管理することができ、できるだけ効率良い通信方式を採用しつつ、通信制限が厳しい端末装置同士であっても、相互の通信を可能とすることができるようになる。
【００５９】
特に、通信が可能か否かの判断を詳細かつ適切に行うことにより、通信の片道のみ中継し、他方は直接通信させるなど、きめ細かい制御が可能となり、中継ホストをできるだけ利用せず、直接ピアツーピア通信によって効率良く通信を行う可能性を増やすことができるようになる。
【００６０】
本発明のその他の観点に係る確認サーバ装置は、上記通信システムにおけるサーバ装置である。
【００６１】
本発明のその他の観点に係る確認方法は、第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置と、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、を備え、サーバ装置と、端末装置と、が、コネクション型プロトコル通信可能に接続される確認システムにおいて、サーバ装置と、端末装置と、が実行する方法である。
【００６２】
ここで、端末装置は、端末側予告送信部、端末側試行送信部、端末側予告受信部、端末側試行受信部、端末側判定部を備え、サーバ装置は、サーバ側予告受信部、サーバ側試行受信部、サーバ側判定部、サーバ側予告送信部、サーバ側試行送信部を備える。
【００６３】
そして、本確認方法は、端末側予告送信工程、端末側試行送信工程、サーバ側予告受信工程、サーバ側試行受信工程、サーバ側判定工程、サーバ側予告送信工程、サーバ側試行送信工程、端末側予告受信工程、端末側試行受信工程、端末側判定工程を備える。
【００６４】
ここで、端末装置において、端末側予告送信工程では、端末側予告送信部が、第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信し、端末側試行送信工程では、端末側試行送信部が、第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する。
【００６５】
一方、サーバ装置において、サーバ側予告受信工程では、サーバ側予告受信部が、第１のアドレスを介して、端末装置から送信された予告パケットを受信し、サーバ側試行受信工程では、サーバ側試行受信部が、予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、第１のアドレスを介して、端末装置から送信された試行パケットの受信を試み、サーバ側判定工程では、サーバ側判定部が、試行パケットが受信された場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定する。
【００６６】
さらに、サーバ装置において、サーバ側予告送信工程では、サーバ側予告送信部が、第１のアドレスから端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信し、サーバ側試行送信工程では、サーバ側試行送信部が、第２のアドレスから端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信する。
【００６７】
さらに、端末装置において、端末側予告受信工程では、端末側予告受信部が、サーバ装置から第１のアドレスを介して送信された予告パケットを受信し、端末側試行受信工程では、端末側試行受信部が、予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、サーバ装置から第２のアドレスを介して送信された試行パケットの受信を試み、端末側判定工程では、端末側判定部が、試行パケットが受信された場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する。
【００６８】
本発明のその他の観点に係るプログラムは、サーバ用プログラムと、端末用プログラムと、を備え、サーバ用プログラムは、サーバ用コンピュータを、上記のサーバ装置として機能させ、端末用プログラムは、端末用コンピュータを、上記の端末装置として機能させるように構成する。
【００６９】
また、本発明のプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、半導体メモリ等のコンピュータ読取可能な情報記憶媒体に記録することができる。
【００７０】
上記プログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網を介して配布・販売することができる。また、上記情報記憶媒体は、コンピュータとは独立して配布・販売することができる。
【発明の効果】
【００７１】
本発明によれば、サーバ装置と複数の端末装置との間で、効率よく通信を行うのに好適な確認システム、通信システム、確認サーバ装置、確認方法ならびに、これらをコンピュータにて実現するためのプログラムを提供することができる。
【図面の簡単な説明】
【００７２】
【図１】プログラムを実行することにより、本実施形態の確認システムにおける端末装置として機能しうる典型的な情報処理装置の概要構成を示す模式図である。
【図２】本実施形態に係るサーバ装置と、端末装置と、の様子を示す説明図である。
【図３】確認処理の際に、１台の端末装置と、確認サーバ装置と、の間で行われる通信の様子を示すセッション図である。
【図４】本実施形態に係る端末装置の構成を示す模式図である。
【図５】本実施形態に係る確認サーバ装置の構成を示す模式図である。
【図６】本実施形態に係る端末装置にて実行される端末処理の制御の流れを示すフローチャートである。
【図７】本実施形態に係る確認サーバ装置にて実行されるサービス処理の制御の流れを示すフローチャートである。
【発明を実施するための形態】
【００７３】
以下に本発明の実施形態を説明する。以下では、理解を容易にするため、ゲーム用の情報処理装置を利用して本発明が実現される実施形態を説明するが、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。
【００７４】
したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
【実施例１】
【００７５】
図１は、プログラムを実行することにより、本実施形態の確認システムにおける端末装置として機能しうる典型的な情報処理装置の概要構成を示す模式図である。以下、本図を参照して説明する。
【００７６】
情報処理装置１００は、ＣＰＵ（Central Processing Unit）１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、インターフェース１０４と、コントローラ１０５と、外部メモリ１０６と、画像処理部１０７と、ＤＶＤ−ＲＯＭ（Digital Versatile Disc ROM）ドライブ１０８と、ＮＩＣ（Network Interface Card）１０９と、音声処理部１１０と、マイク１１１と、を備えるように構成することができる。各種の入出力装置は、適宜省略することができる。
【００７７】
ゲーム用のプログラムおよびデータを記憶したＤＶＤ−ＲＯＭをＤＶＤ−ＲＯＭドライブ１０８に装着して、情報処理装置１００の電源を投入することにより、当該プログラムが実行され、本実施形態の端末装置が実現される。
【００７８】
また、携帯型ゲーム機においては、携帯可能とするために、ＤＶＤ−ＲＯＭドライブ１０８を利用するのではなく、ＲＯＭカセット用スロットを利用することも可能である。この場合、プログラムが記録されたＲＯＭカセットを挿入して、当該プログラムを実行することで、本実施形態の端末装置が実現される。
【００７９】
なお、端末装置から専用サーバ装置に接続することにより対戦するゲーム機を紹介してもらった後、両者の間で通信をしてゲームを進めるようなシステムにおいては、ゲーム機とは異なるサーバ装置を用意することとなるが、このようなサーバ装置は、計算能力の違いや機器構成に少々の相違はあるものの、本質的には、情報処理装置１００と同様の構成である。ロビーサーバ、マッチングサーバ、中継サーバ等のほか、本発明の確認サーバ装置としては、情報処理装置１００と同様の構成ではあるが性能がより高いサーバ用コンピュータを利用するのが一般的である。
【００８０】
さて、ＣＰＵ １０１は、情報処理装置１００全体の動作を制御し、各構成要素と接続され制御信号やデータをやりとりする。また、ＣＰＵ １０１は、レジスタ（図示せず）という高速アクセスが可能な記憶域に対してＡＬＵ（Arithmetic Logic Unit）（図示せず）を用いて加減乗除等の算術演算や、論理和、論理積、論理否定等の論理演算、ビット和、ビット積、ビット反転、ビットシフト、ビット回転等のビット演算などを行うことができる。さらに、マルチメディア処理対応のための加減乗除等の飽和演算や、三角関数等、ベクトル演算などを高速に行えるように、ＣＰＵ １０１自身が構成されているものや、コプロセッサを備えて実現するものがある。
【００８１】
ＲＯＭ １０２には、電源投入直後に実行されるＩＰＬ（Initial Program Loader）が記録され、これが実行されることにより、ＤＶＤ−ＲＯＭに記録されたプログラムをＲＡＭ １０３に読み出してＣＰＵ １０１による実行が開始される。また、ＲＯＭ １０２には、情報処理装置１００全体の動作制御に必要なオペレーティングシステムのプログラムや各種のデータが記録される。
【００８２】
ＲＡＭ １０３は、データやプログラムを一時的に記憶するためのもので、ＤＶＤ−ＲＯＭから読み出したプログラムやデータ、その他ゲームの進行やチャット通信に必要なデータが保持される。また、ＣＰＵ １０１は、ＲＡＭ １０３に変数領域を設け、当該変数に格納された値に対して直接ＡＬＵを作用させて演算を行ったり、ＲＡＭ １０３に格納された値を一旦レジスタに格納してからレジスタに対して演算を行い、演算結果をメモリに書き戻す、などの処理を行う。
【００８３】
インターフェース１０４を介して接続されたコントローラ１０５は、ユーザがゲーム実行の際に行う操作入力を受け付ける。
【００８４】
なお、コントローラ１０５は、必ずしも情報処理装置１００に対して外付けにされている必要はなく、一体に形成されていても良い。
【００８５】
携帯可能な端末装置のコントローラ１０５は、各種のボタンやスイッチから構成され、これらの押圧操作を操作入力として扱う。このほか、タッチスクリーンを利用した情報処理装置１００では、ユーザがペンや指を利用してタッチスクリーンをなぞった軌跡を操作入力として扱う。
【００８６】
インターフェース１０４を介して着脱自在に接続された外部メモリ１０６には、ゲーム等のプレイ状況（過去の成績等）を示すデータ、ゲームの進行状態を示すデータ、ネットワーク対戦の場合のチャット通信のログ（記録）のデータなどが書き換え可能に記憶される。ユーザは、コントローラ１０５を介して指示入力を行うことにより、これらのデータを適宜外部メモリ１０６に記録することができる。
【００８７】
ＤＶＤ−ＲＯＭドライブ１０８に装着されるＤＶＤ−ＲＯＭには、ゲームを実現するためのプログラムとゲームに付随する画像データや音声データが記録される。ＣＰＵ １０１の制御によって、ＤＶＤ−ＲＯＭドライブ１０８は、これに装着されたＤＶＤ−ＲＯＭに対する読み出し処理を行って、必要なプログラムやデータを読み出し、これらはＲＡＭ １０３等に一時的に記憶される。
【００８８】
画像処理部１０７は、ＤＶＤ−ＲＯＭから読み出されたデータをＣＰＵ １０１や画像処理部１０７が備える画像演算プロセッサ（図示せず）によって加工処理した後、これを画像処理部１０７が備えるフレームメモリ（図示せず）に記録する。フレームメモリに記録された画像情報は、所定の同期タイミングでビデオ信号に変換され画像処理部１０７に接続されるモニタ（図示せず）へ出力される。これにより、各種の画像表示が可能となる。
【００８９】
携帯可能なゲーム機のモニタとしては、小型の液晶ディスプレイを利用するのが典型的であり、コントローラ１０５としてタッチスクリーンを利用する場合には、当該タッチスクリーンの表示パネルがモニタとして機能する。自宅で遊ぶためのゲーム機のモニタとしては、ＣＲＴ（Cathode Ray Tube）やプラズマディスプレイなどの表示装置を利用することも可能である。
【００９０】
画像演算プロセッサは、２次元の画像の重ね合わせ演算やαブレンディング等の透過演算、各種の飽和演算を高速に実行できる。
【００９１】
また、仮想３次元空間に配置され、各種のテクスチャ情報が付加されたポリゴン情報を、Ｚバッファ法によりレンダリングして、所定の視点位置から仮想３次元空間に配置されたポリゴンを所定の視線の方向へ俯瞰したレンダリング画像を得る演算の高速実行も可能である。
【００９２】
さらに、ＣＰＵ １０１と画像演算プロセッサが協調動作することにより、文字の形状を定義するフォント情報にしたがって、文字列を２次元画像としてフレームメモリへ描画したり、各ポリゴン表面へ描画することが可能である。
【００９３】
ＮＩＣ １０９は、情報処理装置１００をインターネット等のコンピュータ通信網（図示せず）に接続するためのものであり、ＬＡＮを構成する際に用いられる１０ＢＡＳＥ−Ｔ／１００ＢＡＳＥ−Ｔ規格にしたがうものや、電話回線を用いてインターネットに接続するためのアナログモデム、ＩＳＤＮ（Integrated Services Digital Network）モデム、ＡＤＳＬ（Asymmetric Digital Subscriber Line）モデム、ケーブルテレビジョン回線を用いてインターネットに接続するためのケーブルモデム等と、これらとＣＰＵ １０１との仲立ちを行うインターフェース（図示せず）により構成される。
【００９４】
音声処理部１１０は、ＤＶＤ−ＲＯＭから読み出した音声データをアナログ音声信号に変換し、これに接続されたスピーカ（図示せず）から出力させる。また、ＣＰＵ １０１の制御の下、ゲームの進行の中で発生させるべき効果音や楽曲データを生成し、これに対応した音声をスピーカや、ヘッドホン（図示せず）、イヤフォン（図示せず）から出力させる。
【００９５】
音声処理部１１０では、ＤＶＤ−ＲＯＭに記録された音声データがＭＩＤＩデータである場合には、これが有する音源データを参照して、ＭＩＤＩデータをＰＣＭデータに変換する。また、ADPCM形式やOgg Vorbis形式等の圧縮済音声データである場合には、これを展開してＰＣＭデータに変換する。ＰＣＭデータは、そのサンプリング周波数に応じたタイミングでＤ／Ａ（Digital/Analog）変換を行って、スピーカに出力することにより、音声出力が可能となる。
【００９６】
さらに、情報処理装置１００には、インターフェース１０４を介してマイク１１１を接続することができる。この場合、マイク１１１からのアナログ信号に対しては、適当なサンプリング周波数でＡ／Ｄ変換を行い、ＰＣＭ形式のディジタル信号として、音声処理部１１０でのミキシング等の処理ができるようにする。
【００９７】
このほか、情報処理装置１００は、ハードディスク等の大容量外部記憶装置を用いて、ＲＯＭ １０２、ＲＡＭ １０３、外部メモリ１０６、ＤＶＤ−ＲＯＭドライブ１０８に装着されるＤＶＤ−ＲＯＭ等と同じ機能を果たすように構成してもよい。
【００９８】
また、ユーザからの文字列の編集入力を受け付けるためのキーボードや、各種の位置の指定および選択入力を受け付けるためのマウスなどを接続する形態も採用することができる。また、本実施形態の情報処理装置１００にかえて、汎用のパーソナルコンピュータを利用することもできる。
【００９９】
以上で説明した情報処理装置１００は、いわゆるコンシューマ向けゲーム機に相当するものであるが、携帯電話、携帯ゲーム機器、カラオケ装置、一般的なビジネス用コンピュータなど、種々の計算機上で本発明の確認サーバ装置や端末装置を実現することが可能である。
【０１００】
たとえば、一般的なコンピュータは、上記情報処理装置１００と同様に、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＤＶＤ−ＲＯＭドライブ、および、ＮＩＣを備え、情報処理装置１００よりも簡易な機能を備えた画像処理部を備え、外部記憶装置としてハードディスクを有する他、フレキシブルディスク、光磁気ディスク、磁気テープ等が利用できるようになっている。また、コントローラ１０５ではなく、キーボードやマウスなどを入力装置として利用する。
【０１０１】
図２は、本実施形態に係る確認サーバ装置と、端末装置とからなる通信システムの様子を示す説明図である。以下、本図を参照して説明する。
【０１０２】
通信システム２０１は、１台の確認サーバ装置２２１と、２台の端末装置２４１と、を備え、これらはインターネット２６１に接続されている。
【０１０３】
２台の端末装置２４１は、確認サーバ装置２２１の紹介を受けて、通信の準備を始める。すなわち、確認サーバ装置２２１は、通信対戦ゲームにおけるロビーサーバとして機能する。
【０１０４】
したがって、各端末装置２４１に電源が投入され、インターネット２６１への接続が行われると、端末装置２４１から確認サーバ装置２２１へその旨の通知がなされるので、確認サーバ装置２２１では、端末装置２４１の通信がどのようなプロトコルでどのように可能か、を判定するための確認処理が実行されることになる。
【０１０５】
なお、本実施形態では、コネクション型プロトコルとしてＴＣＰを、コネクションレス型プロトコルとしてＵＤＰを、それぞれ採用する。また、確認サーバ装置２２１や端末装置２４１のアドレスとして、ＩＰアドレスを採用する。
【０１０６】
また、通信の際に利用するポートは、ＴＣＰ、ＵＤＰのそれぞれの場合において、あらかじめ定められたポート番号を利用することとする。
【０１０７】
図３は、確認処理の際に、１台の端末装置２４１と、確認サーバ装置２２１と、の間で行われる通信の様子を示すセッション図である。以下、本図を参照して説明する。
【０１０８】
端末装置２４１に電源が投入され、インターネット２６１への接続が行われると、端末装置２４１は、自身のＩＰアドレスを発信元として、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）宛に、ＴＣＰにより、予告パケットを送信する（３０１）。
【０１０９】
ここで、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）は、通信対戦ゲームのソフトウェア等によって定義されたものである。また、ポート番号もあらかじめ固定されていることから、端末装置２４１がルータ越しにインターネット２６１に接続されている場合であっても、フィルタリングのルールを適切に設定することによって、通信が可能となる。
【０１１０】
すると、予告パケットを受信した確認サーバ装置２２１は、コネクション通信の規約にしたがい、当該受信を通知するため、端末装置２４１へ確認パケットを送信する（３０２）。
【０１１１】
パケットの送受（３０１、３０２）によって、端末装置２４１から確認サーバ装置２２１への通信が、ＴＣＰによって可能に接続されていることが確認されると、端末装置２４１は、自身のＩＰアドレスを発信元として、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）宛に、ＵＤＰにより、試行パケットを送信する（３０３）。
【０１１２】
ＵＤＰは、コネクションレス型通信プロトコルであるから、当該試行パケットが確認サーバ装置２２１に到着したか否かを、ＵＤＰの規約から知ることはできない。
【０１１３】
確認サーバ装置２２１は、予告パケットを受信し（３０１）、確認パケットを送信して（３０２）から、所定のタイムアウト時間が経過するまで、試行パケットが到着するのを待つ。
【０１１４】
ここで、本図に示すように、試行パケットが確認サーバ装置２２１に到達した場合には、端末装置２４１から「他の任意の通信機器」へ、ＵＤＰによるパケットの送出が可能であると判定する（判定結果ａ）。
【０１１５】
一方、本図に示すものとは異なり、タイムアウト時間が経過するまでに、確認サーバ装置２２１に到達しなかった場合には、端末装置２４１から「他の任意の通信機器」へのＵＤＰによるパケットの送出はできない、と判定する（判定結果ｂ）。
【０１１６】
試行パケットを受信するか、あるいは、所定のタイムアウト時間が経過すると、確認サーバ装置２２１は、予告パケット（３０１）の発信元として指定されたＩＰアドレス宛、すなわち、端末装置２４１宛に、公開ＩＰアドレス（第１のＩＰアドレス）を発信元として、ＴＣＰにより、予告パケットを送信する（３０４）。
【０１１７】
この予告パケットを受信した端末装置２４１は、コネクション通信の規約にしたがい、当該受信を通知するため、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）へ、自身のＩＰアドレスを発信元として、確認パケットを送信する（３０５）。
【０１１８】
パケットの送受（３０４、３０５）によって、確認サーバ装置２２１から端末装置２４１への通信が、ＴＣＰによって可能に接続されていることが確認されると、確認サーバ装置２２１は、非公開ＩＰアドレス（第２のＩＰアドレス）を発信元として、端末装置２４１のＩＰアドレス宛に、ＵＤＰにより、試行パケットを送信する（３０６）。
【０１１９】
ここで、非公開ＩＰアドレス（第２のＩＰアドレス）とは、確認サーバ装置２２１に公開ＩＰアドレス（第１のＩＰアドレス）とは別に割り当てられたものであり、端末装置２４１があらかじめ知得しているものではない。
【０１２０】
確認サーバ装置２２１が有するＮＩＣ １０９に対して、複数のＩＰアドレスを用意することは、現在の技術で可能であり、そのうちの１つを公開情報として広く知得させる一方で、非公開ＩＰアドレスは、適宜変更される可能性がある不定のアドレスとしておく。
【０１２１】
そして、試行パケットを送信する際に発信元のＩＰアドレスとして指定されることで、端末装置２４１に初めて知得されるようにする。ＩＰアドレスをこのように用意しておけば、端末装置２４１側のルータで、あらかじめ非公開ＩＰアドレス専用にＵＤＰ用のポートを空けておくように設定しておくことはできないことになる。
【０１２２】
さて、端末装置２４１は、予告パケットを受信し（３０４）、確認パケットを送信して（３０５）から、所定のタイムアウト時間が経過するまで、試行パケットが到着するのを待つ。
【０１２３】
ここで、本図に示すように、試行パケットが端末装置２４１に到達した場合には、「他の任意の通信機器」からＵＤＰにより送信されたパケットの端末装置２４１による受信が可能であると判定する（判定結果ｃ）。
【０１２４】
一方、本図に示すものとは異なり、タイムアウト時間が経過するまでに、試行パケットが端末装置２４１に到達しなかった場合には、「他の任意の通信機器」からＵＤＰにより送信されたパケットの端末装置２４１による受信はできないと判定する（判定結果ｄ）。
【０１２５】
そして、判定ｃ／ｄの結果を表す結果パケットが端末装置２４１から確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）へ送信され（３０７）、確認サーバ装置２２１から端末装置２４１へ、結果パケットの到着を示す確認パケットが送信される（３０８）。
【０１２６】
これによって、確認サーバ装置２２１は、端末装置２４１のＵＤＰによる通信がどの方向に可能であるか否かを判定することができる。すなわち、端末装置２４１からのＵＤＰパケットの送出については、判定結果ａ／ｂが得られ、端末装置２４１へのＵＤＰパケットの受入については、判定結果ｃ／ｄが得られる。
【０１２７】
確認サーバ装置２２１は、紹介しようとする２台の端末装置２４１のそれぞれに、ＵＤＰパケットの送出および受入が可能であるか否かを、上記のような通信を元に、判定するのである。
【０１２８】
以下、これらの判定を行うための確認サーバ装置２２１の構成と、端末装置２４１の構成と、について、さらに詳細に説明する。
【０１２９】
図４は、本実施形態に係る端末装置２４１の構成を示す模式図である。図５は、本実施形態に係る確認サーバ装置２２１の構成を示す模式図である。以下、これらの図を参照して説明する。
【０１３０】
図４に示すように、端末装置２４１は、端末側予告送信部４０１、端末側試行送信部４０２、端末側予告受信部４０３、端末側試行受信部４０４、端末側判定部４０５、端末側結果送信部４０６を備える。これらの各要素のうち、端末側判定部４０５は、情報処理装置１００のＣＰＵ １０１により実現され、他の要素は、ＣＰＵ １０１の制御の下、ＮＩＣ １０９により実現される。
【０１３１】
図５に示すように、確認サーバ装置２２１は、サーバ側予告受信部５０１、サーバ側試行受信部５０２、サーバ側判定部５０３、サーバ側予告送信部５０４、サーバ側試行送信部５０５、サーバ側結果受信部５０６を備える。これらの各要素のうち、サーバ側判定部５０３は、情報処理装置１００のＣＰＵ １０１により実現され、他の要素は、ＣＰＵ １０１の制御の下、ＮＩＣ １０９により実現される。
【０１３２】
以下、これら各部の機能を、処理の詳細な制御の流れに基づいて説明する。
【０１３３】
さて、図６は、本実施形態に係る端末装置２４１にて実行される端末処理の制御の流れを示すフローチャートである。図７は、本実施形態に係る確認サーバ装置２２１にて実行されるサービス処理の制御の流れを示すフローチャートである。以下、これらの図を参照して説明する。
【０１３４】
まず、端末装置２４１において、電源が投入されたり、通信対戦ゲームが開始されたりすることを契機として、端末処理が開始されると、端末側予告送信部４０１は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）に対して、ＴＣＰにより、予告パケットを送信する（ステップＳ６０１）。
【０１３５】
一方、確認サーバ装置２２１は、電源が投入されると、端末装置２４１からパケットが到達するのを待機する状態となる。ステップＳ６０１において送信された予告パケットが到達したことが検知されたことを契機として、サービス処理が開始され、サーバ側予告受信部５０１が、予告パケットを受信する（ステップＳ７０１）。
【０１３６】
すると、確認サーバ装置２２１は、予告パケットを受信した旨を通知するため、予告パケットの発信元のＩＰアドレスに対して、ＴＣＰにより、確認パケットを送信する（ステップＳ７０２）。
【０１３７】
確認サーバ装置２２１から送信された確認パケットを端末装置２４１が受信すると（ステップＳ６０２）、端末装置２４１の端末側試行送信部４０２は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）に対して、ＵＤＰにより試行パケットを送信する（ステップＳ６０３）。
【０１３８】
一方、確認サーバ装置２２１では、確認パケットを送信した後（ステップＳ７０２）、確認サーバ装置２２１のサーバ側試行受信部５０２は、サーバ側タイムアウト期間が経過するまで待機して、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）を介して、端末装置２４１から送信された試行パケットの受信を試みる（ステップＳ７０３）。
【０１３９】
そして、タイムアウト期間が経過するまでに、試行パケットが受信ができた場合（ステップＳ７０４；Ｙｅｓ）、サーバ側判定部５０３は、「端末装置２４１は、外部（他の通信機器）に対して、ＵＤＰによるパケットの送信が可能である（判定結果ａ）」と判定する（ステップＳ７０５）。
【０１４０】
一方、受信されなかった場合（ステップＳ７０４；Ｎｏ）、サーバ側判定部５０３は、「端末装置２４１は、外部（他の通信機器）に対して、ＵＤＰによるパケットの送信が不可能である（判定結果ｂ）」と判定する（ステップＳ７０６）。
【０１４１】
これらの判定（ステップＳ７０５、Ｓ７０６）が終わると、確認サーバ装置２２１のサーバ側予告送信部５０４は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）から端末装置２４１に対して、ＴＰＣにより、予告パケットを送信する（ステップＳ７０７）。
【０１４２】
すると、端末装置２４１では、端末側予告受信部４０３が、確認サーバ装置２２１から送信された予告パケットを受信して（ステップＳ６０４）、当該受信を通知するため、予告パケットの発信元のＩＰアドレスに対して、ＴＣＰにより、確認パケットを送信する（ステップＳ６０５）。
【０１４３】
端末装置２４１から送信された確認パケットを確認サーバ装置２２１が受信すると（ステップＳ７０８）、確認サーバ装置２２１のサーバ側試行送信部５０５は、非公開ＩＰアドレス（第２のＩＰアドレス）を発信元として、端末装置２４１のＩＰアドレスに対して、ＵＤＰにより試行パケットを送信する（ステップＳ７０９）。
【０１４４】
一方、端末装置２４１では、確認パケットを送信した後（ステップＳ６０５）、端末側試行受信部４０４は、端末側タイムアウト期間が経過するまで待機して、試行パケットの受信を試みる（ステップＳ６０６）。
【０１４５】
これらの処理は、上記の確認サーバ装置２２１における処理と同様であるが、予告パケットの送信元と試行パケットの送信元のアドレスが異なる点が特徴である。
【０１４６】
ＵＤＰホールパンチングの技術等では、ＬＡＮの内部から外部（他の通信機器）へパケットを送出すると、その送出先をある程度信頼できるものと仮定して、当該送出先から送信されたパケットの流入を、一定期間認める手法があるが、このような手法は、セキュリティ上の問題があり、採用できないことも多い。そこで、より一層きめ細かい分析を可能とするため、確認サーバ装置２２１が配置されている外部（他の通信機器）から端末装置２４１が配置されている内部へのパケットの流入が可能かどうかを、異なるアドレスを用いて調べるのである。
【０１４７】
そして、タイムアウト期間が経過するまでに、試行パケットが受信された場合（ステップＳ６０７；Ｙｅｓ）、端末側判定部４０５は、「端末装置２４１は、外部（他の通信機器）からの、ＵＤＰによるパケットの受信が可能である（判定結果ｃ）」と判定する（ステップＳ６０８）。
【０１４８】
一方、タイムアウト期間が経過するまでに、試行パケットが受信されなかった場合（ステップＳ６０７；Ｎｏ）、端末側判定部４０５は、「端末装置２４１は、外部（他の通信機器）からの、ＵＤＰによるパケットの受信が不可能である（判定結果ｄ）」と判定する（ステップＳ６０９）。
【０１４９】
なお、タイムアウト期間は、確認サーバ装置２２１と端末装置２４１とで、異なる値としても良いし、同じ値としても良い。
【０１５０】
すなわち、端末装置２４１は、第２のアドレスからのパケットの流入が可能か否かによって、任意のアドレスからのパケットの流入が可能か否かを判定する。本手法では、確認サーバ装置２２１から予告パケットが送信される以前は、端末装置２４１も確認サーバ装置２２１も第２のアドレスを用いた通信は行っていない。したがって、第２のアドレスからのパケットの受信ができれば、任意のアドレスからのパケットの受信ができる可能性は、極めて高いものと考えられる。
【０１５１】
この後、端末装置２４１において、端末側結果送信部４０６は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）に対して、ＴＰＣにより、端末側判定部４０５による判定結果を指定する判定結果パケットを送信する（ステップＳ６１０）。
【０１５２】
これに対して、確認サーバ装置２２１において、サーバ側結果受信部５０６は、確認サーバ装置２２１の端末装置２４１から送信された判定結果パケットを受信する（ステップＳ７１０）。
【０１５３】
そして、当該受信を確認する確認パケットが、確認サーバ装置２２１から送信され（ステップＳ７１１）、これを端末装置２４１が受信することにより（ステップＳ６１１）、これらの処理は終了する。
【０１５４】
各端末装置２４１に対してこれらの処理を行うことにより、確認サーバ装置２２１は、当該端末装置２４１に対する判定結果を収集することができる。
【０１５５】
なお、上記のように、通信に用いるポート番号を各プロトコルについて定数とすると、ファイアウォールの設定が容易になる。また、ポート番号を定数とすれば、外部からの流入を認めるポート番号を狭い範囲に抑制することができるので、広範なポートを開放しなければならないＵＰｎＰに比べて、セキュリティを向上させることができる。
【０１５６】
さて、上記のような端末処理およびサービス処理によって、確認が行われ、判定結果ａ〜ｄが確認サーバ装置２２１に得られると、確認サーバ装置２２１は、マッチングサーバとして機能し、ログインしている端末装置２４１の中から、対戦させる端末装置２４１を２台選択する。そして、その２台の端末装置２４１に、通信に用いるべきＩＰアドレス、および、送信に用いるプロトコル、受信に用いるプロトコル等について通知する。
【０１５７】
ここで、ある端末装置２４１から、別の端末装置２４１への片道のパケットの送受を考えると、以下の４通りの状態がありうる。
（ａ）送信側は、ＵＤＰ送出可能、受信側は、ＵＤＰ受入可能。
（ｂ）送信側は、ＵＤＰ送出可能、受信側は、ＵＤＰ受入不可。
（ｃ）送信側は、ＵＤＰ送出不可、受信側は、ＵＤＰ受入可能。
（ｄ）送信側は、ＵＤＰ送出不可、受信側は、ＵＤＰ受入不可。
【０１５８】
これらの分類において、状態（ａ）では、当該片道の通信において、通信効率の良いＵＤＰが利用可能であるが、状態（ｂ）（ｃ）（ｄ）では、通信効率がＵＤＰに比べて低いＴＣＰを利用しなければならないことになる。
【０１５９】
そこで、２台の端末装置２４１には、パケットの送信とパケットの受信とのそれぞれにおいて、ＵＤＰを利用するか、ＴＣＰを利用するか、を指定する。
【０１６０】
また、予告パケット（３０１）等によって得られたＩＰアドレスを、当該端末装置２４１の通信用のＩＰアドレスとして、相手方の端末装置２４１に通知する。
【０１６１】
端末装置２４１は、マッチングサーバとして機能する確認サーバ装置２２１から通知されたＩＰアドレスを、相手方の端末装置２４１のＩＰアドレスとして使用することになる。
【０１６２】
なお、上記の説明では、ＴＣＰ通信は双方向に可能であることを前提に説明しているが、「流出（３０１、３０２）は可能であるが、流入（３０４、３０５）は不可能である」ようにルータ等を設定することもありうる。このように設定されているか否かは、確認サーバ装置２２１から予告パケットを送信（３０４）してから、所定のタイムアウト時間が経過するまでに、確認パケットが到着するか否か、によって判定が可能である。
【０１６３】
すなわち、「端末装置２４１は、端末装置２４１からの送信を契機とするＴＣＰ通信と、『他の任意の通信機器』からの送信を契機とするＴＣＰ通信と、の２つが可能である（判定結果ｘ）」、あるいは、「端末装置２４１は、端末装置２４１からの送信を契機とするＴＣＰ通信は可能であるが、『他の任意の通信機器』からの送信を契機とするＴＣＰ通信はできない（判定結果ｙ）」のいずれであるかを判定することも可能である。
【０１６４】
両端末装置２４１において、判定結果ｘが得られた場合には、プッシュ型およびプル型の通信が相互に可能である、ということになるから、両端末装置２４１は、ＴＣＰによって、直接ピアツーピアに通信を行うことになる。
【０１６５】
一方、両端末装置２４１において、判定結果ｙが得られた場合には、プル型の通信のみが可能である、ということになる。この場合には、相手方に送るべきパケットを一旦中継サーバに送信し、蓄積させる。中継サーバは、端末装置２４１からの問い合わせがあると、蓄積されているパケットのうち、問い合わせ元の端末装置２４１宛のパケットを応答として返信する。
【０１６６】
端末装置２４１の一方で判定結果ｘが得られ、端末装置２４１の他方で判定結果ｙが得られた場合には、一方の片道については、上記の一方の手法を、他方の片道については、上記の他方の手法を、それぞれ利用すれば良い。
【０１６７】
また、プッシュ型の通信が可能な端末装置２４１に対しては、中継サーバに当該端末装置２４１宛のパケットが到着したら、直ちに当該端末装置２４１に転送することとしても良い。
【０１６８】
中継サーバとしては、上記の確認サーバ装置２２１を利用することができるほか、専用の中継プロキシサーバを利用することとしても良い。後者の場合には、マッチングの際に、中継プロキシサーバのＩＰアドレスを端末装置２４１に知らせるとともに、当該端末装置２４１は、自身宛のパケットをプッシュ型により取得すべきか、プル型により取得すべきか、を指定すれば良い。
【０１６９】
なお、上記の態様では、端末装置２４１同士を紹介する前に、確認サーバ装置２２１が各端末装置２４１におけるパケット送受の能力を判定しているが、以下のような態様を採用することも可能である。
【０１７０】
すなわち、まず最初に、各端末装置２４１同士のＩＰアドレスを紹介してしまう。そして、端末装置２４１同士の間でピアツーピアの通信が可能か否かを実際に調べさせ、通信が可能である場合には、そのまま処理を続行させる。
【０１７１】
一方、通信が不可能である場合には、その結果を確認サーバ装置２２１に通知させる。その上で、確認サーバ装置２２１と各端末装置２４１との間で、上記の確認処理を実行して、中継サーバを利用するか否かを判定するのである。
【産業上の利用可能性】
【０１７２】
本発明によれば、端末装置による通信がＮＡＴやＮＡＰＴ等において制約を受けているかを適切に確認して、できるだけ高速な通信を可能とするのに好適な確認システム、通信システム、確認サーバ装置、確認方法、ならびに、これらをコンピュータにて実現するプログラムを提供することができる。
【符号の説明】
【０１７３】
１００ 情報処理装置
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ インターフェース
１０５ コントローラ
１０６ 外部メモリ
１０７ 画像処理部
１０８ ＤＶＤ−ＲＯＭドライブ
１０９ ＮＩＣ
１１０ 音声処理部
１１１ マイク
２０１ 通信システム
２２１ 確認サーバ装置
２４１ 端末装置
２６１ インターネット
４０１ 端末側予告送信部
４０２ 端末側試行送信部
４０３ 端末側予告受信部
４０４ 端末側試行受信部
４０５ 端末側判定部
４０６ 端末側結果送信部
５０１ サーバ側予告受信部
５０２ サーバ側試行受信部
５０３ サーバ側判定部
５０４ サーバ側予告送信部
５０５ サーバ側試行送信部
５０６ サーバ側結果受信部
【技術分野】
【０００１】
本発明は、端末装置による通信がＮＡＴ（Network Address Translation）やＮＡＰＴ（Network Address Port Translation）等において制約を受けているかを適切に確認して、できるだけ高速な通信を可能とするのに好適な確認システム、通信システム、確認サーバ装置、確認方法、ならびに、これらをコンピュータにて実現するプログラムに関する。
【背景技術】
【０００２】
従来から、ネットワーク通信機能を持ったコンピュータやゲーム装置を用いて、動画チャットや通信対戦ゲームなどを行う通信システムが提案されている。このような通信システムでは、通信を始めようとする際に、通信相手のＩＰ（Internet Protocol）アドレスがサーバ装置によって紹介され、その後は、紹介されたＩＰアドレスを用いて直接ピアツーピア通信を行う技術も採用されている。
【０００３】
この際に用いられる通信プロトコルとしては、到着確認が行われるが通信効率が低いコネクション型プロトコルと、到着確認が行われないが通信効率が高いコネクションレス型プロトコルと、のいずれかを適宜利用するのが一般的であり、前者としてはＴＣＰ（Transfer Control Protocol）、後者としてはＵＤＰ（User Datagram Protocol）が広く用いられている。
【０００４】
さて、後に掲げる特許文献１においては、端末装置がファイアウォールやルータなどを介してインターネットに接続される場合に、ピアツーピア通信を行うためのアドレスやポート番号を適切に通知する技術が開示されている。
【０００５】
一方、非特許文献１においては、ＮＡＴやＮＡＰＴを使ったプライベートネットワーク内にある端末装置同士がＵＤＰコネクションを確立するための、ＵＤＰホールパンチング（UDP hole punching）という手法が開示されている。
【０００６】
ここで一般に、あらかじめ用意された中継ホストを利用して通信を中継させれば、ファイアウォール越しであっても端末装置同士のＴＣＰ通信は可能となることが多い。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−２６６８６３号公報
【非特許文献】
【０００８】
【非特許文献１】ウィキペディア，「UDP hole punching」の項，http://en.wikipedia.org/wiki/UDP_hole_punching，２００９年１月２８日
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、ピアツーピア通信が可能か否かを適切に判断するとともに、ピアツーピア通信ができない場合には、通信プロトコルや通信形態を適切に変更して、できるだけ高速な通信を可能としたい、との要望は大きい。
【００１０】
本発明は、上記のような課題を解決するもので、端末装置による通信がＮＡＴやＮＡＰＴ等において制約を受けているかを適切に確認して、できるだけ高速な通信を可能とするのに好適な確認システム、通信システム、確認サーバ装置、確認方法、ならびに、これらをコンピュータにて実現するプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
以上の目的を達成するため、本発明の原理にしたがって、下記の発明を開示する。
【００１２】
本発明の第１の観点に係る確認システムは、サーバ装置、端末装置と、を備える。
【００１３】
ここで、サーバ装置は、第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能であり、サーバ側予告受信部、サーバ側試行受信部、サーバ側判定部、サーバ側予告送信部、サーバ側試行送信部を備える。
【００１４】
一方、端末装置は、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能であり、端末側予告送信部、端末側試行送信部、端末側予告受信部、端末側試行受信部、端末側判定部を備える。
【００１５】
そして、サーバ装置と、端末装置と、が、コネクション型プロトコル通信可能に接続される。
【００１６】
コネクション型プロトコルとしては、典型的にはＴＣＰが利用され、コネクションレス型プロトコルとしては、典型的にはＵＤＰが利用される。一般に、コネクション型プロトコルは、コネクションレス型プロトコルよりも通信効率が低いが、セキュリティを考慮した場合、コネクションレス型プロトコルが利用できなくとも、コネクション型プロトコルが利用できるように、ファイアウォール等で設定されていることが多い。
【００１７】
そこで、本発明では、これらのプロトコルの利用可能性を、以下のように判定する。
【００１８】
まず、端末装置において、端末側予告送信部は、第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信し、端末側試行送信部は、第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する。
【００１９】
サーバ装置と端末装置とはコネクション型プロトコル通信が可能に接続されているので、予告パケットは、ほぼ確実に、サーバ装置に到着する。
【００２０】
一方、サーバ装置と端末装置とは、コネクションレス型プロトコル通信が可能か否かは不明である。したがって、試行パケットがサーバ装置に到着するか否かはわからない。
【００２１】
典型的には、端末装置は、予告パケットを送信し、当該予告パケットがサーバ装置に到着したことを確認してから、試行パケットを送信する。
【００２２】
一方、サーバ装置において、サーバ側予告受信部は、第１のアドレスを介して、端末装置から送信された予告パケットを受信し、サーバ側試行受信部は、予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、第１のアドレスを介して、端末装置から送信された試行パケットの受信を試みる。
【００２３】
上記のように、端末装置は、予告パケットと試行パケットを第１のアドレスに宛に送信するが、予告パケットは、ほぼ確実にサーバ装置に到着する。そこで、サーバ装置は、予告パケットが到着すると、サーバ側タイムアウト期間が経過するか、試行パケットが到着するまで、待機する。
【００２４】
そして、サーバ側判定部は、試行パケットが受信された場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定する。
【００２５】
コネクションレス型プロトコル通信によるパケットの送信が不可能である典型的な場合は、端末装置がファイアウォールを介してサーバ装置に接続されており、ファイアウォールにおいて、コネクションレス型プロトコル通信によるパケットの送出が禁止されている場合である。
【００２６】
本発明において、端末装置が通信を行う際の「外部」すなわち「他の通信機器」には、サーバ装置のほか、他の端末装置等がありうる。本発明では、サーバ装置との通信が可能か否かの判断結果を、そのまま、「外部」すなわち「他の通信機器」との通信可能か否かの推定結果とする。
【００２７】
すなわち、本発明では、「他の通信機器」のひとつであるサーバ装置との通信が可能であれば、「外部」「他の通信機器」のひとつである他の端末装置との通信も可能であると判断する。
【００２８】
一方、本発明では、「他の通信機器」のひとつであるサーバ装置との通信ができなければ、「外部」「他の通信機器」のひとつである他の端末装置との通信もできない、と判断するのである。
【００２９】
なお、後述するように、本発明では、外部から端末装置への通信の可否と、端末装置から外部への通信の可否と、を、区別して確認する点にも、特徴がある。
【００３０】
さらに、サーバ側予告送信部は、第１のアドレスから端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信する。
【００３１】
上記のように、サーバ装置と端末装置とは、コネクション型プロトコル通信が可能に接続されているので、当該予告パケットは、端末装置に、ほぼ確実に到着する。
【００３２】
そして、サーバ側試行送信部は、第２のアドレスから端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信する。
【００３３】
典型的には、サーバ装置から送信した予告パケットが端末装置に到着したことを確認してから、試行パケットを送信する。
【００３４】
なお、予告パケットを送信するアドレスと、試行パケットを送信するアドレスと、が、異なる点が、本発明の特徴である。
【００３５】
すると、端末装置において、端末側予告受信部は、サーバ装置から第１のアドレスを介して送信された予告パケットを受信し、端末側試行受信部は、予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、サーバ装置から第２のアドレスを介して送信された試行パケットの受信を試みる。
【００３６】
これらの処理は、上記のサーバ装置における処理と同様であるが、予告パケットの送信元と試行パケットの送信元のアドレスが異なる点が特徴である。
【００３７】
ＵＤＰホールパンチングの技術等では、ＬＡＮの内部から外部へパケットを送出することがあった場合に、その送出先をある程度信頼できるものと仮定して、当該送出先から送信されたパケットの流入を、一定期間認める手法があるが、このような手法は、セキュリティ上の問題があり、採用できないことも多い。そこで、より一層きめ細かい分析を可能とするため、サーバ装置が配置されている外部から端末装置が配置されている内部へのパケットの流入が可能かどうかを、異なるアドレスを用いて調べるのである。
【００３８】
そこで、端末側判定部は、試行パケットが受信された場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する。
【００３９】
すなわち、端末装置は、第２のアドレスからのパケットの流入が可能か否かによって、任意のアドレスからのパケットの流入が可能か否かを判定する。本手法では、サーバ装置から予告パケットが送信される以前は、端末装置もサーバ装置も第２のアドレスを用いた通信は行っていない。したがって、第２のアドレスからのパケットの受信ができれば、任意のアドレスからのパケットの受信ができる可能性は、極めて高いものと考えられる。
【００４０】
本発明によれば、端末装置からのコネクションレス型プロトコル通信によるパケットの送信が可能か否か、他の通信機器からのコネクションレス型プロトコル通信によるパケットの受信が端末装置で可能か否か、を適切に判定することができるようになる。
【００４１】
また、本発明の確認システムにおいて、端末装置は、第１のアドレスもしくは第２のアドレスに対して、コネクション型プロトコル通信により、端末側判定部による判定結果を指定する判定結果パケットを送信する端末側結果送信部をさらに備え、サーバ装置は、第１のアドレスもしくは第２のアドレスを介して、端末装置から送信された判定結果パケットを受信するサーバ側結果受信部をさらに備えるように構成することができる。
【００４２】
本発明は、コネクションレス型通信の端末装置での送信ならびに受信が可能か否かの情報をサーバ装置に集めるものである。
【００４３】
本発明を、たとえば、対戦ゲームのマッチングサーバに適用する場合、紹介する端末装置がどのようなプロトコルで通信可能か、を調べることにより、紹介する端末装置のそれぞれに、送受に利用するプロトコルを知らせれば、両端末装置は、効率の良いプロトコルで通信ができるようになる。
【００４４】
したがって、本発明によれば、端末装置の送受の状況を、サーバ装置において確認することができるようになる。
【００４５】
また、本発明の確認システムにおいて、サーバ装置の第１のアドレスならびに第２のアドレス、および、端末装置のアドレスは、いずれもＩＰ（Internet Protocol）アドレスであり、コネクション型プロトコルは、ＴＣＰ（Transmission Control Protocol）であり、コネクションレス型プロトコルは、ＵＤＰ（User Datagram Protocol）であるように構成することができる。
【００４６】
本発明は、上記発明の好適実施形態であり、広く利用されている通信プロトコルを採用するものである。
【００４７】
また、本発明においては、通信に用いるポート番号は、各プロトコルについて、定数とするのが典型的である。ポート番号を定数とすることによって、ファイアウォールの設定が容易になる。また、ポート番号を定数とすれば、外部からの流入を認めるポート番号を狭い範囲に抑制することができるので、広範なポートを開放しなければならないＵＰｎＰ（Universal Plug and Play）に比べて、セキュリティを向上させることができる。
【００４８】
本発明のその他の観点に係る確認システムは、サーバ装置と、第１の端末装置と、第２の端末装置と、を備え、以下のように構成する。
【００４９】
すなわち、サーバ装置ならびに第１の端末装置は、上記の確認システムにおけるサーバ装置ならびに端末装置として機能する。また、サーバ装置ならびに第２の端末装置は、上記の確認システムにおけるサーバ装置ならびに端末装置として機能する。
【００５０】
これらの機能によって、サーバ装置は、第１の端末装置と第２の端末装置のそれぞれにおいて、コネクションレス型プロトコル通信によるパケットの送受のそれぞれが可能であるか否かを知得することができる。
【００５１】
そして、サーバ装置は、第１の端末装置と第２の端末装置との間のパケットの送受について、
（ａ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が可能であると判定され、かつ、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクションレス型プロトコル通信を介して行い、
（ｂ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が不可能であると判定され、もしくは、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が不可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクション型プロトコル通信を介して行う
ように、第１の端末装置と第２の端末装置とに指示する。
【００５２】
すなわち、第１の端末装置と第２の端末装置の間でコネクションレス型プロトコル通信が可能か否かを片道ごとに判定し、可能である場合は、効率は良いが確実性の低いコネクションレス型プロトコル通信を採用し、不可能である場合には、効率は良くないが確実性の高いコネクション型プロトコル通信を採用するのである。
【００５３】
本発明によれば、通信可能性に基づいて、端末装置同士の通信を効率良く設定することができるようになる。
【００５４】
また、本発明の通信システムにおいて、第１の端末装置と第２の端末装置との間のパケットの送受が、直接コネクション型プロトコル通信を介して行うことができない場合、当該パケットの送受を、サーバ装置もしくは所定のプロキシサーバ装置に中継させてコネクション型プロトコル通信により行うように構成することができる。
【００５５】
すなわち、第１の端末装置と第２の端末装置との間のパケットの送受の片道もしくは往復において、コネクション型プロトコル通信を採用することとなった場合に、直接端末装置同士の通信ができないことがありうる。
【００５６】
たとえば、端末装置から他の通信機器に情報を問い合わせるプル型の通信は可能であるが、端末装置へ他の通信機器から情報を流し込むプッシュ型の通信の受入が不可能である場合である。
【００５７】
このような場合には、当該サーバ装置やプロキシサーバ装置により実現される中継サーバを利用し、パケットを受け入れる側の端末装置から中継サーバに問い合わせを行って、パケットを入手する形態で、パケットの送受を行うのである。
【００５８】
本発明によれば、パケットの送受の態様をより一層きめ細かく管理することができ、できるだけ効率良い通信方式を採用しつつ、通信制限が厳しい端末装置同士であっても、相互の通信を可能とすることができるようになる。
【００５９】
特に、通信が可能か否かの判断を詳細かつ適切に行うことにより、通信の片道のみ中継し、他方は直接通信させるなど、きめ細かい制御が可能となり、中継ホストをできるだけ利用せず、直接ピアツーピア通信によって効率良く通信を行う可能性を増やすことができるようになる。
【００６０】
本発明のその他の観点に係る確認サーバ装置は、上記通信システムにおけるサーバ装置である。
【００６１】
本発明のその他の観点に係る確認方法は、第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置と、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、を備え、サーバ装置と、端末装置と、が、コネクション型プロトコル通信可能に接続される確認システムにおいて、サーバ装置と、端末装置と、が実行する方法である。
【００６２】
ここで、端末装置は、端末側予告送信部、端末側試行送信部、端末側予告受信部、端末側試行受信部、端末側判定部を備え、サーバ装置は、サーバ側予告受信部、サーバ側試行受信部、サーバ側判定部、サーバ側予告送信部、サーバ側試行送信部を備える。
【００６３】
そして、本確認方法は、端末側予告送信工程、端末側試行送信工程、サーバ側予告受信工程、サーバ側試行受信工程、サーバ側判定工程、サーバ側予告送信工程、サーバ側試行送信工程、端末側予告受信工程、端末側試行受信工程、端末側判定工程を備える。
【００６４】
ここで、端末装置において、端末側予告送信工程では、端末側予告送信部が、第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信し、端末側試行送信工程では、端末側試行送信部が、第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する。
【００６５】
一方、サーバ装置において、サーバ側予告受信工程では、サーバ側予告受信部が、第１のアドレスを介して、端末装置から送信された予告パケットを受信し、サーバ側試行受信工程では、サーバ側試行受信部が、予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、第１のアドレスを介して、端末装置から送信された試行パケットの受信を試み、サーバ側判定工程では、サーバ側判定部が、試行パケットが受信された場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定する。
【００６６】
さらに、サーバ装置において、サーバ側予告送信工程では、サーバ側予告送信部が、第１のアドレスから端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信し、サーバ側試行送信工程では、サーバ側試行送信部が、第２のアドレスから端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信する。
【００６７】
さらに、端末装置において、端末側予告受信工程では、端末側予告受信部が、サーバ装置から第１のアドレスを介して送信された予告パケットを受信し、端末側試行受信工程では、端末側試行受信部が、予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、サーバ装置から第２のアドレスを介して送信された試行パケットの受信を試み、端末側判定工程では、端末側判定部が、試行パケットが受信された場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する。
【００６８】
本発明のその他の観点に係るプログラムは、サーバ用プログラムと、端末用プログラムと、を備え、サーバ用プログラムは、サーバ用コンピュータを、上記のサーバ装置として機能させ、端末用プログラムは、端末用コンピュータを、上記の端末装置として機能させるように構成する。
【００６９】
また、本発明のプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、半導体メモリ等のコンピュータ読取可能な情報記憶媒体に記録することができる。
【００７０】
上記プログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網を介して配布・販売することができる。また、上記情報記憶媒体は、コンピュータとは独立して配布・販売することができる。
【発明の効果】
【００７１】
本発明によれば、サーバ装置と複数の端末装置との間で、効率よく通信を行うのに好適な確認システム、通信システム、確認サーバ装置、確認方法ならびに、これらをコンピュータにて実現するためのプログラムを提供することができる。
【図面の簡単な説明】
【００７２】
【図１】プログラムを実行することにより、本実施形態の確認システムにおける端末装置として機能しうる典型的な情報処理装置の概要構成を示す模式図である。
【図２】本実施形態に係るサーバ装置と、端末装置と、の様子を示す説明図である。
【図３】確認処理の際に、１台の端末装置と、確認サーバ装置と、の間で行われる通信の様子を示すセッション図である。
【図４】本実施形態に係る端末装置の構成を示す模式図である。
【図５】本実施形態に係る確認サーバ装置の構成を示す模式図である。
【図６】本実施形態に係る端末装置にて実行される端末処理の制御の流れを示すフローチャートである。
【図７】本実施形態に係る確認サーバ装置にて実行されるサービス処理の制御の流れを示すフローチャートである。
【発明を実施するための形態】
【００７３】
以下に本発明の実施形態を説明する。以下では、理解を容易にするため、ゲーム用の情報処理装置を利用して本発明が実現される実施形態を説明するが、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。
【００７４】
したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
【実施例１】
【００７５】
図１は、プログラムを実行することにより、本実施形態の確認システムにおける端末装置として機能しうる典型的な情報処理装置の概要構成を示す模式図である。以下、本図を参照して説明する。
【００７６】
情報処理装置１００は、ＣＰＵ（Central Processing Unit）１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、インターフェース１０４と、コントローラ１０５と、外部メモリ１０６と、画像処理部１０７と、ＤＶＤ−ＲＯＭ（Digital Versatile Disc ROM）ドライブ１０８と、ＮＩＣ（Network Interface Card）１０９と、音声処理部１１０と、マイク１１１と、を備えるように構成することができる。各種の入出力装置は、適宜省略することができる。
【００７７】
ゲーム用のプログラムおよびデータを記憶したＤＶＤ−ＲＯＭをＤＶＤ−ＲＯＭドライブ１０８に装着して、情報処理装置１００の電源を投入することにより、当該プログラムが実行され、本実施形態の端末装置が実現される。
【００７８】
また、携帯型ゲーム機においては、携帯可能とするために、ＤＶＤ−ＲＯＭドライブ１０８を利用するのではなく、ＲＯＭカセット用スロットを利用することも可能である。この場合、プログラムが記録されたＲＯＭカセットを挿入して、当該プログラムを実行することで、本実施形態の端末装置が実現される。
【００７９】
なお、端末装置から専用サーバ装置に接続することにより対戦するゲーム機を紹介してもらった後、両者の間で通信をしてゲームを進めるようなシステムにおいては、ゲーム機とは異なるサーバ装置を用意することとなるが、このようなサーバ装置は、計算能力の違いや機器構成に少々の相違はあるものの、本質的には、情報処理装置１００と同様の構成である。ロビーサーバ、マッチングサーバ、中継サーバ等のほか、本発明の確認サーバ装置としては、情報処理装置１００と同様の構成ではあるが性能がより高いサーバ用コンピュータを利用するのが一般的である。
【００８０】
さて、ＣＰＵ １０１は、情報処理装置１００全体の動作を制御し、各構成要素と接続され制御信号やデータをやりとりする。また、ＣＰＵ １０１は、レジスタ（図示せず）という高速アクセスが可能な記憶域に対してＡＬＵ（Arithmetic Logic Unit）（図示せず）を用いて加減乗除等の算術演算や、論理和、論理積、論理否定等の論理演算、ビット和、ビット積、ビット反転、ビットシフト、ビット回転等のビット演算などを行うことができる。さらに、マルチメディア処理対応のための加減乗除等の飽和演算や、三角関数等、ベクトル演算などを高速に行えるように、ＣＰＵ １０１自身が構成されているものや、コプロセッサを備えて実現するものがある。
【００８１】
ＲＯＭ １０２には、電源投入直後に実行されるＩＰＬ（Initial Program Loader）が記録され、これが実行されることにより、ＤＶＤ−ＲＯＭに記録されたプログラムをＲＡＭ １０３に読み出してＣＰＵ １０１による実行が開始される。また、ＲＯＭ １０２には、情報処理装置１００全体の動作制御に必要なオペレーティングシステムのプログラムや各種のデータが記録される。
【００８２】
ＲＡＭ １０３は、データやプログラムを一時的に記憶するためのもので、ＤＶＤ−ＲＯＭから読み出したプログラムやデータ、その他ゲームの進行やチャット通信に必要なデータが保持される。また、ＣＰＵ １０１は、ＲＡＭ １０３に変数領域を設け、当該変数に格納された値に対して直接ＡＬＵを作用させて演算を行ったり、ＲＡＭ １０３に格納された値を一旦レジスタに格納してからレジスタに対して演算を行い、演算結果をメモリに書き戻す、などの処理を行う。
【００８３】
インターフェース１０４を介して接続されたコントローラ１０５は、ユーザがゲーム実行の際に行う操作入力を受け付ける。
【００８４】
なお、コントローラ１０５は、必ずしも情報処理装置１００に対して外付けにされている必要はなく、一体に形成されていても良い。
【００８５】
携帯可能な端末装置のコントローラ１０５は、各種のボタンやスイッチから構成され、これらの押圧操作を操作入力として扱う。このほか、タッチスクリーンを利用した情報処理装置１００では、ユーザがペンや指を利用してタッチスクリーンをなぞった軌跡を操作入力として扱う。
【００８６】
インターフェース１０４を介して着脱自在に接続された外部メモリ１０６には、ゲーム等のプレイ状況（過去の成績等）を示すデータ、ゲームの進行状態を示すデータ、ネットワーク対戦の場合のチャット通信のログ（記録）のデータなどが書き換え可能に記憶される。ユーザは、コントローラ１０５を介して指示入力を行うことにより、これらのデータを適宜外部メモリ１０６に記録することができる。
【００８７】
ＤＶＤ−ＲＯＭドライブ１０８に装着されるＤＶＤ−ＲＯＭには、ゲームを実現するためのプログラムとゲームに付随する画像データや音声データが記録される。ＣＰＵ １０１の制御によって、ＤＶＤ−ＲＯＭドライブ１０８は、これに装着されたＤＶＤ−ＲＯＭに対する読み出し処理を行って、必要なプログラムやデータを読み出し、これらはＲＡＭ １０３等に一時的に記憶される。
【００８８】
画像処理部１０７は、ＤＶＤ−ＲＯＭから読み出されたデータをＣＰＵ １０１や画像処理部１０７が備える画像演算プロセッサ（図示せず）によって加工処理した後、これを画像処理部１０７が備えるフレームメモリ（図示せず）に記録する。フレームメモリに記録された画像情報は、所定の同期タイミングでビデオ信号に変換され画像処理部１０７に接続されるモニタ（図示せず）へ出力される。これにより、各種の画像表示が可能となる。
【００８９】
携帯可能なゲーム機のモニタとしては、小型の液晶ディスプレイを利用するのが典型的であり、コントローラ１０５としてタッチスクリーンを利用する場合には、当該タッチスクリーンの表示パネルがモニタとして機能する。自宅で遊ぶためのゲーム機のモニタとしては、ＣＲＴ（Cathode Ray Tube）やプラズマディスプレイなどの表示装置を利用することも可能である。
【００９０】
画像演算プロセッサは、２次元の画像の重ね合わせ演算やαブレンディング等の透過演算、各種の飽和演算を高速に実行できる。
【００９１】
また、仮想３次元空間に配置され、各種のテクスチャ情報が付加されたポリゴン情報を、Ｚバッファ法によりレンダリングして、所定の視点位置から仮想３次元空間に配置されたポリゴンを所定の視線の方向へ俯瞰したレンダリング画像を得る演算の高速実行も可能である。
【００９２】
さらに、ＣＰＵ １０１と画像演算プロセッサが協調動作することにより、文字の形状を定義するフォント情報にしたがって、文字列を２次元画像としてフレームメモリへ描画したり、各ポリゴン表面へ描画することが可能である。
【００９３】
ＮＩＣ １０９は、情報処理装置１００をインターネット等のコンピュータ通信網（図示せず）に接続するためのものであり、ＬＡＮを構成する際に用いられる１０ＢＡＳＥ−Ｔ／１００ＢＡＳＥ−Ｔ規格にしたがうものや、電話回線を用いてインターネットに接続するためのアナログモデム、ＩＳＤＮ（Integrated Services Digital Network）モデム、ＡＤＳＬ（Asymmetric Digital Subscriber Line）モデム、ケーブルテレビジョン回線を用いてインターネットに接続するためのケーブルモデム等と、これらとＣＰＵ １０１との仲立ちを行うインターフェース（図示せず）により構成される。
【００９４】
音声処理部１１０は、ＤＶＤ−ＲＯＭから読み出した音声データをアナログ音声信号に変換し、これに接続されたスピーカ（図示せず）から出力させる。また、ＣＰＵ １０１の制御の下、ゲームの進行の中で発生させるべき効果音や楽曲データを生成し、これに対応した音声をスピーカや、ヘッドホン（図示せず）、イヤフォン（図示せず）から出力させる。
【００９５】
音声処理部１１０では、ＤＶＤ−ＲＯＭに記録された音声データがＭＩＤＩデータである場合には、これが有する音源データを参照して、ＭＩＤＩデータをＰＣＭデータに変換する。また、ADPCM形式やOgg Vorbis形式等の圧縮済音声データである場合には、これを展開してＰＣＭデータに変換する。ＰＣＭデータは、そのサンプリング周波数に応じたタイミングでＤ／Ａ（Digital/Analog）変換を行って、スピーカに出力することにより、音声出力が可能となる。
【００９６】
さらに、情報処理装置１００には、インターフェース１０４を介してマイク１１１を接続することができる。この場合、マイク１１１からのアナログ信号に対しては、適当なサンプリング周波数でＡ／Ｄ変換を行い、ＰＣＭ形式のディジタル信号として、音声処理部１１０でのミキシング等の処理ができるようにする。
【００９７】
このほか、情報処理装置１００は、ハードディスク等の大容量外部記憶装置を用いて、ＲＯＭ １０２、ＲＡＭ １０３、外部メモリ１０６、ＤＶＤ−ＲＯＭドライブ１０８に装着されるＤＶＤ−ＲＯＭ等と同じ機能を果たすように構成してもよい。
【００９８】
また、ユーザからの文字列の編集入力を受け付けるためのキーボードや、各種の位置の指定および選択入力を受け付けるためのマウスなどを接続する形態も採用することができる。また、本実施形態の情報処理装置１００にかえて、汎用のパーソナルコンピュータを利用することもできる。
【００９９】
以上で説明した情報処理装置１００は、いわゆるコンシューマ向けゲーム機に相当するものであるが、携帯電話、携帯ゲーム機器、カラオケ装置、一般的なビジネス用コンピュータなど、種々の計算機上で本発明の確認サーバ装置や端末装置を実現することが可能である。
【０１００】
たとえば、一般的なコンピュータは、上記情報処理装置１００と同様に、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＤＶＤ−ＲＯＭドライブ、および、ＮＩＣを備え、情報処理装置１００よりも簡易な機能を備えた画像処理部を備え、外部記憶装置としてハードディスクを有する他、フレキシブルディスク、光磁気ディスク、磁気テープ等が利用できるようになっている。また、コントローラ１０５ではなく、キーボードやマウスなどを入力装置として利用する。
【０１０１】
図２は、本実施形態に係る確認サーバ装置と、端末装置とからなる通信システムの様子を示す説明図である。以下、本図を参照して説明する。
【０１０２】
通信システム２０１は、１台の確認サーバ装置２２１と、２台の端末装置２４１と、を備え、これらはインターネット２６１に接続されている。
【０１０３】
２台の端末装置２４１は、確認サーバ装置２２１の紹介を受けて、通信の準備を始める。すなわち、確認サーバ装置２２１は、通信対戦ゲームにおけるロビーサーバとして機能する。
【０１０４】
したがって、各端末装置２４１に電源が投入され、インターネット２６１への接続が行われると、端末装置２４１から確認サーバ装置２２１へその旨の通知がなされるので、確認サーバ装置２２１では、端末装置２４１の通信がどのようなプロトコルでどのように可能か、を判定するための確認処理が実行されることになる。
【０１０５】
なお、本実施形態では、コネクション型プロトコルとしてＴＣＰを、コネクションレス型プロトコルとしてＵＤＰを、それぞれ採用する。また、確認サーバ装置２２１や端末装置２４１のアドレスとして、ＩＰアドレスを採用する。
【０１０６】
また、通信の際に利用するポートは、ＴＣＰ、ＵＤＰのそれぞれの場合において、あらかじめ定められたポート番号を利用することとする。
【０１０７】
図３は、確認処理の際に、１台の端末装置２４１と、確認サーバ装置２２１と、の間で行われる通信の様子を示すセッション図である。以下、本図を参照して説明する。
【０１０８】
端末装置２４１に電源が投入され、インターネット２６１への接続が行われると、端末装置２４１は、自身のＩＰアドレスを発信元として、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）宛に、ＴＣＰにより、予告パケットを送信する（３０１）。
【０１０９】
ここで、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）は、通信対戦ゲームのソフトウェア等によって定義されたものである。また、ポート番号もあらかじめ固定されていることから、端末装置２４１がルータ越しにインターネット２６１に接続されている場合であっても、フィルタリングのルールを適切に設定することによって、通信が可能となる。
【０１１０】
すると、予告パケットを受信した確認サーバ装置２２１は、コネクション通信の規約にしたがい、当該受信を通知するため、端末装置２４１へ確認パケットを送信する（３０２）。
【０１１１】
パケットの送受（３０１、３０２）によって、端末装置２４１から確認サーバ装置２２１への通信が、ＴＣＰによって可能に接続されていることが確認されると、端末装置２４１は、自身のＩＰアドレスを発信元として、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）宛に、ＵＤＰにより、試行パケットを送信する（３０３）。
【０１１２】
ＵＤＰは、コネクションレス型通信プロトコルであるから、当該試行パケットが確認サーバ装置２２１に到着したか否かを、ＵＤＰの規約から知ることはできない。
【０１１３】
確認サーバ装置２２１は、予告パケットを受信し（３０１）、確認パケットを送信して（３０２）から、所定のタイムアウト時間が経過するまで、試行パケットが到着するのを待つ。
【０１１４】
ここで、本図に示すように、試行パケットが確認サーバ装置２２１に到達した場合には、端末装置２４１から「他の任意の通信機器」へ、ＵＤＰによるパケットの送出が可能であると判定する（判定結果ａ）。
【０１１５】
一方、本図に示すものとは異なり、タイムアウト時間が経過するまでに、確認サーバ装置２２１に到達しなかった場合には、端末装置２４１から「他の任意の通信機器」へのＵＤＰによるパケットの送出はできない、と判定する（判定結果ｂ）。
【０１１６】
試行パケットを受信するか、あるいは、所定のタイムアウト時間が経過すると、確認サーバ装置２２１は、予告パケット（３０１）の発信元として指定されたＩＰアドレス宛、すなわち、端末装置２４１宛に、公開ＩＰアドレス（第１のＩＰアドレス）を発信元として、ＴＣＰにより、予告パケットを送信する（３０４）。
【０１１７】
この予告パケットを受信した端末装置２４１は、コネクション通信の規約にしたがい、当該受信を通知するため、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）へ、自身のＩＰアドレスを発信元として、確認パケットを送信する（３０５）。
【０１１８】
パケットの送受（３０４、３０５）によって、確認サーバ装置２２１から端末装置２４１への通信が、ＴＣＰによって可能に接続されていることが確認されると、確認サーバ装置２２１は、非公開ＩＰアドレス（第２のＩＰアドレス）を発信元として、端末装置２４１のＩＰアドレス宛に、ＵＤＰにより、試行パケットを送信する（３０６）。
【０１１９】
ここで、非公開ＩＰアドレス（第２のＩＰアドレス）とは、確認サーバ装置２２１に公開ＩＰアドレス（第１のＩＰアドレス）とは別に割り当てられたものであり、端末装置２４１があらかじめ知得しているものではない。
【０１２０】
確認サーバ装置２２１が有するＮＩＣ １０９に対して、複数のＩＰアドレスを用意することは、現在の技術で可能であり、そのうちの１つを公開情報として広く知得させる一方で、非公開ＩＰアドレスは、適宜変更される可能性がある不定のアドレスとしておく。
【０１２１】
そして、試行パケットを送信する際に発信元のＩＰアドレスとして指定されることで、端末装置２４１に初めて知得されるようにする。ＩＰアドレスをこのように用意しておけば、端末装置２４１側のルータで、あらかじめ非公開ＩＰアドレス専用にＵＤＰ用のポートを空けておくように設定しておくことはできないことになる。
【０１２２】
さて、端末装置２４１は、予告パケットを受信し（３０４）、確認パケットを送信して（３０５）から、所定のタイムアウト時間が経過するまで、試行パケットが到着するのを待つ。
【０１２３】
ここで、本図に示すように、試行パケットが端末装置２４１に到達した場合には、「他の任意の通信機器」からＵＤＰにより送信されたパケットの端末装置２４１による受信が可能であると判定する（判定結果ｃ）。
【０１２４】
一方、本図に示すものとは異なり、タイムアウト時間が経過するまでに、試行パケットが端末装置２４１に到達しなかった場合には、「他の任意の通信機器」からＵＤＰにより送信されたパケットの端末装置２４１による受信はできないと判定する（判定結果ｄ）。
【０１２５】
そして、判定ｃ／ｄの結果を表す結果パケットが端末装置２４１から確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）へ送信され（３０７）、確認サーバ装置２２１から端末装置２４１へ、結果パケットの到着を示す確認パケットが送信される（３０８）。
【０１２６】
これによって、確認サーバ装置２２１は、端末装置２４１のＵＤＰによる通信がどの方向に可能であるか否かを判定することができる。すなわち、端末装置２４１からのＵＤＰパケットの送出については、判定結果ａ／ｂが得られ、端末装置２４１へのＵＤＰパケットの受入については、判定結果ｃ／ｄが得られる。
【０１２７】
確認サーバ装置２２１は、紹介しようとする２台の端末装置２４１のそれぞれに、ＵＤＰパケットの送出および受入が可能であるか否かを、上記のような通信を元に、判定するのである。
【０１２８】
以下、これらの判定を行うための確認サーバ装置２２１の構成と、端末装置２４１の構成と、について、さらに詳細に説明する。
【０１２９】
図４は、本実施形態に係る端末装置２４１の構成を示す模式図である。図５は、本実施形態に係る確認サーバ装置２２１の構成を示す模式図である。以下、これらの図を参照して説明する。
【０１３０】
図４に示すように、端末装置２４１は、端末側予告送信部４０１、端末側試行送信部４０２、端末側予告受信部４０３、端末側試行受信部４０４、端末側判定部４０５、端末側結果送信部４０６を備える。これらの各要素のうち、端末側判定部４０５は、情報処理装置１００のＣＰＵ １０１により実現され、他の要素は、ＣＰＵ １０１の制御の下、ＮＩＣ １０９により実現される。
【０１３１】
図５に示すように、確認サーバ装置２２１は、サーバ側予告受信部５０１、サーバ側試行受信部５０２、サーバ側判定部５０３、サーバ側予告送信部５０４、サーバ側試行送信部５０５、サーバ側結果受信部５０６を備える。これらの各要素のうち、サーバ側判定部５０３は、情報処理装置１００のＣＰＵ １０１により実現され、他の要素は、ＣＰＵ １０１の制御の下、ＮＩＣ １０９により実現される。
【０１３２】
以下、これら各部の機能を、処理の詳細な制御の流れに基づいて説明する。
【０１３３】
さて、図６は、本実施形態に係る端末装置２４１にて実行される端末処理の制御の流れを示すフローチャートである。図７は、本実施形態に係る確認サーバ装置２２１にて実行されるサービス処理の制御の流れを示すフローチャートである。以下、これらの図を参照して説明する。
【０１３４】
まず、端末装置２４１において、電源が投入されたり、通信対戦ゲームが開始されたりすることを契機として、端末処理が開始されると、端末側予告送信部４０１は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）に対して、ＴＣＰにより、予告パケットを送信する（ステップＳ６０１）。
【０１３５】
一方、確認サーバ装置２２１は、電源が投入されると、端末装置２４１からパケットが到達するのを待機する状態となる。ステップＳ６０１において送信された予告パケットが到達したことが検知されたことを契機として、サービス処理が開始され、サーバ側予告受信部５０１が、予告パケットを受信する（ステップＳ７０１）。
【０１３６】
すると、確認サーバ装置２２１は、予告パケットを受信した旨を通知するため、予告パケットの発信元のＩＰアドレスに対して、ＴＣＰにより、確認パケットを送信する（ステップＳ７０２）。
【０１３７】
確認サーバ装置２２１から送信された確認パケットを端末装置２４１が受信すると（ステップＳ６０２）、端末装置２４１の端末側試行送信部４０２は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）に対して、ＵＤＰにより試行パケットを送信する（ステップＳ６０３）。
【０１３８】
一方、確認サーバ装置２２１では、確認パケットを送信した後（ステップＳ７０２）、確認サーバ装置２２１のサーバ側試行受信部５０２は、サーバ側タイムアウト期間が経過するまで待機して、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）を介して、端末装置２４１から送信された試行パケットの受信を試みる（ステップＳ７０３）。
【０１３９】
そして、タイムアウト期間が経過するまでに、試行パケットが受信ができた場合（ステップＳ７０４；Ｙｅｓ）、サーバ側判定部５０３は、「端末装置２４１は、外部（他の通信機器）に対して、ＵＤＰによるパケットの送信が可能である（判定結果ａ）」と判定する（ステップＳ７０５）。
【０１４０】
一方、受信されなかった場合（ステップＳ７０４；Ｎｏ）、サーバ側判定部５０３は、「端末装置２４１は、外部（他の通信機器）に対して、ＵＤＰによるパケットの送信が不可能である（判定結果ｂ）」と判定する（ステップＳ７０６）。
【０１４１】
これらの判定（ステップＳ７０５、Ｓ７０６）が終わると、確認サーバ装置２２１のサーバ側予告送信部５０４は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）から端末装置２４１に対して、ＴＰＣにより、予告パケットを送信する（ステップＳ７０７）。
【０１４２】
すると、端末装置２４１では、端末側予告受信部４０３が、確認サーバ装置２２１から送信された予告パケットを受信して（ステップＳ６０４）、当該受信を通知するため、予告パケットの発信元のＩＰアドレスに対して、ＴＣＰにより、確認パケットを送信する（ステップＳ６０５）。
【０１４３】
端末装置２４１から送信された確認パケットを確認サーバ装置２２１が受信すると（ステップＳ７０８）、確認サーバ装置２２１のサーバ側試行送信部５０５は、非公開ＩＰアドレス（第２のＩＰアドレス）を発信元として、端末装置２４１のＩＰアドレスに対して、ＵＤＰにより試行パケットを送信する（ステップＳ７０９）。
【０１４４】
一方、端末装置２４１では、確認パケットを送信した後（ステップＳ６０５）、端末側試行受信部４０４は、端末側タイムアウト期間が経過するまで待機して、試行パケットの受信を試みる（ステップＳ６０６）。
【０１４５】
これらの処理は、上記の確認サーバ装置２２１における処理と同様であるが、予告パケットの送信元と試行パケットの送信元のアドレスが異なる点が特徴である。
【０１４６】
ＵＤＰホールパンチングの技術等では、ＬＡＮの内部から外部（他の通信機器）へパケットを送出すると、その送出先をある程度信頼できるものと仮定して、当該送出先から送信されたパケットの流入を、一定期間認める手法があるが、このような手法は、セキュリティ上の問題があり、採用できないことも多い。そこで、より一層きめ細かい分析を可能とするため、確認サーバ装置２２１が配置されている外部（他の通信機器）から端末装置２４１が配置されている内部へのパケットの流入が可能かどうかを、異なるアドレスを用いて調べるのである。
【０１４７】
そして、タイムアウト期間が経過するまでに、試行パケットが受信された場合（ステップＳ６０７；Ｙｅｓ）、端末側判定部４０５は、「端末装置２４１は、外部（他の通信機器）からの、ＵＤＰによるパケットの受信が可能である（判定結果ｃ）」と判定する（ステップＳ６０８）。
【０１４８】
一方、タイムアウト期間が経過するまでに、試行パケットが受信されなかった場合（ステップＳ６０７；Ｎｏ）、端末側判定部４０５は、「端末装置２４１は、外部（他の通信機器）からの、ＵＤＰによるパケットの受信が不可能である（判定結果ｄ）」と判定する（ステップＳ６０９）。
【０１４９】
なお、タイムアウト期間は、確認サーバ装置２２１と端末装置２４１とで、異なる値としても良いし、同じ値としても良い。
【０１５０】
すなわち、端末装置２４１は、第２のアドレスからのパケットの流入が可能か否かによって、任意のアドレスからのパケットの流入が可能か否かを判定する。本手法では、確認サーバ装置２２１から予告パケットが送信される以前は、端末装置２４１も確認サーバ装置２２１も第２のアドレスを用いた通信は行っていない。したがって、第２のアドレスからのパケットの受信ができれば、任意のアドレスからのパケットの受信ができる可能性は、極めて高いものと考えられる。
【０１５１】
この後、端末装置２４１において、端末側結果送信部４０６は、確認サーバ装置２２１の公開ＩＰアドレス（第１のＩＰアドレス）に対して、ＴＰＣにより、端末側判定部４０５による判定結果を指定する判定結果パケットを送信する（ステップＳ６１０）。
【０１５２】
これに対して、確認サーバ装置２２１において、サーバ側結果受信部５０６は、確認サーバ装置２２１の端末装置２４１から送信された判定結果パケットを受信する（ステップＳ７１０）。
【０１５３】
そして、当該受信を確認する確認パケットが、確認サーバ装置２２１から送信され（ステップＳ７１１）、これを端末装置２４１が受信することにより（ステップＳ６１１）、これらの処理は終了する。
【０１５４】
各端末装置２４１に対してこれらの処理を行うことにより、確認サーバ装置２２１は、当該端末装置２４１に対する判定結果を収集することができる。
【０１５５】
なお、上記のように、通信に用いるポート番号を各プロトコルについて定数とすると、ファイアウォールの設定が容易になる。また、ポート番号を定数とすれば、外部からの流入を認めるポート番号を狭い範囲に抑制することができるので、広範なポートを開放しなければならないＵＰｎＰに比べて、セキュリティを向上させることができる。
【０１５６】
さて、上記のような端末処理およびサービス処理によって、確認が行われ、判定結果ａ〜ｄが確認サーバ装置２２１に得られると、確認サーバ装置２２１は、マッチングサーバとして機能し、ログインしている端末装置２４１の中から、対戦させる端末装置２４１を２台選択する。そして、その２台の端末装置２４１に、通信に用いるべきＩＰアドレス、および、送信に用いるプロトコル、受信に用いるプロトコル等について通知する。
【０１５７】
ここで、ある端末装置２４１から、別の端末装置２４１への片道のパケットの送受を考えると、以下の４通りの状態がありうる。
（ａ）送信側は、ＵＤＰ送出可能、受信側は、ＵＤＰ受入可能。
（ｂ）送信側は、ＵＤＰ送出可能、受信側は、ＵＤＰ受入不可。
（ｃ）送信側は、ＵＤＰ送出不可、受信側は、ＵＤＰ受入可能。
（ｄ）送信側は、ＵＤＰ送出不可、受信側は、ＵＤＰ受入不可。
【０１５８】
これらの分類において、状態（ａ）では、当該片道の通信において、通信効率の良いＵＤＰが利用可能であるが、状態（ｂ）（ｃ）（ｄ）では、通信効率がＵＤＰに比べて低いＴＣＰを利用しなければならないことになる。
【０１５９】
そこで、２台の端末装置２４１には、パケットの送信とパケットの受信とのそれぞれにおいて、ＵＤＰを利用するか、ＴＣＰを利用するか、を指定する。
【０１６０】
また、予告パケット（３０１）等によって得られたＩＰアドレスを、当該端末装置２４１の通信用のＩＰアドレスとして、相手方の端末装置２４１に通知する。
【０１６１】
端末装置２４１は、マッチングサーバとして機能する確認サーバ装置２２１から通知されたＩＰアドレスを、相手方の端末装置２４１のＩＰアドレスとして使用することになる。
【０１６２】
なお、上記の説明では、ＴＣＰ通信は双方向に可能であることを前提に説明しているが、「流出（３０１、３０２）は可能であるが、流入（３０４、３０５）は不可能である」ようにルータ等を設定することもありうる。このように設定されているか否かは、確認サーバ装置２２１から予告パケットを送信（３０４）してから、所定のタイムアウト時間が経過するまでに、確認パケットが到着するか否か、によって判定が可能である。
【０１６３】
すなわち、「端末装置２４１は、端末装置２４１からの送信を契機とするＴＣＰ通信と、『他の任意の通信機器』からの送信を契機とするＴＣＰ通信と、の２つが可能である（判定結果ｘ）」、あるいは、「端末装置２４１は、端末装置２４１からの送信を契機とするＴＣＰ通信は可能であるが、『他の任意の通信機器』からの送信を契機とするＴＣＰ通信はできない（判定結果ｙ）」のいずれであるかを判定することも可能である。
【０１６４】
両端末装置２４１において、判定結果ｘが得られた場合には、プッシュ型およびプル型の通信が相互に可能である、ということになるから、両端末装置２４１は、ＴＣＰによって、直接ピアツーピアに通信を行うことになる。
【０１６５】
一方、両端末装置２４１において、判定結果ｙが得られた場合には、プル型の通信のみが可能である、ということになる。この場合には、相手方に送るべきパケットを一旦中継サーバに送信し、蓄積させる。中継サーバは、端末装置２４１からの問い合わせがあると、蓄積されているパケットのうち、問い合わせ元の端末装置２４１宛のパケットを応答として返信する。
【０１６６】
端末装置２４１の一方で判定結果ｘが得られ、端末装置２４１の他方で判定結果ｙが得られた場合には、一方の片道については、上記の一方の手法を、他方の片道については、上記の他方の手法を、それぞれ利用すれば良い。
【０１６７】
また、プッシュ型の通信が可能な端末装置２４１に対しては、中継サーバに当該端末装置２４１宛のパケットが到着したら、直ちに当該端末装置２４１に転送することとしても良い。
【０１６８】
中継サーバとしては、上記の確認サーバ装置２２１を利用することができるほか、専用の中継プロキシサーバを利用することとしても良い。後者の場合には、マッチングの際に、中継プロキシサーバのＩＰアドレスを端末装置２４１に知らせるとともに、当該端末装置２４１は、自身宛のパケットをプッシュ型により取得すべきか、プル型により取得すべきか、を指定すれば良い。
【０１６９】
なお、上記の態様では、端末装置２４１同士を紹介する前に、確認サーバ装置２２１が各端末装置２４１におけるパケット送受の能力を判定しているが、以下のような態様を採用することも可能である。
【０１７０】
すなわち、まず最初に、各端末装置２４１同士のＩＰアドレスを紹介してしまう。そして、端末装置２４１同士の間でピアツーピアの通信が可能か否かを実際に調べさせ、通信が可能である場合には、そのまま処理を続行させる。
【０１７１】
一方、通信が不可能である場合には、その結果を確認サーバ装置２２１に通知させる。その上で、確認サーバ装置２２１と各端末装置２４１との間で、上記の確認処理を実行して、中継サーバを利用するか否かを判定するのである。
【産業上の利用可能性】
【０１７２】
本発明によれば、端末装置による通信がＮＡＴやＮＡＰＴ等において制約を受けているかを適切に確認して、できるだけ高速な通信を可能とするのに好適な確認システム、通信システム、確認サーバ装置、確認方法、ならびに、これらをコンピュータにて実現するプログラムを提供することができる。
【符号の説明】
【０１７３】
１００ 情報処理装置
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ インターフェース
１０５ コントローラ
１０６ 外部メモリ
１０７ 画像処理部
１０８ ＤＶＤ−ＲＯＭドライブ
１０９ ＮＩＣ
１１０ 音声処理部
１１１ マイク
２０１ 通信システム
２２１ 確認サーバ装置
２４１ 端末装置
２６１ インターネット
４０１ 端末側予告送信部
４０２ 端末側試行送信部
４０３ 端末側予告受信部
４０４ 端末側試行受信部
４０５ 端末側判定部
４０６ 端末側結果送信部
５０１ サーバ側予告受信部
５０２ サーバ側試行受信部
５０３ サーバ側判定部
５０４ サーバ側予告送信部
５０５ サーバ側試行送信部
５０６ サーバ側結果受信部
【特許請求の範囲】
【請求項１】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置と、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、を備え、前記サーバ装置と、前記端末装置と、が、コネクション型プロトコル通信可能に接続される確認システムであって、
（ａ）前記端末装置は、
前記第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信する端末側予告送信部、
前記第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する端末側試行送信部
を備え、
（ｂ）前記サーバ装置は、
前記第１のアドレスを介して、前記端末装置から送信された前記予告パケットを受信するサーバ側予告受信部、
前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末装置から送信された試行パケットの受信を試みるサーバ側試行受信部、
前記試行パケットが受信された場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定部、
前記第１のアドレスから前記端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信部、
前記第２のアドレスから前記端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信部
を備え、
（ｃ）前記端末装置は、
前記サーバ装置から前記第１のアドレスを介して送信された前記予告パケットを受信する端末側予告受信部、
前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ装置から前記第２のアドレスを介して送信された試行パケットの受信を試みる端末側試行受信部、
前記試行パケットが受信された場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する端末側判定部
をさらに備える
ことを特徴とする確認システム。
【請求項２】
請求項１に記載の確認システムであって、
前記端末装置は、
前記第１のアドレスもしくは前記第２のアドレスに対して、コネクション型プロトコル通信により、前記端末側判定部による判定結果を指定する判定結果パケットを送信する端末側結果送信部
をさらに備え、
前記サーバ装置は、
前記第１のアドレスもしくは前記第２のアドレスを介して、前記端末装置から送信された判定結果パケットを受信するサーバ側結果受信部
をさらに備える
ことを特徴とする確認システム。
【請求項３】
請求項１または２に記載の確認システムであって、
前記サーバ装置の第１のアドレスならびに第２のアドレス、および、前記端末装置のアドレスは、いずれもＩＰ（Internet Protocol）アドレスであり、
前記コネクション型プロトコルは、ＴＣＰ（Transmission Control Protocol）であり、
前記コネクションレス型プロトコルは、ＵＤＰ（User Datagram Protocol）である
ことを特徴とする確認システム。
【請求項４】
サーバ装置と、第１の端末装置と、第２の端末装置と、を備える通信システムであって、
前記サーバ装置ならびに前記第１の端末装置は、請求項２または３に記載の確認システムにおけるサーバ装置ならびに端末装置として機能し、
前記サーバ装置ならびに前記第２の端末装置は、請求項２または３に記載の確認システムにおけるサーバ装置ならびに端末装置として機能し、
前記サーバ装置は、前記第１の端末装置と前記第２の端末装置との間のパケットの送受について、
（ａ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が可能であると判定され、かつ、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクションレス型プロトコル通信を介して行い、
（ｂ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が不可能であると判定され、もしくは、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が不可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクション型プロトコル通信を介して行う
ように、前記第１の端末装置と前記第２の端末装置とに指示する
ことを特徴とする通信システム。
【請求項５】
請求項４に記載の通信システムであって、
前記第１の端末装置と前記第２の端末装置との間のパケットの送受が、直接コネクション型プロトコル通信を介して行うことができない場合、当該パケットの送受を、サーバ装置もしくは所定のプロキシサーバ装置に中継させてコネクション型プロトコル通信により行う
ことを特徴とする通信システム。
【請求項６】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置であって、
前記サーバ装置は、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、コネクション型プロトコル通信可能に接続され、
前記サーバ装置は、
前記第１のアドレスを介して、前記端末装置から送信された前記予告パケットを受信するサーバ側予告受信部、
前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末装置から前記予告パケットの送信の後に送信された試行パケットの受信を試みるサーバ側試行受信部、
前記試行パケットが受信された場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定部、
前記第１のアドレスから前記端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信部、
前記第２のアドレスから前記端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信部、
を備え、
前記端末装置は、前記サーバ装置から前記第１のアドレスを介して送信された前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ装置から前記第２のアドレスを介して送信された試行パケットの受信を試み、前記試行パケットが受信された場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定して、前記端末装置は、前記第１のアドレスもしくは前記第２のアドレスに対して、コネクション型プロトコル通信により、前記端末側判定部による判定結果を指定する判定結果パケットを送信し、
前記サーバ装置は、
前記端末装置から、前記第１のアドレスもしくは前記第２のアドレスに対して、コネクション型プロトコル通信により送信された判定結果を指定する判定結果パケットを受信するサーバ側結果受信部
をさらに備えることを特徴とする確認サーバ装置。
【請求項７】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置と、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、を備え、前記サーバ装置と、前記端末装置と、が、コネクション型プロトコル通信可能に接続される確認システムにおいて、前記サーバ装置と、前記端末装置と、が実行する確認方法であって、前記端末装置は、端末側予告送信部、端末側試行送信部、端末側予告受信部、端末側試行受信部、端末側判定部を備え、前記サーバ装置は、サーバ側予告受信部、サーバ側試行受信部、サーバ側判定部、サーバ側予告送信部、サーバ側試行送信部を備え、前記確認方法は、
（ａ）前記端末装置において、
前記端末側予告送信部が、前記第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信する端末側予告送信工程、
前記端末側試行送信部が、前記第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する端末側試行送信工程
を備え、
（ｂ）前記サーバ装置において、
前記サーバ側予告受信部が、前記第１のアドレスを介して、前記端末装置から送信された前記予告パケットを受信するサーバ側予告受信工程、
前記サーバ側試行受信部が、前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末装置から送信された試行パケットの受信を試みるサーバ側試行受信工程、
前記サーバ側判定部が、前記試行パケットが受信された場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定工程、
前記サーバ側予告送信部が、前記第１のアドレスから前記端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信工程、
前記サーバ側試行送信部が、前記第２のアドレスから前記端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信工程、
を備え、
（ｃ）前記端末装置において、
前記端末側予告受信部が、前記サーバ装置から前記第１のアドレスを介して送信された前記予告パケットを受信する端末側予告受信工程、
前記端末側試行受信部が、前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ装置から前記第２のアドレスを介して送信された試行パケットの受信を試みる端末側試行受信工程、
前記端末側判定部が、前記試行パケットが受信された場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する端末側判定工程
をさらに備える
ことを特徴とする確認方法。
【請求項８】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ用コンピュータをサーバ装置として機能させるサーバ用プログラムと、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末用コンピュータを端末装置として機能させる、端末用プログラムと、を備えるプログラムであって、前記サーバ用コンピュータと、前記端末用コンピュータと、が、コネクション型プロトコル通信可能に接続され、
（ａ）前記端末用プログラムは、前記端末用コンピュータを、
前記第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信する端末側予告送信部、
前記第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する端末側試行送信部
として機能させ、
（ｂ）前記サーバ用プログラムは、前記サーバ用コンピュータを、
前記第１のアドレスを介して、前記端末用コンピュータから送信された前記予告パケットを受信するサーバ側予告受信部、
前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末用コンピュータから送信された試行パケットの受信を試みるサーバ側試行受信部、
前記試行パケットが受信された場合、前記端末用コンピュータは、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末用コンピュータは、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定部、
前記第１のアドレスから前記端末用コンピュータに対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信部、
前記第２のアドレスから前記端末用コンピュータに対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信部
として機能させ、
（ｃ）前記端末用プログラムは、前記端末用コンピュータを、
前記サーバ用コンピュータから前記第１のアドレスを介して送信された前記予告パケットを受信する端末側予告受信部、
前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ用コンピュータから前記第２のアドレスを介して送信された試行パケットの受信を試みる端末側試行受信部、
前記試行パケットが受信された場合、前記端末用コンピュータは、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末用コンピュータは、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する端末側判定部
としてさらに機能させる
ことを特徴とするプログラム。
【請求項１】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置と、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、を備え、前記サーバ装置と、前記端末装置と、が、コネクション型プロトコル通信可能に接続される確認システムであって、
（ａ）前記端末装置は、
前記第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信する端末側予告送信部、
前記第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する端末側試行送信部
を備え、
（ｂ）前記サーバ装置は、
前記第１のアドレスを介して、前記端末装置から送信された前記予告パケットを受信するサーバ側予告受信部、
前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末装置から送信された試行パケットの受信を試みるサーバ側試行受信部、
前記試行パケットが受信された場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定部、
前記第１のアドレスから前記端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信部、
前記第２のアドレスから前記端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信部
を備え、
（ｃ）前記端末装置は、
前記サーバ装置から前記第１のアドレスを介して送信された前記予告パケットを受信する端末側予告受信部、
前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ装置から前記第２のアドレスを介して送信された試行パケットの受信を試みる端末側試行受信部、
前記試行パケットが受信された場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する端末側判定部
をさらに備える
ことを特徴とする確認システム。
【請求項２】
請求項１に記載の確認システムであって、
前記端末装置は、
前記第１のアドレスもしくは前記第２のアドレスに対して、コネクション型プロトコル通信により、前記端末側判定部による判定結果を指定する判定結果パケットを送信する端末側結果送信部
をさらに備え、
前記サーバ装置は、
前記第１のアドレスもしくは前記第２のアドレスを介して、前記端末装置から送信された判定結果パケットを受信するサーバ側結果受信部
をさらに備える
ことを特徴とする確認システム。
【請求項３】
請求項１または２に記載の確認システムであって、
前記サーバ装置の第１のアドレスならびに第２のアドレス、および、前記端末装置のアドレスは、いずれもＩＰ（Internet Protocol）アドレスであり、
前記コネクション型プロトコルは、ＴＣＰ（Transmission Control Protocol）であり、
前記コネクションレス型プロトコルは、ＵＤＰ（User Datagram Protocol）である
ことを特徴とする確認システム。
【請求項４】
サーバ装置と、第１の端末装置と、第２の端末装置と、を備える通信システムであって、
前記サーバ装置ならびに前記第１の端末装置は、請求項２または３に記載の確認システムにおけるサーバ装置ならびに端末装置として機能し、
前記サーバ装置ならびに前記第２の端末装置は、請求項２または３に記載の確認システムにおけるサーバ装置ならびに端末装置として機能し、
前記サーバ装置は、前記第１の端末装置と前記第２の端末装置との間のパケットの送受について、
（ａ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が可能であると判定され、かつ、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクションレス型プロトコル通信を介して行い、
（ｂ）他の通信機器へのコネクションレス型プロトコル通信によるパケットの一方の端末装置による送信が不可能であると判定され、もしくは、他の通信機器からのコネクションレス型プロトコル通信によるパケットの他方の端末装置による受信が不可能であると判定された場合、当該一方の端末装置から当該他方の端末装置へのパケットの送受は、コネクション型プロトコル通信を介して行う
ように、前記第１の端末装置と前記第２の端末装置とに指示する
ことを特徴とする通信システム。
【請求項５】
請求項４に記載の通信システムであって、
前記第１の端末装置と前記第２の端末装置との間のパケットの送受が、直接コネクション型プロトコル通信を介して行うことができない場合、当該パケットの送受を、サーバ装置もしくは所定のプロキシサーバ装置に中継させてコネクション型プロトコル通信により行う
ことを特徴とする通信システム。
【請求項６】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置であって、
前記サーバ装置は、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、コネクション型プロトコル通信可能に接続され、
前記サーバ装置は、
前記第１のアドレスを介して、前記端末装置から送信された前記予告パケットを受信するサーバ側予告受信部、
前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末装置から前記予告パケットの送信の後に送信された試行パケットの受信を試みるサーバ側試行受信部、
前記試行パケットが受信された場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定部、
前記第１のアドレスから前記端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信部、
前記第２のアドレスから前記端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信部、
を備え、
前記端末装置は、前記サーバ装置から前記第１のアドレスを介して送信された前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ装置から前記第２のアドレスを介して送信された試行パケットの受信を試み、前記試行パケットが受信された場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定して、前記端末装置は、前記第１のアドレスもしくは前記第２のアドレスに対して、コネクション型プロトコル通信により、前記端末側判定部による判定結果を指定する判定結果パケットを送信し、
前記サーバ装置は、
前記端末装置から、前記第１のアドレスもしくは前記第２のアドレスに対して、コネクション型プロトコル通信により送信された判定結果を指定する判定結果パケットを受信するサーバ側結果受信部
をさらに備えることを特徴とする確認サーバ装置。
【請求項７】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ装置と、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末装置と、を備え、前記サーバ装置と、前記端末装置と、が、コネクション型プロトコル通信可能に接続される確認システムにおいて、前記サーバ装置と、前記端末装置と、が実行する確認方法であって、前記端末装置は、端末側予告送信部、端末側試行送信部、端末側予告受信部、端末側試行受信部、端末側判定部を備え、前記サーバ装置は、サーバ側予告受信部、サーバ側試行受信部、サーバ側判定部、サーバ側予告送信部、サーバ側試行送信部を備え、前記確認方法は、
（ａ）前記端末装置において、
前記端末側予告送信部が、前記第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信する端末側予告送信工程、
前記端末側試行送信部が、前記第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する端末側試行送信工程
を備え、
（ｂ）前記サーバ装置において、
前記サーバ側予告受信部が、前記第１のアドレスを介して、前記端末装置から送信された前記予告パケットを受信するサーバ側予告受信工程、
前記サーバ側試行受信部が、前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末装置から送信された試行パケットの受信を試みるサーバ側試行受信工程、
前記サーバ側判定部が、前記試行パケットが受信された場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定工程、
前記サーバ側予告送信部が、前記第１のアドレスから前記端末装置に対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信工程、
前記サーバ側試行送信部が、前記第２のアドレスから前記端末装置に対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信工程、
を備え、
（ｃ）前記端末装置において、
前記端末側予告受信部が、前記サーバ装置から前記第１のアドレスを介して送信された前記予告パケットを受信する端末側予告受信工程、
前記端末側試行受信部が、前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ装置から前記第２のアドレスを介して送信された試行パケットの受信を試みる端末側試行受信工程、
前記端末側判定部が、前記試行パケットが受信された場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末装置は、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する端末側判定工程
をさらに備える
ことを特徴とする確認方法。
【請求項８】
第１のアドレスと第２のアドレスとのいずれによってもコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能なサーバ用コンピュータをサーバ装置として機能させるサーバ用プログラムと、１つのアドレスによってコネクション型プロトコル通信およびコネクションレス型プロトコル通信が可能な端末用コンピュータを端末装置として機能させる、端末用プログラムと、を備えるプログラムであって、前記サーバ用コンピュータと、前記端末用コンピュータと、が、コネクション型プロトコル通信可能に接続され、
（ａ）前記端末用プログラムは、前記端末用コンピュータを、
前記第１のアドレスに対して、コネクション型プロトコル通信により、予告パケットを送信する端末側予告送信部、
前記第１のアドレスに対して、コネクションレス型プロトコル通信により試行パケットを送信する端末側試行送信部
として機能させ、
（ｂ）前記サーバ用プログラムは、前記サーバ用コンピュータを、
前記第１のアドレスを介して、前記端末用コンピュータから送信された前記予告パケットを受信するサーバ側予告受信部、
前記予告パケットが受信されてから、サーバ側タイムアウト期間が経過するまで、前記第１のアドレスを介して、前記端末用コンピュータから送信された試行パケットの受信を試みるサーバ側試行受信部、
前記試行パケットが受信された場合、前記端末用コンピュータは、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が可能であると判定し、受信されなかった場合、前記端末用コンピュータは、他の通信機器に対して、コネクションレス型プロトコル通信によるパケットの送信が不可能であると判定するサーバ側判定部、
前記第１のアドレスから前記端末用コンピュータに対して、コネクション型プロトコル通信により、予告パケットを送信するサーバ側予告送信部、
前記第２のアドレスから前記端末用コンピュータに対して、コネクションレス型プロトコル通信により、試行パケットを送信するサーバ側試行送信部
として機能させ、
（ｃ）前記端末用プログラムは、前記端末用コンピュータを、
前記サーバ用コンピュータから前記第１のアドレスを介して送信された前記予告パケットを受信する端末側予告受信部、
前記予告パケットが受信されてから、端末側タイムアウト期間が経過するまで、前記サーバ用コンピュータから前記第２のアドレスを介して送信された試行パケットの受信を試みる端末側試行受信部、
前記試行パケットが受信された場合、前記端末用コンピュータは、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が可能であると判定し、受信されなかった場合、前記端末用コンピュータは、他の通信機器からの、コネクションレス型プロトコル通信によるパケットの受信が不可能であると判定する端末側判定部
としてさらに機能させる
ことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−２０６３８８（Ｐ２０１０−２０６３８８Ａ）
【公開日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願番号】特願２００９−４８１６２（Ｐ２００９−４８１６２）
【出願日】平成２１年３月２日（２００９．３．２）
【出願人】（５０６１１３６０２）株式会社コナミデジタルエンタテインメント (1,441)
【Ｆターム（参考）】
【公開日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願日】平成２１年３月２日（２００９．３．２）
【出願人】（５０６１１３６０２）株式会社コナミデジタルエンタテインメント (1,441)
【Ｆターム（参考）】
[ Back to top ]