JP4887214B2 - 広告管理システム、広告管理サーバ、およびそれらの制御方法 - Google Patents

Description

本発明は、商品などの広告をウエッブ上に効率的に表示するための技術に関する。

近年、いわゆるウエッブ広告の普及が進んでいる。広告代理店である電通（登録商標）の調査では、２００６年度のウエッブ広告費は２年前と比較して倍増したことが報告されており、近い将来には雑誌広告費を抜く可能性が高い、との予測がなされている。

そして、このようなウエッブ広告の広告効果などを向上させるために現在様々な技術、例えば検索サイトと連動してユーザーが入力した検索キーワードに関連する広告を検索結果画面に表示するウエッブ広告技術などが提供されている。

また、特許文献１には、ＰＯＳ（ポイント・オブ・セール）端末から送信される在庫数などをウエッブ広告上に随時反映表示させる技術などが開示されている。
特開２００２−１５００４７号公報

ところで、広告は商品を売るための手段のひとつである。そのため、商品そのものが無ければ広告を出す意味はあまり無い。例えば、特許文献１の技術において「在庫０」の商品の広告がウエッブのトップページに大々的に表示されていても、その商品をより多く売るための手助けにはあまりならない。

つまり、従来の技術においては、例えば商品在庫が少なくなった／無くなったなど広告を積極的に行うには不適当な状況においても通常どおり広告が表示されている、といった課題がある。

あるいは逆に在庫が多く、たくさん商品を売りたい状況において、表示頻度が少なかったり、あるいは表示サイズが小さかったり広告の表示領域が視認性の低い位置にあったりするなどして、非積極的な表示となってしまっている、という課題もある。

以上の課題を解決するために、本発明は、商品管理用のＰＯＳシステムから送信される商品の在庫状況、受発注情報などを示す受発注在庫情報を利用して、ウエッブ広告の出現頻度や表示位置などを適宜調整する機能を備える広告管理システムを提供する。

具体的には、ＰＯＳシステムと、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバと、前記商品などの広告をウエッブ上で公開するための広告ＤＢ（データベース）と、からなる広告管理システムである。

そして、そのＰＯＳシステムが、商品の受発注在庫情報を商品別に広告管理サーバに対して送信する受発注在庫情報送信部を有していることを特徴とする。

また、その広告管理サーバが、受発注在庫情報を受信する受発注在庫情報受信部と、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の頻度を少なくするか（命令Ａ）、訴求度が比較的小さい広告とするか（命令Ｂ）、又はその商品の広告を停止するか（命令Ｃ）の少なくともいずれか一以上の命令と関連付け、受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の頻度を多くするか（命令Ｄ）、訴求度が比較的大きい広告とするか（命令Ｅ）、又はそれまでにその商品の広告がされていない場合にはその商品の広告を開始するか（命令Ｆ）の少なくともいずれか一以上の命令と関連付けた広告管理テーブルを保持する広告管理テーブル保持部と、受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する命令取得部と、取得した前記命令を広告ＤＢに送信する命令送信部と、を有することを特徴とする。

また、その広告ＤＢが、広告管理サーバから前記命令を受信する命令受信部と、広告を蓄積する広告蓄積部と、受信した前記命令が命令Ａである場合には、他の広告に比較して前記命令に係る商品の広告頻度を下げるスケジュールを計算するＡ計算部と、受信した前記命令が命令Ｂであり、訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的低い広告に前記命令に係る商品の広告を入れ替えるスケジュールを計算するＢ計算部と、受信した前記命令が命令Ｃである場合には、前記命令に係る商品の広告を停止するスケジュールを計算するＣ計算部と、受信した前記命令が命令Ｄである場合には、他の広告に比較して前記命令に係る商品の広告の頻度を多くするスケジュールを計算するＤ計算部と、受信した前記命令が命令Ｅであり、訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的大きい広告に前記命令に係る商品の広告を入れ替えるスケジュールを計算するＥ計算部と、受信した前記命令が命令Ｆである場合には、前記命令に係る商品の広告を開始するスケジュールを計算するＦ計算部と、を有することを特徴とする。

また、第２の広告管理システムとして、商品を共同購入することで割引などの特典を受けられるいわゆる「共同購入キャンペーン広告」に関して、上記と同様の構成によってウエッブ上での出現頻度や表示位置などを適宜調整する機能を備える広告管理システムも提供する。

また、第３の広告管理システムとして、広告ＤＢが、さらに受信した命令に応じて広告を掲載するウエッブページを選択する選択部を有する広告管理システムも提供する。

また、これら広告管理システムの計算機による制御方法も提供する。

以上のような構成をとる本発明によって、商品在庫状況や商品受発注状況に応じてウエッブ広告の出現頻度や表示位置などを適宜調整することができる。したがって、例えば、商品在庫が少なくなった／無くなったなど広告を積極的に行うには不適当な状況であれば、広告表示を停止したり、ラストページ下部へのバナー／テキスト広告での表示をしたりすることができる。

また、逆に在庫が多い商品の広告については、例えばその表示頻度を上げたり、トップページの上部にリッチコンテンツで表示したりすることで、より商品が売れるよう積極的に広告を出すことなどもできる。

以下に、図を用いて本発明の実施の形態を説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。

なお、実施例１は、主に請求項１、２、５、６について説明する。

また、実施例２は、主に請求項３、７について説明する。

また、実施例３は、主に請求項４について説明する。

≪実施例１≫

<概要>

まず、図１および図２を用いて、広告商品の在庫が多い場合と少ない場合での本実施例の広告管理システムにおけるウエッブ広告の表示例を概念的に説明する。

図１は、広告商品の在庫が多い場合での本実施例の広告管理システムにおけるウエッブ広告の一例を表す概念図である。この図にあるように、商品（メモリーカード）を販売している店舗において、ＰＯＳシステムで実際の商品の受発注や販売に応じた商品情報を管理している。

ここで、この「ＰＯＳシステム」から、ウエッブ上での広告表示を管理している図示しない「広告管理サーバ」に対して商品の在庫情報「在庫多し」が送信される。

すると、広告管理サーバでは、この商品がもっと売れるように、そのウエッブ広告を広告表示ページの目立つ領域αに表示するための命令を生成／取得する。また、さらに表示するウエッブ広告として動画などを含む訴求性の高いリッチコンテンツの広告を表示するための命令を生成／取得する。

そして、それら命令に応じた「広告ＤＢ（データベース）」（図示せず）の制御によって、広告表示ページではこの商品の広告がユーザーの目に付きやすい領域αに、動画ＣＭとして表示される、と言う具合である。

このように商品在庫が多いなどの場合には、本実施例の広告管理システムではユーザーの購入意欲を刺激するようにその商品の広告を表示することができる。したがって、商品在庫の減少に寄与する効果が期待できる。

図２は、広告商品の在庫が少ない場合での本実施例の広告管理システムにおけるウエッブ広告の一例を表す概念図である。ここで、例えば図１のようなウエッブ広告の表示を行ったことでメモリーカードの販売数が伸び、商品在庫が少なくってしまった。

そこで、今度は、「ＰＯＳシステム」から図示しない「広告管理サーバ」に対して商品の在庫情報「在庫少なし」が送信される。

すると、広告管理サーバでは、そのウエッブ広告の表示位置を、目立つ領域αから表示ページ下部のあまり目立たない領域βに変更するための命令を生成／取得する。また、さらに表示するウエッブ広告を、訴求性の高い動画広告からテキストベースのバナー広告に差し替えるための命令を生成／取得する。

そして、それら命令に応じた「広告ＤＢ」（図示せず）による制御によって、図に示すようにこの商品の広告がユーザーの目が真っ先には行かないような領域βに、テキストベースのバナー広告として表示される。そして、表示領域αには、在庫が多い別の商品（ＣＰＵ）の動画広告などが表示される、と言う具合である。

このように商品在庫が少ないなどの場合には、本実施例の広告管理システムではその商品の広告を目立たないような形態で表示することができる。したがって、商品が無い状態でユーザーの購入意欲を無駄に刺激する、といった事態の発生を防ぐことができる。

また、その商品の広告を目立たなくすることで、相対的に別の（在庫の多い）広告の広告効果を向上するようにすることもできる。

≪機能的構成≫

以下、適宜図を用いて本実施例の広告管理システムを構成する「ＰＯＳシステム」、「広告管理サーバ」、および「広告ＤＢ（データベース）」のそれぞれの構成要件について説明する。まず、ＰＯＳシステムについて説明する。

（ＰＯＳシステム）

図３は、本実施例の広告管理システムにおける、特にＰＯＳシステムの機能ブロックの一例を表す図である。この図にあるように、本実施例の広告管理システムは、「ＰＯＳシステム」（０３００）と、「広告管理サーバ」（０３１０）と、「広告ＤＢ」（０３２０）と、からなる。

なお「ＰＯＳシステム」とは、商品別に仕入れや販売、それにともなう在庫などの情報を管理するための計算機システムをいい、例えばＰＯＳ機能付レジスターやＰＯＳ端末などの情報入力端末と、端末で入力された情報を蓄積、管理するサーバ装置とで構成することができる。

そして、この「ＰＯＳシステム」（０３００）は、「受発注在庫情報送信部」（０３０１）を有する。

なお、以下に記載する本発明の広告管理システムを構成するＰＯＳシステム、広告管理サーバ、広告ＤＢの機能ブロックは、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方として実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵや主メモリ、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどの記憶メディアとそれらメディアの読取ドライブなど）、印刷機器や表示装置、その他の外部周辺装置などのハードウェア構成部やその外部周辺機器用のＩ／Ｏポート、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラム、情報入力に利用されるユーザーインターフェースなどが挙げられる。

またこれらハードウェアやソフトウェアは、主メモリ上に展開したプログラムをＣＰＵで演算処理したり、メモリやハードディスク上に保持されているデータや、インターフェースを介して入力されたデータなどを加工、蓄積、出力処理したり、あるいは各ハードウェア構成部の制御を行ったりするために利用される。また、この発明は装置として実現できるのみでなく、方法としても実現可能である。また、このような発明の一部をソフトウェアとして構成することができる。さらに、そのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品、及び同製品を記録媒体に固定した記録媒体も、当然にこの発明の技術的な範囲に含まれる（本明細書の全体を通じて同様である）。

「受発注在庫情報送信部」（０３０１）は、商品の受発注在庫情報を商品別に広告管理サーバに対して送信する機能を有する。この受発注在庫情報送信部は、例えば、インターネットなどのネットワーク回線と接続するための接続ポートやその通信制御回路などで実現することができる。

