JP2011517169A - ローカル・ネットワークへのリモート・アクセスの方法および装置 - Google Patents

Abstract

ローカル・ネットワーク外部に位置するリモート・デバイス（３００）からローカル・ネットワークのローカル・ゲートウェイ（３０２）へのリモート・アクセスを可能にする方法および装置である。リモート・アクセスのためにＩＭＳコア（３０４）で、リモート・デバイスに関するおよびローカル・ゲートウェイに関する機能並びに信用証明を独立に構成する。ＩＭＳベースＡＣＬ（アクセス制御リスト）への各許可ユーザのＩＭＳ識別子の追加により、ローカル・ネットワークへのリモート・アクセスを１人または複数のユーザにもまた許可する。ＩＭＳベースＡＣＬにリモート・デバイスユーザのＩＭＳ識別子が存在すれば、リモート・デバイスからローカル・ゲートウェイへのアクセス要求を受理することにする。リモート・デバイスおよびローカル・ゲートウェイに関して構成する機能並びに信用証明により、リモート・アクセス接続を次いで確立することができる。

Description

本発明は一般にローカル・ネットワークの外部に位置する通信デバイスからローカル・ネットワークのサービスおよび通信デバイスへのリモート・アクセスを可能にする方法および装置に関する。

ＩＰ（インターネットプロトコル）を使用するパケットベースマルチメディア通信のために、単に「デバイス」と称することが多い多数の種々のタイプの通信端末が開発された。マルチメディアサービスは典型的にＩＰネットワークを経る種々のフォーマットおよび組み合わせのメディア伝送を必要とする。例えば、ＩＰ接続可能な端末は別のＩＰ説続可能な端末と、ビジュアル情報およびオーディオ情報の少なくともいずれかのようなメディアを交換することができるか、若しくはインターネットを経てコンテンツサーバからメディアをダウンロードすることができる。

一般にＩＭＳネットワークまたはＩＭＳコアと称するＩＰベースマルチメディアサービスおよびセッションを処理および制御するプラットフォームとして、ＩＭＳ（ＩＰマルチメディア・サブシステム）と呼ぶネットワーク構成が開発された。従って使用するアクセス技術にかかわらず、ＩＭＳネットワークを使用して種々のアクセスネットワークに接続する通信端末のメディアセッションを設定し、制御することができる。

ＩＭＳネットワークの特定のセッション制御ノード、例えばノードＰ−ＣＳＣＦ（Proxy Call Session Control Function、代理呼セッション制御機能）、Ｓ−ＣＳＣＦ（Serving CSCF、サービス提供ＣＳＣＦ）およびＩ−ＣＳＣＦ（Interrogating CSCF、問い合わせＣＳＣＦ）により、マルチメディアセッションを処理する。さらに、ＩＭＳネットワークのデータベースノードＨＳＳ（Home Subscriber Server、ホーム加入者サーバ）は加入者および認証データを蓄積する。ＩＭＳネットワークはさらに種々のアプリケーションサーバを含むことができ、また外部サービスプロバイダに接続することもできる。

ＩＭＳプラットフォームによれば、「ＳＩＰ」（セッション開始プロトコル）と呼ばれるプロトコルが、マルチメディアセッションを開始、管理および終了するために一般に使用される。従って、共通セッション開始メッセージ「ＳＩＰＩＮＶＩＴＥ」および共通応答メッセージ「ＳＩＰ２００ＯＫ」のような標準ＳＩＰメッセージを、ＩＰ端末やデバイスは、セッションの確立のためにに使用することができる。また、来るべきマルチメディアセッションに必要な種々の通信パラメータを指定するために、「セッション既述プロトコル」を自律体としてＳＩＰメッセージ内に埋め込むことができる。このプロトコルは、セッション設定手順において必要な情報を交換するために一般的に用いられる。当該情報には、例えば当技術において周知の、デバイス機能、メディア特性、現在使用するＩＰアドレス、などがある。

時にＬＡＮ（ローカルエリアネットワーク）と呼ばれる、住宅ネットワークやオフィス・ネットワークのような、ローカル・ネットワークまたはプライベート・ネットワークにおけるデバイスに、ＩＭＳベースのサービスを提供することもできる。本明細書では、任意のそのようなネットワークを表すために、汎用用語「ローカル・ネットワーク」を使用し、ローカル・ネットワーク内でＩＰ通信の可能な任意の端末を表すために、用語「デバイス」を使用する。そのようなローカル・ネットワークで、ネットワーク内の通信のために各デバイスにローカルＩＰアドレスを割り当てるが、そのネットワーク外部のパブリック・ドメインでメッセージおよびデータのルーティングにローカルＩＰアドレスを使用することはできない。

ローカル・ネットワークが含みうるのは、例えば固定および無線電話機、コンピュータ、メディアプレイヤ、サーバおよびＴＶセットである。そのようなデバイスにＩＭＳサービスを提供するために、ローカル・ネットワークの任意のデバイスに代わりローカル・ネットワークからＩＭＳネットワークに向けてＩＭＳサービスにアクセスするＩＭＳ端末をエミュレートすることができる「ホームＩＭＳゲートウェイ（Home IMS Gateway）、ＨＩＧＡ」と呼ぶマルチメディアゲートウェイが定義された。

ＵＰｎＰ（Universal Plug-and-Play）は、ローカル・ネットワーク内で、アクセス方法、オペレーティングシステム、プログラム言語、フォーマット規格および通信プロトコルが異なってもよいところの異なるデバイス間の通信のための、標準化デバイス・プロトコルを有する構成である。とりわけ、ＵＰｎＰは「ディスカバリ」または「ペアリング」と呼ばれる処理をサポートし、「ディスカバリ」または「ペアリング」でデバイスが行うことができるのは、ローカル・ネットワークへの加入、ローカルＩＰアドレスの取得、デバイスの名前およびＩＰアドレスの公表、ネットワークの他デバイスとの機能およびサービスの交換である。本明細書では、データ伝送、通信、符号化、蓄積および表示のための任意のデバイス機能を短く「機能」と称することにする。

ＵＰｎＰはまたリモート・アクセス構成ＲＡＡ（Remote Access Architecture）を定義し、リモート・アクセス構成はローカル・ネットワーク外部に位置するリモート「ＵＰｎＰデバイス」にネットワーク内に位置するデバイスとの通信を可能にする。特に、ＲＡＡが指定するのは、リモート・アクセス・サーバＲＡＳ（Remote Access Server）およびリモート・アクセス・クライアントＲＡＣ（Remote Access Client）をそれぞれ有するエンティティ間で、リモート・アクセス接続を可能とするために必要なパラメータの提供および構成方法である。本技術分野では、ＲＡＳおよびＲＡＣ機能の制御ポイントは、時に一般に「ＵＰｎＰＲＡ管理コンソール」と呼ばれる。しかしながら、そのようなリモート・アクセス接続を安全にする解決策も、また安全な接続に必要な信用証明または資格証明の配信方法も、ＵＰｎＰＲＡＡは提供しない。例えば外部からローカル・ネットワークにアクセスする場合、リモート・デバイスを認証または検証する解決策をこれまで提示していない。

図１は、種々のローカルデバイスと共にローカル・ネットワーク１００を示す。この例では、種々のローカル・デバイスには、無線電話機、固定電話機、ＴＶセット、ラップトップ・コンピュータおよびメディア・サーバが含まれる。ネットワーク１００はまた、「住宅ゲートウェイＲＧＷ（residential gateway）」と呼ばれる従来型のゲートウェイ１０２を含む。この従来型のゲートウェイは、外部アクセスネットワーク１０４に接続し、他のネットワークやエンティティへの通信リンクを提供する。ＲＧＷ１０２が典型的に含むのは、当技術では周知のローカルＩＰアドレスをデバイスに割り当てるようにする、図示しないＮＡＴ（ネットワーク・アドレス変換、Network Address Translation）機能およびローカルＤＨＣＰ（動的ホスト構成プロトコル、Dynamic Host Configuration Protocol）サーバである。
ローカル・ネットワーク１００は、ＩＭＳネットワーク１０８への接続を提供するＨＩＧＡ１０６を更に含み、ＩＭＳネットワーク１０８にはＨＳＳ１１０が内部に提供されている。ＨＩＧＡ１０６は、破線で示すようにデバイス適応プロトコルを使用するネットワーク１００の種々のデバイスに対する適切なインタフェースを有する。実際には、ＨＩＧＡはＲＧＷ内に統合することができるが、本明細書では論理的に、個別機能ユニットとして考えることにする。

