JP2010262399A - Ｗｅｂサービス制御システム及びＷｅｂサービス制御方法 - Google Patents

Abstract

【課題】通話による口頭コミュニケーションを広告料の算出対象とすることを課題とする。
【解決手段】ボブとアリスとの間で通話が行われると、アフィリエイトサーバは、通話情報を収集して連携情報を発行し、ボブやアリスが用いる情報表示端末それぞれとの対応付けを行う。また、広告主サーバは、情報表示端末それぞれに提供するＷｅｂサービスがボブとアリスとの間で連携されるように、連携情報を用いてＷｅｂサービスの提供を制御する。また、広告主サーバは、広告料が支払われるべきものとして設定された所定の処理（成果）がいずれかの情報表示端末から実行されたことを検知し、アフィリエイトサーバに通知する。すると、アフィリエイトサーバは、所定の処理を実行した利用者の通話相手を通話情報を用いて特定し、特定した利用者を示す情報を広告主サーバに通知する。
【選択図】図２

Description

本発明は、Ｗｅｂサービス制御システム及びＷｅｂサービス制御方法に関する。

近年、インターネット上では、アフィリエイトと呼ばれる広告の仕組みが注目されている。アフィリエイトでは、アフィリエイターと呼ばれる広告媒体主が、広告主のＥＣ（Electronic Commerce）サイトにリンクされた広告バナーやＥＣサイトの推薦情報などを自身のＷｅｂサイトに掲載する。アフィリエイターのＷｅｂサイトを閲覧した閲覧者が、広告バナーを経由してＥＣサイトにアクセスし、例えば商品を購入するなどの処理（いわゆる成果）を行うと、アフィリエイターに広告料が支払われる、といった仕組みである。

このため、従来、広告主のＥＣサイトは、成果に結びついた閲覧者のアクセスがどのアフィリエイターのＷｅｂサイトを経由したものであるかを特定し、その他成果の発生件数などに基づいて、アフィリエイターに支払う広告料を算出していた。

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

しかしながら、上記した従来の仕組みでは、通話による口頭コミュニケーションを広告料の算出対象とすることができないという課題があった。

すなわち、本来、成果に結びついた閲覧者のアクセスは、広告バナーを経由する場合に限られず、通話相手から提供された口頭による推薦情報を契機とする場合もあるはずである。しかしながら、広告主のＥＣサイトは、このようなアクセスが誰から提供された推薦情報を契機とするものであるのかを特定することができず、広告料の算出対象とすることができなかった。

開示の技術は、上記に鑑みてなされたものであって、通話による口頭コミュニケーションを広告料の算出対象とすることが可能なＷｅｂサービス制御システム及びＷｅｂサービス制御方法を提供することを目的とする。

本願の開示するＷｅｂサービス制御システム及びＷｅｂサービス制御方法は、一つの態様において、複数の利用者間で通話による通信が行われると、当該通話の関係にある利用者それぞれを特定する通話情報と個々の利用者がＷｅｂサービスの利用に用いる端末それぞれとの対応付けを行い、当該端末それぞれに提供するＷｅｂサービスが当該複数の利用者間で連携されるように、当該通話情報を用いてＷｅｂサービスの提供を制御するＷｅｂサービス制御手段と、前記Ｗｅｂサービス制御手段によって前記複数の利用者間に提供されているＷｅｂサービスにおいて、広告料が支払われるべきものとして設定された所定の処理がいずれかの端末から実行されたことを検知する検知手段と、前記検知手段によって前記所定の処理が実行されたことが検知されると、当該所定の処理を実行した利用者の通話相手を、前記通話情報を用いて特定する通話相手特定手段と、前記通話相手特定手段によって特定された利用者を示す情報を、前記広告料を算出する広告料算出手段に通知する通知手段とを備える。

本願の開示するＷｅｂサービス制御システム及びＷｅｂサービス制御方法の一つの態様によれば、通話による口頭コミュニケーションを広告料の算出対象とすることが可能になるという効果を奏する。

図１は、実施例１に係るＷｅｂサービス制御システムの概要を説明するための図である。 図２は、実施例１に係るＷｅｂサービス制御システムの構成を説明するための図である。 図３は、アフィリエイトサーバの構成を示すブロック図である。 図４は、ユーザ契約サービス管理テーブルを説明するための図である。 図５は、契約サービス情報テーブルを説明するための図である。 図６は、制御用セッション管理テーブルを説明するための図である。 図７は、発着間紐付けＩＤテーブルを説明するための図である。 図８は、広告主サーバの構成を示すブロック図である。 図９は、Ｗｅｂセッション情報管理テーブルを説明するための図である。 図１０は、ＨＧＷの構成を示すブロック図である。 図１１は、ブラウザセッション情報管理テーブルを説明するための図である。 図１２は、ＳＩＰフォンの構成を示すブロック図である。 図１３は、情報表示端末の構成を示すブロック図である。 図１４は、実施例１に係るＷｅｂサービス制御システムによる処理手順を示すシーケンス図である。 図１５は、実施例１に係るＷｅｂサービス制御システムによる処理手順を示すシーケンス図である。 図１６は、実施例２に係るＷｅｂサービス制御システムの処理手順を示すシーケンス図である。 図１７は、実施例３に係るＷｅｂサービス制御システムの処理手順を示すシーケンス図である。 図１８は、実施例４に係るＷｅｂサービス制御システムの概要を説明するための図である。 図１９は、実施例４におけるアフィリエイトサーバの構成を示すブロック図である。 図２０は、契約情報テーブルを説明するための図である。 図２１は、広告料情報テーブルを説明するための図である。 図２２は、成果テーブルを説明するための図である。 図２３は、報酬テーブルを説明するための図である。 図２４は、広告生成の処理手順を示すシーケンス図である。 図２５は、履歴登録の処理手順を示すシーケンス図である。

以下に、本願の開示するＷｅｂサービス制御システム及びＷｅｂサービス制御方法の実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本発明が限定されるものではない。

［実施例１に係るＷｅｂサービス制御システムの概要］
まず、図１及び図２を用いて、実施例１に係るＷｅｂサービス制御システムの概要を説明する。図１は、実施例１に係るＷｅｂサービス制御システムの概要を説明するための図であり、図２は、実施例１に係るＷｅｂサービス制御システムの構成を説明するための図である。なお、以下では、実施例１に係るＷｅｂサービス制御システムの概要を説明するに留まり、詳細な構成や処理手順については後述する。

図１に示すように、実施例１に係るＷｅｂサービス制御システムにおいては、アフィリエイト機能を有するアフィリエイトサーバが、広告主サーバ（広告主のＥＣサイト）と利用者（ボブ、アリス）との間に介在し、広告料の算出に寄与している。なお、ボブが推薦情報の提供者、アリスが購入者であり、ボブとアリスとの間の通話による口頭コミュニケーションが契機となって、アリスが「アイスクリーム購入」という成果を行った事例を想定している。

ここで、図１と図２との対応について説明すると、図１において電話機の絵で示すものは、図２に示すＳＩＰフォンに対応する。また、図１においてＰＣ（Personal Computer）の絵で示すものは、図２に示す情報表示端末に対応する。なお、図１においてＨＧＷ（HomeGateWay）と示すものは、図２においては図示を省略している。

具体的には、図１及び図２に示すように、ボブのＳＩＰフォンとアリスのＳＩＰフォンとの間で通話による通信が行われ、ボブとアリスとの間で通話による口頭コミュニケーションが行われると、アフィリエイトサーバが、通話の関係にあるボブとアリスとを特定する通話情報を収集する。

続いて、アフィリエイトサーバは、収集した通話情報と、ボブ及びアリスそれぞれがＷｅｂサービスの利用に用いる情報表示端末それぞれとの対応付けを行う。具体的には、アフィリエイトサーバは、図２に示すように、ボブとアリスとを紐付ける連携情報を発行し、発行した連携情報を情報表示端末それぞれに送信することで、ボブとアリスとの間の通話の関係を情報表示端末それぞれに対応付ける。

