JP6357634B1 - 電話番号調査装置、同方法、同プログラム、同情報提供システム - Google Patents

Abstract

【課題】事業者間相互接続にＩＭＳ相互接続インタフェース等を利用し、ＩＭＳ網、ＮＧＮ網とＩＰ電話網における電話番号の使用状況のリサーチを着信ベル無鳴動で実現する。
【解決手段】着信網であるＩＭＳ網３０又はＩＰ電話網４０に接続された０ＡＢ−Ｊ型番号の複数のＩＰ電話にＮＧＮ網２０を介して接続される電話番号調査装置１０であって、ＩＰｖ６としたネットワークプロトコルを含む第１のＳＤＰパラメータを付与したＩＮＶＩＴＥ要求をＮＧＮ網の選択する着信網に送信し、着信網自身が拒否する第１の応答メッセージの場合、再度、ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与したＩＮＶＩＴＥ要求を送信して第２の応答メッセージを受信するメッセージ交換制御部と、第１の応答メッセージ又は第２の応答メッセージに応じて、ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、を備える。
【選択図】図１２

Description

本発明は、電話番号調査装置、同方法、同プログラム、同情報提供システム、及び記録媒体に関する。

出願人が過去に出願し、公開された、例えば、特許文献１，２，３に記載された電話番号調査装置が知られている。この電話番号調査装置によれば、全国の電話番号の使用状況のリサーチを行うことができる。

これらの特許文献に記載された技術によれば、発信側である電話番号調査装置は、ＰＳＴＮ（Public Switched Telephone Networks：公衆交換電話網）、移動体通信網、あるいはＩＰ（Internet Protocol）電話網に接続される。そして、電話番号調査装置は、ＩＳＤＮ（Integrated Service Digital Network：サービス統合デジタル網）のＵＮＩ（User Network Interface:ユーザ網インタフェース）プロトコル等を利用して加入者データの問い合わせを行い、「電話番号有効」、「無効」、「移転」等、電話番号の使用状況のリサーチを行うことができる。

しかしながら、ＮＴＴ東西では、「ＰＳＴＮからＮＧＮ（Next Generation Network）へのマイグレーション」を計画しており、２０２０年後半にはＩＳＤＮサービスの「デジタル通信モード」を廃止することを予定している。このため、ＩＳＤＮのＵＮＩ接続方式に代わって、ＮＧＮ網と接続可能なＳＩＰ（Session Initiation Protocol）ベースの電話番号調査ツールを導入し、新システム基盤への円滑な移行を図る必要がある。

近年、固定電話は順次ＩＰ電話に移行しており、２０１６年の情報通信白書によれば、２０１５年度末で３８４５万台がＩＰ電話であると報告されている。したがって、電話番号の使用状況を正しく判定できるＩＰ電話番号調査装置の実現が待たれている。ＩＰ電話の基本的な仕組みは伝統的な固定電話の技術とは大きく異なり、このため、例えば、特許文献４に記載されているように、敢えて正しくない記述のＩＮＶＩＴＥ要求をＩＰ電話網（ＳＩＰサーバ）に送信することで、ＩＰ電話番号の有効性を調査する電話番号調査装置が知られている。

しかしながら、出願人が特許文献４に記載された技術を用いて評価試験を試みたところ、依然として正しく判定できるＩＰ電話番号の使用状況の調査を確立できていない。すなわち、特許文献４で調査対象とするＩＰ電話は、０５０で始まる１１桁の電話番号が割り当てられた０５０型ＩＰ電話であり、光電話等、これまでの加入者電話と同じ形式を持つ０で始まる電話番号が割り当てられた０ＡＢ−Ｊ型ＩＰ電話を対象としていない。したがって、０ＡＢ−Ｊ型ＩＰ電話の電話番号使用状況をリサーチする際に網側拒否等により有効性の調査はできない。

これに対し、出願人は、ＩＰ電話網のＵＮＩ接続の発信端末（電話番号調査装置）からＩＰ電話が着信を拒否するＳＩＰの特定メッセージを送信することにより、ＩＰ電話網における電話番号使用状況を、着信ベルを鳴動させる信号を用いないで判定する技術を確立し、平成２８年５月２４日に、「電話番号調査装置、同方法、同プログラム、及び記録媒体」（特願２０１６−１０３３５６号）として出願した。この出願に記載された技術によれば、ＮＧＮ網と接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することで、新システム基盤への円滑な移行を図ることができる。ここで、電話番号調査の対象となるＩＰ電話には、０５０で始まる１１桁の電話番号が割り当てられた０５０型の他に、光電話等、これまでの加入者電話と同じ形式を持つ０で始まる電話番号が割り当てられた０ＡＢ−Ｊ型も含まれ、したがって、ＩＰ電話の種類に依存することなく、電話番号の有効／無効調査を行う際に正確に判定することができる。

特開２００９−０５５５１２号公報 特開２０１１−１３５１２１号公報 特開２０１４−０３３４７４号公報 特開２０１２−０１５６０５号公報

ところで、２０２０年以降に予定されているＰＳＴＮからＮＧＮへの移行に伴い、事業者間相互接続インタフェースも共通線信号方式のＳＳ７（Signaling System No.7）からＩＰ方式のＳＩＰ（Session Initiation Protocol）に変更される。このため、発信端末（電話番号調査装置）からＳＩＰの特定メッセージがＩＭＳ（IP Multimedia Subsystem）網、ＮＧＮ（Next Generation Network）網、及びＩＰ電話網（ＶｏＩＰ：Voice over Internet Protocol）に対しトランスペアレントに到達することになる。

なお、ＩＭＳとは、これまで固定網や移動体通信などで行われていたサービスをＩＰ化し、融合したマルチメディアサービスなどを実現するための規格であり、その規格に沿って作られたシステムとして移動体通信システムやＮＧＮがある。

このため、事業者間相互接続にＩＭＳ相互接続インタフェース等を利用し、ＩＭＳ網やＩＰ電話網における電話番号使用状況を、着信ベルを鳴動させる信号を用いないで判定する、ＮＧＮ網とＵＮＩ接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入して新システム基盤への円滑な移行を図る必要がある。

本発明は上記した課題を解決するためになされたものであり、事業者間相互接続にＩＭＳ相互接続インタフェース等を利用し、ＩＭＳ網やＩＰ電話網における電話番号使用状況を、着信ベルを鳴動させる信号を用いないで判定して新システム基盤への円滑な移行を可能にする、電話番号調査装置、同方法、同プログラム、同情報提供システムを提供することを目的とする。特に、０ＡＢ−Ｊ型番号が割り当てられたＩＰ電話の電話番号使用状況について、着信網の種類に依存することなく、着信ベルを鳴動させる信号を用いないで判定することができる、電話番号調査装置、同方法、同プログラム、同情報提供システムを提供することを目的とする。

本発明は、上記目的を達成するために、以下の構成によって把握される。
（１）本発明の電話番号調査装置は、少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置であって、前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信し、受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信して前記着信網から第２の応答メッセージを受信するメッセージ交換制御部と、前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、を備え、前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいる。

（２）上記（１）の構成において、前記第１のＳＤＰパラメータは、前記ＩＭＳ網に準拠したパラメータであり、前記第２のＳＤＰパラメータは、前記ＩＰ電話網に準拠したパラメータである。

（３）上記（１）又は（２）の構成において、前記第１のＳＤＰパラメータは、前記ＩＭＳ網に接続された前記ＩＰ電話が着信を拒否するパラメータでもあり、前記第１のＳＤＰパラメータは、前記ネットワークプロトコル、メディア種別、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなるパラメータの記述で前記ＩＰ電話が着信を拒否するパラメータとされている。

（４）上記（３）の構成において、前記第１のＳＤＰパラメータが、音声、映像、及び、アプリケーションを含む全メディアを含んだメディア種別を含んでいる。

（５）上記（１）から（４）のいずれか１つの構成において、前記第２のＳＤＰパラメータは、前記ＩＰ電話網に接続された前記ＩＰ電話が着信を拒否するパラメータであり、前記第２のＳＤＰパラメータは、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなるパラメータの記述で前記ＩＰ電話が着信を拒否するパラメータとされている。

（６）上記（５）の構成において、前記第２のＳＤＰパラメータは、トランスポートプロトコルとコーデックの２つのパラメータの記述で前記ＩＰ電話が着信を拒否するパラメータとされている。

（７）上記（１）から（６）のいずれか１つの構成において、前記電話番号調査判定部は、前記第１の応答メッセージが、前記着信網自身の拒否である場合には、前記着信網が前記ＩＰ電話網であると判定し、前記第１の応答メッセージが、前記着信網自身の拒否でない場合には、前記着信網が前記ＩＭＳ網であると判定する。

（８）上記（１）から（７）のいずれか１つの構成において、前記電話番号調査判定部は、前記第１の応答メッセージが前記着信網自身の拒否でない場合に、前記第１の応答メッセージに応じた前記ＩＰ電話の電話番号使用状況についての判定を行う。

（９）上記（１）から（８）のいずれか１つの構成において、前記電話番号調査判定部は、前記第１の応答メッセージに含まれる第１のエラーコードを受信した場合、前記ＩＰ電話の電話番号が実在すると判定し、前記電話番号調査判定部は、前記第１の応答メッセージに含まれる第２又は第３のエラーコードを受信した場合、前記ＩＰ電話の電話番号が欠番であると判定する。

（１０）上記（１）から（９）のいずれか１つの構成において、前記電話番号調査判定部は、前記第２の応答メッセージに含まれる第１のエラーコードを受信した場合、前記ＩＰ電話の電話番号が実在すると判定し、前記電話番号調査判定部は、前記第２の応答メッセージに含まれる第３のエラーコードを受信した場合、前記ＩＰ電話が欠番であると判定する。

（１１）本発明の電話番号調査方法は、少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置を用いて、調査対象となる前記ＩＰ電話の電話番号の使用状況を調査する電話番号調査方法であって、前記電話番号調査装置が、前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信するステップと、受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信して前記着信網から第２の応答メッセージを受信するステップと、前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定するステップと、を含み、前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいる。

（１２）本発明のプログラムは、少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置のプログラムであって、電話番号調査装置に、前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信させる処理と、受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信させて前記着信網から第２の応答メッセージを受信させる処理と、前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定させる処理と、を少なくとも実行させ、前記ＩＮＶＩＴＥ要求を送信させる処理を前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいるものとして実行させる。

（１３）本発明の電話番号調査情報提供システムは、ユーザ端末と、ＩＰ網経由で前記ユーザ端末に接続されるとともに、少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置と、を含み、前記電話番号調査装置は、前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信し、受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信して前記着信網から第２の応答メッセージを受信するメッセージ交換制御部と、前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、前記ユーザ端末から前記ＩＰ電話の電話番号調査情報提供要求を受信すると、前記電話番号調査情報提供要求があった前記ユーザ端末に前記電話番号調査判定部が判定した前記ＩＰ電話の電話番号使用状況を前記ＩＰ網経由で送信する網インタフェース部と、を備え、前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいる。

