JP4264016B2

JP4264016B2 - 通信制御装置及び通信制御装置におけるフィルタリング方法

Info

Publication number: JP4264016B2
Application number: JP2004082752A
Authority: JP
Inventors: 貴史宮本; 聡史清藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-03-22
Filing date: 2004-03-22
Publication date: 2009-05-13
Anticipated expiration: 2024-03-22
Also published as: US7738442B2; CN1674586A; JP2005269534A; US20050232229A1

Description

本発明は、通信制御装置及び通信制御装置におけるフィルタリング方法に係り、特に、インターネットプロトコルに準拠した複数の通信端末がＬＡＮネットワークに接続されてＩＰ（Internet Protocol）ネットワークが形成され、そのＩＰネットワークの最小構成単位（ドメイン）毎に、複数の通信端末の制御機能として、インタラクティブ通信のセッションの開始、終了および変更を制御する通信制御装置及びフィルタリング方法に関する。

企業内通信インフラのＩＰベースへの統合、ＶｏＩＰ（Voice over IP）の台頭から、通信制御装置の需要が着実に伸びてきている。この中で悪意呼やトラヒック負荷の増大は容易に考えられる問題であり、これらを規制する手法（フィルタリング）は確実に重要な位置にある機能である。

現状のＩＰ通信におけるフィルタリングでは、第一に、発信者／着信者のワンセットで考えたフィルタリング方式が知られている。つまり、着信者を主体で見て、着信したくない発信者からのメッセージを拒否する方式である。従来方式は、例えば、受信したＩＰパケットのヘッダ部から発信者ＩＰアドレス及び着信者ＩＰアドレス情報を参照し、フィルタテーブル上のエントリを検索し、該当するエントリが検出された場合、そのＩＰパケットを破棄（又は通過）するというものである。

しかし、上記フィルタテーブルは、時間指定による設定ができないという課題があった。特許文献１では、特定時間内だけ適用するように、フィルタテーブルのエントリを設定することで、ネットワーク内のＩＰパケットの流れを時間毎に制御することを可能としたインターネットプロトコルフィルタリング装置等が開示されている（例えば特許文献１参照）。

また、第二に、登録ユーザ以外からのメッセージを規制するフィルタリング方式が知られている。登録ユーザであるかどうかは、そのユーザを一意に示すもの（例えばＩＰアドレスなどの識別子）で認識する。例えば、通信制御装置内部にアドレス管理表を用意し、ＩＰアドレス及びポート番号の組を登録したＩＰパケットのみを通過させるＩＰパケットフィルタリングを行う「ＩＰ転送網を用いた端末間通信接続制御方法」が開示されている（例えば、特許文献２参照）。上記から明確なように、従来のフィルタリング方法は、ＩＰおよびトランスポートレイヤでのフィルタリングが一般的である。

また、クライアント側の機能として、着信者でもフィルタリング設定が可能な方式が開示されている（例えば、特許文献３参照）。そして、不特定多数の人に無差別的、又は、大量のメールが発信されるような場合に、所定数以上のメールを送信するユーザのメールアドレスにより、メールサービスの配信停止を行う迷惑メールフィルタリングが記載された文献がある（例えば、特許文献４参照）。また、迷惑メール内容文中のＵＲＬや電話番号を抽出して格納し、メール利用者へ送られてくるメールに対して、格納されているＵＲＬや電話番号がそのメールに含まれていないか判断することで、送信先のメールアドレスが変わっても迷惑メールをフィルタリングすることができる方式が開示されている（例えば、特許文献５参照）。なお、ＴＳＳ（time sharing system）セッションに関し、グループ毎の開設可能セッション数に従い、セッション開設制御を行う方式が開示されている（例えば、特許文献６参照）。
特開２００２−２３２４５３号公報特開２００２−３１４５７７号公報特開平８−２５１２３１号公報特開２００３−８７３２７号公報特開２００３−２６３３９１号公報特開平３−５２０５５号公報

上述した第一のフィルタリング方式では、発信者／着信者のワンセットのエントリが大量に登録されることになり、例えばユーザ数４００００人で考えた場合、単純計算で４００００×３９９９９のエントリ数となることもある。検索処理はコンピュータによるものであるが処理速度が低下し、また、オペレータ（人）による管理が煩雑になる。例えば、エントリの追加や削除などをオペレータが行うため、量が多いほど設定ミスの影響範囲が大きい。また、予期せぬ発信者からのメッセージを好まず限られた少数ユーザとのみ通信を行いたい着信者がいた場合、上述した前者のフィルタリング方式で対応するにはエントリ数が多くなりすぎるため、人による管理がさらに煩雑になる。

また、上述した第一のフィルタリング方式は、そのフィルタリング方式を有する通信制御装置のオペレータが設定を行うが、着信者が主体であるならば着信者自身も設定可能であるとなお良い。特許文献３では、着信者でもフィルタリング設定が可能な方式を示しているが、クライアント側の機能であり、サーバ側でフィルタリング設定要求を受信し、処理をするような方式は示していない。また、特許文献１及び２では、これらの課題に対応できていない。

上述した第二のフィルタリング方式では、多種類サービスの提供が可能な通信制御装置で、第二のフィルタリング方式を使用する場合、登録ユーザなら全サービス利用可能となる。あるサービスは利用可能だが、他のサービスは利用不可といった柔軟な対処ができない。柔軟な対処ができれば、第二のフィルタリング方式よりも、明らかにトラヒック負荷軽減、通信制御装置の処理負荷軽減を見込むことができる。
さらに、ＳＩＰ（Session Initiation Protocol）を用いた通信では、同一発信者からの同時セッション数も契約に応じて規制することが必要な場合もある。

