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

Description

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

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

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

そして、広告主から広告配信の注文要求に対し、この注文要求で指定されたユーザ属性や配信数の配信条件を満たす受注在庫がある場合に、受注在庫を割り当てて注文要求の受け付けを行っている（例えば、特許文献２参照）。

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

しかしながら、従来の広告配信技術では、広告情報を配信すべきユーザ端末のユーザに対して複数の広告情報が送信可能である場合、いずれの広告情報を配信するかを広告情報の配信残量などに応じて決定していた。

したがって、受注在庫に対する注文要求の割り当て内容と実際の配信内容とが大きく異なり、受け付けた注文要求に対して指定された配信数の広告情報を配信することができないなどの問題が生じるおそれがある。

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

本願に係る広告配信管理装置は、将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶する予測情報記憶手段と、広告情報、ユーザ属性および配信数を指定した注文要求を取得する取得手段と、前記注文要求で指定された前記ユーザ属性を有し、かつ、前記配信数に応じた数の配信対象ユーザを、前記複数の配信対象ユーザの中から選択して前記注文要求に割り当てる割当手段と、ユーザ端末からの広告配信要求に対し、当該ユーザ端末のユーザが有するユーザ属性に対応する前記注文要求の広告情報を前記割当手段による割り当て結果に基づいて選択して前記ユーザ端末へ送信する送信手段とを備える。

実施形態の一態様によれば、受け付けを行った注文要求に対して適切な広告配信を行うことができる広告配信管理装置および広告配信管理方法を提供することができる。

図１は、実施形態に係る広告配信管理処理の説明図である。 図２は、実施形態に係る広告配信管理装置の構成を示す図である。 図３は、将来ログテーブルの一例を示す図である。 図４は、広告情報テーブルの一例を示す図である。 図５は、ユーザ属性の延べ総数の求め方を説明するための図である。 図６は、ユーザ属性パターンの属性内容と配信対象ユーザの数との関係の一例を示す図である。 図７は、注文要求に対して割り当てられるユーザ属性パターンに属する配信対象ユーザの数の割り当て例を示す図である。 図８は、割り当て比率情報テーブルの一例を示す図である。 図９は、ユーザ情報テーブルの一例を示す図である。 図１０は、アクセスログテーブルの一例を示す図である。 図１１は、実施形態に係る広告配信管理装置の広告配信管理処理フローを示す図である。

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

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

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

広告主端末３は、広告配信を希望する広告主の端末装置であり、所定のユーザ属性を有するユーザのユーザ端末４に対して配信したい広告の注文を行う注文要求を広告配信管理装置１に対して行う。具体的には、広告主端末３は、注文主が広告配信対象ページへの掲載を望む広告情報、広告情報の配信先として指定するユーザ属性の情報、広告情報の配信数の情報、および、広告情報の配信期間の情報を含む注文要求を広告配信管理装置１へ送信する。

広告情報として、例えば、バナー広告、テキスト広告、動画広告などの２次元コンテンツや３次元コンテンツなどがある。なお、以下において、注文要求で指定されるユーザ属性を指定ユーザ属性と記載し、注文要求で指定される配信数を指定配信数と記載し、注文要求で指定される配信期間を指定配信期間と記載する場合がある。

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

なお、広告情報のＵＲＬは、広告配信管理装置１のＵＲＬではなく情報配信装置２のＵＲＬとすることもできる。この場合、ユーザ端末４は、広告情報のＵＲＬに基づいて、情報配信装置２に対して広告情報を要求する。かかる要求を受信した場合、情報配信装置２は、広告配信管理装置１に対して広告情報の送信要求を行う。広告配信管理装置１は、情報配信装置２からの送信要求に対応する広告情報を情報配信装置２へ送信する。情報配信装置２は、広告配信管理装置１から広告情報を受信すると、かかる広告情報をユーザ端末４へ送信する。

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

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

図１に示す例では、将来の広告配信先として予測される配信対象ユーザ６₁、６₂、６₃、６₄、…、６_n（以下、配信対象ユーザ６と総称する場合がある）の情報がＤＢに記憶されている。広告配信管理装置１は、広告配信の注文要求を広告主端末３から受信すると、かかる注文要求で指定された配信条件を満たす受注在庫があるか否かを判定し、配信条件を満たす受注在庫がある場合に、広告主端末３からの注文要求を受け付ける。

具体的には、広告配信管理装置１は、受注在庫の数をカウントする。すなわち、広告配信管理装置１は、広告配信の注文要求を広告主端末３から受信すると、注文要求に対して割り当てられていない配信対象ユーザ（以下、未割り当てユーザと記載する場合がある）のうち、注文要求で指定されたユーザ属性を有する未割り当てユーザの数をカウントする。そして、かかるカウント結果が注文要求で指定された配信数以上である場合、広告配信管理装置１は、広告主端末３からの注文要求を受け付ける。

例えば、広告主端末３からの注文要求として、注文要求Ｏ１〜Ｏ３がある場合を考える。注文要求Ｏ１〜Ｏ３は、指定ユーザ属性がそれぞれ「属性Ａ」、「属性Ａ＋Ｂ」、「属性Ｃ」であり、また、指定配信数がそれぞれ「４００」、「３００」、「１５０」であるとする。