本発明によれば、事業者間相互接続にＩＭＳ相互接続インタフェース等を利用し、ＩＭＳ網やＩＰ電話網における電話番号使用状況を、着信ベルを鳴動させる信号を用いないで判定して新システム基盤への円滑な移行を可能にする、電話番号調査装置、同方法、同プログラム、同情報提供システムを提供することができる。また、０ＡＢ−Ｊ型番号が割り当てられたＩＰ電話の電話番号使用状況について、着信網の種類に依存することなく、着信ベルを鳴動させる信号を用いないで判定することができる、電話番号調査装置、同方法、同プログラム、同情報提供システムを提供することができる。

本発明の実施の形態に係る電話番号調査装置の網接続形態を示す図である。 本発明の実施の形態に係る電話番号調査装置の動作シーケンス図である。 本発明の実施の形態に係る電話番号調査装置の構成図である。 本発明の実施の形態に係る電話番号調査装置のＳＤＰ記述に基づく通信確立手順を示すフローチャートである。 本発明の実施の形態に係る電話番号調査装置の電話番号使用状況調査判定アルゴリズムを示すフローチャートである。 実施例１のＩＮＶＩＴＥ要求の一例とそのシーケンス図である。 実施例２のＩＮＶＩＴＥ要求の一例とそのシーケンス図である。 実施例３のＩＮＶＩＴＥ要求の一例とそのシーケンス図である。 実施例４のＩＮＶＩＴＥ要求の一例とそのシーケンス図である。 記録媒体のデータ構造の一例を示す図である。 本発明の実施の形態に係る電話番号調査装置の着信網の網判定手順を示すフローチャートである。 本発明の実施の形態に係る電話番号調査装置の着信網の網判定手順をネットワーク上に示した概念図である。 本発明の実施の形態に係る電話番号調査情報提供システムの構成図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、本実施形態と言う）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。

（実施形態の構成）
図１は、本実施形態に係る電話番号調査装置１０の網接続形態を示す図である。図１に示すように、本実施形態に係る電話番号調査装置１０は、ＩＭＳ網３０又はＩＰ電話網４０に接続された調査対象の複数の電話端末（ＩＭＳ端末５０ａ，５０ｂ及びＩＰ電話端末６０）が、ＮＧＮ網２０を介して接続されている。

ＩＭＳ網３０は、移動体通信事業者（キャリアＡ），ＮＧＮ通信事業者（キャリアＢ）ごとに構築され、それぞれが管理運営するＳＩＰサーバ３０ａ，３０ｂを介し、それぞれの網（契約キャリア）ごとにＩＭＳ端末５０ａ，５０ｂが接続されている。なお、ＩＰ電話網４０にはＶｏＩＰ通信事業者（キャリアＣ）のＳＩＰサーバ３０cを介してＩＰ電話端末６０が接続されている。

図１の構成において、発信側である電話番号調査装置１０が着信側の電話端末の電話番号をダイヤル発信することにより、ＮＧＮ網２０内のＳＩＰサーバ２０ａ、発信側ＮＧＮゲートウェイ（ＮＧＮ−ＧＷ）、着信側ＩＭＳゲートウェイ（ＩＭＳ−ＧＷ）、着信側ＮＧＮゲートウェイ（ＮＧＮ−ＧＷ）又は着信側ＶｏＩＰゲートウェイ（ＶｏＩＰ−ＧＷ）、ＳＩＰサーバ３０ａ，３０ｂ，３０ｃ、着信側のＩＭＳ端末５０ａ，５０ｂ及びＩＰ電話端末６０の順でルーティングが実行される。このとき、電話番号調査装置１０とＮＧＮ網２０との間はＵＮＩ接続、ＮＧＮ網２０とＩＭＳ網３０との間の事業者間相互接続はＩＭＳ相互接続インタフェース等を使用することで、電話番号調査装置１０から発信される後述する特定のＳＩＰメッセージがＩＭＳ網３０にトランスペアレントに到達する。なお、図１において、着信側の網として、ＩＭＳ網、ＮＧＮ網、ＩＰ電話網の３つの網が存在するが、ＩＭＳ端末５０ａが接続されるＩＭＳ網とＩＭＳ端末５０ｂが接続されるＮＧＮ網とは同じアーキテクチャをとるため、同一番号３０を付して説明する。

ところで、ＳＩＰによれば、リアルタイム通信を行うためにメディア情報を含むパケットの符号化方式やパケットの宛先等のアドレスについて端末間でネゴシエーションを行う必要がある。このネゴシエーションのために必要になるのがＳＤＰ（Session Description Protocol）と呼ばれる記述言語であり、ＲＦＣ４５６６で定義されている。

ＳＩＰでセッションを確立するためには、まず、発信側がＳＩＰメッセージにメディア情報を記述した要求を送信し、着信側がその中から対応可能なメディアを選択した応答を返信することで、通信に使用するメディア情報を共有する。このようにセッションを開始するためにＳＩＰメッセージにメディア情報を載せることをオファーといい、それに対して対応可能なメディア情報を返却することをアンサーという。このオファーアンサーモデルについてはＲＦＣ３２６４で定義されている。さらに、ＩＭＳにおけるＳＤＰメディアネゴシエーション手順については、ＴＴＣ標準（ＪＪ−９０．２６）で規定されている。

図１に示すように、本実施形態に係る電話番号調査装置１０は、ＮＧＮ網２０（ＳＩＰサーバ２０ａ）、ＩＭＳ網３０（ＳＩＰサーバ３０ａ）、ＮＧＮ網３０（ＳＩＰサーバ３０ｂ）又はＩＰ電話網４０（ＳＩＰサーバ３０ｃ）経由で調査対象となるＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０に、ＩＮＶＩＴＥ（招待）メソッドのＳＤＰオファー（以下、ＩＮＶＩＴＥ要求という）を送信する際に、そのＳＤＰパラメータに、着信側のＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０が着信を拒否するＳＤＰパラメータを付加して送信する（以下、ＩＮＶＩＴＥ（ＳＤＰ不一致）という）。

これに対し、着信側のＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０は、自身が使用可能なＳＤＰパラメータが異なるため着信を拒否し、応答メッセージとして４８８エラー応答（容認不可：Not Acceptable Here）を返信する。電話番号調査装置１０は、４８８エラー応答を受信することにより、後述する仕組みでＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０の実在を正確に判別することが可能になる。

なお、ＩＮＶＩＴＥメソッドのＳＤＰネゴシエーション手順におけるＳＤＰ不一致には、後述するように、「ネットワークプロトコル」の不一致、「メディア種別」の不一致、「トランスポートプロトコル」の不一致、「コーデック」の不一致の４つのケースがある。本実施形態に係る電話番号調査装置１０によれば、これらケースの組み合わせにより、着信ベルを鳴動させる信号を用いないで正確に有効性の判定が可能である。

図２（ａ）（ｂ）に、上記したＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによるＳＤＰ不一致のシーケンスを示す。ここでは、電話番号調査装置１０、発信側のＮＧＮ網２０、発信側ＮＧＮゲートウェイ（ＮＧＮ−ＧＷ）、着信側ＩＭＳゲートウェイ（ＩＭＳ−ＧＷ）、着信側のＩＭＳ網３０、ＩＭＳ端末５０ａ（５０ｂ）におけるＳＤＰネゴシエーション手順が示されている。

図２（ａ）に示すように、電話番号調査装置１０は、ＮＧＮ網２０を介して調査対象となるＩＭＳ端末５０ａ（５０ｂ）の契約キャリアの携帯電話網等の着信側ＩＭＳ網３０経由で該当のＩＭＳ端末５０ａ（５０ｂ）にＩＮＶＩＴＥ要求を送信するが、そのとき、ＩＮＶＩＴＥ要求に含まれるＳＤＰパラメータに着信側のＩＭＳ端末５０ａ（５０ｂ）が着信を拒否する情報を付与して送信する（ステップＳ１１〜Ｓ１５：ＩＮＶＩＴＥ（ＳＤＰ不一致））。これに対し、着信側のＩＭＳ端末５０ａ（５０ｂ）は、ＳＤＰパラメータが自身で使用可能なものと異なるために着信を拒否し、４８８エラー応答を返信する（ステップＳ１６〜Ｓ２０）。

電話番号調査装置１０は、４８８エラー応答を受信することにより、後述する仕組みでＩＭＳ端末５０ａ（５０ｂ）の電話番号使用状況（実在，空）を正確に取得することが可能になる。

ここで、ＳＤＰ不一致のパラメータとは、着信側のＩＭＳ端末５０ａ（５０ｂ）がサポートできない条件をいう。具体的に、「ネットワークプロトコル」の場合、“ＩＰｖ４”が着信側のＩＭＳ端末５０ａ（５０ｂ）のＳＤＰ条件とするのに対し、敢えて、“ＩＰｖ６”でオファーして着信側のＩＭＳ端末５０ａ（５０ｂ）の着信拒否を誘導する情報をいう。また、「メディア種別」の場合、着信側のＩＭＳ端末５０ａ（５０ｂ）が、例えば、音声（ｍ＝ａｕｄｉｏ）をＳＤＰ条件とするのに対し、電話番号調査装置１０が、音声の他に、敢えて、ビデオやアプリケーションなどの全てのメディア種別も付してオファーすることにより着信側のＩＭＳ端末５０ａ（５０ｂ）の着信拒否を誘導する情報をいう。

また、「トランスポートプロトコル」の場合、着信側のＩＭＳ端末５０ａ（５０ｂ）が、例えば、ｍ＝ｖｉｄｅｏ ＲＴＰ／ＡＶＰをＳＤＰ条件とするのに対し、電話番号調査装置１０が、敢えて、拡張ＲＴＰプロファイルであるＡＶＰＦ（ｍ＝ｖｉｄｅｏ ＲＴＰ／ＡＶＰＦ）をオファーして着信側のＩＭＳ端末５０ａ（５０ｂ）の着信拒否を誘導する情報をいい、「コーデック」の場合、着信側のＩＭＳ端末５０ａ（５０ｂ）が、例えば、映像コーデック“ＭＰＥＧ４”を着信側ＳＤＰ条件とするのに対し、敢えて、映像コーデック“Ｈ.２６４”をオファーして着信側のＩＭＳ端末５０ａ（５０ｂ）の着信拒否を誘導する情報をいう。

なお、電話番号調査装置１０は、ＮＧＮ網２０を介して４８８エラー応答を受信すると、ＮＧＮ−ＧＷ、契約キャリアのＩＭＳ−ＧＷとＩＭＳ網３０経由で着信側のＩＭＳ端末５０ａ（５０ｂ）へ確認のためのＡＣＫリクエストを送信する（ステップＳ２１〜Ｓ２５）。このように、本実施形態に係る電話番号調査装置１０は、電話番号使用状況調査のために、ＩＮＶＩＴＥ要求／４８８エラー応答／ＡＣＫリクエストの３ウェイハンドシェイクを実現して、通信の信頼性を高めている。

