(57)【特許請求の範囲】
【請求項１】
プレゼンス情報の公開者および要求者のいずれにもなり得る複数の端末デバイスと、前記公開者からイベントの発生に際して個別に通知されるプレゼンス情報を含む配信情報を前記要求者に配信するサーバユニットとを具備するプレゼンスサービス提供システムにおいて、
前記複数の端末デバイスは、
プレゼンスの変化したユーザのプレゼンス情報と、当該変化したプレゼンスに遷移するために行われたキー操作またはフックスイッチ操作を示すコード化された操作情報とを、前記イベントの発生に際して前記サーバユニットに通知する通知部を備え、
前記サーバユニットは、
前記通知されたプレゼンス情報と操作情報とを対応付けた拡張プレゼンス情報を蓄積する拡張情報データベースと、
前記配信情報と前記拡張情報データベースから取得した操作情報とを組み合わせた拡張配信情報を生成する生成部と、
前記拡張配信情報を前記要求者に配信する配信部とを備えることを特徴とするプレゼンスサービス提供システム。
【請求項２】
前記生成部は、前記要求者の状態に応じた操作情報を前記拡張情報データベースから取得することを特徴とする請求項１に記載のプレゼンスサービス提供システム。
【請求項３】
複数のフィーチャにそのフィーチャを呼び出す操作番号を対応付けた番号計画データベースをさらに具備し、
前記生成部は、前記取得した操作情報に対応するフィーチャの操作番号を前記番号計画データベースから読み出し、この操作番号を前記配信情報に組み合わせて前記拡張配信情報を生成することを特徴とする請求項２に記載のプレゼンスサービス提供システム。
【請求項４】
前記複数のフィーチャにそれぞれ操作支援のためのヘルプ情報を対応付けたヘルプ情報データベースをさらに具備し、
前記生成部は、前記取得した操作情報に対応するフィーチャのヘルプ情報を前記ヘルプ情報データベースから読み出し、このヘルプ情報を前記配信情報に組み合わせて前記拡張配信情報を生成することを特徴とする請求項３に記載のプレゼンスサービス提供システム。
【請求項５】
前記生成部は、前記拡張情報データベースに蓄積される拡張プレゼンス情報を統計処理し、前記要求者の状態において実施される操作の頻度を示す情報を前記拡張配信情報に含ませることを特徴とする請求項２に記載のプレゼンスサービス提供システム。
【請求項６】
プレゼンスサービス提供システムに設けられ、プレゼンス情報の公開者からイベントの発生に際して個別に通知されるプレゼンス情報を含む配信情報を要求者に配信するサーバユニットにおいて、
前記公開者から通知されたプレゼンス情報と、このプレゼンス情報に示されるプレゼンスに遷移するために行われた前記公開者の端末デバイスにおけるキー操作またはフックスイッチ操作を示すコード化された操作情報とを対応付けた拡張プレゼンス情報を蓄積する拡張情報データベースと、
前記配信情報と前記拡張情報データベースから取得した操作情報とを組み合わせた拡張配信情報を生成する生成部と、
前記拡張配信情報を前記要求者に配信する配信部とを備えることを特徴とするサーバユニット。
【請求項７】
前記生成部は、前記要求者の状態に応じた操作情報を前記拡張情報データベースから取得することを特徴とする請求項６に記載のサーバユニット。
【請求項８】
前記生成部は、
複数のフィーチャにそのフィーチャを呼び出す操作番号を対応付けた番号計画データベースから、前記取得した操作情報に対応するフィーチャの操作番号を読み出し、この操作番号を前記配信情報に組み合わせて前記拡張配信情報を生成することを特徴とする請求項７に記載のサーバユニット。
【請求項９】
前記生成部は、
前記複数のフィーチャにそれぞれ操作支援のためのヘルプ情報を対応付けたヘルプ情報データベースから、前記取得した操作情報に対応するフィーチャのヘルプ情報を読み出し、このヘルプ情報を前記配信情報に組み合わせて前記拡張配信情報を生成することを特徴とする請求項８に記載のサーバユニット。
【請求項１０】
前記生成部は、前記拡張情報データベースに蓄積される拡張プレゼンス情報を統計処理し、前記要求者の状態において実施される操作の頻度を示す情報を前記拡張配信情報に含ませることを特徴とする請求項７に記載のサーバユニット。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、プレゼンスサービスを提供するシステムの改良に関する。
【背景技術】
【０００２】
ＩＰ（Internet Protocol）技術の発展・普及に伴って電話システムのＩＰ化も著しく、いわゆるＶｏＩＰ（Voice over IP）に関する技術開発が盛んである。ＩＰ技術を利用するサービスの一つにプレゼンスサービスがある。このサービスはネットワーク内のユーザの状態（オンライン、オフライン、取り込み中、在席中、離席中、通話中など）をメンバ同士で共有することを可能にする。プレゼンスを公開する側のユーザ（あるいはクライアント端末）をプレゼンティティ（presentity）と称し、プレゼンスを閲覧する側のユーザ（あるいはクライアント端末）をウォッチャ（watcher）と称する。
【０００３】
ところで、ＣＰＵ（Central Processing Unit）の高性能化、あるいはソフトウェアの高機能化によって近年の電話システムは非常に多機能になり、種々のフィーチャ（特殊機能）を持つようになっている。しかしながら十分な操作マニュアルが用意されているにも拘わらず、エンドユーザ（多くはビジネスパーソン）は数多くの便利な機能のうちのほんのわずかしか知らない。マニュアルを参照する機会が極めて少ないことがその一因として考えられ、そもそもマニュアルを見る暇がないのが実情である。
【０００４】
そこで、ユーザ間での情報共有サービスであるプレゼンスサービスを利用することで、操作マニュアルやガイダンスなどの有益な情報をも端末からユーザに提供できる可能性がある。このような機能を持つシステムは未だ知られていない。特許文献１には、プレゼンス情報を拡張してユーザ（あるいはクライアント）の状態をより詳細に定義できるようにする技術が開示される。しかしながらこの文献で取り扱われる情報は依然として「状態」の枠内にとどまるもので、操作ガイダンスなどの情報をユーザ間で共有することまではできない。
【特許文献１】特開２００７−２８０４１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
以上述べたようにプレゼンスサービスを用いれば、ガイダンスメッセージを表示するなどしてより便利なシステムを構築できる可能性がある。  
この発明は上記事情によりなされたもので、その目的は、プレゼンスサービスの利便性を高めたプレゼンスサービス提供システムとそのサーバユニットを提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するためにこの発明の一態様によれば、プレゼンス情報の公開者および要求者のいずれにもなり得る複数の端末デバイスと、前記公開者からイベントの発生に際して個別に通知されるプレゼンス情報を含む配信情報を前記要求者に配信するサーバユニットとを具備するプレゼンスサービス提供システムにおいて、前記複数の端末デバイスは、プレゼンスの変化したユーザのプレゼンス情報と、当該変化したプレゼンスに遷移するために行われたキー操作またはフックスイッチ操作を示すコード化された操作情報とを、前記イベントの発生に際して前記サーバユニットに通知する通知部を備え、前記サーバユニットは、前記通知されたプレゼンス情報と操作情報とを対応付けた拡張プレゼンス情報を蓄積する拡張情報データベースと、前記配信情報と前記拡張情報データベースから取得した操作情報とを組み合わせた拡張配信情報を生成する生成部と、前記拡張配信情報を前記要求者に配信する配信部とを備えることを特徴とするプレゼンスサービス提供システムが提供される。
【０００７】
このような手段を講じることにより、プレゼンティティは自己のプレゼンスの通知に際してそのプレゼンスに遷移するためにユーザによりなされたキー操作またはフックスイッチ操作を示すコード化された操作情報をサーバに通知する。サーバにおいては通知されたプレゼンスと操作情報とを関連付けてデータベースに蓄積する。そして既存のプレゼンスサービスの枠組みを用いてウォッチャに情報を配信するにあたり、ウォッチャの状態に応じた操作情報がデータベースから読み出され、プレゼンス情報とともにウォッチャに配信される。従ってそのときの状態に応じた適切な操作をユーザは実施できるようになり、プレゼンスサービスの利便性を向上させることが可能になる。
【発明の効果】
【０００８】
この発明によれば、プレゼンスサービスの利便性を高めたプレゼンスサービス提供システムとそのサーバユニットを提供することができる。
【発明を実施するための最良の形態】
【０００９】
図１は、この発明に関わるＩＰ電話システムの一実施形態を示す図である。図１において、複数のＶｏＩＰクライアント１〜４がＬＡＮ（Local Area Network）を介して構内交換システム１００に収容される。各ＶｏＩＰクライアント（およびそのユーザ）の状態はＬＡＮに接続されるプレゼンスサーバ２００により監視され、要求するクライアントに配信される。なおプレゼンスサーバ２００を構内交換システム１００の一つの機能としてインプリメントしても良い。
【００１０】
各ＶｏＩＰクライアント１〜４はプレゼンスサービスの枠組みにおいて、他のクライアントとの関係においてプレゼンス情報の公開者（プレゼンティティ）、あるいは要求者（ウォッチャ）のいずれにもなり得る。ウォッチャはＳＵＢＳＣＲＩＢＥメッセージにより、プレゼンティティにすべきクライアントと、このプレゼンティティに対して自己がウォッチャになることとをプレゼンスサーバ２００に宣言する。
【００１１】
この実施形態ではＩＥＴＦ（Internet Engineering Task Force）により策定されるＲＦＣ（Request for Comment）３２６５、ＲＦＣ３９０３に準拠する、ＳＩＰによるプレゼンスサービスを利用することを想定する。この実施形態ではさらに、ＶｏＩＰクライアント端末の状態、端末のユーザの状態、およびユーザの行った操作に関する情報をも含めた管理を実現する。クライアント端末の状態には、空き、発信中、通話中、保留中、着信中、転送設定中などがある。以下ではこれらを統合した情報を拡張プレゼンス情報と称する。
【００１２】
図２は、図１の構内交換システム１００、プレゼンスサーバ２００、ＶｏＩＰクライアントの要部構成を示す機能ブロック図である。プレゼンスサーバ２００は、ＳＩＰプロトコルスタックのもとでＳＩＰによるプレゼンスサービスを実現する、周知のプレゼンス機能ブロック２００ａに加え、拡張情報データベース（ＤＢ）２００ｂと、拡張情報生成部２００ｃとを備える。
【００１３】
拡張情報データベース２００ｂは、ＬＡＮを介して授受されるＳＩＰメッセージに含まれる拡張プレゼンス情報をＳＩＰプロトコルスタックから受け取り、蓄積する。拡張情報生成部２００ｃは、拡張情報データベース２００ｂに蓄積された情報を読み出し、ユーザに配信するための配信情報を生成する。この実施形態では通常のプレゼンス情報に操作情報を組み合わせて配信情報を生成する。この新たな配信情報を拡張配信情報と称する。
【００１４】
プレゼンスサーバ２００は、イベントの発生のたびにＶｏＩＰクライアントから通知される拡張プレゼンス情報を拡張情報データベース２００ｂに蓄積する。プレゼンス機能ブロック２００ａはプレゼンスＳＩＰプロトコルスタックから配信トリガを与えられると、拡張情報生成部２００ｃで生成された拡張配信情報をウォッチャに配信する。
【００１５】
拡張情報生成部２００ｃは、プレゼンス情報の配信を要求するクライアント（ウォッチャ）の状態に応じた操作情報を拡張情報データベース２００ｂから取得し、本来のプレゼンス情報にこの操作情報を組み合わせて拡張配信情報を生成する。拡張配信情報の生成のためには、構内交換システム１００に備わる番号計画データベース１００ａ、電話帳データベース１００ｂ、ヘルプ情報データベース１００ｃなどを利用することができる。例えば、操作情報として与えられたダイヤル番号列をキーとして電話帳データベース１００ｂを参照し、発信者名や着信先の情報を特定することができる。またダイヤル番号列をキーとして番号計画データベース１００ａを参照し、起動されたフィーチャを特定することができる。さらに、特定されたフィーチャのヘルプ情報を呼び出すためにヘルプ情報データベース１００ｃを用いることができる。拡張情報生成部２００ｃにより生成された拡張情報はプレゼンス機能ブロック２００ａに与えられ、ＮＯＴＩＦＹやＭＥＳＳＡＧＥなどのＳＩＰメッセージに載せられてＬＡＮに送出される。メッセージの生成、送受信に関わる処理はプレゼンス機能ブロック２００ａが主体となり実行する。
【００１６】
ＶｏＩＰクライアントは通知部１ａを備える。通知部１ａは例えばオフフックや回線捕捉キー押下などの状態変化イベントを生じると、その旨をＰＵＢＬＩＳＨメッセージでプレゼンスサーバ２００に通知する。特にこの通知部１ａは、状態変化イベントをもたらしたユーザの操作を示す操作情報をＰＵＢＬＩＳＨに追記してプレゼンスサーバ２００に通知する。これにより操作情報を含む拡張プレゼンス情報がプレゼンスサーバ２００に通知される。
【００１７】
図３は、拡張情報データベース２００ｂに蓄積される拡張プレゼンス情報のデータ構造の一例を示す図である。プレゼンスサービスにおけるプレゼンス情報とは、ユーザＩＤ（Identification）に状態を組み合わせたものである。状態とは、ユーザ自身の状態、および／またはクライアント端末の状態である。この実施形態ではこれらの情報に、状態の補足情報と操作情報とを統合した情報を拡張プレゼンス情報とする。なおユーザＩＤはユーザを一意に特定できればどのようなデータでもよいが、ＳＩＰによるプレゼンスサービスモデルを利用するにあたってはユーザＩＤとしてＳＩＰ  ＵＲＩ（SIP Uniform Resource Identifier）が適切である。
【００１８】
ユーザ状態としては、「オンライン」、「オフライン」、「取り込み中」、「退席中」など、従来のプレゼンスサービスで定義される状態が考えられる。クライアント状態としては、「空き」、「発信中」、「通話中」、「保留中」、「着信中」、「転送設定中」などが考えられる。
【００１９】
補足情報には、クライアント状態を補足する情報が設定される。例えば、「着信中」や「通話中」状態であればその相手の番号を補足状態として設定する。  
操作情報には、その状態に遷移するために行われた操作が設定される。例えば、着信呼に対してクライアント端末の回線キーを押下して応答し、クライアント状態が「通話中」に遷移したというケースでは、該当回線キーを意味するコードが操作情報に設定される。
【００２０】
補足情報、操作情報のいずれも種々の形式で表現され得る。例えばＳＩＰによるプレゼンスサービスではプレゼンス情報を表現するのにＸＭＬ（eXtended Markup Language）形式を用いている。この実施形態でもこれに則し、例えば新たなタグを定義するなどの方法で既存プレゼンス情報のＸＭＬを拡張して補足情報、操作情報を表現することができる。
【００２１】
図４は、この実施形態における拡張プレゼンス情報の配信予約シーケンスを示す図である。図４において、プレゼンスサービスを要求するＳＩＰ ＵＡ（User Agent）は、自己をウォッチャとし、拡張プレゼンス情報を得ようとするＳＩＰ ＵＡをプレゼンティティとする旨を、配信期間の設定情報などとともにＳＵＢＳＣＲＩＢＥ（Ｆ１）に記載し、これをプレゼンスサーバ２００に送信する。
【００２２】
プレゼンスサーバ２００は、ＳＵＢＳＣＲＩＢＥ（Ｆ１）に記された配信予約要求が適切であれば２００ ＯＫ（Ｆ２）を返信し、ただちにＮＯＴＩＦＹ（Ｆ３）により初回の拡張プレゼンス情報の配信を行う。ＳＩＰ ＵＡ１は、ＮＯＴＩＦＹ（Ｆ３）を受信すると、２００ ＯＫ（Ｆ４）を返信して応答し、その後は拡張プレゼンス情報が更新されるたびに、プレゼンスサーバ２００からＳＩＰ ＵＡ１にＮＯＴＩＦＹメッセージによる除法配信が行われる。このシーケンスはＲＦＣ３２６５に準拠するが、拡張情報に柔軟に対処するための変更や拡張を行うことももちろん可能である。次に、上記構成における作用を２つの実施形態に分けて説明する。
【００２３】
［第１の実施形態］
図５は、拡張プレゼンス情報の配信に関わるシーケンスの第１の実施形態を示す図である。フィーチャの一例として全転送（Call Forward All：ＣＦ−Ａ）を想定し、これを呼び出すための特番を“＃６０１１”とする。またＳＩＰ ＵＡ１は図１のＶｏＩＰ端末１でありＳＩＰ ＵＡ２はＶｏＩＰ端末２であるとし、ＳＩＰ ＵＡ２がＳＩＰ ＵＡ１のウォッチャとして登録されているとして説明する。
【００２４】
図５において、空き状態の端末１のユーザが特番“＃６０１１”を押下すると図６に示す拡張プレゼンス情報がＰＵＢＬＩＳＨ（Ｆ１）に設定され、プレゼンスサーバ２００に送信される。プレゼンスサーバ２００は端末１に２００ ＯＫ（Ｆ２）を返送したのち図６の拡張プレゼンス情報を拡張情報データベース２００ｂに蓄積する（ステップＢ１１）。
【００２５】
次にプレゼンスサーバ２００は、端末１の状態を端末２に通知するためのＮＯＴＩＦＹ（Ｆ３）を生成する。その際、プレゼンスサーバ２００は例えば拡張情報データベース２００ｂを参照して端末２の状態を判定する（ステップＢ１２）。端末２の状態は空き状態であるので、次にプレゼンスサーバ２００は拡張情報データベース２００ｂを検索して（ステップＢ１３）空き状態における操作情報を１つまたは複数取得する（ステップＢ１４）。ここでは図６に示す情報が選択されたとし、この拡張情報をそのままＮＯＴＩＦＹ（Ｆ３）に設定することができる。
【００２６】
次にプレゼンスサーバ２００は、取得した操作情報に対応するフィーチャを番号計画データベース１００ａに問い合わせる（ステップＢ１５）。そうするとダイヤル列“＃６０１１”は、ＣＦ−Ａの起動コードであり、その後に続くダイヤル列”４４８”は内線番号であることが判明する。そこでプレゼンスサーバ２００はさらにヘルプ情報データベース１００ｃを参照し、ＣＦ−Ａに関するヘルプ情報（例えばテキストデータやヘルプ情報へのリンクなど）を取得し（ステップＢ１６）、このヘルプ情報をＮＯＴＩＦＹ（Ｆ３）に設定する。これにより拡張プレゼンス情報が生成される（ステップＢ１７）。拡張プレゼンス情報にはＣＦ−Ａの操作支援のための情報として、例えば“＃６０１１＋内線番号をダイヤルすると、指定した内線番号へのＣＦ−Ａを設定することができます”といったガイダンスメッセージを設定することができる。端末２はＮＯＴＩＦＹ（Ｆ３）を受信し、このメッセージに設定された拡張プレゼンス情報から上記ガイダンスメッセージを読み出し、これをそのままディスプレイに表示する。
【００２７】
以上のようにこの実施形態では、プレゼンティティからプレゼンスサーバ２００へのプレゼンス通知に際して、状態だけでなく、ユーザによりなされた操作情報をも含めたメッセージを生成してこれをプレゼンスサーバ２００に通知する。プレゼンスサーバ２００は拡張情報データベース２００に、プレゼンス情報と操作情報とを組み合わせた拡張プレゼンス情報を蓄積する。そしてウォッチャへの情報配信にあたり、ウォッチャの状態に応じた操作情報を拡張情報データベース２００から読み出し、プレゼンス情報と併せてウォッチャに通知する。すなわちプレゼンスサービスモデルを用いてクライアントのプレゼンス情報を他のクライアントに配信するにあたり、操作情報を蓄積するデータベースからクライアントの状態に応じて適切な操作情報を選択するようにしている。
【００２８】
このように、ユーザにより行われた操作に関する情報をデータベース化して蓄積することにより、プレゼンス情報の配信に際してクライアント（ウォッチャ）の状態に応じた操作情報を配信することが可能になる。従ってクライアント端末のユーザはマニュアルを参照しなくとも、クライアントの状態に応じた適切なアクションを選択し実行することが可能になる。さらにヘルプ情報をも配信することができるので、各ユーザにとっては他のユーザが使用している様々なフィーチャを知ることができるばかりか、その操作に関するガイダンスをも得られる。これらのことからプレゼンスサービス提供システムの利便性を高めることが可能になる。
【００２９】
［第２の実施形態］
図７は、拡張プレゼンス情報の配信に関わるシーケンスの第２の実施形態を示す図である。この実施形態では、ＲＦＣ３４２８で規定されるＭＥＳＳＡＧＥメソッドをプレゼンスサーバ２００に実装し、ＭＥＳＳＡＧＥメソッドにより拡張プレゼンス情報を配信するようにする。図７のシーケンスは、端末１のユーザが番号０１２３４５６７８９の相手先との通話中に端末１の転送キーを押下し、４４８をダイヤルして内線４４８への転送操作を行った状態を想定する。この状態から端末２が同じく０１２３４５６７８９からの着信を受け、そのユーザが応答すると端末２に拡張プレゼンス情報が配信される。
【００３０】
図７において、端末１のユーザが転送操作を行うと、図８に示すような拡張プレゼンス情報がＰＵＢＬＩＳＨ（Ｆ１）によりプレゼンスサーバ２００に通知される。図８の拡張プレゼンス情報には補足情報として相手先発番号”０１２３４５６７８９”が設定される。操作情報には転送キー押下および転送先内線番号”４４８”がセットされる。
【００３１】
ＰＵＢＬＩＳＨを受けたプレゼンスサーバ２００は端末１に２００ＯＫ（Ｆ２）を返送し、拡張情報データベース２００ｂに拡張プレゼンス情報を蓄積する（ステップＢ２１）。その後、再度０１２３４５６７８９からの着信があり端末２がこれにオフフックして応答すると、端末２は空き状態から通話中状態に遷移する。そして、図９に示す拡張プレゼンス情報をＰＵＢＬＩＳＨ（Ｆ３）に設定してプレゼンスサーバ２００に送信する。
【００３２】
プレゼンスサーバ２００は図９の拡張プレゼンス情報を拡張情報データベース２００ｂに蓄積し、端末１の状態を判定する（ステップＢ２２）。次にプレゼンスサーバ２００は拡張情報データベース２００ｂを検索し（ステップＢ２３）、０１２３４５６７８９との通話中に行われた操作を集計して統計的なデータを得る（ステップＢ２４）。この処理で得られた結果から、プレゼンスサーバ２００は頻度の多い操作を少なくとも一つ選択する。ここでは内線４４８への転送操作の頻度が最も多いとする。この操作を示す操作情報には、「端末１から内線４４８への転送」といった情報が含まれる。
【００３３】
これらの情報から拡張プレゼンス情報を生成することができる。さらにこの情報を充実させるため、プレゼンスサーバは”０１２３４５６７８９”に対応する発信者名を電話帳データベース１００ｂに問い合わせ（ステップＢ２５）、転送先の名称を補足情報”０１２３４５６７８９”をキーとして電話帳データベース１００ｂに問い合わせる（ステップＢ２６）。  
以上の処理により、端末２に配信すべき拡張プレゼンス情報（拡張配信情報）が例えば次のようなテキストデータとして生成される（ステップＢ２７）。  
「ＸＹＺ社（０１２３４５６７８９）からの着信は、
８５％がＡｌｉｃｅさん（４４８）へ
１０％がＢｏｂさん（４１２）へ
５％がＣａｒｏｌさん（４４９）へ
転送されています。」
すなわち拡張情報データベース２００ｂに蓄積される拡張プレゼンス情報に対する統計処理により、相手先内線番号ごとに転送の頻度（割合）を示す統計情報を得ることができる。さらに電話帳データベース１００ｂを参照することで、着信を受けた相手先名称”ＸＹＺ社”、および転送先名称”Ａｌｉｃｅ”，”Ｂｏｂ”，”Ｃａｒｏｌ”などを特定することができる。これらの情報はいずれも、ユーザ状態およびクライアント状態に対応付けて拡張プレゼンス情報に記される補足情報、操作情報をキーとして各データベースから取得される。  
最後に、この拡張配信情報はＭＥＳＳＡＧＥ（Ｆ５）に設定され、端末２に配信される。
【００３４】
このように際２の実施形態では、クライアントのプレゼンス情報を他のクライアントへ配信するにあたり、データベースに蓄積された同じフィーチャに関する操作内容から統計的な情報を算出して、拡張配信情報を生成するようにしている。すなわち拡張情報データベース２００ｂに蓄積された操作情報から例えば転送先の統計データを得て、転送の相手先を頻度別に集計するといったきめ細かな情報を生成するようにしている。これをユーザに通知することで、ユーザは環境に応じた適切な転送先を知ることができる。
【００３５】
以上述べたように各実施形態によれば、プレゼンスサービスの利便性を高めることができる。また各実施形態ではＳＩＰのプレゼンスサービスのフレームワークを利用しているので、既存のシステムへの実装も容易である。さらに第２の実施形態によれば、システムが使用されている環境での暗黙知（「○○からの電話は□□さんへ」など）をユーザに提示することができる。
【００３６】
なお、この発明は上記実施の形態に限定されるものではない。例えばＱｏＳ（Quality of Service）情報を拡張プレゼンス情報として配信することにより、ネットワーク混雑時に発信を控えるようユーザに警告したり、ＶｏＩＰクライアント自身が発着信制限をかけたりするといった用途を考えることができる。
【００３７】
さらに、この発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００３８】
【図１】この発明に関わるプレゼンス配信システムの一実施形態を示す図。
【図２】図１の構内交換システム１００、プレゼンスサーバ２００、ＶｏＩＰクライアントの要部構成を示す機能ブロック図。
【図３】拡張情報データベース２００ｂに蓄積される拡張プレゼンス情報のデータ構造の一例を示す図。
【図４】この発明の実施形態における拡張プレゼンス情報の配信予約シーケンスを示す図。
【図５】拡張プレゼンス情報の配信に関わるシーケンスの第１の実施形態を示す図。
【図６】第１の実施形態における拡張プレゼンス情報の一例を示す図。
【図７】拡張プレゼンス情報の配信に関わるシーケンスの第２の実施形態を示す図。
【図８】第２の実施形態における拡張プレゼンス情報の一例を示す図。
【図９】第２の実施形態における拡張プレゼンス情報の一例を示す図。
【符号の説明】
【００３９】
１〜４…ＶｏＩＰクライアント端末、１００…構内交換システム、２００…プレゼンスサーバ、２００ａ…プレゼンス機能ブロック、２００ｂ…拡張情報データベース、２００ｃ…拡張情報生成部、１００ａ…番号計画データベース、１００ｂ…電話帳データベース、１００ｃ…ヘルプ情報データベース
【図１】
0004445559.tif 000002
【図２】
0004445559.tif 000003
【図３】
0004445559.tif 000004
【図４】
0004445559.tif 000005
【図５】
0004445559.tif 000006
【図６】
0004445559.tif 000007
【図７】
0004445559.tif 000008
【図８】
0004445559.tif 000009
【図９】
0004445559.tif 000010