JP6501653B2 - 広告配信管理システム、広告配信管理方法、及び振分プログラム - Google Patents

Description

本発明は、広告配信管理システム、広告配信管理方法、及び振分プログラムに関する。

近年、インターネットの飛躍的な普及に伴い、インターネットを介した広告配信が盛んに行われている。例えば、広告媒体（例えば、ウェブページ）に設定された広告枠に、企業や商品等の広告コンテンツを表示し、かかる広告コンテンツがクリックされた場合に広告主のウェブページへ遷移させる広告配信が行われている。

従来、未消化の広告予算を減少させ、広告予算を消化する可能性を高める技術が提供されている。例えば、所定の配信元（例えば、アドネットワーク）にＰＰＣ（Pay Per Click）広告に予算の制約がある場合、時間帯毎のインプレッションやＣＴＲ（Click Through Rate）を考慮して、時間帯毎の予算消化額を決定して、日額予算を消化させる。

特開２０１４−１８２４４７号公報

しかしながら、上記の従来技術では、通信負荷を抑制し、広告の配信元を適切に選択することができるとは限らない。例えば、広告配信のリクエストを受け付ける広告配信を行わせる配信元を決定する振分サーバが複数ある場合、管理サーバが各振分サーバから配信実績を随時取得して集計した後、各振分サーバに配信元の選択に関する情報を送信すると通信負荷が高くなってしまう。このような場合、通信負荷を抑制し、広告の配信元を適切に選択することが難しい。

本願は、上記に鑑みてなされたものであって、通信負荷を抑制し、広告の配信元を適切に選択することができる広告配信管理システム、広告配信管理方法、及び振分プログラムを提供することを目的とする。

本願に係る広告配信管理システムは、広告配信を要求するリクエストに応じて複数の配信元から広告配信を行わせる配信元を決定する複数の振分サーバと、前記複数の振分サーバを管理する管理サーバと、を有する広告配信管理システムであって、前記管理サーバは、所定の期間内において前記複数の配信元のうち所定の配信元に行わせる広告配信の計画に関する配信計画情報を各振分サーバに送信する送信部、を備え、前記各振分サーバは、前記リクエストを受け付ける受付部と、前記受付部により前記リクエストを受け付けた場合、前記リクエストに対して各配信元により広告が配信された場合に想定される広告の評価値に基づいて算出される値と、前記配信計画情報から得られる閾値とに応じて、前記複数の配信元から前記リクエストに対する広告配信を行う配信元を決定する決定部と、前記各振分サーバが受け付けたリクエストに対する前記所定の配信元による広告配信の進捗に基づいて前記閾値を更新する更新部と、を備えたことを特徴とする。

実施形態の一態様によれば、通信負荷を抑制し、広告の配信元を適切に選択することができるという効果を奏する。

図１は、実施形態に係る広告配信管理処理の一例を示す図である。 図２は、実施形態に係る管理サーバの構成例を示す図である。 図３は、実施形態に係るリクエスト情報記憶部の一例を示す図である。 図４は、実施形態に係る配信元情報記憶部の一例を示す図である。 図５は、実施形態に係る第１評価値に基づくリクエストの分布の一例を示す図である。 図６は、実施形態に係る第２評価値に基づくリクエストの分布の一例を示す図である。 図７は、実施形態に係る配信スケジュールの一例を示す図である。 図８は、実施形態に係る個別配信スケジュールの一例を示す図である。 図９は、実施形態に係る第２評価値に基づくリクエストの分布の一例を示す図である。 図１０は、実施形態に係る振分サーバの構成例を示す図である。 図１１は、実施形態に係るリクエスト情報記憶部の一例を示す図である。 図１２は、実施形態に係る配信計画情報記憶部の一例を示す図である。 図１３は、実施形態に係る第２評価値の算出の一例を示す図である。 図１４は、実施形態に係る閾値と第２評価値との関係の一例を示す図である。 図１５は、実施形態に係る個別配信スケジュールと配信実績との関係の一例を示す図である。 図１６は、実施形態に係る更新された閾値と第２評価値との関係の一例を示す図である。 図１７は、実施形態に係る個別配信スケジュールと配信実績との関係の一例を示す図である。 図１８は、実施形態に係る更新された閾値と第２評価値との関係の一例を示す図である。 図１９は、変形例に係るフィードバック処理の一例を示す図である。 図２０は、変形例に係る個別配信スケジュールの一例を示す図である。 図２１は、変形例に係る閾値の変動の一例を示す図である。 図２２は、変形例に係る第１評価値に基づくリクエストの分布の一例を示す図である。 図２３は、変形例に係る第２評価値の算出の一例を示す図である。 図２４は、変形例に係る第２評価値に基づくリクエストの分布の一例を示す図である。 図２５は、変形例に係る第２評価値の算出の一例を示す図である。 図２６は、変形例に係る評価ベクトルの一例を示す図である。 図２７は、変形例に係る第１評価値に基づくリクエストの分布に基づく第２評価値の算出の一例を示す図である。 図２８は、変形例に係る個別配信スケジュールの一例を示す図である。 図２９は、変形例に係る閾値の変動の一例を示す図である。 図３０は、変形例に係る配信情報の非累積表示の一例を示す図である。 図３１は、変形例に係る配信情報の累積表示の一例を示す図である。 図３２は、変形例に係る配信情報の閾値表示の一例を示す図である。 図３３は、管理サーバ及び振分サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る広告配信管理システム、広告配信管理方法、及び振分プログラムを実現するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る広告配信管理システム、広告配信管理方法、及び振分プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する記載は省略される。

〔１．広告配信管理処理〕
まず、実施形態に係る広告配信管理処理について説明する。図１は、実施形態に係る広告配信管理処理の一例を示す図である。なお、以下においては、広告媒体の一例としてウェブページを説明するが、広告媒体は、ウェブページ以外の広告媒体であってもよい。例えば、広告媒体は、ゲームアプリケーション、書籍閲覧アプリケーション、音楽配信アプリケーション、動画配信アプリケーションによって表示される媒体などであってもよい。

図１に示すように、実施形態に係る広告配信管理システム１は、複数の端末装置１０Ａ、１０Ｂと、ウェブサーバ２０と、管理サーバ１００と、複数の振分サーバ２００Ａ、２００Ｂと、複数の広告配信装置ＡＮ１、ＡＮ２とを有し、これらの装置は、所定のネットワークを介して通信可能に接続される。以下では、端末装置１０Ａ、１０Ｂについて、特に区別なく説明する場合には、端末装置１０と記載し、振分サーバ２００Ａ、２００Ｂについて、特に区別なく説明する場合には、振分サーバ２００と記載する。なお、図１に示した広告配信管理システム１には、３つ以上の端末装置１０、複数の管理サーバ１００、３つ以上の振分サーバ２００、３つ以上の広告配信装置が含まれてもよい。

端末装置１０は、ユーザによって利用される情報処理装置である。端末装置１０は、例えば、ブラウザアプリケーション（以下、ブラウザと記載する）がインストールされている。図１においては、端末装置１０がスマートフォンである場合を例示する。なお、端末装置１０は、例えば、タブレット型端末や、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等であってもよい。

ウェブサーバ２０は、広告枠が設定された複数のウェブページを記憶している。ウェブサーバ２０は、端末装置１０のブラウザからのアクセスがあると、端末装置１０によって指定されたＵＲＬ（Uniform Resource Locator）に対応するウェブページを提供する。

端末装置１０のブラウザは、ウェブサーバ２０からウェブページを受信すると、ウェブページに設定された広告枠に対応する広告リクエスト（以下、単に「リクエスト」と称する場合がある）を振分サーバ２００へ送信する。リクエストは、広告枠に表示する広告コンテンツの配信要求であり、例えば、端末装置１０のユーザＵの識別情報（以下、ユーザＩＤと記載する）や広告枠の識別情報（以下、広告枠ＩＤと記載する）を含む。ユーザＩＤは、例えば、ＨＴＴＰクッキー（HyperText Transfer Protocol Cookie：以下、クッキーと記載する）である。かかるクッキーには、ユーザＩＤ以外に端末装置１０を所有するユーザの年齢、性別などのユーザ情報を含んでもよい。例えば、端末装置１０Ａから振分サーバ２００へ送信されるクッキーには、ユーザＵ１の年齢、性別などのユーザ情報を含んでもよく、端末装置１０Ｂから振分サーバ２００へ送信されるクッキーには、ユーザＵ２の年齢、性別などのユーザ情報を含んでもよい。

振分サーバ２００は、広告リクエストに対応する広告コンテンツを広告配信装置ＡＮ１、ＡＮ２のいずれかから配信させる。広告配信装置ＡＮ１、ＡＮ２は、広告の配信元であり、例えば所定のアドネットワークである。広告配信装置ＡＮ１、ＡＮ２は、振分サーバ２００からの広告配信の要求があった場合、広告配信を行う。例えば、振分サーバ２００は、媒体社により管理および運用される。また、例えば、広告配信装置ＡＮ１、ＡＮ２は、各々の広告配信業者により管理および運用される。

管理サーバ１００は、振分サーバ２００を管理する情報処理装置である。例えば、管理サーバ１００は、所定の期間（以下、「第１期間」と称する場合がある）内において複数の配信元である広告配信装置ＡＮ１、ＡＮ２のうち所定の配信元に行わせる広告配信の計画に関する配信計画情報を、各振分サーバ２００に送信する。以下に示す例においては、管理サーバ１００は、広告配信装置ＡＮ２に行わせる広告配信の計画に関する配信計画情報を、各振分サーバ２００に送信する。なお、配信計画情報の詳細については後述する。また、例えば、管理サーバ１００は、媒体社により管理および運用される。例えば、管理サーバ１００及び振分サーバ２００は、同じ媒体社により管理および運用され、ＳＳＰ（Supply-Side Platform）等と称される場合がある。以下、図１の例を基に広告配信管理処理について説明する。

図１に示すように、管理サーバ１００は、振分サーバ２００に配信計画情報を送信する（ステップＳ１）。例えば、管理サーバ１００は、広告配信装置ＡＮ２にリクエストに対する広告配信を行わせるかを決定するための閾値や第１期間内に広告配信装置ＡＮ２に広告配信を行わせるリクエスト数等の情報を含む配信計画情報を振分サーバ２００に送信する。また、図１に示す例において、配信計画情報は、配信スケジュール、例えば第１期間内における所定の時刻において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数の情報を含む。管理サーバ１００から配信計画情報を受け付けた振分サーバ２００は、配信計画情報に含まれる閾値と、受け付けたリクエストについて算出した第２評価値とに基づいて、リクエストに対する広告配信を行う配信元を決定する。なお、第２評価値は、受け付けたリクエストに対して各広告配信装置により広告が配信された場合に想定される広告の評価値（以下、「第１評価値」とする）に基づいて算出されるが、詳細は後述する。なお、以下では、振分サーバ２００がリクエストに対して広告配信を行う配信元を決定する処理を、振分処理と称する場合がある。

図１に示すように、ウェブサーバ２０は、端末装置１０Ａから送信されたページ要求（ステップＳ２）を受け付けると、ページ要求に応じたウェブページ１１を端末装置１０Ａへ送信する（ステップＳ３）。例えば、ウェブサーバ２０は、複数のウェブページ１１を記憶しており、ウェブページ１１には広告枠１２が設定される。

ウェブサーバ２０から広告枠１２を含むウェブページ１１を受信した場合、端末装置１０Ａは、広告リクエストを振分サーバ２００Ｂへ送信する（ステップＳ４）。例えば、広告リクエストは、ウェブページ１１に設定された広告枠１２に表示する広告コンテンツの配信要求である。なお、端末装置１０からの広告リクエストの送信先である振分サーバ２００は、所定の基準により適宜決定される。

端末装置１０Ａから広告リクエストを受け付けた場合、振分サーバ２００Ｂは、広告配信装置ＡＮ１、ＡＮ２から広告配信の要求先を決定し、受け付けた広告リクエストに対して広告配信を行う配信元を決定する。具体的には、振分サーバ２００Ｂは、配信計画情報に含まれる閾値と、受け付けた広告リクエストについて算出した第２評価値とに基づいて広告リクエストに対して広告配信を行う配信元を決定する。広告の配信元を決定した後、振分サーバ２００Ｂは、広告配信の要求先として決定された配信元に対して広告の配信要求を送信する（ステップＳ５）。図１に示す例においては、振分サーバ２００Ｂは、広告配信の要求先として決定された広告配信装置ＡＮ２に対して広告の配信要求を送信する。

振分サーバ２００Ｂから広告の配信要求を受け付けた広告配信装置ＡＮ２は、端末装置１０Ａへ配信する広告コンテンツを抽出し、振分サーバ２００Ｂへ送信する（ステップＳ６）。広告配信装置ＡＮ２から広告コンテンツを受け付けた振分サーバ２００Ｂは、端末装置１０Ａへ広告配信装置ＡＮ２から受け付けた広告コンテンツを送信する（ステップＳ７）。その後、端末装置１０Ａは、振分サーバ２００Ｂから送信された広告コンテンツを広告枠１２に表示する。なお、広告配信装置ＡＮ２は、振分サーバ２００Ｂを経由せずに、端末装置１０Ａへ直接広告コンテンツを送信してもよい。

管理サーバ１００から受け付けた配信計画情報に基づいて振分処理を開始した時点（以下、「開始時点」と称する場合がある）から第１期間よりも短い期間（以下、「第２期間」と称する場合がある）が経過した後、各振分サーバ２００は、各振分サーバ２００が受け付けたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新する。具体的には、振分サーバ２００Ａは、開始時点から第２期間が経過した後、振分サーバ２００Ａが受け付けたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新する（ステップＳ８）。また、振分サーバ２００Ｂは、開始時点から第２期間が経過した後、振分サーバ２００Ｂが受け付けたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新する（ステップＳ９）。ここに、振分サーバ２００Ａ、２００Ｂは、各振分サーバ２００が受け付けたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値が変動する。例えば、ステップＳ８及びＳ９における閾値更新により、振分サーバ２００Ａ、２００Ｂは、異なる値の閾値に基づいて振分処理を行う。

図１に示すように、ウェブサーバ２０は、端末装置１０Ｂから送信されたページ要求（ステップＳ１０）を受け付けると、ページ要求に応じたウェブページ１１を端末装置１０Ｂへ送信する（ステップＳ１１）。ウェブサーバ２０から広告枠１２を含むウェブページ１１を受信した場合、端末装置１０Ｂは、広告リクエストを振分サーバ２００Ｂへ送信する（ステップＳ１２）。

端末装置１０Ｂから広告リクエストを受け付けた場合、振分サーバ２００Ｂは、広告配信装置ＡＮ１、ＡＮ２から広告配信の要求先を決定し、受け付けた広告リクエストに対して広告配信を行う配信元を決定する。広告の配信元を決定した後、振分サーバ２００Ｂは、広告配信の要求先として決定された配信元に対して広告の配信要求を送信する（ステップＳ１３）。図１に示す例においては、振分サーバ２００Ｂは、広告配信の要求先として決定された広告配信装置ＡＮ１に対して広告の配信要求を送信する。

