JP5931940B2 - 配信制御装置、広告配信システム、及び広告配信方法 - Google Patents

Description

本発明は、ネットワーク上の端末装置に広告データを配信する配信制御装置、広告配信システム、及び広告配信方法に関する。

従来、インターネット上の端末装置に広告を配信する広告制御装置が知られている（例えば、特許文献１参照）。
この特許文献１に記載の装置は、同一のユーザに対して同じ広告や同じカテゴリの広告が連続して表示されるのを回避するために、同一の広告を表示させた後、所定の第一時間は同一の広告の配信を許容しないように制御している。

一方、ウェブ上で配信される広告として、例えば、クリック課金型広告等では、同一ユーザに対して広告表示回数を制限する必要がある。この場合、広告制御装置は、各広告データに対して、ユーザ毎に当該広告が配信された回数（フリークエンシー値）と、所定期間において配信可能な最大値（フリークエンシー最大値）とを記憶したフリークエンシーデータベース（フリークエンシーＤＢ）を備え、フリークエンシー値が最大値を超えないように広告の配信を制御すればよい。

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

ところで、広告データを配信する広告配信システムとして、広告データを記憶する複数のデータセンターと、ロードバランサとを備え、複数のデータセンターにおいて記憶される広告データを同期させる構成が知られている。このシステムにおけるロードバランサは、ユーザ端末から広告配信のリクエストを受信すると、そのリクエストをいずれかの１つのデータセンターに送信し、リクエストを受け付けたデータセンターから広告データが配信される。このようなシステムでは、データセンターのいずれかに不都合が発生した場合でも他のデータセンターから広告配信が実施できるため、広告配信の信頼性を向上できる。

このような広告配信システムにおいて、クリック課金型広告等、ユーザ端末に表示させる広告を制限する場合、上記のようなフリークエンシーＤＢを各データセンターに持たせ、データセンター間でフリークエンシーＤＢを同期させることが考えられる。
しかしながら、データセンター間のデータ同期には、一定の時間（例えば１０ｍｓ以上）を要する。したがって、例えば略同一タイミングで同一ユーザから複数のリクエストを受信した場合に、ロードバランサからそれぞれ異なるデータセンターにリクエストが送信される場合がある。この場合、リクエストを受けた１つのデータセンターから広告が配信されて、フリークエンシーＤＢの同期を終了する前に、他のデータセンターからも広告が配信される可能性がある。この場合、フリークエンシー値の最大値を超えて広告が配信されてしまうという課題がある。

本発明は、フリークエンシー値の最大値超過を防止する配信制御装置、広告配信システム、及び広告配信方法を提供することを目的とする。

本発明の配信制御装置は、広告データを記憶する複数のデータサーバのうち、前記広告データを配信させる前記データサーバを選択する配信制御装置であって、当該配信制御装置に通信可能に接続された端末装置から前記広告データの配信リクエストを取得するリクエスト取得手段と、前記配信リクエストが取得されたリクエスト時刻を取得するリクエスト時刻取得手段と、前記リクエスト時刻に基づいて前記複数のデータサーバから前記広告データを配信させるデータサーバを選択し、かつ選択された前記データサーバに前記配信リクエストを送信するサーバ選択手段と、を備えていることを特徴とする。

本発明の配信制御装置は、配信リクエストを受け付けたリクエスト時刻によって、広告配信を実施させるデータサーバを選択して配信リクエストを送信し、コントロールサーバから配信リクエストを取得したデータサーバから配信リクエストに応じた広告データが配信される。このため、略同一タイミングで配信リクエストを取得した場合でも、それらの配信リクエストが異なるデータサーバに配信されて、それぞれのデータサーバから広告が配信されることがなく、リクエスト時刻に応じた所定の１つのデータサーバから広告が配信されることになる。したがって、フリークエンシー値の最大値超過を防止することができる。

本発明の一実施形態に係る広告配信システムの概略構成を示す図。 本実施形態のロードバランサの概略構成を示すブロック図。 本実施形態のデータセンターの概略構成を示すブロック図。 本実施形態における広告配信方法を示すフローチャート。

