JP6361002B2 - 広告情報管理プログラム、広告情報表示装置及び広告情報管理システム - Google Patents

Description

本発明は、広告管理プログラム、広告表示装置及び広告管理システムに関し、特に、表示された広告情報に対する反応を集計するための処理に関する。

近年、携帯電話、スマートフォン、タブレット端末等の携帯型の情報処理端末（以降、「携帯端末」とする）が広く用いられている。そのような携帯端末は、特定の機能を実現するためのアプリケーション・プログラム（以降、「アプリ」とする）をダウンロードしてインストールすることによる、ソフトウエア機能の拡張が可能であることが一般的である。

上述したようなアプリには、他のアプリの広告を表示する機能が組み込まれたものがある。このような広告の表示機能が組み込まれたアプリは、例えばメディアアプリと呼ばれる。メディアアプリ内に表示される広告は、告知対象のアプリをダウンロードするためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）へのリンク機能を有するものが一般的であり、メディアアプリ内に表示された広告部分をタッチ操作することにより、告知対象のアプリのダウンロード画面へのアクセスが実行される。

このような携帯端末の広告機能において、広告が表示されることにより告知対象のアプリがダウンロードされたか否かを示す情報を収集することにより、アプリのダウンロードに貢献したメディアアプリを特定する方法が提案されている（例えば、特許文献１参照）。特許文献１に開示された技術によれば、メディアアプリ内に表示された広告が選択された際に生成される第１情報と、新たなアプリがダウンロードされてインストールされた際に生成される第２情報とを管理サーバに夫々送信することにより、管理サーバにおいて、アプリのダウンロードに貢献したメディアアプリを特定する。

また、他の方法として、広告を選択することによってダウンロードサイトにアクセスする際に携帯端末に対してクッキー情報を送信し、新たにダウンロードされてインストールされたアプリの機能によって広告のトラッキングを行う方法が提案されている（例えば、特許文献２参照）。

特許文献１に開示された方法を用いる場合、広告のタッチによって携帯端末において第１情報が生成されて管理サーバに送信されるため、その都度ネットワーク負荷が発生すると共に、管理サーバにおいては記憶領域が消費される。しかしながら、ユーザによる携帯端末の操作においては、メディアアプリ内に表示された広告をタッチ操作してアプリのダウンロード画面にアクセスはしたものの、アプリのダウンロードは行わないという場合が少なくない。

その結果、第１情報の送信によって生じたネットワーク負荷は無駄なものとなり管理サーバ側の記憶領域も無駄に消費されることとなり、非効率である。また、特許文献２に開示された方法は、新たにダウンロードされたアプリが広告のトラッキング機能に対応していることが前提となるため、適用可能な範囲が制限される。

本発明は、このような課題を解決するためになされたものであり、新たなアプリをダウンロードさせるための広告が表示されるメディアアプリのシステムにおいて、新たなアプリのダウンロードに貢献したメディアアプリの特定を効率的に行うことを目的とする。

上記課題を解決するために、本発明の一態様は、ネットワークを介してダウンロード可能なプログラムの広告を表示するための広告情報を管理する広告情報管理プログラムであって、前記広告情報に基づき、前記広告を表示するための情報を出力するステップと、表示された広告に対する操作により、前記広告される対象である対象プログラムのダウンロード画面が要求されたことを認識するステップと、前記ダウンロード画面が要求された場合に、前記対象プログラムを識別するための対象プログラム識別情報及び前記広告が表示される画面上の領域を提供している表示プログラムを識別するための表示プログラム識別情報を関連付けて記憶するステップと、前記対象プログラムがダウンロードされたことを認識するステップと、前記対象プログラムがダウンロードされたことが認識された場合に、ダウンロードされた対象プログラムを識別するための対象プログラム識別情報に関連付けられている表示プログラム識別情報を、ネットワークを介して送信するために出力するステップとを情報処理装置に実行させることを特徴とする。

本発明によれば、新たなアプリをダウンロードさせるための広告が表示されるメディアアプリのシステムにおいて、新たなアプリのダウンロードに貢献したメディアアプリの特定を効率的に行うことができる。

本発明の実施形態に係るシステムの運用形態を示す図である。 本発明の実施形態に係る情報処理装置のハードウエア構成を示すブロック図である。 本発明の実施形態に係るシステム全体の動作を示すシーケンス図である。 本発明の実施形態に係る携帯端末の機能構成を示すブロック図である。 本発明の実施形態に係る基本設定情報の例を示す図である。 本発明の実施形態に係る広告情報の例を示す図である。 本発明の実施形態に係る携帯端末の画面における広告表示の例を示す図である。 本発明の実施形態に係る確認情報の例を示す図である。 本発明の実施形態に係るＤＬ確認動作を示すフローチャートである。 本発明の実施形態に係る広告管理ＳＤＫにおいて複数の確認情報が生成されることを示す図である。 本発明の実施形態に係るＤＬ確認動作の実行判断動作を示すフローチャートである。 本発明の実施形態に係る広告管理サーバの機能構成を示すブロック図である。 本発明の実施形態に係る複数のメディアアプリにおいて確認情報が生成される態様を示す図である。 本発明の実施形態に係るユーザＩＤの関連付け態様を示す図である。 本発明の実施形態に係るユーザ情報ＤＢの例を示す図である。 本発明の実施形態に係るユーザＩＤに基づく重複する確認情報の整理動作を示すフローチャートである。 本発明の実施形態に係る重複する確認情報の削除動作を示すフローチャートである。 本発明の他の実施形態に係る携帯端末１の機能構成を示すブロック図である。 本発明の他の実施形態に係る確認情報の複製態様を示す図である。 本発明の他の実施形態に係る確認情報の複製チェックを示す図である。 本発明の他の実施形態に係る確認情報送信時の重複回避動作を示すシーケンス図である。 本発明の他の実施形態に係る確認情報送信時の重複回避動作を示すシーケンス図である。

実施の形態１．
以下、図面を参照して、本発明の実施形態について説明する。本実施形態においては、携帯端末にインストールされて動作し、広告表示機能を有するアプリケーション・プログラム（以降、「メディアアプリ」とする）がネットワークを介して広告の情報を取得することにより、画面上に広告を表示する広告情報管理システムにおいて、表示された広告によるリンクを経て新たなアプリケーション・プログラムがダウンロードされた場合に、その広告を表示したメディアアプリを特定するための処理について説明する。

図１は、本実施形態に係る広告管理システムの運用形態を示す図である。図１に示すように、本実施形態に係るシステムは、携帯電話、スマートフォン、タブレット、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の携帯端末１、携帯端末１における広告表示を管理する広告管理サーバ２、携帯端末１においてダウンロードして利用することが可能なアプリケーション・プログラムを提供するアプリ提供サーバ３が、夫々インターネットなどのネットワーク回線を介して接続されて構成されている。

携帯端末１は、様々な機能を実現するために夫々専用の機能を有するアプリケーション・プログラム（以降、「アプリ」とする）がインストールされて動作可能となっている情報処理端末である。それらのアプリのうち、広告管理サーバ２と通信することにより広告管理サーバ２から広告情報を受信して広告を表示する機能を有するものがメディアアプリと呼ばれる。

本実施形態に係るメディアアプリは、広告管理サーバ２から受信した広告情報に基づいて広告を表示する機能に加えて、メディアアプリによる他のアプリのダウンロードへの貢献度を把握するための情報を生成して広告管理サーバ２に送信する機能を有する。そのため、本実施形態に係るメディアアプリは、表示された広告に対するタッチ操作によって告知対象のアプリがダウンロードされてインストールされた場合に、それを検知して広告管理サーバ２に対して情報を送信する。詳細は後述する。

広告管理サーバ２は、携帯端末１におけるメディアアプリの動作に応じて広告情報を提供する広告配信装置である。また、本実施形態に係る広告管理サーバ２は、メディアアプリの機能によって生成される確認情報を収集することにより、アプリ提供サーバ３からのアプリのダウンロードに対するメディアアプリの貢献度を解析する機能を有する。