広告配信管理装置１は、注文要求Ｏ１に対し、「属性Ａ」を有する配信対象ユーザの数が「４００」以上ある場合に、注文要求Ｏ１を受け付ける。また、広告配信管理装置１は、注文要求Ｏ２に対し、「属性Ａ＋Ｂ」を有する配信対象ユーザの数が「３００」以上ある場合に、注文要求Ｏ２を受け付ける。広告配信管理装置１は、新たな広告配信の注文要求に対し、例えば、未割り当ての配信対象ユーザの数が最大化するように配信対象ユーザを割り当てる。

図１に示す例では、配信対象ユーザ６₁はユーザ属性Ａ、Ｃ、Ｄを有し、かつ、注文要求Ｏ１に割り当てられ、配信対象ユーザ６₂はユーザ属性Ａ、Ｂを有し、かつ、注文要求Ｏ２に割り当てられ、配信対象ユーザ６₃はユーザ属性Ｃを有し、かつ、注文要求Ｏ３に割り当てられている。一方、配信対象ユーザ６₄、６_nは、注文要求Ｏ１〜Ｏ３に割り当てられていない未割り当てユーザである。

広告配信管理装置１は、広告主端末３からの注文要求に対して配信対象ユーザを割り当てた後、指定配信期間になるまでに、ユーザ属性のパターン（以下、属性パターンと記載する）単位で注文要求毎の割り当て済みユーザの比率を算出する。広告配信管理装置１は属性パターンを複数有しており、配信対象ユーザはいずれか一つの属性パターンに割り当てられる。

図１に示す例では、例えば、属性パターンＰ１に割り当てられた配信対象ユーザの数が、注文要求Ｏ１に対して「１００」であり、注文要求Ｏ３に対して「５０」である。広告配信管理装置１は、属性パターンＰ１を有するユーザに対し、注文要求Ｏ１の広告情報を配信する割合を「６７％（＝１００／１５０）」とし、注文要求Ｏ３の広告情報を配信する割合を「３３％（＝５０／１５０）」とする。

また、広告配信管理装置１は、属性パターンＰ２を有するユーザに対し、注文要求Ｏ１の広告情報を配信する割合を「５０％（＝３００／６００）」とし、注文要求Ｏ２の広告情報を配信する割合を「５０％（＝３００／６００）」とする。また、広告配信管理装置１は、属性パターンＰ３を有するユーザに対し、注文要求Ｏ３の広告情報を配信する割合を「１００％（＝１００／１００）」とする。

このように、広告配信管理装置１は、広告情報を配信する場合に、配信対象ユーザの割り当て結果に応じた広告情報の配信を行う。これにより、予測した将来ログと同様のユーザ属性を有するユーザがアクセスすれば、受注在庫の管理に沿った広告情報の配信を行うことができ、受け付けを行った注文要求に対して適切な広告配信を行うことができる。

しかも、広告情報の配信比率の算出は、上述のように、属性パターン単位で注文要求毎の割り当て済みユーザの比率を事前に算出することにより、広告配信のリアルタイム性を損なわずに、広告情報の配信を行うことができる。

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

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

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

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

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

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

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

「割り当て状態」は、注文要求に対して割り当てられた配信対象ユーザであるか否かを示す情報である。注文要求に対して割り当てられた配信対象ユーザである場合には「１」が記憶され、注文要求に対して割り当てられていない配信対象ユーザである場合には「０」が記憶される。

「割り当て対象」は、配信対象ユーザが割り当てられた注文要求の広告ＩＤである。例えば、配信対象ＩＤが「Ｆ５」の配信対象ユーザは、注文要求Ｏ３が割り当てられている。なお、注文要求が割り当てられていない場合には、「０」が設定される。

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

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

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

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

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

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

（受付部２２について）
受付部２２は、将来ログテーブルに設定された将来ログに基づいて、広告主端末３からの注文要求を受け付けるか否かを判定し、注文要求を受け付ける場合に、広告主端末３に対して注文受付応答を行う。

広告主端末３からの注文要求には、上述のように、指定ユーザ属性、指定配信数および指定配信期間などの指定情報が含まれている。受付部２２は、広告主端末３から注文要求があった場合、将来ログテーブルに設定された複数の配信対象ユーザのうち注文要求の指定ユーザ属性を有する未割り当てユーザの数をカウントする。なお、以下においては、説明を分かり易くするために、将来の広告配信先を予測する対象期間と注文要求の指定配信期間とを同一のものとして説明する。

受付部２２は、かかるカウント結果が注文要求の指定配信数以上である場合に、広告主端末３からの注文要求を受け付ける。例えば、受付部２２は、指定ユーザ属性が「車」であり、指定配信数が「１００」である注文要求を受信した場合、将来ログテーブルにおいて「車」の属性区分に「１」が設定されている配信対象ユーザの数をカウントする。そして、受付部２２は、カウント結果が「１００」以上である場合に、広告主端末３からの注文要求を受け付け、「１００」未満である場合に、広告主端末３からの注文要求を受け付けない。

受付部２２は、広告主端末３からの注文要求を受け付けた場合、広告情報ＤＢ１１の広告情報テーブルに受け付けた注文要求の情報を設定する。

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

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

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

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

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

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

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

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

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