振分サーバ２００Ｂから広告の配信要求を受け付けた広告配信装置ＡＮ１は、端末装置１０Ｂへ配信する広告コンテンツを抽出し、振分サーバ２００Ｂへ送信する（ステップＳ１４）。広告配信装置ＡＮ１から広告コンテンツを受け付けた振分サーバ２００Ｂは、端末装置１０Ｂへ広告配信装置ＡＮ１から受け付けた広告コンテンツを送信する（ステップＳ１５）。その後、端末装置１０Ｂは、振分サーバ２００Ｂから送信された広告コンテンツを広告枠１２に表示する。なお、広告配信装置ＡＮ１は、振分サーバ２００Ｂを経由せずに、端末装置１０Ｂへ直接広告コンテンツを送信してもよい。

これにより、実施形態に係る広告配信管理システム１は、通信負荷を抑制することができる。具体的には、広告配信管理システム１において、複数の振分サーバ２００は、管理サーバ１００から配信計画情報を受け付けた後、各々自律して配信処理を行う。例えば、各振分サーバ２００は、各々が受け付けたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新し、振分処理を行う。すなわち、各振分サーバ２００は、開始時点から第１期間が経過するまでの間、管理サーバ１００との間において通信を行うことなく、振分処理を行うことが可能となる。したがって、広告配信管理システム１は、管理サーバ１００と各振分サーバ２００との間の通信負荷を抑制することができる。また、各振分サーバ２００は、各自の進捗に応じて閾値を変動させて振分処理を行うため、管理サーバ１００と各振分サーバ２００との間で通信を行うことなく、開始時点から第１期間が経過するまでの間、広告の配信元を適切に選択することができる。

なお、上記例においては、管理サーバ１００がステップＳ１において振分サーバ２００に配信計画情報を送信する場合を示したが、管理サーバ１００は、異なるタイミングで振分サーバ２００Ａ、２００Ｂに配信計画情報を送信してもよい。また、管理サーバ１００がステップＳ１において振分サーバ２００に配信計画情報を送信する場合を示したが、管理サーバ１００は、各振分サーバ２００の処理能力や受け付けるリクエストの分布等に応じて異なる内容の配信計画情報を振分サーバ２００Ａ、２００Ｂに送信してもよい。また、振分サーバ２００は、開始時点から第２期間が経過した時点からさらに第２期間が経過した後、振分サーバ２００が受け付けたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新してもよい。振分サーバ２００は、開始時点から第１期間が経過するまでの間、複数回閾値を更新してもよい。また、第２期間は、更新回数に応じて変動してもよい。また、第２期間は、各振分サーバ２００で異なってもよい。

〔２．管理サーバの構成〕
次に、図２を用いて、実施形態に係る管理サーバ１００の構成について説明する。図２は、実施形態に係る管理サーバ１００の構成例を示す図である。図２に示すように、管理サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、管理サーバ１００は、管理サーバ１００の管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）によって実現される。かかる通信部１１０は、図示しない所定のネットワークと有線または無線で接続される。そして、通信部１１０は、図示しない所定のネットワークを介して、振分サーバ２００等との間で情報の送受信を行う。

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部１２０は、図２に示すように、リクエスト情報記憶部１２１と、配信元情報記憶部１２２とを有する。

（リクエスト情報記憶部１２１）
実施形態に係るリクエスト情報記憶部１２１は、リクエストに関する情報を記憶する。例えば、リクエスト情報記憶部１２１は、リクエストの履歴に関する情報を記憶する。例えば、リクエスト情報記憶部１２１は、各振分サーバ２００から取得したリクエストの履歴に関する情報を記憶する。図３は、実施形態に係るリクエスト情報記憶部の一例を示す図である。図３に示すように、リクエスト情報記憶部１２１は、リクエストに関する情報として、「リクエストＩＤ」、「第１評価値（推定ｅＣＰＭ）」・・・といった項目を有する。

「リクエストＩＤ」は、リクエストを識別するための識別情報を示す。また、「第１評価値（推定ｅＣＰＭ）」は、各リクエストＩＤにより識別されるリクエストに対応する推定ｅＣＰＭを示す。具体的には、「第１評価値（推定ｅＣＰＭ）」は、広告配信装置ＡＮ１、ＡＮ２の各々のリクエストに対応する第１評価値（推定ｅＣＰＭ）を示す。例えば、「第１評価値（推定ｅＣＰＭ）」の単位は「円」である。

例えば、図３に示す例においては、リクエストＩＤ「Ｒ１」により識別されるリクエストは、広告配信装置ＡＮ１により広告が配信された場合に想定される第１評価値が「４０」であり、広告配信装置ＡＮ２により広告が配信された場合に想定される第１評価値が「２５」である。例えば、リクエスト情報記憶部１２１に記憶されたリクエスト情報に基づいて、図５や図６等に示す分布が生成される。

なお、リクエスト情報記憶部１２１は、目的に応じて種々のリクエストに関する情報を記憶してもよい。例えば、リクエスト情報記憶部１２１は、「第２評価値」等の項目を有してもよい。また、リクエスト情報記憶部１２１は、各リクエストを受け付けた日時に関する情報を記憶してもよい。

（配信元情報記憶部１２２）
実施形態に係る配信元情報記憶部１２２は、広告の配信元に関する情報を記憶する。例えば、配信元情報記憶部１２２は、配信元に関する情報として配信元の配信条件に関する情報を記憶する。図４は、実施形態に係る配信元情報記憶部の一例を示す図である。図４に示すように、配信元情報記憶部１２２は、配信元に関する情報として、「配信元ＩＤ」、「条件」、「内容」、・・・といった項目を有する。

「配信元ＩＤ」は、広告の配信元を識別するための識別情報を示す。また、「条件」は、各配信元における配信条件の有無を示す。また、「内容」は、各配信元における配信条件の内容を示す。

例えば、図４に示す例においては、配信元ＩＤ「ＡＮ１」により識別される広告配信装置（広告配信装置ＡＮ１）は、広告配信に関する条件が「無」である。また、配信元ＩＤ「ＡＮ２」により識別される広告配信装置（広告配信装置ＡＮ２）は、広告配信に関する条件が「有」であり、その内容が「予算」に関する条件である。

なお、配信元情報記憶部１２２は、目的に応じて種々の配信元に関する情報を記憶してもよい。例えば、配信元情報記憶部１２２は、「予算の金額」や「契約インプレッション数」等の項目を有してもよい。

（制御部１３０）
図２の説明に戻って、制御部１３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、管理サーバ１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図２に示すように、制御部１３０は、取得部１３１と、生成部１３２と、送信部１３３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図２に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図２に示した接続関係に限られず、他の接続関係であってもよい。

（取得部１３１）
取得部１３１は、各振分サーバ２００から配信実績情報を取得する。配信実績情報の詳細については、後述する。また、取得部１３１は、広告の配信元に関する情報を受け付けてもよい。例えば、取得部１３１は、広告配信装置ＡＮ１、ＡＮ２から広告の配信元に関する情報を受け付けてもよい。また、取得部１３１は、リクエストの履歴に関する情報を受け付けてもよい。例えば、取得部１３１は、各振分サーバ２００からリクエストの履歴に関する情報を取得してもよい。

（生成部１３２）
生成部１３２は、リクエスト情報記憶部１２１に記憶されたリクエストに関する情報や配信元情報記憶部１２２に記憶された広告の配信元に関する情報に基づいて、配信計画情報を生成する。例えば、生成部１３２は、リクエスト情報記憶部１２１に記憶された推定ｅＣＰＭを第１評価値として、配信計画情報を生成する。ここで、第１評価値は、目的に応じて適宜選択可能であり、ｅＣＰＭに限らず、広告に関する評価指標に関する値であれば、どのような評価指標に関する値であってもよい。広告に関する評価指標は、ｅＣＰＭの他にも、例えば、ＣＴＲ、ＣＰＣ（Cost Per Click）、ＣＶＲ（Conversion Rate）などであってもよく、第１評価値は、ＣＴＲ、ＣＰＣ、ＣＶＲ等の推定値であってもよい。

以下では、図５〜図９を用いて、配信計画情報の生成について説明する。以下に示す例においては、広告配信装置ＡＮ２が広告配信に関する条件が付された配信元（以下、「条件付配信元」とする場合がある）である場合を示す。例えば、広告配信装置ＡＮ２は、予算の制約や契約したインプレッション数（リクエスト数）の制約等によりインプレッション数（リクエスト数）を制限する条件が付される。

また、以下では、リクエストに対して各配信元が広告を配信した場合に想定される広告指標の値を第１評価値とし、条件付配信元に関する第１評価値を他の配信元に関する第１評価値で相対化した値を第２評価値として説明する。図５は、実施形態に係る第１評価値に基づくリクエストの分布の一例を示す図である。図６は、実施形態に係る第２評価値に基づくリクエストの分布の一例を示す図である。図７は、実施形態に係る配信スケジュールの一例を示す図である。図８は、実施形態に係る個別配信スケジュールの一例を示す図である。図９は、実施形態に係る第２評価値に基づくリクエストの分布の一例を示す図である。また、以下では、図１に示す例と同様に、２つの振分サーバ２００Ａ、２００Ｂが振分処理を行う場合を例に説明する。

例えば、図５は、第１期間に対応する所定の期間（例えば１日）におけるリクエストの履歴に関する第１評価値の分布を示す。図５中に示す各点が、履歴に含まれるリクエストに対応する。ここで、図５に示す例においては、リクエストの第１評価値をｅＣＰＭの推定値とした場合を示す。ここに、図５に示す例においては、ｅＣＰＭを広告の評価指標とした場合を示す。具体的には、図５において、Ｘ軸は広告配信装置ＡＮ１のｅＣＰＭが対応し、Ｙ軸は広告配信装置ＡＮ２のｅＣＰＭが対応する。例えば、図５は、ベクトル平面を示す。例えば、リクエストの履歴中のリクエストＲＱ１０に対して、広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値は、ｘ１０であり、リクエストの履歴中のリクエストＲＱ１０に対して、広告配信装置ＡＮ２が広告を配信した場合おけるｅＣＰＭの推定値は、ｙ１０であることを示す。なお、第１評価値の推定については後述する。

ここで、図２中の基準線ＣＲ１１は、以下の数式（１）により表現される。

Ｙ ＝ Ｘ ・・・ （１）

ここに、図５に示す例において、基準線ＣＲ１１よりも上側にある点に対応するリクエストは、広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値よりも、広告配信装置ＡＮ２が広告を配信した場合におけるｅＣＰＭの推定値の方が大きい。すなわち、基準線ＣＲ１１よりも上側にある点に対応するリクエストは、広告配信装置ＡＮ２の広告コンテンツを配信したほうが、広告配信装置ＡＮ１の広告コンテンツを配信するよりも高い広告効果が得られると想定される。すなわち、基準線ＣＲ１１よりも上側にある点に対応するリクエストは、広告配信装置ＡＮ２の広告コンテンツを配信すべきリクエストである。

また、図５に示す例において、基準線ＣＲ１１よりも下側にある点に対応するリクエストは、広告配信装置ＡＮ２が広告を配信した場合におけるｅＣＰＭの推定値よりも、広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値の方が大きい。すなわち、基準線ＣＲ１１よりも下側にある点に対応するリクエストは、広告配信装置ＡＮ１の広告コンテンツを配信したほうが、広告配信装置ＡＮ２の広告コンテンツを配信するよりも高い広告効果が得られると想定される。すなわち、基準線ＣＲ１１よりも下側にある点に対応するリクエストは、広告配信装置ＡＮ１の広告コンテンツを配信すべきリクエストである。上述したように、広告配信装置ＡＮ２は、予算の制約等によりインプレッション数（リクエスト数）を制限する条件が付される。広告配信装置ＡＮ２は、第１期間に広告配信できるリクエスト数が制限される。つまり、広告配信装置ＡＮ２は、条件付配信元である。そのため、広告配信管理システム１は、例えば、基準線ＣＲ１１よりも上側にある点に対応する全てのリクエストに対して、広告配信装置ＡＮ２の広告コンテンツを配信することができない。

生成部１３２は、第２評価値を算出するための所定の評価ベクトルＲＣ１１を生成する。図５に示す例において、評価ベクトルＲＣ１１は、基準線ＣＲ１１に垂直なベクトルである。例えば、評価ベクトルＲＣ１１は、基準線ＣＲ１１に垂直であってＹ軸から４５°傾き、原点ＯからＹ軸の正の向きに延びる単位ベクトルである。

ここに、原点Ｏからリクエストに対応する点までの距離をＬ、原点Ｏからリクエストに対応する点に延びるベクトルと評価ベクトルＲＣ１１の成す角の角度をθとした場合、第２評価値ＥＶは、以下の数式（２）により算出される。なお、評価ベクトルＲＣ１１の向きや長さは、条件や目的に応じて適宜設定されてもよい。

ＥＶ ＝ Ｌ×ｃｏｓθ ・・・ （２）

このように、生成部１３２は、リクエストの質を決定する評価ベクトルＲＣ１１を設定し、各リクエストの位置（Ｌ,θ）と評価ベクトルＲＣ１１によって算出される第２評価値ＥＶに基づいて、条件付配信元である広告配信装置ＡＮ２に優先的に広告を配信させるリクエストを決定する。具体的には、管理サーバ１００は、第２評価値ＥＶの大きいリクエストに対して広告配信装置ＡＮ２に広告を配信させる。

ここで、第２評価値ＥＶと広告配信装置ＡＮ２が広告を配信できるリクエスト数に基づく、閾値の設定について説明する。図６は、リクエストの履歴に関する第２評価値の分布を示す。なお、図６は、図５に示すリクエストの履歴と同様のリクエストの履歴に関する第２評価値の分布を示す。

図６の横軸は第２評価値ＥＶを示し、縦軸は対応する第２評価値ＥＶのリクエスト数を示す。ここに、分布曲線ＴＲ１０と横軸とにより囲まれる領域が履歴に含まれる全リクエスト数に対応する。ここで、広告配信装置ＡＮ２が広告を配信できるリクエスト数は、広告配信装置ＡＮ２に付された条件、例えば予算等により導出される。

ここに、生成部１３２は、広告配信装置ＡＮ２が広告を配信できるリクエスト数に基づいて、閾値ＴＨ１１を決定する。具体的には、生成部１３２は、分布曲線ＴＲ１０と横軸と分布曲線ＴＲ１０から閾値ＴＨ１１に対応する位置に引かれた垂線ＴＬ１１とにより囲まれ、第２評価値ＥＶが大きい側の領域ＡＲ１０に含まれるリクエスト数Ｓ１０が、広告配信装置ＡＮ２が広告を配信できるリクエスト数となるように、閾値ＴＨ１１を決定する。例えば、生成部１３２は、領域ＡＲ１０に含まれるリクエスト数Ｓ１０が、広告配信装置ＡＮ２が広告を配信できるリクエスト数となるように、閾値ＴＨ１１を決定する。

