JP7410099B2

JP7410099B2 - 情報処理装置、情報処理方法及び情報処理プログラム

Info

Publication number: JP7410099B2
Application number: JP2021142672A
Authority: JP
Inventors: 謙章平澤
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-09-01
Filing date: 2021-09-01
Publication date: 2024-01-09
Anticipated expiration: 2041-09-01
Also published as: JP2023035656A

Description

本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。

近年、広告等のコンテンツの配信に関する様々な技術が提供されている。例えば、予算、期間、配信対象（ターゲット）などの条件を基に広告を配信する広告キャンペーン（予約型広告）に関する技術が提案されている（例えば特許文献１等）。

特許第６６２１９５４号公報

しかしながら、上記の従来技術には、改善の余地がある。上記の従来技術では、キャンペーンに関する成果を予測するものはあるが、キャンペーンに関する広告（コンテンツ）を配信可能な在庫（リクエスト）に関する推定を行うものではない。そのため、キャンペーンのコンテンツを配信可能な在庫（リクエスト）の数を適切に推定することが難しく、コンテンツの配信に関する情報を適切に推定することが望まれている。

本願は、上記に鑑みてなされたものであって、コンテンツの配信に関する情報を適切に推定することができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願にかかる情報処理装置は、推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける受付部と、前記第１配信期間に前記第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報と、前記第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、前記第１配信期間に重なる第２配信期間の条件を含む第２条件とを取得する取得部と、前記第１条件と前記第２条件との重複に基づいて、前記予定在庫のうち、前記第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する推定部と、を備えたことを特徴とする。

実施形態の一態様によれば、コンテンツの配信に関する情報を適切に推定することができるといった効果を奏する。

図１は、実施形態に係る情報処理の一例を示す図である。図２は、実施形態に係る情報処理システムの構成例を示す図である。図３は、実施形態に係る情報処理装置の構成例を示す図である。図４は、実施形態に係る配信ログ情報記憶部の一例を示す図である。図５は、実施形態に係る割当済ログ情報記憶部の一例を示す図である。図６は、実施形態に係るキャンペーン情報記憶部の一例を示す図である。図７は、実施形態に係る重複割合情報記憶部の一例を示す図である。図８は、実施形態に係る情報処理の一例を示すフローチャートである。図９は、異なり数の推定に関する処理を示す概念図である。図１０は、重複割合の推定に関する一例を示す図である。図１１は、重複割合の推定に関する具体例を示す図である。図１２は、情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る情報処理装置、情報処理方法、情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法、情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

（実施形態）
〔１．情報処理〕
まず、図１を用いて、実施形態に係る情報処理の一例について説明する。図１は、実施形態に係る情報処理の一例を示す図である。図１では、情報処理システム１（図２参照）が広告コンテンツ（単に「広告」ともいう）を配信する広告キャンペーン（単に「キャンペーン」ともいう）を対象として情報処理を行う場合を示す。なお、対象とするコンテンツは広告に限らず、以下に示す処理が適用可能なコンテンツであればどのようなコンテンツであってもよい。

まず、図１に示す各構成について簡単に説明する。配信サーバ２０は、ウェブページや広告などのコンテンツを配信するサーバ装置である。配信サーバ２０は、配信期間、配信先（ターゲット）となるユーザの属性（性別、年齢等）が指定されたキャンペーンに関する予約を受け付ける。例えばキャンペーンは予約型広告とも称される。なお、「性別」及び「年齢」は、ユーザの属性の一例に過ぎず、ユーザの属性は、年齢、性別以外にも居住地等のデモグラフィック属性であってもよく、興味・関心等のサイコグラフィック属性等の様々な属性であってもよい。配信サーバ２０は、予約を受け付けたキャンペーン（予約済みキャンペーン）に関する広告を、予約済みキャンペーンが指定する配信期間に配信先の条件を満たすユーザに配信する。配信サーバ２０は、ユーザへのコンテンツの配信に関する履歴を配信ログとして収集し、システムＳＹへ提供する。

広告主端末３０は、広告主ＡＴによって利用されるコンピュータである。広告主端末３０は、推定対象となるキャンペーン（「第１キャンペーン」ともいう）についてのシミュレーションをシステムＳＹに要求する。広告主端末３０は、予約前のキャンペーンについてのシミュレーションをシステムＳＹに要求する。広告主端末３０は、予約前のキャンペーンに割合可能な残在庫の数の推定をシステムＳＹに要求する。例えば、広告主端末３０は、予約前のキャンペーンである第１キャンペーンの配信期間、配信先（ターゲット）となるユーザの属性（性別、年齢等）の条件を含む第１条件を、システムＳＹに送信し、送信した第１条件件を基に、第１キャンペーンに割合可能な残在庫の数の推定をシステムＳＹに要求する。

推定処理を実行するシミュレーションシステムであるシステムＳＹは、配信期間を含む条件が重なるキャンペーン間の条件の重複に基づいて、キャンペーンに対して割当可能な残在庫の数を推定する。システムＳＹは、広告主端末３０から第１キャンペーンの第１条件を受信し、受信した第１条件を基に第１キャンペーンに割合可能な残在庫の数を推定する。なお、以下ではシステムＳＹが情報処理装置１００（図３参照）により実現される場合を一例として説明する。なお、図１の説明における情報処理装置１００はシステムＳＹと読み替えてもよい。システムＳＹの機能が実現可能であれば任意の装置構成が採用可能であり、複数の装置により実現されてもよく、例えば、システムＳＹ中のシミュレータＳＭ、検索エンジンＳＥ、及び予約データベースＲＤＢは各々が異なる装置により実現されてもよい。この場合、情報処理装置１００がシミュレータＳＭであり、情報処理装置１００が検索エンジンＳＥの装置及び予約データベースＲＤＢの装置との間で情報を送受信することにより図１に示す処理を行ってもよい。

以下、図１を用いて、情報処理の一例を説明する。図１では、第１キャンペーンがキャンペーンＡであり、処理時点が２０２０年８月１４日である場合を示す。

情報処理装置１００は、配信サーバ２０から配信ログと予約済みキャンペーン情報を取得する（ステップＳ１）。配信サーバ２０は、処理時点以前の配信ログを情報処理装置１００に送信する。例えば、配信サーバ２０は、情報処理装置１００から指定された期間における配信の配信ログを情報処理装置１００に送信する。図１では、配信サーバ２０は、処理時点（２０２０年８月１４日）までに収集された配信ログ（例えば直近１カ月の配信ログ等）を情報処理装置１００に送信する。これにより、情報処理装置１００は、図４中の配信ログ情報記憶部１２１に示すような配信ログを配信サーバ２０から取得する。

また、配信サーバ２０は、既に予約を受け付けたキャンペーンに関する情報を予約済みキャンペーン情報として情報処理装置１００に送信する。例えば、配信サーバ２０は、既に予約を受け付けたキャンペーンである第２キャンペーンに関する情報を予約済みキャンペーン情報として情報処理装置１００に送信する。例えば、配信サーバ２０は、第２キャンペーンに指定された配信期間（「第２配信期間」ともいう）等を含む条件（「第２条件」ともいう）に関する情報を情報処理装置１００に送信する。図１では、配信サーバ２０は、予約済みキャンペーンであるキャンペーンＸの条件（第２条件）を示す情報を情報処理装置１００に送信する。キャンペーンＸの第２条件は、第２配信期間が２０２０年８月１６日－２１日であり、配信先の条件が２０代女性であるものとする。なお、第２条件には、例えば予約数（配信回数）に関する情報等が含まれる。情報処理装置１００は、配信サーバ２０から受信した予約済みキャンペーン情報を記憶部１２０に記憶する。

そして、情報処理装置１００は、集計処理ＴＢにより、配信ログから未来ログを生成し、生成した未来ログに対して予約済みキャンペーンを割り当てることにより、割当済ログ（キャンペーン割当済みｖｉｍｐログ）を生成する（ステップＳ２）。情報処理装置１００は、割当済ログを、割当済ログ情報記憶部１２２（図５参照）に登録する。情報処理装置１００は、図５中の割当済ログ情報記憶部１２２に示すように、各ログの日付を未来の日付に変更した未来日付を各配信ログに対応付けて登録する。情報処理装置１００は、日付を２週間（１４日）先に変更した未来日付を各配信ログに対応付け、各配信ログをその未来日付に行われるリクエストとする。

