JPWO2017183703A1 - 情報処理装置、情報処理方法、情報処理システム及びプログラム - Google Patents

Abstract

ユーザが複数のデバイスを利用する場合であっても、各デバイスを関連付けて当該ユーザへの好適な広告配信を実現すること。本発明の一態様に係る情報処理装置は、ＩＰ（Internet Protocol）アドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤ（Identifier）を少なくとも含む第２の特定情報と、を取得する取得部と、前記第１の特定情報及び前記第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する制御部と、を有することを特徴とする。

Description

本発明は、広告配信に係る情報処理装置、情報処理方法、情報処理システム及びプログラムに関する。

インターネット広告として、個別のユーザに対するターゲティング広告（ターゲット広告）が広く利用されている。例えば、行動ターゲティング広告は、ユーザの行動履歴（Ｗｅｂの巡回履歴など）に基づいて、特定のジャンルに関心を持つ顧客に限定して広告を配信するものであり、広告効果（例えば、認知、理解、購入など）が高いと言われている。広告とは、一般的に、広告主の管理可能な広告媒体を通じて広告市場に流される情報のことをいい、例えば、広告主が金銭を支払って発信（宣伝）する任意の情報であってもよい。

また、ユーザが複数のデバイスにより異なるメディアが提供するサービスを受ける環境において、各デバイスで用いられるユーザ識別情報（ユーザのログイン情報など）に応じて、各メディアを介してユーザの行動を横断的に収集し、これらのデバイスにターゲティング広告を提供する技術が提案されている（特許文献１）。

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

しかしながら、ユーザのログイン情報に基づいてユーザの情報を確定的に関連付けるものとすると、例えばログインしていないデバイスのユーザの行動を収集することができない。

本発明はかかる点に鑑みてなされたものであり、ユーザが複数のデバイスを利用する場合であっても、各デバイスを関連付けて当該ユーザへの好適な広告配信を実現することができる情報処理装置、情報処理方法、情報処理システム及びプログラムを提供することを目的の１つとする。

本発明の一態様に係る情報処理装置は、ＩＰ（Internet Protocol）アドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤ（Identifier）を少なくとも含む第２の特定情報と、を取得する取得部と、前記第１の特定情報及び前記第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する制御部と、を有することを特徴とする。

本発明によれば、ユーザが複数のデバイスを利用する場合であっても、各デバイスを関連付けて当該ユーザへの好適な広告配信を実現することができる。

本発明の一実施形態に係る情報処理システムの概略構成の一例を示す図である。 本発明の第１の実施形態に係る広告配信処理のシーケンスの一例を示す図である。 １つのＩＰアドレスに関連付けられる広告ＩＤ数の関係性の一例を示す図である。 本発明の一実施形態に係るテレビの機能構成の一例を示す図である。 本発明の一実施形態に係るテレビ、デバイス、ルータ及びサーバのハードウェア構成の一例を示す図である。

本発明者らは、インターネット広告の広告効果は、事前のテレビ広告の視聴があることによって高まる傾向にあることに着目し、テレビ広告の視聴者に対してインターネット広告を配信することで、インターネット広告の広告効果を高めることを考え、本発明を見出した。

以下、本発明の実施形態について添付図面を参照して詳細に説明する。

（情報処理システム）
まず、本発明が適用される情報処理システムについて説明する。図１は、本発明の一実施形態に係る情報処理システムの概略構成の一例を示す図である。図１に示す情報処理システム１は、テレビ１０と、デバイス２０と、ルータ３０と、マッチングサーバ４０と、視聴ログ管理サーバ５０と、広告配信サーバ６０と、を含む。

本発明の一実施形態では、図１に示した情報処理システムの構成において、マッチングサーバ４０が、テレビ１０から送信された情報及びデバイス２０から送信された情報に基づいて、同一のユーザによって利用されるテレビ１０及びデバイス２０を特定する。また、広告配信サーバ６０は、マッチングサーバ４０と連携し、マッチング処理に成功したユーザ（デバイス２０）に対して、テレビ１０の視聴履歴が考慮されたインターネット広告（以下、単に広告とも呼ぶ）を配信する。これにより、所定のテレビ番組を視聴するユーザに対して、好適な広告を配信し、高い広告効果を達成することができる。

テレビ（テレビ受像機）１０は、地上波放送、放送衛星（ＢＳ：Broadcasting Satellite）／通信衛星（ＣＳ：Communications Satellite）による放送などの少なくとも１つを受信する機能を有する装置である。なお、テレビ１０は、インターネット放送（インターネットテレビ）を受信する機能を有してもよい。テレビ１０は、受信した放送を表示（描画）してもよい。

テレビ１０は、ユーザの同意に基づいて、テレビ１０に関する視聴ログ（テレビ視聴ログ、放送視聴ログなどと呼ばれてもよい）を収集し、視聴ログ管理サーバ５０に送信することができる。

ここで、視聴ログは、テレビ１０で視聴されるコンテンツを時系列に沿って記録した情報のことをいう。また、例えば、視聴ログは、視聴された番組情報、視聴されたコマーシャル（ＣＭ：Commercial Message）などに関する情報を含んでもよい。また、視聴ログは、テレビ１０を介した地上波放送などの視聴行動、タイムシフト再生、ブラウザ起動、ネットサービスの実行などの少なくとも１つを特定することができる情報を含んでもよい。また、視聴ログには、視聴番組、視聴行動などに対応してタイムスタンプが付されることが好ましい。

デバイス２０は、ユーザの操作によりブラウザなどのアプリケーションを実行する装置である。また、デバイス２０は、アプリケーションの動作に伴い、広告配信サーバ６０から広告を受信する。

テレビ１０及びデバイス２０はそれぞれ、携帯電話、スマートフォン、タブレット型端末などの携帯端末（移動通信端末）であってもよいし、パソコン（ＰＣ：Personal Computer）、テレビ（ＴＶ）、多機能テレビ、スマートＴＶ、ＩＰ（Internet Protocol）ＴＶ、セットトップボックスなどの固定通信端末であってもよい。つまり、本明細書におけるテレビ１０は、テレビ以外の装置に読み替えることができる。

ルータ３０は、インターネットプロバイダからＩＰアドレスを割り当てられ、ＬＡＮ（Local Area Network）内の装置とＷＡＮ（Wide Area Network）側の装置との通信を中継する。テレビ１０及びデバイス２０は、有線及び／又は無線（例えば、Ｗｉ−Ｆｉ（登録商標））でルータ３０に接続される。同じＬＡＮ内に含まれるテレビ１０及びデバイス２０は、ルータ３０を介して外部のネットワーク（インターネットなど）と通信する。

図１の構成では、テレビ１０及びデバイス２０の通信において、通信相手から見えるＩＰアドレスは、ルータ３０のＩＰアドレス（同一のＩＰアドレス）となる。これは、ルータ３０のＩＰマスカレード（ＮＡＰＴ：Network Address Port Translation）機能などにより実現される。なお、ＩＰアドレスはＩＰｖ４及びＩＰｖ６のいずれでもよいし、これらを拡張／変形したアドレスであってもよい。

マッチングサーバ４０は、同一のユーザが利用するテレビ１０及びデバイス２０を関連付ける（マッチングする）機能を有する装置である。具体的には、マッチングサーバ４０は、テレビ１０を特定するテレビ特定情報（テレビ視聴ログ特定情報）と、デバイス２０を特定するデバイス特定情報（広告識別子（ＩＤ：Identifier）特定情報）と、に基づいて、テレビ１０とデバイス２０との組み合わせを特定する。テレビ１０（テレビ１０の視聴ログ）とデバイス２０との組み合わせは、所定のユーザに関する情報であるため、ユーザ情報と呼ばれてもよい。

ここで、広告ＩＤは、例えば、ユーザによってオプトアウト可能な、匿名かつ一意な広告配信用の識別子（広告に関する識別子）である。広告ＩＤは、デバイス２０のブラウザに保存される小さなファイル（クッキー（Cookie））に関する固有のクッキーＩＤ（Cookie ID）であってもよい。なお、クッキーＩＤは、ブラウザごとにそれぞれ異なるＩＤであってもよい。

また、広告ＩＤは、デバイス２０にインストールされるアプリケーションから取得される識別子であってもよく、例えば、ＩＤＦＡ（Identification For Advertisers）、ＡＤＩＤ（Advertising ＩＤ）などであってもよい。

なお、テレビ特定情報は、ＴＶＩＤと呼ばれてもよいし、デバイス特定情報は、ＷｅｂＩＤと呼ばれてもよい。

視聴ログ管理サーバ５０は、テレビ１０に関する視聴ログを管理（収集、分析など）する機能を有する装置である。視聴ログ管理サーバ５０は、テレビ１０のメーカーが保有するものであってもよいし、テレビ１０に放送を行う放送局（テレビ局）が保有するものであってもよい。

広告配信サーバ６０は、少なくともデバイス２０に対して、インターネット広告を配信する機能を有する装置である。広告は、例えば、テキスト、画像（静止画像、動画像）、音声、その他のメディア又はこれらの組み合わせにより構成されてもよい。なお、広告配信サーバ６０は、広告以外のコンテンツをデバイス２０に送信することができてもよい。