すると、情報表示端末それぞれは、図２に示すように、アフィリエイトサーバによって発行された連携情報を用いて広告主サーバにアクセスする。このため、広告主サーバは、同一の連携情報を用いてアクセスする情報表示端末それぞれに提供するＷｅｂサービスが連携されるように、すなわち、ボブとアリスとの間でＷｅｂサービスが連携されるように、Ｗｅｂサービスの提供を制御する。

ここで、図１に示すように、例えばボブの操作により、ボブ側の情報表示端末が、アイスクリームをインターネット上で販売する広告主サーバにアクセスし、アリス側の情報表示端末に同じＷｅｂページが表示されたとする。ボブが、アリスとの通話による口頭コミュニケーションの中で「コレはオススメだよ」と推薦情報を提供し、これを契機としてアリスが「買ってみるわ」とアイスクリームの購入を決め、アリス側の情報表示端末が購入の処理を実行したとする。なお、実施例１において、アイスクリームの購入処理は、広告料が支払われるべきものとして設定された処理である。

図２に示すように、実施例１においては、広告主サーバが、アイスクリームの購入処理がいずれかの情報表示端末から実行されたことを検知し、アフィリエイトサーバに通知する。すると、アフィリエイトサーバは、アイスクリームの購入処理を実行した利用者（アリス）の通話相手がボブであることを通話情報を用いて特定し、特定した「ボブ」を示す情報を広告主サーバに通知する。こうして、広告主サーバは、通知された利用者「ボブ」の情報を用いて広告料を算出する。

このように、実施例１に係るＷｅｂサービス制御システムは、通話情報を用いてＷｅｂサービスの提供を制御するとともに、Ｗｅｂサービスにおいて成果を検知すると、成果を実行した利用者の通話相手を通話情報を用いて特定する。このため、成果に結びついた閲覧者のアクセスが通話相手から提供された推薦情報を契機とする場合に、その通話相手を特定することが可能になり、通話による口頭コミュニケーションを広告料の算出対象とすることが可能になる。

［実施例１に係るＷｅｂサービス制御システムの構成］
次に、図３〜図１３を用いて、実施例１に係るＷｅｂサービス制御システムの構成を説明する。以下、アフィリエイトサーバ１００、広告主サーバ２００、ＨＧＷ１０、ＳＩＰフォン３０、情報表示端末２０の順に説明する。

［アフィリエイトサーバ］
図３〜図７を用いて、アフィリエイトサーバ１００の構成を説明する。図３は、アフィリエイトサーバの構成を示すブロック図であり、図４は、ユーザ契約サービス管理テーブルを説明するための図であり、図５は、契約サービス情報テーブルを説明するための図であり、図６は、制御用セッション管理テーブルを説明するための図であり、図７は、発着間紐付けＩＤテーブルを説明するための図である。

アフィリエイトサーバ１００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図３に示すように、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

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

記憶部１２０は、制御部１３０における各種制御に用いられる情報を記憶し、図３に示すように、ユーザ契約サービス管理テーブル１２１と契約サービス情報テーブル１２２と制御用セッション管理テーブル１２３と発着間紐付けＩＤテーブル１２４とを備える。

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

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

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

制御用セッション管理テーブル１２３は、制御用セッション情報を管理するテーブルである。例えば、制御用セッション管理テーブル１２３は、図６に示すように、制御用セッション情報と、ｃａｌｌセッション情報と、発着判定フラグと、通話情報（開始時刻〜終了時刻）とを対応付けて記憶している。

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

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

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

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

なお、図６において、説明の便宜上、制御用セッション情報や『Ｃａｌｌ−ＩＤ』として規則的な数値が例示されているが、一般的には乱数などが格納されることになる。

発着間紐付けＩＤテーブル１２４は、発着間紐付けＩＤを管理するテーブルである。例えば、発着間紐付けＩＤテーブル１２４は、図７に示すように、制御用セッション情報と、サービスＩＤと、発着間紐付けＩＤとを対応付けて記憶している。後述する発着間紐付けＩＤ発行部１３２が、情報表示端末２０からサービス開始要求を受け付けた際に発着間紐付けＩＤを発行し、制御用セッション情報、サービスＩＤとともに発着間紐付けＩＤテーブル１２４に格納する。

ここで、発着間紐付けＩＤとは、ＳＩＰによって確立されたセッションを一意に識別するｃａｌｌセッション情報の仮名情報であり、広告主サーバ２００が、通話中の情報表示端末２０各々、すなわち、利用者各々がＳＩＰフォン３０各々によって通話中である情報表示端末２０各々を紐付けるために利用するＩＤである。後述するように、発着間紐付けＩＤは、確立されたセッションごと（すなわち、通話ごと）に新しく発行されるため、広告主サーバ２００は、セッション単位で（すなわち、通話単位で）情報表示端末２０各々を紐付けることができる。

制御部１３０は、図３に示すように、ｃａｌｌセッション情報収集部１３１と、発着間紐付けＩＤ発行部１３２と、推薦情報提供者特定部１３３とを備える。

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

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

推薦情報提供者特定部１３３は、広告主サーバ２００から送信された成果通知を用いて推薦情報の提供者を特定する。

［広告主サーバ］
次に、図８及び図９を用いて、広告主サーバ２００の構成を説明する。図８は、広告主サーバの構成を示すブロック図であり、図９は、Ｗｅｂセッション情報管理テーブルを説明するための図である。

広告主サーバ２００は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、図８に示すように、通信部２１０と、記憶部２２０と、制御部２３０とを備える。

通信部２１０は、ＨＴＴＰ通信用の一般的なインタフェースおよびライブラリを備え、アフィリエイトサーバ１００との間や、情報表示端末２０との間などで情報を送受信する。

記憶部２２０は、制御部２３０における各種制御に用いられる情報を記憶し、図８に示すように、Ｗｅｂセッション情報管理テーブル２２１を備える。

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

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

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

図８に戻り、制御部２３０は、図８に示すように、発着間紐付けＩＤ収集部２３１と、サービス提供制御部２３２と、成果検知部２３３と、広告料算出部２３４とを備える。

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

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

成果検知部２３３は、複数の利用者間に提供されているＷｅｂサービスにおいて、広告料が支払われるべきものとして設定された所定の処理がいずれかの情報表示端末２０から実行されたことを検知する。

広告料算出部２３４は、アフィリエイトサーバ１００によって特定され送信された推薦情報の提供者を示す情報に基づき広告料を算出する。
［ＨＧＷ］
次に、図１０及び図１１を用いて、ＨＧＷ１０の構成を説明する。図１０は、ＨＧＷの構成を示すブロック図であり、図１１は、ブラウザセッション情報管理テーブルを説明するための図である。図１０に示すＨＧＷ１０は、以下に説明する各部が汎用的なゲートウェイ装置などに備えられることによって実現され、図１０に示すように、ＳＩＰ通信部／ＨＴＴＰ通信部１１と、記憶部１２と、制御部１３とを備える。

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

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

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

図１０に戻り、制御部１３は、特に本発明に密接に関連するものとしては、図１０に示すように、サービス利用制御部１３ａを備える。サービス利用制御部１３ａは、情報表示端末２０によるサービス利用を制御する。

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

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

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

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

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

サービス利用部２５ａは、広告主サーバ２００によって提供されるサービスを利用する。具体的には、サービス利用部２５ａは、サービスの提供を開始するサービス提供開始要求をアフィリエイトサーバ１００に送信したり、サービスの利用を要求するサービス利用要求を広告主サーバ２００に送信したりする。

［実施例１に係るＷｅｂサービス制御システムによる処理手順］
続いて、図１４及び図１５を用いて、実施例１に係るＷｅｂサービス制御システムによる処理手順を説明する。図１４及び図１５は、実施例１に係るＷｅｂサービス制御システムによる処理手順を示すシーケンス図である。