そして、情報処理装置１００は、割当済ログ情報記憶部１２２に示す未来日付に行われるリクエスト（未来在庫）を対象として、第２条件に該当する在庫に第２キャンペーンを割り当てる集計処理を実行する。図１では、情報処理装置１００は、図５中の割当済ログ情報記憶部１２２に示すように、未来日付「２０２０年８月１６日」に行われるリクエスト（未来在庫）を対象として、キャンペーンＸの第２条件「２０代女性」に該当する在庫（ｖｉｍｐ２）にキャンペーンＸを割り当てる。情報処理装置１００は、割当済ログ（history-index）を用いた検索処理により検索エンジンＳＥとして機能するが詳細は後述する。

このように、情報処理装置１００は、キャンペーンのような予約型の在庫管理において、各配信ログに未来の日付を対応付け、対応するキャンペーンを割り当てる（紐付ける）集計を行う。なお、図１では処理の流れを説明するために、１つのキャンペーンＸのみを予約済みキャンペーンとして説明するが、複数の予約済みキャンペーンがある場合、情報処理装置１００は、任意の方法により各予約済みキャンペーンを配信ログに割り当てる集計処理を実行してもよい。例えば、情報処理装置１００は、各予約済みキャンペーンの条件（第２条件）を基に、複数の予約済みキャンペーンの配信ログへの割り当ての組合せの最適解を求める集計処理を実行してもよい。例えば、情報処理装置１００は、予約が早い方から順に予約済みキャンペーンをその第２条件に該当する配信ログに割り当てることにより、複数の予約済みキャンペーンの配信ログへの割り当てを行ってもよい。

なお、上記は一例に過ぎず、情報処理装置１００は、組合せ最適化の手法等、任意の方法を適宜用いて予約済みキャンペーンを配信ログに割り当ててもよい。情報処理装置１００は、集計結果をあらかじめ割当済ログ情報記憶部１２２に格納しておき、シミュレーション時に指定された条件に応じてリアルタイムで検索処理を実行することで、全体がどれだけか、残りがどれだけかが計算できる。

また、情報処理装置１００は、広告主ＡＴが利用する広告主端末３０からは、シミュレーション条件を受け付ける（ステップＳ３）。図１では、広告主端末３０は、広告主ＡＴの操作に応じて、推定対象となる第１キャンペーンであるキャンペーンＡについて、広告主ＡＴが指定を予定している配信期間（「第１配信期間」ともいう）等を含む条件（「第１条件」ともいう）を情報処理装置１００に送信する。キャンペーンＡの第１条件は、第１配信期間が２０２０年８月１５日－２０日であり、配信先の条件が女性であるものとする。なお、第１条件には、例えば予約数（配信回数）に関する情報等が含まれる。これにより、情報処理装置１００は、キャンペーンＡについての第１条件をシミュレーション条件として受け付ける。情報処理装置１００は、受け付けたシミュレーション条件を用いてシミュレータＳＭとしての処理を実行する。

情報処理装置１００は、キャンペーンＡについての第１条件をシミュレーション条件として、検索エンジンＳＥの検索処理を実行する（ステップＳ４）。そして、情報処理装置１００は、割当済ログのうちキャンペーンＡの第１条件に該当する配信ログを、シミュレーション用中間集計結果として抽出する（ステップＳ５）。例えば、情報処理装置１００は、割当済ログ情報記憶部１２２中の配信ログのうち、未来日付が第１配信期間に該当し、且つ性別及び年齢が第１条件の配信先の条件に該当する配信ログを抽出する。図１では、情報処理装置１００は、割当済ログのうち未来日付が２０２０年８月１５日－２０日の期間内であり、且つ性別が女性である配信ログを抽出する。例えば、情報処理装置１００は、割当済ログ情報記憶部１２２の配信ログのうち、第１条件のうちｖｉｍｐ１、ｖｉｍｐ２等の配信ログを抽出する。情報処理装置１００は、割当済ログのうち未来日付が２０２０年８月１５日－２０日の期間内であり、且つ性別が女性である配信ログを、キャンペーンＡの配信先になり得るリクエストを示す予定在庫（単に「在庫」ともいう）として抽出する。

情報処理装置１００は、抽出した配信ログを用いて、各種情報を算出する。情報処理装置１００は、第１条件に該当するとして抽出した配信ログ（予定在庫）をカウントし、予定在庫（「総在庫」ともいう）の数を算出する。例えば、情報処理装置１００は、キャンペーンＡのの配信先になり得る総在庫の数を「１０００００」と算出する。また、情報処理装置１００は、第１条件に該当するとして抽出した配信ログ（予定在庫）のうち、割り当てられたキャンペーンが無い在庫ををカウントし、その在庫（「残在庫」ともいう）の数を算出する。例えば、図５では、ｖｉｍｐ２はキャンペーンＡに割当可能な在庫であるが、既にキャンペーンＸに割当済みである。

そのため、情報処理装置１００は、ｖｉｍｐ２等のようにキャンペーンＡに割当可能な在庫であっても既にキャンペーンＸに割当済みである在庫については、キャンペーンＡに対して割当可能な在庫からは除外する。以下、ｖｉｍｐ２等のように第１キャンペーンに割当可能な在庫であるが、既に第２キャンペーンに割当済みである在庫を「割当済み在庫」ともいう。例えば、情報処理装置１００は、割当済み在庫の数を「２００００」と算出する。この場合、情報処理装置１００は、総在庫の数「１０００００」から割当済み在庫の数「２００００」を減算することにより、キャンペーンＡに対する残在庫の数を「８００００（＝１０００００－２００００）」であると推定する。

これにより、情報処理装置１００は、第１条件と前記第２条件との重複に基づいて、予定在庫のうち、第１キャンペーンに対して割当可能な在庫である残在庫の数を推定することができる。

ここで、全てのログに対し、予約済みキャンペーンのどれが配信できるかを判定する処理や、予約した量に応じて適切に割り当てる処理が重いため、集計処理の頻度を上げることは難しい場合がある。このような場合、集計処理を実行する間隔は例えば日に一回等となり、直近予約されたキャンペーンが集計処理の対象となっておらず、その情報は含まれていない場合がある。このような場合、集計処理後、第１キャンペーンについてのシミュレーションを行う前に、他のキャンペーン（第２キャンペーン）が予約された場合、この第２キャンペーン（以下「未反映キャンペーン」）の情報も反映して処理を行うことにより、より精度を高めることが可能となる。そのため、情報処理装置１００は、以下の処理を実行する。例えば、情報処理装置１００は、集計処理とは別に、予約した内容を即時に反映させるための処理を実行する。

なお、以下の処理（ステップＳ６以降の処理）の説明では、上記の処理（ステップＳ５迄の処理）で推定した残在庫を「仮残在庫」と記載する場合がある。また、図１では、ステップＳ２の集計処理後にキャンペーンＢ～Ｄの３つのキャンペーンが予約された場合を示し、説明のためにキャンペーンＡの第１条件と条件が重複する未反映キャンペーンがキャンペーンＢのみである場合を一例として説明する。なお、ステップＳ６～ステップＳ８の処理を「予約状況即時反映処理」ともいう。

まず、情報処理装置１００は、未反映キャンペーンのキャンペーン情報を予約データベースＲＤＢに要求し（ステップＳ６）、予約データベースＲＤＢから直近の予約済みキャンペーンのキャンペーン情報を取得する（ステップＳ７）。例えば、情報処理装置１００は、予約データベースＲＤＢ中の未反映キャンペーンのうち、条件がキャンペーンＡの第１条件と重複するキャンペーンのキャンペーン情報を取得する。図１では、情報処理装置１００は、キャンペーンＡの第１条件と条件が重複する未反映キャンペーンがキャンペーンＢのキャンペーン情報を取得する。情報処理装置１００は、予約データベースＲＤＢとしてキャンペーン情報記憶部１２３（図６参照）を用い、キャンペーン情報記憶部１２３からキャンペーンＢのキャンペーン情報を取得する。なお、情報処理装置１００は、キャンペーン情報記憶部１２３に記憶する情報を配信サーバ２０から受信し、キャンペーン情報記憶部１２３に登録してもよい。このように、情報処理装置１００は、直近の予約済みキャンペーンを保持する予約データベースＲＤＢの情報を用いることで、集計経由のデータで足りない部分を補うことができる。

