(57)【要約】  本発明はソーシャルネットワークサービス(Social Network Service:以下、“ＳＮＳ”と称する）との相互作用を介した連絡先提供方法を提案する。このために本発明は、ＳＮＳとの連動を介して他のサービスを使用するクライアントでそのＳＮＳで提供する連絡先を受信するステップと、受信された連絡先にそのクライアントと同じサービスに加入した相手方クライアントがあるかを判断し、判断結果を通知するステップとからなる。これによって、他のサービスを使用するクライアントは、判断結果に基づいて所望の相手方クライアントのサービスの加入／未加入を決定することができ、その相手方クライアントが自身と同一のサービスに加入していない場合、そのサービスへの招待を要請することができる。このようにすることによって、特定サービスの加入／未加入が決定され得る対象を拡張させることができる。
2013521562.tif 000002
【特許請求の範囲】
【請求項１】
メッセージングサービスとソーシャルネットワークサービス(ＳＮＳ）間の相互作用を介してクライアント端末で連絡先を受信する方法であって、
前記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請するステップと、
前記要請に対応する連絡先プロフィールリストのうちで前記サーバによりフィルターされた連絡先プロフィールリストを前記サーバから受信するステップと、
前記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認するステップと、を含むことを特徴とする連絡先を受信する方法。
【請求項２】
前記連絡先プロフィールリストは、
名前、メールアドレス及び電話番号のうち少なくとも一つを含むことを特徴とする請求項１に記載の連絡先を受信する方法。
【請求項３】
前記確認するステップは、
前記受信された連絡先プロフィールリストに前記自身と同一のサービスのアドレスがあるかを判断するステップであることを特徴とする請求項１に記載の連絡先を受信する方法。
【請求項４】
前記判断の結果、前記自身と同一のサービスのアドレスがある場合、前記自身と同一のサービスのアドレスを有する少なくとも一つの連絡先を加入リストに追加するステップをさらに含むことを特徴とする請求項３に記載の連絡先を受信する方法。
【請求項５】
前記加入リストに追加された前記少なくとも一つの連絡先に該当する相手方が登録したサービスリストをサービス登録サーバに要請するステップと、
前記サービス登録サーバから前記サービスリストを受信するステップと、をさらに含むことを特徴とする請求項４に記載の連絡先を受信する方法。
【請求項６】
前記サービスリストに前記自身と同一のサービスがあるかを判断するステップと、
前記自身と同一のサービスがある場合、前記少なくとも一つの連絡先に該当する相手方が前記自身と同一のサービスを使用することを通知するステップと、をさらに含むことを特徴とする請求項４に記載の連絡先を受信する方法。
【請求項７】
前記連絡先プロフィールリストは、前記ソーシャルネットワークサービスから受信された連絡先プロフィールリストと統合住所録（ＣＡＢ）ＸＤＭＳから受信された住所録を比較することにより、フィルタリングされることを特徴とする請求項１に記載の連絡先を受信する方法。
【請求項８】
メッセージングサービスとソーシャルネットワークサービス(ＳＮＳ）間の相互作用を介して連絡先を受信するクライアント端末であって、
前記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請し、前記要請に対応する連絡先プロフィールリストのうちで前記サーバによりフィルターされた連絡先プロフィールリストを前記サーバから受信し、前記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認する制御部と、
前記サーバとの要請及び応答を送受信するＩ／Ｏインターフェースと、
前記受信された連絡先プロフィールリストを臨時に格納するメモリと、
前記サーバと同期化された住所録を格納する住所録管理部と、
ユーザに前記自身と同一のサービスに加入したか否かを知らせるユーザインターフェースと、を含むことを特徴とするクライアント端末。
【請求項９】
前記連絡先プロフィールリストは、
名前、メールアドレス及び電話番号のうち少なくとも一つを含むことを特徴とする請求項８に記載のクライアント端末。
【請求項１０】
前記制御部は、前記受信された連絡先プロフィールリストに前記自身と同一のサービスのアドレスがあるかを判断することを特徴とする請求項８に記載のクライアント端末。
【請求項１１】
前記制御部は、
前記判断の結果、前記自身と同一のサービスのアドレスがある場合、前記自身と同一のサービスのアドレスを有する少なくとも一つの連絡先を加入リストに追加することを特徴とする請求項８に記載のクライアント端末。
【請求項１２】
前記制御部は、
前記加入リストに追加された前記少なくとも一つの連絡先に該当する相手方が登録したサービスリストをサービス登録サーバに要請し、前記サービス登録サーバから前記サービスリストを受信することを特徴とする請求項１１に記載のクライアント端末。
【請求項１３】
前記制御部は、
前記サービスリストに前記自身と同一のサービスがあるかを判断し、前記自身と同一のサービスがある場合、前記少なくとも一つの連絡先に該当する相手方が前記自身と同一のサービスを使用することを、ユーザインターフェースを通じて通知することを特徴とする請求項１２に記載のクライアント端末。
【請求項１４】
前記連絡先プロフィールリストは、前記ソーシャルネットワークサービスから受信された連絡先プロフィールリストと統合住所録（ＣＡＢ）ＸＤＭＳから受信された住所録を比較することにより、フィルタリングされることを特徴とする請求項８に記載のクライアント端末。
【請求項１５】
前記連絡先プロフィールリストに対する前記要請は、前記ソーシャルネットワークに対するフォーマットに変換され前記サーバを通じて前記ソーシャルネットワークサービスに伝送されることを特徴とする請求項８に記載のクライアント端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメッセージングサービス装置及び方法に関し、特にメッセージングサービスとソーシャルネットワークサービス間の相互作用を介した連絡先提供装置及び方法に関する。
【背景技術】
【０００２】
移動通信端末は、いつどこでも必要な情報を供給し、交換できる手段として、既存には単純に電話などを通じた通話が大部分であったが、順次移動通信端末の普及が普遍化されるにつれて、テキスト及びマルチメディアを通じた対話や情報交換側面がより一層重要視されている。これに対応して、ＳＭＳ(Short Message Service)、ＭＭＳ(Multimedia Messaging Service)、ＭＳＮ(MicroSoft Network)のような多様なメッセージングサービスと、フェイスブック(Facebook)、ツイッター(Twitter)のような多様なソーシャルネットワーク(Social Network)サービスが提供されている。
【０００３】
このような多様なサービスは、相異なる技術を基盤で提供されているが、ユーザ側面では、たとえ異なるサービスを使用しても、重複する機能とユーザ経験(user experience）の提供を受けるようになる。さらに、各サービスごとに他のサービスと区別される特徴もあるために、すべての特徴を体験するためには、ユーザが各サービスに加入しなければならない負担もある。
【０００４】
このようなユーザの負担感を最少化するために、多様なユーザ経験を統合する新規サービスが導入され標準化されている。代表的な場合として、ＯＭＡ(Open Mobile Alliance)で標準したＯＭＡ ＣＰＭ(Converged IP Messaging）と、ＧＳＭＡ ＲＣＳ(Global System for Mobile communication Association Rich Communication Suite)が挙げられる。また、このようなメッセージングサービスの場合、そのサービスごとに相異なる住所録を使用するので、このような住所録管理に対する必要性が台頭された。このような必要性によって、ＯＭＡではＯＭＡ ＣＡＢ(ＯＭＡ Converged Address Book)を提案した。このＯＭＡ ＣＡＢは、向上したネットワーク住所録で多様な情報をネットワークストレージを活用して管理し、グループ間の情報共有が可能な特徴を有している。
【０００５】
上述したように、新しく導入されたサービスのうち、既存メッセージングサービスの場合、ユーザが特定のサービスに加入したとしても、そのサービスまたは互換可能な他のサービスに相手方が加入していないと、そのサービスを通じた対話及び情報交換が難しい実情である。これを勘案してＲＣＳサービスでは住所録管理機能を提供し、ＲＣＳサービスの加入／未加入を通知する機能を提供できる。しかしながら、ＲＣＳサービスも他のサービスと住所録を共有しないので、ＲＣＳサービスの加入／未加入がそのＲＣＳサービスで使用する住所録のみに提供されるだけである。したがって、メッセージングサービスは、ソーシャルネットワークサービスと連動（interwork）すれば、サービスの加入／未加入が決定され得る対象を拡張させることができる、拡張された住所録の提供を受けることができる。これによって、特定サービスの加入／未加入が決定され得る対象を拡張できる方法が要求されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、特定サービスの加入／未加入が決定され得る対象を拡張させることができる、メッセージングサービスとソーシャルネットワークサービス間の相互作用を介した連絡先提供装置及び方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記のような目的を達成するために、本発明の一態様によれば、メッセージングサービスとソーシャルネットワークサービス(ＳＮＳ）間の相互作用を介してクライアント端末で連絡先を受信する方法を提供する。上記方法は、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請するステップと、上記要請に対応する連絡先プロフィールリストのうちで上記サーバによりフィルターされた連絡先プロフィールリストを上記サーバから受信するステップと、上記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認するステップと、を含むことを特徴とする。
【０００８】
本発明の他の態様によれば、メッセージングサービスとソーシャルネットワークサービス(ＳＮＳ）間の相互作用を介して連絡先を受信するクライアント端末を提供する。前記端末は、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストをサーバに要請し、上記要請に対応する連絡先プロフィールリストのうちで上記サーバによりフィルターされた連絡先プロフィールリストを上記サーバから受信し、上記受信された連絡先プロフィールリストの連絡先ごとに自身と同一のサービスに加入したか否かを確認する制御部と、上記サーバとの要請及び応答を送受信するＩ／Ｏインターフェースと、上記受信された連絡先プロフィールリストを臨時に格納するメモリと、上記サーバと同期化された住所録を格納する住所録管理部と、ユーザに上記自身と同一のサービスに加入したか否かを知らせるユーザインターフェースと、を含むことを特徴とする。
【０００９】
本発明のさらに他の態様によれば、メッセージングサービスとソーシャルネットワークサービス(ＳＮＳ）間の相互作用を介してサーバでクライアント端末に連絡先を提供する方法を適用する。上記方法は、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストに対するクライアントの要請事項を受信するステップと、上記受信されたクライアントの要請事項を検討するステップと、上記ソーシャルネットワークサービスに連絡先リスト要請を伝送するステップと、上記伝送に対応して連絡先リストを受信するステップと、上記受信された連絡先リストと既存の連絡先を比較することによって、上記検討した要請事項に対応する連絡先をフィルターするステップと、上記フィルターされた連絡先を提供するステップと、を含むことを特徴とする。
【００１０】
本発明の他のさらなる他の態様によれば、メッセージングサービスとソーシャルネットワークサービス(ＳＮＳ）間の相互作用を介してクライアント端末に連絡先を提供するサーバであって、上記ソーシャルネットワークサービスで提供する連絡先プロフィールリストに対するクライアントの要請事項を受信し、上記受信されたクライアントの要請事項を検討し、上記ソーシャルネットワークサービス(ＳＮＳ）に連絡先リストの要請を伝送し、上記伝送に対応して連絡先リストを受信し、上記受信された連絡先リストと既存の連絡先を比較することによって、上記検討した要請事項に対応する連絡先をフィルターし、上記フィルターされた連絡先を提供する制御部と、上記要請に対応する応答を受信するＩ／Ｏインターフェースと、を含むことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、拡張された住所録の提供を受けることによって、特定サービスの加入／未加入が決定され得る対象を拡大させることができる利点がある。これによって自身が有している住所録にはないが、自動で新規連絡先の提供を受けることができるので、ユーザは住所録にある既存の友人及び家族だけでなく、本人のプロフィールと関連はあるが、まだ知らない連絡先とも容易に接続できるようになる。またユーザ側面では、特定サービスに新規加入した時、そのサービスをまさに使用するのに便宜性を提供する。さらに例えば、サービスプロバイダーが加入招待メッセージを伝送すれば、関心がないが、ある学校の先輩が本発明で提案するシステムを通じてある後輩アドレスを知るようになって、加入招待メッセージを伝送すると、後輩が加入する可能性がより大きい。このような点を考慮すると、サービスプロバイダー側面では、サービスにまだ加入していないユーザにサービス加入をより容易に誘導でき、サービス加入者数がより速く増加する効果を期待することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態による新規連絡先提供のためのシステム構成図である。
【図２】本発明の実施形態によるソーシャルネットワークサービスとの連動を通じた連絡先提供過程を示したフロー図である。
【図３】図２の応用サーバの内部ブロック構成図である。
【図４】図２の応用サーバの動作フロー図である。
【図５】図２の応用クライアントの内部ブロック構成図である。
【図６】図２の応用クライアントの動作フロー図である。
【図７】本発明で使用されるＣＡＢサービスのための構成図である。
【図８】本発明で使用されるプレゼンスイネイブラーでの動作フロー図である。
【図９Ａ】本発明の第１実施形態による連絡先提供過程を示したフロー図である。
【図９Ｂ】本発明の第１実施形態による連絡先提供過程を示したフロー図である。
【図１０Ａ】本発明の第２実施形態による連絡先提供過程を示したフロー図である
【図１０Ｂ】本発明の第２実施形態による連絡先提供過程を示したフロー図である。
【図１１Ａ】本発明の第３実施形態による連絡先提供過程を示したフロー図である。
【図１１Ｂ】本発明の第３実施形態による連絡先提供過程を示したフロー図である。
【図１２Ａ】本発明の第４実施形態による連絡先提供過程を示したフロー図である。
【図１２Ｂ】本発明の第４実施形態による連絡先提供過程を示したフロー図である。
【図１３Ａ】本発明の第５実施形態による連絡先提供過程を示したフロー図である。
【図１３Ｂ】本発明の第５実施形態による連絡先提供過程を示したフロー図である。
【発明を実施するための形態】
【００１３】
以下、本発明の好適な実施の形態を添付した図面を参照して詳しく説明する。また、以降の説明では、具体的な特定事項を示しているが、これは、本発明のより全般的な理解を助けるべく提供しただけであって、このような特定事項なしでも本発明が実施できることは、当該技術分野における通常の知識を有する者には自明である。そして、本発明を説明するに際し、関連公知機能あるいは構成についての具体的な説明が、本発明の要旨を不要に曖昧にするおそれがあると判断される場合は、その詳細な説明を省略する。
後述する詳細な説明には詳述した技術的課題をなすための本発明において代表的な実施例を提示するはずである。
【００１４】
また、本発明の説明の便宜のために、移動端末のアプリケーションの標準機構であるＯＭＡ(Open Mobile Alliance）のＣＡＢ(Converged Address Book)及びＧＳＭＡ(Global System for Mobile communication Association）のＲＣＳ(Rich Communication Suite)で定義している個体等の名称を使用するが、このような標準及び名称が本発明の範囲を限定するものではなく、類似の技術的背景を有するシステムに適用可能であることはちろんである。
【００１５】
本発明は、ソーシャルネットワークサービス(Social Network Service:以下、“ＳＮＳ”と称する）との相互作用を介した連絡先提供方法を提案する。このために、本発明はＳＮＳとの連動を介して他のサービスを使用するクライアントでそのＳＮＳで提供する連絡先の提供を受けるステップと、提供された連絡先にそのクライアントと同じサービスに加入した相手方クライアントがあるかを判断し、その判断結果を通知するステップと、からなる。他のサービスを使用するクライアントは、判断結果に基づいて、所望の相手方クライアントがサービスに加入したか否かを確認し、その相手方クライアントが自身と同一のサービスに加入していない場合、そのサービスへの招待を要請することができる。このようにすることによって、サービスの加入／未加入が決定され得る対象を拡張させることができるようになる。
【００１６】
上記のような機能が具現された連絡先提供のためのシステムの構成を、図１を参照して説明する。
【００１７】
図１を参照すれば、応用クライアントＡ１０は、ユーザ端末機（例えば、ＵＥ又はＭＳ）で動作する応用メッセージングサービスプログラムである。応用クライアントＡ１０は、ユーザ要請事項をネットワークにある応用サーバ２０に伝達し、応用サーバ２０またはサービス登録サーバ５０から受信したイベントやメッセージを、ユーザに知らせる。応用メッセージングサービスの一例として、本発明の実施形態ではＲＣＳサービスを例に挙げて説明する。応用クライアントＡ１０は、ＣＡＢまたはプレゼンスクライアントとして動作可能である。
【００１８】
応用サーバ２０は、応用クライアントＡ１０から受信したユーザ要請事項を遂行する。また、ＳＮＳインターワーキング(Interworking)サーバ３０や他のネットワークから受信したイベントやメッセージを応用クライアントＡ１０に伝達する。
【００１９】
ＳＮＳインターワーキングサーバ３０は、応用サーバ２０と担当するＳＮＳプロバイダー４０を接続するゲートウェイ(Gateway）の役割をし、応用サーバ２０とＳＮＳプロバイダー４０間に適合したフォーマットに変換するなど、主要な中間媒体の役割をする。本発明によるシステムが実際に具現される場合、ＳＮＳインターワーキングサーバ３０は、応用サーバ２０と同一の場所に主に配置されるか、応用サーバ２０の内部要素で含まれることができる。
【００２０】
ＳＮＳプロバイダー４０及び４１は、フェイスブック(Facebook)やツイッター(Twitter)のようなＳＮＳを提供する機関（agencies）である。
【００２１】
サービス登録サーバ５０は、全てのサービスの登録を処理し管理するサーバである。
上記のような構成のシステムで、連絡先提供過程を説明するために図２を参照する。
【００２２】
図２では、ユーザＡの端末、すなわち、応用クライアントＡ１０は、サービスＭとＳＮＳサービスにともに加入していることを前提とする。これによって、ＳＮＳサービスに接続可能なユーザＡのログインとパスワードが存在し、ＳＮＳインターワーキングサーバ３０は、ユーザＡの代わりに、ＳＮＳプロバイダー４０及び４１にログインをした状態であり、接続が可能である。もし、ＳＮＳインターワーキングサーバ３０がＳＮＳプロバイダー４０及び４１に直接ログインすることができない場合、ユーザＡにまず応用クライアントＡ１０を通じてＳＮＳプロバイダー４０及び４１にログインするよう要請してログインすることを前提とする。
【００２３】
図２を参照すれば、ステップ２０１で、応用クライアントＡ１０は、応用サーバ２０に新規連絡先リストを要請する。このような新規連絡先リストの要請は、ユーザＡが応用クライアントＡ１０を実行するか、サービスＭに接続するときになされることができる。このような要請は、ユーザＡと特性が合う、例えば、他の連絡先がある同じ友人、同じ学校の卒業などに該当する連絡先があるか知るために、該当条件に合う新規連絡先プロフィールリストを要請するためである。ここで、新規連絡先プロフィールには、名前、メールアドレス、電話番号などが含まれる。
【００２４】
すると、応用サーバ２０は、ステップ２０３で、その要請をＳＮＳインターワーキングサーバ３０に伝達する。これに対応して、ＳＮＳインターワーキングサーバ３０は、ステップ２０５ａ及び２０５ｂで、応用サーバ２０からの要請に合うように、必要な少なくとも一つの要請事項をＳＮＳプロバイダー４０及び４１に伝達する。その後、ステップ２０７ａ、２０７ｂで、ＳＮＳプロバイダー４０及び４１から該当要請に対する応答を受信すると、ステップ２０９で、ＳＮＳインターワーキングサーバ３０は、プロフィールリストが受信されたかを判断する。
【００２５】
具体的に、ＳＮＳインターワーキングサーバ３０は、受信された応答が、応用サーバ２０が要請した新規連絡先プロフィールリストであるかを判断し、そのリストでなければ、ステップ２０５ａ及び２０５ｂに戻って、ＳＮＳプロバイダー４０及び４１に必要なその次の要請を伝送し、要請に対する応答で、要請した新規連絡先プロフィールリストを受信した場合、ステップ２１１に進行する。ステップ２０９で、ＳＮＳインターワーキングサーバ３０は、例えば、連絡先ＩＤリストのみを受信し、名前、メールアドレス、電話番号などの具体的なプロフィールに対する受信に失敗した場合には、受信された応答が新規連絡先プロフィールリストでないと判断し、ＳＮＳプロバイダー４０及び４１に要請を再伝送する。
【００２６】
このように新規連絡先プロフィールリストを受信すると、ステップ２１１で、ＳＮＳインターワーキングサーバ３０は、受信した新規連絡先プロフィールリストを応用サーバ２０に伝達する。すると、応用サーバ２０は、受信した各連絡先プロフィールからユーザＡに有効な連絡先のみをフィルターまたは抽出する。ここで、ユーザＡの住所録は、ネットワークにも格納されており、応用サーバ２０はその住所録に接続可能である。これによって、応用サーバ２０は、連絡先フィルタリングを遂行することができ、これに対する具体的な説明は図４を参照して後述する。
【００２７】
その後、応用サーバ２０は、ステップ２１５で、フィルターされた連絡先リストを応用クライアントＡ１０に送る。ステップ２１７で、応用クライアントＡ１０は、受信された連絡先ごとにサービスＭに加入したかを確認し、確認結果をユーザに知らせる。このような連絡先がサービスに加入したかを確認する過程及び確認結果をユーザに知らせる過程に対する具体的な説明は、図６を参照して後述する。
【００２８】
以後、どの連絡先がサービスＭに加入したかを確認するために、応用クライアントＡ１０は、ステップ２１７ａでサービス登録サーバ５０に連絡先登録サービスリストを要請すると、ステップ２１７ｂでサービス登録サーバ５０は連絡先に対応して登録されたサービスリストを応用クライアントＡ１０に送る。これによってユーザＡは既に接続したＳＮＳの友人や、そのユーザと特性が合うＳＮＳの連絡先の提供を受けることができ、その連絡先がサービスＭに加入しているという事実と、その連絡先とサービスを通じて接続可能な方法も提供を受けることができる。さらに、提供された連絡先がサービスＭに加入していないか、加入／未加入が分からない場合、連絡先に対する情報のみが提供されても、ユーザＡは、必要によってその連絡先に該当する相手方クライアントに、サービスＭに対する加入招待メッセージを送ることもできる。
【００２９】
以下、連絡先に対するフィルターを遂行する応用サーバの動作を説明する前に、その内部構成を、図３を参照して説明する。
【００３０】
図３は、応用サーバ２０の内部ブロック構成を示す図である。
図３を参照すると、制御部３０１は、応用サーバ２０のすべての動作を制御し、他の内部構成要素と連結（cooperation）して、どの時点に何を遂行すべきであるかを知らせる。Ｉ／Ｏインターフェース(interface)３０３は、他のシステム要素と情報を交換する時に使用され、メモリ３０５は、応用サーバ２０がすべての動作を遂行する時に処理データが臨時に格納されるストレージである。住所録管理部３０７は、ユーザの既存連絡先情報を格納し、応用クライアント１０で使用される住所録管理部５０７と同期化された住所録を格納する。マッピングテーブル管理部３０９は、メールアドレスや電話番号のような既存アドレス／番号をサービスＭで使用される特定アドレス、例えば、ＳＩＰ ＵＲＩに変換する。このような住所録管理部３０７及びマッピングテーブル管理部３０９は、本発明で提案する実施形態によって、応用サーバ２０から分離され具現され得る。
【００３１】
上述したように構成された応用サーバ２０は、図４のような連絡先に対するフィルターを遂行する。このような連絡先フィルタリングは、応用サーバ２０の制御部３０１の制御下で遂行される。
【００３２】
図４を参照すれば、ステップ４０１で、制御部３０１は、Ｉ／Ｏインターフェース３０３を通じて受信した連絡先プロフィールリストをメモリ３０５に格納する。ステップ４０３で、制御部３０１は、メモリ３０５に格納されたプロフィールから、連絡先識別可能なデータ、例えば、名前、メールアドレス、電話番号などを抽出する。ステップ４０５で、制御部３０１は、抽出されたデータと住所録管理部３０７にある該当データとを比較し、抽出されたデータが住所録に既に存在する連絡先であるかを判断する。判断の結果、抽出されたデータが住所録に存在する連絡先に該当する場合、ステップ４０７で、サービスＭに既に加入しているかを判断する。具体的に、制御部３０１は、その存在する連絡先に対してサービスＭに加入していることを示す表示（indicator）が住所録管理部３０７にあるかを判断する。サービスＭに既に加入していると判断されると、制御部３０１は、ステップ４０９でプロフィールを削除する。この時、サービスＭに既に加入していると判断されると、その連絡先がサービスＭに加入しているという事実をユーザＡも既に知っているという意味である。したがって、この連絡先に対してはこれ以上進行する必要がないので、連絡先に対するプロフィールをメモリ３０５から削除するものである。
【００３３】
ステップ４０５で抽出されたデータがその住所録に存在する連絡先ではないか、ステップ４０７でサービスに既に加入した場合でなければ、ステップ４１１で、制御部３００は、サービスＭで使用可能なアドレスがあるかを確認する。具体的に、住所録管理部３０７にその連絡先に対応してサービスＭで使用可能なアドレス（以下、“サービスＭアドレス”と称する)があるかを確認する。したがって、抽出されたデータが住所録管理部３０７に存在する連絡先ではないか、サービスＭアドレス、例えば、ＳＩＰ ＵＲＩがない場合、マッピングテーブル管理部３０９に接続して、ステップ４０３で抽出された連絡先のメールアドレスや電話番号にマッチングされるサービスＭアドレスがあるか否かを確認する。例えば、ＲＣＳサービスの場合、ＳＩＰ ＵＲＩアドレスが使用可能であるが、いろいろなサービスがＳＩＰ ＵＲＩアドレスを使用するために、ＳＩＰ ＵＲＩアドレスがあるとしても、連絡先が必ずＲＣＳサービスに加入したということではない。
【００３４】
したがって、下記のような方法を通じてサービスＭアドレスがあるか否かを確認することができ、その方法は状況によって選択的に使用される。その方法を説明すれば、次のようである。マッピングテーブル管理部３０９にマッチングされる連絡先のサービスＭアドレスがないが、連絡先に該当する相手方クライアントが他のネットワーク加入者であるので、他のネットワークにあるサーバが知る可能性のある場合、制御部３０１は、Ｉ／Ｏインターフェース３０３を通じて他のネットワークサーバに連絡先のプロフィールを伝達し、マッチングされるサービスＭアドレスを要請することができる。他のネットワークサーバからＩ／Ｏインターフェース３０３を通じて応答を受信し、受信された応答にマッチングされるサービスＭアドレスが含まれている場合、制御部３０１は、サービスＭアドレスを連絡先のメールアドレス及び電話番号とともにマッピングテーブル管理部３０９に追加する。
【００３５】
上記の方法により、連絡先のサービスＭアドレスが存在する場合、制御部３０１は、連絡先に該当する相手方クライアントがサービスＭに加入する可能性があるので、ステップ４１３で連絡先プロフィールにサービスＭアドレスを追加する。これとは異なり、連絡先のサービスＭアドレスが存在しないか、分からない場合、ステップ４１５に進行して検討すべき連絡先プロフィールがもっとあるかを判断し、検討すべき連絡先がもっとある場合、ステップ４０３に戻って上述した過程を反復遂行し、これ以上検討すべき連絡先がない場合、連絡先フィルタリング動作を終了する。
【００３６】
一方、連絡先がサービスに加入したか否かを確認する過程及び確認結果をユーザに知らせる動作を遂行する応用クライアントＡの動作を説明する前に、応用クライアントＡ１０の内部構成について図５を参照して説明する。
【００３７】
図５を参照すれば、制御部５０１は、応用クライアントＡ１０のすべての動作を制御する要素として、他の内部構成要素と連結して、どの時点に何を遂行しなければならないかを知らせる役割をする。Ｉ／Ｏインターフェース５０３は、他のシステム要素と情報を交換する時に使用されるインターフェースである。メモリ５０５は、応用クライアントＡ１０がすべての動作を遂行する時に処理データが臨時に格納されるストレージである。住所録管理部５０７は、ユーザの既存連絡先情報を格納するストレージとして、応用サーバ２０で使用される住所録管理部３０７と同期化されている。ユーザインターフェース５０９は、ユーザのすべての情報を見せる時やユーザが情報を入力する時に使用されるインターフェースである。
【００３８】
上述したように構成された応用クライアントＡ１０は、図６のような連絡先が特定サービスに加入したか否かを確認する過程及び確認過程をユーザに知らせる過程を遂行する。このような動作は、応用クライアントＡ１０の制御部５０１の制御下で遂行される。
【００３９】
図６を参照すれば、制御部５０１は、ステップ６０１で、Ｉ／Ｏインターフェース５０３を通じて受信したフィルターされた連絡先プロフィールリストをメモリ５０５に格納する。ステップ６０３で、メモリ５０５に格納された連絡先プロフィールでサービスＭアドレスがあるかを確認する。判断の結果、サービスＭアドレスがある場合、連絡先がサービスＭに加入する可能性があるので、制御部５０１は、ステップ６０５で連絡先プロフィールを“加入リスト”に追加した後、メモリ５０５に格納する。これとは異なり、サービスＭアドレスがない場合、その連絡先がサービスＭに加入する可能性がないか、分からない。したがって、制御部５０１は、連絡先プロフィールを“未加入リスト”に追加し、メモリ５０５に格納する。
【００４０】
ステップ６０９で、受信されたリストに検討するプロフィールがもっとあるかを判断し、検討するプロフィールがもっとある場合、ステップ６０３に戻って上述した過程を反復遂行し、検討するプロフィールがこれ以上ない場合、ステップ６１１に進行する。
【００４１】
ステップ６１１で、制御部５０１は、メモリ５０５に格納された“加入リスト”にある連絡先をＩ／Ｏインターフェース５０３を通じてサービス登録サーバ５０に伝送し、各連絡先の登録されたサービス加入リストを要請する。このような要請に対応してステップ６１３でＩ／Ｏインターフェース５０３を通じてサービス登録サーバ５０から、各連絡先に対応して登録されているサービスリストを受信する。すなわち、制御部５０１は、連絡先に該当する各相手方クライアントが登録したサービスに対するリストを受信する。
【００４２】
ステップ６１５で、制御部５０１は、連絡先サービスリストにサービスＭがあるかを確認する。もし、サービスＭがない場合、ステップ６１７で連絡先がサービスＭに加入していないので、メモリ５０５に格納された連絡先を“加入リスト”から“未加入リスト”に移動させる。ステップ６１９で受信された連絡先プロフィールリストに検討するプロフィールがもっとあるかを判断し、検討するプロフィールがもっとある場合、制御部５０１は、ステップ６１５に戻って上記過程を反復遂行する。これとは異なり、検討するプロフィールがこれ以上ない場合、ステップ６２１でメモリ５０５に格納された“加入リスト”と“未加入リスト”連絡先を、ユーザインターフェース５０９を通じてユーザＡに知らせる。
【００４３】
ここで、“加入リスト”連絡先の場合、応用クライアントＡ１０は、該当連絡先が同じサービスＭを使用するという事実をユーザＡに知らせ、住所録管理部５０７に連絡先を追加する方法と、サービスＭを通じてその連絡先と接続できる方法を提供する。
【００４４】
“未加入リスト”連絡先の場合、応用クライアントＡ１０は、該当連絡先が存在するという事実をユーザＡに知らせ、住所録管理部５０７に連絡先を追加する方法と、その連絡先にサービスＭへの加入招待メッセージを送ることができる方法を提供する。
【００４５】
以下、応用クライアントＡ１０のユーザが加入したサービスＭがＲＣＳサービスと仮定した場合、そのＲＣＳサービスは複数のイネイブラー(enablers）の組み合わせとプロファイリング(profiling)を用いてサービスを提供する。本発明の実施形態では、このようなＲＣＳサービスをＳＮＳサービスと連動させることによって、サービスの加入／未加入が決定され得る対象を拡張させることができる。このようなＲＣＳサービスは、住所録統合機能を提供するイネイブラーの一例であるＯＭＡ(Open Mobile Alliance）のＣＡＢ(Converged Address Book）とＯＭＡプレゼンス(Presence)を基に提供され得る。
【００４６】
これによって、図２での応用クライアントＡ１０は、新規連絡先を受信するためにＣＡＢクライアントとして動作でき、受信された新規連絡先に相当するクライアントのサービスの加入／未加入を受信するためにプレゼンスクライアントとしても動作できる。したがって、本発明にともなうＳＮＳサービスとの連動を通じた連絡先提供システムは、ＯＭＡ ＣＡＢとＯＭＡプレゼンスイネイブラー(Presence Enabler)を基盤で具現され得る。
【００４７】
上記のような本発明を説明する前に、本発明で使用される一般的なＣＡＢシステムの構成について図７を参照して説明する。
【００４８】
図７を参照すれば、ＣＡＢクライアント７１は、ユーザ端末機にある住所録を管理及び制御する応用プログラムである。ＣＡＢサーバ７２は、ＣＡＢクライアント７１から受信したユーザの多様な要請事項を遂行するネットワーク主要要素である。ＣＡＢ ＡＢ((Address Book)ＸＤＭＳ(XML Document Management Server)７３は、ユーザの住所録を格納及び管理するサーバである。ＣＡＢ ＰＣＣ(Personal Contact Card)ＸＤＭＳ７４は、ユーザのプロフィールを格納及び管理するサーバである。ＣＡＢ ＵＰ(User Preferences)ＸＤＭＳ７５は、ユーザの選好度及び特定要請事項を格納及び管理するサーバである。Ｎｏｎ-ＣＡＢ住所録システム７６は、ＣＡＢサービスで使用する住所録システムと他のすべての住所録システムを含み、例えば、ｖＣａｒｄなどがこれに該当する。本発明では、図２に説明したＳＮＳプロバイダー４０及び４１もＮｏｎ-ＣＡＢ 住所録システム７６に含まれると仮定し得る。
【００４９】
本発明で使用されるインターフェースとプロトコル／技術は、次のようである。
ＣＡＢ−１インターフェースは、ＣＡＢサーバ７２を経てＣＡＢクライアント７１にある住所録とＣＡＢ ＡＢ ＸＤＭＳ７３に格納された住所録間の同期化のために使用される。また、ＣＡＢ−１インターフェースは、ＣＡＢサーバ７２がＣＡＢクライアント７１に二つの住所録間に差異を通知するときに使用される。プロトコル／技術としてＳｙｎｃＭＬ［３］が使用される。
【００５０】
ＳＩＣ−１インターフェースは、ＣＡＢ ＰＣＣ ＸＤＭＳ７４とＣＡＢ ＵＰ ＸＤＭＳ７５に格納されたデータが変更されるごとに、ＣＡＢクライアント７１に変更事項を知らせる時に使用される。参考までに、ＣＡＢ ＡＢ ＸＤＭＳ７３変更事項通知はＣＡＢ−１インターフェースが使用される。プロトコル／技術としてはＳＩＰ(Session Initiation Protocol)-Specific Event Notification［４］が使用される。
【００５１】
ＳＩＣ−２インターフェースは、ＣＡＢ ＡＢ ＸＤＭＳ７３、ＣＡＢ ＰＣＣ ＸＤＭＳ７４とＣＡＢ ＵＰ ＸＤＭＳ７５に格納されたデータが変更されるごとに、ＣＡＢサーバ７１に変更事項を知らせる時に使用される。プロトコル／技術としてはＳＩＰ(Session Initiation Protocol)-Specific Event Notification［４］が使用される。
【００５２】
ＸＤＭ−３ｉインターフェースは、ＣＡＢクライアント７１がＣＡＢ ＰＣＣ ＸＤＭＳ７４とＣＡＢ ＵＰ ＸＤＭＳ７５に格納されたデータを管理する時に使用される。プロトコル／技術としてはＸＣＡＰ／ＨＴＴＰ(XML Configuration Access Protocol／HyperText Transfer Protocol)［５］が使用される。
【００５３】
ＸＤＭ−４ｉインターフェースは、ＣＡＢサーバ７２がＣＡＢ ＡＢ ＸＤＭＳ７３、ＣＡＢ ＰＣＣ ＸＤＭＳ７４、及びＣＡＢ ＵＰ ＸＤＭＳ７５に格納されたデータを管理する時に使用される。プロトコル／技術としてはＸＣＡＰ／ＨＴＴＰ(XML Configuration Access Protocol／Hyper Text Transfer Protocol)［５］が使用される。
【００５４】
また、本発明で使用される一般的なプレゼンスイネイブラーでの動作フローは、図８のようである。ＯＭＡプレゼンスイネイブラーは、ユーザが他のユーザが使用するサービスに対して決定しようとする時も、図８のような動作を遂行する。その動作流れは、ＳＩＰ-Specific Event Notification［４］プロトコルを用いて遂行される。
【００５５】
図８を参照すれば、プレゼンスクライアント８１はフェッチャ(fetcher)として、他のユーザがプレゼンスサーバ８４に登録したプレゼンス(Presence)情報を受信するために、ステップ８０１でＳＩＰ ＳＵＢＳＣＲＩＢＥを送る。この時、プレゼンス情報を一度だけ受信するために、ＳＩＰ ＳＵＢＳＣＲＩＢＥのうちに“Ｅｘｐｉｒｅｓ”ヘッダーを０で設定する。これとは異なり、周期的に変更事項を受信するためには、“Ｅｘｐｉｒｅｓ”ヘッダーをより高い値で設定する。ＳＩＰ ＳＵＢＳＣＲＩＢＥは、ステップ８０３及び８０５で、ＳＩＰ基盤の下部伝送ネットワークに該当するフェッチャ（Fetcher）ＳＩＰ／ＩＰ Ｃｏｒｅ８２と、プレゼンスサーバ８４側にあるPresentityＳＩＰ／ＩＰ Ｃｏｒｅ８３を経てプレゼンスサーバ８４に伝達される。
【００５６】
ステップ８０７でプレゼンスサーバ８４は、プレゼンスクライアント８１が要請した情報を受信することを許諾したか否かを判断するために、認証チェック(authorization check)を遂行する。もし要請を許諾する場合、ステップ８０９乃至８１３で、プレゼンスサーバ８４は、２００ ＯＫをＳＩＰ／ＩＰ Ｃｏｒｅｓ８２及び８３を経てプレゼンスクライアントに伝達する。その後、ステップ８１５乃至８１９で、プレゼンスサーバ８４は、要請した情報をＳＩＰ ＮＯＴＩＦＹを用いてＳＩＰ／ＩＰ Ｃｏｒｅｓ８２及び８３を経てプレゼンスクライアント８１に伝達する。これに対応してステップ８２１乃至８２５で、プレゼンスクライアント８１は、２００ ＯＫを用いてプレゼンス情報の受信確認（ＡＣＫ）をＳＩＰ／ＩＰ Ｃｏｒｅｓ８２及び８３を経てプレゼンスサーバ８４に伝達する。
【００５７】
以下、本発明の実施形態による図２の動作の流れを、上記のような図７及び図８を基盤で再構成した場合を具体的に説明する。本発明の実施形態によって、図７及び図８を基盤で再構成されたＲＣＳサービスとＳＮＳサービスと連動するシステムの構成は、図９Ａ乃至図１３Ｂのように具現され得る。ここで、図９Ｂ、図１０Ｂ、図１１Ｂ、図１２Ｂ、図１３Ｂは、各々図９Ａ、図１０Ｂ、図１１Ｂ、図１２Ｂ、図１３Ｂにつながるフロー図である。
【００５８】
図９Ａ及び図９Ｂは、本発明の第１実施形態による連絡先提供過程を示したフロー図である。図９Ａ及び図９Ｂでは、図２の応用サーバ２０とＳＮＳインターワーキングサーバ３０が統合され具現された場合を示し、説明の便宜のためにルーティング及びその他の目的のための要素ら、例えば、ＳＩＰ／ＩＰ Ｃｏｒｅｓ、ＩＭＳ、Aggregation Proxy等は省略されているが、必要によってその過程を遂行すると仮定し得る。以下の図面では、図２のＲＣＳサービスがＣＡＢサービスの構成を基で再構成されたことであるので、ＲＣＳ関連用語はＣＡＢで使用される用語で代替でき、説明の便宜のためにＲＣＳとＣＡＢを並行して表記する。同様に、図２のＳＮＳもＮｏｎ-ＲＣＳと並行して表記できる。
【００５９】
図９Ａを参照すれば、ユーザＡがＲＣＳサービスに接続する時、ＲＣＳ(ＣＡＢ)クライアントＡ７１は、新規連絡先提案リストを受信するために、要請に対する詳細な情報をＣＡＢ ＵＰ ＸＤＭＳ７５が管理する“ＣＡＢ Feature Handler”という文書に格納するように要請する。このためにステップ９０１で、“Get Contact suggestions”要請がＸＣＡＰ／ＨＴＴＰ ＰＵＴ形態でＣＡＢ ＸＤＭＳのうちＣＡＢ ＵＰ ＸＤＭＳ７５に伝達される。“ＣＡＢ Feature Handler”文書に対する詳細説明は後述する。
【００６０】
ステップ９０３でＣＡＢ ＵＰ ＸＤＭＳ７５は、管理する“ＣＡＢ Feature Handler”文書に要請事項を格納し、格納完了応答である２００ ＯＫをＲＣＳ(ＣＡＢ)クライアントＡ７１に送る。ステップ９０５で、ＣＡＢ ＵＰ ＸＤＭＳ７５は“ＣＡＢ Feature Handler”文書に格納されたＲＣＳ(ＣＡＢ)クライアントＡ７１の要請事項と関連情報をＲＣＳ(ＣＡＢ)サーバ７２に通知する。このような通知のために、ＳＩＰ ＮＯＴＩＦＹメッセージが使用される。ステップ９０７で通知を受信すると、ＲＣＳ(ＣＡＢ)サーバ７２は、確認メッセージである２００ ＯＫをＣＡＢ ＵＰ ＸＤＭＳ７５に送る。ステップ９０９でＲＣＳ(ＣＡＢ)サーバ７２は、要請事項を検討してＮｏｎ-ＲＣＳ(ＣＡＢ)住所録システム(Address Book Systems)７６に適合したフォーマットに変換し、Ｎｏｎ-ＲＣＳ(ＣＡＢ)連絡先リストをＲＣＳ(ＣＡＢ)住所録システム７６に要請する。ここで、Ｎｏｎ-ＲＣＳ(ＣＡＢ)住所録システムは、ＳＮＳプロバイダーに該当する。図９Ａ及び図９Ｂでは一つのＳＮＳプロバイダーに該当するＮｏｎ-ＲＣＳ(ＣＡＢ)住所録システムを例示したが、ＳＮＳプロバイダーが複数の場合、その複数のＳＮＳプロバイダーから連絡先リストを受信してＲＣＳ(ＣＡＢ)サーバ７２で結合することができることはもちろんである。
【００６１】
ステップ９１１で、Ｎｏｎ-ＲＣＳ(ＣＡＢ)住所録システム７６は、要請したＮｏｎ-ＲＣＳ(ＣＡＢ)連絡先リストをＲＣＳ(ＣＡＢ)サーバ７２に送る。この時、必要なリストを正確に受信するために、ステップ９０９とステップ９１１が反復遂行され得る。ステップ９１３でＲＣＳ(ＣＡＢ)サーバ７２は、受信されたＮｏｎ-ＣＡＢ連絡先リストをＲＣＳ(ＣＡＢ)フォーマットに変換する。ステップ９１５でＲＣＳ(ＣＡＢ)サーバ７２はネットワークに格納されたユーザＡの既存住所録をＣＡＢ ＡＢ ＸＤＭＳ７３に要請する。このような要請のためにＸＣＡＰ／ＨＴＴＰ ＧＥＴが使用され得る。
【００６２】
これに対応してステップ９１７でＣＡＢ ＡＢ ＸＤＭＳ７３は、要請したユーザＡの住所録を含む２００ ＯＫをＲＣＳ(ＣＡＢ)サーバ７２に送る。ここで、ＲＣＳ(ＣＡＢ)サーバ７２は、図２の応用サーバ２０とＳＮＳインターワーキングサーバ３０の機能を遂行する。
【００６３】
これによってＲＣＳ(ＣＡＢ)サーバ７２は、ステップ９１９でユーザＡの既存連絡先とＮｏｎ-ＲＣＳ(ＣＡＢ)住所録システム７６から受信した新規連絡先プロフィールを比較することによって、連絡先をフィルターする。このような連絡先フィルタリングに対する動作は、上述した図４によって遂行される。このようにフィルターされた連絡先は、ステップ９２１でＣＡＢ ＵＰ ＸＤＭＳ７５に格納され、このような格納要請のために、ＸＣＡＰ／ＨＴＴＰ ＰＵＴが使用される。ステップ９２３でＣＡＢ ＵＰ ＸＤＭＳ７５は、受信した連絡先プロフィールを格納して確認応答として２００ ＯＫをＲＣＳ(ＣＡＢ)サーバ７２に送る。
【００６４】
ステップ９２５で、ＣＡＢ ＵＰ ＸＤＭＳ７５は新規連絡先プロフィールが格納されているという事実をＲＣＳ(ＣＡＢ)クライアントＡ７１に通知し、プロフィールを送る。このようなプロフィールを送るためにＳＩＰ ＮＯＴＩＦＹメッセージが使用される。このような受信されたプロフィールは、ＲＣＳ(ＣＡＢ)クライアントＡ７１がステップ９０１で伝送した要請に対する応答である。ステップ９２７でＲＣＳ(ＣＡＢ)クライアントＡ７１は、受信したＳＩＰ ＮＯＴＩＦＹに対する確認メッセージをＣＡＢ ＵＰ ＸＤＭＳ７５に送る。
【００６５】
このようにＲＣＳ(ＣＡＢ)クライアントＡ７１立場では、Ｎｏｎ-ＲＣＳプロバイダー、すなわち、ＳＮＳプロバイダーとの連動を介して特定サービスの加入／未加入が決定され得る対象を拡張させることができる。このためにステップ９２９で、ＲＣＳ(ＣＡＢ)クライアントＡ７１は、受信したプロフィールからＳＩＰアドレスがある連絡先を抽出する。具体的に、上述した図６によって、受信した連絡先プロフィールのうち、ＲＣＳサービスに使用可能なアドレス、すなわち、ＳＩＰ ＵＲＩがあるかを確認し、その連絡先を抽出する。ステップ９３１でＲＣＳ(ＣＡＢ)クライアントＡ７１は、ＳＩＰ連絡先アドレスを基で、ＲＣＳ(Presence)クライアントＡ７１を通じて使用可能なサービスリストを示す各ＳＩＰ連絡先の“service capability information”をＲＣＳ(Presence)サーバ８４に要請する。このような要請のためにＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージが使用される。ここで、ＲＣＳ(ＣＡＢ)クライアントＡ７１とＲＣＳ(Presence)クライアントＡ７１は、図２の応用クライアントＡ１０に該当し、同じユーザ端末機に設置された応用プログラムである。ただし、本発明では連絡先を要請する場合には、ＲＣＳ(ＣＡＢ)クライアントとして動作するので、ＲＣＳ(ＣＡＢ)クライアントＡ７１と呼び、サービスの加入／未加入を要請する場合には、ＲＣＳ(Presence)クライアントとして動作するので、ＲＣＳ(Presence)クライアントＡ７１とも呼ぶ。
【００６６】
ＲＣＳ(Presence)サーバ８４は、ＲＣＳ(Presence)クライアントＡ７１が要請した情報を受信することを許諾するかを判断するために、認証チェック(authorization check）を検討し、要請を許諾する場合、ステップ９３３で許諾メッセージである２００ ＯＫをＲＣＳ(Presence)クライアントに伝達する。ステップ９３５でＲＣＳ(Presence)サーバ８４は要請した連絡先の“service capability information”をＲＣＳ(Presence)クライアントＡ７１にＳＩＰ ＮＯＴＩＦＹメッセージを用いて伝達する。このようなメッセージを受信したＲＣＳ(Presence)クライアントＡ７１は、ステップ９３７で“service capability information”の受信確認である２００ ＯＫをＲＣＳ(Presence)サーバ８４に伝達する。
【００６７】
その後、ステップ９３９でＲＣＳ(ＣＡＢ)クライアントＡ７１は、ＲＣＳ(Presence)クライアントＡ７１を通じて各連絡先の“service capability”情報を、図６のステップ６１５乃至６２１によってＲＣＳユーザであるか否かを検討してユーザに知らせる。
【００６８】
上述したように、本発明の第１実施形態ではＲＣＳ(ＣＡＢ)サーバ７２がフィルタリング機能及びインターワーキング機能をともに遂行し、フィルターされた連絡先が別途にＣＡＢ ＵＰ ＸＤＭＳ７５で管理する“ＣＡＢ Feature Handler”という文書に格納される場合を例に挙げて説明した。しかしながら、他にはフィルターされた連絡先は“ＣＡＢ Feature Handler”文書でないＲＣＳ（ＣＡＢ）クライアントＡ７１が有している住所録に含まれて格納されることができ、このような本発明の第２実施形態による構成は、図１０Ａ及び図１０Ｂに示したようである。
【００６９】
本発明の第２実施形態を説明する前に、“ＣＡＢ Feature Handler”という文書の詳細内容を説明する。
【００７０】
本発明では、<contact_suggestions>というエレメントを定義する。
<contact_suggestions>エレメントは、ＲＣＳ(ＣＡＢ)クライアントＡ７１が新規連絡先提案リストを受信しようとする時、“ＣＡＢ Feature Handler”文書に含まれるエレメントである。このようなエレメントの下位レベルは、<non-CAB source>、<credentials>、<criteria>、<scheduled-interval>、<max-suggestions>、<id>、<code>、<phrase>、<contact_suggestion_response>などのエレメントなどで構成される。
【００７１】
<non-CAB source>は、どの機関から新規連絡先提案を受信したいかを記載するためのエレメントとして、例えば、domain nameが記載される。このエレメントがない場合、サービスプロバイダーのポリシー（policy）にしたがって決定される。
【００７２】
<credentials>は、該当機関に接続する時に認証のために必要な情報を意味する。
<credentials>の下位レベルには、ログイン情報が記載される<user name>とパスワードが記載される<password>などのエレメントが属している。
【００７３】
<criteria>は、<preferences>または<keywords>で代替でき、新規連絡先提案を何の基準で選択するかを設定するために使用される。このエレメントの下位レベルには、<friend-of-friend>、<same-school>、<same-work>、<same-hobby>などのエレメントが含まれる。
【００７４】
まず、<friend-of-friend>は<mutual-friend>とも言え、ＲＣＳ（ＣＡＢ）クライアントＡが該当機関にあるユーザ住所録の登録された連絡先を受信したい時、例えば、ユーザの友人の友人等の連絡先を受けたい時、“１”で設定される。
【００７５】
<same-school>には、同じ学校に通った連絡先提案を受けたい時、該当学校名が記載される。
【００７６】
<same-work>には、同じ職業を有している連絡先提案を受けたい時、該当会社や職業種類が記載される。
【００７７】
<same-hobby>には、同じ趣味を有している連絡先提案を受けたい時、該当趣味が記載される。
【００７８】
上記の下位エレメントは、例題であるだけで、<criteria>(または<preferences>、<keywords>)エレメントに所望するキーワードを直接入力することもできる。また<criteria>も記載しない場合、ＲＣＳ(ＣＡＢ)サーバ７２がユーザプロフィール(ＣＡＢ ＰＣＣ ＸＤＭＳ７４)に接続し、ユーザプロフィールとサービスプロバイダーのポリシーにしたがって決定されることができる。
【００７９】
<scheduled-interval>には、ＲＣＳ（ＣＡＢ）クライアントＡ７１が一度だけでなく、周期的に連絡先提案を受信することを所望する時、提案時間間隔が記載される。
【００８０】
<max-suggestions>には、ＲＣＳ（ＣＡＢ）クライアントＡ７１が提案を受けようとする最大連絡先数を設定する。
【００８１】
<id>は、各要請を識別するＩＤである。
上述した<contact_suggestions>エレメントは、<cab_feature>の属する下位レベルエレメントである。<cab_feature>エレメントの下位レベルには、<response>というエレメントも含まれる。<response>エレメントは、上述したステップ９２１でのようにＲＣＳ(ＣＡＢ)サーバ７２がＲＣＳ(ＣＡＢ)クライアントＡ７１が要請に応答する時に満たすエレメントである。<response>エレメントの下位レベルは、次のエレメントを含む。
【００８２】
<code>は、応答に対する状態コードであり、応答が成功的に実行されたか、失敗したかを示す該当状態コード(status code)が記載される。
【００８３】
<phrase>は、応答に対するhigh-level文章である。
<contact_suggestions_response>には、上述した<contact_suggestions>要請関連詳細応答が記載される。ここで、新規連絡先提案情報が載せており、各連絡先に対する詳細な情報構造はＯＭＡ ＣＡＢで定義した構造に従う。
【００８４】
本発明の第１実施形態では、<contact_suggestions_response>が新規連絡先提案要請情報と同一の文書に入っていると仮定するが、他の文書に別に記載されることもできる。
【００８５】
一方、本発明の第２実施形態では、ＲＣＳクライアントＡ７１が有している住所録にフィルターされた連絡先が含まれて格納される場合を説明し、このために図１０Ａ及び図１０Ｂを参照する。
【００８６】
図１０Ａのステップ１００１乃至１０１９は、図９Ａのステップ９０１乃至９１９での動作と同一である。ただし、本発明の第２実施形態ではＣＡＢ ＡＢ ＸＤＭＳ７３にフィルターされた連絡先が格納される。これによってステップ１０２１でＲＣＳ(ＣＡＢ)サーバ７２は、フィルターされた連絡先をＣＡＢ ＡＢ ＸＤＭＳ７３に格納するように要請する。このような要請のために、ＸＣＡＰ／ＨＴＴＰ ＰＵＴが使用される。この時、フィルターされた連絡先は、ユーザ住所録に直接格納されることもでき、他の別途の文書に格納されることもできる。
【００８７】
ステップ１０２３で、ＣＡＢ ＡＢ ＸＤＭＳ７３は、受信した連絡先プロフィールを格納し、確認応答である２００ ＯＫをＲＣＳ(ＣＡＢ)サーバ７６に送る。ステップ１０２５で、ＲＣＳ(ＣＡＢ)サーバ７２は住所録の変更をＲＣＳ(ＣＡＢ)クライアントＡ７１に通知する。このような通知のために、ＯＭＡ ＤＳが使用される。図１０Ｂのステップ１０２７で、ＲＣＳ(ＣＡＢ)クライアントＡ７１は、住所録同期化をＲＣＳ(ＣＡＢ)サーバ７２と実施し、同期化を通じて新規提案連絡先を共に受信する。以下、図１０Ｂのステップ１０２９乃至１０３９は、図９Ｂのステップ９２９乃至９３９での動作と同一である。ただ、住所録に直接格納された場合、連絡先がＲＣＳサービスの使用／非使用によって、またユーザ指向及び選択によって、追加された連絡先提案を住所録で削除できる。
【００８８】
一方、本発明の第３実施形態は、本発明の第２実施形態での連絡先フィルタリングステップ及びフィルターされた連絡先リストをＣＡＢ ＵＰ ＸＤＭＳ７５に格納するステップを、ＲＣＳ(ＣＡＢ)サーバ７２でなく、ＣＡＢ ＡＢ ＸＤＭＳ７３が遂行する場合に関することである。本発明の第３実施形態を説明するために図１１Ａ及び図１１Ｂを参照する。
【００８９】
図１１Ａのステップ１１０１乃至１１１３は、図９Ａのステップ９０１乃至９１３での動作と同一である。ただし、ＣＡＢ ＡＢ ＸＤＭＳ７３は連絡先をフィルターし、ＣＡＢ ＵＰ ＸＤＭＳ７５に格納する動作を遂行する。これによってステップ１１１５で、ＲＣＳ(ＣＡＢ)サーバ７２は、変換された連絡先をＣＡＢ ＡＢ ＸＤＭＳ７３に格納するように要請し、このような要請のためにＸＣＡＰ／ＨＴＴＰ ＰＵＴが使用される。ステップ１１１７で、ＣＡＢ ＡＢ ＸＤＭＳ７３は、受信した連絡先プロフィールを格納し、確認応答で２００ ＯＫをＲＣＳ(ＣＡＢ)サーバ７２に送る。ステップ１１１９で、ＣＡＢ ＡＢ ＸＤＭＳ７３は、図４で説明した動作に従ってユーザＡの既存連絡先とＲＣＳ(ＣＡＢ)サーバ７２から受信した(変換した)新規連絡先プロフィールを比較することによって、連絡先をフィルターする。
【００９０】
ステップ１１２１で、ＣＡＢ ＡＢ ＸＤＭＳ７３は、フィルターされた連絡先をＣＡＢ ＵＰ ＸＤＭＳ７５に格納する。この時、フィルターされた連絡先の格納動作は、ＣＡＢ ＸＤＭＳ内部要素間に遂行される動作であるから、別途のプロトコルや受信確認メッセージを使用しない。上述した内容以外の図１１Ａ及び図１１Ｂでのステップ１１２５乃至１１３９は、図９Ａ及び図９Ｂのステップ９２５乃至９３９での動作と同一である。
【００９１】
一方、本発明の第４実施形態は、本発明の第１実施形態での連絡先フィルタリングステップとＳＩＰ連絡先抽出及び“service capability information”要請ステップをＲＣＳ(ＣＡＢ)サーバ７２が予め共に全部遂行する場合に関する。本発明の第４実施形態を説明するために図１２Ａ及び図１２Ｂを参照する。これによって、図１２Ａのステップ１２０１乃至１２１９は、図９Ａのステップ９０１乃至９１９での動作と同一である。また、図１２Ａのステップ１２２１乃至図１２Ｂのステップ１２２９は、図９Ｂのステップ９２９乃至９３７での動作と同一であるが、この動作をＲＣＳ(Presence)クライアント８１でなく、ＲＣＳ(ＣＡＢ)サーバ７２が遂行する。したがって、プレゼンスクライアントＡ８１の役割をするプレゼンス機能がＲＣＳ(ＣＡＢ)サーバ７２内部に含まれたと仮定する。
【００９２】
また、図１２Ｂのステップ１２３１乃至１２３７は、図９Ａのステップ９２１乃至９２７での動作と同一である。ただし、ステップ１２３１で格納する提案連絡先プロフィールには、ステップ１２３１乃至１２３７の結果によって各連絡先のＲＣＳ(ＣＡＢ)サービスの加入／未加入に対する表示が含まれている。そしてステップ１２３９で、ＲＣＳ(ＣＡＢ)クライアント７１は、受信した連絡先情報を別に分析する必要なくユーザに提案する。
【００９３】
一方、上述した本発明の第４実施形態では、すべての分析及びフィルター過程をＲＣＳ(ＣＡＢ)サーバ７２が予め全部遂行する場合を例に挙げて説明したが、本発明の第５実施形態では、反対にＲＣＳ(ＣＡＢ)サーバ７２が予め遂行する代わりに、後でＲＣＳ(ＣＡＢ／Presence)クライアント７１が全部遂行するように具現することができる。このような本発明の第５実施形態を図１３Ａ及び図１３Ｂを参照して説明する。
【００９４】
図１３Ａのステップ１３０１乃至１３１３は、図９Ａのステップ９０１乃至９１３での動作と同一である。また、ステップ１３１５乃至１３２１も図９Ａのステップ９２１乃至９２７での動作と同一であるが、図９Ａのステップ９２１で格納される連絡先は、ＲＣＳ(ＣＡＢ)フォーマットに変換されたが、ステップ１３１５ではまだ追加分析及びフィルターされない状態でＣＡＢ ＵＰ ＸＤＭＳ７５に格納される。また図１３Ｂのステップ１３２３は、図９Ａのステップ９１９での動作と同一であるが、その動作をＲＣＳ(ＣＡＢ)サーバ７２が遂行することでなく、ＲＣＳ(ＣＡＢ)クライアント７１が内部にある住所録管理部５０７にある連絡先と比較することによってフィルターを遂行する。以下、図１３Ｂのステップ１３２５乃至１３３５は、図９Ｂのステップ９２９乃至９３９での動作と同一である。
【００９５】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【符号の説明】
【００９６】
１０  応用クライアントＡ
２０  応用サーバ
３０  ＳＮＳインターワーキングサーバ
４０  ＳＮＳプロバイダー１
４１  ＳＮＳプロバイダー２
５０  サービス登録サーバ
【図１】
2013521562.tif 000003
【図２】
2013521562.tif 000004
【図３】
2013521562.tif 000005
【図４】
2013521562.tif 000006
【図５】
2013521562.tif 000007
【図６】
2013521562.tif 000008
【図７】
2013521562.tif 000009
【図８】
2013521562.tif 000010
【図９Ａ】
2013521562.tif 000011
【図９Ｂ】
2013521562.tif 000012
【図１０Ａ】
2013521562.tif 000013
【図１０Ｂ】
2013521562.tif 000014
【図１１Ａ】
2013521562.tif 000015
【図１１Ｂ】
2013521562.tif 000016
【図１２Ａ】
2013521562.tif 000017
【図１２Ｂ】
2013521562.tif 000018
【図１３Ａ】
2013521562.tif 000019
【図１３Ｂ】
2013521562.tif 000020
【国際調査報告】
2013521562.tif 000021
2013521562.tif 000022