図１４に示すように、実施例１に係るＷｅｂサービス制御システムにおいては、まず、複数の利用者間で通話による通信が行われることを想定している（ステップＳ１０１）。例えば、ボブ（発側）とアリス（着側）との間でＳＩＰフォン３０を用いた通話による通信が行われることを想定している。ボブとアリスとの間で口頭コミュニケーションが行われている状態である。

次に、アフィリエイトサーバ１００が、通話の関係にある利用者それぞれを特定する通話情報と、個々の利用者がＷｅｂサービスの利用に用いる情報表示端末２０それぞれとの対応付けを行う（ステップＳ１０２〜Ｓ１０４）。

具体的には、まず、アフィリエイトサーバ１００は、通話の関係にあるボブ及びアリスを特定するｃａｌｌセッション情報及び発着判定フラグを収集する（ステップＳ１０２）。また、アフィリエイトサーバ１００は、ｃａｌｌセッション情報と対応付けて発着間紐付けＩＤを発行し、発行した発着間紐付けＩＤ及び発着判定フラグを情報表示端末２０それぞれに通知する（ステップＳ１０３）。こうして、ボブとアリスとの間で行われている口頭コミュニケーションの関係が、ボブ及びアリスそれぞれが用いる情報表示端末２０それぞれに対応付けられる。

続いて、広告主サーバ２００は、情報表示端末２０それぞれに提供するＷｅｂサービスが複数の利用者間で連携されるように、Ｗｅｂサービスの提供を制御する（ステップＳ１０４）。

具体的には、まず、情報表示端末２０それぞれが、アフィリエイトサーバ１００によって発行された発着間紐付けＩＤ及び発着判定フラグを用いて広告主サーバ２００にアクセスする。すると、ボブ側の情報表示端末２０とアリス側の情報表示端末２０とが同一の発着間紐付けＩＤを用いてアクセスすることになるので、広告主サーバ２００は、ボブ側の情報表示端末２０に提供するＷｅｂサービスと、アリス側の情報表示端末２０に提供するＷｅｂサービスとが連携されるように、発着間紐付けＩＤを用いてＷｅｂサービスの提供を制御する。すなわち、広告主サーバ２００は、あたかもボブとアリスとの間で行われている口頭コミュニケーションの関係と同様の関係となるように、発着間紐付けＩＤを用いてＷｅｂサービスの提供を制御する。例えば、ボブ側の情報表示端末２０に提供するＷｅｂサービスの画面と、アリス側の情報表示端末２０に提供するＷｅｂサービスの画面とが同期するように制御するなどする。

なお、ステップＳ１０２〜Ｓ１０４の処理手順の詳細については、図１５を用いて後述する。

ここで、広告主サーバ２００が、いずれかの情報表示端末２０から、広告料が支払われるべきものとして設定された所定の処理が実行されたことを検知したとする（ステップＳ１０５）。

例えば、広告主サーバ２００が提供するＷｅｂサービスにおいて、アリスが、アイスクリームの購入処理を実行したとする。この時、アリス側の情報表示端末２０がアイスクリームの購入処理を実行すると、例えば、アリス側の情報表示端末２０は、購入完了ページに対応するＵＲＬにアクセスするように誘導され、情報表示端末２０の出力部２３には、購入完了ページが表示される。この購入完了ページは、いわば成果成立を示すＵＲＬである（以下、成果成立契機ＵＲＬという）。広告主サーバ２００は、成果成立契機ＵＲＬを予め把握しているものと想定するので、広告主サーバ２００の成果検知部２３３は、成果成立契機ＵＲＬに対するアクセスがあったことをもって、成果成立を検知する。

すなわち、広告主サーバ２００の成果検知部２３３は、情報表示端末２０が成果成立契機ＵＲＬにアクセスしたことをアクセスログなどから検知し、情報表示端末２０のＷｅｂセッション情報を用いてＷｅｂセッション情報管理テーブル２２１を参照し、当該Ｗｅｂセッション情報に対応付けて記憶されている発着間紐付けＩＤ及び発着判定フラグを特定する。例えば、成果検知部２３３は、Ｗｅｂセッション情報「ｂｂｂｂｂｂｂｂｂｂ」を用いてＷｅｂセッション情報管理テーブル２２１を参照し、Ｗｅｂセッション情報「ｂｂｂｂｂｂｂｂｂｂ」に対応付けて記憶されている発着間紐付けＩＤ「ｌｉｎ３３３３」及び発着判定フラグ「着」を特定する。

続いて、広告主サーバ２００は、いずれかの情報表示端末２０から購入処理が実行されたことを検知した旨をアフィリエイトサーバ１００に通知する（ステップＳ１０６）。具体的には、広告主サーバ２００は、ステップＳ１０５において特定した発着間紐付けＩＤ及び発着判定フラグを通知する。なお、自己のサービスを特定するサービスＩＤやタイムスタンプを併せて通知してもよい。例えば、タイムスタンプを併せて通知すれば、アフィリエイトサーバ１００側は、通知されたタイムスタンプと制御用セッション管理テーブル１２３に格納された通話情報とを照合して、真正な情報であるか否かを検証することができる。

すると、アフィリエイトサーバ１００が、購入処理を実行した利用者の通話相手を通話情報を用いて特定し（ステップＳ１０７）、特定した通話相手を広告主サーバ２００に通知する（ステップＳ１０８）。

具体的には、アフィリエイトサーバ１００の推薦情報提供者特定部１３３は、まず、発着間紐付けＩＤ及び発着判定フラグを用いて発着間紐付けＩＤテーブル１２４及び制御用セッション管理テーブル１２３をそれぞれ参照し、発着間紐付けＩＤ及び発着判定フラグに対応付けて記憶されている制御用セッション情報を特定する。例えば、推薦情報提供者特定部１３３は、発着間紐付けＩＤ「ｌｉｎ３３３３」及び発着判定フラグ「着」を用いて発着間紐付けＩＤテーブル１２４及び制御用セッション管理テーブル１２３をそれぞれ参照し、発着間紐付けＩＤ「ｌｉｎ３３３３」及び発着判定フラグ「着」に対応付けて記憶されている制御用セッション情報「３３３３３３３３３３」を特定する。

次に、推薦情報提供者特定部１３３は、制御用セッション情報を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報に対応付けて記憶されているｃａｌｌセッション情報を特定し、特定したｃａｌｌセッション情報を用いて購入処理を実行した利用者の通話相手を特定する。例えば、推薦情報提供者特定部１３３は、制御用セッション情報「３３３３３３３３３３」を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報「３３３３３３３３３３」に対応付けて記憶されているｃａｌｌセッション情報を特定し、ｃａｌｌセッション情報の「Ｆｒｏｍ」から、購入処理を実行した利用者の通話相手がＳＩＰ−ＵＲＩ「０３１１１１１１１１」であることを特定する。なお、ｃａｌｌセッション情報の「Ｆｒｏｍ」から特定する意味は、広告主サーバ２００から通知された発着判定フラグが「着」であったので、その逆の「発」側が通話相手となるからである。

すなわち、推薦情報提供者特定部１３３は、購入処理を実行したアリス（ＳＩＰ−ＵＲＩ「０３２２２２２２２２」）の通話相手がボブ（ＳＩＰ−ＵＲＩ「０３１１１１１１１１」）であること、すなわち、いわゆる推薦情報の提供者がボブであることをｃａｌｌセッション情報を用いて特定する（ステップＳ１０７）。

そして、アフィリエイトサーバ１００の推薦情報提供者特定部１３３は、特定した通話相手（ボブ）を示す情報を、広告主サーバ２００に通知する（ステップＳ１０８）。例えば、推薦情報提供者特定部１３３は、ＳＩＰ−ＵＲＩ「０３１１１１１１１１」を広告主サーバ２００の広告料算出部２３４に通知する。