情報処理装置１００は、未反映キャンペーンを反映したキャンペーンＡに対する残在庫の数を推定する（ステップＳ８）。図１では、情報処理装置１００は、キャンペーンＢを反映したキャンペーンＡに対する残在庫の数を推定する。例えば、情報処理装置１００は、キャンペーンＡの条件（第１条件）と、キャンペーンＢの条件（未反映条件）との重複割合を推定する。例えば、情報処理装置１００は、各リクエスト（在庫）が所定のハッシュ法によりハッシュ（ハッシュ値）に変換し、重なり数推定に関する手法を用いて重複割合を推定する。なお、この処理の詳細については後述する。例えば、情報処理装置１００は、推定した重複割合と総在庫の数とを乗算することにより値（「除外在庫数」ともいう）を算出する。そして、情報処理装置１００は、除外在庫数を仮残在庫から減算することにより、残在庫の数を推定する。図１では、情報処理装置１００は、キャンペーンＡの条件（第１条件）と、キャンペーンＢの条件（未反映条件）との重複割合を用いて、除外在庫数を例えば「１００００」と算出する。そして、情報処理装置１００は、仮残在庫の数「８００００」から除外在庫数「１００００」を減算することにより、キャンペーンＡに対する残在庫の数を「７００００（＝８００００－１００００）」であると推定する。

なお、図１では処理の流れを説明するために、１つのキャンペーンＢのみを未反映キャンペーンとして説明するが、複数の未反映キャンペーンがある場合、情報処理装置１００は、複数の未反映キャンペーンについてキャンペーンＡとの重複割合を算出し、算出した複数の重複割合の合計値と総在庫の数とを乗算した値を除外在庫数として用いてもよい。

また、上述したような重なり数推定を用いた処理は一例に過ぎず、情報処理装置１００は、任意の方法により未反映キャンペーンの情報を加味して第１キャンペーンに対する残在庫を推定してもよい。例えば、情報処理装置１００は、未反映キャンペーンについても配信ログに割り当てることにより、第１キャンペーンに対する残在庫を推定してもよい。この場合、情報処理装置１００は、仮残在庫のうち、未反映キャンペーンの条件を満たす在庫に、その未反映キャンペーンを割り当ててもよい。図１では、情報処理装置１００は、仮残在庫のうち、キャンペーンＢの条件を満たす在庫に、キャンペーンＢを割り当ててもよい。そして、情報処理装置１００は、未反映キャンペーンを割り当てた在庫の数を残在庫の数から減算することにより、第１キャンペーンに対する残在庫を推定してもよい。図１では、キャンペーンＢを割り当てた在庫の数が「１００００」である場合、情報処理装置１００は、仮残在庫の数「８００００」からキャンペーンＢを割り当てた在庫の数「１００００」を減算することにより、キャンペーンＡに対する残在庫の数を「７００００（＝８００００－１００００）」であると推定する。

そして、情報処理装置１００は、推定したキャンペーンＡに対する残在庫の情報を広告主ＡＴに提供する（ステップＳ９）。例えば、情報処理装置１００は、キャンペーンＡに対する残在庫の数が「７００００」であることを示す情報を広告主ＡＴが利用する広告主端末３０に送信する。

上述したように、情報処理装置１００は、集計処理後に追加された第２キャンペーンについては未反映キャンペーンとして、第１キャンペーンとの重複割合を求め、その重複割合を基に第１キャンペーンへ割合可能な残在庫を推定する。これにより、情報処理装置１００は、コンテンツの配信に関する情報を適切に推定することができる。

〔２．情報処理システムの構成〕
次に、図２を用いて、情報処理システム１の構成について説明する。図２は、実施形態に係る情報処理システムの構成例を示す図である。図２に例示するように、実施形態にかかる情報処理システム１には、ユーザ端末１０と、配信サーバ２０と、広告主端末３０と、情報処理装置１００とが含まれる。これらの各種装置は、ネットワークＮ（例えば、インターネット）を介して、有線又は無線により通信可能に接続される。なお、図２に示した情報処理システム１には、複数台のユーザ端末１０や、複数台の配信サーバ２０や、複数台の広告主端末３０が含まれてもよい。

ユーザ端末１０は、ユーザによって利用される端末装置である。例えば、ユーザ端末１０は、タブレット型端末、ＰＣ（Personal Computer）、携帯電話機、ＰＤＡ（Personal Digital Assistant）等である。例えば、ユーザ端末１０は、所定のウェブサーバにアクセスすることで、所定のウェブサーバからウェブページを取得し、取得したウェブページを表示画面に表示する。

また、ユーザ端末１０は、ウェブページに広告枠が含まれる場合には、配信サーバ２０にアクセスすることで、配信サーバ２０から広告を取得し、取得した広告を広告枠に表示する。

配信サーバ２０は、広告主端末３０から入稿された広告を配信するサーバ装置である。配信サーバ２０は、広告主端末３０から配信期間、配信先（ターゲット）となるユーザの属性（性別、年齢等）が指定されたキャンペーンに関する予約を受け付ける。

配信サーバ２０は、ウェブページや広告などのコンテンツの配信ログやユーザの行動履歴等の様々な履歴情報を保持する。配信サーバ２０は、配信した広告の配信ログを保持する。配信サーバ２０は、配信したウェブページまたは広告等、過去にユーザに配信したコンテンツに関する履歴である配信ログを情報処理装置１００へ提供する。例えば、配信サーバ２０は、広告がユーザの視認領域に表示された配信（ビューアブルインプレッション）を対象に、そのユーザの属性等に関する情報を配信ログとして収集する。

配信サーバ２０は、ビューアブルインプレッションとなった配信におけるユーザの属性等を示す配信ログを情報処理装置１００へ送信する。また、配信サーバ２０は、ユーザの検索クエリやユーザの訪問ページといったアクセスログを保持してもよい。配信サーバ２０は、ユーザのアクセスログを情報処理装置１００へ送信してもよい。

広告主端末３０は、広告主によって利用される端末装置である。例えば、広告主端末３０は、タブレット型端末、ＰＣ、携帯電話機、ＰＤＡ等である。また、広告主端末３０は、広告主の操作に従って、広告を配信サーバ２０に入稿する。広告主端末３０は、配信期間、配信先（ターゲット）となるユーザの属性（性別、年齢等）等を指定したキャンペーンを配信サーバ２０に入稿（送信）することにより、キャンペーンの予約を行う。例えば、広告主端末３０は、キャンペーンの広告を配信サーバ２０に入稿する。

例えば、広告主端末３０は、静止画像、動画像、テキストデータ等に該当する広告を配信サーバ２０に入稿する。また、例えば、広告主端末３０は、広告が選択操作（例えば、クリックやタップ）された場合に、遷移させる遷移先コンテンツのＵＲＬ（Uniform Resource Locator）に該当する広告を配信サーバ２０に入稿してもよい。

また、広告主端末３０は、キャンペーンに関して推定した情報の提供を情報処理装置１００に要求する。例えば、広告主端末３０は、予約前のキャンペーンについてのシミュレーションを情報処理装置１００に要求する。広告主端末３０は、予約前のキャンペーンに割合可能な残在庫の数の推定を情報処理装置１００に要求する。例えば、広告主端末３０は、予約前のキャンペーンの配信期間、配信先（ターゲット）となるユーザの属性（性別、年齢等）等を示す情報を、情報処理装置１００に送信し、送信した条件を基に、予約前のキャンペーンに割合可能な残在庫の数の推定を情報処理装置１００に要求する。

