JP2008543159A

JP2008543159A - Ｖｏｉｐ呼におけるｓｐｉｔの検出

Info

Publication number: JP2008543159A
Application number: JP2008513008A
Authority: JP
Inventors: ステルマン，バルフ; シュワルツ，デイビッド; カッツ，エリ
Original assignee: カヨテネットワークス，インコーポレイティド; エックスコネクトグローバルネットワークスリミティド
Priority date: 2005-05-26
Filing date: 2006-05-25
Publication date: 2008-11-27
Anticipated expiration: 2026-05-25
Also published as: EP1891782A2; EP1891782A4; WO2006126202A2; US8135022B2; WO2006126202A3; JP5437627B2; US20090067410A1; EP1891782B1

Abstract

パケット電話のための方法は、パケット通信ネットワーク（２２）上において第１の集合組織（２８）の第１のエンドユーザ（３２Ａ）が発した第１メッセージを受け取り、第２集合組織（３０）の第２のエンドユーザ（３２Ｄ）に発呼することを含む。第１メッセージに応じて、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値が割り当られる。パケット通信ネットワーク上において、第２メッセージが第２エンドユーザに向けて送られる。第２メッセージは、セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含んでいる。

Description

本発明は、一般に電話通信に関し、特にパケット電話システムにおける好ましくない呼の検出及びフィルタリングに関する。

著作権表示
本特許文献の開示の一部は著作権保護対象を含む。著作権者は特許文献又は特許開示が特許庁ファイル又は記録に現れたとしても全ての著作権が留保される限りにおいては、特許文献又は特許開示の何人による複製に対しても異議を持たない。
関連特許
本出願は西暦２００５年５月２６日出願の米国仮特許出願第６０／６８５，２３２号の特権を請求し、本願に引用して援用する。
大容量の不要なメッセージの伝送として定義される“スパム”は、インターネットメールには悩みの種である。あいにくスパムは、例えばボイスオーバー・インターネット・プロトコル（VoIP）電話といったようなユーザ対ユーザ通信を可能にするシステムに影響を及ぼす可能性がある。インターネット通信上に伝送されたスパムは通常“SPIT”と呼ばれている。

Rosenberg et alは、本願に引用して援用されるインターネットドラフト刊行物draft-ietf-sipping-spam-00（２００５年２月１３日）で“The Session Initiation Protocol (SIP）and Spam（セッション・イニシエーション・プロトコルとスパム）”でSPIT関連の問題を論じている。SIPそれ自体は、同様に本願に引用して援用される“SIP: Session Initiation Protocol（セッション・イニシエーション・プロトコル）”（２００２年６月）というタイトルのインターネットエンジニアリングタスクフォース（IETF）のRequest for Comment（RFC）３２６１でRosenberg et alが記述している。これらの文献は、以下に引用する他のインターネット関連ドラフトやRFCと同様にwww.ietf.org.でアクセス可能である。Rosenberg et alは、SIPは音声、ビデオ、インスタントメッセージ、プレゼンスを含むユーザ間マルチメディア通信に使われることを説明している。著者は、SIPネットワークは増加するスパムの格好のターゲットになるであろうと予見している。彼らはSIPを組み合わせたアイデンティティ認証においてアンチスパムのための枠組みや、“ホワイトリスト”、“コンセント・フレームワーク”、その他の技術を提案している。

多くの著者がSIPネットワークのセキュリティを強化する方法を提案してきた。例えば、Jennings et alは“Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Network（信頼あるネットワーク内で表明された同一性に対するＳＩＰへのプライベート拡張）”(２００２年１２月)というタイトルで、IETF RFC3325においてこの目的のためにSIPに適用可能な強化策を記述しており、これは本願に引用して援用される。この文献は、アイデンティティ問題への現プライバシー機構の適用だけでなく、信頼あるSIPサーバのネットワークが認証されたユーザのアイデンティティを表明するのを可能にするSIPへの個別の拡張を記述している。しかしながら、これら拡張の使用は、そのような情報の発生、移動及び使用に対し予め合意したポリシーを持った管理ドメイン内でしか適用できない。Jennings et alはこれら拡張は異なる信頼ドメイン間での使用やインターネットにおいてあまねく使用するに適した一般的なプライバシーやアイデンティティのモデルを提供するものではないと注釈をつけている。

Peterson et alは、本願に引用して援用される、インターネットドラフト刊行物draft-ietf-sip-identity-04（２００５年２月）のタイトル“Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)（SIPにおける認証された同一性の管理のための強化策）”(２００５年２月)で、ISPメッセージの発呼者を確実に確認するメカニズムを記述している。この文献では、SIPメッセージにおけるエンドユーザを確認するためのプラクティスや約束事を推奨しており、また暗号によって保護されたアイデンティティ認証を配布する方法を提案している。著者らはSIPのための間接認証アーキテクチャを記述しており、そこではユーザのローカルドメインにおけるサーバに対してリクエストが送られ、サーバはそのリクエストを認証するといったようなものである。一旦メッセージが認証されたならば、その時ローカルドメインは他のSIPエンティティに対し、送信ユーザは認証されかつ“From”のヘッダ域を使用することが認められたことを知らせる。このドラフトは、ドメイン間でのコンテキストにおけるエンドユーザSIP同一性の暗号による保証を共有する手段を特定しており、それは“認証サービス”というコンセプトや、新しいSIPヘッダ：Identityとアイデンティティ情報に基づいている。

Tschofening et alは、本願に引用して援用される、インターネットドラフト刊行物draft-tschofening-sip-saml-02（２００４年１２月）のタイトル“Using SAML for SIP(SIPのためのＳＡＭＬの利用)”(２００５年２月)で、SIPの特性に基づく認可を与えるSecurity Assertion Markup Language(SAML−セキュリティ・アサーション・マークアップ言語)の使用を記述している。特性に基づく認可においては、ユーザはアイデンティティの代わりに役割や特性を用いて認可される。SAMLはセキュリティ情報交換のためにXMLを拡張したものである。この文献ではSAMLアサーション（ステートメント）がSIPで実行される方法を定義している。アサーションは、認証ステートメント、属性ステートメント及び認可決定ステートメントを含む情報のパッケージである。アサーションは、サーバがアサーションを調べる際に用いる符号化された文字列という１つの加工品によって参照される。ソース側のサーバはそのアサーションを一時的に記憶する。宛先側のサーバは加工品を受け取り、それを用いてソース側からのアサーションを引き出す。

SPITに対抗する手段が必要であることは米国特許公開公報US2005／0281284号で強調されており、そこではVoIPメッセージをブロードキャストするシステムと方法が記述されている。その方法ではメッセージのフィルタリングやブロッキングをすり抜けるために、ランダムディレィを使用してメッセージソースの自動化された性質を変容させている。