また、従来のフィルタリングはＩＰアドレスによるものが多い。この場合、ＩＰアドレス、つまり「ユーザの使用機器」単位のフィルタリングと考えることができる。サービスを利用するのは”機器”でなく”ユーザ”であるから、通信サービスにおける発着信フィルタリングは「ユーザ」単位で行うことが本質的である。さらに、モバイル環境のようなＩＰアドレスが動的に変更するような環境においては、従来方式では対応しきれない。特許文献４に示されるような迷惑メールフィルタリングにおいて、メールアドレスによりフィルタリングを実現しているが、あくまで”メールサービス”という一つの特定サービスにおけるフィルタリングにすぎない。また、特許文献５に示される迷惑メールフィルタリングは、ＵＲＬ、電話番号といったユーザの使用機器を対象としてフィルタリングするものである。

本発明は、以上の点に鑑み、通信事業者がエンドユーザに複数サービスを提供する際、エンドユーザ毎に特定のサービス機能のみを提供することが可能な通信制御装置及びフィルタリング方法を提供することを目的とする。さらに、本発明は、発信フィルタリング及び着信フィルタリングにより、さらなるトラヒック負荷軽減および通信制御装置の処理負荷をも軽減することを可能とすることを目的とする。また、本発明は、アプリケーションレイヤでフィルタリングし、ユーザ単位でのメッセージをフィルタリングする通信制御装置及びフィルタリグ方法を提供することを目的とする。本発明は、ＳＩＰをプロトコルとして用いる通信制御装置において、同時セッション数に基づいてフィルタリングすることを目的とする。さらに、本発明は、インターネット上でセッションという論理的なリソースを制御するＳＩＰサーバで、一元的にセッションの確立の制御を可能とすることを目的とする。

また、本発明は、着信フィルタリングテーブルを着信者１人につき１エントリで構成された、人による管理が行いやすい通信制御装置及びフィルタリング方法を提供することを目的とする。また、本発明は、予期せぬ発信者からのメッセージを好まず限られた少数ユーザとのみ通信を行いたい着信者がいる場合にも、着信フィルタリングテーブルのエントリ数が少なくて済むような構成とすることを目的とする。さらに、本発明は、ユーザ自身が着信フィルタリングテーブルの設定が可能とすることを目的とする。

上述の第一のフィルタリング方式の課題について、着信フィルタリングテーブルの主キーを着信者の識別子のみとし、着信許可／拒否の判別カラムを設け、以降のカラムで着信許可／拒否する発信者を記述する着信フィルタリング方式を提供する。また、着信フィルタリング方式を有する通信制御装置において、ユーザ自身がフィルタリングテーブルに設定するためのメッセージを受信したとき、着信フィルタリングテーブルに登録を行う処理を追加することで解決する。また、上記のエントリをアプリケーションレイヤのメッセージヘッダの情報で構成することで従来のＩＰ／トランスポートレイヤのフィルタリングではなくアプリケーションレイヤでフィルタリングを行うことができる。これにより、ＩＰアドレス、つまり「ユーザの使用機器」単位のフィルタリングでなく「ユーザ」単位でのフィルタリングを行うことができる。

上述の第二のフィルタリング方式の課題について、発信フィルタリングテーブルに各サービスの利用許可／拒否の判別カラムを設けることで、登録ユーザでもサービスごとに規制を加える発信フィルタリング方式で解決する。また、上記のエントリをアプリケーションレイヤのメッセージヘッダの情報で構成することで従来のＩＰ／トランスポートレイヤのフィルタリングではなくアプリケーションレイヤでフィルタリングを行うことができる。

本発明の第一の解決手段によると、
複数の通信端末が接続されるＩＰネットワークにおいて、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）をプロトコルとして使用して前記複数の通信端末間のインタラクティブ通信のセッションを制御し、及び、１台で複数のサービスを提供する通信制御装置であって、
発信ユーザを特定するための発信者ＳＩＰ−ＵＲＩ（ＳＩＰ−ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）に対応して、複数の各サービスを発信者が利用可能か又は利用不可能かを示す契約サービス情報と、発信者が確立することのできる最大セッション数情報とが予め記憶される発信フィルタテーブルと、
着信ユーザを特定するための着信者ＳＩＰ−ＵＲＩに対応して、着信の許可又は拒否を示す着信可否情報と、着信可否情報に従って着信を許可又は拒否する発信者を特定するためのひとつ又は複数の発信者ＳＩＰ−ＵＲＩとが予め記憶される着信フィルタテーブルと、着信者ＳＩＰ−ＵＲＩに対応して、着信先の前記通信端末のアドレス情報が記憶された位置情報テーブルと、前記発信フィルタテーブル及び前記着信フィルタテーブルを参照して、前記通信端末から受信したメッセージをフィルタリングする通信制御部とを備え、前記通信制御部は、発信者ＳＩＰ−ＵＲＩと、着信者ＳＩＰ−ＵＲＩと、利用されるサービスに応じたサービス種別情報とを含むメッセージを前記通信端末から受信し、受信されたメッセージに含まれる発信者ＳＩＰ−ＵＲＩに基づき、前記発信フィルタテーブルを参照し、発信者ＳＩＰ−ＵＲＩに対応する契約サービス情報に従い、メッセージに含まれるサービス種別情報が示すサービスの利用可否を判断し、及び、発信者ＳＩＰ−ＵＲＩに対応する最大セッション数情報とその発信者が確立しているセッション数とを比較し、新たなセッションの確立可否を判断し、受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに基づいて、前記着信フィルタテーブルを参照し、着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに対応する着信可否情報に従い、当該発信者から着信者への着信の可否を判断し、
受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩに基づいて、前記位置情報テーブルを参照し、着信者ＳＩＰ−ＵＲＩに対応するアドレス情報を取得し、
サービスの利用可否及びセッションの確立可否及び着信の可否の判断結果に従い、取得されたアドレス情報に基づき受信されたメッセージを着信者の通信端末へ送信する、又は、受信されたメッセージを破棄する前記通信制御装置が提供される。