（割当部２３）
割当部２３は、受付部２２で受け付けた注文要求に対し、将来ログテーブルに設定された配信対象ユーザを割り当てる。割当部２３は、複数の注文要求に対する配信対象ユーザの割り当てを、複数の注文要求のそれぞれの指定ユーザ属性および指定配信数に基づき、未割り当てスコアが最大化するように行う。未割り当てスコアは、所定のユーザ属性を有する注文要求に未割り当ての配信対象ユーザの数である。

ここで、「所定のユーザ属性」は、上述した適切度判定用属性であり、例えば、広告配信管理装置１の管理者（以下、配信管理者と記載する）が広告配信管理装置１の操作部（図示せず）から設定することができる。配信管理者は、適切度判定用属性として、全てのユーザ属性を設定することもでき、また、一部のユーザ属性を設定することもできる。

また、割当部２３は、新たな注文要求が受付部２２によって受け付けられる毎に、広告情報テーブルに設定された全ての注文要求に対して配信対象ユーザを割り当てる処理（以下、全体処理と記載する場合がある）を繰り返し行う。

広告情報テーブルにｎ個の注文要求がある場合、注文要求Ｏｉ（１≦ｉ≦ｎ；ｉは整数）を定義し、注文要求Ｏｉの指定配信数を「ｏ_ｉ」とする。また、ｍ個の属性パターンが設定される場合、属性パターンＰｊ（１≦ｊ≦ｍ；ｊは整数）を定義し、属性パターンＰｊに属する配信対象ユーザの数を「ｐ_ｊ」とする。

「属性パターン」は、例えば将来ログテーブルが図３に示す状態である場合、「車」、「化粧品」、「服」、「旅行」などの属性区分の組み合わせである。例えば、属性パターンを｛車、化粧、服、旅行、・・・｝で定義した場合、各属性パターンは、例えば、｛１、０、０、０、・・・｝、｛０、１、０、０、・・・｝、｛１、１、１、０、・・・｝などで表される。属性パターンの数は、属性区分の数が例えば６個の場合、２⁶個である。なお、注文要求Ｏｉで指定される可能性がないものは属性パターンから除外することもできる。

割当部２３は、下記式（１）、（２）を制約条件として、未割り当てスコアＫＰＩを最大化するように、線形計画法を用いて、複数の注文要求Ｏ１〜Ｏｎに対してそれぞれ配信対象ユーザを割り当てる。なお、下記式（２）において、「ａ_ｉ_ｊ」は、注文要求Ｏｉに対して割り当てられる属性パターンＰｊを有する配信対象ユーザの数であり、「ｃ_ｊ」は、属性パターンＰｊを有する配信対象ユーザの数である。

未割り当てスコアＫＰＩは、注文要求Ｏ１〜Ｏｎに対して未割り当ての配信対象ユーザの数に基づくスコアであり、適切度判定用属性を有する注文要求Ｏ１〜Ｏｎに対して未割り当ての配信対象ユーザの延べ総数である。未割り当てユーザの数が「ｐ」である場合、未割り当てユーザＦｋ（１≦ｋ≦ｐ；ｐは整数）を定義し、未割り当てユーザＦｋが有する適切度判定用属性の数を「ｆ_ｋ」とすると、未割り当てスコアＫＰＩは、下記式（３）により求められる。

適切度判定用属性として全てのユーザ属性が設定されている場合、将来ログテーブルにおいて「割り当て状態」が「０」に設定された配信対象ユーザの「ユーザ属性の数」の合計である「ユーザ属性の延べ総数」が未割り当てスコアＫＰＩである。

例えば、図３に示す将来ログテーブルにおいて、配信対象ＩＤ「Ｆ１」、「Ｆ３」、「Ｆ４」、「Ｆ６」の配信対象ユーザが注文要求Ｏ１〜Ｏｎに割り当てられておらず、その他の配信対象ユーザは注文要求Ｏ１〜Ｏｎに割り当てられているとする。

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

なお、割当部２３は、未割り当てユーザＦｋの「ユーザ属性の延べ総数」を未割り当てスコアＫＰＩとして求めたが、未割り当てユーザＦｋの「属性パターンの延べ総数」を未割り当てスコアＫＰＩとして求めることもできる。

例えば、割当部２３は、属性パターンＰｊ毎に、属性パターンＰｊを有する未割り当てユーザＦｋの数「ｅ_ｊ」を求め、かかる数の合計を未割り当てスコアＫＰＩとすることができる。例えば、割当部２３は、下記式（４）を用いて、未割り当てスコアＫＰＩを求めることができる。

このように、割当部２３は、複数の注文要求Ｏ１〜Ｏｎに対する配信対象ユーザの割り当てを、複数の注文要求Ｏ１〜Ｏｎのそれぞれで指定されるユーザ属性および配信数に基づき、所定のユーザ属性を有する注文要求に未割り当ての配信対象ユーザの数が最大化するように行う。

これにより、注文要求Ｏ１〜Ｏｎに対する配信対象ユーザの割り当ての選択肢を増加させることができ、将来の注文要求Ｏ１〜Ｏｎに対する受け付け可能性が増加することから、販売機会の損失を抑制することができる。

