JP5445606B2 - 広告提供システム、広告制御装置、及び広告制御プログラム - Google Patents

Description

本発明は、通信ネットワークを通じて広告を提供ないし制御する技術に関する。

通信ネットワークに接続された端末装置にウェブ（Web）サーバからバナー広告等を送信し、端末装置上で動作するウェブブラウザ等のソフトウェア上で広告表示（バナー広告）させ、これを選択（例えばクリックやタップ）することで広告サーバから広告対象の商品（以下サービスも含む）等の詳細な情報を受け、当該商品の購入まで誘導するサービスが行なわれている。

上記のような広告サービスでは、広告閲覧者から受信する広告の要求情報に広告媒体提供者を特定する情報を含めることで、どの広告媒体提供者からの広告が閲覧されたのか特定し、広告料を複数の広告媒体提供者で適切に分配するようにしている（例えば下記特許文献１参照）。

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

上記従来技術によれば、広告閲覧者からの広告の要求情報によって広告閲覧者が希望する広告のみを端末装置に送信するものであるため、どの広告対象の商品等の広告を見せるべきか又は広告量を増やしたり減らしたりする等の、効果的な広告量の調整を行なうことはできなかった。

本発明の目的の一つは、効果的な広告量の調整を行なえるようにすることにある。

なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の一つとして位置付けることができる。

本発明の広告提供システムの一態様は、端末装置に対して通信ネットワークを介して複数の電子商品のいずれかに関する広告情報を前記端末装置に提供する広告提供システムである。当該システムは、前記複数の電子商品毎の可変パラメータを記憶するパラメータ記憶手段と、いずれかの前記電子商品に関する情報を含む広告情報を記憶する広告情報記憶手段と、前記広告情報をいずれかの電子商品に関連付けて前記端末装置へ送信する送信手段と、前記送信された広告情報が前記端末装置において利用されたことを示す利用情報を前記端末装置から受信する受信手段と、前記受信手段で前記利用情報が受信されると、前記広告情報を関連付けた電子商品に対応する可変パラメータ及び／又は前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを更新し、前記更新後の前記各可変パラメータに基づいて、前記送信手段を通じて送信する電子商品に関連付ける広告情報を制御する制御手段と、を備える。

ここで、前記利用情報には、前記端末装置で前記広告情報を選択したことを示す閲覧情報及び／又は前記広告情報を通じて前記広告情報に含まれる情報としての電子商品を導入処理したことを示す導入情報が含まれてよく、前記制御手段は、前記閲覧情報と前記導入情報とで前記可変パラメータの更新度合いを異ならせる、ようにしてもよい。

また、前記パラメータ記憶手段は、前記電子商品の価格に対応した価格パラメータを記憶しており、前記制御手段は、前記価格パラメータによって前記可変パラメータの更新度合いを異ならせる、ようにしてもよい。

さらに、前記更新は、前記広告情報を関連付けた電子商品に対応する可変パラメータを増加または減少し、かつ、前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを減少または増加することを含んでよい。

また、本発明の広告制御装置の一態様は、上述した広告提供システムに用いられる広告制御装置である。当該広告制御装置は、前記複数の電子商品毎の可変パラメータを記憶するパラメータ記憶手段と、いずれかの前記電子商品に関する情報を含む広告情報を記憶する広告情報記憶手段と、前記広告情報をいずれかの電子商品に関連付けて前記端末装置へ送信する送信手段と、前記送信された広告情報が前記端末装置において利用されたことを示す利用情報を前記端末装置から受信する受信手段と、前記受信手段で前記利用情報が受信されると、前記広告情報を関連付けた電子商品に対応する可変パラメータ及び／又は前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを更新し、前記更新後の前記各可変パラメータに基づいて、前記送信手段を通じて送信する電子商品に関連付ける広告情報を制御する制御手段と、を備える。

さらに、本発明の広告制御プログラムの一態様は、上述した広告制御装置としてコンピュータを機能させる広告制御プログラムである。当該広告制御プログラムは、前記コンピュータに、前記複数の電子商品毎の可変パラメータを記憶する処理と、いずれかの前記電子商品に関する情報を含む広告情報を記憶する処理と、前記広告情報をいずれかの電子商品に関連付けて前記端末装置へ送信する処理と、前記送信された広告情報が前記端末装置において利用されたことを示す利用情報を前記端末装置から受信する処理と、前記利用情報が受信されると、前記広告情報を関連付けた電子商品に対応する可変パラメータ及び／又は前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを更新し、前記更新後の前記各可変パラメータに基づいて、前記送信する電子商品に関連付ける広告情報を制御する処理と、を実行させる。

一実施形態に係る広告提供システムの構成例を示す図である。 本実施形態において電子商品の一例である４つのアプリケーション間で送客／集客が行なわれる様子を例示する図である。 本実施形態においてアプリケーション毎の送集客ポイントを例示する図である。 図１に例示する端末の構成例を示すブロック図である。 図１に例示する広告制御サーバのハードウェア的構成例を示すブロック図である。 図５に例示する広告制御サーバの機能的な構成例を示すブロック図である。 本実施形態に係るシステム全体フローを説明するフローチャートである。 図７に例示するユーザ認証処理の一例を説明する図である。 図７に例示するバナー処理の一例を説明する図である。 図７に例示するバナー処理の一例を説明する図である。 図７に例示するバナー処理の一例を説明する図である。 図７に例示するオファー処理の一例を説明する図である。 図７に例示するオファー処理の一例を説明する図である。 図７に例示するオファー処理の一例を説明する図である。 図９に例示する送集客バランス処理（バナーケース）の一例を示すフローチャートである。 図１２に例示する送集客バランス処理（オファーケース）の一例を示すフローチャートである。 本実施形態に係る通常バナーの表示例を示す図である。 図１７に例示する通常バナーの変形例を示す図である。 本実施形態に係るキャンペーンバナーの表示例を示す図である。 本実施形態に係るオファーページの表示例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形（各実施例を組み合わせる等）して実施することができる。また、以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付して表している。図面は模式的なものであり、必ずしも実際の寸法や比率・数量等とは一致するものではなく、また、個々の構成等は同等の機能を持つ別の構成に置き換えが可能である。図面相互間においても互いの寸法の関係や比率等が異なる部分が含まれていることがある。

〔１〕システム構成例
図１は、一実施形態に係る広告提供システムの構成例を示す図である。図１に示す広告提供システム１は、複数の電子的な商品情報（以下「電子商品」ともいう。）および電子商品に関する情報を含む広告情報（バナー広告等）を端末装置２０に対して通信ネットワーク１０を介して提供するシステムである。

当該システム１は、例示的に、通信ネットワーク１０と、１又は複数の端末装置（以下、単に「端末」という）２０と、１又は複数の商品サーバ３０と、決済サーバ４０と、広告制御サーバ５０と、を備える。

端末２０は、ＰＣ（Personal Computer）やＰＤＡ（Personal Digital Assistant）、携帯電話、スマートフォン、タブレット型コンピュータ等のインテリジェントデバイスである。端末２０は、必要に応じてネットワーク１０を経由して、商品サーバ３０や決済サーバ４０、広告制御サーバ５０と通信することができる。端末２０のハードウェア構成例については図４により後述する。

通信ネットワーク（以下、単に「ネットワーク」ともいう。）１０は、無線ネットワークでも有線ネットワークでもよい。ネットワーク１０の一例としては、無線ＬＡＮや赤外線通信、３Ｇ、ＷｉＭａｘ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ｃ．Ｌｉｎｋ（登録商標）、ＨＤＭＩ（登録商標）、有線ＬＡＮ、電話線、携帯電話網、ＰＨＳ網、電灯線ネットワーク、ＩＥＥＥ１３９４等に準拠したネットワークが挙げられる。

商品サーバ３０は、電子的な商品情報（例えばゲーム等のアプリケーションプログラム）を格納、管理する電子商品格納手段の一例であるサーバコンピュータである。商品サーバ３０は、端末２０からのネットワーク１０を経由した要求等に応じて商品情報（以下「電子商品」ともいう）を当該端末２０に提供（送信）することができる。なお、電子商品には、音楽や画像、文章等のデータも含まれ得る。

決済サーバ４０は、電子商品の購入に伴う決済処理を行なうサーバコンピュータである。決済サーバ４０は、端末２０からのネットワーク１０を経由した、電子商品の購入要求等に応じて電子商品の決済処理を実施することができる。

別言すると、端末２０は、ネットワーク１０経由で商品サーバ３０にアクセスして、当該サーバ３０からアプリケーションプログラム（以下、単に「アプリケーション」あるいは「アプリ」と略称することがある。）等の電子商品を受信、インストール等することができる。なお、電子商品は、商品サーバ３０において複数分、格納、管理されていてよい。また、電子商品は有償でも無償でもよい。有償の場合、端末２０は、例えば決済サーバ４０と通信して電子商品の決済処理を実施することができる。

広告制御サーバ５０は、広告制御装置の一例であり、商品サーバ３０によって端末２０に提供される電子商品に関する情報を含む広告情報（例えばバナー広告等）の配信等を管理、制御するサーバコンピュータである。

本実施形態の広告制御サーバ５０は、どの電子商品を通じてどの電子商品の広告情報が閲覧されたのか、あるいは当該広告情報を通じて電子商品が端末２０に導入（例えばインストールや使用、アプリケーションの実行等）されたのかといった、広告情報の利用状況を管理し、その利用状況に応じて、電子商品に対する送集客を調整する、あるいは均一化を図る。