本発明の第二の解決手段によると、
複数の通信端末が接続されるＩＰネットワークにおいて、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）をプロトコルとして使用して複数の通信端末間のインタラクティブ通信のセッションを制御し、及び、１台で複数のサービスを提供する通信制御装置におけるフィルタリング方法であって、
発信者ＳＩＰ−ＵＲＩ（ＳＩＰ−ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）と、着信者ＳＩＰ−ＵＲＩと、利用されるサービスに応じたサービス種別情報とを含むメッセージを通信端末から受信し、受信されたメッセージに含まれる発信者ＳＩＰ−ＵＲＩに基づき、発信ユーザを特定するための発信者ＳＩＰ−ＵＲＩに対応して、複数の各サービスを発信者が利用可能か又は利用不可能かを示す契約サービス情報と、発信者が確立することのできる最大セッション数情報とが予め記憶される発信フィルタテーブルを参照し、発信者ＳＩＰ−ＵＲＩに対応する契約サービス情報に従いメッセージに含まれるサービス種別情報が示すサービスの利用可否を判断し、及び、発信者ＳＩＰ−ＵＲＩに対応する最大セッション数情報とその発信者が確立しているセッション数とを比較し、新たなセッションの確立可否を判断し、受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに基づいて、着信ユーザを特定するための着信者ＳＩＰ−ＵＲＩに対応して、着信の許可又は拒否を示す着信可否情報と、着信可否情報に従って着信を許可又は拒否する発信者を特定するためのひとつ又は複数の発信者ＳＩＰ−ＵＲＩとが予め記憶される着信フィルタテーブルを参照し、着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに対応する着信可否情報に従い、当該発信者から着信者への着信の可否を判断し、受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩに基づいて、着信者ＳＩＰ−ＵＲＩに対応して通信端末のアドレス情報が記憶された位置情報テーブルを参照し、着信者ＳＩＰ−ＵＲＩに対応するアドレス情報を取得し、
サービスの利用可否及びセッションの確立可否及び着信の可否の判断結果に従い、取得されたアドレス情報に基づき受信したメッセージを着信者の通信端末へ送信する、又は、該メッセージを破棄する前記フィルタリング方法が提供される。

本発明によると、着信者１人につき１エントリとなるため、着信者／発信者の対応が一つ一つエントリとして登録されるよりも、人による管理が行いやすい通信制御装置を提供することができる。また、本発明によると、予期せぬ発信者からのメッセージを好まず限られた少数ユーザとのみ通信を行いたい着信者についても、エントリ数が少なくて済む。さらに、本発明によると、ユーザ自身が着信フィルタリングテーブルの設定が可能である。

また、本発明の発信フィルタリング方式によると、通信事業者が本発明の発信フィルタリング方式を有した通信制御装置を使用してエンドユーザに複数サービスを提供する際、特定のサービス機能のみの提供といった、エンドユーザ毎のコスト事情に合わせたサービス提供が可能である。さらに、本発明によると、さらなるトラヒック負荷軽減および通信制御装置の処理負荷をも軽減することを可能となる。

本発明によると、アプリケーションレイヤでフィルタリングし、ユーザ単位でのメッセージをフィルタリングする通信制御装置及びフィルタリグ方法を提供することができる。また、本発明によると、ＳＩＰをプロトコルとして用いる通信制御装置において、同時セッション数に基づいてフィルタリングすることができる。さらに、本発明によると、インターネット上でセッションという論理的なリソースを制御するＳＩＰサーバで、一元的にセッションの確立の制御を可能なる。

本発明の着信フィルタリング方式および発信フィルタリング方式においては、ＳＩＰヘッダの情報から各フィルタリングテーブルを作成することで、ＳＩＰレイヤ（アプリケーションレイヤ）でのフィルタリングが可能である。このことから、ＩＰアドレス、つまり「ユーザの使用機器」単位のフィルタリングでなく「ユーザ」単位でのフィルタリングを行うことができる。そして、本発明によると、ユーザが複数機器を利用する場合でも、フィルタリングテーブルのエントリ更新は不要であるし、機器のＩＰアドレスが動的に変動するモバイル環境などにも対応可能である。

以下に、図面を参照して、本発明の実施の形態について説明する。
本実施の形態では、ＳＩＰによる通信形態を使用する。ＳＩＰではＳＩＰ−ＵＲＩ（SIP-Uniform Resource Identifier）と呼ばれる識別子が通信端末ユーザごとに与えられる。ＳＩＰ−ＵＲＩは、例えばｓｉｐ：Ｕｓｅｒ＠ｔｅｓｔ．ｃｏｍのように表される。

図１は、本実施の形態の全体構成を示す図である。通信制御装置２は、ＩＰインタフェース部３と、通信制御部４と、発信フィルタテーブル５と、着信フィルタテーブル６と、位置情報テーブル７とを備える。複数の通信端末１が、ＩＰネットワークを介して通信制御装置２（ＳＩＰサーバ）のＩＰインタフェース部３に繋がる構成となる。複数の通信端末のお互いが通信するために通信制御装置２が存在する。

本実施の形態は、２種類のフィルタリング方式を示している。１つは、発信フィルタリング方式で、発信者の通信利用規制（以下、フィルタリングと称する）を行う方式である。通信制御装置２は、発信フィルタテーブル５のエントリを参照して通信の可否を判断する。もう１つは、着信フィルタリング方式で、発信者／着信者の組み合わせで、フィルタリングを行う方式である。通信制御装置２は、着信フィルタテーブル６のエントリを参照して通信の可否を判断する（図１細線）。

通信端末１間の通信の流れの概略を説明する。まず、フィルタリングされない通信の流れを説明する。
発側の通信端末１（例えば、端末１ｃ）が他の通信端末（例えば、端末１ｄ）にメッセージを送信すると、まず通信制御装置２がＩＰインタフェース部３を介して該メッセージ受信する。そのメッセージは通信制御部４に渡され、通信制御部４は発信フィルタテーブル５を参照・着信フィルタテーブル６を参照・位置情報テーブル７を参照する。

