プレゼンス情報配信装置及び方法
【課題】通信トラフィックの増加を抑制し、しかもＳＩＰアプリケーション・サーバにおけるキャッシュメモリ容量の低減と検索処理負荷の軽減を図る。
【解決手段】プレゼンス要求が受信されたとき、該当するダイアログが存在しない場合に、プレゼンスサーバ３から当該ユーザＡのプレゼンス情報を取得して要求元のクライアント装置ＣＴへ転送すると共に、ＳＮＳサーバ４からユーザＡの友人リストを取得する。そして、この友人リストから友人数Ｎを抽出して、このユーザＡの友人数Ｎをキャッシュメモリ４０に既にキャッシュされている他のユーザの最少友人数Ｎmin と比較し、Ｎ≧Ｎminであれば、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザのキャッシュ情報に代えて、上記ユーザＡのキャッシュ情報を記憶させ、上記最少友人数Ｎmin のユーザのＳＩＰダイアログを開放するようにしている。
【解決手段】プレゼンス要求が受信されたとき、該当するダイアログが存在しない場合に、プレゼンスサーバ３から当該ユーザＡのプレゼンス情報を取得して要求元のクライアント装置ＣＴへ転送すると共に、ＳＮＳサーバ４からユーザＡの友人リストを取得する。そして、この友人リストから友人数Ｎを抽出して、このユーザＡの友人数Ｎをキャッシュメモリ４０に既にキャッシュされている他のユーザの最少友人数Ｎmin と比較し、Ｎ≧Ｎminであれば、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザのキャッシュ情報に代えて、上記ユーザＡのキャッシュ情報を記憶させ、上記最少友人数Ｎmin のユーザのＳＩＰダイアログを開放するようにしている。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、着席中、離席中又は電話中等のユーザの状態を、通信ネットワークを利用して別のユーザに公開するプレゼンスサービスを実現するプレゼンス情報配信装置及び方法に関する。
【背景技術】
【０００２】
ITU-T等で議論している次世代ネットワーク（Next Generation Network；ＮＧＮ）は、サービスがＩＰ（Internet Protocol）ネットワークを経て提供されるネットワークアーキテクチャを想定している。ＮＧＮでは、第三世代の移動通信ネットワークの標準化団体である3GPPで策定されたＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）の採用を決めている。ＩＭＳは、ＳＩＰ（Session Initiation Protocol）を用いることでサービスの実行制御、端末間のセッション制御、登録処理及び課金処理等を行うサブシステムであり、このＩＭＳを用いた種々のネットワークサービスが検討されている。
【０００３】
その一つとして、ユーザの状態を別のユーザに公開するプレゼンスサービスがある。プレゼンスサービスをＩＭＳを用いて実現する場合には、ＳＩＰ／ＳＩＭＰＬＥプロトコルを用いて以下のように行われる。すなわち、プレゼンスを要求するウォッチャ（発側）は、プレゼンスを公開するプレゼンティティ（着側）のＩＤを含むＳＩＰ信号をプレゼンスサーバへ送信する。プレゼンスサーバは各ユーザの状態をプレゼンス情報として管理しており、上記プレゼンス要求を受信すると該当するプレゼンス情報を要求元へ返送する（例えば非特許文献１を参照。）。
【０００４】
また、ＩＭＳが備えているＳＩＰアプリケーション・サーバ（ＳＩＰ Application Server：ＳＩＰ ＡＳ）を利用して、Ｗｅｂクライアントに対しＩＭＳのプレゼンス情報を配信することも検討されている（例えば非特許文献２を参照。）。この場合、ＳＩＰ ＡＳがＩＭＳのプレゼンスサービスをParlay X等のＳＯＡＰ（Simple Object Access Protocol）のＡＰＩ（Application Program Interface）を用いてＷｅｂクライアントに対し提供する。これによりＷｅｂクライアントは、例えばインターネット等のＨＴＴＰベースの通信ネットワークを介して、ＩＭＳのＳＩＰプレゼンスサービスを利用することが可能となる。
【０００５】
さらに、ＳＯＡＰよりさらに簡易なＡＰＩとしてＲＥＳＴ（Representational State Transfer）のアーキテクチャを用い、ＵＲＩ（Uniform Resource Identifier）に対しＨＴＴＰによりアクセスすることにより、ＷｅｂクライアントがＩＭＳのＳＩＰプレゼンスサービスを利用できるようにすることも検討されている（例えば非特許文献３を参照）。
【０００６】
さらに、移動体通信分野における、アプリケーションの実装標準を定めるＯＭＡ（Open Mobile Alliance）では、ＸＤＭ（XML Document Management）と呼ばれるイネーブラが検討されている。このイネーブラは、ネットワークに蓄積されたユーザ特有のサービスに関連した情報へのアクセスや操作（作成、取出し、削除及び修正）等を行う機能を提供するもので、情報はＸＭＬドキュメントで定義され管理される（例えば非特許文献４を参照。）
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】OMA Presence SIMPLE V2.0、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www.Openmobilealliance.org/Technical/release_program/Presence_simple_v2_0.aspx＞
【非特許文献２】3GPP TS 29.199-14, Open Service Access (OSA); Parlay X Web services; Part 14: Presence、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www.3Gpp.org/ftp/Specs/html-info/29199-14.htm＞
【非特許文献３】OMA ＲＥＳＴful bindings for Parlay X Ｗｅｂ Services (ParlayＲＥＳＴ) V1.0、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www.Openmobilealliance.org/Technical/release_program/Parlay REST_v1_0.aspx＞
【非特許文献４】OMA XML Document Management V2.0、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www. Openmobilealliance.org/Technical/release_program/xdm_v2_0.aspx＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、ＳＩＰ ＡＳがプレゼンス情報の配信を制御する方法として、従来では次の２つの方法が考えられている。すなわち、第１の方法は、要求元からプレゼンス要求が送られるごとにＳＩＰ ＡＳが当該プレゼンス要求をプレゼンスサーバへ単純に中継する方法である。第２の方法は、ＳＩＰ ＡＳがプレゼンス要求の履歴を要求先のユーザごとに１つのダイアログに集約し、同じユーザに対するプレゼンス要求を再度受信した場合には上記以前確立したダイアログを再利用し、前回記憶しておいたプレゼンス情報を配信する方法である。
【０００９】
しかしながら、これらの方法には次のような解決すべき課題があった。すなわち、第１の方法では同じユーザのプレゼンス要求が単純中継されるため、ＳＩＰ ＡＳとプレゼンスサーバとの間で同じ情報が何度も送受信されることになり、この結果ＩＭＳの通信トラフィックの増大を招く。第２の方法では、情報集約をするために過去の要求履歴やプレゼンス情報を蓄積するため、ＳＩＰ ＡＳに大容量のキャッシュメモリが必要となり、またＳＩＰ ＡＳのキャッシュメモリに対する検索処理の負荷が増大する。
【００１０】
この発明は上記事情に着目してなされたもので、その目的とするところは、通信トラフィックの増加を抑制し、しかもＳＩＰアプリケーション・サーバにおけるキャッシュメモリ容量の低減と検索処理負荷の軽減を図ったプレゼンス情報配信装置及び方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するためにこの発明の一観点は、ＳＩＰ（Session Initiation Protocol）を基本プロトコルとする第１のネットワークに設けられ、当該第１のネットワークを利用する複数のユーザのプレゼンス情報を管理するプレゼンスサーバとの間で通信が可能であり、かつＨＴＴＰ（Hypertext Transfer Protocol）を基本プロトコルとする第２のネットワークを介してクライアント装置及びソーシャルネットワークサービス・サーバとの間で通信が可能なＳＩＰアプリケーション・サーバからなるプレゼンス情報配信装置において、以下のような構成要素を備えたものである。
すなわち、上記クライアント装置から上記複数のユーザのうち第１のユーザに関するプレゼンス要求を受信した場合に、先ず当該第１のユーザに関するキャッシュ情報がアプリケーション・サーバ内のメモリに既に記憶されているか否かを判定する。そして、上記第１のユーザに関するキャッシュ情報が既に記憶されていると判定された場合に、上記メモリから該当するキャッシュ情報に含まれるプレゼンス情報を読み出して要求元のクライアント装置へ送信する。一方、上記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合には、上記プレゼンスサーバから当該第１のユーザのプレゼンス情報を取得し、このプレゼンス情報を上記要求元のクライアント装置へ転送する。そして、上記第１のユーザの友人関係を表す情報を上記ソーシャルネットワークサービス・サーバから取得し、この取得された友人関係を表す情報に基づいて、上記第１のユーザのプレゼンス情報をキャッシュするか否かを判定し、キャッシュすると判定された場合に上記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して上記メモリに記憶させるようにしたものである。
【００１２】
したがって、ＳＩＰアプリケーション・サーバ内にプレゼンス情報がキャッシュされていない場合にのみ、プレゼンスサーバとの間でユーザのプレゼンス情報を取得するための通信が行われる。このため、プレゼンスサーバとの間の通信トラフィックを抑制することが可能となる。また、ユーザの友人関係を表す情報がソーシャルネットワークサービス・サーバから取得され、この友人関係を表す情報に基づいてプレゼンス情報のキャッシュの可否が判定されて、キャッシュが可能な場合にのみユーザのプレゼンス情報がメモリに記憶される。すなわち、友人数が多いユーザのプレゼンス情報が予め決められた数だけ優先的に選択されてＳＩＰアプリケーション・サーバに集約されることになる。このため、常にすべてのユーザのプレゼンス情報をキャッシュする場合に比べ、キャッシュメモリの小容量化を可能とし、かつキャッシュメモリに対する検索処理の負荷を軽減することが可能となる。
【００１３】
また、この発明の一観点は以下のような態様を備えることを特徴とする。
第１の態様は、友人関係を表す情報を取得する際に、第１のユーザに関するキャッシュ情報が記憶されていないと判定された時点で、ソーシャルネットワークサービス・サーバに対し友人情報取得要求を送信し、この要求に対しソーシャルネットワークサービス・サーバから送信される第１のユーザの友人関係を表す情報を受信するものである。
このようにすると、常に最新の友人関係を表す情報が逐次取得される。このため、常に最新の情報に基づいてキャッシュ制御を実行することが可能となる。
【００１４】
第２の態様は、第１のネットワークにユーザ特有のサービスに関する情報へのアクセス及び操作を行う機能を提供するイネーブラが設けられている場合に、ソーシャルネットワークサービス・サーバに記憶された各ユーザの友人関係を表す情報をイネーブラにも記憶させ、互いに同期させた状態で管理する。そして、第１のユーザの友人関係を表す情報が必要となった場合に、該当する情報を上記イネーブラから取得するようにしたものである。
このようにすると、キャッシュ判定のために友人関係を表す情報が必要となった時点で、その都度ソーシャル・サーバとの間で第２のネットワークを介して友人関係を表す情報を取得するための通信を行う必要がなくなり、第１のネットワークで提供される他のサービス・制御機能からソーシャルネットワークサービスで管理される友人関係を表す情報を利用することができる。
【００１５】
第３の態様は、キャッシュ制御に際し、ユーザの友人数を表す情報を当該ユーザのキャッシュ情報に含めてメモリに記憶しておき、取得された第１のユーザの友人関係を表す情報から友人数を求め、この求められた第１のユーザの友人数を上記メモリに記憶されている他のユーザの友人数と比較する。そして、第１のユーザの友人数が他のユーザの友人数より多い場合に、上記メモリに記憶されている他のユーザのキャッシュ情報に代えて、上記第１のユーザのキャッシュ情報をメモリに記憶させるものである。
このようにすると、友人数同士の比較による非常に簡単な処理によりキャッシュの可否を判定することができる。
【００１６】
第４の態様は、キャッシュ制御に際し、先ずメモリに新たなキャッシュ情報を追加記憶するための容量が残っているか否かを判定し、容量が残っている場合には第１のユーザのプレゼンス情報を含むキャッシュ情報を生成してメモリに追加記憶させる。これに対し、容量が残っていない場合に、メモリに記憶されている複数のユーザのキャッシュ情報から友人数が最も少ない第２のユーザを選択し、当該選択された第２のユーザの友人数と上記第１のユーザの友人数とを比較する。そして、第１のユーザの友人数が第２のユーザの友人数以上の場合に、メモリに記憶されている第２のユーザのキャッシュ情報に代えて第１のユーザのキャッシュ情報を記憶させ、第１のユーザの友人数が第２のユーザの友人数より少ない場合には、メモリに記憶されている第２のユーザのキャッシュ情報を維持するような制御を行う。
このようにすると、メモリの残容量に余裕がある状態では友人数にかかわらずすべてのユーザのプレゼンス情報をキャッシュすることができる。そして、メモリ残容量がなくなった状態では、メモリにプレゼンス情報が記憶されている複数のユーザのうち、友人数が最も少ないユーザに代えて、それよりも友人数の多いユーザのプレゼンス情報が新規にキャッシュされる。このためメモリには、その記憶容量が許す限り友人数が多い順にユーザのプレゼンス情報をキャッシュすることができる。
【００１７】
第５の態様は、各ユーザについてのプレゼンス要求を受信するごとに、ＳＩＰアプリケーション・サーバが当該ユーザごとにプレゼンス情報に対するアクセス実績を計算する。そして、このアクセス実績の計算結果をもとに、アクセス実績の多い順に予め設定した数だけユーザのプレゼンス情報をメモリに記憶させるようにしたものである。
このようにすると、例えばソーシャルネットワークサービス・サーバからユーザの友人関係を表す情報を取得できない場合でも、記憶容量が限られたキャッシュメモリに対し、アクセス実績の高い順にユーザのプレゼンス情報をキャッシュすることができる。しかも、アクセス順位をＳＩＰアプリケーション・サーバが単独で管理することができ、これにより処理負荷を軽減できる利点がある。
【００１８】
第６の態様は、第１のネットワークに収容される複数のユーザの各々について、プレゼンスサーバが当該ユーザのプレゼンス情報に対するアクセス実績を計算し、このユーザごとのアクセス実績を表す情報を複数のＳＩＰアプリケーション・サーバとの間でそれぞれ同期管理する。そして、各ＳＩＰアプリケーション・サーバは、上記管理されたアクセス実績を表す情報に基づいて、アクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報をメモリに記憶させるように制御するものである。
したがって、この第６の態様においても、上記第５の態様と同様、ソーシャルネットワークサービス・サーバからユーザの友人関係を表す情報を取得できない場合でも、記憶容量が限られたキャッシュメモリに対し、アクセス実績の高い順にユーザのプレゼンス情報をキャッシュすることができる。また、各ユーザのアクセス順位がプレゼンスサーバにより一元管理されるので、例えば複数のＳＩＰアプリケーション・サーバがそれぞれユーザのプレゼンス情報をキャッシュ制御している場合でも、不整合を生じることなくキャッシュ制御することが可能となる。
【発明の効果】
【００１９】
すなわちこの発明によれば、通信トラフィックの増加を抑制することができ、しかもヒット率の高いキャッシュを実現可能であるため、ＳＩＰアプリケーション・サーバにおけるキャッシュメモリ容量の低減と第１のネットワークにおけるトラフィック（ＳＩＰ信号)の低減を図ったプレゼンス情報配信装置及び方法を提供することができる。
【図面の簡単な説明】
【００２０】
【図１】この発明に係わるプレゼンス情報配信装置を備えたシステムの概略構成図。
【図２】この発明の第１の実施形態に係わるプレゼンス情報配信装置の機能を備えたＳＩＰ ＡＳの構成を示すブロック図。
【図３】友人リストの管理イメージを示す図。
【図４】友人リストの構造の具体例を示す図。
【図５】図１に示したシステムにおけるプレゼンス情報配信処理の概要を示す図。
【図６】この発明の第１の実施形態に係わる友人リスト取得処理手順の概要を示す図。
【図７】図１に示したシステムにおけるプレゼンス情報配信処理の手順と処理内容を示すフローチャート。
【図８】図７に示した手順の中で、ＳＩＰ ＡＳによる処理手順と処理内容を示すフローチャート。
【図９】この発明の第２の実施形態に係わる友人リスト取得処理手順の概要を示すシーケンス図。
【図１０】この発明の第２の実施形態に係わるシステムにおけるプレゼンス情報配信処理の手順と処理内容を示すフローチャート。
【図１１】図１０に示した手順の中で、ＳＩＰ ＡＳによる処理手順と処理内容を示すフローチャート。
【図１２】この発明の第３の実施形態に係わるプレゼンス情報配信装置の機能を備えたＳＩＰ ＡＳの構成を示すブロック図。
【発明を実施するための形態】
【００２１】
以下、図面を参照してこの発明に係わる実施形態を説明する。
（第１の実施形態）
［システム全体の構成］
図１はこの発明に係わるプレゼンス情報配信装置を備えたシステムの概略構成図であり、ＮＷ２はＩＭＳ等のＳＩＰベースのネットワークを、ＮＷ１はインターネット等のＨＴＴＰベースのネットワークをそれぞれ示している。
【００２２】
ＳＩＰベースのネットワークＮＷ２には複数のユーザ端末ＭＳａ〜ＭＳｂが収容され、これらのユーザ端末ＭＳａ〜ＭＳｂのプレゼンス情報はプレゼンスサーバ（ＰＳ）３で管理されている。プレゼンス情報は、着席中、離席中又は電話中等のユーザの状態を表す情報である。
【００２３】
一方、ＨＴＴＰベースのネットワークＮＷ１には、Ｗｅｂクライアント装置ＣＴと、Twitterやソーシャルネットワークサービス（ＳＮＳ）に代表されるソーシャルネットワークサービスを提供するサーバ（ここではＳＮＳサーバと称する）４が接続されている。ＳＮＳサーバ４は、ソーシャルネットワークサービスに対し利用登録している複数のユーザの各々についてその友人関係を表す情報（友人リスト）を管理している。
【００２４】
図３はこの友人リストの管理イメージを示すもので、例えばユーザＡの本人情報として、当該ユーザＡが利用登録しているＳＮＳのユーザＩＤが管理されている。そして、これらのＳＮＳのユーザＩＤに関連付けて、そのＳＮＳにおいて友人関係にある友人情報が管理されている。図４は上記ユーザＡの友人リストの具体例を示すものである。
【００２５】
ＳＩＰベースのネットワークＮＷ２は、プレゼンス情報配信装置としての機能を有するＳＩＰアプリケーション・サーバ（ＳＩＰ ＡＳ）１を備えている。ＳＩＰアプリケーション・サーバ１は、Ｗｅｂクライアント装置ＣＴからのＳＯＡＰ／ＲＥＳＴによるプレゼンス要求に応じ、当該要求をＳＩＰ／ＳＩＭＰＬＥに変換してプレゼンスサーバ３から該当するユーザのプレゼンス情報を取得し、このプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより要求元のＷｅｂクライアントに配信する。また、このプレゼンス情報の配信処理の過程で、ＳＮＳサーバ４からＳＯＡＰ／ＲＥＳＴにより該当ユーザの友人リストを取得し、この友人リストを利用してプレゼンス情報のキャッシュ制御を行う。
【００２６】
なお、ＳＩＰベースのネットワークＮＷ２はＸＤＭ（XML Document Management）イネーブラ２を備えているが、このＸＤＭイネーブラ２の本発明に対する役割については第２の実施形態で詳しく述べる。
【００２７】
［ＳＩＰアプリケーション・サーバの構成］
図２は、ＳＩＰアプリケーション・サーバ１の構成を示すブロック図である。ＳＩＰアプリケーション・サーバ１は、制御ユニット１０と、ＨＴＴＰ信号送受信部２０と、ＳＩＰ信号送受信部３０と、キャッシュメモリ４０を備えている。ＨＴＴＰ信号送受信部２０は、ＨＴＴＰベースのネットワークＮＷ１に接続されたクライアント装置ＣＴ及びＳＮＳサーバ４との間で、ＳＯＡＰ／ＲＥＳＴのプロトコルに従い信号の送受信を行う。ＳＩＰ信号送受信部３０は、ＳＩＰベースのネットワークＮＷ２に接続されたプレゼンスサーバ３との間で、ＳＩＰ／ＳＩＭＰＬＥのプロトコルに従い信号の送受信を行う。
【００２８】
制御ユニット１０は、この発明を実施するために必要な制御機能として、プレゼンス要求受信制御部１１と、ダイアログ情報判定部１２と、プレゼンス情報取得配信制御部１３と、プレゼンス情報読出配信制御部１４と、友人情報取得制御部１５と、キャッシュ制御部１６を備えている。これらの制御機能はいずれもアプリケーション・プログラムを図示しないプロセッサ（ＣＰＵ）に実行させることにより実現される。
【００２９】
プレゼンス要求受信制御部１１は、クライアント装置ＣＴから送信されたプレゼンス要求をＨＴＴＰ信号送受信部２０を介して受信処理する。プレゼンス要求には要求対象となるユーザのＩＤが含まれている。
【００３０】
ダイアログ情報判定部１２は、上記プレゼンス要求が受信されたとき、ＳＩＰ信号送受信部３０で管理されているダイアログ情報を検索し、上記プレゼンスの取得対象となっているユーザについてＳＩＰのダイアログが確立されているか否かを判定する処理を行う。
【００３１】
プレゼンス情報取得配信制御部１３は、上記ダイアログ情報判定部１２において該当するダイアログが存在しないと判定された場合に、ＳＩＰ信号送受信部３０からプレゼンスサーバ３へＳＩＰのプレゼンス情報取得要求を送信し、これに対しプレゼンスサーバ３から返送される該当するユーザのプレゼンス情報をＳＩＰ信号送受信部３０を介して受信する。そして、この受信されたプレゼンス情報をＨＴＴＰ信号送受信部２０からＳＯＡＰ／ＲＥＳＴにより要求元のクライアント装置ＣＴへ送信する処理を行う。
【００３２】
プレゼンス情報読出配信制御部１４は、上記ダイアログ情報判定部１２において該当するダイアログが存在すると判定された場合に、キャッシュメモリ４０から該当するユーザのプレゼンス情報を読み出し、この読み出されたプレゼンス情報をＨＴＴＰ信号送受信部２０からＳＯＡＰ／ＲＥＳＴにより要求元のクライアント装置ＣＴへ送信する処理を行う。
【００３３】
友人情報取得制御部１５は、上記プレゼンス情報取得配信制御部１３によりプレゼンス情報の取得・配信処理が行われた場合に、ＨＴＴＰ信号送受信部２０からＳＮＳサーバ４に対しＳＯＡＰ／ＲＥＳＴにより対象ユーザの友人リスト取得要求を送信する。そして、これに対しＳＮＳサーバ４から返送される友人リストをＨＴＴＰ信号送受信部２０を介して受信する。
【００３４】
キャッシュ制御部１６は、以下の処理を行う。
(1) キャッシュメモリ４０に現在キャッシュされている情報量Ｍが、キャッシュメモリ４０が備えるキャッシュ可能な情報量の上限値Ｃａｐに達しているか否かを判定する処理。
【００３５】
(2) (1) において、現在キャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していないと判定された場合に、上記プレゼンス情報取得配信制御部１３によりプレゼンスサーバ３から取得されたユーザのプレゼンス情報を含むキャッシュ情報を生成し、この生成されたキャッシュ情報をキャッシュメモリ４０に記憶させる処理。
【００３６】
(3) (1) において、現在キャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していると判定された場合には、上記友人情報取得制御部１５によりＳＮＳサーバ４から取得された友人リストから対象ユーザの友人数Ｎを求める。そして、この対象ユーザの友人数を、キャッシュメモリ４０に既にキャッシュ情報が記憶されている他のユーザの友人数のうち最少の友人数Ｎmin と比較する処理。
【００３７】
(4) (3) の比較の結果、対象ユーザの友人数Ｎが最少友人数Ｎmin 以上であれば、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザのキャッシュ情報に代えて、上記対象ユーザのキャッシュ情報を生成して記憶させ、最少友人数Ｎmin のユーザに係るＳＩＰダイアログを開放させる処理。
【００３８】
(5) (3) の比較の結果、対象ユーザの友人数Ｎが最少友人数Ｎmin に満たなければ、対象ユーザのプレゼンス情報はキャッシュせず、当該対象ユーザに係るＳＩＰダイアログを開放させる処理を行う。
【００３９】
［システム全体の動作］
図５はシステム全体の動作の概要を示す図である。
プレゼンスサーバ３では、ネットワークＮＷ２に収容されるユーザ端末ＭＳａ，ＭＳｂを使用するユーザのプレゼンス情報が管理されており、このプレゼンス情報はユーザ端末ＭＳａ，ＭＳｂからのプレゼンス変更要求に応じて更新される。
【００４０】
この状態で、クライアント装置ＣＴから例えばユーザＡのプレゼンス情報の取得要求が送信されたとする。この取得要求は、ＲＥＳＴ／ＳＯＡＰにより図５中(1) に示すようにネットワークＮＷ１を介してＳＩＰアプリケーション・サーバ１に送信される。ＳＩＰアプリケーション・サーバ１は、上記プレゼンス要求を受信すると、先ずこのプレゼンスの取得対象となっているユーザＡに対応するＳＩＰダイアログが既に存在するか否かを判定する。
【００４１】
この判定の結果、該当するダイアログが存在しない場合には、図５中(2) に示すようにプレゼンスサーバ３へＳＩＰ／ＳＩＭＰＬＥによりプレゼンス情報の取得要求を送信する。これに対しプレゼンスサーバ３からユーザＡのプレゼンス情報が返送されると、ＳＩＰアプリケーション・サーバ１はユーザＡの友人数に基づきプレゼンス情報のキャッシュの可否を図５中(3) で判定した後、上記プレゼンス情報をＲＥＳＴ／ＳＯＡＰにより図５中(4) に示すように要求元のクライアント装置ＣＴへ送信する。
【００４２】
上記キャッシュの可否の判定は以下のように行われる。すなわち、ＳＩＰアプリケーション・サーバ１は、ネットワークＮＷ１を介してＳＮＳサーバ４からユーザＡの友人リストを取得する。そして、この取得した友人リストからユーザＡの友人数を調べ、このユーザＡの友人数と、キャッシュメモリ４０に既にキャッシュ情報が記憶されている他のユーザＢの友人数とを比較し、その比較結果をもとに上記ユーザＡのプレゼンス情報をキャッシュするか否かを判定する（図５中(3)）。
【００４３】
この判定の結果、ユーザＡの友人数がユーザＢの友人数以上だったとすると、キャッシュすると判断して上記ユーザＡのプレゼンス情報をキャッシュメモリ４０に記憶させる。これに対し、上記判定の結果、ユーザＡの友人数より他のユーザＢの友人数の方が多かったとすると、キャッシュしないと判断して上記ユーザＡのプレゼンス情報取得のために確立したダイアログを解放する。
【００４４】
［友人リストの取得処理］
ところで、上記友人リストの取得方法には２つの方法が考えられる。
１つはＳＩＰアプリケーション・サーバ１が友人リストを必要とするごとに逐次ＳＮＳサーバ４から取得するもので、これは第１の実施形態として説明する。他の１つはＸＤＭイネーブラ（ＸＤＭサーバ）２と連携して友人リストを事前に管理しておき、友人リストが必要となった時点で上記ＸＤＭサーバ２から読み出すもので、これは後に第２の実施形態として説明する。
【００４５】
図６は、この第１の実施形態における友人リストの逐次取得方法を説明するための図である。
同図において、ＳＩＰアプリケーション・サーバ１は、ＳＮＳサーバ４に対しネットワークＮＷ１を介してＲＥＳＴ／ＳＯＡＰにより友人リスト取得要求を送信する。これに対し、ＳＮＳサーバ４が該当するユーザＡの友人リストの情報をＲＥＳＴ／ＳＯＡＰにより返送すると、ＳＩＰアプリケーション・サーバ１は上記友人リストの情報を受信する。そして、この友人リスト情報を、友人数に応じてユーザＡのプレゼンス情報をキャッシュするか否かを判定するために、キャッシュ制御部１６に提供する。
【００４６】
［システムの詳細な動作］
図７は、システム全体のプレゼンス情報配信動作の詳細な手順を示すシーケンス図である。
ユーザＡのプレゼンス情報を取得しようとする場合に、クライアント装置ＣＴはＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）を送信する。ここで、UserA_SIPはネットワークＮＷ２で使用されるユーザＡの識別情報を、またUserA_SNSはソーシャルネットワークサービスで使用されるユーザＡの識別情報を示している。
【００４７】
ＳＩＰアプリケーション・サーバ１は、上記ＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）を受信すると、先ず当該ユーザＡ用のＳＩＰダイアログが既に確立されているか否かを判定する。この判定の結果、まだ確立されていなければ、ユーザＡ用のＳＩＰダイアログを確立した後、プレゼンスサーバ３に対しＳＩＰベースのネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＡ用のＳＩＰダイアログを確立した後、該当するユーザＡのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００４８】
ＳＩＰアプリケーション・サーバ１は、次にＳＮＳサーバ４に対し上記ユーザＡの友人リストを取得するための友人リスト要求（UserA_SNS）を送信する。これに対しＳＮＳサーバ４が、ユーザＡの友人リスト情報を返送すると、この友人リスト情報をもとに上記ユーザＡのプレゼンス情報をキャッシュするか否かを判定する。
【００４９】
このキャッシュするか否かは、上記ユーザＡの友人リスト情報からユーザＡの友人数を調べ、このユーザＡの友人数と、キャッシュ済の各ユーザのうち友人数が最少のユーザの友人数（キャッシュ済の最少友人数）とを比較する。そして、ユーザＡの友人数がキャッシュ済の最少友人数以上の場合にキャッシュすると判定し、それ以外の場合にキャッシュしないと判定する。キャッシュすると判定された場合には、上記ユーザＡのプレゼンス情報をキャッシュメモリ４０に格納する。また、それと共に上記ユーザＡ用に確立したダイアログを保持する。
また、上記キャッシュ制御後に、ＳＩＰアプリケーション・サーバ１は上記ユーザＡのプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。
【００５０】
次に、クライアント装置ＣＴから、ユーザＡのプレゼンス情報を取得するために２回目のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）が送信されたとする。この場合ＳＩＰアプリケーション・サーバ１は、取得対象のユーザＡ用のダイアログが既に確立されているため、キャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、この読み出されたプレゼンス情報を、ＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。
【００５１】
以後、クライアント装置ＣＴから、ユーザＡに関するＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）を送信されるごとに、ＳＩＰアプリケーション・サーバ１はキャッシュメモリ４０から該当するプレゼンス情報を読み出し、この読み出されたプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ配信する。
【００５２】
一方、クライアント装置ＣＴから、ユーザＢのプレゼンス情報を取得するために最初のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserB_SIP，UserB_SNS）が送信されたとする。この場合ＳＩＰアプリケーション・サーバは、ユーザＢ用のダイアログは未確立であるため、ダイアログを確立した後、プレゼンスサーバ３に対しネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＢ用のＳＩＰダイアログを確立した後、該当するユーザＢのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００５３】
続いてＳＩＰアプリケーション・サーバ１は、ＳＮＳサーバ４に対し上記ユーザＢの友人リストを取得するための友人リスト要求（UserB_SNS）を送信する。これに対しＳＮＳサーバ４が、ユーザＢの友人リスト情報を返送すると、この友人リスト情報をもとに上記ユーザＢのプレゼンス情報をキャッシュするか否かを判定する。この判定も、ユーザＢの友人リスト情報から友人Ｂの友人数を調べ、このユーザＢの友人数とキャッシュ済の最少友人数とを比較することにより行われる。この判定の結果、ユーザＢの友人数がキャッシュ済の最少友人数より少なければ、プレゼンスサーバ３に対しプレゼンス情報購読解除を要求した後、ＳＩＰアプリケーション・サーバ１におけるユーザＢ用のダイアログを解放する。そして、上記取得したユーザＢのプレゼンス情報を要求元のクライアント装置ＣＴへ送信する。
【００５４】
なお、プレゼンスサーバ３において、ユーザ端末ＭＳａからのプレゼンス情報更新登録の要求に応じてユーザＡのプレゼンス情報が更新されたとする。この場合、プレゼンスサーバ３からＳＩＰアプリケーション・サーバ１へユーザＡのプレゼンス情報の更新通知が送信される。ＳＩＰアプリケーション・サーバ１は、上記プレゼンス情報の更新通知を受信すると、キャッシュメモリ４０内の該当するユーザＡのキャッシュ情報に含まれるプレゼンス情報を上記更新通知の内容に応じて更新する。そして、このユーザＡの更新後のプレゼンス情報をキャッシュメモリ４０から読み出し、ＨＴＴＰベースのネットワークＮＷ１を介してクライアント端末ＣＴへ配信する。
【００５５】
［ＳＩＰアプリケーション・サーバによる詳細な処理動作］
図８は、ＳＩＰアプリケーション・サーバ１の詳細な処理手順と処理内容を示すフローチャートである。
クライアント装置ＣＴから送信されたプレゼンス要求（UserA_SIP，UserA_SNS）がＨＴＴＰ信号送受信部２０で受信されると、制御ユニット１０はステップＳ１１で上記プレゼンス要求の入力を受付け、ステップＳ１２においてＳＩＰ信号送受信部３０に対しUserA_SIPにより検索を行い、ユーザＡに関するダイアログが既に存在するか否かを判定する。この判定の結果、ダイアログが存在すればステップＳ１８によりキャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、ステップＳ１４により、上記読み出されたプレゼンス情報をＨＴＴＰ送受信部２０から要求元のクライアント装置ＣＴに向け送信させる。
【００５６】
これに対し、ユーザＡ用のダイアログがまだ存在しなかったとする。この場合制御ユニット１０は、先ずステップＳ１３においてプレゼンスサーバ３に対しＳＩＰ信号送受信部３０からプレゼンス情報購読要求（UserA_SIP）を送信させる。そして、プレゼンスサーバ３から返送されるユーザＡのプレゼンス情報をＳＩＰ信号送受信部３０を介して受信する。次に制御ユニット１０は、ステップＳ１５においてＳＮＳサーバ４に対しユーザＡの友人リストの取得要求（UserA_SNS）をＨＴＴＰ送受信部２０から送信させる。そして、ＳＮＳサーバ４から返送されるユーザＡの友人リスト情報をＨＴＴＰ送受信部２０を介して受信する。そして、この受信されたユーザＡの友人リスト情報からユーザＡの友人数Ｎを抽出する。
【００５７】
続いて制御ユニット１０は、ステップＳ１６において、キャッシュメモリ４０に現在キャッシュされている情報量Ｍが、キャッシュメモリ４０が備えるキャッシュ可能な情報量の上限値Ｃａｐに達しているか否かを判定する。そして、現在キャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していないと判定されると、ステップＳ１７において、上記プレゼンスサーバ３から取得されたユーザＡのプレゼンス情報を含むキャッシュ情報を生成し、この生成されたキャッシュ情報をキャッシュメモリ４０に記憶させる。
【００５８】
キャッシュ情報は、図８に例示するように、ＳＩＰベースのネットワークＮＷ２で使用されるユーザＡのＩＤ（UserA_SIP）に対し、取得したプレゼンス情報及び友人数を関連付けたものからなる。すなわち、キャッシュ情報では、ＳＩＰベースのネットワークＮＷ２で管理されるＳＩＰのユーザＡのＩＤと、ＨＴＴＰベースのネットワークＮＷ１で管理されるＳＮＳサーバ４からＲＥＳＴ／ＳＯＡＰにより取得される友人リスト情報から抽出される友人数とがまとめて管理される。
【００５９】
一方、キャッシュメモリ４０に既にキャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していたとする。この場合制御ユニット１０は、ステップＳ１９においてキャッシュメモリ４０から、友人数の最少値Ｎmin と、この友人数の最少値Ｎmin を持つユーザのＳＩＰベースのネットワークＮＷ２上におけるＩＤであるUserMin_SIP を検索する。そして、ステップＳ２０において、上記取得されたユーザＡの友人数Ｎを、上記検索された友人数の最少値Ｎmin と比較する。
【００６０】
この比較の結果、Ｎ＞Ｎmin 又はＮ＝Ｎmin だったとすると、制御ユニット１０はステップＳ２１において、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザ（UserMin_SIP ）のキャッシュ情報に代えて、上記ユーザＡのキャッシュ情報を生成して記憶させる。そして、ステップＳ２１において、上記キャッシュメモリ４０から削除した最少友人数Ｎmin のユーザ（UserMin_SIP ）に係るＳＩＰダイアログを開放させる。
これに対し、Ｎ＜Ｎmin だったとする。この場合制御ユニット１０は、ステップＳ２３においてＳＩＰ送受信部３０に対し指示を出し、上記ユーザＡのＳＩＰダイアログを解放させる。
【００６１】
以上詳述したように第１の実施形態では、クライアント装置ＣＴからプレゼンス要求が受信されたとき、該当するユーザＡのＳＩＰダイアログが確立されているか否かを判定する。そして、該当するダイアログが存在する場合にはキャッシュメモリ４０から該当するプレゼンス情報を読み出して要求元のクライアント装置ＣＴへ送信するようにしている。これに対し、該当するダイアログが存在しないと判定された場合に、プレゼンスサーバ３から当該ユーザＡのプレゼンス情報を取得して要求元のクライアント装置ＣＴへ転送すると共に、ＳＮＳサーバ４からユーザＡの友人リストを取得する。そして、取得されたユーザＡの友人リストから友人数Ｎを求め、このユーザＡの友人数Ｎを、キャッシュメモリ４０に既にキャッシュされている他の各ユーザの友人数のうち最少の友人数Ｎmin と比較し、ユーザＡの友人数Ｎが最少友人数Ｎmin 以上であれば、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザのキャッシュ情報に代えて、上記ユーザＡのキャッシュ情報を生成して記憶させ、上記最少友人数Ｎmin のユーザのＳＩＰダイアログを開放するようにしている。
【００６２】
したがって、ＳＩＰアプリケーション・サーバ１内にプレゼンス情報がキャッシュされていない場合にのみ、プレゼンスサーバ３との間でユーザのプレゼンス情報を取得するための通信が行われる。このため、ＳＩＰベースのネットワークＮＷ２における通信トラフィックを抑制することが可能となる。
【００６３】
また、ユーザＡの友人リストに基づいてプレゼンス情報をキャッシュするか否か判定されて、キャッシュ可能な場合にのみユーザのプレゼンス情報がキャッシュメモリ４０に記憶される。すなわち、友人数が多いユーザのプレゼンス情報が予め決められた数だけ優先的に選択されてＳＩＰアプリケーション・サーバ１に集約されることになる。このため、常にすべてのユーザのプレゼンス情報をキャッシュする場合に比べ、キャッシュメモリ４０の小容量化を可能とし、かつキャッシュメモリ４０に対するキャッシュヒット率が向上するため、ＳＩＰベースのネットワークＮＷ２内での高い信号数削減が可能となり、ＩＭＳを介してＳＩＰアプリケーション・サーバ１との間で交換される信号が減ることにより、ＳＩＰ信号処理に関わる負荷を軽減することが可能となる。
【００６４】
さらに第１の実施形態では、ＳＩＰアプリケーション・サーバ１が友人リストを必要とするごとに逐次ＳＮＳサーバ４から取得するようにしている。したがって、ＳＮＳサーバ４からその都度最新の友人リスト情報を取得することができ、これにより常に最新の情報に基づいてキャッシュ制御を実行することが可能となる。
【００６５】
さらに第１の実施形態では、キャッシュメモリ４０に現在キャッシュされている情報量Ｍが、キャッシュメモリ４０が備えるキャッシュ可能な情報量の上限値Ｃａｐに達しているか否かを判定し、達していないと判定された場合にはプレゼンスサーバ３から取得されたユーザＡのプレゼンス情報を無条件にキャッシュするようにしている。このため、キャッシュメモリ４０の残容量に余裕がある状態では、友人数の多少にかかわらずすべてのユーザのプレゼンス情報をキャッシュすることができる。
【００６６】
（第２の実施形態）
この発明の第２の実施形態は、ＳＩＰベースのネットワークＮＷ２にＸＤＭサーバ２が設けられている場合に、ＳＮＳサーバ４に記憶された各ユーザの友人リストをＸＤＭサーバ２においても同期管理し、ユーザの友人リストが必要となった場合に当該友人リストを上記ＸＤＭサーバ２から取得するようにしたものである。
【００６７】
図９は、この第２の実施形態における友人リストの取得方法を説明するための図である。
同図において、ＳＩＰアプリケーション・サーバ１は、定常時において、ＳＯＡＰ／ＲＥＳＴのＡＰＩを利用してＳＮＳサーバ４から各ユーザの友人リスト情報を取得し、この取得された友人リストをＸＤＭサーバ２に記憶させる。ＳＩＰアプリケーション・サーバ１は、このＸＤＭサーバ２に記憶された友人リストの内容がＳＮＳサーバ４の友人リストと常に等しくなるように、互いに連携して同期処理を行っている。
この状態で、ＳＩＰアプリケーション・サーバ１がユーザのプレゼンス情報をキャッシュするか否かを判定するために当該ユーザの友人リストが必要となると、当該友人リストをＸＤＭサーバ２から取得する。このときの取得処理はＸＣＡＰを使用して行う。
【００６８】
［システムの詳細な動作］
図１０は、システム全体のプレゼンス情報配信動作の詳細な手順を示すシーケンス図である。
定常状態においてＳＩＰアプリケーション・サーバ１は、ＳＯＡＰ／ＲＥＳＴにより友人リスト取得要求（UserA_SNS）をＳＮＳサーバ４へ送信する。これに対しＳＮＳサーバ４は、要求されたユーザＡの友人リスト情報を読み出してＳＩＰアプリケーション・サーバ１へ返送する。
【００６９】
ＳＩＰアプリケーション・サーバ１は、上記返送されたユーザＡの友人リスト情報をＸＣＡＰによりＸＤＭサーバ２へ送信し、記憶させる。このとき、ＳＩＰアプリケーション・サーバ１からＸＤＭサーバ２へは、上記友人リスト共にUserA_SNS及びUserA_SIPも送信され、これらのＩＤは友人リストと関連付けられて記憶される。以後、ＳＩＰアプリケーション・サーバ１とＸＤＭサーバ２との間では、ＳＩＰアプリケーション・サーバ１を介して、上記ユーザＡの友人リストを同期させるための処理が行われる。この同期処理は、ＳＮＳサーバ４の友人リストの内容が更新されるごとに行われる。なお、その他のユーザの友人リストについても、上記ユーザＡの友人リストと同様にＸＤＭサーバ２に記憶され同期処理される。
【００７０】
ユーザＡのプレゼンス情報を取得しようとする場合クライアント装置ＣＴは、ＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）を送信する。すなわち、ユーザＩＤとしてはUserA_SIPのみを送り、UserA_SNSは送らない。ＳＩＰアプリケーション・サーバ１は、上記ＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）を受信すると、先ず当該ユーザＡ用のＳＩＰダイアログが既に確立されているか否かを判定する。この判定の結果、まだ確立されていなければ、ユーザＡ用のＳＩＰダイアログを確立した後、プレゼンスサーバ３に対しＳＩＰベースのネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＡ用のＳＩＰダイアログを確立した後、該当するユーザＡのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００７１】
次にＳＩＰアプリケーション・サーバ１は、ＸＤＭサーバ２に対しＸＣＡＰにより上記ユーザＡの友人リストの取得要求（UserA_SIP）を送信する。これに対しＸＤＭサーバ２が、ユーザＡの友人リスト情報（UserA_SIP）を返送すると、この友人リスト情報をもとに上記ユーザＡのプレゼンス情報をキャッシュするか否かを判定する。
【００７２】
このキャッシュするか否かの判定は、第１の実施形態と同様に、上記ユーザＡの友人リスト情報からユーザＡの友人数を抽出し、このユーザＡの友人数と、キャッシュ済の各ユーザのうち友人数が最少のユーザの友人数（キャッシュ済の最少友人数）とを比較することにより行われる。
【００７３】
この比較結果をもとにキャッシュすると判定されると、上記ユーザＡのプレゼンス情報をキャッシュメモリ４０に格納する。また、それと共に上記ユーザＡ用に確立したダイアログを保持する。そして、上記キャッシュ制御後に、ＳＩＰアプリケーション・サーバ１は上記ユーザＡのプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。
【００７４】
次に、クライアント装置ＣＴから、ユーザＡのプレゼンス情報を取得するために２回目のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）が送信されたとする。この場合ＳＩＰアプリケーション・サーバ１は、取得対象のユーザＡ用のダイアログが既に確立されているため、キャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、この読み出されたプレゼンス情報を、ＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。以後、クライアント装置ＣＴから、ユーザＡに関するＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）を送信されるごとに、ＳＩＰアプリケーション・サーバ１はキャッシュメモリ４０から該当するプレゼンス情報を読み出し、この読み出されたプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ配信する。
【００７５】
一方、クライアント装置ＣＴから、ユーザＢのプレゼンス情報を取得するために最初のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserB_SIP）が送信されたとする。この場合ＳＩＰアプリケーション・サーバは、ユーザＢ用のダイアログは未確立であるため、ダイアログを確立した後、プレゼンスサーバ３に対しネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＢ用のＳＩＰダイアログを確立した後、該当するユーザＢのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００７６】
続いてＳＩＰアプリケーション・サーバ１は、ＸＤＭサーバ２に対しＸＣＡＰにより上記ユーザＢの友人リストを取得するための友人リスト要求（UserB_SNS）を送信する。これに対しＸＤＭサーバ２が、ユーザＢの友人リスト情報を返送すると、この友人リスト情報をもとに上記ユーザＢのプレゼンス情報をキャッシュするか否かを判定する。この判定も、ユーザＢの友人リスト情報から友人Ｂの友人数を調べ、このユーザＢの友人数とキャッシュ済の最少友人数とを比較することにより行われる。
【００７７】
この判定の結果、ユーザＢの友人数がキャッシュ済の最少友人数より少なければ、プレゼンスサーバ３に対しプレゼンス情報購読解除を要求した後、ＳＩＰアプリケーション・サーバ１におけるユーザＢ用のダイアログを解放する。そして、上記取得したユーザＢのプレゼンス情報を要求元のクライアント装置ＣＴへ送信する。
【００７８】
なお、プレゼンスサーバ３において、ユーザ端末ＭＳａからのプレゼンス情報更新登録の要求に応じてユーザＡのプレゼンス情報が更新されたとする。この場合、プレゼンスサーバ３からＳＩＰアプリケーション・サーバ１へユーザＡのプレゼンス情報の更新通知が送信される。ＳＩＰアプリケーション・サーバ１は、上記プレゼンス情報の更新通知を受信すると、キャッシュメモリ４０内の該当するユーザＡのキャッシュ情報に含まれるプレゼンス情報を上記更新通知の内容に応じて更新する。そして、このユーザＡの更新後のプレゼンス情報をキャッシュメモリ４０から読み出し、ＨＴＴＰベースのネットワークＮＷ１を介してクライアント端末ＣＴへ配信する。
【００７９】
［ＳＩＰアプリケーション・サーバによる詳細な処理動作］
図１１は、ＳＩＰアプリケーション・サーバ１の詳細な処理手順と処理内容を示すフローチャートである。なお、同図において前記図８と同一部分には同一符号を付して詳しい説明は省略する。
【００８０】
制御ユニット１０は、定常時においてＳＮＳサーバ４とＸＤＭサーバ２との間で友人リストを同期させる処理を実行する。すなわち、いま例えばユーザ端末ＭＳａから、ユーザＡのＳＮＳのＩＤ（UserA_SNS）の登録要求が送信されたとする。この場合ＸＤＭサーバ２は、この要求を受けてＳＩＰアプリケーション・サーバ１に対しユーザＡの友人リストの取得要求をＸＣＡＰにより送信する。
【００８１】
制御ユニット１０は、上記ユーザＡの友人リストの取得要求を受信すると、ステップＳ３１によりＳＮＳサーバ４に対し、UserA_SNSをもとに友人リストの検索要求を送信する。ＳＮＳサーバ４が該当するユーザＡの友人リスト情報を返送すると、制御ユニット１０はステップＳ３２により上記返送された友人リスト情報を成形し、この成形された友人リストをステップＳ３３によりＸＣＡＰによりＸＤＭサーバ２へ送信する。かくして、ＸＤＭサーバ２にユーザＡの友人リストが登録される。以後、このＸＤＭサーバ２に登録されたユーザＡの友人リストは、ＳＮＳサーバ４の対応する友人リスト情報が更新されるごとに、この更新処理に同期して更新される。
【００８２】
さて、この状態でクライアント装置ＣＴから送信されたプレゼンス要求（UserA_SIP）がＨＴＴＰ信号送受信部２０で受信されると、制御ユニット１０はステップＳ１２においてＳＩＰ信号送受信部３０に対しUserA_SIPにより検索を行い、ユーザＡに関するダイアログが既に存在するか否かを判定する。この判定の結果、ダイアログが存在すればステップＳ１８によりキャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、ステップＳ１４により、上記読み出されたプレゼンス情報をＨＴＴＰ送受信部２０から要求元のクライアント装置ＣＴに向け送信させる。
【００８３】
これに対し、ユーザＡ用のダイアログがまだ存在しなかったとする。この場合制御ユニット１０は、先ずステップＳ１３においてプレゼンスサーバ３に対しＳＩＰ信号送受信部３０からプレゼンス情報購読要求（UserA_SIP）を送信する。そして、プレゼンスサーバ３から返送されるユーザＡのプレゼンス情報を、ＳＩＰ信号送受信部３０を介して受信する。
【００８４】
次に制御ユニット１０は、ステップＳ３４においてＸＤＭサーバ２に対しユーザＡの友人リストの検索要求（UserA_SIP）をＸＣＡＰにより送信する。そして、ＳＮＳサーバ４から読み出されたユーザＡの友人リスト情報をＸＣＡＰにより受信する。そして、この受信されたユーザＡの友人リスト情報からユーザＡの友人数Ｎを抽出する。
続いて制御ユニット１０は、ステップＳ１６〜ステップＳ２３によりユーザＡのプレゼンス情報のキャッシュ制御を実行する。このキャッシュ制御の処理手順と処理内容は、先に第１の実施形態において述べた処理手順及び処理内容と同一である。
【００８５】
以上述べたように第２の実施形態では、ＳＩＰベースのネットワークＮＷ２に設けられたＸＤＭサーバ２を利用して、ＳＮＳサーバ４に記憶されたユーザの友人リストをＸＤＭサーバ２においても同期管理し、キヤッシュ判定のためにユーザの友人リストが必要となった場合に、当該友人リストを上記ＸＤＭサーバ２から取得するようにしている。
【００８６】
したがって、キャッシュ判定のために友人リストが必要となった時点で、その都度ＳＮＳサーバ４との間でＨＴＴＰベースのネットワークＮＷ１を介して友人リスト情報を取得するための通信を行うことなく、ＳＩＰベースのネットワークＮＷ２上で友人関係を他のサービスや制御機能に応用することができる。
【００８７】
（第３の実施形態）
この発明の第３の実施形態は、クライアント装置から各ユーザについてのプレゼンス要求を受信するごとに、ＳＩＰアプリケーション・サーバが当該ユーザごとにプレゼンス情報に対するアクセス頻度を計算する。そして、このアクセス頻度の計算結果をもとに、アクセス頻度の多い順にキャッシュメモリでキャッシュ可能な数だけユーザのプレゼンス情報をキャッシュする。
【００８８】
図１２は、この発明の第３の実施形態に係わるプレゼンス情報配信機能を有するＳＩＰアプリケーション・サーバ１′の構成を示すブロック図である。なお、同図において前記図２と同一部分には同一符号を付して詳しい説明は省略する。
【００８９】
ＳＩＰアプリケーション・サーバ１′の制御ユニット１０′は、プレゼンス要求受信制御部１１、ダイアログ情報判定部１２、プレゼンス情報取得配信制御部１３、プレゼンス情報読出配信制御部１４、友人情報取得制御部１５及びキャッシュ制御部１６に加え、アクセス頻度検出部１７と、アクセス順位変更制御部１８をさらに備えている。なお、これらのアクセス頻度検出部１７及びアクセス順位変更制御部１８についても、プログラムをプロセッサ（ＣＰＵ）に実行させることにより実現される。
【００９０】
アクセス頻度検出部１７は、プレゼンス要求受信制御部１１によりプレゼンス要求が受信されるごとに、当該プレゼンス情報に対するアクセス頻度を計算する。アクセス頻度は、過去の予め設定した期間におけるプレゼンス要求の受信回数をカウントすることにより計算される。なお、上記アクセス頻度は、プレゼンス情報取得配信制御部１３においてプレゼンスサーバ３からプレゼンス情報を取得するごとに計算するようにしてもよい。
【００９１】
アクセス順位変更制御部１８は、上記アクセス頻度検出部１７によりユーザごとに得られたアクセス頻度の計算結果をもとに、プレゼンス情報をキャッシュするときの順序を更新し、この更新後のアクセス順位情報をキャッシュ制御部１６に与える。キャッシュ制御部１６は、上記アクセス順位変更制御部１８から与えられたアクセス順位情報をもとに、アクセス頻度の多い順に予め設定した数だけユーザのプレゼンス情報をキャッシュメモリ４０にキャッシュさせる処理を行う。
【００９２】
このような構成により、クライアント装置ＣＴから送信されたユーザＡのプレゼンス情報取得要求がＲＥＳＴ／ＳＯＡＰにより受信されると、同様にアクセス頻度が計算されて、キャッシュメモリ上の当該データのアクセス頻度を更新し、ＳＩＰアプリケーション・サーバ１′は先ずこのプレゼンスの取得対象となっているユーザＡに対応するＳＩＰダイアログが既に存在するか否かを判定する。
【００９３】
この判定の結果、該当するダイアログが存在しない場合には、プレゼンスサーバ３へＳＩＰ／ＳＩＭＰＬＥによりプレゼンス情報の取得要求を送信する。これに対しプレゼンスサーバ３からユーザＡのプレゼンス情報が返送されると、当該ユーザＡに対するアクセス頻度を計算する。
【００９４】
このとき、ＳＩＰアプリケーション・サーバ１′の作業用メモリには、過去にプレゼンス要求が発生した各ユーザのアクセス頻度が保存されている。ＳＩＰアプリケーション・サーバ１′は、上記新たに計算されたユーザＡのアクセス頻度と、上記作業用メモリに記憶されている他のユーザのアクセス頻度をもとに、ユーザのアクセス順位を上記アクセス頻度の高い順に並べ替える。
【００９５】
そして、この並べ替えられたアクセス順に従い、ユーザのプレゼンス情報を上位の予め定められた数だけキャッシュメモリ４０に記憶させる。またこのとき、キャッシュメモリ４０にプレゼンス情報が記憶されたユーザについてはそのＳＩＰダイアログを維持し、キャッシュメモリ４０からプレゼンス情報が削除されたユーザに対してはそのＳＩＰダイアログを解放する。
そして、このキャッシュ制御終了後に、上記ユーザＡのプレゼンス情報をＲＥＳＴ／ＳＯＡＰにより要求元のクライアント装置ＣＴへ送信する。
【００９６】
以後同様に、ＳＩＰダイアログが確立されていないプレゼンス要求が受信されるごとに、プレゼンスサーバ３からプレゼンス情報が取得されると共に、当該ユーザに対するアクセス頻度が計算されてこのアクセス頻度が高い順に一定個数だけユーザのプレゼンス情報がキャッシュメモリ４０に記憶される。
【００９７】
一方、ＳＩＰダイアログが既に確立されている状態でプレゼンス要求が再度受信されると、ＳＩＰアプリケーション・サーバ１′は上記キャッシュメモリ４０から該当するプレゼンス情報を読み出し、この読み出されたプレゼンス情報を要求元のクライアント装置ＣＴへ送信する。
【００９８】
以上述べたように第３の実施形態によれば、クライアント装置ＣＴから各ユーザについてのプレゼンス要求を受信するごとに、ＳＩＰアプリケーション・サーバ１′が当該ユーザごとにプレゼンス情報に対するアクセス頻度を計算し、このアクセス頻度の計算結果をもとに、アクセス頻度の多い順に一定個数だけユーザのプレゼンス情報をキャッシュするようにしている。
【００９９】
したがって、例えば何らかの理由でＳＮＳサーバ４からユーザの友人リスト情報を取得できない場合でも、アクセス頻度の高い順に一定個数のユーザのプレゼンス情報をキャッシュすることができる。しかも、アクセス順位をＳＩＰアプリケーション・サーバ１′が単独で管理できる利点がある。
【０１００】
（その他の実施形態）
前記第３の実施形態では、ユーザごとのプレゼンス情報に対するアクセス頻度をＳＩＰアプリケーション・サーバ１′が単独で検出し、このアクセス頻度に応じてキャッシュ制御を行った。しかし、これに限定されるものではなく、次のような構成も考えられる。
すなわち、ＳＩＰベースのネットワークＮＷ１に収容される複数のユーザの各々について、プレゼンスサーバ３が当該ユーザのプレゼンス情報に対するアクセス頻度を計算し、このユーザごとのアクセス頻度を表す情報を複数のＳＩＰアプリケーション・サーバ１′との間でそれぞれ同期管理する。そして、各ＳＩＰアプリケーション・サーバ１′は、上記管理されたアクセス頻度を表す情報に基づいて、アクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報をキャッシュメモリ４０に記憶させるようにキャッシュ制御する。
【０１０１】
このように構成すると、上記第３の実施形態と同様に、ＳＮＳサーバ４からユーザの友人関係を表す情報を取得できない場合でも、記憶容量が限られたキャッシュメモリに対し、アクセス頻度の高い順にユーザのプレゼンス情報をキャッシュすることができる。また、各ユーザのアクセス順位がプレゼンスサーバ３により一元管理されるので、例えば複数のＳＩＰアプリケーション・サーバがそれぞれユーザのプレゼンス情報をキャッシュ制御している場合でも、不整合を生じることなくキャッシュ制御することが可能となる。
【０１０２】
また、前記第３の実施形態では、ユーザごとのアクセス実績としてアクセス頻度を計算するようにした。しかしそれに限らず、アクセス実績として任意の時点からのアクセス回数をカウントし、このアクセス回数のカウント値をもとにアクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報をキャッシュメモリ４０に記憶させるようにしてもよい。その他、アクセス実績を表す情報であれば、頻度や回数以外の如何なる情報を利用してもよい。
その他、ＳＩＰアプリケーション・サーバの構成、友人リストの構成、友人リストの取得制御手順とその内容、キャッシュ制御手順と内容、キャッシュ情報の構成、キャッシュメモリ４０に格納可能なキャッシュ情報数等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【０１０３】
要するにこの発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【０１０４】
ＣＴ…Ｗｅｂベースクライアント装置、ＭＳａ〜ＭＳｎ…ユーザ端末、ＮＷ１…ＨＴＴＰベースデータネットワーク、ＮＷ２…ＳＩＰベースネットワーク、１，１′…ＳＩＰ ＡＳ、２…ＸＤＭＳ、３…プレゼンスサーバ（ＰＳ）、４…ＳＮＳ、１０，１０′…制御ユニット、１１…プレゼンス要求受信制御部、１２…ダイアログ情報判定部、１３…プレゼンス情報取得配信制御部、１４…プレゼンス情報読出配信制御部、１５…友人関係取得制御部、１６…キャッシュ制御部、１７…アクセス頻度検出部、１８…アクセス順位変更制御部、２０…ＨＴＴＰ信号送受信部、３０…ＳＩＰ信号送受信部、４０…キャッシュメモリ。
【技術分野】
【０００１】
この発明は、着席中、離席中又は電話中等のユーザの状態を、通信ネットワークを利用して別のユーザに公開するプレゼンスサービスを実現するプレゼンス情報配信装置及び方法に関する。
【背景技術】
【０００２】
ITU-T等で議論している次世代ネットワーク（Next Generation Network；ＮＧＮ）は、サービスがＩＰ（Internet Protocol）ネットワークを経て提供されるネットワークアーキテクチャを想定している。ＮＧＮでは、第三世代の移動通信ネットワークの標準化団体である3GPPで策定されたＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）の採用を決めている。ＩＭＳは、ＳＩＰ（Session Initiation Protocol）を用いることでサービスの実行制御、端末間のセッション制御、登録処理及び課金処理等を行うサブシステムであり、このＩＭＳを用いた種々のネットワークサービスが検討されている。
【０００３】
その一つとして、ユーザの状態を別のユーザに公開するプレゼンスサービスがある。プレゼンスサービスをＩＭＳを用いて実現する場合には、ＳＩＰ／ＳＩＭＰＬＥプロトコルを用いて以下のように行われる。すなわち、プレゼンスを要求するウォッチャ（発側）は、プレゼンスを公開するプレゼンティティ（着側）のＩＤを含むＳＩＰ信号をプレゼンスサーバへ送信する。プレゼンスサーバは各ユーザの状態をプレゼンス情報として管理しており、上記プレゼンス要求を受信すると該当するプレゼンス情報を要求元へ返送する（例えば非特許文献１を参照。）。
【０００４】
また、ＩＭＳが備えているＳＩＰアプリケーション・サーバ（ＳＩＰ Application Server：ＳＩＰ ＡＳ）を利用して、Ｗｅｂクライアントに対しＩＭＳのプレゼンス情報を配信することも検討されている（例えば非特許文献２を参照。）。この場合、ＳＩＰ ＡＳがＩＭＳのプレゼンスサービスをParlay X等のＳＯＡＰ（Simple Object Access Protocol）のＡＰＩ（Application Program Interface）を用いてＷｅｂクライアントに対し提供する。これによりＷｅｂクライアントは、例えばインターネット等のＨＴＴＰベースの通信ネットワークを介して、ＩＭＳのＳＩＰプレゼンスサービスを利用することが可能となる。
【０００５】
さらに、ＳＯＡＰよりさらに簡易なＡＰＩとしてＲＥＳＴ（Representational State Transfer）のアーキテクチャを用い、ＵＲＩ（Uniform Resource Identifier）に対しＨＴＴＰによりアクセスすることにより、ＷｅｂクライアントがＩＭＳのＳＩＰプレゼンスサービスを利用できるようにすることも検討されている（例えば非特許文献３を参照）。
【０００６】
さらに、移動体通信分野における、アプリケーションの実装標準を定めるＯＭＡ（Open Mobile Alliance）では、ＸＤＭ（XML Document Management）と呼ばれるイネーブラが検討されている。このイネーブラは、ネットワークに蓄積されたユーザ特有のサービスに関連した情報へのアクセスや操作（作成、取出し、削除及び修正）等を行う機能を提供するもので、情報はＸＭＬドキュメントで定義され管理される（例えば非特許文献４を参照。）
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】OMA Presence SIMPLE V2.0、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www.Openmobilealliance.org/Technical/release_program/Presence_simple_v2_0.aspx＞
【非特許文献２】3GPP TS 29.199-14, Open Service Access (OSA); Parlay X Web services; Part 14: Presence、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www.3Gpp.org/ftp/Specs/html-info/29199-14.htm＞
【非特許文献３】OMA ＲＥＳＴful bindings for Parlay X Ｗｅｂ Services (ParlayＲＥＳＴ) V1.0、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www.Openmobilealliance.org/Technical/release_program/Parlay REST_v1_0.aspx＞
【非特許文献４】OMA XML Document Management V2.0、［平成２２年７月２０日検索］、インターネット＜URL: HTTP://www. Openmobilealliance.org/Technical/release_program/xdm_v2_0.aspx＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、ＳＩＰ ＡＳがプレゼンス情報の配信を制御する方法として、従来では次の２つの方法が考えられている。すなわち、第１の方法は、要求元からプレゼンス要求が送られるごとにＳＩＰ ＡＳが当該プレゼンス要求をプレゼンスサーバへ単純に中継する方法である。第２の方法は、ＳＩＰ ＡＳがプレゼンス要求の履歴を要求先のユーザごとに１つのダイアログに集約し、同じユーザに対するプレゼンス要求を再度受信した場合には上記以前確立したダイアログを再利用し、前回記憶しておいたプレゼンス情報を配信する方法である。
【０００９】
しかしながら、これらの方法には次のような解決すべき課題があった。すなわち、第１の方法では同じユーザのプレゼンス要求が単純中継されるため、ＳＩＰ ＡＳとプレゼンスサーバとの間で同じ情報が何度も送受信されることになり、この結果ＩＭＳの通信トラフィックの増大を招く。第２の方法では、情報集約をするために過去の要求履歴やプレゼンス情報を蓄積するため、ＳＩＰ ＡＳに大容量のキャッシュメモリが必要となり、またＳＩＰ ＡＳのキャッシュメモリに対する検索処理の負荷が増大する。
【００１０】
この発明は上記事情に着目してなされたもので、その目的とするところは、通信トラフィックの増加を抑制し、しかもＳＩＰアプリケーション・サーバにおけるキャッシュメモリ容量の低減と検索処理負荷の軽減を図ったプレゼンス情報配信装置及び方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するためにこの発明の一観点は、ＳＩＰ（Session Initiation Protocol）を基本プロトコルとする第１のネットワークに設けられ、当該第１のネットワークを利用する複数のユーザのプレゼンス情報を管理するプレゼンスサーバとの間で通信が可能であり、かつＨＴＴＰ（Hypertext Transfer Protocol）を基本プロトコルとする第２のネットワークを介してクライアント装置及びソーシャルネットワークサービス・サーバとの間で通信が可能なＳＩＰアプリケーション・サーバからなるプレゼンス情報配信装置において、以下のような構成要素を備えたものである。
すなわち、上記クライアント装置から上記複数のユーザのうち第１のユーザに関するプレゼンス要求を受信した場合に、先ず当該第１のユーザに関するキャッシュ情報がアプリケーション・サーバ内のメモリに既に記憶されているか否かを判定する。そして、上記第１のユーザに関するキャッシュ情報が既に記憶されていると判定された場合に、上記メモリから該当するキャッシュ情報に含まれるプレゼンス情報を読み出して要求元のクライアント装置へ送信する。一方、上記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合には、上記プレゼンスサーバから当該第１のユーザのプレゼンス情報を取得し、このプレゼンス情報を上記要求元のクライアント装置へ転送する。そして、上記第１のユーザの友人関係を表す情報を上記ソーシャルネットワークサービス・サーバから取得し、この取得された友人関係を表す情報に基づいて、上記第１のユーザのプレゼンス情報をキャッシュするか否かを判定し、キャッシュすると判定された場合に上記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して上記メモリに記憶させるようにしたものである。
【００１２】
したがって、ＳＩＰアプリケーション・サーバ内にプレゼンス情報がキャッシュされていない場合にのみ、プレゼンスサーバとの間でユーザのプレゼンス情報を取得するための通信が行われる。このため、プレゼンスサーバとの間の通信トラフィックを抑制することが可能となる。また、ユーザの友人関係を表す情報がソーシャルネットワークサービス・サーバから取得され、この友人関係を表す情報に基づいてプレゼンス情報のキャッシュの可否が判定されて、キャッシュが可能な場合にのみユーザのプレゼンス情報がメモリに記憶される。すなわち、友人数が多いユーザのプレゼンス情報が予め決められた数だけ優先的に選択されてＳＩＰアプリケーション・サーバに集約されることになる。このため、常にすべてのユーザのプレゼンス情報をキャッシュする場合に比べ、キャッシュメモリの小容量化を可能とし、かつキャッシュメモリに対する検索処理の負荷を軽減することが可能となる。
【００１３】
また、この発明の一観点は以下のような態様を備えることを特徴とする。
第１の態様は、友人関係を表す情報を取得する際に、第１のユーザに関するキャッシュ情報が記憶されていないと判定された時点で、ソーシャルネットワークサービス・サーバに対し友人情報取得要求を送信し、この要求に対しソーシャルネットワークサービス・サーバから送信される第１のユーザの友人関係を表す情報を受信するものである。
このようにすると、常に最新の友人関係を表す情報が逐次取得される。このため、常に最新の情報に基づいてキャッシュ制御を実行することが可能となる。
【００１４】
第２の態様は、第１のネットワークにユーザ特有のサービスに関する情報へのアクセス及び操作を行う機能を提供するイネーブラが設けられている場合に、ソーシャルネットワークサービス・サーバに記憶された各ユーザの友人関係を表す情報をイネーブラにも記憶させ、互いに同期させた状態で管理する。そして、第１のユーザの友人関係を表す情報が必要となった場合に、該当する情報を上記イネーブラから取得するようにしたものである。
このようにすると、キャッシュ判定のために友人関係を表す情報が必要となった時点で、その都度ソーシャル・サーバとの間で第２のネットワークを介して友人関係を表す情報を取得するための通信を行う必要がなくなり、第１のネットワークで提供される他のサービス・制御機能からソーシャルネットワークサービスで管理される友人関係を表す情報を利用することができる。
【００１５】
第３の態様は、キャッシュ制御に際し、ユーザの友人数を表す情報を当該ユーザのキャッシュ情報に含めてメモリに記憶しておき、取得された第１のユーザの友人関係を表す情報から友人数を求め、この求められた第１のユーザの友人数を上記メモリに記憶されている他のユーザの友人数と比較する。そして、第１のユーザの友人数が他のユーザの友人数より多い場合に、上記メモリに記憶されている他のユーザのキャッシュ情報に代えて、上記第１のユーザのキャッシュ情報をメモリに記憶させるものである。
このようにすると、友人数同士の比較による非常に簡単な処理によりキャッシュの可否を判定することができる。
【００１６】
第４の態様は、キャッシュ制御に際し、先ずメモリに新たなキャッシュ情報を追加記憶するための容量が残っているか否かを判定し、容量が残っている場合には第１のユーザのプレゼンス情報を含むキャッシュ情報を生成してメモリに追加記憶させる。これに対し、容量が残っていない場合に、メモリに記憶されている複数のユーザのキャッシュ情報から友人数が最も少ない第２のユーザを選択し、当該選択された第２のユーザの友人数と上記第１のユーザの友人数とを比較する。そして、第１のユーザの友人数が第２のユーザの友人数以上の場合に、メモリに記憶されている第２のユーザのキャッシュ情報に代えて第１のユーザのキャッシュ情報を記憶させ、第１のユーザの友人数が第２のユーザの友人数より少ない場合には、メモリに記憶されている第２のユーザのキャッシュ情報を維持するような制御を行う。
このようにすると、メモリの残容量に余裕がある状態では友人数にかかわらずすべてのユーザのプレゼンス情報をキャッシュすることができる。そして、メモリ残容量がなくなった状態では、メモリにプレゼンス情報が記憶されている複数のユーザのうち、友人数が最も少ないユーザに代えて、それよりも友人数の多いユーザのプレゼンス情報が新規にキャッシュされる。このためメモリには、その記憶容量が許す限り友人数が多い順にユーザのプレゼンス情報をキャッシュすることができる。
【００１７】
第５の態様は、各ユーザについてのプレゼンス要求を受信するごとに、ＳＩＰアプリケーション・サーバが当該ユーザごとにプレゼンス情報に対するアクセス実績を計算する。そして、このアクセス実績の計算結果をもとに、アクセス実績の多い順に予め設定した数だけユーザのプレゼンス情報をメモリに記憶させるようにしたものである。
このようにすると、例えばソーシャルネットワークサービス・サーバからユーザの友人関係を表す情報を取得できない場合でも、記憶容量が限られたキャッシュメモリに対し、アクセス実績の高い順にユーザのプレゼンス情報をキャッシュすることができる。しかも、アクセス順位をＳＩＰアプリケーション・サーバが単独で管理することができ、これにより処理負荷を軽減できる利点がある。
【００１８】
第６の態様は、第１のネットワークに収容される複数のユーザの各々について、プレゼンスサーバが当該ユーザのプレゼンス情報に対するアクセス実績を計算し、このユーザごとのアクセス実績を表す情報を複数のＳＩＰアプリケーション・サーバとの間でそれぞれ同期管理する。そして、各ＳＩＰアプリケーション・サーバは、上記管理されたアクセス実績を表す情報に基づいて、アクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報をメモリに記憶させるように制御するものである。
したがって、この第６の態様においても、上記第５の態様と同様、ソーシャルネットワークサービス・サーバからユーザの友人関係を表す情報を取得できない場合でも、記憶容量が限られたキャッシュメモリに対し、アクセス実績の高い順にユーザのプレゼンス情報をキャッシュすることができる。また、各ユーザのアクセス順位がプレゼンスサーバにより一元管理されるので、例えば複数のＳＩＰアプリケーション・サーバがそれぞれユーザのプレゼンス情報をキャッシュ制御している場合でも、不整合を生じることなくキャッシュ制御することが可能となる。
【発明の効果】
【００１９】
すなわちこの発明によれば、通信トラフィックの増加を抑制することができ、しかもヒット率の高いキャッシュを実現可能であるため、ＳＩＰアプリケーション・サーバにおけるキャッシュメモリ容量の低減と第１のネットワークにおけるトラフィック（ＳＩＰ信号)の低減を図ったプレゼンス情報配信装置及び方法を提供することができる。
【図面の簡単な説明】
【００２０】
【図１】この発明に係わるプレゼンス情報配信装置を備えたシステムの概略構成図。
【図２】この発明の第１の実施形態に係わるプレゼンス情報配信装置の機能を備えたＳＩＰ ＡＳの構成を示すブロック図。
【図３】友人リストの管理イメージを示す図。
【図４】友人リストの構造の具体例を示す図。
【図５】図１に示したシステムにおけるプレゼンス情報配信処理の概要を示す図。
【図６】この発明の第１の実施形態に係わる友人リスト取得処理手順の概要を示す図。
【図７】図１に示したシステムにおけるプレゼンス情報配信処理の手順と処理内容を示すフローチャート。
【図８】図７に示した手順の中で、ＳＩＰ ＡＳによる処理手順と処理内容を示すフローチャート。
【図９】この発明の第２の実施形態に係わる友人リスト取得処理手順の概要を示すシーケンス図。
【図１０】この発明の第２の実施形態に係わるシステムにおけるプレゼンス情報配信処理の手順と処理内容を示すフローチャート。
【図１１】図１０に示した手順の中で、ＳＩＰ ＡＳによる処理手順と処理内容を示すフローチャート。
【図１２】この発明の第３の実施形態に係わるプレゼンス情報配信装置の機能を備えたＳＩＰ ＡＳの構成を示すブロック図。
【発明を実施するための形態】
【００２１】
以下、図面を参照してこの発明に係わる実施形態を説明する。
（第１の実施形態）
［システム全体の構成］
図１はこの発明に係わるプレゼンス情報配信装置を備えたシステムの概略構成図であり、ＮＷ２はＩＭＳ等のＳＩＰベースのネットワークを、ＮＷ１はインターネット等のＨＴＴＰベースのネットワークをそれぞれ示している。
【００２２】
ＳＩＰベースのネットワークＮＷ２には複数のユーザ端末ＭＳａ〜ＭＳｂが収容され、これらのユーザ端末ＭＳａ〜ＭＳｂのプレゼンス情報はプレゼンスサーバ（ＰＳ）３で管理されている。プレゼンス情報は、着席中、離席中又は電話中等のユーザの状態を表す情報である。
【００２３】
一方、ＨＴＴＰベースのネットワークＮＷ１には、Ｗｅｂクライアント装置ＣＴと、Twitterやソーシャルネットワークサービス（ＳＮＳ）に代表されるソーシャルネットワークサービスを提供するサーバ（ここではＳＮＳサーバと称する）４が接続されている。ＳＮＳサーバ４は、ソーシャルネットワークサービスに対し利用登録している複数のユーザの各々についてその友人関係を表す情報（友人リスト）を管理している。
【００２４】
図３はこの友人リストの管理イメージを示すもので、例えばユーザＡの本人情報として、当該ユーザＡが利用登録しているＳＮＳのユーザＩＤが管理されている。そして、これらのＳＮＳのユーザＩＤに関連付けて、そのＳＮＳにおいて友人関係にある友人情報が管理されている。図４は上記ユーザＡの友人リストの具体例を示すものである。
【００２５】
ＳＩＰベースのネットワークＮＷ２は、プレゼンス情報配信装置としての機能を有するＳＩＰアプリケーション・サーバ（ＳＩＰ ＡＳ）１を備えている。ＳＩＰアプリケーション・サーバ１は、Ｗｅｂクライアント装置ＣＴからのＳＯＡＰ／ＲＥＳＴによるプレゼンス要求に応じ、当該要求をＳＩＰ／ＳＩＭＰＬＥに変換してプレゼンスサーバ３から該当するユーザのプレゼンス情報を取得し、このプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより要求元のＷｅｂクライアントに配信する。また、このプレゼンス情報の配信処理の過程で、ＳＮＳサーバ４からＳＯＡＰ／ＲＥＳＴにより該当ユーザの友人リストを取得し、この友人リストを利用してプレゼンス情報のキャッシュ制御を行う。
【００２６】
なお、ＳＩＰベースのネットワークＮＷ２はＸＤＭ（XML Document Management）イネーブラ２を備えているが、このＸＤＭイネーブラ２の本発明に対する役割については第２の実施形態で詳しく述べる。
【００２７】
［ＳＩＰアプリケーション・サーバの構成］
図２は、ＳＩＰアプリケーション・サーバ１の構成を示すブロック図である。ＳＩＰアプリケーション・サーバ１は、制御ユニット１０と、ＨＴＴＰ信号送受信部２０と、ＳＩＰ信号送受信部３０と、キャッシュメモリ４０を備えている。ＨＴＴＰ信号送受信部２０は、ＨＴＴＰベースのネットワークＮＷ１に接続されたクライアント装置ＣＴ及びＳＮＳサーバ４との間で、ＳＯＡＰ／ＲＥＳＴのプロトコルに従い信号の送受信を行う。ＳＩＰ信号送受信部３０は、ＳＩＰベースのネットワークＮＷ２に接続されたプレゼンスサーバ３との間で、ＳＩＰ／ＳＩＭＰＬＥのプロトコルに従い信号の送受信を行う。
【００２８】
制御ユニット１０は、この発明を実施するために必要な制御機能として、プレゼンス要求受信制御部１１と、ダイアログ情報判定部１２と、プレゼンス情報取得配信制御部１３と、プレゼンス情報読出配信制御部１４と、友人情報取得制御部１５と、キャッシュ制御部１６を備えている。これらの制御機能はいずれもアプリケーション・プログラムを図示しないプロセッサ（ＣＰＵ）に実行させることにより実現される。
【００２９】
プレゼンス要求受信制御部１１は、クライアント装置ＣＴから送信されたプレゼンス要求をＨＴＴＰ信号送受信部２０を介して受信処理する。プレゼンス要求には要求対象となるユーザのＩＤが含まれている。
【００３０】
ダイアログ情報判定部１２は、上記プレゼンス要求が受信されたとき、ＳＩＰ信号送受信部３０で管理されているダイアログ情報を検索し、上記プレゼンスの取得対象となっているユーザについてＳＩＰのダイアログが確立されているか否かを判定する処理を行う。
【００３１】
プレゼンス情報取得配信制御部１３は、上記ダイアログ情報判定部１２において該当するダイアログが存在しないと判定された場合に、ＳＩＰ信号送受信部３０からプレゼンスサーバ３へＳＩＰのプレゼンス情報取得要求を送信し、これに対しプレゼンスサーバ３から返送される該当するユーザのプレゼンス情報をＳＩＰ信号送受信部３０を介して受信する。そして、この受信されたプレゼンス情報をＨＴＴＰ信号送受信部２０からＳＯＡＰ／ＲＥＳＴにより要求元のクライアント装置ＣＴへ送信する処理を行う。
【００３２】
プレゼンス情報読出配信制御部１４は、上記ダイアログ情報判定部１２において該当するダイアログが存在すると判定された場合に、キャッシュメモリ４０から該当するユーザのプレゼンス情報を読み出し、この読み出されたプレゼンス情報をＨＴＴＰ信号送受信部２０からＳＯＡＰ／ＲＥＳＴにより要求元のクライアント装置ＣＴへ送信する処理を行う。
【００３３】
友人情報取得制御部１５は、上記プレゼンス情報取得配信制御部１３によりプレゼンス情報の取得・配信処理が行われた場合に、ＨＴＴＰ信号送受信部２０からＳＮＳサーバ４に対しＳＯＡＰ／ＲＥＳＴにより対象ユーザの友人リスト取得要求を送信する。そして、これに対しＳＮＳサーバ４から返送される友人リストをＨＴＴＰ信号送受信部２０を介して受信する。
【００３４】
キャッシュ制御部１６は、以下の処理を行う。
(1) キャッシュメモリ４０に現在キャッシュされている情報量Ｍが、キャッシュメモリ４０が備えるキャッシュ可能な情報量の上限値Ｃａｐに達しているか否かを判定する処理。
【００３５】
(2) (1) において、現在キャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していないと判定された場合に、上記プレゼンス情報取得配信制御部１３によりプレゼンスサーバ３から取得されたユーザのプレゼンス情報を含むキャッシュ情報を生成し、この生成されたキャッシュ情報をキャッシュメモリ４０に記憶させる処理。
【００３６】
(3) (1) において、現在キャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していると判定された場合には、上記友人情報取得制御部１５によりＳＮＳサーバ４から取得された友人リストから対象ユーザの友人数Ｎを求める。そして、この対象ユーザの友人数を、キャッシュメモリ４０に既にキャッシュ情報が記憶されている他のユーザの友人数のうち最少の友人数Ｎmin と比較する処理。
【００３７】
(4) (3) の比較の結果、対象ユーザの友人数Ｎが最少友人数Ｎmin 以上であれば、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザのキャッシュ情報に代えて、上記対象ユーザのキャッシュ情報を生成して記憶させ、最少友人数Ｎmin のユーザに係るＳＩＰダイアログを開放させる処理。
【００３８】
(5) (3) の比較の結果、対象ユーザの友人数Ｎが最少友人数Ｎmin に満たなければ、対象ユーザのプレゼンス情報はキャッシュせず、当該対象ユーザに係るＳＩＰダイアログを開放させる処理を行う。
【００３９】
［システム全体の動作］
図５はシステム全体の動作の概要を示す図である。
プレゼンスサーバ３では、ネットワークＮＷ２に収容されるユーザ端末ＭＳａ，ＭＳｂを使用するユーザのプレゼンス情報が管理されており、このプレゼンス情報はユーザ端末ＭＳａ，ＭＳｂからのプレゼンス変更要求に応じて更新される。
【００４０】
この状態で、クライアント装置ＣＴから例えばユーザＡのプレゼンス情報の取得要求が送信されたとする。この取得要求は、ＲＥＳＴ／ＳＯＡＰにより図５中(1) に示すようにネットワークＮＷ１を介してＳＩＰアプリケーション・サーバ１に送信される。ＳＩＰアプリケーション・サーバ１は、上記プレゼンス要求を受信すると、先ずこのプレゼンスの取得対象となっているユーザＡに対応するＳＩＰダイアログが既に存在するか否かを判定する。
【００４１】
この判定の結果、該当するダイアログが存在しない場合には、図５中(2) に示すようにプレゼンスサーバ３へＳＩＰ／ＳＩＭＰＬＥによりプレゼンス情報の取得要求を送信する。これに対しプレゼンスサーバ３からユーザＡのプレゼンス情報が返送されると、ＳＩＰアプリケーション・サーバ１はユーザＡの友人数に基づきプレゼンス情報のキャッシュの可否を図５中(3) で判定した後、上記プレゼンス情報をＲＥＳＴ／ＳＯＡＰにより図５中(4) に示すように要求元のクライアント装置ＣＴへ送信する。
【００４２】
上記キャッシュの可否の判定は以下のように行われる。すなわち、ＳＩＰアプリケーション・サーバ１は、ネットワークＮＷ１を介してＳＮＳサーバ４からユーザＡの友人リストを取得する。そして、この取得した友人リストからユーザＡの友人数を調べ、このユーザＡの友人数と、キャッシュメモリ４０に既にキャッシュ情報が記憶されている他のユーザＢの友人数とを比較し、その比較結果をもとに上記ユーザＡのプレゼンス情報をキャッシュするか否かを判定する（図５中(3)）。
【００４３】
この判定の結果、ユーザＡの友人数がユーザＢの友人数以上だったとすると、キャッシュすると判断して上記ユーザＡのプレゼンス情報をキャッシュメモリ４０に記憶させる。これに対し、上記判定の結果、ユーザＡの友人数より他のユーザＢの友人数の方が多かったとすると、キャッシュしないと判断して上記ユーザＡのプレゼンス情報取得のために確立したダイアログを解放する。
【００４４】
［友人リストの取得処理］
ところで、上記友人リストの取得方法には２つの方法が考えられる。
１つはＳＩＰアプリケーション・サーバ１が友人リストを必要とするごとに逐次ＳＮＳサーバ４から取得するもので、これは第１の実施形態として説明する。他の１つはＸＤＭイネーブラ（ＸＤＭサーバ）２と連携して友人リストを事前に管理しておき、友人リストが必要となった時点で上記ＸＤＭサーバ２から読み出すもので、これは後に第２の実施形態として説明する。
【００４５】
図６は、この第１の実施形態における友人リストの逐次取得方法を説明するための図である。
同図において、ＳＩＰアプリケーション・サーバ１は、ＳＮＳサーバ４に対しネットワークＮＷ１を介してＲＥＳＴ／ＳＯＡＰにより友人リスト取得要求を送信する。これに対し、ＳＮＳサーバ４が該当するユーザＡの友人リストの情報をＲＥＳＴ／ＳＯＡＰにより返送すると、ＳＩＰアプリケーション・サーバ１は上記友人リストの情報を受信する。そして、この友人リスト情報を、友人数に応じてユーザＡのプレゼンス情報をキャッシュするか否かを判定するために、キャッシュ制御部１６に提供する。
【００４６】
［システムの詳細な動作］
図７は、システム全体のプレゼンス情報配信動作の詳細な手順を示すシーケンス図である。
ユーザＡのプレゼンス情報を取得しようとする場合に、クライアント装置ＣＴはＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）を送信する。ここで、UserA_SIPはネットワークＮＷ２で使用されるユーザＡの識別情報を、またUserA_SNSはソーシャルネットワークサービスで使用されるユーザＡの識別情報を示している。
【００４７】
ＳＩＰアプリケーション・サーバ１は、上記ＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）を受信すると、先ず当該ユーザＡ用のＳＩＰダイアログが既に確立されているか否かを判定する。この判定の結果、まだ確立されていなければ、ユーザＡ用のＳＩＰダイアログを確立した後、プレゼンスサーバ３に対しＳＩＰベースのネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＡ用のＳＩＰダイアログを確立した後、該当するユーザＡのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００４８】
ＳＩＰアプリケーション・サーバ１は、次にＳＮＳサーバ４に対し上記ユーザＡの友人リストを取得するための友人リスト要求（UserA_SNS）を送信する。これに対しＳＮＳサーバ４が、ユーザＡの友人リスト情報を返送すると、この友人リスト情報をもとに上記ユーザＡのプレゼンス情報をキャッシュするか否かを判定する。
【００４９】
このキャッシュするか否かは、上記ユーザＡの友人リスト情報からユーザＡの友人数を調べ、このユーザＡの友人数と、キャッシュ済の各ユーザのうち友人数が最少のユーザの友人数（キャッシュ済の最少友人数）とを比較する。そして、ユーザＡの友人数がキャッシュ済の最少友人数以上の場合にキャッシュすると判定し、それ以外の場合にキャッシュしないと判定する。キャッシュすると判定された場合には、上記ユーザＡのプレゼンス情報をキャッシュメモリ４０に格納する。また、それと共に上記ユーザＡ用に確立したダイアログを保持する。
また、上記キャッシュ制御後に、ＳＩＰアプリケーション・サーバ１は上記ユーザＡのプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。
【００５０】
次に、クライアント装置ＣＴから、ユーザＡのプレゼンス情報を取得するために２回目のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）が送信されたとする。この場合ＳＩＰアプリケーション・サーバ１は、取得対象のユーザＡ用のダイアログが既に確立されているため、キャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、この読み出されたプレゼンス情報を、ＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。
【００５１】
以後、クライアント装置ＣＴから、ユーザＡに関するＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP，UserA_SNS）を送信されるごとに、ＳＩＰアプリケーション・サーバ１はキャッシュメモリ４０から該当するプレゼンス情報を読み出し、この読み出されたプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ配信する。
【００５２】
一方、クライアント装置ＣＴから、ユーザＢのプレゼンス情報を取得するために最初のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserB_SIP，UserB_SNS）が送信されたとする。この場合ＳＩＰアプリケーション・サーバは、ユーザＢ用のダイアログは未確立であるため、ダイアログを確立した後、プレゼンスサーバ３に対しネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＢ用のＳＩＰダイアログを確立した後、該当するユーザＢのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００５３】
続いてＳＩＰアプリケーション・サーバ１は、ＳＮＳサーバ４に対し上記ユーザＢの友人リストを取得するための友人リスト要求（UserB_SNS）を送信する。これに対しＳＮＳサーバ４が、ユーザＢの友人リスト情報を返送すると、この友人リスト情報をもとに上記ユーザＢのプレゼンス情報をキャッシュするか否かを判定する。この判定も、ユーザＢの友人リスト情報から友人Ｂの友人数を調べ、このユーザＢの友人数とキャッシュ済の最少友人数とを比較することにより行われる。この判定の結果、ユーザＢの友人数がキャッシュ済の最少友人数より少なければ、プレゼンスサーバ３に対しプレゼンス情報購読解除を要求した後、ＳＩＰアプリケーション・サーバ１におけるユーザＢ用のダイアログを解放する。そして、上記取得したユーザＢのプレゼンス情報を要求元のクライアント装置ＣＴへ送信する。
【００５４】
なお、プレゼンスサーバ３において、ユーザ端末ＭＳａからのプレゼンス情報更新登録の要求に応じてユーザＡのプレゼンス情報が更新されたとする。この場合、プレゼンスサーバ３からＳＩＰアプリケーション・サーバ１へユーザＡのプレゼンス情報の更新通知が送信される。ＳＩＰアプリケーション・サーバ１は、上記プレゼンス情報の更新通知を受信すると、キャッシュメモリ４０内の該当するユーザＡのキャッシュ情報に含まれるプレゼンス情報を上記更新通知の内容に応じて更新する。そして、このユーザＡの更新後のプレゼンス情報をキャッシュメモリ４０から読み出し、ＨＴＴＰベースのネットワークＮＷ１を介してクライアント端末ＣＴへ配信する。
【００５５】
［ＳＩＰアプリケーション・サーバによる詳細な処理動作］
図８は、ＳＩＰアプリケーション・サーバ１の詳細な処理手順と処理内容を示すフローチャートである。
クライアント装置ＣＴから送信されたプレゼンス要求（UserA_SIP，UserA_SNS）がＨＴＴＰ信号送受信部２０で受信されると、制御ユニット１０はステップＳ１１で上記プレゼンス要求の入力を受付け、ステップＳ１２においてＳＩＰ信号送受信部３０に対しUserA_SIPにより検索を行い、ユーザＡに関するダイアログが既に存在するか否かを判定する。この判定の結果、ダイアログが存在すればステップＳ１８によりキャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、ステップＳ１４により、上記読み出されたプレゼンス情報をＨＴＴＰ送受信部２０から要求元のクライアント装置ＣＴに向け送信させる。
【００５６】
これに対し、ユーザＡ用のダイアログがまだ存在しなかったとする。この場合制御ユニット１０は、先ずステップＳ１３においてプレゼンスサーバ３に対しＳＩＰ信号送受信部３０からプレゼンス情報購読要求（UserA_SIP）を送信させる。そして、プレゼンスサーバ３から返送されるユーザＡのプレゼンス情報をＳＩＰ信号送受信部３０を介して受信する。次に制御ユニット１０は、ステップＳ１５においてＳＮＳサーバ４に対しユーザＡの友人リストの取得要求（UserA_SNS）をＨＴＴＰ送受信部２０から送信させる。そして、ＳＮＳサーバ４から返送されるユーザＡの友人リスト情報をＨＴＴＰ送受信部２０を介して受信する。そして、この受信されたユーザＡの友人リスト情報からユーザＡの友人数Ｎを抽出する。
【００５７】
続いて制御ユニット１０は、ステップＳ１６において、キャッシュメモリ４０に現在キャッシュされている情報量Ｍが、キャッシュメモリ４０が備えるキャッシュ可能な情報量の上限値Ｃａｐに達しているか否かを判定する。そして、現在キャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していないと判定されると、ステップＳ１７において、上記プレゼンスサーバ３から取得されたユーザＡのプレゼンス情報を含むキャッシュ情報を生成し、この生成されたキャッシュ情報をキャッシュメモリ４０に記憶させる。
【００５８】
キャッシュ情報は、図８に例示するように、ＳＩＰベースのネットワークＮＷ２で使用されるユーザＡのＩＤ（UserA_SIP）に対し、取得したプレゼンス情報及び友人数を関連付けたものからなる。すなわち、キャッシュ情報では、ＳＩＰベースのネットワークＮＷ２で管理されるＳＩＰのユーザＡのＩＤと、ＨＴＴＰベースのネットワークＮＷ１で管理されるＳＮＳサーバ４からＲＥＳＴ／ＳＯＡＰにより取得される友人リスト情報から抽出される友人数とがまとめて管理される。
【００５９】
一方、キャッシュメモリ４０に既にキャッシュされている情報量Ｍがキャッシュ可能な情報量の上限値Ｃａｐに達していたとする。この場合制御ユニット１０は、ステップＳ１９においてキャッシュメモリ４０から、友人数の最少値Ｎmin と、この友人数の最少値Ｎmin を持つユーザのＳＩＰベースのネットワークＮＷ２上におけるＩＤであるUserMin_SIP を検索する。そして、ステップＳ２０において、上記取得されたユーザＡの友人数Ｎを、上記検索された友人数の最少値Ｎmin と比較する。
【００６０】
この比較の結果、Ｎ＞Ｎmin 又はＮ＝Ｎmin だったとすると、制御ユニット１０はステップＳ２１において、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザ（UserMin_SIP ）のキャッシュ情報に代えて、上記ユーザＡのキャッシュ情報を生成して記憶させる。そして、ステップＳ２１において、上記キャッシュメモリ４０から削除した最少友人数Ｎmin のユーザ（UserMin_SIP ）に係るＳＩＰダイアログを開放させる。
これに対し、Ｎ＜Ｎmin だったとする。この場合制御ユニット１０は、ステップＳ２３においてＳＩＰ送受信部３０に対し指示を出し、上記ユーザＡのＳＩＰダイアログを解放させる。
【００６１】
以上詳述したように第１の実施形態では、クライアント装置ＣＴからプレゼンス要求が受信されたとき、該当するユーザＡのＳＩＰダイアログが確立されているか否かを判定する。そして、該当するダイアログが存在する場合にはキャッシュメモリ４０から該当するプレゼンス情報を読み出して要求元のクライアント装置ＣＴへ送信するようにしている。これに対し、該当するダイアログが存在しないと判定された場合に、プレゼンスサーバ３から当該ユーザＡのプレゼンス情報を取得して要求元のクライアント装置ＣＴへ転送すると共に、ＳＮＳサーバ４からユーザＡの友人リストを取得する。そして、取得されたユーザＡの友人リストから友人数Ｎを求め、このユーザＡの友人数Ｎを、キャッシュメモリ４０に既にキャッシュされている他の各ユーザの友人数のうち最少の友人数Ｎmin と比較し、ユーザＡの友人数Ｎが最少友人数Ｎmin 以上であれば、キャッシュメモリ４０に記憶されている上記最少友人数Ｎmin のユーザのキャッシュ情報に代えて、上記ユーザＡのキャッシュ情報を生成して記憶させ、上記最少友人数Ｎmin のユーザのＳＩＰダイアログを開放するようにしている。
【００６２】
したがって、ＳＩＰアプリケーション・サーバ１内にプレゼンス情報がキャッシュされていない場合にのみ、プレゼンスサーバ３との間でユーザのプレゼンス情報を取得するための通信が行われる。このため、ＳＩＰベースのネットワークＮＷ２における通信トラフィックを抑制することが可能となる。
【００６３】
また、ユーザＡの友人リストに基づいてプレゼンス情報をキャッシュするか否か判定されて、キャッシュ可能な場合にのみユーザのプレゼンス情報がキャッシュメモリ４０に記憶される。すなわち、友人数が多いユーザのプレゼンス情報が予め決められた数だけ優先的に選択されてＳＩＰアプリケーション・サーバ１に集約されることになる。このため、常にすべてのユーザのプレゼンス情報をキャッシュする場合に比べ、キャッシュメモリ４０の小容量化を可能とし、かつキャッシュメモリ４０に対するキャッシュヒット率が向上するため、ＳＩＰベースのネットワークＮＷ２内での高い信号数削減が可能となり、ＩＭＳを介してＳＩＰアプリケーション・サーバ１との間で交換される信号が減ることにより、ＳＩＰ信号処理に関わる負荷を軽減することが可能となる。
【００６４】
さらに第１の実施形態では、ＳＩＰアプリケーション・サーバ１が友人リストを必要とするごとに逐次ＳＮＳサーバ４から取得するようにしている。したがって、ＳＮＳサーバ４からその都度最新の友人リスト情報を取得することができ、これにより常に最新の情報に基づいてキャッシュ制御を実行することが可能となる。
【００６５】
さらに第１の実施形態では、キャッシュメモリ４０に現在キャッシュされている情報量Ｍが、キャッシュメモリ４０が備えるキャッシュ可能な情報量の上限値Ｃａｐに達しているか否かを判定し、達していないと判定された場合にはプレゼンスサーバ３から取得されたユーザＡのプレゼンス情報を無条件にキャッシュするようにしている。このため、キャッシュメモリ４０の残容量に余裕がある状態では、友人数の多少にかかわらずすべてのユーザのプレゼンス情報をキャッシュすることができる。
【００６６】
（第２の実施形態）
この発明の第２の実施形態は、ＳＩＰベースのネットワークＮＷ２にＸＤＭサーバ２が設けられている場合に、ＳＮＳサーバ４に記憶された各ユーザの友人リストをＸＤＭサーバ２においても同期管理し、ユーザの友人リストが必要となった場合に当該友人リストを上記ＸＤＭサーバ２から取得するようにしたものである。
【００６７】
図９は、この第２の実施形態における友人リストの取得方法を説明するための図である。
同図において、ＳＩＰアプリケーション・サーバ１は、定常時において、ＳＯＡＰ／ＲＥＳＴのＡＰＩを利用してＳＮＳサーバ４から各ユーザの友人リスト情報を取得し、この取得された友人リストをＸＤＭサーバ２に記憶させる。ＳＩＰアプリケーション・サーバ１は、このＸＤＭサーバ２に記憶された友人リストの内容がＳＮＳサーバ４の友人リストと常に等しくなるように、互いに連携して同期処理を行っている。
この状態で、ＳＩＰアプリケーション・サーバ１がユーザのプレゼンス情報をキャッシュするか否かを判定するために当該ユーザの友人リストが必要となると、当該友人リストをＸＤＭサーバ２から取得する。このときの取得処理はＸＣＡＰを使用して行う。
【００６８】
［システムの詳細な動作］
図１０は、システム全体のプレゼンス情報配信動作の詳細な手順を示すシーケンス図である。
定常状態においてＳＩＰアプリケーション・サーバ１は、ＳＯＡＰ／ＲＥＳＴにより友人リスト取得要求（UserA_SNS）をＳＮＳサーバ４へ送信する。これに対しＳＮＳサーバ４は、要求されたユーザＡの友人リスト情報を読み出してＳＩＰアプリケーション・サーバ１へ返送する。
【００６９】
ＳＩＰアプリケーション・サーバ１は、上記返送されたユーザＡの友人リスト情報をＸＣＡＰによりＸＤＭサーバ２へ送信し、記憶させる。このとき、ＳＩＰアプリケーション・サーバ１からＸＤＭサーバ２へは、上記友人リスト共にUserA_SNS及びUserA_SIPも送信され、これらのＩＤは友人リストと関連付けられて記憶される。以後、ＳＩＰアプリケーション・サーバ１とＸＤＭサーバ２との間では、ＳＩＰアプリケーション・サーバ１を介して、上記ユーザＡの友人リストを同期させるための処理が行われる。この同期処理は、ＳＮＳサーバ４の友人リストの内容が更新されるごとに行われる。なお、その他のユーザの友人リストについても、上記ユーザＡの友人リストと同様にＸＤＭサーバ２に記憶され同期処理される。
【００７０】
ユーザＡのプレゼンス情報を取得しようとする場合クライアント装置ＣＴは、ＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）を送信する。すなわち、ユーザＩＤとしてはUserA_SIPのみを送り、UserA_SNSは送らない。ＳＩＰアプリケーション・サーバ１は、上記ＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）を受信すると、先ず当該ユーザＡ用のＳＩＰダイアログが既に確立されているか否かを判定する。この判定の結果、まだ確立されていなければ、ユーザＡ用のＳＩＰダイアログを確立した後、プレゼンスサーバ３に対しＳＩＰベースのネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＡ用のＳＩＰダイアログを確立した後、該当するユーザＡのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００７１】
次にＳＩＰアプリケーション・サーバ１は、ＸＤＭサーバ２に対しＸＣＡＰにより上記ユーザＡの友人リストの取得要求（UserA_SIP）を送信する。これに対しＸＤＭサーバ２が、ユーザＡの友人リスト情報（UserA_SIP）を返送すると、この友人リスト情報をもとに上記ユーザＡのプレゼンス情報をキャッシュするか否かを判定する。
【００７２】
このキャッシュするか否かの判定は、第１の実施形態と同様に、上記ユーザＡの友人リスト情報からユーザＡの友人数を抽出し、このユーザＡの友人数と、キャッシュ済の各ユーザのうち友人数が最少のユーザの友人数（キャッシュ済の最少友人数）とを比較することにより行われる。
【００７３】
この比較結果をもとにキャッシュすると判定されると、上記ユーザＡのプレゼンス情報をキャッシュメモリ４０に格納する。また、それと共に上記ユーザＡ用に確立したダイアログを保持する。そして、上記キャッシュ制御後に、ＳＩＰアプリケーション・サーバ１は上記ユーザＡのプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。
【００７４】
次に、クライアント装置ＣＴから、ユーザＡのプレゼンス情報を取得するために２回目のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）が送信されたとする。この場合ＳＩＰアプリケーション・サーバ１は、取得対象のユーザＡ用のダイアログが既に確立されているため、キャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、この読み出されたプレゼンス情報を、ＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ送信する。以後、クライアント装置ＣＴから、ユーザＡに関するＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserA_SIP）を送信されるごとに、ＳＩＰアプリケーション・サーバ１はキャッシュメモリ４０から該当するプレゼンス情報を読み出し、この読み出されたプレゼンス情報をＳＯＡＰ／ＲＥＳＴにより取得要求元のクライアント装置ＣＴへ配信する。
【００７５】
一方、クライアント装置ＣＴから、ユーザＢのプレゼンス情報を取得するために最初のＳＯＡＰ／ＲＥＳＴプレゼンス要求（UserB_SIP）が送信されたとする。この場合ＳＩＰアプリケーション・サーバは、ユーザＢ用のダイアログは未確立であるため、ダイアログを確立した後、プレゼンスサーバ３に対しネットワークＮＷ１を介してプレゼンス情報購読登録の要求を送信する。プレゼンスサーバ３は、上記プレゼンス情報購読登録の要求に応じてユーザＢ用のＳＩＰダイアログを確立した後、該当するユーザＢのプレゼンス情報を読み出して上記送信元のＳＩＰアプリケーション・サーバ１へ返送する。
【００７６】
続いてＳＩＰアプリケーション・サーバ１は、ＸＤＭサーバ２に対しＸＣＡＰにより上記ユーザＢの友人リストを取得するための友人リスト要求（UserB_SNS）を送信する。これに対しＸＤＭサーバ２が、ユーザＢの友人リスト情報を返送すると、この友人リスト情報をもとに上記ユーザＢのプレゼンス情報をキャッシュするか否かを判定する。この判定も、ユーザＢの友人リスト情報から友人Ｂの友人数を調べ、このユーザＢの友人数とキャッシュ済の最少友人数とを比較することにより行われる。
【００７７】
この判定の結果、ユーザＢの友人数がキャッシュ済の最少友人数より少なければ、プレゼンスサーバ３に対しプレゼンス情報購読解除を要求した後、ＳＩＰアプリケーション・サーバ１におけるユーザＢ用のダイアログを解放する。そして、上記取得したユーザＢのプレゼンス情報を要求元のクライアント装置ＣＴへ送信する。
【００７８】
なお、プレゼンスサーバ３において、ユーザ端末ＭＳａからのプレゼンス情報更新登録の要求に応じてユーザＡのプレゼンス情報が更新されたとする。この場合、プレゼンスサーバ３からＳＩＰアプリケーション・サーバ１へユーザＡのプレゼンス情報の更新通知が送信される。ＳＩＰアプリケーション・サーバ１は、上記プレゼンス情報の更新通知を受信すると、キャッシュメモリ４０内の該当するユーザＡのキャッシュ情報に含まれるプレゼンス情報を上記更新通知の内容に応じて更新する。そして、このユーザＡの更新後のプレゼンス情報をキャッシュメモリ４０から読み出し、ＨＴＴＰベースのネットワークＮＷ１を介してクライアント端末ＣＴへ配信する。
【００７９】
［ＳＩＰアプリケーション・サーバによる詳細な処理動作］
図１１は、ＳＩＰアプリケーション・サーバ１の詳細な処理手順と処理内容を示すフローチャートである。なお、同図において前記図８と同一部分には同一符号を付して詳しい説明は省略する。
【００８０】
制御ユニット１０は、定常時においてＳＮＳサーバ４とＸＤＭサーバ２との間で友人リストを同期させる処理を実行する。すなわち、いま例えばユーザ端末ＭＳａから、ユーザＡのＳＮＳのＩＤ（UserA_SNS）の登録要求が送信されたとする。この場合ＸＤＭサーバ２は、この要求を受けてＳＩＰアプリケーション・サーバ１に対しユーザＡの友人リストの取得要求をＸＣＡＰにより送信する。
【００８１】
制御ユニット１０は、上記ユーザＡの友人リストの取得要求を受信すると、ステップＳ３１によりＳＮＳサーバ４に対し、UserA_SNSをもとに友人リストの検索要求を送信する。ＳＮＳサーバ４が該当するユーザＡの友人リスト情報を返送すると、制御ユニット１０はステップＳ３２により上記返送された友人リスト情報を成形し、この成形された友人リストをステップＳ３３によりＸＣＡＰによりＸＤＭサーバ２へ送信する。かくして、ＸＤＭサーバ２にユーザＡの友人リストが登録される。以後、このＸＤＭサーバ２に登録されたユーザＡの友人リストは、ＳＮＳサーバ４の対応する友人リスト情報が更新されるごとに、この更新処理に同期して更新される。
【００８２】
さて、この状態でクライアント装置ＣＴから送信されたプレゼンス要求（UserA_SIP）がＨＴＴＰ信号送受信部２０で受信されると、制御ユニット１０はステップＳ１２においてＳＩＰ信号送受信部３０に対しUserA_SIPにより検索を行い、ユーザＡに関するダイアログが既に存在するか否かを判定する。この判定の結果、ダイアログが存在すればステップＳ１８によりキャッシュメモリ４０から該当するプレゼンス情報を読み出す。そして、ステップＳ１４により、上記読み出されたプレゼンス情報をＨＴＴＰ送受信部２０から要求元のクライアント装置ＣＴに向け送信させる。
【００８３】
これに対し、ユーザＡ用のダイアログがまだ存在しなかったとする。この場合制御ユニット１０は、先ずステップＳ１３においてプレゼンスサーバ３に対しＳＩＰ信号送受信部３０からプレゼンス情報購読要求（UserA_SIP）を送信する。そして、プレゼンスサーバ３から返送されるユーザＡのプレゼンス情報を、ＳＩＰ信号送受信部３０を介して受信する。
【００８４】
次に制御ユニット１０は、ステップＳ３４においてＸＤＭサーバ２に対しユーザＡの友人リストの検索要求（UserA_SIP）をＸＣＡＰにより送信する。そして、ＳＮＳサーバ４から読み出されたユーザＡの友人リスト情報をＸＣＡＰにより受信する。そして、この受信されたユーザＡの友人リスト情報からユーザＡの友人数Ｎを抽出する。
続いて制御ユニット１０は、ステップＳ１６〜ステップＳ２３によりユーザＡのプレゼンス情報のキャッシュ制御を実行する。このキャッシュ制御の処理手順と処理内容は、先に第１の実施形態において述べた処理手順及び処理内容と同一である。
【００８５】
以上述べたように第２の実施形態では、ＳＩＰベースのネットワークＮＷ２に設けられたＸＤＭサーバ２を利用して、ＳＮＳサーバ４に記憶されたユーザの友人リストをＸＤＭサーバ２においても同期管理し、キヤッシュ判定のためにユーザの友人リストが必要となった場合に、当該友人リストを上記ＸＤＭサーバ２から取得するようにしている。
【００８６】
したがって、キャッシュ判定のために友人リストが必要となった時点で、その都度ＳＮＳサーバ４との間でＨＴＴＰベースのネットワークＮＷ１を介して友人リスト情報を取得するための通信を行うことなく、ＳＩＰベースのネットワークＮＷ２上で友人関係を他のサービスや制御機能に応用することができる。
【００８７】
（第３の実施形態）
この発明の第３の実施形態は、クライアント装置から各ユーザについてのプレゼンス要求を受信するごとに、ＳＩＰアプリケーション・サーバが当該ユーザごとにプレゼンス情報に対するアクセス頻度を計算する。そして、このアクセス頻度の計算結果をもとに、アクセス頻度の多い順にキャッシュメモリでキャッシュ可能な数だけユーザのプレゼンス情報をキャッシュする。
【００８８】
図１２は、この発明の第３の実施形態に係わるプレゼンス情報配信機能を有するＳＩＰアプリケーション・サーバ１′の構成を示すブロック図である。なお、同図において前記図２と同一部分には同一符号を付して詳しい説明は省略する。
【００８９】
ＳＩＰアプリケーション・サーバ１′の制御ユニット１０′は、プレゼンス要求受信制御部１１、ダイアログ情報判定部１２、プレゼンス情報取得配信制御部１３、プレゼンス情報読出配信制御部１４、友人情報取得制御部１５及びキャッシュ制御部１６に加え、アクセス頻度検出部１７と、アクセス順位変更制御部１８をさらに備えている。なお、これらのアクセス頻度検出部１７及びアクセス順位変更制御部１８についても、プログラムをプロセッサ（ＣＰＵ）に実行させることにより実現される。
【００９０】
アクセス頻度検出部１７は、プレゼンス要求受信制御部１１によりプレゼンス要求が受信されるごとに、当該プレゼンス情報に対するアクセス頻度を計算する。アクセス頻度は、過去の予め設定した期間におけるプレゼンス要求の受信回数をカウントすることにより計算される。なお、上記アクセス頻度は、プレゼンス情報取得配信制御部１３においてプレゼンスサーバ３からプレゼンス情報を取得するごとに計算するようにしてもよい。
【００９１】
アクセス順位変更制御部１８は、上記アクセス頻度検出部１７によりユーザごとに得られたアクセス頻度の計算結果をもとに、プレゼンス情報をキャッシュするときの順序を更新し、この更新後のアクセス順位情報をキャッシュ制御部１６に与える。キャッシュ制御部１６は、上記アクセス順位変更制御部１８から与えられたアクセス順位情報をもとに、アクセス頻度の多い順に予め設定した数だけユーザのプレゼンス情報をキャッシュメモリ４０にキャッシュさせる処理を行う。
【００９２】
このような構成により、クライアント装置ＣＴから送信されたユーザＡのプレゼンス情報取得要求がＲＥＳＴ／ＳＯＡＰにより受信されると、同様にアクセス頻度が計算されて、キャッシュメモリ上の当該データのアクセス頻度を更新し、ＳＩＰアプリケーション・サーバ１′は先ずこのプレゼンスの取得対象となっているユーザＡに対応するＳＩＰダイアログが既に存在するか否かを判定する。
【００９３】
この判定の結果、該当するダイアログが存在しない場合には、プレゼンスサーバ３へＳＩＰ／ＳＩＭＰＬＥによりプレゼンス情報の取得要求を送信する。これに対しプレゼンスサーバ３からユーザＡのプレゼンス情報が返送されると、当該ユーザＡに対するアクセス頻度を計算する。
【００９４】
このとき、ＳＩＰアプリケーション・サーバ１′の作業用メモリには、過去にプレゼンス要求が発生した各ユーザのアクセス頻度が保存されている。ＳＩＰアプリケーション・サーバ１′は、上記新たに計算されたユーザＡのアクセス頻度と、上記作業用メモリに記憶されている他のユーザのアクセス頻度をもとに、ユーザのアクセス順位を上記アクセス頻度の高い順に並べ替える。
【００９５】
そして、この並べ替えられたアクセス順に従い、ユーザのプレゼンス情報を上位の予め定められた数だけキャッシュメモリ４０に記憶させる。またこのとき、キャッシュメモリ４０にプレゼンス情報が記憶されたユーザについてはそのＳＩＰダイアログを維持し、キャッシュメモリ４０からプレゼンス情報が削除されたユーザに対してはそのＳＩＰダイアログを解放する。
そして、このキャッシュ制御終了後に、上記ユーザＡのプレゼンス情報をＲＥＳＴ／ＳＯＡＰにより要求元のクライアント装置ＣＴへ送信する。
【００９６】
以後同様に、ＳＩＰダイアログが確立されていないプレゼンス要求が受信されるごとに、プレゼンスサーバ３からプレゼンス情報が取得されると共に、当該ユーザに対するアクセス頻度が計算されてこのアクセス頻度が高い順に一定個数だけユーザのプレゼンス情報がキャッシュメモリ４０に記憶される。
【００９７】
一方、ＳＩＰダイアログが既に確立されている状態でプレゼンス要求が再度受信されると、ＳＩＰアプリケーション・サーバ１′は上記キャッシュメモリ４０から該当するプレゼンス情報を読み出し、この読み出されたプレゼンス情報を要求元のクライアント装置ＣＴへ送信する。
【００９８】
以上述べたように第３の実施形態によれば、クライアント装置ＣＴから各ユーザについてのプレゼンス要求を受信するごとに、ＳＩＰアプリケーション・サーバ１′が当該ユーザごとにプレゼンス情報に対するアクセス頻度を計算し、このアクセス頻度の計算結果をもとに、アクセス頻度の多い順に一定個数だけユーザのプレゼンス情報をキャッシュするようにしている。
【００９９】
したがって、例えば何らかの理由でＳＮＳサーバ４からユーザの友人リスト情報を取得できない場合でも、アクセス頻度の高い順に一定個数のユーザのプレゼンス情報をキャッシュすることができる。しかも、アクセス順位をＳＩＰアプリケーション・サーバ１′が単独で管理できる利点がある。
【０１００】
（その他の実施形態）
前記第３の実施形態では、ユーザごとのプレゼンス情報に対するアクセス頻度をＳＩＰアプリケーション・サーバ１′が単独で検出し、このアクセス頻度に応じてキャッシュ制御を行った。しかし、これに限定されるものではなく、次のような構成も考えられる。
すなわち、ＳＩＰベースのネットワークＮＷ１に収容される複数のユーザの各々について、プレゼンスサーバ３が当該ユーザのプレゼンス情報に対するアクセス頻度を計算し、このユーザごとのアクセス頻度を表す情報を複数のＳＩＰアプリケーション・サーバ１′との間でそれぞれ同期管理する。そして、各ＳＩＰアプリケーション・サーバ１′は、上記管理されたアクセス頻度を表す情報に基づいて、アクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報をキャッシュメモリ４０に記憶させるようにキャッシュ制御する。
【０１０１】
このように構成すると、上記第３の実施形態と同様に、ＳＮＳサーバ４からユーザの友人関係を表す情報を取得できない場合でも、記憶容量が限られたキャッシュメモリに対し、アクセス頻度の高い順にユーザのプレゼンス情報をキャッシュすることができる。また、各ユーザのアクセス順位がプレゼンスサーバ３により一元管理されるので、例えば複数のＳＩＰアプリケーション・サーバがそれぞれユーザのプレゼンス情報をキャッシュ制御している場合でも、不整合を生じることなくキャッシュ制御することが可能となる。
【０１０２】
また、前記第３の実施形態では、ユーザごとのアクセス実績としてアクセス頻度を計算するようにした。しかしそれに限らず、アクセス実績として任意の時点からのアクセス回数をカウントし、このアクセス回数のカウント値をもとにアクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報をキャッシュメモリ４０に記憶させるようにしてもよい。その他、アクセス実績を表す情報であれば、頻度や回数以外の如何なる情報を利用してもよい。
その他、ＳＩＰアプリケーション・サーバの構成、友人リストの構成、友人リストの取得制御手順とその内容、キャッシュ制御手順と内容、キャッシュ情報の構成、キャッシュメモリ４０に格納可能なキャッシュ情報数等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【０１０３】
要するにこの発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【０１０４】
ＣＴ…Ｗｅｂベースクライアント装置、ＭＳａ〜ＭＳｎ…ユーザ端末、ＮＷ１…ＨＴＴＰベースデータネットワーク、ＮＷ２…ＳＩＰベースネットワーク、１，１′…ＳＩＰ ＡＳ、２…ＸＤＭＳ、３…プレゼンスサーバ（ＰＳ）、４…ＳＮＳ、１０，１０′…制御ユニット、１１…プレゼンス要求受信制御部、１２…ダイアログ情報判定部、１３…プレゼンス情報取得配信制御部、１４…プレゼンス情報読出配信制御部、１５…友人関係取得制御部、１６…キャッシュ制御部、１７…アクセス頻度検出部、１８…アクセス順位変更制御部、２０…ＨＴＴＰ信号送受信部、３０…ＳＩＰ信号送受信部、４０…キャッシュメモリ。
【特許請求の範囲】
【請求項１】
ＳＩＰ（Session Initiation Protocol）を基本プロトコルとする第１のネットワークに設けられ、当該第１のネットワークを利用する複数のユーザのプレゼンス情報を管理するプレゼンスサーバとの間で通信が可能であり、かつＨＴＴＰ（Hypertext Transfer Protocol）を基本プロトコルとする第２のネットワークを介してクライアント装置及びソーシャルネットワークサービス・サーバとの間で通信が可能なＳＩＰアプリケーション・サーバからなるプレゼンス情報配信装置において、
前記クライアント装置から前記複数のユーザのうち第１のユーザに関するプレゼンス要求を受信した場合に、当該第１のユーザに関するキャッシュ情報がアプリケーション・サーバ内のメモリに既に記憶されているか否かを判定する手段と、
前記第１のユーザに関するキャッシュ情報が既に記憶されていると判定された場合に、前記メモリから該当するキャッシュ情報に含まれるプレゼンス情報を読み出して要求元のクライアント装置へ送信する手段と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、前記プレゼンスサーバから当該第１のユーザのプレゼンス情報を取得し、このプレゼンス情報を前記要求元のクライアント装置へ転送する手段と、
前記第１のユーザの友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得する友人情報取得手段と、
前記取得された友人関係を表す情報に基づいて、前記第１のユーザのプレゼンス情報をキャッシュするか否かを判定し、キャッシュすると判定された場合に前記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して前記メモリに記憶させるキャッシュ制御手段と
を具備することを特徴とするプレゼンス情報配信装置。
【請求項２】
前記友人情報取得手段は、前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された時点で、前記ソーシャルネットワークサービス・サーバに対し友人情報取得要求を送信し、この要求に対しソーシャルネットワークサービス・サーバから送信される第１のユーザの友人関係を表す情報を受信することを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項３】
前記友人情報取得手段は、
前記第１のネットワークに、ユーザ特有のサービスに関する情報へのアクセス及び操作を行う機能を提供するイネーブラが設けられている場合に、定常状態において、前記複数のユーザの各々についてその友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得して前記イネーブラに蓄積し、以後当該友人関係を表す情報を前記ソーシャルネットワークサービス・サーバに記憶された情報と同期させる手段と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、当該第１のユーザの友人関係を表す情報を前記イネーブラから取得する手段と
を備えることを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項４】
前記キャッシュ制御手段は、
ユーザの友人数を表す情報を当該ユーザのキャッシュ情報に含めて前記メモリに記憶する手段と、
前記取得された第１のユーザの友人関係を表す情報から友人数を求め、この求められた第１のユーザの友人数を前記メモリに記憶されている他のユーザのキャッシュ情報に含まれる友人数と比較する手段と、
前記第１のユーザの友人数が他のユーザの友人数より多い場合に、前記メモリに記憶されている他のユーザのキャッシュ情報に代えて、前記第１のユーザのキャッシュ情報をメモリに記憶させる手段と
を備えることを特徴とする請求項１乃至３のいずれかに記載のプレゼンス情報配信装置。
【請求項５】
前記キャッシュ制御手段は、
前記メモリに新たなキャッシュ情報を追加記憶するための容量が残っているか否かを判定する手段と、
前記判定の結果容量が残っている場合には、前記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して前記メモリに追加記憶させる手段と、
前記判定の結果容量が残っていない場合に、前記メモリに記憶されている複数のユーザのキャッシュ情報から友人数が最も少ない第２のユーザを選択し、当該選択された第２のユーザの友人数と前記第１のユーザの友人数とを比較する手段と、
前記第１のユーザの友人数が第２のユーザの友人数以上の場合に、前記メモリに記憶されている第２のユーザのキャッシュ情報に代えて前記第１のユーザのキャッシュ情報をメモリに記憶させ、前記第１のユーザの友人数が第２のユーザの友人数より少ない場合には、前記メモリに記憶されている第２のユーザのキャッシュ情報を維持するように制御する手段と
を備えることを特徴とする請求項１乃至３のいずれかに記載のプレゼンス情報配信装置。
【請求項６】
複数のユーザについてのプレゼンス要求を受信するごとに、当該ユーザごとにプレゼンス情報に対するアクセス実績を計算する手段と、
前記アクセス実績の計算結果をもとに各ユーザのアクセス順位情報を生成し、このアクセス順位情報に応じてアクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報を前記メモリに記憶させるキャッシュ更新手段と
を、さらに備えることを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項７】
前記第１のネットワークに収容された複数のユーザの各々について、当該ユーザのプレゼンス情報に対するアクセス実績を反映した各ユーザに対するアクセス順位を表す情報を生成し、このアクセス順位情報を前記プレゼンスサーバとの間で同期して管理する手段と、
前記アクセス順位情報に応じて、アクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報を前記メモリに記憶させるように更新制御する手段と
を、さらに備えることを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項８】
ＳＩＰ（Session Initiation Protocol）を基本プロトコルとする第１のネットワークに設けられ、当該第１のネットワークを利用する複数のユーザのプレゼンス情報を管理するプレゼンスサーバとの間で通信が可能であり、かつＨＴＴＰ（Hypertext Transfer Protocol）を基本プロトコルとする第２のネットワークを介してクライアント装置及びソーシャルネットワークサービス・サーバとの間で通信が可能なＳＩＰアプリケーション・サーバにより実行されるプレゼンス情報配信方法であって、
前記クライアント装置から前記複数のユーザのうち第１のユーザに関するプレゼンス要求を受信した場合に、当該第１のユーザに関するキャッシュ情報がアプリケーション・サーバ内のメモリに既に記憶されているか否かを判定する過程と、
前記第１のユーザに関するキャッシュ情報が既に記憶されていると判定された場合に、前記メモリから該当するキャッシュ情報に含まれるプレゼンス情報を読み出して要求元のクライアント装置へ送信する過程と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、前記プレゼンスサーバから当該第１のユーザのプレゼンス情報を取得し、このプレゼンス情報を前記要求元のクライアント装置へ転送する過程と、
前記第１のユーザの友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得する過程と、
前記取得された友人関係を表す情報に基づいて、前記第１のユーザのプレゼンス情報をキャッシュするか否かを判定し、キャッシュすると判定された場合に前記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して前記メモリに記憶させる過程と
を具備することを特徴とするプレゼンス情報配信方法。
【請求項９】
前記友人関係を表す情報を取得する過程は、前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された時点で、前記ソーシャルネットワークサービス・サーバに対し友人情報取得要求を送信し、この要求に対しソーシャルネットワークサービス・サーバから送信される第１のユーザの友人関係を表す情報を受信することを特徴とする請求項８記載のプレゼンス情報配信方法。
【請求項１０】
前記友人関係を表す情報を取得する過程は、
前記第１のネットワークに、ユーザ特有のサービスに関する情報へのアクセス及び操作を行う機能を提供するイネーブラが設けられている場合に、定常状態において、前記複数のユーザの各々についてその友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得して前記イネーブラに蓄積し、以後当該友人関係を表す情報を前記ソーシャルネットワークサービス・サーバに記憶された情報と同期させる過程と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、当該第１のユーザの友人関係を表す情報を前記イネーブラから取得する過程と
を備えることを特徴とする請求項８記載のプレゼンス情報配信方法。
【請求項１】
ＳＩＰ（Session Initiation Protocol）を基本プロトコルとする第１のネットワークに設けられ、当該第１のネットワークを利用する複数のユーザのプレゼンス情報を管理するプレゼンスサーバとの間で通信が可能であり、かつＨＴＴＰ（Hypertext Transfer Protocol）を基本プロトコルとする第２のネットワークを介してクライアント装置及びソーシャルネットワークサービス・サーバとの間で通信が可能なＳＩＰアプリケーション・サーバからなるプレゼンス情報配信装置において、
前記クライアント装置から前記複数のユーザのうち第１のユーザに関するプレゼンス要求を受信した場合に、当該第１のユーザに関するキャッシュ情報がアプリケーション・サーバ内のメモリに既に記憶されているか否かを判定する手段と、
前記第１のユーザに関するキャッシュ情報が既に記憶されていると判定された場合に、前記メモリから該当するキャッシュ情報に含まれるプレゼンス情報を読み出して要求元のクライアント装置へ送信する手段と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、前記プレゼンスサーバから当該第１のユーザのプレゼンス情報を取得し、このプレゼンス情報を前記要求元のクライアント装置へ転送する手段と、
前記第１のユーザの友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得する友人情報取得手段と、
前記取得された友人関係を表す情報に基づいて、前記第１のユーザのプレゼンス情報をキャッシュするか否かを判定し、キャッシュすると判定された場合に前記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して前記メモリに記憶させるキャッシュ制御手段と
を具備することを特徴とするプレゼンス情報配信装置。
【請求項２】
前記友人情報取得手段は、前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された時点で、前記ソーシャルネットワークサービス・サーバに対し友人情報取得要求を送信し、この要求に対しソーシャルネットワークサービス・サーバから送信される第１のユーザの友人関係を表す情報を受信することを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項３】
前記友人情報取得手段は、
前記第１のネットワークに、ユーザ特有のサービスに関する情報へのアクセス及び操作を行う機能を提供するイネーブラが設けられている場合に、定常状態において、前記複数のユーザの各々についてその友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得して前記イネーブラに蓄積し、以後当該友人関係を表す情報を前記ソーシャルネットワークサービス・サーバに記憶された情報と同期させる手段と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、当該第１のユーザの友人関係を表す情報を前記イネーブラから取得する手段と
を備えることを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項４】
前記キャッシュ制御手段は、
ユーザの友人数を表す情報を当該ユーザのキャッシュ情報に含めて前記メモリに記憶する手段と、
前記取得された第１のユーザの友人関係を表す情報から友人数を求め、この求められた第１のユーザの友人数を前記メモリに記憶されている他のユーザのキャッシュ情報に含まれる友人数と比較する手段と、
前記第１のユーザの友人数が他のユーザの友人数より多い場合に、前記メモリに記憶されている他のユーザのキャッシュ情報に代えて、前記第１のユーザのキャッシュ情報をメモリに記憶させる手段と
を備えることを特徴とする請求項１乃至３のいずれかに記載のプレゼンス情報配信装置。
【請求項５】
前記キャッシュ制御手段は、
前記メモリに新たなキャッシュ情報を追加記憶するための容量が残っているか否かを判定する手段と、
前記判定の結果容量が残っている場合には、前記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して前記メモリに追加記憶させる手段と、
前記判定の結果容量が残っていない場合に、前記メモリに記憶されている複数のユーザのキャッシュ情報から友人数が最も少ない第２のユーザを選択し、当該選択された第２のユーザの友人数と前記第１のユーザの友人数とを比較する手段と、
前記第１のユーザの友人数が第２のユーザの友人数以上の場合に、前記メモリに記憶されている第２のユーザのキャッシュ情報に代えて前記第１のユーザのキャッシュ情報をメモリに記憶させ、前記第１のユーザの友人数が第２のユーザの友人数より少ない場合には、前記メモリに記憶されている第２のユーザのキャッシュ情報を維持するように制御する手段と
を備えることを特徴とする請求項１乃至３のいずれかに記載のプレゼンス情報配信装置。
【請求項６】
複数のユーザについてのプレゼンス要求を受信するごとに、当該ユーザごとにプレゼンス情報に対するアクセス実績を計算する手段と、
前記アクセス実績の計算結果をもとに各ユーザのアクセス順位情報を生成し、このアクセス順位情報に応じてアクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報を前記メモリに記憶させるキャッシュ更新手段と
を、さらに備えることを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項７】
前記第１のネットワークに収容された複数のユーザの各々について、当該ユーザのプレゼンス情報に対するアクセス実績を反映した各ユーザに対するアクセス順位を表す情報を生成し、このアクセス順位情報を前記プレゼンスサーバとの間で同期して管理する手段と、
前記アクセス順位情報に応じて、アクセス順位が高いものから予め設定された数だけユーザのキャッシュ情報を前記メモリに記憶させるように更新制御する手段と
を、さらに備えることを特徴とする請求項１記載のプレゼンス情報配信装置。
【請求項８】
ＳＩＰ（Session Initiation Protocol）を基本プロトコルとする第１のネットワークに設けられ、当該第１のネットワークを利用する複数のユーザのプレゼンス情報を管理するプレゼンスサーバとの間で通信が可能であり、かつＨＴＴＰ（Hypertext Transfer Protocol）を基本プロトコルとする第２のネットワークを介してクライアント装置及びソーシャルネットワークサービス・サーバとの間で通信が可能なＳＩＰアプリケーション・サーバにより実行されるプレゼンス情報配信方法であって、
前記クライアント装置から前記複数のユーザのうち第１のユーザに関するプレゼンス要求を受信した場合に、当該第１のユーザに関するキャッシュ情報がアプリケーション・サーバ内のメモリに既に記憶されているか否かを判定する過程と、
前記第１のユーザに関するキャッシュ情報が既に記憶されていると判定された場合に、前記メモリから該当するキャッシュ情報に含まれるプレゼンス情報を読み出して要求元のクライアント装置へ送信する過程と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、前記プレゼンスサーバから当該第１のユーザのプレゼンス情報を取得し、このプレゼンス情報を前記要求元のクライアント装置へ転送する過程と、
前記第１のユーザの友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得する過程と、
前記取得された友人関係を表す情報に基づいて、前記第１のユーザのプレゼンス情報をキャッシュするか否かを判定し、キャッシュすると判定された場合に前記第１のユーザのプレゼンス情報を含むキャッシュ情報を生成して前記メモリに記憶させる過程と
を具備することを特徴とするプレゼンス情報配信方法。
【請求項９】
前記友人関係を表す情報を取得する過程は、前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された時点で、前記ソーシャルネットワークサービス・サーバに対し友人情報取得要求を送信し、この要求に対しソーシャルネットワークサービス・サーバから送信される第１のユーザの友人関係を表す情報を受信することを特徴とする請求項８記載のプレゼンス情報配信方法。
【請求項１０】
前記友人関係を表す情報を取得する過程は、
前記第１のネットワークに、ユーザ特有のサービスに関する情報へのアクセス及び操作を行う機能を提供するイネーブラが設けられている場合に、定常状態において、前記複数のユーザの各々についてその友人関係を表す情報を前記ソーシャルネットワークサービス・サーバから取得して前記イネーブラに蓄積し、以後当該友人関係を表す情報を前記ソーシャルネットワークサービス・サーバに記憶された情報と同期させる過程と、
前記第１のユーザに関するキャッシュ情報が記憶されていないと判定された場合に、当該第１のユーザの友人関係を表す情報を前記イネーブラから取得する過程と
を備えることを特徴とする請求項８記載のプレゼンス情報配信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−４４４２７（Ｐ２０１２−４４４２７Ａ）
【公開日】平成２４年３月１日（２０１２．３．１）
【国際特許分類】
【出願番号】特願２０１０−１８３４７７（Ｐ２０１０−１８３４７７）
【出願日】平成２２年８月１８日（２０１０．８．１８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年３月１日（２０１２．３．１）
【国際特許分類】
【出願日】平成２２年８月１８日（２０１０．８．１８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]