ＨＩＧＡ１０６は、ＩＭＳ加入およびユーザ／サービスプロファイルと関連するＩＭＳ識別子１１２を保持し、ＩＭＳ識別子はＩＭＳネットワーク１０８へのアクセスに使用することができ、ＩＭＳネットワーク１０８は対応する加入者情報１１４をＨＳＳノード１１０に蓄積する。従って、ユーザはローカル・ネットワーク１００のデバイスから、ＨＩＧＡ１０６を介してＩＭＳネットワークにログオンすることができるので、使用デバイスのローカルＩＰアドレスを、ユーザプロファイルと関連づけることができる。特許文献１には、ローカル・ネットワークのデバイスがＨＩＧＡによりＩＭＳサービスを得る方法を記載する。

デバイス特有インタフェース／プロトコルを使用してネットワーク１００のデバイスからＨＩＧＡ１０６がマルチメディアサービス要求を受信する場合、ＨＩＧＡ１０６はデバイスに代わりサービス要求を有効なＩＭＳ要求（例えばＳＩＰ ＩＮＶＩＴＥ）に変換し、ＩＭＳネットワーク１０８との適切なＳＩＰメッセージ通信により、デバイスにセッションを設定する。同様な方法でデバイスに関連するＩＭＳ識別子１１２を使用して、ネットワーク１００のデバイスとの通信の入接続要求に対し、ＨＩＧＡ１０６によりＩＭＳセッションを設定することができる。２方向矢印により示すように何れの場合においても、ＲＧＷ１０２およびアクセスネットワーク１０４を経てデバイスからまたはデバイスへセッション中に任意の通信メディアをルーティングする。

図１はさらにネットワーク１００のローカルデバイス１００ａが外部に移動し、リモート・デバイス１００ａ'になることを示す。リモート・デバイス１００ａ'は次いでＩＭＳネットワーク１０８を経てＨＩＧＡ１０６にＳＩＰ ＩＮＶＩＴＥメッセージを送信し、ネットワーク１００の残留デバイスの１つとメディア通信を開始することができる。リモート・デバイス１００ａ'はこの場合ネットワーク１００の外部からＩＭＳネットワークへのアクセスに有効なＩＭＳ識別子を持たなければならない。

ネットワーク１００のローカルデバイスにリモートからアクセスするために、リモート・デバイス１００ａ'は何らかの形でディスカバリ処理においてローカル・デバイスを把握しておかなければならない。リモート・デバイスが最近にローカル・ネットワーク１００内に位置していた間に、通常のディスカバリ処理に参加しておくことができたかもしれない。当該ディスカバリ処理は、典型的に、ＳＳＤＰ（Simple Session Discovery Protocol、簡潔なセッション・ディスカバリ・プロトコル）と呼ばれるプロトコルに従った所定のディスカバリ・メッセージの交換を含んでいる。しなしながら、リモート・デバイスが実際にローカル・ネットワーク内に位置することが全くなかった場合のように、これが該当しなければ、リモートでディスカバリ・メッセージを交換する必要がある。

図２は、（図示しない）ネットワークのローカルデバイスへのリモート・アクセスを可能にするためのローカル・ネットワークのリモート・デバイス２００、および、ローカル・ゲートウェイ２０２それぞれの、ありうる論理構成である。ローカル・ゲートウェイ２０２は、ＲＧＷおよびＨＩＧＡの少なくともいずれかでありうる。リモート・アクセス・クライアントＲＡＣ２００ａは、リモート・デバイス２００内に構成され、対応するリモート・アクセス・サーバＲＡＳ２０２ａはローカル・ゲートウェイ２０２内に構成されているが、構成を行うことができるのは両者がローカル・ネットワークに存在する場合であるが、それはＲＡＣ２００ａおよびＲＡＳ２０２ａは整合プロファイルにより構成すべきだからである。

ＲＡＣ２００ａはリモート・アクセス・ディスカバリ・エージェントＲＡＤＡ（Remote Access Discovery Agent）２００ｂを含み、ＲＡＳ２０２ａは対応するリモート・アクセス・ディスカバリエージェントＲＡＤＡ２０２ｂを含み、２つのエンティティ２００および２０２間でディスカバリメッセージを交換するようにする。ＲＡＣ２００ａはさらにリモート・アクセス伝送エージェントＲＡＴＡ（Remote Access Transport Agent）２００ｃを含み、ＲＡＳ２０２ａは対応するリモート・アクセス伝送エージェントＲＡＴＡ２０２cを含み、２つのエンティティ２００および２０２間のメディア伝送チャネルを確立するようにする。事実上、ＲＡＴＡ２００ｃ、２０２ｃはリモート・アクセスの対向するエンドポイントとして動作することになろう。

しかしながらＵＰｎＰＲＡＡが規定するのは、ＲＡＣおよびＲＡＳを実装するエンティティが物理的に同じローカル・ネットワークに存在し、必要なディスカバリまたは対化処理を実行しなければならないことであり、これは当然欠点でありうる。例えばＰＣデバイスをまず物理的にローカル・ネットワークに持ち込み、必要なディスカバリまたは対化処理を実行しなければ、インターネットのどこかに位置するＵＰｎＰリモート・アクセスの可能なＰＣデバイスはインターネットの他のどこかに位置するローカル・ネットワークのデバイスにリモート・アクセスすることができない。実際的および使用可能性の観点から、この要求は十分に問題でありうる。その上また問題であるのは、このようなリモート・アクセスに対し、例えばローカル・ネットワークに向かう、またはその逆のリモート・デバイスを検証または許可する信頼モデルを提供することができないことである。

国際公開第２００６／０４５７０６号パンフレット

本発明の目的は以上に概説する問題に対処することである。さらに目的であるのは、ローカル・ネットワークにおける物理的存在を必要とすることなく、ローカル・ネットワークへの安全なリモート・アクセス接続を可能にする解決策を提供することである。これらの目的およびその他を得ることができるのは、以下に添付する独立特許請求項による方法および装置の提供による。

１つの態様によれば、ローカル・ネットワークの外部に位置するリモート・デバイスからローカル・ネットワークのローカル・ゲートウェイへのリモート・アクセスを可能にするための方法を提供する。まずリモート・アクセスのために、ＩＭＳコアにおけるリモート・デバイスおよびローカル・ゲートウェイの機能並びに信用証明を構成する。次いで許可された各ユーザのＩＭＳ識別子をＩＭＳベースアクセス制御リストＡＣＬ（Access Control List）に追加することにより、ローカル・ネットワークへのリモート・アクセスを１人以上のユーザに許可する。ＩＭＳコアを介してリモート・デバイスからローカル・ゲートウェイへのアクセス要求を受信した場合、リモート・デバイスユーザに、ＩＭＳベースＡＣＬのユーザのＩＭＳ識別子によるリモート・アクセスを許可していれば、アクセス要求を受理する。その場合、リモート・デバイスおよびローカル・ゲートウェイの、上記の構成された機能並びに信用証明を使用して、リモート・アクセス接続を確立する。

別の態様によれば、ローカル・ネットワークの外部に位置するリモート・デバイスからローカル・ネットワークのローカル・ゲートウェイへのリモート・アクセスを可能にするために、ＩＭＳコアにおけるリモート・アクセス・サーバを提供する。リモート・アクセス・サーバは、リモート・アクセスのためにＩＭＳコアのリモート・デバイスおよびローカル・ゲートウェイの機能並びに信用証明を構成する手段と、許可された各ユーザのＩＭＳ識別子をＩＭＳベースＡＣＬに追加することにより、ローカル・ネットワークへのリモート・アクセスを１人以上のユーザに許可する手段とを含む。

リモート・アクセス・サーバは、ＩＭＳコアを介してリモート・デバイスから、ローカル・ゲートウェイへのアクセス要求を受信する手段と、リモート・デバイスのユーザに、ＩＭＳベースＡＣＬのユーザのＩＭＳ識別子によるリモート・アクセスを許可している場合にアクセス要求を受理する手段と、アクセス要求を受理した場合に、リモート・デバイスおよびローカル・ゲートウェイについて構成された機能及び信用証明を使用して、リモート・アクセス接続を確立する手段とを更に含む。

さらに別の態様によれば、ローカル・ネットワークの外部に位置するリモート・デバイスからローカル・ゲートウェイへのリモート・アクセスを可能にするローカル・ネットワークのローカル・ゲートウェイを提供する。ローカル・ゲートウェイは、リモート・アクセスのためにＩＭＳコアにおけるローカル・ゲートウェイの機能および信用証明を構成する手段と、ＩＭＳコアを介してリモート・デバイスからアクセス要求を受信する手段と、リモート・デバイスのユーザに、ユーザのＩＭＳ識別子によるリモート・アクセスを許可している場合にアクセス要求を受理する手段と、アクセス要求を受理した場合に、リモート・デバイスおよびローカル・ゲートウェイについて構成された機能並びに信用証明によりリモート・アクセス接続を確立する手段とを含む。