アプリ提供サーバ３は、携帯端末１にダウンロードさせるためのアプリのインストールプログラムを記憶し、携帯端末１からの要求に応じて送信する機能を有する。アプリ提供サーバ３としては、例えば、ｉＰｈｏｎｅ（登録商標）のａｐｐｓｔｏｒｅ（登録商標）や、ａｎｄｒｏｉｄ（登録商標）のｇｏｏｇｌｅ ｐｌａｙ（登録商標）等が用いられる。多くのアプリが集められたダウンロードサービスの他、特定のアプリのみを提供しているサーバであってもアプリ提供サーバ３として採用可能である。

次に、本実施形態に係る携帯端末１、広告管理サーバ２及びアプリ提供サーバ３等の情報処理装置のハードウエア構成について図２を参照して説明する。図２に示すように、本実施形態に係る情報処理装置は、一般的なサーバやＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等と同様の構成を含む。即ち、本実施形態に係る情報処理装置は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）４０及びＩ／Ｆ５０がバス８０を介して接続されている。また、Ｉ／Ｆ５０にはＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）６０及び操作部７０が接続されている。

ＣＰＵ１０は演算手段であり、情報処理装置全体の動作を制御する。ＲＡＭ２０は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、ＣＰＵ１０が情報を処理する際の作業領域として用いられる。ＲＯＭ３０は、読み出し専用の不揮発性記憶媒体であり、ファームウエア等のプログラムが格納されている。ＨＤＤ４０は、情報の読み書きが可能な不揮発性の記憶媒体であり、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や各種の制御プログラム、アプリケーション・プログラム等が格納される。

Ｉ／Ｆ５０は、バス８０と各種のハードウエアやネットワーク等を接続し制御する。ＬＣＤ６０は、ユーザが情報処理装置の状態を確認するための視覚的ユーザインタフェースである。操作部７０は、キーボードやマウス等、ユーザが情報処理装置に情報を入力するためのユーザインタフェースである。尚、本実施形態に係る広告管理サーバ２及びアプリ提供サーバ３は、ユーザが直接操作することの無いサーバとして運用されるため、ＬＣＤ６０や操作部７０等のユーザインタフェースは省略可能である。

このようなハードウエア構成において、ＲＯＭ３０に格納されたプログラムや、ＨＤＤ４０若しくは図示しない光学ディスク等の記憶媒体からＲＡＭ２０にロードされたプログラムに従ってＣＰＵ１０が演算を行うことにより、ソフトウエア制御部が構成される。このようにして構成されたソフトウエア制御部と、ハードウエアとの組み合わせによって、本実施形態に係る携帯端末１、広告管理サーバ２及びアプリ提供サーバ３の機能を実現する機能ブロックが構成される。

次に、本実施形態に係るシステム全体の動作について図３のシーケンス図に基づいて説明する。図３に示すシーケンス図は、携帯端末１において表示された広告に応じて携帯端末１にアプリがダウンロードされた場合に、ダウンロードに貢献した広告を表示したメディアアプリを特定するための情報が生成されて広告管理サーバ２に蓄積される際の動作を示す。

図３に示すように、携帯端末１においてメディアアプリが機能することにより、携帯端末１から広告管理サーバ２に対して広告要求が送信される（Ｓ３０１）。携帯端末１からの広告要求を受けた広告管理サーバ２は、要求元の携帯端末１に対して広告情報を送信する（Ｓ３０２）。要求に応じて広告情報を受信した携帯端末１においては、メディアアプリの機能により、受信した広告情報に基づいて広告が表示される（Ｓ３０３）。

携帯端末１においてメディアアプリ内に広告が表示されることにより、携帯端末１のユーザは広告が表示された部分をタップして広告によって告知されているアプリ、即ち、広告対象である対象プログラムのダウンロード画面にアクセスすることが可能となる。ユーザからの広告のタップを受け付けると（Ｓ３０４）、携帯端末１は、広告に埋め込まれたリンク機能により、リンク先のＵＲＬへアクセスする（Ｓ３０５）。本実施形態において広告に埋め込まれているリンクは、他のアプリをダウンロードするためのダウンロード画面にアクセスするためのＵＲＬへのリンクである。

また、携帯端末１は、広告のタップに応じて、広告がタップされたことを示す確認情報を生成する（Ｓ３０６）。Ｓ３０６において生成される情報が、後の処理において広告管理サーバ２に送信されることにより、アプリのダウンロードに貢献した広告表示を行ったメディアアプリを識別するための情報として用いられる。詳細は後述する。

携帯端末１からのＵＲＬアクセスを受け付けたアプリ提供サーバ３は、アクセスされたＵＲＬに応じたアプリのダウンロード画面の情報を携帯端末１に対して送信する（Ｓ３０７）。これにより、携帯端末１は、受信したダウンロード画面の情報に従ってダウンロード画面を表示する（Ｓ３０８）。

携帯端末１においてダウンロード画面が表示されることにより、携帯端末１のユーザは画面上に表示されたダウンロード要求のための操作部分をタップして、対象のアプリのダウンロード要求を行うことが可能となる。ユーザからのダウンロード要求のタップを受け付けると（Ｓ３０９）、携帯端末１は、ダウンロード画面の情報に埋め込まれたＵＲＬにアクセスすることにより、対象のアプリのダウンロード要求を行う（Ｓ３１０）。

携帯端末１からのダウンロード要求を受け付けたアプリ提供サーバ３は、アクセスされたＵＲＬに応じたアプリの送信を開始する（Ｓ３１１）。これにより、携帯端末１は対象のアプリをインストールするためのインストールプログラムのダウンロードを開始する（Ｓ３１２）。尚、Ｓ３１１においては、ユーザＩＤの確認やパスワード認証等が実行されることが一般的である。

その後、ダウンロードが完了すると（Ｓ３１３）、携帯端末１は、メディアアプリの機能により、Ｓ３０６において生成した確認情報を広告管理サーバ２に送信する（Ｓ３１４）。これにより、広告管理サーバ２は、携帯端末１から確認情報を受信して、記憶媒体に記憶させる（Ｓ３１５）。このような処理により、本実施形態に係るシステム全体の一連の動作が完了する。

このようにして蓄積されていく確認情報を解析することにより、どのようなアプリが、どのようなメディアアプリにおいて表示された広告をきっかけとしてダウンロードされているかを把握することが可能となる。このようなシステムの動作により、以下のようなメリットがある。

まず、携帯端末１から広告管理サーバ２に対して確認情報が送信されるのは、Ｓ３１２においてダウンロードが完了した後であり、それ以前には携帯端末１から広告管理サーバ２に対して何ら特別な処理を行っていない。従って、広告管理サーバ２に余分な負荷が発生することを防ぐことが可能であると共に、無駄なネットワーク負荷を発生させることもない。

メディアアプリによる広告表示の貢献度の測定のためには広告管理サーバ２においても何らかの処理を実行し、その結果負荷が発生することになる。しかしながら、スマートフォンやタブレット端末の普及に伴い、広告管理サーバ２は、数多くの携帯端末１に対して広告情報を送信する必要があり、そのための負荷も増大する傾向にある。従って、広告管理サーバ２の負荷は可能な限り軽減することが好ましい。

ここで、Ｓ３０５のタイミングは、ダウンロード画面に対するアクセスは実行されたが、未だダウンロードが開始されていないタイミングである。ユーザによる携帯端末１の操作の傾向として、ダウンロード画面にはアクセスしたが、ダウンロードの開始には至らないという場合もある。そのような場合が相当数あるという前提において、Ｓ３０５のタイミングで広告管理サーバ２やネットワークに負荷を発生させることは避けるべきであり、本実施形態に係るシステムにおいては、そのような課題が解決されている。

また、図３に示すように、アプリ提供サーバ３が担う機能は、ダウンロード画面の送信及びアプリのインストールプログラムの送信という一般的な機能であり、本件発明に際して何ら特別な処理を要求していない。そのため、既存のアプリダウンロードサービスにも適用可能である。

次に、図３に示す動作の各処理においてやり取りされる情報や、各処理を実現するための機能について説明する。まず、携帯端末１の機能や、処理される情報について説明する。図４は、本実施形態に係る携帯端末１の機能構成を示すブロック図である。図４に示すように、本実施形態に係る携帯端末１は、コントローラ１００、ユーザＩ／Ｆ１０１及びネットワークＩ／Ｆ１０２を含む。また、コントローラ１００は、ユーザＩ／Ｆ制御部１１０、ネットワーク制御部１２０、基本制御部１３０及び複数のメディアアプリ１４０を含む。

