JP6450877B1 - 広告サーバおよび広告配信プログラム - Google Patents

Abstract

【課題】能動的かつ反復的な広告の閲覧を支援する。【解決手段】本発明の一態様によれば、広告サーバは、配信制御部と、通知生成部と、送信部とを含む。配信制御部は、広告配信日時に第１のオンラインサービスに関するＷｅｂページのいずれかを閲覧しているユーザを第１の広告の配信対象として決定する。通知生成部は、広告配信日時を示す第１の通知データを生成する。送信部は、広告配信日時の到来前に、第１の通知データをユーザの端末へプッシュ通知する。【選択図】 図２

Description

本発明は、広告の配信に関する。

近年、インターネット上での広告活動が盛んに行われ、広告を数多くのユーザに閲覧してもらうべく様々な手法が研究されている。例えば、広告の閲覧行為に対してインセンティブを付与する手法、より具体的には、広告を閲覧したユーザにポイントを付与すること、動画共有サービスにおいて動画の再生開始前または再生途中に広告を差し込むこと、などが知られている。なお、非特許文献１および非特許文献２によれば、動画の再生途中に広告を差し込む手法を実現可能な技術の１つとして、動画共有サービスにおいて、動画の視聴を強制的に中断し、別の動画やミニゲームを割り込ませる仕組みが存在する。

また、特許文献１（請求項１）によれば、計算機内で成長する仮想的生物を用いた広告システムにおいて、ユーザが検索した語句に関連する閲覧先の閲覧をユーザに要求し、ユーザの閲覧記録より発生する成長源情報により、仮想的生物の状態を変更することも知られている。

さらに、特許文献２（［０００５］）には、広告サイトの閲覧に際し、ゲームをプレイできる機能を付加し、さらに、ゲームの結果によって特典を取得できる機能を組み合わせ、それにより広告閲覧に対する動機付けを高めたゲームを利用した広告システムが開示されている。

特許第４９３４７６３号公報 特開２０１７−２２４１３４号公報 特開２０１４−２１９９０５号公報

「ニコ割ゲームとは」、［ｏｎｌｉｎｅ］、［２０１８年３月５日検索］、インターネット、＜ＵＲＬ：ｈｔｔｐ：／／ｄｉｃ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ａ／ニコ割ゲーム＞ 「ニコニコ割り込みとは」、［ｏｎｌｉｎｅ］、［２０１８年３月５日検索］、インターネット、＜ＵＲＬ：ｈｔｔｐ：／／ｄｉｃ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ａ／ニコニコ割り込み＞

広告の閲覧行為に対してインセンティブを付与するという手法では、広告そのものではなくインセンティブ、すなわち、ポイントや動画の視聴権利、ゲームのプレイ権利、ゲームの結果によって取得できる特典、仮想的生物の成長などが、ユーザが広告を閲覧する主要な動機付けとなりがちである。故に、ユーザは、広告を能動的に閲覧するというよりは寧ろ作業的に閲覧する可能性が高いであろう。

他方、広告そのものの魅力を高めようとするアプローチも研究されている。例えば特許文献３（要約書）によれば、ゲーム性の高い広告やゲームそのものを相互作用性のある広告コンテンツとして配信すること、当該広告コンテンツのセーブデータを保存することが知られている。

しかしながら、特許文献３には、ゲーム性の高い広告を配信することは記載されているものの、そもそもどのような状況で広告を配信するのか、ユーザが気に入るであろう広告をどのように選択して配信するか、ユーザが特定の広告を気に入った場合に、どのようにしてその広告をユーザに能動的かつ反復的に再閲覧してもらうか、などについての洞察を欠いている。

本発明は、能動的かつ反復的な広告の閲覧を支援することを目的とする。

本発明の一態様によれば、広告サーバは、配信制御部と、通知生成部と、送信部とを含む。配信制御部は、広告配信日時に第１のオンラインサービスに関するＷｅｂページのいずれかを閲覧しているユーザを第１の広告の配信対象として決定する。通知生成部は、広告配信日時を示す第１の通知データを生成する。送信部は、広告配信日時の到来前に、第１の通知データをユーザの端末へプッシュ通知する。

本発明によれば、能動的かつ反復的な広告の閲覧を支援することができる。

各実施形態に係る広告サーバを含む広告配信システムを例示するブロック図。 第１の実施形態に係る広告サーバを例示するブロック図。 端末における広告の表示例を示す図。 図２の広告サーバの動作を例示するフローチャート。 第２の実施形態に係る広告サーバを例示するブロック図。 図５の広告サーバの動作を例示するフローチャート。 第３の実施形態に係る広告サーバを例示するブロック図。 図７の広告サーバの動作を例示するフローチャート。

以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

（第１の実施形態）
第１の実施形態に係る広告サーバは、図１に示される広告配信システムに組み込むことができる。この広告配信システムは、端末１００−１，１００−２，・・・と、Ｗｅｂサーバ２００と、広告サーバ３００とを含む。

端末１００のユーザは、当該端末１００を操作して、Ｗｅｂサーバ２００によって提供されるオンラインサービスに関わる任意のＷｅｂページを閲覧できる。具体的には、端末１００は、ユーザからの操作に従って、Ｗｅｂサーバ２００に所望のＷｅｂページのデータを要求し、当該データを受信する。Ｗｅｂページのデータは、例えばＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などのマークアップ言語によって記述されている。そして、端末１００は、Ｗｅｂページのデータを解釈（パース）し、出力（描画および／または音声出力）する。端末１００のかかる機能は、Ｗｅｂブラウザが担当してもよいし、その他のアプリケーションが担当してもよい。

端末１００は、Ｗｅｂページの閲覧が可能なコンピュータなどの電子デバイス、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、モバイル端末（例えば、タブレット、スマートフォン、ラップトップ、フィーチャーフォン、ポータブルゲーム機、デジタルミュージックプレイヤー、電子書籍リーダなど）、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）端末、ＡＲ(Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ)端末、ゲーム機、テレビ受像機（インターネットテレビを含む）、などであり得るが、これらに限られない。

Ｗｅｂサーバ２００は、端末１００および広告サーバ３００とネットワーク経由で接続しており、互いにデータを送受信できる。Ｗｅｂサーバ２００は、端末１００からのアクセスに応じてオンラインサービスを提供する。具体的には、Ｗｅｂサーバ２００は、端末１００からオンラインサービスに関するＷｅｂページのデータの要求（例えばｇｅｔリクエスト）を受信すると、当該データを端末１００へ返す。

オンラインサービスは、例えば、コンテンツ共有サービス、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、電子商取引（ＥＣ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）、インターネットオークション、ポータルサービス（いわゆるポータルサイトによって提供されるオンラインサービス）、などであり得る。ここで、コンテンツ共有サービスは、動画、静止画、テキスト、音声、ゲーム、など任意の種類のコンテンツを複数のユーザ間で共有可能とすることを意味する。コンテンツ共有サービスは、例えば動画生放送などのリアルタイムコンテンツ共有サービスも含み得る。

広告サーバ３００は、端末１００およびＷｅｂサーバ２００とネットワーク経由で接続しており、互いにデータを送受信できる。広告サーバ３００は、Ｗｅｂサーバ２００と協同し、広告付きのオンラインサービスをユーザへ提供する。広告サーバ３００は、オンラインサービスに関するＷｅｂページを閲覧中の端末１００へ、広告のデータを配信する。広告のデータは、Ｗｅｂサーバ２００から端末１００へ送信されるＷｅｂページのデータに埋め込まれていてもよいし、アドタグが埋め込まれたＷｅｂページのデータを受信した端末１００が自動的に広告サーバ３００へアクセスして取得してもよい。

ここで、広告は、例えばユーザが遊ぶことのできるプレイアブル広告であるが、これに限られない。プレイアブル広告は、広告的要素のあるゲームと解釈することもできるし、ゲーム的要素のある広告と解釈することもできる。プレイアブル広告は、何らかの動的要素を含んでおり、例えばユーザが端末１００に対して行った操作に依存して出力が変化する。なお、ここでの出力とは、典型的には画像および／または音声を指しているが、これらの代わりにまたはこれらに加えて、振動および／または温度（の変更）があり得る。さらに、プレイアブル広告は、当該プレイアブル広告の進行状態の遷移に依存してスコアが変動するものであってもよい。

スコアは、プレイアブル広告においてユーザがプレイヤキャラクタを操作して獲得した得点であってもよいし、プレイヤキャラクタが生存することのできた時間、ステージクリアの所要時間、などであってもよい。

プレイアブル広告の対象、すなわち商材は、例えばゲームそのものであってもよく、この場合に、プレイアブル広告はその体験版または機能制限版であってもよい。或いは、商材はゲームでなくてもよい。この場合に、プレイアブル広告は、商材に関連する内容のゲームであってもよい。具体的には、プレイアブル広告は、商材がカップラーメンである場合にジャスト３分間を体験してもらうものであってもよいし、商材がピザ、ハンバーガなどである場合に具の盛り付けを体験できるものであってもよい。或いは、広告は、商材とは独立した内容のゲームであってもよく、そのスポンサーまたは商材の名称、写真、バナー、などの広告的要素がゲーム中に登場する看板、キャラクタの衣装などとして表示されるようにしてもよい。

