JP4768761B2

JP4768761B2 - サービス提供システム、サービス提供方法およびサービス提供プログラム

Info

Publication number: JP4768761B2
Application number: JP2008027009A
Authority: JP
Inventors: 幸司村上; 将司外山; 欣子末田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2008-02-06
Filing date: 2008-02-06
Publication date: 2011-09-07
Anticipated expiration: 2028-02-06
Also published as: JP2009187323A

Description

この発明は、サービス提供システム、サービス提供方法およびサービス提供プログラムに関する。

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

ＩＭサービスについて、図３１を用いて簡単に例示すると、端末各々は、ＩＭサービスの提供を受けるにあたり、まず、ＩＭサービスに対応する専用アプリケーションを当該端末内にインストールする。また、サービス提供サーバは、当該端末各々を利用する会員の会員ＩＤを、会員リストに登録する。さらに、端末各々は、チャットや画像データの共有を実現したい他の会員が利用する端末との間で互いの会員ＩＤを交換し、専用アプリケーションのバディリスト（友人リスト）に登録する。例えば、会員Ａが利用する端末が、会員Ｂをバディリストに登録すると、当該登録を許可するか否かの確認がサービス提供サーバから会員Ｂが利用する端末に対して送信され、会員Ｂが利用する端末が、登録を許可するとともに会員Ａをバディリストに登録する。すると、サービス提供サーバは、会員Ａと会員Ｂとのバディ関係に基づいて、会員Ａが利用する端末と会員Ｂが利用する端末との間でチャットや画像データの共有を実現するよう、サービスを制御する。

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

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

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

すなわち、まず、従来のＩＭサービスの課題として、次の３点が挙げられる。１点目としては、専用アプリケーションに関する課題である。一般的なＩＭサービスでは、異なるアプリケーション間でサービスを利用する仕組みが考慮されていないことから、利用者同士でサービスを受けるには、双方で、同種の専用アプリケーションをインストールしなければならない。２点目としては、バディリストの管理に関する課題である。上記したように、ＩＭサービスを受けるにはバディリストの登録が必要となるが、バディリストはアプリケーションごとに管理されていることから、他のアプリケーションを利用する際には再度バディリストの登録が必要となり、利用者にとって手間となってしまう。３点目としては、一時的な関係に関する課題である。例えば、利用者同士で一時的にファイルを共有したいなど、利用者同士の関係が一時的な場合（アドホックに変化する関係の場合）にサービスを受けたいとしても、バディリストを介することでしかサービスを受けることができない従来のＩＭサービスでは対応することができない。

この点、特許文献１に開示されている技術によっても、少なくとも１点目および３点目の課題は依然として解決されない。また、特許文献２に開示されている技術によっても、少なくとも２点目および３点目の課題は依然として解決されない。結局、上記した従来の技術のいずれによっても、少なくとも３点目の課題を解決することができない。

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

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

また、本発明は、上記の発明において、前記サービス提供システムは、前記第１の通信を確立した端末と組で利用される端末を示す第１の端末情報、および／または、当該第１の通信を確立した他方の端末と組で利用される他方の端末を示す第２の端末情報に応じて、当該第１の端末情報で示される端末および／または当該第２の端末情報で示される端末が利用可能なサービスを記憶する利用可能サービス記憶手段をさらに備え、前記接続先制御手段は、前記開始要求を前記第１の端末情報および／または前記第２の端末情報とともに受け付けると、当該第１の端末情報および／または当該第２の端末情報に基づいて前記利用可能サービス記憶手段から所定の接続先を判定し、当該所定の接続先に接続するように、前記第１の端末情報で示される端末および／または前記第２の端末情報で示される端末の接続先を制御することを特徴とする。

また、本発明は、上記の発明において、前記接続先制御手段は、前記開始要求を前記第１の端末情報および／または前記第２の端末情報とともに受け付ける際に、前記第１の端末の前記ネットワーク上でのアドレスを示す第１端末アドレスおよび／または前記第２の端末の前記ネットワーク上でのアドレスを示す第２端末アドレスを取得し、当該第１端末アドレスを用いて当該第１の端末情報が正しい情報であるか否かを検証、および／または、当該第２端末アドレスを用いて当該第２の端末情報が正しい情報であるか否かを検証し、検証の結果、正しい情報であるとされる当該第１の端末情報および／または当該第２の端末情報に基づいて、前記接続先を制御することを特徴とする。

また、本発明は、上記の発明において、前記利用可能サービス記憶手段は、前記第１の端末情報および／または前記第２の端末情報の他に、当該第１の端末情報で示される端末および／または当該第２の端末情報で示される端末が、前記第１の通信を発信した発側の端末であるのか、もしくは、前記第１の通信を着信した着側の端末であるのかを識別する発着フラグにも応じて、前記利用可能なサービスを記憶し、前記接続先制御手段は、前記開始要求を前記第１の端末情報および／または前記第２の端末情報の他に前記発着フラグもともに受け付けると、当該第１の端末情報および／または当該第２の端末情報の他に当該発着フラグにも基づいて所定の接続先を判定し、前記接続先を制御することを特徴とする。

また、本発明は、上記の発明において、前記利用可能サービス記憶手段は、前記利用可能なサービス各々が、着信と同時に前記端末をサービス提供装置に接続させてサービスを開始すべきコールセンタタイプサービスであるのか、もしくは、サービスの開始に先立ち前記端末の出力部にサービス選択画面を出力させるべきポータルタイプサービスであるのかを識別する着信同時接続フラグにも応じて、前記利用可能なサービスを記憶し、前記接続先制御手段は、前記第１の端末情報および／または前記第２の端末情報の他に前記着信同時接続フラグにも基づいて所定の接続先を判定し、前記接続先を制御することを特徴とする。

また、本発明は、上記の発明において、前記利用可能サービス記憶手段は、前記利用可能なサービス各々が、第１の通信を発信した発側の端末を接続させるべき接続先情報と当該第１の通信を着信した着側の端末を接続させるべき接続先情報とを同一の情報で提供するものであるのか、もしくは、異なる情報で提供するものであるのか、もしくは、前記端末がサービスの加入者であるのか未加入者であるのかによって異なる情報で提供するものであるのかを識別する接続タイプにも応じて、前記利用可能なサービスを記憶し、前記接続先制御手段は、前記第１の端末情報および／または前記第２の端末情報の他に前記接続タイプにも基づいて所定の接続先を判定し、前記接続先を制御することを特徴とする。

また、本発明は、上記の発明において、前記接続先制御手段は、前記開始要求を前記第１の通信を一意に識別する第１通信識別情報とともに受け付けた場合には、当該第１通信識別情報の仮名として前記第１通信情報を払い出し、当該第１通信情報を前記制御情報とともに前記端末に送信することで、当該端末の接続先を制御することを特徴とする。

また、本発明は、上記の発明において、前記サービス提供システムは、前記端末の接続が許容される許容接続先を記憶する許容接続先記憶手段をさらに備え、前記端末は、当該端末が現に接続している接続先情報を取得し、当該接続先情報を前記接続先制御手段に送信する接続先情報送信手段をさらに備え、前記接続先制御手段は、前記接続先情報送信手段によって送信された接続先情報が、前記許容接続先記憶手段によって記憶されている許容接続先に該当するか否かを判定し、該当しない場合には、許容されていない接続先に接続していることを警告する警告情報を前記端末に送信することで、当該端末の接続先をさらに制御することを特徴とする。

また、本発明は、上記の発明において、前記サービス提供システムは、前記端末が現に接続している接続先情報および／または当該端末が現に利用しているサービスを示すサービス情報を記憶する利用サービス記憶手段と、前記サービス提供装置が提供するサービス各々の競合関係を示す競合情報を記憶する競合情報記憶手段とをさらに備え、前記接続先制御手段は、現に利用しているサービスとは異なるサービスを利用することを要求する変更要求を前記端末から受け付けると、前記利用サービス記憶手段によって記憶されている接続先情報および／またはサービス情報に基づいて当該端末が現に利用しているサービスを判定し、当該サービスと当該変更要求で指定されたサービスとが競合関係にあるか否かを前記競合情報記憶手段によって記憶されている競合情報に基づいて判定し、当該判定に基づいて当該端末の接続先をさらに制御し、前記端末は、前記変更要求を前記接続先制御手段に送信する変更要求送信手段をさらに備えたことを特徴とする。

また、本発明は、上記の発明において、前記接続先制御手段は、前記サービス提供装置によって互いに関連づけて制御されている他方の端末の出力部に出力されている画面情報を変更させることを要求する変更要求を、当該他方の端末が変更にあたって接続すべき接続先を示す変更用接続先情報とともに前記端末から受け付けると、当該変更用接続先情報で示される所定の接続先に接続するように制御する制御情報を当該他方の端末に送信することで、当該他方の端末の接続先をさらに制御し、前記端末は、前記変更要求を前記変更用接続先情報とともに前記接続先制御手段に送信する変更要求送信手段をさらに備え、前記サービス提供装置は、前記変更要求を一方の端末から受け付けると、前記変更用接続先情報を当該一方の端末に送信する変更用接続先情報送信手段をさらに備え、前記サービス提供制御手段は、前記変更用接続先情報によって示される接続先に前記他方の端末から接続されると、当該他方の端末の出力部に出力されている画面情報を変更させるようにさらに制御することを特徴とする。

また、本発明は、上記の発明において、前記接続先制御手段は、前記第１の通信が切断されたことを示す切断情報を当該第１の通信を制御する第１通信制御装置から受け付けると、現に接続している接続先であるサービス提供装置が提供するサービスの利用を終了するように接続先を変更する制御情報を当該第１の通信を確立した端末と組で利用される端末に送信することで、当該端末の接続先をさらに制御することを特徴とする。

また、本発明は、ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供方法であって、前記サービスを開始することを要求する開始要求を前記端末から受け付けると、所定の接続先に接続するように当該端末を制御する制御情報を当該端末に送信することで、当該端末の接続先を制御する接続先制御工程を含み、前記端末は、前記接続先制御工程によって送信された制御情報に制御されることで所定の接続先であるサービス提供装置に接続し、当該サービス提供装置が提供するサービスを利用することを要求する利用要求を当該サービス提供装置に送信する利用要求送信工程を含み、前記サービス提供装置は、前記利用要求を前記端末から受け付けた際に、当該端末と組で利用される他の端末が第１の通信を確立したことを示す第１通信情報を取得する第１通信情報取得工程と、前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得工程によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納工程と、前記第２通信情報記憶部に格納されている複数の第１通信情報の内、所定の第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御工程と、を含んだことを特徴とする。

また、本発明は、ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供方法をコンピュータに実行させるサービス提供プログラムであって、前記サービスを開始することを要求する開始要求を前記端末から受け付けると、所定の接続先に接続するように当該端末を制御する制御情報を当該端末に送信することで、当該端末の接続先を制御する接続先制御手順をコンピュータに実行させ、前記接続先制御手順によって送信された制御情報に制御されることで所定の接続先であるサービス提供装置に接続し、当該サービス提供装置が提供するサービスを利用することを要求する利用要求を当該サービス提供装置に送信する利用要求送信手順を前記端末としてのコンピュータに実行させ、前記利用要求を前記端末から受け付けた際に、当該端末と組で利用される他の端末が第１の通信を確立したことを示す第１通信情報を取得する第１通信情報取得手順と、前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手順によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納手順と、前記第２通信情報記憶部に格納されている複数の第１通信情報の内、所定の第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御手順と、を前記サービス提供装置としてのコンピュータに実行させることを特徴とする。

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

本発明によれば、一時的な通信関係に基づいたサービス提供を実現する際に、端末の接続先を制御して一元管理することが可能になる。

また、本発明によれば、端末情報に基づいて、端末の接続先を制御することも可能になる。

また、本発明によれば、正しい情報であると検証された端末情報に基づいて端末の接続先を制御するので、セキュリティを向上させつつ、端末の接続先を制御することも可能になる。

また、本発明によれば、発側の端末であるのか着側の端末であるのかの識別に基づいて、端末の接続先を制御することも可能になる。

また、本発明によれば、サービスが、コールセンタタイプであるのかポータルタイプであるのかの識別に基づいて、端末の接続先を制御することも可能になる。

また、本発明によれば、サービスが、発側の端末と着側の端末とに同一の接続先情報で提供するものであるのか、異なる接続先情報で提供するものであるのか、加入者であるのか未加入者であるのかによって異なる接続先情報で提供するものであるのかの識別に基づいて、端末の接続先を制御することも可能になる。

また、本発明によれば、仮名としての第１通信情報を払い出した上で端末の接続先を制御して一元管理するので、セキュリティを向上させつつ、一時的な通信関係に基づいたサービス提供を実現することも可能になる。

また、本発明によれば、端末の利用者は、接続先について意識する必要が無くなる。

また、本発明によれば、一方の端末の利用者によるリクエストによって、他方の端末のサービスを切り替えることも可能になる。また、サービスを切り替える際に、サービスの競合を考慮して切り替えることも可能になる。

また、本発明によれば、一方の端末が他方の端末の画面を変更させることも可能になる。

また、本発明によれば、第１の通信と第２の通信とを連携させることも可能になる。

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

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

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

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

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

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

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

［実施例１に係るサービス提供システムの概要および特徴］
実施例１に係るサービス提供システムは、ネットワークに接続される複数の情報表示端末に当該ネットワーク上のサービスを提供するサービス提供サーバが、当該サービスを制御することを概要とし、一時的な通信関係に基づいたサービス提供を実現する際に、端末の接続先を制御して一元管理することを主たる特徴とする。

この主たる特徴について、図１を用いて説明する。図１は、実施例１に係るサービス提供システムの概要および特徴を説明するための図である。図１に例示するサービス提供システムは、端末側の構成が、ＳＩＰ（Session Initiation Protocol）フォンと、当該ＳＩＰフォンと組で利用される情報表示端末とに分かれている構成において、ＳＩＰによって通信を確立した通信相手のように、通信相手との関係が一時的な場合にも、サービス提供サーバが、このような一時的な通信関係に基づいたサービスを情報表示端末に提供するものである。ここで、ＳＩＰフォンとは、ＳＩＰによって通信を確立する端末（なお、確立したセッションを用いた通信も行う）のことであり、情報表示端末とは、ＨＴＴＰ（HyperText Transfer Protocol）通信を行う端末のことである。

また、サービス提供システムにおいて、端末側のネットワークには、ＨＧＷが設置される。図１では、ＨＧＷとＳＩＰフォンと情報表示端末との接続関係を明示していないが、ＨＧＷの配下にＳＩＰフォンと情報表示端末とが接続される関係であり、また、ＨＧＷは、ＳＩＰフォンによるＳＩＰ通信と、情報表示端末によるＨＴＴＰ通信とをともに制御する装置である。すなわち、ＳＩＰフォンによるＳＩＰ通信も、情報表示端末によるＨＴＴＰ通信も、いずれもＨＧＷを経由してネットワークに接続される構成である。なお、以下では、ＳＩＰによってセッションが確立される過程を適宜『ＳＩＰ通信』と表現する（すなわち、『ＳＩＰ通信』は、ＳＩＰによって確立されたセッションそのものの通信（例えば、エンドユーザ間の音声パスやＶＰＮ（Virtual Private Network）など）を意味するものではない）。

一方、サービス提供システムにおいて、網側には、ＳＩＰプロキシとセッション管理サーバとサービス提供サーバとが設置される。ＳＩＰプロキシは、ＳＩＰによってセッションが確立される過程や、ＳＩＰによって確立されたセッションそのものの通信を制御する装置である。また、セッション管理サーバは、後述するように、情報表示端末の接続先を制御する装置である。また、サービス提供サーバは、情報表示端末にサービスを提供する装置である。

図１に示すように、実施例１に係るサービス提供システムにおいて、ＳＩＰフォンとＳＩＰフォンとの間でＳＩＰによって通信が確立される（図１の（１）を参照）。

続いて、通信を確立したＳＩＰフォンと組で利用される情報表示端末が、サービスを開始することを要求する開始要求をセッション管理サーバに送信する（図１の（２）を参照）。

すると、セッション管理サーバは、開始要求を送信してきた情報表示端末を所定の接続先に制御するように当該情報表示端末を制御する制御ページを生成する（図１の（３）を参照）。