また、図６中に示す領域ＡＲ１０は、図５中に示す領域ＡＲ１０に対応する。そのため、図５〜図９に示す例においては、生成部１３２は、図５中の左上に位置するリクエストに対して広告配信装置ＡＮ２に優先的に広告を配信させるような配信計画情報を生成することとなる。

また、生成部１３２は、配信スケジュールを生成する。例えば、生成部１３２は、閾値ＴＨ１１やリクエスト数Ｓ１０に基づいて、配信スケジュールを生成する。具体的には、生成部１３２は、開始時点から第１期間が経過した時刻における広告配信装置ＡＮ２へのリクエスト数がリクエスト数Ｓ１０になるように、配信スケジュールを生成する。また、例えば、生成部１３２は、広告配信装置ＡＮ２に関する情報を含む配信元情報記憶部１２２に記憶された広告の配信元に関する情報に基づいて、配信スケジュールを生成する。なお、生成部１３２は、上記に限らず、目的に応じて種々の情報を用いて配信スケジュールを生成してもよい。

例えば、生成部１３２は、図７に示すような配信スケジュール（以下、「全体配信スケジュール」と称する場合がある）を生成する。具体的には、生成部１３２は、第１期間においてリクエストに対して広告配信装置ＡＮ２に広告配信を行わせる配信スケジュールを生成する。図７の横軸は開始時点を０とした場合の時刻を示し、縦軸は各時刻における広告配信装置ＡＮ２へのリクエストの開始時点からの累積数を示す。すなわち、時刻０〜時刻ｔ１１までの期間が、第１期間に対応する。図７に示す例は、開始時点において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数を抑え、第１期間の中間において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数を増やして、第１期間の終了付近において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数を抑えるような配信スケジュールとなる。

例えば、図７に示す例において、第１期間を１日として開始時点を朝６時とした場合、配信スケジュールは、朝は広告配信装置ＡＮ２に広告配信を行わせるリクエスト数を抑え、昼から夜において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数を増やして、深夜〜早朝において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数を抑えることを示す。

また、生成部１３２は、配信スケジュールを生成する。例えば、生成部１３２は、広告配信装置ＡＮ２に関する情報を含む配信元情報記憶部１２２に記憶された広告の配信元に関する情報に基づいて、配信スケジュールを生成する。また、例えば、生成部１３２は、閾値ＴＨ１１やリクエスト数Ｓ１０に基づいて、配信スケジュールを生成する。なお、生成部１３２は、上記に限らず、目的に応じて種々の情報を用いて配信スケジュールを生成してもよい。

また、生成部１３２は、生成した全体配信スケジュールに基づいて、各振分サーバ２００に対応する配信スケジュール（「個別配信スケジュール」と称する場合がある）を生成する。例えば、生成部１３２は、図８に示すような個別配信スケジュールを生成する。図８の横軸は開始時点を０とした場合の時刻を示し、縦軸は各時刻における広告配信装置ＡＮ２へのリクエストの開始時点からの累積数を示す。すなわち、時刻０〜時刻ｔ１１までの期間が、第１期間に対応する。

例えば、生成部１３２は、２つの振分サーバ２００Ａ、２００Ｂに対して同様の配信スケジュールを生成する。図５〜図９に示す例において、振分サーバ２００は２つである。つまり、図８に示す個別配信スケジュールは、図７に示す各時刻における広告配信装置ＡＮ２へのリクエストの開始時点からの累積数に０．５を乗算したものに対応する。例えば、図８中の時刻ｔ１１における広告配信装置ＡＮ２へのリクエストの開始時点からの累積数を示すリクエスト数Ｓ１１は、図７中の時刻ｔ１１における広告配信装置ＡＮ２へのリクエストの開始時点からの累積数を示すリクエスト数Ｓ１０の二分の一である。このように、生成部１３２は、開始時点から第１期間が経過した時刻における広告配信装置ＡＮ２へのリクエスト数がリクエスト数Ｓ１１になるように、個別配信スケジュールを生成する。

また、生成部１３２は、各振分サーバ２００に対応するリクエストの履歴に関する第２評価値の分布の情報を生成する。例えば、生成部１３２は、図６に示すリクエストの履歴に関する第２評価値の分布に基づいて、図９に示すリクエストの履歴に関する第２評価値の分布の情報を生成する。

図９の横軸は第２評価値ＥＶを示し、縦軸は対応する第２評価値ＥＶのリクエスト数を示す。つまり、図９に示すリクエストの履歴に関する第２評価値の分布は、図６に示す第２評価値に対応する広告配信装置ＡＮ２へのリクエスト数に０．５を乗算したものに対応する。ここに、分布曲線ＴＲ１１と横軸とにより囲まれる領域が履歴に含まれる全リクエスト数は、各振分サーバ２００が第１期間において受け付けるリクエスト数に対応する。また、分布曲線ＴＲ１１と横軸と分布曲線ＴＲ１１から閾値ＴＨ１１に対応する位置に引かれた垂線とにより囲まれ、第２評価値ＥＶが大きい側の領域ＡＲ１１に含まれるリクエスト数Ｓ１１は、図８に示すリクエスト数Ｓ１１に対応する。このように、生成部１３２は、例えば、１日等の一定期間の配信予定のリクエスト数（インプレッション数）と、時系列的なリクエスト分布等を基にして、各振分サーバ２００で配信するリクエスト数（インプレッション数）の計画を生成する。例えば、生成部１３２は、各振分サーバ２００が、０時台のインプレッション数を１億、１時台のインプレッション数を７０００万等とする個別配信スケジュールを生成する。

（送信部１３３）
送信部１３３は、生成部１３２により生成された配信計画情報を、各振分サーバ２００に送信する。例えば、送信部１３３は、所定の期間内において所定の配信元に広告配信を行わせるリクエスト数に関する情報を含む配信計画情報を各振分サーバ２００に送信する。例えば、送信部１３３は、広告配信装置ＡＮ２にリクエストに対する広告配信を行わせるかを決定するための閾値や第１期間内に広告配信装置ＡＮ２に広告配信を行わせるリクエスト数等の情報を含む配信計画情報を振分サーバ２００に送信する。また、例えば、送信部１３３は、配信スケジュール、例えば第１期間内における所定の時刻において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数の情報を含む配信計画情報を振分サーバ２００に送信する。また、例えば、送信部１３３は、評価ベクトルＲＣ１１に関する情報を含む配信計画情報を振分サーバ２００に送信する。また、例えば、送信部１３３は、各振分サーバ２００に対応するリクエストの履歴に関する第２評価値の分布の情報を含む配信計画情報を各振分サーバ２００に送信する。送信部１３３は、各振分サーバ２００に配信計画情報や閾値を含む配信スケジュールを所定の頻度（例えば１日１回）で送信する。

〔３．振分サーバの構成〕
次に、図１０を用いて、実施形態に係る振分サーバ２００の構成について説明する。図１０は、実施形態に係る振分サーバの構成例を示す図である。図１０に示すように、振分サーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０とを有する。なお、振分サーバ２００は、振分サーバ２００の管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部２１０）
通信部２１０は、例えば、ＮＩＣによって実現される。かかる通信部２１０は、図示しない所定のネットワークと有線または無線で接続される。そして、通信部２１０は、図示しない所定のネットワークを介して、端末装置１０、管理サーバ１００、広告配信装置ＡＮ１、ＡＮ２との間で情報の送受信を行う。

（記憶部２２０）
記憶部２２０は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部２２０は、図１０に示すように、リクエスト情報記憶部２２１と、配信計画情報記憶部２２２とを有する。

（リクエスト情報記憶部２２１）
実施形態に係るリクエスト情報記憶部２２１は、リクエストに関する情報を記憶する。例えば、リクエスト情報記憶部２２１は、リクエストの履歴に関する情報を記憶する。図１１は、実施形態に係るリクエスト情報記憶部の一例を示す図である。図１１に示すように、リクエスト情報記憶部２２１は、リクエストに関する情報として、「リクエストＩＤ」、「第１評価値（推定ｅＣＰＭ）」、「配信元」・・・といった項目を有する。

「リクエストＩＤ」は、リクエストを識別するための識別情報を示す。また、「第１評価値（推定ｅＣＰＭ）」は、各リクエストＩＤにより識別されるリクエストに対応する推定ｅＣＰＭを示す。具体的には、「第１評価値（推定ｅＣＰＭ）」は、広告配信装置ＡＮ１、ＡＮ２の各々のリクエストに対応する第１評価値（推定ｅＣＰＭ）を示す。例えば、「第１評価値（推定ｅＣＰＭ）」の単位は「円」である。また、「配信元」は、各リクエストＩＤにより識別されるリクエストに対して広告配信を行った配信元を示す。

例えば、図１１に示す例においては、リクエストＩＤ「Ｒ１１」により識別されるリクエストは、広告配信装置ＡＮ１により広告が配信された場合に想定される第１評価値が「１０」であり、広告配信装置ＡＮ２により広告が配信された場合に想定される第１評価値が「３０」である。リクエストＩＤ「Ｒ１１」により識別されるリクエストは、広告配信装置ＡＮ２により広告が配信されたことを示す。

なお、リクエスト情報記憶部２２１は、目的に応じて種々のリクエストに関する情報を記憶してもよい。例えば、リクエスト情報記憶部２２１は、「第２評価値」等の項目を有してもよい。また、リクエスト情報記憶部２２１は、各リクエストを受け付けた日時に関する情報を記憶してもよい。また、振分サーバ２００は、後述するフィードバック処理を行わない場合、リクエスト情報記憶部２２１を有さなくてもよい。

（配信計画情報記憶部２２２）
実施形態に係る配信計画情報記憶部２２２は、配信計画に関する情報を記憶する。例えば、配信計画情報記憶部２２２は、配信計画に関する情報として管理サーバ１００から受け付けた配信計画情報を記憶する。図１２は、実施形態に係る配信計画情報記憶部の一例を示す図である。図１２に示すように、配信計画情報記憶部２２２は、配信計画に関する情報として、「配信元ＩＤ」、「リクエスト数」、「期間」、「閾値」、「評価ベクトル」・・・といった項目を有する。

「配信元ＩＤ」は、広告の配信元を識別するための識別情報を示す。また、「リクエスト数」は、配信元ＩＤにより識別される配信元に広告配信を行わせるリクエスト数を示す。また、「期間」は、配信元ＩＤにより識別される配信元に広告配信を行わせる期間を示す。また、「閾値」は、配信元ＩＤにより識別される配信元に広告配信を行わせるかの基準となる閾値を示す。また、「評価ベクトル」は、配信元ＩＤにより識別される配信元に広告配信を行わせるかに用いる第２評価値の算出に用いる評価ベクトルを示す。

例えば、図１２に示す例においては、配信元ＩＤ「ＡＮ２」により識別される広告配信装置（広告配信装置ＡＮ２）に広告配信を行わせるリクエスト数は、リクエスト数Ｓ１１であり、その期間は、時刻０から時刻ｔ１１までの第１期間であることを示す。なお、図１２に示す例では、期間として第１期間が終了する時刻ｔ１１を記憶したが、第１期間の長さ（例えば、１日等）を記憶したり、第１時間の開始時刻と終了時刻とを記憶したりてもよい。また、広告配信装置ＡＮ２に広告配信を行わせるかの基準となる閾値は閾値ＴＨ１１であり、第２評価値の算出に用いる評価ベクトルは評価ベクトルＲＣ１１であることを示す。

なお、配信計画情報記憶部２２２は、目的に応じて種々の配信元に関する情報を記憶してもよい。例えば、配信計画情報記憶部２２２は、閾値に関する情報や評価ベクトルＲＣ１１に関する情報や振分サーバ２００に対応するリクエストの履歴に関する第２評価値の分布の情報を記憶してもよい。

（制御部２３０）
図１０の説明に戻って、制御部２３０は、例えば、ＣＰＵやＭＰＵ等によって、振分サーバ２００内部の記憶装置に記憶されている各種プログラム（振分プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部２３０は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図１０に示すように、制御部２３０は、受付部２３１と、推定部２３２と、決定部２３３と、情報送信部２３４と、更新部２３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部２３０の内部構成は、図１０に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部２３０が有する各処理部の接続関係は、図１０に示した接続関係に限られず、他の接続関係であってもよい。

（受付部２３１）
受付部２３１は、広告配信を要求するリクエストを受け付ける。例えば、受付部２３１は、端末装置１０から広告枠に表示する広告コンテンツの配信要求であるリクエストを受け付ける。また、例えば、受付部２３１は、端末装置１０Ａから端末装置１０Ａを所有するユーザＵ１のユーザＩＤやユーザＵ１の年齢、性別などのユーザ情報を含むリクエストを受け付ける。具体的には、受付部２３１は、端末装置１０Ａから広告枠に表示する広告コンテンツの配信要求であるリクエストとして、ユーザＵ１の年齢、性別などのユーザ情報を含むＨＴＴＰクッキーを受け付ける。また、受付部２３１は、広告配信装置ＡＮ１、ＡＮ２から端末装置１０へ送信する広告コンテンツを受け付ける。例えば、受付部２３１は、リクエストに対する広告の配信元として決定された広告配信装置ＡＮ１、ＡＮ２から、端末装置１０へ送信する広告コンテンツを受け付ける。

また、受付部２３１は、管理サーバ１００から配信計画情報を受け付ける。例えば、受付部２３１は、広告配信装置ＡＮ２にリクエストに対する広告配信を行わせるかを決定するための閾値や第１期間内に広告配信装置ＡＮ２に広告配信を行わせるリクエスト数等の情報を含む配信計画情報を管理サーバ１００から受け付ける。また、例えば、受付部２３１は、配信スケジュール、例えば第１期間内における所定の時刻において広告配信装置ＡＮ２に広告配信を行わせるリクエスト数の情報を含む配信計画情報を管理サーバ１００から受け付ける。また、例えば、受付部２３１は、評価ベクトルＲＣ１１に関する情報を含む配信計画情報を管理サーバ１００から受け付ける。また、例えば、受付部２３１は、各振分サーバ２００に対応するリクエストの履歴に関する第２評価値の分布の情報を含む配信計画情報を管理サーバ１００から受け付ける。例えば、受付部２３１は、所定の期間内において所定の配信元に広告配信を行わせるリクエスト数に関する情報を含む配信計画情報を管理サーバ１００から受け付ける。

