JP2015156106A - 広告配信サーバ、端末装置、広告配信方法、広告配信プログラム、及び広告受信プログラム - Google Patents

Abstract

【課題】フリークエンシー値の最大値超過を確実に防止する広告配信サーバ、端末装置、広告配信方法、広告配信プログラム、及び広告受信プログラムを提供すること。
【解決手段】
広告配信サーバ１０は、広告ＤＢ１２１と、広告データの配信先毎に、広告データを配信した配信回数を記憶するフリークエンシーＤＢ１２２と、広告データの配信リクエストを受け付けるリクエスト受付手段１３１と、受け付けられた配信リクエストに対応し、かつ、配信回数が最大値未満の広告データを選定して配信する広告配信手段１３２と、広告データが配信された際に、配信回数を更新する回数更新手段１３３と、配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制するロック手段１３４と、を備える。
【選択図】図１

Description

本発明は、広告データの配信を制御する広告配信サーバ、端末装置、広告配信方法、広告配信プログラム、及び広告受信プログラムに関する。

従来、インターネット上の端末装置に広告を配信する広告制御装置が知られている（例えば、特許文献１参照）。
この特許文献１に記載の装置は、同一ユーザに対して、同じ広告や同じカテゴリの広告が連続して表示されるのを回避するために、広告を表示させた後、所定の第一時間は同一の広告の配信を許容しないように制御している。
一方、ウェブ上で配信される広告として、例えば、クリック課金型広告等では、同一ユーザに対して広告表示回数を制限する必要がある。この場合、広告制御装置は、各広告に対して、ユーザ毎に当該広告が配信された回数（フリークエンシー値）と、所定期間において配信可能な最大値（フリークエンシー最大値）とを記憶したフリークエンシーデータベース（フリークエンシーＤＢ）を備える構成とすればよい。
これによれば、広告制御装置は、ユーザから広告の配信リクエストを受け付けると、配信リクエストに対応し、かつ、フリークエンシー値がフリークエンシー最大値未満の広告を選定して配信する。これにより、フリークエンシー値がフリークエンシー最大値を超過することを抑制できる。

特開２０１１−９６０９３号公報

ところで、広告制御装置では、ユーザから配信リクエストを受け付けてから広告を配信するまでに一定の時間を要する。このため、上記のようなフリークエンシーＤＢを備えた広告制御装置では、例えば、ダブルクリック等により、ほぼ同一タイミングで複数の配信リクエストが同一のユーザから送信された場合、最初の配信リクエストに対する広告の配信が行われてフリークエンシー値が更新される前に、他の配信リクエストに対する広告の選定が行われる可能性がある。このため、最初の配信リクエストに対する広告の配信により、フリークエンシー値がフリークエンシー最大値に達する場合にも、他の配信リクエストに対する広告が選定されて配信されてしまう可能性がある。この場合、フリークエンシー値がフリークエンシー最大値を超過してしまう。

本発明は、フリークエンシー値の最大値超過を確実に防止する広告配信サーバ、端末装置、広告配信方法、広告配信プログラム、及び広告受信プログラムを提供することを目的とする。

本発明の広告配信サーバは、広告データを記憶する広告記憶手段と、前記広告データの配信先毎に、前記広告データを配信した配信回数を記憶する配信回数記憶手段と、前記広告データの配信リクエストを受け付けるリクエスト受付手段と、受け付けられた配信リクエストに対応し、かつ、前記配信回数が最大値未満の広告データを選定して配信する広告配信手段と、前記広告データが配信された際に、前記配信回数を更新する回数更新手段と、配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制するロック手段と、を備えたことを特徴とする。

本発明によれば、配信リクエストが受け付けられると、ロック手段は、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制する。
このため、ほぼ同一タイミングで複数の配信リクエストが同一の端末装置等から送信され、最初の配信リクエストに対する広告データの配信により配信回数が最大値に達するような場合に、他の配信リクエストに対する広告データが選定されて配信されることを防止できる。これにより、配信回数（フリークエンシー値）の最大値超過を確実に防止できる。

