JP5683563B2 - 広告配信管理装置および広告配信管理方法 - Google Patents

Description

本発明は、広告配信管理装置および広告配信管理方法に関する。

近年、インターネットなどのネットワークの飛躍的な普及に伴い、ネットワークを介した広告配信が盛んに行われている。かかる広告配信の一つの形態として、広告配信の対象となるページ（以下、広告配信対象ページと記載する）内の一定スペースに画像や映像などを用いて広告を表示するディスプレイ広告が知られている。

ディスプレイ広告では、広告主によって指定されたユーザ属性（性別、年齢、興味など）を有するユーザに対して広告配信を行うことによって、効果的な広告配信が行われている（例えば、特許文献１参照）。

特開２０１１−２３８０２０号公報

上述した広告配信では、広告配信対象ページへアクセスしたユーザのユーザ属性が広告主によって指定されたユーザ属性である場合に、広告が配信される。そのため、将来の広告配信先となる配信対象ユーザを将来ログとして予測し、かかる将来ログに基づいて広告主からの注文を受け付けることが望ましい。

しかしながら、実際にアクセスするユーザと一致するように将来の広告配信先となる配信対象ユーザを正確に予測することは困難であることから、広告配信の注文要求に対する受け付け処理を精度よく行うことは難しい。

本願は、上記に鑑みてなされたものであって、広告配信の注文に対する受け付け処理を精度よく行うことができる広告配信管理装置および広告配信管理方法を提供することを目的とする。

本願に係る広告配信管理装置は、将来の広告配信先となる複数の配信対象ユーザを含む配信対象ユーザ群の情報を複数種類取得する取得手段と、前記複数種類の配信対象ユーザ群のそれぞれについて、広告配信の注文要求により指定される配信条件を満たすか否かを判定する判定手段と、前記判定手段による判定結果に基づき、前記広告配信の注文要求を受け付ける受付手段とを備えることを特徴とする。

実施形態の一態様によれば、広告配信の注文に対する受け付け処理を精度よく行うことができる広告配信管理装置および広告配信管理方法を提供することができる。

図１Ａは、実施形態に係る広告配信管理処理の説明図（その１）である。 図１Ｂは、実施形態に係る広告配信管理処理の説明図（その２）である。 図２は、実施形態に係る広告配信管理装置の構成を示す図である。 図３は、広告情報テーブルの一例を示す図である。 図４は、ユーザ情報テーブルの一例を示す図である。 図５は、アクセスログテーブルの一例を示す図である。 図６は、将来ログテーブルの一例を示す図である。 図７は、配信対象ユーザ群テーブルの一例を示す図である。 図８は、ユーザ属性の延べ総数の求め方を説明するための図である。 図９は、実施形態に係る広告配信管理装置の広告配信管理処理フローを示す図である。

以下に、本願に係る広告配信管理装置および広告配信管理方法を実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る広告配信管理装置および広告配信管理方法が限定されるものではない。また、以下においては、「データベース」を「ＤＢ」と記載するものとする。

〔１．広告配信管理処理〕
まず、実施形態に係る広告配信管理処理について説明する。図１Ａおよび図１Ｂは、実施形態に係る広告配信管理処理の説明図であり、かかる広告配信管理処理によって広告主からの注文に対する受け付け処理を精度よく行うことができる。

図１Ａに示すように、実施形態に係る広告配信管理システムは、広告配信管理装置１、情報配信装置２、広告主端末３およびユーザ端末４を有する。広告配信管理装置１、情報配信装置２、広告主端末３およびユーザ端末４は、互いに通信ネットワーク５を介して接続される。通信ネットワーク５は、例えば、インターネットなどのＩＰ（Internet Protocol）ネットワークである。なお、広告主端末３やユーザ端末４はそれぞれ複数存在するが、図１Ａでは説明の便宜上省略している。

広告主端末３は、広告配信を希望する広告主の端末装置であり、所定のユーザ属性を有するユーザのユーザ端末４に対して配信したい広告の注文（以下、注文要求と記載する）を広告配信管理装置１に対して行う。具体的には、広告主端末３は、注文主が広告配信対象ページへの掲載を望む広告情報および配信先として指定するユーザ属性の情報を含む注文要求を広告配信管理装置１へ送信する。広告情報として、例えば、バナー広告、テキスト広告、動画広告などの２次元コンテンツや３次元コンテンツなどがある。

ユーザ端末４は、広告配信管理装置１および情報配信装置２へアクセスするユーザの端末装置である。情報配信装置２は、ユーザ端末４からアクセスがあった場合、例えば、Ｗｅｂページなどの広告配信対象ページをユーザ端末４へ送信する。広告配信対象ページには、広告情報のＵＲＬ（Uniform Resource Locator）が含まれており、ユーザ端末４は、かかるＵＲＬに基づいて、広告配信管理装置１に対して広告情報を要求する。広告配信管理装置１は、ユーザ端末４から広告情報の要求を受信すると、要求に対応する広告情報をユーザ端末４へ送信する。なお、広告情報のＵＲＬは、広告配信管理装置１のＵＲＬではなく情報配信装置２のＵＲＬとすることもできる。この場合、ユーザ端末４は、広告情報のＵＲＬに基づいて、情報配信装置２に対して広告情報を要求する。かかる要求を受信した場合、情報配信装置２は、広告配信管理装置１へユーザ端末４に対する広告情報の送信要求を行う。広告配信管理装置１は、情報配信装置２からの送信要求に対応する広告情報をユーザ端末４へ送信する。

広告配信管理装置１は、広告配信の注文要求の受け付け処理、受け付けた注文要求に対するユーザ属性の割り当て処理、注文要求で指定された広告情報の配信を実行する処理を行うことによって、広告配信の注文の受け付けから配信までの処理を実行する。

広告配信管理装置１は、将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を将来ログ（予測情報）としてＤＢに記憶しており、かかる将来ログに基づいて、注文要求の受け付け処理を実行する。

図１Ａに示す例では、将来の広告配信先として予測される配信対象ユーザ６₁、６₂、…、６_n（以下、配信対象ユーザ６と総称する場合がある）の情報がＤＢに記憶されている。例えば、配信対象ユーザ６₁はユーザ属性Ａ〜Ｃを有する配信対象ユーザであり、配信対象ユーザ６₂はユーザ属性Ａ、Ｂ、Ｅを有する配信対象ユーザである。また、配信対象ユーザ６_nはユーザ属性Ｂ、Ｄ、Ｅを有する配信対象ユーザである。

