JP5184572B2 - サービス提供装置、サービス提供方法およびサービス提供プログラム - Google Patents

Description

本発明は、サービス提供装置、サービス提供方法およびサービス提供プログラムに関する。

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

近年では、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御するサービス提供システムも開示されている。具体的に、端末Ａ、端末Ｂ、端末Ｃを制御するサービス提供システムを例にして説明する。なお、端末Ａは、ＳＩＰ（Session Initiation Protocol）などの音声通信制御プロトコルを用いて通信することができるＳＩＰフォンと、Ｗｅｂブラウザなどを利用できる情報表示機能を有している。

このような状態におけるサービス提供システムは、ＳＩＰを用いて端末ＡのＳＩＰフォンと端末ＢのＳＩＰフォンとをＳＩＰ通信で接続する。そして、端末ＡのＳＩＰフォン及び端末ＢのＳＩＰフォン各々は、ＳＩＰ通信であることを示すcallセッション情報「CCC」やＳＩＰ通信に含まれるＩＰ（Internet Protocol）アドレスなどを収集する。続いて、サービス提供システムは、端末Ａの情報表示機能（Java（登録商標）scriptなど）からｃａｌｌセッション情報「CCC」やＩＰアドレスをＷｅｂ通信で受信すると、端末Ａに対して、Ｗｅｂ通信を一意に識別する情報であるWebセッション情報「123」を払い出す。同様に、サービス提供システムは、端末Ｂの情報表示機能からｃａｌｌセッション情報「CCC」やＩＰアドレスをＷｅｂ通信で受信すると、端末Ｂに対して、Ｗｅｂセッション情報「456」を払い出す。

このＷｅｂセッション情報を払出すタイミングで、サービス提供システムは、ＩＰアドレスによる認証を実施する。具体的には、サービス提供システムは、端末Ａの情報表示機能からｃａｌｌセッション情報を受信した際に「端末Ａの情報収集機能がアクセスしてきたＩＰアドレス」と、該アクセスによってｃａｌｌセッション情報とともに受信した「端末ＡのＳＩＰフォンによって収集されたＳＩＰ通信で利用されるＩＰアドレス」とが一致するか否かを判定する。そして、サービス提供システムは、両アドレスが一致する場合、すなわち、端末ＡがＷｅｂ通信で使用するＩＰアドレスと端末ＡがＳＩＰ通信で使用するＩＰアドレスが一致する場合に、端末Ａに対してＷｅｂセッション情報を払い出す。端末Ｂについても同様に、サービス提供システムは、端末ＢがＷｅｂ通信で使用するＩＰアドレスと端末ＢがＳＩＰ通信で使用するＩＰアドレスが一致する場合に、端末Ｂに対してＷｅｂセッション情報を払い出す。

そして、サービス提供システムは、ｃａｌｌセッション情報「CCC」に対して払出した端末ＡのＷｅｂセッション情報「123」と端末ＢのＷｅｂセッション情報「456」とを関連付ける。その後、端末Ａが、Ｗｅｂセッション情報「123」が付与されたＷｅｂ通信によってサービス提供システムにアクセスしている際に、一方の端末Ｂが、Ｗｅｂセッション情報「456」が付与されたＷｅｂ通信によってサービス提供システムに画像データをアップロードしたとする。このような場合、端末Ａ、Ｂ各々の関係は、ＳＩＰによって同一の通信を確立した関係であるので、サービス提供システムは、画像データの共有を互いに認めている関係であると判定する。この結果、サービス提供システムは、端末Ａがアップロードした画像データを端末Ｂに送信するようにサービスを制御する。このように、通信相手との関係が一時的な場合（アドホックに変化する関係の場合）に、このような一時的な通信関係に基づいてサービスを制御することができる。

特開２００９−１７６２８９号公報

しかしながら、従来の技術では、ＳＩＰ通信で使用されるＩＰアドレスとＷｅｂ通信で使用されるＩＰアドレスの体系が違う場合など、ＩＰアドレスによる認証ができない事態が発生し、サービスを提供することができないという課題があった。

例えば、ＳＩＰ通信で使用されるＩＰアドレスがＩＰｖ４表記であり、Ｗｅｂ通信で使用されるＩＰアドレスがＩＰｖ６表記である場合には、サービス提供システムは、同じユーザの端末からのアクセスであっても、ＩＰアドレスが違うために認証が許可されず、Ｗｅｂセッション情報を払出せない。したがって、サービス提供システムは、通信相手との関係が一時的な場合に、このような一時的な通信関係に基づいてサービスを制御することができない。

また、各端末の情報表示機能は、ＨＴＴＰを対象とするWebブラウザ機能を実現するJava（登録商標）scriptなどであり、ＳＩＰやＲＴＰ（Real-time Transport Protocol）を対象としていない。このため、各端末の情報表示機能に、ＳＩＰを処理するためのスタックなど特別な機能を組み込む必要がある。したがって、サービス提供システムは、上記特別な機能を有しない情報表示機能が利用されていない端末から、ＳＩＰ通信で使用されるＩＰアドレスを正しく受信できない場合があり、ＩＰアドレスによる認証ができない事態が発生する。

本発明は、上記に鑑みてなされたものであって、サービスを利用する端末の性能やＩＰアドレスの体系に関係なく、一時的な通信関係に基づいてサービスを提供することが可能であるサービス提供装置、サービス提供方法およびサービス提供プログラムを提供することを目的とする。

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

本発明にかかるサービス提供装置、サービス提供方法およびサービス提供プログラムは、サービスを利用する端末の性能やＩＰアドレスの体系に関係なく、一時的な通信関係に基づいてサービスを提供することが可能であるという効果を奏する。

図１は、実施例１に係るサービス提供システムの全体構成を示す図である。 図２は、実施例１に係るサービス提供装置の構成を示すブロック図である。 図３は、仮登録ＤＢに記憶される情報の例を示す図である。 図４は、ユーザ管理ＤＢに記憶される情報の例を示す図である。 図５は、セッション情報ＤＢに記憶する情報の例を示す図である。 図６は、セッション情報ＤＢに記憶する情報の例を示す図である。 図７は、実施例１に係る端末の構成を示すブロック図である。 図８は、実施例１に係るサービス提供システムによる処理の流れを示すシーケンス図である。 図９は、リクエストメッセージを示す図である。 図１０は、レスポンスメッセージを示す図である。 図１１は、ＩＰアドレスによる認証処理を示すフローチャートである。 図１２は、実施例２に係るＨＧＷ、ＳＩＰフォン、情報表示端末のそれぞれの構成を示すブロック図である。 図１３は、ブラウザセッション情報ＤＢに記憶される情報の例を示す図である。 図１４は、実施例２に係るサービス提供装置における処理の流れを示すシーケンス図である。 図１５は、実施例３に係るサービス提供システムにおける処理の流れを示すシーケンス図である。 図１６は、実施例４に係るサービス提供システムにおける処理の流れを示すシーケンス図である。 図１７は、ＩＰアドレスと電話番号との対応付けを格納する有効条件の例を示す図である。

以下に、本発明にかかるサービス提供装置、サービス提供方法およびサービス提供プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

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

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

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

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

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

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

［サービス提供システムの全体構成］
次に、図１を用いて、実施例１に係るサービス提供システムの全体構成を説明する。図１は、実施例１に係るサービス提供システムの全体構成を示す図である。図１に示すように、サービス提供システムは、端末２００、端末４００、ＳＩＰ（Session Initiation Protocol）プロキシ３００、サービス提供装置１００を有する。なお、サービス提供システムは、これら以外にも、例えばＨＧＷ（ホームゲートウェイ）などを有していてもよい。

端末２００は、ＳＩＰによって通信を確立する過程の通信（ＳＩＰ通信）やＳＩＰによって確立された通信を行うＳＩＰフォン機能と、ブラウザ等によってＷｅｂサービスを利用できる情報表示機能とを有する。また、ＳＩＰフォンとＰＣとは別々の筐体で実現されていてもよく、一つの筐体で実現されていてもよい。なお、端末４００は、端末２００と同様なのでここでは詳細な説明は省略する。

ＳＩＰプロキシ３００は、端末からのリクエストを他の端末に転送するなどＳＩＰ通信に関する制御を実施するサーバ装置である。例えば、ＳＩＰプロキシ３００は、端末２００のＳＩＰフォン機能からのリクエスト（ＩＮＶＩＴＥ）を端末４００のＳＩＰフォン機能に転送し、端末４００のＳＩＰフォン機能からの応答（２００ ＯＫ）を端末２００のＳＩＰフォン機能に転送する。このようにすることで、ＳＩＰプロキシ３００は、端末２００と端末４００との間における音声通話を可能とする。

サービス提供装置１００は、端末各々の関係や端末とサービス提供装置１００との関係、もしくは端末を利用する利用者同士の関係などに基づいて、サービスを制御する。例えば、サービス提供装置１００は、端末２００と端末４００とがＳＩＰ接続されている状態で、端末２００の情報表示機能と端末４００の情報表示機能との間でやり取りされるＷｅｂサービスを制御する。なお、ＳＩＰプロキシ３００とサービス提供装置１００は、別々の筐体で実現されていてもよく、一つの筐体で実現されていてもよい。

このような状態において、サービス提供システムのサービス提供装置１００は、ユーザ宅間でアドホックに変化する関係に基づいてサービスを制御する前段階として、端末２００の情報表示機能からＨＴＴＰによるアクセスを受け付ける（図１の（１）参照）。続いて、サービス提供装置１００は、端末２００の情報表示機能が利用するＩＰｖ６表記のＩＰアドレスを受け付けたアクセスから取得し、取得したＩＰアドレスに対して一意な一時アドレスを対応付けて仮登録する（図１の（２）参照）。そして、サービス提供装置１００は、端末２００の情報表示機能が利用するＩＰｖ６表記のＩＰアドレスと対応付けた一時アドレスをアクセス元の端末２００の情報表示機能に送信する（図１の（３）参照）。

その後、サービス提供システムのＳＩＰプロキシ３００は、サービス提供装置１００を宛先とするＳＩＰのＩＮＶＩＴＥであって、ユーザ等によって入力された一時アドレスを含むＩＮＶＩＴＥを端末２００のＳＩＰフォン機能から受信する（図１の（４）参照）。続いて、ＳＩＰプロキシ３００は、受信した一時アドレスを含むＳＩＰのＩＮＶＩＴＥをサービス提供装置１００に転送する（図１の（５）参照）。