そして、広告主サーバ２００が、広告料を算出する（ステップＳ１０９）。具体的には、広告主サーバ２００の広告料算出部２３４は、通話相手がＳＩＰ−ＵＲＩ「０３１１１１１１１１」であるとの情報に基づき広告料を算出する。

このようなことから、実施例１に係るＷｅｂサービス制御システムは、ｃａｌｌセッション情報及び発着判定フラグを用いてＷｅｂサービスの提供を制御するとともに、Ｗｅｂサービスにおいて成果を検知すると、成果を実行した利用者の通話相手をｃａｌｌセッション情報及び発着判定フラグを用いて特定する。このため、成果に結びついた閲覧者のアクセスが通話相手から提供された推薦情報を契機とする場合に、その通話相手を特定することが可能になり、通話による口頭コミュニケーションを広告料の算出対象とすることが可能になる。

ここで、上記したステップＳ１０１〜ステップＳ１０４までの処理手順について、図１５を用いて詳細に説明する。

図１５に示すように、まず、両ＳＩＰフォン３０（ＳＩＰ通信部３１）間でＳＩＰ通信が行われ、その結果、ステップＳ２０１において、両ＳＩＰフォン３０間でＳＩＰによって通信（呼）が確立される。

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

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

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

そして、ＨＧＷ１０（サービス利用制御部１３ａ）は、アクセス先変更指示を、特定した情報表示端末２０に対して行う。具体的には、特定した情報表示端末２０に対して、アフィリエイトサーバ１００のＵＲＬにアクセス先を変更するよう指示するリダイレクト指示を、ｃａｌｌセッション情報及び発着判定フラグとともに行う（ステップＳ２０３）。なお、実施例１においては、ＨＧＷ１０がアフィリエイトサーバ１００のＵＲＬを予め記憶部に記憶していることで、当該ＵＲＬにアクセス先を変更するようリダイレクト指示を行うことができる。この結果、情報表示端末２０は、リダイレクト指示を受け、ＨＧＷ１０のＵＲＬからアフィリエイトサーバ１００のＵＲＬにアクセス先を変更する。

すると、情報表示端末２０（サービス利用部２５ａ）はリダイレクトされ、接続先をアフィリエイトサーバ１００に変更し、サービスを開始することを要求するサービス開始要求を、当該アフィリエイトサーバ１００に送信する（ステップＳ２０３）。この時、情報表示端末２０（サービス利用部２５ａ）は、ｃａｌｌセッション情報及び発着判定フラグを、アフィリエイトサーバ１００に送信することになる。

一方、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、情報表示端末２０から送信されたｃａｌｌセッション情報及び発着判定フラグを受信すると、当該ｃａｌｌセッション情報及び発着判定フラグの検証を行う。すなわち、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、ｃａｌｌセッション情報等が真正な情報であることを検証する。例えば、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、ＳＩＰプロキシに問い合わせを行うことで、ｃａｌｌセッション情報等が真正な情報であることを検証する。

続いて、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、検証の結果、ｃａｌｌセッション情報及び発着判定フラグが真正な情報であることを確認すると、当該ｃａｌｌセッション情報、発着判定フラグ、通話情報としての開始時刻を制御用セッション管理テーブル１２３に格納し、制御用セッション情報を発行し、発行した制御用セッション情報を制御用セッション管理テーブル１２３に格納する（ステップＳ２０４）。

続いて、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、サービス開始要求を送信してきた情報表示端末２０が利用可能なサービスをユーザ契約サービス管理テーブル１２１で確認し、サービスＩＤを取得する。そして、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、制御ページを生成する。

続いて、アフィリエイトサーバ１００（ｃａｌｌセッション情報収集部１３１）は、情報表示端末２０に対して、ステップＳ２０４で発行した制御用セッション情報と、生成した制御ページと、取得したサービスＩＤとを送信する。

すると、情報表示端末２０は、アフィリエイトサーバ１００から送信された制御ページをＷｅｂブラウザから表示する（ステップＳ２０５）。なお、発側の情報表示端末２０についても同様の処理が行われる。

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

すると、アフィリエイトサーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０から送信された制御用セッション情報が、制御用セッション管理テーブル１２３に登録されているものであることを確認し、発着間紐付けＩＤを発行する（ステップＳ２０８）。

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

アフィリエイトサーバ１００（発着間紐付けＩＤ発行部１３２）は、情報表示端末２０に対して、広告主サーバ２００のＵＲＬと、発着間紐付けＩＤ及び発着判定フラグとを送信する（ステップＳ２０９）。

一方、情報表示端末２０（サービス利用部２５ａ）は、アフィリエイトサーバ１００から送信されたＵＲＬに接続し、アフィリエイトサーバ１００から送信された発着間紐付けＩＤ及び発着判定フラグを、広告主サーバ２００に送信する（ステップＳ２０９）。

すると、広告主サーバ２００（発着間紐付けＩＤ収集部２３１）は、情報表示端末２０から送信された発着間紐付けＩＤ及び発着判定フラグを受信すると、当該発着間紐付けＩＤ及び発着判定フラグを送信した情報表示端末２０が行うＷｅｂ通信（サービス提供を受けるために情報表示端末２０が広告主サーバ２００との間で行うＷｅｂ通信）に付与する情報として、Ｗｅｂセッション情報を発行し、発行したＷｅｂセッション情報をＷｅｂセッション情報管理テーブル２２１に格納するとともに、発着間紐付けＩＤ及び発着判定フラグを格納する。

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

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

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

［実施例１の効果］
上記してきたように、実施例１に係るＷｅｂサービス制御システムは、複数の利用者間で通話による通信が行われると、通話の関係にある利用者それぞれを特定するｃａｌｌセッション情報及び発着判定フラグと、個々の利用者がＷｅｂサービスの利用に用いる情報表示端末２０それぞれとの対応付けを行い、情報表示端末２０それぞれに提供するＷｅｂサービスが複数の利用者間で連携されるように、ｃａｌｌセッション情報等を用いてＷｅｂサービスの提供を制御する。また、Ｗｅｂサービス制御システムは、複数の利用者間に提供されているＷｅｂサービスにおいて、広告料が支払われるべきものとして設定された所定の処理（成果）がいずれかの情報表示端末２０から実行されたことを検知する。そして、Ｗｅｂサービス制御システムは、所定の処理が実行されたことを検知すると、所定の処理を実行した利用者の通話相手をｃａｌｌセッション情報及び発着判定フラグを用いて特定する。その後、Ｗｅｂサービス制御システムは、特定した利用者を示す情報を、広告料を算出する広告料算出部に通知する。

このようなことから、通話による口頭コミュニケーションを広告料の算出対象とすることが可能になる。

また、口頭コミュニケーションが広告になるため、商品紹介ブログなど、事前に推薦情報のコンテンツを作成する必要がない。また、口頭コミュニケーションが広告になるため、通話相手に合わせた推薦情報を伝えることができ、万人向けの商品紹介ブログよりも広告効果が期待できる。

ところで、実施例１においては、広告料が支払われるべきものとして設定された所定の処理の実行を、広告主サーバ２００が検知する手法を説明してきた。しかしながら、本発明はこれに限られるものではなく、ＨＧＷ１０が検知する手法であってもよい。以下、図１６を用いて、実施例２に係るＷｅｂサービス制御システムの処理手順を説明する。図１６は、実施例２に係るＷｅｂサービス制御システムの処理手順を示すシーケンス図である。

なお、図１６に示すステップＳ３０１〜Ｓ３０９のうち、Ｓ３０１〜Ｓ３０４の処理手順は、図１４に示すステップＳ１０１〜Ｓ１０４と同様に行われるものであるので、説明を割愛する。

実施例２においては、図１６のステップＳ３０５に示すように、ＨＧＷ１０が、配下に接続する情報表示端末２０から、広告料が支払われるべきものとして設定された所定の処理が実行されたことを検知する（ステップＳ３０５）。

