JP2011008695A - サービス提供システムおよびサービス提供方法 - Google Patents

Abstract

【課題】通信相手との関係が一時的な場合に、このような一時的な通信関係に基づいてサービスを制御することを課題とする。
【解決手段】セッション管理サーバは、ＳＩＰフォンにて通話中の利用者が利用する情報表示端末から、サービスに関連するデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末が、ＳＩＰによって通信を確立したＳＩＰフォンと組で利用される情報表示端末であるか否かを判定する。そして、セッション管理サーバは、ＳＩＰによって通信を確立したＳＩＰフォンと組で利用される端末であると判定すると、受け渡し要求に従ってデータの受け渡しを制御する。
【選択図】 図２

Description

本発明は、サービス提供システムおよびサービス提供方法に関する。

従来、ＩＰ（Internet Protocol）で制御されるネットワークに接続する端末に提供されるサービスとして、いわゆるＷｅｂサービスがある。ここで、Ｗｅｂサービスとは、一般に、ＷＷＷ（World Wide Web）関連技術を適用することで、アプリケーションの機能をネットワーク経由で実現するサービスのことをいう。例えば、インターネットに接続する端末は、Ｗｅｂサービスの一つであるＩＭ（Instant Messaging）サービスの提供を受け、インターネットに接続する他の端末との間で、チャットや画像データの共有を実現する。

また、例えば特許文献１には、会員（コミュニティ）管理を一元化することで、新しいサービスを利用する際の会員登録を不要とする技術が開示されている。また、例えば特許文献２には、一般的なブラウザを用いてアプリケーション共有を行う技術が開示されている。

特開２００５−２２８１２２号公報 特開２００３−０４４４２９号公報

ところで、上記した従来の技術では、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することができないという課題があった。

そこで、本発明は、上記した従来の技術の課題を解決するためになされたものであり、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することが可能なサービス提供システムおよびサービス提供方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供システムであって、前記サービス提供装置は、前記サービスを利用することを要求する利用要求を前記複数の端末の内のいずれか一つの端末から受け付けた際に、当該端末と組で利用され第１の通信を確立する第１通信端末と、他の第１通信端末との間で確立された第１の通信を一意に識別する第１通信情報を取得する第１通信情報取得手段と、前記利用要求を送信した前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手段によって取得された第１通信情報に対応づけて第２通信情報記憶手段に格納する第２通信情報格納手段と、前記第２通信情報記憶手段に格納されている複数の第１通信情報の内、いずれか二つの第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶手段に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御手段と、前記サービス提供制御手段によってサービスが提供される複数の端末の内のいずれか一つの端末から前記複数の端末のいずれとも異なる他の端末への接続要求を受信した場合に、当該接続要求を送信した端末と組で利用される第１通信端末が利用する第１通信情報を用いて、前記サービス提供される複数の端末各々と組で利用される第１通信端末各々と、前記他の端末と組で利用される他の第１通信端末とを接続する通信接続手段と、前記通信接続手段によって第１通信端末各々が接続されると、前記第１通信端末各々が利用する第１通信情報に対応付けて前記第２通信情報記憶手段に記憶される第２通信情報を、前記他の通信端末と組で利用される前記接続要求先の他の端末に対して割り与える第２通信情報割り与え手段と、を備えたことを特徴とする。

通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することが可能になる。

図１は、実施例１に係るサービス提供システムの全体構成を示す図である。 図２は、セッション管理サーバの構成を示すブロック図である。 図３は、ユーザ契約サービス管理テーブルに記憶される情報の例を示す図である。 図４は、契約サービス情報テーブルに記憶される情報の例を示す図である。 図５は、制御用セッション管理テーブルに記憶される情報の例を示す図である。 図６は、発着間紐付けＩＤテーブルに記憶される情報の例を示す図である。 図７は、会議室サービステーブルに記憶される情報の例を示す図である。 図８は、会議室対応管理テーブルに記憶される情報の例を示す図である。 図９は、データテーブルに記憶される情報の例を示す図である。 図１０は、サービス提供サーバの構成を示すブロック図である。 図１１は、Ｗｅｂセッション情報管理テーブルに記憶される情報の例を示す図である。 図１２は、データテーブルに記憶される情報の例を示す図である。 図１３は、ＨＧＷの構成を示すブロック図である。 図１４は、ブラウザセッション情報管理テーブルに記憶される情報の例を示す図である。 図１５は、会議室サーバの構成を示すブロック図である。 図１６は、会議室管理テーブルに記憶される情報の例を示す図である。 図１７は、会議用セッション情報管理テーブルに記憶される情報の例を示す図である。 図１８は、ＳＩＰフォンの構成を示すブロック図である。 図１９は、情報表示端末の構成を示すブロック図である。 図２０は、実施例１に係るサービス提供システムによる処理の流れをシーケンス図（その１）である。 図２１は、実施例１に係るサービス提供システムによる処理の流れをシーケンス図（その２）である。 図２２は、実施例１に係るサービス提供システムによる処理の流れをシーケンス図（その３）である。 図２３は、実施例１に係るサービス提供システムによる処理の流れをシーケンス図（その４）である。 図２４は、実施例１に係るサービス提供システムによる処理の流れをシーケンス図（その５）である。 図２５は、実施例２に係るサービス提供システムによる処理の流れをシーケンス図である。

以下に添付図面を参照して、本発明に係るサービス提供システムおよびサービス提供方法の実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語、実施例１に係るサービス提供システムの概要、実施例１に係るサービス提供システムの構成、実施例１に係るサービス提供システムによる処理の手順、実施例１の効果を順に説明し、続いて、他の実施例について説明する。

［用語の説明］
最初に、以下の実施例で用いる主要な用語を説明する。「サービス」とは、いわゆるＷｅｂサービス（ＷＷＷ関連技術を適用することで、アプリケーションの機能をネットワーク経由で実現するサービス）のことである。インターネットなどＩＰによって制御されるネットワークにおいて、「サービス提供サーバ」がサービスを制御し、ネットワークに接続する「端末」が「サービス」の提供を受けるという関係にある。

ところで、「サービス提供サーバ」は、端末各々の関係や端末とサービス提供サーバとの関係、もしくは端末を利用する利用者同士の関係などに基づいて、サービスを制御する。具体的に例を挙げて説明すると、例えば、ＩＭサービスにおいて、端末Ａを利用する利用者と端末Ｂを利用する利用者とがファイル共有を実現する場合を想定する。端末Ｂが、「サービス提供サーバ」にアクセスしている際に、端末Ａが、「サービス提供サーバ」にファイルをアップロードしたとする。このような場合、「サービス提供サーバ」は、端末Ａの利用者と端末Ｂの利用者との関係に基づいて、端末Ｂにファイルを送信する。すなわち、「サービス提供サーバ」は、例えば、端末Ａの利用者から利用者ＩＤやパスワードの入力を受け付け、端末Ｂの利用者から利用者ＩＤやパスワードの入力を受け付けることで、端末Ａの利用者と端末Ｂの利用者とを特定する。そして、「サービス提供サーバ」は、特定した端末Ａの利用者と端末Ｂの利用者との関係が、ファイル共有を互いに認めている関係であれば、当該関係に基づいて、端末Ｂにファイルを送信するよう、サービスを制御するのである。

また、例えば、ＳＮＳ（Social Networking Service）において、サイトの運営者である端末Ａの利用者が端末Ｂの利用者にサイトを閲覧させる場合を想定する。このような場合、「サービス提供サーバ」は、端末Ａの利用者と端末Ｂの利用者との関係に基づいて、端末Ｂの利用者によるサイトの閲覧を制御する。すなわち、「サービス提供サーバ」は、特定した端末Ａの利用者と特定した端末Ｂの利用者との関係が、端末Ａの利用者によって端末Ｂの利用者によるサイトの閲覧が認められている関係であれば、当該関係に基づいて、端末Ｂの利用者によるサイトの閲覧を許可するよう、サービスを制御するのである。

また、例えば、音楽情報を提供する「サービス提供サーバ」が、端末Ａの利用者に音楽情報のダウンロードを許可する場合を想定する。このような場合、「サービス提供サーバ」は、端末Ａの利用者と「サービス提供サーバ」との関係に基づいて、端末Ａによるダウンロード通信を制御する。すなわち、「サービス提供サーバ」は、特定した端末Ａの利用者と「サービス提供サーバ」との関係が、「サービス提供サーバ」によって端末Ａの利用者によるダウンロード通信が認められている関係であれば、当該関係に基づいて、端末Ａによるダウンロード通信を許可するよう、サービス提供を制御するのである。

このように、端末各々の関係や端末とサービス提供サーバとの関係、もしくは端末を利用する利用者同士の関係などは、そのサービス内容によって様々な態様があるが、いずれの場合も、「サービス提供サーバ」が、これらの関係に基づいてサービスを制御することに変わりはない。

もっとも、従来のＷｅｂサービスは、このような関係が、予め登録されたものであることを前提として提供されてきた。例えば、従来の「サービス提供サーバ」は、利用者同士の関係などを予めバディリストに登録し、登録したバディリストに基づいて、チャットや画像データの共有などのサービスを制御していたのである。これに対し、本発明における「サービス提供サーバ」は、予め登録されたバディリストのような関係のみならず、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）にも、かかる一時的な通信関係に基づいて、チャットや画像データの共有などのサービスを制御するものである。

［実施例１に係るサービス提供システムの全体構成］
図１に示すように、このサービス提供システムは、ＨＧＷ・情報表示端末・ＳＩＰフォンなどを有する利用者宅Ａ〜Ｃと、ＳＩＰプロキシと、セッション管理サーバと、サービス提供サーバと、３ＰＣＣサーバと、会議室サーバとがネットワークを介して、相互に通信可能に接続されている。

各装置の機能を簡単に説明しておくと、利用者宅のＨＧＷは、他の装置やネットワークとの通信を中継するホームゲートウェイであり、情報表示端末は、Ｗｅｂブラウザなどを用いてネットワーク上のサービスを利用するパーソナルコンピュータなどの装置であり、ＳＩＰフォンは、ＳＩＰを用いて音声接続を行う装置であり、ハードウエアで実現されていてもよく、パーソナルコンピュータなどに組み込むソフトウエアとして実現されていてもよい。

ＳＩＰプロキシは、ＳＩＰサーバの役割の一つであり、ＳＩＰフォンなどからのリクエストをほかのＳＩＰ端末やＳＩＰサーバに転送するサーバである。セッション管理サーバは、後述するcallセッション情報や制御用セッション情報を用いて、利用者宅Ａと利用者宅Ｂと利用者宅Ｃとの接続を行うサーバである。サービス提供サーバは、上記したように、端末各々の関係や端末とサービス提供サーバとの関係、もしくは端末を利用する利用者同士の関係などに基づいて、サービスを制御する。

３ＰＣＣサーバは、端末と端末を、第３の装置から操作し接続する「３rd Party Call Control」を実施するサーバであり、会議室サーバは、２者間音声ブリッジや３者間音声ブリッジなどＮ者間音声ブリッジを接続制御するサーバである。

このような構成を有するサービス提供システムによれば、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することが可能になる。例えば、ＳＩＰフォンという簡単なインターフェースを用いて、一時的な通信関係で複数の利用者宅同士（情報表示端末同士）を接続することができる。

［実施例１に係るサービス提供システムの構成］
次に、図２〜図１９を用いて、実施例１に係るサービス提供システムの各装置の構成について説明する。なお、以下では、サービス提供システムの構成については簡単に説明し、各部の処理については後述する処理手順にて詳細に説明することとする。

（セッション管理サーバの構成）
図２は、セッション管理サーバの構成を示すブロック図である。図２に示すように、セッション管理サーバ１００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、通信制御Ｉ／Ｆ部１１０と、記憶部１２０と、制御部１３０とを備える。

通信制御Ｉ／Ｆ部１１０は、ＨＴＴＰ通信用の一般的なインターフェースおよびライブラリを備え、情報表示端末２０との間で情報を送受信したり、ＨＧＷ１０やサービス提供サーバ２００との間で情報を送受信したりするなどする。

記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図２に示すように、ユーザ契約サービス管理テーブル１２１と契約サービス情報テーブル１２２と制御用セッション管理テーブル１２３と発着間紐付けＩＤテーブル１２４と会議室サービステーブル１２５と会議室対応管理テーブル１２６とデータテーブル１２７とを有する。

ユーザ契約サービス管理テーブル１２１は、情報表示端末２０（およびＳＩＰフォン３０）を利用する利用者（ユーザ）が契約しているサービスを管理するテーブルである。例えば、ユーザ契約サービス管理テーブル１２１は、図３に示すように、ユーザ特定情報と契約サービスＩＤとを対応付けて記憶する。ユーザ契約サービス管理テーブル１２１が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。

ここで、ユーザ特定情報とは、情報表示端末２０の利用者を特定するための情報であり、実施例１においては、ＳＩＰ−ＵＲＩ（Uniform Resource Identifier）を用いている。また、契約サービスＩＤ（以下、適宜、サービスＩＤとも称する）とは、サービスを識別するＩＤである。このように、ユーザ契約サービス管理テーブル１２１は、ユーザ特定情報と契約サービスＩＤとを対応付けて記憶することで、ユーザ特定情報で特定される利用者が、契約サービスＩＤで識別されるサービスの加入者であることを管理している。

