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

Description

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

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

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

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

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

しかし、将来の広告配信先となる配信対象ユーザが複数のユーザ属性を有する場合、広告配信の注文に対する配信対象ユーザの割り当て方によっては、広告主からの新たな注文に対する受け付けが難しくなる場合がある。

本願は、上記に鑑みてなされたものであって、広告配信の注文に対する配信対象ユーザの割り当てを適切に行うことができる広告配信管理装置および広告配信管理方法を提供することを目的とする。

本願に係る広告配信管理装置は、将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶する予測情報記憶手段と、ユーザ属性を指定した複数の注文要求を取得する取得手段と、前記取得手段により新たな注文要求が取得される毎に、当該新たな注文要求と前記取得手段により過去に取得された注文要求とを含む前記複数の注文要求に対して前記配信対象ユーザを割り当てる処理を行う割当手段とを備えることを特徴とする。

実施形態の一態様によれば、広告配信の注文に対する配信対象ユーザの割り当てを適切に行うことができる広告配信管理装置および広告配信管理方法を提供することができる。

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

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

〔１．広告配信管理処理〕
まず、実施形態に係る広告配信管理処理について説明する。図１Ａおよび図１Ｂは、実施形態に係る広告配信管理処理の説明図であり、かかる広告配信管理処理によって広告主からの注文要求に対する配信対象ユーザの割り当てが適切に行われる。

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

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

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

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

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

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

図１Ａに示す例では、将来ログとして、配信対象ユーザ６ａ〜６ｅのユーザ属性を含む情報がＤＢに記憶されている。配信対象ユーザ６ａはユーザ属性Ａ、Ｂ、Ｃを有し、配信対象ユーザ６ｂはユーザ属性Ａを有し、配信対象ユーザ６ｃはユーザ属性Ａ、Ｃ〜Ｅを有し、配信対象ユーザ６ｄはユーザ属性Ｂ、Ｄ、Ｅを有し、配信対象ユーザ６ｅはユーザ属性Ｂ〜Ｄを有する。

広告配信管理装置１は、広告主端末３から送信される注文要求を取得し、かかる注文要求に対して配信対象ユーザを割り当てる。広告主端末３から送信される注文要求には、上述のように、広告情報の配信先として指定されるユーザ属性（以下、指定ユーザ属性と記載する）の情報と、広告情報の配信数（以下、指定配信数と記載する）の情報とが含まれている。

広告配信管理装置１は、複数の注文要求を一つの単位として、配信対象ユーザの割り当て処理を行う。具体的には、広告配信管理装置１は、複数の注文要求のそれぞれの指定ユーザ属性および指定配信数に基づき、注文要求に未割り当ての配信対象ユーザが有する所定のユーザ属性の数が最大化するように、複数の注文要求に対して配信対象ユーザを割り当てる。以下、注文要求に未割り当ての配信対象ユーザを未割り当てユーザと記載する場合がある。

例えば、図１Ｂに示すように、指定ユーザ属性が「属性Ａ」、かつ、指定配信数が「２」である注文要求７ａと、指定ユーザ属性が「属性Ｄ」、かつ、指定配信数が「１」である注文要求７ｂが広告主端末３から広告配信管理装置１へ送信された場合を考える。また、上記所定のユーザ属性（以下、適切度判定用属性と記載する）が、「属性Ｂ」、「属性Ｃ」、「属性Ｄ」であるとする。

注文要求７ａの指定ユーザ属性である「属性Ａ」を有する配信対象ユーザ６ａ、６ｃを注文要求７ａに割り当て、注文要求７ｂの指定ユーザ属性である「属性Ｄ」を有する配信対象ユーザ６ｅを割り当てた場合、未割り当てユーザが有する属性Ａ〜Ｅの数は、それぞれ「１」、「１」、「０」、「１」、「１」である。したがって、未割り当てユーザが有する適切度判定用属性（属性Ｂ〜Ｄ）の総数（以下、未割り当てスコアと記載する）は「２」である。