本発明の一実施形態に係る広告配信システムの構成を示す図。 本実施形態における広告配信方法を示すフローチャート。 本実施形態における広告配信方法を示すフローチャート。 本発明の変形例６の端末装置の構成を示す図。

以下、本発明の一実施形態について、図面に基づいて説明する。
図１は、本実施形態の広告配信システムの構成を示す図である。
図１に示すように、本実施形態の広告配信システム１は、ウェブ上で広告をユーザに配信するシステムである。
図１に示すように、本実施形態の広告配信システム１は、広告配信サーバ１０と、広告配信サーバ１０に対してネットワーク（例えばインターネット等のＷＡＮ（Wide Area Network））を介して通信可能に接続された端末装置２０とを備えている。

本実施形態の広告配信システム１では、端末装置２０から広告配信に係る配信リクエストが広告配信サーバ１０に送信されると、広告配信サーバ１０は、広告データを端末装置２０に返す。
ここで、端末装置２０は、例えば、携帯電話、スマートフォン、タブレット端末等であり、ユーザに所持されて使用される。
広告データは、例えばコンテンツ用ウェブサーバ（図示略）が提供するウェブページ内に表示する広告であり、ウェブページのＨＴＭＬファイル内に本発明の配信リクエストとなるＵＲＬを含めておく態様が考えられる。この場合、広告配信サーバ１０は、端末装置２０から配信リクエストを受け付ける。
また、他の態様として、コンテンツ用ウェブサーバと広告配信サーバ１０とを例えばインターネット等の通信手段により接続し、端末装置２０からコンテンツ用ウェブサーバへのページリクエストを基に、前記通信手段経由でコンテンツ用ウェブサーバが広告配信サーバ１０に配信リクエストを送信する。そして、広告配信サーバ１０は、当該配信リクエストに応じた広告データをコンテンツ用ウェブサーバに返し、コンテンツ用ウェブサーバは当該広告データの広告をウェブページに組み込み、端末装置２０に提供する。この場合、広告配信サーバ１０は、コンテンツ用ウェブサーバから配信リクエストを受け付ける。
なお、以下では、一例として、前者の態様についての詳細を説明する。

［広告配信サーバの構成］
広告配信サーバ１０は、１つまたは複数のコンピュータにより構成され、サーバ通信部１１、サーバ記憶部１２、及びサーバ制御部１３等を含んで構成されている。
サーバ通信部１１は、例えばＬＡＮ等を介して端末装置２０が接続されるネットワークに接続されており、端末装置２０と通信する。
サーバ記憶部１２は、例えばメモリ、ハードディスク等により構成されたデータ記憶装置である。

サーバ記憶部１２は、複数の広告データを記憶した広告ＤＢ１２１（広告データベース）、及び各広告データに対してそれぞれ設定されたフリークエンシー値等を記憶したフリークエンシーＤＢ１２２（フリークエンシーデータベース）を備えている。すなわち、サーバ記憶部１２は、本発明の広告記憶手段及び配信回数記憶手段として機能する。また、サーバ記憶部１２には、広告配信サーバ１０の動作を制御するための各種プログラムや各種データが記憶されている。

広告ＤＢ１２１には、複数の広告データが記録されている。この広告データには、広告内容（広告画像や音声データ等）、広告ＩＤ、広告主、広告のカテゴリ、リンク先のＵＲＬ等が含まれる。その他、広告配信時の配信リクエストに対応した各種データ（例えば広告を配信したユーザ種別等）が含まれていてもよい。

表１は、フリークエンシーＤＢ１２２の一例を示す図である。フリークエンシーＤＢ１２２は、表１に示すように、端末ＩＤ毎の各広告（広告ＩＤ）に対するフリークエンシー値、及びそのフリークエンシー値の最大値が記録されている。換言すると、広告ＩＤ毎の各端末ＩＤに対するフリークエンシー値、及びそのフリークエンシー値の最大値が記録されている。