広告配信管理装置１は、配信対象ユーザ６₁、６₂、…、６_nの中から所定割合Ｒ１（例えば、Ｒ１＝０．８）の配信対象ユーザをランダムに選択する処理を繰り返し行うことによって複数種類の配信対象ユーザ群の情報を取得する。図１Ｂに示す例では、広告配信管理装置１が、将来ログ７から、それぞれ異なる配信対象ユーザ群８₁、８₂、…、８_m（以下、配信対象ユーザ群８と総称する場合がある）の情報を取得している状態を示している。

広告配信管理装置１は、図１Ｂに示すように、広告配信の注文要求９を広告主端末３から受信すると、配信対象ユーザ群８₁〜８_mのそれぞれについて、注文要求９により指定される配信条件を満たすか否かを判定する。

注文要求９により指定される配信条件には、ユーザ属性や掲載回数などが含まれており、例えば、ユーザ属性が「属性Ａ」であり、掲載回数が「１０００」であるとする。また、ユーザ属性として「属性Ａ」を有する配信対象ユーザ６の数が、配信対象ユーザ群８₁では「１２００」であり、配信対象ユーザ群８₂では「１１２０」であり、配信対象ユーザ群８_mでは「９８０」であるとする。

この場合、広告配信の注文要求９により指定される配信条件を満たす配信対象ユーザ群８は、配信対象ユーザ群８₁、８₂などである。一方、配信対象ユーザ群８_mは、ユーザ属性Ａを有する配信対象ユーザ６の数が「９８０」であり、注文要求９で指定される掲載回数「１０００」を満たさない。

広告配信管理装置１は、配信対象ユーザ群８₁〜８_mのうち、注文要求９の配信条件を満たす配信対象ユーザ群８の割合が所定値Ｒ２（例えば、Ｒ２＝０．９）以上の場合に注文要求９を受け付ける。一方、広告配信管理装置１は、注文要求９の配信条件を満たす配信対象ユーザ群８の割合が所定値Ｒ２未満の場合には、注文要求９の受け付けを行わない。

このように、広告配信管理装置１は、将来の広告配信先となる複数の配信対象ユーザ６を含む複数種類の配信対象ユーザ群８₁〜８_mに対して広告配信の注文要求９により指定される配信条件を満たすか否かに基づいて、注文要求９を受け付けるか否かを判定する。これにより、注文要求９の配信条件を満たすか否かの判断を、複数の予測パターンについて行うことができることから、一つの予測パターンに対する判断に比べて、注文要求９の受け付け精度を向上させることができる。

また、広告配信管理装置１は、将来ログ７に含まれる配信対象ユーザ６₁、６₂、…、６_nの中から所定割合Ｒ１の配信対象ユーザ６をそれぞれランダムに選択することによって複数種類の配信対象ユーザ群８₁〜８_mの情報を取得する。これにより、異なる予測パターンを容易に生成することが可能となる。なお、ここでは配信対象ユーザ６をランダムに選択することにしているが、一例であり、所定の規則に基づいて選択してもよい。また、複数種類の将来ログを予測し、かかる複数種類の将来ログをそれぞれ配信対象ユーザ群８₁〜８_mとしてもよい。

また、広告配信管理装置１は、複数種類の配信対象ユーザ群８₁〜８_mのうち配信条件を満たす配信対象ユーザ群８の割合が所定値Ｒ２以上である場合に、広告配信の注文要求９を受け付ける。これにより、注文要求９の受け付け精度をさらに向上させることができる。すなわち、配信対象ユーザ群８の数が多いほど、注文要求９の配信条件を満たす配信対象ユーザ群８の割合が低くなり、注文要求９の受け付け精度が却って悪くなる恐れがあるが、所定値Ｒ２を調整することで、注文要求９の受け付けを精度よく行うことができる。

以下、上述した広告配信管理処理を実行する広告配信管理装置１について、具体的構成および具体的処理の内容について図面を参照して説明する。

〔２．広告配信管理装置１の構成〕
図２は、実施形態に係る広告配信管理装置１の構成を示す図である。図２に示すように、広告配信管理装置１は通信部１０と、広告情報ＤＢ１１と、ユーザ情報ＤＢ１２と、過去ログＤＢ１３と、将来ログＤＢ１４と、制御部１５とを有する。さらに制御部１５は、広告配信部２１と、将来ログ予測部２２と、受付部２３と、割当部２４とを有する。

通信部１０は、ＮＩＣ（Network Interface Card）等のインタフェースである。制御部１５は、通信部１０および通信ネットワーク５を介して、広告主端末３やユーザ端末４との間で各種の情報を送受信する。広告情報ＤＢ１１、ユーザ情報ＤＢ１２、過去ログＤＢ１３および将来ログＤＢ１４は、例えば、ハードディスク、ＲＡＭ（Random Access Memory)、フラッシュメモリ等の半導体メモリ素子、光ディスク等の記憶装置である。

制御部１５は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。また、制御部１５は、ＣＰＵ（Central Processing Unit）またはＭＰＵ（Micro Processing Unit）によって内部の記憶装置に記憶されたプログラムがＲＡＭを作業領域として実行されることで、広告配信部２１、将来ログ予測部２２、受付部２３および割当部２４として機能する。なお、制御部１５の構成は、かかる構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

（広告配信部２１について）
広告配信部２１は、ユーザ端末４から広告情報の配信要求があった場合に、ユーザ端末４のユーザが有するユーザ属性に応じた広告情報を広告情報ＤＢ１１の広告情報テーブルから取得し、取得した広告情報を通信部１０から配信要求元のユーザ端末４へ送信する。

図３は、広告情報ＤＢ１１に記憶された広告情報テーブルの一例を示す図である。図３に示すように、広告情報テーブルには、「広告ＩＤ」毎に、「ユーザ属性」、「掲載期間」、「掲載回数」および「広告情報」が関連付けられた情報が含まれる。

「広告ＩＤ」は、受け付けられた注文要求毎に割り当てられる識別情報である。「ユーザ属性」は、注文要求で指定されたユーザ属性であり、「掲載期間」は、注文要求で指定された広告情報の配信期間であり、「掲載回数」は、注文要求で指定された広告情報の配信回数である。また、「広告情報」は、注文要求で指定された広告情報である。