ここで、割当部２３が、上記式（１）、（２）を制約条件とし、未割り当てスコアＫＰＩを最大化するように、線形計画法を用いて割り当て処理を行う一例について説明する。図６は、属性パターンＰｊの属性内容と配信対象ユーザのユーザ数ｃ_ｊとの関係の一例を示す図である。

図６に示すように、属性パターンＰ１〜Ｐ６がそれぞれ、「車」、「化粧品」、「服」、「旅行」、「車＆旅行」、「化粧品＆服」であるとする。また、配信対象ユーザの数がそれぞれ図６に示すように設定されているとする。図６に示すように、属性パターンを有する配信対象ユーザの数であるｃ_１〜ｃ_６が、「９０２０」、「５３０２」、「２３１９」、「４２８７」、「４０３０」、「２９００」であるとする。

属性パターンＰｊを｛車、化粧、服、旅行、・・・｝で定義した場合、属性パターンＰ１〜Ｐ６は、それぞれ｛１、０、０、０｝、｛０、１、０、０｝、｛０、０、１、０｝、｛０、０、０、１｝、｛１、０、０、１｝、｛０、１、１、０｝である。したがって、例えば、図６に示すユーザＩＤ「Ｆ８」の配信対象ユーザは、｛１、０、０、０｝である属性パターンＰ１に設定され、図６に示すユーザＩＤ「Ｆ３」の配信対象ユーザは、｛１、０、０、１｝である属性パターンＰ５に設定される。

割当部２３は、上記式（１）、（２）を制約条件として、未割り当てスコアＫＰＩを最大化するように、線形計画法を用いて、注文要求に対する配信対象ユーザの割り当てである「ａ_ｉ_ｊ」を設定する。属性パターンＰｊの属性内容とユーザ数ｃ_ｊとの関係が図５に示す状態であり、広告情報テーブルが図４に示す状態であるとすると、「ａ_ｉ_ｊ」の設定は例えば図７に示す状態になる。図７は、「ａ_ｉ_ｊ」の割り当て例を示す図である。

なお、上記式（１）は、各注文要求Ｏｉに割り当てられる配信対象ユーザの総数が注文要求の指定配信数と一致することを制約条件とする。例えば、図７に示す注文要求Ｏ１では、指定配信数ｏ_１が「１００」であり、ａ_１_１〜ａ_１_６の合計が「１００」になるように、ａ_１_１〜ａ_１_６が設定される。

また、上記式（２）は、各属性パターンＰｊにおいて、注文要求Ｏｉに割り当てられた配信対象ユーザの数が属性パターンＰｊを有する配信対象ユーザの数であるユーザ数ｃ_ｊを超過しないことを制約条件とする。例えば、属性パターンＰ１では、図６に示すように、ユーザ数ｃ_ｊが「９０２０」であり、ａ_１_１〜ａ_ｎ_１の合計が「９０２０」以下になる範囲で、ａ_１_１〜ａ_ｎ_１が設定される。

割当部２３は、新たな注文要求が受付部２２によって受け付けられる毎に、広告情報テーブルに設定された全ての注文要求に対する配信対象ユーザの割り当てを行う全体処理を繰り返す。かかる全体処理では、将来ログテーブルに設定された全ての配信対象ユーザが対象となる。

例えば、注文要求Ｏ１〜Ｏ１０に対して配信対象ユーザを割り当てた後、新たな注文要求Ｏ１１が受付部２２で受け付けられたとする。この場合、割当部２３は、注文要求Ｏ１〜Ｏ１１に対し、上記式（１）、（２）を制約条件として、将来ログテーブルに設定された複数の配信対象ユーザから未割り当てスコアＫＰＩを最大化するように配信対象ユーザを割り当てる。

このように、割当部２３は、広告情報テーブルに設定された全ての注文要求に対する配信対象ユーザの割り当てを行う全体処理を繰り返すことから、注文要求全体に対する配信対象ユーザの割り当てを適切に行うことができる。

なお、割当部２３は、配信対象ユーザを割り当てた注文要求への割り当てを維持した状態で、新たに取得した注文要求に対して配信対象ユーザを割り当てる処理（以下、部分処理と記載する場合がある）を行うこともできる。

例えば、注文要求Ｏ１〜Ｏ１０に対して配信対象ユーザを割り当てた後、新たな注文要求Ｏ１１が受付部２２で受け付けられたとする。この場合、割当部２３は、注文要求Ｏ１〜Ｏ１０に対する配信対象ユーザの割り当てを維持した状態で、注文要求Ｏ１１に対する配信対象ユーザの割り当て部分処理を行う。すなわち、割当部２３は、ａ_１_ｊ〜ａ_１０_ｊに対する配信対象ユーザの割り当てを変更することなく、ａ_１１_ｊに対する配信対象ユーザの割り当てを行う。

また、割当部２３は、新たな注文要求に対して部分処理を行いつつ、所定のタイミング（例えば、注文要求が少ない夜間）で全体処理を行うこともできる。

上述の実施形態では、線形計画法を用いて、適切度判定用属性を有する注文要求に未割り当ての配信対象ユーザの数が最大化するように複数の注文要求に対する配信対象ユーザの割り当てを行ったが、線形計画法以外の方法を用いることもできる。