プレイアブル広告のプログラムは、いわゆるスタンドアローン型のゲームまたはＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）型のオンラインゲームとして端末１００のみによって実行されてもよいし、Ｃ／Ｓ（Ｃｌｉｅｎｔ ／ Ｓｅｒｖｅｒ）型のオンラインゲームとして端末１００および図示されないゲームサーバ（これは、広告サーバ３００が兼務してもよい）によって分担して実行されてもよい。Ｐ２Ｐ型のオンラインゲームとして端末１００のみによって実行される場合には、当該端末１００が他の端末１００から操作データを受信したり、当該他の端末へ後述されるプレイアブル広告のプログラムの実行結果を送信したりする。

広告サーバ３００が図示されないゲーム実行部を含む場合には、このゲーム実行部は端末１００から送信されるユーザの操作データに基づいてプレイアブル広告のプログラム（サーバサイドプログラム）を実行し、その実行結果を端末１００に返す。ここで、プログラムの実行結果とは、例えば、プレイアブル広告の画面／音声（のエンコード済みデータ）そのものであってもよいし、進行状態（ゲーム状態）のようなプレイアブル広告の画面／音声を生成するために必要なデータであってもよい。例えば、プレイアブル広告がクラウドゲームに相当する場合には、広告サーバ３００は、プレイアブル広告の画面／音声そのものを端末１００へ送信し得る。

また、このゲーム実行部は、スコアの算出、セーブデータ／リプレイデータの作成を行ってもよい。これらの処理をゲームサーバ（この例では広告サーバ３００が兼務）において行うと、端末１００において行った場合に比べたチート対策がしやすいというメリットがある。

また、図３に例示されるように、（プレイアブル）広告の画像は、端末１００の画面において、Ｗｅｂサーバ２００によって提供されるオンラインサービスに関するＷｅｂページを表示する領域（図３の白色領域）によって互いに隔てられた複数の異なる広告表示領域（図３の斜線模様の領域）に亘って表示されてよい。

一般に、広告表示領域は、当該広告が掲載されるＷｅｂページの閲覧を阻害しないように、画面の中心よりは寧ろ端部、すなわち上端、下端、左端、右端などに分割して配置されやすい。図３のようにスペースの限られた広告表示領域を寄せ集めることで、単体の広告表示領域を使用した場合に比べて、ユーザの印象に残る広告を表示したり、プレイアブル広告の表現力を高めて高度なゲーム体験をユーザに提供したりすることができる。前者の例として、４つの広告表示領域に４コマ漫画を順に表示してもよいし、１つの広告表示領域にクイズを表示し別の広告表示領域にその答えを表示してもよい。後者の例として、マップを複数の広告表示領域に亘って空間的に分割して表示してもよいし、１つの広告表示領域にマップ、別の広告表示領域にステータスを表示するなどして広告表示領域間で役割を変えてもよい。

広告サーバ３００は、広告を配信する日時（広告配信日時）を予め決定し、当該広告配信日時をその配信対象となり得るユーザの端末１００へプッシュ通知する。ここで、プッシュ通知とは、典型的には広告サーバ３００が端末１００としてのスマートフォンのロック画面またはホーム画面の上端などにメッセージウィンドウを表示させることであるが、これに限らず、広告サーバ３００が端末１００へ何らかのデータを能動的に送信することを指す。これにより、ユーザに広告を閲覧（プレイアブル広告であればプレイ）可能な日時を認知させることができる。仮にユーザがこの広告を以前に閲覧ないしプレイして気に入っているか、或いは口コミなどを通じて興味を持っているとすれば、当該広告を閲覧ないしプレイすべく、端末１００を操作して広告配信日時にＷｅｂサーバ２００へアクセスするように促される。すなわち、ユーザの能動的かつ反復的な広告の閲覧を支援することができる。

なお、図１において示される各装置の数は、例示に過ぎない。例えば、端末１００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、広告サーバ３００は、１つではなく複数のＷｅｂサーバ２００と協同して、それぞれのＷｅｂサーバ２００によって提供されるオンラインサービスのユーザ向けに広告を配信してもよい。さらに、図１に示されないアプリケーションサーバ、データベースサーバなどがさらに設けられてもよい。

以下、図２および図４を用いて、広告サーバ３００について詳しく説明する。
広告サーバ３００は、コンピュータであって、例えば、入出力制御、通信制御、そして広告配信（すなわち、広告の配信制御、後述される通知データの生成、など）を行うプロセッサを含む。ここで、プロセッサは、典型的にはＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）および／またはＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であるが、マイコン、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、またはＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、などであってもよい。また、広告サーバ３００は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリを含んでいる。

なお、広告サーバ３００は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、広告サーバ３００に内蔵または外付けされたＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリなどであってもよいし、広告サーバ３００からアクセス可能なデータベースサーバであってもよい。

また、広告サーバ３００は、複数のコンピュータの組み合わせであってよい。例えば、広告サーバ３００の機能部、例えば後述される通信部３１０（または、通信部３４０もしくは通信部３７０）と広告配信部３２０（または、広告配信部３５０もしくは広告配信部３８０）および種々の記憶部とが別個のコンピュータに分散して実装されてもよい。

広告サーバ３００は、さらに、ネットワークに接続するための通信Ｉ／Ｆ（インタフェース）を利用可能である。通信Ｉ／Ｆは、広告サーバ３００に内蔵されてもよいし、広告サーバ３００に外付けされてもよい。

通信Ｉ／Ｆは、ネットワーク経由で、端末１００およびＷｅｂサーバ２００と通信をするためのモジュールであり得る。例えば、通信Ｉ／Ｆは、広告のデータ、通知データなどを端末１００へ送信したりする。

次に、図２を用いて第１の実施形態に係る広告サーバ３００の構成例の説明を続ける。図２の広告サーバ３００は、通信部３１０と、広告配信部３２０と、種々の記憶部とを含む。

通信部３１０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、例えば端末１００およびＷｅｂサーバ２００からデータを受信したり、端末１００およびＷｅｂサーバ２００へデータを送信したりする。具体的には、通信部３１０は、受信部３１１および送信部３１２を含む。

受信部３１１は、ユーザが指定した広告を広告サーバ３００に登録／広告サーバ３００から削除するためのお気に入り登録／削除要求を端末１００から受信する。これにより、広告サーバ３００は、ユーザ毎に、お気に入り登録された広告とそうでない広告とを区別することができ、例えば後述されるプッシュ通知の対象者のフィルタリングの基準などに利用することができる。この要求は、例えば、お気に入り登録／削除の対象となる広告を識別するデータと、要求の主体であるユーザを識別するデータ（ユーザ識別子）とを含み得る。ユーザの操作に応じて端末１００は、かかる要求を発行する。なお、ユーザは閲覧（またはプレイ）した広告に限らず、未閲覧の広告であっても口コミなどを通じて興味を持った広告をお気に入り登録することがあり得る。受信部３１１は、お気に入り登録／削除要求をお気に入り登録部３２３へ送る。

送信部３１２は、配信制御部３２１から広告のデータを受け取り、これを端末１００へ送信する。また、送信部３１２は、通知生成部３２２から通知データを受け取り、これを広告配信日時の到来前に端末１００へ送信（プッシュ通知）する。プッシュ通知のタイミングは任意であるが、広告配信日時までの間隔が大きすぎるとユーザが通知された広告配信日時を失念するおそれがあるので、広告配信日時の直前、例えば数分〜数十分程度前に設定され得る。或いは、送信部３１２は、広告配信日時の例えば前日および直前のように複数回に亘って通知データをプッシュ通知してもよい。

広告配信部３２０は、前述のプロセッサおよびメモリであってよい。広告配信部３２０は、お気に入り登録／削除要求、などを通信部３１０から受け取る。また、広告配信部３２０は、種々の記憶部から必要なデータを読み出す。広告配信部３２０は、通信部３１０から受け取ったデータおよび／または種々の記憶部から読み出したデータに基づいて、広告の配信をスケジュールおよび実施したり、ユーザにスケジューリング結果をプッシュ通知するための通知データを生成したり、ユーザの広告閲覧履歴および／またはお気に入り広告を管理したりする。さらに、広告配信部３２０は、広告のデータ、通知データ、などを通信部３１０へ送る。具体的には、広告配信部３２０は、配信制御部３２１と、通知生成部３２２と、お気に入り登録部３２３とを含む。

配信制御部３２１は、広告の配信を実施する前に、広告の配信をスケジュールする。具体的には、配信制御部３２１は、いつ、どこで、どの広告を、後述されるユーザリストデータに登録されたどのユーザに向けて配信するかを決定する。一例として、配信制御部３２１は、ある広告配信日時に、Ｗｅｂサーバ２００が提供するオンラインサービス（第１のオンラインサービス）に関するＷｅｂページのいずれかにおいて、ある広告（第１の広告）を任意のユーザに配信することを決定する。すなわち、配信制御部３２１は、広告配信日時に第１のオンラインサービスに関するＷｅｂページのいずれかを閲覧しているユーザを第１の広告の配信対象として決定する。或いは、配信制御部３２１は、広告が配信されるＷｅｂページ（広告配信ページ）をより詳細に限定することもできる。すなわち、配信制御部３２１は、広告配信日時に第１のオンラインサービスに関するあるＷｅｂページ（第１のＷｅｂページ）を閲覧しているユーザを第１の広告の配信対象として決定してもよい。それから、配信制御部３２１は、スケジューリング結果、すなわち、いつ、どこで、どの広告を、どのユーザに向けて配信するかを示すスケジュールデータを、スケジュール記憶部３３３へ書き込む。