例えば、広告ＩＤ「Ａ０００１」では、配信対象のユーザ属性が「車」であり、広告情報の配信期間が「２０１３年１月１日〜１月３１日」であり、広告情報の配信回数が「１０００」であり、広告情報が「バナー広告Ｙａ」であることを示す。なお、広告情報の配信期間内であっても広告情報の配信回数が「１０００」を超えた場合に、注文要求に対する広告情報の配信処理が終了する。

広告配信部２１は、広告情報の配信要求を行ったユーザ端末４のユーザがユーザ属性「車」を有する場合、例えば、広告情報ＤＢ１１の広告情報テーブルから広告ＩＤ「Ａ０００１」の広告情報「バナー広告Ｙａ」を取得し、配信要求元のユーザ端末４へ送信する。

ユーザ端末４のユーザが有するユーザ属性は、ユーザ情報ＤＢ１２のユーザ情報テーブルに基づいて判定される。図４は、ユーザ情報ＤＢ１２に記憶されたユーザ情報テーブルの一例を示す図である。図４に示すように、ユーザ情報テーブルには、「ユーザＩＤ」、「サイコグラフィック属性」、「デモグラフィック属性」などの情報を有する。

「ユーザＩＤ」は、ユーザ端末４を利用するユーザを識別するための識別情報である。かかる「ユーザＩＤ」は、例えば、広告配信管理装置１とユーザ端末４との間で送受信されるＨＴＴＰクッキー（HyperText Transfer Protocol Cookie）に設定されるユーザ識別情報に該当する。

「サイコグラフィック属性」は、ユーザの価値観、ライフスタイル、性格、嗜好などを示す情報である。かかる「サイコグラフィック属性」は、例えば、「車」、「化粧品」、「服」、「旅行」などの属性区分に分類される。図４に示す例では、属性区分毎に、ユーザの嗜好が相対的に高い場合に「１」が記憶され、それ以外の場合には「０」が記憶される。また、「サイコグラフィック属性」は、図４に示した属性区分の例に限られず、経済、政治、野球、サッカー、その他スポーツ、スイーツ、パソコン、白物家電、家具など様々な属性区分が含まれてもよい。

「デモグラフィック属性」は、人口統計学的なユーザの属性情報を示す。かかる「デモグラフィック属性」は、例えば、ユーザの「性別」、「年齢」などの属性区分に分類される。図４に示す「性別」には、ユーザが女性である場合には「１」が記憶され、ユーザが男性である場合には「２」が記憶される。また、「年齢」には、ユーザの年齢が記憶される。なお、「デモグラフィック属性」は、図４に示した属性区分の例に限られず、ユーザの職業、家族構成、年収、住所、出身地、学歴など様々な属性区分が含まれてもよい。

例えば、図４に示すユーザＩＤ「Ｕ０００１」のユーザがユーザ端末４から広告情報の配信要求を行った場合、かかるユーザのユーザ属性が「車」、「旅行」、「男性」、「２１才」などであることを判定する。また、例えば、図４に示すユーザＩＤ「Ｕ０００２」のユーザがユーザ端末４から広告情報の配信要求を行った場合、広告配信部２１は、かかるユーザのユーザ属性が「服」、「女性」、「４４才」などであることを判定する。

また、広告配信部２１は、広告情報の配信要求を行ったユーザのユーザＩＤを過去ログＤＢ１３のアクセスログテーブルに設定する。図５は、過去ログＤＢ１３に記憶されるアクセスログテーブルの一例を示す図である。

図５に示すように、アクセスログテーブルには、ユーザが広告配信管理装置１に対して広告情報の配信要求を行った日時とユーザＩＤとを関連付けた情報（以下、過去ログと記載する場合がある）が設定されるテーブルである。広告配信部２１は、ユーザ端末４から広告情報の配信要求がある毎に、アクセスログテーブルを更新する。

なお、広告配信部２１は、情報配信装置２からユーザ端末４に対する広告情報の送信要求があった場合も同様に、ユーザ端末４のユーザが有するユーザ属性に応じた広告情報を広告情報ＤＢ１１の広告情報テーブルから取得し、取得した広告情報を通信部１０からユーザ端末４へ送信する。なお、情報配信装置２からの送信要求には、ユーザ端末４のユーザのユーザＩＤが含まれ、かかるユーザＩＤに基づき、広告配信部２１は、ユーザ端末４のユーザが有するユーザ属性に応じた広告情報を広告情報テーブルから取得する。

（将来ログ予測部２２について）
将来ログ予測部２２は、過去ログＤＢ１３に記憶されたアクセスログテーブルに基づいて、将来の広告配信先として予測される複数の配信対象ユーザを判定し、判定した配信対象ユーザのユーザ情報を将来ログＤＢ１４の将来ログテーブルに設定する。

図６は、将来ログＤＢ１４に記憶される将来ログテーブルの一例を示す図である。図６に示すように、将来ログテーブルは、将来の所定期間に広告配信先として予測される配信対象ユーザに関する情報（以下、将来ログと記載する場合がある）が設定される。図６に示す将来ログテーブルには、「配信対象ＩＤ」、「割り当て状態」、「サイコグラフィック属性」、「デモグラフィック属性」などの将来ログの情報が含まれる。

「配信対象ＩＤ」は、将来の広告配信先として予測される配信対象ユーザ毎に割り当てられる識別情報である。かかる配信対象ユーザは、ユーザ情報ＤＢ１２のユーザ情報テーブルに設定されるユーザとは異なる仮想的なユーザである。

「割り当て状態」は、注文要求に対して割り当てられた配信対象ユーザであるか否かを示す情報である。注文要求に対して割り当てられた配信対象ユーザ（以下、割り当て済みユーザと記載する場合がある）である場合には「１」が設定され、注文要求に対して割り当てられていない配信対象ユーザ（以下、未割り当てユーザと記載する場合がある）である場合には「０」が設定される。

「サイコグラフィック属性」および「デモグラフィック属性」は、ユーザ情報ＤＢ１２のユーザ情報テーブルと同様の項目である。なお、ユーザ情報テーブルに設定されているユーザを配信対象ユーザとして推定し、配信対象ＩＤをユーザＩＤとすることもできる。この場合、「サイコグラフィック属性」および「デモグラフィック属性」の情報は、ユーザＩＤに基づいてユーザ情報テーブルから取得することができる。