ここで、端末ＩＤ（表１における「端末イ」、「端末ロ」、「端末ハ」…）は、本発明における広告データの配信先を識別する識別データである。
広告ＩＤ（表１における「広告Ａ」、「広告Ｂ」、「広告Ｃ」…）は、広告データを識別する識別データであり、広告データに記録された広告ＩＤと同様である。
フリークエンシー値は、広告ＩＤにより特定される広告が、端末ＩＤにて特定された端末装置２０に、所定時間内に配信された配信回数である。広告配信サーバ１０からの広告データが端末装置２０に送信されると、当該端末装置２０に対応したフリークエンシー値に「１」が加算される。なお、このフリークエンシー値は、前記所定時間が経過した時点でリセットされる（「０」に設定される）。
フリークエンシー値の最大値は、例えば、広告主により設定される値であり、所定期間内（例えば１日、１時間等）において、広告データを配信できる最大値となる。
なお、フリークエンシーＤＢ１２２は、表１に示される構成に限定されない。
例えば、フリークエンシー値の最大値は、どの端末装置２０でも同じ値であれば、端末ＩＤに対応付けられていなくても、表２に示されるように、広告ＩＤに対応付けられていればよい。

サーバ制御部１３は、ＣＰＵ（Central Processing Unit）等の演算回路、ＲＡＭ（Random Access Memory）等の記憶回路により構成され、サーバ記憶部１２等に記憶されている広告配信プログラム（ソフトウェア）をＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働で、各種処理を実行する。そして、サーバ制御部１３は、上記各種処理を実行することで、リクエスト受付手段１３１、広告配信手段１３２、回数更新手段１３３、ロック手段１３４として機能する。

リクエスト受付手段１３１は、端末装置２０から送信された配信リクエストを受け付ける。
広告配信手段１３２は、受け付けられた配信リクエストに基づいて、広告データを選定して端末装置２０に配信する。
回数更新手段１３３は、広告配信手段１３２により広告データが配信された際に、フリークエンシーＤＢ１２２のフリークエンシー値を更新する。
ロック手段１３４は、配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制する。また、ロック手段１３４は、所定のロック解除条件に該当すると、前記他の配信リクエストに対する広告データの選定を許可する。
なお、各機能構成の詳細な説明については後述する。

［広告配信方法］
次に、上述のような広告配信システム１における広告配信方法について、図面に基づいて説明する。
図２、図３は、本実施形態における広告配信方法を示すフローチャートである。
本実施形態の広告配信システム１では、端末装置２０から広告配信に関する配信リクエストが広告配信サーバ１０に送信されると、広告配信サーバ１０のリクエスト受付手段１３１は、その配信リクエストを受信する（ステップＳ１（リクエスト受付ステップ））。
この際、リクエスト受付手段１３１は、配信リクエストを送信した端末装置２０から、端末ＩＤも同時に受信する。

そして、広告配信手段１３２は、取得した端末ＩＤを識別する（ステップＳ２）。また、広告配信手段１３２は、取得した端末ＩＤに対して、配信リクエストの受付規制（リードロック）が掛かっているか否かを判定する（ステップＳ３）。なお、本実施形態では、端末ＩＤに対してロックフラグを設定し、当該ロックフラグが「１」の場合にロック状態、当該ロックフラグが「０」の時にアンロック状態とする。ステップＳ３では、広告配信手段１３２は、ロックフラグが「１」であるか否かを判定する。

ステップＳ３において、「Ｙｅｓ」と判定された場合は、配信リクエストを受け付けず、広告配信の処理を終了させる。つまり、当該配信リクエストに対する広告データの選定がロックされた状態であるため、処理を終了させる。

また、ステップＳ３において「Ｎｏ」と判定された場合は、フリークエンシーＤＢ１２２から、ステップＳ２で識別された端末ＩＤに対応する各広告のフリークエンシー値及びその最大値を読み込む。
そして、広告配信手段１３２は、（最大値）−（フリークエンシー値）の値が所定値（例えば、本実施形態では「１」）以下となる広告データがあるか否かを判定する（ステップＳ４）。つまり、所定期間における広告の残り配信回数が１以下である広告データがあるか否かを判定する。なお、所定値は、「１」に限定されず、「２」や「３」であってもよい。
すなわち、所定値は、配信リクエストを受け付けてから当該配信リクエストに対する広告データを配信してフリークエンシー値を更新するまでの間（更新時間）に、同一の端末装置２０から送信される他の配信リクエストの想定される最大値に基づいて設定される。なお、本実施形態では、ダブルクリック等により、前記更新時間に他の配信リクエストが１つ送信されることを想定している。このため、前記最大値を「１」と想定し、所定値を「１」に設定している。