スケジュールの後に、配信制御部３２１は、広告の配信を実施する。例えば、第１の広告の配信対象として決定されたユーザの端末１００が、第１の広告の配信対象となるＷｅｂページに埋め込まれたアドタグに従って、当該第１の広告の広告配信日時に広告サーバ３００に広告を要求すると、配信制御部３２１は、当該端末１００へ第１の広告を配信すべく、広告記憶部３３２から第１の広告のデータを読み出して送信部３１２へ送ってもよい。或いは、配信制御部３２１は、第１の広告配信日時が到来すると、第１の広告の配信対象として決定されたユーザの端末１００を例えばＷｅｂサーバ２００から取得した情報に基づいて検知し、当該端末１００へ第１の広告を配信すべく、広告記憶部３３２から第１の広告のデータを読み出して送信部３１２へ送ってもよい。

また、配信制御部３２１は、ユーザの閲覧履歴データを管理してもよい。具体的には、配信制御部３２１は、ユーザ識別子に対応付けて、当該ユーザへ配信済みの広告を識別する閲覧履歴データをユーザデータ記憶部３３１に書き込んでもよい。閲覧履歴データは、ユーザが過去に閲覧（またはプレイ）した広告群（第１の広告群）を示す。ここで、広告群とは、広告の集合を意味し、その要素の数は複数である可能性もあるし、１個または零個（空集合）である可能性もある。なお、通知生成部３２２が、後述される、閲覧履歴データに基づくプッシュ通知の対象者のフィルタリングを行わない場合には、配信制御部３２１はユーザの閲覧履歴データを管理しなくてもよい。

通知生成部３２２は、スケジュール記憶部３３３からスケジュールデータを読み出す。通知生成部３２２は、少なくとも広告配信日時を示す通知データ（第１の通知データ）を生成し、送信部３１２へ送る。この通知データをユーザの端末１００へプッシュ通知することで、ユーザは気になる広告やお気に入りの広告が配信される日時に、第１のオンラインサービスを利用するように促される。この通知データは、例えば、「今日の２０時に、○○動画共有サイトに××広告が掲載されます！遊びたい方は、２０時に○○動画共有サイトへ！」などのメッセージとして端末１００の画面に表示され得る。

また、前述のように配信制御部３２１が広告配信日時に第１のＷｅｂページを閲覧しているユーザを第１の広告の配信対象として決定している場合に、通知生成部３２２は、当該第１のＷｅｂページを示す通知データ（第２の通知データ）をさらに生成し、送信部３１２へ送ってもよい。この通知データをユーザの端末１００へプッシュ通知することで、ユーザは気になる広告やお気に入りの広告が配信される日時に、第１のＷｅｂページを閲覧するように促される。これは、第１のオンラインサービスの運営側からすれば、特定のＷｅｂページにユーザを誘導できることを意味する。さらに、この第２の通知データは、第１のＷｅｂページへのリンクを含んでいてもよい。これにより、ユーザを迅速かつ確実に第１のＷｅｂページへ誘導することができる。この通知データは、例えば、「今日の２０時に、○○動画共有サイトの特設ページに××広告が掲載されます！遊びたい方は、２０時にこのＵＲＬへ！」などのリンク付きメッセージとして端末１００の画面に表示され得る。

通知生成部３２２は、（１）プッシュ通知の対象者のフィルタリングを全く行わなくてもよいし、（２）フィルタリングにより一部のユーザをプッシュ通知の対象者から除外してもよい。（２）の例として、（２−１）通知生成部３２２は、ユーザが過去に閲覧（またはプレイ）した広告に限って当該ユーザ向けに通知データをプッシュ通知してもよいし、（２−２）ユーザがお気に入り登録した広告に限って当該ユーザ向けに通知データをプッシュ通知してもよい。なお、通知生成部３２２は、複数の異なる基準のフィルタリングを組み合わせてもよい。例えば、（２−１）および（２−２）の両方を実施すれば、ユーザは、過去に閲覧した広告およびお気に入り登録した広告の両方に関するプッシュ通知を受け取ることもできるし、或いは、過去に閲覧しかつお気に入り登録した広告に限ってプッシュ通知を受け取ることもできる。

まず（２−１）の例について説明する。通知生成部３２２は、ユーザデータ記憶部３３１から閲覧履歴データを読み出す。そして、通知生成部３２２は、ユーザ毎に、第１の広告が閲覧履歴データの示す広告群のいずれか（の要素）に一致するか否かを判定する。第１の広告が閲覧履歴データの示す広告群のいずれとも一致しなかったユーザを、通知生成部３２２は通知データのプッシュ通知の対象者から除外する。そして、送信部３１２は、このユーザの端末１００へ通知データを送信しない。これにより、ユーザの端末１００には過去に閲覧（またはプレイ）した広告に限って広告配信日時などがプッシュ通知されることになる。故に、ユーザが未閲覧かつ閲覧するかも不明な広告に関する大量のプッシュ通知に、ユーザが再閲覧を望む広告に関するプッシュ通知が埋もれるのを防ぐことができる。

次に（２−２）の例について説明する。通知生成部３２２は、ユーザデータ記憶部３３１からお気に入りデータを読み出す。このお気に入りデータは、後述されるように、ユーザがお気に入り指定した広告群（第２の広告群）を識別するデータである。そして、通知生成部３２２は、ユーザ毎に、第１の広告がお気に入りデータの示す広告群のいずれか（の要素）に一致するか否かを判定する。第１の広告がお気に入りデータの示す広告群のいずれとも一致しなかったユーザを、通知生成部３２２は通知データのプッシュ通知の対象者から除外する。そして、送信部３１２はこのユーザの端末１００へ通知データを送信しない。これにより、ユーザの端末１００には当該ユーザがお気に入り登録した広告に限って広告配信日時などがプッシュ通知されることになる。故に、ユーザは能動的に閲覧（またはプレイ）を望む広告を選択してプッシュ通知を受け取ることができる。

さらに通知データは、上記メッセージ例のように第１の広告を明示的または暗黙的に示す要素を含んでいてもよいし、例えば「今日の２０時に、○○動画共有サイトの特設ページにオススメの広告が掲載されます！遊びたい方は、２０時にこのＵＲＬへ！」のように第１の広告を示す要素を全く含まなくてもよい。

また、両者を使い分けることも可能である。例えば、第１の広告を閲覧済みまたはお気に入り登録済みのユーザは第１の広告が配信されることを認知させた方が能動的な閲覧を期待できるので、当該ユーザ向けのプッシュ通知には当該第１の広告を示す要素を含めてもよい。他方、他のユーザ向けのプッシュ通知には第１の広告を示す要素を敢えて含めないことで、これらのユーザの好奇心を刺激して第１の広告を閲覧するように仕向けてもよい。

お気に入り登録部３２３は、受信部３１１からお気に入り登録要求を受け取る。お気に入り登録部３２３は、お気に入り登録要求の主体のユーザ識別子に対応付けて、お気に入り登録の対象となる広告を識別するお気に入りデータをユーザデータ記憶部３３１に書き込む。

また、お気に入り登録部３２３は、受信部３１１からお気に入り削除要求を受け取る。お気に入り登録部３２３は、お気に入り削除要求の対象となるお気に入りデータをユーザデータ記憶部３３１から削除する。

なお、通知生成部３２２が、お気に入りデータに基づくプッシュ通知の対象者のフィルタリングを行わない場合には、お気に入り登録部３２３は広告サーバ３００から削除され得る。

図２の例において種々の記憶部は、ユーザデータ記憶部３３１と、広告記憶部３３２と、スケジュール記憶部３３３とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

ユーザデータ記憶部３３１は、種々のユーザデータ、具体的には、ユーザリストデータ、閲覧履歴データおよびお気に入りデータを保存する。なお、図２の例ではユーザデータ記憶部３３１は複数種類のデータを保存しているが、個別のデータを保存する複数の記憶部、例えば、ユーザリストデータ記憶部、閲覧履歴データ記憶部およびお気に入りデータ記憶部に機能分割されてよい。

ユーザリストデータは、広告サーバ３００が広告を配信するユーザのリストであり、ユーザ毎のユーザ識別子を含む。ユーザリストデータは、第１のオンラインサービスのユーザリストデータと紐付けられていてもよい。また、ユーザリストデータは、例えば、図示されないユーザ管理部によって管理され得る。例えば、第１のオンラインサービスに新規ユーザが加入した場合には、ユーザ管理部は当該新規ユーザを識別するユーザ識別子をユーザリストデータに追加する。他方、第１のオンラインサービスから既存ユーザが脱退した場合には、ユーザ管理部は当該既存ユーザを識別するユーザ識別子をユーザリストデータから削除する。