（配信比率算出部２４について）
配信比率算出部２４は、属性パターンＰｊの注文要求Ｏｉに対する配信対象ユーザの割り当て数である「ａ_ｉ_ｊ」の情報を受付部２２から取得し、属性パターンＰｊ毎に各注文要求Ｏｉに対する配信対象ユーザの割り当て比率Ｖ_ｉ_ｊを算出する。

具体的には、配信比率算出部２４は、下記式（５）に基づき、属性パターンＰｊ毎に注文要求Ｏｉに対する配信対象ユーザの割り当て比率Ｖ_ｉ_ｊを算出し、算出した割り当て比率Ｖ_ｉ_ｊを広告情報ＤＢ１１の割り当て比率情報テーブルに設定する。図８は、割り当て比率情報テーブルの一例を示す図である。

例えば、図７に示す例では、属性パターンＰ５の注文要求Ｏ１に対する配信対象ユーザの数である「ａ_１_５」は「２３」であり、属性パターンＰ５の総数は、「４０３０」である。したがって、配信比率算出部２４は、属性パターンＰ５の注文要求Ｏ１に対する配信対象ユーザの割り当て比率Ｖ_１_５として、「０．００５７（＝２３／４０３０）」を算出し、図８に示すように割り当て比率情報テーブルに設定する。

また、属性パターンＰ５の注文要求Ｏ２に対する配信対象ユーザの数である「ａ_２_５」は「２００」であり、属性パターンＰ５の総数は、「４０３０」である。したがって、配信比率算出部２４は、属性パターンＰ５の注文要求Ｏ２に対する配信対象ユーザの割り当て比率Ｖ_２_５として、「０．０４９６（＝２００／４０３０）」を算出し、図８に示すように割り当て比率情報テーブルに設定する。

このように、配信比率算出部２４は、属性パターンＰｊの注文要求Ｏｉに対する配信対象ユーザの割り当て数である「ａ_ｉ_ｊ」の情報を受付部２２から取得することから、割り当て比率Ｖ_ｉ_ｊの算出処理を容易かつ高速に行うことができる。

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

広告配信部２５は、端末ユーザのユーザ属性の属性パターンＰｊに対応する割り当て比率Ｖ_１_ｊ〜Ｖ_ｎ_ｊを広告情報ＤＢ１１の割り当て比率情報テーブルから取得する。そして、割り当て比率Ｖ_１_ｊ〜Ｖ_ｎ_ｊに応じた確率で、注文要求Ｏ１〜Ｏｎの中から一つの注文要求を選択し、選択した注文要求で指定される広告要求の広告情報を広告情報テーブルから取得する。

例えば、広告情報の配信要求を行った端末ユーザがユーザ属性「車」を有する場合、広告配信部２５は、０．５７％の確率で広告情報テーブルから注文要求Ｏ１の広告情報「バナー広告Ｙａ」を取得し、配信要求元のユーザ端末４へ送信する。また、広告配信部２５は、４．９６％の確率で広告情報テーブルから注文要求Ｏ２の広告情報「動画広告Ｙｂ」を取得し、配信要求元のユーザ端末４へ送信する。

このように、広告配信部２５は、ユーザ端末４からの広告配信要求に対し、端末ユーザのユーザ属性に対応する注文要求Ｏｉの広告情報を割当部２３による割り当て結果に基づいて選択してユーザ端末４へ送信する。これにより、予測した将来ログである配信対象ユーザと同様のユーザ属性を有するユーザがアクセスすれば、受注在庫の管理に沿った広告情報の配信を行うことができ、受け付けを行った注文要求に対して適切な広告配信を行うことができる。

しかも、属性パターン単位で注文要求毎の割り当て済みユーザの比率を事前に算出することにより、広告配信のリアルタイム性を損なわずに、広告情報の配信を行うことができる。

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

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

「サイコグラフィック属性」および「デモグラフィック属性」は、将来ログＤＢ１４の将来ログテーブルと同様の項目である。

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

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

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

〔３．広告配信管理装置１の処理フロー〕
次に、実施形態に係る広告配信管理装置１による広告配信管理処理の手順について説明する。図１１は、実施形態に係る広告配信管理装置１の広告配信管理処理フローの一例を示す図である。かかる広告配信管理処理フローは広告配信管理装置１の制御部１５によって繰り返し実行される処理であり、制御部１５の受付部２２、割当部２３、配信比率算出部２４および広告配信部２５の処理を中心に説明する。

図１１に示すように、広告配信管理装置１の制御部１５は、広告配信管理処理を開始すると、広告主端末３からの注文要求を受信したか否かを判定する（ステップＳ１１）。制御部１５は、広告主端末３からの注文要求を受信したと判定すると（ステップＳ１１；Ｙｅｓ）、将来ログテーブルに設定された将来ログに基づいて、広告主端末３からの注文要求を受け付けるか否かを判定する（ステップＳ１２）。制御部１５は、例えば、将来ログテーブルに設定された未割り当てユーザのユーザ属性のうち注文要求で指定されたユーザ属性の数をカウントし、かかるカウント結果が注文要求の指定配信数以上である場合に注文要求を受け付けると判定する。

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

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

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

