特許 6011899 広告制御装置及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6011899

(24)【登録日】2016年9月30日

(45)【発行日】2016年10月25日

(54)【発明の名称】広告制御装置及びプログラム

(51)【国際特許分類】

   G06Q 30/02 20120101AFI20161011BHJP

【ＦＩ】

   G06Q30/02 332

   G06Q30/02 446

【請求項の数】8

【全頁数】26

(21)【出願番号】特願2016-80378(P2016-80378)

(22)【出願日】2016年4月13日

【審査請求日】2016年5月23日

【早期審査対象出願】

(73)【特許権者】

【識別番号】000132471

【氏名又は名称】株式会社セガゲームス

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100080953

【弁理士】

【氏名又は名称】田中 克郎

(72)【発明者】

【氏名】金子 崇久

(72)【発明者】

【氏名】吉田 繁治

(72)【発明者】

【氏名】久下 臣

(72)【発明者】

【氏名】片桐 誠自

(72)【発明者】

【氏名】山口 乃絵

(72)【発明者】

【氏名】松木 大輔

【審査官】 田付 徳雄

(56)【参考文献】

【文献】 特開２０１３−１９６０４４（ＪＰ，Ａ）

【文献】 特開２０１１−０６５２０１（ＪＰ，Ａ）

【文献】 国際公開第２０１６／００２３４２（ＷＯ，Ａ１）

【文献】 特許第５５０６０７２（ＪＰ，Ｂ２）

【文献】 米国特許出願公開第２０１２／０２７８１８５（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

複数の電子商品が提供される端末装置と通信可能な広告制御装置であって、
前記複数の電子商品毎の可変パラメータ、前記複数の電子商品毎の前記可変パラメータに関する閾値及び前記複数の電子商品毎の広告情報を記憶する記憶手段と、
各可変パラメータに基づいて各広告情報の中から何れか１つの第１電子商品の広告情報を選択する選択手段と、
前記選択された広告情報を前記複数の電子商品のうち前記第１電子商品を除く何れか１つの第２電子商品に関連付けて前記端末装置へ送信する送信手段と、
前記第２電子商品に関する動作を実行した前記端末装置において前記広告情報が利用されたことを示す利用情報を受信する受信手段と、
前記受信手段で前記利用情報が受信された場合に、前記端末装置のユーザを前記第２電子商品が前記第１電子商品に送客したと判定し、前記第２電子商品の可変パラメータ及び前記第１電子商品の可変パラメータを更新するパラメータ更新手段と、
前記複数の電子商品のうち何れか１つの電子商品の可変パラメータが、対応する閾値に関する条件を満たす場合に、前記条件を満たす電子商品の広告情報を前記選択手段により選択される広告情報から除外することで前記条件を満たす電子商品の広告を停止する広告停止手段と、
所定期間ごとに前記第２電子商品が送客した規模を示す送客規模を算出し、前記送客規模に応じて前記第２電子商品の閾値を変更する閾値変更手段と、
を備え、
前記記憶手段は、前記複数の電子商品のうち１又は複数の電子商品から構成されるグループのグループ情報を更に記憶し、
前記パラメータ更新手段は、前記複数の電子商品のうち何れか１つの電子商品の提供が終了した場合に、前記提供が終了した電子商品のグループを特定し、前記提供が終了した電子商品の可変パラメータに基づき前記特定したグループ内の１又は複数の電子商品の可変パラメータを更新する、
広告制御装置。

【請求項2】

前記パラメータ更新手段は、前記複数の電子商品のうち何れか１つの電子商品が所定の条件を満たす場合に、前記所定の条件を満たす電子商品のグループを特定し、前記特定したグループ内の１又は複数の電子商品の可変パラメータに基づき、前記閾値の絶対値未満である可変パラメータの基準値に近づくように前記所定の条件を満たす電子商品の可変パラメータを更新する、
請求項１に記載の広告制御装置。

【請求項3】

前記記憶手段は、前記複数の電子商品のうち２以上の電子商品に紐づけられた共通パラメータを更に記憶し、
前記パラメータ更新手段は、前記受信手段で前記利用情報が受信された場合に、前記共通パラメータを更新し、且つ、前記複数の電子商品のうち何れか１つの電子商品が所定の条件を満たす場合に、前記共通パラメータに基づき、前記閾値の絶対値未満である可変パラメータの基準値に近づくように前記所定の条件を満たす電子商品の可変パラメータを更新する、
請求項１に記載の広告制御装置。

【請求項4】

前記所定の条件は、前記複数の電子商品のうち何れか１つの電子商品の広告が停止されている期間が所定期間を超えているという条件を含む、
請求項２又は３に記載の広告制御装置。

【請求項5】

前記所定の条件は、前記複数の電子商品のうち何れか１つの電子商品の広告が停止されている期間が所定期間を超えており、且つ、前記特定したグループ内の１又は複数の電子商品の広告が停止されていないという条件を含む、
請求項２に記載の広告制御装置。

【請求項6】

前記所定の条件は、前記複数の電子商品のうち何れか１つの電子商品の提供が終了したという条件を含む、
請求項２乃至５の何れか１項に記載の広告制御装置。

【請求項7】

前記広告停止手段は、更に、前記複数の電子商品のうち何れか１つの電子商品の提供が終了する予定日時の所定期間前から実際に提供が終了する間、前記終了する予定の電子商品の広告情報を前記選択手段により選択される広告情報から除外することで前記終了する予定の電子商品の広告を停止する、
請求項１乃至６の何れか１項に記載の広告制御装置。

【請求項8】

複数の電子商品が提供される端末装置と通信可能なコンピュータを、
前記複数の電子商品毎の可変パラメータ、前記複数の電子商品毎の前記可変パラメータに関する閾値及び前記複数の電子商品毎の広告情報を記憶する記憶手段、
各可変パラメータに基づいて各広告情報の中から何れか１つの第１電子商品の広告情報を選択する選択手段、
前記選択された広告情報を前記複数の電子商品のうち前記第１電子商品を除く何れか１つの第２電子商品に関連付けて前記端末装置へ送信する送信手段、
前記第２電子商品に関する動作を実行した前記端末装置において前記広告情報が利用されたことを示す利用情報を受信する受信手段、
前記受信手段で前記利用情報が受信された場合に、前記端末装置のユーザを前記第２電子商品が前記第１電子商品に送客したと判定し、前記第２電子商品の可変パラメータ及び前記第１電子商品の可変パラメータを更新するパラメータ更新手段、
前記複数の電子商品のうち何れか１つの電子商品の可変パラメータが、対応する閾値に関する条件を満たす場合に、前記条件を満たす電子商品の広告情報を前記選択手段により選択される広告情報から除外することで前記条件を満たす電子商品の広告を停止する広告停止手段、及び、
所定期間ごとに前記第２電子商品が送客した規模を示す送客規模を算出し、前記送客規模に応じて前記第２電子商品の閾値を変更する閾値変更手段、
として機能させ、
前記記憶手段において、前記複数の電子商品のうち１又は複数の電子商品から構成されるグループのグループ情報を更に記憶し、
前記パラメータ更新手段において、前記複数の電子商品のうち何れか１つの電子商品の提供が終了した場合に、前記提供が終了した電子商品のグループを特定し、前記提供が終了した電子商品の可変パラメータに基づき前記特定したグループ内の１又は複数の電子商品の可変パラメータを更新する、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、広告制御装置及びプログラムに関する。

【背景技術】

【0002】

従来から、複数の電子商品（例えばアプリケーション）のうち何れか１つの電子商品に関する動作が端末装置において実行された場合に、他の電子商品に関する広告情報を広告制御装置から端末装置に送信するサービスが知られている。このようなサービスでは、広告情報を通じて端末装置のユーザを或る電子商品（第２電子商品）から他の電子商品（第１電子商品）に誘導することを可能としている。なお、この誘導は、第２電子商品側では１人のユーザを送客したと捉えることができ、第１電子商品側では１人のユーザを集客したと捉えることができる。

【0003】

これに関し、特許文献１には、各電子商品にポイントを対応付けて管理し、上記誘導した場合に、第２電子商品がポイントを獲得する一方で第１電子商品がポイントを消費する技術が開示されている。この技術では、何れかの電子商品のポイントが閾値に達して予め定められた数の集客（集客規模）を示す場合に、それ以上の集客（過集客）を抑えるために当該何れかの電子商品の広告を停止している。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特許第５４４５６０６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、上記の技術において電子商品間のユーザの循環（回遊）を促進するためには、電子商品の送客規模と集客規模のバランスを取ることが望まれる。しかしながら、上記の技術では、例えば人気の低い電子商品は、自身の送客能力が低くなり易く、自身の送客能力を超えた数のユーザを集客する場合がある。この場合、人気の低い電子商品のポイントが閾値に達して当該電子商品の広告が停止され、その後において当該電子商品が送客のみをしても、その送客規模が広告停止前までの集客規模に追いつくのに時間を要するか、或いは追いつくことが困難であるので、送客規模と集客規模のバランスを取ることができない。