情報処理装置１００は、配信期間を含む条件が重なるキャンペーン間の条件の重複に基づいて、キャンペーンに対して割当可能な残在庫の数を推定する推定処理を実行するサーバ装置（コンピュータ）である。情報処理装置１００は、広告主端末３０からの要求に応じて、予約前のキャンペーンを対象に推定処理を実行する。情報処理装置１００は、配信サーバ２０から受信した推定処理を実行する。

なお、図２に示す情報処理システム１の装置構成は一例に過ぎず、情報処理システム１は、図１に示す情報処理を実現可能であれば、どのような装置構成であってもよい。例えば、情報処理装置１００は、配信サーバ２０と一体であってもよい。すなわち、情報処理装置１００は、コンテンツを配信するサーバとしての機能を有してもよい。

〔３．情報処理装置の構成〕
次に、図３を用いて、情報処理装置の一例である情報処理装置１００について説明する。図３は、実施形態に係る情報処理装置の構成例を示す図である。図３に示すように、情報処理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、例えば、ユーザ端末１０、配信サーバ２０との間で情報の送受信を行う。

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、図３に示すように、配信ログ情報記憶部１２１と、割当済ログ情報記憶部１２２と、キャンペーン情報記憶部１２３と、重複割合情報記憶部１２４とを有する。なお、記憶部１２０は、上記に限らず様々な情報を記憶してもよい。

記憶部１２０は、ハッシュに関する情報を記憶する。記憶部１２０は、ハッシュ関数を記憶する。例えば、記憶部１２０は、リクエストをハッシュ値に変換するために用いるハッシュ関数を記憶する。

（配信ログ情報記憶部１２１）
配信ログ情報記憶部１２１は、配信ログに関する各種情報を記憶する。図４は、実施形態に係る配信ログ情報記憶部の一例を示す図である。図４では、配信ログ情報記憶部１２１は、「ログＩＤ」、「日付」、「性別」、「年齢」といった項目を有する。

「ログＩＤ」は、広告（コンテンツ）配信の履歴を識別するための識別情報を示す。「日付」は、配信日時を示す。なお、図４では日付のみを図示するが、日付には配信の時分秒を含む情報が記憶されてもよい。

「性別」は、配信先となったユーザの性別を示す。また、「年齢」は、配信先となったユーザの年齢を示す。なお、「性別」及び「年齢」は、ユーザの属性の一例に過ぎず、ユーザの属性は、年齢、性別以外にも居住地等のデモグラフィック属性であってもよく、興味・関心等のサイコグラフィック属性等であってもよい。

図４では、ログＩＤ「ｖｉｍｐ１」により識別されるログ（ログｖｉｍｐ１）は、２０２０年８月１日における配信の履歴であり、３０代女性のユーザを配信先とする配信であることを示す。

なお、配信ログ情報記憶部１２１は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、配信ログ情報記憶部１２１は、配信時のユーザの位置等を各ログに対応付けて記憶する。

（割当済ログ情報記憶部１２２）
割当済ログ情報記憶部１２２は、未来日付が対応付けられた配信ログに関する各種情報を記憶する。図５は、実施形態に係る割当済ログ情報記憶部の一例を示す図である。図５では、割当済ログ情報記憶部１２２は、「ログＩＤ」、「元日付」、「未来日付」、「割当」、「ハッシュ」、「性別」、「年齢」といった項目を有する。

なお、割当済ログ情報記憶部１２２中の「ログＩＤ」、「元日付」、「性別」及び「年齢」の項目の情報は、配信ログ情報記憶部１２１の「ログＩＤ」、「日付」、「性別」及び「年齢」の項目の情報の各々が流用される。例えば、割当済ログ情報記憶部１２２中の「元日付」の情報は、配信ログ情報記憶部１２１の「日付」の情報に対応する。

「未来日付」は、「元日付」の日時を未来の日付に変更した日時を示す。図５では、「未来日付」は、「元日付」の日時を２週間（１４日）先に変更した日時を示す。なお、図５では日付のみを図示するが、日付には配信の時分秒を含む情報が記憶されてもよい。

「割当」は、その未来日付の配信に対して割り当てられたキャンペーンを示す。例えば、キャンペーンＸは、２０２０年８月１６日を配信期間に含むキャンペーンであり、２０代女性を配信先の条件として含むキャンペーンである。

「ハッシュ」は、対応する配信についてのリクエストがハッシュ値に変換された値を示す。例えば、「ハッシュ」は、配信日時、配信先の属性等、配信のリクエストに関する情報がハッシュ化された値を示す。

図５では、ログＩＤ「ｖｉｍｐ１」により識別されるログ（ログｖｉｍｐ１）は、２０２０年８月１日における３０代女性への配信の履歴の日付が、２０２０年８月１５日に変更された未来ログであることを示す。また、２０２０年８月１５日に変更された未来ログは、未だキャンペーンが割り当てられていないことを示す。

また、ログＩＤ「ｖｉｍｐ２」により識別されるログ（ログｖｉｍｐ２）は、２０２０年８月２日における２０代女性への配信の履歴の日付が、２０２０年８月１６日に変更された未来ログであることを示す。また、２０２０年８月１６日に変更された未来ログは、キャンペーンＸに割り当てられることを示す。また、そのリクエストから生成されたハッシュの値は、「３３２２７８」であることを示す。

なお、割当済ログ情報記憶部１２２は、上記に限らず、目的に応じて種々の情報を記憶してもよい。

（キャンペーン情報記憶部１２３）
実施形態に係るキャンペーン情報記憶部１２３は、キャンペーンに関する情報を記憶する。図６は、実施形態に係るキャンペーン情報記憶部の一例を示す図である。図６では、キャンペーン情報記憶部１２３は、「キャンペーン」、「配信開始」、「配信終了」、「ｓｏｖ」、「性別」、「年齢」、「ハッシュ」といった項目が含まれる。

「キャンペーン」は、キャンペーンを示す。なお、「キャンペーン」には、キャンペーンを識別するための識別情報（キャンペーンＩＤ等）が記憶されてもよい。

「配信開始」及び「配信終了」は、キャンペーンの配信期間に関する情報を示す。なお、図６では日付のみを図示するが、日付には時分秒を含む情報が記憶されてもよい。「配信開始」は、キャンペーンの配信開始の日時を示す。「配信終了」は、キャンペーンの配信終了の日時を示す。「ｓｏｖ」は、重複割合を推定するために用いる情報（値）を示す。

「性別」は、配信対象とするユーザの性別に関する条件を示す。また、「年齢」は、配信対象とするユーザの年齢に関するを示す。なお、「性別」及び「年齢」は、配信先に関する条件の一例に過ぎず、配信先に関する条件は、年齢、性別以外にも居住地等のデモグラフィック属性であってもよく、興味・関心等のサイコグラフィック属性等であってもよい。

「ハッシュ」は、対応するキャンペーンに割り当てられた各リクエストのハッシュ値を示す。「ハッシュ」は、対応するキャンペーンに割り当てられたリクエストのハッシュ値の一覧を示す。

図６では、キャンペーンＢは、２０１０年８月１０日から１６日までを配信期間とするキャンペーンであることを示す。また、キャンペーンＢは、ｓｏｖが「０．１」であり、性別に関する条件として「女性」が指定され、年齢に関する条件は指定されていないことを示す。また、キャンペーンＢは、ハッシュ値が「１２３４５６」であるリクエスト等が割り当てられていることを示す。

なお、キャンペーン情報記憶部１２３は、上記に限らず、目的に応じて種々の情報を記憶してもよい。

（重複割合情報記憶部１２４）
実施形態に係る重複割合情報記憶部１２４は、重複割合に関する各種の情報を記憶する。図７は、実施形態に係る重複割合情報記憶部の一例を示す図である。図７では、重複割合情報記憶部１２４は、「重複割合ＩＤ」、「推定対象」、「重複割合」といった項目が含まれる。

「重複割合ＩＤ」は、重複割合を識別するための識別情報を示す。「推定対象」は、重複割合を推定する対象となったキャンペーンの組合せを示す。「重複割合」は、推定した重複割合の値を示す。

図７では、重複割合ＩＤ「ＰＤ１」により識別され重複割合は、キャンペーンＡとキャンペーンＢとの重複割合であることを示す。また、重複割合ＩＤ「ＰＤ１」により識別され重複割合は、値が「０．３３…」であることを示す。