契約サービス情報テーブル１２２は、契約サービス各々について、各種情報を管理するテーブルである。例えば、契約サービス情報テーブル１２２は、図４に示すように、契約サービスＩＤとアクセス先ＵＲＬとを対応付けて記憶する。ここで、アクセス先ＵＲＬとは、契約サービスＩＤで識別されるサービスを提供するサービス提供サーバ２００のＵＲＬである。契約サービス情報テーブル１２２が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。

制御用セッション管理テーブル１２３は、制御用セッション情報（セッション管理サーバ１００が情報表示端末２０との間で通信を行うために、当該情報表示端末２０のＷｅｂブラウザに対して付与する情報）を管理するテーブルである。例えば、制御用セッション管理テーブル１２３は、図５に示すように、制御用セッション情報と、Ｃａｌｌ−ＩＤと、Ｆｒｏｍと、Ｔｏと、発着判定フラグと、通話情報（開始時刻〜終了時刻）と、ＨＧＷのＵＲＬとグループＩＤとを対応付けて記憶している。

制御用セッション管理テーブル１２３が記憶するこれらの情報の内、制御用セッション情報は、セッション管理サーバ１００が情報表示端末２０からサービス開始要求を受け付けた際に払い出したものであり、例えば、セッション管理サーバ１００が情報表示端末２０との間で通信を行うために、当該情報表示端末２０のＷｅｂブラウザに対して付与する情報のことであり、情報表示端末２０とセッション管理サーバ１００との間で確立されたＷｅｂ通信を一意に識別する情報である。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に制御用セッション情報を払い出し、制御用セッション管理テーブル１２３に格納する。なお、制御用セッション情報としては、情報表示端末２０がＷｅｂ通信を行う際に利用するブラウザに付与された情報である『セッションID』（CookieのIDなど）を用いる手法などが考えられる。また、制御用セッション情報は、一般的には確立されたセッションごとにユニークに生成される。

また、ｃａｌｌセッション情報とは、ＳＩＰフォン３０間でＳＩＰによって確立されたセッションを一意に識別する情報である。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に当該情報表示端末２０から取得し、制御用セッション管理テーブル１２３に格納する。なお、ｃａｌｌセッション情報としては、ＳＩＰ通信に含まれる情報である『Ｃａｌｌ−ＩＤ』もしくは『ｉｓｕｂ』、または、『Ｆｒｏｍ』、『Ｔｏ』、『ｔａｇ』、ＩＰアドレス、もしくは、これらの組合せを用いる手法や、ＳＩＰ通信に含まれるその他の情報（例えば、『Ｄａｔｅ』など）を組合せて用いる手法などが考えられ、ＳＩＰによって確立された通信を一意に識別することが可能な情報を用いる手法であれば、どのような手法でもよい。また、ｃａｌｌセッション情報は、一般的には確立されたセッションごとにユニークに生成される。

また、発着判定フラグとは、ＳＩＰフォン３０間でＳＩＰによって確立されたセッションについて、ＳＩＰフォン３０（制御用セッション情報を払い出した情報表示端末２０と組で利用されるＳＩＰフォン３０）が発側であるのか着側であるのかを判定するフラグである。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に当該情報表示端末２０から取得し、制御用セッション管理テーブル１２３に格納する。

通話情報とは、ｃａｌｌセッション情報によって一意に識別されるセッションの開始時刻と終了時刻とを示す情報である。例えば、後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に、その時刻を開始時刻として制御用セッション管理テーブル１２３に格納する。なお、後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０から開始時刻を取得し、制御用セッション管理テーブル１２３に格納してもよい。また、例えば、セッション管理サーバ１００は、セッションが切断されたことを把握した際などに、その時刻を終了時刻として制御用セッション管理テーブル１２３に格納する。

ＨＧＷのＵＲＬとは、情報表示端末２０によるＨＴＴＰ通信を制御するＨＧＷ１０のＵＲＬである。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に当該情報表示端末２０から取得し、制御用セッション管理テーブル１２３に格納する。また、グループＩＤは、通話接続（音声ブリッジ）されている端末をグループ化するための情報である。

このように、制御用セッション管理テーブル１２３は、セッション管理サーバ１００が払い出した制御用セッション情報に対応付けて、ＳＩＰフォン３０（情報表示端末２０と組で利用されるＳＩＰフォン３０）によって確立されたセッションに関する情報（以下、ｃａｌｌセッション情報、発着判定フラグおよび通話情報を「セッションに関する情報」という）等を記憶することで、制御用セッション情報が、どのような情報表示端末２０に対して払い出されたものであるか等を管理するものである。なお、図５において、説明の便宜上、制御用セッション情報や『Ｃａｌｌ−ＩＤ』として規則的な数値が例示されているが、一般的には乱数などが格納されることになる。

発着間紐付けＩＤテーブル１２４は、発着間紐付けＩＤ（ＳＩＰによって確立されたセッションを一意に識別するｃａｌｌセッション情報の仮名としてセッション管理サーバ１００が払い出した仮名情報）を管理するテーブルである。例えば、発着間紐付けＩＤテーブル１２４は、図６に示すように、制御用セッション情報と、契約サービスＩＤと、発着間紐付けＩＤと、仮名ＩＤと、ステータスとを対応付けて記憶している。

発着間紐付けＩＤテーブル１２４が記憶するこれらの情報は、セッション管理サーバ１００が発着間紐付けＩＤおよび仮名ＩＤを発行する際などに登録される。ここで、発着間紐付けＩＤは、サービス提供サーバ２００が、通話中の情報表示端末２０各々、すなわち、利用者各々がＳＩＰフォン３０各々によって通話中である情報表示端末２０各々を紐付けるために利用するＩＤである。後述するように、発着間紐付けＩＤは、確立されたセッションごと（すなわち、通話ごと）に新しく払い出されるため、サービス提供サーバ２００は、セッション単位で（すなわち、通話単位で）情報表示端末２０各々を紐付けることができる。

また、仮名ＩＤとは、情報表示端末２０と当該情報表示端末２０が利用するサービスとの組合せごとに、かつ、確立されたセッションごと（すなわち、通話ごと）にセッション管理サーバ１００が発行したものである。例えば、情報表示端末２０と当該情報表示端末２０が利用するサービスとの組合せを一意に識別する情報であり、サービス提供サーバ２００が、２台の情報表示端末２０のうちのどちらの情報表示端末２０であるかを特定するために利用するＩＤである。すなわち、サービス提供サーバ２００は、発着間紐付けＩＤを用いることで２台の情報表示端末２０を特定し、特定した２台の情報表示端末２０に提供するサービスを連携するように制御することまではできるが、発着間紐付けＩＤだけでは２台の情報表示端末２０を区別してサービスを提供することまではできない。この点、仮名ＩＤは、情報表示端末２０とサービスとの組合せごとに発行されるため、サービス提供サーバ２００は、この仮名ＩＤを用いて２台の情報表示端末２０それぞれを区別し、それぞれの情報表示端末２０に適応したサービスを提供するように制御することができる。

また、ステータスとは、仮名ＩＤによって識別される利用者が、契約サービスＩＤによって識別されるサービスを利用中であるか否かの状態を示すものである。

会議室サービステーブル１２５は、図７に示すように、契約サービスＩＤに対応つけて、会議室サーバの電話番号を管理するテーブルである。会議室サービステーブル１２５は、ユーザ契約サービス管理テーブル１２１が管理する「契約サービスＩＤ」に対応付けて「会議室サーバのＵＲＬ」を記憶しているので、セッション管理サーバ１００は、「契約サービスＩＤ」をキーに「会議室サーバのＵＲＬ」を特定して、情報表示端末２０各々に通知することができる。会議室サービステーブル１２５が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。

会議室対応管理テーブル１２６は、図８に示すように、会議室ＩＤに対応付けて、グループＩＤを管理するテーブルである。例えば、会議室対応管理テーブル１２６は、サービス提供サーバ２００によって会議室ＩＤが発行されたタイミングで、当該発行された会議室ＩＤと、会議室ＩＤが発行された情報表示端末２０の制御用セッション情報をキーにして制御用セッション管理テーブル１２３から特定できるグループＩＤとを対応付けて管理する。こうすることにより、どのグループＩＤの情報表示端末２０がどの会議室ＩＤを利用しているかを把握することができる。

データテーブル１２７は、データ受け渡しの対象となったデータを記憶するテーブルである。例えば、データテーブル１２７は、図９に示すように、データファイル名とデータとを対応付けて記憶する。データの受け渡しは、必ずしもセッション管理サーバ１００が受け渡しの対象となったデータを取得するとは限らないが、セッション管理サーバ１００がデータを取得した場合には、セッション管理サーバ１００は、取得したデータを適宜データテーブル１２７に格納すればよい。

制御部１３０は、特に本発明に密接に関連するものとしては、図２に示すように、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２と、会議室関連制御部１３３と、受け渡し要求判定部１３４と、データ受け渡し制御部１３５とを有する。

ｃａｌｌセッション情報収集部１３１は、サービス開始要求を送信してきた情報表示端末２０毎に、当該情報表示端末２０と組で利用されるＳＩＰフォン３０と他のＳＩＰフォン３０との間で確立された通信を識別するｃａｌｌセッション情報を収集する。

発着間紐付けＩＤ発行部１３２は、ｃａｌｌセッション情報収集部１３１によって収集された複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報を特定し、特定したｃａｌｌセッション情報によって識別されるＳＩＰフォン３０各々と組で利用される情報表示端末２０各々を連携するための発着間紐付けＩＤを、情報表示端末各々に対して発行する。また、発着間紐付けＩＤ発行部１３２は、仮名ＩＤを発行する。

会議室関連制御部１３３は、他の情報表示端末と通話接続された情報表示端末から新たな情報表示端末との通話接続要求（３者間セッション連携要求）を受信した場合に、当該接続要求を送信した情報表示端末の仮名ＩＤが自装置が発行した仮名ＩＤであるか否かを判定したり、当該接続要求を送信した情報表示端末（ＨＧＷ）の通話相手を特定してグループＩＤを発行したりして、会議室サーバを介して２者間接続や３者間接続を実行し、新たな情報表示端末との通話接続を確立する。

受け渡し要求判定部１３４は、サービス提供サーバ２００からサービスを連携するように提供される情報表示端末２０間において、一方の情報表示端末２０からデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０が、ｃａｌｌセッション情報収集部１３１によって収集されたｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０であるか否かを判定する。すなわち、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。

データ受け渡し制御部１３５は、受け渡し要求判定部１３４によって、受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であると判定されると、受け渡し要求に従って、受け渡しに用いられるデータをデータの保存元から取得し、取得したデータを用いてデータの受け渡しを制御する。

（サービス提供サーバの構成）
サービス提供サーバ２００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図１０に示すように、通信部２１０と、記憶部２２０と、制御部２３０とを備える。

通信部２１０は、ＨＴＴＰ通信用の一般的なインターフェースおよびライブラリを備え、セッション管理サーバ１００との間や、情報表示端末２０との間、ＳＩＰプロキシとの間などで情報を送受信する。

記憶部２２０は、制御部２３０における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図１０に示すように、Ｗｅｂセッション情報管理テーブル２２１とデータテーブル２２２とを有する。

Ｗｅｂセッション情報管理テーブル２２１は、発着間紐付けＩＤ（ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報の仮名としてセッション管理サーバ１００が発行した仮名情報であり、情報表示端末２０各々を連携するための情報）などを管理するテーブルである。例えば、Ｗｅｂセッション情報管理テーブル２２１は、図１１に示すように、Ｗｅｂセッション情報と、発着間紐付けＩＤと、仮名ＩＤと、発着判定フラグとを対応付けて記憶している。

Ｗｅｂセッション情報管理テーブル２２１が記憶するこれらの情報の内、Ｗｅｂセッション情報（サービス提供サーバ２００が情報表示端末２０との間で通信を行うために、当該情報表示端末２０のＷｅｂブラウザに対して付与する情報）は、サービス提供サーバ２００が、情報表示端末２０からサービス利用要求を受け付けた際に払い出し、登録するものである。また、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグは、サービス提供サーバ２００が、情報表示端末２０からサービス利用要求を受け付けた際に登録するものである。

ここで、Ｗｅｂセッション情報は、サービス提供サーバ２００が、情報表示端末２０を特定するために用いられる。すなわち、サービス提供サーバ２００は、情報表示端末２０からアクセスを受付けた際に、当該情報表示端末２０のＷｅｂブラウザに付与されているＷｅｂセッション情報を取得し、情報表示端末２０を特定する。また、発着間紐付けＩＤは、サービス提供サーバ２００が、通話中の情報表示端末２０各々、すなわち、利用者各々がＳＩＰフォン３０各々によって通話中である情報表示端末２０各々を紐付けるために用いられる。

また、仮名ＩＤは、サービス提供サーバ２００が、２台の情報表示端末２０のうちのどちらの情報表示端末２０であるかを特定するために用いられる。すなわち、サービス提供サーバ２００は、発着間紐付けＩＤを用いることで情報表示端末２０を特定し、特定した情報表示端末２０に提供するサービスを連携するように制御することまではできるが、発着間紐付けＩＤだけでは複数の情報表示端末２０それぞれを区別してサービスを提供することまではできない。この点、仮名ＩＤは、情報表示端末２０とサービスとの組合せごとに発行されるため、サービス提供サーバ２００は、この仮名ＩＤを用いて情報表示端末２０それぞれを区別し、それぞれの情報表示端末２０に適応したサービスを提供するように制御することができる。つまり、サービス提供サーバ２００は、仮名ＩＤを用いることによって、「通話中の利用者各々のいずれかであること」だけでなく、「いずれの利用者であるか」を特定することはできる。また、発着判定フラグは、サービス提供サーバ２００が、情報表示端末２０と組で利用されるＳＩＰフォン３０が、発側であるのか着側であるのかを判定するために用いられる。