そして、サービス提供装置１００は、ＳＩＰプロキシから受信したＩＮＶＩＴＥに含まれる一時アドレスが仮登録しておいた一時アドレスと一致する場合に、該ＩＮＶＩＴＥから電話番号（ＳＩＰ−ＵＲＩ（Uniform Resource Identifier））を取得し、取得した電話番号と該一時アドレスに対応付けて仮登録されるＩＰアドレスとを対応付けて登録する（図１の（６）参照）。その後、サービス提供装置１００は、ＳＩＰプロキシ３００を介してＩＮＶＩＴＥに対する応答（２００ ＯＫ）を端末２００のＳＩＰフォン機能に送信する（図１の（７）参照）。

また、上記（１）〜（７）までの処理は、サービス提供装置１００と端末４００との間でも実施される。したがって、サービス提供装置１００は、端末４００のＳＩＰフォン機能が利用する電話番号と、端末４００の情報表示機能が使用するＩＰｖ６表記のＩＰアドレスとを対応付けて登録することができる。

その後、サービス提供装置１００は、端末２００のＳＩＰフォン機能と端末４００のＳＩＰフォン機能とがＳＩＰ接続中であることを条件に、つまり、アドホックな関係にあることを条件に、端末２００の情報表示機能と端末４００の情報表示機能との間にやり取りされるＷｅｂサービスを制御するのに際して、ＩＰアドレスによる認証を実施する（図１の（８）参照）。

具体的には、サービス提供装置１００は、端末２００の情報表示機能及び端末４００の情報表示機能の各々に、Ｗｅｂサービスを一意に識別するＷｅｂセッション情報を払出すのに際して、図１の（６）で登録したＩＰアドレスからのアクセスであるか否かを判定する。そして、サービス提供装置１００は、図１の（６）で登録したＩＰアドレスからのアクセスに対して、Ｗｅｂセッション情報を払出す。その後の一時的な通信関係（アドホックに変化する関係）に基づいてサービスを制御する例については、後述するので、ここでは省略する。

このように、実施例１に係るサービス提供システムでは、一時的な通信関係に基づいてサービスを制御する前処理として、実際に使用されるＩＰアドレスと電話番号との対応付けを登録することができる。この結果、一時的な通信関係に基づいてサービスを制御するのに際して、サービスを利用する端末の性能やＩＰアドレスの体系に関係なく、一時的な通信関係に基づいてサービスを提供することが可能である。

［サービス提供システムの構成］
次に、図２〜図７を用いて、サービス提供システムが有する各装置の構成について説明する。ここでは、ユーザ宅の端末構成がいずれもＳＩＰフォン機能と情報表示機能との一体型である場合を想定し、また、ＳＩＰプロキシが汎用的なＳＩＰプロキシである場合を想定するので、以下では、サービス提供装置および一方の端末についてのみ説明する。

（サービス提供装置の構成）
図２を用いて、サービス提供システムにおけるサービス提供装置の構成を説明する。図２は、実施例１に係るサービス提供装置の構成を示すブロック図である。図２に示すように、サービス提供装置１００は、通信制御Ｉ／Ｆ部１１０と記憶部１２０と制御部１３０とを有する。

通信制御Ｉ／Ｆ部１１０は、ＨＴＴＰ（HyperText Transfer Protocol）通信用の一般的なインタフェースおよびライブラリを備え、端末２００との間で情報を送受信する。具体的には、通信制御Ｉ／Ｆ部１１０は、後述するｃａｌｌセッション情報受信部１３２が端末２００からcallセッション情報を受信する通信や、後述するＷｅｂセッション情報払出部１３４が端末２００にＷｅｂセッション情報を送信する通信や、後述するサービス提供部１３６が端末２００にサービスを提供する通信などを行う。なお、実施例１においては、上記したいずれの通信もＨＴＴＰで行われるものとして説明するが、中でも、サービス提供部１３６による通信はＷｅｂサービスに関係する通信であるという意味で、「Ｗｅｂ通信」と呼ぶ。

記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶する半導体メモリ素子やハードディスクなどの記憶装置である。このような記憶部１２０は、図２に示すように、仮登録ＤＢ１２１とユーザ管理ＤＢ１２２とセッション情報ＤＢ１２３を有する。

仮登録ＤＢ１２１は、ユーザ宅の端末が使用するＩＰアドレスと電話番号とが対応付けて登録される前に、Ｗｅｂブラウザ等によるＨＴＴＰアクセスから取得したユーザ宅の端末のＩＰアドレスを記憶する。そして、仮登録ＤＢ１２１は、記憶するＩＰアドレスが電話番号と対応付けられて、ユーザ管理ＤＢ１２２に記憶された場合に、該ＩＰアドレスを消去する。

例えば、仮登録ＤＢ１２１は、図３に示すように、「ＩＤ、電話番号、ＩＰアドレス、登録プロトコル、一時アドレス」を対応付けて記憶する。「ＩＤ」は、レコードを識別する識別子であり、「電話番号」は、ユーザ宅の端末が使用するＩＰアドレスと電話番号とが対応付けて登録される前に、ＳＩＰ通信等から取得されたユーザ宅（送信元）の電話番号が格納される。「ＩＰアドレス」は、ユーザ宅の端末が使用するＩＰアドレスと電話番号とが対応付けて登録される前に、Ｗｅｂブラウザ等によるＨＴＴＰアクセスから取得されたＩＰアドレスが格納される。「登録プロトコル」は、ＩＰアドレス又は電話番号を取得したプロトコルを示す。「一時アドレス」は、「ＩＰアドレス」に記憶されるＩＰアドレスを一意に識別する識別子であり、どのような情報であってもよい。

具体的には、仮登録ＤＢ１２１は、通常、図３の（ａ）に示すように、いずれに情報も記憶していない。そして、仮登録ＤＢ１２１は、図３の（ｂ）に示すように、後述するＩＰアドレス対応付け部１３１によってＷｅｂブラウザによるアクセスからＩＰアドレスが取得された場合に、一意なＩＤを生成して、取得されたＩＰアドレスに関する情報を記憶する。その後、仮登録ＤＢ１２１は、図３の（ｃ）に示すように、後述するＩＰアドレス対応付け部１３１によって、電話番番号と対応付けられるＩＰアドレスに関する情報を消去する。なお、図３に示す各情報は、説明の便宜上から特定の数字を示したものに過ぎず、数字に何ら特別の意味があるものではない。また、図３は、仮登録ＤＢに記憶される情報の例を示す図である。

ユーザ管理ＤＢ１２２は、ユーザ宅で利用される電話番号とＩＰアドレスとの対応付けを記憶する。例えば、ユーザ管理ＤＢ１２２は、図４に示すように、「ＩＤ、電話番号、ＩＰアドレス、登録日時」を記憶する。「ＩＤ」は、レコードを一意に識別する識別子である。「電話番号」は、ユーザ宅が利用する電話番号であり、「ＩＰアドレス」は、ユーザ宅が利用するＩＰアドレスであり、「登録日時」は、電話番号とＩＰアドレスとの対応付けが登録された日である。

具体的には、ユーザ管理ＤＢ１２２は、後述するＩＰアドレス対応付け部１３１によって対応づけられて格納されるまで、図４の（ａ）に示すように、いずれの情報も記憶していない。そして、ＩＰアドレス対応付け部１３１が、仮登録ＤＢ１２１に記憶されるＩＰアドレスを利用する端末２００の電話番号であると判定したとする。その場合に、ユーザ管理ＤＢ１２２は、図４の（ｂ）に示すように、仮登録ＤＢ１２１に記憶されるＩＰアドレスと電話番号とを対応付け、さらに記憶した日をあわせて記憶する。なお、図４に示す各情報は、説明の便宜上から特定の数字を示したものに過ぎず、数字に何ら特別の意味があるものではない。また、図４は、ユーザ管理ＤＢに記憶される情報の例を示す図である。

セッション情報ＤＢ１２３は、Ｗｅｂセッション情報をｃａｌｌセッション情報と対応づけて記憶する。具体的には、セッション情報ＤＢ１２３は、まず、後述するｃａｌｌセッション情報受信部１３２によって受信されたｃａｌｌセッション情報を記憶し、次に、後述するＷｅｂセッション情報払出部１３４によって払い出されたＷｅｂセッション情報をｃａｌｌセッション情報と対応づけて記憶する。また、セッション情報ＤＢ１２３が記憶したこれらのセッション情報は、後述するサービス提供部１３６による処理に利用されるなどする。

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

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

セッション情報ＤＢ１２３の説明に戻ると、セッション情報ＤＢ１２３は、例えば、図５に示すように、ｃａｌｌセッション情報とＷｅｂセッション情報との対応づけを記憶する。すなわち、後述するｃａｌｌセッション情報受信部１３２によって一方の端末２００からｃａｌｌセッション情報『１００』が受信されると、セッション情報ＤＢ１２３は、図５の（ａ）に示すように、ｃａｌｌセッション情報『１００』を記憶する。次に、後述するＷｅｂセッション情報払出部１３４によってＷｅｂセッション情報『１２３』が払い出されると、セッション情報ＤＢ１２３は、図５の（ｂ）に示すように、Ｗｅｂセッション情報『１２３』をｃａｌｌセッション情報『１００』に対応づけて記憶する。同様に、セッション情報ＤＢ１２３は、他方の端末２００についても、図５の（ｃ）に示すように、ｃａｌｌセッション情報『１００』を記憶し、図５の（ｄ）に示すように、Ｗｅｂセッション情報『４５６』をｃａｌｌセッション情報『１００』に対応づけて記憶する。その後、後述するサービス提供部１３６による関連づけが行われると、セッション情報ＤＢ１２３は、図５の（ｅ）に示すように、関連づけを記憶する。なお、図５に示すｃａｌｌセッション情報やＷｅｂセッション情報は、説明の便宜上から特定の数字を示したものに過ぎず、数字に何ら特別の意味があるものではない。また、図５は、セッション情報ＤＢに記憶する情報の例を示す図である。

また、セッション情報ＤＢ１２３は、ｃａｌｌセッション情報『１００』とＷｅｂセッション情報『１２３』とを対応づけて格納するだけでなく、図６に示すように、ｃａｌｌセッション情報としての発側ＩＰアドレス『10.0.10.111』と着側ＩＰアドレス『10.0.10.199』とを対応づけて格納してもよい。さらに、セッション情報ＤＢ１２３は、端末２００が使用するＷｅｂ通信上のＩＰアドレス『2001:fa:1001:2400::1』も対応づけて格納してもよい。