そして、「受発注在庫情報」とは、商品の受注、発注、在庫のいずれか1以上に関する情報をいう。発注に関する情報としては、例えば商品の発注数や発注予定数、発注価格のほか、発注相手、納入予定日時、発注担当者などの情報が挙げられる。また、受注に関する情報としては、受注数や受注価格のほか、受注者（顧客）情報、受注日時、受注担当者、発送予定時間、発送担当者、受注キャンセル情報などが挙げられる。また、在庫に関する情報としては、受入数と発送数の差で示される在庫数情報や保持期間、廃棄予定日時などの情報が挙げられる。

また、上記のような受発注在庫情報は、例えばＰＯＳシステムの棚卸用ＰＯＳ端末やＰＯＳレジ端末、あるいは注文受付端末や、それら端末からの情報を管理する受注マスタ、発注マスタ、在庫マスタなどの各種データベースから取得された情報を組み合わせるなどして生成、取得されると良い。

そして、例えばバーコードなどで示される商品ＩＤ（識別情報）と関連付けて、これら受発注在庫情報を管理し、後述する「広告管理サーバ」に対して送信する、と言う具合である。なお、その送信のトリガーは、例えばＧＵＩなどを利用してＰＯＳシステムの操作者からの送信命令入力や、予め設定された所定の周期タイミングの到来などさまざまであって良い。

図４は、送信される受発注在庫情報のデータ内容の一例を表す概略図である。この図にあるように、受発注在庫情報として、店舗を識別するための店舗ＩＤ、住所やＷｅｂショップであればＷｅｂアドレス、また送信時間などの情報が含まれていると良い。

そして商品に関する情報として、例えば「商品ＩＤ：SD_Memory_WS_00B」や「商品名：メモリーカードWS00B」、「価格：1000円」、「受注数：42個」、「受注済未発送数：30個」、「在庫数：158個」、「（明日）入荷予定数：200個」などの情報が示される、という具合である。

そして、このように受発注在庫情報で示される商品ごとの例えば受注数や在庫数等の情報を利用して、次の「広告管理サーバ」では、以下に説明するような構成によって、商品ＩＤなどで示される商品の広告の表示方法などに関する各種制御を実行することになる。

（広告管理サーバ）

次に、本実施例の広告管理システムを構成する「広告管理サーバ」について説明する。

図５は、本実施例の広告管理システムにおける、特に広告管理サーバの機能ブロックの一例を表す図である。この図にあるように、本実施例の広告管理システムは、前述のように「ＰＯＳシステム」（０５００）と、「広告管理サーバ」（０５１０）と、「広告ＤＢ」（０５２０）と、からなる。

なお、「広告管理サーバ」とは、ＰＯＳシステムで管理されている商品などの広告を管理するためのサーバをいう。また、「広告の管理」とは、例えば、広告の掲載期間に関する管理や、広告の掲載位置や掲載タイミングに関する管理などが挙げられる。

そして、「広告管理サーバ」（０５１０）は、「受発注在庫情報受信部」（０５１１）と、「広告管理テーブル保持部」（０５１２）と、「命令取得部」（０５１３）と、「命令送信部」（０５１４）と、を有する。

「受発注在庫情報受信部」（０５１１）は、受発注在庫情報を受信する機能を有する。この受発注在庫情報受信部は、例えば、インターネットなどのネットワーク回線と接続するための接続ポートやその通信制御回路などで実現することができる。

そして、ここで受信した受発注在庫情報を利用して、まず、その受発注在庫情報に含まれる商品ＩＤを利用して広告の表示制御を行うべき商品を特定する。そして特定された商品の広告に対してその表示方法などを制御するための命令が、以下の構成によって選択されることになる。

「広告管理テーブル保持部」（０５１２）は、広告管理テーブルを保持する機能を有し、例えば、ＨＤＤ（ハードディスクドライブ）や不揮発性メモリ、光学記録メディアなどの二次記憶媒体によって実現することができる。

なお、「広告管理テーブル」とは、受発注在庫情報と閾値とを比較した「結果」と、「命令ＡからＣ」の少なくともいずれか一以上、又は「命令ＤからＦ」の少なくともいずれか一以上と、を関連付けたテーブルである。また「閾値」とは、販売できる商品が少ない又は十分調達できない状況を示す閾値（命令ＡからＣに関する閾値）、または、販売できる商品が十分ある又は十分調達できる状況を示す閾値（命令ＤからＦに関する閾値）である。

したがって、この管理テーブルによって、受発注在庫情報で示される受発注数や在庫数が販売可能な数（閾値）以上に確保されているか、などその関係に応じて広告の表示方法を制御するための命令ＡからＦを選択することができる、という具合である。

図６は、広告管理テーブルで示されるこの比較結果と命令との関連付けの一例を説明するための概念図である。この図にあるように、まずＰＯＳシステムから受信した受発注在庫情報によって、ある商品の現在の在庫数は「Ｘ」であることが示される。そして、広告管理サーバ内の二次記憶媒体からその商品の閾値「Ａ１」又は「Ａ２」が取得され、「Ｘ」と「Ａ１（Ａ２）」の値の大小比較がＣＰＵなどの演算装置の演算処理によって実行される。

なお、閾値Ａ１は、販売できる商品が少ない状況を示す閾値であって、したがってこの閾値Ａ１を、商品の十分な在庫が無いことを判断する基準とすることができる。また、閾値Ａ２は、販売できる商品が十分あるなどの状況を示す閾値であって、したがって、この閾値Ａ２を、商品の十分な在庫があることを判断する基準とすることができる。

（１）ここで「Ｘ<Ａ１」、すなわち商品の在庫数が予め定められた閾値Ａ１よりも小さい値（あるいは以下の値）であれば、在庫が少なく積極的な広告表示にあまり意味がないとして、非積極的な広告表示を行うための「命令Ａ」、「命令Ｂ」、「命令Ｃ」が関連付けられている。

（２）一方「Ｘ≧Ａ２」、すなわち商品の在庫数が予め定められた閾値Ａ２以上の値（あるいはより大きい値）であれば、在庫が多く積極的な広告表示が必要として、積極的な広告表示を行うための「命令Ｄ」、「命令Ｅ」、「命令Ｆ」が関連付けられている、という具合である。

なお、上記閾値「Ａ１」又は「Ａ２」は同じ値であっても構わない。また、販売できる商品が少ないなどの状況を示す閾値「Ａ１」と、販売できる商品が十分あるなどの状況を示す閾値「Ａ２」は、その定義上、当然「Ａ１<Ａ２」という大小関係にある。また、この閾値は商品ごとに異なった値で設定されていても良い。その場合には、受発注在庫情報に含まれる商品ＩＤを利用して、その商品個別の閾値を特定するよう構成すると良い。
また上記例において閾値Ｘは、「販売できる商品が少ない／多い状況」を示す閾値として在庫数と比較されることになる。ここで、閾値Ｘが「販売できる商品が十分調達できない／できる状況」を示す閾値であれば、例えば、「在庫数」から（将来の調達予定数値である）「入荷予定数」を減じて算出された値と比較するよう構成すると良い。

つづいて、この閾値と受発注在庫情報との関係に対して、上記広告管理テーブルにて関連付けられている「命令ＡからＦ」のそれぞれについて詳細に説明する。

まず、第一の命令である「命令Ａ」は、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たした場合に、命令に係る商品の広告の頻度を少なくするための命令である。

なお、「広告の頻度」とは、広告が表示される頻度をいい、例えばその広告の絶対的な表示回数や表示時間、他の広告との相対的な表示割合などが挙げられる。

図７は、この命令Ａのデータ内容の一例を示す概略図である。この図にあるように、命令Ａは、一日の表示回数を現在の７５％に減らす、といった具合にその広告の表示回数を減らすための命令であってもよい。あるいは、一日の表示時間を１／２に減らす、といった具合にその広告の表示時間を減らすための命令も挙げられる。また、他の広告の表示割合（回数や時間などの割合）を現在の割合から１１０％増やす命令とすることで、相対的に対象となる広告の表示頻度を減らすような命令であっても良い。

あるいは、広告管理マスタなどを利用して、予め現在の例えば広告表示回数「１００回／1日」などが分かっていれば、命令Ａでは増減率ではなく「７５回／1日」といった具合にその回数などそのものが示されても良い。

また、広告表示の条件が「検索サイトにて所定の検索キーワードが入力された場合」（いわゆる検索連動広告における連動条件）であれば、「カー」「車」「バイク」いずれの検索キーワードでも表示していた（条件１）広告を、「車」のみの検索キーワード入力の場合のみ（条件２）広告表示を行うような命令であっても良い。

また、乱数表に応じてランダムに広告を表示するような形態であれば、乱数表１と乱数表２とを使い分けることでその広告頻度を変更する命令であっても良い。

また、インターネットはその時間帯によってその接続数に大きな差が生じる。そのため、命令Ａは、インターネットの接続数が多い時間帯、例えば「２０時から２４時」から、少ない時間帯、例えば「朝８時から１２時」へとその広告表示の時間帯を変更する命令であっても良い。このような命令Ａによって広告表示の時間帯が制御されることで、ユーザー全体におけるトータルでの広告の（視聴）頻度を変更することが出来る。

そして、上記のようなデータ内容で示される命令Ａによって、広告の表示頻度を、絶対的または他の広告との相対関係において減らすことができる、という具合である。

つづいて、第二の命令である「命令Ｂ」は、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たした場合に、命令に係る商品の広告を訴求度が比較的小さい広告とするための命令である。

なお「訴求度」とは、広告がユーザーの印象に残る度合いなどの情報深度を客観的に指標化したものをいい、一般的には、画面の中で視線が行きやすい位置に表示したり、広告そのものを大きく表示したり、アニメーションなどの視覚効果あるいは音声を付加して表示したりする場合に広告の訴求度が高くなる。

そして、本実施例の広告管理サーバでは、例えば上記原則に応じて広告の表示位置や表示形態と、その訴求度属性値とを関連付けた訴求度属性値テーブルを保持していると良い。この「訴求度属性値テーブル」では、例えば視認性の高いトップページや広告表示スペースＡ、あるいは動画広告は、その訴求度属性値が「ランク３」として関連付けられている。あるいは、視認性に劣るトップページから２階層下のページや広告表示スペースＢ、あるいはテキストベースのバナー広告などは、それよりも訴求度属性値が低い「ランク２」として関連付けられている、という具合である。