（推定部２３２）
推定部２３２は、配信元によって端末装置１０からのリクエストに対して配信されることが想定される広告の評価値である第１評価値を推定する。例えば、推定部２３２は、第１評価値としてｅＣＰＭの値を推定する。なお、第１評価値は、目的に応じて適宜選択可能であり、ｅＣＰＭに限らず、広告に関する評価指標に関する値であれば、どのような評価指標に関する値であってもよい。広告に関する評価指標は、ｅＣＰＭの他にも、例えば、ＣＴＲ、ＣＰＣ、ＣＶＲなどであってもよく、第１評価値は、ＣＴＲ、ＣＰＣ、ＣＶＲ等の推定値であってもよい。

例えば、推定部２３２は、端末装置１０からのリクエストに対して広告配信装置ＡＮ１、ＡＮ２が配信すると想定される広告の第１評価値を推定する。例えば、推定部２３２は、受付部２３１により受け付けられた端末装置１０Ａを所有するユーザＵ１のユーザ情報に基づいて、リクエストに対して広告配信装置ＡＮ１、ＡＮ２が配信すると想定される広告の第１評価値を推定する。また、推定部２３２は、種々の従来技術を適宜用いて、配信元によって端末装置１０からのリクエストに対して配信されることが想定される広告の第１評価値を推定してもよい。

推定部２３２は、例えば、第１評価値をｅＣＰＭの推定値とする場合、広告配信装置ＡＮ１、ＡＮ２毎にＣＴＲの推定値とＣＰＣの推定値とを求め、ＣＴＲの推定値とＣＰＣの推定値とを掛け合わせて広告配信装置ＡＮ１、ＡＮ２毎の第１評価値を求める。ここで、ＣＴＲの推定値は、リクエストに対するＣＴＲの推定値である。推定部２３２は、広告枠の広告コンテンツへのクリックを従属変数とし、上述したユーザＵの属性情報や広告枠の情報を独立変数（説明変数）として、例えば、ＳＶＭ（Support Vector Machine）とシグモイドフィッティングによりＣＴＲの推定値を求める。また、推定部２３２は、例えば、ロジスティック回帰分析によりＣＴＲの推定値を求めることもできる。

また、ＣＰＣの推定値は、リクエストに対するＣＰＣの推定値である。推定部２３２は、広告リクエストに対する配信候補の広告コンテンツの配信単価（例えば、ＣＰＣやＣＰＡ（Cost Per Action））を従属変数とし、上述したユーザＵの属性情報や広告枠の情報を独立変数（説明変数）として、例えば、重回帰分析またはポアソン回帰分析によりＣＰＣの推定値を求める。推定部２３２は、上述のように求めたＣＴＲの推定値とＣＰＣの推定値とにより、第１評価値であるｅＣＰＭの推定値を求める。

なお、振分サーバ２００として、予め設定された第１評価値、例えばＣＰＣなどを用いる場合、推定部２３２を有さなくてもよい。

（決定部２３３）
決定部２３３は、リクエストに対して各配信元により広告が配信された場合に想定される広告の評価値である第１評価値に基づいて算出される値である第２評価値の閾値と、配信計画情報から得られる閾値とに応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。例えば、決定部２３３は、広告配信に関する条件が付された配信元である条件付配信元を含む複数の配信元によってリクエストに対して配信されることが想定される第１評価値のうち、条件付配信元に関する第１評価値と他の配信元に関する第１評価値とに基づいて算出した第２評価値に応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。また、決定部２３３は、２つの配信元に関する第１評価値に対応する評価指標を軸とする場合において、リクエストに対応するベクトルと、所定の評価ベクトルとに基づいて算出される第２評価値に応じて、２つの配信元からリクエストに対する広告配信を行う配信元を決定する。例えば、決定部２３３は、条件付配信元に関する第１評価値に対応する軸に対して所定の傾きを有する評価ベクトルに基づいて算出される第２評価値に応じて、２つの配信元からリクエストに対する広告配信を行う配信元を決定する。

（情報送信部２３４）
情報送信部２３４は、決定部２３３によりリクエストに対する広告の配信元として決定された配信元に広告コンテンツの配信要求を送信する。例えば、情報送信部２３４は、リクエストに対する広告の配信元として決定された広告配信装置ＡＮ２に広告コンテンツの配信要求を送信する。また、情報送信部２３４は、広告の配信元から受け付けた広告コンテンツを端末装置１０へ送信する。例えば、情報送信部２３４は、広告配信装置ＡＮ２から受け付けた広告コンテンツを端末装置１０Ａへ送信する。また、情報送信部２３４は、リクエスト情報記憶部２２１に記憶されたリクエストに関する情報を管理サーバ１００へ送信してもよい。

ここで、受付部２３１がリクエストＲＱ１１を受け付けた場合を図１３及び図１４を例に説明する。図１３は、実施形態に係る第２評価値の算出の一例を示す図である。図１４は、実施形態に係る閾値と第２評価値との関係の一例を示す図である。図１３中の評価ベクトルＲＣ１１は、図５中の評価ベクトルＲＣ１１に対応する。また、図１４中の分布曲線ＴＲ１１や閾値ＴＨ１１は、図９中の分布曲線ＴＲ１１や閾値ＴＨ１１に対応する。

推定部２３２は、リクエストＲＱ１１に対して広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値と、リクエストＲＱ１１に対して広告配信装置ＡＮ２が広告を配信した場合におけるｅＣＰＭの推定値とを推定する。

図１３に示すように、原点ＯからリクエストＲＱ１１に対応する点までの距離はＬ１１であり、原点ＯからリクエストＲＱ１１に対応する点に延びるベクトルＶＣ１１と評価ベクトルＲＣ１１の成す角の角度をθ１とした場合、評価値ＥＶ１１は、上記の数式（２）に基づいて以下の数式（３）より算出される。

ＥＶ１１ ＝ Ｌ１１×ｃｏｓθ１ ・・・ （３）

上記の数式（３）により算出された評価値ＥＶ１１は、閾値ＴＨ１１よりも大きい。つまり、図１４においてリクエストＲＱ１１は領域ＡＲ１１内に含まれる。したがって、決定部２３３は、リクエストＲＱ１１を広告配信装置ＡＮ２に優先的に広告を配信させるリクエストと決定する。また、決定部２３３は、評価値が閾値ＴＨ１１未満であった場合、リクエストを広告配信装置ＡＮ１に広告を配信させるリクエストと決定する。このように、決定部２３３は、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

広告の配信元を決定した後、情報送信部２３４は、広告配信の要求先として決定された配信元に対して広告の配信要求を送信する。

決定部２３３は、条件付配信元に関する第１評価値を他の配信元に関する第１評価値で相対化した第２評価値に応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。具体的には、決定部２３３は、他の配信元よりも広告配信数に関連する制約が強い条件付配信元に関する第１評価値を、条件に基づいて他の配信元に関する第１評価値で相対化した第２評価値に応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。図１３及び図１４に示す例において、決定部２３３は、第２評価値ＥＶを算出するために、所定の評価ベクトルＲＣ１１を用いる。この場合、第２評価値ＥＶは、上記の数式（２）により算出される。上記の数式（２）により算出される第２評価値ＥＶは、例えば原点Ｏからリクエストに対応する点に延びるベクトルを評価ベクトルＲＣ１１に正射影したベクトルの長さになる。

また、図１３及び図１４に示す例において、受付部２３１によりリクエストＲＱ１１を受け付けられた場合、決定部２３３は、上記の数式（３）に基づいて第２評価値ＥＶ１１を算出する。上記の数式（３）により算出された第２評価値ＥＶ１１は、閾値ＴＨ１１よりも大きい。つまり、図１４においてリクエストＲＱ１１は領域ＡＲ１１内に含まれる。したがって、決定部２３３は、リクエストＲＱ１１を広告配信装置ＡＮ２に優先的に広告を配信させるリクエストと決定する。また、決定部２３３は、第２評価値が閾値ＴＨ１１未満であった場合、リクエストを広告配信装置ＡＮ１に広告を配信させるリクエストと決定する。このように、決定部２３３は、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

（更新部２３５）
更新部２３５は、各振分サーバ２００が受け付けたリクエストに対する所定の配信元による広告配信の進捗に基づいて閾値を更新する。例えば、更新部２３５は、受付部２３１により受け付けられたリクエストに対する広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新する。例えば、更新部２３５は、配信計画情報に含まれるリクエスト数に関する情報と、広告配信装置ＡＮ２に広告配信を行わせたリクエスト数とに基づいて閾値を更新する。例えば、更新部２３５は、閾値の更新時において広告配信装置ＡＮ２に広告配信を行わせたリクエスト数が、配信計画情報において対応するリクエスト数よりも少ない場合、所定の配信元に広告配信を行わせるリクエスト数が多くなるように閾値を更新する。また、例えば、更新部２３５は、閾値の更新時において広告配信装置ＡＮ２に広告配信を行わせたリクエスト数が、配信計画情報において対応するリクエスト数よりも多い場合、所定の配信元に広告配信を行わせるリクエスト数が少なくなるように閾値を更新する。なお、所定の配信元による広告配信の進捗とは、所定の配信元に対応する広告配信の実績と予定とに基づく、予定された広告配信のスケジュールと実際に行われた広告配信との関係を言う。

まず、図１５及び図１６を用いて、閾値を高くする場合について説明する。図１５は、実施形態に係る個別配信スケジュールと配信実績との関係の一例を示す図である。図１６は、実施形態に係る更新された閾値と第２評価値との関係の一例を示す図である。図１５及び図１６に示す例は、振分サーバ２００Ａにおける閾値の更新の例を示す。例えば、図１５に示す時刻０〜時刻ｔ１までの期間が第２期間に対応する。

図１５に示す例では、時刻０から第２期間が経過した時刻ｔ１における配信実績ＡＰ１１が配信予定ＰＲ１１よりも大きい。つまり、振分サーバ２００Ａは、時刻ｔ１において予定されたリクエスト数よりも多くの広告配信を広告配信装置ＡＮ２に行わせたこととなる。この場合、振分サーバ２００Ａの更新部２３５は、広告配信装置ＡＮ２の広告が配信されにくくなるように閾値を調整する。具体的には、図１６に示すように、振分サーバ２００Ａの更新部２３５は、閾値ＴＨ１１を閾値ＴＨ２１（＞閾値ＴＨ１１）へ更新する。これにより、振分サーバ２００Ａは、時刻ｔ１以降において、時刻ｔ１以前と比べて広告配信装置ＡＮ２に広告配信を行わせにくくなる。これにより、振分サーバ２００Ａの配信実績は、配信スケジュールに近づく。なお、振分サーバ２００Ａは、時刻ｔ１以後時刻ｔ１１よりも以前の時刻ｔ２においても閾値を更新してもよい。このように、振分サーバ２００は、振分処理の開始時点または閾値の更新時点から第２期間以内において閾値の更新を繰り返し行ってもよい。

次に、図１７及び図１８を用いて、閾値を低くする場合について説明する。図１７は、実施形態に係る個別配信スケジュールと配信実績との関係の一例を示す図である。図１８は、実施形態に係る更新された閾値と第２評価値との関係の一例を示す図である。図１７及び図１８に示す例は、振分サーバ２００Ｂにおける閾値の更新の例を示す。例えば、図１７に示す時刻０〜時刻ｔ１までの期間が第２期間に対応する。

図１７に示す例では、時刻０から第２期間が経過した時刻ｔ１における配信実績ＡＰ１０が配信予定ＰＲ１１よりも小さい。つまり、振分サーバ２００Ｂは、時刻ｔ１において予定されたリクエスト数よりも少ない広告配信を広告配信装置ＡＮ２に行わせたこととなる。この場合、振分サーバ２００Ｂの更新部２３５は、広告配信装置ＡＮ２の広告が配信されやすくなるように閾値を調整する。具体的には、図１８に示すように、振分サーバ２００Ｂの更新部２３５は、閾値ＴＨ１１を閾値ＴＨ３１（＜閾値ＴＨ１１）へ更新する。これにより、振分サーバ２００Ｂは、時刻ｔ１以降において、時刻ｔ１以前と比べて広告配信装置ＡＮ２に広告配信を行わせやすくなる。これにより、振分サーバ２００Ｂの配信実績は、配信スケジュールに近づく。

上述した図１５〜図１８に示す例においては、時刻ｔ１以降において、振分サーバ２００Ａの閾値と振分サーバ２００Ｂの閾値とは異なる値となる。具体的には、時刻ｔ１以降において、振分サーバ２００Ａの閾値は閾値ＴＨ２１となり、振分サーバ２００Ｂの閾値は閾値ＴＨ３１となる。このように、広告配信管理システム１においては、各振分サーバ２００が、自身の配信実績に基づいて、配信スケジュールに近づくように閾値を更新する。

〔４．変形例〕
上述した実施形態に係る広告配信管理システム１は、上記実施形態以外にも様々な異なる形態にて実施されてよい。そこで、以下では、上記の広告配信管理システム１の他の実施形態について説明する。

〔４−１．フィードバック処理〕
広告配信管理システム１においては、管理サーバ１００は、各振分サーバ２００から取得した配信実績情報に基づいて、配信計画情報を生成してもよい。この点について、図１９を用いて説明する。

図１９に示す例において、振分処理の開始時点から第１期間が経過した場合、振分サーバ２００Ａは、配信実績情報を管理サーバ１００へ送信する（ステップＳ１６）。例えば、図１５に示す例において、第１期間が経過した後、すなわち時刻ｔ１１に達した場合、振分サーバ２００Ａは、時刻０〜時刻ｔ１１までに行った振分処理に関する情報を配信実績情報として管理サーバ１００に送信する。例えば、振分サーバ２００Ａは、リクエスト情報記憶部２２１に記憶されたリクエストに関する情報を配信実績情報として管理サーバ１００に送信する。

また、図１９に示す例において、振分処理の開始時点から第１期間が経過した場合、振分サーバ２００Ｂは、配信実績情報を管理サーバ１００へ送信する（ステップＳ１７）。例えば、図１７に示す例において、第１期間が経過した後、すなわち時刻ｔ１１に達した場合、振分サーバ２００Ｂは、時刻０〜時刻ｔ１１までに行った振分処理に関する情報を配信実績情報として管理サーバ１００に送信する。例えば、振分サーバ２００Ｂは、リクエスト情報記憶部２２１に記憶されたリクエストに関する情報を配信実績情報として管理サーバ１００に送信する。

各振分サーバ２００から配信実績情報を取得した管理サーバ１００は、取得した配信実績情報を反映する（ステップＳ１８）。例えば、管理サーバ１００は、取得した配信実績情報をリクエスト情報記憶部１２１に記憶してもよい。その後、管理サーバ１００は、例えば、ステップＳ１８で取得した配信実績情報に基づいて、配信計画情報を生成する。その後、管理サーバ１００は、振分サーバ２００に配信計画情報を送信する（ステップＳ１９）。例えば、管理サーバ１００は、１日１回各振分サーバ２００の配信実績情報を受信して、配信予定との差分を考慮して次（翌日）の広告配信数を含む配信スケジュールを決定する。これにより、管理サーバ１００は、より適切な配信計画情報に配信計画情報を更新することができる。また、管理サーバ１００から配信計画情報を受け付けた振分サーバ２００は、更新された配信計画情報を用いることにより、広告の配信元を適切に選択することができる。例えば、管理サーバ１００は、広告配信装置ＡＮ２にリクエストに対する広告配信を行わせるかを決定するための閾値や第１期間内に広告配信装置ＡＮ２に広告配信を行わせるリクエスト数等の情報を含む配信計画情報を振分サーバ２００に送信する。例えば、管理サーバ１００は、ステップＳ１６及びステップＳ１７において取得した配信実績情報に基づいて生成した配信計画情報を各振分サーバ２００へ送信してもよい。