以上の方法、リモート・アクセス・サーバおよびローカル・ゲートウェイ装置において、種々の実施形態が可能である。例えばリモート・デバイスのＩＭＳクライアントとＩＭＳコアのリモート・アクセス・サーバ間のＩＭＳメッセージ送信により、リモート・デバイスに関する機能および信用証明をＩＭＳコアにおいて構成することができる。ローカル・ゲートウェイのＩＭＳクライアントとリモート・アクセス・サーバ間のＩＭＳメッセージ送信により、ローカル・ゲートウェイに関する機能および信用証明をＩＭＳコアにおいて構成することができる。以上の信用証明はＶＰＮトンネルを確立するための証明書を含むことができる。さらに以上の機能はローカル・ゲートウェイのＲＡＳのＲＡＴＡ機能およびリモート・デバイスのＲＡＣのＲＡＴＡ機能を含むことができる。

リモート・デバイスがローカル・ネットワーク外部に位置する場合、以上の機能および信用証明を構成することができる。許可されたユーザはユーザのＩＭＳ識別子により任意の端末からローカル・ネットワークにリモートからアクセスすることができる。ＩＭＳベースのＡＣＬはローカル・ゲートウェイ、またはＩＭＳコアのリモート・アクセス・サーバで保持することができる。

リモート・デバイスユーザにユーザのＩＭＳ識別子によりリモート・アクセスを許可していなければ、例えばアクセス要求受理の可否に関して、ローカル・ネットワーク・オーナーに問い合わせを行うことにより、ローカル・ネットワークを制御するローカル・ネットワーク・オーナーにとりアクセス要求が受理可能であるかを判断することができる。

リモート・アクセスを許容するデバイスのＵＵＩＤを包含するＵＰｎＰベースＡＣＬをローカル・ゲートウェイで保持することもできる。この場合アクセス要求を受理すれば、リモート・デバイスのＵＵＩＤをＵＰｎＰベースＡＣＬに加えることができる。

本発明のさらなる可能な特徴と利益を以下の詳細な記述において説明することにする。

本発明を次に好ましい実施形態により、添付する図面を参照してより詳細に説明することにする。
図１は従来技術によりネットワークの外部位置からリモート・デバイスがネットワークにアクセスする場合のローカル・ネットワークを示す概観図である。 図２は従来技術によるリモート・デバイスのおよび住宅ゲートウェイのリモート・アクセスの特徴を示すブロック図である。 図３はある実施形態によりＩＭＳを経てローカル・ネットワークのローカル・ゲートウェイにアクセスするリモート・デバイスを示すブロック図である。 図４は別の実施形態によるローカル・ネットワークへの安全なリモート・アクセスを可能にする手順を示すフローチャートである。 図５は別の実施形態によりリモート・アクセスサービスのためにＩＭＳコアにおいてローカル・ゲートウェイおよびリモート・デバイスに関する機能並びに信用証明を構成することができる方法を示す信号図である。 図６はさらに別の実施形態によりＩＭＳコアにＡＣＬを保持する場合のリモート・デバイスからローカル・ゲートウェイへのアクセスをユーザＸに許可することができる方法を示す信号図である。 図７はさらに別の実施形態によりローカル・ゲートウェイにＡＣＬを保持する場合のリモート・デバイスからローカル・ゲートウェイへのアクセスをユーザＹに許可することができる方法を示す信号図である。 図８はさらに別の実施形態によりリモート・デバイスのユーザを事前に許可している場合のリモート・デバイスに対するローカル・ネットワークへのリモート・アクセスの確立手順を示す信号図である。 図９はさらに別の実施形態によりリモート・デバイスのユーザを事前に許可していない場合のリモート・デバイスに対するローカル・ネットワークへのリモート・アクセスの確立手順を示す信号図である。

本発明を使用して得ることができるのは、上述のディスカバリまたは対化処理中にリモート・デバイスが物理的にローカル・ネットワークに存在する必要なく、リモート・デバイスからローカル・ネットワークのサービスおよび／またはデバイスへの安全なリモート・アクセスである。この解決策では、リモート・アクセスのための認証／許可および信用証明の配信をサポートする機能のＩＭＳコアへの導入により、ＩＭＳコアを経るリモート・アクセスを確立することができる。以下の説明では、ＩＭＳコアのＲＡ（Remote Access）サーバによりこの機能を概略的に表す。さらに以下の説明で「リモート・アクセス・サポート・モジュール」ＲＡＳＵＭ（"Remote Access Support Module"）と称するＩＭＳベースリモート・アクセス・サポート機能をまたＲＡＣおよびＲＡＳにそれぞれ導入する。

以下で説明する特徴を有する機能ユニットを一般的に表すために、用語ＲＡサーバおよびＲＡＳＵＭを本明細書を通じて使用するが、本発明はユニットの何ら特定の実装に限定しない。さらに少なくともリモート・アクセスサービスを処理し、本明細書で説明する方法でネットワークへのリモートからのアクセスを許容するユーザおよびデバイスを決定する意味で、ローカル・ネットワークを制御する管理者、監督者またはその他の人間を一般的に表すために、用語「ローカル・ネットワーク・オーナー」を使用する。

以上の本発明の装置の例示実施形態を基本的に図３に示す。この例で、リモート・デバイス３００はＩＭＳコア３０４を経てローカル・ネットワークのローカル・ゲートウェイ３０２にアクセスし、図示しないネットワークのローカルデバイスとの通信を確立することができる。リモート・デバイス３００は移動端末でありえ、ローカル・ゲートウェイ３０２はＨＩＧＡでありうるが、本発明は以下に限定しない。リモート・デバイス３００およびローカル・ゲートウェイ３０２はＲＡＳＵＭユニット３００ａおよび３０２ａをそれぞれ含み、ＲＡサーバ３０４ａはＩＭＳコア３０４内に所在し、ＩＭＳコア内のＨＳＳノード３０４ｂに接続する。

特にＩＭＳコア３０４においてＩＭＳのサポートするリモート・アクセスサービスの構成のためおよびリモート・アクセス通信の確立のために、各ＲＡＳＵＭユニット３００ａ、３０２ａは例えばＳＩＰを使用してＲＡサーバ３０４ａとＩＭＳメッセージを交換するようにするＩＭＳクライアント３００ｂ、３０２ｂを含む。リモート・デバイス３００のＲＡＳＵＭユニット３００ａがさらに含むのは、基本的にＵＰｎＰＲＡ構成により定義するようなＵＰｎＰ動作によりＲＡＣ３００ｄと相互動作するようにするＲＡ（リモート・アクセス）管理者コンソール３００ｃである。同様にローカル・ゲートウェイ３０２のＲＡＳＵＭユニット３０２ａがまた含むのは、ＵＰｎＰ動作によりＲＡＳ３０２ｄと相互動作するようにするＲＡ管理者コンソール３０２ｃである。

簡単に説明すると、次の方法でローカル・ネットワークにおける物理的存在を必要とすることなく、ローカル・ネットワークへのＩＭＳベースリモート・アクセスをリモート・デバイスのために安全に得ることができる。第１に、それぞれＩＭＳクライアント３０２ｂとＲＡサーバ３０４ａ間のＩＭＳメッセージ送信により、およびＩＭＳクライアント３００ｂとＲＡサーバ３０４ａ間のＩＭＳメッセージ送信により、リモート・アクセスの機能および信用証明をＩＭＳコアにおいて構成する。本明細書で用語「信用証明」が示すのは、以下でさらに詳細に説明するようにＶＰＮ（Virtual Private Network、バーチャル・プライベート・ネットワーク）トンネルを確立するための証明書のような安全な接続の確立に必要な任意のパラメータである。第２に、ＩＭＳクライアント３００ｂとＲＡサーバ３０４ａ間のＩＭＳメッセージ送信により、ＩＭＳセキュリティに基づく信頼モデルを使用して、リモート・デバイス３００にローカル・ネットワークへのリモート・アクセスを許可する。第３に、ＲＡサーバ３０４ａを経るＩＭＳクライアント３００ｂと３０２ｂ間のＩＭＳメッセージ送信により、リモート・アクセスセッションを確立し、底部の２方向矢印が示すようにＲＡＣ３００ｄのＲＡＴＡとＲＡＳ３０２ｄのＲＡＴＡ間でデータを伝送する。