そしてこの命令Ｂは、例えばその訴求度属性値を示すランクを指定することで、上記訴求度属性値テーブルを参照してその訴求度に応じた表示位置や表示形態の変更を計算機に処理させるよう構成すると良い。

図８は、この命令Ｂのデータ内容の一例を示す概略図である。この図にあるように、命令Ｂは、例えば広告の表示ページをＷｅｂサイトのトップページ（訴求度属性値のランク３）からトップページの２階層下のページ（同ランク２）に変更することで、広告を比較的ユーザーの目に付き難くする命令が挙げられる。あるいは、同一の表示ページであっても、同ランク３の表示スペースＡ（例えば図２のα）から比較的視認性の低い同ランク２の表示スペースＢ（例えば図２のβ）にその表示位置を変更する命令なども挙げられる。

また、同一商品に関して動画形式の広告とテキストベースのバナー広告など広告属性形態が異なる複数の広告が用意されていれば、広告属性形態が動画広告（同ランク３）から、テキストのバナー広告（同ランク２）に変更するための命令などであっても良い。具体的には、例えば一の商品ＩＤと、広告属性形態（訴求度ランク）が異なる複数の広告ＩＤとを関連付けた参照用テーブルを予め用意しておく。そして、受発注在庫情報に含まれる商品ＩＤと、命令Ｂで指定される広告属性形態（訴求度ランク）などをキーとして、ある商品に関する（訴求度が変更された）広告を特定する、という具合である。
なお、上記命令に応じた計算機上の処理においては、例えば以下のようにして実現すると良い、例えば命令Ｂの命令内容を「ランクを1ランクダウンさせる」といった内容とすることで、前述の訴求度属性値テーブルを参照し、該当するランクの属性値と関連付けられた例えば表示位置などを選択するよう構成する、という具合である。

また、検索連動広告などにおいては、例えばあるキーワードに対する入札価格が高い広告ほど、訴求度の高い表示位置に表示するよう構成された検索連動型位置決定プログラムを利用している。そこで、「命令Ｂ」を、「（在庫の少なくなった商品の広告の）入札価格を仮想的に下げて、前記検索連動型位置決定プログラムでの表示位置決定処理を実行する」といった命令とすることで、結果的に広告の訴求度が変更されるようにしても良い。
具体的には、例えば「メモリーカード」というキーワードに対してＡ社のメモリーカード「ＭＡ」の広告の入札価格は１０万円であり、Ｂ社のメモリーカード「ＭＢ」の広告の入札価格は８万円であった。すると、「メモリーカード」というキーワード検索に連動して広告を表示する場合には、「ＭＡ」の方が「ＭＢ」よりも訴求度の高い場所に表示される。
ここで、「ＭＡ」の在庫数減少などに応じて「ＭＡの入札価格を（仮想的に）７５％に減額する」といった命令Ｂを出力する。すると、「ＭＡ」の広告の入札価格は（仮想的に）７．５万円となる。一方Ｂ社のメモリーカード「ＭＢ」の広告の入札価格は８万円であるので、前述の検索連動型位置決定プログラムは、「ＭＡ」の広告の表示位置を「ＭＢ」の表示位置よりも訴求度が低い位置と決定することになる、という具合である。
もちろん、実際に広告効果（訴求度）が下がる位置に表示位置を変更しているので、入札価格の減額は、仮想的ではなく、実際の広告料に反映されるようにしても構わない。

また、上記以外にも、前述のように広告の表示サイズによってもその訴求度は変わってくる。そこで、命令Ｂは、その表示サイズを１／３（例えば「幅３００ピクセル×高さ９０ピクセル」であれば「幅１００×高さ３０」）に変更する命令などであっても良い。

そして、上記のようなデータ内容で示される命令Ｂによって、広告の表示位置や表示サイズ、あるいは動画やテキストなど広告属性を変更することで訴求度の低い広告を表示することができる、という具合である。

つづいて、第三の命令である「命令Ｃ」は、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たした場合に、命令に係る商品の広告を停止するための命令をいう。

図９は、この命令Ｃのデータ内容の一例を示す概略図である。この図にあるように、命令Ｃは、例えばその広告の表示終了時刻を指定し、広告表示を終了させる命令などが挙げられる。

以上のように、受発注在庫情報と閾値との関係から、例えば商品在庫が少なくなった／無くなったなどの場合には命令Ａから命令Ｃによって広告の表示を非積極的とすることができる。

一方、命令Ｄから命令Ｆは、逆に商品在庫が多いなどの場合に積極的に広告表示を行うための命令となる。

具体的に「命令Ｄ」は、受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たした場合に、命令に係る商品の広告の頻度を多くするための命令をいう。つまり、命令Ａと逆の広告表示処理を行うための命令である。

図１０は、この命令Ｄのデータ内容の一例を示す概略図である。この図にあるように、命令Ｄは、一日の表示回数を現在の１２０％に増やす、といった具合にその広告の表示回数を増やすための命令が挙げられる。あるいは、一日の表示時間を現在の２倍に増やす、といった具合にその広告の表示時間を増やすための命令も挙げられる。また、他の広告の表示割合を現在の割合から７０％減らす命令とすることで、相対的に対象となる広告の表示頻度を増やすような命令であっても良い。

また、命令Ａ同様に、広告表示の条件が「検索サイトにて所定の検索キーワードが入力された場合」であれば、「車」のみの検索キーワードで表示していた（条件２）広告を、「カー」「車」「バイク」いずれの検索キーワード入力でも広告表示を行う（条件１）とするような命令であっても良い。また、乱数表に応じてランダムに広告を表示するような形態であれば、使用する乱数表を２から１に変更する命令であっても良い。

そして、上記のようなデータ内容で示される命令Ｄによって、広告の表示頻度が、絶対的または他の広告との相対関係で増やすことができる、という具合である。

つづいて、第５の命令である「命令Ｅ」は、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たした場合に、命令に係る商品の広告を訴求度が比較的大きい広告とする命令をいう。つまり、命令Ｂと逆の広告表示処理を行うための命令である。

図１１は、この命令Ｅのデータ内容の一例を示す概略図である。この図にあるように、命令Ｅは、例えば広告の表示ページを訴求度属性値のランクが３であるトップページに変更することで、広告をユーザーの目に付き易くするようにするための命令が挙げられる。あるいは、同一の表示ページ内で視認性の低い表示スペースＢ（同ランク２）から比較的視認性の高い表示スペースＡ（同ランク３）にその表示位置を変更する命令なども挙げられる。
また、前述の検索連動広告などにおいては、「（在庫の多い商品の広告の）入札価格を仮想的に上げて、検索連動型位置決定プログラムでの表示位置決定処理を実行する」といった命令とすることで、結果的に広告の訴求度が高くなるようにしても良い。

また、同一商品に関して広告属性形態が異なる複数の広告が用意されていれば、例えばテキストベースのバナー広告（同ランク２）から動画広告（同ランク３）に変更するための命令などであっても良い。

また、例えば広告の表示サイズを３倍に変更する命令などであっても良い。

そして、上記のようなデータ内容で示される命令Ｅによって、広告の表示位置や表示サイズ、あるいは動画やテキストなど広告属性を変更することで訴求度の高い広告を表示することができる、という具合である。

つづいて、第六の命令である「命令Ｆ」は、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たした場合に、それまでに命令に係る商品の広告がされていない場合にはその商品の広告を開始するための命令をいう。つまり、命令Ｃと逆の広告表示処理を行うための命令である。

図１２は、この命令Ｆのデータ内容の一例を示す概略図である。この図にあるように、命令Ｆは、例えば広告の開始時刻や、その広告の一日の表示回数、表示ページやその表示サイズなどを示す情報が挙げられる。

そして、上記のようなデータ内容で示される命令Ｆによって、新たに広告表示が開始される、という具合である。

以上のように、受発注在庫情報と閾値との関係から、例えば商品在庫が多いなどの場合には命令Ｄから命令Ｆによって積極的に広告の表示を実行することができる。

なお、上記各命令のデータ内容は一例であって、例えば命令で示されるデータ内容は、対象となる広告を示すＩＤと、命令種別を示すＩＤのみであっても構わない。その場合、広告ＤＢが、広告の例えば表示頻度や表示サイズ、表示属性を管理する広告管理マスタ（テーブル）を保持しておき、また、命令種別に応じた命令の内容を示す命令テーブルを保持することで、上記説明したような広告の表示頻度や表示サイズ等の変更処理を行うよう構成されていても良い。

「命令取得部」（０５１３）は、受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する機能を有する。この命令取得部は、例えばＣＰＵなどの演算回路と、主メモリなどの一次記憶装置などで実現することができる。

図１３は、前述の広告管理テーブルの一例を表す図である。この図を利用して命令取得部での命令取得処理について説明する。この図にあるように、例えば広告管理テーブルには、受発注在庫情報で示される在庫数「Ｘ」と閾値「Ａ」との差分値と、命令ＡからＦの命令種別とが関連付けて示されている。なお、図１３（ａ）では「Ａ：Ａ１＝Ａ２」の場合におけるテーブルの一例を表している。また図１３（ｂ）では、「Ａ１≠Ａ２」の場合におけるリレーショナルテーブルの一例を表している。

そこで、命令取得部では、例えばＣＰＵなどの四則演算処理によって主メモリに格納したＸとＡとの差分値を算出する。そしてその差分値をキーとして、例えば「０以下」であれば十分な在庫が残っていないとして「命令Ｃ」（その商品に係る広告の停止命令）を取得する。また、差分値が「５１〜１００」であれば、在庫が十分あるとして「命令Ｄ」（その商品に係る広告表示の頻度を挙げる命令）を取得する、といった具合である。

もちろん、上記取得例は一例であって、例えば広告管理テーブルが差分値に応じて複数の命令を同時に選択するよう構成しても良い。また、在庫数以外にも受発注在庫情報で示される受注数と閾値との差分を算出するよう構成しても良い。また、命令も予め設定されているものを選択取得するだけでなく、広告に合わせて命令ＡからＦを生成、取得するような構成であっても良い。具体的には広告管理サーバが、広告ＤＢから「現在配信中の広告の識別ＩＤや、その広告のサイズを示す情報」などを取得可能に構成されている。そして取得した広告のサイズ、例えば「３００×９０」を示すサイズ情報を利用して、「該広告のサイズを１００×３０に縮小する」という命令を生成する、という具合である。
また、受発注在庫情報と閾値との関係を示す値は差分値には限定されず、例えば、発注および受注数と閾値とを変数とする所定式から導かられる指標値などであっても良い。