本発明の各実施形態により、パケット電話通信から効果的にSPITをフィルタリングすることができる方法及びシステムが提供される。以下記述する各実施形態では、未知の人がパケット電話呼を開始する試みに関連し得る新しいタイプのセキュリティ属性が定義されており、ここではこれらの属性を算定して呼信号に当てるためのプロトコルも定義されている。未承認の人から呼を開始するリクエストを受け、その呼の相手となるエンドユーザ（又はエンドユーザとなる集合組織）は、セキュリティ属性に従って上記呼をフィルタリングするべく、予めセットされたポリシーを適用してもよい。

本発明の幾つかの実施形態では、セキュリティ属性が中央の信頼あるオーソリティ（以下、“アンカー”と呼ぶ）によって算定され、呼信号に当てがわれる。アンカーは、異なる“メンバーアイランド”（即ち、この目的でアンカーと提携したインターネット電話サービスプロバイダや企業のような、パケット電話トラヒックを集めて転送する組織）に属するエンドユーザ間の呼に対し責任をもってルーティングする。一方のアイランドから他方のアイランドへの呼開始リクエストを運ぶ際に、アンカーは、アンカー自身が保持する、又は推測可能な呼や発呼者や発呼側アイランドの情報に基づいてセキュリティ属性を算定する。アンカーがこれらの属性を呼信号に当てがうことにより、受呼側のアイランドやエンドユーザは、必ずしも発呼側エンドユーザやエンドユーザのアイデンティティについての特別な情報を持つことなく、その呼をフィルタリングすることができる。即ち、アンカーは、メンバーアイランドに対し複数のピアツーピア型信頼関係を確立させたり、機密のエンドユーザ情報を他のメンバーアイランドと交換させることなく、メンバーアイランド間のSPIT呼のフィルタリングを強化することができる。

以下記述する実施形態は、特にSIPを使ったインターネット電話(VoIP)呼の信号処理、及びあるセキュリティ属性を上述したようにSAMLを使ったSIP制御に組み入れる方法に関係したものである。しかしながら本発明の原理は、適宜変更を加えることで、他のプロトコルやパケットネットワーク上の他のタイプの連結型マルチメディア・コミュニケーションにも同様に適用可能である。本特許出願の明細書や請求項における便宜上、このようなマルチメディア・コミュニケーションを一般に“パケットテレフォニー（パケット電話）”と呼び、そのようなコミュニケーションにおいて使用されるエンドツーエンド接続を“呼”と呼ぶ。しかしながらこれらの用語は、単に声のコミュニケーションだけでなく、例えばビデオやインスタントメッセージのような電話ネットワーク上で共通して実行される他のメディアをも含んでいると理解されたい。

それゆえ、本発明の実施形態によれば、
第２集合組織の第２のエンドユーザに発呼するためにパケット通信ネットワーク上において第１の集合組織の第１のエンドユーザが発した第１メッセージを受け取り、
前記第１メッセージに応じて、前記第１集合組織と前記第１エンドユーザの内、少なくとも一方の１つ又はそれ以上の特性を決定し、
前記１つ又はそれ以上の特性に基づき、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値を割り当て、及び
上記パケット通信ネットワーク上において、第２エンドユーザを対象とした第２メッセージであって、前記セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含む第２メッセージを送ることを具備するパケット電話方法が提供される。

開示された実施形態では、前記第１及び第２組織は、信頼のおけるアンカーによって提供された連邦組織のメンバーアイランドであって、前記アンカーはメンバーアイランド間のパケット電話呼のルートを決め、前記方法の各ステップは信頼のおける前記アンカーによって実行される。

一実施形態では、前記呼は、ボイスオーバー・インターネット・プロトコル（VoIP）呼であり、前記第１及び第２メッセージはセッション・イニシエーション・プロトコル（SIP）に従って送信される。前記各値の前記少なくとも１つは、セキュリティ・アサーション・マークアップ言語（SAML）を使った前記第２メッセージに組み込まれてもよい。

代表例として、その方法は、各値の内の前記少なくとも１つの値に応じて前記呼を完成するか拒絶するかを決定することを有する。前記呼を完成するか拒絶するかを決定することは、前記第２メッセージに応じて前記第２集合組織と第２エンドユーザの内、少なくとも一方から発された第３のメッセージを受け取り、前記第３メッセージに応じて上記呼を完成するか拒絶するか決定することを有する。開示された実施形態において、前記呼を完成するか拒絶するかの決定は、１組の呼フィルタリングルールを前記セキュリティ属性の値に適用することを有する。

幾つかの実施形態において、前記１つ又はそれ以上のセキュリティ属性は、少なくとも１つのアイデンティティ関連属性を有し、上記１つ又はそれ以上の特性を決定することは、前記少なくとも１つのアイデンティティ関連属性を決定するために前記第１集合組織に対し前記第１エンドユーザによって提供された識別情報の信頼性を評価することを有する。１つの実施形態において、前記少なくとも１つのアイデンティティ関連の属性はアイデンティティ強度の属性を有し、この属性は前記第１集合組織によって提供された呼サービスにアクセスする際に第１エンドユーザが遭遇する難易度を示す。これに追加するか、又はその代わりとして、前記少なくとも１つのアイデンティティ関連の属性は、前記第１集合組織によって提供された呼サービスのユーザを認証する際に使用される方法のセキュリティレベルを示す認証方法属性を有する。更に、これに追加するか、又はその代わりとして、前記少なくとも１つのアイデンティティ関連の属性は、アイデンティティ・アサーション属性を有し、この属性は前記第１集合組織によって提供された呼サービスにアクセスする際に第１エンドユーザが遭遇する難易度を示す。

前記１つ又はそれ以上のセキュリティ属性は、前記第１エンドユーザが負う前記呼のコストの表示を含む。これに追加するか、又はその代わりとして、前記少なくとも１つのセキュリティ属性は、前記第１メッセージを伝達するネットワークリンクのセキュリティレベルを示すコネクションセキュリティ属性を含む。更に、これに追加するか、又はその代わりとして、前記少なくとも１つのセキュリティ属性はSPITサスペクト属性を含み、ここでは前記１つ又はそれ以上の特性を決定することは、前記呼がスパムコールである可能性を決定するべく前記第１エンドユーザが発した呼のパターンを評価することと、その可能性に応じて前記SPITサスペクト属性の値を設定することを含んでいる。更に、これに追加するか、又はその代わりとして、前記少なくとも１つのセキュリティ属性は、前記第１集合組織にあるアウトバウンドのコールセンターの作動を示すコールセンター属性を含んでいる。

開示された実施形態において、前記各値の割り当ては、それぞれの属性値にかかる重みスコアを算定することを含んでおり、前記第２メッセージの送信は、第２メッセージに前記重みスコアを組み込むことを含んでいる。