〔４−２．配信スケジュール及び閾値の更新〕
上記実施形態における配信スケジュール及び閾値の更新について、さらに詳述する。例えば、管理サーバ１００は、各振分サーバ２００が広告配信装置ＡＮ２に広告配信を行わせることができるリクエスト数をリクエスト数Ｓ１１とした場合、所定の閾値ＴＨ１１と時系列的なリクエストの分布等に基づいて、第１期間（例えば１日）の累積リクエストの配信スケジュールを生成する。例えば、管理サーバ１００は、種々の従来技術を用いて適宜、累積リクエストの配信計画を作成する。また、管理サーバ１００は、各振分サーバ２００に配信スケジュールを含む配信計画情報を送信する。

また、上述のようにリクエストの分布は例えば過去の履歴等に基づく予測であり、閾値ＴＨ１１に基づく配信計画通りに配信されていかない可能性がある。そのため、各振分サーバ２００は、周期的に、配信予定ＰＲと配信実績ＡＰに基づいて配信実績ＡＰを配信予定ＰＲに近づけるため、閾値を更新して広告配信装置ＡＮ２の広告の配信されやすさを調整する。この点について、図２０及び図２１を用いて説明する。

図２０は、変形例に係る個別配信スケジュールの一例を示す図である。図２１は、変形例に係る閾値の変動の一例を示す図である。具体的には、図２０及び図２１に示す例では、振分サーバ２００は、時刻ｔ１１において広告配信装置ＡＮ２へのリクエスト数がリクエスト数Ｓ１１になるように、閾値を更新する。例えば、振分サーバ２００は、以下の数式（４）により、閾値を更新する。

ＴＨ_ｎｅｗ ＝ ＴＨ_ｏｌｄ×Ｆ（ＡＰ／ＰＲ） ・・・ （４）

ここで、数式（４）中のＴＨ_ｏｌｄは更新前の閾値を示し、ＴＨ_ｎｅｗは更新後の閾値を示す。また、数式（４）中のＡＰは閾値更新時における配信実績数を示し、ＰＲは閾値更新時における配信予定数を示す。また、数式（４）中のＦは、所定の関数であってリクエストの分布や配信計画に応じて適宜設定される。例えば、管理サーバ１００や振分サーバ２００は、図２１に示す例において、ある時刻ｔにおける、配信予定ＰＲと配信実績ＡＰとの差の絶対値が等しい場合、分布曲線ＴＲ１１と横軸と分布曲線ＴＲ１１から閾値に対応する位置に引かれた垂線とにより囲まれ、第２評価値ＥＶが大きい側の領域の面積の変化量の絶対値が同じになるように、関数Ｆを設定してもよい。なお、図２１に示す第２評価値に基づくリクエストの分布が一様分布である場合、ＡＰ／ＰＲを閾値ＴＨ_ｏｌｄに乗算した値を新たな閾値ＴＨ_ｎｅｗとしてもよい。

ここで、図２０に示す例では、時刻ｔ１における配信実績ＡＰ１１が配信予定ＰＲ１１よりも大きい。この場合、振分サーバ２００は、広告配信装置ＡＮ２の広告が配信されにくくなるように閾値を調整する。具体的には、図２１に示すように、振分サーバ２００は、閾値ＴＨ１１を閾値ＴＨ２１（＞閾値ＴＨ１１）へ更新する。

また、図２０に示す例では、時刻ｔ２における配信実績ＡＰ１２が配信予定ＰＲ１２よりも小さい。この場合、振分サーバ２００は、広告配信装置ＡＮ２の広告が配信されやすくなるように閾値を調整する。具体的には、図２１に示すように、振分サーバ２００は、閾値ＴＨ１１を閾値ＴＨ３１（＜閾値ＴＨ１１）へ更新する。このように、振分サーバ２００は、広告配信装置ＡＮ２による広告配信の進捗に基づいて閾値を更新することにより、広告の配信元を適切に選択することができる。

なお、管理サーバ１００は、所定の期間（年間、月間等）に決められたリクエスト数（インプレッション数）を考慮して、１日当たりのリクエスト数（インプレッション数）、例えばリクエスト数Ｓ１１を決定してもよい。また、管理サーバ１００は、１日の合計リクエスト数や１日の時間帯毎のリクエスト数の計画は、曜日や季節性を考慮して決定してもよい。また、管理サーバ１００は、ＰＣ、スマホ等のデバイス別、または、広告掲載面（ソース）毎にリクエスト数の計画を決定してもよい。また、管理サーバ１００は、スポーツや天災等により、急激にリクエストが急増減した場合、リクエストの急増減を検知して、リクエスト予定数、例えばリクエスト数Ｓ１１を更新してもよい。

〔４−３．第２評価値〕
上記実施形態においては、振分サーバ２００が第２評価値を算出するために所定の評価ベクトルを用いる例を示したが、振分サーバ２００は、評価ベクトルを用いることなく第２評価値を算出してもよい。例えば、振分サーバ２００は、２つの配信元に関する第１評価値の差により導出される値を第２評価値として用いてもよい。この場合、振分サーバ２００は、２つの配信元に関する第１評価値の差により導出される第２評価値に基づいて、２つの配信元からリクエストに対する広告配信を行う配信元を決定してもよい。

例えば、振分サーバ２００は、上述した例において、広告配信装置ＡＮ２の第１評価値である広告配信装置ＡＮ２が広告を配信した場合におけるｅＣＰＭの推定値から、広告配信装置ＡＮ１の第１評価値である広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値を減算した値を第２評価値としてもよい。このように、振分サーバ２００は、２つの配信元に関する第１評価値の差を第２評価値として用いることにより、広告の配信元を適切に選択することができる。なお、管理サーバ１００や振分サーバ２００は、２つの配信元の第１評価値の差に限らず、目的に応じて種々の算出手段を採用してもよい。例えば、管理サーバ１００や振分サーバ２００は、各配信元の第１評価値に異なる重み値を乗算した値の差を第２評価値として用いてもよい。この場合、管理サーバ１００は、評価ベクトルを振分サーバ２００に送信しなくてもよい。

〔４−４．評価ベクトル〕
管理サーバ１００や振分サーバ２００は、評価ベクトルＲＣ１１に限らず、目的に応じて適宜選択された評価ベクトルを用いてもよい。この点について、図２２〜図２５を用いて説明する。図２２は、変形例に係る第１評価値に基づくリクエストの分布の一例を示す図である。図２３は、変形例に係る第２評価値の算出の一例を示す図である。図２４は、変形例に係る第２評価値に基づくリクエストの分布の一例を示す図である。図２５は、変形例に係る第２評価値の算出の一例を示す図である。

例えば、図２２は、第１期間（例えば１日）におけるリクエストの履歴に関する第１評価値の分布を示す。図２２中に示す各点が、履歴に含まれるリクエストに対応する。ここで、図２２に示す例においては、リクエストの第１評価値をｅＣＰＭの推定値とした場合を示す。ここに、図２２に示す例においては、ｅＣＰＭを広告の評価指標とした場合を示す。具体的には、図２２において、Ｘ軸は広告配信装置ＡＮ１のｅＣＰＭが対応し、Ｙ軸は広告配信装置ＡＮ２のｅＣＰＭが対応する。例えば、図２２は、ベクトル平面を示す。

ここで、図２２〜図２４に示す例においては、広告配信装置ＡＮ２は、予算の制約等によりインプレッション数（リクエスト数）を制限する条件が付される。つまり、広告配信装置ＡＮ２は、条件付配信元である。そのため、振分サーバ２００は、条件付配信元に関する第１評価値を他の配信元に関する第１評価値で相対化した第２評価値に基づいて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。図２２〜図２４に示す例においては、振分サーバ２００は、第２評価値ＥＶを算出するために、所定の評価ベクトルＲＣ１２を用いる。図２３に示す例において、評価ベクトルＲＣ１２は、Ｘ軸に垂直なベクトルである。例えば、評価ベクトルＲＣ１２は、Ｘ軸に垂直であって原点ＯからＹ軸の正の向きに延びる単位ベクトルである。なお、評価ベクトルＲＣ１２の向きや長さは、条件や目的に応じて適宜設定されてもよい。

ここに、原点Ｏからリクエストに対応する点までの距離をＬ、原点Ｏからリクエストに対応する点に延びるベクトルと評価ベクトルＲＣ１２の成す角の角度をθとした場合、第２評価値ＥＶは、上記の数式（２）により算出される。

このように、振分サーバ２００は、リクエストの質を決定する評価ベクトルＲＣ１２を設定し、各リクエストの位置（Ｌ,θ）と評価ベクトルＲＣ１２によって算出される第２評価値ＥＶに基づいて、条件付配信元である広告配信装置ＡＮ２に優先的に広告を配信させるリクエストを決定する。具体的には、振分サーバ２００は、第２評価値ＥＶの大きいリクエストに対して広告配信装置ＡＮ２に広告を配信させる。

ここで、第２評価値ＥＶと広告配信装置ＡＮ２が広告を配信できるリクエスト数に基づく、閾値の設定について説明する。図２４は、リクエストの履歴に関する第２評価値の分布を示す。

図２４の横軸は第２評価値ＥＶを示し、縦軸は対応する第２評価値ＥＶのリクエスト数を示す。ここに、分布曲線ＴＲ１２と横軸とにより囲まれる領域が履歴に含まれる全リクエスト数に対応する。ここで、広告配信装置ＡＮ２が広告を配信できるリクエスト数は、広告配信装置ＡＮ２に付された条件、例えば予算等により導出される。ここに、管理サーバ１００は、広告配信装置ＡＮ２が広告を配信できるリクエスト数に基づいて、閾値ＴＨ１２を決定する。具体的には、管理サーバ１００は、分布曲線ＴＲ１２と横軸と分布曲線ＴＲ１２から閾値ＴＨ１２に対応する位置に引かれた垂線ＴＬ１２とにより囲まれ、第２評価値ＥＶが大きい側の領域ＡＲ１２１に含まれるリクエスト数が、各振分サーバ２００が広告配信装置ＡＮ２に広告配信を行わせることができるリクエスト数となるように、閾値ＴＨ１２を決定する。

ここで、振分サーバ２００が、リクエストＲＱ１２を受け付けた場合を例に説明する。管理サーバ１００は、リクエストＲＱ１２に対して広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値と、リクエストＲＱ１２に対して広告配信装置ＡＮ２が広告を配信した場合におけるｅＣＰＭの推定値とを推定する。

図２３に示すように、原点ＯからリクエストＲＱ１２に対応する点までの距離はＬ１２であり、原点ＯからリクエストＲＱ１２に対応する点に延びるベクトルＶＣ１２と評価ベクトルＲＣ１２の成す角の角度をθ２とした場合、第２評価値ＥＶ１２は、上記の数式（２）に基づいて以下の数式（５）より算出される。

ＥＶ１２ ＝ Ｌ１２×ｃｏｓθ２ ・・・ （５）

上記の数式（５）により算出された第２評価値ＥＶ１２は、閾値ＴＨ１２よりも大きい。したがって、振分サーバ２００は、リクエストＲＱ１２を広告配信装置ＡＮ２に優先的に広告を配信させるリクエストと決定する。また、振分サーバ２００は、第２評価値が閾値ＴＨ１２未満であった場合、リクエストを広告配信装置ＡＮ１に広告を配信させるリクエストと決定する。そのため、図２２〜図２４に示す例においては、振分サーバ２００は、図２２中の上側に位置する領域ＡＲ１２内のリクエスト、すなわち広告配信装置ＡＮ２のｅＣＰＭの推定値が大きいリクエストに対して広告配信装置ＡＮ２に優先的に広告を配信させることとなる。このように、振分サーバ２００は、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

また、図２５に示す例においては、振分サーバ２００は、第２評価値ＥＶを算出するために、所定の評価ベクトルＲＣ１３を用いる。図２５に示す例において、評価ベクトルＲＣ１３は、基準線ＣＲ１１に重なる（沿う）ベクトルである。例えば、評価ベクトルＲＣ１３は、基準線ＣＲ１１に重なりＹ軸から４５°傾き、原点ＯからＹ軸の正の向きに延びる単位ベクトルである。ここで、図２５中の基準線ＣＲ１１は、上記の数式（１）により表現される。

ここに、原点Ｏからリクエストに対応する点までの距離をＬ、原点Ｏからリクエストに対応する点に延びるベクトルと評価ベクトルＲＣ１３の成す角の角度をθとした場合、第２評価値ＥＶは、下記の数式（６）により算出される。

ＥＶ ＝ Ｌ×ｓｉｎθ ・・・ （６）

このように、振分サーバ２００は、各リクエストの位置（Ｌ,θ）と評価ベクトルＲＣ１３によって算出される第２評価値ＥＶに基づいて、条件付配信元である広告配信装置ＡＮ２に優先的に広告を配信させるリクエストを決定する。具体的には、振分サーバ２００は、第２評価値ＥＶの大きいリクエストに対して広告配信装置ＡＮ２に広告を配信させる。なお、評価ベクトルＲＣ１３の向きや長さは、条件や目的に応じて適宜設定されてもよい。

ここで、振分サーバ２００が、リクエストＲＱ１３を受け付けた場合を例に説明する。振分サーバ２００は、リクエストＲＱ１３に対して広告配信装置ＡＮ１が広告を配信した場合におけるｅＣＰＭの推定値と、リクエストＲＱ１３に対して広告配信装置ＡＮ２が広告を配信した場合におけるｅＣＰＭの推定値とを推定する。

図２５に示すように、原点ＯからリクエストＲＱ１３に対応する点までの距離はＬ１３であり、原点ＯからリクエストＲＱ１３に対応する点に延びるベクトルＶＣ１３と評価ベクトルＲＣ１３の成す角の角度をθ３とした場合、第２評価値ＥＶ１３は、上記の数式（６）に基づいて以下の数式（７）より算出される。

ＥＶ１３ ＝ Ｌ１３×ｓｉｎθ３ ・・・ （７）

上記の数式（７）により算出された第２評価値ＥＶ１３が所定の閾値よりも大きい場合、振分サーバ２００は、リクエストＲＱ１３を広告配信装置ＡＮ２に優先的に広告を配信させるリクエストと決定する。また、振分サーバ２００は、第２評価値ＥＶ１３が所定の閾値未満であった場合、リクエストを広告配信装置ＡＮ１に広告を配信させるリクエストと決定する。このように、振分サーバ２００は、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