以下、本発明の一実施形態について、図面に基づいて説明する。
図１は、本実施形態の広告配信システムの概略構成を示す図である。
図１に示すように、本実施形態の広告配信システム１は、本発明の配信制御装置であるロードバランサ１０と、ロードバランサ１０に対して通信可能に接続された本発明のデータサーバであるデータセンター２０（２０Ａ，２０Ｂ）と、ロードバランサ１０に対してネットワーク（例えばインターネット等のＷＡＮ（Wide Area Network））を介して通信可能に接続された端末装置３０とを備えている。
ここで、ロードバランサ１０及びデータセンター２０は、ロードバランサ１０及び端末装置３０と同様に例えばインターネット等のネットワークを介して接続されていてもよく、専用線等により接続されていてもよい。また、同一拠点内にロードバランサ１０及びデータセンター２０が配置されている場合では、例えば有線等によって直接接続されていてもよい。

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

［ロードバランサの構成］
図２は、ロードバランサの概略構成を示すブロック図である。
図２に示すように、ロードバランサ１０は、コンピュータにより構成され、第一通信部１１、第二通信部１２、記憶部１３、及び制御部１４等を含んで構成されている。
第一通信部１１は、例えばＬＡＮ等を介して端末装置３０が接続されるネットワークに接続されており、端末装置３０と通信する。
第二通信部１２は、例えば専用線等を介してデータセンター２０と通信する。
記憶部１３は、例えばメモリ、ハードディスク等により構成されたデータ記録装置である。この記憶部１３には、ロードバランサ１０を制御するための各種プログラムや各種データが記憶されている。

制御部１４は、ＣＰＵ（Central Processing Unit）等の演算回路、ＲＡＭ（Random Access Memory）等の記憶回路により構成され、記憶部１３等に記憶されている配信制御プログラム（ソフトウェア）を読み込んでＲＡＭに展開し、ＲＡＭに展開された配信制御プログラムとの協働で、各種処理を実行する。そして、制御部１４は、上記各種処理を実行することで、図２に示すように、リクエスト取得手段１４１、リクエスト時刻取得手段１４２、本発明のサーバ選択手段であるセンター選択手段１４３、及び広告転送手段１４４等として機能する。

リクエスト取得手段１４１は、端末装置３０から送信された広告の配信リクエストを取得する。
リクエスト時刻取得手段１４２は、リクエスト取得手段１４１により配信リクエストが取得された時刻（リクエスト時刻）を取得する。すなわち、制御部１４は、内部クロック（システムクロック又はハードウェアクロック）により現在時刻を計時し、当該現在時刻は第一通信部１１から取得されるUTC (Universal Time Coordinated)となるように設定されている。リクエスト時刻取得手段１４２は、リクエスト取得手段１４１により配信リクエストを受け付けた際の内部クロックの時刻をリクエスト時刻として取得する。

センター選択手段１４３は、リクエスト時刻の値に応じて、複数（本実施形態では２つ）のデータセンター２０のうちのいずれか一つを選択する。また、センター選択手段１４３は、選択したデータセンター２０に対して、取得した配信リクエストを送信する。
広告転送手段１４４は、データセンター２０から送信された広告データを、配信リクエストを送信した端末装置３０に転送する。
なお、以上の制御部１４の各機能構成についての詳細な説明は後述する。

［データセンターの構成］
図３は、データセンター２０の概略構成を示すブロック図である。
データセンター２０は、コンピュータにより構成され、図３に示すように、センター通信部２１、センター記憶部２２、及びセンター制御部２３等を含んで構成されている。
センター通信部２１は、例えば専用線等を介してロードバランサ１０や、他のデータセンター２０と通信する。
センター記憶部２２は、例えばメモリ、ハードディスク等により構成されたデータ記録装置である。

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

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

表１は、フリークエンシーＤＢ２２２の一例を示す図である。フリークエンシーＤＢ２２２は、本発明の配信回数が記録された配信関連データであり、表１に示すように、端末ＩＤ毎の各広告（広告ＩＤ）に対するフリークエンシー値）、及びそのフリークエンシー値の最大値が記録されている。

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

また、複数のデータセンター２０のセンター記憶部２２において、上記のような広告ＤＢ２２１やフリークエンシーＤＢ２２２は所定のタイミングで同期処理が実施されることで、それぞれ、同一の広告ＤＢ２２１、同一のフリークエンシーＤＢ２２２が記憶されている。