また、本発明の実施形態によれば、パケット電話のための装置であって、
パケット電話システムに含まれるエンティティの特性を格納するように配置されたメモリ；及び
前記メモリに接続されたアンカーであって、第２集合組織の第２のエンドユーザに発呼するためにパケット通信ネットワークを介して第１の集合組織の第１のエンドユーザが発した第１メッセージを受け取り、更に前記第１メッセージに応じて、前記第１集合組織と前記第１エンドユーザの内、少なくとも一方の１つ又はそれ以上の特性を決定し、前記１つ又はそれ以上の特性に基づき、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値を割り当てるように配置された前記アンカー、を有し、
前記アンカーは、上記パケット通信ネットワーク上において、第２エンドユーザを対象とした第２メッセージであって、前記セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含む第２メッセージを送るように配置されていることを特徴とするパケット電話のための装置が提供される。

加えて、本発明の実施形態によれば、プログラムインストラクションを格納するコンピュータ読み込み媒体を有すると共に、前記コンピュータに読み込まれた際には、前記インストラクションによりコンピュータが第２集合組織の第２のエンドユーザに発呼するためにパケット通信ネットワークを介して第１の集合組織の第１のエンドユーザが発した第１メッセージを受け取り、さらに前記第１メッセージに応じて、前記第１集合組織と前記第１エンドユーザの内、少なくとも一方の１つ又はそれ以上の特性を決定し、前記１つ又はそれ以上の特性に基づき、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値を割り当てるコンピュータソフトウエア製品であって、
上記インストラクションにより、コンピュータは、パケット通信ネットワークを介して、第２エンドユーザを対象とした第２メッセージであって、前記セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含む第２メッセージを送ることを特徴とするコンピュータソフトウエア製品が提供される。
図面を参照した実施形態の以下の詳細な説明から本発明は一層理解されよう。

図面を参照した実施形態の以下の詳細な説明から本発明は一層理解されよう。

図１は、本発明の実施形態によるインターネット電話のためのシステム２０を概略的に示すブロック図である。そのシステムは、例えば公共インターネットのようなパケットネットワーク２２を介してメンバーアイランド２８，３０間を接続する。本特許出願及び請求項に関連して、“アイランド”とは例えば端末３２A，３２Ｂ，３２Ｃ及び３２Ｄ，３２Ｅ，３２Ｆ（ここでは総称的に単に端末３２と呼ぶ）の組のような１組のエンドユーザ端末間においてインターネット電話トラフィックを統合する組織を指している。各端末は、例えばオーディオインターフェースや適当なソフトウエアを備えたネットワークコンピュータや専用インターネット電話のような、ＶｏＩＰ可能な電話装置からなる。各アイランド２８，３０は、例えばＳＩＰプロキシ、ＩＰ構内交換機（ＰＢＸ）、セッション・ボーダー・コントローラとして形成されたルータのような各ボーダーサーバ２４，２６によりネットワーク２２に接続される。個々のアイランドは例えば、インターネット電話サービスプロバイダ（ＩＴＳＰ）によって提供された加入者端末グループ、又は企業や大学のVoIPネットワークから構成されてもよい。図の単純化のため、図１では２つのアイランド２８，３０しか示していないが、本発明の原理を大量のアイランドからなるシステムで実現してもよい。

アイランド２８，３０は、ネットワーク２２を介して異なるアイランド間でパケット電話呼を交換するという目的で連邦組織に加入するため“メンバーアイランド”と呼ばれる。異なるメンバーアイランド間の呼は、アンカー３４を介して繋がれ、アンカーは、このルーティングと、システム２０に含まれるエンティティに関するセキュリティ関連情報とを、メモリ３６内の中央データベースに保持する。（この種の中央ルーティング権限とデータベースの他の特徴は、２００６年５月２３日出願の“Efficient Address Caching for Packet Telephony Service（パケット電話サービスのための効果的なアドレスキャッチング）”というタイトルのＰＣＴ出願に記載されており、この出願は本特許出願の譲渡人に譲渡されており、ここでは本願に引用して援用されている）代表例として、アンカー３４はコンピュータサーバからなり、それはネットワーク２２に対し適当なインターフェースを持つと共に、本願において記述する機能を実行するべくソフトウエアにプログラミング化される。このソフトウエアは、例えばネットワーク上で電子的形態をもってアンカーにダウンロードすることも可能である。或いは、又はこれに加える形で、例えば光学媒体や磁気媒体や電子メモリ媒体といったような有形のメディア上で提供されるようにしてもよい。さらに、或いは、又はこれに加える形で、幾つか又は全てのアンカー３４の機能を、それ専用又はブログラム化できるハードウエア要素によって実行するようにしてもよい。

特に、メンバーアイランドにとって互いの信頼関係を構築する必要もないし、或いは着呼の元となるメンバーアイランドを識別できることさえ必要がないという点で、信頼に足るアンカーを中央としたこの種の連邦組織は好都合である。この手の匿名性は、例えば、カスタマーベースを同じくしつつも異なるＩＴＳＰ間で競争するといった観点からは好ましいかもしれない。連邦組織外の悪質な者によるハッキングを防止するため、メンバーアイランド／アンカー間の通信が、当分野では公知のホップバイホップのデータ保全機構を使ったリンク上で行なわれることが望ましい。

アンカー３４は、発呼者について関連するセキュリティ情報を認定・表明し、かつ標準的で均一な方法で各呼毎に目標となるメンバーアイランドにその情報を伝える責任がある。連邦組織は、必ずしも各メンバーアイランドがそれ自身のエンドユーザを認証することを要求しないが、アンカーがこれに関して各メンバーアイランドのポリシー(又はポリシーがないこと)を認識していることが想定されている。各呼毎にセキュリティ属性を算定するにあたり、アンカーは、メモリ３６内に保持する発呼側メンバーアイランドのセキュリティパラメータと信頼度に関する情報を伴って、発呼側メンバーアイランドのアイデンティティ及び発呼側メンバーアイランドによって提供される発呼パーティのアイデンティティ（又は有効アイデンティティが無いこと）を用いる。アンカーは、発信メンバーアイランドやエンドユーザを必ずしも識別することなしに、これらの属性を呼信号の一部として目標メンバーアイランドに対して手渡す。このようにして、目標メンバーアイランド及び／又はエンドユーザは、その呼信号におけるセキュリティ属性に基づいて、必ずしも発呼者や発呼側メンバーアイランドの如何なる検証も受けずに呼を受け入れるか拒絶するか決定することができる。

更に、又はこの代わりとして、アンカー（又は他のシグナリングエンティティ）によるセキュリティ属性の値の評価および割り当ては、連邦組織における発呼側アイランドから自発的に提供されるメンバーシップのみに基づく必要はない。むしろアンカーは、発呼側アイランドに関して公的に入手可能な情報、或いは与えられたアイランド及び／又は該アイランド内の個々のユーザから発せられた呼のパターンから類推されるかもしれない情報に基づき、与えられた呼のセキュリティ属性を決定してもよい。更に、又はこの代わりとして、属性値を決定して呼信号の中に属性をカプセル化する方法を伴って、以下記述するセキュリティ属性を、アイランド間及び／又はエンドユーザ間の集中化されないピアツーピア信号に適用してもよい。以下には、一例としてある特定のセキュリティ属性が記述されるが、本特許出願を読んだ後においては、その他のセキュリティ属性もまた、以下に掲げた属性に加えるかその代わりに使用可能であることが本分野の当業者に明らかになるであろう。このような他のシステム形態、セキュリティ属性及びこれら属性の適用例の全てが、本発明の範囲内にある。