一方、図２（ｂ）に示すように、着信側のＩＭＳ端末５０ａ（５０ｂ）が不在の場合、電話番号調査装置１０は、着信側のＩＭＳ端末５０ａ（５０ｂ）宛に、ＮＧＮ網２０、ＩＭＳ網３０経由でＳＤＰ不一致のＩＮＶＩＴＥ要求を送信する（ステップＳ３１〜Ｓ３４）。このことにより、電話番号調査装置１０は、着信側のＩＭＳ網３０（ＳＩＰサーバ３０ａ（３０ｂ））から、“４０４／１８３”エラー応答を受信し（ステップＳ３５〜Ｓ３８）、電話番号使用状況（欠番）を取得することができる。電話番号調査装置１０は、４０４エラー応答を受信すると、ＮＧＮ網２０経由でＩＭＳ網３０へ確認のためのＡＣＫリクエストを送信する（ステップＳ３９〜Ｓ４２）。なお、エラー応答である４０４コードはユーザ不在、１８３コードはガイダンス応答を示す。

図３は、本実施形態に係る電話番号調査装置１０の構成を示すブロック図である。図３によれば、本実施形態に係る電話番号調査装置１０は、網インタフェース部１１と、メッセージ交換制御部１２と、電話番号調査判定部１３と、電話番号履歴生成部１４と、電話番号履歴ＤＢ（１５）とを含み、構成される。

網インタフェース部１１は、電話番号調査装置１０がＳＩＰプロトコルに準拠した通信を行うための通信インタフェースを担う。メッセージ交換制御部１２は、ＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０にＳＤＰ不一致のＩＮＶＩＴＥ要求を送信し、着信側ＩＭＳ網３０のＳＩＰサーバ３０ａ，３０ｂ又はＩＰ電話網４０のＳＩＰサーバ３０ｃからメッセージ（エラー応答）を受信する。なお、ＳＤＰ不一致とするために付加されるＳＤＰパラメータは、着信側のＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０が使用不可である、「ネットワークプロトコル」、「メディア種別」、「トランスポートプロトコル」、「コーデック」のいずれかであり、あるいはその組み合わせである。

このため、メッセージ交換制御部１２は、着信側のＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０が使用不可の、ネットワークプロトコル、メディア種別、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなるＳＤＰパラメータを付与して送信する。

電話番号調査判定部１３は、メッセージ交換制御部１２を介して受信したエラー応答に応じて、着信側のＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０の実在の有無等、電話番号の有効性を判定する。電話番号調査判定部１３は、応答メッセージが着信拒否を示す場合に、ＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０の電話番号を実在すると判定する。なお、メッセージ交換制御部１２が、例えば、エラーコード４８８（第１のエラーコード）を受信した場合に、調査対象である着信側のＩＭＳ端末５０ａ，５０ｂ又はＩＰ電話端末６０の電話番号が実在すると判定し、例えば、エラーコード４０４（第２のエラーコード）又は１８３（第３のエラーコード）を受信した場合に電話番号が欠番であると判定する。

電話番号調査判定部１３は、メッセージ交換制御部１２が、ＩＭＳ網３０（ＳＩＰサーバ３０ａ，３０ｂ）から応答メッセージとしてエラーコード４８８（第１のエラーコード）を受信した場合に、調査対象となる着信側のＩＭＳ端末５０ａ，５０ｂの電話番号が、「空き状態で実在する」と判定してもよい。また、メッセージ交換制御部１２が、例えば、エラーコード４８６（第４のエラーコード）を受信した場合に、調査対象である着信側のＩＭＳ端末５０ａ，５０ｂの電話番号が、「話中状態で実在する」と判定してもよい。

電話番号調査判定部１３は、メッセージ交換制御部１２が、ＩＭＳ網３０（ＳＩＰサーバ３０ａ，３０ｂ）から応答メッセージとしてエラーコード４０４（第２のエラーコード）を受信した場合に、調査対象である着信側のＩＭＳ端末５０ａ，５０ｂの電話番号が、「ユーザ不在で解約状態にあり欠番である」と判定してもよい。

電話番号調査判定部１３は、メッセージ交換制御部１２が、ＩＰ電話網４０（ＳＩＰサーバ３０ｃ）から応答メッセージとして４８８（第１のエラーコード）を受信した場合に、調査対象である着信側のＩＰ電話端末６０の電話番号が「空き状態で実在する」と判定してもよい。

電話番号調査判定部１３は、メッセージ交換制御部１２が、ＩＰ電話網４０（ＳＩＰサーバ３０ｃ）から応答メッセージとして、例えば、エラーコード１８３（第３のエラーコード）を受信した場合に、調査対象である着信側のＩＰ電話端末６０の電話番号が、「欠番である」と判定してもよい。

電話番号履歴生成部１４は、電話番号調査判定部１３での判定結果のそれぞれに判定日時を示すタイムスタンプを付与して記録媒体上に時系列に記録することにより電話番号履歴ＤＢ（１５）を構築する。

電話番号履歴ＤＢ（１５）のデータ構造の一例が図１０に示されている。電話番号履歴ＤＢ（１５）に格納される電話番号履歴情報は、電話番号履歴情報レイアウトに示すように、１回の調査ごとに調査対象である「電話番号」と、調査時に判明した移転先あるいは連絡先電話番号である「新加入者番号」と、着信網から返信される「エラーコード」と、「調査年月日」（タイムスタンプ）と、着信網から返信されるレイヤーに関する「その他レイヤー情報」とが記憶されて登録される。

また、電話番号履歴情報の例として、例えば、電話番号「０３−３３５９−０９０６」の電話番号使用状況の調査が実行されると、電話番号調査判定部１３の判定ごとに、上記したレイアウトに調査情報が順次格納され、履歴情報として蓄積される。なお、電話番号履歴ＤＢ（１５）には、上記したデータ項目の他に、電話番号を所有する「法人名・個人名」、住所、年齢等の「属性情報」、「地図リンク情報」と、信用を評価するための「与信情報」とを付加して記録してもよい。

説明を図３に戻す。網インタフェース部１１、メッセージ交換制御部１２、電話番号調査判定部１３、電話番号履歴生成部１４のそれぞれは、プログラムが記録されたメモリを内蔵するか、同メモリが外付けされたマイクロプロセッサと、通信を含む周辺制御用ＬＳＩ（Large Scale Integration）により実現され、マイクロプロセッサがメモリに記録されたプログラムを逐次読み出し実行することにより、電話番号調査装置１０としての以下の機能を実現することができる。

すなわち、ＩＭＳ端末５０ａ（５０ｂ）にＮＧＮ網２０を介してＩＮＶＩＴＥ要求を送信するときに、当該ＩＮＶＩＴＥ要求に含まれるＳＤＰパラメータにＩＭＳ端末５０ａ（５０ｂ）が着信を拒否するＳＤＰパラメータを付与し、ＮＧＮ網２０で選択されるＩＭＳ端末５０ａ（５０ｂ）の契約キャリアごとの着信網となるＩＭＳ網３０を介して送信する。そして、ＮＧＮ網２０で選択された着信網であるＩＭＳ網３０（ＩＭＳ端末５０ａ（５０ｂ））の応答メッセージに応じて、ＩＭＳ端末５０ａ（５０ｂ）の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する。

なお、電話番号履歴ＤＢ（１５）は、半導体メモリ、あるいはハードディスクやＤＶＤ（Digital Versatile Disc）等の光メモリ等の大容量記録媒体に実装される。

（実施形態の動作）
以下、図４のＩＭＳ網３０におけるＳＤＰネゴシエーション手順のフローチャートを参照して、図３の本実施形態に係る電話番号調査装置１０のＳＤＰ記述に基づく通信確立手順から説明する。

図４に示すように、電話番号調査装置１０（メッセージ交換制御部１２）は、電話番号調査の対象となるＩＭＳ端末５０ａ，５０ｂとの間で、ＳＤＰパラメータの記述内容から、ネットワークプロトコルの確認判定（ステップＳ４１）、メディア種別の確認判定（ステップＳ４３）、メディアのトランスポートプロトコルの確認判定（ステップＳ４５）、コーデックの確認判定（ステップＳ４７）の順で通信確立のためのネゴシエーションを行う。

ここでは、ＮＧＮ網２０における通信確立のためのネゴシエーション手順において、ＳＤＰパラメータとして、例えば、ネットワークプロトコルに“ＩＰｖ６”，メディア種別に“全メディアに対応した端末（ｍ＝ａｕｄｉｏ＋ｍ＝ｖｉｄｅｏ＋ｍ＝ａｐｐｌｉｃａｔｉｏｎ）”、トランスポートプロトコルに“ＲＴＰ／ＡＶＰＦ”、映像コーデックに“Ｈ．２６４”を記述してオファーした場合を想定する。

まず、ネットワークプロトコルの確認判定（ステップＳ４１）において、着信側のＩＭＳ端末５０ａ、５０ｂに、ＩＰｖ６をサポートしていないＩＰｖ４端末が実装されている場合（ステップＳ４１“ＮＯ”）、そのＩＰｖ４端末は、メッセージ交換制御部１２に、ネットワークプロトコルの不一致を示すエラーコード４８８（ｗａｒｎｉｎｇコード３００／３０１）を返信する（ステップＳ４２）。一方、ＩＰｖ６端末が実装されていた場合（ステップＳ４１“ＹＥＳ”）、続いてメディア種別の確認判定（ステップＳ４３）が実行される。ここで、ＳＤＰ記述にＩＰｖ６端末が対応していないメディア種別（ｍ）が一つでも含まれていた場合（ステップＳ４３“ＮＯ”）、着信側のＩＭＳ端末５０ａ，５０ｂは、メディア種別の不一致を示すエラーコード４８８（ｗａｒｎｉｎｇコード３０４）を返信する（ステップＳ４４）。

ここで、メディア非対応のＩＰｖ６端末とは、例えば、音声（ｍ＝ａｕｄｉｏ）にのみ対応した電話機、アプリケーション（ｍ＝ａｐｐｌｉｃａｔｉｏｎ）に非対応のＴＶ電話、映像（ｍ＝ｖｉｄｅｏ）に非対応のＩＰ−ＦＡＸ等である。

着信側のＩＭＳ端末５０ａ，５０ｂに、全てのメディアタイプに対応した端末が実装されていた場合（ステップＳ４３“ＹＥＳ”）、続いてトランスポートプロトコルの確認判定が行われる（ステップＳ４５）。ここでは、ＳＤＰ記述にしたがう全てのメディアタイプを利用可能であるが、利用できないトランスポートプロトコル（ＲＴＰ／ＡＶＰＦ）が記述されていた場合（ステップＳ４５“ＮＯ”）、ＡＶＰ端末である着信側のＩＭＳ端末５０ａ，５０ｂは、エラーコード４８８（ｗａｒｎｉｎｇコード３０２）を返信する（ステップＳ４６）。

一方、ＳＤＰ記述にあるトランスポートプロトコルが利用可能であれば（ステップＳ４５“ＹＥＳ”）、続いて、コーデックの確認判定が実行される（ステップＳ４７）。ここで、利用できないコーデックが記述されていた場合（ステップＳ４７“ＮＯ”）、すなわち、着信側のＩＭＳ端末５０ａ，５０ｂに、Ｈ．２６４よりも低画質、低圧縮な映像コーデック、例えばＭＰＥＧ４等を用いる端末が実装されていた場合、そのＨ．２６４以外の端末は、電話番号調査装置１０（メッセージ交換制御部１２）にエラーコード４８８（ｗａｒｎｉｎｇコード３０５）を返信する（ステップＳ４８）。