広告配信サーバ６０は、ＤＭＰ（Data Management Platform）を含んで構成されてもよく、ＤＭＰを用いて配信する広告を決定してもよい。また、広告配信サーバ６０は、ＤＳＰ（Demand Side Platform）を利用する配信サーバであってもよいし、ＤＳＰ以外の広告配信サーバ（アドサーバ）又はアドサーバを利用する配信サーバであってもよい。

アドサーバは、特定の企業（例えば、Ｔｗｉｔｔｅｒ（登録商標）社、Ｆａｃｅｂｏｏｋ（登録商標）社など）が提供するＡＰＩ（Application Programming Interface）（Ads-API）を利用する配信サーバであってもよい。また、アドサーバは、オンライン動画広告を配信する動画広告配信サーバであってもよいし、テレビ受像機向けに広告を配信するＣＭＳ（Content Management System）であってもよい。また、広告配信サーバ６０は、ＤＳＰ、ＡＰＩ、動画広告配信及びＣＭＳなどのアドサーバとの連携を、ＤＭＰ（例えば、パブリックＤＭＰ）を介して行ってもよい。

テレビ１０、デバイス２０など、各装置の機能構成及びハードウェア構成の一例については、後述する。

なお、当該システム構成は一例であり、これに限られない。例えば、各装置は、図１ではそれぞれ１つずつ含まれる構成としたが、各機器の数はこれに限られず、複数存在してもよい。また、情報処理システム１は、一部の装置を含まない構成としてもよいし、所定の装置の機能が複数の装置により実現される構成としてもよい。

また、複数の装置の機能が１つの装置により実現される構成としてもよい。例えば、マッチングサーバ４０、視聴ログ管理サーバ５０及び広告配信サーバ６０は、１つのサーバ上で実装されてもよい。

（情報処理方法）
本発明の実施形態に係る情報処理方法について、以下で説明する。各情報処理方法は、上述の情報処理システムに適用されてもよい。

＜第１の実施形態：テレビ及びデバイスのマッチング＞
第１の実施形態において、テレビ特定情報（第１の特定情報）は、テレビ１０のＩＰアドレスと、テレビ１０の視聴ログに関する情報と、を少なくとも含む。また、デバイス特定情報（第２の特定情報）は、デバイス２０のＩＰアドレスと、デバイス２０に配信される広告ＩＤに関する情報と、を少なくとも含む。なお、デバイス特定情報は、デバイス２０のウェブ閲覧ログ（ウェブアクセスログ）を含んでもよい。

図２は、本発明の第１の実施形態に係る広告配信処理のシーケンスの一例を示す図である。テレビ１０は、視聴ログを視聴ログ管理サーバ５０に送信することができる（ステップＳＴ１０１）。視聴ログの送信のタイミングは、周期的（例えば、１時間ごと、１日ごとなど）であってもよいし、任意のタイミングであってもよい。視聴ログ管理サーバ５０は、テレビ１０のＩＰアドレス（つまりルータ３０のＩＰアドレス）と、テレビ１０の視聴ログに関する情報と、を取得し、これらの組をテレビ特定情報として蓄積してもよい（ステップＳＴ１０２）。

デバイス２０は、ウェブブラウジング及び／又はアプリケーションの利用中に、広告配信サーバ６０から広告を配信される（ステップＳＴ１０３）。この際、広告配信サーバ６０は、デバイス２０のＩＰアドレス（つまりルータ３０のＩＰアドレス）を取得し、当該ＩＰアドレスと広告ＩＤ（例えば、クッキーＩＤ）との組をデバイス特定情報として蓄積してもよい（ステップＳＴ１０４）。また、広告ＩＤを蓄積する際、広告が配信された時刻及び広告ＩＤが取得された時刻の少なくとも１つを示すタイムスタンプが広告ＩＤに付されることが好ましい。

マッチングサーバ４０は、テレビ１０及び／又は視聴ログ管理サーバ５０から、テレビ特定情報を受信する（ステップＳＴ１０５）。また、マッチングサーバ４０は、デバイス２０及び／又は広告配信サーバ６０から、デバイス特定情報を受信する。マッチングサーバ４０は、デバイス２０におけるウェブ閲覧ログを、デバイス２０及び／又は広告配信サーバ６０から取得してもよい（同ステップ）。

マッチングサーバ４０は、ＩＰアドレスに基づいて、テレビ１０の視聴ログと、デバイス２０に関する広告ＩＤと、を関連付ける（ステップＳＴ１０６）。具体的には、マッチングサーバ４０は、テレビ１０のＩＰアドレスとデバイス２０のＩＰアドレスが、同一か否かを判断（マッチング）し、同一の場合には、当該ＩＰアドレスと、対応する視聴ログと、対応する広告ＩＤとの組み合わせ（ユーザ情報と呼ばれてもよい）を保存する。

マッチングサーバ４０は、テレビ１０の視聴ログに付されるタイムスタンプと、広告ＩＤに付されるタイムスタンプと、に基づいて、マッチング処理の実施を行う対象か否かを判断してもよい。例えば、マッチングサーバ４０は、両タイムスタンプで求められる時間差が所定の値以下の場合、視聴ログ及び広告ＩＤが同一の時間に取得されたものと判断して、マッチング処理を行うように制御してもよい。

なお、各装置（例えば、マッチングサーバ４０、テレビ１０、視聴ログ管理サーバ５０など）は、テレビ１０のＩＰアドレスと、テレビ１０の視聴ログに関する情報と、テレビ１０の視聴ログに付されるタイムスタンプと、の組をＴＶＩＤとして、１つ以上のＴＶＩＤから、ＴＶＩＤに関するテーブルを構築及び保持してもよい。ＴＶＩＤからはいずれかの情報を除いてもよい。

また、各装置（例えば、マッチングサーバ４０、デバイス２０、広告配信サーバ６０など）は、デバイス２０のＩＰアドレスと、デバイス２０に配信される広告ＩＤに関する情報と、当該広告ＩＤに関するタイムスタンプと、の組をＷｅｂＩＤとして、１つ以上のＷｅｂＩＤから、ＷｅｂＩＤに関するテーブルを構築及び保持してもよい。ＷｅｂＩＤからはいずれかの情報を除いてもよい。

当該関連付けの実施のタイミングは、周期的（例えば、１時間ごと、１日ごとなど）であってもよいし、任意のタイミングであってもよい。ＩＰアドレスによって関連付けられるテレビ１０及びデバイス２０の個数は、１対１に限られず、１対多、多対１、及び多対多であってもよい。なお、ＩＰアドレスには、ウェブ閲覧ログも関連付けられてもよい。

マッチングサーバ４０は、例えば、所定のユーザのテレビ１０の視聴ログに基づいて、広告配信対象の広告ＩＤ（クッキーＩＤなど）を決定し、広告配信サーバ６０に送信する（ステップＳＴ１０７）。この際、マッチングサーバ４０は、複数のユーザの視聴ログを解析し、同じ又は類似する視聴傾向を有する複数のユーザの広告ＩＤをまとめて（グループ化して）広告配信サーバ６０に送信してもよい。

例えば、マッチングサーバ４０は、よく視聴する番組が同じ／類似する（例えば、番組名、番組のジャンル、番組の出演者などが同じ／類似する）ユーザ、よく視聴する放送局（チャンネル）が同じユーザ、所定の広告（例えば、車の広告など）に触れる機会の多いユーザなどを、グループ化してもよい。

ここで、広告配信サーバ６０に送信される広告ＩＤは、ＷｅｂＩＤとして保存されたものに限られない。例えば広告配信サーバ６０がパブリックＤＭＰを利用し、当該パブリックＤＭＰではデバイス特定情報（例えば、ＩＰアドレス＋クッキーＩＤ＋ウェブアクセスログ）が保持される場合を考える。この場合、マッチングサーバ４０は、広告配信サーバ６０から、ＩＰアドレスとパブリックＤＭＰの広告ＩＤ（例えば、クッキーＩＤ）との対応関係に関する情報を取得してもよい。

マッチングサーバ４０は、自身が保持するＴＶＩＤなどのテーブルに基づいて、所定のＩＰアドレスに対応するユーザへの広告配信を決定すると、上述の対応関係に基づいて当該ユーザに関連するパブリックＤＭＰの広告ＩＤを特定し、広告配信サーバ６０に対して、特定したパブリックＤＭＰの広告ＩＤを送信することができる。このようにすることで、マッチングサーバ４０の運用者は、パブリックＤＭＰを用いる場合であっても、重要な情報である視聴ログ（視聴履歴）をＤＭＰ事業者に公開することなく、視聴ログをセグメントデータ（オーディエンスデータと呼ばれてもよい）と関連付けることができる。

広告配信サーバ６０は、ステップＳＴ１０７で通知された広告ＩＤに基づいて、配信対象の広告を決定する（ステップＳＴ１０８）。例えば、広告配信サーバ６０は、通知された広告ＩＤを、ＤＳＰの広告ＩＤ（例えば、クッキーＩＤ）に変換してもよい。この際、ＤＳＰの広告ＩＤは、必要に応じてパブリックＤＭＰ内にあるウェブアクセスログを基に拡張／変形されてもよい。広告配信サーバ６０は、所定のユーザのデバイス２０に広告を配信する際に、当該ユーザが興味／関心を持つ可能性の高い広告を配信する（ステップＳＴ１０９）。