ここで記憶される「ｃａｌｌセッション情報」は、ＳＩＰ通信であることを示すセッション情報であり、「Ｗｅｂセッション情報」は、Ｗｅｂ通信であることを示すセッション情報である。「発側ＩＰアドレス」は、ＩＰアドレス対応付け部１３１によって、ＳＩＰ通信における発側のＳＤＰ（Session Description Protocol）から取得された、ＳＩＰ通信で使用されるＩＰアドレスである。「着側ＩＰアドレス」は、ＩＰアドレス対応付け部１３１によって、ＳＩＰ通信における着側のＳＤＰから取得された、ＳＩＰ通信で使用されるＩＰアドレスである。「Ｗｅｂ通信のＩＰアドレス」は、「発側ＩＰアドレス」又は「着側ＩＰアドレス」に記憶されるＩＰアドレスをＳＩＰ通信で利用する端末がＷｅｂ通信で利用する際のＩＰアドレスである、なお、図６に示すｃａｌｌセッション情報やＷｅｂセッション情報は、説明の便宜上から特定の数字を示したものに過ぎず、数字に何ら特別の意味があるものではない。また、図６は、セッション情報ＤＢに記憶する情報の例を示す図である。

図２に戻り、制御部１３０は、集積回路又はＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路である。この制御部１３０は、ＩＰアドレス対応付け部１３１と、ｃａｌｌセッション情報受信部１３２と、認証実行部１３３と、Ｗｅｂセッション情報払出部１３４と、関連づけ部１３５と、サービス提供部１３６とを有する。

ＩＰアドレス対応付け部１３１は、ユーザ宅間でアドホックに変化する関係に基づいてサービスを制御する前段階として、ユーザ宅で利用する電話番号とＩＰアドレスとの対応付けを実施してユーザ管理ＤＢ１２２に記憶する。例えば、ＩＰアドレス対応付け部１３１は、ユーザ宅の端末からＨＴＴＰによるアクセスを受け付けると、該アクセスからＩＰアドレスを取得するとともに、取得したＩＰアドレスに対して一時アドレスを発行する。そして、ＩＰアドレス対応付け部１３１は、アクセス元の端末に一時アドレスを送信するとともに、取得したＩＰアドレスと発行した一時アドレスとを対応付けて仮登録ＤＢ１２１に格納する。

その後、ＩＰアドレス対応付け部１３１は、一時アドレスを含むＳＩＰ通信におけるＩＮＶＩＴＥをユーザ宅の端末から受信した場合に、該一時アドレスが仮登録ＤＢ１２１に登録されているか否かを判定する。そして、ＩＰアドレス対応付け部１３１は、一時アドレスが仮登録ＤＢ１２１に登録されている場合に、仮登録ＤＢ１２１に登録されている「ＩＰアドレス」とＳＩＰ通信に含まれる「電話番号」とを対応付けて、ユーザ管理ＤＢ１２２に格納する。この際、ＩＰアドレス対応付け部１３１は、仮登録ＤＢ１２１の情報を削除する。また、ＩＰアドレス対応付け部１３１は、ＳＩＰ通信のＳＤＰ等に含まれるＩＰアドレス、すなわち、ＳＩＰ通信上で利用されるＩＰアドレスもさらに対応付けて記憶してもよい。

ｃａｌｌセッション情報受信部１３２は、ｃａｌｌセッション情報を受信する。具体的には、ｃａｌｌセッション情報受信部１３２は、ＳＩＰによって通信を確立した端末２００から送信されたｃａｌｌセッション情報を受信することで、ｃａｌｌセッション情報を取得する。また、ｃａｌｌセッション情報受信部１３２は、受信したｃａｌｌセッション情報を、セッション情報ＤＢ１２３に格納する。また、ｃａｌｌセッション情報受信部１３２は、端末２００からｃａｌｌセッション情報を受信する場合に、該端末２００で使用されるＩＰアドレスもあわせて受信する。そして、ｃａｌｌセッション情報受信部１３２は、受信したＩＰアドレスを認証実行部１３３に送信する。

認証実行部１３３は、ＩＰアドレスによる認証を実施し、認証を許可した場合には、その旨をＷｅｂセッション情報払出部１３４に伝達し、認証を拒否した場合には、認証拒否を端末２００に伝達する。例えば、認証実行部１３３は、ｃａｌｌセッション情報受信部１３２がｃａｌｌセッション情報を受信したＩＰアドレスと当該ｃａｌｌセッション情報に含まれる電話番号とがユーザ管理ＤＢ１２２に記憶されている場合に、認証を許可し、ユーザ管理ＤＢ１２２に記憶されていない場合に、認証を拒否する。

また、セッション情報ＤＢ１２３が、図６に示すように、「ｃａｌｌセッション情報」と「Ｗｅｂ通信のＩＰアドレス」とを対応付けて記憶しているとする。この場合、認証実行部１３３は、ｃａｌｌセッション情報受信部１３２が受信したｃａｌｌセッション情報とＩＰアドレスとの組がセッション情報ＤＢ１２３に記憶されているか否かによる認証を行ってもよい。

Ｗｅｂセッション情報払出部１３４は、認証実行部１３３によって認証が許可された場合に、認証が許可された端末に対してＷｅｂセッション情報を払い出す。具体的には、Ｗｅｂセッション情報払出部１３４は、ｃａｌｌセッション情報受信部１３２によってｃａｌｌセッション情報が受信されると、当該ｃａｌｌセッション情報を送信した端末２００が行うＷｅｂ通信（サービス提供を受けるために端末２００がサービス提供装置１００との間で行うＷｅｂ通信）に付与する情報として、Ｗｅｂセッション情報を払い出す。また、Ｗｅｂセッション情報払出部１３４は、払い出したＷｅｂセッション情報を、端末２００に送信する。

関連づけ部１３５は、Ｗｅｂセッション情報をｃａｌｌセッション情報に対応づけて格納する。具体的には、関連づけ部１３５は、Ｗｅｂセッション情報払出部１３４によって払い出されたＷｅｂセッション情報を、ｃａｌｌセッション情報受信部１３２によって取得されたｃａｌｌセッション情報に対応づけてセッション情報ＤＢ１２３に格納する。

サービス提供部１３６は、サービスを制御する。具体的には、サービス提供部１３６は、セッション情報ＤＢ１２３に格納されているＷｅｂセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する。

例えば、サービス提供部１３６は、図５の（ｄ）および（ｅ）に示すように、セッション情報ＤＢ１２３によって記憶されている複数のｃａｌｌセッション情報の内、２つのｃａｌｌセッション情報『１００』各々が、ＳＩＰによって同一の通信として確立されたものであることを判別する。そして、サービス提供部１３６は、ｃａｌｌセッション情報『１００』に対応づけて記憶されているＷｅｂセッション情報『１２３』が付与されたＷｅｂ通信と、Ｗｅｂセッション情報『４５６』が付与されたＷｅｂ通信とを用いて提供されるサービスを、互いに関連づけて制御する。

すなわち、例えば、他方の端末２００が、Ｗｅｂセッション情報『４５６』が付与されたＷｅｂ通信によってサービス提供装置１００にアクセスしている際に、一方の端末２００が、Ｗｅｂセッション情報『１２３』が付与されたＷｅｂ通信によってサービス提供装置１００に画像データをアップロードしたとする。このような場合、端末２００各々の関係は、ＳＩＰによって同一の通信を確立した関係であるので、この関係は、画像データの共有を互いに認めている関係であるとして、実施例１におけるサービス提供部１３６は、他方の端末２００に画像データを送信するよう、サービスを制御する。

ここで、改めて、サービス提供装置１００によるサービス提供について考える。すなわち、サービス提供装置１００によるサービス提供が、端末２００各々の関係に基づいて制御される点は、従来のサービス提供装置と同様であるが、実施例１におけるサービス提供装置１００が、「端末２００各々の関係」をどのように把握しているかが重要である。

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

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

（端末２００の構成）
次に、図７を用いて、ユーザ端末である端末２００の構成について説明する。図７は、実施例１に係る端末の構成を示すブロック図である。端末２００は、以下に説明する各部が汎用的なＰＣ（Personal Computer）などに備えられることによって実現され、図７に示すように、入力部２０１と、出力部２０２と、入出力制御Ｉ／Ｆ部２０３と、ＳＩＰフォン機能部２１０と、情報表示機能部２２０とを有する。

入力部２０１は、ＳＩＰフォン機能部２１０や情報表示機能部２２０に用いられる情報や、各種処理をするための操作指示などを、番号キー、キーボード、マウス、マイクなどによって入力する。例えば、入力部２０１は、他方の端末２００との間でＳＩＰによって通信を確立するにあたり、ＳＩＰ−ＵＲＩの元になる電話番号を、キーボードによって入力するなどする。

出力部２０２は、ＳＩＰフォン機能部２１０や情報表示機能部２２０による各種処理の結果や、各種処理をするための操作指示などを、ディスプレイ、プリンタ、スピーカなどに出力する。例えば、出力部２０２は、後述するサービス利用部２２５によってサービス提供装置１００からサービス提供を受けた際に、当該サービスの内容をディスプレイに表示するなどする。

入出力制御Ｉ／Ｆ部２０３は、入力部２０１と、出力部２０２と、ＳＩＰフォン機能部２１０と、情報表示機能部２２０との間における情報転送を制御する。

ＳＩＰフォン機能部２１０は、端末２００において、ＳＩＰによって通信を確立する過程の通信（ＳＩＰ通信）や、ＳＩＰによって確立された通信を行う部であり、特に本発明に密接に関連するものとしては、図７に示すように、ＳＩＰ通信部２１１と、制御部２１２とを備える。

ＳＩＰ通信部２１１は、ＳＩＰ用の一般的なインタフェースおよびライブラリを備え、他方の端末２００との間で（ＳＩＰ ＰＲＯＸＹを介するなどして）情報を送受信する。具体的には、ＳＩＰ通信部２１１は、他方の端末２００との間でＳＩＰによって確立される通信の情報などを送受信する。また、ＳＩＰ通信部２１１は、ユーザから一時アドレスの入力を受け付けた場合に、入力された一時アドレスを含めたＳＩＰ接続要求等をＳＩＰプロキシに送信する。

制御部２１２は、ＳＩＰフォン機能部２１０における各種制御を行う集積回路又はＣＰＵやＭＰＵなどの電子回路である。この制御部２１２は、図７に示すように、ｃａｌｌセッション情報収集部２１３と、起動指示部２１４とを備える。

ｃａｌｌセッション情報収集部２１３は、ｃａｌｌセッション情報を収集する。具体的には、ｃａｌｌセッション情報収集部２１３は、他方の端末２００との間でＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を、ＳＩＰ通信に含まれる情報から収集する。また、ｃａｌｌセッション情報収集部２１３は、収集したｃａｌｌセッション情報を、起動指示部２１４に伝達する。例えば、ｃａｌｌセッション情報収集部２１３は、ｃａｌｌセッション情報としては、ＳＩＰ通信に含まれる『Call-ID』、または、『From』、『To』、『tag』、ＩＰアドレス、もしくは、これらの組合せを収集したり、ＳＩＰ通信に含まれるその他の情報を収集する。なお、ｃａｌｌセッション情報は、ＳＩＰによって確立された通信を一意に識別することが可能な情報であれば、どのような情報であってもよい。