本発明の一実施形態に従い、システム２０の呼設定のプロセスを概略的に示した図２及び図３を参照する。図２は代表的な呼シグナリングフローを示すメッセージフロー図であり、図３は呼設定及びフィルタリング処理に含まれるプロセスのフローチャートである。本例では、呼がメンバーアイランド２８のエンドユーザ端末３２Ａから、ボーダーサーバ２４、アンカー３４及びボーダーサーバ２６を通ってメンバーアイランド３０のエンドユーザ端末３２Ｄに発せられると仮定する。図２に示す呼フロー内のメッセージは、対応するＳＩＰメッセージのタイプである（ＩＮＶＩＴＥ，４０７，２００及びＡＣＫ）。呼フローの詳細は以下の付録Ａに与えられている。

端末３２ＡはＳＩＰ・ＩＮＶＩＴＥメッセージをサーバ２４に送ることにより電話サービスプロバイダに通話を申し込む。サーバ２４は発呼者認証ステップ５０においてユーザを認証する。このステップでは、ユーザネームと、これに関連したパスワードとのマッチングのため例えばダイジェスト認証を用いてもよい。この代わりに、又はこれに加えて、例えばアクセスコントロール・リストやプライベート・トンネルのような他の技術をユーザ認証に用いるようにしてもよい。サーバは又、メンバーアイランド２８で入手可能な情報に基づきＳＩＰメッセージのヘッダ“Ｆｒｏｍ”で渡されたアイデンティティがそのユーザネームに実際に関連していることを点検することも可能である。このようにして、サーバ２４が端末２４Ａによって提供されたアイデンティティが実際に認証ユーザに登録されていることを積極的に主張し、１人のユーザが別のユーザアイデンティティを提示する，所謂アイデンティティ盗用の可能性を排除することができる。

呼中継ステップ５２では、サーバ２４は上記呼をアンカー３４へと中継する。このステップでは、仮に発呼者が自分のアイデンティティを被呼者に表示しないように要求したとしても、サーバ２４は呼を申し込んだユーザのアイデンティティ値をアンカーに渡す。サーバはこのアイデンティティ情報を、例えば、Ｐ−asserted-Identityヘッダやサーバがアンカーに送るＳＩＰ・ＩＮＶＩＴＥメッセージのアイデンティティ・ヘッダの形でアンカーに渡すことができる。これらのヘッダは、本願の上記背景技術の項で引用したJenningsやPetersonらの刊行物に記載されている。この種のヘッダの使用例は付録Ａに掲げてある。

代表例として、アンカー２４はこれらメンバーアイランド２８，３０間で背向型ユーザ・エージェント（Ｂ２ＢＵＡ）として作用する。アンカーはステップ５２で受け取ったＳＩＰメッセージを、属性決定ステップ５４で算定されるセキュリティやアイデンティティや信頼性に関する情報を含むように書き換える。発呼側メンバーアイランドや発呼側エンドユーザのポリシーに関してメモリ３６内に保持された情報と共に、アンカーは、ステップ５２でサーバ２４から渡されたデータを用いて上記情報を決定する。アンカーはこのセキュリティ情報をシステム２０内のパーティ間で標準化されたセキュリティ属性値の形で提供する。例示されるセキュリティ属性は以下の項目を含んでいる。
・アイデンティティ強度
・発呼コスト
・認証方法
・接続セキュリティ
・ SPIT嫌疑
・コールセンター
・アサーション強度
これらセキュリティ属性を算定する意味と方法については以下に詳しく記述する。アンカー３４は、これら属性の一部のみ，或いは上に掲げていない別の属性を含むものを算定してもよい。

メッセージ転送ステップ５６において、アンカー３４は、セキュリティ、アイデンティティ、信頼性情報を含むように書き換えられたＳＩＰ・ＩＮＶＩＴＥメッセージをメンバーアイランド３０のサーバ２６に転送する。メッセージは、ステップ５４において算定されたセキュリティ属性と発呼者のアイデンティティ情報（発呼者が自身のアイデンティティを隠す要求をしない場合）を含む。アンカーはメッセージ中のセキュリティ属性とアイデンティティ情報を標準的なフォーマットに挿入する。先に引用したJenningsやPetersonらの刊行物に記載されているように、アイデンティティは例えば、Ｐ−asserted-IdentityとPrivacy ヘッダの組み合わせや、アイデンティティとアイデンティティ情報ヘッダの組み合わせのいずれかで渡すようにしてもよい。

先に発明の背景において引用したTschofenigらによる刊行物に記載されているように、セキュリティ属性は、例えばSAMLアサーションを使った記述子と値の組み合わせとしてフォーマットしてもよい。この種のセキュリティ属性を含むＳＡＭＬコードのサンプルは以下の付録Ｂに提示されている。アイデンティティ・ヘッダをSIPメッセージに結合するため、Petersonらによる刊行物のセクション１０に定められたように、選択された数個のＳIPヘッダを、アイデンティティ・ヘッダ・ストリングに含まれるハッシュ値の計算に使用することができる。悪意をもったSAMLメッセージ改竄を回避するために、アンカー３４はステップ５６でセキュアリンクを使用してもよいし、或いはサーバ２６が、ＳAMLするメッセージを受けた上でこのメッセージが確かにアンカーによって送られたものであることを証明するチャレンジ・レスポンス機構を使用してもよい。

SPIT分析ステップ５８では、SPIT呼を除去するためにサーバ２６がアンカー３４からのメッセージに含まれる呼の属性を分析する。これとは別に、或いはこれに加える形で、例えば端末３２Dのようなエンドユーザ装置やサーバ２６／エンドユーザ装置間の他の装備（例えば、図示しないファイアウォールのようなもの）が、アンカー３４によって計算されたセキュリティ属性を読み込んで使用するように構成されているならば、SPIT分析やフィルタリングはボーダー・サーバの下流側で行うことも可能である。また、これとは別に、或いはこれに加える形で、メンバーアイランド及び／又は目標とするエンドユーザからの命令に基づき、アンカー３４それ自身が、メンバーアイランド３０に向けられた或る呼を除外するようにしてもよい。

典型的に、ステップ５８では、ステップ５４で決定したセキュリティ属性値が１つのセキュリティ・プロフィールに対し考査される。このプロフィールは入ってくる各呼の処遇を決定するルールを含んでいる。SPITと判断された呼は、呼阻止ステップ６０で拒絶される。仮にその呼が適法であると判断された場合には、サーバ２６は目標エンドユーザに対しその呼信号を受け渡し、アンカー３４に対しては呼完了ステップ６２において、当該呼が受け入れられた旨のメッセージ（例えばSIP200）を戻す。

