JP6254530B2

JP6254530B2 - 連絡先情報の購読を招待する装置及び方法

Info

Publication number: JP6254530B2
Application number: JP2014545826A
Authority: JP
Inventors: ギュ−ボン・オ; ウク・キム; キュン−タク・イ
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2011-12-08
Filing date: 2012-12-07
Publication date: 2017-12-27
Anticipated expiration: 2032-12-07
Also published as: CN103988468A; US10795963B2; WO2013085342A1; JP2015502613A; CN103988468B; KR20130082561A; EP2789122B1; KR101922985B1; US20140344215A1; EP2789122A1; EP2789122A4

Description

本発明は、統合アドレスブックサービス(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を通してＣＡＢサーバに伝達して個人情報の購読招待方法を実現したが、システム実現によって、そうでない場合すなわち、ＣＡＢクライアントとＣＡＢＸＤＭＳ間のＸＤＭ文書伝送要請/応答のための直接インターフェースがあり、これを通じて連絡先共有要請がＸＤＭ文書伝送の形態でＣＡＢＸＤＭＳに伝えられる統合アドレスブックシステムの下では、上記の例題が一般的なＸＤＭ文書管理の機能実現の許容範囲内で修正されて行われることができるが全体的な動作及び方法は、本発明の範囲内で同様である。

最後に本発明では、異なるドメインユーザ間の連絡先情報の購読招待方法を実現したが、同一ドメインユーザとの間の連絡先情報の購読招待方法においても同一ドメイン内ＣＡＢサーバ及びＣＡＢＸＭＤＳで一般的なＸＤＭ文書管理の機能実現の許容範囲内で上記で示した異なるドメインユーザ間の連絡先情報の購読招待方法が一部修正されて行われることができるが全体的な動作及び方法は本発明の範囲内で同様である。

１００ＣＡＢクライアントＡ
１１０，１４０ＣＡＢサーバ
１２０，１３０ＣＡＢＸＤＭＳ
１５０ＣＡＢクライアントＢ

Claims

第１のクライアントが属する統合アドレスブック(Converged Address Book:ＣＡＢ)文書管理サーバ(ＸＭＬ Document Management Server:ＸＤＭＳ）における連絡先情報の購読を招待する方法であって、
前記第１のクライアントの連絡先ビューの一部に対する購読のために第２のクライアントを招待する連絡先共有要請を前記第１のクライアントから受信するステップと、
前記連絡先共有要請を前記第１のクライアントが属するＣＡＢサーバに報告するステップと、
前記連絡先共有要請の報告に対応して、前記ＣＡＢサーバによりアップデートされる前記第２のクライアントによる前記連絡先ビューの一部に対する購読を受諾するためのアクセス権限(Access Permission)文書を記憶するステップと、
前記ＣＡＢサーバから連絡先共有のためのフォワード要請を受信するステップと、
前記第２のクライアントが属するＣＡＢＸＤＭＳに連絡先共有のための遠隔要請をフォワードするステップと、を含み、
前記連絡先共有要請は、前記連絡先ビューの一部に対する購読を許可する条件及び前記第２のクライアントを招待するための招待メッセージを含み、
前記遠隔要請は、前記連絡先ビューの一部を受信することができるアドレス情報を含み、前記第２のクライアントが属するＣＡＢＸＤＭＳが前記第２のクライアントのアドレスブック文書伝送に関する選好度確認を実行し、その選好度確認結果によって前記アドレス情報に基づいて連絡先情報の購読招待に使用される文書を記憶するようにするための要請であることを特徴とする方法。
前記アクセス権限文書は、
前記第１のクライアントの連絡先情報をフィルタリングするための情報を含むことを特徴とする請求項１に記載の方法。
前記第１のクライアントの全体連絡先情報のうち、前記条件を適用してフィルタリングされた特定連絡先情報を生成するステップをさらに含むことを特徴とする請求項１に記載の方法。
前記連絡先ビューの一部を受信することができるアドレス情報を生成するステップをさらに含むことを特徴とする請求項１に記載の方法。
前記フォワード要請は、
ＨＴＴＰＰＯＳＴを利用して前記ＣＡＢサーバにより生成されてフォワードされることを特徴とする請求項１に記載の方法。
連絡先情報の購読を招待する第１のクライアントの統合アドレスブック(Converged Address Book:ＣＡＢ)文書管理サーバ(ＸＭＬ Document Management Server:ＸＤＭＳ）であって、
前記第１のクライアントから前記第１のクライアントの連絡先ビューの一部に対する購読のために第２のクライアントを招待する連絡先共有要請を受信し、前記連絡先共有要請を前記第１のクライアントが属するＣＡＢサーバに報告する統合アドレスブック機能駆動アプリケーション使用部と、
前記連絡先共有要請の報告に対応して、前記ＣＡＢサーバによりアップデートされる前記第２のクライアントによる前記連絡先ビューの一部に対する購読を受諾するためのアクセス権限(Access Permission)文書を記憶し、前記ＣＡＢサーバから連絡先共有のためのフォワード要請を受信し、前記第２のクライアントが属するＣＡＢＸＤＭＳに連絡先共有のための遠隔要請をフォワードする統合アドレスブック個人連絡カードアプリケーション使用部と、を含み、
前記連絡先共有要請は、前記連絡先ビューの一部に対する購読を許可する条件及び前記第２のクライアントを招待するための招待メッセージを含み、
前記遠隔要請は、前記連絡先ビューの一部を受信することができるアドレス情報を含み、前記第２のクライアントが属するＣＡＢＸＤＭＳが前記第２のクライアントのアドレスブック文書伝送に関する選好度確認を実行し、その選好度確認結果によって前記アドレス情報に基づいて連絡先情報の購読招待に使用される文書を記憶するようにするための要請であることを特徴とする連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
前記アクセス権限文書は、
前記第１のクライアントの連絡先情報をフィルタリングするための情報を含むことを特徴とする請求項６に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
前記統合アドレスブック個人連絡カードアプリケーション使用部は、
前記連絡先ビューの一部を受信することができるアドレス情報を生成することを特徴とする請求項６に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
前記フォワード要請は、
ＨＴＴＰＰＯＳＴを利用して前記ＣＡＢサーバにより生成されてフォワードされることを特徴とする請求項６に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
前記統合アドレスブック個人連絡カードアプリケーション使用部は、
前記第２のクライアントと通信するネットワークから前記遠隔要請に対する伝送結果に対する第１の応答メッセージを受信し、前記フォワード要請に対する第２の応答メッセージを生成して前記フォワード要請の結果を前記ＣＡＢサーバの連絡先共有機能部に記憶することを特徴とする請求項６に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
前記第２のクライアントと通信するネットワークから前記遠隔要請に対するフォーワーディング結果に対する第１の応答メッセージを受信するステップと、
前記フォワード要請に対する第２の応答メッセージを生成して前記フォワード要請に対する結果を記憶するステップと、をさらに含むことを特徴とする請求項１に記載の方法。
前記第２の応答メッセージを伝送するステップと、
前記第２の応答メッセージの伝送以後に前記第２のクライアントと通信するネットワークから前記連絡先共有要請に対する伝送報告を受信するステップと、をさらに含むことを特徴とする請求項１１に記載の方法。
前記連絡先共有要請に対する伝送報告に基づいて前記連絡先共有要請の伝送状態は前記ＣＡＢサーバでアップデートされることを特徴とする請求項１２に記載の方法。
前記統合アドレスブック機能駆動アプリケーション使用部は、前記第２の応答メッセージを前記連絡先共有機能部に伝送し、
前記統合アドレスブック個人連絡カードアプリケーション使用部は、前記連絡先共有要請の伝送報告を前記第２のクライアントと通信するネットワークから受信することを特徴とする請求項１０に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。
前記連絡先共有要請に対する伝送報告に基づいて前記連絡先共有要請の伝送状態は前記ＣＡＢサーバでアップデートされることを特徴とする請求項１４に記載の連絡先情報の購読を招待する統合アドレスブック文書管理サーバ。