データテーブル２２２は、データ受け渡しの対象のデータを記憶するテーブルである。例えば、データテーブル２２２は、図１２に示すように、仮名ＩＤとデータとを対応付けて記憶する。すなわち、データテーブル２２２は、利用者とデータとの対応関係を記憶するため、利用者を特定する仮名ＩＤとデータとを対応づけて記憶する。なお、サービス提供サーバ２００は、初めから仮名ＩＤとデータとの対応をデータテーブル２２２に保存していても良いし、例えば、データダウンロード画面を生成する場合には、通話相手のデータやサービス提供サーバ２００に関する情報をダウンロード用のデータとしてＳＩＰフォン３０の利用者の仮名ＩＤと対応づけてデータテーブル２２２に保存し、通話相手のデータやサービス提供サーバ２００のデータをダウンロードできるようにしても良い。

図１０に戻り、制御部２３０は、特に本発明に密接に関連するものとしては、図１０に示すように、発着間紐付けＩＤ収集部２３１と、サービス提供制御部２３２と、データ受け渡し部２３３とを備える。

発着間紐付けＩＤ収集部２３１は、サービスの提供を要求する情報表示端末２０毎に、セッション管理サーバ１００によって発行された発着間紐付けＩＤを収集し、Ｗｅｂセッション情報管理テーブル２２１に格納する。すなわち、発着間紐付けＩＤ収集部２３１は、情報表示端末２０からサービス提供の要求を受け付けると、当該情報表示端末２０から発着間紐付けＩＤを収集する。発着間紐付けＩＤは、上記したように、確立されたセッションごと（すなわち、通話ごと）に新しく払い出されるものであるので、発着間紐付けＩＤ収集部２３１は、個々の情報表示端末２０から発着間紐付けＩＤを収集した結果、２つの情報表示端末２０からは同じ発着間紐付けＩＤを収集することにもなる。また、実施例１における発着間紐付けＩＤ収集部２３１は、情報表示端末２０毎に、仮名ＩＤおよび発着判定フラグを収集し、Ｗｅｂセッション情報管理テーブル２２１に格納する。

サービス提供制御部２３２は、発着間紐付けＩＤ収集部２３１によって収集された複数の発着間紐付けＩＤの中からサービスを連携することを示す発着間紐付けＩＤを特定し、特定した発着間紐付けＩＤの収集元である情報表示端末２０各々に提供するサービスを連携するように、サービス提供を制御する。

データ受け渡し部２３３は、セッション管理サーバ１００による制御に従って、サービスに関連するデータの受け渡しを行う。すなわち、実施例１に係るサービス提供システムにおいて、データの受け渡しは、セッション管理サーバ１００において「受け渡し要求の要求元の情報表示端末が、収集したｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォンと組で利用される情報表示端末であるか否か」が判定されることによって制御される。言い換えると、セッション管理サーバ１００が、どのデータが受け渡しの対象であるのか、どの情報表示端末２０に受け渡すべきであるのかといった情報を、サービス提供サーバ２００に通知し、サービス提供サーバ２００を制御することで、データ受け渡し全体を制御するものであるといえる。データ受け渡し部２３３は、このようなセッション管理サーバ１００からの制御情報を受け取って、データの受け渡しを行う。

なお、ここで、改めて、サービス提供サーバ２００によるサービス提供について考える。すなわち、サービス提供サーバ２００によるサービス提供が、情報表示端末２０間の関係に基づいて制御される点は、予め登録したバディリストに基づいてサービスを制御するような従来のサービス提供サーバと同様であるが、実施例１におけるサービス提供サーバ２００が、「情報表示端末２０間の関係」をどのように把握しているかを説明する。

つまり、実施例１におけるサービス提供サーバ２００は、従来のサービス提供サーバのように、予め記憶部に登録された関係（例えば、バディリストに登録された関係）を「情報表示端末２０間の関係」として把握するのではなく、サービス提供制御部２３２が、発着間紐付けＩＤを用いて「情報表示端末２０間の関係」を把握するのである。言い換えると、サービス提供サーバ２００は、ＳＩＰによって同一の通信を確立したＳＩＰフォン３０間の関係のように、通信相手となる端末との関係が一時的な場合にも、かかる一時的な通信関係に基づいて、情報表示端末２０各々において行われるＷｅｂ通信を互いに関連づけることで、一時的な通信関係に関連づけたサービス提供を可能としている。

なお、実施例１のように、第１の通信がＳＩＰによって通信を確立する過程の通信である場合には、「情報表示端末２０間の関係」がＳＩＰによる認証済みの関係であるという点でも意味がある。すなわち、ＳＩＰ通信においては、Digest（ダイジェスト）認証などが行われるのが一般的であり、ＳＩＰフォン３０間でＳＩＰによって通信が確立されたということは、情報表示端末２０各々の関係が認証済みであることを示す。

（ＨＧＷの構成）
図１３に示すＨＧＷ１０は、以下に説明する各部が汎用的なゲートウェイ装置などに備えられることによって実現され、特に本発明に密接に関連するものとしては、ＳＩＰ通信部／ＨＴＴＰ通信部１１と、記憶部１２と、制御部１３とを備える。

ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰ用およびＨＴＴＰ通信用の一般的なインターフェースおよびライブラリを備え、ＳＩＰフォン３０とＳＩＰプロキシとの間の通信、情報表示端末２０とサービス提供サーバ２００との間の通信、ＨＧＷ１０とセッション管理サーバ１００との間の通信、ＨＧＷ１０とＳＩＰプロキシとの間の通信、ＨＧＷ１０とサービス提供サーバ２００との間の通信などを制御する。

記憶部１２は、制御部１３における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図１３に示すように、ブラウザセッション情報管理テーブル１２ａを有する。

ブラウザセッション情報管理テーブル１２ａは、配下の情報表示端末２０に割り当てられたブラウザセッション情報を予め記憶する。例えば、ブラウザセッション情報管理テーブル１２ａは、図１４に示すように、ＳＩＰフォン３０を一意に識別する情報（ＳＩＰフォンＩＤ）と、当該ＳＩＰフォン３０と組で利用される情報表示端末２０を一意に識別する情報（情報表示端末ＩＤ）と、当該情報表示端末２０を特定するためのブラウザセッション情報とを対応づけて予め記憶する。また、ブラウザセッション情報管理テーブル１２ａは、Ｃａｌｌ−ＩＤと、Ｆｒｏｍと、Ｔｏと、発着判定フラグと、通話情報とを対応付けて記憶している。ブラウザセッション情報管理テーブル１２ａが記憶するこれらの情報の内、Ｃａｌｌ−ＩＤと、Ｆｒｏｍと、Ｔｏとは、例えば、ＨＧＷ１０が収集し、登録したものである。発着判定フラグは、ＨＧＷ１０が、ＳＩＰによって確立された通信に含まれる情報から自ら生成した情報である。ＨＧＷ１０は、配下に接続するＳＩＰフォン３０を把握しているので、該当する呼が、発信であるのか、着信であるのかを判断することができる。

図１３に戻り、制御部１３は、特に本発明に密接に関連するものとしては、図１３に示すように、サービス利用制御部１３ａとデータ受け渡し部１３ｂとを有する。

サービス利用制御部１３ａは、情報表示端末２０によるサービス利用を制御する。データ受け渡し部１３ｂは、セッション管理サーバ１００による制御に従って、サービスに関連するデータの受け渡しを行う。

（会議室サーバの構成）
会議室サーバ３００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図１５に示すように、通信制御Ｉ／Ｆ部３１０と、記憶部３２０と、制御部３３０とを有する。

通信制御Ｉ／Ｆ部３１０は、ＨＴＴＰ通信用の一般的なインターフェースおよびライブラリを備え、セッション管理サーバ１００などの他のサーバ装置との間や、情報表示端末２０との間、ＳＩＰプロキシとの間などで情報を送受信する。

記憶部３２０は、制御部３３０における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図１５に示すように、会議室管理テーブル３２１と会議用セッション情報管理テーブル３２２とを有する。

会議室管理テーブル３２１は、会議室がどのユーザによって利用されているのかを管理するテーブルである。例えば、会議室管理テーブル３２１は、図１６に示すように、Ｎ者間を接続する会議室を一意に識別する会議室ＩＤと、当該会議室ＩＤによって特定される会議室を利用しているＳＩＰフォン（ＨＧＷ）のＳＩＰ−ＵＲＩと、当該会議室が利用された開始時刻と、当該会議室の利用が終了した終了時刻と、当該会議室の利用ステータスとを管理する。

会議用セッション情報管理テーブル３２２は、会議室管理テーブル３２１のステータスが「使用中」となっている会議室ＩＤを利用するユーザの詳細情報を記憶する。例えば、会議用セッション情報管理テーブル３２２は、会議室管理テーブル３２１のステータスが「使用中」となっている会議室ＩＤに対応付けて、当該会議室ＩＤによって特定される会議室を利用している情報表示端末等のcallセッション情報や発着フラグ、通話情報などを記憶する。

図１５に戻り、制御部３３０は、特に本発明に密接に関連するものとしては、図１５に示すように、会議室ＩＤ発行部３３１と、音声ブリッジ制御部３３２とを備える。

会議室ＩＤ発行部３３１は、セッション管理サーバ１００から会議室予約要求を受け付けた場合に、会議室ＩＤを発行する。その後、会議室サーバ３００を介して利用者宅同士が接続された場合に、会議室ＩＤ発行部３３１は、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を自ら収集することで取得し、また、発着判定フラグを取得する。そして、会議室ＩＤ発行部３３１は、収集した情報を会議用セッション情報管理テーブル３２２に格納する。

音声ブリッジ制御部３３２は、複数の利用者宅同士を音声ブリッジ接続する。例えば、音声ブリッジ制御部３３２は、会議室ＩＤ発行部３３１により会議室ＩＤがセッション管理サーバ１００に送信されて、セッション管理サーバから受信した「会議室ＩＤ」と「callセッション情報」をキーにして、会議用セッション情報管理テーブル３２２からＦｒｏｍやＴｏを特定することで、音声ブリッジ接続をするＨＧＷを特定する。そして、音声ブリッジ制御部３３２は、ＨＧＷ同士の音声ブリッジ（２者間音声ブリッジ）を開始し、２者間音声ブリッジ開始完了通知をセッション管理サーバに通知する。また、音声ブリッジ制御部３３２は、ここで音声ブリッジ接続したＨＧＷのＳＩＰ−ＵＲＩと会議室ＩＤとを対応付けて会議室管理テーブル３２１に格納する。

また、音声ブリッジ制御部３３２は、セッション管理サーバ１００から、音声ブリッジで追加接続する利用者宅のcallセッション情報と会議室ＩＤとが通知された場合に、通知された「会議室ＩＤ」が一致する会議用セッション情報管理テーブル３２２に、同様に受信した追加接続する利用者宅のcallセッション情報を追加格納して、３者間音声ブリッジを開始する。また、音声ブリッジ制御部３３２は、ここで新たに音声ブリッジ接続したＨＧＷのＳＩＰ−ＵＲＩを、追加接続された会議室ＩＤに対応付けて会議室管理テーブル３２１に格納する。

（ＳＩＰフォンの構成）
ＳＩＰフォン３０は、汎用的なＳＩＰフォンによって実現され、特に本発明に密接に関連するものとしては、図１８に示すように、ＳＩＰ通信部３１と、入力部３２と、出力部３３と、入出力制御Ｉ／Ｆ部３４とを有する。

いずれも汎用的なＳＩＰフォン３０と同様であるので簡単に説明すると、入力部３２は、ＳＩＰフォン３０に用いられる情報や、各種処理をするための操作指示などを、番号キーやマイクなどによって入力し、出力部３３は、ＳＩＰフォン３０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやスピーカに出力し、入出力制御Ｉ／Ｆ部３４は、入力部３２と、出力部３３と、ＳＩＰ通信部３１との間における情報転送を制御し、ＳＩＰ通信部３１は、ＳＩＰ用の一般的なインターフェースおよびライブラリを備え、他方のＳＩＰフォン３０との間で（ＨＧＷ１０を介して）情報を送受信する。

（情報表示端末の構成）
情報表示端末２０は、以下に説明する各部が汎用的なＰＣや情報家電などに備えられることによって実現され、特に本発明に密接に関連するものとしては、図１９に示すように、ＨＴＴＰ通信部２１と、入力部２２と、出力部２３と、入出力制御Ｉ／Ｆ部２４と、制御部２５とを有する。

入力部２２は、情報表示端末２０に用いられる情報や、各種処理をするための操作指示などを、キーボード、マウス、リモコンなどによって入力し、出力部２３は、情報表示端末２０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやプリンタなどに出力し、入出力制御Ｉ／Ｆ部２４は、入力部２２と、出力部２３と、ＨＴＴＰ通信部２１と、制御部２５との間における情報転送を制御し、ＨＴＴＰ通信部２１は、ＨＴＴＰ通信用の一般的なインターフェースおよびライブラリを備え、サービス提供サーバ２００との間で（ＨＧＷ１０を介して）情報を送受信する。