発信フィルタテーブル５に通信端末１ｂユーザのフィルタリングのエントリがなく、着信フィルタテーブル６に通信端末１ｃユーザから通信端末１ｄユーザへの通信のフィルタリングのエントリがない場合、通信制御部４は、通信端末１ｄユーザのＳＩＰ−ＵＲＩ（Ｄ＠ｔｅｓｔ．ｃｏｍ）からＩＰアドレスを位置情報テーブル７で解決し、該メッセージを着側の通信端末１ｄに送る。

ここで、位置情報テーブル７とは、通信端末のアドレスを解決するためのものであり、本実施の形態においては、例えばＳＩＰ−ＵＲＩからＩＰアドレスを解決するためのテーブルである。位置情報テーブル７は従来と同様のものであるが、説明の便宜上、図に示している。

次に、フィルタリングされる通信の流れの概略を説明する。
例えば、通信端末１ａが通信端末１ｂへメッセージを送信すると、通信制御装置２の通信制御部４は、上述と同様にメッセージを受信し、発信フィルタテーブル５を参照する。発信フィルタテーブル５に通信端末１ａユーザのフィルタリングのエントリがある場合、このメッセージは通信制御装置２で破棄され、通信端末１ｂまで届かない（発信フィルタリング、図１太線）。また、通信制御装置２は通信端末１ａに対し、フィルタリングした旨通知する。

また、例えば、通信端末１ｂが通信端末１ｃへメッセージを送信すると、通信制御部４は、上述と同様にメッセージを受信し、発信フィルタテーブル５を参照し、発信フィルタテーブル５に通信端末１ｂユーザのフィルタリングのエントリがなければ、次に着信フィルタテーブル６を参照する。着信フィルタテーブル６に通信端末１ｂユーザから通信端末１ｃユーザへの通信拒否のフィルタリングのエントリがある場合（又は、通信許可のエントリがない場合）、このメッセージは通信制御装置２で破棄され、通信端末１ｃまで届かない（着信フィルタリング、図１破線）。また、通信制御装置２は通信端末１ｂに対し、フィルタリングした旨通知する。
以上は、単純な処理の流れを説明しており、詳細については後述する。

図２は、発信フィルタテーブル５の構成およびデータの登録例を示す図である。発信フィルタテーブル５は、発信フィルタリングを行うときに参照されるテーブルである。発信フィルタテーブル５は、発信者識別子に対応して、契約サービス情報及び契約最大セッション数をカラムとして有するテーブルである。発信者識別子カラムは、発信者を一意に表す識別子であり、本実施の形態ではＳＩＰ−ＵＲＩを指す。

契約サービス情報カラムは、ユーザが利用可能なサービス・利用不可能なサービスの分類のことである。図２に示すように、２進数における各ビット（０又は１）がサービスの利用可／不可を表している。例えば、本実施の形態は、本実施の形態においては、“１”が利用可、“０”が利用不可を示す。テーブルには各サービスの利用可／不可を表したビットが並べられた２進数が１０進数化された値が、予め登録される。通信制御装置２は、例えばＶｏＩＰ（Voice Over IP：ＩＰ音声通話）サービス、プレゼンスサービス（相手ユーザの状態を知ることができる）、ＩＭ（Instant Message：簡易メッセージのやり取り）サービスの３サービスを提供するとし、契約サービスカラムの２進数において、１ビット目をＶｏＩＰサービス、２ビット目をプレゼンスサービス、３ビット目をＩＭサービスとする。ここで、例えば、ＳＩＰ−ＵＲＩがＴＡＲＯ＠ｔｅｓｔ．ｃｏｍであるユーザが、ＶｏＩＰサービスのみ利用可能であるとき、図示のように、契約サービスカラムには“００１_（２）”が１０進数化された“１_（１０）”が予め登録される。

契約最大セッション数カラムは、そのユーザが一度に張ることができるセッションの最大数を示す。サービスごとという分類は無く、純粋なセッション数の合計を指す。ユーザとの契約に応じたセッション数が予め登録される。

図３は、着信フィルタテーブル６の構成およびデータの登録例を示す図である。着信フィルタテーブル６は、着信フィルタリングを行うときに参照されるテーブルである。着信フィルタテーブル６は、着信者識別子に対応して、許可／拒否情報（着信可否情報）・許可／拒否数Ｎ・発信者識別子１、発信者識別子２、・・・、発信者識別子Ｎをカラムとして有する。着信者識別子カラムは、着信者を一意に表す識別子であり、本実施の形態ではＳＩＰ−ＵＲＩを指す。

許可／拒否情報カラムは、着信者が発信者識別子カラムに記憶される発信者からのメッセージ着信を許可するか、拒否するかを示す。例えば、許可なら“ａｌｌｏｗ”、拒否なら“ｄｅｎｙ”で表すことができる。なお、これ以外にも、許可／拒否を示す適宜の情報・識別子等を用いることもできる。また、着信を許可／拒否する発信者については以降の発信者識別子カラムに指定することになる。

許可／拒否数Ｎカラムは、許可／拒否する発信者の数を表す。前記許可／拒否カラムの指定が“ａｌｌｏｗ”なら着信許可する発信者の数を、“ｄｅｎｙ”なら着信拒否する発信者の数を表す。

発信者識別子１カラム・発信者識別子２カラム・・・発信者識別子Ｎカラムは、許可／拒否数Ｎカラムで指定した数の分、それぞれ発信者のＳＩＰ−ＵＲＩが予め登録される。許可／拒否数Ｎカラムの値が１０なら、発信者識別子は１０個指定される。なお、端末からの登録メッセージを受信することにより、発信者識別子の追加、削除、変更も可能である。

