(57)【要約】  サービス提供サーバ（１０）は、端末（３０）間で確立された通信を識別するｃａｌｌセッション情報と端末（３０）を識別するサービス利用ＩＤとを端末（３０）毎に収集する。そして、サービス提供サーバ（１０）は、同一の通信を示すｃａｌｌセッション情報各々を特定し、Ｗｅｂサービス各々を関連づける。また、サービス提供サーバ（１０）は、関連づけたＷｅｂサービス各々を端末（３０）各々に提供する際に、端末（３０）各々を識別するサービス利用ＩＤ各々を特定し、サービス利用ＩＤ各々に対応づけて履歴情報ＤＢに記憶されている履歴情報に従う内容でＷｅｂサービス各々が提供されるようにＷｅｂサービス提供を制御する。
2010044471.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上のサービスを端末に提供するサービス提供システムであって、
端末間で確立された通信を識別する通信情報を端末毎に収集する通信情報収集手段と、
端末もしくは端末の利用者を識別する識別情報を前記通信情報と組の情報として端末毎に収集する識別情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から同一の通信を示す通信情報各々を特定し、特定した通信情報各々によって識別される通信を確立した端末各々に提供するサービス各々を関連づける関連づけ手段と、
前記関連づけ手段によって関連づけられたサービス各々を端末各々に提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該端末各々もしくは当該端末各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、
を備えたことを特徴とするサービス提供システム。
【請求項２】
前記端末間で確立された通信は、ＳＩＰによって確立された通信であって、
前記通信情報収集手段は、端末間でＳＩＰによって確立された通信を識別する通信情報を端末毎に収集することを特徴とする請求項１に記載のサービス提供システム。
【請求項３】
前記サービス提供システムは、
端末間で通信を確立するセッション管理サーバと、
前記通信情報収集手段と前記識別情報収集手段と前記関連づけ手段と前記サービス提供手段とを備えたサービス提供サーバとを有するものであって、
前記セッション管理サーバは、
端末を識別する識別情報を発行する識別情報発行手段を備え、
前記サービス提供サーバは、
前記サービス提供手段によって提供されたサービスの履歴情報を前記識別情報発行手段によって発行された識別情報と対応づけて記憶部に格納する格納手段をさらに備え、
前記識別情報収集手段は、前記識別情報発行手段によって発行された識別情報を前記通信情報と組の情報として端末毎に収集し、
前記サービス提供手段は、特定した識別情報各々に対応づけて記憶部に記憶されている履歴情報に従う内容でサービス各々が提供されるようにサービス提供を制御することを特徴とする請求項１または２に記載のサービス提供システム。
【請求項４】
前記サービス提供システムは、
端末間で通信を確立するセッション管理サーバと、
前記通信情報収集手段と前記識別情報収集手段と前記関連づけ手段と前記サービス提供手段とを備えたサービス提供サーバとを有するものであって、
前記セッション管理サーバは、
端末を識別する識別情報を発行する識別情報発行手段を備え、
前記サービス提供サーバは、
端末の利用者に関する情報を記憶する利用者情報記憶手段と、
前記識別情報発行手段によって発行された識別情報と、前記利用者情報記憶手段によって記憶されている利用者に関する情報とを対応づける利用者情報対応づけ手段とをさらに備え、
前記識別情報収集手段は、前記識別情報発行手段によって発行された識別情報を前記通信情報と組の情報として端末毎に収集し、
前記サービス提供手段は、特定した識別情報各々に前記利用者情報対応づけ手段によって対応づけられた利用者に関する情報に従う内容でサービス各々が提供されるようにサービス提供を制御することを特徴とする請求項１または２に記載のサービス提供システム。
【請求項５】
前記サービス提供システムは、
端末間で通信を確立するセッション管理サーバと、
前記通信情報収集手段と前記識別情報収集手段と前記関連づけ手段と前記サービス提供手段とを備えたサービス提供サーバとを有するものであって、
前記セッション管理サーバは、
端末を識別する識別情報を発行する識別情報発行手段と、
前記識別情報発行手段によって発行された識別情報と、前記端末の利用者を識別する利用者識別情報とを対応づける利用者識別情報対応づけ手段と、
前記利用者識別情報対応づけ手段によって対応づけられた利用者識別情報を前記サービス提供サーバに対して送信する利用者識別情報送信手段と、
をさらに備え、
前記サービス提供サーバは、
利用者識別情報と当該利用者識別情報によって識別される利用者に関する情報とを対応づけて記憶する利用者情報記憶手段をさらに備え、
前記識別情報収集手段は、前記利用者識別情報送信手段によって送信された利用者識別情報を前記通信情報と組の情報として端末毎に収集し、
前記サービス提供手段は、前記識別情報収集手段によって収集された複数の利用者識別情報の中から前記端末各々の利用者各々を識別する利用者識別情報各々を特定し、特定した利用者識別情報各々に対応づけて前記利用者情報記憶手段に記憶されている利用者に関する情報に従う内容でサービス各々が提供されるようにサービス提供を制御することを特徴とする請求項１または２に記載のサービス提供システム。
【請求項６】
前記識別情報発行手段は、端末とサービス提供サーバとの組合せごとに異なる識別情報を発行することを特徴とする請求項１に記載のサービス提供システム。
【請求項７】
前記識別情報発行手段は、検証可能な形式で識別情報を発行することを特徴とし、
前記サービス提供サーバは、
前記識別情報収集手段が識別情報を検証可能な形式で収集すると、当該識別情報に関する事実を検証する識別情報検証手段をさらに備えたことを特徴とする請求項１に記載のサービス提供システム。
【請求項８】
ネットワーク上のサービスを端末に提供するサービス提供方法であって、
端末間で確立された通信を識別する通信情報を端末毎に収集する通信情報収集工程と、
端末もしくは端末の利用者を識別する識別情報を前記通信情報と組の情報として端末毎に収集する識別情報収集工程と、
前記通信情報収集工程によって収集された複数の通信情報の中から同一の通信を示す通信情報各々を特定し、特定した通信情報各々によって識別される通信を確立した端末各々に提供するサービス各々を関連づける関連づけ工程と、
前記関連づけ工程によって関連づけられたサービス各々を端末各々に提供する際に、前記識別情報収集工程によって収集された複数の識別情報の中から当該端末各々もしくは当該端末各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供工程と、
を含んだことを特徴とするサービス提供方法。
【請求項９】
ネットワーク上のサービスをクライアント側システムに提供するサービス提供システムであって、
クライアント側システム間で確立された通信を識別する通信情報をクライアント側システム毎に収集する通信情報収集手段と、
クライアント側システムもしくはクライアント側システムの利用者を識別する識別情報を前記通信情報と組の情報としてクライアント側システム毎に収集する識別情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から同一の通信を示す通信情報各々を特定し、特定した通信情報各々によって識別される通信を確立したクライアント側システム各々に提供するサービス各々を関連づける関連づけ手段と、
前記関連づけ手段によって関連づけられたサービス各々をクライアント側システム各々に提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該クライアント側システム各々もしくは当該クライアント側システム各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、
を備えたことを特徴とするサービス提供システム。
【請求項１０】
ネットワーク上のサービスを端末に提供するサービス提供システムであって、
前記サービスを提供するサービス提供サーバは、
当該サービス提供サーバと端末との間で確立された通信を識別する通信情報を端末毎に収集する通信情報収集手段と、
端末もしくは端末の利用者を識別する識別情報を前記通信情報と組の情報として端末毎に収集する識別情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から当該サービス提供サーバとの間で確立した通信を示す通信情報を特定し、特定した通信情報によって識別される通信を確立した端末にサービスを提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該端末各々もしくは当該端末各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、
を備えたことを特徴とするサービス提供システム。
【請求項１１】
ネットワーク上のサービスを端末に提供するサービス提供サーバであって、
端末間で確立された通信を識別する通信情報を端末毎に収集する通信情報収集手段と、
端末もしくは端末の利用者を識別する識別情報を前記通信情報と組の情報として端末毎に収集する識別情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から同一の通信を示す通信情報各々を特定し、特定した通信情報各々によって識別される通信を確立した端末各々に提供するサービス各々を関連づける関連づけ手段と、
前記関連づけ手段によって関連づけられたサービス各々を端末各々に提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該端末各々もしくは当該端末各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、
を備えたことを特徴とするサービス提供サーバ。
【請求項１２】
ネットワーク上のサービスをクライアント側システムに提供するサービス提供サーバであって、
クライアント側システム間で確立された通信を識別する通信情報をクライアント側システム毎に収集する通信情報収集手段と、
クライアント側システムもしくはクライアント側システムの利用者を識別する識別情報を前記通信情報と組の情報としてクライアント側システム毎に収集する識別情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から同一の通信を示す通信情報各々を特定し、特定した通信情報各々によって識別される通信を確立したクライアント側システム各々に提供するサービス各々を関連づける関連づけ手段と、
前記関連づけ手段によって関連づけられたサービス各々をクライアント側システム各々に提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該クライアント側システム各々もしくは当該クライアント側システム各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、
を備えたことを特徴とするサービス提供サーバ。
【請求項１３】
ネットワーク上のサービスを端末に提供するサービス提供サーバであって、
当該サービス提供サーバと端末との間で確立された通信を識別する通信情報を端末毎に収集する通信情報収集手段と、
端末もしくは端末の利用者を識別する識別情報を前記通信情報と組の情報として端末毎に収集する識別情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から当該サービス提供サーバとの間で確立した通信を示す通信情報を特定し、特定した通信情報によって識別される通信を確立した端末にサービスを提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該端末各々もしくは当該端末各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、
を備えたことを特徴とするサービス提供サーバ。
【請求項１４】
コンピュータを請求項１１に記載のサービス提供サーバとして機能させるサービス提供プログラム。
【請求項１５】
コンピュータを請求項１２に記載のサービス提供サーバとして機能させるサービス提供プログラム。
【請求項１６】
コンピュータを請求項１３に記載のサービス提供サーバとして機能させるサービス提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス提供システムおよびサービス提供方法に関する。
【背景技術】
【０００２】
従来、ＩＰ（Internet  Protocol）ネットワークに接続する端末に提供されるサービスとして、ＷＷＷ（World  Wide  Web）関連技術を用いたＷｅｂサービスがある。また、Ｗｅｂサービスの中には、ＩＭ（Instant  Messaging）サービスなど、高度なＷｅｂサービスがある。例えば、ＩＭサービスを提供するサービス提供サーバは、端末各々に対して提供するＷｅｂサービスを端末同士で連携させることで、チャットや画像データの共有など、高度なＷｅｂサービスを提供する。【０００３】
この時、ＩＭサービスを利用する端末は、サービス提供サーバに対して予め会員登録をしている。また、端末は、他の会員との間で互いの会員ＩＤを交換し、バディリストに予め登録している。こうして、サービス提供サーバは、予め登録された会員同士のバディ関係に基づいてＷｅｂサービスを制御し、Ｗｅｂサービスを会員同士で連携させる。なお、例えば、特許文献１には、会員管理を一元化することで、新しいサービスを利用する際の会員登録を不要とする技術が開示されている。また、例えば、特許文献２には、一般的なブラウザを用いてアプリケーション共有を行う技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２２８１２２号公報
【特許文献２】特開２００３−０４４４２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、上記した従来の技術では、高度なＷｅｂサービスを柔軟に提供することができないという課題があった。近年、ネットワークを介してアドホックな（一時的な）通信関係を結ぶ端末同士が多く存在するが、このような通信関係の端末同士に対しても、高度なＷｅｂサービスを提供することが望まれる。しかしながら、予め会員登録をすることが前提の従来の技術では、サービス提供サーバは、アドホックな通信関係を結ぶ端末同士に対して高度なＷｅｂサービスを提供することができない。【０００６】
そこで、本発明は、上記した従来の技術の課題を解決するためになされたものであり、アドホックな通信関係にも対応するなど、高度なＷｅｂサービスを柔軟に提供することを第一の目的とする。【０００７】
また、本発明は、アドホックな通信関係に対応するとともに、利用者に関する各種情報とも連携した付加価値の高いＷｅｂサービスを提供することを第二の目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するため、ネットワーク上のサービスを端末に提供するサービス提供システムは、端末間で確立された通信を識別する通信情報を端末毎に収集する通信情報収集手段と、端末もしくは端末の利用者を識別する識別情報を前記通信情報と組の情報として端末毎に収集する識別情報収集手段と、前記通信情報収集手段によって収集された複数の通信情報の中から同一の通信を示す通信情報各々を特定し、特定した通信情報各々によって識別される通信を確立した端末各々に提供するサービス各々を関連づける関連づけ手段と、前記関連づけ手段によって関連づけられたサービス各々を端末各々に提供する際に、前記識別情報収集手段によって収集された複数の識別情報の中から当該端末各々もしくは当該端末各々の利用者各々を識別する識別情報各々を特定し、特定した識別情報各々に対応づけて記憶部に記憶されている情報に従う内容でサービス各々が提供されるようにサービス提供を制御するサービス提供手段と、を備える。
【発明の効果】
【０００９】
アドホックな通信関係にも対応するなど、高度なＷｅｂサービスを柔軟に提供する。【００１０】
また、アドホックな通信関係に対応するとともに、利用者に関する各種情報とも連携した付加価値の高いＷｅｂサービスを提供する。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施例１に係るサービス提供システムの概要を説明するための図である。
【図２】図２は、端末の構成を示すブロック図である。
【図３】図３は、セッション管理サーバの構成を示すブロック図である。
【図４】図４は、ｃａｌｌセッション情報ＤＢを説明するための図である。
【図５】図５は、サービス利用情報ＤＢを説明するための図である。
【図６】図６は、証明書を説明するための図である。
【図７】図７は、証明書に添付される署名を説明するための図である。
【図８】図８は、サービス提供サーバの構成を示すブロック図である。
【図９】図９は、セッション情報ＤＢを説明するための図である。
【図１０】図１０は、店舗情報ＤＢを説明するための図である。
【図１１】図１１は、履歴情報ＤＢを説明するための図である。
【図１２】図１２は、実施例１に係るサービス提供システムによる処理手順を示すシーケンス図である。
【図１３】図１３は、証明書発行部による処理手順を示すフローチャートである。
【図１４】図１４は、サービス提供部による処理手順を示すフローチャートである。
【図１５】図１５は、実施例２に係るサービス提供システムの概要を説明するための図である。
【図１６】図１６は、サービス提供サーバの構成を示すブロック図である。
【図１７】図１７は、ユーザ情報ＤＢを説明するための図である。
【図１８】図１８は、実施例２に係るサービス提供システムによる処理手順を示すシーケンス図である。
【図１９】図１９は、サービス提供部による処理手順を示すフローチャートである。
【図２０】図２０は、サービス提供画面を説明するための図である。
【図２１】図２１は、実施例３に係るサービス提供システムの概要を説明するための図である。
【図２２】図２２は、セッション管理サーバの構成を示すブロック図である。
【図２３】図２３は、サービス利用情報ＤＢを説明するための図である。
【図２４】図２４は、証明書を説明するための図である。
【図２５】図２５は、セッション情報ＤＢを説明するための図である。
【図２６】図２６は、ユーザ情報ＤＢを説明するための図である。
【図２７】図２７は、実施例３に係るサービス提供システムによる処理手順を示すシーケンス図である。
【図２８】図２８は、実施例３に係るサービス提供システムによる処理手順を示すシーケンス図である。
【図２９】図２９は、証明書発行部による処理手順を示すフローチャートである。
【図３０】図３０は、証明書を説明するための図である。
【図３１】図３１は、サービス提供画面を説明するための図である。
【図３２】図３２は、Ｐａｒｌａｙ  Ｘを利用してセッション管理サーバとＳＩＰサーバとの間の通信を実現する一例を説明するための図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、本発明に係るサービス提供システムおよびサービス提供方法の実施例を詳細に説明する。以下では、実施例１に係るサービス提供システムの概要、構成、処理手順、実施例１の効果を順に説明し、その後、他の実施例を説明する。
【実施例１】
【００１３】
［実施例１に係るサービス提供システムの概要］
まず、図１を用いて、実施例１に係るサービス提供システムの概要を説明する。図１は、実施例１に係るサービス提供システムの概要を説明するための図である。【００１４】
図１に示すように、実施例１に係るサービス提供システムは、サービス提供サーバ１０とセッション管理サーバ２０と端末３０とを備える。まず、端末３０間でＳＩＰ（Session  Initiation  Protocol）によって通信が確立され、次に、サービス提供サーバ１０が端末３０各々にＨＴＴＰ（Hyper  Text  Transfer  Protocol）通信にてＷｅｂサービスを提供する。【００１５】
具体的に説明すると、まず、端末３０間でＳＩＰによって通信が確立され、端末３０間で音声通話が開始される（図１の（１）を参照）。【００１６】
次に、セッション管理サーバ２０は、端末３０各々に対して、ｃａｌｌセッション情報とサービス利用ＩＤとを記載した証明書を発行する（図１の（２）を参照）。ここで、ｃａｌｌセッション情報とは、端末３０間でＳＩＰによって確立された通信を識別する情報であり、また、サービス利用ＩＤとは、端末３０を識別する情報である。【００１７】
そして、端末３０各々は、セッション管理サーバ２０から発行された証明書をサービス利用要求とともにサービス提供サーバ１０に送信する（図１の（３）を参照）。【００１８】
一方、サービス提供サーバ１０は、図１に示すように、サービス利用ＩＤと履歴情報とを対応づけて履歴情報ＤＢに記憶している。すなわち、サービス提供サーバ１０は、Ｗｅｂサービスを利用したことのある端末３０については、当該端末３０を識別するサービス利用ＩＤと対応づけて履歴情報を記憶している。このため、サービス提供サーバ１０は、端末３０から証明書を受け付けると、証明書に記載されているサービス利用ＩＤを用いて履歴情報ＤＢを参照し、履歴情報を検索する（図１の（４）を参照）。【００１９】
そして、サービス提供サーバ１０は、端末３０各々から送信されたｃａｌｌセッション情報各々が同一の通信を示すｃａｌｌセッション情報であることを特定し、端末３０各々に提供するＷｅｂサービスを連携させるとともに、検索した履歴情報に従う内容でサービス各々が提供されるようにサービス提供を制御する（図１の（５）を参照）。【００２０】
また、サービス提供サーバ１０は、端末３０各々に提供したＷｅｂサービスの履歴情報を履歴情報ＤＢに格納する（図１の（６）を参照）。【００２１】
このようなことから、実施例１に係るサービス提供システムによれば、アドホックな通信関係にも対応するなど、高度なＷｅｂサービスを柔軟に提供することが可能になる。【００２２】
すなわち、端末３０各々は、サービス提供サーバ１０に予め会員登録しているわけではなく、また、予めバディ関係を登録しているわけでもない。端末３０各々の関係は、ＳＩＰによって通信を確立したというアドホックな通信関係にすぎない。この点、実施例１に係るサービス提供システムは、アドホックな通信関係を識別するｃａｌｌセッション情報を用いることで、サービス提供サーバ１０にアドホックな通信関係をその都度把握させ、Ｗｅｂサービスの連携など高度なＷｅｂサービスを柔軟に提供させている。【００２３】
また、実施例１に係るサービス提供システムによれば、利用者に関する各種情報とも連携した付加価値の高いＷｅｂサービスを提供することが可能になる。【００２４】
すなわち、サービス提供サーバ１０は、端末３０各々を予め会員登録しているわけではなく、端末３０各々の関係をｃａｌｌセッション情報を用いて把握しているにすぎない。この点、実施例１に係るサービス提供システムは、端末３０を識別するサービス利用ＩＤを発行し、サービス利用ＩＤを用いることで、サービス提供サーバ１０に端末３０を把握させている。この結果、サービス提供サーバ１０は、Ｗｅｂサービスを利用したことのある端末３０について履歴情報を蓄積することができ、再び端末３０にＷｅｂサービスを提供する際には、履歴情報とも連携した付加価値の高いＷｅｂサービスを提供することができるのである。【００２５】
［実施例１に係るサービス提供システムの構成］
次に、図２〜図１１を用いて、実施例１に係るサービス提供システムの構成を説明する。以下では、端末３０の構成、セッション管理サーバ２０の構成、サービス提供サーバ１０の構成を順に説明する。【００２６】
［端末］
まず、図２を用いて、端末３０の構成を説明する。図２は、端末の構成を示すブロック図である。端末３０は、以下に説明する各部が汎用的なＰＣ（Personal  Computer）などに備えられることによって実現され、図２に示すように、ＳＩＰ通信部３１と、ｃａｌｌセッション情報収集部３２と、ｃａｌｌセッション情報送信部３３と、サービス利用部３４とを備える。【００２７】
ＳＩＰ通信部３１は、他の端末３０との間でＳＩＰによって通信を確立する過程の通信（以下、ＳＩＰ通信と呼ぶ）や、ＳＩＰによって確立された通信を行う。具体的には、ＳＩＰ通信部３１は、ｃａｌｌセッション情報収集部３２と接続され、他の端末３０との間でＳＩＰによって通信を確立すると、通信を確立した旨をｃａｌｌセッション情報収集部３２に通知する。なお、端末３０で行われるＳＩＰ通信やＳＩＰによって確立された通信は、セッション管理サーバ２０を介して行われる。【００２８】
ｃａｌｌセッション情報収集部３２は、他の端末３０との間で確立された通信を一意に識別するｃａｌｌセッション情報を収集する。具体的には、ｃａｌｌセッション情報収集部３２は、ＳＩＰ通信部３１とｃａｌｌセッション情報送信部３３と接続され、通信を確立した旨をＳＩＰ通信部３１から通知されると、ＳＩＰ通信に含まれる情報からｃａｌｌセッション情報を収集し、収集したｃａｌｌセッション情報をｃａｌｌセッション情報送信部３３に通知する。【００２９】
ここで、ｃａｌｌセッション情報について説明する。本来、セッション情報とは、ＯＳＩ（Open  Systems  Interconnection）でいうところの第５層で通信を一意に識別する情報である。すなわち、実施例１に係るサービス提供システムにおいては、通信として、ＳＩＰ通信とＨＴＴＰ通信とが行われることを想定しているが、ＳＩＰ通信もＨＴＴＰ通信も、いずれもＴＣＰ（Transmission  Control  Protocol）通信であるという点で、第４層では識別することができない。このため、端末３０間で確立された通信にセッション情報が付与されることで、当該通信がＳＩＰ通信であるのか、あるいはＨＴＴＰ通信であるのかが識別される。すなわち、ｃａｌｌセッション情報とは、ＳＩＰ通信であることを示すセッション情報である。【００３０】
また、セッション情報は、単にＳＩＰ通信とＨＴＴＰ通信とを識別するのみならず、端末３０間で確立された通信が、他の端末３０間で確立された通信とは異なる通信であることをも識別する。これを言い換えると、ｃａｌｌセッション情報とは、端末３０間でＳＩＰによって確立された通信を識別する情報である。例えば、ｃａｌｌセッション情報収集部３２は、ＳＩＰ通信に含まれる『Call-ID』、または、『From』、『To』、『tag』、ＩＰアドレス、もしくは、これらの組合せを収集したり、ＳＩＰ通信に含まれるその他の情報を収集する。なお、ｃａｌｌセッション情報は、ＳＩＰによって確立された通信を一意に識別することが可能な情報であれば、どのような情報であってもよい。【００３１】
ｃａｌｌセッション情報送信部３３は、セッション管理サーバ２０に対してｃａｌｌセッション情報を送信する。具体的には、ｃａｌｌセッション情報送信部３３は、ｃａｌｌセッション情報収集部３２と接続され、ｃａｌｌセッション情報をｃａｌｌセッション情報収集部３２から通知されると、通知されたｃａｌｌセッション情報をセッション管理サーバ２０に送信する。なお、実施例１における端末３０は、セッション管理サーバ２０のＵＲＬ（Uniform  Resource  Locator）を予め記憶部（図示を省略）に記憶している。このため、ｃａｌｌセッション情報送信部３３は、記憶部を参照してセッション管理サーバ２０のＵＲＬを取得し、取得したＵＲＬに対してｃａｌｌセッション情報を送信する。【００３２】
サービス利用部３４は、サービス提供サーバ１０によって提供されるサービスの提供を受ける。具体的には、サービス利用部３４は、サービスの提供を受けるにあたり、セッション管理サーバ２０にて発行されて送信された証明書をサービス提供サーバ１０に送信する。また、サービス利用部３４は、Ｗｅｂセッション情報をサービス提供サーバ１０から受信し、受信したＷｅｂセッション情報をＷｅｂブラウザに付与し、サービス提供サーバ１０にアクセスする。【００３３】
ここで、Ｗｅｂセッション情報について説明する。ｃａｌｌセッション情報と同様、Ｗｅｂセッション情報とは、ＨＴＴＰ通信であることを示すセッション情報である。また、Ｗｅｂセッション情報とは、端末３０とサービス提供サーバ１０との間で確立されたＨＴＴＰ通信を一意に識別する情報である。例えば、Ｗｅｂセッション情報は、ＣｏｏｋｉｅのＩＤなどによって実現される。なお、Ｗｅｂセッション情報は、端末３０とサービス提供サーバ１０との間で確立されたＨＴＴＰ通信を一意に識別することが可能な情報であれば、どのような情報であってもよい。【００３４】
［セッション管理サーバ］
次に、図３〜図７を用いて、セッション管理サーバ２０の構成を説明する。図３は、セッション管理サーバの構成を示すブロック図であり、図４は、ｃａｌｌセッション情報ＤＢを説明するための図であり、図５は、サービス利用情報ＤＢを説明するための図であり、図６は、証明書を説明するための図であり、図７は、証明書に添付される署名を説明するための図である。【００３５】
セッション管理サーバ２０は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図３に示すように、ｃａｌｌセッション情報ＤＢ２１と、サービス利用情報ＤＢ２２と、ＳＩＰ通信制御部２３と、ｃａｌｌセッション情報検証部２４と、証明書発行部２５とを備える。【００３６】
ｃａｌｌセッション情報ＤＢ２１は、ｃａｌｌセッション情報を記憶する。具体的には、ｃａｌｌセッション情報ＤＢ２１は、ＳＩＰ通信制御部２３とｃａｌｌセッション情報検証部２４と証明書発行部２５と接続され、ＳＩＰ通信制御部２３やｃａｌｌセッション情報検証部２４、あるいは証明書発行部２５による処理に利用される。【００３７】
例えば、ｃａｌｌセッション情報ＤＢ２１は、図４に示すような情報を記憶する。ここで、実施例１におけるセッション管理サーバ２０は、端末３０から送信されたｃａｌｌセッション情報をそのまま記載して証明書を発行するのではなく、ｃａｌｌセッション情報を暗号化して証明書を発行する。このため、図４に示すように、ｃａｌｌセッション情報ＤＢ２１は、端末３０から送信されたｃａｌｌセッション情報『Call-ID』、『From』および『To』とは別に、これらのｃａｌｌセッション情報に対応づけて暗号化された『ｃａｌｌセッション情報』を記憶する。【００３８】
サービス利用情報ＤＢ２２は、サービス利用情報を記憶する。具体的には、サービス利用情報ＤＢ２２は、証明書発行部２５と接続され、証明書発行部２５による処理に利用される。【００３９】
例えば、サービス利用情報ＤＢ２２は、図５に示すように、『ＳＩＰ−ＵＲＩ（Uniform  Resource  Identifier）』、『サービス提供サーバＵＲＩ』、および『サービス利用ＩＤ』を対応づけて記憶する。実施例１におけるセッション管理サーバ２０は、端末と、当該端末が利用するサービスとの組合せごとに、サービス利用ＩＤを発行する。このため、サービス利用情報ＤＢ２２は、端末を一意に識別する『ＳＩＰ−ＵＲＩ』と、サービスを一意に識別する『サービス提供サーバＵＲＩ』との組合せに対応づけて、『サービス利用ＩＤ』を記憶する。例えば、図５の３行目に示す『0422591111@idp.com』と４行目に示す『0422591111@idp.com』とは、同一の端末を識別するＳＩＰ−ＵＲＩであるが、利用するサービスごとに異なるサービス利用ＩＤ『USER1-web1-SP-id』と『USER1-web2-SP-id』とが発行されている。なお、サービス利用ＩＤは、サービス提供サーバ１０において端末３０を識別する情報であればどのような情報でもよく、例えば、乱数であってもよい。【００４０】
ＳＩＰ通信制御部２３は、端末３０間で行われるＳＩＰ通信や、ＳＩＰによって確立された通信、あるいは、ＳＩＰによって確立された通信を切断する通信などを制御する。また、ＳＩＰ通信制御部２３は、ｃａｌｌセッション情報ＤＢ２１とｃａｌｌセッション情報検証部２４と接続され、端末３０から送信されたｃａｌｌセッション情報をcallセッション情報ＤＢ２１に格納し、格納した旨をｃａｌｌセッション情報検証部２４に通知する。例えば、ＳＩＰ通信制御部２３は、端末３０から送信されたｃａｌｌセッション情報『Call-ID』、または、『From』、『To』、『tag』、ＩＰアドレス、もしくは、これらの組合せやＳＩＰに含まれるその他の情報をセッション情報ＤＢ２１に格納する。なお、図４は、ＳＩＰ通信制御部２３が、ｃａｌｌセッション情報の内、例えば、『Call-ID』、『From』および『To』をｃａｌｌセッション情報ＤＢ２１に格納した図である。【００４１】
ｃａｌｌセッション情報検証部２４は、ｃａｌｌセッション情報を検証する。具体的には、ｃａｌｌセッション情報検証部２４は、ｃａｌｌセッション情報ＤＢ２１とＳＩＰ通信制御部２３と証明書発行部２５と接続され、ｃａｌｌセッション情報を格納した旨をＳＩＰ通信制御部２３から通知されると、ｃａｌｌセッション情報ＤＢ２１を参照する。そして、ｃａｌｌセッション情報検証部２４は、格納されたｃａｌｌセッション情報が、確かにセッション管理サーバ２０が確立した通信を一意に識別する情報であるか否かなどを検証し、検証結果を証明書発行部２５に通知する。【００４２】
証明書発行部２５は、サービス利用ＩＤを発行し、ｃａｌｌセッション情報とサービス利用ＩＤとを記載した証明書を発行する。具体的には、証明書発行部２５は、ｃａｌｌセッション情報ＤＢ２１と、サービス利用情報ＤＢ２２と、ｃａｌｌセッション情報検証部２４と接続され、検証結果をｃａｌｌセッション情報検証部２４から通知されると、ｃａｌｌセッション情報ＤＢ２１を参照し、暗号化したｃａｌｌセッション情報をｃａｌｌセッション情報ＤＢ２１に格納する。【００４３】
また、証明書発行部２５は、サービス選択情報を端末３０から受け付けると、端末３０を一意に識別するＳＩＰ−ＵＲＩと、サービス選択情報によって示されるサービスを一意に識別するサービス提供サーバＵＲＩとの組合せに対応づけてサービス利用ＩＤを発行し、サービス利用情報ＤＢ２２に格納する。そして、証明書発行部２５は、ｃａｌｌセッション情報ＤＢ２１に格納したｃａｌｌセッション情報と、サービス利用情報ＤＢ２２に格納したサービス利用ＩＤとを記載した証明書を発行し、端末３０に対して送信する。この時、証明書発行部２５は、サービス提供サーバ１０のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示とともに送信する。【００４４】
例えば、証明書発行部２５は、図６および図７に示すように、ｃａｌｌセッション情報およびサービス利用ＩＤにセッション管理サーバ２０の署名を添付したＳＡＭＬ（Security  Assertion  Markup  Language）形式の証明書を発行する。なお、図６において、署名等は省略されており、図７は、署名および公開鍵を示すものである。ここで、ＳＡＭＬ形式とは、認証のための情報をＸＭＬ（Extensible  Markup  Language）で記述されたデータで交換することを目的として策定されたプロトコルであり、データが改竄されていないことや、データの発行元などを署名によって検証可能な形式である。証明書発行部２５は、ｃａｌｌセッション情報と、サービス利用ＩＤと、セッション管理サーバ２０の公開鍵が真正であることを証明する認証局発行の証明書と、セッション管理サーバ２０の秘密鍵でcallセッション情報およびサービス利用ＩＤ（ハッシュ値）を暗号化した署名とを、ＳＡＭＬ形式で記述したものを発行するなどする。【００４５】
なお、実施例１においては、ｃａｌｌセッション情報およびサービス利用ＩＤを送信する手法としてＸＭＬ形式の証明書を発行する手法を説明するが、本発明はこれに限られるものではない。ｃａｌｌセッション情報およびサービス利用ＩＤを送信する手法としては、例えば、ＨＴＴＰでサポートされるＧＥＴメソッドによる手法（ｃａｌｌセッション情報およびサービス利用ＩＤを取得可能なＵＲＩをパラメータとして送信する手法）、ＰＯＳＴメソッドによる手法（所定のフォームの本文にｃａｌｌセッション情報およびサービス利用ＩＤが記載されて送信される手法）などでもよい。また、これらの手法においては、パラメータに署名を添付することで、ＸＭＬ形式の証明書と同様、データが改竄されていないことや、データの発行元などを署名によって検証可能な形式にすることも可能である。【００４６】
［サービス提供サーバ］
続いて、図８〜図１１を用いて、サービス提供サーバ１０の構成を説明する。図８は、サービス提供サーバの構成を示すブロック図であり、図９は、セッション情報ＤＢを説明するための図であり、図１０は、店舗情報ＤＢを説明するための図であり、図１１は、履歴情報ＤＢを説明するための図である。【００４７】
サービス提供サーバ１０は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図８に示すように、セッション情報ＤＢ１１と、店舗情報ＤＢ１２と、履歴情報ＤＢ１３と、証明書検証部１４と、Ｗｅｂセッション情報発行部１５と、サービス提供部１６とを備える。【００４８】
セッション情報ＤＢ１１は、ｃａｌｌセッション情報とサービス利用ＩＤとＷｅｂセッション情報とを対応づけて記憶する。具体的には、セッション情報ＤＢ１１は、証明書検証部１４と、Ｗｅｂセッション情報発行部１５と、サービス提供部１６と接続され、証明書検証部１４、Ｗｅｂセッション情報発行部１５、あるいはサービス提供部１６による処理に利用される。例えば、セッション情報ＤＢ１１は、図９に示すような情報を記憶する。【００４９】
店舗情報ＤＢ１２は、サービス提供サーバ１０が提供するサービスのコンテンツである店舗情報を記憶する。具体的には、店舗情報ＤＢ１２は、サービス提供部１６と接続され、サービス提供部１６による処理に利用される。例えば、店舗情報ＤＢ１２は、図１０に示すような情報を記憶する。【００５０】
履歴情報ＤＢ１３は、サービス利用の履歴情報をサービス利用ＩＤごとに記憶する。具体的には、履歴情報ＤＢ１３は、サービス提供部１６と接続され、サービス提供部１６による処理に利用される。例えば、履歴情報ＤＢ１３は、図１１に示すような情報を記憶する。【００５１】
証明書検証部１４は、証明書を検証する。具体的には、証明書検証部１４は、セッション情報ＤＢ１１とＷｅｂセッション情報発行部１５と接続され、セッション管理サーバ２０にて発行された証明書を端末３０から送信されると、当該証明書を検証し、検証結果をＷｅｂセッション情報発行部１５に通知する。【００５２】
例えば、証明書検証部１４は、証明書に含まれるセッション管理サーバ２０の公開鍵（認証局によって真正な公開鍵であることは証明されている）を利用して署名を復号し、callセッション情報およびサービス利用ＩＤのハッシュ値を取り出す。また、証明書検証部１４は、callセッション情報およびサービス利用ＩＤ自体からハッシュ値を算出する。そして、証明書検証部１４は、署名から取り出したハッシュ値と算出したハッシュ値とを照合することで、callセッション情報およびサービス利用ＩＤが真正な情報であることを検証する。すなわち、署名から取り出したハッシュ値と算出したハッシュ値とを照合した結果、両者が一致すれば、(a)当該callセッション情報およびサービス利用ＩＤが、確かにセッション管理サーバ２０から発行された情報であること、(b)当該callセッション情報およびサービス利用ＩＤが、改竄されていないこと、(c)セッション管理サーバ２０が当該callセッション情報およびサービス利用ＩＤを送信した事実を否認しないことなどの事実を検証することができ、当該callセッション情報およびサービス利用ＩＤが真正な情報であることを検証することができる。【００５３】
Ｗｅｂセッション情報発行部１５は、Ｗｅｂセッション情報を発行する。具体的には、Ｗｅｂセッション情報発行部１５は、セッション情報ＤＢ１１と証明書検証部１４と接続され、証明書の検証結果を証明書検証部１４から通知されると、Ｗｅｂセッション情報を発行し、ｃａｌｌセッション情報とサービス利用ＩＤとＷｅｂセッション情報とを対応づけてセッション情報ＤＢ１１に格納する。【００５４】
サービス提供部１６は、サービスを提供する。具体的には、サービス提供部１６は、セッション情報ＤＢ１１と店舗情報ＤＢ１２と履歴情報ＤＢ１３と接続され、端末３０からＷｅｂセッション情報とともにアクセスされると、Ｗｅｂセッションを用いてセッション情報ＤＢ１１を参照し、ｃａｌｌセッション情報およびサービス利用ＩＤを取得する。また、サービス提供部１６は、サービス利用ＩＤを用いて履歴情報ＤＢ１３を参照し、履歴情報を取得する。そして、サービス提供部１６は、端末３０に対して履歴情報に従う内容でサービス各々が提供されるようにサービス提供を制御する。また、サービス提供部１６は、端末３０によるサービス利用の履歴情報をサービス利用ＩＤと対応づけて履歴情報ＤＢ１３に格納する。【００５５】
また、サービス提供部１６は、セッション情報ＤＢ１１に格納されている複数のｃａｌｌセッション情報の内、所定のｃａｌｌセッション情報各々が同一の通信として確立されたものであることを示す場合に、Ｗｅｂセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する。【００５６】
例えば、サービス提供部１６は、図９に示すように、セッション情報ＤＢ１１によって記憶されている複数のｃａｌｌセッション情報の内、２つのｃａｌｌセッション情報『e8b03879d0f5629aa8b5ea6a06736cle』各々が、ＳＩＰによって同一の通信として確立されたものであることを判別する。そして、サービス提供部１６は、ｃａｌｌセッション情報『e8b03879d0f5629aa8b5ea6a06736cle』に対応づけて記憶されているＷｅｂセッション情報『１２３』が付与されたＨＴＴＰ通信と、Ｗｅｂセッション情報『４５６』が付与されたＨＴＴＰ通信とを用いて提供されるサービスを、互いに関連づけて制御する。【００５７】
すなわち、例えば、他方の端末３０が、Ｗｅｂセッション情報『１２３』が付与されたＨＴＴＰ通信によってサービス提供サーバ１０にアクセスしている際に、一方の端末３０が、Ｗｅｂセッション情報『４５６』が付与されたＨＴＴＰ通信によってサービス提供サーバ１０に画像データをアップロードしたとする。このような場合、端末３０間の関係は、ＳＩＰによって同一の通信を確立した関係であるとみなされるので、この関係は、画像データの共有を互いに認めている関係であるとして、実施例１におけるサービス提供部１６は、他方の端末３０に画像データを送信するよう、サービスを制御する。【００５８】
ここで、改めて、サービス提供サーバ１０によるサービス提供について考える。すなわち、サービス提供サーバ１０によるサービス提供が、端末３０間の関係に基づいて制御される点は、従来のサービス提供サーバと同様であるが、実施例１におけるサービス提供サーバ１０が、「端末３０間の関係」をどのように把握しているかを説明する。【００５９】
つまり、実施例１におけるサービス提供サーバ１０は、従来のサービス提供サーバのように、予め記憶部に登録されたバディ関係を「端末３０間の関係」として把握するのではなく、サービス提供部１６が、ｃａｌｌセッション情報各々がＳＩＰによって同一の通信を確立したものであることを示す場合に、「端末３０間の関係」を把握するのである。言い換えると、サービス提供サーバ１０は、ＳＩＰによって同一の通信を確立した端末３０間の関係のように、通信相手となる端末との関係が一時的な場合にも、かかる一時的な通信関係に基づいて、端末３０各々において行われるＨＴＴＰ通信を互いに関連づけることで、一時的な通信関係に関連づけたサービス提供を可能としている。【００６０】
なお、実施例１のように、第１の通信がＳＩＰによって通信を確立する過程の通信である場合には、「端末３０間の関係」がＳＩＰによる認証済みの関係であるという点でも意味がある。すなわち、ＳＩＰ通信においては、Digest（ダイジェスト）認証などが行われるのが一般的であり、端末３０間でＳＩＰによって通信が確立されたということは、端末３０各々の関係が認証済みであることを示す。【００６１】
［実施例１に係るサービス提供システムによる処理手順］
次に、図１２〜図１４を用いて、実施例１に係るサービス提供システムによる処理手順を説明する。図１２は、実施例１に係るサービス提供システムによる処理手順を示すシーケンス図であり、図１３は、証明書発行部による処理手順を示すフローチャートであり、図１４は、サービス提供部による処理手順を示すフローチャートである。【００６２】
図１２に示すように、まず、セッション管理サーバ２０のＳＩＰ通信制御部２３が制御することで、端末３０間で、ステップＳ１０１〜Ｓ１０３のＳＩＰ通信が行われ、その結果、ステップＳ１０４において、端末３０間でＳＩＰによって通信が確立される。【００６３】
端末３０間でＳＩＰによって通信が確立されると、端末３０のｃａｌｌセッション情報収集部３２は、ＳＩＰ通信に含まれる情報からｃａｌｌセッション情報を収集し（ステップＳ１１０）、ｃａｌｌセッション情報送信部３３が、ｃａｌｌセッション情報をセッション管理サーバ２０に送信する（ステップＳ１１１）。【００６４】
すると、セッション管理サーバ２０のcallセッション情報検証部２４がｃａｌｌセッション情報を検証し（ステップＳ１１２）、証明書発行部２５が、サービスのメニュー画面を端末３０に対して送信する（ステップＳ１１３）。【００６５】
メニュー画面に表示されている複数のサービスの内の所定サービスが、端末３０の利用者によって押下されることなどによって選択されると、端末３０のサービス利用部３４は、サービス選択情報をセッション管理サーバ２０に対して送信する（ステップＳ１１４）。【００６６】
すると、セッション管理サーバ２０の証明書発行部２５は、端末３０を一意に識別するＳＩＰ−ＵＲＩと、サービス選択情報によって示されるサービスを一意に識別するサービス提供サーバＵＲＩとの組合せに対応づけてサービス利用ＩＤを発行する。また、証明書発行部２５は、ｃａｌｌセッション情報とサービス利用ＩＤとを記載した証明書を発行する（ステップＳ１１５）。【００６７】
次に、証明書発行部２５は、サービス提供サーバ１０のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示とともに、発行した証明書を端末３０に対して送信する（ステップＳ１１６）。【００６８】
一方、端末３０のサービス利用部３４は、セッション管理サーバ２０から送信されたリダイレクト指示によってリダイレクトされ、サービス提供サーバ１０にアクセスする（ステップＳ１１７）。この時、サービス利用部３４は、セッション管理サーバ２０にて発行された証明書とともにサービス提供サーバ１０にアクセスする。【００６９】
すると、サービス提供サーバ１０の証明書検証部１４が証明書を検証し、Ｗｅｂセッション情報発行部１５が、Ｗｅｂセッション情報を発行し（ステップＳ１１８）、発行したＷｅｂセッション情報を端末３０に対して送信する（ステップＳ１１９）。【００７０】
続いて、証明書検証部１４は、ｃａｌｌセッション情報とサービス利用ＩＤとＷｅｂセッション情報とを対応づけてセッション情報ＤＢ１１に格納し、ｃａｌｌセッション情報とサービス利用ＩＤとＷｅｂセッション情報とを関連づける（ステップＳ１２０）。【００７１】
その後、端末３０のサービス利用部３４が、Ｗｅｂセッション情報とともにサービス提供サーバ１０にアクセスすると、サービス提供サーバ１０のサービス提供部１６は、サービス利用ＩＤと対応づけて履歴情報ＤＢ１３に記憶されている履歴情報を用いてサービスを提供する。また、サービス提供部１６は、端末３０によるサービス利用の履歴情報をサービス利用ＩＤと対応づけて履歴情報ＤＢ１３に格納する（ステップＳ１２１）。【００７２】
なお、実施例１においては、ステップＳ１１３において、セッション管理サーバ２０がメニュー画面を端末３０に対して送信し、ステップＳ１１４において、端末３０がサービス選択情報をセッション管理サーバ２０に対して送信する手法を説明したが、本発明はこれに限られるものではない。例えば、セッション管理サーバ２０が、端末３０の組合せごとに利用させるサービス提供サーバ１０を予め設定している場合には、ステップＳ１１３およびステップＳ１１４を省略し、ステップＳ１１５に移行してもよい。【００７３】
［証明書発行部による処理手順］
次に、図１３を用いて、図１２に示すステップＳ１１５を詳述する。【００７４】
まず、セッション管理サーバ２０の証明書発行部２５は、サービス選択情報を端末３０から受け付けたか否かを判定し（ステップＳ１１）、受け付けていない場合には（ステップＳ１１否定）、受け付けたか否かを判定する処理を繰り返し行う。【００７５】
一方、受け付けた場合には（ステップＳ１１肯定）、証明書発行部２５は、端末３０を一意に識別するＳＩＰ−ＵＲＩと、サービス選択情報によって示されるサービスを一意に識別するサービス提供サーバＵＲＩとを用いて、サービス利用情報ＤＢ２２を参照する（ステップＳ１２）。【００７６】
そして、証明書発行部２５は、サービス利用ＩＤを検索できなかった場合には（ステップＳ１３否定）、サービス利用ＩＤを新規発行し（ステップＳ１４）、ｃａｌｌセッション情報と、新規発行したサービス利用ＩＤとを記載した証明書を発行し（ステップＳ１５）、処理を終了する。【００７７】
一方、証明書発行部２５は、サービス利用ＩＤを検索できた場合には（ステップＳ１３肯定）、ｃａｌｌセッション情報と、検索したサービス利用ＩＤとを記載した証明書を発行し（ステップＳ１６）、処理を終了する。【００７８】
［サービス提供部による処理手順］
続いて、図１４を用いて、図１２に示すステップＳ１２１を詳述する。【００７９】
まず、サービス提供サーバ１０のサービス提供部１６は、サービス利用要求を受け付けたか否か（端末３０からＷｅｂセッション情報とともにアクセスされたか否か）を判定し（ステップＳ２１）、受け付けていない場合には（ステップＳ２１否定）、受け付けたか否かを判定する処理を繰り返し行う。【００８０】
一方、受け付けた場合には（ステップＳ２１肯定）、サービス提供部１６は、Ｗｅｂセッション情報を用いてセッション情報ＤＢ１１を参照し、ｃａｌｌセッション情報およびサービス利用ＩＤを取得する（ステップＳ２２）。【００８１】
そして、サービス提供部１６は、サービス利用ＩＤを用いて履歴情報ＤＢ１３を参照し（ステップＳ２３）、サービス利用ＩＤの履歴情報がある場合には（ステップＳ２４肯定）、端末３０に対して履歴情報を用いてサービスを提供する（ステップＳ２５）。例えば、サービス提供部１６は、履歴情報を参照し、端末３０各々の利用者各々の趣味に近いであろう和食の情報を提示する。【００８２】
一方、履歴情報がない場合には（ステップＳ２４否定）、サービス提供部１６は、履歴情報を用いることなく、サービスを提供する（ステップＳ２６）。なお、履歴情報を用いてサービスを提供する場合も履歴情報を用いることなくサービスを提供する場合も、サービス提供部１６は、端末各々に提供するサービス各々を互いに関連づけて制御する。すなわち、サービス提供部１６は、セッション情報ＤＢ１１によって記憶されている複数のｃａｌｌセッション情報の内、２つのｃａｌｌセッション情報各々が、ＳＩＰによって同一の通信として確立されたものである場合に、ｃａｌｌセッション情報に対応づけて記憶されているＷｅｂセッション情報各々が付与されたＨＴＴＰ通信を用いて提供されるサービス各々を互いに関連づけて制御する。【００８３】
そして、サービス提供部１６は、端末３０によるサービス利用の履歴情報をサービス利用ＩＤと対応づけて履歴情報ＤＢ１３に格納し（ステップＳ２７）、処理を終了する。【００８４】
［実施例１の効果］
上記してきたように、実施例１に係るサービス提供システムにおいて、サービス提供サーバ１０は、端末３０間で確立された通信を識別するｃａｌｌセッション情報を端末３０毎に収集する。また、サービス提供サーバ１０は、端末３０を識別するサービス利用ＩＤをｃａｌｌセッション情報と組の情報として端末３０毎に収集する。また、サービス提供サーバ１０は、複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報各々を特定し、特定したｃａｌｌセッション情報各々によって識別される通信を確立した端末３０各々に提供するサービス各々を関連づける。また、サービス提供サーバ１０は、関連づけられたサービス各々を端末３０各々に提供する際に、複数のサービス利用ＩＤの中から当該端末３０各々を識別するサービス利用ＩＤ各々を特定し、特定したサービス利用ＩＤ各々に対応づけて記憶部に記憶されている履歴情報に従う内容でサービス各々が提供されるようにサービス提供を制御する。【００８５】
このようなことから、実施例１に係るサービス提供システムによれば、アドホックな通信関係にも対応するなど、高度なＷｅｂサービスを柔軟に提供することが可能になる。【００８６】
すなわち、端末３０各々は、サービス提供サーバ１０に予め会員登録しているわけではなく、また、予めバディ関係を登録しているわけでもない。端末３０各々の関係は、ＳＩＰによって通信を確立したというアドホックな通信関係にすぎない。この点、実施例１に係るサービス提供システムは、アドホックな通信関係を識別するｃａｌｌセッション情報を用いることで、サービス提供サーバ１０にアドホックな通信関係をその都度把握させ、Ｗｅｂサービスの連携など高度なＷｅｂサービスを柔軟に提供させている。【００８７】
また、実施例１に係るサービス提供システムによれば、利用者に関する各種情報とも連携した付加価値の高いＷｅｂサービスを提供することが可能になる。【００８８】
すなわち、サービス提供サーバ１０は、端末３０各々を予め会員登録しているわけではなく、端末３０各々の関係をｃａｌｌセッション情報を用いて把握しているにすぎない。この点、実施例１に係るサービス提供システムは、端末３０を識別するサービス利用ＩＤを発行し、サービス利用ＩＤを用いることで、サービス提供サーバ１０に端末３０を把握させている。この結果、サービス提供サーバ１０は、Ｗｅｂサービスを利用したことのある端末３０について履歴情報を蓄積することができ、再び端末３０にＷｅｂサービスを提供する際には、履歴情報とも連携した付加価値の高いＷｅｂサービスを提供することができるのである。【００８９】
また、実施例１によれば、セッション管理サーバ２０は、サービス利用ＩＤとして、電話番号そのものではなく、仮名化したＩＤを用いている。このため、サービス提供サーバ１０において利用者が特定されることを防止することができる。【００９０】
また、実施例１によれば、サービス利用ＩＤは、端末３０とサービスとの組合せごとに発行されていた。この場合には、名寄せ（複数のＷｅｂサーバ間で共謀することによる利用者特定行為）を防止することが可能である。
【実施例２】
【００９１】
さて、これまで実施例１として、サービス提供サーバ１０が、サービス利用ＩＤと履歴情報とを対応づけて記憶し、履歴情報を用いてＷｅｂサービスを提供する事例を説明してきた。しかしながら、本発明はこれに限られるものではない。サービス提供サーバ１０が、サービス提供サーバ１０に予め会員登録しているユーザに関するユーザ情報とサービス利用ＩＤとを対応づけて記憶し、ユーザ情報を用いてＷｅｂサービスを提供する事例にも、本発明を同様に適用することができる。以下、実施例２として説明する。【００９２】
［実施例２に係るサービス提供システムの概要］
まず、図１５を用いて、実施例２に係るサービス提供システムの概要を説明する。図１５は、実施例２に係るサービス提供システムの概要を説明するための図である。【００９３】
図１５に示すように、実施例２に係るサービス提供システムは、サービス提供サーバ１０が、サービス提供サーバ１０に予め会員登録しているユーザに関するユーザ情報とサービス利用ＩＤとを対応づけて記憶するユーザ情報ＤＢを備える。サービス提供サーバ１０は、実施例１と同様、端末３０各々に提供するＷｅｂサービスを連携させるが、この時、ユーザ情報に従う内容でサービス各々が提供されるようにサービス提供を制御する。【００９４】
具体的に説明すると、実施例１と同様、まず、端末３０間でＳＩＰによって通信が確立され、端末３０間で音声通話が開始される（図１５の（１）を参照）。【００９５】
次に、実施例１と同様、セッション管理サーバ２０は、端末３０各々に対して、ｃａｌｌセッション情報とサービス利用ＩＤとを記載した証明書を発行する（図１５の（２）を参照）。【００９６】
そして、端末３０各々は、セッション管理サーバ２０から発行された証明書をサービス利用要求とともにサービス提供サーバ１０に送信する（図１５の（３）を参照）。なお、図１５においては明示していないが、Ｗｅｂサービスの利用が初回である場合には、端末３０各々は、ログイン操作を行う。例えば、端末３０各々は、ユーザＩＤとパスワードとをサービス提供サーバ１０に送信する。すると、サービス提供サーバ１０は、端末３０各々を認証し、認証に成功した場合に、ユーザ情報ＤＢのユーザＩＤに対応づけてサービス利用ＩＤを格納する。【００９７】
このため、サービス提供サーバ１０は、初回以降、端末３０から証明書を受け付けると、証明書に記載されているサービス利用ＩＤを用いてユーザ情報ＤＢを参照し、ユーザ情報を検索する（図１５の（４）を参照）。【００９８】
そして、サービス提供サーバ１０は、実施例１と同様、端末３０各々から送信されたｃａｌｌセッション情報各々が同一の通信を示すｃａｌｌセッション情報であることを特定し、端末３０各々に提供するＷｅｂサービスを連携させるとともに、実施例１と異なり、検索したユーザ情報に従う内容でサービス各々が提供されるようにサービス提供を制御する（図１５の（５）を参照）。【００９９】
このようなことから、実施例２に係るサービス提供システムによれば、予め会員登録したユーザ情報とも連携することで、さらに付加価値の高いＷｅｂサービスを提供することが可能になる。【０１００】
例えば、図１５に示すように、サービス提供サーバ１０は、ユーザＩＤ『myuser@web1.sp1.com』の住所が『東京都武蔵野市・・・』であり、ユーザＩＤ『ouruser@web1.sp1.com』の住所が『東京都千代田区・・・』であるとのユーザ情報を用いて、その中間地点である『新宿区』の店舗を紹介することが可能になる。【０１０１】
［実施例２に係るサービス提供システムの構成］
次に、図１６および図１７を用いて、実施例２に係るサービス提供システムの構成を説明する。図１６は、サービス提供サーバの構成を示すブロック図であり、図１７は、ユーザ情報ＤＢを説明するための図である。なお、以下では、実施例２に係るサービス提供システムが、実施例１と特に異なる構成のみを説明する。【０１０２】
図１６に示すように、実施例２におけるサービス提供サーバ１０は、ユーザ情報ＤＢ１７をさらに備える。なお、実施例２におけるサービス提供サーバ１０は、履歴情報ＤＢ１３を備えていないが、実施例１と同様、履歴情報ＤＢ１３を備えていてもよい。この場合には、サービス提供部１６は、ユーザ情報を用いてＷｅｂサービスを提供するのみならず、ユーザ情報と履歴情報とを用いてＷｅｂサービスを提供することも可能になる。【０１０３】
ユーザ情報ＤＢ１７は、サービス提供サーバ１０に予め会員登録しているユーザに関するユーザ情報と、サービス利用ＩＤとを対応づけて記憶する。具体的には、ユーザ情報ＤＢ１７は、サービス提供部１６と接続され、サービス提供部１６による処理に利用される。例えば、ユーザ情報ＤＢ１７は、図１７に示すような情報を記憶する。【０１０４】
実施例２におけるサービス提供部１６は、実施例１と同様、サービスを提供するが、実施例１と異なり、ユーザ情報とも連携してサービスを提供する。具体的には、サービス提供部１６は、セッション情報ＤＢ１１と店舗情報ＤＢ１２とユーザ情報ＤＢ１７と接続され、端末３０からＷｅｂセッション情報とともにアクセスされると、Ｗｅｂセッション情報を用いてセッション情報ＤＢ１１を参照し、ｃａｌｌセッション情報およびサービス利用ＩＤを取得する。また、サービス提供部１６は、サービス利用ＩＤを用いてユーザ情報ＤＢ１７を参照し、サービスＩＤに対応づけて記憶されているユーザ情報を取得する。そして、サービス提供部１６は、端末３０に対してユーザ情報に従う内容でサービス各々が提供されるようにサービス提供を制御する。【０１０５】
［実施例２に係るサービス提供システムによる処理手順］
次に、図１８〜図２０を用いて、実施例２に係るサービス提供システムによる処理手順を説明する。図１８は、実施例２に係るサービス提供システムによる処理手順を示すシーケンス図であり、図１９は、サービス提供部による処理手順を示すフローチャートであり、図２０は、サービス提供画面を説明するための図である。【０１０６】
図１８に示す処理手順の内、ステップＳ２０１〜Ｓ２２０は、実施例１に係るサービス提供システムによる処理手順のステップＳ１０１〜Ｓ１２０に対応する。実施例２に係るサービス提供システムにおいては、ステップＳ２２１の処理のみが、実施例１と異なる。【０１０７】
すなわち、ステップＳ２２１において、端末３０のサービス利用部３４は、実施例１と同様、Ｗｅｂセッション情報とともにサービス提供サーバ１０にアクセスする。もっとも、実施例２におけるサービス利用部３４は、当該サービスの利用が初回である場合には、ユーザＩＤとパスワードとを送信するログイン操作を行う。なお、ログイン操作は、ユーザＩＤとパスワードとを送信する手法に限られず、例えば、公開鍵証明書を送信する手法などでもよい。【０１０８】
初回ログイン時、サービス提供サーバ１０のサービス提供部１６は、端末３０から送信されたユーザＩＤとパスワードとを用いてユーザ情報ＤＢ１７を参照し、端末３０の利用者を認証する。そして、サービス提供部１６は、認証に成功した場合に、ユーザ情報ＤＢ１７の当該ユーザ情報に対応づけてサービス利用ＩＤを格納することで、ユーザＩＤとサービス利用ＩＤとの関連づけを行う。【０１０９】
初回以降は、端末３０のサービス利用部３４は、ログイン操作を行う必要はない。すなわち、サービス提供サーバ１０のサービス提供部１６は、サービス利用ＩＤを用いてユーザ情報ＤＢ１７を参照すれば、当該サービス利用ＩＤに対応づけて記憶されているユーザＩＤを特定することができる。このため、サービス提供部１６は、当該ユーザＩＤのユーザ情報を用いてサービス提供を行う。【０１１０】
［サービス提供部による処理手順］
続いて、図１９を用いて、図１８に示すステップＳ２２１を詳述する。【０１１１】
まず、サービス提供サーバ１０のサービス提供部１６は、サービス利用要求を受け付けたか否かを判定し（ステップＳ３１）、受け付けていない場合には（ステップＳ３１否定）、受け付けたか否かを判定する処理を繰り返し行う。【０１１２】
一方、受け付けた場合には（ステップＳ３１肯定）、サービス提供部１６は、Ｗｅｂセッション情報を用いてセッション情報ＤＢ１１を参照し、ｃａｌｌセッション情報およびサービス利用ＩＤを取得する（ステップＳ３２）。【０１１３】
そして、サービス提供部１６は、サービス利用ＩＤを用いてユーザ情報ＤＢ１７を参照し（ステップＳ３３）、サービス利用ＩＤを検索できない場合には（ステップＳ３４否定）、端末３０からユーザＩＤとパスワードとを受け付けたか否かを判定する（ステップＳ３５）。【０１１４】
受け付けている場合には（ステップＳ３５肯定）、サービス提供部１６は、ユーザＩＤおよびパスワードを用いてユーザ情報ＤＢ１７を参照し、認証する（ステップＳ３６）。【０１１５】
そして、サービス提供部１６は、認証を成功したか否かを判定し（ステップＳ３７）、成功した場合には（ステップＳ３７肯定）、ユーザＩＤに対応づけて、ステップＳ３２で取得したサービス利用ＩＤを格納することで、ユーザＩＤとサービス利用ＩＤとの関連づけを行う（ステップＳ３８）。【０１１６】
続いて、サービス提供部１６は、当該ユーザＩＤのユーザ情報を用いてサービス提供を行い（ステップＳ３９）、処理を終了する。【０１１７】
ところで、ステップＳ３４において、サービス利用ＩＤを検索できた場合には（ステップＳ３４肯定）、初回以降であるので、サービス提供部１６は、サービス利用ＩＤに対応づけて記憶されているユーザＩＤを特定し、当該ユーザＩＤのユーザ情報を用いてサービス提供を行い（ステップＳ３９）、処理を終了する。【０１１８】
また、ステップＳ３５において、端末３０からユーザＩＤとパスワードとを受け付けていない場合（ステップＳ３５否定）、もしくは、ステップＳ３７において、認証に失敗した場合には（ステップＳ３７否定）、サービス提供部１６は、ユーザ情報を用いることなくサービスを提供して（ステップＳ４０）、処理を終了する。【０１１９】
ここで、ユーザ情報を用いてサービスを提供する事例を説明する。サービス提供サーバ１０のサービス提供部１６は、ある端末３０から送信されたサービス利用ＩＤ『USER1-web1-SP-id』を用いてユーザ情報ＤＢ１７を検索することで、当該端末３０の利用者が、サービス提供サーバ１０に予め会員登録しているユーザＩＤ『myuser@web1.sp1.com』であることを特定する。【０１２０】
同様に、サービス提供部１６は、ある端末３０から送信されたサービス利用ＩＤ『USER3-web1-SP-id』を用いてユーザ情報ＤＢ１７を検索することで、当該端末３０の利用者が、サービス提供サーバ１０に予め会員登録しているユーザＩＤ『ouruser@web1.sp1.com』であることを特定する。【０１２１】
また、サービス提供部１６は、端末３０から送信されたＷｅｂセッション情報を用いてセッション情報ＤＢ１１を参照し、ｃａｌｌセッション情報、サービス利用ＩＤを取得することで、ユーザＩＤ『myuser@web1.sp1.com』に提供するサービスとユーザＩＤ『ouruser@web1.sp1.com』に提供するサービスとを互いに関連づけることを把握する。【０１２２】
ここで、図２０に示すように、サービス提供部１６が提供するサービスが、店舗検索サービスであるとする。サービス提供部１６は、ユーザＩＤ『myuser@web1.sp1.com』の住所が『東京都武蔵野市・・・』であり、ユーザＩＤ『ouruser@web1.sp1.com』の住所が『東京都千代田区・・・』であるとのユーザ情報を用いて、その中間地点である『新宿区』の店舗を紹介する。【０１２３】
また、サービス提供部１６は、サービスを提供する画面に、ユーザＩＤ『myuser@web1.sp1.com』の氏名『特許太郎』や、ユーザＩＤ『ouruser@web1.sp1.com』の氏名『特許花子』を表示する。【０１２４】
［実施例２の効果］
上記してきたように、実施例２に係るサービス提供システムによれば、予め会員登録したユーザ情報とも連携することで、さらに付加価値の高いＷｅｂサービスを提供することが可能になる。【０１２５】
例えば、サービス提供サーバ１０は、ユーザＩＤ『myuser@web1.sp1.com』の住所が『東京都武蔵野市・・・』であり、ユーザＩＤ『ouruser@web1.sp1.com』の住所が『東京都千代田区・・・』であるとのユーザ情報を用いて、その中間地点である『新宿区』の店舗を紹介することが可能になる。【０１２６】
また、実施例２によれば、利用者は、初回のログイン操作のみでＳＳＯ（Single  Sign  On）が可能になり、既存のＷｅｂサービスのユーザとしてサービスを利用することが可能になる。
【実施例３】
【０１２７】
さて、これまで実施例２として、サービス提供サーバ１０が、ユーザ情報とサービス利用ＩＤとを対応づけて記憶し、ユーザ情報を用いてＷｅｂサービスを提供する事例を説明してきた。しかしながら、本発明はこれに限られるものではない。ユーザ情報とサービス利用ＩＤとの対応づけをセッション管理サーバ２０が行う事例にも、本発明を同様に適用することができる。以下、実施例３として説明する。【０１２８】
［実施例３に係るサービス提供システムの概要］
まず、図２１を用いて、実施例３に係るサービス提供システムの概要を説明する。図２１は、実施例３に係るサービス提供システムの概要を説明するための図である。【０１２９】
図２１に示すように、実施例３に係るサービス提供システムは、セッション管理サーバ２０が、サービス提供サーバ１０に予め会員登録しているユーザに関するユーザ情報とサービス利用ＩＤとを対応づけて記憶するサービス利用情報ＤＢを備える。サービス提供サーバ１０は、実施例２と同様、ユーザ情報を用いてサービスを提供するが、それは、セッション管理サーバ２０によって発行された証明書にユーザＩＤが記載されているからである。【０１３０】
具体的に説明すると、実施例２と同様、まず、端末３０間でＳＩＰによって通信が確立され、端末３０間で音声通話が開始される（図２１の（１）を参照）。【０１３１】
次に、実施例２と同様、セッション管理サーバ２０は、端末３０各々に対して証明書を発行するが、実施例２と異なり、サービス利用ＩＤを用いてサービス利用情報ＤＢを参照し、ユーザＩＤを検索し（図２１の（２）を参照）、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行する（図２１の（３）を参照）。【０１３２】
すなわち、図２１においては明示していないが、Ｗｅｂサービスの利用が初回である場合には、セッション管理サーバ２０は、ｃａｌｌセッション情報のみを記載した証明書を発行し、端末３０各々は、ログイン操作を行う。すると、サービス提供サーバ１０は、端末３０各々を認証し、認証に成功した場合に、ユーザＩＤをセッション管理サーバ２０に送信する。この時、セッション管理サーバ２０は、サービス利用ＩＤとユーザＩＤとを対応づけてサービス利用情報ＤＢに格納するので、初回以降、セッション管理サーバ２０は、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行することができる。【０１３３】
そして、端末３０各々は、セッション管理サーバ２０から発行された証明書をサービス利用要求とともにサービス提供サーバ１０に送信する（図２１の（４）を参照）。【０１３４】
一方、サービス提供サーバ１０は、初回以降、端末３０から証明書を受け付けると、証明書に記載されているユーザＩＤを用いてユーザ情報ＤＢを参照し、ユーザ情報を検索する（図２１の（５）を参照）。【０１３５】
そして、サービス提供サーバ１０は、実施例２と同様、端末３０各々から送信されたｃａｌｌセッション情報各々が同一の通信を示すｃａｌｌセッション情報であることを特定し、端末３０各々に提供するＷｅｂサービスを連携させるとともに、検索したユーザ情報に従う内容でサービス各々が提供されるようにサービス提供を制御する（図２１の（６）を参照）。【０１３６】
このようなことから、実施例３に係るサービス提供システムによれば、サービス提供サーバ１０は、サービス利用ＩＤを管理する必要がなくなるので、サービス提供サーバ１０に変更を加えることなく、付加価値の高いＷｅｂサービスを提供することが可能になる。【０１３７】
［実施例３に係るサービス提供システムの構成］
次に、図２２〜図２６を用いて、実施例３に係るサービス提供システムの構成を説明する。図２２は、セッション管理サーバの構成を示すブロック図であり、図２３は、サービス利用情報ＤＢを説明するための図であり、図２４は、証明書を説明するための図であり、図２５は、セッション情報ＤＢを説明するための図であり、図２６は、ユーザ情報ＤＢを説明するための図である。なお、以下では、実施例３に係るサービス提供システムが、実施例１や実施例２と特に異なる構成のみを説明する。【０１３８】
図２２に示すように、実施例３におけるセッション管理サーバ２０は、ユーザＩＤ関連づけ部２６をさらに備える。【０１３９】
ユーザＩＤ関連づけ部２６は、サービス利用ＩＤとユーザＩＤとを関連づける。具体的には、ユーザＩＤ関連づけ部２６は、端末３０にてリダイレクトされることでサービス提供サーバ１０からユーザＩＤを送信されると、当該ユーザＩＤをリダイレクトした端末３０のサービス利用ＩＤと、送信されたユーザＩＤとを対応づけて、サービス利用情報ＤＢ２２に格納する。例えば、ユーザＩＤ関連づけ部２６は、図２３に示すように、サービス利用ＩＤに対応づけてユーザＩＤを格納する。【０１４０】
実施例３における証明書発行部２５は、実施例１や実施例２と同様、サービス利用ＩＤを発行し、証明書を発行するが、実施例１や実施例２と異なり、ｃａｌｌセッション情報のみを記載した証明書を発行する場合と、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行する場合とがある。具体的には、証明書発行部２５は、サービス利用情報ＤＢ２２を参照し、サービス利用ＩＤに対応づけて記憶されているユーザＩＤを検索する。ユーザＩＤを検索できた場合には、証明書発行部２５は、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行する。一方、ユーザＩＤを検索できなかった場合には、証明書発行部２５は、ｃａｌｌセッション情報のみを記載した証明書を発行する。【０１４１】
例えば、証明書発行部２５は、図２４に示すように、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行する。なお、図２４では、証明書発行部２５は、さらにサービス利用ＩＤを証明書に記載している。証明書にサービス利用ＩＤが記載されていたとしても、証明書を受信したサービス提供サーバ１０側でサービス利用ＩＤを利用しないようにすればよい。すなわち、複数のサービス提供サーバ１０が存在する場合には、サービス利用ＩＤを用いてユーザを管理するサービス提供サーバ１０と、サービス利用ＩＤを用いないサービス提供サーバ１０とが混在することもあり得る。このような状況に対応するには、証明書にサービス利用ＩＤを記載しておき、適宜、サービス提供サーバ１０側で、サービス利用ＩＤを利用するなり、あるいは利用しないようにすればよい。【０１４２】
実施例３におけるサービス提供サーバ１０のセッション情報ＤＢ１１は、実施例１や実施例２と異なり、ｃａｌｌセッション情報とユーザＩＤとＷｅｂセッション情報とを対応づけて記憶する。例えば、セッション情報ＤＢ１１は、図２５に示すような情報を記憶する。【０１４３】
実施例３におけるユーザ情報ＤＢ１７は、実施例２と異なり、サービス利用ＩＤをユーザ情報に対応づけて記憶していない。例えば、ユーザ情報ＤＢ１７は、図２６に示すような情報を記憶する。【０１４４】
実施例３におけるサービス提供部１６は、実施例２と同様、ユーザ情報とも連携してサービスを提供するが、実施例２と異なり、サービス利用ＩＤを用いない。すなわち、実施例３において、証明書検証部１４は、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を端末３０から受け付け、Ｗｅｂセッション情報発行部１５は、ｃａｌｌセッション情報とユーザＩＤとＷｅｂセッション情報とを対応づけてセッション情報ＤＢ１１に格納している。【０１４５】
このため、実施例３におけるサービス提供部１６は、サービスを提供する際に、Ｗｅｂセッション情報を用いてセッション情報ＤＢ１１を参照し、ｃａｌｌセッション情報およびユーザＩＤを取得する。また、サービス提供部１６は、ユーザＩＤを用いてユーザ情報ＤＢ１７を参照し、ユーザＩＤに対応づけて記憶されているユーザ情報を取得する。そして、サービス提供部１６は、端末３０に対してユーザ情報に従う内容でサービス各々が提供されるようにサービス提供を制御する。【０１４６】
［実施例３に係るサービス提供システムによる処理手順］
次に、図２７〜図２９を用いて、実施例３に係るサービス提供システムによる処理手順を説明する。図２７および図２８は、実施例３に係るサービス提供システムによる処理手順を示すシーケンス図であり、図２９は、証明書発行部による処理手順を示すフローチャートである。なお、図２７は、初回ログイン時の処理手順を示し、図２８は、初回以降の処理手順を示す。【０１４７】
図２７に示す処理手順の内、ステップＳ３０１〜Ｓ３２０は、実施例１に係るサービス提供システムによる処理手順のステップＳ１０１〜Ｓ１２０に対応する。もっとも、実施例３に係るサービス提供システムにおいては、ステップＳ３１５の処理が実施例１と異なる。また、ステップＳ３２１以降の処理が実施例１と異なる。【０１４８】
また、図２８に示す処理手順の内、ステップＳ４０１〜４２１は、実施例１に係るサービス提供システムによる処理手順のステップＳ１０１〜Ｓ１２１に対応する。もっとも、実施例３に係るサービス提供システムにおいては、ステップＳ４１５で発行する証明書が実施例１と異なり、このため、ステップＳ４１６以降、各装置で用いられる情報が実施例１と異なる。【０１４９】
まず、図２９を用いて、図２７に示すステップＳ３１５を詳述すると、セッション管理サーバ２０の証明書発行部２５は、サービス選択情報を端末３０から受け付けたか否かを判定し（ステップＳ５１）、受け付けていない場合には（ステップＳ５１否定）、受け付けたか否かを判定する処理を繰り返し行う。【０１５０】
一方、受け付けた場合には（ステップＳ５１肯定）、証明書発行部２５は、端末３０を一意に識別するＳＩＰ−ＵＲＩと、サービス選択情報によって示されるサービスを一意に識別するサービス提供サーバＵＲＩとを用いて、サービス利用情報ＤＢ２２を参照する（ステップＳ５２）。【０１５１】
そして、証明書発行部２５は、サービス利用ＩＤを検索できなかった場合には（ステップＳ５３否定）、サービス利用ＩＤを新規発行し（ステップＳ５４）、ｃａｌｌセッション情報のみを記載した証明書を発行して（ステップＳ５６）、処理を終了する。【０１５２】
一方、サービス利用ＩＤを検索できた場合には（ステップＳ５３肯定）、証明書発行部２５は、続いて、ユーザＩＤを検索し（ステップＳ５５）、ユーザＩＤを検索できなかった場合には（ステップＳ５５否定）、ｃａｌｌセッション情報のみを記載した証明書を発行して（ステップＳ５６）、処理を終了する。【０１５３】
また、ユーザＩＤを検索できた場合には（ステップＳ５５肯定）、証明書発行部２５は、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行し（ステップＳ５７）、処理を終了する。【０１５４】
図２７に戻り、図２７は、初回ログイン時の処理手順を示すシーケンス図であるので、図２９に示すステップＳ５３においてサービス利用ＩＤを検索できないか、もしくは、ステップＳ５５においてユーザＩＤを検索できないはずである。このため、証明書発行部２５は、図２７に示すステップＳ３１５において、ｃａｌｌセッション情報のみを記載した証明書を発行する。【０１５５】
ステップＳ３２１において、実施例３におけるサービス利用部３４は、ユーザＩＤとパスワードとを送信するログイン操作を行う。【０１５６】
初回ログイン時、サービス提供サーバ１０のサービス提供部１６は、端末３０から送信されたユーザＩＤとパスワードとを用いてユーザ情報ＤＢ１７を参照し、端末３０の利用者を認証する。そして、サービス提供部１６は、認証に成功した場合に、実施例２と異なり、ユーザＩＤをセッション管理サーバ２０に対して送信する（ステップＳ３２２）。なお、この時、ユーザＩＤは、端末３０にてリダイレクトされてセッション管理サーバ２０に送信される。【０１５７】
すると、セッション管理サーバ２０のユーザＩＤ関連づけ部２６が、端末３０にてリダイレクトされることでサービス提供サーバ１０からユーザＩＤを送信されると、当該ユーザＩＤをリダイレクトした端末３０のサービス利用ＩＤと、送信されたユーザＩＤとを対応づけて、サービス利用情報ＤＢ２２に格納する（ステップＳ３２３）。この時、ユーザＩＤ関連づけ部２６は、何らかの手法によって、ステップＳ３１４のアクセスとステップＳ３２２のアクセスとが同一の通信であることを認識する。例えば、ユーザＩＤ関連づけ部２６は、セッション管理サーバ２０が端末３０のＨＴＴＰ通信に対して払い出したセッション情報を用いて、ステップＳ３１４のアクセスとステップＳ３２２のアクセスとが同一の通信であることを認識することができる。また、例えば、ステップＳ３１７の証明書にサービス利用ＩＤが記載されており、サービス提供サーバ１０が、ステップＳ３２２においてユーザＩＤを送信する際に、証明書に記載されていたサービス利用ＩＤを添付すれば、ユーザＩＤ関連づけ部２６は、ステップＳ３１４のアクセスとステップＳ３２２のアクセスとが同一の通信であることを認識することができる。【０１５８】
一方、サービス提供サーバのサービス提供部１６は、ユーザＩＤのユーザ情報を用いてサービス提供を行う（ステップＳ３２４）。【０１５９】
また、図２８は、初回以降の処理手順を示すシーケンス図であるので、図２９に示すステップＳ５３においてサービス利用ＩＤを検索でき、ステップＳ５５においてユーザＩＤを検索できるはずである。このため、証明書発行部２５は、図２８に示すステップＳ４１５において、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を発行する。【０１６０】
すると、サービス提供サーバ１０のサービス提供部１６は、ステップＳ４１７において、ｃａｌｌセッション情報とユーザＩＤとを記載した証明書を端末３０から受け付け、Ｗｅｂセッション情報発行部１５は、ステップＳ４２０において、ｃａｌｌセッション情報とユーザＩＤとＷｅｂセッション情報とを対応づけてセッション情報ＤＢ１１に格納している。【０１６１】
このため、サービス提供部１６は、ステップＳ４２１においてサービスを提供する際に、ユーザＩＤを用いてユーザ情報ＤＢ１７を参照し、ユーザＩＤに対応づけて記憶されているユーザ情報を取得し、端末３０に対してユーザ情報を用いてサービスを提供する。【０１６２】
［実施例３の効果］
上記してきたように、実施例３に係るサービス提供システムによれば、サービス提供サーバ１０は、サービス利用ＩＤを管理する必要がなくなるので、サービス提供サーバ１０のＤＢに変更を加えることなく、付加価値の高いＷｅｂサービスを提供することが可能になる。【０１６３】
また、実施例３によれば、利用者は、初回のログイン操作のみでＳＳＯが可能になり、既存のＷｅｂサービスのユーザとしてサービスを利用することが可能になる。
【実施例４】
【０１６４】
［他の実施例］
さて、これまで本発明の実施例１〜３について説明してきたが、本発明は上記した実施例以外にも、種々の異なる形態にて実施されてよいものである。【０１６５】
［サービス利用ＩＤ］
実施例１〜３においては、サービス利用ＩＤとして『USER1-web1-SP-id』などや乱数を用いる手法を説明してきた。しかしながら、本発明はこれに限られるものではない。例えば、サービス利用ＩＤとして、図３０に示すように、ＨＴＴＰ−ＵＲＩ形式の情報を用いてもよい。【０１６６】
サービス利用ＩＤとしてＨＴＴＰ−ＵＲＩ形式の情報を用いた場合には、サービス提供サーバ１０は、ＨＴＴＰ−ＵＲＩを用いて他のサーバにアクセスし、端末３０（もしくは端末３０の利用者）に関するその他のユーザ情報を収集し、収集したユーザ情報を用いてさらに付加価値の高いＷｅｂサービスを提供することも可能になる。【０１６７】
また、実施例１〜３においては、サービス利用ＩＤは、端末とサービスとの組合せごとに発行されていた。しかしながら、本発明はこれに限られるものではなく、サービス利用ＩＤは、サービス提供サーバ１０において端末を識別することが可能な情報であれば、必ずしも、端末とサービスとの組合せごとに発行される必要はない。【０１６８】
［ユーザ情報の交換］
また、実施例１〜３においては、サービス提供サーバ１０が、自サーバにて蓄積した履歴情報、あるいは、予め登録されたユーザ情報を用いてＷｅｂサービスを提供する手法を説明してきた。しかしながら、本発明はこれに限られるものではなく、セッション管理サーバ２０からサービス提供サーバ１０にユーザ情報を送信してもよい。【０１６９】
例えば、セッション管理サーバ２０が、端末３０のユーザ情報として、住所、氏名、年齢、地名、最寄り駅、ＧＰＳ（Global  Positioning  System）情報、郵便番号などを予め登録していた場合、セッション管理サーバ２０は、発行する証明書にこれらのユーザ情報を適宜記載してもよい。すると、サービス提供サーバ１０は、証明書に記載されたサービス利用ＩＤに対応づけてユーザ情報を取得することができ、取得したユーザ情報を用いてＷｅｂサービスを提供することが可能になる。【０１７０】
なお、セッション管理サーバ２０は、証明書にユーザ情報を記載してよいか否かを端末３０の利用者に確認してもよい。また、セッション管理サーバ２０が、端末３０のユーザ情報として、ＨＴＴＰ−ＵＲＩ形式の情報のみを予め登録していた場合、セッション管理サーバ２０は、利用者の許可が得られた場合に、ＨＴＴＰ−ＵＲＩを用いて他のサーバにアクセスし、ユーザ情報を収集してもよい。【０１７１】
また、反対に、サービス提供サーバ１０からセッション管理サーバ２０にユーザ情報を送信してもよい。すなわち、サービス提供サーバ１０が、事前に収集したユーザ情報をセッション管理サーバ２０に送信すると、例えば、端末３０が、他のサービス提供サーバ１０にセッション管理サーバ２０経由でアクセスする際に、セッション管理サーバ２０において受信されていたユーザ情報を用いることができ、他のサービス提供サーバ１０のユーザ情報を用いてＷｅｂサービスを提供することが可能になる。【０１７２】
［通信プロトコルの選択］
また、実施例１〜３においては、第一の通信がＳＩＰによって確立される通信であり、第二の通信がＨＴＴＰ通信であることを想定してきたが、本発明はこれに限られるものではない。第一の通信によって確立されるセッションと第二の通信のセッションとが互いに異なるセッションであれば、具体的な通信プロトコルはいずれでもよい。【０１７３】
［ｃａｌｌセッション情報］
また、実施例１〜３においては、サービス提供サーバ１０が取得するｃａｌｌセッション情報は同一の値であるものとして説明してきたが、同一の値でなくてもよい。ＳＩＰによって端末３０間で確立された同一の通信を一意に識別するものとしてサービス提供装置が認識可能なものであれば、二つの値の組合せなどでもよい。【０１７４】
［問い合わせ］
また、実施例１〜３においては、セッション管理サーバ２０は、ｃａｌｌセッション情報やサービス利用ＩＤなどを証明書で発行したことから、サービス提供サーバ１０は、証明書を検証することで、ｃａｌｌセッション情報やサービス利用ＩＤが確かな情報であることを確認していた。しかしながら、本発明はこれに限られるものではない。例えば、セッション管理サーバ２０が、証明書で発行せずに、ｃａｌｌセッション情報やサービス利用ＩＤなどをそのままの情報として発行したとする。サービス提供サーバ１０は、端末３０からこれらの情報を受信すると、例えば、セッション管理サーバ２０に対する問い合わせを行って、ｃａｌｌセッション情報やサービス利用ＩＤなどが確かな情報であることを確認してもよい。【０１７５】
［システム構成等］
また、実施例１〜３においては、ＳＩＰ通信機能とＨＴＴＰ通信機能とを一体化して備えた端末３０に対して、サービス提供サーバ１０がサービスを提供する手法を説明してきた。しかしながら、本発明は、これに限られるものではない。ＳＩＰ通信機能とＨＴＴＰ通信機能とが各々異なる端末に備えられる場合（ＳＩＰ通信機能を備えたＳＩＰフォンと、ＨＴＴＰ通信機能を備えた情報表示端末とで構成される場合）や、複数台のＳＩＰフォンと複数台の情報表示端末とで構成される場合にも、本発明を同様に適用することができる。すなわち、いずれの場合にも、ＳＩＰフォンと情報表示端末との間の情報伝達を代行するとともに、サービス提供の対象となる情報表示端末を特定する装置が別途必要になると考えられるが、例えば、ＨＧＷ（Home  GateWay）などの装置が、かかる装置としての役割を果たしてもよい。【０１７６】
例えば、ＨＧＷ各々は、配下に接続する情報表示端末に対して予めブラウザセッション情報を付与し、このブラウザセッション情報とＳＩＰフォンを識別するＳＩＰフォンＩＤとを対応づけて記憶している。このような構成の下、ＨＧＷ各々は、ＳＩＰフォン間でＳＩＰによって通信が確立された後、ｃａｌｌセッション情報とＳＩＰフォンＩＤとを収集する。すると、ＨＧＷ各々は、ＳＩＰフォンＩＤからブラウザセッション情報を検索し、検索したブラウザセッション情報を用いてポーリングする情報表示端末を特定することで、通信を確立したＳＩＰフォンと組で利用される情報表示端末を特定する。こうして、ＨＧＷ各々は、特定した情報表示端末に対してｃａｌｌセッション情報を送信し、セッション管理サーバにリダイレクトすればよい。【０１７７】
また、ＳＩＰフォンがＷｅｂサーバ相当の機能を備えていれば、ＨＧＷも不要である。例えば、ＳＩＰフォン各々が、ＳＩＰによって確立した通信からｃａｌｌセッション情報を収集し、情報表示端末各々が、Ｗｅｂサーバ相当の機能を備えたＳＩＰフォンにポーリングするなどしてｃａｌｌセッション情報をＳＩＰフォンから取得し、取得したｃａｌｌセッション情報をセッション管理サーバに送信してもよい。【０１７８】
また、発信側の構成と着信側の構成が異なる構成であってもよい。【０１７９】
また、実施例１〜３においては、サービス提供サーバ１０が、端末３０各々に対して提供するＷｅｂサービス各々を連携させる事例を説明してきた。しかしながら、本発明はこれに限られるものではない。サービス提供サーバ１０が、当該サービス提供サーバ１０と端末３０との間のアドホックな通信関係に対応して、端末３０に対してＷｅｂサービスを提供する事例にも、本発明を同様に適用することができる。【０１８０】
具体的には、サービス提供サーバ１０は、サービス提供サーバ１０と端末３０との間で確立された通信を識別するｃａｌｌセッション情報を端末３０毎に収集する。また、サービス提供サーバ１０は、端末３０を識別するサービス利用ＩＤもしくは端末３０の利用者を識別するユーザＩＤをｃａｌｌセッション情報と組の情報として端末３０毎に収集する。また、サービス提供サーバ１０は、複数のｃａｌｌセッション情報の中からサービス提供サーバ１０との間で確立した通信を示すｃａｌｌセッション情報を特定し、特定したｃａｌｌセッション情報によって識別される通信を確立した端末３０にサービスを提供する際に、複数のサービス利用ＩＤ（もしくはユーザＩＤ）の中から端末３０各々もしくは当該端末３０各々の利用者各々を識別するサービス利用ＩＤ（もしくはユーザＩＤ）各々を特定する。そして、サービス提供サーバ１０は、特定したサービス利用ＩＤ（もしくはユーザＩＤ）各々に対応づけて記憶部に記憶されている履歴情報やユーザ情報を用いてサービスを提供する。【０１８１】
例えば、セッション管理サーバ２０は、端末３０に対してのみ証明書を発行し、端末３０は、証明書をサービス提供サーバ１０に送信する。サービス提供サーバ１０は、自サーバにてｃａｌｌセッション情報を収集しているので、端末３０から送信された証明書に記載されたｃａｌｌセッション情報と、自サーバにて収集したｃａｌｌセッション情報とを検証する。そして、サービス提供サーバ１０は、検証結果が成功の場合に、Ｗｅｂセッション情報を発行し、ｃａｌｌセッション情報とサービス利用ＩＤとＷｅｂセッション情報とを関連づける。その後、サービス提供サーバ１０は、実施例１〜３と同様、履歴情報やユーザ情報を用いてサービスを提供する。【０１８２】
例えば、図３１に示すように、発信者の依頼に基づいて着信者がお店や商品などを推薦するコンシェルジュサービスを実現することができる。サービス提供サーバ１０は、特許太郎さんの履歴情報（過去に利用した店舗情報など）を記憶している。発信者（myuser@web1.sp1.com）が電話をすると、着信者であるオペレータの画面には、図３１の右に示すような、発信者のサービス利用ＩＤに基づく過去に利用した店舗情報やお勧め情報などが表示される。オペレータは、この情報から利用者の好みを推測し、送信ボタンを押すことで、図３１の左に示すように、発信者に適合した情報を推薦することが可能になる。【０１８３】
また、上記の実施例においては、セッション管理サーバ２０とＳＩＰサーバとが同一の装置で実現される事例を説明してきたが、本発明はこれに限られるものではない。セッション管理サーバ２０は、ＳＩＰサーバと異なる装置であってもよい。この場合には、セッション管理サーバ２０とは異なる他のＳＩＰサーバによって端末３０間の通信が確立され、確立された通信を識別するｃａｌｌセッション情報をセッション管理サーバ２０が収集することになる。【０１８４】
また、セッション管理サーバ２０がＳＩＰサーバと異なる装置である場合には、セッション管理サーバ２０のcallセッション情報検証部２４による検証処理は、例えば、callセッション情報検証部２４がＳＩＰサーバとの間で通信を行い、必要な情報を送受信することで実現される。例えば、標準化されたＡＰＩ（Application  Programming  Interface）である『Ｐａｒｌａｙ  Ｘ』を利用して実現される。【０１８５】
図３２は、Ｐａｒｌａｙ  Ｘを利用してセッション管理サーバとＳＩＰサーバとの間の通信を実現する一例を説明するための図である。図３２に示すステップＳ１０１〜Ｓ１０４、及びステップＳ１１０〜Ｓ１１２は、図１２を用いて説明したステップＳ１０１〜Ｓ１０４、及びステップＳ１１０〜Ｓ１１２に対応する。また、図３２に示すステップＳ１３１〜Ｓ１３３は、図１２においては説明を割愛したが、両端末３０間で、ＳＩＰによって確立された通信が切断される処理手順である。なお、図１２を用いて説明したステップＳ１１３〜Ｓ１２１は、図３２においては図示を省略する。【０１８６】
ここで、図３２に示すステップＳ１〜Ｓ４は、callセッション情報検証部２４による検証処理の処理手順である。ステップＳ１に示すように、セッション管理サーバ２０は、ＳＩＰサーバ４０に対して着信者の登録を事前に行う。すなわち、ＳＩＰサーバ４０は、事前に登録を受け付けたユーザについてのみ、後述するステップＳ２の通知をセッション管理サーバ２０に対して行う。【０１８７】
例えば、セッション管理サーバ２０は、サービス提供システムの加入契約時、ユーザの登録を受け付けた際に、そのＵＲＩをＳＩＰサーバ４０に登録する。『Ｐａｒｌａｙ  Ｘ』を利用した例では、セッション管理サーバ２０は、着信者のＵＲＩを引数として「startCallNotification」をＳＩＰサーバ４０に対して送信する。「startCallNotification」は、指定した着信者のＵＲＩに係るcallセッション情報要求である。なお、ＵＲＩとしては、ＳＩＰ−ＵＲＩや電話番号などを用いることができる。また、ステップＳ１の登録は、Ｓ１０４によって通信が確立される時点よりも前に行われている必要があるが、ステップＳ１０１から始まる一連の処理手順と連続する処理として行われる必要はない。すなわち、例えば、１年前にステップＳ１の登録が行われていれば、１年後に初めて該当する通信が確立した場合にも、ＳＩＰサーバ４０によるステップＳ２の通知は実行される。【０１８８】
このように、ステップＳ１においてＳＩＰサーバ４０に登録されたユーザについては、ＳＩＰサーバ４０は、当該ユーザを着信者とする通信が確立した場合に、ステップＳ２に示すように、セッション管理サーバ２０に通知する。『Ｐａｒｌａｙ  Ｘ』を利用した例では、ＳＩＰサーバ４０は、発信者のＵＲＩ、着信者のＵＲＩ、及び確立した通信のcallセッション情報を引数として「notifyAnswer」をセッション管理サーバ２０に対して送信する。「notifyAnswer」は、通信確立時のcallセッション情報通知である。すると、callセッション情報検証部２４は、ステップＳ１１２においてcallセッション情報を検証する際に、ステップＳ２において受信したcallセッション情報であるか否かを検証するなどする。【０１８９】
また、ステップＳ３に示すように、その後、セッション管理サーバ２０は、ＳＩＰサーバ４０に対してポーリングなどで問い合わせを行うことで、ステップＳ１０４において確立した通信の状況を確認することができる。『Ｐａｒｌａｙ  Ｘ』を利用した例では、セッション管理サーバ２０は、callセッション情報を引数として「getCallSessionInformation」をＳＩＰサーバ４０に送信することで、その応答として通信の状況を受信する。「getCallSessionInformation」は、callセッション情報識別子に係るセッション状態（通話中、通話終了など）取得である。例えば、ステップＳ１３１〜Ｓ１３３に示すように通信が切断された場合には、ＳＩＰサーバ４０は、ステップＳ４に示す問い合わせの応答として、通信が切断された状況を送信する。【０１９０】
このように、セッション管理サーバ２０は、ＳＩＰによって確立された通信が切断されたとの状況をcallセッション情報とともに受信すると、例えば、当該callセッション情報に該当するサービス提供を終了するように制御することができる。例えば、セッション管理サーバ２０は、図１２のステップＳ１２１において提供中のサービスを終了するように制御することができる。また、例えば、セッション管理サーバ２０は、サービス提供を終了するように制御した端末３０のアクセス先を、所定のＵＲＬに変更するようリダイレクト指示を行うこともできる。【０１９１】
なお、図３２を用いて説明した処理手順は一例に過ぎず、『Ｐａｒｌａｙ  Ｘ』に替わるＡＰＩなどに任意に置き換えて実現することができる。例えば、上述した例では、ステップＳ１において着信者の登録を事前に行い、ステップＳ２において着信者のＵＲＩに係るcallセッション情報要求を送信した。しかしながら、これに限られるものではなく、例えば、『Ｐａｒｌａｙ  Ｘ』に替わるＡＰＩなどが、着信者のみならず発信者のＵＲＩに係るcallセッション情報要求にも対応する仕様である場合には、ステップＳ１における登録も、着信者のみならず発信者についても行えばよい。また、例えば、『Ｐａｒｌａｙ  Ｘ』に替わるＡＰＩなどが、通信が切断されたことを検知すると自動的にセッション管理サーバ２０に切断された状況を送信する仕様である場合には、セッション管理サーバ２０は、ステップＳ３のように問い合わせを繰り返す必要はない。【０１９２】
また、明細書や図面中で示した処理手順（図１２〜１４、図１８〜１９、図２７〜２９）、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。【０１９３】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。【０１９４】
なお、本実施例で説明したサービス提供方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【産業上の利用可能性】
【０１９５】
以上のように、本発明に係るサービス提供システムおよびサービス提供方法は、ネットワーク上のサービスを端末に提供することに有用であり、特に、アドホックな通信関係に対応するとともに、利用者に関する各種情報とも連携した付加価値の高いＷｅｂサービスを提供することに適する。
【符号の説明】
【０１９６】
１０  サービス提供サーバ
１１  セッション情報ＤＢ
１２  店舗情報ＤＢ
１３  履歴情報ＤＢ
１４  証明書検証部
１５  Ｗｅｂセッション情報発行部
１６  サービス提供部
１７  ユーザ情報ＤＢ
２０  セッション管理サーバ
２１  ｃａｌｌセッション情報ＤＢ
２２  サービス利用情報ＤＢ
２３  ＳＩＰ通信制御部
２４  ｃａｌｌセッション情報検証部
２５  証明書発行部
２６  ユーザＩＤ関連づけ部
３０  端末
３１  ＳＩＰ通信部
３２  ｃａｌｌセッション情報収集部
３３  ｃａｌｌセッション情報送信部
３４  サービス利用部
【図１】
2010044471.tif 000003
【図２】
2010044471.tif 000004
【図３】
2010044471.tif 000005
【図４】
2010044471.tif 000006
【図５】
2010044471.tif 000007
【図６】
2010044471.tif 000008
【図７】
2010044471.tif 000009
【図８】
2010044471.tif 000010
【図９】
2010044471.tif 000011
【図１０】
2010044471.tif 000012
【図１１】
2010044471.tif 000013
【図１２】
2010044471.tif 000014
【図１３】
2010044471.tif 000015
【図１４】
2010044471.tif 000016
【図１５】
2010044471.tif 000017
【図１６】
2010044471.tif 000018
【図１７】
2010044471.tif 000019
【図１８】
2010044471.tif 000020
【図１９】
2010044471.tif 000021
【図２０】
2010044471.tif 000022
【図２１】
2010044471.tif 000023
【図２２】
2010044471.tif 000024
【図２３】
2010044471.tif 000025
【図２４】
2010044471.tif 000026
【図２５】
2010044471.tif 000027
【図２６】
2010044471.tif 000028
【図２７】
2010044471.tif 000029
【図２８】
2010044471.tif 000030
【図２９】
2010044471.tif 000031
【図３０】
2010044471.tif 000032
【図３１】
2010044471.tif 000033
【図３２】
2010044471.tif 000034
【国際調査報告】
2010044471.tif 000035
2010044471.tif 000036
2010044471.tif 000037