次に、制御部１５は、割り当て比率情報テーブルの更新を行う（ステップＳ１６）。かかる処理において、制御部１５は、属性パターンＰｊの注文要求Ｏｉに対する配信対象ユーザの割り当て数である「ａ_ｉ_ｊ」に基づき、属性パターンＰｊ毎に注文要求Ｏｉに対する配信対象ユーザの割り当て比率Ｖ_ｉ_ｊを算出する。そして、制御部１５は、算出した割り当て比率Ｖ_ｉ_ｊを広告情報ＤＢ１１の割り当て比率情報テーブルに設定する。

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

また、ステップＳ１１において、広告主端末３からの注文要求を受信していないと判定すると（ステップＳ１１；Ｎｏ）、制御部１５は、ユーザ端末４から通信部１０を介して広告情報の配信要求を受信したか否かを判定する（ステップＳ１９）。広告情報の配信要求を受信したと判定すると（ステップＳ１９；Ｙｅｓ）、制御部１５は、割り当て比率Ｖ_ｉ_ｊに基づいて選択した広告情報を送信する（ステップＳ２０）。

ステップＳ２０において、制御部１５は、割り当て比率情報テーブルから端末ユーザのユーザ属性の属性パターンＰｊに対応する割り当て比率Ｖ_１_ｊ〜Ｖ_ｎ_ｊの情報を割り当て比率情報テーブルから取得する。制御部１５は、割り当て比率Ｖ_１_ｊ〜Ｖ_ｎ_ｊに応じた確率に基づき、注文要求Ｏ１〜Ｏｎの中から一つの注文要求を選択し、選択した注文要求で指定される広告要求の広告情報を広告情報テーブルから取得する。

次に、制御部１５は、広告情報の配信要求を行ったユーザのユーザＩＤを過去ログＤＢ１３のアクセスログテーブルに設定することによりアクセスログテーブルを更新する（ステップＳ２１）。

制御部１５は、ステップＳ２１の処理が終了した場合、または、ステップＳ１９において広告情報の配信要求を受信していないと判定した場合（ステップＳ１９；Ｎｏ）、広告配信管理処理を終了する。

〔４．変形例〕
上述の実施形態では、属性パターンＰｊを排他的な属性パターンとし、配信対象ユーザはいずれか一つの属性パターンＰｊに割り当てられることにしたが、属性区分の数が多くなると、排他的な属性パターンを用意することが困難なおそれがある。このような場合には、例えば、属性パターンを注文要求で指定される頻度が高い２以上のユーザ属性の組み合わせとし、属性パターンの数を抑えてもよい。

属性パターンの数を抑えた場合、一部の属性パターンが排他的な属性パターンとならず、ユーザ端末４のユーザが複数の属性パターンＰｊのユーザ属性を有することになる場合がある。そこで、このような場合には、広告配信部２５において、割り当て比率Ｖ_i_ｊに重み付けを行うようにしてもよい。

例えば、広告配信部２５は、割り当て比率情報テーブルから端末ユーザのユーザ属性に対応する複数の属性パターンＰｊに設定された割り当て比率Ｖ_ｉ_ｊを取得する。そして、広告配信部２５は、端末ユーザのユーザ属性に対応する属性パターンＰｊの数で割り当て比率Ｖ_ｉ_ｊを除算し、かかる除算結果に応じた確率で注文要求の中から一つの注文要求を選択する。

広告配信部２５は、例えば、広告情報の配信先である端末ユーザのユーザ属性に対応する属性パターンが属性パターンＰ１〜Ｐ３の３つである場合、割り当て比率Ｖ_１_ｊ、Ｖ_２_ｊ、Ｖ_３_ｊを３で除算する。そして、広告配信部２５は、除算結果であるＶ_１_ｊ／３、Ｖ_２_ｊ／３、Ｖ_３_ｊ／３に応じた確率で注文要求の中から一つの注文要求を選択する。

また、広告配信部２５は、除算時に重み付けを行うこともできる。例えば、広告情報の配信先である端末ユーザのユーザ属性に対応する属性パターンが属性パターンＰ１〜Ｐ３の３つである場合、割り当て比率Ｖ_１_ｊ、Ｖ_２_ｊ、Ｖ_３_ｊをそれぞれΣａ_ｉ_１／（Σａ_ｉ_１＋Σａ_ｉ_２＋Σａ_ｉ_３）、Σａ_ｉ_２／（Σａ_ｉ_１＋Σａ_ｉ_２＋Σａ_ｉ_３）、Σａ_ｉ_３／（Σａ_ｉ_１＋Σａ_ｉ_２＋Σａ_ｉ_３）で除算する。かかる除算結果に応じた確率で、広告配信部２５は、注文要求の中から一つの注文要求を選択することができる。

例えば、図７に示す例では、Σａ_ｉ_１＝９２７、Σａ_ｉ_２＝３５４、Σａ_ｉ_３＝２１８、Σａ_ｉ_１＋Σａ_ｉ_２＋Σａ_ｉ_３＝１４９９である。この場合、広告配信部２５は、例えば、割り当て比率Ｖ_１_１（＝０．０８３０）であれば、Ｖ_１_１×９２７／１４９９＝０．０５１３であり、したがって、注文要求Ｏ１に対応する広告情報を「０．０５１３」に応じた確率（５．１３％）で選択する。

このように重み付けすることによって、ユーザ端末４のユーザが複数の属性パターンＰｊのユーザ属性を有する場合であっても、割当部２３による割り当て結果に対して精度よく受注在庫の管理に沿った広告情報の配信を行うことができる。