ユーザＩ／Ｆ１０１は、図２において説明したＬＣＤ６０及び操作部７０等、ユーザが携帯端末１を操作するためのインタフェースである。ネットワークＩ／Ｆ１０２は、携帯端末１がネットワークを介して他の機器と通信するためのインタフェースであり、Ｅｔｈｅｒｎｅｔ（登録商標）やＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インタフェースが用いられる。コントローラ１００は、ソフトウエアとハードウエアとの組み合わせによって構成され、携帯端末１全体を制御する制御部として機能する。

ユーザＩ／Ｆ制御部１１０は、コントローラ１００においてユーザＩ／Ｆ１０１を制御するための制御部であり、ＬＣＤ６０や、操作部７０を制御するためのドライバソフトウエアを含む。ネットワーク制御部１２０は、ネットワークＩ／Ｆ１０２を制御するための制御部であり、ハードウエアであるネットワークＩ／Ｆ１０２を制御するためのドライバソフトウエアを含む。

基本制御部１３０は、コントローラ１００において携帯端末１の基本的な機能を実現するためのソフトウエアモジュールであり、ＯＳやミドルウエア等の基本的なソフトウエアモジュールである。メディアアプリ１４０は、上述したように、広告管理サーバ２から広告情報を受信して広告を表示する機能を有するアプリケーション・プログラムによって構成され、アプリコアモジュール１４１、基本設定情報１４２及び広告管理ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）１５０を含む。

アプリコアモジュール１４１は、メディアアプリ１４０において元々のコアとなる機能を実現するためのソフトウエアモジュールであり、例えば、メディアアプリがゲームのアプリであれば、ゲーム機能を担う。また、メディアアプリがＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）閲覧用のアプリであれば、ＳＮＳ閲覧機能を担う。このメディアアプリが、広告を表示するための画面上の領域を提供している表示プログラムとして機能する。

基本設定情報１４２は、メディアアプリ１４０夫々の基本的な設定情報である。図５に示すように、本実施形態に係る基本設定情報は、メディアアプリ１４０を夫々識別する“メディアアプリＩＤ”、ユーザがメディアアプリ１４０のシステムにログインする際にユーザを識別するための識別情報として用いられる“ユーザＩＤ”を含む。即ち、“メディアアプリＩＤ”が、表示プログラム識別情報として機能する。

広告管理ＳＤＫ１５０は、メディアアプリ１４０において、広告管理サーバ２から広告情報を受信して広告を表示する機能を担うソフトウエアモジュールであり、広告情報処理部１５１、確認情報処理部１５２及びＤＬ（ＤｏｗｎＬｏａｄ）完了確認部１５３を含む。即ち、広告管理ＳＤＫ１５０が、広告情報管理プログラムとして用いられると共に、広告管理ＳＤＫ１５０が組み込まれたメディアアプリ１４０がインストールされた携帯端末１が広告表示装置として機能する。広告情報処理部１５１は、広告管理サーバ２からの広告情報の受信や、受信した広告情報に基づく広告の表示のための表示情報の生成等、広告情報に関する処理を行う。

具体的に、図３のＳ３０１においては、広告情報処理部１５１がネットワーク制御部１２０の機能を利用して広告管理サーバ２に対する広告情報の要求処理を実行する。また、広告情報処理部１５１は、広告管理サーバ２から送信された広告情報をネットワーク制御部１２０を介して取得する。図６は、本実施形態において広告を表示するための情報を含む広告情報の内容の例を示す図である。

図６に示すように、本実施形態員係る広告情報は、広告を識別するための広告識別情報である“広告ＩＤ”と、夫々の広告によって案内されるアプリを識別するための識別情報である“ＤＬ対象アプリＩＤ”と、案内されるアプリをダウンロードするためのダウンロード画面にアクセスするための“ＵＲＬ”と、メディアアプリのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）上において広告が表示される領域に広告として表示するための画像の情報である“広告画像情報”とを含む。“ＤＬ対象アプリＩＤ”が、対象プログラム識別情報として用いられる。

Ｓ３０３において、広告情報処理部１５１は、ユーザＩ／Ｆ制御部１１０に含まれるディスプレイドライバの機能を利用することにより、図６に示す“広告画像情報”に基づいて広告表示を実行する。図７は、本実施形態に係るメディアアプリ１４０のＧＵＩにおける広告表示の例を示す図である。

図７に示すように、携帯端末１にはＬＣＤ６０が表示部として搭載されており、ＬＣＤ６０の表面はタッチパネルである操作部７０として機能する。このような表示部兼操作部（以降、「表示操作部」とする）に表示されたメディアアプリ１４０のＧＵＩには、広告表示領域７０１が設けられている。広告情報処理部１５１による処理により、この広告表示領域７０１に“広告画像情報”に基づいた広告画像表示が行われる。

また、広告情報処理部１５１は、Ｓ３０４においてユーザＩ／Ｆ制御部１１０から広告の表示エリア、即ち、図７に示す広告表示領域７０１がタップされたことを示す通知を受けると、Ｓ３０５におけるＵＲＬアクセスのために、図６に示す“ＵＲＬ”の情報を出力する。

確認情報処理部１５２は、図３のＳ３０６において生成される確認情報に関する処理を行う。具体的に、Ｓ３０６においては、確認情報処理部１５２が確認情報を生成する。ここで、本実施形態に係る確認情報について図８を参照して説明する。

図８に示すように、本実施形態に係る確認情報は、夫々の確認情報の生成に際して、そのきっかけとなったＳ３０４のタップ操作においてタップされた広告を識別する“広告ＩＤ”、タップされた広告が表示されていた広告表示領域７０１のＧＵＩを提供したメディアアプリを識別する“メディアアプリＩＤ”、その広告において告知されていたアプリ、即ちダウンロード対象のアプリを識別する“ＤＬ対象アプリＩＤ”、タップ操作を受け付けた“日時”、タップ操作を行ったユーザを識別する“ユーザＩＤ”の情報を含む。

従って、確認情報においては、広告をタップすることによってダウンロード画面が要求された場合に、タップされた広告を識別するための広告識別情報と、広告対象であるプログラムを識別する対象プログラム識別情報と、広告が表示される領域を提供する表示プログラムを識別する表示プログラム識別情報と、日時の情報と、表示プログラムにおいてユーザを識別するためのユーザ識別情報とが関連付けて記憶されている。即ち、確認情報処理部１５２が、関連付け情報記憶処理部として機能する。

確認情報処理部１５２は、Ｓ３０６において、図６の“広告ＩＤ”及び“ＤＬ対象アプリＩＤ”を広告情報から取得して、図８に示す確認情報の“広告ＩＤ”及び“ＤＬ態様アプリＩＤ”とする。また、図５の“メディアアプリＩＤ”及び“ユーザＩＤ”を基本設定情報から取得して、図８に示す確認情報の“メディアアプリＩＤ”及び“ユーザＩＤ”とする。また、Ｓ３０４における実際の時刻を取得し、図８に示す確認情報の“タップ日時”とする。

また、確認情報処理部１５２は、Ｓ３１４において、ネットワーク制御部１２０の機能を用いることにより、広告管理サーバ２に対して確認情報を送信する。即ち、確認情報処理部１５２は、情報出力部としても機能する。そのため、確認情報処理部１５２は、確認情報を送信するために必要なネットワークアドレス等の情報を予め記憶している。但し、確認情報を送信するために必要な情報は、例えば図６において説明した広告情報に含まれても良い。

ＤＬ完了確認部１５３は、図３のＳ１３１３におけるダウンロードの確認処理を行うダウンロード確認部である。図９は、ＤＬ完了確認部１５３によるダウンロード確認処理の詳細な動作を示すフローチャートである。図９に示すように、ＤＬ完了確認部１５３は、まず、上述したように図３のＳ３０６において生成された確認情報を選択する（Ｓ９０１）。ここで、広告管理ＳＤＫ１５０において生成される確認情報の態様について図１０を参照して説明する。