将来ログ予測部２２は、将来の所定期間に広告配信先となる配信対象ユーザの予測を、１年前の同時期のアクセスログや直前の所定期間のアクセスログなどから行うことができる。例えば、将来ログ予測部２２は、直前の過去１ヶ月間に広告情報の配信要求を行ったユーザを将来の１ヶ月間の配信対象ユーザと推定することができる。

また、将来ログ予測部２２は、アクセスログテーブルに設定された過去ログを統計処理することによって、将来の広告配信先となる配信対象ユーザの傾向を判定し、かかる判定結果に基づいて、将来ログを予測することもできる。この場合、例えば、天候や気温などの変動情報を加味して配信対象ユーザの傾向を判定するようにしてもよい。

なお、将来ログ予測部２２は、予測した将来ログを将来ログテーブルに設定することができるが、外部装置から通信部１０を介して取得された将来ログを将来ログテーブルに設定することもできる。

また、異なる規則に従って配信対象ユーザを予測する複数の将来ログ予測部２２を設けることもできる。このようにすることで、複数の異なる将来ログ（以下、予測パターンと記載する場合がある）の情報を取得することができる。

（受付部２３について）
受付部２３は、将来ログテーブルに設定された将来ログに基づいて、広告主端末３からの注文要求を受け付けるか否かを判定し、注文要求を受け付ける場合に、広告主端末３に対して注文受付応答を行う。広告主端末３からの注文要求には、上述のように、ユーザ属性および掲載回数などの指定情報が含まれている。

受付部２３が行う受け付け処理には、例えば、配信対象ユーザ群の取得処理、注文要求の配信条件に対する各配信対象ユーザ群の充足判定処理、および、注文要求に対する受け付け判定処理が含まれる。以下、それぞれの処理について具体的に説明する。

（受付部２３による取得処理）
まず、配信対象ユーザ群の取得処理について説明する。かかる処理において、受付部２３は、将来ログテーブルに含まれる未割り当てユーザの中から所定割合Ｒ１の未割り当てユーザをランダムに選択する処理を繰り返し行うことによって複数種類の配信対象ユーザ群の情報を取得する。

例えば、将来ログテーブルに含まれる未割り当てユーザの数が「１０００」であり、所定割合Ｒ１が「０．８」に設定されているとする。この場合、受付部２３は、将来ログテーブルから未割り当てユーザを８００回（＝１０００×０．８）選択する処理をｍ（ｍは２以上の整数）回繰り返す。

これにより、受付部２３は、「８００」の未割り当てユーザをそれぞれ含むｍ個の配信対象ユーザ群の情報を将来ログテーブルから取得することができる。受付部２３は、所定割合Ｒ１の未割り当てユーザを選択する毎に、配信対象ユーザ群として配信対象ユーザ群テーブルに設定する。図７は、配信対象ユーザ群テーブルの一例を示す図である。

これにより、将来ログテーブルに基づいて異なる将来ログ（予測パターン）を容易に生成することが可能となる。すなわち、将来ログ予測部２２によって複数種類の将来ログを生成する場合には、複数種類の異なる予測規則が必要になるが、将来ログテーブルから配信対象ユーザをサンプリングすることで、将来ログ予測部２２における予測規則の増加を抑制できる。

また、将来ログテーブルから配信対象ユーザをサンプリングすることから、受付部２３によって取得される配信対象ユーザ群は、将来ログテーブルに対して、ユーザ属性の分布傾向に関連性を有するといった特徴がある。これにより、例えば、将来ログ予測部２２による予測精度が高い場合には、受け付け判定処理における注文要求の受け付けをより精度よく行うことができる。

また、配信対象ユーザ群を構成する配信対象ユーザの数が少なくなるほど、将来ログテーブルに対してユーザ属性の分布傾向に関連性が低くなり、未割り当てユーザの数に応じて予測パターン間の関連性を変化させることができるという特徴もある。これにより、配信対象ユーザの数が少なくなるほど、後述する配信条件の充足判定が厳しくなることから、これによっても、受け付け判定処理における注文要求の受け付けをより精度よく行うことができる。

なお、所定割合Ｒ１は、広告配信管理装置１の管理者によって図示しない操作部を介して制御部１５に設定することができる。また、受付部２３は、将来ログテーブルにおける未割り当てユーザの数に応じて、所定割合Ｒ１を変更することもできる。

例えば、受付部２３は、将来ログテーブルにおける未割り当てユーザの数が相対的に多い場合には、所定割合Ｒ１を大きくし、将来ログテーブルにおける未割り当てユーザの数が相対的に少ない場合には、所定割合Ｒ１を小さくする。このようにすることで、受け付け処理をより精度よく行うことができる。

また、配信対象ユーザ群の取得処理において、受付部２３は、配信対象ユーザの選択をランダムに行うことに代えて、それ以外の異なる規則に基づいて配信対象ユーザを選択することもできる。例えば、受付部２３は、将来ログテーブルに含まれる未割り当てユーザの中から所定割合Ｒ３（＝１−Ｒ１）の未割り当てユーザをランダムに取り除き、残った未割り当てユーザを配信対象ユーザ群とすることができる。

また、受付部２３は、例えば、将来ログテーブルの未割り当てユーザが設定された行のうちｋ行目（１≦ｋ≦ｍ）を複数数行除外した未割り当てユーザを配信対象ユーザ群として取得することもできる。例えば、所定割合Ｒ１が「０．８」であり、ｍが「１０」であるとする。

この場合、受付部２３は、第１の配信対象ユーザ群については、将来ログテーブルにおいて、３〜１０行目、１３〜２０行目、・・・というように下一桁が「１」および「２」の行に設定された未割り当てユーザを除外する。また、受付部２３は、第２の配信対象ユーザ群については、将来ログテーブルにおいて、１行目、４〜１０行目、１１行目、１４〜２０行目、・・・というように下一桁が「２」および「３」の行に設定された未割り当てユーザを除外する。

また、受付部２３は、将来ログテーブルに含まれる未割り当てユーザの中から所定割合Ｒ１の未割り当てユーザをランダムに選択し、さらに選択した未割り当てユーザに所定係数Ｋ１（＞１）を乗じた処理を繰り返し行うことによって複数種類の配信対象ユーザ群の情報を取得することもできる。受付部２３は、所定係数Ｋ１を、例えば、１／Ｒ１とする。所定係数Ｋ１を１／Ｒ１とする場合、所定係数Ｋ１が整数になるように、所定割合Ｒ１を設定することが望ましい。