〔４−５．複数（３つ以上）の配信元（Ｎ次元）〕
上記実施形態においては、広告配信管理システム１が２つの配信元からリクエストに対する広告配信を行う配信元を決定する例を示したが、広告配信管理システム１は、２つに限らず３つ以上の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。例えば、振分サーバ２００は、各配信元に関する第１評価値に対応する評価指標を軸とする場合において、リクエストに対応するベクトルと、所定の評価ベクトルとに基づいて算出される第２評価値に応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。この点について、図２６を用いて説明する。図２６は、変形例に係る評価ベクトルの一例を示す図である。

図２６に示す例においては、３つの配信元である広告配信装置ＡＮ１、ＡＮ２、ＡＮ３からリクエストに対する広告配信を行う配信元を決定する場合を示す。図２６において、Ｘ軸は広告配信装置ＡＮ１のｅＣＰＭが対応し、Ｙ軸は広告配信装置ＡＮ２のｅＣＰＭが対応し、Ｚ軸は広告配信装置ＡＮ３のｅＣＰＭが対応する。例えば、図２６は、３次元のベクトル空間を示す。このように、３つ以上の配信元からリクエストに対する広告配信を行う配信元を決定する場合、振分サーバ２００は、多次元のベクトル空間に基づいてリクエストに対する広告配信を行う配信元を決定してもよい。

例えば、振分サーバ２００は、条件付配信元に関する第１評価値に対応する軸に対して所定の傾きを有する評価ベクトルに基づいて算出される第２評価値に応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。図２６に示すように、振分サーバ２００は、例えば、所定の評価ベクトルＲＣ１４を用いる。評価ベクトルＲＣ１４は、その長さと、２つの角の角度θ、φにより示される。

図２６に示す例において、評価ベクトルＲＣ１４は単位ベクトルであり、角度θは、評価ベクトルＲＣ１４とＺ軸とがなす角度を示し、角度φは、評価ベクトルＲＣ１４をＸＹ平面に正射影したベクトルとＸ軸とがなす角度を示す。この場合、振分サーバ２００は、例えば原点Ｏからリクエストに対応する点に延びるベクトルを評価ベクトルＲＣ１４に正射影したベクトルの長さｒを、第２評価値ＥＶとして算出する。振分サーバ２００は、算出した第２評価値ＥＶに基づいて、リクエストに対する広告配信を行う配信元を決定してもよい。なお、評価ベクトルＲＣ１４の向きや長さは、条件や目的に応じて適宜設定されてもよい。

例えば、振分サーバ２００は、算出した第２評価値ＥＶに基づいて、Ｚ軸に対応する広告配信装置ＡＮ３に広告配信を行わせるかを決定してもよい。また、振分サーバ２００は、Ｚ軸に対応する広告配信装置ＡＮ３以外、すなわち広告配信装置ＡＮ１、ＡＮ２に広告配信を行わせると決定した場合、評価ベクトルＲＣ１４をＸＹ平面に正射影したベクトルを評価ベクトルとして用いてもよい。ここに、評価ベクトルＲＣ１４をＸＹ平面に正射影したベクトルは、広告配信装置ＡＮ１、ＡＮ２のいずれに広告配信を行わせるかを決定するために用いられる評価ベクトルとなる。

例えば、振分サーバ２００は、評価ベクトルＲＣ１４をＸＹ平面に正射影したベクトルと原点Ｏからリクエストに対応する点に延びるベクトルとに基づいて新たに算出された第２評価値ＥＶに基づいて、広告配信装置ＡＮ１、ＡＮ２のいずれに広告配信を行わせるかを決定してもよい。なお、振分サーバ２００は、条件付配信元に関する第１評価値に対応する軸に沿う評価ベクトルに基づいて算出される第２評価値に応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。また、振分サーバ２００は、４つ以上の配信元からリクエストに対する広告配信を行う配信元を決定する場合、評価ベクトルの角の角度をθ、φ・・・と増加させることにより、複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。

また、振分サーバ２００は、複数の評価ベクトルを用いて、複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。この場合、振分サーバ２００は、例えば、２つの配信元に対応する複数の評価ベクトルを用いてもよい。また、振分サーバ２００は、予め設定された複数の評価ベクトル間の優先順位に基づいて複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。例えば、振分サーバ２００は、２つの配信元からリクエストに対する広告配信を行う配信元を決定する処理を繰り返し、最終的にリクエストに対する広告配信を行う配信元として決定された配信元に、リクエストに対する広告配信を行わせてもよい。

また、振分サーバ２００は、例えば、特定の配信元に対する評価ベクトルを複数用いてもよい。例えば、振分サーバ２００は、特定の配信元に対する評価ベクトルを用いて、その特定の配信元にリクエストに対する広告配信を行わせるかを決定してもよい。この場合、振分サーバ２００は、評価ベクトルに対応する特定の配信元にリクエストに対する広告配信を行わせないと決定した場合、他の特定の配信元に対する評価ベクトルを用いて、処理を繰り返してもよい。そして、振分サーバ２００は、特定の配信元に対する評価ベクトルを用いて、その特定の配信元にリクエストに対する広告配信を行わせることを決定した場合、配信元を決定する処理を終了してもよい。

また、例えば、振分サーバ２００は、３つの配信元からリクエストに対する広告配信を行う配信元を決定する場合、原点Ｏからリクエストに対応する点までの距離をＬ、原点Ｏからリクエストに対応する点に延びるベクトルと評価ベクトルとの間の２つの角の角度をθ、φとする。この場合、振分サーバ２００は、リクエストの質を決定する評価ベクトルを設定し、各リクエストの位置（Ｌ,θ，φ）と評価ベクトルによって算出される第２評価値ＥＶに基づいて、３つの配信元からリクエストに対する広告配信を行う配信元を決定してもよい。

また、振分サーバ２００は、例えば、各リクエストの位置（Ｌ,θ，φ）が最も近接する軸に対応する配信元を広告配信を行う配信元として決定してもよい。なお、振分サーバ２００は、４つ以上の配信元からリクエストに対する広告配信を行う配信元を決定する場合、原点Ｏからリクエストに対応する点に延びるベクトルと評価ベクトルとの間の角の角度をθ、φ・・・と増加させることにより、複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。

〔４−６．条件付配信元と閾値〕
上述の変形例においては、振分サーバ２００が条件付配信元である広告配信装置ＡＮ２の条件に基づいて閾値を更新することにより、広告配信装置ＡＮ２に広告を配信させるリクエストを決定する。以下では、条件付配信元が広告配信装置ＡＮ１である場合において、振分サーバ２００が広告配信装置ＡＮ１の条件に基づいて閾値を更新することにより、広告配信装置ＡＮ２に広告を配信させるリクエストを決定してもよい。この点について、図２７〜図２９を用いて説明する。図２７は、変形例に係る第１評価値に基づくリクエストの分布に基づく第２評価値の算出の一例を示す図である。図２８は、変形例に係る個別配信スケジュールの一例を示す図である。図２９は、変形例に係る閾値の変動の一例を示す図である。

例えば、図２７は、所定の期間（例えば１日）におけるリクエストの履歴に関する第１評価値の分布を示す。図２７中に示す各点が、履歴に含まれるリクエストに対応する。ここで、図２７に示す例においては、リクエストの第１評価値をＣＴＲの推定値とした場合を示す。ここに、図２７に示す例においては、ＣＴＲを広告の評価指標とした場合を示す。具体的には、図２７において、Ｘ軸は広告配信装置ＡＮ１のＣＴＲが対応し、Ｙ軸は広告配信装置ＡＮ２のＣＴＲが対応する。例えば、図２７は、ベクトル平面を示す。

ここで、図２７〜図２９に示す例においては、広告配信装置ＡＮ１は、インプレッション数（リクエスト数）に関する条件が付される。例えば、広告配信装置ＡＮ１は、所定の期間内に所定数のインプレッション数（リクエスト数）を満たす条件が付される。つまり、広告配信装置ＡＮ１は、条件付配信元である。ここで、広告配信装置ＡＮ２のクリック数を最大化、すなわちＣＴＲを最大化したい場合、振分サーバ２００は、条件付配信元に関する第１評価値を他の配信元に関する第１評価値で相対化した第２評価値に基づいて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

図２７〜図２９に示す例においては、振分サーバ２００は、第２評価値ＥＶを算出するために、所定の評価ベクトルＲＣ１５を用いる。図２７に示す例において、評価ベクトルＲＣ１５は、Ｘ軸に垂直なベクトルである。例えば、評価ベクトルＲＣ１５は、Ｘ軸に垂直であって原点ＯからＹ軸の正の向きに延びる単位ベクトルである。

ここに、原点Ｏからリクエストに対応する点までの距離をＬ、原点Ｏからリクエストに対応する点に延びるベクトルと評価ベクトルＲＣ１５の成す角の角度をθとした場合、第２評価値ＥＶは、上記の数式（２）により算出される。

このように、振分サーバ２００は、リクエストの質を決定する評価ベクトルＲＣ１５を設定し、各リクエストの位置（Ｌ,θ）と評価ベクトルＲＣ１５によって算出される第２評価値ＥＶに基づいて、条件付配信元である広告配信装置ＡＮ２に優先的に広告を配信させるリクエストを決定する。具体的には、振分サーバ２００は、第２評価値ＥＶの大きいリクエストに対して広告配信装置ＡＮ２に広告を配信させる。

例えば、図２７に示す例において、原点ＯからリクエストＲＱ１５に対応する点までの距離はＬ１５であり、原点ＯからリクエストＲＱ１５に対応する点に延びるベクトルＶＣ１５と評価ベクトルＲＣ１５の成す角の角度をθ５とした場合、第２評価値ＥＶ１５は、上記の数式（２）に基づいて以下の数式（８）より算出される。

ＥＶ１５ ＝ Ｌ１５×ｃｏｓθ５ ・・・ （８）

上記の数式（８）により算出された第２評価値ＥＶ１５が、閾値よりも大きい場合、振分サーバ２００は、リクエストＲＱ１５を広告配信装置ＡＮ２に優先的に広告を配信させるリクエストと決定する。また、振分サーバ２００は、第２評価値ＥＶ１５が閾値未満であった場合、リクエストを広告配信装置ＡＮ１に広告を配信させるリクエストと決定する。そのため、図２７〜図２９に示す例においては、振分サーバ２００は、図２７中の上側に位置する領域ＡＲ１５内のリクエスト、すなわち広告配信装置ＡＮ２のＣＴＲの推定値が大きいリクエストに対して広告配信装置ＡＮ２に優先的に広告を配信させることとなる。このように、振分サーバ２００は、条件付配信元の条件や他の配信元における戦略的な条件を総合して、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。なお、評価ベクトルＲＣ１５の向きや長さは、条件や目的に応じて適宜設定されてもよい。

また、管理サーバ１００は、各振分サーバ２００が広告配信装置ＡＮ１に広告配信を行なわせる必要があるリクエスト数（インプレッション数）をリクエスト数Ｓ２１とした場合、所定の閾値ＴＨ１５と時系列的なリクエストの分布等に基づいて、所定の期間（例えば１日）の累積リクエストの配信計画を作成する。例えば、管理サーバ１００は、種々の従来技術を用いて適宜、累積リクエストの配信計画を作成する。

ここで、図２９の横軸は第２評価値ＥＶを示し、縦軸は対応する第２評価値ＥＶのリクエスト数を示す。ここに、分布曲線ＴＲ１５と横軸とにより囲まれる領域が履歴に含まれる全リクエスト数に対応する。また、図２８及び図２９に示す例では、振分サーバ２００は、時刻ｔ２３において広告配信装置ＡＮ１へのリクエスト数がリクエスト数Ｓ２１になるように、閾値を更新する。例えば、振分サーバ２００は、上記の数式（４）により、閾値を更新する。

ここで、図２８に示す例では、時刻ｔ２１における配信実績ＡＰ２１が配信予定ＰＲ２１よりも大きい。この場合、振分サーバ２００は、広告配信装置ＡＮ１の広告が配信されにくくなるよう、言い換えると広告配信装置ＡＮ２の広告が配信されやすくなるように閾値を調整する。具体的には、図２９に示すように、振分サーバ２００は、閾値ＴＨ１５を閾値ＴＨ３５（＜閾値ＴＨ１５）へ更新する。

また、図２８に示す例では、時刻ｔ２２における配信実績ＡＰ２２が配信予定ＰＲ２２よりも小さい。この場合、振分サーバ２００は、広告配信装置ＡＮ１の広告が配信されやすくなるよう、言い換えると広告配信装置ＡＮ２の広告が配信されにくくなるように閾値を調整する。具体的には、図２９に示すように、振分サーバ２００は、閾値ＴＨ１５を閾値ＴＨ２５（＞閾値ＴＨ１５）へ更新する。このように、振分サーバ２００は、条件付配信元による広告配信の進捗に基づいて閾値を更新することにより、条件付配信元の条件や他の配信元における戦略的な条件を総合して、広告の配信元を適切に選択することができる。

〔４−７．閾値の変動〕
なお、振分サーバ２００は、配信スケジュールにおいて閾値の更新時以降に予定されるリクエスト数に基づいて、閾値を更新してもよい。例えば、振分サーバ２００は、配信スケジュールにおいて閾値の更新時以降に予定されるリクエスト数に基づいて、閾値を変動させる割合を変化させてもよい。この点について、以下に説明する。以下に示す例においては、１時間おきに閾値を更新する、すなわち第２期間が１時間である場合に基づいて説明する。以下では、振分サーバ２００が０時、１時、２時・・・と時間が変化する毎に閾値を更新する。以下では時間がｎ時に対応する時間帯をｎ時台と称する場合がある。

例えば、振分サーバ２００は、以下の数式（９）に基づいて、ｎ時台の閾値ＴＨ（ｎ）を算出する。

ＴＨ（ｎ）＝ＴＨ_initial×Ｆ（（Ｂ（ｎ）＋Ｓ（ｎ−１））／Ｂ（ｎ）） ・・・（９）

上記の数式（９）において、初期閾値ＴＨ_initialは、閾値ＴＨの初期値を示す。例えば、初期閾値ＴＨ_initialは、管理サーバ１００から送信された閾値ＴＨに対応する。また、数式（９）中のＦは、所定の関数であってリクエストの分布や配信スケジュールに応じて適宜設定される。また、予定値Ｂ（ｎ）は、ｎ時台に所定の配信元に広告配信を行わせるリクエスト数に対応する。例えば、予定値Ｂ（ｎ）は、ｎ時台に広告配信装置ＡＮ２に広告配信を行わせるリクエスト数に対応する。例えば、２時台に広告配信装置ＡＮ２に１０００個のリクエストに対して広告配信を行わせる予定の場合、２時台の予定値Ｂ（２）＝１０００となる。