例えば、広告主サーバ２００が提供するＷｅｂサービスにおいて、アリスが、アイスクリームの購入処理を実行したとする。この時、アリス側の情報表示端末２０がアイスクリームの購入処理を実行すると、例えば、アリス側の情報表示端末２０は、実施例１と同様、購入完了ページに対応するＵＲＬ（成果成立契機ＵＲＬ）にアクセスするように誘導され、情報表示端末２０の出力部２３には、購入完了ページが表示される。ＨＧＷ１０は、成果成立契機ＵＲＬを予め把握しており、また、情報表示端末２０が広告主サーバ２００にアクセスする際にはＨＧＷ１０を経由する。このため、ＨＧＷ１０は、アリス側の情報表示端末２０から成果成立契機ＵＲＬに対するアクセスがあったことをもって、成果成立を検知することができる。

すなわち、ＨＧＷ１０は、成果成立契機ＵＲＬにアクセスした情報表示端末２０の情報表示端末ＩＤを用いてブラウザセッション情報管理テーブル１２ａを参照し、当該情報表示端末ＩＤに対応付けて記憶されているｃａｌｌセッション情報及び発着判定フラグを特定する。例えば、ＨＧＷ１０は、情報表示端末ＩＤ「ＪＯＨＯａａａ」を用いてブラウザセッション情報管理テーブル１２ａを参照し、情報表示端末ＩＤ「ＪＯＨＯａａａ」に対応付けて記憶されているｃａｌｌセッション情報及び発着判定フラグ「着」を特定する。

続いて、ＨＧＷ１０、配下の情報表示端末２０から購入処理が実行されたことを検知した旨をアフィリエイトサーバ１００に通知する（ステップＳ３０６）。具体的には、ＨＧＷ１０は、ステップＳ３０５において特定したｃａｌｌセッション情報及び発着判定フラグを通知する。

すると、アフィリエイトサーバ１００が、購入処理を実行した利用者の通話相手を通話情報を用いて特定し（ステップＳ３０７）、特定した通話相手を広告主サーバ２００に通知する（ステップＳ３０８）。

具体的には、アフィリエイトサーバ１００の推薦情報提供者特定部１３３は、まず、ｃａｌｌセッション情報及び発着判定フラグを用いて制御用セッション管理テーブル１２３を参照し、ｃａｌｌセッション情報及び発着判定フラグから通話相手を特定する。例えば、推薦情報提供者特定部１３３は、ｃａｌｌセッション情報の「Ｆｒｏｍ」から、購入処理を実行した利用者の通話相手がＳＩＰ−ＵＲＩ「０３１１１１１１１１」であることを特定する。

すなわち、推薦情報提供者特定部１３３は、購入処理を実行したアリス（ＳＩＰ−ＵＲＩ「０３２２２２２２２２」）の通話相手がボブ（ＳＩＰ−ＵＲＩ「０３１１１１１１１１」）であること、すなわち、いわゆる推薦情報の提供者がボブであることをｃａｌｌセッション情報を用いて特定する（ステップＳ３０７）。

そして、その後は、実施例１と同様に、アフィリエイトサーバ１００の推薦情報提供者特定部１３３が、特定した通話相手（ボブ）を示す情報を、広告主サーバ２００に通知すると（ステップＳ３０８）、広告主サーバ２００の広告料算出部２３４が、通話相手がＳＩＰ−ＵＲＩ「０３１１１１１１１１」であるとの情報に基づき広告料を算出する（ステップＳ３０９）。

［実施例２の効果］
このようなことから、実施例２に係るＷｅｂサービス制御システムは、実施例１と同様に、成果に結びついた閲覧者のアクセスが通話相手から提供された推薦情報を契機とする場合に、その通話相手を特定することが可能になり、通話による口頭コミュニケーションを広告料の算出対象とすることが可能になる。

また、広告主サーバ２００が成果を検知する手法ではなくＨＧＷ１０が検知する手法であることから、まず、広告主サーバ２００が成果検知の機能を備えなくてよいという効果が得られる。また、広告主サーバ２００を運営するＥＣサイト側の不正（例えば、広告費を削減するために成果を正しくカウントしないなど）を防止するといった効果が得られる。さらに、例えば、広告主サーバ２００が、複数の成果成立契機ＵＲＬを分散して保有したり、移行を行う場合などには（例えば、自広告主サーバ２００に保有していた成果成立契機ＵＲＬを次の月には第三者のサーバに移行した場合など）、成果の重複カウントやカウント漏れなど、カウントが正確に行われないおそれがある。この点、ＨＧＷ１０が検知する手法であれば、一元的に検知することができるため、成果を正確にカウントすることができるといった効果も得られる。

ところで、実施例１においては、広告料が支払われるべきものとして設定された所定の処理の実行を、広告主サーバ２００が検知する手法を説明し、実施例２においては、ＨＧＷ１０が検知する手法を説明してきた。しかしながら、本発明はこれに限られるものではなく、アフィリエイトサーバ１００が検知する手法であってもよい。以下、図１７を用いて、実施例３に係るＷｅｂサービス制御システムの処理手順を説明する。図１７は、実施例３に係るＷｅｂサービス制御システムの処理手順を示すシーケンス図である。

なお、図１７に示すステップＳ４０１〜Ｓ４０８のうち、Ｓ４０１〜Ｓ４０４の処理手順は、図１４に示すステップＳ１０１〜Ｓ１０４と同様に行われるものであるので、説明を割愛する。

実施例３においては、図１７のステップＳ４０５に示すように、アフィリエイトサーバ１００が、いずれかの情報表示端末２０から、広告料が支払われるべきものとして設定された所定の処理が実行されたことを検知する（ステップＳ４０５）。

例えば、広告主サーバ２００が提供するＷｅｂサービスにおいて、アリスが、アイスクリームの購入処理を実行したとする。この時、アリス側の情報表示端末２０がアイスクリームの購入処理を実行すると、例えば、アリス側の情報表示端末２０は、実施例１と同様、購入完了ページに対応するＵＲＬ（成果成立契機ＵＲＬ）にアクセスするように誘導され、情報表示端末２０の出力部２３には、購入完了ページが表示される。

アフィリエイトサーバ１００が成果成立契機ＵＲＬを予め把握しているものとし、また、アフィリエイトサーバ１００が情報表示端末２０のアクセス先を把握できるものとすれば、アフィリエイトサーバ１００は、アリス側の情報表示端末２０から成果成立契機ＵＲＬに対するアクセスがあったことをもって、成果成立を検知することができるはずである。もっとも、アフィリエイトサーバ１００が情報表示端末２０のアクセス先を把握するには、別途仕組みが必要になる。

そこでこの仕組みについて説明すると、図１５を用いて説明したように、アフィリエイトサーバ１００は、情報表示端末２０に対して制御ページを送信している(ステップＳ２０４)。例えば、アフィリエイトサーバ１００は、この制御ページに、情報表示端末２０の接続先を監視し、当該接続先を定期的にアフィリエイトサーバ１００に送信するプログラム（例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイル）を埋め込むことができる。すると、情報表示端末２０は、アフィリエイトサーバ１００から送信された当該プログラムをインストールすることで、アフィリエイトサーバ１００との間で通信を確立し、当該プログラムは、監視した接続先のＵＲＬをポーリングによってアフィリエイトサーバ１００に定期的に送信する。このような仕組みが情報表示端末２０に備えられれば、アリス側の情報表示端末２０が成果成立契機ＵＲＬにアクセスした旨は、当該プログラムによってアフィリエイトサーバ１００に通知されるので、アフィリエイトサーバ１００は、成果成立を検知することができることになる。

