(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）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。また、広告配信管理装置１および情報配信装置２を一つのサーバコンピュータで実現してもよい。
【符号の説明】
【０１６０】
１  広告配信管理装置
２  情報配信装置
３  広告主端末
４  ユーザ端末
５  通信ネットワーク
１０  通信部
１１  広告情報ＤＢ
１２  ユーザ情報ＤＢ
１３  過去ログＤＢ
１４  将来ログＤＢ
２１  広告配信部
２２  将来ログ予測部
２３  受付部
２４  スコア判定部
２５  割当部
２６  再割当部
【図１】
0005600727.tif 000002
【図２】
0005600727.tif 000003
【図３】
0005600727.tif 000004
【図４】
0005600727.tif 000005
【図５】
0005600727.tif 000006
【図６】
0005600727.tif 000007
【図７】
0005600727.tif 000008
【図８】
0005600727.tif 000009
【図９】
0005600727.tif 000010