JP6301624B2 - 放送受信装置、情報処理システムおよび情報処理装置 - Google Patents

Description

本発明の実施形態は、放送受信装置および情報処理システムに関する。

近年、スマートフォンやタブレットなどの携帯装置とデジタルテレビをネットワークを通じて接続し、携帯装置からデジタルテレビを操作したり、デジタルテレビ側から情報を受信したりするといった技術が用いられるようになってきている。

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

また、デジタルテレビで特定の番組を視聴したユーザに対して、番組を視聴したことを示す証明書を発行し、証明書に基づいて他の装置と携帯装置との間で様々な処理を行うことが求められている。しかしながら、証明書が改変されていたり、不正に取得されたりした場合には、携帯装置から不正な操作が可能となってしまうことになる。

本発明の実施形態は、上記に鑑みてなされたものであって、携帯装置に対して特定の番組を視聴したことを示す証明書の改変を防止しつつ、証明書を付与することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の実施形態の放送受信装置は、チューナー部と、取得部と、署名実行部と、命令受信部と、ネットワークインタフェース部と、送信部とを備える。チューナー部は、番組を特定する情報と、特定の番組を受信したことを証明する視聴証明書を放送波から受信する。取得部は、前記チューナー部で受信した前記視聴証明書を取得する。署名実行部は、取得した前記視聴証明書に鍵を使って署名を施す。ネットワークインタフェース部は、外部装置とネットワーク経由で接続される。命令受信部は、前記外部装置から前記視聴証明書の取得命令を受信する。送信部は、前記署名が施された前記視聴証明書を、前記取得命令を発行した前記外部装置へと送信する。

第１の実施形態の情報処理システムのブロック図。 第１の実施形態の放送受信装置の内部構成を示すブロック図。 第１の実施形態の携帯装置の内部構成を示すブロック図。 第１の実施形態の情報発行装置の内部構成を示すブロック図。 第１の実施形態の情報処理システムの処理の流れを示すフロー図。 第１の実施形態の画面出力部が出力する画面の一例を示す図。 第１の実施形態の視聴証明書のフォーマットの一例を示す図。 第１の実施形態の視聴証明書のフォーマットの一例を示す図。 第１の実施形態の視聴証明書のフォーマットの一例を示す図。 第１の実施形態の変形例の携帯装置の内部構成を示すブロック図。 第１の実施形態の変形例の情報発行装置の内部構成を示すブロック図。 第１の実施形態の変形例の放送受信装置の内部構成を示すブロック図。 第１の実施形態の変形例の携帯装置の内部構成を示すブロック図。 第１の実施形態の変形例の情報発行装置の内部構成を示すブロック図。 第２の実施形態の情報処理システムのブロック図。 第２の実施形態の放送受信装置管理サーバのブロック図。 第２の実施形態の放送受信装置の内部構成を示すブロック図。 第２の実施形態の情報発行装置の内部構成を示すブロック図。 第２の実施形態の処理の流れを示すフロー図。 第２の実施形態の変形例の放送受信装置管理サーバのブロック図。 第２の実施形態の変形例の情報発行装置の内部構成を示すブロック図。 第２の実施形態の変形例の携帯装置の内部構成を示すブロック図。 第２の実施形態の変形例の処理の流れを示すフロー図。 第３の実施形態の放送受信装置の内部構成を示すブロック図。 第３の実施形態の携帯装置の内部構成を示すブロック図。 第３の実施形態の利用許可証のフォーマットの一例を示す図。 第３の実施形態の処理手順を示すフロー図。 第３の実施形態の変形例の放送受信装置の内部構成を示すブロック図。 第３の実施形態の変形例の携帯装置の内部構成を示すブロック図。 第３の実施形態の変形例の放送受信装置と携帯装置との処理手順を示すフロー図。

(第１の実施形態)
図１は第１の実施形態に係る放送受信装置１００と外部装置である携帯装置２００、情報発行装置３００を備えた情報処理システム１の概略構成を示す図である。図１の情報処理システム１は、放送受信装置１００、携帯装置２００、情報発行装置３００、Ｗｅｂアプリ配布サーバ４００を備えている。放送受信装置１００は、放送波に含まれるＡＶデータや文字情報を映像として出力する。携帯装置２００は、放送受信装置１００から送信される視聴証明書を受信する。Ｗｅｂアプリ配布サーバ４００は、ウェブアプリケーション(以下、Ｗｅｂアプリ)を放送受信装置１００と携帯装置２００に配布する。情報発行装置３００は、携帯装置２００から送信する視聴証明書に対する応答として携帯装置２００に情報を送信する。

視聴証明書とは、放送波から送信される特定の放送番組を放送受信装置１００が受信したことを証明する情報である。視聴証明書にはどの放送受信装置１００でどの放送番組を視聴したかを示す情報が含まれており、改変を防止するために放送受信装置１００ごとに割り当てられた秘密鍵で署名が付与されている。

Ｗｅｂアプリとは、ＨＴＭＬ（HyperText Markup Language）やＪａｖａＳｃｒｉｐｔ（登録商標）などが解釈できるＷｅｂブラウザの実行環境で実行されるアプリケーションのことを指す。なお、ＨＴＭＬのバージョンは４でもよいし５でもよい。Ｗｅｂアプリは一般に、複数のページファイルとメディアファイルを有する。メディアファイルとは、ＪＰＥＧ、ＧＩＦ、およびＭＰＥＧなどの動画像データが納められたファイルや、ＭＰ３などの音声データが納められたファイルを指す。これに対して、ページファイルには、ＨＴＭＬなどで記述する文字や画像等の配置情報、表示文字データなどに加えて、ＪａｖａＳｃｒｉｐｔのような制御プログラム情報が格納される場合がある。また、ＨＴＭＬ５またはＪａｖａＳｃｒｉｐｔからはＨＴＴＰ(ＸＭＬＨＴＴＰＲｅｑｕｅｓｔ)やＷｅｂＳｏｃｋｅｔと呼ばれるプロトコルでＨＴＴＰサーバや、ＷｅｂＳｏｃｋｅｔサーバと通信することができる。

放送受信装置１００は放送波を受信する。図１に示す例では同軸ケーブルにて放送波を受信する例を示しているが、もちろん、同軸ケーブルに限らずインターネットプロトコルで接続された不図示の放送配信サーバから放送波を受信してもよい。

放送受信装置１００と携帯装置２００は、有線または無線のネットワークで接続されており、携帯装置２００は放送受信装置１００に視聴証明書を送信するよう指示する命令を送信する。放送受信装置１００はその応答として視聴証明書を携帯装置２００に送信する。携帯装置２００は受信した視聴証明書を自装置内の記憶領域に保存する。

携帯装置２００は、インターネットを介してＷｅｂアプリ配布サーバ４００と接続されており、Ｗｅｂアプリを受信する。放送受信装置１００もインターネットを介してＷｅｂアプリ配布サーバ４００と接続されており、Ｗｅｂアプリを受信する。

放送受信装置１００から携帯装置２００に視聴証明書を送信するための物理レイヤとリンクレイヤとして、赤外線、ＩＥＥＥ８０２．１１規格に準拠した無線ＬＡＮ、イーサネット（登録商標）などの種々の通信形態が採用可能であるが、図１では一例として無線ＬＡＮを示している。

なお、これらインタフェースが有線であるか無線であるかは問わない。ネットワークレイヤとして、インターネットプロトコル（ＩＰ）を使用する場合は、ＩＰｖ４でもよいし、ＩＰｖ６でもよい。インタフェースがＩＰの場合には、放送受信装置１００と携帯装置２００の間に不図示の無線アクセスポイント機器やルータ機器等が接続されていてもよい。ここでは一例として、放送受信装置１００から携帯装置２００に無線ＬＡＮを介して視聴証明書を送信する例を説明するが、ネットワーク形態は特に問わない。視聴証明書の詳細については後述する。

放送受信装置１００は、携帯装置２００と通信するコネクションとは別に、Ｗｅｂアプリ配布サーバ４００と通信するためのＩＰインタフェースであるＨＴＴＰ処理部１０３（鍵受信部）を備えている。同様に、携帯装置２００も放送受信装置１００と通信するコネクションとは別に、Ｗｅｂアプリ配布サーバ４００と通信するためのＩＰインタフェースを備えている。これらＩＰインタフェースは、後述するＨＴＴＰ処理部２０３に内蔵される。

ＩＰインタフェースの物理レイヤとリンクレイヤとして、ＩＥＥＥ８０２．１１規格に準拠した無線ＬＡＮやイーサネットなど種々の通信形態が採用可能である。ネットワークレイヤとして、インターネットプロトコル（ＩＰ）を使用する場合は、ＩＰｖ４でもよいし、ＩＰｖ６でもよい。