ステップＳ４において、「Ｙｅｓ」と判定された場合、ロック手段１３４は、ステップＳ２において識別された端末ＩＤに対するロックフラグを「１」にしロック状態にする（ステップＳ５（規制ステップ））。
また、ステップＳ４において、「Ｎｏ」と判定された場合、及びステップＳ５の処理の後、広告配信手段１３２は、取得した配信リクエストの内容（クエリ）に基づいて、広告ＤＢ１２１から広告データを読み込み、クエリに対応した広告データを選定する（ステップＳ６）。
このステップＳ６では、広告配信手段１３２は、配信リクエストのクエリに対応し、かつ、フリークエンシー値が最大値に達していない広告データを選定する。
この際、広告配信手段１３２は、例えば広告ＤＢ１２１等に記憶された広告主の予算や広告配信先の条件等を参照し、配信リクエストの要求元である端末装置２０が配信先として適切かどうかを検証して広告配信の可否を判定する。
なお、サーバ記憶部１２に、端末装置２０のユーザの属性に関するユーザデータ等を例えば端末ＩＤと関連付けて記憶しておくことで、端末装置２０が配信先として適切か否かを判定することが可能となる。また、広告配信回数に応じた金額が、広告主の予算を超える広告データは、配信不可として判定される。
さらに、広告配信手段１３２は、配信リクエストのクエリに対応した広告データを、例えば配信回数やユーザデータ等に基づいてランキング（ソート）し、ランキング上位の広告データを配信対象の広告データをして選定する。なお、このステップＳ６の広告データの選定処理では、通常２００ｍｓの時間を要する。

この後、広告配信手段１３２は、ステップＳ６により選定された配信可能な広告データがあるか否かを判定し（ステップＳ７）、あると判定された場合（「Ｙｅｓ」と判定された場合）は、選定された広告データを、端末装置２０に送信する（ステップＳ８（広告配信ステップ））。

この後、回数更新手段１３３は、ステップＳ２で識別された端末ＩＤに対応し、かつ、ステップＳ６で選定され、ステップＳ８で送信された広告データに対応したフリークエンシー値に「１」を加算して、フリークエンシーＤＢ１２２を更新する（ステップＳ９（回数更新ステップ））。
このステップＳ９の後、及びステップＳ７において「Ｎｏ」と判定された場合、ロック手段１３４は、ステップＳ２で識別された端末ＩＤに対するロックフラグを「０」にする。すなわち、端末ＩＤのリードロックが解除されてアンロック状態となる（ステップＳ１０）。
なお、ロック手段１３４は、ロックフラグが「１」の状態、すなわち、ロック状態が、所定時間以上になった場合、ロックフラグを「０」にして、リードロックを解除する。
［本実施形態の作用効果］

本実施形態では、広告配信サーバ１０のロック手段１３４は、配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制する。
これによれば、ほぼ同一タイミングで複数の配信リクエストが同一の端末装置２０から送信され、最初の配信リクエストに対する広告データの配信によりフリークエンシー値が最大値に達するような場合に、他の配信リクエストに対する広告データが選定されて配信されることを防止できる。これにより、フリークエンシー値の最大値超過を確実に防止できる。

本実施形態では、ロック手段１３４は、受け付けられた配信リクエストに対する広告データの配信先において、残り配信回数が所定値（例えば「１」）以下となる広告データがある場合、当該配信先からの他の配信リクエストに対する広告データの選定を規制する。すなわち、残り配信回数が所定値以下となる広告データがない場合、当該他の配信リクエストに対する広告データの選定は規制されない。
これによれば、残り配信回数が所定値以下となる広告データがなく、フリークエンシー値が最大値を超過する可能性が低い場合には、受信した配信リクエストのすべてに対して広告データが配信されるため、広告データの配信機会が減少することを抑制できる。