なお、広告情報は、「閲覧」される場合に限らず、「クリック」や「タップ」によって「選択」される場合がある。また、ゲーム等のアプリケーション実行中に広告情報が画面表示されている場合には「クリック」や「タップ」に限らず、キャラクタをドラッグする等して広告情報の表示領域に移動等させたりする操作も広告情報を「選択」する概念に含まれる。

例えば、広告制御サーバ５０は、各電子商品（例えばアプリケーション）に対応した広告情報の閲覧回数及び／又は広告情報を通じた電子商品の導入処理回数を管理する。そして、広告制御サーバ５０は、閲覧回数及び／又は導入の有無や回数（量）等に応じたポイントを算出（例えば加減算）し、当該ポイントに応じて電子商品間の広告の量や内容、種類等を変化させる。

なお、商品サーバ３０から電子商品が端末２０宛てに送信され、広告制御サーバ５０から広告（バナー等）が端末２０宛てに送信される。広告制御サーバ５０から端末２０宛ての広告の送信タイミングは、非限定的な一例として、以下の３つが考えられる。
（１）電子商品の送信と同時。
（２）電子商品が端末２０においてインストールされたことを示す情報を端末２０から受信したとき。
（３）電子商品を端末２０において使用したことを示す情報を端末２０から受信したとき。

ここで、電子商品の送信とインストールは電子商品１つにつき１回である一方、電子商品の使用は何度も行なわれ得るので、その度に広告を選択して端末２０宛てに送信することで、より効果的な広告が可能となる。

また、広告制御サーバ５０としての機能は、複数のサーバコンピュータによって分散的に実現されてもよい。

〔２〕広告制御サーバ５０による広告制御動作概要
広告制御サーバ５０による広告制御動作の概要について図２を用いて説明する。図２には、電子商品の一例である４つのアプリケーションＡ〜Ｄ間で送客／集客が行なわれる様子を例示している。

ここで、端末２０においてアプリＡの実行中にアプリＢのバナー広告（アプリＢバナー）が表示されているとする。端末２０においてアプリＢバナーが例えば端末２０のユーザによってクリック又はタップされると、端末２０にはアプリＢの例えば商品紹介画面及び／又はインストール画面が表示される。

別言すると、端末２０は、アプリＡの実行中にアプリＢバナーが選択されると表示画面がアプリＢの商品紹介画面等に遷移する。これをアプリＡからみると、アプリＡは、１人のユーザをアプリＢに送客したと捉えることができる。一方、アプリＢからみると、１人のユーザをアプリＡから集客したと捉えることができる。

このとき、送客元のアプリＡは、送客数に応じたポイント（例えば１人につき＋１０ｐｔ等）を獲得し、送客された（集客した）側のアプリＢは、集客数に応じたポイント（例えば１人につき−１０ｐｔ）を消費する。なお、本例において、アプリＡは、アプリＢの広告情報が関連付けられた電子商品の一例であり、アプリＢは、当該広告情報に含まれる情報としての電子商品の一例である。他のアプリＢ−Ｃ間、アプリＣ−Ｄ間、アプリＤ−Ａ間についてもそれぞれ同様のルールを適用する。

以上のようなアプリ間の送客数及び集客数に応じたポイント（以下「送集客ポイント」と称する。）を広告制御サーバ５０はデータベースとしてメモリやハードディスク等の記憶装置に記録することで管理し（例えば図３参照）、送集客ポイントが各アプリ間で平等あるいは均一化（平準化）されるように、どのアプリ（電子商品）にどのバナー広告（広告情報）を関連付けるか（別言すると送信、表示させるか）を制御（選択、決定）する。

例えば図３に示す例では、アプリＢ（＋３００ｐｔ）の送集客ポイントが最も高い、つまりはアプリＢが最も多く他のアプリへ送客している（別言すると、他のアプリに貸しが有る）ので、例えば送集客ポイントの低い（−３００ｐｔ）、つまりは他のアプリからの集客数が多く他のアプリに借りが有るアプリＤに、アプリＢのバナー広告を表示させるようにする。

なお、送集客ポイントは、可変パラメータの一例である。送集客ポイントの増減幅（更新度合い）は、広告情報によって誘導されたユーザが誘導先の商品紹介画面等を閲覧した場合と誘導先の商品紹介画面等を通じて電子商品を導入処理（インストールや使用等）した場合とで異ならせることもできる。

例えば、商品紹介画面等を閲覧した場合よりも電子商品を導入処理した場合の方の更新度合いを大きくすることができる。一例を挙げると、アプリＡからアプリＢに誘導されたユーザが、アプリＢの紹介画面を閲覧した場合にアプリＡが＋１０ｐｔを獲得し、アプリＢが−１０ｐｔを消費するのに対して、当該ユーザがアプリＢを端末２０にインストールした場合は、アプリＡが＋１００ｐｔを獲得し、アプリＢは−１００ｐｔを消費することとしてもよい。

その際、アプリＢが有償か無償かで獲得（消費）するポイント数（更新度合い）を更に異ならせてもよい。例えば、無償のアプリよりも有償のアプリの方が、更新度合いを有償額に応じて大きくするようにしてもよい。例えば、価格パラメータを有し（図３では図示しないが、可変パラメータが価格パラメータを含んでいてもよい）、この価格もしくは価格に対応した値（N）に基づいて、更新度合いを変化させるように制御することも可能である。

例示すると、アプリＢがＮ円（Ｎは０以上の整数であり、Ｎ＝０は無償であることを意味する。）の場合、アプリＡは、＋（１００＋Ｎ）ｐｔを獲得し、アプリＢは−（１００＋Ｎ）ｐｔを消費することとしてもよい。

なお、上記の例は、送集客ポイント数が送客側アプリと被送客（集客）側アプリとで連動して、また、同じ増減幅（更新度合い）で更新される例であり、単純なロジックで実現可能である。ただし、これに限られない。

例えば、いずれか一方についての送集客ポイント数を更新するようにしてもよいし、送客側アプリと集客側アプリとの間で相対的に異なる更新度合いで更新するようにしてもよい。いずれにしても、上記の例と同等の制御を実現できる。なお、広告制御サーバ５０の構成例については、図５及び図６により後述する。

〔３〕端末２０の構成例
図４に本実施形態の端末２０の構成例を示す。図４に示す端末２０は、例示的に、コンピューティングデバイス２１０、タッチスクリーン２２０、オーディオ出力ユニット２３０、外部メディアユニット２４０、通信ユニット２５０、操作ボタン２６０、前面カメラ２７０、及び、背面カメラ２９０を備える。

コンピューティングデバイス２１０は、端末２０を統括的に制御する。

タッチスクリーン２２０は、例えば、電子商品の一例である、ゲーム等のアプリケーションを表現あるいは演出するための画像（例えば、静止画、動画、映像等）をグラフィックスエンジン２１３から受け取って表示するディスプレイであり、また、ユーザ（例えばゲームプレイヤ）のタッチ操作による入力を受け付け、Ｉ／Ｏコントローラ２１５に入力信号を送信するタッチパネル等である。

オーディオ入出力ユニット２３０は、例えば、電子商品の一例である、ゲーム等のアプリケーションを表現あるいは演出するためのサウンド（例えば、音楽、音声、効果音等）をサウンドエンジン２１４から受け取って出力するスピーカまたは音声出力端子等であり、また、ユーザ（例えばゲームプレイヤ）の声等の音声入力を受け付け、サウンドエンジン２１４に音声信号を送信するマイク等である。

外部メディアユニット２４０は、外部記憶媒体に対するアクセスを可能にするインターフェースであり、各種のメモリカードや磁気または光等のディスクユニット等が接続される。

通信ユニット２５０は、ネットワーク１０に接続されて、他の端末２０や、各種サーバ３０、４０、及び５０等とのネットワーク通信を可能にする。

操作ボタン２６０は、タッチスクリーン２２０によるユーザ入力に代え、またはその入力を補完するために用いられる。コンピューティングデバイス２１０は、各種のプロセッサ及びメモリ等からなる、例えばチップセットを含むコンピュータ回路要素である。

本実施形態のコンピューティングデバイス２１０は、例示的に、プロセッサコア２１１と、メモリモジュール２１２と、グラフィックスエンジン２１３と、サウンドエンジン２１４と、Ｉ／Ｏコントローラ２１５と、これらを接続するシステムバス２１６とを含む。また、コンピューティングデバイス２１０は、プロセッサコア２１１やグラフィックコア２１３１等のデータ処理機能とは別に、処理に負荷がかかる動画像等を高速に処理するためのプロセッサとしてメディアエンジンを備えてもよい。

プロセッサコア２１１は、コンピューティングデバイスのメインプロセッサとして機能するチップである。ここでは、「プロセッサコア」という用語は、メインプロセッサを意味するプロセッサやＣＰＵ、ＭＰＵ等と同義と扱うことができる。

プロセッサコア２１１は、例えば、メモリモジュール２１２上に展開されたプログラムを実行し、コンピューティングデバイス２１０に各種の機能を実現させる。

別言すると、コンピューティングデバイス２１０は、プロセッサコア２１１がプログラムを実行し、当該プログラムの記述内容に従って他のハードウェアユニット／コンポーネントを制御していくことにより、全体として端末２０においてゲーム等のアプリケーションが実行されることとなる。

アプリケーションは、例えば、オペレーティングシステム（ＯＳ）を実行するプロセッサコア２１１の制御の下で実行されてもよい。プロセッサコア２１１は、シングルコアでもよいしマルチコアでもよい。プロセッサコア２１１は、図示しない複数次のデータキャッシュを含んでよい。