図４は、通信制御装置２の構成図である。図４を参照して、発信フィルタリング方式・着信フィルタリング機能を持つ通信制御装置２の構成について説明する。
ＩＰインタフェース部３は、通信端末１からのメッセージ（ＩＰパケット）を受信する部分であり、および、通信端末１へメッセージ（ＩＰパケット）を送信する部分である。

通信制御部４は、プロトコルスタック部８、処理ルーチン部９、発信フィルタ管理部１０、着信フィルタ管理部１１、位置情報管理部１２を有する。本実施の形態において、プロトコルスタック部８はＳＩＰプロトコルスタックであり、ＳＩＰプロトコルに準拠した通信を制御する。処理ルーチン部９は、渡されたメッセージメソッド（例えば、ＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、ＩＮＶＩＴＥなど）に応じて、予め定められた処理シナリオを決定し、フィルタリング処理を行うよう、発信フィルタ管理部１０、着信フィルタ管理部１１、位置情報管理部１２に指示する。

発信フィルタ管理部１０は、発信フィルタテーブル５を参照し、参照結果を処理ルーチン部９へ返す。着信フィルタ管理部１１は、着信フィルタテーブル６を参照し、参照結果を処理ルーチン部９へ返す。位置情報管理部１２は、位置情報テーブル７を参照してアドレス解決を行い、結果を処理ルーチン部９へ返す。位置情報管理部１２は、位置情報テーブル７同様、従来と同様のものを用いることができるので、詳細な説明を省略する。
なお、発信フィルタテーブル５、着信フィルタテーブル６、位置情報テーブル７の説明は上述の通りである。

図５は、本実施の形態におけるメッセージのヘッダ構成の説明図である。本実施の形態では、通信端末１同士はＳＩＰによる通信を行うため、ＩＰヘッダ・レイヤ４ヘッダ・ＳＩＰヘッダを有する構成になる。本実施の形態では、ＳＩＰヘッダの情報に基づきフィルタリングを行う。参照するのは、Ｒｅｑｕｅｓｔ−ＵＲＩ、ＴｏおよびＦｒｏｍヘッダである。Ｒｅｑｕｅｓｔ−ＵＲＩは図に示す通り、例えば“ＩＮＶＩＴＥｓｉｐ：Ａ２＠ｔｅｓｔ．ｃｏｍ”と記述され、メッセージの種別（“ＩＮＶＩＴＥ”の部分）の情報が得られる。Ｔｏヘッダは、図に示す通り、例えば“＜ｓｉｐ：Ａ２＠ｔｅｓｔ．ｃｏｍ＞”と記述され、着信者ＳＩＰ−ＵＲＩの情報が得られる。Ｆｒｏｍヘッダは、図に示す通り、例えば“＜ｓｉｐ：Ａ１＠ｔｅｓｔ．ｃｏｍ＞”と記述され、発信者ＳＩＰ−ＵＲＩの情報が得られる。

図６は、発信及び着信フィルタリングのフローチャートである。図６を参照して、メッセージを受信し、メッセージの送信に至るまでの処理の流れについて説明する。
まず、通信端末１からメッセージが送信されると、通信制御装置２の通信制御部４が、ＩＰネットワーク及びＩＰインタフェース部３を介して、そのメッセージを受信する（Ｓ６０１）。このとき、例えば、通信端末１はＶｏＩＰサービスを利用するとし、メッセージのＳＩＰヘッダが、Ｒｅｑｕｅｓｔ−ＵＲＩ：ＩＮＶＩＴＥＪＩＲＯ＠ｔｅｓｔ．ｃｏｍ、Ｆｒｏｍ：ｓｉｐ：ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ、Ｔｏ：ｓｉｐ：ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍである例として説明する。なお、例えば通信制御部４は、受信したメッセージを解析してこれら所定の情報を抽出する。

次に、プロトコルスタック部８を介して処理ルーチン部９がメッセージを認識し、発信フィルタ管理部１０に対し発信フィルタテーブル５を参照するように指示をする（Ｓ６０２）。発信フィルタ管理部１０は、Ｆｒｏｍヘッダを検索キーにして、発信フィルタテーブル５を参照し、発信フィルタテーブル５にｓｉｐ：ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍのＩＮＶＩＴＥ送信をフィルタリングするエントリがあるかを判別する（Ｓ６０３）。例えば、発信フィルタ管理部１０は、発信者識別子カラムを参照してＦｒｏｍヘッダが示す発信者識別子を検索し、該当する発信者識別子に対応する契約サービス情報を取得して、取得した契約サービス情報がＶｏＩＰサービスを利用可能であることを示すか判別する。すなわち、発信フィルタ管理部１０は、取得した契約サービス情報がＶｏＩＰ利用可能を示す、「１、３、５、７」のいずれか（２進数で１ビット目が１である値のいずれか）であれば、発信許可と判別し、一方契約サービス情報がそれ以外、又は、発信者識別子がない場合、発信不可と判別する。また、発信フィルタ管理部１０は、判別結果を処理ルーチン部９に返信する。

ところで上記で、発信フィルタテーブル５の契約サービス情報には、ＶｏＩＰサービス・プレゼンスサービス・ＩＭサービスの利用可／不可が登録されると記述した。ここで、ＶｏＩＰサービスではセッション確立のためにＩＮＶＩＴＥメッセージの送信が必要であること、プレゼンスサービスでは同じくセッション確立のためにＳＵＢＳＣＲＩＢＥメッセージの送信が必要であること、ＩＭサービスではＭＥＳＳＡＧＥメッセージのやり取りになることから、本実施の形態ではそれぞれのサービスを発信フィルタリングすることを、それぞれＩＮＶＩＴＥメッセージ、ＳＵＢＳＣＲＩＢＥメッセージ、ＭＥＳＳＡＧＥメッセージを発信フィルタリングすることと同義と考える。本実施の形態では、この３種のメッセージを、ＳＩＰヘッダのＲｅｑｕｅｓｔ−ＵＲＩに基づき判別し、フィルタリングを行う。