すると、アフィリエイトサーバ１００は、成果成立契機ＵＲＬにアクセスした情報表示端末２０の制御用セッション情報を用いて制御用セッション管理テーブル１２３を参照し、当該制御用セッション情報に対応付けて記憶されているｃａｌｌセッション情報及び発着判定フラグを特定する。例えば、アフィリエイトサーバ１００は、制御用セッション情報「３３３３３３３３３３」を用いて制御用セッション管理テーブル１２３を参照し、制御用セッション情報「３３３３３３３３３３」に対応付けて記憶されているｃａｌｌセッション情報及び発着判定フラグ「着」を特定する。

続いて、アフィリエイトサーバ１００は、購入処理を実行した利用者の通話相手を通話情報を用いて特定し（ステップＳ４０６）、特定した通話相手を広告主サーバ２００に通知する（ステップ４０７）。

具体的には、アフィリエイトサーバ１００の推薦情報提供者特定部１３３は、ｃａｌｌセッション情報及び発着判定フラグから通話相手を特定する。例えば、推薦情報提供者特定部１３３は、ｃａｌｌセッション情報の「Ｆｒｏｍ」から、購入処理を実行した利用者の通話相手がＳＩＰ−ＵＲＩ「０３１１１１１１１１」であることを特定する。

すなわち、推薦情報提供者特定部１３３は、購入処理を実行したアリス（ＳＩＰ−ＵＲＩ「０３２２２２２２２２」）の通話相手がボブ（ＳＩＰ−ＵＲＩ「０３１１１１１１１１」）であること、すなわち、いわゆる推薦情報の提供者がボブであることをｃａｌｌセッション情報を用いて特定する（ステップＳ４０６）。

そして、その後は、実施例１と同様に、アフィリエイトサーバ１００の推薦情報提供者特定部１３３が、特定した通話相手（ボブ）を示す情報を、広告主サーバ２００に通知すると（ステップＳ４０７）、広告主サーバ２００の広告料算出部２３４が、通話相手がＳＩＰ−ＵＲＩ「０３１１１１１１１１」であるとの情報に基づき広告料を算出する（ステップＳ４０８）。

［実施例３の効果］
このようなことから、実施例３に係るＷｅｂサービス制御システムは、実施例１と同様に、成果に結びついた閲覧者のアクセスが通話相手から提供された推薦情報を契機とする場合に、その通話相手を特定することが可能になり、通話による口頭コミュニケーションを広告料の算出対象とすることが可能になる。

また、広告主サーバ２００が成果を検知する手法ではなくアフィリエイトサーバ１００が検知する手法であることから、まず、広告主サーバ２００が成果検知の機能を備えなくてよいという効果が得られる。また、広告主サーバ２００を運営するＥＣサイト側の不正（例えば、広告費を削減するために成果を正しくカウントしないなど）を防止するといった効果が得られる。さらに、例えば、広告主サーバ２００が、複数の成果成立契機ＵＲＬを分散して保有したり、移行を行う場合などには（例えば、自広告主サーバ２００に保有していた成果成立契機ＵＲＬを次の月には第三者のサーバに移行した場合など）、成果の重複カウントやカウント漏れなど、カウントが正確に行われないおそれがある。この点、アフィリエイトサーバ１００が検知する手法であれば、一元的に検知することができるため、成果を正確にカウントすることができるといった効果も得られる。

次に、実施例４に係るＷｅｂサービス制御システムを説明する。実施例４に係るＷｅｂサービス制御システムは、図１８に示すように、アフィリエイトサーバ１００が、アフィリエイトの履歴情報を管理し、履歴情報を用いてさらに付加価値のあるアフィリエイトを実現している。すなわち、実施例４によれば、通話相手の成果状況に基づく広告表示が可能になり（「アリス用広告」、「ボブ用広告」を参照）、また、成果状況に応じた広告料や割引料の算出が可能になる。なお、図１８は、実施例４に係るＷｅｂサービス制御システムの概要を説明するための図である。

［実施例４に係るＷｅｂサービス制御システムの構成］
まず、図１９〜図２３を用いて、実施例４に係るＷｅｂサービス制御システムの構成を説明する。図１９は、実施例４におけるアフィリエイトサーバの構成を示すブロック図であり、図２０は、契約情報テーブルを説明するための図であり、図２１は、広告料情報テーブルを説明するための図であり、図２２は、成果テーブルを説明するための図であり、図２３は、報酬テーブルを説明するための図である。

図１９に示すように、実施例４におけるアフィリエイトサーバ１００は、記憶部１２０に、契約情報テーブル１２５、広告料情報テーブル１２６、成果テーブル１２７、報酬テーブル１２８をさらに備える。

契約情報テーブル１２５は、広告料情報テーブル１２６とともに、アフィリエイトに関する契約情報を管理するテーブルである。例えば、図２０に示すように、契約情報テーブル１２５は、サービスＩＤと成果成立契機ＵＲＬと広告料情報ＩＤと成果報酬期間とを対応付けて記憶する。契約情報テーブル１２５は、例えば、広告主から通知された情報がアフィリエイトサーバの運用者によって予め登録されることで、これらの情報を記憶する。

広告料情報テーブル１２６は、広告料に関する情報を管理するテーブルである。例えば、図２１に示すように、広告料情報テーブル１２６は、広告料情報ＩＤと、広告料と、推薦情報提供者の条件と、購入者の条件とを対応付けて記憶する。広告料情報テーブル１２６は、例えば、広告主から通知された情報がアフィリエイトサーバの運用者によって予め登録されることで、これらの情報を記憶する。

成果テーブル１２７は、成果に関する履歴情報を管理するテーブルである。例えば、図２２に示すように、成果テーブル１２７は、成果ＩＤと購入者のユーザＩＤと推薦情報提供者のユーザＩＤと発着間紐付けＩＤと成果成立サービスＩＤとタイムスタンプとを対応付けて記憶する。

報酬テーブル１２８は、利用者に支払われる広告料の算出基準となる獲得ポイントを管理するテーブルである。例えば、図２３に示すように、報酬テーブル１２８は、ユーザＩＤと成果ＩＤと発着間紐付けＩＤと成果成立ＩＤと獲得ポイントとタイムスタンプとを対応付けて記憶する。

また、図１９に示すように、実施例４におけるアフィリエイトサーバ１００は、制御部１３０に、広告生成部１３４、履歴登録部１３５をさらに備える。

広告生成部１３４は、広告ページを生成する。具体的には、広告生成部１３４は、ｃａｌｌセッション情報収集部１３１によって取得されたｃａｌｌセッション情報に基づき利用者のユーザＩＤを特定し、契約情報テーブル１２５や成果テーブル１２７を参照することで得られた情報を用いて、利用者毎の広告ページを生成する。

履歴登録部１３５は、履歴情報を登録する。具体的には、履歴登録部１３５は、成果テーブル１２７や報酬テーブル１２８に履歴情報を登録する。

［実施例４に係るＷｅｂサービス制御システムによる処理手順］
続いて、図２４及び図２５を用いて、実施例４に係るＷｅｂサービス制御システムによる処理手順を説明する。図２４は、広告生成の処理手順を示すシーケンス図であり、図２５は、履歴登録の処理手順を示すシーケンス図である。

図２４に示す広告生成の処理手順は、図１５を用いて説明した処理手順と比較した場合に、ステップＳ２０１〜Ｓ２０４に続く処理が異なっている。すなわち、図２４に示すステップＳ５０１〜Ｓ５０４の処理手順は、図１５に示すステップＳ２０１〜Ｓ２０４の処理手順と同一であり、その後図１５に示す処理手順においては、情報表示端末２０において制御ページが表示されていたが、これに代わり、実施例４においては、通話相手の成果状況に基づく広告ページが表示されることになる。ステップＳ５０５〜Ｓ５０８は、広告ページを生成するまでの処理手順である。

そこで、ステップＳ５０５〜Ｓ５０８の処理手順を説明すると、アフィリエイトサーバ１００の広告生成部１３４は、ユーザ情報を取得する（ステップＳ５０５）。具体的には、広告生成部１３４は、ステップＳ５０３において取得したｃａｌｌセッション情報からユーザＩＤ（ＳＩＰ−ＵＲＩ）を特定し、特定したユーザＩＤを用いてユーザ契約サービス管理テーブル１２１を参照し、当該ユーザＩＤに対応付けて記憶されているサービスＩＤを取得する。