そして、セッション管理サーバは、生成した制御ページを情報表示端末に送信することで、当該情報表示端末の接続先を制御する。すなわち、情報表示端末は、セッション管理サーバから送信された制御ページに制御されることで、所定の接続先であるサービス提供サーバに接続し、当該サービス提供サーバが提供するサービスを利用することを要求する利用要求を当該サービス提供サーバに送信する（図１の（４）を参照）。

この時、サービス提供サーバは、当該情報表示端末と組で利用されるＳＩＰフォンがＳＩＰによってセッションを確立したことを示す発着間紐付けＩＤを取得する。また、サービス提供サーバは、情報表示端末がサービスを利用する際に必要なWebセッション情報を、取得した発着間紐付けＩＤに対応づけて記憶部に格納する。

そして、サービス提供サーバは、複数の情報表示端末から送信された複数の発着間紐付けＩＤの内、所定の発着間紐付けＩＤ各々が同一のセッションとして確立されたものであることを示す場合に、当該発着間紐付けＩＤ各々と対応づけて記憶部に格納されているWebセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する。

このように、実施例１に係るサービス提供システムにおいて、情報表示端末は、セッション管理サーバによって制御されることでサービス提供サーバにアクセスするので、一時的な通信関係に基づいたサービス提供を実現する際に、情報表示端末の接続先を制御して一元管理することが可能になる。

［実施例１に係るサービス提供システムの構成］
次に、図２〜図１４を用いて、実施例１に係るサービス提供システムの構成を説明する。図２は、セッション管理サーバの構成を示すブロック図であり、図３は、ユーザ契約サービス管理テーブルを説明するための図であり、図４は、契約サービス情報テーブルを説明するための図であり、図５は、競合サービス管理テーブルを説明するための図であり、図６は、制御用セッション管理テーブルを説明するための図であり、図７は、アクセス中サービス管理テーブルを説明するための図であり、図８は、発着間紐付けＩＤテーブルを説明するための図であり、図９は、アクセス許容ＵＲＬテーブルを説明するための図であり、図１０は、ＳＩＰプロキシの構成を示すブロック図であり、図１１は、サービス提供サーバの構成を示すブロック図であり、図１２は、Webセッション情報管理テーブルを説明するための図であり、図１３は、端末側の構成を説明するための図であり、図１４は、ブラウザセッション情報管理テーブルを説明するための図である。

［セッション管理サーバ］
セッション管理サーバ１００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図２に示すように、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

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

記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図２に示すように、ユーザ契約サービス管理テーブル１２１と、契約サービス情報テーブル１２２と、競合サービス管理テーブル１２３と、制御用セッション管理テーブル１２４と、アクセス中サービス管理テーブル１２５と、発着間紐付けＩＤテーブル１２６と、アクセス許容ＵＲＬテーブル１２７とを備える。

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

ここで、ユーザ特定情報とは、情報表示端末５５０の利用者（ユーザ）を特定するための情報であり、実施例１においては、ＳＩＰ−ＵＲＩ（Uniform Resource Identifier）を用いている。また、契約サービスＩＤとは、サービスを識別するＩＤである。このように、ユーザ契約サービス管理テーブル１２１は、ユーザ特定情報と契約サービスＩＤとを対応づけて記憶することで、ユーザ特定情報で特定される利用者が、契約サービスＩＤで識別されるサービスの加入者であることを管理している。なお、ユーザ契約サービス管理テーブル１２１が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

契約サービス情報テーブル１２２は、契約サービス各々について、各種情報を管理するテーブルである。例えば、契約サービス情報テーブル１２２は、図４に示すように、契約サービスＩＤとサービスＴｙｐｅと着信同時接続フラグと接続Ｔｙｐｅとアクセス先ＵＲＬと着側ＵＲＬと優先度とを対応づけて記憶する。契約サービス情報テーブル１２２が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。

ここで、サービスＴｙｐｅとは、契約サービスＩＤで識別されるサービスが、発側ユーザもしくは着側ユーザのどちらかが加入中であれば利用できるサービスであるか、発側ユーザおよび着側ユーザの両方が加入中でないと利用できないサービスであるか、あるいは、発側ユーザもしくは着側ユーザのどちらかが加入中であれば利用できるが、加入者しか起動できないサービスであるかを示すものである。また、着信同時接続フラグとは、契約サービスＩＤで識別されるサービスが、コールセンタタイプ（着信と同時にサービスを開始するタイプ）のサービスであるか、ポータルタイプ（着信時にはサービス選択画面を表示するタイプ）のサービスであるかを示すフラグである。また、接続Ｔｙｐｅとは、発側ユーザおよび着側ユーザに接続先として同じＵＲＬを提示するサービスであるか、異なるＵＲＬを提示するサービスであるか、あるいは、加入者と未加入者とで異なるＵＲＬを提示するサービスであるかを示すものである。言い換えると、発側と着側とで異なるＵＲＬに接続することを可能にするための情報である。また、優先度とは、契約サービスＩＤで識別されるサービスの優先度を示すものである。このように、契約サービス情報テーブル１２２は、契約サービスＩＤに対応づけて各種情報を記憶することで、契約サービスＩＤで識別されるサービスに関する各種情報を管理している。なお、契約サービス情報テーブル１２２が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

競合サービス管理テーブル１２３は、サービス各々の競合関係を管理するテーブルである。例えば、競合サービス管理テーブル１２３は、図５に示すように、競合関係にあるサービスを一つのグループとして記憶している。競合サービス管理テーブル１２３が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。ここで、例えば、『1114,*』とあるのは、『1114』で識別されるサービスが、全てのサービスと排他的であることを示すものである。なお、競合サービス管理テーブル１２３が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

制御用セッション管理テーブル１２４は、制御用セッション情報（セッション管理サーバ１００が情報表示端末５５０との間で通信を行うために、当該情報表示端末５５０のＷｅｂブラウザに対して付与する情報）を管理するテーブルである。例えば、制御用セッション管理テーブル１２４は、図６に示すように、制御用セッション情報と、Call-IDと、Fromと、Toと、発着判定フラグと、開始時刻と、終了時刻と、ＨＧＷのＵＲＬと、ＩＰアドレスとを対応づけて記憶している。制御用セッション管理テーブル１２４が記憶するこれらの情報の内、制御用セッション情報は、セッション管理サーバ１００が情報表示端末５５０からサービス開始要求を受け付けた際に払い出したものである。また、Call-IDと、Fromと、Toと、発着判定フラグと、ＨＧＷのＵＲＬとは、情報表示端末５５０からサービス開始要求を受け付けた際に当該情報表示端末５５０から取得し、登録したものである。また、開始時刻は、当該サービス開始要求を受け付けた際の時刻を登録するなどしたものである（情報表示端末５５０から開始時刻を取得してもよい）。また、終了時刻は、セッション管理サーバ１００がセッションの切断時刻を把握した際に登録し得るものである。また、ＩＰアドレスは、情報表示端末５５０のＩＰアドレスを収集して取得したものである。なお、当該ＩＰアドレスは、情報表示端末５５０の認証に用いることができる。

このように、制御用セッション管理テーブル１２４は、セッション管理サーバ１００が払い出した制御用セッション情報に対応づけて、ＳＩＰフォン５００（情報表示端末５５０と組で利用されるＳＩＰフォン）によって確立されたセッションに関する情報等を記憶することで、制御用セッション情報が、どのような情報表示端末５５０に対して払い出されたものであるか等を管理するものである。なお、制御用セッション管理テーブル１２４が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

アクセス中サービス管理テーブル１２５は、情報表示端末５５０が現に利用しているサービス（アクセス中のサービス）を管理するテーブルである。例えば、アクセス中サービス管理テーブル１２５は、図７に示すように、制御用セッション情報と、アクセス中サービスＩＤと、ステータスとを対応づけて記憶している。アクセス中サービス管理テーブル１２５が記憶するこれらの情報は、セッション管理サーバ１００が接続先を制御することで情報表示端末５５０がサービスを利用する際に、登録される。

ここで、ステータスとは、サービスＩＤで識別されるサービスの状況を示すものである。例えば、『１』は、情報表示端末５５０が自らサービスの開始要求をセッション管理サーバ１００に送信することで、サービス利用準備中であることを示す。また、『２』は、相手側の情報表示端末５５０がサービスの開始要求を行ったことで、自らもサービス利用準備中になったことを示す。また、『３』は、情報表示端末５５０がサービスを利用中であることを示す。また、『４』は、情報表示端末５５０がサービスの中断処理中であることを示す。なお、アクセス中サービス管理テーブル１２５が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

発着間紐付けＩＤテーブル１２６は、発着間紐付けＩＤ（ＳＩＰによって確立されたセッションを一意に識別するcallセッション情報の仮名としてセッション管理サーバ１００が払い出した仮名情報）を管理するテーブルである。例えば、発着間紐付けＩＤテーブル１２６は、図８に示すように、制御用セッション情報と、サービスＩＤと、発着間紐付けＩＤとを対応づけて記憶している。発着間紐付けＩＤテーブル１２６が記憶するこれらの情報は、セッション管理サーバ１００が発着間紐付けＩＤを払い出す際に、登録される。なお、発着間紐付けＩＤテーブル１２６が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

アクセス許容ＵＲＬテーブル１２７は、情報表示端末５５０の接続先として許容される接続先（ＵＲＬ（Uniform Resource Locator））を管理するテーブルである。例えば、アクセス許容ＵＲＬテーブル１２７は、図９に示すように、ＵＲＬのリストを記憶する。このように、アクセス許容ＵＲＬテーブル１２７は、ＵＲＬのリストを記憶することで、情報表示端末５５０の接続先として許容されているＵＲＬのホワイトリストを管理する（ブラックリストを管理してもよい）。なお、アクセス許容ＵＲＬテーブル１２７が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

制御部１３０は、セッション管理サーバ１００における各種制御を行い、特に本発明に密接に関連するものとしては、図２に示すように、制御ページ生成部１３１と、接続先監視部１３２と、サービス開始部１３３と、画面変更部１３４と、接続先警告部１３５と、強制切断部１３６とを備える。

制御ページ生成部１３１は、情報表示端末５５０の接続先を制御する制御ページを生成する。具体的には、制御ページ生成部１３１は、情報表示端末５５０からサービス開始要求（サービスを開始することを要求するサービス開始要求）を受け付けた際に、所定の接続先に制御するように当該情報表示端末５５０を制御する制御ページを生成して、当該制御ページを当該情報表示端末５５０に送信する。なお、制御ページ生成部１３１が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

接続先監視部１３２は、情報表示端末５５０の接続先を監視する。具体的には、接続先監視部１３２は、情報表示端末５５０にインストールされている接続先監視機能部５５８との間で通信を確立し、当該接続先監視機能部５５８から定期的に接続先のＵＲＬを受信することで、当該情報表示端末５５０の接続先を監視する。なお、接続先監視部１３２が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

サービス開始部１３３は、情報表示端末５５０が、サービス提供サーバ３００が提供するサービスを利用（もしくは変更）する際に、当該情報表示端末５５０の接続先を制御する。具体的には、サービス開始部１３３は、サービスを利用する要求や、現に利用しているサービスとは異なるサービスを利用することを要求する変更要求を情報表示端末５５０から受け付けると、当該情報表示端末５５０が現に利用しているサービスを判定し、競合関係などを判定した上で、当該情報表示端末５５０の接続先を制御する。なお、サービス開始部１３３が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

画面変更部１３４は、発着の情報表示端末５５０の画面情報を変更させる制御を行う。具体的には、画面変更部１３４は、変更要求（サービス提供サーバ３００によって互いに関連づけて制御されている他方の情報表示端末５５０の出力部５５２に出力されている画面情報を変更させることを要求する変更要求）を情報表示端末５５０から受け付けると、他方の情報表示端末５５０を所定の接続先に接続するように制御する。なお、画面変更部１３４が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

接続先警告部１３５は、情報表示端末５５０の接続先を監視し、情報表示端末５５０の利用者に警告を通知する。具体的には、接続先警告部１３５は、情報表示端末５５０にインストールされている接続先監視機能部５５８から定期的に受信した接続先のＵＲＬが、許容されているＵＲＬであるか否かを判定し、許容されていないＵＲＬである場合には、警告を通知するべく当該情報表示端末５５０に警告情報を送信する。なお、接続先警告部１３５が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

強制切断部１３６は、情報表示端末５５０と組で利用されるＳＩＰフォン５００によって確立されたセッションが切断された際に、サービス提供サーバ３００が提供するサービスの利用を終了するように情報表示端末５５０の接続先を制御する。具体的には、強制切断部１３６は、ＳＩＰによって確立された通信が切断されたことを示す切断情報をＳＩＰプロキシ２００から受け付けると、現に接続している接続先であるサービス提供サーバ３００が提供するサービスの利用を終了するように接続先を変更する制御情報を、情報表示端末５５０に送信することで、当該情報表示端末５５０の接続先を制御する。なお、強制切断部１３６が、サービス提供システムにおいてどのように利用されるものであるかについては、処理の手順を説明する際に詳述することとする。

［ＳＩＰプロキシ］
ＳＩＰプロキシ２００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図１０に示すように、通信部２１０と、制御部２３０とを備える。

通信部２１０は、ＳＩＰ通信用の一般的なインタフェースおよびライブラリを備え、ＳＩＰフォン５００との間で情報を送受信したり、ＨＧＷ４００やサービス提供サーバ３００との間で情報を送受信するなどする。

制御部２３０は、ＳＩＰプロキシ２００における各種制御を行い、特に本発明に密接に関連するものとしては、図１０に示すように、ＳＩＰ通信制御部２３１と、callセッション情報等送信部２３２とを備える。

ＳＩＰ通信制御部２３１は、汎用的なＳＩＰプロキシが備えるＳＩＰ通信制御機能と同様の機能を備える。具体的には、ＳＩＰ通信制御部２３１は、ＳＩＰフォン５００間でＳＩＰによって通信が確立される過程や、ＳＩＰによって確立された通信、あるいは、ＳＩＰによって確立された通信が切断される過程などを制御するなどする。

callセッション情報等送信部２３２は、callセッション情報等を検証可能な形式で発行する。また、実施例１におけるcallセッション情報等送信部２３２は、収集したcallセッション情報等について、「callセッション情報等に関する事実」を検証可能な形式で発行している。具体的に例を挙げて説明すると、「callセッション情報等に関する事実」とは、例えば、(a)当該callセッション情報等が、確かにＳＩＰプロキシ２００から発行された情報であること、(b)当該callセッション情報等が、改竄されていないこと、(c)ＳＩＰプロキシ２００が当該callセッション情報等を送信した事実を否認しないことなどの事実である。このような事実をセッション管理サーバ１００において検証することができれば、セッション管理サーバ１００は、取得したcallセッション情報が信用できる情報（真正な情報）であることを確認できるからである。

また、callセッション情報等送信部２３２は、callセッション情報等をＨＧＷ４００に送信する。具体的には、callセッション情報等送信部２３２は、発行したcallセッション情報（ＳＩＰプロキシ２００の署名付証明書が添付されたcallセッション情報等）をＨＧＷ４００にプッシュ型で送信する。ここで、callセッション情報等送信部２３２がcallセッション情報を送信する手法としては各種手法が考えられるが、実施例１においては、callセッション情報等送信部２３２が、ＳＩＰ信号の『MESSAGE』にＳＡＭＬ形式で記述されたcallセッション情報等を含ませることで、ＨＧＷ４００に対してcallセッション情報等を送信する。なお、ＨＧＷ４００が、ＨＴＴＰ通信によってＳＩＰプロキシ２００にアクセスし、プル型でcallセッション情報等を取得してもよい。もっとも、この場合には、ＳＩＰプロキシ２００が、callセッション情報等の取得を希望するＨＧＷ４００について、ＩＰアドレスベースや回線ベースの認証など、何らかの認証手段によって認証することが望ましい。

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

通信部３１０は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、セッション管理サーバ１００との間や、情報通信端末５５０との間、ＳＩＰプロキシ２００との間などで情報を送受信する。具体的には、通信部３１０は、後述する発着間紐付けＩＤ受信部３３１が情報表示端末５５０からサービス開始要求を受信する通信や、後述するサービス提供部３３３が情報表示端末５５０にサービスを提供する通信などを行う。なお、実施例１においては、上記したいずれの通信もＨＴＴＰで行われるものとして説明するが、中でも、サービス提供部３３３による通信はＷｅｂサービスに関係する通信であるという意味で、「Ｗｅｂ通信」と呼ぶ。

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