広告配信サーバ６０は、所定のアドサーバとの連携を行う場合、ＤＳＰを用いる場合と同様に、通知された広告ＩＤを、当該アドサーバで利用される広告ＩＤに変換してもよい。例えば、広告配信サーバ６０のパブリックＤＭＰは、通知された広告ＩＤに対して所定のセグメントＩＤを関連付けて生成してもよい。アドサーバでは、セグメントＩＤに応じて広告の配信設定が行われるものとする。ここで、アドサーバにおけるセグメントＩＤと広告との関連付けは、マッチングサーバ４０に保持される視聴ログの解析結果（視聴傾向など）に基づいて設定されてもよい。

そして、セグメントＩＤがＤＭＰ上で配信対象として設定されると、上述の広告ＩＤに関連するユーザのデバイス２０が広告を含むＷｅｂベージにアクセスする際、ＤＭＰから当該デバイス２０にセグメントＩＤが送信され、保存される。また、デバイス２０がセグメントＩＤを保持する場合には、ＤＭＰはアドサーバに対して当該セグメントＩＤの情報を通知することで、アドサーバは当該デバイス２０に対して広告を送信することができる。

広告配信サーバ６０は、マッチングサーバ４０と、より密に連携してもよい。例えば、マッチングサーバ４０は、例えば、所定のユーザのテレビ１０の視聴ログに基づいて、ＤＭＰのセグメントデータを制御（例えば、作成、拡張、絞込など）してもよい。

なお、ＤＭＰのセグメントデータは、ユーザがよく視聴する番組に関する情報（例えば、番組名、番組のジャンル、番組の出演者など）、よく視聴する放送局（チャンネル）などのユーザの関心事項に関わるデータを含むように制御されてもよい。また、ＤＭＰのセグメントデータは、マッチングサーバ４０及び／又はパブリックＤＭＰの過去の広告出稿情報に基づいて、広告に反応（例えば、広告のクリック、登録など）しやすいユーザを含むように制御されてもよい。

マッチングサーバ４０は、ＤＭＰを含んで構成されてもよいし、パブリックＤＭＰの機能を実現するように構成されてもよい。この場合、上記説明におけるパブリックＤＭＰは、マッチングサーバ４０に読み替えることができる。

以上説明した第１の実施形態によれば、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを、同一のユーザに関する情報と判断（特定）して、テレビ視聴ログを考慮した広告配信を実施することができる。

＜第１の実施形態の変形例＞
ＩＰアドレスが変わらない場合、上述の方法により、ユーザについて視聴ログを長期間蓄積することができ、ユーザに適した広告の配信を好適に行うことができる。

しかしながら、ＩＰアドレスは、セキュリティ上の理由などにより、割り当てから所定の時間が経過すると、再度割り当てが行われることがある。このため、ユーザについて視聴ログを蓄積する前にＩＰアドレスが変更されると、ユーザに関する視聴ログが少量しか確保できず、適切にユーザの嗜好を反映した広告の配信が行えないおそれがある。

そこで、テレビ１０は、視聴ログに加えて、テレビの識別子に関する情報を視聴ログ管理サーバ５０に送信してもよい。当該識別子は、例えば、機器ＩＤと呼ばれてもよく、シリアル番号（製造番号）、製品型番又はこれらの組み合わせなどであってもよいし、動的に生成される値であってもよい。また、機器ＩＤはこれらの値に基づいて算出した値（例えば、シリアル番号をハッシュ化した値）であってもよい。

また、テレビの識別子に関する情報は、放送を再生するために必要なデバイス（例えば、カード）に関する情報であってもよい。当該情報は、Ｂ−ＣＡＳ（BS Conditional Access Systems）（登録商標）カードに関する情報であってもよく、例えば２０桁のＢ−ＣＡＳカード番号（Ｂ−ＣＡＳ ＩＤ）であってもよいし、Ｂ−ＣＡＳ ＩＤに基づいて算出した値（例えば、Ｂ−ＣＡＳ ＩＤをハッシュ化した値）であってもよい。

このように、テレビの識別子に関する情報は、時間に伴って変動することのない固定的なデータであるため、当該情報を利用することで、ユーザごとの一貫した関連付けを実現することができる。

第１の実施形態の変形例では、テレビ特定情報は、テレビ１０のＩＰアドレスと、テレビ１０の視聴ログに関する情報と、テレビ１０の識別子に関する情報と、を少なくとも含む。視聴ログ管理サーバ５０は、テレビ１０のＩＰアドレスと、テレビ１０の視聴ログに関する情報と、テレビ１０の識別子に関する情報と、を取得し、これらの組をテレビ特定情報として蓄積してもよい。なお、上述したように、テレビ特定情報（ＴＶＩＤ）にはタイムスタンプが含まれてもよい。

マッチングサーバ４０は、テレビ１０及び／又は視聴ログ管理サーバ５０から、テレビ特定情報を受信する。マッチングサーバ４０は、テレビ１０のＩＰアドレスとデバイス２０のＩＰアドレスが同一か否かを判断し、同一の場合には、当該ＩＰアドレスと、対応する視聴ログと、対応する広告ＩＤと、テレビ１０の識別子に関する情報との組み合わせ（ユーザ情報）を保存する。

なお、マッチングサーバ４０は、テレビ１０の識別子に関する情報が既に保存されている場合には、受信したテレビ特定情報に含まれるＩＰアドレスが既に保存されているものと異なっていても、テレビ１０の識別子に関する情報に基づいて、視聴ログを適切なユーザ情報として保存することができる。つまり、ルータ３０のＩＰアドレスが変化しても、同じテレビ１０の識別子に関する情報に紐付けて、ルータ３０のＩＰアドレスの変化前後で継続して視聴ログを蓄積することができる。

言い換えると、マッチングサーバ４０は、複数のテレビ特定情報に関して、テレビの識別子に関する情報が同一か否かを判断（マッチング）し、同一の場合には、これらのテレビ特定情報に含まれる複数の視聴ログが、同一のユーザに関する情報であると判断（特定）してもよい。

なお、上述したように、ＩＰアドレスは一定期間ごとに変化する可能性があるため、第１の実施形態及び第１の実施形態の変形例で述べたマッチング処理は、各特定情報の取得後一定期間内に行われることが好ましい。

また、本発明者らは、１つのＩＰアドレスが、複数の広告ＩＤに紐付けられる場合があることに着目し、マッチングサーバ４０における同一のユーザの判断を下記手順によって実施することをさらに着想した。ここで、テレビ１０とデバイス２０との関連付け（マッチング）は、できるだけ同時のタイミングで取得されたＴＶＩＤ及びＷｅｂＩＤに基づいて行われるものとし、最大でも所定のフレッシュな期間（約１−２週間）以内の時間差で取得された両ＩＤに基づいて行われるものとする。

ここでは、あるテレビ１０の識別子に関する情報（例えば、機器ＩＤ）と、あるデバイス２０の広告ＩＤ（例えば、クッキーＩＤ）とが、同一世帯のものであるかを、第１の基準及び第２の基準の少なくとも１つに基づいて判断する。

第１の基準は、連続性に着目した確率（Ａタイプ一致確率と呼ばれてもよい）である。本発明者らは、動的ＩＰアドレスであっても、連続した１つのインターネットセッション中であれば、プロバイダに依らず同一のＩＰアドレスが付番され続ける点に着目し、第１の基準を採用することを見出した。

第１の基準は、タイムスタンプを含むＴＶＩＤのテーブルと、タイムスタンプを含むＷｅｂＩＤのテーブルと、をそれぞれタイムスタンプ及びＩＰアドレスのセットで降順にソートした際に、連続して紐づいているレコード数が多いほど、高くなる確率である。マッチングサーバ４０は、第１の基準が所定の閾値以上である場合に、テレビ１０の識別子に関する情報及びデバイス２０の広告ＩＤが同一世帯のものであると判断することができる。

第２の基準は、可変性に着目した確率である（Ｂタイプ一致確率と呼ばれてもよい）。本発明者らは、時系列でＡ、Ｂ、Ｃ及びＤの順で広告キャンペーンがあると想定した場合に、それぞれの時期でフレッシュなＩＰアドレスで紐づけた際に、いずれのタイミングでも同じ機器ＩＤ及びクッキーＩＤが別々のＩＰアドレスで紐づけられると、両ＩＤが同一世帯にある可能性が高い点に着目し、第２の基準を採用することを見出した。

第２の基準は、所定の期間ごとに実施されたマッチングの結果において、同じテレビ１０の識別子に関する情報及び広告ＩＤが、異なるＩＰアドレスで紐付けられたレコード数が多いほど、高くなる確率である。マッチングサーバ４０は、第２の基準が所定の閾値以上である場合に、テレビ１０の識別子に関する情報及びデバイス２０の広告ＩＤが同一世帯のものであると判断することができる。なお、所定の期間は、周期的なものであってもよいし、周期的でなくてもよい。

