メッセージングサービスとソーシャルネットワークサービスSNS間の相互作用を介してクライアント端末で連絡先を受信する方法であって、前記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請するステップと、前記要請に対応する連絡先プロフィールリストのうちで前記サーバによりフィルターされた連絡先プロフィールリストを前記サーバから受信するステップと、前記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認するステップと、を含むことを特徴とする連絡先を受信する方法。前記連絡先プロフィールリストは、名前、メールアドレス及び電話番号のうち少なくとも一つを含むことを特徴とする請求項1に記載の連絡先を受信する方法。前記確認するステップは、前記受信された連絡先プロフィールリストに前記自身と同一のサービスのアドレスがあるかを判断するステップであることを特徴とする請求項1に記載の連絡先を受信する方法。前記判断の結果、前記自身と同一のサービスのアドレスがある場合、前記自身と同一のサービスのアドレスを有する少なくとも一つの連絡先を加入リストに追加するステップをさらに含むことを特徴とする請求項3に記載の連絡先を受信する方法。前記加入リストに追加された前記少なくとも一つの連絡先に該当する相手方が登録したサービスリストをサービス登録サーバに要請するステップと、前記サービス登録サーバから前記サービスリストを受信するステップと、をさらに含むことを特徴とする請求項4に記載の連絡先を受信する方法。前記サービスリストに前記自身と同一のサービスがあるかを判断するステップと、前記自身と同一のサービスがある場合、前記少なくとも一つの連絡先に該当する相手方が前記自身と同一のサービスを使用することを通知するステップと、をさらに含むことを特徴とする請求項4に記載の連絡先を受信する方法。前記連絡先プロフィールリストは、前記ソーシャルネットワークサービスから受信された連絡先プロフィールリストと統合住所録CABXDMSから受信された住所録を比較することにより、フィルタリングされることを特徴とする請求項1に記載の連絡先を受信する方法。メッセージングサービスとソーシャルネットワークサービスSNS間の相互作用を介して連絡先を受信するクライアント端末であって、前記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請し、前記要請に対応する連絡先プロフィールリストのうちで前記サーバによりフィルターされた連絡先プロフィールリストを前記サーバから受信し、前記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認する制御部と、前記サーバとの要請及び応答を送受信するI/Oインターフェースと、前記受信された連絡先プロフィールリストを臨時に格納するメモリと、前記サーバと同期化された住所録を格納する住所録管理部と、ユーザに前記自身と同一のサービスに加入したか否かを知らせるユーザインターフェースと、を含むことを特徴とするクライアント端末。前記連絡先プロフィールリストは、名前、メールアドレス及び電話番号のうち少なくとも一つを含むことを特徴とする請求項8に記載のクライアント端末。前記制御部は、前記受信された連絡先プロフィールリストに前記自身と同一のサービスのアドレスがあるかを判断することを特徴とする請求項8に記載のクライアント端末。前記制御部は、前記判断の結果、前記自身と同一のサービスのアドレスがある場合、前記自身と同一のサービスのアドレスを有する少なくとも一つの連絡先を加入リストに追加することを特徴とする請求項8に記載のクライアント端末。前記制御部は、前記加入リストに追加された前記少なくとも一つの連絡先に該当する相手方が登録したサービスリストをサービス登録サーバに要請し、前記サービス登録サーバから前記サービスリストを受信することを特徴とする請求項11に記載のクライアント端末。前記制御部は、前記サービスリストに前記自身と同一のサービスがあるかを判断し、前記自身と同一のサービスがある場合、前記少なくとも一つの連絡先に該当する相手方が前記自身と同一のサービスを使用することを、ユーザインターフェースを通じて通知することを特徴とする請求項12に記載のクライアント端末。前記連絡先プロフィールリストは、前記ソーシャルネットワークサービスから受信された連絡先プロフィールリストと統合住所録CABXDMSから受信された住所録を比較することにより、フィルタリングされることを特徴とする請求項8に記載のクライアント端末。前記連絡先プロフィールリストに対する前記要請は、前記ソーシャルネットワークに対するフォーマットに変換され前記サーバを通じて前記ソーシャルネットワークサービスに伝送されることを特徴とする請求項8に記載のクライアント端末。本発明の目的は、特定サービスの加入/未加入が決定され得る対象を拡張させることができる、メッセージングサービスとソーシャルネットワークサービス間の相互作用を介した連絡先提供装置及び方法を提供することにある。上記のような目的を達成するために、本発明の一態様によれば、メッセージングサービスとソーシャルネットワークサービスSNS間の相互作用を介してクライアント端末で連絡先を受信する方法を提供する。上記方法は、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請するステップと、上記要請に対応する連絡先プロフィールリストのうちで上記サーバによりフィルターされた連絡先プロフィールリストを上記サーバから受信するステップと、上記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認するステップと、を含むことを特徴とする。本発明の他の態様によれば、メッセージングサービスとソーシャルネットワークサービスSNS間の相互作用を介して連絡先を受信するクライアント端末を提供する。前記端末は、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請し、上記要請に対応する連絡先プロフィールリストのうちで上記サーバによりフィルターされた連絡先プロフィールリストを上記サーバから受信し、上記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認する制御部と、上記サーバとの要請及び応答を送受信するI/Oインターフェースと、上記受信された連絡先プロフィールリストを臨時に格納するメモリと、上記サーバと同期化された住所録を格納する住所録管理部と、ユーザに上記自身と同一のサービスに加入したか否かを知らせるユーザインターフェースと、を含むことを特徴とする。本発明のさらに他の態様によれば、メッセージングサービスとソーシャルネットワークサービスSNS間の相互作用を介してサーバでクライアント端末に連絡先を提供する方法を適用する。上記方法は、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストに対するクライアントの要請事項を受信するステップと、上記受信されたクライアントの要請事項を検討するステップと、上記ソーシャルネットワークサービスに連絡先リスト要請を伝送するステップと、上記伝送に対応して連絡先リストを受信するステップと、上記受信された連絡先リストと既存の連絡先を比較することによって、上記検討した要請事項に対応する連絡先をフィルターするステップと、上記フィルターされた連絡先を提供するステップと、を含むことを特徴とする。本発明の他のさらなる他の態様によれば、メッセージングサービスとソーシャルネットワークサービスSNS間の相互作用を介してクライアント端末に連絡先を提供するサーバであって、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストに対するクライアントの要請事項を受信し、上記受信されたクライアントの要請事項を検討し、上記ソーシャルネットワークサービスSNSに連絡先リストの要請を伝送し、上記伝送に対応して連絡先リストを受信し、上記受信された連絡先リストと既存の連絡先を比較することによって、上記検討した要請事項に対応する連絡先をフィルターし、上記フィルターされた連絡先を提供する制御部と、上記要請に対応する応答を受信するI/Oインターフェースと、を含むことを特徴とする。本発明によれば、拡張された住所録の提供を受けることによって、特定サービスの加入/未加入が決定され得る対象を拡大させることができる利点がある。これによって自身が有している住所録にはないが、自動で新規連絡先の提供を受けることができるので、ユーザは住所録にある既存の友人及び家族だけでなく、本人のプロフィールと関連はあるが、まだ知らない連絡先とも容易に接続できるようになる。またユーザ側面では、特定サービスに新規加入した時、そのサービスをまさに使用するのに便宜性を提供する。さらに例えば、サービスプロバイダーが加入招待メッセージを伝送すれば、関心がないが、ある学校の先輩が本発明で提案するシステムを通じてある後輩アドレスを知るようになって、加入招待メッセージを伝送すると、後輩が加入する可能性がより大きい。このような点を考慮すると、サービスプロバイダー側面では、サービスにまだ加入していないユーザにサービス加入をより容易に誘導でき、サービス加入者数がより速く増加する効果を期待することができる。以下、本発明の好適な実施の形態を添付した図面を参照して詳しく説明する。また、以降の説明では、具体的な特定事項を示しているが、これは、本発明のより全般的な理解を助けるべく提供しただけであって、このような特定事項なしでも本発明が実施できることは、当該技術分野における通常の知識を有する者には自明である。そして、本発明を説明するに際し、関連公知機能あるいは構成についての具体的な説明が、本発明の要旨を不要に曖昧にするおそれがあると判断される場合は、その詳細な説明を省略する。後述する詳細な説明には詳述した技術的課題をなすための本発明において代表的な実施例を提示するはずである。また、本発明の説明の便宜のために、移動端末のアプリケーションの標準機構であるOMA及びGSMAで定義している個体等の名称を使用するが、このような標準及び名称が本発明の範囲を限定するものではなく、類似の技術的背景を有するシステムに適用可能であることはちろんである。本発明は、ソーシャルネットワークサービスサーバ30や他のネットワークから受信したイベントやメッセージを応用クライアントA10に伝達する。SNSインターワーキングサーバ30は、応用サーバ20と担当するSNSプロバイダー40を接続するゲートウェイやツイッターのようなSNSを提供する機関agenciesである。サービス登録サーバ50は、全てのサービスの登録を処理し管理するサーバである。上記のような構成のシステムで、連絡先提供過程を説明するために図2を参照する。図2では、ユーザAの端末、すなわち、応用クライアントA10は、サービスMとSNSサービスにともに加入していることを前提とする。これによって、SNSサービスに接続可能なユーザAのログインとパスワードが存在し、SNSインターワーキングサーバ30は、ユーザAの代わりに、SNSプロバイダー40及び41にログインをした状態であり、接続が可能である。もし、SNSインターワーキングサーバ30がSNSプロバイダー40及び41に直接ログインすることができない場合、ユーザAにまず応用クライアントA10を通じてSNSプロバイダー40及び41にログインするよう要請してログインすることを前提とする。図2を参照すれば、ステップ201で、応用クライアントA10は、応用サーバ20に新規連絡先リストを要請する。このような新規連絡先リストの要請は、ユーザAが応用クライアントA10を実行するか、サービスMに接続するときになされることができる。このような要請は、ユーザAと特性が合う、例えば、他の連絡先がある同じ友人、同じ学校の卒業などに該当する連絡先があるか知るために、該当条件に合う新規連絡先プロフィールリストを要請するためである。ここで、新規連絡先プロフィールには、名前、メールアドレス、電話番号などが含まれる。すると、応用サーバ20は、ステップ203で、その要請をSNSインターワーキングサーバ30に伝達する。これに対応して、SNSインターワーキングサーバ30は、ステップ205a及び205bで、応用サーバ20からの要請に合うように、必要な少なくとも一つの要請事項をSNSプロバイダー40及び41に伝達する。その後、ステップ207a、207bで、SNSプロバイダー40及び41から該当要請に対する応答を受信すると、ステップ209で、SNSインターワーキングサーバ30は、プロフィールリストが受信されたかを判断する。具体的に、SNSインターワーキングサーバ30は、受信された応答が、応用サーバ20が要請した新規連絡先プロフィールリストであるかを判断し、そのリストでなければ、ステップ205a及び205bに戻って、SNSプロバイダー40及び41に必要なその次の要請を伝送し、要請に対する応答で、要請した新規連絡先プロフィールリストを受信した場合、ステップ211に進行する。ステップ209で、SNSインターワーキングサーバ30は、例えば、連絡先IDリストのみを受信し、名前、メールアドレス、電話番号などの具体的なプロフィールに対する受信に失敗した場合には、受信された応答が新規連絡先プロフィールリストでないと判断し、SNSプロバイダー40及び41に要請を再伝送する。このように新規連絡先プロフィールリストを受信すると、ステップ211で、SNSインターワーキングサーバ30は、受信した新規連絡先プロフィールリストを応用サーバ20に伝達する。すると、応用サーバ20は、受信した各連絡先プロフィールからユーザAに有効な連絡先のみをフィルターまたは抽出する。ここで、ユーザAの住所録は、ネットワークにも格納されており、応用サーバ20はその住所録に接続可能である。これによって、応用サーバ20は、連絡先フィルタリングを遂行することができ、これに対する具体的な説明は図4を参照して後述する。その後、応用サーバ20は、ステップ215で、フィルターされた連絡先リストを応用クライアントA10に送る。ステップ217で、応用クライアントA10は、受信された連絡先ごとにサービスMに加入したかを確認し、確認結果をユーザに知らせる。このような連絡先がサービスに加入したかを確認する過程及び確認結果をユーザに知らせる過程に対する具体的な説明は、図6を参照して後述する。以後、どの連絡先がサービスMに加入したかを確認するために、応用クライアントA10は、ステップ217aでサービス登録サーバ50に連絡先登録サービスリストを要請すると、ステップ217bでサービス登録サーバ50は連絡先に対応して登録されたサービスリストを応用クライアントA10に送る。これによってユーザAは既に接続したSNSの友人や、そのユーザと特性が合うSNSの連絡先の提供を受けることができ、その連絡先がサービスMに加入しているという事実と、その連絡先とサービスを通じて接続可能な方法も提供を受けることができる。さらに、提供された連絡先がサービスMに加入していないか、加入/未加入が分からない場合、連絡先に対する情報のみが提供されても、ユーザAは、必要によってその連絡先に該当する相手方クライアントに、サービスMに対する加入招待メッセージを送ることもできる。以下、連絡先に対するフィルターを遂行する応用サーバの動作を説明する前に、その内部構成を、図3を参照して説明する。図3は、応用サーバ20の内部ブロック構成を示す図である。図3を参照すると、制御部301は、応用サーバ20のすべての動作を制御し、他の内部構成要素と連結cooperationして、どの時点に何を遂行すべきであるかを知らせる。I/Oインターフェース303は、他のシステム要素と情報を交換する時に使用され、メモリ305は、応用サーバ20がすべての動作を遂行する時に処理データが臨時に格納されるストレージである。住所録管理部307は、ユーザの既存連絡先情報を格納し、応用クライアント10で使用される住所録管理部507と同期化された住所録を格納する。マッピングテーブル管理部309は、メールアドレスや電話番号のような既存アドレス/番号をサービスMで使用される特定アドレス、例えば、SIPURIに変換する。このような住所録管理部307及びマッピングテーブル管理部309は、本発明で提案する実施形態によって、応用サーバ20から分離され具現され得る。上述したように構成された応用サーバ20は、図4のような連絡先に対するフィルターを遂行する。このような連絡先フィルタリングは、応用サーバ20の制御部301の制御下で遂行される。図4を参照すれば、ステップ401で、制御部301は、I/Oインターフェース303を通じて受信した連絡先プロフィールリストをメモリ305に格納する。ステップ403で、制御部301は、メモリ305に格納されたプロフィールから、連絡先識別可能なデータ、例えば、名前、メールアドレス、電話番号などを抽出する。ステップ405で、制御部301は、抽出されたデータと住所録管理部307にある該当データとを比較し、抽出されたデータが住所録に既に存在する連絡先であるかを判断する。判断の結果、抽出されたデータが住所録に存在する連絡先に該当する場合、ステップ407で、サービスMに既に加入しているかを判断する。具体的に、制御部301は、その存在する連絡先に対してサービスMに加入していることを示す表示indicatorが住所録管理部307にあるかを判断する。サービスMに既に加入していると判断されると、制御部301は、ステップ409でプロフィールを削除する。この時、サービスMに既に加入していると判断されると、その連絡先がサービスMに加入しているという事実をユーザAも既に知っているという意味である。したがって、この連絡先に対してはこれ以上進行する必要がないので、連絡先に対するプロフィールをメモリ305から削除するものである。ステップ405で抽出されたデータがその住所録に存在する連絡先ではないか、ステップ407でサービスに既に加入した場合でなければ、ステップ411で、制御部300は、サービスMで使用可能なアドレスがあるかを確認する。具体的に、住所録管理部307にその連絡先に対応してサービスMで使用可能なアドレス以下、サービスMアドレスと称するがあるかを確認する。したがって、抽出されたデータが住所録管理部307に存在する連絡先ではないか、サービスMアドレス、例えば、SIPURIがない場合、マッピングテーブル管理部309に接続して、ステップ403で抽出された連絡先のメールアドレスや電話番号にマッチングされるサービスMアドレスがあるか否かを確認する。例えば、RCSサービスの場合、SIPURIアドレスが使用可能であるが、いろいろなサービスがSIPURIアドレスを使用するために、SIPURIアドレスがあるとしても、連絡先が必ずRCSサービスに加入したということではない。したがって、下記のような方法を通じてサービスMアドレスがあるか否かを確認することができ、その方法は状況によって選択的に使用される。その方法を説明すれば、次のようである。マッピングテーブル管理部309にマッチングされる連絡先のサービスMアドレスがないが、連絡先に該当する相手方クライアントが他のネットワーク加入者であるので、他のネットワークにあるサーバが知る可能性のある場合、制御部301は、I/Oインターフェース303を通じて他のネットワークサーバに連絡先のプロフィールを伝達し、マッチングされるサービスMアドレスを要請することができる。他のネットワークサーバからI/Oインターフェース303を通じて応答を受信し、受信された応答にマッチングされるサービスMアドレスが含まれている場合、制御部301は、サービスMアドレスを連絡先のメールアドレス及び電話番号とともにマッピングテーブル管理部309に追加する。上記の方法により、連絡先のサービスMアドレスが存在する場合、制御部301は、連絡先に該当する相手方クライアントがサービスMに加入する可能性があるので、ステップ413で連絡先プロフィールにサービスMアドレスを追加する。これとは異なり、連絡先のサービスMアドレスが存在しないか、分からない場合、ステップ415に進行して検討すべき連絡先プロフィールがもっとあるかを判断し、検討すべき連絡先がもっとある場合、ステップ403に戻って上述した過程を反復遂行し、これ以上検討すべき連絡先がない場合、連絡先フィルタリング動作を終了する。一方、連絡先がサービスに加入したか否かを確認する過程及び確認結果をユーザに知らせる動作を遂行する応用クライアントAの動作を説明する前に、応用クライアントA10の内部構成について図5を参照して説明する。図5を参照すれば、制御部501は、応用クライアントA10のすべての動作を制御する要素として、他の内部構成要素と連結して、どの時点に何を遂行しなければならないかを知らせる役割をする。I/Oインターフェース503は、他のシステム要素と情報を交換する時に使用されるインターフェースである。メモリ505は、応用クライアントA10がすべての動作を遂行する時に処理データが臨時に格納されるストレージである。住所録管理部507は、ユーザの既存連絡先情報を格納するストレージとして、応用サーバ20で使用される住所録管理部307と同期化されている。ユーザインターフェース509は、ユーザのすべての情報を見せる時やユーザが情報を入力する時に使用されるインターフェースである。上述したように構成された応用クライアントA10は、図6のような連絡先が特定サービスに加入したか否かを確認する過程及び確認過程をユーザに知らせる過程を遂行する。このような動作は、応用クライアントA10の制御部501の制御下で遂行される。図6を参照すれば、制御部501は、ステップ601で、I/Oインターフェース503を通じて受信したフィルターされた連絡先プロフィールリストをメモリ505に格納する。ステップ603で、メモリ505に格納された連絡先プロフィールでサービスMアドレスがあるかを確認する。判断の結果、サービスMアドレスがある場合、連絡先がサービスMに加入する可能性があるので、制御部501は、ステップ605で連絡先プロフィールを加入リストに追加した後、メモリ505に格納する。これとは異なり、サービスMアドレスがない場合、その連絡先がサービスMに加入する可能性がないか、分からない。したがって、制御部501は、連絡先プロフィールを未加入リストに追加し、メモリ505に格納する。ステップ609で、受信されたリストに検討するプロフィールがもっとあるかを判断し、検討するプロフィールがもっとある場合、ステップ603に戻って上述した過程を反復遂行し、検討するプロフィールがこれ以上ない場合、ステップ611に進行する。ステップ611で、制御部501は、メモリ505に格納された加入リストにある連絡先をI/Oインターフェース503を通じてサービス登録サーバ50に伝送し、各連絡先の登録されたサービス加入リストを要請する。このような要請に対応してステップ613でI/Oインターフェース503を通じてサービス登録サーバ50から、各連絡先に対応して登録されているサービスリストを受信する。すなわち、制御部501は、連絡先に該当する各相手方クライアントが登録したサービスに対するリストを受信する。ステップ615で、制御部501は、連絡先サービスリストにサービスMがあるかを確認する。もし、サービスMがない場合、ステップ617で連絡先がサービスMに加入していないので、メモリ505に格納された連絡先を加入リストから未加入リストに移動させる。ステップ619で受信された連絡先プロフィールリストに検討するプロフィールがもっとあるかを判断し、検討するプロフィールがもっとある場合、制御部501は、ステップ615に戻って上記過程を反復遂行する。これとは異なり、検討するプロフィールがこれ以上ない場合、ステップ621でメモリ505に格納された加入リストと未加入リスト連絡先を、ユーザインターフェース509を通じてユーザAに知らせる。ここで、加入リスト連絡先の場合、応用クライアントA10は、該当連絡先が同じサービスMを使用するという事実をユーザAに知らせ、住所録管理部507に連絡先を追加する方法と、サービスMを通じてその連絡先と接続できる方法を提供する。未加入リスト連絡先の場合、応用クライアントA10は、該当連絡先が存在するという事実をユーザAに知らせ、住所録管理部507に連絡先を追加する方法と、その連絡先にサービスMへの加入招待メッセージを送ることができる方法を提供する。以下、応用クライアントA10のユーザが加入したサービスMがRCSサービスと仮定した場合、そのRCSサービスは複数のイネイブラーを用いてサービスを提供する。本発明の実施形態では、このようなRCSサービスをSNSサービスと連動させることによって、サービスの加入/未加入が決定され得る対象を拡張させることができる。このようなRCSサービスは、住所録統合機能を提供するイネイブラーの一例であるOMAを基に提供され得る。これによって、図2での応用クライアントA10は、新規連絡先を受信するためにCABクライアントとして動作でき、受信された新規連絡先に相当するクライアントのサービスの加入/未加入を受信するためにプレゼンスクライアントとしても動作できる。したがって、本発明にともなうSNSサービスとの連動を通じた連絡先提供システムは、OMACABとOMAプレゼンスイネイブラーを基盤で具現され得る。上記のような本発明を説明する前に、本発明で使用される一般的なCABシステムの構成について図7を参照して説明する。図7を参照すれば、CABクライアント71は、ユーザ端末機にある住所録を管理及び制御する応用プログラムである。CABサーバ72は、CABクライアント71から受信したユーザの多様な要請事項を遂行するネットワーク主要要素である。CABABXDMS73は、ユーザの住所録を格納及び管理するサーバである。CABPCCXDMS74は、ユーザのプロフィールを格納及び管理するサーバである。CABUPXDMS75は、ユーザの選好度及び特定要請事項を格納及び管理するサーバである。NonCAB住所録システム76は、CABサービスで使用する住所録システムと他のすべての住所録システムを含み、例えば、vCardなどがこれに該当する。本発明では、図2に説明したSNSプロバイダー40及び41もNonCAB住所録システム76に含まれると仮定し得る。本発明で使用されるインターフェースとプロトコル/技術は、次のようである。CAB-1インターフェースは、CABサーバ72を経てCABクライアント71にある住所録とCABABXDMS73に格納された住所録間の同期化のために使用される。また、CAB-1インターフェースは、CABサーバ72がCABクライアント71に二つの住所録間に差異を通知するときに使用される。プロトコル/技術としてSyncML[3]が使用される。SIC-1インターフェースは、CABPCCXDMS74とCABUPXDMS75に格納されたデータが変更されるごとに、CABクライアント71に変更事項を知らせる時に使用される。参考までに、CABABXDMS73変更事項通知はCAB-1インターフェースが使用される。プロトコル/技術としてはSIPSpecificEventNotification[4]が使用される。SIC-2インターフェースは、CABABXDMS73、CABPCCXDMS74とCABUPXDMS75に格納されたデータが変更されるごとに、CABサーバ71に変更事項を知らせる時に使用される。プロトコル/技術としてはSIPSpecificEventNotification[4]が使用される。XDM-3iインターフェースは、CABクライアント71がCABPCCXDMS74とCABUPXDMS75に格納されたデータを管理する時に使用される。プロトコル/技術としてはXCAP/HTTP[5]が使用される。XDM-4iインターフェースは、CABサーバ72がCABABXDMS73、CABPCCXDMS74、及びCABUPXDMS75に格納されたデータを管理する時に使用される。プロトコル/技術としてはXCAP/HTTP[5]が使用される。また、本発明で使用される一般的なプレゼンスイネイブラーでの動作フローは、図8のようである。OMAプレゼンスイネイブラーは、ユーザが他のユーザが使用するサービスに対して決定しようとする時も、図8のような動作を遂行する。その動作流れは、SIPSpecificEventNotification[4]プロトコルを用いて遂行される。図8を参照すれば、プレゼンスクライアント81はフェッチャとして、他のユーザがプレゼンスサーバ84に登録したプレゼンス情報を受信するために、ステップ801でSIPSUBSCRIBEを送る。この時、プレゼンス情報を一度だけ受信するために、SIPSUBSCRIBEのうちにExpiresヘッダーを0で設定する。これとは異なり、周期的に変更事項を受信するためには、Expiresヘッダーをより高い値で設定する。SIPSUBSCRIBEは、ステップ803及び805で、SIP基盤の下部伝送ネットワークに該当するフェッチャFetcherSIP/IPCore82と、プレゼンスサーバ84側にあるPresentitySIP/IPCore83を経てプレゼンスサーバ84に伝達される。ステップ807でプレゼンスサーバ84は、プレゼンスクライアント81が要請した情報を受信することを許諾したか否かを判断するために、認証チェックを遂行する。もし要請を許諾する場合、ステップ809乃至813で、プレゼンスサーバ84は、200OKをSIP/IPCores82及び83を経てプレゼンスクライアントに伝達する。その後、ステップ815乃至819で、プレゼンスサーバ84は、要請した情報をSIPNOTIFYを用いてSIP/IPCores82及び83を経てプレゼンスクライアント81に伝達する。これに対応してステップ821乃至825で、プレゼンスクライアント81は、200OKを用いてプレゼンス情報の受信確認ACKをSIP/IPCores82及び83を経てプレゼンスサーバ84に伝達する。以下、本発明の実施形態による図2の動作の流れを、上記のような図7及び図8を基盤で再構成した場合を具体的に説明する。本発明の実施形態によって、図7及び図8を基盤で再構成されたRCSサービスとSNSサービスと連動するシステムの構成は、図9A乃至図13Bのように具現され得る。ここで、図9B、図10B、図11B、図12B、図13Bは、各々図9A、図10B、図11B、図12B、図13Bにつながるフロー図である。図9A及び図9Bは、本発明の第1実施形態による連絡先提供過程を示したフロー図である。図9A及び図9Bでは、図2の応用サーバ20とSNSインターワーキングサーバ30が統合され具現された場合を示し、説明の便宜のためにルーティング及びその他の目的のための要素ら、例えば、SIP/IPCores、IMS、AggregationProxy等は省略されているが、必要によってその過程を遂行すると仮定し得る。以下の図面では、図2のRCSサービスがCABサービスの構成を基で再構成されたことであるので、RCS関連用語はCABで使用される用語で代替でき、説明の便宜のためにRCSとCABを並行して表記する。同様に、図2のSNSもNonRCSと並行して表記できる。図9Aを参照すれば、ユーザAがRCSサービスに接続する時、RCSクライアントA71は、新規連絡先提案リストを受信するために、要請に対する詳細な情報をCABUPXDMS75が管理するCABFeatureHandlerという文書に格納するように要請する。このためにステップ901で、GetContactsuggestions要請がXCAP/HTTPPUT形態でCABXDMSのうちCABUPXDMS75に伝達される。CABFeatureHandler文書に対する詳細説明は後述する。ステップ903でCABUPXDMS75は、管理するCABFeatureHandler文書に要請事項を格納し、格納完了応答である200OKをRCSクライアントA71に送る。ステップ905で、CABUPXDMS75はCABFeatureHandler文書に格納されたRCSクライアントA71の要請事項と関連情報をRCSサーバ72に通知する。このような通知のために、SIPNOTIFYメッセージが使用される。ステップ907で通知を受信すると、RCSサーバ72は、確認メッセージである200OKをCABUPXDMS75に送る。ステップ909でRCSサーバ72は、要請事項を検討してNonRCS住所録システム76に適合したフォーマットに変換し、NonRCS連絡先リストをRCS住所録システム76に要請する。ここで、NonRCS住所録システムは、SNSプロバイダーに該当する。図9A及び図9Bでは一つのSNSプロバイダーに該当するNonRCS住所録システムを例示したが、SNSプロバイダーが複数の場合、その複数のSNSプロバイダーから連絡先リストを受信してRCSサーバ72で結合することができることはもちろんである。ステップ911で、NonRCS住所録システム76は、要請したNonRCS連絡先リストをRCSサーバ72に送る。この時、必要なリストを正確に受信するために、ステップ909とステップ911が反復遂行され得る。ステップ913でRCSサーバ72は、受信されたNonCAB連絡先リストをRCSフォーマットに変換する。ステップ915でRCSサーバ72はネットワークに格納されたユーザAの既存住所録をCABABXDMS73に要請する。このような要請のためにXCAP/HTTPGETが使用され得る。これに対応してステップ917でCABABXDMS73は、要請したユーザAの住所録を含む200OKをRCSサーバ72に送る。ここで、RCSサーバ72は、図2の応用サーバ20とSNSインターワーキングサーバ30の機能を遂行する。これによってRCSサーバ72は、ステップ919でユーザAの既存連絡先とNonRCS住所録システム76から受信した新規連絡先プロフィールを比較することによって、連絡先をフィルターする。このような連絡先フィルタリングに対する動作は、上述した図4によって遂行される。このようにフィルターされた連絡先は、ステップ921でCABUPXDMS75に格納され、このような格納要請のために、XCAP/HTTPPUTが使用される。ステップ923でCABUPXDMS75は、受信した連絡先プロフィールを格納して確認応答として200OKをRCSサーバ72に送る。ステップ925で、CABUPXDMS75は新規連絡先プロフィールが格納されているという事実をRCSクライアントA71に通知し、プロフィールを送る。このようなプロフィールを送るためにSIPNOTIFYメッセージが使用される。このような受信されたプロフィールは、RCSクライアントA71がステップ901で伝送した要請に対する応答である。ステップ927でRCSクライアントA71は、受信したSIPNOTIFYに対する確認メッセージをCABUPXDMS75に送る。このようにRCSクライアントA71立場では、NonRCSプロバイダー、すなわち、SNSプロバイダーとの連動を介して特定サービスの加入/未加入が決定され得る対象を拡張させることができる。このためにステップ929で、RCSクライアントA71は、受信したプロフィールからSIPアドレスがある連絡先を抽出する。具体的に、上述した図6によって、受信した連絡先プロフィールのうち、RCSサービスに使用可能なアドレス、すなわち、SIPURIがあるかを確認し、その連絡先を抽出する。ステップ931でRCSクライアントA71は、SIP連絡先アドレスを基で、RCSクライアントA71を通じて使用可能なサービスリストを示す各SIP連絡先のservicecapabilityinformationをRCSサーバ84に要請する。このような要請のためにSIPSUBSCRIBEメッセージが使用される。ここで、RCSクライアントA71とRCSクライアントA71は、図2の応用クライアントA10に該当し、同じユーザ端末機に設置された応用プログラムである。ただし、本発明では連絡先を要請する場合には、RCSクライアントとして動作するので、RCSクライアントA71と呼び、サービスの加入/未加入を要請する場合には、RCSクライアントとして動作するので、RCSクライアントA71とも呼ぶ。RCSサーバ84は、RCSクライアントA71が要請した情報を受信することを許諾するかを判断するために、認証チェッククライアントに伝達する。ステップ935でRCSサーバ84は要請した連絡先のservicecapabilityinformationをRCSクライアントA71にSIPNOTIFYメッセージを用いて伝達する。このようなメッセージを受信したRCSクライアントA71は、ステップ937でservicecapabilityinformationの受信確認である200OKをRCSサーバ84に伝達する。その後、ステップ939でRCSクライアントA71は、RCSクライアントA71を通じて各連絡先のservicecapability情報を、図6のステップ615乃至621によってRCSユーザであるか否かを検討してユーザに知らせる。上述したように、本発明の第1実施形態ではRCSサーバ72がフィルタリング機能及びインターワーキング機能をともに遂行し、フィルターされた連絡先が別途にCABUPXDMS75で管理するCABFeatureHandlerという文書に格納される場合を例に挙げて説明した。しかしながら、他にはフィルターされた連絡先はCABFeatureHandler文書でないRCSCABクライアントA71が有している住所録に含まれて格納されることができ、このような本発明の第2実施形態による構成は、図10A及び図10Bに示したようである。本発明の第2実施形態を説明する前に、CABFeatureHandlerという文書の詳細内容を説明する。本発明では、というエレメントを定義する。エレメントは、RCSクライアントA71が新規連絡先提案リストを受信しようとする時、CABFeatureHandler文書に含まれるエレメントである。このようなエレメントの下位レベルは、、、、、、、、、などのエレメントなどで構成される。は、どの機関から新規連絡先提案を受信したいかを記載するためのエレメントとして、例えば、domainnameが記載される。このエレメントがない場合、サービスプロバイダーのポリシーpolicyにしたがって決定される。は、該当機関に接続する時に認証のために必要な情報を意味する。の下位レベルには、ログイン情報が記載されるとパスワードが記載されるなどのエレメントが属している。は、またはで代替でき、新規連絡先提案を何の基準で選択するかを設定するために使用される。このエレメントの下位レベルには、、、、などのエレメントが含まれる。まず、はとも言え、RCSCABクライアントAが該当機関にあるユーザ住所録の登録された連絡先を受信したい時、例えば、ユーザの友人の友人等の連絡先を受けたい時、1で設定される。には、同じ学校に通った連絡先提案を受けたい時、該当学校名が記載される。には、同じ職業を有している連絡先提案を受けたい時、該当会社や職業種類が記載される。には、同じ趣味を有している連絡先提案を受けたい時、該当趣味が記載される。上記の下位エレメントは、例題であるだけで、エレメントに所望するキーワードを直接入力することもできる。またも記載しない場合、RCSサーバ72がユーザプロフィールに接続し、ユーザプロフィールとサービスプロバイダーのポリシーにしたがって決定されることができる。には、RCSCABクライアントA71が一度だけでなく、周期的に連絡先提案を受信することを所望する時、提案時間間隔が記載される。には、RCSCABクライアントA71が提案を受けようとする最大連絡先数を設定する。は、各要請を識別するIDである。上述したエレメントは、の属する下位レベルエレメントである。エレメントの下位レベルには、というエレメントも含まれる。エレメントは、上述したステップ921でのようにRCSサーバ72がRCSクライアントA71が要請に応答する時に満たすエレメントである。エレメントの下位レベルは、次のエレメントを含む。は、応答に対する状態コードであり、応答が成功的に実行されたか、失敗したかを示す該当状態コードが記載される。は、応答に対するhighlevel文章である。には、上述した要請関連詳細応答が記載される。ここで、新規連絡先提案情報が載せており、各連絡先に対する詳細な情報構造はOMACABで定義した構造に従う。本発明の第1実施形態では、が新規連絡先提案要請情報と同一の文書に入っていると仮定するが、他の文書に別に記載されることもできる。一方、本発明の第2実施形態では、RCSクライアントA71が有している住所録にフィルターされた連絡先が含まれて格納される場合を説明し、このために図10A及び図10Bを参照する。図10Aのステップ1001乃至1019は、図9Aのステップ901乃至919での動作と同一である。ただし、本発明の第2実施形態ではCABABXDMS73にフィルターされた連絡先が格納される。これによってステップ1021でRCSサーバ72は、フィルターされた連絡先をCABABXDMS73に格納するように要請する。このような要請のために、XCAP/HTTPPUTが使用される。この時、フィルターされた連絡先は、ユーザ住所録に直接格納されることもでき、他の別途の文書に格納されることもできる。ステップ1023で、CABABXDMS73は、受信した連絡先プロフィールを格納し、確認応答である200OKをRCSサーバ76に送る。ステップ1025で、RCSサーバ72は住所録の変更をRCSクライアントA71に通知する。このような通知のために、OMADSが使用される。図10Bのステップ1027で、RCSクライアントA71は、住所録同期化をRCSサーバ72と実施し、同期化を通じて新規提案連絡先を共に受信する。以下、図10Bのステップ1029乃至1039は、図9Bのステップ929乃至939での動作と同一である。ただ、住所録に直接格納された場合、連絡先がRCSサービスの使用/非使用によって、またユーザ指向及び選択によって、追加された連絡先提案を住所録で削除できる。一方、本発明の第3実施形態は、本発明の第2実施形態での連絡先フィルタリングステップ及びフィルターされた連絡先リストをCABUPXDMS75に格納するステップを、RCSサーバ72でなく、CABABXDMS73が遂行する場合に関することである。本発明の第3実施形態を説明するために図11A及び図11Bを参照する。図11Aのステップ1101乃至1113は、図9Aのステップ901乃至913での動作と同一である。ただし、CABABXDMS73は連絡先をフィルターし、CABUPXDMS75に格納する動作を遂行する。これによってステップ1115で、RCSサーバ72は、変換された連絡先をCABABXDMS73に格納するように要請し、このような要請のためにXCAP/HTTPPUTが使用される。ステップ1117で、CABABXDMS73は、受信した連絡先プロフィールを格納し、確認応答で200OKをRCSサーバ72に送る。ステップ1119で、CABABXDMS73は、図4で説明した動作に従ってユーザAの既存連絡先とRCSサーバ72から受信した新規連絡先プロフィールを比較することによって、連絡先をフィルターする。ステップ1121で、CABABXDMS73は、フィルターされた連絡先をCABUPXDMS75に格納する。この時、フィルターされた連絡先の格納動作は、CABXDMS内部要素間に遂行される動作であるから、別途のプロトコルや受信確認メッセージを使用しない。上述した内容以外の図11A及び図11Bでのステップ1125乃至1139は、図9A及び図9Bのステップ925乃至939での動作と同一である。一方、本発明の第4実施形態は、本発明の第1実施形態での連絡先フィルタリングステップとSIP連絡先抽出及びservicecapabilityinformation要請ステップをRCSサーバ72が予め共に全部遂行する場合に関する。本発明の第4実施形態を説明するために図12A及び図12Bを参照する。これによって、図12Aのステップ1201乃至1219は、図9Aのステップ901乃至919での動作と同一である。また、図12Aのステップ1221乃至図12Bのステップ1229は、図9Bのステップ929乃至937での動作と同一であるが、この動作をRCSクライアント81でなく、RCSサーバ72が遂行する。したがって、プレゼンスクライアントA81の役割をするプレゼンス機能がRCSサーバ72内部に含まれたと仮定する。また、図12Bのステップ1231乃至1237は、図9Aのステップ921乃至927での動作と同一である。ただし、ステップ1231で格納する提案連絡先プロフィールには、ステップ1231乃至1237の結果によって各連絡先のRCSサービスの加入/未加入に対する表示が含まれている。そしてステップ1239で、RCSクライアント71は、受信した連絡先情報を別に分析する必要なくユーザに提案する。一方、上述した本発明の第4実施形態では、すべての分析及びフィルター過程をRCSサーバ72が予め全部遂行する場合を例に挙げて説明したが、本発明の第5実施形態では、反対にRCSサーバ72が予め遂行する代わりに、後でRCSクライアント71が全部遂行するように具現することができる。このような本発明の第5実施形態を図13A及び図13Bを参照して説明する。図13Aのステップ1301乃至1313は、図9Aのステップ901乃至913での動作と同一である。また、ステップ1315乃至1321も図9Aのステップ921乃至927での動作と同一であるが、図9Aのステップ921で格納される連絡先は、RCSフォーマットに変換されたが、ステップ1315ではまだ追加分析及びフィルターされない状態でCABUPXDMS75に格納される。また図13Bのステップ1323は、図9Aのステップ919での動作と同一であるが、その動作をRCSサーバ72が遂行することでなく、RCSクライアント71が内部にある住所録管理部507にある連絡先と比較することによってフィルターを遂行する。以下、図13Bのステップ1325乃至1335は、図9Bのステップ929乃至939での動作と同一である。以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。