一方、注文要求７ａの指定ユーザ属性である「属性Ａ」を有する配信対象ユーザ６ａ、６ｂを注文要求７ａに割り当て、注文要求７ｂの指定ユーザ属性である「属性Ｄ」を有する配信対象ユーザ６ｄを割り当てた場合、未割り当てユーザが有する属性Ａ〜Ｅの数は、それぞれ「１」、「１」、「２」、「２」、「１」である。したがって、未割り当てユーザが有する適切度判定用属性（属性Ｂ〜Ｄ）の総数である未割り当てスコアは「５」である。

複数の注文要求７ａ、７ｂに対して配信対象ユーザを割り当てた場合の未割り当てスコアが最大となるのは、配信対象ユーザ６ａ、６ｂ、６ｄを割り当てた場合である。したがって、広告配信管理装置１は、複数の注文要求７ａ、７ｂに対して配信対象ユーザ６ａ、６ｂ、６ｄを割り当てる。

このように、広告配信管理装置１は、未割り当てスコアが最大となるように、複数の注文要求に対して配信対象ユーザを割り当てる。未割り当てスコアは未割り当てユーザが有する適切度判定用属性の数であることから、適切度判定用属性として、例えば、注文要求で指定される頻度が高いユーザ属性を設定することによって、将来の注文要求に対する受け付け可能性を増加させることができ、販売機会の損失を抑制することができる。

なお、適切度判定用属性は、複数のユーザ属性のうち一部のユーザ属性として説明したが、全てのユーザ属性を適切度判定用属性とすることもできる。例えば、注文要求７ａ、７ｂに対して配信対象ユーザ６ａ、６ｃ、６ｅを割り当てた場合、未割り当てスコアは「４」である。一方、注文要求７ａ、７ｂに対して配信対象ユーザ６ａ、６ｂ、６ｄを割り当てた場合、未割り当てスコアは「７」である。

このように全てのユーザ属性を適切度判定用属性とすることで、注文要求に対する配信対象ユーザの割り当て可能なユーザ属性の総数を増加させることができる。したがって、この場合でも、将来の注文要求に対する受け付け可能性が増加することから、販売機会の損失を抑制することができる。

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

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

通信部１０は、ＮＩＣ（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 (5)

1. 将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶する予測情報記憶手段と、
   ユーザ属性を指定した複数の注文要求を取得する取得手段と、
   前記取得手段により新たな注文要求が取得される毎に、当該新たな注文要求と前記取得手段により過去に取得された注文要求とを含む前記複数の注文要求に対して前記配信対象ユーザを割り当てる処理を行う割当手段と、
   を備えることを特徴とする広告配信管理装置。
2. 前記取得手段は、
   ユーザ属性および配信数をそれぞれ指定する複数の注文要求を取得し、
   前記割当手段は、
   前記複数の注文要求のそれぞれで指定されるユーザ属性および配信数に基づき、前記注文要求に未割り当ての配信対象ユーザが有する所定のユーザ属性の数が最大化するように前記複数の注文要求に対して前記配信対象ユーザを割り当てる
   ことを特徴とする請求項１に記載の広告配信管理装置。
3. 前記割当手段は、
   前記複数の注文要求に対し、線形計画法を用いて前記配信対象ユーザの割り当てを行う
   ことを特徴とする請求項１または２に記載の広告配信管理装置。
4. 前記割当手段は、
   広告主からの広告配信の注文で指定される頻度が閾値以上である２以上のユーザ属性の組み合わせを一つのユーザ属性として前記配信対象ユーザを割り当てる
   ことを特徴とする請求項１〜３のいずれか一つに記載の広告配信管理装置。
5. コンピュータが実行する広告配信管理方法であって、
   ユーザ属性を指定した複数の注文要求を取得するステップと、
   新たな注文要求が取得される毎に、将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性の情報を記憶する記憶部に記憶された前記ユーザ属性の情報に基づいて、前記複数の配信対象ユーザの中から前記新たな注文要求と過去に取得された注文要求とを含む前記複数の注文要求に対して前記配信対象ユーザを割り当てる処理を行うステップと、
   を含むことを特徴とする広告配信管理方法。

Images