なお、第１の基準及び第２の基準の両方に基づいて算出した第３の基準に基づいて、上述の同一世帯判定を行ってもよい。例えば、マッチングサーバ４０は、蓄積する各機器ＩＤについて第１の基準及び第２の基準を算出する。そして、マッチングサーバ４０は、蓄積する機器ＩＤ全体のうち、所定の機器ＩＤに関する第１の基準の偏差値及び第２の基準の偏差値を算出し、これらの偏差値の平均を所定の機器ＩＤに関する第３の基準としてもよい。

マッチングサーバ４０は、第３の基準が所定の閾値以上である場合に、対応するテレビ１０の識別子に関する情報及びデバイス２０の広告ＩＤが同一世帯のものであると判断することができる。

また、別の方針で同一世帯であるか否かを判断してもよい。例えば、マッチングサーバ４０は、所定の期間（例えば、２週間）以内に、異なるＩＰアドレスでテレビ１０とデバイス２０が関連付けられた場合、これらを同一世帯のものである（関係性が正である）を判断し、保持してもよい。

一方で、保持された前回の判断（関係性）とは違う関係性が紐づいてしまったとき（例えば、所定のテレビ１０の機器ＩＤに、前回の広告ＩＤとは異なる広告ＩＤが関連付けられたとき）は、今回の関連性を正と判断してもよいし、前回の関係性を正（関係性をそのまま維持）としてもよい。クッキーＩＤが必ずしも固定的ではないことを考慮すると、前者が好ましいが、現在から直近の所定の期間（例えば、過去１ヶ月）にＩＰアドレス及びクッキーＩＤとの紐付けが行われなかった場合であっても、前回の関係性を正（つまり、最新の関係性を用いる）としてもよい。このようにすると、視聴ログを考慮した広告配信対象を多くすることができる。

なお、上述した同一世帯の判断には、例えば所定のサービスに利用する識別子（ログインＩＤなど）を用いてもよい。例えば、ＴＶＩＤ及びＷｅｂＩＤにログインＩＤが含まれる構成である場合には、同一のログインＩＤを含むＴＶＩＤ及びＷｅｂＩＤに基づいて同一世帯のユーザが特定されてもよい。

＜第１の実施形態の変形例２＞
視聴ログ管理サーバ５０がテレビ１０のメーカーによって保有されるものである場合、蓄積される視聴ログは、テレビ１０が受信可能な全てのテレビ局のデータを含むことが想定される。一方、視聴ログ管理サーバ５０が特定のテレビ局によって保有されるものである場合、蓄積される視聴ログは、当該特定のテレビ局に関するデータしか含まれないと考えられる。

広告主及び／又は広告配信者には、特定のユーザに関するテレビ１０の視聴ログをまとめて管理したいという要求がある。このため、各テレビ局が有する個別の視聴ログ管理サーバ５０に蓄積される視聴ログは、同じユーザに関するものはまとめて扱えるように統合されることが望ましい。そこで、マッチングサーバ４０は、個別の視聴ログ管理サーバ５０にアクセスできる場合、複数のテレビ局の視聴ログに関して、例えば上述のテレビ１０の識別子に関する情報（Ｂ−ＣＡＳ ＩＤなど）が同じ視聴ログをまとめることができる構成としてもよい。

ここで、視聴ログ管理サーバ５０の視聴ログが、他の視聴ログ管理サーバ５０と同じ関連付けで蓄積されるとは限らない。例えば、ある視聴ログ管理サーバ５０では、テレビ特定情報（第１のテレビ特定情報）として、テレビ１０のＩＰアドレス、視聴ログ及び機器ＩＤが関連付けられるのに対し、別の視聴ログ管理サーバ５０では、テレビ特定情報（第２のテレビ特定情報）として、テレビ１０のＩＰアドレス、視聴ログ及びＢ−ＣＡＳ ＩＤが関連付けられる可能性がある。

この場合には、マッチングサーバ４０は、複数のテレビ局に関するテレビ特定情報（第１のテレビ特定情報及び第２のテレビ特定情報）について、テレビ１０のＩＰアドレスに基づいて、視聴ログ、機器ＩＤ及びＢ−ＣＡＳ ＩＤをまとめることができる。

つまり、マッチングサーバ４０は、複数のテレビ特定情報に含まれるテレビの識別子に関する情報が異なる場合（例えば、一方は機器ＩＤ、他方はＢ−ＣＡＳ ＩＤ）であっても、複数のテレビ特定情報に含まれるＩＰアドレスが同じ場合には、同一のＩＰアドレスに対応する複数の視聴ログ（並びに機器ＩＤ及びＢ−ＣＡＳ ＩＤ）を、同一のユーザに関する情報であると判断（特定）することができる。

なお、第１の実施形態の変形例２においては、マッチングサーバ４０は、デバイス２０のＩＰアドレス及び／又は広告ＩＤに関する情報を受信しなくてもよい。

＜第２の実施形態＞
マンションなどの集合住宅や、組織体（例えば、会社、社団法人など）が保有する建物では、複数世帯に渡る多数の人又は当該組織体に属する多数の人が１つのＩＰアドレスで通信する場合がある。嗜好性の全く異なる視聴ログが同じＩＰアドレスに紐づいてしまうと、適切な広告配信が行われないという課題がある。

当該課題を解決するため、本発明者らは、１つのＩＰアドレスに関連付けられる広告ＩＤの数について検討した。その結果、本発明者らは、１つのＩＰアドレスに関連付けられる広告ＩＤ数の特徴について発見した。図３は、１つのＩＰアドレスに関連付けられる広告ＩＤ数の関係性の一例を示す図である。

図３では、広告キャンペーンＡ及びＢについて、それぞれ横軸にＩＰアドレスに紐づく広告ＩＤ（例えば、クッキーＩＤ）数を示し、縦軸にＩＰアドレスの発生頻度を示している。本例では、どちらのキャンペーンでも、１つのＩＰアドレスあたりの広告ＩＤ数が１から１０程度まではほぼ単調にＩＰアドレスの発生頻度が減少しているが、広告ＩＤ数が１０を超えるくらいからＩＰアドレスの発生頻度の傾向が増加に転じている。この理由について以下で考察する。

本発明者らは、まず戸建て住宅のみが存在するケースを検討した。この場合、紐付く広告ＩＤ数が増加するということは、世帯人数が増えるということを意味する。戸建て住宅だけを考えると、３−４人世帯の世帯数は５人世帯よりも多く、５人世帯の世帯数は８、９、１０人世帯よりも多いというように、世帯当たりの人数が増加すると、世帯数は減少する関係があると推測される。このように考えると、戸建て住宅の場合、ＩＰアドレスに紐づく広告ＩＤ数が増加するに従って、世帯数と同様に、対応するＩＰアドレスの発生頻度も減少するはずである。

ここで、本発明者らは、ＩＰアドレスの発生頻度が逆に増加する広告ＩＤ数（閾値）があるとすれば、当該閾値より大きな広告ＩＤ数のＩＰアドレスには、紐付けられる世帯数自体が増えている、つまり、集合住宅／組織体が含まれると予測した。また、ＩＰアドレスに紐付けられるテレビの台数についても、広告ＩＤ数と同様の傾向があると考えられる。

そこで、本発明者らは、本発明の第２の実施形態として、集合住宅のユーザと想定されるデータを除外することを着想した。より具体的には、マッチングサーバ４０は、１つのＩＰアドレスに関連付けられる広告ＩＤの数が所定の数（第１の閾値）以上となった場合に、当該ＩＰアドレスに対しては、視聴ログに基づく広告配信を行わないように制御してもよい。例えば、マッチングサーバ４０は、当該ＩＰアドレスに関して、視聴ログに基づくＤＭＰのセグメントデータの作成／拡張を行わない（既に行っていた場合、当該セグメントデータをリセット／削除する）としてもよいし、広告配信サーバ６０に対して、当該ＩＰアドレスに関連するパブリックＤＭＰの広告ＩＤを送信しないように制御してもよい。

また、マッチングサーバ４０は、１つのＩＰアドレスに関連付けられるテレビの識別子に関する情報の数が所定の数（第２の閾値）以上となった場合に、当該ＩＰアドレスに対しては、視聴ログに基づく広告配信を行わないように制御してもよい。なお、第１の閾値と第２の閾値とは異なる値としてもよいし、同じ値としてもよい。

マッチングサーバ４０は、保存するユーザ情報（広告ＩＤ、視聴ログなどから構成される情報セット）に、視聴ログに基づく広告配信の可否に関する情報（視聴ログ連動広告配信フラグ）を含めるようにしてもよい。そして、マッチングサーバ４０は、ユーザ情報に含まれる視聴ログ連動広告配信フラグが「否」である場合、セグメントに紐づいた広告ＩＤの情報をＤＭＰ／ＤＳＰに送信しないように制御してもよい。

以上説明した第２の実施形態によれば、同一のＩＰアドレスに対応する広告ＩＤ及びテレビの識別子に関する情報の少なくとも一方の数が所定の数（閾値）以上の場合、当該ＩＰアドレスが集合住宅及び／又は組織体に割り当てられるものである（特性／嗜好性の異なる多数の人が同じルータを介して通信している）可能性が高いとして、処理対象から排除することができる。