閲覧履歴データは、配信制御部３２１によって書き込まれ、または書き換えられる。また、閲覧履歴データは、通知生成部３２２によって読み出される。ただし、閲覧履歴データをプッシュ通知対象者のフィルタリングにおいて全く利用しないことも可能である。この場合には、閲覧履歴データがユーザデータ記憶部３３１に保存されなくてもよい。

お気に入りデータは、お気に入り登録部３２３によって書き込まれ、または書き換えられる。また、お気に入りデータは、通知生成部３２２によって読み出される。ただし、お気に入りデータをプッシュ通知対象者のフィルタリングにおいて全く利用しないことも可能である。この場合には、お気に入りデータがユーザデータ記憶部３３１に保存されなくてもよい。

広告記憶部３３２は、第１の広告を含む１以上の広告のデータを保存する。この広告のデータは、配信のために配信制御部３２１によって読み出される。広告のデータは、例えば、画像データおよび／または音声データであってもよいし、ゲームプログラムおよび当該ゲームプログラムによって用いられるデータであってもよいし、ゲームサーバにアクセスするためのバナーであってもよい。

広告がプレイアブル広告でない場合には、広告のデータは、単なる画像データもしくはバナー、および／または音声データであり得る。広告がスタンドアローン型のゲームまたはＰ２Ｐ型のオンラインゲームに相当するプレイアブル広告である場合には、広告のデータは、ゲームプログラムおよび当該ゲームプログラムによって用いられるデータであり得る。広告がＣ／Ｓ型のオンラインゲーム（ブラウザゲームを含む）に相当するプレイアブル広告である場合には、広告のデータは、ゲームサーバにアクセスするためのバナーであり得る。

広告のデータは、広告主によって自由に登録、削除または編集可能としてもよいし、広告サーバ３００の運営者が広告主の依頼を受けて登録、削除または編集するようにしてもよい。

スケジュール記憶部３３３は、配信制御部３２１によって決定されたスケジュールデータを保存する。スケジュールデータは、配信制御部３２１によって書き込まれ、または書き換えられる。また、スケジュールデータは、通知生成部３２２によって読み出される。

次に、図４を用いて、１つの広告（第１の広告）の１回の配信についての広告サーバ３００の動作例を説明する。

まず、配信制御部３２１は、第１の広告について広告配信日時および広告配信ページを決定する（ステップＳ４０１）。なお、広告配信ページは、第１のオンラインサービスに関する特定のＷｅｂページに限らず全Ｗｅｂページであってもよい。

次に、通知生成部３２２は、ステップＳ４０１において決定された広告配信日時および広告配信ページに基づいて、これらを示す通知データを生成する（ステップＳ４０２）。ステップＳ４０２の後に、処理はステップＳ４０３へと進む。

ステップＳ４０３において、通知生成部３２２は、ユーザリストデータに登録されたユーザのうち未処理のユーザの１人を選択する。そして、通知生成部３２２は、閲覧履歴データに基づいてユーザが第１の広告を閲覧（またはプレイ）したことがあるか否かを判定する（ステップＳ４０４）。ユーザが第１の広告を閲覧したことがあれば処理はステップＳ４０５へ進み、そうでなければ処理はステップＳ４０６へと進む（ステップＳ４０３において選択されたユーザがプッシュ通知の対象者から除外される）。

ステップＳ４０５において、送信部３１２は、ステップＳ４０３において選択したユーザの端末１００へステップＳ４０２において生成した通知データをプッシュ通知する。なお、ステップＳ４０５の段階では、ユーザをプッシュ通知の対象者リストに加えるに留めておき、プッシュ通知は全ユーザに対するフィルタリング処理が完了してからまとめて行われてもよい。ステップＳ４０５の後に、処理はステップＳ４０６へと進む。

ステップＳ４０６において、通知生成部３２２は、ユーザリストデータに登録された全てのユーザについて、ステップＳ４０３乃至ステップＳ４０５の処理が済んでいるか否かを判定する。未処理のユーザが残存していれば処理はステップＳ４０３へ戻り、そうでなければ処理はステップＳ４０７へ進む。

なお、図４の例では広告サーバ３００はユーザリストデータに登録された全てのユーザを処理対象としているが、広告サーバ３００はユーザリストデータに登録されたユーザの一部に限って処理対象としてもよい。すなわち、「ユーザリストデータに登録された全てのユーザ」は、「ユーザリストデータに登録されたユーザのうち処理対象として選ばれた全てのユーザ」に読み替えられ得る。

ステップＳ４０３からステップＳ４０６は、プッシュ通知の対象者のフィルタリング処理に相当する。なお、かかるフィルタリング処理は省略されてもよいし、お気に入りデータおよび／またはその他のデータに基づくフィルタリング処理に置き換えられてもよい。例えば、ステップＳ４０４では、通知生成部３２２は、お気に入りデータに基づいてユーザが第１の広告をお気に入り登録しているか否かを判定してもよい。

ステップＳ４０７では、広告サーバ３００はステップＳ４０１において決定された広告配信日時を待ち受ける。広告配信日時が到来すると、処理はステップＳ４０８へ進む。ステップＳ４０８において、送信部３１２は、ステップＳ４０１において決定された広告配信ページを閲覧しているユーザの端末１００へ第１の広告のデータを送信する。なお、ステップＳ４０８において、送信部３１２は、ユーザの端末１００が、ステップＳ４０１において決定された広告配信ページに埋め込まれたアドタグに従って広告サーバ３００に広告を要求したことをトリガとして、第１の広告のデータを端末１００へ送信してもよい。

以上説明したように、第１の実施形態に係る広告サーバは、広告配信日時をユーザの端末へプッシュ通知する。故に、この広告サーバによれば、ユーザに広告を閲覧（プレイアブル広告であればプレイ）可能な日時を認知させることができる。仮にユーザが以前にこの広告を閲覧ないしプレイして気に入っているか、或いは口コミなどを通じて興味を持っているとすれば、当該広告を閲覧ないしプレイすべく、端末を操作して広告配信日時に広告が配信されるＷｅｂサーバへアクセスするように促される。すなわち、ユーザの能動的かつ反復的な広告の閲覧を支援することができる。

また、プッシュ通知によりユーザが広告に誘導されると、当該広告の閲覧数（またはプレイ数）の増加が期待できる。これは、広告が配信されるＷｅｂページ（またはＷｅｂサイト）への波及効果、例えば当該Ｗｅｂページにおいて提供されるコンテンツの再生回数（およびコメント投稿数）の増加、当該Ｗｅｂページに掲載された商品の購入者数の増加なども期待できる。

（第２の実施形態）
前述のように、第１の実施形態に係る広告サーバは、広告配信日時などをユーザの端末へプッシュ通知することで、ユーザの能動的かつ反復的な広告の閲覧を支援する。第２の実施形態に係る広告サーバは、上記プッシュ通知に加えて、プレイアブル広告のセーブデータ／リプレイデータを保持しておき将来的に本人または他人が利用できるようにすることで、ユーザの能動的かつ反復的なプレイアブル広告のプレイを支援する。

以下、図５および図６を用いて、第２の実施形態に係る広告サーバ３００について詳しく説明する。なお、第１の実施形態と重複する説明については基本的に省略する。
まず、図５を用いて第２の実施形態に係る広告サーバ３００の構成例の説明を続ける。図５の広告サーバ３００は、通信部３４０と、広告配信部３５０と、種々の記憶部とを含む。

通信部３４０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、例えば端末１００およびＷｅｂサーバ２００からデータを受信したり、端末１００およびＷｅｂサーバ２００へデータを送信したりする。具体的には、通信部３４０は、受信部３４１および送信部３４２を含む。

受信部３４１は、端末１００から、セーブデータ／リプレイデータ登録／削除要求を受信したり、セーブデータ／リプレイデータ共有要求を受信したりする。ユーザの操作に応じて端末１００は、これらの要求を発行する。セーブデータ／リプレイデータ登録要求は、例えば、登録の対象となるセーブデータ／リプレイデータと、要求の主体のユーザ識別子とを含み得る。さらに、要求は、オプションとして、セーブデータ／リプレイデータの作成日時を含んでいてもよい。このセーブデータ／リプレイデータの作成日時は、プッシュ通知の対象者のフィルタリングの基準の一部に利用され得る。例えば、ユーザが直近１ヶ月以内にセーブデータを保存したプレイアブル広告に限って広告配信日時などがプッシュ通知されるようにしてもよい。

セーブデータは、いずれかのユーザが過去に遊んだプレイアブル広告群のいずれかの、当該セーブデータ保存時の進行状態を復元するためのデータである。セーブデータは、端末１００によって作成されてもよいし、ゲームサーバによって作成されてもよいし、広告サーバ３００によって作成されてもよい。セーブデータは、当該セーブデータの共有を許可されたユーザの端末１００によってロードされてよい。これにより、ユーザは、配信されたプレイアブル広告を他人または自身が中断したポイントから再開することができる。