このように所定係数Ｋ１を乗じることによって、受付部２３は、将来ログテーブルに含まれる未割り当てユーザの数に応じた配信対象ユーザ群をより精度よく設定することができる。なお、所定係数Ｋ１が整数ではない場合、所定係数Ｋ１を乗じると、配信対象ユーザ群を構成する未割り当てユーザの数に小数点以下の端数がでるおそれがある。そのため、受付部２３は、例えば、所定条件に基づき、配信対象ユーザ群を構成する未割り当てユーザに対する所定係数Ｋ１の乗算結果に対し、四捨五入、切り捨てまたは切り上げを行うことができる。これにより、各配信対象ユーザ群を構成する未割り当てユーザの総数を、将来ログテーブルに含まれる未割り当てユーザの総数と一致または略一致した数とすることができる。

なお、上述のように複数の将来ログ予測部２２によって複数種類の将来ログを生成する場合には、受付部２３は、将来ログ予測部２２から複数種類の将来ログをそのまま複数種類の配信対象ユーザ群として取得することもできる。

（受付部２３による充足判定処理）
次に、注文要求の配信条件に対する各配信対象ユーザ群の充足判定処理について説明する。かかる処理において、受付部２３は、複数種類の配信対象ユーザ群のそれぞれについて、広告配信の注文要求により指定される配信条件を満たすか否かを判定する。

具体的には、受付部２３は、配信対象ユーザ群に含まれる配信対象ユーザのうち注文要求で指定されたユーザ属性を有する配信対象ユーザの数をカウントする。受付部２３は、かかるカウント結果が注文要求で指定された掲載回数以上である場合に、注文要求により指定される配信条件を満たすと判定する。

例えば、受付部２３は、注文要求によって指定されるユーザ属性が「車」であり、掲載回数が「１０００」である場合、各配信対象ユーザ群に含まれる配信対象ユーザのうち「車」の属性区分に「１」が設定されている配信対象ユーザの数をカウントする。そして、受付部２３は、カウント結果が「１０００」以上である場合、配信対象ユーザ群が注文要求の配信条件を満たすと判定し、カウント結果が「１０００」未満である場合、配信対象ユーザ群が注文要求の配信条件を満たさないと判定する。

また、受付部２３は、注文要求で指定される頻度が閾値以上ある２以上のユーザ属性の組み合わせを一つのユーザ属性（以下、結合ユーザ属性と記載する場合がある）としてカウントする。例えば、「服」および「旅行」の組み合わせが注文要求で指定される頻度が高い場合、受付部２３は、「服」および「旅行」の組み合わせを一つのユーザ属性としてカウントする。

広告情報ＤＢ１１の広告情報テーブルには受付部２３によって受け付けた注文要求の情報が設定されており、かかる広告情報テーブルに基づき、受付部２３は、注文要求で指定される頻度が閾値以上ある２以上のユーザ属性の組み合わせを判定できる。

例えば、受付部２３は、広告情報テーブルに基づき、過去の注文要求で指定された掲載回数の合計を第１の合計値として求め、また、２以上のユーザ属性の組み合わせ毎に過去の注文要求で指定された掲載回数の合計を第２の合計値として求める。そして、受付部２３は、第１の合計値に対する第２の合計値の比が所定閾値以上のユーザ属性の組み合わせを一つのユーザ属性としてカウントする。

「服」および「旅行」の組み合わせが注文要求で指定される頻度が高く、また、将来ログテーブルが図６に示す状態である場合、配信対象ＩＤ「Ｆ０００２」の配信対象ユーザのユーザ属性は、「服」や「旅行」ではなく「服＆旅行」となる。

なお、注文要求で指定される頻度が閾値以上ある２以上のユーザ属性の組み合わせは、受付部２３で判定するのではなく、外部装置などから別途ユーザ情報ＤＢ１２に設定するようにしてもよい。

また、受付部２３は、将来ログテーブルにおいて未割り当てユーザの数が所定値以下となった場合や結合ユーザ属性を有する未割り当てユーザの数が所定値以下となった場合などにおいて、結合ユーザ属性を複数のユーザ属性に分割することができる。これによりユーザ属性の総数を増加させることができ、その結果、結合ユーザ属性を指定した注文要求の受け付け可能性が低減するものの、他の注文要求の受け付け可能性を増加させることができる。

（受付部２３による受け付け判定処理）
次に、注文要求に対する受け付け判定処理について説明する。かかる処理において、受付部２３は、上述した充足判定処理に基づき、広告配信の注文要求を受け付けるか否かを判定する。

具体的には、受付部２３は、複数種類の配信対象ユーザ群のうち配信条件を満たす配信対象ユーザ群の割合が所定値Ｒ２以上の場合に広告配信の注文要求を受け付ける。例えば、配信対象ユーザ群の数が「１０」であり、所定値Ｒ２が「０．８」である場合、配信条件を満たす配信対象ユーザ群が「８」以上であれば広告配信の注文要求を受け付ける。

なお、所定値Ｒ２は、広告配信管理装置１の管理者によって図示しない操作部を介して制御部１５に設定することができる。また、受付部２３は、将来ログテーブルにおける未割り当てユーザの数に応じて所定値Ｒ２を変更することもできる。

例えば、受付部２３は、将来ログテーブルにおける未割り当てユーザの数が相対的に多い場合には、所定値Ｒ２を小さくし、将来ログテーブルにおける未割り当てユーザの数が相対的に少ない場合には、所定値Ｒ２を大きくする。このようにすることで、受け付け処理をより精度よく行うことができる。

また、上述において、受付部２３は、将来ログテーブルにおける未割り当てユーザの中から配信対象ユーザ群を構成する配信対象ユーザを選択しているが、将来ログテーブルに含まれる配信対象ユーザ全体の中から配信対象ユーザ群を構成する配信対象ユーザを選択することもできる。「配信対象ユーザ全体」とは、未割り当てユーザのみならず割り当て済みユーザを含む配信対象ユーザであり、未割り当てユーザの数が「２０００」であり、割り当て済みユーザの数が「８０００」である場合、配信対象ユーザ全体の数は「１００００」である。

この場合、受付部２３は、広告主端末３からの新たな広告配信の注文要求に加えて、すでに受け付け済みの注文要求を含めて一つの注文要求として処理する。例えば、すでに受け付け済みの注文要求が図３に示す広告ＩＤ「Ａ０００１」〜「Ａ０００３」の注文要求であるとし、新たな注文要求において、指定されるユーザ属性が「車」、指定される掲載回数が「１０００」であるとする。