上述の実施形態では、割当部２３は、上記式（１）、（２）を制約条件として、未割り当てスコアＫＰＩを最大化するように、線形計画法を用いて、複数の注文要求Ｏ１〜Ｏｎに対してそれぞれ配信対象ユーザを割り当てるものであるが、異なる割当方法を適用することができる。

例えば、割当部２３は、注文要求に対する配信対象ユーザである未割り当てユーザのユーザ属性別の比率（または数）に基づき、未割り当てユーザの比率（または数）が最も少ないユーザ属性の未割り当てユーザの比率をスコアとし、かかるスコアの減少が最小となるように注文要求に対する配信対象ユーザの割り当てを行うこともできる。

また、割当部２３は、未割り当てユーザの比率（または数）が最も少ないユーザ属性の未割り当てユーザの比率（または数）をスコアとし、かかるスコアの減少が最小となるように注文要求に対する配信対象ユーザの割り当てを行うこともできる。

また、割当部２３は、ユーザ属性別の予測比率に対する未割り当てユーザの比率の比をユーザ属性毎に算出し、これらの算出結果の合計値をスコアとし、かかるスコアの減少が最小となるように注文要求に対する配信対象ユーザの割り当てを行うこともできる。

また、上述の実施形態では、配信比率算出部２４は、属性パターンＰｊの注文要求Ｏｉに対する配信対象ユーザの割り当て数である「ａ_ｉ_ｊ」に基づいて、割り当て比率Ｖ_ｉ_ｊを算出したが、他の算出処理を行うこともできる。例えば、配信比率算出部２４は、将来ログテーブルに設定された配信対象ユーザのうち注文要求に受け付けられた割り当て済みユーザのユーザ属性を統計処理することによって割り当て比率Ｖ_ｉ_ｊを算出することもできる。

また、配信比率算出部２４は、将来ログテーブルを参照し、広告情報の配信先である端末ユーザのユーザ属性と同一または近似する割り当て済みユーザに割り当てられた注文要求の広告情報を選択することもできる。

また、上述の実施形態では、説明を分かり易くするために、将来の広告配信先を予測する対象期間と注文要求の配信期間とを同一のものとして説明した。しかしながら、将来の広告配信先を予測する対象期間と注文要求の配信期間とは同一でなくてもよく、例えば、将来の広告配信先を予測する対象期間を１日単位とし、注文要求の配信期間を１日単位で設定してもよい。この場合、割当部２３は、例えば、１日単位の配信対象ユーザで割り当て処理を行うことができ、また、配信比率算出部２４は、１日単位の割り当て比率Ｖ_ｉ_ｊを算出する処理を行うことができる。

〔５．効果〕
実施形態にかかる広告配信管理装置１において、将来ログＤＢ１４（予測情報記憶手段の一例に相当）が、将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶し、受付部２２（取得手段の一例に相当）が、ユーザ属性および配信数を指定した注文要求を取得し、割当部２３（割当手段の一例に相当）が、注文要求で指定されたユーザ属性を有し、かつ、配信数に応じた数の配信対象ユーザを、複数の配信対象ユーザの中から選択して注文要求に割り当て、広告配信部２５（広告配信手段の一例に相当）が、ユーザ端末４からの広告配信要求に対し、ユーザ端末４のユーザが有するユーザ属性に対応する注文要求の広告情報を割当部２３による割り当て結果に基づいて選択してユーザ端末４へ送信する。

かかる構成により、予測した将来ログである配信対象ユーザと同様のユーザ属性を有するユーザがアクセスすれば、受注在庫の管理に沿った広告情報の配信を行うことができ、受け付けを行った注文要求に対して適切な広告配信を行うことができる。また、広告配信のリアルタイム性を損なわずに、広告情報の配信を行うことができる。

また、配信比率算出部２４（算出手段の一例に相当）が、１以上のユーザ属性を含む属性パターン毎に、各注文要求に対する割当部２３による配信対象ユーザの割り当て比率を算出し、広告配信部２５は、ユーザ端末４のユーザが有するユーザ属性の属性パターンＰｊに対応する注文要求の広告情報を、割り当て比率に応じた確率で選択してユーザ端末４へ送信する。

かかる構成により、割当部２３による属性パターンＰｊ毎の割り当て比率に応じた確率で注文要求の広告情報を選択することができ、割当部２３による割り当て結果に対して精度よく受注在庫の管理に沿った広告情報の配信を行うことができる。

また、割当部２３が、所定のユーザ属性を有する配信対象ユーザのうち注文要求に未割り当ての配信対象ユーザの数が最大化するように、属性パターンＰｊ毎に各注文要求に対して配信対象ユーザを割り当て、配信比率算出部２４が、割当部２３により属性パターンＰｊ毎に各注文要求に対して割り当てられた配信対象ユーザの数である「ａ_ｉ_ｊ」に基づき、割り当て比率Ｖ_ｉ_ｊを算出する。

かかる構成により、割当部２３で求めた「ａ_ｉ_ｊ」に基づき、割り当て比率Ｖ_ｉ_ｊを算出することができることから、割り当て比率Ｖ_ｉ_ｊの演算処理を高速に行うことができる。また、広告配信の注文に対する配信対象ユーザの割り当てを適切に行うことができ、将来の広告配信の注文要求に対する受け付け可能性の減少を抑制できることから、販売機会の損失を抑制することができる。