制御部２５は、特に本発明に密接に関連するものとしては、図１９に示すように、サービス利用部２５ａと受け渡し要求部２５ｂとを備える。

サービス利用部２５ａは、サービス提供サーバ２００によって提供されるサービスを利用する。具体的には、サービス利用部２５ａは、サービスの提供を開始するサービス提供開始要求をセッション管理サーバ１００に送信したり、サービスの利用を要求するサービス利用要求をサービス提供サーバ２００に送信したりする。

受け渡し要求部２５ｂは、セッション管理サーバ１００による制御に従って、サービスに関連するデータの受け渡しを行う。具体的には、受け渡し要求部２５ｂは、サービスに関連するデータの受け渡しを要求する受け渡し要求をセッション管理サーバ１００に送信するなどする。

［実施例１に係るサービス提供システムによる処理の手順］
続いて、図２０〜図２４を用いて、実施例１に係るサービス提供システムによる処理の流れを説明する。

（サービス提供に関する処理の手順）
図２０に示すように、まず、ＳＩＰプロキシが、両ＳＩＰフォン３０（ＳＩＰ通信部３１）による通信を制御することで、両ＳＩＰフォン３０（ＳＩＰ通信部３１）間でステップＳ１〜Ｓ３のＳＩＰ通信が行われ、その結果、ステップＳ４において、両ＳＩＰフォン３０間でＳＩＰによって通信（呼）が確立される。なお、ＳＩＰ通信におけるDigest認証やREGISTER処理などについては図示していないが、一般的なＳＩＰ通信と同様、ステップＳ１よりも前に行われている。

両ＳＩＰフォン間でＳＩＰによって通信が確立されると、ＨＧＷ１０（サービス利用制御部１３ａ）は、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を自ら収集することで取得し、また、発着判定フラグを取得する（ステップＳ５）。例えば、ＨＧＷ１０は、ｃａｌｌセッション情報としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ）』および『Ｔｏ（ＳＩＰ−ＵＲＩ）』を、ＳＩＰによって確立された通信に含まれる情報から自ら収集することで取得する。また、ＨＧＷ１０（サービス利用制御部１３ａ）は、両ＳＩＰフォンが発側であるのか着側であるのかを示す『発着判定フラグ』を、ＳＩＰによって確立された通信に含まれる情報から自ら生成する。なお、ＨＧＷ１０（サービス利用制御部１３ａ）は、取得したｃａｌｌセッション情報等についてＨＧＷの署名付証明書を発行し、当該署名付証明書をｃａｌｌセッション情報に添付することで、当該ｃａｌｌセッション情報を検証可能な形式で発行してもよい。

また、実施例１においては、ＨＧＷ１０がｃａｌｌセッション情報を自ら収集し、発着判定フラグを自ら生成する手法を説明したが、この手法に限られるものではない。例えば、ＨＧＷ１０が、ＳＩＰプロキシによって収集されたｃａｌｌセッション情報をＳＩＰプロキシから受信することで収集し、発着判定フラグについては自ら生成する手法でもよい。また、ＳＩＰプロキシから通知される情報に、ｃａｌｌセッション情報や発着判定フラグなどの情報が付与されていてもよい。

ここで、ＳＩＰプロキシがｃａｌｌセッション情報を収集する点について簡単に説明しておくと、ＳＩＰプロキシは、ＳＩＰによって通信を確立する過程やＳＩＰによって確立された通信を制御する装置自身であるので、自装置が制御することで確立したセッションに関する情報を管理しているのが一般的である。したがって、ＳＩＰプロキシは、自らが制御することで両ＳＩＰフォンの間にセッションを確立すると、ｃａｌｌセッション情報としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ）』、『Ｔｏ（ＳＩＰ−ＵＲＩ）』を、確立したセッションのＳＩＰ信号から収集することができる。そして、ＳＩＰプロキシは、収集したｃａｌｌセッション情報を、発側のＳＩＰフォンを配下に接続するＨＧＷと、着側のＳＩＰフォンを配下に接続するＨＧＷとに、プッシュ型で送信するなどする。すると、ＨＧＷは、ＳＩＰプロキシによって収集されたｃａｌｌセッション情報をＳＩＰプロキシから受信することで、ｃａｌｌセッション情報を収集することができる。

なお、この手法の場合に、ＳＩＰプロキシは、ｃａｌｌセッション情報についてＳＩＰプロキシの署名付証明書を発行し、当該署名付証明書をｃａｌｌセッション情報に添付することで、当該ｃａｌｌセッション情報を検証可能な形式で発行してもよい。

図２０に戻り、続いて、ＨＧＷ１０（サービス利用制御部１３ａ）は、配下のＳＩＰフォンを一意に識別する情報であるＳＩＰフォンＩＤを、当該ＳＩＰ通信に含まれる情報から収集する（ステップＳ６）。なお、ＳＩＰフォンＩＤとは、例えば、ＳＩＰフォンの内線番号のことである。ＨＧＷ１０の配下に複数のＳＩＰフォンが接続される構成の場合、ＳＩＰ−ＵＲＩはＨＧＷ１０に対して付与され、ＨＧＷ１０配下のＳＩＰフォン３０各々には、内線番号が付与される。

そして、ＨＧＷ１０（サービス利用制御部１３ａ）は、ステップＳ４においてＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する（ステップＳ７）。具体的には、ＨＧＷ１０（サービス利用制御部１３ａ）は、まず、ＳＩＰフォンＩＤをキーとしてブラウザセッション情報管理テーブル１２ａを検索することで情報表示端末２０を特定し、特定した情報表示端末２０のブラウザセッション情報と、ＨＧＷに対してポーリングを行う複数の情報表示端末２０各々のブラウザセッション情報とを比較し、ブラウザセッション情報の一致によって、ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する。

そして、ＨＧＷ１０（サービス利用制御部１３ａ）は、アクセス先変更指示を、ステップＳ７において特定された情報表示端末２０に対して行う。具体的には、特定された情報表示端末に対して、セッション管理サーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報等とともに行う（ステップＳ８）。この時、実施例１におけるＨＧＷ１０（サービス利用制御部１３ａ）は、セッション管理サーバ１００にＨＧＷ１０のＵＲＬを通知することを目的として、リダイレクト指示に、ＨＧＷ１０のＵＲＬをも含めている。すなわち、リダイレクト指示に含められたＨＧＷ１０のＵＲＬは、情報表示端末２０によってセッション管理サーバ１００に送信される。なお、実施例１においては、ＨＧＷ１０がセッション管理サーバ１００のＵＲＬを予め記憶部に記憶していることで、当該ＵＲＬにアクセス先を変更するようリダイレクト指示を行うことができる。この結果、情報表示端末２０は、リダイレクト指示を受け、ＨＧＷ１０のＵＲＬからセッション管理サーバ１００のＵＲＬにアクセス先を変更する。

すると、情報表示端末２０（サービス利用部２５ａ）はリダイレクトされ、接続先をセッション管理サーバ１００に変更し、サービスを開始することを要求するサービス開始要求を、当該セッション管理サーバ１００に送信する（ステップＳ９）。この時、情報表示端末２０（サービス利用部２５ａ）は、ｃａｌｌセッション情報等と、ＨＧＷのＵＲＬとを、セッション管理サーバに送信することになる。

一方、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、情報表示端末から送信されたｃａｌｌセッション情報等を受信すると、当該ｃａｌｌセッション情報等の検証を行う（ステップＳ１０）。すなわち、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、ｃａｌｌセッション情報等が真正な情報であることを検証する。例えば、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、ＳＩＰプロキシに問い合わせを行うことで、ｃａｌｌセッション情報等が真正な情報であることを検証する。なお、ｃａｌｌセッション情報等を、署名付証明書が添付された検証可能な形式で受信した場合には、セッション管理サーバは、例えば、当該署名付証明書を検証することで、ｃａｌｌセッション情報等が真正な情報であることを検証してもよい。

続いて、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、ステップＳ１０における検証の結果、ｃａｌｌセッション情報等が真正な情報であることを確認すると、当該ｃａｌｌセッション情報等、ＨＧＷ１０のＵＲＬ、及び通話情報としての開始時刻を制御用セッション管理テーブルに格納し、制御用セッション情報を払い出し、払い出した制御用セッション情報を制御用セッション管理テーブルおよび発着間紐付けＩＤテーブル１２４に格納する（ステップＳ１１）。

続いて、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、サービス開始要求を送信してきた情報表示端末２０（発側）が利用可能なサービスをユーザ契約サービス管理テーブル１２１で確認し、契約サービスＩＤを取得する（ステップＳ１２）。

そして、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、制御ページを生成する（ステップＳ１３）。

続いて、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、情報表示端末２０に対して、接続先監視機能と、ステップＳ１１で払い出した制御用セッション情報と、ステップＳ１３で生成した制御ページと、ステップＳ１２で取得した契約サービスＩＤとを送信する（ステップＳ１４）。ここで、接続先監視機能とは、例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイルであり、情報表示端末２０にインストールされることで、情報表示端末２０とセッション管理サーバ１００との間で通信を確立し、情報表示端末２０の接続先を監視する役割を果たす機能である。

すると、情報表示端末２０は、セッション管理サーバ１００から送信された制御ページをＷｅｂブラウザから表示する（ステップＳ１５）。また、情報表示端末２０は、セッション管理サーバ１００から送信された接続先監視機能をインストールする。すると、当該接続先監視機能部は、セッション管理サーバ１００との間で通信を確立し、セッション管理サーバ１００から送信された制御用セッション情報を用いてポーリングを行うことで、情報表示端末の接続先のＵＲＬをセッション管理サーバ１００に定期的に送信する。一方、サービス提供サーバは、ポーリングに用いられている制御用セッション情報を確認することで（ステップＳ１６）、当該制御用セッション情報を払い出した情報表示端末の接続先を定期的に監視する。

なお、これまで、発信側の情報表示端末２０について説明してきたが、着信側の情報表示端末２０についても同様の処理が行われる。こうして、発信側の情報表示端末２０および着信側の情報表示端末２０の両方に接続監視機能がインストールされ、接続先監視機能部各々とセッション管理サーバ１００との間で通信が確立される。

続いて、図２１に示すように、発信側の情報表示端末２０の利用者が、Ｗｅｂブラウザに表示された制御ページの中からサービスを選択することで（ステップＳ１７）、情報表示端末２０（サービス利用部２５ａ）は、サービス開始要求をセッション管理サーバ１００に対して送信する（ステップＳ１８）。この時、情報表示端末２０（サービス利用部２５ａ）は、ステップＳ１４において送信された制御用セッション情報を用いて、選択したサービスの契約サービスＩＤをセッション管理サーバ１００に対して送信する。なお、サービス開始要求の送信は、図２１に示すように、接続先監視機能を介して行われてもよく、あるいは、接続先監視機能を介さずに情報表示端末から直接セッション管理サーバ１００に送信されてもよい。

すると、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０から送信された制御用セッション情報が、制御用セッション管理テーブル１２３に登録されているものであることを確認し（ステップＳ１９）、発着間紐付けＩＤおよび仮名ＩＤを発行する（ステップＳ２０）。なお、発行された発着間紐付けＩＤおよび仮名ＩＤが発着間紐付けＩＤ管理テーブル１２４に格納される実装例を説明する。例えば、発信側の情報表示端末２０の利用者が、制御ページの中からサービスを選択すると（サービスを起動すると）、情報表示端末２０（サービス利用部２５ａ）は、選択したサービスを識別するサービスＩＤをセッション管理サーバ１００に送信する。この時、情報表示端末２０（サービス利用部２５ａ）は、制御用セッション情報を用いる。すると、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０が用いた制御用セッション情報を検索キーとして制御用セッション管理テーブル１２３を参照し、情報表示端末２０から送信された制御用セッション情報が、制御用セッション管理テーブル１２３に登録されているものであることを確認する。そして、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、確認した制御用セッション情報を用いて発着間紐付けＩＤテーブル１２４を参照する。報表示端末２０（サービス利用部２５ａ）による当該制御用セッション情報の送信が初回である場合には、制御用セッション情報は発着間紐付けＩＤテーブル１２４に未だ格納されていないはずである。このため、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤおよび仮名ＩＤを発行し、発行した発着間紐付けＩＤおよび仮名ＩＤを制御用セッション情報に対応付けて発着間紐付けＩＤテーブル１２４に格納し、さらに契約サービスＩＤ、ステータス（「利用中」）を格納する。

ここで、発着間紐付けＩＤとは、サービス提供サーバ２００において、発信側の情報表示端末２０と着信側の情報表示端末２０とを紐付けるために用いられるＩＤのことである。発信側のＳＩＰフォン３０と着信側のＳＩＰフォン３０との間でＳＩＰによって確立された通信は、ｃａｌｌセッション情報によって一意に識別することができるので、サービス提供サーバ２００は、当該ｃａｌｌセッション情報を用いれば、発信側の情報表示端末２０と着信側の情報表示端末とを紐付けることができる。しかしながら、ｃａｌｌセッション情報をサービス提供サーバ２００に開示することにセキュリティ上の問題があると考えられるような場合（例えば、どの利用者同士からのアクセスであるかをサービス提供事業者にはわからないようにする場合）には、ｃａｌｌセッション情報そのものをサービス提供サーバ２００に開示するべきではない。そこで、実施例１においては、ｃａｌｌセッション情報を匿名化し、かつ紐付け可能とするために、仮名の形式で、セッション管理サーバ１００が、発着間紐付けＩＤを発行するものである。また、仮名ＩＤとは、サービス提供サーバ２００において、発信側の利用者もしくは着信側の利用者を特定するために用いられるＩＤのことである。すなわち、発着間紐付けＩＤのみでは利用者までを特定することができないため、サービス提供事業者が利用者を特定することを目的として、情報表示端末２０と当該情報表示端末２０が利用するサービスとの組合せごとに、セッション管理サーバ１００が発行するものである。

セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０に対して、サービス提供サーバ２００のＵＲＬ（ステップＳ１２において取得したもの）と、発着間紐付けＩＤと、仮名ＩＤと、発着判定フラグとを送信する（ステップＳ２１）。また、実施例１におけるセッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを検証可能な形式で送信する。例えば、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグについてセッション管理サーバの署名付証明書を発行し、当該署名付証明書を発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグに添付することで、当該発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを検証可能な形式で発行する。なお、署名付証明書を添付する手法に限られるものではなく、添付しない手法を用いてもよい。

一方、情報表示端末２０（サービス利用部２５ａ）は、セッション管理サーバ１００から送信されたＵＲＬに接続し、セッション管理サーバ１００から送信された発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを、サービス提供サーバ２００に送信する（ステップＳ２２）。

すると、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、情報表示端末２０から送信された発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを受信すると、当該発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグの検証を行う（ステップＳ２３）。すなわち、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグに添付された署名付証明書を検証することで、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを検証する。なお、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを検証する手法としては、セッション管理サーバ１００に問い合わせを行う手法でもよい。

続いて、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、ステップＳ２３における検証の結果、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを確認すると、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを送信した情報表示端末２０が行うＷｅｂ通信（サービス提供を受けるために情報表示端末２０がサービス提供サーバ２００との間で行うＷｅｂ通信）に付与する情報として、Ｗｅｂセッション情報を払い出し、Ｗｅｂセッション情報管理テーブル２２１に格納する（ステップＳ２４）。すると、Ｗｅｂセッション情報管理テーブル２２１は、Ｗｅｂセッション情報と発着間紐付けＩＤと仮名ＩＤと発着判定フラグとを格納することになる。なお、このように、サービス提供サーバ２００は、仮名ＩＤや発着判定フラグをも格納していれば、サービス提供サーバ２００がサービスを提供する際に、この仮名ＩＤや発着判定フラグに基づいたサービス提供を制御することも可能になる。

サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、続いて、サービス提供画面を生成し（ステップＳ２５）、ステップＳ２４において払い出したＷｅｂセッション情報とともに、生成したサービス提供画面を情報表示端末２０に送信する（ステップＳ２６）。

すると、情報表示端末２０のＷｅｂブラウザには、サービス提供画面が表示される（ステップＳ２７）。

ところで、実施例１においては、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、ステップＳ１８におけるサービス開始要求に応じて発信側の情報表示端末２０を制御すると同時に（あるいは直ちに）、着信側の情報表示端末２０についても制御する（ステップＳ２８〜Ｓ３５）。すなわち、図２１には図示していないが、着信側の情報表示端末２０も、ステップＳ１８〜Ｓ２０と同様の処理手順によってステップＳ２８に移行する。ステップＳ２８は、発信側の情報表示端末２０について行われるステップＳ２１に対応する処理である。また、着信側の情報表示端末２０も、ステップＳ２１〜Ｓ２７と同様の処理手順、すなわちステップＳ３１〜Ｓ３５を行う結果、着信側の情報表示端末２０のＷｅｂブラウザにも、サービス提供画面が表示される。このため、発信側の情報表示端末２０および着信側の情報表示端末２０の両方が直ちにサービスを利用する状態となる。

すなわち、サービス提供サーバ２００（サービス提供制御部２３２）は、ステップＳ２４において発信側の情報表示端末に対してＷｅｂセッション情報を払い出して、発着間紐付けＩＤとともにＷｅｂセッション情報管理テーブル２２１に格納するとともに、ステップＳ３１において着信側の情報表示端末２０に対してＷｅｂセッション情報を払い出してＷｅｂセッション情報管理テーブル２２１に格納する。すると、サービス提供サーバ２００（サービス提供制御部２３２）は、ステップＳ３８において、Ｗｅｂセッション情報管理テーブル２２１に格納されている複数の発着間紐付けＩＤの内、所定の発着間紐付けＩＤ各々がサービスを連携すべきものであることを示す場合に、当該発着間紐付けＩＤ各々に対応づけて格納されているＷｅｂセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する（ステップＳ３６〜Ｓ３９）。

例えば、ステップＳ３６〜ステップＳ３９について説明すると、一方の情報表示端末２０が、ステップＳ２４において払い出されたＷｅｂセッション情報が付与されたＷｅｂ通信によって、サービス提供サーバ２００に画像データをアップロードし、他方の情報表示端末２０が、同じくステップＳ３１において払い出されたＷｅｂセッション情報が付与されたＷｅｂ通信によって、サービス提供サーバ２００にアクセスしていたとする。すると、サービス提供サーバ２００は、他方の情報表示端末２０に画像データを送信するよう、サービスを制御するので、他方の情報表示端末２０に画像データが送信され、他方の情報表示端末２０は、出力部に画像データを表示するなどする。

このように、セッション管理サーバ１００が、発信側の情報表示端末を制御すると同時に（あるいは直ちに）、着信側の情報表示端末２０についても制御する手法を説明したが、本発明はこれに限られるものではない。この他の手法として、例えば、着信側の情報表示端末２０が、自らサービスを選択し、発信側の情報表示端末２０と同様にサービス開始要求をセッション管理サーバ１００に送信したことを契機として、セッション管理サーバ１００が、着側の情報表示端末２０について制御する手法にも、本発明を同様に適用することができる。あるいは、例えば、発信側の情報表示端末２０が、セッション管理サーバ１００に対して、着信側の情報表示端末制御を行うように要求したことを契機として、セッション管理サーバ１００が、ステップＳ２８以降の処理を開始する手法にも、本発明を同様に適用することができる。

そして、図２２に示すように、サービス提供サーバ２００（サービス提供制御部２３２）は、ステップＳ２４において払い出したＷｅｂセッション情報が付与されたＷｅｂ通信によって、利用者Ａにサービスを提供する、例えば、情報表示端末２０に店舗情報などが示されたサービス画面を出力する（ステップＳ１０１）。

その後、利用者Ａ宅の情報表示端末２０に表示されるサービス画面が利用者によりクリックされると（ステップＳ１０２）、情報表示端末２０（サービス利用部２５ａ）は、３者間セッション連携要求をセッション管理サーバ１００に送信する（ステップＳ１０３）。例えば、利用者Ａ宅の情報表示端末２０は、マウスなどを介してお店の連絡先（電話番号「0333333333」）のクリックを受け付けると、３者間セッション連携要求とともに、セッション管理サーバ１００が情報表示端末２０と当該情報表示端末２０が利用するサービスとの組合せごとに発行した仮名ＩＤと、呼び出し先電話番号「0333333333」とをセッション管理サーバ１００に送信する。

すると、セッション管理サーバ１００（会議室関連制御部１３３）は、利用者Ａ宅の情報表示端末から受信した３者間セッション連携要求に付加されている仮名ＩＤが自装置が発行した仮名ＩＤであるか否かを判定する（ステップＳ１０４）。そして、セッション管理サーバ１００（会議室関連制御部１３３）は、受信した仮名ＩＤが自装置が発行した仮名ＩＤであると判定した場合、３者間セッション連携要求を送信したＨＧＷ１０（利用者Ａ）の通話相手を特定し（ステップＳ１０５）、グループＩＤを発行する（ステップＳ１０６）。

例えば、セッション管理サーバ１００（会議室関連制御部１３３）は、受信した３者間セッション連携要求に付加されている仮名ＩＤが発着間紐付けＩＤテーブル１２４に記憶されているか否かにより、自装置が発行した仮名ＩＤであるか否かを判定する。そして、セッション管理サーバ１００（会議室関連制御部１３３）は、受信した仮名ＩＤが発着間紐付けＩＤテーブル１２４に記憶されている場合、当該仮名ＩＤに対応する「制御用セッション情報」を発着間紐付けＩＤテーブル１２４から特定する。続いて、セッション管理サーバ１００（会議室関連制御部１３３）は、特定した「制御用セッション情報」に対応する「call-ID」を制御用セッション管理テーブル１２３から特定する。ここで通話のセッションを一意に特定するためのＩＤとして、たとえば「call-ID」を用いており、他にもisubなどを用いることもできる。そして、セッション管理サーバ１００（会議室関連制御部１３３）は、特定した「call-ID」を同じ「call-ID」が格納されているレコードを制御用セッション管理テーブル１２３から特定する。そうして、セッション管理サーバ１００（会議室関連制御部１３３）は、特定したレコードの「発着判定フラグ」を参照して「発着」を特定することができ、さらに、特定したレコードに発行したグループＩＤを格納する。

このようにしてグループＩＤを発行したセッション管理サーバ１００（会議室関連制御部１３３）は、例えば、ＨＴＴＰなど任意のプロトコルを用いた通信で、会議室予約要求を会議室サーバ３００に送信する（ステップＳ１０７）。このとき、セッション管理サーバ１００（会議室関連制御部１３３）は、Ｓ１０３で受信した３者間接続要求に含まれる仮名ＩＤをキーにして、発着間紐付けＩＤテーブル１２４から契約サービスＩＤを特定する。そして、セッション管理サーバ１００（会議室関連制御部１３３）は、特定した契約サービスＩＤをキーにして会議室サーバ３００のＵＲＬを会議室サービステーブル１２５から特定し、特定したＵＲＬにアクセスして会議室サーバ３００に会議室予約要求を送信する。すると、会議室サーバ３００（会議室ＩＤ発行部３３１）は、会議室管理テーブル３２１を参照し、ステータスが利用中でない会議室ＩＤを発行して、予約完了通知とともにセッション管理サーバ１００に出力する（ステップＳ１０８とステップＳ１０９）。

そして、セッション管理サーバ１００（会議室関連制御部１３３）は、ステップＳ１０６で発行したグループＩＤと、ステップＳ１０９で受信した会議室ＩＤとを対応付けて、会議室対応管理テーブル１２６に格納する（ステップＳ１１０）。その後、セッション管理サーバ１００（会議室関連制御部１３３）は、利用者Ａ宅および利用者Ｂ宅のＨＧＷ１０に通話先変更指示を送信することにより、利用者Ａ宅および利用者Ｂ宅のＨＧＷ１０は、ＳＩＰフォン３０の通話先を会議室サーバに変更し、利用者Ａ宅および利用者Ｂ宅のＳＩＰフォン３０は、会議室サーバ３００を介して接続される（ステップＳ１１１〜ステップＳ１１３）。

例えば、グループＩＤと会議室ＩＤとを対応付けて会議室対応管理テーブル１２６に格納したセッション管理サーバ１００（会議室関連制御部１３３）は、利用者Ａ宅および利用者Ｂ宅の情報表示端末２０にＨＧＷ１０へのリダイレクト通信で、callセッション情報、会議室サーバ３００の電話番号、発着間紐付けＩＤテーブル１２４から発着間紐付けＩＤなどを特定するための制御用セッション情報を送信する。そして、利用者Ａ宅および利用者Ｂ宅のＨＧＷ１０は、受信したcallセッション情報を検証する。具体的には、利用者Ａ宅および利用者Ｂ宅のＨＧＷ１０は、受信したcallセッション情報と完全一致するcallセッション情報がブラウザセッション情報管理テーブル１２ａにあるかどうか検証する。利用者Ａ宅および利用者Ｂ宅のＨＧＷは、ブラウザセッション情報管理テーブル１２ａにcallセッション情報があれば、通話中の端末（ＳＩＰフォン）を特定する。また、利用者Ａ宅および利用者Ｂ宅のＨＧＷ１０は、両者の間で接続されている通話接続の通話相手先を受信した会議室サーバ３００の電話番号へ通話先を変更するための制御指示（発呼指示）をＳＩＰフォンへ送出し、応答を受け付けると、会議室サーバ３００に発呼する。その結果、利用者Ａ宅および利用者Ｂ宅のＳＩＰフォンは、会議室サーバ３００を介して接続される。なお、ＳＩＰフォンにて接続替えを行っても良いし、ＳＩＰフォンとＨＧＷ間は音声パスを維持しつつ、ＨＧＷ１０が接続先を会議室サーバ３００に変更してもよい。

図２２に戻り、その後、利用者Ａ宅のＨＧＷ３００は、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を自ら収集することで取得し、また、発着判定フラグを取得する（ステップＳ１１４）。また、会議室サーバ３００も同様に、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を自ら収集することで取得し、また、発着判定フラグを取得する（ステップＳ１１５）。そして、利用者Ａ宅のＨＧＷ１０は、利用者Ａ宅のＳＩＰフォン３０と利用者Ｂ宅のＳＩＰフォン３０とが会議室サーバ３００を介して接続されたことを示す接続完了通知をセッション管理サーバ１００に送信する（ステップＳ１１６）。また、会議室サーバ３００も同様に、利用者Ａ宅のＳＩＰフォン３０と接続されたことを示す接続完了通知と、利用者Ｂ宅のＳＩＰフォン３０と接続されたことを示す接続完了通知とをセッション管理サーバ１００に送信する（ステップＳ１１７）。なお、利用者Ｂ宅のＨＧＷ３０についても、ｃａｌｌセッション情報と発着判定フラグとを取得して、利用者Ａ宅のＳＩＰフォン３０と利用者Ｂ宅のＳＩＰフォン３０とが会議室サーバ３００を介して接続されたことを示す接続完了通知をセッション管理サーバ１００に送信する（ステップＳ１１８）。