ステップ５８で用いられるプロフィール例としては、以下のルールを含むことがある。
・アイデンティティ強度＜ｎの場合、呼を拒絶
・発呼コスト＜ｎの場合、呼を拒絶
・認証方法＜ｎの場合、呼を拒絶
・接続セキュリティ＜ｎの場合、呼を拒絶
・ SPITサスペクト＜ｎの場合、呼を拒絶
・コールセンター≠０の場合、呼を拒絶
・アサーション強度＜ｎの場合、呼を拒絶
加えて、或いはこの代わりに、プロフィールは２つ以上の属性値を組み合わせて作用するようなより複雑なルールを含むことも可能である。オプションとして、プロフィールは、例えば“日時”のような付加的要因に依存できるような細かな処遇を提供したり、或いはSPITの嫌疑がかけられた幾つかの呼に関しては、エンドユーザのボイス・メールボックスやその他の宛先に送ることを定めるようなものでもよい。拒絶された呼の場合、サーバ２６（又は拒絶をする如何なる要素でも）は、発呼側メンバーアイランドとエンドユーザに対し適当な拒絶応答を返すようにしてもよい。

ステップ６２において目標端末３２Dに呼信号を受け渡すに当たっては、仮にユーザエージェントや他の下流側要素がSAMLをサポートしない場合（或いは、他のどんな手段がセキュリティ情報を運搬するのに使用されたとしても）、サーバ２６はセキュリティ情報を剥ぎ取るようにしてもよい。或いは、上述したようにサーバは、セキュリティ情報を、下流側にある互換性のある要素に受け渡すようにしてもよい。

セキュリティ属性
以下の記述は、システム２０において使用可能なセキュリティ属性の例である。属性は、記述子：数値の組み合わせでフォーマットされ、セキュリティレベルと不正可能性レベルを変えた形で示す提案値と共に、それぞれの意味とユーティリティの記述をもって以下に提示される。これらの数値割り付けはあくまで例として掲げただけであり、他の価値尺度もまた本発明の範囲に含まれている。

アイデンティティ強度：
このパラメータは、発呼側メンバーアイランドにおいて呼サービスにアクセスする際に顧客や他のユーザが持つ相対的な難易度に関係するものであり、例えばアカウントやエンドユーザ端末を得る際に含まれる難易度に関するものである。それは、１つの呼が当該のアイランドから発せられる際に、ユーザのアイデンティティという形で認識できる信用の大きさを反映している。例えばITSPの場合、e-mailアドレスに基づいてユーザがソフトウエアをダウンロードするといったような無料のサービスは、予め割り振られたIDが付いた製品が実際のアドレスに発送されるようなサービスに比べて低い数値を持つことになるだろう。公衆交換電話網（PSTN）から発された呼もまた高い値を持つであろう。何故なら、PSTN上での呼に連携する発呼者IDは高い信用度を持つからである。ここでは、アイデンティティ強度の高い数値を持つ発呼者はSPIT呼を発する可能性が低いと仮定する。
このパラメータのための値は以下の通り。
０−未知
１−フリーサービス
２−有料サービス（例：請求先アドレス又は支払い方法が確認済）
３−確認済／企業／PSTNベースの物的資産
４−強力な認証（暗号認証）の発呼者アイデンティティ

呼のコスト：
このパラメータは１つの呼に関して発生する請求額を示している。有料の呼はSPITである可能性が低いと仮定する。このパラメータの数値は以下の通り。
０−未知
１−無料
２−定額
３−分当たりの課金

認証方法：
このパラメータは、メンバーアイランド（又は他の認可サービス）がそのユーザを認証するために使用する方法を指している。このパラメータの数値は以下の通り。
０−未知
１−ベーシック
２−ダイジェスト
３−他の強力な認証形態（例えば、バーチャルなプライベートネットワークやスマートカードなど）

アイデンティティ・アサーション：
このパラメータはアイデンティティを主張するのに用いられる方法を指している。前述したように、アイデンティティを主張することとユーザを認可することは異なる。何故なら1人の認可されたユーザが認可された他ユーザのアイデンティティを盗むこともあるからである。

アンカー３４がメンバーアイランド間の呼のルーティングに責任がある場合、所与のユーザが実際に発呼側メンバーアイランドのドメインに属していることを検証できる情報を持つようにしてもよい。例えば、ユーザのアイデンティティが発呼者IDであってかつその発呼者IDが、呼をユーザのメンバーアイランドに繋ぐ直通社内通話(DID)番号と同じであるなら、アンカーは発呼者IDが発呼側メンバーアイランドのDIDドメインに属していることを確認することができたり、或いはあるメンバーアイランドからの呼がメンバーアイランドのドメイン内の一連のユーザに属さないことを決定できる。このような場合、たとえ発呼側メンバーアイランドが、そのアイデンティティをダイジェスト認証から得られたユーザネームと照合するなんらかの方策を実施しなくとも、アンカーはユーザのアイデンティティに関しある程度のアサーションを提供することができる。

ここではアイデンティティ・アサーション値の高い呼は、SPIT呼の可能性が低いと仮定する。その場合、このパラメータの数値は以下の通り。
０−ユーザ・スペース違反の検出時
１−未知−如何なるアイデンティティ情報なく提供された呼（例えば、PSTNから発せられた匿名の呼など）
２−アイデンティティが発呼側メンバーアイランドのドメインに帰属することの決定に基づき、アイデンティティがアンカーによって主張された場合
２−認可されたユーザに独自に連携されたかのように、アイデンティティが発呼側メンバーアイランドによって主張された場合
接続セキュリティ：

このパラメータは発呼側メンバーアイランドとアンカーの間のリンクの安全性を示す。このパラメータの数値は以下の通り。
０−未知
１−アクセスリスト
２−プロキシ認証
３−バーチャルなプライベートネットワーク（VPN）/IP Serurity(IPsec)
４−トランスペアレントなローカルエリアネットワーク・サービス（TLS）
SPIT嫌疑：

このパラメータは、呼がSPITである可能性を決定するための発呼側エンドユーザに関係した発呼記録の検証に基づき、アンカーによってその呼に割り当てられた点数である。本目的のため各種のテストを適用してもよい。例えば：
・１ユーザからの1分当たりの発呼数（ステップ５２で発呼側メンバーアイランドからアンカーに渡った発呼者アイデンティティ情報に基づく）
・１つのアドレスから大量のエンドユーザに向けての呼
・目標エンドユーザによって返答されたほんの一握りの呼
・ユーザによってダイアルされたほんの一握りのリピートナンバー
・同じ長さの大量な呼
・連続した宛先ナンバーへの呼

このパラメータの数値は０〜９、９がSPIT呼である可能性が最も大きい。
コールセンター：

SPIT嫌疑値が大きな数（例えば、大量のアウトバウンド呼のせいで）の場合でも、呼を申し込むユーザが正規のユーザである可能性がある。ユーザに責任のあるメンバーアイランドは、当該ユーザが実際には商業ベースのアウトバウンドコールセンター（高いSPITサスペクト値を占めることになる）であることを点検してもよい。この識別を容易にするため、発呼側メンバーアイランドは、そのユーザをアンカーに申し立てることも可能であり、アンカーはそれを受け、呼を識別する。