現状、上記した４つのＳＤＰパラメータの全てに一致するＩＭＳ端末５０ａ，５０ｂは確認されておらず、したがって、着信が拒否され、通信が確立する可能性は限りなくゼロに近いため、電話番号調査装置１０は、着信側のＩＭＳ端末５０ａ，５０ｂの着信ベルを鳴動させる信号を用いないで電話番号の有効性を正しく判定することができる。ＮＧＮ網２０の場合、上記した通信の確立手順において４つの着信を拒否するパラメータの記述が可能であり、ネットワークプロトコル、メディア種別、トランスポートプロトコル、コーデックの４つ全てのＳＤＰパラメータを記述することにより、着信ベルを鳴動させる信号を用いないで正確に判定することができる。

次に、図５にフローチャートで示す電話番号使用状況調査アルゴリズムを参照して、本実施形態に係る電話番号調査方法について説明する。なお、以下に説明する電話番号調査方法は、コンピュータに対し該当する各手順を実行させて達成することができる。

電話番号調査装置１０は、メッセージ交換制御部１２が、調査対象となるＩＭＳ端末５０ａ，５０ｂ，ＩＰ電話端末６０に対してＩＮＶＩＴＥ要求を送信するときに、そのＩＮＶＩＴＥ要求に含まれるＳＤＰパラメータにＩＭＳ端末５０ａ，５０ｂ，ＩＰ電話端末６０が着信を拒否するＳＤＰパラメータを付与し、ＮＧＮ網２０で選択される契約キャリアごとの着信網となるＩＭＳ網３０、あるいはＩＰ電話網４０を介して送信する。

ここで、調査対象となるＩＭＳ端末５０ａ，５０ｂ，ＩＰ電話端末６０の契約キャリアがＡの移動体通信事業者であれば（ステップＳ５１“キャリアＡ”）、電話番号調査判定部１３は、着信側のＩＭＳ端末５０ａから、契約キャリアＡのＩＭＳ網３０経由で返信されるＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答を解読することにより実在／欠番の判定を行う（ステップＳ５２）。

欠番判定（ステップＳ５２“欠番”）は、図２（ａ）（ｂ）のシーケンス図を使用して説明したように、電話番号調査判定部１３が、選択された着信網であるＩＭＳ網３０から返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード“４０４又は１８３”）を解読することにより行われる（ステップＳ５３，Ｓ５７）。

ここで、調査対象のＩＭＳ端末５０ａが実在すれば（ステップＳ５２“実在”）、そのＩＭＳ端末５０ａが空き状態にあるか話中であるかの判定が行われる（ステップＳ５４）。着信側のＩＭＳ端末５０ａの話中判定（ステップＳ５４“話中”）は、図２（ａ）（ｂ）のシーケンス図を使用して説明したように、電話番号調査判定部１３が、選択された着信網であるＩＭＳ網３０から返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答、例えば、エラーコード“４８６”を解読することにより行われ（ステップＳ５５、Ｓ５７）、一方、空き判定（ステップＳ５４“空き”）は、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード４８８）を解読することにより行われる（ステップＳ５６，Ｓ５７）。

なお、ステップＳ５７で判定された着信側のＩＭＳ端末５０ａの電話番号の使用状況は、電話番号履歴生成部１４が、電話番号調査判定部１３による判定結果に基づき、例えば、図１０に示す電話番号履歴情報レイアウトにしたがって電話番号履歴情報を生成し、都度、電話番号履歴ＤＢ（１５）に記録する。ここでは、エラーコードにより、ＩＭＳ／ＶｏＩＰの着信網判定と電話番号使用状況を確認することができる。網判定情報をＤＢ化することで次回以降の電話番号調査に活用できる。電話番号履歴ＤＢ（１５）に蓄積された電話番号履歴情報は、一定期間分蓄積された時点で適当な形式で編集し、電話番号使用状況調査記録媒体として検索用に希望者に頒布される。

次に、調査対象となるＩＭＳ端末５０ａ，５０ｂ，ＩＰ電話端末６０の契約キャリアがＢのＮＧＮ通信事業者であれば（ステップＳ５１“キャリアＢ”）、電話番号調査判定部１３は、着信側のＩＭＳ端末５０ｂから、契約キャリアＢのＮＧＮ網３０経由で返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答を解読することにより実在／欠番の判定を行う（ステップＳ５８）。

欠番判定（ステップＳ５８“欠番”）は、電話番号調査判定部１３が、選択された着信網であるＮＧＮ網３０から返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード“４０４又は１８３”）を解読することにより行われる（ステップＳ５９，Ｓ６３）。

ここで、調査対象となるＩＭＳ端末５０ｂが実在すれば（ステップＳ５８“実在”）、続いて空き状態にあるか話中であるかの判定が行われる（ステップＳ６０）。着信側のＩＭＳ端末５０ｂの話中判定（ステップＳ６０“話中”）は、電話番号調査判定部１３が、選択された着信網であるＮＧＮ網３０から返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード“４８６”）を解読することにより行われる（ステップＳ６１，Ｓ６３）。一方、空き判定（ステップＳ６０“空き”）は、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード４８８）を解読することにより行われる（ステップＳ６２，Ｓ６３）。

なお、ステップＳ６３で判定されたＩＭＳ端末５０ｂの電話番号の使用状況は、電話番号履歴生成部１４が、電話番号調査判定部１３による判定結果に基づき、図１０に示す電話番号履歴情報レイアウトにしたがって電話番号履歴情報を生成し、都度、電話番号履歴ＤＢ（１５）に記録する。電話番号履歴ＤＢ（１５）に蓄積された電話番号履歴情報は、一定期間分蓄積された時点で適当な形式で編集し、電話番号使用状況調査記録媒体として検索用に希望者に頒布される。

次に、調査対象となるＩＭＳ端末５０ａ，５０ｂ，ＩＰ電話端末６０の契約キャリアがＣのＶｏＩＰ通信事業者であれば（ステップＳ５１“キャリア”Ｃ”）、電話番号調査判定部１３は、着信側のＩＰ電話端末６０から、契約キャリアＣのＩＰ電話網４０経由で返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答を解読することにより実在／欠番の判定を行う（ステップＳ６４）。

欠番判定（ステップＳ６４“欠番”）は、電話番号調査判定部１３が、選択された着信網であるＩＰ電話網４０から返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード“１８３”）を解読することにより行われる（ステップＳ６７，Ｓ７１）。

ここで、ＩＰ電話端末６０が実在すれば（ステップＳ６４“実在”）、空き状態にあるか話中であるかの判定が行われる（ステップＳ６８）。着信側のＩＰ電話端末６０の話中判定（ステップＳ６８“話中”）は、電話番号調査判定部１３が、選択された着信網であるＩＰ電話網４０から返信される、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード“４８６”）を解読することにより行われる（ステップＳ６９，Ｓ７１）。一方、空き判定（ステップＳ６８“空き”）は、ＳＤＰ不一致によるＩＮＶＩＴＥ要求に対する応答（エラーコード４８８）を解読することにより行われる（ステップＳ７０，Ｓ７１）。

なお、ステップＳ７１で判定されたＩＰ電話番号の使用状況は、電話番号履歴生成部１４が、電話番号調査判定部１３による判定結果に基づき、図１０に示す電話番号履歴情報レイアウトにしたがって電話番号履歴情報を生成し、都度、電話番号履歴ＤＢ（１５）に記録する。電話番号履歴ＤＢ（１５）に蓄積された電話番号履歴情報は、一定期間分蓄積された時点で適当な形式で編集し、電話番号使用状況調査記録媒体として検索用に希望者に頒布される。

ここで、本実施形態に係る電話番号調査装置１０において、ＳＤＰ不一致のパラメータ記述を、「ネットワークプロトコル」、「メディア種別」、「トランスポートプロトコル」、「コーデック」とした場合の、それぞれにおけるＩＮＶＩＴＥ要求の一例と、そのシーケンスについて、ＩＭＳ相互接続を例示し、実施例１，実施例２，実施例３，実施例４として以下に詳細な説明を行う。

（実施例１：ネットワークプロトコル）
以下に説明する実施例１は、オファー側が、アンサー側に対しＳＤＰ不一致のパラメータ記述を含むＩＮＶＩＴＥ要求を送信し、アンサー側から４８８エラーレスポンスを受信し、当該レスポンスにＷａｒｎｉｎｇヘッダが設定され、Ｗａｒｎｉｎｇコード“３００（Incompatible network protocol）”、又は“３０１（Incompatible network protocol address format）”が含まれる場合が相当する。この場合のＩＮＶＩＴＥ要求のＳＤＰ不一致パラメータ記述の例を図６（ａ）に、その動作シーケンスを図６（ｂ）に示す。なお、図６（ａ）において、ヘッダ部の記述は省略されており、また、図６（ｂ）において、電話番号調査装置１０は、ＩＰｖ４が１９２．０．１．１，ＩＰｖ６が２００１：ｄｂ８：１２３４：５６７８：ａｃｄｅ：４８ｆｆ．ｆｅ０１：２３４５（図６（ａ））のＩＰアドレスが割り当てられた「オファー側」とし、ＮＧＮ網２０で選択されたＩＭＳ端末５０ａは、１９２．０．２．２のＩＰｖ４アドレスが割り当てられたアンサー側としてそれぞれ表記し、また、仲介するＮＧＮ網２０及びＩＭＳ網３０は、単に、「網」と省略して表記されている。

図６（ａ）に矢印で示したように、オファー側が、ＩＮＶＩＴＥ要求のＳＤＰパラメータ記述に、「ＩＰｖ６」ネットワークプロトコルを使用して発信することを指定してＩＮＶＩＴＥ要求を送信する。このとき、アンサー側は、ＩＰｖ４ネットワークプロトコルによる通信にしか対応しておらず、ＩＰｖ６ネットワークプロトコルは未対応であるため、オファー側は、４８８エラーレスポンスを受信することになる。

具体的に、図６（ｂ）の動作シーケンスに示すように、オファー側は、アンサー側に対し、ＳＤＰパラメータのネットワークプロトコルに、アンサー側（ＩＰｖ４端末）が対応していない「ＩＰｖ６」を指定してＩＮＶＩＴＥ要求を送信する（ステップＳ１０１）。このＩＮＶＩＴＥ要求を網経由でトランスペアレントに受信したアンサー側は（ステップＳ１０２）、ＳＤＰパラメータ記述が正規のパラメータ（アンサー側はＩＰｖ６に非対応）と異なるため、着信を拒否してＷａｒｎｉｎｇコード３０１を付して４８８エラー応答を返信する（ステップＳ１０３）。

オファー側は、４８８エラーレスポンスを受信することにより、Ａで示すように、アンサー側がＩＰｖ６に対応していないものと判定し、アンサー側の電話番号使用状況を正確に取得することが可能になる（ステップＳ１０４）。そして、網はアンサー側に確認のためのＡＣＫリクエストを、オファー側は網にＡＣＫリクエストをそれぞれ送信する（ステップＳ１０５，Ｓ１０６）。