また、プロセッサコア２１１は、図示しない浮動小数点プロセッサ（ＦＰＵ）やベクトル浮動小数点プロセッサ（ＶＦＰＵ）等を接続し、これらと協働して、アプリケーションを実行するように構成されてもよい。

メモリモジュール２１２は、例示的に、電子商品の一例である１又は複数のゲーム等のアプリケーション、当該アプリケーションの実行に用いられる各種のデータ、端末２０を識別する識別情報（端末ＩＤ）、広告制御サーバ５０から発行される識別情報（サーバＩＤ）等を記憶する。

メモリモジュール２１２は、例えば、ＤＲＡＭに代表される揮発性メモリ、マスクＲＯＭに代表される書き換え不能な不揮発性メモリ、及びフラッシュメモリや磁気ディスクに代表される書き換え可能な不揮発性メモリのいずれか又はこれらの適宜の組み合わせで構成してよい。

揮発性メモリは、例示的に、プロセッサコア２１１のメインメモリに供され、例えば、アプリケーション及び当該アプリケーションの実行に用いられるデータの一部又は全部を必要に応じて記憶する。

不揮発性メモリは、例えば、ＢＩＯＳや、ＯＳプログラム、デバイスドライバ、端末２０の制御に必要なシステムデータ、グラフィックデータ、カメラ２７０及び／又は２９０で撮影した画像データ等を記憶する。

不揮発性メモリは、マスクＲＯＭを採用することなく、その全てがフラッシュメモリで構成されてもよい。また、メモリモジュール２１２の全てをフラッシュメモリ等の書き換え可能な不揮発性メモリで構成してもよい。端末２０の外部メディアスロット外部記憶媒体もまた、メモリモジュール２１２の一部として供されてもよい。

グラフィックスエンジン２１３は、プロセッサコア２１１の制御の下、各種のグラフィックス処理を行なう。グラフィックスエンジン２１３は、例示的に、グラフィックコア２１３１及びグラフィックメモリ２１３２を含んでよい。

グラフィックコア２１３１は、２Ｄ及び／又は３Ｄのコンピュータグラフィックス（ＣＧ）を生成、描画する機能を有するグラフィックプロセッサの一例であり、ビデオディスプレイプロセッサ（ＶＤＰ）やグラフィックプロセッシングユニット（ＧＰＵ）と称されることもある。

グラフィックコア２１３１は、グラフィックメモリ２１３２に記憶されるグラフィックデータを読み出して、各種のグラフィック処理（例えば、ジオメトリ処理、レンダリング処理、テクスチャマッピング処理等）を行なって、画像データを生成することができる。

例示的に、グラフィックコア２１３１は、ポリゴンのジオメトリ（座標）を計算するジオメトリプロセッサと、ジオメトリ計算されたポリゴンをラスタライズ／レンダリング（描画）するレンダリングプロセッサとを含んでよい。また、グラフィックコア２１３１は、描画された画像をタッチスクリーン２２０等に出力するため、ビデオエンコーダやＨＤＭＩ（High-Definition Multimedia Interface）等を備えていてもよい。

ジオメトリプロセッサは、例えば、ポリゴンの２次元又は３次元空間での座標について、行列の回転や拡大等を実施して、アフィン変換等を行ない、ポリゴンの座標を求める。また、ジオメトリプロセッサは、ポリゴンの分割やスプライン補完等のテッセレーションを行なう、「ジオメトリシェーダ」（又はバーテックスシェーダ）を備えてもよい。

レンダリングプロセッサは、例えば、座標計算されたポリゴンについて、テクスチャと呼ばれる画像データを貼り付け、各種効果を加えてグラフィックメモリに描画する。各種効果の一例としては、プログラマブル・シェーダ等を用いて、光点・影（シェーディング）計算、明暗の表現、半透明、ぶれ、霧、ぼかし、ＨＤＲ（ハイダイナミックレンジ合成）等の計算が挙げられる。

ポリゴンの種類の一例としては、点ポリゴン（ポイント）、線ポリゴン（ラインリスト）、三角形や四角形といった面ポリゴン、面ポリゴンの集合体等が挙げられる。加えて、レンダリングプロセッサがレイ・トレーシング等を用いて描画を行なう際には、円、楕円、球、メタボール等の領域で定義される物体を描画することも可能である。

なお、以上のグラフィックコア２１３１による画像処理の一部又は全部は、プロセッサコア２１１で処理するようにしてもよい。グラフィックコア２１３１によって生成された画像データは、ビデオエンコーダ等のビデオインターフェース回路によって所定のビデオ信号に変換され、タッチスクリーン２２０に出力される。

サウンドエンジン２１４は、プロセッサコア２１１の制御の下、サウンドメモリ（図示せず）に記憶されるサウンドデータに対して、適宜、各種のサウンド処理（例えば、エフェクト処理、ミキシング処理等）を施す。

サウンドエンジン２１４は、音楽や音声や効果音を出力するためのＰＣＭ（Ｗａｖｅ）音源等を備えたデジタルシグナルプロセッサ（ＤＳＰ）等でもよく、また、物理モデル音源、ＦＭ音源等の計算を行ない、残響や反射等の各種音声効果を計算することもできる。

サウンドエンジン２１４によって処理されたサウンドデータは、図示しないサウンドインターフェース回路によって所定のオーディオ信号に変換され、オーディオ出力ユニット２３０に出力される。なお、サウンドエンジン２１４は、図示しないマイクから入力された音声の認識等をサポートしてもよい。

Ｉ／Ｏコントローラ２１５は、外部の様々なユニットとの入出力を制御するインターフェース回路の一例である。Ｉ／Ｏコントローラ２１５には、タッチセンサ２２２、操作ボタン２６０、外部メディアユニット２４０、及び通信ユニット２５０を接続することができる。Ｉ／Ｏコントローラ２１５は、接続された各種のユニットから与えられる外部信号をコンピューティングデバイス２１０内の内部データに変換し、また、内部データを各種のユニットに適した外部信号に変換する。

タッチスクリーン２２０は、ユーザインターフェースデバイスの一例であり、ディスプレイ（スクリーン）２２１及び当該ディスプレイ２２１のサイズに略一致するように形成された透過性のタッチセンサ２２２を含んでよい。タッチスクリーン２２０は、コンピューティングデバイス２１０の制御の下、アプリケーションの実行に応じた画像を表示して、ユーザによるインタラクティブなタッチ操作（クリックあるいはタップ等）を受け付けることができる。

ディスプレイ２２１は、グラフィックスエンジン２１３からのビデオ信号に基づいて、画像（例えば、静止画、動画、映像等）をディスプレイ２２１上に表示する。ディスプレイ２２１は、２Ｄ表示に対応するものでもよいし立体視等の３Ｄ表示に対応するものでもよい。

タッチセンサ２２２は、ユーザによるタッチ操作に応じた操作信号を出力する。ユーザのタッチ操作は、ユーザの指によりなされてもよいし、スタイラス等でもよい。タッチセンサ２２２は、例えば、静電容量タイプのものを採用することができるが、これに限定されない。

タッチセンサ２２２から出力された操作信号は、コンピューティングデバイス２１０に入力される。コンピューティングデバイス２１０は、タッチセンサ２２２からの操作信号を検出すると、アプリケーションに対する操作として解釈し、これに応じた処理を実行する。

例えば、コンピューティングデバイス２１０は、タッチセンサ２２２からの操作信号に基づいて、ディスプレイ２２１上の位置情報を算出し、画像及び時間情報と相まって、操作アクションを決定するために用いられる。本実施形態の端末２０は、複数の指（又はスタイラス）によるマルチタッチ操作を受け付けることができる。

オーディオ出力ユニット２３０は、オーディオ出力デバイスの一例であり、アプリケーションの実行状況に合わせて、ユーザに音（例えば、音声、音楽、効果音等）を提供する。オーディオ出力ユニット２３０は、サウンドエンジン２１４からのオーディオ信号に基づいて、音を発生させる。

外部メディアユニット２４０は、メディアインターフェースデバイスの一例であり、コンピューティングデバイス２１０が外部記憶媒体にアクセスすることを可能にする。外部記憶媒体は、メモリカードやＵＳＢメモリの他、ハードディスクドライブ（ＨＤＤ）、フラッシュメモリ、ＳＲＡＭ（Static Random Access Memory）、磁気テープ装置、光ディスク装置等であってもよい。外部記憶媒体には、アプリケーションの実行に用いられるパラメータ等の各種データを記憶することができる。外部記憶媒体に、既述の端末ＩＤやサーバＩＤが記憶されてもよい。端末２０は、外部記憶媒体からアプリケーション等を読み取ってメモリモジュール２１２に転送し格納して用いる。

アプリケーション等は、コンピュータ読取可能な記録媒体に記録された形態で提供することができる。記録媒体には、例えば、ハードディスク、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Versatile Disk）、ＢＤ（Blue-ray Disk）、ＲＯＭカートリッジ、バッテリバックアップ付きＲＡＭカートリッジ、フラッシュメモリカートリッジ、不揮発性ＲＡＭカートリッジ等が含まれてよい。また、アプリケーション等の電子商品は、通信ユニット２５０によりネットワーク１０経由で商品サーバ３０から受信することもできる。

なお、「コンピュータ」とは、例えば、ハードウェアとオペレーティングシステム（ＯＳ）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味することがある。また、ＯＳが不要でプログラム単独でハードウェアを動作可能な場合には、そのハードウェアがコンピュータに相当するとみることができる。ハードウェアは、ＣＰＵ等の演算装置と、記録媒体に記録されたプログラムを読み取り可能な読み取り装置とを含むことができる。