なお、重複割合情報記憶部１２４は、上記に限らず、目的に応じて種々の情報を記憶してもよい。

（制御部１３０）
図３の説明に戻って、制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、情報処理装置１００内部の記憶装置に記憶されている各種プログラム（算出プログラム、予測プログラム等の各種の情報処理プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部１３０は、受付部１３１と、取得部１３２と、集計部１３３と、推定部１３４と、提供部１３５とを有し、以下に説明する情報処理の作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

（受付部１３１）
受付部１３１は、各種情報を受け付ける。受付部１３１は、外部の情報処理装置から各種要求を受け付ける。受付部１３１は、通信部１１０を介して、外部の情報処理装置から各種要求を示す情報を受信する。例えば、受付部１３１は、広告主端末３０から要求を受け付ける。また、受付部１３１は、ユーザ端末１０または配信サーバ２０から要求を受け付けてもよい。

受付部１３１は、推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける。受付部１３１は、第１キャンペーンの配信先の属性に関する条件を含む第１条件を受け付ける。受付部１３１は、配信先となるユーザの年齢（年代等）に関する条件を含む第１条件を受け付ける。受付部１３１は、配信先となるユーザの性別等に関する条件を含む第１条件を受け付ける。

（取得部１３２）
取得部１３２は、各種情報を取得する。取得部１３２は、通信部１１０を介して、外部の情報処理装置から各種情報を受信する。取得部１３２は、外部の情報処理装置から受信した情報を、記憶部１２０に格納する。取得部１３２は、ユーザ端末１０から各種情報を受信する。取得部１３２は、配信サーバ２０から各種情報を受信する。取得部１３２は、広告主端末３０から各種情報を受信する。

取得部１３２は、記憶部１２０から各種情報を取得する。取得部１３２は、配信ログ情報記憶部１２１や割当済ログ情報記憶部１２２やキャンペーン情報記憶部１２３や重複割合情報記憶部１２４から各種情報を取得する。

取得部１３２は、第１配信期間に第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報を取得する。取得部１３２は、第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、第１配信期間に重なる第２配信期間の条件を含む第２条件を取得する。

取得部１３２は、第２キャンペーンの配信先の属性に関する条件を含む第２条件を取得する。取得部１３２は、配信先となるユーザの年齢に関する条件を含む条件を含む第２条件を取得する。取得部１３２は、配信先となるユーザの性別に関する条件を含む条件を含む第２条件を取得する。

取得部１３２は、推定処理以前のコンテンツの配信ログから生成される予定在庫を示す情報を取得する。取得部１３２は、配信ログの日付を第１配信期間に含まれる日付に変更した未来ログである予定在庫を示す情報を取得する。取得部１３２は、集計処理後に追加された第２キャンペーンである未反映キャンペーンの第２条件である未反映条件を取得する。

（集計部１３３）
集計部１３３は、各種情報を集計する集計処理を実行する。集計部１３３は、記憶部１２０に記憶された情報を用いて、集計処理を実行する。集計部１３３は、受付部１３１により受け付けられた情報を用いて、集計処理を実行する。集計部１３３は、取得部１３２により取得された情報を用いて、集計処理を実行する。集計部１３３は、各種情報を抽出する抽出処理を実行する。集計部１３３は、記憶部１２０から情報を抽出する。集計部１３３は、各種情報を算出する算出処理を実行する。集計部１３３は、抽出した情報を用いて算出処理を実行する。

集計部１３３は、予定在庫のうち、第２条件に該当する在庫に第２キャンペーンを割り当てる集計処理を実行する。集計部１３３は、各種の情報を生成する。集計部１３３は、集計処理に用いる情報を生成する。集計部１３３は、生成した情報を用いて集計処理を実行する。

集計部１３３は、第１配信期間に第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報を生成する。集計部１３３は、推定処理以前のコンテンツの配信ログから予定在庫を示す情報を生成する。集計部１３３は、配信ログの日付を第１配信期間に含まれる日付に変更することにより、未来ログを、予定在庫を示す情報として生成する。集計部１３３は、配信ログの日付を第１配信期間に含まれる日付に変更した未来日付を、配信ログに対応付けて割当済ログ情報記憶部１２２に登録する。集計部１３３は、配信ログの日付を元日付とし、変更後の日付を未来日付として、配信ログに対応付けて割当済ログ情報記憶部１２２に登録する。

集計部１３３は、未来ログを対象として集計処理を実行する。集計部１３３は、第２キャンペーンの第２条件が該当するログに、その第２キャンペーンを割り当てることにより、集計処理を実行する。集計部１３３は、第２キャンペーンの第２条件が該当するログに、その第２キャンペーンを対応付けて割当済ログ情報記憶部１２２に登録する。

（推定部１３４）
推定部１３４は、種々の情報を推定する推定処理を実行する。推定部１３４は、外部の情報処理装置から受信された各種情報に基づいて、推定処理を実行する。推定部１３４は、ユーザ端末１０、配信サーバ２０、または広告主端末３０から受信された各種情報に基づいて、推定処理を実行する。

推定部１３４は、記憶部１２０に記憶された各種情報に基づいて、推定処理を実行する。例えば、推定部１３４は、集計部１３３により集計された情報に基づいて、推定処理を実行する。

推定部１３４は、第１条件と第２条件との重複に基づいて、予定在庫のうち、第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する。推定部１３４は、第２キャンペーンが割り当てられた在庫である割当済在庫の数を用いて、残在庫の数を推定する。推定部１３４は、予定在庫から割当済在庫を除外することにより、残在庫の数を推定する。推定部１３４は、予定在庫の数から割当済在庫の数を減算した値を用いて、残在庫の数を推定する。

推定部１３４は、第１条件と未反映条件との重複割合を推定し、推定した重複割合と予定在庫の数とを乗算した値を用いて、残在庫の数を推定する。推定部１３４は、予定在庫の数から重複割合と予定在庫の数とを乗算した値を減算した値を用いて、残在庫の数を推定する。推定部１３４は、重なり数推定に関する手法を用いて重複割合を推定する。推定部１３４は、予定在庫の各リクエストが所定のハッシュ法により変換されたハッシュ値を用いて、重複割合を推定する。

（提供部１３５）
提供部１３５は、各種情報を提供する。提供部１３５は、通信部１１０を介して、外部の情報処理装へ各種情報を送信する。提供部１３５は、ユーザ端末１０へ各種情報を送信する。提供部１３５は、配信サーバ２０へ各種情報を送信する。提供部１３５は、広告主端末３０へ各種情報を送信する。提供部１３５は、集計部１３３による集計処理の結果を提供する。提供部１３５は、推定部１３４による推定処理の結果を提供する。

提供部１３５は、残在庫の数を示す情報を提供する。提供部１３５は、残在庫の数を示す情報を広告主端末３０へ送信する。

〔４．処理フロー〕
次に、図８を用いて、実施形態に係る情報処理システム１による情報処理の手順について説明する。図８は、実施形態に係る情報処理の一例を示すフローチャートである。

図８に示すように、情報処理装置１００は、推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける（ステップＳ１０１）。また、情報処理装置１００は、第１配信期間に第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報を取得する（ステップＳ１０２）。

また、情報処理装置１００は、第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、第１配信期間に重なる第２配信期間の条件を含む第２条件を取得する（ステップＳ１０３）。そして、情報処理装置１００は、第１条件と第２条件との重複に基づいて、予定在庫のうち、第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する（ステップＳ１０４）。

〔５．予約状況即時反映処理〕
ここで、図１でのステップＳ６～ステップＳ８に対応する予約状況即時反映処理について、異なり数推定を用いた場合の処理例について、図９～図１１を用いて説明する。図９は、異なり数の推定に関する処理を示す概念図である。図１０は、重複割合の推定に関する一例を示す図である。図１１は、重複割合の推定に関する具体例を示す図である。