リプレイデータは、いずれかのユーザが過去に遊んだプレイアブル広告群のいずれかについて当該ユーザがプレイアブル広告を遊んだ時の進行状態の遷移を再現するためのデータである。リプレイデータは、端末１００によって作成されてもよいし、ゲームサーバによって作成されてもよいし、広告サーバ３００によって作成されてもよい。リプレイデータは、当該リプレイデータの共有を許可されたユーザの端末１００の画面においていわゆるゴーストとして、配信されたプレイアブル広告に重畳して再生されてよい。これにより、ユーザは、他人または自身が過去に遊んだプレイアブル広告を同時並行的に追体験しながら、自らのプレイアブル広告の進行を楽しむことができる。

セーブデータ／リプレイデータ削除要求は、例えば、削除の対象となるセーブデータ／リプレイデータを識別するデータと、要求の主体のユーザ識別子とを含み得る。セーブデータ／リプレイデータ共有要求は、例えば、共有の対象となるセーブデータ／リプレイデータを識別するデータと、要求の主体のユーザ識別子とを含み得る。

受信部３４１は、セーブデータ／リプレイデータ登録／削除要求をデータ登録部３５３へ送る。受信部３４１は、セーブデータ／リプレイデータ共有要求を共有制御部３５４へ送る。

なお、セーブデータ／リプレイデータの共有は、Ｗｅｂサーバ２００が提供するオンラインサービスに限らず、当該オンラインサービスと連携するＳＮＳを介して行われてもよい。具体的には、ＳＮＳにおけるユーザのページに、当該ユーザの保存したセーブデータ／リプレイデータについて他のユーザの端末１００がセーブデータ／リプレイデータ共有要求を発行するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部品（ウィジェット）が表示されてもよい。このようにＳＮＳを介したセーブデータ／リプレイデータの共有を可能とすることで、ＳＮＳのユーザを当該プレイアブル広告およびＷｅｂサーバ２００が提供するオンラインサービスに誘導することができる。この結果、プレイアブル広告のプレイ、オンラインサービスの利用および／または新規ユーザの獲得の促進が期待できる。

送信部３４２は、配信制御部３５１から広告のデータを受け取り、これを端末１００へ送信する。また、送信部３４２は、通知生成部３５２から通知データを受け取り、これを広告配信日時の到来前に端末１００へ送信（プッシュ通知）する。さらに、送信部３４２は、共有制御部３５４からセーブデータ／リプレイデータ共有要求に対する応答を受け取り、これを当該要求の送信元となる端末１００へ返す。この応答は、例えばセーブデータ／リプレイデータの共有の許可／拒否を示すコードを含んでいてよく、セーブデータ／リプレイデータの共有が許可されたことを示すコードを含む場合にはさらにセーブデータ／リプレイデータを含んでいてもよい。

広告配信部３５０は、前述のプロセッサおよびメモリであってよい。広告配信部３５０は、セーブデータ／リプレイデータ登録／削除／共有要求、などを通信部３４０から受け取る。また、広告配信部３５０は、種々の記憶部から必要なデータを読み出す。広告配信部３５０は、通信部３４０から受け取ったデータおよび／または種々の記憶部から読み出したデータに基づいて、広告の配信をスケジュールおよび実施したり、ユーザにスケジューリング結果をプッシュ通知するための通知データを生成したり、ユーザのセーブデータ／リプレイデータを管理したりする。さらに、広告配信部３５０は、広告のデータ、通知データ、セーブデータ／リプレイデータ共有要求に対する応答、などを通信部３４０へ送る。具体的には、広告配信部３５０は、配信制御部３５１と、通知生成部３５２と、データ登録部３５３と、共有制御部３５４とを含む。

なお、図５には、お気に入り登録部３２３およびお気に入りデータが描かれていないものの、通知生成部３５２は図２の例と同様にお気に入りデータに基づいてプッシュ通知の対象者のフィルタリングを行い得る。この場合には、広告配信部３５０は、図２のお気に入り登録部３２３と同一または類似の機能部を含み得る。

配信制御部３５１は、図２の配信制御部３２１と同一または類似であり得る。なお、図５には、閲覧履歴データが描かれていないものの、通知生成部３５２は図２の例と同様に閲覧履歴データに基づいてプッシュ通知の対象者のフィルタリングを行い得る。この場合には、配信制御部３５１は、図２の配信制御部３２１と同様に、閲覧履歴データを管理し得る。

通知生成部３５２は、図２の通知生成部３２２と基本的に同一または類似であり得る。ただし、通知生成部３５２は、セーブデータに基づいてプッシュ通知の対象者のフィルタリングを行ってもよい。具体的には、通知生成部３２２は、ユーザデータ記憶部３３１からセーブデータを読み出す。そして、通知生成部３２２は、ユーザ毎に、当該ユーザがセーブデータを保存したプレイアブル広告群のいずれか（の要素）に第１の広告が一致するか否かを判定する。通知生成部３２２は、第１の広告のセーブデータを保存していないユーザを、通知データのプッシュ通知の対象者から除外する。そして、送信部３１２は、このユーザの端末１００へ通知データを送信しない。これにより、ユーザの端末１００にはセーブデータを保存した、すなわち暗黙的に再プレイの意思表示をしたプレイアブル広告に限って広告配信日時などがプッシュ通知されることになる。故に、ユーザは能動的に再プレイを望むプレイアブル広告を選択してプッシュ通知を受け取ることができる。

なお、図５には、お気に入り登録部３２３、閲覧履歴データおよびお気に入りデータが描かれていないものの、通知生成部３５２は図２の例と同様に閲覧履歴データおよび／またはお気に入りデータに基づいてプッシュ通知の対象者のフィルタリングを行い得る。

データ登録部３５３は、受信部３４１からセーブデータ／リプレイデータ登録要求を受け取る。データ登録部３５３は、セーブデータ／リプレイデータ登録要求の主体のユーザ識別子に対応付けて、セーブデータ／リプレイデータをユーザデータ記憶部３６１に書き込む。

また、データ登録部３５３は、受信部３４１からセーブデータ／リプレイデータ削除要求を受け取る。データ登録部３５３は、セーブデータ／リプレイデータ削除要求の対象となるセーブデータ／リプレイデータをユーザデータ記憶部３６１から削除する。

なお、図５の広告サーバ３００は、セーブデータおよびリプレイデータの必ずしも両方を管理する必要はなく一方のみを管理してもよい。

共有制御部３５４は、ユーザデータ記憶部３６１に保存されているセーブデータ／リプレイデータの共有を制御する。具体的には、共有制御部３５４は、受信部３４１からセーブデータ／リプレイデータ共有要求を受け取る。共有制御部３５４は、セーブデータ／リプレイデータ共有要求の許可／拒否を判定し、要求を拒否する場合にはその旨を示すコードを応答として送信部３４２へ送る。他方、共有制御部３５４は、要求を許可する場合には、要求の対象となるセーブデータ／リプレイデータをユーザデータ記憶部３６１から読み出す。そして、共有制御部３５４は、要求が許可された旨のコードと、読み出したセーブデータ／リプレイデータとを当該要求に対する応答に含めて送信部３４２へ送る。

ここで、共有制御部３５４は、例えば、ユーザ単位、プレイアブル広告単位、またはセーブデータ／リプレイデータ単位で設定されたアクセス権限に基づいて、セーブデータ／リプレイデータ共有要求の許可／拒否を判定し得る。アクセス権限は、ユーザが自由に編集可能としてもよいし、広告サーバ３００の運営者が一括で設定してもよい。

アクセス権限は、例えば以下の（ａ）〜（ｄ）のようなものであり得る。
（ａ）ユーザＡの全てのプレイアブル広告の全てのセーブデータ／リプレイデータは、本人以外と共有しない。

（ｂ）ユーザＢのプレイアブル広告Ｃのセーブデータ／リプレイデータは、本人およびホワイトリストにあるユーザ間でのみ共有する。ここで、ホワイトリストには、例えば、ユーザのフォロワー、ユーザがフォローしているユーザ、ユーザのフレンド、ユーザが個別指定した他のユーザ、などが登録され得る。

（ｃ）ユーザＤのプレイアブル広告ＥのセーブデータＦは、本人およびブラックリストに登録されていない全てのユーザと共有する。ここで、ブラックリストには、例えば、ユーザ間で共通のＮＧユーザリストに登録されているユーザ、ユーザが個別指定した他のユーザ、などが登録され得る。
（ｄ）ユーザＧのプレイアブル広告ＨのリプレイデータＩは、全ユーザに共有される。

図５の例において種々の記憶部は、ユーザデータ記憶部３６１と、広告記憶部３６２と、スケジュール記憶部３６３とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

ユーザデータ記憶部３６１は、種々のユーザデータ、具体的には、ユーザリストデータ、セーブデータおよびリプレイデータを保存する。なお、図５の例ではユーザデータ記憶部３６１は複数種類のデータを保存しているが、個別のデータを保存する複数の記憶部、例えば、ユーザリストデータ記憶部、セーブデータ記憶部およびリプレイデータ記憶部に機能分割されてよい。

セーブデータ／リプレイデータは、データ登録部３５３によって書き込まれ、または書き換えられる。また、セーブデータ／リプレイデータは、共有制御部３５４によって読み出される。ただし、セーブデータおよびリプレイデータの一方が、図５の広告サーバ３００によって管理されないこともあり得る。この場合には、セーブデータおよびリプレイデータの一方がユーザデータ記憶部３６１に保存されなくてもよい。