「命令送信部」（０５１４）は、取得した命令を広告ＤＢに送信する機能を有する。この命令送信部は、例えば、インターネットなどのネットワーク回線と接続するための接続ポートやその通信制御回路などで実現することができる。

そして上記のように、例えば在庫などが少なければ命令ＡからＣの非積極的な広告表示をするための命令をこの命令送信部から送信することで、次の広告ＤＢでの広告表示を非積極的なものとすることができる。また、例えば在庫などが多ければ命令ＤからＦの積極的な広告表示をするための命令をこの命令送信部から送信することで、次の広告ＤＢでの広告表示を積極的なものとすることができる、という具合である。

（広告ＤＢ）

次に、本実施例の広告管理システムを構成する「広告ＤＢ」について説明する。

図１４は、本実施例の広告管理システムにおける、特に広告ＤＢ（データベース）の機能ブロックの一例を表す図である。この図にあるように、本実施例の広告管理システムは、前述のように「ＰＯＳシステム」（１４００）と、「広告管理サーバ」（１４１０）と、「広告ＤＢ」（１４２０）と、からなる。

なお、「広告ＤＢ」とは、前記商品などの広告をウエッブ上で公開するためのデータベースをいう。また、この「広告ＤＢ」は、「広告管理サーバ」に組みこまれていても、あるいは逆にこの「広告ＤＢ」に前述の「広告管理サーバ」が組み込まれていても構わない。

そして、「広告ＤＢ」（１４２０）は、「命令受信部」（１４２１）と、「広告蓄積部」（１４２２）と、「Ａ計算部」（１４２３）と、「Ｂ計算部」（１４２４）と、「Ｃ計算部」（１４２５）と、「Ｄ計算部」（１４２６）と、「Ｅ計算部」（１４２７）と、「Ｆ計算部」（１４２８）と、を有する。

「命令受信部」（１４２１）は、広告管理サーバから命令を受信する機能を有する。この命令受信部は、例えば、インターネットなどのネットワーク回線と接続するための接続ポートやその通信制御回路などで実現することができる。

そして、ここで受信した命令に応じて、広告ＤＢでは、広告の表示制御を行うためのスケジュールを計算する、という具合である。

「広告蓄積部」（１４２２）は、広告を蓄積する機能を有する。この広告蓄積部は、例えば、ＨＤＤ（ハードディスクドライブ）や不揮発性メモリ、光学記録メディアなどの二次記憶媒体によって実現することができる。

そして、ここに蓄積されている広告が、受信した命令に応じた表示頻度や表示位置などでウエッブページに表示される、という具合である。

また、この広告蓄積部にて、例えば同一の商品に対して動画形式の広告とテキストベースのバナー広告など広告属性形態が異なる複数の広告が用意されていれば、蓄積されている広告とその広告属性とを関連付けたテーブルを保持していても良い。そしてそのテーブルを利用して、命令Ｂや命令Ｅに応じた訴求度の高い／低い広告への差し替えなどを実現するよう構成することができる。

また広告ＤＢが、広告管理マスタとして、現在実行中の各広告の表示頻度や表示時間、表示サイズなどの情報を保持、管理していても良い。もちろん、広告管理サーバにこの広告管理マスタが保持されていて、必要に応じて命令とともにこれら管理情報が広告ＤＢに送信されるような構成であっても良い。

そして、ここに蓄積されている広告が、次のＡからＦの計算部のスケジュール計算処理によって、各命令に応じた表示頻度や表示位置などでウエッブページに表示されることになる。

「Ａ計算部」（１４２３）は、受信した命令が命令Ａである場合には、他の広告に比較して命令に係る商品の広告頻度を下げるスケジュールを計算する機能を有する。なお、各計算部において計算される「スケジュール」とは、ウエッブ広告の表示タイミングなどの時間的なスケジュール（規定）等が挙げられる。

Ａ計算部において計算される処理としては、例えば、対象となる広告の絶対的な表示回数を減らすようなスケジュールを計算する処理が挙げられる。例えば、前述の広告管理マスタなどから取得した対象となる広告の現在の表示回数情報、例えば「２０」を取得する。そして、命令Ａにて例えばその回数を１／２に減じる命令が示されていれば、「２０」を１／２にする演算処理を実行し、その広告の表示回数を「１０」として算出する。

そして、ウエッブページ上にその広告を１日１０回表示するためのスケジュールを、他の広告のスケジュールも加味して計算する、という具合である。具体的には、例えば他の広告も合わせてそのウエッブページ上で全部で１００回の広告が表示される。その場合には２４時間を１００で割った枠を生成し、乱数処理などでそのうちの１０の枠にその広告を表示するようスケジュールを計算し、その他の広告も同様に乱数処理でその表示枠を決定する、という具合である。

もちろん、このような表示時間に応じたスケジュール計算以外にも、表示位置等のスケジュール計算も同様に実行することが出来る。

またその他にも、広告表示の条件が「検索サイトにて所定の検索キーワードが入力された場合」であれば、Ａ計算部ではその命令に応じて、例えば検索キーワードと広告のワードとが一致するか否かの判断処理を行う計算を実行し、一致すれば広告を表示する、といった計算を実行しても良い。

「Ｂ計算部」（１４２４）は、受信した命令が命令Ｂであり、訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的低い広告に命令に係る商品の広告を入れ替えるスケジュールを計算する機能を有する。

Ｂ計算部において計算される処理としては、例えば、対象となる広告の表示ページを変更するための計算処理や、表示サイズを減らすような計算処理、あるいは、表示スペースを変更するための計算処理、表示時間帯を変更するための計算処理、広告属性（動画広告やバナー広告）を変更するための計算処理が挙げられる。

具体的には、例えば広告の表示スペースを１ランクダウンさせる旨の命令Bであれば、現在の表示スペースのランクから１低いランクの表示スペースを前述の訴求度属性値テーブルを参照して決定する、といった計算を行う、という具合である。

「Ｃ計算部」（１４２５）は、受信した命令が命令Ｃである場合には、命令に係る商品の広告を停止するスケジュールを計算する機能を有する。このＣ計算部では、この広告の表示を停止するとともに、例えば前述の広告管理マスタなどから対象となる広告の現在の表示時間や表示位置などを取得する。そして停止によって空いたその広告表示領域や表示時間帯に、別の広告を表示するためのスケジュールの計算を同時に行う、という具合である。

「Ｄ計算部」（１４２６）は、受信した命令が命令Ｄである場合には、他の広告に比較して命令に係る商品の広告の頻度を多くするスケジュールを計算する機能を有する。すなわち、このＤ計算部では、具体的には命令Ｄにしたがって、Ａ計算部と逆に、例えば広告の絶対的な表示回数を増やすなどの計算を行う。また、それに合わせて、他の広告の表示回数を減らして表示するための１日のスケジュールを計算する、という具合である。

「Ｅ計算部」（１４２７）は、受信した命令が命令Ｅであり、訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的大きい広告に命令に係る商品の広告を入れ替えるスケジュールを計算する機能を有する。すなわち、このＥ計算部では、具体的には命令Ｅにしたがって、Ｂ計算部と逆に、例えば広告表示サイズを大きくするなどの計算を行う。また、それに合わせて、他の広告の表示サイズを減らしたりするための計算を実行する、という具合である。

「Ｆ計算部」（１４２８）は、受信した命令が命令Ｆである場合には、命令に係る商品の広告を開始するスケジュールを計算する機能を有する。すなわち、このＦ計算部では、具体的には命令Ｆにしたがって、Ｃ計算部と逆に、広告表示を開始するために、他の広告の表示時間を削る計算などをして対象となる広告の表示開始時間などの計算を行う、という具合である。
なお、ある商品に関して例えば命令受信部にて命令Ｂを受信し、訴求度の比較的小さい広告への切替を行うべきところ、その商品広告には比較的訴求度の小さい広告がない、などの場合もあり得る。そのような場合には、例外／エラー処理として、例えば命令優先順位テーブルなどを利用して別の代替命令に応じた処理を実行したり、あるいは命令に応じた処理そのものを実行しなかったりする、といった処理を行うと良い。

以上のように、本実施例の広告管理システムによって、商品在庫が少ないなどの場合には、その商品の広告を目立たないような形態で表示することができる。したがって、商品が無い状態でユーザーの購入意欲を無駄に刺激する、といった事態の発生を防ぐことができる。

また、その商品の広告を目立たなくすることで、相対的に別の（在庫の多い）広告の広告効果を向上するようにすることもできる。

一方、商品在庫が多いなどの場合には、本実施例の広告管理システムではユーザーの購入意欲を刺激するようにその商品の広告を積極的に表示することができる。したがって、商品在庫の減少に寄与する効果が期待できる。

<ハードウェア的構成>

以下、図を用いて、上記「ＰＯＳシステム」、「広告管理サーバ」、および「広告ＤＢ」のそれぞれの機能的な構成要件を、ハードウェアとして実現した際の構成の一例について説明する。

（ＰＯＳシステム）

図１５は、広告管理システムを構成する「ＰＯＳシステム」のハードウェア構成の一例を表す概略図である。この図を利用して受発注在庫情報の送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。

この図にあるように、ＰＯＳシステムは、各種演算処理や制御を行う「ＣＰＵ」（１５０１）と、「主メモリ」（１５０２）と、を備えている。また、受発注在庫情報送信部である「Ｉ／Ｏ（インプット／アウトプット）」（１５０３）や、「フラッシュメモリ」（１５０４）、「入力デバイス」（１５０５）、「バーコードリーダ／ＰＯＳレジ端末」（１５０６）なども備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

また、「主メモリ」は、各種処理を行うプログラムをＣＰＵに実行させるために読み出すと同時にそのプログラムの作業領域でもあるワーク領域を提供する。また、この「主メモリ」や「フラッシュメモリ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」で実行されるプログラムは、そのアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。

ここで、棚卸や入荷商品管理用の「バーコードリーダ」や図示しないＰＯＳ端末、あるいはその他の「入力デバイス」を利用した入力によって商品の入荷（発注数）などの情報が商品ＩＤと関連付けて商品別に取得される。そして取得された情報が、「フラッシュメモリ」に格納されている商品管理マスタの発注マスタに登録される。

そして、商品の受注や販売があると、その受注数などを示す情報が「ＰＯＳレジ端末」等から入力され、同じく「フラッシュメモリ」の受注マスタに登録される。また、「ＣＰＵ」などの演算処理でその発注数と受注数の差分などから商品ごとの在庫数も算出され、「フラッシュメモリ」の在庫マスタに登録される。