なお、オファー側は、ＩＰｖ６ネットワークプロトコルを用いた発信に対し、網側のＳＩＰサーバ３０ａから４８８エラーレスポンスが返信された場合に、調査対象である着信側のＩＭＳ端末５０ａがＩＰｖ６ネットワークプロトコルを用いた通信に対応していないと判定し、ＩＰｖ４を用いた再発呼オファーによるフォールバック動作を行う。すなわち、４８８レスポンスを受信すると、網にＡＣＫリクエスト送信後に、ＩＮＶＩＴＥ要求のＳＤＰパラメータ（ネットワークプロトコル）をＩＰｖ６からＩＰｖ４に変更して再発呼する（ステップＳ１０７）。

この再発呼オファーは、アンサー側に網経由でトランスペアレントに伝達され（ステップＳ１０８）、再発呼オファーを受信したアンサー側は、セッションを確立できる状態になった時点でオファー側へ網経由で「２００ＯＫ」応答を送信する（ステップＳ１０９、Ｓ１１０）。

（実施例２：メディア種別）
以下に説明する実施例２は、発信側である電話番号調査装置１０が着信側のＩＭＳ端末５０ａに対し、ＳＤＰ不一致パラメータ記述を含むＩＮＶＩＴＥ要求を送信し、ＮＧＮ網２０及び着信網であるＩＭＳ網３０を介して４８８エラーレスポンスを受信した場合で、かつ、このエラーレスポンスにＷａｒｎｉｎｇコード“３０４（Media type not available）”が含まれる場合が相当する。

この場合のＩＮＶＩＴＥ要求のＳＤＰ不一致パラメータ記述の例を図７（ａ）に、その動作シーケンスを図７（ｂ）に示している。なお、図７（ａ）において、ヘッダ部の記述は省略されており、また、図７（ｂ）において、電話番号調査装置１０は、１９２．０．１．１（図７（ａ））のＩＰアドレスが割り当てられた「オファー側」とし、ＮＧＮ網２０で選択されたＩＭＳ端末５０ａは、１９２．０．２．２のＩＰアドレスが割り当てられたアンサー側としてそれぞれ表記し、また、仲介するＮＧＮ網２０及びＩＭＳ網３０は、単に、「網」と省略して表記されている。

図７（ａ）に矢印で示したように、オファー側が、ＩＮＶＩＴＥ要求のＳＤＰパラメータ記述に、例えば、「テレビ電話」（音声の他に映像も使用可能）のメディア種別（ｍ＝ａｕｄｉｏ＋ｍ＝ｖｉｄｅｏ）を付して送信するものとする。このとき、アンサー側（電話機）は、ｍ＝ａｕｄｉｏのメディア種別には対応しているものの、ｍ＝ｖｉｄｅｏのメディア種別には対応していないため、オファー側は、アンサー側から網経由で４８８エラーメッセージを受信することになる。

具体的に、図７（ｂ）の動作シーケンスに示すように、オファー側は、まず、アンサー側（電話機）に対して、ＳＤＰパラメータのメディア種別を「映像＋音声」としてＩＮＶＩＴＥ要求を送信する（ステップＳ２０１）。このＩＮＶＩＴＥ要求によるオファーは、網を介しトランスペアレントにアンサー側に到達する（ステップＳ２０２）。続いてアンサー側は、受信したＩＮＶＩＴＥ要求に記述されたＳＤＰパラメータが正規のパラメータ（アンサー側は音声のみ対応し映像は不対応）と異なるため、着信を拒否して４８８エラーレスポンスに、Ｗａｒｎｉｎｇコード３０４（Media type not available）を付加してオファー側に返信する（ステップＳ２０３）。オファー側は、網を介して４８８エラーレスポンスをトランスペアレントに受信することにより、アンサー側の電話番号使用状況（実在，空）を正確に取得することができる（ステップＳ２０４）。

このとき、Ｂで示すように、オファー側は、Ｗａｒｎｉｎｇコード３０４（Media type not available）を含む４８８エラー応答により、アンサー側にはＩＮＶＩＴＥ要求に付与されたＳＤＰパラメータ（メディア種別）を使用する能力が無い（メディア種別ｖｉｄｅｏの＝行が受容されなかった）と判定する。そして、網はアンサー側に確認のためのＡＣＫリクエストを、オファー側は網にＡＣＫリクエストをそれぞれ送信する（ステップＳ２０５，Ｓ２０６）。

なお、オファー側は、網へＡＣＫリクエスト送信後、記述したメディア種別のいずれに対してもアンサー側が対応する能力を持たないと判定することなく、ＩＮＶＩＴＥ要求に付されたＳＤＰ記述（メディア種別）を同時に使用する能力を持たないと判定して、一部のメディア記述を除外して作成したＳＤＰを用い、網にＩＮＶＩＴＥ要求による再発呼オファーを行うフォールバック動作（縮退運転）を行う（ステップＳ２０７）。再発呼オファーは、アンサー側に網経由でトランスペアレントに伝達される（ステップＳ２０８）。

再発呼オファーを受信したアンサー側は、セッションを確立できる状態になった時点でオファー側へ網経由で「２００ＯＫ」応答を送信する（ステップＳ２０９，Ｓ２１０）。

（実施例３：トランスポートプロトコル）
以下に説明する実施例３は、オファー側がアンサー側に対し網経由でＳＤＰ不一致パラメータの記述を含むＩＮＶＩＴＥ要求を送信し、アンサー側から４８８エラーレスポンスを受信し、当該レスポンスにＷａｒｎｉｎｇヘッダが設定され、Ｗａｒｎｉｎｇコードに“３０２（Incompatible transport Protocol）”が含まれる場合が相当する。この場合のＩＮＶＩＴＥ要求のＳＤＰ不一致パラメータ記述の例を図８（ａ）に、その動作シーケンスを図８（ｂ）に示す。

図８（ａ）に矢印で示したように、オファー側が、ＩＮＶＩＴＥ要求のＳＤＰパラメータ記述に、ｍ＝ｖｉｄｅｏのトランスポートプロトコルとして、ＲＴＰ／ＡＶＰＦを指定し、「テレビ電話」のメディア種別を付してＩＮＶＩＴＥ要求を送信するものとする。このとき、アンサー側は、ＲＴＰ／ＡＶＰのみに対応し、ＲＴＰ／ＡＶＰＦに対応していないため、オファー側は、４８８エラーレスポンスを受信することになる。

具体的に、図８（ｂ）の動作シーケンスに示すように、オファー側は、アンサー側（映像ＲＴＰ／ＡＶＰ端末）に対し、ＳＤＰパラメータのトランスポートプロトコルを「ＲＴＰ／ＡＶＰＦ」としてＩＮＶＩＴＥ要求を送信する（ステップＳ３０１）。このＩＮＶＩＴＥ要求によるオファーは、網を介しトランスペアレントにアンサー側に到達する（ステップＳ３０２）。

これに対し、アンサー側は、受信したＩＮＶＩＴＥ要求に記述されたＳＤＰパラメータが正規のパラメータ（アンサー側はＡＶＰに対応するがＡＶＰＦに非対応）と異なるため、着信を拒否する４８８エラーレスポンスにＷａｒｎｉｎｇコード３０２（Incompatible transport Protocol）を付して返信する（ステップＳ３０３）。オファー側は、４８８エラーレスポンスを受信することにより（ステップＳ３０４）、Ｃで示すように、１以上について指定されているトランスポートプロトコルを使用する能力がない（ＲＴＰ／ＡＶＰＦが受容できない）と判定し、アンサー側の電話番号使用状況を正確に取得することが可能になる。

そして、網はアンサー側に確認のためのＡＣＫリクエストを、オファー側は網にＡＣＫリクエストをそれぞれ送信する（ステップＳ３０５，Ｓ３０６）。なお、オファー側は、網へＡＣＫリクエスト送信後、ＳＤＰパラメータ記述のうち、１以上について指定されているトランスポートプロトコルを使用する能力がアンサー側にないと判定し、トランスポートプロトコルを変更して網に対しＩＮＶＩＴＥ要求に基づく再発呼オファーによるフォールバック動作を行う（ステップＳ３０７）。

具体的に、ｍ＝ｖｉｄｅｏのトランスポートプロトコルとして、ＲＴＰ／ＡＶＰＦを指定して「テレビ電話」のＳＤＰオファー（ｍ＝ａｕｄｉｏ＋ｍ＝ｖｉｄｅｏのメディア記述）を行ったのに対して、アンサー側が、ＲＴＰ／ＡＶＰＦに対応していない（ＲＴＰ／ＡＶＰのみ対応）ため、当該４８８エラー応答を受信する結果になった場合に、オファー側がＳＤＰ記述をＲＴＰ／ＡＶＰＦからＲＴＰ／ＡＶＰに変更して再発呼オファーするフォールバック動作を行う。

再発呼は、アンサー側に網経由でトランスペアレントに伝達され（ステップＳ２０８）、再発呼オファーを受信したアンサー側は、セッションを確立できる状態になった時点でオファー側へ網経由で「２００ＯＫ」応答を送信する（ステップＳ３０９，Ｓ３１０）。

（実施例４：コーデック）
以下に説明する実施例４は、オファー側がアンサー側に対しＳＤＰ不一致のパラメータ記述（コーデック）を含むＩＮＶＩＴＥ要求を送信し、アンサー側から４８８エラーレスポンスを受信し、当該レスポンスにＷａｒｎｉｎｇヘッダが設定され、Ｗａｒｎｉｎｇコードに“３０５（Incompatible media format）”が含まれる場合が相当する。この場合のＩＮＶＩＴＥ要求のＳＤＰ不一致パラメータ記述の例を図９（ａ）に、その動作シーケンスを図９（ｂ）に示す。

図９（ａ）に矢印で示したように、オファー側が、ＩＮＶＩＴＥ要求のＳＤＰパラメータ記述に、例えば、動画に特化したＨ．２６４等を用いるＳＤＰ記述によるＩＮＶＩＴＥ要求（映像コーデックにＨ．２６４を設定）を送信するものとする。このとき、アンサー側は、Ｈ．２６４に対応していないため、オファー側は、４８８エラーレスポンスを受信することになる。

具体的に、図９（ｂ）の動作シーケンスに示すように、オファー側は、アンサー側（映像ＭＰＥＧ４端末）に対し、ＳＤＰパラメータの映像コーデックを、アンサー側が対応していない、「Ｈ．２６４」としてＩＮＶＩＴＥ要求を送信する（ステップＳ４０１）。このＩＮＶＩＴＥ要求を網経由でトランスペアレントに受信したアンサー側は（ステップＳ４０２）、記述されたＳＤＰパラメータが正規のパラメータと異なるため、着信を拒否して４８８エラーレスポンスにＷａｒｎｉｎｇコード３０５（Incompatible media format）を付して返信する（ステップＳ４０３）。オファー側は、４８８エラーレスポンスを受信することにより、Ｄで示すように、アンサー側がコーデック種別Ｈ．２６４に対応していないものと判定し、アンサー側の電話番号使用状況を正確に取得することが可能になる（ステップＳ４０４）。