センター制御部２３は、ＣＰＵ等の演算回路、ＲＡＭ等の記憶回路により構成され、センター記憶部２２等に記憶されている広告配信プログラム（ソフトウェア）を読み込んでＲＡＭに展開し、ＲＡＭに展開された広告配信プログラムとの協働で、各種処理を実行する。そして、センター制御部２３は、上記各種処理を実行することで、図３に示すように、リクエスト受付手段２３１、広告配信手段２３２、回数更新手段２３３、ロック手段２３４、及び同期手段２３５として機能する。

リクエスト受付手段２３１は、ロードバランサ１０から送信された配信リクエストを受け付ける。
広告配信手段２３２は、取得した配信リクエストに基づいて、広告ＤＢ２２１から端末装置３０に送信する広告データを抽出して配信する。
回数更新手段２３３は、広告配信手段２３２により広告データが配信された際に、フリークエンシーＤＢ２２２の配信回数を更新する。
ロック手段２３４は、配信リクエストが取得された際に、その配信リクエトを送信した端末装置３０に対して広告データが配信されるまでの間、同一の端末装置３０から送信された他の配信リクエストに対する広告データの配信を制限する。
同期手段２３５は、所定の同期期間において、他のデータセンター２０との間で、フリークエンシーＤＢ２２２を同期させる同期処理を実施する。
なお、各機能構成の詳細な説明については後述する。

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

そして、リクエスト時刻取得手段１４２は、制御部１４によりカウントされている内部クロックを参照し、ステップＳ１において配信リクエストを取得した時点での時刻であるリクエスト時刻を取得する（ステップＳ２）。

次に、センター選択手段１４３は、ステップＳ２で取得したリクエスト時刻に基づき、配信リクエスト及び端末ＩＤを送信するデータセンター２０を選択する（ステップＳ３）。
具体的には、センター選択手段１４３は、下記表２に示すように、配信リクエストの送信先を選択する。

つまり、センター選択手段１４３は、リクエスト時刻の秒数が０秒から２４秒までの間（本発明における第１の広告配信期間）の場合、データセンター２０Ａを選択し、３０秒から５４秒までの間（本発明における第２の広告配信期間）の場合はデータセンター２０Ｂを選択する。また、センター選択手段１４３は、リクエスト時刻の秒数が２５秒から２９秒までの間、及び５５秒から５９秒までの間（本発明の更新期間）の場合、どちらのデータセンター２０をも選択しない。

この後、センター選択手段１４３は、ステップＳ３において、データセンター２０が選択されたか否かを判定する（ステップＳ４）。
ステップＳ４において、「Ｙｅｓ」と判定された場合（データセンター２０Ａ又はデータセンター２０Ｂが選択されている場合）は、選択されたデータセンター２０に対して配信リクエスト及び端末ＩＤを送信する（ステップＳ５）。
また、ステップＳ４において、「Ｎｏ」と判定された場合は、配信リクエストの送信は実施しない。つまり、時刻秒数が２５秒から２９秒までの間、及び５５秒から５９秒までの間では、データセンター２０間で、フリークエンシーＤＢ２２２の同期処理が実施される。このため、ロードバランサ１０は、この同期処理が実施される同期期間（２５〜２９秒、５５〜５９秒）の間に配信リクエストを受信した場合は、配信リクエストの送信処理を実施しない。
なお、同期処理の詳細は後述する。

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

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

また、ステップＳ８において「Ｎｏ」と判定された場合は、フリークエンシーＤＢ２２２から、ステップＳ７で識別された端末ＩＤに対応する各広告のフリークエンシー値及びその最大値を読み込む。
そして、広告配信手段２３２は、（最大値）−（フリークエンシー値）の値が所定値（例えば、本実施形態では「１」）以下となる広告データがあるか否かを判定する（ステップＳ９）。つまり、所定期間における広告の残り配信回数が１以下である広告データがあるか否かを判定する。

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

この後、広告配信手段２３２は、ステップＳ１１により選択された配信可能な広告データがあるか否かを判定し（ステップＳ１２）、あると判定された場合（「Ｙｅｓ」と判定された場合）は、選定された広告データをロードバランサ１０に送信する（ステップＳ１３）。

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