例えば、利用者Ａ宅のＨＧＷ１０は、ｃａｌｌセッション情報としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（自装置のＵＲＩ）』および『Ｔｏ（会議室サーバのＵＲＩ）』を、ＳＩＰによって確立された通信に含まれる情報から自ら収集することで取得する。また、利用者Ａ宅のＨＧＷ１０は、ＳＩＰフォン３０が発側であるのか着側であるのかを示す『発着判定フラグ』を、ＳＩＰによって確立された通信に含まれる情報から自ら生成する。そして、ＨＧＷ１０は、収集または取得したｃａｌｌセッション情報「Ｃａｌｌ−ＩＤ、Ｆｒｏｍ（自装置のＵＲＩ）、Ｔｏ（会議室サーバのＵＲＩ）」と「発着判定フラグ」とを対応づけて格納する。また、ＨＧＷ１０は、セッション管理サーバ１００から送信された通話先変更指示に含まれる「制御用セッション情報」と、接続完了通知とをセッション管理サーバに送信し、セッション管理サーバ１００は、ステップＳ１１６又はステップＳ１１８で各ＨＧＷ１０から受信した制御用セッション情報が、ステップＳ１１１やステップＳ１１２で各ＨＧＷ１０に送信した制御用セッション情報と一致しているか否かによって、ステップＳ１１１やステップＳ１１２で会議室サーバに通話先を変更するように指示したＨＧＷからの接続完了通知であるか否かを判定することができる。また、利用者Ｂ宅のＨＧＷについても上記した処理が実施されて、セッション管理サーバ１００から送信された通話先変更指示に含まれる「制御用セッション情報」と、収集した「callセッション情報（callセッション情報（Ｂ）」とを接続完了通知とともにセッション管理サーバ１００に送信する。なお、利用者ＡのＨＧＷ１０と会議室サーバ３００間のＳＩＰ通信と、利用者Ｂ宅のＨＧＷ１０と会議室サーバ３００間のＳＩＰ通信は、別々に接続されるＳＩＰ通信であるため、ここで取得される「Ｃａｌｌ−ＩＤ」は異なっている。

また、会議室サーバ３００については、利用者Ａ宅のＨＧＷ１０とのＳＩＰ通信、利用者Ｂ宅のＨＧＷ１０とのＳＩＰ通信のそれぞれについて、callセッション情報を取得して格納する。つまり、会議室サーバ３００は、収集または取得したｃａｌｌセッション情報「Ｃａｌｌ−ＩＤ、Ｆｒｏｍ（自装置のＵＲＩ）、Ｔｏ（利用者Ａ宅のＨＧＷのＵＲＩ）」と「発着判定フラグ」とを対応づけて格納する。さらに、会議室サーバ３００は、収集または取得したｃａｌｌセッション情報「Ｃａｌｌ−ＩＤ、Ｆｒｏｍ（自装置のＵＲＩ）、Ｔｏ（利用者Ｂ宅のＨＧＷのＵＲＩ）」と「発着判定フラグ」とを対応づけて格納する。なお、ここでのcallセッション情報の収集または取得手法については、ステップＳ５と同様であるので、ステップＳ５で説明した様々な手法を適用することができる。

図２２に戻り、利用者Ａ宅のＨＧＷ１０、利用者Ｂ宅のＨＧＷ１０、会議室サーバ３００のそれぞれから接続完了通知を受信したセッション管理サーバ１００（会議室関連制御部１３３）は、ＨＧＷ１０から受信した「制御用セッション情報」と「callセッション情報」とを対応付けるとともに、グループＩＤを付与して格納する（ステップＳ１１９）。この際、古いcallセッション情報については、通話が終了したことを示す通話終了時刻を設定する。例えば、セッション管理サーバ１００（会議室関連制御部１３３）は、利用者Ａ宅のＨＧＷから受信した「制御用セッション情報」に対応付けられた「グループＩＤ」を制御用セッション管理テーブルから特定する。そして、セッション管理サーバ１００（会議室関連制御部１３３）は、利用者Ａ宅のＨＧＷ１０から受信した「制御用セッション情報」と「callセッション情報」と、特定した「グループＩＤ」とを対応付けた情報を新たなレコードとして制御用セッション管理テーブル１２３に格納する。なお、セッション管理サーバ１００（会議室関連制御部１３３）は、利用者Ａ宅〜ＨＧＷ間の発着および利用者Ｂ宅〜ＨＧＷ間の発着のそれぞれについて、上記した処理を実施するので、制御用セッション管理テーブル１２３には、４つのレコードが新たに格納されることとなる（図５の上から３レコード目〜６レコード名）。また、発着（発信側と着信側）は、同じＳＩＰ通信で接続されることから、制御用セッション情報及びｃａｌｌセッション情報は同じ値となる。なお、ここでは、新たにレコードを追加する例について説明したが、これに限定されるものではなく、「制御用セッション情報」が同じである古い情報を上書きするようにしてもよい。

続いて、セッション管理サーバ１００（会議室関連制御部１３３）は、ステップＳ１１９で特定した「グループＩＤ」に対応する「会議室ＩＤ」を会議室対応管理テーブル１２６から特定し（ステップＳ１２０）、各装置の「callセッション情報（callセッション情報（Ａ）、callセッション情報（Ｂ））」とともに、会議室サーバ３００に通知して音声ブリッジの接続を要求する（ステップＳ１２１）。すると、会議室サーバ３００（音声ブリッジ制御部３３２）は、セッション管理サーバ１００から受信した「会議室ＩＤ」と「callセッション情報」とにより特定されるＨＧＷ１０同士の音声ブリッジ（２者間音声ブリッジ）を開始し（ステップＳ１２２）、２者間音声ブリッジ開始完了通知をセッション管理サーバ１００に通知する（ステップＳ１２３）。このとき、会議室サーバ３００は、セッション管理サーバ１００から受信した「会議室ＩＤ」と「利用者Ａ宅のＨＧＷから受信したcallセッション情報（Ａ）」、「利用者Ｂ宅のＨＧＷから受信したcallセッション情報（Ｂ）」などを対応付けて、会議用セッション情報管理テーブル３２２に格納する。

すると、３ＰＣＣサーバは、会議室サーバと利用者Ｃ宅のＨＧＷに対して接続指示（サードパーティコール指示）を送信し、会議室サーバ３００と利用者Ｃ宅のＨＧＷ１０（ＳＩＰフォン３０）がＳＩＰ通信に関する各種情報をやり取りして、会議室サーバ３００と利用者Ｃ宅のＳＩＰフォン３０とを通話接続する（ステップＳ１２５）。なお、サードパーティコールとは、端末と端末を他の第３の装置から操作して接続することであり、ここでは、セッション管理サーバ１００が会議室サーバ３００と利用者Ｃ宅のＳＩＰフォン３０とを接続する指示を３ＰＣＣサーバに対して送信する。つまり、通話接続対象である会議室サーバ３００と利用者Ｃ宅のＳＩＰフォン３０ともいずれとも異なる３ＰＣＣサーバが、会議室サーバ３００と利用者Ｃ宅のＳＩＰフォン３０とを通話接続することとなる。３ＰＣＣサーバの通話接続手法は、サードパーティコールの一般的な手法を用いることができるが、簡単に説明すると、まず、３ＰＣＣサーバは、会議室サーバに対してINVITE送信して２００ＯＫ（会議室サーバのＳＤＰ）を受信すると、会議室サーバ３００にＡＣＫを応答する。このようにして会議室サーバ３００が応答すると、３ＰＣＣサーバは、利用者Ｃ宅のＳＩＰフォン３０に対してINVITE送信して２００ＯＫ（利用者Ｃ宅のＳＩＰフォン３０のＳＤＰ）を受信すると、利用者Ｃ宅のＳＩＰフォン３０にＡＣＫを応答する。そして、３ＰＣＣサーバが、会議室サーバ３００には利用者Ｃ宅のＳＩＰフォン３０のＳＤＰを送信し、利用者Ｃ宅のＳＩＰフォン３０には会議室サーバ３００のＳＤＰを送信した結果、会議室サーバ３００と利用者Ｃ宅のＳＩＰフォン３０とを接続される。なお、これ以外にもＲＥＦＥＲなどを用いた手法がある。

そして、会議室サーバ３００（音声ブリッジ制御部３３２）は、ｃａｌｌセッション情報（Ｃ）としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（自装置のＵＲＩ）』および『Ｔｏ（会議室サーバのＵＲＩ）』を、ＳＩＰによって確立された通信に含まれる情報から自ら収集することで取得して、セッション管理サーバ１００に送信する（ステップＳ１２６）。このとき、ステップＳ１２４で通知されたＩＤ（ステップＳ１２４の要求に基づき通話が開始したことを示すＩＤ）もあわせて送信する。セッション管理サーバ１００は、このとき受信したＩＤがステップＳ１２４で発行したＩＤと一致するか否かによって、ステップＳ１２４で送信した接続指示の接続対象から送信された接続完了通知であるか否かを判定することができる。なお、ここでのcallセッション情報の収集または取得手法については、ステップＳ５と同様であるので、ステップＳ５で説明した様々な手法を適用することができる。

一方、利用者Ｃ宅のＨＧＷ１０は、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報（Ｃ）と発着判定フラグとを取得し、さらに、配下のＳＩＰフォン３０を一意に識別する情報であるＳＩＰフォンＩＤを、当該ＳＩＰ通信に含まれる情報から収集する（ステップＳ１２７）。また、利用者Ｃ宅のＨＧＷ１０は、ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する（ステップＳ１２８）。そして、利用者Ｃ宅のＨＧＷ１０は、特定された情報表示端末２０に対して、セッション管理サーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報等とともに行う（ステップＳ１２９）。このとき、ステップＳ１２４で通知されたＩＤ（ステップＳ１２４の要求に基づき通話が開始したことを示すＩＤ）もあわせて送信する。また、利用者Ｃ宅のＨＧＷ１０は、リダイレクト指示に、利用者Ｃ宅のＨＧＷ１０のＵＲＬをも含めている。セッション管理サーバ１００は、このとき受信したＩＤがステップＳ１２４で発行したＩＤと一致するか否かによって、ステップＳ１２４で送信した接続指示の接続対象から送信された接続完了通知であるか否かを判定することができる。なお、ここでのcallセッション情報の収集または取得手法については、ステップＳ５と同様であるので、ステップＳ５で説明した様々な手法を適用することができる。

このようにして、会議室サーバ３００からｃａｌｌセッション情報（Ｃ）を受信したセッション管理サーバ１００（会議室関連制御部１３３）は、ステップＳ１０と同様の手法で、ｃａｌｌセッション情報（Ｃ）等の検証を行い、ｃａｌｌセッション情報（Ｃ）等が真正な情報であることを確認すると、ステップＳ１１のように、ｃａｌｌセッション情報（Ｃ）等、ＨＧＷ１０のＵＲＬ、及び通話情報としての開始時刻を制御用セッション管理テーブル１２３に格納し、制御用セッション情報を払い出し、払い出した制御用セッション情報に対応付けてｃａｌｌセッション情報（Ｃ）「Ｃａｌｌ−ＩＤ、Ｆｒｏｍ（自装置のＵＲＩ）、Ｔｏ（会議室サーバのＵＲＩ）、発着フラグ（発）」とするＨＧＷ側のレコードと、ｃａｌｌセッション情報（Ｃ）「Ｃａｌｌ−ＩＤ、Ｆｒｏｍ（自装置のＵＲＩ）、Ｔｏ（会議室サーバのＵＲＩ）、発着フラグ（着）」とする会議室サーバ側のレコードとの２つのレコードを制御用セッション管理テーブル１２３に追加する（ステップＳ１３０）。なお、利用者Ｃ宅の情報表示端末２０からのｃａｌｌセッション情報（Ｃ）を用いて上記した処理を実行してもよい。続いて、セッション管理サーバ１００（会議室関連制御部１３３）は、追加した２レコードのｃａｌｌセッション情報（Ｃ）における「Ｔｏ（会議室サーバのＵＲＩ）」が同じレコードのグループＩＤ（group３）を、追加した２レコードのグループＩＤに追加格納することにより、利用者Ｃを利用者ＡとＢと同じグループに追加する（ステップＳ１３１）。

そして、セッション管理サーバ１００（会議室関連制御部１３３）は、ステップＳ１３１で追加格納した「グループＩＤ」に対応する「会議室ＩＤ」を会議室対応管理テーブル１２６から特定し、利用者Ｃ宅の「callセッション情報（callセッション情報（Ｃ））」と「会議室ＩＤ」とを会議室サーバ３００に音声ブリッジの接続を要求する（ステップＳ１３２）。