＜第３の実施形態＞
上述の各実施形態におけるユーザは、視聴ログ取得に同意していることを前提としている。このため、一般の視聴者とは異なる視聴傾向となる可能性がある（母数が特殊であるため）。したがって、視聴ログを、一般の視聴者の視聴傾向に合わせる補正を行うことが好ましい。

第３の実施形態では、一般の視聴者の視聴傾向の代表として、別途収集された視聴ログデータを教師データとして、補正を行う。当該別途収集された視聴ログデータは、代表視聴ログと呼ばれてもよい。代表視聴ログは、世帯と世帯内個人の関係が把握できており、世の中との代表性を厳密に管理した上で取得される機械式の視聴ログデータであることが好ましい。なお、以下の例で、「代表視聴ログ」ではなく単に「視聴ログ」と記載する場合、本発明の一実施形態により所定の端末（デバイス２０）に配信する広告を決定するために用いられるものを表すものとする。

例えば、代表視聴ログとしては、個人視聴率の個票データを用いることができる。当該データには、個人視聴率に加えて世帯視聴率が含まれてもよい。また、当該データには、世帯主情報が含まれてもよいし、含まれなくてもよい。

補正対象のデータは、世帯主情報有の視聴ログ及び世帯主情報無の視聴ログの少なくとも一方である。補正の検証指標として、各世帯の１日あたりの平均の視聴分数、任意の１週間の視聴日数、総視聴分数、延べ視聴率（ＧＲＰ：Gross Rating Point）の少なくとも１つ又はこれらの任意の組み合わせを用いることができる。例えば、検証指標として、各世帯の１日あたりの平均の視聴分数及び任意の１週間の視聴日数を用いてもよい。

補正は、例えば以下のステップＳＴ２０１−ＳＴ２０３により実施する。ここでは地上波放送を対象に説明するが、他の放送についても同様の処理を行ってもよい。また、当該補正処理は、マッチングサーバ４０で行われてもよいし、視聴ログ管理サーバ５０で行われてもよい。なお、補正は、ステップＳＴ２０１−２０３のうち、全ての処理を実施することで実現されてもよいし、少なくとも１つの処理を実施することで実現されてもよい。

ステップＳＴ２０１では、地上波における上記検証指標が異常に多い世帯を排除する。ステップＳＴ２０２では、代表視聴ログである教師データと対象データとの上記検証指標の分布を合わせる。ここで、対象データは、所定の時間（例えば、３０分）刻みで、地上波とその他局／地上波各局の上記検証指標のシェアが代表視聴ログに類似している順番で採用されるものとしてもよい。なお、ステップＳＴ２０２では、世帯主情報有りの視聴ログについては、世帯主別に補正を行う（分布を合わせる）。

ステップＳＴ２０３では、局×曜日×所定の時間（例えば、１０分）刻みの変数を主成分分析し、次元圧縮を行う。また、代表視聴ログの各データ（例えば、個人視聴率の各個票）に対し、各主成分の距離の類似度をもとに割り当てを行い、上記検証指標の分布が略一致するまで繰り返す。

以上説明した第３の実施形態によれば、ユーザの視聴ログを、一般の視聴者の視聴傾向に合わせることができる。

＜第４の実施形態＞
視聴ログは、通常、世帯あたりの視聴ログ（世帯視聴ログ）である。しかしながら、世帯内の各個人が、それぞれ異なるデバイス２０を保有するのが一般的である。したがって、広告配信をより精緻化するためは、世帯視聴ログを個人視聴ログに分離することが好ましい。

上述したように、視聴ログには世帯主情報が存在する場合がある。第４の実施形態では、この世帯主データを利用し、上述の代表視聴ログを教師データとして、所定の世帯の視聴ログのデータから、当該世帯の世帯人数、構成要因の性別、年齢などを推定する。当該推定処理は、マッチングサーバ４０で行われてもよいし、視聴ログ管理サーバ５０で行われてもよい。

推定の学習に用いる対象データは、世帯主情報、世帯人数、世帯構成などの情報を有する視聴ログと、いずれの情報も有しない視聴ログと、から構成することができる。

推定の学習のため、効率の良いデータセットを作成する。視聴ログを所定の時間（例えば、３０分）刻みに分離し、番組情報などに基づいていくつかの情報を説明変数として保持する。推定の学習は、例えばニューラルネットワーク、機械学習、ディープラーニングなどを利用して行うことができる。

具体的には、推定の学習の前処理として、局×曜日×所定の時間（例えば、３０分）刻みのデータに対して、まず、属性データとラベルデータを付与する。

属性データとしては、該当番組の世帯視聴の有無などの世帯視聴に関するパラメータ、該当番組の放送時間帯などの放送枠属性に関するパラメータ、並びに該当番組の世帯視聴率などの番組の人気に関するパラメータなどの説明変数を作成する。

世帯視聴に関するパラメータとしては、例えば、該当番組の世帯視聴の有無、該当番組の前ｎ週世帯視聴の有無、該当番組の前後ｎ枠世帯視聴の有無、該当時間の前ｎ週裏番組視聴の有無、該当時間の前後ｎ枠裏番組視聴の有無、該当時間の前ｎ週の所定局の番組視聴の有無、該当時間の前後ｎ枠の所定局の番組視聴の有無、曜日時間別総視聴確率、曜日時間局別総視聴確率、ジャンル別総視聴確率、世帯主の属性などを用いてもよい。これらの説明変数は、世帯視聴に関するカテゴリーを構成することができる。

放送枠属性に関するパラメータとしては、例えば、曜日、時間、局、ジャンル、前後ｎ枠ジャンル、レギュラーか否か、特番か否か、超大型特番か否か、該当曜日・時間・局・５２週の世帯視聴率、該当曜日・時間・５２週の世帯視聴率、該当ジャンルの世帯視聴率、該当曜日・時間・局・５２週の個人視聴率、該当曜日・時間・５２週の個人視聴率、該当ジャンルの個人視聴率などを用いてもよい。これらの説明変数は、放送枠属性に関するカテゴリーを構成することができる。

番組の人気に関するパラメータとしては、例えば、該当番組の世帯視聴率、該当番組の前ｎ週世帯視聴率、該当番組の前後ｎ枠世帯視聴率、該当番組の個人視聴率、該当番組の前ｎ週個人視聴率、該当番組の前後ｎ枠個人視聴率、電子番組表詳細の総閲覧数、電子番組表詳細の年齢別閲覧数、番宣出稿量（金額換算）、番組単位の検索ウェブサイトの検索数、番組単位のツイートの話題数、出演者の人気度（検索数）などを用いてもよい。これらの説明変数は、番組の人気に関するカテゴリーを構成することができる。

なお、属性データについては、全てのパラメータを用いてもよいし、用途に合わせて一部を用いてもよい。

ラベルデータとしては、所定のターゲットが実際にその枠を視聴していたか否かに関する情報（例えば、１又は０のフラグデータ）を作成する。なお、ターゲットは、マーケティングの分野で用いられる年齢別区分（Ｍ１−Ｍ３層、Ｆ１−Ｆ３層、Ｃ層、Ｔ層）で特定されてもよい。また、所定の時間のうち一定以上の割合（例えば、３分の２以上）の時間視聴されていた場合、フラグは１とするものとしてもよい。

属性データ及びラベルデータをデータセットとし、例えばディープラーニングにおいて、隠れ層（中間層）の数の構成をＦ値（予測結果の評価尺度の１つ）が高まるようにチューニングし、活性化関数として正規化線形関数を用いて学習器を構成する。学習器の精度は、各ターゲット有無の予測に対してＦ値を求め、訓練データとテストデータの期間に基づいて繰り返し計算を行って高めることができる。なお、訓練データとテストデータの期間が異なる場合、所定の期間ごとに学習器の精度を評価することが好ましい。

また、学習器に、所定の世帯の視聴ログから抽出した属性データ及びラベルデータのデータセットを入力することで、当該世帯を構成する個人を推定することができる。

以上説明した第４の実施形態によれば、学習の結果である推定方法を用いて、所定の世帯の視聴ログのデータから、当該世帯の個人視聴ログを分離することができる。

＜第５の実施形態＞
第１の実施形態の変形例２に関して上述したように、テレビ局が取得及び保有し得る視聴ログは、自社番組の視聴に関するデータのみである。図１のようなシステムにおいて、全ての放送局から視聴ログの提供を受けることができるとは限らないため、マッチングサーバ４０が利用できる視聴ログは、一部の局の情報を含まない可能性がある。この場合、例えば、情報が含まれない局をよく視聴するユーザには、視聴ログを考慮した広告配信を行うことが困難になる。

また、全ての放送局から視聴ログの提供を受けることができる場合であっても、各放送局で視聴ログを記録する時間間隔が異なる可能性がある。この場合、あるタイミングにおいて、視聴ログがない局が存在することが考えられる。

そこで、視聴ログを提供しないテレビ局があるという前提で、他に提供を受けた（歯抜けの）視聴ログから、所定のユーザ（ＩＰアドレス）に紐付く視聴ログ全体を推定できることが好ましい。