【0006】

本発明はこのような課題に鑑みてなされたものであり、その目的は、電子商品の送客規模と集客規模のバランスを取ることができる広告制御装置及びプログラムを提供することにある。

【課題を解決するための手段】

【0007】

上記課題を解決するために、本発明に係る広告制御装置は、
複数の電子商品が提供される端末装置と通信可能な広告制御装置であって、
前記複数の電子商品毎の可変パラメータ、前記複数の電子商品毎の前記可変パラメータに関する閾値及び前記複数の電子商品毎の広告情報を記憶する記憶手段と、
各可変パラメータに基づいて各広告情報の中から何れか１つの第１電子商品の広告情報を選択する選択手段と、
前記選択された広告情報を前記複数の電子商品のうち前記第１電子商品を除く何れか１つの第２電子商品に関連付けて前記端末装置へ送信する送信手段と、
前記第２電子商品に関する動作を実行した前記端末装置において前記広告情報が利用されたことを示す利用情報を受信する受信手段と、
前記受信手段で前記利用情報が受信された場合に、前記端末装置のユーザを前記第２電子商品が前記第１電子商品に送客したと判定し、前記第２電子商品の可変パラメータ及び前記第１電子商品の可変パラメータを更新するパラメータ更新手段と、
前記複数の電子商品のうち何れか１つの電子商品の可変パラメータが、対応する閾値に関する条件を満たす場合に、前記条件を満たす電子商品の広告情報を前記選択手段により選択される広告情報から除外することで前記条件を満たす電子商品の広告を停止する広告停止手段と、
所定期間において前記第２電子商品が送客した規模を示す送客規模を算出し、前記送客規模に応じて前記第２電子商品の閾値を変更する閾値変更手段と、
を備える。

【0008】

この構成によれば、閾値変更手段が、第２電子商品の所定期間の送客規模に応じて当該第２電子商品自身の閾値を変更するので、自身の送客規模（言い換えれば送客能力）を超えた集客規模のユーザを集客する前に、広告停止手段が、その広告を停止してユーザの集客を止めることができる。すなわち、電子商品が自身の送客能力を超えた規模のユーザを集客することを抑制できる。このように送客能力を超えた規模のユーザを集客することを抑制できれば、その後において集客が止められた電子商品が自身の送客能力の範囲で送客をすることで、集客を止める前までの集客規模に送客規模を追いつかせることができ、電子商品の送客規模と集客規模のバランスを取ることができる。

【発明の効果】

【0009】

本発明によれば、電子商品の送客規模と集客規模のバランスを取ることができる。

【図面の簡単な説明】

【0010】

【図1】本発明の実施形態に係る広告制御装置（広告制御サーバ）が組み込まれた広告提供システムの構成例を示す図である。

【図2】本発明の実施形態において電子商品の一例である４つのアプリケーション間で送客／集客が行なわれる様子を例示する図である。

【図3】本発明の実施形態においてアプリケーション毎の送集客ポイントを例示する図である。

【図4】図１に例示する広告制御サーバのハードウェア的構成例を示すブロック図である。

【図5】図４に例示する広告制御サーバの機能的な構成例を示すブロック図である。

【図6】本発明の実施形態に係るシステム全体フローを説明するフローチャートである。

【図7】図６に例示するバナー処理の一例を説明する図である。

【図8】図７から続くバナー処理を説明する図である。

【図9】図７に例示する送集客バランス処理の一例を示すフローチャートである。

【図10】図５に例示する第２更新部による第２更新処理の一例を示すフローチャートである。

【図11】図５に例示する閾値変更部による閾値変更処理について説明する。

【図12】図５に例示する第４更新部の第４更新処理について説明する。

【発明を実施するための形態】

【0011】

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形（各実施例を組み合わせる等）して実施することができる。また、以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付して表している。図面は模式的なものであり、必ずしも実際の寸法や比率・数量等とは一致するものではなく、また、個々の構成等は同等の機能を持つ別の構成に置き換えが可能である。図面相互間においても互いの寸法の関係や比率等が異なる部分が含まれていることがある。

【0012】

〔１〕システム構成例
本発明の実施形態に係る広告制御装置は、以下に説明する広告提供システムに組み込まれている。まず、この広告提供システムの構成例について以下に説明する。

【0013】

図１は、実施形態に係る広告制御装置が組み込まれた広告提供システムの構成例を示す図である。図１に示す広告提供システム１は、複数の電子的な商品情報（以下「電子商品」ともいう。）および電子商品に関する広告情報（バナー広告等）を端末装置２０に対して通信ネットワーク１０を介して提供するシステムである。

【0014】

上記「電子商品」とは、アプリケーションプログラム等のコンピュータソフト、動画・静止画コンテンツといったデジタルプロダクトなどの電子情報で構成されたものをいう。本実施形態では、複数の電子商品それぞれがゲームアプリケーションプログラム（以下、単に「アプリ」という。）である場合を説明する。

【0015】

広告提供システム１は、例示的に、通信ネットワーク１０と、１又は複数の端末装置（以下、単に「端末」という）２０と、１又は複数の商品サーバ３０と、決済サーバ４０と、広告制御サーバ５０と、を備える。

【0016】

端末２０は、ＰＣ（Personal Computer）やＰＤＡ（Personal Digital Assistant）、携帯電話、スマートフォン、タブレット型コンピュータ等のインテリジェントデバイスである。端末２０は、必要に応じて通信ネットワーク１０を経由して、商品サーバ３０や決済サーバ４０、広告制御サーバ５０と通信することができる。

【0017】

通信ネットワーク１０は、無線ネットワークでも有線ネットワークでもよい。通信ネットワーク１０の一例としては、インターネットや無線ＬＡＮ、赤外線通信、３Ｇ、ＷｉＭａｘ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ｃ．Ｌｉｎｋ（登録商標）、ＨＤＭＩ（登録商標）、有線ＬＡＮ、電話線、携帯電話網、ＰＨＳ網、電灯線ネットワーク、ＩＥＥＥ１３９４等に準拠したネットワークが挙げられる。

【0018】

商品サーバ３０は、電子商品としてのアプリを格納、管理するサーバコンピュータである。商品サーバ３０は、端末２０からの通信ネットワーク１０を経由した要求等に応じてアプリを当該端末２０に提供（送信）することができる。

【0019】

決済サーバ４０は、アプリの購入や課金行為に伴う決済処理を行なうサーバコンピュータである。決済サーバ４０は、端末２０からの通信ネットワーク１０を経由した、アプリの購入要求等に応じてアプリの決済処理を実施することができる。

【0020】

別言すると、端末２０は、通信ネットワーク１０経由で商品サーバ３０にアクセスして、当該サーバ３０からアプリを受信、インストール等することができる。なお、アプリは、商品サーバ３０において複数分、格納、管理されていてもよい。また、アプリは有償でも無償でもよい。有償の場合、端末２０は、例えば決済サーバ４０と通信して電子商品の決済処理を実施することができる。

【0021】

広告制御サーバ５０は、本実施形態に係る広告制御装置の一例であり、商品サーバ３０によって端末２０に提供されるアプリに関する広告情報の配信等を管理、制御するサーバコンピュータである。

【0022】

本実施形態に係る広告制御サーバ５０は、管理している広告情報のうち何れか１つの広告情報を或るアプリに関連付けて端末２０へ送信する。なお、「関連付け」とは、当該或るアプリに関する動作が端末２０において実行された場合（開始時や実行中の場合を含む）、広告情報が端末２０において出力（表示）されるように、広告情報と或るアプリとの関係を結びつけることを言う。

【0023】

また、広告制御サーバ５０は、関連付けられた或るアプリに関する動作を実行した端末装置において送信された広告情報が利用されたことを示す利用情報（広告情報の利用情報）を受信する。これにより、広告制御サーバ５０は、広告情報を通じてユーザを或るアプリから他のアプリに誘導した事実を把握することができる。そして、広告制御サーバ５０は、このユーザの誘導回数等に基づいてアプリ間の広告の量や内容、種類等を変化させる。

【0024】

なお、「広告情報の利用情報」には、端末２０で広告情報を選択したことを示す閲覧情報および／または広告情報を通じてアプリを導入（例えばダウンロードやインストール、アプリの初回利用）したことを示す導入情報が含まれる。

【0025】

また、広告制御サーバ５０から端末２０宛ての広告情報の送信タイミングは、非限定的な一例として、以下の３つが考えられる。
（１）或るアプリが送信されたことを示す情報を商品サーバ３０から受信したとき又は受信したことを示す情報を端末２０から受信したとき。
（２）或るアプリが端末２０においてインストールされたことを示す情報を端末２０から受信したとき。
（３）或るアプリが端末２０において利用されたことを示す情報を端末２０から受信したとき。

【0026】

また、広告制御サーバ５０としての機能は、複数のサーバコンピュータによって分散的に実現されてもよい。

【0027】