図３においては、広告表示、広告タップ、確認情報生成、ダウンロード開始、ダウンロード確認といった処理が一連となって説明されているが、上述したように、確認情報は広告がタップされた時点で生成されるため、図１０に示すように、広告管理ＳＤＫ１５０において複数の確認情報が生成されることとなる。従って、図３のＳ３０６の処理に際して、確認情報処理部１５２は、同一の“広告ＩＤ”を有する確認情報を過去に生成していないかを確認し、同一の“広告ＩＤ”を有する確認情報が既に生成されていれば、図３のＳ３０６の処理を省略することが好ましい。

尚、図１０においては、広告管理ＳＤＫ１５０内部に確認情報が生成されて記憶されているように示しているが、実際には、広告管理ＳＤＫ１５０によって認識されているＨＤＤ４０内部の記憶領域等に記憶される。

ユーザによる広告のタップ操作に応じて、図１０に示すように複数の確認情報が生成されるため、ＤＬ完了確認部１５３は、Ｓ９０１において、複数生成される確認情報から１つを選択する。確認情報を１つ選択したＤＬ完了確認部１５３は、選択した確認情報の“タップ日時”を参照し、その確認情報が有効期限内であるか否かを確認する（Ｓ９０２）。Ｓ９０２の処理の意義は、広告のタップ操作と、アプリのダウンロードとの関連性の確認である。例えば、図３のＳ３０４のタイミングから１年が経過した後に、その広告に対応するアプリがダウンロードされてインストールされたとしても、そのダウンロードは広告効果が発揮された上でのダウンロードである可能性は低い。

従って、本実施形態に係るＤＬ完了確認部１５３は、夫々の確認情報に対応するアプリのダウンロード完了の確認に際して、夫々の確認情報の有効性を“タップ日時”に基づいて確認する。Ｓ９０２における有効期限は、例えば“タップ日時”から１か月であるが、この期間は、広告効果が発揮されたことを判断するための期間として任意に設定可能である。

Ｓ９０２の判断の結果、有効期限ないではなかった場合（Ｓ９０２／ＮＯ）、ＤＬ完了確認部１５３は、選択中の確認情報が無効であるとして記憶媒体から削除する（Ｓ９０４）。他方、有効期限内であった場合（Ｓ９０２／ＹＥＳ）、ＤＬ完了確認部１５３は、携帯端末１にインストールされているアプリ（以降、「インストール済みアプリ」とする）の一覧を取得する（Ｓ９０３）。インストール済みアプリの一覧は、例えば基本制御部１３０の機能によって生成され、メディアアプリ１４０が基本制御部１３０から情報を取得することにより、ＤＬ完了確認部１５３によって参照可能である。

尚、本実施形態に係るインストール済みアプリ一覧においては、図６や図８において説明した“ＤＬ対象アプリＩＤ”に対応するＩＤが記述されている。従って、ＤＬ完了確認部１５３は、図８に示す“ＤＬ対象アプリＩＤ”とインストール済みアプリ一覧に記述されたＩＤとを比較することにより、確認情報において対象となっているダウンロード対象のアプリが、既に携帯端末１にインストールされているか否かを確認することが出来る。

インストール済みアプリ一覧を取得したＤＬ完了確認部１５３は、選択中の確認情報の“ＤＬ対象アプリＩＤ”及びインストール済みアプリ一覧を比較し、一致するものを検索する（Ｓ９０５）。その結果、一致するものがあった場合（Ｓ９０５／ＹＥＳ）、選択中の確認情報が対象としてダウンロード対象のアプリは既にダウンロードされてインストールされていると判断し、ダウンロードが完了したことを示すＤＬ完了イベントを生成する（Ｓ９０６）。

Ｓ９０６の処理により、図３のＳ３１３の処理が実現される。その結果、選択中の確認情報が、図３のＳ３１４において広告管理サーバ２に送信されることとなる。尚、図３のＳ３１４において確認情報の送信が完了した後、確認情報処理部１５２は、送信した確認情報を携帯端末１の記憶媒体から削除することが好ましい。これにより、以降に図９の動作が再度実行された場合に、既に送信されている確認情報が再度送信されてしまうことを防ぐことが出来る。この他、送信済みであることを示すフラグ情報を付すことにより、既に送信された確認情報が図９のＳ９０１において選択されないようにしても良い。

他方、一致するものがなければ（Ｓ９０５／ＮＯ）、ＤＬ完了確認部１５３は次の処理に進む。Ｓ９０６におけるＤＬ完了イベントの生成、Ｓ９０５において一致するものがなかった場合、Ｓ９０４における確認情報の削除の処理の後、ＤＬ完了確認部１５３は、図１０に示すように複数生成されている確認情報の全てについてＳ９０１からの処理を行ったかを確認する（Ｓ９０７）。

そして、ＤＬ完了確認部１５３は、確認情報の全てについて処理を完了するまで、Ｓ９０１からの処理を繰り返し（Ｓ９０７／ＮＯ）、生成された全ての確認情報の選択を完了したら（Ｓ９０７／ＹＥＳ）、ダウンロード確認の動作を完了する。このような処理により、本実施形態に係るダウンロード確認の動作が完了する。

尚、図９においては、確認情報の有効期限の確認処理や、有効期限の切れた確認情報の削除処理を、ダウンロード完了の確認動作に組み込んでいるが、他の処理としても良い。例えば、確認情報処理部１５２が、図９のＳ９０２及びＳ９０４の処理を定期的に実行するようにしても良い。

図９に示すような動作は、メディアアプリ１４０の動作中におけるあらゆるタイミングで実行される。図１１は、図９に示す動作（以降、「ＤＬ確認動作」とする）の実行タイミングを示すフローチャートである。図１１においては、携帯端末１において、アプリが起動された後、バックグラウンド化されるまでのＤＬ確認動作の実行判断が示されている。尚、アプリのバックグラウンド化とは、携帯端末１において、基本制御部１３０によるタスク上には残っているが、ＧＵＩが表示されていない状態を示す。

図１１に示すように、メディアアプリ１４０が起動すると（Ｓ１１０１）、起動時の処理としてＤＬ完了確認部１５３が図９に示すＤＬ確認動作を実行する（Ｓ１１０２）。その後、ＤＬ完了確認部１５３は、所定期間のカウントを開始し（Ｓ１１０３）、設定された所定期間の経過をカウントすると（Ｓ１１０４／ＹＥＳ）、カウンタをリセットして（Ｓ１１０５）、ＤＬ確認動作を実行する（Ｓ１１０６）。

Ｓ１１０３の処理は、定期的にＤＬ確認動作を実行するためのカウントである。ＤＬ確認動作を定期的に実行する際の周期は任意の期間を設定可能であるが、例えば１分毎である。他方、基本制御部１３０の機能により、携帯端末１に新規にアプリがダウンロードされてインストールされた場合には、その旨を示す通知（以降、「新規インストール通知」とする）を受け取ることが可能である。この場合、基本制御部１３０が、新規ダウンロード通知部として機能する。従って、新規インストール通知を受けた場合にも（Ｓ１１０７／ＹＥＳ）、ＤＬ完了確認部１５３は、ＤＬ確認動作を実行する（Ｓ１１０８）

尚、Ｓ１１０８におけるＤＬ確認動作は、新規にアプリがインストールされた場合における確認動作であるため、新規にインストールされたアプリについてのみ確認を行っても良い。その場合、図９のＳ９０３においてはインストール済みアプリ一覧を取得するのではなく、新規にインストールされたアプリのＩＤを取得し、そのＩＤと確認情報における“ＤＬ対象アプリＩＤ”とが一致するか否かをＳ９０５において確認すれば良い。

ＤＬ完了確認部１５３は、メディアアプリ１４０がバックグラウンド化されるまで、Ｓ１１０４からの処理を繰り返し実行する（Ｓ１１０９／ＮＯ）。その後、メディアアプリ１４０がバックグラウンド化されると（Ｓ１１０９／ＹＥＳ）、ＤＬ完了確認部１５３は、メディアアプリ１４０がバックグラウンド化された状態でＤＬ確認動作を実行する（Ｓ１１１０）。