第５の実施形態では、上述の代表視聴ログと、別途収集されたウェブアクセスログデータと、を教師データとして、「歯抜け」部分の視聴ログを推定する。当該別途収集されたウェブアクセスログデータは、代表ウェブアクセスログと呼ばれてもよい。代表視聴ログは、上述の代表視聴ログに関連付けられる（紐付けられる）ウェブアクセスログデータであることが好ましい。

例えば、代表ウェブアクセスログとしては、テレビ視聴ログとウェブ閲覧履歴を合わせたデータを用いることができる。なお、推定する内容に応じて、代表ウェブアクセスログの代わりに又は代表ウェブアクセスログに加えて、上述の代表視聴ログを用いてもよい。

上記推定処理は、マッチングサーバ４０で行われてもよいし、視聴ログ管理サーバ５０で行われてもよい。推定の学習に用いる対象データは、例えば、特定放送局のみの視聴ログから構成することができる。推定は、特定局についての所定の時間（例えば、１０分）刻みのＡＮＤ条件と、過去Ｘ（Ｘ＞０）週間の視聴動向（例えば代表視聴ログ及び／又は代表視聴ウェブアクセスログを用いて取得できる）をもとに、裏局の当該所定の時間刻みの視聴確率（＝視聴分数／放送分数）を世帯単位で算出することにより行うことができる。推定結果としては、テレビを消している、他局の番組を視聴している、ウェブを閲覧している、の少なくとも１つの可能性を求めるものとしてもよい。

以上説明した第５の実施形態によれば、学習の結果である推定方法を用いて、歯抜けの視聴ログから、視聴ログ全体を推定することができる。例えば、所定のユーザに関する視聴ログから、当該ユーザに類似した特徴（視聴傾向）を有するユーザを推定し、当該ユーザの視聴傾向を推定することができる。

なお、以上説明した情報処理方法では、マッチングサーバ４０は、ＩＰアドレスに基づいて、テレビ１０の視聴ログと、デバイス２０に関する広告ＩＤと、を関連付けるものとしたが、これに限られない。例えば、マッチングサーバ４０は、ＩＰアドレスの代わりに又はＩＰアドレスに加えて、テレビ１０及びデバイス２０が属するネットワーク（ＬＡＮ）を特定する情報（ネットワーク特定情報、ルータ３０を特定する情報などと呼ばれてもよい）を、関連付けに利用してもよい。ネットワーク特定情報は、例えば、ルータ３０のＭＡＣ（Media Access Control）アドレスであってもよい。

また、視聴ログ及び広告ＩＤが関連付けられる例を示したが、視聴ログには、広告ＩＤの代わりに又は広告ＩＤに加えて、デバイス２０に配信される広告に関する他の情報が関連付けられてもよい。例えば、視聴ログと、デバイス２０に配信された広告の履歴（広告ログ）と、が関連付けられてもよい。

＜第６の実施形態＞
これまで説明したテレビ１０のＩＰアドレス、視聴ログに関する情報、テレビの識別子に関する情報、ＩＤデバイス２０のＩＰアドレス、デバイス２０に対する広告ＩＤに関する情報などは、ユーザの特性、嗜好性などを推定するために用いられてもよい。

例えば、マッチングサーバ４０、視聴ログ管理サーバ５０及び広告配信サーバ６０の少なくとも１つは、これらの情報に基づいて、特定の視聴者層を特定又は推定し、当該特定の視聴者層に対してインターネット広告を配信する制御を行ってもよい。

ここでは、所定のテレビＣＭを見ていない人に対してインターネット広告（デジタル広告、デジタル動画などと呼ばれてもよい）を配信することを目的とする。つまり、上述の特定の視聴者層は、所定のテレビＣＭを見ていない視聴者層であってもよい。

上記目的を達成するには、所定のテレビＣＭを見ていない人が持つデバイス２０のデバイス特定情報（例えば、クッキーＩＤ、モバイル広告ＩＤなど）に対して、インターネット広告を配信する必要がある。テレビＣＭを見ていない人を特定又は推定する手法として、例えば以下の４つの手法が考えられる。

第１の手法では、テレビ視聴ログを用いて実際に所定のテレビＣＭに接触したか否かを判断し、実際に所定のテレビＣＭに接触していない人を特定する。第１の手法は、所定のテレビＣＭを見ていない人を特定してインターネット広告を配信できるため、精度が高く、広告配信の規模を抑制できる。

第２の手法では、テレビ視聴ログを用いて普段のテレビの視聴量を判断し、所定のテレビＣＭを見ていないと想定される視聴者層を推定する。第２の手法は、第１の手法に比べてより多くの人にインターネット広告を配信できる。

第３の手法では、ＤＭＰのデータの中から、例えば多次元ベクトルを用いて、普段のテレビ視聴量が少ない人に類似する人を推定する。第３の手法は、第２の手法よりさらに広告配信の規模を大きくすることができる。

第４の手法では、ＤＭＰのデータの中から、世帯構成、居住エリア、性年代、職業、趣味嗜好などのアフィニティカテゴリーの特徴点を解析し、普段のテレビ視聴量が少ない人の含有率が高くなるアフィニティカテゴリーの広告パッケージを、例えば精度の高い順に作成する。第４の手法は、第３の手法よりさらに広告配信の規模を大きくすることができる。

第１−第４の手法は、単独で用いられてもよいし、組み合わせて用いられてもよい。例えば、目標として設定した配信リーチ（ユニークユーザ（ＵＵ：Unique User）数）に応じた数に達するまで、第１の手法から第４の手法を順番に追加で利用するものとしてもよい。具体的には、広告規模が小さい場合には所定の手法（例えば、第１の手法）のみを用いて、広告規模が大きい場合には所定の手法に加えて別の手法（例えば、第２、第３及び／又は第４の手法）も用いるといった態様が考えられる。なお、所定の手法は第１の手法に限られず、例えば第２の手法であってもよい。

第２の手法において、特定の視聴者層の推定及び広告配信は、例えば以下のステップで行われてもよい。なお、各ステップの動作主体は、マッチングサーバ４０、視聴ログ管理サーバ５０及び広告配信サーバ６０のいずれかを含んでもよいし、これらの組み合わせであってもよい。ここでは、視聴者層を、テレビによく触れることを示す評価尺度（例えば、テレビを視聴する時間、頻度など）で分類するものとするが、分類のための評価尺度はこれに限られない。

まず、テレビ視聴ログを用いて、ユーザを特定する所定の識別子（例えば、テレビ１０に紐づくデバイス特定情報（例えば、クッキーＩＤ、モバイル広告ＩＤなど））ごとに、テレビの視聴時間（例えば、視聴分数）と、視聴頻度と、を算出する（ステップＳＴ３０１）。これらの算出は、例えば特定の日時、曜日及び放送局（チャンネル）の少なくとも１つに該当するテレビ視聴ログを用いて実施されてもよい。

ステップＳＴ３０１で算出されたユーザごとのテレビの視聴時間及び／又は視聴頻度に基づいて、ユーザの一部又は全部を視聴者層に分類する（ステップＳＴ３０２）。ここでは、視聴者層を、評価尺度の高い方から順に、「ＨＨ」、「Ｈ」、「Ｍ」、「Ｌ」、「Ｎ」と呼称する。

例えば、ステップＳＴ３０２において、まず、視聴時間及び視聴頻度の両方が最低値（例えば、０）に該当するユーザを「Ｎ」に分類し、視聴時間及び視聴頻度の両方が所定の閾値以上（例えば、上位１０％）に該当するユーザを「ＨＨ」に分類してもよい。

そして、まだ未分類の残りのユーザのデータから、視聴時間の偏差値及び視聴頻度の偏差値を求め、偏差値が高い方から残りのユーザを３つに分割し、高い方から「Ｈ」、「Ｍ」、「Ｌ」にそれぞれ分類してもよい。

次に、広告配信対象の視聴者層を決定する（ステップＳＴ３０３）。例えば、ここではテレビをあまり見ない人（「テレビライトビューアー」などと呼ばれてもよい）を広告配信対象として決定したものとするが、これに限られない。テレビライトビューアーは、上述の「Ｌ」及び「Ｎ」のいずれかに該当するユーザであると判断されてもよい。

広告配信対象の視聴者層のうち、実際に広告が配信されるユーザは、インターネット広告の配信状況に関する情報、各ユーザの特徴情報（例えば、趣味、性別、年齢を含んでもよく、アフィニティカテゴリー、アフィニティセグメント、インタレストカテゴリーなどと呼ばれてもよい）などに基づいて、さらに限定されてもよい。

例えば、所定の視聴者層に含まれるあるユーザに関して、インターネット広告の表示時間（広告配信サーバ６０（ＤＭＰ）上での利用時間（例えば、分数））、リファラ（広告のリンク元となったページの情報）、接触キーワード（例えば、所定の検索エンジンでの検索キーワード）、別途アンケートベースで取得したユーザの趣味嗜好、性別、年齢などに基づいて、配信されるインターネット広告が決定されてもよい。

所定の視聴者層に含まれるユーザは、他の視聴者層に含まれるユーザ（及び／又は他の視聴者層の代表ユーザ（例えば、ユーザの平均）とのインターネット広告の配信状況に関する情報、各ユーザの特徴情報などの比較に基づいて、配信されるインターネット広告が決定されてもよい。