このパラメータの値は以下の通り。
０−未知
１−コールセンターであることが既知。但し疑いあり（例えば、このコールセンターが迷惑コールをしてる場合及び／又は“Do-Not-Call”データベースを遵守していない場合）
２−充分信頼に足るコールセンターであることが既知（例えば迷惑コールではなく、かつエンドユーザかメンバーアイランドのどちらかが入手可能な“Do-Not-Call”データベースへの呼をフィルタリングする場合）
アサーション強度：

このパラメータは全体の客観的重み付け点数であり、この値を基にアンカーは呼を割り付けるものである。下流側の設備は、同様に入手可能な、より詳細な情報に加えるか又はその代わりに、このパラメータ値だけに応じ粗野な決定をする可能性がある。

このパラメータの値は以下の通り。
０−低セキュリティレベル
１−中セキュリティレベル
２−高セキュリティレベル

この値は全体的な呼の格付けであるため、呼を再ルーティングするか阻止するかの決定には最も有効かも知れない。上述したように呼の処分の決定は、終端 IP-PBXやプロキシ或いはユーザエージェントによってもなされ得るかもしれない。これらはSAMLアウェアでない可能性もあり、またSAMLストラクチャをストリッピングするファイアウォールの後に置かれる場合がある。このような制約に打ち勝つため、それ自身によるアサーション強度パラメータは、SAMLメッセージ内に組み入れるよりもむしろSIPヘッダの中（場合によっては、警告ヘッダの中）で渡すことができる。

以上説明した各実施形態はあくまで例示したものであり、本発明は特に図示したものや上述したものに限定されるものでない。むしろ、本発明の範囲は、本明細書を読んだ上で当業者が想倒実施可能な、従来技術に開示されない変形例のみならず、上述した様々な特徴のコンビネーションやサブコンビネーションを含んでいる。
附録A−詳細な呼フロー

本セクションにおけるSIPコードの断片は図2に示すメッセージフローに対応している。本コードは本願の背景技術の項で掲げたように、JenningsらやPetersonらによる刊行物で提示された情報に凡そ基づいている。
発呼エンドユーザからのINVITE
INVITE ship:+140855511212@MIO.com SIP/2.０
Via: SIP/2.0/TCP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1INVITE
Max-Forward: 70
Privacy: id
ヘッダFromに挿入された偽値は、発呼エンティティが匿名を希望していることを示す。
サーバからエンドユーザへの４０７メッセージ
SIP/2.0 407 Proxy Authorization (プロキシ認可)
Via: SIP/2.0/TＬP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>;tag=123456
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1INVITE
Proxy-Authenticate:…realm=”sip.MIO.com”
エンドユーザからサーバへのACK
ACK ship:+140855511212@MIO.com SIP/2.０
Via: SIP/2.0/TＬP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>;tag=123456
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Max-Forward: 70
エンドユーザからINVITEのリピート
INVITE ship:+140855511212@MIO.com SIP/2.０
Via: SIP/2.0/TCP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2INVITE
Max-Forward: 70
Privacy: id
Proxy-Authorization:…realm=”sip.originatingMI.com”username=”alice”
最終行のProxy-Authorizationの ”username”タグは、本例において、発呼側エンドユーザがそれ自身のリアルな情報を提供する最初の時である。他のケースではこの情報はヘッダ“From”から入手可能である。
サーバからアンカーへのINVITE
以下のコードはP-asserted Identityのために使用可
INVITE ship:+140855511212@TA.netSIP/2.０
Via: SIP/2.0/TCP MIO.com;branch=z9hG4bk-124
Via: SIP/2.0/TLP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2INVITE
Max-Forward: 69
P-Asserted-Identity: “Alice Andrews” <sip:alice@MIO.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
呼は匿名であるが、発呼側メンバーアイランドは実際の発呼者ID情報（”Alice Andrews”と14085264000）をアンカーに送る。エンドユーザは匿名をリクエストしたので、サーバは”id”の数値を付けた”Privacy”のヘッダを加え、これはプライベートな情報であって、通過されるべきでないことをアンカーに知らせる。

或いは、このアイデンティティ・ヘッダへのアプローチは本ステップで用いてもよい。このケースでは、一旦メンバーアイランド（認証サービスの役割を担う）が発呼者（Alice）のアイデンティティを確信したならば、メンバーアイランドはリクエストに対しアイデンティティ・ヘッダを算定する。アイデンティティの署名を生成する標準ストリング（CANONICAL string）は以下のようにして作られる。
Sip:alice@MIO.com:sip:14085551212@MIO.com:
245780247857024504:2INVITE:Thu, 21 Feb 2002
13:02:03 GMT: alice@MIO.com:v=0
o=UserA 2890844526 2890844526 IN IP4 MIO.com
s=Session SDP
c=IN IP4 MIO.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
以上のように付与されたプライベートRSAキーを使用して得られた署名（sha1 WithRsaEncryption）はbase 64のコード化を伴って、以下のような一般的フォームを持つ。
CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZX
x1ja9k0nB2sN3W + v1PDsy32MaqZi0………
.IoK8HMyY1VT7egt0kk4XrKFCHYWGClsM9CG4hq+YJZTMaSROoMU
BhikVIjnQ8ykeD6UXNOyfl=
発呼側メンバーアイランドのoriginatingMI.com認証サービスは、base 64署名ストリングを含むアイデンティティ・ヘッダを作ることになる。同サービスはHTTPSのURLも加えることとなり、これにより証明書が入手可能になる。付け加えられたこれら2つのヘッダにより、発呼側サーバからアンカーへのINVITEメッセージは以下のフォームになる。
INVITE ship:+140855511212@TA.netSIP/2.０
Via: SIP/2.0/TCP MIO.com;branch=z9hG4bk-124
Via: SIP/2.0/TLP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2INVITE
Max-Forward: 69
Date: Thu, 21 Feb 2002 13:02:03 GMT//Date field is MANDATORY
Contact: <sip:anonymous@MIO.com>
Identity:”CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdup
RI1vpkXRvZXx1ja9k0nB2sN3W + v1PDsy32MaqZi0………
..IoK8HMyY1VT7egt0kk4XrKFCHYWGClsM9CG4hq+YJZT
MaSROoMUBhikVIjnQ8ykeD6UXNOyfl==”
Identity-Info: https://cert.MIO.com/cert
Content-type: application/sdp
Content-length: …
v = 0
o=UserA 2890844526 2890844526 IN IP4 MIO.com
s=Session SDP
c=IN IP4 MIO.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

