以下に、図を用いて本発明の実施の形態を説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。
なお、実施例1は、主に請求項1、16、19について説明する。また、実施例2は、主に請求項2,11、12、13、15、17、20、29、30、31、33、34、35について説明する。また、実施例3は、主に請求項3、4、14、18、21、22、32について説明する。また、実施例4は、主に請求項5、6、7、8、9、23、24、25、26、27について説明する。また、実施例5は、主に請求項10、28について説明する。
≪実施例1≫
<概要>
図1は、本実施例の広告表示システムにおける広告表示の一例を表す概念図である。この図1(a)にあるように、7月7日のウェッブページ「ニュースサイト」の所定領域上に「ケータイ新モデル」の広告α1が表示されている。なお、統計上の予測などから、このニュースサイトの7月7日のアクセス数は「40000アクセス」だと推定されている。そして、この広告α1は、本実施例の広告表示システムによって、40000回の予想アクセスのうち支払対価に応じて決定された「10000回(アクセス)」という表示頻度で表示されるよう制御される。
また図1(b)に示すように同じ7月7日のウェッブページ「ニュースサイト」の所定領域上に、表示頻度を「5000回」として別の「セキュリティソフト」の広告α2が表示されるようにも制御される。また図1(c)に示すように表示頻度を「3000回」として別の「CPU」の広告α2が同日同領域に表示されるよう制御される、という具合である。
このように、本実施例の広告表示システムによって、一の表示領域において表示頻度を変えて複数の広告を表示することができる。
<機能的構成>
図2は、本実施例の広告表示システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「広告表示システム」(0200)は、「表示部」(0201)と、「広告蓄積部」(0202)と、「ユーザ入力情報受付部」(0203)と、「演算部」(0204)と、「制御部」(0205)と、を有する。
なお、以下に記載する本システム、また後述するオークションサーバ装置の機能ブロックは、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方として実現され得る。具体的には、コンピュータを利用するものであれば、CPUや主メモリ、バス、あるいは二次記憶装置(ハードディスクや不揮発性メモリ、CDやDVDどの記憶メディアとそれらメディアの読取ドライブなど)、印刷機器や表示装置、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のI/Oポート、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラム、情報入力に利用されるユーザインターフェースなどが挙げられる。
そして主メモリ上に展開したプログラムに従ったCPUの演算処理によって、インターフェースを介して入力されメモリやハードディスク上に保持されているデータなどが加工、蓄積されたり、上記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。
また、この発明はシステムとして実現できるのみでなく、方法としても実現可能である。また、このような発明の一部をソフトウェアとして構成することができる。さらに、そのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品、及び同製品を記録媒体に固定した記録媒体も、当然にこの発明の技術的な範囲に含まれる(本明細書の全体を通じて同様である)。
「表示部」(0201)は、ウェッブページの特定領域に広告を表示するための機能を有する。「ウェッブページの特定領域」とは、ウェッブページにおいて広告を表示するために設けられた所定の領域をいい、例えばウェッブページのHTML文書にて<align>タグなどで指定される領域が挙げられる。またこの特定領域は一のウェッブページ上に複数あって良い。
そしてこの表示部は、例えばウェッブページのHTML文書に埋め込まれた<img>などの引用タグや、広告表示用のScript言語を利用するための<script>タグなどを解釈し、当該タグで引用などされている広告データを取得する。そして取得した広告を<align>タグなどで指定されるウェッブページの特定領域に表示する、という具合である。
そして上記表示部の機能によってウェッブページ上の複数の特定領域に広告が表示されることになる。ところで当該ウェッブページ上の特定領域は、前述のように視認性などの差から広告効果に差が生じている。そこで広告効果の高い一の特定領域を特定の広告が占有などしないよう、本実施例の広告表示システムでは後述する構成によって表示頻度を変えて複数の広告が一の特定領域に表示されるよう制御することを特徴とする。
「広告蓄積部」(0202)は、ユーザが特定領域に表示を希望する広告を蓄積する機能を有し、例えば、HDDや不揮発性メモリ、光学系記憶ディスクとその読取媒体などの外部(二次)記憶装置によって実現できる。また、そのような記憶媒体にて蓄積される広告データとしては、例えばテキスト形式のデータや画像形式のデータ、あるいは動画形式のデータなどが挙げられる。
「ユーザ情報入力受付部」(0203)は、広告表示の対価を示す情報を含むユーザ入力情報を受付ける機能を有する。このユーザ入力情報受付部は、例えばGUI(グラフィカル・ユーザインターフェース)などを介して当該情報を入力する入力デバイスなどで実現することができる。また、当該GUIや入力デバイスは、ネットワーク上の広告クライアント(ユーザ)端末に具備されていても良い。その場合、ユーザ端末にて入力されネットワークを介して送信されたユーザ入力情報を、サーバ装置の「通信I/O(インプット/アウトプット)」などで受信する構成とすると良い。
図3は、所望の特定領域に関してユーザ入力情報として広告表示の対価を示す情報を入力するためのGUIの一例を表す図である。この図にあるように、ユーザは、例えばニュースサイトの所定領域αに関して、「12月31日に50口」、「1月2日に20口」といった具合に、1日単位で広告の支払対価(設定口数)を入力していく。そして、最終的に図中右下のチェックボタンをクリックすることで、本実施例の広告表示システムにその支払対価を含むユーザ入力情報が受付けられる、という具合である。
なお、支払対価の入力は1日単位ではなく、例えば1週間単位や12時間単位などで様々な単位で受付けて良い。
また各ユーザが過度に支払対価額を設定してしまわないよう、一ユーザが1日など所定の時間単位で支払うことができる対価の額や、同時間単位で全ユーザが支払うことができる対価の総額に上限を設けるよう構成しても良い。その場合、図3に示すように当該ユーザの1日当たりの残り口数などを表示するよう構成しても良い。また、さらに当該ユーザの支払対価(設定口数)が上限に達した場合には警告メッセージを出力したり、図中チェックボタンをグレーアウト(操作不可状態)にしたりしても良い。
また、実施例5にて後述するように入力を受付けた支払対価に応じた「見込表示回数(見込表示頻度)」を表示しても良い。
また、上記広告表示の対価を示す情報以外のユーザ入力情報としては、例えばユーザID、広告表示を希望するウェッブページやその特定領域の指定情報、広告蓄積部にて蓄積されている広告を指定する情報などが挙げられる。
図4は、このようにGUIを介して各ユーザから受付けたユーザ入力情報を管理するためのテーブルデータの一例を表す図である。この図にあるように、例えば、特定領域「ポータルP−1A」に関して、ユーザID「Hモバイル」で示されるユーザが携帯電話の広告「931H.flv」を表示するための対価「10000円」を支払っている。また、同様に特定領域「ポータルP−1A」に関して、「(株)イージス」がソフトウェアの広告「security.jpg」を表示するための対価「5000円」を支払い、「パソコンショップI」がPCショップの広告「cpu.png」を表示するための対価「3000円」を支払っている。
また、別の特定領域「ニュースサイトN−B」では、「福岡自動車」が自動車の広告「car.avi」を表示するための対価「7500円」を支払っている。また、さらに別の特定領域「料理屋サイトC−C」では、「牛肉本舗」が精肉の広告「meat.txt」を表示するための対価「1000円」を支払っている、という具合である。
そして、このようなユーザ入力情報を利用して、本実施例の広告表示システムは以下の構成により広告の表示頻度を算出し、その頻度に従い広告表示を制御する。
「演算部」(0204)は、ユーザ入力情報から得られる全体のユーザの対価における各ユーザの対価の割合に基づいて広告の表示頻度を演算する機能を有し、例えばCPUや主メモリなどの演算装置によって実現することができる。
「表示頻度」とは、例えば「10000回/1日(予想アクセス数40000)」といった具合に1日など所定時間あたりの表示回数で示される頻度が挙げられる。また、その他にも、「広告Aは4日/1週間」、「広告Bは次の3日/1週間」といった具合の所定時間あたりの表示時間で示される頻度が挙げられる。
そして演算部では、ユーザ入力情報から得られる全体のユーザの対価に対する各ユーザの対価の割合に基づいて上記のような表示頻度を演算する、という具合である。なお、表示頻度が「広告の表示回数」である場合、例えば前述のように統計データを利用して予想全アクセス数を推定し、その予想全アクセス数を各ユーザの対価の割合で除することで表示回数を演算すると良い。
具体的には、例えばウェッブページ「ポータルP」への翌日の予想アクセス数は、これまでの統計データから「40000アクセス」と推定される。そして、その日の特定領域「ポータルP−1A」に対するユーザ(広告クライアント)全体の広告対価総額が40000円であった場合、図4に示すように広告ID「AD001」で示される広告(支払対価「10000円」)の対価支払比率は25%と算出される。したがって、40000アクセス中の25%、すなわち「10000回」が広告ID「AD001」の広告の表示頻度として算出される、という具合である。
もちろん、上記例は一例であり、各ユーザの対価比率に所定の係数を加えるなどして表示頻度を算出するよう構成しても良い。例えば表示頻度が「12時間/1週間」といった具合に所定時間あたりの表示時間で示される場合、当該広告の表示がアクセス数の少ない深夜に集中するなどの可能性がある。そのような場合、広告効果自体は低いと想定されるため、表示頻度を「24時間/1週間」といった具合に2倍に補正する、という具合である。また、表示頻度は広告ごとに算出されるのではなく、広告主(ユーザ)ごとに算出されるよう構成しても良い。
このように、演算部によって支払対価に応じて一の特定領域に対する広告の表示頻度が算出される。そしてその算出した表示頻度を利用して、当該特定領域における広告表示が制御される、という具合である。
「制御部」(0205)は、演算部(0204)で演算された表示頻度に基づいて定められる制御ルールに従って広告蓄積部(0202)に蓄積された広告を表示部(0201)に表示させる制御をする機能を有する。
ここで、まず、制御部における広告の表示頻度に基づいた制御ルールの決定、およびその制御ルールに従った表示広告の決定に関する処理概要について、表示頻度として表示回数を例に挙げ図5を用いて説明する。
図5は、制御部による制御を実現するための制御ルールの一例を表す概念図である。この図にあるように、例えば表示頻度が1日当たりの表示回数により示される場合、制御ルールは、ランダム関数で利用するための数値を、表示頻度に基づいて定めると良い。具体的には「広告ID:AD001(931H.flv)」に関する制御ルール中の<total>で示される数値を、表示頻度における全体のアクセス予想数である「40000」とする。また、制御ルール中の<random>で示される数値を、前記算出された表示回数である「10000」とする。
そしてこのように定められた制御ルールにしたがって、まず<total>で示す「0〜40000」を算出範囲としてランダム関数にて数値を算出する。そして、その算出された数値が、<random>で示される値「10000」以下の数値であれば、当該広告AD001をウェッブページの特定領域に表示する広告として決定する。また、「10001〜15000」であれば、次の制御ルール(Adrule2)から広告AD002をウェッブページの特定領域に表示する広告として決定する、という具合である。
続いて、上記処理によって決定された広告を表示部にて表示するための制御の一例について以下に説明する。
すなわち制御部は、例えばクライアント端末からアクセス(HTTPリクエスト)がある都度、上記広告決定処理を実行する。そしてリクエストのあったウェッブページのHTML文書に埋め込まれた前記<img>タグや<script>タグが引用する広告データのURLを、決定された広告のものに変更する処理を実行する。それによってクライアント端末にて閲覧されるウェッブページ上の特定領域に、HTML文書の上記タグによって引用された当該広告が表示されることになる、という具合である。
そして、制御部におけるこのような制御によって、例えば「広告AD001」は、表示部にて7月7日の全アクセス予想数40000のうち、10000回の頻度でニュースサイトの特定領域上に表示される。また、その他の広告AD002やAD003も、その表示頻度に応じて同時のニュースサイトの特定領域上に、5000回の頻度や3000回の頻度でそれぞれ表示されることになる、という具合である。
またその他にも、例えば表示頻度が1週間当たりの表示時間などにより示される場合の制御ルールとして、表示開始時刻と表示終了時刻を示す制御ルールなども挙げられる。そして内蔵時計などを監視し制御ルールで示される時刻になると、ウェッブページのHTML文書中の上記タグが引用する広告のURLを変更する処理を行っても良い。
なお本発明の広告表示システムは、例えば上記構成要件の全てが一のサーバ装置に設けられ、その一のサーバ装置によって実現される形態であっても良い。あるいは、本発明の広告表示システムは、例えばクライアント端末とサーバ装置とで構成され、表示部はクライアント端末に動的アプリケーションなどとして備えられ、その他構成要件はサーバ装置に備えられている、といった具合に二以上の装置上で分割して設けられる構成であっても良い。
また後者の構成の場合、例えばサーバ装置からクライアント端末に対して広告抜きのウェッブページと、表示すべき広告および制御ルールを送信する。そして、クライアント端末に設けられた表示部である動的アプリケーションなどの処理によって、当該Webブラウザの所定領域上に制御ルールで示される表示頻度に従った広告表示が実行される、といった構成により上記機能を実現しても良い。
<ハードウェア構成>
図6は、上記機能的な各構成要件をハードウェアとして実現した際の、広告表示システムにおける構成の一例を表す概略図である。この図を利用して表示頻度に応じた広告表示処理におけるそれぞれのハードウェア構成部の働きについて説明する。
この図にあるように、広告表示システムは、表示部、演算部及び制御部である「CPU(中央演算装置)」(0601)と、「主メモリ」(0602)と、を備えている。また広告蓄積部である「HDD」(0603)や、ユーザ入力情報受付部である「I/O」(0604)も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
また、「主メモリ」は、各種処理を行うプログラムをCPUに実行させるために読み出すと同時にそのプログラムの作業領域でもあるワーク領域を提供する。また、この「主メモリ」や「記憶装置」にはそれぞれ複数のアドレスが割り当てられており、「CPU」で実行されるプログラムは、そのアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。
ここで、図3のようなGUIを利用しユーザ(広告クライアント)が自身の端末にて入力した広告の支払対価を含むユーザ入力情報を「I/O」にて受信し、「主メモリ」のアドレス1に格納する。また、その他のユーザからのユーザ入力情報も同様に受信し、「主メモリ」の所定アドレスに格納する。そして、格納したユーザ入力情報を図4に示すようにテーブルデータとしてまとめ、広告管理データベース(DB)として「HDD」の所定アドレスに蓄積、管理する。
そして表示制御プログラムに従い、「広告ごとに所定単位(7月7日など)で特定領域ポータルP−1Aに対して支払われる対価」について、例えば広告AD001は「10000円」、広告AD002は「5000円」といった具合に取得する。そして「CPU」の演算処理によってその対価総額、例えば「40000円」を算出し、「主メモリ」のアドレス2に格納する。そして、その算出した全体のユーザの対価総額に対する各ユーザの対価の割合を「CPU」の演算処理によって算出し、「主メモリ」のアドレス3に格納する。
具体的には、図4中の広告AD001は特定領域ポータルP−1Aに対して「10000円」の支払があるので、同特定領域に対する全体対価総額の「40000円」のうちの割合が「25%」と算出される。同様に広告AD002は対価比率「12.5%」、広告AD003は「7.5%」と算出される、という具合である。
続いて広告管理DBにて予め保持されている「ポータルP(特定領域ポータルP−1Aを含む)」への翌日(7月7日)の予想アクセス数、例えば「40000アクセス」を取得する。あるいは別に保持されている統計データを利用して、「CPU」の演算処理によって予想アクセス数「40000アクセス」などを算出する。そして、前記算出した対価比率の値にてこの予想アクセス数を除する演算処理を「CPU」にて実行することで、表示頻度を算出し「主メモリ」のアドレス4に格納する。
具体的には、図4中の広告AD001の表示頻度については、40000アクセス中の25%であるので「10000回」と算出される。同様に広告AD002については表示頻度「5000回」、広告AD003については「3000回」と算出される、という具合である。
そして、算出された表示頻度を利用して、例えば図5に示すような制御ルールを「CPU」の演算処理によって生成し、「主メモリ」のアドレス5に格納する。そして、このように生成、格納された制御ルールを、「HDD」の広告管理DBに追加し、管理する。
そして当日(7月7日)、ネットワーク上端末装置からのウェッブページ「ポータルP」へのアクセス(HTTPリクエスト)を「I/O」にて受信すると、制御ルールに従い以下のように処理を行う。すなわち、「CPU」によるランダム関数を利用した演算処理の結果、「10365」という数値を算出する。これは、制御ルールの<Adrule2>の<random>で示される範囲内の数値であるので、当該アクセスでは広告AD002で示される「security.jpg」が特定領域に表示される広告として決定される、という具合である。
そしてその演算結果に従い、「CPU」は「ポータルP」のHTML文書中の<script>タグが引用する広告データのURLを、決定された広告の「security.jpg」に変更する処理を実行する。そしてそのHTML文書データを「I/O」からHTTPレスポンスとしてネットワーク上の端末に返信する。それによって、当該端末上では広告AD002が「ポータルP」の特定領域上に表示される。
そして上記処理をネットワーク上の端末からのアクセスの都度実行することで、支払対価に応じた表示頻度で広告がウェッブページの特定領域上に表示される、という具合である。
<処理の流れ>
図7は、本実施例の広告表示システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。
この図にあるように、まず、広告表示の対価を示す情報を含むユーザ入力情報を受付ける(ステップS0701)。そして受付けたユーザ入力情報から得られる全体の対価を算出し(ステップS0702)、全体のユーザの対価に対する各ユーザの対価の割合を算出する(ステップS0703)。
つづいて、算出した対価の割合に応じて各ユーザが表示を希望する広告の表示頻度を算出し(ステップS0703)、算出した表示頻度に基づいて制御ルールを定める(ステップS0705)。そして、決定した表示ルールに従い広告をウェッブページの特定領域に表示するよう制御する(ステップS0706)。
<効果の簡単な説明>
以上のように本実施例の広告表示システムによって、支払対価に応じて一の表示領域における広告ごとの表示頻度を決定し、一の表示領域にて表示頻度を変えた複数の広告を表示することができる。
したがって少ない支払対価でも頻度が少ないとはいえ所望の表示領域に広告を表示することができるので、本発明の広告表示システムによって全ての広告クライアントの満足度を充足させることが期待できる。
≪実施例2≫
<概要>
本実施例は、上記実施例1を基本として、オークション関連ページの特定領域にオークション出品物の広告を支払対価に応じた表示頻度で表示することを特徴とする広告表示システムである。
図8は、本実施例の広告表示システムにおける広告表示の一例を表す概念図である。この図8(a)にあるように、ウェッブページ「オークションサイト」にて「トラックボールマウス」や「エクスプローラマウス」、「ワイヤレスマウス」などが出品されている。
ここで、オークション出品物「トラックボールマウス」β1は広告の対価を支払っているため、特定領域にその広告α1が表示されている。またこの表示時点では、広告α1は10000回として制御されている表示頻度のうち3000回目の表示である。したがって、この広告α1は現時点で残り7000回表示されるよう制御されるはずである。
ところが、このトラックボールマウスは、その後「希望落札価格」の3000円で入札した者がいたため即決で落札となり、「オークションサイト」ページ上での表示が終了した。すると本実施例の広告表示システムでは、図8(b)に示すように出品が終了した出品物に関してはその後の表示を行わないよう削除し、例えば図示しない別のオークション出品物の広告に差替えるなどすることを特徴とする。
このように、特にオークション出品物は、支払対価に応じた表示頻度が残っていても例えば即決価格などによって早期落札、出品終了がなされる場合がある。そのため本実施例では出品終了となった場合に、例えば当該出品物に係る広告の表示を終了したり、別の出品物に係る広告に差替えたりするなどの処理を行う、という具合である。そしてこのような処理を実行することで、商品自体が無く表示する意味の無い広告を表示してしまう、などの無駄を省くことができる。
<機能的構成>
ここで前述のように、本実施例はオークション関連ページにて広告を表示することを特徴とする。そこで本実施例の広告表示システムの構成要件について説明する前に、そのオークション関連ページを利用したオークションを実行するためのオークションサーバ装置について、以下に図を用いて説明する。そして以下の説明の後で、当該オークションサーバ装置との協働によってその機能を実現する本実施例の広告表示システムの各構成要件について説明する。
図9は、本実施例の広告表示システムが広告を表示するオークション関連ページに係るオークションサーバ装置(また、そのオークションサーバ装置で実現されるオークションシステム)の機能ブロックの一例を表す図である。この図にあるように、「オークションサーバ装置」(0910)は、「出品受付部」(0911)と、「出品表示部」(0912)と、「入札受付部」(0913)と、「落札決定部」(0914)と、を有する。
「出品受付部」(0911)は、オークションへの出品を受付ける機能を有し、例えば通信IFやCPUなどの演算回路、記憶装置、そしてそれらを制御するための出品受付プログラムなどによって実現できる。また、「オークションへの出品を受付ける」とは、例えば具体的にオークション出品者が自身の端末(0920)にて商品名や商品写真、商品紹介文章、オークション開始価格、出品者IDなどを出品商品情報として入力し送信する。また、その他に出品商品の入札単位金額や、オークション開始日時および終了日時、あるいは最低落札希望金額や即決価格なども出品商品情報として入力、送信されても良い。そして出品受付部では、上記オークションサーバ装置からの送信情報を、オークションへの出品として受付ける、という具合である。そしてオークションサーバ装置ではその受付けた出品商品情報に対し、例えば送信順にオークション出品IDなどを付加し管理する、という具合である。
また後述するように、本実施例の広告表示システムでは、このオークションサーバ装置(オークションシステム)で受付けたオークションの出品物に係る広告を表示することを特徴とする。すなわち、この出品受付部にて受付けた出品者が広告主(ユーザ)となり、その商品(出品物)の広告表示を希望することになる。したがって、この出品受付部にて出品の受付とともに、その出品の広告を希望するか否かの広告依頼情報なども受付けるよう構成しても良い。また広告の希望があった場合、出品受付に応じて生成した出品IDと広告表示システムに送信し、広告表示システムにて後述するように、その出品IDと広告IDとを関連付けて管理するよう構成すると良い。
そしてこのように管理されているオークション出品IDなどが本実施例の広告表示システムに送信されることで、広告表示システムにてオークション関連ページの広告表示を制御することができる。
「出品表示部」(0912)は、出品受付部にて受付けた出品を表示する機能を有し、例えばCPUなどの演算装置やクライアント端末に表示用情報を送信するための通信IF、またそれらを制御するための出品表示プログラムによって実現できる。具体的に、例えば受付けた出品商品情報に基づいてオークション関連ページを生成し、入札者の端末にて表示させるための機能を有する。そして本実施例の広告表示システムから送信された制御ルールに従い、ここで生成されるオークション関連ページの特定領域にて支払対価に応じた表示頻度での広告表示が実行される、という具合である。
また、ここで表示されるオークション関連ページ(オークションWebページ)では、広告表示システムの制御によってオークション出品物に係る広告の表示も実行される。もちろん当該広告表示は、オークション関連ページにて入札を受付けている出品物自身に係る広告が表示されるよう制御されても良いし、全く関係の無いオークション関連ページに広告が表示されるよう制御されても良い。いずれにせよ、このようにオークション関連ページにて表示される広告は、前述のようにその広告表示対価の支払割合に応じて表示頻度が演算され、一の広告スペースに表示頻度を変えて表示されることを特徴とする。
「入札受付部」(0913)は、出品表示部にて表示されている出品に対する入札を受付ける機能を有し、具体的に例えば、オークション関連ページを介して入札者端末にて実行された入札金額や入札者を識別するIDなどを含む入札情報を受付ける。
「落札決定部」(0914)は、入札受付部において受付けた入札に応じて落札を決定し、または出品時間に基づいてオークションの終了を決定し、その結果を決定結果として広告表示システムに出力する機能を有し、例えばCPUなどの演算回路や決定結果の出力用通信IF、またそれらを制御するための落札決定プログラムによって実現できる。具体的に例えば、入札受付部にて受付けた入札情報を利用して出品物の落札を決定したり、予め設定された出品終了時間までに入札が無かったり落札金額が最低落札額に届かなかったりした場合に入札を締め切ったりした結果を決定結果とする。そして、その決定結果を示す情報を、広告表示システムに対して送信する、という具合である。なお、上記のオークションの終了となる落札決定処理や締切決定処理の詳細については、従来のオークションシステムにおけるものと同様の処理であるので詳細な説明は省略する。
そして、ここでの処理によって生成される出品IDなどを含む落札情報が、本実施例の広告表示システムに送信されることで、その商品のオークション終了を通知する、という具合である。
図10は、本実施例の広告表示システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「広告表示システム」(1000)は、実施例1を基本として、「表示部」(1001)と、「広告蓄積部」(1002)と、「ユーザ入力情報受付部」(1003)と、「演算部」(1004)と、「制御部」(1005)と、を有する。なお、上記構成要件は実施例1にて記載済みであるので、その説明は省略する。
そして本実施例の広告表示システムの特徴点は、表示部が「オークションページ表示手段」(1006)をさらに有し、広告蓄積部が「限定蓄積手段」(1007)をさらに有し、そして演算部が「終了依存削除手段」(1008)をさらに有する点である。
「オークションページ表示手段」(1006)は、ウェッブページの特定領域としてオークション関連ページの特定領域に広告を表示する機能を有する。なお、このオークションページ表示手段は、ハードウェア上では上記オークションサーバ装置の出品表示部に含まれていると良い。
また、このオークションページ表示手段は、概要例のようにオークション出品物とその広告とが同一ページに表示されるようなオークションページを表示しても良いし、両者が別個のページに表示されるようなオークションページを表示しても良い。
また、広告そのものがオークション入札用のフォームを有していたり、同フォームへのリンクが張られていたりするオークションページを表示するよう構成されていても良い。また、その場合には、オークション関連ページの特定領域が「おすすめ品」などを表示するための特別枠などであっても良い。
「限定蓄積手段」(1007)は、前記広告をオークション出品物に限定して蓄積する機能を有する。「限定して蓄積する」とは、具体的には、前述のオークションサーバ装置から送信された出品IDを受信する。そして、蓄積するための広告を取得した際に、受信した出品IDと関連付けられているか否かの判断処理を行い、関連付けられていない広告は蓄積しない、といった処理が挙げられる。
図11は、本実施例の広告蓄積部にて蓄積されている広告を管理するためのテーブルデータの一例を表す図である。この図にあるように、例えば広告IDのほか、出品IDや出品者ID、オークション開始/終了日などの情報によって管理されていると良い。また、ここで蓄積されているテーブルデータに係る出品物IDや出品者IDは、前述のオークションサーバ装置(オークションシステム)にて出品受付に応じて付与され、この広告表示システムに対して送信されてきた出品IDを利用して生成されると良い。そして、このように広告IDと出品IDとを関連付けたテーブルデータを利用した広告と出品の連動管理処理は、通常のウェッブページにおけるバナー広告などの表示においては必要のない処理であって、オークションの出品に係る商品を広告表示する際に特有の処理である。
「終了依存削除手段」(1008)は、オークションにおいて広告に係る出品物のオークションが終了したかの検知結果を取得して、検知結果に基づいてオークションが終了した出品物に係る広告を広告蓄積部から削除するための処理を行う機能を有する。
この終了依存削除手段でのオークション終了の検知結果の取得は、前述のようにオークションサーバ装置の落札決定部から送信される出品IDを含む落札情報を受信することで当該検知結果を取得すると良い。
そして終了依存削除手段では、その検知結果取得をトリガーとして例えば以下のような処理を行うことで、オークション出品商品に係る広告を広告蓄積部から削除する処理を行う。すなわち、例えば広告データそのものを広告蓄積部であるHDDから削除する処理が挙げられる。あるいは広告管理DB上の広告IDのみ削除したり、広告管理DB上の広告IDに終了フラグを付加したりすることで当該広告を表示させないようにしても良い。あるいは、上記終了出品物に係る広告の表示頻度を全て「0」とする処理なども挙げられる。
また、このようにオークション終了によって中途削除された広告の替わりについては、例えば実施例3で後述するように、補充広告を取得することで補填するよう構成すると良い。あるいは、補充広告が無い場合などには、終了出品物に係る広告の残された表示頻度を広告管理DBなどから取得し、その残り頻度を同じ特定領域に表示すべきその他の広告の表示頻度に割り振る演算処理を行っても良い。また、その際には、図11に示す出品者IDなどをキーとして同一の出品者の出品物を特定し、同一出品者の出品物に対してのみ表示頻度の残り分を割り振るよう構成しても良い。
なお、その他複数の広告に残り表示頻度分を割り振る比率は、実施例1で記載した表示頻度の算出と同様に支払対価に応じて算出すると良い。
このようにして、オークション出品物のオークションが終了した場合には、それを検知して終了出品物に係る広告について、特定領域への表示中止や差替えなどを行い、広告スペースを有効に活用することができる。
また、このような本実施例の広告表示システムと、オークションサーバ装置で実現されるオークションシステムとが連動することでオークション関連ページに広告を表示するシステム(以下、オークション広告表示複合システムと記載)は、以下のような特徴点を有する。すなわち前述の限定蓄積手段にて記載したように、オークション関連ページに表示される広告はオークション出品物に係る広告になるので、当該オークション広告表示複合システムにおける広告表示システムは、広告IDとオークション出品物の出品IDとを関連付けて管理する構成を備えると良い。
すなわち、本実施例の広告表示システムは、図25に示すように、その広告蓄積部が「広告出品テーブル保持手段」(2509)を有するとともに、「結果取得部」(2510)を有することを特徴とする。
「広告出品テーブル保持手段」(2509)は、広告出品テーブルを保持する機能を有する。なお「広告出品テーブル」とは、限定蓄積手段にて限定して蓄積されるオークション出品物の広告の広告IDと、そのオークション出品物の出品IDとを関連付けたテーブルデータをいう。具体的にこの広告出品テーブルは、例えば前述のようにオークションサーバ装置から出力された出品IDを受信する際に、その出品物に係る商品写真や広告文章も合わせて受信するよう構成する。そして、それら情報を利用してオークション関連ページに表示する広告画像を生成し、当該広告画像に対して広告IDを付与する。そして、受信した出品IDと、その広告IDとを関連付けて広告出品テーブルを生成する、という具合である。もちろん、上記例は広告出品テーブル生成の一例であって、例えば予め商品名と広告画像とを蓄積しておき、出品ID受信時には商品名を合わせて取得すること広告画像を選択決定する構成とし、その選択した広告画像に対し広告IDを付与し出品IDと関連付けても良い。
図26は、この広告出品テーブルの一例を表す概念図である。この図にあるように、前述のオークションサーバ装置(またそれで実現されるオークションシステム)において受付けられ出品されている「トラックボールマウス光学式」を示す出品IDと、その「トラックボールマウス光学式」をオークション関連ページに表示するための広告IDと、が関連付けられている。このようにして本実施例の広告表示システムでは、オークションの出品と広告の表示とを連動して管理する構成を備える。したがって、例えばオークションの出品が予定よりも早く終了し、オークションシステムからその終了を通知する決定結果を本実施例の広告表示システムが受信した場合、この広告出品テーブルを参照して、出品が終了した商品に係る広告を連動して終了するなどの処理を行うことができる。
また、このような処理は、通常のウェッブページにおけるバナー広告などの表示においては必要のない処理であって、オークションの出品に係る商品を広告表示する際に特有の処理である。
「結果取得部」(2510)は、オークションシステムの落札決定部から出力される決定結果を取得して演算部に検知結果として出力する機能を有し、例えば、通信IFやCPUなどの演算装置、またそれらを制御するための結果取得プログラムによって実現することができる。
具体的に、前述のようにオークションの出品が終了した旨を示す決定結果を受信した場合、広告表示システムはこの広告出品テーブルを参照して、出品が終了した商品に係る広告も商品のオークション終了と連動させて終了した上で、表示頻度の再計算を行うための命令を演算部に出力する、という具合である。
<その他の機能的構成>
また、上記のオークションサーバ装置と広告表示システムとからなる「オークション広告表示複合システム」は、さらに図示しない以下のような構成を備えていても良い。すなわち、広告表示システムの広告蓄積部が、「広告ユーザIDテーブル保持手段」をさらに有していても良い。
「広告ユーザIDテーブル保持手段」は、広告ユーザIDテーブルを保持する機能を有する。「広告ユーザIDテーブル」とは、限定蓄積手段に蓄積された広告の広告IDと、その広告を希望するユーザのユーザIDとを関連付けたテーブルをいう。すなわち前述の広告出品テーブルでは広告と出品とを関連付けて管理することで、例えばオークション出品の出品終了に合わせて広告表示も終了する、といったオークション出品物の広告特有の連動管理を可能としている。
一方、この「広告ユーザIDテーブル」では、広告IDとユーザID(出品者兼広告主)とを関連付けて管理することで、ユーザをキーとしてさらに幅広く広告とオークション出品物とを連動管理することができる。すなわち、通常ユーザは、出品者として複数のオークション出品を行っていることが多い。つまり、ユーザは複数の広告の表示を希望する広告主でもある。したがって、ある出品の終了に合わせて広告表示を終了する場合、この「広告ユーザIDテーブル」を参照することで、その出品者=広告主の他の出品に係る広告を終了した広告に差替えて表示するなどの連動表示を可能とする、という具合である。なお、この広告の差替表示に係る処理については、実施例3などで説明する。
図27は、この広告ユーザIDテーブルの一例を表す概念図である。この図にあるように、オークションサーバ装置(オークションシステム)に係るオークションにて、ユーザID「nine01」で識別されるユーザは、出品ID「001」で識別される「トラックボールマウス光学式」のほかにも、出品ID「002」の「エクスプローラマウス(シルバー)」なども出品していることが管理されている。したがって、例えば「トラックボールマウス光学式」の出品が終了しその広告表示も連動して終了する場合に、この広告ユーザIDテーブルを参照して、「トラックボールマウス光学式」の替わりに同一出品者(広告主)の「エクスプローラマウス(シルバー)」の広告の表示頻度を再演算し、替わりに広告表示を行うことができる。
また、「オークション広告表示複合システム」は、さらにまた別の図示しない以下のような構成を備えていても良い。すなわち、オークションサーバ装置(オークションシステム)の落札決定部が、「非定常終了受付手段」をさらに有していても良い。
「非定常終了受付手段」とは、落札成立や受付時間経過による入札終了(落札不成立)に加えて、さらにオークション主催者によるオークション出品の取消の決定、又は/および出品者によるオークション出品の削除の決定を決定結果として受付ける機能を有する。このような「非定常の終了結果」としては、例えば出品物が公序良俗に反するものである場合や、出品者に規約違反や詐欺行為の疑いがある場合に、オークション主催者が主催者用管理Webページなどを介して設定入力した終了結果が挙げられる。あるいはオークション出品者の一身上の都合(旅行で出品管理が出来ないなど)がある場合などにオークション出品者が出品の早期終了をするために出品者用管理Webページを介して設定入力した終了結果が挙げられる。
そして、このようなオークションに特有のイレギュラーな理由による広告表示の終了に係る処理もまた、当然オークションの出品に係る商品を広告表示する際に特有の処理として本実施例のオークション広告表示複合システムにて実行される。
またこのオークション広告表示複合システムは、例えば以下のような機能を備えていても良い。すなわち、例えばオークションシステムが検索機能を備え、広告表示システムはその検索結果を表示するページ上の特定領域に、制御ルールにしたがって「カメラα」(出品番号00X)の広告を表示する予定となっている。
ところが、当該広告が表示されるページには、検索結果として同じ「カメラα」で別の出品(出品番号99Y)が表示される。そして、この出品番号99Yの「カメラα」の現在入札価格は、「2000円」であり、一方、広告表示予定の出品番号00Xの「カメラα」の現在入札価格は「2500円」である。このように、広告表示予定のオークション出品と同種の商品がより安い入札価格で広告出品と同一ページに表示される場合、その広告効果はむしろマイナスに作用してしまう。そこで、このオークション広告表示複合システムでは、上記のような場合には制御ルールに従った広告の表示を行わない機能を有する、という具合である。なお、その場合には、特定領域には何も表示されないよう構成しても良いし、別の広告を差替えるよう構成しても良い。また、それに加えて、広告表示を1回キャンセルした分を補償するため演算部での表示頻度の演算を再度実行するよう構成しても良い。
そして上記機能を実現するために、このオークション広告表示複合システムは、以下のような構成要件を有していると良い。すなわち、オークション広告表示複合システムを構成する「オークションシステム」は、上記すでに記載した構成に加えて、さらに「検索部」と、「検索結果出力部」と、「検索結果表示部」と、を有する。
「検索部」とは、任意の検索キーを受付け、受付けた検索キーに基づいてオークション出品物を検索する機能を有する。具体的に、例えば検索キーワードとして商品名や商品カテゴリー、入札の現在価格など様々な検索条件を検索キーとして受付け、その検索キーに合致する出品を、図11などに示すような出品管理DBから検索する、という具合である。
なお、この検索部での検索結果には、検索にヒットした出品に係る出品IDのほか、後述する表示予定広告との価格比較のために、当該出品商品の商品種を識別する商品ID(商品名や機種番号など)や、その出品の現在価格なども取得するよう構成すると良い。
「検索結果出力部」は、検索結果を広告表示システムに出力する機能を有する。具体的に、この検索結果出力部は、検索結果を後述する広告予定出品現在価格と、前記同一種出品現在価格との比較判断処理のため、広告表示システムに送信する、という具合である。なお、検索結果として、前述のように当該出品商品の商品IDや現在価格などを関連付けて同時に広告表示システムに送信するよう構成しても良い。あるいは、検索結果としては検索にヒットした出品IDのみ送信し、広告表示システムから当該出品商品の商品IDや現在価格などの送信リクエストがあるつど、それら情報を送信するよう構成しても良い。
「検索結果表示部」は、検索部での検索結果を、前記広告表示システムのオークションページ表示手段により広告を表示するための前記特定領域とともに表示する機能を有する。具体的に、検索結果表示部は、検索結果の写真付リストなど所定のページレイアウトにしたがって検索結果を表示する事に加えて、そのページ上に広告表示用の特定領域も用意している点を特徴とする。なお、その特定領域は検索結果を表示するページ内に同時に設けられていても良いし、別ウィンドウなどとして検索結果を表示するページに重ねて同時に表示されるよう構成しても良い。
そして、この特定領域に対して制御ルールにしたがった広告表示が行われる事になるが、その際、前述のように広告表示予定の出品よりも安い入札価格である、同一商品種で別の出品商品が検索結果として表示される可能性がある。そこで、このオークション広告表示複合システムを構成する広告表示システムでは以下の構成を備えることでその旨を判断し、広告効果がマイナスとならないよう表示予定の広告を表示しないなどの処理を行うことを特徴とする。
すなわち、オークション広告表示複合システムを構成する「広告表示システム」は、上記すでに記載した構成に加えて、さらに「検索結果取得部」と、「広告出品ID取得部」と、「広告予定出品現在価格取得部」と、「商品ID取得部」と、「同一種出品現在価格取得部」と、「価格判断部」と、「非表示制御部」と、を有する。
「検索結果取得部」は、オークションシステムから出力された検索結果を取得する機能を有する。
「広告出品ID取得部」は、オークションページ表示手段にて、前記制御ルールに従って前記特定領域に表示する予定の広告IDを取得し、広告出品テーブルからその広告IDに関連付けられた出品IDを取得する機能を有する。このようにして、この広告表示システムでは、制御ルールにしたがって出品の検索結果の表示ページ上に表示する予定の広告に係る出品IDを特定する。
「広告予定出品現在価格取得部」は、前記出品IDで識別される広告予定の出品の現在価格を取得する機能を有する。この広告予定出品現在価格取得部は、例えば広告表示予定の出品の現在価格の送信リクエストを、前記取得した出品IDを含めてオークションシステムに送信し、そのレスポンスとしてその出品の現在価格を取得する方法で実現することができる。あるいは、検索結果中に、前記取得した広告表示予定の出品IDと同一の出品IDが含まれており、また、当該検索結果中の出品IDに現在価格も関連付けてオークションシステムより送信されていれば、その検索結果からその出品の現在価格を取得する方法で実現することもできる。
そして、さらにその特定した広告表示予定の出品の現在価格と比較するため、広告表示システムは以下の「商品ID取得部」や「同一種出品現在価格取得部」などの構成によって、広告表示予定の出品と同一商品種の別の出品の現在価格を取得する。
「商品ID取得部」は、前記出品IDで識別される出品に係る商品の商品種を識別するための商品IDを取得する機能を有する。なお、この商品IDは、例えば商品名や機種番号、品種など商品そのものを識別する情報のほか、例えば「カメラ」、「りんご」などの当該商品のカテゴリーを示す情報であっても良い。その場合、価格の比較がより広い範囲を対象として実行できる利点を生じる。ただし、その一方で同一カテゴリーの商品であってもハイエンド商品、ローエンド商品という具合にその絶対的な価格に差が生じる場合があるので、ここで取得される商品IDは、商品そのものを識別する商品名や機種番号、品種などの情報であることが好ましい。
「同一種出品現在価格取得部」は、商品ID取得部にて取得した商品IDに基づいて、検索結果取得部にて取得した検索結果に含まれる出品IDを検索して同一商品種の出品IDを抽出し、抽出した出品IDで示される同一商品種の出品の現在価格を取得する機能を有する。この同一種出品現在価格取得部も、前述の広告予定出品現在価格取得部同様に、例えば同一種出品の現在価格の送信リクエストをオークションシステムに送信し、そのレスポンスとしてその現在価格を取得する方法で実現することができる。あるいは検索結果中に、その出品IDに現在価格が関連付けられていれば、その検索結果からその現在価格を取得する方法で実現することもできる。
「価格判断部」は、前記広告予定出品現在価格と、前記同一種出品現在価格と、いずれの価格が高いかを判断する機能を有する。なお、例えば同一種出品が複数ある場合、全ての同一種出品価格よりも高いかを判断する構成であっても良いし、いずれか一の同一種出品価格よりも高いか、すなわち一つでも広告予定出品よりも安い同一種の別出品があるかを判断する構成であっても良い。
「非表示制御部」は、価格判断部での判断結果が、広告予定の出品の価格の方が高いとの判断結果である場合には、オークションページ表示手段にて前記制御ルールに従って前記特定領域に表示する予定の広告を表示しないよう制御する機能を有する。
このようにして、このオークション広告表示複合システムでは、広告表示予定のオークション出品と同種の商品がより安い入札価格で広告出品と同一ページに表示されるような場合、広告を表示しないようにすることができる。なおその場合には、前述のように特定領域には何も表示されないよう構成しても良いし、別の広告を差替えるよう構成しても良い。また、それに加えて、広告表示を1回キャンセルした分を補償するため演算部での表示頻度の演算を再度実行するよう構成しても良い。
<ハードウェア構成>
図12は、上記機能的な各構成要件をハードウェアとして実現した際の、広告表示システムにおける構成の一例を表す概略図である。この図を利用してオークション出品物に係る広告の表示処理におけるそれぞれのハードウェア構成部の働きについて説明する。
この図にあるように、広告表示システムは、実施例1同様に「CPU」(1201)と、「主メモリ」(1202)と、「HDD」(1203)と、「I/O」(1204)と、を備えている。
そして実施例1で記載したような処理を行い、ウェッブページの特定領域に支払対価に応じた表示頻度で広告を表示する。ただし、そのウェッブページはオークション関連ページであり、また、表示される広告はオークション出品物に係る広告である。
ここで、図示しないオークションサーバ装置(オークションシステム)は、まずネットワークを介して出品者であり広告主にもなるユーザの端末からのHTTPリクエストを受付けると、出品受付プログラムにしたがって出品受付用のWebページを返信する。そしてユーザ端末にて当該Webページを介して入力送信された出品のための情報(商品名や商品写真、商品紹介文章、オークション開始価格、出品者IDなどの情報)を受信する。また、当該出品受付用のWebページに、「広告表示希望」のチェックボックスや広告対価の入力欄などを設け、それら情報を出品と同時に受付けるよう構成しても良い。
そしてオークションサーバ装置では出品のための情報を受信すると、出品表示プログラムに従ったCPUの演算処理によって、当該オークション出品に対し、出品番号「001」などの識別情報を付与し、出品管理テーブルなどを生成して管理する。またそれに加えて、例えば所定のレイアウトで商品写真や商品紹介文章を配置し、入札金額の入力送信用フォーム(またこの入力送信フォームは現在入札額情報を保持し、現在入札額以下の入札を受付けないよう記述されていると良い)などを供える出品商品のオークション入札受付用のオークションWebページを生成する。そして、それを自身のHDD内に設けた所定のディレクトリに配置し、ネットワークを介してクライアント端末に公開することで、オークション出品物への入札を受付ける。
またそれに加えて、当該出品に関する広告表示希望を示す情報も受信した場合、オークションサーバ装置は、その旨を示す情報を出品番号(ID)「001」などと合わせて広告表示システムに出力する。すると、広告表示システムでは図11や図27に示すようなテーブルデータを生成し広告IDと当該出品IDとを関連付けて管理するとともに、広告の対価に応じた表示頻度の演算を実行する。なおこの表示頻度の演算は実施例1にて記載したものと同様の処理であるので説明は省略する。そして、その演算された表示頻度でオークション出品に係る広告がオークション関連ページにて表示されるよう、広告表示システムでは制御を実行する。
一方、オークションサーバ装置では、上記オークションWebページを介して入力送信された(入力フォームによって受付けた現在入札額よりも多い入札額での)入札金額を受信すると、CPUが入札受付プログラムにしたがって、受付けた入札金額を、例えばその入札時間や入札者IDと関連付けて主メモリなどに格納し、現在入札額として管理する。
つづいて落札決定プログラムにしたがって、管理されている現在入札額が落札条件(現在時刻が入札受付時刻を経過した、あるいは所定時間までに即決金額を最初に超えた、など)を満たしたか否かをCPUの論理演算処理によって判断する。そして、その落札条件を満たした入札額と関連付けて管理されている入札者IDを利用して、当該入札者を落札者として決定し、出品者/落札者双方に対する落札通知メールの配信などの予め定められた必要な処理を行う。また、入札受付時間までに入札が無かった場合などには、CPUは落札決定プログラムにしたがって「落札不成立」の旨を判断結果として出力し、その判断結果に応じて出品者に対する落札不成立の通知メール配信などの予め定められた必要な処理を行う。
そして、落札成立/不成立いずれの場合でも、オークションサーバ装置は落札決定プログラムに従い、そのオークション「001」の終了の決定結果を広告表示システムに対して出力する。
そして広告表示システムでは、上記のようにオークションサーバよりオークション出品物001のオークションが終了した旨の情報を「I/O」にて受信し、「主メモリ」のアドレス1に格納する。すると、本実施例の広告表示システムは、表示制御プログラムに従い、オークション終了情報で示される終了出品物のIDを取得する。そして、「HDD」に保持されているオークション広告管理DB(広告出品テーブル)にて管理されている図11や図26に示すようなテーブルデータを参照し、終了出品物に係る広告IDを取得し「主メモリ」のアドレス2に格納する。そして表示制御プログラムに従い、その広告IDをテーブルデータ上から削除する命令を生成し、削除処理を実行する。そして、詳細は実施例3で後述するように、例えば削除された商品と同一出品者が出品する別の商品の広告を補充広告として取得し、以降はその補充広告が所定の頻度(例えば終了商品から引き継いだ頻度など)で表示されるよう処理すると良い。
また、補充すべき広告が無い場合などには、上記IDが削除された広告の残り表示頻度を再分配する処理を以下のように実行しても良い。すなわちその広告IDで管理されている広告の残り表示頻度を、オークション広告管理DBから取得し、「主メモリ」の所定アドレスに格納する。つづいて、当該終了出品物が表示される特定領域を広告の表示領域とするその他の広告IDを、オークション広告管理DBにて特定し、その支払対価や表示頻度を取得する。そして実施例1で説明したような処理によって、その他の広告の対価比率を算出し、その対価比率を利用して、終了出品物に係る広告の残り表示頻度を割り振る処理を「CPU」の演算処理によって実行する。そしてその演算処理の結果、新たに算出されたその他の広告の表示頻度に応じて制御ルールを生成し、「主メモリ」の所定アドレスに格納する、という具合である。
<処理の流れ>
図13は、本実施例の広告表示システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。
ここで実施例1にて記載したような処理の流れによって決定した制御ルールに従い、広告をオークション関連ページの特定領域に表示するよう制御する(ステップS1301)。
その後、この図にあるように、広告に係るオークションの終了を検知する(ステップS1302)と、その検知結果に従って、広告IDをテーブルデータなどから削除したり、広告そのものをHDDなどから削除したりする(ステップS1303)。
また、上記処理の流れについて、オークションサーバ装置(オークションシステム)での処理も含めた形で、図28を用いてさらに詳細に説明する。この図にあるように、オークションサーバ装置にて、まず、オークションへの出品を受付ける(ステップS2801)と、その受付けた出品に係る出品IDを広告表示システムに出力する。またその受付けた出品を、例えばオークションWebページなどを生成しネットワーク上に公開して、ネットワーク上のクライアント端末に表示する(ステップS2802)。つづいて、そのネットワーク上のクライアント端末に表示したオークションWebページを介して入力されたオークション出品物に対する入札を受付け(ステップS2803)、その受付けた入札のうち所定の落札条件に合致する入札を落札と決定し(落札成立)、又は出品時間経過に基づいてオークションの終了を決定し(落札不成立)、その結果を決定結果として広告表示システムに出力する(ステップS2804)。
そして、広告表示システムでは、ステップS2802にてオークションサーバ装置から出力された出品IDを受信すると、当該出品IDで識別されるオークション出品物に係る広告の広告IDと、出品IDとを関連付けて広告出品テーブルを生成し、HDDなどに保持するため記録する(ステップS2805)。また、実施例1にて記載したような処理の流れによって決定した制御ルールに従い、広告をオークション関連ページの特定領域に表示するよう、オークションサーバ装置に対して制御命令を出力などする(ステップS2806)。
その後、広告表示システムでは、ステップS2804にてオークションサーバ装置から出力された決定結果を受信すると、当該広告の表示頻度に係る演算を再計算するため、その結果を演算装置などに出力し、表示頻度の再計算を実行する(ステップS2807)。またそれに伴い、広告IDをテーブルデータなどから削除したり、広告そのものをHDDなどから削除したりする(ステップS2808)。
また上記処理の流れでは、さらに図示しない以下のようなステップを有していても良い。すなわち広告表示システムにて広告出品テーブルを生成し保持するために記録するステップ(ステップS2805)の実行とともに、オークション出品物に係る当該広告の広告IDと、その広告を希望するユーザのユーザIDとを関連付けた広告ユーザIDテーブルを生成し、保持するためにHDDなどに記録するステップを有していても良い。
あるいは、オークションサーバ装置(オークションシステム)におけるステップS2804において、オークション主催者によるオークション出品の取消の決定、又は/および出品者によるオークション出品の削除の決定を決定結果として受付け、それを決定結果として広告表示システムに出力するステップをさらに有していても良い。そして、広告表示システムでは、このようなイレギュラーな出品中止においてもその広告表示を中止し、表示頻度を際演算するなどの処理を行う、という具合である。
また、広告表示予定のオークション出品と同種の商品がより安い入札価格で広告出品と同一ページに表示されてしまい、その広告効果がマイナスに作用しないよう、さらに図示しない以下の処理の流れを有していても良い。
すなわち、オークションシステムにて、任意の検索キーを受付け、受付けた検索キーに基づいてオークション出品物を検索し(検索ステップ)、検索結果を広告表示システムに出力する(検索結果出力ステップ)。また、検索ステップでの検索結果を、前記広告表示システムのオークションページ表示サブステップにより広告を表示するための前記特定領域とともに表示する(検索結果表示ステップ)。
また、一方で広告表示システムにて、オークションシステムから出力された検索結果を取得し(検索結果取得ステップ)、オークションページ表示サブステップにて、前記制御ルールに従って前記特定領域に表示する予定の広告IDを取得し、広告出品テーブルからその広告IDに関連付けられた出品IDを取得する(広告出品ID取得ステップ)。つづいて、前記出品IDで識別される広告予定の出品の現在価格を取得する(広告予定出品現在価格取得ステップ)。
そして、さらに前記出品IDで識別される出品に係る商品の商品種を識別するための商品IDを取得し(商品ID取得ステップ)、商品ID取得ステップにて取得した商品IDに基づいて、検索結果取得ステップにて取得した検索結果に含まれる出品IDを検索して同一商品種の出品IDを抽出し、抽出した出品IDで示される同一商品種の出品の現在価格を取得する(同一種出品現在価格取得ステップ)。そして、前記広告予定出品現在価格と、前記同一種出品現在価格と、いずれの価格が高いかを判断し(価格判断ステップ)、価格判断ステップでの判断結果が、広告予定の出品の価格の方が高いとの判断結果である場合には、オークションページ表示サブステップにて前記制御ルールに従って前記特定領域に表示する予定の広告を表示しないよう制御する(非表示制御ステップ)。
<効果の簡単な説明>
以上のように本実施例の広告表示システムによって、オークション出品物のオークションが終了となった場合には、例えば当該出品物に係る広告の表示を終了することができる。そしてその替わりに別の広告に差替えたりするなどの処理を行うことで、商品自体が無く表示する意味の無い広告を表示してしまう、などの無駄を省くことができる。
≪実施例3≫
<概要>
本実施例は、上記実施例を基本として、オークション終了によって終了出品物に係る広告表示も終了する場合に、替わりに表示すべき広告を新しく補充する機能を有することを特徴とする広告表示システムである。
図14は、本実施例の広告表示システムにおける広告表示の一例を表す概念図である。この図14(a)にあるように、ウェッブページ「オークションサイト」にて「トラックボールマウス」や「エクスプローラマウス」、「ワイヤレスマウス」などが出品されている。なお、実施例2で示す概要と同様に、オークション出品物「トラックボールマウス」β1は広告の対価を支払っているため、残り表示頻度を7000回とする広告α1が特定領域に表示されている。
その後このトラックボールマウスβ1のオークションが終了すると、本実施例の広告表示システムでは、オークション終了が無ければこの特定領域に表示されることの無い「予備の広告」であるオークション出品物β2に係る広告α2を新たに補充する。そして、図14(b)に示すように、その替わりの広告α2を同じ特定領域に所定の表示頻度(例えば前広告と同じ残り7000回の表示頻度など)で表示するよう制御する、という具合である。
<機能的構成>
図15は、本実施例の広告表示システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「広告表示システム」(1500)は、実施例2を基本として、「表示部」(1501)と、「広告蓄積部」(1502)と、「ユーザ入力情報受付部」(1503)と、「演算部」(1504)と、「制御部」(1505)と、「オークションページ表示手段」(1506)と、「限定蓄積手段」(1507)と、「終了依存削除手段」(1508)と、を有する。なお、上記構成要件は実施例1や実施例2にて記載済みであるので、その説明は省略する。
そして本実施例の広告表示システムの特徴点は、「補充広告蓄積部」(1509)と、「追加部」(1510)と、をさらに有する点である。
「補充広告蓄積部」(1509)は、オークションが終了することで広告を表示する必要がなくなった場合に、新たに広告蓄積部に蓄積し、特定領域に表示する為の広告である補充広告を蓄積する機能を有する。なお、この補充広告蓄積部は、例えばオークション終了が無ければ広告表示されない広告を補充広告として蓄積する構成であっても良い。あるいは別の特定領域や別の日に表示されるよう前記広告蓄積部にて蓄積されている広告に関して、別途補充広告としても管理する管理データベースを具備することで補充広告蓄積部を構成しても良い。
また、この補充広告蓄積部では、例えば補充広告に関して代替優先順位を示す情報と関連付けて蓄積する構成であっても良い。
「追加部」(1510)は、オークションが終了することで前記終了依存削除手段にて広告の削除が行われた場合に、補充広告蓄積部(1509)に蓄積されている広告を広告蓄積部(1502)に追加する機能を有する。
この追加部の機能は、例えばデータベースなどで補充広告フラグを立てて補充広告として管理している広告に関し、当該補充広告フラグを広告フラグに書き換える処理などで実現することができる。
あるいは、例えば補充広告蓄積部がネットワークなどを介した外部の別装置上に具備されている場合は、当該外部の別装置に所定の補充広告を送信する命令を出力する。そしてその命令にしたがって送信されてきた補充広告を広告蓄積部に追加書き込みする処理などによって実現することもできる。
またこの追加部にて、複数の補充広告の中から広告として追加するものを選択するために例えば以下のような処理を行うと良い。
図16は、上記選択処理に関する優先順位を指定するためのGUIの一例を表す図である。この図にあるように、例えばユーザ(広告クライアント)がこの追加機能(自動補充モード)について「OFF」とした場合には、まずオークション終了出品物の出品者IDや登録情報などを利用して、その出品者に対して終了通知メールを自動送信する。そして当該メールに応じてユーザが自身の出品リストの中から指定した出品物に関する情報を受信する。そして本実施例の広告システムでは、そのように指定された出品物に係る補充広告を上記追加される広告として選択決定する、という具合である。
また、その他にも、入札件数の最も高い出品物にかかる広告を追加の広告として選択しても良いし、現在価格の最も高いものや残り時間の最も長いもの/短いものに係る広告を追加の広告として選択しても良い。また、その際にはオークション広告管理データベースにて管理されている情報を参照し、終了出品物と同一の出品者IDと関連付けられた広告についてその選択対象とすることで、支払対価の返還や再請求などの処理を省くことができる。
そして、上記処理によって複数の補充広告の中から選択され追加された広告の表示頻度に関して、例えば前広告(オークション終了出品物に係る広告)と追加広告とが同一出品者によるものであれば、支払対価の負担者が同一なので残り表示頻度をそのまま引き継ぐよう処理すると良い。
なお、上記のような広告の表示終了に伴う補充すべき別の広告の選択処理に際し、ユーザIDを利用し同一出品者に係る別の広告を補充対象とするために、本実施例の広告表示システムは図29に示すような以下のような構成を備えていると良い。
図29は、上記機能を実現するための本実施例の広告表示システムにおける機能ブロックの、別の一例を表す図である。この図にあるように本実施例の広告表示システムは、上記構成に加えて、さらに「ユーザID取得部」(2911)と、「補充広告抽出部」(2912)と、「追加候補出力部」(2913)と、を有する。
「ユーザID取得部」(2911)は、終了依存削除手段にて削除された広告の広告IDに基づいて、その広告を希望したユーザのユーザIDを取得する機能を有する。具体的には、例えば図27に示すような広告ユーザIDテーブルを参照し、CPUの論理演算処理によって広告IDと関連付けられているユーザIDを特定する、という具合である。
「補充広告抽出部」(2912)は、ユーザID取得部にて取得したユーザIDと関連付けられている広告IDを補充広告蓄積部から抽出する機能を有する。具体的には上記同様に、例えば図27で示す広告ユーザIDテーブルを参照し、CPUの論理演算処理によって取得したユーザIDに関連付けられている、その他(終了によって削除された広告以外)の広告IDを抽出する。また、その抽出した広告IDが複数ある場合には、例えばユーザが指定した代替優先順位の最も高い出品物に係る広告や、入札件数の最も高い出品物にかかる広告や、現在価格の最も高いものや残り時間の最も長い出品物に係る広告など、その中から一つの広告を特定する処理をCPUの演算処理によって行っても良い。
「追加候補出力部」(2913)は、前記抽出された広告の広告IDを追加候補として追加部に出力する機能を有する。このようにして、広告の表示終了に伴って、ユーザIDを利用し同一出品者に係る別の広告を補充対象として処理することができる。
また上記のように追加補充された広告を含む表示されるべき全ての広告の表示頻度に関しては、その他にも、残りの予想アクセス数などを用いて当該特定領域に関する全ての広告について再演算することで算出するなど様々であって良い。
このように、オークションが終了することで広告を表示する必要がなくなった場合に新たに広告を補充し、特定領域に広告を表示することができる。
<ハードウェア構成>
図17は、上記機能的な各構成要件をハードウェアとして実現した際の、広告表示システムにおける構成の一例を表す概略図である。この図を利用してオークション出品物に係る広告の表示処理におけるそれぞれのハードウェア構成部の働きについて説明する。
この図にあるように、広告表示システムは、実施例2同様に「CPU」(1701)と、「主メモリ」(1702)と、「HDD」(1703)と、「I/O」(1704)と、を備えている。
そして実施例1で記載したような処理を行い、オークション関連ページの特定領域に支払対価に応じた表示頻度で広告を表示する。そしてオークションサーバよりオークション出品物001のオークションが終了した旨の情報を「I/O」にて受信し、「主メモリ」のアドレス1に格納する。またそれに伴い、前述のようにオークション終了商品に係る広告IDの削除処理を実行する。
すると本実施例の広告表示システムは、表示制御プログラムに従い、オークション終了情報で示される終了出品物のIDを取得する。そして、「HDD」に保持されているオークション広告管理DBを参照し、終了出品物に係る出品者IDを取得する。そして、その出品者IDをキーとしてオークション広告管理DBテーブルデータにて管理されているテーブルデータを検索し、同一出品者IDで出品され、かつ補充広告フラグを立てて管理されている補充広告A、補充広告B、・・・を特定する。
続いて上記特定した補充広告の中から広告として追加するものを選択する。そのために図16のGUIなどを介して指定された選択方法情報に従い、例えば特定した補充広告に係る出品物の入札件数などを返信するようオークションサーバに命令を出力する。そして、その命令に応じて返信された入札件数情報を「I/O」にて受信し、「主メモリ」のアドレス2に格納する。そして、入札件数情報で示される各出品物の入札件数を「CPU」の演算処理によって大小比較し、例えば補充広告Aに係る出品物が最も入札件数が多い、との比較結果が出力される。
つづいて、その比較結果に応じて「CPU」は補充広告Aのフラグ書換命令を生成し「主メモリ」のアドレス4に格納する。そして当該書換命令に従い、オークション広告管理DBで管理されている補充広告Aの設定フラグを、補充広告から広告へと書き換える処理が実行され、新たなオークション広告Cが広告として追加管理される、という具合である。
また、そのように新たな広告として追加されたオークション広告Cの表示頻度については、前広告の残り表示頻度をそのまま引き継ぐ処理により決定すると良い。
<処理の流れ>
図18は、本実施例の広告表示システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。
ここで実施例1にて記載したような処理の流れによって決定した制御ルールに従い、広告をオークション関連ページの特定領域に表示するよう制御する(ステップS1801)。
その後、この図にあるように、広告に係るオークションの終了を検知する(ステップS1802)と、予め補充広告蓄積部に蓄積されている補充広告を広告蓄積部に追加する(ステップS1803)。
また上記処理の流れにおいて、ステップS1803にてユーザIDをキーとして広告蓄積部に追加すべき補充広告の選択処理を行うための処理について、図30を用いてさらに詳細に説明する。この図にあるように、広告表示の終了に伴い削除された広告の広告IDを取得し、その広告IDに基づいてその広告を希望したユーザのユーザIDを取得する(ステップS3001)。つづいてその取得したユーザIDと関連付けられている広告IDを広告蓄積部から抽出し(ステップS3002)、前記抽出された広告の広告IDを追加候補として追加ステップに出力する(ステップS3003)。
<効果の簡単な説明>
以上のように本実施例の広告表示システムによって、オークションが終了することで広告を表示する必要がなくなった場合に新たに広告を補充し、特定領域に追加した新しい広告を表示することができる。したがって広告スペースを有効に使い回して活用することができる。
また、前述のようにオークション出品物に係る広告に特有の、例えば広告の表示頻度が残っている状態での出品終了、即ち広告表示終了などが発生しても、別途表示すべき広告を補充することができる。また、その際に、表示終了広告の出品ユーザが出品している別の出品物の広告を補充広告とするよう構成することで、例えば支払対価の負担者が同一なので残り表示頻度をそのまま引き継ぐなど、表示頻度の際演算処理を簡略化することもできる。
≪実施例4≫
<概要>
本実施例は、上記実施例1から3のいずれかを基本として、さらにユーザ入力情報の受付を常時行うとともに、所定のインターバルで表示頻度の演算および制御ルールの生成を実行することを特徴とする広告表示システムである。
このように、本実施例の広告表示システムでは設定された所定のインターバルに応じて広告表示制御が変更される、という具合に柔軟な表示制御を行うことができる。
<機能的構成>
図19は、本実施例の広告表示システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「広告表示システム」(1900)は、例えば実施例1を基本として、「表示部」(1901)と、「広告蓄積部」(1902)と、「ユーザ入力情報受付部」(1903)と、「演算部」(1904)と、「制御部」(1905)と、を有する。また、実施例2や3を基本として、図示しない「オークションページ表示手段」や「限定蓄積手段」や「終了依存削除手段」、あるいは「補充広告蓄積部」や「追加部」などを有していても良い。なお、上記構成要件は実施例1や2、3にて記載済みであるので、その説明は省略する。
そして本実施例の広告表示システムの特徴点は、ユーザ入力情報受付部が「常時受付手段」(1906)をさらに有し、演算部が「インターバル演算手段」(1907)をさらに有し、そして制御部が「制御ルール生成手段」(1908)をさらに有する点である。
「常時受付手段」(1906)は、常時ユーザ入力情報の受付を行う機能を有する。この常時受付手段では、例えばユーザ入力情報を受付けた時間を取得し、ユーザ入力情報と受付時間を関連付けて管理できるよう構成しても良い。
「インターバル演算手段」(1907)は、所定のインターバルで前記演算を行う機能を有する。また、「制御ルール生成手段」(1908)は、インターバル演算手段(1907)で新たに演算が行われるたびに演算された表示頻度に基づいて表示をさせるための制御ルールを生成する機能を有する。
ここで、「所定のインターバル」は、1日や12時間、あるいは1週間といった具合に予め定められていても良いし、ユーザ(広告クライアント)からのインターバル希望情報を受付けるなどして、ユーザの希望を反映させるように定められても良い。また、予め設けられた所定日付の1日前に広告入稿の受付けを終了するよう構成し、所定のインターバルでの演算を実現しても良い。
また所定のインターバルは、常時受付手段での受付状況に応じて決定されるよう構成しても良い。例えば、一の特定領域に関するユーザ入力情報の受付件数が一時間で100以上など集中している場合、その集中度合いを閾値などを基準に「CPU」の論理演算処理によって判断する。そして集中している旨判断された場合には、所定のインターバルを延長し、より多くのユーザ入力情報が受付けられ、それら全てを反映されるようにする、という具合である。
具体的に、インターバル演算手段が、常時受付手段で受付けたユーザ入力情報の受付け状況が所定の集中度合いに達したかの判断をし、その結果、集中度合いが所定の閾値超えるごとにこれをインターバルとして前記演算を行う閾値演算手段をさらに有すると良い。
あるいは、所定のインターバルは、時間経過によるインターバルの他、広告に対する支払口数(支払対価)を基準としたインターバルであっても良い。例えば、1万口を基準とし、ユーザ入力情報の受付によって対価支払が1万口に達した際に、表示頻度や制御ルールの生成処理が開始される。そしてそこから再度支払対価のカウントを行い、また1万口に達したら次の表示頻度や制御ルールの生成処理が開始される、という具合である。
具体的に、インターバル演算手段が、オークションにおいて広告に係る出品物のオークションが終了したかの検知結果を取得して、出品物のオークションが終了したとの検知結果を取得する毎にこれをインターバルとして前記演算を行う検知結果依存演算手段をさらに有すると良い。
またその他にも、オークションシステムから広告表示に係るオークション出品が終了したことを示す検知結果の受信に基づくインターバルであっても良い。具体的に、インターバル演算手段が、オークションにおいて広告に係る出品物のオークションが終了したかの検知結果を取得して、出品物のオークションが終了したとの検知結果を取得する毎にこれをインターバルとして前記演算を行う検知結果依存演算手段をさらに有すると良い。
あるいは、実施例3にて記載のオークション出品終了に伴う広告終了に対し、別の広告を補充する構成を備える広告表示システムにおいて、あるユーザ(広告主)が表示を希望するすべての広告が終了したことの通知に基づくインターバルであっても良い。具体的に、前記補充広告蓄積部が、補充広告を、その補充広告の表示を希望するユーザのユーザIDに関連付けて蓄積するとともに、任意のユーザIDに関連付けられている補充広告が空になったか判断する補充広告空判断手段をさらに有し、前記インターバル演算手段が、補充広告空判断手段での判断結果が空になったとの判断結果である場合ごとにこれをインターバルとして前記演算を行う補充広告依存演算手段をさらに有すると良い。
<ハードウェア構成>
本実施例のハードウェア構成、およびその処理の内容などは、上記実施例にて記載したものとほぼ同様であるのでその説明は省略する。相違点は、そのハードウェア構成を用いた各処理の処理開始トリガーとして、タイムスケジューラなどのアプリケーションと「内蔵時計」などを利用する点である。
<処理の流れ>
図20は、本実施例の広告表示システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。
この図にあるように、まず、広告表示の対価を示す情報を含むユーザ入力情報を、所定のインターバルが経過するまで受付ける(ステップS2001)。そして所定のインターバルが経過したことを内蔵時計などで検知する(ステップS2002)と、受付けたユーザ入力情報から得られる全体の対価を算出する(ステップS2003)。また、続く対価の割合や表示頻度の算出、制御ルールの生成処理を上記実施例にて説明したような処理の流れによって実行する。
そして、決定した表示ルールに従い広告をウェッブページの特定領域に表示するよう制御する(ステップS2004)。
また、上記のように時間をベースとするインターバルの他、以下のようなインターバルで表示頻度の算出や制御ルールの生成を実行するよう構成しても良い。すなわち、ユーザ入力情報を常時受付け(常時受付けサブステップ)、常時受付サブステップで受付けたユーザ入力情報の受付け状況が所定の集中度合いに達したかの判断をし、その結果、集中度合いが所定の閾値超えるごとにこれをインターバルとして前記演算を行う(閾値演算サブステップ)という具合である。
あるいは、ユーザ入力情報を受付け(ユーザ入力情報受付ステップ)、ユーザ入力情報受付ステップに受付けられたユーザ入力情報に含まれる広告表示の対価が所定の基準支払対価に達したかの判断をし、その結果、基準支払対価に達する場合ごとにこれをインターバルとして前記演算を行う(基準対価依存演算サブステップ)という具合である。
あるいは、オークションにおいて広告に係る出品物のオークションが終了したかの検知結果を取得して、出品物のオークションが終了したとの検知結果を取得する毎にこれをインターバルとして前記演算を行う(検知結果依存演算サブステップ)構成をさらに有していても良い。
あるいは、補充広告蓄積部は補充広告を、その補充広告の表示を希望するユーザのユーザIDに関連付けて蓄積することを前提として、任意のユーザIDに関連付けられている補充広告が空になったか判断し(補充広告空判断ステップ)、補充広告空判断ステップでの判断結果が空になったとの判断結果である場合ごとにこれをインターバルとして前記演算を行う(補充広告依存演算サブステップ)構成をさらに有していても良い。
<効果の簡単な説明>
以上のように本実施例の広告表示システムによって、設定された所定のインターバルに応じて柔軟な表示制御を行うことができる。
≪実施例5≫
<概要>
本実施例は、ユーザ(広告クライアント)により入力された「支払対価」による表示頻度予想をユーザに通知する機能をさらに備える広告表示システムである。
図21は、本実施例による表示頻度予想のユーザ通知画面の一例を表す図である。この図にあるように、本実施例の広告表示システムでは、GUI上の「見込算出ボタン」の押下によるユーザからのリクエスト受付に応じて、現時点での表示頻度を計算し、「見込表示回数」の項目にその計算結果を予想として表示する、という具合である。
つまり本発明の広告表示システムの最大の特徴は、広告の支払対価総額に対する各広告の支払対価の割合で表示頻度を変えて広告を表示する点にある。しかし、広告の支払対価総額は、時間経過によって変わるなどするため、その表示頻度も当初の対価支払時から変動してしまう。
そこで本実施例では、ユーザの要求(リクエスト)に応じてその要求時点での表示頻度をユーザに通知することで、変動した表示頻度に応じて例えば支払対価を追加するなどの対応をとることができるようになる。
<機能的構成>
図22は、本実施例の広告表示システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「広告表示システム」(2200)は、実施例1を基本として、「表示部」(2201)と、「広告蓄積部」(2202)と、「ユーザ入力情報受付部」(2203)と、「演算部」(2204)と、「制御部」(2205)と、を有する。また、実施例2や3、4を基本として、図示しない「オークションページ表示手段」や「限定蓄積手段」や「終了依存削除手段」、あるいは「補充広告蓄積部」や「追加部」、また「常時受付手段」や「インターバル演算手段」や「制御ルール生成手段」などを有していても良い。なお、上記構成要件は実施例1から4にて記載済みであるので、その説明は省略する。
そして本実施例の広告表示システムの特徴点は、「表示頻度情報出力部」(2206)をさらに有する点である。
「表示頻度情報出力部」(2206)は、ユーザの要求に応じて対価と要求時の演算結果として得られる表示頻度との関係を示す表示頻度情報を出力する機能を有する。なお、この「ユーザの要求」の取得は、最初の支払対価の入力時、すなわちユーザ入力情報の受付時にユーザ入力情報に含む形で取得しても良いし、その後に別途ユーザ要求のみを所定のサービス用ウェッブページのGUIなどを介して取得するよう構成しても良い。また、ユーザが自身の出稿広告を管理するための「管理ページ」にアクセスしたことをユーザの要求として処理し、当該管理ページの画面上に、他の管理情報と併せて表示頻度情報を出力表示するよう構成しても良い。
そして、そのユーザ要求を受付けた時点でのユーザ全体の支払対価総額に応じて、現時点での表示頻度をユーザに通知する、という具合である。なお、その通知方法は上記ユーザ要求受付用のGUI上に表示して通知するようにしても良いし、ユーザの指定メール先へのメール送信など、その他手段で通知するようにしても良い。
<ハードウェア構成>
図23は、上記機能的な各構成要件をハードウェアとして実現した際の、広告表示システムにおける構成の一例を表す概略図である。この図を利用してユーザへの表示頻度の通知処理におけるそれぞれのハードウェア構成部の働きについて説明する。
この図にあるように、広告表示システムは、上記実施例同様に「CPU」(2301)と、「主メモリ」(2302)と、「HDD」(2303)と、「I/O」(2304)と、を備えている。
ここで、図21のようなGUIを利用しユーザ(広告クライアント)が自身の端末から送信されたユーザの要求(特定領域の識別情報を含む)を「I/O」にて受信し、「主メモリ」のアドレス1に格納する。すると特定領域の識別情報を利用して、現時点で当該特定領域について支払われた対価を、「HDD」の広告管理DBから取得する。そして、「CPU」の演算処理によって現時点の対価総額を算出し、「主メモリ」のアドレス2に格納する。そして、その算出した全体のユーザの対価総額に対する各ユーザの対価の割合から現時点での表示頻度を算出し「主メモリ」のアドレス3に格納する。
そして算出した表示頻度を表示頻度情報として「I/O」から出力し、ユーザ要求を送信した端末に返信する、という具合である。そしてユーザはその現時点での表示頻度(予想)を知ることで例えば、変動した表示頻度に応じて支払対価を追加するなどの対応をとることができる。
<処理の流れ>
図24は、本実施例の広告表示システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。
この図にあるように、まず、実施例1で記載したような処理を実行し全体のユーザの対価に対する各ユーザの対価の割合を算出する。つづいて、算出した対価の割合に応じて各ユーザが表示を希望する広告の表示頻度を算出し(ステップS2401)、算出した表示頻度に基づいて制御ルールを定める(ステップS2402)。
その後、ユーザから要求を取得する(ステップS2403)と、その要求を取得した時点での表示頻度を再計算する(ステップS2404)。そして再計算した表示頻度を表示頻度情報として出力し(ステップS2405)、ユーザに現時点での表示頻度を通知する。
<効果の簡単な説明>
以上のように本実施例の広告表示システムによって、ユーザの要求(リクエスト)に応じてその要求時点での表示頻度をユーザに通知することができる。したがってユーザは、変動した表示頻度に応じて例えば支払対価を追加するなどの対応をとることができるようになる。