〔２〕広告制御サーバ５０による広告制御動作概要
広告制御サーバ５０による広告制御動作の概要について図２を用いて説明する。図２には、電子商品の一例である４つのアプリケーションＡ〜Ｄ間で送客／集客が行なわれる様子を例示している。

【0028】

ここで、端末２０においてアプリＡの実行中にアプリＢのバナー広告（アプリＢバナー）が表示されているとする。端末２０においてアプリＢバナーが例えば端末２０のユーザによってクリック又はタップされると、端末２０にはアプリＢの例えば商品紹介画面及び／又はインストール画面が表示される。これにより、広告制御サーバ５０は、アプリＢバナーを通じて１人のユーザをアプリＡからアプリＢの商品紹介画面等に誘導したことになる。これをアプリＡからみると、アプリＡは、１人のユーザをアプリＢに送客したと捉えることができる。一方、アプリＢからみると、１人のユーザをアプリＡから集客したと捉えることができる。

【0029】

このとき、送客元のアプリＡは、送客数に応じたポイント（例えば１人につき＋１０ｐｔ等）を獲得し、送客された（集客した）側のアプリＢは、集客数に応じたポイント（例えば１人につき−１０ｐｔ）を消費する。このようなルールを、他のアプリＢ−Ｃ間、アプリＣ−Ｄ間、アプリＤ−Ａ間についてもそれぞれ同様に適用する。

【0030】

なお、本例において、アプリＡは、広告情報が関連付けられた電子商品であって、ユーザをアプリＢに送客する第２電子商品の一例である。一方で、アプリＢは、アプリＡに関連付けられた広告情報に対応する（広告される）電子商品であって、ユーザをアプリＡから集客する第１電子商品の一例である。

【0031】

以上のようなアプリ間の送客数及び集客数に応じたポイント（以下「送集客ポイント」と称する。）を広告制御サーバ５０はデータベースに記録することで管理し（例えば図３参照）、送集客ポイントが各アプリ間で平等あるいは均一化（平準化）されるように、どのアプリ（電子商品）にどのバナー広告（広告情報）を関連付けるか（別言すると送信、表示させるか）を制御（選択、決定）する。

【0032】

例えば図３に示す例では、アプリＢ（＋３００ｐｔ）の送集客ポイントが最も高い、つまりはアプリＢが最も多く他のアプリへ送客している（別言すると、他のアプリに貸しが有る）ので、何れかのアプリにアプリＢのバナー広告を表示させるようにする。これにより、他のアプリからアプリＢへ送客（アプリＢが集客）する結果、全体としての送集客がバランスされる。

【0033】

なお、送集客ポイントは、可変パラメータの一例である。送集客ポイントは、上述したように、ユーザがアプリＡからアプリＢの商品紹介画面等に誘導された場合だけでなく、ユーザがアプリＢの導入に誘導された場合にも増減されてもよい。この場合、送集客ポイントの増減幅は、ユーザがアプリＡからアプリＢの商品紹介画面等に誘導された場合と、ユーザがアプリＢの導入に誘導された場合とで異ならせることもできる。

【0034】

なお、上記の例は、送集客ポイント数が送客側アプリと被送客（集客）側アプリとで連動して、また、同じ増減幅で更新される例であり、単純なロジックで実現可能である。ただし、これに限られない。

【0035】

例えば、いずれか一方についての送集客ポイント数だけを更新するようにしてもよいし、送客側アプリと集客側アプリとの間で相対的に異なる増減幅で更新するようにしてもよい。いずれにしても、上記の例と同等の制御を実現できる。

【0036】

〔３〕端末２０の構成例
次に、端末２０のハードウェア的な構成は、従来の技術を適宜採用することが可能であるため、以下に簡単に説明する。

【0037】

端末２０は、例えば、プロセッサと記憶装置と出力装置と入力装置と通信装置等を備える。

【0038】

プロセッサは、アプリ等を実行するためのものである。記憶装置は、メモリやハードディスクドライブが挙げられ、アプリ等を記憶するためのものである。出力装置は、ディスプレイ等を含み、アプリの実行結果等を出力（表示）するためのものである。入力装置は、広告情報に対する操作やアプリのインストール操作をするためのものである。通信装置は、通信ネットワーク１０への接続を可能にする装置あるいはインターフェースである。

【0039】

〔４〕広告制御サーバ５０の構成例
次に、広告制御サーバ５０のハードウェア的な構成と機能的な構成とを以下に説明する。なお、商品サーバ３０や決済サーバ４０のハードウェア的な構成は、広告制御サーバ５０の構成と同等とすることができる。

【0040】

（４．１）ハードウェア構成例
図４に、本実施形態の広告制御サーバ５０のハードウェア的な構成例を示す。図３に示す広告制御サーバ５０は、例示的に、制御部５０１、入力装置５０３、外部記憶装置５０５、及び出力装置５０６を備える。また、広告制御サーバ５０は、通信インターフェース（ＩＦ）５０７を備えてもよい。

【0041】

制御部５０１は、例えば、広告制御サーバ５０全体の動作を制御する。

【0042】

入力装置５０３は、サーバ管理者等が制御部５０１に操作信号を入力するために用いられる。入力装置５０３の一例としては、キーボード、マウスやトラックボール等のポインティングデバイス等が挙げられる。また、入力装置５０３には、後述するディスプレイ５０６Ａに備えられたタッチパッドやタッチパネルが含まれてもよい。

【0043】

外部記憶装置５０５は、例示的に、ペリフェラルインタフェース（Ｉ／Ｆ）５２１を介して制御部５０１に着脱可能に接続することができる。当該ペリフェラレルＩ／Ｆ５２１には、１又は複数の周辺機器を追加的に接続してもよい。なお、外部記憶装置５０５は、広告制御サーバ５０内に内蔵される記憶装置であってもよい。

【0044】

外部記憶装置５０５には、ハードディスクドライブ（ＨＤＤ）、フラッシュメモリ、ＳＲＡＭ（Static Random Access Memory）、磁気テープ装置、光ディスク装置等を用いることができる。外部記憶装置５０５には、広告制御に用いられるプログラム（以下「広告制御プログラム」ともいう。）やサーバ内で生成した及び／又は端末から受信したパラメータ等の各種データのほか、電子商品や広告情報等を記憶することができる。コンピュータの一例である広告制御サーバ５０は、外部記憶装置５０５から広告制御プログラム等を読み取って後述するメインメモリ５１３等の内部メモリに転送し格納して用いる。なお、図５のハードウェア的な構成例は、図３の商品サーバ３０にも適用が可能である。この場合、電子商品は商品サーバ３０に記憶され、商品サーバ３０から電子商品が端末装置に送信される。この場合であっても、広告制御サーバ５０は商品サーバ３０の機能を有していてもよい。

【0045】

広告制御プログラム等は、コンピュータ読取可能な記録媒体に記録された形態で提供することができる。記録媒体には、例えば、ハードディスク、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Versatile Disk）、ＢＤ（Blue-ray Disk）、ＲＯＭカートリッジ、バッテリバックアップ付きＲＡＭカートリッジ、フラッシュメモリカートリッジ、不揮発性ＲＡＭカートリッジ等が含まれてよい。また、広告制御プログラム等は、通信ＩＦ５０７により通信ネットワーク１０経由で広告制御サーバ５０に提供してもよい。

【0046】

なお、「コンピュータ」とは、例えば、ハードウェアとオペレーティングシステム（ＯＳ）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味することがある。また、ＯＳが不要でプログラム単独でハードウェアを動作可能な場合には、そのハードウェアがコンピュータに相当するとみることができる。ハードウェアは、ＣＰＵ等の演算装置と、記録媒体に記録されたプログラムを読み取り可能な読み取り装置とを含むことができる。

【0047】

広告制御プログラム等は、上述のようなコンピュータに、広告制御サーバ５０としての機能を実現させるプログラムコードを含んでいる。その機能の一部はプログラムではなくＯＳによって実現されてもよい。

【0048】

出力装置５０６は、例示的に、ディスプレイ５０６Ａやスピーカ５０６Ｂを備え、広告制御サーバ５０のオペレータ等に広告制御プログラム等の実行状態に応じた映像や音声を提供する。ディスプレイ５０６Ａには、液晶ディスプレイや、ＰＤＰ（プラズマ・ディスプレイ・パネル）、ＨＭＤ（ヘッドマウントディスプレイ）等を適用することができる。また、ディスプレイ５０６Ａは、複数のディスプレイを有して成る大画面の統合ディスプレイとしてもよい。

【0049】

通信ＩＦ５０７は、通信ネットワーク１０への接続を可能にする装置あるいはインターフェースである。通信ＩＦ５０７を介して、広告制御サーバ５０は、通信ネットワーク１０に接続された端末２０や他のサーバ３０、４０と適宜に通信することができる。

【0050】

通信ＩＦ５０７は、送受信機能を有しており、送信機能に着目すれば、何れかのアプリを、当該アプリを除く何れか１つのアプリ（他のアプリ）の広告情報に関連付けて端末２０宛てに送信する送信手段の一例として機能する。