ＤＬ完了確認部１５３は、メディアアプリ１４０がバックグラウンド化された後、設定されたチェックループ期間が完了するまで、繰り返しＤＬ確認動作を実行し（Ｓ１１１１／ＮＯ）、チェックループ期間が完了すると（Ｓ１１１１／ＹＥＳ）、処理を終了する。このように、本実施形態に係るＤＬ完了確認部１５３は、メディアアプリ起動時、所定期間経過時、新規インストール通知時、バックグラウンド化後のチェックループ期間において、ＤＬ確認動作を実行する。

次に、本実施形態に係る広告管理サーバ２の機能について説明する。図１２は、本実施形態に係る広告管理サーバ２の機能構成を示すブロック図である。図１２に示すように、本実施形態に係る広告管理サーバ２は、広告管理コントローラ２００及びネットワークＩ／Ｆ２０１を含む。また、広告管理コントローラ２００は、広告配信部２１０、広告情報ＤＢ２１１、確認情報記憶処理部２２０、確認情報ＤＢ２２１及びユーザ情報ＤＢ２２２を含む。

ネットワークＩ／Ｆ２０１は、広告管理サーバ２がネットワークを介して他の機器と通信するためのインタフェースであり、Ｅｔｈｅｒｎｅｔ（登録商標）やＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インタフェースが用いられる。広告管理コントローラ２００は、ソフトウエアとハードウエアとの組み合わせによって構成され、広告管理サーバ２全体を制御する制御部として機能する。

広告配信部２１０は、図３のＳ３０１において送信された広告要求をネットワークＩ／Ｆ２０１を介して取得し、Ｓ３０２において、広告情報ＤＢ２１１に記憶されている広告情報を取得して要求元の携帯端末１に対して送信する。広告情報ＤＢ２１１は、図６において説明した広告情報が複数蓄積されたデータベースである。従って、広告配信部２１０は、広告情報ＤＢ２１１に記憶されている複数の広告情報から１つを選択して、Ｓ３０２において送信する。

広告配信部２１０による広告情報の選択は、Ｓ３０１において送信される広告要求において具体的に広告ＩＤが特定されていても良いし、広告配信部２１０が、要求元の携帯端末１におけるメディアアプリ１４０の種類に応じた広告を選択するようにしても良い。また、ランダムで１つの広告が選択されても良い。

確認情報記憶処理部２２０は、図３のＳ３１４において広告管理サーバ２に送信された確認情報をネットワークＩ／Ｆ２０１を介して取得し、確認情報ＤＢ２２１に記憶させる。確認情報ＤＢ２２１は、図８において説明した確認情報を蓄積して記憶しているデータベースである。従って、確認情報ＤＢ２２１に蓄積されている確認情報を解析することにより、どのようなメディアアプリが、どのようなアプリのダウンロードに貢献しているかを把握することができる。

ユーザ情報ＤＢ２２２は、識別子としては異なるが、実際には同一のユーザを示している異なる複数のユーザＩＤを、同一ユーザを示すものとして関連付けているデータベースである。ユーザ情報ＤＢ２２２は、確認情報記憶処理部２２０が、重複した確認情報を識別して整理するために用いられる。ここで、まず重複した確認情報が発生する要因について説明する。

図１３は、重複した確認所法が生成される態様を示す図である。図３において説明したように、確認情報は広告がタップされた時点で生成される。これは、広告に対するタップ操作は、メディアアプリ１４０上での操作であるため、メディアアプリ１４０に組み込まれている広告管理ＳＤＫ１５０において認識することが可能であるが、広告がタップされることにより表示されたダウンロード画面はメディアアプリ１４０上での操作ではないため、広告管理ＳＤＫ１５０はそれを検知することができず、ダウンロード画面でのダウンロード開始をトリガとして認識することが出来ないからである。

従って、図１３に示すように、複数のメディアアプリ１４０において同一のＤＬ対象アプリについての広告が表示され、夫々タップ操作が行われたものの、ダウンロード画面において実際のダウロード要求には至らなった場合、夫々のメディアアプリ１４０毎に、同一のＤＬ対象アプリＩＤが設定された確認情報が生成され、結果的に１つの携帯端末１において重複した確認情報が複数生成されることとなる。

このように確認情報が複数生成された状態において、その後に、そのＤＬ対象アプリがダウンロードされてインストールされた場合、確認情報の有効期限内に夫々のメディアアプリ１４０において図９に示すＤＬ確認動作が実行されると、夫々のメディアアプリ１４０が個別に広告管理サーバ２に対して確認情報を送信することとなる。

ここで、図８において説明したように、確認情報には、メディアアプリ１４０にログインするためのユーザＩＤが含まれる。そのため、複数の確認情報において、ＤＬ対象アプリＩＤが同一であり、且つユーザＩＤも同一であれば、上述したように重複した確認情報が個別に広告管理サーバ２に送信されたとしても広告管理サーバ２側で重複を判断することが可能である。

しかしながら、同一のユーザを示すユーザＩＤであっても、メディアアプリ毎に異なるユーザＩＤが用いられることが多い。そのため、異なるメディアアプリについてのユーザＩＤをそのまま比較しても、上述した重複した確認情報を判断することはできない。このような課題を解決するためにユーザ情報ＤＢ２２２が用いられる。

図１４は、本実施形態に係るユーザ情報ＤＢ２２２によるユーザ情報の関連付けの概念を示す図である。図１４に示すように、本実施形態に係るユーザ情報ＤＢ２２２においては、メディアアプリごとに異なる複数のユーザＩＤ（以降、「アプリユーザＩＤ」とする）が、ユーザ１人に対して一意である基本となるユーザＩＤ（以降、「ベースユーザＩＤ」とする）に関連付けられる構成となっている。このベースユーザＩＤは、専用に作りこまれたメディアアプリ（以降、「ベースメディアアプリ」とする）のユーザＩＤとしても用い荒れる。

ここで、通常のメディアアプリと、ベースメディアアプリとの違いについて説明する。メディアアプリとは、上述したように広告管理サーバ２との通信により広告を表示する機能を有するアプリであり、図４において説明した広告管理ＳＤＫ１５０が組み込まれることによって実現される。これに対して、ベースメディアアプリとは、広告管理ＳＤＫ１５０のみならず、アプリコアモジュール１４１側にも、広告管理に対応した機能が組み込まれており、より広告管理サーバ２との連携が強められているアプリである。

図１４の例の場合、メディアアプリＡ、メディアアプリＢ、メディアアプリＣ及びベースメディアアプリは夫々別個のアプリであり、“Ａｕｓｅｒ００１”、“Ａｕｓｅｒ００２”、“Ａｕｓｅｒ００３”、“Ｂｕｓｅｒ００１”という別個のユーザＩＤが用いられる。そして、“Ａｕｓｅｒ００１”、“Ａｕｓｅｒ００２”、“Ａｕｓｅｒ００３”は、“Ｂｕｓｅｒ００１”に関連付けられており、この関連付けにより、“Ａｕｓｅｒ００１”、“Ａｕｓｅｒ００２”、“Ａｕｓｅｒ００３”夫々によって識別されるユーザが、“Ｂｕｓｅｒ００１”によって識別されるユーザと同一であることが識別可能となる。

図１５は、図１４に示す関連付けに対応するユーザ情報ＤＢ２２２のテーブル構成を示す図である。図１５に示すように、ユーザ情報ＤＢ２２２においては、“アプリユーザＩＤ”を主キーとして、そのアプリユーザＩＤが対応しているメディアアプリを示す“メディアアプリＩＤ”と、そのアプリユーザＩＤによって識別されるユーザと同一のユーザを識別するための“ベースユーザＩＤ”とが関連付けられている。

図１６は、本実施形態に係る確認情報記憶処理部２２０が、重複した確認情報を識別して整理する際の動作を示すフローチャートである。図１６に示すように、確認情報記憶処理部２２０は、図８に示す確認情報が蓄積された確認情報ＤＢ２２１を参照し、１つの“ＤＬ対象アプリＩＤ”を選択し（Ｓ１６０１）、選択した“ＤＬ対象アプリＩＤ”確認情報ＤＢ２２１に格納された確認情報を絞り込んで（Ｓ１６０２）、選択した“ＤＬ対象アプリＩＤ”を有する確認情報を抽出する。