本実施形態では、ロック手段１３４は、回数更新手段１３３によるフリークエンシーＤＢ１２２の更新が終了すると、前記他の配信リクエストに対する広告データの選定を許可する。
これによれば、前記他の配信リクエストに対する広告データの選定が規制されている時間を最短にできるため、広告データの配信機会が減少することを抑制できる。

本実施形態では、ロック手段１３４は、受け付けられた配信リクエストに対する広告データの配信が行われない場合、前記他の配信リクエストに対する広告データの選定を許可する。
これによれば、受け付けられた配信リクエストに対する広告データの選定の結果、配信する広告データがなく、配信が行われないような場合に、規制した前記他の配信リクエストに対する広告データの選定を再開できる。

本実施形態では、ロック手段１３４は、前記他の配信リクエストに対する広告データの選定を規制した時間が所定時間以上になった場合、前記他の配信リクエストに対する広告データの選定を許可する。
これによれば、例えば、受け付けられた配信リクエストに対する広告データの配信処理が途中で停止してしまい、フリークエンシーＤＢ１２２が更新されないような場合でも、前記他の配信リクエストに対する広告データの選定を規制した時間が所定時間以上になると、当該選定を再開できる。このため、当該選定が規制された状態が継続され、広告データの配信が実行されなくなる不都合を回避できる。

［変形例］
なお、本発明は、上述した実施形態に限定されるものではなく、本発明の目的を達成できる範囲で、以下に示される変形をも含むものである。

［変形例１］
上記実施形態では、配信先を示すデータとして、端末装置２０を識別する端末ＩＤを示したが、これに限定されない。例えば、配信先となる個々のユーザ毎に割り振られた識別データ（例えばユーザ登録時に登録されるユーザＩＤ等）であってもよい。このようなユーザＩＤを用いる場合では、複数の端末装置２０であっても、それぞれ同一のユーザＩＤを用いて広告データの配信リクエストを送信すると、同一の配信先として判定される。したがって、略同一タイミングで複数の端末装置２０から同一のユーザＩＤを含む配信リクエストが送信された場合でも、２つ目以降の配信リクエストに対してリードロックが掛けられることになる。

［変形例２］
上記実施形態では、端末ＩＤ単位でロックを掛ける処理を実施した。つまり、ロック手段１３４は、同一の端末ＩＤに対して配信リクエストを受け付けないようにロック処理を実施した。これに対して、広告データ単位でロック状態を制御してもよい。例えば、ロック手段１３４は、フリークエンシー値が最大値−１となる広告データのみをリードロックし、その他の広告データに対して読み込み可能などとしてもよい。
つまり、上記実施形態のステップＳ５では、ロック手段１３４は、端末ＩＤに対して配信リクエストの受け付けを制御するようにロック制御を行った。これに対して、ロック手段１３４は、残り配信回数が１回である広告データに対して、次回以降の同一端末ＩＤの配信リクエストがあった際に読み込みができないようにリードロックを掛ける。この場合、ステップＳ３において、Ｙｅｓと判定された場合、ステップＳ６の処理を実施させる。この際、フリークエンシー値が最大値−１となっている広告データは、リードロックが掛かっているため、読み込みができずに選択されない。
このような処理でも、上記実施形態と同様、フリークエンシー値が最大値を超える不都合を防止できる。

［変形例３］
上記実施形態では、フリークエンシー値が最大値−１となった場合（残り配信回数が１以下である場合）に、ロック手段１３４によるロック制御を行ったが、これに限定されない。
例えば、配信リクエストを受け付けてた際、フリークエンシー値に依らずに配信リクエストの受付をロックする（上記変形例２では広告データをリードロックする）構成及び処理としてもよい。