【0051】

また、通信ＩＦ５０７は、受信機能に着目すれば、上述したように、何れかのアプリに関する動作を実行した端末２０において他のアプリの広告情報が利用されたことを示す広告情報の利用情報を受信する受信手段の一例として機能する。

【0052】

なお、広告制御サーバ５０および商品サーバ３０において、グラフィックメモリ５１４、オーディオメモリ５１５、ＧＰＵ５１６、オーディオプロセッサ５１８、及び出力装置５０６（別言すると、グラフィック関連機能及びオーディオ関連機能）の一部又は全部は備えないこととしても構わない。

【0053】

（４．２）広告制御サーバ５０の機能的構成例
次に、図５に広告制御サーバ５０の機能的な構成例を示す。

【0054】

図５に例示する広告制御サーバ５０は、ＣＰＵ５１１が広告制御プログラム等をメインメモリ５１３から読み取って実行することによって具現される複数の機能（制御部５０１）を備える。この複数の機能の一例としては、広告処理部５１１ａと、送集客バランス処理部５１１ｂと、広告停止部５１１ｃと、ポイント更新部５１１ｄと、閾値変更部５１１ｅと、が挙げられる。

【0055】

なお、図５に例示する記憶部５３０は、既述のメインメモリ５１３及び／又は外部記憶装置５０５に該当する。記憶部５３０は、例示的に、アプリケーションデータベース（ＤＢ）５３１、ユーザデータベース（ＤＢ）５３５、及びログデータベース（ＤＢ）５３６が記憶する記憶手段の一例である。

【0056】

まず、記憶部５３０の各データベースについて説明する。

【0057】

アプリケーションＤＢ５３１は、電子商品の一例である複数のアプリに関連する情報を記憶する。

【0058】

アプリに関連する情報の一例としては、アプリの識別情報（以下「アプリＩＤ」ともいう。）の他、送集客ポイントＤＢ５３１ａや、会社情報ＤＢ５３１ｂ、広告情報ＤＢ５３１ｃが挙げられる。

【0059】

送集客ポイントＤＢ５３１ａは、複数のアプリ毎の送集客ポイントを記憶する。すなわち、送集客ポイントＤＢ５３１ａは、複数のアプリＩＤとそれぞれの送集客ポイントを対応付けて記憶する。他にも、送集客ポイントＤＢ５３１ａは、例えば各送集客ポイントで共通の基準値（例えばゼロ）も記憶する。

【0060】

ここで、本実施形態では、送集客ポイントは、送客数に応じて獲得され且つ集客数に応じて消費されるため、送客数と集客数に応じた値である。具体的には、送集客ポイントがプラスであれば送客数が集客数よりも多く、送集客ポイントがマイナスであれば集客数が送客数よりも多いことを示す。また、送集客ポイントが基準値のゼロであれば、アプリの送客数と集客数のバランスが取れていることを示す。なお、以下では、送客数を「総客規模」と言い換え、集客数を「集客規模」と言い換える。

【0061】

送集客ポイントＤＢ５３１ａは、更に、アプリＩＤ毎の送集客ポイントに関する上限閾値（プラス側の閾値）と、アプリＩＤ毎の送集客ポイントに関する下限閾値（マイナス側の閾値）と、を記憶する。なお、「上限閾値」は、「過送客」を抑えるために設定される値である。また、「下限閾値」は、「過集客」を抑えるために設定される値である。また、「過送客」とは、集客規模よりも送客規模が多く、送客規模と集客規模の差分が過度であることを意味する。また、「過集客」とは、送客規模よりも集客規模が多く、送客規模と集客規模の差分が過度であることを意味する。

【0062】

更に、送集客ポイントＤＢ５３１ａは、複数の電子商品のうち２以上の電子商品に紐づけられた保険ポイントを記憶する。保険ポイントは、共通パラメータの一例である。この保険ポイントは、提供会社が同じ複数のアプリに紐づけられてもよいし、提供会社は異なるが協力関係にある複数のアプリに紐付けられてもよいし、広告提供システム１の枠組みに参加する全てのアプリに紐付けられてもよい。本実施形態では、保険ポイントは、広告提供システム１の枠組みに参加する全てのアプリに紐付いている。

【0063】

会社情報ＤＢ５３１ｂは、アプリＩＤ毎の会社情報を記憶する。この会社情報は、例えばアプリを提供する提供会社名であり、同じ提供会社が提供する１又は複数のアプリから構成されるグループのグループ情報の一例である。このグループは、他にも提供会社は異なるが協力関係にあるアプリから構成されるグループや、ジャンルが同じアプリから構成されるグループ、ターゲットが同じアプリから構成されるグループ等を含んでいてもよい。以下では、提供会社が同じアプリで構成されるグループの場合を例に説明する。

【0064】

広告情報ＤＢ５３１ｃは、複数のアプリ毎の広告情報を記憶する。すなわち、広告情報ＤＢ５３１ｃは、複数のアプリＩＤとそれぞれの広告情報ＤＢ５３１ｃを対応付けて記憶する。この広告情報には、例えばバナー広告とオファー広告が含まれる。なお、「オファー広告」とは、例えば、端末２０で実行中のアプリＡとは異なる他のアプリＢをインストールするとアプリＡで利用可能な価値情報（例えば、ゲームで使用するパラメータやゲーム内通貨等のゲームポイントやアイテム、追加プログラムやデータ等）が端末２０に付与されることを端末２０に通知する広告である。

【0065】

また、広告情報ＤＢ５３１ｃは、バナー広告のバナーデータリスト５３３及び／又はオファー広告のオファーデータリスト５３４を記憶する。このバナーデータリスト５３３は、例えば複数のバナー広告毎に、広告するアプリのアプリＩＤやバナー広告のデータの保存場所等がリスト形式で記述されている。オファーデータリスト５３４も同様である。なお、アプリＩＤがあることで、各アプリのバナー広告又はオファー広告は、各アプリの送集客ポイント等とも対応付けられることになる。

【0066】

ユーザＤＢ５３５は、端末２０及び／又は当該端末２０のユーザに関する情報を格納しており、例えば端末ＩＤ等を保存している。

【0067】

ログＤＢ５３６は、広告情報の送信履歴や当該広告情報の利用履歴等のログ情報を格納する。

【0068】

アプリケーションＤＢ５３１（広告情報ＤＢ５３１ｃ）と、ユーザＤＢ５３５及びログＤＢ５３６とは互いに関連付けられており、これにより、端末２０においてどのアプリに関連付けられたどの広告情報が利用されたかを管理、把握することができる。

【0069】

次に、制御部５０１の各機能部について説明する。

【0070】

広告処理部５１１ａは、例えばユーザ認証処理と広告処理等を実行する。

【0071】

ユーザ認証処理では、広告処理部５１１ａは、ユーザＤＢ５３５の記憶情報に基づいて端末２０との間のユーザ認証に成功したか否かを判定する。ユーザ認証に成功した場合には、端末２０は、広告制御サーバ５０によるサービス（広告制御）を利用することができる。このような認証処理は従来技術を適宜利用することができるので、詳細な説明は省略する。

【0072】

広告処理は、バナー広告を送信するバナー処理及び／又はオファー広告を送信するオファー処理を含む。第１実施形態では、バナー処理についてのみ説明する。したがって、以下では、広告情報をバナー広告として説明する。なお、オファー処理については、総客側アプリで利用可能な価値情報の付与に関する処理以外は後述するバナー処理の詳細と同様である。

【0073】

広告処理では、広告処理部５１１ａは、何れかのアプリに関する動作を実行した端末２０からバナー要求を受信した場合に、当該端末２０宛てに、送集客バランス処理部５１１ｂにより選択されたアプリのバナー広告（広告情報）を送信する。そして、広告処理部５１１ａは、バナー広告の利用情報を端末２０等から受信した場合に、後述するように、ポイント更新部５１１ｄと連携して送集客ポイントを更新する。

【0074】

送集客バランス処理部５１１ｂは、送集客ポイントに基づいて電子商品間の送集客をバランスする送集客バランス処理を実施する。

【0075】

別言すると、送集客バランス処理部５１１ｂは、送集客ポイントに基づいて各バナー広告の中から何れかのアプリに関連付けるバナー広告を選択する選択手段の一例として機能する。送集客バランス処理部５１１ｂによる送集客バランス処理の詳細については、図９にて後述する。

【0076】

広告停止部５１１ｃは、何れかのアプリの送集客ポイントが対応する閾値に関する条件を満たす場合に、当該アプリのバナー広告を送集客バランス処理部５１１ｂにより選択されるバナー広告から除外する。これにより、広告停止部５１１ｃは、当該アプリの広告を停止して当該アプリの集客を止める広告停止手段の一例として機能する。本実施形態では、広告停止部５１１ｃは、何れかのアプリの送集客ポイントが対応する下限閾値に達する場合に、当該アプリの広告を停止する。

【0077】