また、乖離値Ｓ（ｎ）は、ｎ時台までの配信実績と配信予定との差を示す。すなわち、乖離数Ｓ（ｎ−１）は、ｎ−１時台までの配信実績と配信予定との差を示す。例えば、乖離値Ｓ（ｎ−１）は、振分処理開始時からｎ−１時台までの配信実績と配信予定との差を示す。この場合、乖離値Ｓ（ｎ−１）は、ｎ時台に用いる閾値ＴＨ（ｎ）に閾値を更新する時点までの配信実績と配信予定との差となる。このように、上記の数式（９）を用いることにより、振分サーバ２００は、閾値ＴＨ（ｎ）に閾値を更新した以降の配信予定と、閾値ＴＨ（ｎ）に閾値を更新する時点までの配信実績と配信予定との乖離とに基づいて、閾値を更新する。そのため、振分サーバ２００は、配信実績と配信予定とを適切に反映した閾値を用いることができるため、より配信スケジュールに沿った広告配信を所定の配信元に広告配信を行わせることができる。

なお、振分サーバ２００は、以下の数式（１０）に基づいて、ｎ時台の閾値ＴＨ（ｎ）を算出してもよい。

ＴＨ（ｎ）＝ＴＨ_initial×（Ｂ（ｎ）＋Ｓ（ｎ−１））／Ｂ（ｎ） ・・・（１０）

上記の例では、初期閾値ＴＨ_initialを用いたが、振分サーバ２００は、更新された閾値を用いて、再帰的に閾値を更新してもよい。例えば、振分サーバ２００は、以下の数式（１１）に基づいて、ｎ時台の閾値ＴＨ（ｎ）を算出してもよい。

ＴＨ（ｎ）＝ＴＨ（ｎ−１）×（Ｂ（ｎ）＋Ｓ（ｎ−１））／Ｂ（ｎ）・・・（１１）

上記の数式（９）において、閾値ＴＨ（ｎ−１）は、ｎ−１時台の閾値、すなわち閾値ＴＨ（ｎ）に更新する直前に用いた閾値である。これにより、振分サーバ２００は、直前の閾値に基づいて、閾値を更新する。そのため、振分サーバ２００は、配信実績と配信予定とを適切に反映した閾値を用いることができるため、より配信スケジュールに沿った広告配信を所定の配信元に広告配信を行わせることができる。なお、上記の数式（９）の初期閾値ＴＨ_initialを閾値ＴＨ（ｎ−１）に置き換えた数式を用いてもよい。

また、振分サーバ２００は、日を跨いで乖離値Ｓ（ｎ）を用いてもよい。例えば、振分サーバ２００は、０時台に閾値を更新しＴＨ（０）を算出する場合、前日の２３時台までの配信実績と配信予定との差を示す乖離値Ｓ（２３）を用いてもよい。この場合、各振分サーバ２００は、初期閾値ＴＨ_initialと１時間毎（ｎ＝０，１，２,…，２３）の予定値Ｂ（ｎ）があれば、自律して閾値を更新して振分処理を行うことができる。つまり、振分サーバ２００は、１日１回、管理サーバ１００で各各配信サーバの乖離値Ｓ（ｎ）を集計する処理、すなわちフィードバック処理を行うことなく、振分サーバ２００は、適切に閾値を更新して振分処理を行なうことができる。この場合、管理サーバ１００や振分サーバ２００は、例えば、第１期間を設定しなくてもよい。また、振分サーバ２００は、上記の数式（１１）のように、再帰的に更新された閾値を用いてもよい。

また、振分サーバ２００は、配信予定よりも配信実績が大きくなり過ぎた場合、所定の配信元に広告配信を行わせることを停止してもよい。例えば、振分サーバ２００は、乖離値Ｓ（ｎ）が所定の値を超えた場合、所定の配信元に広告配信を行わせることを一時停止してもよい。具体的には、振分サーバ２００は、乖離値Ｓ（ｎ）が所定の値（例えば、１万等）を超えた場合、広告配信装置ＡＮ２に広告配信を行わせることを一時停止してもよい。また、振分サーバ２００は、一時停止から所定の期間が経過した後、所定の配信元に広告配信を再開させてもよい。また、振分サーバ２００は、一時停止から広告配信を再開させるまでの所定の期間を、乖離値Ｓ（ｎ）に基づいて変動させてもよい。

また、振分サーバ２００は、配信予定よりも配信実績が小さくなり過ぎた場合、所定の配信元以外の他の配信元に広告配信を行わせることを停止してもよい。例えば、振分サーバ２００は、乖離値Ｓ（ｎ）が所定の値未満になった場合、所定の配信元以外の他の配信元に広告配信を行わせることを一時停止してもよい。具体的には、振分サーバ２００は、乖離値Ｓ（ｎ）が所定の値（例えば、−１万等）未満になった場合、広告配信装置ＡＮ１に広告配信を行わせることを一時停止してもよい。なお、振分サーバ２００は、上記の広告配信の一時停止の判定を行う場合、乖離値Ｓ（ｎ）のみに限らず、目的に応じて種々の数値を用いてもよい。例えば、振分サーバ２００は、Ｓ（ｎ）／Ｂ（ｎ＋１）のように乖離値Ｓ（ｎ）と予定値Ｂ（ｎ＋１）との相対値を用いてもよい。また、振分サーバ２００は、一時停止から所定の期間が経過した後、一時停止させた配信元に広告配信を再開させてもよい。また、振分サーバ２００は、一時停止から広告配信を再開させるまでの所定の期間を、乖離値Ｓ（ｎ）に基づいて変動させてもよい。

振分サーバ２００は、閾値ＴＨを更新できる最大値ＴＨ_ｍａｘや最小値ＴＨ_ｍｉｎを設定してもよい。例えば、振分サーバ２００は、上記の数式（９）〜（１１）を用いて閾値ＴＨ（ｎ）を算出した際に、閾値ＴＨ（ｎ）が最大値ＴＨ_ｍａｘを超えた場合、閾値ＴＨ（ｎ）を最大値ＴＨ_ｍａｘに設定してもよい。また、例えば、振分サーバ２００は、上記の数式（９）〜（１１）を用いて閾値ＴＨ（ｎ）を算出した際に、閾値ＴＨ（ｎ）が最小値ＴＨ_ｍｉｎ未満になった場合、閾値ＴＨ（ｎ）を最小値ＴＨ_ｍｉｎに設定してもよい。これにより、振分サーバ２００は、閾値の想定されない値に更新されることを抑制し、適切な値に閾値を更新する。そのため、振分サーバ２００は、適切な範囲の値に設定された閾値を用いることができるため、より配信スケジュールに沿った広告配信を所定の配信元に広告配信を行わせることができる。

なお、第２期間に限らず、閾値の更新時から所定の期間（例えば、第１期間が終了するまでの期間）に予定されるリクエスト数に基づいて、閾値を変動させる割合を変化させてもよい。

〔４−８．配信元〕
上述した例においては、広告配信装置ＡＮ１と広告配信装置ＡＮ２とが別の配信元として用いられる場合を説明したが、広告配信管理システム１は、概念的に分割された複数の配信元からリクエストに対する広告配信を行う配信元を決定してもよい。例えば２つの配信元を１つの配信元とみなしたり、一の配信元と他の配信元の一部とを１つの配信元とみなしたりしてもよい。具体的には、広告配信装置ＡＮ２と、広告配信装置ＡＮ１と広告配信装置ＡＮ２とを混合させた２つの配信元に概念的に分割した場合、広告配信装置ＡＮ２のみにより広告配信が行われる数と、広告配信装置ＡＮ１と広告配信装置ＡＮ２とがランダムやＲＴＢ（Real-Time Bidding）等によって自由に配信される数との広告の出し分けに利用してもよい。この場合、例えば、ランダムやＲＴＢ等による配信を行う広告配信装置ＡＮ１と広告配信装置ＡＮ２の一部のトラフィックにリクエスト数の制約があり（条件付配信元に相当）、残りの広告配信装置ＡＮ２に第２評価値が高いトラフィックを割り当てたい（他の配信元に相当）といった場合も適用できる。

〔４−９．配信情報の表示〕
なお、広告配信管理システム１は、上述した種々の情報を提供する機能を有してもよい。例えば、広告配信管理システム１は、管理サーバ１００や振分サーバ２００による広告配信に関する配信情報を視覚的に提供する機能を有してもよい。この点について、図３０〜図３２を用いて以下説明する。なお、以下の例においては、管理サーバ１００が管理サーバ１００や振分サーバ２００による広告配信に関する配信情報を表示する場合を例に説明する。

まず、図３０を用いて、配信情報の非累積表示について説明する。図３０は、変形例に係る配信情報の非累積表示の一例を示す図である。図３０には、所定の振分サーバ２００における広告配信装置ＡＮ１に対するリクエスト数の時系列的な変動を示す。ここで、図３０に示す例において、予定曲線ＣＬ３１は、所定の時間（例えば１時間）ごとに予定される広告配信装置ＡＮ１に対するリクエスト数、すなわち配信スケジュールを示す。また、図３０に示す例において、実績曲線ＣＬ３２は、所定の時間ごとに広告配信装置ＡＮ１に対するリクエスト数、すなわち配信実績を示す。

このように、管理サーバ１００は、予定曲線ＣＬ３１と実績曲線ＣＬ３２とを表示する。これにより、例えば、管理サーバ１００の管理者は、図３０に示す非累積表示された配信情報を確認することにより、予定と実績のリクエスト（インプレッション）数の乖離から、最適な配信のためのチューニングが可能となる。例えば、図３０に示す例において、時刻ｔ３１における、予定曲線ＣＬ３１と実績曲線ＣＬ３２との乖離は、乖離値ｄｆ３１であることが視覚的に表現される。そのため、例えば、管理サーバ１００の管理者は、直感的に予定曲線ＣＬ３１と実績曲線ＣＬ３２との乖離を認識できる。

次に、図３１を用いて、配信情報の累積表示について説明する。図３１は、変形例に係る配信情報の累積表示の一例を示す図である。図３１には、所定の振分サーバ２００における広告配信装置ＡＮ１に対するリクエスト数の時系列的な変動を示す。ここで、図３１に示す例において、予定曲線ＣＬ４１は、所定の時間（例えば１時間）までに予定される広告配信装置ＡＮ１に対する累積リクエスト数、すなわち累積された配信スケジュールを示す。また、図３１に示す例において、実績曲線ＣＬ４２は、所定の時間迄の広告配信装置ＡＮ１に対するリクエスト数、すなわち累積された配信実績を示す。

このように、管理サーバ１００は、予定曲線ＣＬ４１と実績曲線ＣＬ４２とを表示する。これにより、例えば、管理サーバ１００の管理者は、図３１に示す累積表示された配信情報を確認することにより、予定と実績のリクエスト（インプレッション）数の乖離から、最適な配信のためのチューニングが可能となる。例えば、図３１に示す例において、時刻ｔ４１における、予定曲線ＣＬ４１と実績曲線ＣＬ４２との乖離は、乖離値ｄｆ４１であることが視覚的に表現される。そのため、例えば、管理サーバ１００の管理者は、直感的に予定曲線ＣＬ４１と実績曲線ＣＬ４２との乖離を認識できる。

なお、予定曲線ＣＬ３１や予定曲線ＣＬ４１は、予定値Ｂ（ｎ）に乖離値Ｓ（ｎ−１）を加えて更新された予定曲線であってもよい。また、各振分サーバ２００の情報や全ての振分サーバ２００の合計値、平均値、最大値、最小値や標準偏差等の統計量を表示してもよい。例えば、図３０や図３１において表示される配信情報は、全ての振分サーバ２００に広告配信装置ＡＮ１に対するリクエスト数の時系列的な変動であってもよい。例えば、全ての振分サーバ２００に広告配信装置ＡＮ１に対するリクエスト数の平均に基づく、時系列的な変動であってもよい。また、例えば、管理サーバ１００の管理者は、所定の操作により予定曲線ＣＬ３１、ＣＬ４１や実績曲線ＣＬ３２、ＣＬ４２を、単体で表示させてもよい。また、例えば、管理サーバ１００の管理者は、所定の操作により予定曲線ＣＬ３１、ＣＬ４１及び実績曲線ＣＬ３２、ＣＬ４２を重ねて表示させてもよい。また、管理サーバ１００は、比較のために過去の統計量も表示してもよい。例えば、管理サーバ１００は、前日、一週間前、直近一週間の平均等の統計量を表示してもよい。

また、管理サーバ１００は、全ての振分サーバ２００の統計量や過去の統計量との乖離を検知することにより異常を検知してもよい。この場合、管理サーバ１００は、異常を検知した場合、例えば管理サーバ１００の管理者に、アラートとして報告することができる。また、管理サーバ１００は、全ての振分サーバ２００の合計や平均等の統計量が過去の全ての振分サーバ２００の合計や平均等の統計量とある程度乖離した場合に、原因の振分サーバ２００に関する情報と共にアラートとして報告してもよい。この場合、例えばアラートを認識した管理サーバ１００の管理者に、どの振分サーバ２００がアラートの原因かを通知することができる。

次に、図３２を用いて、閾値の変動の表示について説明する。図３２は、変形例に係る配信情報の閾値表示の一例を示す図である。図３２には、所定の振分サーバ２００における閾値の時系列的な変動を示す。ここで、図３２に示す例において、変動曲線ＣＬ５１は、時間ごとの閾値の変動を示す。このように、管理サーバ１００は、決定した閾値ＴＨ１１から閾値がどのような推移を経て遷移していったのかを、時系列的に表示することができる。つまり、管理サーバ１００は、所定の振分サーバ２００において配信実績数を配信予定数に近づけるために更新していく閾値の推移を視覚的にわかるように表示することができる。これにより、例えば、管理サーバ１００の管理者は、閾値の推移を容易に認識できる。したがって、管理サーバ１００の管理者は、例えば、予定に誘導する初期閾値（例えば、閾値ＴＨ１１）のチューニングを行うことができる。すなわち、管理サーバ１００の管理者は、配信開始時点（例えば、０時）に使う初期閾値を増減させることができる。また、例えば、管理サーバ１００の管理者は、閾値算出に用いられる上記の式（４）や式（９）に示す関数Ｆのチューニングをすることが可能となる。すなわち、管理サーバ１００は、閾値を更新していく関数を変更することができる。

なお、上記の表示は一例であり、目的に応じて種々の内容や組合せに基づいて、廃止情報を表示してもよい。例えば、管理サーバ１００は、図３２を図３０や図３１とともに表示してもよい。この場合、例えば、管理サーバ１００の管理者は、閾値の変動と配信実績の推移との相関等を直感的に認識することができる。