すると、会議室サーバ３００（音声ブリッジ制御部３３２）は、セッション管理サーバ１００から受信した「会議室ＩＤ」が一致する会議用セッション情報管理テーブル３２２に、同様に受信した利用者Ｃ宅の「callセッション情報（callセッション情報（Ｃ））」を追加格納することにより、利用者ＡとＢの音声ブリッジに利用者Ｃを追加する（ステップＳ１３３）。なお、会議室サーバ３００は、セッション管理サーバ１００から受信した「会議室ＩＤ」が一致する会議室ＩＤが会議用セッション情報管理テーブル３２２に存在しない場合には、受信した「会議室ＩＤ」と利用者Ｃ宅の「callセッション情報（callセッション情報（Ｃ））」とを用いて、これらを対応付けたレコードを会議用セッション情報管理テーブル３２２に追加格納する。このようにすることで、利用者Ａと利用者Ｂが先に通話していなくても、利用者Ｃ宅が先に接続してから、利用者Ａと利用者Ｂがその会議室に入ることにより、３者間の結び付けを行うことができる。そして、会議室サーバ３００（音声ブリッジ制御部３３２）は、３者間音声ブリッジを開始した会議室ＩＤとともに、完了通知をセッション管理サーバ１００に通知する（ステップＳ１３４）。この結果、利用者Ａ宅のＳＩＰフォン３０、利用者Ｂ宅のＳＩＰフォン３０、利用者Ｃ宅のＳＩＰフォン３０は、会議室サーバ３００を介して、３者間音声ブリッジ接続される（ステップＳ１３５）。

その後、セッション管理サーバ１００は、ステップＳ１２〜ステップＳ３５と同様の処理を行って、利用者Ｃ宅の情報表示端末２０にサービス提供画面を表示する。具体的には、セッション管理サーバ１００は、情報表示端末２０から送信されたｃａｌｌセッション情報等を受信すると、当該ｃａｌｌセッション情報（Ｃ）等の検証を行う（ステップＳ１５０）。続いて、セッション管理サーバ１００は、ステップＳ１５０における検証の結果、ｃａｌｌセッション情報（Ｃ）等が真正な情報であることを確認すると、当該ｃａｌｌセッション情報（Ｃ）等、ＨＧＷ１０のＵＲＬ、及び通話情報としての開始時刻を制御用セッション管理テーブルに格納し、制御用セッション情報を払い出し、払い出した制御用セッション情報を制御用セッション管理テーブル１２３に格納する（ステップＳ１５１）。

そして、セッション管理サーバ１００は、３者間音声ブリッジが開始された装置間（利用者Ａ宅のＳＩＰフォント利用者Ｂ宅のＳＩＰフォン）で利用されているサービスＩＤをユーザ契約サービス管理テーブル１２１で確認し、サービスＩＤを取得する（ステップＳ１５２）。また、セッション管理サーバ１００は、制御ページを生成する（ステップＳ１５３）。

続いて、セッション管理サーバ１００は、利用者Ｃ宅の情報表示端末に対して、接続先監視機能と、ステップＳ１５１で払い出した制御用セッション情報と、ステップＳ１５３で生成した制御ページと、ステップＳ１５２で取得した現在利用されているサービスＩＤとを送信する（ステップＳ１５４）。

すると、利用者Ｃ宅の情報表示端末２０は、セッション管理サーバ１００から送信された制御ページをＷｅｂブラウザから表示する（ステップＳ１５５）。そして、ステップＳ１５と同様にして利用者Ｃ宅の情報表示端末にインストールされた接続先監視機能は、制御ページが表示されると自動的に、ステップＳ１５４において送信された制御用セッション情報、利用中のサービスＩＤ、サービス開始要求をセッション管理サーバ１００に対して送信する（ステップＳ１５７）。

このサービス開始要求を受信したセッション管理サーバ１００は、利用者Ｃ宅の情報表示端末から送信された制御用セッション情報が制御用セッション管理テーブル１２３に登録されているものであることを確認し（ステップＳ１５８）、利用者Ｃ宅の情報表示端末２０から送信された制御用セッション情報に対応付けられているレコードを発着間紐付けＩＤテーブル１２４から特定し、特定したレコードに格納されている発着間紐付けＩＤと仮名ＩＤとを発着間紐付けＩＤテーブル１２４から取得し（ステップＳ１５９）、サービス提供サーバ２００のＵＲＬと、発着間紐付けＩＤと、仮名ＩＤと、発着判定フラグとに証明書を付加して、利用者Ｃ宅の情報表示端末２０の接続先監視機能に送信する（ステップＳ１６０）。

一方、利用者Ｃ宅の情報表示端末２０は、セッション管理サーバ１００から送信されたＵＲＬに接続し、セッション管理サーバ１００から送信された発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを、サービス提供サーバ２００に送信する（ステップＳ１６１）。

すると、サービス提供サーバ２００（サービス提供制御部２３２）は、利用者Ｃ宅の情報表示端末から送信された発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを受信すると、当該発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを、ステップＳ１６０で付加された証明書に基づいて検証する（ステップＳ１６２）。そして、サービス提供サーバ２００（サービス提供制御部２３２）は、ステップＳ１６２における検証の結果、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを確認すると、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを送信した利用者Ｃ宅の情報表示端末が行うＷｅｂ通信に付与する情報として、Ｗｅｂセッション情報を払い出し、Ｗｅｂセッション情報管理テーブル２２１に格納する（ステップＳ１６３）。続いて、サービス提供サーバ２００（サービス提供制御部２３２）は、受信した発着間紐付けＩＤが一致する仮名ＩＤをＷｅｂセッション情報管理テーブル２２２１から特定し、特定した仮名ＩＤによって通話先相手を特定して、サービス提供画面を生成し（ステップＳ１６４）、ステップＳ１６３において払い出したＷｅｂセッション情報とともに、生成したサービス提供画面を利用者Ｃ宅の情報表示端末２０に送信する（ステップＳ１６５）。

すると、利用者Ｃ宅の情報表示端末２０のＷｅｂブラウザには、サービス提供画面が表示される（ステップＳ１６６）。

この結果、セッション管理サーバ１００は、サービス開始要求に応じて発信側の情報表示端末を制御すると同時に（あるいは直ちに）、着信側の情報表示端末についても制御することができ、発信側の情報表示端末および着信側の情報表示端末の双方が直ちにサービスを利用する状態となる（ステップＳ１６７）。

例えば、利用者宅Ａの情報表示端末が、払い出されたＷｅｂセッション情報が付与されたＷｅｂ通信によって、サービス提供サーバ２００に画像データをアップロードする。そして、利用者Ａ宅と音声ブリッジで接続されており、同じ発着間紐付けＩＤが割り振られた利用者Ｂ宅および利用者Ｃ宅の情報表示端末２０が、同様に払い出されたＷｅｂセッション情報が付与されたＷｅｂ通信によって、サービス提供サーバ２００にアクセスしたとする。すると、サービス提供サーバ２００は、利用者Ｂ宅および利用者Ｃ宅の情報表示端末２０に画像データを送信するようにサービスを制御するので、利用者宅Ａの情報表示端末２０からアップロードされた画像データが利用者Ｂ宅および利用者Ｃ宅の情報表示端末２０に送信される。この結果、利用者Ｂ宅および利用者Ｃ宅の情報表示端末２０は、利用者宅Ａの情報表示端末２０からアップロードされた画像データをダウンロード（受信）して出力部に表示するなどできる。

このように、実施例１によれば、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することが可能になる。例えば、ＳＩＰフォンという簡単なインターフェースを用いて、一時的な通信関係で複数の利用者宅同士を接続することができる。

このように、実施例１に係るサービス提供システムにおいて、セッション管理サーバ１００は、ＳＩＰによって確立した一時的な通信関係に基づくサービス提供を実現するための発着間紐付けＩＤを発行するとともに、データの受け渡し要求を受け付けると、受け渡し要求の要求元の利用者が通話中であることを確認の上、データ受け渡しを制御する。このようなことから、ＳＩＰフォン３０と情報表示端末２０とを組で利用する利用者は、例えば、通話をしながら通話相手と連携してＷｅｂサービスを利用することが可能になり、かつ、通話の延長で容易にデータの受け渡しを行うことが可能になる。また、利用者は、セッション管理サーバ１００を信用しているならば、安心してデータの受け渡しを行うことができるようになる。

ところで、実施例１では、２者間（利用者Ａ、利用者Ｂ）が音声ブリッジされた後に会議室サーバ３００に接続し、会議室サーバ３００を経由して、新たな利用者（利用者Ｃ）を接続する例について説明してきたが、本発明はこれに限定されるものではなく、利用者Ａが会議室サーバ３００に接続した後、利用者Ｂや利用者Ｃが当該会議室サーバ３００に接続するような接続形態であっても、３者間接続を行うことができる。

（直接接続方式）
具体的には、通話接続されている利用者宅Ａのユーザが、３者間接続するための会議室番号（会議室ＩＤ）をＳＩＰフォン３０で直接選択し、選択された会議室番号の会議室を用いて３者間接続を開始することもできる。

例えば、図２５に示すように、利用者Ａ宅のＳＩＰフォン３０とセッション管理サーバ１００との間、および、会議室サーバ３００とセッション管理サーバ１００との間で、図２０のステップＳ１〜ステップＳ２７を実行後（ステップＳ５０１）、サービス提供サーバ２００は、利用者Ａ宅の情報表示端末２０に会議室番号選択画面（ＵＲＬ）を送信する（ステップＳ５０２）。

その後、利用者Ａ宅の情報表示端末２０は、サービス提供サーバ２００から送信された会議室番号選択画面（ＵＲＬ）をディスプレイなどに表示し、ユーザからの会議室番号の入力を受け付けると、選択された会議室番号をセッション管理サーバ１００に送信する（ステップＳ５０３〜ステップＳ５０５）。そして、セッション管理サーバ１００は、ユーザが選択した会議室ＩＤ（ステップＳ５０３では「５」）をキーにして、会議室対応管理テーブル１２６を参照し、ユーザが選択した会議室ＩＤに対応付けられたグループＩＤが存在するか否かをチェックする（ステップＳ５０６）。続いて、セッション管理サーバ１００は、ユーザが選択した会議室ＩＤに対応付けられたグループＩＤが会議室対応管理テーブル１２６に存在する場合には、当該グループＩＤをキーにして、制御用セッション管理テーブル１２３を参照し、当該グループＩＤに対応付けられた制御用セッション情報が存在するか否かをチェックする（ステップＳ５０７）。

このとき、セッション管理サーバ１００（会議室関連制御部１３３）は、グループＩＤに対応付けられた制御用セッション情報が存在する場合、この制御用セッション情報をキーにして発着間紐付けＩＤテーブル１２４を検索し、発着間紐付けＩＤとサービスＩＤの組を取得する。そして、セッション管理サーバ１００は、このとき取得したサービスＩＤをキーにして発着間紐付けＩＤテーブル１２４を検索し、同じサービスＩＤでステータスが使用中のサービスＩＤがある場合には、当該使用中のサービスＩＤに対応づけられた発着間紐付けＩＤを先ほど取得した発着間紐付けＩＤで上書きする。このようにすることで、同一グループＩＤのユーザは、同じサービスを利用すると同一の発着間紐付けＩＤを利用することが可能となる。一方、セッション管理サーバ１００は、グループＩＤに対応付けられた制御用セッション情報が存在しない場合、会議室対応管理テーブル１２６の会議室ＩＤに新たなグループＩＤを払い出すと同時に、払いだしたグループＩＤを制御用セッション管理テーブル１２３にも設定する。

そして、サービス提供サーバ２００は、利用者Ａ宅の情報表示端末から受信したｃａｌｌセッション情報、仮名ＩＤ、発着間紐付けＩＤ、会議室番号を含んだ音声ブリッジ接続要求を会議室サーバに送信する（ステップＳ５０８）。

会議室サーバ３００（音声ブリッジ制御部３３２）は、受信したｃａｌｌセッション情報の呼を会議室番号（会議室ＩＤ）に音声ブリッジする（ステップＳ５０９）。このとき、会議室番号によって特定される会議室スタータスが使用中となる。そして、会議室サーバ３００は、Ｓ５０９のレスポンスとして、利用者Ａ宅の情報表示端末２０から受信した仮名ＩＤ、発着間紐付けＩＤをセッション管理サーバ１００に送信する（ステップＳ５１０）。

そうして、セッション管理サーバ１００は、ステップＳ５１０の処理結果とともに、利用者Ａ宅の情報表示端末２０から受信した仮名ＩＤ、発着間紐付けＩＤを会議室サーバ３００に送信し（ステップＳ５１１）、会議室サーバ３００は、音声ブリッジ完了通知をサービス提供サーバ２００に通知する（ステップＳ５１２）。すると、サービス提供サーバ２００は、接続された会議室画面を情報表示端末に送信し（ステップＳ５１３とステップＳ５１４）、ＳＩＰによる音声通信並びにＷｅｂ通信をｃａｌｌセッション情報やＷｅｂセッション情報などに一意に区別することで、利用者Ａ宅と会議室サーバとの間を通信可能に接続する。

