(57)【要約】【課題】端末種別情報を利用してユーザ間のコミュニケーションをよりスムーズにする。【解決手段】ログイン時の情報から端末種別を特定し，その情報をプレゼンス情報に付与して通知する。また，SIPサーバにおいて同一端末種別間を接続する。【効果】プレゼンス情報に端末情報がアドインし，お互いが所有端末を把握することで，コミュニケーション開始時の音声通話や文字チャット等通信手段の選択と相手端末での呼び出し端末の特定ができるようになる。また，プレゼンス情報＋端末情報を把握することで同一名称のプレゼンス情報からでも詳細な状態を把握することが可能になる。さらにプレゼンス機能を有さない端末の場合でも端末種別情報識別をSIPサーバが代理で行い，呼び出し端末の特定が行えるようになる。【選択図】図３
2005318503.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末間の通信接続制御を行う接続制御サーバに接続されることが可能で、かつ前記複数の端末の状態情報を管理するプレゼンスサーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケットのヘッダ情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項２】
請求項１記載のプレゼンスサーバであって、
前記制御部は、前記回線インターフェースで受信したログインメッセージに含まれるヘッダ情報から、前記通信接続制御サーバに接続している前記送信元端末の端末種別情報を抽出し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記接続制御サーバを介して前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項３】
請求項１に記載のプレゼンスサーバであって、
前記端末種別情報の通知可否情報を前記送信元端末の通信相手ごとに格納したテーブルを備え、
前記端末種別情報の通知が可である相手端末に対してのみ、該端末種別情報を送信することを特徴とするプレゼンスサーバ。
【請求項４】
請求項１に記載のプレゼンスサーバであって、
さらに辞書テーブルを備え、
前記制御部は、前記ヘッダ情報から抽出した前記端末種別情報を、前記辞書テーブルを用いて内部管理用端末種別情報に変換することを特徴とするプレゼンスサーバ。
【請求項５】
請求項１に記載のプレゼンスサーバであって、
前記制御部は、
前記複数の端末それぞれに対して前記端末種別情報を付与することが可能であり、
前記複数の端末のそれぞれごとに、前記端末種別情報を付与する方法を変更できることを特徴とするプレゼンスサーバ。
【請求項６】
請求項５に記載のプレゼンスサーバであって、
前記制御部は、
前記複数の端末のそれぞれが用いる端末種別情報通知プロトコルに応じて前記端末種別情報の出力方法を変更することを特徴とするプレゼンスサーバ。
【請求項７】
請求項１に記載のプレゼンスサーバであって、
前記制御部は、前記パケットのヘッダ情報のうち、前記端末種別情報を抽出する部分を自由に設定できることを特徴とするプレゼンスサーバ。
【請求項８】
複数の端末間の通信接続制御を行う接続制御サーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケットのヘッダ情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の前記端末種別情報を、前記相手端末に送信することを特徴とするセッション制御サーバ。
【請求項９】
請求項８記載のセッション制御サーバであって、
前記制御部は、前記回線インターフェースで受信したログインメッセージに含まれるヘッダ情報から、前記送信元端末の端末種別情報を抽出することを特徴とするセッション制御サーバ。
【請求項１０】
請求項８に記載のセッション制御サーバであって、
さらに辞書テーブルを備え、
前記制御部は、前記ヘッダ情報から抽出した前記端末種別情報を、前記辞書テーブルを用いて内部管理用端末種別情報に変換することを特徴とするセッション制御サーバ。
【請求項１１】
請求項８に記載のセッション制御サーバであって、
前記制御部は、
前記複数の端末それぞれに対して前記端末種別情報を付与することが可能であり、
前記複数の端末のそれぞれごとに、前記端末種別情報を付与する方法を変更でいることを特徴とするセッション制御サーバ。
【請求項１２】
請求項９に記載のセッション制御サーバであって、
前記制御部は、
前記複数の端末のそれぞれが用いる端末種別情報通知プロトコルに応じて端末種別情報の出力方法を変更することを特徴とするセッション制御サーバ。
【請求項１３】
請求項８に記載のセッション制御サーバであって、
前記制御部は、前記パケットのヘッダ情報のうち、前記端末種別情報を抽出する部分を自由に設定できることを特徴とするセッション制御サーバ。
【請求項１４】
請求項８に記載のセッション制御サーバであって、
前記端末種別情報を利用してメッセージの振り分けを行うことが可能であることを特徴とするセッション制御サーバ。
【請求項１５】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けのポリシを自由に変更可能なことを特徴とするサーバ。
【請求項１６】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けの対象とするメッセージ種別を自由に設定することが可能であることを特徴とするサーバ。
【請求項１７】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けの際に、振り分け先が見つからない場合に，その旨を発信者に返すことを特徴とするセッション制御サーバ。
【請求項１８】
請求項８乃至１７のいずれかに記載のセッション制御サーバであって、
セッション制御プロトコルにSIP(Session Initiation Protocol)を用いることを特徴とするセッション制御サーバ。
【請求項１９】
端末またはサーバから送信されるパケットを受信して他のサーバまたは端末にパケットを中継するパケット中継システムであって、
前記端末またはサーバから送信されたパケットから、該端末またはサーバの端末種別を把握する手段と、
前記端末種別を記憶する手段と、
該端末種別を用いて目的の合った端末同士、サーバ同士、または端末とサーバ同士を接続することを特徴とするパケット中継システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報公開の設定方式に関する。
【背景技術】
【０００２】
近年、”プレゼンス”と呼ばれる概念を利用した状態把握技術を取り入れた通信技術の開発が盛んに行なわれている。”プレゼンス”とはユーザの現在状態を表す言葉である。この”プレゼンス”を他のユーザに対してリアルタイムに通知することでお互いの現在状態を把握することが可能となる。プレゼンスを取り入れた通信技術の中で、現段階で実施されている代表的な通信技術に、IM(Instant Messaging)がある。プレゼンス情報を用いたIMの概念とその通知方法はIETF(Internet Engineering Task Force)のimpp(Instant Messaging and Presence Protocol)ワーキンググループを中心に標準化が行われている。imppワーキンググループで標準化された内容は非特許文献１、非特許文献２に記述されている。
【０００３】
従来までは、”プレゼンス”を用いた状態把握技術はIMサービスにアドオンする形で提供される形態が殆どであり，使用される通信プロトコルも各社が独自に構築したIMサービス用のプロトコルを拡張した形となっていた。しかし，最近はプロトコルレベルでの標準化も積極的に行われてきている。例えば，IETFのSIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)ワーキンググループではIP電話等で利用するセッション接続プロトコルSIP(Session Initiation Protocol)を拡張したプレゼンス情報送受信プロトコルの標準化を行っている。非特許文献３やその他Internet-Draftにその標準仕様が記述されている。最近は各社が自社で展開するIMサービスの通信プロトコルをSIMPLE標準に合わせ，SIPを用いたIP電話，テレビ電話等のサービスとの統合化を図る動きが見られる。また， SIMPLE標準を実装したプレゼンスサーバを開発し，IMサービスと分離した形でのプレゼンス活用を提案する動きも見られる。
【０００４】
また、IMサービスは、基本的に1ユーザ1端末で展開するサービスを前提としている。例えば、IMサービスを利用するUserAが複数の端末、端末Aおよび端末A'を所持しており、現在は端末AでIMサービスを利用していると想定する。もし，UserAが、端末AとA'をIMサーバに同時ログインさせた場合、現在のIMサーバは他のユーザであるUserBがUserAに送信するインスタントメッセージを端末A，A'のどちらに送信すればよいかの判断ができない。現在のIMサービスではUserAが端末Aをログインさせている時に端末A'をログインさせようとすると端末Aを強制的にログアウトさせる処理を行う等，２重ログインを防止する為の機構をサーバ側に実装して対処している。
【０００５】
SIPを用いた場合はこの2重ログインを許可するモデルが存在する。しかし，その機能はIP電話に特化したものである。それは，SIPが元来IP電話をターゲットとした規格である為である。以下SIPによる2重ログインのモデルを説明する。
【０００６】
図13は312に示すUserBが314，315に示す2台のIP電話をSIPサーバ41に対してログインさせている図である。この時UserBは314，315の2端末からSIPサーバ41にログインする為にSIPのREGISTERメッセージを送信する。図5にREGISTERメッセージの内容を示す。各端末はREGISTER送信時に図5の73に示すq-valueを指定することにより，優先順位を指定することが可能である。q-valueは0から1までの数字で指定し，値が高い端末ほど優先順位が高いとみなす。例えば，314に示すIP電話端末1がq-valueに0.5を指定し，315に示すIP電話端末2がq-valueに0.7を示したとすると，315に示すIP電話端末2の方がq-valueの値が高いのでSIPサーバ41は以後IP電話端末2を優先的に扱う形となる。この状態でUserAがUserBに対して電話呼び出しを行うと，SIPサーバ41はUserBがログインさせている端末のうち，優先順位の高いIP電話端末2に呼び出しをかける。SIPの規格では以上の形式で端末の2重ログインを管理する。
【０００７】
【非特許文献１】RFC 2778
【０００８】
【非特許文献２】RFC 2779
【非特許文献３】RFC 3265
【非特許文献４】IETF Internet Draft draft-ietf-impp-cpim-pidf-08.txt
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来のIMサービスでは、IMサーバは、ログインしたユーザのスクリーンネーム（ユーザの識別子）と対応するオンライン/オフラインの状態情報のみを管理し、端末の種類情報までは管理していなかった。また，各社のIMシステムに対するSIPプロトコル実装状況を見ると、SIP等の共通プロトコルに基づきシステムを構築し、構築されたシステムを共通プラットフォームとして、その上でIMサービスやその他のサービスを運用していく可能性が高い。よって、今後は、共通プラットフォーム上に、IM端末やIP電話、チャット端末など、様々な種別の端末が接続されるようになるものと予想される。更に、アプリケーション毎に違った端末が接続される場合のみならず、複数アプリケーションが実行されている同一端末が共通プラットフォームに接続されるようになるとも予想される。従って、プレゼンス情報を用いた種々のサービスをネットワーク上で展開する場合に、従来のIMサービスで実施されていたプレゼンス情報の利用方法をそのまま適用すると、図１１に示すような不都合が生じると考えられる。
【００１０】
図１１は、IP電話端末211を所有するUserAが、複数の端末213〜216を所有するUserBにSIPサーバ経由で電話をかける場合を示した概要図である。UserA211は、各端末ユーザのプレゼンス情報を管理するプレゼンスサーバに接続されており、その結果、吹き出し217に示すようなUserBのプレゼンス情報を知っているものとする。また、各端末は、接続管理サーバとしてのSIPサーバに接続されており、SIPサーバが各端末の通信制御を実行しているものとする。実線が端末−SIPサーバ間でやりとりされる接続信号の伝達経路を示し、一点鎖線で示した線がプレゼンス情報の伝達経路を示す。
【００１１】
従来のIMサーバにおいては、IMサーバは、UserAのスクリーンネームとUserA端末201がオンライン状態になったという状態情報とを対にして管理している。IMサービスにおけるプレゼンス情報の管理方法をそのままプレゼンスサーバに対して用いた場合、プレゼンスサーバは、ユーザの識別子とそれに対応するオンライン/オフラインの状態情報とを対にして管理することになる。UserBがテレビ電話端末213，IP電話端末214，会議端末215，IM端末216を同時にログインさせていたとする。プレゼンスサーバはユーザの識別子は管理しているので、吹き出し217に示す通り、UserBの各端末のオンライン/オフラインの状態情報をUserAに通知することは可能である。そこで、UserA211が、現在オンライン中であるUserB212のIP電話端末Bに対して電話をかけたいと考えたとする。もちろん、UserAがUserBのアドレス情報を全て知っていれば、UserA〜UserB間での通信自体は可能である。しかし，プレゼンスサーバは、各端末の種別までは管理していないので、UserAがIP電話で連絡が取りたいとしても，相手端末のうちどれがIP電話端末なのか分からない。よってUserBが所有する端末の中で実際に電話を掛ける先を特定することができない。
【００１２】
また，従来技術で述べたようにSIPでは1ユーザが複数端末を2重ログインさせるモデルが存在するが，このモデルでは不都合が発生する。例えば，端末315がIP電話端末ではなく，テレビ電話端末や会議端末等IP電話以外の端末であったとする。SIPサーバ41はそれを意識しないので，この状態でUserAがUserBにIP電話で呼び出しを行ってもUserBがログインさせている端末で優先順位が最も高いIP電話以外の端末に呼び出しをかけてしまう。結果UserAの発信端末とUserBの受信端末の端末種別が異なってしまい通話が成立しない。
【００１３】
このようにSIPネットワーク上にIP電話しか存在しない状態ならこの2重ログインモデルが成立するが，IP電話以外の様々な端末が存在する場合はこのq-valueを用いたモデルでは不都合が発生する。
また，プロトコルの共通化により，端末種別が多様化すると，各端末が同一名称のプレゼンス情報を利用した時，そのプレゼンス情報だけでは情報量として不足する可能性が出てくる。例えば、図１１の吹き出し227は、”通話中”という名称のプレゼンス情報を各端末が共通で利用している形態を示している。213から216までの各端末は自端末が現在のセッション確立状態を，プレゼンス情報の名称が”通話情報”と呼ばれる部分に”通話中”もしくは”待機中”のどちらかの値で登録していたとする。211に示すUserAはUserBが所有する各端末の現在のセッション確立状態を”通話中状態”から取得することができる。しかし，”通話情報”には具体的な通話手段は記述されていない。よって，プレゼンス情報を取得した結果，227に示す様に表示したとしても，実際にどのような手段で通話を行っているか分からない。 よって211に示す発信者のUserAは212に示す着信側のUserBが単純に誰かと通話中であるから今は連絡できない，といったレベルの解像度でしか相手の状態を把握できない。もし212で示すUserBが実際には文字チャットで通話をしているのであれば，割り込みにはなるが，緊急の用事ならば電話のベルを鳴らすことは可能であり，この時点で発信者側のユーザがコミュニケーションのタイミングを一つ失ったことになってしまう。
【課題を解決するための手段】
【００１４】
本願発明は上記問題を解決する為に，各端末のログイン時にログイン情報から端末種別を抽出し，プレゼンスサーバに保持する。また他のユーザにプレゼンス情報を通知する時，プレゼンス情報に端末情報を付加し，通知をする。
【発明の効果】
【００１５】
各ユーザはコミュニケーションを取る時，相手ユーザがログインしている端末の種別を把握することが可能となる。よって，コミュニケーションを取りたい発信者は相手ユーザが現在とれるコミュニケーション手段を確認し，自分が希望するコミュニケーション手段に合った相手ユーザ端末の特定をすることが可能となる。
【００１６】
また，プレゼンス情報に端末種別を付加することで，同一プレゼンス項目でも端末種別により詳細なプレゼンス情報を得ることが可能となる。例えば，”通話中状態”と言う名称のプレゼンス情報が”close(話中)”であったとしても，その情報がIP電話のものであると分かればユーザは”電話中”と判断できるし，この情報が会議端末のものであったら”会議中”と判断できるし，チャット端末のものであったら”チャット中”と判断することが可能となる。
【発明を実施するための最良の形態】
【００１７】
本実施例では、まず，プレゼンスサーバの構造、動作、及びプレゼンスサーバを用いたサービスを実現するためのネットワークについて説明する。その後，本願発明を応用したSIPメッセージルーティング方式を適用したSIPサーバの構造，動作について説明を行う。
図１には、本実施例のプレゼンスサーバの機能ブロック図を模式的に示した。図１の機能ブロック図は、ソフトウェア上実現される論理的な機能構成を示した図であるが、各機能ブロックをハードウェアで構成しても構わない。
【００１８】
図２には、図１に示した機能ブロックが、ハードウェア上、どう実現されているかを示した。図１に示した種々の機能ブロックの動作は、図２に示すメモリ22の処理モジュール群26に収納されており，動作時にはＣＰＵ23がその動作手順を読み出して実行する。個々の処理モジュールが動作する際に必要な端末種別情報は、データベース24の端末種別情報管理テーブル30に格納されており，また，プレゼンス情報はデータベース24のプレゼンス情報管理テーブル31に格納されている。これら情報はプレゼンスサーバ1が利用する時に，適時インターフェース33を経由してメモリ22の各種情報テンポラリテーブル25に展開され，ＣＰＵ23で処理が行われる。また，その結果はインターフェース33を経由してデータベース24に書き込む。
【００１９】
図26は図1に示す機能ブロック群の処理についてのフローチャートである。各機能ブロックはメッセージの入出力時に本図のフローチャートに沿って動作を行う。
図3は端末種別情報を用いたサービス一例のネットワーク図であり，図４はそのシーケンス図である。この例では図3の42に示すUserBが所有する端末45，及び46がSIPサーバ41，及びプレゼンスサーバ1にログインを行う。42に示すUserAと47に示すUserCもログインを行い，43に示すUserBの端末45，46のプレゼンス情報を閲覧している状態にある。その後，UserAはUserBに対してIP電話により通話する。以下，これら図面を用いて端末種別情報の抽出から他ユーザへの端末情報付プレゼンス通知までの全体的な動作について説明する。なお，本サービス例は通信プロトコルにSIPを用いてプレゼンスシステムを運用しているが，プレゼンスシステムの構築にSIPが必須であるわけではなく，他のプロトコルを利用する事も可能である。他のプロトコルを利用した場合は具体的なメッセージ内容や詳細なシーケンスは異なるが，基本的な概念は変化しない。さらに図3では43に示すUserBが所有する端末45，46を異なるハードウェアとして記述しているが，図26の様に同一ハードウェア49上の異なるアプリケーション45，46として取り扱うケースも存在する。
【００２０】
まず，図4のステップ51でUserBのテレビ電話端末45がSIPサーバ41，及びプレゼンスサーバ1にログインする。ログイン時のSIPメッセージ内容を図5に示す。SIPではログイン時にREGISTERメソッドを用いたメッセージを送信する。
【００２１】
次に，プレゼンスサーバ1は図5に示すログインメッセージのContactヘッダに記述されたコンタクトアドレス71を端末アドレスとして登録する。また，ステップ52で端末種別情報を認識する。ステップ52の具体的な処理内容について図26（a）を用いて説明する。プレゼンスサーバ1はステップ1291で図1のインタフェース13-1〜13-nからメッセージを受信すると，ステップ1292で端末種別抽出処理を開始する。まずは，ログイン情報送受信部12へ転送，ステップ1293でログイン情報を抽出，つまりコンタクトアドレス71を抽出する。また，ステップ1294で端末種別情報抽出・転送部10がログイン情報のUser-Agentヘッダ値72を抽出し，その情報を端末情報管理部7へ転送する。本例ではUser-Agentヘッダから端末種別を判断しているが，他の方法で端末種別を判断してもよい。例えば，独自のヘッダを拡張する，Contactヘッダに付与するパラメータを独自追加する等の方法が考えられる。Contactヘッダにパラメータを付与する場合の一例を挙げると，“Contact:<sip:UserA@abc.com>;agent=TVPhone”のような記述が考えられる。端末種別の判断方法を変える場合，端末種別情報抽出・転送部10の処理を変更して対応する。
【００２２】
次にプレゼンスサーバ1はステップ1294で抽出した端末種別情報から端末種別を割り出し，ログイン情報と共に記憶する。その具体的な処理を説明する。先ほど端末種別情報抽出・転送部10から転送された端末情報は端末種別情報管理部7が受信する。端末種別情報管理部7はステップ1295で受信した端末種別情報から端末種別を判断する。端末種別情報管理部7は図2のデータベース34の端末種別情報管理テーブル30の中にある入力用テーブル37で図８の(a)に示すテーブル101を管理している。ステップ1295における端末種別判断処理はこのテーブル101を利用して行われる。なお，図2の36で管理する図8(b)のテーブル106はプレゼンス情報を出力する為のテーブルであるが，テーブル101と106はデータベース上での利用を考え，同一テーブル上で管理することも可能である。本例ではログイン端末であるUserBが所有するテレビ電話端末45はログイン情報に”TVPhone/1.0(xxCorp TV Phone)”といった端末種別情報を付与している。SIPの標準が記載されたIETFのRFC3261ではUser-Agentヘッダ値の記述フォーマットはRFC2616と同様である，と記述がある。RFC2616ではUser-Agentヘッダ値の記述フォーマットを”[端末名]/[バージョン番号] ([コメント])”と規定しているので，ステップ1295ではログイン端末の端末種別情報をUser-Agentヘッダ値72からバージョン番号，コメントを差し引いた値である”TVPhone”と判断する。User-Agentヘッダ値の取り扱い方法は本例で示した以外のロジックを利用しても良い。本例では端末種別情報として”端末名”のみを利用しているが，”バージョン番号”や”コメント”部分を端末種別情報として利用するパターンも考えられる。
【００２３】
上記処理でログイン端末の端末種別情報は”TVPhone”と判断した。次にステップ1295では端末種別情報から実際の端末種別を判定する為に，端末種別管理テーブルの入力用テーブル101を検索する。検索対象はログイン情報(User-Agentヘッダ)102であり，検索キーは端末種別情報”TVPhone”である。検索の結果”TVPhone”は内部管理用端末種別103よりテレビ電話であると判断することができる。端末種別情報管理部7は端末種別を判断するとそのデータを端末情報入力部5に送信する。端末情報出力部5はステップ1296でインタフェース33を経由して，データベース24のログイン端末種別管理テーブル34にその情報を登録する。ログイン端末種別管理テーブル34は図7の91に示す形式のテーブルで構成されており，そこに端末種別93とログイン端末識別子92をペアとしたデータレコードを追加する。プレゼンスサーバ1はステップ1297で本処理と同時に端末のログイン状態やプレゼンス情報を管理するテーブルであるデータベース34のプレゼンス情報管理テーブル31にログインした端末の情報を記述する。プレゼンス情報管理テーブル31は図6の81に示す形式のテーブルで構成されており，ログイン端末の識別子である端末アドレス82，その端末の所有者83をペアとしたデータレコードを追加する。他のセッション情報84や現在状態83等のプレゼンス情報はログイン処理とは異なる方法で別途登録する形となる。本例ではプレゼンス情報とログイン情報を別シーケンスとして取り扱っているが，同一メッセージを利用して1シーケンスで行うことも可能である。
【００２４】
次に43で示すUserBはIP電話端末46をステップ53，54でログインさせるが，この時に発生するプレゼンスサーバ1の処理手順はステップ51，52の時と同様である。但し，IP電話端末46がSIPサーバ41及びプレゼンスサーバ1に送信するログインメッセージのUser-Agentヘッダ値は図5の72で示した値とは異なる。これはテレビ電話端末45とIP電話端末46は端末種別が異なるためである。結果プレゼンスサーバ1はIP電話端末46をテレビ電話端末45とは異なる端末種別として認識する。これは端末種別情報にUser-Agentヘッダを用いなかった場合でも同様であり，異なる端末は必ず異なる端末種別情報を付与してログインを行う。
【００２５】
その後，42で示すUserAがIP電話端末44をログインさせるが，この時に発生するプレゼンスサーバ1の処理手順についてもステップ51，52と同様である。
ここで，IP電話端末44と46は端末の種別は同一であるが，44はUser-Agentヘッダの値に”IPPhone”を，46は”IPTelephone”を記述されていたとする。つまり同一種別でも異なるUser-Agentヘッダ値が記述されていた場合である。例えば，同じIP電話端末でも開発したベンダによりこの様に付与するUser-Agentヘッダ値が変わる可能性が考えられる。プレゼンスサーバ1はこの様な同一端末種別で異なるUser-Agentヘッダ値が記述された端末でも同一の端末種別にマッピングする。これは図8(a)のテーブル101に記述された2つのレコード1101，1102のように管理を行い，異なるUser-Agentヘッダ102でも同一の内部管理用端末種別103，出力形態(SIMPLE用)104にマッピングするからである。この様に端末種別情報を管理する際に，各端末が通知する端末種別情報を内部管理用の端末種別情報に翻訳する為の辞書となるテーブルを用意することで，多数ベンダが設計した端末を機能やサービス等で分類することが可能となる。さらにベンダによってはログイン時にこの様な端末種別の識別子を全く付けない可能性もある。この様な端末についてはレコード1103の様に一律デフォルトの端末種別にマッピングする方法が考えられる。または，異なる方法を用いて端末種別を判断する方法も考えられる。
【００２６】
次に42に示すUserAは43に示すUserBの現在のプレゼンス情報確認，及び今後プレゼンス情報変更時の通知を予約する為に，ステップ36でプレゼンスサーバ1に対して情報取得要求を送信する。インターフェースにSIP/SIMPLEを利用している場合は非特許文献３の記述に従いSUBSCRIBEメソッドを利用したメッセージを送信する。
【００２７】
メッセージを受信したプレゼンスサーバ１は，図4のステップ57でUserBのプレゼンス情報をUserAに通知する為の処理を行う。具体的な処理内容について図26(b)を用いて説明する。ステップ1301においてプレゼンスサーバ1内部でプレゼンス情報の通知要求が発生するとステップ1302で通知処理を開始する。まずステップ1303でUserBがUserAに対してプレゼンス情報公開自体を許可しているかどうかを調べる。具体的には図2のデータベース24にあるパーミッション情報管理テーブル35に記述されたパーミッション情報を検索する。本テーブルの具体的な構成を図12に示す。テーブル35はプレゼンス情報の閲覧を求めるアクセスユーザ302，プレゼンス情報を公開するユーザであるアクセス対象ユーザ303，アクセス対象ユーザのプレゼンス公開ポリシを記述したパーミッション情報304から構成される。パーミッション情報の中には各プレゼンス情報や端末毎のパーミッション情報，つまり公開するかしないかの設定が記載されている。本例ではUserBがUserAのプレゼンス情報を閲覧する状態なので，検索キーをカラム302はUserB，カラム303はUserAとして検索を行う。また，検索されたパーミッション情報は後のプレゼンス情報構築時に利用するために，図2の各種情報テンポラリテーブル25に一時的に保存される。
【００２８】
プレゼンスサーバ1はプレゼンス情報公開許可を確認した後，ステップ1304で端末情報出力部5を使い，図2のデータベース24のプレゼンス情報管理テーブル31からUserBの全プレゼンス情報をインターフェース33経由で取得する。なお，UserBのプレゼンス情報とはUserBが所有するテレビ電話端末45，IP電話端末46両方のプレゼンス情報を指す。データベース24から取得したプレゼンス情報は後のプレゼンス情報構築の為に図２のメモリ22上にある各種情報テンポラリテーブル25に保持される。次に，プレゼンスサーバ1はステップ1305において図1の通知情報選択部14で各種情報テンポラリテーブル25に保持されたUserBのプレゼンス情報からUserAへの通知を許可されたプレゼンス情報を選択する。本処理は先ほど検索して各種情報テンポラリテーブル25に一時的に保持された，UserBのUserAに対するパーミッション情報を用いて行う。公開パーミッションが許可されていないプレゼンス情報はこのステップでフィルタリングされる。フィルタリングされたUserBのプレゼンス情報はプレゼンス情報構築部9へ転送される。
【００２９】
次にステップ1306において，端末種別情報管理部7に問い合わせを行い，各端末の端末種別情報とプレゼンス情報構築時の付加情報を取得する。プレゼンス情報の通知方法はプロトコル毎に異なる。よって，端末種別情報の付与方法についてもプロトコル毎に異なる。図8(b)の106に示す端末種別情報管理テーブルには各プロトコルでの出力形態について記述されている。プロトコル毎に出力形態を変化させてプレゼンス情報の通知を行う。本例ではSIP/SIMPLE以外に105でHTTP用の出力形態を記述している。次にステップ1307においてプレゼンス情報構築部9がUserAに通知を行う時のフォーマットで通知内容を構築する。
【００３０】
本例ではUserAに対して非特許文献４で規定されたPIDF(Presence Information Data Format)と呼ばれるフォーマットを用いてプレゼンス情報を通知する。また，端末種別情報の付加はPIDFの元フォーマットであるXML(eXchange Markup Language)の名前空間(Name Space)機能を利用する。構築されたプレゼンス情報の例を図9に示す。図9の111，112には図8に記述されたIP電話とテレビ電話用の名前空間が定義されている。XMLはまず名前空間を利用する為にその定義を記述する必要がある。図3の43に示すUserBはテレビ電話端末45とIP電話端末46の2端末を所有しており，それらすべてのプレゼンス情報をUserAに通知するので2端末の端末種別を識別する為に2つの名前空間を定義する。また，名前空間を表現する時の省略系をこの定義部分で宣言し，その後，XML文章に名前空間を付与する場合はその省略形の文字列を接頭辞として記述すればよい。本例ではテレビ電話端末用の名前空間の接頭辞を”tvphone”と定義し，IP電話用の名前空間の接頭辞を”phone”と定義する。
【００３１】
その後に記述されるプレゼンス情報にはこの端末種別を表すXML接頭辞をプレゼンス情報名称の前段に付与する。図9の113，114はそれぞれIP電話の現在状態(Availability)，電話中情報(Session Status)であるので接頭辞は”phone”となる。また，115，116はテレビ電話の現在状態と電話中情報であるので接頭辞は”tvphone”となる。本例ではXML名前空間を利用して端末情報を付与したが，端末種別を一プレゼンス情報と考え，他のプレゼンス情報と並列に記述する方法も考えられる。
上記処理で作成されたプレゼンス情報はステップ1308において，図1のプレゼンス情報送受信部11に転送され，非特許文献３で規定されたNOTIFYメソッドを用いたSIPメッセージにより図4のステップ58でUserAに送信される。
【００３２】
その後，図3の59に示すUserCが所有するIP電話端末48でログインしてきたとする。図4のステップ59からステップ63までの処理手順は上記のUserAがログインする場合と同様であり，UserCもUserBのプレゼンス情報を閲覧している状態である。
次に図3の43に示すUserAが自分の所有するIP電話端末44を利用してUserBに電話を掛けようとしたとする。UserAはステップ58で受信したUserBのプレゼンス情報より，UserBが所有する端末の中でどれがIP電話端末かを把握することが可能である。具体的には117，118に記述された端末識別子(SIPアドレス)で端末アドレスを確認し，XML名前空間により各端末の端末種別を確認する。よってUserAは図3の43に示すUserBが所有するIP電話端末46の電話ベルを直接鳴らすことが可能であり，間違ってテレビ電話端末45に向かって呼び出しをかけることはない。
【００３３】
図4のステップ64でUserAがUserBを呼び出し，通話を開始する。その時UserBが所有するIP電話端末46はステップ65で自分が通話状態になったことをプレゼンスサーバ1に通知する。プレゼンスサーバ1はUserBのプレゼンスに変化があったので通知予約しているUserAとUserCに対してステップ66及び67でプレゼンス情報更新の通知を行う。
【００３４】
ステップ68でUserAとUserBが通話中の時はUserBが所有するIP電話端末のプレゼンス情報の一つである”通話中情報”が”通話中”となる。UserCがUserBに連絡を取りたいと考えてもUserBのIP電話端末が通話中状態にある，つまりUserBは電話中であることが分かるのでUserCはUserBの電話が終るまでは電話しても出てもらえないと把握できる。UserBが文字チャット用端末を所有しており，文字チャット端末の”通話中情報”が通話中であるならUserCは，UserBの文字チャット端末が通話中状態にある，つまりUserBはチャット中であることが分かる。この時UserBは一応チャットの文字を入力するのに手は利用しているが，耳と口は利用可能であるので緊急の連絡ならUserCはUserBに連絡できると判断することが可能となる。また，UserAもUserBと直接通話してはいるが，UserBのIP電話端末の”通話中情報”が通話中であることをUserCと同様に把握できる。
【００３５】
その後，ステップ69でUserAとUserBの通話が終了するとステップ70でUserBのIP電話端末46がセッション終了をプレゼンスサーバ1に通知し，その結果プレゼンスサーバ1がステップ1070，1071でUserAとUserCに対してUserBのIP電話の”通話中情報”がアイドル状態であることを通知する。
【００３６】
また，この時UserAとUserBに通知されるプレゼンス情報には図9の様な形で端末情報が付与される。この情報を利用することによりUserA，UserCの端末のGUI上にセッション情報を表示する時，端末種別からどのようなアプリケーションでセッションを確立しているかを表示させることが可能となる。図14の吹き出し228は実際にUserAのGUI上でどのような表示がされているかを示している。また，図15の1221はUserA，UserCの端末内部で保持するテーブルイメージであり，各端末がどのようにセッション情報の表示形式を決定しているかについて記述されている。例えば，UserBが所有する端末Aはセッション情報1224の値が”接続中”であり，端末種別1225がIP電話であることから表示形式1226は”電話中”であると計算されている。この計算は端末依存であり，端末毎に異なる可能性もある。UserAの端末では”電話中”と計算されたので，図14の228にはBさんの端末Aは電話中である旨の表示が行われている。
【００３７】
図16は図4の1072の部分のシーケンスを別方法で実現した場合の図である。図16の1072部分以外のシーケンスは図4と同様である。図4のシーケンスでは，各端末のセッションが確立した時，セッションが終了した時にそれぞれステップ65，70でプレゼンスサーバ1に対してそのことをプレゼンス情報として通知していた。図16ではこの方法が図4とは異なる。図16ではセッション確立，終了を各端末がプレゼンスサーバ1に通知するのではなく，SIPサーバ41がステップ1111，及び1112で通知する。SIPサーバ41は各端末のセッション情報を管理するサーバであり，44に示すUserAと46に示すUserBの端末2のセッションの確立，終了の状態も把握している。よって，セッション確立，終了の情報を各端末の代わりにプレゼンスサーバ1に対して通知することが可能である。本方法を用いることで既存のセッション情報を通知する機能を有さないIP電話がセッションを確立，終了してもSIPサーバがセッション状態を代理でプレゼンスサーバ１に登録する為，他のユーザはその端末のセッション状態を把握することが可能となる。
【００３８】
図17はSIPサーバ321が各端末の端末種別を把握したルーティングを行った場合のネットワーク図である。また，図18はそのシーケンス図である。また，図19は本方式のルーティングを行う為のSIPサーバの機能ブロック図であり，図20はSIPサーバのフローチャート図である。また，図21は端末種別を把握したルーティングを図18の方式とは異なる方式で実現した場合のシーケンス図であり，図22はその時のSIPサーバ機能ブロック図，図23，24はその際のSIPサーバが行う処理のフローチャート図である。また，図25は本方式を採用したSIPサーバのハードウェア構成図である。図19，22に示した種々の機能ブロックの動作は図1，2と同様，メモリ1272の処理モジュール群1279に収納されており，動作時にはCPU1273がその動作手順を読み出して実行する。個々の処理モジュールが動作する際に必要な情報はメモリ1272上のロケーションテーブル1278及び端末種別テーブル1280に格納されている。また，図19，22の機能ブロック図は、ソフトウェア上実現される論理的な機能構成を示した図であるが、各機能ブロックをハードウェアで構成しても構わない。
【００３９】
まず，図18，21と図4の違いについて説明する。前述，図4のシーケンスでは，44に示すUserAが所有する端末(IP電話)が相手ユーザのログインさせている端末の端末種別をプレゼンス情報から取得し，その情報を用いて端末44自身がUserBのログインさせている端末のうち，46に示すIP電話端末を呼び出す判断を行っていた。しかし，もし44に示すUserAのIP電話端末が図17の324の様にプレゼンス取得機能を持っていなかった場合，相手の端末種別を特定することができない。よって，この方法をそのまま利用することはできなくなる。図18，21のシーケンス図で示した方法ではUserBがログインさせている端末種別の確認を324に示すUserAのIP電話端末ではなく，SIPサーバ321が代理で行う。結果324に示すUserAのIP電話端末がプレゼンス情報取得機能を持たなくても，端末種別を意識した呼び出しを行うことが可能となる。以下，その方法について図18,21のシーケンス図を用いて説明する。なお，図17の323に示すUserBが所有する端末325，326は別々のハードウェアとして記述されているが，図3の時と同様，図10の端末49，アプリケーション45，46の様な形態を取っても構わない。
【００４０】
図18では，まず，ステップ1121で325に示すUserBのIP電話端末がSIPサーバ321，及びプレゼンスサーバ1にログインする。この時ステップ1122でプレゼンスサーバ1は端末325の端末種別情報を抽出するが，方法については前述の方法と同様である。またSIPサーバ321は端末ログイン時に図19ログイン情報送受信モジュール1204でログインメッセージを受信後，端末ロケーション管理モジュール1206でログイン端末の情報を図25のロケーションテーブル1278に保存する。その後，ステップ1123で326に示すUserBの端末2が，ステップ1125で324に示すUserAのIP電話端末がログインを行うが，その時の処理手順はステップ1121，1122と同様である。次に，324に示すUserAのIP電話端末がUserBを呼び出す。この時，端末324はUserBのプレゼンスを把握していないので，端末アドレスではなく，UserBのユーザそのもののアドレスを指定して呼び出しを行う。その呼び出しを受信したSIPサーバ321は呼び出し元のUserAの端末324の端末種別と呼び出し先のUserBがログインさせている端末の端末種別をステップ1128でプレゼンスサーバ1に問い合わせる。問い合わせを受信したプレゼンスサーバ1はその結果をステップ1123で返信する。具体的には，SIPサーバ321はUserAのIP端末324からステップ1127でUserBの呼び出し用のSIPメッセージを受信すると，図20のステップ1211でSIPメッセージを受信し，ステップ1212でメッセージ転送のための処理を開始する。まず，SIPサーバ321はステップ1213において図19のメッセージルーティングモジュール1203でメッセージの種別を判別する。メッセージ種別を判別するとステップ1214において，そのメッセージ種別が端末種別を意識したルーティングを必要とするかどうかを判定する。
【００４１】
この時，端末種別を意識する必要が無いと判断するとステップ1220に進み，通常のSIPメッセージルーティングを行い，ステップ1221でメッセージを転送しステップ1224で処理が終了する。端末種別を意識する必要がある場合はステップ1215に進む。ステップ1215では図19の端末情報問い合わせモジュール1205を利用してプレゼンスサーバ1に対して送信元であるUserAのIP端末324の端末種別，及び，UserBが現在ログインさせている端末の端末種別を問い合わせる。問い合わせ方法はSIPメッセージを利用しても良いし，その他の方法を用いても良い。その後，図18のステップ1129でプレゼンスサーバ1から端末種別情報を受信すると図20のステップ1216で送信元であるUserAのIP端末324の端末種別を確認し，続いてステップ1217で送信先であるUserBのログイン端末とその種別を確認する。本例ではUserBがログインさせている端末はテレビ電話端末325，及びIP電話端末326であるのでこれを確認する。次に，ステップ1218においてメッセージルーティングモジュール1203は送信元であるUserAのIP電話端末324と同じ端末種別の端末を送信先であるUserBがログインさせているかどうかを調査する。もし，送信先であるUserBが送信元と同一種別の端末をログインさせていない場合，UserBがログインさせているどの端末にメッセージを転送してもコネクションが成立しない。
【００４２】
よって，SIPサーバ321はメッセージを転送せず，ステップ1222で送信元であるUserAに対するコネクション先に接続できないことを示す403レスポンスメッセージを作成し，ステップ1223でレスポンスメッセージをUserAに対して返信して，ステップ1224で処理を終了する。本例ではUserBはIP電話端末326をログインさせているので送信先に同一種別の端末が存在する。よって，処理はステップ1219に進み，呼び出しメッセージの転送先アドレスをUserBのIP電話端末326にセットしてステップ1221でそのメッセージを送信する。そして，ステップ1224で処理を終了する。
結果UserAからUserBの呼び出しメッセージは図18のステップ1130でSIPサーバ321からUserBのIP電話端末326へ転送され，ステップ1131で通話が開始する。その後，ステップ1132で通話が終了する。
【００４３】
図21はSIPサーバ321が端末種別を意識したメッセージルーティングを図18に示した方法以外で実現した場合のシーケンスである。図18と異なる部分はSIPサーバ321が各端末の端末種別を調査する時の方法である。図18ではこれをプレゼンスサーバ１に問い合わせることにより実現していたが，図21ではSIPサーバ321がプレゼンスサーバ1と同様の端末種別抽出機能を有し，ログイン情報受信時に端末種別をSIPサーバ単体で把握する。図21について詳細を説明する。
【００４４】
図21では図18と同様まずステップ1141でUserBのテレビ電話端末325がSIPサーバ321，及びプレゼンスサーバ1にログインする。次にSIPサーバ321はプレゼンスサーバ1へログインメッセージを転送する前に，ステップ1142でログイン端末の端末種別を抽出する。具体的には図23の1231でログインメッセージを受信後，ステップ1232で端末種別を把握する為の処理を行う。処理が開始するとステップ1233において図22の端末種別情報抽出モジュール1207で端末種別情報をログインメッセージから抽出する。この処理内容はプレゼンスサーバ1が端末種別を把握する時の処理と全く同様であり，ログインメッセージであるREGISTERメッセージのヘッダ，パラメータ等から端末種別の判定材料にする部分を抽出する。次にステップ1234で端末種別を判定するが，本処理もプレゼンスサーバ1と同様である。判定された端末情報はステップ1225で図25のメモリ1272にある端末種別テーブル1280に登録される。また，ログイン情報をステップ1236で図25のメモリ1280上のロケーションテーブル1278に登録し，ステップ1237で処理が終了する。その後SIPサーバ321は図21のステップ1143でログイン情報をプレゼンスサーバ1に転送する。
【００４５】
その後のステップ1144のプレゼンスサーバ1の処理は前述と同様となる。その後，UserBのIP電話端末326とUesrAのIP電話端末324がそれぞれステップ1145，1149でログインを行うが，その時のSIPサーバ321，プレゼンスサーバ1の処理手順はステップ1141の場合と同様である。その後，ステップ1153でUserAのIP電話324がUserBを呼び出す。ここでSIPサーバ321はステップ1154でUserBがログインさせている端末の中でどの端末を呼び出すかを判断するが，図18のシーケンス手順とは異なり，SIPサーバ321はプレゼンスサーバ1に端末種別情報を問い合わせるのではなく，図25のメモリ1272上にある端末種別テーブル1280で端末種別情報を検索する。具体的には図24のフローチャートで処理が行われる。図24のフローチャートはステップ1255以外，図19と同様である。ステップ1255では図22の端末種別情報管理モジュール1208に問い合わせを行いUserAの端末324，325に示すUserBの端末１及び326に示す端末2の端末種別を調査する。その後，ステップ1154により送信先端末の選択をSIPサーバ321内部で行った結果，ステップ1155でSIPサーバ321はUserAからUserBへの呼び出しメッセージを326に示すUserBの端末2，つまりIP電話端末に転送する。結果，ステップ1156で通話が開始され，その後ステップ1157で通話が終了する。
【図面の簡単な説明】
【００４６】
【図１】本願発明における端末種別管理方式を適用したプレゼンスサーバの機能ブロック図である。
【図２】本願発明における端末種別管理方式を適用したプレゼンスサーバの装置図である。
【図３】本願発明装置を用いた接続形態を示すネットワーク図である。
【図４】本願発明装置を用いた接続形態の動作シーケンス図である。
【図５】SIPを用いたログイン時の送信メッセージ詳細である。
【図６】本願発明装置が記憶するプレゼンス情報のテーブル図である。
【図７】本願発明装置が記憶するログイン端末種別管理用のテーブル図である。
【図８】本願発明装置が記憶する端末種別情報管理用のテーブル図である。
【図９】本願発明装置が外部に送信するプレゼンス情報の記述形式例である。
【図１０】本願発明装置を用いた接続形態を表すネットワーク図である。
【図１１】IMサービスで実施中のプレゼンス情報サービスをSIPサーバを用いた通信ネットワークで提供する場合に発生する問題点を説明するための図である。
【図１２】本願発明装置が記憶するパーミッション情報用のテーブル図である。
【図１３】従来技術で1ユーザが2重ログインする場合の接続形態を示すネットワーク図である。
【図１４】本願発明の端末種別管理機能とセッション情報を組み合わせた場合のユーザ端末上での表示形式イメージ図である。
【図１５】本願発明で用いる端末種別情報をユーザ端末が記憶する時のテーブル図である。
【図１６】図３におけるシーケンスでセッション開始，終了をSIPサーバが代理で行う場合のシーケンス図である。
【図１７】本願発明装置を用いた接続形態を表すネットワーク図である。
【図１８】本願発明装置を用いた接続形態の動作シーケンス図である。
【図１９】本願発明における端末種別管理方式を適用したSIPサーバの機能ブロック図である。
【図２０】本願発明SIPサーバにおける端末種別管理のメッセージルーティング時の処理フローチャート図である。
【図２１】本願発明装置を用いた接続形態の動作シーケンス図である。
【図２２】本願発明における端末種別管理方式を適用したSIPサーバの機能ブロック図である。
【図２３】本願発明SIPサーバにおける端末種別識別時の処理フローチャート図である。
【図２４】本願発明SIPサーバにおけるメッセージルーティング時の処理フローチャート図である。
【図２５】本願発明における端末種別管理方式を適用したSIPサーバの装置図である。
【図２６】本願発明プレゼンスサーバにおける端末種別識別時，及びプレゼンス情報通知時の処理フローチャート図である。
【符号の説明】
【００４７】
１・・・プレゼンスサーバ、２・・・パーミッション情報制御部、３・・・パーミッション管理部。
【図１】
2005318503.tif 000003
【図２】
2005318503.tif 000004
【図３】
2005318503.tif 000005
【図４】
2005318503.tif 000006
【図５】
2005318503.tif 000007
【図６】
2005318503.tif 000008
【図７】
2005318503.tif 000009
【図８】
2005318503.tif 000010
【図９】
2005318503.tif 000011
【図１０】
2005318503.tif 000012
【図１１】
2005318503.tif 000013
【図１２】
2005318503.tif 000014
【図１３】
2005318503.tif 000015
【図１４】
2005318503.tif 000016
【図１５】
2005318503.tif 000017
【図１６】
2005318503.tif 000018
【図１７】
2005318503.tif 000019
【図１８】
2005318503.tif 000020
【図１９】
2005318503.tif 000021
【図２０】
2005318503.tif 000022
【図２１】
2005318503.tif 000023
【図２２】
2005318503.tif 000024
【図２３】
2005318503.tif 000025
【図２４】
2005318503.tif 000026
【図２５】
2005318503.tif 000027
【図２６】
2005318503.tif 000028
【手続補正書】
【提出日】平成17年4月19日(2005.4.19)
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の端末間の通信接続制御を行う接続制御サーバに接続されることが可能で、かつ前記複数の端末の状態情報を管理するプレゼンスサーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項２】
請求項１記載のプレゼンスサーバであって、
前記制御部は、前記回線インターフェースで受信したログインメッセージに含まれる情報から、前記通信接続制御サーバに接続している前記送信元端末の端末種別情報を抽出し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記接続制御サーバを介して前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項３】
請求項１に記載のプレゼンスサーバであって、
前記端末種別情報の通知可否情報を前記送信元端末の通信相手ごとに格納したテーブルを備え、
前記端末種別情報の通知が可である相手端末に対してのみ、該端末種別情報を送信することを特徴とするプレゼンスサーバ。
【請求項４】
請求項１に記載のプレゼンスサーバであって、
さらに辞書テーブルを備え、
前記制御部は、前記受信パケット内の情報から抽出した前記端末種別情報を、前記辞書テーブルを用いて内部管理用端末種別情報に変換することを特徴とするプレゼンスサーバ。
【請求項５】
請求項１に記載のプレゼンスサーバであって、
前記制御部は、
前記複数の端末それぞれに対して前記端末種別情報を付与することが可能であり、
前記複数の端末のそれぞれごとに、前記端末種別情報を付与する方法を変更できることを特徴とするプレゼンスサーバ。
【請求項６】
請求項５に記載のプレゼンスサーバであって、
前記制御部は、
前記複数の端末のそれぞれが用いる端末種別情報通知プロトコルに応じて前記端末種別情報の出力方法を変更することを特徴とするプレゼンスサーバ。
【請求項７】
請求項１に記載のプレゼンスサーバであって、
前記制御部は、前記受信パケット内の情報のうち、前記端末種別情報を抽出する部分を自由に設定できることを特徴とするプレゼンスサーバ。
【請求項８】
複数の端末間の通信接続制御を行う接続制御サーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の前記端末種別情報を、前記相手端末に送信することを特徴とするセッション制御サーバ。
【請求項９】
請求項８記載のセッション制御サーバであって、
前記制御部は、前記回線インターフェースで受信したログインメッセージに含まれる情報から、前記送信元端末の端末種別情報を抽出することを特徴とするセッション制御サーバ。
【請求項１０】
請求項８に記載のセッション制御サーバであって、
さらに辞書テーブルを備え、
前記制御部は、前記受信パケット内の情報から抽出した前記端末種別情報を、前記辞書テーブルを用いて内部管理用端末種別情報に変換することを特徴とするセッション制御サーバ。
【請求項１１】
請求項８に記載のセッション制御サーバであって、
前記制御部は、
前記複数の端末それぞれに対して前記端末種別情報を付与することが可能であり、
前記複数の端末のそれぞれごとに、前記端末種別情報を付与する方法を変更できることを特徴とするセッション制御サーバ。
【請求項１２】
請求項９に記載のセッション制御サーバであって、
前記制御部は、
前記複数の端末のそれぞれが用いる端末種別情報通知プロトコルに応じて端末種別情報の出力方法を変更することを特徴とするセッション制御サーバ。
【請求項１３】
請求項８に記載のセッション制御サーバであって、
前記制御部は、前記受信パケット内の情報のうち、前記端末種別情報を抽出する部分を自由に設定できることを特徴とするセッション制御サーバ。
【請求項１４】
請求項８に記載のセッション制御サーバであって、
前記端末種別情報を利用してメッセージの振り分けを行うことが可能であることを特徴とするセッション制御サーバ。
【請求項１５】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けのポリシを自由に変更可能なことを特徴とするサーバ。
【請求項１６】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けの対象とするメッセージ種別を自由に設定することが可能であることを特徴とするサーバ。
【請求項１７】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けの際に、振り分け先が見つからない場合に，その旨を発信者に返すことを特徴とするセッション制御サーバ。
【請求項１８】
請求項８乃至１７のいずれかに記載のセッション制御サーバであって、
セッション制御プロトコルにSIP(Session Initiation Protocol)を用いることを特徴とするセッション制御サーバ。
【請求項１９】
端末またはサーバから送信されるパケットを受信して他のサーバまたは端末にパケットを中継するパケット中継システムであって、
前記端末またはサーバから送信されたパケットから、該端末またはサーバの端末種別を把握する手段と、
前記端末種別を記憶する手段と、
該端末種別を用いて目的の合った端末同士、サーバ同士、または端末とサーバ同士を接続することを特徴とするパケット中継システム。
【請求項２０】
複数の端末の状態情報を管理するサーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするサーバ。
【請求項２１】
複数の端末間の通信接続制御を行う接続制御サーバに接続され、かつ前記複数の端末の状態情報を管理するプレゼンスサーバであって、
前記接続制御サーバからパケットを受信する回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項２２】
複数の端末間の通信接続制御を行う接続制御サーバと、複数の端末の状態情報を管理するサーバとを備えたシステムであって、
上記接続制御サーバは、
パケットを受信し、該パケットの送信元端末の端末種別を示す情報含むパケットを上記状態情報を管理するサーバに送信する回線インターフェースを有し、
上記状態情報を管理するサーバは、
上記接続制御サーバから上記パケットを受信する回線インターフェースと、
該パケット内に含まれる上記端末種別を示す情報から上記送信元端末の端末種別情報を抽出する制御部と、
上記抽出された端末種別情報と、上記送信元端末と通信を行っている相手端末と上記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
上記状態情報を管理するサーバの回線インターフェースは、上記送信元端末の端末種別情報を、上記相手端末に送信することを特徴とするシステム。
【手続補正書】
【提出日】平成17年9月27日(2005.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の端末間の通信接続制御を行う接続制御サーバに接続されることが可能で、かつ前記複数の端末の状態情報を管理するプレゼンスサーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項２】
請求項１記載のプレゼンスサーバであって、
前記制御部は、前記回線インターフェースで受信したログインメッセージに含まれる情報から、前記通信接続制御サーバに接続している前記送信元端末の端末種別情報を抽出し、前記回線インターフェースは、前記送信元端末の端末種別情報を、前記接続制御サーバを介して前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項３】
請求項１に記載のプレゼンスサーバであって、
前記端末種別情報の通知可否情報を前記送信元端末の通信相手ごとに格納したテーブルを備え、
前記端末種別情報の通知が可である相手端末に対してのみ、該端末種別情報を送信することを特徴とするプレゼンスサーバ。
【請求項４】
請求項１に記載のプレゼンスサーバであって、
さらに辞書テーブルを備え、
前記制御部は、前記受信パケット内の情報から抽出した前記端末種別情報を、前記辞書テーブルを用いて内部管理用端末種別情報に変換することを特徴とするプレゼンスサーバ。
【請求項５】
請求項１に記載のプレゼンスサーバであって、
前記制御部は、
前記複数の端末それぞれに対して前記端末種別情報を付与することが可能であり、
前記複数の端末のそれぞれごとに、前記端末種別情報を付与する方法を変更できることを特徴とするプレゼンスサーバ。
【請求項６】
請求項５に記載のプレゼンスサーバであって、
前記制御部は、
前記複数の端末のそれぞれが用いる端末種別情報通知プロトコルに応じて前記端末種別情報の出力方法を変更することを特徴とするプレゼンスサーバ。
【請求項７】
請求項１に記載のプレゼンスサーバであって、
前記制御部は、前記受信パケット内の情報のうち、前記端末種別情報を抽出する部分を自由に設定できることを特徴とするプレゼンスサーバ。
【請求項８】
複数の端末間の通信接続制御を行うセッション制御サーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の前記端末種別情報を、前記相手端末に送信することを特徴とするセッション制御サーバ。
【請求項９】
請求項８記載のセッション制御サーバであって、
前記制御部は、前記回線インターフェースで受信したログインメッセージに含まれる情報から、前記送信元端末の端末種別情報を抽出することを特徴とするセッション制御サーバ。
【請求項１０】
請求項８に記載のセッション制御サーバであって、
さらに辞書テーブルを備え、
前記制御部は、前記受信パケット内の情報から抽出した前記端末種別情報を、前記辞書テーブルを用いて内部管理用端末種別情報に変換することを特徴とするセッション制御サーバ。
【請求項１１】
請求項８に記載のセッション制御サーバであって、
前記制御部は、
前記複数の端末それぞれに対して前記端末種別情報を付与することが可能であり、
前記複数の端末のそれぞれごとに、前記端末種別情報を付与する方法を変更できることを特徴とするセッション制御サーバ。
【請求項１２】
請求項９に記載のセッション制御サーバであって、
前記制御部は、
前記複数の端末のそれぞれが用いる端末種別情報通知プロトコルに応じて端末種別情報の出力方法を変更することを特徴とするセッション制御サーバ。
【請求項１３】
請求項８に記載のセッション制御サーバであって、
前記制御部は、前記受信パケット内の情報のうち、前記端末種別情報を抽出する部分を自由に設定できることを特徴とするセッション制御サーバ。
【請求項１４】
請求項８に記載のセッション制御サーバであって、
前記端末種別情報を利用してメッセージの振り分けを行うことが可能であることを特徴とするセッション制御サーバ。
【請求項１５】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けのポリシを自由に変更可能なことを特徴とするサーバ。
【請求項１６】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けの対象とするメッセージ種別を自由に設定することが可能であることを特徴とするサーバ。
【請求項１７】
請求項１４に記載のセッション制御サーバであって、
前記端末種別を利用したメッセージ振り分けの際に、振り分け先が見つからない場合に，その旨を発信者に返すことを特徴とするセッション制御サーバ。
【請求項１８】
請求項８乃至１７のいずれかに記載のセッション制御サーバであって、
セッション制御プロトコルにSIP(Session Initiation Protocol)を用いることを特徴とするセッション制御サーバ。
【請求項１９】
端末またはサーバから送信されるパケットを受信して他のサーバまたは端末にパケットを中継するパケット中継システムであって、
前記端末またはサーバから送信されたパケットから、該端末またはサーバの端末種別を把握する手段と、
前記端末種別を記憶する手段と、
該端末種別を用いて目的の合った端末同士、サーバ同士、または端末とサーバ同士を接続することを特徴とするパケット中継システム。
【請求項２０】
複数の端末の状態情報を管理するサーバであって、
回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするサーバ。
【請求項２１】
複数の端末間の通信接続制御を行う接続制御サーバに接続され、かつ前記複数の端末の状態情報を管理するプレゼンスサーバであって、
前記接続制御サーバからパケットを受信する回線インターフェースと、
該回線インターフェースで受信したパケットの送信元端末の端末種別情報を前記受信パケット内の情報から抽出する制御部と、
前記抽出された端末種別情報と、前記送信元端末と通信を行っている相手端末と前記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
前記回線インターフェースは、前記送信元端末の端末種別情報を、前記相手端末に送信することを特徴とするプレゼンスサーバ。
【請求項２２】
複数の端末間の通信接続制御を行う接続制御サーバと、複数の端末の状態情報を管理するサーバとを備えたシステムであって、
上記接続制御サーバは、
パケットを受信し、該パケットの送信元端末の端末種別を示す情報含むパケットを上記状態情報を管理するサーバに送信する回線インターフェースを有し、
上記状態情報を管理するサーバは、
上記接続制御サーバから上記パケットを受信する回線インターフェースと、
該パケット内に含まれる上記端末種別を示す情報から上記送信元端末の端末種別情報を抽出する制御部と、
上記抽出された端末種別情報と、上記送信元端末と通信を行っている相手端末と上記送信元端末間の接続状態情報とを対応させて記憶する記憶部とを有し、
上記状態情報を管理するサーバの回線インターフェースは、上記送信元端末の端末種別情報を、上記相手端末に送信することを特徴とするシステム。