また、放送受信装置１００とＷｅｂアプリ配布サーバ４００は、例えばインターネットを介してインターネットプロトコル（ＩＰ）で接続されている。同様に携帯装置２００とＷｅｂアプリ配布サーバ４００は、例えばインターネットを介してＩＰで接続されている。

放送受信装置１００と携帯装置２００は、Ｗｅｂアプリ配布サーバ４００からＷｅｂアプリをダウンロードして実行する。放送受信装置１００と携帯装置２００は、複数のＷｅｂアプリ配布サーバ４００からそれぞれ異なる複数のＷｅｂアプリをダウンロードしたり、実行したりしてもよい。

携帯装置２００は、ユーザによって携帯可能な装置であり、放送受信装置１００とは別のネットワークに接続されている情報発行装置３００と通信可能な領域に移動させる事ができる。すなわち、携帯装置２００は、例えば家庭内に設定されたＴＶなどの放送受信装置１００との通信を一旦切断したあとに、移動先の場所、例えば店舗などで有線または無線のネットワークで情報発行装置３００と接続する。

携帯装置２００は情報発行装置３００に対して、放送受信装置１００から受信して保存しておいた視聴証明書を送信する。情報発行装置３００は、その応答として携帯装置２００に情報を返す。情報発行装置３００が携帯装置２００へと返信する情報の一例としては、例えば特定の放送番組を視聴した人に対して発行するクーポンなどが考えられる。

携帯装置２００から情報発行装置３００に視聴証明書を送信したり、情報発行装置３００から情報を受信したりするための物理レイヤとリンクレイヤとして、赤外線、ＩＥＥＥ８０２．１１規格に準拠した無線ＬＡＮ、イーサネット（登録商標）などの種々の通信形態が採用可能であるが、図１では一例として無線Ｌａｎを示している。

なお、これらインタフェースが有線であるか無線であるかは問わない。ネットワークレイヤとして、インターネットプロトコル（ＩＰ）を使用する場合は、ＩＰｖ４でもよいし、ＩＰｖ６でもよい。インタフェースがＩＰの場合には、情報発行装置３００と携帯装置２００の間に不図示の無線アクセスポイント機器やルータ機器等が接続されていてもよい。ここでは一例として、携帯装置２００から情報発行装置３００に無線ＬＡＮを介して視聴証明書を送信する例を説明するが、ネットワーク形態は特に問わない。

なお、図１では放送受信装置１００と情報発行装置３００が別々の場所に位置し、それぞれ異なるネットワークに接続されている構成を示しているが、同一のネットワークに接続されていてもよいし、同一の場所に設置されていてもよい。以下の例では、別々の場所に設置され、それぞれ異なるネットワークに接続されている場合について説明する。

図２は第１の実施形態に係る放送受信装置１００の内部構成を示すブロック図である。図２の放送受信装置１００は、入力受信部１０１、チューナー部１０２、画面出力部１１３、ＨＴＴＰ処理部１０３、Ｗｅｂアプリ取得部１０４、Ｗｅｂアプリ実行部１０５、視聴証明書取得部１０６（取得部）、視聴証明書生成部１０７（署名実行部）、鍵管理部１０８、視聴証明書管理部１０９、Ｗｅｂｓｏｃｋｅｔサーバ処理部１１２、機器操作命令処理部１１１、視聴証明書送信部１１０、を備えている。

入力受信部１０１は、赤外線やＢｌｕｅｔｏｏｔｈ（登録商標）などの通信インタフェースを有し、その通信インタフェースを介して入力された選局や音量調整などの命令を受信し、チューナー部１０２を操作する処理部である。

チューナー部１０２は、放送波を受信する処理を行う。放送波は、特定の放送番組や、番組を特定する情報や視聴証明書を含む放送関連情報を有する。画面出力部１１３は、チューナー部１０２から出力された動画データや音声データをデコードし、不図示の内部液晶モニターや外部出力インタフェースに出力する。外部出力インタフェースとは、例えばＨＤＭＩ（High-Definition Multimedia Interface）やコンポジット、Ｓ―Ｖｉｄｅｏ、コンポーネントのようなインタフェースのことを指す。

ＨＴＴＰ処理部１０３は、Ｗｅｂアプリ配布サーバ４００との間で、ＨＴＴＰ(Hypertext Transfer Protocol)もしくはＨＴＴＰＳ(Hypertext Transfer Protocol over Secure Socket Layer)のプロトコルで通信し、後述するＷｅｂアプリに必要なＨＴＴＰクライアント処理及びＴＣＰ／ＩＰ処理、リンクレイヤ処理・物理レイヤ処理を行う。

Ｗｅｂアプリ取得部１０４は、ＨＴＴＰ処理部１０３を使って、所定のＷｅｂサーバ(Ｗｅｂアプリ配布サーバ４００)から後述するＷｅｂアプリを取得する処理を行う。Ｗｅｂアプリ実行部１０５は、Ｗｅｂアプリ取得部１０４で取得したＷｅｂアプリを実行するＷｅｂブラウザ処理を行う。視聴証明書取得部１０６は、Ｗｅｂアプリ実行部１０５の指示に基づき、チューナー部１０２で受信した放送波から未署名の視聴証明書を取得する処理を行う。鍵管理部１０８（固有鍵管理部）は、視聴証明書に署名を施すための鍵を保存して管理する処理部である。

視聴証明書生成部１０７は、鍵管理部１０８に蓄積されている鍵を用い、視聴証明書取得部１０６で取得した未署名の視聴証明書に対して署名処理を施す。なお、この署名処理は公開鍵暗号を使ってもよいし、共通鍵を使ったＭＡＣ(Message Authentication Code: 鍵付きハッシュ関数)でもよい。以下では公開鍵暗号を使った署名として説明する。なお、公開鍵のアルゴリズムとしてはＲＳＡ暗号や楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。

視聴証明書管理部１０９は、視聴証明書生成部１０７にて署名が施された視聴証明書を保存して管理する処理部である。Ｗｅｂｓｏｃｋｅｔサーバ処理部１１２（命令受信部）は、ＲＦＣ６４５５規格で定められたＷｅｂｓｏｃｋｅｔと呼ばれるプロトコルに従って携帯装置２００と通信を行うためのサーバ処理を行う。視聴証明書送信命令など携帯装置２００から送信されるデータを受信し、視聴証明書などを携帯装置２００に送信する処理を行う。なお、Ｗｅｂｓｏｃｋｅｔサーバ処理部１１２のＴＣＰ／ＩＰ処理、リンクレイヤ処理・物理レイヤ処理はＨＴＴＰ処理部１０３と共用してもよいし、ＨＴＴＰ処理部１０３とは独立にＷｅｂｓｏｃｋｅｔサーバ処理部１１２が備えていてもよい。

機器操作命令処理部１１１は、携帯装置２００からＷｅｂｓｏｃｋｅｔで送信された機器操作命令を受け付けて、その命令に従った処理を行う。たとえば、機器操作命令とは視聴証明書を送信するよう要求する命令や、チューナー部１０２に対する選局命令、音量調整命令などがある。

視聴証明書送信部１１０は、携帯装置２００からの命令が視聴証明書を送信するよう指示する命令だった場合に、視聴証明書管理部１０９に蓄積されている視聴証明書を取得して送信する処理を行う処理部である。

図３は第１の実施形態に係る携帯装置２００の内部構成を示すブロック図である。図３の携帯装置２００は、ＨＴＴＰ処理部２０３、アプリ取得部２０４、アプリ実行部２０１、入力受信部２０２、画面出力部２１３、Ｗｅｂｓｏｃｋｅｔクライアント処理部２０５、機器操作命令送信部２０６、視聴証明書受信部２０７、視聴証明書蓄積部２０８、視聴証明書送信部２１０、クーポン受信部２１１、クーポン蓄積部２０９、を備えている。

ＨＴＴＰ処理部２０３は、Ｗｅｂサーバ(ＨＴＴＰサーバ)との間で、ＨＴＴＰ(Hypertext Transfer Protocol)もしくはＨＴＴＰＳ(Hypertext Transfer Protocol over Secure Socket Layer)のプロトコルで通信し、後述するＷｅｂアプリの要求、取得に必要なＨＴＴＰクライアント処理及びＴＣＰ／ＩＰ処理、リンクレイヤ処理・物理レイヤ処理を行う。

ＨＴＴＰ処理部２０３は、後述するアプリ取得部２０４からの要求に応じて、所定のＷｅｂサーバ(Ｗｅｂアプリ配布サーバ４００)に後述するＷｅｂアプリの取得要求を送信し、取得したＷｅｂアプリを受信する。ＨＴＴＰ処理部２０３は、受信したＷｅｂアプリをアプリ取得部２０４に送信する。