一方、ロードバランサ１０は、データセンター２０から広告データ及び端末ＩＤを取得したか否かを判定する（ステップＳ１６）。
ステップＳ１５で「Ｙｅｓ」と判定された場合は、広告転送手段１４４は、取得した端末ＩＤに対応する端末装置３０に取得した広告データを送信する（ステップＳ１７）。

［データセンター間における同期処理］
上述したように、ステップＳ３において、リクエスト時刻が２５〜２９秒、５５〜５９秒である場合、センター選択手段１４３は、いずれのデータセンター２０をも配信リクエストの送信先に選択しない。この期間は、本発明の更新期間であり、データセンター間でフリークエンシーＤＢ２２２の同期処理が実施される。

具体的には、フリークエンシーＤＢ２２２が更新されたデータセンター２０の同期手段２３５は、センター制御部２３においてカウントされている内部クロックの現在時刻（ロードバランサ１０や他のデータセンター２０と同期されている）を参照し、上記同期期間（２５〜２９秒、５５〜５９秒）になると、他のデータセンター２０に対してフリークエンシーＤＢ２２２を送信する。
例えば、表２の例では、データセンター２０Ａの同期手段２３５は、現在時刻が２５〜２９秒になると、データセンター２０Ｂに対してフリークエンシーＤＢ２２２を送信する。データセンター２０Ｂの同期手段２３５は、データセンター２０ＡからフリークエンシーＤＢ２２２を受信すると、センター記憶部２２に記憶されたフリークエンシーＤＢ２２２を受信したデータに置き換える（更新する）。
同様に、データセンター２０Ｂの同期手段２３５は、現在時刻が５５〜５９秒になると、データセンター２０Ａに対してフリークエンシーＤＢ２２２を送信し、データセンター２０Ａの同期手段２３５は受信したフリークエンシーＤＢ２２２により、既存のデータを更新する。

なお、本実施形態では、各データセンター２０が、センター制御部２３の内部クロックを参照することで同期処理を実施する例を示すが、これに限らない。例えば、ロードバランサ１０が上記同期期間になると、所定のデータセンター２０に同期指令を送信するなどとしてもよい。この場合、同期指令を受けたデータセンター２０が他のデータセンター２０にフリークエンシーＤＢ２２２を送信して同期させる。
また、フリークエンシーＤＢ２２２に加えて、広告ＤＢ２２１の同期も同時に実施してもよい。

［本実施形態の作用効果］
本実施形態における広告配信システム１におけるロードバランサ１０は、リクエスト取得手段１４１により端末装置３０から配信リクエストを取得すると、リクエスト時刻取得手段１４２により、配信リクエストを受信したリクエスト時刻を取得する。そして、センター選択手段１４３は、リクエスト時刻に基づいて、複数のデータセンター２０のうち、広告データを配信させるデータセンター２０を選択して、選択したデータセンター２０に配信リクエストを送信する。
また、配信リクエストの送信先となったデータセンター２０は、リクエスト受付手段２３１により配信リクエストを受信すると、広告配信手段２３２は、その配信リクエストに対応した広告データを選定してロードバランサ１０を介して端末装置３０に送信する。
上記のようなロードバランサ１０及び広告配信システム１では、ほぼ同一タイミングで同一の端末装置３０から配信リクエストが送信された場合に、ロードバランサ１０から異なるデータセンター２０に配信リクエストが送信されず、１つのデータセンター２０に配信リクエストを送信することになる。このため、データセンター２０間でフリークエンシーＤＢ２２２の同期が取られる前に同一の広告データが送信されることがなく、フリークエンシー値が最大値を超過してしまう不都合を回避できる。

本実施形態では、センター選択手段１４３は、リクエスト時刻の末尾の秒数に基づいてデータセンターを選択する。
例えば、リクエスト時刻の時分数でデータセンター２０を選択すると、１つのデータセンター２０に負荷が集中する。これに対して、秒数でデータセンター２０を選択することで、データセンター２０の付加を適度に分散させることができる。
また、本実施形態のように、データセンター２０間の同期処理を時刻の秒数で設定することで、同期期間を短くでき、同期処理による広告配信処理の妨げを抑制できる。つまり、リクエスト時刻の分の値に基づいて、例えば０〜２９分をデータセンター２０Ａの選択、２９〜３０分を同期期間、３０〜５９分をデータセンター２０Ｂの選択、５９〜００分を同期期間として設定すると、同期期間が１分と長くなり、この間に取得した配信リクエストに対して広告データを配信できなくなる。これに対して、秒数に基づいて同期期間を設定することで、例えば上記実施形態では、５秒の間のみ同期期間を設定すればよく、広告配信を妨げない。