このモデルでは、アンカーがB2BUAとしての機能を果たす。従って、アンカーは、メンバーアイランドMIに情報を受け渡すか否かにかかわらず、アンカーが受け取るアイデンティティ情報をデコードしなければならない。仮にアンカーがoriginatingMI.comの証明書をまだ知らない場合、証明書を得るためにIdentity-Infoのヘッダに与えられたURLにアクセスする。その際、このエージェントはSIPリクエストの同じヘッダから上に示したような同じ標準ストリング（canonical string）を作る。この標準ストリング（canonical string）、アイデンティティ・ヘッダの署名されたダイジェスト及び証明書を用いることでアンカーは与えられたヘッダの組み合わせとメッセージ本体が変更されていないことを証明できる。
アンカーから目標サーバへのINVITE

アイデンティティ・ヘッダ（以下に論じる）以外に、アンカーは、自身が算定したセキュリティ属性値を含むSAMLメッセージを目標メンバーアイランドへと通す際に、以下のヘッダを使用する。
SAML-Payload: cid:attribute*SAML@TA.net
Content-type: multipart/mixed; boundary=unique-boundary-1
--unique-boundary-1
Content-type: application/sdp
Content-length: …
v=0
…
--unique-boundary-1
Content-ID:<attribute*SAML@TA.net>
Content-type: application/saml+xml
Content-length: …
<saml:Assertion> Assertion from Appendix A
</saml:Assertion>
--unique-boundary-1

仮にP-Asserted-Identityへのアプローチがなされたならば、その時アンカーはアイデンティティ情報をサーバに運ぶために以下のコードを使用する。
INVITE ship:+140855511212@MIO.com SIP/2.０
Via: SIP/2.0/TCP eur.MIO.com;branch=z9hG4bk-123
To: <sip:+14085551212@MIO.com>
From:“Anonymous”<sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 1234567890123456789
CSeq: 1INVITE
Max-Forward: 70
Privacy: id

仮にアイデンティティ・アプローチが選択され、かつアンカーがエンドユーザ・アイデンティティを目標メンバーアイランドに送ることを決定したならば、発呼側メンバーアイランドからアンカーへアイデンティティを送るための先に概要説明したステップが繰り返される（発呼側メンバーアイランドで使用したキーに代わり、アンカーに関係したプライベートキーを用いて）。このケースではアイデンティティ情報はアンカーに帰属する証明書を含むことになる。
附録B - SAMLコード

先に述べたように、SAMLはセキュリティ情報を交換するためのXMLベースのフレームワークである。フレームワーク内のある地点から別の地点への確実な通信を保証する証明書を発行する際に他のアプローチが中央の証明機関を使うのに対し、SAMLではネットワーク内のいずれの地点でもユーザやデータピースのアイデンティティを知っていることを主張できる。被呼側のアプリケーションがその主張を信用するか否か決定してもよい。
SAMLメッセージ構造
<saml:Assertion
xmlns:saml=”urn:oasis:name:tc:SAML:1.0:assertion”
MajorVersion=”1”MinorVersion=”1”
AssertionID=”P1YaAz/tP6U/fsw/xA+jax5TPxQ=”
Issuer=”mediator.com”
IssueInstant=”2005-03-12T17:15:32.753Z”>
<saml:Conditions
NotBefore=”2005-03-12T17:10:32.753Z”
NotOnOrAfter=”2005-03-12T17:20:32.753Z”/>
<saml:AttributeStatement>
<saml:Subject>…</saml:Subject>
<saml:Attribute
AttributeName=”IdentityStrength”
AttributeNamespace=http://ta.com>
<saml:AttributeValue>1</saml:AttributeValue>
<saml:Attribute><saml:Attribute
AttributeName=”CostofCall”
AttributeNamespace=http://ta.com>
<saml:AttributeValue>０</saml:AttributeValue>
<saml:Attribute><saml:Attribute
AttributeName=”CallIDAssertion”
AttributeNamespace=http://ta.com>
<saml:AttributeValue>good</saml:AttributeValue>
<saml:Attribute><saml:Attribute
AttributeName=”ConnectionSecurity”
AttributeNamespace=http://ta.com>
<saml:AttributeValue>TLS</saml:AttributeValue>
<saml:Attribute><saml:Attribute
AttributeName=”SPITSuspect”
AttributeNamespace=http://ta.com>
<saml:AttributeValue>True</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>

本発明の実施形態によるインターネット電話システムを概略的に示すブロック図である。本発明に実施形態によるVoIP呼の開始に関連する呼シグナリングを概略的に示すメッセージフロー図である。本発明の実施形態による呼フィルタリング方法を概略的に示すフロー図である。

符号の説明

２０システム
２２インターネット
２４ボーダーサーバ（発呼側）
２６ボーダーサーバ（着呼側）
２８発呼側メンバーアイランド
３０着呼側メンバーアイランド
32A, 32B, 32C, 32D, 32E, 32F 端末
３４アンカー

Claims