図４のフローチャートを参照し、さらに随時図３を参照して、リモート・デバイスからローカル・ネットワークへの安全なリモート・アクセスを可能にする手順を次に説明することにする。この手順がこの場合に提供するのは、ネットワークのローカル・ゲートウェイ３０２、例えばＨＩＧＡ、ＩＭＳコア３０４のＲＡサーバ３０４ａおよびリモート・デバイス３００を含むリモート・アクセスサービスである。少なくとも以下で明確に説明する方法でローカル・ネットワーク・オーナーにより、ローカル・ネットワークを一般に管理および制御する。

第１のステップ４００でリモート・アクセスサービスのためにＩＭＳコア３０４において、両リモート・アクセス・エンド・ポイント３０２，３００に関する機能および信用証明を構成する。このステップで、ローカル・ゲートウェイ３０２のＩＭＳクライアント３０２ｂはＲＡサーバ３０４ａと適切なＩＭＳメッセージを交換し、ＩＭＳコアのＲＡＳ３０２ｄのＲＡＴＡ機能を判断する。ＩＭＳコア３０４のＲＡサーバ３０４ａにより、ローカル・ゲートウェイ３０２の信用証明を生成し、信用証明をまたゲートウェイ３０２のＲＡエンドポイント、即ちＲＡＳ３０２ｄのＲＡＴＡに配信するが、これを以下でさらに詳細に説明することにする。

同様にリモート・デバイス３００のＩＭＳクライアント３００ｂはＲＡサーバ３０４ａと適切なＩＭＳメッセージを交換し、ＩＭＳコアのリモート・デバイス３００の機能、即ちＲＡＣ３００ｄの対応するＲＡＴＡ機能、および対向するＲＡエンドポイント、即ちＲＡＣ３００ｄのＲＡＴＡに配信するデバイス３００の信用証明を構成する。ローカル・ネットワーク外部に位置する場合に以上のリモート・デバイス３００のリモート・アクセス構成を実行することができ、それ故ローカル・ネットワークにおける物理的存在を必要としない。

例えばゲートウェイ３０２およびデバイス３００それぞれの信用証明でありうるのは、ＩＰＳｅｃ（Internet Protocol Security、インターネットプロトコルセキュリティ）に基づくＶＰＮトンネルのようなサポートするトンネル確立法に対応する証明書である。その場合証明書は当技術で周知である、所謂「ｘ．５０９証明書」でありえよう。とはいえ本発明は何ら特定の信用証明、即ち証明書に限定しない。

ステップ４００によるＩＭＳコア３０４のＲＡＳ３０２ｄおよびＲＡＣ３００ｄそれぞれのＲＡＴＡ機能の構成は実際上上記のディスカバリ処理に対応するが、ローカル・ネットワークにおけるリモート・デバイス３００の物理的存在を必要としない。それ故ステップ４００が基本的に表すと考えうるのは、構成動作、即ち互いに独立に行うＩＭＳコア３０４におけるリモート・アクセスのためのリモート・デバイス３００およびローカル・ゲートウェイ３０２の構成である。実際にステップ４００を実装することができる方法の例を、図５を参照して後に以下で説明することにする。

次のステップ４０２で、ローカル・ネットワーク・オーナーが指定するようにリモート・デバイス３００のユーザを含む、ローカル・ネットワークへのリモート・アクセスを１人または複数の特定ユーザに許可する。一定のユーザに対するリモート・アクセスの許可はそのユーザのＩＭＳ識別子に基づき、ユーザのＩＭＳ識別子はＩＭＳコアにおけるアクセスサービスに必要であるような信頼に値する確認を提供することになろう。ＩＭＳ識別子は典型的にSIP URI（Universal Resource Identifier）、例えばalice@op.netである。本解決策はこのようにＩＭＳ識別子を利用して、使用する端末にかかわらずローカル・ネットワークへのユーザのリモート・アクセスをも確認または許容する。図１に関連して以上で記述するように、ＩＭＳコアを経るローカル・ネットワークへのアクセスに、リモート・デバイスユーザは有効なＩＭＳ識別子を使用しなければならない。使用する実際の端末に関する特定の許可をなんら必要とすることなくユーザのＩＭＳ識別子により、許可されたユーザはその場合任意の端末からローカル・ネットワークにリモートから基本的にアクセスすることができよう。

このステップで、例えばユーザのＩＭＳ識別子のＡＣＬ（アクセス制御リスト）またはローカル・ネットワークの同類への追加により、ネットワークにリモートからアクセスすることをユーザに許容することをローカル・ネットワーク・オーナーが明確に指定する場合、有用な信頼モデルが確立する。それ故ユーザのリモート・デバイス３００へのローカル・ネットワークアクセスの許可に先立ち、既存ＩＭＳセキュリティ機構により、ユーザの認証および許可を共に行ったことの概念をこの信頼モデルは利用する。これらのＩＭＳセキュリティ機構はそれ故一般に確実で、信頼に値すると考えられる。

ＡＣＬはこのようにリモート・アクセスを許容するユーザのＩＭＳ識別子を包含し、ＲＡサーバ３０４ａまたはローカル・ゲートウェイ３０２の何れかに、例えばＲＡ管理者コンソール３０２ｃにおいて格納および保持することができる。ステップ４０２が基本的に表すと考えることができるのは、準備動作、即ちリモート・デバイスユーザにローカル・ネットワークへのリモート・アクセスを準備することである。特定ユーザのために実際にステップ４０２を実装することができる方法の２つの例を図６および図７をそれぞれ参照して後に以下で説明することにする。

さらに、ＵＰｎＰベースＡＣＬをまた、例えばリモート・アクセスを許容または拒否する各デバイスのＵＵＩＤ（Universally Unique Identifier）を包含する「ホワイトリスト」または「ブラックリスト」として使用して種々のＵＰｎＰデバイスのリモート・アクセスを制御することができる。ＵＵＩＤは１２８ビットを包含するＵＰｎＰデバイスの標準化された識別子であり、従ってユーザよりむしろデバイスに関連する。ＵＰｎＰベースＡＣＬはローカル・ゲートウェイのＲＡＳにおいて保持し、従ってＩＭＳベースＡＣＬに追加して使用することができ、図８および図９に示す幾つかの実装例を参照して以下でさらに詳細に説明することにする。ＩＭＳベースＡＣＬおよびＵＰｎＰベースＡＣＬを共にアクセス制御に使用すれば、ユーザ並びにデバイスを共に独立に許可し、アクセス制御をかなり高度化するであろう。実際これらのＡＣＬはＵＰｎＰおよびＩＭＳにそれぞれ幾らか相違して実装することになろう。ＩＭＳベースＡＣＬは基本的にリモート・アクセスサービスのフィルタ基準を形成するデータセットである。ＵＰｎＰベースＡＣＬは所謂「ＲＡＤＡ構成フィルタ」であり、ホワイトリストまたはブラックリストの何れかである。

図４に戻り、さらにステップ４０４でＩＭＳコアを経てリモート・デバイスからある点で、アクセス要求を受信する。例えば要求するデバイスユーザはメディアサーバからのデータの取り出し、またはネットワークのメディアレンダラーまたは蓄積装置へのデータ送信を意図することができる。このステップで、アクセス要求を受信し、ＩＭＳベースＡＣＬを格納し、保持する場所に応じてＩＭＳコアまたはローカル・ゲートウェイの何れかで、アクセス要求を処理することができ、これを以下でさらに詳細に説明することにする。

以上のステップ４０２によりリモート・デバイスユーザへのリモート・アクセスの許可の有無を次のステップ４０６で次いで判断する。例えばステップ４０２で確立するＩＭＳベースＡＣＬに基づくアクセス要求受理の可否、即ち基本的にリモート・デバイスユーザのＩＭＳ識別子のＡＣＬにおける存在をチェックすることができる。

リモート・デバイスユーザを許可し、従ってローカル・ネットワークのリモート・デバイスおよびローカルデバイスを含む通信セッションを実行できることをステップ４０６で判断すれば、ステップ４０８でアクセス要求を受理することができる。他方リモート・デバイスユーザを許可しないことをステップ４０６が明らかにすれば、ステップ４１０により示すようにローカル・ネットワーク・オーナーによりアクセス要求を受理することができるかをさらに判断することができる。例えばデバイスユーザのリモート・アクセス受理の可否に関してローカル・ネットワーク・オーナーに問い合わせを行うことができる。あるいは破線のステップ４１０ａにより示すように、アクセス要求を単に拒否することできる。

ステップ４０４乃至ステップ４１０／ステップ４１０ａは実行時動作、即ちリモート・デバイスのローカル・ネットワークへのリモート・アクセス確立を基本的に表すと考えることができる。特定ユーザに対し実際にステップ４０４乃至ステップ４１０を実装することができる方法の２つの例を図８および図９をそれぞれ参照して後に以下で説明することにする。