次に、確認情報記憶処理部２２０は、抽出した確認情報に含まれる“ユーザＩＤ”について、アプリユーザＩＤをベースユーザＩＤに変換する処理を行う（Ｓ１６０３）。これにより、例えば図１４に示す“Ａｕｓｅｒ００１”、“Ａｕｓｅｒ００２”、“Ａｕｓｅｒ００３”は、“Ｂｕｓｅｒ００１”に変換される。

ユーザＩＤの変換処理を終えると、確認情報記憶処理部２２０は、ユーザＩＤの一致の有無を確認する（Ｓ１６０４）。例えば図１４に示す状態であった場合、“Ａｕｓｅｒ００１”、“Ａｕｓｅｒ００２”、“Ａｕｓｅｒ００３”は、“Ｂｕｓｅｒ００１”に変換されているため、“Ｂｕｓｅｒ００１”というユーザＩＤが４つとなり、一致有と判断される。

Ｓ１６０４の判断の結果、一致があった場合（Ｓ１６０４／ＹＥＳ）、確認情報記憶処理部２２０は、ユーザＩＤが一致している複数の確認情報について、残すべき確認情報を選択する処理を行う（Ｓ１６０５）。Ｓ１６０５の処理は、一のＤＬ対象アプリについて、複数のメディアアプリを介してユーザに対して広告が表示されている現状において、いずれのメディアアプリについて広告効果を認めるかを判断する処理に等しい。

従って、Ｓ１６０５の処理は、用途に応じた様々なアルゴリズムにより実現される。例えば、一のユーザに対して、最初に特定のアプリを告知できたメディアアプリが最も広告効果を発揮したメディアアプリであると判断する場合には、“タップ日時”が最も古い確認情報を残し、それ以外は削除するという処理を行う。

また、実際のダウンロードに直接的に寄与したメディアアプリが最も広告効果を発揮したメディアアプリである判断する場合には、“タップ日時”が最も新しい確認情報を残し、それ以外は削除するという処理を行う。Ｓ１６０５の処理が完了した場合、若しくはユーザＩＤの一致がなかった場合（Ｓ１６０４／ＮＯ）、確認情報記憶処理部２２０は、確認情報ＤＢ２２１に蓄積されている確認情報に含まれる“ＤＬ対象アプリＩＤ”をすべて選択し終えたか否かを確認する（Ｓ１６０６）。

そして確認情報記憶処理部２２０は、選択可能な“ＤＬ対象アプリＩＤ”をすべて選択し終えるまでＳ１６０１からの処理を繰り返し（Ｓ１６０６／ＮＯ）、すべて選択し終えたら（Ｓ１６０６／ＹＥＳ）、処理を終了する。このような処理により、本実施形態に係る確認情報記憶処理部２２０による、重複した確認情報の整理動作が完了する。

以上説明したように、本実施形態に係るシステムにおいては、携帯端末１にインストールされたメディアアプリ１４０に組み込まれている広告管理ＳＤＫ１５０の機能により、携帯端末１に新たにアプリがインストールされて初めて広告管理サーバ２に対して確認情報を送信する。そのため、実際にはダウンロードが行われない場合にも確認情報を送信してしまうような処理を防ぐことが可能であり、無駄なネットワーク負荷の発生や無駄な情報記憶の発生を防ぐことができ、新たなアプリのダウンロードに貢献したメディアアプリの特定を効率的に行うことが可能となる。

尚、上記実施形態においては、図３のＳ３０６のタイミング、即ち、ＤＬ対象アプリのダウンロード画面を要求したタイミングにおいて図８に示す確認情報が生成され、その確認情報が図３のＳ３１４において送信される場合を例として説明した。ここで、確認情報は上述したように広告管理サーバ２に蓄積されて、広告効果の解析に用いることが可能であるが、元々は、図９において説明したように、新たにアプリがインストールされたされた場合に、そのアプリが広告に基づいてインストールされたものであるか否かを判断するための情報である。

従って、図３のＳ３１４において送信される情報は、図８に示す確認情報そのものでなくともよく。広告管理サーバ２において、どのようなメディアアプリが、どのようなＤＬ対象アプリのダウンロードに貢献しているかを判断可能な情報であればよい。但し、“ユーザＩＤ”や“タップ日時”を含むことにより、図１６において説明したような、実質的に同一なユーザの確認情報を識別することが可能となる。また、“タップ日時”を含むことにより、時系列の変化を解析することも可能となる。

実施の形態２．
実施の形態１においては、図１３において説明したように、同一のＤＬ対象アプリについての広告が異なる複数のメディアアプリで表示され、複数の確認情報が生成された場合に、生成された確認情報が夫々広告管理サーバ２に送信され、広告管理サーバ２側において重複チェックをする場合を例として説明した。

これに対して、携帯端末１側で予め重複を排除することも可能である。その場合、広告管理サーバ２において実行するべき処理を削減可能となり、広告管理サーバ２の処理負荷を更に低減することが出来る。例えば、上述したＳ１６０５の処理の１つの方針として実際のダウンロードに直接的に寄与したメディアアプリが最も広告効果を発揮したメディアアプリである判断する場合、最新の確認情報のみを残しておけば良いことは、上述した通りである。

その場合、図３のＳ３０６において、確認情報処理部１５２が確認情報を生成した際に、他のメディアアプリの確認情報を削除することにより、同様の効果を得ることが可能である。図１７は、そのような場合の動作を示すフローチャートである。図１７の動作は、図３のＳ３０６の処理に応じて実行される動作である。

図１７に示すように、確認情報処理部１５２は、図３のＳ３０６において確認情報を生成すると、他のメディアアプリ１４０において生成済みである確認情報を参照する（Ｓ１７０１）。上述したように、同一のメディアアプリ１４０において生成した確認情報については、確認情報の生成時に確認することが好ましく、ここでは他のメディアアプリ１４０において生成された確認情報を対象とする。

他のメディアアプリにおいて生成された確認情報を参照すると、確認情報処理部１５２は、今回新たに生成した確認情報の“広告ＩＤ”で絞り込みを行い、同一の“広告ＩＤ”を有する確認情報を抽出する（Ｓ１７０２）。その結果、一致するものが抽出された場合（Ｓ１７０３）、確認情報処理部１５２は、その抽出された確認情報を削除する（Ｓ１７０４）。このような処理により、１つの携帯端末１において同一の“広告ＩＤ”を有する確認情報が生成される場合には、常に最新の確認情報のみが残されることとなる。

その結果、その確認情報における“ＤＬ対象アプリＩＤ”によって識別されるアプリがダウンロードされてインストールされた後に図９の動作が実行された場合、広告管理サーバ２に対して送信される確認情報は、最新の確認情報１つのみとなる。その結果、広告管理サーバ２において確認情報の重複チェックを行う必要がなくなり、負荷を低減することが可能となる。

実施の形態３．
実施の形態１においては、図９に示すＤＬ確認動作が実行されるタイミングとして、図１１に示すフローチャートを例として説明した。しかしながら、図１１に示す例の場合、図３のＳ３１０においてＤＬ要求を行われ、Ｓ３１２においてダウンロードが開始された後、そのメディアアプリがバックグラウンド化してループ期間が経過する前にダウンロードおよびインストールが完了せず、且つ、その後にそのメディアアプリが起動されなかった場合には、永遠に確認情報が送信されないこととなってしまう。

例えば、携帯端末１において新たにアプリがダウンロードされてインストールされたことをトリガとして、各メディアアプリをバックグラウンドで起動することが可能であれば、図１１のＳ１１０２によりＤＬ確認動作が実行されるため、そのような課題は解決可能である。しかしながら、そのようなアプリの起動は一般的には図４に示す基本制御部１３０や、アプリコアモジュール１４１の機能に依存する。そのため、広告管理ＳＤＫ１５０の配布によりシステムを普及させる場合には、そのような手法を用いることはできない。

これに対して、一般的なメディアアプリ１４０はそのような機能に対応していなかったとしても、アプリコアモジュール１４１の機能まで広告管理ＳＤＫ１５０や広告管理サーバ２との連携を前提として作りこむベースメディアアプリの機能を用いることにより、上述した課題を解決することが可能となる。本実施形態においては、そのような態様について説明する。