本実施形態では、データセンター２０のセンター記憶部２２には、各端末ＩＤに対応して、広告データの配信回数であるフリークエンシー値と、その最大値とを関連付けたフリークエンシーＤＢ２２２が記憶されている。そして、回数更新手段２３３は、広告データが配信された際にフリークエンシー値を加算して更新し、広告配信手段２３２は、フリークエンシー値が最大値となった広告データを配信対象として選択せず、最大値未満の広告データを配信対象に選択する。
このため、フリークエンシー値が最大値に達した広告データは配信対象とならず、フリークエンシー値が最大値を超えることがない。したがって、特定の広告データの掲示頻度が過剰に高くなる不都合を回避できる。
また、クリック課金型広告等においては、所定時間において広告の配信可能数が制限される。さらに、上記のように、ロードバランサ１０により、リクエスト時刻によるデータセンター２０の選択が実施されることで、フリークエンシー値の最大値超過も防止している。したがって、同一ユーザに対して同一の広告が複数回配信されることによる広告主の不利益をより確実に抑制できる。

本実施形態では、データセンター２０は、同期手段２３５を有し、広告配信処理によりフリークエンシーＤＢ２２２が更新されたデータセンター２０は、他のデータセンター２０に対して、当該更新されたフリークエンシーＤＢ２２２を送信して同期させる。
これにより、全てのデータセンター２０において、同じフリークエンシーＤＢ２２２が共有されることになる。

この際、上記のように、リクエスト時刻に基づいて、広告データの配信対象となるデータセンター２０が選択され、そのデータセンター２０による広告配信期間の直後に同期期間を設定している。このため、広告配信処理によりフリークエンシーＤＢ２２２が更新されているのは、選択されたデータセンター２０のみであり、同期処理において、容易かつ確実にデータ整合性を合わせることができる。

本実施形態では、データセンター２０のロック手段２３４は、配信リクエストが受け付けられた際に、回数更新手段２３３によるフリークエンシーＤＢ２２２の更新が終了するまでの間、同一端末ＩＤからの次の配信リクエストを規制する。つまり、同一端末ＩＤに対して、先に受けた配信リクエストに対する広告の配信が終了してフリークエンシーＤＢ２２２が更新されるまでの間、次に受けた配信リクエストに対する広告データの読み込み、抽出、及び配信処理がロック状態となる。
このため、ほぼ同一タイミングで複数の配信リクエストが端末装置３０からロードバランサ１０に送信され、それらの複数の配信リクエストが同一のデータセンター２０で受け付けられた場合に、フリークエンシーＤＢ２２２が更新される前に、次に配信リクエストに対する広告配信処理がロックされることになり、フリークエンシー値が最大値を超える不都合を防止できる。特に、ステップＳ１１における広告データの選定処理は処理負荷がかかるので処理時間として２００ｍｓを要するが、本実施形態では、この間に他の配信リクエストが受け付けられた場合でも、その配信リクエストが受け付けられないため、当該他の配信リクエストの対する広告データの読み込みがロックされ、フリークエンシー値が最大値を超過する不都合を確実に回避できる。

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

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

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

［変形例３］
上記実施形態では、データセンター２０の広告配信手段２３２は、ロードバランサ１０を介して端末装置３０に広告データを配信したが、例えばデータセンター２０からネットワークを介して直接端末装置３０に広告データが配信されてもよい。

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

［変形例５］
上記実施形態では、センター選択手段１４３は、リクエスト時刻の秒数に基づいて、データセンター２０の選択を実施したが、これに限定されない。
例えば、リクエスト時刻の分や時の値に基づいてデータセンターを選択してもよい。この場合、広告配信期間の切り替わり時に例えば５秒間の同期期間を設定する等してもよい。例えば、分の値が奇数（１分、３分、５分・・・）では、データセンター２０Ａを選択し、分の値が偶数（２分、４分、６分・・・）では、データセンター２０Ｂを選択する。
この際、各分の０秒から５秒までの間を同期期間として、データセンター２０間での同期処理を実施し、各データセンター２０において、当該期間において受信した配信リクエストは、同期処理後に広告配信処理を実施してもよい。

