(57)【要約】【課題】様々な通信手順に対応する表示制御を簡易に行うことができる通信端末、制御方法、及び制御プログラムを提供する。【解決手段】通信端末１２、１３に対して、略同時期に、Ｐ２Ｐ型の通信を開始する指示が入力される（Ｓ４１、４５）。通信端末１２、１３は、セッションの確立を要求する確立要求パケットを送信する（Ｓ４３、４７）。通信端末１３は、確立要求パケットを送信した後、ＯＫ応答パケットを受信する前に、通信装置１２から確立要求パケットを受信する（Ｓ４９）。通信端末１３は、通信端末１２からセッションの確立の要求があった旨をディスプレイに表示しない。通信端末１３は、通信端末１２から送信されたＡＣＫパケットを受信した場合（Ｓ６９）、通信端末１２とのセッションが確立した旨をディスプレイに表示する（Ｓ７１）。通信端末１２、１３間で、Ｐ２Ｐ通信が開始される。【選択図】図４
2012231359.tif 000002
【特許請求の範囲】
【請求項１】
他の通信端末である相手端末との間でセッションを確立し、通信を行う通信端末であって、
ユーザからの指示に応じ、前記相手端末との間のセッションの確立を、前記相手端末に対して要求する第一要求手段と、
前記第一要求手段において前記相手端末に対してセッションの確立を要求した後、前記相手端末との間のセッションを確立する第一確立手段と、
前記相手端末との間のセッションの確立の要求を、前記相手端末から受け付ける第一受付手段と、
前記第一受付手段において前記相手端末からセッションの確立の要求を受け付けた後、前記相手端末との間のセッションを確立する第二確立手段と、
前記第一要求手段において前記相手端末に対してセッションの確立を要求してから、前記第一確立手段において前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第一通知情報を、通信を行う度に表示手段に表示する第一表示制御手段と、
前記第一受付手段において前記相手端末からセッションの確立の要求を受け付けてから、前記第二確立手段において前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第二通知情報を、通信を行う度に前記表示手段に表示する第二表示制御手段と
を備え、
前記第一要求手段において、前記相手端末に対してセッションの確立を要求した後、前記第一確立手段において、前記相手端末との間のセッションを確立する前に、前記第一受付手段において、前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一表示制御手段は、前記第一通知情報を前記表示手段に表示し、前記第二表示制御手段は、前記第二通知情報を前記表示手段に表示しないことを特徴とする通信端末。
【請求項２】
前記相手端末とは別の前記他の通信端末である要求端末から、前記相手端末との間のセッションの確立の要求を受け付ける第二受付手段と、
前記第二受付手段において、前記要求端末から前記要求を受け付けた場合に、前記相手端末との間のセッションの確立を、前記相手端末に対して要求する第二要求手段と、
前記第二要求手段において前記相手端末にセッションの確立を要求した後、前記相手端末との間のセッションを確立する第三確立手段と
を備え、
前記第二要求手段において前記相手端末に対してセッションの確立を要求してから、前記第三確立手段において前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記第二表示制御手段は、前記第二通知情報を前記表示手段に表示し、前記第一表示制御手段は、前記第一通知情報を前記表示手段に表示しないことを特徴とする請求項１に記載の通信端末。
【請求項３】
前記第一要求手段において前記相手端末にセッションの確立を要求した後、前記第一確立手段において前記相手端末との間のセッションを確立する前に、前記第一受付手段において前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一確立手段は、前記相手端末との間のセッションを確立することを特徴とする請求項１又は２に記載の通信端末。
【請求項４】
ユーザからの指示に応じ、他の通信端末である相手端末との間のセッションの確立を、前記相手端末に対して要求する第一要求ステップと、
前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求した後、前記相手端末との間のセッションを確立する第一確立ステップと、
前記相手端末との間のセッションの確立の要求を、前記相手端末から受け付ける第一受付ステップと、
前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けた後、前記相手端末との間のセッションを確立する第二確立ステップと、
前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求してから、前記第一確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第一通知情報を、通信を行う度に表示手段に表示する第一表示制御ステップと、
前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けてから、前記第二確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第二通知情報を、通信を行う度に前記表示手段に表示する第二表示制御ステップと
を備え、
前記第一要求ステップにおいて、前記相手端末に対してセッションの確立を要求した後、前記第一確立ステップにおいて、前記相手端末との間のセッションを確立する前に、前記第一受付ステップにおいて、前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一表示制御ステップは、前記第一通知情報を前記表示手段に表示し、前記第二表示制御ステップは、前記第二通知情報を前記表示手段に表示しないことを特徴とする制御方法。
【請求項５】
ユーザからの指示に応じ、他の通信端末である相手端末との間のセッションの確立を、前記相手端末に対して要求する第一要求ステップと、
前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求した後、前記相手端末との間のセッションを確立する第一確立ステップと、
前記相手端末との間のセッションの確立の要求を、前記相手端末から受け付ける第一受付ステップと、
前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けた後、前記相手端末との間のセッションを確立する第二確立ステップと、
前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求してから、前記第一確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第一通知情報を、通信を行う度に表示手段に表示する第一表示制御ステップと、
前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けてから、前記第二確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第二通知情報を、通信を行う度に前記表示手段に表示する第二表示制御ステップと
をコンピュータに実行させるための制御プログラムであって、
前記第一要求ステップにおいて、前記相手端末に対してセッションの確立を要求した後、前記第一確立ステップにおいて、前記相手端末との間のセッションを確立する前に、前記第一受付ステップにおいて、前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一表示制御ステップは、前記第一通知情報を前記表示手段に表示し、前記第二表示制御ステップは、前記第二通知情報を前記表示手段に表示しないことを特徴とする制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼制御通信を行う通信端末、制御方法、及び制御プログラムに関する。
【背景技術】
【０００２】
サーバ等の呼制御装置を介して呼制御通信を行い、相手方の通信端末との間のセッションを確立することで、相手方の通信端末とPeer to Peer（Ｐ２Ｐ）通信を開始する通信端末が知られている。呼制御通信では、発呼側の通信端末から相手方の通信端末に対して、セッションの確立を要求する要求パケットが送信される。以下、発呼側の通信端末を発呼端末という。相手方の通信端末を着呼端末という。要求パケットを受信した着呼端末は、発呼端末との間のセッションの確立を許可する場合、応答パケットを発呼端末に対して送信する。発呼端末は、応答パケットを受信する。以上の手順を経て、発呼端末と着呼端末との間のセッションは確立し、Ｐ２Ｐ通信が開始される。
【０００３】
通信端末は、他の通信端末との間の呼制御通信の状況をユーザに通知するための表示画面を、表示部に表示する。例えば、発呼端末から送信された要求パケットを着呼端末が受信した場合、セッションの確立が要求された旨を通知する表示画面が、着呼端末の表示部に表示される。又例えば、着呼端末から送信された応答パケットを発呼端末が受信した場合、セッションが確立した旨を通知する表示画面が、発呼端末の表示部に表示される。
【０００４】
呼制御通信時のパケットの送信タイミングによっては、上述した正規の通信手順とは異なる通信手順で呼制御通信が行われる場合がある。例えば特許文献１では、同時期に、二つの通信端末から相互に要求パケットが送信される場合が想定されている。この場合、通信端末は、自身が送信した要求パケットに対し、応答パケットを受信する前に、相手方の通信端末から要求パケットを受信することになる。これに対して特許文献１では、二つの通信端末のうち優先順位の高い側の通信端末が、着呼端末に対して要求パケットを再送する。これによって、二つの通信端末から同時期に要求パケットが送信された場合でも、通信端末間のセッションは確立される。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２１２９４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
通信端末は、正規の通信手順とは異なる通信手順で呼制御通信が行われる場合であっても、呼制御通信の状況を通知するための表示画面を表示部に表示する必要がある。ここで、正規の通信手順で呼制御通信が行われた場合と同様の方法で表示制御が行われた場合を想定する。この場合、要求パケットを送信した発呼端末が要求パケットを受信することになるので、発呼端末の表示部に、セッションの確立が要求された旨を通知する表示画面が表示されることになる。従ってユーザは、他の通信端末との間のセッションの確立を通信端末に対して指示したにも関わらず、指示内容とは異なる態様の表示画面が表示部に表示されるため、混乱する。このように、正規の通信手順とは異なる通信手順で呼制御通信が行われた場合、ユーザの認識する通信端末の状態と、実際に表示部に表示される表示画面の内容とが相違する場合があるため、ユーザの混乱を招いてしまうという問題点がある。
【０００７】
本発明の目的は、正規の通信手順とは異なる通信手順で呼制御通信が行われた場合でも、ユーザに違和感を与えることなく、通信端末の状態をユーザに通知することができる通信端末、制御方法、及び制御プログラムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明の第一態様に係る通信端末は、他の通信端末である相手端末との間でセッションを確立し、通信を行う通信端末であって、ユーザからの指示に応じ、前記相手端末との間のセッションの確立を、前記相手端末に対して要求する第一要求手段と、前記第一要求手段において前記相手端末に対してセッションの確立を要求した後、前記相手端末との間のセッションを確立する第一確立手段と、前記相手端末との間のセッションの確立の要求を、前記相手端末から受け付ける第一受付手段と、前記第一受付手段において前記相手端末からセッションの確立の要求を受け付けた後、前記相手端末との間のセッションを確立する第二確立手段と、前記第一要求手段において前記相手端末に対してセッションの確立を要求してから、前記第一確立手段において前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第一通知情報を、通信を行う度に表示手段に表示する第一表示制御手段と、前記第一受付手段において前記相手端末からセッションの確立の要求を受け付けてから、前記第二確立手段において前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第二通知情報を、通信を行う度に前記表示手段に表示する第二表示制御手段とを備え、前記第一要求手段において、前記相手端末に対してセッションの確立を要求した後、前記第一確立手段において、前記相手端末との間のセッションを確立する前に、前記第一受付手段において、前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一表示制御手段は、前記第一通知情報を前記表示手段に表示し、前記第二表示制御手段は、前記第二通知情報を前記表示手段に表示しないことを特徴とする。
【０００９】
第一態様によれば、通信端末は、相手端末に対してセッションの確立を要求し、且つ、相手端末からセッションの確立が要求された場合に、第一通知情報を表示手段に表示する。これによって通信端末は、ユーザの認識する通信端末の状態と、実際に表示手段に表示される情報とを一致させることができる。これによって通信端末のユーザは、通信端末の状態を違和感なく認識することができる。
【００１０】
第一態様において、前記相手端末とは別の前記他の通信端末である要求端末から、前記相手端末との間のセッションの確立の要求を受け付ける第二受付手段と、前記第二受付手段において、前記要求端末から前記要求を受け付けた場合に、前記相手端末との間のセッションの確立を、前記相手端末に対して要求する第二要求手段と、前記第二要求手段において前記相手端末にセッションの確立を要求した後、前記相手端末との間のセッションを確立する第三確立手段とを備え、前記第二要求手段において前記相手端末に対してセッションの確立を要求してから、前記第三確立手段において前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記第二表示制御手段は、前記第二通知情報を前記表示手段に表示し、前記第一表示制御手段は、前記第一通知情報を前記表示手段に表示しなくてもよい。通信端末は、要求端末からの要求に応じ、相手端末に対してセッションの確立を要求することができる。これによって通信端末は、セッションを確立させるための通信手順を多様化することができるので、状況に応じて様々な手順で通信を行い、相手端末との間のセッションを確立させることができる。また、表示手段には、相手端末からセッションの確立が要求された場合と同様の情報が表示される。従って通信端末のユーザは、呼制御通信が異なる通信手順で実行された場合でも、通信端末の状態を違和感なく認識することができる。
【００１１】
第一態様において、前記第一要求手段において前記相手端末にセッションの確立を要求した後、前記第一確立手段において前記相手端末との間のセッションを確立する前に、前記第一受付手段において前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一確立手段は、前記相手端末との間のセッションを確立してもよい。通信端末と相手端末とでセッションの確立を要求するタイミングが略同時となった場合も、通信端末は、相手端末との間のセッションを確立させることができる。
【００１２】
本発明の第二態様に制御方法は、ユーザからの指示に応じ、他の通信端末である相手端末との間のセッションの確立を、前記相手端末に対して要求する第一要求ステップと、前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求した後、前記相手端末との間のセッションを確立する第一確立ステップと、前記相手端末との間のセッションの確立の要求を、前記相手端末から受け付ける第一受付ステップと、前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けた後、前記相手端末との間のセッションを確立する第二確立ステップと、前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求してから、前記第一確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第一通知情報を、通信を行う度に表示手段に表示する第一表示制御ステップと、前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けてから、前記第二確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第二通知情報を、通信を行う度に前記表示手段に表示する第二表示制御ステップとを備え、前記第一要求ステップにおいて、前記相手端末に対してセッションの確立を要求した後、前記第一確立ステップにおいて、前記相手端末との間のセッションを確立する前に、前記第一受付ステップにおいて、前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一表示制御ステップは、前記第一通知情報を前記表示手段に表示し、前記第二表示制御ステップは、前記第二通知情報を前記表示手段に表示しないことを特徴とする。第二態様によれば、第一態様と同様の効果を奏することができる。
【００１３】
本発明の第三態様に係る制御プログラムは、ユーザからの指示に応じ、他の通信端末である相手端末との間のセッションの確立を、前記相手端末に対して要求する第一要求ステップと、前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求した後、前記相手端末との間のセッションを確立する第一確立ステップと、前記相手端末との間のセッションの確立の要求を、前記相手端末から受け付ける第一受付ステップと、前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けた後、前記相手端末との間のセッションを確立する第二確立ステップと、前記第一要求ステップにおいて前記相手端末に対してセッションの確立を要求してから、前記第一確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第一通知情報を、通信を行う度に表示手段に表示する第一表示制御ステップと、前記第一受付ステップにおいて前記相手端末からセッションの確立の要求を受け付けてから、前記第二確立ステップにおいて前記相手端末との間のセッションを確立するまでの間の前記通信端末の状態をユーザに通知するために、前記相手端末との間で実行する通信の種別毎に設けた第二通知情報を、通信を行う度に前記表示手段に表示する第二表示制御ステップとをコンピュータに実行させるための制御プログラムであって、前記第一要求ステップにおいて、前記相手端末に対してセッションの確立を要求した後、前記第一確立ステップにおいて、前記相手端末との間のセッションを確立する前に、前記第一受付ステップにおいて、前記相手端末からセッションの確立の要求を受け付けた場合に、前記第一表示制御ステップは、前記第一通知情報を前記表示手段に表示し、前記第二表示制御ステップは、前記第二通知情報を前記表示手段に表示しないことを特徴とする。第三態様によれば、第一態様と同様の効果を奏することができる。
【図面の簡単な説明】
【００１４】
【図１】通信システム１の概要、及び通信端末２の電気的構成を示す図である。
【図２】通信端末１２、１３間の通信を説明するためのシーケンス図である。
【図３】制御プログラム３０の詳細を示す模式図である。
【図４】第一実施例における通信端末１２、１３間の通信を示すシーケンス図である。
【図５】第一実施例におけるメイン処理を示すフローチャートである。
【図６】第一実施例におけるメイン処理を示すフローチャートであって、図５の続きである。
【図７】第一実施例におけるメイン処理を示すフローチャートであって、図６の続きである。
【図８】第二実施例における通信端末１２、１３間の通信を示すシーケンス図である。
【図９】第二実施例におけるメイン処理を示すフローチャートである。
【図１０】第二実施例におけるメイン処理を示すフローチャートであって、図９の続きである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施形態（第一実施例、及び第二実施例）について、図面を参照して説明する。これらの図面は、本発明が採用しうる技術的特徴を説明するために用いられるものである。記載されている装置の構成、各種処理のフローチャート等は、それのみに限定する趣旨ではなく、単なる説明例である。
【００１６】
図１を参照し、通信システム１について説明する。通信システム１は、サーバ１１、及び通信端末１２、１３、１４を備えている。以下、通信端末１２、１３、１４を区別しない場合、または総称する場合、通信端末２という。サーバ１１及び通信端末２は、ネットワーク３を介して相互に通信を行うことができる。通信端末２は、呼制御通信によってセッションを確立し、Peer to Peer（Ｐ２Ｐ）型の通信を開始することができる。通信端末２として、例えば周知のＰＣが使用される。呼制御通信のプロトコルとして、例えばＳＩＰ（Session Initiation Protocol）が使用される。サーバ１１は、通信端末２間の呼制御通信を制御する。サーバ１１として、ＳＩＰサーバが使用される。なお、通信端末２に付された符号（１２、１３、１４）は、通信端末２のＩＤも示しているものとする。
【００１７】
通信端末２の電気的構成について説明する。通信端末２は、通信端末２の制御を司るＣＰＵ２１を備えている。ＣＰＵ２１は、ＲＯＭ２２、ＲＡＭ２３、ハードディスクドライブ（ＨＤＤ）２４、入力部２５、出力部２６、ドライブ装置２７、及び通信部２８と電気的に接続している。ＲＯＭ２２には、ブートプログラムやＢＩＯＳ等が記憶される。ＲＡＭ２３には、タイマやカウンタ、一時的なデータが記憶される。ＨＤＤ２４には、ＣＰＵ２１の制御プログラムやＯＳが記憶される。入力部２５は、ユーザからの入力を受け付けるキーボードやマウスである。出力部２６は、所望の画像を表示させるディスプレイである。ドライブ装置２７は、記憶媒体２７１に記憶された情報を読み出すことができる。例えば、通信端末２のセットアップ時、記憶媒体２７１に記憶された制御プログラムはドライブ装置２７によって読み出され、ＨＤＤ２４に記憶される。通信部２８は、ネットワーク３を介して他の通信端末２と通信を行うためのコントローラである。
【００１８】
図２を参照し、正規の通信手順で実行される呼制御通信の概要について説明する。通信端末１２を使用するユーザによって、通信端末１３との間でＰ２Ｐ通信を開始する指示が、入力部２５（図１参照）を介して入力される（Ｓ１１）。通信端末１２は、セッションの確立を要求するパケットを作成する。以下、セッションの確立を要求するパケットを、確立要求パケットともいう。通信端末１２は、通信端末１３を宛先とする確立要求パケットを、サーバ１１に対して送信する（Ｓ１２）。ここで通信端末１２は、通信端末１３との間のセッションの確立を要求している最中である旨を、出力部２６（図１参照）に表示してもよい。例えば出力部２６には、「通信端末１３に対して発信中です。」という文字情報が表示されてもよい。
【００１９】
サーバ１１は、通信端末１２から送信された確立要求パケットを受信し、通信端末１３に対して転送する。通信端末１３は、サーバ１１によって転送された確立要求パケットを受信する（Ｓ１３）。通信端末１３は、通信端末１２からセッションの確立の要求を着呼した旨を、出力部２６に表示してユーザに通知する（Ｓ１５）。以下、セッションの確立の要求を着呼した旨を表示してユーザに通知する処理を、着呼通知処理ともいう。例えば着呼通知処理によって、通信端末１３の出力部２６には「通信端末１２から着信中です。」という文字情報が表示される。通信端末１３のユーザは、通信端末１２からセッションの確立要求があった旨を認識する。
【００２０】
通信端末１３を使用するユーザによって、通信端末１２との間のセッションの確立を許諾する指示が、入力部２５を介して入力されたとする（Ｓ１７）。通信端末１３は、通信端末１２に対してセッションの確立の許諾を通知する肯定的な応答パケットを作成する。以下、セッションの確立の許諾を通知する肯定的な応答パケットを、ＯＫ応答パケットともいう。通信端末１３は、通信端末１２を宛先とするＯＫ応答パケットを、サーバ１１に対して送信する（Ｓ１８）。サーバ１１は、通信端末１３から送信されたＯＫ応答パケットを受信し、通信端末１２に対して転送する。通信端末１２は、サーバ１１によって転送されたＯＫ応答パケットを受信する（Ｓ１９）。通信端末１２は、通信端末１３においてセッションの確立が許諾され、通信端末１３との間のセッションが確立された旨を、出力部２６に表示してユーザに通知する（Ｓ２１）。以下、セッションが確立された旨を表示してユーザに通知する処理を、確立通知処理ともいう。例えば確立通知処理によって、通信端末１２の出力部２６には「通信端末１３との間のセッションが確立されました。」という文字情報が表示される。通信端末１２のユーザは、通信端末１３との間のセッションが確立された旨を認識する。
【００２１】
通信端末１２は、ＯＫ応答パケットを受信したことを通知するＡＣＫパケットを、サーバ１１を介して通信端末１３に対して送信する（Ｓ２２）。通信端末１３は、サーバ１１を介してＡＣＫパケットを受信する（Ｓ２３）。通信端末１３では、確立通知処理が実行される。確立通知処理によって、通信端末１２との間のセッションが確立された旨が、ユーザに通知される（Ｓ２５）。
【００２２】
以上の呼制御通信を経て、通信端末１２と通信端末１３との間のセッションは確立した状態になる。通信端末１２のユーザが、通信端末１３に対してデータを送信する指示を、入力部２５を介して入力したとする（Ｓ２７）。通信端末１２は、サーバ１１を介することなく、通信端末１３に対してデータを直接送信する（Ｓ２８）。通信端末１３は、通信端末１２からデータを受信する（Ｓ２９）。通信端末１３は、通信端末１２からデータを受信した旨を、受信したデータと共に出力部２６に表示してユーザに通知する（Ｓ３１）。以下、データを受信した旨を、受信したデータと共に表示してユーザに通知する処理を、受信通知処理ともいう。
【００２３】
通信端末１３のユーザが、通信端末１２に対してデータを送信する指示を、入力部２５を介して入力したとする（Ｓ３３）。通信端末１３は、サーバ１１を介することなく、通信端末１２に対してデータを直接送信する（Ｓ３４）。通信端末１２は、通信端末１３からデータを受信する（Ｓ３５）。通信端末１２では、受信通知処理が実行される。受信通知処理によって、通信端末１３からデータを受信した旨が、受信したデータと共にユーザに通知される（Ｓ３７）。
【００２４】
図３を参照し、通信端末２のＨＤＤ２４に記憶された制御プログラム３０について説明する。制御プログラム３０は、通信制御を実行するアプリケーションプログラムと、出力部２６への表示制御を実行するアプリケーションとを備えている。以下、通信制御を実行するアプリケーションを、通信アプリケーション３１ともいう。出力部２６への表示制御を実行するアプリケーションを、表示アプリケーション３２ともいう。通信アプリケーション３１がＣＰＵ２１において実行されることによって、通信端末２間で呼制御通信、及びＰ２Ｐ型の通信が実行される。表示アプリケーション３２がＣＰＵ２１において実行されることによって、着呼通知処理、確立通知処理、及び受信通知処理が実行される。
【００２５】
表示アプリケーション３２は、発呼側表示アプリケーション３３及び着呼側表示アプリケーション３６を備えている。発呼側表示アプリケーション３３は、Ｐ２Ｐ型の通信の開始がユーザによって指示された通信端末２のＣＰＵ２１において起動され、実行される。着呼側表示アプリケーション３６は、セッションの確立の要求を受けた通信端末２のＣＰＵ２１において起動され、実行される。以下、Ｐ２Ｐ型の通信の開始がユーザによって指示された通信端末２を、発呼端末ともいう。セッションの確立の要求を受けた通信端末２を、着呼端末ともいう。
【００２６】
発呼側表示アプリケーション３３について説明する。発呼側表示アプリケーション３３は、発呼端末のＣＰＵ２１において起動される。通信アプリケーション３１は、ＯＫ応答パケットが受信された場合（Ｓ１９、図２参照）に、起動された発呼側表示アプリケーション３３に対して確立通知処理３４（Ｓ２１、図２参照）の実行を指示する。通信アプリケーション３１は、他の通信端末２との間のセッションの確立後、Ｐ２Ｐ型の通信によってデータが受信された場合（Ｓ３５、図２参照）に、起動された発呼側表示アプリケーション３３に対して受信通知処理３５（Ｓ３７、図２参照）の実行を指示する。発呼側表示アプリケーション３３は、通信アプリケーションからの指示に基づき、確立通知処理３４及び受信通知処理３５を順に実行することになる。
【００２７】
着呼側表示アプリケーション３６について説明する。着呼側表示アプリケーション３６は、確立要求パケットが受信された通信端末２のＣＰＵ２１において起動される。通信アプリケーション３１は、確立要求パケットが受信された場合（Ｓ１３、図２参照）に、起動された着呼側表示アプリケーション３６に対して着呼通知処理３７（Ｓ１５、図２参照）の実行を指示する。通信アプリケーション３１は、ＡＣＫパケットが受信された場合（Ｓ２３、図２参照）に、起動された着呼側表示アプリケーション３６に対して確立通知処理３８（Ｓ２５、図２参照）の実行を指示する。通信アプリケーション３１は、他の通信端末２との間のセッションの確立後、Ｐ２Ｐ型の通信によってデータが受信された場合（Ｓ２９、図２参照）に、起動された着呼側表示アプリケーション３６に対して受信通知処理３９（Ｓ３１、図２参照）の実行を指示する。着呼側表示アプリケーション３６は、通信アプリケーション３１からの指示に基づき、着呼通知処理３７、確立通知処理３８、及び受信通知処理３９を順に実行することになる。
【００２８】
＜第一実施例＞
図４を参照し、例外的な通信手順で実行される呼制御通信の概要について説明する。通信端末１３とのＰ２Ｐ通信を開始する指示が通信端末１２に対して入力され、且つ、同時期に、通信端末１２とのＰ２Ｐ通信を開始する指示が通信端末１３に対して入力された場合を想定している。
【００２９】
通信端末１２に対して、通信端末１３とのＰ２Ｐ通信を開始する指示が入力される（Ｓ４１）。通信端末１２は、確立要求パケットを、サーバ１１を介して通信端末１３に対して送信する。（Ｓ４３）。また同時期に、通信端末１３に対して、通信端末１２とのＰ２Ｐ通信を開始する指示が入力される（Ｓ４５）。通信端末１３は、確立要求パケットを、サーバ１１を介して通信端末１２に対して送信する（Ｓ４７）。
【００３０】
通信端末１３は、通信端末１２から送信された確立要求パケットを、サーバ１１を介して受信する（Ｓ４９）。通信端末１３では、確立要求パケットの送信後に通信端末１２から受信されたパケットが、ＯＫ応答パケットでないことになる。ここで通信端末１３は、通信端末１２から受信されたパケットがＯＫ応答パケットでない場合であっても、受信されたパケットが確立要求パケットである場合には、通信端末１２に対してＰ２Ｐ通信を開始する指示が入力されていると判断する。通信端末１３は、継続して呼制御通信を行う。
【００３１】
同様に通信端末１２は、通信端末１３から送信された確立要求パケットを、サーバ１１を介して受信する（Ｓ５１）。通信端末１２は、受信されたパケットはＯＫ応答パケットでないが、確立要求パケットであるので、通信端末１３に対してＰ２Ｐ通信を開始する指示が入力されていると判断する。通信端末１２は、継続して呼制御通信を行う。
【００３２】
通信端末１２、１３は、受信した確立要求パケットに応じて返信するパケットの種別を決定する。上述のように、相手方の通信端末２に対して同時期にＰ２Ｐ通信を開始する指示が入力されていると判断された場合、通信端末１２、１３のうちいずれか一方の通信端末２は、相手方の通信端末に対してＯＫ応答パケットを送信する。これによっていずれか一方の通信端末２では、Ｐ２Ｐ通信を開始する指示が入力されているにも関わらず、正規の呼制御通信の手順（図２参照）のうち着呼端末側の手順で通信が実行されることになる。
【００３３】
ＯＫ応答パケットを送信するか否かは、自身のＩＤと相手方のＩＤとを比較することで決定される。具体的な方法は以下の通りである。通信端末１３のＩＤ  １３は、通信端末１３において受信された確立要求パケットの送信元の通信端末１２のＩＤ  １２よりも大きい。この場合、通信端末１３は、ＯＫ応答パケットを通信端末１２に対して送信する（Ｓ５３）。一方、通信端末１２のＩＤ  １２は、通信端末１２において受信された確立要求パケットの送信元の通信端末１３のＩＤ  １３よりも小さい。この場合、通信端末１２は、通信端末１３との間のセッションの確立が許可されている場合であっても、セッションの確立の拒否を通知する否定的な応答パケットを通信端末１３に対して送信する（Ｓ５５）。以下、セッションの確立の拒否を通知する否定的な応答パケットを、ＮＧ応答パケットともいう。
【００３４】
通信端末１２は、通信端末１３から送信されたＯＫ応答パケットを、サーバ１１を介して受信する（Ｓ５７）。通信端末１２は、Ｓ４３で自身が送信した確立要求パケットが、通信端末１３において正常に処理されていると判断する。通信端末１２は、通信端末１３に対してＮＧ応答パケットを送信した後、通信端末１３からＯＫ応答パケットを受信した場合に、通信端末１３とのセッションの確立に成功したと判断する。通信端末１２は、ＡＣＫパケットを通信端末１３に対して返信する（Ｓ６５）。以上のように、通信端末１２において実行される呼制御通信（Ｓ４３、５７、及び６５）の手順は、Ｓ５１、及びＳ５５の通信を除き、正規の呼制御通信の手順（図２参照）のうち発呼端末側の手順と同一である。
【００３５】
通信端末１３は、通信端末１２から送信されたＮＧ応答パケットを、サーバ１１を介して受信する（Ｓ６１）。通信端末１３は、通信端末１２に対してＯＫ応答パケットを送信した後、通信端末１２からＮＧ応答パケットを受信した場合に、ＡＣＫパケットを通信端末１２に対して返信する（Ｓ６３）。通信端末１３は、通信端末１２からＡＣＫパケットを受信する（Ｓ６９）。通信端末１３は、通信端末１２とのセッションの確立に成功したと判断する。以上のように、通信端末１３において実行される呼制御通信（Ｓ４９、５３、６９）の手順は、Ｓ４７、Ｓ６１、及びＳ６３を除き、正規の呼制御通信の手順（図２参照）のうち着呼端末側の手順と同一である。
【００３６】
以上の呼制御通信を経て、通信端末１２と通信端末１３との間のセッションは確立した状態になる。通信端末１２、１３間でＰ２Ｐ型の通信が実行されることによって、通信端末１２、１３間でデータが送受信される（Ｓ７５、Ｓ８１）。
【００３７】
図４で説明した通信手順で通信が実行された場合の、通信アプリケーション３１（図３参照）と表示アプリケーション３２（図３参照）との関係について説明する。通信端末１２、１３では、Ｐ２Ｐ型の通信の開始がユーザによって指示されている（Ｓ４１、Ｓ４５）ので、発呼側表示アプリケーション３３（図２参照）が起動される。しかしながら上述のような通信手順で呼制御通信が実行される場合、通信端末１３では、正規の呼制御通信の手順（図２参照）のうち着呼端末側の手順で通信が実行される。従って通信アプリケーション３１は、通信端末１２から送信された確立要求パケットが受信された場合（Ｓ４９）、起動された発呼側表示アプリケーション３３に対して、着呼通知処理の実行を指示する（Ｓ１５、図２参照）。しかしながら、通信端末１３に対して、Ｐ２Ｐ型の通信の開始指示がされているので（Ｓ４５）、着呼通知処理によって「通信端末１２から着信中です。」のような文字が出力部２６に表示された場合、ユーザは違和感を覚える。また、そもそも発呼側表示アプリケーション３３では着呼通知処理の指示が想定されていない。このため発呼側表示アプリケーション３３は、着呼通知処理を実行することができない。これに対して本発明では、正規の呼制御通信の手順における着呼端末側の手順で通信が行われている場合であっても、発呼端末において実行される制御方法で、起動された発呼側表示アプリケーション３３を制御する。詳細を以下に説明する。
【００３８】
通信端末１２の場合について説明する。通信端末１２において、Ｐ２Ｐ型の通信の開始がユーザによって指示される（Ｓ４１）。発呼側表示アプリケーション３３が起動される。確立要求パケットが通信端末１３に対して送信される（Ｓ４３）。なおここで発呼側表示アプリケーション３３は、通信端末１３との間のセッションの確立を要求している最中である旨を出力部２６（図１参照）に表示してもよい。確立要求パケットの送信後、通信端末１３から送信されたＯＫ応答パケットが受信される（Ｓ５７）。通信アプリケーション３１は、起動された発呼側表示アプリケーション３３に対して、確立通知処理３４の実行を指示する。発呼側表示アプリケーション３３は、確立通知処理３４を実行する（Ｓ５９）。通信端末１３との間のセッションが確立された旨が、ユーザに通知される。
【００３９】
通信端末１３との間のセッションが確立した後、通信端末１３から送信されたデータが受信されたとする（Ｓ８１）。通信アプリケーション３１は、起動された発呼側表示アプリケーション３３に対して、受信通知処理３５の実行を指示する。発呼側表示アプリケーション３３は、受信通知処理３５を実行する（Ｓ８３）。通信端末１３からデータを受信した旨が、受信したデータと共にユーザに通知される。
【００４０】
以上の処理では、通信アプリケーション３１から発呼側表示アプリケーション３３に対して、確立通知処理３４及び受信通知処理３５の順で指示が実行されている。発呼側表示アプリケーション３３に対する指示の手順は、正規の呼制御通信時（図２参照）の場合と同一となる。このため発呼側表示アプリケーション３３は、通信アプリケーション３１からの指示に応じてユーザへの通知を確実に行うことができる。
【００４１】
通信端末１３の場合について説明する。通信端末１３において、Ｐ２Ｐ型の通信がユーザによって指示される（Ｓ４５）。発呼側表示アプリケーション３３が起動される。確立要求パケットが通信端末１２に対して送信される（Ｓ４７）。通信端末１２から送信された確立要求パケットが受信され（Ｓ４９）、ＯＫ応答パケットが通信端末１２に対して送信される（Ｓ５３）。通信アプリケーション３１は、起動された発呼側表示アプリケーション３３に対して着信通知の指示を行わない。送信されたＯＫ応答パケットに応じ、通信端末１２から送信されるＡＣＫパケットが受信される（Ｓ６９）。通信アプリケーション３１は、起動された発呼側表示アプリケーション３３に対して、確立通知処理３４の実行を指示する。発呼側表示アプリケーションは、確立通知処理３４を実行する（Ｓ７１）。通信端末１２との間のセッションが確立された旨が、ユーザに通知される。
【００４２】
通信端末１２との間のセッションが確立した後、通信端末１２から送信されたデータが受信されたとする（Ｓ７５）。通信アプリケーション３１は、起動された発呼側表示アプリケーション３３に対して、受信通知処理３５の実行を指示する。発呼側表示アプリケーション３３は、受信通知処理３５を実行する（Ｓ７７）。通信端末１２からデータを受信した旨が、受信したデータと共にユーザに通知される。
【００４３】
以上の処理では、通信端末１２の場合と同様、通信アプリケーション３１から発呼側表示アプリケーション３３に対して、確立通知処理３４及び受信通知処理３５の順で指示が実行されている。通信端末１３では着呼端末における呼制御通信の通信手順で通信が実行されているにも関わらず、発呼側表示アプリケーション３３によって実行される指示の手順は、正規の呼制御通信時（図２参照）の場合と同一となる。このため発呼側表示アプリケーションは、通信アプリケーションからの指示に応じてユーザへの通知を確実に行うことができる。また、違和感のない表示態様でユーザに通知を行うことができる。
【００４４】
以上のようにして通信端末２は、他の通信端末２に対してセッションの確立を要求し、且つ、他の通信端末２からセッションの確立が要求された場合に、発呼側表示アプリケーション３３が起動される。通信アプリケーション３１は、確立通知処理３４及び受信通知処理３５が順番に実行されるように指示する。従って通信端末２は、図４に示すように例外的な手順で呼制御通信が実行された場合でも、出力部２６に表示する処理を共通化できる。例外的な手順の呼制御通信に対応した場合であっても、通信端末２は、出力部２６への表示制御方法は、正規の手順で呼制御通信が実行された場合と同一となる。従って、新たな通信手順で呼制御通信を行うための機能が通信端末２に対して新たに加えられる場合でも、機能追加に伴う不具合の発生は抑制される。このため、機能追加に必要な作業量を抑制することができる。また、ユーザに対して違和感のない通知を行うことができる。
【００４５】
図５から図７を参照し、第一実施例における通信端末２のＣＰＵ２１において実行される通信アプリケーション３１のメイン処理について説明する。メイン処理は、通信端末２の電源が投入された場合に、ＣＰＵ２１において起動され実行される。他の通信端末２との間でＰ２Ｐ型の通信を開始する指示が、ユーザによって入力されたかが判断される（Ｓ１１１）。他の通信端末２との間でＰ２Ｐ型の通信を開始する指示が入力された場合（Ｓ１１１：ＹＥＳ）、指示と同時にユーザによって入力された、他の通信端末２のＩＤが取得される（Ｓ１１３）。取得されたＩＤにて特定される他の通信端末２との間のセッションを確立させるために、確立要求パケットがサーバ１１に対して送信される（Ｓ１１５）。処理はＳ１１１に戻る。なおサーバ１１は、受信された確立要求パケットを、Ｓ１１３で取得されたＩＤによって特定される他の通信端末２に対して転送する。
【００４６】
Ｓ１１１で、Ｐ２Ｐ型の通信を開始する指示が入力されていない場合（Ｓ１１１：ＮＯ）、他の通信端末２から送信された確立要求パケットを、サーバ１１を介して受信したかが判断される（Ｓ１１７）。他の通信端末２から確立要求パケットが受信されたとする（Ｓ１１７：ＹＥＳ）。Ｓ１１５で確立要求パケットを送信しているかが判断される（Ｓ１１９）。Ｓ１１５で他の通信端末２に対して確立要求パケットを送信していない場合（Ｓ１１９：ＮＯ）、着呼端末として確立要求パケットを受信したことになる。図２に示す正規の呼制御通信が開始される。着呼側表示アプリケーション３６（図３参照）が起動される。着呼側表示アプリケーション３６に対して、着呼通知処理３７の実行が指示される。他の通信端末２からセッションの確立の要求を着呼した旨が、出力部２６に表示される（Ｓ１２１、Ｓ１５（図２参照））。処理はＳ１１１に戻る。
【００４７】
Ｓ１１５で確立要求パケットを送信している場合（Ｓ１１９：ＹＥＳ）、確立要求パケットに応じるＯＫ応答パケットを受信する前に、確立要求パケットを受信していることになる。この場合、ユーザによってＰ２Ｐ型の通信を開始する指示が入力されたと同時期に、他の通信端末２に対してＰ２Ｐ型の通信を開始する指示が入力されていることになる。図４に示す例外的な呼制御通信が開始される。
【００４８】
発呼側表示アプリケーション３３（図３参照）が起動される。Ｓ１１７で受信された確立要求パケットを送信した他の通信端末２のＩＤが取得される。取得されたＩＤと、自身のＩＤとが比較される（Ｓ１２３）。自身のＩＤの方が、取得された他の通信端末２のＩＤよりも大きい場合（Ｓ１２３：ＹＥＳ）、他の通信端末２に対してＯＫ応答パケットが送信される（Ｓ１２５、Ｓ５３（図４参照））。送信されたＯＫ応答パケットに応じ、他の通信端末２から送信されるＡＣＫパケットを受信したかが判断される（Ｓ１２７）。ＡＣＫパケットが受信された場合（Ｓ１２７：ＹＥＳ、Ｓ６９（図４参照））、他の通信端末２との間のセッションの確立に成功したと判断される。発呼側表示アプリケーション３３に対して、確立通知処理３４（図３参照）の実行が指示される。他の通信端末２との間のセッションが確立した旨が、出力部２６に表示される（Ｓ１３３、Ｓ７１（図４参照））。処理はＳ１４９（図６参照）に進む。
【００４９】
一方、ＡＣＫパケットが受信されない場合（Ｓ１２７：ＮＯ）、他の通信端末２からＮＧ応答パケットを受信したかが判断される（Ｓ１２９）。ＮＧ応答パケットが受信された場合（Ｓ１２９：ＹＥＳ、Ｓ６１（図４参照））、他の通信端末２に対してＡＣＫパケットが送信される（Ｓ１３１、Ｓ６３（図４参照））。処理はＳ１２７に戻る。ＮＧ応答パケットを受信していない場合（Ｓ１２９：ＮＯ）、処理はＳ１２７に戻る。
【００５０】
Ｓ１２３で、自身のＩＤの方が、Ｓ１１７で受信された確立要求パケットを送信した他の通信端末２のＩＤよりも小さい場合（Ｓ１２７：ＮＯ）、他の通信端末２に対してＮＧ応答が送信される（Ｓ１３５、Ｓ５５（図４参照））。他の通信端末２から送信されるＯＫ応答パケットの受信が監視される（Ｓ１３７）。ＯＫ応答パケットが受信されない場合（Ｓ１３７：ＮＯ）、処理はＳ１３７に戻る。他の通信端末２からＯＫ応答パケットが受信された場合（Ｓ１３７：ＹＥＳ、Ｓ５７（図４参照））、発呼側表示アプリケーション３３に対して、確立通知処理３４の実行が指示される。他の通信端末２との間のセッションが確立した旨が、出力部２６に表示される（Ｓ１３９、Ｓ５９（図４参照））。他の通信端末２に対してＡＣＫパケットが送信される（Ｓ１４１、Ｓ６５（図４参照））。処理はＳ１４９（図６参照）に進む。
【００５１】
図６に示すように、呼制御通信を経て、他の通信端末２との間のセッションが確立された状態になる（Ｓ１４９）。他の通信端末２との間でＰ２Ｐ通信が開始される（Ｓ１５１）。他の通信端末２からデータが受信された場合（Ｓ１５３：ＹＥＳ）、発呼側表示アプリケーション３３に対して、受信通知処理３５（図３参照）の実行が指示される。他の通信端末２からデータを受信した旨が、受信したデータと共に出力部２６に表示される（Ｓ１５５、Ｓ７７（図４参照）、Ｓ８３（図４参照））。処理はＳ１５７に進む。他の通信端末２からデータが受信されなかった場合（Ｓ１５３：ＮＯ）、処理はＳ１５７に進む。
【００５２】
他の通信端末２との間のＰ２Ｐ通信を終了させる指示が、ユーザによって入力されたかが判断される（Ｓ１５７）。Ｐ２Ｐ通信を終了させる指示が入力されていない場合（Ｓ１５７：ＮＯ）、処理はＳ１５１に戻る。Ｐ２Ｐ通信を終了させる指示が入力された場合（Ｓ１５７：ＹＥＳ）、メイン処理は終了する。
【００５３】
図５のＳ１１７で、確立要求パケットが受信されなかったとする（Ｓ１１７：ＮＯ）。図７に示すように、セッションの確立を許諾する旨の指示が、ユーザによって入力されたかが判断される（Ｓ１６１）。セッションの確立を許諾する旨の指示が入力された場合（Ｓ１６１：ＹＥＳ、Ｓ１７（図２参照））、図２に示す正規の呼制御通信が実行されていることになる。着呼側表示アプリケーション３６が起動され、Ｓ１２１（図５参照）で着呼通知処理３７が実行されている。他の通信端末２に対してＯＫ応答パケットが送信される（Ｓ１６３、Ｓ１８（図２参照））。送信されたＯＫ応答パケットに応じ、他の通信端末２から送信されるＡＣＫパケットが受信される（Ｓ１６５、Ｓ２３（図２参照））。着呼側表示アプリケーション３６に対して、確立通知処理３８（図３参照）の実行が指示される。他の通信端末２との間のセッションが確立した旨が、出力部２６に表示される（Ｓ１６７、Ｓ２５（図２参照））。処理はＳ１４９（図６参照）に進む。
【００５４】
セッションの確立を許諾する旨の指示が入力されていない場合（Ｓ１６１：ＮＯ）、他の通信端末２からＯＫ応答パケットを受信したかが判断される（Ｓ１６９）。ＯＫ応答パケットが受信された場合（Ｓ１６９：ＹＥＳ、Ｓ１９（図２参照））、Ｓ１１５（図５参照）で送信された確立要求パケットに対して、他の通信端末２がセッションの確立を許諾したことになる。図２に示す正規の呼制御通信が実行されている。発呼側表示アプリケーション３３に対して、確立通知処理３４の実行が指示される。他の通信端末２との間のセッションが確立した旨が、出力部２６に表示される（Ｓ１７１、Ｓ２１（図２参照））。他の通信端末２に対してＡＣＫパケットが送信される（Ｓ１７３、Ｓ２２（図２参照））。処理はＳ１４９（図６参照）に進む。
【００５５】
図６に示すように、図２に示す正規の呼制御通信によって他の通信端末２との間のセッションが確立され（Ｓ１４９）、Ｐ２Ｐ通信が開始される（Ｓ１５１）。他の通信端末２からデータが受信された場合（Ｓ１５３：ＹＥＳ）、発呼側表示アプリケーション３３又は着呼側表示アプリケーション３６に対して、受信通知処理３５、３９の実行が指示される。他の通信端末２からデータを受信した旨が、受信したデータと共に出力部２６に表示される（Ｓ１５５、３１（図２参照）、３７（図２参照））。
【００５６】
図７のＳ１６９で、ＯＫ応答パケットが受信されなかったとする（Ｓ１６９：ＮＯ）。他の通信端末２との間のセッションの確立を拒否する旨の指示が、ユーザによって入力されたかが判断される（Ｓ１７５）。セッションの確立を拒否する旨の指示が入力された場合（Ｓ１７５：ＹＥＳ）、他の通信端末２に対してＮＧ応答パケットが送信される（Ｓ１７９）。ＮＧ応答パケットを受信した他の通信端末２から、ＡＣＫパケットが受信される（Ｓ１８１）。処理はＳ１１１（図５参照）に戻る。
【００５７】
Ｓ１７５で、セッションの確立を拒否する旨の指示が入力されなかったとする（Ｓ１７５：ＮＯ）。他の通信端末２から送信されたＮＧ応答パケットを受信したかが判断される（Ｓ１８３）。ＮＧ応答パケットが受信されなかった場合（Ｓ１８３：ＮＯ）、処理はＳ１１１（図５参照）に戻る。他の通信端末２からＮＧ応答パケットが受信された場合（Ｓ１８３：ＹＥＳ）、セッションの確立が拒否された旨が出力部２６に表示される（Ｓ１８５）。他の通信端末２に対してＡＣＫパケットが送信される（Ｓ１８７）。処理はＳ１１１（図５参照）に戻る。
【００５８】
以上説明したように、通信端末２は、他の通信端末２に対してセッションの確立を要求し、且つ、他の通信端末２からセッションの確立が要求された場合であっても、正規の手順で呼制御通信が実行される場合と同様の方法で、ユーザに対する通知を実行することができる。通信端末２は、セッションを確立させるために実行される通信の手順が複雑になった場合も、表示制御方法を共通化できる。これによって通信端末２は、表示制御処理が多様化し且つ複雑化することを防止できる。また通信端末２は、ユーザの認識する通信端末２の状態と、実際に表示される情報とを一致させることができる。これによって通信端末２は、ユーザにとって違和感のない表示態様で、出力部２６への表示を行うことができる。
【００５９】
＜第二実施例＞
図８を参照し、図４で示した通信手順とは異なる例外的な通信手順の概要について説明する。図８では、通信端末１２、１３間でＰ２Ｐ型の通信を開始させるように指示するパケットが、通信端末１４から通信端末１２に対して送信されている。以下、他の通信端末２間でＰ２Ｐ型の通信を開始させるように指示するパケットを、ＲＥＦＥＲパケットともいう。例えば通信端末１４は、通信端末１２、１３との間のセッションを既に確立させており、通信端末１２、１３、１４間でＰ２Ｐ型の通信を開始するために、通信端末１２に対してＲＥＦＥＲパケットを送信する（Ｓ８０）。通信端末１２は、通信端末１４から送信されたＲＥＦＥＲパケットを受信する（Ｓ８１）。ＲＥＦＥＲパケットには、セッションを確立させる相手方の通信端末１３のＩＤ  １３が格納される。またＲＥＦＥＲパケットには、通信端末１４において生成されたキー情報  ｘｘｘｘが格納される。なお、キー情報  ｙｙｙｙが通信端末１４から通信端末１３に対して事前に通知されているものとする。
【００６０】
通信端末１２は、ＲＥＦＥＲパケットに応じて通信端末１３間のセッションを確立させるために、サーバ１１を介して、通信端末１３に対して確立要求パケットを送信する（Ｓ８２）。確立要求パケットには、キー情報  ｘｘｘｘが格納される。なお、Ｐ２Ｐ型の通信の開始指示はユーザによって直接入力されていないので、通信端末１２において発呼側表示アプリケーション３３（図３参照）は起動されない。通信端末１３は、通信端末１２から送信された確立要求パケットを、サーバ１１を介して受信する（Ｓ８３）。通信端末１３は、確立要求パケットに格納されているキー情報  ｘｘｘｘを取得する。通信端末１３では、セッションの確立の要求を通信端末１２から受けたことになるので、着呼側表示アプリケーション３６（図３参照）が起動される。通信アプリケーション３１（図３参照）は、起動された着呼側表示アプリケーション３６に対して、着呼通知処理３７（図３参照）の実行を指示する。着呼側表示アプリケーション３６は、着呼通知処理３７を実行する（Ｓ８５）。通信端末１２からセッションの確立要求を受けた旨が、ユーザに通知される。
【００６１】
通信端末１３は、確立要求パケットから取得したキー情報  ｘｘｘｘと、事前に通信端末１４から通知されたキー情報  ｙｙｙｙとを比較する。キー情報が一致する場合、通信端末１３は、ユーザによる入力操作の内容に関わらず、通信端末１２との間のセッションの確立を許諾する。一方、キー情報が相違する場合、通信端末１３は、セッションの確立を許諾する旨の入力操作がユーザによってなされた場合に、セッションの確立を許諾する。
【００６２】
図８では、確立要求パケットから取得されたキー情報  ｘｘｘｘと、事前に通信端末１４から通知されていたキー情報  ｙｙｙｙとが相違している。通信端末１３は、ユーザからの入力操作を受け付ける。通信端末１３を使用するユーザによって、通信端末１２との間のセッションの確立を許諾する指示が入力されたとする（Ｓ８７）。通信端末１３は、通信端末１２を宛先とするＯＫ応答パケットを、サーバ１１を介して通信端末１２に対して送信する（Ｓ８８）。通信端末１３では、正規の呼制御通信の手順（図２参照）のうち着呼端末側の手順で通信が行われることになる。なおＯＫ応答パケットには、通信端末１３に対して事前に通知されていたキー情報  ｙｙｙｙが格納される。通信端末１２は、サーバ１１を介してＯＫ応答パケットを受信する（Ｓ８９）。
【００６３】
通信端末１２は、Ｐ２Ｐ型の通信を開始する指示がユーザによって入力されていない状態で、ＯＫ応答パケットを通信端末１３から受信したことになる。このような場合に通信端末１２は、正規の呼制御通信の手順（図２参照）のうち発呼端末側の手順で通信を行う。また通信端末１２は、着呼側表示アプリケーション３６を起動し、着呼端末において実行される制御方法で、起動された着呼側表示アプリケーション３６を制御する。詳細は以下のとおりである。
【００６４】
Ｓ８９でＯＫ応答パケットが受信された場合、通信端末１２は、起動された着呼側表示アプリケーション３６に対して、着呼通知処理３７（図３参照）の実行を指示する。着呼側表示アプリケーション３６は、着呼通知処理を実行する。通信端末１３からセッションの確立要求を受けた旨が、ユーザに通知される（Ｓ９１）。
【００６５】
ＲＥＦＥＲパケットに格納されたキー情報  ｘｘｘｘと、ＯＫ応答パケットに格納されていたキー情報  ｙｙｙｙとが比較される。キー情報が一致する場合、通信端末１２は、ユーザによる入力操作の内容に関わらず、通信端末１３との間のセッションの確立を許諾する。一方、キー情報が相違する場合、通信端末１２は、セッションの確立を許諾する旨の入力操作がユーザによってなされた場合に、セッションの確立を許諾する。
【００６６】
図８では、ＲＥＦＥＲパケットに格納されたキー情報  ｘｘｘｘと、ＯＫ応答パケットに格納されたキー情報  ｙｙｙｙとは相違している。通信端末１２を使用するユーザによって、通信端末１３とのセッションの確立を許諾する指示が入力されたとする（Ｓ９３）。通信端末１２は、Ｓ８９でＯＫ応答パケットを受信したことを通知するＡＣＫパケットを、サーバ１１を介して通信端末１３に対して送信する（Ｓ９４）。通信端末１２は、通信端末１３との間のセッションが確立されたと判断する。通信端末１２の通信アプリケーション３１は、着呼側表示アプリケーション３６に対して、確立通知処理３８（図３参照）の実行を指示する。着呼側表示アプリケーション３６は、確立通知処理３８を実行する。通信端末１３との間のセッションが確立された旨が、ユーザに通知される（Ｓ９８）。
【００６７】
通信端末１３との間のセッションが確立した後、通信端末１３から送信されたデータが受信されたとする（Ｓ１０７）。通信アプリケーション３１は、着呼側表示アプリケーション３６に対して、受信通知処理３９（図３参照）の実行を指示する。発呼側表示アプリケーション３６は、受信通知処理３９を実行する。通信端末１３からデータを受信した旨が、受信したデータと共にユーザに通知される（Ｓ１０９）。
【００６８】
以上のように、通信アプリケーション３１から着呼側表示アプリケーション３６に対して、着呼通知処理３７、確立通知処理３８、及び受信通知処理３９の順で指示が実行される。通信端末１２では発呼端末における呼制御通信の通信手順で通信が実行されているにも関わらず、着呼側表示アプリケーション３６に対して、正規の呼制御通信時（図２参照）における着呼端末側と同一の手順で指示が実行される。このため着呼側表示アプリケーション３６は、通信アプリケーション３１からの指示に応じてユーザへの通知を確実に行うことができる。又、ユーザによるＰ２Ｐ型の通信の開始指示がされていないので、通信端末１２は、着呼通知処理、確立通知処理、及び受信通知処理を順番に実行する。これによって、ＲＥＦＥＲパケットを受信することで呼制御通信が開始された場合であっても、違和感のない表示態様でユーザに通知を行うことができる。
【００６９】
通信端末１３の場合について説明する。通信端末１３は、Ｓ８８で送信されたＯＫ応答パケットに応じて通信端末１２から送信されるＡＣＫパケットを、サーバ１１を介して受信する（Ｓ９５）。通信端末１３は、通信端末１２とのセッションの確立に成功したと判断する。通信端末１３の通信アプリケーション３１は、着呼側表示アプリケーション３６に対して、確立通知処理３８の実行を指示する。着呼側表示アプリケーション３６は、確立通知処理３８を実行する。通信端末１２との間のセッションが確立された旨が、ユーザに通知される（Ｓ９７）。
【００７０】
通信端末１２との間のセッションが確立した後、通信端末１２から送信されたデータが受信されたとする（Ｓ１０１）。通信アプリケーション３１は、着呼側表示アプリケーション３６に対して、受信通知処理３９の実行を指示する。着呼側表示アプリケーション３６は、受信通知処理３９を実行する。通信端末１２からデータを受信した旨が、受信したデータと共にユーザに通知される（Ｓ１０３）。以上のように、通信アプリケーション３１から着呼側表示アプリケーション３６に対して、着呼通知処理３７、確立通知処理３８、及び受信通知処理３９の順で指示が実行される。
【００７１】
以上説明したように、通信端末１２は、通信端末１４からの要求に応じ、通信端末１３に対してセッションの確立を要求することができる。これによって通信端末１２は、セッションを確立させるための通信手順を多様化することができるので、状況に応じて様々な手順で通信を行い、通信端末１３との間のセッションを確立させることができる。
【００７２】
また、図８に示す手順で呼制御通信が実行される場合、通信端末１２、１３では着呼側表示アプリケーション３６が起動される。通信端末１２は、正規の呼制御通信時における着呼端末において実行される通知制御と同一の方法で、ユーザに各種通知を行うことができる。従って通信端末１２は、呼制御通信が異なる通信手順で実行された場合でも、ユーザへの通知方法が多様化し且つ複雑化することを防止できる。また通信端末１２は、ユーザにとって違和感のない表示態様で、出力部２６への表示を行うことができる。
【００７３】
図９及び１０を参照し、第二実施例における通信端末２のＣＰＵ２１において実行される通信アプリケーションのメイン処理について説明する。メイン処理は、通信端末２の電源が投入された場合に、ＣＰＵ２１において起動され実行される。Ｓ１４９−Ｓ１５７（図６参照）の処理は、第一実施例と共通である。従って説明を省略又は簡略している。
【００７４】
ＲＡＭ２３に記憶された許諾フラグがＯＦＦされ初期化される（Ｓ２００）。許諾フラグは、Ｓ８７、９３（図８参照）においてユーザの入力操作を受け付けるか否かを判断する場合に使用されるフラグである。詳細は後述する。
【００７５】
Ｐ２Ｐ型の通信を開始する指示がされたかが判断される（Ｓ２０１）。Ｐ２Ｐ型の通信の開始指示は、ユーザの入力操作によって行われるか、又は、他の通信端末２からＲＥＦＥＲパケットを受信することによって行われる。Ｐ２Ｐ型の通信を開始する指示がされた場合（Ｓ２０１：ＹＥＳ、Ｓ１１（図２参照）、Ｓ８１（図８参照））、相手方の通信端末２のＩＤが取得される（Ｓ２０３）。ユーザによって開始指示が入力されている場合（Ｓ１１（図２参照））、開始指示と共にユーザによって入力されたＩＤが取得される。一方、ＲＥＦＥＲパケットが受信されている場合（Ｓ８１（図８参照））、ＲＥＦＥＲパケットに格納されたＩＤが取得される。ＲＥＦＥＲパケットが受信されている場合（Ｓ８１（図８参照））、ＲＥＦＥＲパケットに格納されたキー情報が取得される（Ｓ２０５）。確立要求パケットが、Ｓ２０３で取得されたＩＤを有する他の通信端末２に対して送信される（Ｓ２０７、Ｓ１２（図２参照）、Ｓ８２（図８参照））。Ｓ２０５でキー情報が取得されている場合、取得されたキー情報は確立要求パケットに格納される。ユーザによって開始指示が入力されている場合（Ｓ１１（図２参照））、発呼側表示アプリケーション３３が起動される。ＲＥＦＥＲパケットが受信されている場合（Ｓ８１（図８参照））、着呼側表示アプリケーション３６が起動される。処理はＳ２０１に戻る。
【００７６】
Ｓ２０１で、Ｐ２Ｐ型の通信を開始する指示がされていない場合（Ｓ２０１：ＮＯ）、他の通信端末２から送信された確立要求パケットを受信したかが判断される（Ｓ２１１）。確立要求パケットが受信された場合（Ｓ２１１：ＹＥＳ、Ｓ１３（図２参照）、Ｓ８３（図８参照））、着呼側表示アプリケーション３６が起動される。受信された確立要求パケットにキー情報が格納されている場合、該キー情報が取得される。取得されたキー情報と、事前に通知されたキー情報とが比較される。キー情報が一致する場合（Ｓ２１３：ＹＥＳ）、ユーザによる入力操作に関わらず、確立要求パケットを送信した他の通信端末２との間のセッションの確立は許諾される。許諾フラグがＯＮされる（Ｓ２１５）。処理はＳ２１７に進む。一方、キー情報が相違する場合（Ｓ２１３：ＮＯ）、ユーザによってセッションの確立を許諾する旨の入力操作がされた場合に、セッションの確立は許諾される。許諾フラグはＯＮされない。処理はＳ２１７に進む。なお、受信された確立要求パケットにキー情報が格納されていない場合、許諾フラグはＯＮされることなく（Ｓ２１３：ＮＯ）、処理はＳ２１７に進む。
【００７７】
Ｓ２１７では、起動された着呼側表示アプリケーション３６に対して、着呼通知処理３７（図３参照）の実行が指示される。着呼側表示アプリケーション３６によって着呼通知処理３７が実行される。他の通信端末２からセッションの確立の要求を着呼した旨が、出力部２６に表示される（Ｓ２１７、Ｓ１５（図２参照）、Ｓ８５（図８参照））。処理はＳ２０１に戻る。
【００７８】
Ｓ２１１で、確立要求パケットを受信していないと判断された場合（Ｓ２１１：ＮＯ）、図１０に示すように、許諾フラグがＯＮされているかが判断される（Ｓ２２１）。許諾フラグがＯＮされている場合（Ｓ２２１：ＹＥＳ）、ユーザの入力操作の内容に関わらずセッションの確立は許諾される。確立要求パケットに応じてＯＫ応答パケットを送信するために、処理はＳ２２５に進む。一方、許諾フラグがＯＦＦされている場合（Ｓ２２１：ＮＯ）、ユーザによる入力操作の内容が判断される。セッションを許諾する旨の入力操作がされた場合（Ｓ２２３：ＹＥＳ、Ｓ１７（図２参照）、Ｓ８７（図８参照）、確立要求パケットに応じてＯＫ応答パケットを送信するために、処理はＳ２２５に進む。
【００７９】
Ｓ２２５では、確立要求パケットを送信した他の通信端末２に対して、ＯＫ応答パケットが送信される（Ｓ２２５、Ｓ１８（図２参照）、Ｓ８８（図８参照））。送信されたＯＫ応答パケットに応じ、他の通信端末２から送信されるＡＣＫパケットが受信される（Ｓ２２７、Ｓ２３（図２参照）、Ｓ９５（図８参照））。他の通信端末２との間のセッションが確立したと判断される。起動された着呼側表示アプリケーション３６に対して、確立通知処理３８（図３参照）の実行が指示される。通信端末１２との間のセッションが確立された旨が、ユーザに通知される（Ｓ２５１、Ｓ２５（図２参照）、Ｓ９７（図８参照））。処理はＳ１４９（図６参照）に進む。Ｓ１４９−Ｓ１５７の説明は後述する。
【００８０】
Ｓ２２３で、セッションの確立を許諾する指示がユーザによって入力されない場合（Ｓ２２３：ＮＯ）、他の通信端末２からＯＫ応答パケットを受信したかが判断される（Ｓ２２９）。ＯＫ応答パケットが受信されない場合（Ｓ２２９：ＮＯ）、処理はＳ２０１（図９参照）に戻る。ＯＫ応答パケットが受信された場合（Ｓ２２９：ＹＥＳ、Ｓ１９（図２参照）、Ｓ８９（図８参照））、ＲＥＦＥＲパケットを受信した後、Ｓ２０７（図９参照）で確立要求パケットを受信しているかが判断される（Ｓ２３１）。ＲＥＦＥＲパケットを受信していない場合（Ｓ２３１：ＮＯ）、正規の呼制御通信（図２参照）の手順に基づいて通信が行われている。このためＳ２０７では、ユーザからの開始指示に応じて確立要求パケットが他の通信端末２に対して送信されている。ＯＫ応答パケットを送信した他の通信端末２に対して、ＡＣＫパケットが送信される（Ｓ２３３、Ｓ２２（図２参照））。発呼側表示アプリケーション３３が起動されているので、発呼側表示アプリケーション３３に対して、確立通知処理３４（図３参照）の実行が指示される。他の通信端末２との間のセッションが確立された旨が、ユーザに通知される（Ｓ２５１、Ｓ２１（図２参照））。処理はＳ１４９（図６参照）に進むＳ１４９−Ｓ１５７の説明は後述する。
【００８１】
一方、Ｓ２３１でＲＥＦＥＲパケットが受信されている場合（Ｓ２３１：ＹＥＳ）、受信されたＲＥＦＥＲパケットに応じて確立要求パケットが送信された後、Ｓ２２９でＯＫ応答パケットが受信されていることになる（Ｓ８９、図８参照）。例外的な呼制御通信（図８参照）の手順に基づいて通信が行われている。着呼側表示アプリケーション３６が起動されているので、着呼側表示アプリケーション３６に対して、着呼通知処理３７（図８参照）の実行が指示される。セッションの確立の要求を着呼した旨が、ユーザに通知される（Ｓ２３５、Ｓ９１（図８参照））。
【００８２】
許諾フラグがＯＮされているかが判断される（Ｓ２３７）。許諾フラグがＯＮされている場合（Ｓ２３７：ＹＥＳ）、ユーザの入力操作の内容に関わらずセッションの確立は許諾される。処理はＳ２４１に進む。一方、許諾フラグがＯＦＦされている場合（Ｓ２３７：ＮＯ）、ユーザによる入力操作の内容が判断される（Ｓ２３９）。セッションを許諾する指示が入力されない場合（Ｓ２３９：ＮＯ）、処理はＳ２０１（図９参照）に戻る。セッションを許諾する指示が入力された場合（Ｓ２３９：ＹＥＳ、Ｓ９３（図８参照））、処理はＳ２４１に進む。
【００８３】
Ｓ２４１では、確立要求パケットを送信した他の通信端末２に対してＡＣＫパケットが送信される（Ｓ２４１、Ｓ９４（図８参照））。着呼側表示アプリケーション３６に対して、確立通知処理３８の実行が指示される。通信端末１３との間のセッションが確立された旨が、出力部２６に表示される（Ｓ２５１、Ｓ９８（図８参照））。処理はＳ１４９（図６参照）に進む。
【００８４】
図６に示すように、上述の呼制御通信を経て、他の通信端末２との間のセッションが確立された状態になる（Ｓ１４９）。他の通信端末２との間でＰ２Ｐ通信が開始される（Ｓ１５１）。他の通信端末２からデータが受信された場合（Ｓ１５３：ＹＥＳ、Ｓ２８（図２参照）、３４（図２参照）、１０１（図８参照）、１０７（図８参照））、表示アプリケーション３２（図３参照）に対して、受信通知処理３５、３９（図３参照）の実行が指示される。他の通信端末２からデータを受信した旨が、受信したデータと共に出力部２６に表示される（Ｓ１５５、Ｓ３１（図２参照）、Ｓ３７（図２参照）、Ｓ１０３（図８参照）、Ｓ１０９（図８参照））。処理はＳ１５７に進む。他の通信端末２からデータが受信されなかった場合（Ｓ１５３：ＮＯ）、処理はＳ１５７に進む。
【００８５】
他の通信端末２との間のＰ２Ｐ通信を終了させる指示が、ユーザによって入力されたかが判断される（Ｓ１５７）。Ｐ２Ｐ通信を終了させる指示が入力されていない場合（Ｓ１５７：ＮＯ）、処理はＳ１５１に戻る。Ｐ２Ｐ通信を終了させる指示が入力された場合（Ｓ１５７：ＹＥＳ）、メイン処理は終了する。
【００８６】
以上説明したように、第二実施例では、通信端末１２は、通信端末１４からＲＥＦＥＲパケットを受信した場合、通信端末１３に対して確立要求パケットを送信することができる。これによって通信端末１２は、通信端末１３との間のセッションを確立させるための通信手順を多様化することができるので、状況に応じて様々な手順で通信を行い、通信端末１３との間のセッションを確立させることができる。また通信端末１２の出力部２６には、他の通信端末２から確立要求パケットが受信された場合と同様の表示態様で情報が表示される。従って通信端末１２は、呼制御通信が異なる通信手順で実行された場合でも、出力部２６に表示される情報が多様化し且つ複雑化することを防止できる。また通信装置２は、ユーザの認識する通信端末２の状態と、実際に表示される情報とを一致させることができる。これによって通信端末２は、ユーザにとって違和感のない表示態様で、出力部２６への表示を行うことができる。
【００８７】
なお本発明は上述の実施形態に限定されず、種々の変更が可能である。ユーザに対する通知処理は、着呼通知処理、確立通知処理、及び受信通知処理に限定されない。他の態様の通知処理によってユーザに呼制御通信の内容を通知してもよい。又、各通知処理による通知のタイミングは、上述の実施形態に限定されない。例えは図２において、通信端末１２はＡＣＫパケット（Ｓ２２）を送信しなくてもよい。通信端末１３は、Ｓ１８でＯＫ応答パケットを送信した場合に、確立通知処理を実行してもよい。同様に図３では、通信端末１２はＡＣＫパケット（Ｓ６５）を送信しなくてもよい。通信端末１３は、Ｓ５３でＯＫ応答パケットを送信した場合に、確立通知処理を実行してもよい。図８では、通信端末１２はＡＣＫパケット（Ｓ９４）を送信しなくてもよい。通信端末１２は、ＯＫ応答パケットを受信した（Ｓ８９）場合に、着呼通知処理及び確立通知処理を実行してもよい。通信端末１３は、Ｓ８８でＯＫ応答パケットを送信した場合に、確立通知処理を実行してもよい。
【００８８】
通信端末２間の呼制御通信は、サーバ１１を介さず、通信端末２間で直接実行されてもよい。通信端末２は、通信機能のみを備えた機器（モデムなど）であってもよい。通信端末２は、外部に接続されたディスプレイに通知情報を表示することによって、各種通知処理を実行してもよい。
【００８９】
本発明は、上述の第一実施例及び第二実施例における例外的な呼制御通信の手順に限定されない。ＩＤの比較後に通信端末２から送信されるＯＫ応答パケット又はＮＧ応答パケットの送信タイミングを変更してもよい。具体的には、例えば、ＩＤを比較してからＮＧ応答パケットを送信するまでの時間は、ＯＫ応答パケットを送信するまでの時間よりも長くしてもよい。又は、ＮＧ応答パケットを送信するタイミングは、相手方の通信端末２からＯＫ応答パケットを受信した後であってもよい。これらによって、其々の通信端末２から送信されるＯＫ応答パケットとＮＧ応答パケットとが、通信経路上で衝突してしまい、呼制御通信が失敗してしまうことを防止できる。
【００９０】
上述において、通信端末２は、確立要求パケットの送信後、相手方の通信端末２から確立要求パケットを受信した場合、ＩＤの比較処理を行うことなく、相手方の通信端末２に対してＯＫ応答パケットを送信してもよい。
【００９１】
例えば以下のように通信を行ってもよい。通信端末１３は、確立要求パケットの送信後、通信端末１２から応答パケットを受信する前に、確立要求パケットを受信する。通信端末１３は、確立要求パケットに付加されていたＩＤと自身のＩＤとを比較する。通信端末１３は、確立要求パケットに付加されていたＩＤよりも自身のＩＤの方が大きいので、通信端末１２に対して確立要求パケットを再送する。一方通信端末１２は、確立要求パケットの送信後、通信端末１３から応答パケットを受信する前に、確立要求パケットを受信する。通信端末１２は、確立要求パケットに付加されていたＩＤよりも自身のＩＤの方が小さいので、パケットを返信せず、そのまま待機する。通信端末１２は、通信端末１３から再送された確立要求パケットを受信し、通信端末１３に対してＯＫ応答パケットを送信する。以上の方法によっても、通信端末１２と通信端末１３との間のセッションは確立するので、通信端末１２と通信端末１３との間でＰ２Ｐ通信を開始することが可能となる。
【００９２】
なお、Ｓ１１５の処理を行うＣＰＵ２１が本発明の「第一要求手段」に相当する。Ｓ１１７の処理を行うＣＰＵ２１が本発明の「第一受付手段」「第二受付手段」に相当する。Ｓ１４９の処理を行うＣＰＵ２１が本発明の「第一確立手段」「第二確立手段」「第三確立手段」に相当する。Ｓ１３３、Ｓ１３９、及びＳ１７１の処理を行うＣＰＵ２１が本発明の「第一通知手段」に相当する。Ｓ１２１、Ｓ２１７、Ｓ２３５、及びＳ２５１の処理を行うＣＰＵ２１が本発明の「第二通知手段」に相当する。Ｓ２０７の処理を行うＣＰＵ２１が本発明の「第二要求手段」に相当する。Ｓ１１５の処理が本発明の「第一要求ステップ」に相当する。Ｓ１１７の処理が本発明の「第一受付ステップ」に相当する。Ｓ１４９の処理が本発明の「第一確立ステップ」「第二確立ステップ」に相当する。Ｓ１３３、Ｓ１３９、及びＳ１７１の処理を行うＣＰＵ２１が本発明の「第一通知ステップ」に相当する。Ｓ１２１、Ｓ２１７、Ｓ２３５、及びＳ２５１の処理を行うＣＰＵ２１が本発明の「第二通知ステップ」に相当する。
【符号の説明】
【００９３】
１      通信システム
２、１２、１３、１４  通信端末
１１    サーバ
２１    ＣＰＵ
２４    ＨＤＤ
２６    出力部
【図１】
2012231359.tif 000003
【図２】
2012231359.tif 000004
【図３】
2012231359.tif 000005
【図４】
2012231359.tif 000006
【図５】
2012231359.tif 000007
【図６】
2012231359.tif 000008
【図７】
2012231359.tif 000009
【図８】
2012231359.tif 000010
【図９】
2012231359.tif 000011
【図１０】
2012231359.tif 000012