図５がさらに詳細に示すのは、即ち基本的に以上のステップ４００に従い、ＩＭＳコアにおけるローカル・ゲートウェイおよびリモート・デバイスに関するリモート・アクセスサービスの機能を判断し、信用証明を構成する例示実施形態である。実際に、この処理はローカル・ゲートウェイおよびリモート・デバイスに対して分離して実行するが、同じ処理が何れのパーティにも有効であり、それ故ここでは一度だけ説明する。ローカル・ゲートウェイおよびリモート・デバイスは共に、以上で全て説明したＲＡＴＡ５００およびＲＡマネジャー５０２並びにＩＭＳクライアント５０４を伴うＲＡＳＵＭを含む。ローカル・ゲートウェイはＨＩＧＡでありうる。

リモート・デバイスではＲＡＴＡ５００はＲＡＣに所在し、ローカル・ゲートウェイではＲＡＴＡ５００はＲＡＳに位置する。ローカル・ゲートウェイでは、ＲＡＳＵＭはＨＩＧＡにおけるＳＩＰユーザエージェントのモジュールでありうる。ＩＭＳコアはＲＡサーバ５０６およびＨＳＳノード５０８を含む。この例ではＩＭＳクライアント５０４およびＲＡサーバ５０６はＳＩＰにより通信するが、本発明は一般に以上に限定しない。

第１のステップ５：１が示すのは、ローカル・ネットワーク・オーナーが構成処理を開始する何か適切な入力を提供し、入力がＩＭＳクライアント５０４への起動信号となり、ＩＭＳクライアント５０４が次いで次のステップ５：２で適切なＳＩＰメッセージでリモート・アクセスサービス要求をＩＭＳコアに送信することであり、リモート・アクセスサービス要求はＲＡマネジャー５０２により受信する。これは従ってサービス起動ステップであり、好ましくは、ユーザはＩＭＳ運用会社とサービス合意を既に行っている。

次のステップ５：３で、ＲＡサーバ５０６は別の適切なＳＩＰメッセージでＩＭＳクライアント５０４にＲＡＴＡ５００の機能要求を送信する。ＲＡＳＵＭは次いでＳＩＰメッセージからこの機能要求を抽出することができる。さらにステップ５：４で、ＲＡＴＡ機能を基本的にＲＡＴＡ５００から取り出す。このステップにおいて前ステップで受信するＳＩＰメッセージの解析後、ＲＡＳＵＭ機能は事実上ＲＡマネジャー５０２への要求を作成し、ＲＡマネジャー５０２に発出し、ＲＡマネジャー５０２は次いで機能をＲＡＴＡ５００から取り出し、機能をＩＭＳクライアント５０４に返信する。例えばＲＡＴＡの機能は「証明書に基づくＩＰｓｅｃおよびＩＫＥ（Internet Key Establishment、インターネット鍵確立）のサポート」を含むことができる。

次のステップ５：５で、ＩＭＳクライアント５０４は以上のステップ５：３の機能要求に応じて、さらに別の適切なＳＩＰメッセージでＲＡサーバ５０６にＲＡＴＡ機能を送信する。ＲＡサーバ５０６は次いで後の使用のためにＲＡＴＡ機能をＨＳＳノード５０８に蓄積する、これをローカル・ゲートウェイおよびリモート・デバイスのそれぞれのリモート・アクセスサービス・データ更新ステップ５：６としてここに示す。

次のステップ５：７でローカル・ゲートウェイおよびリモート・デバイスのそれぞれに対するリモート・アクセスの信用証明として、ＲＡサーバ５０６は証明書を生成する。ＩＰｓｅｃに基づく証明書をサポートすれば、ｘ．５０９証明書をこのステップで生成することができる。公認済の認証局のような第３のパーティエンティティにより、このステップを事実上実行することができよう。

次のステップ５：８でローカル・ゲートウェイおよびリモート・デバイスのＩＭＳクライアント５０４にそれぞれリモート・アクセスの信用証明として、ＲＡサーバ５０６は生成する証明書を送信する。以上に示すようにＲＡサーバ５０６によるまたは代わって（図示しない）第３のパーティサーバによる信用証明として、ｘ．５０９証明書を生成することができる。伝送ネットワークを経るＩＭＳクライアントへの信用証明の配信はプッシュベースまたはプルベースの何れかでありえよう。信用証明のプッシュベース分配はＲＡサーバ５０６からのメッセージＨＴＴＰＰＯＳＴにより実装することができようが、一方適切なＳＩＰメッセージにより起動するように、信用証明のプルベース分配はリモート・デバイスまたはローカル・ゲートウェイからのメッセージＨＴＴＰＧＥＴにより実装することができよう。

証明書を受信すると、ＩＭＳクライアント５０４は証明書を信用証明としてＲＡマネジャー５０２を経てＲＡＴＡ５００に配信する、これを結合ステップ５：９として示す。最後に、ＲＡマネジャー５０２をＲＡＳＵＭにより起動し、ＲＡＴＡ５００において新規プロファイルを作成する、これを最終ステップ５：１０として示す。このプロファイルが従って示すことができるのは、リモート・アクセス・エンド・ポイント、即ちＲＡＳまたはＲＡＣがＩＰｓｅｃベースＶＰＮをサポートし、これを行うのに必要な信用証明、この場合は証明書を有することである。ローカル・ゲートウェイおよびリモート・デバイスのＲＡＴＡ５００はそれぞれこの時技術的にリモート・アクセス接続の確立の準備が整う。しかしながら図４のステップ４０２により規定するように、リモート・アクセスユーザにまずリモート・アクセスを許可しなければならない。

ローカル・ネットワークへのリモート・アクセス接続の確立を許容するユーザのＩＭＳ識別子を包含するＩＭＳベースＡＣＬまたは同類を、ローカル・ネットワーク・オーナーが作成することができる方法の異なる代替手順が可能である。図６ａおよび図６ｂは２つの代替実施形態を示し、２つの代替実施形態はそれぞれ「サーバ側」手順および「ゲートウェイ側」手順と称することができよう。許容ユーザの識別子は一般に種々の方法で指定することができる。現在のＩＭＳ標準によれば、ＳＩＰ ＵＲＩおよび電話ＵＲＩ、即ち電話番号、例えば０７０１２３４５６の少なくともいずれかのような識別子でありうる所謂「P-asserted identity」に基づき、ユーザを唯一に特定する。

図６および図７が示すのは、ネットワーク外部に位置するリモート・デバイスからローカル・ゲートウェイへのアクセスをユーザに許可する、即ち基本的に以上のステップ４０２による２つの代替実施形態である。図６でローカル・ネットワークのＡＣＬをＩＭＳコアにおいて保持し、図７でローカル・ゲートウェイにおいてＡＣＬを保持する。上記のように、ＵＰｎＰベースのＡＣＬを追加使用してローカル・ゲートウェイへのリモート・アクセスをリモートＵＰｎＰデバイスに許可することができる。

図６でローカル・ゲートウェイはＲＡユーザ管理モジュール６００を含み、ＲＡサーバ６０２およびＨＳＳノード６０４を含むＩＭＳコアにおいて、ＩＭＳベースＡＣＬを保持する。ＲＡユーザ管理モジュール６００はＲＡＳＵＭユニットに実装することができ、ＡＣＬはＲＡサーバ６０２またはＨＳＳノード６０４に位置することができる。その上、図５の例えばステップ５：２の後の構成処理の過程で、リモート・アクセスサービスに対するローカル・ネットワークの一定のフィルタ基準を事前にＨＳＳノード６０４に蓄積しておくことができる。「ＩＮＶＩＴＥ」はＳＩＰメッセージであり、セッション開始のためにエンドユーザデバイスにより一般に使用する。リモート・アクセスサービスのために蓄積するフィルタ基準により、もしあればあらゆる受信ＩＮＶＩＴＥメッセージに、Ｐ−ＣＳＣＦと呼ぶＩＭＳネットワークのセッション制御ノードはフィルタ機能を適用することができる。