アプリケーション等は、上述のようなコンピュータに、端末２０としての機能を実現させるプログラムコードを含んでいる。その機能の一部はプログラムではなくＯＳによって実現されてもよい。

通信ユニット２５０は、ネットワーク１０を通じて端末２０が他の端末２０や各種サーバ３０、４０、５０と通信することを可能にする。

〔４〕広告制御サーバ５０の構成例
次に、広告制御サーバ５０のハードウェア的な構成と機能的な構成とを以下に説明する。なお、ゲームサーバ３０や決済サーバ４０のハードウェア的な構成は、広告制御サーバ５０の構成と同等とすることができる。

（４．１）ハードウェア構成例
図５に、本実施形態の広告制御サーバ５０のハードウェア的な構成例を示す。図３に示す広告制御サーバ５０は、例示的に、制御部５０１、入力装置５０３、外部記憶装置５０５、及び出力装置５０６を備える。また、広告制御サーバ５０は、通信インターフェース（ＩＦ）５０７を備えてもよい。

制御部５０２は、例えば、広告制御サーバ５０全体の動作を制御する。

入力装置５０３は、サーバ管理者等が制御部５０２に操作信号を入力するために用いられる。入力装置５０３の一例としては、キーボード、マウスやトラックボール等のポインティングデバイス等が挙げられる。また、入力装置５０３には、後述するディスプレイ５０６Ａに備えられたタッチパッドやタッチパネルが含まれてもよい。

外部記憶装置５０５は、例示的に、ペリフェラルインタフェース（Ｉ／Ｆ）５２１を介して制御部５０２に着脱可能に接続することができる。当該ペリフェラレルＩ／Ｆ５２１には、１又は複数の周辺機器を追加的に接続してもよい。なお、外部記憶装置５０５は、広告制御サーバ５０内に内蔵される記憶装置であってもよい。

外部記憶装置５０５には、ハードディスクドライブ（ＨＤＤ）、フラッシュメモリ、ＳＲＡＭ（Static Random Access Memory）、磁気テープ装置、光ディスク装置等を用いることができる。外部記憶装置５０５には、広告制御に用いられるプログラム（以下「広告制御プログラム」ともいう。）やサーバ内で生成した及び／又は端末から受信したパラメータ等の各種データのほか、電子商品や広告情報等を記憶することができる。コンピュータの一例である広告制御サーバ５０は、外部記憶装置５０５から広告制御プログラム等を読み取って後述するメインメモリ５１３等の内部メモリに転送し格納して用いる。なお、図５のハードウェア的な構成例は、図３の商品サーバ３０にも適用が可能である。この場合、電子商品は商品サーバ３０に記憶され、商品サーバ３０から電子商品が端末装置に送信される。この場合であっても、広告制御サーバ５０は商品サーバ３０の機能を有していてもよい。

広告制御プログラム等は、コンピュータ読取可能な記録媒体に記録された形態で提供することができる。記録媒体には、例えば、ハードディスク、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Versatile Disk）、ＢＤ（Blue-ray Disk）、ＲＯＭカートリッジ、バッテリバックアップ付きＲＡＭカートリッジ、フラッシュメモリカートリッジ、不揮発性ＲＡＭカートリッジ等が含まれてよい。また、広告制御プログラム等は、通信ＩＦ５０７によりネットワーク１０経由で広告制御サーバ５０に提供してもよい。

なお、「コンピュータ」とは、例えば、ハードウェアとオペレーティングシステム（ＯＳ）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味することがある。また、ＯＳが不要でプログラム単独でハードウェアを動作可能な場合には、そのハードウェアがコンピュータに相当するとみることができる。ハードウェアは、ＣＰＵ等の演算装置と、記録媒体に記録されたプログラムを読み取り可能な読み取り装置とを含むことができる。

広告制御プログラム等は、上述のようなコンピュータに、広告制御サーバ５０としての機能を実現させるプログラムコードを含んでいる。その機能の一部はプログラムではなくＯＳによって実現されてもよい。

出力装置５０６は、例示的に、ディスプレイ５０６Ａやスピーカ５０６Ｂを備え、広告制御サーバ５０のオペレータ等に広告制御プログラム等の実行状態に応じた映像や音声を提供する。ディスプレイ５０６Ａには、液晶ディスプレイや、ＰＤＰ（プラズマ・ディスプレイ・パネル）、ＨＭＤ（ヘッドマウントディスプレイ）等を適用することができる。また、ディスプレイ５０６Ａは、複数のディスプレイを有して成る大画面の統合ディスプレイとしてもよい。

通信ＩＦ５０７は、ネットワーク１０への接続を可能にする装置あるいはインターフェースである。通信ＩＦ５０７を介して、広告制御サーバ５０は、ネットワーク１０に接続された端末２０や他のサーバ３０、４０と適宜に通信することができる。

通信ＩＦ５０７は、送受信機能を有しており、送信機能に着目すれば、電子商品および広告情報を端末２０宛てに送信する送信手段の一例として機能する。送信手段の一例である通信ＩＦ５０７は、いずれかの電子商品と他の電子商品に関連付けられた広告情報とを端末２０宛てに送信することができる。また、通信ＩＦ５０７は、受信機能に着目すれば、端末２０において広告情報が利用されたことを示す利用情報（後述）を端末２０から受信する受信手段の一例として機能する。

なお、広告制御サーバ５０および商品サーバ３０において、グラフィックメモリ５１４、オーディオメモリ５１５、ＧＰＵ５１６、オーディオプロセッサ５１８、及び出力装置５０６（別言すると、グラフィック関連機能及びオーディオ関連機能）の一部又は全部は備えないこととしても構わない。

（４．２）広告制御サーバ５０の機能的構成例
次に、図６に広告制御サーバ５０の機能的な構成例を示す。

図６に例示する広告制御サーバ５０は、ＣＰＵ５１１が広告制御プログラム等をメインメモリ５１３から読み取って実行することによって具現される機能（制御部５０１）の一例として、認証処理部５１１ａ、バナー処理部５１１ｂ、オファー処理部５１１ｃ及び送集客バランス処理部５１１ｄを備える。なお、図６に例示する記憶部５３０は、既述のメインメモリ５１３及び／又は外部記憶装置５０５に該当する。記憶部５３０には、例示的に、アプリケーションデータベース（ＤＢ）５３１、ユーザデータベース（ＤＢ）５３５、及びログデータベース（ＤＢ）５３６が記憶される。

認証処理部５１１ａは、ユーザＤＢ５３５の記憶情報に基づいて端末２０との間の認証処理を実施する。

ユーザＤＢ５３５には、例示的に、端末２０を識別する情報（端末ＩＤ）と、当該端末ＩＤと一意に対応する広告制御サーバ５０の識別情報（サーバＩＤ）とが格納されており、認証処理は、これらの組み合わせを用いて行なわれる。

認証処理に成功した端末２０が広告制御サーバ５０によるサービス（広告制御）を利用することができる。認証処理の詳細については図８により後述する。

バナー処理部５１１ｂは、バナー要求のあった端末２０宛てにバナー広告を送信し、当該バナー広告の選択操作（例えばクリック又はタップ等）が端末２０においてなされたか否かを監視する。

バナー広告の選択操作があったことを示す情報を端末２０から受信した場合、バナー処理部５１１ｂは、送集客バランス処理部５１１ｄと連携して、図２及び図３にて説明したような送集客ポイントを更新する。

当該更新結果に基づいて、バナー処理部５１１ｂは、端末２０宛てに送信するバナー広告を選択、決定する。バナー処理部５１１ｂによるバナー処理の詳細については、図９〜図１１にて後述する。

なお、バナー広告は複数種類用意しておいてもよい。例えば、通常のバナー広告（以下「通常バナー」ともいう。）と、キャンペーンバナー広告（以下、単に「キャンペーンバナー」ともいう。）と、を用意しておくことができる。

「通常バナー」は、例えば他の電子商品へ誘導して（遷移させて）他の電子商品の閲覧等を促すバナーである。図１７及び図１８に通常バナーの一例を示す。

図１７は文字情報によるバナーの一例を示し、図１８はデザイニングされたバナー（例えばゲームタイトルデザイン等を含む画像情報によるバナー）の一例を示している。

「キャンペーンバナー」は、例えば誘導先（遷移先）の電子商品（例えばアプリＢ）を導入処理（例えばインストール若しくは実行等）すると、誘導先の電子商品（アプリＢ）で利用可能な価値情報（リワード：例えば、ゲームで使用するパラメータやゲーム内通貨等のゲームポイントやアイテム、追加プログラムやデータ等）が貰えるといった、ユーザに他の電子商品の導入を促すようなバナーである。図１９にキャンペーンバナーの一例を示す。

次に、オファー処理部５１１ｃは、オファー要求のあった端末２０宛てにオファー広告を送信し、当該オファー広告における選択操作（例えばクリック又はタップ等）を通じて電子商品の導入処理が端末２０においてなされたか否かを監視する。

ここで、「オファー広告」とは、例えば、端末２０で実行中のゲームアプリＡとは異なる他のゲームアプリＢをインストールするとアプリＡで利用可能な価値情報（例えば、ゲームで使用するパラメータやゲーム内通貨等のゲームポイントやアイテム、追加プログラムやデータ等）が端末２０に付与されることを端末２０に通知する広告（以下「オファーページ」ともいう。）である。