受付部２３は、ユーザ属性「車」を有する配信対象ユーザ、ユーザ属性「車＆旅行」を有する配信対象ユーザ、ユーザ属性「男性＆２０代」を有する配信対象ユーザがそれぞれ別個に「１０００」、「２０００」、「１５００」以上ある配信対象ユーザ群を注文要求の配信条件を満たす配信対象ユーザ群と判定する。

（割当部２４について）
割当部２４は、新たな広告配信の注文要求を受付部２３で受け付ける毎に、かかる注文要求に対して配信対象ユーザを割り当てる。かかる割り当て処理は、将来ログテーブルに設定された配信対象ユーザの注文要求に対する割り当て状態に応じた割り当てスコアを求め、新たな広告配信の注文要求に対する配信対象ユーザの割り当て前後で割り当てスコアの減少が最小となるように行われる。割当部２４は、受付部２３と同様に、結合ユーザ属性を一つのユーザ属性として取り扱う。

まず、割り当てスコアについて説明する。割当部２４は、図６に示す将来ログテーブルに設定された複数の配信対象ユーザのうち未割り当てユーザの「ユーザ属性の延べ総数」をカウントする。未割り当てユーザは、将来ログテーブルにおいて「割り当て状態」が「０」に設定されている配信対象ユーザである。

「ユーザ属性の延べ総数」は、未割り当てユーザの「ユーザ属性の数」の合計値である。例えば、未割り当てユーザが１０００人である場合、１０００人の未割り当てユーザの「ユーザ属性の数」を合計した数が「ユーザ属性の延べ総数」である。

「ユーザ属性の数」は、ユーザ属性の属性区分別の有効に設定されている配信対象ユーザの数である。属性区分は、「サイコグラフィック属性」の場合、「車」、「化粧品」、「服」、「旅行」などのそれぞれを意味し、「デモグラフィック属性」の場合、「性別」、「年齢」などのそれぞれを意味する。

また、有効に設定されている配信対象ユーザとは、「サイコグラフィック属性」の場合、対応する属性区分に「１」が設定されている配信対象ユーザであり、「デモグラフィック属性」の場合、属性区分に情報が設定されている配信対象ユーザである。

例えば、「サイコグラフィック属性」が「車」、「化粧品」、「服」および「旅行」の４つの属性区分のみであり、「デモグラフィック属性」が「性別」および「年齢」の２つの属性区分のみであるとする。この場合、「ユーザ属性の数」の最大値は「６」である。

注文要求に割り当てられていない配信対象ユーザは、図６に示す例では、配信対象ＩＤ「Ｆ０００１」、「Ｆ０００３」、「Ｆ０００４」、「Ｆ０００６」の配信対象ユーザである。この場合、図８に示すように、配信対象ＩＤ「Ｆ０００１」、「Ｆ０００３」、「Ｆ０００４」、「Ｆ０００６」に対応する配信対象ユーザの「ユーザ属性の数」は、それぞれ「４」、「２」、「３」、「６」である。したがって、注文要求に割り当てられていない配信対象ユーザの「ユーザ属性の数」の合計値である「ユーザ属性の延べ総数」は、図８に示すように、「１５（＝４＋２＋３＋６）」であり、割り当てスコアは「１５」である。

なお、割当部２４は、「サイコグラフィック属性」のみを対象とした「ユーザ属性の延べ総数」を割り当てスコアとすることもでき、また、「デモグラフィック属性」のみを対象とした「ユーザ属性の延べ総数」を割り当てスコアとすることもできる。また、割当部２４は、「サイコグラフィック属性」や「デモグラフィック属性」の一部の属性区分のみを対象として「ユーザ属性の延べ総数」を割り当てスコアとすることもできる。

また、「ユーザ属性の延べ総数」を割り当てスコアとするのではなく、他の指標を割り当てスコアとすることもできる。例えば、割当部２４は、未割り当てユーザの数または比率が最も少ないユーザ属性の未割り当てユーザの数または比率を割り当てスコアとすることもできる。

次に、新たな広告配信の注文要求に対する配信対象ユーザの割り当てについて説明する。割当部２４は、新たな広告配信の注文要求で指定されたユーザ属性を有する未割り当てユーザを注文要求で指定された掲載回数分だけ将来ログテーブルから選択し、かかる選択した未割り当てユーザを注文要求に割り当てた前後での割り当てスコアの減少値を判定する。

広告配信の注文要求で指定されたユーザ属性を有する未割り当てユーザが注文要求で指定された掲載回数分しか将来ログテーブルに設定されていない場合を除き、注文要求で指定された掲載回数分の未割り当てユーザの組み合わせは複数ある。例えば、広告配信の注文要求で指定されたユーザ属性を有する未割り当てユーザの数が「１０」であり、注文要求で指定された掲載回数分が「５」である場合、未割り当てユーザの組み合わせは「２５２」である。

割当部２４は、注文要求で指定された掲載回数分の未割り当てユーザの組み合わせのすべてに対して注文要求に割り当てた前後での割り当てスコアの減少値が最も少ない未割り当てユーザの組み合わせを判定する。そして、最も減少値が少ないと判定した組み合わせの未割り当てユーザを選択して注文要求に割り当てる。

なお、割当部２４は、受付部２３によって配信条件を満たす配信対象ユーザ群のうち一つの配信対象ユーザ群を選択し、かかる配信対象ユーザ群を構成する未割り当てユーザの中から注文要求に対する配信対象ユーザの割り当て前後で割り当てスコアの減少が最小となるように割り当て処理を行うこともできる。このようにすることで、割り当て処理で割り当てスコアを判定する未割り当てユーザの組み合わせの数を抑制することができ、割当部２４の処理負荷を低減することができる。

この場合、割当部２４は、例えば、受付部２３によって配信条件を満たす配信対象ユーザ群のうち、注文要求で指定されるユーザ属性を最も多く含む配信対象ユーザ群を注文要求の割り当て対象とすることができる。このようにすることで、割当部２４の処理負荷を低減しつつも、配信対象ユーザの適切な割り当てを行うことができる。

〔３．広告配信管理装置１の処理フロー〕
次に、実施形態に係る広告配信管理装置１による広告配信管理処理の手順について説明する。図９は、実施形態に係る広告配信管理装置１の広告配信管理処理フローの一例を示す図である。かかる広告配信管理処理フローは、広告主端末３から広告配信の注文要求があった場合に開始される。