起動指示部２１４は、情報表示機能部２２０を起動する指示を行う。具体的には、起動指示部２１４は、ｃａｌｌセッション情報収集部２１３によってｃａｌｌセッション情報を伝達されると、情報表示機能部２２０を起動する指示（情報表示機能部２２０が起動している場合には、後述するｃａｌｌセッション情報送信部２２３を起動する指示など）を行うとともに、サービス提供装置１００のＵＲＬ（Uniform Resource Locator）やｃａｌｌセッション情報をｃａｌｌセッション情報送信部２２３に伝達する。

情報表示機能部２２０は、端末２００において、ＨＴＴＰ通信を行うブラウザであり、特に、図７に示すように、ＨＴＴＰ通信部２２１と、制御部２２２とを備える。ＨＴＴＰ通信部２２１は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、サービス提供装置１００との間で情報を送受信する。具体的には、ＨＴＴＰ通信部２２１は、後述するｃａｌｌセッション情報送信部２２３からサービス提供装置１００にｃａｌｌセッション情報を送信する通信や、後述するＷｅｂセッション情報受信部２２４がサービス提供装置１００からＷｅｂセッション情報を受信する通信や、後述するサービス利用部２２５がサービス提供装置１００からサービス提供を受ける通信などを行う。

制御部２２２は、情報表示機能部２２０における各種制御を行う集積回路又はＣＰＵやＭＰＵなどの電子回路である。この制御部２２２は、図７に示すように、ｃａｌｌセッション情報送信部２２３と、Ｗｅｂセッション情報受信部２２４と、サービス利用部２２５とを備える。

ｃａｌｌセッション情報送信部２２３は、ｃａｌｌセッション情報を送信する。具体的には、ｃａｌｌセッション情報送信部２２３は、起動指示部２１４からサービス提供装置１００のＵＲＬやｃａｌｌセッション情報を伝達されると、ＵＲＬで示されるサービス提供装置１００にｃａｌｌセッション情報を送信する。なお、実施例１においては、端末２００がサービス提供装置１００のＵＲＬを予め記憶部に記憶していることで、ｃａｌｌセッション情報送信部２２３が当該ＵＲＬで示されるサービス提供装置１００にｃａｌｌセッション情報を送信する。

Ｗｅｂセッション情報受信部２２４は、Ｗｅｂセッション情報を受信する。具体的には、Ｗｅｂセッション情報受信部２２４は、サービス提供装置１００からＷｅｂセッション情報を受信する。また、Ｗｅｂセッション情報受信部２２４は、受信したＷｅｂセッション情報を、サービス利用部２２５に伝達する。

サービス利用部２２５は、サービス提供装置１００によって提供されるサービスの提供を受け、サービスを利用する。具体的には、サービス利用部２２５は、Ｗｅｂセッション情報受信部２２４によって伝達されたＷｅｂセッション情報を、ＨＴＴＰ通信を行うブラウザに付与し、サービス提供を受けるために、サービス提供装置１００との間でＷｅｂ通信を行う。

［処理の流れ］
次に、図８を用いて、サービス提供システムの処理シーケンスを説明する。図８は、実施例１に係るサービス提供システムによる処理の流れを示すシーケンス図である。

（シーケンス）
図８に示すように、端末２００の情報表示機能は、サービス提供装置１００に対してＷｅｂアクセスを実施する（ステップＳ１０１）。続いて、サービス提供装置１００のＩＰアドレス対応付け部１３１は、受け付けたＷｅｂアクセスからＩＰアドレスを取得し、取得したＩＰアドレスに対して一意な一時アドレスを払出すとともに、該ＩＰアドレスと一時アドレスとを対応付けて仮登録ＤＢ１２１に格納する（ステップＳ１０２）。その後、サービス提供装置１００のＩＰアドレス対応付け部１３１は、アクセス元である端末２００の情報表示機能に対して、払い出した一時アドレスを応答する（ステップＳ１０３）。

その後、端末２００のＳＩＰフォン機能は、情報表示機能によって受信された一時アドレスの入力をユーザから受け付ける（ステップＳ１０４）。続いて、端末２００のＳＩＰフォン機能は、ＳＩＰプロキシ３００を介して、サービス提供装置１００を接続先とするＳＩＰ接続要求（ＩＮＶＩＴＥ）を送信する（ステップＳ１０５）。

そして、サービス提供装置１００のＩＰアドレス対応付け部１３１は、端末２００のＳＩＰフォン機能から受信したＩＮＶＩＴＥに含まれる一時アドレスに一致するＩＰアドレスを仮登録ＤＢ１２１から取得し、取得したＩＰアドレスとＩＮＶＩＴＥに含まれる電話番号（ＳＩＰ−ＵＲＩ）とを対応付けて、ユーザ管理ＤＢ１２２に格納する（ステップＳ１０６）。その後、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ＩＮＶＩＴＥに対する応答（２００ ＯＫ）を端末２００のＳＩＰフォン機能に送信する（ステップＳ１０７）。

上述したＳ１０１〜Ｓ１０７の処理は、端末４００とサービス提供装置１００との間でも同様に実行される（ステップＳ１０８〜ステップＳ１１４）。したがって、サービス提供装置１００は、端末２００及び端末４００の各々に対して、電話番号とＩＰアドレスとの組をユーザ管理ＤＢ１２２に格納することができる。なお、端末２００と端末４００の処理順序は同じタイミングになってもよいし、異なるタイミングになってもよい。

その後、端末２００および端末４００各々のＳＩＰ通信部２１１間で、ステップＳ１１５〜ステップＳ１２０のＳＩＰ通信がＳＩＰプロキシ３００を介して行われ、その結果、ステップＳ１２１において、端末２００および端末４００間でＳＩＰによって通信が確立される。なお、ＳＩＰ通信におけるDigest認証やREGISTER処理などについては図示していないが、一般的なＳＩＰ通信と同様、ステップＳ１１５よりも前に行われている。

両端末間でＳＩＰによって通信が確立されると、端末２００のｃａｌｌセッション情報収集部２１３は、端末４００との間でＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を、ＳＩＰ通信に含まれる情報から収集する（ステップＳ１２２）。そして、端末２００の起動指示部２１４は、情報表示機能部２２０を起動する指示を行うとともに、サービス提供装置１００のＵＲＬやｃａｌｌセッション情報を、情報表示機能部２２０のｃａｌｌセッション情報送信部２２３に伝達する（ステップＳ１２３、ステップＳ１２４）。すると、ｃａｌｌセッション情報送信部２２３は、ＵＲＬで示されるサービス提供装置１００にｃａｌｌセッション情報を送信する（ステップＳ１２５）。

同様に、端末４００のｃａｌｌセッション情報収集部２１３は、端末２００との間でＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を、ＳＩＰ通信に含まれる情報から収集する（ステップＳ１２６）。そして、端末４００の起動指示部２１４は、情報表示機能部２２０を起動する指示を行うとともに、サービス提供装置１００のＵＲＬやｃａｌｌセッション情報を、情報表示機能部２２０のｃａｌｌセッション情報送信部２２３に伝達する（ステップＳ１２７、ステップＳ１２８）。すると、ｃａｌｌセッション情報送信部２２３は、ＵＲＬで示されるサービス提供装置１００にｃａｌｌセッション情報を送信する（ステップＳ１２９）。なお、端末２００と端末４００の処理順序は同じタイミングになってもよいし、異なるタイミングになってもよい。

ここで、ＳＩＰ通信に含まれる情報について、図９および図１０を用いて説明する。図９および図１０は、ＳＩＰメッセージを説明するための図であり、図９は、リクエストメッセージを示し、図１０は、レスポンスメッセージを示す。

ＳＩＰメッセージには、スタートラインと呼ばれる部分と、ヘッダと呼ばれる部分と、ボディと呼ばれる部分とがある。図９に示すリクエストメッセージの例では、「INVITE」の行がスタートラインにあたり、「Via」の行から「Content-Length」の行までがヘッダにあたり、「v=0」の行から「a=rtpmap:0 PCMU/8000」の行までがボディにあたる。ボディは、図９に示すように、ＳＤＰ（Session Description Protocol）と呼ばれる書式で記載され、ここに、ＳＩＰメッセージの発信元のＩＰアドレスが記載される。

例えば、図９に示すリクエストメッセージのＳＤＰには、リクエストメッセージを発信したＳＩＰフォンのＩＰアドレス「10.0.10.111」が記載されている。同様に、図１０に示すレスポンスメッセージのＳＤＰには、レスポンスメッセージを発信したＳＩＰフォンのＩＰアドレス「10.0.10.199」が記載されている。このように、ＳＩＰメッセージには、ＳＩＰメッセージの発信元のＩＰアドレスが含まれている。

図８に戻り、サービス提供装置１００の認証実行部１３３は、端末２００がＷｅｂアクセスで利用するＩＰアドレスがユーザ管理ＤＢ１２２に記憶されているか否か、また、端末４００がＷｅｂアクセスで利用するＩＰアドレスがユーザ管理ＤＢ１２２に記憶されているか否かを認証するＩＰアドレスによる認証を実行する（ステップＳ１３０）。

サービス提供装置１００のｃａｌｌセッション情報受信部１３２が、端末２００から送信されたｃａｌｌセッション情報を受信すると、続いて、Ｗｅｂセッション情報払出部１３４が、当該ｃａｌｌセッション情報を送信した端末２００が行うＷｅｂ通信（サービス提供を受けるために端末２００がサービス提供装置１００との間で行うＷｅｂ通信）に付与する情報として、Ｗｅｂセッション情報を払い出し（ステップＳ１３１）、払い出したＷｅｂセッション情報を端末２００に送信する（ステップＳ１３２）。同様に、Ｗｅｂセッション情報払出部１３４は、端末４００に対してもＷｅｂセッション情報を払い出す（ステップＳ１３３）。

次に、サービス提供装置１００の関連づけ部１３５は、ステップＳ１３１及びステップＳ１３３において端末２００について払い出されたＷｅｂセッション情報を、ステップＳ１２５において端末２００について取得されたｃａｌｌセッション情報及びステップＳ１２９において端末４００について取得されたｃａｌｌセッション情報に対応づけてセッション情報ＤＢ１２３に格納する（ステップＳ１３４）。