広告記憶部３６２は、図２の広告記憶部３３２と同一または類似であり得る。スケジュール記憶部３６３は、図２のスケジュール記憶部３６３と同一または類似であり得る。

次に、図６を用いて、１つのプレイアブル広告（第１の広告）の１回の配信についての図５の広告サーバ３００の動作例を説明する。
まず、配信制御部３５１は、第１の広告について広告配信日時および広告配信ページを決定する（ステップＳ４１１）。なお、広告配信ページは、第１のオンラインサービスに関する特定のＷｅｂページに限らず全Ｗｅｂページであってもよい。

次に、通知生成部３５２は、ステップＳ４１１において決定された広告配信日時および広告配信ページに基づいて、これらを示す通知データを生成する（ステップＳ４１２）。ステップＳ４１２の後に、処理はステップＳ４１３へと進む。

ステップＳ４１３において、通知生成部３５２は、ユーザリストデータに登録されたユーザのうち未処理のユーザの１人を選択する。そして、送信部３４２は、ステップＳ４１３において選択したユーザの端末１００へステップＳ４１２において生成した通知データをプッシュ通知する（ステップＳ４１４）。ステップＳ４１４の後に、処理はステップＳ４１５へと進む。

ステップＳ４１５において、通知生成部３５２は、ユーザリストデータに登録された全てのユーザについて、ステップＳ４１３乃至ステップＳ４１４の処理が済んでいるか否かを判定する。未処理のユーザが残存していれば処理はステップＳ４１３へ戻り、そうでなければ処理はステップＳ４１６へ進む。

なお、図６の例では広告サーバ３００はユーザリストデータに登録された全てのユーザを処理対象としているが、広告サーバ３００はユーザリストデータに登録されたユーザの一部に限って処理対象としてもよい。すなわち、「ユーザリストデータに登録された全てのユーザ」は、「ユーザリストデータに登録されたユーザのうち処理対象として選ばれた全てのユーザ」に読み替えられ得る。また、図６の例では、通知生成部３５２は、プッシュ通知の対象者のフィルタリングを全く行っていない。しかしながら、通知生成部３５２は、第１の実施形態および本実施形態において説明したように、閲覧履歴データ、お気に入りデータおよび／またはセーブデータに基づいて、プッシュ通知の対象者をフィルタリングしてもよい。

ステップＳ４１６では、広告サーバ３００はステップＳ４１１において決定された広告配信日時を待ち受ける。広告配信日時が到来すると、処理はステップＳ４１７へ進む。ステップＳ４１７において、送信部３４２は、ステップＳ４１１において決定された広告配信ページを閲覧しているユーザの端末１００へ第１の広告のデータを送信する。なお、ステップＳ４１７において、送信部３４２は、ユーザの端末１００が、ステップＳ４１１において決定された広告配信ページに埋め込まれたアドタグに従って広告サーバ３００に広告を要求したことをトリガとして、第１の広告のデータを端末１００へ送信してもよい。

以上説明したように、第２の実施形態に係る広告サーバは、プレイアブル広告のセーブデータ／リプレイデータを保持しておき、ユーザがプレイアブル広告のプレイする時に本人または他人のセーブデータ／リプレイデータを利用できるようにする。故に、この広告サーバによれば、例えば、ボリュームの大きなプレイアブル広告を徐々に進行させる、難所に繰り返し挑戦して達成感を味わう、過去の自分または他人のプレイを参考にして自らのプレイを研鑽する、などの高度なゲーム体験をユーザに提供することができる。故に、この広告サーバによれば、ユーザが能動的かつ反復的にプレイアブル広告をプレイするように促すことができる。

（第３の実施形態）
前述のように、第１の実施形態に係る広告サーバは、広告配信日時などをユーザの端末へプッシュ通知することで、ユーザの能動的かつ反復的な広告の閲覧を支援する。第３の実施形態に係る広告サーバは、ユーザがオンラインサービスを利用中に配信する広告を、当該オンラインサービスにおける当該ユーザの活動実績に基づいて選択する。

以下、図７および図８を用いて、第３の実施形態に係る広告サーバ３００について詳しく説明する。なお、第１の実施形態または第２の実施形態と重複する説明については基本的に省略する。
まず、図７を用いて第３の実施形態に係る広告サーバ３００の構成例の説明を続ける。図７の広告サーバ３００は、通信部３７０と、広告配信部３８０と、種々の記憶部とを含む。

通信部３７０は、例えば前述の通信Ｉ／Ｆであってよく、ネットワーク経由で、例えば端末１００およびＷｅｂサーバ２００からデータを受信したり、端末１００およびＷｅｂサーバ２００へデータを送信したりする。具体的には、通信部３７０は、受信部３７１および送信部３７２を含む。送信部３７２は、図２の送信部３１２または図５の送信部３４２と同一または類似であり得る。

受信部３７１は、ユーザの活動実績データをＷｅｂサーバ２００から受信する。活動実績データは、Ｗｅｂサーバ２００が提供する第１のオンラインサービスにおけるユーザの活動実績を表す。活動実績は、例えば、第１のオンラインサービスにおける、コンテンツの視聴履歴、コンテンツまたはコメントの投稿履歴、商品（コンテンツなどの無体物を含む）の売買履歴、検索履歴、などを含み得る。受信部３７１は、活動実績データを活動実績取得部３８３へ送る。

広告配信部３８０は、前述のプロセッサおよびメモリであってよい。広告配信部３８０は、ユーザの活動実績データ、などを通信部３７０から受け取る。また、広告配信部３８０は、種々の記憶部から必要なデータを読み出す。広告配信部３８０は、通信部３７０から受け取ったデータおよび／または種々の記憶部から読み出したデータに基づいて、広告の配信をスケジュール（広告の選択を含む）および実施したり、ユーザにスケジューリング結果をプッシュ通知するための通知データを生成したりする。さらに、広告配信部３８０は、広告のデータ、通知データ、などを通信部３７０へ送る。具体的には、広告配信部３８０は、配信制御部３８１と、通知生成部３８２と、活動実績取得部３８３とを含む。

配信制御部３８１は、広告の選択を行う以外は、図２の配信制御部３２１または図５の配信制御部３５１と同一または類似であり得る。故に以下では、配信制御部３８１による広告の選択について説明する。

配信制御部３８１は、ユーザデータ記憶部３９１から活動実績データを読み出す。そして、配信制御部３８１は、ユーザ毎に、または活動実績データに基づいてユーザに付与されるラベル毎に、広告記憶部３９２に保存されている配信可能な複数の広告の１つを、当該ユーザまたは当該ラベルが付与されたユーザへ配信する広告として選択する。ここで、ラベルは、ユーザをそのオンラインサービスにおける活動実績に基づいてカテゴライズするための属性データであってよく、例えば、「熱心な動画投稿」、「たまに動画視聴」、「ゲーム実況好き」、「週末中心」、「長期ユーザ」、「あるコンテンツを視聴中／視聴済み」などであり得る。また、１人のユーザに、複数のラベルが付与されてもよいし、全くラベルが付与されなくてもよい。通常、ラベルの数はユーザの数に比べて少ないので、ラベル毎に広告を選択することで、配信制御部３８１の広告の選択に関わる計算量を抑えることができる。

配信制御部３８１は、活動実績データに基づいて、ユーザの好みそうな商材を扱った広告、ユーザの好みそうなゲーム体験を提供するプレイアブル広告、などを選択してよい。なお、広告には、メタデータとして、例えば、広告のジャンルを表す広告カテゴリ、広告のキーワードとなる広告タグ、などが付与されてもよい。メタデータは、広告主、広告サーバ３００の運営者、またはオンラインサービスの提供者によって定められてもよいし、ユーザにより編集可能としてもよい。これらのメタデータは、広告のデータに対応付けて広告記憶部３９２に保存され得る。配信制御部３８１は、活動実績データに加えてかかるメタデータを利用することで、ユーザの好みに合った広告を選択してもよい。

通知生成部３８２は、図２の通知生成部３２２または図５の通知生成部３５２と同一または類似であり得る。
活動実績取得部３８３は、受信部３７１からユーザ毎の活動実績データを受け取る。活動実績取得部３８３は、ユーザ識別子に対応付けて、活動実績データをユーザデータ記憶部３９１に書き込む。

図７の例において種々の記憶部は、ユーザデータ記憶部３９１と、広告記憶部３９２と、スケジュール記憶部３９３とを含む。これらの記憶部は、前述のメモリ単体であってもよいし、メモリおよび補助記憶装置の組み合わせであってもよい。

ユーザデータ記憶部３９１は、種々のユーザデータ、具体的には、ユーザリストデータおよび活動実績データを保存する。なお、図７の例ではユーザデータ記憶部３９１は複数種類のデータを保存しているが、個別のデータを保存する複数の記憶部、例えば、ユーザリストデータ記憶部および活動実績データ記憶部に機能分割されてよい。
活動実績データは、活動実績取得部３８３によって書き込まれ、または書き換えられる。また、活動実績データは、配信制御部３８１によって読み出される。

広告記憶部３９２は、第１の広告を含む複数の広告のデータを保存する。スケジュール記憶部３９３は、図２のスケジュール記憶部３３３または図５のスケジュール記憶部３６３と同一または類似であり得る。