Webセッション情報管理テーブル３２１は、Webセッション情報を発着間紐付けＩＤと対応づけて記憶する。具体的には、Webセッション情報管理テーブル３２１は、まず、後述する発着間紐付けＩＤ受信部３３１によって受信された発着間紐付けＩＤおよび発着判定フラグを記憶し、次に、後述するWebセッション情報払出部３３２によって払い出されたWebセッション情報を発着間紐付けＩＤと対応づけて記憶する。また、Webセッション情報管理テーブル３２１が記憶したこれらの情報は、後述するサービス提供部３３３による処理に利用されるなどする。

Webセッション情報管理テーブル３２１は、例えば、図１２に示すように、Webセッション情報と発着間紐付けＩＤと発着判定フラグとの対応づけを記憶する。

図１１に戻り、制御部３３０は、サービス提供サーバ３００における各種制御を行い、特に本発明に密接に関連するものとしては、図１１に示すように、発着間紐付けＩＤ受信部３３１と、Ｗｅｂセッション情報払出部３３２と、サービス提供部３３３とを備える。

発着間紐付けＩＤ受信部３３１は、発着間紐付けＩＤおよび発着判定フラグを受信する。具体的には、発着間紐付けＩＤ受信部３３１は、情報表示端末５５０からサービス開始要求とともに発着間紐付けＩＤおよび発着判定フラグを受信することで発着間紐付けＩＤおよび発着判定フラグを取得し、取得した発着間紐付けＩＤおよび発着判定フラグを、Webセッション情報管理テーブル３２１に格納する。なお、実施例１における発着間紐付けＩＤ受信部３３１は、発着間紐付けＩＤとともに発着判定フラグをも受信することとしているが、本発明はこれに限られるものではなく、発着判定フラグの受信はオプションである。

ここで、実施例１において、情報表示端末５５０から送信される発着間紐付けＩＤおよび発着判定フラグは、セッション管理サーバ１００の署名付証明書を添付された発着間紐付けＩＤおよび発着判定フラグである。したがって、発着間紐付けＩＤ受信部３３１は、セッション管理サーバ１００の署名付証明書を添付された発着間紐付けＩＤおよび発着判定フラグを取得し、取得した当該発着間紐付けＩＤおよび発着判定フラグを検証し、当該発着間紐付けＩＤおよび発着判定フラグをWebセッション情報管理テーブル３２１に格納する。

具体的には、発着間紐付けＩＤ受信部３３１は、発着間紐付けＩＤおよび発着判定フラグに添付された署名付証明書を検証することで、発着間紐付けＩＤおよび発着判定フラグが真正な情報であることを検証し、検証結果を、Webセッション情報払出部３３２に伝達する。

例えば、発着間紐付けＩＤ受信部３３１は、証明書に含まれるセッション管理サーバ１００の公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号し、発着間紐付けＩＤおよび発着判定フラグのハッシュ値を取り出す。また、発着間紐付けＩＤ受信部３３１は、発着間紐付けＩＤおよび発着判定フラグ自体からハッシュ値を算出する。そして、発着間紐付けＩＤ受信部３３１は、署名から取り出したハッシュ値と算出したハッシュ値とを照合することで、発着間紐付けＩＤおよび発着判定フラグが真正な情報であることを検証する。すなわち、署名から取り出したハッシュ値と算出したハッシュ値とを照合した結果、両者が一致すれば、(a)当該発着間紐付けＩＤおよび発着判定フラグが、確かにセッション管理サーバ１００から発行された情報であること、(b)当該発着間紐付けＩＤおよび発着判定フラグが、改竄されていないこと、(c)セッション管理サーバ１００が当該発着間紐付けＩＤおよび発着判定フラグを送信した事実を否認しないことなどの事実を検証することができ、当該発着間紐付けＩＤおよび発着判定フラグが真正な情報であることを検証することができる。

Webセッション情報払出部３３２は、Webセッション情報を払い出す。具体的には、Webセッション情報払出部３３２は、発着間紐付けＩＤ受信部３３１によって発着間紐付けＩＤおよび発着判定フラグが受信され、かつ、検証結果が当該発着間紐付けＩＤおよび発着判定フラグが真正な情報であることを示すものである場合に、当該発着間紐付けＩＤおよび発着判定フラグを送信した情報表示端末５５０が行うＷｅｂ通信（サービス提供を受けるために情報表示端末５５０がサービス提供サーバ３００との間で行うＷｅｂ通信）に付与する情報として、Webセッション情報を払い出す。また、Webセッション情報払出部３３２は、払い出したWebセッション情報を、情報表示端末５５０に送信する。

また、Webセッション情報払出部３３２は、払い出したWebセッション情報を発着間紐付けＩＤおよび発着判定フラグに対応づけて格納する。具体的には、Webセッション情報払出部３３２は、払い出したWebセッション情報を、発着間紐付けＩＤ受信部３３１によって取得された発着間紐付けＩＤおよび発着判定フラグに対応づけてWebセッション情報管理テーブル３２１に格納する。

サービス提供部３３３は、サービスを制御する。具体的には、サービス提供部３３３は、Webセッション情報管理テーブル３２１に格納されている複数の発着間紐付けＩＤの内、所定の発着間紐付けＩＤ各々が同一の通信として確立されたものであることを示す場合であり、かつ、当該所定の発着間紐付けＩＤ各々に関して検証された結果、当該発着間紐付けＩＤ各々が真正な情報であることを示すものである場合に、Webセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する。

すなわち、例えば、他方の情報表示端末５５０が、Webセッション情報『Ss4444444』が付与されたＷｅｂ通信によってサービス提供サーバ３００にアクセスしている際に、一方の情報表示端末５５０が、Webセッション情報『Ss4444445』が付与されたＷｅｂ通信によってサービス提供サーバ３００に画像データをアップロードしたとする。このような場合、情報表示端末５５０間の関係は、ＳＩＰによって同一の通信を確立した関係であるとみなされるので、この関係は、画像データの共有を互いに認めている関係であるとして、実施例１におけるサービス提供部３３３は、他方の情報表示端末５５０に画像データを送信するよう、サービスを制御する。なお、サービス提供部３３３は、Webセッション情報管理テーブル３２１に格納されている発着判定フラグを用いて、情報表示端末５５０が発側であるのか着側であるのかを区別した上で、サービスを制御してもよい。

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

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

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

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

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

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

ブラウザセッション情報管理テーブル４２１は、配下の情報表示端末５５０に割り当てられたブラウザセッション情報を予め記憶する。具体的には、ブラウザセッション情報管理テーブル４２１は、ＳＩＰフォン５００を一意に識別する情報（ＳＩＰフォンＩＤ）と、当該ＳＩＰフォン５００と組で利用される情報表示端末５５０を一意に識別する情報（情報表示端末ＩＤ）と、当該情報表示端末５５０を特定するためのブラウザセッション情報とを対応づけて予め記憶する。また、ブラウザセッション情報管理テーブル４２１が記憶するこれらの情報は、後述する情報表示端末特定部４３３による処理に利用されるなどする。ブラウザセッション情報管理テーブル４２１は、例えば、図１４に示すように、ＳＩＰフォンＩＤと情報表示端末ＩＤとブラウザセッション情報との対応づけを記憶する。

図１３に戻り、制御部４３０は、ＨＧＷ４００における各種制御を行い、特に本発明に密接に関連するものとしては、図１３に示すように、callセッション情報等取得部４３１と、ＳＩＰフォンＩＤ収集部４３２と、情報表示端末特定部４３３と、アクセス先変更指示部４３４とを備える。

callセッション情報等取得部４３１は、callセッション情報等を取得する。具体的には、callセッション情報等取得部４３１は、配下のＳＩＰフォン５００と他方のＳＩＰフォン５００との間でＳＩＰによって確立された通信を一意に識別するcallセッション情報、当該通信を確立した情報表示端末５５０の利用者を特定するユーザ特定情報、および発着判定フラグを、ＳＩＰプロキシ２００からプッシュ型で送信されることで取得し、取得したこれらの情報を情報表示端末特定部４３３に伝達する。

なお、ここで、callセッション情報およびWebセッション情報について説明しておくと、本来、セッション情報とは、ＯＳＩ（Open Systems Interconnection）でいうところの第５層で通信を一意に識別する情報である。すなわち、実施例１に係るサービス提供システムにおいては、通信として、ＳＩＰ通信とＷｅｂ通信（ＨＴＴＰ通信）とが行われることを想定しているが、ＳＩＰ通信もＷｅｂ通信も、いずれもＴＣＰ（Transmission Control Protocol）通信であるという点で、第４層では識別することができない。このため、ＳＩＰフォン間や情報表示端末間で確立された通信にセッション情報が付与されることで、当該通信がＳＩＰ通信であるのか、あるいは、Ｗｅｂ通信であるのかが識別される。すなわち、callセッション情報とは、ＳＩＰ通信であることを示すセッション情報であり、Webセッション情報とは、Ｗｅｂ通信であることを示すセッション情報である。

また、セッション情報は、単にＳＩＰ通信とＷｅｂ通信とを識別するのみならず、ＳＩＰフォン間や情報表示端末間で確立された通信が、他のＳＩＰフォン間や情報表示端末間で確立された通信とは異なる通信であることをも識別する。これを言い換えると、callセッション情報とは、ＳＩＰフォン間でＳＩＰによって確立されたＳＩＰ通信を一意に識別する情報であり、Webセッション情報とは、情報表示端末間で確立されたＷｅｂ通信を一意に識別する情報である。callセッション情報としては、ＳＩＰ通信に含まれる情報である『Call-ID』、または、『From』、『To』、『tag』、もしくは、これらの組合せを用いる手法や、ＳＩＰ通信に含まれるその他の情報（例えば、『Date』など）を組合せて用いる手法などが考えられ、ＳＩＰによって確立された通信を一意に識別することが可能な情報を用いる手法であれば、どのような手法でもよい。一方、Webセッション情報としては、情報表示端末がＷｅｂ通信を行う際に利用するブラウザに付与された情報である『セッションID』（CookieのIDなど）を用いる手法などが考えられる。なお、これらのcallセッション情報やWebセッション情報は、一般的には確立されたセッションごとにユニークに生成されるものであり、通常のアプリケーション利用の範囲では、競合しないものである。

次に、ユーザ特定情報について説明しておくと、実施例１において、ユーザ特定情報とは、ＳＩＰ通信に含まれる情報である『From』や『To』としてのＳＩＰ−ＵＲＩを想定している。すなわち、『From』や『To』の情報は、callセッション情報として用いられることもあれば、ユーザ特定情報として用いられることもあり、実施例１においては、callセッション情報として『Call-ID』が用いられ、ユーザ特定情報として『From』や『To』が用いられているといえる。また、発着判定フラグについて説明しておくと、ユーザ特定情報で特定されるユーザ（情報表示端末５５０）が、ＳＩＰによって確立された通信の発信側であるのか、あるいは、着信側であるのかを判定するためのフラグである。発着判定フラグは、例えば、『０』や『１』といった単純なフラグが用いられる場合もあれば、乱数などで作成されたフラグが用いられる場合もある。

ここで、実施例１において、発着判定フラグは、２通りの意味で用いられている。まず、発着判定フラグは、ＳＩＰプロキシ２００がＨＧＷ４００に送信し、情報表示端末５５０がセッション管理サーバ１００に送信することで、セッション管理サーバ１００における管理に用いられるものである。また、発着判定フラグは、セッション管理サーバ１００が情報表示端末５５０に送信し、情報表示端末５５０がサービス管理サーバ３００に送信することで、サービス管理サーバ３００におけるサービス制御に用いられるものである。前者の意味で用いられる発着判定フラグと後者の意味で用いられる発着判定フラグとを、同じフラグを用いて実現する手法もあるが、例えば、前者の発着判定フラグについては『０』や『１』といった単純なフラグを用い、後者の発着判定フラグについては乱数などで作成されたフラグを用いるといった、使い分けをして実現する手法も考えられる。すなわち、使い分けをして実現する手法によれば、セッション管理サーバ１００は、セッション管理サーバ１００のみが判定可能な情報として、乱数の発着判定フラグを作成することができ、結果として、情報表示端末５５０側が発着判定フラグをなりすます事態を防止することができる。言い換えると、後者の発着判定フラグについても『０』や『１』といった単純なフラグを用いた場合、発側の情報表示端末５５０は、自らの発着判定フラグとして『１』が送信されてきたことから、着側を示す発着判定フラグは『０』であると推測し、推測した『０』を用いて着側になりすますことができてしまう。このようななりすましを防止すべく、情報表示端末５５０に推測されないような手法で後者の発着判定フラグを作成することが望ましい。その意味で、これを実現する手法は乱数に限られるものではなく、例えば、セッション管理サーバ１００が発着判定フラグを暗号化する（サービス提供サーバ３００のみが復号可能な鍵で暗号化する）といった手法でもよい。なお、サービス提供サーバ３００は、セッション管理サーバ１００に問い合わせたり復号するなどして、発着判定フラグに基づいたサービス制御を行うことになる。

ＳＩＰフォンＩＤ収集部４３２は、ＳＩＰフォンＩＤを収集する。具体的には、ＳＩＰフォンＩＤ収集部４３２は、配下のＳＩＰフォン５００を一意に識別する情報であるＳＩＰフォンＩＤを、当該ＳＩＰ通信に含まれる情報から収集する。また、ＳＩＰフォンＩＤ収集部４３２は、収集したＳＩＰフォンＩＤを、情報表示端末特定部４３３に伝達する。

ここで、ＳＩＰフォンＩＤとは、例えば、ＳＩＰフォン５００の内線番号のことである。ＨＧＷの配下に複数のＳＩＰフォン５００が接続される構成の場合、ＳＩＰ−ＵＲＩ（Uniform Resource Identifier）はＨＧＷに対して付与され、ＨＧＷ配下のＳＩＰフォン５００各々には、内線番号が付与される。すなわち、ＨＧＷ配下のＳＩＰフォン５００を通信相手として指定する際には、ＨＧＷのＳＩＰ−ＵＲＩと内線番号との組み合わせが指定されなければならない。

情報表示端末特定部４３３は、ＳＩＰによって通信を確立したＳＩＰフォン５００と組で利用される情報表示端末５５０を特定する。具体的には、情報表示端末特定部４３３は、ＳＩＰフォンＩＤ収集部４３２によって収集されたＳＩＰフォンＩＤを検索キーとして、ブラウザセッション情報管理テーブル４２１を検索し、当該ＳＩＰフォンＩＤによって一意に識別されるＳＩＰフォン５００と組で利用される情報表示端末５５０を特定するとともに、当該情報表示端末５５０のブラウザセッション情報を特定する。次に、情報表示端末特定部４３３は、特定したブラウザセッション情報と、ＨＧＷ４００に対してポーリングを行う複数の情報表示端末５５０各々のブラウザセッション情報とを比較し、ブラウザセッション情報が一致したポーリングを行っている情報表示端末５５０が、ＳＩＰによって通信を確立したＳＩＰフォン５００と組で利用される情報表示端末５５０であると特定する。そして、情報表示端末特定部４３３は、アクセス先変更指示部４３４に、情報表示端末５５０の特定情報とcallセッション情報等（ＳＩＰプロキシ２００の署名付証明書を添付されたcallセッション情報、ユーザ特定情報、および発着判定フラグ）とを伝達する。

アクセス先変更指示部４３４は、アクセス先変更指示を情報表示端末５５０に対して行う。具体的には、アクセス先変更指示部４３４は、情報表示端末特定部４３３から情報表示端末５５０の特定情報とcallセッション情報等（ＳＩＰプロキシ２００の署名付証明書を添付されたcallセッション情報、ユーザ特定情報、および発着判定フラグ）とを伝達されると、特定情報で特定される情報表示端末５５０に対して、セッション管理サーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、callセッション情報等とともに行う。

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

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

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

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

制御部５５５は、情報表示端末５５０における各種制御を行い、特に本発明に密接に関連するものとしては、図１３に示すように、サービス開始要求部５５６と、サービス利用部５５７と、接続先監視機能部５５８とを備える。

サービス開始要求部５５６は、サービスを開始することを要求するサービス開始要求をcallセッション情報等（ＳＩＰプロキシ２００の署名付証明書を添付されたcallセッション情報、ユーザ特定情報、および発着判定フラグ）とともにセッション管理サーバ１００に対して送信する。具体的には、サービス開始要求部５５６は、ＨＧＷ４００のアクセス先変更指示部４３４によってリダイレクトされると、アクセス先をセッション管理サーバ１００に変更し、callセッション情報等をサービス開始要求とともにセッション管理サーバ１００に対して送信する。