別言すると、「オファー広告」は、例示的に、遷移先アプリＢのインストールを成果として遷移元アプリＡの実行継続のインセンティブを端末２０のユーザに与えるような広告である。オファーページの一例を図２０に示す。図２０では、３つのアプリケーションがインストール候補としてリストアップされている様子を例示している。

オファー処理部５１１ｃは、端末２０において上記導入処理がなされたか（オファーが成立したか）否かを監視し、送集客バランス処理部５１１ｄと連携して、図２及び図３にて説明したような送集客ポイントを更新する。

当該更新結果に基づいて、オファー処理部５１１ｂは、オファーページに優先的に表示するアプリケーション等の電子商品のリスト順序等を決定する。オファー処理部５１１ｂによるオファー処理の詳細については、図１２〜図１４にて後述する。

次に、送集客バランス処理部５１１ｄは、バナー処理部５１１ｂ及び／又はオファー処理部５１１ｃと連携して、図２及び図３にて説明したような送集客ポイントに基づいて電子商品間の送集客をバランスする処理を実施する。

別言すると、送集客バランス処理部５１１ｄは、どの電子商品にどの広告情報を関連付けるかを送集客ポイントに基づいて制御する。送集客バランス処理部５１１ｄによる送集客バランス処理の詳細については、図１５及び図１６にて後述する。

アプリケーションＤＢ５３１は、電子商品の一例である複数のアプリケーションに関連する情報を記憶する。アプリケーションの一例は、ゲームアプリケーションであるが、これに限られない。

アプリケーションに関連する情報の一例としては、アプリケーションの識別情報（以下「アプリＩＤ」ともいう。）や、アプリケーション（アプリＩＤ）毎の送集客ポイントＤＢ５３１ａ、アプリケーション（アプリＩＤ）毎の会社情報ＤＢ５３１ｂ、アプリケーション（アプリＩＤ）毎に関連付ける広告情報（バナー広告及び／又はオファー広告）等のＤＢ（広告情報ＤＢ）５３１ｃ等が挙げられる。

送集客ポイントＤＢ５３１ａは、アプリケーション毎の可変パラメータ（送集客ポイント）を記憶するパラメータ記憶手段の一例である。

広告情報ＤＢ５３１ｃは、いずれかの電子商品に関する情報を含む広告情報を記憶する広告情報記憶手段の一例である。広告情報ＤＢ５３１ｃには、例示的に、バナーデータリスト５３３及び／又はオファーデータリスト５３４が格納される。

ユーザＤＢ５３５は、端末２０及び／又は当該端末２０のユーザに関する情報を格納しており、例えば既述のように少なくとも前記認証処理に用いられる端末ＩＤとサーバＩＤとを保存している。

ログＤＢ５３６は、広告情報の送信履歴や当該広告情報の利用履歴等のログ情報を格納する。ここで、「広告情報の利用」とは、例示的に、バナー広告及び／又はオファー広告の端末２０での選択操作（例えばクリック、タップ、広告表示領域へのキャラクタの移動等）、及び／又は、当該選択操作を通じた導入処理（例えばアプリのインストールや使用等）を含む概念である。

したがって、広告情報の「利用情報」には、端末２０で広告情報を選択（バナーをクリック等）したことを示す閲覧情報および／または広告情報を通じて商品を導入処理（インストール、使用等）したことを示す導入情報が含まれる。よって、ログＤＢ５３６は、利用情報を広告選択情報として蓄積、格納する広告選択情報格納手段の一例として機能する。

アプリケーションＤＢ５３１（広告情報ＤＢ５３１ｃ）と、ユーザＤＢ５３５及びログＤＢ５３６とは互いに関連付けられており、これにより、端末２０においてどのアプリケーション（電子商品）に関連付けられたどの広告情報が利用されたかを管理、把握することができる。

〔５〕システム動作説明
以下、上述のごとく構成された広告提供システム１の動作について説明する。ただし、以下の説明では、電子商品の一例がアプリケーションである場合について説明する。

（５．１）システム全体フロー（図７）
図７に例示するように、端末２０は、インストール済みの或るアプリケーションが起動されると、広告制御サーバ５０との間でユーザ認証処理を実施する（処理Ｐ１０及びＰ２０）。

通信障害やサーバ障害等によりユーザ認証に失敗した場合（処理Ｐ２０でＮＯの場合）、端末２０では起動したアプリによる通常の処理（例えばゲーム等）が実施される（処理Ｐ３０）。別言すると、端末２０のユーザは、ユーザ認証に失敗しても、広告制御サーバ５０によるサービスを利用できないだけで、起動したアプリによる通常の処理は利用可能である。

これに対し、ユーザ認証が成功した場合、広告制御サーバ５０は、呼び出すメソッド（例えば、バナーを取得するメソッドとオファーページを表示するメソッド）を判断し（処理Ｐ４０）、端末２０に対してバナー処理及びオファー処理のいずれかを実施する（処理Ｐ５０又はＰ６０）。

バナー処理（図９〜図１１）又はオファー処理（図１２〜図１４）が完了すると、端末２０では起動されたアプリケーション（仮にアプリＡとする）による通常の処理が実施される（処理Ｐ７０又はＰ８０）。

例えば、バナー処理後では端末２０においてアプリＡの実行中にバナー広告が表示され、オファー処理後では端末２０においてアプリＡの実行中にオファー広告が表示される。

（５．２）ユーザ認証処理（図８）
次に、図８を参照して、上述した広告制御サーバ５０（認証処理部５１１ａ）によるユーザ認証処理の詳細について説明する。

端末２０において或るアプリＡが起動されると、当該アプリＡは、端末２０の識別情報（端末ＩＤ）を取得し（処理Ｐ１０１）、偽装ユーザでないかを判断する（処理Ｐ１０２）。例えばアプリＡについて端末２０で保存された端末ＩＤとアプリＡを起動した端末２０の端末ＩＤとが異なっていた場合に、端末ＩＤが偽装され、端末２０のユーザが偽装ユーザであると判断する。

偽装ユーザと判断されれば（処理Ｐ１０２でＮＯの場合）、端末２０（アプリＡ）は、通常の処理（ゲーム等）を実行する（処理Ｐ１０３）。これに対し、偽装ユーザでなければ（処理Ｐ１０２でＹＥＳの場合）、端末２０（アプリＡ）は、例えば、端末ＩＤとサーバＩＤとを広告制御サーバ５０宛てに送信する（処理Ｐ１０４）。

広告制御サーバ５０は、端末２０（アプリＡ）から受信したサーバＩＤをユーザＤＢ５３５において検索し、該当サーバＩＤが存在すれば、同ユーザＤＢ５３５を参照して、端末ＩＤが当該ユーザＤＢ５３５に存在するか検索する（処理Ｐ１０５及びＰ１０６）。

端末２０から受信した端末ＩＤがユーザＤＢ５３５に存在していれば（別言すると、登録済みであれば）（処理Ｐ１０６でＹＥＳの場合）、広告制御サーバ５０は、当該端末ＩＤとサーバＩＤとの組み合わせが正しいか否かを判断する（処理Ｐ１０７及びＰ１０８）。

当該判断の結果、端末ＩＤとサーバＩＤとの組み合わせが正しければ（処理Ｐ１０８でＹＥＳの場合）、広告制御サーバ５０は、ユーザ認証に成功したことを示す情報を端末２０へ送信する（処理Ｐ１１１）。これにより、端末２０は、広告制御サーバ５０によるサービスを受けることが可能になる。

一方、端末ＩＤとサーバＩＤとの組み合わせが正しくなければ（処理Ｐ１０８でＮＯの場合）、ユーザ認証に失敗したことを示す情報を端末２０へ送信する。この場合、端末２０では、広告制御サーバ５０によるサービスは受けられないが、アプリＡによる通常の処理が実行される。

なお、端末ＩＤがユーザＤＢ５３５に存在しなかった場合（処理Ｐ１０６でＮＯの場合）、広告制御サーバ５０は、当該端末ＩＤに一意に対応するサーバＩＤを端末２０（アプリＡ）に対して発行する（処理Ｐ１０９）。これにより、端末２０のユーザ認証が成功する（処理Ｐ１１１）。つまり、端末２０のユーザは、新規ユーザとして広告制御サーバ５０によるサービスを受けることができるようになる。

（５．３）バナー処理（図９〜図１１）
次に、図９〜図１１を参照して、広告制御サーバ５０（バナー処理部５１１ｂ）によるバナー処理について説明する。

図９に例示するように、端末２０において或るアプリＡが起動され、バナーメソッドが開始されると、端末２０（アプリＡ）は、バナー要求を広告制御サーバ５０宛てに送信する（処理Ｐ５０１）。

広告制御サーバ５０は、バナー要求を受信すると、バナー要求元のアプリＡが属するアカウントの送集客ポイント（合計ポイント）が、予め設定された上限閾値に達しているか否かを判断する（処理Ｐ５０２及びＰ５０３）。なお、「アカウント」は、例えばアプリを配信する会社毎やアプリの開発チーム毎等に発行される（割り当てられる）情報である。上限閾値は、各会社等のアプリ全体についての送集客ポイントに関する閾値であり、例えばアプリケーションＤＢ５３１の送集客ポイントＤＢ５３１ａに格納されている。

その結果、送集客ポイントが上限閾値に達していれば（処理Ｐ５０３でＹＥＳの場合）、広告制御サーバ５０は、アプリＡが「過送客」の状態にあると判断して、バナー処理を終了する。したがって、端末２０で起動されたアプリＡに対してバナー広告は表示されない（処理Ｐ５０４）。

