(57)【要約】【課題】プレゼンス情報の提供においてプレゼンスクライアントとプレゼンスサーバとの間で送受されるリクエスト信号を偽装した不正リクエスト信号を検出することを課題とする。【解決手段】プレゼンスクライアントが、任意の文字列で構成されたロケーション情報を周期的に生成し、このロケーション情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバに周期的に送信し、最後に生成されたロケーション情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバに送信し、プレゼンスサーバは、送信されたＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されているロケーション情報を登録しておき、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されているロケーション情報と、最後に登録されたロケーション情報とを比較する。【選択図】図１
2009290358.tif 000002
【特許請求の範囲】
【請求項１】
プレゼンス情報を要求するプレゼンス情報要求装置と当該プレゼンス情報を提供するプレゼンス情報提供装置との間で送受されるリクエスト信号を偽装した不正リクエスト信号を検出可能なプレゼンス情報提供システムであって、
前記プレゼンス情報要求装置は、
任意の文字列で構成された識別情報を周期的に生成して第１の保持手段に保持する手段と、
前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号を前記プレゼンス情報提供装置に周期的に送信する手段と、
最後に生成された前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を前記プレゼンス情報提供装置に送信する手段と、を有し、
前記プレゼンス情報提供装置は、
送信された前記ＲＥＧＩＳＴＥＲリクエスト信号を受信する手段と、
受信した当該ＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に登録しておく手段と、
送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信する手段と、
受信した当該ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、前記第２の保持手段に最後に登録された識別情報とを比較し、一致しない場合に当該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定する手段と、
を有することを特徴とするプレゼンス情報提供システム。
【請求項２】
前記プレゼンス情報提供装置は、
送信された前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第３の保持手段に保持する手段と、
当該第３の保持手段に保持されている前記識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、前記ＳＵＢＳＣＲＩＢＥリクエスト信号に対応する前記プレゼンス情報が蓄積手段に蓄積されている場合には当該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を前記プレゼンス情報要求装置に送信する送信手段と、を更に有し、
前記プレゼンス情報要求装置は、
前記プレゼンス情報提供装置に送信した前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第４の保持手段に保持しておく手段と、
送信されたＮＯＴＩＦＹリクエスト信号を受信する手段と、
受信した当該ＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、前記第４の保持手段に保持されている識別情報とを比較し、一致しない場合に当該ＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定する手段と、
を更に有することを特徴とする請求項１に記載のプレゼンス情報提供システム。
【請求項３】
前記プレゼンス情報要求装置は、
受信した前記ＮＯＴＩＦＹリクエスト信号が前記不正リクエスト信号であると判定した場合に、不正リクエストを受信したことを示す情報を前記プレゼンス情報提供装置に送信することを特徴とする請求項２に記載のプレゼンス情報提供システム。
【請求項４】
プレゼンス情報を要求するプレゼンス情報要求装置であって、
任意の文字列で構成された識別情報を周期的に生成して第１の保持手段に保持する手段と、
前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号を前記プレゼンス情報提供装置に周期的に送信する手段と、
最後に生成された前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を前記プレゼンス情報提供装置に送信する手段と、
前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておく手段と、
識別情報がＲｅｑｕｅｓｔ−ＵＲＩに設定されたＮＯＴＩＦＹリクエスト信号を受信する手段と、
受信した当該ＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、前記第２の保持手段に保持されている識別情報とを比較し、一致しない場合に当該ＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定する手段と、
を有することを特徴とするプレゼンス情報要求装置。
【請求項５】
プレゼンス情報を提供するプレゼンス情報提供装置であって、
任意の文字列で構成された識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＲＥＧＩＳＴＥＲリクエスト信号を受信する手段と、
受信した当該ＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第１の保持手段に登録しておく手段と、
識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信する手段と、
受信した当該ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、前記第１の保持手段に最後に登録された識別情報とを比較し、一致しない場合に当該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定する手段と、
前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておく手段と、
前記第２の保持手段に保持されている前記識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、前記ＳＵＢＳＣＲＩＢＥリクエスト信号に対応する前記プレゼンス情報が蓄積手段に蓄積されている場合には当該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を前記プレゼンス情報要求装置に送信する手段と、
を有することを特徴とするプレゼンス情報提供装置。
【請求項６】
プレゼンス情報を要求するプレゼンス情報要求装置により、
任意の文字列で構成された識別情報を周期的に生成して第１の保持手段に保持するステップと、
前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号を前記プレゼンス情報提供装置に周期的に送信するステップと、
最後に生成された前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を前記プレゼンス情報提供装置に送信するステップと、
前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておくステップと、
識別情報がＲｅｑｕｅｓｔ−ＵＲＩに設定されたＮＯＴＩＦＹリクエスト信号を受信するステップと、
受信した当該ＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、前記第２の保持手段に保持されている識別情報とを比較し、一致しない場合に当該ＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定するステップと、
を有することを特徴とするプレゼンス情報要求方法。
【請求項７】
プレゼンス情報を提供するプレゼンス情報提供装置により、
任意の文字列で構成された識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＲＥＧＩＳＴＥＲリクエスト信号を受信するステップと、
受信した当該ＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第１の保持手段に登録しておくステップと、
識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信するステップと、
受信した当該ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、前記第１の保持手段に最後に登録された識別情報とを比較し、一致しない場合に当該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定するステップと、
前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておくステップと、
前記第２の保持手段に保持されている前記識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、前記ＳＵＢＳＣＲＩＢＥリクエスト信号に対応する前記プレゼンス情報が蓄積手段に蓄積されている場合には当該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を前記プレゼンス情報要求装置に送信するステップと、
を有することを特徴とするプレゼンス情報提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プレゼンス情報の提供においてプレゼンス情報要求装置とプレゼンス情報提供装置との間で送受されるリクエスト信号を偽装した不正リクエスト信号を検出可能なプレゼンス情報提供システム、プレゼンス情報要求装置、プレゼンス情報提供装置、プレゼンス情報要求方法及びプレゼンス情報提供方法の技術に関する。
【背景技術】
【０００２】
現在、ブロードバンドサービスの展開に伴い、人や物の状態（プレゼンス）と通信とを組み合わせた様々なプレゼンスサービスが提供できるようになっている（非特許文献１参照）。このプレゼンスサービスとは、ユーザ自身の情報特性と状態（通話意思，通信可否等）や、携帯電話，パソコン，ＰＤＡ（Personal Digital Assistant）等の装置特性と状態（バッテリー残量，位置情報等）を、通信を行う可能性のある他のユーザに知らせることを可能とするサービスである。これにより、相手が今どのような状態にあるのかを把握可能となるため、ユーザ同士のより円滑なコミュニケーションを実現することができる。
【０００３】
図９は、プレゼンスサービスの概要を示す概要図である。プレゼンスサービスを実現するために必要となるプレゼンスサーバ２１には、収容している各プレゼンスクライアント１１，１２から夫々を識別するロケーション情報や特性情報としてのプレゼンス情報が事前に送信され、登録されている（プレゼンス情報登録：ＲＥＧＩＳＴＥＲ）。そして、プレゼンスサーバ２１は、見る側のプレゼンスクライアント１１から送信された要求（プレゼンス情報要求：ＳＵＢＳＣＲＩＢＥ）に基づいて、見せる側のプレゼンスクライアント１１のプレゼンス情報を通知（プレゼンス情報通知：ＮＯＴＩＦＹ）する。また、プレゼンスサーバ２１は、プレゼンスクライアント１２のプレゼンスが変更（プレゼンス情報変更：ＲＥＧＩＳＴＥＲ又はＰＵＢＬＩＳＨ）された場合に、変更後のプレゼンス情報を更に通知（プレゼンス情報変更通知：ＮＯＴＩＦＹ）することも可能となっている。なお、このようなプレゼンス情報については、オンライン状態及びオフライン状態といった択一的なプレゼンスのみではなく、オンライン状態の場合であっても待機中，通話中，会議中等といった多様なプレゼンスを用いることも可能となっている。
【０００４】
ここで、このようなプレゼンスサービスを実現するための従来の信号処理フローについて説明する。図１０は、プレゼンスサービスの実現に用いる従来のプレゼンス情報提供システムのシステム構成及び機能ブロックを示す構成図である。プレゼンスサーバ２１は、通信ネットワーク３００を介してプレゼンスサーバ２２に接続され、通信ネットワーク３０１を介してプレゼンスクライアント１１及びプレゼンスクライアント１２を収容している。このプレゼンスサーバ２１は、ロケーション情報を管理するロケーション情報管理部２１１と、収容しているプレゼンスクライアント１１，１２からの要求に基づく呼情報を管理する呼情報管理部２１２と、各リクエスト信号の送受信を行う信号送受信部２１３とを備えている。また、プレゼンスサーバ２２は、通信ネットワーク３０２を介してプレゼンスクライアント１３を収容し、プレゼンスサーバ２１と同様の機能ブロックを備えている。更に、各プレゼンスクライアント１１，１２，１３についても、プレゼンスサーバ２１と略同様の機能ブロックを備えている。
【０００５】
図１１は、各リクエスト信号の信号フォーマットの概要を示す概要図である。同図の（ａ）はＲＥＧＩＳＴＥＲリクエスト信号，（ｂ）はＳＵＢＳＣＲＩＢＥリクエスト信号，（ｃ）はＮＯＴＩＦＹリクエスト信号におけるフォーマットの一部を示している。ＲＥＧＩＳＴＥＲリクエスト信号の場合には、送信先アドレスが設定される“Ｒｅｑｕｅｓｔ−ＵＲＩ”と、着信先アドレスが設定される“Ｔｏ”と、発信元アドレスが設定される“Ｆｒｏｍ”と、コンタクトアドレス（自己を識別するロケーション情報）が設定される“Ｃｏｎｔａｃｔ”とで構成されるヘッダ部と、プレゼンス情報が設定されるメッセージボディ部と、で構成されている。ここで、ヘッダ部の各項に設定されるアドレスは、自己を識別可能なｕｓｅｒｉｎｆｏ部と、ＦＱＤＮ（Fully Qualified Domain Name）形式のｈｏｓｔ部とで構成されたＳＩＰ−ＵＲＩ形式のアドレス（ｓｉｐ：ｕｓｅｒｉｎｆｏ＠ＦＱＤＮ）が用いられている。ＳＵＢＳＣＲＩＢＥリクエスト信号及びＮＯＴＩＦＹリクエスト信号の場合についてもＲＥＧＩＳＴＥＲリクエスト信号と同様のフォーマットであるが、プレゼンスクライアントとプレゼンスサーバとの間でのみ処理されるＲＥＧＩＳＴＥＲリクエスト信号とは異なりプレゼンスサーバ間での処理についても用いられるため、転送元のプレゼンスサーバのアドレス（プロキシサーバアドレス）を設定しておく“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”や“Ｒｏｕｔｅ”がヘッダ部に更に用意されている。
【０００６】
図１２は、従来のプレゼンス情報提供システムの信号処理フロー（実施例１）を示すシーケンス図である。この実施例１は、プレゼンスサーバ２１とプレゼンスサーバ２２が連携しており、プレゼンスサーバ２１が収容しているプレゼンスクライアント１１から、プレゼンスサーバ２２が収容しているプレゼンスクライアント１３のプレゼンス参照が要求され、プレゼンスサーバ２２がプレゼンスクライアント１３のプレゼンス情報をプレゼンスクライアント１１に送信する処理の流れについて説明するものである。なお、プレゼンスクライアント１１のロケーション情報管理部１１１が、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を予め生成して保持し、プレゼンスクライアント１３のロケーション情報管理部１３１が、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ１３）を予め生成して保持していることを前提に説明する。
【０００７】
最初に、プレゼンスクライアント１１の信号送受信部１１３が、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ３０１）。
【０００８】
プレゼンスサーバ２１の信号送受信部２１３は、リクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２１１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を保持しておく（ステップＳ３０２）。
【０００９】
また、プレゼンスクライアント１３の信号送受信部１３３が、プレゼンスサーバ２２のアドレス（ｓｉｐ：ｈｏｓｔ２２）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を発信元アドレスとして“Ｆｒｏｍ”に設定し、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ１３）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２２に送信する（ステップＳ３０３）。
【００１０】
プレゼンスサーバ２２の信号送受信部２２３は、リクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２２１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を保持しておく（ステップＳ３０４）。
【００１１】
なお、説明の都合上、プレゼンスクライアント１３から送信されたＲＥＧＩＳＴＥＲリクエスト信号のメッセージボディ部には、同プレゼンスクライアント１３のプレゼンス情報が既に含まれているものとし、プレゼンスサーバ２２は、このプレゼンス情報をプレゼンスクライアント１３に対応付けて蓄積部に蓄積しているものとして以下説明を続ける。
【００１２】
続いて、プレゼンスクライアント１１の信号送受信部１１３は、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ３０５）。
【００１３】
プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｔｏ”に設定されている着信先アドレスを参照する。ここで、プレゼンスサーバ２２のプレゼンスクライアント１３を着信先としているので、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２２に送信する（ステップＳ３０６）。
【００１４】
プレゼンスサーバ２２の信号送受信部２２３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、“Ｔｏ”に設定されている着信先アドレスを参照する。ここで、自己が収容しているプレゼンスクライアント１３を着信先としているので、このＳＵＢＳＣＲＩＢＥリクエスト信号を受け付けて、呼情報管理部２２２が、“Ｃｏｎｔａｃｔ”に設定されているロケーション情報と“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”に設定されている経由したプレゼンスサーバ２１のアドレスとを構成要素とする呼情報を、プレゼンスクライアント１３に関連付けて保持する（ステップＳ３０７）。
【００１５】
プレゼンスサーバ２２の呼情報管理部２２２は、プレゼンスクライアント１３に対応するプレゼンス情報を蓄積部から取得すると共に、呼情報管理部２２２で保持されているプレゼンスクライアント１３に関連する呼情報を取得して（ステップＳ３０８）、呼情報を構成するロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を“Ｃｏｎｔａｃｔ”に設定し、呼情報を構成するプレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を“Ｒｏｕｔｅ”に設定し、取得したプレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を、プレゼンスサーバ２１に送信する（ステップＳ３０９）。
【００１６】
最後に、プレゼンスサーバ２１の信号送受信部２１３は、送信されたＮＯＴＩＦＹリクエスト信号を受信し、“Ｒｏｕｔｅ”を削除したＮＯＴＩＦＹリクエスト信号をプレゼンスクライアント１１に送信する（ステップＳ３１０）。
【００１７】
以上の信号処理フローにより、プレゼンスクライアント１１は、プレゼンスクライアント１３のプレゼンス情報を取得することが可能となっている。
【００１８】
図１３は、従来のプレゼンス情報提供システムの信号処理フロー（実施例２）を示すシーケンス図である。この実施例２は、プレゼンスサーバ２１が収容しているプレゼンスクライアント１１から、同プレゼンスサーバ２１が収容しているプレゼンスクライアント１２のプレゼンス参照が要求され、プレゼンスサーバ２１がプレゼンスクライアント１２のプレゼンス情報をプレゼンスクライアント１１に送信する処理の流れについて説明するものである。なお、プレゼンスクライアント１１のロケーション情報管理部１１１が、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を予め生成して保持し、プレゼンスクライアント１２のロケーション情報管理部１２１が、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ１２）を予め生成して保持していることを前提に説明する。
【００１９】
最初に、プレゼンスクライアント１１の信号送受信部１１３が、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ４０１）。
【００２０】
プレゼンスサーバ２１の信号送受信部２１３は、リクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２１１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を保持しておく（ステップＳ４０２）。
【００２１】
また、プレゼンスクライアント１２の信号送受信部１２３が、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ１２）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ４０３）。
【００２２】
プレゼンスサーバ２１の信号送受信部２１３は、リクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２１１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を保持しておく（ステップＳ４０４）。
【００２３】
なお、説明の都合上、プレゼンスクライアント１２から送信されたＲＥＧＩＳＴＥＲリクエスト信号のメッセージボディ部には、同プレゼンスクライアント１２のプレゼンス情報が既に含まれているものとし、プレゼンスサーバ２１は、このプレゼンス情報をプレゼンスクライアント１２に対応付けて蓄積部に蓄積している状態として以下説明を続ける。
【００２４】
続いて、プレゼンスクライアント１１の信号送受信部１１３は、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、自己のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ４０５）。
【００２５】
プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、“Ｔｏ”に設定されている着信先アドレスを参照する。ここで、自己が収容しているプレゼンスクライアント１２を着信先としているので、このＳＵＢＳＣＲＩＢＥリクエスト信号を受け付けて、呼情報管理部２１２が、“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を構成要素とする呼情報を、プレゼンスクライアント１２に関連付けて保持する（ステップＳ４０６）。
【００２６】
プレゼンスサーバ２１の呼情報管理部２１２は、プレゼンスクライアント１２に対応するプレゼンス情報を蓄積部から取得すると共に、呼情報管理部２１２で保持されているプレゼンスクライアント１２に関連する呼情報を取得して（ステップＳ４０７）、呼情報を構成するロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を“Ｃｏｎｔａｃｔ”に設定し、取得したプレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を、プレゼンスクライアント１１に送信する（ステップＳ４０８）。
【００２７】
以上の信号処理フローにより、プレゼンスクライアント１１は、プレゼンスクライアント１２のプレゼンス情報を取得することが可能となっている。
【非特許文献１】鈴木  茂房、外３名、「プレゼンスという名のＢＢ時代の新たなサービスに向けて」、ＮＴＴ技術ジャーナル、2003年6月、p.62-65
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかしながら、ＳＵＢＳＣＲＩＢＥリクエスト信号やＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩにユーザ名や自身の電話番号といった容易に他者に推測されうる値を用いているため、各リクエスト信号の詐称が行われるといった問題があった。より具体的には、偽装プレゼンスクライアントや偽装プレゼンスサーバからの攻撃によって、本来的にプレゼンス情報の購読が許可されていない攻撃者にプレゼンス情報が送信されたり、プレゼンス情報の購読が許可されているプレゼンスクライアントに対するプレゼンス情報の配信が中止されたり、偽装されたプレゼンス情報がユーザに配信され、例えばオンライン状態であるにもかかわらず、オフライン状態であるかのような間違った情報に基づいてユーザの判断がなされてしまうという可能性があった。
【００２９】
本発明は、上記に鑑みてなされたものであり、プレゼンス情報の提供においてプレゼンスクライアントとプレゼンスサーバとの間で送受されるリクエスト信号を偽装した不正リクエスト信号を検出可能なプレゼンス情報提供システム、プレゼンス情報要求装置、プレゼンス情報提供装置、プレゼンス情報要求方法及びプレゼンス情報提供方法を提供することを課題とする。
【課題を解決するための手段】
【００３０】
請求項１に記載の本発明は、プレゼンス情報を要求するプレゼンス情報要求装置と当該プレゼンス情報を提供するプレゼンス情報提供装置との間で送受されるリクエスト信号を偽装した不正リクエスト信号を検出可能なプレゼンス情報提供システムであって、前記プレゼンス情報要求装置は、任意の文字列で構成された識別情報を周期的に生成して第１の保持手段に保持する手段と、前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号を前記プレゼンス情報提供装置に周期的に送信する手段と、最後に生成された前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を前記プレゼンス情報提供装置に送信する手段と、を有し、前記プレゼンス情報提供装置は、送信された前記ＲＥＧＩＳＴＥＲリクエスト信号を受信する手段と、受信した当該ＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に登録しておく手段と、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信する手段と、受信した当該ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、前記第２の保持手段に最後に登録された識別情報とを比較し、一致しない場合に当該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定する手段と、を有することを要旨とする。
【００３１】
本発明にあっては、プレゼンス情報要求装置が、任意の文字列で構成された識別情報を周期的に生成し、この識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンス情報提供装置に周期的に送信し、最後に生成された識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンス情報提供装置に送信し、プレゼンス情報提供装置は、送信されたＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を登録しておき、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、最後に登録された識別情報とを比較し、一致しない場合に該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定するため、プレゼンス情報提供装置に対する不正なリクエスト信号を検出することが可能となり、より具体的には、成りすまし攻撃に対するプレゼンス情報の誤送信や、プレゼンス情報配信の誤停止を低減することができる。
【００３２】
請求項２に記載の本発明は、前記プレゼンス情報提供装置が、送信された前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第３の保持手段に保持する手段と、当該第３の保持手段に保持されている前記識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、前記ＳＵＢＳＣＲＩＢＥリクエスト信号に対応する前記プレゼンス情報が蓄積手段に蓄積されている場合には当該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を前記プレゼンス情報要求装置に送信する送信手段と、を更に有し、前記プレゼンス情報要求装置は、前記プレゼンス情報提供装置に送信した前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第４の保持手段に保持しておく手段と、送信されたＮＯＴＩＦＹリクエスト信号を受信する手段と、受信した当該ＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、前記第４の保持手段に保持されている識別情報とを比較し、一致しない場合に当該ＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定する手段と、を更に有することを要旨とする。
【００３３】
本発明にあっては、プレゼンス情報提供装置が、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を保持し、保持した識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、ＳＵＢＳＣＲＩＢＥリクエスト信号に対応するプレゼンス情報が蓄積されている場合には該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号をプレゼンス情報要求装置に送信し、プレゼンス情報要求装置は、プレゼンス情報提供装置に送信したＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を保持しておき、送信されたＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、保持している識別情報とを比較し、一致しない場合にＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定するため、プレゼンス情報要求装置に対する不正なリクエスト信号を検出することが可能となり、より具体的には、偽装されたプレゼンス情報に基づくユーザの誤判断を低減することができる。
【００３４】
請求項３に記載の本発明は、前記プレゼンス情報要求装置が、受信した前記ＮＯＴＩＦＹリクエスト信号が前記不正リクエスト信号であると判定した場合に、不正リクエストを受信したことを示す情報を前記プレゼンス情報提供装置に送信することを要旨とする。
【００３５】
本発明にあっては、プレゼンス情報要求装置が、受信したＮＯＴＩＦＹリクエスト信号が不正リクエスト信号であると判定した場合に、不正リクエストを受信したことを示す情報をプレゼンス情報提供装置に送信するため、プレゼンス情報要求装置に対する偽装プレゼンス情報提供装置からの攻撃があったことをプレゼンス情報提供サーバの保守者に通知することができる。
【００３６】
請求項４に記載の本発明は、プレゼンス情報を要求するプレゼンス情報要求装置であって、任意の文字列で構成された識別情報を周期的に生成して第１の保持手段に保持する手段と、前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号を前記プレゼンス情報提供装置に周期的に送信する手段と、最後に生成された前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を前記プレゼンス情報提供装置に送信する手段と、前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておく手段と、識別情報がＲｅｑｕｅｓｔ−ＵＲＩに設定されたＮＯＴＩＦＹリクエスト信号を受信する手段と、受信した当該ＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、前記第２の保持手段に保持されている識別情報とを比較し、一致しない場合に当該ＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定する手段と、を有することを要旨とする。
【００３７】
請求項５に記載の本発明は、プレゼンス情報を提供するプレゼンス情報提供装置であって、任意の文字列で構成された識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＲＥＧＩＳＴＥＲリクエスト信号を受信する手段と、受信した当該ＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第１の保持手段に登録しておく手段と、識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信する手段と、受信した当該ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、前記第１の保持手段に最後に登録された識別情報とを比較し、一致しない場合に当該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定する手段と、前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておく手段と、前記第２の保持手段に保持されている前記識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、前記ＳＵＢＳＣＲＩＢＥリクエスト信号に対応する前記プレゼンス情報が蓄積手段に蓄積されている場合には当該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を前記プレゼンス情報要求装置に送信する手段と、を有することを要旨とする。
【００３８】
請求項６に記載の本発明は、プレゼンス情報を要求するプレゼンス情報要求装置により、任意の文字列で構成された識別情報を周期的に生成して第１の保持手段に保持するステップと、前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＲＥＧＩＳＴＥＲリクエスト信号を前記プレゼンス情報提供装置に周期的に送信するステップと、最後に生成された前記識別情報を前記第１の保持手段から読み出して、当該識別情報をＣｏｎｔａｃｔヘッダ部に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を前記プレゼンス情報提供装置に送信するステップと、前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておくステップと、識別情報がＲｅｑｕｅｓｔ−ＵＲＩに設定されたＮＯＴＩＦＹリクエスト信号を受信するステップと、受信した当該ＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されている識別情報と、前記第２の保持手段に保持されている識別情報とを比較し、一致しない場合に当該ＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定するステップと、を有することを要旨とする。
【００３９】
請求項７に記載の本発明は、プレゼンス情報を提供するプレゼンス情報提供装置により、任意の文字列で構成された識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＲＥＧＩＳＴＥＲリクエスト信号を受信するステップと、受信した当該ＲＥＧＩＳＴＥＲリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第１の保持手段に登録しておくステップと、識別情報がＣｏｎｔａｃｔヘッダ部に設定されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信するステップと、受信した当該ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報と、前記第１の保持手段に最後に登録された識別情報とを比較し、一致しない場合に当該ＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定するステップと、前記ＳＵＢＳＣＲＩＢＥリクエスト信号のＣｏｎｔａｃｔヘッダ部に設定されている識別情報を第２の保持手段に保持しておくステップと、前記第２の保持手段に保持されている前記識別情報をＲｅｑｕｅｓｔ−ＵＲＩに設定すると共に、前記ＳＵＢＳＣＲＩＢＥリクエスト信号に対応する前記プレゼンス情報が蓄積手段に蓄積されている場合には当該プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を前記プレゼンス情報要求装置に送信するステップと、を有することを要旨とする。
【発明の効果】
【００４０】
本発明によれば、プレゼンス情報の提供においてプレゼンスクライアントとプレゼンスサーバとの間で送受されるリクエスト信号を偽装した不正リクエスト信号を検出可能なプレゼンス情報提供システム、プレゼンス情報要求装置、プレゼンス情報提供装置、プレゼンス情報要求方法及びプレゼンス情報提供方法を提供することができる。
【発明を実施するための最良の形態】
【００４１】
以下、本発明の実施の形態について図面を用いて説明する。
【００４２】
図１は、プレゼンスサービスの実現に用いる本実施の形態に係るプレゼンス情報提供システムのシステム構成及び機能ブロックを示す構成図である。このプレゼンス情報提供システムは、プレゼンス情報を提供するプレゼンス情報提供装置としてのプレゼンスサーバ２１及びプレゼンスサーバ２２と、プレゼンス情報を要求するプレゼンス情報要求装置としてのプレゼンスクライアント１１，プレゼンスクライアント１２，プレゼンスクライアント１３とで構成されている。
【００４３】
プレゼンスサーバ２１は、通信ネットワーク３００を介してプレゼンスサーバ２２に接続され、通信ネットワーク３０１を介してプレゼンスクライアント１１及びプレゼンスクライアント１２を収容している。このプレゼンスサーバ２１は、ＲＥＧＩＴＳＥＲリクエスト信号，ＳＵＢＳＣＲＩＢＥリクエスト信号，ＮＯＴＩＦＹリクエスト信号を処理するサーバであって、プレゼンスクライアント１１，１２から夫々送信された各ロケーション情報を管理するロケーション情報管理部２１１と、その各ロケーション情報を保持可能なロケーション情報保持部２１５と、プレゼンスクライアント１１，１２からの各要求に基づく各呼情報を管理する呼情報管理部２１２と、その各呼情報を保持可能な呼情報保持部２１６と、各リクエスト信号の送受信を行う信号送受信部２１３と、プレゼンスクライアント１１，１２から送信されたＳＵＢＳＣＲＩＢＥリクエスト信号に設定されているロケーション情報とロケーション情報保持部２１５に登録されているロケーション情報とを比較して同一性を判定するロケーション情報比較判定部２１４と、プレゼンスクライアント１１，１２から夫々送信された各プレゼンス情報を蓄積しておくプレゼンス情報蓄積部２１７とを備えた構成である。
【００４４】
特に、信号送受信部２１３については、プレゼンスクライアント１１，１２から送信されたＲＥＧＩＳＴＥＲリクエスト信号及びＳＵＢＳＣＲＩＢＥリクエスト信号を受信する機能と、プレゼンスクライアント１１，１２とプレゼンスサーバ２２との間でＳＵＢＳＣＲＩＢＥリクエスト信号及びＮＯＴＩＦＹリクエスト信号を中継（転送）する機能と、ＮＯＴＩＦＹリクエスト信号を送信する機能とを備えている。
【００４５】
プレゼンスサーバ２２は、通信ネットワーク３０２を介してプレゼンスクライアント１３を収容している。なお、プレゼンスサーバ２１と同様の機能ブロックを備えているので、ここでは重複する説明は省略することにする。
【００４６】
プレゼンスクライアント１１は、自己を識別する識別情報であって任意（ランダム）の英数文字列のｕｓｅｒｉｎｆｏ部とｈｏｓｔｓ部とで構成されたＳＩＰ−ＵＲＩ形式のロケーション情報を周期的に生成するロケーション情報管理部１１１と、その各ロケーション情報を保持可能なロケーション情報保持部１１５と、プレゼンスサーバ２１に送信したＳＵＢＳＣＲＩＢＥリクエスト信号に対応する呼情報を管理する呼情報管理部１１２と、その呼情報を保持可能な呼情報保持部１１６と、各リクエスト信号の送受信を行う信号送受信部１１３と、プレゼンスサーバ２１から送信されたＮＯＴＩＦＹリクエスト信号に設定されているロケーション情報と呼情報保持部１１６に保持されているロケーション情報とを比較して同一性を判定するロケーション情報比較判定部１１４とを備えた構成である。
【００４７】
特に、信号送受信部１１３については、ロケーション情報をロケーション情報保持部１１５から読み出して、そのロケーション情報を設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に送信する機能と、最後に生成されたロケーション情報をロケーション情報保持部１１５から読み出して、その最後のロケーション情報を設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２１に送信する機能と、プレゼンスサーバ２１から送信又は転送されたＮＯＴＩＦＹリクエスト信号を受信する機能とを備えている。このようなプレゼンスクライアントとしては、例えば、携帯電話，パソコン，ＰＤＡ等の端末装置を用いることが可能である。
【００４８】
プレゼンスクライアント１２，１３については、プレゼンスクライアント１１と同様の機能ブロックを備えているので、ここでは重複する説明は省略することにする。
【００４９】
なお、プレゼンスサーバ２１，２２と、プレゼンスクライアント１１，１２，１３との夫々は、コンピュータで構成され、各機能部の処理はプログラムで実行されるようになっている。
【００５０】
図２は、各リクエスト信号の信号フォーマットの概要を示す概要図である。同図の（ａ）はＲＥＧＩＳＴＥＲリクエスト信号，（ｂ）はＳＵＢＳＣＲＩＢＥリクエスト信号，（ｃ）はＮＯＴＩＦＹリクエスト信号におけるフォーマットの一部を示している。これら信号フォーマットは、図１１を用いて説明した従来の各信号フォーマットと同様であって、ＲＥＧＩＳＴＥＲリクエスト信号の場合には、送信先アドレスが設定される“Ｒｅｑｕｅｓｔ−ＵＲＩ”と、着信先アドレスが設定される“Ｔｏ”と、発信元アドレスが設定される“Ｆｒｏｍ”と、コンタクトアドレス（自己を識別するロケーション情報）が設定される“Ｃｏｎｔａｃｔ”とで構成されるヘッダ部と、プレゼンス情報が設定されるメッセージボディ部と、で構成されている。ここで、ヘッダ部の各項に設定されるアドレスは、自己を識別可能なｕｓｅｒｉｎｆｏ部と、ＦＱＤＮ形式のｈｏｓｔ部とで構成されたＳＩＰ−ＵＲＩ形式のアドレス（ｓｉｐ：ｕｓｅｒｉｎｆｏ＠ＦＱＤＮ）が用いられている。ＳＵＢＳＣＲＩＢＥリクエスト信号及びＮＯＴＩＦＹリクエスト信号の場合についてもＲＥＧＩＳＴＥＲリクエスト信号と同様のフォーマットであるが、プレゼンスクライアントとプレゼンスサーバとの間でのみ処理されるＲＥＧＩＳＴＥＲリクエスト信号とは異なりプレゼンスサーバ間での処理についても用いられるため、転送元のプレゼンスサーバのアドレス（プロキシサーバアドレス）を設定しておく“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”や“Ｒｏｕｔｅ”がヘッダ部に更に用意されている。
【００５１】
図３は、本実施の形態に係るプレゼンス情報提供システムの信号処理フロー（実施例１）を示すシーケンス図である。この実施例１は、プレゼンスサーバ２１が収容しているプレゼンスクライアント１１から、プレゼンスサーバ２２が収容しているプレゼンスクライアント１３のプレゼンス参照が要求され、プレゼンスサーバ２２がプレゼンスクライアント１３のプレゼンス情報をプレゼンスクライアント１１に送信する処理の流れについて説明するものである。なお、プレゼンスサーバ２１のアドレスやプレゼンスクライアント１１，１３のアドレスについては、プレゼンスクライアント１１の記憶手段（図１において未記載）に読み出し可能に記憶されているものとして説明する。
【００５２】
最初に、プレゼンスクライアント１１のロケーション情報管理部１１１が、第三者が推測困難な任意（ランダム）の英数文字列をｕｓｅｒｉｎｆｏ部に設定したロケーション情報（例えば、ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を周期的に生成し、生成時刻に関連付けてロケーション情報保持部１１５に保持しておく（ステップＳ１０１）。なお、このロケーション情報は生成される度に異なる値に設定することが望ましい。また、生成時刻に関連付けてロケーション情報を登録するのではなく、最後に生成されたロケーション情報のみを登録しておく場合であってもよい。
【００５３】
続いて、プレゼンスクライアント１１の信号送受信部１１３が、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、ロケーション情報保持部１１５に保持されている自己のロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に周期的に送信する（ステップＳ１０２）。なお、送信されるＲＥＧＩＳＴＥＲリクエスト信号に設定されるロケーション情報とは、ステップＳ１０１において最後に生成されたロケーション情報、言い換えれば、最も新しく生成されたロケーション情報である。
【００５４】
プレゼンスサーバ２１の信号送受信部２１３は、送信されたＲＥＧＩＳＴＥＲリクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２１１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を、ＲＥＧＩＳＴＥＲリクエスト信号の受信時刻や受信した順番等に関連付けてロケーション情報保持部２１５に登録しておく（ステップＳ１０３）。なお、受信時刻や受信した順番に関連付けてロケーション情報を登録するのではなく、最後に送信されたロケーション情報のみを登録しておく場合であってもよい。
【００５５】
また、プレゼンスクライアント１３のロケーション情報管理部１３１が、ステップＳ１０１と同様に、第三者が推測困難な任意（ランダム）の英数文字列をｕｓｅｒｉｎｆｏ部に設定したロケーション情報（例えば、ｓｉｐ：ｚｚｚｚ＠ｈｏｓｔ１３）を周期的に生成し、生成時刻に関連付けてロケーション情報保持部１３５に保持しておく（ステップＳ１０４）。なお、このロケーション情報は生成される度に異なる値が設定することが望ましい。また、ステップＳ１０１と同様に、生成時刻に関連付けてロケーション情報を登録するのではなく、最後に生成されたロケーション情報のみを登録しておく場合であってもよい。
【００５６】
続いて、プレゼンスクライアント１３の信号送受信部１３３が、プレゼンスサーバ２２のアドレス（ｓｉｐ：ｈｏｓｔ２２）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を発信元アドレスとして“Ｆｒｏｍ”に設定し、ロケーション情報保持部１３５に保持されている自己のロケーション情報（ｓｉｐ：ｚｚｚｚ＠ｈｏｓｔ１３）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２２に周期的に送信する（ステップＳ１０５）。なお、送信されるＲＥＧＩＳＴＥＲリクエスト信号に設定されるロケーション情報とは、ステップＳ１０４において最後に生成されたロケーション情報、言い換えれば、最も新しく生成されたロケーション情報である。
【００５７】
プレゼンスサーバ２２の信号送受信部２２３は、送信されたＲＥＧＩＳＴＥＲリクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２２１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を、ＲＥＧＩＳＴＥＲリクエスト信号の受信時刻や受信した順番等に関連付けてロケーション情報保持部２２５に登録しておく（ステップＳ１０６）。なお、ステップＳ１０３と同様に、受信時刻や受信した順番に関連付けてロケーション情報を登録するのではなく、最後に送信されたロケーション情報のみを登録しておく場合であってもよい。
【００５８】
以上のステップＳ１０１〜ステップＳ１０６が、各プレゼンスクライアント１１，１３から収容元のプレゼンスサーバ２１，２２に各ロケーション情報を夫々登録する信号処理フローである。続いて、プレゼンス情報を送受信する信号処理フローについて説明する。なお、説明の都合上、プレゼンスクライアント１３から送信されたＲＥＧＩＳＴＥＲリクエスト信号のメッセージボディ部には、同プレゼンスクライアント１３のプレゼンス情報が既に含まれているものとし、プレゼンスサーバ２２は、このプレゼンス情報をプレゼンスクライアント１３に対応付けてプレゼンス情報蓄積部２２７に蓄積しているものとする。
【００５９】
プレゼンスクライアント１１の信号送受信部１１３は、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、ロケーション情報保持部１１５に最後に生成されて保持されている自己のロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ１０７）。
【００６０】
そして、プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、ロケーション情報比較判定部２１４が、受信したＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報と、ロケーション情報保持部２１５に最後に登録されているロケーション情報とを比較し、一致しない場合に、送信されたＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定する（ステップＳ１０８）。この判定の結果、ロケーション情報が一致する場合には後段のステップＳ１０９に進み、ロケーション情報が一致しない場合にはエラーレスポンスをプレゼンスクライアント１１に送信する。
【００６１】
ステップＳ１０８の比較においてそれらロケーション情報が一致する場合に、プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｔｏ”に設定されている着信先アドレスを参照する。ここで、プレゼンスサーバ２２のプレゼンスクライアント１３を着信先としているので、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２２に送信する（ステップＳ１０９）。
【００６２】
プレゼンスサーバ２２の信号送受信部２２３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、“Ｔｏ”に設定されている着信先アドレスを参照する。ここで、自己が収容しているプレゼンスクライアント１３を着信先としているので、このＳＵＢＳＣＲＩＢＥリクエスト信号を受け付けると共に、送信されたＲＥＧＩＳＴＥＲリクエスト信号を受け入れたことを示す２００番の応答情報を返信し、呼情報管理部２２２が、“Ｃｏｎｔａｃｔ”に設定されているロケーション情報と“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”に設定されている経由したプレゼンスサーバ２１のアドレスとを構成要素とする呼情報を、プレゼンスクライアント１３に関連付けて呼情報保持部２２６に保持する（ステップＳ１１０）。
【００６３】
プレゼンスサーバ２１の信号送受信部２１３は、返信された２００番の応答情報をプレゼンスクライアント１１に転送し、プレゼンスクライアント１１は、２００番の応答情報を受信することによりステップＳ１０７で送信したＳＵＢＳＣＲＩＢＥリクエスト信号が正常に受け入れられたと判断し、そのＳＵＢＳＣＲＩＢＥリクエストの“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を呼情報として呼情報保持部１１６に保持しておく（ステップＳ１１１）。
【００６４】
一方、プレゼンスサーバ２２の呼情報管理部２２２は、プレゼンスクライアント１３に対応するプレゼンス情報をプレゼンス情報蓄積部２２７から読み出すと共に、呼情報保持部２２６で保持されているプレゼンスクライアント１３に関連する呼情報を読み出して（ステップＳ１１２）、呼情報を構成するロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を“Ｃｏｎｔａｃｔ”に設定し、呼情報を構成するプレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を“Ｒｏｕｔｅ”に設定し、読み出したプレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を、プレゼンスサーバ２１に送信する（ステップＳ１１３）。
【００６５】
プレゼンスサーバ２１の信号送受信部２１３は、送信されたＮＯＴＩＦＹリクエスト信号を受信し、“Ｒｏｕｔｅ”を削除したＮＯＴＩＦＹリクエスト信号をプレゼンスクライアント１１に送信する（ステップＳ１１４）。
【００６６】
最後に、プレゼンスクライアント１１の信号送受信部１１３は、送信されたＮＯＴＩＦＹリクエスト信号を受信し、ロケーション情報比較判定部１１４が、受信したＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されているロケーション情報と、呼情報保持部１１６に保持されているロケーション情報とを比較し、一致しない場合に、送信されたＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定する（ステップＳ１１５）。
【００６７】
続いて、このような実施例１の信号処理フローにおいて、正規プレゼンスクライアント１１として偽装した偽装プレゼンスクライアント１１’が、正規プレゼンスサーバ２２が収容している正規プレゼンスクライアント１３のプレゼンス参照を正規プレゼンスサーバ２１に要求した場合について説明する。図４は、偽装プレゼンスクライアントからのプレゼンス情報購読要求時の信号処理フローを示すフローチャートである。ここでは、実施例１で説明したステップＳ１０１〜ステップＳ１０６以降の信号処理フローについて説明する。
【００６８】
偽装プレゼンスクライアント１１’は、正規プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、正規プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、正規プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、正規プレゼンスクライアント１１のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を正規プレゼンスサーバ２１に送信する（ステップＳ１０７’）。
【００６９】
その後、正規プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、ロケーション情報比較判定部２１４が、受信したＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）と、ロケーション情報保持部２１５に最後に登録されているロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）とを比較する。（ステップＳ１０８’）。
【００７０】
この比較の結果、ロケーション情報が一致しないので、ロケーション情報比較判定部２１４は、送信されたＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定し、信号送受信部２１３は、エラーレスポンスを偽装プレゼンスクライアント１１’に送信する。以上の信号処理フローにより、正規プレゼンスサーバに対する不正なリクエスト信号を検出することが可能となる。より具体的には、成りすまし攻撃に対するプレゼンス情報の誤送信や、プレゼンス情報配信の誤停止を低減することができる。
【００７１】
更に続いて、上述の実施例１の信号処理フローにおいて、正規プレゼンスサーバ２１として偽装した偽装プレゼンスサーバ２１’が、正規プレゼンスサーバ２１が収容している正規プレゼンスクライアント１１へ偽装プレゼンス情報を送信した場合について説明する。図５は、偽装プレゼンスサーバによる偽装プレゼンス情報送信時の信号処理フローを示すフローチャートである。ここでは、実施例１で説明したステップＳ１０１〜ステップＳ１１３以降の信号処理フローについて説明する。
【００７２】
偽装プレゼンスサーバ２１’が、正規プレゼンスクライアント１１のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、正規プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を着信先アドレスとして“Ｔｏ”に設定し、正規プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、正規プレゼンスクライアント１３のアドレス（ｓｉｐ：ｕｓｅｒ１３＠ｈｏｓｔ２２）を“Ｃｏｎｔａｃｔ”に設定し、偽装プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を、正規プレゼンスクライアント１１に送信する（ステップＳ１１４’）。
【００７３】
その後、プレゼンスクライアント１１の信号送受信部１１３は、送信されたＮＯＴＩＦＹリクエスト信号を受信し、ロケーション情報比較判定部１１４が、受信したＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されているロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）と、呼情報保持部１１６に保持されているロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）とを比較する（ステップＳ１１５’）。
【００７４】
この比較の結果、ロケーション情報が一致しないので、ロケーション情報比較判定部１１４は、送信されたＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定し、信号送受信部１１３は、不正リクエストを受信したことを示すエラーレスポンス情報を正規プレゼンスクサーバ２１に送信する。以上の信号処理フローにより、正規プレゼンスクライアントに対する不正なリクエスト信号を検出することが可能となる。より具体的には、偽装された偽装プレゼンス情報に基づくユーザの誤判断を低減することができる。また、正規プレゼンスクライアントに対する偽装プレゼンスサーバからの攻撃があったことを正規プレゼンスサーバの保守者に通知することができる。
【００７５】
図６は、本実施の形態に係るプレゼンス情報提供システムの信号処理フロー（実施例２）を示すシーケンス図である。この実施例２は、プレゼンスサーバ２１が収容しているプレゼンスクライアント１１から、同プレゼンスサーバ２１が収容しているプレゼンスクライアント１２のプレゼンス参照が要求され、プレゼンスサーバ２１がプレゼンスクライアント１２のプレゼンス情報をプレゼンスクライアント１１に送信する処理の流れについて説明するものである。なお、プレゼンスサーバ２１のアドレスやプレゼンスクライアント１１，１２のアドレスについては、プレゼンスクライアント１１の記憶手段（図１において未記載）に読み出し可能に記憶されているものとして説明する。
【００７６】
最初に、プレゼンスクライアント１１のロケーション情報管理部１１１が、第三者が推測困難な任意（ランダム）の英数文字列をｕｓｅｒｉｎｆｏ部に設定したロケーション情報（例えば、ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を周期的に生成し、生成時刻に関連付けてロケーション情報保持部１１５に保持しておく（ステップＳ２０１）。なお、このロケーション情報は生成される度に異なる値に設定することが望ましい。また、生成時刻に関連付けてロケーション情報を登録するのではなく、最後に生成されたロケーション情報のみを登録しておく場合であってもよい。
【００７７】
続いて、プレゼンスクライアント１１の信号送受信部１１３が、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、ロケーション情報保持部１１５に保持されている自己のロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に周期的に送信する（ステップＳ２０２）。なお、送信されるＲＥＧＩＳＴＥＲリクエスト信号に設定されるロケーション情報とは、ステップＳ２０１において最後に生成されたロケーション情報、言い換えれば、最も新しく生成されたロケーション情報である。
【００７８】
プレゼンスサーバ２１の信号送受信部２１３は、送信されたＲＥＧＩＳＴＥＲリクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２１１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を、ＲＥＧＩＳＴＥＲリクエスト信号の受信時刻や受信した順番等に関連付けてロケーション情報保持部２１５に登録しておく（ステップＳ２０３）。なお、受信時刻や受信した順番に関連付けてロケーション情報を登録するのではなく、最後に送信されたロケーション情報のみを登録しておく場合であってもよい。
【００７９】
また、プレゼンスクライアント１２のロケーション情報管理部１２１が、ステップＳ２０１と同様に、第三者が推測困難な任意（ランダム）の英数文字列をｕｓｅｒｉｎｆｏ部に設定したロケーション情報（例えば、ｓｉｐ：ｙｙｙｙ＠ｈｏｓｔ１２）を周期的に生成し、生成時刻に関連付けてロケーション情報保持部１２５に保持しておく（ステップＳ２０４）。なお、このロケーション情報は生成される度に異なる値が設定することが望ましい。また、ステップＳ２０１と同様に、生成時刻に関連付けてロケーション情報を登録するのではなく、最後に生成されたロケーション情報のみを登録しておく場合であってもよい。
【００８０】
続いて、プレゼンスクライアント１２の信号送受信部１２３が、プレゼンスサーバ２１のアドレス（ｓｉｐ：ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、ロケーション情報保持部１２５に保持されている自己のロケーション情報（ｓｉｐ：ｙｙｙｙ＠ｈｏｓｔ１２）を“Ｃｏｎｔａｃｔ”に設定したＲＥＧＩＳＴＥＲリクエスト信号をプレゼンスサーバ２１に周期的に送信する（ステップＳ２０５）。なお、送信されるＲＥＧＩＳＴＥＲリクエスト信号に設定されるロケーション情報とは、ステップＳ２０４において最後に生成されたロケーション情報、言い換えれば、最も新しく生成されたロケーション情報である。
【００８１】
プレゼンスサーバ２１の信号送受信部２１３は、送信されたＲＥＧＩＳＴＥＲリクエスト信号を受け入れたことを示す２００番の応答情報を返信し、ロケーション情報管理部２１１が、送信されたＲＥＧＩＳＴＥＲリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を、ＲＥＧＩＳＴＥＲリクエスト信号の受信時刻や受信した順番等に関連付けてロケーション情報保持部２１５に登録しておく（ステップＳ２０６）。なお、ステップＳ２０３と同様に、受信時刻や受信した順番に関連付けてロケーション情報を登録するのではなく、最後に送信されたロケーション情報のみを登録しておく場合であってもよい。
【００８２】
以上のステップＳ２０１〜ステップＳ２０６が、プレゼンスクライアント１１，１２からプレゼンスサーバ２１にロケーション情報を登録する信号処理フローである。続いて、プレゼンス情報を送受信する信号処理フローについて説明する。なお、説明の都合上、プレゼンスクライアント１２から送信されたＲＥＧＩＳＴＥＲリクエスト信号のメッセージボディ部には、同プレゼンスクライアント１２のプレゼンス情報が既に含まれているものとし、プレゼンスサーバ２１は、このプレゼンス情報をプレゼンスクライアント１２に対応付けてプレゼンス情報蓄積部２１７に蓄積しているものとする。
【００８３】
プレゼンスクライアント１１の信号送受信部１１３は、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、ロケーション情報保持部１１５に最後に生成されて保持されている自己のロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号をプレゼンスサーバ２１に送信する（ステップＳ２０７）。
【００８４】
そして、プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、ロケーション情報比較判定部２１４が、受信したＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報と、ロケーション情報保持部２１５に最後に登録されているロケーション情報とを比較し、一致しない場合に、送信されたＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定する（ステップＳ２０８）。この判定の結果、ロケーション情報が一致する場合には後段のステップＳ２０９に進み、ロケーション情報が一致しない場合にはエラーレスポンスをプレゼンスクライアント１１に送信する。
【００８５】
ステップＳ２０８の比較においてそれらロケーション情報が一致する場合に、プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｔｏ”に設定されている着信先アドレスを参照する。ここで、自己が収容しているプレゼンスクライアント１２を着信先としているので、このＳＵＢＳＣＲＩＢＥリクエスト信号を受け付けると共に、送信されたＲＥＧＩＳＴＥＲリクエスト信号を受け入れたことを示す２００番の応答情報を返信し、呼情報管理部２１２が、“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を構成要素とする呼情報を、プレゼンスクライアント１２に関連付けて呼情報保持部２１６に保持する（ステップＳ２０９）。
【００８６】
プレゼンスサーバ２１は、２００番の応答情報を受信することによりステップＳ２０７で送信したＳＵＢＳＣＲＩＢＥリクエスト信号が正常に受け入れられたと判断し、そのＳＵＢＳＣＲＩＢＥリクエストの“Ｃｏｎｔａｃｔ”に設定されているロケーション情報を呼情報として呼情報保持部１１６に保持しておく（ステップＳ２１０）。
【００８７】
一方、プレゼンスサーバ２１の呼情報管理部２１２は、プレゼンスクライアント１２に対応するプレゼンス情報をプレゼンス情報蓄積部２１７から読み出すと共に、呼情報保持部２１６で保持されているプレゼンスクライアント１２に関連する呼情報を読み出して（ステップＳ２１１）、呼情報を構成するロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）を“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を“Ｃｏｎｔａｃｔ”に設定し、読み出したプレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を、プレゼンスクライアント１１に送信する（ステップＳ２１２）。
【００８８】
最後に、プレゼンスクライアント１１の信号送受信部１１３は、送信されたＮＯＴＩＦＹリクエスト信号を受信し、ロケーション情報比較判定部１１４が、受信したＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されているロケーション情報と、呼情報保持部１１６に保持されているロケーション情報とを比較し、一致しない場合に、送信されたＮＯＴＩＦＹリクエスト信号は不正リクエスト信号であると判定する（ステップＳ２１３）。
【００８９】
続いて、このような実施例２の信号処理フローにおいて、正規プレゼンスクライアント１１として偽装した偽装プレゼンスクライアント１１’が、正規プレゼンスサーバ２１が収容している正規プレゼンスクライアント１２のプレゼンス参照を正規プレゼンスサーバ２１に要求した場合について説明する。図７は、偽装プレゼンスクライアントからのプレゼンス情報購読要求時の信号処理フローを示すフローチャートである。ここでは、実施例２で説明したステップＳ２０１〜ステップＳ２０６以降の信号処理フローについて説明する。
【００９０】
偽装プレゼンスクライアント１１’は、正規プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を送信先アドレスとして“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、正規プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、正規プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、正規プレゼンスクライアント１１のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｃｏｎｔａｃｔ”に設定したＳＵＢＳＣＲＩＢＥリクエスト信号を正規プレゼンスサーバ２１に送信する（ステップＳ２０７’）。
【００９１】
その後、正規プレゼンスサーバ２１の信号送受信部２１３は、送信されたＳＵＢＳＣＲＩＢＥリクエスト信号を受信し、ロケーション情報比較判定部２１４が、受信したＳＵＢＳＣＲＩＢＥリクエスト信号の“Ｃｏｎｔａｃｔ”に設定されているロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）と、ロケーション情報保持部２１５に最後に登録されているロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）とを比較する。（ステップＳ２０８’）。
【００９２】
この比較の結果、ロケーション情報が一致しないので、ロケーション情報比較判定部２１４は、送信されたＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定し、信号送受信部２１３は、エラーレスポンスを偽装プレゼンスクライアント１１’に送信する。以上の信号処理フローにより、正規プレゼンスサーバに対する不正なリクエスト信号を検出することが可能となる。より具体的には、成りすまし攻撃に対するプレゼンス情報の誤送信や、プレゼンス情報配信の誤停止を低減することができる。
【００９３】
更に続いて、上述の実施例２の信号処理フローにおいて、正規プレゼンスサーバ２１として偽装した偽装プレゼンスサーバ２１’が、正規プレゼンスサーバ２１が収容している正規プレゼンスクライアント１１へ偽装プレゼンス情報を送信した場合について説明する。図８は、偽装プレゼンスサーバによる偽装プレゼンス情報送信時の信号処理フローを示すフローチャートである。ここでは、実施例２で説明したステップＳ２０１〜ステップＳ２１１以降の信号処理フローについて説明する。
【００９４】
偽装プレゼンスサーバ２１’が、正規プレゼンスクライアント１１のロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）を“Ｒｅｑｕｅｓｔ−ＵＲＩ”に設定し、正規プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を着信先アドレスとして“Ｔｏ”に設定し、正規プレゼンスクライアント１１のアドレス（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ２１）を発信元アドレスとして“Ｆｒｏｍ”に設定し、正規プレゼンスクライアント１２のアドレス（ｓｉｐ：ｕｓｅｒ１２＠ｈｏｓｔ２１）を“Ｃｏｎｔａｃｔ”に設定し、偽装プレゼンス情報をメッセージボディ部に設定したＮＯＴＩＦＹリクエスト信号を、正規プレゼンスクライアント１１に送信する（ステップＳ２１２’）。
【００９５】
その後、プレゼンスクライアント１１の信号送受信部１１３は、送信されたＮＯＴＩＦＹリクエスト信号を受信し、ロケーション情報比較判定部１１４が、受信したＮＯＴＩＦＹリクエスト信号のＲｅｑｕｅｓｔ−ＵＲＩに設定されているロケーション情報（ｓｉｐ：ｕｓｅｒ１１＠ｈｏｓｔ１１）と、呼情報保持部１１６に保持されているロケーション情報（ｓｉｐ：ｘｘｘｘ＠ｈｏｓｔ１１）とを比較する（ステップＳ２１３’）。
【００９６】
この比較の結果、ロケーション情報が一致しないので、ロケーション情報比較判定部１１４は、送信されたＳＵＢＳＣＴＩＢＥリクエスト信号は不正リクエスト信号であると判定し、信号送受信部１１３は、不正リクエストを受信したことを示すエラーレスポンス情報を正規プレゼンスサーバ２１に送信する。以上の信号処理フローにより、正規プレゼンスクライアントに対する不正なリクエスト信号を検出することが可能となる。より具体的には、偽装された偽装プレゼンス情報に基づくユーザの誤判断を低減することができる。また、正規プレゼンスクライアントに対する偽装プレゼンスサーバからの攻撃があったことを正規プレゼンスサーバの保守者に通知することができる。
【００９７】
本実施の形態では、ＲＥＧＩＳＴＥＲリクエスト信号のメッセージボディ部に含まれているプレゼンス情報をプレゼンスクライアント１１に送信するとして説明したが、プレゼンス情報の登録後にＲＥＧＩＳＴＥＲリクエスト信号又はＰＵＢＬＩＳＨリクエスト信号（図９に記載）が送信された場合には、それら各リクエスト信号のメッセージボディ部に設定されている変更後のプレゼンス情報がプレゼンスクライアントに送信されることを付言しておく。また、ＲＥＧＩＳＴＥＲリクエスト信号やＰＵＢＬＩＳＨリクエスト信号にプレゼンス情報が含まれていない場合、換言すれば、見せる側のプレゼンスクライアントのユーザが自己のプレゼンスを未だ登録していない場合にあっては、未登録であることを示すプレゼンス情報や、単純に空（カラ）のプレゼンス情報を要求元のプレゼンスクライアントに送信することも勿論可能である。
【００９８】
なお、本実施の形態で説明したプレゼンスサーバ２１，２２及びプレゼンスクライアント１１，１２，１３の各動作をプログラムとして例えばＣＤ（Compact Disk）やＦＤ（Floppy（登録商標） Disk）等の記録媒体に記録して、この記録媒体をコンピュータに組み込んだり、若しくは記録媒体に記録されたプログラムを、任意の通信回線を介してコンピュータにダウンロードしたり、又は記録媒体からインストールし、該プログラムでコンピュータを動作させることにより、上述した各動作をプレゼンスサーバ２１，２２及びプレゼンスクライアント１１，１２，１３として機能させることができるのは勿論である。また、このような記録媒体を用いることにより、その流通性を高めることが可能となることも付言しておく。
【図面の簡単な説明】
【００９９】
【図１】プレゼンスサービスの実現に用いる本実施の形態に係るプレゼンス情報提供システムのシステム構成及び機能ブロックを示す構成図である。
【図２】各リクエスト信号の信号フォーマットの概要を示す概要図である。
【図３】本実施の形態に係るプレゼンス情報提供システムの信号処理フロー（実施例１）を示すシーケンス図である。
【図４】偽装プレゼンスクライアントからのプレゼンス情報購読要求時の信号処理フローを示すフローチャートである。
【図５】偽装プレゼンスサーバによる偽装プレゼンス情報送信時の信号処理フローを示すフローチャートである。
【図６】本実施の形態に係るプレゼンス情報提供システムの信号処理フロー（実施例２）を示すシーケンス図である。
【図７】偽装プレゼンスクライアントからのプレゼンス情報購読要求時の信号処理フローを示すフローチャートである。
【図８】偽装プレゼンスサーバによる偽装プレゼンス情報送信時の信号処理フローを示すフローチャートである。
【図９】プレゼンスサービスの概要を示す概要図である。
【図１０】プレゼンスサービスの実現に用いる従来のプレゼンス情報提供システムのシステム構成及び機能ブロックを示す構成図である。
【図１１】各リクエスト信号の信号フォーマットの概要を示す概要図である。
【図１２】従来のプレゼンス情報提供システムの信号処理フロー（実施例１）を示すシーケンス図である。
【図１３】従来のプレゼンス情報提供システムの信号処理フロー（実施例２）を示すシーケンス図である。
【符号の説明】
【０１００】
１１，１２，１３…プレゼンスクライアント
１１１，１２１，１３１…ロケーション情報管理部
１１２，１２２，１３２…呼情報管理部
１１３，１２３，１３３…信号送受信部
１１４，１２４，１３４…ロケーション情報比較判定部
１１５，１２５，１３５…ロケーション情報保持部
１１６，１２６，１３６…呼情報保持部
２１，２２…プレゼンスサーバ
２１１，２２１…ロケーション情報管理部
２１２，２２２…呼情報管理部
２１３，２２３…信号送受信部
２１４，２２４…ロケーション情報比較判定部
２１５，２２５…ロケーション情報保持部
２１６，２２６…呼情報保持部
２１７，２２７…プレゼンス情報蓄積部
３００，３０１，３０２…通信ネットワーク
Ｓ１０１〜Ｓ１１５…ステップ
Ｓ２０１〜Ｓ２１３…ステップ
Ｓ３０１〜Ｓ３１０…ステップ
Ｓ４０１〜Ｓ４０８…ステップ
【図１】
2009290358.tif 000003
【図２】
2009290358.tif 000004
【図３】
2009290358.tif 000005
【図４】
2009290358.tif 000006
【図５】
2009290358.tif 000007
【図６】
2009290358.tif 000008
【図７】
2009290358.tif 000009
【図８】
2009290358.tif 000010
【図９】
2009290358.tif 000011
【図１０】
2009290358.tif 000012
【図１１】
2009290358.tif 000013
【図１２】
2009290358.tif 000014
【図１３】
2009290358.tif 000015