そして、網はアンサー側に確認のためのＡＣＫリクエストを、オファー側は網にＡＣＫリクエストをそれぞれ送信する（ステップＳ４０５，Ｓ４０６）。なお、オファー側は、網へＡＣＫリクエスト送信後、ＳＤＰパラメータ記述のうち、１以上について指定されているコーデックを使用する能力がアンサー側にないと判定し、コーデックを変更してＩＮＶＩＴＥ要求による再発呼オファーを行う。具体的に、Ｈ．２６４を用いるＳＤＰ記述（映像コーデックにＨ．２６４を設定）を、例えば、映像コーデックＭＰＥＧ４に変更して再発呼オファーによるフォールバック動作を行う（ステップＳ４０７）。

この再発呼オファーは、アンサー側に網経由でトランスペアレントに伝達され（ステップＳ４０８）、再発呼オファーを受信したアンサー側は、セッションを確立できる状態になった時点でオファー側へ網経由で「２００ＯＫ」応答を送信する（ステップＳ４０９，Ｓ４１０）。

なお、図６〜図９に示したいずれの実施例においても、オファー側の電話番号調査装置１０は、アンサー側のＩＭＳ端末５０ａに、網経由でＩＮＶＩＴＥ要求を送信するときに、当該ＩＮＶＩＴＥ要求に含まれるＳＤＰパラメータに着信を拒否するＳＤＰパラメータを付与し、ＮＧＮ網２０で選択されるＩＭＳ端末５０ａの契約キャリアごとの着信網となるＩＭＳ網３０を介して送信する。そして、選択されたＩＭＳ網３０経由でアンサー側のＩＭＳ端末５０ａの応答メッセージを受信し、受信した応答メッセージに応じて、ＩＭＳ端末５０ａの電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定するものである。

ところで、光ＩＰ電話等、これまでの加入者番号と同じ形式を持つ、０で始まる電話番号が割り当てられた０ＡＢ−Ｊ型電話番号を持つＩＰ電話の場合、ＬＮＰ（Local Number Portability）により、着信網がＩＭＳ網（ＮＧＮ網）かＩＰ電話網（ＶｏＩＰ網）かの区別ができず、ＩＭＳ網（ＮＧＮ網）とＩＰ電話網（ＶｏＩＰ網）ではＳＤＰ不一致のパラメータが異なる。

すなわち、ＩＭＳ網３０（ＮＧＮ網）の場合、ＩＰｖ４とＩＰｖ６のネットワークプロトコルのいずれにも対応しているが、ＩＰ電話網４０場合、ＩＰｖ４にのみ対応し、ＩＰｖ６には対応していない。また、ＩＭＳ網３０（ＮＧＮ網）は、音声、映像のいずれのメディア種別にも対応するが、ＩＰ電話網４０の場合、音声のみにしか対応していない。このため、電話番号調査装置１０は、ＩＰ電話が接続される着信網の判定後、それぞれに応じたＳＤＰパラメータを設定して発信する必要がある。

以降の説明では、０ＡＢ−Ｊ型番号を持つＩＰ電話として、着信網であるＩＭＳ網３０（ＮＧＮ網）に接続されるＩＭＳ端末５０ｂ、ＩＰ電話網４０に接続されるＩＰ電話端末６０を想定し、０ＡＢ−Ｊ型番号が割り当てられたＩＰ電話の着信網の判定手順について、図１１に示す着信網の網判定手順のフローチャートを参照しながら詳細に説明する。

図１１において、電話番号調査装置１０は、まず、メッセージ交換制御部１２が、調査対象とするＩＰ電話（ＩＭＳ端末５０ｂ又はＩＰ電話端末６０）に対し、ＩＮＶＩＴＥ要求に、例えば、ネットワークプロトコルとしてＩＰｖ６、あるいはメディア種別として音声と映像（ａｕｄｉｏ＋ｖｉｄｅｏ）を設定したＩＭＳ網（ＮＧＮ網）に準拠した第１のＳＤＰパラメータを付与してオファー（送信）する（ステップＳ５０１）。ここでは、ネットワークプロトコルＩＰｖ６を設定するものとして説明する。

次に、メッセージ交換制御部１２は、第１のＳＤＰパラメータが付与されたＩＮＶＩＴＥ要求に対し、着信網からからアンサーとしてＩＰｖ６を拒否するエラーコードを含む応答メッセージを受信すると（ステップＳ５０２“ＹＥＳ”）、調査対象のＩＰ電話は「ＩＰ電話端末６０」であると判定し、ネットワークプロトコルとしてＩＰｖ４(メディア種別の場合音声のみ)設定したＶｏＩＰ網に準拠した第２のＳＤＰパラメータを付与してＩＮＶＩＴＥ要求を送信する（ステップＳ５０３）。

電話番号調査判定部１３は、ステップＳ５０３でオファーしたＩＮＶＩＴＥ要求に対し、メッセージ交換制御部１２が受信した応答メッセージを取り込むと、その応答メッセージに含まれるエラーコードが“４８８”であれば、調査対象のＩＰ電話端末６０に割り当てられた電話番号は実在すると判定し、エラーコードが“１８３”であれば欠番であると判定する（ステップＳ５０４）。

なお、電話番号調査判定部１３は、ステップＳ５０２で着信網からからアンサーとしてＩＰｖ６拒否エラー以外の応答メッセージを受信すると（ステップＳ５０２“ＮＯ”）、調査対象のＩＰ電話は、「ＩＭＳ端末５０ｂ」であると判定し、その応答メッセージに含まれるエラーコードが“４８８”あるいは“４８６”であればその電話番号は実在し、“４０４”であれば欠番であると判定する（ステップＳ５０５）。

図１２に、本実施形態に係る電話番号調査装置１０の着信網の網判定手順がネットワーク上に概念図として示してある。図１２によれば、まず、電話番号調査装置１０は、メッセージ交換制御部１２が０ＡＢ−Ｊ型番号が割り当てられた調査対象のＩＰ電話端末６０に対しＩＮＶＩＴＥ要求を送信するとき、そのＩＮＶＩＴＥ要求に、ネットワークプロトコルとしてＩＰｖ６が設定された、ＮＧＮ網３０に準拠したＳＤＰパラメータ（第１のＳＤＰパラメータ）を付与し、発信側のＮＧＮ網２０を介して選択されるＩＰ電話の契約キャリアごとの着信網となるＩＰ電話網４０に送信する（Ｓ５０１）。

続いて、メッセージ交換制御部１２が、ＩＰ電話網４０からＩＰｖ６を拒否するエラーコードを含む第１の応答メッセージを受信すると（Ｓ５０２）、電話番号調査装置１０は、着信網としてのＩＰ電話網４０用に、適切なＩＰｖ４が設定された、ＩＰ電話網４０に準拠したＳＤＰパラメータ（第２のＳＤＰパラメータ）を付与してＩＮＶＩＴＥ要求を送信し（Ｓ５０３）、該当のＩＰ電話端末６０からのエラーコード（第２の応答メッセージ）を受信する（Ｓ５０４）。

ここで、電話番号調査判定部１３は、第２の応答メッセージに含まれるエラーコードが“４８８”であれば、調査対象のＩＰ電話（ＩＰ電話端末６０）に割り当てられた電話番号は実在すると判定し、エラーコード１８３であれば欠番であると判定できる。一方、ステップＳ５０２で着信網からからアンサーとしてＩＰｖ６拒否エラー以外の応答メッセージを受信した場合、着信網はＮＧＮ網３０であると判定し、第１の応答メッセージに含まれるエラーコードが“４８８”あるいは“４８６”であればその電話番号は実在し、“４０４”であれば欠番であると判定する。

つまり、電話番号調査装置１０は、ＬＮＰにより、着信網がＩＭＳ網（ＮＧＮ網）かＩＰ電話網（ＶｏＩＰ網）かの区別ができず、着信網によってはＳＤＰ不一致のパラメータが異なる０ＡＢ−Ｊ型番号を持つＩＰ電話（ＩＭＳ端末５０ｂ，ＩＰ電話端末６０）において、メッセージ交換制御部１２が、調査対象のＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、当該ＩＮＶＩＴＥ要求に、ネットワークプロトコルとしてＩＰｖ６が設定された、ＮＧＮ網３０に準拠した第１のＳＤＰパラメータを付与し、ＮＧＮ網２０を介して選択される契約キャリアごとの着信網となるＩＭＳ網３０又はＩＰ電話網４０に送信する。そして、着信網から第１の応答メッセージを受信すると、ＩＰｖ６拒否エラーか否かを判断し、ＩＰｖ６を拒否する応答メッセージの場合にはＩＰ電話網４０のＳＤＰ不一致となる第２のＳＤＰパラメータを付与して送信し、着信網から第２の応答メッセージを受信することにより、調査対象のＩＰ電話が接続される着信網の網判定を行う。そして、電話番号調査判定部１３が、第１の応答メッセージ又は第２の応答メッセージに応じて、０ＡＢ−Ｊ型番号が割り当てられた調査対象のＩＰ電話の電話番号使用状況について、着信網（ＩＭＳ網３０（ＮＧＮ網）、ＩＰ電話網４０）に依存することなく、着信ベルを鳴動させる信号を用いないで判定することができる。

なお、上記した本実施形態に係る電話番号調査装置１０によれば、着信網の種別に応じて、ＩＭＳ／ＮＧＮ網用のＳＤＰパラメータ、あるいはＶｏＩＰ網用のＳＤＰパラメータを送信する機能を有するものとして説明したが、ＩＭＳ／ＮＧＮ網用のＳＤＰパラメータを送信する電話番号調査装置１０と、ＶｏＩＰ網用のＳＤＰパラメータを送信する電話番号調査装置１０とをそれぞれ独立に設けてもよい。

（実施形態の効果）
以上説明したように本実施形態に係る電話番号調査装置１０によれば、事業者間相互接続にＩＭＳ相互接続インタフェース等を利用し、ＩＭＳ網３０における電話番号の使用状況のリサーチを着信ベル無鳴動で実現することができる。このため、ＮＧＮ網２０と接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することにより新システム基盤への円滑な移行を可能にする。

また、本実施形態による電話番号調査装置１０によれば、ＮＧＮ網２０側で着信網であるキャリアごとのＩＭＳ網３０を選択するため、携帯電話番号ポータビリティであるＭＮＰ（Mobile Number Portability）に対応でき、ＵＮＩ接続時とは異なり網違い（調査対象の電話番号が他網に接続された電話端末）が発生しない。このため、電話番号調査の手順が簡素化され、電話番号調査装置１０での判定負荷を軽減することができる。さらに、ＮＧＮ網２０のみ電話番号調査装置１０及び回線を設置すればよいため設備投資のコストも低減することができる。

なお、本実施形態に係る電話番号調査装置１０によれば、調査対象となる電話端末として、携帯電話等のＩＭＳ端末５０ａ，５０ｂ、及びＩＰ電話端末６０を例示したが、ＩＰ電話端末６０については、メタルＩＰ電話、あるいは０５０で始まる１１桁の電話番号が割り当てられた０５０型ＩＰ電話、光電話等、これまでの加入者電話と同じ形式を持つ０で始まる電話番号が割り当てられた０ＡＢ−Ｊ型ＩＰ電話も含まれ、ＩＰ電話の種類、及び着信網に依存することなく、電話番号の有効／無効調査を行う際に正確に判定することができる。

