通信ネットワーク間のセキュアな通信を提供する方法及びシステム
【課題】第１のネットワークと第２のネットワークとの間でのセキュアな通信。
【解決手段】本発明は，第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法に関し，該方法は被呼者のアドレスを第１のネットワークにおいて判定するステップと，被呼者が信頼できるネットワークにいるかどうかをアドレスに基づいて判定するステップと，被呼者が信頼できるネットワークにいるかどうかに依存して被呼者と発呼者との間の通信を制御するステップと，を有する。
【解決手段】本発明は，第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法に関し，該方法は被呼者のアドレスを第１のネットワークにおいて判定するステップと，被呼者が信頼できるネットワークにいるかどうかをアドレスに基づいて判定するステップと，被呼者が信頼できるネットワークにいるかどうかに依存して被呼者と発呼者との間の通信を制御するステップと，を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，通信方法に関する。
【背景技術】
【０００２】
通信システムは，ユーザ装置及び／又は通信システムに関連した他のノードのような２以上のエンティティ間の通信セッションを可能にする設備としてとらえることができる。その通信は，例えば，音声，データ，マルチメディアなどの通信を含むことができる。セッションは，例えば，ユーザ間の電話呼，多地点会議セッション，又はユーザ装置と，例えばサービス提供者のサーバなどアプリケーションサーバ（ＡＳ）との間の通信セッションであってもよい。これらセッションの確立は，一般的にはユーザにさまざまなサービスを提供することを可能にする。
【０００３】
通信システムは，典型的には所定の標準又は仕様に基づいて動作し，それら標準又は仕様はその通信システムに関連するさまざまなエンティティが何をすることが許され，またそれがどのように達成されるかについて列挙している。例えば，その標準又は仕様は，ユーザ，より正確にはユーザ装置が，回線交換サービス及び／又はパケット交換サービスを受けられるかどうかを定義してもよい。そのコネクションに使うべき通信プロトコル及び／又はパラメータをも定義してもよい。言い換えれば，そのシステムによって通信を可能にするために，通信が基づくことのできる特定の「規定」（ｒｕｌｅｓ）のセットが定義されなければならない。
【０００４】
ユーザ装置に無線通信を提供するいくつかの通信システムが知られている。無線システムの一例は，公衆陸上移動体ネットワーク（ＰＬＭＮ）である。ＰＬＭＮは，典型的にはセルラ技術に基づいている。セルラシステムでは，基地局（ＢＴＳ）又は類似のアクセスエンティティが移動機（ＭＳ）としても知られる無線ユーザ装置（ＵＥ）に，それらエンティティ間の無線インタフェースを介してサービスを提供する。ユーザ装置と通信ネットワーク要素との間の無線インタフェース上の通信は，適当な通信プロトコルに基づくことができる。基地局装置及びその他通信のために必要とされる装置の運用は１又はいくつかの制御エンティティによって制御することができる。さまざまな制御エンティティが相互接続されていてもよい。
【０００５】
また，１以上のゲートウェイノードが，セルラネットワークと他のネットワークとを接続するために提供されもよい。他のネットワークとは，例えば公衆交換電話ネットワーク（ＰＳＴＮ）及び／又はＩＰ（インターネットプロトコル）のような他の通信ネットワーク及び／又は他のパケット交換データネットワークである。そのような構成において，移動体通信ネットワークはユーザが無線ユーザ装置を使って外部ネットワーク，ホスト又は特定サービス提供者が提供するサービスを利用することできるアクセスネットワークを提供する。次にアクセスポイント又は移動体通信ネットワークのゲートウェイノードは，外部ネットワーク又は外部ホストへの更なるアクセスを提供する。例えば，もし要求されたサービスが他のネットワークに存在するサービス提供者によって提供されているならば，そのサービス要求はゲートウェイを介してそのサービス提供者に届けられる。その経路設定は，移動体ネットワーク運用者が保有している移動体加入者データの定義に基づいてなされてもよい。
【０００６】
通信システムの加入者のようなユーザに対して提供できるサービスの一例は，いわゆるマルチメディアサービスである。マルチメディアサービスを提供できるようにした通信システムのいくつかはインターネットプロトコル（ＩＰ）マルチメディアネットワークとして知られている。ＩＰマルチメディア（ＩＭ）機能はＩＰマルチメディアコアネットワーク（ＣＮ）サブシステム，すなわち短く称するとＩＰマルチメディアサブシステム（ＩＭＳ），によって提供できる。ＩＭＳは，マルチメディアサービスを提供するためにさまざまなネットワークエンティティを含んでいる。ＩＭＳサービスは，数あるサービスの中でも，移動体ユーザ装置間のＩＰコネクションを提供することを意図している。
【０００７】
第三世代パートナシッププロジェクト（３ＧＰＰ）は，ＩＭＳサービス提供のための一般パケット無線サービス（ＧＰＲＳ）の利用法を規定している。それゆえにこれが，以降の説明の中でＩＭＳサービスを可能にするバックボーン通信ネットワークの例として用いられる。一例としての一般パケット無線サービス（ＧＰＲＳ）動作環境は，１以上のサブネットワークサービスエリアを有し，それらはＧＰＲＳバックボーンネットワークによって相互接続されている。一つのサブネットワークはいくつかのパケットデータサービスノード（ＳＮ）を備える。このアプリケーションでは，サービスノードはサービス提供ＧＰＲＳサポートノード（ＳＧＳＮ）と呼ぶことにする。各々のＳＧＳＮは，少なくとも一つの移動体通信ネットワーク，典型的には基地局システム，に接続されている。その接続は，典型的には，無線ネットワークコントローラ（ＲＮＣ）又は基地局コントローラ（ＢＳＣ）のような他のアクセスシステムコントローラによって，パケットサービスをいくつかの基地局を経由して移動体ユーザ装置に提供することができるような方法でなされる。中間移動体通信ネットワークは，サービスノードと移動体ユーザ装置との間のパケット交換データ伝送を提供する。さまざまなサブネットワークは，順に，ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）を経由して外部データネットワーク，例えば公衆交換データネットワーク（ＰＳＰＤＮ），に接続される。ＧＰＲＳサービスはこのようにして移動体データ端末と外部データネットワークとの間のパケットデータ伝送を可能にする。
【０００８】
このようなネットワークでは，パケットデータセッションはネットワーク上でトラヒックフローを搬送するために確立される。そのようなパケットデータセッションはしばしば，パケットデータプロトコル（ＰＤＰ）コンテキストと呼ばれる。ＰＤＰコンテキストは，ユーザ装置と，無線ネットワークコントローラと，ＳＧＳＮとの間に提供される無線アクセスベアラ，及びサービス提供ＧＰＲＳサポートノードとゲートウェイＧＰＲＳサポートノードとの間に提供される交換パケットデータチャネルを含んでもよい。
【０００９】
ユーザ装置と他者との間のデータ通信セッションは，次に，確立されたＰＤＰコンテキスト上で実行されることになる。各ＰＤＰコンテキストは１以上のトラヒックフローを搬送することができるが，一つの特定ＰＤＰコンテキスト内にあるすべてのトラヒックフローは，そのネットワーク内での伝送に関しては同じ方法で取り扱われる。このＰＤＰコンテキスト取扱い要求条件は，トラヒックフローに付随するＰＤＰコンテキスト取扱い属性に基づく。
【００１０】
第三世代パートナシッププロジェクト（３ＧＰＰ）は，また，ユーザ装置のユーザにマルチメディアサービスへのアクセスを提供する第三世代（３Ｇ）コアネットワークのための参照アーキテクチャも規定している。このコアネットワークは三つの主要ドメインに分割される。それらは，回線交換（ＣＳ）ドメイン，パケット交換（ＰＳ）ドメイン及びインターネットプロトコルマルチメディア（ＩＭ）ドメイン，である。これらのうちの後者であるＩＭドメインは，マルチメディアサービスが適切に管理されることを確実にするためにある。
【００１１】
ＩＭドメインは，インターネット技術タスクフォース（ＩＥＴＦ）によって開発されたセッション開始プロトコル（ＳＩＰ）を提供する。セッション開始プロトコル（ＳＩＰ）は，１以上の参加者（終点）に関するセッションを生成，修正及び終了させるためのアプリケーション層制御プロトコルである。ＳＩＰは，一般的には，インターネット内にある２以上の終点間のセッションについて，これら終点に対しセッションの意味を知らしめることによってこのセッションを開始させるように開発された。ＳＩＰベースの通信システムに接続されたユーザは，標準化されたＳＩＰメッセージに基づいて通信システムのさまざまなエンティティと通信してもよい。ユーザ装置上であるアプリケーションを実行させるユーザ装置，すなわちユーザは，特定セッションへの招待がそれら終点に正しく配信されるようＳＩＰバックボーンに登録される。これを実現するため，ＳＩＰはデバイスとユーザのための登録機構を提供し，そしてこのＳＩＰセッション招待を正しく届けるために位置情報サーバ及び登録サーバのような機構に適用される。ＳＩＰ通知手段によって提供可能なセッションの例としては，インターネットマルチメディア会議，インターネット電話呼及びマルチメディア配信などがある。
【００１２】
ここでＩＥＴＦ文書ＲＦＣ３３２５を参照文献として引用する。この文書はＳＩＰに対する私的拡張を述べているが，これによれば信頼できるＳＩＰサーバのネットワークがエンドユーザ又はエンドシステムの識別情報を主張することを可能にし，エンドユーザが要求したプライバシについての指示を搬送することができる。この拡張は，ネットワーク主張識別情報のための短期要求条件に定義された「信頼できるドメイン」内で利用できる。そのような「信頼できるドメイン」内にあるノードは，各自の識別情報を公に主張すること，およびプライバシが要求されるときはその信頼できるドメイン外に識別情報を出さないよう責任を持つこと，がそのユーザ及び最終システムによって明確に信頼されている。
【００１３】
ＲＦＣ３３２５に記述されたプライバシに関する手続を適用することができるように，隣接ホップネットワークの信頼性を検知する必要がある。もし隣接ホップが信頼できるならば，さまざまなプライバシ選択肢に応じた手続がその隣接ホップに対して送られる。そうでなければ，プライバシに関する手続が実行されなければならない。
【００１４】
例として，発呼者が識別情報のプライバシを要求する場合は，P-Asserted-Identityヘッダは，被呼者に届く前に削除されなければならない。発呼者によって送信されたメッセージは，送信者を識別するためのP-Asserted-Identityヘッダと呼ばれるヘッダを含む。このヘッダの形式は，もし送信者が公に知られたユーザ識別情報を持っているならば，<sip:user1_public1@home1.net>である。この発呼者のホームネットワークは，被呼者のホームネットワークが信頼できないときだけ，そのヘッダを削除しなければならない。もし，被呼者のホームネットワーク（それは発呼者のホームネットワークの隣接ホップである）が信頼できるならば，発呼者のホームネットワークはそのヘッダを削除しない。これはＲＦＣ３２５５に従うために必要であり，このＲＦＣ３２５５によれば，P-Asserted-Identityヘッダは信頼できるドメイン内の最後の要素によって取り除かれなければならない。
【００１５】
ＲＦＣ３２５５では，提案された機構は，ＵＲＩ（一般にはＳＩＰ ＵＲＩ）及び選択的に表示用氏名を含むP-Asserted-Identityと呼ばれるヘッダフィールドに頼る。メッセージを取り扱うプロキシサーバは，発呼ユーザをなんらかの方法（例えば，ダイジェスト認証）で認証したのちに，そのメッセージにP-Asserted-Identityヘッダフィールドを挿入することができ，それを他の信頼できるプロキシに転送することができる。プロキシが信頼しないプロキシサーバ又はＵＡにメッセージを転送しようとするとき，もしユーザがプライベートにとどめたいと要求するならば，プロキシはすべてのP-Asserted-Identityヘッダフィールド値を削除する。ユーザはこの種のプライバシを要求することができる。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開平６−９５９９１号公報
【非特許文献】
【００１７】
【非特許文献１】Jennings, C.，RFC3325，"SIP Asserted Identity"，IETF，２００２年１１月
【発明の概要】
【発明が解決しようとする課題】
【００１８】
正しい場所で適用されるべき手続き（ｐｒｏｃｅｄｕｒｅ）にとっては，隣接ホップの信頼性が何らかの方法で検知されなければならない。
【図面の簡単な説明】
【００１９】
【図１】本発明を実施できる通信システムを示す図である。
【図２】本発明の一実施例の動作を説明するフローチャートである。
【図３】本発明の実施例を提供可能な環境を示す図である。
【発明を実施するための形態】
【００２０】
本発明の第１の態様は，第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間での通信方法であって，この方法は，
前記被呼者のアドレスを第１のネットワークにおいて判定するステップと；
前記アドレスに基づいて前記被呼者が信頼できるネットワークにいるかどうかを判定するステップと；
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて被呼者と発呼者との間の通信を制御するステップと；
を有する。
【００２１】
本発明の第２の態様は，発呼者がいる第１のネットワークと，発呼者がいる第２のネットワークとを備える通信システムであって，前記第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と；
前記被呼者が信頼できるネットワーク内にいるかどうかを，前記アドレスに基づいて判定するための判定手段と；
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて，被呼者と発呼者との間の通信を制御するための制御手段と；
を備える。
【００２２】
第３の態様は，第２のネットワーク内にいる発呼者に発呼するように構成された発呼者のいる第１のネットワークであって，該第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と；
前記被呼者が信頼できるネットワークにいるかどうかを，前記アドレスに基づいて判定するための判定手段と；
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて，被呼者と発呼者との間の通信を制御するための制御手段と；
を備える。
【００２３】
第４の態様は，第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法であって，この方法は，
前記第２のネットワークとの間にセキュアコネクションがあるかどうかを，第１のネットワークにおいて判定するステップと；
もし前記第２のネットワークとの間にセキュアコネクションがないと判定されたら，発呼者から被呼者へのメッセージを廃棄又は修正するステップと；
を有する。
【実施例】
【００２４】
本発明の実施例は特にＲｅｌ−５ ＩＭＳネットワークに関連するがこれに限定されるものではない。本発明の実施例はまた，ＩＭＳネットワークの他のバージョンに適用してもよい。本発明の実施例は他のＳＩＰネットワークに適用してもよい。本発明のいくつかの実施例はＳＩＰ環境及びＩＭＳ環境外のより広範な応用を見いだすであろう。
【００２５】
本発明のある実施例は例示として第三世代（３Ｇ）移動体通信システムにおける一例としてのアーキテクチャを参照して記述する。しかし，ある実施例は他のいかなる適切なネットワーク形態に適用されてもよいと理解される。移動体通信システムは典型的には，通常はユーザ装置と通信システムの基地局との間の無線インタフェースを介して，複数の移動体ユーザ装置にサービスを提供するよう構成される。移動体通信システムは，無線アクセスネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）とに論理的に分割されてもよい。
【００２６】
本発明のよりよい理解のために，ここで添付の図面を例として参照する。図１を参照して，本発明の実施が可能なネットワークアーキテクチャの例を示す。図１は，ＩＰマルチメディアネットワーク加入者にＩＰマルチメディアサービスを提供するためのＩＰマルチメディアネットワーク４５を示す。ＩＰマルチメディア（ＩＭ）機能は，サービスを提供するためのさまざまなエンティティを含むコアネットワーク（ＣＮ）によって提供することができる。
【００２７】
基地局３１及び４３は，無線インタフェースを介して移動体ユーザ，すなわち加入者，の移動体ユーザ装置３０及び４４へ信号を送信し，また移動体ユーザ装置から信号を受信するように構成される。同様に，各移動体ユーザ装置は無線インタフェースを介して基地局に信号を送信し，また基地局から信号を受信することができる。図１の簡略化された記載では，基地局３１及び４３は異なる無線アクセスネットワーク（ＲＡＮ）に属している。図示する構成では，ユーザ装置３０と４４のいずれも，基地局３１及び４３に連携した二つのアクセスネットワークをそれぞれ介してＩＭＳネットワーク４５にアクセスすることができる。図１では，明瞭化のために二つの無線アクセスネットワークのみの基地局を示しているが，典型的な移動体通信ネットワークにおいては，通常，多くの無線アクセスネットワークが含まれていることを認識しなければならない。
【００２８】
３Ｇ無線アクセスネットワーク（ＲＡＮ）は，典型的には適当な無線ネットワークコントローラ（ＲＮＣ）によって制御される。このコントローラは，明瞭性のために図示しない。コントローラは基地局ごとに割り当てられてもよいし，若しくは複数の基地局をコントローラが制御することもできる。コントローラが，複数の基地局を制御するために，個々の基地局と無線アクセスネットワークレベルとの双方に提供されるといった解決策も知られている。したがって，ネットワークコントローラの名称，位置及び数は，システムに依存することを認識しなければならない。
【００２９】
移動体ユーザは，ネットワークに接続するため，インターネットプロトコル（ＩＰ）通信に適合した任意の適当な移動体デバイスを使ってもよい。例えば，移動体ユーザは，パーソナルコンピュータ（ＰＣ），パーソナルデータアシスタント（ＰＤＡ），移動機（ＭＳ）などの手段によってセルラネットワークにアクセスしてもよい。次に掲げる例は移動機環境において記述されている。
【００３０】
本技術における当業者ならば，典型的な移動機の特徴及び動作をよく知っている。したがって，これら特徴についての詳細な説明は不要である。ユーザは，電話呼を発信及び受信したり，データをネットワークから受信したり，データをネットワークに送信したり，例えばマルチメディアコンテンツを体験したり，といった仕事のために移動機を使ってもよいことを特筆すれば十分である。移動機は，典型的にはこれらの仕事を達成するために，プロセッサ及びメモリ手段を備えている。移動機は，信号を無線で移動体通信ネットワークの基地局から受信したり，基地局へ送信したりするためにアンテナ手段を含んでもよい。移動機はまた，移動体ユーザ装置のユーザに画像及び他の図形情報を表示するためのディスプレイを備えてもよい。スピーカ手段があってもよい。移動機の動作は，制御ボタン，音声コマンドなどのような適当なユーザインタフェース手段によって制御してもよい。
【００３１】
図１には明瞭にするため二つの移動機のみを示しているが，移動体通信ネットワークの各基地局といくつかの移動機とが同時に通信状態にあってもよいことを認識しなければならない。また，移動機はいくつかの同時セッション，例えばいくつかのＳＩＰセッション及び活性化されたＰＤＰコンテキストを持ってもよい。また，ユーザは電話呼をなし，また同時に少なくとも一つの他サービスに接続してもよい。
【００３２】
コアネットワーク（ＣＮ）エンティティは，いくつかの無線アクセスネットワークを経由した通信を可能にするため，また他のセルラシステム及び／又は固定回線通信システムのような１以上の通信システムと単一通信システムとをインタフェースするために，典型的にはさまざまな制御エンティティ及びゲートウェイを含む。図１において，サービス提供ＧＰＲＳサポートノード３３，４２及びゲートウェイＧＰＲＳサポートノード３４，４０はネットワークにおいて，それぞれＧＰＲＳサービス３２及び４１を提供するためにある。
【００３３】
無線アクセスネットワークは，典型的には，適当なコアネットワークエンティティ又はサービス提供一般パケット無線サービスサーポートノード（ＳＧＳＮ）３３及び４２のようなエンティティ（ただしそれに限定はされない）に接続される。図示されてはいないが，各ＳＧＳＮは，典型的には，各ユーザ装置の加入契約に関連する情報を保有するよう構成された指定加入者データベースにアクセスできる。
【００３４】
無線アクセスネットワーク内のユーザ装置は，典型的には無線ベアラ（ＲＢ）と呼ばれる無線ネットワークチャネルを介して，無線ネットワークコントローラと通信してもよい。各ユーザ装置は無線ネットワークコントローラとの間に同時に張られる１以上の無線ネットワークチャネルを有してもよい。無線アクセスネットワークコントローラは，例えばI uインタフェース上の適当なインタフェースを介して，サービス提供ＧＰＲＳサポートノードと通信する。
【００３５】
サービス提供ＧＰＲＳサポートノードは，次に，典型的にはＧＰＲＳバックボーンネットワーク３２，４１を介して，ゲートウェイＧＰＲＳサポートノードと通信する。このインタフェースは，通常，交換パケットデータインタフェースである。サービス提供ＧＰＲＳサポートノード及び／又はゲートウェイＧＰＲＳサポートノードは，ネットワーク内のＧＰＲＳサービスを提供するためにある。
【００３６】
アクセスエンティティにあるユーザ装置と，ゲートウェイＧＰＲＳサポートノードとの間の全体の通信は，一般にパケットデータプロトコル（ＰＤＰ）環境によって提供される。全体のＰＤＰコンテキストは通常特定ユーザ装置とゲートウェイＧＰＲＳサポートノードとの間の通信路を提供し，いったん確立されたならば，典型的には複数フローを搬送することができる。各フローは通常，例えば，特定サービス及び／又は特定サービスの１メディアコンポーネントを表す。したがって，ＰＤＰコンテキストはしばしば，ネットワークを横切る１以上のフローのための論理的通信路を表す。ユーザ装置とサービス提供ＧＰＲＳサポートノードとの間のＰＤＰコンテキストを実装するために，無線アクセスベアラ（ＲＡＢ）が確立されなければならず，それは通常ユーザ装置のためのデータ転送を可能にする。これら論理的及び物理的チャネルの実装は本技術の当業者には知られており，それ故ここではこれ以上議論しない。
【００３７】
ユーザ装置３０，４４は，ＧＰＲＳネットワークを介して，一般的にはＩＭＳに接続されているアプリケーションサーバに接続してもよい。
【００３８】
この通信システムは，サーバとして知られるネットワークエンティティによって取り扱われるさまざまなネットワーク機能手段によって，サービスをユーザ装置に提供してもよいように開発された。例えば，現在の第三世代（３Ｇ）無線マルチメディアネットワークアーキテクチャでは，さまざまな機能を取り扱うためにいくつかのさまざまなサーバが使われることを想定している。これら機能は，呼セッション制御機能（ＣＳＣＦｓ）のような機能を含む。呼セッション制御機能は，プロキシ呼セッション制御機能（Ｐ-ＣＳＣＦ)３５及び３９，問合せ（interrogating）呼セッション制御機能（Ｉ−ＣＳＣＦ）３７，及びサービス提供呼セッション制御機能（Ｓ−ＣＳＣＦ）３６及び３８，といったさまざまなカテゴリに分割し得る。ＩＭＳシステムを介してアプリケーションサーバによって提供されるサービスを利用したいと思うユーザは，サービス提供制御エンティティに登録する必要があろう。サービス提供呼セッション制御機能（Ｓ−ＣＳＣＦ）は，通信システムからサービス要求をすることができるように，ユーザが登録する必要のある３Ｇ ＩＭＳ構成内のエンティティを形成してもよい。ＣＳＣＦｓは，ＵＭＴＳシステムのＩＭＳネットワークを規定する。
【００３９】
同様な機能は，さまざまなシステムにおいてさまざまな名称で呼ぶことができることを認識しなければならない。例えば，あるアプリケーションではＣＳＣＦｓは呼状態制御機能と呼ばれるかも知れない。
【００４０】
通信システムは，バックボーンネットワークによって要求される通信リソースを与えられたユーザが，その通信システム上で所望のサービス要求を送信することによってサービスの利用を起動しなければならないように構成されていてもよい。例えば，ユーザは適当なネットワークエンティティから，セッション，トランザクション又は他の種類の通信を要求してもよい。
【００４１】
本発明の一実施例では，データベースが発呼者のホームネットワークのＳ-ＣＳＣＦにあって，そのデータベースはホームネットワークが信頼するすべての既知のＩＭＳネットワークドメイン名及びＩＰアドレスを記録する。
【００４２】
ＩＭＳネットワークのドメイン名と対応するＩ−ＣＳＣＦｓのＩＰアドレスとを含むデータベースは，ＳＩＰレベルのデータベース内に維持されなければならない。なぜならば，ＳＩＰ要求は，要求（Ｒ）−ユニバーサルリソースインジケータ内にドメイン名かＩＰアドレスのいずれかを含んでもよいからである。ドメイン名をデータベースに保有するだけでは十分ではない。したがって，発呼者は被呼者が信頼できるネットワークにいるか，信頼できないネットワークにいるかを，被呼者のドメイン名又はＩＰアドレスがデータベースにあるかどうかを見ることによって調べることができる。
【００４３】
しかし，本発明の別の実施例では，Ｒ-ＵＲＩ内のドメイン名の代わりに，ＩＰアドレスが受信されたときにはいつでも，逆ＤＮＳ（ドメイン名サーバ）問合せをすることができる。このように，次に掲げる簡易化された解決策もまた可能であり，それは図２を参照して記述される。
【００４４】
データベースは，ホームネットワークが信頼するＩＭＳネットワークのドメイン名と共に保存される。
【００４５】
ステップＳ１では，要求がドメイン名を含むかどうか判定される。
【００４６】
もしそうならば，次にステップＳ２へ移行し，そこでそのドメインがデータベースにあるかどうか調べられる。もしそうならば，隣接ホップは信頼できるドメインと考えられ，対応する手順が適用される（ステップＳ３）。もしドメインがデータベースになければ，そのとき，隣接ホップは信頼できないドメインと考え，対応する手順を適用する−ステップＳ４。
【００４７】
もし，被呼者が信頼できない者であれば，メッセージを破棄するか，それに代えて修正するようにしてもよい。もし，メッセージが修正されるならば，発呼者を識別する情報は削除される。この情報はP-Assertedヘッダでもよい。これは，発呼者がプライバシを要求したとき，すなわちその識別情報をプライベートにしておきたいとき，に行われる。
【００４８】
もし，要求がドメイン名を含まないならば，Ｒ-ＵＲＩにおいてＩＰアドレスを持つ要求が受信されたかどうかを判定する−ステップＳ５。ステップＳ５及びＳ１は結合して単一のステップとしてもよい。もし，要求がＩＰアドレスを含むならば，次に対応するドメインを探すために，逆ＤＮＳ問合せが行われる−ステップＳ６。それは，そのＩＰアドレスと関連するドメインの名前を求めてドメイン名サーバに送られる要求である。次のステップは，データベースのチェックを行うステップＳ２である。
【００４９】
本発明の更なる実施例においては，データベースはホームネットワークのＳ−ＣＳＣＦにのみ保存されており，それはホームネットワークが信頼するすべての既知のＩＭＳネットワークドメイン名を記録する。
【００５０】
もし，Ｒ−ＵＲＩがドメイン名の代わりにＩＰアドレスを含む（したがって，データベースにおいてチェックできない）ときは，単純に次のホップは信頼できないドメインと推定する。
【００５１】
本発明のまた更なる実施例においては，ＮＤＳネットワークドメインセキュリティがセキュリティゲートウェイ（ＳＰＤ）において，そのゲートウェイが一部となっているドメインのＣＳＣＦから来るＩＰパケットがセキュアなコネクション上で送信されるように構成される。もし，宛先へのセキュアなコネクションが存在しないときは，パケットは単純に廃棄され，ＩＣＭＰインターネット制御メッセージプロトコルメッセージが生成される。ＩＣＭＰは，ゲートウェイ又は宛先ホストと，情報源ホストとの間でＩＰデータグラム処理に関してエラーメッセージ及び制御メッセージを配信するインターネットプロトコルである。ＩＣＭＰは，例えばＩＰデータグラム処理におけるエラーを報告することができる。ＩＣＭＰは通常ＩＰプロトコルの一部である。したがって，ホームネットワークは常に隣接ホップを信頼できると推定しP-Asserted-Identityを削除しない。もし，たまたま隣接ホップが信頼できないときは，パケットは廃棄され，被呼者には届かない。
【００５２】
この解決策の結果ＣＳＣＦは，信頼できるドメインに属するＳＩＰエンティティと通信することができるだけになる。
【００５３】
第三世代パートナシッププロジェクト仕様番号ＴＳ３３．２１０，３．３．０版を参考としてここに引用する。この文書はネットワークドメインセキュリティアーキテクチャの概要を述べている。図３は本発明の実施例が適用できるこのアーキテクチャを示している。
【００５４】
初めにネットワーク間及びそれぞれのネットワーク内に存在することができるＺａ及びＺｂインタフェースに関して説明する。この説明は３ＧＰＰ ＴＳ３３．２１０ Ｖ６．０．０（２００２−１２）技術仕様リリース６を引用している。図３は二つのセキュリティドメイン及びこれらドメインのエンティティ間のＺａ及びＺｂインタフェースを示している。
【００５５】
このインタフェースは本来のＩＰベースのプロトコルの保護に対して定義されている。
【００５６】
Ｚａ−インタフェース（ＳＥＧ−ＳＥＧ）
Ｚａ−インタフェースは，セキュリティドメイン間のすべてのＮＤＰ／ＩＰ（ネットワークドメインセキュリティ／インターネットプロトコル）トラヒックを包含する。ＳＥＧ（セキュリティゲートウェイ）は，それらの間のセキュアＥＳＰ（カプセル化セキュリティペイロード）トンネルの交渉，確立及び維持のために，ＩＫＥ（インターネットかぎ交換）を利用する。ローミング協定に従って，ＳＥＧ間トンネルは通常，常に利用できるが，それらは必要に応じて確立することもできる。ＥＳＰは暗号化と認証／完全性の双方と共に利用されることになるが，認証／完全性のみのモードも許される。トンネルはその後に，セキュリティドメインＡとセキュリティドメインＢとの間のＮＤＳ／ＩＰトラヒックを転送するために利用される。
【００５７】
一つのＳＥＧは，すべてのローミング相手のうちある特定の一部へのサービス提供専用にすることができる。これは，維持する必要があるＳＡとトンネルの数を限定する。
【００５８】
この仕様に適合するすべてのセキュリティドメインは，Ｚａ−インタフェースを運用しなければならない。
【００５９】
Ｚｂ−インタフェース（ＮＥ−ＳＥＧ／ＮＥ−ＮＥ）
Ｚｂ−インタフェースは，ＳＥＧ及びＮＥ間と，同じセキュリティドメイン内のＮＥ間とに位置する。Ｚｂ−インタフェースの実装は選択的である。もし実装されるなら，ＥＳＰ＋ＩＫＥを実装しなければならない。
【００６０】
Ｚｂ−インタフェース上で，ＥＳＰは常に認証／完全性保護と共に利用しなければならない。暗号化の利用は選択的である。ＥＳＰセキュリティアソシエーションはセキュリティ保護を必要とするすべての制御プレーントラヒックに使用しなければならない。
【００６１】
セキュリティアソシエーションが必要になったとき確立されるか，常に先行して確立するかは，セキュリティドメイン運用者の判断による。セキュリティアソシエーションはその後に，ＮＥ間のＮＤＳ／ＩＰトラヒック交換に利用される。
【００６２】
Ｚａ−インタフェース上に確立されたセキュリティポリシは，ローミング協定に従う。これは，Ｚｂ−インタフェース上に強制されるセキュリティポリシとは異なり，セキュリティドメイン運用者によって一方的に判断される。
【００６３】
ＮＤＳ／ＩＰアーキテクチャの基本的な考え方は，ホップごと（ｈｏｐ−ｂｙ−ｈｏｐ）にセキュリティを提供することである。これは運用に関する「連鎖トンネルモデル」又は「ハブとスポークモデル」に合致している。また，ホップごとのセキュリティは，セキュリティドメインの内部と他の外部セキュリティドメインとで，別のセキュリティポリシを運用することを容易にする。
【００６４】
ＮＤＳ／ＩＰでは，ＮＤＳ／ＩＰトラヒックのためにセキュリティゲートウェイ（ＳＥＧ）だけが他のセキュリティドメインにあるエンティティとの直接通信にかかわることができる。ＳＥＧは次に，セキュリティドメイン間のトンネルモードにおけるＩＰｓｅｃによって保障されたＥＳＰセキュリティアソシエーションを確立し，そして維持する。ＳＥＧは，通常，特定の対向ＳＥＧが常に利用可能な少なくとも一つのＩＰｓｅｃトンネルを維持する。ＳＥＧは，各インタフェース用のＳＡＤデータベースとＳＰＤデータベースとを論理的に分けて維持する。
【００６５】
ＮＥはＳＥＧ又は同一セキュリティドメイン内の他のＮＥへ必要に応じたセキュリティアソシエーションを確立し，そして維持することも可能である。一つのセキュリティドメインにあるＮＥから異なるセキュリティドメインにあるＮＥへのすべてのＮＤＳ／ＩＰトラヒックは，ＳＥＧを経由して送られ，あて先に向けてホップごとのセキュリティ保護が与えられる。
【００６６】
運用者は，通信しあう二つのセキュリティドメイン間で唯一のＥＳＰセキュリティアソシエーションを確立するように判断してもよい。これは粗いセキュリティ粒度を目指している。これはトラヒックフローの解析に対してある一定の保護を与える利点があるが，通信しあうエンティティ間に与えられるセキュリティ保護に差をつけることができないという欠点がある。これは，通信しあうエンティティの自由裁量によってより細かいセキュリティ粒度について交渉することを排除しない。
【００６７】
本発明の実施例では，発呼者のＳＥＧは，被呼者へのパケットがセキュアなコネクション上で該被呼者のＳＥＧに送信されるかどうかを判定することになる。もし，セキュアなコネクションがなければパケットは廃棄される。もしセキュアなコネクションがあればパケットは送信される。
【００６８】
実施例の一つの変形では，もしセキュアなコネクションがないならば，発呼者のＳＥＧはメッセージ，すなわちP-Assertedヘッダ，から識別情報を削除する。かくして修正されたメッセージは次に被呼者に送られる。
【００６９】
本発明の実施例では，P-Assertedヘッダ情報はパケットから削除される。P-Assertedヘッダ情報がない本発明の代替実施例では，発呼者の識別に関する識別情報は削除される。
【００７０】
データベースは信頼できる者だけの識別情報を保有するように記述されている。一つの変形実施例では，信頼できない者の識別情報のみ，又は信頼できる者と信頼できない者の両者について，それらが信頼できるかどうかの指示情報と共に保有することができる。
【００７１】
ＧＰＲＳシステムがある一つの実施例の記述は例示のためであり，他のシステムが本発明の代替実施例として利用されてもよいことを認識すべきである。
【００７２】
本発明の実施例は移動機のようなユーザ装置に関して記述されているが，本発明の実施例は他の適当ないかなる種類のユーザ装置にも適用できることを認識すべきである。
【００７３】
本発明の例はＩＭＳシステム及びＧＰＲＳネットワークの環境で記述されてきた。しかし本発明は，他のいかなるアクセス技術にも適用可能である。さらに，示された例は，ＳＩＰ対応のエンティティを有するＳＩＰネットワーク環境で記述されている。しかし，本発明は，無線システム又は固定回線どちらでもよい他の適当ないかなる通信システムにも，他の適当ないかなる標準にも，そして他の適当ないかなるプロトコルにも適用可能である。
【００７４】
本発明の実施例は呼状態制御機能の環境で議論されてきた。しかし，本発明の実施例は適用可能ならば他のネットワーク要素にも適用可能である。
【００７５】
ここで，以上は本発明の例示としての実施例を記述しているが，本願の請求項に規定された発明の範囲を逸脱することなく，開示された解決策にいくつかの変形及び修正が可能であることに注意すべきである。
【技術分野】
【０００１】
本発明は，通信方法に関する。
【背景技術】
【０００２】
通信システムは，ユーザ装置及び／又は通信システムに関連した他のノードのような２以上のエンティティ間の通信セッションを可能にする設備としてとらえることができる。その通信は，例えば，音声，データ，マルチメディアなどの通信を含むことができる。セッションは，例えば，ユーザ間の電話呼，多地点会議セッション，又はユーザ装置と，例えばサービス提供者のサーバなどアプリケーションサーバ（ＡＳ）との間の通信セッションであってもよい。これらセッションの確立は，一般的にはユーザにさまざまなサービスを提供することを可能にする。
【０００３】
通信システムは，典型的には所定の標準又は仕様に基づいて動作し，それら標準又は仕様はその通信システムに関連するさまざまなエンティティが何をすることが許され，またそれがどのように達成されるかについて列挙している。例えば，その標準又は仕様は，ユーザ，より正確にはユーザ装置が，回線交換サービス及び／又はパケット交換サービスを受けられるかどうかを定義してもよい。そのコネクションに使うべき通信プロトコル及び／又はパラメータをも定義してもよい。言い換えれば，そのシステムによって通信を可能にするために，通信が基づくことのできる特定の「規定」（ｒｕｌｅｓ）のセットが定義されなければならない。
【０００４】
ユーザ装置に無線通信を提供するいくつかの通信システムが知られている。無線システムの一例は，公衆陸上移動体ネットワーク（ＰＬＭＮ）である。ＰＬＭＮは，典型的にはセルラ技術に基づいている。セルラシステムでは，基地局（ＢＴＳ）又は類似のアクセスエンティティが移動機（ＭＳ）としても知られる無線ユーザ装置（ＵＥ）に，それらエンティティ間の無線インタフェースを介してサービスを提供する。ユーザ装置と通信ネットワーク要素との間の無線インタフェース上の通信は，適当な通信プロトコルに基づくことができる。基地局装置及びその他通信のために必要とされる装置の運用は１又はいくつかの制御エンティティによって制御することができる。さまざまな制御エンティティが相互接続されていてもよい。
【０００５】
また，１以上のゲートウェイノードが，セルラネットワークと他のネットワークとを接続するために提供されもよい。他のネットワークとは，例えば公衆交換電話ネットワーク（ＰＳＴＮ）及び／又はＩＰ（インターネットプロトコル）のような他の通信ネットワーク及び／又は他のパケット交換データネットワークである。そのような構成において，移動体通信ネットワークはユーザが無線ユーザ装置を使って外部ネットワーク，ホスト又は特定サービス提供者が提供するサービスを利用することできるアクセスネットワークを提供する。次にアクセスポイント又は移動体通信ネットワークのゲートウェイノードは，外部ネットワーク又は外部ホストへの更なるアクセスを提供する。例えば，もし要求されたサービスが他のネットワークに存在するサービス提供者によって提供されているならば，そのサービス要求はゲートウェイを介してそのサービス提供者に届けられる。その経路設定は，移動体ネットワーク運用者が保有している移動体加入者データの定義に基づいてなされてもよい。
【０００６】
通信システムの加入者のようなユーザに対して提供できるサービスの一例は，いわゆるマルチメディアサービスである。マルチメディアサービスを提供できるようにした通信システムのいくつかはインターネットプロトコル（ＩＰ）マルチメディアネットワークとして知られている。ＩＰマルチメディア（ＩＭ）機能はＩＰマルチメディアコアネットワーク（ＣＮ）サブシステム，すなわち短く称するとＩＰマルチメディアサブシステム（ＩＭＳ），によって提供できる。ＩＭＳは，マルチメディアサービスを提供するためにさまざまなネットワークエンティティを含んでいる。ＩＭＳサービスは，数あるサービスの中でも，移動体ユーザ装置間のＩＰコネクションを提供することを意図している。
【０００７】
第三世代パートナシッププロジェクト（３ＧＰＰ）は，ＩＭＳサービス提供のための一般パケット無線サービス（ＧＰＲＳ）の利用法を規定している。それゆえにこれが，以降の説明の中でＩＭＳサービスを可能にするバックボーン通信ネットワークの例として用いられる。一例としての一般パケット無線サービス（ＧＰＲＳ）動作環境は，１以上のサブネットワークサービスエリアを有し，それらはＧＰＲＳバックボーンネットワークによって相互接続されている。一つのサブネットワークはいくつかのパケットデータサービスノード（ＳＮ）を備える。このアプリケーションでは，サービスノードはサービス提供ＧＰＲＳサポートノード（ＳＧＳＮ）と呼ぶことにする。各々のＳＧＳＮは，少なくとも一つの移動体通信ネットワーク，典型的には基地局システム，に接続されている。その接続は，典型的には，無線ネットワークコントローラ（ＲＮＣ）又は基地局コントローラ（ＢＳＣ）のような他のアクセスシステムコントローラによって，パケットサービスをいくつかの基地局を経由して移動体ユーザ装置に提供することができるような方法でなされる。中間移動体通信ネットワークは，サービスノードと移動体ユーザ装置との間のパケット交換データ伝送を提供する。さまざまなサブネットワークは，順に，ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）を経由して外部データネットワーク，例えば公衆交換データネットワーク（ＰＳＰＤＮ），に接続される。ＧＰＲＳサービスはこのようにして移動体データ端末と外部データネットワークとの間のパケットデータ伝送を可能にする。
【０００８】
このようなネットワークでは，パケットデータセッションはネットワーク上でトラヒックフローを搬送するために確立される。そのようなパケットデータセッションはしばしば，パケットデータプロトコル（ＰＤＰ）コンテキストと呼ばれる。ＰＤＰコンテキストは，ユーザ装置と，無線ネットワークコントローラと，ＳＧＳＮとの間に提供される無線アクセスベアラ，及びサービス提供ＧＰＲＳサポートノードとゲートウェイＧＰＲＳサポートノードとの間に提供される交換パケットデータチャネルを含んでもよい。
【０００９】
ユーザ装置と他者との間のデータ通信セッションは，次に，確立されたＰＤＰコンテキスト上で実行されることになる。各ＰＤＰコンテキストは１以上のトラヒックフローを搬送することができるが，一つの特定ＰＤＰコンテキスト内にあるすべてのトラヒックフローは，そのネットワーク内での伝送に関しては同じ方法で取り扱われる。このＰＤＰコンテキスト取扱い要求条件は，トラヒックフローに付随するＰＤＰコンテキスト取扱い属性に基づく。
【００１０】
第三世代パートナシッププロジェクト（３ＧＰＰ）は，また，ユーザ装置のユーザにマルチメディアサービスへのアクセスを提供する第三世代（３Ｇ）コアネットワークのための参照アーキテクチャも規定している。このコアネットワークは三つの主要ドメインに分割される。それらは，回線交換（ＣＳ）ドメイン，パケット交換（ＰＳ）ドメイン及びインターネットプロトコルマルチメディア（ＩＭ）ドメイン，である。これらのうちの後者であるＩＭドメインは，マルチメディアサービスが適切に管理されることを確実にするためにある。
【００１１】
ＩＭドメインは，インターネット技術タスクフォース（ＩＥＴＦ）によって開発されたセッション開始プロトコル（ＳＩＰ）を提供する。セッション開始プロトコル（ＳＩＰ）は，１以上の参加者（終点）に関するセッションを生成，修正及び終了させるためのアプリケーション層制御プロトコルである。ＳＩＰは，一般的には，インターネット内にある２以上の終点間のセッションについて，これら終点に対しセッションの意味を知らしめることによってこのセッションを開始させるように開発された。ＳＩＰベースの通信システムに接続されたユーザは，標準化されたＳＩＰメッセージに基づいて通信システムのさまざまなエンティティと通信してもよい。ユーザ装置上であるアプリケーションを実行させるユーザ装置，すなわちユーザは，特定セッションへの招待がそれら終点に正しく配信されるようＳＩＰバックボーンに登録される。これを実現するため，ＳＩＰはデバイスとユーザのための登録機構を提供し，そしてこのＳＩＰセッション招待を正しく届けるために位置情報サーバ及び登録サーバのような機構に適用される。ＳＩＰ通知手段によって提供可能なセッションの例としては，インターネットマルチメディア会議，インターネット電話呼及びマルチメディア配信などがある。
【００１２】
ここでＩＥＴＦ文書ＲＦＣ３３２５を参照文献として引用する。この文書はＳＩＰに対する私的拡張を述べているが，これによれば信頼できるＳＩＰサーバのネットワークがエンドユーザ又はエンドシステムの識別情報を主張することを可能にし，エンドユーザが要求したプライバシについての指示を搬送することができる。この拡張は，ネットワーク主張識別情報のための短期要求条件に定義された「信頼できるドメイン」内で利用できる。そのような「信頼できるドメイン」内にあるノードは，各自の識別情報を公に主張すること，およびプライバシが要求されるときはその信頼できるドメイン外に識別情報を出さないよう責任を持つこと，がそのユーザ及び最終システムによって明確に信頼されている。
【００１３】
ＲＦＣ３３２５に記述されたプライバシに関する手続を適用することができるように，隣接ホップネットワークの信頼性を検知する必要がある。もし隣接ホップが信頼できるならば，さまざまなプライバシ選択肢に応じた手続がその隣接ホップに対して送られる。そうでなければ，プライバシに関する手続が実行されなければならない。
【００１４】
例として，発呼者が識別情報のプライバシを要求する場合は，P-Asserted-Identityヘッダは，被呼者に届く前に削除されなければならない。発呼者によって送信されたメッセージは，送信者を識別するためのP-Asserted-Identityヘッダと呼ばれるヘッダを含む。このヘッダの形式は，もし送信者が公に知られたユーザ識別情報を持っているならば，<sip:user1_public1@home1.net>である。この発呼者のホームネットワークは，被呼者のホームネットワークが信頼できないときだけ，そのヘッダを削除しなければならない。もし，被呼者のホームネットワーク（それは発呼者のホームネットワークの隣接ホップである）が信頼できるならば，発呼者のホームネットワークはそのヘッダを削除しない。これはＲＦＣ３２５５に従うために必要であり，このＲＦＣ３２５５によれば，P-Asserted-Identityヘッダは信頼できるドメイン内の最後の要素によって取り除かれなければならない。
【００１５】
ＲＦＣ３２５５では，提案された機構は，ＵＲＩ（一般にはＳＩＰ ＵＲＩ）及び選択的に表示用氏名を含むP-Asserted-Identityと呼ばれるヘッダフィールドに頼る。メッセージを取り扱うプロキシサーバは，発呼ユーザをなんらかの方法（例えば，ダイジェスト認証）で認証したのちに，そのメッセージにP-Asserted-Identityヘッダフィールドを挿入することができ，それを他の信頼できるプロキシに転送することができる。プロキシが信頼しないプロキシサーバ又はＵＡにメッセージを転送しようとするとき，もしユーザがプライベートにとどめたいと要求するならば，プロキシはすべてのP-Asserted-Identityヘッダフィールド値を削除する。ユーザはこの種のプライバシを要求することができる。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開平６−９５９９１号公報
【非特許文献】
【００１７】
【非特許文献１】Jennings, C.，RFC3325，"SIP Asserted Identity"，IETF，２００２年１１月
【発明の概要】
【発明が解決しようとする課題】
【００１８】
正しい場所で適用されるべき手続き（ｐｒｏｃｅｄｕｒｅ）にとっては，隣接ホップの信頼性が何らかの方法で検知されなければならない。
【図面の簡単な説明】
【００１９】
【図１】本発明を実施できる通信システムを示す図である。
【図２】本発明の一実施例の動作を説明するフローチャートである。
【図３】本発明の実施例を提供可能な環境を示す図である。
【発明を実施するための形態】
【００２０】
本発明の第１の態様は，第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間での通信方法であって，この方法は，
前記被呼者のアドレスを第１のネットワークにおいて判定するステップと；
前記アドレスに基づいて前記被呼者が信頼できるネットワークにいるかどうかを判定するステップと；
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて被呼者と発呼者との間の通信を制御するステップと；
を有する。
【００２１】
本発明の第２の態様は，発呼者がいる第１のネットワークと，発呼者がいる第２のネットワークとを備える通信システムであって，前記第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と；
前記被呼者が信頼できるネットワーク内にいるかどうかを，前記アドレスに基づいて判定するための判定手段と；
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて，被呼者と発呼者との間の通信を制御するための制御手段と；
を備える。
【００２２】
第３の態様は，第２のネットワーク内にいる発呼者に発呼するように構成された発呼者のいる第１のネットワークであって，該第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と；
前記被呼者が信頼できるネットワークにいるかどうかを，前記アドレスに基づいて判定するための判定手段と；
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて，被呼者と発呼者との間の通信を制御するための制御手段と；
を備える。
【００２３】
第４の態様は，第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法であって，この方法は，
前記第２のネットワークとの間にセキュアコネクションがあるかどうかを，第１のネットワークにおいて判定するステップと；
もし前記第２のネットワークとの間にセキュアコネクションがないと判定されたら，発呼者から被呼者へのメッセージを廃棄又は修正するステップと；
を有する。
【実施例】
【００２４】
本発明の実施例は特にＲｅｌ−５ ＩＭＳネットワークに関連するがこれに限定されるものではない。本発明の実施例はまた，ＩＭＳネットワークの他のバージョンに適用してもよい。本発明の実施例は他のＳＩＰネットワークに適用してもよい。本発明のいくつかの実施例はＳＩＰ環境及びＩＭＳ環境外のより広範な応用を見いだすであろう。
【００２５】
本発明のある実施例は例示として第三世代（３Ｇ）移動体通信システムにおける一例としてのアーキテクチャを参照して記述する。しかし，ある実施例は他のいかなる適切なネットワーク形態に適用されてもよいと理解される。移動体通信システムは典型的には，通常はユーザ装置と通信システムの基地局との間の無線インタフェースを介して，複数の移動体ユーザ装置にサービスを提供するよう構成される。移動体通信システムは，無線アクセスネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）とに論理的に分割されてもよい。
【００２６】
本発明のよりよい理解のために，ここで添付の図面を例として参照する。図１を参照して，本発明の実施が可能なネットワークアーキテクチャの例を示す。図１は，ＩＰマルチメディアネットワーク加入者にＩＰマルチメディアサービスを提供するためのＩＰマルチメディアネットワーク４５を示す。ＩＰマルチメディア（ＩＭ）機能は，サービスを提供するためのさまざまなエンティティを含むコアネットワーク（ＣＮ）によって提供することができる。
【００２７】
基地局３１及び４３は，無線インタフェースを介して移動体ユーザ，すなわち加入者，の移動体ユーザ装置３０及び４４へ信号を送信し，また移動体ユーザ装置から信号を受信するように構成される。同様に，各移動体ユーザ装置は無線インタフェースを介して基地局に信号を送信し，また基地局から信号を受信することができる。図１の簡略化された記載では，基地局３１及び４３は異なる無線アクセスネットワーク（ＲＡＮ）に属している。図示する構成では，ユーザ装置３０と４４のいずれも，基地局３１及び４３に連携した二つのアクセスネットワークをそれぞれ介してＩＭＳネットワーク４５にアクセスすることができる。図１では，明瞭化のために二つの無線アクセスネットワークのみの基地局を示しているが，典型的な移動体通信ネットワークにおいては，通常，多くの無線アクセスネットワークが含まれていることを認識しなければならない。
【００２８】
３Ｇ無線アクセスネットワーク（ＲＡＮ）は，典型的には適当な無線ネットワークコントローラ（ＲＮＣ）によって制御される。このコントローラは，明瞭性のために図示しない。コントローラは基地局ごとに割り当てられてもよいし，若しくは複数の基地局をコントローラが制御することもできる。コントローラが，複数の基地局を制御するために，個々の基地局と無線アクセスネットワークレベルとの双方に提供されるといった解決策も知られている。したがって，ネットワークコントローラの名称，位置及び数は，システムに依存することを認識しなければならない。
【００２９】
移動体ユーザは，ネットワークに接続するため，インターネットプロトコル（ＩＰ）通信に適合した任意の適当な移動体デバイスを使ってもよい。例えば，移動体ユーザは，パーソナルコンピュータ（ＰＣ），パーソナルデータアシスタント（ＰＤＡ），移動機（ＭＳ）などの手段によってセルラネットワークにアクセスしてもよい。次に掲げる例は移動機環境において記述されている。
【００３０】
本技術における当業者ならば，典型的な移動機の特徴及び動作をよく知っている。したがって，これら特徴についての詳細な説明は不要である。ユーザは，電話呼を発信及び受信したり，データをネットワークから受信したり，データをネットワークに送信したり，例えばマルチメディアコンテンツを体験したり，といった仕事のために移動機を使ってもよいことを特筆すれば十分である。移動機は，典型的にはこれらの仕事を達成するために，プロセッサ及びメモリ手段を備えている。移動機は，信号を無線で移動体通信ネットワークの基地局から受信したり，基地局へ送信したりするためにアンテナ手段を含んでもよい。移動機はまた，移動体ユーザ装置のユーザに画像及び他の図形情報を表示するためのディスプレイを備えてもよい。スピーカ手段があってもよい。移動機の動作は，制御ボタン，音声コマンドなどのような適当なユーザインタフェース手段によって制御してもよい。
【００３１】
図１には明瞭にするため二つの移動機のみを示しているが，移動体通信ネットワークの各基地局といくつかの移動機とが同時に通信状態にあってもよいことを認識しなければならない。また，移動機はいくつかの同時セッション，例えばいくつかのＳＩＰセッション及び活性化されたＰＤＰコンテキストを持ってもよい。また，ユーザは電話呼をなし，また同時に少なくとも一つの他サービスに接続してもよい。
【００３２】
コアネットワーク（ＣＮ）エンティティは，いくつかの無線アクセスネットワークを経由した通信を可能にするため，また他のセルラシステム及び／又は固定回線通信システムのような１以上の通信システムと単一通信システムとをインタフェースするために，典型的にはさまざまな制御エンティティ及びゲートウェイを含む。図１において，サービス提供ＧＰＲＳサポートノード３３，４２及びゲートウェイＧＰＲＳサポートノード３４，４０はネットワークにおいて，それぞれＧＰＲＳサービス３２及び４１を提供するためにある。
【００３３】
無線アクセスネットワークは，典型的には，適当なコアネットワークエンティティ又はサービス提供一般パケット無線サービスサーポートノード（ＳＧＳＮ）３３及び４２のようなエンティティ（ただしそれに限定はされない）に接続される。図示されてはいないが，各ＳＧＳＮは，典型的には，各ユーザ装置の加入契約に関連する情報を保有するよう構成された指定加入者データベースにアクセスできる。
【００３４】
無線アクセスネットワーク内のユーザ装置は，典型的には無線ベアラ（ＲＢ）と呼ばれる無線ネットワークチャネルを介して，無線ネットワークコントローラと通信してもよい。各ユーザ装置は無線ネットワークコントローラとの間に同時に張られる１以上の無線ネットワークチャネルを有してもよい。無線アクセスネットワークコントローラは，例えばI uインタフェース上の適当なインタフェースを介して，サービス提供ＧＰＲＳサポートノードと通信する。
【００３５】
サービス提供ＧＰＲＳサポートノードは，次に，典型的にはＧＰＲＳバックボーンネットワーク３２，４１を介して，ゲートウェイＧＰＲＳサポートノードと通信する。このインタフェースは，通常，交換パケットデータインタフェースである。サービス提供ＧＰＲＳサポートノード及び／又はゲートウェイＧＰＲＳサポートノードは，ネットワーク内のＧＰＲＳサービスを提供するためにある。
【００３６】
アクセスエンティティにあるユーザ装置と，ゲートウェイＧＰＲＳサポートノードとの間の全体の通信は，一般にパケットデータプロトコル（ＰＤＰ）環境によって提供される。全体のＰＤＰコンテキストは通常特定ユーザ装置とゲートウェイＧＰＲＳサポートノードとの間の通信路を提供し，いったん確立されたならば，典型的には複数フローを搬送することができる。各フローは通常，例えば，特定サービス及び／又は特定サービスの１メディアコンポーネントを表す。したがって，ＰＤＰコンテキストはしばしば，ネットワークを横切る１以上のフローのための論理的通信路を表す。ユーザ装置とサービス提供ＧＰＲＳサポートノードとの間のＰＤＰコンテキストを実装するために，無線アクセスベアラ（ＲＡＢ）が確立されなければならず，それは通常ユーザ装置のためのデータ転送を可能にする。これら論理的及び物理的チャネルの実装は本技術の当業者には知られており，それ故ここではこれ以上議論しない。
【００３７】
ユーザ装置３０，４４は，ＧＰＲＳネットワークを介して，一般的にはＩＭＳに接続されているアプリケーションサーバに接続してもよい。
【００３８】
この通信システムは，サーバとして知られるネットワークエンティティによって取り扱われるさまざまなネットワーク機能手段によって，サービスをユーザ装置に提供してもよいように開発された。例えば，現在の第三世代（３Ｇ）無線マルチメディアネットワークアーキテクチャでは，さまざまな機能を取り扱うためにいくつかのさまざまなサーバが使われることを想定している。これら機能は，呼セッション制御機能（ＣＳＣＦｓ）のような機能を含む。呼セッション制御機能は，プロキシ呼セッション制御機能（Ｐ-ＣＳＣＦ)３５及び３９，問合せ（interrogating）呼セッション制御機能（Ｉ−ＣＳＣＦ）３７，及びサービス提供呼セッション制御機能（Ｓ−ＣＳＣＦ）３６及び３８，といったさまざまなカテゴリに分割し得る。ＩＭＳシステムを介してアプリケーションサーバによって提供されるサービスを利用したいと思うユーザは，サービス提供制御エンティティに登録する必要があろう。サービス提供呼セッション制御機能（Ｓ−ＣＳＣＦ）は，通信システムからサービス要求をすることができるように，ユーザが登録する必要のある３Ｇ ＩＭＳ構成内のエンティティを形成してもよい。ＣＳＣＦｓは，ＵＭＴＳシステムのＩＭＳネットワークを規定する。
【００３９】
同様な機能は，さまざまなシステムにおいてさまざまな名称で呼ぶことができることを認識しなければならない。例えば，あるアプリケーションではＣＳＣＦｓは呼状態制御機能と呼ばれるかも知れない。
【００４０】
通信システムは，バックボーンネットワークによって要求される通信リソースを与えられたユーザが，その通信システム上で所望のサービス要求を送信することによってサービスの利用を起動しなければならないように構成されていてもよい。例えば，ユーザは適当なネットワークエンティティから，セッション，トランザクション又は他の種類の通信を要求してもよい。
【００４１】
本発明の一実施例では，データベースが発呼者のホームネットワークのＳ-ＣＳＣＦにあって，そのデータベースはホームネットワークが信頼するすべての既知のＩＭＳネットワークドメイン名及びＩＰアドレスを記録する。
【００４２】
ＩＭＳネットワークのドメイン名と対応するＩ−ＣＳＣＦｓのＩＰアドレスとを含むデータベースは，ＳＩＰレベルのデータベース内に維持されなければならない。なぜならば，ＳＩＰ要求は，要求（Ｒ）−ユニバーサルリソースインジケータ内にドメイン名かＩＰアドレスのいずれかを含んでもよいからである。ドメイン名をデータベースに保有するだけでは十分ではない。したがって，発呼者は被呼者が信頼できるネットワークにいるか，信頼できないネットワークにいるかを，被呼者のドメイン名又はＩＰアドレスがデータベースにあるかどうかを見ることによって調べることができる。
【００４３】
しかし，本発明の別の実施例では，Ｒ-ＵＲＩ内のドメイン名の代わりに，ＩＰアドレスが受信されたときにはいつでも，逆ＤＮＳ（ドメイン名サーバ）問合せをすることができる。このように，次に掲げる簡易化された解決策もまた可能であり，それは図２を参照して記述される。
【００４４】
データベースは，ホームネットワークが信頼するＩＭＳネットワークのドメイン名と共に保存される。
【００４５】
ステップＳ１では，要求がドメイン名を含むかどうか判定される。
【００４６】
もしそうならば，次にステップＳ２へ移行し，そこでそのドメインがデータベースにあるかどうか調べられる。もしそうならば，隣接ホップは信頼できるドメインと考えられ，対応する手順が適用される（ステップＳ３）。もしドメインがデータベースになければ，そのとき，隣接ホップは信頼できないドメインと考え，対応する手順を適用する−ステップＳ４。
【００４７】
もし，被呼者が信頼できない者であれば，メッセージを破棄するか，それに代えて修正するようにしてもよい。もし，メッセージが修正されるならば，発呼者を識別する情報は削除される。この情報はP-Assertedヘッダでもよい。これは，発呼者がプライバシを要求したとき，すなわちその識別情報をプライベートにしておきたいとき，に行われる。
【００４８】
もし，要求がドメイン名を含まないならば，Ｒ-ＵＲＩにおいてＩＰアドレスを持つ要求が受信されたかどうかを判定する−ステップＳ５。ステップＳ５及びＳ１は結合して単一のステップとしてもよい。もし，要求がＩＰアドレスを含むならば，次に対応するドメインを探すために，逆ＤＮＳ問合せが行われる−ステップＳ６。それは，そのＩＰアドレスと関連するドメインの名前を求めてドメイン名サーバに送られる要求である。次のステップは，データベースのチェックを行うステップＳ２である。
【００４９】
本発明の更なる実施例においては，データベースはホームネットワークのＳ−ＣＳＣＦにのみ保存されており，それはホームネットワークが信頼するすべての既知のＩＭＳネットワークドメイン名を記録する。
【００５０】
もし，Ｒ−ＵＲＩがドメイン名の代わりにＩＰアドレスを含む（したがって，データベースにおいてチェックできない）ときは，単純に次のホップは信頼できないドメインと推定する。
【００５１】
本発明のまた更なる実施例においては，ＮＤＳネットワークドメインセキュリティがセキュリティゲートウェイ（ＳＰＤ）において，そのゲートウェイが一部となっているドメインのＣＳＣＦから来るＩＰパケットがセキュアなコネクション上で送信されるように構成される。もし，宛先へのセキュアなコネクションが存在しないときは，パケットは単純に廃棄され，ＩＣＭＰインターネット制御メッセージプロトコルメッセージが生成される。ＩＣＭＰは，ゲートウェイ又は宛先ホストと，情報源ホストとの間でＩＰデータグラム処理に関してエラーメッセージ及び制御メッセージを配信するインターネットプロトコルである。ＩＣＭＰは，例えばＩＰデータグラム処理におけるエラーを報告することができる。ＩＣＭＰは通常ＩＰプロトコルの一部である。したがって，ホームネットワークは常に隣接ホップを信頼できると推定しP-Asserted-Identityを削除しない。もし，たまたま隣接ホップが信頼できないときは，パケットは廃棄され，被呼者には届かない。
【００５２】
この解決策の結果ＣＳＣＦは，信頼できるドメインに属するＳＩＰエンティティと通信することができるだけになる。
【００５３】
第三世代パートナシッププロジェクト仕様番号ＴＳ３３．２１０，３．３．０版を参考としてここに引用する。この文書はネットワークドメインセキュリティアーキテクチャの概要を述べている。図３は本発明の実施例が適用できるこのアーキテクチャを示している。
【００５４】
初めにネットワーク間及びそれぞれのネットワーク内に存在することができるＺａ及びＺｂインタフェースに関して説明する。この説明は３ＧＰＰ ＴＳ３３．２１０ Ｖ６．０．０（２００２−１２）技術仕様リリース６を引用している。図３は二つのセキュリティドメイン及びこれらドメインのエンティティ間のＺａ及びＺｂインタフェースを示している。
【００５５】
このインタフェースは本来のＩＰベースのプロトコルの保護に対して定義されている。
【００５６】
Ｚａ−インタフェース（ＳＥＧ−ＳＥＧ）
Ｚａ−インタフェースは，セキュリティドメイン間のすべてのＮＤＰ／ＩＰ（ネットワークドメインセキュリティ／インターネットプロトコル）トラヒックを包含する。ＳＥＧ（セキュリティゲートウェイ）は，それらの間のセキュアＥＳＰ（カプセル化セキュリティペイロード）トンネルの交渉，確立及び維持のために，ＩＫＥ（インターネットかぎ交換）を利用する。ローミング協定に従って，ＳＥＧ間トンネルは通常，常に利用できるが，それらは必要に応じて確立することもできる。ＥＳＰは暗号化と認証／完全性の双方と共に利用されることになるが，認証／完全性のみのモードも許される。トンネルはその後に，セキュリティドメインＡとセキュリティドメインＢとの間のＮＤＳ／ＩＰトラヒックを転送するために利用される。
【００５７】
一つのＳＥＧは，すべてのローミング相手のうちある特定の一部へのサービス提供専用にすることができる。これは，維持する必要があるＳＡとトンネルの数を限定する。
【００５８】
この仕様に適合するすべてのセキュリティドメインは，Ｚａ−インタフェースを運用しなければならない。
【００５９】
Ｚｂ−インタフェース（ＮＥ−ＳＥＧ／ＮＥ−ＮＥ）
Ｚｂ−インタフェースは，ＳＥＧ及びＮＥ間と，同じセキュリティドメイン内のＮＥ間とに位置する。Ｚｂ−インタフェースの実装は選択的である。もし実装されるなら，ＥＳＰ＋ＩＫＥを実装しなければならない。
【００６０】
Ｚｂ−インタフェース上で，ＥＳＰは常に認証／完全性保護と共に利用しなければならない。暗号化の利用は選択的である。ＥＳＰセキュリティアソシエーションはセキュリティ保護を必要とするすべての制御プレーントラヒックに使用しなければならない。
【００６１】
セキュリティアソシエーションが必要になったとき確立されるか，常に先行して確立するかは，セキュリティドメイン運用者の判断による。セキュリティアソシエーションはその後に，ＮＥ間のＮＤＳ／ＩＰトラヒック交換に利用される。
【００６２】
Ｚａ−インタフェース上に確立されたセキュリティポリシは，ローミング協定に従う。これは，Ｚｂ−インタフェース上に強制されるセキュリティポリシとは異なり，セキュリティドメイン運用者によって一方的に判断される。
【００６３】
ＮＤＳ／ＩＰアーキテクチャの基本的な考え方は，ホップごと（ｈｏｐ−ｂｙ−ｈｏｐ）にセキュリティを提供することである。これは運用に関する「連鎖トンネルモデル」又は「ハブとスポークモデル」に合致している。また，ホップごとのセキュリティは，セキュリティドメインの内部と他の外部セキュリティドメインとで，別のセキュリティポリシを運用することを容易にする。
【００６４】
ＮＤＳ／ＩＰでは，ＮＤＳ／ＩＰトラヒックのためにセキュリティゲートウェイ（ＳＥＧ）だけが他のセキュリティドメインにあるエンティティとの直接通信にかかわることができる。ＳＥＧは次に，セキュリティドメイン間のトンネルモードにおけるＩＰｓｅｃによって保障されたＥＳＰセキュリティアソシエーションを確立し，そして維持する。ＳＥＧは，通常，特定の対向ＳＥＧが常に利用可能な少なくとも一つのＩＰｓｅｃトンネルを維持する。ＳＥＧは，各インタフェース用のＳＡＤデータベースとＳＰＤデータベースとを論理的に分けて維持する。
【００６５】
ＮＥはＳＥＧ又は同一セキュリティドメイン内の他のＮＥへ必要に応じたセキュリティアソシエーションを確立し，そして維持することも可能である。一つのセキュリティドメインにあるＮＥから異なるセキュリティドメインにあるＮＥへのすべてのＮＤＳ／ＩＰトラヒックは，ＳＥＧを経由して送られ，あて先に向けてホップごとのセキュリティ保護が与えられる。
【００６６】
運用者は，通信しあう二つのセキュリティドメイン間で唯一のＥＳＰセキュリティアソシエーションを確立するように判断してもよい。これは粗いセキュリティ粒度を目指している。これはトラヒックフローの解析に対してある一定の保護を与える利点があるが，通信しあうエンティティ間に与えられるセキュリティ保護に差をつけることができないという欠点がある。これは，通信しあうエンティティの自由裁量によってより細かいセキュリティ粒度について交渉することを排除しない。
【００６７】
本発明の実施例では，発呼者のＳＥＧは，被呼者へのパケットがセキュアなコネクション上で該被呼者のＳＥＧに送信されるかどうかを判定することになる。もし，セキュアなコネクションがなければパケットは廃棄される。もしセキュアなコネクションがあればパケットは送信される。
【００６８】
実施例の一つの変形では，もしセキュアなコネクションがないならば，発呼者のＳＥＧはメッセージ，すなわちP-Assertedヘッダ，から識別情報を削除する。かくして修正されたメッセージは次に被呼者に送られる。
【００６９】
本発明の実施例では，P-Assertedヘッダ情報はパケットから削除される。P-Assertedヘッダ情報がない本発明の代替実施例では，発呼者の識別に関する識別情報は削除される。
【００７０】
データベースは信頼できる者だけの識別情報を保有するように記述されている。一つの変形実施例では，信頼できない者の識別情報のみ，又は信頼できる者と信頼できない者の両者について，それらが信頼できるかどうかの指示情報と共に保有することができる。
【００７１】
ＧＰＲＳシステムがある一つの実施例の記述は例示のためであり，他のシステムが本発明の代替実施例として利用されてもよいことを認識すべきである。
【００７２】
本発明の実施例は移動機のようなユーザ装置に関して記述されているが，本発明の実施例は他の適当ないかなる種類のユーザ装置にも適用できることを認識すべきである。
【００７３】
本発明の例はＩＭＳシステム及びＧＰＲＳネットワークの環境で記述されてきた。しかし本発明は，他のいかなるアクセス技術にも適用可能である。さらに，示された例は，ＳＩＰ対応のエンティティを有するＳＩＰネットワーク環境で記述されている。しかし，本発明は，無線システム又は固定回線どちらでもよい他の適当ないかなる通信システムにも，他の適当ないかなる標準にも，そして他の適当ないかなるプロトコルにも適用可能である。
【００７４】
本発明の実施例は呼状態制御機能の環境で議論されてきた。しかし，本発明の実施例は適用可能ならば他のネットワーク要素にも適用可能である。
【００７５】
ここで，以上は本発明の例示としての実施例を記述しているが，本願の請求項に規定された発明の範囲を逸脱することなく，開示された解決策にいくつかの変形及び修正が可能であることに注意すべきである。
【特許請求の範囲】
【請求項１】
第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法であって，
前記被呼者のアドレスを第一のネットワークにおいて判定するステップと，
前記被呼者が信頼できるネットワーク内にいるかどうかを前記アドレスに基づいて判定するステップと，
前記被呼者が信頼できるネットワークにいるかどうかに応じて，前記被呼者と発呼者との間の通信を制御するステップと，
を有する通信方法。
【請求項２】
前記被呼者宛のメッセージに，アドレスが含まれる請求項１記載の方法。
【請求項３】
前記メッセージはパケット形式である請求項２記載の方法。
【請求項４】
前記被呼者が信頼できるネットワーク内にいるかどうか判定するステップは，前記アドレスが信頼できるネットワークのデータベースに含まれているかどうか調べるステップを有する請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記データベースは前記第１のネットワーク内にある請求項４記載の方法。
【請求項６】
データベースをＣＳＣＦ又はセキュリティゲートウェイ内に設ける請求項４又は５記載の方法。
【請求項７】
前記データベースは，信頼できるネットワークに関するドメイン名及び選択的に信頼できるネットワークのＩＰアドレスを有する請求項４〜７のいずれか一項に記載の方法。
【請求項８】
前記のアドレスを判定するための判定ステップは，該アドレスがドメイン名を含むかどうかの判定ステップを有する請求項１〜７のいずれか一項に記載の方法。
【請求項９】
もし前記アドレスがドメイン名を含まないと判定されたら，該ドメイン名のための要求が送信される請求項８記載の方法。
【請求項１０】
前記要求はドメイン名サーバに送信される請求項９記載の方法。
【請求項１１】
もし前記アドレスがドメイン名を含まないと判定されたら，前記被呼者は信頼できないネットワーク内にいるものと推定する請求項８記載の方法。
【請求項１２】
もし前記被呼者が信頼できるネットワーク内にいないならば，前記の制御ステップは前記被呼者宛の少なくとも一つのメッセージを廃棄するステップを有する請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
もし前記被呼者が信頼できるネットワーク内にいないならば，該被呼者宛の少なくとも一つのメッセージを修正する請求項１〜１１のいずれか一項に記載の方法。
【請求項１４】
前記の被呼者宛の少なくとも一つのメッセージを，前記発呼者に関する識別情報を削除することによって修正する請求項１３記載の方法。
【請求項１５】
前記識別情報はP-Asserted-Identityヘッダである請求項１４記載の方法。
【請求項１６】
前記第１及び第２のネットワークは，ＳＩＰに従って動作する請求項１〜１５のいずれか一項に記載の方法。
【請求項１７】
前記の被呼者が信頼できるネットワーク内にいるかどうかを判定するステップは，発呼ネットワークから被呼ネットワーク宛のコネクションがセキュアであるかどうか判定するステップを有する請求項１〜１６のいずれか一項に記載の方法。
【請求項１８】
前記の被呼者が信頼できるネットワーク内にいるかどうか判定するステップは，発呼ネットワークのゲートウェイにおいて実行される請求項１７記載の方法。
【請求項１９】
前記の被呼者が信頼できるネットワーク内にいるかどうか判定するステップは，発呼ネットワークのゲートウェイと被呼ネットワークのゲートウェイとの間のコネクションがセキュアなコネクションかどうかを，前記発呼ネットワークのゲートウェイが判定するステップを有する請求項１８記載の方法。
【請求項２０】
発呼者を含む第１のネットワークと被呼者を含む第２のネットワークとを備える通信システムであって，前記第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかを前記アドレスに基づいて判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて前記被呼者と発呼者との間の通信を制御するための制御手段と，
を備える通信システム。
【請求項２１】
第２のネットワーク内にいる発呼者に発呼するように設定された発呼者を含む第１のネットワークであって，該第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかを前記アドレスに基づいて判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて前記被呼者と発呼者との間の通信を制御するための制御手段と，
を備えるシステム。
【請求項２２】
第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法であって，
前記第２のネットワークとのセキュアなコネクションがあるかどうかを前記第１のネットワークにおいて判定するステップと，
もし前記第２のネットワークとのセキュアなコネクションがないと判定されたら，前記発呼者から被呼者宛のメッセージを廃棄又は修正するステップと，
を有する通信方法。
【請求項２３】
前記の判定ステップはゲートウェイにおいて実行される請求項２２記載の方法。
【請求項２４】
前記ゲートウェイはセキュリティゲートウェイである請求項２３記載の方法。
【請求項１】
第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法であって，
前記被呼者のアドレスを第一のネットワークにおいて判定するステップと，
前記被呼者が信頼できるネットワーク内にいるかどうかを前記アドレスに基づいて判定するステップと，
前記被呼者が信頼できるネットワークにいるかどうかに応じて，前記被呼者と発呼者との間の通信を制御するステップと，
を有する通信方法。
【請求項２】
前記被呼者宛のメッセージに，アドレスが含まれる請求項１記載の方法。
【請求項３】
前記メッセージはパケット形式である請求項２記載の方法。
【請求項４】
前記被呼者が信頼できるネットワーク内にいるかどうか判定するステップは，前記アドレスが信頼できるネットワークのデータベースに含まれているかどうか調べるステップを有する請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記データベースは前記第１のネットワーク内にある請求項４記載の方法。
【請求項６】
データベースをＣＳＣＦ又はセキュリティゲートウェイ内に設ける請求項４又は５記載の方法。
【請求項７】
前記データベースは，信頼できるネットワークに関するドメイン名及び選択的に信頼できるネットワークのＩＰアドレスを有する請求項４〜７のいずれか一項に記載の方法。
【請求項８】
前記のアドレスを判定するための判定ステップは，該アドレスがドメイン名を含むかどうかの判定ステップを有する請求項１〜７のいずれか一項に記載の方法。
【請求項９】
もし前記アドレスがドメイン名を含まないと判定されたら，該ドメイン名のための要求が送信される請求項８記載の方法。
【請求項１０】
前記要求はドメイン名サーバに送信される請求項９記載の方法。
【請求項１１】
もし前記アドレスがドメイン名を含まないと判定されたら，前記被呼者は信頼できないネットワーク内にいるものと推定する請求項８記載の方法。
【請求項１２】
もし前記被呼者が信頼できるネットワーク内にいないならば，前記の制御ステップは前記被呼者宛の少なくとも一つのメッセージを廃棄するステップを有する請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
もし前記被呼者が信頼できるネットワーク内にいないならば，該被呼者宛の少なくとも一つのメッセージを修正する請求項１〜１１のいずれか一項に記載の方法。
【請求項１４】
前記の被呼者宛の少なくとも一つのメッセージを，前記発呼者に関する識別情報を削除することによって修正する請求項１３記載の方法。
【請求項１５】
前記識別情報はP-Asserted-Identityヘッダである請求項１４記載の方法。
【請求項１６】
前記第１及び第２のネットワークは，ＳＩＰに従って動作する請求項１〜１５のいずれか一項に記載の方法。
【請求項１７】
前記の被呼者が信頼できるネットワーク内にいるかどうかを判定するステップは，発呼ネットワークから被呼ネットワーク宛のコネクションがセキュアであるかどうか判定するステップを有する請求項１〜１６のいずれか一項に記載の方法。
【請求項１８】
前記の被呼者が信頼できるネットワーク内にいるかどうか判定するステップは，発呼ネットワークのゲートウェイにおいて実行される請求項１７記載の方法。
【請求項１９】
前記の被呼者が信頼できるネットワーク内にいるかどうか判定するステップは，発呼ネットワークのゲートウェイと被呼ネットワークのゲートウェイとの間のコネクションがセキュアなコネクションかどうかを，前記発呼ネットワークのゲートウェイが判定するステップを有する請求項１８記載の方法。
【請求項２０】
発呼者を含む第１のネットワークと被呼者を含む第２のネットワークとを備える通信システムであって，前記第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかを前記アドレスに基づいて判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて前記被呼者と発呼者との間の通信を制御するための制御手段と，
を備える通信システム。
【請求項２１】
第２のネットワーク内にいる発呼者に発呼するように設定された発呼者を含む第１のネットワークであって，該第１のネットワークは，
前記被呼者のアドレスを判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかを前記アドレスに基づいて判定するための判定手段と，
前記被呼者が信頼できるネットワーク内にいるかどうかに応じて前記被呼者と発呼者との間の通信を制御するための制御手段と，
を備えるシステム。
【請求項２２】
第１のネットワーク内にいる発呼者と第２のネットワーク内にいる被呼者との間の通信方法であって，
前記第２のネットワークとのセキュアなコネクションがあるかどうかを前記第１のネットワークにおいて判定するステップと，
もし前記第２のネットワークとのセキュアなコネクションがないと判定されたら，前記発呼者から被呼者宛のメッセージを廃棄又は修正するステップと，
を有する通信方法。
【請求項２３】
前記の判定ステップはゲートウェイにおいて実行される請求項２２記載の方法。
【請求項２４】
前記ゲートウェイはセキュリティゲートウェイである請求項２３記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２００９−２８４４９２（Ｐ２００９−２８４４９２Ａ）
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願番号】特願２００９−１３１３３２（Ｐ２００９−１３１３３２）
【出願日】平成２１年５月２９日（２００９．５．２９）
【分割の表示】特願２００６−５３０７３３（Ｐ２００６−５３０７３３）の分割
【原出願日】平成１６年９月２７日（２００４．９．２７）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願日】平成２１年５月２９日（２００９．５．２９）
【分割の表示】特願２００６−５３０７３３（Ｐ２００６−５３０７３３）の分割
【原出願日】平成１６年９月２７日（２００４．９．２７）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]