その後、「入力デバイス」によって、受発注在庫情報を送信するためのキー入力操作を受付けると、商品管理プログラムにしたがって、「フラッシュメモリ」に格納されている受注マスタ、発注マスタ、在庫マスタのデータを利用した商品ＩＤごとの受発注在庫情報が生成され、「主メモリ」のアドレス１などに格納される。

つづいて、商品管理プログラムは「主メモリのアドレス１、・・・、に格納されている情報をＩＰｘｘｘｘに送信せよ」との命令を出力する。そして、その命令に従って商品ごとの受発注在庫情報が「Ｉ／Ｏ」から広告管理サーバに送信される、という具合である。

（広告管理サーバ）

図１６は、広告管理システムを構成する「広告管理サーバ」のハードウェア構成の一例を表す概略図である。この図を利用して商品の在庫量等に応じた命令の生成／取得、送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。

この図にあるように、広告管理サーバは、各種演算処理や制御を行う「ＣＰＵ」（１６０１）と、「主メモリ」（１６０２）と、を備えている。また、この「ＣＰＵ」と「主メモリ」によって命令取得部の機能を実現することができる。

また、この広告管理サーバは、さらに受発注在庫情報受信部および命令送信部である「Ｉ／Ｏ」（１６０３）や、広告管理テーブル保持部である「ＨＤＤ」（１６０４）や「フラッシュメモリ」（１６０５）なども備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

ここで、「Ｉ／Ｏ」にて、ＰＯＳシステムから送信された商品ごとの受発注在庫情報を受信すると、その受信した受発注在庫情報を「主メモリ」のアドレス１に格納する。そして、この主メモリへの格納をトリガーとして、命令取得プログラムは以下の処理を実行する。なお、ここでは閾値が「Ａ１≠Ａ２」である場合を例に挙げ、以下にその処理について説明する

まず、「フラッシュメモリ」から予め格納されている閾値Ａ１を読み出し、「主メモリ」のアドレス２に格納する。なお、この閾値Ａ１は販売できる商品が十分ある状況を示す閾値であるとする。そして、受発注在庫情報で示される例えば在庫数Ｘと、その閾値Ａ１との差分値を、「ＣＰＵ」の四則演算処理によって算出し、その算出値を「主メモリ」のアドレス３に格納する。

ここで、例えば在庫数が１５２であって閾値Ａ１が１００であるならば、その差分値は５２となる。つまり販売できる商品が十分ある状況を示す閾値より在庫数の方が５２多く、提供可能な商品が潤沢にある、と解釈することができる。そこで、「ＨＤＤ」に格納されている広告管理テーブルにおいては、閾値Ａ１との差分値が＋５０以上の場合には命令Ｄ，Ｅ，Ｆなど、積極的な広告表示を行うための命令が関連付けられている。

したがって、この「主メモリ」のアドレス３に格納されているＸ−Ａ１の値をキーとして「ＨＤＤ」に保持されている広告管理テーブルが検索される。そして例えば命令Ｄが取得するべき命令種別として選択され、「主メモリ」のアドレス４に格納される。

また、受発注在庫情報で示される在庫数Ｘが、例えば３８であった場合、その値は閾値Ａ１である１００よりも小さい。そこで、今度は販売できる商品が少ない状況を示す閾値Ａ２、例えば「５０」を読み出し、その差分値を算出する。すると、販売できる商品が少ない状況を示す閾値より在庫数の方が１２少なく、提供可能な商品が潤沢にはない、と解釈することができる。そこで、「ＨＤＤ」に格納されている広告管理テーブルにおいては、閾値Ａ２との差分値がマイナスの値をとる場合には命令Ａ，Ｂ，Ｃなど、非積極的な広告表示を行うための命令が関連付けられている。

したがって、この場合には「主メモリ」のアドレス３に格納されているＸ−Ａ２の値をキーとして「ＨＤＤ」に保持されている広告管理テーブルが検索される。そして例えば命令Ｂが取得するべき命令種別として選択され、商品ＩＤとともに「Ｉ／Ｏ」から広告ＤＢへ送信される、という具合である。

（広告ＤＢ）

図１７は、広告管理システムを構成する「広告ＤＢ」のハードウェア構成の一例を表す概略図である。この図を利用して広告のスケジュール計算処理におけるそれぞれのハードウェア構成部の働きについて説明する。

この図にあるように、広告ＤＢは、各種演算処理や制御を行う「ＣＰＵ」（１７０１）と、「主メモリ」（１７０２）と、を備えている。また、この「ＣＰＵ」と「主メモリ」によってＡ計算部からＦ計算部の機能を実現することができる。

また、この広告ＤＢは、さらに命令受信部である「Ｉ／Ｏ」（１７０３）や、広告蓄積部である「ＨＤＤ」（１７０４）なども備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

ここで、「Ｉ／Ｏ」にて、広告管理サーバから送信された命令（ここでは命令種別がＢ）を受信すると、その受信した命令Ｂを「主メモリ」のアドレス１に格納する。そして、この主メモリへの格納をトリガーとして、スケジュール計算プログラムは以下の処理を実行する。

まず、「主メモリ」のアドレス１に格納されている命令Ｂから、命令内容として例えば表示サイズの修正用変数「１／３」と、広告属性の修正用変数「１ランクダウン」を取得し、「主メモリ」のアドレス２に格納する。

続いて、命令とともに送信された商品ＩＤなどを利用し、「ＨＤＤ」に格納されている広告管理マスタの情報を「ＣＰＵ」の演算処理によって検索し、命令に応じてその表示形態などを変更すべき広告を特定する。そして、特定した広告に関する例えば表示サイズや表示属性（動画かテキストか）などを示す情報を、同様に広告管理マスタから取得する。

そしてその取得した情報から、対象となる広告のウエッブページ上での表示サイズが「幅３００×高さ９０」であって、また、その広告属性が「動画広告（ランク３）」であることが分かる。

そこで、スケジュール計算プログラムにしたがって、「ＣＰＵ」の演算処理により表示サイズ「幅３００×高さ９０」を命令で示される修正用変数「１／３」で修正した新たな表示サイズ「幅１００×高さ３０」が新スケジュールとして算出される。また、広告属性ランクも修正用変数「１ランクダウン」にしたがい「動画広告（ランク３）」から「テキストバナー広告（ランク２）」が新スケジュールとして算出される。

そして、このように算出された新スケジュールが「主メモリ」のアドレス３に格納され、例えば「Ｉ／Ｏ」からその広告を表示しているウエッブページを保持しているウエッブサーバに対して送信される。それによって、受発注や在庫などに連動してウエッブページ上での広告の表示形態などを制御することができる、という具合である。

<処理の流れ>

図１８は、本実施例の広告管理システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。また、この処理の実行は所定時間おきに実行されるバッチ処理であっても良いし、例えば管理者操作などによって任意に実行されるような処理であっても良い。

この図にあるように、まず、広告管理サーバにおいて、受発注在庫情報と閾値との関係と、命令Ａ〜Ｆの少なくともいずれか一以上の命令と、を関連付けた広告管理テーブルを保持するために、例えばフラッシュメモリなどに記録する（ステップＳ１８０１）。

その後、ＰＯＳシステムが、商品の受発注在庫情報を商品別に広告管理サーバに対して送信し（ステップＳ１８０２）、広告管理サーバにて、その受発注在庫情報が受信される（ステップＳ１８０３）。

広告管理サーバでは、受信した受発注在庫情報で示される例えば受発注数や在庫数などと、予め保持している閾値と、を例えばＣＰＵの演算処理などで比較し、その関係を算出、取得する（ステップＳ１８０４）。そして取得した関係をキーとして、前記フラッシュメモリなどに保持されている広告管理テーブルを検索し、命令Ａ〜Ｆのいずれか一以上を取得する（ステップＳ１８０５）。そして、取得した命令を、広告ＤＢに送信する（ステップＳ１８０６）。

広告ＤＢでは、まず、予め広告を蓄積するために、例えばＨＤＤなどに記録する（ステップＳ１８０７）。また、その蓄積した広告に関する広告頻度や表示サイズなどの情報を広告管理マスタに登録しても良い。

そして広告管理サーバから送信された命令を広告ＤＢが受信する（ステップＳ１８０８）と、受信した命令に応じて、場合によって広告管理マスタなどの情報を参照し広告のスケジュールを計算する（ステップＳ１８０９）。そして、計算されたスケジュールで、前記ＨＤＤなどに蓄積されている広告のウエッブページ上での表示を実行する、という具合である。

<効果の簡単な説明>

以上のように、本実施例の広告管理システムによって、商品在庫が少ないなどの場合には、その商品の広告を目立たないような形態で表示することができる。したがって、商品が無い状態でユーザーの購入意欲を無駄に刺激する、といった事態の発生を防ぐことができる。

また、その商品の広告を目立たなくすることで、相対的に別の（在庫の多い）広告の広告効果を向上するようにすることもできる。

一方、商品在庫が多いなどの場合には、本実施例の広告管理システムではユーザーの購入意欲を刺激するようにその商品の広告を積極的に表示することができる。したがって、商品在庫の減少に寄与する効果が期待できる。

≪実施例２≫

<概要>

本実施例は、前記実施例１と同様に、受発注在庫情報と閾値との関係に応じた命令を選択、取得する。そして取得した命令に従って、ウエッブ上の広告の表示頻度や表示サイズ、広告属性などの変更を行う機能を備えている広告管理システムである。

そして、本実施例の広告管理システムの特徴点は、変更の対象となる広告が共同購入キャンペーン広告である点である。なお、「共同購入キャンペーン」とは、同一の商品を複数の買い手が共同で購入することで割引等の特典が受けられるキャンペーンである。

図１９は、本実施例の広告管理システムにおけるウエッブ広告の一例を表す概念図である。この図１９（ａ）にあるように、ウエッブ上の広告表示ページの表示エリアαに、「１０人以上の購入で割引」といった具合の商品（メモリーカード）の共同購入キャンペーン広告が表示されている。

そして、この図にあるようにこの共同購入キャンペーンは「５０人まで」といった具合にその共同購入数に上限が設けられている。これは前述のように特典キャンペーンという「共同購入キャンペーン」の特性上から特典が受けられる人の数を制限する（共同購入数に上限を設ける）場合があるからである。

そして、このウエッブ広告を見るなどしたユーザーが共同購入での注文を行い、図１９（ｂ）に示すように、その数が上限として設定されている５０人に到達した。すると、その共同購入に関する注文を受付けたＰＯＳシステムは、受発注在庫情報としてその受注数の情報を広告管理サーバに送信する。すると、広告管理サーバではキャンペーンは終了したとして、表示エリアαの広告を別の商品の広告に差し替える。また、この商品の広告については、広告表示ページの表示エリアβにバナー広告として表示する、という具合である。