なお、上記の例においては、管理サーバ１００は、配信情報を表示する例を示したが、例えば、広告配信管理システム１は、管理サーバ１００や振分サーバ２００に加えて、上述した配信情報を集計する集計装置を有してもよい。また、例えば、広告配信管理システム１は、管理サーバ１００や振分サーバ２００に加えて、上述した配信情報を集計した結果を視覚的に表示する表示装置を有してもよい。また、広告配信管理システム１は、例えば、上述した配信情報を集計した結果に基づいて広告配信管理システム１における異常を検知する検知装置を有してもよい。なお、上記構成は例示であり、例えば、管理サーバ１００や振分サーバ２００が、上述した集計装置の機能や表示装置の機能や検知装置の機能を有してもよい。

〔４−１０．配信計画情報〕
なお、管理サーバ１００や振分サーバ２００は、第１評価値を第２評価値として用いてもよい。例えば、管理サーバ１００や振分サーバ２００は、所定の配信元に対応する第１評価値を第２評価値として用いてもよい。また、管理サーバ１００は、各振分サーバ２００の処理能力等に基づいて、配信計画情報を生成してもよい。例えば、振分サーバ２００Ａの処理能力が振分サーバ２００Ｂの処理能力よりも高い場合、管理サーバ１００は、振分サーバ２００Ａにより所定の配信元に広告配信を行わせるリクエスト数が、振分サーバ２００Ｂにより所定の配信元に広告配信を行わせるリクエスト数よりも多くなるように配信計画情報を生成してもよい。また、管理サーバ１００は、上記に限らず、種々の目的に応じて振分サーバ２００毎に異なる配信計画情報を生成してもよい。

〔５．効果〕
上述してきたように、実施形態に係る広告配信管理システム１は、管理サーバ１００と、複数の振分サーバ２００を有する。管理サーバ１００は、複数の振分サーバ２００を管理する。管理サーバ１００は、送信部１３３を有する。送信部１３３は、所定の期間（実施形態においては第１期間。以下同じ）内において複数の配信元のうち所定の配信元（実施形態においては広告配信装置ＡＮ２。以下同じ）に行わせる広告配信の計画に関する配信計画情報を各振分サーバ２００に送信する。また、振分サーバ２００は、広告配信を要求するリクエストに応じて複数の配信元から広告配信を行わせる配信元を決定する。振分サーバ２００は、受付部２３１と、決定部２３３と、更新部２３５とを有する。受付部２３１は、リクエストを受け付ける。決定部２３３は、受付部２３１によりリクエストを受け付けた場合、リクエストに対して各配信元により広告が配信された場合に想定される広告の評価値（実施形態においては第１評価値）に基づいて算出される値（実施形態においては第２評価値）と、配信計画情報から得られる閾値とに応じて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。更新部２３５は、各振分サーバ２００が受け付けたリクエストに対する所定の配信元による広告配信の進捗に基づいて閾値を更新する。

これにより、実施形態に係る広告配信管理システム１は、通信負荷を抑制することができる。具体的には、広告配信管理システム１において、複数の振分サーバ２００は、管理サーバ１００から配信計画情報を受け付けた後、各々自律して配信処理を行う。したがって、広告配信管理システム１は、管理サーバ１００と各振分サーバ２００との間の通信負荷を抑制することができる。また、広告配信管理システム１は、振分サーバ２００が所定の配信元による広告配信の進捗に基づいて閾値を更新することにより、広告の配信元を適切に選択することができる。

また、実施形態に係る広告配信管理システム１において、送信部１３３は、所定の期間内において所定の配信元に広告配信を行わせるリクエスト数に関する情報を含む配信計画情報を各振分サーバ２００に送信する。また、更新部２３５は、配信計画情報に含まれるリクエスト数に関する情報と、各振分サーバ２００が所定の配信元に広告配信を行わせたリクエスト数とに基づいて閾値を更新する。

これにより、実施形態に係る広告配信管理システム１は、通信負荷を抑制することができる。具体的には、広告配信管理システム１において、複数の振分サーバ２００は、管理サーバ１００から配信計画情報を受け付けた後、各々自律して配信処理を行う。したがって、広告配信管理システム１は、管理サーバ１００と各振分サーバ２００との間の通信負荷を抑制することができる。また、広告配信管理システム１は、振分サーバ２００が所定の配信元による広告配信の進捗に基づいて閾値を更新することにより、広告の配信元を適切に選択することができる。

また、実施形態に係る広告配信管理システム１において、更新部２３５は、閾値の更新時において各振分サーバ２００が所定の配信元に広告配信を行わせたリクエスト数が、配信計画情報において対応するリクエスト数よりも少ない場合、所定の配信元に広告配信を行わせるリクエスト数が多くなるように閾値を更新する。

これにより、実施形態に係る広告配信管理システム１において、所定の配信元の広告が配信されやすくなる。これにより、振分サーバ２００の配信実績は、配信計画情報の配信スケジュールに近づく。したがって、振分サーバ２００は、所定の配信元による広告配信の進捗に基づいて閾値を更新することにより、広告の配信元を適切に選択することができる。

また、実施形態に係る広告配信管理システム１において、更新部２３５は、閾値の更新時において各振分サーバが所定の配信元に広告配信を行わせたリクエスト数が、配信計画情報において対応するリクエスト数よりも多い場合、所定の配信元に広告配信を行わせるリクエスト数が少なくなるように閾値を更新する。

これにより、実施形態に係る広告配信管理システム１において、所定の配信元の広告が配信されにくくなる。これにより、振分サーバ２００の配信実績は、配信計画情報の配信スケジュールに近づく。したがって、振分サーバ２００は、所定の配信元による広告配信の進捗に基づいて閾値を更新することにより、広告の配信元を適切に選択することができる。

また、実施形態に係る広告配信管理システム１において、更新部２３５は、配信計画情報において閾値の更新時以降に予定されるリクエスト数に基づいて、閾値を更新する。

これにより、実施形態に係る広告配信管理システム１において、閾値の更新時以降に予定されるリクエスト数に応じて、閾値の変動割合が変化する。これにより、振分サーバ２００は、閾値の更新時以降に予定されるリクエスト数を考慮して閾値を更新することができるため、振分サーバ２００の配信実績が配信計画情報の配信スケジュールに近づく。したがって、振分サーバ２００は、更新時以降の広告配信の予定に基づいて閾値を更新することにより、広告の配信元を適切に選択することができる。

また、実施形態に係る広告配信管理システム１において、更新部２３５は、管理サーバ１００から受け付けた配信計画情報に基づく処理を開始してから所定の期間よりも短い期間（実施形態においては第２期間）内に閾値を更新する。また、決定部２３３は、更新部２３５により更新された閾値に基づいて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

これにより、実施形態に係る広告配信管理システム１において、複数の振分サーバ２００は、管理サーバ１００から配信計画情報を受け付けた後、各自の配信実績に基づいて各々自律して閾値を更新して配信処理を行う。したがって、広告配信管理システム１は、管理サーバ１００と各振分サーバ２００との間の通信負荷を抑制することができる。また、振分サーバ２００は、更新された閾値を用いることにより、広告の配信元を適切に選択することができる。

また、実施形態に係る広告配信管理システム１において、振分サーバ２００は、情報送信部２３４を有する。情報送信部２３４は、管理サーバ１００から受け付けた配信計画情報に基づく処理を開始してから所定の期間経過した後、所定の配信元に行わせた広告配信の実績に関する配信実績情報を管理サーバ１００に送信する。

これにより、実施形態に係る広告配信管理システム１において、管理サーバ１００は、複数の振分サーバ２００の配信実績情報を収集することができる。また、振分サーバ２００から管理サーバ１００へ配信実績情報が送信されるのは、所定の期間が経過した後であるため、広告配信管理システム１は、管理サーバ１００と各振分サーバ２００との間の通信負荷を抑制することができる。

また、実施形態に係る広告配信管理システム１において、送信部１３３は、各振分サーバ２００から取得した配信実績情報に基づいて更新された配信計画情報を、各振分サーバ２００に送信する。また、決定部２３３は、更新された配信計画情報と、閾値とに基づいて、複数の配信元からリクエストに対する広告配信を行う配信元を決定する。

これにより、実施形態に係る広告配信管理システム１において、管理サーバ１００は、より適切な配信計画情報に配信計画情報を更新することができる。また、管理サーバ１００から配信計画情報を受け付けた振分サーバ２００は、更新された配信計画情報を用いることにより、広告の配信元を適切に選択することができる。

〔６．ハードウェア構成〕
上述してきた実施形態に係る管理サーバ１００及び振分サーバ２００は、例えば図３３に示すような構成のコンピュータ１０００によって実現される。図３３は、管理サーバ及び振分サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００またはＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、所定のネットワークＮを介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを所定のネットワークＮを介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラムまたはデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disk）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る管理サーバ１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定のネットワークＮを介してこれらのプログラムを取得してもよい。

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の行に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

〔７．その他〕
また、上記各実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上述してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、受付部は、受付手段や受付回路に読み替えることができる。

１ 広告配信管理システム
１００ 管理サーバ
１２１ リクエスト情報記憶部
１２２ 配信元情報記憶部
１３０ 制御部
１３１ 取得部
１３２ 生成部
１３３ 送信部
２００ 振分サーバ
２２１ リクエスト情報記憶部
２２２ 配信計画情報記憶部
２３０ 制御部
２３１ 受付部
２３２ 推定部
２３３ 決定部
２３４ 情報送信部
２３５ 更新部

Claims (10)

1. 広告配信を要求するリクエストに応じて複数の配信元から広告配信を行わせる配信元を決定する複数の振分サーバと、前記複数の振分サーバを管理する管理サーバと、を有する広告配信管理システムであって、
   前記管理サーバは、
   所定の期間内において前記複数の配信元のうち所定の配信元に行わせる広告配信の計画に関する配信計画情報を各振分サーバに送信する送信部、
   を備え、
   前記各振分サーバは、
   前記リクエストを受け付ける受付部と、
   前記受付部により前記リクエストを受け付けた場合、前記リクエストに対して各配信元により広告が配信された場合に想定される広告の評価値に基づいて算出される値と、前記配信計画情報から得られる閾値とに応じて、前記複数の配信元から前記リクエストに対する広告配信を行う配信元を決定する決定部と、
   前記各振分サーバが受け付けたリクエストに対する前記所定の配信元による広告配信の進捗に基づいて前記閾値を更新する更新部と、
   を備えたことを特徴とする広告配信管理システム。
2. 前記送信部は、
   前記所定の期間内において前記所定の配信元に広告配信を行わせるリクエスト数に関する情報を含む配信計画情報を前記各振分サーバに送信し、
   前記更新部は、
   前記配信計画情報に含まれる前記リクエスト数に関する情報と、前記各振分サーバが前記所定の配信元に広告配信を行わせたリクエスト数とに基づいて前記閾値を更新する
   ことを特徴とする請求項１に記載の広告配信管理システム。
3. 前記更新部は、
   前記閾値の更新時において前記各振分サーバが前記所定の配信元に広告配信を行わせたリクエスト数が、前記配信計画情報において対応するリクエスト数よりも少ない場合、前記所定の配信元に広告配信を行わせるリクエスト数が多くなるように前記閾値を更新する
   ことを特徴とする請求項２に記載の広告配信管理システム。
4. 前記更新部は、
   前記閾値の更新時において前記各振分サーバが前記所定の配信元に広告配信を行わせたリクエスト数が、前記配信計画情報において対応するリクエスト数よりも多い場合、前記所定の配信元に広告配信を行わせるリクエスト数が少なくなるように前記閾値を更新する
   ことを特徴とする請求項２または請求項３に記載の広告配信管理システム。
5. 前記更新部は、
   前記配信計画情報において前記閾値の更新時以降に予定されるリクエスト数に基づいて、前記閾値を更新する
   ことを特徴とする請求項１〜４のいずれか１項に記載の広告配信管理システム。
6. 前記更新部は、
   前記管理サーバから受け付けた前記配信計画情報に基づく処理を開始してから前記所定の期間よりも短い期間内に前記閾値を更新し、
   前記決定部は、
   前記更新部により更新された閾値に基づいて、前記複数の配信元から前記リクエストに対する広告配信を行う配信元を決定する
   ことを特徴とする請求項１〜５のいずれか１項に記載の広告配信管理システム。
7. 前記各振分サーバは、
   前記管理サーバから受け付けた前記配信計画情報に基づく処理を開始してから前記所定の期間経過した後、前記所定の配信元に行わせた広告配信の実績に関する配信実績情報を前記管理サーバに送信する情報送信部、
   をさらに備えたことを特徴とする請求項１〜６のいずれか１項に記載の広告配信管理システム。
8. 前記送信部は、
   前記各振分サーバから取得した前記配信実績情報に基づいて更新された配信計画情報を、前記各振分サーバに送信し、
   前記決定部は、前記更新された配信計画情報と、前記閾値とに基づいて、前記複数の配信元から前記リクエストに対する広告配信を行う配信元を決定する
   ことを特徴とする請求項７に記載の広告配信管理システム。
9. 広告配信を要求するリクエストに応じて複数の配信元から広告配信を行わせる配信元を決定する複数の振分サーバと、前記複数の振分サーバを管理する管理サーバと、を有する広告配信管理システムで実行される広告配信管理方法であって、
   前記管理サーバは、
   所定の期間内において前記複数の配信元のうち所定の配信元に行わせる広告配信の計画に関する配信計画情報を各振分サーバに送信する計画送信工程と、
   前記各振分サーバは、
   前記リクエストを受け付ける受付工程と、
   前記受付工程により前記リクエストを受け付けた場合、前記リクエストに対して各配信元により広告が配信された場合に想定される広告の評価値に基づいて算出される値と、前記配信計画情報から得られる閾値とに応じて、前記複数の配信元から前記リクエストに対する広告配信を行う配信元を決定する決定工程と、
   前記各振分サーバが受け付けたリクエストに対する前記所定の配信元による広告配信の進捗に基づいて前記閾値を更新する更新工程と、
   を含むことを特徴とする広告配信管理方法。
10. 広告配信を要求するリクエストに応じて複数の配信元から広告配信を行わせる配信元を決定する複数の振分サーバと、前記複数の振分サーバを管理する管理サーバと、を有する広告配信管理システムにおいて、
    所定の期間内において前記複数の配信元のうち所定の配信元に行わせる広告配信の計画に関する配信計画情報を前記管理サーバから受け付けた振分サーバが実行する振分プログラムであって、
    広告配信を要求する前記リクエストを受け付ける受付手順と、
    前記受付手順により前記リクエストを受け付けた場合、前記リクエストに対して各配信元により広告が配信された場合に想定される広告の評価値に基づいて算出される値と、前記配信計画情報から得られる閾値とに応じて、前記複数の配信元から前記リクエストに対する広告配信を行う配信元を決定する決定手順と、
    前記振分サーバが受け付けたリクエストに対する前記所定の配信元による広告配信の進捗に基づいて前記閾値を更新する更新手順と、
    を振分サーバに実行させることを特徴とする振分プログラム。

Images