そして、サービス提供装置１００のサービス提供部１３６は、セッション情報ＤＢ１２３に格納されている複数のｃａｌｌセッション情報の内、所定のｃａｌｌセッション情報各々がＳＩＰによって同一の通信として確立されたものであることを示す場合に、当該ｃａｌｌセッション情報各々に対応づけて格納されているＷｅｂセッション情報各々を用いて提供されるサービスを、互いに関連づけて制御する（ステップＳ１３５〜Ｓ１３８）。

なお、図８に示す『マッチング』とは、サービス提供部１３６が、ｃａｌｌセッション情報各々について、ＳＩＰによって同一の通信として確立されたものであるか否かを判別することを意味する。また、サービス提供部１３６が、端末２００及び端末４００各々のＷｅｂ通信に付与されたＷｅｂセッション情報各々を、互いに関連づけることで、端末２００及び端末４００各々のＷｅｂ通信を、ＳＩＰによって同一の通信が確立された関係として扱うことを意味する。

こうして、サービス提供装置１００のサービス提供部１３６は、ステップＳ１３４において行われた関連づけに基づいて、サービスを制御する。

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

（ＩＰアドレスによる認証）
次に、図１１を用いて、図８に示したステップＳ１３０に該当するＩＰアドレスによる認証処理を説明する。図１１は、ＩＰアドレスによる認証処理を示すフローチャートである。

図１１に示すように、サービス提供装置１００の認証実行部１３３は、ｃａｌｌセッション情報受信部１３２によって、端末２００のＩＰアドレスが受信されると（ステップＳ２０１肯定）、受信したＩＰアドレスがユーザ管理ＤＢ１２２に記憶されているＩＰアドレスと一致するか否かを判定する（ステップＳ２０２）。すなわち、認証実行部１３３は、図８のステップＳ１２５でｃａｌｌセッション情報を受信したＷｅｂアクセスからＩＰアドレスを取得し、取得したＩＰアドレスとｃａｌｌセッション情報に含まれる電話番号との組み合わせがユーザ管理ＤＢ１２２に記憶されているか否かを判定する。つまり、認証実行部１３３は、取得したＩＰアドレスとｃａｌｌセッション情報に含まれる電話番号との組み合わせが事前に登録されている情報であるか否かを判定する。

認証実行部１３３は、取得したＩＰアドレスと電話番号とがユーザ管理ＤＢ１２２に記憶されている場合に（ステップＳ２０２肯定）、認証を許可して、Ｗｅｂセッション情報を許可した端末２００に払い出す（ステップＳ２０３）。

一方、認証実行部１３３は取得したＩＰアドレスと電話番号とがユーザ管理ＤＢ１２２に記憶されていない場合に（ステップＳ２０２否定）、認証を拒否して、認証エラーを端末２００に送信する（ステップＳ２０４）。

また、認証実行部１３３が認証する手法はこれに限定されるものではない。例えば、認証実行部１３３は、ｃａｌｌセッション情報受信部１３２が受信したｃａｌｌセッション情報そのものと該ｃａｌｌセッション情報を受信したＷｅｂアクセスから取得したＩＰアドレスとの組が、セッション情報ＤＢ１２３に記憶されているか否かによる認証を行ってもよい。また、認証実行部１３３は、ｃａｌｌセッション情報を受信したＷｅｂアクセスから取得したＩＰアドレスが、セッション情報ＤＢ１２３に記憶されているか否かによる認証を行ってもよい。

［実施例１による効果］
このように、実施例１によれば、一時的な通信関係に基づいてサービスを制御する前処理として、実際に使用されるＩＰアドレスと電話番号との対応付けを登録することができる。この結果、一時的な通信関係に基づいてサービスを制御するのに際して、サービスを利用する端末の性能やＩＰアドレスの体系に関係なく、ＩＰアドレスによる認証を実施することが可能である。

事前に、Ｗｅｂ通信で使用されるＩＰアドレスとＳＩＰ通信で使用される電話番号、ＩＰアドレスなどを対応付けて記憶することができる。この結果、ＳＩＰ通信で使用されるＩＰアドレスがＩＰｖ４表記であり、Ｗｅｂ通信で使用されるＩＰアドレスがＩＰｖ６表記である場合でも、ＩＰアドレスによる認証を実施することが可能である。また、端末２００等の情報表示機能に、ＳＩＰを処理するためのスタックなど特別な機能を組み込む必要もなく、ＩＰアドレスによる認証を実施することが可能である。

ところで、本願の開示するサービス提供システムは、ＨＧＷを用いた構成であってもよい。具体的には、ＳＩＰプロキシ３００と端末２００との間にＨＧＷ５００を有し、ＳＩＰプロキシ３００と端末４００との間にＨＧＷ６００を有していてもよい。さらに、端末２００及び端末４００がＳＩＰフォン２５０と情報表示端末２６０とのように別々の筐体で実現されていてもよい。

そこで、実施例２では、ＨＧＷ５００およびＨＧＷ６００を有するとともに、端末２００及び端末４００がＳＩＰフォン２５０と情報表示端末２６０とのように別々の筐体で実現されているサービス提供システムについて説明する。

［ＨＧＷ、ＳＩＰフォン、情報表示端末の構成］
まず、図１２を用いて、実施例２のサービス提供システムが有するＨＧＷ、ＳＩＰフォン、情報表示端末のそれぞれの構成について説明する。図１２は、実施例２に係るＨＧＷ、ＳＩＰフォン、情報表示端末のそれぞれの構成を示すブロック図である。

なお、ＳＩＰプロキシ３００と端末２００との間に設置するＨＧＷ５００と、ＳＩＰプロキシ３００と端末４００との間に設置するＨＧＷ６００とは、同様の構成を有するので、ここではＨＧＷ５００についてのみ説明する。また、端末４００が有するＳＩＰフォンと情報表示端末についても、端末２００と同様の機能を有するので、ここでは、端末２００が有するＳＩＰフォン２５０と情報表示端末２６０についてのみ説明する。

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

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

記憶部５２０は、制御部５３０における各種制御に用いられる情報を記憶する半導体メモリ素子やハードディスクなどの記憶装置であり、特に、図１２に示すように、ブラウザセッション情報ＤＢ５２１を有する。

ブラウザセッション情報ＤＢ５２１は、配下の情報表示端末２６０に割り当てられたブラウザセッション情報を予め記憶する。具体的には、ブラウザセッション情報ＤＢ５２１は、ＳＩＰフォン２５０を一意に識別する情報（ＳＩＰフォンＩＤ）と、当該ＳＩＰフォン２５０と組で利用される情報表示端末２６０を一意に識別する情報（情報表示端末ＩＤ）と、当該情報表示端末２６０を特定するためのブラウザセッション情報とを対応づけて予め記憶する。また、ブラウザセッション情報ＤＢ５２１が記憶するこれらの情報は、後述する情報表示端末特定部５３３による処理に利用されるなどする。なお、ＳＩＰフォンと情報表示端末とが「組で利用される」状況としては、例えば、ＳＩＰフォンと情報表示端末とが同じ利用者によって利用される場合などが想定される。

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

ブラウザセッション情報ＤＢ５２１の説明に戻ると、ブラウザセッション情報ＤＢ５２１は、例えば、図１３に示すように、ＳＩＰフォンＩＤと情報表示端末ＩＤとブラウザセッション情報との対応づけを記憶する。なお、図１３に示すＳＩＰフォンＩＤや情報表示端末ＩＤやブラウザセッション情報は、説明の便宜上から特定の数字を示したものに過ぎず、数字に何ら特別の意味があるものではない。また、図１３は、ブラウザセッション情報ＤＢに記憶される情報の例を示す図である。

図１２に戻り、制御部５３０は、ＨＧＷ５００における各種制御を行う集積回路又はＣＰＵやＭＰＵなどの電子回路であり、図１２に示すように、ｃａｌｌセッション情報収集部５３１と、ＳＩＰフォンＩＤ収集部５３２と、情報表示端末特定部５３３と、アクセス先変更指示部５３４とを有する。また、図１２の点線は、ｃａｌｌセッション情報収集部５３１およびＳＩＰフォンＩＤ収集部５３２が、ＳＩＰフォン２５０に関連して処理が行われる部であり、情報表示端末特定部５３３およびアクセス先変更指示部５３４が、情報表示端末２６０に関連して処理が行われる部であることを、説明の便宜上の区分けとして示すものに過ぎない。

ｃａｌｌセッション情報収集部５３１は、ｃａｌｌセッション情報を収集する。具体的には、ｃａｌｌセッション情報収集部５３１は、配下のＳＩＰフォン２５０と他方のＳＩＰフォン２５０との間でＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を、ＳＩＰ通信に含まれる情報から収集する。また、ｃａｌｌセッション情報収集部５３１は、収集したｃａｌｌセッション情報を情報表示端末特定部５３３に伝達する。

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

情報表示端末特定部５３３は、ＳＩＰによって通信を確立したＳＩＰフォン２５０と組で利用される情報表示端末２６０を特定する。具体的には、情報表示端末特定部５３３は、ＳＩＰフォンＩＤ収集部５３２によって収集されたＳＩＰフォンＩＤを検索キーとして、ブラウザセッション情報ＤＢ５２１を検索し、当該ＳＩＰフォンＩＤによって一意に識別されるＳＩＰフォン２５０と組で利用される情報表示端末２６０を特定するとともに、当該情報表示端末２６０のブラウザセッション情報を特定する。次に、情報表示端末特定部５３３は、特定したブラウザセッション情報と、ＨＧＷ５００に対してポーリングを行う複数の情報表示端末２６０各々のブラウザセッション情報とを比較し、ブラウザセッション情報が一致したポーリングを行っている情報表示端末２６０が、ＳＩＰによって通信を確立したＳＩＰフォン２５０と組で利用される情報表示端末２６０であると特定する。そして、情報表示端末特定部５３３は、アクセス先変更指示部５３４に、情報表示端末２６０の特定情報とｃａｌｌセッション情報とを伝達する。

アクセス先変更指示部５３４は、アクセス先変更指示を情報表示端末２６０に対して行う。具体的には、アクセス先変更指示部５３４は、情報表示端末特定部５３３から情報表示端末２６０の特定情報とｃａｌｌセッション情報とを伝達されると、特定情報で特定される情報表示端末２６０に対して、サービス提供装置１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報とともに行う。

（ＳＩＰフォンの構成）
実施例２におけるＳＩＰフォン２５０は、汎用的なＳＩＰフォンによって実現され、特に、図１２に示すように、入力部２５１と、出力部２５２と、入出力制御Ｉ／Ｆ部２５３と、ＳＩＰ通信部２５４とを有する。

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

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

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