アプリ取得部２０４は、ＨＴＴＰ処理部２０３を使って、所定のＷｅｂサーバ(Ｗｅｂアプリ配布サーバ４００)から後述するＰＦアプリとＷｅｂアプリを取得し、アプリ実行部２０１に送信する処理を行う。

アプリ実行部２０１は、アプリ取得部２０４で取得したＷｅｂアプリを実行するＷｅｂブラウザ処理を行う。入力受信部２０２は、タッチパッドやキーボード、マウスなどの入力機器を介してユーザが入力した情報を受信し、入力した情報をアプリ実行部２０１に通知する。

Ｗｅｂｓｏｃｋｅｔクライアント処理部２０５は、ＲＦＣ６４５５規格で定められたウェブソケット（Ｗｅｂｓｏｃｋｅｔ）と呼ばれるプロトコルに従って放送受信装置１００と通信を行うためのクライアント処理を行う。Ｗｅｂｓｏｃｋｅｔサーバ部に送信する機器操作命令などのデータは、このＷｅｂｓｏｃｋｅｔクライアント処理部２０５で処理され、ＲＦＣ６４５５規格で定められたフォーマットに従って、ヘッダなどを付与して放送受信装置１００に送信される。なお、Ｗｅｂｓｏｃｋｅｔクライアント処理部２０５のＴＣＰ／ＩＰ処理、リンクレイヤ処理・物理レイヤ処理はＨＴＴＰ処理部２０３と共用してもよいし、ＨＴＴＰ処理部２０３とは独立にＷｅｂｓｏｃｋｅｔクライアント処理部２０５が備えていてもよい。

画面出力部２１３は、アプリ実行部２０１で生成した画面を自装置内の不図示のモニターに表示もしくは外部出力インタフェースに出力する。外部出力インタフェースとは、例えばＨＤＭＩ（High-Definition Multimedia Interface）やコンポジット、Ｓ―Ｖｉｄｅｏ、コンポーネントのようなインタフェースのことを指す。

機器操作命令送信部２０６は、アプリ実行部２０１からの指示に基づいて機器操作命令を放送受信装置１００に送信するようＷｅｂｓｏｃｋｅｔクライアント処理部２０５に依頼する処理部である。視聴証明書受信部２０７は、機器操作命令として視聴証明書を送信するよう依頼する命令の応答として放送受信装置１００から送信されてきた視聴証明書を受信し、視聴証明書蓄積部２０８に蓄積するよう依頼する処理部である。

視聴証明書蓄積部２０８は、視聴証明書を蓄積して管理する処理部である。視聴証明書送信部２１０は、アプリ実行部２０１からの指示に基づいて視聴証明書を情報発行装置３００に送信する処理を行う処理部である。

クーポン受信部２１１は、情報発行装置３００から送信されてきたクーポンを受信し、クーポン蓄積部２０９に蓄積するよう依頼する処理を行う処理部である。クーポン蓄積部２０９は、クーポンを蓄積して管理する処理部である。

図４は第１の実施形態に係る情報発行装置３００の内部構成を示すブロック図である。図４の情報発行装置３００は、Ｗｅｂｓｏｃｋｅｔサーバ処理部３０４、鍵管理部３０５、視聴証明書検査部３０３、クーポン管理部３０１、クーポン発行部３０２、を備えている。

Ｗｅｂｓｏｃｋｅｔサーバ処理部３０４は、図２で示した放送受信装置１００のＷｅｂｓｏｃｋｅｔサーバ処理部１１２と同様の機能を有し、ＲＦＣ６４５５規格で定められたＷｅｂｓｏｃｋｅｔと呼ばれるプロトコルに従って携帯装置２００と通信を行うためのサーバ処理を行う。視聴証明書など携帯装置２００から送信されるデータを受信し、クーポン情報などを携帯装置２００に送信する処理を行う。

鍵管理部３０５は、視聴証明書に付与された証明書の検査を行うための公開鍵を蓄積し、管理する処理を行う。視聴証明書検査部３０３は、鍵管理部３０５に蓄積された公開鍵を利用して、Ｗｅｂｓｏｃｋｅｔサーバ処理部３０４で受信した視聴証明書に付与された署名が正しいかどうかを検査する処理を行う。

クーポン管理部３０１は、視聴者が放送番組ないしは放送番組に付随する宣伝情報(コマーシャル)を視聴した特典として商品の割引情報や新商品の案内等の情報を管理する処理部である。なお、放送番組に関連した情報であれば特典情報に限定する必要はないが、ここではクーポンと表記する。

クーポン発行部３０２は、視聴証明書検査部３０３にて受信した視聴証明書が正しいと判定された場合に限り、クーポン管理部３０１から視聴証明書に対応した、すなわち放送番組に対応したクーポンを取得し、Ｗｅｂｓｏｃｋｅｔサーバ処理部３０４を経由して携帯装置２００に送信する。

図５は第１の実施形態における放送受信装置１００、携帯装置２００、情報発行装置３００の処理手順を示すフローチャートである。図５に示すように、処理シーケンスは大きく分けて、放送受信装置１００と携帯装置２００間の通信であるフェーズ１と、携帯装置２００と情報発行装置３００との間の通信であるフェーズ２の２つのフェーズから構成される。フェーズ１では、携帯装置２００が放送受信装置１００から署名済み視聴証明書を取得して保存する。フェーズ２では、携帯装置２００が情報発行装置３００からクーポンを取得して保存する。以下に各フェーズの詳細を述べる。

フェーズ１は、まず放送受信装置１００にて放送番組を視聴する事から始まる（ステップＳ１０１）。これは放送受信装置１００のチューナー部１０２で放送波を受信し、現在選局中の番組を画面出力部１１３に出力する処理である。

図６に放送受信装置１００の画面出力部１１３が出力する画面の一例を示す。通常の放送番組視聴時には放送波から受信し、チューナー部１０２でデコードした放送番組が画面出力部１１３に出力される。なお、放送波には放送番組の他に関連情報としてＵＲＬないしはＷｅｂアプリが含まれている場合がある。チューナー部１０２は放送波にＵＲＬやＷｅｂアプリが含まれている場合には、それらの情報を抽出し、Ｗｅｂアプリ取得部１０４に送信する。Ｗｅｂアプリ取得部１０４は、チューナー部１０２で取得した情報がＵＲＬだった場合には、そのＵＲＬを元にＨＴＴＰ処理部１０３を使ってＷｅｂアプリを取得し、Ｗｅｂアプリ実行部１０５で実行する。

ＷｅｂアプリにはＧＵＩ(画面インタフェース)を備えているものもあり、図６で示した画面はその一例である。Ｗｅｂアプリのリソースファイルには放送番組と関連情報をどのような画面のサイズでどの位置に表示するかといった情報が含まれており、その指示に従って放送番組、テキスト文字や画像などの情報、ボタンが配置される。ここではクーポン取得ボタンと戻るボタンがＷｅｂアプリとして配置されている。クーポン取得ボタンが選択されると、Ｗｅｂアプリ実行部１０５は視聴証明書取得部１０６に対して放送波に含まれる視聴証明書を取得するよう依頼する。なお、クーポン選択ボタンの選択は赤外線リモコンなどを通して入力受信部１０１からアプリ実行部２０１に指示する事により実現すればよい。

ここで、視聴証明書は放送番組に重畳されて放送波として配信される。視聴証明書はチャンネルや番組によって固有の情報を有する。視聴証明書のフォーマットの一例を図７に示す。視聴証明書は放送ネットワークＩＤ、番組ＩＤ、ＤＴＶ ＩＤ、署名、署名方式から構成される。

放送ネットワークＩＤと番組ＩＤは番組を一意に識別するための情報である。放送ネットワークＩＤは、放送地域ごとに放送局に一意に付与されるＩＤである。すなわち、放送ネットワークＩＤによってある特定の地域の放送局が一意に識別できる。番組ＩＤは、その放送局の中で番組に一意につけられたＩＤである。放送ネットワークＩＤと番組ＩＤは別々のフィールドになっている必要はなく、同一のフィールドでもよい。また、番組ＩＤはＩＤの形式になっている必要はなく、その放送番組が放送された日時でもよい。ＤＴＶ ＩＤは放送受信装置１００に一意に付与されたＩＤである。放送受信装置１００には製造時に一意のＩＤが割り当てられている。この値はランダムでもよいし、放送受信装置１００のセットメーカーのＩＤと、そのセットメーカーが割り当てたモデルＩＤ、モデル内で一意に割り当てられた値となっていてもよい。

なお、視聴証明書は放送コンテンツに重畳されて放送波から送信されてくる。放送ネットワークＩＤと番組ＩＤは放送波から受信した時点で適切な値が挿入されているが、ＤＴＶ ＩＤは放送受信装置１００が埋め込むフィールドであるため、放送波から受信した時には何も値が入っていない(オールゼロなど放送受信装置１００のＩＤとして存在しない値)。従って、放送受信装置１００は自身に割り当てられたＩＤをこのフィールドに挿入する。