パケット電話のための方法であって、
第２集合組織の第２のエンドユーザに発呼するためにパケット通信ネットワークを介して第１の集合組織の第１のエンドユーザからの第１メッセージを受け取り、
前記第１メッセージに応じて、前記第１集合組織と前記第１エンドユーザの内、少なくとも一方の１つ又はそれ以上の特性を決定し、
前記１つ又はそれ以上の特性に基づき、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値を割り当て、及び
上記パケット通信ネットワーク上において、第２エンドユーザを対象とした第２メッセージであって、前記セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含む第２メッセージを送ることを具備するパケット電話方法。
前記第１及び第２組織は、信頼のおけるアンカーによって提供された連邦組織のメンバーアイランドであって、前記アンカーはメンバーアイランド間のパケット電話呼のルートを決め、前記方法の各ステップは信頼のおける前記アンカーによって実行される請求項１に記載の方法。
前記呼は、ボイスオーバー・インターネット・プロトコル（VoIP）呼であり、前記第１及び第２メッセージはセッション・イニシエーション・プロトコル（SIP）に従って送信される請求項１に記載の方法。
前記各値の前記少なくとも１つは、セキュリティ・アサーション・マークアップ言語（SAML）を使った前記第２メッセージに組み込まれる請求項３に記載の方法。
更に、各値の内の前記少なくとも１つの値に応じて前記呼を完成するか拒絶するかを決定することを具備する請求項１に記載の方法。
前記呼を完成するか拒絶するかを決定することは、前記第２メッセージに応じて前記第２集合組織と第２エンドユーザの内、少なくとも一方から発された第３のメッセージを受け取り、前記第３メッセージに応じて上記呼を完成するか拒絶するか決定することを具備する請求項５に記載の方法。
前記呼を完成するか拒絶するかの決定は、１組の呼フィルタリングルールを前記セキュリティ属性の値に適用することを具備する請求項５に記載の方法。
前記１つ又はそれ以上のセキュリティ属性は、少なくとも１つのアイデンティティ関連属性を有し、上記１つ又はそれ以上の特性を決定することは、前記少なくとも１つのアイデンティティ関連属性を決定するために前記第１集合組織に対し前記第１エンドユーザによって提供された識別情報の信頼性を評価することを具備する請求項１乃至７のいずれかに記載の方法。
前記少なくとも１つのアイデンティティ関連属性は、前記第１集合組織によって提供された呼サービスにアクセスする際に第１エンドユーザが遭遇する難易度を示すアイデンティティ強度属性を具備する請求項８に記載の方法。
前記少なくとも１つのアイデンティティ関連属性は、前記第１集合組織によって提供された呼サービスのユーザを認証する際に使用される方法のセキュリティレベルを示す認証方法属性を具備する請求項８に記載の方法。
前記少なくとも１つのアイデンティティ関連属性は、前記第１集合組織によって提供された呼サービスにアクセスする際に第１エンドユーザが遭遇する難易度を示すアイデンティティアサーション属性を具備する請求項８に記載の方法。
前記少なくとも１つのセキュリティ属性は、前記第１エンドユーザが負う前記呼のコスト指示を具備する請求項１乃至７のいずれかに記載の方法。
前記少なくとも１つのセキュリティ属性は、前記第１メッセージを伝達するネットワークリンクのセキュリティレベルを示すコネクションセキュリティ属性を具備する請求項１乃至７のいずれかに記載の方法。
前記少なくとも１つのセキュリティ属性はSPIT嫌疑属性を有し、前記１つ又はそれ以上の特性を決定することは、前記呼がスパムコールである可能性を決定するように前記第１エンドユーザが発した呼のパターンを評価し、その可能性に応じて前記SPIT嫌疑属性の値を設定することを具備する請求項１乃至７のいずれかに記載の方法。
前記少なくとも１つのセキュリティ属性は、前記第１集合組織にあるアウトバウンドのコールセンターの作動を示すコールセンター属性を具備する請求項１乃至７のいずれかに記載の方法。
前記各値の割り当ては、複数の前記各値上に重みスコアを算定することを具備し、前記第２メッセージを送信することは、第２メッセージに前記重みスコアを組み込むことを具備する請求項１乃至７のいずれかに記載の方法。
パケット電話のための装置であって、
パケット電話システムに含まれるエンティティの特性を格納するように配置されたメモリ；及び
前記メモリに接続されたアンカーであって、第２集合組織の第２のエンドユーザに発呼するために、パケット通信ネットワークを介して第１の集合組織の第１のエンドユーザが発した第１メッセージを受け取り、前記第１メッセージに応じて、前記第１集合組織と前記第１エンドユーザの内、少なくとも一方の１つ又はそれ以上の特性を決定し、前記１つ又はそれ以上の特性に基づき、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値を割り当てるように配置された前記アンカー、を具備し、
前記アンカーは、上記パケット通信ネットワーク上において、第２エンドユーザを対象とした第２メッセージであって、前記セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含む第２メッセージを送るように配置されていることを特徴とするパケット電話のための装置。
前記第１及び第２組織は、前記アンカーによって提供された連邦組織のメンバーアイランドである請求項１７に記載の装置。
前記呼は、ボイスオーバー・インターネット・プロトコル（VoIP）呼であり、前記第１及び第２メッセージはセッション・イニシエーション・プロトコル（SIP）に従って送信される請求項１７に記載の装置。
前記各値の前記少なくとも１つは、セキュリティ・アサーション・マークアップ言語（SAML）を使った前記第２メッセージに組み込まれる請求項１９に記載の装置。
前記各値の内の前記少なくとも１つの値は、前記呼を完成するか拒絶するかを決定する際に適用される請求項１７に記載の装置。
前記アンカーは、前記第２メッセージに応じて前記第２集合組織と第２エンドユーザの内、少なくとも一方から発された第３のメッセージに基づき、前記呼を完成するか拒絶するか決定するように配置されること特徴とする請求項２１に記載の装置。
前記呼を完成するか拒絶するかを決定するべく、１組の呼フィルタリングルールが前記セキュリティ属性の値に適用される請求項２１に記載の装置。
前記１つ又はそれ以上のセキュリティ属性は、少なくとも１つのアイデンティティ関連属性を有し、該アイデンティティ関連属性は、前記少なくとも１つのアイデンティティ関連属性を決定するために前記第１集合組織に対し前記第１エンドユーザによって提供された識別情報の信頼性を示す請求項１７乃至２３のいずれかに記載の装置。
前記少なくとも１つのアイデンティティ関連属性は、前記第１集合組織によって提供された呼サービスにアクセスする際に第１エンドユーザが遭遇する難易度を示すアイデンティティ強度属性を具備する請求項２４に記載の装置。
前記少なくとも１つのアイデンティティ関連属性は、前記第１集合組織によって提供された呼サービスのユーザを認証する際に使用される装置のセキュリティレベルを示す認証装置属性を具備する請求項２４に記載の装置。
前記少なくとも１つのアイデンティティ関連属性は、前記第１集合組織によって提供された呼サービスにアクセスする際に第１エンドユーザが遭遇する難易度を示すアイデンティティ断定属性を具備する請求項２４に記載の装置。
前記１つ又はそれ以上のセキュリティ属性は、前記第１エンドユーザが負う前記呼のコスト表示を具備する請求項１７乃至２３のいずれかに記載の装置。
前記１つ又はそれ以上のセキュリティ属性は、前記第１メッセージを伝達するネットワークリンクのセキュリティレベルを示すコネクションセキュリティ属性を具備する請求項１７乃至２３のいずれかに記載の装置。
前記１つ又はそれ以上のセキュリティ属性はSPIT嫌疑属性を有し、前記アンカーは、前記呼がスパムコールである可能性を決定するように前記第１エンドユーザが発した呼のパターンを評価し、その可能性に応じて前記SPIT嫌疑属性の値を設定するように配置されている請求項１７乃至２３のいずれかに記載の装置。
前記１つ又はそれ以上のセキュリティ属性は、前記第１集合組織にあるアウトバウンドのコールセンターの作動を示すコールセンター属性を具備する請求項１７乃至２３のいずれかに記載の装置。
前記１つ又はそれ以上のセキュリティ属性は、複数の前記各値の上の重みスコアを有し、前記アンカーは前記重みスコアを第２メッセージに組み込むように配置されている請求項１７乃至２３のいずれかに記載の装置。
プログラムインストラクションを格納するコンピュータ読み込み媒体を具備し、前記コンピュータに読み込まれた際に、前記インストラクションによりコンピュータが、第２集合組織の第２のエンドユーザに発呼するためにパケット通信ネットワークを介して第１の集合組織の第１のエンドユーザが発した第１メッセージを受け取り、前記第１メッセージに応じて、前記第１集合組織と前記第１エンドユーザの内、少なくとも一方の１つ又はそれ以上の特性を決定し、前記１つ又はそれ以上の特性に基づき、前記呼がスパムコールである可能性を示す１つ又はそれ以上のセキュリティ属性に対し夫々の値を割り当てるコンピュータソフトウエア製品であって、
上記インストラクションにより、コンピュータは、パケット通信ネットワークを介して、第２エンドユーザを対象とした第２メッセージであって、前記セキュリティ属性の少なくとも１つに割り当てられた夫々の値の少なくとも１つを含む第２メッセージを送ることを特徴とするコンピュータソフトウエア製品。