制御部２６５は、情報表示端末２６０における各種制御を行う集積回路又はＣＰＵやＭＰＵなどの電子回路であり、図１２に示すように、ｃａｌｌセッション情報送信部２６６と、Ｗｅｂセッション情報受信部２６７と、サービス利用部２６８とを備える。

ｃａｌｌセッション情報送信部２６６は、ｃａｌｌセッション情報を送信する。具体的には、ｃａｌｌセッション情報送信部２６６は、ＨＧＷ５００のアクセス先変更指示部５３４によってリダイレクトされると、アクセス先をサービス提供装置１００に変更し、ｃａｌｌセッション情報をサービス提供装置１００に送信する。この時、ｃａｌｌセッション情報送信部２６６は、ＨＴＴＰ通信を行うブラウザによってサービス提供装置１００にアクセスするので、当該ＨＴＴＰ通信には、情報表示端末２６０のＷｅｂセッション情報が付与されている。

Ｗｅｂセッション情報受信部２６７は、Ｗｅｂセッション情報を受信する。具体的には、Ｗｅｂセッション情報受信部２６７は、サービス提供装置１００からＷｅｂセッション情報を受信する。また、Ｗｅｂセッション情報受信部２６７は、受信したＷｅｂセッション情報を、サービス利用部２６８に伝達する。

サービス利用部２６８は、サービス提供装置１００によって提供されるサービスの提供を受け、サービスを利用する。具体的には、サービス利用部２６８は、Ｗｅｂセッション情報受信部２６７によって伝達されたＷｅｂセッション情報を、ＨＴＴＰ通信を行うブラウザに付与し、サービス提供を受けるために、サービス提供装置１００との間でＷｅｂ通信を行う。

（処理の流れ）
次に、図１４を用いて、サービス提供装置における処理の流れを説明する。図１４は、実施例２に係るサービス提供装置における処理の流れを示すシーケンス図である。

図１４に示すように、情報表示端末２６０のＨＴＴＰ通信部２６４は、ユーザの指示操作を入力部２６１を介して受け付けて、サービス提供装置１００にＷｅｂアクセスを実施する（ステップＳ３０１）。

情報表示端末２６０からＷｅｂアクセスを受け付けたサービス提供装置１００のＩＰアドレス対応付け部１３１は、該ＷｅｂアクセスからＩＰアドレスを取得し、取得したＷｅｂアクセスに対応付ける一時アドレスを払出し、取得したＩＰアドレスと払い出した一時アドレスとを対応付けて、仮登録ＤＢ１２１に格納する（ステップＳ３０２）。すなわち、ＩＰアドレス対応付け部１３１は、取得したＩＰアドレスをユーザがＷｅｂ上で使用するＩＰアドレスと認識する。続いて、ＩＰアドレス対応付け部１３１は、アクセス元の情報表示端末２６０に、払い出した一時アドレスを含めた応答を送信する（ステップＳ３０３）。

その後、ＳＩＰフォン２５０のＳＩＰ通信部２５４は、入力部２５１を介して、ユーザから一時アドレスを受け付けると、サービス提供装置１００を宛先として、該一時アドレスを含むＳＩＰ通信のＩＮＶＩＴＥをＨＧＷ５００に送信する（ステップＳ３０４）。ＨＧＷ５００は、受信したＩＮＶＩＴＥをＳＩＰプロキシ３００に送信し（ステップＳ３０５）、ＳＩＰプロキシ３００は、該ＩＮＶＩＴＥを宛先のサービス提供装置１００に転送する（ステップＳ３０６）。

すると、サービス提供装置１００のＩＰアドレス対応付け部１３１は、受け付けたＳＩＰのＩＮＶＩＴＥに含まれる一時アドレスに対応するＩＰアドレスを仮登録ＤＢ１２１から取得し、取得したＩＰアドレスをＩＮＶＩＴＥに含まれる電話番号を対応付けてユーザ管理ＤＢ１２２に格納する（ステップＳ３０７）。その後、ＩＰアドレス対応付け部１３１は、ＳＩＰフォン２５０を宛先とする応答（２００ ＯＫ）をＳＩＰプロキシ３００に送信し（ステップＳ３０８）、ＳＩＰプロキシ３００は、受信した応答をＨＧＷ５００に送信する（ステップＳ３０９）。そして、ＨＧＷ５００は、サービス提供装置１００から送信された応答をＳＩＰフォン２５０に転送する（ステップＳ３１０）。

上述したＳ３０１〜Ｓ３１０の処理は、ＨＧＷ６００とサービス提供装置１００との間でも同様に実行される（ステップＳ３１１〜ステップＳ３２０）。したがって、サービス提供装置１００は、両端末に対して、電話番号とＩＰアドレスとの組をユーザ管理ＤＢ１２２に格納することができる。なお、処理順序は同じタイミングになってもよいし、異なるタイミングになってもよい。

その後、ＳＩＰフォン２５０とＳＩＰフォン４５０との間で、ステップＳ３２１〜ステップＳ３２８のＳＩＰ通信がＨＧＷ５００、ＨＧＷ６００、ＳＩＰプロキシ３００を介して行われ、その結果、ステップＳ３２９において、ＳＩＰフォン２５０とＳＩＰフォン４５０との間でＳＩＰによって通信が確立される。なお、ＳＩＰ通信におけるDigest認証やREGISTER処理などについては図示していないが、一般的なＳＩＰ通信と同様、ステップＳ３２１よりも前に行われている。

両ＳＩＰフォン間でＳＩＰによって通信が確立されると、ＨＧＷ５００のｃａｌｌセッション情報収集部５３１は、配下のＳＩＰフォン２５０と他方のＳＩＰフォン４５０との間でＳＩＰによって確立された通信を一意に識別するｃａｌｌセッション情報を、ＳＩＰ通信に含まれる情報から収集し（ステップＳ３３０）、ステップＳ３３２において、情報表示端末特定部５３３に伝達する。

次に、ＨＧＷ５００のＳＩＰフォンＩＤ収集部５３２は、配下のＳＩＰフォン２５０を一意に識別する情報であるＳＩＰフォンＩＤを、当該ＳＩＰ通信に含まれる情報から収集し（ステップＳ３３１）、情報表示端末特定部５３３に伝達する（ステップＳ３３２）。

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

そして、ＨＧＷ５００のアクセス先変更指示部５３４は、アクセス先変更指示を、ステップＳ３３３において特定された情報表示端末２６０に対して行う。具体的には、特定された情報表示端末２６０に対して、サービス提供装置１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報とともに行う（ステップＳ３３５）。なお、実施例２においては、ＨＧＷ５００がサービス提供装置１００のＵＲＬを予め記憶部に記憶していることで、アクセス先変更指示部５３４が情報表示端末２６０に対して当該ＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を行うことができる。

すると、情報表示端末２６０のｃａｌｌセッション情報送信部２６６は、リダイレクトされ、アクセス先をサービス提供装置１００に変更し、ｃａｌｌセッション情報をサービス提供装置１００に送信する（ステップＳ３３５）。

なお、上述したステップＳ３３０〜ステップＳ３３５の処理は、情報表示端末２６０とサービス提供装置１００との間でも同様に実行される（ステップＳ３３６〜ステップＳ３４１）。なお、情報表示端末２６０と情報表示端末４６０の処理順序は同じタイミングになってもよいし、異なるタイミングになってもよい。

その後、サービス提供装置１００がＩＰアドレスによる認証を行って、Ｗｅｂセッション情報を払出し、Ｗｅｂセッション情報に基づいてサービスを制御するまでの処理（ステップＳ３４２〜ステップＳ３５０）は、実施例１で説明したステップＳ１３０〜ステップＳ１３８と同様なので、ここでは省略する。

（実施例２による効果）
このように、実施例２によれば、端末側が、複数台のＳＩＰフォンと複数台の情報表示端末とで構成される下、通信相手との関係が一時的な場合にも、サービスを利用する端末の性能やＩＰアドレスの体系に関係なく、ＩＰアドレスによる認証を実施でき、さらに、このような一時的な通信関係に基づいてサービス提供を実現することが可能になる。

ところで、実施例１や２に係るサービス提供装置１００は、まず、ＨＴＴＰによるアクセスからＩＰアドレスを取得して一時アドレスを払出し、次に、払い出した一時アドレスを含むＳＩＰ通信から電話番号を取得し、これらを対応付けて記憶する例を説明した。本願は、これに限定されるものではない。

例えば、サービス提供装置１００は、まず、ＳＩＰ通信から電話番号とＩＰアドレスとを取得し、次に、ＨＴＴＰアクセスからＩＰアドレスを取得する。そして、サービス提供装置１００は、電話番号に対応付けられているＳＩＰ通信から取得したＩＰアドレスを、ＨＴＴＰアクセスから取得したＩＰアドレスで書き換えて対応付けるようにしてもよい。

そこで、実施例３では、図１５を用いて、サービス提供装置１００が、電話番号に対応付けられているＳＩＰ通信から取得したＩＰアドレスを、ＨＴＴＰアクセスから取得したＩＰアドレスで書き換えて対応付ける例について説明する。図１５は、実施例３に係るサービス提供システムにおける処理の流れを示すシーケンス図である。

図１５に示すように、端末２００のＳＩＰフォン機能部２１０は、ＳＩＰプロキシ３００を介して、ＳＩＰのＩＮＶＩＴＥをサービス提供装置１００に送信する（ステップＳ４０１とステップＳ４０２）。続いて、サービス提供装置１００は、ＳＩＰプロキシ３００を介して、ＩＮＶＩＴＥに対する応答（２００ ＯＫ）を端末２００のＳＩＰフォン機能部２１０に送信する（ステップＳ４０３とステップＳ４０４）。この結果、サービス提供装置１００と端末２００のＳＩＰフォン機能部２１０とが音声接続される（ステップＳ４０５）。

同様に、端末４００のＳＩＰフォン機能部は、ＳＩＰプロキシ３００を介して、ＳＩＰのＩＮＶＩＴＥをサービス提供装置１００に送信する（ステップＳ４０６とステップＳ４０７）。続いて、サービス提供装置１００は、ＳＩＰプロキシ３００を介して、ＩＮＶＩＴＥに対する応答（２００ ＯＫ）を端末４００のＳＩＰフォン機能部に送信する（ステップＳ４０８とステップＳ４０９）。この結果、サービス提供装置１００と端末４００のＳＩＰフォン機能部が音声接続される（ステップＳ４１０）。