次に、広告生成部１３４は、契約情報を取得する（ステップＳ５０６）。具体的には、広告生成部１３４は、ステップＳ５０５において取得したサービスＩＤを用いて契約情報テーブル１２５を参照し、まず、当該サービスＩＤに対応付けて記憶されている成果報酬期間と現在の日時とを比較し、現在の日時が成果報酬期間内であるか否かを判定する。成果報酬期間内である場合には、広告生成部１３４は、当該サービスＩＤに対応付けて記憶されている成果成立契機ＵＲＬと広告料情報ＩＤとを取得する。

続いて、広告生成部１３４は、成果情報を取得する（ステップＳ５０７）。具体的には、広告生成部１３４は、ユーザＩＤを用いて成果テーブル１２７を参照する。そして、広告生成部１３４は、ユーザＩＤが購入者のユーザＩＤとして存在する場合には、当該ユーザＩＤに対応付けて記憶されている推薦情報提供者のユーザＩＤ及び成果成立サービスＩＤを取得する。一方、広告生成部１３４は、ユーザＩＤが推薦情報提供者のユーザＩＤとして存在する場合には、当該ユーザＩＤに対応付けて記憶されている成果成立サービスＩＤを取得する。

そして、広告生成部１３４は、広告ページを生成する（ステップＳ５０８）。具体的には、広告生成部１３４は、例えば、ステップＳ５０７において推薦情報提供者のユーザＩＤ及び成果成立サービスＩＤを取得している場合には、広告ページ上に、そのサービスＩＤのサービスを利用するためのアイコンを生成し、さらに、推薦情報提供者のユーザＩＤによって識別される利用者に関する情報を併せて生成するなどする。例えば、広告生成部１３４は、図１８のアリス用広告に示すように、アイスクリームを販売する広告主サーバにアクセスするためのアイコンを表示するとともに、「ボブも利用中」といった情報（その他紹介割引があることを示す情報など）を併せて表示する広告ページを生成する。ここで、アイコンには、成果成立契機ＵＲＬへの導線が張られたＵＲＬが埋め込まれる。すなわち、成果成立契機ＵＲＬとは、例えば購入完了ページのＵＲＬである。このため、アリス用広告のアイコンには、購入完了ページへの導線が張られたＵＲＬとして、例えばアイスクリームの販売を展開するトップページのＵＲＬが埋め込まれる。もっとも、ＥＣサイトのトップページを表示させること自体が成果になる場合には、アイコンに、成果成立契機ＵＲＬ自体が埋め込まれることもある。なお、広告生成部１３４は、成果成立契機ＵＲＬへの導線が張られたＵＲＬを別途管理することで、アイコンに埋め込むことができる。また、広告生成部１３４は、例えば、ユーザＩＤと「ボブ」とを対応づけて別途管理することで、「ボブも利用中」といった文言の情報を生成することができる。

一方、広告生成部１３４は、例えば、ステップＳ５０７において成果成立サービスＩＤのみを取得している場合には、図１８のボブ用広告に示すように、広告ページ上に、そのサービスＩＤのサービスを利用するためのアイコンを生成し、さらに、「アフィリエイトチャンス」といった情報（その他経験者ボーナスが適用されることを示す情報など）を併せて表示する広告ページを生成する。成果報酬期間の情報を併せて表示してもよい。なお、アイコンに成果成立契機ＵＲＬへの導線が張られたＵＲＬが埋め込まれる点は、アリス用広告と同様である。

そして、発着間紐付けＩＤ発行部１３２が、広告生成部１３４によって生成された広告ページを情報表示端末２０に対して送信し（ステップＳ５０９）、情報表示端末２０においては、広告ページが表示される。なお、この時、発着間紐付けＩＤ発行部１３２は、広告ページとともに、ステップＳ５０４で発行した制御用セッション情報を送信する。

図２５に示す履歴登録の処理手順は、図１４を用いて説明した処理手順のうち、ステップＳ１０７の推薦情報提供者特定の処理と、ステップＳ１０８の推薦情報提供者通知の処理との間に、新たに履歴登録の処理Ｓ６０２〜Ｓ６０４が行われる点が異なっている。すなわち、図２５に示すように、ステップＳ６０１と図１４のステップＳ１０７とが対応し、ステップＳ６０５と図１４のステップＳ１０８とが対応する。

そこで、ステップＳ６０２〜Ｓ６０４の処理手順を説明すると、アフィリエイトサーバ１００の履歴登録部１３５は、成果が成立したサービスＩＤを用いて契約情報テーブル１２５を参照し、当該サービスＩＤに対応付けて記憶されている広告料情報ＩＤ及び成果報酬期間を取得する（ステップＳ６０２）。また、履歴登録部１３５は、制御用セッション管理テーブル１２３を参照し、制御用セッション管理テーブル１２３に記憶されている通話情報と成果報酬期間とを比較することで、報酬期間内であるか否かを判定する。

報酬期間内である場合、履歴登録部１３５は、成果テーブル１２７及び報酬テーブル１２８に履歴情報を登録する。

具体的には、まず、履歴登録部１３５は、成果テーブル１２７に新たな成果ＩＤを付与したレコードを挿入し、購入者のユーザＩＤと、推薦情報提供者のユーザＩＤと、発着間紐付けＩＤと、成果成立サービスＩＤと、タイムスタンプとを対応付けて格納する（ステップＳ６０３）。

また、履歴登録部１３５は、報酬テーブル１２８に、推薦情報提供者のユーザＩＤと、ステップＳ６０３において新たに付与した成果ＩＤと、発着間紐付けＩＤと、成果成立ＩＤと、タイムスタンプとを対応付けて格納する（ステップＳ６０４）。また、履歴登録部１３５は、ステップＳ６０２において取得した広告料情報ＩＤを用いて広告料情報テーブル１２６をさらに参照し、当該広告料情報ＩＤに対応付けて記憶されている広告料を獲得ポイントとして報酬テーブル１２８に格納する。なお、広告料情報テーブル１２６には、推薦情報提供者や購入者の条件が規定されているが、これは、報酬テーブル１２８を参照することによって、推薦情報提供者が過去にも同一のサービスについて成果を成立させた経験があるか否かで判定することができる。

［実施例４の効果］
上記してきたように、実施例４に係るＷｅｂサービス制御システムは、所定の処理（成果）が実行されたことに関する履歴情報を記憶する成果テーブル１２７や報酬テーブル１２８をさらに備える。そして、Ｗｅｂサービス制御システムは、Ｗｅｂサービスの提供を制御する際に、成果テーブル１２７や報酬テーブル１２８に記憶されている履歴情報をさらに用いて制御する。

例えば、所定の広告（経験者ボーナス、紹介割引など）が掲載された広告ページを履歴情報に基づき生成し、生成した広告ページを情報表示端末２０それぞれに送信する。また、例えば、広告料として、履歴情報に応じて異なる金額が設定されている場合に、履歴情報に基づき広告料を算出する。

このようなことから、例えば、購入経験の保障ができ、広告を通じて口コミにお墨付きができる。また、推薦情報提供者の成果履歴を蓄積することで、成果履歴に応じて広告料や料金を変更することもでき、柔軟な広告プロモーションに寄与する。

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

［成果検知］
上記した実施例１〜実施例４では、広告料が支払われるべきものとして設定された所定の処理の実行（成果）を、広告主サーバ２００、ＨＧＷ１０、アフィリエイトサーバ１００それぞれで検知する手法を説明してきたが、本発明はこれに限られるものではない。例えば、複数の装置で検知し、検知した内容を照合して整合性を検証してもよい。このような場合には、通知の整合性を検証することができ、不正を防止することができる。