また、割当部２３が、注文要求に未割り当ての配信対象ユーザが有する所定のユーザ属性の数が最大化するように注文要求に対して配信対象ユーザを割り当てる。

かかる構成により、広告配信の注文に対する配信対象ユーザの割り当てを適切に行うことができ、将来の広告配信の注文要求に対する受け付け可能性の減少を抑制できることから、販売機会の損失を抑制することができる。

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

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

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

Claims (5)

1. 将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶する予測情報記憶手段と、
   広告情報、ユーザ属性および配信数を指定した注文要求を取得する取得手段と、
   前記注文要求で指定された前記ユーザ属性を有し、かつ、前記配信数に応じた数の配信対象ユーザを、前記複数の配信対象ユーザの中から選択して前記注文要求に割り当てる割当手段と、
   １以上のユーザ属性を含む属性パターン毎に、各前記注文要求に対する前記割当手段による配信対象ユーザの割り当て比率を算出し、算出した割り当て比率を割り当て比率情報テーブルに設定する算出手段と、
   ユーザ端末からの広告配信要求に対し、当該ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する割り当て比率を前記割り当て比率情報テーブルから取得し、当該割り当て比率に応じた確率で、前記ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する前記注文要求の広告情報を選択して前記ユーザ端末へ送信する広告配信手段と、
   を備えることを特徴とする広告配信管理装置。
2. 将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶する予測情報記憶手段と、
   広告情報、ユーザ属性および配信数を指定した注文要求を取得する取得手段と、
   前記注文要求で指定された前記ユーザ属性を有し、かつ、前記配信数に応じた数の配信対象ユーザを、前記複数の配信対象ユーザの中から選択して前記注文要求に割り当てる割当手段と、
   １以上のユーザ属性を含む属性パターン毎に、各前記注文要求に対する前記割当手段による配信対象ユーザの割り当て比率を算出する算出手段と、
   ユーザ端末からの広告配信要求に対し、当該ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する前記注文要求の広告情報を、前記割り当て比率に応じた確率で選択して前記ユーザ端末へ送信する広告配信手段と、
   を備え、
   前記広告配信手段は、
   前記広告配信要求を行った前記ユーザ端末のユーザが有するユーザ属性に対応する前記属性パターンが複数である場合、当該属性パターンの数、または、当該複数のユーザ属性のそれぞれに割り当てられた配信対象ユーザの数およびその合計に基づき、前記割り当て比率に重み付けを行い、当該重み付け後の比率に応じた確率で、前記ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する前記注文要求の広告情報を選択する
   ことを特徴とする広告配信管理装置。
3. 前記割当手段は、
   前記注文要求に未割り当ての配信対象ユーザが有する所定のユーザ属性の数が最大化するように前記注文要求に対して前記配信対象ユーザを割り当てる
   ことを特徴とする請求項１または２に記載の広告配信管理装置。
4. コンピュータが実行する広告配信管理方法であって、
   将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を取得するステップと、
   広告情報、ユーザ属性および配信数を指定した注文要求を取得する取得ステップと、
   前記注文要求で指定された配信数に応じて、前記注文要求で指定された該ユーザ属性を有する配信対象ユーザを複数の配信対象ユーザの中から選択して前記注文要求に割り当てる割当ステップと、
   １以上のユーザ属性を含む属性パターン毎に、各前記注文要求に対する前記割当ステップによる配信対象ユーザの割り当て比率を算出し、算出した割り当て比率を割り当て比率情報テーブルに設定する算出ステップと、
   ユーザ端末からの広告配信要求に対し、当該ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する割り当て比率を前記割り当て比率情報テーブルから取得し、当該割り当て比率に応じた確率で、前記ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する前記注文要求の広告情報を選択して前記ユーザ端末へ送信する広告配信ステップと、
   を含むことを特徴とする広告配信管理方法。
5. コンピュータが実行する広告配信管理方法であって、
   将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を取得するステップと、
   広告情報、ユーザ属性および配信数を指定した注文要求を取得する取得ステップと、
   前記注文要求で指定された配信数に応じて、前記注文要求で指定された該ユーザ属性を有する配信対象ユーザを複数の配信対象ユーザの中から選択して前記注文要求に割り当てる割当ステップと、
   １以上のユーザ属性を含む属性パターン毎に、各前記注文要求に対する前記割当ステップによる配信対象ユーザの割り当て比率を算出する算出ステップと、
   ユーザ端末からの広告配信要求に対し、当該ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する前記注文要求の広告情報を、前記割り当て比率に応じた確率で選択して前記ユーザ端末へ送信する広告配信ステップと、
   を含み、
   前記広告配信ステップは、
   前記広告配信要求を行った前記ユーザ端末のユーザが有するユーザ属性に対応する前記属性パターンが複数である場合、当該属性パターンの数、または、当該複数のユーザ属性のそれぞれに割り当てられた配信対象ユーザの数およびその合計に基づき、前記割り当て比率に重み付けを行い、当該重み付け後の比率に応じた確率で、前記ユーザ端末のユーザが有するユーザ属性の属性パターンに対応する前記注文要求の広告情報を選択する
   ことを特徴とする広告配信管理方法。

Images