IMS非対応端末を使用してIPマルチメディアサブシステムIMSのサービスにアクセスするのを支援する方法であって、ホームIMSゲートウェイに対してIMS非対応端末を登録する工程と、前記IMS非対応端末の登録に応えて、前記ホームIMSゲートウェイに存在するUMTS用ICカードUICCの汎用SIMアプリケーションから取得した情報を使用して、前記IMS非対応端末に成り代わって、前記ホームIMSゲートウェイと前記IMSとの間でIMS登録を実行する工程とを含むことを特徴とする方法。前記ホームIMSゲートウェイは、前記UMTS用ICカード上のISIMへのインターフェースを有するSIPバックトゥバックユーザエージェントを含むことを特徴する請求項1に記載の方法。前記IMS非対応端末がSIP端末である場合に、前記ホームIMSゲートウェイに対してIMS非対応端末を登録する前記工程には、前記SIP端末と前記SIPバックトゥバックユーザエージェントとの間でSIP登録を実行する工程を含むことを特徴とする請求項2に記載の方法。前記SIP端末は、前記SIPバックトゥバックユーザエージェントに対して、該SIP端末に対して関係付けられることになっているパブリックユーザ識別情報を通知することを特徴とする請求項3に記載の方法。前記SIP端末は、前記SIPバックトゥバックユーザエージェントによって、あらかじめ記憶されているパブリックユーザ識別情報に対してマッピングされるローカル識別情報を供給することを特徴とする請求項3に記載の方法。前記IMS登録には、前記IMS非対応端末に関係付けられた前記パブリックユーザ識別情報をIMSネットワークに対して通知するとともに、前記IMSネットワークと前記SIPバックトゥバックユーザエージェントとの間でSIP登録を実行する工程が含まれることを特徴とする請求項2乃至5のいずれか1項に記載の方法。前記IMS非対応端末がSIP端末でない場合に、前記ホームIMSゲートウェイに対してIMS非対応端末を登録する前記工程には、前記IMS非対応端末の端末入線上でのループを検出する工程を含むことを特徴とする請求項1に記載の方法。前記ホームIMSゲートウェイには、前記IMS非対応端末に対して割当てられ、かつ、前記IMSに対して登録する際に使用されるデフォルトのパブリックユーザ識別情報があらかじめ記憶されていることを特徴とする請求項1または7に記載の方法。前記ホームIMSゲートウェイに対する前記IMS非対応端末の登録は、前記UMTS用ICカード上のISIMへのインターフェースを有するSIPゲートウェイによって実行されることを特徴とする請求項1、7または8に記載の方法。IMS非対応端末を使用してIPマルチメディアサブシステムIMSのサービスにアクセスするのを支援するためのホームIMSゲートウェイを動作させる方法であって、前記ホームIMSゲートウェイに対してIMS非対応端末を登録する工程と、前記IMS非対応端末の登録に応えて、前記ホームIMSゲートウェイに存在するUMTS用ICカードUICCの汎用SIMアプリケーションから情報を取得し、取得した該情報を使用して、前記IMS非対応端末に成り代わって、前記IMSに対してIMS登録を実行する工程とを含むことを特徴とする方法。IMS非対応端末を使用してIPマルチメディアサブシステムIMSのサービスにアクセスするのを支援するためのホームIMSゲートウェイであって、前記ホームIMSゲートウェイをIMS非対応端末へ接続するための少なくとも1つのインターフェースと、UMTS用ICカードUICCからISIMアプリケーションデータを読み出すUICCリーダ装置と、IMS非対応端末を前記ホームIMSゲートウェイに対して登録する第1処理手段と、前記ホームIMSゲートウェイに登録されたIMS非対応端末を、前記IMSに対して登録する第2処理手段とを含むことを特徴とするホームIMSゲートウェイ。前記ホームIMSゲートウェイをIMS非対応端末へ接続するための前記インターフェースは、前記ホームIMSゲートウェイとレガシー機器とを接続するための回線インターフェース、LANインターフェース、または、無線LANインターフェースであることを特徴とする請求項11に記載のホームIMSゲートウェイ。前記第1処理手段及び前記第2処理手段は、前記IMSによって使用されるセッション開始プロトコルSIPと前記IMS非対応端末によって使用されているプロトコルとの間でプロトコル変換を実行するSIPゲートウェイを実現する手段を含むことを特徴とする請求項11または12に記載のホームIMSゲートウェイ。前記第1処理手段及び前記第2処理手段は、SIP端末に対してはSIPサーバとして動作し、前記IMSに対してはSIPクライアントとして動作するSIPバックトゥバックユーザエージェントを実現する手段を含むことを特徴とする請求項11または12に記載のホームIMSゲートウェイ。HIGに関する現在の提案は、3GPP技術仕様書33.203に規定されるIMSに対する現行アクセスセキュリティ要件とある程度相反する。この要件は、IMSにアクセスする各端末がIMSSIMISIM:IMS加入者識別IDモジュールアプリケーションにアクセスすることを条件としている。ISIMは、ネットワークオペレータに対して加入者を証明し、ネットワークで使用可能なサービスへのアクセスを正当とするのに必要な、加入者識別情報および他の情報を格納するモジュールである。ISIMアプリケーションは、汎用ICカードUICC、現在のGSMSIMカードに類似により提供される。もちろん、レガシー装置などの非IMS端末は、必要なUICCカードリーダまたはIMS機能を有しないであろう。アクセスセキュリティ要件を満足しながら、非IMS端末からIMSサービスへのアクセスを可能にする課題の解決策は、非IMS端末のおのおのにISIMアプリケーションを有するUICCを割当てることである。次いでユーザは、その端末をIMSサービスのアクセスに使用したいとき、特定の非IMS端末に関係するUICCをHIGに挿入しなければならない。この解決策は、柔軟性、便宜性および費用の点で明らかに不利である。本発明の第1の実施形態では、IMS非対応端末を使用してIPマルチメディアサブシステムIMSサービスにアクセスするのを支援する方法が提供される。その方法は、ホームIMSゲートウェイにIMS非対応端末を登録する工程と、その登録に応えて、ホームIMSゲートウェイにあるUMTS用ICカードの汎用SIMアプリケーションから取得した情報を使用して、前述したIMS非対応端末とホームIMSゲートウェイとIMSとの間でIMS登録を実行する工程とを備える。本発明の実施形態は、実際のところホームIMSゲートウェイにIMS登録を委託する。したがって、IMSサービスを使用したいと望む各端末が、ISIMアプリケーションを格納するUICCカードにアクセスすることは必ずしも必要でない。ホームIMSゲートウェイは、UICC上の前述したISIMへのインターフェースを有するSIPバックトゥバックユーザエージェントを備えるのが好ましい。前述したIMS非対応端末がSIP端末の場合、ホームIMSゲートウェイへの端末の登録は、端末とSIPバックトゥバックユーザエージェントとの間のSIP登録実施工程を備える。端末は、SIPバックトゥバックユーザエージェントに、端末に関係付けられたパブリックユーザIDを知らせてもよい。代わりに、端末はローカルIDを提供してもよく、そのローカルIDは、SIPバックトゥバックユーザエージェントによりあらかじめ格納されたパブリックユーザIDにマッピングされる。前述したIMS登録は、IMSネットワークに端末に関係付けられたパブリックユーザIDの通知を含む、バックトゥバックユーザエージェントとIMSネットワークとの間のSIP登録の実行工程を備える。IMS非対応端末がSIP端末でない場合、ホームIMSゲートウェイに端末を登録する工程は、例えばループ形成の検出を含み、ゲートウェイと端末との最初の接続に続いて実行されてもよい。すでに接続されている端末に関しては、登録はHIGの電源オン時に行われてもよい。ゲートウェイは、非SIP端末に割当てられIMS登録時に使用されるデフォルトのパブリックユーザIDを、自装置の中にあらかじめ格納しておいてもよい。より好ましいのは、UICCの前述したISIMとのインターフェースを有するSIPゲートウェイにより登録が実行されることである。SIPゲートウェイは、SIPとこれら非SIP端末が使用するプロトコルとの間のプロトコル変換を実行する。本発明の第2の様相によれば、IMS非対応端末からIPマルチメディアサブシステムIMSサービスにアクセスするのを支援する、ホームIPマルチメディアサブシステムゲートウェイを操作する方法が提供される。その方法は、ホームIMSゲートウェイにIMS非対応端末を登録する工程と、前述した登録に応えて、ホームIMSゲートウェイにあるUMTS用ICカードの汎用SIMアプリケーションから情報を取得する工程と、前述した端末の代わりにこの情報でIMSにIMS登録を実行する工程とを備える。本発明の第3の実施形態によれば、IMS非対応端末からIPマルチメディアサブシステムIMSサービスにアクセスするのを支援する用途向けに構成された、ホームIPマルチメディアサブシステムゲートウェイが提供される。その装置は、ゲートウェイと前述したIMS非対応端末とを接続する少なくとも1つのインターフェースと、UICCカードからISIMアプリケーションデータを読み出すためのUICCカードリーダと、ゲートウェイにIMS非対応端末を登録する第1の処理手段と、ゲートウェイに登録されたIMS非対応端末をIMSに登録する第2の処理手段とを備える。ゲートウェイと前述したIMS非対応端末とを接続するインターフェースは、例えばゲートウェイとブラックフォン黒電話機若しくはDECT電話機などのレガシー装置とを接続する回線インターフェースまたはLANインターフェース若しくはWLANインターフェースであってもよい。第1および第2の処理手段は、IMSが使用するセッション開始プロトコルSIPとIMS非対応端末が使用するプロトコルとの間のプロトコル変換を実行するSIPゲートウェイを実装する手段を備えてもよい。非SIP端末に対しては、SIPゲートウェイは、ISIMのプライベートユーザIDに関係するデフォルトパブリックユーザIDをIMSに登録してもよい。第1および第2の処理手段は、SIP端末に対してはSIPサーバの機能を果たし、IMSに対してはSIPクライアントとして機能するSIPバックトゥバックユーザエージェントを備えてもよい。SIPバックトゥバックユーザエージェントは、ISIMのプライベートユーザIDに関係する個人用パブリックユーザIDをIMSに登録してもよい。前述したように、図1の一般的なIMSアーキテクチャに、いわゆるホームIMSゲートウェイHIGを導入することを提案している。図2は、家庭または小規模事業所内に設置され、レガシー装置とSIP対応端末の両方を含む相当数の端末に便宜をもたらすHIG図では住宅用ゲートウェイと呼ぶを図解する。図3は、様々な外部ユーザ端末とのインターフェースとともに、HIGの機能アーキテクチャを詳細に図解する。特に、ワイドエリアネットワークWAN/ローカルエリアネットワークLANインターフェースが、HIGをIMSに接続するために使用される。SIP端末でない様々なレガシー端末は、SIPゲートウェイに接続する回線インターフェースを介してHIGに接続する。レガシー端末の例に、DECT電話機および従来の電話機黒電話機がある。HIGは、セッション開始プロトコルSIPゲートウェイ3GPPTS24.229およびIETFRFC3261に準拠して実装を有する。SIPゲートウェイは、様々なクライアント端末のシグナリングプロトコルとIMSが使用するSIPプロトコルとの間の相互作用を可能にする。例えば、SIPゲートウェイは、黒電話機が使用するISDNベースのシグナリングプロトコルとSIPとの間の変換を提供してもよい。SIPゲートウェイは、WAN/LANインターフェースに接続している。デスクトップPCおよびノートPCならびにSIP電話機などのIMS対応SIP端末は、ローカルエリアネットワークLANおよび/または無線ローカルエリアネットワークWLANにアタッチ接続しており、それらネットワークに、HIGもLAN/WLANインターフェースを介して接続している。ネットワークアドレス変換NAT/ファイアウォールFWレイヤが、HIG内のアドレスのマッピングを提供するために使用される。NAT/FWレイヤは、WAN/LANインターフェースに接続している。これらの各端末は、それぞれのISIMアプリケーションを格納する自端末のUICCを有している。ISIMアプリケーションにアクセスできないIMS非対応SIP端末も、端末のLAN/WLANインターフェースとHIGのLAN/WLANインターフェースを介してHIGに接続している。これらの端末に関するIMSサービスへのアクセスは、NAT/FWエンティティを有するSIPバックトゥバックユーザエージェントB2BUAが支援する。SIPB2BUAは、ユーザ装置に対してはSIPサーバの機能を果たし、IMSに対してはSIPクライアントとしての機能を果たす。SIPB2BUAとSIPゲートウェイの両方とも、UICCに格納されるISIMアプリケーションとのインターフェースを有する。このUICCは、HIGハードウェアから取り外し可能であってもよいし、HIGに永久的に固定されてもよい。ISIMアプリケーションは、HIGを介してIMSに接続する非ISIM端末のすべてが利用可能であり、すべてに有効である。自端末のISIMアプリケーションにアクセスできる端末は、HIG内のISIMをもちろん使用せず、上記のようにHIGのNAT/FW機能だけを使用する。続く検討の中では、ISIMアプリケーションのすべて、すなわちHIGが利用可能なアプリケーションとユーザ端末装置が利用可能なアプリケーションとは、1回の加入申し込みでIMSに関係付けられることに注意。HIGの動作をさらに検討する前に、プライベートユーザIDおよびパブリックユーザIDの概念をまず導入する。これらはIMSの動作に本質的に必要であり、3GPPTS23.2286.7.0で検討されている。プライベートユーザIDは、ISIMに結びついたIDであり、加入者を証明し正当とするために使用される。プライベートユーザIDは、サードパーティには通常開示されておらず、GSMネットワークで使用される国際移動電話加入者識別番号IMSIにいくぶん類似している。他方パブリックユーザIDは、IMSサービスに参加する目的で加入者および/またはそのユーザ装置を識別するために使用され、電子メールアドレスまたは電話番号にいくぶん類似している。パブリックユーザIDは、例えばIMSサービスセッション要求の宛先を識別するために使用される。加入者は、1つのプライベートユーザIDに関係付けられた幾つかのパブリックユーザIDを有してもよいし、それに対して所与の加入申し込みに関係付けられた異なる複数のプライベートユーザIDが、共通のパブリックユーザIDを共用してもよい。IMS登録中に認証が成功したと仮定すると、IMSは加入者に関係付けられたパブリックユーザIDの通知を受ける。図4は、図3のHIGを使用して実装してもよい、パブリックユーザIDとプライベートユーザIDとのマッピングを図解する。この例では、同一のIMS加入申し込みに関係付けられた2つのプライベートユーザIDがある。234150123456operator.netは、幾つかのSIP対応ユーザ端末装置のISIMに格納されているプライベートユーザIDであり、234150654321operator.netは、HIGのISIMに格納されているプライベートユーザIDである。デフォルトパブリックユーザIDは、加入者に関係付けられていて、HIGを介してIMSにアクセスし、加入申し込みを所有する家庭または小規模事業所を識別するグループIDと見なすことができる。デフォルトパブリックユーザIDは、HIGに格納され、HIG内のISIMのプライベートユーザID234150654321operator.netとだけ、SIPB2BUAで関係付けられている。少なくともSIP非対応端末のすべて、すなわち関係するパブリックユーザIDをHIGに通知することができない端末は、他のサードパーティのIMSユーザがデフォルトパブリックIDを使用して電話を掛けるとき、そのユーザから着信可能であるべきである。図4の例では、デフォルトパブリックユーザIDは、smithoperator.netである。このデフォルトパブリックユーザIDは、この例では44113111123456など、E.164番号の形態で非開示のパブリックIDに関係付けることができる。非開示の回線IDはネットワーク内で設定されており、B2BUAは登録手続きの一部としてこの回線IDをダウンロードする。ユーザ例えば、家族の一員AliceSmithは、2つの端末を連絡可能にしたいと考えているものとする。1つ目の端末は、プライベートユーザID234150123456operator.netを割当てられているユーザ端末装置であり、2つ目の端末は、SIP対応でかつHIGに接続する非IMSのホームPCである。それ故、IMSネットワーク内では、AliceのパブリックユーザIDalice.smithoperator.netは、両方のプライベートユーザIDに関係付けられなければならない。Aliceはさらに、近い親族および親しい友人だけに知らせるパブリックユーザIDaliceoperator.netを有する。Aliceは、自分のユーザ端末装置でだけこのパーソナルIDに到達可能にしたいと希望しているいものとする。それ故、このIDは、プライベートユーザIDである234150123456operator.netだけに関係付けられている。Aliceの夫Bobは、非IMSだがSIP対応の自分のノートパソコンを介してだけ連絡可能にしたいと希望しているものとする。それ故、BobのパブリックユーザIDbob.smithoperator.netは、HIG内のISIMのプライベートユーザIDである234150654321operator.netだけにIMSネットワーク内で関係付けられている。BobとAliceの各端末内のSIPユーザエージェントUAはそれぞれ、HIG内のSIPB2BUAを介して、IMSネットワークでそれぞれのプライベートユーザIDに関係付けられる、それぞれのパーソナルIDを登録する。既に述べたように、プライベートユーザIDにも関係付けられるデフォルトパブリックユーザIDは、IMSネットワークにも登録される。デフォルトのIDは、パーソナルIDの登録前または登録後のいずれのときに登録されてもよい。図5は、SIP対応でかつ非IMS端末である1組のUA1とUA2を、HIGのB2BUAに登録し、続いてB2BUAとIMSとの間で認可する手順に関連したシグナリングを示す図である。図に示すのは、IMSネットワークのプロキシ呼セッション制御機能P-CSCFノードおよびサービング呼セッション制御機能S-CSCFノード、それにネットワークオペレータに属し加入データおよびアクセスデータを有するホーム加入者サーバHSSである。シグナリング手順は、3GPPTS24.229およびTS24.228に基づく。1.UA1は、ISIMに関する加入申し込みと関係するローカルユーザネームbobを含むToヘッダを使用して、HIGのSIPB2BUAに登録する。2.B2BUAは、状況に応じてユーザに身元確認を要求する。加入者はローカル局所的に、ローカルユーザが身元確認を要求されるべきか否かを設定することと、ローカルユーザが使用するパスワードを設定することができる。3.UA1は、身元確認を要求された場合、登録メッセージを再送する。その場合、メッセージは、ユーザネームパラメータに含まれる身元確認要求されたユーザのIDbobを含むAuthorizationヘッダを有する。4.SIPB2BUAは、P-CSCFとの間でTCP接続通常はポート5061番を確立する。5.SIPB2BUAは、TLSハンドシェイクを行い、TLS接続を確立する。TLSハンドシェイクは、既存のTLSセッションを再び用いてもよい。3GPPで現在規定されているIPsecは、NATを越えることができないので、選択の余地はない。それ故、TLSがこの例では使用される。6.B2BUAは、ユーザネームとしてHIGのISIMに格納されたプライベートユーザID234150654321operator.netを使用する。Contactヘッダは、B2BUAのIPアドレスまたはドメインネームを有する。通常このIPアドレスは動的ホスト設定プロトコルDHCPにより割当てられる。P-CSCFのアドレスまたは名前も、DHCPにより割当てられる。Toヘッダ内の選択されたパブリックユーザIDは、UA1から送信されたToヘッダ内の値かまたはマッピングされた名前すなわちbob.smithoperator.netである。UA1が使用するローカルユーザネームは、HIGによりパブリックユーザIDにマッピングされる。加入者は、そのようなマッピングをローカルに構成することができる。7.P-CSCFは、幾つかのヘッダProxy-RequireおよびSecurity-Clientと幾らかのヘッダ情報例えば、Requireヘッダのsec-agreeを除いた後、S-CSCFに要求を送信する。8.クライアントが認証されなければならず、S-CSCFにこの加入申し込みに対する認証ベクトルがまだ存在しない場合には、S-CSCFは、HSSに認証ベクトルを要求する。通常、加入申し込みコンテキストは、S-CSCF内で各加入申し込みに対して作成され、その加入申し込みに対する新規登録に続いて、コンテキストのフラグは、未認証から認証済状態に切替えられる。9.HSSは、S-CSCFに1つまたは複数の認証ベクトルを返信する。10.S-CSCFは、クライアント認証が必要な場合、RANDおよびAUTNを有するSIP401メッセージでB2BUA/ISIMに身元確認を要求する。11.P-CSCFは、401メッセージに幾つかのヘッダを加えてから、B2BUAに401メッセージを送信する。12.401により身元確認を要求された場合、B2BUAは、RESを計算するとともに、AUTNを確かめる。次いでB2BUAは、RESを共有鍵として使用したダイジェストを有するAuthorizationヘッダを含む新しいREGISTERメッセージを送信する。13.P-CSCFは、幾つかのヘッダProxy-Require、Security-Verify、Security-Clientと幾らかのヘッダ情報例えば、Requireヘッダのsec-agreeとを除外した後、S-CSCFにリクエストを送信する。S-CSCFは、B2BUAからのRESに基づくダイジェストとXRESから計算したダイジェストを照合する。これが必要なのは、B2BUAが身元確認要求された場合だけである。14.S-CSCFは、Pathヘッダ、Service-RouteヘッダおよびP-Associated-URIヘッダを有する、SIP200メッセージで返答する15.B2BUAは、Service-RouteヘッダおよびP-Associated-URIヘッダの中身を格納し、次にPathヘッダ、Service-RouteヘッダおよびP-Associated-URIヘッダを除去してから、UA1に200メッセージを送信する。これで、UA1に関する登録手続きが完了する。16.UA2は、ISIMの加入申し込みに関係するローカルユーザネームaliceを有するToヘッダを使用して、SIPB2BUAに登録する。17.B2BUAは、状況に応じてユーザに身元確認を要求する。18.UA2は、身元確認要求された場合、登録メッセージを再送する。その場合メッセージは、ユーザネームパラメータに含まれる身元確認要求されたユーザのIDaliceを含むAuthorizationヘッダを有する。19.B2BUAは、ユーザネームとしてISIMに格納されたプライベートユーザID234150654321operator.netを使用する。Toヘッダ内の選択されたパブリックユーザIDは、マッピングされた名前alice.smithoperator.netである。20.P-CSCFは、幾つかのヘッダProxy-Require、Security-Verify、Security-Clientおよび幾らかのヘッダ情報例えば、Requireヘッダのsec-agreeを除外した後、S-CSCFに要求を送信する。21.S-CSCFはプライベートユーザIDを既に認証しているのでサービスコンテキストがある、認証を再び行う必要はない。22.S-CSCFは、Pathヘッダ、Service-RouteヘッダおよびP-Associated-URIヘッダを有するSIP200メッセージで応答する。23.B2BUAは、Service-RouteヘッダおよびP-Associated-URIヘッダの中身を格納し、次にPathヘッダ、Service-RouteヘッダおよびP-Associated-URIヘッダを除去してから、UA1に200メッセージを送信する。これで、端末UA2はIMSに登録される。図6は、レガシー電話機すなわち黒電話機の登録に関連するシグナリングを図解する。黒電話機はSIP端末ではないので、HIGへの端末の登録は、HIGの電源オンまたは黒電話機とHIGとの接続に続いてSIPゲートウェイで行われる。REGISTERメッセージのToヘッダ内のパブリックユーザIDに関して、HIGは、デフォルトユーザIDであるsmithoperator.netを選択する図6。SIP対応端末のシナリオをまた考慮して、図7は、HIGの後方にあるUA1がセッションの始端となる場合の、IMSセッション確立に関連するシグナリングを図解する。シグナリングの工程は以下の通りである。1.UA1は、B2BUAにSIPINVITEを送信する。2.B2BUAは、100Tryingで応答する。3.B2BUAは、INVITEメッセージに幾つかのヘッダを加える。Fromヘッダは、ユーザに対するパーソナルIDに等しいパブリックユーザIDに変換される。P-Preferred-Identityヘッダも、パーソナルIDを有する。P-Access-Network-Infoは、アクセス名を有する。場合によっては、アプリケーションはこのアクセス名を知らず、その場合はアクセスネットワークのどこかで加えられてもよいし、加入者が設定してもよい。電話番号は、ISIMに格納された回線IDに基づき加えることができる。B2BUAは、Contactヘッダを変更し、P-CSCFにINVITEを送信する。4.100Trying。5.ネットワークの視点からは認証された場合、P-CSCFは、P-Preferred-Identityを除去し、P-Preferred-Identityの中身を有するP-Asserted-Identityを代わりに挿入する。次いでP-CSCFは、S-CSCFにINVITEを送信する。6.100Trying。7.S-CSCFは、INVITEがネットワークから送信される前に、P-Access-Network-Infoを除去する。8.100Trying。9.着信側UAは、180Ringingを送信する。10.着信側UAは、200OKを送信する。11.UA1は、ACKで200OKの受信を通知する。図8は、UA1がセッションの終端となる場合において、IMSセッションの確立に関連するシグナリングを図解する。シグナリング工程は、以下の通りである。1.遠くにあるUAが、S-CSCFにSIPINVITEを送信する。2.S-CSCFは、100Tryingで応答する。3.S-CSCFは、登録時に格納された連絡アドレスを抽出し、Request-URIとして挿入する。S-CSCFは、P-Called-Party-IDヘッダに元のRequest-URIを挿入し、P-CSCFにINVITEを送信する。4.P-CSCFは、100Tryingで応答する。5.P-CSCFは、P-Charging-Vectorを除去し、B2BUAにINVITEを送信する。6.B2BUAは、100Tryingで応答する。7.B2BUAは、P-Asserted-Identityを移動する実行可能手段は、Fromヘッダ内の中身をP-Asserted-Identity内の中身で置き換える。Record-Routeヘッダが移動される。実行可能手段は、B2BUAがToヘッダの中身を置き換えるためにP-Called-Party-IDの中身を使用することである。B2BUAは、前に登録したホームユーザを見つけるため、受信要求内のRequest-URIを使用する。Request-URIは、ローカルに格納された連絡アドレスで置き換えられる。B2BUAは、UA1にINVITEを送信する。8.UA1は、100Tryingで応答する。9.UA1は、180Ringingで応答する。10.遠くのUAは、S-CSCFおよびP-CSCFを介して、UA1にACKを送信する。相当数の重要な利点が、上記手順の実装から生じる。特に、幾つかのユーザに対してISIMは1つしか必要ない。これにより、システムの費用が減少し、柔軟性が増大する一方で、UICCが提供するセキュリティ向上の利点を依然として活かすことができる。他の利点は次の通りである。●ISIMを有しない端末は、HIGから延びている保護されたトンネル、ならびにHIG内のNATとファイアウォールの境界防護を利用できる。●オペレータは、パスワードを提供し維持する必要がない。ローカルパスワードの設定は、加入者にまかせる。●非IMSでSIP対応PCが使用するローカルパーソナルIDをIMSネットワークの特定のパブリックユーザIDにマッピングするとき、パーソナルIDを使用することはまだ可能である。本発明の範囲から逸脱することなしに上記の実施形態に対して、様々な変更形態の作成が可能であることは、当業者なら理解するであろう。