［変形例４］
上記実施形態において、ロック解除のタイミングとしてフリークエンシーＤＢ１２２が更新された後としたが、これに限定されない。例えば、ステップＳ６の広告データの選定時において、フリークエンシー値が「最大値−１」となっている広告データが、ランキング外と判定された時点で、ロックを解除してもよい。

［変形例５］
上記実施形態では、広告配信サーバ１０が配信リクエストを受信した際、受信した配信リクエストの要求元の端末ＩＤに対してリードロックが掛っている場合（ステップＳ３における「Ｙｅｓ」）、当該配信リクエストに対する広告データの配信処理を終了していた。これに対して、リードロックが解除された後に、当該配信リクエストを受け付けて、広告データの配信処理を行ってもよい。

［変形例６］
上記実施形態では、Ｓ４において、広告配信手段１３２は、残り配信回数が所定値以下の広告データがあるか否かを判定していたが、これに限定されない。すなわち、広告配信手段１３２は、残り配信回数が０の広告データを除き、当該残り配信回数が所定値以下の広告データがあるか否かを判定してもよい。

［変形例７］
上記実施形態では、受け付けられた配信リクエストに対する広告データのフリークエンシー値の判定は、広告配信サーバ１０で行われていたが、端末装置で行ってもよい。
この場合、端末装置２０Ａは、図４に示すように、端末通信部２１、表示部２２、入力部２３、端末記憶部２４、端末制御部２５等を含んで構成されている。
端末記憶部２４は、フリークエンシーＤＢ２４１を備えている。すなわち、端末記憶部２４は、本発明の配信回数記憶手段として機能する。また、端末記憶部２４には、端末装置２０Ａの動作を制御するための各種プログラムや各種データが記録されている。
フリークエンシーＤＢ２４１は、本発明の配信関連データであり、各広告に対するフリークエンシー値、及びそのフリークエンシー値の最大値が記録されている。ここで、フリークエンシー値は、端末装置２０Ａが広告データを受信した受信回数である。
端末制御部２５は、ＣＰＵ等の演算回路、ＲＡＭ等の記憶回路により構成され、端末記憶部２４等に記憶されている広告受信プログラム（ソフトウェア）をＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働で、各種処理を実行する。そして、端末制御部２５は、上記各種処理を実行することで、リクエスト受付手段２５１、広告要求手段２５２、広告受信手段２５３、回数更新手段２５４、ロック手段２５５等として機能する。

リクエスト受付手段２５１は、入力された配信リクエストを受け付ける。広告要求手段２５２は、受け付けられた配信リクエストに基づいて広告データを選定し、選定した広告データの配信を広告配信サーバに要求する。広告受信手段２５３は、広告配信サーバから広告データを受信する。回数更新手段２５４は、広告受信手段２５３により広告データが受信された際に、フリークエンシーＤＢ２４１の受信回数を更新する。ロック手段２５５は、配信リクエストが受け付けられると、他の配信リクエストに対する広告データの選定を規制する。また、ロック手段２５５は、ロック解除条件に該当すると、前記他の配信リクエストに対する広告データの選定を許可する。

変形例７では、リクエスト受付手段２５１が配信リクエストを受け付けると、広告要求手段２５２は、受け付けられた配信リクエストに対応し、かつ、受信回数が受信回数の最大値未満の広告データを選定し、選定した広告データの配信を広告配信サーバに要求する。このとき、ロック手段２５５は、他の配信リクエストに対する広告データの選定を規制する。
広告配信サーバは、端末装置２０Ａから広告データの配信要求を受信すると、広告ＤＢから対応する広告データを読み込んで、端末装置２０Ａに送信する。
そして、端末装置２０Ａの広告受信手段２５３が広告配信サーバから広告データを受信すると、回数更新手段２５４は、フリークエンシーＤＢ２４１の受信回数を更新し、ロック手段２５５は、他の配信リクエストに対する広告データの選定を許可する。