また、これら電話端末は、通信確立のために、ＳＤＰパラメータの記述内容から、ネットワークプロトコルの確認、メディア種別の確認、メディアのトランスポートプロトコルの確認、コーデックの確認の順に従いネゴシエーションを行うが、ＮＧＮ網の場合、ＩＭＳ網と同様にこのネゴシエーションの手順における４つの着信を拒否するパラメータ記述が可能であり、これら４つのパラメータ全てを記述することにより、着信ベルを鳴動させる信号を用いないで正確に判定することができる。また、ＩＰ電話端末６０（０ＡＢ−Ｊ型番号及び０５０番号）は、ＩＰｖ６やマルチメディアは未サポートのため、トランスポートプロトコルとコーデックの２つの着信を拒否するパラメータ記述により、着信側のＩＰ電話端末６０の着信ベルを鳴動させる信号を用いないで有効性判定を正確化することができる。

なお、ＬＮＰにより、着信網がＩＭＳ網（ＮＧＮ網）かＩＰ電話網（ＶｏＩＰ網）かの区別ができず、着信網によってはＳＤＰ不一致のパラメータが異なる０ＡＢ−Ｊ型番号を持つＩＰ電話（ＩＭＳ端末５０ｂ，ＩＰ電話端末６０）の場合、メッセージ交換制御部１２が、調査対象のＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、当該ＩＮＶＩＴＥ要求に、ネットワークプロトコルとしてＩＰｖ６が設定された、ＮＧＮ網３０に準拠した第１のＳＤＰパラメータを付与し、ＮＧＮ網２０を介して選択される契約キャリアごとの着信網となるＩＭＳ網３０又はＩＰ電話網４０に送信する。そして、着信網から第１の応答メッセージを受信すると、ＩＰｖ６拒否エラーか否かを判断し、ＩＰｖ６を拒否する応答メッセージの場合にはＩＰ電話網４０のＳＤＰ不一致となる第２のＳＤＰパラメータを付与して送信し、着信網から第２の応答メッセージを受信することにより、調査対象のＩＰ電話が接続される着信網の網判定を行う。このことにより、電話番号調査判定部１３が、メッセージ交換制御部１２で受信した第１の応答メッセージ又は第２の応答メッセージに応じて、ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する。したがって、本実施形態に係る電話番号調査装置１０によれば、着信網に依存せずにＩＰ電話の着信ベルを鳴動させる信号を用いないで有効性判定を正確化することができる。

なお、本実施形態に係る電話番号調査装置１０の実施例１〜実施例４において、電話番号調査装置１０は、電話番号使用状況調査のために、ＩＮＶＩＴＥ／４８８レスポンス／ＡＣＫの３ウェイハンドシェイクを実施した後に、ＩＮＶＩＴＥ要求のＳＤＰパラメータを変更して再発呼するフォールバック動作を行うものとして説明したが、フォールバック動作の実施は必須でなく、いずれもフォールバック動作を実施することなく着信側ＩＰ電話の電話番号の有効／無効調査を行う際の正確な判定を実現している。

このように、本実施形態に係る電話番号調査装置１０によれば、ＩＭＳ端末５０ａ、５０ｂ及びＩＰ電話端末６０の電話番号が使用されている状態（有効（実在））、使用されていない状態（無効（欠番））、移転の別を正確に判定できる。また、無着信の結果、これまで一部発生していた課金も全て遮断することができる。そして、判定結果において、判定した期日、時間を判定結果とともに記録媒体（電話番号履歴ＤＢ（１５））に記録できるツールも用意している。この記録媒体には、例えば、図１０にそのデータ構造の一例が示されているように、調査対象の電話番号ごとに、判定結果、移転元電話番号とリンクした移転先電話番号の情報、判定した期日、時間が記録される。

（プログラム）
なお、本実施形態に係るプログラムは、例えば、図１に示すように、ＩＭＳ網３０（ＮＧＮ網）又はＩＰ電話網４０に接続され、０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話（ＩＭＳ端末５０ｂ，ＩＰ電話端末６０）が、ＮＧＮ網（２０）を介して接続される電話番号調査装置１０のプログラムである。そして、そのプログラムは、例えば、図１１に示すように、コンピュータ（電話番号調査装置１０）に、調査対象のＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、当該ＩＮＶＩＴＥ要求に第１のＳＤＰパラメータを付与し、ＮＧＮ網２０で選択されるＩＰ電話の契約キャリアごとの着信網となるＩＭＳ網３０（ＮＧＮ網）又はＩＰ電話網４０に送信する手順（ステップＳ５０１）と、着信網から第１の応答メッセージを受信すると、第１の応答メッセージがＩＰｖ６を拒否するメッセージであれば、第１のＳＤＰパラメータとは異なる第２のＳＤＰパラメータを付与して送信して着信網から第２の応答メッセージを受信する手順（ステップＳ５０２，Ｓ５０３）と、受信した第１の応答メッセージ又は第２の応答メッセージに応じて、ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する手順（Ｓ５０４，Ｓ５０５）と、を実行させるものである。

本実施形態に係るプログラムによれば、電話番号調査装置１０が図示省略したメモリに記録された当該プログラムを逐次読み出し実行することにより、事業者間相互接続にＩＭＳ相互接続インタフェース等を利用し、ＩＭＳ網３０における電話番号の使用状況のリサーチを着信ベル無鳴動で実現することができる。このため、ＮＧＮ網２０と接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することにより新システム基盤への円滑な移行を可能にする。特に、０ＡＢ−Ｊ型番号が割り当てられた調査対象のＩＰ電話（ＩＭＳ端末５０ｂ又はＩＰ電話端末６０）の電話番号使用状況について、着信網（ＩＭＳ網３０（ＮＧＮ網）、ＩＰ電話網４０）の種類に依存することなく、着信ベルを鳴動させる信号を用いないで判定することができる。

（電話番号調査情報提供システム）
図１３は、本実施形態に係る電話番号調査情報提供システム１００のシステム構成図である。図１３に示すように、本実施形態に係る電話番号調査情報提供システム１００は、１以上のユーザ端末９０と、ユーザ端末９０とはＩＰ網８０経由で接続されるとともに、図示省略した網と接続される電話番号調査サーバ（図１の電話番号調査装置１０）とを含む。

電話番号調査サーバ１０は、ユーザ端末９０から調査対象番号に基づく電話番号調査情報提供要求をＩＰ網８０経由で受信すると、調査対象のＩＰ電話（ＩＭＳ端末５０ｂ，ＩＰ電話端末６０）に対してＩＮＶＩＴＥ要求を送信するときに、当該ＩＮＶＩＴＥ要求に第１のＳＤＰパラメータを付与し、ＮＧＮ網２０を介して選択されるＩＰ電話の契約キャリアごとの着信網となるＩＭＳ網３０又はＩＰ電話網４０に送信する。続いて、電話番号調査サーバ１０は、着信網から第１の応答メッセージを受信すると、ＩＰｖ６拒否エラーか否かを判断し、ＩＰｖ６を拒否する応答メッセージの場合には第１のＳＤＰパラメータとは異なる第２のＳＤＰパラメータを付与して送信し、着信網から第２の応答メッセージを受信する。そして、受信した第１の応答メッセージ又は第２の応答メッセージに応じて、ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定し、電話番号調査情報提供要求があったユーザ端末９０へＩＰ網８０経由で送信する。このため、電話番号調査サーバ１０は、図３に示した網インタフェース部１１に、ユーザ端末９０から電話端末の電話番号調査情報提供要求を受信したときに、電話番号調査判定部１３で判定された電話端末の電話番号使用状況について、電話番号調査情報提供要求があったユーザ端末９０へＩＰ網８０経由で送信する機能が付加される。

このとき、電話番号調査サーバ１０は、ユーザ端末９０から調査対象番号に基づく電話番号調査情報提供要求をＩＰ網８０経由で受信すると、判定の結果のそれぞれに判定日時を示すタイムスタンプを付与して時系列に記録された電話番号調査情報が記録された記録媒体（電話番号履歴ＤＢ（１５））を参照し、電話番号調査情報提供要求があったユーザ端末９０へＩＰ網８０経由で送信する。

なお、電話番号調査情報記録媒体（電話番号履歴ＤＢ（１５））は、必要なユーザに単独で頒布されてもよい。記録媒体（電話番号履歴ＤＢ（１５））は、通信事業者網に専用線経由で接続される電話番号調査装置１０により生成される、調査対象番号の実在の有無が記録される記録媒体であり、頒布先のシステムで検索用に使用される。

電話番号調査情報記録媒体（電話番号履歴ＤＢ（１５））は、着信側の電話端末の電話番号使用状況について有効性を判定した結果の集合体であり、例えば、図１０に一例を示すデータ構造からなり、判定結果のそれぞれに判定日時を示すタイムスタンプを付与して時系列に記録したものである。なお、記録媒体の頒布は、ＤＶＤやハードディスクに記録したデータベースに限らず、通信回線を利用した頒布も含まれる。

本実施形態に係る電話番号調査情報提供システム１００によれば、電話番号調査装置１０で判定した、電話番号が使用されている状態（有効（実在））、使用されていない状態（無効（欠番））、移転先電話番号を案内している状態（移転）の別を、必要なユーザに提供することができる。同様に、電話番号調査情報記録媒体（電話番号履歴ＤＢ（１５））を必要とするユーザへ配布することにより、ユーザサイドで活用でき、例えば、与信等において顕著な効果を得ることができる。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。またその様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

