(57)【特許請求の範囲】
【請求項１】
将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む予測情報を記憶する予測情報記憶手段と、
新たな広告配信の注文要求に対し、当該注文要求に対する前記配信対象ユーザの割り当て前後で、前記複数の配信対象ユーザのうち広告配信の注文要求に未割り当ての配信対象ユーザである未割り当てユーザのユーザ属性別の数または比率に応じた割り当てスコアの減少が最小となるように前記新たな広告配信の注文要求に対して配信対象ユーザを割り当てる割当手段と、
を有することを特徴とする広告配信管理装置。 
【請求項２】
前記複数の配信対象ユーザのうち広告配信の注文要求に未割り当ての配信対象ユーザである未割り当てユーザのユーザ属性別の数または比率に基づき、前記注文要求に対する配信対象ユーザの割り当ての適切度を示す前記割り当てスコアを求めるスコア判定手段を備える
ことを特徴とする請求項１に記載の広告配信管理装置。
【請求項３】
前記スコア判定手段は、
前記未割り当てユーザの数または比率が最も少ないユーザ属性の前記未割り当てユーザの数または比率を前記割り当てスコアとする
ことを特徴とする請求項２に記載の広告配信管理装置。 
【請求項４】
前記スコア判定手段は、
前記予測情報から前記ユーザ属性別の配信対象ユーザの予測数または予測比率を求め、当該ユーザ属性別の予測数または予測比率に対する前記未割り当てユーザの数または比率の比を前記ユーザ属性毎に算出し、当該算出結果の最小値を前記割り当てスコアとする
ことを特徴とする請求項２に記載の広告配信管理装置。 
【請求項５】
前記スコア判定手段は、
前記予測情報から前記ユーザ属性別の配信対象ユーザの予測数または予測比率を求め、当該ユーザ属性別の予測数または予測比率に対する前記未割り当てユーザの数または比率の比を前記ユーザ属性毎に算出し、当該算出結果の合計値を前記割り当てスコアとする
ことを特徴とする請求項２に記載の広告配信管理装置。 
【請求項６】
前記割当手段は、
広告主からの広告配信の注文で指定される頻度が閾値以上である２以上のユーザ属性の組み合わせを一つのユーザ属性として前記配信対象ユーザを割り当てる
ことを特徴とする請求項１〜５のいずれか一つに記載の広告配信管理装置。 
【請求項７】
コンピュータによって実行される広告配信管理方法であって、
コンピュータが、新たな広告配信の注文要求に対し、将来の広告配信先として予測される複数の配信対象ユーザのうち広告配信の注文要求に未割り当ての配信対象ユーザである未割り当てユーザのユーザ属性別の数または比率に応じた割り当てスコアの減少が、前記新たな注文要求に対する前記配信対象ユーザの割り当て前後で、最小となるように前記新たな広告配信の注文要求に対して配信対象ユーザを割り当てる割当ステップ、
を含むことを特徴とする広告配信管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広告配信管理装置および広告配信管理方法に関する。
【背景技術】
【０００２】
近年、インターネットなどのネットワークの飛躍的な普及に伴い、ネットワークを介した広告配信が盛んに行われている。かかる広告配信の一つの形態として、広告配信の対象となるページ（以下、広告配信対象ページと記載する）内の一定スペースに画像や映像などを用いて広告を表示するディスプレイ広告が知られている。
【０００３】
ディスプレイ広告では、広告主によって指定されたユーザ属性（性別、年齢、興味など）を有するユーザに対して広告配信を行うことによって、効果的な広告配信が行われている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−２３８０２０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した広告配信では、広告配信対象ページへアクセスしたユーザのユーザ属性が広告主によって指定されたユーザ属性である場合に、広告が配信される。そのため、将来の広告配信先となる配信対象ユーザをそのユーザ属性を含めて将来ログとして予測し、かかる将来ログに基づいて広告主からの注文を受け付けることが望ましい。
【０００６】
しかし、将来の広告配信先となる配信対象ユーザが複数のユーザ属性を有する場合、広告配信の注文に対する配信対象ユーザの割り当て方によっては、広告主からの新たな注文に対する受け付けが難しくなる場合がある。
【０００７】
本願は、上記に鑑みてなされたものであって、広告配信の注文に対する配信対象ユーザの割り当てを適切に行うことができる広告配信管理装置および広告配信管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本願に係る広告配信管理装置は、将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む予測情報を記憶する予測情報記憶手段と、新たな広告配信の注文要求に対し、当該注文要求に対する前記配信対象ユーザの割り当て前後で、前記複数の配信対象ユーザのうち広告配信の注文要求に未割り当ての配信対象ユーザである未割り当てユーザのユーザ属性別の数または比率に応じた割り当てスコアの減少が最小となるように前記新たな広告配信の注文要求に対して配信対象ユーザを割り当てる割当手段とを備えることを特徴とする。
【発明の効果】
【０００９】
実施形態の一態様によれば、広告配信の注文に対する配信対象ユーザの割り当てを適切に行うことができる広告配信管理装置および広告配信管理方法を提供することができる。
【図面の簡単な説明】
【００１０】
【図１Ａ】図１Ａは、実施形態に係る広告配信管理処理の説明図（その１）である。
【図１Ｂ】図１Ｂは、実施形態に係る広告配信管理処理の説明図（その２）である。
【図２】図２は、実施形態に係る広告配信管理装置の構成を示す図である。
【図３】図３は、広告情報テーブルの一例を示す図である。
【図４】図４は、ユーザ情報テーブルの一例を示す図である。
【図５】図５は、アクセスログテーブルの一例を示す図である。
【図６】図６は、将来ログテーブルの一例を示す図である。
【図７】図７は、実施形態に係る広告配信管理装置の広告配信管理処理フローを示す図である。
【図８】図８は、実施形態に係る広告配信管理装置の割り当て処理フローの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下に、本願に係る広告配信管理装置および広告配信管理方法を実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る広告配信管理装置および広告配信管理方法が限定されるものではない。また、以下においては、「データベース」を「ＤＢ」と記載するものとする。
【００１２】
〔１．広告配信管理処理〕
まず、実施形態に係る広告配信管理処理について説明する。図１Ａおよび図１Ｂは、実施形態に係る広告配信管理処理の説明図であり、かかる広告配信管理処理によって広告主からの注文に対して配信対象ユーザの割り当てを適切に行っている。
【００１３】
図１Ａに示すように、実施形態に係る広告配信管理システムは、広告配信管理装置１（広告配信管理装置の一例に相当）、情報配信装置２、広告主端末３およびユーザ端末４を有する。広告配信管理装置１、情報配信装置２、広告主端末３およびユーザ端末４は、互いに通信ネットワーク５を介して接続される。通信ネットワーク５は、例えば、インターネットなどのＩＰ（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）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。また、広告配信管理装置１および情報配信装置２を一つのサーバコンピュータで実現してもよい。
【符号の説明】
【０１３２】
１  広告配信管理装置
２  情報配信装置
３  広告主端末
４  ユーザ端末
５  通信ネットワーク
１０  通信部
１１  広告情報ＤＢ
１２  ユーザ情報ＤＢ
１３  過去ログＤＢ
１４  将来ログＤＢ
２１  広告配信部
２２  将来ログ予測部
２３  受付部
２４  スコア判定部
２５  割当部
【図１Ａ】
0005602212.tif 000002
【図１Ｂ】
0005602212.tif 000003
【図２】
0005602212.tif 000004
【図３】
0005602212.tif 000005
【図４】
0005602212.tif 000006
【図５】
0005602212.tif 000007
【図６】
0005602212.tif 000008
【図７】
0005602212.tif 000009
【図８】
0005602212.tif 000010