［変形例６］
上記実施形態では、ロードバランサ１０は、同期期間内に配信リクエストを取得した場合、当該配信リクエストをデータセンター２０に送信しなかったが、これに限定されない。例えば、ロードバランサ１０は、取得した配信リクエストを同期期間終了まで保持し、広告配信期間になった際に、データセンター２０を選択して配信リクエストを送信してもよい。この場合、端末装置３０において広告の提示機会が失われることがなく、より適正な広告配信を実施できる。

［変形例７］
上記実施形態において、ロック解除のタイミングとしてフリークエンシーＤＢ２２２が更新された後としたが、これに限定されない。例えば、配信リクエストを受け付けた後、予め設定された時間が経過した後に、ロック状態が続いている場合にロックを解除してもよい。
また、ステップＳ１１の広告データの選定時において、フリークエンシー値が（最大値−１）となっている広告データが、ランキング外と判定された時点で、ロックを解除してもよい。

［変形例８］
上記実施形態では、データセンター２０は、所定端末ＩＤの端末装置３０からの配信リクエストを受信した際に、その配信リクエストに対する広告データが配信されてフリークエンシーＤＢ２２２が更新されるまでの間、当該端末ＩＤに対する広告データのリードをロックしたが、これに限定されない。
例えば、データセンター２０は、上記のような端末ＩＤ毎にロック制御を実施しない従来のデータセンター（例えば、上述した特許文献１の装置）を用いてもよい。この場合でも、ロードバランサ１０のセンター選択手段１４３により、配信リクエストを送信するデータセンターの選択を実施することで、複数のデータセンターに対して配信リクエストが送信されることによるフリークエンシー値の超過は防止することができる。

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

１…広告配信システム、１０…ロードバランサ（配信制御装置）、１３…記憶部、１４…制御部、２０…データセンター（データサーバ）、２０Ａ…データセンター（第１のデータサーバ）、２０Ｂ…データセンター（第２のデータサーバ）、２２…センター記憶部、２３…センター制御部、３０…端末装置、１４１…リクエスト取得手段、１４２…リクエスト時刻取得手段、１４３…センター選択手段（サーバ選択手段）、１４４…広告転送手段、２３１…リクエスト受付手段、２３２…広告配信手段、２３３…回数更新手段、２３４…ロック手段、２３５…同期手段、２２１…広告ＤＢ、２２２…フリークエンシーＤＢ。

Claims (8)

1. 広告データと広告データを配信した配信回数とを記憶し、前記広告データを配信した際に前記配信回数を更新する複数のデータサーバのうち、前記広告データを配信させる前記データサーバを選択する配信制御装置であって、
   当該配信制御装置に通信可能に接続された端末装置から前記広告データの配信リクエストを取得するリクエスト取得手段と、
   前記配信リクエストが取得されたリクエスト時刻を取得するリクエスト時刻取得手段と、
   前記リクエスト時刻に基づいて前記複数のデータサーバから前記広告データを配信させるデータサーバを選択し、かつ選択された前記データサーバに前記配信リクエストを送信するサーバ選択手段と、
   現在時刻が予め設定された更新期間である場合に、他の前記データサーバとの間で、前記配信回数の同期処理を実施する同期手段と、を備え、
   前記サーバ選択手段は、前記リクエスト時刻が予め設定された更新期間である場合に、前記データサーバを選択せず、前記更新期間の終了時点から次に設定された更新期間の開始時点までの間の広告配信期間において、前記データサーバを選択する
   ことを特徴とする配信制御装置。
2. 請求項１に記載の配信制御装置において、
   前記サーバ選択手段は、前記リクエスト時刻における末尾秒数に基づいて前記データサーバを選択する
   ことを特徴とする配信制御装置。