また、通信制御部４は、セッション数に基づく発信フィルタリングを行うこともできる。例えば、通信制御部４は、受信されたメッセージに含まれる発信者識別子に基づき発信フィルタテーブル５を参照し、発信者識別子に対応する最大セッション数情報を取得する。通信制御部４は、その発信者が確立しているセッション数が、取得された最大セッション数に等しい場合に、又は、新たにセッションを張ることによりその発信者が確立するセッション数が取得された最大セッション数を超える場合に、発信不可と判断する。なお、通信制御部４は、上述の契約サービス情報に従って判断した判断結果に関係なく、発信不可と判断することができる。

発信フィルタ管理部１０が発信不可と判断した場合（Ｓ６０３）、通信制御装置２は、ｓｉｐ：ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ、つまり発信者通信端末１に対しエラー応答を送信する（Ｓ６０４）。また、通信制御装置２は、メッセージを破棄し処理を終了する。一方、発信許可の場合は（Ｓ６０３）、着信フィルタ管理部１１が着信フィルタテーブル６を参照する処理に移る（Ｓ６０５）。なお、発信フィルタ管理部１０の処理終了後、着信フィルタ管理部１１による処理を開始させるなどの処理の流れは処理ルーチン部９が管理することができる。

次に、着信フィルタ管理部１１は、Ｔｏヘッダを検索キーにして、着信フィルタテーブル６を参照し、ｓｉｐ：ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍからｓｉｐ：ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍのメッセージ着信をフィルタリングするエントリがあるかを判別する（Ｓ６０６）。例えば、着信フィルタ管理部１１は、着信者識別子カラムを参照してＴｏヘッダが示す着信者識別子を検索する。また、着信フィルタ管理部１１は、該当する着信者識別子に対応する発信者識別子１〜Ｎを参照して、Ｆｒｏｍヘッダが示す発信者識別子を検索する。該当するエントリがある場合、着信フィルタ管理部１１は、該当する着信者識別子に対応した許可／拒否情報に従い、着信許可／拒否を判断する。一方、該当するエントリがない場合、該当する着信者識別子に対応した許可／判断情報と逆の判断をする。また、着信フィルタ管理部１１は、判断結果を処理ルーチン部９に返信する。

通信制御装置２は、着信フィルタ管理部１１の判断結果が着信拒否を示す場合は（Ｓ６０６）、ｓｉｐ：ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ、つまり発信者通信端末１に対しエラー応答を送信する（Ｓ６０７）。また、通信制御装置２は、メッセージを破棄し処理を終了する。一方、着信許可を示す場合は（Ｓ６０６）、位置情報管理部１２が位置情報テーブル７を参照し、Ｔｏヘッダから宛先ＩＰアドレスを解決する（Ｓ６０８）。例えば位置情報管理部１２は、ＴｏヘッダのＳＩＰアドレスに対応したＩＰアドレスを位置情報テーブル７から取得する。

位置情報テーブル７に該エントリが無く、ＩＰアドレスを解決できない場合（Ｓ６０９）、通信制御装置２はｓｉｐ：ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ、つまり発信者通信端末１に対しエラー応答を送信する（Ｓ６１０）。一方、位置情報テーブル７に該エントリがあり、ステップＳ６０８でアドレス解決できた場合（Ｓ６０９）、通信制御装置２は、メッセージをｓｉｐ：ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍに対応するＩＰアドレス（ステップＳ６０８で得られたＩＰアドレス）、つまり着信者通信端末１に送信する（Ｓ６１１）。

図７は、発信フィルタリングの動作例を示す図である。図７を参照して、メッセージを受信し、発信フィルタリングに至るまでの処理の例について説明する。
前提として、図に示す通り、発信フィルタテーブル５には、ＳＩＰ−ＵＲＩがＴＡＲＯ＠ｔｅｓｔ．ｃｏｍのユーザは契約サービス：１、つまり２進表示で”００１”となりＶｏＩＰサービスのみ使用可能であり、ＳＩＰ−ＵＲＩがＪＩＲＯ＠ｔｅｓｔ．ｃｏｍのユーザは契約サービス：７、つまり２進表示で”１１１”となり全サービスのみ使用可能であるとともに最大セッション数：１、つまり一度に張ることができるセッションの最大数が１であるいう情報が格納されているとする。また、説明の便宜上、着信フィルタリングについては何も設定されていないとする。

ＳＩＰ−ＵＲＩがＴＡＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ａから、任意のユーザ通信端末１に、例えばプレゼンスサービスを利用するためにＳＵＢＳＣＲＩＢＥメッセージを送信した場合、発信フィルタテーブル５の発信者識別子（ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ）に対応する契約サービス情報は、ＶｏＩＰサービスのみ使用可能を示すので、発信フィルタリングされ、通信端末１ａにはエラー応答が返ってくる（図７ａ）。

ＳＩＰ−ＵＲＩがＪＩＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｂにセッションが張られていない状態で、通信端末１ｂからＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｃに、例えばＩＮＶＩＴＥメッセージを送信した場合、発信フィルタテーブル５の発信者識別子（ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍ）に対応する契約サービス情報は全サービス利用可を示すので、セッションが張られ、正常にＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｃまでＩＮＶＩＴＥメッセージは送信される（図７ｂ）。

そのセッション解放前に、さらにＪＩＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｂから、ＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍ以外の任意の通信端末１に例えばＩＮＶＩＴＥメッセージを送信した場合、発信フィルタテーブル５の発信者識別子（ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍ）に対応する最大セッション数は１であるため、これ以上セッションを張ることができないので発信フィルタリングされ、エラー応答が返される（図７ｃ）。

このように、発信フィルタリングにより、サービス提供の可否およびセッション数の制限をすることができる。本実施の形態では、ＳＩＰ特有の同時セッション数を制限できることが特徴のひとつである。