署名は鍵管理部１０８で管理している鍵を使って視聴証明書生成部１０７にて署名対象フィールドに施した署名である。ＤＴＶ ＩＤと同様、このフィールドも放送波から受信した時には何も値が入っておらず、放送受信装置１００が挿入する。署名方式は署名の方式を示すアルゴリズム名を示す。このフィールドはオプションである。このフィールドも放送波から受信した時には何も値が入っておらず、放送受信装置１００が挿入する。なお、視聴証明書は署名が付与された状態で携帯装置２００に送信されればよいため、視聴証明書は必ずしも放送波に重畳されて放送局から送信されてくる必要はない。たとえばインターネットを経由してＩＰネットワークで不図示の視聴証明書配信サーバから受信してもよい。放送ネットワークＩＤは放送波から送信されてくる。よって、図７に示したフォーマットに従って、放送受信装置１００が、放送波から放送ネットワークＩＤを取得し、番組ＩＤにはその番組が放送された放送時刻を記入し、ＤＴＶ ＩＤには自身に割り当てられたＩＤを挿入してもよい。

なお、図６ではクーポン取得ボタンを明示的に選択する事によって放送受信装置１００が視聴証明書を取得・生成する例について示したが、ＷｅｂアプリがＧＵＩを生成する事なく、自動的に視聴証明書を取得・生成するようにしてもよい。自動的に視聴証明書を取得する場合、放送受信装置１００が番組の切り替わり時、すなわち放送ネットワークＩＤまたは番組ＩＤが切り替わった時に視聴証明書を取得・生成するか、定期的に視聴証明書を取得するようにすればよい。

次いで、図５へと戻り、視聴証明書生成部１０７によって署名付き視聴証明書が生成されると、署名付き視聴証明書は視聴証明書管理部１０９で蓄積される（ステップＳ１０２）。次いで、携帯装置２００は放送受信装置１００に対して視聴証明書を送信するよう指示する命令を送信する（ステップＳ１０３）。この際、携帯装置２００自身のＩＤ（識別情報）を含めてもよい。この命令はＷｅｂｓｏｃｋｅｔクライアント処理部２０５またはＷｅｂｓｏｃｋｅｔサーバ処理部１１２（受信部）を用いて双方の装置でＷｅｂｓｏｃｋｅｔコネクションを確立し、そのコネクション上で伝送される。この視聴証明書の取得要求は放送受信装置１００の視聴証明書管理部１０９が蓄積しているすべての視聴証明書を取得する要求であってもよいし、特定のネットワークＩＤを指定する要求であってもよいし、特定のネットワークＩＤと特定の番組ＩＤを指定する要求であってもよいし、特定の日時または期間を指定する要求であってもよい。その応答として放送受信装置１００は携帯装置２００のＩＤを取得し、該当する視聴証明書を検索する（ステップＳ１０４）。そして、放送受信装置１００は視聴証明書管理部１０９に蓄積している検索された署名済み視聴証明書を携帯装置２００に送信する（ステップＳ１０５）。携帯装置２００は放送受信装置１００から受信した視聴証明書を証明書蓄積部に蓄積する（ステップＳ１０６）。以上がフェーズ１であり、以降がフェーズ２となる。

フェーズ２では、携帯装置２００のＷｅｂｓｏｃｋｅｔクライアント処理部２０５と、情報発行装置３００のＷｅｂｓｏｃｋｅｔサーバ処理部３０４がＷｅｂｓｏｃｋｅｔコネクションを確立する処理から始まる。携帯装置２００はＷｅｂｓｏｃｋｅｔコネクションを確立すると、情報発行装置３００に対して証明書蓄積部に蓄積しておいた視聴証明書を送信する（ステップＳ１０７）。なお、この例では携帯装置２００から情報発行装置３００に視聴証明書を送信する例を示したが、この視聴証明書の送信に先立ち、情報発行装置３００から携帯装置２００に対して、特定の視聴証明書を送信するように要求してもよい。また、情報発行装置３００から携帯装置２００に対して特定のネットワークＩＤを提示したり、特定のネットワークＩＤと特定の番組ＩＤを提示したり、特定の日時または期間を提示し、携帯装置２００は情報発行装置３００に対して、それに該当する視聴証明書を送信するようにしてもよい。

情報発行装置３００は視聴証明書を受信すると、情報発行装置３００は視聴証明書検査部３０３で鍵管理部１０８に格納されている鍵を取得し、視聴証明書に付与された署名が正しいかどうかを検証し（ステップＳ１０８）、検証結果を携帯装置２００に送信する（ステップＳ１０９）。携帯装置２００は検証結果が成功しているならば、クーポンの送信要求を情報発行装置３００に送信する（ステップＳ１１０）。情報発行装置３００は検証結果が成功した場合に限り、携帯装置２００にクーポンを送信する（ステップＳ１１１）。

なお、ここでは視聴証明書の送信とクーポンの送信要求を別々の命令で送信する例を示したが、視聴証明書とクーポンの送信要求を同一の命令で送信し、情報発行装置３００は視聴証明書の検証に成功した場合のみクーポンを送信するようにしてもよい。

また、視聴証明書に携帯装置２００のＩＤが含まれる場合、情報発行装置３００はそのＩＤを元に、クーポンを送信するかどうか判断してもよいし、ＩＤを元に送信するクーポンを変更してもよい。

なお、上記では放送受信装置１００がライブ（生放送）で放送番組を受信しており、その放送番組に該当する視聴証明書を生成する事を想定していたが、録画番組に対してその放送番組に該当する視聴証明書を生成してもよい。放送受信装置１００はＨＤＤ(ハードディスクドライブ)などから構成された不図示の二次記憶装置を用いて放送コンテンツを録画する機能を有していてもよい。録画番組を再生する際に、ライブで受信したのと同一の視聴証明書を生成するようにしてもよいし、録画コンテンツに対して生成した視聴証明書か、ライブ放送コンテンツに対して生成した視聴証明書かを区別できるようになっていてもよい。

図８は、ライブと録画を区別する場合の、視聴証明書のフォーマットの一例を示す。図８に示すように、署名対象フィールドにその視聴証明書がライブ放送コンテンツの視聴により生成されたのか、放送の録画コンテンツの視聴により生成されたのか区別するフィールドが存在する。また、視聴証明書に携帯装置２００のＩＤを含めてもよい。その場合の視聴証明書のフォーマットの一例を図９に示す。

図１０は、携帯装置２００の変形例である。図３に示した携帯装置２００との違いは、近接無線送信部２１４を新たに備えている点である。図３の携帯装置２００では視聴証明書の送信とクーポンの受信をＷｅｂｓｏｃｋｅｔクライアント処理部２０５によってＷｅｂｓｏｃｋｅｔコネクションを使っていた。図６に示す携帯装置２００ａでは、近接無線によって視聴証明書を送信したり、クーポンを受信したりする。なお、近接無線の物理レイヤとしてＮＦＣやＴｒａｎｓｆｅｒｊｅｔなどで規格化されている伝達距離の短い無線を用いればよい。

図１１は情報発行装置３００の別例である。図４に示した情報発行装置３００との違いは、Ｗｅｂｓｏｃｋｅｔサーバ処理部３０４の代わりに近接無線受信部３０６を備えている点である。図４の情報発行装置３００では視聴証明書の受信とクーポンの送信をＷｅｂｓｏｃｋｅｔサーバ処理部３０４によってＷｅｂｓｏｃｋｅｔコネクションを使っていた。図１１に示す情報発行装置３００ａでは、近接無線によって視聴証明書を受信したり、クーポンを送信したりする。

図１２は放送受信装置１００の別例である。図２との違いはＷｅｂｓｏｃｋｅｔサーバ処理部１１２の代わりにＨＴＴＰサーバ処理部１１２−２を備えている点である。ＨＴＴＰサーバ処理部１１２−２はＨＴＴＰもしくはＨＴＴＰＳのプロトコルで通信する際のサーバ処理を行う。すなわち、この変形例の場合、ＨＴＴＰサーバ処理部１１２−２が受信部に相当する。なお、ＨＴＴＰサーバ処理部１１２−２のＴＣＰ／ＩＰ処理、リンクレイヤ処理・物理レイヤ処理はＨＴＴＰ処理部１０３と共用してもよいし、ＨＴＴＰ処理部１０３とは独立にＨＴＴＰサーバ処理部１１２−２が備えていてもよい。