第１のステップ６：１が示すのは、ローカル・ネットワーク・オーナーが適切なＧＵＩでＲＡユーザ管理モジュール６００にユーザＸの電話ＵＲＩまたはＳＩＰ ＵＲＩを入力し、ＩＭＳベースＡＣＬにユーザＸを追加することである。この場合サーバ側手順を使用し、ローカル・ネットワーク・オーナーはSIP URIまたは電話ＵＲＩ若しくはＩＭＳコアに既知のユーザＸの他の識別子の何れかを提供することができよう。次のステップ６：２で、ユーザＸの許可要求をＲＡサーバ６０２に、例えばＸＣＡＰメッセージで提出する。オプションとしてＩＭＳクライアントを実装する任意のデバイスから、許可要求を送信することができる。この送信に応じて、ＲＡサーバ６０２はユーザＸのSIP URIを取り出し、ＡＣＬに追加し、ステップ６：３でＨＳＳノード６０４のローカル・ゲートウェイの例えば上記フィルタ基準を含むサービスデータを更新する。

図７に示す実施形態で図示するＲＡユーザ管理モジュール６００およびＲＡサーバ６０２は基本的に図６におけるのと同じであるが、ＩＭＳベースＡＣＬはローカル・ゲートウェイで、例えばＲＡユーザ管理モジュール６００において保持する。結果として、この場合ゲートウェイ側手順を使用するユーザＹに対するリモート・アクセス許可手順は図６におけるそれとは幾らか異なる。このシナリオでは発呼者のSIP URI（P-asserted identity）のチェックにより、ローカル・ゲートウェイは発呼者から入力するリモート・アクセス接続要求を包含するＳＩＰＩＮＶＩＴＥメッセージのフィルタリングを実行する。ＡＣＬにそのユーザを追加する場合、ローカル・ネットワーク・オーナーはユーザのSIP URIまたは電話ＵＲＩの何れかを指定することができよう。電話ＵＲＩを指定すれば、ローカル・ネットワークは上記のフィルタリング動作を実行することができる対応SIP URIを知らなければならない。それ故電話ＵＲＩを提供されるとすれば、ローカル・ネットワークはＩＭＳコアにユーザの対応SIP URIを尋ねる必要があろう。

ユーザＹの電話ＵＲＩまたはSIP URIをＲＡユーザ管理モジュール６００への入力として入力する第１のステップ７：１は基本的にステップ６：１と同じである。モジュール６００は次いで次のステップ７：２でSIP URIまたは電話ＵＲＩをステップ７：１で入力されたかを判断する。電話ＵＲＩをステップ７：１で入力されたとすれば、対応するSIP URIをＡＣＬに蓄積するために取り出さなければならず、モジュール６００はそれ故さらにステップ７：３で電話ＵＲＩに対応するSIP URI要求をＲＡサーバ６０２に送信する。ＲＡサーバ６０２は次いで次のステップ７：４で電話ＵＲＩに基づき対応するSIP URIをＨＳＳ６０４から取り出す。

ステップ７：２の要求に応じて、ＲＡサーバ６０２は次いで次のステップ７：５でユーザＹのP-asserted identityであるユーザＹのSIP URIを送信する。このステップで、SIP URIは適切なＳＩＰメッセージで送信することができる。最後に最終ステップ７：６で、ＲＡユーザ管理モジュール６００はユーザＹのSIP URIをＡＣＬに追加する。しかしながらSIP URIをステップ７：１で入力されたとステップ７：２で判断したとすれば、SIP URIをＡＣＬに直接蓄積することができ、従ってこの場合ステップ７：３乃至ステップ７：５を省略することができる。何れの場合でも、SIP URIに代わりユーザフレンドリーな識別子を好ましくはローカル・ネットワーク・オーナーに表示する。

ローカル・ゲートウェイは次に、例えばＳＩＰ ＩＮＶＩＴＥメッセージのようなあらゆる入力リモート・アクセス要求のフィルタリングを実行するので、これらのリモート・アクセス要求が好ましくは包含すべきは、セルラーデバイスおよびＩＭＳコアに関する要求を提出するP-asserted identityである。例えば発信デバイスにＳＩＰヘッダにおける適するセキュリティレベルの指示を強いることができ、それ故ＩＭＳコアはＳＩＰヘッダのP-asserted identityを抹消すべきでなく、むしろＳＩＰヘッダのP-asserted identityをローカル・ゲートウェイのＳＩＰユーザエージェントに伝達すべきである。リモート・アクセス接続開始者である発信デバイスはそれ故ＩＮＶＩＴＥメッセージのプライバシーヘッダフィールドを「無」に設定することができる。それによりメッセージをローカル・ゲートウェイに転送する場合はP-asserted identityをＰ−ＣＳＣＦにより除去することはないであろう。

例示的な実施形態によるリモート・デバイスのローカル・ネットワークへのリモート・アクセス確立手順を次に図８を参照して説明することにする。この図が基本的に示すのは、図４のステップ４０４乃至ステップ４１０／ステップ４１０ａにより表す実行時動作である。仮定するのは、ネットワークのリモート・デバイスに関するおよびローカル・ゲートウェイに関する機能並びに信用証明を、例えば図５に対し説明するようにリモート・アクセスのためにＩＭＳコアにおいて事前に構成していることである。この例で、リモート・アクセスを許容するユーザのＩＭＳ識別子を包含するＩＭＳベースＡＣＬをローカル・ゲートウェイに代わりＩＭＳコアで保持する、即ちサーバ側手順をユーザの以上の許可に使用した。さらに、この場合このようにＡＣＬに存在するリモート・デバイスのユーザにリモート・アクセスを許容した。さらに、リモート・アクセスを許容するデバイスのＵＵＩＤを包含するＵＰｎＰベースＡＣＬをまた図示する例のローカル・ゲートウェイでデバイスのリモート・アクセス制御にも使用する。

ローカル・ゲートウェイが含むのは、ＲＡＳ８００およびＲＡユーザ管理者コンソール８０２並びにＩＭＳクライアント８０４を含むＲＡＳＵＭである。ＵＰｎＰベースＡＣＬはＲＡＳ８００で保持する。ＩＭＳコアはＨＳＳに蓄積する情報にアクセスするＲＡサーバ８０６を含み、実装に応じてＲＡサーバでまたはＨＳＳで若しくはＩＭＳコアの他の適切なノードで、ＩＭＳベースＡＣＬをフィルタ基準として保持することができる。リモート・デバイスが含むのは、ＲＡＣ８０８および同様にＲＡユーザ管理者コンソール８１０およびＩＭＳクライアント８１２を含むＲＡＳＵＭである。仮定するのは、ローカル・ネットワーク・オーナーおよびデバイスユーザが共にＩＭＳベースＲＡサービスの加入者であり、それによりＩＭＳセキュリティに基づく信頼関係を有する。

第１のステップ８：１で、ＩＭＳコアはリモート・デバイスのＩＭＳクライアント８１２からデバイスのユーザからローカル・ゲートウェイに向けた実際上セッションインビテーションであるＩＮＶＩＴＥメッセージを受信する。ＩＮＶＩＴＥメッセージはＳＩＰ ＩＮＶＩＴＥであり、デバイスユーザのＩＭＳ識別子、例えばSIP URIを含む。さらに、リモート・デバイスのＵＵＩＤはＳＩＰ本体に含む。

次のステップ８：２で、ＩＭＳコアのＡＣＬをチェックし、ローカル・ネットワークへのリモート・アクセス接続を誘起することをデバイスユーザに許可していることを検証し、またＲＡＣ８０８がＲＡＳ８００のセッションインビテーションに整合する機能を有することをチェックする。従って例えば図６に示す手順の結果として、デバイスユーザがＩＭＳベースＡＣＬに存在し、ＲＡＳ８００との通信ができれば、ＲＡＣ８０８とＲＡＳ８００間のリモート・アクセス接続が可能であり、リモート・アクセス接続を許容する。次に次のステップ８：３で、ステップ８：１で受信するＩＮＶＩＴＥメッセージをＲＡサーバ８０６からローカル・ゲートウェイのＩＭＳクライアント８０４に送信する。

ローカル・ゲートウェイで次に次のステップ８：４でチェックするのは、デバイス識別子であるＵＵＩＤがＲＡＳ８００のＵＰｎＰベースＡＣＬに存在するかである。デバイス識別子ＵＵＩＤがＵＰｎＰベースＡＣＬに存在しなければ、ステップ８：４ａでＲＡユーザ管理者コンソール８０２からの起動メッセージによりデバイス識別子ＵＵＩＤをＵＰｎＰベースＡＣＬに追加することができる。従来のＵＰｎＰリモート・アクセス設定手順を使用し、ＵＵＩＤのＵＰｎＰベースＡＣＬへの追加を含むことにより、ＲＡＳ８００のＲＡＤＡを次いでステップ８：４ｂで構成することになる。リモート・デバイスのＵＰｎＰベースＡＣＬへの追加に成功したことを、ＲＡユーザ管理者コンソール８０２はまたステップ８：４ｃでＩＭＳクライアント８０４に確認する。他方リモート・デバイスがＵＰｎＰベースＡＣＬに既に存在することがステップ８：４で見つかれば、ステップ８：４ａ乃至ステップ８：４ｃを省略することができる。