その後、利用者Ｂ宅とセッション管理サーバ１００の間、セッション管理サーバ１００と会議室サーバとの間、サービス提供サーバ２００と利用者Ｂ宅との間においても、ステップＳ５０１〜ステップＳ５１４までの処理が実行される（ステップＳ５１５）。すなわち、利用者Ｂ宅のＳＩＰフォン３０とセッション管理サーバ１００との間、および、会議室サーバ３００とセッション管理サーバ１００との間で、図２０のステップＳ１〜ステップＳ２７が実行され、利用者Ｂ宅の情報表示端末は、サービス提供サーバ２００から送信された会議室番号選択画面（ＵＲＬ）上で会議室番号の入力を受け付ける。その後、セッション管理サーバ１００は、グループＩＤの存在チェックや制御用セッション情報の存在チェックを実行し、会議室サーバ３００は、指定された会議室ＩＤと音声ブリッジを接続する。つまり、利用者Ｂ宅において、利用者Ａ宅と音声ブリッジされる会議室ＩＤと同じ会議室ＩＤの入力を受け付けると、利用者Ａ宅と利用者Ｂ宅とには同じグループＩＤが割り与えられる。そして、利用者Ａ宅のＳＩＰフォン３０や情報表示端末２０が音声ブリッジされている会議室にさらに、利用者Ｂ宅のＳＩＰフォン３０や情報表示端末２０が接続されることとなる。このようにすることで、利用者Ａ宅（ＳＩＰフォンや情報表示端末）と利用者Ｂ宅（ＳＩＰフォンや情報表示端末）とが会議室サーバ３００を介して接続される。

同様に、利用者Ｃ宅とセッション管理サーバ１００の間、セッション管理サーバ１００と会議室サーバ３００との間、サービス提供サーバ２００と利用者Ｃ宅との間においても、ステップＳ５０１〜ステップＳ５１４までの処理が実行される（ステップＳ５１６）。すなわち、利用者Ｃ宅のＳＩＰフォンとセッション管理サーバ１００との間、および、会議室サーバ３００とセッション管理サーバ１００との間で、図２０のステップＳ１〜ステップＳ２７が実行され、利用者Ｃ宅の情報表示端末２０は、サービス提供サーバ２００から送信された会議室番号選択画面（ＵＲＬ）上で会議室番号の入力を受け付ける。その後、セッション管理サーバ１００は、グループＩＤの存在チェックや制御用セッション情報の存在チェックを実行し、会議室サーバ３００は、指定された会議室ＩＤと音声ブリッジを接続する。つまり、利用者Ｃ宅において、利用者Ａ宅や利用者Ｂ宅と音声ブリッジされる会議室ＩＤと同じ会議室ＩＤの入力を受け付けると、利用者Ａ宅と利用者Ｂ宅と利用者Ｃ宅とには同じグループＩＤが割り与えられる。そして、利用者Ｃ宅のＳＩＰフォンや情報表示端末２０が音声ブリッジされている会議室にさらに、利用者Ａ宅や利用者Ｂ宅のＳＩＰフォン３０や情報表示端末２０が接続されることとなる。このようにすることで、利用者Ａ宅（ＳＩＰフォン３０や情報表示端末２０）と、利用者Ｂ宅（ＳＩＰフォン３０や情報表示端末２０）と、利用者Ｃ宅（ＳＩＰフォン３０や情報表示端末２０）とが会議室サーバ３００を介して接続される。上記処理の結果、利用者Ａ宅〜利用者Ｂ宅〜利用者Ｃ宅との間で、図２４のステップＳ１６７と同様の処理が実行できることとなる（ステップＳ５１７）。

さて、これまで本発明の実施例について説明してきたが、本発明は上述してきた実施例以外にも種々の異なる形態にて実施されてよいものである。そこで、実施例３では、以下に示すように、種々の異なる実施例について説明する。

（Ｎ者間接続）
また、実施例１では、３者間接続を行う例について説明したが、本願はこれに限定されるものではなく、４者間、５者間・・・Ｎ者間でも、上記した手法と同様の手法を用いることで接続することができる。

（セッション管理機能）
上記実施例においては、『セッション連携機能』が、ＳＩＰプロキシやサービス提供サーバとは物理的に異なるセッション管理サーバに備えられている事例を説明してきたが、本発明はこれに限られるものではない。『セッション連携機能』が、ＳＩＰプロキシに備えられている事例にも、あるいは、サービス提供サーバに備えられている事例などにも、本発明を同様に適用することができる。

（接続先監視機能）
上記実施例においては、情報表示端末が、汎用的なＷｅｂブラウザを備え、『接続先監視機能』として、当該Ｗｅｂブラウザ上で動作するＪａｖａ（登録商標）Ｓｃｒｉｐｔファイルを備える手法（セッション管理サーバから送信されることで『接続先監視機能』を備える手法）を説明してきたが、本発明はこれに限られるものではない。情報表示端末が、専用アプリケーションを備え、当該専用アプリケーションが、予め『接続先監視機能』を備えている手法などにも、本発明を同様に適用することができる。

（発着間紐付けＩＤ）
上記実施例においては、サービス提供サーバがＷｅｂサービスを互いに関連づけて制御する際に用いる「発着間紐付けＩＤ」として、セッション管理サーバが新たに発行した発着間紐付けＩＤを用いる手法を説明してきたが、本発明はこれに限られるものではない。呼情報であるｃａｌｌセッション情報そのもの（例えば、Call-IDなど）を流用する手法にも、本発明を同様に適用することができる。すなわち、「発着間紐付けＩＤ」は、サービス提供サーバが、複数の端末に対してＷｅｂサービスを互いに関連づけて提供する際に、当該複数の端末各々がＳＩＰによって通信を確立した端末同士であることを認識可能な情報であればよい。

（署名付証明書）
上記実施例においては、ＳＩＰプロキシやセッション管理サーバが他の装置に情報を送信する際、自装置の署名付証明書を発行し、当該署名付証明書を添付した検証可能な形式で当該情報を送信する手法を説明してきたが、本発明はこれに限られるものではない。署名付証明書を添付することなく、単に情報をそのまま送信する手法にも、本発明を同様に適用することができる。なお、この場合には、情報を受信した側における当該情報の検証も不要となる。

（ポーリング）
上記実施例においては、情報表示端末とＨＧＷとの間、情報表示端末とセッション管理サーバとの間などで、適宜ポーリングを用いて通信を行う手法を説明してきたが、本発明はこれに限られるものではなく、ポーリングの替わりにプッシュ型やプル型の通信であってもよい（この場合には、必要な時のみアクセスすればよいことになる）。

（端末側の構成）
また、本発明に係るサービス提供システムは、上記実施例で例示した構成に限られるものではない。すなわち、本発明に係るサービス提供システムは、まず、端末側の構成という点で、端末側にＨＧＷが設置されているか否か、端末が、ＳＩＰフォンと情報表示端末との分離型であるか、ＳＩＰフォン機能と情報表示機能との一体型であるか、といった選択肢がある。また、どの装置がcallセッション情報を収集するかという点で、ＳＩＰプロキシがcallセッション情報を収集するか、ＨＧＷがｃａｌｌセッション情報を収集するか、端末（ＳＩＰフォン、もしくは、ＳＩＰフォン機能）がｃａｌｌセッション情報を収集するか、といった選択肢がある。また、ＳＩＰプロキシが収集したｃａｌｌセッション情報を誰に送信するかという点で、ＨＧＷに送信するか、端末（ＳＩＰフォン、もしくは、ＳＩＰフォン機能）に送信するか、といった選択肢がある。その他、発信側の構成と着信側の構成とが同一であるか、異なるか、といった選択肢や、情報表示端末がＨＧＷの配下の端末として接続しているか否かといった選択肢もある。上記実施例は、これらの選択肢の内、一部の組み合わせを示したに過ぎず、本発明はこれらの構成に限られるものではない。すなわち、上記してきた手法や公知の手法を用いることで、その他の構成についても、本発明を同様に実現することができる。

（ＳＩＰプロキシ）
また、上記の実施例においては、単一のＳＩＰプロキシがＳＩＰ信号（ＳＩＰの具体的な信号、INVITE、200 OKなどの種類、および、From、Toなどのパラメータを含む）を仲介する事例を説明してきたが、本発明はこれに限られるものではない。複数のＳＩＰプロキシがＳＩＰ信号を仲介する事例や、ＮＧＮ（Next Generation Network）におけるＡＳ（Application Server）などがＳＩＰ信号を仲介する事例にも、本発明を同様に適用することができる。

（システム構成等）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

なお、本実施例で説明したサービス提供方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

以上のように、本発明に係るサービス提供システムは、ネットワーク上のサービスを端末に提供することに有用であり、特に、通信相手との関係が一時的な場合に、このような一時的な通信関係に基づいてサービスを制御することに適する。

１００ セッション管理サーバ
１１０ 通信制御Ｉ／Ｆ部
１２０ 記憶部
１２１ ユーザ契約サービス管理テーブル
１２２ 契約サービス情報テーブル
１２３ 制御用セッション管理テーブル
１２４ 発着間紐付けＩＤテーブル
１２５ 会議室サービステーブル
１２６ 会議室対応管理テーブル
１２７ データテーブル
１３０ 制御部
１３１ ｃａｌｌセッション情報収集部
１３２ 発着間紐付けＩＤ発行部
１３３ 会議室関連制御部
１３４ 受け渡し要求判定部
１３５ データ受け渡し制御部
２００ サービス提供サーバ
２１０ 通信部
２２０ 記憶部
２２１ Ｗｅｂセッション情報管理テーブル
２２２ データテーブル
２３０ 制御部
２３１ 発着間紐付けＩＤ収集部
２３２ サービス提供制御部
２３３ データ受け渡し部
３００ 会議室サーバ
３１０ 通信制御Ｉ／Ｆ部
３２０ 記憶部
３２１ 会議室管理テーブル
３２２ 会議用セッション情報管理テーブル
３３０ 制御部
３３１ 会議室ＩＤ発行部
３３２ 音声ブリッジ制御部
１０ ＨＧＷ
１１ ＳＩＰ通信部／ＨＴＴＰ通信部
１２ 記憶部
１２ａ ブラウザセッション情報管理テーブル
１３ 制御部
１３ａ サービス利用制御部
１３ｂ データ受け渡し部
２０ 情報表示端末
２１ ＨＴＴＰ通信部
２２ 入力部
２３ 出力部
２４ 入出力制御Ｉ／Ｆ部
２５ 制御部
２５ａ サービス利用部
２５ｂ 受け渡し要求部
３０ ＳＩＰフォン
３１ ＳＩＰ通信部
３２ 入力部
３３ 出力部
３４ 入出力制御Ｉ／Ｆ部

Claims (3)

1. ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供システムであって、
   前記サービス提供装置は、
   前記サービスを利用することを要求する利用要求を前記複数の端末の内のいずれか一つの端末から受け付けた際に、当該端末と組で利用され第１の通信を確立する第１通信端末と、他の第１通信端末との間で確立された第１の通信を一意に識別する第１通信情報を取得する第１通信情報取得手段と、
   前記利用要求を送信した前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手段によって取得された第１通信情報に対応づけて第２通信情報記憶手段に格納する第２通信情報格納手段と、
   前記第２通信情報記憶手段に格納されている複数の第１通信情報の内、いずれか二つの第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶手段に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御手段と、
   前記サービス提供制御手段によってサービスが提供される複数の端末の内のいずれか一つの端末から前記複数の端末のいずれとも異なる他の端末への接続要求を受信した場合に、当該接続要求を送信した端末と組で利用される第１通信端末が利用する第１通信情報を用いて、前記サービス提供される複数の端末各々と組で利用される第１通信端末各々と、前記他の端末と組で利用される他の第１通信端末とを接続する通信接続手段と、
   前記通信接続手段によって第１通信端末各々が接続されると、前記第１通信端末各々が利用する第１通信情報に対応付けて前記第２通信情報記憶手段に記憶される第２通信情報を、前記他の端末と組で利用される前記接続要求先の他の端末に対して割り与える第２通信情報割り与え手段と、
   を備えたことを特徴とするサービス提供システム。
2. 前記サービス提供装置のサービス提供制御手段は、前記第２通信情報割り与え手段によって第２通信情報が割り与えられた前記他の端末に対しても、前記第１通信情報各々に対応づけて前記第２通信情報記憶手段に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御することを特徴とする請求項１に記載のサービス提供システム。
3. ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供装置に適したサービス提供方法であって、
   前記サービスを利用することを要求する利用要求を前記複数の端末の内のいずれか一つの端末から受け付けた際に、当該端末と組で利用され第１の通信を確立する第１通信端末と、他の第１通信端末との間で確立された第１の通信を一意に識別する第１通信情報を取得する第１通信情報取得工程と、
   前記利用要求を送信した前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得工程によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納工程と、
   前記第２通信情報記憶部に格納されている複数の第１通信情報の内、いずれか二つの第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御工程と、
   前記サービス提供制御工程によってサービスが提供される複数の端末の内のいずれか一つの端末から前記複数の端末のいずれとも異なる他の端末への接続要求を受信した場合に、当該接続要求を送信した端末と組で利用される第１通信端末が利用する第１通信情報を用いて、前記サービス提供される複数の端末各々と組で利用される第１通信端末各々と、前記他の端末と組で利用される他の第１通信端末とを接続する通信接続工程と、
   前記通信接続工程によって第１通信端末各々が接続されると、前記第１通信端末各々が利用する第１通信情報に対応付けて前記第２通信情報記憶部に記憶される第２通信情報を、前記他の端末と組で利用される前記接続要求先の他の端末に対して割り与える第２通信情報割り与え工程と、
   を含んだことを特徴とするサービス提供方法。

Images