図１８は、本実施形態に係る携帯端末１の機能構成を示すブロック図である。図１８に示すように、本実施形態に係る携帯端末１は、図４において説明した構成に加えて、ベースメディアアプリ１６０が追加された構成となっている。ベースメディアアプリ１６０は、アプリコアモジュール１６１及び基本設定情報１６２に加えて、広告管理ＳＤＫ１７０を含む。

ベースメディアアプリ１６０も、メディアアプリ１４０と同様に、広告管理ＳＤＫ１７０の機能により広告管理サーバ２と通信することによってＧＵＩ上の広告表示領域７０１に広告表示を行う機能を有する。そのため、広告管理ＳＤＫ１７０は、広告管理ＳＤＫ１５０と同様に広告情報処理部１５１、確認情報処理部１５２及びＤＬ完了確認部１５３を含む。更に、ベースメディアアプリ１６０に組み込まれる広告管理ＳＤＫ１７０は、確認情報収集部１７１を含む。

本実施形態に係るベースメディアアプリ１６０のアプリコアモジュール１６１は、携帯端末１において新たにアプリがダウンロードされてインストールされた場合に、基本制御部１３０からの通知に応じてバックグラウンドで起動する機能を有する。そのため、携帯端末１において新たにアプリがダウンロードされてインストールされた場合、ベースメディアアプリ１６０に組み込まれた広告管理ＳＤＫ１７０の処理として、図１１のＳ１１０２においてＤＬ確認動作が実行されることとなる。

しかしながら、実施の形態１において説明した広告管理ＳＤＫ１５０の機能によれば、ベースメディアアプリ１６０に組み込まれた広告管理ＳＤＫの処理としてＤＬ確認動作が実行されたとしても、その結果広告管理サーバ２に送信される確認情報は、ベースメディアアプリ１６０のＧＵＩにおいて表示された広告がタップされて生成された確認情報のみであり、メディアアプリ１４０に組み込まれた広告管理ＳＤＫ１５０において生成された確認情報は送信されない。

そのため、本実施形態に係る広告管理ＳＤＫ１７０は、広告管理ＳＤＫ１５０と同一の機能に加えて、確認情報収集部１７１を有する。確認情報収集部１７１は、図１９に示すように、他のメディアアプリ１４０に組み込まれた広告管理ＳＤＫ１５０において生成された確認情報を複製し、広告管理ＳＤＫ１７０において生成された確認情報と同様に記憶媒体に記憶させる。これにより、広告管理ＳＤＫ１７０の処理として図９に示すＤＬ確認動作が実行される場合、他のメディアアプリ１４０において生成された確認情報も、Ｓ９０１において選択対象の候補となる。

尚、図１９に示す確認情報の複製処理は、確認情報を生成した側の確認情報処理部１５２が主体となって実行され、確認情報収集部１７１は、確認情報を生成した確認情報処理部１５２から、複製された確認情報を取得して記憶媒体に記憶する。この他、確認情報収集部１７１が、他のメディアアプリ１４０における確認情報の生成有無を監視し、他のメディアアプリ１４０において確認情報が生成された場合に、その複製情報を生成するようにしても良い。

このような態様により、仮に確認情報を生成したメディアアプリ１４０が、その後に起動されなかったとしても、ベースメディアアプリ１６０に複製された確認情報がベースメディアアプリ１６０によって送信されるため、広告管理サーバ２に確認情報が送信されなくなる問題を解消することが可能である。

これに対して、メディアアプリ１４０とベースメディアアプリ１６０との両方から確認情報が送信される可能性があるという問題が生じる。この問題は、例えば、広告管理サーバ２側において重複チェックをすることにより解消可能である。重複チェックの態様としては、図１６において説明した動作と同様の動作により実現可能であるが、確認情報の複製に特有な情報を付加することにより、図１６よりも更に簡易な処理でチェックが可能である。

図２０は、確認情報の複製に特有な情報を付加する場合の一態様を示す図である。携帯端末１側における確認情報の複製に際して、図２０に示すように乱数を生成し、複製元及び複製先の夫々の確認情報に付加する。そして、その両方が広告管理サーバ２に送信された場合、広告管理サーバ２の確認情報記憶処理部２２０は、付加されている乱数が一致するか否かを確認することにより、複製された確認情報であることを認識し、いずれか一方を削除して重複した確認情報を排除することが可能となる。

他方、携帯端末１側のみで、重複した確認情報の送信を排除する方法もある。具体的には、図３のＳ３１４において確認情報を送信する際に、複製されている確認情報を削除する方法である。そのような動作について説明する。図２１、図２２は、図９において説明したＤＬ確認動作によってＤＬ完了イベントが生成され、確認情報が送信される際の、ベースメディアアプリ１６０とメディアアプリ１４０との相対的な動作の例を示すシーケンス図である。

図２１は、メディアアプリ１４０が起動状態若しくは図１１のＳ１１１１において判断されるループ期間内であり、新たにアプリがインストールされた後、比較的早い段階でメディアアプリ１４０によって確認情報が送信される場合の動作を示している。図２１に示すように、新規にアプリがインストールされたことが基本制御部１３０によって通知されると（Ｓ２１０１）、上述したようにベースメディアアプリ１６０はアプリコアモジュール１６１の機能によってバックグラウンド起動し（Ｓ２１０２）、図１１において説明した動作により、ＤＬ確認動作が実行されることとなるが、本実施形態に係るベースメディアアプリ１６０に組み込まれた広告管理ＳＤＫ１７０のＤＬ完了確認部１５３は、バックグラウンド起動後、ＤＬ完了確認動作の実行を待機する（Ｓ２１０３）。

Ｓ２１０３における待機は、メディアアプリ１４０が確認情報を送信可能な状態である場合に、その送信処理の完了を待つための待機である。従って、待機期間は、確認情報の送信処理に要する時間に応じて定められる。具体的には、例えば、図１１のＳ１１０４において判断される所定期間分等の期間を用いることも可能である。

また、図２１においては、新規インストールが発生して、ベースメディアアプリ１６０がバックグラウンド起動する場合を例としているが、ベースメディアアプリが起動中であり、図１１のＳ１１０７の判断によりＳ１１０８においてＤＬ確認動作が実行される場合もあり得る。そのような場合も同様に、メディアアプリ１４０における確認情報の送信処理に対応する期間待機する。

メディアアプリ１４０においては、新規インストールが発生した後、図１１のＳ１１０７や、Ｓ１１０４の判断によりＤＬ確認動作が実行される（Ｓ２１０６）。その結果、図９のＳ９０６においてＤＬ完了イベントが生成され、確認情報処理部１５２によって確認情報が広告管理サーバ２に送信されることとなる。そして、メディアアプリ１４０においては、ベースメディアアプリ１６０に複製されている確認情報の削除を行う（Ｓ２１０７）。

Ｓ２１０７の処理は、例えば、図２０において説明したように、乱数の一致を判断することによって行われるが、そのほか、図８に示す各項目が同一であることをもって判断しても良い。他方、ベースメディアアプリ１６０においては、ＤＬ確認動作の実行を待機する期間が満了した後、ＤＬ確認動作が実行される（Ｓ２１０４）。しかしながら、待機期間中に、メディアアプリ１４０の処理によって確認情報が削除されているため、このＤＬ確認動作によっては図９のＳ９０６のＤＬ完了イベントは発生しない。結果的に、確認情報はメディアアプリ１４０からのみ送信されることとなる。

図２２は、メディアアプリ１４０が起動状態ではなく、且つＳ１１１１において判断されるループ期間も経過しており、次にメディアアプリ１４０が起動されるまで、メディアアプリ１４０によっては確認情報が送信されない場合の動作を示している。Ｓ２２０１〜Ｓ２２０３までの処理は、図２１のＳ２１０１〜Ｓ２１０３と同様である。図２２の場合、メディアアプリ１４０は動作していないため、図２１において説明したメディアアプリ１４０による確認情報削除処理は発生しない。