一方、送集客ポイントが上限閾値に達していなければ（処理Ｐ５０３でＮＯの場合）、広告制御サーバ５０は、送集客バランス処理部５１１ｄによる送集客バランス処理を実施し（処理Ｐ５０５）、バナー広告を端末２０宛てに送信し、バナー広告送信済みであることを例えばログＤＢ５３６に一時（キャッシュ）保存する（処理Ｐ５０６）。なお、送集客バランス処理の詳細については、図１５及び図１６にて後述する。

端末２０では、上記バナー広告を広告制御サーバ５０から受信すると、当該バナー広告を表示し（処理Ｐ５０７）、当該バナー広告に対するユーザによる選択操作（例えばクリック又はタップ）の有無を監視する（処理Ｐ５０８）。

バナー広告に対する選択操作が無ければ（処理Ｐ５０８でＮＯの場合）、端末２０のアプリＡは、広告制御サーバ５０が指定する時間だけバナー広告を表示し（処理Ｐ５０９）、処理Ｐ５０１へ戻る。バナー広告を表示する指定時間の情報は、バナー広告と共にあるいはバナー広告とは別に広告制御サーバ５０から端末２０に送信される。代替的に、当該指定時間の情報は、端末２０において予め保有しておいてもよい。

バナー広告の利用があった場合（処理Ｐ５０８でＹＥＳの場合）、バナー広告が利用されたことを示す利用情報（予め定義されている広告制御サーバ５０が利用情報と識別できるコマンド若しくはデータ列等）とバナー広告のＵＲＬ（Uniform Resource Locator）要求とを広告制御サーバ５０宛てに送信する（処理Ｐ５１０）。

広告制御サーバ５０は、端末２０から上記利用情報を受信すると、当該利用情報を例えばログＤＢ５３６に保存し（処理Ｐ５１１）、ＵＲＬ要求のあったバナー広告の種別（以下「バナー種別」ともいう。）が「通常バナー」及び「キャンペーンバナー」のいずれであるかを判断する（処理Ｐ５１２及びＰ５１３）。

その結果、バナー種別が「キャンペーンバナー」であれば、広告制御サーバ５０は、キャンペーン対象のアプリケーション（仮にアプリＢとする）についての価値情報の管理場所が広告制御サーバ５０及び当該アプリＢを管理するゲームサーバ３０のいずれであるかを判定する（処理Ｐ５１４及びＰ５１５）。なお、価値情報の一例は、キャンペーン対象（遷移先）のアプリＢで利用可能なゲームポイント（ゲームで使用するパラメータ、ゲーム内通貨等）やアイテム、グッズ、追加プログラムやデータ等の情報である。

上記判定の結果、キャンペーン対象のアプリＢについての価値情報の管理場所がゲームサーバ３０であれば、広告制御サーバ５０は、キャンペーン対象のアプリＢに価値情報を付与する情報を当該ゲームサーバ３０宛てに送信する（処理Ｐ５１７）。これにより、ゲームサーバ３０は、キャンペーン対象のアプリＢについて価値情報を取得する（処理Ｐ５１８）。

一方、キャンペーン対象のアプリＢについての価値情報の管理場所が広告制御サーバ５０であれば、当該アプリＢに対して価値情報を追加する（処理Ｐ５１６）。なお、バナー種別が通常バナーであれば、広告制御サーバ５０は、下記の同一会社間送客判定を実施する。

図１０に例示するように、広告制御サーバ５０は、同一会社間の送客か否かを判定する（処理Ｐ５１９及びＰ５２０）。当該判定は、例えばアプリケーションＤＢ５３１の会社情報ＤＢ５３１ｂにて保存、管理されているアプリケーション毎の会社情報を基にして実施することができる。

同一会社間の送客であれば（処理Ｐ５２０でＹＥＳの場合）、広告制御サーバ５０は、送客元のアプリＡについての送集客ポイントを増加（例えば＋１０ｐｔ）し、送客先（キャンペーン対象）のアプリＢについての送集客ポイントを減少（例えば−１０ｐｔ）する（処理Ｐ５２１）。

これに対し、同一会社間の送客でなければ（処理Ｐ５２０でＮＯの場合）、広告制御サーバ５０は、送客元のアプリＡについての送集客ポイントを増加（例えば＋９ｐｔ）し、送客先（キャンペーン対象）のアプリＢについての送集客ポイントを減少（例えば−１０ｐｔ）する（処理Ｐ５２３）。

ここで、＋１ｐｔは広告制御サーバ５０において保険ポイントとして例えば送集客ポイントＤＢ５３１ａ（図６参照）に蓄積（プール）しておくことができる（処理Ｐ５２４）。保険ポイントは、「過送客」や「過集客」の場合の調整ポイントとして使用することができる。

上記送集客ポイント増減処理の後、広告制御サーバ５０は、端末２０から要求されたＵＲＬを当該端末２０宛てに送信する（処理Ｐ５２２）。端末２０は、受信したＵＲＬにアクセスする。端末２０は、当該ＵＲＬにアクセスすると、例えば広告制御サーバ５０からＵＲＬに対応するページのデータが端末２０に送信される。当該ページは、例えばバナー広告されたアプリＢの紹介やインストールを実施可能なページ（インストールページ）である。

図１１に例示するように、端末２０は、当該インストールページを通じてバナー広告されたアプリＢをインストールし、当該アプリＢが起動されると（処理Ｐ５２７）、ユーザ認証処理を実施する（処理Ｐ５２８）。ユーザ認証処理は、図８にて説明したとおりである。

ユーザ認証処理が終了すると、端末２０は、起動したアプリＢ（例えばゲーム）内で利用可能な価値情報（ゲームで使用するパラメータやゲーム内通貨等のゲームポイントやアイテム、追加データやプログラム等）の管理場所が広告制御サーバ５０及び当該アプリケーションを管理しているゲームサーバ３０のいずれであるかを判定する（処理Ｐ５２９及びＰ５３０）。

ゲームポイント等の管理場所がゲームサーバ３０であれば、端末２０で起動されたアプリＢは、新規ポイント有無をゲームサーバ３０に問い合わせる（処理Ｐ５３１）。

ゲームサーバ３０は、端末２０で起動されたアプリＢに対して付与すべき新規ゲームポイント等が無ければ（処理Ｐ５３２で「なし」の場合）、その旨を端末２０宛てに送信する。これにより、端末２０はバナー処理を終了する。

一方、端末２０で起動されたアプリＢに対して付与すべき新規ゲームポイント等が有れば（処理Ｐ５３２で「あり」の場合）、ゲームサーバ３０は、当該新規ポイント等を当該アプリＢに対して付与する（処理Ｐ５３３）。これにより、端末２０で起動されたアプリＢはゲームポイント等を獲得し（処理Ｐ５４１）、バナー処理を終了する（処理Ｐ５４２）。

なお、ゲームポイント等の管理場所が広告制御サーバ５０であれば、端末２０で起動されたアプリＢは、新規ポイント等の有無を広告制御サーバ５０に問い合わせる（処理Ｐ５３４及びＰ５３５）。

その結果、端末２０で起動されたアプリＢに対して付与すべき新規ゲームポイント等が有れば（処理Ｐ５３２で「あり」の場合）、広告制御サーバ５０は、当該新規ポイント等を当該アプリＢに対して付与する（処理Ｐ５３６）。これにより、端末２０で起動されたアプリＢはゲームポイント等を獲得し（処理Ｐ５３７）、バナー処理を終了する（処理Ｐ５３８）。

端末２０で起動されたアプリＢに対して付与すべき新規ゲームポイント等が無ければ（処理Ｐ５３５で「なし」の場合）、その旨を端末２０宛てに送信する。これにより、端末２０の起動アプリＢはバナー処理を終了する（処理Ｐ５３９）。

以上のようにして、広告制御サーバ５０は、「キャンペーンバナー」が端末２０において選択されると、送客元の電子商品の送集客ポイントを増加し、かつ、送客先の電子商品の送集客ポイントを減少する。また、キャンペーン対象の電子商品が「キャンペーンバナー」の選択を通じて端末２０に導入されると、当該キャンペーン対象の電子商品で利用可能な価値情報が端末２０に付与される。

（５．４）オファー処理（図１２〜図１４）
次に、図１２〜図１４を参照して、広告制御サーバ５０（オファー処理部５１１ｃ）によるオファー処理について説明する。

図１２に例示するように、端末２０において或るアプリケーション（仮にアプリＡとする。）が起動され、オファーメソッドが開始されると、端末２０（アプリＡ）は、オファー要求を広告制御サーバ５０宛てに送信する（処理Ｐ６０１）。

広告制御サーバ５０は、オファー要求を受信すると、オファー要求元のアプリＡが属するアカウントの送集客ポイントが、予め設定された上限閾値に達しているか否かを判断する（処理Ｐ６０２及びＰ６０３）。なお、上限閾値は、「過送客」を防ぐために設定される。

その結果、送集客ポイントが上限閾値に達していれば（処理Ｐ６０３でＹＥＳの場合）、広告制御サーバ５０は、オファー処理を終了する。したがって、端末２０で起動されたアプリＡに対してオファーページ（例えば図２０参照）は表示されない（処理Ｐ６０４）。

一方、送集客ポイントが上限閾値に達していなければ（処理Ｐ６０３でＮＯの場合）、広告制御サーバ５０は、送集客バランス処理を実施し（処理Ｐ６０５）、オファーページのＵＲＬを端末２０宛てに送信する（処理Ｐ６０６）。端末２０は、当該ＵＲＬにアクセスすると、例えば広告制御サーバ５０からＵＲＬに対応するページ（オファーページ）のデータが端末２０に送信される。

