知財求人 - 知財ポータルサイト「IP Force」
特許7414215電話番号の調査装置、調査方法、調査プログラム、及び情報提供システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-01-05
(45)【発行日】2024-01-16
(54)【発明の名称】電話番号の調査装置、調査方法、調査プログラム、及び情報提供システム
(51)【国際特許分類】
H04M 3/42 20060101AFI20240109BHJP
【ＦＩ】
H04M3/42 Z
【請求項の数】
16
(21)【出願番号】P 2023194823
(22)【出願日】2023-11-16
【審査請求日】2023-11-22
【早期審査対象出願】
(73)【特許権者】
【識別番号】501032951
【氏名又は名称】株式会社クローバー・ネットワーク・コム
(74)【代理人】
【識別番号】110002871
【氏名又は名称】弁理士法人坂本国際特許商標事務所
(72)【発明者】
【氏名】川上 泰則
(72)【発明者】
【氏名】大石 光
【審査官】石井 則之
(56)【参考文献】
【文献】特開２０１７－２１２７３０（ＪＰ，Ａ）
【文献】特開２０１７－２１２７１５（ＪＰ，Ａ）
【文献】特開２０１５－０２６９３０（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｍ３／００
３／１６－３／２０
３／３８－３／５８
７／００－７／１６
１１／００－１１／１０
(57)【特許請求の範囲】
【請求項1】
発側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、着側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、のうちの少なくとも一方に前記発側固定ＩＭＳ網を介して接続される電話番号の調査装置であり、調査対象の前記メタルＩＰ電話端末に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して前記発側固定ＩＭＳ網に前記ＩＮＶＩＴＥリクエストを送信するとともに少なくとも前記発側固定ＩＭＳ網を介して応答メッセージを受信するメッセージ交換制御部と、
前記応答メッセージに応じて前記調査対象の前記メタルＩＰ電話端末の電話番号の使用状況を判定する電話番号調査判定部と、を備え、
前記ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、
ことを特徴とする電話番号の調査装置。
【請求項2】
前記電話番号調査判定部が、前記応答メッセージが、コード１８０ Ｒｉｎｇｉｎｇ、コード２００ ＯＫ、又はコード４８６ Ｂｕｓｙ Ｈｅｒｅである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記応答メッセージが、コード４０４ Ｎｏｔ Ｆｏｕｎｄである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号は欠番であると判定し、
前記応答メッセージが、コード４１０ Ｇｏｎｅである場合に前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定する、
ことを特徴とする請求項１に記載の電話番号の調査装置。
【請求項3】
前記応答メッセージがコード１８０ Ｒｉｎｇｉｎｇである場合に、前記電話番号調査判定部が、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記メッセージ交換制御部が、前記発側固定ＩＭＳ網にＣＡＮＣＥＬリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の呼出しベルの鳴動を停止させる、
ことを特徴とする請求項１に記載の電話番号の調査装置。
【請求項4】
前記応答メッセージがコード２００ ＯＫである場合に、前記電話番号調査判定部が、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記メッセージ交換制御部が、前記発側固定ＩＭＳ網にＢＹＥリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の通信を切断する、
ことを特徴とする請求項１に記載の電話番号の調査装置。
【請求項5】
音声変換部をさらに備え、前記応答メッセージがコード４１０ Ｇｏｎｅである場合に、
前記電話番号調査判定部が、前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定し、
前記音声変換部が、移転ガイダンスとして送信される音声データをテキストデータへと変換して前記調査対象の前記メタルＩＰ電話端末の移転先の電話番号情報を取得する、
ことを特徴とする請求項１に記載の電話番号の調査装置。
【請求項6】
発側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、着側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、のうちの少なくとも一方に前記発側固定ＩＭＳ網を介して接続される装置を用いて、調査対象となる前記メタルＩＰ電話端末の電話番号の使用状況を調査する電話番号の調査方法であり、前記装置が、
調査対象の前記メタルＩＰ電話端末に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して前記発側固定ＩＭＳ網に前記ＩＮＶＩＴＥリクエストを送信するステップと、
少なくとも前記発側固定ＩＭＳ網を介して応答メッセージを受信するステップと、
前記応答メッセージに応じて前記調査対象の前記メタルＩＰ電話端末の電話番号の使用状況を判定するステップと、を含み、
前記ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、
ことを特徴とする電話番号の調査方法。
【請求項7】
前記応答メッセージが、コード１８０ Ｒｉｎｇｉｎｇ、コード２００ ＯＫ、又はコード４８６ Ｂｕｓｙ Ｈｅｒｅである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記応答メッセージが、コード４０４ Ｎｏｔ Ｆｏｕｎｄである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号は欠番であると判定し、
前記応答メッセージが、コード４１０ Ｇｏｎｅである場合に前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定する、
ことを特徴とする請求項６に記載の電話番号の調査方法。
【請求項8】
前記応答メッセージがコード１８０ Ｒｉｎｇｉｎｇである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記発側固定ＩＭＳ網にＣＡＮＣＥＬリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の呼出しベルの鳴動を停止させる、
ことを特徴とする請求項６に記載の電話番号の調査方法。
【請求項9】
前記応答メッセージがコード２００ ＯＫである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記発側固定ＩＭＳ網にＢＹＥリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の通信を切断する、
ことを特徴とする請求項６に記載の電話番号の調査方法。
【請求項10】
前記応答メッセージがコード４１０ Ｇｏｎｅである場合に、前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定し、
移転ガイダンスとして送信される音声データをテキストデータへと変換して前記調査対象の前記メタルＩＰ電話端末の移転先の電話番号情報を取得する、
ことを特徴とする請求項６に記載の電話番号の調査方法。
【請求項11】
発側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、着側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、のうちの少なくとも一方に前記発側固定ＩＭＳ網を介して接続されるコンピュータに、調査対象の前記メタルＩＰ電話端末に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して前記発側固定ＩＭＳ網に前記ＩＮＶＩＴＥリクエストを送信させる処理と、
少なくとも前記発側固定ＩＭＳ網を介して応答メッセージを受信させる処理と、
前記応答メッセージに応じて前記調査対象の前記メタルＩＰ電話端末の電話番号の使用状況を判定させる処理と、を少なくとも実行させ、
前記ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、
ことを特徴とする電話番号の調査プログラム。
【請求項12】
前記応答メッセージが、コード１８０ Ｒｉｎｇｉｎｇ、コード２００ ＯＫ、又はコード４８６ Ｂｕｓｙ Ｈｅｒｅである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記応答メッセージが、コード４０４ Ｎｏｔ Ｆｏｕｎｄである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号は欠番であると判定し、
前記応答メッセージが、コード４１０ Ｇｏｎｅである場合に前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定する、
ことを特徴とする請求項１１に記載の電話番号の調査プログラム。
【請求項13】
前記応答メッセージがコード１８０ Ｒｉｎｇｉｎｇである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記発側固定ＩＭＳ網にＣＡＮＣＥＬリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の呼出しベルの鳴動を停止させる、
ことを特徴とする請求項１１に記載の電話番号の調査プログラム。
【請求項14】
前記応答メッセージがコード２００ ＯＫである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、
前記発側固定ＩＭＳ網にＢＹＥリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の通信を切断する、
ことを特徴とする請求項１１に記載の電話番号の調査プログラム。
【請求項15】
前記応答メッセージがコード４１０ Ｇｏｎｅである場合に、前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定し、
移転ガイダンスとして送信される音声データをテキストデータへと変換して前記調査対象の前記メタルＩＰ電話端末の移転先の電話番号情報を取得する、
ことを特徴とする請求項１１に記載の電話番号の調査プログラム。
【請求項16】
請求項１から５のうちのいずれか１項に記載の電話番号の調査装置と、ユーザ端末と、を有し、
前記電話番号の調査装置が、前記ユーザ端末から前記メタルＩＰ電話端末についての電話番号調査情報提供要求を受信すると、前記電話番号調査情報提供要求があった前記ユーザ端末に前記電話番号調査判定部が判定した前記メタルＩＰ電話端末の電話番号の使用状況をＩＰ網経由で送信する網インタフェース部を備える、
ことを特徴とする電話番号の情報提供システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電話番号を調査する技術に関する。
【背景技術】
【0002】
電話番号情報の判定に関する従来の技術として、複数の端末とインターネット網を介して接続されるコンピュータサーバを用いた電話番号情報の判定装置であって、複数の電話番号の使用履歴情報を記憶するデータベースと、端末から認証情報を受信し認証手段がログインを許可することを条件として、端末から検索情報として電話番号を受付ける検索情報受付手段と、検索情報受付手段が受付けた電話番号を用いてデータベースを検索し、電話番号履歴情報の中に加入状態から欠番状態へ遷移する複数の履歴が存在するか電話番号のフィールドの欠番変化を解析し、および／または、電話番号履歴情報の中に欠番状態から加入状態へ遷移する複数の履歴が存在するか電話番号のフィールドの有効変化を解析し、電話番号履歴情報の未蓄積履歴、電話番号履歴情報の直近調査記録が欠番履歴、直近調査記録より一つ前の調査記録が欠番履歴、電話番号履歴情報の中に存在する複数の通話停止履歴、を参照して、検索情報の電話番号に対して所定の加入者番号と判定する履歴判定情報を生成し、この履歴判定情報を端末へインターネット網を介して表示させるシステム制御手段と、を備える電話番号情報の判定装置が知られている（特許文献１参照）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１４－０６０７９６号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、ＰＳＴＮ（Ｐublic Ｓwitched Ｔelephone Ｎetworks：公衆交換電話網）からＮＧＮ（Ｎext Ｇeneration Ｎetwork）への移行に伴い、事業者間相互接続インタフェースも共通線信号方式のＳＳ７（Ｓignaling Ｓystem No.７）からＩＰ（Ｉnternet Ｐrotocol）方式のＳＩＰ（Ｓession Ｉnitiation Ｐrotocol）に変更される。このため、発信端末（例えば、電話番号の調査装置）からＳＩＰの特定メッセージがＩＭＳ（ＩＰ Ｍultimedia Ｓubsystem）網、ＮＧＮ網、及びＩＰ電話網（ＶｏＩＰ：Ｖoice ｏver Ｉnternet Ｐrotocol）に対して到達することになる。
【0005】
なお、ＩＭＳとは、これまで固定網や移動体通信などで行われていたサービスをＩＰ化し、融合したマルチメディアサービスなどを実現するための規格であり、その規格に沿って作られたシステムとして移動体通信システムやＮＧＮがある。
【0006】
このため、事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用し、着側ＩＭＳ網における電話番号の使用状況を判定する、発側ＩＭＳ網とＵＮＩ（Ｕser Ｎetwork Ｉnterface：ユーザ網インタフェース）接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入して新システム基盤への円滑な移行を図る必要がある。
【0007】
そこで本発明は、１つの側面では、事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用してＩＭＳ網における電話番号の使用状況を判定することが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【0008】
上記課題を解決するため、本発明に係る電話番号の調査装置は、発側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、着側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、のうちの少なくとも一方に前記発側固定ＩＭＳ網を介して接続される電話番号の調査装置であり、調査対象の前記メタルＩＰ電話端末に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して前記発側固定ＩＭＳ網に前記ＩＮＶＩＴＥリクエストを送信するとともに少なくとも前記発側固定ＩＭＳ網を介して応答メッセージを受信するメッセージ交換制御部と、前記応答メッセージに応じて前記調査対象の前記メタルＩＰ電話端末の電話番号の使用状況を判定する電話番号調査判定部と、を備え、前記ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、ようにしてもよい。
【0009】
本発明に係る電話番号の調査装置は、前記電話番号調査判定部が、前記応答メッセージが、コード１８０ Ｒｉｎｇｉｎｇ、コード２００ ＯＫ、又はコード４８６ Ｂｕｓｙ Ｈｅｒｅである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記応答メッセージが、コード４０４ Ｎｏｔ Ｆｏｕｎｄである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号は欠番であると判定し、前記応答メッセージが、コード４１０ Ｇｏｎｅである場合に前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定する、ようにしてもよい。
【0010】
本発明に係る電話番号の調査装置は、前記応答メッセージがコード１８０ Ｒｉｎｇｉｎｇである場合に、前記電話番号調査判定部が、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記メッセージ交換制御部が、前記発側固定ＩＭＳ網にＣＡＮＣＥＬリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の呼出しベルの鳴動を停止させる、ようにしてもよい。
【0011】
本発明に係る電話番号の調査装置は、前記応答メッセージがコード２００ ＯＫである場合に、前記電話番号調査判定部が、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記メッセージ交換制御部が、前記発側固定ＩＭＳ網にＢＹＥリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の通信を切断する、ようにしてもよい。
【0012】
本発明に係る電話番号の調査装置は、音声変換部をさらに備え、前記応答メッセージがコード４１０ Ｇｏｎｅである場合に、前記電話番号調査判定部が、前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定し、前記音声変換部が、移転ガイダンスとして送信される音声データをテキストデータへと変換して前記調査対象の前記メタルＩＰ電話端末の移転先の電話番号情報を取得する、ようにしてもよい。
【0013】
また、本発明に係る電話番号の調査方法は、発側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、着側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、のうちの少なくとも一方に前記発側固定ＩＭＳ網を介して接続される装置を用いて、調査対象となる前記メタルＩＰ電話端末の電話番号の使用状況を調査する電話番号の調査方法であり、前記装置が、調査対象の前記メタルＩＰ電話端末に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して前記発側固定ＩＭＳ網に前記ＩＮＶＩＴＥリクエストを送信するステップと、少なくとも前記発側固定ＩＭＳ網を介して応答メッセージを受信するステップと、前記応答メッセージに応じて前記調査対象の前記メタルＩＰ電話端末の電話番号の使用状況を判定するステップと、を含み、前記ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、ようにしてもよい。
【0014】
本発明に係る電話番号の調査方法は、前記応答メッセージが、コード１８０ Ｒｉｎｇｉｎｇ、コード２００ ＯＫ、又はコード４８６ Ｂｕｓｙ Ｈｅｒｅである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記応答メッセージが、コード４０４ Ｎｏｔ Ｆｏｕｎｄである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号は欠番であると判定し、前記応答メッセージが、コード４１０ Ｇｏｎｅである場合に前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定する、ようにしてもよい。
【0015】
本発明に係る電話番号の調査方法は、前記応答メッセージがコード１８０ Ｒｉｎｇｉｎｇである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記発側固定ＩＭＳ網にＣＡＮＣＥＬリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の呼出しベルの鳴動を停止させる、ようにしてもよい。
【0016】
本発明に係る電話番号の調査方法は、前記応答メッセージがコード２００ ＯＫである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記発側固定ＩＭＳ網にＢＹＥリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の通信を切断する、ようにしてもよい。
【0017】
本発明に係る電話番号の調査方法は、前記応答メッセージがコード４１０ Ｇｏｎｅである場合に、前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定し、移転ガイダンスとして送信される音声データをテキストデータへと変換して前記調査対象の前記メタルＩＰ電話端末の移転先の電話番号情報を取得する、ようにしてもよい。
【0018】
また、本発明に係る電話番号の調査プログラムは、発側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、着側固定ＩＭＳ網に接続されている複数のメタルＩＰ電話端末と、のうちの少なくとも一方に前記発側固定ＩＭＳ網を介して接続されるコンピュータに、調査対象の前記メタルＩＰ電話端末に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して前記発側固定ＩＭＳ網に前記ＩＮＶＩＴＥリクエストを送信させる処理と、少なくとも前記発側固定ＩＭＳ網を介して応答メッセージを受信させる処理と、前記応答メッセージに応じて前記調査対象の前記メタルＩＰ電話端末の電話番号の使用状況を判定させる処理と、を少なくとも実行させ、前記ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、ようにしてもよい。
【0019】
本発明に係る電話番号の調査プログラムは、前記応答メッセージが、コード１８０ Ｒｉｎｇｉｎｇ、コード２００ ＯＫ、又はコード４８６ Ｂｕｓｙ Ｈｅｒｅである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記応答メッセージが、コード４０４ Ｎｏｔ Ｆｏｕｎｄである場合に前記調査対象の前記メタルＩＰ電話端末の電話番号は欠番であると判定し、前記応答メッセージが、コード４１０ Ｇｏｎｅである場合に前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定する、ようにしてもよい。
【0020】
本発明に係る電話番号の調査プログラムは、前記応答メッセージがコード１８０ Ｒｉｎｇｉｎｇである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記発側固定ＩＭＳ網にＣＡＮＣＥＬリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の呼出しベルの鳴動を停止させる、ようにしてもよい。
【0021】
本発明に係る電話番号の調査プログラムは、前記応答メッセージがコード２００ ＯＫである場合に、前記調査対象の前記メタルＩＰ電話端末の電話番号が実在すると判定し、前記発側固定ＩＭＳ網にＢＹＥリクエストを送信することにより、前記調査対象の前記メタルＩＰ電話端末の通信を切断する、ようにしてもよい。
【0022】
本発明に係る電話番号の調査プログラムは、前記応答メッセージがコード４１０ Ｇｏｎｅである場合に、前記調査対象の前記メタルＩＰ電話端末は移転して電話番号は欠番であると判定し、移転ガイダンスとして送信される音声データをテキストデータへと変換して前記調査対象の前記メタルＩＰ電話端末の移転先の電話番号情報を取得する、ようにしてもよい。
【0023】
また、本発明に係る電話番号の情報提供システムは、上記のうちのいずれかの電話番号の調査装置と、ユーザ端末と、を有し、前記電話番号の調査装置が、前記ユーザ端末から前記メタルＩＰ電話端末についての電話番号調査情報提供要求を受信すると、前記電話番号調査情報提供要求があった前記ユーザ端末に前記電話番号調査判定部が判定した前記メタルＩＰ電話端末の電話番号の使用状況をＩＰ網経由で送信する網インタフェース部を備える、ようにしてもよい。
【発明の効果】
【0024】
本発明によれば、１つの側面では、事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用してＩＭＳ網における電話番号の使用状況を判定することが可能となる。
【図面の簡単な説明】
【0025】
【図1】本発明の実施の形態に係る電話番号の調査装置の網接続形態を示す概略図である。
【図2】発信側の機器と発側固定ＩＭＳ網とメタル収容装置との間における、着信側の機器としてメタルＩＰ電話端末が実在し且つ話中でない場合の動作の基本シーケンスのパターン１を説明する図である。
【図3】発信側の機器と発側固定ＩＭＳ網とメタル収容装置との間における、着信側の機器としてメタルＩＰ電話端末が実在し且つ話中でない場合の動作の基本シーケンスのパターン２を説明する図である。
【図4】発信側の機器と発側固定ＩＭＳ網とメタル収容装置との間における、着信側の機器としてメタルＩＰ電話端末が実在し且つ話中である場合の動作の基本シーケンスを説明する図である。
【図5】発信側の機器と発側固定ＩＭＳ網とメタル収容装置との間における、着信側の機器が欠番である場合の動作の基本シーケンスを説明する図である。
【図6】発信側の機器と発側固定ＩＭＳ網とメタル収容装置との間における、着信側の機器としてのメタルＩＰ電話端末が移転している場合の動作の基本シーケンスを説明する図である。
【図8】調査対象のメタルＩＰ電話端末が実在し且つ話中でない場合の動作シーケンスのその１を説明する図である。
【図9】調査対象のメタルＩＰ電話端末が実在し且つ話中でない場合の動作シーケンスのその２を説明する図である。
【図10】調査対象のメタルＩＰ電話端末が実在し且つ話中である場合の動作シーケンスを説明する図である。
【図11】調査対象のメタルＩＰ電話端末が欠番である場合の動作シーケンスを説明する図である。
【図12】調査対象のメタルＩＰ電話端末が欠番である場合の動作シーケンスを説明する図である（ＩＰｖ４、Ｇ．７１１ μ－ｌａｗのみ）。
【図13】調査対象のメタルＩＰ電話端末が移転している場合の動作シーケンスを説明する図である。
【図14】メタルＩＰ電話端末の電話番号の使用状況を調査する仕法の整理を示す図である。
【図15】本発明の実施の形態に係る電話番号の情報提供システムのシステム構成図である。
【発明を実施するための形態】
【0026】
以下、本発明の実施の形態について添付図面を参照しながら説明する。
【0027】
（網接続形態）
図１は、本発明に係る電話番号の調査装置の具体的な構成態様の一例としての、実施の形態に係る電話番号の調査装置１０の網接続形態を示す概略図である。電話番号の調査装置１０は、ホームゲートウェイ（ＨＧＷ：Ｈome ＧateＷay）１９を介して発側固定ＩＭＳ網２０に接続されている。
図１は、本発明に係る電話番号の調査装置の具体的な構成態様の一例としての、実施の形態に係る電話番号の調査装置１０の網接続形態を示す概略図である。電話番号の調査装置１０は、ホームゲートウェイ（ＨＧＷ：Ｈome ＧateＷay）１９を介して発側固定ＩＭＳ網２０に接続されている。
【0028】
実施の形態に係る電話番号の調査装置１０には、調査対象のメタルＩＰ電話端末６０ａが発側固定ＩＭＳ網２０（具体的には例えば、ＮＧＮ網）を介して接続され、また、着側固定ＩＭＳ網３０（具体的には例えば、ＮＧＮ網、ＩＰ電話網（ＶｏＩＰ：Ｖoice ｏver Ｉnternet Ｐrotocol））に接続されている調査対象のメタルＩＰ電話端末６０ｂが発側固定ＩＭＳ網２０（具体的には例えば、ＮＧＮ網）を介して接続されている。
【0029】
メタルＩＰ電話端末６０ａ，６０ｂは、固定電話のコアネットワークをＰＳＴＮからＩＰ網へと移行した後も既存のメタルケーブルを継続利用して、既存のメタルケーブルに接続されている固定電話の受け皿として提供される電話端末のことである。なお、既存のメタルケーブルとともに、加入者交換機がメタル収容装置として継続利用される。
【0030】
なお、発側固定ＩＭＳ網２０を介して電話番号の調査装置１０と接続されている調査対象のメタルＩＰ電話端末は複数であってよく、図に示す例におけるメタルＩＰ電話端末６０ａは発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末のうちの１つとして表されている。また、発側固定ＩＭＳ網２０及び着側固定ＩＭＳ網３０を介して電話番号の調査装置１０と接続されている調査対象のメタルＩＰ電話端末は複数であってよく、図に示す例におけるメタルＩＰ電話端末６０ｂは着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末のうちの１つとして表されている。また、実施の形態の説明では、網ごと（言い換えると、契約事業者ごと）のメタルＩＰ電話端末６０ａ，６０ｂ各々を相互に区別する必要がないときは、単に「メタルＩＰ電話端末６０」と表記する。
【0031】
発側固定ＩＭＳ網２０はＳＩＰサーバ２０ａを備え、当該ＳＩＰサーバ２０ａによって発側固定ＩＭＳ網２０の動作が管理、制御される。また、着側固定ＩＭＳ網３０はＳＩＰサーバ３０ａを備え、当該ＳＩＰサーバ３０ａによって着側固定ＩＭＳ網３０の動作が管理、制御される。
【0032】
発側固定ＩＭＳ網２０や着側固定ＩＭＳ網３０は、通信事業者（図１に示す例では、事業者Ａ、事業者Ｂ）ごとに構築され、各々が管理運営するＳＩＰサーバ２０ａ，３０ａを介して、各々の網ごと（言い換えると、契約事業者ごと）にメタルＩＰ電話端末６０ａ，６０ｂが接続されている。なお、図に示す例における発側固定ＩＭＳ網２０からみて、着側固定ＩＭＳ網は複数であってよく、図に示す例における着側固定ＩＭＳ網３０は複数の着側固定ＩＭＳ網のうちの１つとして表されている。
【0033】
発側固定ＩＭＳ網２０及び着側固定ＩＭＳ網３０は、ＳＤＰ（Ｓession Ｄescription Ｐrotocol）パラメータについて、ＩＰ（Ｉnternet Ｐrotocol）ｖ４のネットワークプロトコル（別言すると、インターネットプロトコル、ＩＰバージョン）に対応しているとともに、メディア種別はａｕｄｉｏ（音声）に対応し、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰに対応し、音声コーデックはＧ．７１１ μ－ｌａｗに対応している。
【0034】
０ＡＢ－Ｊ型の電話番号を持つ固定電話として、発信側の網である発側固定ＩＭＳ網２０に接続されているメタルＩＰ電話端末６０ａ及び着信側の網である着側固定ＩＭＳ網３０に接続されているメタルＩＰ電話端末６０ｂを想定する。
【0035】
図１に示す構成において、発信側である電話番号の調査装置１０が、着信側の電話端末の電話番号として発側固定ＩＭＳ網２０に接続されているメタルＩＰ電話端末６０ａの電話番号をダイヤル発信することにより、発側固定ＩＭＳ網２０のＢＧＣＦ（Ｂreakout Ｇateway Ｃontrol Ｆunction）２２、メタル収容装置４１、及び着信側のメタルＩＰ電話端末６０ａの順でルーティングが実行される。
【0036】
また、発信側である電話番号の調査装置１０が、着信側の電話端末の電話番号として着側固定ＩＭＳ網３０に接続されているメタルＩＰ電話端末６０ｂの電話番号をダイヤル発信することにより、発側固定ＩＭＳ網２０のＩＢＣＦ（Ｉnter-connection Ｂorder Ｃontrol Ｆunction）２１、着側固定ＩＭＳ網３０のＩＢＣＦ３１及びＢＧＣＦ３２、メタル収容装置５１、並びに着信側のメタルＩＰ電話端末６０ｂの順でルーティングが実行される。
【0037】
このとき、電話番号の調査装置１０と発側固定ＩＭＳ網２０との間はＵＮＩ接続が担保され、また、発側固定ＩＭＳ網２０と着側固定ＩＭＳ網３０との間の事業者間相互接続はＩＭＳ相互接続インタフェース（具体的には、発側固定ＩＭＳ網２０のＩＢＣＦ２１及び着側固定ＩＭＳ網３０のＩＢＣＦ３１）などを介してＩＭＳ相互接続が担保されて、ＳＩＰ信号方式に則り電話番号の調査装置１０から発信される特定のＳＩＰメッセージ（詳細については後述する）が着側固定ＩＭＳ網３０へと到達する。
【0038】
なお、図１に示す例における、ＩＰ－ＩＰ接続によるＩＭＳ事業者間の相互接続共通インタフェースであるII－ＮＮＩ（Ｎetwork－Ｎetwork Ｉnterface）は、ＴＴＣ標準のＪＪ－９０．３０に規定されている（ＴＴＣ：Ｔelecommunication Ｔechnology Ｃommittee；一般社団法人情報通信技術委員会）。
【0039】
すなわち、この発明の説明では、発側固定ＩＭＳ網２０は、電話番号の調査装置１０とホームゲートウェイ１９を介して接続されているＩＭＳ網であり、また、着側固定ＩＭＳ網３０は、発側固定ＩＭＳ網２０と各々のＩＢＣＦを介して接続されているＩＭＳ網である。
【0040】
また、発側固定ＩＭＳ網２０と当該発側固定ＩＭＳ網２０に接続されているメタル収容装置４１とはＩＳＵＰ（Ｉntegrated Ｓervices for digital network Ｕser Ｐart）信号方式で接続され、着側固定ＩＭＳ網３０と当該着側固定ＩＭＳ網３０に接続されているメタル収容装置５１もＩＳＵＰ信号方式で接続される。ＩＳＵＰプロトコルに関し、ＳＩＰ－ＴＴＣ ＩＳＵＰ信号方式相互接続に関する技術仕様は、ＴＴＣ標準のＪＦ－ＩＥＴＦ－ＲＦＣ３３９８に規定されている。また、ＩＳＵＰ情報のカプセル化に関する技術情報は、ＴＴＣ仕様書のＴＳ－１０２５に規定されている。
【0041】
ところで、ＳＩＰによれば、リアルタイム通信を行うためにメディア情報を含むパケットの符号化方式やパケットの宛先等のアドレスについて端末間でネゴシエーションを行う必要がある。このネゴシエーションのために必要になるのがＳＤＰ（Ｓession Ｄescription Ｐrotocol）と呼ばれる記述言語であり、ＴＴＣ標準のＲＦＣ４５６６に定義されている。
【0042】
ＳＩＰでセッションを確立するためには、まず、発信側がＳＩＰメッセージにメディア情報を記述したリクエストを送信し、着信側がその中から対応可能なメディアを選択したレスポンスを返信することで、通信に使用するメディア情報を発信側と着信側とで共有する。
【0043】
セッションを開始するためにＳＩＰメッセージにメディア情報を記述して送信することをオファーといい、それに対して対応可能なメディア情報を返信することをアンサーという。このオファー／アンサーモデルについてはＴＴＣ標準のＲＦＣ３２６４に定義されている。さらに、ＩＭＳにおけるＳＤＰメディアネゴシエーション手順については、ＴＴＣ標準のＪＪ－９０．２６に規定されている。
【0044】
図１に示す例における電話番号の調査装置１０は、発側固定ＩＭＳ網２０（尚、ＳＩＰサーバ２０ａを含む）及びメタル収容装置４１経由で、或いは、発側固定ＩＭＳ網２０（尚、ＳＩＰサーバ２０ａを含む）及び着側固定ＩＭＳ網３０（尚、ＳＩＰサーバ３０ａを含む）並びにメタル収容装置５１経由で、調査対象となるメタルＩＰ電話端末６０へと、ＩＮＶＩＴＥ（招待）メソッドのＳＤＰオファー（「ＩＮＶＩＴＥリクエスト」と称する）を送信する際、そのＳＤＰパラメータに、所定のＳＤＰパラメータ（「判定用ＳＤＰパラメータ」と称する）を付加して（別言すると、記述して）送信する。
【0045】
ＩＮＶＩＴＥリクエストを送信する際にＳＤＰパラメータに付加される判定用ＳＤＰパラメータは、ネットワークプロトコル（別言すると、インターネットプロトコル、ＩＰバージョン）、メディア種別、メディアのトランスポートプロトコル、及び音声コーデックである。
【0046】
ＩＮＶＩＴＥリクエストに対して、着信側のメタルＩＰ電話端末６０は、当該のＩＮＶＩＴＥリクエストに含まれているＳＤＰパラメータと自身が使用可能なＳＤＰパラメータとを比較し、比較の結果（即ち、ＳＤＰパラメータの一致／不一致の状況）に応じて、応答メッセージとしてＳＩＰセッションにおける所定コードのレスポンスを返信する。
【0047】
そして、電話番号の調査装置１０は、受信した所定コードのレスポンスに基づいて、着信側のメタルＩＰ電話端末６０の実在／不在（延いては、メタルＩＰ電話端末６０の電話番号の実在／欠番）などを判定する。
【0048】
（基本シーケンス）
図２乃至図６は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、着信側の機器がメタルＩＰ電話端末６０である場合の、発信側の機器と発側固定ＩＭＳ網２０と当該発側固定ＩＭＳ網２０に接続されているメタル収容装置４１との間、或いは、発信側の機器と発側固定ＩＭＳ網２０と着側固定ＩＭＳ網３０に接続されているメタル収容装置５１との間における動作の基本シーケンスを説明する図である。なお、実施の形態に係る発信側の機器とメタルＩＰ電話端末６０との間に纏わる動作の基本シーケンスは、図２乃至図６に示す内容に限らず、ＴＴＣ標準のＪＪ－９０．３０、ＴＴＣ標準のＪＪ－９０．２６、ＴＴＣ標準のＪＦ－ＩＥＴＦ－ＲＦＣ３３９８、ＴＴＣ標準のＴＲ－１０８８、ＴＴＣ標準のＪＴ－Ｑ８５０、及びＴＴＣ仕様書のＴＳ－１０２５に規定されている内容に従う。
図２乃至図６は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、着信側の機器がメタルＩＰ電話端末６０である場合の、発信側の機器と発側固定ＩＭＳ網２０と当該発側固定ＩＭＳ網２０に接続されているメタル収容装置４１との間、或いは、発信側の機器と発側固定ＩＭＳ網２０と着側固定ＩＭＳ網３０に接続されているメタル収容装置５１との間における動作の基本シーケンスを説明する図である。なお、実施の形態に係る発信側の機器とメタルＩＰ電話端末６０との間に纏わる動作の基本シーケンスは、図２乃至図６に示す内容に限らず、ＴＴＣ標準のＪＪ－９０．３０、ＴＴＣ標準のＪＪ－９０．２６、ＴＴＣ標準のＪＦ－ＩＥＴＦ－ＲＦＣ３３９８、ＴＴＣ標準のＴＲ－１０８８、ＴＴＣ標準のＪＴ－Ｑ８５０、及びＴＴＣ仕様書のＴＳ－１０２５に規定されている内容に従う。
【0049】
発信側の機器と発側固定ＩＭＳ網２０に接続されている着信側の機器（具体的には、電話端末）との間では、発側固定ＩＭＳ網２０のＢＧＣＦ２２及び発側固定ＩＭＳ網２０に接続されているメタル収容装置４１を介して通信が行われる。また、発信側の機器と着側固定ＩＭＳ３０に接続されている着信側の機器（具体的には、電話端末）との間では、発側固定ＩＭＳ網２０のＩＢＣＦ２１、着側固定ＩＭＳ網３０のＩＢＣＦ３１及びＢＧＣＦ３２、並びに着側固定ＩＭＳ網３０に接続されているメタル収容装置５１を介して通信が行われる。
【0050】
ここで、発信側の機器と発側固定ＩＭＳ網２０に接続されている着信側の機器との間の場合と、発信側の機器と着側固定ＩＭＳ網３０に接続されている着信側の機器との間の場合と、のどちらも、発側固定ＩＭＳ網２０と当該発側固定ＩＭＳ網２０に接続されているメタル収容装置４１との間における通信の内容と、発側固定ＩＭＳ網２０と着側固定ＩＭＳ網３０に接続されているメタル収容装置５１との間における通信の内容と、は同じである。このため、図２乃至図６には、発信側の機器と発側固定ＩＭＳ網２０（特に、ＳＩＰサーバ２０ａ）との間、及び、発側固定ＩＭＳ網２０（特に、ＳＩＰサーバ２０ａ）とメタル収容装置（具体的には、発側固定ＩＭＳ網２０に接続されているメタル収容装置４１と着側固定ＩＭＳ網３０に接続されているメタル収容装置５１；これら２つのメタル収容装置のことを「メタル収容装置４１／５１」と表記する）との間における通信の内容に着目して、発信側の機器と着信側の機器（具体的には、メタルＩＰ電話端末６０）との間に纏わる動作の基本シーケンスが示されている。
【0051】
（実在の場合／パターン１）
図２は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてメタルＩＰ電話端末６０が実在し且つ話中でなく、発信側の機器が通信を切断する場合の動作の基本シーケンスのパターン１を説明する図である。
図２は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてメタルＩＰ電話端末６０が実在し且つ話中でなく、発信側の機器が通信を切断する場合の動作の基本シーケンスのパターン１を説明する図である。
【0052】
図２は、特に、着信の際に発信者（即ち、相手方）の電話番号を電話端末に表示させる機能（具体的には、Ｃaller ＩＤ、Ｃalling Ｎumber Ｉdentification；例えば、ナンバーディスプレイ（登録商標））による、発信者が電話番号を非通知とする設定をしている場合には着信を拒否する設定がされていない場合の基本シーケンスを説明する図である。
【0053】
発信側の機器は、発側固定ＩＭＳ網２０を介して着信側の機器へと向けてＩＮＶＩＴＥリクエストを送信し（Ｆ１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0054】
続いて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0055】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。なお、着信側の機器によっては、ＡＣＭの返信が行われず、このため、コード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスの返信も行われない場合がある。
【0056】
さらに、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式においてインチャネル情報利用可能を示すメッセージであるＣＰＧ（Ｃall Ｐrogress Ｍessage）が返信され（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて着信音が鳴っていることを示すコード１８０ Ｒｉｎｇｉｎｇレスポンスが返信される（Ｆ７）。
【0057】
この際、着信側の機器は呼出しベルが鳴動し、メタル収容装置４１／５１から発信側の機器へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、ＲＢＴ（Ｒinging Ｂack Ｔone）が送信される。
【0058】
次に、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において着信者が通話に応答したことを示すメッセージであるＡＮＭ（Ａnswer Ｍessage）が返信され（Ｆ８）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＩＮＶＩＴＥリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ９）。
【0059】
これに対して、発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫ（Ａcknowledgment）レスポンスが返信され（Ｆ１０）、発信側の機器と着信側の機器との間でセッションが確立して通話が開始される。
【0060】
その後、（図２に示す例では発信側の機器が通信を切断すると）発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいてセッションを終了することを示すＢＹＥリクエストが送信され（Ｆ１１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ１２）。
【0061】
これに対して、（図２に示す例では）メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信され（Ｆ１３）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＢＹＥリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ１４）。これにより、発信側の機器と着信側の機器との間のセッションが終了し、すなわち、発信側の機器と着信側の機器との間の通信が切断される。
【0062】
（実在の場合／パターン２）
図３は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてメタルＩＰ電話端末６０が実在し且つ話中でなく、発信側の機器が通信を切断する場合の動作の基本シーケンスのパターン２を説明する図である。
図３は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてメタルＩＰ電話端末６０が実在し且つ話中でなく、発信側の機器が通信を切断する場合の動作の基本シーケンスのパターン２を説明する図である。
【0063】
図３は、特に、着信の際に発信者（即ち、相手方）の電話番号を電話端末に表示させる機能（具体的には、Ｃaller ＩＤ、Ｃalling Ｎumber Ｉdentification；例えば、ナンバーディスプレイ（登録商標））による、発信者が電話番号を非通知とする設定をしている場合には着信を拒否する設定がされている場合の基本シーケンスを説明する図である。
【0064】
発信側の機器は、発側固定ＩＭＳ網２０を介して着信側の機器へと向けてＩＮＶＩＴＥリクエストを送信し（Ｆ１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0065】
続いて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0066】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。
【0067】
さらに、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式においてインチャネル情報利用可能を示すメッセージであるＣＰＧ（Ｃall Ｐrogress Ｍessage）が返信され（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて着信音が鳴っていることを示すコード１８０ Ｒｉｎｇｉｎｇレスポンスが返信される（Ｆ７）。なお、着信側の機器によっては、ＣＰＧの返信が行われず、このため、コード１８０ Ｒｉｎｇｉｎｇレスポンスの返信も行われない場合がある。
【0068】
この際、（実際には、着信が拒否されているので）着信側の機器は呼出しベルが鳴動せず、メタル収容装置４１／５１から発信側の機器へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、ＲＢＴ（Ｒinging Ｂack Ｔone）が送信され、その後、発信者が電話番号を非通知とする設定をしているために着信が拒否されていることを知らせるガイダンスが送信される。
【0069】
次に、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において着信者が通話に応答したことを示すメッセージであるＡＮＭ（Ａnswer Ｍessage）が返信され（Ｆ８）（但し、実際には着信は拒否されている）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＩＮＶＩＴＥリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ９）。
【0070】
これに対して、発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスが返信される（Ｆ１０）。
【0071】
その後、（図３に示す例では発信側の機器が通信を切断すると）発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいてセッションを終了することを示すＢＹＥリクエストが送信され（Ｆ１１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ１２）。
【0072】
これに対して、（図３に示す例では）メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信され（Ｆ１３）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＢＹＥリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ１４）。これにより、発信側の機器と着信側の機器との間のセッションが終了し、すなわち、発信側の機器と着信側の機器との間の通信が切断される。
【0073】
（話中の場合）
図４は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてメタルＩＰ電話端末６０が実在し且つ話中である場合の動作の基本シーケンスを説明する図である。
図４は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてメタルＩＰ電話端末６０が実在し且つ話中である場合の動作の基本シーケンスを説明する図である。
【0074】
発信側の機器は、発側固定ＩＭＳ網２０を介して着信側の機器へと向けてＩＮＶＩＴＥリクエストを送信し（Ｆ１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0075】
続いて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0076】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。なお、次のＦ６のメッセージＲＥＬ（Ｒelease Ｍessage）を生成することによってＡＣＭの返信が行われない場合があり、このため、コード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスの返信も行われない場合がある。
【0077】
さらに、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ６）。このとき、メッセージＲＥＬの理由表示値（Ｃａｕｓｅ Ｖａｌｕｅ）が、着信者がビジー状態であることを意味するコード１７（即ち、Ｕｓｅｒ ｂｕｓｙ）とされる。
【0078】
メッセージＲＥＬ（尚、理由表示値がコード１７である）の送信（Ｆ６）を受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて発信側からリクエストされたメディアリソースが現在ビジー状態であってセッションを開始できないことを示すコード４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスが返信される（Ｆ７）。
【0079】
これに対して、発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスが返信され（Ｆ８）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信される（Ｆ９）。これにより、発信側の機器からのＩＮＶＩＴＥリクエストに係るセッションが終了する。
【0080】
（欠番の場合）
図５は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器（言い換えると、電話番号）が欠番である場合の動作の基本シーケンスを説明する図である。
図５は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器（言い換えると、電話番号）が欠番である場合の動作の基本シーケンスを説明する図である。
【0081】
発信側の機器は、発側固定ＩＭＳ網２０を介して着信側の機器へと向けてＩＮＶＩＴＥリクエストを送信し（Ｆ１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0082】
続いて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0083】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ４）。このとき、メッセージＲＥＬの理由表示値（Ｃａｕｓｅ Ｖａｌｕｅ）が、機器が割り当てられていない電話番号（即ち、欠番）であることを意味するコード１（即ち、Ｕｎａｌｌｏｃａｔｅｄ ｎｕｍｂｅｒ）とされる。
【0084】
メッセージＲＥＬ（尚、理由表示値がコード１である）の送信（Ｆ４）を受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて発信側からリクエストされたメディアリソースが見つからないことを示すコード４０４ Ｎｏｔ Ｆｏｕｎｄレスポンスが返信される（Ｆ５）。
【0085】
これに対して、発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスが返信され（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信される（Ｆ７）。これにより、発信側の機器からのＩＮＶＩＴＥリクエストに係るセッションが終了する。
【0086】
（移転の場合）
図６は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてのメタルＩＰ電話端末６０が移転している場合の動作の基本シーケンスを説明する図である。
図６は、ＩＭＳ相互接続におけるＩＮＶＩＴＥメソッドによる、発信側の機器と発側固定ＩＭＳ網２０とメタル収容装置４１／５１との間における、着信側の機器としてのメタルＩＰ電話端末６０が移転している場合の動作の基本シーケンスを説明する図である。
【0087】
発信側の機器は、発側固定ＩＭＳ網２０を介して着信側の機器へと向けてＩＮＶＩＴＥリクエストを送信し（Ｆ１）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0088】
続いて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0089】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。
【0090】
さらに、メタル収容装置４１／５１から発信側の機器へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、着信側の機器の電話番号は変更されていることを知らせる移転ガイダンス及び変更後の電話番号（言い換えると、着信側の機器は移転していることを知らせる移転ガイダンス及び移転先の電話番号）が送信される。なお、移転ガイダンスの案内の時間長さは、例えば、６０～８０秒程度である。
【0091】
移転ガイダンスの終了後、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ６）。このとき、メッセージＲＥＬの理由表示値（Ｃａｕｓｅ Ｖａｌｕｅ）が、着信者の番号は変更されていることを意味するコード２２（即ち、ｎｕｍｂｅｒ ｃｈａｎｇｅｄ （ｗ／ｏ ｄｉａｇｎｏｓｔｉｃ））とされる。
【0092】
メッセージＲＥＬ（尚、理由表示値がコード２２である）の送信（Ｆ６）を受けて、発側固定ＩＭＳ網２０から発信側の機器へと、ＳＩＰセッションにおいて発信側からリクエストされたメディアリソースが以前は存在したが現在は存在しないことを示すコード４１０ Ｇｏｎｅレスポンスが返信される（Ｆ７）。
【0093】
これに対して、発信側の機器から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスが返信され（Ｆ８）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信される（Ｆ９）。これにより、発信側の機器からのＩＮＶＩＴＥリクエストに係るセッションが終了する。
【0094】
（電話番号の調査装置）
図７は、実施の形態に係る電話番号の調査装置１０の構成を示すブロック図である。
図７は、実施の形態に係る電話番号の調査装置１０の構成を示すブロック図である。
【0095】
実施の形態に係る電話番号の調査装置１０は、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続され、調査対象のメタルＩＰ電話端末６０に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して（調査対象のメタルＩＰ電話端末６０へと向けて）発側固定ＩＭＳ網２０にＩＮＶＩＴＥリクエストを送信するとともに、少なくとも発側固定ＩＭＳ網２０を介して応答メッセージを受信し、応答メッセージに応じて調査対象のメタルＩＰ電話端末６０の電話番号の使用状況を判定する、ようにしている。
【0096】
電話番号の調査装置１０は、網インタフェース部１１と、メッセージ交換制御部１２と、電話番号調査判定部１３と、電話番号履歴生成部１４と、電話番号履歴データベース(ＤＢ)１５と、を含む。
【0097】
網インタフェース部１１は、電話番号の調査装置１０がＳＩＰプロトコルに準拠した通信を行うための通信インタフェースを担う。
【0098】
メッセージ交換制御部１２は、調査対象のメタルＩＰ電話端末６０へと、判定用ＳＤＰパラメータを含むＩＮＶＩＴＥリクエストを送信し、また、少なくとも発側固定ＩＭＳ網２０を介してメッセージ（例えば、ＳＩＰセッションにおける所定コードのレスポンス）を受信する。
【0099】
電話番号調査判定部１３は、メッセージ交換制御部１２を介して受信したメッセージ（例えば、ＳＩＰセッションにおける所定コードのレスポンス）に応じて、着信側のメタルＩＰ電話端末６０の実在の有無などを判定し、延いては、調査対象のメタルＩＰ電話端末６０の電話番号の有効性（言い換えると、電話番号の使用状況）を判定する。
【0100】
電話番号履歴生成部１４は、電話番号調査判定部１３での判定結果のそれぞれに判定日時を示すタイムスタンプを付与して記録媒体上に時系列に記録することにより、電話番号履歴データベース１５を構築する。
【0101】
電話番号履歴データベース１５のデータ構造（言い換えると、収録データ項目）は特定の構造や項目には限定されないものの、電話番号履歴データベース１５に格納される電話番号履歴情報は、例えば、１回の調査ごと（言い換えると、ＩＮＶＩＴＥリクエストの送信ごと）の、調査対象である「電話番号」と、発側固定ＩＭＳ網２０を介して返信される「エラーコード」と、「調査年月日」（即ち、タイムスタンプ）と、「実在／欠番／移転の判定結果」と、発側固定ＩＭＳ網２０を介して返信されるレイヤーに関する「その他レイヤー情報」と、の組合せを含んでよい。
【0102】
電話番号履歴データベース１５に格納される電話番号履歴情報は、また、上記したデータ項目のほかに、例えば、調査対象のメタルＩＰ電話端末６０の種別、調査時に判明した移転先あるいは連絡先電話番号である「新加入者番号」、電話番号を所有する「法人名・個人名」、住所や年齢などの「属性情報」、「地図リンク情報」、信用を評価するための「与信情報」を含んでもよい。
【0103】
そして、例えば電話番号「０３－ＸＸＸＸ－ＸＸＸＸ」について電話番号の調査装置１０によって電話番号の使用状況の調査が実行されると、電話番号履歴データベース１５に、電話番号調査判定部１３による判定ごとに、調査情報が順次記録され、電話番号履歴情報として蓄積される。
【0104】
なお、電話番号履歴データベース１５は、例えば、半導体メモリ、ハードディスク、或いは、ＤＶＤ（Ｄigital Ｖersatile Ｄisc）等の光メモリなどの大容量記録媒体に実装されてよい。
【0105】
電話番号の調査装置１０は、所定のプログラム（尚、実施の形態に係る電話番号の調査プログラムを含む）が記録されたメモリ（図示していない）を内蔵するマイクロプロセッサ、又は所定のプログラムが記録されたメモリ（図示していない）が外付けされたマイクロプロセッサと、通信制御を含む周辺制御を行うＬＳＩ（Ｌarge Ｓcale Ｉntegration）と、を含んで構成される。
【0106】
そして、メモリ（図示していない）に記録された所定のプログラム（尚、実施の形態に係る電話番号の調査プログラムを含む）をマイクロプロセッサが逐次読み出して実行することにより、網インタフェース部１１、メッセージ交換制御部１２、電話番号調査判定部１３、及び電話番号履歴生成部１４のそれぞれが構成され、電話番号の調査装置１０としての所定の機能が実現される。
【0107】
（電話番号の調査方法）
本発明に係る電話番号の調査方法の具体的な構成態様の一例としての、実施の形態に係る電話番号の調査方法は、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続されるコンピュータ（具体的には、電話番号の調査装置１０）を用いて、調査対象となるメタルＩＰ電話端末６０の電話番号の使用状況を調査する方法であり、調査対象のメタルＩＰ電話端末６０に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して（調査対象のメタルＩＰ電話端末６０へと向けて）発側固定ＩＭＳ網２０にＩＮＶＩＴＥリクエストを送信するステップと、少なくとも発側固定ＩＭＳ網２０を介して応答メッセージを受信するステップと、応答メッセージに応じて調査対象のメタルＩＰ電話端末６０の電話番号の使用状況を判定するステップと、を含み、ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、ようにしている。
本発明に係る電話番号の調査方法の具体的な構成態様の一例としての、実施の形態に係る電話番号の調査方法は、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続されるコンピュータ（具体的には、電話番号の調査装置１０）を用いて、調査対象となるメタルＩＰ電話端末６０の電話番号の使用状況を調査する方法であり、調査対象のメタルＩＰ電話端末６０に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して（調査対象のメタルＩＰ電話端末６０へと向けて）発側固定ＩＭＳ網２０にＩＮＶＩＴＥリクエストを送信するステップと、少なくとも発側固定ＩＭＳ網２０を介して応答メッセージを受信するステップと、応答メッセージに応じて調査対象のメタルＩＰ電話端末６０の電話番号の使用状況を判定するステップと、を含み、ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている、ようにしている。
【0108】
以下に説明する電話番号の調査方法は、コンピュータ（具体的には、電話番号の調査装置１０）に電話番号の調査プログラムを実行させて当該プログラムに従って該当する各手順を実行させることによって実施されうる。
【0109】
ＳＤＰパラメータとして、判定用ＳＤＰパラメータのうち、ネットワークプロトコル（別言すると、インターネットプロトコル、ＩＰバージョン）についてＩＰｖ４を記述して（言い換えると、使用して）オファーするとともに、他の判定用ＳＤＰパラメータについては下記のように記述される。判定用ＳＤＰパラメータに関する下記の記述のことを「メタルＩＰ電話用ＳＤＰ」と称する。
○メディア種別：ａｕｄｉｏのみ
○メディアのトランスポートプロトコル：ＲＴＰ／ＡＶＰのみ
○音声コーデック：Ｇ．７１１ μ－ｌａｗ 及び Ｇ．７２２
○メディア種別：ａｕｄｉｏのみ
○メディアのトランスポートプロトコル：ＲＴＰ／ＡＶＰのみ
○音声コーデック：Ｇ．７１１ μ－ｌａｗ 及び Ｇ．７２２
【0110】
（実在判定／その１）
図８は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が実在し且つ話中でない場合の動作シーケンスのその１を説明する図である。
図８は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が実在し且つ話中でない場合の動作シーケンスのその１を説明する図である。
【0111】
図８は、特に、着信の際に発信者（即ち、相手方）の電話番号を電話端末に表示させる機能（具体的には、Ｃaller ＩＤ、Ｃalling Ｎumber Ｉdentification；例えば、ナンバーディスプレイ（登録商標））による、発信者が電話番号を非通知とする設定をしている場合には着信を拒否する設定がされていない場合の動作シーケンスを説明する図である。
【0112】
電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０を介して調査対象となるメタルＩＰ電話端末６０に宛ててＩＮＶＩＴＥリクエストを送信する（Ｆ１）。このとき、ＩＮＶＩＴＥリクエストに含まれるＳＤＰパラメータとして、判定用ＳＤＰパラメータ（尚、ネットワークプロトコルはＩＰｖ４である）について上記のメタルＩＰ電話用ＳＤＰが記述される。
【0113】
ＩＮＶＩＴＥリクエストの送信（Ｆ１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0114】
続いて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0115】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。なお、着信側の機器（即ち、調査対象のメタルＩＰ電話端末６０）によっては、ＡＣＭの返信が行われず、このため、コード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスの返信も行われない場合がある。
【0116】
さらに、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式においてインチャネル情報利用可能を示すメッセージであるＣＰＧ（Ｃall Ｐrogress Ｍessage）が返信され（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて着信音が鳴っていることを示すコード１８０ Ｒｉｎｇｉｎｇレスポンスが返信される（Ｆ７）。この時、着信側の調査対象のメタルＩＰ電話端末６０は、呼出しベルが鳴動する。
【0117】
この場合、電話番号の調査装置１０の電話番号調査判定部１３は、着信側の調査対象のメタルＩＰ電話端末６０が実在し且つ話中でない（即ち、調査対象のメタルＩＰ電話端末６０の電話番号が実在する）と判定する。
【0118】
上記のＦ６及びＦ７に続いて、メタル収容装置４１／５１から電話番号の調査装置１０へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、ＲＢＴ（Ｒinging Ｂack Ｔone）が送出される。
【0119】
また、電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいてセッションを終了するための指示であるＣＡＮＣＥＬリクエストを送信する（Ｆ８）。
【0120】
電話番号の調査装置１０のメッセージ交換制御部１２は、すなわち、コード１８０レスポンスを受信すると、着信側の調査対象のメタルＩＰ電話端末６０の呼出しベルの鳴動を停止させるために、即時に（さらに言えば、コード１８０レスポンスの受信とほぼ同時に）、ＣＡＮＣＥＬリクエストを送信する。これにより、着信側の調査対象のメタルＩＰ電話端末６０の呼出しベルの鳴動は極めて短い時間で停止する。
【0121】
ＣＡＮＣＥＬリクエストの送信（Ｆ８）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ９）。
【0122】
これに対して、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信され（Ｆ１０）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＣＡＮＣＥＬリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ１１）とともに、ＳＩＰセッションにおいてセッションの終了を示すコード４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄレスポンスが返信される（Ｆ１２）。
【0123】
これに対して、電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスを返信する（Ｆ１３）。これにより、電話番号の調査装置１０と着信側の調査対象のメタルＩＰ電話端末６０との間のセッションが終了し、すなわち、電話番号の調査装置１０と着信側の調査対象のメタルＩＰ電話端末６０との間の通信が切断される。
【0124】
（実在判定／その２）
図９は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が実在し且つ話中でない場合の動作シーケンスのその２を説明する図である。
図９は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が実在し且つ話中でない場合の動作シーケンスのその２を説明する図である。
【0125】
図９は、特に、着信の際に発信者（即ち、相手方）の電話番号を電話端末に表示させる機能（具体的には、Ｃaller ＩＤ、Ｃalling Ｎumber Ｉdentification；例えば、ナンバーディスプレイ（登録商標））による、発信者が電話番号を非通知とする設定をしている場合には着信を拒否する設定がされている場合の動作シーケンスを説明する図である。
【0126】
電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０を介して調査対象となるメタルＩＰ電話端末６０に宛ててＩＮＶＩＴＥリクエストを送信する（Ｆ１）。このとき、ＩＮＶＩＴＥリクエストに含まれるＳＤＰパラメータとして、判定用ＳＤＰパラメータ（尚、ネットワークプロトコルはＩＰｖ４である）について上記のメタルＩＰ電話用ＳＤＰが記述される。
【0127】
ＩＮＶＩＴＥリクエストの送信（Ｆ１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0128】
続いて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0129】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。
【0130】
さらに、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式においてインチャネル情報利用可能を示すメッセージであるＣＰＧ（Ｃall Ｐrogress Ｍessage）が返信され（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて着信音が鳴っていることを示すコード１８０ Ｒｉｎｇｉｎｇレスポンスが返信される（Ｆ７）。なお、着信側の機器（即ち、調査対象のメタルＩＰ電話端末６０）によっては、ＣＰＧの返信が行われず、このため、コード１８０ Ｒｉｎｇｉｎｇレスポンスの返信も行われない場合がある。
【0131】
この際、（実際には、着信が拒否されているので）着信側の調査対象のメタルＩＰ電話端末６０は呼出しベルが鳴動せず、メタル収容装置４１／５１から電話番号の調査装置１０へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、ＲＢＴ（Ｒinging Ｂack Ｔone）が送信され、その後、発信者が電話番号を非通知とする設定をしているために着信が拒否されていることを知らせるガイダンスが送信される。
【0132】
次に、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において着信者が通話に応答したことを示すメッセージであるＡＮＭ（Ａnswer Ｍessage）が返信され（Ｆ８）（但し、実際には着信は拒否されている）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＩＮＶＩＴＥリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ９）。
【0133】
この場合、電話番号の調査装置１０の電話番号調査判定部１３は、着信側の調査対象のメタルＩＰ電話端末６０が実在し且つ話中でない（即ち、調査対象のメタルＩＰ電話端末６０の電話番号が実在する）と判定する。なお、着信側の調査対象のメタルＩＰ電話端末６０は、呼出しベルが鳴動しない。
【0134】
続いて、電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスを送信する（Ｆ１０）とともに、ＳＩＰセッションにおいてセッションを終了することを示すＢＹＥリクエストを送信する（Ｆ１１）。
【0135】
電話番号の調査装置１０のメッセージ交換制御部１２は、すなわち、コード２００レスポンスを受信すると、着信側の調査対象のメタルＩＰ電話端末６０との間の通信を切断するために、ＢＹＥリクエストを送信する。
【0136】
ＢＹＥリクエストの送信（Ｆ１１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ１２）。
【0137】
これに対して、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信され（Ｆ１３）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＢＹＥリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ１４）。これにより、電話番号の調査装置１０と着信側の調査対象のメタルＩＰ電話端末６０との間のセッションが終了し、すなわち、電話番号の調査装置１０と着信側の調査対象のメタルＩＰ電話端末６０との間の通信が切断される。
【0138】
（実在判定／話中の場合）
図１０は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が実在し且つ話中である場合の動作シーケンスを説明する図である。
図１０は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が実在し且つ話中である場合の動作シーケンスを説明する図である。
【0139】
電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０を介して調査対象となるメタルＩＰ電話端末６０に宛ててＩＮＶＩＴＥリクエストを送信する（Ｆ１）。このとき、ＩＮＶＩＴＥリクエストに含まれるＳＤＰパラメータとして、判定用ＳＤＰパラメータ（尚、ネットワークプロトコルはＩＰｖ４である）について上記のメタルＩＰ電話用ＳＤＰが記述される。
【0140】
ＩＮＶＩＴＥリクエストの送信（Ｆ１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0141】
続いて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0142】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。なお、次のＦ６のメッセージＲＥＬ（Ｒelease Ｍessage）を生成することによってＡＣＭの返信が行われない場合があり、このため、コード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスの返信も行われない場合がある。
【0143】
さらに、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ６）。このとき、メッセージＲＥＬの理由表示値（Ｃａｕｓｅ Ｖａｌｕｅ）が、着信者がビジー状態であることを意味するコード１７（即ち、Ｕｓｅｒ ｂｕｓｙ）とされる。
【0144】
メッセージＲＥＬ（尚、理由表示値がコード１７である）の送信（Ｆ６）を受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて発信側からリクエストされたメディアリソースが現在ビジー状態であってセッションを開始できないことを示すコード４８６ Ｂｕｓｙ Ｈｅｒｅレスポンスが返信される（Ｆ７）。
【0145】
この場合、電話番号の調査装置１０の電話番号調査判定部１３は、着信側の調査対象のメタルＩＰ電話端末６０が実在し且つ話中である（即ち、調査対象のメタルＩＰ電話端末６０の電話番号が実在する）と判定する。
【0146】
続いて、電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスを返信し（Ｆ８）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信される（Ｆ９）。これにより、電話番号の調査装置１０からのＩＮＶＩＴＥリクエストに係るセッションが終了する。
【0147】
（欠番判定）
図１１は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０（言い換えると、電話番号）が欠番である場合の動作シーケンスを説明する図である。
図１１は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０（言い換えると、電話番号）が欠番である場合の動作シーケンスを説明する図である。
【0148】
電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０を介して調査対象となるメタルＩＰ電話端末６０に宛ててＩＮＶＩＴＥリクエストを送信する（Ｆ１）。このとき、ＩＮＶＩＴＥリクエストに含まれるＳＤＰパラメータとして、判定用ＳＤＰパラメータ（尚、ネットワークプロトコルはＩＰｖ４である）について上記のメタルＩＰ電話用ＳＤＰが記述される。
【0149】
ＩＮＶＩＴＥリクエストの送信（Ｆ１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0150】
続いて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0151】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ４）。このとき、メッセージＲＥＬの理由表示値（Ｃａｕｓｅ Ｖａｌｕｅ）が、機器が割り当てられていない電話番号（即ち、欠番）であることを意味するコード１（即ち、Ｕｎａｌｌｏｃａｔｅｄ ｎｕｍｂｅｒ）とされる。
【0152】
メッセージＲＥＬ（尚、理由表示値がコード１である）の送信（Ｆ４）を受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて発信側からリクエストされたメディアリソースが見つからないことを示すコード４０４ Ｎｏｔ Ｆｏｕｎｄレスポンスが返信される（Ｆ５）。
【0153】
この場合、電話番号の調査装置１０の電話番号調査判定部１３は、着信側の調査対象のメタルＩＰ電話端末６０は欠番である（即ち、調査対象のメタルＩＰ電話端末６０の電話番号は欠番である）と判定する。なお、欠番は、着信側の調査対象のメタルＩＰ電話端末６０が解約されている場合を含む
【0154】
続いて、電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスを返信し（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信される（Ｆ７）。これにより、電話番号の調査装置１０からのＩＮＶＩＴＥリクエストに係るセッションが終了する。
【0155】
ここで、図１２は、ＳＤＰパラメータとして、判定用ＳＤＰパラメータのうち、ネットワークプロトコル（別言すると、インターネットプロトコル、ＩＰバージョン）についてＩＰｖ４を記述してオファーする場合で、メタルＩＰ電話用ＳＤＰのうち音声コーデックについてＧ．７１１ μ－ｌａｗのみを記述した（即ち、Ｇ．７２２を含まない）場合に、調査対象のメタルＩＰ電話端末６０（言い換えると、電話番号）が欠番である場合の動作シーケンスを説明する図である。
【0156】
この場合は、電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）からのＩＮＶＩＴＥリクエストの送信（Ｆ１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へとメッセージＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信され（Ｆ２）、続いて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へとコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0157】
また、メタル収容装置４１／５１からのメッセージＡＣＭの返信（Ｆ４）を受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へとコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。
【0158】
続いて、電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）から発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおける仮応答確認であるＰＲＡＣＫ（Ｐrovisional Ｒesponse Ａcknowledgement）リクエストが送信され（Ｆ６）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと宛てて、ＳＩＰセッションにおいてリクエスト（ここでは具体的には、ＰＲＡＣＫリクエスト）が正常に処理されたことを示すコード２００ ＯＫレスポンスが返信される（Ｆ７）。
【0159】
このとき、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと宛てて返信されるコード２００ ＯＫレスポンス（Ｆ７）は、ホームゲートウェイ１９を通過することができず、したがって電話番号の調査装置１０へと到達することができない。このため、図９で説明したような、電話番号の調査装置１０のメッセージ交換制御部１２がコード２００レスポンスを受信するとＢＹＥリクエストを送信する、という動作は起こらない。
【0160】
続いて、メタル収容装置４１／５１から電話番号の調査装置１０へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、着信側の機器（ここでは具体的には、調査対象のメタルＩＰ電話端末６０；言い換えると、電話番号）が欠番であることを知らせる欠番ガイダンスが送信される。
【0161】
欠番ガイダンスの終了後、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へとメッセージＲＬＣが返信され（Ｆ８）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へとコード４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄレスポンスが返信される（Ｆ９）。
【0162】
これを受けて、電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）から発側固定ＩＭＳ網２０へとＡＣＫレスポンスが返信される（Ｆ１０）。
【0163】
このとき、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へとコード４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄレスポンスが返信された（Ｆ９）ことを以て、調査対象のメタルＩＰ電話端末６０（言い換えると、電話番号）が欠番であると判定するようにすることも考えられる。
【0164】
しかしながら、図１２に示す動作では、欠番ガイダンスの送信が終了してからメッセージＲＬＣの返信（Ｆ８）及びコード４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄレスポンスの返信（Ｆ９）が行われる。このため、ＩＮＶＩＴＥリクエストを送信して（Ｆ１）からＡＣＫレスポンスを返信する（Ｆ１０）まで３２秒程度要する。
【0165】
これに対して、図１１に示す動作では、ＩＮＶＩＴＥリクエストを送信して（Ｆ１）からＡＣＫレスポンスを返信して（Ｆ６）メッセージＲＬＣを返信する（Ｆ７）まで０．４秒程度しか要しない。
【0166】
したがって、図１２に示すように判定用ＳＤＰパラメータのうち音声コーデックについてＧ．７１１ μ－ｌａｗのみとして欠番ガイダンスの後のコード４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄレスポンスの返信を以て欠番判定を行うよりも、図１１に示すように判定用ＳＤＰパラメータのうち音声コーデックについてＧ．７１１ μ－ｌａｗ及びＧ．７２２として欠番ガイダンスを経ることなくコード４０４ Ｎｏｔ Ｆｏｕｎｄレスポンスの返信を以て欠番判定を行う方が、大幅な時間短縮が可能である点で好ましい。
【0167】
このため、ＳＤＰパラメータとして、判定用ＳＤＰパラメータのうち、ネットワークプロトコルについてＩＰｖ４を記述してオファーする場合には、他の判定用ＳＤＰパラメータのうち音声コーデックについてＧ．７１１ μ－ｌａｗに加えてＧ．７２２を記述する（即ち、Ｇ．７１１ μ－ｌａｗとＧ．７２２とを同時オファーする）ようにすることが適当である。
【0168】
（移転判定）
図１３は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が移転している場合の動作シーケンスを説明する図である。
図１３は、ＳＤＰパラメータとして、ネットワークプロトコルについてＩＰｖ４を記述するとともに判定用ＳＤＰパラメータについて上記のメタルＩＰ電話用ＳＤＰを記述してオファーした場合で、調査対象のメタルＩＰ電話端末６０が移転している場合の動作シーケンスを説明する図である。
【0169】
電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０を介して調査対象となるメタルＩＰ電話端末６０に宛ててＩＮＶＩＴＥリクエストを送信する（Ｆ１）。このとき、ＩＮＶＩＴＥリクエストに含まれるＳＤＰパラメータとして、判定用ＳＤＰパラメータ（尚、ネットワークプロトコルはＩＰｖ４である）について上記のメタルＩＰ電話用ＳＤＰが記述される。
【0170】
ＩＮＶＩＴＥリクエストの送信（Ｆ１）を受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式においてネットワーク内で通話の設立情報を伝達するメッセージであるＩＡＭ（Ｉnitial Ａddress Ｍessage）が送信される（Ｆ２）。
【0171】
続いて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいてリクエストを受け付けたことを示すコード１００ Ｔｒｙｉｎｇレスポンスが返信される（Ｆ３）。
【0172】
また、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の設立の際に通話が到達して発信者と着信者との間で通信回線が確立したことを示すメッセージであるＡＣＭ（Ａddress Ｃomplete Ｍessage）が返信され（Ｆ４）、これを受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて呼び出しの進行状況を示すコード１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓレスポンスが返信される（Ｆ５）。
【0173】
さらに、メタル収容装置４１／５１から電話番号の調査装置１０へと、ＲＴＰ（Ｒeal time Ｔransport Ｐrotocol）として、着信側の機器の電話番号は変更されていることを知らせる移転ガイダンス及び変更後の電話番号（言い換えると、着信側の機器は移転していることを知らせる移転ガイダンス及び移転先の電話番号）が送信される。なお、移転ガイダンスの案内の時間長さは、例えば、６０～８０秒程度である。
【0174】
移転ガイダンスの終了後、メタル収容装置４１／５１から発側固定ＩＭＳ網２０へと、ＩＳＵＰ信号方式において通話の終了を示すメッセージであるＲＥＬ（Ｒelease Ｍessage）が送信される（Ｆ６）。このとき、メッセージＲＥＬの理由表示値（Ｃａｕｓｅ Ｖａｌｕｅ）が、着信者の番号は変更されていることを意味するコード２２（即ち、ｎｕｍｂｅｒ ｃｈａｎｇｅｄ （ｗ／ｏ ｄｉａｇｎｏｓｔｉｃ））とされる。
【0175】
メッセージＲＥＬ（尚、理由表示値がコード２２である）の送信（Ｆ６）を受けて、発側固定ＩＭＳ網２０から電話番号の調査装置１０（具体的には、メッセージ交換制御部１２）へと、ＳＩＰセッションにおいて発信側からリクエストされたメディアリソースが以前は存在したが現在は存在しないことを示すコード４１０ Ｇｏｎｅレスポンスが返信される（Ｆ７）。
【0176】
この場合、電話番号の調査装置１０の電話番号調査判定部１３は、着信側の調査対象のメタルＩＰ電話端末６０は移転している（即ち、調査対象のメタルＩＰ電話端末６０の電話番号は欠番である）と判定する。
【0177】
電話番号の調査装置１０は、（何らかの）ガイダンスが送信されてきた場合に当該ガイダンスを録音（別言すると、パケットキャプチャ）して音声データとして保持し、ガイダンスに続いてコード４１０ Ｇｏｎｅレスポンスが返信されたときは、録音・保持した音声データを着信側の調査対象のメタルＩＰ電話端末６０の移転先の電話番号を含む音声データとしてメモリやストレージデバイス（いずれも図示していない）に保存するようにしてもよい。
【0178】
電話番号の調査装置１０は、さらに、着信側の調査対象のメタルＩＰ電話端末６０の移転先の電話番号を含む音声データとして保存された音声データをテキスト変換（即ち、Ｓｐｅｅｃｈ ｔｏ Ｔｅｘｔ）し、変換後のテキストデータを着信側の調査対象のメタルＩＰ電話端末６０の移転先の電話番号を含むテキストデータとしてメモリやストレージデバイス（いずれも図示していない）に保存するようにしてもよい。
【0179】
すなわち、電話番号の調査装置１０は、移転ガイダンスを利用して、具体的には、移転ガイダンスとして送信される音声データをテキストデータへと変換して、着信側の調査対象のメタルＩＰ電話端末６０の移転先の電話番号情報を取得するようにしてもよい。この場合、電話番号の調査装置１０は、音声変換部（図示していない）をさらに含むようにしてよい。
【0180】
続いて、電話番号の調査装置１０のメッセージ交換制御部１２は、発側固定ＩＭＳ網２０へと、ＳＩＰセッションにおいて確認応答を示すＡＣＫレスポンスを返信し（Ｆ８）、これを受けて、発側固定ＩＭＳ網２０からメタル収容装置４１／５１へと、ＩＳＵＰ信号方式において通話の終了の確認と通話に関連するリソースの解放とを示すメッセージであるＲＬＣ（Ｒelease Ｃomplete Ｍessage）が返信される（Ｆ９）。これにより、電話番号の調査装置１０からのＩＮＶＩＴＥリクエストに係るセッションが終了する。
【0181】
（電話番号の調査方法）
図１４は、上述の動作シーケンスをふまえた、メタルＩＰ電話端末６０の電話番号（具体的には例えば、０ＡＢ－Ｊ型固定電話の電話番号）の使用状況（具体的には、実在（空き、話中）、欠番、及び移転）を調査する仕法の整理を示す。
図１４は、上述の動作シーケンスをふまえた、メタルＩＰ電話端末６０の電話番号（具体的には例えば、０ＡＢ－Ｊ型固定電話の電話番号）の使用状況（具体的には、実在（空き、話中）、欠番、及び移転）を調査する仕法の整理を示す。
【0182】
通信事業者に接続されるメタルＩＰ電話端末６０の０ＡＢ－Ｊ番号である固定電話の電話番号の使用状況については、ＳＤＰパラメータのうち、ネットワークプロトコル（別言すると、インターネットプロトコル、ＩＰバージョン）についてＩＰｖ４を記述するとともに、他のＳＤＰパラメータについてメタルＩＰ電話用ＳＤＰを用いてＳＤＰオファー（即ち、ＩＮＶＩＴＥリクエスト）をすることにより、実在（空き、話中）、欠番、及び移転のうちのいずれであるかを的確に判定することができる。
【0183】
（電話番号の調査プログラム）
本発明に係る電話番号の調査プログラムの具体的な構成態様の一例としての、実施の形態に係る電話番号の調査プログラムは、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続される電話番号の調査装置１０（図１、図７参照）に実装されるプログラムである。
本発明に係る電話番号の調査プログラムの具体的な構成態様の一例としての、実施の形態に係る電話番号の調査プログラムは、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続される電話番号の調査装置１０（図１、図７参照）に実装されるプログラムである。
【0184】
実施の形態に係る電話番号の調査プログラムは、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続されるコンピュータ（具体的には、電話番号の調査装置１０）に、調査対象のメタルＩＰ電話端末６０に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して（調査対象のメタルＩＰ電話端末６０へと向けて）発側固定ＩＭＳ網２０にＩＮＶＩＴＥリクエストを送信させる処理と、少なくとも発側固定ＩＭＳ網２０を介して応答メッセージを受信させる処理と、応答メッセージに応じて調査対象のメタルＩＰ電話端末６０の電話番号の使用状況を判定させる処理と、を少なくとも実行させる、ようにしている。
【0185】
そして、実施の形態に係る電話番号の調査プログラムは、ＳＤＰパラメータが、ネットワークプロトコルはＩＰｖ４、メディア種別はａｕｄｉｏのみ、メディアのトランスポートプロトコルはＲＴＰ／ＡＶＰのみ、並びに音声コーデックはＧ．７１１ μ－ｌａｗ及びＧ．７２２とされている（即ち、メタルＩＰ電話用ＳＤＰ）、ようにしている。
【0186】
（電話番号の情報提供システム）
図１５は、本発明に係る電話番号の情報提供システムの具体的な構成態様の一例としての、実施の形態に係る電話番号の情報提供システム１００のシステム構成図である。
図１５は、本発明に係る電話番号の情報提供システムの具体的な構成態様の一例としての、実施の形態に係る電話番号の情報提供システム１００のシステム構成図である。
【0187】
実施の形態に係る電話番号の情報提供システム１００は、１以上のユーザ端末９０と、ユーザ端末９０とＩＰ網８０経由で接続されるとともに図示省略した網（例えば、発側固定ＩＭＳ網２０）と接続される電話番号調査サーバ（具体的には、電話番号の調査装置１０）と、を含む。
【0188】
実施の形態に係る電話番号の情報提供システム１００は、電話番号調査サーバ（具体的には、電話番号の調査装置１０）と、ユーザ端末９０と、を有し、電話番号調査サーバ（具体的には、電話番号の調査装置１０）が、ユーザ端末９０からメタルＩＰ電話端末６０についての電話番号調査情報提供要求を受信すると、電話番号調査情報提供要求があったユーザ端末９０に電話番号調査判定部１３が判定したメタルＩＰ電話端末６０の電話番号の使用状況をＩＰ網８０経由で送信する網インタフェース部１１を備える（図７参照）、ようにしている。
【0189】
電話番号調査サーバ（具体的には、電話番号の調査装置１０）は、ユーザ端末９０から調査対象の電話番号に関する電話番号調査情報提供要求をＩＰ網８０経由で受信すると、電話番号の使用状況の判定結果のそれぞれに判定日時を示すタイムスタンプが付与されて時系列に記録された電話番号履歴情報が格納されている記録媒体（具体的には、電話番号履歴データベース(ＤＢ)１５）を参照し、電話番号調査情報提供要求があったユーザ端末９０へとＩＰ網８０経由で電話番号履歴情報を送信する。
【0190】
電話番号履歴情報が格納されている記録媒体（具体的には、電話番号履歴データベース１５）は、必要なユーザに単独で配布されてもよい。前記記録媒体（電話番号履歴データベース１５）は、例えば、通信事業者網に専用線経由で接続される電話番号の調査装置１０により生成される、調査対象の電話番号の実在の有無が記録される記録媒体であり、配布先のシステムで検索用に使用されてもよい。
【0191】
電話番号履歴情報が格納されている記録媒体（具体的には、電話番号履歴データベース１５）は、着信側の電話端末（具体的には、メタルＩＰ電話端末６０としての固定電話）の電話番号の使用状況について有効性を判定した結果の集合体であり、例えば、判定結果のそれぞれに判定日時を示すタイムスタンプが付与されて時系列に記録されているものである。
【0192】
記録媒体（具体的には、電話番号履歴データベース１５）の配布は、ＤＶＤやハードディスクに記録されたデータベースの態様での配布に限らず、通信回線を利用した配布も含まれる。
【0193】
（作用効果）
実施の形態に係る電話番号の調査装置１０によれば、事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用して、発側固定ＩＭＳ網２０及び着側固定ＩＭＳ網３０における電話番号の使用状況の調査を実現することが可能となる。このため、発側固定ＩＭＳ網２０とＵＮＩ接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することにより、新システム基盤への円滑な移行が可能となる。
実施の形態に係る電話番号の調査装置１０によれば、事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用して、発側固定ＩＭＳ網２０及び着側固定ＩＭＳ網３０における電話番号の使用状況の調査を実現することが可能となる。このため、発側固定ＩＭＳ網２０とＵＮＩ接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することにより、新システム基盤への円滑な移行が可能となる。
【0194】
実施の形態に係る電話番号の調査装置１０によれば、また、メタルＩＰ電話端末６０の電話番号が使用されている状態（有効（実在））と使用されていない状態（無効（欠番））との別を正確に判定することが可能となる。このため、発側固定ＩＭＳ網２０とＵＮＩ接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することにより、新システム基盤への円滑な移行が可能となる。
【0195】
実施の形態に係る電話番号の調査プログラムによれば、電話番号の調査装置１０がメモリ（図示していない）に記録されている当該プログラムを逐次読み出して実行することにより、事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用して、発側固定ＩＭＳ網２０及び着側固定ＩＭＳ網３０における電話番号の使用状況の調査を実現することが可能となる。このため、発側固定ＩＭＳ網２０とＵＮＩ接続可能なＳＩＰプロトコルベースの電話番号調査ツールを導入することにより、新システム基盤への円滑な移行が可能となる。
【0196】
実施の形態に係る電話番号の情報提供システム１００によれば、電話番号の調査装置１０で判定した、電話番号が使用されている状態（有効（実在））と使用されていない状態（無効（欠番））との別を、当該情報を必要としているユーザに提供することが可能となる。また、電話番号履歴情報が格納されている記録媒体（具体的には、電話番号履歴データベース１５）を、当該情報を必要としているユーザへ配布することにより、ユーザサイドで活用することを可能とし、例えば与信などにおいて有用な情報を提供することが可能となる。
【0197】
以上、本発明の実施の形態について説明したが、本発明の具体的な構成態様は上記の実施の形態に限定されるものではなく、上記の実施の形態に、本発明の要旨を逸脱しない範囲の変形や変更などが加えられた形態も本発明に含まれる。
【0198】
例えば、上記の実施の形態では、電話番号の調査装置１０が、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続されているとともに、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続されているようにしている。しかしながら、本発明に係る電話番号の調査装置の網接続態様は上述の実施の形態における態様に限定されるものではなく、電話番号の調査装置が、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）と、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）と、のうちのどちらか一方のみに、発側固定ＩＭＳ網２０を介して接続されているようにしてもよい。
【符号の説明】
【0199】
１０ 電話番号の調査装置
１１ 網インタフェース部
１２ メッセージ交換制御部
１３ 電話番号調査判定部
１４ 電話番号履歴生成部
１５ 電話番号履歴データベース
１９ ホームゲートウェイ（ＨＧＷ）
２０ 発側固定ＩＭＳ網
２０ａ ＳＩＰサーバ
２１ ＩＢＣＦ（Ｉnter-connection Ｂorder Ｃontrol Ｆunction）
２２ ＢＧＣＦ（Ｂreakout Ｇateway Ｃontrol Ｆunction）
３０ 着側固定ＩＭＳ網
３０ａ ＳＩＰサーバ
３１ ＩＢＣＦ（Ｉnter-connection Ｂorder Ｃontrol Ｆunction）
３２ ＢＧＣＦ（Ｂreakout Ｇateway Ｃontrol Ｆunction）
４１ メタル収容装置
５１ メタル収容装置
６０ メタルＩＰ電話端末
６０ａ メタルＩＰ電話端末
６０ｂ メタルＩＰ電話端末
９０ ユーザ端末
１００ 電話番号の情報提供システム
１１ 網インタフェース部
１２ メッセージ交換制御部
１３ 電話番号調査判定部
１４ 電話番号履歴生成部
１５ 電話番号履歴データベース
１９ ホームゲートウェイ（ＨＧＷ）
２０ 発側固定ＩＭＳ網
２０ａ ＳＩＰサーバ
２１ ＩＢＣＦ（Ｉnter-connection Ｂorder Ｃontrol Ｆunction）
２２ ＢＧＣＦ（Ｂreakout Ｇateway Ｃontrol Ｆunction）
３０ 着側固定ＩＭＳ網
３０ａ ＳＩＰサーバ
３１ ＩＢＣＦ（Ｉnter-connection Ｂorder Ｃontrol Ｆunction）
３２ ＢＧＣＦ（Ｂreakout Ｇateway Ｃontrol Ｆunction）
４１ メタル収容装置
５１ メタル収容装置
６０ メタルＩＰ電話端末
６０ａ メタルＩＰ電話端末
６０ｂ メタルＩＰ電話端末
９０ ユーザ端末
１００ 電話番号の情報提供システム
【要約】
【課題】事業者間相互接続にＩＭＳ相互接続インタフェースなどを利用してＩＭＳ網における電話番号の使用状況を判定する。
【解決手段】電話番号の調査装置１０は、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続され、調査対象のメタルＩＰ電話端末６０に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して（調査対象のメタルＩＰ電話端末６０へと向けて）発側固定ＩＭＳ網２０にＩＮＶＩＴＥリクエストを送信するとともに、少なくとも発側固定ＩＭＳ網２０を介して応答メッセージを受信し、応答メッセージに応じて調査対象のメタルＩＰ電話端末６０の電話番号の使用状況を判定する。
【選択図】図１
【解決手段】電話番号の調査装置１０は、発側固定ＩＭＳ網２０に接続されている複数のメタルＩＰ電話端末（６０ａ）に発側固定ＩＭＳ網２０を介して接続され、また、着側固定ＩＭＳ網３０に接続されている複数のメタルＩＰ電話端末（６０ｂ）に発側固定ＩＭＳ網２０を介して接続され、調査対象のメタルＩＰ電話端末６０に対するＩＮＶＩＴＥリクエストにＳＤＰパラメータを付与して（調査対象のメタルＩＰ電話端末６０へと向けて）発側固定ＩＭＳ網２０にＩＮＶＩＴＥリクエストを送信するとともに、少なくとも発側固定ＩＭＳ網２０を介して応答メッセージを受信し、応答メッセージに応じて調査対象のメタルＩＰ電話端末６０の電話番号の使用状況を判定する。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