〔５－１．重なり数推定〕
まず、図９を用いて異なり数の推定に関する処理について説明する。例えば残在庫を求めるにあたり、シミュレーション・予約しようとしているキャンペーンと予約済みのキャンペーンの配信対象の被り具合を出す必要があるが、予約済みキャンペーンは複数存在するため、愚直に検索処理をすると処理負荷の増大を抑制することが難しい。そこで、情報処理装置１００は、異なり数推定の手法を用いて推定処理を実行する。

例えば、情報処理装置１００は、下記の文献に開示されている異なり数推定関する技術を用いて、重なり具合を推定する。
・On Synopses for Distinct-Value Estimation Under Multiset Operations, Kevin Beyer et al. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.230.7008&rep=rep1&type=pdf>

図９には異なり数の推定に関する処理を示す概念図を示し、１～Ｍまでの値（ハッシュ値）を示す。すなわち、Ｍはハッシュが取り得る値の範囲とするハッシュ関数により生成されるハッシュ値を示す。例えば、情報処理装置１００は、各在庫（リクエスト）のハッシュ（値）をリクエストＩＤ（ログＩＤ）から求める。例えば、情報処理装置１００は、各在庫（リクエスト）のログＩＤ等の情報をハッシュ関数に入力し、ハッシュ関数が出力したハッシュ値をその在庫（リクエスト）の値として用いる。例えば、ハッシュ関数は、出力が一様になるような関数であればどのようなハッシュ関数であってもよい。

例えば、ｘ＿１、ｘ＿２、…ｘ＿Ｎのうち、異なる値の数を求めたいとする。例えばｘ＿１、ｘ＿２、…ｘ＿Ｎ等は、各在庫（リクエスト）に対応する値であるものとする。この場合、情報処理装置１００は、ハッシュ関数ｈ（ｘ）を用いて、ｈ（ｘ＿１）、ｈ（ｘ＿２）、…ｈ（ｘ＿Ｎ）等のハッシュ値を求める。ハッシュの値域は１～Ｍとする。情報処理装置１００は、求めたｈ（ｘ＿ｉ）のうち、ｋ番目に小さい値を求め、その値Ｈとする。

この場合、情報処理装置１００は、異なる値の数を「（ｋ－１）＊Ｍ／Ｈ」であると推定する。情報処理装置１００は、ハッシュをリクエストＩＤ（ログＩＤ）から求めて、上述した手法を利用することで、配信対象の重なり具合を高速に計算することができる。

〔５－２．ハッシュの付与〕
情報処理システム１は、上記の手法を行うために、各配信ログに対して、リクエストＩＤを元に作成されたハッシュを付与し、検索エンジンＳＥ等に格納しておく。例えば、情報処理装置１００は、図５の割当済ログ情報記憶部１２２に示すように、各配信ログに対して、生成したハッシュ値を対応付けて記憶する。

〔５－３．予約内容の保存〕
情報処理システム１は、予約実行の際、ｓｏｖ及び予約重複率算出のためのハッシュの情報を予約データベースＲＤＢに保存する。例えば、情報処理装置１００は、図６のキャンペーン情報記憶部１２３に示すように、各キャンペーンに対して、ｓｏｖ及びハッシュの情報を対応付けて記憶する。なお、実際は一つのテーブルに保存されているわけではないが、図６では簡単のため一つの表として図示する。

例えば、ｓｏｖは、「予約ｖｉｍｐｓ／配信可能ｖｉｍｐｓ」により算出される。例えば、予約ｖｉｍｐｓは、キャンペーン作成時に指定される予約数（配信回数）を示す。例えば、配信可能ｖｉｍｐｓは、そのキャンペーンの総在庫の数を示し、そのキャンペーンのターゲット、配信期間等の条件に該当するリクエスト（配信ログ）の量を示す。例えば、ｓｏｖは、キャンペーンについての契約時の予約数を、契約時の総在庫の数で割った値である。

図５の割当済ログ情報記憶部１２２に示すように、各キャンペーンには、ハッシュ値が対応付けられる。なお、情報処理装置１００は、種々の情報を適宜用いて、各キャンペーンにハッシュ値を対応付ける。例えば、各キャンペーンに対応付けられるハッシュは、図５の割当済ログ情報記憶部１２２中の割当済ログで、割当が「なし」である配信ログ（未割当リクエスト）のうち、そのキャンペーンの条件に該当するリクエスト（対象リクエスト）のハッシュ値であってもよい。例えば、情報処理装置１００は、キャンペーンについて未割当リクエストから対象リクエストを抽出し、ハッシュ値が小さい方からそのキャンペーンの予約数分のハッシュ値をそのキャンペーンに対応付けてもよい。なお、情報処理装置１００は、キャンペーンＡについても同様にハッシュ値を対応付けてもよい。

〔５－４．重複割合の計算〕
情報処理システム１は、シミュレーション・予約対象のキャンペーンと予約済みのキャンペーンの配信対象がどれだけ重なっているかを、以下の式（１）により算出することができる。

重複割合＝ｓｏｖ×ハッシュにより推定される重複割合 … （１）

上述したように、式（１）中の「ｓｏｖ」は予約済みキャンペーンが、配信対象全体に対してどれだけ予約しているかの比率（全て予約していれば１となる）である。また、情報処理システム１は、式（１）中の「ハッシュにより推定される重複割合」を、次の手順＃１～手順＃３のように異なり数推定の手法を用いて計算する。

（手順＃１）
情報処理システム１は、シミュレーション対象のキャンペーンＡの配信対象ｖｉｍｐ（Ａ）のうち、最小ｋ個（例えばｋ＝４０００とする）のハッシュ値を検索エンジンＳＥから取得する。例えば、情報処理装置１００は、割当済ログ情報記憶部１２２からキャンペーンＡの条件に該当するｋ個のハッシュ値を取得する。

（手順＃２）
情報処理システム１は、予約済みのキャンペーンＢの配信対象ｖｉｍｐ（Ｂ）のうちの最小ｋ個のハッシュ値も予約データベースＲＤＢから取得する。例えば、情報処理装置１００は、キャンペーン情報記憶部１２３からキャンペーンＢに対応付けられたｋ個のハッシュ値を取得する。

（手順＃３）
情報処理システム１は、手順＃１及び手順＃１で取得した情報を用いて、キャンペーンＡとキャンペーンＢとの重複割合を計算する。例えば、情報処理装置１００は、関数Ｎ（...）で上述の異なり数推定を行うとすると、図１０のように計算できる。情報処理装置１００は、図１０に示す式を用いることにより、シミュレーション対象のキャンペーンＡと予約済みのキャンペーンＢの配信対象がどれだけ重なっているかを推定することができる。

図１０中のＮ（Ａ）は、キャンペーンＡに対応するビューアブルインプレッション（リクエスト）の数を示す。また、図１０中のＮ（Ｂ）は、キャンペーンＢに対応するビューアブルインプレッション（リクエスト）の数を示す。また、図１０中のＮ（Ａ∪Ｂ）は、キャンペーンＡまたはキャンペーンＢのいずれかが配信対象となるビューアブルインプレッション（リクエスト）の数を示す。また、図１０中のＮ（Ａ∩Ｂ）は、キャンペーンＡ及びキャンペーンＢの両方が配信対象となるビューアブルインプレッション（リクエスト）の数を示す。

（手順＃４）
なお、情報処理システム１は、キャンペーンの予約時に最小ｋ個のハッシュ値を予約データベースＲＤＢに保存しておく。例えば、情報処理装置１００は、割当済ログ情報記憶部１２２から取得したキャンペーンＡの条件に該当するｋ個のハッシュ値を、キャンペーンＡに対応付けてキャンペーン情報記憶部１２３に登録する。

〔５－５．重複割合の具体例〕
次に、図１１を用いて、重複割合の推定の具体例について説明する。なお、図１１では説明の容易化のために数値を簡単にしており、例えばハッシュの値域を１～１０００００００としている。なお、実際にはハッシュを用いるため、図１１に示すような綺麗な数字が並ぶことはまずないものとなる。