図１３は携帯装置２００の別例である。図３との違いはＷｅｂｓｏｃｋｅｔクライアント処理部２０５の代わりにＨＴＴＰ処理部２１５を備えている点である。ＨＴＴＰ処理部２１５は図２に示した放送受信装置１００のＨＴＴＰ処理部１０３と同等の構成でよい。図１４は情報発行装置３００の別例である。図４との違いはＷｅｂｓｏｃｋｅｔサーバ処理部３０４の代わりにＨＴＴＰサーバ処理部３０７を備えている点である。

図２〜図４に示した構成では、放送受信装置１００と携帯装置２００との通信、及び携帯装置２００と情報発行装置３００との通信にＷｅｂｓｏｃｋｅｔのプロトコルを利用していた。図１３〜図１４に示す構成では、Ｗｅｂｓｏｃｋｅｔのプロトコルの代わりにＨＴＴＰのプロトコルで通信する。それ以外は図２〜図４に示した構成と同一である。以上に示した本実施形態の構成においては、放送受信装置１００にて特定の番組を視聴した事を情報発行装置３００が検証することができる。なおかつ、視聴証明書という改変不可能な情報を用い、携帯装置２００を介して視聴証明書を運搬することによって放送受信装置１００と情報発行装置３００をそれぞれ別の場所に設置しても上記目標を達成する事ができる。したがって、ある特定の番組を利用者が正式に視聴したことを契機に、情報発行装置３００が確認して、クーポンなどを発行するといったことが実現可能となる。

(第２の実施形態)
第１の実施形態では、放送受信装置１００が視聴証明書に署名する際に用いる鍵や、視聴証明書に埋め込む放送受信装置１００に固有のＩＤは、あらかじめ放送受信装置１００が備えていた。第２の実施形態では、放送受信装置管理サーバ５００を新たに備え、この放送受信装置管理サーバ５００から放送受信装置１００ｃに対して放送受信装置１００ｃが視聴証明書に署名する際に用いる鍵を配布する構成となっている。

図１５は第２の実施形態に係る放送受信装置１００ｃと携帯装置２００、情報発行装置３００ｃを備えた情報処理システムの概略構成を示す図である。図１の情報処理システムとの違いは、放送受信装置管理サーバ５００を備えている点と、放送受信装置１００ｃ及び情報発行装置３００ｃが、放送受信装置管理サーバ５００とインターネットを介して接続されている点である。

放送受信装置管理サーバ５００は、どのＩＤを持つ装置に視聴証明書に署名する鍵（署名用の鍵、秘密鍵）と、視聴証明書を検証する鍵（検証用の鍵、公開鍵）を配信したか管理し、署名用の鍵と検証用の鍵をそれぞれ放送受信装置１００ｃと情報発行装置３００ｃに配布する機能を持つ。

図１６は第２の実施形態に係る放送受信装置管理サーバ５００の内部構成を示すブロック図である。図１６の放送受信装置管理サーバ５００は、ＨＴＴＰサーバ処理部５０１、署名用鍵要求受信部５０２、署名用鍵送信部５０３、検証用鍵要求受信部５０４、検証用鍵送信部５０５、放送受信装置管理部５０６、署名用鍵生成部５０７、を備えている。

ＨＴＴＰサーバ処理部５０１は、ＨＴＴＰもしくはＨＴＴＰＳのプロトコルで通信する際のサーバ処理を行う。署名用鍵生成部５０７は、視聴証明書の署名に用いる鍵と視聴証明書を検証するための鍵を生成する処理を行う。署名用鍵送信部５０３は、署名用鍵生成部５０７が生成した視聴証明書の署名に用いる鍵を放送受信装置１００ｃに送信する処理を行う。検証用鍵送信部５０５は、署名用鍵生成部５０７が生成した視聴証明書の検証に用いる鍵を情報発行装置３００ｃに送信する処理を行う。署名用鍵要求受信部５０２は、放送受信装置１００ｃから視聴証明書の署名用の鍵を要求された場合に、署名用鍵送信部５０３に対して署名用の鍵を送信するよう依頼する処理を行う。放送受信装置１００ｃは視聴証明書の署名用の鍵を要求する際、その要求命令に自身のＩＤを含めて送信する。その場合、署名用鍵要求受信部５０２は、どのＩＤを持つ放送受信装置１００ｃにどの署名用鍵を送信したのか放送受信装置管理部５０６に通知する。放送受信装置管理部５０６は、放送受信装置１００ｃに配布した署名用鍵と放送受信装置のＩＤをペアとして蓄積しておく。検証用鍵要求受信部５０４は、情報発行装置３００ｃから視聴証明書の検証用の鍵を要求された場合に、検証用鍵送信部５０５に対して検証用の鍵を送信するよう依頼する処理を行う。

図１７は第２の実施形態に係る放送受信装置１００ｃの内部構成を示すブロック図である。図２に示す放送受信装置１００との違いは、鍵管理部１０８の代わりに登録部１２１とＩＤ・鍵管理部１２２を備えている点である。ＩＤ・鍵管理部１２２は、放送受信装置１００ｃに固有のＩＤ(ＤＴＶ ＩＤ)を蓄積する処理部である。さらに、ＩＤ・鍵管理部１２２は放送受信装置管理サーバ５００から、視聴証明書の署名用の鍵を受信して格納する処理も行う。

登録部１２１は、ＩＤ・鍵管理部１２２から放送受信装置１００ｃに固有のＩＤを取得し、放送受信装置管理サーバ５００に対してＩＤを送信して視聴証明書の署名用の鍵を要求し、鍵を受信したならばＩＤ・鍵管理部１２２に格納する処理を行う。

図１８は第２の実施形態に係る情報発行装置３００ｃの内部構成を示すブロック図である。図４に示す情報発行装置３００との違いは、第２鍵管理部３１１とＨＴＴＰ処理部３１２、および鍵要求部３１３を新たに備えている点である。第１の実施形態では、情報発行装置３００が視聴証明書に付与された署名を検証するための鍵をあらかじめ有している事を前提としていた。署名の方式として公開鍵方式を用い放送受信装置１００ごとに異なる鍵(秘密鍵(署名鍵))を割り当てたとすると、それに対応した数の検証鍵(公開鍵)を情報発行装置３００が備えておく事は困難である。そこで第２の実施形態では、情報発行装置３００ｃは放送受信装置管理サーバ５００に、検証に必要な公開鍵を問い合わせて取得する処理を行う。

鍵要求部３１３は、携帯装置２００から受信した視聴証明書に含まれる放送受信装置１００ｃに固有のＩＤ(ＤＴＶ ＩＤ)を取得し、放送受信装置１００ｃのＩＤを指定して検証用の鍵を送信するよう放送受信装置管理サーバ５００に要求する処理を行う。

第２鍵管理部３１１は、放送受信装置管理サーバ５００から受信した検証用の鍵を蓄積する処理を行う。

図１９は第２の実施形態における放送受信装置１００ｃ、携帯装置２００、情報発行装置３００ｃ、放送受信装置管理サーバ５００の処理手順を示すフローチャートである。まず放送受信装置１００ｃは登録部でＩＤ・鍵管理部１２２から放送受信装置１００ｃに固有のＩＤを取得し、ＨＴＴＰのプロトコルにて放送受信装置管理サーバ５００に登録依頼を送信する（ステップＳ２０１）。

放送受信装置管理サーバ５００は、視聴証明書を署名するための鍵（署名鍵）と検証するための鍵（検証鍵）を生成し、受信した放送受信装置１００ｃに固有のＩＤと共にそれら生成した鍵をＩＤ・鍵管理部１２２に登録すると共に、署名鍵を放送受信装置１００ｃに送信する（ステップＳ２０２、Ｓ２０３）。なお、ここでは登録依頼を元に鍵を生成する処理を説明したが、あらかじめ鍵を生成しておき、登録要求があった時点で、その鍵とＩＤを紐付けて格納するようにしてもよい。

以降、放送受信装置１００ｃで番組を視聴し、携帯装置２００から視聴証明書を情報発行装置３００ｃに送信するステップＳ１０６までは図５に示した第１の実施形態と同一の処理の流れとなる。情報発行装置３００ｃは視聴証明書を受信すると、第２鍵管理部３１１にて視聴証明書に含まれる放送受信装置１００ｃに固有のＩＤを取得し、そのＩＤと共に放送受信装置管理サーバ５００に対して検証用の鍵を要求するメッセージを送信する（ステップＳ２０４）。放送受信装置管理サーバ５００は放送受信装置１００ｃに固有のＩＤを元に検証用の鍵を放送受信装置管理部５０６から検索し（ステップＳ２０５）、情報発行装置３００ｃに送信する（ステップＳ２０６）。情報発行装置３００ｃは、受信した検証用の鍵を第２鍵管理部３１１に格納する。そして、視聴証明書検査部３０３にて取得した検証用の鍵を使って視聴証明書に添付された署名を検証する（ステップＳ２０７）。それ以降の処理は図５に示した第１の実施形態と同一である。