［広告料算出］
また、上記した実施例１〜実施例４では、広告料の算出が広告主サーバ２００において行われる手法を説明してきたが、本発明はこれに限られるものではない。例えば、広告料の算出は、アフィリエイトサーバ１００において行われてもよい。すなわち、アフィリエイトサーバ１００が、例えばサービス提供事業者からの委託を受けて、広告料の算出まで実行してもよい。

［履歴情報の重複検証］
また、上記した実施例１〜実施例４では、推薦情報提供者を特定するとそのまま広告料算出部に通知していたが、本発明はこれに限られるものではない。例えば、実施例４のように履歴情報を管理している場合には、例えば成果テーブル１２７を参照し、重複する履歴情報の有無を検証してから通知してもよい。このような場合には、アフィリエイトのポイントを不正に獲得することを防止することができる。

［成果成立契機ＵＲＬ］
また、上記した実施例１〜４では、成果成立契機ＵＲＬが広告主サーバ２００の管理下にあることを想定していたが、本発明はこれに限られるものではない。例えば、ショッピング機能を他社に委託するＥＣサイトも存在するのであって（例えば、個人商店がレンタルショッピングカート会社に委託するなど）、成果成立契機ＵＲＬが他のサーバの管理下にある場合もある。

例えば、アフィリエイトサーバ１００が、販売処理及び決済処理を管理している場合を想定する。すなわち、成果成立契機ＵＲＬは、アフィリエイトサーバ１００の管理下にある。すると、アフィリエイトサーバ１００は、情報表示端末２０による成果成立契機ＵＲＬへのアクセスを、管理下のＵＲＬへのアクセスとして検知することができる。その後は上記した実施例３と同様、アフィリエイトサーバ１００は、成果成立契機ＵＲＬにアクセスした情報表示端末２０の制御用セッション情報を用いて制御用セッション管理テーブル１２３を参照し、当該制御用セッション情報に対応付けて記憶されているｃａｌｌセッション情報及び発着判定フラグを特定すればよい。

また、例えば、広告主サーバ２００でもアフィリエイトサーバ１００でもない第三者のサーバが、販売処理及び決済処理を管理している場合を想定する。すなわち、成果成立契機ＵＲＬは、第三者サーバの管理下にある。この場合には、例えば、実施例２と同様、ＨＧＷ１０が、成果成立契機ＵＲＬを予め把握しているものとすれば、情報表示端末２０が広告主サーバ２００にアクセスする際にはＨＧＷ１０を経由する結果、ＨＧＷ１０は、アリス側の情報表示端末２０から成果成立契機ＵＲＬに対するアクセスがあったことをもって、成果成立を検知することができる。その後は上記した実施例２と同様、ＨＧＷ１０は、成果成立契機ＵＲＬにアクセスした情報表示端末２０の情報表示端末ＩＤを用いてブラウザセッション情報管理テーブル１２ａを参照し、当該情報表示端末ＩＤに対応付けて記憶されているｃａｌｌセッション情報及び発着判定フラグを特定すればよい。

１０ ＨＧＷ
１１ ＳＩＰ通信部／ＨＴＴＰ通信部
１２ 記憶部
１２ａ ブラウザセッション情報管理テーブル
１３ 制御部
１３ａ サービス利用制御部
２０ 情報表示端末
２１ ＨＴＴＰ通信部
２２ 入力部
２３ 出力部
２４ 入出力制御Ｉ／Ｆ部
２５ 制御部
２５ａ サービス利用部
３０ ＳＩＰフォン
３１ ＳＩＰ通信部
３２ 入力部
３３ 出力部
３４ 入出力制御Ｉ／Ｆ部
１００ アフィリエイトサーバ
１１０ 通信部
１２０ 記憶部
１２１ ユーザ契約サービス管理テーブル
１２２ 契約サービス情報テーブル
１２３ 制御用セッション管理テーブル
１２４ 発着間紐付けＩＤテーブル
１２５ 契約情報テーブル
１２６ 広告料情報テーブル
１２７ 成果テーブル
１２８ 報酬テーブル
１３０ 制御部
１３１ ｃａｌｌセッション情報収集部
１３２ 発着間紐付けＩＤ発行部
１３３ 推薦情報提供者特定部
１３４ 広告生成部
１３５ 履歴登録部
２００ 広告主サーバ
２１０ 通信部
２２０ 記憶部
２２１ Ｗｅｂセッション情報管理テーブル
２３０ 制御部
２３１ 発着間紐付けＩＤ収集部
２３２ サービス提供制御部
２３３ 成果検知部
２３４ 広告料算出部

Claims (6)

1. 複数の利用者間で通話による通信が行われると、当該通話の関係にある利用者それぞれを特定する通話情報と個々の利用者がＷｅｂサービスの利用に用いる端末それぞれとの対応付けを行い、当該端末それぞれに提供するＷｅｂサービスが当該複数の利用者間で連携されるように、当該通話情報を用いてＷｅｂサービスの提供を制御するＷｅｂサービス制御手段と、
   前記Ｗｅｂサービス制御手段によって前記複数の利用者間に提供されているＷｅｂサービスにおいて、広告料が支払われるべきものとして設定された所定の処理がいずれかの端末から実行されたことを検知する検知手段と、
   前記検知手段によって前記所定の処理が実行されたことが検知されると、当該所定の処理を実行した利用者の通話相手を、前記通話情報を用いて特定する通話相手特定手段と、
   前記通話相手特定手段によって特定された利用者を示す情報を、前記広告料を算出する広告料算出手段に通知する通知手段と
   を備えたことを特徴とするＷｅｂサービス制御システム。
2. 前記所定の処理が実行されたことに関する履歴情報を記憶する履歴情報記憶手段をさらに備え、
   前記Ｗｅｂサービス制御手段は、前記Ｗｅｂサービスの提供を制御する際に、前記履歴情報記憶手段に記憶されている履歴情報をさらに用いて制御することを特徴とする請求項１に記載のＷｅｂサービス制御システム。
3. 前記Ｗｅｂサービス制御手段は、所定の広告が掲載された広告ページを、前記履歴情報記憶手段によって記憶されている履歴情報に基づき生成し、生成した当該広告ページを前記端末それぞれに送信することを特徴とする請求項２に記載のＷｅｂサービス制御システム。
4. 前記広告料は、履歴情報に応じて異なる金額が設定されているものであって、
   前記広告料算出手段は、前記履歴情報記憶手段によって記憶されている履歴情報に基づき広告料を算出することを特徴とする請求項２に記載のＷｅｂサービス制御システム。
5. 前記通知手段は、前記通話相手特定手段によって特定された利用者を示す情報を前記広告料算出手段に通知する際に、前記履歴情報記憶手段によって記憶されている履歴情報を参照し、重複する履歴情報の有無を検証してから通知することを特徴とする請求項２に記載のＷｅｂサービス制御システム。
6. コンピュータが、
   複数の利用者間で通話による通信が行われると、当該通話の関係にある利用者それぞれを特定する通話情報と個々の利用者がＷｅｂサービスの利用に用いる端末それぞれとの対応付けを行い、当該端末それぞれに提供するＷｅｂサービスが当該複数の利用者間で連携されるように、当該通話情報を用いてＷｅｂサービスの提供を制御するＷｅｂサービス制御工程と、
   前記Ｗｅｂサービス制御工程によって前記複数の利用者間に提供されているＷｅｂサービスにおいて、広告料が支払われるべきものとして設定された所定の処理がいずれかの端末から実行されたことを検知する検知工程と、
   前記検知工程によって前記所定の処理が実行されたことが検知されると、当該所定の処理を実行した利用者の通話相手を、前記通話情報を用いて特定する通話相手特定工程と、
   前記通話相手特定工程によって特定された利用者を示す情報を、前記広告料を算出する広告料算出工程に通知する通知工程と
   を含んだことを特徴とするＷｅｂサービス制御方法。

Images