広告配信管理装置１の制御部１５は、広告主端末３から広告配信の注文要求を通信部１０で受信すると、図９に示すように、配信対象ユーザ群の取得処理を行う（ステップＳ１１）。かかる処理において、制御部１５は、将来ログＤＢ１４に記憶された将来ログテーブルから配信対象ユーザを所定の規則に従って選択する処理を繰り返し行うことによって複数種類の配信対象ユーザ群の情報を取得する。

次に、制御部１５は、配信条件充足処理を行う（ステップＳ１２）。かかる処理において、制御部１５は、複数種類の配信対象ユーザ群のそれぞれについて、広告配信の注文要求により指定される配信条件を満たすか否かを判定する。

次に、制御部１５は、広告配信の注文要求を受け付け可能か否かを判定する（ステップＳ１３）。かかる処理において、制御部１５は、ステップＳ１１にて取得した複数種類の配信対象ユーザ群のうち配信条件を満たす配信対象ユーザ群の割合が所定値以上の場合に広告配信の注文要求を受け付け可能と判定する。

広告配信の注文要求を受け付け可能であると判定すると（ステップＳ１３；Ｙｅｓ）、制御部１５は、注文要求に含まれる情報を広告情報テーブルに設定して広告情報テーブルを更新する（ステップＳ１４）。なお、注文要求に含まれる情報には、ユーザ属性、掲載期間、掲載回数および広告情報などが含まれており、これらの情報が広告情報テーブルに設定される。

次に、制御部１５は、配信対象ユーザの割り当て処理を行う（ステップＳ１５）。かかる割り当て処理によって、注文要求で指定されたユーザ属性を有する未割り当てユーザが注文要求に対して割り当てられる。

次に、制御部１５は、ステップＳ１５の割り当て処理の結果に基づき、将来ログテーブルの更新を行う（ステップＳ１６）。具体的には、制御部１５は、将来ログテーブルに設定されている未割り当てユーザのうち注文要求に対して割り当てた未割り当てユーザを割り当て済ユーザに変更する。未割り当てユーザから割り当て済みユーザへの変更は、「割り当て状態」を「０」から「１」へ変更することによって行われる。

その後、制御部１５は、通信部１０を介して注文受付応答を広告主端末３へ送信し（ステップＳ１７）、広告配信管理処理を終了する。一方、ステップＳ１３において、広告主端末３からの注文要求を受け付けできないと判定した場合（ステップＳ１３；Ｎｏ）、制御部１５は、通信部１０を介して注文拒否応答を広告主端末３へ送信し（ステップＳ１８）、広告配信管理処理を終了する。

〔４．変形例〕
上述した実施形態では、受付部２３は、複数種類の配信対象ユーザ群のうち前記判定手段によって配信条件を満たす配信対象ユーザ群の割合が所定値以上の場合に広告配信の注文要求を受け付けるようにしたが、かかる受け付け判定処理に限定されるものではない。例えば、受付部２３は、配信条件に対する各配信対象ユーザ群の充足率に基づいて広告配信の注文要求を受け付けることもできる。

例えば、第１〜第３の配信対象ユーザ群がそれぞれユーザ属性「車」を有する配信対象ユーザの数が「２０００」、「１４００」、「１０００」であり、配信条件がユーザ属性「車」の配信数が「１５００」であるとする。

この場合、第１の配信対象ユーザ群に対する配信条件の充足率は、１．２５（＝２０００／１５００）、第２の配信対象ユーザ群に対する配信条件の充足率は、０．９３（＝１４００／１５００）、第３の配信対象ユーザ群の配信条件に対する充足率は、０．６７（＝１０００／１５００）である。

したがって、第１〜第３の配信対象ユーザ群の配信条件に対する充足率の平均は、０．９５である。受付部２３は、かかる充足率の平均が所定値Ｒ４（例えば、０．９）以上である場合に、広告配信の注文要求を受け付けると判定することができる。

また、受付部２３は、複数種類の配信対象ユーザ群のうち配信条件を満たす配信対象ユーザ群の割合が所定範囲（例えば、０．８〜０．９）である場合に、配信対象ユーザ群の配信条件に対する充足率の平均を演算してもよい。この場合、受付部２３は、かかる充足率の平均が所定値Ｒ４である場合に、広告配信の注文要求を受け付けると判定することができる。

また、上述では、所定割合Ｒ１や所定値Ｒ２は、広告配信管理装置１の管理者による設定や、将来ログテーブルにおける未割り当てユーザの数に応じて変更することができるものとして説明したが、他の要因によっても変更が可能である。例えば、将来ログ予測部２２によって予測される将来ログと、実際に広告情報を配信したユーザのユーザ属性との一致度（以下、予測一致度とする）に基づいて所定割合Ｒ１や所定値Ｒ２を変更することができる。

例えば、予測一致度が低い場合には、所定割合Ｒ１や所定値Ｒ２を小さくし、予測一致度が高い場合には、所定割合Ｒ１や所定値Ｒ２を大きくする。このようにすることで、注文要求の受け付けを精度よく行うことができる。

〔５．効果〕
実施形態にかかる広告配信管理装置１において、受付部２３（取得手段の一例に相当）が、将来の広告配信先となる複数の配信対象ユーザを含む配信対象ユーザ群の情報を複数種類取得し、受付部２３（判定手段の一例に相当）が、複数種類の配信対象ユーザ群のそれぞれについて、広告配信の注文要求により指定される配信条件を満たすか否かを判定し、受付部２３（受付手段の一例に相当）が、かかる判定結果に基づき、広告配信の注文要求を受け付ける。

かかる構成により、広告配信の配信条件を満たすか否かの判断を、複数の予測パターンについて行うことができることから、一つの予測パターンに対する判断に比べて、注文要求の受け付け精度を向上させることができる。これにより、販売機会の損失を抑制することができ、また、実際には受け付けできない注文要求の受け付けを抑制できる。

また、受付部２３が、複数種類の配信対象ユーザ群のうち配信条件を満たす配信対象ユーザ群の割合が所定値以上の場合に広告配信の注文要求を受け付ける。

かかる構成により、注文要求の受け付け精度をさらに向上させることができる。すなわち、配信対象ユーザ群の数が多いほど、注文要求の配信条件を満たす配信対象ユーザ群の割合が低くなり、注文要求の受け付け精度が却って悪くなる恐れがあるが、所定値を調整することで、注文要求の受け付けを精度よく行うことができる。