図２０は放送受信装置管理サーバ５００の別例である。図１６に示す放送受信装置管理サーバ５００との違いは、属性情報蓄積部５０８を新たに備えている点である。属性情報蓄積部５０８は、放送受信装置１００ｃに関連した情報を蓄積する処理部である。たとえば、放送受信装置１００ｃのＩＤに関連して、その放送受信装置１００ｃの所有者の性別や年齢、嗜好情報などを蓄積しておく処理部である。

図２１は図２０に対応した情報発行装置３００ｄの内部構成を示すブロック図である。図１８に示す情報発行装置３００との違いは、クーポン発行部３０２がＨＴＴＰ処理部３１２と接続されており、放送受信装置管理サーバ５００と通信する機能を有する点である。

図２２は図２０に対応した携帯装置２００ｂの内部構成を示すブロック図である。図３に示す携帯装置２００との違いは、属性情報登録部２３１を新たに備えている点である。属性情報登録部２３１は放送受信装置１００ｃに放送受信装置１００ｃのＩＤに関連した属性情報を登録する処理部である。視聴証明書には放送受信装置１００ｃの固有ＩＤが含まれている。属性情報登録部２３１は、視聴証明書蓄積部２０８からこのＩＤを取得する。さらに、入力受信部２０２で取得した性別や年齢、嗜好情報などの情報を放送受信装置管理サーバ５００に送信する処理を行う。

図２３は図２０〜図２２の構成における放送受信装置１００ｃ、携帯装置２００ｂ、情報発行装置３００ｄ、放送受信装置管理サーバ５００ａの処理手順を示すフローチャートである。携帯装置２００ｂが視聴証明書を保存するステップＳ１０６までは図１９と同じでよい。その後、携帯装置２００ｂは視聴証明書から放送受信装置１００ｃのＩＤに関連した属性情報を入力し（ステップＳ３０１）、放送受信装置１００ｃのＩＤと共に放送受信装置管理サーバ５００ａに送信する（ステップＳ３０２）。

放送受信装置管理サーバ５００ａは受信した属性情報を属性情報蓄積部５０８に登録する（ステップＳ３０３）。以降、放送受信装置管理サーバ５００が検証用の鍵を検索するまでは図１９のＳ２０５までの処理と同じでよい。放送受信装置管理サーバ５００ａは検証用の鍵と共に、その検証用の鍵に対応する属性情報を属性情報蓄積部５０８から取得し、情報発行装置３００ｄに送信する（ステップＳ３０４）。

以上に示した本実施形態においては、情報発行装置３００ｄは放送受信装置１００ｃの所有者に適切なクーポンを発行する事が可能となる。放送受信装置１００ｃを放送受信装置管理サーバ５００に登録する際、性別や年齢、家族構成などを登録すれば、情報発行装置３００ｄはクーポン発行時にその放送受信装置１００ｃを所有しているユーザを特定する事ができる。属性情報に対応した異なるクーポンを複数用意しておけば、同一の番組を視聴したユーザに対して、たとえば、一人暮らし男性用のクーポン、あるいは３人家族用クーポンといったように異なるクーポンを発行することが可能となる。

(第３の実施形態)
第１及び第２の実施形態では、どのような携帯装置２００でも視聴証明書を取得することができた。第３の実施形態では視聴証明書を取得可能な携帯装置２００を限定する事により、放送受信サーバから不要な視聴証明書の流出を防止するものである。

図２４は第３の実施形態に係る放送受信装置１００ｅの内部構成を示すブロック図である。図２に示す放送受信装置１００との違いは、公開鍵管理部１３１、ＰＩＮ管理部１３２、利用許可証検査部１３３（第１判定部）、利用許可証送信部１３５、アプリ出所検査部１３４（第２判定部）を新たに備えている点である。

公開鍵管理部１３１は、後述する利用許可証を検証するための公開鍵を蓄積する処理部である。ＰＩＮ管理部１３２は、パスワードを蓄積する処理部である。利用許可証検査部１３３は、後述する利用許可証が正当なものであるかを検査する処理部である。アプリ出所検査部１３４は、携帯装置２００上で動作するＷｅｂアプリが正当なＷｅｂアプリ配布サーバ４００からダウンロードしたものであるかどうかを出所情報によって検査する処理部である。利用許可証送信部１３５は、利用許可証を携帯装置２００ｅへと送信する。

図２５は第３の実施形態に係る携帯装置２００ｅの内部構成を示すブロック図である。図３に示す携帯装置２００との違いは、ＰＩＮ管理部２２１、ＰＩＮ送信部２２２、利用許可証送信部２２３を新たに備えている点である。ＰＩＮ管理部２２１は、パスワード(ＰＩＮ)を管理する処理部である。パスワードはアプリ実行部２０１で実行されるＷｅｂアプリによって、ユーザ入力部で入力された値がＰＩＮ管理部２２１に蓄積される。ＰＩＮ送信部２２２は、ＰＩＮ管理部２２１に蓄積されたＰＩＮを放送受信装置１００ｅに送信する処理部である。利用許可証送信部２２３は、アプリ実行部２０１で実行されるＷｅｂアプリが有する利用許可証を放送受信装置１００ｅに送信する処理を行う。

図２６は利用許可証のフォーマットの一例を示す図である。利用許可証は、必須のフィールドとして、Ｗｅｂアプリの出所（ドメイン名）、および署名を有する。Ｗｅｂアプリの出所は、利用許可証や視聴証明書の要求命令を放送受信装置１００ｅに送信するＷｅｂアプリの送信元Ｗｅｂサーバのドメイン名である。署名は、Ｗｅｂアプリの出所のハッシュ値に対して秘密鍵を利用して公開鍵暗号方式に従って計算した署名の値である。ハッシュアルゴリズムとしてはＭＤ５やＳＨＡ１などよく知られた方式を用い、署名アルゴリズムとしてはＲＳＡや楕円曲線暗号などよく知られた方式を用いればよい。署名の計算方法の一例としては、例えば、署名＝ｒｓａ(第２秘密鍵，ＳＨＡ１(Ｗｅｂアプリのドメイン名))などが考えられる。

ここで第２秘密鍵とは、Ｗｅｂアプリの開発者に付与する値である。この第２秘密鍵に対応する公開鍵が放送受信装置１００ｅの公開鍵管理部１３１に蓄積される。すなわち、放送受信装置１００ｅの公開鍵管理部１３１に蓄積された公開鍵に対応する第２秘密鍵を有する開発者しか、正当な署名を生成することはできない。

図２７は第３の実施形態における放送受信装置１００ｅと携帯装置２００ｅの処理手順を示すフローチャートである。まず、携帯装置２００ｅと放送受信装置１００ｅの通信に先立ち、双方の装置でパスワードを入力し、設定しておく（ステップＳ４０１）。この処理は、入力受信部１０１で受信した値をＰＩＮ管理部１３２に蓄積する処理である。

次に、アプリ実行部２０１で動作するＷｅｂアプリは、ＰＩＮ送信部２２２を利用してＰＩＮと、Ｗｅｂアプリ自身がリソースファイルとして有する利用許可証をＷｅｂｓｏｃｋｅｔクライアント処理部２０５を利用して放送受信装置１００ｅに送信する（ステップＳ４０２）。

この時、Ｗｅｂｓｏｃｋｅｔクライアント処理部２０５は、アプリ実行部２０１で実行中のＷｅｂアプリのドメイン名（出所情報）をＷｅｂｓｏｃｋｅｔヘッダ(Ｗｅｂｓｏｃｋｅｔコネクションのヘッダ)に付与する処理を行う。

次いで、放送受信装置１００ｅは、Ｗｅｂｓｏｃｋｅｔサーバ処理部１１２（許可証受信部、ヘッダ受信部）で受信したＰＩＮコードと利用許可証の検証を行う（ステップＳ４０３）。具体的には（ａ）携帯装置２００ｅから受信したＰＩＮの値が、ＰＩＮ管理部１３２に格納した値と一致するかを判定し、一致していれば成功とし、一致していなければ失敗と判定する。（ｂ）また、利用許可証検査部１３３が、公開鍵管理部１３１に格納されている公開鍵を用い、利用許可証に付与された署名の検証が成功するかを判定する。（ｃ）さらには、アプリ出所検査部１３４が、利用許可証に含まれるＷｅｂアプリの出所と、Ｗｅｂｓｏｃｋｅｔヘッダに付与されたＷｅｂアプリのドメイン名が一致もしくは包含関係にあるかを検査し、一致または包含関係にあれば成功とし、一致または包含関係になければ失敗と判定する。以上の（ａ）〜（ｃ）の判定のいずれか一つでも失敗すれば、検証失敗とみなす。また、すべて成功していた場合に成功とみなす。放送受信装置１００ｅは、その判定結果を携帯装置２００ｅに送信する（ステップＳ４０４）。