図８は、着信フィルタリングの動作例である。図８を参照して、メッセージを受信し、着信フィルタリングに至るまでの処理の流れについて説明する。前提として、図に示す通り、着信フィルタテーブル６には、ＳＩＰ−ＵＲＩがＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍのユーザは、ＳＩＰ−ＵＲＩがＪＩＲＯ＠ｔｅｓｔ．ｃｏｍのユーザからのメッセージのみ着信許可、それ以外のユーザからの着信を拒否するエントリが格納されているとする。また、上述した通り、着信フィルタリングの処理の前に発信フィルタリングの処理が行われるが、説明の便宜上、以下に示す処理の流れでは発信フィルタリングされるようなエントリは無いものとする。

ＳＩＰ−ＵＲＩがＴＡＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ａから、ＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｃにＩＮＶＩＴＥメッセージを送信したとき、発信フィルタリングはされないが、着信フィルタテーブル６にはＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍが着信を許可する（ａｌｌｏｗ）発信者として、ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍが登録されていないため、着信フィルタリングされ、通信端末１ａにはエラー応答が返ってくる（図８ａ）。

一方、ＳＩＰ−ＵＲＩがＪＩＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｂから、ＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｃにＩＮＶＩＴＥメッセージを送信したとき、発信フィルタリングされず、また、着信フィルタテーブル６にはＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍが着信を許可する（ａｌｌｏｗ）発信者として、ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍが登録されているため、着信フィルタリングもされない。よって、正常にＳＡＢＵＲＯ＠ｔｅｓｔ．ｃｏｍの通信端末１ｃまで該ＩＮＶＩＴＥメッセージは送信される（図８ｂ）。

上記前提の着信フィルタテーブル６の設定であると、ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍ以外のユーザからのメッセージは、上述のＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ同様に着信フィルタリングされてエラー応答が返される。

図９は、通信端末１から、着信フィルタテーブル６にエントリを登録する処理の説明図である。また、図１０は、通信端末１から送信されるＲＥＧＩＳＴＥＲメッセージの例である。本実施の形態では通信端末１からＲＥＧＩＳＴＥＲメッセージを送信し、着信フィルタテーブル６にデータを登録・変更等する。

メッセージのボディ部には例えば図１０のＲＥＧＩＳＴＥＲメッセージに示すようなＸＭＬ（ｅｘｔｅｎｓｉｂｌｅｍａｒｋｕｐｌａｎｇｕａｇｅ）形式で、許可／拒否情報・許可／拒否数Ｎ・発信者ＳＩＰ−ＵＲＩ−１、・・・、発信者ＳＩＰ−ＵＲＩ−Ｎを記述する。

通信制御部４の処理ルーチン部９は、メッセージを参照して、ＲＥＧＩＳＴＥＲメッセージであることを認識すると、着信フィルタ管理部１１にそのメッセージを送信する。着信フィルタ管理部１１は、ＸＭＬ形式のメッセージを解析して着信フィルタテーブル６に登録する機能を有する。例えば、図９に示すＸＭＬ文の例では、着信フィルタ管理部１１は、着信者識別子：”ＴＡＲＯ＠ｔｅｓｔ．ｃｏｍ”、許可／拒否：”ｄｅｎｙ”、許可／拒否数：”１”、発信者識別子１：”ＪＩＲＯ＠ｔｅｓｔ．ｃｏｍ” というエントリを着信フィルタテーブル６に登録する。

また、登録する着信者識別子のエントリが既に登録されている場合、解析された許可／拒否数をエントリの許可／拒否数に加算し、及び、発信者識別子を追加するようにしてもよい。なお、既に登録されている同一の着信者識別子のエントリの許可／拒否情報が“ａｌｌｏｗ”を示し、解析された許可／拒否情報が“ｄｅｎｙ”を示すように、許可拒否情報が相反する場合等には、“ａｌｌｏｗ”又は“ｄｅｎｙ”のいずれか一方のエントリを登録するようにし、他方は削除するようにしてもよい。また、追加登録のほか、エントリの削除、変更も同様にして可能である。

登録が正常に成功した場合は、同じく通信制御部４で応答メッセージ、例えば２００ＯＫを作成し、通信端末１に返信する。また、ＸＭＬ不正の場合は、通信制御部４は、エラーメッセージ、例えば４００ＢａｄＲｅｑｕｅｓｔを返信する。

インターネットプロトコルに準拠した複数の通信端末がＬＡＮネットワークに接続されてＩＰネットワークが形成され、通信端末間でのインタラクティブ通信に関する産業に利用可能である。

本実施の形態におけるシステムの全体構成図。発信フィルタテーブルの構成およびデータの登録例を示す図。着信フィルタテーブルの構成およびデータの登録例を示す図。通信制御装置の構成図。通信パケットの構成例を示す図。発信フィルタリング、着信フィルタリングの処理フロー。発信フィルタリングの動作例を示す図。着信フィルタリングの動作例を示す図。エンドユーザ端末から着信フィルタテーブルに登録する時の説明図。登録メッセージの例を示す図。

符号の説明

１、１ａ、１ｂ、１ｃ、１ｄ：通信端末
２：通信制御装置
３：ＩＰインタフェース部
４：通信制御部
５：発信フィルタテーブル
６：着信フィルタテーブル
７：位置情報テーブル
８：プロトコルスタック部
９：処理ルーチン部
１０：発信フィルタ管理部
１１：着信フィルタ管理部
１２：位置情報管理部

Claims