このように本実施例では、前記例で説明した在庫数など以上に、受発注在庫情報で示される受注数で広告の表示形態などに変更を行うようにすることが好ましい。ただし、もちろん本実施例においても在庫数などに応じて命令が選択、取得されるよう構成しても良いことは言うまでも無い。

<機能的構成>

以下、適宜図を用いて本実施例の広告管理システムを構成する「ＰＯＳシステム」、「広告管理サーバ」、および「広告ＤＢ（データベース）」のそれぞれの構成要件について説明する。まず、ＰＯＳシステムについて説明する。

（ＰＯＳシステム）

図２０は、本実施例の広告管理システムにおける、特にＰＯＳシステムの機能ブロックの一例を表す図である。この図にあるように、本実施例の広告管理システムは、実施例１と同様に、「ＰＯＳシステム」（２０００）と、「広告管理サーバ」（２０１０）と、「広告ＤＢ」（２０２０）と、からなる。

そして、この「ＰＯＳシステム」（２０００）は、「受発注在庫情報送信部」（２００１）を有する。

「受発注在庫情報送信部」（２００１）は、上記実施例１同様に、商品の受発注在庫情報を商品別に広告管理サーバに対して送信する機能を有する。そして実施例１との相違点は、その受発注在庫情報を送信する商品の広告が、ウエッブ上で共同購入キャンペーン広告である点である。ただし、当該商品が共同購入キャンペーンに係る商品であるか否かの判断処理は、次に説明するように広告管理サーバにて行う。そのため、ここで送信される受発注在庫情報そのものは実施例１と同内容の情報が送信されて構わない。もちろん、図示していないがＰＯＳシステムにて商品ごとに共同購入キャンペーン有無を管理するための構成を有することで、ここで送信される受発注在庫情報に共同購入キャンペーンの有無を示すフラグ情報が含まれていても構わない。また、送信される受発注在庫情報は、前述の通り共同購入キャンペーンの特性からその受注数を含むことが望ましい。

（広告管理サーバ）

次に、本実施例の広告管理システムを構成する「広告管理サーバ」について説明する。

図２１は、本実施例の広告管理システムにおける、特に広告管理サーバの機能ブロックの一例を表す図である。この図にあるように、本実施例の広告管理システムは、前述のように「ＰＯＳシステム」（２１００）と、「広告管理サーバ」（２１１０）と、「広告ＤＢ」（２２２０）と、からなる。

そして、「広告管理サーバ」（２１１０）は、「受発注在庫情報受信部」（２１１１）と、「キャンペーン実行有無情報保持部」（２１１２）と、「第二広告管理テーブル保持部」（２１１３）と、「キャンペーン実行有無判断部」（２１１４）と、「第二命令取得部」（２１１５）と、「命令送信部」（２１１６）と、を有する。

「受発注在庫情報受信部」（２１１１）は、受発注在庫情報を受信する機能を有する。そして本実施例の広告管理サーバは、ここで受信した受発注在庫情報に含まれる商品ＩＤなどを利用して、後述する次のような構成によって、その商品が共同購入キャンペーンの対象商品か否かの判断を行うことを特徴とする。
「キャンペーン実行有無情報保持部」（２１１２）は、キャンペーン実行有無情報を保持する機能を有し、例えば各種記憶媒体で実現することができる。「キャンペーン実行有無情報」とは、各商品ごとに共同購入キャンペーンが行われているか否かを示す情報をいい、具体的には、商品ＩＤと、その商品ＩＤで示される商品が共同購入キャンペーンの対象商品か否かを示すフラグ情報と、の組をテーブル化した情報などが挙げられる。
そしてここで保持されている商品別のキャンペーンテーブルを参照することで、本実施例の広告管理サーバは、その商品の共同購入キャンペーン実行の有無を判断することができる。
そして、後述するように受信した受発注在庫情報に係る商品が共同購入キャンペーンの対象商品であれば、その共同購入キャンペーン広告の表示制御が実行される、という具合である。一方、共同購入キャンペーンの対象商品でなければ、上記実施例１で記載したような処理によって、その広告の表示制御が実行されると良い。

「第二広告管理テーブル保持部」（２１１３）は、広告管理テーブルを保持する機能を有する。そして、本実施例における「広告管理テーブル」は、受発注在庫情報と閾値とを比較した「結果」と、「命令ＧからＩ」の少なくともいずれか一以上、又は「命令ＪからＬ」の少なくともいずれか一以上と、を関連付けたテーブルである。なお、上記命令ＧからＬは、その命令の対象となる広告が共同購入キャンペーン広告であることを特徴とする。

したがって、この広告管理テーブルによって、共同購入キャンペーンを実施している商品に係る広告について、後述する命令ＧからＬに応じてその表示頻度等を変更することができる、という具合である。

図２２は、広告管理テーブルで示されるこの比較結果と命令との関連付けの一例を説明するための概念図である。この図にあるように、まずＰＯＳシステムから受信した受発注在庫情報によって、ある商品の現在の受注数は「Ｙ」であることが示される。そして、広告管理サーバ内の二次記憶媒体からその商品の閾値「Ｂ１」又は「Ｂ２」が取得され、「Ｙ」と「Ｂ１（Ｂ２）」の値の大小比較がＣＰＵなどの演算装置の演算処理によって実行される。

なお、閾値Ｂ１は、販売できる商品が少ないなどの状況を示す閾値である。また、閾値Ｂ２は、販売できる商品が十分あるなどの状況を示す閾値である。

（１）ここで「Ｙ≧Ｂ１」、すなわち商品の受注数が予め定められた閾値Ｂ１以上の値（あるいはより大きい値）であれば、これ以上はキャンペーンで設定されている上限人数を超えてしまうとして、非積極的な広告表示を行うための「命令Ｇ」、「命令Ｈ」、「命令Ｉ」が関連付けられている。

（２）一方「Ｙ<Ｂ２」、すなわち商品の受注数が予め定められた閾値Ｂ２より小さい値（あるいは以下の値）であれば、キャンペーンで設定されている共同購入者数に達していないとして、積極的な広告表示を行うための「命令Ｊ」、「命令Ｋ」、「命令Ｌ」が関連付けられている、という具合である。

なお、上記閾値「Ｂ１」又は「Ｂ２」も、実施例１同様に同じ値であっても構わない。

つづいて、この閾値と受発注在庫情報との関係と関連付けられている「命令ＧからＬ」のそれぞれについてその命令内容などを説明する。

「命令Ｇ」は、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たし、かつ、その商品について共同購入キャンペーンが行なわれている場合に、その商品の共同購入キャンペーン広告の頻度を少なくするための命令である。

すなわち、この命令Ｇは、命令Ａと同様の命令であって、対象が共同購入キャンペーン広告であることを特徴する命令である。したがって、この命令Ｇに関する命令内容や命令に応じた具体的な処理などについての説明は省略する。

「命令Ｈ」は、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たし、かつ、その商品について共同購入キャンペーンが行なわれている場合に、訴求度が比較的小さい共同購入キャンペーン広告とするための命令である。

すなわち、この命令Ｈは、命令Ｂと同様の命令であって、対象が共同購入キャンペーン広告であることを特徴する命令である。したがって、この命令Ｈに関する命令内容や命令に応じた具体的な処理などについての説明も省略する。

「命令Ｉ」は、受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たし、かつ、その商品について共同購入キャンペーンが行なわれている場合に、その商品の共同購入キャンペーン広告を停止するための命令である。

すなわち、この命令Ｉは、命令Ｃと同様の命令であって、対象が共同購入キャンペーン広告であることを特徴する命令である。したがって、この命令Ｉに関する命令内容や命令に応じた具体的な処理などについての説明も省略する。

以上のように、受発注在庫情報と閾値との関係から、例えば受注数が共同購入キャンペーンで設定された上限人数値に近くなる／達したなどの場合には命令Ｇから命令Ｉによって広告の表示を非積極的とすることができる。

一方、命令Ｊから命令Ｌは、逆にキャンペーンの上限人数に達していない場合など、実施例１の命令Ｄ，Ｅ，Ｆと同様に積極的な広告表示を行うための命令となる。

「命令Ｊ」は、受発注在庫情報と、販売できる商品が十分ある、又は十分調達できる状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たし、かつ、その商品について共同購入キャンペーンが行なわれている場合に、その商品の共同購入キャンペーン広告の頻度を多くするための命令である。

すなわち、この命令Ｊは、命令Ｄと同様の命令であって、対象が共同購入キャンペーン広告であることを特徴する命令である。したがって、この命令Ｊに関する命令内容や命令に応じた具体的な処理などについての説明は省略する。

「命令Ｋ」は、受発注在庫情報と、販売できる商品が十分ある、又は十分調達できる状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たし、かつ、その商品について共同購入キャンペーンが行なわれている場合に、訴求度が比較的大きい共同購入キャンペーン広告とするための命令である。

すなわち、この命令Ｋは、命令Ｅと同様の命令であって、対象が共同購入キャンペーン広告であることを特徴する命令である。したがって、この命令Ｋに関する命令内容や命令に応じた具体的な処理などについての説明も省略する。

「命令Ｌ」は、受発注在庫情報と、販売できる商品が十分ある、又は十分調達できる状況を示す閾値と、を比較した結果が、その状況に該当する閾値との関係を満たし、かつ、その商品について共同購入キャンペーンが行なわれている場合で、それまでにその商品の広告がされていない場合にはその商品の広告を開始するための命令である。

すなわち、この命令Ｌは、命令Ｆと同様の命令であって、対象が共同購入キャンペーン広告であることを特徴する命令である。したがって、この命令Ｌに関する命令内容や命令に応じた具体的な処理などについての説明も省略する。

以上のように、受発注在庫情報と閾値との関係から、例えば受注数がキャンペーンの上限人数に達していない場合などに積極的な広告表示を行うためができる。

続いて、図２１に戻り、本実施例の広告管理サーバのそのほかの構成要件について説明をする。