携帯装置２００ｅは、判定結果が成功していた場合、視聴証明書の送信要求を放送受信装置１００ｅに送信する（ステップＳ４０５）。放送受信装置１００ｅは、判定結果が成功していた場合に限り、視聴証明書を検索して携帯装置２００ｅに送信する（ステップＳ４０６）。もし判定結果が失敗していた場合は、視聴証明書を送信しない。

放送受信装置１００ｅに対して、視聴証明書を送信するよう要求命令を送信したり、放送受信装置１００ｅから視聴証明書を受信したりするのは携帯装置２００ｅ上のアプリ実行部２０１(アプリ実行部２０１で動作するＷｅｂアプリ)である。すなわち、アプリ実行部２０１で動作するＷｅｂアプリが悪意のあるＷｅｂアプリであった場合、視聴証明書を本来とは異なる目的で利用してしまう危険性がある。視聴証明書は、ユーザがどのような番組を視聴したかの履歴であるため、プライバシー情報とみなすことができ、不正なＷｅｂアプリはそれらプライバシー情報を流出させようとするかもしれない。

放送受信装置１００ｅが視聴証明書を携帯装置２００ｅに送信する際、携帯装置２００ｅのアプリ実行部２０１で動作するＷｅｂアプリの出所を確認することができる。さらに、この出所情報は利用許可証と一致するか否かで判定している。利用許可証は正当なアプリ開発者しか有しない第２秘密鍵によって署名が付与されているため、利用許可証を偽造する事は不可能である。

以上に示した本実施形態の構成にあっては、放送受信装置１００ｅは携帯装置２００ｅのアプリ実行部２０１で動作するＷｅｂアプリが正当なものである場合にのみ、視聴証明書を送信することが実現でき、プライバシー情報の流出を防止することができる。

図２８は放送受信装置１００ｆの別例である。図２４との違いはチャレンジ生成部１４１を新たに備えている点と、公開鍵管理部１３１の代わりに第２鍵管理部１４２を備えている点、及びＭＡＣ検証部１４３を備えている点である。

チャレンジ生成部１４１は、乱数を生成し、一次的に保存する処理を行う。携帯装置２００ｆから利用許可証が送信されてきた場合にチャレンジ生成部１４１を利用して乱数を生成し、携帯装置２００ｆに送信する。第２鍵管理部１４２は、利用許可証を検証する公開鍵と、後述するＭＡＣの検証に用いる第３秘密鍵を格納する処理部である。ＭＡＣ検証部１４３は、チャレンジ生成部１４１で生成した乱数と、第２鍵管理部１４２が格納しているＭＡＣの検証に用いる第３秘密鍵と、ＰＩＮ管理部１３２で管理しているパスワード(ＰＩＮ)からＭＡＣ値を生成し、そのＭＡＣ値と携帯装置２００ｆから受信したＭＡＣ値の値が一致するか検査する処理部である。一致すれば検査成功と判定し、一致しなければ失敗と判定する。ＭＡＣ値の計算方法については後述する。

図２９は携帯装置２００ｆの別例である。図２５との違いはＭＡＣ計算部２４１を新たに備えている点である。ＭＡＣ計算部２４１は、ＭＡＣ計算用の第３秘密鍵を管理している。そして、放送受信装置１００ｆから受信した乱数と、そのＭＡＣ計算用の第３秘密鍵を利用してメッセージ認証コードを生成する。携帯装置２００ｆが生成するメッセージ認証コードの計算方法の一例としては、ＭＡＣ値＝ＨＭＡＣ―ＳＨＡ１(ＭＡＣ鍵、ＰＩＮ｜｜チャレンジ)などが考えられる。

ここで、ＭＡＣ鍵はＭＡＣ計算部２４１で管理しているＭＡＣ計算用の第３秘密鍵を示し、ＰＩＮはＰＩＮ管理部２２１で管理しているパスワード(ＰＩＮ)を示し、チャレンジは放送受信装置１００ｆから受信した乱数である。アプリ実行部２０１で実行中のＷｅｂアプリは、放送受信装置１００ｆから送信される乱数の応答として、このＭＡＣ値を計算し、放送受信装置１００ｆに返信する。

図３０は放送受信装置１００ｆと携帯装置２００ｆの処理手順を示すフローチャートである。携帯装置２００ｆが利用許可証を送信するステップＳ４０１までは図２７に示したフローと同一である。携帯装置２００ｆはＰＩＮを送信せずに、利用許可証のみ放送受信装置１００に送信する（ステップＳ５０１）。次いで、放送受信装置１００ｆは利用許可書の正当性を検証する（ステップＳ５０２）。この際、携帯装置２００ｆから放送受信装置１００ｆにＰＩＮは送信しないため、上述した（ａ）の判定は行わず、（ｂ)、（ｃ)の両方の判定が成功していた場合に成功と判定する。

放送受信装置１００は、受信した利用許可証の署名を検証する。署名の検証に成功すれば以下の処理を行う。検証に成功すれば以下の処理は行わず、エラー処理を行う。エラー処理は、例えば利用者に対して検証が失敗した旨を通知するといった処理である。放送受信装置１００ｆはチャレンジ生成部１４１で乱数を生成し（ステップＳ５０３）、携帯装置２００ｆに送信する（ステップＳ５０４）。携帯装置２００ｆは上述の式に従ってＭＡＣ値を計算し（ステップＳ５０５）、放送受信装置１００ｆに送信する（ステップＳ５０６）。

放送受信装置１００ｆは、第２鍵管理部１４２で管理するＭＡＣの検証に用いる第３秘密鍵と、チャレンジ生成部１４１で生成した乱数と、ＰＩＮ管理部１３２で管理しているパスワード(ＰＩＮ)を用い、上述の携帯装置２００ｆが計算するＭＡＣ値の式と同様にＭＡＣ値を計算する。そして、放送受信装置１００ｆは、携帯装置２００ｆから送信されてくるＭＡＣ値と、自装置で計算したＭＡＣ値が一致するか検証し（ステップＳ５０７）、一致している場合に限り、視聴証明書を携帯装置２００ｆに送信する（ステップＳ５０８）。

以上で示した本実施形態の構成では携帯装置２００ｆから放送受信装置１００ｆにＰＩＮを送信しないため、ネットワーク上でＰＩＮの値が漏えいすることはない。さらに、正当なＭＡＣ値を計算できるのは正当なＭＡＣ鍵を有する端末に限定されるため、放送受信装置１００ｆは不正な携帯端末からの視聴証明書の要求を拒否することができる。

本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到し
うる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわ
ち、特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的
な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１ 情報処理システム
１００ 放送受信装置
１０１ 入力受信部
１０２ チューナー部
１０３ ＨＴＴＰ処理部
１０４ Ｗｅｂアプリ取得部
１０５ Ｗｅｂアプリ実行部
１０６ 視聴証明書取得部
１０７ 視聴証明書生成部
１０８ 鍵管理部
１０９ 視聴証明書管理部
１１０ 視聴証明書送信部
１１１ 機器操作命令処理部
１１２ Ｗｅｂｓｏｃｋｅｔサーバ処理部
１１２−２ ＨＴＴＰサーバ処理部
１１３ 画面出力部
１２１ 登録部
１２２ ＩＤ・鍵管理部
１３１ 公開鍵管理部
１３２ ＰＩＮ管理部
１３３ 利用許可証検査部
１３４ アプリ出所検査部
１３５ 利用許可証送信部
１４１ チャレンジ生成部
１４２ 第２鍵管理部
１４３ ＭＡＣ検証部
２００ 携帯装置
２０１ アプリ実行部
２０２ 入力受信部
２０３ ＨＴＴＰ処理部
２０４ アプリ取得部
２０５ Ｗｅｂｓｏｃｋｅｔクライアント処理部
２０６ 機器操作命令送信部
２０７ 視聴証明書受信部
２０８ 視聴証明書蓄積部
２０９ クーポン蓄積部
２１０ 視聴証明書送信部
２１１ クーポン受信部
２１３ 画面出力部
２１４ 近接無線送信部
２１５ ＨＴＴＰ処理部
２２１ ＰＩＮ管理部
２２２ ＰＩＮ送信部
２２３ 利用許可証送信部
２３１ 属性情報登録部
２４１ ＭＡＣ計算部
３００ 情報発行装置
３０１ クーポン管理部
３０２ クーポン発行部
３０３ 視聴証明書検査部
３０４ Ｗｅｂｓｏｃｋｅｔサーバ処理部
３０５ 鍵管理部
３０６ 近接無線受信部
３０７ ＨＴＴＰサーバ処理部
３１１ 鍵管理部
３１２ ＨＴＴＰ処理部
３１３ 鍵要求部
４００ アプリ配布サーバ
５００ 放送受信装置管理サーバ
５０１ ＨＴＴＰサーバ処理部
５０２ 署名用鍵要求受信部
５０３ 署名用鍵送信部
５０４ 検証用鍵要求受信部
５０５ 検証用鍵送信部
５０６ 放送受信装置管理部
５０７ 署名用鍵生成部
５０８ 属性情報蓄積部