その後、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ステップＳ４０１−ステップＳ４０２で取得した電話番号とｃａｌｌセッション情報とを仮登録ＤＢ１２１に格納する（ステップＳ４１１）。同様に、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ステップＳ４０６−ステップＳ４０７で取得した電話番号とｃａｌｌセッション情報とを仮登録ＤＢ１２１に格納する（ステップＳ４１１）。すなわち、サービス提供装置１００のＩＰアドレス対応付け部１３１は、端末２００の電話番号とｃａｌｌセッション情報とを対応付けて記憶するとともに、端末４００の電話番号とｃａｌｌセッション情報とを対応付けて記憶する。

その後、端末２００のＳＩＰフォン機能部２１０は、ｃａｌｌセッション情報を収集し（ステップＳ４１２）、収集したｃａｌｌセッション情報を情報表示機能部２２０に伝達する（ステップＳ４１３）。そして、情報表示機能部２２０は、ｃａｌｌセッション情報を含んだＷｅｂアクセスをサービス提供装置１００に実施する（ステップＳ４１４）。

同様に、端末４００のＳＩＰフォン機能部は、ｃａｌｌセッション情報を収集し（ステップＳ４１５）、収集したｃａｌｌセッション情報を情報表示機能部に伝達する（ステップＳ４１６）。そして、情報表示機能部は、ｃａｌｌセッション情報を含んだＷｅｂアクセスをサービス提供装置１００に実施する（ステップＳ４１７）。

そして、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ステップＳ４１４で受信したＷｅｂアクセスに含まれるｃａｌｌセッション情報に対応付けられる電話番号を仮登録ＤＢ１２１から取得するとともに、該ＷｅｂアクセスからＩＰアドレスを取得し、これらの電話番号とＩＰアドレスとを対応付けてユーザ管理ＤＢ１２２に格納する（ステップＳ４１８）。また、端末２００とサービス提供装置１００との間のＳＩＰ通信は、端末２００により接続されてもよく、端末４００とサービス提供装置１００との間のＳＩＰ通信は、端末４００の操作により切断されてもよい。なお、切断されない場合には、端末２００または端末４００が複数のＳＩＰ通信（音声通信）を接続することになる。

同様に、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ステップＳ４１７で受信したＷｅｂアクセスに含まれるｃａｌｌセッション情報に対応付けられる電話番号を仮登録ＤＢ１２１から取得するとともに、該ＷｅｂアクセスからＩＰアドレスを取得し、これらの電話番号とＩＰアドレスとを対応付けてユーザ管理ＤＢ１２２に格納する（ステップＳ４１８）。

その後のステップＳ４１９〜ステップＳ４４２までの処理は、実施例１で説明したステップＳ１１５〜ステップＳ１３８と同様なので、ここでは省略する。

このように、実施例３によれば、電話番号とＩＰアドレスとの対応付けを記憶する場合に、どちらの情報を先に仮登録したとしても、端末がＳＩＰで利用する電話番号と端末がＷｅｂで利用するＩＰアドレスとを正確に対応付けて記憶することができる。

ところで、実施例３では、端末間同士のＳＩＰ接続より前の段階で、ＳＩＰ通信を発生させた上で、端末がＳＩＰで利用する電話番号と端末がＷｅｂで利用するＩＰアドレスとを対応付けて記憶した。ところが、本願はこれに限定されるものではなく、端末間同士のＳＩＰ接続を利用して、電話番号とＩＰアドレスとを対応付けて記憶することもできる。

そこで、実施例４では、図１６を用いて、端末間同士のＳＩＰ接続において、電話番号とＩＰアドレスとを対応付けて記憶する例について説明する。図１６は、実施例４に係るサービス提供システムにおける処理の流れを示すシーケンス図である。

図１６に示すように、端末２００および端末４００各々のＳＩＰ通信部２１１間で、ステップＳ５０１〜ステップＳ５０６のＳＩＰ通信がＳＩＰプロキシ３００を介して行われ、その結果、ステップＳ５０８において、端末２００および端末４００間でＳＩＰによって通信が確立される。なお、ＳＩＰ通信におけるDigest認証やREGISTER処理などについては図示していないが、一般的なＳＩＰ通信と同様、ステップＳ５０１よりも前に行われている。

そして、端末間同士でＳＩＰ通信が接続されると、サービス提供装置１００のＩＰアドレス対応付け部１３１は、該ＳＩＰ通信で端末２００が利用する電話番号とＩＰアドレスとの組をＳＩＰプロキシ３００から取得して仮登録ＤＢ１２１に格納する（ステップＳ５０９）。

同様に、端末間同士でＳＩＰ通信が接続されると、サービス提供装置１００のＩＰアドレス対応付け部１３１は、該ＳＩＰ通信で端末４００が利用する電話番号とＩＰアドレスとの組をＳＩＰプロキシ３００から取得して仮登録ＤＢ１２１に格納する（ステップＳ５０９）。

その後、端末２００のＳＩＰフォン機能部２１０は、ｃａｌｌセッション情報を収集し（ステップＳ５１０）、収集したｃａｌｌセッション情報を情報表示機能部２２０に伝達する（ステップＳ５１１）。そして、情報表示機能部２２０は、ｃａｌｌセッション情報を含んだＷｅｂアクセスをサービス提供装置１００に実施する（ステップＳ５１２）。

同様に、端末４００のＳＩＰフォン機能部は、ｃａｌｌセッション情報を収集し（ステップＳ５１３）、収集したｃａｌｌセッション情報を情報表示機能部に伝達する（ステップＳ５１４）。そして、情報表示機能部は、ｃａｌｌセッション情報を含んだＷｅｂアクセスをサービス提供装置１００に実施する（ステップＳ５１５）。

そして、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ステップＳ５１２で受信したＷｅｂアクセスに含まれるｃａｌｌセッション情報に対応付けられる電話番号を仮登録ＤＢ１２１から取得するとともに、該ＷｅｂアクセスからＩＰアドレスを取得し、これらの電話番号とＩＰアドレスとを対応付けてユーザ管理ＤＢ１２２に格納する（ステップＳ５１６）。

同様に、サービス提供装置１００のＩＰアドレス対応付け部１３１は、ステップＳ５２２で受信したＷｅｂアクセスに含まれるｃａｌｌセッション情報に対応付けられる電話番号を仮登録ＤＢ１２１から取得するとともに、該ＷｅｂアクセスからＩＰアドレスを取得し、これらの電話番号とＩＰアドレスとを対応付けてユーザ管理ＤＢ１２２に格納する（ステップＳ５２３）。

その後のステップＳ５１７〜ステップＳ５３１までの処理は、実施例１と同様なので、ここでは省略する。

このように、実施例４によれば、端末間同士のＳＩＰ接続において、電話番号とＩＰアドレスとを対応付けて記憶することができるので、実施例１〜３と比較して、ＳＩＰ通信を省略することができ、ネットワークの輻輳等も防止することができる。

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

（ＩＰアドレスの表記）
実施例１では、ＳＩＰ通信で利用されるＩＰアドレスがＩＰｖ４表記であり、Ｗｅｂ通信で利用されるＩＰアドレスがＩＰｖ６表記である場合に説明したが、これに限定されるものではなく、逆であってもよい。また、同じ表記であってもよく、その場合には、一時アドレスを用いることなく、実現することができる。

（通信プロトコルの選択）
上記の実施例においては、第１の通信が、ＳＩＰによってセッションが確立される過程の通信（なお、実施例３において切断の対象となる第１の通信は、ＳＩＰによって確立された通信を意味する）であり、第２の通信が、Ｗｅｂ通信（ＨＴＴＰ通信）であることを想定してきたが、本発明はこれに限られるものではない。第１の通信によって確立されるセッションと第２の通信のセッションとが互いに異なるセッションであれば、具体的な通信プロトコルはいずれでもよい。

（有効条件）
例えば、サービス提供装置は、端末の情報表示機能から受信したアクセスからＩＰアドレスを取得して、仮登録ＤＢに格納するのに際して、有効条件を格納するようにしてもよい。そして、サービス提供装置は、有効条件を満たすことを条件に、電話番号とＩＰアドレスとの対応付けを格納する。例えば、サービス提供装置は、図１７に示すように、通話中、登録後１０分間、同一プレフィックスなどの有効条件を記憶する。なお、図１７は、ＩＰアドレスと電話番号との対応付けを格納する有効条件の例を示す図である。

（ｃａｌｌセッション情報）
また、上記の実施例においては、双方の端末や双方の情報表示端末からサービス提供装置が取得するｃａｌｌセッション情報は、同一の値であるものとして説明してきたが、同一の値でなくてもよい。ＳＩＰによって端末間で確立された同一の通信を一意に識別するものとしてサービス提供装置が認識可能なものであれば、二つの値の組み合わせでもよい。

（ｃａｌｌセッション情報の収集）
また、サービス提供装置は、第１の通信を制御する第１通信制御装置によって収集された第１通信情報を当該第１通信制御装置から受信することで取得してもよい。この場合には、例えば、ＳＩＰプロキシが第１通信情報を収集するという手法で、一時的な通信関係に基づいたサービス提供を制御することが可能になる。

（ｃａｌｌセッション情報の再利用）
また、サービス提供装置は、Ｗｅｂセッション情報を用いてサービスが提供された際に、提供されたサービスに関する情報と、当該Ｗｅｂセッション情報に対応づけてセッション情報ＤＢに格納されているｃａｌｌセッション情報とを対応づけ、当該対応づけを予め設定された有効期間とともに記憶部に格納する。また、サービス提供装置は、端末が、有効期間内に、記憶部によって記憶されているｃａｌｌセッション情報を指定してサービス提供装置との間でＷｅｂ通信を行うと、当該ｃａｌｌセッション情報を検索キーとして記憶部を検索し、当該ｃａｌｌセッション情報に対応づけて格納されているサービスに関する情報を取得する。そして、サービス提供装置は、サービスに関する情報を取得すると、当該情報に基づいて、当該端末に対するサービスを制御する。この場合には、有効期間内であれば、過去にＳＩＰによって同一の通信を確立した端末各々の一時的な通信関係（過去の通信関係）に基づいて、サービスを制御することが可能になる。

例えば、端末は、Ｗｅｂサービスの初回利用時に用いたｃａｌｌセッション情報を端末内に保存しておき、一方、サービス提供装置は、当該ｃａｌｌセッション情報に対応づけて、いつ、誰と、どのタイミングで接続した端末であるか、端末の利用データは何か、等を保存しておいたとする。すると、端末が、次回利用時に、このｃａｌｌセッション情報を用いてサービス提供装置にアクセスすれば、サービス提供装置は、これらの情報に基づいて、サービス提供を再制御することができる。