また、広告停止部５１１ｃは、何れかのアプリの提供が終了する予定日時の所定期間前から実際に提供が終了する間、当該アプリのバナー広告を送集客バランス処理部５１１ｂにより選択されるバナー広告から除外する。これにより、広告停止部５１１ｃは、当該アプリの広告を停止して当該アプリの集客を止める。

【0078】

ポイント更新部５１１ｄは、アプリの送集客ポイントを更新するパラメータ更新手段の一例である。

【0079】

ポイント更新部５１１ｄは、第１更新部５１２ａと、第２更新部５１２ｂと、第３更新部５１２ｃと、第４更新部５１２ｄと、を備える。

【0080】

第１更新部５１２ａは、第１更新処理を実行する。すなわち、第１更新部５１２ａは、通信ＩＦ５０７でバナー広告の利用情報が受信された場合に、端末２０のユーザをバナー広告に関連付けられた或るアプリがバナー広告にて広告されているアプリに送客したと判定する。そして、第１更新部５１２ａは、当該或るアプリ（送客側アプリ）の送集客ポイント及び広告されているアプリ（集客側アプリ）の送集客ポイントを更新する。本実施形態では、第１更新部５１２ａは、送客側アプリの送集客ポイントを増加する一方で、集客側アプリの送集客ポイントを減少する。

【0081】

第２更新部５１２ｂは、第２更新処理を実行する。すなわち、第２更新部５１２ｂは、複数のアプリのうち何れか１つのアプリが所定の条件を満たす場合に、当該所定の条件を満たすアプリの提供会社（グループ）を特定する。そして、第２更新部５１２ｂは、特定した提供会社内の１又は複数のアプリの送集客ポイントに基づき、下限閾値の絶対値未満である送集客ポイントの基準値（ゼロ）に近づくように所定の条件を満たすアプリの送集客ポイントを更新する。本実施形態では、第２更新部５１２ｂは、特定した提供会社内の１つのアプリの送集客ポイントを減少すると共に、その減少量の全部又は一部だけ、所定の条件を満たすアプリの送集客ポイントを増加する。

【0082】

第３更新部５１２ｃは、第３更新処理を実行する。すなわち、第３更新部５１２ｃは、通信ＩＦ５０７でバナー広告の利用情報が受信された場合に、保険ポイントを更新する。また、第３更新部５１２ｃは、何れか１つのアプリが所定の条件を満たす場合に、保険ポイントに基づき、基準値に近づくように所定の条件を満たすアプリの送集客ポイントを更新する。本実施形態では、第３更新部５１２ｃは、基準値となるように所定の条件を満たすアプリの送集客ポイントを更新する。より具体的には、第３更新部５１２ｃは、保険ポイントを減少すると共に、その減少量の全部又は一部だけ、所定の条件を満たすアプリの送集客ポイントを増加して当該送集客ポイントを基準値にする。

【0083】

ここで、第２更新部５１２ｂ及び第３更新部５１２ｃにおける上記「所定の条件」は、何れか１つのアプリの広告が停止されている期間が所定期間を超えているという条件や、何れか１つのアプリの提供が終了したという条件を含む。

【0084】

なお、第２更新部５１２ｂが、特定したグループ内の１つのアプリの送集客ポイントを減少する場合では、上記「所定の条件」は、何れか１つのアプリの広告が停止されている期間が所定期間を超えているという条件の他、特定したグループ内の１つのアプリの広告が停止されていないという条件も含んでもよい。
上記「特定したグループ内の１つのアプリの広告が停止されていないという条件」は、当該送集客ポイントが上限閾値に達しているという条件や、当該送集客ポイントが基準値を超えているという条件であってもよい。

【0085】

第４更新部５１２ｄは、第４更新処理を実行する。すなわち、第４更新部５１２ｄは、複数のアプリのうち何れか１つのアプリの提供が終了した場合に、当該提供が終了したアプリの提供会社（グループ）を特定する。そして、第４更新部５１２ｄは、当該提供が終了したアプリの送集客ポイントに基づき特定した提供会社内の１又は複数のアプリの送集客ポイントを更新する。

【0086】

上記更新では、第４更新部５１２ｄは、提供が終了したアプリの送集客ポイントをそのまま特定した提供会社内の或るアプリの送集客ポイントとするように、当該或るアプリの送集客ポイントを更新してもよい。また、第４更新部５１２ｄは、提供が終了したアプリの送集客ポイントに対して算出した後、算出で得られた値を特定した提供会社内の或るアプリの送集客ポイントとするように、当該或るアプリの送集客ポイントを更新してもよい。

【0087】

閾値変更部５１１ｅは、所定期間において送客側アプリが送客した規模を示す送客規模を算出する。そして、閾値変更部５１１ｅは、当該送客規模に応じて送客側アプリの下限閾値を変更する。この閾値変更部５１１ｅは、閾値変更手段の一例である。なお、本実施形態では、閾値変更部５１１ｅは、送客規模が大きいほど下限閾値を低くし（よりマイナス側にし）、送客規模が小さいほど下限閾値を高くする（よりプラス側にする）。

【0088】

また、上記「送客規模」は、ユーザの送客数であっても当該送客数に応じたスコアであってもよいが、本実施形態では、送客規模が送客数に応じたスコアである場合を説明する。このスコアは、以下では「送客規模スコア」と呼称する。

【0089】

〔５〕システム動作説明
以下、上述のごとく構成された広告提供システム１の動作について説明する。

【0090】

（５．１）システム全体フロー
図６に例示するように、端末２０は、インストール済みの何れかのアプリが起動されると、起動されたアプリは、広告制御サーバ５０との間でユーザ認証処理を実施する（処理Ｐ１０及びＰ２０）。

【0091】

通信障害やサーバ障害等によりユーザ認証に失敗した場合（処理Ｐ２０でＮＯの場合）、端末２０では起動したアプリによる通常の処理（例えばゲーム等）が実施される（処理Ｐ３０）。別言すると、端末２０のユーザは、ユーザ認証に失敗しても、広告制御サーバ５０によるサービスを利用できないだけで、起動したアプリによる通常の処理は利用可能である。

【0092】

これに対し、ユーザ認証が成功した場合、起動されたアプリは広告処理（バナー処理）を開始する（処理Ｐ４０）。なお、起動されたアプリによってはオファー処理を実施してもよい。例えば、バナー処理では端末２０において或るアプリの実行中にバナー広告が表示される。

【0093】

バナー処理が完了すると、起動されたアプリによる通常の処理が実施される（処理Ｐ５０）。

【0094】

（５．２）バナー処理及び第１更新処理
次に、図７及び図８を参照して、広告制御サーバ５０（広告処理部５１１ａ）や端末２０等の広告提供システム１全体によるバナー処理について説明する。このバナー処理の途中で、第１更新部５１２ａによる第１更新処理も実行される。

【0095】

図７に例示するように、端末２０において何れかのアプリＡが起動され、バナー処理が開始されると、端末２０（アプリＡ）は、バナー要求を広告制御サーバ５０宛てに送信する（処理Ｐ５０１）。

【0096】

広告制御サーバ５０は、バナー要求を受信すると、バナー要求元のアプリＡの送集客ポイントが、バナー要求元のアプリＡの上限閾値に達しているか否かを判定する（処理Ｐ５０２及びＰ５０３）。

【0097】

その結果、送集客ポイントが上限閾値に達していれば（処理Ｐ５０３でＹＥＳの場合）、広告制御サーバ５０は、アプリＡが「過送客」の状態にあると判定して、バナー処理を終了する。したがって、端末２０で起動されたアプリＡに対してバナー広告は表示されない（処理Ｐ５０４）。この結果、アプリＡから他のアプリへの送客が行われなくなるため、過送客が抑制されて、アプリＡの送客規模と集客規模のバランスが改善される。

【0098】

一方、送集客ポイントが上限閾値に達していなければ（処理Ｐ５０３でＮＯの場合）、広告制御サーバ５０は、送集客バランス処理部５１１ｂによる送集客バランス処理を実施し（処理Ｐ５０５）、当該送集客バランス処理により選択されたアプリ（例えばアプリＢ）のバナー広告をバナー要求のあったアプリＡに関連付けて端末２０宛てに送信し、バナー広告送信済みであることを例えばログＤＢ５３６に一時（キャッシュ）保存する（処理Ｐ５０６）。なお、送集客バランス処理の詳細については、図９にて後述する。

【0099】

端末２０（アプリＡ）では、上記バナー広告を広告制御サーバ５０から受信すると、当該バナー広告を表示し（処理Ｐ５０７）、当該バナー広告の利用（例えばクリック又はタップ等の選択操作）の有無を監視する（処理Ｐ５０８）。

【0100】

バナー広告に対する選択操作が無ければ（処理Ｐ５０８でＮＯの場合）、端末２０のアプリＡは、広告制御サーバ５０が指定する時間だけバナー広告を表示し（処理Ｐ５０９）、処理Ｐ５０１へ戻る。バナー広告を表示する指定時間の情報は、バナー広告と共にあるいはバナー広告とは別に広告制御サーバ５０から端末２０に送信される。代替的に、当該指定時間の情報は、端末２０において予め保有しておいてもよい。

