(57)【要約】【課題】３ＰＣＣ方式を用いて第三者呼制御を実行する場合に、呼制御端末の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザに通信相手を確認させることを課題とする。【解決手段】ＳＩＰサーバは、呼制御端末であるＵＡ３から、ユーザ端末であるＵＡ１とＵＡ２との呼接続を指示するＩＮＶＩＴＥ信号を受信すると、各ＩＮＶＩＴＥ信号のヘッダ内に挿入された第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼が行われたかどうかを検証する。ＳＩＰサーバは、検証の結果、第三者呼制御の情報に記述の通りの発呼が行われている場合には、ＵＡ３を起点とした第三者呼制御により端末間（ＵＡ１−ＵＡ２間）を接続する信号であることを保証するための保証情報をＩＮＶＩＴＥ信号のヘッダに挿入して、接続対象のＵＡ１およびＵＡ２へそれぞれ中継する。【選択図】        図１
2010178290.tif 000002
【特許請求の範囲】
【請求項１】
端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、前記呼制御端末を起点とした第三者呼制御による前記端末間の通信を確立するサーバ装置であって、
端末間の接続を指示するためのリクエスト信号を前記呼制御端末からそれぞれ受信した場合に、当該リクエスト信号の各々が有するヘッダ内に前記呼制御端末により挿入された第三者呼制御の情報をそれぞれ参照して、当該第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われたか否かを検証する発呼検証手段と、
前記発呼検証手段による検証の結果、前記第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われている場合には、前記リクエスト信号を前記接続対象の各端末へそれぞれ中継する中継手段と、
端末間でセッション情報をやり取りするための信号を前記呼制御端末から受信した場合に、前記第三者呼制御の情報に基づいて、前記セッション情報に含まれるＩＰアドレスを検証するアドレス検証手段と、
前記アドレス検証手段によるＩＰアドレスの検証に成功した場合には、前記端末間の通信を許可する通信許可手段と
を備えたことを特徴とするサーバ装置。
【請求項２】
前記第三者呼制御の情報が示すとおりに、前記第三者呼制御による端末間の接続のための発呼が行われている場合には、前記呼制御端末を起点とした第三者呼制御により端末間を接続する信号であることを保証する保証情報を、端末間の接続を指示するためのリクエスト信号にそれぞれ挿入する挿入手段をさらに備え、
前記中継手段は、前記挿入手段により前記保証情報が挿入されたリクエスト信号を中継することを特徴とする請求項１に記載のサーバ装置。
【請求項３】
端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、前記呼制御端末を起点とした第三者呼制御による前記端末間の通信を確立する通信処理システムであって、
端末間の接続を指示するためのリクエスト信号を呼制御端末から最初に受信するサーバ装置は、
前記リクエスト信号の各々が有するヘッダ内に前記呼制御端末により挿入された第三者呼制御の情報をそれぞれ参照して、当該第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われたか否かを検証する発呼検証手段と、
前記検証手段による検証の結果、前記第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われている場合には、前記リクエスト信号を前記接続対象の各端末へそれぞれ中継する中継手段と、
端末間でセッション情報をやり取りするためのリクエスト信号を前記呼制御端末から受信した場合に、前記第三者呼制御の情報に基づいて、前記セッション情報に含まれるＩＰアドレスを検証するアドレス検証手段と、
前記アドレス検証手段によるＩＰアドレスの検証に成功した場合には、前記端末間の通信を許可する通信許可手段と
を備えたことを特徴とする通信処理システム。
【請求項４】
前記第三者呼制御の情報が示すとおりに、前記第三者呼制御による端末間の接続のための発呼が行われている場合には、前記呼制御端末を起点とした第三者呼制御により端末間を接続する信号であることを保証する保証情報を、端末間の接続を指示するためのリクエスト信号にそれぞれ挿入する挿入手段をさらに備え、
前記中継手段は、前記挿入手段により前記保証情報が挿入されたリクエスト信号を中継することを特徴とする請求項３に記載の通信処理システム。
【請求項５】
端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、前記呼制御端末を起点とした第三者呼制御による前記端末間の通信を確立する通信処理方法であって、
端末間の接続を指示するためのリクエスト信号を前記呼制御端末からそれぞれ受信した場合に、当該リクエスト信号の各々が有するヘッダ内に前記呼制御端末により挿入された第三者呼制御の情報をそれぞれ参照して、当該第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われたか否かを検証する発呼検証ステップと、
前記発呼検証ステップによる検証の結果、前記第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われている場合には、前記リクエスト信号を前記接続対象の各端末へそれぞれ中継する中継ステップと、
端末間でセッション情報をやり取りするためのリクエスト信号を前記呼制御端末から受信した場合に、前記第三者呼制御の情報に基づいて、前記セッション情報に含まれるＩＰアドレスを検証するアドレス検証ステップと、
前記アドレス検証ステップによるＩＰアドレスの検証に成功した場合には、前記端末間の通信を許可する通信許可ステップと
を含んだことを特徴とする通信処理方法。
【請求項６】
前記第三者呼制御の情報が示すとおりに、前記第三者呼制御による端末間の接続のための発呼が行われている場合には、前記呼制御端末を起点とした第三者呼制御により端末間を接続する信号であることを保証する保証情報を、端末間の接続を指示するためのリクエスト信号にそれぞれ挿入する挿入ステップをさらに含み、
前記中継ステップは、前記挿入ステップにより前記保証情報が挿入されたリクエスト信号を中継することを特徴とする請求項５に記載の通信処理方法。
【請求項７】
端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、前記呼制御端末を起点とした第三者呼制御による前記端末間の通信を確立する処理をコンピュータに実行させる通信処理プログラムであって、
端末間の接続を指示するためのリクエスト信号を前記呼制御端末からそれぞれ受信した場合に、当該リクエスト信号の各々が有するヘッダ内に前記呼制御端末により挿入された第三者呼制御の情報をそれぞれ参照して、当該第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われたか否かを検証する発呼検証手順と、
前記発呼検証手順による検証の結果、前記第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われている場合には、前記リクエスト信号を前記接続対象の各端末へそれぞれ中継する中継手順と、
端末間でセッション情報をやり取りするためのリクエスト信号を前記呼制御端末から受信した場合に、前記第三者呼制御の情報に基づいて、前記セッション情報に含まれるＩＰアドレスを検証するアドレス検証手順と、
前記アドレス検証手順によるＩＰアドレスの検証に成功した場合には、前記端末間の通信を許可する通信許可手順と
をコンピュータに実行させることを特徴とする通信処理プログラム。
【請求項８】
前記第三者呼制御の情報が示すとおりに、前記第三者呼制御による端末間の接続のための発呼が行われている場合には、前記呼制御端末を起点とした第三者呼制御により端末間を接続する信号であることを保証する保証情報を、端末間の接続を指示するためのリクエスト信号にそれぞれ挿入する挿入手順をさらにコンピュータに実行させ、
前記中継手順は、前記挿入手順により前記保証情報が挿入されたリクエスト信号を中継することを特徴とする請求項７に記載の通信処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、サーバ装置、通信処理システム、通信処理方法および通信処理プログラムに関する。
【背景技術】
【０００２】
ＩＳＰ（Internet Service Provider）が提供するＶｏＩＰ（Voice over Internet Protocol）サービスなどのように、管理されたネットワーク内で利用されるSIP（Session Initiation Protocol）では、第三者呼制御と呼ばれる呼制御方式を用いて、発着信端末間を接続することが可能である。代表的なものとして、例えば、ＳＩＰの第三者呼制御の基本メソッドのみを利用する３ＰＣＣ方式（非特許文献１参照）が存在する。
【０００３】
そして、上記３ＰＣＣ方式の利用シーンとして、例えば、図９に示すように、外部からの操作を受け付けてユーザ間の接続を行うシステム（ＵＡ３）を呼制御者として、利用者１（ＵＡ１）と利用者２（ＵＡ２）との間の第三者呼制御を実行し、ユーザ間接続を支援するサービスが考えられる。この場合、利用者１および利用者２は、着信許可・拒否などの制御を行うために、第三者呼制御により接続される相手を確認する必要がある。図９は、３ＰＣＣ方式が利用されるサービス例を示す図である。
【０００４】
そこで、上記３ＰＣＣ方式では、第三者呼制御により接続される通信相手を特定する情報（例えば、名前や電話番号）を各端末へ通知するための仕組みを有する。
【０００５】
例えば、図１０に示すように、上記３ＰＣＣ方式では、呼制御者であるシステム（ＵＡ３）から、利用者１（ＵＡ１）および利用者２（ＵＡ２）に送信されるリクエスト（ＩＮＶＩＴＥ）に含まれるヘッダＦｒｏｍ行の表示名に、通信相手の識別情報（例えば、From:UA3 On behalf of UA2，From:UA3 On behalf of UA1）を挿入することで、利用者１および利用者２に対して、第三者呼制御により接続される通信相手を通知する。図１０は、３ＰＣＣ方式における従来の仕組みを説明するための図である。
【０００６】
【非特許文献１】Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP), RFC3725
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記した通信相手を通知する仕組みでは、呼制御者から各ユーザに対して通知される情報の信頼性が、呼制御者の端末の動作に依存してしまうという問題点があった。すなわち、上記３ＰＣＣ方式により各ユーザ（ＵＡ１およびＵＡ２）に通知される情報は、呼制御者側（ＵＡ３）で挿入される情報であり、発信者番号通知により網から通知される発信者番号にように、信頼性のおける網で保証されたような情報ではなく、信頼性に欠ける。
【０００８】
例えば、上述した図９に示す利用シーンでは、利用者１（ＵＡ１）および利用者２（ＵＡ２）に送信されるリクエスト（ＩＮＶＩＴＥ）に追加された通信相手の識別情報（例えば、From:UA3 On behalf of UA2，From:UA3 On behalf of UA1）は、呼制御者であるシステム（ＵＡ３）により挿入された情報であるので、通信相手の識別情報の信頼度は個性御者であるシステム側の動作に依存してしまう。
【０００９】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、３ＰＣＣ方式を用いて第三者呼制御を実行する場合に、呼制御端末の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザに通信相手を確認させることが可能なサーバ装置、通信処理システム、通信処理方法および通信処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するため、本発明は、端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、前記呼制御端末を起点とした第三者呼制御による前記端末間の通信を確立するサーバ装置であって、端末間の接続を指示するためのリクエスト信号を前記呼制御端末からそれぞれ受信した場合に、当該リクエスト信号の各々が有するヘッダ内に前記呼制御端末により挿入された第三者呼制御の情報をそれぞれ参照して、当該第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われたか否かを検証する発呼検証手段と、前記発呼検証手段による検証の結果、前記第三者呼制御の情報が示すとおりに、前記第三者呼制御により端末間を接続するための発呼が行われている場合には、前記リクエスト信号を前記接続対象の各端末へそれぞれ中継する中継手段と、端末間でセッション情報をやり取りするためのリクエスト信号を前記呼制御端末から受信した場合に、前記第三者呼制御の情報に基づいて、前記セッション情報に含まれるＩＰアドレスを検証するアドレス検証手段と、前記アドレス検証手段によるＩＰアドレスの検証に成功した場合には、前記端末間の通信を許可する通信許可手段とを備えたことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、３ＰＣＣ方式を用いて第三者呼制御を実行する場合に、呼制御端末の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザに通信相手を確認させることができる。
【発明を実施するための最良の形態】
【００１２】
以下に添付図面を参照して、この発明に係るサーバ装置、通信処理システム、通信処理方法および通信処理プログラムの一実施形態について詳細に説明する。なお、以下では、本発明に係るサーバ装置としてＳＩＰサーバを例に挙げ、実施例１に係るＳＩＰサーバを説明した後に、本発明に含まれる他の実施形態について説明する。
【実施例１】
【００１３】
以下の実施例１では、実施例１に係るＳＩＰサーバの概要および特徴、かかるＳＩＰサーバの構成および動作を順に説明し、最後に実施例１による効果を説明する。
【００１４】
［ＳＩＰサーバの概要および特徴（実施例１）］
まず、図１を用いて、実施例１に係るＳＩＰサーバの概要および特徴を説明する。図１は、実施例１に係るＳＩＰサーバの特徴を説明するための図である。
【００１５】
実施例１に係るＳＩＰサーバは、端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、呼制御端末を起点とした３ＰＣＣ方式による端末間の通信（ＳＩＰセッション）を確立することを概要とする。
【００１６】
そして、実施例１に係るＳＩＰサーバは、３ＰＣＣ方式を用いて第三者呼制御を実行する場合に、呼制御端末の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザに通信相手を確認させることができる点に特徴がある。
【００１７】
この特徴について具体的に説明すると、実施例１に係るＳＩＰサーバは、図１に示すように、呼制御端末であるＵＡ３から、ユーザ端末であるＵＡ１とＵＡ２との呼接続を指示するＩＮＶＩＴＥ信号を受信すると、各ＩＮＶＩＴＥ信号のヘッダ内に挿入された第三者呼制御の情報（第三者呼制御ヘッダ）をそれぞれ参照して、ＩＮＶＩＴＥ信号の結びつけを行う（図１の（１）参照）。すなわち、第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼が行われたかどうかを検証する。
【００１８】
具体的には、実施例１に係るＳＩＰサーバは、ＵＡ３を起点とした第三者呼制御によりＵＡ１およびＵＡ２をこれから接続することを示したＩＮＶＩＴＥ信号の一方に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）と、ＵＡ３を起点とした第三者呼制御によりＵＡ１およびＵＡ２をこれから接続することを示したＩＮＶＩＴＥ信号の他方に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）との整合性を検証する。
【００１９】
なお、第三者呼制御の情報（第三者呼制御ヘッダ）は、各ＵＡに一意な電話番号を含んで構成される情報であり、第三者呼制御であることを示す情報として、呼制御端末であるＵＡ３によりＩＮＶＩＴＥ信号のヘッダに挿入される。
【００２０】
実施例１に係るＳＩＰサーバは、検証の結果、第三者呼制御の情報（第三者呼制御ヘッダ）間に整合性がある場合には、第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼が行われたものと判断して、ＵＡ３を起点とした第三者呼制御によりＵＡ１およびＵＡ２を接続する信号であることを保証するための保証情報をＩＮＶＩＴＥ信号のヘッダに挿入して、接続対象のＵＡ１およびＵＡ２へそれぞれ中継する（図１の（２）参照）。
【００２１】
なお、保証情報は、各ＵＡに一意な電話番号を含んで構成される第三者呼制御の情報（第三者呼制御ヘッダ）と同様の情報であり、接続対象となる各ＵＡ（ＵＡ１，ＵＡ２）に対して接続相手を通知できる。
【００２２】
このようなことから、実施例１に係るＳＩＰサーバは、３ＰＣＣ方式を用いて第三者呼制御を実行する場合に、呼制御端末（ＵＡ３）の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザ（ＵＡ１，ＵＡ２）に通信相手を確認させることができる。
【００２３】
なお、上記以降の実施例１に係るＳＩＰサーバの動作について、以下に簡単に説明する。ＳＩＰサーバは、ＩＮＶＩＴＥ信号を着信した各ＵＡから発信されるレスポンス信号を受信した場合に、レスポンス信号の各々に含まれる接続対象のＵＡに一意なＩＰアドレスを、第三者呼制御の情報（第三者呼制御ヘッダ）をそれぞれ参照して検証し、検証の結果に基づいて接続対象となるＵＡ間（ＵＡ１とＵＡ２）の通信を許可するか否かを決定する。
【００２４】
具体的には、例えば、ＵＡ１から発信されたレスポンス信号は、ＵＡ３に受信された後、ＵＡ３の電話番号を発信者番号として、ＵＡ３からのリクエスト信号として転送されてくる。実施例１に係るＳＩＰサーバは、ＵＡ３から受信するリクエスト信号の発信者番号（ＵＡ３の番号）と、リクエスト信号に含まれるＩＰアドレス（ＵＡ１のアドレス）の対応が異なるが、リクエスト信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）を参照して、ＵＡ３を起点とした第三者呼制御であることを確認すると、ＵＡ間（ＵＡ１とＵＡ２）の通信を許可することを決定し、以後の信号のやり取りを許容する。このようにして、呼制御端末（ＵＡ３）の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザ（ＵＡ１，ＵＡ２）に通信相手を確認させるとともに、第三者呼制御による通信を実施可能とする。
【００２５】
［ＳＩＰサーバの構成（実施例１）］
次に、図２を用いて、実施例１に係るＳＩＰサーバの構成を説明する。図２は、実施例１に係るＳＩＰサーバの構成を示す図である。
【００２６】
図２に示すユーザ端末１００およびユーザ端末２００は、ＳＩＰサーバ４００から受信したＩＮＶＩＴＥ信号に含まれるヘッダ内の保証情報を参照して、接続相手の確認を行った後、セッション情報（ＩＰアドレス等）をやり取りするために、ＩＮＶＩＴＥ信号に対するレスポンス信号（例えば、「２００  ＯＫ  ＳＤＰ  ｏｆｆｅｒ」、「２００  ＯＫ  ＳＤＰ  ａｎｓｗｅｒ」など）を発信する。
【００２７】
呼制御端末３００は、第三者呼制御の接続対象であるユーザ端末１００およびユーザ端末２００へ向けて、自らを起点とした第三者呼制御により、ユーザ端末１００およびユーザ端末２００をこれから接続することを示した第三者呼制御の情報（第三者呼制御ヘッダに記述される情報）を、ＩＮＶＩＴＥ信号のヘッダに挿入して発信する。また、ＳＩＰサーバ４００を介して、ユーザ端末１００あるいはユーザ端末２００から発信されたレスポンス信号を受信すると、レスポンス信号に第三者呼制御の情報を挿入してＳＩＰサーバ４００へ転送する。
【００２８】
また、呼制御端末３００によりＩＮＶＩＴＥ信号のヘッダに挿入される第三者呼制御の情報（第三者呼制御ヘッダに記述される情報）は、ユーザ端末１００およびユーザ端末２００を第三者呼制御により接続するためにユーザ端末１００へ向けてＩＮＶＩＴＥ信号を発信する場合、ヘッダのＦｒｏｍ行に、「From:<UA3 on behalf of UA2>」といった形式で記述される。および一方、ユーザ端末１００とユーザ端末２００を第三者呼制御により接続するためにユーザ端末２００へ向けてＩＮＶＩＴＥ信号を発信する場合、ヘッダのＦｒｏｍ行に、「From:<UA3 on behalf of UA1>」といった形式で記述される（図３の（２）参照）。なお、「ＵＡ１」、「ＵＡ２」および「ＵＡ３」は、ユーザ端末１００、ユーザ端末２００および呼制御端末３００の電話番号を表す。
【００２９】
実施例１に係るＳＩＰサーバ４００は、図２に示すように、ＳＩＰ網１を介して、ユーザ端末１００、ユーザ端末２００および呼制御端末３００と通信可能な状態で接続され、通信制御部４１０および制御部４２０を有する。
【００３０】
通信制御部４１０は、ユーザ端末１００、ユーザ端末２００および呼制御端末３００との間でやり取りするＳＩＰ信号や各種情報（セッション情報）に関する通信を制御する。
【００３１】
制御部４２０は、所定の制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。そして、制御部４２０は、ＳＩＰサーバ４００に密接に関連するものとしては、特に、信号検証部４２１および信号中継部４２２を有する。
【００３２】
信号検証部４２１は、呼制御端末３００から、ユーザ端末１００とユーザ端末２００との呼接続を指示するＩＮＶＩＴＥ信号を受信すると、各ＩＮＶＩＴＥ信号に含まれるヘッダ内の情報をそれぞれ参照して、ＩＮＶＩＴＥ信号の結びつけを行う。なお、信号検証部４２１は、特許請求の範囲に記載の「発呼検証手段」に対応する。
【００３３】
具体的には、信号検証部４２１は、呼制御端末３００を起点とした第三者呼制御によりユーザ端末１００およびユーザ端末２００をこれから接続することを示した一方のＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）と、呼制御端末３００を起点とした第三者呼制御によりユーザ端末１００およびユーザ端末２００をこれから接続することを示した他方のＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）との整合性を検証する。
【００３４】
信号検証部４２１は、例えば、呼制御端末３００から受信したＩＮＶＩＴＥ信号の一方に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）が「From:<UA3 on behalf of UA2>」で、ＩＮＶＩＴＥ信号の他方に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）が「From:<UA3 on behalf of UA1>」である場合には、第三者呼制御の情報（第三者呼制御ヘッダ）間に整合性があるものとする。そして、信号検証部４２１は、信号の中継指示を信号中継部４２２に送出する。
【００３５】
信号検証部４２１は、検証の結果、呼制御端末３００から受信した各ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）間に整合性がない場合（第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼が行われなかった場合）には、呼制御端末３００からのＩＮＶＩＴＥ信号を中継せず、セッションを切断する。
【００３６】
信号中継部４２２は、信号検証部４２１から信号の中継指示を受け付けると、信号の発信者である呼制御端末３００の電話番号の情報（発信者番号）、および呼制御端末３００を起点とした第三者呼制御によりユーザ端末１００およびユーザ端末２００を接続する信号であることを保証するための保証情報をＩＮＶＩＴＥ信号のヘッダにそれぞれ挿入して、ユーザ端末１００およびユーザ端末２００にそれぞれ中継する。なお、信号中継部４２２は、特許請求の範囲に記載の「中継手段」および「アドレス検証手段」に対応する。
【００３７】
信号の発信者である呼制御端末３００の電話番号の情報として、信号中継部４２２によりＩＮＶＩＴＥ信号に挿入される発信者番号は、「P-Asserted-Identity:UA3」という形式でヘッダに記述される（図３の（１）参照）。なお、信号中継部４２２は、後述する従来技術を用いた検証に成功した場合には、ＩＮＶＩＴＥ信号に発信者番号を挿入して中継するが、後述する従来技術を用いた検証に失敗した場合には、ＩＮＶＩＴＥ信号を中継せずに、セッションを切断する。
【００３８】
信号中継部４２２によりＩＮＶＩＴＥ信号に挿入される保証情報は、呼制御端末３００を起点とした第三者呼制御より、ユーザ端末１００およびユーザ端末２００を接続するために、ユーザ端末１００に対してＩＮＶＩＴＥ信号を中継する場合、「P-Asserted-Identity:<UA3 on behalf of UA2>」、もしくは「P-3pcc-Identity:UA3」といった形式でヘッダに記述される（図３の（２）参照）。一方、呼制御端末３００を起点とした第三者呼制御より、ユーザ端末１００およびユーザ端末２００を接続するために、ユーザ端末２００に対してＩＮＶＩＴＥ信号を中継する場合、「P-Asserted-Identity:<UA3 on behalf of UA1>」、もしくは「P-3pcc-Identity:UA3」といった形式でヘッダに記述される（図３の（３）参照）。なお、図３は、実施例１に係るヘッダの記述例を示す図である。また、「ＵＡ１」、「ＵＡ２」および「ＵＡ３」は、ユーザ端末１００、ユーザ端末２００および呼制御端末３００の電話番号をそれぞれ表す。
【００３９】
また、信号中継部４２２は、ユーザ端末１００とユーザ端末２００端末との間でセッション情報をやり取りするための信号（ＩＮＶＩＴＥ、ｒｅ‐ＩＮＶＩＴＥなど）を呼制御端末３００から受信した場合に、この信号の発信元と当該セッション情報に含まれるＩＰアドレスとの対応関係を第三者呼制御の情報に基づいて検証し、検証の結果に基づいてユーザ端末１００とユーザ端末２００との間の通信を許可するか否かを決定する。
【００４０】
なお、信号検証部４２１および信号中継部４２２による詳細な動作については、後に具体的な信号のやり取りを交えて詳細に説明する。
【００４１】
まず、図４を用いて、信号中継部４２２が前提とする従来技術（発信者番号通知）の仕組みについて説明する。図４は、従来技術（発信者番号通知）を説明するための図である。
【００４２】
同図に示すように、ＳＩＰサーバ４００を介して接続されたユーザ端末１００とユーザ端末２００との間で通信を行う場合を例に挙げる。ＳＩＰサーバ４００は、ユーザ端末１００およびユーザ端末２００の電話番号およびＩＰアドレスの対応関係を予め認識しているものとする。
【００４３】
ユーザ端末１００からユーザ端末２００へ向けた信号（ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ）が発信される（ステップＳ１）。この信号には、信号の発信元を示すユーザ端末１００の電話番号（「Ｆｒｏｍ：１１１１」）、信号の宛先を示すユーザ端末２００の電話番号（「Ｔｏ：２２２２」）、および信号の発信元であるユーザ端末１００のＩＰアドレス（「ｃ＝Ｉｐ１」）がそれぞれ挿入されている。
【００４４】
ＳＩＰサーバ４００は、ユーザ端末１００からの信号を受信すると、信号内の情報を参照して、信号の発信元であるユーザ端末１００の電話番号と、ＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ２）。検証の結果、電話番号とＩＰアドレスとの対応関係が正しい場合には、ユーザ端末１００からの信号に、ユーザ端末１００の電話番号を発信者番号として挿入して（「ＰＡＩ：１１１１」）、ユーザ端末２００に転送する（ステップＳ３）。
【００４５】
ユーザ端末２００は、ＳＩＰサーバ４００を介して、ユーザ端末１００からの信号を受信すると、信号の発信者番号がユーザ端末１００の番号であることを確認して、ユーザ端末１００へ向けたレスポンス信号（２００  ＯＫ  ＳＤＰ  ａｎｓｗｅｒ）を発信する（ステップＳ４）。このレスポンス信号には、レスポンス信号の発信元であるユーザ端末２００の電話番号（「Ｆｒｏｍ：２２２２」）、信号の宛先を示すユーザ端末１００の電話番号（「Ｔｏ：１１１１」）、および信号の発信元であるユーザ端末２００のＩＰアドレス（「ｃ＝Ｉｐ２」）がそれぞれ挿入されている。
【００４６】
ＳＩＰサーバ４００は、ユーザ端末２００からのレスポンス信号を受信すると、信号内の情報を参照して、信号の発信元であるユーザ端末２００の電話番号と、ＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ５）。検証の結果、電話番号とＩＰアドレスとの対応関係が正しい場合には、ユーザ端末２００からのレスポンス信号をユーザ端末１００に転送する（ステップＳ６）。
【００４７】
ユーザ端末１００が、ＳＩＰサーバ４００を介して、ユーザ端末２００からのレスポンス信号を受信すると、ユーザ端末１００とユーザ端末２００との間で、互いのＩＰアドレスの交換が完了する。そこで、ユーザ端末１００とユーザ端末２００は、通信相手のＩＰアドレスを用いて通信を開始する（ステップＳ７）。
【００４８】
上述してきた従来技術の仕組みを前提として、信号中継部４２２は、以下に説明するように、ユーザ端末１００とユーザ端末２００との間の通信を許可するか否かを決定する。なお、以下では、ユーザ端末１００、ユーザ端末２００および呼制御端末３００との間で、それぞれ信号のやり取りの仕方が異なるフロー１とフロー２を例に挙げて、信号中継部４２２における通信許可決定までの流れを説明する。
【００４９】
［フロー１］
まず、フロー１における通信許可決定までの流れを説明する。前提として、ＳＩＰサーバ４００は、まず、ユーザ端末１００、ユーザ端末２００および呼制御端末３００の電話番号と、ＩＰアドレスとの対応関係を予め認識しているものとする。
【００５０】
ＳＩＰサーバ４００は、呼制御端末３００から、ユーザ端末１００を宛先としたＩＮＶＩＴＥ信号（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，第三者呼制御の情報（第三者呼制御ヘッダ）」）を受信すると、ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）を参照し、呼制御端末３００を起点とした第三者呼制御によりユーザ端末１００およびユーザ端末２００を接続する発呼であることを確認し、対応する発呼の待機状態をとる。次に、ＳＩＰサーバ４００は、信号の送信元（Ｆｒｏｍ行）の電話番号とＩＰアドレスとの対応関係が正しいか否かを検証する。検証の結果、電話番号とＩＰアドレスとの対応関係が正しい場合には、呼制御端末３００の電話番号を発信者番号とする。
【００５１】
そして、ＳＩＰサーバ４００は、ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）を保証するための保証情報と、発信者番号とを呼制御端末３００からのＩＮＶＩＴＥ信号に挿入して（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，第三者呼制御の情報（第三者呼制御ヘッダ），発信者番号，保証情報」）をユーザ端末１００に中継する。
【００５２】
ＩＮＶＩＴＥ信号に対する応答として、「２００  ＯＫ  ＳＤＰ  ｏｆｆｅｒ（ＩＰアドレス）」信号をユーザ端末１００から受信すると、ＳＩＰサーバ４００は、この信号を呼制御端末３００に中継する。
【００５３】
「２００  ＯＫ  ＳＤＰ  ｏｆｆｅｒ（ＩＰアドレス）」信号に対する応答として、「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ２，第三者呼制御の情報（第三者呼制御ヘッダ），ＳＤＰ  ｏｆｆｅｒ（ＩＰアドレス）」）を呼制御端末３００から受信すると、ＳＩＰサーバ４００の信号検証部４２１は、対応する発呼の待機状態を解除して、上記で説明したように、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）と、呼制御端末３００から先に受信したＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）との間の整合性が検証する。
【００５４】
信号検証部４２１による検証の結果、第三者呼制御の情報（第三者呼制御ヘッダ）間の整合性が正しい場合には、ＳＩＰサーバ４００の信号中継部４２２は、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ｏｆｆｅｒ」内のＩＰアドレスとの対応関係が正しいか否かを検証する。
【００５５】
この場合、「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ＳＤＰ  ｏｆｆｅｒ」内のＩＰアドレスは、ユーザ端末１００のＩＰアドレスであるので、対応関係は正しいものではなく、上述した従来技術の仕組みであれば、信号を中継することなく、セッションを切断して以後の通信を許可しない。
【００５６】
しかし、信号中継部４２２は、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、呼制御端末３００を起点としてユーザ端末１００およびユーザ端末２００を第三者呼制御によりこれから接続するものであることを確認できるので、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ｏｆｆｅｒ」内のＩＰアドレスとの対応関係が正しくなくとも、信号を中継することを決定し、呼制御端末３００からの信号をユーザ端末２００に中継する。
【００５７】
「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に対する応答として、「２００  ＯＫ  ＳＤＰ  ａｎｓｗｅｒ（ＩＰアドレス）」信号をユーザ端末２００から受信すると、この信号を呼制御端末３００に中継する。
【００５８】
「２００  ＯＫ  ＳＤＰ  ａｎｓｗｅｒ」に対する応答として、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ（ＩＰアドレス）」信号を呼制御端末３００から受信すると、信号中継部４２２は、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ａｎｓｗｅｒ」内のＩＰアドレスとの対応関係が正しいか否かを検証する。この場合も、上記と同様に、信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ＳＤＰ  ａｎｓｗｅｒ」内のＩＰアドレスは、ユーザ端末２００のＩＰアドレスであるので、対応関係は正しいものではない。
【００５９】
しかし、信号中継部４２２は、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号が、呼制御端末３００を起点とした第三者呼制御に基づく上記の「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に関連した信号であるので、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に含まれていた第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ａｎｓｗｅｒ」内のＩＰアドレスとの対応関係が正しくなくとも、ユーザ端末１００とユーザ端末２００との間の通信を許可することを決定し、信号をユーザ端末１００に中継する。
【００６０】
この「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号が、ユーザ端末１００に受信されることにより、ユーザ端末１００とユーザ端末２００との間のＩＰアドレス交換が完了し、以後、通信が可能となる。
【００６１】
［フロー２］
続いて、フロー２における通信許可決定までの流れを説明する。ＳＩＰサーバ４００は、呼制御端末３００から、ユーザ端末１００およびユーザ端末２００を宛先としたＩＮＶＩＴＥ信号（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，第三者呼制御の情報（第三者呼制御ヘッダ），ｏｆｆｅｒ１」、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ２，第三者呼制御の情報（第三者呼制御ヘッダ）」）をそれぞれ受信すると、信号の送信元（Ｆｒｏｍ行）の電話番号とＩＰアドレスとの対応関係が正しいか否かを検証する。検証の結果、電話番号とＩＰアドレスとの対応関係が正しい場合には、呼制御端末３００の電話番号を発信者番号とする。
【００６２】
さらに、ＳＩＰサーバ４００の信号検証部４２１は、上記で説明したように、各ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）間の整合性を検証し、検証の結果、第三者呼制御の情報（第三者呼制御ヘッダ）間の整合性が正しい場合には、呼制御端末３００からの各ＩＮＶＩＴＥ信号に発信者番号および保証情報をそれぞれ挿入して（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，第三者呼制御の情報（第三者呼制御ヘッダ），発信者番号，保証情報」、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ２，第三者呼制御の情報（第三者呼制御ヘッダ），発信者番号，保証情報」）をユーザ端末１００およびユーザ端末２００にそれぞれ中継する。
【００６３】
ＩＮＶＩＴＥ信号に対する応答として、「２００  ＯＫ  ａｎｓｗｅｒ１（ＩＰアドレス）」信号をユーザ端末１００から受信すると、ＳＩＰサーバ４００は、この信号を呼制御端末３００に中継する。また、ＩＮＶＩＴＥ信号に対する応答として、ＳＩＰサーバ４００は、「２００  ＯＫ  ｏｆｆｅｒ２（ＩＰアドレス）」信号をユーザ端末１００から受信すると、この信号を呼制御端末３００に中継する。
【００６４】
そして、ＳＩＰサーバ４００の信号中継部４２２は、呼制御端末３００からの「ｒｅ‐ＩＮＶＩＴＥ  Ｔｏ：ＵＡ１，ｏｆｆｅｒ２（ＩＰアドレス）」信号を受信すると、上述したフロー１と同様に、この信号の送信元（Ｆｒｏｍ行）の電話番号と、「ｏｆｆｅｒ２」内のＩＰアドレスとの対応関係が正しいか否かを検証する。
【００６５】
この場合、信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ｏｆｆｅｒ２」内のＩＰアドレスは、ユーザ端末２００のＩＰアドレスであるので、対応関係は正しいものではなく、上述した従来技術の仕組みであれば、信号を中継することなく、セッションを切断して以後の通信を許可しない。
【００６６】
しかし、信号中継部４２２は、「ｒｅ‐ＩＮＶＩＴＥ  ｏｆｆｅｒ２」信号が、呼制御端末３００を起点とした第三者呼制御に基づく上記のＩＮＶＩＴＥ信号に関連した信号であるので、呼制御端末３００からのＩＮＶＩＴＥ信号に含まれていた第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ｏｆｆｅｒ２」内のＩＰアドレスとの対応関係が正しくなくとも、この信号を中継することを決定し、「ｒｅ‐ＩＮＶＩＴＥ  ｏｆｆｅｒ２」信号をユーザ端末１００に中継する。
【００６７】
信号中継部４２２は、「ｒｅ‐ＩＮＶＩＴＥ  ｏｆｆｅｒ２」信号に対する応答として、「２００  ＯＫ  ａｎｓｗｅｒ２（ＩＰアドレス）」信号をユーザ端末１００から受信すると、この信号を呼制御端末３００に中継する。
【００６８】
そして、信号中継部４２２は、「２００  ＯＫ  ａｎｓｗｅｒ２」信号に対する応答として、「ＡＣＫ  ａｎｓｗｅｒ２」信号を呼制御端末３００から受信すると、この信号の送信元（Ｆｒｏｍ行）の電話番号と、「ａｎｓｗｅｒ２」内のＩＰアドレスとの対応関係が正しいか否かを検証する。この場合も、上記と同様に、信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ａｎｓｗｅｒ２」内のＩＰアドレスは、ユーザ端末１００のＩＰアドレスであるので、対応関係は正しいものではない。
【００６９】
しかし、信号中継部４２２は、「ＡＣＫ  ａｎｓｗｅｒ２」信号が、呼制御端末３００を起点とした第三者呼制御に基づく上記のＩＮＶＩＴＥ信号に関連した信号であるので、呼制御端末３００からのＩＮＶＩＴＥ信号に含まれていた第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ａｎｓｗｅｒ２」内のＩＰアドレスとの対応関係が正しくなくとも、ユーザ端末１００とユーザ端末２００との間の通信を許可することを決定し、「ＡＣＫ  ａｎｓｗｅｒ２」信号をユーザ端末２００に中継する。
【００７０】
この「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号が、ユーザ端末１００に受信されることにより、ユーザ端末１００とユーザ端末２００との間のＩＰアドレス交換が完了し、以後、通信が可能となる。
【００７１】
［ＳＩＰサーバの動作（実施例１）］
次に、図５および図６を用いて、実施例１に係るＳＩＰサーバの動作を説明する。なお、図５および図６は、実施例１に係るＳＩＰサーバの動作を説明するための図である。また、図５および図６において記載されている（１）〜（３）は、上述した図３に記載の（１）〜（３）の各情報に対応する。
【００７２】
［フロー１に対応する動作］
まず、図５を用いて、上述したフロー１に対応するＳＩＰサーバ４００の動作を説明する。同図に示すように、ＳＩＰサーバ４００は、呼制御端末３００から、ユーザ端末１００を宛先としたＩＮＶＩＴＥ信号（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，（２）第三者呼制御の情報（第三者呼制御ヘッダ）」）を受信すると（ステップＳ１）、信号の送信元（Ｆｒｏｍ行）の電話番号とＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ２）。検証の結果、電話番号とＩＰアドレスとの対応関係が正しい場合には、呼制御端末３００の電話番号を発信者番号とする。
【００７３】
さらに、ＳＩＰサーバ４００は、ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）を参照し、呼制御端末３００を起点とした第三者呼制御によりユーザ端末１００およびユーザ端末２００を接続する発呼であることを確認し、対応する発呼の待機状態をとる（同ステップＳ２）。そして、ＳＩＰサーバ４００の信号中継部４２２は、ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）を保証するための保証情報と、発信者番号とを呼制御端末３００からのＩＮＶＩＴＥ信号に挿入して（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，（２）第三者呼制御の情報（第三者呼制御ヘッダ），（１）発信者番号，（３）保証情報」）をユーザ端末１００に中継する（ステップＳ３）。
【００７４】
ＩＮＶＩＴＥ信号に対する応答として、「２００  ＯＫ  ＳＤＰ  ｏｆｆｅｒ（ＩＰアドレス）」信号をユーザ端末１００から受信すると、ＳＩＰサーバ４００は、この信号を呼制御端末３００に中継する（ステップＳ４）。
【００７５】
「２００  ＯＫ  ＳＤＰ  ｏｆｆｅｒ（ＩＰアドレス）」信号に対する応答として、「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ２，（２）第三者呼制御の情報（第三者呼制御ヘッダ），ＳＤＰ  ｏｆｆｅｒ（ＩＰアドレス）」）を呼制御端末３００から受信すると（ステップＳ５）、ＳＩＰサーバ４００の信号検証部４２１は、対応する発呼の待機状態を解除して、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）と、呼制御端末３００から先に受信したＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）との間の整合性（第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼か否か）を検証する（ステップＳ６）。
【００７６】
検証の結果、第三者呼制御の情報（第三者呼制御ヘッダ）間の整合性が正しかった場合（第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼が行われた場合）には、ＳＩＰサーバ４００の信号中継部４２２は、呼制御端末３００から受信した「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ｏｆｆｅｒ」内のＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ６）。
【００７７】
この場合、「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ＳＤＰ  ｏｆｆｅｒ」内のＩＰアドレスは、ユーザ端末１００のＩＰアドレスであるので、対応関係は正しいものではなく、上述した従来技術の仕組みであれば、信号を中継することなく、セッションを切断して以後の通信を許可しない。
【００７８】
しかし、ＳＩＰサーバ４００の信号中継部４２２は、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、呼制御端末３００を起点としてユーザ端末１００およびユーザ端末２００を第三者呼制御によりこれから接続するものであることを確認できるので、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ｏｆｆｅｒ」内のＩＰアドレスとの対応関係が正しくなくとも、信号を中継することを決定し、呼制御端末３００からの信号をユーザ端末２００に中継する（ステップＳ７）。
【００７９】
「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に対する応答として、「２００  ＯＫ  ＳＤＰ  ａｎｓｗｅｒ（ＩＰアドレス）」をユーザ端末２００から受信すると、ＳＩＰサーバ４００の信号中継部４２２は、この信号を呼制御端末３００に中継する（ステップＳ８）。
【００８０】
「２００  ＯＫ  ＳＤＰ  ａｎｓｗｅｒ」に対する応答として、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ（ＩＰアドレス）」信号を呼制御端末３００から受信すると、ＳＩＰサーバ４００の信号中継部４２２は、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ａｎｓｗｅｒ」内のＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ９）。この場合も、上記と同様に、信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ＳＤＰ  ａｎｓｗｅｒ」内のＩＰアドレスは、ユーザ端末２００のＩＰアドレスであるので、対応関係は正しいものではない。
【００８１】
しかし、ＳＩＰサーバ４００の信号中継部４２２は、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号が、呼制御端末３００を起点とした第三者呼制御に基づく上記の「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に関連した信号であるので、呼制御端末３００からの「ＩＮＶＩＴＥ  ＳＤＰ  ｏｆｆｅｒ」信号に含まれていた第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ＳＤＰ  ａｎｓｗｅｒ」内のＩＰアドレスとの対応関係が正しくなくとも、ユーザ端末１００とユーザ端末２００との間の通信を許可することを決定し、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号をユーザ端末１００に中継する（ステップＳ１０）。
【００８２】
ＳＩＰサーバ４００の信号中継部４２２は、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号を受信した後、呼制御端末３００から「ＡＣＫ」信号を受信すると、ユーザ端末２００に転送する（ステップＳ１１）。
【００８３】
そして、「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号が、ユーザ端末１００に受信されることにより、ユーザ端末１００とユーザ端末２００との間のＩＰアドレス交換が完了し、以後、通信が可能となる（ステップＳ１２）。
【００８４】
［フロー２に対応する動作（実施例１）］
続いて、図６を用いて、上述したフロー２に対応するＳＩＰサーバ４００の動作を説明する。なお、フロー２に対応するＳＩＰサーバの動作は、ユーザ端末１００と呼制御端末３００との間にメディア通信なし（ｎｏ  ｍｅｄｉａ）の一時的なセッションを張るための手順１と、手順１でユーザ端末１００と呼制御端末３００との間の一時的なセッションをユーザ端末１００とユーザ端末２００との間のセッションへと更新する手順２とで構成される。
【００８５】
図６に示すように、呼制御端末３００から、ユーザ端末１００およびユーザ端末２００を宛先としたＩＮＶＩＴＥ信号（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，第三者呼制御の情報（第三者呼制御ヘッダ），ｏｆｆｅｒ１」、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ２，第三者呼制御の情報（第三者呼制御ヘッダ）」）をそれぞれ受信すると（ステップＳ１およびステップＳ２）、ＳＩＰサーバ４００は、信号の送信元（Ｆｒｏｍ行）の電話番号とＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ３）。検証の結果、電話番号とＩＰアドレスとの対応関係が正しい場合には、呼制御端末３００の電話番号を発信者番号とする。
【００８６】
さらに、ＳＩＰサーバ４００の信号検証部４２１は、各ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）間の整合性（第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼か否か）を検証し（同ステップＳ３）、検証の結果、第三者呼制御の情報（第三者呼制御ヘッダ）間の整合性が正しい場合（第三者呼制御の情報（第三者呼制御ヘッダ）に記述の通りの発呼が行われた場合）には、ＩＮＶＩＴＥ信号に含まれる第三者呼制御の情報（第三者呼制御ヘッダ）を保証するための保証情報と、発信者番号とを呼制御端末３００から受信した各ＩＮＶＩＴＥ信号にそれぞれ挿入して（例えば、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ１，（２）第三者呼制御の情報（第三者呼制御ヘッダ），（１）発信者番号，（３）保証情報」、「ＩＮＶＩＴＥ  Ｔｏ  ＵＡ２，（２）第三者呼制御の情報（第三者呼制御ヘッダ），（１）発信者番号，（３）保証情報」）をユーザ端末１００およびユーザ端末２００にそれぞれ中継する（ステップＳ４およびステップＳ５）。
【００８７】
ＩＮＶＩＴＥ信号に対する応答として、「２００  ＯＫ  ａｎｓｗｅｒ１（ＩＰアドレス）」信号をユーザ端末１００から受信すると、ＳＩＰサーバ４００は、この信号を呼制御端末３００に中継する（ステップＳ６）。また、ＩＮＶＩＴＥ信号に対する応答として、ＳＩＰサーバ４００は、「２００  ＯＫ  ｏｆｆｅｒ２（ＩＰアドレス）」信号をユーザ端末１００から受信すると、この信号を呼制御端末３００に中継する（ステップＳ７）。
【００８８】
そして、ＳＩＰサーバ４００の信号中継部４２２は、「ｒｅ‐ＩＮＶＩＴＥ  Ｔｏ：ＵＡ１，ｏｆｆｅｒ２（ＩＰアドレス）」信号を呼制御端末３００から受信すると、上述したフロー１と同様に、この信号の送信元（Ｆｒｏｍ行）の電話番号と、「ｏｆｆｅｒ２」内のＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ８）。
【００８９】
この場合、信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ｏｆｆｅｒ２」内のＩＰアドレスは、ユーザ端末２００のＩＰアドレスであるので、対応関係は正しいものではなく、上述した従来技術の仕組みであれば、信号を中継することなく、セッションを切断して以後の通信を許可しない。
【００９０】
しかし、ＳＩＰサーバ４００の信号中継部４２２は、「ｒｅ‐ＩＮＶＩＴＥ  ｏｆｆｅｒ２」信号が、呼制御端末３００を起点とした第三者呼制御に基づく上記のＩＮＶＩＴＥ信号に関連した信号であるので、呼制御端末３００からのＩＮＶＩＴＥ信号に含まれていた第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ｏｆｆｅｒ２」内のＩＰアドレスとの対応関係が正しくなくとも、この信号を中継することを決定し、「ｒｅ‐ＩＮＶＩＴＥ  ｏｆｆｅｒ２」信号をユーザ端末１００に中継する（ステップＳ９）。
【００９１】
ＳＩＰサーバ４００の信号中継部４２２は、「ｒｅ‐ＩＮＶＩＴＥ  ｏｆｆｅｒ２」信号に対する応答として、「２００  ＯＫ  ａｎｓｗｅｒ２（ＩＰアドレス）」信号をユーザ端末１００から受信すると、この信号を呼制御端末３００に中継する（ステップＳ１０）。
【００９２】
そして、ＳＩＰサーバ４００の信号中継部４２２は、「２００  ＯＫ  ａｎｓｗｅｒ２」信号に対する応答として、「ＡＣＫ  ａｎｓｗｅｒ２」信号を呼制御端末３００から受信すると、この信号の送信元（Ｆｒｏｍ行）の電話番号と、「ａｎｓｗｅｒ２」内のＩＰアドレスとの対応関係が正しいか否かを検証する（ステップＳ１１）。この場合も、上記と同様に、信号の送信元の電話番号は、呼制御端末３００の電話番号であり、「ａｎｓｗｅｒ２」内のＩＰアドレスは、ユーザ端末１００のＩＰアドレスであるので、対応関係は正しいものではない。
【００９３】
しかし、ＳＩＰサーバ４００の信号中継部４２２は、「ＡＣＫ  ａｎｓｗｅｒ２」信号が、呼制御端末３００を起点とした第三者呼制御に基づく上記のＩＮＶＩＴＥ信号に関連した信号であるので、呼制御端末３００からのＩＮＶＩＴＥ信号に含まれていた第三者呼制御の情報（第三者呼制御ヘッダ）に基づいて、信号の送信元（Ｆｒｏｍ行）の電話番号と、「ａｎｓｗｅｒ２」内のＩＰアドレスとの対応関係が正しくなくとも、ユーザ端末１００とユーザ端末２００との間の通信を許可することを決定し、「ＡＣＫ  ａｎｓｗｅｒ２」信号をユーザ端末２００に中継する（ステップＳ１２）。
【００９４】
この「ＡＣＫ  ＳＤＰ  ａｎｓｗｅｒ」信号が、ユーザ端末１００に受信されることにより、ユーザ端末１００とユーザ端末２００との間のＩＰアドレス交換が完了し、ユーザ端末１００と呼制御端末３００との間の一時的なセッションがユーザ端末１００とユーザ端末２００との間のセッションへ更新され、以後、通信が可能となる（ステップＳ１３）。
【００９５】
［実施例１による効果］
上述してきたように、実施例１によれば、呼制御端末３００が信号に挿入する第三者呼制御の情報（第三者呼制御ヘッダに記述される情報）ではなく、ＳＩＰサーバ４００が挿入する信頼性のある保証情報に基づいて、通信を行う各ユーザ端末に通信相手を確認させることができる。また、従来からの発信者番号通知の技術を利用して、ＳＩＰサーバがＩＰアドレスの検証を行うので、ＳＩＰサーバにより検証された信頼性のあるＩＰアドレスによりユーザ端末間の通信を実現する。
【００９６】
また、上記の実施例１では、ＳＩＰサーバ４００が、第三者呼制御の情報（第三者呼制御ヘッダに記述された情報）を保証するための保証情報（ＳＩＰサーバ４００が信号に挿入する第三者呼制御のヘッダ）をユーザ端末宛の信号に挿入する場合を説明したが、これに限定されるものではない。例えば、呼制御端末３００から発信される信号に整合性がある場合には、ＳＩＰサーバからユーザ端末へ中継する仕様とすることができる。この場合、ユーザ端末側では、呼制御端末３００からの信号がＳＩＰサーバ４００から中継された場合には、ＳＩＰサーバ４００において保証された信号であるものとして取り扱う。
【実施例２】
【００９７】
さて、これまでＳＩＰサーバ４００の一実施形態について説明してきたが、上述した実施例１以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、他の実施形態について説明する。
【００９８】
（１）信号を複数台のサーバで中継
上記の実施例では、一台のＳＩＰサーバ４００で信号の中継を行う場合を説明したが、これに限定されるものではなく、通信可能に接続された信頼関係のある複数台のサーバで信号を中継するようにしてもよい。
【００９９】
例えば、図７に示すように、ＳＩＰサーバ４００とＳＩＰサーバ５００とが相互に通信可能な状態で接続され、ＳＩＰサーバ５００と、ＳＩＰサーバ６００およびＳＩＰサーバ７００とが相互に通信可能な状態で接続されているものとする。また、ＳＩＰサーバ４００には、呼制御端末３００が所属し、ＳＩＰサーバ６００にユーザ端末１００が所属し、ＳＩＰサーバ７００にユーザ端末２００が所属するものとする。なお、図７は、実施例２に係るシステムの構成例を示す図である。
【０１００】
上述したようにシステムが構成される場合に、呼制御端末３００が所属するＳＩＰサーバ４００は、上述した実施例１と同様に、ＩＮＶＩＴＥ信号の結びつけ（検証）を行った後、ＩＮＶＩＴＥ信号へ保証情報を挿入して（あるいは、第三者呼制御の情報（第三者呼制御ヘッダ）を保証して）、ＩＮＶＩＴＥ信号をＳＩＰサーバ５００に中継する。ＳＩＰサーバ５００は、ＳＩＰサーバ４００から受信したＩＮＶＩＴＥ信号をＳＩＰサーバ６００およびＳＩＰサーバ７００にそれぞれ中継する。なお、ＳＩＰサーバ４００と、ＳＩＰサーバ６００およびＳＩＰサーバ７００との間には、ＳＩＰサーバ５００以外の複数のＳＩＰサーバをさらに配置して、信号を中継させるようにしてもよい。
【０１０１】
ＳＩＰサーバ６００は、ＳＩＰサーバ５００からＩＮＶＩＴＥ信号を受信すると、ＳＩＰサーバ４００が挿入した保証情報を信用して、自らに所属するユーザ端末１００に中継する。同様に、ＳＩＰサーバ７００は、ＳＩＰサーバ５００からＩＮＶＩＴＥ信号を受信すると、ＳＩＰサーバ４００が挿入した保証情報を信用して、自らに所属するユーザ端末２００に中継する。なお、ＳＩＰサーバ４００は、ＳＩＰサーバ６００およびＳＩＰサーバ７００が、正しい宛先へ信号を中継することを信用するものとする。
【０１０２】
上述してきたようなシステム構成をとることで、上記の実施例１で説明したＳＩＰサーバ４００の機能を、大規模なコンピュータシステムにも適用できる。
【０１０３】
（２）装置構成等
また、図２に示したＳＩＰサーバ４００の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、ＳＩＰサーバ４００の分散・統合の具体的形態は図示のものに限られず、例えば、信号検証部４２１と信号中継部４２２とを統合するなど、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、ＳＩＰサーバ４００にて行なわれる各処理機能（図５および図６等参照）は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１０４】
（３）通信処理プログラム
また、上記の実施例１で説明したＳＩＰサーバ４００の各種の処理（例えば、図５、図６等参照）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、図８を用いて、上記の実施例１と同様の機能を有する通信処理プログラムを実行するコンピュータの一例を説明する。図８は、通信処理プログラムを実行するコンピュータを示す図である。
【０１０５】
同図に示すように、ＳＩＰサーバとしてコンピュータ８００は、通信制御部８１０、ＨＤＤ８２０、ＲＡＭ８３０およびＣＰＵ８４０をバス９００で接続して構成される。
【０１０６】
ここで、通信制御部８１０は、各種情報のやり取りに関する通信を制御する。ＨＤＤ８２０は、ＣＰＵ８４０による各種処理の実行に必要な情報を記憶する。ＲＡＭ８３０は、各種情報を一時的に記憶する。ＣＰＵ８４０は、各種演算処理を実行する。
【０１０７】
そして、ＨＤＤ８２０には、図８に示すように、上記の実施例１に示したＳＩＰサーバ４００の各処理部と同様の機能を発揮する通信処理プログラム８２１と、通信処理用データ８２２とがあらかじめ記憶されている。なお、この通信処理プログラム８２１を適宜分散させて、ネットワークを介して通信可能に接続された他のコンピュータの記憶部に記憶させておくこともできる。
【０１０８】
そして、ＣＰＵ８４０が、この通信処理プログラム８２１をＨＤＤ８２０から読み出してＲＡＭ８３０に展開することにより、図８に示すように、通信処理プログラム８２１は通信処理プロセス８３１として機能するようになる。そして、通信処理プロセス８３１は、通信処理用データ８２２等をＨＤＤ８２０から読み出して、ＲＡＭ８３０において自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種処理を実行する。なお、通信処理プロセス８３１は、図２に示したＳＩＰサーバ４００の制御部（信号検証部４２１および信号中継部４２２等）において実行される処理にそれぞれ対応する。
【０１０９】
なお、上記した通信処理プログラム８２１については、必ずしも最初からＨＤＤ８２０に記憶させておく必要はなく、例えば、コンピュータ８００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ８００に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ８００がこれらから各プログラムを読み出して実行するようにしてもよい。
【０１１０】
（４）通信処理方法
上記の実施例１で説明したＳＩＰサーバにより、以下のような通信処理方法が実現される。
【０１１１】
すなわち、端末間の呼接続を指示する呼制御端末から発信された第三者呼制御の接続対象である各端末へのリクエスト信号をそれぞれ中継するとともに、当該各端末から発信されたレスポンス信号をそれぞれ中継することにより、前記呼制御端末を起点とした第三者呼制御による前記端末間の通信を確立する通信処理方法であって、端末間の接続を指示するためのリクエスト信号を呼制御端末からそれぞれ受信した場合に、当該リクエスト信号の各々が有するヘッダ内に呼制御端末により挿入された第三者呼制御の情報をそれぞれ参照して、当該第三者呼制御の情報が示すとおりに、第三者呼制御により端末間を接続するための発呼が行われたか否かを検証する発呼検証ステップと（例えば、図６のステップＳ３参照）、発呼検証ステップによる検証の結果、第三者呼制御の情報が示すとおりに、第三者呼制御により端末間を接続するための発呼が行われている場合には、リクエスト信号を接続対象の各端末へそれぞれ中継する中継ステップと（図６のステップＳ４、Ｓ５参照）、端末間でセッション情報をやり取りするためのリクエスト信号を呼制御端末から受信した場合に、当該リクエスト信号の発信元と当該セッション情報に含まれるＩＰアドレスとの対応関係を第三者呼制御の情報に基づいて検証するアドレス検証ステップと（図６のステップＳ８、Ｓ１１参照）を含んだ通信処理方法が実現される。
【産業上の利用可能性】
【０１１２】
以上のように、本発明に係るサーバ装置、通信処理システム、通信処理方法および通信処理プログラムは、呼制御端末を起点とした３ＰＣＣ方式による端末間の通信を確立することに有用であり、特に、３ＰＣＣ方式を用いて第三者呼制御を実行する場合に、呼制御端末の動作に依存されない信頼性のある情報に基づいて、通信を行う各ユーザに通信相手を確認させることに適する。
【図面の簡単な説明】
【０１１３】
【図１】実施例１に係るＳＩＰサーバの特徴を説明するための図である。
【図２】実施例１に係るＳＩＰサーバの構成を示す図である。
【図３】実施例１に係るヘッダの記述例を示す図である。
【図４】従来技術（発信者番号通知）を説明するための図である。
【図５】実施例１に係るＳＩＰサーバの動作を説明するための図である。
【図６】実施例１に係るＳＩＰサーバの動作を説明するための図である。
【図７】実施例２に係るシステムの構成例を示す図である。
【図８】通信処理プログラムを実行するコンピュータを示す図である。
【図９】３ＰＣＣ方式が利用されるサービス例を示す図である。
【図１０】３ＰＣＣ方式における従来の仕組みを説明するための図である。
【符号の説明】
【０１１４】
１  ＳＩＰ網
１００  ユーザ端末
２００  ユーザ端末
３００  呼制御端末
４００  ＳＩＰサーバ
４１０  通信制御部
４２０  制御部
４２１  信号検証部
４２２  信号中継部
５００〜７００  ＳＩＰサーバ
８００  コンピュータ（ＳＩＰサーバ）
８１０  通信制御部 
８２０  ＨＤＤ（Hard Disk Drive）
８２１  通信処理プログラム
８２２  通信処理用データ
８３０  ＲＡＭ（Random Access Memory）
８３１  通信処理プロセス
８４０  ＣＰＵ（Central Processing Unit）
９００  バス
【図１】
2010178290.tif 000003
【図２】
2010178290.tif 000004
【図３】
2010178290.tif 000005
【図４】
2010178290.tif 000006
【図５】
2010178290.tif 000007
【図６】
2010178290.tif 000008
【図７】
2010178290.tif 000009
【図８】
2010178290.tif 000010
【図９】
2010178290.tif 000011
【図１０】
2010178290.tif 000012