以下に、この分割出願の基礎となる出願の願書に最初に添付した特許請求の範囲に記載した発明を付記する。付記に記載した請求項の項番は、この分割出願の基礎となる出願の願書に最初に添付した特許請求の範囲のとおりである。
＜請求項１＞
ＩＭＳ網又はＩＰ電話網に接続され、０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話が、ＮＧＮ網を介して接続される電話番号調査装置であって、
調査対象の前記ＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、前記ＩＮＶＩＴＥ要求に第１のＳＤＰパラメータを付与し、前記ＮＧＮ網で選択される契約キャリアごとの着信網となる前記ＩＭＳ網又は前記ＩＰ電話網に送信し、前記着信網から第１の応答メッセージを受信すると、前記第１の応答メッセージがＩＰｖ６を拒否するメッセージであれば、前記第１のＳＤＰパラメータとは異なる第２のＳＤＰパラメータを付与して送信して前記着信網から第２の応答メッセージを受信するメッセージ交換制御部と、
前記メッセージ交換制御部が受信した前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、
を備えたことを特徴とする電話番号調査装置。
＜請求項２＞
前記第１のＳＤＰパラメータは、前記ＩＭＳ網に準拠したパラメータであり、前記第２のＳＤＰパラメータは、前記ＩＰ電話網に準拠したパラメータであることを特徴とする請求項１に記載の電話番号調査装置。
＜請求項３＞
前記第１のＳＤＰパラメータは、ネットワークプロトコル、メディア種別、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなる、前記ＩＰ電話が着信を拒否するパラメータであり、前記第２のＳＤＰパラメータは、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなる、前記ＩＰ電話が着信を拒否するパラメータであることを特徴とする請求項１又は２に記載の電話番号調査装置。
＜請求項４＞
前記電話番号調査判定部は、
前記第１の応答メッセージが、着信網からアンサーとしてＩＰｖ６拒否エラー以外のメッセージであるか、ＩＰｖ６を拒否するメッセージであるかにより、前記ＩＰ電話の前記着信網の判定を行うことを特徴とする請求項１に記載の電話番号調査装置。
＜請求項５＞
前記電話番号調査判定部は、
前記第１の応答メッセージが着信網からアンサーとしてＩＰｖ６拒否エラー以外のメッセージであれば、前記第１の応答メッセージに応じて前記ＩＰ電話の電話番号使用状況について判定し、前記第１の応答メッセージがＩＰｖ６を拒否するメッセージであれば、第２のＳＤＰパラメータを付与して送信後に前記着信網から受信する前記第２の応答メッセージに応じて前記ＩＰ電話の電話番号使用状況について判定することを特徴とする請求項１又は４に記載の電話番号調査装置。
＜請求項６＞
前記電話番号調査判定部は、
前記第１の応答メッセージに含まれる第１のエラーコードを受信した場合に、前記ＩＰ電話の電話番号が実在すると判定し、第２又は第３のエラーコードを受信した場合に、前記ＩＰ電話の電話番号が欠番であるとの判定を行うことを特徴とする請求項１、４、５のいずれか１項に記載の電話番号調査装置。
＜請求項７＞
前記電話番号調査判定部は、
前記第２の応答メッセージに含まれる第１のエラーコードを受信した場合に、前記ＩＰ電話の電話番号が実在すると判定し、第３のエラーコードを受信した場合に、前記ＩＰ電話が欠番であると判定することを特徴とする請求項１、４、５のいずれか１項に記載の電話番号調査装置。
＜請求項８＞
ＩＭＳ網又はＩＰ電話網に接続され、０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話が、ＮＧＮ網を介して接続される電話番号調査装置を用い、調査対象となる前記ＩＰ電話の電話番号の使用状況を調査する電話番号調査方法であって、
前記電話番号調査装置が、
調査対象の前記ＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、前記ＩＮＶＩＴＥ要求に第１のＳＤＰパラメータを付与し、前記ＮＧＮ網で選択される契約キャリアごとの着信網となる前記ＩＭＳ網又は前記ＩＰ電話網に送信するステップと、
前記着信網から第１の応答メッセージを受信すると、前記第１の応答メッセージがＩＰｖ６を拒否するメッセージであれば、前記第１のＳＤＰパラメータとは異なる第２のＳＤＰパラメータを付与して送信して前記着信網から第２の応答メッセージを受信するステップと、
受信した前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定するステップと、
を有することを特徴とする電話番号調査方法。
＜請求項９＞
ＩＭＳ網又はＩＰ電話網に接続され、０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話が、ＮＧＮ網を介して接続される電話番号調査装置のプログラムであって、
コンピュータに、
調査対象の前記ＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、前記ＩＮＶＩＴＥ要求に第１のＳＤＰパラメータを付与し、前記ＮＧＮ網で選択される契約キャリアごとの着信網となる前記ＩＭＳ網又は前記ＩＰ電話網に送信する手順と、
前記着信網から第１の応答メッセージを受信すると、前記第１の応答メッセージがＩＰｖ６を拒否するメッセージであれば、前記第１のＳＤＰパラメータとは異なる第２のＳＤＰパラメータを付与して送信して前記着信網から第２の応答メッセージを受信する手順と、
受信した前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する手順と、
を実行させるプログラム。
＜請求項１０＞
ユーザ端末と、
前記ユーザ端末とはＩＰ網経由で接続されるとともに、ＩＭＳ網又はＩＰ電話網に接続され、０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話がＮＧＮ網を介して接続される電話番号調査装置とからなる電話番号調査情報提供システムであって、
前記電話番号調査装置は、
調査対象の前記ＩＰ電話に対してＩＮＶＩＴＥ要求を送信するときに、前記ＩＮＶＩＴＥ要求に第１のＳＤＰパラメータを付与し、前記ＮＧＮ網で選択される契約キャリアごとの着信網となる前記ＩＭＳ網又は前記ＩＰ電話網に送信し、前記着信網から第１の応答メッセージを受信すると、前記第１の応答メッセージがＩＰｖ６を拒否するメッセージであれば、前記第１のＳＤＰパラメータとは異なる第２のＳＤＰパラメータを付与して送信して前記着信網から第２の応答メッセージを受信するメッセージ交換制御部と、
前記メッセージ交換制御部が受信した前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、
前記ユーザ端末から前記ＩＰ電話の電話番号調査情報提供要求を受信すると、前記電話番号調査判定部で判定された前記ＩＰ電話の電話番号使用状況について、前記電話番号調査情報提供要求があったユーザ端末へ前記ＩＰ網経由で送信する網インタフェース部と、
を有することを特徴とする電話番号調査情報提供システム。

１０…電話番号調査装置（サーバ）、１１…網インタフェース部、１２…メッセージ交換制御部、１３…電話番号調査判定部、１４…電話番号履歴生成部、１５…電話番号履歴ＤＢ（電話番号調査情報記録媒体）、２０…ＮＧＮ網、２０ａ…ＳＩＰサーバ、３０…ＩＭＳ（ＮＧＮ）網、３０ａ，３０ｂ，３０ｃ…ＳＩＰサーバ、４０…ＩＰ電話網、５０ａ…ＩＭＳ端末（移動体電話）、５０ｂ…ＩＭＳ端末（ＩＰ電話）、６０…ＩＰ電話端末（ＩＰ電話）、８０…ＩＰ網、９０…ユーザ端末、１００…電話番号調査情報提供システム

Claims (13)

1. 少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置であって、
   前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信し、受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信して前記着信網から第２の応答メッセージを受信するメッセージ交換制御部と、
   前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、を備え、
   前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいることを特徴とする電話番号調査装置。
2. 前記第１のＳＤＰパラメータは、前記ＩＭＳ網に準拠したパラメータであり、
   前記第２のＳＤＰパラメータは、前記ＩＰ電話網に準拠したパラメータであることを特徴とする請求項１に記載の電話番号調査装置。
3. 前記第１のＳＤＰパラメータは、前記ＩＭＳ網に接続された前記ＩＰ電話が着信を拒否するパラメータでもあり、
   前記第１のＳＤＰパラメータは、前記ネットワークプロトコル、メディア種別、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなるパラメータの記述で前記ＩＰ電話が着信を拒否するパラメータとされていることを特徴とする請求項１又は請求項２に記載の電話番号調査装置。
4. 前記第１のＳＤＰパラメータが、音声、映像、及び、アプリケーションを含む全メディアを含んだメディア種別を含んでいることを特徴とする請求項３に記載の電話番号調査装置。
5. 前記第２のＳＤＰパラメータは、前記ＩＰ電話網に接続された前記ＩＰ電話が着信を拒否するパラメータであり、
   前記第２のＳＤＰパラメータは、トランスポートプロトコル、コーデックのうちの少なくとも一つ、又はその組み合わせからなるパラメータの記述で前記ＩＰ電話が着信を拒否するパラメータとされていることを特徴とする請求項１から請求項４のいずれか１項に記載の電話番号調査装置。
6. 前記第２のＳＤＰパラメータは、トランスポートプロトコルとコーデックの２つのパラメータの記述で前記ＩＰ電話が着信を拒否するパラメータとされていることを特徴とする請求項５に記載の電話番号調査装置。
7. 前記電話番号調査判定部は、
   前記第１の応答メッセージが、前記着信網自身の拒否である場合には、前記着信網が前記ＩＰ電話網であると判定し、
   前記第１の応答メッセージが、前記着信網自身の拒否でない場合には、前記着信網が前記ＩＭＳ網であると判定することを特徴とする請求項１から請求項６のいずれか１項に記載の電話番号調査装置。
8. 前記電話番号調査判定部は、前記第１の応答メッセージが前記着信網自身の拒否でない場合に、前記第１の応答メッセージに応じた前記ＩＰ電話の電話番号使用状況についての判定を行うことを特徴とする請求項１から請求項７のいずれか１項に記載の電話番号調査装置。
9. 前記電話番号調査判定部は、前記第１の応答メッセージに含まれる第１のエラーコードを受信した場合、前記ＩＰ電話の電話番号が実在すると判定し、
   前記電話番号調査判定部は、前記第１の応答メッセージに含まれる第２又は第３のエラーコードを受信した場合、前記ＩＰ電話の電話番号が欠番であると判定することを特徴とする請求項１から請求項８のいずれか１項に記載の電話番号調査装置。
10. 前記電話番号調査判定部は、前記第２の応答メッセージに含まれる第１のエラーコードを受信した場合、前記ＩＰ電話の電話番号が実在すると判定し、
    前記電話番号調査判定部は、前記第２の応答メッセージに含まれる第３のエラーコードを受信した場合、前記ＩＰ電話が欠番であると判定することを特徴とする請求項１から請求項９のいずれか１項に記載の電話番号調査装置。
11. 少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置を用いて、調査対象となる前記ＩＰ電話の電話番号の使用状況を調査する電話番号調査方法であって、
    前記電話番号調査装置が、
    前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信するステップと、
    受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信して前記着信網から第２の応答メッセージを受信するステップと、
    前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定するステップと、を含み、
    前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいることを特徴とする電話番号調査方法。
12. 少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置のプログラムであって、
    電話番号調査装置に、
    前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信させる処理と、
    受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信させて前記着信網から第２の応答メッセージを受信させる処理と、
    前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定させる処理と、を少なくとも実行させ、
    前記ＩＮＶＩＴＥ要求を送信させる処理を前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいるものとして実行させることを特徴とするプログラム。
13. 電話番号調査情報提供システムであって、
    電話番号調査情報提供システムは、
    ユーザ端末と、
    ＩＰ網経由で前記ユーザ端末に接続されるとともに、少なくとも着信網であるＩＭＳ網又はＩＰ電話網に接続された０ＡＢ−Ｊ型番号が割り当てられた複数のＩＰ電話にＮＧＮ網を介して接続される電話番号調査装置と、を含み、
    前記電話番号調査装置は、
    前記ＩＰ電話網が拒否する第１のＳＤＰパラメータを調査対象の前記ＩＰ電話に対するＩＮＶＩＴＥ要求に付与して前記ＮＧＮ網の選択する前記着信網に前記ＩＮＶＩＴＥ要求を送信し、受信した前記着信網からの第１の応答メッセージが前記着信網自身の拒否である場合、再度、前記着信網に前記ＩＰ電話網が拒否しない第２のＳＤＰパラメータを付与した前記ＩＮＶＩＴＥ要求を送信して前記着信網から第２の応答メッセージを受信するメッセージ交換制御部と、
    前記第１の応答メッセージ又は前記第２の応答メッセージに応じて、前記ＩＰ電話の電話番号使用状況について着信ベルを鳴動させる信号を用いないで判定する電話番号調査判定部と、
    前記ユーザ端末から前記ＩＰ電話の電話番号調査情報提供要求を受信すると、前記電話番号調査情報提供要求があった前記ユーザ端末に前記電話番号調査判定部が判定した前記ＩＰ電話の電話番号使用状況を前記ＩＰ網経由で送信する網インタフェース部と、を備え、
    前記第１のＳＤＰパラメータが、少なくともＩＰｖ６としたネットワークプロトコルを含んでいることを特徴とする電話番号調査情報提供システム。