そのため、ベースメディアアプリ１６０において、ＤＬ確認動作の実行を待機する期間が満了した後、ＤＬ確認動作が実行されると（Ｓ２１０４）、図９のＳ９０６においてＤＬ完了イベントが生成され、ベースメディアアプリ１６０に組み込まれた広告管理ＳＤＫ１７０によって確認情報が広告管理サーバ２に送信されることとなる。そして、ベースメディアアプリ１６０においては、ＤＬ完了イベントの要因となった確認情報の複製元である、メディアアプリ１４０において記憶されている確認情報の削除を行う（Ｓ２２０５）。

Ｓ２２０５の処理は、図２１のＳ２１０７の処理と同様に実行される。その後、メディアアプリ１４０がユーザの操作に応じて起動され、ＤＬ確認動作が実行されたとしても、対象の確認情報は既に削除されているため、このＤＬ確認動作によっては図９のＳ９０６のＤＬ完了イベントは発生しない。結果的に、確認情報はベースメディアアプリ１６０からのみ送信されることとなる。

このように、本実施形態に係るシステムによれば、携帯端末１におけるメディアアプリ１４０の起動状況により、確認情報が広告管理サーバ２に送信されなくなる状態を防ぐことが可能となる。また、ベースメディアアプリ１６０に複製された確認情報とメディアアプリ１４０で生成された元の確認情報とのいずれかのみが広告管理サーバ２に送信されるようにすることにより、広告管理サーバ２における負荷を低減することが可能となる。

１ 携帯端末
２ 広告管理サーバ
３ アプリ提供サーバ
１０ ＣＰＵ
２０ ＲＡＭ
３０ ＲＯＭ
４０ ＨＤＤ
５０ Ｉ／Ｆ
６０ ＬＣＤ
７０ 操作部
８０ バス
１００ コントローラ
１０１ ユーザＩ／Ｆ
１０２ ネットワークＩ／Ｆ
１１０ ユーザＩ／Ｆ制御部
１２０ ネットワーク制御部
１３０ 基本制御部
１４０ メディアアプリ
１４１ アプリコアモジュール
１４２ 基本設定情報
１５０ 広告管理ＳＤＫ
１５１ 広告情報処理部
１５２ 確認情報処理部
１５３ ＤＬ完了確認部
１６０ ベースメディアアプリ
１６１ アプリコアモジュール
１６２ 基本設定情報
１７０ 広告管理ＳＤＫ
１７１ 確認情報収集部
２００ 広告管理コントローラ
２０１ ネットワークＩ／Ｆ
２１０ 広告配信部
２１１ 高校情報ＤＢ
２２０ 確認情報記憶処理部
２２１ 確認情報ＤＢ
２２２ ユーザ情報ＤＢ

特許５１０７４５５号公報 特開２０１３−８２３３号公報

Claims (10)

1. ネットワークを介してダウンロード可能なプログラムの広告を表示するための広告情報を管理する広告情報管理プログラムであって、
   前記広告情報に基づき、前記広告を表示するための情報を出力するステップと、
   表示された広告に対する操作により、前記広告される対象である対象プログラムのダウンロード画面が要求されたことを認識するステップと、
   前記ダウンロード画面が要求された場合に、前記対象プログラムを識別するための対象プログラム識別情報及び前記広告が表示される画面上の領域を提供している表示プログラムを識別するための表示プログラム識別情報を関連付けて記憶するステップと、
   前記対象プログラムがダウンロードされたことを認識するステップと、
   前記対象プログラムがダウンロードされたことが認識された場合に、ダウンロードされた対象プログラムを識別するための対象プログラム識別情報に関連付けられている表示プログラム識別情報を、ネットワークを介して送信するために出力するステップとを情報処理装置に実行させることを特徴とする広告情報管理プログラム。
2. 前記対象プログラム識別情報及び前記表示プログラム識別情報を関連付けて記憶するステップにおいて、日時の情報を関連付けて記憶し、
   関連付けられている前記日時が所定期間以内である前記表示プログラム識別情報のみ、ネットワークを介して送信する対象とすることを特徴とする請求項１に記載の広告情報管理プログラム。
3. 前記対象プログラム識別情報及び前記表示プログラム識別情報を関連付けて記憶するステップにおいて、前記表示プログラムにおいてユーザを識別するためのユーザ識別情報を関連付けて記憶し、
   前記ユーザ識別情報は、異なる前記表示プログラムにおいて同一のユーザを識別するための異なるユーザ識別情報と関連付けられていることを特徴とする請求項１または２に記載の広告情報管理プログラム。
4. 前記対象プログラム識別情報及び前記表示プログラム識別情報を関連付けて記憶するステップの後、他の広告情報管理プログラムによって記憶された前記対象プログラム識別情報と前記表示プログラム識別情報とが関連付けられた情報のうち、同一の前記対象プログラムの広告に基づいて生成された情報を削除するステップを情報処理装置に実行させることを特徴とする請求項１乃至３いずれか１項に記載の広告情報管理プログラム。
5. 前記対象プログラム識別情報と前記表示プログラム識別情報とが関連付けられた情報であって他の広告情報管理プログラムにおいて生成された情報が複製された情報を取得して記憶するステップを情報処理装置に実行させ、
   前記表示プログラム識別情報を出力するステップにおいて、前記複製された情報に含まれる前記表示プログラム識別情報も候補とすることを特徴とする請求項１乃至３いずれか１項に記載の広告情報管理プログラム。
6. 前記表示プログラム識別情報を出力するステップの後、前記対象プログラム識別情報と前記表示プログラム識別情報とが関連付けられた情報であって他の広告情報管理プログラムに複製された情報を削除するステップを情報処理装置に実行させることを特徴とする請求項５に記載の広告情報管理プログラム。
7. 前記対象プログラムがダウンロードされたことを認識するステップは、前記広告情報管理プログラムが動作している情報処理装置において新たにプログラムがダウンロードされたことを示す通知が発生した後、所定期間の待機期間が経過した後に実行されることを特徴とする請求項６に記載の広告情報管理プログラム。
8. ネットワークを介してダウンロード可能なプログラムの広告を表示可能な広告情報表示装置であって、
   前記広告を表示するための広告情報に基づき、前記広告を表示するための情報を出力し、表示された広告に対する操作により、前記広告される対象である対象プログラムのダウンロード画面が要求されたことを認識する広告情報処理部と、
   前記ダウンロード画面が要求された場合に、前記対象プログラムを識別するための対象プログラム識別情報及び前記広告が表示される画面上の領域を提供している表示プログラムを識別するための表示プログラム識別情報を関連付けて記憶する関連付け情報記憶処理部と、
   前記広告情報表示装置において前記対象プログラムがダウンロードされたことを認識するダウンロード確認部と、
   前記対象プログラムがダウンロードされたことが認識された場合に、ダウンロードされた対象プログラムを識別するための対象プログラム識別情報に関連付けられている表示プログラム識別情報を、ネットワークを介して送信するために出力する情報出力部と含むことを特徴とする広告情報表示装置。
9. 前記広告情報表示装置において新たにプログラムがダウンロードされたことを示す通知を出力する新規ダウンロード通知部を含み、
   前記ダウンロード確認部は、新たにプログラムがダウンロードされたことを示す通知に基づいて前記広告情報表示装置において前記対象プログラムがダウンロードされたことを認識することを特徴とする請求項８に記載の広告情報表示装置。
10. ネットワークを介してダウンロード可能なプログラムの広告を表示するための広告情報を管理する広告情報管理プログラムが動作している情報処理端末及び前記広告の配信を管理する広告配信装置を含む広告情報管理システムであって、
    前記広告情報管理プログラムは、
    前記広告情報に基づき、前記広告を表示するための情報を出力するステップと、
    表示された広告に対する操作により、前記広告される対象である対象プログラムのダウンロード画面が要求されたことを認識するステップと、
    前記ダウンロード画面が要求された場合に、前記対象プログラムを識別するための対象プログラム識別情報及び前記広告が表示される画面上の領域を提供している表示プログラムを識別するための表示プログラム識別情報を関連付けて記憶するステップと、
    前記対象プログラムがダウンロードされたことを認識するステップと、
    前記対象プログラムがダウンロードされたことが認識された場合に、ダウンロードされた対象プログラムを識別するための対象プログラム識別情報に関連付けられている表示プログラム識別情報を、前記広告配信装置に送信するために出力するステップとを前記情報処理端末に実行させることを特徴とする広告情報管理システム。