次に、図８を用いて、１つの広告群の１回の配信についての図７の広告サーバ３００の動作例を説明する。
まず、配信制御部３８１は、ある広告群（ここでは、広告群は複数の広告を含む）について広告配信日時および広告配信ページを決定する（ステップＳ４２１）。なお、広告配信ページは、第１のオンラインサービスに関する特定のＷｅｂページに限らず全Ｗｅｂページであってもよい。ステップＳ４２１の後に、処理はステップＳ４２２へと進む。

ステップＳ４２２において、配信制御部３８１は、ユーザリストデータに登録されたユーザのうち未処理のユーザの１人（または、全ラベルのうち未処理のラベルの１つ）を選択する。そして、配信制御部３８１は、ステップＳ４２２において選択したユーザ（またはステップＳ４２２において選択したラベルを付与されたユーザ）の活動実績データに基づいて、当該ユーザへ配信する広告を広告群から選択する（ステップＳ４２３）。

通知生成部３８２は、ステップＳ４２２において選択されたユーザ（またはステップＳ４２２において選択されたラベルを付与されたユーザ）向けの通知データを生成する（ステップＳ４２４）。そして、送信部３７２は、ステップＳ４２２において選択されたユーザ（またはステップＳ４２２において選択されたラベルを付与されたユーザ）の端末１００へステップＳ４２４において生成した通知データをプッシュ通知する（ステップＳ４２５）。ステップＳ４２５の後に、処理はステップＳ４２６へと進む。

ステップＳ４２６において、配信制御部３８１は、ユーザリストデータに登録された全てのユーザ（または全てのラベル）について、ステップＳ４２２乃至ステップＳ４２５の処理が済んでいるか否かを判定する。未処理のユーザ（またはラベル）が残存していれば処理はステップＳ４２２へ戻り、そうでなければ処理はステップＳ４２７へ進む。

なお、図８の例では広告サーバ３００はユーザリストデータに登録された全てのユーザを処理対象としているが、広告サーバ３００はユーザリストデータに登録されたユーザの一部に限って処理対象としてもよい。すなわち、「ユーザリストデータに登録された全てのユーザ」は、「ユーザリストデータに登録されたユーザのうち処理対象として選ばれた全てのユーザ」に読み替えられ得る。また、図８の例では、通知生成部３８２は、プッシュ通知の対象者のフィルタリングを全く行っていない。しかしながら、通知生成部３８２は、第１の実施形態または第２の実施形態において説明したように、閲覧履歴データ、お気に入りデータおよび／またはセーブデータに基づいて、プッシュ通知の対象者をフィルタリングしてもよい。

ステップＳ４２７では、広告サーバ３００はステップＳ４２１において決定された広告配信日時を待ち受ける。広告配信日時が到来すると、処理はステップＳ４２８へ進む。ステップＳ４２８において、送信部３７２は、ステップＳ４２１において決定された広告配信ページを閲覧しているユーザの端末１００へ、ステップＳ４２３において選択した広告のデータを送信する。なお、ステップＳ４２８において、送信部３７２は、ユーザの端末１００が、ステップＳ４２１において決定された広告配信ページに埋め込まれたアドタグに従って広告サーバ３００に広告のデータを要求したことをトリガとして、ステップＳ４２３において選択した広告のデータを端末１００へ送信してもよい。

以上説明したように、第３の実施形態に係る広告サーバは、ユーザがオンラインサービス中に配信する広告を、当該ユーザの当該オンラインサービスにおける活動実績に基づいて選択する。故に、この広告サーバによれば、例えば、ユーザの好みそうな商材を扱った広告、ユーザの好みそうなゲーム体験を提供するプレイアブル広告、などを選択して配信して、ユーザが能動的かつ反復的に広告を閲覧するように促すことができる。また、ユーザの活動実績により配信される広告が変化する点は、ユーザのオンラインサービスにおける活動を方向付ける効果もある。例えば、特定の広告の配信を望むユーザに、オンラインサービスにおいて特定の行動（例えば動画の投稿）を行うように誘導することができる。

（変形例１）
前述の第１の実施形態乃至第３の実施形態によれば、配信制御部３２１（または、配信制御部３５１もしくは配信制御部３８１）は、リアルタイムコンテンツ共有サービスにおいてあるリアルタイムコンテンツ（第１のリアルタイムコンテンツ）を配信または視聴しているユーザを、プレイアブル広告としての第１の広告の配信対象として決定し得る。

これにより、広告そのものの効果に留まらず、第１のリアルタイムコンテンツへの波及効果、例えば、当該第１のリアルタイムコンテンツの配信者および視聴者が同時並行的に同じプレイアブル広告が遊べるようになることで、例えば、話題の提供、盛り上げ効果、などを期待できる。

この変形例において、通知生成部３２２（または、通知生成部３５２もしくは通知生成部３８２）は、第１のリアルタイムコンテンツを示す通知データをさらに生成し、送信部３１２（または、送信部３４２もしくは送信部３７２）へ送ってもよい。

この通知データをユーザの端末１００へプッシュ通知することで、ユーザは気になる広告やお気に入りの広告が配信される日時に、第１のリアルタイムコンテンツを閲覧するように促される。これは、第１のオンラインサービスの運営側からすれば、第１のリアルタイムコンテンツにユーザを集客できることを意味する。

さらに、この通知データは、第１のリアルタイムコンテンツを視聴するためのページへのリンクを含んでいてもよい。これにより、ユーザを迅速かつ確実に第１のリアルタイムコンテンツへ誘導することができる。この通知データは、例えば、「５分後に、○○動画共有サイトで生放送中の番組「△△のゲーム実況」に××広告が掲載されます！遊びたい方は、今すぐこのＵＲＬへ！」などのリンク付きメッセージとして端末１００の画面に表示され得る。

（変形例２）
前述の第１の実施形態乃至第３の実施形態によれば、配信制御部３２１（または、配信制御部３５１もしくは配信制御部３８１）は、ユーザをプレイアブル広告としての第１の広告の配信対象として決定し、さらにプレイアブル広告のスコアをランキング化してユーザに発表してもよい。これは、例えば上記変形例１との組み合わせることで、ランキング結果を第１のリアルタイムコンテンツにおいて、例えば、さらなる話題の提供、盛り上げ効果、などを期待できる。

ランキングは、例えば広告サーバ３００または他のサーバに内蔵される図示されないランキング作成部によって作成され得る。ランキング作成部は、プレイアブル広告を遊んだユーザのスコアを収集し、これらをソートしてランキングを作成する。スコアは、前述のように端末１００において算出されてもよいし、ゲームサーバまたは広告サーバ３００において算出されてもよいが、チート対策の観点では後者において行う方が好ましい。

ランキングの順位またはスコアに応じて、ユーザに特典が付与されてもよい。特典は、オンラインサービスまたはプレイアブル広告（これは、ランキングの対象となったプレイアブル広告と同一であっても異なっていてもよい）において使用可能なポイント、アイテム、ゲーム内通貨、などであってもよいし、オンラインサービスまたはプレイアブル広告における何らかの権限（例えば、特定のコンテンツを視聴する権利、特定のイベントを発生させる権利、など）であってもよいし、その他の商品またはサービス（例えば、広告の商材）であってもよい。
なお、ランキングは、同時並行的にプレイアブル広告を遊んだユーザに限らず、異なる時間にプレイアブル広告を遊んだユーザのスコアを対象としてもよい。

そして、送信部３１２（または、送信部３４２もしくは送信部３７２）は、ランキング作成部によって作成されたランキングをユーザの端末１００へ送信する。

（変形例３）
第３の実施形態では、配信制御部３８１は、ユーザまたはユーザに付与されたラベル毎に配信する広告を選択する、と説明した。しかしながら、例えば、配信制御部３８１は、コンテンツ共有サービスにおいて何らかのコンテンツを配信／視聴中のユーザに配信する広告を、当該コンテンツまたはコンテンツに付与されたメタデータ毎に選択することもできる。

ここで、コンテンツのメタデータは、例えば、動画のジャンルを表す動画カテゴリ、動画のキーワードとなる動画タグ、などを含み得る。メタデータは、コンテンツの配信者、またはＷｅｂサーバ２００（この例ではコンテンツ共有サービスの提供サーバ）の運営者によって定められてもよいし、コンテンツの視聴者を含むユーザにより編集可能としてもよい。

この変形例において、配信制御部３８１は、例えば、コンテンツの属性（例えば、上記メタデータを含み得る）、および／または、コンテンツの配信者および／または視聴者であるユーザの属性（例えば、上記ラベルおよび／または活動実績データを含み得る）に基づいて、当該コンテンツを配信／視聴中のユーザに配信する広告を選択してもよい。

（変形例４）
なお、第３の実施形態および上記変形例３の説明では、配信制御部３８１は、ユーザ（またはユーザに付与されたラベル）またはコンテンツ（またはコンテンツに付与されたメタデータ）毎に、配信する広告を選択すると説明した。これに加えてまたは代えて、配信制御部３８１は、例えばユーザ（またはユーザに付与されたラベル）またはコンテンツ（またはコンテンツに付与されたメタデータ）毎に、プレイアブル広告のプレイ条件を選択することもできる。