「キャンペーン実行有無判断部」（２１１４）は、受信した商品別の受発注在庫情報に基づいて前記保持されているキャンペーン実行有無情報を取得し、その商品について共同購入キャンペーンが行われているか否か判断する機能を有する。
具体的には、例えば受発注在庫情報に含まれる商品ＩＤをキーとして、キャンペーン実行有無情報保持部で保持されている前述の商品別キャンペーンテーブルの検索処理をＣＰＵなどの演算処理によって実行する。そして、検索に合致した商品に関するフラグから、共同購入キャンペーンが行われているか否か判断する、という具合である。
「第二命令取得部」（２１１５）は、前記判断結果が、その商品について共同購入キャンペーンが行われているとの判断結果である場合に、受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する機能を有する。

このように本実施例では、受信した受発注在庫情報に係る商品が共同購入キャンペーンの対象商品であれば、その共同購入キャンペーン広告の表示制御を行うための命令Ｇ〜Ｌが取得される、という具合である。

もちろん、本実施例において取得される命令は共同購入キャンペーン広告を対象とする命令であるが、実施例１と組み合わせることで、それ以外の広告に関しては命令ＡからＦを取得するように構成しても良い。

「命令送信部」（２１１６）は、取得した命令を広告ＤＢに送信する機能を有する。

そして上記のように、例えば受注数がキャンペーンで設定された上限人数などに達すれば命令ＧからＩの非積極的な広告表示をするための命令をこの命令送信部から送信する。そして次の広告ＤＢにて非積極的な広告表示を実行する。

また、例えば受注数がキャンペーン設定人数に未達であれば命令ＪからＬの積極的な広告表示をするための命令をこの命令送信部から送信する。そして次の広告ＤＢにて積極的な広告表示を展開する、という具合である。

（広告ＤＢ）

次に、本実施例の広告管理システムを構成する「広告ＤＢ」について説明する。

図２３は、本実施例の広告管理システムにおける、特に広告ＤＢ（データベース）の機能ブロックの一例を表す図である。この図にあるように、本実施例の広告管理システムは、前述のように「ＰＯＳシステム」（２３００）と、「広告管理サーバ」（２３１０）と、「広告ＤＢ」（２３２０）と、からなる。

そして、「広告ＤＢ」（２３２０）は、「命令受信部」（２３２１）と、「広告蓄積部」（２３２２）と、「Ｇ計算部」（２３２３）と、「Ｈ計算部」（２３２４）と、「Ｉ計算部」（２３２５）と、「Ｊ計算部」（２３２６）と、「Ｋ計算部」（２３２７）と、「Ｌ計算部」（２３２８）と、を有する。

「命令受信部」（２３２１）は、広告管理サーバから命令を受信する機能を有する。

「広告蓄積部」（２３２２）は、広告を蓄積する機能を有する。もちろん、ここで蓄積される広告は共同購入キャンペーンに係る広告となる。そして、ここに蓄積されている共同購入キャンペーン広告が、次のＧからＬの計算部のスケジュール計算処理によって、実施例１同様に受信した各命令に応じた表示頻度や表示位置などでウエッブページに表示されることになる。

「Ｇ計算部」（２３２３）は、受信した命令が命令Ｇである場合には、他の広告に比較して命令に係る商品の広告頻度を下げるスケジュールを計算する機能を有する。すなわち、このＧ計算部は、Ａ計算部と同様のスケジュール計算を行い、その対象が共同購入キャンペーン広告であることを特徴する計算部である。したがって、このＧ計算部に関する詳細な説明は省略する。

「Ｈ計算部」（２３２４）は、受信した命令が命令Ｈであり、訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的低い広告にその商品の広告を入れ替えるスケジュールを計算する機能を有する。すなわち、このＨ計算部は、Ｂ計算部と同様のスケジュール計算を行い、その対象が共同購入キャンペーン広告であることを特徴する計算部である。したがって、このＨ計算部に関する詳細な説明も省略する。

「Ｉ計算部」（２３２５）は、受信した命令が命令Ｉである場合には、命令に係る商品の広告を停止するスケジュールを計算する機能を有する。すなわち、このＩ計算部は、Ｃ計算部と同様のスケジュール計算を行い、その対象が共同購入キャンペーン広告であることを特徴する計算部である。したがって、このＩ計算部に関する詳細な説明も省略する。

「Ｊ計算部」（２３２６）は、受信した命令が命令Ｊである場合には、他の広告に比較して命令に係る商品の広告の頻度を多くするスケジュールを計算する機能を有する。すなわち、このＪ計算部は、Ｄ計算部と同様のスケジュール計算を行い、その対象が共同購入キャンペーン広告であることを特徴する計算部である。したがって、このＪ計算部に関する詳細な説明も省略する。

「Ｋ計算部」（２３２７）は、受信した命令が命令Ｋであり、訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的大きい広告にその商品の広告を入れ替えるスケジュールを計算する機能を有する。すなわち、このＫ計算部は、Ｅ計算部と同様のスケジュール計算を行い、その対象が共同購入キャンペーン広告であることを特徴する計算部である。したがって、このＫ計算部に関する詳細な説明も省略する。

「Ｌ計算部」（２３２８）は、受信した命令が命令Ｌである場合には、その商品の広告を開始するスケジュールを計算する機能を有する。すなわち、このＬ計算部は、Ｆ計算部と同様のスケジュール計算を行い、その対象が共同購入キャンペーン広告であることを特徴する計算部である。したがって、このＬ計算部に関する詳細な説明も省略する。

以上のように、本実施例の広告管理システムによって、例えば受注数が共同購入キャンペーンで設定された上限人数値に近くなる／達したなどの場合には、その広告表示を非積極的で目立たないような形態とすることができる。したがって、共同購入による割引などキャンペーン特典が付与できない状態になったなどの場合にも関わらず、その特典広告が目立つよう表示されてしまう、といった事態の発生を防ぐことができる。

また、例えば受注数がキャンペーンの上限人数に達していない場合などに積極的な広告表示を行うためができる、という具合である。

<処理の流れ>

図２４は、本実施例の広告管理システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。

この図にあるように、まず、広告管理サーバにおいて、共同購入キャンペーン広告が行われている商品に関し、受発注在庫情報と閾値との関係と、命令Ｇ〜Ｌの少なくともいずれか一以上の命令と、を関連付けた広告管理テーブルを保持するために、例えばフラッシュメモリなどに記録する（ステップＳ２４０１）。

その後、ＰＯＳシステムが、商品の受発注在庫情報を商品別に広告管理サーバに対して送信し（ステップＳ２４０２）、広告管理サーバにて、その受発注在庫情報が受信される（ステップＳ２４０３）。

広告管理サーバでは、受信した受発注在庫情報で示される商品ＩＤと、予め保持されているキャンペーン実行有無情報と、を利用して当該商品が共同購入キャンペーンの対象商品か否か、を判断する（ステップＳ２４０４）。その判断の結果、共同購入キャンペーンが実行されていると判断された場合には、受信した受発注在庫情報で示される例えば受注数などと、予め保持している閾値と、を例えばＣＰＵの演算処理などで比較し、その関係を算出、取得する（ステップＳ２４０５）。また、受発注在庫情報で示される商品ＩＤなどから、その商品に係る広告が共同購入キャンペーン広告であるか否かの判断処理を行う。その判断の結果共同購入キャンペーンの広告であれば、ステップＳ２４０５で取得した関係をキーとして、前記フラッシュメモリなどに保持されている広告管理テーブルを検索し、命令Ｇ〜Ｌのいずれか一以上を取得する（ステップＳ２４０６）。そして、取得した命令を、広告ＤＢに送信する（ステップＳ２４０７）。

広告ＤＢでは、まず、予め共同購入キャンペーン広告を蓄積するために、例えばＨＤＤなどに記録する（ステップＳ２４０８）。また、その蓄積した広告に関する広告頻度や表示サイズなどの情報を広告管理マスタに登録しても良い。

そして広告管理サーバから送信された命令を広告ＤＢが受信する（ステップＳ２４０９）と、受信した命令に応じて、場合によって広告管理マスタなどの情報を参照し、共同購入キャンペーンに係る広告のスケジュールを計算する（ステップＳ２４１０）。そして、計算されたスケジュールで、前記ＨＤＤなどに蓄積されている共同購入キャンペーン広告のウエッブページ上での表示を実行する、という具合である。

<効果の簡単な説明>

以上のように、本実施例の広告管理システムによって、例えば受注数が共同購入キャンペーンで設定された上限人数値に近くなる／達したなどの場合には、その広告表示を非積極的で目立たないような形態とすることができる。したがって、共同購入による割引などキャンペーン特典が付与できない状態になったなどの場合にも関わらず、その特典広告が目立つよう表示されてしまう、といった事態の発生を防ぐことができる。

また、例えば受注数がキャンペーンの上限人数に達していない場合などに積極的な広告表示を行うためができる。

≪実施例３≫

<概要>

本実施例は、上記実施例１や２を基本として、さらに広告を表示するウエッブページを命令に応じて選択する機能を備えた広告管理システムである。

すなわち、ウエッブページごとにそのアクセス数やアクセスユーザー層などは異なっている。そのため、ウエッブページごとに広告効果が異なっている、とも言える。そこで、本実施例の広告管理システムでは、受発注在庫情報に応じてその広告を表示するウエッブページそのものを変更することで、さらに無駄の無い広告表示を行う、という具合である。

<機能的構成>

図２５は、本実施例の広告管理システムにおける、特に広告ＤＢの機能ブロックの一例を表す図である。

この図にあるように、本実施例の広告管理システムは、前述のように「ＰＯＳシステム」（２５００）と、「広告管理サーバ」（２５１０）と、「広告ＤＢ」（２５２０）と、からなる。なお、このＰＯＳシステムや広告管理サーバの構成要件については、上記実施例１や２での説明と同様であるので省略する。

そして、「広告ＤＢ」（２５２０）は、実施例1を基本として、「命令受信部」（２５２１）と、「広告蓄積部」（２５２２）と、「Ａ計算部」（２５２３）と、「Ｂ計算部」（２５２４）と、「Ｃ計算部」（２５２５）と、「Ｄ計算部」（２５２６）と、「Ｅ計算部」（２５２７）と、「Ｆ計算部」（２５２８）と、を有する。

なお、上記各構成要件についても、上記実施例１での説明と同様であるので省略する。また、この広告ＤＢは、実施例２を基本として、「命令受信部」と、「広告蓄積部」と、「Ｇ計算部」と、「Ｈ計算部」と、「Ｉ計算部」と、「Ｊ計算部」と、「Ｋ計算部」と、「Ｌ計算部」と、を有していても良い。

そして、本実施例の広告ＤＢの特徴点は、さらに、「選択部」（２５２９）を有する点である。