複数の通信端末が接続されるＩＰネットワークにおいて、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）をプロトコルとして使用して前記複数の通信端末間のインタラクティブ通信のセッションを制御し、及び、１台で複数のサービスを提供する通信制御装置であって、
発信ユーザを特定するための発信者ＳＩＰ−ＵＲＩ（ＳＩＰ−ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）に対応して、複数の各サービスを発信者が利用可能か又は利用不可能かを示す契約サービス情報と、発信者が確立することのできる最大セッション数情報とが予め記憶される発信フィルタテーブルと、
着信ユーザを特定するための着信者ＳＩＰ−ＵＲＩに対応して、着信の許可又は拒否を示す着信可否情報と、着信可否情報に従って着信を許可又は拒否する発信者を特定するためのひとつ又は複数の発信者ＳＩＰ−ＵＲＩとが予め記憶される着信フィルタテーブルと、
着信者ＳＩＰ−ＵＲＩに対応して、着信先の前記通信端末のアドレス情報が記憶された位置情報テーブルと、
前記発信フィルタテーブル及び前記着信フィルタテーブルを参照して、前記通信端末から受信したメッセージをフィルタリングする通信制御部と
を備え、
前記通信制御部は、
発信者ＳＩＰ−ＵＲＩと、着信者ＳＩＰ−ＵＲＩと、利用されるサービスに応じたサービス種別情報とを含むメッセージを前記通信端末から受信し、
受信されたメッセージに含まれる発信者ＳＩＰ−ＵＲＩに基づき、前記発信フィルタテーブルを参照し、発信者ＳＩＰ−ＵＲＩに対応する契約サービス情報に従い、メッセージに含まれるサービス種別情報が示すサービスの利用可否を判断し、及び、発信者ＳＩＰ−ＵＲＩに対応する最大セッション数情報とその発信者が確立しているセッション数とを比較し、新たなセッションの確立可否を判断し、
受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに基づいて、前記着信フィルタテーブルを参照し、着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに対応する着信可否情報に従い、当該発信者から着信者への着信の可否を判断し、
受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩに基づいて、前記位置情報テーブルを参照し、着信者ＳＩＰ−ＵＲＩに対応するアドレス情報を取得し、
サービスの利用可否及びセッションの確立可否及び着信の可否の判断結果に従い、取得されたアドレス情報に基づき受信されたメッセージを着信者の通信端末へ送信する、又は、受信されたメッセージを破棄する前記通信制御装置。
前記通信制御部は、
前記通信端末から送信された、着信者ＳＩＰ−ＵＲＩ及び着信可否情報及びひとつ又は複数の発信者ＳＩＰ−ＵＲＩを含む登録要求メッセージを受信し、
受信されたメッセージを解析して抽出された着信者ＳＩＰ−ＵＲＩ及び着信可否情報及びひとつ又は複数の発信者ＳＩＰ−ＵＲＩを、前記着信フィルタテーブルに新たに登録する、又は、着信者ＳＩＰ−ＵＲＩ及び着信可否情報が一致するエントリに、抽出されたひとつ又は複数の発信者ＳＩＰ−ＵＲＩを追加登録する請求項１に記載の通信制御装置。
前記通信制御装置が提供する複数のサービスは、
インターネット電話サービス又はＶｏＩＰサービス、及び、プレゼンスサービス、及び、インスタントメッセージサービスのいずれか又は複数を含み、
前記サービス種別は、メッセージヘッダのＲｅｑｕｅｓｔ−ＵＲＩに含まれる、前記複数のサービスに対応する「ＩＮＶＩＴＥ」、「ＳＵＢＳＣＲＩＢＥ」及び「ＭＥＳＳＡＧＥ」のいずれかである請求項１又は２に記載の通信制御装置。
ＩＮＶＩＴＥメッセージ、ＳＵＢＳＣＲＩＢＥメッセージ、及び、ＭＥＳＳＡＧＥメッセージをフィルタリングすることにより、これらメッセージに対応した各サービス全体をフィルタリングすることと等価であることを特徴とする請求項１乃至３のいずれかに記載の通信制御装置。
複数の通信端末が接続されるＩＰネットワークにおいて、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）をプロトコルとして使用して複数の通信端末間のインタラクティブ通信のセッションを制御し、及び、１台で複数のサービスを提供する通信制御装置におけるフィルタリング方法であって、
発信者ＳＩＰ−ＵＲＩ（ＳＩＰ−ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）と、着信者ＳＩＰ−ＵＲＩと、利用されるサービスに応じたサービス種別情報とを含むメッセージを通信端末から受信し、
受信されたメッセージに含まれる発信者ＳＩＰ−ＵＲＩに基づき、発信ユーザを特定するための発信者ＳＩＰ−ＵＲＩに対応して、複数の各サービスを発信者が利用可能か又は利用不可能かを示す契約サービス情報と、発信者が確立することのできる最大セッション数情報とが予め記憶される発信フィルタテーブルを参照し、発信者ＳＩＰ−ＵＲＩに対応する契約サービス情報に従いメッセージに含まれるサービス種別情報が示すサービスの利用可否を判断し、及び、発信者ＳＩＰ−ＵＲＩに対応する最大セッション数情報とその発信者が確立しているセッション数とを比較し、新たなセッションの確立可否を判断し、
受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに基づいて、着信ユーザを特定するための着信者ＳＩＰ−ＵＲＩに対応して、着信の許可又は拒否を示す着信可否情報と、着信可否情報に従って着信を許可又は拒否する発信者を特定するためのひとつ又は複数の発信者ＳＩＰ−ＵＲＩとが予め記憶される着信フィルタテーブルを参照し、着信者ＳＩＰ−ＵＲＩ及び発信者ＳＩＰ−ＵＲＩに対応する着信可否情報に従い、当該発信者から着信者への着信の可否を判断し、
受信したメッセージに含まれる着信者ＳＩＰ−ＵＲＩに基づいて、着信者ＳＩＰ−ＵＲＩに対応して通信端末のアドレス情報が記憶された位置情報テーブルを参照し、着信者ＳＩＰ−ＵＲＩに対応するアドレス情報を取得し、
サービスの利用可否及びセッションの確立可否及び着信の可否の判断結果に従い、取得されたアドレス情報に基づき受信したメッセージを着信者の通信端末へ送信する、又は、該メッセージを破棄する前記フィルタリング方法。