例えば、所定の視聴者層（例えば、ライトビューアー）が利用すると判断された（例えば、ＴＶＩＤ、ＷｅｂＩＤなどを用いてマッチングされた）デバイス２０には、他の視聴者層（「ＨＨ」、「Ｈ」など）との比較に基づいて、インターネット広告の配信が行われてもよい。

以上説明したように、第２の手法によれば、例えば、所定の時間帯にテレビを見ていないユーザ及び／又は普段テレビを見ていないユーザのデバイス２０に対してインターネット広告を配信できる。

なお、テレビ１０とデバイス２０とのマッチング処理ができないユーザ（非マッチングユーザと呼ばれてもよい）に対して、マッチング処理ができたユーザ（マッチングユーザと呼ばれてもよい）の情報に基づいてインターネット広告が配信されてもよい。

インターネット広告の配信状況に関する情報、各ユーザの特徴情報などは、ユーザ（及び／又は各視聴者層の代表ユーザ）ごとに、（１）多次元ベクトル化されてもよいし、（２）特徴点が抽出されてもよい（例えば、ランダムフォレスト、ディープラーニングなどの機械学習が用いられてもよい）。

上記（１）の場合、所定の視聴者層に含まれるユーザに関する多次元ベクトルは、他の視聴者層に含まれるユーザ（及び／又は代表ユーザ）に関する多次元ベクトルとの間の距離が算出され、当該距離の近い順に所定の視聴者層としての広告配信対象とされてもよい。

例えば、上述のステップＳＴ３０２で分類された所定の視聴者層に含まれるユーザ（デバイス２０）とＷｅｂ上で類似の行動をとるユーザ（デバイス２０）は、当該所定の視聴者層に含まれるとみなされてもよい。複数のユーザが類似の行動をとっているか否かは、例えば、同じ及び／又は類似の広告が配信されたか、同じ及び／又は類似のＷｅｂサイトが訪問されたかなどによって、広告配信サーバ６０（ＤＭＰ）におけるＤＭＰデータを用いて判断されてもよい。これにより、第３の手法が実現されてもよい。

上記（２）の場合、所定の視聴者層に含まれるユーザに関する特徴点に基づいて、所定の視聴者層の含有率が高くなるようなユーザに対してインターネット広告が配信されてもよい。例えば媒体側のターゲティングメニューとして所定の視聴者層の含有率が高くなる組み合わせを、ＵＵ数に応じた数に達するまで作成してもよい。

例えば、上述のステップＳＴ３０２で分類された所定の視聴者層に含まれるユーザ（デバイス２０）が有する可能性が高い特徴情報が判断されてもよい。所定の視聴者層に対してインターネット広告を配信する場合には、当該特徴情報を有するユーザに対しても、テレビ視聴ログの有無によらず、同じインターネット広告が配信されるようにしてもよい。これにより、第４の手法が実現されてもよい。

所定の視聴者層とアフィニティカテゴリーとの関連付けは、以下のように行われてもよい。例えば、まず、各ユーザが回答したアンケート結果などを用いて、各ユーザのアフィニティカテゴリー（例えば、「ゲーム好き」、「スポーツ好き」など）が推定（設定、付与）されてもよい。また、テレビ視聴ログを用いて、各ユーザのテレビ視聴に関するアフィニティカテゴリー（例えば、「テレビライトビューアー（テレビライト層）」、「テレビヘビー層」など）が推定（設定、付与）されてもよい。例えば、全ユーザのうち視聴時間上位５０％にはテレビヘビー層のカテゴリーが付与されてもよく、視聴時間下位５０％にはテレビライト層のカテゴリーが付与されてもよい。

そして、アフィニティカテゴリーごとにテレビライト層の割合を集計し、テレビライト層の含有率が高い／低いアフィニティカテゴリーが判断されてもよい。所定のテレビＣＭを見ていない人に対してインターネット広告を配信したい場合、テレビライト層の含有率が高いアフィニティカテゴリーをＤＭＰの配信セグメントに設定し、当該含有率が低いアフィニティカテゴリーを除外セグメントに設定してもよい。

なお、上述した例では、所定のテレビＣＭを見ていない人に対してインターネット広告を配信することを目的として説明したが、第６の実施形態は別の目的に利用されてもよい。例えば、第６の実施形態は、特定の層に対してインターネット広告を配信するために用いられてもよいし、所定のインターネット広告を見ていない人に対してテレビＣＭを配信するために用いられてもよい。これらの構成を実現するために、上述の例の説明は適宜読み替えられてもよい。

＜その他の態様＞
なお、上述の各実施形態では、マッチングサーバ４０、視聴ログ管理サーバ５０及び広告配信サーバ６０の少なくとも１つにおいて、広告主のコンバージョン（ＣＶ：Conversion）データが用いられてもよい。ここで、ＣＶとは、広告主の設定した目標（例えば、商品の購入）を、ある広告を見たユーザが達成したことをいう。また、ＣＶデータは、広告主のＫＰＩ（Key Performance Indicator）を算出するおおもととなるブランドサイトへの来訪、会員登録、商品購入などといったコンバージョンのことを表してもよい。広告配信サーバ６０などは、コンバージョンが高められるような設定をリアルタイムに制御してもよい。

広告配信サーバ６０は、ＣＶデータに基づいて、ＣＶに貢献しない条件（除外条件と呼ばれてもよい）を判断し、当該条件に該当する場合に広告が配信されないように制御してもよい。ＣＶに貢献しない条件は、例えば、以下の（１）−（７）の少なくとも１つであってもよい：
（１）特定のＣＭ枠及び／又は番組枠の接触をきっかけとしたアクセスであること、
（２）特定のオーディエンスデータ（例えば、所定の企業に属するユーザ、ボット、クローラー）に該当するアクセスであること、
（３）所定のＷｅｂページの広告であること、
（４）所定のリファラ（メディア）からのアクセスであること、
（５）所定の地理的位置（ジオグラフィック）及び／又は人口統計学的な（デモグラフィック）データ（年齢など）に該当するユーザのアクセスであること、
（６）所定のスペック（例えば、解像度が悪い）及び／又は通信環境（例えば、通信速度が遅い）に該当するデバイスからのアクセスであること、
（７）所定の言語を利用するユーザからのアクセスであること。

例えば、広告配信サーバ６０は、テレビＣＭ経由でＣＶに至ったユーザのリファラ、ＩＰアドレスなどを解析し、ＤＭＰ内で連携するセグメントから自動的にＩＤ除外を行うことで、既にＣＶに至ったユーザに対する広告の重複を抑制し、広告パフォーマンスを向上してもよい。これにより、ＣＰＡ（Cost Per Action）を改善できる。

広告配信対象を指定する指定条件を利用する場合、配信される規模がどんどん減ってしまう。このため、配信される広告リスト自体が少ないと接触回数（フリークエンシー）過多を発生させてしまい、サイト来訪はするもののコンバージョンが起きないという問題が生じやすい。一方で、上述したような広告配信対象から除外する除外条件に基づく判断によれば、上記問題を抑制できる。

また、例えば第４の実施形態において、世帯視聴ログに基づいて得られる世帯あたりの所定のＣＭへの接触回数（フリークエンシー）から、個人あたりの当該所定のＣＭへの接触回数が推定されてもよい。

また、広告配信サーバ６０は、テレビ１０及び／又はデバイス２０が利用できない場合であっても、ユーザがテレビ１０の視聴環境にいる（又は在宅中である）ことを推定してもよい。この場合、ユーザへの好適な広告配信を実現することができる。

本発明の一態様によれば、テレビＣＭ経由のみでＣＶに至った（例えば、所定のＷｅｂサイトを来訪した）ケースと、インターネット広告のみでＣＶに至ったケースと、テレビＣＭ及びインターネット広告の両方に接触してＣＶに至ったケースと、テレビＣＭ及びインターネット広告の両方に接触せずにＣＶに至ったケースと、を分析できる。このため、広告主は、テレビ及びインターネットの両方を活かしてＣＶ達成率を向上するための広告予算配分を実現できる。

（機器の構成）
図４は、本発明の一実施形態に係るテレビの機能構成の一例を示す図である。図４に示すように、テレビ１０は、制御部１１と、記憶部１２と、通信部（取得部）１３と、入力部１４と、出力部（表示部）１５と、を有する。なお、図４では、本実施形態における特徴部分の機能ブロックを主に示しており、テレビ１０は、他の処理に必要な他の機能ブロックも有してもよい。また、一部の機能ブロックを含まない構成としてもよい。

制御部１１は、テレビ１０の制御を実施する。例えば、制御部１１は、ユーザの操作に基づいて映像の表示を行ったり、視聴ログの送信を制御したりする。制御部１１は、本発明に係る技術分野での共通認識に基づいて説明されるコントローラ、制御回路又は制御装置により構成することができる。

記憶部１２は、テレビ１０で利用する情報を記憶（保持）する。例えば、記憶部１２は、視聴ログを逐次記憶する。記憶部１２は、例えば、本発明に係る技術分野での共通認識に基づいて説明されるメモリ、ストレージ、記憶装置などにより構成することができる。

