(57)【要約】【課題】通信相手との関係が一時的な場合に、このような一時的な通信関係に基づいてサービスを制御し、かつ、データの受け渡しを容易に行うことを課題とする。【解決手段】セッション管理サーバは、ＳＩＰフォンにて通話中の利用者が利用する情報表示端末から、データの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末が、ＳＩＰによって通信を確立したＳＩＰフォンと組で利用される情報表示端末であるか否かを判定する。そして、セッション管理サーバは、ＳＩＰによって通信を確立したＳＩＰフォンと組で利用される端末であると判定すると、受け渡し要求に従って、受け渡しに用いられるデータをデータの保存元から取得し、取得したデータを用いてデータの受け渡しを制御する。【選択図】        図２
2010273101.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上のサービスを端末に提供するサービス提供システムであって、
セッション管理サーバは、
サービスの提供を要求する端末毎に、当該端末と組で利用され第１の通信を確立する第１通信端末と他の第１通信端末との間で確立された第１の通信を識別する通信情報を収集する通信情報収集手段と、
前記通信情報収集手段によって収集された複数の通信情報の中から同一の第１の通信を示す通信情報を特定し、特定した通信情報によって識別される第１の通信を確立した第１通信端末各々と組で利用される端末各々を連携するための連携情報を、当該端末各々に対して発行する連携情報発行手段と、
サービス提供サーバからサービスを連携するように提供される端末間において、一方の端末からデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の端末が、前記通信情報収集手段によって収集された通信情報によって識別される第１の通信を確立した第１通信端末と組で利用される端末であるか否かを判定する判定手段と、
前記判定手段によって前記第１の通信を確立した第１通信端末と組で利用される端末であると判定されると、前記受け渡し要求に従って、当該受け渡しに用いられるデータを当該データの保存元から取得する取得手段と、
前記取得手段によって取得されたデータを用いてデータの受け渡しを制御する受け渡し制御手段とを備え、
サービス提供サーバは、
サービスの提供を要求する端末毎に、前記連携情報発行手段によって発行された連携情報を収集する連携情報収集手段と、
前記連携情報収集手段によって収集された複数の連携情報の中からサービスを連携することを示す連携情報を特定し、特定した連携情報の収集元である端末各々に提供するサービスを連携するようにサービス提供を制御するサービス提供制御手段と
を備えたことを特徴とするサービス提供システム。
【請求項２】
前記受け渡し要求は、受け渡し先を指定する受け渡し先フラグおよび受け渡しの対象となるデータの保存元を指定するデータ保存元フラグを含むものであって、
前記受け渡し制御手段は、受け渡し要求に含められていた受け渡し先フラグおよびデータ保存元フラグに従って、当該データ保存元フラグにて指定されたデータを、当該受け渡し先フラグにて指定された受け渡し先へと受け渡すよう制御することを特徴とする請求項１に記載のサービス提供システム。
【請求項３】
前記連携情報発行手段は、前記連携情報を発行するとともに、前記端末もしくは前記端末の利用者を識別する識別情報を当該連携情報と組の情報として発行し、
前記データ受け渡し制御手段は、前記連携情報発行手段によって発行された識別情報を用いて、前記受け渡し要求にて指定された受け渡し先もしくはデータ保存元を特定して受け渡しを制御することを特徴とする請求項２に記載のサービス提供システム。
【請求項４】
前記データ受け渡し制御手段は、受け渡しの対象となるデータが、受け渡し先の鍵情報を用いて暗号化された上で受け渡されるように、データの受け渡しを制御することを特徴とする請求項１〜３のいずれか一つに記載のサービス提供システム。
【請求項５】
前記サービス提供システムは、前記第１の通信を確立する端末である第１通信端末と、前記サービスを利用する端末である第２通信端末とに接続され、当該第１通信端末による前記ネットワークに対する接続と、当該第２通信端末による前記ネットワークに対する接続とを制御するゲートウェイ装置を備えるものであって、
前記受け渡し制御手段は、前記サービス提供サーバから前記ゲートウェイ装置へのデータの受け渡しを制御することを特徴とする請求項１〜４のいずれか一つに記載のサービス提供システム。
【請求項６】
前記サービス提供システムは、前記第１の通信を確立する端末である第１通信端末と、前記サービスを利用する端末である第２通信端末とに接続され、当該第１通信端末による前記ネットワークに対する接続と、当該第２通信端末による前記ネットワークに対する接続とを制御するゲートウェイ装置を備えるものであって、
前記受け渡し制御手段は、前記ゲートウェイ装置から前記サービス提供サーバへのデータの受け渡しを制御することを特徴とする請求項１〜４のいずれか一つに記載のサービス提供システム。
【請求項７】
前記受け渡し制御手段は、前記サービス提供サーバから当該サービス提供サーバとは異なる他のサービス提供サーバへのデータの受け渡しを制御することを特徴とする請求項１〜４のいずれか一つに記載のサービス提供システム。
【請求項８】
前記サービス提供システムは、前記第１の通信を確立する端末である第１通信端末と、前記サービスを利用する端末である第２通信端末とに接続され、当該第１通信端末による前記ネットワークに対する接続と、当該第２通信端末による前記ネットワークに対する接続とを制御するゲートウェイ装置を備えるものであって、
前記ゲートウェイ装置は、前記第１の通信を発信する発信側の第１通信端末に接続される第１のゲートウェイ装置と、前記発信を着信する着信側の第１通信端末に接続される第２のゲートウェイ装置とであって、
前記受け渡し制御手段は、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間のデータの受け渡しを制御することを特徴とする請求項１〜４のいずれか一つに記載のサービス提供システム。
【請求項９】
前記受け渡し制御手段によって制御されたデータの受け渡しに関する履歴情報を管理する履歴情報管理手段をさらに備えたことを特徴とする請求項１〜８のいずれか一つに記載のサービス提供システム。
【請求項１０】
前記受け渡し制御手段は、受け渡しの対象となるデータの代わりに、当該データに対するアクセスが許可された受け渡し先であるか否かを判定する情報として当該データの保存元にて発行されたアクセス情報を、当該データの保存元から受け渡し先へと中継することで、データの受け渡しを制御することを特徴とする請求項１〜９のいずれか一つに記載のサービス提供システム。
【請求項１１】
前記受け渡し制御手段は、受け渡しの対象となるデータを前記セッション管理サーバから前記ゲートウェイ装置に中継する際に、当該ゲートウェイ装置に対して直接送信する代わりに、当該ゲートウェイ装置に接続する前記第２通信端末を経由したリダイレクトによって送信することを特徴とする請求項５、６または８のいずれか一つに記載のサービス提供システム。
【請求項１２】
ネットワーク上のサービスを端末に提供するサービス提供方法であって、
セッション管理サーバが、
サービスの提供を要求する端末毎に、当該端末と組で利用され第１の通信を確立する第１通信端末と他の第１通信端末との間で確立された第１の通信を識別する通信情報を収集する通信情報収集工程と、
前記通信情報収集工程によって収集された複数の通信情報の中から同一の第１の通信を示す通信情報を特定し、特定した通信情報によって識別される第１の通信を確立した第１通信端末各々と組で利用される端末各々を連携するための連携情報を、当該端末各々に対して発行する連携情報発行工程と、
サービス提供サーバからサービスを連携するように提供される端末間において、一方の端末からデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の端末が、前記通信情報収集工程によって収集された通信情報によって識別される第１の通信を確立した第１通信端末と組で利用される端末であるか否かを判定する判定工程と、
前記判定工程によって前記第１の通信を確立した第１通信端末と組で利用される端末であると判定されると、前記受け渡し要求に従って、当該受け渡しに用いられるデータを当該データの保存元から取得する取得工程と、
前記取得工程によって取得されたデータを用いてデータの受け渡しを制御する受け渡し制御工程とを含み、
サービス提供サーバが、
サービスの提供を要求する端末毎に、前記連携情報発行工程によって発行された連携情報を収集する連携情報収集工程と、
前記連携情報収集工程によって収集された複数の連携情報の中からサービスを連携することを示す連携情報を特定し、特定した連携情報の収集元である端末各々に提供するサービスを連携するようにサービス提供を制御するサービス提供制御工程と
を含んだことを特徴とするサービス提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス提供システムおよびサービス提供方法に関する。
【背景技術】
【０００２】
従来、ＩＰ（Internet  Protocol）で制御されるネットワークに接続する端末に提供されるサービスとして、いわゆるＷｅｂサービスがある。ここで、Ｗｅｂサービスとは、一般に、ＷＷＷ（World  Wide  Web）関連技術を適用することで、アプリケーションの機能をネットワーク経由で実現するサービスのことをいう。例えば、インターネットに接続する端末は、Ｗｅｂサービスの一つであるＩＭ（Instant  Messaging）サービスの提供を受け、インターネットに接続する他の端末との間で、チャットや画像データの共有を実現する。
【０００３】
また、例えば特許文献１には、会員（コミュニティ）管理を一元化することで、新しいサービスを利用する際の会員登録を不要とする技術が開示されている。また、例えば特許文献２には、一般的なブラウザを用いてアプリケーション共有を行う技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２２８１２２号公報
【特許文献２】特開２００３−０４４４２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記した従来の技術では、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することができず、また、データの受け渡しを容易に行うことができないという課題があった。
【０００６】
そこで、本発明は、上記した従来の技術の課題を解決するためになされたものであり、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御し、かつ、データの受け渡しを容易に行うことが可能なサービス提供システムおよびサービス提供方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願の開示するサービス提供システムおよびサービス提供方法は、一つの態様において、ネットワーク上のサービスを端末に提供するサービス提供システムであって、セッション管理サーバは、サービスの提供を要求する端末毎に、当該端末と組で利用され第１の通信を確立する第１通信端末と他の第１通信端末との間で確立された第１の通信を識別する通信情報を収集する通信情報収集手段と、前記通信情報収集手段によって収集された複数の通信情報の中から同一の第１の通信を示す通信情報を特定し、特定した通信情報によって識別される第１の通信を確立した第１通信端末各々と組で利用される端末各々を連携するための連携情報を、当該端末各々に対して発行する連携情報発行手段と、サービス提供サーバからサービスを連携するように提供される端末間において、一方の端末からデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の端末が、前記通信情報収集手段によって収集された通信情報によって識別される第１の通信を確立した第１通信端末と組で利用される端末であるか否かを判定する判定手段と、前記判定手段によって前記第１の通信を確立した第１通信端末と組で利用される端末であると判定されると、前記受け渡し要求に従って、当該受け渡しに用いられるデータを当該データの保存元から取得する取得手段と、前記取得手段によって取得されたデータを用いてデータの受け渡しを制御する受け渡し制御手段とを備えたことを特徴とする。また、サービス提供サーバは、サービスの提供を要求する端末毎に、前記連携情報発行手段によって発行された連携情報を収集する連携情報収集手段と、前記連携情報収集手段によって収集された複数の連携情報の中からサービスを連携することを示す連携情報を特定し、特定した連携情報の収集元である端末各々に提供するサービスを連携するようにサービス提供を制御するサービス提供制御手段とを備えたことを特徴とする。
【発明の効果】
【０００８】
本願の開示するサービス提供システムおよびサービス提供方法の一つの態様によれば、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御し、かつ、データの受け渡しを容易に行うことが可能になるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１に係るサービス提供システムの概要を説明するための図である。
【図２】図２は、実施例１に係るサービス提供システムの概要を説明するための図である。
【図３】図３は、セッション管理サーバの構成を示すブロック図である。
【図４】図４は、サービス提供サーバの構成を示すブロック図である。
【図５】図５は、ＨＧＷの構成を示すブロック図である。
【図６】図６は、ＳＩＰフォンの構成を示すブロック図である。
【図７】図７は、情報表示端末の構成を示すブロック図である。
【図８−１】図８−１は、セッション管理サーバが記憶する各種テーブルを説明するための図である。
【図８−２】図８−２は、セッション管理サーバが記憶する各種テーブルを説明するための図である。
【図９−１】図９−１は、サービス提供サーバが記憶するテーブルを説明するための図である。
【図９−２】図９−２は、ＨＧＷが記憶するテーブルを説明するための図である。
【図１０】図１０は、サービス提供に関する処理の手順を示すシーケンス図である。
【図１１】図１１は、サービス提供に関する処理の手順を示すシーケンス図である。
【図１２】図１２は、受け渡しフラグおよびデータ保存元フラグを説明するための図である。
【図１３−１】図１３−１は、各種方式を説明するための図である。
【図１３−２】図１３−２は、各種方式を説明するための図である。
【図１３−３】図１３−３は、各種方式を説明するための図である。
【図１３−４】図１３−４は、各種方式を説明するための図である。
【図１４】図１４は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図１５】図１５は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図１６】図１６は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図１７】図１７は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図１８】図１８は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図１９】図１９は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２０】図２０は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２１】図２１は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２２】図２２は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２３】図２３は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２４】図２４は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２５】図２５は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２６】図２６は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２７−１】図２７−１は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【図２７−２】図２７−２は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【発明を実施するための形態】
【００１０】
以下に添付図面を参照して、本発明に係るサービス提供システムおよびサービス提供方法の実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語の説明、実施例１に係るサービス提供システムの概要、実施例１に係るサービス提供システムの構成、実施例１に係るサービス提供システムによる処理の手順、実施例１の効果を順に説明し、続いて、他の実施例について説明する。
【００１１】
［用語の説明］
最初に、以下の実施例で用いる主要な用語を説明する。「サービス」とは、いわゆるＷｅｂサービス（ＷＷＷ関連技術を適用することで、アプリケーションの機能をネットワーク経由で実現するサービス）のことである。インターネットなどＩＰによって制御されるネットワークにおいて、「サービス提供サーバ」がサービスを制御し、ネットワークに接続する「端末」が「サービス」の提供を受けるという関係にある。
【００１２】
ところで、「サービス提供サーバ」は、端末各々の関係や端末とサービス提供サーバとの関係、もしくは端末を利用する利用者同士の関係などに基づいて、サービスを制御する。具体的に例を挙げて説明すると、例えば、ＩＭサービスにおいて、端末Ａを利用する利用者と端末Ｂを利用する利用者とがファイル共有を実現する場合を想定する。端末Ｂが、「サービス提供サーバ」にアクセスしている際に、端末Ａが、「サービス提供サーバ」にファイルをアップロードしたとする。このような場合、「サービス提供サーバ」は、端末Ａの利用者と端末Ｂの利用者との関係に基づいて、端末Ｂにファイルを送信する。すなわち、「サービス提供サーバ」は、例えば、端末Ａの利用者から利用者ＩＤやパスワードの入力を受け付け、端末Ｂの利用者から利用者ＩＤやパスワードの入力を受け付けることで、端末Ａの利用者と端末Ｂの利用者とを特定する。そして、「サービス提供サーバ」は、特定した端末Ａの利用者と端末Ｂの利用者との関係が、ファイル共有を互いに認めている関係であれば、当該関係に基づいて、端末Ｂにファイルを送信するよう、サービスを制御するのである。
【００１３】
また、例えば、ＳＮＳ（Social  Networking  Service）において、サイトの運営者である端末Ａの利用者が端末Ｂの利用者にサイトを閲覧させる場合を想定する。このような場合、「サービス提供サーバ」は、端末Ａの利用者と端末Ｂの利用者との関係に基づいて、端末Ｂの利用者によるサイトの閲覧を制御する。すなわち、「サービス提供サーバ」は、特定した端末Ａの利用者と特定した端末Ｂの利用者との関係が、端末Ａの利用者によって端末Ｂの利用者によるサイトの閲覧が認められている関係であれば、当該関係に基づいて、端末Ｂの利用者によるサイトの閲覧を許可するよう、サービスを制御するのである。
【００１４】
また、例えば、音楽情報を提供する「サービス提供サーバ」が、端末Ａの利用者に音楽情報のダウンロードを許可する場合を想定する。このような場合、「サービス提供サーバ」は、端末Ａの利用者と「サービス提供サーバ」との関係に基づいて、端末Ａによるダウンロード通信を制御する。すなわち、「サービス提供サーバ」は、特定した端末Ａの利用者と「サービス提供サーバ」との関係が、「サービス提供サーバ」によって端末Ａの利用者によるダウンロード通信が認められている関係であれば、当該関係に基づいて、端末Ａによるダウンロード通信を許可するよう、サービス提供を制御するのである。
【００１５】
このように、端末各々の関係や端末とサービス提供サーバとの関係、もしくは端末を利用する利用者同士の関係などは、そのサービス内容によって様々な態様があるが、いずれの場合も、「サービス提供サーバ」が、これらの関係に基づいてサービスを制御することに変わりはない。
【００１６】
もっとも、従来のＷｅｂサービスは、このような関係が、予め登録されたものであることを前提として提供されてきた。例えば、従来の「サービス提供サーバ」は、利用者同士の関係などを予めバディリストに登録し、登録したバディリストに基づいて、チャットや画像データの共有などのサービスを制御していたのである。これに対し、本発明に係るサービス提供システムおよびサービス提供方法は、予め登録されたバディリストのような関係のみならず、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）にも、かかる一時的な通信関係に基づいて、チャットや画像データの共有などのサービスを制御するものである。
【実施例１】
【００１７】
［実施例１に係るサービス提供システムの概要］
実施例１に係るサービス提供システムは、ネットワーク上のサービスを端末に提供することを概要とし、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御し、かつ、データの受け渡しを容易に行うものである。
【００１８】
かかる概要について、図１および図２を用いて説明する。図１および図２は、実施例１に係るサービス提供システムの概要を説明するための図である。図１および図２に例示するサービス提供システムは、端末側の構成が、ＳＩＰ（Session  Initiation  Protocol）フォンと、当該ＳＩＰフォンと組で利用される情報表示端末とに分かれている構成において、ＳＩＰによって通信を確立した通信相手のように、通信相手との関係が一時的な場合にも、サービス提供サーバが、このような一時的な通信関係に基づいたサービスを情報表示端末に提供するものである。ここで、ＳＩＰフォンとは、ＳＩＰによって通信を確立する端末（なお、確立したセッションを用いた通信も行う）のことであり、情報表示端末とは、ＨＴＴＰ（HyperText  Transfer  Protocol）通信を行う端末のことである。また、「組で利用される」とは、例えば、一人の利用者が、ＳＩＰフォンおよび情報表示端末の双方を利用しているような状況をいう。
【００１９】
また、サービス提供システムにおいて、端末側のネットワークには、ＨＧＷ（Home  Gate  Way）が設置される。図１および図２では、ＨＧＷとＳＩＰフォンと情報表示端末との接続関係を明示していないが、ＨＧＷの配下にＳＩＰフォンと情報表示端末とが接続される関係であり、また、ＨＧＷは、ＳＩＰフォンによるＳＩＰ通信と、情報表示端末によるＨＴＴＰ通信とをともに制御する装置である。すなわち、ＳＩＰフォンによるＳＩＰ通信も、情報表示端末によるＨＴＴＰ通信も、いずれもＨＧＷを経由してネットワークに接続される構成である。なお、以下では、ＳＩＰによってセッションが確立される過程を適宜『ＳＩＰ通信』と表現する（すなわち、『ＳＩＰ通信』は、ＳＩＰによって確立されたセッションそのものの通信（例えば、エンドユーザ間の音声パスやＶＰＮ（Virtual  Private  Network）など）を意味するものではない）。
【００２０】
一方、サービス提供システムにおいて、網側には、ＳＩＰプロキシとセッション管理サーバとサービス提供サーバとが設置される。ＳＩＰプロキシは、ＳＩＰによってセッションが確立される過程や、ＳＩＰによって確立されたセッションそのものの通信を制御する装置である。また、セッション管理サーバは、後述するように、情報表示端末の接続先を制御し、また、データの受け渡しを制御する装置である。また、サービス提供サーバは、情報表示端末にサービスを提供する装置である。なお、実施例１においては、ＳＩＰプロキシとセッション管理サーバとサービス提供サーバとが物理的に異なる装置として設置される例を説明するが、本発明はこれに限られるものではない。物理的に異なる装置として設定されるか否かは、サービスを提供する事業者の運用形態などに応じて任意に変更し得るものである。
【００２１】
上記したように、実施例１に係るサービス提供システムは、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御し、かつ、データの受け渡しを容易に行うものである。そこで、以下では、まず、図１を用いて、実施例１に係るサービス提供システムが一時的な通信関係に基づいてサービスを制御する点について、その概要を説明する。次に、図２を用いて、実施例１に係るサービス提供システムがデータの受け渡しを容易に行う点について、その概要を説明する。
【００２２】
図１に示すように、実施例１に係るサービス提供システムにおいて、ＳＩＰフォンとＳＩＰフォンとの間でＳＩＰによって通信が確立される。
【００２３】
続いて、通信を確立したＳＩＰフォンと利用者において組で利用される情報表示端末が、サービスを開始することを要求するサービス開始要求を、ｃａｌｌセッション情報（確立した通信を識別する情報）とともにセッション管理サーバに送信する。
【００２４】
セッション管理サーバは、ｃａｌｌセッション情報を収集し、収集した複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報を特定する。すなわち、セッション管理サーバは、図１に示す２台の情報表示端末のみからｃａｌｌセッション情報を収集するわけではなく、実際には、図１に示されていない多数の情報表示端末からも同様にｃａｌｌセッション情報を収集することになる。このため、セッション管理サーバは、このような多数の情報表示端末から収集した多数のｃａｌｌセッション情報の中から、図１に示す２台の情報表示端末から収集したｃａｌｌセッション情報を特定する。そして、セッション管理サーバは、特定したｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォン各々と組で利用される情報表示端末各々を連携するための連携情報を、情報表示端末各々に対して発行する。
【００２５】
すると、情報表示端末が、サービスを利用することを要求するサービス利用要求を、連携情報とともにサービス提供サーバに送信する。
【００２６】
サービス提供サーバは、連携情報を収集し、収集した複数の連携情報の中からサービスを連携することを示す連携情報を特定する。すなわち、セッション管理サーバと同様、サービス提供サーバも、図１に示す２台の情報表示端末のみから連携情報を収集するわけではなく、実際には、図１に示されていない多数の情報表示端末からも同様に連携情報を収集することになる。このため、サービス提供サーバは、このような多数の情報表示端末から収集した多数の連携情報の中から、図１に示す２台の情報表示端末から収集した連携情報を特定する。そして、サービス提供サーバは、特定した連携情報の収集元である情報表示端末各々に提供するサービスを連携するように、サービス提供を制御する。
【００２７】
続いて、図２に示すように、実施例１に係るサービス提供システムにおいて、サービス提供サーバからサービスを連携するように提供される情報表示端末間において、一方の情報表示端末が、データの受け渡しを要求する受け渡し要求を、セッション管理サーバに送信する。なお、実施例１における受け渡し要求は、受け渡し先を指定する受け渡し先フラグおよび受け渡しの対象となるデータの保存元を指定するデータ保存元フラグを含むものである。
【００２８】
セッション管理サーバは、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末が、収集したｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォンと組で利用される情報表示端末であるか否かを判定する。すなわち、当該情報表示端末の利用者が、ＳＩＰによって通信を確立したＳＩＰフォンの利用者であるか否か、例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。なお、実施例１においては、現に通話中の利用者であることを判定する手法を説明するが、本発明はこれに限られるものではなく、例えば、少なくとも過去に通話したことのある利用者であることを判定する手法などでもよい。
【００２９】
そして、セッション管理サーバは、受け渡し要求の要求元の情報表示端末の利用者が現に通話中であると判定すると、受け渡し要求に従ってデータの受け渡しを制御する。すなわち、実施例１におけるセッション管理サーバは、受け渡し要求に含められていた受け渡し先フラグおよびデータ保存元フラグに従って、当該データ保存元フラグにて指定されたデータをデータの保存元から取得し、取得したデータを当該受け渡し先フラグにて指定された受け渡し先へと受け渡すよう制御する。
【００３０】
このように、実施例１に係るサービス提供システムにおいて、セッション管理サーバは、ＳＩＰによって確立した一時的な通信関係に基づくサービス提供を実現するための連携情報を発行するとともに、データの受け渡し要求を受け付けると、例えば、要求元の利用者が現に通話中であることを判定の上、データ受け渡しを制御する。このようなことから、ＳＩＰフォンと情報表示端末とを組で利用する利用者は、例えば、通話をしながら通話相手と連携してＷｅｂサービスを利用することが可能になり、かつ、通話の延長で容易にデータの受け渡しを行うことが可能になる。
【００３１】
［実施例１に係るサービス提供システムの構成］
次に、図３〜図９−２を用いて、実施例１に係るサービス提供システムの構成を説明する。図３は、セッション管理サーバの構成を示すブロック図であり、図４は、サービス提供サーバの構成を示すブロック図であり、図５は、ＨＧＷの構成を示すブロック図であり、図６は、ＳＩＰフォンの構成を示すブロック図であり、図７は、情報表示端末の構成を示すブロック図であり、図８−１及び図８−２は、セッション管理サーバが記憶する各種テーブルを説明するための図であり、図９−１は、サービス提供サーバが記憶するテーブルを説明するための図であり、図９−２は、ＨＧＷが記憶するテーブルを説明するための図である。
【００３２】
なお、以下では、サービス提供システムの構成については簡単に説明し、各部の処理については後述する処理手順にて詳細に説明することとする。
【００３３】
［セッション管理サーバ］
セッション管理サーバ１００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図３に示すように、通信部１１０と、記憶部１２０と、制御部１３０とを備える。
【００３４】
通信部１１０は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、情報表示端末２０との間で情報を送受信したり、ＨＧＷ１０やサービス提供サーバ２００との間で情報を送受信するなどする。
【００３５】
記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図２に示すように、ユーザ契約サービス管理テーブル１２１と契約サービス情報テーブル１２２と制御用セッション管理テーブル１２３と発着間紐付けＩＤテーブル１２４とデータ受け渡しテーブル１２５とデータテーブル１２６とを備える。
【００３６】
ユーザ契約サービス管理テーブル１２１は、情報表示端末２０（およびＳＩＰフォン３０）を利用する利用者（ユーザ）が契約しているサービスを管理するテーブルである。例えば、ユーザ契約サービス管理テーブル１２１は、図８−１に示すように、ユーザ特定情報と契約サービスＩＤとを対応付けて記憶する。ユーザ契約サービス管理テーブル１２１が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。
【００３７】
ここで、ユーザ特定情報とは、情報表示端末２０の利用者を特定するための情報であり、実施例１においては、ＳＩＰ−ＵＲＩ（Uniform  Resource  Identifier）を用いている。また、契約サービスＩＤ（以下、適宜、サービスＩＤとも称する）とは、サービスを識別するＩＤである。このように、ユーザ契約サービス管理テーブル１２１は、ユーザ特定情報と契約サービスＩＤとを対応付けて記憶することで、ユーザ特定情報で特定される利用者が、契約サービスＩＤで識別されるサービスの加入者であることを管理している。
【００３８】
契約サービス情報テーブル１２２は、契約サービス各々について、各種情報を管理するテーブルである。例えば、契約サービス情報テーブル１２２は、図８−１に示すように、契約サービスＩＤとアクセス先ＵＲＬ（Uniform  Resource  Locator）とを対応付けて記憶する。ここで、アクセス先ＵＲＬとは、契約サービスＩＤで識別されるサービスを提供するサービス提供サーバ２００のＵＲＬである。契約サービス情報テーブル１２２が記憶するこれらの情報は、実施例１に係るサービス提供システムにおいて、予め登録されるものであり、また、適宜登録されるものである。
【００３９】
制御用セッション管理テーブル１２３は、制御用セッション情報を管理するテーブルである。例えば、制御用セッション管理テーブル１２３は、図８−１に示すように、制御用セッション情報と、ｃａｌｌセッション情報と、発着判定フラグと、通話情報（開始時刻〜終了時刻）と、ＨＧＷのＵＲＬとを対応付けて記憶している。
【００４０】
ここで、制御用セッション情報とは、セッション管理サーバ１００が情報表示端末２０との間で通信を行うために、当該情報表示端末２０のＷｅｂブラウザに対して付与する情報のことであり、情報表示端末２０とセッション管理サーバ１００との間で確立されたＷｅｂ通信を一意に識別する情報である。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に制御用セッション情報を払い出し、制御用セッション管理テーブル１２３に格納する。なお、制御用セッション情報としては、情報表示端末２０がＷｅｂ通信を行う際に利用するブラウザに付与された情報である『セッションID』（CookieのIDなど）を用いる手法などが考えられる。また、制御用セッション情報は、一般的には確立されたセッションごとにユニークに生成される。
【００４１】
また、ｃａｌｌセッション情報とは、ＳＩＰフォン３０間でＳＩＰによって確立されたセッションを一意に識別する情報である。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に当該情報表示端末２０から取得し、制御用セッション管理テーブル１２３に格納する。なお、ｃａｌｌセッション情報としては、ＳＩＰ通信に含まれる情報である『Ｃａｌｌ−ＩＤ』もしくは『ｉｓｕｂ』、または、『Ｆｒｏｍ』、『Ｔｏ』、『ｔａｇ』、ＩＰアドレス、もしくは、これらの組合せを用いる手法や、ＳＩＰ通信に含まれるその他の情報（例えば、『Ｄａｔｅ』など）を組合せて用いる手法などが考えられ、ＳＩＰによって確立された通信を一意に識別することが可能な情報を用いる手法であれば、どのような手法でもよい。また、ｃａｌｌセッション情報は、一般的には確立されたセッションごとにユニークに生成される。
【００４２】
また、発着判定フラグとは、ＳＩＰフォン３０間でＳＩＰによって確立されたセッションについて、ＳＩＰフォン３０（制御用セッション情報を払い出した情報表示端末２０と組で利用されるＳＩＰフォン３０）が発側であるのか着側であるのかを判定するフラグである。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に当該情報表示端末２０から取得し、制御用セッション管理テーブル１２３に格納する。
【００４３】
通話情報とは、ｃａｌｌセッション情報によって一意に識別されるセッションの開始時刻と終了時刻とを示す情報である。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に、その時刻を開始時刻として制御用セッション管理テーブル１２３に格納する。なお、後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０から開始時刻を取得し、制御用セッション管理テーブル１２３に格納してもよい。また、同様に、セッション管理サーバ１００は、セッションが切断されたことを把握した際などに、その時刻を終了時刻として制御用セッション管理テーブル１２３に格納する。
【００４４】
ＨＧＷのＵＲＬとは、情報表示端末２０によるＨＴＴＰ通信を制御するＨＧＷ１０のＵＲＬである。後述するｃａｌｌセッション情報収集部１３１が、情報表示端末２０からサービス開始要求を受け付けた際に当該情報表示端末２０から取得し、制御用セッション管理テーブル１２３に格納する。
【００４５】
このように、制御用セッション管理テーブル１２３は、セッション管理サーバ１００が払い出した制御用セッション情報に対応付けて、ＳＩＰフォン３０（情報表示端末２０と組で利用されるＳＩＰフォン３０）によって確立されたセッションに関する情報（以下、ｃａｌｌセッション情報、発着判定フラグおよび通話情報を「セッションに関する情報」という）等を記憶することで、制御用セッション情報が、どのような情報表示端末２０に対して払い出されたものであるか等を管理するものである。なお、図８−１において、説明の便宜上、制御用セッション情報や『Ｃａｌｌ−ＩＤ』として規則的な数値が例示されているが、一般的には乱数などが格納されることになる。
【００４６】
発着間紐付けＩＤテーブル１２４は、発着間紐付けＩＤを管理するテーブルである。例えば、発着間紐付けＩＤテーブル１２４は、図８−１に示すように、制御用セッション情報と、契約サービスＩＤと、発着間紐付けＩＤと、仮名ＩＤと、ステータスとを対応付けて記憶している。後述する発着間紐付けＩＤ発行部１３２が、情報表示端末２０からサービス開始要求を受け付けた際に発着間紐付けＩＤおよび仮名ＩＤを払い出し、ｃａｌｌセッション情報収集部１３１によって払い出された制御用セッション情報や、契約サービスＩＤ、ステータスとともに発着間紐付けＩＤテーブル１２４に格納する。
【００４７】
ここで、発着間紐付けＩＤとは、ＳＩＰによって確立されたセッションを一意に識別するｃａｌｌセッション情報の仮名情報であり、サービス提供サーバ２００が、通話中の情報表示端末２０各々、すなわち、利用者各々がＳＩＰフォン３０各々によって通話中である情報表示端末２０各々を紐付けるために利用するＩＤである。後述するように、発着間紐付けＩＤは、確立されたセッションごと（すなわち、通話ごと）に新しく発行されるため、サービス提供サーバ２００は、セッション単位で（すなわち、通話単位で）情報表示端末２０各々を紐付けることができる。
【００４８】
また、仮名ＩＤとは、情報表示端末２０と当該情報表示端末２０が利用するサービスとの組合せを一意に識別する情報であり、サービス提供サーバ２００が、２台の情報表示端末２０のうちのどちらの情報表示端末２０であるかを特定するために利用するＩＤである。すなわち、サービス提供サーバ２００は、発着間紐付けＩＤを用いることで２台の情報表示端末２０を特定し、特定した２台の情報表示端末２０に提供するサービスを連携するように制御することまではできるが、発着間紐付けＩＤだけでは２台の情報表示端末２０を区別してサービスを提供することまではできない。この点、仮名ＩＤは、情報表示端末２０とサービスとの組合せごとに発行されるため、サービス提供サーバ２００は、この仮名ＩＤを用いて２台の情報表示端末２０それぞれを区別し、それぞれの情報表示端末２０に適応したサービスを提供するように制御することができる。
【００４９】
また、ステータスとは、仮名ＩＤによって識別される利用者が、契約サービスＩＤによって識別されるサービスを利用中であるか否かの状態を示すものである。
【００５０】
データ受け渡しテーブル１２５は、データの受け渡しを管理するテーブルである。例えば、データ受け渡しテーブル１２５は、図８−２に示すように、制御用セッション情報と、ｃａｌｌセッション情報と、発着判定フラグと、受け渡し先情報と、データ保存元情報と、アクセスキーと、データファイル名と、ステータス情報とを対応付けて記憶している。なお、図８−２においては、データ受け渡しテーブル１２５が３行に分かれて記載されているが、３行で一つのレコードを意味する。
【００５１】
また、データ受け渡しテーブル１２５は、受け渡し先情報およびデータ保存元情報として、受け渡し要求に含まれていた受け渡し先フラグやデータ保存元フラグ、サービスＩＤを、発着間紐付けＩＤや仮名ＩＤとともに記憶する。この受け渡し先情報やデータ保存元情報は、後述するデータ受け渡し制御部１３４による処理に用いられる。すなわち、データ受け渡し制御部１３４は、この受け渡し先情報やデータ保存元情報を参照することで、データの受け渡しを制御する。
【００５２】
また、データ受け渡しテーブル１２５は、ステータス情報として、受け渡し要求を受付けた状態となった日時情報、アクセスキーを送信済みの状態となった日時情報、データを送信済みの状態となった日時情報、およびデータ受け渡しが完了の状態となった日時情報を記憶する。これらの日時情報は、セッション管理サーバ１００において該当する状態となった都度、データ受け渡しテーブル１２５に格納される。
【００５３】
ここで、セッション管理サーバ１００は、受け渡し要求に関し、受け渡し先情報やデータ保存元情報をデータ受け渡しテーブル１２５に格納するとともに、受け渡し要求を受け付けたタイミング、後述するアクセスキー（もしくはキー情報）を送信したタイミング、受け渡しの対象となるデータを送信したタイミング、受け渡しが完了したことを示す結果通知を受信したタイミングなどに、データ受け渡しテーブル１２５のステータス情報に時刻情報を格納することで、データの受け渡しに関する履歴情報を管理する。なお、実施例１においては、当該受け渡しにて用いられたアクセスキー（もしくはキー情報）や、受け渡しの対象となったデータのデータファイル名などについても、データ受け渡しテーブル１２５に格納することとする。また、制御用セッション情報、ｃａｌｌセッション情報、及び発着判定フラグは、制御用セッション管理テーブル１２３にも格納されている情報であるが、実施例１においては、便宜上データ受け渡しテーブル１２５にも格納することとする。
【００５４】
データテーブル１２６は、データ受け渡しの対象となったデータを記憶するテーブルである。例えば、データテーブル１２６は、図８−２に示すように、データファイル名とデータとを対応付けて記憶する。後述するように、データの受け渡しには各種方式があり、必ずしもセッション管理サーバ１００が受け渡しの対象となったデータを取得するとは限らないが、セッション管理サーバ１００がデータを取得した場合には、セッション管理サーバ１００は、取得したデータを適宜データテーブル１２６に格納すればよい。なお、データテーブル１２６に格納されるデータファイル名は、データ受け渡しテーブル１２５に格納されるデータファイル名と同一である。
【００５５】
制御部１３０は、特に本発明に密接に関連するものとしては、図３に示すように、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２と、受け渡し要求判定部１３３と、データ受け渡し制御部１３４とを備える。
【００５６】
ｃａｌｌセッション情報収集部１３１は、サービス開始要求を送信してきた情報表示端末２０毎に、当該情報表示端末２０と組で利用されるＳＩＰフォン３０と他のＳＩＰフォン３０との間で確立された通信を識別するｃａｌｌセッション情報を収集する。
【００５７】
発着間紐付けＩＤ発行部１３２は、ｃａｌｌセッション情報収集部１３１によって収集された複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報を特定し、特定したｃａｌｌセッション情報によって識別されるＳＩＰフォン３０各々と組で利用される情報表示端末２０各々を連携するための発着間紐付けＩＤを、情報表示端末２０各々に対して発行する。また、発着間紐付けＩＤ発行部１３２は、仮名ＩＤを発行する。
【００５８】
受け渡し要求判定部１３３は、サービス提供サーバ２００からサービスを連携するように提供される情報表示端末２０間において、一方の情報表示端末２０からデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０が、ｃａｌｌセッション情報収集部１３１によって収集されたｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０であるか否かを判定する。すなわち、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【００５９】
データ受け渡し制御部１３４は、受け渡し要求判定部１３３によって、受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であると判定されると、受け渡し要求に従って、受け渡しに用いられるデータをデータの保存元から取得し、取得したデータを用いてデータの受け渡しを制御する。
【００６０】
［サービス提供サーバ］
サービス提供サーバ２００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図４に示すように、通信部２１０と、記憶部２２０と、制御部２３０とを備える。
【００６１】
通信部２１０は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、セッション管理サーバ１００との間や、情報表示端末２０との間、ＳＩＰプロキシとの間などで情報を送受信する。
【００６２】
記憶部２２０は、制御部２３０における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図４に示すように、Ｗｅｂセッション情報管理テーブル２２１とデータテーブル２２２とを備える。
【００６３】
Ｗｅｂセッション情報管理テーブル２２１は、発着間紐付けＩＤ（ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報の仮名としてセッション管理サーバ１００が発行した仮名情報であり、情報表示端末２０各々を連携するための情報）などを管理するテーブルである。例えば、Ｗｅｂセッション情報管理テーブル２２１は、図９−１に示すように、Ｗｅｂセッション情報と、発着間紐付けＩＤと、仮名ＩＤと、発着判定フラグと、アクセスキーとを対応付けて記憶している。
【００６４】
Ｗｅｂセッション情報管理テーブル２２１が記憶するこれらの情報の内、Ｗｅｂセッション情報（サービス提供サーバ２００が情報表示端末２０との間で通信を行うために、当該情報表示端末２０のＷｅｂブラウザに対して付与する情報）は、サービス提供サーバ２００が、情報表示端末２０からサービス利用要求を受け付けた際に払い出し、登録するものである。また、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグは、サービス提供サーバ２００が、情報表示端末２０からサービス利用要求を受け付けた際に登録するものである。
【００６５】
ここで、Ｗｅｂセッション情報は、サービス提供サーバ２００が、情報表示端末２０を特定するために用いられる。すなわち、サービス提供サーバ２００は、情報表示端末２０からアクセスを受付けた際に、当該情報表示端末２０のＷｅｂブラウザに付与されているＷｅｂセッション情報を取得し、情報表示端末２０を特定する。また、発着間紐付けＩＤは、サービス提供サーバ２００が、通話中の情報表示端末２０各々、すなわち、利用者各々がＳＩＰフォン３０各々によって通話中である情報表示端末２０各々を紐付けるために用いられる。また、仮名ＩＤは、サービス提供サーバ２００が、２台の情報表示端末２０のうちのどちらの情報表示端末２０であるかを特定するために用いられる。すなわち、サービス提供サーバ２００は、発着間紐付けＩＤを用いることで２台の情報表示端末２０を特定し、特定した２台の情報表示端末２０に提供するサービスを連携するように制御することまではできるが、発着間紐付けＩＤだけでは２台の情報表示端末２０を区別してサービスを提供することまではできない。この点、仮名ＩＤは、情報表示端末２０とサービスとの組合せごとに発行されるため、サービス提供サーバ２００は、この仮名ＩＤを用いて２台の情報表示端末２０それぞれを区別し、それぞれの情報表示端末２０に適応したサービスを提供するように制御することができる。また、発着判定フラグは、サービス提供サーバ２００が、情報表示端末２０と組で利用されるＳＩＰフォン３０が、発側であるのか着側であるのかを判定するために用いられる。また、アクセスキーは、処理手順の説明において詳述するように、サービス提供サーバ２００が、データ受け渡しに関連してアクセスを受け付けた際に、受け渡しの対象となるデータを特定したり、アクセス元を認証するために用いられる。
【００６６】
データテーブル２２２は、データ受け渡しの対象のデータを記憶するテーブルである。例えば、データテーブル２２２は、図９−１に示すように、仮名ＩＤとデータとを対応付けて記憶する。すなわち、データテーブル２２２は、利用者とデータとの対応関係を記憶するため、利用者を特定する仮名ＩＤとデータとを対応づけて記憶する。なお、サービス提供サーバ２００は、初めから仮名ＩＤとデータとの対応をデータテーブル２２２に保存していても良いし、データダウンロード画面生成の際（後述する図１４のステップＳ１０１等で情報表示端末２０に表示される画面）に、例えば、通話相手のデータやサービス提供サーバ２００に関する情報をダウンロード用のデータとしてＳＩＰフォン３０の利用者の仮名ＩＤと対応づけてデータテーブル２２２に保存し、通話相手のデータやサービス提供サーバ２００のデータをダウンロードできるようにしても良い。
【００６７】
図４に戻り、制御部２３０は、特に本発明に密接に関連するものとしては、図４に示すように、発着間紐付けＩＤ収集部２３１と、サービス提供制御部２３２と、データ受け渡し部２３３とを備える。
【００６８】
発着間紐付けＩＤ収集部２３１は、サービスの提供を要求する情報表示端末２０毎に、セッション管理サーバ１００によって発行された発着間紐付けＩＤを収集し、Ｗｅｂセッション情報管理テーブル２２１に格納する。すなわち、発着間紐付けＩＤ収集部２３１は、情報表示端末２０からサービス提供の要求を受け付けると、当該情報表示端末２０から発着間紐付けＩＤを収集する。発着間紐付けＩＤは、上記したように、確立されたセッションごと（すなわち、通話ごと）に新しく払い出されるものであるので、発着間紐付けＩＤ収集部２３１は、個々の情報表示端末２０から発着間紐付けＩＤを収集した結果、２つの情報表示端末２０からは同じ発着間紐付けＩＤを収集することにもなる。また、実施例１における発着間紐付けＩＤ収集部２３１は、情報表示端末２０毎に、仮名ＩＤおよび発着判定フラグを収集し、Ｗｅｂセッション情報管理テーブル２２１に格納する。
【００６９】
サービス提供制御部２３２は、発着間紐付けＩＤ収集部２３１によって収集された複数の発着間紐付けＩＤの中からサービスを連携することを示す発着間紐付けＩＤを特定し、特定した発着間紐付けＩＤの収集元である情報表示端末２０各々に提供するサービスを連携するように、サービス提供を制御する。
【００７０】
データ受け渡し部２３３は、セッション管理サーバ１００による制御に従って、サービスに関連するデータの受け渡しを行う。すなわち、実施例１に係るサービス提供システムにおいて、データの受け渡しは、セッション管理サーバ１００において「受け渡し要求の要求元の情報表示端末が、収集したｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォンと組で利用される情報表示端末であるか否か」が判定されることによって制御される。言い換えると、セッション管理サーバ１００が、どのデータが受け渡しの対象であるのか、どの情報表示端末２０に受け渡すべきであるのかといった情報を、サービス提供サーバ２００に通知し、サービス提供サーバ２００を制御することで、データ受け渡し全体を制御するものであるといえる。データ受け渡し部２３３は、このようなセッション管理サーバ１００からの制御情報を受け取って、データの受け渡しを行う。なお、データ受け渡し部２３３による処理内容の詳細は、後述する処理手順の説明にて記載する。
【００７１】
なお、ここで、改めて、サービス提供サーバ２００によるサービス提供について考える。すなわち、サービス提供サーバ２００によるサービス提供が、情報表示端末２０間の関係に基づいて制御される点は、予め登録したバディリストに基づいてサービスを制御するような従来のサービス提供サーバと同様であるが、実施例１におけるサービス提供サーバ２００が、「情報表示端末２０間の関係」をどのように把握しているかを説明する。
【００７２】
つまり、実施例１におけるサービス提供サーバ２００は、従来のサービス提供サーバのように、予め記憶部に登録された関係（例えば、バディリストに登録された関係）を「情報表示端末２０間の関係」として把握するのではなく、サービス提供制御部２３２が、発着間紐付けＩＤを用いて「情報表示端末２０間の関係」を把握するのである。言い換えると、サービス提供サーバ２００は、ＳＩＰによって同一の通信を確立したＳＩＰフォン３０間の関係のように、通信相手となる端末との関係が一時的な場合にも、かかる一時的な通信関係に基づいて、情報表示端末２０各々において行われるＷｅｂ通信を互いに関連づけることで、一時的な通信関係に関連づけたサービス提供を可能としている。
【００７３】
なお、実施例１のように、第１の通信がＳＩＰによって通信を確立する過程の通信である場合には、「情報表示端末２０間の関係」がＳＩＰによる認証済みの関係であるという点でも意味がある。すなわち、ＳＩＰ通信においては、Digest（ダイジェスト）認証などが行われるのが一般的であり、ＳＩＰフォン３０間でＳＩＰによって通信が確立されたということは、情報表示端末２０各々の関係が認証済みであることを示す。
【００７４】
［ＨＧＷ］
図５に示すＨＧＷ１０は、以下に説明する各部が汎用的なゲートウェイ装置などに備えられることによって実現され、特に本発明に密接に関連するものとしては、図５に示すように、ＳＩＰ通信部／ＨＴＴＰ通信部１１と、記憶部１２と、制御部１３とを備える。
【００７５】
ＳＩＰ通信部／ＨＴＴＰ通信部１１は、ＳＩＰ用およびＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、ＳＩＰフォン３０とＳＩＰプロキシとの間の通信、情報表示端末２０とサービス提供サーバ２００との間の通信、ＨＧＷ１０とセッション管理サーバ１００との間の通信、ＨＧＷ１０とＳＩＰプロキシとの間の通信、ＨＧＷ１０とサービス提供サーバ２００との間の通信などを制御する。
【００７６】
記憶部１２は、制御部１３における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図５に示すように、ブラウザセッション情報管理テーブル１２ａを備える。
【００７７】
ブラウザセッション情報管理テーブル１２ａは、配下の情報表示端末２０に割り当てられたブラウザセッション情報を予め記憶する。例えば、ブラウザセッション情報管理テーブル１２ａは、図９−２に示すように、ＳＩＰフォン３０を一意に識別する情報（ＳＩＰフォンＩＤ）と、当該ＳＩＰフォン３０と組で利用される情報表示端末２０を一意に識別する情報（情報表示端末ＩＤ）と、当該情報表示端末２０を特定するためのブラウザセッション情報とを対応づけて予め記憶する。また、ブラウザセッション情報管理テーブル１２ａは、Ｃａｌｌ−ＩＤと、Ｆｒｏｍと、Ｔｏと、発着判定フラグと、通話情報とを対応付けて記憶している。ブラウザセッション情報管理テーブル１２ａが記憶するこれらの情報の内、Ｃａｌｌ−ＩＤと、Ｆｒｏｍと、Ｔｏとは、例えば、ＨＧＷ１０が収集し、登録したものである。発着判定フラグは、ＨＧＷ１０が、ＳＩＰによって確立された通信に含まれる情報から自ら生成した情報である。ＨＧＷ１０は、配下に接続するＳＩＰフォン３０を把握しているので、該当する呼が、発信であるのか、着信であるのかを判断することができる。
【００７８】
図５に戻り、制御部１３は、特に本発明に密接に関連するものとしては、図５に示すように、サービス利用制御部１３ａとデータ受け渡し部１３ｂとを備える。
【００７９】
サービス利用制御部１３ａは、情報表示端末２０によるサービス利用を制御する。データ受け渡し部１３ｂは、セッション管理サーバ１００による制御に従って、サービスに関連するデータの受け渡しを行う。
【００８０】
［ＳＩＰフォン］
ＳＩＰフォン３０は、汎用的なＳＩＰフォンによって実現され、特に本発明に密接に関連するものとしては、図６に示すように、入力部３２と、出力部３３と、入出力制御Ｉ／Ｆ部３４と、ＳＩＰ通信部３１とを備える。
【００８１】
いずれも汎用的なＳＩＰフォン３０と同様であるので簡単に説明すると、入力部３２は、ＳＩＰフォン３０に用いられる情報や、各種処理をするための操作指示などを、番号キーやマイクなどによって入力し、出力部３３は、ＳＩＰフォン３０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやスピーカに出力し、入出力制御Ｉ／Ｆ部３４は、入力部３２と、出力部３３と、ＳＩＰ通信部３１との間における情報転送を制御し、ＳＩＰ通信部３１は、ＳＩＰ用の一般的なインタフェースおよびライブラリを備え、他方のＳＩＰフォン３０との間で（ＨＧＷ１０を介して）情報を送受信する。
【００８２】
［情報表示端末］
情報表示端末２０は、以下に説明する各部が汎用的なＰＣや情報家電などに備えられることによって実現され、特に本発明に密接に関連するものとしては、図７に示すように、入力部２２と、出力部２３と、入出力制御Ｉ／Ｆ部２４と、ＨＴＴＰ通信部２１と、制御部２５とを備える。
【００８３】
入力部２２は、情報表示端末２０に用いられる情報や、各種処理をするための操作指示などを、キーボード、マウス、リモコンなどによって入力し、出力部２３は、情報表示端末２０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイやプリンタなどに出力し、入出力制御Ｉ／Ｆ部２４は、入力部２２と、出力部２３と、ＨＴＴＰ通信部２１と、制御部２５との間における情報転送を制御し、ＨＴＴＰ通信部２１は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、サービス提供サーバ２００との間でＨＧＷ１０を介して情報を送受信する。
【００８４】
制御部２５は、特に本発明に密接に関連するものとしては、図７に示すように、サービス利用部２５ａと受け渡し要求部２５ｂとを備える。
【００８５】
サービス利用部２５ａは、サービス提供サーバ２００によって提供されるサービスを利用する。具体的には、サービス利用部２５ａは、サービスの提供を開始するサービス提供開始要求をセッション管理サーバ１００に送信したり、サービスの利用を要求するサービス利用要求をサービス提供サーバ２００に送信したりする。
【００８６】
受け渡し要求部２５ｂは、セッション管理サーバ１００による制御に従って、サービスに関連するデータの受け渡しを行う。具体的には、受け渡し要求部２５ｂは、サービスに関連するデータの受け渡しを要求する受け渡し要求をセッション管理サーバ１００に送信するなどする。
【００８７】
［実施例１に係るサービス提供システムによる処理の手順］
続いて、図１０〜図２７−２を用いて、実施例１に係るサービス提供システムによる処理の手順を説明する。なお、実施例１に係るサービス提供システムによる処理は、サービス提供に関する処理（図１に対応）とデータ受け渡しに関する処理（図２に対応）とに大別され、またデータ受け渡しに関する処理として各種方式がある。以下では、サービス提供に関する処理の手順の一例を説明した後に、データ受け渡しに関する処理を各種方式毎に説明することとする。
【００８８】
図１０および図１１は、サービス提供に関する処理の手順を示すシーケンス図であり、図１２は、受け渡しフラグおよびデータ保存元フラグを説明するための図であり、図１３−１〜図１３−４は、各種方式を説明するための図であり、図１４〜図２７−２は、データ受け渡しに関する処理の手順を示すシーケンス図である。
【００８９】
［サービス提供に関する処理の手順］
図１０に示すように、まず、ＳＩＰプロキシが、両ＳＩＰフォン３０（ＳＩＰ通信部３１）による通信を制御することで、両ＳＩＰフォン３０（ＳＩＰ通信部３１）間でステップＳ１〜Ｓ３のＳＩＰ通信が行われ、その結果、ステップＳ４において、両ＳＩＰフォン３０間でＳＩＰによって通信（呼）が確立される。なお、ＳＩＰ通信におけるDigest認証やREGISTER処理などについては図示していないが、一般的なＳＩＰ通信と同様、ステップＳ１よりも前に行われている。
【００９０】
両ＳＩＰフォン３０間でＳＩＰによって通信が確立されると、ＨＧＷ１０（サービス利用制御部１３ａ）は、ＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を自ら収集することで取得し、また、発着判定フラグを取得する（ステップＳ５）。例えば、ＨＧＷ１０（サービス利用制御部１３ａ）は、ｃａｌｌセッション情報としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ）』および『Ｔｏ（ＳＩＰ−ＵＲＩ）』を、ＳＩＰによって確立された通信に含まれる情報から自ら収集することで取得する。また、ＨＧＷ１０（サービス利用制御部１３ａ）は、両ＳＩＰフォン３０が発側であるのか着側であるのかを示す『発着判定フラグ』を、ＳＩＰによって確立された通信に含まれる情報から自ら生成する。なお、ＨＧＷ１０（サービス利用制御部１３ａ）は、取得したｃａｌｌセッション情報等についてＨＧＷ１０の署名付証明書を発行し、当該署名付証明書をｃａｌｌセッション情報に添付することで、当該ｃａｌｌセッション情報を検証可能な形式で発行してもよい。
【００９１】
また、実施例１においては、ＨＧＷがｃａｌｌセッション情報を自ら収集し、発着判定フラグを自ら生成する手法を説明したが、この手法に限られるものではない。例えば、ＨＧＷが、ＳＩＰプロキシによって収集されたｃａｌｌセッション情報をＳＩＰプロキシから受信することで収集し、発着判定フラグについては自ら生成する手法でもよい。また、ＳＩＰプロキシから通知される情報に、ｃａｌｌセッション情報や発着判定フラグなどの情報が付与されていてもよい。
【００９２】
なお、ＳＩＰプロキシがｃａｌｌセッション情報を収集する点について簡単に説明しておくと、ＳＩＰプロキシは、ＳＩＰによって通信を確立する過程やＳＩＰによって確立された通信を制御する装置自身であるので、自装置が制御することで確立したセッションの情報を管理しているのが一般的である。したがって、ＳＩＰプロキシは、自らが制御することで両ＳＩＰフォン３０の間にセッションを確立すると、ｃａｌｌセッション情報としての『Ｃａｌｌ−ＩＤ』、『Ｆｒｏｍ（ＳＩＰ−ＵＲＩ）』、『Ｔｏ（ＳＩＰ−ＵＲＩ）』を、確立したセッションのＳＩＰ信号から収集することができる。そして、ＳＩＰプロキシは、収集したｃａｌｌセッション情報を、発側のＳＩＰフォン３０を配下に接続するＨＧＷ１０と、着側のＳＩＰフォン３０を配下に接続するＨＧＷ１０とに、プッシュ型で送信するなどする。すると、ＨＧＷ１０は、ＳＩＰプロキシによって収集されたｃａｌｌセッション情報をＳＩＰプロキシから受信することで、ｃａｌｌセッション情報を収集することができる。
【００９３】
なお、この手法の場合に、ＳＩＰプロキシは、ｃａｌｌセッション情報についてＳＩＰプロキシの署名付証明書を発行し、当該署名付証明書をｃａｌｌセッション情報に添付することで、当該ｃａｌｌセッション情報を検証可能な形式で発行してもよい。
【００９４】
図１０に戻り、続いて、ＨＧＷ１０（サービス利用制御部１３ａ）は、配下のＳＩＰフォン３０を一意に識別する情報であるＳＩＰフォンＩＤを、当該ＳＩＰ通信に含まれる情報から収集する（ステップＳ６）。なお、ＳＩＰフォンＩＤとは、例えば、ＳＩＰフォン３０の内線番号のことである。ＨＧＷ１０の配下に複数のＳＩＰフォン３０が接続される構成の場合、ＳＩＰ−ＵＲＩはＨＧＷ１０に対して付与され、ＨＧＷ１０配下のＳＩＰフォン３０各々には、内線番号が付与される。
【００９５】
そして、ＨＧＷ１０（サービス利用制御部１３ａ）は、ステップＳ４においてＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する（ステップＳ７）。具体的には、ＨＧＷ１０（サービス利用制御部１３ａ）は、まず、ＳＩＰフォンＩＤをキーとしてブラウザセッション情報管理テーブル１２ａを検索することで情報表示端末２０を特定し、特定した情報表示端末２０のブラウザセッション情報と、ＨＧＷ１０に対してポーリングを行う複数の情報表示端末２０各々のブラウザセッション情報とを比較し、ブラウザセッション情報の一致によって、ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０を特定する。
【００９６】
そして、ＨＧＷ１０（サービス利用制御部１３ａ）は、アクセス先変更指示を、ステップＳ７において特定された情報表示端末２０に対して行う。具体的には、特定された情報表示端末２０に対して、セッション管理サーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報等とともに行う（ステップＳ８）。この時、実施例１におけるＨＧＷ１０（サービス利用制御部１３ａ）は、セッション管理サーバ１００にＨＧＷ１０のＵＲＬを通知することを目的として、リダイレクト指示に、ＨＧＷ１０のＵＲＬをも含めている。すなわち、リダイレクト指示に含められたＨＧＷ１０のＵＲＬは、情報表示端末２０によってセッション管理サーバ１００に送信される。なお、実施例１においては、ＨＧＷ１０がセッション管理サーバ１００のＵＲＬを予め記憶部に記憶していることで、当該ＵＲＬにアクセス先を変更するようリダイレクト指示を行うことができる。この結果、情報表示端末２０は、リダイレクト指示を受け、ＨＧＷ１０のＵＲＬからセッション管理サーバ１００のＵＲＬにアクセス先を変更する。
【００９７】
すると、情報表示端末２０（サービス利用部２５ａ）はリダイレクトされ、接続先をセッション管理サーバ１００に変更し、サービスを開始することを要求するサービス開始要求を、当該セッション管理サーバ１００に送信する（ステップＳ９）。この時、情報表示端末２０（サービス利用部２５ａ）は、ｃａｌｌセッション情報等と、ＨＧＷ１０のＵＲＬとを、セッション管理サーバ１００に送信することになる。
【００９８】
一方、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、情報表示端末２０から送信されたｃａｌｌセッション情報等を受信すると、当該ｃａｌｌセッション情報等の検証を行う（ステップＳ１０）。すなわち、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、ｃａｌｌセッション情報等が真正な情報であることを検証する。例えば、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、ＳＩＰプロキシに問い合わせを行うことで、ｃａｌｌセッション情報等が真正な情報であることを検証する。なお、ｃａｌｌセッション情報等を、署名付証明書が添付された検証可能な形式で受信した場合には、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、例えば、当該署名付証明書を検証することで、ｃａｌｌセッション情報等が真正な情報であることを検証してもよい。
【００９９】
続いて、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、ステップＳ１０における検証の結果、ｃａｌｌセッション情報等が真正な情報であることを確認すると、当該ｃａｌｌセッション情報等、ＨＧＷ１０のＵＲＬ、及び通話情報としての開始時刻を制御用セッション管理テーブル１２３に格納し、制御用セッション情報を払い出し、払い出した制御用セッション情報を制御用セッション管理テーブル１２３に格納する（ステップＳ１１）。
【０１００】
続いて、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、サービス開始要求を送信してきた情報表示端末２０（発側）が利用可能なサービスをユーザ契約サービス管理テーブル１２１で確認し、契約サービスＩＤを取得する（ステップＳ１２）。
【０１０１】
そして、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、制御ページを生成する（ステップＳ１３）。
【０１０２】
続いて、セッション管理サーバ１００（ｃａｌｌセッション情報収集部１３１）は、情報表示端末２０に対して、接続先監視機能と、ステップＳ１１で払い出した制御用セッション情報と、ステップＳ１３で生成した制御ページと、ステップＳ１２で取得した契約サービスＩＤとを送信する（ステップＳ１４）。ここで、接続先監視機能とは、例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイルであり、情報表示端末２０にインストールされることで、情報表示端末２０とセッション管理サーバ１００との間で通信を確立し、情報表示端末２０の接続先を監視する役割を果たす機能である。
【０１０３】
すると、情報表示端末２０は、セッション管理サーバ１００から送信された制御ページをＷｅｂブラウザから表示する（ステップＳ１５）。また、情報表示端末２０は、セッション管理サーバ１００から送信された接続先監視機能をインストールする。すると、当該接続先監視機能部は、セッション管理サーバ１００との間で通信を確立し、セッション管理サーバ１００から送信された制御用セッション情報を用いてポーリングを行うことで、情報表示端末２０の接続先のＵＲＬをセッション管理サーバ１００に定期的に送信する。一方、セッション管理サーバ１００は、ポーリングに用いられている制御用セッション情報を確認することで（ステップＳ１６）、当該制御用セッション情報を払い出した情報表示端末２０の接続先を定期的に監視する。
【０１０４】
なお、これまで、発信側の情報表示端末２０について説明してきたが、着信側の情報表示端末２０についても同様の処理が行われる。こうして、発信側の情報表示端末２０および着信側の情報表示端末２０の両方に接続監視機能がインストールされ、接続先監視機能部各々とセッション管理サーバ１００との間で通信が確立される。
【０１０５】
続いて、図１１に示すように、発信側の情報表示端末２０の利用者が、Ｗｅｂブラウザに表示された制御ページの中からサービスを選択することで（ステップＳ２０）、情報表示端末２０（サービス利用部２５ａ）は、サービス開始要求をセッション管理サーバ１００に対して送信する（ステップＳ２１）。この時、情報表示端末２０（サービス利用部２５ａ）は、ステップＳ１４において送信された制御用セッション情報を用いて、選択したサービスの契約サービスＩＤをセッション管理サーバ１００に対して送信する。なお、サービス開始要求の送信は、図１１に示すように接続先監視機能を介して行われてもよく、あるいは、接続先監視機能を介さずに情報表示端末２０（サービス利用部２５ａ）から直接セッション管理サーバ１００に送信されてもよい。
【０１０６】
すると、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０から送信された制御用セッション情報が、制御用セッション管理テーブル１２３に登録されているものであることを確認し（ステップＳ２２）、発着間紐付けＩＤおよび仮名ＩＤを発行する（ステップＳ２３）。なお、発行された発着間紐付けＩＤおよび仮名ＩＤが発着間紐付けＩＤテーブル１２４に格納される実装例を説明する。例えば、発信側の情報表示端末２０の利用者が、制御ページの中からサービスを選択すると（サービスを起動すると）、情報表示端末２０（サービス利用部２５ａ）は、選択したサービスを識別するサービスＩＤをセッション管理サーバ１００に送信する。この時、情報表示端末２０（サービス利用部２５ａ）は、制御用セッション情報を用いる。すると、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０が用いた制御用セッション情報を検索キーとして制御用セッション管理テーブル１２３を参照し、情報表示端末２０から送信された制御用セッション情報が、制御用セッション管理テーブル１２３に登録されているものであることを確認する。そして、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、確認した制御用セッション情報を用いて発着間紐付けＩＤテーブル１２４を参照する。情報表示端末２０（サービス利用部２５ａ）による当該制御用セッション情報の送信が初回である場合には、制御用セッション情報は発着間紐付けＩＤテーブル１２４に未だ格納されていないはずである。このため、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤおよび仮名ＩＤを発行し、発行した発着間紐付けＩＤおよび仮名ＩＤを制御用セッション情報に対応付けて発着間紐付けＩＤテーブル１２４に格納し、さらに契約サービスＩＤ、ステータス（「利用中」）を格納する。一方、情報表示端末２０（サービス利用部２５ａ）による制御用セッション情報の送信が初回でない場合には、制御用セッション情報は発着間紐付けＩＤテーブル１２４に格納されているはずである。このため、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤおよび仮名ＩＤを新たに発行し、新たに発行した発着間紐付けＩＤおよび仮名ＩＤを、既に格納済みの制御用セッション情報に対応付けて発着間紐付けＩＤテーブル１２４に格納し（発着間紐付けＩＤおよび仮名ＩＤは更新される）、さらに契約サービスＩＤ、ステータス（「利用中」）を格納する。
【０１０７】
ここで、発着間紐付けＩＤとは、サービス提供サーバ２００において、発信側の情報表示端末２０と着信側の情報表示端末２０とを紐付けるために用いられるＩＤのことである。発信側のＳＩＰフォン３０と着信側のＳＩＰフォン３０との間でＳＩＰによって確立された通信は、ｃａｌｌセッション情報によって一意に識別することができるので、サービス提供サーバ２００は、当該ｃａｌｌセッション情報を用いれば、発信側の情報表示端末２０と着信側の情報表示端末２０とを紐付けることができる。しかしながら、ｃａｌｌセッション情報をサービス提供サーバ２００に開示することにセキュリティ上の問題があると考えられるような場合（例えば、どの利用者同士からのアクセスであるかをサービス提供事業者にはわからないようにする場合）には、ｃａｌｌセッション情報そのものをサービス提供サーバ２００に開示するべきではない。そこで、実施例１においては、ｃａｌｌセッション情報を匿名化し、かつ紐付け可能とするために、仮名の形式で、セッション管理サーバ１００が、発着間紐付けＩＤを発行するものである。また、仮名ＩＤとは、サービス提供サーバ２００において、発信側の利用者もしくは着信側の利用者を特定するために用いられるＩＤのことである。すなわち、発着間紐付けＩＤのみでは利用者までを特定することができないため、サービス提供事業者が利用者を特定することを目的として、情報表示端末２０と当該情報表示端末２０が利用するサービスとの組合せごとに、セッション管理サーバ１００が発行するものである。
【０１０８】
セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０に対して、サービス提供サーバのＵＲＬ（ステップＳ１２において取得したもの）と、発着間紐付けＩＤと、仮名ＩＤと、発着判定フラグとを送信する（ステップＳ２４）。また、実施例１におけるセッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを検証可能な形式で送信する。例えば、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグについてセッション管理サーバ１００の署名付証明書を発行し、当該署名付証明書を発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグに添付することで、当該発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを検証可能な形式で発行する。なお、署名付証明書を添付する手法に限られるものではなく、添付しない手法を用いてもよい。
【０１０９】
一方、情報表示端末２０（サービス利用部２５ａ）は、セッション管理サーバ１００から送信されたＵＲＬに接続し、セッション管理サーバ１００から送信された発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを、サービス提供サーバ２００に送信する（ステップＳ２５）。
【０１１０】
すると、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、情報表示端末２０から送信された発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを受信すると、当該発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグの検証を行う（ステップＳ２６）。すなわち、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグに添付された署名付証明書を検証することで、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを検証する。なお、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを検証する手法としては、セッション管理サーバ１００に問い合わせを行う手法でもよい。
【０１１１】
続いて、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、ステップＳ２６における検証の結果、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグが真正な情報であることを確認すると、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを送信した情報表示端末２０が行うＷｅｂ通信（サービス提供を受けるために情報表示端末２０がサービス提供サーバ２００との間で行うＷｅｂ通信）に付与する情報として、Ｗｅｂセッション情報を払い出し、払い出したＷｅｂセッション情報をＷｅｂセッション情報管理テーブル２２１に格納するとともに、発着間紐付けＩＤ、仮名ＩＤおよび発着判定フラグを格納する（ステップＳ２７）。すると、Ｗｅｂセッション情報管理テーブル２２１は、図９−１に示すように、Ｗｅｂセッション情報と発着間紐付けＩＤと仮名ＩＤと発着判定フラグとを格納することになる。なお、このように、サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、仮名ＩＤや発着判定フラグをも格納していれば、サービス提供サーバ２００（サービス提供制御部２３２）がサービスを提供する際に、この仮名ＩＤや発着判定フラグに基づいたサービス提供を制御することも可能になる。
【０１１２】
サービス提供サーバ２００（発着間紐付けＩＤ収集部２３１）は、続いて、サービス提供画面を生成し（ステップＳ２８）、ステップＳ２７において払い出したＷｅｂセッション情報とともに、生成したサービス提供画面を情報表示端末２０に送信する（ステップＳ２９）。
【０１１３】
すると、情報表示端末２０のＷｅｂブラウザには、サービス提供画面が表示される（ステップＳ３０）。
【０１１４】
ところで、実施例１においては、セッション管理サーバ１００（発着間紐付けＩＤ発行部１３２）は、ステップＳ２１におけるサービス開始要求に応じて発信側の情報表示端末２０を制御すると同時に（あるいは直ちに）、着信側の情報表示端末２０についても制御する。すなわち、図１１には図示していないが、着信側の情報表示端末２０も、ステップＳ２１〜Ｓ２３と同様の処理手順によってステップＳ３１に移行する。ステップＳ３１は、発信側の情報表示端末２０について行われるステップＳ２４に対応する処理である。また、着信側の情報表示端末２０も、ステップＳ２４〜Ｓ３０と同様の処理手順、すなわちステップＳ３１〜Ｓ３７を行う結果、着信側の情報表示端末２０のＷｅｂブラウザにも、サービス提供画面が表示される。このため、発信側の情報表示端末２０および着信側の情報表示端末２０の両方が直ちにサービスを利用する状態となる。
【０１１５】
すなわち、サービス提供サーバ２００（サービス提供制御部２３２）は、ステップＳ２７において発信側の情報表示端末２０に対してＷｅｂセッション情報を払い出し、発着間紐付けＩＤとともにＷｅｂセッション情報管理テーブル２２１に格納するとともに、ステップＳ３４において着信側の情報表示端末２０に対してＷｅｂセッション情報を払い出し、発着間紐付けＩＤとともにＷｅｂセッション情報管理テーブル２２１に格納する。すると、サービス提供サーバ２００（サービス提供制御部２３２）は、ステップＳ３８において、Ｗｅｂセッション情報管理テーブル２２１に格納されている複数の発着間紐付けＩＤの内、所定の発着間紐付けＩＤ各々がサービスを連携すべきものであることを示す場合に、当該発着間紐付けＩＤ各々に対応づけて格納されているＷｅｂセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する（ステップＳ３９〜Ｓ４２）。
【０１１６】
例えば、一方の情報表示端末２０（サービス利用部２５ａ）が、ステップＳ２７において払い出されたＷｅｂセッション情報が付与されたＷｅｂ通信によって、サービス提供サーバ２００に画像データをアップロードし（ステップＳ４０）、他方の情報表示端末２０（サービス利用部２５ａ）が、同じくステップＳ３４において払い出されたＷｅｂセッション情報が付与されたＷｅｂ通信によって、サービス提供サーバ２００にアクセスしていたとする（ステップＳ３９）。すると、サービス提供サーバ２００（サービス提供制御部２３２）は、他方の情報表示端末２０に画像データを送信するよう、サービスを制御するので、他方の情報表示端末２０に画像データが送信され（ステップＳ４１）、他方の情報表示端末２０は、出力部２３に画像データを表示するなどする（ステップＳ４２）。
【０１１７】
このように、実施例１においては、セッション管理サーバ１００が、発信側の情報表示端末２０を制御すると同時に（あるいは直ちに）、着信側の情報表示端末２０についても制御する手法を説明したが、本発明はこれに限られるものではない。この他の手法として、例えば、着信側の情報表示端末２０が、自らサービスを選択し、発信側の情報表示端末２０と同様にサービス開始要求をセッション管理サーバ１００に送信したことを契機として、セッション管理サーバ１００が、着側の情報表示端末２０についても制御する手法にも、本発明を同様に適用することができる。あるいは、例えば、発信側の情報表示端末２０が、セッション管理サーバ１００に対して、着信側の情報表示端末２０の制御を行うように要求したことを契機として、セッション管理サーバ１００が、ステップＳ３１以降の処理を開始する手法にも、本発明を同様に適用することができる。
【０１１８】
［データ受け渡しに関する処理］
まず、実施例１におけるサービス提供システムにおいては、情報表示端末２０がセッション管理サーバ１００やサービス提供サーバ２００に送信する受け渡し要求に、受け渡し先を指定する受け渡し先フラグや受け渡しの対象となるデータの保存元を指定するデータ保存元フラグなどが含められる。この結果、セッション管理サーバ１００のデータ受け渡し制御部１３４や、サービス提供サーバ２００のデータ受け渡し部２３３は、後述するように、受け渡し要求に含められていた受け渡し先フラグやデータ保存元フラグに従って、当該データ保存元フラグにて指定されたデータを、当該受け渡し先フラグにて指定された受け渡し先へと受け渡すよう制御する。例えば、実施例１における受け渡し先フラグおよびデータ保存元フラグは、図１２に示すようなものである。
【０１１９】
図１２に示す「自ＨＧＷ」とは、受け渡し要求を送信する情報表示端末２０と同じサイトに設置されたＨＧＷ１０（当該情報表示端末２０のネットワークに対する接続を制御するＨＧＷ１０のこと、例えば、受け渡し要求を送信する情報表示端末２０が発信側の情報表示端末２０であれば、同じく発信側のＨＧＷ１０のこと）を意味する。また、「通話相手ＨＧＷ」とは、受け渡し要求を送信する情報表示端末２０と組で利用されるＳＩＰフォン３０の通話相手となるＳＩＰフォン３０と同じサイトに設置されたＨＧＷ１０（通話相手となるＳＩＰフォン３０のネットワークに対する接続を制御するＨＧＷ１０のこと、例えば、受け渡し要求を送信する情報表示端末２０が発信側の情報表示端末２０であれば、着信側のＨＧＷ１０のこと）を意味する。また、「両ＨＧＷ」とは、発信側のＨＧＷ１０及び着信側のＨＧＷ１０の双方（自ＨＧＷ及び通話相手ＨＧＷの双方）を意味する。
【０１２０】
また、「利用中サービス」とは、現在利用者が利用中のサービスを指定する際に利用するＩＤのことであり、発着間紐付けＩＤテーブル１２４の「ステータス」が「利用中」のサービスＩＤに対応するものである。また、「サービスＩＤ指定」とは、サービスを指定する際に利用するＩＤのことであり、利用中か否かにかかわらずサービスＩＤを直接指定するものである。なお、この場合には、セッション管理サーバ１００は、例えば、そのサービスを利用可能であるか否かをユーザ契約サービス管理テーブル１２１を参照することで確認してもよい。すなわち、セッション管理サーバ１００は、例えば、利用可能であることを確認できた時のみ、データの受け渡しを制御するようにしてもよい。
【０１２１】
ここで、実施例１におけるサービス提供システムにおいては、セッション管理サーバ１００のデータ受け渡し制御部１３４や、サービス提供サーバ２００のデータ受け渡し部２３３は、受け渡し先フラグやデータ保存元フラグ、サービスＩＤを把握しているものとする。すなわち、セッション管理サーバ１００のデータ受け渡し制御部１３４や、サービス提供サーバ２００のデータ受け渡し部２３３が、受け渡し要求に含められていた受け渡し先フラグやデータ保存元フラグを参照し、参照したフラグの内容から、受け渡し先がどのＨＧＷやサーバであるのか、あるいはデータ保存元がどのＨＧＷやサーバであるのかを識別する。そして、セッション管理サーバ１００のデータ受け渡し制御部１３４や、サービス提供サーバ２００のデータ受け渡し部２３３は、識別したデータ保存元や受け渡し先フラグに従ってデータの受け渡しがなされるように、その後の処理手順を制御するのである。
【０１２２】
また、実施例１におけるサービス提供システムにおいては、図１３−１〜図１３−４に示すように、データ受け渡しに関する処理として、４つに大別される方式が行われる。具体的には、方式１は、セッション管理サーバ１００が管理するセッションに関する情報（ｃａｌｌセッション情報、発着判定フラグおよび通話情報）に基づき、通話の延長でサービス提供サーバからＨＧＷへとデータを受け渡す方式である。方式２は、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長でＨＧＷからサービス提供サーバへとデータを受け渡す方式である。方式３は、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長でサービス提供サーバからサービス提供サーバへとデータを受け渡す方式である。方式４は、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長でＨＧＷからＨＧＷへとデータを受け渡す方式である。以下では、まず、各方式の具体的な適用例について説明した後に、各方式の処理手順を詳細に説明する。
【０１２３】
［方式１の適用例］
例えば、方式１によれば、図１３−１に示すように、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長で、店の電話番号やメニュー情報などのデータを、飲食店情報を提供するサービス提供サーバ（コンシェルジュサービスを提供するサービス提供サーバ）からＨＧＷに受け渡すことができる。
【０１２４】
例えば後述する方式１−１に則って説明すると、利用者Ａと利用者Ｂ（コンシェルジュサービスのコールセンタのオペレータ）とが通話中に、飲食店情報共有サービスのサイトを閲覧していたとする。なお、サービス提供サーバによって制御されることで利用者Ａと利用者Ｂとが閲覧する画面は連携している。ここで、利用者Ａが、画面に表示された『店情報ダウンロードボタン』（図示を省略）を押下したとする。すると、データの受け渡しを要求する受け渡し要求が、利用者Ａの情報表示端末から、セッション管理サーバへと送信される。この受け渡し要求は、飲食店情報提供サービスを提供するサービス提供サーバをデータ保存元とし、自ＨＧＷを受け渡し先として指定するものである。
【０１２５】
すると、セッション管理サーバは、利用者Ａと利用者Ｂとが通話中であるか否かを、自装置が管理するセッションに関する情報から判定し、通話中であると判定すると、飲食店情報提供サービスを提供するサービス提供サーバから利用者ＡのＨＧＷへのデータ受け渡しを制御する。例えば、セッション管理サーバは、飲食店情報提供サービスを提供するサービス提供サーバから、店の電話番号やメニュー情報などを取得し、取得したこれらの情報をブラウザセッション情報とともに利用者ＡのＨＧＷに送信する。
【０１２６】
このように、セッション管理サーバが、利用者Ａと利用者Ｂとの間で確立された通話に基づいてデータの受け渡しを制御するので、利用者Ａは、利用者Ｂとの間で確立した通話の延長でデータの受け渡しを行うことが可能になる。すなわち、セッション管理サーバが管理しているセッションに関する情報に基づいて行われるデータの受け渡しであるので、利用者Ａは、セッション管理サーバやサービス提供サーバにログインするためのログイン操作をする必要もなければ、ＨＧＷに関する情報などを入力する必要もなく、手間が軽減され、入力間違いもなくなる。さらに、利用者Ａは、通話中に利用可能なサービス提供サーバからのみＨＧＷへのデータ受け渡しを行うので、利用者Ａが利用できない非加入のサービス提供サーバから勝手にＨＧＷへのデータ受け渡しが行われてしまうといったおそれもなくなり、データの受け渡しを安心して行うことができる。また、後述するように、セッション管理サーバが、データの受け渡しに関する履歴情報を管理すれば、利用者Ａは、いつ、どこの誰と、何のサービス利用中に、どのデータを受け渡したのかを把握することができ、例えば何らかの問題発生時などに正確な状況把握を行うことができるので、データの受け渡しを安心確実に行うことができる。なお、利用者Ａは、ＨＧＷに店の電話番号が格納されたので、電話帳に電話番号を改めて入力する必要もなく、容易に再度電話をすることが可能になる。
【０１２７】
［方式２の適用例］
また、例えば、方式２によれば、図１３−２に示すように、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長で、利用者の住所情報などを、ＨＧＷから地図情報提供サービスを提供するサービス提供サーバに受け渡すことができる。
【０１２８】
例えば、後述する方式２−１に則って説明すると、利用者Ａと利用者Ｂとが通話中に、地図情報提供サービスのサイトを閲覧していたとする。なお、サービス提供サーバによって制御されることで利用者Ａと利用者Ｂとが閲覧する画面は連携している。ここで、利用者Ａ及び利用者Ｂが、画面に表示された『住所情報アップロードボタン』（図示を省略）を押下したとする。すると、データの受け渡しを要求する受け渡し要求が、利用者Ａ及び利用者Ｂの情報表示端末双方から、セッション管理サーバへと送信される。この受け渡し要求は、利用者ＡのＨＧＷあるいは利用者ＢのＨＧＷをデータ保存元とし、サービス提供サーバを受け渡し先として指定するものである。
【０１２９】
すると、セッション管理サーバは、利用者Ａと利用者Ｂとが通話中であるか否かを、自装置が管理するセッションに関する情報から判定し、通話中であると判定すると、利用者Ａ（あるいは利用者Ｂ）のＨＧＷから地図情報提供サービスを提供するサービス提供サーバへのデータ受け渡しを制御する。例えば、利用者ＡのＨＧＷから住所情報を取得し、取得した住所情報を、地図情報提供サービスを提供するサービス提供サーバへ送信する。
【０１３０】
このように、セッション管理サーバが、利用者Ａと利用者Ｂとの間で確立された通話に基づいてデータの受け渡しを制御するので、利用者Ａ（利用者Ｂ）は、利用者Ｂ（利用者Ａ）との間で確立した通話の延長でデータの受け渡しを行うことが可能になる。すなわち、セッション管理サーバが管理しているセッションに関する情報に基づいて行われるデータの受け渡しであるので、利用者は、セッション管理サーバやサービス提供サーバにログインするためのログイン操作をする必要もなければ、ＨＧＷに関する情報や住所情報などを入力する必要もなく、手間が軽減され、入力間違いもなくなる。さらに、利用者は、通話中に利用可能なサービス提供サーバにのみＨＧＷからデータ受け渡しを行うので、利用者が利用できない非加入のサービス提供サーバに対して勝手にＨＧＷのデータが受け渡されてしまうといったおそれもなくなり、データの受け渡しを安心して行うことができる。また、後述するように、セッション管理サーバが、データの受け渡しに関する履歴情報を管理すれば、利用者は、いつ、どこの誰と、何のサービス利用中に、どのデータを受け渡したのかを把握することができ、例えば何らかの問題発生時などに正確な状況把握を行うことができるので、データの受け渡しを安心確実に行うことができる。なお、通話中の利用者双方から住所情報が受け渡されれば、例えば、サービス提供サーバは、利用者双方の中間地点に位置する住所を割り出してサービスを提供することができる。
【０１３１】
また、例えば、方式２によれば、上記の例と同様、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長で、利用者の住所情報などを、ＨＧＷから通販サービス（コールセンタサービス）を提供するサービス提供サーバに受け渡すことができる。
【０１３２】
例えば、後述する方式２−１に則って説明すると、利用者Ａと利用者Ｂ（コールサービスセンタのオペレータ）とが通話中に、通販サービスサービスのサイトを閲覧していたとする。なお、サービス提供サーバによって制御されることで利用者Ａと利用者Ｂとが閲覧する画面は連携している。ここで、利用者Ａが、画面に表示された『住所情報アップロードボタン』（図示を省略）を押下したとする。すると、データの受け渡しを要求する受け渡し要求が、利用者Ａの情報表示端末から、セッション管理サーバへと送信される。この受け渡し要求は、利用者ＡのＨＧＷをデータ保存元とし、サービス提供サーバを受け渡し先として指定するものである。
【０１３３】
すると、セッション管理サーバは、利用者Ａと利用者Ｂとが通話中であるか否かを、自装置が管理するセッションに関する情報から判定し、通話中であると判定すると、利用者ＡのＨＧＷから通販サービスを提供するサービス提供サーバへのデータ受け渡しを制御する。例えば、利用者ＡのＨＧＷから住所情報を取得し、取得した住所情報を、通販サービスを提供するサービス提供サーバへ送信する。
【０１３４】
このように、セッション管理サーバが、利用者Ａと利用者Ｂとの間で確立された通話に基づいてデータの受け渡しを制御するので、利用者Ａは、利用者Ｂとの間で確立した通話の延長でデータの受け渡しを行うことが可能になる。すなわち、セッション管理サーバが管理しているセッションに関する情報に基づいて行われるデータの受け渡しであるので、利用者は、セッション管理サーバやサービス提供サーバにログインするためのログイン操作をする必要もなければ、ＨＧＷに関する情報や住所情報などを入力する必要もなく、手間が軽減され、入力間違いもなくなる。さらに、利用者は、通話中に利用可能なサービス提供サーバにのみＨＧＷからデータ受け渡しを行うので、利用者が利用できない非加入のサービス提供サーバに対して勝手にＨＧＷのデータが受け渡されてしまうといったおそれもなくなり、データの受け渡しを安心して行うことができる。また、後述するように、セッション管理サーバが、データの受け渡しに関する履歴情報を管理すれば、利用者は、いつ、どこの誰と、何のサービス利用中に、どのデータを受け渡したのかを把握することができ、例えば何らかの問題発生時などに正確な状況把握を行うことができるので、データの受け渡しを安心確実に行うことができる。
【０１３５】
［方式３の適用例］
また、例えば、方式３によれば、図１３−３に示すように、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長で、写真データなどを、写真共有サービスを提供するサービス提供サーバから、写真プリントサービスを提供するサービス提供サーバに受け渡すことができる。
【０１３６】
例えば、後述する方式３−１に則って説明すると、利用者Ａと利用者Ｂとが通話中に、写真共有サービスのサイトを閲覧していたとする。なお、サービス提供サーバによって制御されることで利用者Ａと利用者Ｂとが閲覧する画面は連携している。ここで、利用者Ａが、画面に表示された所定の写真を選択し、画面に表示された『購入ボタン』を押下したとする。すると、データの受け渡しを要求する受け渡し要求が、利用者Ａの情報表示端末から、セッション管理サーバへと送信される。この受け渡し要求は、写真共有サービスを提供するサービス提供サーバをデータ保存元とし、写真プリントサービスを提供するサービス提供サーバを受け渡し先として指定するものである。
【０１３７】
すると、セッション管理サーバは、利用者Ａと利用者Ｂとが通話中であるか否かを、自装置が管理するセッションに関する情報から判定し、通話中であると判定すると、写真共有サービスサーバを提供するサービス提供サーバから、写真プリントサービスを提供するサービス提供サーバへの写真データの受け渡しを制御する。例えば、セッション管理サーバは、利用者Ａと利用者Ｂとが利用中のサービス提供サーバに対して、選択された写真を識別する情報等を送信することで、該当する写真データを取得し、取得した写真データを、受け渡し先として指定されたサービス提供サーバへ送信する。
【０１３８】
このように、セッション管理サーバが、利用者Ａと利用者Ｂとの間で確立された通話に基づいてデータの受け渡しを制御するので、利用者Ａは、利用者Ｂ（利用者Ａ）との間で確立した通話の延長でデータの受け渡しを行うことが可能になる。すなわち、セッション管理サーバが管理しているセッションに関する情報に基づいて行われるデータの受け渡しであるので、利用者は、セッション管理サーバやサービス提供サーバにログインするためのログイン操作をする必要もなく、手間が軽減され、入力間違いもなくなる。さらに、利用者は、通話中に利用可能なサービス提供サーバ間でのみ、データ受け渡しを行うので、利用者が利用できない非加入のサービス提供サーバ間で勝手にデータが受け渡されてしまうといったおそれもなくなり、データの受け渡しを安心して行うことができる。また、後述するように、セッション管理サーバが、データの受け渡しに関する履歴情報を管理すれば、利用者は、いつ、どこの誰と、何のサービス利用中に、どのデータを受け渡したのかを把握することができ、例えば何らかの問題発生時などに正確な状況把握を行うことができるので、データの受け渡しを安心確実に行うことができる。なお、この適用例においては、例えば、写真プリントサービスを提供するサービス提供サーバは、図１３−４に示すように、予め利用者Ａの住所情報を格納している。このため、写真プリントサービスを提供するサービス提供サーバは、写真共有サービスを提供するサービス提供サーバから送信された写真データを印刷し、利用者Ａの住所情報を用いて、利用者Ａの自宅まで配送することができる。
【０１３９】
［方式４の適用例］
また、例えば、方式４によれば、図１３−４に示すように、セッション管理サーバ１００が管理するセッションに関する情報に基づき、通話の延長で、写真データなどを、通話中の利用者のＨＧＷ間で受け渡すことができる。
【０１４０】
例えば、後述する方式４−１に則って説明すると、利用者Ａと利用者Ｂとが通話中に、写真共有サービスのサイトを閲覧していたとする。なお、サービス提供サーバによって制御されることで利用者Ａと利用者Ｂとが閲覧する画面は連携している。ここで、利用者Ｂが、画面に表示された所定の写真を選択し、画面に表示された『送信ボタン』を押下したとする。すると、データの受け渡しを要求する受け渡し要求が、利用者Ｂの情報表示端末から、セッション管理サーバへと送信される。この受け渡し要求は、利用者ＡのＨＧＷをデータ保存元とし、利用者ＢのＨＧＷを受け渡し先として指定するものである。
【０１４１】
すると、セッション管理サーバは、利用者Ａと利用者Ｂとが通話中であるか否かを、自装置が管理するセッションに関する情報から判定し、通話中であると判定すると、写真共有サービスサーバを提供するサービス提供サーバから、利用者ＡのＨＧＷから利用者ＢのＨＧＷへの写真データの受け渡しを制御する。例えば、セッション管理サーバは、利用者ＡのＨＧＷから該当する写真データを取得し、取得した写真データを、受け渡し先として指定された利用者ＢのＨＧＷへ送信する。
【０１４２】
このように、セッション管理サーバが、利用者Ａと利用者Ｂとの間で確立された通話に基づいてデータの受け渡しを制御するので、利用者Ａは、利用者Ｂ（利用者Ａ）との間で確立した通話の延長でデータの受け渡しを行うことが可能になる。すなわち、セッション管理サーバが管理しているセッションに関する情報に基づいて行われるデータの受け渡しであるので、利用者は、セッション管理サーバやサービス提供サーバにログインするためのログイン操作をする必要もなければ、ＨＧＷに関する情報などを入力する必要もなく、手間が軽減され、入力間違いもなくなる。さらに、利用者は、通話相手との間でのみデータ受け渡しを行うので、ＨＧＷのデータが勝手に受け渡されてしまうといったおそれもなくなり、データの受け渡しを安心して行うことができる。また、後述するように、セッション管理サーバが、データの受け渡しに関する履歴情報を管理すれば、利用者は、いつ、どこの誰と、何のサービス利用中に、どのデータを受け渡したのかを把握することができ、例えば何らかの問題発生時などに正確な状況把握を行うことができるので、データの受け渡しを安心確実に行うことができる。
【０１４３】
以下では、方式１〜方式４を順に説明する。なお、方式１〜方式４のいずれによっても、サービス提供システムの利用者は、受け渡し先の情報やデータ保存元の情報（例えば、ＵＲＬ、利用者ＩＤ、電話番号など）を改めて詳細にセッション管理サーバ１００に開示することなく、受け渡し先フラグやデータ保存元フラグを指定した受け渡し要求を送信するのみで、データ受け渡しを実現することが可能になる。また、ＨＧＷ１０は、外部ネットワークからのＨＴＴＰアクセスを非許容とすることが可能になり、外部ネットワークにＨＴＴＰサーバを公開する必要がない。また、方式１〜方式４のいずれによっても、セッション管理サーバ１００は、データ受け渡しに関するステータス情報を適宜格納し、記憶しているので、データ受け渡しの履歴情報が管理され、データ受け渡しを確実なものとすることができる。
【０１４４】
［方式１］
方式１は、上記したように、現に通話中の利用者であるとの判定に基づいてセッション管理サーバ１００が制御することで、サービス提供サーバ２００からＨＧＷ１０へとデータを受け渡す方式である。方式１には、図１４〜１８に示すように、例えば方式１−１〜１−５の種類がある。各方式の相違点を簡単に説明すると、まず、方式１−１〜方式１−３は、データの受け渡しを要求する受け渡し要求がセッション管理サーバ１００に対して送信される方式であるのに対し、方式１−４は、受け渡し要求がサービス提供サーバ２００に対して送信される方式である。このように、実施例１におけるサービス提供システムは、受け渡し要求がセッション管理サーバ１００に対して送信される場合にもサービス提供サーバ２００に対して送信される場合にも、現に通話中の利用者であるとの判定に基づいて、サービス提供サーバ２００からＨＧＷ１０へとデータを受け渡すことができる。
【０１４５】
また、方式１−１〜方式１−３の各方式の相違点としては、方式１−１及び方式１−２は、セッション管理サーバ１００が、受け渡しの対象となるデータを直接送受信する方式（セッション管理サーバ１００が受け渡しの対象となるデータ自体を一度は取得し、取得したデータを送受信の対象とする方式）であるのに対し、方式１−３は、セッション管理サーバ１００が、データの受け渡しを制御するものの、受け渡しの対象となるデータを直接送受信しない方式である。このため、例えば秘匿性の高いデータを受け渡しの対象とする場合などに方式１−３を採用することで、データがセッション管理サーバ１００に取得されることがなくなり、方式１−１や方式１−２に比較して、セキュリティをより向上することが可能になる。また、セッション管理サーバ１００がそのようなデータを保持する必要がなくなるので、セッション管理サーバ１００の負荷を軽減することも可能になる。さらに、セッション管理サーバ１００は、そのようなデータを保持せずとも、利用者間でデータの受け渡しが行われたことを把握することが可能になる。また、方式１−１と方式１−２との相違点としては、後述するように、方式１−２を採用することで、方式１−１に比較して、宅内ネットワーク（ＨＧＷ１０以下のネットワーク）の負荷をより軽減することが可能になり、また、情報表示端末２０がデータをアップロードしなくて済むため能力が低い情報表示端末２０でも対応することが可能になる。
【０１４６】
また、方式１−１〜方式１−４は、データの暗号化を想定しないで行う方式であるのに対し（もっとも、方式１−１〜方式１−４であっても、通信路の暗号化などの手法によるデータの暗号化が併用されてもよい）、方式１−５は、データを暗号化してから受け渡す方式である。このため、方式１−５を方式１−１や方式１−２と組み合わせれば、方式１−１や方式１−２であっても、例えば秘匿性の高いデータを受け渡しの対象とする場合などに適用することができる。すなわち、方式１−１や方式１−２は、上記したように、セッション管理サーバ１００が、受け渡しの対象となるデータを直接送受信する方式であるが、方式１−５は、データを暗号化してから受け渡すので、セッション管理サーバ１００は、データを復号できなければ実質的にデータを取得することにはならず、セキュリティをより向上することが可能になるのである。また、方式１−５は、セッション管理サーバ１００が、後に利用者双方の鍵情報を取得すれば、受け渡しの対象となったデータの正当性を検証することも可能になる。なお、例えば方式１−１のように、セッション管理サーバ１００からＨＧＷ１０へのデータ送信がリダイレクト方式によって行われる場合には、ＨＧＷ１０の外部通信用ポートを外部に公開しなくて済み、セキュリティをより向上することが可能になる。これは、方式１−１以外の他の方式においても、リダイレクト方式を採用する場合に共通の効果である。
【０１４７】
［方式１−１］
図１４を用いて方式１−１を説明する。図１４に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ１０１）。例えば、図１１のステップＳ３０やＳ３７において、情報表示端末２０のＷｅｂブラウザには、サービス提供サーバ２００が提供するサービス提供画面が表示された。このため、発信側の利用者と着信側の利用者とは、通話中に、情報表示端末２０を用いてサービス提供サーバ２００が提供するサイトを閲覧できる状況にある。また、サービス提供サーバ２００によって制御されることで、発信側の利用者と着信側の利用者とが閲覧するサービス提供画面は連携している。ここで、例えば、発信側の利用者が、画面に表示されたブラウザの受け渡しボタンを押下する。
【０１４８】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ１０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。ここで、データの受け渡しについて説明すると、受け渡しの対象となるデータとしては、例えば、受け渡し要求の要求元が開示権を有するデータが受け渡しの対象となる場合や、要求元の通話相手が開示権を有するデータが受け渡しの対象となる場合、あるいはサービス提供サーバが開示権を有するデータが受け渡しの対象となる場合などがある。なお、開示権とは、受け渡し要求の対象となっているデータを開示してよいか否かを判断する権限のことである。
【０１４９】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含め、データ保存元フラグとして『５』（契約サービスＩＤ指定）を含め、さらにサービスＩＤ『１００１』を含めることで、サービス提供サーバ２００が提供するサービス『１００１』に関連するデータを自ＨＧＷ１０に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０１５０】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ１０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０１５１】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０１５２】
なお、利用者が現に通話中であるか否かを確認する手法としては、上記した制御用セッション情報で判定する手法の他、発着間紐付けＩＤで判定する手法（受け渡し要求に付与されていた発着間紐付けＩＤを用いて制御用セッション管理テーブル１２３を参照する手法）、仮名ＩＤで判定する手法（受け渡し要求に付与されていた仮名ＩＤを用いて制御用セッション管理テーブル１２３を参照する手法）、発着間紐付けＩＤおよび仮名ＩＤで判定する手法（受け渡し要求に付与されていた発着間紐付けＩＤおよび仮名ＩＤを用いて制御用セッション管理テーブル１２３を参照する手法）など、様々な手法がある。なお、このように様々な手法を適用できるという点について、以下に説明する方式１〜方式４の他の方式についても同様にあてはまるものである。
【０１５３】
なお、実施例１においては、「ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０であるか否か」を判定する手法として、情報表示端末２０の利用者が現に通話中の利用者であることまでを判定する手法を説明したが、本発明はこれに限られるものではない。例えば、少なくとも過去に通話したことのある利用者であることを判定すればよい場合には、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認すればよい。もっともこの場合には、セッション管理サーバ１００が、過去の通話履歴を管理していることが前提となる。すなわち、セッション管理サーバ１００が、通話情報の終了時刻が記録されたレコードを、履歴情報として制御用セッション管理テーブル１２３に一定期間記憶していることが前提となる。なお、この点について、以下に説明する方式１〜方式４の他の方式についても同様にあてはまるものである。
【０１５４】
また、図１４に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０１５５】
次に、受け渡し要求判定部１３３は、データ保存元フラグが『５』の場合であるので、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けられているｃａｌｌセッション情報および発着判定フラグからユーザ特定情報『０３１１１１１１１１』を取得する。次に、受け渡し要求判定部１３３は、取得したユーザ特定情報『０３１１１１１１１１』を用いてユーザ契約サービス管理テーブル１２１を参照し、ユーザ特定情報『０３１１１１１１１１』に対応付けられている契約サービスＩＤを確認する。すなわち、契約サービスＩＤとして『１００１』が対応付けられているか否かを確認する。そして、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤを格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００１』をデータ保存元情報に格納する。
【０１５６】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ１０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０１５７】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ１０４〜Ｓ１１０に示すデータ受け渡しを制御する。
【０１５８】
まず、データ受け渡し制御部１３４は、受け渡しの対象となるデータを取得する。具体的には、データ受け渡し制御部１３４は、受け渡し要求に含められていたサービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照する。そして、データ受け渡し制御部１３４は、契約サービスＩＤ『１００１』に対応付けて記憶されているサービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を含めたデータ取得要求をＵＲＬ『http://example1.co.jp』に対して送信する（ステップＳ１０４）。
【０１５９】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、データ取得要求に含められていた仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得する（ステップＳ１０５）。なお、サービスの内容によっては、例えば、データ受け渡し部２３３は、データ取得要求に含められていた発着間紐付けＩＤ『ｌｉｎ３３３３』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、発着間紐付けＩＤ『ｌｉｎ３３３３』に対応付けて記憶されている仮名ＩＤ『ｋａｍｅｉ３１１１』を取得し、さらに仮名ＩＤ『ｋａｍｅｉ３１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ３１１１』に対応付けて記憶されているデータを取得してもよい。
【０１６０】
そして、データ受け渡し部２３３は、セッション管理サーバ１００から送信されたデータ取得要求に対する応答として、ステップＳ１０５において取得したデータをセッション管理サーバ１００に対して送信する（ステップＳ１０６）。
【０１６１】
次に、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、受け渡し先情報に格納されている受け渡し先フラグ『１』から、データの受け渡し先が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０１６２】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０１６３】
続いて、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ１０６において取得したデータ及びｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ１０７）。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、以下に説明するように、ＨＧＷ１０が、受け渡しの対象となったデータが信頼できる装置から送信されたデータであるのか否か、また、確かにセッション管理サーバ１００による制御の下で受け渡されたデータであるのか否かを検証する目的もある。また、ＨＧＷ１０が、受け渡されたデータについて、ＨＧＷ１０が把握しているどの呼に対応したデータであるかを把握する目的もある。
【０１６４】
また、図１４に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１０７においてデータを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『データ送信済』に、ステップＳ１０７におけるデータ送信の時刻情報（日時など）を格納する。
【０１６５】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１０８）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０１６６】
そして、データ受け渡し部１３ｂは、ステップＳ１０８においてｃａｌｌセッション情報の検証に成功すると、ステップＳ１０７において受信したデータを記憶部１２に格納する（ステップＳ１０９）。
【０１６７】
その後、データ受け渡し部１３ｂは、ステップＳ１０７とステップＳ１１０との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ１０７に対する応答として結果通知を行う（ステップＳ１１０）。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ１０７において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ１０７においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ１１０において当該乱数を送信してもよい。
【０１６８】
また、図１４に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１１０において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ１１０において受信した結果通知の時刻情報（日時など）を格納する。
【０１６９】
［方式１−２］
図１５を用いて方式１−２を説明する。図１５に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ２０１）。
【０１７０】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ２０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０１７１】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含め、データ保存元フラグとして『５』（契約サービスＩＤ指定）を含め、さらにサービスＩＤ『１００１』を含めることで、サービス提供サーバ２００が提供するサービス『１００１』に関連するデータを自ＨＧＷ１０に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０１７２】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ２０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０１７３】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０１７４】
また、図１５に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ２０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０１７５】
次に、受け渡し要求判定部１３３は、データ保存元フラグが『５』の場合であるので、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けられているｃａｌｌセッション情報および発着判定フラグからユーザ特定情報『０３１１１１１１１１』を取得する。次に、受け渡し要求判定部１３３は、取得したユーザ特定情報『０３１１１１１１１１』を用いてユーザ契約サービス管理テーブル１２１を参照し、ユーザ特定情報『０３１１１１１１１１』に対応付けられている契約サービスＩＤを確認する。すなわち、契約サービスＩＤとして『１００１』が対応付けられているか否かを確認する。そして、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤを格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００１』をデータ保存元情報に格納する。
【０１７６】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ２０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０１７７】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ２０４〜Ｓ２１４に示すデータ受け渡しを制御する。
【０１７８】
具体的には、データ受け渡し制御部１３４は、まず、アクセスキーを発行する（ステップＳ２０４）。データ受け渡し制御部１３４は、データ受け渡しテーブル１２５にて制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードに、発行したアクセスキーを格納する。ここで、アクセスキーとは、受け渡し要求を一意に特定するための識別情報であり、乱数や文字列などである。すなわち、アクセスキーは、ＨＧＷ１０からのデータダウンロード要求に対して、どのデータをダウンロードすればよいかを判定するために、リクエストとデータとの対応関係を管理するためのものである。また、アクセスキーは、セッション管理サーバ１００が許可したＨＧＷ１０からのアクセスであるか否かを判定するためにも利用される。例えば、データ受け渡し制御部１３４は、アクセスキーを発行する際に、ステップＳ２０２において受け渡し要求を送信してきた情報表示端末２０のＩＰアドレス（ＩＰｖ６であればプレフィックスなど）と発行したアクセスキーとを対応づけて記憶する。すると、後述するように、再びアクセスキーをＨＧＷ１０から受信した際に、アクセスキーとＩＰアドレスとの対応関係を判定し、ＩＰアドレスの一致をもって、通話中のＨＧＷ１０からのアクセスであるか否か（履歴情報に基づくデータ受け渡しの場合であれば、過去に通話したＨＧＷ１０からのアクセスであるか否か）を判定することができる。なお、ステップＳ２０２において受け渡し要求を送信する主体は情報表示端末２０であり、ステップＳ２０７においてアクセスキーを送信する主体はＨＧＷ１０であるが、ＨＧＷ１０でアドレス変換が行われることから、両者のＩＰアドレスは一致すると考えられる。
【０１７９】
次に、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、受け渡し先情報に格納されている受け渡し先フラグ『１』から、データの受け渡し先が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０１８０】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０１８１】
続いて、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ２０４において発行したアクセスキー及びｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ２０５）。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、受け渡しの対象となったデータが信頼できる装置から送信されたデータであるのか否か、また、確かにセッション管理サーバ１００による制御の下で受け渡されたデータであるのか否かを検証する目的もある。また、ＨＧＷ１０が、受け渡されたデータについて、ＨＧＷ１０が把握しているどの呼に対応したデータであるかを把握する目的もある。
【０１８２】
また、図１５に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ２０５においてアクセスキーを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『アクセスキー送信済』に、ステップＳ２０５におけるアクセスキー送信の時刻情報（日時など）を格納する。
【０１８３】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ２０６）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０１８４】
そして、データ受け渡し部１３ｂは、ステップＳ２０６においてｃａｌｌセッション情報の検証に成功すると、ステップＳ２０５において受信したアクセスキーをセッション管理サーバ１００に送信する（ステップＳ２０７）。
【０１８５】
一方、セッション管理サーバ１００のデータ受け渡し制御部１３４は、アクセスキーを検証する（ステップＳ２０８）。具体的には、データ受け渡し制御部１３４は、アクセスキーを用いてデータ受け渡しテーブル１２５を参照し、アクセスキーに対応付けて保持されているサービスＩＤ『１００１』を取得する。なお、上述したように、データ受け渡し制御部１３４が、ステップＳ２０４において情報表示端末２０のＩＰアドレスとアクセスキーとを対応づけて記憶している場合には、データ受け渡し制御部１３４は、アクセスキーを送信してきたＨＧＷ１０のＩＰアドレスとの一致関係をもって、通話中のＨＧＷ１０からのアクセスであるか否か（履歴情報に基づくデータ受け渡しの場合であれば、過去に通話したＨＧＷ１０からのアクセスであるか否か）を判定することができる。
【０１８６】
そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照する。そして、データ受け渡し制御部１３４は、契約サービスＩＤ『１００１』に対応付けて記憶されているサービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を含めたデータ取得要求をＵＲＬ『http://example1.co.jp』に対して送信する（ステップＳ２０９）。
【０１８７】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、データ取得要求に含められていた仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得する（ステップＳ２１０）。なお、サービスの内容によっては、例えば、データ受け渡し部２３３は、データ取得要求に含められていた発着間紐付けＩＤ『ｌｉｎ３３３３』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、発着間紐付けＩＤ『ｌｉｎ３３３３』に対応付けて記憶されている仮名ＩＤ『ｋａｍｅｉ３１１１』を取得し、さらに仮名ＩＤ『ｋａｍｅｉ３１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ３１１１』に対応付けて記憶されているデータを取得してもよい。
【０１８８】
そして、データ受け渡し部２３３は、セッション管理サーバ１００から送信されたデータ取得要求に対する応答として、ステップＳ２１０において取得したデータをセッション管理サーバ１００に対して送信する（ステップＳ２１１）。
【０１８９】
次に、データ受け渡し制御部１３４は、ステップＳ２０７においてアクセスキーを送信した送信元のＨＧＷ１０に対して、ステップＳ２１０において取得したデータを送信する（ステップＳ２１２）。なお、アクセスキーは、データ受け渡しテーブル１２５にて制御用セッション情報に対応付けて記憶されている。そこで、データ受け渡し制御部１３４は、アクセスキーを用いてデータ受け渡しテーブル１２５を参照することで制御用セッション情報を取得し、取得した制御用セッション情報を用いて制御用セッション管理テーブル１２３を参照することで、当該アクセスキーを送信した送信元のＨＧＷ１０のＵＲＬを取得することができる。
【０１９０】
また、図１５に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ２１２においてデータを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『データ送信済』に、ステップＳ２１２におけるデータ送信の時刻情報（日時など）を格納する。
【０１９１】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、データを記憶部１２に格納し（ステップＳ２１３）、その後、データ受け渡し部１３ｂは、ステップＳ２０５とステップＳ２１４との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ２０５に対する応答として結果通知を行う（ステップＳ２１４）。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ２０５において取得したｃａｌｌセッション情報やアクセスキーを送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ２０５やステップＳ２１２においてｃａｌｌセッション情報やデータとともに乱数が送信されていた場合などには、ステップＳ２１４において当該乱数を送信してもよい。
【０１９２】
また、図１５に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ２１４において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ２１４において受信した結果通知の時刻情報（日時など）を格納する。
【０１９３】
［方式１−２の効果］
上記したように、方式１−２によれば、方式１−１に比較して、宅内ネットワーク（ＨＧＷ１０以下のネットワーク）の負荷をより軽減することが可能になり、また、情報表示端末２０がデータをアップロードしなくて済むため能力が低い情報表示端末２０でも対応することが可能になる。すなわち、方式１−１では、データをＨＧＷ１０に受け渡す際に、セッション管理サーバ１００から情報表示端末２０にデータを渡し、その後、情報表示端末２０からＨＧＷ１０にデータを渡すため、データサイズが大きい場合、ＨＧＷ１０にデータを受け渡すまでに宅内ネットワークを２回経由することになり、トラフィックが増えてしまっていた。これに対し、方式１−２では、アクセスキーのみをＨＧＷ１０へ通知し、ＨＧＷ１０にデータをダウンロードする方式であるので、データの移動は、ＨＧＷ１０とセッション管理サーバ１００との間のみとなり、方式１−１に比較して宅内ネットワークのトラフィック量を軽減することが可能になる。また、情報表示端末２０がデータをアップロードしなくて済むため能力が低い情報表示端末２０でも対応することが可能になる。なお、方式１−１の効果はそのまま継承している。
【０１９４】
［方式１−３］
図１６を用いて方式１−３を説明する。図１６に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ３０１）。
【０１９５】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ３０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０１９６】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含め、データ保存元フラグとして『５』（契約サービスＩＤ指定）を含め、さらにサービスＩＤ『１００１』を含めることで、サービス提供サーバ２００が提供するサービス『１００１』に関連するデータを自ＨＧＷ１０に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０１９７】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ３０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０１９８】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０１９９】
また、図１６に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ３０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０２００】
次に、受け渡し要求判定部１３３は、データ保存元フラグが『５』の場合であるので、制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けられているｃａｌｌセッション情報および発着判定フラグからユーザ特定情報『０３１１１１１１１１』を取得する。次に、受け渡し要求判定部１３３は、取得したユーザ特定情報『０３１１１１１１１１』を用いてユーザ契約サービス管理テーブル１２１を参照し、ユーザ特定情報『０３１１１１１１１１』に対応付けられている契約サービスＩＤを確認する。すなわち、契約サービスＩＤとして『１００１』が対応付けられているか否かを確認する。そして、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤを格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００１』をデータ保存元情報に格納する。
【０２０１】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ３０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０２０２】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ３０４〜Ｓ３１４に示すデータ受け渡しを制御する。
【０２０３】
まず、データ受け渡し制御部１３４は、受け渡し要求に含められていたサービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照する。そして、データ受け渡し制御部１３４は、契約サービスＩＤ『１００１』に対応付けて記憶されているサービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、アクセスキー取得要求をＵＲＬ『http://example1.co.jp』に対して送信する（ステップＳ３０４）。
【０２０４】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、アクセスキーを発行する（ステップＳ３０５）。ここで、アクセスキーとは、受け渡し要求を一意に特定するための識別情報であり、乱数や文字列などである。
【０２０５】
そして、データ受け渡し部２３３は、セッション管理サーバ１００から送信されたアクセスキー取得要求に対する応答として、ステップＳ３０５において発行したアクセスキーをセッション管理サーバ１００に対して送信する（ステップＳ３０６）。
【０２０６】
続いて、データ受け渡し制御部１３４は、ステップＳ３０６において受信したアクセスキーを、データ受け渡しテーブル１２５にて制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードに格納する。また、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ３０６において受信したアクセスキー、サービス提供サーバ２００のＵＲＬおよびｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ３０７）。この時、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、ＨＧＷ１０のＵＲＬを取得している。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、受け渡しの対象となったデータが信頼できる装置から送信されたデータであるのか否か、また、確かにセッション管理サーバ１００による制御の下で受け渡されたデータであるのか否かを検証する目的もある。また、ＨＧＷ１０が、受け渡されたデータについて、ＨＧＷ１０が把握しているどの呼に対応したデータであるかを把握する目的もある。
【０２０７】
また、図１６に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ３０７においてアクセスキーを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『アクセスキー送信済』に、ステップＳ３０７におけるアクセスキー送信の時刻情報（日時など）を格納する。
【０２０８】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ３０８）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０２０９】
そして、データ受け渡し部１３ｂは、ステップＳ３０８においてｃａｌｌセッション情報の検証に成功すると、ステップＳ３０７において受信したアクセスキーを、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともにサービス提供サーバ２００に送信する（ステップＳ３０９）。
【０２１０】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、受信したアクセスキーを検証し（ステップＳ３１０）、アクセスキーとともに受信した仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得する（ステップＳ３１１）。なお、サービスの内容によっては、例えば、データ受け渡し部２３３は、データ取得要求に含められていた発着間紐付けＩＤ『ｌｉｎ３３３３』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、発着間紐付けＩＤ『ｌｉｎ３３３３』に対応付けて記憶されている仮名ＩＤ『ｋａｍｅｉ３１１１』を取得し、さらに仮名ＩＤ『ｋａｍｅｉ３１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ３１１１』に対応付けて記憶されているデータを取得してもよい。
【０２１１】
そして、データ受け渡し部２３３は、ＨＧＷ１０から送信されたアクセスキーに対する応答として、ステップＳ３１１において取得したデータをＨＧＷ１０に対して送信する（ステップＳ３１２）。
【０２１２】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、データを記憶部１２に格納し（ステップＳ３１３）、その後、データ受け渡し部１３ｂは、ステップＳ３０７とステップＳ３１４との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ３０７に対する応答として結果通知を行う（ステップＳ３１４）。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ３０７において取得したｃａｌｌセッション情報やアクセスキーを送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ３０７やステップＳ３１２においてｃａｌｌセッション情報やデータとともに乱数が送信されていた場合などには、ステップＳ３１４において当該乱数を送信してもよい。
【０２１３】
また、図１６に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ３１４において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ３１４において受信した結果通知の時刻情報（日時など）を格納する。
【０２１４】
［方式１−４］
図１７を用いて方式１−４を説明する。図１７に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ４０１）。
【０２１５】
すると、情報表示端末２０の受け渡し要求部２５ｂは、Ｗｅｂセッション情報を付与した受け渡し要求をサービス提供サーバ２００に送信する（ステップＳ４０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグを受け渡し要求に含める。
【０２１６】
例えば、受け渡し要求部２５ｂは、Ｗｅｂセッション情報『ａａａａａａａａａａ』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含めることで、サービス提供サーバ２００が提供するサービス『１００１』に関連するデータを自ＨＧＷ１０に受け渡すことを要求する。
【０２１７】
一方、サービス提供サーバ２００のデータ受け渡し部２３３は、アクセスキーを発行する（ステップＳ４０３）。ここで、アクセスキーとは、受け渡し要求を一意に特定するための識別情報であり、乱数や文字列などである。
【０２１８】
例えば、データ受け渡し部２３３は、Ｗｅｂセッション情報『ａａａａａａａａａａ』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、Ｗｅｂセッション情報『ａａａａａａａａａａ』に対応付けて記憶されている発着間紐付けＩＤ『ｌｉｎ３３３３』及び仮名ＩＤ『ｋａｍｅｉ１１１１』を取得する。そして、データ受け渡し部２３３は、アクセスキーをＷｅｂセッション情報管理テーブル２２１に保持する。
【０２１９】
次に、データ受け渡し部２３３は、ステップＳ４０２において受信した受け渡し要求を、ステップＳ４０３において発行したアクセスキーを添付して、セッション管理サーバ１００に対してリダイレクトで転送する（ステップＳ４０４）。なお、データ受け渡し部２３３は、転送する受け渡し要求には、既に含められていた受け渡し先フラグに加え、データ保存元フラグ『５』やサービスＩＤ『１００１』、および仮名ＩＤを含めて転送する。また、ステップＳ４０４の受け渡し要求の転送は、リダイレクト方式でなく、ＨＴＴＰ通信により直接転送する方式でもよい。
【０２２０】
また、図１７に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ４０４において受け渡し要求の転送を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された仮名ＩＤ『ｋａｍｅｉ１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されている制御用セッション情報『１１１１１１１１１１』を取得する。また、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０２２１】
次に、受け渡し要求判定部１３３は、データ保存元フラグが『５』の場合であるので、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けられているｃａｌｌセッション情報および発着判定フラグからユーザ特定情報『０３１１１１１１１１』を取得する。次に、受け渡し要求判定部１３３は、取得したユーザ特定情報『０３１１１１１１１１』を用いてユーザ契約サービス管理テーブル１２１を参照し、ユーザ特定情報『０３１１１１１１１１』に対応付けられている契約サービスＩＤを確認する。すなわち、契約サービスＩＤとして『１００１』が対応付けられているか否かを確認する。そして、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤを格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００１』をデータ保存元情報に格納する。
【０２２２】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ４０４において受け付けた受け渡し要求の転送に関する時刻情報（受け渡し要求の転送を受信した日時など）を格納する。
【０２２３】
そして、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ４０５）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０２２４】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０２２５】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ４０６〜Ｓ４１３に示すデータ受け渡しを制御する。
【０２２６】
まず、データ受け渡し制御部１３４は、ステップＳ４０４において受信したアクセスキーを、データ受け渡しテーブル１２５にて制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードに格納する。また、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ４０４において受信したアクセスキー、サービス提供サーバ２００のＵＲＬおよびｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ４０６）。この時、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、ＨＧＷ１０のＵＲＬを取得している。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、受け渡しの対象となったデータが信頼できる装置から送信されたデータであるのか否か、また、確かにセッション管理サーバ１００による制御の下で受け渡されたデータであるのか否かを検証する目的もある。また、ＨＧＷ１０が、受け渡されたデータについて、ＨＧＷ１０が把握しているどの呼に対応したデータであるかを把握する目的もある。
【０２２７】
また、図１７に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ４０６においてアクセスキーを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『アクセスキー送信済』に、ステップＳ４０６におけるアクセスキー送信の時刻情報（日時など）を格納する。
【０２２８】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ４０７）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０２２９】
そして、データ受け渡し部１３ｂは、ステップＳ４０７においてｃａｌｌセッション情報の検証に成功すると、ステップＳ４０６において受信したアクセスキーを、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともにサービス提供サーバ２００に送信する（ステップＳ４０８）。
【０２３０】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、受信したアクセスキーを検証し（ステップＳ４０９）、アクセスキーとともに受信した仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得する（ステップＳ４１０）。なお、サービスの内容によっては、例えば、データ受け渡し部２３３は、データ取得要求に含められていた発着間紐付けＩＤ『ｌｉｎ３３３３』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、発着間紐付けＩＤ『ｌｉｎ３３３３』に対応付けて記憶されている仮名ＩＤ『ｋａｍｅｉ３１１１』を取得し、さらに仮名ＩＤ『ｋａｍｅｉ３１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ３１１１』に対応付けて記憶されているデータを取得してもよい。
【０２３１】
そして、データ受け渡し部２３３は、ＨＧＷ１０から送信されたアクセスキーに対する応答として、ステップＳ４１０において取得したデータをＨＧＷ１０に対して送信する（ステップＳ４１１）。
【０２３２】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、データを記憶部１２に格納し（ステップＳ４１２）、その後、データ受け渡し部１３ｂは、ステップＳ４０６とステップＳ４１３との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ４０６に対する応答として結果通知を行う（ステップＳ４１３）。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ４０６おいて取得したｃａｌｌセッション情報やアクセスキーを送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ４０６やステップＳ４１１においてｃａｌｌセッション情報やデータとともに乱数が送信されていた場合などには、ステップＳ４１３において当該乱数を送信してもよい。
【０２３３】
また、図１７に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ４１３において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ４１３において受信した結果通知の時刻情報（日時など）を格納する。
【０２３４】
［方式１−５］
図１８を用いて方式１−５を説明する。図１８に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ５０１）。
【０２３５】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ５０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。ここで、データの受け渡しについて説明すると、受け渡しの対象となるデータとしては、例えば、受け渡し要求の要求元が開示権を有するデータが受け渡しの対象となる場合や、要求元の通話相手が開示権を有するデータが受け渡しの対象となる場合、あるいはサービス提供サーバが開示権を有するデータが受け渡しの対象となる場合などがある。
【０２３６】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含め、データ保存元フラグとして『５』（契約サービスＩＤ指定）を含め、さらにサービスＩＤ『１００１』を含めることで、サービス提供サーバ２００が提供するサービス『１００１』に関連するデータを自ＨＧＷ１０に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０２３７】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ５０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０２３８】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０２３９】
また、図１８に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ５０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０２４０】
次に、受け渡し要求判定部１３３は、データ保存元フラグが『５』の場合であるので、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けられているｃａｌｌセッション情報および発着判定フラグからユーザ特定情報『０３１１１１１１１１』を取得する。次に、受け渡し要求判定部１３３は、取得したユーザ特定情報『０３１１１１１１１１』を用いてユーザ契約サービス管理テーブル１２１を参照し、ユーザ特定情報『０３１１１１１１１１』に対応付けられている契約サービスＩＤを確認する。すなわち、契約サービスＩＤとして『１００１』が対応付けられているか否かを確認する。そして、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤを格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００１』をデータ保存元情報に格納する。
【０２４１】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ５０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０２４２】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ５０４以降に示すデータ受け渡しを制御する。
【０２４３】
具体的には、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、受け渡し先情報に格納されている受け渡し先フラグ『１』から、データの受け渡し先が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０２４４】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０２４５】
続いて、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、公開鍵を送信することを要求する公開鍵要求及びｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ５０４）。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、以下に説明するように、ＨＧＷ１０が、受け渡しの対象となったデータが信頼できる装置から送信されたデータであるのか否か、また、確かにセッション管理サーバ１００による制御の下で受け渡されたデータであるのか否かを検証する目的もある。また、ＨＧＷ１０が、受け渡されたデータについて、ＨＧＷ１０が把握しているどの呼に対応したデータであるかを把握する目的もある。
【０２４６】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ５０５）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０２４７】
そして、ＨＧＷ１０のデータ受け渡し部１３ｂは、記憶部に記憶している公開鍵及び秘密鍵を取得する（ステップＳ５０６）。なお、公開鍵及び秘密鍵をその都度生成してもよい。
【０２４８】
そして、データ受け渡し部１３ｂは、ステップＳ５０６において取得した公開鍵を、セッション管理サーバ１００に対してリダイレクトで送信する（ステップＳ５０７）。この時、データ受け渡し部１３ｂは、ステップＳ５０４とステップＳ５０７との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信する。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ５０４において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ５０４においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ５０７において当該乱数を送信してもよい。
【０２４９】
すると、セッション管理サーバ１００のデータ受け渡し制御部１３４は、ステップＳ５０７において受信したｃａｌｌセッション情報を用いてデータ受け渡しテーブル１２５を参照し、当該ｃａｌｌセッション情報に対応づけて記憶されているデータ保存元情報（データ保存元フラグ『５』及びサービスＩＤ『１００１』）を取得する（ステップＳ５０８）。また、データ受け渡し制御部１３４は、データ保存元フラグ『５』及びサービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照する。そして、データ受け渡し制御部１３４は、契約サービスＩＤ『１００１』に対応付けて記憶されているサービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、公開鍵、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を含めたデータ取得要求をＵＲＬ『http://example1.co.jp』に対して送信する（ステップＳ５０９）。
【０２５０】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、データ取得要求に含められていた仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得する（ステップＳ５１０）。なお、サービスの内容によっては、例えば、データ受け渡し部２３３は、データ取得要求に含められていた発着間紐付けＩＤ『ｌｉｎ３３３３』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、発着間紐付けＩＤ『ｌｉｎ３３３３』に対応付けて記憶されている仮名ＩＤ『ｋａｍｅｉ３１１１』を取得し、さらに仮名ＩＤ『ｋａｍｅｉ３１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ３１１１』に対応付けて記憶されているデータを取得してもよい。
【０２５１】
そして、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ５０９において受信した公開鍵でデータを暗号化する（ステップＳ５１１）。
【０２５２】
なお、以降の処理手順については、方式１−１のステップＳ１０７以降、もしくは方式１−２のステップＳ２１２以降、方式１−３のステップＳ３０５以降のいずれを組み合わせてもよい。この時、データは暗号化されているので、方式１−２や方式１−２の処理手順において、復号化の処理を行うことになる。例えば、方式１−１であれば、ステップＳ１０９においてデータを格納する前に、ＨＧＷ１０は、ステップＳ５０６において取得した秘密鍵を用いて、暗号化されたデータを復号化し、復号化したデータを格納する。また、例えば、方式１−２であれば、ステップＳ２１３においてデータを格納する前に、ＨＧＷ１０は、ステップＳ５０６において取得した秘密鍵を用いて、暗号化されたデータを復号化し、復号化したデータを格納する。また、例えば、方式１−３であれば、ステップＳ３１３においてデータを格納する前に、ＨＧＷ１０は、ステップＳ５０６において取得した秘密鍵を用いて、暗号化されたデータを復号化し、復号化したデータを格納する。
【０２５３】
［方式２］
方式２は、上記したように、現に通話中の利用者であるとの判定に基づいてセッション管理サーバ１００が制御することで、ＨＧＷ１０からサービス提供サーバ２００へとデータを受け渡す方式である。方式２には、図１９〜２３に示すように、例えば方式２−１〜２−５の種類がある。各方式の相違点を簡単に説明すると、まず、方式２−１〜方式２−３及び方式２−５は、データの受け渡しを要求する受け渡し要求がセッション管理サーバ１００に対して送信される方式であるのに対し、方式２−４は、受け渡し要求がサービス提供サーバ２００に対して送信される方式である。このため、実施例１におけるサービス提供システムは、受け渡し要求がセッション管理サーバ１００に対して送信される場合にもサービス提供サーバ２００に対して送信される場合にも、現に通話中の利用者であるとの判定に基づいて、ＨＧＷ１０からサービス提供サーバ２００へとデータを受け渡すことができる。
【０２５４】
また、方式２−１〜方式２−３及び方式２−５の各方式の相違点としては、方式２−１及び方式２−２は、セッション管理サーバ１００が、受け渡しの対象となるデータを直接送受信する方式（一度は取得する方式）であるのに対し、方式２−３及び方式２−５は、セッション管理サーバ１００が、データの受け渡しを制御するものの、受け渡しの対象となるデータを直接送受信しない方式である。このため、例えば秘匿性の高いデータを受け渡しの対象とする場合などに方式２−３や方式２−５を採用することで、データがセッション管理サーバ１００に取得されることがなくなり、方式２−１や方式２−２に比較して、セキュリティをより向上することが可能になる。
【０２５５】
また、方式２−１と方式２−２との相違点としては、後述するように、方式２−２を採用することで、方式２−１に比較して、宅内ネットワーク（ＨＧＷ１０以下のネットワーク）の負荷をより軽減することが可能になる。また、方式２−３と方式２−５との相違点としては、方式２−５によれば、ＨＧＷ１０からサービス提供サーバ２００に対して送信されるデータは暗号化されるので、ＨＧＷ１０からサービス提供サーバ２００に対するデータの受け渡しを確実なものとすることが可能になる。すなわち、サービス提供サーバ２００は、セッション管理サーバ１００に問い合わせを行わなければ、暗号化されたデータを復号するための鍵を入手することができない。また、鍵の送信をセッション管理サーバ１００が行うので、ＨＧＷ１０がサービス提供サーバ２００に対して確実にデータを送信したことを証明する送達証明の役割を果たす。
【０２５６】
［方式２−１］
図１９を用いて方式２−１を説明する。図１９に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ６０１）。
【０２５７】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ６０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０２５８】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『４』（利用中サービス）を含め、データ保存元フラグとして『１』（自ＨＧＷ）を含めることで、発信側のＨＧＷ１０が記憶するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０２５９】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ６０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０２６０】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０２６１】
また、図１９に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ６０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０２６２】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『１』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０２６３】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ６０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０２６４】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ６０４〜Ｓ６１５に示すデータ受け渡しを制御する。
【０２６５】
具体的には、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、データ保存元情報に格納されているデータ保存元フラグ『１』から、データの保存元が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０２６６】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０２６７】
続いて、データ受け渡し制御部１３４は、ＨＧＷ１０に対して、データ送信要求を送信する（ステップＳ６０４）。具体的には、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行い、このリダイレクト指示の際には、データ送信要求であることを示すリクエストも送信する。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０２６８】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ６０５）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０２６９】
そして、データ受け渡し部１３ｂは、ステップＳ６０５においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ６０６)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ６０７）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ６０８）。
【０２７０】
ここで、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ６０９）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ６１０）。
【０２７１】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ６０９において受信した選択情報にて指定されるデータを記憶部から取得し（ステップＳ６１１）、取得したデータを、セッション管理サーバ１００に対してリダイレクトで送信する（ステップＳ６１２）。この時、データ受け渡し部１３ｂは、ステップＳ６０４とＳ６１２との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信する。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ６０４において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ６０４においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ６１２において当該乱数を送信してもよい。
【０２７２】
すると、セッション管理サーバ１００のデータ受け渡し制御部１３４は、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてデータ受け渡しテーブル１２５を参照し、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』に対応付けて記憶されている受け渡し先フラグ『４』を取得する。次に、データ受け渡し制御部１３４は、受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、データ受け渡しテーブル１２５にてｃａｌｌセッション情報『ｕｉ１２３４５６７８９』に対応付けて記憶されている制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.com』を検索し、ＵＲＬ『http://example1.com』にデータを送信する（ステップＳ６１３）。なお、実施例１におけるデータ受け渡し制御部１３４は、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともにデータを送信する。
【０２７３】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ６１３において受信したデータを、ステップＳ６１３において受信した仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けてデータテーブル２２２に格納する（ステップＳ６１４）。
【０２７４】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップ６１３とステップＳ６１５との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ６１３に対する応答として結果通知を行う（ステップＳ６１５）。例えば、データ受け渡し部２３３は、ステップＳ６１３において取得した仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を送信したりする。あるいは、ステップＳ６１３においてデータとともに乱数が送信されていた場合などには、ステップＳ６１５において当該乱数を送信してもよい。
【０２７５】
また、図１９に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ６１５において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ６１５において受信した結果通知の時刻情報（日時など）を格納する。
【０２７６】
［方式２−２］
図２０を用いて方式２−２を説明する。図２０に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ７０１）。
【０２７７】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ７０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０２７８】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『４』（利用中サービス）を含め、データ保存元フラグとして『１』（自ＨＧＷ）を含めることで、発信側のＨＧＷ１０が記憶するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０２７９】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ７０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０２８０】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０２８１】
また、図２０に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ７０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０２８２】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『１』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０２８３】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ７０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０２８４】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ７０４〜Ｓ７１５に示すデータ受け渡しを制御する。
【０２８５】
具体的には、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、データ保存元情報に格納されているデータ保存元フラグ『１』から、データの保存元が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０２８６】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０２８７】
続いて、データ受け渡し制御部１３４は、ＨＧＷ１０に対して、データ送信要求を送信する（ステップＳ７０４）。具体的には、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行い、このリダイレクト指示の際には、データ送信要求であることを示すリクエストも送信する。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０２８８】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ７０５）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０２８９】
そして、データ受け渡し部１３ｂは、ステップＳ７０５においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ７０６)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ７０７）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ７０８）。
【０２９０】
ここで、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ７０９）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ７１０）。
【０２９１】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ７０９において受信した選択情報にて指定されるデータを記憶部から取得し（ステップＳ７１１）、取得したデータをセッション管理サーバ１００に対して送信する（ステップＳ７１２）。この時、データ受け渡し部１３ｂは、ステップＳ７０４とＳ７１２との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信する。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ７０４において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ７０４においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ７１２において当該乱数を送信してもよい。
【０２９２】
すると、セッション管理サーバ１００のデータ受け渡し制御部１３４は、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてデータ受け渡しテーブル１２５を参照し、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』に対応付けて記憶されている受け渡し先フラグ『４』を取得する。次に、データ受け渡し制御部１３４は、受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、データ受け渡しテーブル１２５にてｃａｌｌセッション情報『ｕｉ１２３４５６７８９』に対応付けて記憶されている制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、ＵＲＬ『http://example1.co.jp』にデータを送信する（ステップＳ７１３）。なお、実施例１におけるデータ受け渡し制御部１３４は、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともにデータを送信する。
【０２９３】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ７１３において受信したデータを、ステップＳ７１３において受信した仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けてデータテーブル２２２に格納する（ステップＳ７１４）。
【０２９４】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップ７１３とステップＳ７１５との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ７１３に対する応答として結果通知を行う（ステップＳ７１５）。例えば、データ受け渡し部２３３は、ステップＳ７１３において取得した仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を送信したりする。あるいは、ステップＳ７１３においてデータとともに乱数が送信されていた場合などには、ステップＳ７１５において当該乱数を送信してもよい。
【０２９５】
また、図２０に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ７１５において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ７１５において受信した結果通知の時刻情報（日時など）を格納する。
【０２９６】
［方式２−３］
図２１を用いて方式２−３を説明する。図２１に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ８０１）。
【０２９７】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ８０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０２９８】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『４』（利用中サービス）を含め、データ保存元フラグとして『１』（自ＨＧＷ）を含めることで、発信側のＨＧＷ１０が記憶するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０２９９】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ８０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０３００】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０３０１】
また、図２１に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ８０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０３０２】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『１』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０３０３】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ８０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０３０４】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ８０４〜Ｓ８１８に示すデータ受け渡しを制御する。
【０３０５】
具体的には、データ受け渡し制御部１３４は、まず、キー情報を発行する（ステップＳ８０４）。ここで、キー情報とは、データの送信先の正当性を検証するための情報であり、乱数や文字列などである。すなわち、セッション管理サーバ１００が、正しいデータの送信先を保証するための情報である（通話中で現在利用中の利用者のうち、どの送信先に対応したデータであるのかを、セッション管理サーバ１００が通知し、保証するためのＩＤ）。このようなキー情報を用いることで、利用者も、電話番号等を送信先に通知しなくても、セッションに関する情報ベースで、データを確実に受け渡すことが可能となる。また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５にて制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードに、発行したキー情報を格納する。
【０３０６】
次に、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、データ保存元情報に格納されているデータ保存元フラグ『１』から、データの保存元が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０３０７】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０３０８】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、受け渡し先情報に格納されている受け渡し先フラグ『４』を取得する。受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.co.jp』を取得する。
【０３０９】
続いて、データ受け渡し制御部１３４は、ＨＧＷ１０に対して、データ送信要求を送信する（ステップＳ８０５）。具体的には、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ８０４において発行したキー情報、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』、及びサービス提供サーバのＵＲＬ『http://example1.co.jp』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行い、このリダイレクト指示の際には、データ送信要求であることを示すリクエストも送信する。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０３１０】
また、図２１に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ８０５においてキー情報を送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『キー情報送信済』に、ステップＳ８０５におけるキー情報送信の時刻情報（日時など）を格納する。
【０３１１】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ８０６）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０３１２】
そして、データ受け渡し部１３ｂは、ステップＳ８０６においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ８０７)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ８０８）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ８０９）。
【０３１３】
ここで、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ８１０）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ８１１）。
【０３１４】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ８１１において受信した選択情報にて指定されるデータを記憶部から取得し（ステップＳ８１２）、取得したデータを、ステップＳ８０５において受信したキー情報とともに、ステップＳ８０５において受信したサービス提供サーバ２００のＵＲＬに対して送信する（ステップＳ８１３）。
【０３１５】
すると、サービス提供サーバ２００のデータ受け渡し制御部１３４は、ステップＳ８１３において受信したキー情報の検証をセッション管理サーバ１００に対して依頼する（ステップＳ８１４）。
【０３１６】
一方、セッション管理サーバ１００のデータ受け渡し制御部１３４は、ステップＳ８１４において受信したキー情報を用いてデータ受け渡しテーブル１２５を参照し、ステップＳ８１４において受信したキー情報が記憶されていることを確認することで、自らが発行したキー情報であることを検証する（ステップＳ８１５）。
【０３１７】
そして、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５にてキー情報に対応付けて記憶されているデータ保存元情報の仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を取得し、取得した仮名ＩＤおよび発着間紐付けＩＤをサービス提供サーバ２００に送信する（ステップＳ８１６）。
【０３１８】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ８１３において受信したデータを、ステップＳ８１６において受信した仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けてデータテーブル２２２に格納する（ステップＳ８１７）。
【０３１９】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップ８１６とステップＳ８１８との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ８１６に対する応答として結果通知を行う（ステップＳ８１８）。例えば、データ受け渡し部２３３は、ステップＳ８１６において取得した仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を送信したりする。あるいは、ステップＳ８１６において乱数が送信されていた場合などには、ステップＳ８１８において当該乱数を送信してもよい。
【０３２０】
また、図２１に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ８１８において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ８１８において受信した結果通知の時刻情報（日時など）を格納する。
【０３２１】
［方式２−４］
図２２を用いて方式２−４を説明する。図２２に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ９０１）。
【０３２２】
すると、情報表示端末２０の受け渡し要求部２５ｂは、Ｗｅｂセッション情報を付与した受け渡し要求をサービス提供サーバ２００に送信する（ステップＳ９０２）。また、この時、受け渡し要求部２５ｂは、データ保存元フラグを受け渡し要求に含める。
【０３２３】
例えば、受け渡し要求部２５ｂは、Ｗｅｂセッション情報『ａａａａａａａａａａ』を付与した受け渡し要求に、データ保存元フラグとして『１』（自ＨＧＷ）を含めることで、発信側のＨＧＷ１０が記憶するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。
【０３２４】
一方、サービス提供サーバ２００のデータ受け渡し部２３３は、アクセスキーを発行する（ステップＳ９０３）。ここで、アクセスキーとは、受け渡し要求を一意に特定するための識別情報であり、乱数や文字列などである。
【０３２５】
例えば、データ受け渡し部２３３は、Ｗｅｂセッション情報『ａａａａａａａａａａ』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、Ｗｅｂセッション情報『ａａａａａａａａａａ』に対応付けて記憶されている発着間紐付けＩＤ『ｌｉｎ３３３３』及び仮名ＩＤ『ｋａｍｅｉ１１１１』を取得する。そして、データ受け渡し部２３３は、アクセスキーを記憶部２２０に保持する。
【０３２６】
次に、データ受け渡し部２３３は、ステップＳ９０２において受信した受け渡し要求を、ステップＳ９０３において発行したアクセスキーを添付して、セッション管理サーバ１００に対してリダイレクトで転送する（ステップＳ９０４）。なお、データ受け渡し部２３３は、転送する受け渡し要求には、既に含められていたデータ保存元フラグに加え、受け渡し先フラグ『１』や仮名ＩＤを含めて転送する。
【０３２７】
また、図２２に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ９０４において受け渡し要求の転送を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された仮名ＩＤ『ｋａｍｅｉ１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されている制御用セッション情報『１１１１１１１１１１』を取得する。また、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０３２８】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『１』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０３２９】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ９０４において受け付けた受け渡し要求の転送に関する時刻情報（受け渡し要求の転送を受信した日時など）を格納する。
【０３３０】
そして、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ９０５）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０３３１】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０３３２】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ９０６〜Ｓ９１７に示すデータ受け渡しを制御する。
【０３３３】
具体的には、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、データ保存元情報に格納されているデータ保存元フラグ『１』から、データの保存元が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０３３４】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０３３５】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、受け渡し先情報に格納されている受け渡し先フラグ『４』を取得する。受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.co.jp』を取得する。
【０３３６】
続いて、データ受け渡し制御部１３４は、ＨＧＷ１０に対して、データ送信要求を送信する（ステップＳ９０６）。具体的には、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ９０４において受信したアクセスキー、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』、及びサービス提供サーバのＵＲＬ『http://example1.co.jp』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示行い、このリダイレクト指示の際には、データ送信要求であることを示すリクエストも送信する。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０３３７】
また、図２２に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ９０６においてアクセスキーを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『アクセスキー送信済』に、ステップＳ９０６におけるアクセスキー送信の時刻情報（日時など）を格納する。
【０３３８】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ９０７）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０３３９】
そして、データ受け渡し部１３ｂは、ステップＳ９０７においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ９０８)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ９０９）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ９１０）。
【０３４０】
ここで、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ９１１）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ９１２）。
【０３４１】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ９１２において受信した選択情報にて指定されるデータを記憶部から取得し（ステップＳ９１３）、取得したデータを、ステップＳ９０６において受信したアクセスキーとともに、ステップＳ９０６において受信したサービス提供サーバ２００のＵＲＬに対して送信する（ステップＳ９１４）。
【０３４２】
すると、サービス提供サーバ２００のデータ受け渡し制御部１３４は、ステップＳ９１４において受信したアクセスキーを検証し（ステップＳ９１５）、検証に成功すると、仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けて、ステップＳ９１４において受信したデータをデータテーブル２２２に格納する（ステップＳ９１６）。
【０３４３】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、結果通知を行う（ステップＳ９１７）。例えば、データ受け渡し部２３３は、仮名ＩＤ『ｋａｍｅｉ１１１１』を送信したりする。
【０３４４】
また、図２２に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ９１７において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ９１７において受信した結果通知の時刻情報（日時など）を格納する。
【０３４５】
［方式２−５］
図２３を用いて方式２−５を説明する。図２３に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ１００１）。
【０３４６】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ１００２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０３４７】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『４』（利用中サービス）を含め、データ保存元フラグとして『１』（自ＨＧＷ）を含めることで、発信側のＨＧＷ１０が記憶するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０３４８】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ１００３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０３４９】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０３５０】
また、図２３に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１００２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０３５１】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『１』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０３５２】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ１００２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０３５３】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ１００４〜Ｓ１０２０に示すデータ受け渡しを制御する。
【０３５４】
具体的には、データ受け渡し制御部１３４は、まず、キー情報を発行する（ステップＳ１００４）。ここで、キー情報とは、発信側の正当性を検証するための情報であり、乱数や文字列などである。また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５にて制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードに、発行したキー情報を格納する。また、データ受け渡し制御部１３４は、暗号化復号のための鍵を生成する（ステップＳ１００５）。
【０３５５】
次に、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、データ保存元情報に格納されているデータ保存元フラグ『１』から、データの保存元が情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/returm』を取得する。
【０３５６】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報としてＣａｌｌ−ＩＤ『ｕｉ１２３４５６７８９』を取得する。
【０３５７】
また、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５を参照し、受け渡し先情報に格納されている受け渡し先フラグ『４』を取得する。受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.co.jp』を取得する。
【０３５８】
続いて、データ受け渡し制御部１３４は、ＨＧＷ１０に対して、データ送信要求を送信する（ステップＳ１００６）。具体的には、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ１００４において発行したキー情報、ステップＳ１００５において生成した鍵、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』、及びサービス提供サーバのＵＲＬ『http://example1.co.jp』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行い、このリダイレクト指示の際には、データ送信要求であることを示すリクエストも送信する。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０３５９】
また、図２３に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１００６においてキー情報を送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『キー情報送信済』に、ステップＳ１００６におけるキー情報送信の時刻情報（日時など）を格納する。
【０３６０】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１００７）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０３６１】
そして、データ受け渡し部１３ｂは、ステップＳ１００７においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ１００８)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ１００９）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ１０１０）。
【０３６２】
ここで、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ１０１１）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ１０１２）。
【０３６３】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ１０１２において受信した選択情報にて指定されるデータを記憶部から取得し、取得したデータを、ステップＳ１００６において受信した鍵（暗号化のための鍵）で暗号化する（ステップＳ１０１３）。
【０３６４】
そして、データ受け渡し部１３ｂは、暗号化したデータを、ステップＳ１００６において受信したキー情報とともに、ステップＳ１００６において受信したサービス提供サーバ２００のＵＲＬに対して送信する（ステップＳ１０１４）。
【０３６５】
すると、サービス提供サーバ２００のデータ受け渡し制御部１３４は、ステップＳ１０１４において受信したキー情報の検証をセッション管理サーバ１００に対して依頼する（ステップＳ１０１５）。
【０３６６】
一方、セッション管理サーバ１００のデータ受け渡し制御部１３４は、ステップＳ１０１５において受信したキー情報を用いてデータ受け渡しテーブル１２５を参照し、ステップＳ１０１５において受信したキー情報が記憶されていることを確認することで、自らが発行したキー情報であることを検証する（ステップＳ１０１６）。
【０３６７】
そして、データ受け渡し制御部１３４は、データ受け渡しテーブル１２５にてキー情報に対応付けて記憶されているデータ保存元情報の仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を取得し、取得した仮名ＩＤおよび発着間紐付けＩＤと、ステップＳ１００５において生成した鍵（復号のための鍵）をサービス提供サーバ２００に送信する（ステップＳ１０１７）。
【０３６８】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ１０１４において受信したデータを、ステップＳ１０１７において受信した鍵で復号し（ステップＳ１０１８）、ステップＳ１０１７において受信した仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けてデータテーブル２２２に格納する（ステップＳ１０１９）。
【０３６９】
また、図２３に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１０１７において鍵を送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『データ送信済』に、ステップＳ１０１７において鍵を送信した時刻情報（日時など）を格納する。
【０３７０】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップ１０１７とステップＳ１０２０との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ１０１７に対する応答として結果通知を行う（ステップＳ１０２０）。例えば、データ受け渡し部２３３は、ステップＳ１０１７において取得した仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を送信したりする。あるいは、ステップＳ１０１７において乱数が送信されていた場合などには、ステップＳ１０２０において当該乱数を送信してもよい。
【０３７１】
また、図２３に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１０２０において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ１０２０において受信した結果通知の時刻情報（日時など）を格納する。
【０３７２】
［方式３］
方式３は、現に通話中の利用者であるとの判定に基づいてセッション管理サーバ１００が制御することで、サービス提供サーバ２００からサービス提供サーバ２００へとデータを受け渡す方式である。方式３には、図２４〜２５に示すように、例えば方式３−１及び３−２の種類がある。各方式の相違点を簡単に説明すると、まず、方式３−１は、データを暗号化せずに受け渡しを行う方式であるのに対し、方式３−２は、データを暗号化してから受け渡す方式である。このため、方式３−２は、例えば秘匿性の高いデータを受け渡しの対象とする場合などに適用することができる。すなわち、方式３−１は、上記したように、セッション管理サーバ１００が、受け渡しの対象となるデータを直接送受信する方式であるが、方式３−２は、データを暗号化してから受け渡すので、セッション管理サーバ１００は、データを復号できなければ実質的にデータを取得することにはならず、セキュリティをより向上することが可能になるのである。すなわち、方式３−２によれば、受け渡しの対象となるデータは暗号化されているので、セッション管理サーバ１００は、受け渡しの対象となるデータの内容を把握することが不可能である。言い換えると、セッション管理サーバ１００は、例えばデータが個人情報であれば、個人情報を管理する難しさを回避することができ、データを管理するリスクを低減することができることになる。また一方で、セッション管理サーバ１００は、暗号化されたデータについて第三者として検証を行うことができる。すなわち、例えば、後日サービス提供サーバＡとサービス提供サーバＢとの間でデータの受け渡しに関する紛争（データを渡した、渡さないといった紛争など）が起きた場合に、セッション管理サーバ１００は、鍵情報を提供されれば証拠のデータを復元させることができ、第三者として検証を行うことができる。
【０３７３】
［方式３−１］
図２４を用いて方式３−１を説明する。図２４に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ１１０１）。
【０３７４】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ１１０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０３７５】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『４』（利用中サービス）を含め、データ保存元フラグとして『５』（契約サービスＩＤ指定）を含め、さらにサービスＩＤ『１００２』を含めることで、サービス提供サーバ２００が提供するサービス『１００２』に関連するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０３７６】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ１１０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０３７７】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０３７８】
また、図２４に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１１０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０３７９】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００２』をデータ保存元情報に格納する。
【０３８０】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ１１０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０３８１】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ１１０４〜Ｓ１１０９に示すデータ受け渡しを制御する。
【０３８２】
まず、データ受け渡し制御部１３４は、受け渡しの対象となるデータを取得する。具体的には、データ受け渡し制御部１３４は、受け渡し要求に含められていたサービスＩＤ『１００２』を用いて契約サービス情報テーブル１２２を参照する。そして、データ受け渡し制御部１３４は、契約サービスＩＤ『１００２』に対応付けて記憶されているサービス提供サーバのＵＲＬ『http://example2.co.jp』を検索し、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を含めたデータ取得要求をＵＲＬ『http://example2.co.jp』に対して送信する（ステップＳ１１０４）。
【０３８３】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、データ取得要求に含められていた仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得する（ステップＳ１１０５）。なお、サービスの内容によっては、例えば、データ受け渡し部２３３は、データ取得要求に含められていた発着間紐付けＩＤ『ｌｉｎ３３３３』を用いてＷｅｂセッション情報管理テーブル２２１を参照し、発着間紐付けＩＤ『ｌｉｎ３３３３』に対応付けて記憶されている仮名ＩＤ『ｋａｍｅｉ３１１１』を取得し、さらに仮名ＩＤ『ｋａｍｅｉ３１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ３１１１』に対応付けて記憶されているデータを取得してもよい。
【０３８４】
そして、データ受け渡し部２３３は、セッション管理サーバ１００から送信されたデータ取得要求に対する応答として、ステップＳ１１０５において取得したデータをセッション管理サーバ１００に対して送信する（ステップＳ１１０６）。
【０３８５】
すると、セッション管理サーバ１００のデータ受け渡し制御部１３４は、受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、ＵＲＬ『http://example1.co.jp』にデータを送信する（ステップＳ１１０７）。なお、実施例１におけるデータ受け渡し制御部１３４は、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともにデータを送信する。
【０３８６】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ１１０７において受信したデータを、ステップＳ１１０７において受信した仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けてデータテーブル２２２に格納する（ステップＳ１１０８）。
【０３８７】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップ１１０７とステップＳ１１０９との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ１１０７に対する応答として結果通知を行う（ステップＳ１１０９）。例えば、データ受け渡し部２３３は、ステップＳ１１０７において取得した仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を送信したりする。あるいは、ステップＳ１１０７においてデータとともに乱数が送信されていた場合などには、ステップＳ１１０９において当該乱数を送信してもよい。
【０３８８】
また、図２４に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１１０９において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ１１０９において受信した結果通知の時刻情報（日時など）を格納する。
【０３８９】
［方式３−２］
図２５を用いて方式３−２を説明する。なお、図２５に示す例では、自分自身が現在利用中のサービス提供サーバ２００に対してデータを受け渡す事例を説明するが、これに限られるものではなく、通話相手が現在利用中のサービス提供サーバ２００に対してデータを受け渡す事例にも同様に適用することができる。図２５に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ１２０１）。
【０３９０】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ１２０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０３９１】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『４』（利用中サービス）を含め、データ保存元フラグとして『５』（契約サービスＩＤ指定）を含め、さらにサービスＩＤ『１００２』を含めることで、サービス提供サーバ２００が提供するサービス『１００２』に関連するデータを利用中のサービス提供サーバ２００に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０３９２】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ１２０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０３９３】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０３９４】
また、図２５に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１２０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０３９５】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『４』を受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『５』、サービスＩＤ『１００２』をデータ保存元情報に格納する。
【０３９６】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ１２０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０３９７】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ１２０４〜Ｓ１２１３に示すデータ受け渡しを制御する。
【０３９８】
まず、データ受け渡し制御部１３４は、公開鍵及び秘密鍵を取得する。具体的には、データ受け渡し制御部１３４は、受け渡し先フラグ『４』は『利用中サービス』を示す情報であるので、制御用セッション情報『１１１１１１１１１１』を用いて発着間紐付けＩＤテーブル１２４を参照し、ステータスが『利用中』のサービスのサービスＩＤ『１００１』を取得する。そして、データ受け渡し制御部１３４は、サービスＩＤ『１００１』を用いて契約サービス情報テーブル１２２を参照し、サービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、公開鍵要求をＵＲＬ『http://example1.co.jp』に対して送信する（ステップＳ１２０４）。
【０３９９】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、公開鍵及び秘密鍵を取得し（ステップＳ１２０５）、公開鍵をセッション管理サーバ１００に対して送信する（ステップＳ１２０６）。
【０４００】
セッション管理サーバ１００のデータ受け渡し制御部１３４は、受け渡し要求に含められていたサービスＩＤ『１００２』を用いて契約サービス情報テーブル１２２を参照する。そして、データ受け渡し制御部１３４は、契約サービスＩＤ『１００２』に対応付けて記憶されているサービス提供サーバのＵＲＬ『http://example2.co.jp』を検索し、ＵＲＬ『http://example2.co.jp』に対して、ステップＳ１２０６において取得した公開鍵を送信する（ステップＳ１２０７）。なお、実施例１におけるデータ受け渡し制御部１３４は、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともに公開鍵を送信する。
【０４０１】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、データ取得要求に含められていた仮名ＩＤ『ｋａｍｅｉ１１１１』を用いてデータテーブル２２２を参照し、仮名ＩＤ『ｋａｍｅｉ１１１１』に対応付けて記憶されているデータを取得し、取得したデータを、ステップＳ１２０７において受信した公開鍵で暗号化する（ステップＳ１２０８）。
【０４０２】
そして、データ受け渡し部２３３は、ステップＳ１２０８において暗号化したデータをセッション管理サーバ１００に対して送信する（ステップＳ１２０９）。
【０４０３】
すると、セッション管理サーバ１００のデータ受け渡し制御部１３４は、サービス提供サーバのＵＲＬ『http://example1.co.jp』を検索し、ＵＲＬ『http://example1.co.jp』に暗号されたデータを送信する（ステップＳ１２１０）。なお、実施例１におけるデータ受け渡し制御部１３４は、仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』とともにデータを送信する。
【０４０４】
すると、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップＳ１２１０において受信したデータを、ステップＳ１２０５において取得した秘密鍵で復号し（ステップＳ１２１１）、ステップＳ１２１０において受信した仮名ＩＤ『ｋａｍｅｉ１１１１』と対応付けてデータテーブル２２２に格納する（ステップＳ１２１２）。
【０４０５】
その後、サービス提供サーバ２００のデータ受け渡し部２３３は、ステップ１２１０とステップＳ１２１３との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ１２１０に対する応答として結果通知を行う（ステップＳ１２１３）。例えば、データ受け渡し部２３３は、ステップＳ１２１０において取得した仮名ＩＤ『ｋａｍｅｉ１１１１』および発着間紐付けＩＤ『ｌｉｎ３３３３』を送信したりする。あるいは、ステップＳ１２１０においてデータとともに乱数が送信されていた場合などには、ステップＳ１２１３において当該乱数を送信してもよい。
【０４０６】
また、図２５に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１２１３において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ１２１３において受信した結果通知の時刻情報（日時など）を格納する。
【０４０７】
［方式４］
方式４は、現に通話中の利用者であるとの判定に基づいてセッション管理サーバ１００が制御することで、通話相手のＨＧＷ１０から受け渡し要求の要求元のＨＧＷ１０へとデータを受け渡す方式である。方式４には、図２６〜２７に示すように、例えば方式４−１及び４−２の種類がある。各方式の相違点を簡単に説明すると、まず、方式４−１は、データを暗号化せずに受け渡しを行う方式であるのに対し、方式４−２は、データを暗号化してから受け渡す方式である。このため、方式４−２は、例えば秘匿性の高いデータを受け渡しの対象とする場合などに適用することができる。すなわち、方式４−１は、上記したように、セッション管理サーバ１００が、受け渡しの対象となるデータを直接送受信する方式であるが、方式４−２は、データを暗号化してから受け渡すので、セッション管理サーバ１００は、データを復号できなければ実質的にデータを取得することにはならず、セキュリティをより向上することが可能になるのである。すなわち、方式４−２によれば、受け渡しの対象となるデータは暗号化されているので、セッション管理サーバ１００は、受け渡しの対象となるデータの内容を把握することが不可能である。言い換えると、セッション管理サーバ１００は、例えばデータが個人情報であれば、個人情報を管理する難しさを回避することができ、データを管理するリスクを低減することができることになる。また一方で、セッション管理サーバ１００は、暗号化されたデータについて第三者として検証を行うことができる。すなわち、例えば、後日ＨＧＷ１０間でデータの受け渡しに関する紛争（データを渡した、渡さないといった紛争など）が起きた場合に、セッション管理サーバ１００は、鍵情報を提供されれば証拠のデータを復元させることができ、第三者として検証を行うことができる。
【０４０８】
［方式４−１］
図２６を用いて方式４−１を説明する。図２６に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ１３０１）。
【０４０９】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ１３０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０４１０】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含め、データ保存元フラグとして『２』（通話相手ＨＧＷ）を含めることで、着信側のＨＧＷ１０が記憶するデータを発信側のＨＧＷ１０に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０４１１】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ１３０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０４１２】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０４１３】
また、図２６に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１３０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０４１４】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤを受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『２』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０４１５】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ１３０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０４１６】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ１３０４〜Ｓ１３２１に示すデータ受け渡しを制御する。
【０４１７】
具体的には、データ受け渡し制御部１３４は、受け渡し要求に含められていたデータ保存元フラグ『２』から、データの保存元が要求元の情報表示端末２０とは異なる着信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報『ｕｉ１２３４５６７８９』と同じｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を検索し、制御用セッション情報『３３３３３３３３３３』を取得する。
【０４１８】
また、データ受け渡し制御部１３４は、受け渡し要求に含められていた受け渡し先フラグ『１』から、データの保存元が要求元の情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/return』を取得する。
【０４１９】
そして、データ受け渡し制御部１３４は、ポーリングしている情報表示端末２０の中から制御用セッション情報『３３３３３３３３３３』の情報表示端末２０を特定し、特定した情報表示端末２０に対して、データ送信の可否を確認する確認画面（ダイアログが画面）を送信する（ステップＳ１３０４）。例えば、確認画面には、「通話相手の方からデータ受け渡し要求を受けていますが、ダウンロードしてもよろしいですか？」と記載されている。
【０４２０】
すると、情報表示端末２０の受け渡し要求部２５ｂは、出力部２３に確認画面を表示し（ステップＳ１３０５）、例えば、着信側の利用者が、情報表示端末２０の出力部２３に表示された確認画面を了承する了承ボタンを、入力部２２を用いて押下する（ステップＳ１３０６）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者による了承をセッション管理サーバ１００に通知する（ステップＳ１３０７）。
【０４２１】
続いて、セッション管理サーバ１００のデータ受け渡し制御部１３４は、着信側のＨＧＷ１０に対して、データ送信要求を送信する（ステップＳ１３０８）。具体的には、データ受け渡し制御部１３４は、着信側の情報表示端末２０に対して、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.3.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行い、このリダイレクト指示の際には、データ送信要求であることを示すリクエストも送信する。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０４２２】
すると、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１３０９）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０４２３】
そして、データ受け渡し部１３ｂは、ステップＳ１２０９においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ１３１０)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ１３１１）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ１３１２）。
【０４２４】
ここで、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ１３１３）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ１３１４）。
【０４２５】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ１３１４において受信した選択情報にて指定されるデータを記憶部から取得し（ステップＳ１３１５）、取得したデータを、セッション管理サーバ１００に対してリダイレクトで送信する（ステップＳ１３１６）。この時、データ受け渡し部１３ｂは、ステップＳ１３０８とＳ１３１６との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信する。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ１３０８において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ１３０８においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ１３１６において当該乱数を送信してもよい。
【０４２６】
続いて、データ受け渡し制御部１３４は、受け渡し先フラグ『１』から、データの受け渡し先が要求元の情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ１３１６において取得したデータ及びｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ１３１７）。この時、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、ＨＧＷ１０のＵＲＬを取得している。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０４２７】
また、図２６に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１３１７においてデータを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『データ送信済』に、ステップＳ１３１７におけるデータ送信の時刻情報（日時など）を格納する。
【０４２８】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１３１８）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０４２９】
そして、データ受け渡し部１３ｂは、ステップＳ１３１８においてｃａｌｌセッション情報の検証に成功すると、ステップＳ１３１７において受信したデータを記憶部１２に格納する（ステップＳ１３１９）。
【０４３０】
その後、データ受け渡し部１３ｂは、ステップＳ１３１７とステップＳ１３２０との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ１３１７に対する応答として結果通知を行う（ステップＳ１３２０）。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ１３１７において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ１３１７においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ１３２０において当該乱数を送信してもよい。
【０４３１】
また、図２６に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１３２０において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ１３２０において受信した結果通知の時刻情報（日時など）を格納する。
【０４３２】
なお、上記した処理手順の他に、ステップＳ１３１７以降については、例えば、図１５のステップＳ２０４と同様の処理手順によってデータを受け渡すこともできる。
【０４３３】
［方式４−２］
図２７−１及び図２７−２を用いて方式４−２を説明する。図２７−１に示すように、例えば、発信側の利用者が、情報表示端末２０の出力部２３に表示されたブラウザの受け渡しボタンを、入力部２２を用いて押下する（ステップＳ１４０１）。
【０４３４】
すると、情報表示端末２０の受け渡し要求部２５ｂは、制御用セッション情報を付与した受け渡し要求をセッション管理サーバ１００に送信する（ステップＳ１４０２）。また、この時、受け渡し要求部２５ｂは、受け渡し先フラグ及びデータ保存元フラグを受け渡し要求に含め、また、必要に応じてサービスＩＤを受け渡し要求に含める。もっとも、例えば現に利用中のサービスに関連するデータが受け渡しの対象となる場合などには、サービスＩＤを省略することもできる。
【０４３５】
例えば、受け渡し要求部２５ｂは、制御用セッション情報『１１１１１１１１１１』を付与した受け渡し要求に、受け渡し先フラグとして『１』（自ＨＧＷ）を含め、データ保存元フラグとして『２』（通話相手ＨＧＷ）を含めることで、着信側のＨＧＷ１０が記憶するデータを発信側のＨＧＷ１０に受け渡すことを要求する。なお、受け渡し要求に制御用セッション情報を付与する手法を説明したが、この手法に限られるものではなく、制御用セッション情報の替わりに発着間紐付けＩＤを付与する手法や、仮名ＩＤを付与する手法、あるいは発着間紐付けＩＤおよび仮名ＩＤを付与する手法などでもよい。
【０４３６】
一方、セッション管理サーバ１００の受け渡し要求判定部１３３は、受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０の利用者が、ＳＩＰによって通信を確立したＳＩＰフォン３０の利用者であるか否かを判定する（ステップＳ１４０３）。例えば、当該利用者が、現に通話中の利用者であるか否かを判定する。
【０４３７】
具体的には、受け渡し要求判定部１３３は、受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、受け渡し要求判定部１３３は、制御用セッション情報『１１１１１１１１１１』が記憶されていることを確認するとともに、通話情報『２００９年１月７日  ２２：３５〜』を確認すること（通話終了時刻が記録されていないという通話状態を確認すること）で、情報表示端末２０の利用者が現に通話中の利用者であると判定する。
【０４３８】
また、図２７−１に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１４０２において受け渡し要求を受け付けた後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、まず受け渡し要求に付与された制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているレコードについて、『制御用セッション情報』から『発着判定フラグ』までの情報をデータ受け渡しテーブル１２５に格納する。
【０４３９】
次に、受け渡し要求判定部１３３は、受け渡し要求に含められていた受け渡し先フラグ『１』を受け渡し先情報に格納するとともに発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤを受け渡し先情報に格納し、また、受け渡し要求に含められていたデータ保存元フラグ『２』をデータ保存元情報に格納するとともに、発着間紐付けＩＤテーブル１２４から取得した発着間紐付けＩＤおよび仮名ＩＤをデータ保存元情報に格納する。
【０４４０】
続いて、受け渡し要求判定部１３３は、ステータス情報の『要求受付』に、ステップＳ１４０２において受け付けた受け渡し要求に関する時刻情報（受け渡し要求を受信した日時など）を格納する。
【０４４１】
続いて、データ受け渡し制御部１３４が、受け渡し要求に従って、ステップＳ１４０４〜Ｓ１４２５に示すデータ受け渡しを制御する。
【０４４２】
具体的には、データ受け渡し制御部１３４は、受け渡し要求に含められていたデータ保存元フラグ『２』から、データの保存元が要求元の情報表示端末２０とは異なる着信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているｃａｌｌセッション情報『ｕｉ１２３４５６７８９』と同じｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を検索し、制御用セッション情報『３３３３３３３３３３』を取得する。また、データ受け渡し制御部１３４は、制御用セッション情報『３３３３３３３３３３』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.3.10/return』を取得する。
【０４４３】
また、データ受け渡し制御部１３４は、受け渡し要求に含められていた受け渡し先フラグ『１』から、データの受け渡し先が要求元の情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、制御用セッション情報『１１１１１１１１１１』を用いて制御用セッション管理テーブル１２３を参照する。そして、データ受け渡し制御部１３４は、制御用セッション情報『１１１１１１１１１１』に対応付けて記憶されているＨＧＷのＵＲＬ『http://192.168.1.10/return』を取得する。
【０４４４】
そして、データ受け渡し制御部１３４は、ポーリングしている情報表示端末２０の中から制御用セッション情報『３３３３３３３３３３』の情報表示端末２０を特定し、特定した情報表示端末２０に対して、データ送信の可否を確認する確認画面（ダイアログが画面）を送信する（ステップＳ１４０４）。例えば、確認画面には、「通話相手の方からデータ受け渡し要求を受けていますが、ダウンロードしてもよろしいですか？」と記載されている。
【０４４５】
すると、情報表示端末２０の受け渡し要求部２５ｂは、出力部２３に確認画面を表示し（ステップＳ１４０５）、例えば、着信側の利用者が、情報表示端末２０の出力部２３に表示された確認画面を了承する了承ボタンを、入力部２２を用いて押下する（ステップＳ１４０６）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者による了承をセッション管理サーバ１００に通知する（ステップＳ１４０７）。
【０４４６】
続いて、セッション管理サーバ１００のデータ受け渡し制御部１３４は、公開鍵及び秘密鍵を取得する。具体的には、データ受け渡し制御部１３４は、受け渡し要求の要求元の情報表示端末２０に対して、公開鍵要求をｃａｌｌセッション情報『ｕｉ１２３４５６７８９』とともに送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ１４０８）。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０４４７】
すると、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１４０９）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０４４８】
そして、データ受け渡し部１３ｂは、ステップＳ１４０９においてｃａｌｌセッション情報の検証に成功すると、公開鍵及び秘密鍵を取得し（ステップＳ１４１０）、取得した公開鍵をセッション管理サーバ１００に対してリダイレクトで送信する（ステップＳ１４１１）。この時、データ受け渡し部１３ｂは、ステップＳ１４０８とＳ１４１１との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信する。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ１４０８において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ１４０８においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ１４１１において当該乱数を送信してもよい。
【０４４９】
続いて、セッション管理サーバ１００のデータ受け渡し制御部１３４は、ポーリングしている情報表示端末２０の中から制御用セッション情報『３３３３３３３３３３』の情報表示端末２０を特定し、特定した情報表示端末２０に対して、ステップＳ１４１１において受信した公開鍵をｃａｌｌセッション情報『ｕｉ１２３４５６７８９』とともに送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.3.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ１４１２）。ここでｃａｌｌセッション情報（例えば、Ｃａｌｌ−ＩＤ）を送信する目的は、ｃａｌｌセッション情報が、ＨＧＷ１０とセッション管理サーバ１００との間で呼を一意に識別できる情報であるからである。また、ＨＧＷ１０が、確かにセッション管理サーバ１００による制御の下でデータが受け渡されるのかを検証する目的もある。
【０４５０】
すると、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１４１３）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０４５１】
そして、データ受け渡し部１３ｂは、ステップＳ１４１３においてｃａｌｌセッション情報の検証に成功すると、ＨＧＷ１０に記憶しているデータのインデックス情報などを記載した『データ一覧ページ』を生成し(ステップＳ１４１４)、生成した『データ一覧ページ』を情報表示端末２０に送信する（ステップＳ１４１５）。すると、情報表示端末２０の受け渡し要求部２５ｂは、ＨＧＷ１０から受信した『データ一覧ページ』を出力部２３に表示する（ステップＳ１４１６）。
【０４５２】
ここで、例えば、利用者が、情報表示端末２０の出力部２３に表示された『データ一覧ページ』を閲覧し、所定のデータを選択する選択ボタンを入力部２２を用いて押下する（ステップＳ１４１７）。すると、情報表示端末２０の受け渡し要求部２５ｂは、利用者によって選択されたデータの選択情報をＨＧＷ１０に通知する（ステップＳ１４１８）。
【０４５３】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ステップＳ１４１８において受信した選択情報にて指定されるデータを記憶部から取得し（ステップＳ１４１９）、取得したデータを、ステップＳ１４１２において取得した公開鍵で暗号化し（ステップＳ１４１９）、セッション管理サーバ１００に対してリダイレクトで送信する（ステップＳ１４２０）。この時、データ受け渡し部１３ｂは、ステップＳ１４１２とＳ１４２０との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信する。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ１４１２において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ１４１２においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ１４２０において当該乱数を送信してもよい。
【０４５４】
続いて、データ受け渡し制御部１３４は、受け渡し先フラグ『１』から、データの受け渡し先が要求元の情報表示端末２０と同じ発信側のＨＧＷ１０であることを識別し、受け渡し要求の要求元の情報表示端末２０に対して、ステップＳ１４２１において取得したデータ及びｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を送信するとともに、制御用セッション管理テーブル１２３を参照して取得したＨＧＷのＵＲＬ『http://192.168.1.10/returm』を送信することで、ＨＧＷ１０へのリダイレクト指示を行う（ステップＳ１４２１）。
【０４５５】
また、図２７−２に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１４２１においてデータを送信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『データ送信済』に、ステップＳ１４２１におけるデータ送信の時刻情報（日時など）を格納する。
【０４５６】
一方、ＨＧＷ１０のデータ受け渡し部１３ｂは、ｃａｌｌセッション情報を検証する（ステップＳ１４２２）。具体的には、データ受け渡し部１３ｂは、ｃａｌｌセッション情報『ｕｉ１２３４５６７８９』を用いてブラウザセッション情報管理テーブル１２ａを参照し、ブラウザセッション情報管理テーブル１２ａで管理しているｃａｌｌセッション情報と同じｃａｌｌセッション情報であることを検証する。
【０４５７】
そして、データ受け渡し部１３ｂは、ステップＳ１４２２においてｃａｌｌセッション情報の検証に成功すると、ステップＳ１４２１において取得したデータをステップＳ１４１０において取得した秘密鍵で復号し（ステップＳ１４２３）、記憶部１２に格納する（ステップＳ１４２４）。
【０４５８】
その後、データ受け渡し部１３ｂは、ステップＳ１４２１とステップＳ１４２５との対応関係を検証することが可能な情報をセッション管理サーバ１００に対して送信することで、ステップＳ１４２１に対する応答として結果通知を行う（ステップＳ１４２５）。例えば、データ受け渡し部１３ｂは、対応関係を検証することが可能な情報として、ステップＳ１４２１において取得したｃａｌｌセッション情報を送信したり、制御用セッション情報を送信したりする。あるいは、ステップＳ１４２１においてｃａｌｌセッション情報とともに乱数が送信されていた場合などには、ステップＳ１４２５において当該乱数を送信してもよい。
【０４５９】
また、図２７に示すように、セッション管理サーバ１００の受け渡し要求判定部１３３は、ステップＳ１４２５において結果通知を受信した後に、データ受け渡しテーブル１２５にステータス情報を格納する。例えば、受け渡し要求判定部１３３は、ステータス情報の『受け渡し完了』に、ステップＳ１４２５において受信した結果通知の時刻情報（日時など）を格納する。
【０４６０】
なお、方式１〜方式４について、上記してきた処理手順は一例に過ぎず、適宜順序やデータの送信先などを変更することができる。また、方式１〜方式４について、リダイレクトを用いてデータを送信した処理手順については、リダイレクトを用いずに直接送信する処理手順に適宜変更することができる。
【０４６１】
［実施例１の効果］
上記してきたように、実施例１に係るサービス提供システムにおいて、セッション管理サーバ１００は、サービスの提供を要求する情報表示端末２０毎に、利用者において当該情報表示端末２０と組で利用されＳＩＰ通信を確立するＳＩＰフォン３０と他のＳＩＰフォン３０との間で確立された通信を識別するｃａｌｌセッション情報を収集する。また、セッション管理サーバ１００は、収集した複数のｃａｌｌセッション情報の中から同一の通信を示すｃａｌｌセッション情報を特定し、特定したｃａｌｌセッション情報によって識別される通信を確立したＳＩＰフォン３０各々と組で利用される情報表示端末２０各々を連携するための連携情報を、情報表示端末２０各々に対して発行する。そして、サービス提供サーバ２００からサービスを連携するように提供される情報表示端末２０間において、一方の情報表示端末２０からデータの受け渡しを要求する受け渡し要求を受け付けると、当該受け渡し要求の要求元の情報表示端末２０が、ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される端末であるか否かを判定する。そして、ＳＩＰによって通信を確立したＳＩＰフォン３０と組で利用される情報表示端末２０であると判定すると、受け渡し要求に従って、受け渡しに用いられるデータをデータの保存元から取得し、取得したデータを用いてデータの受け渡しを制御する。
【０４６２】
このように、実施例１に係るサービス提供システムにおいて、セッション管理サーバ１００は、ＳＩＰによって確立した一時的な通信関係に基づくサービス提供を実現するための発着間紐付けＩＤを発行するとともに、データの受け渡し要求を受け付けると、受け渡し要求の要求元の利用者が通話中であることを確認の上、データ受け渡しを制御する。このようなことから、ＳＩＰフォン３０と情報表示端末２０とを組で利用する利用者は、例えば、通話をしながら通話相手と連携してＷｅｂサービスを利用することが可能になり、かつ、通話の延長で容易にデータの受け渡しを行うことが可能になる。
【０４６３】
すなわち、上記の仕組みがなければ、発信側の情報表示端末２０と着信側の情報表示端末２０との間で、ブラウザ間でデータを受け渡すことしかできない。また、セッション管理サーバ１００がデータの受け渡しを保証することができない。セッション管理サーバ１００がデータの受け渡しを保証できないとすると、例えば、利用者は、ＨＧＷ１０に格納している個人情報をサービス提供サーバ２００に対して受け渡したはずであるのに、実は当該サービス提供サーバは、サービス利用の途中から通信に介在したなりすましのサービス提供サーバかもしれず、利用者は、個人情報をなりすましのサービス提供サーバに受け渡してしまうかもしれない。
【０４６４】
しかしながら、上記の仕組みによれば、データの受け渡しはセッション管理サーバ１００による保証付き、すなわち、発信側の情報表示端末２０と着信側の情報表示端末２０とがセッション管理サーバ１００によって発着間紐付けＩＤが発行された端末であることが保証され、また、データの受け渡し先や保存元が、セッション管理サーバ１００による保証付きになる（例えば、利用中のサービス提供サーバ２００であることなど）。結果として、利用者は、セッション管理サーバ１００を信用しているならば、安心してデータの受け渡しを行うことができるようになる。
【０４６５】
また、実施例１における受け渡し要求は、受け渡し先を指定する受け渡し先フラグおよび受け渡しの対象となるデータの保存元を指定するデータ保存元フラグを含むものであって、セッション管理サーバ１００は、受け渡し要求に含められていた受け渡し先フラグおよびデータ保存元フラグに従って、当該データ保存元フラグにて指定されたデータを、当該受け渡し先フラグにて指定された受け渡し先へと受け渡すよう制御する。
【０４６６】
また、実施例１におけるセッション管理サーバ１００は、発着間紐付けＩＤを発行するとともに、情報表示端末２０もしくは情報表示端末２０の利用者を識別する仮名ＩＤを当該発着間紐付けＩＤと組の情報として発行し、仮名ＩＤを用いて、受け渡し要求にて指定された受け渡し先もしくはデータ保存元を特定して受け渡しを制御する。
【０４６７】
また、実施例１におけるセッション管理サーバ１００は、受け渡しの対象となるデータが、受け渡し先の鍵情報を用いて暗号化された上で受け渡されるように、データの受け渡しを制御する。
【０４６８】
このようなことから、利用者は、セッション管理サーバ１００を信用しているならば、安心してデータの受け渡しを行うことができるようになる。
【実施例２】
【０４６９】
さて、これまで本発明の実施例１について説明してきたが、本発明は実施例１以外にも種々の異なる形態にて実施されてよいものである。
【０４７０】
［受け渡し対象のデータ］
上記実施例においては、受け渡し対象となるデータがサービスに関連するデータであることを想定してきた。しかしながら、本発明はこれに限られるものではなく、単に通話中にデータの受け渡しをするような場合にも適用することができる。例えば、ＨＧＷ間でデータを受け渡すような場合には、サービス提供サーバとは関係なく、方式４−１および方式４−２を適用することができる。もっとも、この場合には、セッション管理サーバが、サービスを連携するための情報として発着間紐付けＩＤを発行する必要がなくなってしまう。そこで、セッション管理サーバは、例えば、受け渡し要求に含められているｃａｌｌセッション情報が、セッション管理サーバが管理しているｃａｌｌセッション情報であるかといった判定を行い、判定の結果が成功であれば、データの受け渡しを制御する、といった手法が考えられる。
【０４７１】
［セッション管理機能］
上記実施例においては、『セッション連携機能』が、ＳＩＰプロキシやサービス提供サーバとは物理的に異なるセッション管理サーバに備えられている事例を説明してきたが、本発明はこれに限られるものではない。『セッション連携機能』が、ＳＩＰプロキシに備えられている事例にも、あるいは、サービス提供サーバに備えられている事例などにも、本発明を同様に適用することができる。
【０４７２】
［接続先監視機能］
上記実施例においては、情報表示端末が、汎用的なＷｅｂブラウザを備え、『接続先監視機能』として、当該Ｗｅｂブラウザ上で動作するＪａｖａＳｃｒｉｐｔファイルを備える手法（セッション管理サーバから送信されることで『接続先監視機能』を備える手法）を説明してきたが、本発明はこれに限られるものではない。情報表示端末が、専用アプリケーションを備え、当該専用アプリケーションが、予め『接続先監視機能』を備えている手法などにも、本発明を同様に適用することができる。
【０４７３】
［発着間紐付けＩＤ］
上記実施例においては、サービス提供サーバがＷｅｂサービスを互いに関連づけて制御する際に用いる「発着間紐付けＩＤ」として、セッション管理サーバが新たに発行した発着間紐付けＩＤを用いる手法を説明してきたが、本発明はこれに限られるものではない。呼情報であるｃａｌｌセッション情報そのもの（例えば、Call-IDなど）を流用する手法にも、本発明を同様に適用することができる。すなわち、「発着間紐付けＩＤ」は、サービス提供サーバが、複数の端末に対してＷｅｂサービスを互いに関連づけて提供する際に、当該複数の端末各々がＳＩＰによって通信を確立した端末同士であることを認識可能な情報であればよい。
【０４７４】
［署名付証明書］
上記実施例においては、ＳＩＰプロキシやセッション管理サーバが他の装置に情報を送信する際、自装置の署名付証明書を発行し、当該署名付証明書を添付した検証可能な形式で当該情報を送信する手法を説明してきたが、本発明はこれに限られるものではない。署名付証明書を添付することなく、単に情報をそのまま送信する手法にも、本発明を同様に適用することができる。なお、この場合には、情報を受信した側における当該情報の検証も不要となる。
【０４７５】
［ポーリング］
上記実施例においては、情報表示端末とＨＧＷとの間、情報表示端末とセッション管理サーバとの間などで、適宜ポーリングを用いて通信を行う手法を説明してきたが、本発明はこれに限られるものではなく、ポーリングの替わりにプッシュ型やプル型の通信であってもよい（この場合には、必要な時のみアクセスすればよいことになる）。
【０４７６】
［端末側の構成］
また、本発明に係るサービス提供システムは、上記実施例で例示した構成に限られるものではない。すなわち、本発明に係るサービス提供システムは、まず、端末側の構成という点で、端末側にＨＧＷが設置されているか否か、端末が、ＳＩＰフォンと情報表示端末との分離型であるか、ＳＩＰフォン機能と情報表示機能との一体型であるか、といった選択肢がある。また、どの装置がcallセッション情報を収集するかという点で、ＳＩＰプロキシがcallセッション情報を収集するか、ＨＧＷがｃａｌｌセッション情報を収集するか、端末（ＳＩＰフォン、もしくは、ＳＩＰフォン機能）がｃａｌｌセッション情報を収集するか、といった選択肢がある。また、ＳＩＰプロキシが収集したｃａｌｌセッション情報を誰に送信するかという点で、ＨＧＷに送信するか、端末（ＳＩＰフォン、もしくは、ＳＩＰフォン機能）に送信するか、といった選択肢がある。その他、発信側の構成と着信側の構成とが同一であるか、異なるか、といった選択肢や、情報表示端末がＨＧＷの配下の端末として接続しているか否かといった選択肢もある。上記実施例は、これらの選択肢の内、一部の組み合わせを示したに過ぎず、本発明はこれらの構成に限られるものではない。すなわち、上記してきた手法や公知の手法を用いることで、その他の構成についても、本発明を同様に実現することができる。
【０４７７】
［ＳＩＰプロキシ］
また、上記の実施例においては、単一のＳＩＰプロキシがＳＩＰ信号（ＳＩＰの具体的な信号、INVITE、200  OKなどの種類、および、From、Toなどのパラメータを含む）を仲介する事例を説明してきたが、本発明はこれに限られるものではない。複数のＳＩＰプロキシがＳＩＰ信号を仲介する事例や、ＮＧＮ（Next  Generation  Network）におけるＡＳ（Application  Server）などがＳＩＰ信号を仲介する事例にも、本発明を同様に適用することができる。
【０４７８】
［過去の通話の利用者］
また、上記の実施例においては、現に通話中の利用者であることを判定する手法を説明してきたが、本発明はこれに限られるものではなく、例えば、少なくとも過去に通話したことのある利用者であることを判定する手法などでもよい。かかる手法では、例えば、利用者は、通話中にデータを作成しておけば、通話切断後、過去の通話に関係のある情報として当該データを取得することができる。例えば、利用者が、通話中の会話データをＨＧＷに格納しておき、セッション管理サーバは、当該通話を通話した通話相手にのみ、当該会話データをダウンロードさせるといったことが可能になる。具体的な事例を想定して説明すると、例えば、利用者がコールセンタに電話して問い合わせを行い、一旦通話を切断して、別途回答を受け取るといった事例が考えられる。この時、利用者は、一度通話を切断するが、コールセンタ側のサービス提供サーバ２００は、通話のセッション情報を用いることで、利用者側のＨＧＷ１０に対して、後日、質問の回答の文面（データ）を受け渡す。つまり、サービス提供サーバ２００が、問い合わせを受けた際のセッション情報をセッション管理サーバ１００に通知してデータの受け渡しを要求すると、セッション管理サーバ１００は、このデータの受け渡しに介在し、過去の通話履歴情報に基づき、回答情報を、利用者側のＨＧＷ１０へ受け渡す。なお、セッション管理サーバ１００から利用者側のＨＧＷ１０にデータを受け渡す時には、ブラウザのリダイレクトではなく、セッション管理サーバ１００から、ＨＧＷ１０に対して直接データを送信してもよい。
【０４７９】
［受け渡し先フラグ、データ保存元フラグの設定］
また、受け渡し先フラグやデータ保存元フラグの設定は、上記の実施例１に記載した組み合わせに限られるものではなく、組み合わせ得る様々なパターンで、データの受け渡しをすることができる。例えば、上記の実施例１に記載した方式１や方式２においては、通話元の情報表示端末２０に対してデータを送信したり、通話元の情報表示端末３０からデータを送信しているが、受け渡し先フラグやデータ保存元フラグの設定によっては、通話相手のＨＧＷ１０に対してデータを送信したり、通話相手のＨＧＷ１０からサービス提供サーバ２００にデータを送信することもできる。
【０４８０】
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０４８１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０４８２】
なお、本実施例で説明したサービス提供方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【符号の説明】
【０４８３】
１００  セッション管理サーバ
１１０  通信部
１２０  記憶部
１２１  ユーザ契約サービス管理テーブル
１２２  契約サービス情報テーブル
１２３  制御用セッション管理テーブル
１２４  発着間紐付けＩＤテーブル
１３０  制御部
１３１  ｃａｌｌセッション情報収集部
１３２  発着間紐付けＩＤ発行部
１３３  受け渡し要求判定部
１３４  データ受け渡し制御部
２００  サービス提供サーバ
２１０  通信部
２２０  記憶部
２２１  Ｗｅｂセッション情報管理テーブル
２３０  制御部
２３１  発着間紐付けＩＤ収集部
２３２  サービス提供制御部
２３３  データ受け渡し部
１０  ＨＧＷ
１１  ＳＩＰ通信部／ＨＴＴＰ通信部
１２  記憶部
１２ａ  ブラウザセッション情報管理テーブル
１３  制御部
１３ａ  サービス利用制御部
１３ｂ  データ受け渡し部
２０  情報表示端末
２１  ＨＴＴＰ通信部
２２  入力部
２３  出力部
２４  入出力制御Ｉ／Ｆ部
２５  制御部
２５ａ  サービス利用部
２５ｂ  受け渡し要求部
３０  ＳＩＰフォン
３１  ＳＩＰ通信部
３２  入力部
３３  出力部
３４  入出力制御Ｉ／Ｆ部
【図１】
2010273101.tif 000003
【図２】
2010273101.tif 000004
【図３】
2010273101.tif 000005
【図４】
2010273101.tif 000006
【図５】
2010273101.tif 000007
【図６】
2010273101.tif 000008
【図７】
2010273101.tif 000009
【図８−１】
2010273101.tif 000010
【図８−２】
2010273101.tif 000011
【図９−１】
2010273101.tif 000012
【図９−２】
2010273101.tif 000013
【図１０】
2010273101.tif 000014
【図１１】
2010273101.tif 000015
【図１２】
2010273101.tif 000016
【図１３−１】
2010273101.tif 000017
【図１３−２】
2010273101.tif 000018
【図１３−３】
2010273101.tif 000019
【図１３−４】
2010273101.tif 000020
【図１４】
2010273101.tif 000021
【図１５】
2010273101.tif 000022
【図１６】
2010273101.tif 000023
【図１７】
2010273101.tif 000024
【図１８】
2010273101.tif 000025
【図１９】
2010273101.tif 000026
【図２０】
2010273101.tif 000027
【図２１】
2010273101.tif 000028
【図２２】
2010273101.tif 000029
【図２３】
2010273101.tif 000030
【図２４】
2010273101.tif 000031
【図２５】
2010273101.tif 000032
【図２６】
2010273101.tif 000033
【図２７−１】
2010273101.tif 000034
【図２７−２】
2010273101.tif 000035