(57)【特許請求の範囲】
【請求項１】
送信側装置から受信した情報を受信側装置に提供する情報提供サーバであって、
送信側装置、および、当該送信側装置から得られる情報を提供する受信側装置、を特定する提供先情報と、
少なくとも一つ以上の前記受信側装置が処理することのできる構造であるデータ構造、および、当該データ構造に対応する受信側装置、を特定する構造情報と、
を記憶する記憶部と、制御部と、を備え、
前記制御部は、
前記送信側装置から情報を受信すると、前記送信側装置から得られる情報を提供する受信側装置を、前記提供先情報より特定する提供先特定処理と、
前記提供先特定処理で特定された前記受信側装置が対応するデータ構造を、前記構造情報より特定するデータ構造特定処理と、
前記送信側装置から受信した情報のデータ構造を、前記データ構造特定処理で特定されたデータ構造に変換することで標準情報を生成する標準情報生成処理と、
前記標準情報の予め定められた位置の情報を、前記提供先特定処理で特定された前記受信者装置毎の情報に置き換えることで、前記受信者装置毎の通知情報を生成する通知情報生成処理と、
前記受信者装置毎の通知情報を、前記提供先特定処理で特定された前記受信者装置毎に送信する通知情報送信処理と、
を行うことを特徴とする情報提供サーバ。
【請求項２】
請求項１に記載の情報提供サーバであって、
前記標準情報生成処理は、前記データ構造特定処理で特定されたデータ構造によるテンプレートに、前記送信側装置から受信した情報より抽出された情報、または、前記送信側装置から受信した情報より抽出された情報により特定される情報、を格納する処理であること、
を特徴とする情報提供サーバ。
【請求項３】
請求項１に記載の情報提供サーバであって、
前記記憶部には、前記受信側装置毎に、前記受信側装置に提供する通知情報に使用する情報を特定した変更情報が記憶されており、
前記通知情報生成処理は、前記標準情報の予め定められた位置の情報を、前記変更情報に格納されている情報、または、前記変更情報に格納されている情報より特定される情報、に置き換える処理であること、
を特徴とする情報提供サーバ。
【請求項４】
請求項３に記載の情報提供サーバであって、
前記標準情報には、前記受信側装置毎の情報を格納する位置と、前記受信側装置毎の情報を取得するルールと、を有する変更指示が含まれており、
前記通知情報生成処理は、前記ルールに従って取得された情報を、前記変更指示で特定される位置に格納する処理であること、
を特徴とする情報提供サーバ。
【請求項５】
請求項１に記載の情報提供サーバであって、
前記送信側装置から受信する情報データ構造と、前記受信側装置に送信するデータ構造と、は異なるものであること、
を特徴とする情報提供サーバ。
【請求項６】
コンピュータを、送信側装置から受信した情報を受信側装置に提供する情報提供サーバとして機能させるプログラムであって、
前記コンピュータを、
送信側装置、および、当該送信側装置から得られる情報を提供する受信側装置、を特定する提供先情報と、
少なくとも一つ以上の前記受信側装置が処理することのできる構造であるデータ構造、および、当該データ構造に対応する受信側装置、を特定する構造情報と、
を記憶する記憶手段、制御手段、として機能させ、
前記制御手段に、
前記送信側装置から情報を受信すると、前記送信側装置から得られる情報を提供する受信側装置を、前記提供先情報より特定する提供先特定処理と、
前記提供先特定処理で特定された前記受信側装置が対応するデータ構造を、前記構造情報より特定するデータ構造特定処理と、
前記送信側装置から受信した情報のデータ構造を、前記データ構造特定処理で特定されたデータ構造に変換することで標準情報を生成する標準情報生成処理と、
前記標準情報の予め定められた位置の情報を、前記提供先特定処理で特定された前記受信者装置毎の情報に置き換えることで、前記受信者装置毎の通知情報を生成する通知情報生成処理と、
前記受信者装置毎の通知情報を、前記提供先特定処理で特定された前記受信者装置毎に送信する通知情報送信処理と、
を行わせることを特徴とするプログラム。
【請求項７】
請求項６に記載のプログラムであって、
前記標準情報生成処理は、前記データ構造特定処理で特定されたデータ構造によるテンプレートに、前記送信側装置から受信した情報より抽出された情報、または、前記送信側装置から受信した情報より抽出された情報により特定される情報、を格納する処理であること、
を特徴とするプログラム。
【請求項８】
請求項６に記載のプログラムであって、
前記記憶手段には、前記受信側装置毎に、前記受信側装置に提供する通知情報に使用する情報を特定した変更情報が記憶されており、
前記通知情報生成処理は、前記標準情報の予め定められた位置の情報を、前記変更情報に格納されている情報、または、前記変更情報に格納されている情報より特定される情報、に置き換える処理であること、
を特徴とするプログラム。
【請求項９】
請求項８に記載のプログラムであって、
前記標準情報には、前記受信側装置毎の情報を格納する位置と、前記受信側装置毎の情報を取得するルールと、を有する変更指示が含まれており、
前記通知情報生成処理は、前記ルールに従って取得された情報を、前記変更指示で特定される位置に格納する処理であること、
を特徴とするプログラム。
【請求項１０】
請求項６に記載のプログラムであって、
前記送信側装置から受信する情報のデータ構造と、前記受信側装置に送信するデータ構造と、は異なるものであること、
を特徴とするプログラム。
【請求項１１】
送信側装置、および、当該送信側装置から得られる情報を提供する受信側装置、を特定する提供先情報と、
少なくとも一つ以上の前記受信側装置が処理することのできる構造であるデータ構造、および、当該データ構造に対応する受信側装置、を特定する構造情報と、
を記憶する記憶部と、制御部と、を備える情報提供サーバが行う情報提供方法であって、
前記制御部が、前記送信側装置から情報を受信すると、前記送信側装置から得られる情報を提供する受信側装置を、前記提供先情報より特定する提供先特定処理過程と、
前記制御部が、前記提供先特定処理過程で特定された前記受信側装置が対応するデータ構造を、前記構造情報より特定するデータ構造特定処理過程と、
前記制御部が、前記送信側装置から受信した情報のデータ構造を、前記データ構造特定処理過程で特定されたデータ構造に変換することで標準情報を生成する標準情報生成処理過程と、
前記制御部が、前記標準情報の予め定められた位置の情報を、前記提供先特定処理過程で特定された前記受信者装置毎の情報に置き換えることで、前記受信者装置毎の通知情報を生成する通知情報生成処理過程と、
前記制御部が、前記受信者装置毎の通知情報を、前記提供先特定処理過程で特定された前記受信者装置毎に送信する通知情報送信処理過程と、
を有することを特徴とする情報提供方法。
【請求項１２】
送信側装置と、受信側装置と、当該送信側装置から受信した情報を当該受信側装置に提供する情報提供サーバと、を備える情報提供システムであって、
前記送信装置は、前記情報提供サーバに情報を送信する処理を行う制御部を備え、
前記情報提供サーバは、
送信側装置、および、当該送信側装置から得られる情報を提供する受信側装置、を特定する提供先情報と、
少なくとも一つ以上の前記受信側装置が処理することのできる構造であるデータ構造、および、当該データ構造に対応する受信側装置、を特定する構造情報と、
を記憶する記憶部と、制御部と、を備え、
前記情報提供サーバの前記制御部は、
前記送信側装置から情報を受信すると、前記送信側装置から得られる情報を提供する受信側装置を、前記提供先情報より特定する提供先特定処理と、
前記提供先特定処理で特定された前記受信側装置が対応するデータ構造を、前記構造情報より特定するデータ構造特定処理と、
前記送信側装置から受信した情報のデータ構造を、前記データ構造特定処理で特定されたデータ構造に変換することで標準情報を生成する標準情報生成処理と、
前記標準情報の予め定められた位置の情報を、前記提供先特定処理で特定された前記受信者装置毎の情報に置き換えることで、前記受信者装置毎の通知情報を生成する通知情報生成処理と、
前記受信者装置毎の通知情報を、前記提供先特定処理で特定された前記受信者装置毎に送信する通知情報送信処理と、を行い、
前記受信側装置は、前記情報提供サーバから受信した前記通知情報に応じた処理を行う制御部を備えること、
を特徴とする情報提供システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信側装置から受信した情報を受信側装置に提供する技術に関する。
【背景技術】
【０００２】
ＩＰ電話やインスタントメッセージサービスのように、通信を行う前に通信相手の状態を認識することができるシステムがある。このようなシステムでは、通信相手の状態等の情報（プレゼンス情報）を収集し、提供する情報提供サーバ装置（プレゼンスサーバと呼ばれる）が用いられる。
【０００３】
また、最新ニュースや番組情報、プレスリリース等の情報が提供されたことを通知するため、そうした情報を収集し、提供する情報提供サーバ装置（ＰＩＮＧサーバと呼ばれる）も用いられてきている。
【０００４】
以上のような情報提供サーバ装置に情報を提供する装置（送信側装置）と、情報提供サーバ装置から情報の提供を受ける装置（受信側装置）と、において情報の記述方法（データ構造）が異なるときには、情報提供サーバ装置から受信した情報を受信側装置において正しく処理できない場合がある。
【０００５】
このような場合に、情報提供サーバ装置において、送信側装置や受信側装置の機種を管理し、送信側装置から受信した情報を受信側装置が処理可能な記述に変換する技術がある（特許文献１参照）。
【０００６】
【特許文献１】特開２００７−２９５３８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
送信側装置の識別情報が受信側装置毎に異なる場合、あるいは、受信側装置に提供する情報に、電子署名を付したり、メッセージ認証コード（ＭＡＣと呼ばれる）を付加したりする場合、さらに、受信側装置に提供する情報に動的に生成される情報が含まれたりする場合、等のように、受信側装置に提供する情報が受信側装置毎に異なる値を含むような場合には、特許文献１に記載された技術では、受信側装置毎にデータを変換する変換規則を用意する必要があり、変換規則の作成負荷や、受信側装置毎にデータを変換する処理負荷が大きかった。
【０００８】
そこで、本発明は、受信側装置毎のデータに容易に変換することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
以上の課題を解決するため、本発明は、送信側装置から受信した情報を、受信側装置が共通して処理可能なデータ構造に変換してから、受信者側装置毎の情報を置き換えることにより、受信者側装置毎に提供する情報を作成する。
【００１０】
例えば、本発明は、送信側装置から受信した情報を受信側装置に提供する情報提供サーバであって、送信側装置、および、当該送信側装置から得られる情報を提供する受信側装置、を特定する提供先情報と、少なくとも一つ以上の前記受信側装置が処理することのできる構造であるデータ構造、および、当該データ構造に対応する受信側装置、を特定する構造情報と、を記憶する記憶部と、制御部と、を備え、前記制御部は、前記送信側装置から情報を受信すると、前記送信側装置から得られる情報を提供する受信側装置を、前記提供先情報より特定する提供先特定処理と、前記提供先特定処理で特定された前記受信側装置が対応するデータ構造を、前記構造情報より特定するデータ構造特定処理と、前記送信側装置から受信した情報のデータ構造を、前記データ構造特定処理で特定されたデータ構造に変換することで標準情報を生成する標準情報生成処理と、前記標準情報の予め定められた位置の情報を、前記提供先特定処理で特定された前記受信者装置毎の情報に置き換えることで、前記受信者装置毎の通知情報を生成する通知情報生成処理と、前記受信者装置毎の通知情報を、前記提供先特定処理で特定された前記受信者装置毎に送信する通知情報送信処理と、を行うことを特徴とする。
【発明の効果】
【００１１】
以上のように、本発明によれば、受信側装置毎のデータに容易に変換することのできる技術を提供することができる。
【発明を実施するための最良の形態】
【００１２】
図１は、本発明の一実施形態である情報提供システム１００の概略図である。
【００１３】
図示するように、情報提供システム１００は、情報提供サーバ１１０と、送信側装置１３０Ａ、１３０Ｂ（特に各々の装置を区別する必要のないときは、送信側装置１３０とする）と、受信側装置１５０Ａ、１５０Ｂ、１５０Ｃ（特に各々の装置を区別する必要のないときは、受信側装置１５０とする）と、を備え、これらは、ネットワーク１７０を介して相互に情報の送受信を行うことができるようにされている。
【００１４】
図２は、情報提供サーバ１１０の概略図である。
【００１５】
図示するように、情報提供サーバ１１０は、記憶部１１１と、制御部１１７と、入力部１２６と、出力部１２７と、送受信部１２８と、を備える。
【００１６】
記憶部１１１は、提供先情報記憶領域１１２と、構造情報記憶領域１１３と、テンプレート情報記憶領域１１４と、変更情報記憶領域１１５と、を備える。
【００１７】
提供先情報記憶領域１１２には、情報の提供を受ける受信側装置１５０を特定する情報と、当該受信側装置１５０が提供を受けることを要求する情報の送信元である送信側装置１３０を特定する情報と、が格納される。
【００１８】
例えば、本実施形態においては、図３（提供先テーブル１１２ａの概略図）に示すような提供先テーブル１１２ａが提供先情報記憶領域１１２に記憶される。
【００１９】
図示するように、提供先テーブル１１２ａは、登録番号欄１１２ｂと、送信側装置欄１１２ｃと、受信側装置欄１１２ｄと、を有する。
【００２０】
登録番号欄１１２ｂには、各々のレコードを識別するための識別情報である登録番号が格納される。
【００２１】
送信側装置欄１１２ｃには、後述する受信側装置欄１１２ｄで特定される受信側装置１５０が情報の提供を要求する送信側装置１３０を特定する情報が格納される。ここで、本実施形態においては、送信側装置１３０を特定する情報として、送信側装置１３０のアドレスを特定する情報（ここでは、ＳＩＰ  ＵＲＩ（Session Initiation Protocol Uniform Resource Identifier））が格納される。
【００２２】
受信側装置欄１１２ｄには、送信側装置欄１１２ｃで特定される送信側装置１３０の情報の提供を要求する受信側装置１５０を特定する情報が格納される。ここで、本実施形態においては、受信側装置１５０を特定する情報として、受信側装置１５０のアドレスを特定する情報（ここでは、ＵＲＬ：Uniform Resource Locator）が格納される。
【００２３】
なお、受信側装置１５０で動作している複数のアプリケーションがそれぞれ情報の提供を要求する場合（特に、受信側装置１５０のアプリケーション毎に処理することのできるデータ構造が複数ある場合や、受信側装置１５０のアプリケーション毎に情報の提供を要求する送信側装置１３０が異なるような場合）には、各々のアプリケーション毎に提供先テーブル１１２ａに新たなレコードを生成して、受信側装置欄１１２ｄに格納するアドレスを受信側装置１５０で動作しているアプリケーションのアドレスを特定する情報に変える等により管理すればよい。
【００２４】
図２に戻り、構造情報記憶領域１１３には、受信側装置１５０で処理することのできるデータ構造を特定する情報が格納される。
【００２５】
例えば、本実施形態においては、図４（構造テーブル１１３ａの概略図）に示すような構造テーブル１１３ａが構造情報記憶領域１１３に記憶される。
【００２６】
図示するように、構造テーブル１１３ａは、登録番号欄１１３ｂと、データ構造欄１１３ｃと、受信側装置欄１１３ｄと、を有する。
【００２７】
登録番号欄１１３ｂには、各々のレコードを識別するための識別情報である登録番号が格納される。
【００２８】
データ構造欄１１３ｃには、後述する受信側装置欄１１３ｄで特定される受信側装置１５０が処理可能なデータ構造を特定する情報が格納される。ここで、データ構造としては、ＳＩＰやＳＯＡＰ（Simple Object Access Protocol）といったプロトコル等により定められる記述方式（型）毎に、各々の記述方式（型）を識別することのできる情報がデータ構造欄１１３ｃに格納される。
【００２９】
なお、本実施形態においては、データ構造は、ＸＭＬスキーマのようなスキーマ言語で定義されるＸＭＬ文書の構造（あるメッセージをその構成要素間の関係に基づいてツリー状に表現したもの）を示しているが、このような態様に限定されるわけではない。
【００３０】
受信側装置欄１１３ｄには、データ構造欄１１３ｃで特定されるデータ構造で送信側装置１３０の情報の提供を受信する受信側装置１５０を特定する情報が格納される。ここで、本実施形態においては、受信側装置１５０を特定する情報として、受信側装置１５０のアドレスを特定する情報（ここでは、ＵＲＬ）が格納される。
【００３１】
なお、受信側装置１５０で処理することのできるデータ構造が複数ある場合（例えば、受信側装置１５０のアプリケーション毎に処理することのできるデータ構造が複数ある場合）には、処理可能なデータ構造毎に新たなレコードを生成して、受信側装置欄１１３ｄに格納するアドレスを受信側装置１５０で動作しているアプリケーションのアドレスを特定する情報に変える等により管理すればよい。
【００３２】
テンプレート情報記憶領域１１４には、送信者側装置１３０が対応するデータ構造と、受信者側装置１５０が対応するデータ構造と、の組み合わせ毎に、データ構造を変換するための変換テンプレートを特定する情報が格納される。なお、本実施形態では、テンプレート情報記憶領域１１４に記憶されている変換テンプレートを用いて変換されたデータを標準データとする。
【００３３】
例えば、テンプレート情報記憶領域１１４には、図５（変換テンプレート１１４ａの概略図）に示すような変換テンプレート１１４ａが格納される。なお、変換テンプレート１１４ａは、送信者側装置１３０の状態情報を通知する通知用ＳＩＰメッセージ（ここでは、ＮＯＴＩＦＹメッセージ）を標準データである通知用ＳＯＡＰメッセージに変換するためのものである。
【００３４】
また、図５における向かって左端の数字は、変換テンプレート１１４ａの行数を示す目盛りである。
【００３５】
変換テンプレート１１４ａは、変換指示領域１１４ｂと、テンプレート領域１１４ｃと、を有する。
【００３６】
変換指示領域１１４ｂは、送信者側装置１３０が送信した情報に応じて、後述するテンプレート領域１１４ｃに格納されているテンプレートを変換する変換指示が記述される領域である。
【００３７】
テンプレート領域１１４ｃには、返還後のデータ構造によるデータ（テンプレート）が記述される。
【００３８】
ここで、本実施形態においては、テンプレート領域１１４ｃに格納されるテンプレートには、ＩＤ等のように各々の受信側装置１５０において異なる値となる部分には、後述する変更情報記憶領域１１５に記憶される情報等に基づいて値を変更するための変更指示（コマンド）が格納されている。
【００３９】
例えば、図５の変換テンプレート１１４ａでは、「＄」の記号を用いて変更指示を識別している。
【００４０】
変更情報記憶領域１１５には、テンプレート情報記憶領域１１４に格納されている変換テンプレートを用いて変換された標準データに格納されている値を変更するための情報が記憶される。
【００４１】
例えば、本実施形態においては、図６（変更テーブル１１５ａの概略図）に示すような変更テーブル１１５ａ及び図７（ＩＤテーブル１１５ｅの概略図）に示すようなＩＤテーブル１１５ｅが、各々の受信側装置１５０毎に記憶される。
【００４２】
図６に示すように、変更テーブル１１５ａは、情報種別欄１１５ｂと、値欄１１５ｃと、を有する。
【００４３】
情報種別欄１１５ｂには、後述する値欄１１５ｃに格納されている値の種別を特定する情報が格納される。
【００４４】
値欄１１５ｃには、標準データに格納する値を生成するための値を特定する情報が格納される。
【００４５】
なお、変更テーブル１１５ａに格納する情報については、受信側装置１５０から取得して格納してもよく、また、入力部１２６を介して、予め入力を受け付けて格納してもよい。さらに、変更テーブル１１５ａに格納する情報の一部については、受信側装置１５０から取得して格納し、その他の情報については、入力部１２６を介して、予め入力を受け付けて格納してもよい。
【００４６】
なお、変更テーブル１１５ａに格納する情報については、受信側装置１５０から取得してもよく、また、入力部１２６を介して、予め入力を受け付けてもよい。また、変更テーブル１１５ａに格納する情報の一部について、受信側装置１５０から取得してもよく、その他の情報を、入力部１２６を介して、入力を受け付けてもよい。
【００４７】
図７に示すように、ＩＤテーブル１１５ｅは、ＩＤ１欄１１５ｆと、ＩＤ２欄１１５ｇと、を有する。
【００４８】
ＩＤ１欄１１５ｆには、他の装置のＩＤを特定する情報が格納される。
【００４９】
ＩＤ２欄１１５ｇには、ＩＤ１欄１１５ｆで特定されるＩＤに関して、ＩＤテーブル１１５ｅに対応する受信側装置１５０において識別しているＩＤを特定する情報が格納される。即ち、ＩＤ１欄１１５ｆに格納されているＩＤと、受信側装置１５０において識別しているＩＤと、が対応付けられて一つのレコードに格納されている。
【００５０】
図２に戻り、制御部１１７は、ＳＯＡＰ通信部１１８と、メッセージ解析部１１９と、提供先管理部１２０と、送信依頼用ＳＩＰ作成部１２１と、ＳＩＰ通信部１２２と、構造別メッセージ作成部１２３と、通知用ＳＯＡＰ作成部１２４と、を備える。
【００５１】
ＳＯＡＰ通信部１１８は、ＳＯＡＰに従った通信を制御する。特に、本実施形態においては、送受信部１２８を介して、通知用ＳＯＡＰ作成部１２４で作成した通知用ＳＯＡＰメッセージを受信側装置１５０に送信する処理、および、受信側装置１５０より送信された提供依頼用ＳＯＡＰメッセージを受信する処理、を制御する。
【００５２】
メッセージ解析部１１９は、送受信部１２８を介して受信した提供依頼用ＳＯＡＰメッセージを解析し、必要な情報を構造テーブル１１３ａ、変更テーブル１１５ａ及びＩＤテーブル１１５ｅに格納する処理を行う。
【００５３】
提供先管理部１２０は、送受信部１２８を介して受信した提供依頼用ＳＯＡＰメッセージより、情報の提供元である送信側装置１３０と、当該送信側装置１３０から得られる情報を提供する受信側装置１５０と、を特定する情報を取得して、これらのアドレスを特定する情報を提供先テーブル１１２ａに格納する処理を行う。
【００５４】
送信依頼用ＳＩＰ作成部１２１は、情報提供サーバ１１０のアドレスを特定した送信依頼用のメッセージ（送信依頼用ＳＩＰメッセージ）をＳＩＰに従って作成し（例えば、ＳＵＢＳＣＲＩＢＥメッセージを用いて作成し）、ＳＩＰ通信部１２２に出力する。
【００５５】
ＳＩＰ通信部１２２は、ＳＩＰに従った通信を制御する。特に、本実施形態においては、送受信部１２８を介して、送信依頼用ＳＩＰ作成部１２１で作成された送信依頼用ＳＩＰメッセージを送信側装置１３０に送信する処理、および、送信側装置１３０より送信された通知用ＳＩＰメッセージを受信する処理、を制御する。
【００５６】
構造別メッセージ作成部１２３は、テンプレート情報記憶領域１１４に記憶されている変換テンプレートを用いて、送信側装置１３０より受信したメッセージのデータ構造を、受信側装置１５０が処理可能なデータ構造に変換する処理を行う。
【００５７】
ここで、本実施形態においては、送信側装置１３０は、ＳＩＰに従ったメッセージを送信するものとし、受信側装置１５０は、ＳＯＡＰに従ったメッセージを処理するものとする。従って、本実施形態においては、構造別メッセージ作成部１２３は、ＳＩＰメッセージを標準データである標準ＳＯＡＰメッセージに変換する処理を行うものとする。
【００５８】
通知用ＳＯＡＰ作成部１２４は、構造別メッセージ作成部１２３で変換された標準ＳＯＡＰメッセージに格納されている変更指示で特定されている情報を、当該メッセージを提供する受信側装置１５０毎に変更テーブル１１５ａやＩＤテーブル１１５ｅ等により特定し、変更指示で特定されている処理を行い標準ＳＯＡＰメッセージに格納することにより、受信側装置１５０毎の通知用データである通知用ＳＯＡＰメッセージを作成する。
【００５９】
なお、通知用ＳＯＡＰ作成部１２４は、作成した通知用ＳＯＡＰメッセージをＳＯＡＰ通信部１１８に出力する。
【００６０】
入力部１２６は、情報の入力を受け付ける。
【００６１】
出力部１２７は、情報を出力する。
【００６２】
送受信部１２８は、ネットワーク１７０を介した情報の送受信を行う。
【００６３】
以上に記載した情報提供サーバ１１０は、例えば、図８（コンピュータ１９０の概略図）に示すような、ＣＰＵ（Central Processing Unit）１９１と、メモリ１９２と、ＨＤＤ（Hard Disk Drive）等の外部記憶装置１９３と、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）やＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）等の可搬性を有する記憶媒体１９４から情報を読み出す読取装置１９５と、キーボードやマウスなどの入力装置１９６と、ディスプレイなどの出力装置１９７と、通信ネットワークに接続するためのＮＩＣ（Network Interface Card）等の通信装置１９８と、を備えた一般的なコンピュータ１９０で実現できる。
【００６４】
例えば、記憶部１１１は、ＣＰＵ１９１がメモリ１９２又は外部記憶装置１９３を利用することにより実現可能であり、制御部１１７は、外部記憶装置１９３に記憶されている所定のプログラムをメモリ１９２にロードしてＣＰＵ１９１で実行することで実現可能であり、入力部１２６は、ＣＰＵ１９１が入力装置１９６を利用することで実現可能であり、出力部１２７は、ＣＰＵ１９１が出力装置１９７を利用することで実現可能であり、送受信部１２８は、ＣＰＵ１９１が通信装置１９８を利用することで実現可能である。
【００６５】
この所定のプログラムは、読取装置１９５を介して記憶媒体１９４から、あるいは、通信装置１９８を介してネットワークから、外部記憶装置１９３にダウンロードされ、それから、メモリ１９２上にロードされてＣＰＵ１９１により実行されるようにしてもよい。また、読取装置１９５を介して記憶媒体１９４から、あるいは、通信装置１９８を介してネットワークから、メモリ１９２上に直接ロードされ、ＣＰＵ１９１により実行されるようにしてもよい。
【００６６】
図９は、送信側装置１３０の概略図である。
【００６７】
図示するように、送信側装置１３０は、記憶部１３１と、制御部１３３と、入力部１３９と、出力部１４０と、送受信部１４１と、を備える。
【００６８】
記憶部１３１には、送信側装置１３０で処理を行うために必要な情報が記憶される。特に、本実施形態においては、情報を送信する情報提供サーバ１１０のアドレスを特定する情報が記憶される。
【００６９】
制御部１３３は、状態管理部１３４と、状態変更通知作成部１３５と、送信先管理部１３６と、ＳＩＰ通信部１３７と、を備える。
【００７０】
状態管理部１３４は、送信側装置１３０の状態（例えば、オフライン又はオンライン）を管理する。
【００７１】
なお、本実施形態においては、送信側装置１３０の状態を管理するようにしているがこのような態様に限定されず、ネットワーク１７０や他の有線、無線等を介して接続されている他の装置の状態を管理して、状態の変更を情報提供サーバ１１０に通知するようにしてもよい。
【００７２】
状態変更通知作成部１３５は、状態管理部１３４で管理している状態に変更が生じた場合に、状態が変更したことを通知する送信データを作成する。ここで、本実施形態においては、送信データとして、ＳＩＰのＮＯＴＩＦＹメッセージを用いて通知用ＳＩＰメッセージを作成する。
【００７３】
送信先管理部１３６は、ＳＩＰ通信部１３７より入力された送信依頼用ＳＩＰメッセージに含まれている情報提供サーバ１１０のアドレスを抽出して、記憶部１３１に記憶する処理を行う。
【００７４】
ＳｉＰ通信部１３７は、ＳＩＰに従った通信を制御する。特に、本実施形態においては、送受信部１４１を介して、状態変更通知作成部１３５で作成された通知用ＳＩＰメッセージを送信する処理、および、情報提供サーバ１１０より送信された送信依頼用ＳＩＰメッセージを受信する処理、を制御する。
【００７５】
入力部１３９は、情報の入力を受け付ける。
【００７６】
出力部１４０は、情報を出力する。
【００７７】
送受信部１４１は、ネットワーク１７０を介した情報の送受信を行う。
【００７８】
以上に記載した送信側装置１３０は、例えば、図８に示すような、一般的なコンピュータ１９０で実現できる。
【００７９】
例えば、記憶部１３１は、ＣＰＵ１９１がメモリ１９２又は外部記憶装置１９３を利用することにより実現可能であり、制御部１３３は、外部記憶装置１９３に記憶されている所定のプログラムをメモリ１９２にロードしてＣＰＵ１９１で実行することで実現可能であり、入力部１３９は、ＣＰＵ１９１が入力装置１９６を利用することで実現可能であり、出力部１４０は、ＣＰＵ１９１が出力装置１９７を利用することで実現可能であり、送受信部１４１は、ＣＰＵ１９１が通信装置１９８を利用することで実現可能である。
【００８０】
この所定のプログラムは、読取装置１９５を介して記憶媒体１９４から、あるいは、通信装置１９８を介してネットワークから、外部記憶装置１９３にダウンロードされ、それから、メモリ１９２上にロードされてＣＰＵ１９１により実行されるようにしてもよい。また、読取装置１９５を介して記憶媒体１９４から、あるいは、通信装置１９８を介してネットワークから、メモリ１９２上に直接ロードされ、ＣＰＵ１９１により実行されるようにしてもよい。
【００８１】
なお、送信側装置１３０については、一般的なコンピュータ１９０のほかにも、例えば、ＣＰＵ１９１と、メモリ１９２と、外部記憶装置１９３と、入力装置１９６と、出力装置１９７と、通信装置１９８と、を有する携帯端末、携帯電話端末、または、ＳＩＰ端末等によっても実現可能である。
【００８２】
図１０は、受信側装置１５０の概略図である。
【００８３】
図示するように、受信側装置１５０は、記憶部１５１と、制御部１５３と、入力部１５９と、出力部１６０と、送受信部１６１と、を備える。
【００８４】
記憶部１５１には、受信側装置１５０で処理を行うために必要な情報が記憶される。特に、本実施形態においては、受信側装置１５０毎に、メッセージにおいて変更を要求する値を特定する情報が格納される。
【００８５】
制御部１５３は、処理部１５４と、提供依頼作成部１５５と、通知用ＳＯＡＰ解析部１５６と、ＳＯＡＰ通信部１５７と、を備える。
【００８６】
処理部１５４は、情報提供サーバ１１０より得られる送信側装置１３０の状態に応じた処理を行う。例えば、本実施形態においては、送信側装置１３０毎に、オンライン状態であるか、オフライン状態であるか、を特定する情報を、出力部１６０に表示する処理を行うが、このような態様に限定されるわけではない。
【００８７】
提供依頼作成部１５５は、ＳＯＡＰに従って、自装置のアドレスを特定する情報と、状態情報の取得を要求する送信側措置１３０を特定する情報と、自装置が処理可能なデータ構造を特定する情報と、自装置用の値に変更するために使用される値を特定する情報と、を格納した提供依頼用ＳＯＡＰメッセージを作成する。
【００８８】
なお、提供依頼作成部１５５は、作成した提供依頼用ＳＯＡＰメッセージをＳＯＡＰ通信部１５７に出力する。
【００８９】
通知用ＳＯＡＰ解析部１５６は、ＳＯＡＰ通信部１５７より入力された通知用ＳＯＡＰメッセージを解析して、必要な情報（例えば、送信側装置１３０の状態）を特定して、処理部１５４に出力する。
【００９０】
ＳＯＡＰ通信部１５７は、ＳＯＡＰに従った通信を制御する。特に、本実施形態においては、送受信部１６１を介して、提供依頼作成部１５５が作成した提供依頼用ＳＯＡＰメッセージを送信する処理、および、情報提供サーバ１１０より送信された通知用ＳＯＡＰメッセージを受信する処理、を制御する。
【００９１】
入力部１５９は、情報の入力を受け付ける。
【００９２】
出力部１６０は、情報を出力する。
【００９３】
送受信部１６１は、ネットワーク１７０を介した情報の送受信を行う。
【００９４】
以上に記載した受信側装置１５０は、例えば、図８に示すような、一般的なコンピュータ１９０で実現できる。
【００９５】
例えば、記憶部１５１は、ＣＰＵ１９１がメモリ１９２又は外部記憶装置１９３を利用することにより実現可能であり、制御部１５３は、外部記憶装置１９３に記憶されている所定のプログラムをメモリ１９２にロードしてＣＰＵ１９１で実行することで実現可能であり、入力部１５９は、ＣＰＵ１９１が入力装置１９６を利用することで実現可能であり、出力部１６０は、ＣＰＵ１９１が出力装置１９７を利用することで実現可能であり、送受信部１６１は、ＣＰＵ１９１が通信装置１９８を利用することで実現可能である。
【００９６】
この所定のプログラムは、読取装置１９５を介して記憶媒体１９４から、あるいは、通信装置１９８を介してネットワークから、外部記憶装置１９３にダウンロードされ、それから、メモリ１９２上にロードされてＣＰＵ１９１により実行されるようにしてもよい。また、読取装置１９５を介して記憶媒体１９４から、あるいは、通信装置１９８を介してネットワークから、メモリ１９２上に直接ロードされ、ＣＰＵ１９１により実行されるようにしてもよい。
【００９７】
なお、受信側装置１５０については、一般的なコンピュータ１９０のほかにも、例えば、ＣＰＵ１９１と、メモリ１９２と、外部記憶装置１９３と、入力装置１９６と、出力装置１９７と、通信装置１９８と、を有する携帯端末、携帯電話端末、または、ＳＩＰ端末等によっても実現可能である。
【００９８】
図１１は、情報提供システム１００での処理を示すシーケンス図である。ここでは、受信側装置１５０Ｂが、情報提供サーバ１１０を介して、送信側装置１３０Ａの状態情報を取得する際の処理を例に説明するが、このような態様に限定されるわけではない。
【００９９】
まず、情報提供サーバ１１０の送信依頼用ＳＩＰ作成部１２１が送信依頼用ＳＩＰメッセージを生成して、ＳＩＰ通信部１２２に出力し、ＳＩＰ通信部１２２が送受信部１２８を介して、当該送信依頼用ＳＩＰメッセージを送信側装置１３０Ａに送信する（Ｓ１０）。
【０１００】
このような送信依頼用ＳＩＰメッセージを受信した送信側装置１３０Ａでは、送信先管理部１３６が、送信依頼用ＳＩＰメッセージに含まれている情報提供サーバ１１０のアドレス情報を記憶部１３１に記憶する（Ｓ１１）。
【０１０１】
また、受信側装置１５０Ｂの提供依頼作成部１５５は、自装置のアドレスを特定する情報と、状態情報の取得を要求する送信側措置１３０Ａを特定する情報と、自装置が処理可能なデータ構造を特定する情報と、自装置用にメッセージを変更するために使用される値を特定する情報と、を格納した提供依頼用ＳＯＡＰメッセージを作成して、ＳＯＡＰ通信部１５７に出力し、ＳＯＡＰ通信部１５７が、送受信部１６１を介して、情報提供サーバ１１０に送信する（Ｓ１２）。
【０１０２】
このような提供依頼用ＳＯＡＰメッセージを受信した情報提供サーバ１１０では、メッセージ解析部１１９及び提供先管理部１２０が、受信した提供依頼用ＳＯＡＰメッセージから必要な情報を抽出して記憶部１１１に記憶する（Ｓ１３）。
【０１０３】
具体的には、メッセージ解析部１１９が、受信した提供依頼用ＳＯＡＰメッセージより、処理可能なデータ構造を特定する情報及び受信側装置１５０Ｂのアドレスを特定する情報を抽出して、これらを対応付けて構造テーブル１１３ａに格納するとともに、受信側装置１５０Ｂ用にメッセージを変更するために使用される値を特定する情報を変更テーブル１１５ａに格納する。
【０１０４】
また、提供先管理部１２０は、受信した提供依頼用ＳＯＡＰメッセージより、送信側装置１３０Ａを特定する情報を抽出して、ＩＤテーブル１１５ｅのＩＤ２欄１１５ｇを検索し対応するレコードのＩＤ１欄１１５ｆに格納されている送信側装置１３０Ａのアドレスを特定する情報を取得する。
【０１０５】
そして、提供先管理部１２０は、このようにして取得した送信側装置１３０Ａのアドレスを特定する情報と、受信した提供依頼用ＳＯＡＰメッセージより抽出した受信側装置１５０Ｂのアドレスを特定する情報と、を対応付けて提供先テーブル１１２ａに格納する。
【０１０６】
また、受信側装置１５０Ｂの処理部１５４は、初期状態として、本シーケンスでは、送信側装置１３０Ａがオフライン状態であることを出力部１６０に表示する（Ｓ１４）。
【０１０７】
そして、送信側装置１３０Ａの状態管理部１３４で、送信側装置１３０Ａの状態が変化（ここでは、オフライン状態からオンライン状態に変化）したことを検知した場合には（Ｓ１５）、状態変更通知作成部１３５が、状態が変化したことを特定する情報を含む通知用ＳＩＰメッセージ（ＮＯＴＩＦＹメッセージ）を作成して、ＳＩＰ通信部１３７が、送受信部１４１を介して、記憶部１３１に記憶されている送信先（ここでは情報提供サーバ１１０）のアドレスに送信する（Ｓ１６）。
【０１０８】
このような通知用ＳＩＰメッセージを受信した情報提供サーバ１１０では、構造別メッセージ作成部１２３が、送信側装置１３０Ａからの情報の取得を要求する受信側装置１５０が処理可能なデータ構造を特定して、テンプレート情報記憶領域１１４に記憶されている変換テンプレートを用いて、データ構造を変換して標準データである標準通知用ＳＯＡＰメッセージを作成する（Ｓ１７）。
【０１０９】
そして、情報提供サーバ１１０の通知用ＳＯＡＰメッセージ作成部１２４は、ステップＳ１７で生成された標準通知用ＳＯＡＰメッセージに格納されている変更指示に応じて、送信側装置１３０Ａからの情報の取得を要求する受信側装置１５０Ｂ用の値を、変更情報記憶領域１１５に受信側装置１５０Ｂに対応付けて記憶されている変更テーブル１１５ａ及びＩＤテーブル１１５ｅに格納されている値から生成し、生成した値を標準通知用ＳＯＡＰメッセージに格納することで、受信側装置１５０Ｂへの通知データである通知用ＳＯＡＰメッセージを作成する（Ｓ１８）。
【０１１０】
そして、情報提供サーバ１１０のＳＯＡＰ通信部１１８は、送受信部１２８を介して、通知用ＳＯＡＰメッセージ作成部１２４が作成した通知用ＳＯＡＰメッセージを受信側装置１５０Ｂに送信する（Ｓ１９）。
【０１１１】
このような通知用ＳＯＡＰメッセージを受信した受信側装置１５０Ｂでは、通知用ＳＯＡＰ解析部１５６が、受信した通知用ＳＯＡＰメッセージを解析することで、送信側装置１３０Ａがオンライン状態であることを特定し、処理部１５４が、受信した通知用ＳＯＡＰメッセージで特定される送信側装置１３０Ａの状態に応じた処理を行う（Ｓ２０）。ここでは、処理部１５４は、送信側装置１３０Ａがオンライン状態であることを示す情報を出力部１６０に表示する処理を行う。
【０１１２】
図１２は、情報提供サーバ１１０での処理を示すフローチャートである。
【０１１３】
まず、情報提供サーバ１１０は、動作を開始すると、送信依頼用ＳＩＰ作成部１２１が、全ての送信側装置１３０に対して、少なくとも情報提供サーバ１１０のアドレス情報を含む送信依頼用ＳＩＰメッセージを作成し（Ｓ３０）、ＳＩＰ通信部１２２が、送受信部１２８を介して、各々の送信側装置１３０に送信する（Ｓ３１）。
【０１１４】
ここで、本実施形態では、送信依頼用ＳＩＰメッセージは、ＲＦＣ３２６５で規定されたＳＵＢＳＣＲＩＢＥメッセージを使用するため、詳細な説明は省略するが、このようなＳＵＢＳＣＲＩＢＥメッセージに限定されるわけではなく、各種の標準で規定されたメッセージ、あるいは独自に規定したメッセージを使用してもよい。
【０１１５】
次に、情報提供サーバ１１０のＳＯＡＰ通信部１１８は、送受信部１２８を介して、受信側装置１５０より新たな提供依頼用ＳＯＡＰメッセージを受信しているかどうかを確認する（Ｓ３２）。そして、新たなＳＯＡＰメッセージを受信している場合には（ステップＳ３２でＹｅｓ）ステップＳ３２に進み、新たなＳＯＡＰメッセージを受信していない場合には（ステップＳ３２でＮｏ）ステップＳ３５に進む。
【０１１６】
図１３は、提供依頼用ＳＯＡＰメッセージ１８０の概略図である。なお、図１３における向かって左端の数字は、提供依頼用ＳＯＡＰメッセージ１８０の行数を示す目盛りである。
【０１１７】
図示するように、提供依頼用ＳＯＡＰメッセージ１８０は、ＳＯＡＰメッセージのボディ部（１１行目〜１９行目）において、情報の取得を要求する送信側装置１３０の識別情報（１３行目および１４行目）、受信側端末１５０を特定するための情報（１５行目〜１７行目）が記述されている。さらに、１５行目には、受信側端末１５０が処理することのできるデータ構造を特定する情報「ｔｙｐｅ＝“ＳＯＡＰ”」が記述されている。
【０１１８】
さらに、ＳＯＡＰメッセージのヘッダ部（３行目〜１０行目）には、ＭＡＣ（メッセージ認証コード：Message Authentication Code）を生成するためのハッシュ関数を特定する情報（５行目）、および、ＭＡＣを生成するための鍵（シークレット情報）を特定する情報（６行目及び７行目）、が格納されている。
【０１１９】
図１２に戻り、ステップＳ３２では、メッセージ解析部１１９は、ステップＳ３４で受信した提供依頼用ＳＯＡＰメッセージを解析し、予め定められた要素や属性の値から必要な情報を抽出する（Ｓ３２）。
【０１２０】
具体的には、メッセージ解析部１１９は、図１３に示す提供依頼用ＳＯＡＰメッセージ１８０のヘッダ部において、「macSecret」要素の「Algorithm」の属性値として記述されているハッシュ関数を特定する情報「hmac-sha1」を抽出して、提供依頼用ＳＯＡＰメッセージ１８０を送信してきた受信側装置１５０の識別情報に対応付けて変更テーブル１１５ａを生成し、当該変更テーブル１１５ａに新たなレコードを作成して、作成したレコードの情報種別欄１１５ｂに「アルゴリズム」を特定する情報を格納し、当該レコードの値欄１１５ｃに「hmac-sha1」を特定する情報を格納する。
【０１２１】
また、メッセージ解析部１１９は、図１３に示す提供依頼用ＳＯＡＰメッセージ１８０のヘッダ部において、「keyName」要素の値として記述されている鍵ＩＤ「00000001」を抽出して、提供依頼用ＳＯＡＰメッセージ１８０を送信してきた受信側装置１５０の識別情報に対応付けられている変更テーブル１１５ａに新たなレコードを作成して、作成したレコードの情報種別欄１１５ｂに「シークレットＩＤ」を特定する情報を格納し、当該レコードの値欄１１５ｃに「00000001」を特定する情報を格納する。
【０１２２】
さらに、メッセージ解析部１１９は、図１３に示す提供依頼用ＳＯＡＰメッセージ１８０のヘッダ部において、「keyValue」要素の値として記述されている鍵情報「Tl7uwy8xnQn44R9YvFkjYpe=」を抽出して、提供依頼用ＳＯＡＰメッセージ１８０を送信してきた受信側装置１５０の識別情報に対応付けられている変更テーブル１１５ａに新たなレコードを作成して、作成したレコードの情報種別欄１１５ｂに「シークレット値」を特定する情報を格納し、当該レコードの値欄１１５ｃに「Tl7uwy8xnQn44R9YvFkjYpe=」を特定する情報を格納する。
【０１２３】
また、メッセージ解析部１１９は、図１３に示す提供依頼用ＳＯＡＰメッセージ１８０のボディ部において、「watcher」要素の「type」の属性値として記述されているデータ構造を特定する情報「SOAP」と、当該「watcher」要素の値として記述されている受信側装置１５０のアドレス情報「http://terminal1.hitachi.com/PresenxeNotification」と、を抽出して、構造テーブル１１３ａに新たなレコードを作成して、作成したレコードの登録番号欄１１３ｂに各々のレコードの識別番号（上方のレコードからの連番）を特定する情報を格納し、当該レコードのデータ構造欄１１３ｃに「SOAP」を特定する情報を格納し、当該レコードの受信側装置欄１１３ｄに「http://terminal1.hitachi.com/PresenxeNotification」を特定する情報を格納する。
【０１２４】
さらに、メッセージ解析部１１９は、図１３に示す提供依頼用ＳＯＡＰメッセージ１８０のボディ部において、「presentity」の要素から、情報を取得したい送信側装置１３０の識別情報と、「watcher」要素の値として記述されている受信側装置１５０のアドレス情報と、を抽出して、提供先管理部１２０に出力する。
【０１２５】
そして、これらの情報を取得した提供先管理部１２０は、提供先テーブル１１２ａに新たなレコードを作成して、作成したレコードの登録番号欄１１３ｂに各々のレコードの識別番号（上方のレコードからの連番）を特定する情報を格納し、当該レコードの送信側装置欄１１２ｃに送信側装置１３０の識別情報に対応するアドレス情報（ＳＩＰ  ＵＲＩ）を特定する情報（ＩＤテーブル１１５ｅより取得）を格納し、当該レコードの受信側装置欄１１２ｄに受信側装置１５０のアドレス情報を特定する情報を格納する（Ｓ３３）。
【０１２６】
一方、ステップＳ３５では、ＳＩＰ通信部１２２は、新たな通知用ＳＩＰメッセージを受信していないかどうかを確認する。そして、新たな通知用ＳＩＰメッセージを受信していない場合には、ステップＳ３４に戻り処理を繰り返し、新たな通知用ＳＩＰメッセージを受信している場合には、ステップＳ３６に進む。
【０１２７】
図１４は、通知用ＳＩＰメッセージ１８１の概略図である。なお、図１４における向かって左端の数字は、通知用ＳＩＰメッセージ１８１の行数を示す目盛りである。
【０１２８】
図示するように、通知用ＳＩＰメッセージ１８１のボディ部（１２行目〜２０行目）には、「presence」の要素の「entity」の属性値として送信元である送信側装置１３０のＳＩＰ  ＵＲＩを特定する情報「sip:user1@hitachi.com」が格納されており、「status」の子要素である「basic」の要素の値として送信元である送信側装置１３０の状態情報である「open」（ここでは、オンライン状態であることを示し、オフライン状態であるときは「close」）が格納されている。
【０１２９】
図１２に戻り、ステップＳ３６では、提供先管理部１２０は、受信した通知用ＳＩＰメッセージを送信してきた受信側装置１３０のアドレス情報に対応付けられている受信側装置１５０のアドレス情報を提供先テーブル１１２ａから特定して、構造別メッセージ作成部１２３に出力する。そして、構造別メッセージ作成部１２３は、入力されたアドレス情報に対応付けられているデータ構造を構造テーブル１１３ａから特定する。
【０１３０】
次に、構造別メッセージ作成部１２３は、ステップＳ３６で特定したデータ構造のうちで、後述するステップＳ３８で行うデータ構造変換を未だ行っていないデータ構造があるか否かを確認する（Ｓ３７）。そして、未変換のデータ構造がある場合には（ステップＳ３７でＹｅｓ）ステップＳ３８に進み、未変換のデータ構造がない場合には（ステップＳ３７でＮｏ）ステップＳ３４に戻り処理を繰り返す。
【０１３１】
ステップＳ３８では、構造別メッセージ作成部１２３は、ステップＳ３５で受信した通知用ＳＩＰメッセージを、ステップＳ３６で特定されたデータ構造であって未変換のデータ構造に変換する（ここでは、ＳＯＡＰで識別されるデータ構造に変換するものとする）。
【０１３２】
具体的には、通知用ＳＩＰメッセージをステップＳ３６で特定されたデータ構造であって未変換のデータ構造に変換するための変換テンプレート１１４ａをテンプレート情報記憶領域１１４より取得して、当該変換テンプレート１１４ａのテンプレート領域１１４ｃに格納されているテンプレートを抽出して、抽出したテンプレートに、変換テンプレート１１４ａの変換指示領域１１４ｂに格納される変換指示に応じた処理を行うことにより、通知用ＳＩＰメッセージを、変換するデータ構造における標準データである標準通知用ＳＯＡＰメッセージに変換する。
【０１３３】
例えば、図５に示す変換テンプレート１１４ａでは、変換指示領域１１４ｂにおける１行目において、変換対象となるＳＩＰメッセージ（ここでは、通知用ＳＩＰメッセージ１８１）の「/presence/entity」というパスで特定される値をテンプレート領域１１４ｃに記述されているテンプレートの「%1」（２４行目）という変数に代入することが指定されている。また、変換指示領域１１４ｂにおける２行目から７行目までの間において、変換対象となるＳＩＰメッセージ（ここでは、通知用ＳＩＰメッセージ１８１）の「/presence/tuple/status/basic」というパスで特定される値が「open」であれば、テンプレートの「%2」という変数に「Available」という値を、「open」以外の場合には「Not Available」という値を代入することが指定されている。
【０１３４】
従って、構造別メッセージ作成部１２３は、通知用ＳＩＰメッセージ１８１を解析してＸＭＬツリーを作成し、該当する箇所の値を検索し、変数に代入する。次に、構造別メッセージ作成部１２３は、テンプレート領域１１４ｃに記述されているテンプレートを標準データとして出力しながら「%1」として指定されている箇所（２４行目）及び「%2」として指定されている箇所（２８行目）の値を、変換指示領域１１４ｂで指示された値に置き換えて標準通知用ＳＯＡＰメッセージとして出力する。
【０１３５】
図１５は、図１４に示す通知用ＳＩＰメッセージ１８１を変換した標準通知用ＳＯＡＰメッセージ１８２の概略図である。なお、図１５における向かって左端の数字は、標準通知用ＳＯＡＰメッセージ１８２の行数を示す目盛りである。
【０１３６】
図示するように、標準通知用ＳＯＡＰメッセージ１８２のボディ部（１４行目〜２４行目）において、１６行目の「presentity」の要素の値に、通知用ＳＩＰメッセージ１８１の「/presence/entity」というパスで特定された送信側装置１３０のＳＩＰ  ＵＲＩ「SIP:user1@hitachi.com」を特定する情報が格納されており、２０行目の「Activity」の要素の値に、通知用ＳＩＰメッセージ１８１の「/presence/tuple/status/basic」というパスで特定される値「open」に対応する「Available」を特定する情報が格納される。
【０１３７】
図１２に戻り、ステップＳ３９では、通知用ＳＯＡＰ作成部１２４は、ステップＳ３８で標準通知用ＳＯＡＰメッセージを作成したデータ構造に対応する受信側装置１５０を提供先テーブル１１２ａで検索する（Ｓ３９）。
【０１３８】
そして、通知用ＳＯＡＰ作成部１２４は、ステップＳ３９で検索した受信側装置１５０のうち、未だ情報を送信していない受信側装置１５０が存在するかどうかを特定する（Ｓ４０）。そして、未だ情報を送信していない受信側装置１５０が存在する場合には（ステップＳ４０でＹｅｓ）、ステップＳ４１に進み、未だ情報を送信していない受信側装置１５０が存在しない場合には（ステッＳ４０でＮｏ）、ステップＳ３７に戻り処理を繰り返す。
【０１３９】
ステップＳ４１では、通知用ＳＯＡＰ作成部１２４は、標準通知用ＳＯＡＰメッセージ１８２の装置毎に異なる値への書き換えを指示した箇所を、当該箇所毎に指定された方法に従って書き換えることで、装置毎の通知用ＳＯＡＰメッセージを作成する。
【０１４０】
例えば、図１５に示す標準通知用ＳＯＡＰメッセージ１８２では、「＄」の記号を識別情報として用いて装置毎に異なる値を書き換える変更指示が格納されている位置を示している。
【０１４１】
具体的には、標準通知用ＳＯＡＰメッセージ１８２の１０行目に格納されている「$BASE64($HMAC($BODY、$SECRET))」と記述されている変更指示は、当該変更指示が記述されている箇所に、ボディ部（＄BODY：１４行目〜２４行目）に格納されている情報を、受信側装置１５０の鍵情報（＄SECRET）を使って作成したＭＡＣの値を、当該変更指示に書き換えて格納することを指示している。なお、受信側装置１５０の鍵情報については、送信する受信側装置１５０の識別情報に対応付けて記憶されている変更テーブル１１５ａにおいて情報種別欄１１５ｂにシークレット値を特定する情報が格納されているレコードの値欄１１５ｃに格納されている値が使用される。
【０１４２】
また、標準通知用ＳＯＡＰメッセージ１８２の１６行目に格納されている「$IDCONV(sip:user1@hitachi.com)」と記述されている変更指示は、当該変更指示が記述されている箇所に、「sip:user1@hitachi.com」というアドレス情報（ＩＤ）を受信側装置１５０が識別しているＩＤに変換することを指示している。なお、受信側装置１５０が識別しているＩＤについては、送信する受信側装置１５０の識別情報に対応付けて記憶されているＩＤテーブル１１５ｅにおいてＩＤ１欄１１５ｆに「sip:user1@hitachi.com」を特定する情報が格納されているレコードのＩＤ２欄１１５ｇに格納されている値が使用される。
【０１４３】
さらに、標準通知用ＳＯＡＰメッセージ１８２の１８行目に格納されている「＄DATE」と記述されている変更指示は、当該変更指示が記述されている箇所に、現在時刻を書き換えて格納することを指示している。
【０１４４】
図１６は、図１５に示す標準通知用ＳＯＡＰメッセージ１８２から、通知用ＳＯＡＰ作成部１２４が作成した通知用ＳＯＡＰメッセージ１８３の概略図である。なお、図１６における向かって左端の数字は、通知用ＳＯＡＰメッセージ１８３の行数を示す目盛りである。
【０１４５】
図１２に戻り、ステップＳ４２では、ＳＯＡＰ通信部１１８が、ステップＳ４１で作成された通知用ＳＯＡＰメッセージ１８３を、送受信部１２８を介して受信側装置１５０に送信する。
【０１４６】
以上が、本実施形態における情報提供サーバ１１０での処理である。
【０１４７】
例えば、図１７（情報提供サーバ１１０での処理を示す概略図）に示すように、送信側装置１３０Ａから通知用ＳＩＰメッセージ１８１を受信した場合、情報提供サーバ１１０は、構造別メッセージ作成部１２３が、通知用ＳＩＰメッセージ１８１を、受信側装置１５０Ａ及び受信側装置１５０Ｂが共通して対応するデータ構造である標準通知用ＳＯＡＰメッセージ１８３に変換し、通知用ＳＯＡＰ作成部１２４が、各々の受信側装置１５０Ａ及び受信側装置１５０Ｂ用の通知用ＳＯＡＰメッセージ１８４に変更して、ＳＯＡＰ通信部１１８が、各々の装置に送信する。
【０１４８】
図１８は、送信側装置１３０での処理を示すフローチャートである。
【０１４９】
本実施形態における送信側装置１３０は、動作を開始すると、まず、ＳＩＰ通信部１３７が、送受信部１４１を介して、新たな送信依頼用ＳＩＰメッセージを受信しているかどうかを確認する（Ｓ５０）。そして、新たな送信依頼用ＳＩＰメッセージを受信していた場合には、ステップＳ５１に進み、新たな送信依頼用ＳＩＰメッセージを受信していない場合には、ステップＳ５２に進む。
【０１５０】
ステップＳ５１では、送信先管理部１３６が、送信依頼用ＳＩＰメッセージに含まれている送信元である情報提供サーバ１１０のアドレスを特定する情報を取得して、記憶部１３１に記憶して、ステップＳ５０に進み処理を繰り返す。
【０１５１】
一方、ステップＳ５２では、状態管理部１３４が、送信側装置１３０の状態を確認し、送信側装置１３０の状態が更新されているか否かを判断する。そして、送信側装置１３０の状態が更新されている場合には、ステップＳ５３に進み、送信側装置１３０の状態が更新されていない場合には、ステップＳ５０に進み処理を繰り返す。
【０１５２】
ステップＳ５３では、状態変更通知作成部１３５は、記憶部１３１に記憶されている送信先である情報提供サーバ１１０のアドレス情報を検索する。
【０１５３】
次に、状態変更通知作成部１３５は、通知用ＳＩＰメッセージを送信していない情報提供サーバ１１０のアドレス情報があるか否かを確認する（Ｓ５４）。そして、通知用ＳＩＰメッセージを送信していない情報提供サーバ１１０のアドレス情報がある場合には（ステップＳ５４でＹｅｓ）、ステップＳ５５に進み、通知用ＳＩＰメッセージを送信していない情報提供サーバ１１０のアドレス情報がない場合には（ステップＳ５４でＮｏ）、ステップＳ５０に戻り処理を繰り返す。
【０１５４】
ステップＳ５５では、状態変更通知作成部１３５は、送信装置１３０の更新後の状態を特定した通知用ＳＩＰメッセージ（例えば、図１４に示す通知用ＳＩＰメッセージ１８１）を作成して、ＳＩＰ通信部１３７に出力する。
【０１５５】
そして、ＳＩＰ通信部１３７は、送受信部１４１を介して、入力された通知用ＳＩＰメッセージを情報提供サーバ１１０に送信する（Ｓ５６）。
【０１５６】
図１９は、受信側装置１５０の処理を示すフローチャートである。
【０１５７】
本実施形態における受信側装置１５０は、動作を開始すると、まず、提供依頼作成部１５５が、提供依頼用ＳＯＡＰメッセージ（例えば、図１３に示す提供依頼用ＳＯＡＰメッセージ１８０）を作成する（Ｓ６０）。
【０１５８】
そして、ＳＯＡＰ通信部１５７が、ステップＳ６０で作成された提供依頼用ＳＯＡＰメッセージを情報提供サーバ１１０に送信する（Ｓ６１）。
【０１５９】
次に、処理部１５４は、初期状態として、全ての送信側装置１３０がオフライン状態であることを出力部１６０に表示する（Ｓ６２）。
【０１６０】
そして、ＳＯＡＰ通信部１１８が、送受信部１６１を介して、通知用ＳＯＡＰメッセージを受信すると（Ｓ６３）、通知用ＳＯＡＰ解析部１５６が、通知用ＳＯＡＰメッセージを解析して、状態が更新された送信先装置１３０と更新後の状態を取得し、処理部１５４に通知する（Ｓ６４）。
【０１６１】
そして、処理部１５４は、通知用ＳＯＡＰ解析部１５６から通知された送信側装置１３０の状態を更新して出力部１６０に表示して（Ｓ６５）と、ステップＳ６３に戻り処理を繰り返す。
【０１６２】
以上に記載した実施形態においては、送信側装置１３０は、送信依頼用ＳＩＰメッセージを介して通知された送信先に通知用ＳＩＰメッセージを送信するようにしているが、このような態様に限定されず、例えば、設定ファイルや送信側装置１３０のオペレータが指定した送信先に通知用ＳＩＰメッセージを送信するようにしてもよい。
【０１６３】
また、受信側装置１５０が提供を受けるＳＯＡＰメッセージは、Parlay-X Presence Web Service仕様やLibertyで規定されたプレゼンスインタフェースやLiberty ID-SIS Presence Service仕様等を用いてもよい。
【０１６４】
さらには、送信側装置１３０から受信したＳＯＡＰメッセージをＳＩＰメッセージとして受信側装置１５０に送信したり、送信側装置１３０から受信したParlay-X Presence Web Service仕様のＳＯＡＰメッセージをLiberty ID-SIS Presence Service仕様のＳＯＡＰメッセージとして受信側装置１５０に送信したりする等、送信側装置１３０が送信するメッセージのデータ構造と、受信側装置１５０が受信できるメッセージのデータ構造が異なる場合に本発明は適用できる。
【０１６５】
なお、Parlay-X Presence Web Service仕様については、下記の文献１に詳細に説明されており、Libertyで規定されたLiberty ID-SIS Presence Service仕様については、下記の文献２に詳細に説明されている。
【０１６６】
文献１：ETSI、 ES 202 391-14 V1.2.1 (2006-12)、Open Service Access (OSA); Parlay X Web Services; Part 14: Presence 、[2008年2月13日検索] 、インターネット＜URL：http://webapp.etsi.org/action%5CPU/20061219/es_20239114v010201p.pdf＞
文献２：Liberty Alliance Project、Liberty ID-SIS Presence Service Specification、[2008年2月13日検索] 、インターネット＜URL：http://www.projectliberty.org/liberty/content/download/1041/7185/file/draft-liberty-id-sis-presence-v1.0-10.pdf＞
なお、以上に記載した実施形態で使用したＳＯＡＰについては、下記の文献３に詳細に説明されている。
【０１６７】
文献３：Ｗ３Ｃ、SOAP Version 1.2 Part 0: Primer (Second Edition) 、[2008年2月13日検索] 、インターネット＜URL：http://www.w3.org/TR/soap12-part0/＞
さらに、以上に記載した実施形態で使用したＳＩＰについては、下記の文献４に詳細に説明されている。
【０１６８】
文献４：IETF、RFC3261：SIP: Session Initiation Protocol、[2008年2月13日検索] 、インターネット＜URL：http://www.ietf.org/rfc/rfc3261.txt＞
本実施形態で説明したように、ＳＩＰメッセージやＳＯＡＰメッセージに記載される情報は、どちらもＸＭＬ（eXtensible Markup Language）と呼ばれる形式のメッセージであるが、情報のデータ構造が異なっているため、通常は、次のようにデータ構造の変換を行っている。
【０１６９】
まず、ＳＩＰメッセージを読み込んで、ＳＩＰメッセージに含まれるＸＭＬが正しい構文規則に適合しているか、データ構造が正しいかをチェックする。次に、チェックの済んだＸＭＬをデータ構造の置換などの処理を行いやすいようにツリー構造の内部データ（ＸＭＬツリー）に展開する。そして、ＳＩＰメッセージのＸＭＬツリーをＳＯＡＰメッセージに記載するＸＭＬのデータ構造に適合したＸＭＬツリーに変換して、最後に、変換したＸＭＬツリーからＳＯＡＰメッセージに記載するＸＭＬを出力する。
【０１７０】
ここで、ＳＩＰメッセージのＸＭＬツリーをＳＯＡＰメッセージのＸＭＬツリーに変換する場合に、ＸＳＬＴ（eXtensible Stylesheet Langage Text）と呼ばれる変換規則定義に従って変換を行うことがよく知られている（ＸＳＬＴについては、下記の文献５を参照）。
【０１７１】
文献５：Ｗ３Ｃ、XSL Transformations (XSLT) Version 1.0、[2008年2月13日検索]、インターネット＜URL：http://www.w3.org/TR/xslt＞
そして、このような通常の技術では、ＳＩＰメッセージを変換するＳＯＡＰメッセージに送信する受信側の装置の固有の情報が含まれる場合に、固有の情報を含めた変換規則定義を各々の装置毎に行わなければならなかったのが、本実施形態によれば、同じデータ構造を使用する装置において、データ構造の変換は一度で済み、変換されたデータ構造のうち、装置に固有の情報については、変換されたデータ構造において書き換えることで、データ構造の変換処理の負荷を小さくすることができる。
【０１７２】
従って、例えば、通常のデータ構造の変換処理は、変換を行う場所を探索するためにＸＭＬツリーを辿ったりしなければならず、テキスト文書の書き換えに比べて時間がかかるが、本実施形態ではテキスト文書の書き換えで済むため処理時間が短縮される。
【０１７３】
さらに、ある送信側装置１３０から収集した情報を複数の受信側装置１５０に提供する場合、受信側装置１５０の数だけ同じ変換処理が必要になり、受信側装置１５０が増えるにしたがって性能が劣化していくが、本実施形態においては、データ構造の変換は一度で済むため性能の劣化を回避することができる。
【０１７４】
また、以上に記載した実施形態においては、情報提供サーバ１１０から情報を送信する受信側装置１５０毎に通知用のメッセージを作成するようにしているが、このような態様に限定されず、例えば、通知用のメッセージを利用する受信側装置１５０のアプリケーション毎に通知用メッセージを作成するようにしてもよい。このような場合でも、アプリケーションが対応しているデータ構造毎にデータ構造の変換を行い、データ構造の変換を行った後に各々のアプリケーションに固有の値の変更を行えばよい。
【０１７５】
例えば、ＮＧＮ（New Generation Network）として構築が進められている次世代ネットワークでは多種多様なアプリケーションサービスがユーザの状態に応じたサービスを提供するようになると想定されており、あるユーザの情報を提供するアプリケーションサービスは多数になるため、このような場合には、本発明による効果は高く発揮されるものと思われる。
【０１７６】
以上のように、本発明によれば、情報提供サーバ１１０は、送信側装置１３０および受信側装置１５０で処理することのできるデータ構造の種類毎に処理可能なＸＭＬツリーの型を管理し、送信側装置１３０から収集した情報を受信側装置１５０が対応するデータ構造に対応した型のＸＭＬツリーに変換した後、当該ＸＭＬツリーに基づいてデータ構造別のメッセージを出力する。当該データ構造別の機種別メッセージをテキスト文書として扱い、受信側装置１５０毎に値が異なる箇所を書き換えて、受信側装置１５０それぞれに提供するメッセージを作成する。したがって、受信側装置１５０に提供する情報が受信側装置１５０毎に異なる値を含むような場合でも、受信側装置１５０毎に変換規則を用意する必要はなく、同じデータ構造に対応する装置であれば同じ変換規則を用意すればよい、という特徴がある。
【０１７７】
また、本発明によれば、送信側装置１３０から受信した情報のデータ構造の変換処理を行った後、受信側装置１５０毎に値を書き換える処理を行うため、データ構造の変換処理は受信側装置１５０の数に依存せずに、ただ１度だけ実行されるようになる。したがって、受信側装置１５０が増えも性能が劣化しづらい、という特徴がある。
【０１７８】
さらに、本発明によれば、データ構造毎のメッセージは、受信側装置１５０に提供するメッセージの中で動的に生成される情報に対応する箇所は、当該情報の生成手段を指定した情報が記載されているため、動的に生成される情報が含まれる場合にも受信側装置１５０が処理できるメッセージを生成できる、という特徴がある。
【０１７９】
なお、以上に記載した実施形態においては、例えば、図１５に示す標準通知用ＳＯＡＰメッセージのように、データ構造毎のメッセージに、受信側装置１５０毎に値を書き換える変更指示が含まれているが、このような態様に限定されず、例えば、データ構造毎のメッセージの受信側装置１５０毎に値を書き換える箇所の値は空欄等にしておき、書き換える箇所と、当該箇所においた値を書き換える変更指示と、を対応させた変更情報を別途記憶部等に記憶しておき、このような変更情報を用いて値を書き換えることも可能である。
【０１８０】
また、以上に記載した実施形態においては、ＩＤの変換には情報提供サーバ１１０が管理するＩＤテーブル１１５ｅを参照するようにしているが、このような態様に限定されず、例えば、ネットワーク１７０を介して接続されたデータベースを参照したり、ＩＤ変換サービスを提供するサーバに問い合わせしたりするようにしてもよい。
【図面の簡単な説明】
【０１８１】
【図１】情報提供システムの概略図。
【図２】情報提供サーバの概略図。
【図３】提供先テーブルの概略図。
【図４】構造テーブルの概略図。
【図５】変換テンプレートの概略図。
【図６】変更テーブルの概略図。
【図７】ＩＤテーブルの概略図。
【図８】コンピュータの概略図。
【図９】送信側装置の概略図。
【図１０】受信側装置の概略図。
【図１１】情報提供システムでの処理を示すシーケンス図。
【図１２】情報提供サーバでの処理を示すフローチャート。
【図１３】提供依頼用ＳＯＡＰメッセージの概略図。
【図１４】通知用ＳＩＰメッセージの概略図。
【図１５】標準通知用ＳＯＡＰメッセージの概略図。
【図１６】通知用ＳＯＡＰメッセージの概略図。
【図１７】情報提供サーバでの処理を示す概略図。
【図１８】送信側装置での処理を示すフローチャート。
【図１９】受信側装置の処理を示すフローチャート。
【符号の説明】
【０１８２】
１００  情報提供システム
１１０  情報提供サーバ
１１１  記憶部
１１７  制御部
１２６  入力部
１２７  出力部
１２８  送受信部
１３０  送信側装置
１３１  記憶部
１３３  制御部
１３９  入力部
１４０  出力部
１４１  送受信部
１５０  受信側装置
１５１  記憶部
１５３  制御部
１５９  入力部
１６０  出力部
１６１  送受信部
【図１】
0005248145.tif 000002
【図２】
0005248145.tif 000003
【図３】
0005248145.tif 000004
【図４】
0005248145.tif 000005
【図５】
0005248145.tif 000006
【図６】
0005248145.tif 000007
【図７】
0005248145.tif 000008
【図８】
0005248145.tif 000009
【図９】
0005248145.tif 000010
【図１０】
0005248145.tif 000011
【図１１】
0005248145.tif 000012
【図１２】
0005248145.tif 000013
【図１３】
0005248145.tif 000014
【図１４】
0005248145.tif 000015
【図１５】
0005248145.tif 000016
【図１６】
0005248145.tif 000017
【図１７】
0005248145.tif 000018
【図１８】
0005248145.tif 000019
【図１９】
0005248145.tif 000020