また、将来ログ予測部２２（予測手段の一例に相当）が、将来の広告配信先となる複数の配信対象ユーザを予測し、受付部２３が、複数の配信対象ユーザのうち所定割合の配信対象ユーザを所定の規則に従って選択する処理を繰り返し行うことによって複数種類の配信対象ユーザ群の情報を取得する。

かかる構成により、異なる予測パターンを容易に取得することが可能となる。また、これらの予測パターンは、将来ログ予測部２２によって予測される一つの予測パターンから取得されることからユーザ属性の分布傾向に関連性を持たせることができ、将来ログ予測部２２による予測精度が高い場合には、注文要求の受け付けをさらに精度よく行うことができる。

また、受付部２３が、配信対象ユーザを選択する所定の規則は、複数の配信対象ユーザの中から所定数の配信対象ユーザをランダムに選択する規則である。

かかる構成により、異なる予測パターンをより容易に取得することが可能となる。

また、複数の将来ログ予測部２２（予測手段の一例に相当）が、将来の広告配信先となる複数の配信対象ユーザをそれぞれ異なる規則に従って予測し、受付部２３が、複数の将来ログ予測部２２によってそれぞれ予測される複数の配信対象ユーザの情報を複数種類の配信対象ユーザ群の情報として取得する。

かかる構成により、個々の将来ログ予測部２２による予測精度が低い場合であっても、注文要求の受け付けを精度よく行うことができる。

また、注文要求の配信条件には１以上のユーザ属性を指定する情報および配信回数の情報が含まれており、受付部２３が、配信対象ユーザ群に含まれる複数の配信対象ユーザのうち配信条件により指定されたユーザ属性を有する配信対象ユーザの数が配信条件で指定された配信回数以上である場合に配信条件を満たすと判定する。

かかる構成により、注文要求に指定されたユーザ属性や配信回数を考慮した配信条件充足判定を精度よく行うことができる。

また、受付部２３が、広告配信の注文要求で指定される頻度が閾値以上ある２以上のユーザ属性の組み合わせを一つのユーザ属性として配信対象ユーザの数をカウントする。

かかる構成により、注文要求で指定される頻度が閾値以上ある２以上のユーザ属性の組み合わせを一つのユーザ属性として配信対象ユーザの数をカウントすることができ、これにより、将来の広告配信の注文に対する受け付け可能性を増加させ、販売機会の損失を抑制できる。

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

上述した広告配信管理装置１は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。また、広告配信管理装置１および情報配信装置２を一つのサーバコンピュータで実現してもよい。

１ 広告配信管理装置
２ 情報配信装置
３ 広告主端末
４ ユーザ端末
５ 通信ネットワーク
１０ 通信部
１１ 広告情報ＤＢ
１２ ユーザ情報ＤＢ
１３ 過去ログＤＢ
１４ 将来ログＤＢ
２１ 広告配信部
２２ 将来ログ予測部
２３ 受付部
２４ 割当部

Claims (8)

1. 広告配信の注文要求を受信する受信手段と、
   将来の広告配信先となる複数の配信対象ユーザを含む配信対象ユーザ群の情報を複数種類取得する取得手段と、
   前記受信手段によって前記広告配信の注文要求を受信した場合に、前記複数種類の配信対象ユーザ群のそれぞれについて、前記広告配信の注文要求により指定される配信条件を満たすか否かを判定する判定手段と、
   前記複数種類の配信対象ユーザ群に対する前記判定手段の判定結果に基づき、前記広告配信の注文要求を受け付けるか否かを判定する受付手段と、を備えることを特徴とする広告配信管理装置。
2. 前記受付手段は、
   前記複数種類の配信対象ユーザ群のうち前記判定手段によって配信条件を満たす配信対象ユーザ群の割合が所定値以上の場合に前記広告配信の注文要求を受け付ける
   ことを特徴とする請求項１に記載の広告配信管理装置。
3. 将来の広告配信先となる複数の配信対象ユーザを予測する予測手段を備え、
   前記取得手段は、
   前記複数の配信対象ユーザのうち所定割合の配信対象ユーザを所定の規則に従って選択する処理を繰り返し行うことによって前記複数種類の配信対象ユーザ群の情報を取得する
   ことを特徴とする請求項１または２に記載の広告配信管理装置。
4. 前記所定の規則は、
   前記複数の配信対象ユーザの中から所定数の配信対象ユーザをランダムに選択する規則である
   ことを特徴とする請求項３に記載の広告配信管理装置。
5. 将来の広告配信先となる複数の配信対象ユーザをそれぞれ異なる規則に従って予測する複数の予測手段を備え、
   前記取得手段は、
   前記複数の予測手段によってそれぞれ予測される複数の配信対象ユーザの情報を前記複数種類の配信対象ユーザ群の情報として取得する
   ことを特徴とする請求項１または２に記載の広告配信管理装置。
6. 前記配信条件には１以上のユーザ属性を指定する情報および配信回数の情報が含まれており、
   前記判定手段は、
   前記配信対象ユーザ群に含まれる複数の配信対象ユーザのうち前記配信条件により指定されたユーザ属性を有する配信対象ユーザの数が前記配信条件で指定された配信回数以上である場合に前記配信条件を満たすと判定する
   ことを特徴とする請求項１〜５のいずれか１つに記載の広告配信管理装置。
7. 前記判定手段は、
   前記広告配信の注文要求で指定される頻度が閾値以上ある２以上のユーザ属性の組み合わせを一つのユーザ属性として前記配信対象ユーザの数をカウントする
   ことを特徴とする請求項６に記載の広告配信管理装置。
8. コンピュータが実行する広告配信管理方法であって、
   広告配信の注文要求を受信する受信ステップと、
   将来の広告配信先となる複数の配信対象ユーザを含む配信対象ユーザ群の情報を複数種類取得する取得ステップと、
   前記受信ステップによって前記広告配信の注文要求を受信した場合に、前記複数種類の配信対象ユーザ群のそれぞれについて、前記広告配信の注文要求により指定される配信条件を満たすか否かを判定する判定ステップと、
   前記複数種類の配信対象ユーザ群に対する前記判定ステップの判定結果に基づき、前記広告配信の注文要求を受け付けるか否かを判定する受付ステップと、を含むことを特徴とする広告配信管理方法。

Images