これにより、端末２０のアプリＡは、受信したオファーページを表示し、当該オファーページに対するインストール等の選択操作（例えばクリック又はタップ）の有無を監視する（処理Ｐ６０７及びＰ６０８）。

選択操作が無ければ（処理Ｐ６０８でＮＯの場合）、端末２０のアプリＡは、オファー処理を終了する（処理Ｐ６０９）。

これに対し、選択操作があった場合（処理Ｐ６０８でＹＥＳの場合）、端末２０は、オファーページにおいて選択操作があったことを示す選択情報を広告制御サーバ５０宛てに送信する（処理Ｐ６１０）。

広告制御サーバ５０は、受信した選択情報を例えばログＤＢ５３６に保存し（処理Ｐ６１１）、インストールページ（オファーページ）のＵＲＬを端末２０宛てに送信する（処理Ｐ６１２）。

端末２０のアプリＡは、広告制御サーバ５０から受信したＵＲＬにアクセスする（処理Ｐ６１３）。端末２０は、当該ＵＲＬにアクセスすると、例えば広告制御サーバ５０からＵＲＬに対応するページ（オファーページ）のデータが端末２０に送信される。これにより、端末２０は、オファーページを表示する（処理Ｐ６１４）。オファーページは、例えば端末２０にインストール可能なアプリケーションの候補リストを表示する。

端末２０は、当該オファーページを通じてオファーされたいずれかのアプリケーション（仮にアプリＢとする。）をインストールし、当該アプリＢが起動されると（処理Ｐ６１５）、ユーザ認証処理を実施する（処理Ｐ６１６）。ユーザ認証処理は、図８にて説明したとおりである。

ユーザ認証処理が終了すると、端末２０は、アプリＢの起動情報を広告制御サーバ５０宛てに送信する（処理Ｐ６１７）。広告制御サーバ５０は、起動情報を端末２０のアプリＢから受信すると、オファーが成立したことを示す情報を例えばログＤＢ５３６に保存する（処理Ｐ６１８）。

その後、図１３に例示するように、広告制御サーバ５０は、同一会社間の送客か否かを判定する（処理Ｐ６１９及びＰ６２０）。

同一会社間の送客でなければ（処理Ｐ６２０でＮＯの場合）、広告制御サーバ５０は、有償（例えばＮ円；Ｎは０以上の整数）のアプリＢのオファー成立であれば、送客元のアプリＡについての送集客ポイントを増加する。例えば、＋（１００＋Ｎ）×０．９ｐｔ（ただし、小数点切り上げ）で計算される送集客ポイントを加算する。これに対し、送客先のアプリＢについての送集客ポイントについては減少させる。例えば、−（１００＋Ｎ）ｐｔだけ減算する（処理Ｐ６２１）。なお、（１００＋Ｎ）×０．１ｐｔ（ただし、小数点切り捨て）は、保険ポイントとして例えば送集客ポイントＤＢ５３１ａ（図６参照）にプールしておくことができる（処理Ｐ６２２）。

一方、同一会社間の送客であれば（処理Ｐ６２０でＹＥＳの場合）、広告制御サーバ５０は、送客元のアプリＡについてのポイントを増加〔例えば、＋（１００＋Ｎ）ｐｔ〕し、送客先のアプリＢについてのポイントを減少〔例えば、−（１００＋Ｎ）ｐｔ〕する（処理Ｐ６２３）。

その後、広告制御サーバ５０は、端末２０の送客元のアプリＡ（例えばゲーム）で利用可能なゲームポイント等の価値情報の管理場所がゲームサーバ３０及び広告制御サーバ５０のいずれであるかを判定する（処理Ｐ６２４及びＰ６２５）。

その結果、価値情報の管理場所がゲームサーバ３０であれば、端末２０の送客元のアプリＡに対して新規ポイント付与情報を当該ゲームサーバ３０に送信する（処理Ｐ６２６）。

これにより、ゲームサーバ３０は、送客元のアプリＡに対してゲームポイント等の追加処理を実施する（処理Ｐ６２８）。一方、価値情報の管理場所が広告制御サーバ５０であれば、送客元のＡに新規ポイント等を付与する（処理Ｐ６２７）。

その後、端末２０において送客元のアプリＡが起動あるいはレジュームされると、端末２０は、ユーザ認証処理を実施する（処理Ｐ６３０）。ユーザ認証処理の詳細については、図８にて説明したとおりである。

ユーザ認証処理が終了すると、端末２０は、送客元のアプリＡ（例えばゲーム）で利用可能なゲームポイント等の価値情報の管理場所がゲームサーバ３０及び広告制御サーバ５０のいずれであるかを判定する（処理Ｐ６３１及びＰ６３２）。

判定の結果、価値情報の管理場所がゲームサーバ３０であれば、端末２０の送客元アプリＡは、当該ゲームサーバ３０に未付与ゲームポイント等の有無を問い合わせる。

問い合わせを受けたゲームサーバ３０は、未付与ゲームポイントの有無を判定し（処理Ｐ６３３及びＰ６３４）、無ければ、その旨を端末２０に送信する。これにより、端末２０の送客元のアプリＡは、オファー処理を終了する（処理Ｐ６３５）。

一方、ゲームサーバ３０において送客元のアプリＡに対する未付与ゲームポイント等が有れば、新規ゲームポイント等を端末２０の送客元のアプリＡに対して付与する（処理Ｐ６３６）。これにより、端末２０の送客元のアプリＡは、新規ゲームポイント等を獲得し（処理Ｐ６３７）、オファー処理を終了する（処理Ｐ６３８）。

これに対し、ゲームポイント等の価値情報の管理場所が広告制御サーバ５０であれば、端末２０の送客元のアプリＡは、広告制御サーバ５０に対して未付与ゲームポイント等の有無を問い合わせる。

問い合わせを受けた広告制御サーバ５０は、未付与ゲームポイント等の有無を判定し（処理Ｐ６３９及びＰ６４０）、無ければ、その旨を端末２０に送信する。これにより、端末２０の送客元のアプリＡは、オファー処理を終了する（処理Ｐ６４２）。

一方、広告制御サーバ５０において送客元のアプリＡに対する未付与ゲームポイント等が有れば、新規ゲームポイント等を端末２０の送客元のアプリＡに対して付与する（処理Ｐ６４１）。これにより、端末２０の送客元のアプリＡは、新規ゲームポイントを獲得し（処理Ｐ６４３）、オファー処理を終了する（処理Ｐ６４４）。

以上のようにして、広告制御サーバ５０は、端末２０との間でオファーが成立すると、送客元の電子商品の送集客ポイントを増加し、かつ、送客先の電子商品の送集客ポイントを減少する。また、送客先の電子商品の導入処理を成果として、広告制御サーバ５０は、送客元の電子商品で利用可能な価値情報を端末２０に付与する。

（５．５）送集客バランス処理（図１５及び図１６）
次に、図１５及び図１６を参照して、広告制御サーバ５０（送集客バランス処理部５１１ｄ）による送集客バランス処理（バナーケース及びオファーケース）について説明する。

（５．５．１）バナーケース（図９及び図１５）
図９にて説明した送集客バランス処理Ｐ５０５では、図１５に例示する処理が実施される。すなわち、広告制御サーバ５０（送集客バランス処理部５１１ｄ）は、広告情報ＤＢ５３１ｃのバナーデータリスト５３３（図６参照）を参照し（処理Ｐ７０１）、該当サーバＩＤのインストール済みアプリケーションを当該リストから除外する（処理Ｐ７０２）。

次いで、広告制御サーバ５０は、バナーデータリスト５３３をポイント順に整列し（処理Ｐ７０３）、ポイントの最も高いアプリケーションを選択する（処理Ｐ７０４）。そして、広告制御サーバ５０は、選択したアプリケーションの属するアカウントの送集客ポイントが予め設定された下限閾値に達しているか否かを判断する（処理Ｐ７０５及びＰ７０６）。なお、「下限閾値」は、「過集客」を抑えるために設定される。

当該判断の結果、合計ポイントが予め設定された下限閾値に達していれば（処理Ｐ７０６でＹＥＳの場合）、広告制御サーバ５０は、選択したアプリケーションをバナーデータリスト５３３から除外し（処理Ｐ７０７）、改めてポイントの最も高い他のアプリケーションをバナーデータリスト５３３において選択する（処理Ｐ７０４）。

一方、送集客ポイントが予め設定された下限閾値に達していなければ（処理Ｐ７０６でＮＯの場合）、広告制御サーバ５０は、アプリケーション（仮にアプリＡとする。）へのバナー送信履歴をキャッシュで確認する（処理Ｐ７０８）。当該確認の結果、アプリＡにて直近５回以内に別のアプリＢへ誘導するバナー広告が表示されていたかを判断する（処理Ｐ７０９及びＰ７１０）。

当該判断の結果、アプリＡにて直近５回以内にアプリＢへ誘導するバナー広告が表示されていれば（処理Ｐ７１０でＹＥＳの場合）、広告制御サーバ５０は、選択したアプリＡをバナーデータリストから除外し、改めてポイントの最も高い他のアプリを選択する（処理Ｐ７０４）。

一方、アプリＡにて直近５回以内にアプリＢへ誘導するバナー広告が表示されていなければ、アプリＡにて表示するバナー広告をアプリＢへ誘導するバナーに決定する（処理Ｐ７１２）。