【0101】

バナー広告に対する選択操作が有れば（処理Ｐ５０８でＹＥＳの場合）、端末２０のアプリＡは、バナー広告が利用されたことを示す利用情報（例えばクリック情報等）と、バナー広告で広告されるアプリ（例えばアプリＢとする。）の商品紹介画面等のＵＲＬ（Uniform Resource Locator）要求と、を広告制御サーバ５０宛てに送信する（処理Ｐ５１０）。

【0102】

広告制御サーバ５０は、端末２０のアプリＡから上記利用情報を受信すると、当該利用情報を例えばログＤＢ５３６に保存する（処理Ｐ５１１）。

【0103】

図８に例示するように、広告制御サーバ５０は、会社情報ＤＢ５３１ｂが記憶している会社情報に基づいて、同一会社間の送客か否かを判定する（処理Ｐ５１２及びＰ５１３）。

【0104】

同一会社間の送客であれば（処理Ｐ５１３でＹＥＳの場合）、広告制御サーバ５０は、第１更新部５１２ａを呼び出す。広告制御サーバ５０（第１更新部５１２ａ）は、送客側アプリＡの送集客ポイントを増加（例えば＋１０ｐｔ）し、集客側アプリＢの送集客ポイントを減少（例えば−１０ｐｔ）する（処理Ｐ５１４）。

【0105】

これに対し、同一会社間の送客でなければ（処理Ｐ５１３でＮＯの場合）、広告制御サーバ５０は、送客側アプリＡの送集客ポイントを増加（例えば同一会社で付与されるポイント＋１０ｐｔのうち一部の＋９ｐｔのみ）し、集客側アプリＢの送集客ポイントを減少（例えば−１０ｐｔ）する（処理Ｐ５１６）。

【0106】

ここで、広告制御サーバ５０は、第２更新部５１２ｂを呼び出す。広告制御サーバ５０（第２更新部５１２ｂ）は、上記＋１０ｐｔのうち残り＋１ｐｔを保険ポイントとして例えば送集客ポイントＤＢ５３１ａ（図５参照）に蓄積（プール）する（処理Ｐ５１７）。

【0107】

上記送集客ポイント増減処理の後、広告制御サーバ５０は、端末２０から要求された商品紹介画面等のＵＲＬを当該端末２０宛てに送信する（処理Ｐ５１５）。端末２０は、受信したＵＲＬにアクセスする（処理Ｐ５１８）。端末２０は、当該ＵＲＬにアクセスすると、例えば広告制御サーバ５０からＵＲＬに対応するページのデータが、各種マーケットの商品サーバ３０から、端末２０に送信される（処理Ｐ５１９）。当該ページは、例えばバナー広告されたアプリＢの紹介やインストールを実施可能なページ（インストールページ）である。

【0108】

端末２０は、当該インストールページを通じてバナー広告されたアプリＢをインストールする。そして、アプリＢが、端末２０においてユーザにより起動されて実行される（処理Ｐ５２０）。

【0109】

以上より、一連のバナー処理が終了する。

【0110】

（５．３）送集客バランス処理及び広告停止処理
次に、図９を参照して、広告制御サーバ５０（送集客バランス処理部５１１ｂ）による送集客バランス処理について説明する。なお、この処理では、広告停止部５１１ｃと連携して広告停止処理も実施される。

【0111】

図７にて説明した送集客バランス処理（処理Ｐ５０５）では、図９に例示する処理が実施される。すなわち、広告制御サーバ５０（送集客バランス処理部５１１ｂ）は、広告情報ＤＢ５３１ｃのバナーデータリスト５３３（図５参照）を参照し（処理Ｐ７０１）、端末２０において既にインストール済みアプリに対応するバナー広告を当該リストから除外する（処理Ｐ７０２）。

【0112】

次いで、広告制御サーバ５０は、バナーデータリスト５３３をポイント順にソートし（処理Ｐ７０３）、ポイントの最も高いアプリを選択する（処理Ｐ７０４）。そして、広告制御サーバ５０は、選択したアプリの送集客ポイントが当該選択したアプリの下限閾値に達しているか否かを判定する（処理Ｐ７０５及びＰ７０６）。

【0113】

当該判定の結果、送集客ポイントが下限閾値に達していれば（処理Ｐ７０６でＹＥＳの場合）、広告制御サーバ５０は、広告停止部５１１ｃを呼び出して広告停止処理を実施させる（処理Ｐ７０７）。この広告停止処理では、広告制御サーバ５０は、選択したアプリをバナーデータリスト５３３から削除することで、送集客バランス処理により最終的に選択される（選択が決定される）広告情報から除外する。これにより、広告制御サーバ５０は、選択したアプリの広告（集客）を停止する。そして、広告制御サーバ５０は、除外後に改めてポイントの最も高い他のアプリをバナーデータリスト５３３において選択する（処理Ｐ７０４）。

【0114】

一方、送集客ポイントが下限閾値に達していなければ（処理Ｐ７０６でＮＯの場合）、広告制御サーバ５０は、広告要求のあった日が、選択したアプリが商品サーバ３０において初めて提供可能となった日（アプリのリリース日）から７日以内か否かを判定する（処理Ｐ７０８及びＰ７０９）。

【0115】

当該判定の結果、リリース日から７日以内であれば（処理Ｐ７０９でＹＥＳの場合）、広告制御サーバ５０は、上述した処理Ｐ７０７を実行した後再び処理Ｐ７０４を実行する。

【0116】

リリース日から７日以内でなければ（処理Ｐ７０９でＮＯの場合）、広告要求のあった日が、選択したアプリの商品サーバ３０による提供が終了する日の６０日前以降か否かを判定する（処理Ｐ７１０及びＰ７１１）。なお、広告制御サーバ５０は、アプリの提供が終了する日を、その６０日前以前にそのアプリの提供会社等から通知を受けることで知得しているものとする。

【0117】

当該判定の結果、選択したアプリの提供が終了する日の６０日前以降であれば（処理Ｐ７１１でＹＥＳの場合）、広告制御サーバ５０は、上述した処理Ｐ７０７を実行した後再び処理Ｐ７０４を実行する。

【0118】

広告要求のあった日が、選択したアプリの提供が終了する日の６０日前以降でなければ（処理Ｐ７１１でＮＯの場合）、バナー要求したアプリへのバナー送信履歴をキャッシュで確認し、当該確認の結果、バナー要求したアプリにて直近５回以内に、選択したアプリのバナー広告が表示されていたかを判定する（処理Ｐ７１２及びＰ７１３）。

【0119】

当該判定の結果、バナー要求したアプリにて直近５回以内に、選択したアプリのバナー広告が表示されていれば（処理Ｐ７１３でＹＥＳの場合）、広告制御サーバ５０は、上述した処理Ｐ７０７を実行した後再び処理Ｐ７０４を実行する。

【0120】

一方、バナー要求したアプリにて直近５回以内に、選択したアプリのバナー広告が表示されていなければ（処理Ｐ７１３でＮＯの場合）、バナー要求したアプリにて表示するバナー広告を選択したアプリのバナーに決定する（処理Ｐ７１４）。

【0121】

広告制御サーバ５０（送集客バランス処理部５１１ｂ）は、以上のようにして送集客ポイントに基づいてバナー要求したアプリに関連付ける広告情報を制御する。例えば、送客規模が相対的に他のアプリよりも高いアプリがあれば、当該送客規模の高いアプリの広告情報をバナー要求した他のアプリに関連付けて端末２０宛てに送信する広告情報として選択する。

【0122】

図３の例でいえば、アプリＢは送集客ポイントが他のアプリよりも高く送集客ポイントが高いので、他のアプリに関連付けて送信する広告情報としてアプリＢの広告情報を選択して送信する。

【0123】

なお、送集客ポイントに基づいて広告を行う方法としては、上記の他、既に送集客ポイントが高いアプリを含む各アプリに対して、送集客ポイントが低い（集客させたいアプリ）の広告情報を選択して送信する（表示させる）方法も考えられる。したがって、送集客ポイントに基づいた広告情報の制御は、その趣旨を逸脱しない範囲で種々変形して実施することができることは言うまでもない。

【0124】

（５．４）第２更新処理
次に、図１０を参照しながら、第２更新部５１２ｂの第２更新処理について説明する。なお、この第２更新処理は、定期的に或いは所定のタイミングで繰り返し実行される。

【0125】

広告制御サーバ５０（第２更新部５１２ｂ）は、何れかのアプリについて所定期間（予め停止最大期間として定めた期間であって例えば７日間や３０日間）、広告（集客）が停止されているか否かを判定する（処理Ｐ８００及びＰ８０１）。すなわち、広告制御サーバ５０は、所定期間、何れかのアプリの送集客ポイントが下限閾値に達しているか否かを判定する。

【0126】