通信部（取得部）１３は、マッチングサーバ４０及び／又は視聴ログ管理サーバ５０に対して、視聴ログを送信する。また、通信部１３は、サーバ２０及び／又はデバイス３０から受信した種々の情報を制御部１１に出力する。

通信部１３は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置により構成することができる。なお、通信部１３は、送信部及び受信部から構成されてもよい。

入力部１４は、ユーザからの操作により入力を受け付ける。また、入力部１４は、所定の機器、記憶媒体などと接続され、データの入力を受け付けてもよい。入力部１４は、入力結果を例えば制御部１１に出力してもよい。

入力部１４は、本発明に係る技術分野での共通認識に基づいて説明されるキーボード、マウス、ボタンなどの入力装置、入出力端子、入出力回路などにより構成することができる。また、入力部１４は、表示部と一体となった構成（例えば、タッチパネル）としてもよい。

出力部（表示部）１５は、所定のコンテンツの再生を行って、出力する。例えば、出力部１５は、画像を表示する表示部、音声を出力する音声出力部などを含んで構成されてもよい。表示部は、例えば、本発明に係る技術分野での共通認識に基づいて説明されるディスプレイ、モニタなどの表示装置により構成することができる。また、音声出力部は、本発明に係る技術分野での共通認識に基づいて説明されるスピーカーなどの出力装置により構成することができる。

出力部１５は、例えば、本発明に係る技術分野での共通認識に基づいて説明される演算器、演算回路、演算装置、プレイヤー、画像／映像／音声処理回路、画像／映像／音声処理装置、アンプなどを含んで構成することができる。

デバイス２０、ルータ３０、マッチングサーバ４０、視聴ログ管理サーバ５０、広告配信サーバ６０などについても、図４と同様の構成を有してもよい。以下、いくつかの部について詳しく説明する。なお、各装置の図４の各機能ブロックに対応する構成は、各装置を示す符号の下一桁を図４と同様に変更して表すものとする。

デバイス２０の制御部２１は、ユーザの操作に従って、ブラウザなどのアプリケーションを実行するように制御する。通信部２３は、アプリケーションの動作に伴い、広告配信サーバ６０に広告リクエストを送信し、広告又は広告ＩＤ（例えば、キャンペーンＩＤなど）を受信する。

マッチングサーバ４０の通信部（取得部）４３は、ＩＰアドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤを少なくとも含む第２の特定情報と、を取得する。

また、制御部４１は、第１の特定情報及び第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する。

制御部４１は、第１の特定情報がさらにテレビの識別子に関する情報を含む場合、複数の第１の特定情報に基づいて、同一のテレビの識別子に関する情報に対応する複数の視聴ログを特定するように制御してもよい。

制御部４１は、複数の第１の特定情報に含まれるＩＰアドレスが異なる場合であっても、複数の第１の特定情報に含まれるテレビの識別子に関する情報が同一の場合には、同一のテレビの識別子に関する情報に対応する複数の視聴ログを、同一のユーザに関する情報であると判断してもよい。

制御部４１は、複数の第１の特定情報に含まれるテレビの識別子に関する情報が異なる場合であっても、複数の第１の特定情報に含まれるＩＰアドレスが同じ場合には、同一のＩＰアドレスに対応する複数の視聴ログを、同一のユーザに関する情報であると判断してもよい。なお、複数の第１の特定情報に含まれるテレビの識別子に関する情報のうち、一方は機器ＩＤであり、他方はＢ−ＣＡＳ ＩＤであってもよい。

制御部４１は、同一のＩＰアドレスに対応する広告ＩＤの数が所定の閾値以上である場合、当該ＩＰアドレスに対しては、視聴ログに基づく広告配信を行わないように制御してもよい。

（ハードウェア構成）
なお、上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線又は無線で接続し、これら複数の装置により実現されてもよい。

例えば、本発明の一実施形態における無線基地局、ユーザ端末などは、本発明の無線通信方法の処理を行うコンピュータとして機能してもよい。図５は、本発明の一実施形態に係るテレビ、デバイス、ルータ及びサーバのハードウェア構成の一例を示す図である。上述のテレビ１０、デバイス２０、マッチングサーバ４０などは、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。テレビ１０、デバイス２０、マッチングサーバ４０などのハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

例えば、プロセッサ１００１は１つだけ図示されているが、複数のプロセッサがあってもよい。また、処理は、１のプロセッサで実行されてもよいし、処理が同時に、逐次に、又はその他の手法で、１以上のプロセッサで実行されてもよい。

テレビ１０、デバイス２０、マッチングサーバ４０などにおける各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みなどを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。なお、上述の制御部１１などの各部は、プロセッサ１００１で実現されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール、データなどを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、制御部１１は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ROM）、ＥＥＰＲＯＭ（Electrically EPROM）、ＲＡＭ（Random Access Memory）、その他の適切な記憶媒体の少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施形態に係る無線通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、フレキシブルディスク、フロッピー（登録商標）ディスク、光磁気ディスク（例えば、コンパクトディスク（ＣＤ−ＲＯＭ（Compact Disc ROM）など）、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、リムーバブルディスク、ハードディスクドライブ、スマートカード、フラッシュメモリデバイス（例えば、カード、スティック、キードライブ）、磁気ストライプ、データベース、サーバ、その他の適切な記憶媒体の少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。なお、上述の記憶部１２は、メモリ１００２及び／又はストレージ１００３で実現されてもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。なお、上述の通信部１３は、通信装置１００４で実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウスなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカーなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。なお、上述の入力部１４及び出力部１５は、それぞれ入力装置１００５及び出力装置１００６で実現されてもよい。

また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

また、テレビ１０、デバイス２０、マッチングサーバ４０などは、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

（変形例）
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。

本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。また、本明細書においてパラメータなどに使用する名称は、いかなる点においても限定的なものではない。

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

情報、信号などは、複数のネットワークノードを介して入出力されてもよい。入出力された情報、信号などは、特定の場所（例えば、メモリ）に保存されてもよいし、テーブルで管理してもよい。入出力される情報、信号などは、上書き、更新又は追記をされ得る。出力された情報、信号などは、削除されてもよい。入力された情報、信号などは、他の装置へ送信されてもよい。

また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗示的に（例えば、当該所定の情報の通知を行わないことによって）行われてもよい。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）など）及び／又は無線技術（赤外線、マイクロ波など）を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。

本明細書で使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

本明細書で使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素の参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

本出願は、２０１６年４月２０日出願の特願２０１６−０８４６０２に基づく。この内容は、全てここに含めておく。

Claims (9)

1. ＩＰ（Internet Protocol）アドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤ（Identifier）を少なくとも含む第２の特定情報と、を取得する取得部と、
   前記第１の特定情報及び前記第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する制御部と、を有することを特徴とする情報処理装置。
2. 前記第１の特定情報は、さらにテレビの識別子に関する情報を含み、
   前記制御部は、複数の前記第１の特定情報に基づいて、同一のテレビの識別子に関する情報に対応する複数の視聴ログを特定するように制御することを特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、複数の前記第１の特定情報に含まれるＩＰアドレスが異なる場合であっても、複数の前記第１の特定情報に含まれるテレビの識別子に関する情報が同一の場合には、同一のテレビの識別子に関する情報に対応する複数の視聴ログを、同一のユーザに関する情報であると判断することを特徴とする請求項２に記載の情報処理装置。
4. 前記制御部は、複数の前記第１の特定情報に含まれるテレビの識別子に関する情報が異なる場合であっても、複数の前記第１の特定情報に含まれるＩＰアドレスが同じ場合には、同一のＩＰアドレスに対応する複数の視聴ログを、同一のユーザに関する情報であると判断することを特徴とする請求項２又は請求項３に記載の情報処理装置。
5. 複数の前記第１の特定情報に含まれるテレビの識別子に関する情報のうち、一方は機器ＩＤであり、他方はＢ−ＣＡＳ（BS Conditional Access Systems）（登録商標） ＩＤであることを特徴とする請求項４に記載の情報処理装置。
6. 前記制御部は、同一のＩＰアドレスに対応する広告ＩＤの数が所定の閾値以上である場合、当該ＩＰアドレスに対しては、視聴ログに基づく広告配信を行わないように制御することを特徴とする請求項２に記載の情報処理装置。
7. ＩＰ（Internet Protocol）アドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤ（Identifier）を少なくとも含む第２の特定情報と、を取得する工程と、
   前記第１の特定情報及び前記第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する工程と、を有することを特徴とする情報処理方法。
8. 情報処理装置を含む情報処理システムであって、
   前記情報処理装置は、ＩＰ（Internet Protocol）アドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤ（Identifier）を少なくとも含む第２の特定情報と、を取得する取得部と、
   前記第１の特定情報及び前記第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する制御部と、を有することを特徴とする情報処理システム。
9. コンピュータに、
   ＩＰ（Internet Protocol）アドレス及びテレビの視聴ログに関する情報を少なくとも含む第１の特定情報と、ＩＰアドレス及び広告ＩＤ（Identifier）を少なくとも含む第２の特定情報と、を取得する手順と、
   前記第１の特定情報及び前記第２の特定情報に基づいて、同一のＩＰアドレスに対応する視聴ログ及び広告ＩＤの組み合わせを特定するように制御する手順と、を実行させるためのプログラム。
   

Images