(57)【特許請求の範囲】
【請求項１】
通信システムにおける端末が通信履歴を受信する方法であって、
前記端末のユーザーに関連して登録されたすべての端末の通信履歴情報を受信する端末として、前記端末を登録することを要求する通信履歴の購読要求をサーバに送信するステップと、
前記通信履歴情報が変更されることによって、前記変更された通信履歴情報を前記サーバから受信するステップと、
前記受信された通信履歴を保存するステップと、
前記通信履歴情報に含まれた少なくとも１つの通信相手端末に関するプレゼンス情報の要求を送信するステップと、
前記少なくとも１つの通信相手端末に関するプレゼンス情報を受信するステップと、を有することを特徴とする方法。
【請求項２】
前記端末が任意の端末と通信を実行した後に新たな通信履歴が生成される場合に、前記新たな通信履歴を前記サーバに伝達するステップと、
前記新たな通信履歴を含む前記通信履歴情報を前記サーバから受信し、前記受信された通信履歴情報を保存するステップと
をさらに有することを特徴とする請求項１に記載の方法。
【請求項３】
前記通信履歴情報に含まれた通信相手端末の中でプレゼンス状態の特定の端末に関するプレゼンス情報を要求するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
ユーザーの要求に応じて前記通信履歴情報をディスプレーするステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項５】
前記通信履歴情報に含まれた通信相手端末の中でユーザーにより選択された端末と通信を実行するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項６】
前記通信履歴情報は、前記通信履歴情報に含まれた通信相手端末に対応する接続タイプ、接続番号、日程、及び通話時間の中の少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項７】
通信システムのサーバにおける端末に通信履歴を提供する方法であって、
通信履歴の購読要求を前記端末から受信するステップと、
前記端末のユーザーに関連して登録されたすべての端末の通信履歴情報を受信する端末として、前記端末を登録するステップと、
前記通信履歴情報が変更されると、前記変更された通信履歴情報を前記端末に送信するステップと、
前記通信履歴情報に含まれた少なくとも１つの通信相手端末に関するプレゼンス情報の要求を前記端末から受信するステップと、
前記少なくとも１つの通信相手端末に関するプレゼンス情報を前記端末に伝達するステップと
を有することを特徴とする方法。
【請求項８】
新たに生成された通信履歴を前記端末から受信するステップと、
前記新たに生成された通信履歴を含む前記通信履歴情報を前記端末に送信するステップとをさらに有することを特徴とする請求項７に記載の方法。
【請求項９】
通信システムにおける端末の通信履歴を受信する装置であって、
送受信部と、
前記送受信部を通して前記端末のユーザーに関連して登録されたすべての端末の通信履歴情報を受信する端末として、前記端末を登録することを要求する通信履歴の購読要求をサーバに送信し、前記通信履歴情報が変更されることによって、前記変更された通信履歴情報を前記サーバから受信し、前記受信された通信履歴情報を前記端末のメモリに保存し、前記通信履歴情報に含まれた少なくとも１つの通信相手端末に関するプレゼンス情報を要求し、前記少なくとも１つの通信相手端末に関するプレゼンス情報を受信する制御部とを有することを特徴とする装置。
【請求項１０】
前記制御部は、任意の端末と通信を実行した後に新たな通信履歴が生成される場合に、前記新たな通信履歴を前記送受信部を通して前記サーバに送信し、前記新たな通信履歴を含む前記通信履歴情報を前記サーバから受信し、前記受信された通信履歴情報を前記メモリに記憶することを特徴とする請求項９に記載の装置。
【請求項１１】
前記制御部は、ユーザーの要求に応じて前記通信履歴情報をディスプレーすることを特徴とする請求項９に記載の装置。
【請求項１２】
前記制御部は、前記通信履歴情報に含まれた通信相手端末の中でユーザーにより選択された端末と通信を実行することを特徴とする請求項９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション開始プロトコル（Session Initiation Protocol：以下、“ＳＩＰ”と称する。）／インターネットプロトコル（Internet Protocol：以下、“ＩＰ”と称する。）コア網の統合アドレス帳サービスに関し、特に、統合アドレス帳サービスを使用して移動端末の通信履歴を管理する方法及び装置に関する。
【背景技術】
【０００２】
ＳＩＰ／ＩＰコア網において、統合アドレス帳（Converged Address Book：以下、“ＣＡＢ”と称する。）サービスは、ユーザーが様々な端末で使用可能なアドレス情報を記憶するようにし、いつでも、どこにでも、どの装置でも、この情報にアクセスすることができるようにし、アドレス情報を同期化する単一ネットワーク基盤のアドレス帳サービスである。
【０００３】
図１に示すように、オープンモバイルアプライアンス（Open Mobile Alliance：以下、“ＯＭＡ”と称する。）ＣＡＢグループにより提案されたＣＡＢの概念構造は、ＣＡＢクライアント１００、ＣＡＢサーバ１２０、コンタクト制御サーバ１３０、及び拡張可能マークアップ言語（eXtensible Markup Language：以下、“ＸＭＬ”と称する。）文書管理サーバ（XML Document Management Server：以下、“ＸＤＭＳ”と称する。）１４０を含む。
【０００４】
端末上のＣＡＢサーバ１２０と通信するＣＡＢクライアント１００は、ＣＡＢユーザー認証に関する情報をＣＡＢサーバ１２０に送信し、個人コンタクトカード（Personal Contact Card：以下、“ＰＣＣ”と称する。）及びネットワークストレージに記憶されたＣＡＢを同期化し、ＣＡＢユーザーの要求事項、例えば、アドレス購読（subscription）、アドレス検索、アドレス共有、旧アドレス帳との相互作用、ユーザー選好度の管理などを保持する。
【０００５】
ＣＡＢサーバ１２０は、ＣＡＢアーキテクチャで主要なネットワーク構成要素であり、ＣＡＢクライアント１００から受信したＣＡＢユーザー要求事項を処理する機能をする。ＣＡＢサーバ１２０の主要な機能は、ＣＡＢクライアントの相互認証、ＣＡＢアドレスの記憶、アドレス情報の同期化、及びアドレス購読のような機能からアップデートされたアドレス情報の受信、このアップデートされたアドレス情報のアドレス帳への反映を含む。
【０００６】
コンタクト制御サーバ１３０は、アドレス購読／共有／変換及びユーザー選好度／ポリシーなどを反映するネットワーク構成要素であり、その主要機能は、ＣＡＢユーザー選好度／ポリシーＸＤＭＳからＣＡＢユーザー選好度関連ＸＭＬ文書の回収、ＣＡＢユーザーから購読要求（subscribe request）を受信するアドレス購読機能、アドレス購読を通して受信されたデータの個人選好度の適用、アドレス帳への個人選好度の反映、購読状態情報の保持、及びＰＣＣ又はＣＡＢを共有するアドレス共有機能、及び既存のアドレス帳システムとのインターワーキング又は外部のイネイブラーにインターフェースを公開するインターワーキング機能（ＩＷＦ）などを含む。
【０００７】
ユーザーデータを管理するＸＤＭＳ１４０は、ＣＡＢを記憶するＣＡＢ  ＸＤＭＳ、ユーザー選好度及びポリシーを記憶するＣＡＢユーザー選好度／ポリシーＸＤＭＳ、既存のユーザーからＣＡＢユーザーを識別するＣＡＢコンタクト状態ＸＤＭＳ、他人と共有するアドレス帳を記憶するＣＡＢコンタクト共有ＸＤＭＳ、ＰＣＣ情報を記憶するＰＣＣ  ＸＤＭＳ、通信履歴を記憶する通信履歴ＸＤＭＳなどを含む。それ以外に、ＸＤＭＳ１４０は、様々なＸＤＭＳ機能にアクセスするためのＸＤＭＳ、外部ドメイン内のエンティティーとのメッセージルーティングのためのＳＩＰ／ＩＰコア網を含んでもよい。
【０００８】
複数の端末を有する受信者と発信者間の通信の例について図２を参照して説明する。図２に示す例において、複数の端末を有する受信者は、ＣＡＢサービスで発信者と通信する。図２において、複数の端末を有する受信側ユーザーＡは、ステップ２０１、ステップ２０３、及びステップ２０５で、第１の端末＃１  ２００で受信された発信側ユーザーＢ  ２４０の通信要求に応じてオーディオセッションを確立する。ここで、ユーザーＢ  ２４０は、ユーザーグループを構成することができる。発信者と受信者間の所定の目的（例えば、通話、短文メッセージサービス（ＳＭＳ）、メッセンジャーサービスなど）を達成した後に、ユーザーＡは、ステップ２０７及びステップ２０９で、ユーザーＢ  ２４０とのセッションを終了する。セッションが終了するに従って、このような通信に対する通信履歴は、ステップ２１５及びステップ２４５で、ユーザーＡの第１の端末＃１  ２００及びユーザーＢ  ２４０の端末に記録される。しかしながら、現在のＣＡＢサービスにおいて、ユーザーＡの第２の端末＃２  ２２０がユーザーＢ  ２４０にセッション確立に対する要求を送信する場合に、第２の端末＃２  ２２０は、ユーザーＡの第１の端末＃１  ２００に記録された通信履歴を探すことができず、これにより、ユーザーＡは、ステップ２２５で、通信履歴を使用するユーザーＢ  ２４０との通信を円滑に行うことができない。また、ユーザーＢ  ２４０の連絡先がＣＡＢアドレス帳に保存されていない場合に、ユーザーＡは、第１の端末＃１  ２００の通信履歴を確認しない限り、ユーザーＢ  ２４０との通信を開始することができない。
【０００９】
上述したように、複数の端末を有する受信者が第１の端末を使用して発信者との通信の後に、第２の端末で発信者との通信を試みる場合に、受信者は、発信者と最初に通信した特定の端末を使用して通信履歴を確認しない限り、既存の発信者との通信履歴に関する情報を取得することができず、現在のＣＡＢサービスもこれに関する情報を提供せず、これにより、複数の端末を有するユーザーの円滑な通信に大きな支障がある。したがって、ＣＡＢサービスにおいて、複数の端末に存在する通信履歴を統合的に管理することができる方案が切実である。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
そこで、本発明は上記従来の問題点に鑑みてなされたものであって、本発明の目的は、複数の端末を有するユーザーが統合された通信履歴を使用して所望の受信者との円滑な通信を実行することができる方法及び装置を提供することにある。
【００１１】
本発明の他の目的は、ＣＡＢシステムにおける統合された通信履歴を提供することにより複数の端末ユーザーが個々の端末に存在する通信履歴を散発的に使用する際に経験する不便さを除去することにより、複数の端末ユーザーの決定に従って迅速であり容易にＣＡＢサービスが可能なデータ送受信方法及び装置を提供することにある。
【課題を解決するための手段】
【００１２】
上記のような目的を達成するために、本発明の一態様によれば、通信システムにおける端末が通信履歴を受信する方法を提供する。上記方法は、特定のユーザーの通信履歴の購読要求をサーバに送信するステップと、上記端末の特定のユーザーに関連して登録されたすべての端末の通信履歴情報を上記サーバから受信し、上記受信された通信履歴を上記特定のユーザーの端末内に保存するステップとを有することを特徴とする。
【００１３】
本発明の他の態様によれば、 通信システムにおける端末に通信履歴を提供する方法を提供する。上記方法は、通信履歴の要求を端末から受信するステップと、上記端末のユーザーに関連して登録されたすべての端末の通信履歴情報を上記端末の中の１つの端末に送信するステップとを有することを特徴とする。
【００１４】
本発明のさらに他の態様によれば、 通信システムにおける端末の通信履歴を受信する装置を提供する。上記装置は、送受信部と、上記送受信部を通して特定のユーザーの通信履歴の購読要求をサーバに送信し、上記端末の特定のユーザーと関連して登録されたすべての端末の通信履歴情報を上記サーバから受信し、上記受信された通信履歴情報を上記端末のメモリに保存する制御部とを有することを特徴とする。
【発明の効果】
【００１５】
本発明で提案する方法及び装置において、発信者の登録された端末が通信履歴の購読要求を行う場合に、通信履歴が生成されるか又はアップデートされるたびに、すべての端末は、通信履歴の通知を受ける。既存の端末でない他の端末がプレゼンス情報を含む通信履歴を提供するので、ユーザー又は発信者は、活性化状態のグループメンバーとの連続的通信を行い、これにより、ユーザー経験も向上させることができる。
【図面の簡単な説明】
【００１６】
【図１】一般的なＳＩＰ基盤の統合アドレス帳（ＣＡＢ）システムのアーキテクチャを示す図である。
【図２】複数の端末を有する受信者と発信者グループ間の通信履歴を記憶するための信号送受信を示す図である。
【図３】本発明で提案するＳＩＰ基盤のプレゼンス情報を含む通信履歴を共有することによりグループコールをするための信号送受信を示す図である。
【図４】本発明で提案するＳＩＰ基盤のプレゼンス情報を含む通信履歴を共有することによりグループコールをするための信号送受信を示す図である。
【図５】本発明の一実施形態による通信履歴を管理する工程を示す図である。
【図６】本発明の一実施形態による通信履歴を提供する工程を示す図である。
【発明を実施するための形態】
【００１７】
以下、本発明を実施するための形態を、図面を参照しながら詳細に説明する。下記の説明において、明瞭性と簡潔性の観点から、本発明に関連した公知の機能や構成に関する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、その詳細な説明を省略する。
【００１８】
本発明は、一般的に、セッション開始プロトコル（Session Initiation Protocol：以下、“ＳＩＰ”と称する。）／インターネットプロトコル（Internet Protocol：以下、“ＩＰ”と称する。）コア網で単一ユーザーが有している複数の端末で使用可能であるようにアドレス情報及び通信履歴を記憶し、いつでも、どこにでも、どの装置でも、この情報にアクセス可能であり、この情報を同期化する単一ネットワーク基盤のアドレス帳サービスである統合アドレス帳（Converged Address Book：以下、“ＣＡＢ”と称する。）サービスに関し、より詳細に、複数の端末を有するユーザーがそれぞれの端末に存在するアドレス情報及び通信履歴を統合方式で管理するようにし、この情報に基づくプレゼンス情報を提供することにより、通信履歴を用いてグループコールの間に通話連続性の保持の便宜をユーザーに提供する方法及び装置に関する。
【００１９】
本発明において、ＣＡＢイネイブラーの機能として含まれた通信履歴は、端末で発生したすべての通信に関する記録を意味し、既存の発呼／着呼リストを含んで通話タイプ別（発呼、着呼、留守中、受信拒否など）、通信タイプ、例えば、音声呼、ビデオ呼、グループ呼、及び各種メッセーシングサービス（ＳＭＳ／ＭＭＳ（複数のメディアメッセージサービス）／ＳＩＭＰＬＥ（プレゼンスを表現するためのＳＩＰの拡張プロトコル）ＩＭ（インスタントメッセージング）／ＰｏＣ（セルラー経由のプッシュツートーク）／ＣＰＭ（統合されたＩＰメッセージング）／ＣＡＢなど）を含み、端末アドレス、ＵＳＩＭアドレス、及び外部メモリアドレスのようなアドレス記憶位置に関する通信記録などを含む。
【００２０】
本発明は、通信相手間でプレゼンス情報を含む通信履歴を提供することにより端末間の履歴の連続性の保証のための方法を提案する。より具体的に、関連した通信相手間で登録された端末が統合通信履歴の購読要求を行う場合に、端末ごとに通信履歴が生成されるか又はアップデートされるたびに通信履歴の通知を受ける。ユーザーは、既存の使用端末でない他の端末からプレゼンス情報を含む通信履歴の通知を受けることにより、活性化状態のグループメンバーとの連続的通信を行い、これにより、ユーザー経験も向上させることができる。
【００２１】
現在の統合ＩＰメッセージング（ＣＰＭ）サービス及びセルラー経由のプッシュツートーク（ＰｏＣ）サービスは、それぞれメッセージ及びメディア記憶装置（ＭＭＳ）及びＰｏＣボックスと呼ばれるストレージにセッション履歴情報及びメディアを保存することができる。しかしながら、これらのサービスは、ユーザーの選好度及びサービスプロバイダーのポリシーに依存するので、記録が保存されないことがある。また、セッション履歴に関する内容がＳＩＰヘッダー情報に限定されるために、その値は、現在の端末で提供している通信履歴情報に比べて多様性及び有用性の観点で相対的に低い。
【００２２】
このようなセッション履歴情報の限界を克服し、端末ごとに個別に存在する通信履歴情報を明らかに管理する必要がある。このために、本発明は、ユーザーが登録された端末の通信履歴の購読要求を行うようにし、変更された情報を受信することができるようにすることにより、端末間の通信履歴を管理し、プレゼンス情報を含む通信履歴を伝達することができ、これにより、複数の端末を有するユーザーが通信履歴を用いて連続的な通信を行うようにすることができる。これについては、以下に詳細に説明する。
【００２３】
図３及び図４において、ユーザーＢ  ２４０が送信したグループコールインバイトメッセージに応じて、２つ以上の端末を有するユーザーＡは、第１の端末＃１  ２００を有するグループメンバー（ユーザーＢ及びユーザーＣ）とグループコールを行う。その後に、アップデートされた通信履歴に含まれたプレゼンス情報を用いて、ユーザーＡの第２の端末＃２  ２２０を有する活性化状態のグループメンバーとグループコールを試みる。
【００２４】
図３及び図４は、本発明で提案するプレゼンス情報を含む通信履歴を提供する方法を示す。複数の端末を有する発信者は、グループコールを円滑にすることができるようにするために、ステップ３２１０、ステップ３２１１、ステップ３２１３、ステップ３２１７、及びステップ３２１９で、発信者が使用した２つの端末の中でユーザーＡの第２の端末＃２  ２２０にアップデートされた通信履歴の購読要求を送信する。この購読要求を受信すると、ＣＡＢ  ＸＤＭＳ２８０は、ステップ３２２１、ステップ３２２３、ステップ３２２４、及びステップ３２２７で、いままでユーザーＡと関連して記憶している既存の通信履歴を第２の端末＃２  ２２０に通知する。この後に、購読要求期間が満了するまで変更された通信履歴がない場合には、通知もなされない。
【００２５】
この後に、ユーザーＡとユーザーＢ間でグループコールが行われ、この後にグループコールが終了する場合に、ステップ３２２５、ステップ３１１０、及びステップ３２３０で通信履歴が生成され、この生成された通信履歴は、ステップ３２３１での第１の端末＃１  ２００とＣＡＢサーバ２６０間のデータ同期化を通してステップ３２３３及びステップ３２４０でＣＡＢ  ＸＤＭＳ２８０に記憶される。ＣＡＢ  ＸＤＭＳ２８０は、変更された通信履歴に対する購読要求権限を確認した後に、ステップ３２４１、ステップ３２４３、ステップ３２４５、及びステップ３２４７で、この権限結果を第２の端末＃２  ２２０に通知する。発信者は、ステップ３２５０で、通知を受けた第１の端末＃１  ２００でのグループコールに関する通信履歴情報に基づいて第２の端末＃２  ２２０で既存のグループコールの再確立要求を試みる。この際に、グループメンバーのプレゼンスが提供される場合に、グループコール接続に対する接続／開催可能性を確保するようにすることができ、ユーザーの経験の向上に格段に役立つ。発信者は、通信履歴からリソースリストを取得した後に、ステップ３２５１及びステップ３２５３で、活性化状態のリソースに対するプレゼンス購読要求を行うフィルターを有するプレゼンス購読要求メッセージをプレゼンスサーバ３５０に送信する。“リソースリスト”は、通信履歴に含まれた対応する端末のリストを意味する。
【００２６】
プレゼンスサーバ３５０は、発信者の権限を確認した後に、ステップ３２６１、ステップ３２６３、ステップ３２６５、及びステップ３２６７で、リソースリスト内の活性化状態のリソース（すなわち、ユーザーＢ及びユーザーＣ）のみに対してプレゼンス情報を通知する。既存のグループコールに参加したグループメンバー中で活性化状態のグループメンバー（すなわち、ユーザーＡ、ユーザーＢ、及びユーザーＣ）のプレゼンス情報を取得した発信者は、ステップ３２７０及びステップ３２７１で、ユーザーＡの第２の端末＃２  ２２０でユーザーＢ及びユーザーＣとグループコールを行う。このグループコールが終了した後に、これに関する通信履歴情報は、ステップ３２７３、ステップ３２７５、ステップ３２７７、及びステップ３２７９で、前と同様にＣＡＢ  ＸＤＭＳ２８０に記憶される。
【００２７】
本発明に従って、端末とサーバ間の通信履歴データを同期化する方法は、図３及び図４に示す同期化工程に加えて、図５の同期化工程を含んでもよい。図４は、ｎｏｎ  ＳＩＰ基盤の購読バインディング（non SIP based subscription binding ）に基づくＸＣＡＰパッチオペレーション（XCAP patch operations）（ＲＦＣ  ５２６１）を使用する通信履歴データを同期化する工程を示す。
【００２８】
図４において、ＸＣＡＰ  ＰＵＴは、ＣＡＢ  ＸＤＭＳ２８０にｎｏｎ  ＳＩＰ基盤の購読バインディングを確立した後に、前に確立されたユーザー選好度を確認し、アップデートされた通信履歴を関連した端末に通知するために使用される。
【００２９】
まず、ユーザーＡの第２の端末＃２  ２２０について、ステップ３３０１で、ユーザーＡは、登録された端末の通信履歴に関するアップデートされた情報を受信するためにユーザー選好度に購読要求を確立する。この後に、ステップ３３０３で、ユーザーＡが自身の第１の端末＃１  ２００とグループコールを行う場合に、ＸＣＡＰ  ＰＵＴを使用して生成された通信履歴は、ステップ３３０５−ａ、ステップ３３０５−ｂ、ステップ３３０７、及びステップ３３０９で、ＣＡＢ  ＸＤＭＳ２８０に記憶される。この際に、ユーザーは、ｎｏｎ  ＳＩＰ基盤の購読バインディングを通して他の端末への同期化の必要性及び通信履歴の変更をともに送信することにより、通信履歴データの同期化のためのｎｏｎ  ＳＩＰ通知を試みることができる。ＸＣＡＰ  ＰＵＴを受信したＣＡＢ  ＸＤＭＳ２８０は、ステップ３３１１及びステップ３３１３で、通信履歴の状態が変更されることを購読機能部３７０に通知する。この状態変更情報を受信した購読機能部３７０は、ステップ３３１５で、ユーザー選好度を確認することにより通信履歴同期化のために通知が必要なユーザーの登録された端末を確認する。購読機能部３７０は、ユーザーＡの第２の端末＃２  ２２０が通信履歴購読機能を前に設定したことを確認し、ステップ３３１７、ステップ３３１９、ステップ３３２１、及びステップ３３２３で、XCAP patch operationsを使用してアップデートされた通信履歴のみをユーザーの第２の端末＃２  ２２０に送信する。その結果、ユーザーＡの第２の端末＃２  ２２０は、既存のグループコールの再確立を要求することができ、図３と同様に、ステップ３３２５で、既存の参加者のプレゼンス情報に基づいてグループコールをさらに行うことができる。
【００３０】
図３、図４、及び図５の信号フロー図からわかるように、発信側ユーザーがその端末に関する統合された通信履歴情報を受信することができるので、１つの端末で受信された通話に対する通信履歴を他の端末で取得することができない問題点を解決することができる。また、ユーザーは、関連したプレゼンス情報を有する通信履歴情報を受信することができ、これにより、通信の連続性を向上させることができる。
【００３１】
表１乃至表５は、上記信号フロー図での各ステップに対するメッセージフォーマットを示す。
【００３２】
表１は、ユーザーＡの第２の端末＃２  ２２０がアップデートされた通信履歴の購読要求をするためにＣＡＢ  ＸＤＭＳ２８０に送信するメッセージの一例を示す。“ｘｃａｐ−ｄｉｆｆ”は、アップデートされたＸＭＬ文書を受信するためにイベントパッケージとして使用され、本発明で提案する通信履歴を定義する新たなフォーマットは、コンテンツタイプ（Content-Type）として要求される。次のＸＭＬ文書は、通信履歴ストレージに記憶されているユーザーＡの通信履歴を購読するために使用されるＵＲＩを示す。
【００３３】
【表１】
0005436571.tif 000002
【００３４】
表２は、ユーザーＢとのグループコールを行ったユーザーＡの第１の端末＃１  ２００により新たに生成された通信履歴をＣＡＢ  ＸＤＭＳ２８０に保存するために使用されるメッセージの一例を示す（ステップ３２３３）。生成された通信履歴が属するリストは、着信グループ呼に対応し、通信履歴の参照アドレスは、SIP:112233@comm_historyserver.example.com.である。発信者は、ユーザーＢ  ２４０であり、続いて接続タイプ（例えば、contact type_“home”、“office”、“abroad”など）、接続番号、日程、通話時間、及びグループコール参加者情報（すなわち、参加者）が出る。表２の例は、基本的な通信履歴のフォーマットを示し、端末に従ってさらに豊かな通信履歴情報を提供することができる。
【００３５】
【表２】
0005436571.tif 000003
【００３６】
表３は、新たに記憶された通信履歴をユーザーＡの第２の端末＃２  ２２０の購読要求に応じて通知するために使用されるメッセージを示す（ステップ３２４１）。ＣＡＢ  ＸＤＭＳ２８０は、“SIP:112233@comm_historyserver.example.com.”と呼ばれる新たなエントリーを端末に送信する。
【００３７】
【表３】
0005436571.tif 000004
【００３８】
表４は、ユーザーＡが第２の端末＃２  ２２０との既存のグループコールを再開するために、通信履歴からのリソースリストをフィルターとして使用することによりプレゼンスに対する購読要求を行うメッセージの一例を示す（ステップ３２５１）。ユーザーＡの第２の端末＃２  ２２０は、ユーザーＡの第１の端末＃１  ２００及びユーザーＢ、ユーザーＣ、及びユーザーＤのグループ２４０のそれぞれにプレゼンス情報に対する要求を送信する。
【００３９】
【表４】
0005436571.tif 000005
【００４０】
表５は、表４の要求に関する結果情報であるリソースリストの状態に関するフィルターが適用されたプレゼンス情報を通知するために使用されるメッセージを示す（ステップ３２６１）。メッセージに示すように、ユーザーＢ及びユーザーＣが“online”状態にあることがわかる。この情報に基づいて、ユーザーＡは、第２の端末＃２  ２２０と関連する受信者にグループコールを試みることができる。
【００４１】
【表５】
0005436571.tif 000006
【００４２】
図４のXCAP patch operationsを使用してアップデートされた通信履歴を通知する例について、主要ステップに対するメッセージフォーマットは、表６及び表７に示す（ステップ３３０７を参照）。
【００４３】
表６のメッセージは、生成された通信履歴が同期化を必要とし（sync=“active”）、ＣＡＢ  ＸＤＭＳ２８０に保存されることにより他の登録された端末への同期化が必要である（status=“update”）ことをＣＡＢ  ＸＤＭＳ２８０に送信する。
【００４４】
【表６】
0005436571.tif 000007
【００４５】
表７は、ユーザーＡのユーザー選好度ＸＤＭＳからユーザーＡの第２の端末＃２  ２２０の通信履歴の購読が要求されることを確認した購読機能部３７０がXCAP patch operationsを通してアップデートされた通信履歴をユーザーＡの第２の端末＃２  ２２０に送信するメッセージの一例を示す（ステップ３３１９を参照）。
【００４６】
【表７】
0005436571.tif 000008
【００４７】
図６は、上述したように、複数の端末を有するユーザーがそれぞれの端末に存在する通話履歴を統合して管理し、プレゼンス情報をこれに提供する動作を一般化した工程を示す。
【００４８】
図６を参照すると、ステップ４０３で、ユーザーＡは、第２の端末＃２  ２２０を使用して通信履歴に対する購読要求を送信し、これに応じた通知を受信する。具体的に、第２の端末＃２  ２２０の制御部は、端末内の送受信部を通して通信履歴に対する購読要求を送信する。制御部は、第２の端末＃２  ２２０の全般的な動作を制御し、送受信部は、制御部の制御の下に、データを無線で外部の装置に送信するか、又は外部装置からデータを受信し、この受信されたデータを制御部に伝達する。
【００４９】
ユーザーＡは、ステップ４０５で、第１の端末＃１  ２００を使用してユーザーＢからグループコールを受信し、ユーザーＣ及びユーザーＤとともにグループコール通信を行う。グループコールが終了する場合に、ユーザーＡの第１の端末＃１  ２００は、ステップ４０７で、生成された通信履歴をオープンモバイルアライアンス（ＯＭＡ）同期化マークアップ言語（ＳｙｎｃＭＬ）及びＸＭＬ構成アクセスプロトコル（ＸＣＡＰ）ＰＵＴを用いて自身の通信履歴ＸＤＭＳ内に保存する。その後に、第１の端末＃１  ２００の制御部は、第１の端末＃１  ２００の通信履歴を送受信部を通してＣＡＢ  ＸＤＭＳ２８０に送信する。
【００５０】
この購読要求に応じて、ユーザーＡの第２の端末＃２  ２２０は、ステップ４０９で、ＣＡＢ  ＸＤＭＳ２８０からアップデートされた通信履歴情報の通知を受ける。その後に、第２の端末＃２  ２２０は、ＣＡＢ  ＸＤＭＳ２８０から送信された通信履歴情報を送受信部を通して受信し、この受信された通信履歴情報をメモリに記憶する。
【００５１】
ユーザーＡは、ステップ４１１で、この通知を受けた通信履歴を用いて、必要であれば、第２の端末＃２  ２２０とグループコールをさらに試みる。ユーザーＡの入力を受信すると、第２の端末＃２  ２２０は、ステップ４１３で、既存のグループコールを行ったグループメンバーに関するプレゼンス情報を要求するか否かを決定する。第２の端末＃２  ２２０がプレゼンス情報を要求しないことに決定する場合に、ユーザーＡは、単純なグループコールを要求し、したがって、第２の端末＃２  ２２０の制御部は、ステップ４２３で、通信履歴情報を用いて単純なグループコールを要求する。他方、第２の端末＃２  ２２０がプレゼンス情報を要求することに決定した場合に、ユーザーＡは、ステップ４１５で、フィルタリングされたプレゼンス情報を要求するか否かを決定する。ユーザーＡがグループメンバーに関するフィルタリングされたプレゼンス情報を要求することに決定した場合に、第２の端末＃２  ２２０の制御部は、ステップ４１７で、送受信部を通してグループメンバーのプレゼンスに関するフィルタリングされた情報の購読要求を送信する（SUBSCRIBE（Event:presence, with filter））。グループメンバーに関するフィルタリングされたプレゼンス情報を要求しないことに決定した場合に、ユーザーＡは、ステップ４１９で、すべてのグループメンバーに関するプレゼンス情報の購読要求を送信する（SUBSCRIBE）。その後に、第２の端末＃２  ２２０の制御部は、送受信部によりすべてのグループメンバーに関するプレゼンス情報の要求をプレゼンスサーバ３５０に送信する。第２の端末＃２  ２２０が送受信部を通してプレゼンス情報をプレゼンスサーバ３５０から受信するので、ユーザーＡは、ステップ４２１で、グループメンバーのプレゼンスに関する要求された情報の通知を受ける。ユーザーＡは、ステップ４２３で、通知を受けたグループメンバーのプレゼンス情報に基づいて活性化状態のグループメンバーとグループコールを試みる（INVITE）。
【００５２】
このように、通信履歴を用いてグループコールを再び試みる場合に、複数の端末を有するユーザーは、活性化状態のグループメンバーと通話することができるだけでなく、自身の他の端末を用いて通信履歴を共有することもできる。
【００５３】
本発明の実施形態は、コンピュータ読み取り可能な記録媒体上でコンピュータ読み取り可能なコードとして実現することもできる。コンピュータ読み取り可能な記録媒体は、コンピュータシステムにより読出し可能なデータを記憶できる任意のデータ記憶装置である。コンピュータ読み取り可能な記録媒体の例としては、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光学データ記憶装置が含まれるが、これらに限定されるものではない。また、上記コンピュータ読み取り可能な記録媒体は、コンピュータ読み取り可能なコードが配布される方式で記憶されて実行されるように、ネットワーク結合型コンピュータシステムを介して配布できる。更に、本発明を達成するための関数プログラム、コード及びコードセグメントは、本発明が属する技術分野で熟練したプログラマーにより本発明の範囲内で容易に解釈できるであろう。
【００５４】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００５５】
２００  ユーザーＡ  ＃１
２２０  ユーザーＡ  ＃２
２４０  ユーザーＢ／Ｃ／Ｄ
２８０  ＣＡＢ  ＸＤＭＳ
３７０  購読機能部
【図１】
0005436571.tif 000009
【図２】
0005436571.tif 000010
【図３】
0005436571.tif 000011
【図４】
0005436571.tif 000012
【図５】
0005436571.tif 000013
【図６】
0005436571.tif 000014