「選択部」（２５２９）は、さらに受信した命令に応じて広告を掲載するウエッブページを選択する機能を有する。この選択部は、例えばＣＰＵや主メモリなどの演算回路や、後述するアクセス数などの参照用テーブルを保持する記憶媒体などで実現することが出来る。

そして、この選択は、例えば、前述のようにウエッブページごとのアクセス数や、広告のクリック率などの数値情報をテーブル化して保持しておき、非積極的な広告を行うための命令ＡからＣの場合には、その数値が少ないウエッブページを選択する、といった処理が挙げられる。

また、逆に積極的な広告を行うための命令ＤからＦの場合には、その数値が多いウエッブページを選択する、といった具合である。

<効果の簡単な説明>

以上のように、本実施例の広告管理システムによって、ウエッブページごとの広告効果に合わせて、命令に応じた広告の表示ページを選択することが出来る。したがって本実施例の広告管理システムでは、受発注在庫情報に応じてその広告を表示するウエッブページそのものを変更することで、さらに無駄の無い広告表示を行うことが出来る。

実施例１の広告管理システムにおけるウエッブ広告の一例を表す概念図 実施例１の広告管理システムにおけるウエッブ広告の、別の一例を表す概念図 実施例１の広告管理システムにおける、特にＰＯＳシステムの機能ブロックの一例を表す図 実施例１の広告管理システムにおいて送信される受発注在庫情報のデータ内容の一例を表す概略図 実施例１の広告管理システムにおける、特に広告管理サーバの機能ブロックの一例を表す図 実施例１の広告管理システムにおける、広告管理テーブルで示される比較結果と命令との関連付けの一例を説明するための概念図 実施例１の広告管理システムにおける命令Ａのデータ内容の一例を示す概略図 実施例１の広告管理システムにおける命令Ｂのデータ内容の一例を示す概略図 実施例１の広告管理システムにおける命令Ｃのデータ内容の一例を示す概略図 実施例１の広告管理システムにおける命令Ｄのデータ内容の一例を示す概略図 実施例１の広告管理システムにおける命令Ｅのデータ内容の一例を示す概略図 実施例１の広告管理システムにおける命令Ｆのデータ内容の一例を示す概略図 実施例１の広告管理システムにおける広告管理テーブルの一例を表す図 実施例１の広告管理システムにおける、特に広告ＤＢの機能ブロックの一例を表す図 実施例１の広告管理システムを構成するＰＯＳシステムのハードウェア構成の一例を表す概略図 実施例１の広告管理システムを構成する広告管理サーバのハードウェア構成の一例を表す概略図 実施例１の広告管理システムを構成する広告ＤＢのハードウェア構成の一例を表す概略図 実施例１の広告管理システムにおける処理の流れの一例を表すフローチャート 実施例２の広告管理システムにおけるウエッブ広告の一例を表す概念図 実施例２の広告管理システムにおける、特にＰＯＳシステムの機能ブロックの一例を表す図 実施例２の広告管理システムにおける、特に広告管理サーバの機能ブロックの一例を表す図 実施例２の広告管理システムにおける、広告管理テーブルで示される比較結果と命令との関連付けの一例を説明するための概念図 実施例２の広告管理システムにおける、特に広告ＤＢの機能ブロックの一例を表す図 実施例２の広告管理システムにおける処理の流れの一例を表すフローチャート 実施例３の広告管理システムにおける、特に広告ＤＢの機能ブロックの一例を表す図

符号の説明

０３００ ＰＯＳシステム
０３０１ 受発注在庫情報送信部
０５１０ 広告管理サーバ
０５１１ 受発注在庫情報受信部
０５１２ 広告管理テーブル保持部
０５１３ 命令取得部
０５１４ 命令送信部
１４２０ 広告ＤＢ
１４２１ 命令受信部
１４２２ 広告蓄積部
１４２３ Ａ計算部
１４２４ Ｂ計算部
１４２５ Ｃ計算部
１４２６ Ｄ計算部
１４２７ Ｅ計算部
１４２８ Ｆ計算部

Claims (7)

1. ＰＯＳシステムと、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバと、前記商品などの広告をウエッブ上で公開するための広告ＤＢと、からなる広告管理システムであって、
   前記ＰＯＳシステムは、
   商品の受発注在庫情報を商品別に広告管理サーバに対して送信する受発注在庫情報送信部を有し、
   前記広告管理サーバは、
   受発注在庫情報を受信する受発注在庫情報受信部と、
   受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的小さい広告とする命令Ｂと関連付け、
   受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的大きい広告とする命令Ｅと関連付けた広告管理テーブルを保持する広告管理テーブル保持部と、
   受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する命令取得部と、
   取得した前記命令を広告ＤＢに送信する命令送信部と、を有し、
   前記広告ＤＢは、
   広告管理サーバから前記命令を受信する命令受信部と、
   広告を蓄積する広告蓄積部と、
   受信した前記命令が命令Ｂであり、商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態の変更に応じた訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的低い広告に前記命令に係る商品の広告を入れ替えるスケジュールを計算するＢ計算部と、
   受信した前記命令が命令Ｅであり、商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態の変更に応じた訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的大きい広告に前記命令に係る商品の広告を入れ替えるスケジュールを計算するＥ計算部と、を有する
   広告管理システム。
2. ＰＯＳシステムと、商品などの広告をウエッブ上で公開するための広告ＤＢと、に接続され、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバであって、
   前記ＰＯＳシステムから受発注在庫情報を受信する受発注在庫情報受信部と、
   受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的小さい広告とする命令Ｂと関連付け、
   受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的大きい広告とする命令Ｅと関連付けた広告管理テーブルを保持する広告管理テーブル保持部と、
   受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する命令取得部と、
   取得した前記命令を前記広告ＤＢに送信する命令送信部と、
   を有する広告管理サーバ。
3. ＰＯＳシステムと、商品などの広告をウエッブ上で公開するための広告ＤＢと、に接続され、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバであって、
   前記ＰＯＳシステムから受発注在庫情報を受信する受発注在庫情報受信部と、
   各商品ごとに共同購入キャンペーンが行われているか否かを示すキャンペーン実行有無情報を保持するキャンペーン実行有無情報保持部と、
   受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的小さい共同購入キャンペーン広告とする命令Ｈと関連付け、
   受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的大きい共同購入キャンペーン広告とする命令Ｋと関連付けた広告管理テーブルを保持する第二広告管理テーブル保持部と、
   受信した受発注在庫情報に基づいて前記保持されているキャンペーン実行有無情報を取得し、その商品について共同購入キャンペーンが行われているか否か判断するキャンペーン実行有無判断部と、
   前記判断結果が、その商品について共同購入キャンペーンが行われているとの判断結果である場合に、受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する第二命令取得部と、
   取得した前記命令を前記広告ＤＢに送信する命令送信部と、
   を有する広告管理サーバ。
4. 広告ＤＢは、
   さらに受信した前記命令に応じて広告を掲載するウエッブページを選択する選択部を有する請求項１に記載の広告管理システム。
5. ＰＯＳシステムと、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバと、前記商品などの広告をウエッブ上で公開するための広告ＤＢと、からなる広告管理システムの制御方法であって、
   前記ＰＯＳシステムにおいて、
   商品の受発注在庫情報を商品別に広告管理サーバに対して送信する受発注在庫情報送信ステップを計算機に計算させ、
   前記広告管理サーバにおいて、
   受発注在庫情報を受信する受発注在庫情報受信ステップと、
   受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的小さい広告とする命令Ｂと関連付け、
   受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的大きい広告とする命令Ｅと関連付けた広告管理テーブルを保持するために記録する広告管理テーブル記録ステップと、
   受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する命令取得ステップと、
   取得した前記命令を広告ＤＢに送信する命令送信ステップと、を計算機に計算させ、
   予め広告を蓄積している前記広告ＤＢにおいて、
   広告管理サーバから前記命令を受信する命令受信ステップと、
   受信した前記命令が命令Ｂであり、商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態の変更に応じた訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的低い広告に前記命令に係る商品の広告を入れ替えるスケジュールを計算するＢ計算ステップと、
   受信した前記命令が命令Ｅであり、商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態の変更に応じた訴求度を示す属性が蓄積されている広告に与えられている場合には、訴求度を示す属性が比較的大きい広告に前記命令に係る商品の広告を入れ替えるスケジュールを計算するＥ計算ステップと、
   ケジュールを計算するＦ計算ステップと、を計算機に計算させる
   広告管理システムの制御方法。
6. ＰＯＳシステムと、商品などの広告をウエッブ上で公開するための広告ＤＢと、に接続され、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバであって、
   受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的小さい広告とする命令Ｂと関連付け、
   受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的大きい広告とする命令Eと関連付けた広告管理テーブルを有する広告管理サーバの制御方法であって、
   前記ＰＯＳシステムから受発注在庫情報を受信する受発注在庫情報受信ステップと、
   受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する命令取得ステップと、
   取得した前記命令を前記広告ＤＢに送信する命令送信ステップと、
   を計算機に計算させる広告管理サーバの制御方法。
7. ＰＯＳシステムと、商品などの広告をウエッブ上で公開するための広告ＤＢと、に接続され、ＰＯＳシステムで管理されている商品などの広告を管理するための広告管理サーバであって、
   受発注在庫情報と、販売できる商品が少ない又は十分調達できない状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的小さい共同購入キャンペーン広告とする命令Ｈと関連付け、
   受発注在庫情報と、販売できる商品が十分ある又は十分調達できる状況を示す閾値と、を比較した結果を、その商品の広告の1回の表示における当該広告の表示位置又は／及び表示形態を変更することで訴求度を比較的大きい共同購入キャンペーン広告とする命令Ｋと関連付けた広告管理テーブルを有する広告管理サーバの制御方法であって、
   各商品ごとに共同購入キャンペーンが行われているか否かを示すキャンペーン実行有無情報を保持するために記録するキャンペーン実行有無情報記録ステップと、
   ＰＯＳシステムから受発注在庫情報を受信する受発注在庫情報受信ステップと、
   受信した受発注在庫情報に基づいて前記保持されているキャンペーン実行有無情報を取得し、その商品について共同購入キャンペーンが行われているか否か判断するキャンペーン実行有無判断ステップと、
   前記判断結果が、その商品について共同購入キャンペーンが行われているとの判断結果である場合に、受信した受発注在庫情報を前記閾値と比較して、その結果をキーとして広告管理テーブルを検索してその結果に関連付けられた命令を取得する第二命令取得ステップと、
   取得した前記命令を前記広告ＤＢに送信する命令送信ステップと、
   を計算機に計算させる広告管理サーバの制御方法。

Images