どちらの場合でもリモート・アクセスセッションに備えて、ローカル・ゲートウェイのＮＡＴ／ファイアウォールに「ピンホール」を開けることにより、ローカル・ゲートウェイにおいて入り方向接続構成を行うことができる。発信デバイスユーザに次いでステップ８：５で通知するのは、ＩＭＳクライアント８０４からＩＭＳクライアント８１２への、ＩＭＳコアを経て伝達する適切なＯＫメッセージ、例えばＳＩＰＯＫにより、ローカル・ゲートウェイがリモート・デバイスからリモート・アクセスを受理したことである。

リモート・アクセス接続を開始するＩＭＳクライアント８１２からＲＡＣ８０８へのステップ８：６における適切な起動メッセージの後、ステップ８：７でＲＡＣ８０８とＲＡＳ８００間で接続を最終的に確立する。接続の確立が含みうるのは、例えば図５のステップ５：７乃至ステップ５：９により配信し、ＲＡＳ８００に蓄積するリモート・デバイスの信用証明に基づくＲＡＣ８０８とＲＡＳ８００間のＶＰＮトンネルの設定である。ＶＰＮトンネルはリモート・アクセスのＵＰｎＰ仕様に従いＲＡＣ８０８により開始することができる。

リモート・デバイスのローカル・ネットワークへのリモート・アクセス確立の別の例示手順を次に図９を参照して説明することにする。関係するリモート・デバイス、ＩＭＳコアおよびローカル・ゲートウェイは基本的に図８におけるのと同じであり、機能ユニット８００乃至８１２をそれ故図９で再使用する。再度仮定するのは、リモート・デバイスに関するおよびローカル・ゲートウェイに関する機能および信用証明をリモート・アクセスのためにＩＭＳコアで構成していることである。この例で、ローカル・ゲートウェイのＩＭＳベースＡＣＬは同様にＩＭＳコアで保持するが、リモート・デバイスのユーザにリモート・アクセスを事前に許可しておらず、ユーザのＩＭＳ識別子はそれ故ＡＣＬには存在しない。さらにこの場合、ＵＰｎＰベースＡＣＬもまたＲＡＳ８００で保持し、リモート・デバイスのＵＵＩＤはＵＰｎＰベースＡＣＬにはない。

まず第１のステップ９：１でＩＭＳコアがリモート・デバイスから受信するのは、ローカル・ゲートウェイに向けたセッションインビテーション、即ち以上のステップ８：１の同等物としてユーザのＩＭＳ識別子およびデバイスのＵＵＩＤを含むＩＮＶＩＴＥメッセージである。次のステップ９：２で、ローカル・ゲートウェイのＩＭＳベースＡＣＬをＩＭＳコアでチェックし、デバイスユーザを検証し／デバイスユーザにリモート・アクセスを許容することができるかを調べる。リモート・デバイスおよびローカル・ゲートウェイがリモート・アクセスに整合する機能を有するか、即ちＲＡＴＡ機能および信用証明を図５の手順によりリモート・デバイスおよびローカル・ゲートウェイのために構成したかをまたチェックすることができる。

しかしながらユーザのＩＭＳ識別子はこの場合ＡＣＬに見つからず、次のステップ９：３でＩＭＳベースＡＣＬによりデバイスユーザを検証しなかったことの指示を伴うＩＮＶＩＴＥメッセージを、ＲＡサーバ８０６からローカル・ゲートウェイのＩＭＳクライアント８０４に送信する。これを示すことができるのは、対応するキーワードまたは同類のＩＮＶＩＴＥメッセージ、例えばＳＩＰ本体若しくはＳＤＰ（セッション記述プロトコル、Session Description Protocol）本体への追加による。にもかかわらず整合機能の所有により、リモート・デバイスは技術的にローカル・ゲートウェイとの接続を確立することができよう。

デバイスユーザを検証できなかったのでさらにステップ９：４で、非検証ユーザがリモート・アクセスセッションへのインビテーションを行ったことを、ローカル・ネットワーク・オーナーに通知し、適切なＧＵＩによりデバイスユーザへのリモート・アクセスの受理の可否に関し、オーナーに問い合わせを行う。この場合次のステップ９：５により示すように、ネットワーク・オーナーはユーザにリモート・アクセスを受理する。次のステップ９：６で、ＩＭＳクライアント８０４はＲＡユーザ管理者コンソール８０２を起動し、リモート・デバイスのＵＵＩＤをＲＡＳ８００のＵＰｎＰベースＡＣＬに追加し、通常のＵＰｎＰリモート・アクセス設定手順を使用して従ってステップ９：７で、ＲＡＳ８００のＲＡＤＡを構成する。ステップ９：８でＩＭＳクライアント８０４にＲＡユーザ管理者コンソール８０２がまた確認するのは、リモート・デバイスのＵＰｎＰベースＡＣＬへの追加に成功したことである。リモート・アクセスセッションに備えて、ローカル・ゲートウェイにＮＡＴ／ファイアウォールピンホールを開けることにより、入り方向接続構成を次に行うことができる。

ＲＡサーバ８０６によりまず受信する適切なＯＫメッセージ、例えばＳＩＰＯＫにより、ローカル・ゲートウェイがリモート・デバイスからリモート・アクセスを受理することを示す通知を次いでＩＭＳクライアント８０４からＩＭＳクライアント８１２に対しステップ９：９で送信する。通知を受信してユーザのＩＭＳ識別子のＩＭＳベースＡＣＬへの追加によりさらにステップ９：１０で、ＲＡサーバ８０６は次いでＩＭＳベースＡＣＬを更新する。ＲＡサーバ８０６はまたステップ９：１１でＯＫメッセージをＩＭＳクライアント８１２に送信する。ＩＭＳクライアント８１２はまたステップ９：１２で接続起動メッセージをＲＡＣ８０８に送信し、リモート・アクセス接続を開始する。最後に、例えば図８の以前の例の場合に説明するようにＲＡＳ８００に蓄積するリモート・デバイスの信用証明に基づくＲＡＣ８０８とＲＡＳ８００間のＶＰＮトンネルの設定により、ステップ９：１３で接続を確立する。

本発明を使用して使用するデバイスに関わらず、ＩＭＳベースＡＣＬのユーザのＩＭＳ識別子により許可するユーザの安全なリモート・アクセス接続を可能にするであろう方法で、上記の信頼モデルの問題を解決することができる。以上の例により示すように、リモート・アクセスに現在使用するデバイスもまたＵＰｎＰベースＡＣＬにおいて許可することができる。ＵＰｎＰＲＡＤＡの準拠を保証すると同時に、信用証明配信の問題もまた解決することができる。ＵＰｎＰＲＡＤＡとＵＰｎＰＲＡＴＡ間の全ての相互動作およびＲＡＣおよびＲＡＳの管理コンソールをそれぞれ真似ることにより、準拠をまた達成することができる。

信頼確立へのＩＭＳ認証／許可の再使用により、上記解決策はさらに信用証明、例えば証明書の配信にＩＭＳシステムの使用を可能にする。上記解決策をさらに使用して回避することができるのは、ＵＰｎＰＲＡに定義するようにディスカバリまたは対化処理の場合、ＲＡＣおよびＲＡＳは同じ物理ローカル・ネットワークに所在しなければならないとの要求であり、その回避によりＵＰｎＰリモート・アクセス構成をより魅力的で、有益にする。

例示的な特定の実施形態を参照して本発明を説明したが、説明は本発明の範囲を制限するものと解釈されるべきではない。本発明は、以下の独立請求項により一般的に定義される。

Claims (25)

1. ローカル・ネットワークの外部に位置するリモート・デバイス（３００）から前記ローカル・ネットワークのローカル・ゲートウェイ（３０２）へのリモート・アクセスを可能にするための方法であって、
   −前記リモート・アクセスのために、ＩＭＳコア（３０４）における前記リモート・デバイスおよび前記ローカル・ゲートウェイの機能並びに信用証明を構成する工程と、
   −許可された各ユーザのＩＭＳ識別子をＩＭＳベースのＡＣＬに追加することにより、前記ローカル・ネットワークへのリモート・アクセスを１人以上のユーザに許可する工程と、
   −前記ＩＭＳコアを介して、前記リモート・デバイスから前記ローカル・ゲートウェイへのアクセス要求を受信する工程、
   −前記リモート・デバイスのユーザが、前記ＩＭＳベースのＡＣＬのＩＭＳ識別子によるリモート・アクセスを許可されている場合に、前記アクセス要求を受理する工程と、
   −前記アクセス要求を受理した場合に、前記リモート・デバイスおよび前記ローカル・ゲートウェイの前記構成された機能並びに信用証明を使用して、リモート・アクセス接続を確立する工程と
   を備えることを特徴とする方法。