プレイ条件は、例えば、プレイヤキャラクタ、プレイヤキャラクタのロール、ステータス、強さ、所持アイテム、または所持金、など、プレイステージ、プレイ可能時間、イベント発生の有無、など様々であり得る。なお、第２の実施形態において説明したセーブデータを利用する場合にも、プレイ条件として、ゲーム再開時に付与されるボーナス、例えばアイテム、経験値、お金、などの質または量などを変化させることができる。

同じプレイアブル広告であってもプレイ条件が変化することで、ユーザにプレイする度に新鮮味のあるゲーム体験を提供することができる。すなわち、飽きにくいプレイアブル広告を配信することが可能となる。

上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。

上述の実施形態では、いくつかの機能部を説明したが、これらは各機能部の実装の一例に過ぎない。例えば、１つの装置に実装されると説明された複数の機能部が複数の別々の装置に亘って実装されることもあり得るし、逆に複数の別々の装置に亘って実装されると説明された機能部が１つの装置に実装されることもあり得る。

上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。

上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。

１００・・・端末
２００・・・Ｗｅｂサーバ
３００・・・広告サーバ
３１０，３４０，３７０・・・通信部
３１１，３４１，３７１・・・受信部
３１２，３４２，３７２・・・送信部
３２０，３５０，３８０・・・広告配信部
３２１，３５１，３８１・・・配信制御部
３２２，３５２，３８２・・・通知生成部
３２３・・・お気に入り登録部
３３１，３６１，３９１・・・ユーザデータ記憶部
３３２，３６２，３９２・・・広告記憶部
３３３，３６３，３９３・・・スケジュール記憶部
３５３・・・データ登録部
３５４・・・共有制御部
３８３・・・活動実績取得部

Claims (13)

1. ユーザリストデータに登録されたユーザが広告配信ページを広告配信日時に閲覧する場合に当該ユーザの端末へ配信される第１の広告について、将来の日時を前記広告配信日時として決定し、第１のオンラインサービスに関するＷｅｂページのいずれかを前記広告配信ページとして決定する配信制御部と、
   前記広告配信日時を示す第１の通知データを生成する通知生成部と
   前記広告配信日時の到来前に、前記第１の通知データを前記ユーザリストデータに登録された少なくとも一部のユーザの端末へプッシュ通知する送信部と
   を具備し、
   前記送信部は、前記ユーザリストデータに登録されたユーザのうち、当該ユーザが過去に閲覧した第１の広告群のいずれにも前記第１の広告が一致しないユーザの端末へ前記第１の通知データをプッシュ通知しない、
   広告サーバ。
2. ユーザリストデータに登録されたユーザが広告配信ページを広告配信日時に閲覧する場合に当該ユーザの端末へ配信される第１の広告について、将来の日時を前記広告配信日時として決定し、第１のオンラインサービスに関するＷｅｂページのいずれかを前記広告配信ページとして決定する配信制御部と、
   前記広告配信日時を示す第１の通知データを生成する通知生成部と
   前記広告配信日時の到来前に、前記第１の通知データを前記ユーザリストデータに登録された少なくとも一部のユーザの端末へプッシュ通知する送信部と
   を具備し、
   前記送信部は、前記ユーザリストデータに登録されたユーザのうち、当該ユーザによって広告単位で指定された第２の広告群のいずれにも前記第１の広告が一致しないユーザの端末へ前記第１の通知データをプッシュ通知しない、
   広告サーバ。
3. ユーザリストデータに登録されたユーザが広告配信ページを広告配信日時に閲覧する場合に当該ユーザの端末へ配信される第１の広告について、将来の日時を前記広告配信日時として決定し、第１のオンラインサービスに関するＷｅｂページのいずれかを前記広告配信ページとして決定する配信制御部と、
   前記広告配信日時を示す第１の通知データを生成する通知生成部と
   前記広告配信日時の到来前に、前記第１の通知データを前記ユーザリストデータに登録された少なくとも一部のユーザの端末へプッシュ通知する送信部と
   を具備し、
   前記第１の広告は、前記ユーザが前記端末に対して行った操作に依存して出力画像および出力音声の少なくとも一方が変化するプレイアブル広告であって、
   前記送信部は、前記ユーザリストデータに登録されたユーザのうち、当該ユーザがセーブデータを保存したプレイアブル広告群のいずれにも前記第１の広告が一致しないユーザの端末へ前記第１の通知データをプッシュ通知しない、
   広告サーバ。
4. 前記配信制御部は、前記第１のオンラインサービスに関する第１のＷｅｂページを前記広告配信ページとして決定し、
   前記通知生成部は、さらに、前記第１のＷｅｂページを示す第２の通知データを生成し、
   前記送信部は、さらに、前記広告配信日時の到来前に、前記第２の通知データを前記端末へプッシュ通知する、
   請求項１乃至請求項３のいずれか１項に記載の広告サーバ。
5. 前記第２の通知データは、前記第１のＷｅｂページへのリンクを含む、請求項４に記載の広告サーバ。
6. 前記第１の広告は、前記ユーザが前記端末に対して行った操作に依存して出力画像および出力音声の少なくとも一方が変化するプレイアブル広告であって、
   前記送信部は、さらに、前記ユーザまたは他のユーザが前記第１の広告を過去に遊んだ時のリプレイデータを前記端末へ送信する、
   請求項１または請求項２に記載の広告サーバ。
7. 前記第１の広告は、前記ユーザが前記端末に対して行った操作に依存して出力画像および出力音声の少なくとも一方が変化するプレイアブル広告であって、
   前記送信部は、さらに、前記ユーザまたは他のユーザが過去に遊んだ前記第１の広告のセーブデータを前記端末へ送信する、
   請求項１または請求項２に記載の広告サーバ。
8. 前記第１のオンラインサービスは、リアルタイムコンテンツの共有サービスであって、
   前記第１の広告は、前記ユーザが前記端末に対して行った操作に依存して出力画像および出力音声の少なくとも一方が変化するプレイアブル広告であって、
   前記配信制御部は、前記第１のオンラインサービスにおいて第１のリアルタイムコンテンツを視聴するためのページを前記広告配信ページとして決定する、
   請求項１または請求項２に記載の広告サーバ。
9. 前記第１の広告は、前記ユーザが前記端末に対して行った操作に依存して出力画像および出力音声の少なくとも一方が変化し、かつ、進行状態の遷移に依存してスコアが変動するプレイアブル広告であって、
   前記広告サーバは、前記第１の広告を遊んだユーザ間の前記スコアのランキングを作成するランキング作成部をさらに具備し、
   前記送信部は、さらに、前記ランキングを前記端末へ送信する、
   請求項８に記載の広告サーバ。
10. 前記第１のオンラインサービスにおける前記ユーザの活動実績を示す活動実績データを取得する活動実績取得部をさらに具備し、
    前記配信制御部は、前記活動実績データに基づいて、前記ユーザリストデータに登録されたユーザ毎、または前記活動実績に基づいて前記ユーザに付与されるラベル毎に、複数の広告の中から前記第１の広告を選択する、
    請求項１乃至請求項９のいずれか１項に記載の広告サーバ。
11. 前記第１の広告の画像は、前記端末の画面において前記第１のオンラインサービスに関するＷｅｂページを表示する領域によって互いに隔てられた複数の異なる領域に亘って表示される、請求項１乃至請求項１０のいずれか１項に記載の広告サーバ。
12. コンピュータを、
    ユーザリストデータに登録されたユーザが広告配信ページを広告配信日時に閲覧する場合に当該ユーザの端末へ配信される第１の広告について、将来の日時を前記広告配信日時として決定し、第１のオンラインサービスに関するＷｅｂページを閲覧しているユーザを前記広告配信ページとして決定する手段、
    前記広告配信日時を示す第１の通知データを生成する手段、
    前記広告配信日時の到来前に、前記第１の通知データを前記ユーザリストデータに登録された少なくとも一部のユーザの端末へプッシュ通知する手段、
    として機能させ、
    前記プッシュ通知する手段は、前記ユーザリストデータに登録されたユーザのうち、当該ユーザが過去に閲覧した第１の広告群のいずれにも前記第１の広告が一致しないユーザの端末へ前記第１の通知データをプッシュ通知しない、
    広告配信プログラム。
13. コンピュータを、
    ユーザリストデータに登録されたユーザが広告配信ページを広告配信日時に閲覧する場合に当該ユーザの端末へ配信される第１の広告について、将来の日時を前記広告配信日時として決定し、第１のオンラインサービスに関するＷｅｂページを閲覧しているユーザを前記広告配信ページとして決定する手段、
    前記広告配信日時を示す第１の通知データを生成する手段、
    前記広告配信日時の到来前に、前記第１の通知データを前記ユーザリストデータに登録された少なくとも一部のユーザの端末へプッシュ通知する手段、
    として機能させ、
    前記プッシュ通知する手段は、前記ユーザリストデータに登録されたユーザのうち、当該ユーザによって広告単位で指定された第２の広告群のいずれにも前記第１の広告が一致しないユーザの端末へ前記第１の通知データをプッシュ通知しない、
    広告配信プログラム。