図１１中のＮ（Ａ）は、キャンペーンＡのビューアブルインプレッション（リクエスト）の数が「９９９７５」であることを示す。また、図１１中のＮ（Ｂ）は、キャンペーンＢのビューアブルインプレッション（リクエスト）の数が「６６６５０」であることを示す。また、図１１中のＮ（Ａ∪Ｂ）は、キャンペーンＡまたはキャンペーンＢのいずれかが配信対象となるビューアブルインプレッション（リクエスト）の数が「１３３３００」であることを示す。

また、図１１中のＮ（Ａ∩Ｂ）は、キャンペーンＡ及びキャンペーンＢの両方が配信対象となるビューアブルインプレッション（リクエスト）の数が「３３３２５」であることを示す。ハッシュにより推定される重複割合は、キャンペーンＡとキャンペーンＢとの重複割合が「０．３３３３３３」であることを示す。

すなわち、図１１では、Ｍを１千万とし、ｋを「４０００」とした例を示し、情報処理装置１００が第１キャンペーンであるキャンペーンＡと、第２キャンペーン（未反映キャンペーン）であるキャンペーンＢとの重複割合が「０．３３３３３３」と推定した場合を示す。このように、図１１の例は、推定対象の第１キャンペーンであるキャンペーンＡの３３％（１／３）が、既に予約済みのキャンペーンＢの配信対象になっていることを示す。

そのため、情報処理装置１００は、重複割合に、ｓｏｖを乗算することにより、どれだけ予約済みキャンペーンに割合済みの在庫にするべきかを推定することができる。図１１では、情報処理装置１００は、キャンペーンＡとキャンペーンＢとの重複割合「０．３３３３…」、キャンペーンＢのｓｏｖ「０．１」を乗算することにより、キャンペーンＡに対する総在庫のうち、キャンペーンＢに割合済みの在庫にするべき数（除外在庫数）を推定することができる。

情報処理装置１００は、上述した処理により、第１キャンペーンの残在庫量を推定することができる。例えば、情報処理装置１００は、検索エンジンＳＥ内の情報から総在庫及び仮残在庫を算出する。そして、情報処理装置１００は、予約データベースＲＤＢから検索エンジンＳＥに未反映の予約済みキャンペーンを抽出し、抽出した予約済みキャンペーン全てについて重複割合を計算する。そして、情報処理装置１００は、「残在庫＝仮残在庫－在庫×(算出した重複割合の総和)」により第１キャンペーンに対する在庫数を推定することができる。

なお、上記のキャンペーンのような予約型広告の在庫管理では、総在庫（最大でどれだけ配信できるか）と残在庫（どれだけの配信量を予約させられるか）を求める必要がある。例えば、従来の広告配信での在庫管理では、予め決められた地域（エリア）のセットでの指定や１つのカテゴリ（オーディエンスカテゴリ）のみ指定可能である等の制約があり、配信対象のセグメントごとに全体に対する割合を求め、全体の予測量に対し掛け合わせることで総在庫量を求めていた。

しかしながら、このような従来の広告配信の方法では、任意のエリア及び任意のカテゴリを複数指定可能である場合、異なるエリア同士や異なるオーディエンスカテゴリ同士は重複し、各エリア及びカテゴリずつ割合を求めてそれを足し合わせるのでは正しい結果は得ることが難しい。例えば、任意のエリア及び任意のカテゴリを複数指定可能である場合、エリアとカテゴリとの組み合わせの数は非常に大きく、エリアが数千、カテゴリが数百カテゴリある場案等では、全てを事前計算しておくのは困難である。

一方で、情報処理装置１００は、上述した処理により、集計処理後に追加された第２キャンペーンについては未反映キャンペーンとして、第１キャンペーンとの重複割合を求め、その重複割合を基に第１キャンペーンへ割合可能な残在庫を推定する。これにより、情報処理装置１００は、コンテンツの配信に関する情報を適切に推定することができる。

なお、上記は一例に過ぎず、情報処理システム１は、様々な情報を適宜用いて第１キャンペーンに対する残在庫を推定してもよい。情報処理システム１は、シミュレーション対象と各予約済みキャンペーンのかぶり具合を推定する、そして、情報処理システム１は、仮想在庫から総在庫に各被り具合を積算した値を減算した値を、推定在庫とする。

〔６．効果〕
上述してきたように、実施形態に係る情報処理装置１００は、受付部１３１と、取得部１３２と、推定部１３４とを備える。受付部１３１は、推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける。取得部１３２は、第１配信期間に第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報と、第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、第１配信期間に重なる第２配信期間の条件を含む第２条件とを取得する。推定部１３４は、第１条件と第２条件との重複に基づいて、予定在庫のうち、第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する。

このように、実施形態に係る情報処理装置１００は、配信期間を含む条件が重なるキャンペーン間の条件の重複に基づいて、キャンペーンに対して割当可能な残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、受付部１３１は、第１キャンペーンの配信先の属性に関する条件を含む第１条件を受け付ける。

このように、実施形態に係る情報処理装置１００は、配信先の属性に関する条件を含め、キャンペーン間の条件の重複に基づいて、キャンペーンに対して割当可能な残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、受付部１３１は、配信先となるユーザの年齢に関する条件を含む第１条件を受け付ける。

このように、実施形態に係る情報処理装置１００は、配信先となるユーザの年齢に関する条件を含め、キャンペーン間の条件の重複に基づいて、キャンペーンに対して割当可能な残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、受付部１３１は、配信先となるユーザの性別に関する条件を含む第１条件を受け付ける。

このように、実施形態に係る情報処理装置１００は、配信先となるユーザの性別に関する条件を含め、キャンペーン間の条件の重複に基づいて、キャンペーンに対して割当可能な残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、取得部１３２は、第２キャンペーンの配信先の属性に関する条件を含む第２条件を取得する。

また、実施形態に係る情報処理装置１００において、取得部１３２は、配信先となるユーザの年齢に関する条件を含む条件を含む第２条件を取得する。

また、実施形態に係る情報処理装置１００において、取得部１３２は、配信先となるユーザの性別に関する条件を含む条件を含む第２条件を取得する。

また、実施形態に係る情報処理装置１００において、取得部１３２は、推定処理以前のコンテンツの配信ログから生成される予定在庫を示す情報を取得する。

このように、実施形態に係る情報処理装置１００は、推定処理以前のコンテンツの配信ログから生成される予定在庫を用いて、キャンペーンに対して割当可能な残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、取得部１３２は、配信ログの日付を第１配信期間に含まれる日付に変更した未来ログである予定在庫を示す情報を取得する。

このように、実施形態に係る情報処理装置１００は、配信ログの日付を第１配信期間に含まれる日付に変更した未来ログを用いて、キャンペーンに対して割当可能な残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００は、集計部１３３を有する。集計部１３３は、予定在庫のうち、第２条件に該当する在庫に第２キャンペーンを割り当てる集計処理を実行する。推定部１３４は、第２キャンペーンが割り当てられた在庫である割当済在庫の数を用いて、残在庫の数を推定する。

このように、実施形態に係る情報処理装置１００は、予定在庫のうち、第２条件に該当する在庫に第２キャンペーンを割り当てる集計処理を実行し、第２キャンペーンが割り当てられた在庫である割当済在庫の数を用いて、残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、推定部１３４は、予定在庫から割当済在庫を除外することにより、残在庫の数を推定する。

このように、実施形態に係る情報処理装置１００は、予定在庫から割当済在庫を除外することにより、残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、推定部１３４は、予定在庫の数から割当済在庫の数を減算した値を用いて、残在庫の数を推定する。

このように、実施形態に係る情報処理装置１００は、予定在庫の数から割当済在庫の数を減算した値を用いて、残在庫の数を推定することにより、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、取得部１３２は、集計処理後に追加された第２キャンペーンである未反映キャンペーンの第２条件である未反映条件を取得する。

このように、実施形態に係る情報処理装置１００は、集計処理後に追加された未反映キャンペーンがある場合であっても、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、推定部１３４は、第１条件と未反映条件との重複割合を推定し、推定した重複割合と予定在庫の数とを乗算した値を用いて、残在庫の数を推定する。