2. 前記リモート・デバイスのＩＭＳクライアント（３００ｂ）と前記ＩＭＳコアのリモート・アクセス・サーバ（３０４ａ）との間のＩＭＳメッセージングにより、前記リモート・デバイスの前記機能および信用証明が構成され、
   前記リモート・デバイスのＩＭＳクライアント（３０２ｂ）と前記リモート・アクセス・サーバ（３０４ａ）との間のＩＭＳメッセージングにより、前記ローカル・ゲートウェイの前記機能および信用証明が構成される、ことを特徴とする請求項１に記載の方法。
3. 前記信用証明は、ＶＰＮトンネルを確立するための証明書を含む、ことを特徴とする請求項１または請求項２に記載の方法。
4. 前記機能は、前記ローカル・ゲートウェイにおけるＲＡＳのＲＡＴＡ機能と、前記リモート・デバイスにおけるＲＡＣのＲＡＴＡ機能とを含む、ことを特徴とする請求項１乃至請求項３の何れか１項に記載の方法。
5. 前記リモート・デバイスが前記ローカル・ネットワークの外部に位置するときに、前記機能および信用証明が構成される、ことを特徴とする請求項１乃至請求項４の何れか１項に記載の方法。
6. 許可されたユーザは、自身のＩＭＳ識別子を用いて、任意の端末から前記ローカル・ネットワークにリモートでアクセス可能である、ことを特徴とする請求項１乃至請求項５の何れか１項に記載の方法。
7. 前記ＩＭＳベースのＡＣＬは、前記ＩＭＳコアのリモート・アクセス・サーバ（３０４ａ）で保持される、ことを特徴とする請求項１乃至請求項６の何れか１項に記載の方法。
8. 前記ＩＭＳベースのＡＣＬは、前記ローカル・ゲートウェイにおいて保持される、ことを特徴とする請求項１乃至請求項６の何れか１項に記載の方法。
9. 前記リモート・デバイスのユーザが、自身のＩＭＳ識別子によるリモート・アクセスを許可されていない場合、前記ローカル・ネットワークを制御するローカル・ネットワーク・オーナーにとって前記アクセス要求が受理可能であるかが判定される、ことを特徴とする請求項１乃至請求項８の何れか１項に記載の方法。
10. 前記アクセス要求が受理可能か否かに関して、前記ローカル・ネットワーク・オーナーに問い合わせが行われる、ことを特徴とする請求項９に記載の方法。
11. リモート・アクセスが許可されたデバイスのＵＵＩＤを包含するＵＰｎＰベースのＡＣＬが、前記ローカル・ゲートウェイにおいて保持される、ことを特徴とする請求項１乃至請求項１０の何れか１項に記載の方法。
12. 前記アクセス要求が受理された場合に、前記リモート・デバイスの前記ＵＵＩＤを前記ＵＰｎＰベースのＡＣＬに追加する、ことを特徴とする請求項１１に記載の方法。
13. ローカル・ネットワークの外部に位置するリモート・デバイス（３００）から前記ローカル・ネットワークのローカル・ゲートウェイ（３０２）へのリモート・アクセスを可能にする、ＩＭＳコア（３０４）におけるリモート・アクセス・サーバ（３０４ａ）であって、
    −前記リモート・アクセスのために、前記ＩＭＳコアにおける前記リモート・デバイスおよび前記ローカル・ゲートウェイの機能及び信用証明を構成する手段と、
    −許可された各ユーザのＩＭＳ識別子をＩＭＳベースのＡＣＬに追加することにより、前記ローカル・ネットワークへのリモート・アクセスを１人以上のユーザに許可する手段と、
    −前記ＩＭＳコアを介して、前記リモート・デバイスから前記ローカル・ゲートウェイへのアクセス要求を受信する手段と、
    −前記リモート・デバイスのユーザが、前記ＩＭＳベースのＡＣＬのＩＭＳ識別子によるリモート・アクセスを許可されている場合に、前記アクセス要求を受理する手段と、
    −前記アクセス要求を受理した場合に、前記リモート・デバイスおよび前記ローカル・ゲートウェイの前記構成された機能及び信用証明を使用して、リモート・アクセス接続を確立する手段と
    を備えることを特徴とするリモート・アクセス・サーバ。
14. 前記リモート・デバイスのＩＭＳクライアント（３００ｂ）と前記ＩＭＳコアのリモート・アクセス・サーバ（３０４ａ）との間のＩＭＳメッセージングにより、前記リモート・デバイスの前記機能および信用証明が構成され、
    前記リモート・デバイスのＩＭＳクライアント（３０２ｂ）と前記リモート・アクセス・サーバ（３０４ａ）との間のＩＭＳメッセージングにより、前記ローカル・ゲートウェイに関する前記機能および信用証明が構成されるように適合された、請求項１３にリモート・アクセス・サーバ。
15. 前記信用証明は、ＶＰＮトンネルを確立するための証明書を含む、ことを特徴とする請求項１３または請求項１４に記載のリモート・アクセス・サーバ。
16. 前記機能は、前記ローカル・ゲートウェイにおけるＲＡＳ（３０２ｄ）のＲＡＴＡ機能と、前記リモート・デバイスにおけるＲＡＣ（３００ｄ）のＲＡＴＡ機能とを含む、ことを特徴とする請求項１３乃至請求項１５の何れか１項に記載のリモート・アクセス・サーバ。
17. 前記リモート・デバイスが前記ローカル・ネットワークの外部に位置する場合に、前記機能および信用証明が構成されるように適合された、請求項１３乃至請求項１６の何れか１項に記載のリモート・アクセス・サーバ。
18. 許可されたユーザは、自身のＩＭＳ識別子を用いて、任意の端末から前記ローカル・ネットワークにリモートでアクセス可能である、ことを特徴とする請求項１３乃至請求項１７の何れか１項に記載のリモート・アクセス・サーバ。
19. 前記ＩＭＳベースのＡＣＬは、前記ＩＭＳコアのリモート・アクセス・サーバ（３０４ａ）で保持される、ことを特徴とする請求項１３乃至請求項１８の何れか１項に記載のリモート・アクセス・サーバ。
20. 前記ＩＭＳベースのＡＣＬは、前記ローカル・ゲートウェイにおいて保持される、ことを特徴とする請求項１３乃至請求項１８の何れか１項に記載のリモート・アクセス・サーバ。
21. ローカル・ネットワークの外部に位置するリモート・デバイス（３００）からローカル・ゲートウェイへのリモート・アクセスを可能にする、前記ローカル・ネットワークの前記ローカル・ゲートウェイ（３０２）であって、
    −前記リモート・アクセスのために、ＩＭＳコア（３０４）における前記ローカル・ゲートウェイの機能および信用証明を構成する手段と、
    −前記ＩＭＳコアを介して前記リモート・デバイスからアクセス要求を受信する手段と、
    −前記リモート・デバイスのユーザが、自身のＩＭＳ識別子によるリモート・アクセスを許可されている場合に、前記アクセス要求を受理する手段と、
    −前記アクセス要求を受理した場合に、前記リモート・デバイスおよび前記ローカル・ゲートウェイについて構成された前記機能及び信用証明を使用して、リモート・アクセス接続を確立する手段と
    を備えることを特徴とするローカル・ゲートウェイ。
22. 前記リモート・デバイスのユーザが、自身のＩＭＳ識別子によるリモート・アクセスを許可されていない場合、前記ローカル・ネットワークを制御するローカル・ネットワーク・オーナーにとって前記アクセス要求が受理可能であるかが判定されるように適合された、ことを特徴とする請求項２１に記載のローカル・ゲートウェイ。
23. 前記アクセス要求が受理可能か否かに関して、前記ローカル・ネットワーク・オーナーに問い合わせが行われる、ことを特徴とする請求項２２に記載のローカル・ゲートウェイ。
24. リモート・アクセスが許可されたデバイスのＵＵＩＤを包含するＵＰｎＰベースのＡＣＬが、前記ローカル・ゲートウェイにおいて保持される、ことを特徴とする請求項２１乃至請求項２３の何れか１項に記載のローカル・ゲートウェイ。
25. 前記アクセス要求が受理された場合に、前記リモート・デバイスの前記ＵＵＩＤを前記ＵＰｎＰベースのＡＣＬに追加する、ことを特徴とする請求項２４に記載のローカル・ゲートウェイ。

Images