さらに、サービスの具体例を挙げて説明すると、通信相手に送信した画像がサービス提供装置に保存されている場合、サービスの利用者は、その画像送信時のｃａｌｌセッション情報をサービス提供装置に送信することで、再度、送信した画像、又は、受信した画像を確認することができる。また、この時、通信相手先と通話中である必要はない。つまり、通話と関係なく、ブラウザがｃａｌｌセッション情報をサービス提供装置に送るだけで実現することができる。

（システム構成等）
また、上記の実施例においては、単一のＳＩＰプロキシがＳＩＰ信号（ＳＩＰの具体的な信号、ＩＮＶＩＴＥ、２００ ＯＫなどの種類、および、Ｆｒｏｍ、Ｔｏなどのパラメータを含む）を仲介する事例を説明してきたが、本発明はこれに限られるものではない。複数のＳＩＰプロキシがＳＩＰ信号を仲介する事例や、ＮＧＮ（Next Generation Network）におけるＡＳ（Application Server）などがＳＩＰ信号を仲介する事例にも、本発明を同様に適用することができる。

また、上記の実施例においては、ＳＩＰフォンと情報表示端末との間の情報伝達を代行するとともに、サービス提供の対象となる情報表示端末を特定する装置としての役割を、ＨＧＷが行う例についても説明してきたが、本発明はこれに限られるものではない。例えば、ＳＩＰフォンにＷｅｂサーバ相当の機能が備えられれば、ＳＩＰフォンと情報表示端末との間の情報伝達が可能になり、情報表示端末からＳＩＰフォンに向かってｃａｌｌセッション情報取得の処理を行うことで、サービス提供の対象となる情報表示端末を特定することも可能になる（ＨＧＷが不要な構成となる）。

例えば、実施例２において、端末側の形態は、ＳＩＰフォンと情報表示端末とに分かれているが、ＳＩＰフォンはＷｅｂサーバ相当の機能を備えているとする。このような場合、双方のＳＩＰフォンが、ＳＩＰによって確立した通信からｃａｌｌセッション情報を収集し、情報表示端末が、Ｗｅｂサーバ相当の機能を備えたＳＩＰフォンにポーリングするなどしてｃａｌｌセッション情報をＳＩＰフォンから取得し、取得したｃａｌｌセッション情報とともにサービス提供装置にアクセスする。すると、サービス提供装置は、ｃａｌｌセッション情報を取得することができる。

また、例えば、一方のＳＩＰフォンのみｃａｌｌセッション情報を収集する手法も考えられる。すなわち、一方のＳＩＰフォン（Ｗｅｂサーバ相当の機能を備える）は、ＩＰによって確立した通信からｃａｌｌセッション情報を収集し、上記と同様に、情報表示端末が、Ｗｅｂサーバ相当の機能を備えたＳＩＰフォンにポーリングするなどしてｃａｌｌセッション情報をＳＩＰフォンから取得し、取得したｃａｌｌセッション情報とともにサービス提供装置にアクセスする。すると、サービス提供装置は、まず、一方について、ｃａｌｌセッション情報を取得することができる。この時、このＳＩＰフォンは、収集したｃａｌｌセッション情報を、他方のＳＩＰフォン（ＳＩＰによって通信を確立した通信相手のＳＩＰフォン）に通知する。すると、他方のＳＩＰフォンと組で利用される情報表示端末は、当該他方のＳＩＰフォンにポーリングするなどしてｃａｌｌセッション情報を取得し、取得したｃａｌｌセッション情報とともにサービス提供装置にアクセスする。すると、サービス提供装置は、他方についても、ｃａｌｌセッション情報を取得することができる。

また、実施例２において、仮に、ＳＩＰフォンがＷｅｂサーバ相当の機能を備える場合には、ＳＩＰ ＰＲＯＸＹが、ＳＩＰフォン自体にサービス提供装置のＵＲＬを通知する手法を用いることもできる。

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

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

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

以上のように、本発明に係るサービス提供システム、サービス提供方法およびサービス提供プログラムは、ネットワークに接続される複数の端末に当該ネットワーク上のサービスを提供するサービス提供装置がサービスを制御することに有用であり、特に、サービスを利用する端末の性能やＩＰアドレスの体系に関係なく、一時的な通信関係に基づいてサービスを提供することに適する。

１００ サービス提供装置
１１０ 通信制御Ｉ／Ｆ部
１２０ 記憶部
１２１ 仮登録ＤＢ
１２２ ユーザ管理ＤＢ
１２３ セッション情報ＤＢ
１３０ 制御部
１３１ ＩＰアドレス対応付け部
１３２ ｃａｌｌセッション情報受信部
１３３ 認証実行部
１３４ Ｗｅｂセッション情報払出部
１３５ 関連づけ部
１３６ サービス提供部
２００ 端末
２０１ 入力部
２０２ 出力部
２０３ 入出力制御Ｉ／Ｆ部
２１０ ＳＩＰフォン機能部
２１１ ＳＩＰ通信部
２１２ 制御部
２１３ ｃａｌｌセッション情報収集部
２１４ 起動指示部
２２０ 情報表示機能部
２２１ ＨＴＴＰ通信部
２２２ 制御部
２２３ ｃａｌｌセッション情報送信部
２２４ Ｗｅｂセッション情報受信部
２２５ サービス利用部

Claims (6)

1. ネットワークに接続される複数の端末に対して、当該ネットワーク上のサービスを制御するサービス提供装置であって、
   前記複数の端末との間で接続される第１の通信で利用される電話番号と、前記複数の端末との間で接続される第２の通信で利用されるＩＰアドレスとを対応付けて対応付け記憶手段に格納する対応付け格納手段と、
   前記サービスを利用することを要求する利用要求を前記複数の端末の内のいずれか一つの端末から前記第２の通信で受け付けた際に、当該端末と組で利用され前記第１の通信を確立する第１通信端末と、他の第１通信端末との間で確立された前記第１の通信を一意に識別する第１通信情報を取得する第１通信情報取得手段と、
   前記第１通信情報取得手段によって取得された第１通信情報に含まれる電話番号と、前記第１通信情報取得手段によって第１通信情報が取得された前記第２の通信から取得した前記ＩＰアドレスとが対応付けられて前記対応付け格納手段に格納されているか否かを判定する判定手段と、
   前記判定手段によって前記対応付け格納手段に格納されていると判定された場合に、前記利用要求を送信した前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う前記第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手段によって取得された第１通信情報に対応づけて第２通信情報記憶手段に格納する第２通信情報格納手段と、
   前記第２通信情報記憶手段に格納されている複数の第１通信情報の内、いずれか二つの第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶手段に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御手段と、
   を備えたことを特徴とするサービス提供装置。
2. 前記対応付け格納手段は、前記第１の通信と前記第２の通信とが予め指定された所定の有効条件を満たす通信である場合に限って、前記電話番号とＩＰアドレスとを格納することを特徴とする請求項１に記載のサービス提供装置。
3. 前記第２の通信から前記ＩＰアドレスを取得する際に、一意な識別子である一時アドレスを発行する発行手段をさらに有し、
   前記対応付け格納手段は、前記第１の通信から取得した一時アドレスが前記発行手段により発行された一時アドレスである場合に、前記電話番号とＩＰアドレスとを格納することを特徴とする請求項１または２に記載のサービス提供装置。
4. 前記対応付け格納手段は、前記第１の通信から取得した前記第１通信情報をさらに対応付けて格納し、
   前記判定手段は、前記第１通信情報取得手段によって取得された第１通信情報と、前記第１通信情報取得手段によって第１通信情報が取得された前記第２の通信から取得した前記ＩＰアドレスとが対応付けられて前記対応付け格納手段に格納されているか否かを判定することを特徴とする請求項１〜３のいずれか一つに記載のサービス提供装置。
5. ネットワークに接続される複数の端末に対して、当該ネットワーク上のサービスを制御するサービス提供装置に適したサービス提供方法であって、
   前記複数の端末との間で接続される第１の通信で利用される電話番号と、前記複数の端末との間で接続される第２の通信で利用されるＩＰアドレスとを対応付けて対応付け記憶部に格納する対応付け格納工程と、
   前記サービスを利用することを要求する利用要求を前記複数の端末の内のいずれか一つの端末から前記第２の通信で受け付けた際に、当該端末と組で利用され前記第１の通信を確立する第１通信端末と、他の第１通信端末との間で確立された前記第１の通信を一意に識別する第１通信情報を取得する第１通信情報取得工程と、
   前記第１通信情報取得工程によって取得された第１通信情報に含まれる電話番号と、前記第１通信情報取得工程によって第１通信情報が取得された前記第２の通信から取得した前記ＩＰアドレスとが対応付けられて前記対応付け格納部に格納されているか否かを判定する判定工程と、
   前記判定工程によって前記対応付け格納部に格納されていると判定された場合に、前記利用要求を送信した前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う前記第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得工程によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納工程と、
   前記第２通信情報記憶部に格納されている複数の第１通信情報の内、いずれか二つの第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御工程と、
   を含んだことを特徴とするサービス提供方法。
6. ネットワークに接続される複数の端末に対して、当該ネットワーク上のサービスを制御するサービス提供装置としてのコンピュータに実行させるサービス提供プログラムであって、
   前記複数の端末との間で接続される第１の通信で利用される電話番号と、前記複数の端末との間で接続される第２の通信で利用されるＩＰアドレスとを対応付けて対応付け記憶部に格納する対応付け格納手順と、
   前記サービスを利用することを要求する利用要求を前記複数の端末の内のいずれか一つの端末から前記第２の通信で受け付けた際に、当該端末と組で利用され前記第１の通信を確立する第１通信端末と、他の第１通信端末との間で確立された前記第１の通信を一意に識別する第１通信情報を取得する第１通信情報取得手順と、
   前記第１通信情報取得手順によって取得された第１通信情報に含まれる電話番号と、前記第１通信情報取得手順によって第１通信情報が取得された前記第２の通信から取得した前記ＩＰアドレスとが対応付けられて前記対応付け格納部に格納されているか否かを判定する判定手順と、
   前記判定手順によって前記対応付け格納部に格納されていると判定された場合に、前記利用要求を送信した前記端末が当該サービス提供装置との間で前記サービスを利用する際に行う前記第２の通信を一意に識別する第２通信情報を、前記第１通信情報取得手順によって取得された第１通信情報に対応づけて第２通信情報記憶部に格納する第２通信情報格納手順と、
   前記第２通信情報記憶部に格納されている複数の第１通信情報の内、いずれか二つの第１通信情報各々が同一の第１の通信として確立されたものであることを示す場合に、当該第１通信情報各々に対応づけて前記第２通信情報記憶部に格納されている第２通信情報各々を用いて提供されるサービスを、互いに関連づけて制御するサービス提供制御手順と、
   をコンピュータに実行させるサービス提供プログラム。

Images