(57)【要約】  本発明は効率的に連絡先情報の購読招待をするための方法を提案する。そのために本発明は第１のクライアントで第１のクライアントの特定連絡先情報の購読招待を要請すれば、ＣＡＢサーバが特定連絡先情報に対して購読を許可する条件が含まれているかを判定して、上記条件が含まれた場合は、上記条件及び上記特定連絡先情報のアドレス情報を含む購読要請を第２のクライアントに送る過程で行われる。したがって多様な形態の通信サービスをサポートする通信システムにおいてリソース及び電力及びメモリを無駄にせず、高速で通信サービスを提供することができる。また、ユーザの意思選択によって容易かつ迅速にＣＡＢサービスが可能なデータ送受信方法を提供できる。
2015502613.tif 000002
【特許請求の範囲】
【請求項１】
統合アドレスブックサーバにおける連絡先情報の購読を招待する方法であって、
第１のクライアントから第１のクライアントの特定連絡先情報の購読招待要請を受信するステップと、
前記購読招待要請に前記特定連絡先情報に対して購読を許可する条件が含まれているかを判定して、前記条件が含まれた場合は、前記条件及び前記特定連絡先情報の提供を受けることができるアドレス情報を含む購読要請を第２のクライアントに送るステップと
を含むことを特徴とする統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項２】
前記購読招待要請は、
発信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）を通して受信されることを特徴とする請求項１に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項３】
前記第１のクライアントの全体連絡先情報のうち、前記条件を適用してフィルタリングされた特定連絡先情報を生成するステップをさらに含むことを特徴とする請求項１に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項４】
前記特定連絡先情報の提供を受けることができるアドレス情報を生成するステップをさらに含むことを特徴とする請求項１に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項５】
前記購読要請は、
ＨＴＴＰ ＰＯＳＴを利用して発信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）から連絡先伝送に対する前記第２のクライアントの選好度を確認する受信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）にフォワードされることを特徴とする請求項１に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項６】
前記第２のクライアントの選好度は、
前記連絡先伝送に対する受諾、拒否及び確認のうち何れか一つであることを特徴とする請求項５に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項７】
前記第２のクライアントの選好度が前記受諾である場合、
前記第２のクライアントに問うことなく前記アドレス情報を利用して、前記受信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）により前記発信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）からフェッチされた連絡先が記憶されることを特徴とする請求項６に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項８】
前記購読招待要請を受信すると、前記購読招待要請に含まれた前記第２のクライアントの情報及び前記条件に基づいて、前記第２のクライアントに対するアクセス権限文書を更新するステップをさらに含むことを特徴とする請求項１に記載の統合アドレスブックサーバにおける連絡先情報の購読を招待する方法。
【請求項９】
連絡先情報の購読を招待する統合アドレスブック文書管理サーバ（ＸＤＭＳ）であって、
第１のクライアントから第１のクライアントの特定連絡先情報の購読招待要請を受信すると、統合アドレスブックサーバに、前記特定連絡先情報に対して購読を許可する条件を含む連絡先共有要請を報告する統合アドレスブック機能駆動アプリケーション使用部と、
前記統合アドレスブックサーバにより前記条件でフィルタリングされた特定連絡先情報を記憶して、前記特定連絡先情報の提供を受けることができるアドレス情報を含む購読要請を第２のクライアントにフォワードする統合アドレスブック個人連絡カードアプリケーション使用部と
を含むことを特徴とする連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【請求項１０】
前記統合アドレスブック個人連絡カードアプリケーション使用部は、
前記第１のクライアントの全体連絡先情報のうち、前記条件を適用してフィルタリングされた特定連絡先情報を生成することを特徴とする請求項９に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【請求項１１】
前記統合アドレスブック個人連絡カードアプリケーション使用部は、
前記特定連絡先情報の提供を受けることができるアドレス情報を生成することを特徴とする請求項９に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【請求項１２】
前記購読要請は、
ＨＴＴＰ ＰＯＳＴを利用して連絡先伝送に対する前記第２のクライアントの選好度を確認する受信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）にフォワードされることを特徴とする請求項９に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【請求項１３】
前記第２のクライアントの選好度は、
前記連絡先伝送に対する受諾、拒否及び確認のうち何れか一つであることを特徴とする請求項１２に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【請求項１４】
前記第２のクライアントの選好度が前記受諾である場合、
前記第２のクライアントに問うことなく前記アドレス情報を利用して、前記受信側統合アドレスブック文書管理サーバ（ＸＤＭＳ）により前記統合アドレスブック個人連絡カードアプリケーション使用部からフェッチされた連絡先が記憶されることを特徴とする請求項１３に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【請求項１５】
前記統合アドレスブック個人連絡カードアプリケーション使用部は、
前記統合アドレスブックサーバにより、前記購読招待要請による第２のクライアントの連絡先購読許容のためのアクセス権限文書を更新して記憶することを特徴とする請求項９に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、統合アドレスブックサービス(Converged Address Book:ＣＡＢ)に関し、特に統合アドレスブックサービスに基づく連絡先情報の購読を招待する装置及び方法に関する。
【背景技術】
【０００２】
統合アドレスブック(Converged Address Book:ＣＡＢ)サービスは、ユーザが有する多様な端末で利用可能なアドレス情報を記憶して、この情報をいつ、どこでも、どの装置でもアクセス可能にしながら、アドレス情報を同期化する単一ネットワーク基盤のアドレスブックサービスである。このような統合アドレスブックサービスは、ネットワークに単一ネットワークアドレスブックを記憶することによってアドレスブックに対するユーザの経験と機能を向上させる目的で提供されているサービスである。このような統合アドレスブックサービスの主要機能としては、アドレスブック同期化、連絡先購読(Contact Subscription)、連絡先共有(Contact Share)、連絡先検索(Contact Search)、非統合アドレスブック(non-ＣＡＢ)システムから外部アドレスブックインポートなどがある。
【０００３】
その中でも連絡先購読機能の場合、発信側から受信側に自身の連絡先を購読するように招待する方法がある。そのために、従来には図１に図示されたように購読要請対象の情報を直接に受信側に伝達して記憶した後、連絡先状態情報を伝達する形態で実現される。
【０００４】
図１を参照すれば、ＣＡＢクライアントＡ１０は、ステップ１で購読招待要請(subscription invitation request)をＣＡＢサーバ２０に記憶すれば、ＣＡＢサーバ２０では、ＣＡＢクライアントＡ１０の連絡先情報をＣＡＢクライアントＢ６０のユーザＢが購読するように招待するために一連の動作を実行するようになる。しかし、従来にはＣＡＢクライアントＢ６０が購読を受諾するか否かに関係なく、ステップ４で、ＣＡＢクライアントＡ１０の全ての連絡先情報が一応ＣＡＢクライアントＢ６０が属したＣＡＢサーバに伝えられるようになる。ステップ５で購読を受諾した場合、ステップ６で、購読要請対象情報、すなわち、受信された全ての連絡先情報と購読招待が記憶されて、ステップ７でＣＡＢクライアントＢ６０のユーザＢは、ユーザＡがユーザＡの連絡先情報購読に対して招待することを認識するようになる。また、ステップ５で購読を受諾しない場合は受信された全ての連絡先情報を記憶しない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記した通り、ＣＡＢクライアントＡ１０は、ＣＡＢクライアントＢ６０がユーザＡの連絡先情報を購読するように招待するが、ステップ４ではユーザＡの全ての連絡先情報が伝えられるので、ユーザＡの立場では自身の連絡先情報のうち一部だけをユーザＢと共有しようとしてもそれをサポートする方法がない。その上、ＣＡＢクライアントＢ６０が購読招待を受諾または拒絶するかに関係なく、実際連絡先情報がユーザＡ側のＣＡＢサーバ２０からユーザＢ側のＣＡＢサーバ５０に伝えられるので、プロセシング容量の非効率性及びＣＡＢサーバ及びＣＡＢ ＸＤＭＳ内の不必要な記憶空間を消耗しなければならないので効率性側面でも望ましくない。
【０００６】
また、ＣＡＢクライアントＢ６０のユーザＢの立場では、ステップ５で、このような購読に対して拒絶を設定した場合、ＣＡＢクライアントＡ１０の連絡先情報の購読要請だけでなく他の全てのクライアントからの要請も一括的に拒絶される。すなわち、クライアント別に受諾または拒絶を設定できない。したがって、効率的に連絡先情報の購読招待ができる方法が要求される。
【課題を解決するための手段】
【０００７】
従って、本発明は、効率的に連絡先情報の購読招待ができる装置及び方法を提供する。
【０００８】
また、本発明は、連絡先情報のうち一分だけを選択的に購読するように招待する装置及び方法を提供する。
【０００９】
上記したことを達成するための本発明は、統合アドレスブックサーバにおける連絡先情報の購読を招待する方法であって、第１のクライアントから第１のクライアントの特定連絡先情報の購読招待要請を受信するステップと、上記購読招待要請に上記特定連絡先情報に対して購読を許可する条件が含まれているかを判定し、上記条件が含まれた場合は、上記条件及び上記特定連絡先情報の提供を受けることができるアドレス情報を含む購読要請を第２のクライアントに送るステップを含むことを特徴とする。
【００１０】
上記したことを達成するための本発明は、統合アドレスブックサーバにおける連絡先情報の購読を招待する方法であって、 第１のクライアントから第１のクライアントの特定連絡先情報の購読招待要請を受信すると、統合アドレスブックサーバに、上記特定連絡先情報に対して購読を許可する条件を含む連絡先共有要請を報告する統合アドレスブック機能駆動アプリケーション使用部と、
【００１１】
上記統合アドレスブックサーバにより上記条件でフィルタリングされた特定連絡先情報を記憶して、上記特定連絡先情報の提供を受けることができるアドレス情報を含む購読要請を上記第２のクライアントにフォワードする統合アドレスブック個人連絡カードアプリケーション使用部を含むことを特徴とする。
【発明の効果】
【００１２】
本発明によれば、本発明で提案したシステム及び方法を通して、ユーザにより効率的な連絡先情報の管理方法を提供できる。また、本発明は、発信側の立場では全体連絡先情報のうち希望の部分だけを購読することを要請でき、受信側立場では希望のクライアントの連絡先情報だけを選択的に提供を受けることができる。その上、実際の連絡先情報の代わりに連絡先情報に対するアドレス情報を伝達することで、伝送効率が増大する利点があるだけでなく、ＣＡＢサーバ及びＣＡＢ ＸＤＭＳの記憶効率を増大させるようになる。
【図面の簡単な説明】
【００１３】
【図１】従来の連絡先情報の購読招待方式を説明するための図である。
【図２】本発明の実施形態による連絡先情報の購読招待のためのシステム構成図である。
【図３】本発明の実施形態による連絡先情報の購読招待過程を示す図である。
【図４】図３の詳細過程を示す図である。
【図５】図３の連絡先共有要請メッセージの例示図である。
【図６】図３の受信者の購読許可のためのアクセス権限文書の例示図である、
【図７】図４のＸＤＣＰフォワード要請メッセージの例示図である、
【図８】図４のＸＤＣＰフォワード遠隔要請メッセージの例示図である、
【図９】本発明の実施形態による受諾状態である場合の連絡先情報の購読招待の過程を示す図である。
【図１０】図９の連絡先状態の例示図である。
【図１１】図９の要請通知リストの例示図である。
【発明を実施するための形態】
【００１４】
以下、本発明の望ましい実施形態を添付図面を参照して詳細に説明する。図面における同一構成要素はできるだけ同一符号で表していることに留意しなければならない。
【００１５】
また、本発明の要旨を不必要にすることができる公知機能及び構成に対する詳細な説明は省略する。
【００１６】
後述する詳細な説明では、詳述した技術的課題を解決するための本発明における代表的な実施形態提を示す。また、本発明の説明の便宜のために移動端末のアプリケーションの標準機構であるＯＭＡ(Open Mobile Alliance）のＣＡＢ(Converged Address Book)で定義している個体の名称を使用するが、このような標準及び名称は本発明の範囲を限定せず、類似の技術的背景を有するシステムに適用可能であることは明らかである。
【００１７】
本発明は、効率的に連絡先(contact)情報の購読招待をするための方法を提案する。そのために本発明は、第１のクライアントで第１のクライアントの特定連絡先情報の購読招待を要請すれば、ＣＡＢサーバが特定連絡先情報に対して購読を許可する条件が含まれているかを判定し、上記条件が含まれた場合は、上記条件及び上記特定連絡先情報のアドレス情報を含む購読要請を第２のクライアントに送るステップからなる。このようにすることで多様な形態の通信サービスをサポートする通信システムでリソースと電力及びメモリを無駄にすることなく、高速で通信サービスを提供できるようになる。また、ユーザの意思選択によって容易かつ迅速にＣＡＢサービスが可能なデータ送受信方法を提供できるようになる。
【００１８】
図１を通してＯＭＡ ＣＡＢの概念的な構造を説明すると、ＣＡＢサービスシステムは統合アドレスブック(以下、ＣＡＢ)クライアント１００、ＣＡＢサーバ１１０、ＣＡＢ文書管理サーバ(ＸＭＬ Document Management Server:ＸＤＭＳ）(以下、ＣＡＢ ＸＤＭＳ）１２０、非統合アドレスブック(以下、non-ＣＡＢ)システム１３０で構成される。
【００１９】
まず、ＣＡＢクライアント１００は、端末上でＣＡＢサーバ１１０と通信をしながらＣＡＢユーザ認証、個人連絡カード情報(Personal Contact Card:以下、「ＰＣＣ」と称する)とネットワーク記憶空間に記憶された統合アドレスブックの同期化、そしてＣＡＢユーザの要求事項、例えば、アドレス購読(subscription)、アドレス検索、アドレス共有、既存アドレスブックとの相互作用またはユーザ選好度の管理などをＣＡＢサーバ１１０に伝送する役割を担当する。
【００２０】
特に本発明の実施形態によるＣＡＢクライアント１００は、ユーザＡの端末を意味し、ユーザＡの要請によってユーザＡ保有の連絡先情報に対する購読をユーザＢに勧誘するための連絡先共有要請を伝送する役割をする。このような連絡先共有要請には個人情報（ＰＣＣ）のうち連絡先ビュー(contact view）の一部分を許可するための条件としてフィルタ値が含まれる。このような連絡先共有要請は、ユーザＢにユーザＡの一部連絡先情報を購読することを要請する意味であり、特に購読要請する一部連絡先情報が何であるかを報告するためにフィルタ値が含まれることができる。
【００２１】
ここで、本発明の実施形態による連絡先情報はアドレスブック、名刺情報、個人情報（ＰＣＣ）のうち少なくとも一つを含み、このような連絡先ビューは、個人情報のうちユーザが必要によって、例えば、名前、電話番号、イメールなどの一部情報を一つのグループとして結ぶことを意味する。すなわち、全体連絡先情報のうち共有のために一部を選択的に抽出してサブセット(subset)として作ったことを意味する。
【００２２】
ＣＡＢサーバ１１０は、ＣＡＢ構造で主要なネットワーク構成要素として、ＣＡＢクライアント１００からＣＡＢユーザの要請事項を受けて処理する役割を担当する。ＣＡＢサーバ１２０の主要機能としては、ＣＡＢクライアント相互認証、ＣＡＢアドレスの記憶、アドレス情報同期化、アドレス購読機能からのアドレス情報更新を受けてアドレスブックに反映する役割がある。
【００２３】
ＣＡＢサーバ１１０は、アドレス購読/共有/変換及びユーザの選好度/ポリシーなどを反映するネットワーク運営に対する動作を実行する。また、既存アドレスブックシステムと連係または外部イネーブラにインターフェースを露出するインターワーキング機能(ＩＷＦ)などの機能を有する。
【００２４】
このようなＣＡＢサーバ１１０は、ＣＡＢクライアント１００から連絡先情報の選択的な購読許容のためのフィルタ値を含む連絡先共有要請を受信する。そして、ＣＡＢサーバ１１０はこのようなフィルタ値によって選択されたＣＡＢクライアント１００の特定連絡先情報の提供を受けることができるアドレス情報を生成する。このように新しく生成されたアドレス情報を含む要請はユーザＡが属したＣＡＢサーバ(例えば、ＸＤＭＳ１３０)を通してユーザＢが属したＣＡＢサーバ(例えば、ＸＤＭＳ１４０)に伝えられるようになる。このようにＣＡＢサーバ１１０では伝送負荷量を削減するように実際連絡先情報の代わりに連絡先情報の提供を受けることができるアドレス情報、例えば、ＵＲＬ情報を新しく生成して提供する役割をする。
【００２５】
ユーザのデータを管理するＣＡＢ ＸＤＭＳ１２０には、統合アドレスブック及び既存ユーザとＣＡＢユーザを区分するための連絡先状態を記憶する統合アドレスブックアプリケーション使用部(ＣＡＢ ＡＢ App(Address Book Application)Usage)、ユーザの選好度を記憶する統合アドレスブックユーザ選好度アプリケーション使用部(ＣＡＢ ＵＰ App((User Preference Application)Usage)、個人連絡カード情報を記憶する統合アドレスブック個人連絡カードアプリケーション使用部(ＣＡＢ ＰＣＣ App(Personal Contact Card Application)Usage)及びＣＡＢサービス要請及び応答を管理する統合アドレスブック機能駆動アプリケーション使用部(ＣＡＢ FH App(Feature Handler Application)Usage)などがある。以外に多様なアプリケーション使用部(App Usage)機能にアクセスするためのＸＤＭＣ、外部ドメインのエンティティとのメッセージルーティングのためのＳＩＰ／ＩＰコアネットワーク、non-SIP端末の通知メッセージ伝達のためのＰＵＳＨイネーブラなどがある。
【００２６】
本発明の実施形態では、図２の統合アドレスブックシステム内の連絡先情報、例えば、個人プロファイル情報(ＰＣＣ information)に対して他のユーザに個人プロファイル情報を購読するように招待しようとする場合、定型化された招待メッセージ(例えば、「連絡先購読招待」(contact subscription invitation))を含む連絡先共有を要請する新規スキーマ(schema)をＣＡＢ Feature Handler App.Usage内で定義する。一方、ＣＡＢサーバ１１０では、該当連絡先共有要請に対して受信者の個人プロファイル情報購読のための権限を許可して、該当連絡先共有要請を受信側に伝送し、受信者が設定していた他人の購読要請に関するユーザ選好度、すなわち受諾、拒否及び確認によって該当個人プロファイル情報購読招待を含む連絡先共有要請を処理することで、最終的に連絡先状態情報の形態で受信者に連絡先情報購読を招待する方法を提案するものである。ここで、ユーザ選好度確認は、他人の購読要請に対して受信者に購読要請事実を通知して受諾するか否かを聞くように設定したことを意味する。
【００２７】
これを具体的に説明するために、本発明の実施形態による連絡先情報の購読招待過程を示した図３を参照して説明する。図３では、ＸＭＬ文書伝送を通した連絡先情報の購読招待方法を例示している。
【００２８】
図３を参照すれば、ステップ３００で、ＣＡＢクライアントＡ１００は、連絡先共有要請をＣＡＢ ＸＤＭＳ１３０内のＣＡＢ Feature Handler App.Usageに送る。この時、連絡先共有要請のためにＸＣＡＰ(ＸＭＬ Configuration Access Protocol)リクエストが使用される。このような連絡先共有要請は、個人情報（ＰＣＣ）のうち特定連絡先ビューに対して受信者、例えば、(ＸＵＩ:sip:bob@example.com)に連絡先情報の購読招待のための定型化された招待メッセージと、連絡先ビューに一部分だけの購読を許可するための選択的なフィルタ値を含む。また定型化された招待メッセージは、受信者の上記連絡先情報の購読招待メッセージを受信したサーバで自動的に生成できることは明らかである。
【００２９】
これに対応して、ステップ３０５で、ＣＡＢ ＸＤＭＳ１３０は、連絡先共有要請を報告する。そのためにＣＡＢ ＸＤＭＳ１３０内のＣＡＢ Feature Handler App.UsageはＣＡＢ Feature Handlerの文書変更(document change)すなわち、連絡先共有要請に対する文書更新情報をＣＡＢサーバ１１０内の連絡先共有機能部(Contact Share  function)１０５に報告する。
【００３０】
ステップ３１０で、ＣＡＢサーバ１１０は、受信者に対するアクセス権限文書をアップデートする。具体的に、ＣＡＢ ＸＤＭＳ１２０内のＰＣＣ App.Usageに発信者の連絡先情報の購読招待による受信者の購読許可のために、ステップ６０５で獲得した連絡先共有要請に対する文書更新情報に基づいてアクセス権限(Access Permission)文書を更新する。この時、連絡先情報購読制限のために含まれたフィルタ情報は、アクセス権限文書にも反映される。これは、予め、受信者、例えば、ユーザＢが発信者、例えば、ユーザＡの連絡先情報を購読できるように認証する過程に該当する。ＣＡＢサーバ１１０は、ユーザＡの複数の受信者に対して連絡先情報から異なる複数の購読許可要請を受けることができ、これを管理する役割、すなわち、ユーザＡに対して複数の購読許可要請に対して生成、更新、削除などを実行することができる。
【００３１】
続いて、ＣＡＢサーバ１１０は、ステップ３１５で要請をフォワードする。このような要請の伝達のためにＣＡＢサーバ１１０は、ＸＤＣＰフォワードリクエストを生成してこれを利用する。このようなＸＤＣＰフォワードリクエストは、連絡先情報の購読招待のための定型化されたメッセージと連絡先ビューに一部分だけを購読許可するためのフィルタ値を含む。特にＣＡＢサーバ１１０は、このような特定連絡先情報の提供を実際に受けることができるＵＲＬ情報を生成して、これを上記フォワードリクエストに含めて伝送する。このように、本発明では、従来の「ＳＩＰメッセージ」の代わりに「ＨＴＴＰ ＰＯＳＴ」を利用するので、実際連絡先情報を送る代わりに連絡先情報の提供を受けられる情報だけを送ることができるだけでなく、フィルタ値を通して部分的な連絡先情報を提供することも可能である。
【００３２】
このようなＸＤＣＰフォワードリクエストは、ＣＡＢ ＸＤＭＳ１２０内のＰＣＣ App.Usageに伝えられ、発信者すなわち、ユーザＡが購読招待のために指定した特定連絡先ビューに対して一部分だけを購読許可するための上記フィルタを適用して新しい連絡先ビューを生成した後、これを一時記憶空間またはＰＣＣ App.Usage内の別途の文書記憶空間に記憶する。続いて、ＣＡＢ ＸＤＭＳ１２０は、ステップ３２０で、上記文書に対するＵＲＩ値と連絡先情報の購読招待のための定型化されたメッセージを含む遠隔要請をフォワードする。また、全体連絡先情報から上記フィルタを適用して特定連絡先ビューのみが特定受信者に見えるようにＵＲＩ値を生成することができる。このような遠隔要請のためにＸＤＣＰフォワードリモートリクエストが使用される。
【００３３】
このようなＸＤＣＰフォワードリモートリクエストは、受信側、すなわち、ユーザＢが属したＣＡＢ ＸＤＭＳ１３０に伝えられる。そして、ステップ３２５で、ＣＡＢ ＸＤＭＳ１３０のＰＣＣ App.Usageは、受信したＸＤＣＰフォワードリモートリクエストに基づいて遠隔要請を処理する。すなわち、ＣＡＢ ＸＤＭＳ１３０は、ユーザＢのアドレスブック文書伝送に関する選好度確認を実行する。アドレスブック文書伝送に関する選好度には、受諾、拒否及び確認などの設定があり得る。受諾は、ユーザＢが他人の購読要請がある時にユーザＢに問うことなく、直接に受けた文書を記憶するという意味であり、拒否は、他人の購読要請を受諾しないという意味であり、確認は、ユーザＢに他人の購読要請を報告して、ユーザＢから購読要請に対する応答(例えば、受諾あるいは拒否）を受信して処理することを意味する。したがって、選好度が受諾である場合にユーザＡ側から受信された文書のＵＲＩ値を利用して連絡先情報の購読招待に使用される文書が記憶されているサーバからフェッチして(Fetch)一時文書、例えば、ContactInvitationPCC.xml形態で記憶する。
【００３４】
ステップ３３０で、受信側ＣＡＢサーバ１４０は、ＣＡＢ ＸＤＭＳ１３０のＰＣＣ App.Usageから一時文書の通知を受ける。具体的に、一時文書である「ContactSharePCC.Xml」及び上記「note」エレメントを含む連絡先招待文書(Contact Invitation document)を文書変更として通知を受けたり、「ContactInvitationPCC.Xml」及び上記「note」エレメントを含む連絡先招待文書(Contact Invitation document)を文書変更として通知を受けることがある。
【００３５】
ステップ３３５で、ＣＡＢサーバ１４０は、連絡先エントリーを記憶する。このような連絡先エントリーの例としてはアドレスがあり、このようなアドレス共有データをアドレスブックフォーマットに整合するように変換した後、これをＣＡＢ ＸＤＭＳ１３０のＡＢ App.Usage内のアドレスブック文書(ＡＢ document)内に追加する。また、ステップ３３０での連絡先招待文書(Contact Invitation document)を参照してそれに対する連絡先状態(contact status)としてのアドレスタイプとエントリー状態としての更新形態(＜updated＞)と、発信者から伝えられた連絡先情報の購読招待のための定型化されたメッセージ(または表現)である＜note＞エレメントなどを表示する。
【００３６】
以後、ＣＡＢサーバ１４０は、ステップ３４０でＣＡＢクライアントＢ１５０のアドレスブック同期化のために、ＡＢ App.Usageに発生した文書変更を含むサーバ報告メッセージを送る。こうすることで、ＣＡＢクライアントＢ１５０のユーザＢは、アドレスブック同期化を通してユーザＡで購読を許可した連絡先情報を見ることができる。
【００３７】
以下、図３をより具体的に説明するために図４を参照する。図４は、発信側での連絡先情報共有のための詳細内容を例示している。
【００３８】
図４を参照すれば、ステップ４００は、図３のステップ３００と同一であり、より詳細に説明すると、連絡先共有要請にはこのような共有要請に対する結果報告及びその共有要請内の「note」エレメントに「contact subscription invitation」という連絡先情報の購読招待のための定型化されたメッセージが含まれる。このような連絡先共有要請のためのメッセージを例示すれば図５の通りである。
【００３９】
図５を参照すれば、上記「note」エレメントに「contact subscription invitation」という定型化されたメッセージは、以後、発信側及び受信側で連絡先共有要請が発信者の連絡先情報の購読招待のための連絡先共有要請であることを表す指示(indication)役割をする。また、図５では「invite-include」というフィルタＩＤを通して発信者の連絡先情報のうち名前(name)、連絡先(comm-addr)、経歴(career-history)だけを最終的に受信者(ＸＵＩ:sip:bob@example.com)が連絡先情報の購読招待に応じて発信者の連絡先情報購読を試す場合、購読するか又は読むことができるように該当文書の一部値だけを購読許可するためのフィルタ値を設定した場合を例示している。
【００４０】
ステップ４０５で、ＣＡＢ ＸＤＭＳ１２０のＣＡＢ Feature Handler App.Usageは、伝達を受けたＸＣＡＰ requestを記憶して応答メッセージ（２００ ＯＫ）をＣＡＢクライアントＡ１００に送る。
【００４１】
ステップ４１０で、ＣＡＢ Feature Handler App.Usageは、ＣＡＢ Feature Handlerの文書変更、すなわち、該当連絡先共有要請に対する文書更新情報をＣＡＢサーバ１１０内の連絡先共有機能部(Contact Share function)１０５に報告する。ここでは、ＣＡＢ Feature Handler App.Usageが変更情報を通知することとは別途に、連絡先共有機能部１０５により能動的に連絡先共有要請メッセージが記憶されているか否かを確認して、ＣＡＢ Feature  Handler内の変更情報を獲得することができる。
【００４２】
これに対応して、ステップ４１５で、連絡先共有機能部１０５は、応答メッセージ（２００ ＯＫ）をＣＡＢ Feature Handler App.Usageに送る。続いて、ステップ４２０は、図３のステップ３１０と同一である。より詳細に説明すると、連絡先共有機能部１０５はＸＤＭエージェントを用いて、該当ＰＣＣ App.Usage内の発信者の連絡先情報の購読招待による受信者の購読許可のために、ステップ４１０で獲得した連絡先共有要請に対する文書更新情報内の受信者情報及び連絡先情報購読制限のために含まれたフィルタ情報に基づいてアクセス権限(Access Permission)文書を更新する。
【００４３】
図６では、ＰＣＣ App.Usage内の連絡先情報の購読招待による受信者の購読許可のためのアクセス権限文書の例示を示す。
【００４４】
図６を参照すれば、発信者(ＸＵＩ:sip:alice@example1.com）の連絡先情報のうち個人情報（ＰＣＣ）に対した文書ルール(document-rule)である「allow-retrieve」の場合は、発信者の連絡先情報全体を受信者が購読するか又は読むことができるという意味である。また、ステップ４１０で獲得した連絡先共有要請に対する文書更新情報内受信者(ＸＵＩ:sip:bob@example.com)情報及び連絡先情報購読制限のために含まれたフィルタ情報(「invite-include」)に基づいてアクセス権限(Access Permission)文書を更新することによって、発信者の個人情報のうち名前(name)、連絡先(comm-addr)、経歴(career-history)だけが、最終的に受信者が連絡先情報の購読招待に応じて発信者の連絡先情報購読を試す場合に購読するか又は読むことができるように許可される。
【００４５】
ステップ４２５で、連絡先共有機能部１０５は、応答メッセージ（２００ ＯＫ）をＰＣＣ App.Usageから受信した後、ステップ４３０で、ＸＤＭエージェントで、該当ＰＣＣ App.Usageに連絡先情報を共有するためにＸＤＣＰフォワードリクエストを生成して伝送する。この時、ステップ４１０で獲得した連絡先ビューに一部値だけを購読許可するためのフィルタ情報を含める。また、ＸＤＣＰフォワードリクエスト内の「note」エレメントに「contact subscription invitation」という連絡先情報の購読招待のための定型化されたメッセージ(または表現)も含める。このような連絡先共有機能部１０５で生成したＸＤＣＰフォワードリクエストを図７に例示する。
【００４６】
続いて、ステップ４３５でＰＣＣ App.Usageは、優先的に発信者の連絡先共有に対する伝送報告(Contact Share Delivery Report)が要請されたか否かを確認する。続いて、伝送結果を発信者に通知するためにList ＸＤＭＳのForward Notification List(以下、「ＦＮＬ」)App.Usage内の伝達通知リスト(＜forward-notification-list＞)エレメントの伝送通知リスト(＜delivery-notification-list＞)エレメントに上記「note」エレメントを含んで該当受信者の伝送状態値を「伝送中(pending)」として関連情報を更新する。これに対応してステップ４４０でＰＣＣ App.Usageは応答メッセージ（２００ ＯＫ）をList ＸＤＭＳ１２５から受信する。
【００４７】
そしてＰＣＣ App.Usageは上記ＸＤＣＰフォワードリクエストに基づいて、受信者が異なるドメインのユーザであることを確認し、発信者が購読招待のために指定した特定連絡先ビューに対して一部値だけを購読許可するための上記フィルタを適用した後、これを一時記憶空間またはＰＣＣ App.Usage内の別途の文書記憶空間に記憶する。
【００４８】
すると、ステップ４４５でその文書に対するＵＲＩ値と個人情報の購読招待のための定型化されたメッセージを含むＸＤＣＰフォワードリモートリクエストを受信側に送る。このような発信側ＰＣＣ App.Usageが生成するＸＤＣＰフォワードリモートリクエストを図８に図示する。以後、ステップ４５０でＰＣＣ App.Usageは受信側ネットワーク１２７＆１２９から伝送結果に対する応答メッセージ（２００ ＯＫ）を受信する。すると、ステップ４５５でＰＣＣ App.Usageは伝送結果に対する応答メッセージ（２００ ＯＫ）からＸＤＣＰフォワードリクエストに対する応答メッセージ（２００ ＯＫ）を生成する。
【００４９】
以後、連絡先共有機能部１０５はステップ４６０でフォーワーディング結果を記憶する。すなわち、ＣＡＢ Feature Handler App.Usageに伝送結果を記憶して、ステップ４６５でＣＡＢ Feature Handler App.Usageは応答メッセージ（２００ ＯＫ）を連絡先共有機能部１０５に送る。
【００５０】
ステップ４７０で、ＰＣＣ App.Usageは、受信側ネットワーク１２７＆１２９から連絡先共有伝送報告(Contact Share Delivery Report)を受信する。これに対する応答で、ステップ４７５でＰＣＣ App.Usageは受信側ネットワーク１２７＆１２９に応答メッセージ（２００ ＯＫ）を伝送する。
【００５１】
すると、ＰＣＣ App.Usageは、ステップ４８０で、フォワード通知リストをアップデートする。具体的に伝送結果を受信者に通知するためにList ＸＤＭＳのForward Notification List(以下、「ＦＮＬ」)App.Usage内の伝達通知リスト(＜forward-notification-list＞)エレメントの伝送通知リスト(＜delivery-notification-list＞)エレメントに該当受信者の伝送状態値を「伝送完了(delivered)」として関連情報を更新する。このような更新が完了すれば、ステップ４８５で、ＰＣＣ App.Usageは、応答メッセージ（２００ ＯＫ）をList ＸＤＭＳ１２５から受信する。
【００５２】
以後、ステップ４９０でＣＡＢサーバ１２０内のＸＤＭエージェントは伝送報告に対する結果の通知を受けてＣＡＢ ＦＨ App.Usage内の該当連絡先共有要請の伝送状態を更新する。
【００５３】
一方、図９では、受信者のＸＭＬ文書伝送に対するユーザ選好度を受諾(accept)に設定した場合に対して個人情報購読を招待する方法の詳細内容を例示している。
【００５４】
図９を参照すれば、ステップ９００でＣＡＢクライアントＢ１５０が属したＰＣＣ App.Usageは発信側ネットワーク１２７＆１２９からＸＤＣＰフォワードリモートリクエストを受信する。すると、ステップ９０５で、ＰＣＣ App.Usageは、ＸＤＣＰフォワードリモートリクエスト内の受信者が該当ドメイン内にあるかを確認後に応答メッセージ（２００ ＯＫ）をＣＡＢクライアントＡ１００が属したＰＣＣ App.Usageに送る。
【００５５】
続いて、ステップ９１０で、ＣＡＢ ＸＤＭＳ１３０のＰＣＣ App.Usageは、ＡＢ App.Usage内のＡＢフォワード選好度からＸＤＣＰフォワードリモートリクエストに対するＣＡＢクライアントＢ１５０の選好度を確認する。ＡＢフォワード選好度には次の３種類の場合があり、ここではＣＡＢクライアントＢ１５０がＣＡＢクライアントＡ１００から受信したＸＤＭリソースを受信する(accept)場合を示す。
【００５６】
選好度が受諾(accept)である場合は、ステップ９１５で、発信側から転送されたＸＤＭリソースを該当ＸＤＭサーバに自動的に記憶する。一方、選好度が確認(confirm)である場合は、発信側から転送されたＸＤＭリソースを受信者に報告した後、それに対する決定を待つ。しかし選好度が拒絶(reject)である場合には発信側から転送されたＸＤＭリソースを該当ＸＤＭサーバが記憶せず拒絶する。その上、選好度が拒絶である場合にはステップ９２０以降の段階は実行しない。
【００５７】
具体的に、受信側ＰＣＣ App.Usageは、ＸＤＣＰフォワードリモートリクエストに含まれた文書ＵＲＩすなわち、購読招待のために発信者が指定した特定連絡先ビューに対して一部値だけを購読許可するために、発信者が設定したフィルタ値を適用して、発信側ＰＣＣ App.Usage内の一時記憶空間または別途記憶空間に記憶された文書のＵＲＩを利用してＸＤＭリソースを発信側ＰＣＣ App.Usageからフェッチする。そして、既存アドレス共有要請の方法で示す「ContactSharePCC.Xml」形態の文書で記憶するか、又はＸＤＣＰフォワードリモートリクエストに含まれた「note」エレメントに「contact subscription invitation」という個人情報の購読招待のための定型化されたメッセージ(または、表現)を確認して「ContactInvitationPCC.Xml」のような新規形態の文書で記憶する。例えば、「ContactSharePCC.Xml」の形態で記憶することがある。
【００５８】
続いて、ステップ９２０で、ＣＡＢサーバ１４０は、受信側ＰＣＣ App.Usageから一時文書の通知を受ける。具体的には、「ContactSharePCC.Xml」及び上記「note」エレメントを含むContactInvitation documentを文書変更として通知を受けたり、「ContactInvitationPCC.Xml」及び上記「note」エレメントを含むContactInvitation  documentを文書変更として通知を受ける。併せて、システム実現によっては、前述した「note」エレメントを含むContact Invitation documentを別途に生成して含むことなく通知要請メッセージ(SIPNOTIFY)内の新規ヘッダー形態で含めることができる。例えば、「ContactSharePCC.Xml」及びContact Invitation document形態で文書変更の通知を受けるようにする。ＣＡＢサーバ１４０が受信側ＰＣＣ App.Usageから上記情報を通知されるのとは別途に、能動的に受信側ＰＣＣ App.Usage内の該当文書の変更情報を獲得することができる。
【００５９】
これに対応してＣＡＢサーバ１４０は、ステップ９２５で応答メッセージ（２００ ＯＫ）をＰＣＣ App.Usageに送った後、ステップ９３０でアドレスブックをアップデートする。具体的に、ＣＡＢサーバ１４０は連絡先情報共有データをＡＢフォーマットに変換した後、これをＡＢ App.Usage内のＡＢ document内に追加する。その後、連絡先招待文書(Contact Invitation document)または通知要請メッセージ内に含まれた「note」関連ヘッダーを参照してそれに対する連絡先状態(contact status)として下記のようにアドレスタイプとエントリー状態として更新形態(＜updated＞)と、発信者から伝えられた個人情報の購読招待のための定型化されたメッセージ(または表現)である＜note＞エレメントなどを表示する。
【００６０】
このような連絡先状態を図１０に例示する。図１０ではＡＢ document内の連絡先共有データとともに連絡先情報の購読招待のために追加される連絡先状態を例示している。
【００６１】
以後、ステップ９３５で、ＡＢ App.Usageは応答メッセージ（２００ ＯＫ）をＣＡＢサーバ１４０に送る。
【００６２】
ステップ９４０で、ＰＣＣ App.Usageは受信したＸＤＣＰフォワードリモートリクエストの詳細事項を受信者に通知するために、List ＸＤＭＳ１３２のForward Notification List内の＜request-notification-list＞エレメントを追加する。この時、連絡先情報の共有要請内の連絡先情報の購読招待のための定型化されたメッセージ(または、表現)である「note」エレメントを一緒に記憶する。このようなList ＸＤＭＳ１３２のForward Notification List内の「note」エレメントを含む＜request-notification-list＞エレメントを図１１に例示する。
【００６３】
図１１のRequest Notification Listの例示で見られるように、受信者は、該当Request Notification Listを通して発信者(ＸＵＩ:sip:alice@example1.com)の情報及び連絡先情報の購読招待のための定型化されたメッセージ(または、表現)などを確認することができる。ここでは、List ＸＤＭＳ１３２の該当Request Notification List変更情報を受信者に通知することと受信者が能動的にList ＸＤＭＳ１３２の該当Request Notification Listを確認しList ＸＤＭＳ１３２の該当Request Notification List変更情報を獲得することができる。
【００６４】
ステップ９４５でList ＸＤＭＳ１３２は、応答メッセージ（２００ ＯＫ）をＰＣＣ App.Usageに送る。続いて、ステップ９５０で、ＣＡＢ ＸＤＭＳ１３０は、連絡先共有伝送報告(Contact Share Delivery Report)を生成して発信側ネットワーク１２７＆１２９に伝送する。これに対応してＣＡＢ ＸＤＭＳ１３０は、ステップ９５５で、発信側ネットワーク１２７＆１２９から応答メッセージ（２００ ＯＫ）を受信する。
【００６５】
以後、ステップ９６０で、ＣＡＢサーバ１４０は、ＣＡＢクライアントＢ１５０のアドレスブック同期化のためにＡＢ App.Usageに発生した文書変更を含むサーバ報告メッセージをＣＡＢクライアントＢ１５０に送る。
【００６６】
追加的に受信側の発信側の購読招待を確認した後、これを受諾して購読する場合は、以後の連絡先情報購読過程は一般的な手順によって進行される。ただし、このような場合は、発信者のＰＣＣ App.Usage内の既に設定されたアクセス権限すなわち、図４のステップ４２０で「invite-include」というフィルタＩＤを通して発信者の連絡先情報のうち名前(name)、連絡先(comm-addr)、経歴(career-history)だけを最終的に受信者(ＸＵＩ:sip:bob@example.com)が連絡先情報の購読招待に応じて発信者の連絡先情報購読を試す場合に購読するかまたは読むことができるように設定したので、連絡先情報購読結果の通知を受けるようになり、ユーザ選好度によって連絡先情報を更新するようになるはずである。
【００６７】
そして、受信側ＸＭＬ文書伝送に対するユーザ選好度が受諾(accept)ではなく、確認(confirm)である場合には、ＡＢ App.Usageに受信したＡＢ documentを追加して連絡先状態を「temporary」にしてＣＡＢクライアントＢ１５０のアドレスと同期化した後、受信者が直接にこれに対する確認意思を表示して「temporary」を除去することで連絡先共有が完了する。
【００６８】
また、本発明では、連絡先共有要請をＣＡＢ ＦＨ App.Usageを通してＣＡＢサーバに伝達して個人情報の購読招待方法を実現したが、システム実現によって、そうでない場合すなわち、ＣＡＢクライアントとＣＡＢ ＸＤＭＳ間のＸＤＭ文書伝送要請/応答のための直接インターフェースがあり、これを通じて連絡先共有要請がＸＤＭ文書伝送の形態でＣＡＢ ＸＤＭＳに伝えられる統合アドレスブックシステムの下では、上記の例題が一般的なＸＤＭ文書管理の機能実現の許容範囲内で修正されて行われることができるが全体的な動作及び方法は、本発明の範囲内で同様である。
【００６９】
最後に本発明では、異なるドメインユーザ間の連絡先情報の購読招待方法を実現したが、同一ドメインユーザとの間の連絡先情報の購読招待方法においても同一ドメイン内ＣＡＢサーバ及びＣＡＢＸＭＤＳで一般的なＸＤＭ文書管理の機能実現の許容範囲内で上記で示した異なるドメインユーザ間の連絡先情報の購読招待方法が一部修正されて行われることができるが全体的な動作及び方法は本発明の範囲内で同様である。
【符号の説明】
【００７０】
１００  ＣＡＢクライアントＡ
１１０，１４０  ＣＡＢサーバ
１２０，１３０  ＣＡＢ  ＸＤＭＳ
１５０  ＣＡＢクライアントＢ
【図１】
2015502613.tif 000003
【図２】
2015502613.tif 000004
【図３】
2015502613.tif 000005
【図４】
2015502613.tif 000006
【図５】
2015502613.tif 000007
【図６】
2015502613.tif 000008
【図７】
2015502613.tif 000009
【図８】
2015502613.tif 000010
【図９】
2015502613.tif 000011
【図１０】
2015502613.tif 000012
【図１１】
2015502613.tif 000013
【国際調査報告】
2015502613.tif 000014
2015502613.tif 000015
2015502613.tif 000016