3. 請求項１又は請求項２に記載の配信制御装置において、
   前記サーバ選択手段は、前記リクエスト時刻が第１の前記広告配信期間に属する場合、前記複数のデータサーバのうち第１のデータサーバを選択し、前記リクエスト時刻が、前記第１の広告配信期間の次の前記広告配信期間である第２の広告配信期間に属する場合、前記第１のデータサーバとは異なる第２のデータサーバを選択し、
   前記更新期間は、前記第１の広告配信期間及び前記第２の広告配信期間の間に設けられる
   ことを特徴とする配信制御装置。
4. 請求項１から請求項３のいずれかに記載の配信制御装置と、前記配信制御装置に通信可能に接続され、前記広告データを記憶する複数のデータサーバと、を具備した配信システムであって、
   前記データサーバは、
   前記広告データを記憶する広告記憶手段と、
   前記配信制御装置から前記配信リクエストを受け付けるリクエスト受付手段と、
   受け付けた前記配信リクエストに対応した前記広告データを抽出して配信する広告配信手段と、を備え、
   複数の前記データサーバ間で前記広告データが定期的に同期されている
   ことを特徴とする広告配信システム。
5. 請求項４に記載の広告配信システムにおいて、
   前記データサーバは、
   前記広告データを配信した配信回数を記憶する配信回数記憶手段と、
   前記広告データが配信された際に、前記配信回数を更新する回数更新手段と、を備え、
   前記広告配信手段は、前記配信回数が所定の最大値未満の前記広告データを抽出する
   ことを特徴とする広告配信システム。
6. 請求項５に記載の広告配信システムにおいて、
   前記データサーバは、
   前記配信リクエストが受け付けられると、当該配信リクエストに対する広告データの配信先からの他の配信リクエストに対する前記広告データの配信を規制するロック手段を備えている
   ことを特徴とする広告配信システム。
7. データサーバと配信制御装置とが通信可能に接続された配信制御システムであって、
   前記配信制御装置は、
   当該配信制御装置に通信可能に接続された端末装置から広告データの配信リクエストを取得するリクエスト取得手段と、
   前記配信リクエストが取得されたリクエスト時刻を取得するリクエスト時刻取得手段と、
   前記リクエスト時刻に基づいて複数の前記データサーバから前記広告データを配信させるデータサーバを選択し、かつ選択された前記データサーバに前記配信リクエストを送信するサーバ選択手段と、を備え、
   前記データサーバは、
   前記広告データを記憶する広告記憶手段と、
   前記配信制御装置から前記配信リクエストを受け付けるリクエスト受付手段と、
   受け付けた前記配信リクエストに対応した前記広告データを抽出して配信する広告配信手段と、
   前記広告データを配信した配信回数を記憶する配信回数記憶手段と、
   前記広告データが配信された際に、前記配信回数を更新する回数更新手段と、
   現在時刻が予め設定された更新期間である場合に、他の前記データサーバとの間で、前記配信回数の同期処理を実施する同期手段と、を備え、
   複数の前記データサーバ間で前記広告データが定期的に同期されており、
   前記サーバ選択手段は、前記リクエスト時刻が前記更新期間である場合に、前記データサーバを選択せず、前記更新期間の終了時点から次に設定された更新期間の開始時点までの間の広告配信期間において、前記データサーバを選択し、
   前記広告配信手段は、前記配信回数が所定の最大値未満の前記広告データを抽出する
   ことを特徴とする広告配信システム。
8. コンピュータにより、広告データと広告データを配信した配信回数とを記憶し、前記広告データを配信した際に前記配信回数を更新する複数のデータサーバから前記広告データを配信させる前記データサーバを選択する配信制御方法であって、
   前記コンピュータは、
   通信接続された端末装置から前記広告データの配信リクエストを取得し、
   前記配信リクエストを取得したリクエスト時刻を取得し、
   現在時刻が予め設定された更新期間である場合に、他の前記データサーバとの間で、前記配信回数の同期処理を実施し、
   前記リクエスト時刻に基づいて、前記リクエスト時刻が予め設定された更新期間である場合に、前記データサーバを選択せず、前記更新期間の終了時点から次に設定された更新期間の開始時点までの間の広告配信期間において、前記複数のデータサーバから前記広告データを配信させるデータサーバを選択し、かつ選択された前記データサーバに前記配信リクエストを送信する
   ことを特徴とする広告配信方法。

Images