当該判定の結果、何れかのアプリについて所定期間広告が停止されていなければ（処理Ｐ８０１でＮＯの場合）、広告制御サーバ５０は、処理を終了する。

【0127】

一方で、何れかのアプリについて所定期間広告が停止されていれば（処理Ｐ８０１でＹＥＳの場合）、広告制御サーバ５０は、会社情報ＤＢ５３１ｂを参照して当該何れかのアプリの提供会社（グループ）を特定する。そして、広告制御サーバ５０は、特定した提供会社内の他のアプリの広告が停止されていないか否かを判定する。本実施形態では、他のアプリの送集客ポイントが上限閾値に達しているか否かを判定する（処理Ｐ８０２及びＰ８０３）。

【0128】

当該判定の結果、他のアプリの送集客ポイントが上限閾値に達していなければ（所定Ｐ８０３でＮＯの場合）、広告制御サーバ５０は、処理を終了する。

【0129】

一方で、他のアプリの送集客ポイントが上限閾値に達していれば（処理Ｐ８０３でＹＥＳの場合）、広告制御サーバ５０は、他のアプリの送集客ポイントを使用（減少）する（処理Ｐ８０４）。なお、この減少量は、固定であっても、広告が停止されているアプリの送集客ポイントに応じて可変であってもよい。

【0130】

その後、広告制御サーバ５０は、他のアプリの送集客ポイントの減少量だけ基準値に近づくように広告が停止されているアプリの送集客ポイントを増加する。例えば、減算分が１００ｐｔであれば、増加量も１００ｐｔとすることができる。本実施形態では、広告制御サーバ５０は、広告が停止されているアプリの送集客ポイントが下限閾値から上回るように当該送集客ポイントを増加する。これにより、広告制御サーバ５０は、広告が停止されているアプリの広告停止を解除する。なお、上記「下限閾値から上回る」とは、送集客ポイントが基準値に近づくことを意味する。

【0131】

そして、広告制御サーバ５０は、一旦待機した後に改めて処理Ｐ８００を実行する。

【0132】

（５．５）閾値変更処理
次に、図１１を参照しながら、閾値変更部５１１ｅによる閾値変更処理について説明する。なお、この閾値変更処理は、商品サーバ３０が提供する予定のアプリ毎に定期的に或いは所定のタイミングで行われる。

【0133】

広告制御サーバ５０（閾値変更部５１１ｅ）は、商品サーバ３０においてアプリが提供可能となったか（リリースしたか）否かを判定する（処理Ｐ９００及びＰ９０１）。

【0134】

当該判定の結果、アプリが提供可能となっていなければ（処理Ｐ９０１でＮＯの場合）、広告制御サーバ５０は、改めて処理Ｐ９００を実行する。

【0135】

一方で、アプリが提供可能（リリース）となっていれば（処理Ｐ９０１でＹＥＳの場合）、広告制御サーバ５０は、当該アプリが他のアプリのバナー広告に関連付けられたとき（当該アプリが送客側アプリになったとき）の利用情報をログＤＢ５３６から参照する。そして、広告制御サーバ５０は、当該利用情報に基づき、リリース日から７日間の送客規模を算出する（処理Ｐ９０２）。なお、この７日間、アプリの広告（集客）は停止している（図９参照）。

【0136】

本実施形態では、送客規模は上述の送客規模スコアである。この送客規模スコアは、例えばアプリ毎にログＤＢ５３６に記憶される。送客規模スコアは、例えば１人の送客につき送集客ポイントと同様に１０ｐｔが加算されるものの、集客したとしても減算されることはない。

【0137】

その後、広告制御サーバ５０は、７日間の送客規模に基づき当月分の送客規模Ｓ０を予測する（処理Ｐ９０３）。

【0138】

次に、広告制御サーバ５０は、予測した送客規模Ｓ０に基づいて下限閾値を初期値から変更（設定）する（処理Ｐ９０４）。具体的には、広告制御サーバ５０は、下限閾値を送客規模Ｓ０（送客規模スコア）に「−１」を乗算した値に変更する。

【0139】

その後、広告制御サーバ５０は、翌月になったか否かを判定する（処理Ｐ９０５及びＰ９０６）。

【0140】

当該判定の結果、翌月になっていれば（処理Ｐ９０６でＹＥＳの場合）、先月の送客規模Ｓ１を算出する。この算出方法は、上述の処理Ｐ９０２と同様である。

【0141】

一方で、翌月になっていなければ（処理Ｐ９０６でＮＯの場合）、広告制御サーバ５０は、商品サーバ３０によるアプリの提供が終了する予定日の６０日前以降か否かを判定する（処理Ｐ９１０及びＰ９１１）。なお、この処理Ｐ９１０及び９１１は省略することもできる。

【0142】

当該判定の結果、予定日の６０日前以降であれば（処理Ｐ９１１でＹＥＳの場合）、広告制御サーバ５０は、閾値変更処理を終了する。

【0143】

一方で、予定日の６０日前以降でなければ（処理Ｐ９１１でＮＯの場合）、広告制御サーバ５０は、改めて処理Ｐ９０５を実行する。

【0144】

先月の送客規模Ｓ１を算出した後（処理Ｐ９０７）、広告制御サーバ５０は、先月の送客規模Ｓ１に基づき下限閾値を変更する（処理Ｐ９０８）。具体的には、広告制御サーバ５０は、下限閾値を送客規模Ｓ１（送客規模スコア）に「−１」を乗算した値に変更する。

【0145】

その後、広告制御サーバ５０は、送客規模Ｓ１をリセットし（処理Ｐ９０９）、処理９０１に進む。

【0146】

（５．６）第３更新処理及び第４更新処理
次に、図１２を参照しながら、第４更新部５１２ｄによる第４更新処理について説明する。この第４更新処理の途中で、第３更新部５１２ｃによる第３更新処理も実行される。なお、この第４更新処理は、商品サーバ３０が提供するアプリ毎に定期的に或いは所定のタイミングで行われる。

【0147】

広告制御サーバ５０（第４更新部５１２ｄ）は、商品サーバ３０によるアプリの提供が終了したか否かを判定する（処理Ｐ１０００及びＰ１００１）。

【0148】

当該判定の結果、アプリの提供が終了していなければ（処理Ｐ１００１でＮＯの場合）、広告制御サーバ５０は、一旦待機した後、改めて処理Ｐ１０００を実行する。

【0149】

一方で、アプリの提供が終了していれば（処理Ｐ１００１でＹＥＳの場合）、広告制御サーバ５０は、会社情報ＤＢ５３１ｂを参照して提供が終了したアプリの提供会社（グループ）を特定する。そして、特定した提供会社内の他のアプリであって商品サーバ３０により新たに提供する他のアプリがあるか否かを判定する（処理Ｐ１００２及びＰ１００３）。

【0150】

当該判定の結果、新たに提供するアプリがあれば（処理Ｐ１００３でＹＥＳの場合）、広告制御サーバ５０は、提供が終了したアプリの送集客ポイントがそのまま新たに提供するアプリの送集客ポイントとなるように、当該新たに提供するアプリの送集客ポイントを更新する。すなわち、新たに提供するアプリの送集客ポイントの初期値がゼロとすれば、当該新たに提供するアプリの送集客ポイントを、そのゼロから、提供が終了したアプリの送集客ポイントになるように更新する。

【0151】

一方で、新たに提供するアプリがなければ（処理Ｐ１００３でＮＯの場合）、広告制御サーバ５０は、アプリの提供が終了した日から１ヶ月が経過したか否かを判定する（処理Ｐ１００５及びＰ１００６）。

【0152】

当該判定の結果、１ヶ月が経過していなければ（処理Ｐ１００６でＮＯの場合）、広告制御サーバ５０は、改めて処理Ｐ１００２を実行する。

【0153】

一方で、１ヶ月が経過していれば（処理Ｐ１００６でＹＥＳの場合）、広告制御サーバ５０は、提供が終了したアプリの送集客ポイントが基準値未満（マイナス）か否かを判定する（処理Ｐ１００７及びＰ１００８）。

【0154】

当該判定の結果、提供が終了したアプリの送集客ポイントが基準値未満でなければ（処理Ｐ１００８でＮＯの場合）、移行処理を終了する。

【0155】

一方で、提供が終了したアプリの送集客ポイントが基準値未満であれば（処理Ｐ１００８でＹＥＳの場合）、広告制御サーバ５０は、第３更新部５１２ｃの第３更新処理を呼び出した後（処理Ｐ１００９）、第４更新処理を終了する。

【0156】

そして、呼び出された第３更新処理では、広告制御サーバ５０は、保険ポイントを減少すると共に、提供が終了したアプリの送集客ポイントが基準値に近づくように、その減少量だけ、提供が終了したアプリの送集客ポイントを増加する。本実施形態では、上記減少量は、提供が終了したアプリの送集客ポイントと基準値との差分である。

【0157】