変形例７では、ロック手段２５５は、配信リクエストが受け付けられると、他の配信リクエストに対する広告データの選定を規制する。
これによれば、ほぼ同一タイミングで複数の配信リクエストがあり、最初の配信リクエストに対する広告データの受信によりフリークエンシー値が最大値に達するような場合に、他の配信リクエストに対する広告データが選定されて受信されることを防止できる。これにより、フリークエンシー値の最大値超過を確実に防止できる。

その他、本発明の実施の際の具体的な構造および手順は、本発明の目的を達成できる範囲で他の構造などに適宜変更できる。

１…広告配信システム、１０…広告配信サーバ、１１…サーバ通信部、１２…サーバ記憶部、１３…サーバ制御部、１３１…リクエスト受付手段、１３２…広告配信手段、１３３…回数更新手段、１３４…ロック手段、２０…端末装置、１２１…広告ＤＢ、１２２…フリークエンシーＤＢ。

Claims (9)

1. 広告データを記憶する広告記憶手段と、
   前記広告データの配信先毎に、前記広告データを配信した配信回数を記憶する配信回数記憶手段と、
   前記広告データの配信リクエストを受け付けるリクエスト受付手段と、
   受け付けられた配信リクエストに対応し、かつ、前記配信回数が最大値未満の広告データを選定して配信する広告配信手段と、
   前記広告データが配信された際に、前記配信回数を更新する回数更新手段と、
   配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制するロック手段と、を備えた
   ことを特徴とする広告配信サーバ。
2. 請求項１に記載の広告配信サーバにおいて、
   前記ロック手段は、受け付けられた配信リクエストに対する広告データの配信先において、前記最大値から前記配信回数を引いた残り配信回数が所定値以下の広告データがある場合、前記他の配信リクエストに対する広告データの選定を規制する
   ことを特徴とする広告配信サーバ。
3. 請求項１または請求項２に記載の広告配信サーバにおいて、
   前記ロック手段は、前記回数更新手段による前記配信回数の更新が終了すると、前記他の配信リクエストに対する広告データの選定を許可する
   ことを特徴とする広告配信サーバ。
4. 請求項１から請求項３のいずれかに記載の広告配信サーバにおいて、
   前記ロック手段は、受け付けられた配信リクエストに対する広告データの配信が行われない場合、前記他の配信リクエストに対する広告データの選定を許可する
   ことを特徴とする広告配信サーバ。
5. 請求項１から請求項４のいずれかに記載の広告配信サーバにおいて、
   前記ロック手段は、前記他の配信リクエストに対する広告データの選定を規制した時間が所定時間以上になった場合、前記他の配信リクエストに対する広告データの配信を許可する
   ことを特徴とする広告配信サーバ。
6. 広告データを受信した受信回数を記憶する配信回数記憶手段と、
   前記広告データの配信リクエストを受け付けるリクエスト受付手段と、
   受け付けられた配信リクエストに対応し、かつ、前記受信回数が最大値未満の広告データを選定し、選定した広告データの配信を広告配信サーバに要求する広告要求手段と、
   前記広告配信サーバから前記広告データを受信する広告受信手段と、
   前記広告データが受信された際に、前記受信回数を更新する回数更新手段と、
   配信リクエストが受け付けられると、他の配信リクエストに対する広告データの選定を規制するロック手段と、を備えた
   ことを特徴とする端末装置。
7. 広告データを記憶する広告記憶手段と、前記広告データの配信先毎に、前記広告データを配信した配信回数を記憶する配信回数記憶手段と、を備えた広告配信サーバの広告配信方法であって、
   前記広告データの配信リクエストを受け付けるリクエスト受付ステップと、
   受け付けられた配信リクエストに対応し、かつ、前記配信回数が最大値未満の広告データを選定して配信する広告配信ステップと、
   前記広告データが配信された際に、前記配信回数を更新する回数更新ステップと、
   配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する広告データの選定を規制する規制ステップと、を備えた
   ことを特徴とする広告配信方法。
8. コンピュータを、請求項１から請求項５のいずれかに記載した広告配信サーバとして機能させる
   ことを特徴とする広告配信プログラム。
9. コンピュータを、請求項６に記載した端末装置として機能させる
   ことを特徴とする広告受信プログラム。

Images