サービス利用部５５７は、Webセッション情報を受信する。具体的には、サービス利用部５５７は、サービス提供サーバ３００からWebセッション情報を受信する。また、サービス利用部５５７は、受信したWebセッション情報を用いて、サービス提供サーバ３００によって提供されるサービスの提供を受け、サービスを利用する。具体的には、サービス利用部５５７は、Webセッション情報をＨＴＴＰ通信を行うＷｅｂブラウザに付与し、サービス提供を受けるために、サービス提供サーバ３００との間でＷｅｂ通信を行う。なお、実施例１において、サービス利用部５５７による通信は、Ｗｅｂサービスに関係する通信であるという意味で、「Ｗｅｂ通信」と呼ぶ。

接続先監視機能部５５８は、情報表示端末５５０の接続先を監視し、当該接続先を定期的にセッション管理サーバ１００に送信する。具体的には、接続先監視機能部５５８は、セッション管理サーバ１００から送信されたプログラム（例えば、Ｊａｖａ(登録商標）Ｓｃｒｉｐｔファイル）などをインストールすることで情報表示端末５５０に備えられ、その後、セッション管理サーバ１００との間で通信を確立し、監視した接続先のＵＲＬをポーリングによって定期的に送信する。なお、実施例１においては、接続先監視機能部５５８がセッション管理サーバ１００に対して接続先を送信する手法を説明したが、本発明はこれに限られるものではない。例えば、セッション管理サーバ１００が、情報表示端末５５０のＷｅｂブラウザに定期的に接続先送信要求を送信し、Ｗｅｂブラウザがこれに応答して接続先を定期的に送信する手法などでもよい。

［実施例１に係るサービス提供システムによる処理の手順］
続いて、図１５〜図２２を用いて、実施例１に係るサービス提供システムによる処理の手順を説明する。図１５は、実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（発側）であり、図１６は、利用可能なサービス確認処理の手順を示すフローチャートであり、図１７は、制御ページを説明するための図であり、図１８は、実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（着側）であり、図１９は、実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス開始要求）であり、図２０は、アクセス権確認処理の手順を示すフローチャートであり、図２１は、制御ページを説明するための図であり、図２２は、実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス開始後）である。

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

両ＳＩＰフォン５００間でＳＩＰによって通信が確立されると、ＨＧＷ４００（callセッション情報等取得部４３１）は、ＳＩＰによって確立された通信を一意に識別するcallセッション情報や、当該通信を確立した両ＳＩＰフォン５００の利用者を一意に特定するユーザ特定情報、発着判定フラグなどを取得する（ステップＳ１０５）。例えば、ＨＧＷ４００（callセッション情報等取得部４３１）は、callセッション情報としての『Call-ID』、ユーザ特定情報としての『From（ＳＩＰ−ＵＲＩ）』および『To（ＳＩＰ−ＵＲＩ）』、両ＳＩＰフォン５００が発側であるのか着側であるのかを示す『発着判定フラグ』（図１５においては『発着フラグ』と表示する）を、検証可能な形式（ＳＩＰプロキシ２００の署名付証明書を添付された形式、図１５においては『証明書（Ｓ）』と表示する）で取得する。

ここで、ＳＩＰプロキシ２００の署名付証明書について簡単に説明しておくと、ＳＩＰプロキシ２００は、ＳＩＰによって通信を確立する過程やＳＩＰによって確立された通信を制御する装置自身であるので、自装置が制御することで確立したセッションに関する情報を管理しているのが一般的である。したがって、ＳＩＰプロキシ２００（ＳＩＰ通信制御部２３１）は、自らが制御することで両ＳＩＰフォン５００の間にセッションを確立すると、『Call-ID』、『From（ＳＩＰ−ＵＲＩ（Uniform Resource Identifier））』、『To（ＳＩＰ−ＵＲＩ）』や、両ＳＩＰフォン５００が発側であるのか着側であるのかを識別する情報などを、確立したセッションのＳＩＰ信号から収集することができる。

そこで、ＳＩＰプロキシ２００（callセッション情報等送信部２３２）は、ＳＩＰ信号から収集したcallセッション情報等（ＳＩＰプロキシ２００の署名付証明書を添付されたcallセッション情報、ユーザ特定情報、および発着判定フラグ）についてＳＩＰプロキシ２００の署名付証明書を発行し、当該署名付証明書をcallセッション情報等に添付することで、当該callセッション情報等を検証可能な形式で発行する。そして、ＳＩＰプロキシ２００（callセッション情報等送信部２３２）は、検証可能な形式で発行したcallセッション情報等を、発側のＳＩＰフォン５００を配下に接続するＨＧＷ４００と、着側のＳＩＰフォン５００を配下に接続するＨＧＷ４００とに、プッシュ型で送信するなどする。

このようにして、ＨＧＷ４００（callセッション情報等取得部４３１）は、上記したように、『Call-ID』、『From（ＳＩＰ−ＵＲＩ）』、『To（ＳＩＰ−ＵＲＩ）』、『発着フラグ』を、検証可能な形式で取得するのである。なお、ＨＧＷ４００（callセッション情報等取得部４３１）が、自らこれらの情報を収集することで取得してもよい。

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

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

そして、ＨＧＷ４００（アクセス先変更指示部４３４）は、アクセス先変更指示を、ステップＳ１０７において特定された情報表示端末５５０に対して行う。具体的には、特定された情報表示端末５５０に対して、セッション管理サーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、callセッション情報等（ＳＩＰプロキシ２００の署名付証明書を添付されたcallセッション情報、ユーザ特定情報、および発着判定フラグ）とともに行う（ステップＳ１０８）。この時、実施例１におけるＨＧＷ４００（アクセス先変更指示部４３４）は、リダイレクト指示に、ＨＧＷ４００のＵＲＬをも含めている。なお、実施例１においては、ＨＧＷ４００がセッション管理サーバ１００のＵＲＬを予め記憶部に記憶していることで、当該ＵＲＬにアクセス先を変更するようリダイレクト指示を行うことができる。

すると、情報表示端末５５０（サービス開始要求部５５６）はリダイレクトされ、接続先をセッション管理サーバ１００に変更し、サービスを開始することを要求するサービス開始要求を、当該セッション管理サーバ１００に送信する（ステップＳ１０９）。この時、情報表示端末５５０（サービス開始要求部５５６）は、callセッション情報等（ＳＩＰプロキシ２００の署名付証明書を添付されたcallセッション情報、ユーザ特定情報、および発着判定フラグ）と、ＨＧＷ４００のＵＲＬとを、セッション管理サーバ１００に送信することになる。

一方、セッション管理サーバ１００（制御ページ生成部１３１）は、情報表示端末５５０から送信されたcallセッション情報等を受信すると、当該callセッション情報等の検証を行う（ステップＳ１１０）。すなわち、セッション管理サーバ１００（制御ページ生成部１３１）は、callセッション情報等に添付された署名付証明書を検証することで、callセッション情報等が真正な情報であることを検証する。なお、callセッション情報等が真正な情報であることを検証する手法としては、ＳＩＰプロキシ２００に問い合わせを行う手法でもよい。

続いて、セッション管理サーバ１００（制御ページ生成部１３１）は、ステップＳ１１０における検証の結果、callセッション情報等が真正な情報であることを確認すると、当該callセッション情報等やＨＧＷ４００のＵＲＬを制御用セッション管理テーブル１２４に格納し、制御用セッション情報を払い出す（ステップＳ１１１）。

すなわち、セッション管理サーバ１００（制御ページ生成部１３１）は、『Call-ID』、『From（ＳＩＰ−ＵＲＩ）』、『To（ＳＩＰ−ＵＲＩ）』、『発着フラグ』や、ＨＧＷ４００のＵＲＬを制御用セッション管理テーブル１２４に格納し、制御用セッション情報を払い出す。すると、制御用セッション管理テーブル１２４は、例えば、図６に示すような情報を格納することになる。なお、図６に示すように、セッション管理サーバ１００（制御ページ生成部１３１）は、ＳＩＰによって確立された通信の開始時刻や、情報表示端末５５０のＩＰアドレスなどを取得して格納してもよい。例えば、ＩＰアドレスを格納した場合には、セッション管理サーバ１００（制御ページ生成部１３１）は、ＩＰアドレスを用いてＳＩＰプロキシ２００など（ＳＩＰプロキシ２００に限られず、ＩＰアドレスとＳＩＰ−ＵＲＩとの対応づけを管理しているシステムなど）に問い合わせを行い、当該ＩＰアドレスに対応づけられているＳＩＰ−ＵＲＩの応答を受けることで、『From（ＳＩＰ−ＵＲＩ）』や『To（ＳＩＰ−ＵＲＩ）』の情報が正しい情報であるか否かを検証することが可能になり、セキュリティを向上させることが可能になる。

図１５に戻り、続いて、セッション管理サーバ１００（制御ページ生成部１３１）は、サービス開始要求を送信してきた情報表示端末５５０（発側）が利用可能なサービスを確認し、サービスＩＤを取得する（ステップＳ１１２）。

ここで、図１６を用いて、利用可能なサービス確認処理を詳しく説明すると、まず、セッション管理サーバ１００（制御ページ生成部１３１）は、発着のユーザ特定情報（『From（ＳＩＰ−ＵＲＩ）』や『To（ＳＩＰ−ＵＲＩ）』）をキーとしてユーザ契約サービス管理テーブル１２１を検索し、発側ユーザおよび着側ユーザが契約している契約サービスＩＤを取得する（ステップＳ１１２−１）。例えば、図３に示すユーザ契約サービス管理テーブル１２１を例に説明すると、セッション管理サーバ１００（制御ページ生成部１３１）は、発側のユーザ特定情報『sip：0333333333@hogehoge.com』をキーとしてユーザ契約サービス管理テーブル１２１を検索し、契約サービスＩＤ『1111』、『1112』、『1115』および『1117』を取得する。

次に、セッション管理サーバ１００（制御ページ生成部１３１）は、契約サービスＩＤをキーとして契約サービス情報テーブル１２２を検索し、サービスＴｙｐｅ、着信同時接続フラグ、接続Ｔｙｐｅ、アクセス先ＵＲＬ、着側ＵＲＬを取得する（ステップＳ１１２−２）。例えば、図４に示す契約サービス情報テーブル１２２を例に説明すると、セッション管理サーバ１００（制御ページ生成部１３１）は、契約サービスＩＤ『1111』に関する情報として、サービスＴｙｐｅ『００』、着信同時接続フラグ『０』、接続Ｔｙｐｅ『０』、アクセス先ＵＲＬ『http://hoge1111.com/』、着側ＵＲＬ『−』を取得し、その他の契約サービスＩＤ『1112』、『1115』および『1117』についても同様に取得する。

続いて、セッション管理サーバ１００（制御ページ生成部１３１）は、取得した情報の内、着信同時接続フラグ『１』のものがあるか否かを判定する（ステップＳ１１２−３）。ここで、着信同時接続フラグとは、契約サービスＩＤで識別されるサービスが、コールセンタタイプ（着信と同時にサービスを開始するタイプ）のサービスであるか、ポータルタイプ（着信時にはサービス選択画面を表示するタイプ）のサービスであるかを示すフラグである。実施例１においては、コールセンタタイプのサービスの優先度が高いことを想定しているので、まず、着信同時接続フラグ『１』のものがあるか否かを判定するのである。

契約サービスＩＤ『1112』、『1115』および『1117』の中にはコールセンタタイプのサービスはないが、着信同時接続フラグ『１』のものがあった場合（ステップＳ１１２−３肯定）について説明しておくと、セッション管理サーバ１００（制御ページ生成部１３１）は、次に、サービスＴｙｐｅをチェックする（ステップＳ１１２−４）。ここで、サービスＴｙｐｅとは、契約サービスＩＤで識別されるサービスが、発側ユーザもしくは着側ユーザのどちらかが加入中であれば利用できるサービスであるか、発側ユーザおよび着側ユーザの両方が加入中でないと利用できないサービスであるか、あるいは、発側ユーザもしくは着側ユーザのどちらかが加入中であれば利用できるが、加入者しか起動できないサービスであるかを示すものである。

サービスＴｙｐｅをチェックした結果、発側ユーザが利用可能なサービスがあれば（ステップＳ１１２−５肯定）、次に、セッション管理サーバ１００（制御ページ生成部１３１）は、接続Ｔｙｐｅをチェックする（ステップＳ１１２−６）。ここで、接続Ｔｙｐｅとは、発側ユーザおよび着側ユーザに接続先として同じＵＲＬを提示するサービスであるか、異なるＵＲＬを提示するサービスであるか、あるいは、加入者と未加入者とで異なるＵＲＬを提示するサービスであるかを示すものである。言い換えると、発側と着側とで異なるＵＲＬに接続することを可能にするための情報である。

すなわち、接続Ｔｙｐｅが『発着同じＵＲＬ』である場合には（ステップＳ１１２−７肯定）、セッション管理サーバ１００（制御ページ生成部１３１）は、当該契約サービスＩＤとアクセス先ＵＲＬとを取得する（ステップＳ１１２−８）。また、接続Ｔｙｐｅが『異なるＵＲＬ』である場合には（ステップＳ１１２−７否定、ステップＳ１１２−９肯定）、セッション管理サーバ１００（制御ページ生成部１３１）は、当該契約サービスＩＤと発側ＵＲＬとを取得する（ステップＳ１１２−１０）。また、接続Ｔｙｐｅが『加入者ＵＲＬ、未加入者ＵＲＬ』である場合には（ステップＳ１１２−９否定）、次に、セッション管理サーバ１００（制御ページ生成部１３１）は、発側ユーザが加入者であるか否かを判定し（ステップＳ１１２−１１）、加入者である場合には（ステップＳ１１２−１１肯定）、当該契約サービスＩＤと加入者ＵＲＬとを取得し（ステップＳ１１２−１２）、加入者でない場合には（ステップＳ１１２−１１否定）、当該契約サービスＩＤと未加入者ＵＲＬとを取得する（ステップＳ１１２−１３）。

なお、ステップＳ１１２−５において、サービスＴｙｐｅをチェックした結果、発側ユーザが利用可能なサービスがなければ（ステップＳ１１２−５否定）、セッション管理サーバ１００（制御ページ生成部１３１）は、コールセンタタイプのサービス以外のサービス（ポータルタイプのサービス）について、サービスＴｙｐｅをチェックする（ステップＳ１１２−１４）。

そして、サービスＴｙｐｅをチェックした結果、発側ユーザが利用可能なサービスがなければ（ステップＳ１１２−１５否定）、セッション管理サーバ１００（制御ページ生成部１３１）は、処理を終了（サービス開始要求を送信してきた発側ユーザに利用可能なサービスがなかった場合であるので、エラーを通知して終了するなどする）し、発側ユーザが利用可能なサービスがあれば（ステップＳ１１２−１５肯定）、セッション管理サーバ１００（制御ページ生成部１３１）は、上記したステップＳ１１２−７〜１３と同様の処理を行う。

図１５に戻り、続いて、セッション管理サーバ１００（制御ページ生成部１３１）は、制御ページを生成する（ステップＳ１１３）。例えば、セッション管理サーバ１００（制御ページ生成部１３１）は、図１７に示すような制御ページをＨＴＭＬ（HyperText Markup Language）で記述するなどして生成する。ここで、『領域１』および『領域２』について説明すると、『領域１』および『領域２』は、一般的なＷｅｂブラウザで表示されるＷｅｂページでいうところのフレームに相当する概念であり、例えば、『領域１』は接続先監視用のフレームであり、『領域２』はＷｅｂサービス用のフレームであるといった使い分けが考えられる。

図１５に戻り、そして、セッション管理サーバ１００（制御ページ生成部１３１）は、情報表示端末５５０に対して、接続先監視機能と、ステップＳ１１１で払い出した制御用セッション情報と、ステップＳ１１３で生成した制御ページと、ステップＳ１１２で取得したサービスＩＤとを送信する（ステップＳ１１４）。ここで、接続先監視機能とは、例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイルであり、情報表示端末５５０にインストールされることで、情報表示端末５５０とセッション管理サーバ１００との間で通信を確立し、情報表示端末５５０の接続先を監視する役割を果たす機能である。情報表示端末５５０に専用アプリケーションがインストールされていれば、このような接続先監視機能を送信する必要はないが、実施例１においては、情報表示端末５５０に一般的なＷｅｂブラウザのみがインストールされていることを想定しているので、接続先監視機能を送信する必要がある。

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

ところで、上記したように、制御ページについて、『領域１』が接続先監視用のフレームであり、『領域２』がＷｅｂサービス用のフレームであるといった使い分けが考えられるが、このような制御ページと接続監視機能との関係について、一例を挙げて説明する。ここで、接続先監視機能（Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイル）は、『領域１』および『領域２』のいずれにもインストールされているものとすると、このような場合、例えば、『領域１』の接続先監視機能は、接続先がサービス提供サーバ単位で変更になる場合に、このような状態変更をセッション管理サーバ１００に通知し、『領域２』の接続先監視機能は、接続先が、同一のサービス提供サーバ内で変更になる場合に、このような状態変更をセッション管理サーバ１００に通知する。また、『領域２』はＷｅｂサービス用のフレームであるので、接続先がサービス提供サーバ単位で変更になる場合には、書き替えられ、インストールされていた接続先監視機能が失われるおそれもある。このような場合には、情報表示端末５５０は、別途、接続先監視機能のダウンロードをセッション管理サーバ１００に対して要求し、ダウンロードした接続先監視機能を再び『領域２』にインストールすればよい。

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

続いて、図１９に示すように、発側の情報表示端末５５０の利用者が、Ｗｅｂブラウザに表示された制御ページの中からサービスを選択することで（ステップＳ１２０）、情報表示端末５５０（サービス開始要求部５５６）は、サービス開始要求をセッション管理サーバ１００に対して送信する（ステップＳ１２１）。この時、情報表示端末５５０（サービス開始要求部５５６）は、ステップＳ１１４において送信された制御用セッション情報を用いて、選択したサービスのサービスＩＤをセッション管理サーバ１００に対して送信する。

すると、セッション管理サーバ１００（サービス開始部１３３）は、情報表示端末５５０から送信された制御用セッション情報が、制御用セッション管理テーブル１２４に登録されているものであることを確認し（ステップＳ１２２）、続いて、アクセス中サービス管理テーブル１２５を確認して、当該制御用セッション情報を設定する（ステップＳ１２３）。すなわち、セッション管理サーバ１００（サービス開始部１３３）は、情報表示端末５５０から送信されたサービス開始要求が、初回のものであるのか、あるいは、２回目以降（サービス変更要求）であるのかを確認すべく、アクセス中サービス管理テーブル１２５を確認する。ここでは、初回のサービス開始要求であることを想定するので、セッション管理サーバ１００（サービス開始部１３３）は、情報表示端末５５０から送信された制御用セッション情報を直ちに設定する。

例えば、セッション管理サーバ１００（サービス開始部１３３）は、図７に示すように、制御用セッション情報と、アクセス中サービスＩＤ（サービス開始要求とともに送信したサービスＩＤ）と、ステータスとを対応づけて、アクセス中サービス管理テーブル１２５に設定する。ここで、ステータスとは、サービス利用準備中であるか、相手側からの要求でサービス利用準備中であるか、サービス利用中であるか、サービス中断処理中であるか、というステータスを示すものである。ステップＳ１２３において、発側の情報表示端末５５０は、サービス利用準備中であるので、ステータスとして『１』が設定される。なお、サービス同士が競合しない場合には、同一のユーザであっても複数のサービスを利用することができる。

続いて、セッション管理サーバ１００（サービス開始部１３３）は、サービス提供サーバ３００へのアクセス権確認処理を行う（ステップＳ１２４）。ここで、図２０を用いて、アクセス権確認処理を詳しく説明すると、まず、セッション管理サーバ１００（サービス開始部１３３）は、サービス開始要求とともに送信された制御用セッション情報をキーとして制御用セッション管理テーブル１２４を検索し、発着のユーザ特定情報を取得する（ステップＳ１２４−１）。例えば、図６に示す制御用セッション管理テーブル１２４を例に説明すると、セッション管理サーバ１００（サービス開始部１３３）は、制御用セッション情報『s11111111』をキーとして制御用セッション管理テーブル１２４を検索し、当該制御用セッション情報『s11111111』に対応づけられているCall-ID『cs333933333』を取得し、次に、当該Call-ID『cs333933333』に対応づけられている『From』や『To』、発着判定フラグなどから、発側のユーザ特定情報として『sip:0333333333@hogehoge.com』を取得し、着側のユーザ特定情報として『sip:0344444444@hogehoge.com』を取得する。

次に、セッション管理サーバ１００（サービス開始部１３３）は、発着のユーザ特定情報をキーとしてユーザ契約サービス管理テーブル１２１を検索し、発側ユーザおよび着側ユーザが契約している契約サービスＩＤを取得する（ステップＳ１２４−２）。例えば、図３に示すユーザ契約サービス管理テーブル１２１を例に説明すると、セッション管理サーバ１００（サービス開始部１３３）は、ユーザ特定情報『sip:0333333333@hogehoge.com』をキーとして契約サービスＩＤ『1111』、『1112』、『1115』および『1117』を取得し、ユーザ特定情報『sip:0344444444@hogehoge.com』をキーとして契約サービスＩＤ『1111』および『1112』を取得する。

そして、セッション管理サーバ１００（サービス開始部１３３）は、サービス開始要求とともに送信されてきたサービスＩＤが、発側ユーザが契約している契約サービスＩＤであるか否かを確認する（ステップＳ１２４−３）。確認の結果、発側ユーザが契約している契約サービスＩＤであれば（ステップＳ１２４−３肯定）、セッション管理サーバ１００（サービス開始部１３３）は、次の処理（図１９のステップＳ１２５の処理）に移行すべく処理を終了する。一方、確認の結果、発側ユーザが契約している契約サービスＩＤでなければ（ステップＳ１２４−３否定）、セッション管理サーバ１００（サービス開始部１３３）は、次に、サービス開始要求とともに送信されてきたサービスＩＤが、着側ユーザが契約している契約サービスＩＤであるか否かを確認する（ステップＳ１２４−４）。

確認の結果、着側ユーザが契約している契約サービスＩＤであれば（ステップＳ１２４−４肯定）、セッション管理サーバ１００（サービス開始部１３３）は、当該契約サービスＩＤをキーとして契約サービス情報テーブル１２２を検索し、サービスＴｙｐｅを取得する（ステップＳ１２４−５）。そして、セッション管理サーバ１００（サービス開始部１３３）は、サービスＴｙｐｅが『００』であるか否かを判定し（ステップＳ１２４−６）、『００』であれば（ステップＳ１２４−６肯定）、発側ユーザもしくは着側ユーザのどちらかが加入中であれば利用できるサービスであるので、次の処理（図１９のステップＳ１２５の処理）に移行すべく処理を終了する。一方、『００』でなければ（ステップＳ１２４−６否定）、サービスを利用することができない（もしくは、発側ユーザからは起動することができない）ので、サービス利用不可を情報表示端末５５０に通知する（ステップＳ１２４−７）。

また、ステップＳ１２４−４における確認の結果、着側ユーザが契約している契約サービスＩＤでなければ（ステップＳ１２４−４否定）、やはり、サービスを利用することができないので、セッション管理サーバ１００（サービス開始部１３３）は、サービス利用不可を情報表示端末５５０に通知する（ステップＳ１２４−７）。

図１９に戻り、次に、セッション管理サーバ１００（サービス開始部１３３）は、発着間紐付けＩＤを払い出し、発着間紐付けＩＤテーブル１２６に登録する（ステップＳ１２５）。ここで、発着間紐付けＩＤとは、サービス提供サーバ３００において、発側の情報表示端末５５０と着側の情報表示端末５５０とを紐付けるために用いられるＩＤのことである。発側のＳＩＰフォン５００と着側のＳＩＰフォン５００との間でＳＩＰによって確立された通信は、callセッション情報によって一意に識別することができるので、サービス提供サーバ３００は、当該callセッション情報を用いれば、発側の情報表示端末５５０と着側の情報表示端末５５０とを紐付けることができる。しかしながら、callセッション情報をサービス提供サーバ３００に開示することにセキュリティ上の問題があると考えられるような場合には、callセッション情報そのものをサービス提供サーバ３００に開示するべきではない。そこで、実施例１においては、callセッション情報の仮名ＩＤとして、セッション管理サーバ１００が、発着間紐付けＩＤを払い出すものである。

例えば、図８に示す発着間紐付けＩＤテーブル１２６を例に説明すると、セッション管理サーバ１００（サービス開始部１３３）は、発着両方について、制御用セッション情報と、サービスＩＤと、発着間紐付けＩＤとを対応づけて登録する。

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

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

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

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

この他、サービス提供サーバ３００（Webセッション情報払出部３３２）が、例えば、callセッション情報自体や、ユーザ特定情報、ＳＩＰによって確立された通信の開始時刻、ＩＰアドレス、サービス名といった各種情報を、情報表示端末５５０やセッション管理サーバ１００から通知されることで取得し得る場合には、これらの情報をもWebセッション情報管理テーブル３２１に格納し、これらの情報にも基づいてサービス提供を制御してもよい。

図１９に戻り、サービス提供サーバ３００（Webセッション情報払出部３３２）は、続いて、領域２の画面を生成し（ステップＳ１３０）、ステップＳ１２９において払い出したWebセッション情報とともに、生成した領域２の画面を情報表示端末５５０に送信する（ステップＳ１３１）。

すると、情報表示端末５５０のＷｅｂブラウザには、領域２の画面が表示される（ステップＳ１３２）。例えば、図２１に示すような画面が表示される。

ところで、実施例１においては、セッション管理サーバ１００（サービス開始部１３３）は、ステップＳ１２１におけるサービス開始要求に応じて発側の情報表示端末５５０を制御すると同時に（あるいは直ちに）、着側の情報表示端末５５０についても制御する（ステップＳ１３３〜Ｓ１３９）。このため、発側の情報表示端末５５０および着側の情報表示端末５５０の両方が直ちにサービスを利用する状態となる。

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

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

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

この後、図２２に示すように、情報表示端末５５０（サービス利用部５５７）は、サービス提供サーバ３００に対する接続を完了したことを、制御用セッション情報およびサービスＩＤとともにセッション管理サーバ１００に通知する（ステップＳ１５０）。

すると、セッション管理サーバ１００（サービス開始部１３３）は、情報表示端末５５０から通知された制御用セッション情報が、制御用セッション管理テーブル１２４に登録されているものであることを確認するなどして（ステップＳ１５１）、その後、当該制御用セッション情報およびサービスＩＤをキーとしてアクセス中サービス管理テーブル１２５を検索し、検索したレコードのステータスを、『１』から『３』（サービス利用中）に更新する（ステップＳ１５２）。

着側の情報表示端末５５０（サービス利用部５５７）も同様に、接続完了をセッション管理サーバ１００に通知し（ステップＳ１５３）、セッション管理サーバ１００（サービス開始部１３３）は、制御用セッション情報の確認や、ステータスの更新を行う（ステップＳ１５４〜Ｓ１５５）。

［着側の情報表示端末５５０によるサービス開始要求が並行して行われないケース］
ところで、上記においては、両ＳＩＰフォン５００間でＳＩＰによって通信が確立されると、発側の情報表示端末５５０および着側の情報表示端末５５０のいずれもが、サービス開始要求を直ちに行う処理の手順を説明してきた。すなわち、発側の情報表示端末５５０が、図１５に示すステップＳ１０５〜Ｓ１１５の処理を行っているのとほぼ並行するようにして、着側の情報表示端末５５０が、図１８に示す処理を行っていることを想定してきた。しかしながら、本発明はこれに限られるものではない。

例えば、発側の情報表示端末５５０は、図１５に示すステップＳ１０５〜Ｓ１１５の処理を行ったものの、着側の情報表示端末５５０は、図１８に示す処理を行っていないとする。このような場合に、発側の情報表示端末５５０が図１９に示すステップＳ１２０の処理を行うと、上記してきたように、ステップＳ１２１〜Ｓ１３２の処理が行われる。この時、セッション管理サーバ１００は、例えば、ステップＳ１２５で発着間紐付けＩＤを払い出した際に、当該発着間紐付けＩＤが、着側の情報表示端末５５０に対しても払い出されたものであって、当該着側の情報表示端末５５０からのサービス開始要求待機中であることを記憶する。すると、例えば、ステップＳ１３０の段階で、着側の情報表示端末５５０が、図１８に示す処理を開始すると、図１８に示すように、着側の情報表示端末５５０の接続先監視機能とセッション管理サーバ１００との間でポーリングが行われ、このポーリングを用いることで、セッション管理サーバ１００は、待機中であった発着間紐付けＩＤ、および発着判定フラグを、当該着側の情報表示端末５５０に払い出すことができる。

［コールセンタタイプサービス］
ところで、上記においては、情報表示端末５５０に提供されるサービスが、ポータルタイプ（着信時にはサービス選択画面を表示するタイプ）のサービスであることを想定してきたが、本発明はこれに限られるものではなく、コールセンタタイプ（着信と同時にサービスを開始するタイプ）のサービスであってもよい。この場合の処理の手順について説明すると、まず、セッション管理サーバ１００は、図１５のステップＳ１１２において利用可能なサービスを確認し、これがコールセンタタイプのサービスである場合には、図１９のステップＳ１２３〜Ｓ１２５の処理を先に行う。その後、セッション管理サーバ１００は、図１５のステップＳ１１３に示すように、制御ページとして『領域１』および『領域２』を生成する。この時、『領域２』には、サービス提供サーバ３００のＵＲＬがリンク情報として埋め込まれるなどする。そして、セッション管理サーバ１００は、接続先監視機能、制御用セッション情報、発着間紐付けＩＤ、制御ページ（サービス提供サーバ３００のＵＲＬが埋め込まれている）を情報表示端末５５０に送信する。すると、情報表示端末５５０は、リダイレクトされるなどしてサービス提供サーバ３００に接続する。その後は、サービス提供サーバ３００において、図１９のステップＳ１２８と同様の処理が行われることになる。

［実施例１の効果］
上記してきたように、実施例１によれば、一時的な通信関係に基づいたサービス提供を実現する際に、情報表示端末の接続先を制御して一元管理することが可能になる。

また、実施例１によれば、ＳＩＰ−ＵＲＩなどの端末情報に基づいて、情報表示端末の接続先を制御することも可能になる。

また、実施例１によれば、発側の端末であるのか着側の端末であるのかの識別に基づいて、情報表示端末の接続先を制御することも可能になる。

また、実施例１によれば、サービスが、コールセンタタイプであるのかポータルタイプであるのかの識別に基づいて、情報表示端末の接続先を制御することも可能になる。

また、実施例１によれば、サービスが、発側の情報表示端末と着側の情報表示端末とに同一のＵＲＬで提供するものであるのか、異なるＵＲＬで提供するものであるのか、加入者であるのか未加入者であるのかによって異なるＵＲＬで提供するものであるのかの識別に基づいて、情報表示端末の接続先を制御することも可能になる。

また、実施例１によれば、仮名としての発着間紐付けＩＤを払い出した上で情報表示端末の接続先を制御して一元管理するので、セキュリティを向上させつつ、一時的な通信関係に基づいたサービス提供を実現することも可能になる。また、セッション管理サーバがこのような仮名情報を発行することで、サービス提供サーバは、callセッション情報（From、Toなど）を直接知ることなく、サービスを提供することが可能になる。これにより、callセッション情報を悪用した攻撃を防止することが可能になる他、通話記録などのプライバシ情報を守りつつサービス提供サーバによるサービス提供が可能になる。この動作は、いわゆるＷｅｂでのシングルサインオン（ＳＳＯ）と共通点があるが、本方式の特徴として、これら仮名情報は、セッション管理サーバ内にてcallセッション情報と紐付いており、セッション管理サーバ内で照合が可能であるため、何かトラブルが起きた時には、セッション管理サーバへの問い合わせを行うことで、これまでと同等にセッションが存在していたことを確認することが可能である。なお、callセッション情報を悪用した攻撃とは、例えば、接続中のセッションに対して同callセッション情報を含んだ切断指示を第三者が送信することで、利用者が意図しないサービス終了を第三者が引き起こすといったものである。

また、実施例１によれば、情報表示端末の利用者や、Ｗｅｂサービスの提供者は、情報表示端末の接続先について意識する必要が無くなる。

また、発側ユーザ（発側の情報表示端末の利用者）や着側ユーザ（着側の情報表示端末の利用者）のＷｅｂサービスへの加入状況（利用可否など）に基づいて、接続先を制御することも可能になる。

また、実施例１によれば、サービス提供装置は、ＳＩＰ通信を確立する毎に払い出されるユニークな発着間紐付けＩＤを用いて、ＳＩＰ通信を確立した端末各々の関係に基づいてＷｅｂサービスを制御することが可能になり、従来のＩＭサービスのように、バディリスト等に基づいた発着端末の紐付けが不要になる。

また、従来のＩＭサービスなどにおいては、当該ＩＭサービスに対応する専用アプリケーションが端末内にインストールされなければならなかったが、実施例１によれば、端末は、Ｗｅｂ通信（ＨＴＴＰ通信）を行うブラウザを基本機能として備えていればよく、サービスごとの専用アプリケーションを備える必要はない。

また、従来のＩＭサービスなどにおいては、当該ＩＭサービスを利用するにあたり、端末の利用者は、会員ＩＤやパスワード等を入力しなければならなかったが、実施例１によれば、端末の利用者は、ＳＩＰ通信の発信操作（例えば、番号入力）という簡易な操作のみで、Ｗｅｂサービスを利用することができる。

また、従来のＩＭサービスの中には、サービスを提供するＵＲＬを知る者であれば、誰でもアクセスすることが可能である、といったセキュリティレベルの低いサービスもあったが、実施例１によれば、少なくともＳＩＰにおける認証が行われた関係（ネットワークで接続が保証された通信相手との関係）であるという点で、セキュリティを確保することができる。

これまで、実施例１として、情報表示端末が初回のサービス開始要求を行う手法について説明してきたが、本発明に係るサービス提供システムは、その後、一方の情報表示端末が異なるサービスについてサービス開始要求を行うことで、他方の情報表示端末を当該異なるサービスに接続させることが可能である。そこで、以下では、実施例２として、情報表示端末がサービス変更要求（２回目以降のサービス開始要求）を行う手法について説明する。

［実施例２に係るサービス提供システムによる処理の手順］
図２３〜図２６を用いて、実施例２に係るサービス提供システムによる処理の手順を説明する。図２３は、実施例２に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス終了指示）であり、図２４は、アクセス中サービス管理テーブル確認処理を示すフローチャートであり、図２５は、競合サービスチェック処理を示すフローチャートであり、図２６は、実施例２に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス変更）である。

ところで、図２３では、発側の情報表示端末５５０と着側の情報表示端末５５０とが、すでにサービス提供サーバ３００（その１）のサービスを利用している状況を想定している。図２３は、このような状況から、発側の情報表示端末５５０と着側の情報表示端末５５０とが、サービス提供サーバ３００（その２）のサービスの利用を開始するまでの処理の手順を例示するものである。なお、サービス提供サーバ３００（その１）のサービスとサービス提供サーバ３００（その２）のサービスとが競合関係にある（同時に利用できない）ことを想定している。

図２３に示すように、まず、発側の情報表示端末５５０の利用者が、Ｗｅｂブラウザに表示された制御ページの中からサービスを選択することで（ステップＳ２０１）、情報表示端末５５０（サービス開始要求部５５６）は、サービス開始要求をセッション管理サーバ１００に対して送信する（ステップＳ２０２）。この時、情報表示端末５５０（サービス開始要求部５５６）は、初回のサービス開始要求と同様、制御用セッション情報を用いて、選択したサービスのサービスＩＤをセッション管理サーバ１００に対して送信するが、現在利用中のサービスとは異なるサービスについて、サービスＩＤを送信するものである。

すると、セッション管理サーバ１００（サービス開始部１３３）は、初回のサービス開始要求と同様、情報表示端末５５０から送信された制御用セッション情報が、制御用セッション管理テーブル１２４に登録されているものであることを確認し（ステップＳ２０３）、続いて、アクセス中サービス管理テーブル１２５を確認して、当該制御用セッション情報を設定する（ステップＳ２０４）。すなわち、セッション管理サーバ１００（サービス開始部１３３）は、情報表示端末５５０から送信されたサービス開始要求が、初回のものであるのか、あるいは、２回目以降（サービス変更要求）であるのかを確認すべく、アクセス中サービス管理テーブル１２５を確認する。ここでは、２回目のサービス開始要求であることを想定するので、セッション管理サーバ１００（サービス開始部１３３）は、情報表示端末５５０から送信された制御用セッション情報を設定する前に、図２４に示す確認処理を行う。

ここで、図２４を用いて、アクセス中サービス管理テーブルの確認処理を詳しく説明すると、まず、セッション管理サーバ１００（サービス開始部１３３）は、制御用セッショ情報をキーとして制御用セッション管理テーブル１２４を検索し、着側の制御用セッション情報を取得する（ステップＳ２０４−１）。例えば、図６に示す制御用セッション管理テーブル１２４を例に説明すると、セッション管理サーバ１００（サービス開始部１３３）は、制御用セッション情報『s11111111』をキーとして制御用セッション管理テーブル１２４を検索し、着側の制御用セッション情報『s22222222』を取得する。

続いて、セッション管理サーバ１００（サービス開始部１３３）は、着側の制御用セッション情報およびサービス開始要求で指定されたサービスＩＤをキーとしてアクセス中サービス管理テーブル１２５を検索する（ステップＳ２０４−２）。

そして、セッション管理サーバ１００（サービス開始部１３３）は、該当するレコードがあるか否かを判定する（ステップＳ２０４−３）。レコードがない場合（ステップＳ２０４−３否定）というのは、着側の情報表示端末５５０が、発側の情報表示端末５５０が利用を開始しようとしているサービスを未だ利用していない状況であるので、サービス開始要求の衝突は起きないと考えられ、セッション管理サーバ１００（サービス開始部１３３）は、次の処理へと移行すべく、処理を終了する。

一方、該当するレコードがある場合には（ステップＳ２０４−３肯定）、次に、セッション管理サーバ１００（サービス開始部１３３）は、ステータスを確認し（ステップＳ２０４−４）、ステータスが『１』であるか否かを判定する（ステップＳ２０４−５）。ステータスが『１』でない場合（ステップＳ２０４−５否定）というのは、ステータスが『３』か『４』の場合である。ステータスが『３』の場合というのは、着側の情報表示端末５５０が、発側の情報表示端末５５０が利用を開始しようとしているサービスをすでに利用している状況であるので、サービス開始要求の衝突は起きないと考えられ、セッション管理サーバ１００（サービス開始部１３３）は、次の処理へと移行すべく、処理を終了する。また、ステータスが『４』の場合というのは、着側の情報表示端末５５０が、発側の情報表示端末５５０が利用を開始しようとしているサービスを中断しようとしている状況であるので、しばらく処理をスリープして様子をみれば、結局、サービス開始要求の衝突は起きないと考えられ、セッション管理サーバ１００（サービス開始部１３３）は、次の処理へと移行すべく、処理を終了する。

一方、ステータスが『１』である場合（ステップＳ２０４−５肯定）というのは、着側の情報表示端末５５０が、発側の情報表示端末５５０が利用を開始しようとしているサービスをまさに利用しようと準備している状況であるので、サービス開始要求の衝突が起きると考えられ、セッション管理サーバ１００（サービス開始部１３３）は、発側の情報表示端末５５０に、サービス変更不可であることを通知する（ステップＳ２０４−６）。

このように、セッション管理サーバ１００（サービス開始部１３３）は、図２４に示す確認処理を行った後に、情報表示端末５５０から送信された制御用セッション情報をアクセス中サービス管理テーブル１２５に設定する。なお、実施例１や実施例２においては、サービス開始要求の衝突を回避する手法として、サービス開始要求が初回のものであるのか、あるいは、２回目以降（サービス変更要求）であるのかを確認し、後者の場合にのみ、着側の情報表示端末５５０について、アクセス中サービス管理テーブル１２５を確認する手法を説明したが、本発明はこれに限られるものではない。まず、サービス開始要求が初回の場合であっても、着側の情報表示端末５５０について、アクセス中サービス管理テーブル１２５を確認してもよい。例えば、両ＳＩＰフォン５００間にＳＩＰによって通信が確立される前に着側の情報表示端末５５０が既にサービスを開始していた場合などに、有効である。

また、アクセス中サービス管理テーブル１２５の確認は、着側（相手側）の情報表示端末５５０に関する確認のみならず、発側（自端末側）の情報表示端末５５０に関する確認を行うものであってもよい。例えば、セッション管理サーバ１００（サービス開始部１３３）は、まず、制御用セッション情報およびサービスＩＤをキーとしてアクセス中サービス管理テーブル１２５を検索し、該当するレコードがある場合、ステータスが『２』であるか否かを確認する。ステータス『２』というのは、着側の情報表示端末５５０がサービスの開始要求を行ったことで、発側の情報表示端末５５０もサービス利用準備中になったという状況であるので、サービス開始要求の衝突は起きると考えられ、セッション管理サーバ１００（サービス開始部１３３）は、発側の情報表示端末５５０に、サービス変更不可であることを通知する。その後、着側の情報表示端末５５０に関する確認を行ってもよい。

図２３に戻り、続いて、セッション管理サーバ１００（サービス開始部１３３）は、サービス提供サーバ３００へのアクセス権確認処理を行う（ステップＳ２０５）。なお、アクセス権確認処理は、図２０を用いて説明したものと同様の処理である。

次に、セッション管理サーバ１００（サービス開始部１３３）は、競合サービスチェック処理を行う（ステップＳ２０６）。ここで、図２５を用いて、競合サービスチェック処理を詳しく説明すると、まず、セッション管理サーバ１００（サービス開始部１３３）は、発着の制御用セッション情報をキーとしてアクセス中サービス管理テーブル１２５を検索し、ステータスが『３』（サービス利用中）となっているサービスＩＤを取得する（ステップＳ２０６−１）。すなわち、セッション管理サーバ１００（サービス開始部１３３）は、発側の情報表示端末５５０が利用を開始しようとしているサービスが、現在利用中のサービスと競合しているか否かを確認するべく、まずは、現在利用中のサービス（ステータスが『３』のサービス）を洗い出そうとするものである。このため、ステータスが『１』（サービス利用準備中）となっているサービスについては、処理をスリープしてから再確認し、ステータスが『３』に移行していれば、サービスＩＤを取得する。

続いて、セッション管理サーバ１００（サービス開始部１３３）は、取得されたサービスＩＤをキーとして競合サービス管理テーブル１２３を検索し、競合するサービスのサービスＩＤを取得する（ステップＳ２０６−２）。例えば、図５に示す競合サービス管理テーブル１２３を例に説明すると、セッション管理サーバ１００（サービス開始部１３３）は、現在アクセス中のサービスＩＤ『1111』をキーとして競合サービス管理テーブル１２３を検索し、サービスＩＤ『1112』を、競合するサービスのサービスＩＤとして取得する。

そして、セッション管理サーバ１００（サービス開始部１３３）は、ステップＳ２０６−３において競合サービスＩＤとして取得したサービスＩＤと、発側の情報表示端末５５０から送信されたサービス開始要求のサービスＩＤとが一致するか否かを判定する（ステップＳ２０６−３）。一致しない場合（ステップＳ２０６−３否定）には、セッション管理サーバ１００（サービス開始部１３３）は、次の処理（図２６のステップＳ２２０）へと移行すべく処理を終了する。

一方、一致した場合（ステップＳ２０６−３肯定）、発側の情報表示端末５５０が利用を開始しようとしているサービスと、現在アクセス中のサービスとが競合する場合であるので、セッション管理サーバ１００（サービス開始部１３３）は、現在アクセス中の当該サービスを終了させるべく、終了指示へと処理を移行する（ステップＳ２０６−４）。

すなわち、図２３に戻り、セッション管理サーバ１００（サービス開始部１３３）は、競合サービスの終了指示を行い（ステップＳ２０７）、サービス終了指示が、サービスＩＤとともに、情報表示端末５５０に送信される（ステップＳ２０８〜Ｓ２０９）。情報表示端末５５０は、サービス終了指示のダイアログをＷｅｂブラウザに表示するなどして（ステップＳ２１０）、その後、サービスの利用を強制的に終了する指示を、サービス提供サーバ３００（その１）に送信するなどする（ステップＳ２１１）。一方、セッション管理サーバ１００（サービス開始部１３３）は、アクセス中サービス管理テーブル１２５から、サービスを終了したレコードを削除する（ステップＳ２１２）。

なお、実施例２においては、競合サービスがある場合について、後勝ち方式（現在アクセス中の競合サービスを中止し、新しいサービスを開始する）を説明したが、本発明はこれに限られるものではなく、優先度が高いサービスを継続して、優先度が低いサービスを停止する方式や、発側優先方式、着側優先方式など、運用の形態に応じて適宜選択し得るものである。

さて、続いて、図２６に示すように、セッション管理サーバ１００（サービス開始部１３３）は、アクセス中サービス管理テーブル１２５に、利用予定のサービスＩＤに関するレコードを設定する（ステップＳ２２０）。この時、発側の制御用セッション情報に対応づけて登録するレコードについては、ステータスを『１』と設定し、着側の制御用セッション情報に対応づけて登録するレコードについては、ステータスを『２』と設定してもよい。ステータス『２』は、相手側（ここでは、発側）からの要求でサービス利用準備中であることを示すもので、このように区別して管理してもよい。

その後、セッション管理サーバ１００（サービス開始部１３３）は、初回のサービス開始要求と同様、サービス提供サーバ３００（その２）について、ステップＳ２２１以降の処理を行う。また、サービス提供サーバ３００（その２）も、初回のサービス開始要求時のサービス提供サーバ３００（その１）と同様、ステップＳ２２４以降の処理を行う。

こうして、発側の情報表示端末５５０および着側の情報表示端末５５０においてサービス提供サーバ３００（その２）の利用が開始されると、実施例１と同様（図２２を参照）、情報表示端末５５０（サービス利用部５５７）は、サービス提供サーバ３００（その２）に対する接続を完了したことを、制御用セッション情報およびサービスＩＤとともに接続先監視機能を介してセッション管理サーバ１００に通知し、セッション管理サーバ１００（サービス開始部１３３）は、当該制御用セッション情報およびサービスＩＤをキーとしてアクセス中サービス管理テーブル１２５を検索し、検索したレコードのステータスを、発側の情報表示端末５５０については『１』から『３』に更新し、着側の情報表示端末５５０については『２』から『３』に更新する。

［実施例２の効果］
上記してきたように、実施例２によれば、一方の情報表示端末の利用者によるリクエストによって、他方の情報表示端末のサービスを切り替えることが可能になる。

また、サービスを切り替える際に、サービスの競合を考慮して切り替えることも可能になる。

本発明に係るサービス提供システムは、一方の情報表示端末が、他方の情報表示端末の出力部に出力されている画面を変更することが可能である。すなわち、発側の情報表示端末と着側の情報表示端末との間で画面を同期させることが可能である。そこで、以下では、実施例３として、発側の情報表示端末と着側の情報表示端末との間で画面を同期させる手法について説明する。

［実施例３に係るサービス提供システムによる処理の手順］
図２７および図２８を用いて、実施例３に係るサービス提供システムによる処理の手順を説明する。図２７は、実施例３に係るサービス提供システムによる処理の手順を示すシーケンス図（画面変更）であり、図２８は、ステータス確認処理を示すフローチャートである。

ところで、図２７では、発側の情報表示端末５５０と着側の情報表示端末５５０とが、すでにサービス提供サーバ３００のサービスを利用している状況を想定している。図２７は、このような状況において、着側の情報表示端末５５０からの要求で、着側の情報表示端末５５０が、発側の情報表示端末５５０の画面を変更させるものである。

図２７に示すように、まず、着側の情報表示端末５５０の利用者が、Ｗｅｂブラウザに表示された制御ページの中においてボタンを押下することで（ステップＳ３０１）、情報表示端末５５０（サービス利用部５５７）は、画面変更のための情報通知をサービス提供サーバ３００に対して送信する（ステップＳ３０２）。この時、情報表示端末５５０（サービス利用部５５７）は、Webセッション情報および発着間紐付けＩＤをサービス提供サーバ３００に送信する。

すると、サービス提供サーバ３００（サービス提供部３３３）は、情報表示端末５５０から送信されたWebセッション情報および発着間紐付けＩＤをキーとしてWebセッション情報管理テーブル３２１を検索し、Webセッション情報および発着間紐付けＩＤを確認してから（ステップＳ３０３）、発側の情報表示端末５５０にアクセスして欲しいサイトや内容等を特定できるパラメータ（発側アクセス用パラメータ）を指定する（ステップＳ３０４）。なお、発側アクセス用パラメータとしては、ＵＲＬやＵＲＩ（例えば、ＵＲＬの一部）を指定する手法が考えられるが、これに限定されるものではなく、サイトや内容等を特定できる情報であれば、どのようなパラメータであってもよい。

そして、サービス提供サーバ３００（サービス提供部３３３）は、着側の情報表示端末５５０に表示させる着側画面を生成し（ステップＳ３０５）、発側アクセス用パラメータとともに、着側の情報表示端末５５０に送信する（ステップＳ３０６）。

すると、着側の情報表示端末５５０のＷｅｂブラウザが、接続先監視機能部５５８を起動するなどすることで（ステップＳ３０７）、情報表示端末５５０（接続先監視機能部５５８）は、発側の情報表示端末５５０の画面を変更することを指示する発側画面変更確認指示を、セッション管理サーバ１００に対して送信する（ステップＳ３０８）。この時、情報表示端末５５０（接続先監視機能部５５８）は、制御用セッション情報、発着間紐付けＩＤ、発側アクセス用パラメータとともに送信する。

一方、セッション管理サーバ１００（画面変更部１３４）は、着側の情報表示端末５５０から送信された制御用セッション情報および発着間紐付けＩＤをキーとして発着間紐付けＩＤテーブル１２６を検索し、発側の制御用セッション情報およびサービスＩＤを取得する（ステップＳ３０９）。なお、実施例３においては、着側の情報表示端末５５０が、制御用セッション情報および発着間紐付けＩＤを送信し、セッション管理サーバ１００（画面変更部１３４）は、これらの情報を用いて発側の制御用セッション情報およびサービスＩＤを取得する手法を説明したが、本発明はこれに限られるものではない。例えば、着側の情報表示端末５５０が、制御用セッション情報およびサービスＩＤを送信し、セッション管理サーバ１００（画面変更部１３４）は、これらの情報を用いて発側の制御用セッション情報およびサービスＩＤを取得する手法でもよい。あるいは、例えば、着側の情報表示端末５５０が、発着間紐付けＩＤおよび発着判定フラグを送信し、セッション管理サーバ１００（画面変更部１３４）は、これらの情報を用いて発側の制御用セッション情報およびサービスＩＤを取得する手法でもよい。

続いて、セッション管理サーバ１００（画面変更部１３４）は、アクセス中サービス管理テーブル１２５のステータス確認処理を行う（ステップＳ３１０）。ここで、図２８を用いて、ステータス確認処理を詳しく説明すると、まず、セッション管理サーバ１００（画面変更部１３４）は、発側の制御用セッション情報およびサービスＩＤをキーとしてアクセス中サービス管理テーブル１２５を検索する（ステップＳ３１０−１）。

該当するレコードがない場合（ステップＳ３１０−２否定）というのは、発側の情報表示端末５５０において、画面変更を実現したいサービスが利用されていない場合であるので、着側の情報表示端末５５０は、発側の情報表示端末５５０に当該サービスを利用させるべく、実施例２で説明した手法などによって、サービス開始要求を行う（ステップＳ３１０−３）。

一方、該当するレコードがある場合（ステップＳ３１０−２肯定）、セッション管理サーバ１００（画面変更部１３４）は、次に、ステータスを確認する（ステップＳ３１０−４）。そして、ステータスが『３』の場合（ステップＳ３１０−５肯定）というのは、発側の情報表示端末５５０が、該当するサービスを利用している場合であるので、セッション管理サーバ１００（画面変更部１３４）は、発側の情報表示端末５５０に発側画面変更確認指示を送信する処理へと移行する（ステップＳ３１０−６）。

ステータスが『３』ではなく（ステップＳ３１０−５否定）、『１』か『２』である場合（ステップＳ３１０−７肯定）というのは、発側の情報表示端末５５０が、サービス利用準備中であるか、着側の情報表示端末５５０の要求を受けてサービス利用準備中である場合であるので、セッション管理サーバ１００（画面変更部１３４）は、処理をスリープしてから（ステップＳ３１０−８）、レコードがあるか否かを確認する処理に戻る（ステップＳ３１０−４）。なお、ステータスが『４』でもない場合（ステップＳ３１０−７否定、ステップＳ３１０−９否定）は、何らかのエラー発生であるとして、処理を中断するなどする。

ステータスが『４』の場合（ステップＳ３１０−９肯定）というのは、発側の情報表示端末５５０が、サービス中断処理中であるので、セッション管理サーバ１００（画面変更部１３４）は、処理をスリープしてから（ステップＳ３１０−１０）、ステータスを確認する処理に戻る（ステップＳ３１０−４）。

［発側アクセス用パラメータが既知であるケース］
ところで、上記においては、サービス提供サーバ３００が発側アクセス用パラメータを指定し、着側の情報表示端末５５０が、サービス提供サーバ３００から受信した発側アクセス用パラメータをセッション管理サーバ１００に送信する手法を説明してきたが、本発明はこれに限られるものではない。例えば、発側アクセス用パラメータがＷｅｂページに予め埋め込まれている場合などには、着側の情報表示端末５５０は、ステップＳ３０１でボタンを押下した後に、ステップＳ３０７の処理を開始し、Ｗｅｂページに埋め込まれている発側アクセス用パラメータをセッション管理サーバ１００に送信すればよい。

［実施例３の効果］
上記してきたように、実施例３によれば、発側の情報表示端末と着側の情報表示端末との間で画面を同期させることも可能になる。また、サービス提供サーバ側に画面変更のロジックを作りこむ従来の手法とは異なり、サービス提供サーバ側が画面変更のロジックを作りこむ必要が無くなり、サービスの開発（ひいては提供）を容易にすることが可能になる。

本発明に係るサービス提供システムは、情報表示端末の接続先を監視することが可能である。例えば、情報表示端末が許容されていないサイトに接続した際に、当該情報表示端末の利用者に警告を通知することが可能である。そこで、以下では、実施例４として、情報表示端末が許容されていないサイトに接続した際に、当該情報表示端末の利用者に警告を通知する手法について説明する。

［実施例４に係るサービス提供システムによる処理の手順］
図２９を用いて、実施例４に係るサービス提供システムによる処理の手順を説明する。図２９は、実施例４に係るサービス提供システムによる処理の手順を説明するためのシーケンス図である。

図２９に示すように、まず、サービス提供サーバ３００が、情報表示端末５５０のＷｅｂブラウザに表示する画面の情報を情報表示端末５５０に通知すると（ステップＳ４０１）、情報表示端末５５０は、Ｗｅｂブラウザにおいて当該画面情報を取得する（ステップＳ４０２）。なお、実施例４において、情報表示端末５５０は、この段階で取得した画面情報を表示しないので、セキュリティという観点からは望ましい形態であるが、取得した画面情報を表示した上で、後述する処理の手順を行ってもよい。後者の手法の方が、画面情報を表示するまでの時間は短縮されることになる（結果的に許容されている接続先であった場合などには、後者の手法の方が使い勝手が良いことになる）。

すると、情報表示端末５５０（接続先監視機能部５５８）は、Ｗｅｂブラウザに表示されている画面情報を吸出し（ステップＳ４０３）、情報表示端末５５０が接続しているサービス提供サーバ３００のＵＲＬを解析する（ステップＳ４０４）。

そして、情報表示端末５５０（接続先監視機能部５５８）は、ステップＳ４０４において解析したアクセス先ＵＲＬと、発着間紐付けＩＤと、制御用セッション情報とを、セッション管理サーバ１００に送信する（ステップＳ４０５）。

一方、セッション管理サーバ１００（接続先警告部１３５）は、情報表示端末５５０から送信された制御用セッション情報が制御用セッション管理テーブル１２４に登録されているか否かを確認するなどし（ステップＳ４０６）、続いて、情報表示端末５５０から送信された発着間紐付けＩＤおよび制御用セッション情報が、発着間紐付けＩＤテーブル１２６に登録されているか否かを確認するなどする（ステップＳ４０７）。

そして、セッション管理サーバ１００（接続先警告部１３５）は、情報表示端末５５０から送信された発着間紐付けＩＤおよび制御用セッション情報をキーとして発着間紐付けＩＤテーブル１２６を検索し、サービスＩＤを取得する（ステップＳ４０８）。

続いて、セッション管理サーバ１００（接続先警告部１３５）は、取得したサービスＩＤをキーとして契約サービス情報テーブル１２２を検索し、契約サービス情報テーブル１２２からＵＲＬテーブル（アクセス先ＵＲＬ、着側ＵＲＬなど）を取得して、情報表示端末５５０から送信されたアクセス先ＵＲＬと、当該ＵＲＬテーブルに登録されているＵＲＬとが一致するか否かを確認する（ステップＳ４０９）。

あるいは、セッション管理サーバ１００（接続先警告部１３５）は、アクセス許容ＵＲＬテーブル１２７を検索し、情報表示端末５５０から送信されたＵＲＬが含まれているか否かを確認する（ステップＳ４０９）。

この結果、情報表示端末５５０から送信されたＵＲＬが、ＵＲＬテーブルに登録されているＵＲＬと一致しない場合や、アクセス許容ＵＲＬテーブル１２７に含まれていない場合には、セッション管理サーバ１００（接続先警告部１３５）は、当該ＵＲＬが、許容されていない接続先であることを情報表示端末５５０に対して通知する（ステップＳ４１０）。すると、情報表示端末５５０は、警告ダイアログをＷｅｂブラウザに表示するなどする（ステップＳ４１１）。

［実施例４の効果］
上記してきたように、実施例４によれば、情報表示端末が許容されていないサイトに接続した際に、当該情報表示端末の利用者に警告を通知することが可能になる。この結果、情報表示端末の利用者は、接続先について意識する必要が無くなる。すなわち、情報表示端末の利用者は、自らが意識的に選択したサイト以外のサイトに当該情報表示端末が接続してしまった場合にも、警告を通知されることで、選択したサイト以外のサイトに接続していることを気づくことができる。この結果、利用者は、接続先について特に意識することなく、不正なサイトへの接続を回避したり切断することができる。

本発明に係るサービス提供システムは、ＳＩＰによって確立された通信と、当該通信を引き継いで行われたＷｅｂ通信とを連携させることが可能である。例えば、ＳＩＰによって確立された呼が切断された際に、サービスを強制的に終了させることが可能である。そこで、以下では、実施例５として、ＳＩＰによって確立された呼が切断された際に、サービス提供を強制的に終了させる手法について説明する。

［実施例５に係るサービス提供システムによる処理の手順］
図３０を用いて、実施例５に係るサービス提供システムによる処理の手順を説明する。図３０は、実施例５に係るサービス提供システムによる処理の手順を説明するためのシーケンス図である。

図３０に示すように、まず、ＳＩＰプロキシ２００（ＳＩＰ通信制御部２３１）が制御することで、両ＳＩＰフォン５００（ＳＩＰ通信部５０４）間で、ステップＳ５０１〜Ｓ５０２のＳＩＰ通信が行われ、その結果、ステップＳ５０３において、両ＳＩＰフォン５００間でＳＩＰによって確立された通信が切断される。

すると、ＳＩＰプロキシ２００（callセッション情報等送信部２３２）が、ＳＩＰによって確立された通信が切断されたことを示す切断情報を、切断された通信を識別するcallセッション情報（実施例５においては、Call-ID）とともに、セッション管理サーバ１００に送信する（ステップＳ５０４）。

セッション管理サーバ１００（強制切断部１３６）は、ＳＩＰプロキシ２００から送信されたCall-IDをキーとして制御用セッション管理テーブル１２４を検索し、発着の制御用セッション情報を取得する（ステップＳ５０５）。

続いて、セッション管理サーバ１００（強制切断部１３６）は、発着の制御用セッション情報をキーとしてアクセス中サービス管理テーブル１２５を検索し、発着の制御用セッション情報を含むレコードを削除する（ステップＳ５０６）。

また、セッション管理サーバ１００（強制切断部１３６）は、ＳＩＰによって確立された通信が切断されたことを、発着の情報表示端末５５０に通知する（ステップＳ５０７）。この時、情報表示端末５５０（接続先監視機能部５５８）は、制御用セッション情報を用いてセッション管理サーバ１００に対してポーリングを行っているので、セッション管理サーバ１００（強制切断部１３６）は、制御用セッション情報を用いて情報表示端末５５０を特定し、通話切断を通知する（ステップＳ５０８）。なお、セッション管理サーバ１００（強制切断部１３６）は、通話切断通知ととともにＨＧＷ４００のＵＲＬを送信する。このＨＧＷ４００のＵＲＬは、図１５のステップＳ１０９において、ＨＧＷ４００から通知されていたものである。

すると、情報表示端末５５０（接続先監視機能部５５８）は、セッション管理サーバ１００から送信されたＨＧＷ４００のＵＲＬを用いて、ＨＧＷ４００への接続指示をＷｅｂブラウザに対して行う（ステップＳ５０９）。情報表示端末５５０がＨＧＷ４００に接続すると（ステップＳ５１０）、ＨＧＷ４００は、通話待ちの画面を生成し（ステップＳ５１１）、情報表示端末５５０に送信する（ステップＳ５１２）。すると、情報表示端末５５０においては、通話待ち画面が表示される（ステップＳ５１３）。

［実施例５の効果］
上記してきたように、実施例５によれば、ＳＩＰによって確立された通信と、当該通信を引き継いで行われたＷｅｂ通信とを連携させることも可能になる。

また、実施例５によれば、サービス提供サーバ側に画面遷移のロジックを作りこむ従来の手法とは異なり、サービス提供サーバ側が画面遷移のロジックを作りこむ必要が無くなり、サービスの開発（ひいては提供）を容易にすることが可能になる。

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

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

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

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

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

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

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

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

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

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

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

以上のように、本発明に係るサービス提供システム、サービス提供方法およびサービス提供プログラムは、ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供サーバが当該サービスを制御することに有用であり、特に、一時的な通信関係に基づいたサービス提供を実現する際に、端末の接続先を制御して一元管理することに適する。

実施例１に係るサービス提供システムの概要および特徴を説明するための図である。セッション管理サーバの構成を示すブロック図である。ユーザ契約サービス管理テーブルを説明するための図である。契約サービス情報テーブルを説明するための図である。競合サービス管理テーブルを説明するための図である。制御用セッション管理テーブルを説明するための図である。アクセス中サービス管理テーブルを説明するための図である。発着間紐付けＩＤテーブルを説明するための図である。アクセス許容ＵＲＬテーブルを説明するための図である。ＳＩＰプロキシの構成を示すブロック図である。サービス提供サーバの構成を示すブロック図である。 Webセッション情報管理テーブルを説明するための図である。端末側の構成を説明するための図である。ブラウザセッション情報管理テーブルを説明するための図である。実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（発側）である。利用可能なサービス確認処理の手順を示すフローチャートである。制御ページを説明するための図である。実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（着側）である。実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス開始要求）である。アクセス権確認処理の手順を示すフローチャートである。制御ページを説明するための図である。実施例１に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス開始後）である。実施例２に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス終了指示）である。アクセス中サービス管理テーブル確認処理を示すフローチャートである。競合サービスチェック処理を示すフローチャートである。実施例２に係るサービス提供システムによる処理の手順を示すシーケンス図（サービス変更）である。実施例３に係るサービス提供システムによる処理の手順を示すシーケンス図（画面変更）である。ステータス確認処理を示すフローチャートである。実施例４に係るサービス提供システムによる処理の手順を説明するためのシーケンス図である。実施例５に係るサービス提供システムによる処理の手順を説明するためのシーケンス図である。従来技術を説明するための図である。

符号の説明

１００セッション管理サーバ
１１０通信部
１２０記憶部
１２１ユーザ契約サービス管理テーブル
１２２契約サービス情報テーブル
１２３競合サービス管理テーブル
１２４制御用セッション管理テーブル
１２５アクセス中サービス管理テーブル
１２６発着間紐付けＩＤテーブル
１２７アクセス許容ＵＲＬテーブル
１３０制御部
１３１制御ページ生成部
１３２接続先監視部
１３３サービス開始部
１３４画面変更部
１３５接続先警告部
１３６強制切断部
２００ＳＩＰプロキシ
２１０通信部
２３０制御部
２３１ＳＩＰ通信制御部
２３２ callセッション情報等送信部
３００サービス提供サーバ
３１０通信部
３２０記憶部
３２１ Webセッション情報管理テーブル
３３０制御部
３３１発着間紐付けＩＤ受信部
３３２ Webセッション情報払出部
３３３サービス提供部
４００ＨＧＷ
４１０ＳＩＰ通信部／ＨＴＴＰ通信部
４２０記憶部
４２１ブラウザセッション情報管理テーブル
４３０制御部
４３１ callセッション情報等取得部
４３２ＳＩＰフォンＩＤ収集部
４３３情報表示端末特定部
４３４アクセス先変更指示部
５００ＳＩＰフォン
５０１入力部
５０２出力部
５０３入出力制御Ｉ／Ｆ部
５０４ＳＩＰ通信部
５５０情報表示端末
５５１入力部
５５２出力部
５５３入出力制御Ｉ／Ｆ部
５５４ＨＴＴＰ通信部
５５５制御部
５５６サービス開始要求部
５５７サービス利用部
５５８接続先監視機能部

Claims

ネットワークに接続される第１の端末および第２の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供システムであって、
前記サービス提供装置とは異なるセッション管理装置は、
前記第１の端末と組で利用される他の端末と前記第２の端末と組で利用される他の端末との間で第１の通信が確立された場合に、複数のサービス提供装置のうち所定のサービス提供装置によって提供されるサービスを開始することを要求する開始要求を前記第１の端末から受け付けると、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第１の端末を制御する制御情報を、前記第１の通信が確立されたことを示す第１通信情報とともに当該第１の端末に送信し、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第２の端末を制御する制御情報を前記第１通信情報とともに当該第２の端末に送信することで、当該第１の端末および当該第２の端末の接続先を制御する接続先制御手段を備え、
前記第１の端末および前記第２の端末のそれぞれは、
前記接続先制御手段によって送信された制御情報に制御されることで、複数のサービス提供装置のうち前記開始要求した前記サービスを提供するサービス提供装置に接続し、当該サービス提供装置が提供するサービスを利用することを要求する利用要求を、前記第１通信情報とともに当該サービス提供装置に送信する利用要求送信手段を備え、
前記開始要求された前記サービスを提供するサービス提供装置は、
前記利用要求を前記第１の端末または前記第２の端末から受け付けた際に、前記第１通信情報を取得する第１通信情報取得手段と、
前記利用要求を受け付けた前記第１の端末または前記第２の端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手段によって取得された第１通信情報に対応づけて第２通信情報記憶手段に格納する第２通信情報格納手段と、
前記第２通信情報記憶手段に格納されている複数の第１通信情報の内、所定の第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶手段に格納されている第２通信情報各々を用いて前記第１の端末と前記第２の端末との間に提供されるサービスを、互いに関連づけて制御するサービス提供制御手段と、
を備えたことを特徴とするサービス提供システム。
前記セッション管理装置は、
前記第１の通信を確立した端末と組で利用される前記第１の端末を示す第１の端末情報、および／または、当該第１の通信を確立した他方の端末と組で利用される前記第２の端末を示す第２の端末情報に応じて、当該第１の端末情報で示される前記第１の端末および／または当該第２の端末情報で示される前記第２の端末が利用可能なサービスを記憶する利用可能サービス記憶手段をさらに備え、
前記接続先制御手段は、
前記開始要求を前記第１の端末情報および／または前記第２の端末情報とともに受け付けると、当該第１の端末情報および／または当該第２の端末情報に基づいて前記利用可能サービス記憶手段から利用可能なサービスを提供するサービス提供装置を判定し、当該サービス提供装置に接続するように、前記第１の端末情報で示される前記第１の端末および／または前記第２の端末情報で示される前記第２の端末の接続先を制御することを特徴とする請求項１に記載のサービス提供システム。
前記接続先制御手段は、
前記開始要求を前記第１の端末情報および／または前記第２の端末情報とともに受け付ける際に、前記第１の端末の前記ネットワーク上でのアドレスを示す第１端末アドレスおよび／または前記第２の端末の前記ネットワーク上でのアドレスを示す第２端末アドレスを取得し、当該第１端末アドレスを用いて当該第１の端末情報が正しい情報であるか否かを検証、および／または、当該第２端末アドレスを用いて当該第２の端末情報が正しい情報であるか否かを検証し、検証の結果、正しい情報であるとされる当該第１の端末情報および／または当該第２の端末情報に基づいて、前記接続先を制御することを特徴とする請求項２に記載のサービス提供システム。
前記利用可能サービス記憶手段は、前記第１の端末情報および／または前記第２の端末情報の他に、当該第１の端末情報で示される前記第１の端末および／または当該第２の端末情報で示される前記第２の端末が、前記第１の通信を発信した発側の端末であるのか、もしくは、前記第１の通信を着信した着側の端末であるのかを識別する発着フラグにも応じて、前記利用可能なサービスを記憶し、
前記接続先制御手段は、
前記開始要求を前記第１の端末情報および／または前記第２の端末情報の他に前記発着フラグもともに受け付けると、当該第１の端末情報および／または当該第２の端末情報の他に当該発着フラグにも基づいて利用可能なサービスを提供するサービス提供装置を判定し、前記接続先を制御することを特徴とする請求項２または３に記載のサービス提供システム。
前記利用可能サービス記憶手段は、前記利用可能なサービス各々が、着信と同時に前記第１の端末または前記第２の端末をサービス提供装置に接続させてサービスを開始すべきコールセンタタイプサービスであるのか、もしくは、サービスの開始に先立ち前記第１の端末または前記第２の端末の出力部にサービス選択画面を出力させるべきポータルタイプサービスであるのかを識別する着信同時接続フラグにも応じて、前記利用可能なサービスを記憶し、
前記接続先制御手段は、
前記第１の端末情報および／または前記第２の端末情報の他に前記着信同時接続フラグにも基づいて利用可能なサービスを提供するサービス提供装置を判定し、前記接続先を制御することを特徴とする請求項２〜４のいずれか一つに記載のサービス提供システム。
前記利用可能サービス記憶手段は、前記利用可能なサービス各々が、第１の通信を発信した発側の端末を接続させるべき接続先情報と当該第１の通信を着信した着側の端末を接続させるべき接続先情報とを同一の情報で提供するものであるのか、もしくは、異なる情報で提供するものであるのか、もしくは、前記端末がサービスの加入者であるのか未加入者であるのかによって異なる情報で提供するものであるのかを識別する接続タイプにも応じて、前記利用可能なサービスを記憶し、
前記接続先制御手段は、
前記第１の端末情報および／または前記第２の端末情報の他に前記接続タイプにも基づいて利用可能なサービスを提供するサービス提供装置を判定し、前記接続先を制御することを特徴とする請求項２〜５のいずれか一つに記載のサービス提供システム。
前記接続先制御手段は、
前記開始要求を前記第１の通信を一意に識別する第１通信識別情報とともに受け付けた場合には、当該第１通信識別情報の仮名として前記第１通信情報を払い出し、当該第１通信情報を前記制御情報とともに前記第１の端末および前記第２の端末に送信することで、当該第１の端末および当該記第２の端末の接続先を制御することを特徴とする請求項１〜６のいずれか一つに記載のサービス提供システム。
前記セッション管理装置は、
前記第１の端末または前記第２の端末の接続が許容される許容接続先を記憶する許容接続先記憶手段をさらに備え、
前記第１の端末または前記第２の端末それぞれは、
当該第１の端末または当該第２の端末が現に接続している接続先情報を取得し、当該接続先情報を前記接続先制御手段に送信する接続先情報送信手段をさらに備え、
前記接続先制御手段は、
前記接続先情報送信手段によって送信された接続先情報が、前記許容接続先記憶手段によって記憶されている許容接続先に該当するか否かを判定し、該当しない場合には、許容されていない接続先に接続していることを警告する警告情報を、当該接続先情報を送信した前記第１の端末または前記第２の端末に送信することで、当該第１の端末または当該第２の端末の接続先をさらに制御することを特徴とする請求項１〜７のいずれか一つに記載のサービス提供システム。
前記セッション管理装置は、
前記第１の端末または前記第２の端末が現に接続している接続先情報および／または当該端末が現に利用しているサービスを示すサービス情報を記憶する利用サービス記憶手段と、
前記サービス提供装置が提供するサービス各々の競合関係を示す競合情報を記憶する競合情報記憶手段とをさらに備え、
前記接続先制御手段は、
現に利用しているサービスとは異なるサービスを利用することを要求する変更要求を前記第１の端末または前記第２の端末から受け付けると、前記利用サービス記憶手段によって記憶されている接続先情報および／またはサービス情報に基づいて当該第１の端末または当該第２の端末が現に利用しているサービスを判定し、当該サービスと当該変更要求で指定されたサービスとが競合関係にあるか否かを前記競合情報記憶手段によって記憶されている競合情報に基づいて判定し、当該判定に基づいて当該第１の端末または当該第２の端末の接続先をさらに制御し、
前記第１の端末または前記第２の端末それぞれは、
前記変更要求を前記接続先制御手段に送信する変更要求送信手段をさらに備えたことを特徴とする請求項１〜８のいずれか一つに記載のサービス提供システム。
前記接続先制御手段は、
前記サービス提供装置によって互いに関連づけて制御されている前記第１の端末または前記第２の端末の出力部に出力されている画面情報を変更させることを要求する変更要求を、変更要求先の当該第１の端末または当該第２の端末が変更にあたって接続すべき接続先を示す変更用接続先情報とともに変更要求元の前記第２の端末または前記第１の端末から受け付けると、当該変更用接続先情報で示される所定の接続先に接続するように制御する制御情報を変更要求先の当該第１の端末または当該第２の端末に送信することで、変更要求先の当該第１の端末または当該第２の端末の接続先をさらに制御し、
変更要求元の前記第２の端末または前記第１の端末のそれぞれは、
前記変更要求を前記変更用接続先情報とともに前記接続先制御手段に送信する変更要求送信手段をさらに備え、
前記サービス提供装置は、
前記変更要求を変更要求元の前記第２の端末または前記第１の端末から受け付けると、前記変更用接続先情報を変更要求元の当該第２の端末または当該第１の端末に送信する変更用接続先情報送信手段をさらに備え、
前記サービス提供制御手段は、前記変更用接続先情報によって示される接続先に前記第１の端末または前記第２の端末から接続されると、当該第１の端末または当該第２の端末の出力部に出力されている画面情報を変更させるようにさらに制御することを特徴とする請求項１〜９のいずれか一つに記載のサービス提供システム。
前記接続先制御手段は、
前記第１の通信が切断されたことを示す切断情報を当該第１の通信を制御する第１通信制御装置から受け付けると、現に接続している接続先であるサービス提供装置が提供するサービスの利用を終了するように接続先を変更する制御情報を当該第１の通信を確立した端末と組で利用される前記第１の端末および前記第２の端末に送信することで、当該第１の端末および当該第２の端末の接続先をさらに制御することを特徴とする請求項１〜１０のいずれか一つに記載のサービス提供システム。
ネットワークに接続される第１の端末および第２の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供方法であって、
前記サービス提供装置とは異なるセッション管理装置は、
前記第１の端末と組で利用される他の端末と前記第２の端末と組で利用される他の端末との間で第１の通信が確立された場合に、複数のサービス提供装置のうち所定のサービス提供装置によって提供されるサービスを開始することを要求する開始要求を前記第１の端末から受け付けると、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第１の端末を制御する制御情報を、前記第１の通信が確立されたことを示す第１通信情報とともに当該第１の端末に送信し、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第２の端末を制御する制御情報を前記第１通信情報とともに当該第２の端末に送信することで、当該第１の端末および当該第２の端末の接続先を制御する接続先制御工程を含み、
前記第１の端末および前記第２の端末のそれぞれは、
前記接続先制御工程によって送信された制御情報に制御されることで、複数のサービス提供装置のうち前記開始要求した前記サービスを提供するサービス提供装置に接続し、当該サービス提供装置が提供するサービスを利用することを要求する利用要求を、前記第１通信情報とともに当該サービス提供装置に送信する利用要求送信工程を含み、
前記開始要求された前記サービスを提供するサービス提供装置は、
前記利用要求を受け付けた前記第１の端末または前記第２の端末から受け付けた際に、前記第１通信情報を取得する第１通信情報取得工程と、
前記利用要求を受け付けた前記第１の端末または前記第２の端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得工程によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納工程と、
前記第２通信情報記憶部に格納されている複数の第１通信情報の内、所定の第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて前記第１の端末と前記第２の端末との間に提供されるサービスを、互いに関連づけて制御するサービス提供制御工程と、
を含んだことを特徴とするサービス提供方法。
ネットワークに接続される第１の端末および第２の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供方法をコンピュータに実行させるサービス提供プログラムであって、
前記サービス提供装置とは異なるセッション管理装置に、
前記第１の端末と組で利用される他の端末と前記第２の端末と組で利用される他の端末との間で第１の通信が確立された場合に、複数のサービス提供装置のうち所定のサービス提供装置によって提供されるサービスを開始することを要求する開始要求を前記第１の端末から受け付けると、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第１の端末を制御する制御情報を、前記第１の通信が確立されたことを示す第１通信情報とともに当該第１の端末に送信し、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第２の端末を制御する制御情報を前記第１通信情報とともに当該第２の端末に送信することで、当該第１の端末および当該第２の端末の接続先を制御する接続先制御手順を実行させ、
前記第１の端末および前記第２の端末のそれぞれに、
前記接続先制御手順によって送信された制御情報に制御されることで、複数のサービス提供装置のうち前記開始要求した前記サービスを提供するサービス提供装置に接続し、当該サービス提供装置が提供するサービスを利用することを要求する利用要求を、前記第１通信情報とともに当該サービス提供装置に送信する利用要求送信手順を実行させ、
前記開始要求された前記サービスを提供するサービス提供装置に、
前記利用要求を前記第１の端末または前記第２の端末から受け付けた際に、前記第１通信情報を取得する第１通信情報取得手順と、
前記利用要求を受け付けた前記第１の端末または前記第２の端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手順によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納手順と、
前記第２通信情報記憶部に格納されている複数の第１通信情報の内、所定の第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて前記第１の端末と前記第２の端末との間に提供されるサービスを、互いに関連づけて制御するサービス提供制御手順と、
を実行させることを特徴とするサービス提供プログラム。
ネットワークに接続される第１の端末および第２の端末に当該ネットワーク上のサービスを提供するサービス提供装置が、当該サービスを制御するサービス提供システムであって、
前記サービス提供装置とは異なるセッション管理装置は、
前記第１の端末と前記第２の端末との間で第１の通信が確立された場合に、複数のサービス提供装置のうち所定のサービス提供装置によって提供されるサービスを開始することを要求する開始要求を前記第１の端末から受け付けると、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第１の端末を制御する制御情報を、前記第１の通信が確立されたことを示す第１通信情報とともに当該第１の端末に送信し、前記開始要求された当該サービスを提供するサービス提供装置に接続するように前記第２の端末を制御する制御情報を前記第１通信情報とともに当該第２の端末に送信することで、当該第１の端末および当該第２の端末の接続先を制御する接続先制御手段を備え、
前記第１の端末および前記第２の端末のそれぞれは、
前記接続先制御手段によって送信された制御情報に制御されることで、複数のサービス提供装置のうち前記開始要求した前記サービスを提供するサービス提供装置に接続し、当該サービス提供装置が提供するサービスを利用することを要求する利用要求を、前記第１通信情報とともに当該サービス提供装置に送信する利用要求送信手段を備え、
前記開始要求された前記サービスを提供するサービス提供装置は、
前記利用要求を前記第１の端末または前記第２の端末から受け付けた際に、前記第１通信情報を取得する第１通信情報取得手段と、
前記利用要求を受け付けた前記第１の端末または前記第２の端末が当該サービス提供装置との間で前記サービスを利用する際に行う第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手段によって取得された第１通信情報に対応づけて第２通信情報記憶手段に格納する第２通信情報格納手段と、
前記第２通信情報記憶手段に格納されている複数の第１通信情報の内、所定の第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶手段に格納されている第２通信情報各々を用いて前記第１の端末と前記第２の端末との間に提供されるサービスを、互いに関連づけて制御するサービス提供制御手段と、
を備えたことを特徴とするサービス提供システム。