〔６〕結び
以上のように、本実施形態によれば、閾値変更部５１１ｅが、或るアプリの所定期間の送客規模に応じて当該或るアプリ自身の下限閾値を変更するので（図１１参照）、所定期間の送客規模（言い換えれば送客能力）を超えた集客規模のユーザを集客する前に、広告停止部５１１が、或るアプリの広告を停止してユーザの集客を止めることができる。すなわち、或るアプリが自身の送客能力を超えた規模のユーザを集客することを抑制できる。このように構成することで、その後において集客が止められた或るアプリが自身の送客能力の範囲で送客をすることで、集客を止める前までの集客規模に送客規模を追いつかせることができ、アプリの送客規模と集客規模のバランスを取ることができる。

【0158】

また、第４更新部５１２ｄが、アプリの提供が終了した場合に、提供が終了したアプリの提供会社を特定し、提供が終了したアプリの送集客ポイントに基づき特定した提供会社内の或るアプリの送集客ポイントを更新する。ここで、提供が終了したアプリの送集客ポイントが基準値でない場合、もはや送集客ポイントを基準値にする、すなわち提供が終了したアプリでは送客規模と集客規模のバランスを取ることができない。そこで、更新部５１２ｂが、提供が終了したアプリの送集客ポイントに基づき特定した提供会社内の或るアプリの送集客ポイントを更新することで、アプリの提供会社全体で送集客ポイントが基準値となるよう、すなわち送客規模と集客規模のバランスを取るようにすることができる。

【0159】

本実施形態では、第４更新部５１２ｄが、提供が終了したアプリの送集客ポイントをそのまま或るアプリの送集客ポイントとするように、当該或るアプリの送集客ポイントを更新するので、アプリの提供会社全体としての送集客ポイントの合計値の収支を合わせることができる。また、例えば提供が終了したアプリの送集客ポイントがプラスであれば、新たに提供するアプリはその送集客ポイントを消費して新たなユーザを集客することが可能となる。

【0160】

また、第２更新部５１２ｂが、何れか１つのアプリが所定の条件を満たす場合に、当該所定の条件を満たすアプリの提供会社を特定し、特定した提供会社内の或るアプリの送集客ポイントに基づき、送集客ポイントの基準値に近づくように当該所定の条件を満たすアプリの送集客ポイントを更新する。これにより、上記所定の条件にもよるものの、或るアプリが、所定の条件を満たすアプリの広告が停止されないように、当該所定の条件を満たすアプリを助けることができる。

【0161】

本実施形態では、第２更新部５１２ｂが、アプリの広告が停止されている期間が所定期間を超えており、当該アプリと同じ提供会社内の或るアプリの送集客ポイントが対応する下限閾値に達していないという条件を満たしたときに、或るアプリの送集客ポイントを減少すると共に、広告が停止されているアプリの送集客ポイントを増加する。このため、同じ提供会社内の或るアプリに集客の余裕等があるときに、当該或るアプリが広告の停止されているアプリを広告が再開するように助けることができる。
なお、本実施形態では、上記「下限閾値に達していないとき」とは、同じ提供会社のアプリの送集客ポイントが対応する上限閾値に達しているときであるため、十分に集客の余裕がある。このように、広告の停止されているアプリを助けることができれば、広告が停止されているアプリに再び集客できるという機会を与えることができ、もって当該アプリが広告提供システム１の枠組みから離脱することを抑制できる。

【0162】

また、第３更新部５１２ｃが、何れか１つのアプリが所定の条件を満たす場合に、保険ポイントに基づき、送集客ポイントの基準値に近づくように当該所定の条件を満たすアプリの送集客ポイントを更新する。これにより、所定の条件にもよるものの、広告提供システム１全体としての送集客ポイントの収支を合わせることができる。

【0163】

本実施形態では、第３更新部５１２ｃが、何れか１つのアプリの提供が終了したという条件を満たすときに、提供が終了したアプリの送集客ポイントが基準値に近づくように、保険ポイントを減少すると共に、提供が終了したアプリの送集客ポイントを増加する。ここで、アプリの送集客ポイントがマイナスのまま当該アプリの提供が終了した場合、広告提供システム１全体としての送集客ポイントの収支を合わなくなる。収支が合わないと、各アプリの送集客ポイントが基準値付近にあることで、回遊が好適に行われるという枠組みを乱す要因ともなり得る。そこで、上述のように、提供が終了したアプリの送集客ポイントを提供が終了したアプリの送集客ポイントが基準値に近づくように増加することで、広告提供システム１全体としての送集客ポイントの収支を合わせることができる。

【0164】

また、広告停止部５１１ｃが、アプリの提供が終了する予定日時の所定期間前から実際に提供が終了する間、終了するアプリの広告（集客）を停止するので（図９参照）、提供が終了するアプリはその間に送客だけして、送集客ポイントがマイナスのまま、すなわち送客規模と集客規模のバランスを崩したままアプリの提供が終了することを抑制することができる。このような抑制ができれば、この送集客ポイントをそのまま新たに提供するアプリの送集客ポイントにしたとしても、新たに提供するアプリが送集客ポイントを基準値にすることが容易となり、新たに提供するアプリの送客規模と集客規模のバランスを取ることができる。

【0165】

〔７〕変形例
なお、本発明は上記の具体例に限定されるものではない。すなわち、上記の具体例に、当業者が適宜設計変更を加えたものも、本発明の特徴を備えている限り、本発明の範囲に包含される。また、前述した実施形態が備える各要素は、技術的に可能な限りにおいて組み合わせることができ、これらを組み合わせたものも本発明の特徴を含む限り本発明の範囲に包含される。

【0166】

例えば、上述した実施形態において送集客ポイントの大小や送集客ポイントについての上限／下限閾値等は、送客や集客の量や差を示す情報（可変パラメータ）の一例に過ぎず、送集客ポイントの「加減算」は、上述した実施形態で示した態様に限られない。例えば送集客ポイントを加算するのか減算するのかは、一方が加算で他方が減算となっていればどちらでも良い。

【0167】

また、広告制御サーバ５０は、バナー要求があった場合に送集客バランス処理を実行する場合を説明したが、定期的に或いはランダムに送集客バランス処理を実施してもよい。この場合、バナー要求があったときは、広告制御サーバ５０は、既に送集客バランス処理により選択されている広告情報を送信する（図７に示す処理Ｐ５０６）。また、広告制御サーバ５０は、バナー要求の受信が無くても広告情報を何れかのアプリに関連付けて送信してもよい。この場合、端末２０は、広告情報に関連付けられたアプリの動作があった場合にその広告情報を表示する。

【0168】

また、図１２に示す移行処理では、処理Ｐ１００７〜Ｐ１００９を実行した後に、処理Ｐ１００２〜処理Ｐ１００５を実施してもよい。すなわち、第４更新処理と第３更新処理の順番が逆であってもよく、提供が終了したアプリの送集客ポイントが基準値未満の場合にまず保険ポイントを消費して当該送集客ポイントを増加した後に、その送集客ポイントを新たに提供するアプリの送集客ポイントにしてもよい。この場合、新たに提供するアプリの送集客ポイントとする量を、保険ポイントで減らすことができる。また、第４更新処理と第３更新処理の少なくとも何れか一方を省略してもよい。

【0169】

また、閾値変更部５１１ｅは、下限閾値と共に或いは当該下限閾値に代えて、アプリの所定期間の集客度合に応じて当該アプリの上限閾値を変更してもよい。この場合でも、アプリの送客規模と集客規模のバランスを取ることができる。

【0170】

また、第２更新部５１２ｂが、アプリの広告が停止されている期間が所定期間を超えた場合に、その広告を再開するために同じ提供会社のアプリの送集客ポイントを使用（減算）する場合を説明したが、保険ポイントを使用（減算）してもよい。

【0171】

また、閾値変更部５１１ｅは、ログＤＢ５３６を参照して送客規模スコアを算出する場合を説明したが、通信ＩＦ５０７で利用情報が受信された場合に、バナー広告が表示されているアプリがユーザを送客したと判定し、例えば図８に例示する処理Ｐ５１４において現在の送客規模スコアに１０ｐｔを加算することを例えば７日間繰り返すことで、送客規模スコアを算出してもよい。

【符号の説明】

【0172】

５０：広告制御サーバ（広告制御装置）
５０７：通信ＩＦ（送信手段、受信手段）
５１１ｂ：送集客バランス処理部（選択手段）
５１１ｃ：広告停止部（広告停止手段）
５１１ｄ：ポイント更新部（パラメータ更新手段）
５１１ｅ：閾値変更部（閾値変更手段）
５３０：記憶部（記憶手段）

【要約】

【課題】電子商品の送客規模と集客規模のバランスを取る。
【解決手段】広告制御装置（５０）が、或る電子商品の広告情報を他の電子商品に関連付けて端末装置（２０）へ送信するものであって、その広告情報の送信、すなわち或る電子商品の広告を停止するための閾値を記憶しておき、その閾値を当該或る電子商品が他の電子商品にユーザを送客した規模を示す送客規模に応じて変更する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】