JP5602211B2 - 広告配信管理装置および広告配信管理方法 - 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 (6)

1. 将来の広告配信先として予測される複数の配信対象ユーザのユーザ属性を含む情報を記憶する予測情報記憶手段と、
   新たな広告配信の注文要求に対し、当該注文要求に対する前記配信対象ユーザの割り当て前後で、前記複数の配信対象ユーザのうち広告配信の注文要求に対して割り当てられていない配信対象ユーザのユーザ属性の延べ総数の減少が最小となるように前記配信対象ユーザを割り当てる割当手段と、
   を有することを特徴とする広告配信管理装置。
2. 前記複数の配信対象ユーザのうち広告配信の注文要求に対して割り当てられていない配信対象ユーザのユーザ属性の延べ総数をカウントするカウント手段を備える
   ことを特徴とする請求項１に記載の広告配信管理装置。
3. 前記広告配信の注文要求には１以上のユーザ属性を指定する情報が含まれており、
   前記割当手段は、
   前記新たな広告配信の注文要求に対して、当該注文要求で指定されたユーザ属性を有する配信対象ユーザを割り当てる
   ことを特徴とする請求項１または２に記載の広告配信管理装置。
4. 前記割当手段は、
   前記注文要求により指定されるユーザ属性以外のユーザ属性の減少が所定以下となる範囲で前記延べ総数の減少が最小となるように前記配信対象ユーザを割り当てる
   ことを特徴とする請求項１〜３のいずれか１つに記載の広告配信管理装置。
5. 前記カウント手段は、
   前記広告配信の注文要求で指定される頻度が閾値以上である２以上のユーザ属性の組み合わせを一つのユーザ属性として前記延べ総数をカウントする
   ことを特徴とする請求項２〜４のいずれか１つに記載の広告配信管理装置。
6. コンピュータによって実行される広告配信管理方法であって、
   コンピュータが、広告主からの新たな広告配信の注文に対し、将来の広告配信先として予測される複数の配信対象ユーザのうち広告主からの広告配信の注文に対して割り当てられていない配信対象ユーザのユーザ属性の延べ総数の減少が、前記新たな広告配信の注文に対する前記配信対象ユーザの割り当て前後で、最小となるように前記配信対象ユーザを割り当てる割当ステップ、
   を含むことを特徴とする広告配信管理方法。

Images