（５．５．２）オファーケース（図１６）
次に、図１２にて説明した送集客バランス処理Ｐ６０５では、図１６に例示する処理が実施される。すなわち、図１６に例示するように、広告制御サーバ５０（送集客バランス処理部５１１ｄ）は、広告情報ＤＢ５３１ｃのオファーデータリスト５３４（図６参照）を参照し（処理Ｐ８０１）、該当サーバＩＤのオファー成立済みアプリケーションをオファーデータリストから除外する（処理Ｐ８０２）。

次いで、広告制御サーバ５０は、オファーデータリストをポイント順に整列し（処理Ｐ８０３）、広告表示対象のアプリの属するアカウントの送集客ポイントが予め設定された下限閾値に達しているアプリが存在するか否かを判断する（処理Ｐ８０４及びＰ８０５）。

当該判断の結果、下限閾値に達しているアプリケーションが存在すれば（処理Ｐ８０５でＹＥＳの場合）、広告制御サーバ５０は、該当アプリケーションをオファーデータリストから除外し（処理Ｐ８０６）、オファー配列順序を決定する（処理Ｐ８０７）。

なお、下限閾値に達しているアプリケーションが存在しなければ（処理Ｐ８０５でＮＯの場合）、サーバ５０は、当該オファーデータリストのオファー配列順序を変更しない（処理Ｐ８０７）。

広告制御サーバ５０（送集客バランス処理部５１１ｄ）は、以上のようにして送集客ポイントに基づいて電子商品と当該電子商品に関連付ける広告情報を制御する。例えば、送客成績が相対的に他の電子商品よりも高い電子商品があれば、当該送客成績の高い電子商品に関する情報を含む広告情報を他の電子商品に関連付けて端末２０宛てに送信する広告情報として選択する。

図３の例でいえば、アプリＡは送集客ポイントが他のアプリよりも高く送客成績が高いので、他のアプリに関連付けて送信する広告情報としてアプリＡの広告情報を選択して送信する。

端末２０のユーザが当該広告情報を見て、当該広告情報を選択したり当該選択を通じてアプリＡを導入したりすると、他のアプリの送集客ポイントが上昇（アプリＡに送客したことによる）する。

これにより、もともと送客成績が他よりも高いアプリＡの選択数や導入数が増加して集客数が増すこととなり、結果として送客成績の高いアプリＡから他のアプリへの送客数の更なる増加に跳ね返ってくることになる。

このように、送集客ポイントが各アプリ間で平等あるいは均一化（平準化）されるように、送信する広告情報を選択及び／又は決定する等の制御を行なうことで、効果的な広告を行なうことができるようになる。なお、送集客ポイントに基づいて効果的な広告を行う方法としては、上記のような送集客ポイントを均一化する方向に制御するほか、既に送客成績が高い（送集客ポイントが高い）アプリを含む各アプリに対して、集客させたいアプリ（送集客ポイントが低い）の広告情報を選択して送信する（表示させる）方法も考えられる。この場合は、例えば短期的に販売数を伸ばしたい若しくはユーザ数を増やしたいアプリがある等の場合に有効であるため、送集客ポイントに基づいた広告情報の制御は、その趣旨を逸脱しない範囲で種々変形して実施することができることは言うまでもない。

〔６〕結び
以上のように、本実施形態によれば、各アプリケーションに対応した広告の利用回数（量）をカウントし、どのアプリケーションに対してどのアプリケーションからの広告が利用されたのか、利用回数（量）に応じた送集客ポイントを算出（例えば加減算）するので、送集客ポイントに応じてアプリケーション間の広告の量や内容を変化させることができる。

したがって、どの電子商品を通じてどの電子商品の広告が閲覧あるいは利用されたのか、広告の利用状況を把握し、利用状況に応じて商品に対する送集客を効果的に調整または均一にすることが可能になる。よって、電子商品間でのユーザの誘導が把握でき、効率よくユーザを他の商品に案内することができる。

なお、上述した実施形態において送集客ポイントの大小や送集客ポイントについての上限／下限閾値等は、送客や集客の量や差を示す情報（可変パラメータ）の一例に過ぎず、送集客ポイントの「加減算」は、上述した実施形態で示した態様に限られない。例えば送集客ポイントを加算するのか減算するのかは、一方が加算で他方が減算となっていればどちらでも良い。

１ 広告提供システム
１０ 通信ネットワーク
２０ 端末装置
３０ 商品サーバ
４０ 決済サーバ
５０ 広告制御サーバ
２１０ コンピューティングデバイス
２１１ プロセッサコア
２１２ メモリモジュール
２１３ グラフィックスエンジン
２１３１ グラフィックコア
２１３２ グラフィックメモリ
２１４ サウンドエンジン
２１５ Ｉ／Ｏコントローラ
２１６ システムバス
２２０ タッチスクリーン
２２１ ディスプレイ
２２２ タッチセンサ
２３０ オーディオ出力ユニット
２４０ 外部メディアユニット
２５０ 通信ユニット
２６０ 操作ボタン
２７０ 前面カメラ
２９０ 背面カメラ
５０１ 制御部
５０３ 入力装置
５０５ 外部記憶装置
５０６ 出力装置
５０６Ａ ディスプレイ
５０６Ｂ スピーカ
５０７ 通信インターフェース（ＩＦ）
５１１ ＣＰＵ
５１１ａ 認証処理部
５１１ｂ オファー処理部
５１１ｂ バナー処理部
５１１ｃ オファー処理部
５１１ｄ 送集客バランス処理部
５１２ ＲＯＭ
５１３ メインメモリ
５１４ グラフィックメモリ
５１５ オーディオメモリ
５１６ ＧＰＵ
５１８ オーディオプロセッサ
５２１ ペリフェラレルインターフェース（ＩＦ）
５３０ 記憶部
５３１ アプリケーションデータベース（ＤＢ）
５３１ａ 送集客ポイントＤＢ
５３１ｂ 会社情報ＤＢ
５３１ｃ 広告情報ＤＢ
５３３ バナーデータリスト
５３４ オファーデータリスト
５３５ ユーザＤＢ
５３６ ログＤＢ

Claims (6)

1. 端末装置に対して通信ネットワークを介して複数の電子商品のいずれかに関する広告情報を前記端末装置に提供する広告提供システムであって、
   前記複数の電子商品毎の可変パラメータを記憶するパラメータ記憶手段と、
   いずれかの前記電子商品に関する情報を含む広告情報を記憶する広告情報記憶手段と、
   前記広告情報をいずれかの電子商品に関連付けて前記端末装置へ送信する送信手段と、
   前記送信された広告情報が前記端末装置において利用されたことを示す利用情報を前記端末装置から受信する受信手段と、
   前記受信手段で前記利用情報が受信されると、前記広告情報を関連付けた電子商品に対応する可変パラメータ及び／又は前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを更新し、前記更新後の前記各可変パラメータに基づいて、前記送信手段を通じて送信する電子商品に関連付ける広告情報を制御する制御手段と、を備えた電子商品提供システム。
2. 前記利用情報には、前記端末装置で前記広告情報を選択したことを示す閲覧情報及び／又は前記広告情報を通じて前記広告情報に含まれる情報としての電子商品を導入処理したことを示す導入情報が含まれ、
   前記制御手段は、前記閲覧情報と前記導入情報とで前記可変パラメータの更新度合いを異ならせる、請求項１に記載の電子商品提供システム。
3. 前記パラメータ記憶手段は、前記電子商品の価格に対応した価格パラメータを記憶しており、
   前記制御手段は、前記価格パラメータによって前記可変パラメータの更新度合いを異ならせる、請求項１又は２に記載の電子商品提供システム。
4. 前記更新は、前記広告情報を関連付けた電子商品に対応する可変パラメータを増加または減少し、かつ、前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを減少または増加することを含む、請求項１乃至３のいずれか１項に記載の電子商品提供システム。
5. 端末装置に対して通信ネットワークを介して複数の電子商品のいずれかに関する広告情報を前記端末装置に提供する広告提供システムに用いられる広告制御装置であって、
   前記複数の電子商品毎の可変パラメータを記憶するパラメータ記憶手段と、
   いずれかの前記電子商品に関する情報を含む広告情報を記憶する広告情報記憶手段と、
   前記広告情報をいずれかの電子商品に関連付けて前記端末装置へ送信する送信手段と、
   前記送信された広告情報が前記端末装置において利用されたことを示す利用情報を前記端末装置から受信する受信手段と、
   前記受信手段で前記利用情報が受信されると、前記広告情報を関連付けた電子商品に対応する可変パラメータ及び／又は前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを更新し、前記更新後の前記各可変パラメータに基づいて、前記送信手段を通じて送信する電子商品に関連付ける広告情報を制御する制御手段と、を備えた広告制御装置。
6. 端末装置に対して通信ネットワークを介して複数の電子商品のいずれかに関する広告情報を前記端末装置に提供する広告提供システムに用いられる広告制御装置としてコンピュータを機能させる広告制御プログラムであって、
   前記コンピュータに、
   前記複数の電子商品毎の可変パラメータを記憶する処理と、
   いずれかの前記電子商品に関する情報を含む広告情報を記憶する処理と、
   前記広告情報をいずれかの電子商品に関連付けて前記端末装置へ送信する処理と、
   前記送信された広告情報が前記端末装置において利用されたことを示す利用情報を前記端末装置から受信する処理と、
   前記利用情報が受信されると、前記広告情報を関連付けた電子商品に対応する可変パラメータ及び／又は前記広告情報に含まれる情報としての電子商品に対応する可変パラメータを更新し、前記更新後の前記各可変パラメータに基づいて、前記送信する電子商品に関連付ける広告情報を制御する処理とを実行させる、広告制御プログラム。