このように、実施形態に係る情報処理装置１００は、第１条件との重複割合を推定し、重複割合と予定在庫の数とを乗算した値を用いて残在庫の数を推定することにより、集計処理後に追加された未反映キャンペーンがある場合であっても、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、推定部１３４は、予定在庫の数から重複割合と予定在庫の数とを乗算した値を減算した値を用いて、残在庫の数を推定する。

このように、実施形態に係る情報処理装置１００は、予定在庫の数から重複割合と予定在庫の数とを乗算した値を減算した値を用いて、残在庫の数を推定することにより、集計処理後に追加された未反映キャンペーンがある場合であっても、コンテンツの配信に関する情報を適切に推定することができる。

また、実施形態に係る情報処理装置１００において、推定部１３４は、重なり数推定に関する手法を用いて重複割合を推定する。

このように、実施形態に係る情報処理装置１００は、重なり数推定に関する手法を用いて重複割合を推定することにより、適切に重複割合を推定することができる。

また、実施形態に係る情報処理装置１００において、推定部１３４は、予定在庫の各リクエストが所定のハッシュ法により変換されたハッシュ値を用いて、重複割合を推定する。

このように、実施形態に係る情報処理装置１００は、予定在庫の各リクエストが所定のハッシュ法により変換されたハッシュ値を用いて、重複割合を推定することにより、適切に重複割合を推定することができる。

また、実施形態に係る情報処理装置１００は、提供部１３５を有する。提供部１３５は、残在庫の数を示す情報を提供する。

このように、実施形態に係る情報処理装置１００は、残在庫の数を示す情報を提供することにより、コンテンツの配信に関して推定した情報を提供することができる。

〔７．ハードウェア構成〕
また、上述してきた実施形態に係る情報処理装置１００等の情報処理装置は、例えば図１２に示すような構成のコンピュータ１０００によって実現される。図１２は、情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００またはＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、所定の通信網を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを所定の通信網を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラムまたはデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る情報処理装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムまたはデータ（例えばモデル等）を実行することにより、制御部１３０の機能を実現する。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムまたはデータを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムまたはデータを取得してもよい。

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

〔８．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上述してきた実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、受付部は、受付手段や受付回路に読み替えることができる。

１情報処理システム
１０ユーザ端末
２０配信サーバ
３０広告主端末
１００情報処理装置
１２１配信ログ情報記憶部
１２２割当済ログ情報記憶部
１２３キャンペーン情報記憶部
１２４重複割合情報記憶部
１３１受付部
１３２取得部
１３３集計部
１３４推定部
１３５提供部

Claims

推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける受付部と、
前記第１配信期間に前記第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報と、前記第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、前記第１配信期間に重なる第２配信期間の条件を含む第２条件とを取得する取得部と、
前記第１条件と前記第２条件との重複に基づいて、前記予定在庫のうち、前記第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する推定部と、
前記予定在庫のうち、前記第２条件に該当する在庫に前記第２キャンペーンを割り当てる集計処理を実行する集計部と、
を備え、
前記取得部は、
前記集計処理後に追加された前記第２キャンペーンである未反映キャンペーンの前記第２条件である未反映条件を取得し、
前記推定部は、
前記第１条件と前記未反映条件との重複割合を推定し、推定した前記重複割合と前記予定在庫の数とを乗算した値を用いて、前記残在庫の数を推定する
ことを特徴とする情報処理装置。
前記受付部は、
前記第１キャンペーンの配信先の属性に関する条件を含む前記第１条件を受け付ける
ことを特徴とする請求項１に記載の情報処理装置。
前記受付部は、
前記配信先となるユーザの年齢に関する条件を含む前記第１条件を受け付ける
ことを特徴とする請求項２に記載の情報処理装置。
前記受付部は、
前記配信先となるユーザの性別に関する条件を含む前記第１条件を受け付ける
ことを特徴とする請求項２または請求項３に記載の情報処理装置。
前記取得部は、
前記第２キャンペーンの配信先の属性に関する条件を含む前記第２条件を取得する
ことを特徴とする請求項１～４のいずれか１項に記載の情報処理装置。
前記取得部は、
前記配信先となるユーザの年齢に関する条件を含む条件を含む前記第２条件を取得する
ことを特徴とする請求項５に記載の情報処理装置。
前記取得部は、
前記配信先となるユーザの性別に関する条件を含む条件を含む前記第２条件を取得する
ことを特徴とする請求項５または請求項６に記載の情報処理装置。
前記取得部は、
前記推定処理以前のコンテンツの配信ログから生成される前記予定在庫を示す情報を取得する
ことを特徴とする請求項１～７のいずれか１項に記載の情報処理装置。
前記取得部は、
前記配信ログの日付を前記第１配信期間に含まれる日付に変更した未来ログである前記予定在庫を示す情報を取得する
ことを特徴とする請求項８に記載の情報処理装置。
前記推定部は、前記第２キャンペーンが割り当てられた在庫である割当済在庫の数を用いて、前記残在庫の数を推定する
ことを特徴とする請求項１～９のいずれか１項に記載の情報処理装置。
前記推定部は、
前記予定在庫から前記割当済在庫を除外することにより、前記残在庫の数を推定する
ことを特徴とする請求項１０に記載の情報処理装置。
前記推定部は、
前記予定在庫の数から前記割当済在庫の数を減算した値を用いて、前記残在庫の数を推定する
ことを特徴とする請求項１０または請求項１１に記載の情報処理装置。
前記推定部は、
前記予定在庫の数から前記重複割合と前記予定在庫の数とを乗算した値を減算した値を用いて、前記残在庫の数を推定する
ことを特徴とする請求項１～１２のいずれか１項に記載の情報処理装置。
前記推定部は、
重なり数推定に関する手法を用いて前記重複割合を推定する
ことを特徴とする請求項１～１３のいずれか１項に記載の情報処理装置。
前記推定部は、
前記予定在庫の各リクエストが所定のハッシュ法により変換されたハッシュ値を用いて、前記重複割合を推定する
ことを特徴とする請求項１～１４のいずれか１項に記載の情報処理装置。
前記残在庫の数を示す情報を提供する提供部、
をさらに備えることを特徴とする請求項１～１５のいずれか１項に記載の情報処理装置。
コンピュータが実行する情報処理方法であって、
推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける受付工程と、
前記第１配信期間に前記第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報と、前記第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、前記第１配信期間に重なる第２配信期間の条件を含む第２条件とを取得する取得工程と、
前記第１条件と前記第２条件との重複に基づいて、前記予定在庫のうち、前記第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する推定工程と、
前記予定在庫のうち、前記第２条件に該当する在庫に前記第２キャンペーンを割り当てる集計処理を実行する集計工程と、
を含み、
前記取得工程は、
前記集計処理後に追加された前記第２キャンペーンである未反映キャンペーンの前記第２条件である未反映条件を取得し、
前記推定工程は、
前記第１条件と前記未反映条件との重複割合を推定し、推定した前記重複割合と前記予定在庫の数とを乗算した値を用いて、前記残在庫の数を推定する
ことを特徴とする情報処理方法。
推定対象となるキャンペーンである第１キャンペーンに対して指定された第１配信期間の条件を含む第１条件を受け付ける受付手順と、
前記第１配信期間に前記第１キャンペーンのコンテンツの配信先になり得るリクエストを示す予定在庫を示す情報と、前記第１キャンペーンとは異なる第２キャンペーンに対して指定された第２配信期間あって、前記第１配信期間に重なる第２配信期間の条件を含む第２条件とを取得する取得手順と、
前記第１条件と前記第２条件との重複に基づいて、前記予定在庫のうち、前記第１キャンペーンに対して割当可能な在庫である残在庫の数を推定する推定処理を実行する推定手順と、
前記予定在庫のうち、前記第２条件に該当する在庫に前記第２キャンペーンを割り当てる集計処理を実行する集計手順と、
をコンピュータに実行させ、
前記取得手順は、
前記集計処理後に追加された前記第２キャンペーンである未反映キャンペーンの前記第２条件である未反映条件を取得し、
前記推定手順は、
前記第１条件と前記未反映条件との重複割合を推定し、推定した前記重複割合と前記予定在庫の数とを乗算した値を用いて、前記残在庫の数を推定する
ことを特徴とする情報処理プログラム。