Claims (14)

1. 放送番組を特定する情報と、放送番組と特定の放送番組を受信したことを証明する視聴証明書を含む放送波を受信するチューナー部と、
   前記チューナー部で受信した放送波から、前記視聴証明書を取得する取得部と、
   取得した前記視聴証明書に鍵を使って署名を施す署名実行部と、
   外部装置とネットワーク経由で接続された第１インタフェース部と、
   前記外部装置から前記視聴証明書の取得命令を受信する命令受信部と、
   前記外部装置において実行されるアプリケーションの出所情報を含む利用許可証を前記外部装置から受信する許可証受信部と、
   前記外部装置において実行中の前記アプリケーションの前記出所情報を含むデータを前記外部装置から受信するデータ受信部と、
   前記データに含まれる出所情報と、前記利用許可証に含まれる出所情報とを比較する第２判定部と、
   比較結果に基づいて、前記署名が施された前記視聴証明書を、前記取得命令を発行した前記外部装置へと送信する送信部と、
   を備えることを特徴とする放送受信装置。
2. 前記鍵を管理する管理サーバに対して前記外部装置とは異なるプロトコルで接続する第２インタフェース部と、
   前記第２インタフェース部を用いて前記管理サーバから前記鍵を受信する鍵受信部と、 前記鍵受信部で受信した前記鍵を記憶する鍵記憶部と、
   を更に備え、
   前記署名実行部は、前記鍵記憶部に記憶された前記鍵を使って前記視聴証明書に署名を施す
   ことを特徴とする請求項１に記載の放送受信装置。
3. 前記第１インタフェース部は、ＷｅｂＳｏｃｋｅｔプロトコルで通信することを特徴とする請求項１に記載の放送受信装置。
4. 前記第１インタフェース部は、ＷｅｂＳｏｃｋｅｔプロトコルで通信し、
   前記第２インタフェース部は、ＨＴＴＰで通信する
   ことを特徴とする請求項２に記載の放送受信装置。
5. 前記許可証受信部は、署名を含む前記利用許可証を受信し、
   前記署名に用いる鍵と対応する公開鍵を記憶する鍵管理部と、
   受信した前記利用許可証に含まれる署名が正しいかを、前記鍵管理部に記憶された前記公開鍵を用いて検証する第１判定部と、
   をさらに備え、
   前記第２判定部は、受信した前記データに含まれる前記出所情報が、前記利用許可証に含まれる前記出所情報と一致するか否か、および、受信した前記データに含まれる前記出所情報が前記利用許可証に含まれる前記出所情報を包含するか否か、のうち少なくとも１つを判定し、
   前記送信部は、前記第１判定部と前記第２判定部の判定が肯定の場合に、前記視聴証明書を前記外部装置に送信する
   ことを特徴とする請求項１に記載の放送受信装置。
6. 前記許可証受信部は、署名を含む前記利用許可証を受信し、
   前記署名に用いる鍵と対応する公開鍵を記憶する鍵管理部と、
   受信した前記利用許可証に含まれる署名が正しいかを、前記鍵管理部に記憶された前記公開鍵を用いて検証する第１判定部と、
   をさらに備え、
   前記第２判定部は、受信した前記データに含まれる前記出所情報が、前記利用許可証に含まれる前記出所情報が受信した前記データに含まれる前記出所情報を包含するか否か、を判定し、
   前記送信部は、前記第１判定部と前記第２判定部の判定が肯定の場合に、前記視聴証明書を前記外部装置に送信する
   ことを特徴とする請求項１に記載の放送受信装置。
7. 装置固有のパスワードを管理する管理部と、
   前記外部装置から送信されたパスワードが、前記管理部により管理された前記パスワードと一致するか否かを判定する第３判定部と、
   を更に備え、
   前記送信部は、前記第３判定部により一致すると判定された場合に前記視聴証明書を前記外部装置に送信する
   ことを特徴とする請求項５または６に記載の放送受信装置。
8. 乱数を生成して前記外部装置に対して送信するチャレンジ生成部と、
   ＭＡＣ値の生成、及び検証に用いる秘密鍵を記憶する第２管理部と、
   前記外部装置から第２ＭＡＣ値を受信し、前記パスワード、前記乱数、及び前記秘密鍵とからＭＡＣ値を生成し、生成したＭＡＣ値が前記第２ＭＡＣ値と一致するか否かを検証するＭＡＣ検証部と、
   を更に備えることを特徴とする請求項７に記載の放送受信装置。
9. 前記視聴証明書には、前記放送番組が生放送か、録画かを示す情報が含まれる
   ことを特徴とする請求項１に記載の放送受信装置。
10. 前記視聴証明書には、前記外部装置の識別情報が含まれる
    ことを特徴とする請求項１に記載の放送受信装置。
11. 放送波を受信する放送受信装置と、前記放送受信装置を通じて前記放送波に含まれる放送番組を視聴した事を示す情報を管理する外部装置と、前記外部装置に対して特定の情報を送信する情報発行装置と、を備えた情報処理システムであって、
    前記放送受信装置は、
    放送番組を特定する情報と、特定の放送番組を受信したことを証明する視聴証明書を放送波から受信するチューナー部と、
    前記チューナー部で受信した前記視聴証明書を取得する取得部と、
    取得した前記視聴証明書に鍵を使って署名を施す署名実行部と、
    前記外部装置とネットワーク経由で接続されたネットワークインタフェース部と、
    前記外部装置から前記視聴証明書の取得命令を受信する命令受信部と、
    前記外部装置において実行されるアプリケーションの出所情報を含む利用許可証を前記外部装置から受信する許可証受信部と、
    前記外部装置において実行中の前記アプリケーションの前記出所情報を含むデータを前記外部装置から受信するデータ受信部と、
    前記データに含まれる出所情報と、前記利用許可証に含まれる出所情報とを比較する第２判定部と、
    比較結果に基づいて、前記署名が施された前記視聴証明書を、前記取得命令を発行した前記外部装置へと送信する送信部と、
    を備え、
    前記外部装置は、
    前記視聴証明書を前記放送受信装置に対して要求する命令送信部と、
    前記視聴証明書を受信する視聴証明書受信部と、
    受信した前記視聴証明書を蓄積する視聴証明書蓄積部と、
    蓄積された前記視聴証明書を前記情報発行装置へと送信する視聴証明書送信部と、
    を備え、
    前記情報発行装置は、
    視聴証明書の署名を検証するための公開鍵を管理する公開鍵管理部と、
    前記外部装置から受信した前記視聴証明書に付与された署名が正しいかを前記公開鍵を用いて検証する視聴証明書検査部と、
    発行する所定のクーポンを管理するクーポン管理部と、
    前記視聴証明書検査部で前記視聴証明書が正しいと判定された場合に前記クーポン管理部から前記クーポンを発行するクーポン発行部と、
    を備えることを特徴とする情報処理システム。
12. 前記放送受信装置に対して、前記視聴証明書の署名用の鍵を送信する署名用鍵送信部と、
    前記情報発行装置に対して、前記視聴証明書検査部が用いる前記公開鍵を送信する検証用鍵送信部と、
    を備える管理サーバを更に備えることを特徴とする請求項１１に記載の情報処理システム。
13. 前記管理サーバは、
    前記放送受信装置と関連付けて、前記放送受信装置の所有者の属性情報を記憶する属性情報蓄積部を更に備え、
    前記検証用鍵送信部は、前記公開鍵とともに、対応する前記属性情報を前記情報発行装置へと送信し、
    前記クーポン発行部は、受信した前記属性情報に基づいて、発行する前記クーポンの内容を変更する
    ことを特徴とする請求項１２に記載の情報処理システム。
14. アプリケーションを実行する情報処理装置であって、
    視聴証明書を放送受信装置に対して要求する命令送信部と、
    前記アプリケーションの出所情報を含む利用許可証を前記放送受信装置に対して送信する許可証送信部と、
    実行中の前記アプリケーションの前記出所情報を含むデータを前記放送受信装置に対して送信する送信部と、
    前記放送受信装置から、前記利用許可証に含まれる出所情報と前記データに含まれる出所情報との比較結果に基づいて送信される前記視聴証明書を受信する視聴証明書受信部と、
    受信した前記視聴証明書を蓄積する視聴証明書蓄積部と、
    蓄積された前記視聴証明書を情報発行装置へと送信する視聴証明書送信部と、
    を備える情報処理装置。

Images