JP2014038521A - 情報操作装置、情報出力装置および情報処理方法 - Google Patents

情報操作装置、情報出力装置および情報処理方法 Download PDF

Info

Publication number
JP2014038521A
JP2014038521A JP2012181067A JP2012181067A JP2014038521A JP 2014038521 A JP2014038521 A JP 2014038521A JP 2012181067 A JP2012181067 A JP 2012181067A JP 2012181067 A JP2012181067 A JP 2012181067A JP 2014038521 A JP2014038521 A JP 2014038521A
Authority
JP
Japan
Prior art keywords
web application
information
unit
information output
output device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012181067A
Other languages
English (en)
Other versions
JP5662391B2 (ja
Inventor
Hiroshi Isozaki
崎 宏 磯
Jun Kanai
井 遵 金
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2012181067A priority Critical patent/JP5662391B2/ja
Priority to US13/967,616 priority patent/US9391961B2/en
Publication of JP2014038521A publication Critical patent/JP2014038521A/ja
Application granted granted Critical
Publication of JP5662391B2 publication Critical patent/JP5662391B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】ユーザの許諾なしに情報出力装置が勝手に操作されることを防止する。
【解決手段】情報操作装置１は、第１通信装置から第１コネクション部を介して取得した暗証コード入力用ウェブアプリケーションを実行するとともに、第１コネクション部を介して取得した機器操作用ウェブアプリケーションを実行し、機器操作用ウェブアプリケーションの利用許可証を第１通信装置から受信し、ユーザが入力した暗証コードと乱数に基づいて、情報出力装置と共有する共通鍵を用いて暗号情報を生成して情報出力装置２に送信し、第２コネクション部を介して情報出力装置に利用許可証と暗号情報とを送信する。情報出力装置が検査した利用許可証と暗号情報との検査結果が正しければ、機器操作用ウェブアプリケーションに含まれる機器操作命令を、第２コネクション部を介して情報出力装置に送信する。
【選択図】図１

Description

本発明の実施形態は、機器操作命令の送受を行う情報操作装置、情報出力装置および情報出力方法に関する。
近年、スマートフォンやタブレット等の情報操作端末とＴＶをインタフェースを介して接続し、ＴＶを操作する技術がある。
DTCP Volume 1 Supplement E Mapping DTCP to IP, Revision 1.4ed1 (Informational Version). http://www.dtcp.com/documents/dtcp/Info%2020111214%20DTCP%20V1SE%20IP%20Rev%201.4ed1.pdf HDCP Specification Rev. 1.4 http://www.digital-cp.com/files/static_page_files/5C3DC13B-9F6B-D82E-D77D8ACA08A448BF/HDCP%20Specification%20Rev1_4.pdf
本実施形態は、ユーザの許諾なしに情報出力装置が勝手に操作されることを防止しつつ、情報操作装置から情報出力装置を操作できるようにして利便性を向上させた情報操作装置、情報出力装置および情報処理方法を提供するものである。
本実施形態によれば、第１通信装置から機器操作用ウェブアプリケーションおよび暗証コード入力用ウェブアプリケーションを取得するための接続確立処理を行う第１コネクション部と、
前記機器操作命令の送信を指示する前記機器操作用ウェブアプリケーションが正規の前記第１通信装置から取得されたものであることを証明する利用許可証と、情報出力装置を操作するための機器操作命令と、を前記情報出力装置に送信するための接続確立処理を行う第２コネクション部と、
前記第２コネクション部で情報出力装置とコネクションを確立し、前記コネクションを用いて前記情報出力装置を操作するための機器操作命令を送信する際に、前記機器操作用ウェブアプリケーションの送信元である前記第１通信装置のドメイン名を前記コネクションのヘッダに付与するドメイン名付与部と、
前記第１通信装置から前記第１コネクション部を介して取得した前記暗証コード入力用ウェブアプリケーションを実行するとともに、前記第１コネクション部を介して取得した前記機器操作用ウェブアプリケーションを実行し、前記機器操作用ウェブアプリケーションに対応する前記ウェブアプリケーションの利用許可証を前記第１通信装置から受信するアプリケーション実行部と、
前記実行された暗証コード入力用ウェブアプリケーションに応じてユーザが入力した前記暗証コード、および乱数に基づいて、前記情報出力装置と共有する共通鍵を用いて暗号情報を生成して前記情報出力装置に送信する暗号情報生成部と、
前記第２コネクション部を介して前記情報出力装置に前記利用許可証と前記暗号情報とを送信し、前記情報出力装置が検査した前記利用許可証と前記暗号情報との検査結果が正しければ前記機器操作用ウェブアプリケーションに含まれる前記機器操作命令を、前記第２コネクション部を介して前記情報出力装置に送信するクライアント処理部と、を備えることを特徴とする情報操作装置を提供する。
第１の実施形態に係る情報処理システム３の概略構成を示す図。 第１の実施形態に係る情報操作装置１の内部ブロック図。 情報操作装置１の内部ブロック図。 第１の実施形態に係る情報出力装置２の内部ブロック図。 第１の実施形態に係るWebアプリ配布サーバ４の内部ブロック図。 第１の実施形態に係るPFアプリ配布サーバ５の内部ブロック図。 第１の実施形態に係る利用許可証配布サーバ６の内部ブロック図。 利用許可証配布サーバ６の一変形例を示す内部ブロック図。 第１の実施形態の処理手順を示すフローチャート。 第１の実施形態の情報出力装置セットアップフェーズの処理シーケンス図。 第１の実施形態の情報操作装置セットアップフェーズの処理シーケンス図。 PFアプリの一覧の表示例の一例を示す図。 第１の実施形態におけるPFアプリの構造を示す図。 第１の実施形態における情報出力装置操作フェーズの処理シーケンス図。 取得した情報出力装置２の一覧をアイコンとして表示する例を示す図。 情報出力装置２のPINの入力を促すメッセージを示す図。 利用許可証のフォーマットの一例を示す図。 ローカルWebアプリを含めない場合のPFアプリのブロック図。 情報出力装置操作フェーズの処理シーケンス図。 情報出力装置操作フェーズ（レベル２）の処理シーケンス図。 リモコン画面の表示例を示す図。 PFアプリ実行部２１が利用許可証を送信する場合の処理シーケンス図。 情報出力装置操作フェーズ（レベル2）の一変形例の処理シーケンス図。 情報出力装置操作フェーズ（レベル2）の一変形例の処理シーケンス図。 情報操作装置１の一変形例の内部ブロック図。 情報出力装置操作フェーズ（レベル2）の一変形例の処理シーケンス図。 情報操作装置１の一変形例の内部ブロック図。 情報出力装置２の一変形例の内部ブロック図。 情報出力装置操作フェーズ（レベル2）の一変形例の処理シーケンス図。 第２の実施形態に係る情報出力装置２の内部ブロック図。 第２の実施形態の処理シーケンス図。 情報出力装置操作フェーズ（レベル1）の処理シーケンス図。 情報操作装置１の一変形例の内部ブロック図。 情報出力装置２の一変形例の内部ブロック図。 情報出力装置２に表示されるPINの画面の表示例を示す図。 情報出力装置操作フェーズ（レベル1）の一変形例の処理シーケンス図。 情報出力装置２の一変形例の内部ブロック図。 第３の実施形態に係る利用許可証のフォーマットの一例を示す図。 第３の実施形態に係る情報出力装置２の内部構成を示すブロック図。 ＰＩＮコード入力画面を示す図。 利用許可証のフォーマットの一例を示す図。 第４の実施形態の処理手順を示すシーケンス図。 第４の実施形態の利用許可証のフォーマットの一例を示す図。 第４の実施形態に係る利用許可証配布サーバ６の内部構成ブロック図。 第４の実施形態に係る情報出力装置２の内部構成ブロック図。 第４の実施形態の情報操作装置の内部構成ブロック図。 第４の実施形態の情報出力装置操作フェーズ(レベル1)のシーケンス図。 図４６に続くシーケンス図。 図４７に続くシーケンス図。 第５の実施形態に係る情報操作装置１の内部構成を示すブロック図。 図４９Ａの一変形例に係るブロック図。 図４９Ａの他の変形例に係るブロック図。 図４９Ｃの一変形例に係るブロック図。 PIN入力用Webアプリ配布サーバ４ａの内部構成を示すブロック図。 第５の実施形態に係る情報出力装置２の内部構成を示すブロック図。 図５１Ａの一変形例に係る情報出力装置２のブロック図。 第５の実施形態の処理手順を示すシーケンス図。 図５２に続くシーケンス図。 図５３Ａの一変形例に係るシーケンス図。 図５３Ｂの一変形例に係るシーケンス図。 図５３Ｃの一変形例に係るシーケンス図。 情報操作装置１の別の構成を示すブロック図。 図５４Ａの一変形例に係るブロック図。 図５４Ａの他の変形例に係るブロック図。 図５４Ｃの一変形例に係るブロック図。 図５４の情報操作装置１に対応する情報出力装置２のブロック図。 図５５Ａの一変形例に係る情報出力装置２のブロック図。 MAC値を利用する場合の処理手順を示すシーケンス図。 図５６Ａの一変形例に係るシーケンス図。 図５６に続くシーケンス図。 図５７に続くシーケンス図。 図５８Ａの一変形例に係るシーケンス図。 図５８に続くシーケンス図。 図５９Ａの一変形例に係るシーケンス図。
(第１の実施形態)
図１は第１の実施形態に係る情報操作装置１と情報出力装置２を備えた情報処理システム３の概略構成を示す図である。図１の情報処理システム３は、放送波に含まれるＡＶデータや文字情報を映像として出力可能な情報出力装置２と、情報出力装置２を操作する情報操作装置１と、ウェブアプリケーション（以下、Webアプリ）を配布するWebアプリ配布サーバ４と、プラットホームに固有のアプリ（以下、PFアプリ）を配布するPFアプリ配布サーバ５と、情報出力装置２を操作する時に必要となる利用許可証を配布する利用許可証配布サーバ６と、を備えている。
ここで、利用許可証とは、情報出力装置２に機器操作命令を送信する権利を有するWebアプリ開発者が開発した正規のWebアプリであり、なおかつ正規のWebアプリ配布サーバ４から配布されたものであることを証明する情報であり、利用許可証はWebアプリごとに発行される。すべてのWebアプリに対応して利用許可証が発行されるわけではなく、後述するように、利用許可証を利用できるWebアプリは制限されている。
情報操作装置１と情報出力装置２は、有線または無線のネットワーク７で接続されており、情報操作装置１は情報出力装置２の各種機能を操作するための機器操作命令を情報出力装置２に送信する。また、情報操作装置１は、上述した利用許可証を情報出力装置２に送信し、機器操作命令が正規のWebアプリからのものであることを情報出力装置２に把握させる。
情報操作装置１は、インターネット８を介してWebアプリ配布サーバ４、PFアプリ配布サーバ５、および利用許可証配布サーバ６と接続されており、それぞれWebアプリ、PFアプリ、および利用許可証を受信する。情報出力装置２はインターネット８を介して利用許可証配布サーバ６と接続されている。
情報操作装置１から情報出力装置２に機器操作命令を送るための物理レイヤとリンクレイヤとして、赤外線、IEEE802.11規格に準拠した無線LAN、イーサネット（登録商標）などの種々の通信形態が採用可能であるが、図１では一例として無線LAN７を示している。
なお、これらインタフェースが有線であるか無線であるかは問わない。ネットワークレイヤとして、インターネットプロトコル（IP）を使用する場合は、IPv4でもよいし、IPv6でもよい。インタフェースがIPの場合には、情報操作装置１と情報生成装置の間に不図示の無線アクセスポイント機器やルータ機器等が接続されていてもよい。ここでは一例として、情報操作装置１から情報出力装置２に無線LAN７を介して機器操作命令を送る例を説明するが、ネットワーク形態は特に問わない。
ここで、機器操作命令とは、情報出力装置２の機能を制御する命令であり、例えば、情報出力装置２が有するチューナ部を制御する命令（チューナ部に対する選局命令など）や音量調節命令、入力切り替え命令（放送チューナ入力から外部入力に切り替える等）などを指す。情報出力装置２が放送コンテンツを録画・蓄積する機能を備えている場合は、機器操作命令に録画コンテンツの一覧表示命令、指定した録画コンテンツに対する再生命令、指定した録画コンテンツの特定の位置から再生を指示する再生命令、指定した録画コンテンツに対する削除命令なども含まれる。
情報操作装置１は、情報出力装置２と通信するコネクションとは別に、Webアプリ配布サーバ４、PFアプリ配布サーバ５、および利用許可証配布サーバ６と通信するためのIPインタフェースを備えている。同様に、情報出力装置２も情報操作装置１と通信するコネクションとは別に、利用許可証配布サーバ６と通信するためのIPインタフェースを備えている。これらIPインタフェースは、後述するHTTP処理部に内蔵される。
IPインタフェースの物理レイヤとリンクレイヤとして、IEEE802.11規格に準拠した無線LANやイーサネットなど種々の通信形態が採用可能である。ネットワークレイヤとして、インターネットプロトコル（IP）を使用する場合は、IPv4でもよいし、IPv6でもよい。
また、情報操作装置１とWebアプリサーバ、PFアプリ配布サーバ５、利用許可証配布サーバ６は、例えばインターネット８を介してインターネットプロトコル（IP）で接続されている。同様に情報出力装置２と利用許可証配布サーバ６は、例えばインターネット８を介してIPで接続されている。
情報操作装置１は、PFアプリ配布サーバ５からPFアプリをダウンロードし、Webアプリ配布サーバ４からWebアプリをそれぞれダウンロードして実行する。情報操作装置１は複数のPFアプリ配布サーバ５からそれぞれ異なる複数のPFアプリをダウンロードしたり、複数のWebアプリ配布サーバ４からそれぞれ異なる複数のWebアプリをダウンロードしたりしてもよい。
図２は第１の実施形態に係る情報操作装置１の内部構成を示すブロック図である。図２の情報操作装置１は、アプリ蓄積部３０、HTTP処理部１１、アプリ取得部１２、アプリキャッシュ部１３、利用許可証取得部１４、入力受信部１５、アプリ実行部１６、画面出力部１７、Websocketクライアント処理部（クライアント処理部）１８、機器操作命令送信部１９、リダイレクト処理部、機器検索処理部２０、アプリ蓄積部３０およびリダイレクト部５５を有する。
アプリ蓄積部３０は、PFアプリ、Webアプリのキャッシュ、PFアプリが利用するデータ、及びWebアプリが格納するデータを記録する処理を行う。PFアプリ、Webアプリのキャッシュなどアプリ蓄積部３０がデータを記録する媒体としては情報操作装置２に内蔵のハードディスクドライブやフラッシュメモリ、外付けハードディスクドライブやSDカードなどの汎用の記録媒体が使用可能である。
HTTP処理部１１は、Webサーバ(HTTPサーバ)との間で、HTTP(Hypertext Transfer Protocol)もしくはHTTPS(Hypertext Transfer Protocol over Secure Socket Layer)のプロトコルで通信し、後述するWebアプリ、利用許可証の要求、取得に必要なHTTPクライアント処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。
HTTP処理部１１は、Webアプリ配布サーバ４からWebアプリを取得するための接続確立処理を行う第１コネクション部を内蔵する。
HTTP処理部１１は、後述するアプリ取得部１２からの要求に応じて、所定のWebサーバ(Webアプリ配布サーバ４、PFアプリ配布サーバ５)に後述するPFアプリとWebアプリの取得要求を送信し、取得要求したPFアプリとWebアプリを受信する。HTTP処理部１１は、受信したPFアプリとWebアプリをアプリ取得部１２に送信する。
HTTP処理部１１は、後述する利用許可証取得部１４からの要求に応じて、利用許可証配布サーバ６に後述する利用許可証の取得要求を送信し、要求した利用許可証を利用許可証取得部１４で受信する。HTTP処理部１１は、受信した利用許可証を利用許可証取得部１４に送信する。
アプリ取得部１２は、HTTP処理部１１を使って、所定のWebサーバ(Webアプリ配布サーバ４、PFアプリ配布サーバ５)から後述するPFアプリとWebアプリを取得する処理を行う。
アプリキャッシュ部１３は、アプリ取得部１２で取得したPFアプリもしくはWebアプリの全部もしくは一部のデータをキャッシュとしてアプリ蓄積部３０に格納する処理を行う。Webアプリのうち、どの部分をキャッシュとしてアプリ蓄積部３０に格納するかは、Webアプリの開発者があらかじめ設定ファイルに記述しておく。アプリキャッシュ部１３はその設定ファイルに従って、指定された部分をキャッシュとしてアプリ蓄積部３０に格納する。
利用許可証取得部１４は、HTTP処理部１１を使って利用許可証配布サーバ６から利用許可証を取得する。
入力受信部１５は、タッチパッドやキーボード、マウスなどの入力機器を介してユーザが入力した情報を受信し、入力した情報をアプリ実行部１６に通知する。
アプリ実行部１６は、アプリ取得部１２で取得したWebアプリやPFアプリ、アプリ蓄積部３０に蓄積されているWebアプリやPFアプリを実行する。アプリがWebアプリの場合はWebブラウザを用いて実行する。詳細は後述する。
画面出力部１７は、アプリ実行部１６で生成した画面を自装置内の不図示のモニターに表示もしくは外部出力インタフェースに出力する。外部出力インタフェースとは、例えばHDMI（High-Definition Multimedia Interface）やコンポジット、S-Video、コンポーネントのようなインタフェースのことを指す。
Websocketクライアント処理部１８は、RFC6455規格で定められたウェブソケット（Websocket）と呼ばれるプロトコルに従って情報出力装置２と通信を行うためのクライアント処理を行う。機器操作命令送信部１９やアプリ実行部１６から送られてくるデータ(機器操作命令、利用許可証)は、このWebsocketクライアント処理部１８で処理され、RFC6455規格で定められたフォーマットに従って、ヘッダなどを付与して情報出力装置２に送信される。Websocketクライアント処理部１８はドメイン付与部７０を備えている。Websocketクライアント処理部１８のドメイン付与部７０はWebアプリ実行部２２で実行中のWebアプリのドメイン名（出所情報）をWebsocketヘッダ（Websocketコネクションのヘッダ（特許請求の範囲のコネクションのヘッダに対応））に付与する処理を行う。その理由については後述する。
Websocketクライアント処理部１８は、機器操作命令と利用許可証を情報出力装置２に送信するための接続確立処理を行う第２コネクション部を内蔵する。
機器操作命令送信部１９は、アプリ実行部１６からの命令に基づいて機器操作命令をWebsocketクライアント処理部１８を使って情報出力装置２に送信する処理を行う。
リダイレクト処理部５５は、HTTP処理部１１で受信したメッセージの中に、HTTPリダイレクト命令に含まれる場合には、その命令の中に含まれるURLを取得し、そのURLで指示されたWebアプリを取得するようアプリ取得部１２に指示する。
機器検索処理部２０は、アプリからの要求に基づいてネットワーク上に情報出力装置２など他の装置が存在するかどうかを検索し、存在する場合は情報出力装置２のIPアドレスやWebsocketのTCPポート番号などを取得する。具体的には、アプリからの要求に基づいてアプリ実行部１６が機器検索処理部２０に機器検索要求を送信し、機器検索処理部２０はその結果をアプリ実行部１６に通知し、アプリ実行部１６はアプリにその結果を通知する。
このように、機器検索処理部２０は、情報出力装置２に装置検索要求を送信して、情報出力装置２から送信された、情報出力装置２の名前やIPアドレス等を受信するためのネットワークセッション確立処理を行うコネクション部を有する。機器検索の詳細は後述する。なお、機器検索処理部２０は必須の構成ではない。
より具体的には、機器検索処理部２０は、情報出力装置のID等の識別情報を取得するためのネットワークセッション確立処理を行う第３コネクション部を内蔵する。この第３コネクション部で情報出力装置２のIPアドレス等を取得した後に、上述したWebsocketクライアント処理部１８は、機器検索処理部２０が受信した情報出力装置２のIPアドレス等に基づいて、情報出力装置２に対して機器操作命令と利用許可証を送信するための第２コネクション部の接続確立処理を行う。
なお、本実施形態では、Webアプリとプラットホーム固有アプリ(PFアプリ)の二種類のアプリケーション・ソフトウェアが存在することを念頭に置いている。
Webアプリは、HTML（HyperText Markup Language）やJavaScript（登録商標）などが解釈できるWebブラウザの実行環境で実行されるアプリケーションのことを指す。なお、HTMLのバージョンは４でもよいし５でもよい。Webアプリは一般に、複数のページファイルとメディアファイルを有する。
ここで、メディアファイルとは、JPEG、GIF、およびMPEGなどの動画像データが納められたファイルや、MP3などの音声データが納められたファイルを指す。これに対して、ページファイルには、HTMLなどで記述する文字や画像等の配置情報、表示文字データなどに加えて、JavaScriptのような制御プログラム情報が格納される場合がある。また、HTML５またはJavaScriptからはHTTP(XMLHTTPRequest)やWebSocketと呼ばれるプロトコルでHTTPサーバや、WebSocketサーバと通信することができる。
プラットホーム固有アプリとは、Webブラウザ上ではなく、オペレーティングシステム（OS）あるいは仮想マシン(Virtual Machine)上で実行されるアプリケーションを指し、プロセッサやOSや仮想マシンに依存するアプリを意味する。これらのプラットホーム固有アプリは、アプリの実行ファイル(実行バイナリファイル)と、静止画データやテキストデータなどのアプリで利用するデータが一つのファイルとしてパッケージ化された形で配布される。以下、PFアプリと省略して記述する。
図３は情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図である。
図３のアプリ実行部１６は、PFアプリ９を実行するPFアプリ実行部（第１アプリ実行部）２１と、Webアプリ１０を実行するWebアプリ実行部（第２アプリ実行部）２２とを有する。
Webアプリ実行部２２は、汎用のWebブラウザで実現され、Webブラウザの機能としては、利用許可証アクセス制御部２３と、利用許可証蓄積部２４と、利用許可証送信部２５とを有する。
アプリ取得部１２はさらに、HTTP処理部１１を介してWebサーバ(PFアプリ配布サーバ５)と通信してPFアプリ９を取得するPFアプリ取得部（第１アプリ取得部）２６と、同じくHTTP処理部１１を介してWebサーバ(Webアプリ配布サーバ４)と通信してWebアプリ１０を取得するWebアプリ取得部２７とを有する。
アプリキャッシュ部１３はさらに、PFアプリ取得部２６で取得したPFアプリ９をアプリ蓄積部３０に格納するPFアプリキャッシュ部２８と、Webアプリ取得部２７で取得したWebアプリ１０をアプリ蓄積部３０に格納するWebアプリキャッシュ部２９とを有する。 Webアプリ１０をキャッシュとしてアプリ蓄積部３０に蓄積する際の技術としてW3Cで規格化されているHTML5仕様のAppCache機能を利用してもよい。
次にWebアプリ実行部２２の詳細について説明する。
利用許可証蓄積部２４は、利用許可証取得部１４で利用許可証配布サーバ６から取得した利用許可証をアプリ蓄積部３０に格納する処理を行う。
Webアプリ実行部２２はWebブラウザであるため、W3Cで規格化が進められているWeb Storage仕様に従って情報操作装置１内のアプリ蓄積部３０にWebアプリを記憶してもよいし、RFC 6265で規定されたHTTP Cookieに従って情報操作装置１内のアプリ蓄積部３０にWebアプリを記憶してもよい。
利用許可証アクセス制御部２３は、利用許可証蓄積部２４に蓄積した利用許可証をWebアプリ配布サーバ４のドメイン毎に管理する。情報操作装置１は複数のWebアプリ配布サーバ４と通信し、それぞれ異なる複数のWebアプリを取得して実行する可能性がある。利用許可証配布サーバ６は利用許可証を利用できるWebアプリを制限するために、利用許可証の利用を許可するWebアプリのドメインの範囲を指定して情報操作装置１に保存する。具体的には、Cookieとして情報操作装置１に利用許可証を保存する場合、利用許可証配布サーバ６はRFC 2965やRFC6265で規定されたSet-CookieヘッダなどのCookieを保存する命令のパラメタとしてドメイン名を指定するようにすればよい。
利用許可証アクセス制御部２３は、Webアプリから利用許可証蓄積部２４内に蓄積された利用許可証の利用要求があった場合、Webアプリのドメイン名が利用許可証配布サーバ６で指定されたドメインの範囲に含まれるか否かを検査し、含まれる場合のみWebアプリに対して利用許可証の利用を許可する処理を行う。たとえば、情報操作装置１が利用許可証をCookieとして保存する際、利用許可証配布サーバ６がexample.foo.bar.comとして利用範囲(ドメイン)を指定した場合、利用許可証を利用するWebアプリのドメイン名はexample.foo.bar.comやa.example.foo.bar.comなど、example.foo.bar.comを含むドメインでなければならない。仮にWebアプリのドメインがfoo.foo.bar.comだった場合、そのドメインは利用許可証配布サーバ６が指定したドメインに含まれないため、利用許可証アクセス制御部２３はそのWebアプリから利用許可証の利用要求があったとしても、利用許可証を返さないように制限する。
なお、Webアプリのドメイン名が利用許可証配布サーバ６が指定したドメインの範囲外で、Webアプリから利用許可証蓄積部２４内に蓄積された利用許可証の利用要求があった場合には、何も返さないか、エラーを返す処理を行う。
利用許可証送信部２５は、Webアプリからの指示に基づいて利用許可証蓄積部２４に蓄積された利用許可証をWebsocketクライアント処理部１８に送信する処理を行う。
図４は第１の実施形態に係る情報出力装置２の内部構成を示すブロック図である。図４の情報出力装置２は、HTTP処理部３１と、チューナ部３２、画面出力部３３、機器操作命令処理部３４、リモコン命令処理部３５、固有ID管理部３６、ID登録要求送信部３７、ＭＡＣ鍵管理部５６、公開鍵管理部３８、PIN管理部３９、Websocketサーバ処理部４０、機器検索処理部４１、利用許可証検査部４２、およびアプリ出所検査部４３を有する。
HTTP処理部３１は、Webサーバ(HTTPサーバ)との間で、HTTP(Hypertext Transfer Protocol)もしくはHTTPS(Hypertext Transfer Protocol over Secure Socket Layer)のプロトコルで通信し、後述するID登録要求を送信したり公開鍵を受信したりするのに必要なHTTPクライアント処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。
チューナ部３２は、アンテナ等から受信した放送波から、特定の放送番組や放送関連情報を抽出し、デコード処理を行う。
画面出力部３３は、チューナ部３２から出力された動画データや音声データを不図示の内部液晶モニターや外部出力インタフェースに出力する。外部出力インタフェースとは、例えばHDMI（High-Definition Multimedia Interface）やコンポジット、S-Video、コンポーネントのようなインタフェースのことを指す。
機器操作命令処理部３４は、情報操作装置１や赤外線リモコンから受信した機器操作命令を処理し、チューナ部３２を制御したり、画面出力部３３に表示する映像等を切り替える指示を送ったりする。
リモコン命令処理部３５は、不図示の赤外線リモコンから受信した命令を処理し、機器操作命令処理部３４にその命令を通知する処理を行う。なお、リモコン命令処理部は必須の構成ではない。
固有ID管理部３６は、情報出力装置２に固有のIDを管理する処理を行う。固有IDの生成方法として、情報出力装置２の工場出荷時に一意のIDを書きこむ方法、情報出力装置２の初回起動時に不図示の乱数生成器を用いて乱数を生成して保存する方法、HTTP処理部３１のイーサネット物理アドレス(MACアドレス)を利用する方法、MACアドレスを元に乱数生成する方法、情報出力装置２がユーザの指示に基づき赤外線リモコン命令を経由して固有IDを生成する命令を受信し、不図示の乱数生成器を用いて乱数を生成して保存する方法、それらを組み合わせる方法などがあり、いずれを採用してもよい。
ID登録要求送信部３７は、利用許可証配布サーバ６とHTTPのプロトコルで通信し、利用許可証配布サーバ６に対して公開鍵を要求するメッセージに固有ID管理部３６で管理する固有IDを添付して登録要求として送信し、その応答として利用許可証配布サーバ６から公開鍵を受信する処理を行う。
ＭＡＣ鍵管理部５６は、利用許可証配布サーバ６と共有する共通鍵を管理し、その鍵を用いてメッセージ認証コード(Message Authentication Code:MAC)を生成する処理を行う。なお、ＭＡＣ鍵管理部５６は必須の構成ではない。
公開鍵管理部３８は、利用許可証配布サーバ６から受信した公開鍵を保存して管理する処理を行う。
PIN管理部３９はパスワード(暗証コード、より具体的にはPINコード、以下PINと省略して表記する)を管理する処理を行う。PINの生成方法として、情報出力装置２の工場出荷時にPINの値を書きこむ方法、情報出力装置２が不図示の乱数生成器を用いて乱数を生成し、その乱数をPINの値とする方法、情報出力装置２がユーザの指示に基づき赤外線リモコン命令を経由してPINを生成する命令を受信し、不図示の乱数生成器を用いて乱数を生成してPINの値とする方法、情報出力装置２がユーザの指示に基づき赤外線リモコン命令を経由して文字列データや数字列データを受信し、その受信したデータをPINの値とする方法、HTTP処理部のMACアドレスを元に乱数生成する方法、それらを組み合わせる方法などがあり、いずれを採用してもよい。
Websocketサーバ処理部４０は、RFC6455規格で定められたWebsocketと呼ばれるプロトコルに従って情報操作装置１と通信を行うためのサーバ処理を行う。機器操作命令送信部１９や利用許可証など情報操作装置１から送信されるデータを受信し、利用許可証検査部４２やアプリ出所検査部４３、機器操作命令処理部３４にデータを振り分ける処理を行う。
機器検索処理部４１は、後述する情報操作装置１からの装置検索要求に応答して自装置の名前やIPアドレス、Websocketサーバ処理部４０のTCPポート番号を返信する処理を行う。装置検索のプロトコルとして、DLNA (Digital Living Network Alliance)規格や、UPnP (Universal Plug and Play)規格で定められた方式、あるいはNetBIOS (Network Basic Input Output System)による名前検索方式を用いてもよい。このように、機器検索処理部４１は、情報操作装置１からの装置検索要求に応答して、自装置の名前やIPアドレス等を返信するためのネットワークセッション確立処理を行うコネクション部を有する。なお、この機器検索処理部４１は必須の構成ではない。
利用許可証検査部４２は、情報操作装置１から送信されてWebsocketサーバ処理部４０で受信した利用許可証が正しいかどうかの検査処理を行い、その結果を機器操作命令処理部３４に通知する。利用許可証検査部４２の検査処理の詳細は後述する。
アプリ出所検査部４３は、情報操作装置１から送信されてWebsocketサーバ処理部４０で受信した機器操作命令に含まれるヘッダ情報が正しいかどうかの検査処理を行い、その結果を機器操作命令処理部３４に通知する。アプリ出所検査部４３の検査処理の詳細は後述する。
図５は第１の実施形態に係るWebアプリ配布サーバ４の内部構成を示すブロック図である。Webアプリ配布サーバ４は、情報操作装置１とHTTPまたはHTTPSのプロトコルで通信し、情報操作装置１からの要求に従ってWebアプリを配布する。図５のWebアプリ配布サーバ４は、HTTPサーバ処理部５１、Webアプリ蓄積部５２、Webアプリ登録処理部５３、およびWebアプリ配布部５４を有する。
HTTPサーバ処理部５１は、情報操作装置１とHTTPもしくはHTTPSのプロトコルで通信し、Webアプリの取得要求やWebアプリの配布処理に必要なHTTPサーバ処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。
Webアプリ蓄積部５２は、Webアプリを蓄積する処理を行う。Webアプリは固有のID(WebアプリID)が付与されて蓄積される。
Webアプリ登録処理部５３は、WebアプリをWebアプリ蓄積部５２に蓄積する処理を行う。図５ではHTTPサーバ処理部５１を介してネットワーク経由でWebアプリを蓄積する構成について示したが、必ずしもネットワーク経由で蓄積する必要はなく、USBメモリなど外部メモリを経由してWebアプリを蓄積してもよい。なお、このWebアプリ登録処理部５３は必須の構成ではない。
Webアプリ配布部５４は、情報操作装置１からアプリに固有のIDを指定してWebアプリを送信するようネットワークを経由して指示を受けると、Webアプリ蓄積部５２に蓄積されたWebアプリの中から指定されたIDに対応するWebアプリを検索し、そのWebアプリに属する各種リソースをHTTPサーバ処理部５１を経由して情報操作装置１に送信する処理を行う。なお、アプリに固有のIDはURLでもよい。
なお、Webアプリ配布サーバ４は複数のWebアプリを配布してもよいが、その場合にはWebアプリ配布サーバ４の同一ドメインの中に複数のWebアプリを格納してもよいし、Webアプリごとに異なるドメインとなるようにWebアプリを格納してもよい。同一ドメインの中に複数のWebアプリを格納する場合とは、例えば、WebアプリXとWebアプリYをdomain1.example-Webserver.comで示すドメインに格納するようにする事を示す。具体的な例としては、WebアプリXを取得するためのURLをhttp://domain1.example-Webserver.com/appidX/などとし、WebアプリYを取得するためのURLをhttp://domain1.example-Webserver.com/appidY/などとするような場合を指す。
このほかに、WebアプリXを取得するためのURLをhttp://domain1.example-Webserver.com/appid=Xなどとし、WebアプリYを取得するためのURLをhttp://domain1.example-Webserver.com/appid=Yなどとしてもよい。
Webアプリごとに異なるドメインとなるようにWebアプリを格納する場合とは、WebアプリXのURLをhttp://appX. example-Webserver.comで示すURLに格納し、WebアプリYをhttp://appY. example-Webserver.comで示すURLに格納するといったようにドメインを分けて格納する事を示す。なお、この実施形態では同一ドメインの中に複数のWebアプリを格納する例について説明する。
図６は第１の実施形態に係るPFアプリ配布サーバ５の内部構成を示すブロック図である。PFアプリ配布サーバ５は、情報操作装置１とHTTPまたはHTTPSのプロトコルで通信し、情報操作装置１からの要求に基づいてPFアプリを配布する処理を行う。図６のPFアプリ配布サーバ５は、HTTPサーバ処理部６１、PFアプリ蓄積部６２、PFアプリ登録処理部６３およびPFアプリ配布部６４を有する。
HTTPサーバ処理部６１は、Webアプリ配布サーバ４のHTTPサーバ処理部５１と同等の処理を行う。
PFアプリ蓄積部６２は、PFアプリを蓄積する処理を行う。PFアプリは固有のIDが付与されて蓄積される。なお、Webアプリは上述したように静止画データやテキストデータなど複数のリソース（ファイル）で構成されることが一般的だが、PFアプリはそれらリソースを一つのファイルに圧縮して配布する。従って、PFアプリは固有のIDにつき一つのPFアプリファイルとして提供される。
PFアプリ登録処理部６３は、PFアプリをPFアプリ蓄積部６２に蓄積（登録）する処理を行う。図６ではHTTPサーバ処理部６１を介してネットワーク経由でPFアプリを登録する構成について示したが、必ずしもネットワーク経由で登録する必要はなく、USBメモリなど外部メモリを経由してWebアプリを登録してもよい。なお、このPFアプリ登録処理部６３は必須の構成ではない。
PFアプリ配布部６４は、情報操作装置１からアプリに固有のIDを指定してPFアプリを送信するようネットワークを経由して指示を受けると、PFアプリ蓄積部６２に蓄積されたPFアプリの中から指定されたIDに該当するPFアプリを検索し、そのPFアプリに該当するファイルをHTTPサーバ処理部６１を経由して情報操作装置１に送信する処理を行う。
図７Ａは第１の実施形態に係る利用許可証配布サーバ６の内部構成を示すブロック図である。利用許可証配布サーバ６は、情報操作装置１および情報出力装置２とHTTPまたはHTTPSのプロトコルで通信し、情報操作装置１に利用許可証を配布したり、情報出力装置２に公開鍵を配布したりする処理を行う。図７Ａの利用許可証配布サーバ６は、HTTPサーバ処理部７１、情報出力装置情報蓄積部７２、情報出力装置固有ID登録部７３、鍵ペア生成部７４、鍵ペア送信部７５、情報出力装置登録受付処理部７６、Webアプリ情報蓄積部７７、利用許可証登録受付処理部７８、利用許可証生成部７９、および利用許可証要求受付処理部８０を有する。
HTTPサーバ処理部７１は、情報操作装置１とHTTPもしくはHTTPSのプロトコルで通信し、利用許可証の取得要求や利用許可証の配布処理に必要なHTTPサーバ処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。HTTPサーバ処理部７１はまた、情報出力装置２とHTTPもしくはHTTPSのプロトコルで通信し、情報出力装置２から送信される登録要求メッセージを受信したり、その応答として公開鍵を配布したりする処理に必要なHTTPサーバ処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。また、受信したメッセージが情報出力装置２からの登録要求メッセージであれば、情報出力装置登録受付処理部７６にメッセージの内容を渡し、情報操作装置１からの利用許可証生成要求であれば利用許可証要求受付処理部８０にメッセージの内容を渡し、利用許可証の登録要求であれば利用許可証登録受付処理部７８にメッセージの内容を渡す処理も行う。
情報出力装置情報蓄積部７２は、情報出力装置２の固有IDとそれに対応する公開鍵ペアを蓄積および管理する処理を行う。
情報出力装置固有ID登録部７３は、画面生成装置から送信される登録要求メッセージに含まれる情報出力装置２の固有IDを情報出力装置情報蓄積部７２に蓄積する処理を行う。
鍵ペア生成部７４は、情報出力装置固有ID登録部７３が情報出力装置情報蓄積部７２に情報出力装置２の固有IDを登録する際、公開鍵ペアを生成して情報出力装置２の固有IDとセットにして情報出力装置情報蓄積部７２に登録する処理を行う。公開鍵のアルゴリズムとしてはRSA暗号や楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。なお、ここで生成した公開鍵ペアのうち、公開鍵は情報出力装置２に送信され、秘密鍵は利用許可証配布サーバ６が管理して利用許可証の署名を生成する際に用いられる。
鍵ペア送信部７５は、登録要求メッセージの応答として、鍵ペア生成部７４が生成した公開鍵、もしくは情報出力装置情報蓄積部７２に登録された公開鍵を取得する処理を行う。登録要求メッセージに含まれる固有IDに対応する公開鍵がまだ情報出力装置情報蓄積部７２に登録されていない場合は鍵ペア生成部７４から公開鍵を取得し、既に情報出力装置情報蓄積部７２に登録されている場合は情報出力装置情報蓄積部７２から公開鍵を取得する。
なお、鍵ペア生成部７４は、鍵ペアを生成したら必ず情報出力装置情報蓄積部７２に登録し、鍵ペア送信部７５は情報出力装置情報蓄積部７２から公開鍵を取得してもよい。
また、情報出力装置２に公開鍵を送信する際、情報出力装置２と利用許可証配布サーバ６との間の通信経路上で公開鍵の値が改ざんされることを防止するために、利用許可証配布サーバ６はメッセージ認証コード秘密鍵(Message Authentication Code秘密鍵、以下MAC鍵と略して表記する)を生成して、公開鍵にMAC鍵を使って作成したメッセージ認証コードを添付してもよい。なお、メッセージ認証コードの生成アルゴリズムとしてはHMAC-MD5, HMAC-SHA1など良く知られたアルゴリズムを用いればよい。このMAC鍵は情報出力装置２とMAC鍵管理部５６に蓄積された鍵と同じ値である。なお、利用許可証配布サーバ６は情報出力装置２毎にMAC鍵を管理してもよいし、複数の情報出力装置２で同一のMAC鍵を管理しても良い。
情報出力装置登録受付処理部７６は、情報出力装置２から送信された登録要求メッセージを受信し、その応答として登録要求メッセージに含まれる固有IDに対応する公開鍵を情報出力装置２に送信する処理を行う。
なお、既に情報出力装置情報蓄積部７２に登録されている情報出力装置２から登録要求メッセージが来た場合、鍵ペア生成部７４にて新しい鍵ペアを生成して情報出力装置情報蓄積部７２に登録してもよいし、新しい鍵ペアを生成せず情報出力装置情報蓄積部７２に蓄積されている固有IDに対応する公開鍵を送信してもよい。
Webアプリ情報蓄積部７７は、各Webアプリ、すなわちWebアプリIDに対応した利用許可証を蓄積する処理を行う。利用許可証登録受付処理部７８からWebアプリIDに対応したドメイン名も受信し、WebアプリIDとペアにして蓄積する。すなわち、Webアプリ情報蓄積部７７はWebアプリの固有ID、Webアプリのドメイン名のペアが蓄積される。利用許可証やドメイン名については後述する。
利用許可証登録受付処理部７８は、利用許可証を登録する処理を行う。図７ＡではHTTPサーバ処理部７１を介してネットワーク経由で利用許可証を登録する構成を示すが、必ずしもネットワーク経由で登録する必要はなく、USBメモリなど外部メモリを経由してWebアプリを登録してもよい。なお、この利用許可証登録処理部は必須の構成ではない。なお、この登録した状態では利用許可証に署名は付与されていない。
利用許可証生成部７９は、利用許可証要求メッセージに含まれるWebアプリに固有のIDに対応する利用許可証をWebアプリ情報蓄積部７７から取得し、利用許可証、WebアプリID、利用許可証要求メッセージに含まれるPINに対して秘密鍵管理部に格納した秘密鍵を使って署名を施し、署名付き利用許可証を生成する処理を行う。なお、署名のほかにオプションとして署名方式を付与してもよい。
利用許可証要求受付処理部８０は、情報操作装置１から送信された利用許可証要求メッセージを受信し、その応答として署名付き利用許可証を情報操作装置１に送信する処理を行う。
なお、図１では、Webアプリ配布サーバ４、PFアプリ配布サーバ５、および利用許可証配布サーバ６を別々の装置として図示したが、これら三つのサーバをまとめて一つの装置で実現してもよい。すなわち、これら３つのサーバのうち任意の２つ以上を１つの装置にまとめてもよい。
図７Ｂは利用許可証配布サーバ６に図５に示したWebアプリ配布サーバ４の機能を持たせた場合の内部構成を示すブロック図である。図７Ａとの違いはWebアプリ蓄積部５２とWebアプリ配布部５４を新たに備えている点である。Webアプリ蓄積部５２は図５に示したWebアプリ配布サーバ４内のWebアプリ蓄積部５２と同一の機能を持っていればよい。Webアプリ配布部５４は図５に示したWebアプリ配布部５４の機能に加えて、Webアプリの取得要求メッセージの中に情報出力装置２の固有IDが含まれている場合、情報出力装置情報蓄積部７２の中に、その固有IDを持つ情報出力装置２に関する情報が登録されているかどうかを確認し、含まれている場合に限り要求されたWebアプリの配布を行う機能を有する。このようにする事で、利用許可証配布サーバ６に未登録の固有IDを持つ情報出力装置２の固有IDを付けてWebアプリの取得要求メッセージを送信するような不正な装置からWebアプリを配信する事を防止できる。
図８は第１の実施形態における情報操作装置１、情報出力装置２、利用許可証配布サーバ６、PFアプリ配布サーバ５、およびWebアプリ配布サーバ４の処理手順を示すフローチャートである。図８に示すように、処理シーケンスは大きく分けて、情報出力装置セットアップフェーズ（ステップＳ１）、情報操作装置セットアップフェーズ（ステップＳ２）、情報出力装置操作フェーズ（ステップＳ３〜Ｓ６）の3つのフェーズを有する。まずここでは全体処理シーケンスを示し、各フェーズの詳細な処理シーケンスに関しては後述する。
情報出力装置セットアップフェーズでは、情報出力装置２が利用許可証配布サーバ６と通信し、情報出力装置２を利用許可証配布サーバ６に登録する処理を行う。
情報操作装置セットアップフェーズでは、情報操作装置１がPFアプリ配布サーバ５と通信し、情報操作装置１がPFアプリをPFアプリ配布サーバ５からダウンロードして情報操作装置１にインストールする処理を行う。
情報出力装置操作フェーズは、レベル１（ステップＳ３，Ｓ４）とレベル２（ステップＳ５，Ｓ６）の二つのフェーズに分かれている。レベル１では、情報操作装置１がWebアプリ配布サーバ４と通信し、情報操作装置１がWebアプリをWebアプリ配布サーバ４からダウンロードする処理（ステップＳ３）と、情報操作装置１が利用許可証配布サーバ６から利用許可証をダウンロードする処理（ステップＳ４）とを行う。
なお、情報操作装置１上でWebアプリをダウンロードして実行する処理のトリガーは、情報操作装置セットアップフェーズにてインストールしておいたPFアプリが行う。
レベル２では、情報操作装置１が情報出力装置２と通信し（ステップＳ５）、情報操作装置１から情報出力装置２に機器操作命令を送信して情報出力装置２を制御する処理を行う（ステップＳ６）。
図９は第１の実施形態における情報出力装置セットアップフェーズの情報出力装置２と利用許可証配布サーバ６の処理手順を示すシーケンス図である。
まず情報出力装置２は、利用許可証配布サーバ６のＵＲＬを取得し（ステップＳ１１）、取得したＵＲＬにHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでアクセスして、利用許可証配布サーバ６に対して、固有ID管理部３６で管理する情報出力装置２の固有IDを添付して、情報出力装置２の固有IDの登録要求を送信する（ステップＳ１２）。このメッセージはHTTP GETリクエストとして送信すればよい。以下にメッセージの一例を示す。
http://example-CAserver.com/register.php?device_id=xxxx
このメッセージでは、利用許可証配布サーバ６のサーバ名を"example-CAserver.com"、情報出力装置２の固有IDをdevice_idでラベル付けされた値"xxxx"として、利用許可証配布サーバ６に送信している。利用許可証配布サーバ６のＵＲＬは、情報出力装置２の工場出荷時に情報出力装置２内に登録しておいてもよいし、赤外線リモコンを利用してユーザにURLを入力させてもよいし、情報出力装置２がアクセスするトップページからリンク情報として利用許可証配布サーバ６のURLにたどれるようにWebページを構成してもよい。
なお、登録要求メッセージの中でも固有IDが情報出力装置２と利用許可証配布サーバ６との間の通信経路上で改ざんされないようにするために、MAC鍵管理部５６で情報出力装置２に利用許可証配布サーバ６と共有する共通鍵を管理し、その鍵を用いてメッセージ認証コードを生成してもよい。情報出力装置２が生成するメッセージ認証コードの計算方法の一例を以下に示す。
signature = keyed_hash (key、device_id)
ここで、keyは利用許可証配布サーバ６と共有する共通鍵を示し、device_idは情報出力装置２の固有IDを示し、keyを鍵としてdevice_idをkeyed_hashアルゴリズムを使って計算した値がSignatureである事を示す。keyed_hashアルゴリズムとしてHMAC-SHA1アルゴリズムやHMAC-MD5、HMAC-SHA256などを利用すればよい。
情報出力装置２がメッセージ認証コードを添付して利用許可証配布サーバ６に送信する登録要求メッセージの一例を以下に示す。
http://example-CAserver.com/register.php?device_id=xxxx&signature=yyyy&signature_method=hmac-sha1
この例では、signatureでラベル付けされた値"yyyy"をメッセージ認証コードとしてURLに付与し、さらに利用許可証配布サーバ６に対してメッセージ認証コードの生成アルゴリズムを通知している。なお、ここではsignature_methodでラベル付けされた値"hmac-sha1"にてHMAC-SHA1アルゴリズムを利用してメッセージ認証コードを情報出力装置２が生成する例を示している。
次に、利用許可証配布サーバ６が登録要求を受信すると、情報出力装置登録受付処理部７６は登録要求メッセージに含まれる固有IDを取り出し、その固有IDに対応する公開鍵ペアが情報出力装置情報蓄積部７２に登録されているかどうかを検査する（ステップＳ１３）。
もし既に登録されている場合は、この登録要求は二度目以降の要求であると判断して情報出力装置情報蓄積部７２から公開鍵を取得し（ステップＳ１４）、情報出力装置２に公開鍵を含めて応答メッセージを送信する（ステップＳ１５、Ｓ１６）。
もしまだ登録されていない場合、利用許可証配布サーバ６は、その固有IDを持つ情報出力装置２から初めての登録要求であると判断して公開鍵ペアを生成し（ステップＳ１７）、情報出力装置情報蓄積部７２の中に公開鍵ペアと固有IDをセットにして登録し（ステップＳ１８）、生成した公開鍵ペアのうち公開鍵の方だけを含めて応答メッセージを送信する（ステップＳ１５、Ｓ１６）。
この時のHTTP GETリクエストに対するレスポンスメッセージボディの一例を以下に示す。
pubkey=xyxyxy
上述した例では、pubkeyでラベル付けされた値"xyxyxy"を公開鍵として送信している。なお、通信経路上でのメッセージ改変を防止するために、登録要求メッセージ同様、メッセージ認証コードを付与してもよい。その場合の登録要求メッセージに対する応答メッセージの一例を以下に示す。
pubkey=xyxyxy&signature=zyzyzy&signature_method=hmac-sha1
上述した例では、signatureでラベル付けされた値"zyzyzy"は、利用許可証配布サーバ６が情報出力装置２と共有する共通鍵にてHMAC-SHA1アルゴリズムを利用して生成したメッセージ認証コードである。
情報出力装置２は公開鍵を受信すると公開鍵管理部３８に保存する（ステップＳ１９）。この公開鍵は情報出力装置操作フェーズにて用いる。
図１０は第１の実施形態における情報操作装置セットアップフェーズの情報操作装置１とPFアプリ配布サーバ５の処理手順を示すシーケンス図である。
なお、情報操作装置１に情報出力装置２操作用のPFアプリがプリインストールされている場合は図１０に示したシーケンスを実行する必要はない。
まず情報操作装置１はPFアプリ配布サーバ５からPFアプリの一覧を取得する（ステップＳ２１）。その時の情報操作装置１の画面出力部１７の画面に出力されるPFアプリの一覧の表示例を図１１に示す。このアプリ一覧は、例えばWebコンテンツとしてWebアプリ実行部２２で画面を生成すればよい。その場合のWebコンテンツは予め機器出荷時に設定されたURLを元にPFアプリ配布サーバ５から、一覧を表示させるWebコンテンツを取得するようにすればよい。
図１１に示す例では、PFアプリの一覧をアイコンとして表示し、そのアイコンの下に簡単な説明を記述している。情報操作装置１のユーザは、マウスやタッチパッド等を利用して入力受信部１５からPFアプリを選択する（ステップＳ２２）。図１１の例では、PFアプリAが情報出力装置２操作用のPFアプリであるため、このPFアプリが選択されたと仮定する。するとPFアプリAに関連づけられたアプリ固有IDを含むPFアプリ送信要求(URL)が情報操作装置１からPFアプリ配布サーバ５に送信される（ステップＳ２３）。情報操作装置１はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでPFアプリ送信要求をPFアプリ配布サーバ５に送信する。
PFアプリ配布サーバ５は、PFアプリ蓄積部６２に蓄積されたPFアプリ群の中から、情報操作装置１によって指定されたアプリ固有IDを持つPFアプリを検索して取得し（ステップＳ２４）、取得したPFアプリをアプリ送信要求に対する応答としてPFアプリ配布部６４は情報操作装置１に送信する（ステップＳ２５）。
情報操作装置１は、PFアプリ取得部２６を利用して、PFアプリAをPFアプリ配布サーバ５から受信してダウンロードし（ステップＳ２６）、PFアプリAをインストールする（ステップＳ２７）。インストールされたPFアプリAはアプリ蓄積部３０に保存される。
図１２は第１の実施形態におけるPFアプリの構造を示す図である。PFアプリは、PFアプリ初期化命令８１、ローカルWebアプリ#1 ８２、WebアプリURL８３、Webアプリ実行部呼び出し命令８４、およびリソース８５を有する。
PFアプリ初期化命令８１は、初期化処理などPFアプリをPFアプリ実行部２１で実行させる際に最初に実行する汎用の処理と、Webアプリ実行部呼び出し命令８４を呼び出す処理を行うプログラムである。
ローカルWebアプリ#1 ８２は、利用許可証が情報操作装置１の利用許可証蓄積部２４に保存されているかどうかを検査する。このローカルWebアプリ#1 ８２はHTML4/5またはJavaScriptによって記述されており、情報操作装置１のWebアプリ実行部２２(ブラウザ)で実行される。ローカルWebアプリはPFアプリのパッケージ内に含めても良いし、Webアプリ配布サーバ４に置き、アプリ取得部１２を使ってネットワーク経由で取得するようにしてもよい。ネットワーク経由で取得する場合、ローカルWebアプリはPFアプリには含まれない。
WebアプリURL８３はWebアプリ#0の場所を示すURLである。WebアプリがPFアプリのパッケージ内に含めて配布される場合は情報操作装置１内のローカルWebアプリが保存されたロケーションを示し、Webアプリ配布サーバ４に置かれている場合は、Webアプリ配布サーバ４のローカルWebアプリが置かれているロケーションを示す。以下では、まずWebアプリがPFアプリのパッケージ内に含めて配布される場合について説明する。
Webアプリ実行部呼び出し命令８４はWebアプリURL８３を引数としてWebアプリ実行部２２を起動するプログラムである。すなわち、WebアプリURL８３で示すWebアプリがWebアプリ実行部２２で実行されることになる。
リソース８５は、情報操作装置１にインストールされたPFアプリ一覧を表示させる際のPFアプリのアイコン(静止画データ)や説明文、バージョン番号などである。
図１３は第１の実施形態における情報出力装置操作フェーズ(レベル1)の情報操作装置１、Webアプリ配布サーバ４、および利用許可証配布サーバ６の処理手順を示すシーケンス図である。
まず情報操作装置１はPFアプリ実行部２１でPFアプリを実行する（ステップＳ３１）。PFアプリ実行のトリガーは入力受信部１５によるPFアプリ選択によって行われる。PFアプリはPFアプリ初期化命令８１で初期化処理等を実行した後、Webアプリ実行部呼び出し命令８４を実行する。Webアプリ実行部呼び出し命令８４はWebアプリURL８３で指定され、PFアプリに含まれるローカルWebアプリ(Webアプリ#1)をWebアプリ実行部２２で実行する（ステップＳ３２）。以降の処理はWebアプリ実行部２２でなされる。
次に、情報操作装置１はローカルWebアプリ(Webアプリ#1)を実行する。上述のようにWebアプリ#1は利用許可証が情報操作装置１の利用許可証蓄積部２４に保存されているかどうかを検査する（ステップＳ３３）。Webアプリ#1は利用許可証蓄積部２４に利用許可証が保存されていないと判断した場合には、ローカルWebアプリ#1 ８２内に記述されたWebアプリ#2のURLを参照して（ステップＳ３４）、そのURLが示すWebアプリ(Webアプリ#2)をWebアプリ配布サーバ４から取得して実行させる（ステップＳ３５，Ｓ３６）。具体的には情報操作装置１はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでWebアプリ送信要求をWebアプリ配布サーバ４に送信し、Webアプリ(Webアプリ#2)をWebアプリ配布サーバ４から取得して実行させる。
この例ではWebアプリ#2の保存先はWebアプリ配布サーバ４としているため、情報操作装置１はWebアプリ配布サーバ４からWebアプリ#2を取得し（ステップＳ３７）、Webアプリ実行部２２で実行する（ステップＳ３８）。
もし、利用許可証が利用許可証蓄積部２４に保存されていると判断した場合には、ローカルWebアプリ#1 ８２内に記述されたWebアプリ#4のURLを参照して、そのURLが示すWebアプリ(Webアプリ#4)を実行させる。
なお、Webアプリ#1が利用許可証が蓄積されているかどうかを検査する処理の前に、情報操作装置１の機器検索処理部２０を利用して、これから操作する対象となる情報出力装置２を検索し、検索された情報出力装置２に固有のIDを取得してもよい。
図１４は、機器検索処理部２０で検索した結果、情報操作装置１の画面出力部１７の画面に取得した情報出力装置２の一覧をアイコンとして表示する例を示している。情報操作装置１のユーザはマウスやタッチパッドを利用して入力受信部１５から情報出力装置２を選択する。ここでは、情報出力装置２Aを選択したとする。
次に、Webアプリ#2について説明する。Webアプリ#2は、情報操作装置１の入力受信部１５からPINを入力させるユーザインタフェースを提供し、利用許可証配布サーバ６に送信する処理を行うWebアプリである（PIN入力用Webアプリ）。情報操作装置１がWebアプリ#2を取得するために、ステップＳ３５でWebアプリ配布サーバ４に送信するURLの例を以下に示す。
http://example-Webserver.com/input_pin.php?appid=X
この例では、Webアプリ配布サーバ４"example-Webserver.com"に対して、Webアプリの固有ID"X"を指定してWebアプリ取得要求を送信している。
また、別のURLの例を以下に示す。
http:// example-Webserver.com/appidX/
なお、ここでは、WebアプリごとにPIN入力ユーザインタフェースを異なるようにする例を示したが、複数のWebアプリで同一のPIN入力ユーザインタフェースを提供してもよい。また、Webアプリ#2の取得を要求する際、上述の情報出力装置２に固有のIDを添付してもよい。後述するように、この後、情報操作装置１は利用許可証配布サーバ６に対して利用許可証を要求するメッセージを送信するが、そのメッセージの中で情報出力装置２に固有のIDが必要になる。Webアプリ#2の取得を要求する際に、情報出力装置２に固有のIDをWebアプリ配布サーバ４に送信し、Webアプリ配布サーバ４がWebアプリ#2の中に固有IDを含めて返信することで、その固有IDを利用許可証を要求するメッセージで再利用する事ができるため、情報操作装置１が情報出力装置２に固有のIDを記憶しておく必要がないという利点がある。
Webアプリ#2を取得する目的でWebアプリ配布サーバ４に送信するURLに、情報出力装置２の固有IDを添付するURLの例を以下に示す。
http://example-Webserver.com/input_pin.php?device_id=xxxx&appid=X
図７Ｂに示すように、利用許可証配布サーバ６にWebアプリ配布サーバ４の機能を持たせる場合、Webアプリ配布サーバ４は情報出力装置２に固有のIDを受信し、その固有IDが情報出力装置情報蓄積部７２に登録されているか否かを判断し、登録されている場合に限り、Webアプリ#2を配布するようにしてもよい。これにより、不正なWebアプリからのWebアプリ#2（PIN入力用Webアプリ）の取得要求を拒否する事ができる。
次に、Webアプリ#2は、図１５に示すように、情報出力装置２のPINの入力を促すメッセージを情報操作装置１の画面出力部１７の画面に表示させる（ステップＳ３９）。入力受信部１５から情報出力装置２のPINが入力されると、Webアプリ#2は利用許可証の要求メッセージを生成し（ステップＳ４０）、利用許可証配布サーバ６に送信する（ステップＳ４１）。情報操作装置１はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルで利用許可証の要求メッセージを利用許可証配布サーバ６に送信する。情報操作装置１が利用許可証配布サーバ６に送信する利用許可証の要求メッセージの一例を以下に示す。
https://example-CAserver.com/req_token.php?device_id=xxxx&appid=X&pin=ZZZZ
この例では、利用許可証配布サーバ６” example-CAserver.com”に対して、device_idでラベル付けされた値"xxxx"で情報出力装置２に固有のIDを指定し、appidでラベル付けされた値"X"でWebアプリの固有IDを指定し、pinでラベル付けされた値"ZZZZ"で入力受信部１５から入力された値を指定している。
利用許可証配布サーバ６は、情報操作装置１から利用許可証要求メッセージを受信すると、情報出力装置情報蓄積部７２とWebアプリ情報蓄積部７７に蓄積されたデータを用いて、利用許可証生成部７９で利用許可証を生成する（ステップＳ４２）。
図１６は利用許可証のフォーマットの一例を示す図である。利用許可証は、必須のフィールドとして、Webアプリ固有ID９１、Webアプリの出所（ドメイン名）９２、および署名９３を有する。Webアプリ固有ID９１は、情報操作装置１から送信された利用許可証要求メッセージに含まれていた値である。Webアプリの出所９２は、後述する機器操作命令を情報出力装置２に送信するWebアプリ(Webアプリ#4)の送信元Webサーバのドメイン名である。
利用許可証配布サーバ６は、利用許可証生成部７９を使い、情報操作装置１から送信された利用許可証要求メッセージに含まれる情報出力装置２の固有IDに対応した秘密鍵を情報出力装置情報蓄積部７２から取得する。さらに情報操作装置１から送信された利用許可証要求メッセージに含まれるWebアプリの固有IDに対応したWebアプリのドメイン名をWebアプリ情報蓄積部７７から取得する。そして、Webアプリの固有ID、Webアプリのドメイン名、情報操作装置１から送信された利用許可証要求メッセージに含まれるPINの値に対して、ハッシュ値を計算し、情報出力装置情報蓄積部７２から取得した秘密鍵を利用して公開鍵暗号方式に従った署名９３を生成する。このハッシュアルゴリズムとしてはMD5やSHA1などよく知られた方式を用い、署名９３生成アルゴリズムとしてはRSAや楕円曲線暗号などよく知られた方式を用いればよい。署名の計算方法の一例を以下に示す。
署名＝rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名 || PIN))
秘密鍵は情報出力装置情報蓄積部７２から取得した情報出力装置２に固有の秘密鍵であり、この値を秘密鍵として署名を計算する。署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名、PINを結合してSHA1アルゴリズムを使って計算した値とする。これらの計算結果からRSAアルゴリズムを使って署名が求められる。ここでは署名計算アルゴリズムとしてRSAを使った例を示したが、このほかにも楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。
なお、オプションの情報として署名９３がどのハッシュ・署名９３アルゴリズムを用いて生成されたものであるかを示すための署名方式９４の情報を添付してもよい。利用許可証配布サーバ６は利用許可証要求メッセージへの応答として、利用許可証とWebアプリ#4のURLを情報操作装置１に送信する（ステップＳ４３）。利用許可証配布サーバ６からWebアプリ#4のURLを情報操作装置１に送信する手段として、HTTPリダイレクト(HTTP redirect)を使っても良い。HTTPリダイレクトの場合、HTTPレスポンスのLocationヘッダの中にURLが含まれる。このURLはWebアプリの固有IDに関連づけられて利用許可証配布サーバ６のWebアプリ情報蓄積部７７に保存されている。情報操作装置１の利用許可証要求のメッセージにはWebアプリの固有IDが含まれているため、利用許可証要求受付処理部８０はこのWebアプリに固有のIDを元にWebアプリ情報蓄積部７７からURLを取得し、Locationヘッダの中に取得したURLを含めればよい。情報操作装置１はHTTPリダイレクトを受信すると、リダイレクト処理部５５でLocationヘッダの中に含まれるURLを取得し、アプリ取得部１２にそのURLで指示されたWebアプリを取得するように指示する。URLには利用許可証の内容が含まれるため、URLで指示されたWebアプリはURLの引数として利用許可証を取得できる。ステップ４１で示したように、利用許可証はWebアプリ#4のURLと共に送信される。すなわち、HTTPリダイレクトを用いる事で、利用許可証がWebアプリ#4以外に入手できないように制限できる点が重要である。
Webアプリ配布サーバ４の説明で述べたように、Webアプリ配布サーバ４は同一ドメインの中に複数のWebアプリを格納する場合がある。この時、WebアプリXとWebアプリYは同一のドメイン名を有するWebアプリ配布サーバ４から配布されることになり、利用許可証に含まれるWebアプリの出所も同じ値となる。
仮にWebアプリYがWebアプリX用の利用許可証を入手し、情報装置操作フェーズ(レベル2)でそのWebアプリX用の利用許可証を使って機器操作命令を情報出力装置２に送信したとしても、WebアプリXとWebアプリYは出所が同一のため、情報出力装置２はその利用許可証を見てWebアプリを判別し、利用許可証に含まれるアプリIDからその利用許可証がWebアプリXから送信されたものだと解釈してしまい、正しく動作しない。従って、WebアプリXとWebアプリYはアプリIDが異なるため、WebアプリYがWebアプリX用の利用許可証を取得して利用する事を防ぐ必要がある。そこで、HTTPリダイレクトを利用して、利用許可証配布サーバ６が、その利用許可証を取得するWebアプリをURLによって指定する事で、利用許可証配付サーバ６は利用許可証が取得可能なWebアプリを制限する事ができる。つまり、WebアプリX用の利用許可証を情報操作装置１に送信する際、HTTPリダイレクトでWebアプリXのURLを指定しておけば、WebアプリX用の利用許可証を取得できるのはWebアプリXに限定することができる。言い換えると、HTTPリダイレクトによって利用許可証配布サーバ６が指定したWebアプリ以外のWebアプリに利用許可証が渡る事を防止することができる。これによりWebアプリYはWebアプリXの利用許可証を取得する事を防止でき、上述のように情報出力装置２がWebアプリを混同する事も避けられる。
情報操作装置１は、利用許可証を利用許可証蓄積部２４に保存し、Webアプリ実行部２２にてWebアプリ#4を実行する（ステップＳ４４）。
以上では、PFアプリ配布サーバ５が配布するPFアプリにローカルWebアプリを含める形態について説明したが、PFアプリ配布サーバ５が配布するPFアプリにWebアプリを含めない形態も可能である。図１７はローカルWebアプリを含めない場合のPFアプリの構成を示すブロック図である。図１２との違いはローカルWebアプリ#1 ８２がない点と、WebアプリURL８３の値が異なる点である。
図１８はPFアプリにローカルWebアプリが含まれない場合における情報出力装置操作フェーズの情報操作装置１、Webアプリ配布サーバ４、利用許可証配布サーバ６の処理手順を示すシーケンス図である。PFアプリを選択して実行する処理（ステップＳ５１）は図１３に示した処理と同様である。PFアプリはPFアプリ初期化命令８１で初期化処理等を実行した後、Webアプリ実行部呼び出し命令８４を実行する。Webアプリ実行部呼び出し命令８４はWebアプリURL８３で指定されたWebアプリ(Webアプリ#3)をWebアプリ実行部２２で実行しようとする。この時、Webアプリ#3はWebサーバ上のURLを示している（ステップＳ５２）。従って、情報操作装置１のWebアプリ取得部２７はURLの情報を元にWebアプリ#3を取得するようネットワーク経由でWebアプリ配布サーバ４に要求する（ステップＳ５３）。具体的には情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでWebアプリ（Webアプリ#3）取得要求をWebアプリ配布サーバ４に送信する。この要求は通常のHTTP GETリクエストで行えばよい。
http://example-Webserver.com/input_pin.php?appid=XX
また、HTTP GETリクエストを使う別のURLの例を以下に示す。
http:// example-Webserver.com/appidXX/
Webアプリ配布サーバ４は応答としてWebアプリ#3を返す（ステップＳ５４、Ｓ５５）。情報操作装置１は取得したWebアプリ#3をWebアプリ実行部２２で実行する（ステップＳ５６）。
以降の処理はWebアプリ実行部２２でなされる。Webアプリ#3の処理内容はWebアプリ#1と同じでよい。すなわち、利用許可証が情報操作装置１の利用許可証蓄積部２４に保存されているかどうかを検査する（ステップＳ５７）。利用許可証蓄積部２４に利用許可証が蓄積されていないと判断した場合には、ローカルWebアプリ#3内に記述されたWebアプリ#2のURLを参照して（ステップＳ５８）、そのURLが示すWebアプリ(Webアプリ#2)をWebサーバから取得して実行させる。もし蓄積されていると判断した場合には、ローカルWebアプリ#3内に記述されたWebアプリ#4のURLを参照して、そのURLが示すWebアプリ(Webアプリ#4)を実行させる。
このように、PFアプリにWebアプリを含めないことで、PFアプリの全体ファイルサイズを削減することができるだけでなく、PFアプリをインストールした後でもPFアプリ実行後に実行されるWebアプリの挙動を変更することができる利点がある。
図１８に示したように、Webアプリ#3はWebアプリ配布サーバ４上に置かれている。Webアプリ#3をPFアプリに含める場合、Webアプリ#3の開発者は情報操作装置セットアップフェーズまでにWebアプリ#3の実装を完了させておく必要がある。一方、Webアプリ#3をPFアプリに含めない場合、情報出力装置操作フェーズ(レベル１)でWebアプリをダウンロードするまではWebアプリ#3の処理内容や画面デザインを確定させておく必要がない。そればかりか、情報出力装置操作フェーズ(レベル１)を実行するタイミングは各ユーザによって異なるため、キャラクターロゴや案内文など、ある期間にWebアプリ#3に表示させる内容と、別な期間にWebアプリ#3に表示させる内容を別々のものにすることができる。その他にも、ユーザごとにWebアプリ#3で表示させる内容を切り替えることができるといった利点もある。
次に、第１の実施形態における情報出力装置操作フェーズ(レベル2)について説明する。図１９はこのフェーズにおける情報操作装置１、Webアプリ配布サーバ４、情報出力装置２の処理手順を示すシーケンス図である。図１９は図１３及び図１８の続きの処理である。
情報操作装置１はWebアプリ#4のURLを取得すると（ステップＳ６１）、Webアプリ配布サーバ４からWebアプリ#4を取得する（ステップＳ６２〜Ｓ６４）。具体的には情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでWebアプリ（Webアプリ#4）取得要求をWebアプリ配布サーバ４に送信する。ステップS61で取得したURLにはWebアプリ#4のURLと共に利用許可証も含まれているため、Webアプリ#4はこのURLに含まれる利用許可証を利用許可証蓄積部２４に保存する（ステップＳ６５）。
その後、Webアプリ#4は情報出力装置２を操作するための画面を生成し、画面出力部１７に表示させる。
図２０はWebアプリ#4が生成し、情報操作装置１の画面出力部１７に出力されるリモコン画面の表示例を示す。情報操作装置１のユーザはマウスやタッチパッドを利用して入力受信部１５からボタンやスクロールバーを操作して情報出力装置２を操作する。
ここで、仮に情報出力装置２に対する機器操作命令としてVolume UPボタン(音量(上)ボタン)を押したとする。Webアプリ実行部２２上で実行されているWebアプリ#4は入力受信部１５から音量(上)命令を受信すると（ステップＳ６６）、利用許可証蓄積部２４に保存しておいた利用許可証を取得する。ここで重要な点は情報操作装置１の利用許可証アクセス制御部２３である。利用許可証アクセス制御部２３は、Webアプリが利用許可証を利用許可証蓄積部２４に保存する際、利用可能なWebアプリの範囲を指定する。Webアプリから利用許可証蓄積部２４内に蓄積された利用許可証の取得要求があった時には、そのWebアプリが範囲内に一致するか否かを検査し、一致する時のみそのWebアプリに利用許可証の利用を許可する処理を行い、許可する場合には利用許可証を送信する処理を行う（ステップＳ６７）。
利用可能なWebアプリの範囲を指定する情報として、WebアプリのURLの範囲を利用する。つまり、Webアプリ#4は利用許可証を利用許可証蓄積部２４に保存する際、URLのドメインの範囲を指定する（ステップＳ６５）。ここではWebアプリ#4は自身のURLのドメインを指定したとする。Webアプリ#4が利用許可証の利用を利用許可証蓄積部２４に要求する際、利用許可証アクセス制御部２３はWebアプリがWebアプリ#4が指定したドメインの範囲と一致するか否かを検査する。この場合は同一のWebアプリ#4であるためWebアプリ#4は利用許可証を取得することができる。
このように、Webアプリが利用許可証の利用を利用許可証蓄積部２４に要求する際、利用許可証アクセス制御部２３は、そのWebアプリを配布したWebアプリ配布サーバ４のドメインがWebアプリ#4が指定した範囲と一致するか否かを検査する。
仮にWebアプリ配布サーバ４とは別のドメイン名を持つWebサーバから送信されてきたWebアプリが利用許可証の利用を要求した場合、Webアプリ#4のドメイン名とそのWebアプリのドメイン名は異なるため、利用許可証アクセス制御部２３は別のWebサーバから送信されてきたWebアプリに利用許可証を渡さない。これにより、利用許可証の利用を、利用許可証を保存したWebアプリに制限する、または特定のWebサーバ(Webアプリ配布サーバ４)から配布されたWebアプリのみ利用許可証を利用できるようにすることが実現でき、不正なWebアプリが利用許可証を取得することを防止できる。
次に、Webアプリ#4は利用許可証送信部２５を使い、Websocketクライアント処理部１８を経由してWebsocketのプロトコルにて利用許可証を情報出力装置２に送信する（ステップＳ６８）。この時、情報操作装置１のWebsocketクライアント処理部１８内のドメイン付与部７０はWebアプリ実行部２２で実行中のWebアプリのドメイン名（出所情報）をWebsocketヘッダに付与する処理を行う。Websocketにて利用許可証を送信する方法として、たとえばJSON (JavaScript Object Notation)を用いればよい。
情報出力装置２は、情報操作装置１から利用許可証を受信すると、利用許可証検査部４２にて(1)利用許可証に含まれる署名９３が正しいか、(2) PIN管理部に蓄積されているPINの値と利用許可証に含まれるPINの値が一致するか検査を行う。さらにアプリ出所検査部４３にて(3)利用許可証に含まれるWebアプリのドメイン名がWebsocketヘッダに含まれるドメイン名と一致するか検査を行い（ステップＳ６９）、その検査結果をWebsocketで情報操作装置１に返信する（ステップＳ７０）。
(1)と(2)の検査に関して、利用許可証検査部４２はPIN管理部３９が予め管理していたPINの値を取得する。そして利用許可証に含まれるWebアプリ固有ID９１とWebアプリのドメイン名にPINの値を加えてハッシュ値を求め、そのハッシュ値に対する署名９３が正当か否かを公開鍵管理部３８に保存されている公開鍵の値を利用して検証する。検証に成功した場合、検査成功と判断する。
(3)の検査に関して、利用許可証にはWebアプリのドメイン名が含まれる。さらに利用許可証を受信したWebsocketコネクションのヘッダにはWebアプリのドメイン名が含まれている。これらのドメイン名が一致もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。
情報操作装置１は、利用許可証を送信した後、Websocketのコネクションで機器操作命令を送信する（ステップＳ７４）が、情報出力装置２の利用許可証検査部４２とアプリ出所検査部４３は(1)〜(3)のすべての検査が成功した場合には機器利用命令を受け入れるよう機器操作命令処理部３４に指示する（ステップＳ７１、Ｓ７２）。(1)〜(3)の検査が一つでも失敗した場合には、Websocketコネクションを切断するか、あるいは機器操作命令処理部３４に対して利用許可証を受信したのと同じWebsocketコネクションで送信されてくる機器操作命令を拒絶するよう指示する（ステップＳ７３）。
機器操作命令処理部３４は、利用許可証検査部４２とアプリ出所検査部４３が許可した時のみ、情報操作装置１からWebsocketで送信された機器操作命令を受け付けて、機器操作命令に従った処理を行う（ステップＳ７４、Ｓ７５）。例えば、機器操作命令が音量(上)ボタンの場合、画面出力部１７に対して出力する音量を上げるように指示する。
なお、これまでの説明では、Webアプリ#2、Webアプリ#3、およびWebアプリ#4を初めてWebアプリ配布サーバ４から取得する場合のシーケンスについて述べてきたが、情報操作装置１がひとたびそれらのWebアプリを取得したならば、Webアプリキャッシュ部１３がWebアプリ蓄積部５２に保存し、次回、それらのWebアプリを取得する場合にはその都度Webサーバから取得するのではなくWebアプリ蓄積部５２に保存されている内容を利用してもよい。このようにする事で、高速にWebアプリの読み込みを行い、機器の反応速度を速める事ができるだけでなく、WebアプリがWebアプリ蓄積部５２に保存されている状態になれば情報操作装置１が情報出力装置２と接続可能な状態にあれば、かりに情報操作装置１がインターネットに接続していなくても情報出力装置２に機器操作命令を送信することができる。
なお、これまでの説明では利用許可証の存在を確認するWebアプリ#3と、機器操作WebアプリであるWebアプリ#4が異なるWebアプリである場合を説明してきたが、Webアプリ#3とWebアプリ#4は同一のWebアプリでもよい。その場合、Webアプリ#4のURLはWebアプリ#3と同一であり、Webアプリ#4を取得する処理（ステップＳ６２〜Ｓ６４）は省略され、Webアプリ#3が利用許可証の保存から機器操作命令の送信までを行う（ステップＳ６５〜ステップＳ７４）。
なお、図３ではWebアプリ実行部２２で実行するWebアプリが情報出力装置２に利用許可証を送信する形態を示したが、PFアプリ実行部２１が利用許可証を送信してもよい。図２１はその場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図である。図３との違いは、Websocketクライアント処理部１８がWebアプリ実行部２２に接続されていない点と、PFアプリ実行部２１に利用許可証送信部２５ａとWebsocketクライアント処理部１８ａを備えている点である。
利用許可証送信部２５ａは、Webアプリ実行部２２のWebアプリから渡された利用許可証を受け取ると共に、利用許可証を渡してきたWebアプリを特定し、そのWebアプリの配布元Webサーバのドメイン名を取得する処理を行う。
Websocketクライアント処理部１８ａは情報出力装置２とWebsocketのプロトコルで通信を行うためのクライアント処理を行う。すなわち図２で示したWebsocketクライアント処理部１８と同等の処理を行う。図２１はWebsocketクライアント処理部１８ａがPFアプリ実行部２１の中で実行される点が特徴である。装置の構成として冗長ではあるが、情報操作装置１はWebsocketのプロトコルで通信を行うためのクライアント処理を行う処理部として、Websocketクライアント処理部１８とWebsocketクライアント処理部１８ａの両方を備えていても良い。
Webアプリは、利用許可証を情報出力装置２に送信するにあたって、まずPFアプリ実行部２１に利用許可証を渡す。この際、情報出力装置２のWebsocketサーバのIPアドレスやTCPポート番号も合わせて渡してもよい。PFアプリ実行部２１は、利用許可証送信部２５ａでWebアプリ実行部２２から渡された利用許可証を受け取ると共に、利用許可証を渡してきたWebアプリを特定し、Webアプリ実行部２２からそのWebアプリの配布元Webサーバのドメイン名を取得する。そしてWebsocketクライアント処理部１８ａを使って情報出力装置２とWebsocketのコネクションを確立し、利用許可証を情報出力装置２に送信する。この際、PFアプリ実行部２１のWebsocketクライアント処理部１８ａ内のドメイン付与部７０ａはWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与して情報出力装置２に送信してもよい。
なお、機器操作命令は機器操作命令送信部１９によってWebsocketクライアント処理部１８ａを介して送信されるが、図１９と同様にWebsocketクライアント処理部１８ａ内のドメイン付与部７０ａはWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行う。
図２２はこの形態における情報出力装置操作フェーズ(レベル2)における情報操作装置１、Webアプリ配布サーバ４、情報出力装置２の処理手順を示すシーケンス図である。図１９との違いは利用許可証の送受信に使うWebsocketコネクション（ステップＳ８８、Ｓ９０）と、機器操作命令の送受信に使うWebsocketコネクション（ステップＳ９４）が別々になっている点である。利用許可証の送受信に使うWebsocketコネクション（ステップＳ８８、Ｓ９０）はWebsocketクライアント処理部１８ａがコネクション確立処理と以降のコネクション管理処理を行い、機器操作命令の送受信に使うWebsocketコネクション（ステップＳ９４）はWebsocketクライアント処理部１８がコネクション確立処理と以降のコネクション管理処理を行う。これらの処理以外は、図１９と同様である。
情報出力装置２のアプリ出所検査部（検証部）４３は機器操作命令の送受信に使うWebsocketコネクション（Websocketコネクション#2）のWebsocketヘッダに含まれるドメイン名が利用許可証に含まれるWebアプリのドメイン名と一致するか検査を行う。一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。利用許可証の送受信に使うWebsocketコネクション(Websocketコネクション#1)のWebsocketヘッダにドメイン名を示すヘッダが含まれている場合、利用許可証に含まれるWebアプリのドメイン名と一致するか検査しても良いししなくても良い。検証する場合、一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。
また、利用許可証送信部２５ａは、Webアプリのドメイン名と利用許可証に含まれるドメイン名との比較検査処理を行い、一致もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれるか検査し、検査に失敗した場合は以降の情報出力装置２と機器操作命令送信用のコネクションを切断してもよい。
図２３はこの形態における情報出力装置操作フェーズ(レベル2)における情報操作装置１、Webアプリ配布サーバ４、情報出力装置２の処理手順を示すシーケンス図を示す。図２２との違いは、情報操作装置１が利用許可証を情報出力装置２に送信するに先立って、Webアプリのドメイン名と利用許可証のドメイン名を比較して（ステップＳ９６）、一致しているか否かを検証し（ステップＳ９７）、一致している場合に限り、Websocketコネクション＃１で利用許可証を送信する（ステップＳ８７、Ｓ８８）点である。利用許可証の送受信に使うWebsocketコネクション（ステップＳ８８、Ｓ９０）はWebsocketクライアント処理部１８ａがコネクション確立処理と以降のコネクション管理処理を行う。なお、一致していない場合はコネクションを切断するなどのエラー処理を行う（ステップＳ９３）。ステップＳ９７の検証は、例えばPFアプリ実行部２１内で実行されるPFアプリが行う。
また、情報操作装置１は、ドメイン名のリストを保持し、そのリストにWebアプリのドメイン名が含まれているか検査処理を行い、含まれない場合には情報出力装置２と機器操作命令送信用のコネクションを切断してもよい。
図２４はこの形態における情報操作装置１内のアプリ実行部１６、アプリ取得部１２、アプリキャッシュ部１３の内部構成の一例を示すブロック図である。図２１との違いはPFアプリ内にドメインリスト９５を備えている点である。ドメインリスト９５はPFアプリ内に埋め込まれており、PFアプリ配布サーバ５からPFアプリと共に配布してもよいし、PFアプリ配布サーバ５からドメインリスト９５なしのPFアプリを配布してからPFアプリ実行時に不図示のドメインリスト９５配布サーバからドメインリスト９５をダウンロードするようにしてもよい。
なお、図２２、図２３でも図１９と同様にWebアプリ#3と、Webアプリ#4が異なるWebアプリである場合を説明してきたが、Webアプリ#3とWebアプリ#4は同一のWebアプリでもよい。その場合、Webアプリ#4のURLはWebアプリ#3と同一であり、Webアプリ#4を取得する処理（ステップＳ８２〜Ｓ８４）は省略され、Webアプリ#3が利用許可証の保存から機器操作命令の送信までを行う（ステップＳ８５〜ステップＳ９４）。
図２５はこの形態における情報出力装置操作フェーズ(レベル2)における操作装置、Webアプリ配布サーバ４、情報出力装置２の処理手順を示すシーケンス図を示す。図１９との違いは操作装置が利用許可証を情報出力装置２に送信する処理に先立って、PFアプリ内のドメインリスト９５にWebアプリのドメイン名が含まれているか検査処理を行い（ステップＳ９８、Ｓ９９）、含まれている場合に限り利用許可証を送信する（ステップＳ８７、Ｓ８８）点である。なお、含まれていない場合はコネクションを切断するなどのエラー処理を行う（ステップＳ９３）。
以上の説明では、情報操作装置１が情報出力装置２に対して利用許可証や機器操作命令を送信するためにWebsocketのプロトコルを利用していたが、HTTPまたはHTTPSのプロトコルを利用してもよい。
図２６は利用許可証や機器操作命令を送信するためにHTTPまたはHTTPSのプロトコルを利用する形態の情報操作装置１の内部構成を示すブロック図である。図２との違いはWebsocketクライアント処理部１８がない点と、機器操作命令送信部１９がHTTP処理部１１に接続されている点である。
図２ではアプリ実行部１６からの命令に基づいて利用許可証と機器操作命令を送信する送信機器操作命令送信部１９はWebsocketのプロトコルを用いていたが、図２６ではHTTP処理部１１を用いてそれらを送信する。なお、図２のWebsocketクライアント処理部１８内のドメイン付与部７０はWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行っていたが、図２６ではHTTP処理部１１がWebアプリ実行部２２で実行中のWebアプリのドメイン名をHTTPヘッダに付与する処理を行う。
図２７は利用許可証や機器操作命令をHTTPまたはHTTPSのプロトコルを利用して受信する形態の情報出力装置２の内部構成を示すブロック図である。図４との違いはWebsocketサーバ処理部４０の代わりにHTTPサーバ処理部４４がある点である。なお、図４ではアプリ出所検査部４３は、Websocketサーバ処理部４０で受信した機器操作命令に含まれるWebsocketヘッダの情報が正しいかどうかの検査処理を行っていたが、図２７ではWebアプリのドメイン名がHTTPヘッダに含まれるため、アプリ出所検査部４３は、その代わりの処理としてHTTPサーバ処理部４４で受信した機器操作命令に含まれるヘッダ情報が正しいかどうかの検査処理を行う。具体的には、機器操作命令に含まれるヘッダ情報が、利用許可証に含まれるWebアプリのドメイン名と一致するか検査処理を行い、一致した場合には検査成功と判断する。
次に利用許可証や機器操作命令を送信するためにHTTPまたはHTTPSのプロトコルを利用する場合の情報出力装置操作フェーズ(レベル2)について説明する。図２８は情報操作装置１、Webアプリ配布サーバ４、および情報出力装置２の処理手順を示すシーケンス図である。
図１９との違いは、利用許可証、利用許可証検査結果、および機器操作命令がHTTPまたはHTTPSのプロトコルにてなされる点である（ステップＳ１０８、Ｓ１１０、Ｓ１１４）。これらの処理以外は図１９と同様である。
なお、情報操作装置１が情報出力装置２に利用許可証を送信するメッセージの一例を以下に示す。
http://homeTV/req_token.php?appid=X&origin=xxxx&signature=yyyy&signature_method=rsa-sha1
この例では、情報出力装置”homeTV”に対して、利用許可証の情報を送信している。具体的にはappidでラベル付けされた値”X”でWebアプリの固有IDを送信し、originでラベル付けされた値”xxxx”でこのWebアプリに対応する出所情報(ドメイン名)を送信し、signatureでラベル付けされた値”yyyy”で利用許可証の署名を送信し、signature_methodでラベル付けされた値”rsa-sha1”で署名方式がRSA-SHA1である事を送信している。
図２８では、Webアプリ#4がHTTP処理部３１を使ってHTTPまたはHTTPSのプロトコルにて利用許可証を情報出力装置２に送信する。その際、POSTリクエストを用いればよい。もちろん、PUTリクエストやGETリクエストを用いてもよい。
以上述べてきたように、本実施形態では、情報操作装置１上で動作させるWebアプリから情報出力装置２をネットワーク経由で操作する際、情報操作装置１から送信される機器操作命令の受付に先立ち、情報出力装置２がWebアプリの配布元Webサーバ（Webアプリ配布サーバ４）のドメイン名をチェックする。さらに、情報出力装置２は、情報操作装置１から送信されてくる利用許可証に含まれる情報及び署名９３をチェックする。この二つの検査が成功した場合に限り、それ以降、情報操作装置１から送信される機器操作命令を受け付ける。
このようにすることで、以下の効果が得られる。
第一の効果として、機器操作命令の受信を許可されたWebアプリ配布サーバ４に限定することができる。仮に、攻撃者によって情報出力装置２に機器操作命令を送信する命令（例えばWebアプリ#4に含まれる命令）を記述した部分をコピーされてしまい、WebコンテンツXとしてあるWebサーバXにアップロードされてしまったとする。上述したようにWebアプリはHTMLやJavaScriptなどから構成されるが、これらはいわゆるPC上のWebブラウザで表示させるホームページ等のWebコンテンツと変わりはない。従って、情報操作装置１上でWebブラウザ(Webアプリ実行部２２)を利用して、各種ホームページなどを閲覧する際、WebコンテンツXを実行してしまうと、情報操作装置１の利用者が気付かぬうちに機器操作命令が情報出力装置２に送信されてしまう。したがって、何も制限がない場合、仮に機器操作命令が情報出力装置２内に録画された放送コンテンツをすべて削除するといった命令であった場合、情報操作装置１上でWebコンテンツXを閲覧しただけで利用者の気が付かないうちに情報出力装置２上の録画コンテンツが消去されてしまう。そこで、Webアプリ配布サーバ４の管理外のWebサーバにWebコンテンツXのような不正なWebアプリが置かれたとしても、情報出力装置２がWebアプリの配布元Webサーバのドメイン名をチェックすることで、それら不正なWebアプリからの操作命令を拒否することができる。
第二の効果として、情報出力装置２の操作をユーザが許可したWebアプリに限定できる。情報出力装置２はデジタルＴＶ等を想定しており、本実施形態に係る情報出力装置２は各家庭あるいは各個人によって所有される。ユーザAの情報操作装置１上で動作させる正規のWebアプリ(例えばWebアプリ#4)からユーザAの情報出力装置２を操作することは問題ない。しかし、ユーザAの情報操作装置１上で動作させる正規のWebアプリから、ユーザBの許諾なしにユーザBの情報出力装置２を操作することは防止する必要がある。情報操作装置１から機器操作命令を送信する度に情報出力装置２の赤外線リモコンを使って確認操作を強いることも可能であるが煩雑である。そこで、情報出力装置２にPINを設定し、情報出力装置２のパスワード(PIN)を含んだ利用許可証を情報操作装置１にインストールする。情報出力装置２は、情報操作装置１から送信された機器操作命令を実行する前に、利用許可証に含まれるPINが正しいか確認する。さらに通信経路上でのPINの値の改ざんを防止するために利用許可証に署名９３を添付し、情報出力装置２で署名９３を検証する。これにより、情報出力装置２のPINの値を知らないWebアプリによって情報出力装置２が勝手に操作されるのを防止できる。
以上により、ＴＶ等の情報出力装置がユーザの許諾なく勝手に操作されるのを確実に防止しつつ、スマートフォンやタブレット等の情報操作装置から情報出力装置を操作できるようになり、情報操作装置を有効活用できるとともに、情報出力装置の使い勝手も向上する。
（第２の実施形態）
第１の実施形態では、利用許可証を発行する利用許可証配布サーバ６と利用許可証を検査して機器操作命令を受け付ける情報出力装置２とが別々の装置であったのに対して、第２の実施形態では、利用許可証配布サーバ６と情報出力装置２とを一体構成にするものである。
図２９は第２の実施形態に係る情報出力装置２の内部構成を示すブロック図である。図４に示した情報出力装置２との違いは、ID登録要求送信部３７と固有ID管理部３６がない点、HTTPサーバ処理部４４、利用許可証要求受付処理部４５、許可証生成部４６、およびWebアプリ情報蓄積部４７を新たに備えている点、公開鍵管理部３８の代わりに鍵管理部４８を備えている点である。
HTTPサーバ処理部４４、利用許可証要求受付処理部４５、およびWebアプリ情報蓄積部４７は図７Ａの利用許可証配布サーバ６と同等の機能を有する。
機器検索処理部４１は、情報操作装置１からの装置検索要求に応答して、自装置の名前やIPアドレス、Websocketサーバ処理部４０のTCPポート番号に加えて、HTTPサーバ処理部４４のTCPポート番号を返信する処理を行ってもよい。
鍵管理部４８は、利用許可証の署名９３の生成に用いる秘密鍵と、利用許可証の署名９３の検証に用いる公開鍵の公開鍵ペアを管理する処理を行う。公開鍵のアルゴリズムとしてはRSA暗号や楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。公開鍵ペアの生成方法として、情報出力装置２の工場出荷時に鍵管理部４８に書き込む方法、情報出力装置２が鍵管理部４８にて公開鍵ペアを生成する方法がある。
利用許可証生成部４６は、利用許可証要求メッセージに含まれるWebアプリに固有のIDに対応する利用許可証をWebアプリ情報蓄積部４７から取得し、利用許可証、WebアプリID、利用許可証要求メッセージに含まれるPINに対して鍵管理部４８に格納した秘密鍵を使って署名９３を施し、署名９３付き利用許可証を生成する処理を行う。
Webアプリ情報蓄積部４７は、WebアプリIDに対応した署名前の利用許可証を蓄積する処理を行う記憶装置であるが、利用許可証は工場出荷時に予めWebアプリ情報蓄積部４７に書きこまれるか、HTTPのプロトコルで利用許可証配布サーバ６からインターネット８経由で書き込むようにしておけばよい。以下の例では工場出荷時にWebアプリ情報蓄積部４７に書きこまれているものとして説明する。
図３０は第２の実施形態における情報操作装置１、情報出力装置２、PFアプリ配布サーバ５、Webアプリ配布サーバ４の処理手順を示すシーケンス図である。図８に示した第１の実施形態のシーケンス図との違いは、図８のステップＳ１に示す情報出力装置セットアップフェーズがない点と、情報出力装置操作フェーズ(レベル１)で情報操作装置１が利用許可証を情報出力装置２からダウンロードする点（ステップＳ１２３）である。
第１の実施形態では、利用許可証配布サーバ６が公開鍵ペアを生成して情報出力装置２に公開鍵を配布したり、その公開鍵に対応する秘密鍵で利用許可証の署名９３を生成したりする処理を行っていたが、第２の実施形態では、情報出力装置２に公開鍵ペアが埋め込まれているため、情報出力装置セットアップフェーズは不要である。また、第２の実施形態では、情報出力装置２が利用許可証を生成するため、情報操作装置１は、利用許可証配布サーバ６ではなく、情報出力装置２から利用許可証をダウンロードする。
情報操作装置セットアップフェーズと情報出力装置操作フェーズ(レベル２)は第一の実施形態と同じである。
図３１は第２の実施形態における情報出力装置操作フェーズ(レベル1)の情報操作装置１とWebアプリ配布サーバ４の処理手順を示すシーケンス図である。
Webアプリ#2を実行し、PINの入力を促すようなメッセージを情報操作装置１の画面出力部１７の画面に表示させるまで（ステップＳ１３１〜Ｓ１３９）は図１３で示した手順と同様である。入力受信部１５からPINが入力されると、Webアプリ#2は利用許可証の要求メッセージを生成する（ステップＳ１４０）。具体的にはWebアプリ#2の命令に基づき、情報操作装置１はHTTP処理部３１を使ってHTTPS（またはHTTP）のプロトコルで利用許可証の要求メッセージを情報出力装置２に送信する。情報操作装置１が情報出力装置２に送信する利用許可証の要求メッセージの一例を以下に示す。
https://homeTV/req_token.php?appid=X&pin=ZZZZ
この例では、情報出力装置２”homeTV”に対して、appidでラベル付けされた値"X"でWebアプリの固有IDを指定し、pinでラベル付けされた値"ZZZZ"で入力受信部１５から入力されたPINの値を指定している。この例から分かるように、情報操作装置１はHTTPS(またはHTTPでもよい)のプロトコルで情報出力装置２に利用許可証の要求メッセージを送信する（ステップＳ１４１）。
情報出力装置２は、利用許可証要求メッセージを受信すると、Webアプリ情報蓄積部４７に蓄積されたデータを用い、利用許可証生成部４６で利用許可証を生成する（ステップＳ１４２）。具体的には、情報操作装置１から送信された利用許可証要求メッセージに含まれるWebアプリの固有IDに対応したWebアプリのドメイン名をWebアプリ情報蓄積部４７から取得する。そして、Webアプリの固有ID、Webアプリのドメイン名、情報操作装置１から送信された利用許可証要求メッセージに含まれるPINの値に対して、ハッシュ値を計算し、鍵管理部４８に保存されている秘密鍵を利用して公開鍵暗号方式に従った署名９３を生成する。そして利用許可証要求メッセージへの応答として、利用許可証とWebアプリ#4のURLを情報操作装置１に送信する（ステップＳ１４３）。
なお、第１の実施形態と同様に、利用許可証をWebアプリ#4のURLとともに情報操作装置１に送信する手段として、HTTPリダイレクト(HTTP redirect)を使っても良い。その場合、情報出力装置２はHTTPレスポンスのLocationヘッダにWebアプリ#4のURLと利用許可証を含めることになる。情報出力装置２がWebアプリ#4のURLを取得する方法として、情報出力装置２にあらかじめ記憶させておく方法、情報操作装置１が利用許可証の送信要求メッセージを生成する際、Webアプリ#2が送信要求メッセージにWebアプリ#4のURLを含めて情報操作装置１が情報出力装置２に送信し、情報出力装置２が入手する方法がある。
Webアプリ#2が利用許可証の送信要求メッセージにWebアプリ#4のURLを含めて情報出力装置２に送信する際のURL例を以下に示す。
https://homeTV/req_token.php?appid=X&pin=ZZZZ&url=example-Webserver.com/appid4
ここでurlでラベル付けされた値”example-Webserver.com/appid4”はWebアプリ#4のURLを示す。情報出力装置はこのURLを取得し、HTTPレスポンスのLocationヘッダにこのURLと利用許可証を含めて情報操作装置１に送信する。
以降の処理（ステップＳ１４４以降）は第一の実施形態と同様である。
以上の例では利用許可証配布サーバ６と情報出力装置２が一体となった構成を示したが、利用許可証要求メッセージ及び利用許可証の送受信は第一の実施形態と同様にHTTP(またはHTTPS)のプロトコルを用いてなされたが、必ずしもこれに限定するものではなくWebsocketのプロトコルを用いてなされてもよい。
図３２はWebsocketのプロトコルを用いて利用許可証要求メッセージを情報出力装置２に送信する際の情報操作装置１の構成を示すブロック図である。図２との違いは利用許可証取得部１４がHTTP処理部１１に接続されておらずWebsocketクライアント処理部１８に接続されている点である。
図３３はWebsocketのプロトコルを用いて情報操作装置１から利用許可証要求メッセージを受信し、利用許可証を送信する情報出力装置２の構成を示すブロック図である。図２９との違いはHTTPサーバ接続部が存在せず、利用許可証要求受付処理部４５がHTTPサーバ接続部ではなくWebsocketサーバ処理部４０に接続されている点である。
また、情報操作装置１がWebアプリ#2を使って情報出力装置２に送信する利用許可証の要求メッセージがHTTPまたはHTTPSのプロトコルであったのに対し、図３２及び図３３に示す構成ではWebsocketのプロトコルでなされる点が異なる。それ以外の処理フローは図３１に示したものと同様である。
なお、ユーザが入力するPINの値は以降の処理で通信する情報出力装置２に保存されているPINと同じ値である必要がある。ユーザが情報出力装置２のPINを忘れてしまった場合を考慮し、情報操作装置１から情報出力装置２の画面出力部にPINを表示させるよう情報出力装置２に指示してもよい。
図３４に情報出力装置２に表示されるPINの画面の表示例を示す。
図３５はこの形態における情報出力装置操作フェーズ(レベル1)の情報操作装置１とWebアプリ配布サーバ４の処理手順を示すシーケンス図である。Webアプリ#2を実行し、PINの入力を促すようなメッセージを情報操作装置１の画面出力部１７の画面に表示させるまで（ステップＳ１３１〜Ｓ１３７）は図３１で示した手順と同様である。
図３５では、PINの入力を促すようなメッセージを情報操作装置１の画面出力部１７の画面に表示させると共に、Webアプリ#2は機器操作命令送信部１９に対してPIN表示命令を送信する（ステップＳ１５１）。機器操作命令送信部１９はWebsocketクライアント処理部１８を使ってWebsocketのコネクションでPIN表示命令を情報出力装置２に送信する。
図３６はこの形態に係る情報出力装置２の内部構成を示すブロック図である。図３３との違いはPIN表示操作部４９を備えている点である。
PIN表示操作部４９は、情報操作装置１から受信したPIN表示命令を取得し、PIN管理部３９からPINを取得して情報出力装置２の画面出力部３３に出力する処理を行う（ステップＳ１５２）。この際、この画面出力を行う前にアプリ出所検査部４３でヘッダ情報の検査処理を行ってもよい。
情報操作装置１のユーザは、PIN管理部３９に記憶されているPINの値を覚えておく必要がなく、情報出力装置２の画面出力部３３に表示されたPINを見ながら、情報操作装置１の入力受信部１５にてPINを入力する（ステップＳ１５３）ことができるため、利便性を向上させる事ができる。
次に、情報操作装置１は、Websocketクライアント処理部１８を使って情報出力装置２とWebsocketのコネクションを確立し、情報出力装置２に対して、WebsocketのコネクションにてPIN表示終了通知を行う（ステップＳ１５４）。この通知を受けて、情報出力装置２は画面出力部３３のPIN表示を終了する（ステップＳ１５５）。その後は、図３１のステップＳ１４０〜Ｓ１４４と同様の処理を行う（ステップＳ１５６〜Ｓ１６０）。
なお、上記では情報出力装置２が情報出力装置２ごとに固有の公開鍵ペアを使って利用許可証の署名９３を生成する例について示したが、機器出荷時に共通の公開鍵ペアを鍵管理部４８に設定し、PFアプリに利用許可証を含めてもよい。このようにすることで、情報出力装置操作フェーズ(レベル1)の処理手順を省略してもよい。
このように、第２の実施形態では、利用許可証配布サーバ６と情報出力装置２とを一体化するため、情報操作装置１は、情報出力装置２だけと通信を行うことで利用許可証を取得でき、情報出力装置セットアップフェーズも不要となって、全体的な処理を簡略化できる。
（第３の実施形態）
第１および第２の実施形態で示した利用許可証は図１６に示すようにWebアプリ固有ID９１、Webアプリの出所９２、署名９３が含まれていた。第３の実施形態では、Webアプリごとに許可される機器操作命令を分ける構成を示すものである。
図３７に第３の実施形態に係る利用許可証のフォーマットの一例を示す。図１６に示した利用許可証との違いは、許可された操作命令リスト９５を備えている点である。この許可された操作命令リストもWebアプリIDに対応したドメイン名等と同様にWebアプリ情報蓄積部７７に蓄積されている。
第１および第２の実施形態では、署名対象のデータとしてWebアプリの固有ID、Webアプリのドメイン名、PINが含まれていたが、第３の実施形態ではこれらのデータに加えて許可された操作命令リストが含まれる。署名の計算方法の一例を以下に示す。
署名＝rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名 || PIN || 操作命令リスト))
秘密鍵は情報出力装置情報蓄積部７２から取得した情報出力装置２に固有の秘密鍵であり、この値を秘密鍵として署名を計算する。署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名、PIN、操作命令リストを結合してSHA1アルゴリズムを使って計算した値とする。これらの計算結果からRSAアルゴリズムを使って署名が求められる。ここでは署名計算アルゴリズムとしてRSAを使った例を示したが、このほかにも楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。
図３８は第３の実施形態に係る情報出力装置２の内部構成を示すブロック図である。第２の実施形態では利用許可証配布サーバ６と情報出力装置２とを一体構成にした例を示したが、ここでは第１の実施形態のように別々の構成の場合について説明する。すなわち、利用許可証は利用許可証配布サーバ６から取得する。図４との違いは、機器操作命令処理部３４の中に命令判断部５０を備えている点である。
命令判断部５０は、情報操作装置１から送信された機器操作命令が利用許可証検査部４２から通知された操作命令のリストに含まれていればその機器操作命令を受け付け、含まれていなければ拒絶する処理を行う。
処理のシーケンスに関しては第１の実施形態、第２の実施形態と同様である。
なお、第３の実施形態ではWebアプリごとに利用可能な機器操作命令が異なる事を想定しているが、Webアプリがどのような機器操作命令を実行する可能性があるか、情報操作装置１上の画面でユーザに通知するようにしてもよい。具体的には、図３９に示すように、PIN入力用WebアプリにてユーザにPIN入力を促す際、PIN入力Webアプリは情報出力装置２の画面出力部３３にWebアプリが操作可能な命令の一覧を出力させるようにしても良い。もちろん、許可された命令の一覧ではなく、上述したカテゴリー番号を表示させるようにしてもよい。
図３９に示したPIN入力用Webアプリは、Webアプリ配布サーバ４から情報操作装置１に配信される。Webアプリ配布サーバ４の構成は図７Ｂに示したものと同様の構成でよいが、Webアプリ蓄積部５２にはWebアプリの固有IDに対応したドメイン名と許可された操作命令リストのセットが記憶されている。
第１の実施形態で示したように、情報操作装置１は以下のようなURLでPIN入力用Webアプリの取得要求をWebアプリ配布サーバ４に送信する。
http://example-Webserver.com/input_pin.php?appid=X
Webアプリ配布サーバ４のWebアプリ配布部５４はWebアプリの固有IDを元にWebアプリ蓄積部５２からその固有IDを持つWebアプリに対応した操作命令リストを取得し、図３９に示した操作可能な命令の一覧を出力させる。これにより、ユーザはWebアプリにPIN入力をする前に、Webアプリの操作可能な命令の一覧を知ることができる。たとえば、Webアプリから情報出力装置２に対して特定の操作命令を送信したくないとユーザが判断すれば、PIN入力をしなければよい。このようにしてユーザは危険なWebアプリかどうかを自分で判断することができる利点がある。情報出力装置２は情報出力装置操作フェーズ(レベル２)で利用許可証を受信し、利用許可証検査部４２とアプリ出所検査部４３で検査が成功すると、操作命令リスト９５に含まれる機器操作命令を解釈して、どの機器操作命令を許可するかを機器操作命令処理部３４に通知する。機器操作命令処理部３４の命令判断部５０は、情報操作装置１から送信された機器操作命令が利用許可証検査部４２から通知された操作命令のリストに含まれていればその機器操作命令を受け付け、含まれていなければ拒絶する処理を行う。
利用許可証配布サーバ６の利用許可証生成部７９（第１の実施形態）、または情報出力装置２の利用許可証生成部４６（第２の実施形態）で利用許可証を生成する際、どのWebアプリにどの機器操作命令を許可するか、すなわち利用許可証の操作命令リスト９５をWebアプリごとに異なるものにすることで、Webアプリ#Xは情報出力装置２に対してチャンネル変更命令とコンテンツの一覧表示命令、コンテンツの消去機能命令を許可するが、Webアプリ#Yは情報出力装置２に対してチャンネル変更命令とコンテンツの一覧表示命令しか許可しないといったことが実現できる。
なお、操作命令リスト９５は機器命令を一つ一つリストしてもよいし、複数の機器命令をカテゴリーに分類してもよい。その場合、例えばチャンネル変更命令とコンテンツの一覧表示命令はカテゴリー1、コンテンツの消去命令をカテゴリー2と分類し、操作命令リスト９５にはWebアプリに許可するカテゴリー番号を含めるようにし、命令判断部５０は情報操作装置１から送信された機器操作命令が属するカテゴリーが操作命令リスト９５に含まれるか否かの検査を行い、含まれる場合のみその機器操作命令を許可するようにしても良い。
さらに、カテゴリーに優先順位をつけたレベルとしてとらえ、操作命令リスト９５にはWebアプリに許可する最も高い番号を含めるようにする。操作命令リスト９５にカテゴリー2と記されている場合はカテゴリー1とカテゴリー2に含まれる機器操作命令を許可すると定義してもよい。命令判断部５０は情報操作装置１から送信された機器操作命令が属するカテゴリーと、操作命令リスト９５に含まれるカテゴリーの番号の大きさを比較し、機器操作命令が属するカテゴリーが操作命令リスト９５に含まれるカテゴリーの番号より小さければ機器操作命令を許可するようにする。例えば、操作命令リスト９５にはカテゴリー2を含め、情報操作装置１が送信する機器操作命令がチャンネル変更命令だった場合 、チャンネル変更命令はカテゴリー1のため、この命令を許可する。一方、操作命令リスト９５にはカテゴリー1を含め、情報操作装置１が送信する機器操作命令がコンテンツ削除命令だった場合 、コンテンツ削除命令はカテゴリー2で操作命令リスト９５に含まれているカテゴリー1より大きいためこの命令を拒否する。
このように、第３の実施形態では、Webアプリごとに利用可能な機器操作命令を分ける事を実現している。例えば、WebアプリXはチャンネル変更命令とコンテンツの一覧表示命令が許可されており、WebアプリYはチャンネル変更命令のみ許可されている場合を考える。つまり、WebアプリX用の利用許可証に含まれる許可された操作命令リストとWebアプリYの利用許可証に含まれる許可された操作命令リストは異なる。さらに、Webアプリ配布サーバ４の説明で述べたように、Webアプリ配布サーバ４が同一ドメインの中に複数のWebアプリを格納する場合を考える。この時、WebアプリXとWebアプリYは同一のドメイン名を有するWebアプリ配布サーバ４から配布されることになり、利用許可証に含まれるWebアプリの出所も同じ値となる。
ここで、WebアプリYがWebアプリWebアプリX用の利用許可証を入手し、情報装置操作フェーズ(レベル2)でそのWebアプリX用の利用許可証を使って機器操作命令を情報出力装置２に送信したとしても、WebアプリXとWebアプリYは出所が同一のため、情報出力装置２はその利用許可証を見てWebアプリXに許可された操作が可能となってしまう。つまり、WebアプリYは本来許可されていないにも関わらず、コンテンツの一覧表示命令を情報出力装置２で実行させる事が可能になってしまう。
そこで、HTTPリダイレクトを利用して、利用許可証配布サーバ６が、その利用許可証を取得するWebアプリをURLによって指定する事で、利用許可証配付サーバ６は利用許可証が取得可能なWebアプリを制限する事ができる。つまり、WebアプリX用の利用許可証を情報操作装置１に送信する際、HTTPリダイレクトでWebアプリXのURLを指定しておけば、WebアプリX用の利用許可証を取得できるアプリをWebアプリXに限定することができる。これにより、WebアプリX用の利用許可証がWebアプリX以外に取得される事を防ぐ事ができる。
また、第１の実施形態では、情報操作装置１のPFアプリ内にドメインリストを持たせ、ダウンロードしたWebアプリのドメイン名がドメインリストに含まれるかどうか検査処理を行う例について示したが、その場合、利用許可証にWebアプリのドメイン名を含める必要は必ずしもない。その場合の利用許可証のフォーマットの一例を図４０に示す。図３７に示した利用許可証との違いは、許可されたWebアプリの出所９２を備えていない点である。
このように、第３の実施形態では、Webアプリに許可される機器操作命令のリストを利用許可証に含めることで、許可する機器操作命令をWebアプリ毎に異ならせることができる。例えば、情報出力装置２の製造メーカーが開発するWebアプリに対してはすべての機器操作命令を許可し、情報出力装置２の製造メーカーのパートナー企業が開発したWebアプリには許可する機器操作命令を制限することが可能となる。また、特別なライセンスを締結した情報出力装置２の製造メーカーのパートナー企業に対してはその制限を緩めるといったようなビジネスを展開することも可能となる。
（第４の実施形態）
第１、第２および第３の実施形態では、Webアプリ配布サーバ４が同一ドメインの中に複数のWebアプリを格納する場合を想定していた。以下に説明する第４の実施形態では、Webアプリ配布サーバ４は同一ドメインの中に複数のWebアプリを格納してもよいが、それらのWebアプリが同一の利用許可証を利用するという制限をつけることで、利用許可証配布サーバ６の処理内容を削減するものである。
図４１は第４の実施形態における情報操作装置１、情報出力装置２、PFアプリ配布サーバ５、およびWebアプリ配布サーバ４の処理手順を示すシーケンス図である。図３０に示した第２および第３の実施形態のシーケンス図との違いは、情報出力装置操作フェーズ(レベル１)で情報操作装置１が利用許可証配布サーバ６との通信を介さずPINを入力する手順（ステップＳ１６２）が追加された点と、情報出力装置操作フェーズ(レベル２)で利用許可証をダウンロードする手順（ステップＳ１６１）と、情報操作装置１が情報出力装置２と通信する処理手順（ステップＳ１６３）とが異なる点である。
なお、以後の説明では第３の実施形態との差分を示すが、この実施形態のポイントは利用許可証のフォーマットの中でも署名部分を変更し、利用許可証配布サーバ６の処理内容を削減する点にある。第４の実施形態の特徴部分は、第１の実施形態または第２の実施形態にも適用可能である。
第３の実施形態では、情報出力装置操作フェーズ(レベル１)で情報操作装置１は情報出力装置２から利用許可証を受信する際に、入力されたPINを情報出力装置２に送信していたが、第４の実施形態では、PINは情報操作装置１に保存され（ステップＳ１６２）、利用許可証要求時には情報出力装置２に送信しない。さらに第３の実施形態では利用許可証を情報出力装置２から受信していたが、第４の実施形態では第１の実施形態と同様、情報操作装置１は利用許可証配布サーバ６から利用許可証を受信する（ステップＳ１６１）。なお、この実施形態では利用許可証は情報出力装置２に固有の値ではない。また、利用許可証は事前に計算しておくことが可能であるため、利用許可証配布サーバ６から配信される必要もなく、Webアプリ配布時またはPFアプリ配布時に生成しておく事が可能であり、利用許可証をPFアプリ配布時にリソースの一つとして配布する事が可能である。このような場合、利用許可証は利用許可証からダウンロードする必要はない。つまり、ステップＳ１６１は省略可能である。以下では、まず利用許可証配布サーバ６から配信する例について述べる。ただし、利用許可証のフォーマット（データ構造）は異なる。利用許可証のフォーマットについては後述する。
さらに、第３の実施形態では、情報出力装置操作フェーズ(レベル２)で情報操作装置１は利用許可証のみを情報出力装置２に送信していたが、第４の実施形態では利用許可証に加えて、情報出力装置操作フェーズ(レベル１)で保存しておいたPINを送信する（ステップＳ１６３）。
図４２に第４の実施形態に係る利用許可証のフォーマットの一例を示す。図３７に示した利用許可証との違いは、署名９３ａの計算方法である。第３の実施形態では署名対象のデータとしてWebアプリの固有ID、Webアプリのドメイン名、およびPINが含まれていた。第４の実施形態ではPINを含まず、Webアプリの固有IDとWebアプリのドメイン名しか含まない。さらに、第３の実施形態では秘密鍵は情報出力装置２に固有の値となっていたが、第４の実施形態では複数の情報出力装置２に共通の値となる。署名の計算方法の一例を以下に示す。
署名＝rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名|| 操作命令リスト)) 秘密鍵に対応する公開鍵は複数の情報出力装置２で共有される。この値を秘密鍵として署名を計算する。署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名、操作命令リストを結合してSHA1アルゴリズムを使って計算した値とする。これらの計算結果からRSAアルゴリズムを使って署名が求められる。ここでは署名計算アルゴリズムとしてRSAを使った例を示したが、このほかにも楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。
なお、操作命令リストはオプションであり、必ずしも署名の計算に含める必要はない。その場合の署名計算の方法の一例を以下に示す。
署名＝rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名))
この場合、署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名を結合してSHA1アルゴリズムを使って計算した値とする。
図４３は第４の実施形態に係る利用許可証配布サーバ６の内部構成を示すブロック図である。図７Ａとの違いは、図７Ａの利用許可証配布サーバ６よりも内部構成を簡略化させ、HTTPサーバ処理部７１、利用許可証登録受付処理部８０、利用許可証生成部７９、Webアプリ情報蓄積部７７、および利用許可証検索処理部５７のみを有する点である。
HTTPサーバ処理部７１、利用許可証登録受付処理部８０は、図７Ａに示したものと同等の処理を行う。なお、利用許可証登録受付処理部８０は必須の構成ではない。
Webアプリ情報蓄積部７７は署名済み利用許可証を蓄積する処理を行う。
利用許可証生成部７９は、利用許可証を生成する処理を行う。利用許可証のフォーマットは第３の実施形態と異なるため、利用許可証を生成する処理も異なる。図７Ａでは情報出力装置２に固有の秘密鍵を生成し、情報出力装置情報蓄積部７２に保存し、その秘密鍵で利用許可証の署名を生成していた。第４の実施形態では複数の情報出力装置２に共通の秘密鍵によって利用許可証の署名を生成する。なお、この秘密鍵に対応する公開鍵は情報出力装置２の公開鍵管理部３８にあらかじめ蓄積されている。つまり、第４の実施形態では利用許可証を生成するために情報出力装置２の情報は不要であるため、情報出力装置２と通信する事なく利用許可証を生成することが可能である。利用許可証は、情報出力装置２に共通の公開鍵に対応する秘密鍵を持った装置であれば生成することができるため、必ずしも利用許可証配布サーバ６で行う必要はない。不図示の情報出力装置２に共通の公開鍵に対応する秘密鍵を備えた装置で利用許可証を生成し、Webアプリ情報蓄積部７７に登録してもよい。利用許可証配布サーバ６で利用許可証の署名計算処理を行わない場合は、利用許可証生成部７９は必須の構成ではない。その場合、利用許可証登録受付処理部８０は署名済み利用許可証を受け付け、そのままWebアプリ情報蓄積部７７に蓄積する処理を行う。
利用許可証検索処理部５７は、情報操作装置１からの要求に基づいてWebアプリ情報蓄積部７７に蓄積しておいた署名済み利用許可証を検索し、HTTPサーバ処理部７１を利用して情報出力装置２に送信する処理を行う。具体的な処理の例としては、情報操作装置１はWebアプリ固有IDを指定し、利用許可証検索処理部５７はその指定されたWebアプリ固有IDをキーとしてWebアプリ情報蓄積部７７に蓄積されている利用許可証を取得して、情報操作装置１に送信する処理を行う。
第３の実施形態では情報操作装置１からの利用許可証要求に基づき、その利用許可証要求に含まれる情報出力装置２に固有のIDを元に、情報出力装置２とWebアプリに固有の利用許可証を生成する処理が必要であった。しかし、第４の実施形態ではWebアプリ情報蓄積部７７に蓄積されている利用許可証を検索して取得する処理を行えばよく、署名生成のための暗号処理などを行う必要がないため、利用許可証配布サーバ６にとって必要とする計算処理能力を大幅に削減することができる。また、第３の実施形態では生成する利用許可証の個数はWebアプリの数に情報出力装置の数を掛け合わせた数となっていた。しかし、第４の実施形態では利用許可証は情報出力装置２に固有ではなく、Webアプリにのみ固有であるため、生成すべき利用許可証の数はWebアプリの数と同一になり利用許可証の生成処理を大幅に削減することができる。また、第３の実施形態では利用許可証の生成処理を情報操作装置１からの利用許可証要求に基づき都度行う事を想定していたが、第４の実施形態ではWebアプリの個数分だけ事前に利用許可証を生成しておくことも可能である。このように、第４の実施形態では利用許可証配布サーバ６の処理を簡略化することができる。
図４４は第４の実施形態に係る情報出力装置２の内部構成を示すブロック図である。図３８との違いは、PIN入力Webアプリ生成・送信部５８とPIN検査部５９を新たに備えている点と、図３８の固有ID管理部３６、MAC鍵管理部５６、およびID登録要求送信部３７を備えていない点である。
PIN入力Webアプリ生成・送信部５８は図１５に示したように情報操作装置１でPIN入力画面を表示するためのWebアプリ（PIN入力用Webアプリ）を生成し、情報操作装置１に送信する処理を行う。なお、画面操作装置１からPIN入力用Webアプリの要求メッセージの中に利用許可証の署名が含まれている場合、PIN入力Webアプリ生成・送信部５８は公開鍵管理部３８に蓄積されている公開鍵で利用許可証の署名の正当性を検証し、検証が成功した場合のみPIN入力用Webアプリを画面操作装置１に送信するようにしても良い。これは、画面操作装置１から送信される利用許可証に含まれる情報、たとえば許可された操作命令リストが通信途中で改ざんされていた時に有用である。たとえば、あるWebアプリがチャンネル変更命令とコンテンツの一覧表示命令が許可されているとする。しかし通信経路上で許可された操作命令リストがコンテンツの一覧表示命令しか要求しないと改ざんされてしまうと、それを受信した画面出力装置２は図３９の画面として「コンテンツの一覧表示命令」が可能と表示してしまう。これを見たユーザは、本来、そのWebアプリがチャンネル変更命令とコンテンツの一覧表示命令実行可能であるにも関わらず、コンテンツの一覧表示命令しか実行する権限がないと誤って判断してPINを入力してしまうかもしれない。一方で、情報出力装置２はWebアプリ情報蓄積部を有しないため、そのWebアプリがどのような許可された操作命令リストを有しているか分からない。しかし、情報出力装置２で利用許可証の署名検証処理を行うことで、利用許可証の内容が正しいか確かめることができるため、PIN入力用Webアプリに、利用許可証と同じ許可された操作命令リストを表示させる事ができるようになる。これにより、ユーザにPIN入力Webアプリの正しい表示内容を出力させる事が可能となる。
PIN検査部５９は情報操作装置１からWebsocketのコネクションで送信されてきたPINがPIN管理部３９に登録されている値と一致するか否か検査を行い、その結果を機器操作命令処理部３４に通知する処理を行う。
図４５は第４の実施形態に係る情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図である。図３との違いはPIN保存部６０を備えている点である。
PIN保存部６０は入力受信部１５で受信したPINの値を一時的に保存する処理を行う。
図４６乃至図４８は第４の実施形態における情報出力装置操作フェーズ(レベル1、レベル2)の情報操作装置１と、利用許可証配布サーバ６、Webアプリ配布サーバ４、および情報出力装置２の処理手順を示すシーケンス図である。情報出力装置セットアップフェーズは第２の実施形態と同様不要である。情報操作装置セットアップフェーズは第１の実施形態または第２の実施形態と同様の手順でよい。
PFアプリを実行し（ステップＳ１７１）、ローカルWebアプリを実行する（ステップＳ１７２）までは図３１のステップＳ１３１，Ｓ１３２と同じである。なお、この例ではローカルWebアプリとしているが、図１８で示したようにPFアプリはURLのみ備え、PFアプリ実行部２１からWebアプリ取得部２７にURLを渡し、Webアプリ取得部２７がWebアプリ配布サーバ４に対してそのURLを元にWebアプリの送信要求を送信してWebアプリ配布サーバ４からWebアプリをダウンロードし、Webアプリ実行部２２にてそのWebアプリを実行するようにしてもよい。
ローカルWebアプリ(Webアプリ#5)は、まず情報操作装置１の中に利用許可証が存在するかどうかチェックする（ステップＳ１７３）。もし既に利用許可証を取得している場合はステップＳ１７８に進む。
なお、前述のように本実施形態では利用許可証は情報出力装置２の固有IDには依存せず、操作対象の情報出力装置が異なっていたとしても、同じWebアプリであれば利用許可証も同じものとなる。従って、利用許可証を含んだ形でPFアプリをパッケージ化して配布してもよい。その場合、PFアプリがインストールされる際、利用許可証はアプリ蓄積部３０にPFアプリのデータの一部として記憶される。その場合は、利用許可証が存在するかどうかを検査する処理を省略し、Webアプリはアプリ蓄積部３０から利用許可証を取得するようにしても良い。
情報操作装置１の中に利用許可証がない場合、Webアプリごとに決められ、あらかじめアプリケーションパッケージの中に含まれているURLを取得して（ステップＳ１７４）、このURLを元に利用許可証取得要求を利用許可証配布サーバ６に送信する（ステップＳ１７５）。この処理はHTTP処理部１１を用いてHTTP（またはHTTPS）のプロトコルで送信する。情報操作装置１が利用許可証配布サーバ６に送信する利用許可証の要求メッセージの一例を以下に示す。
https://example-CAserver.com/req_token.php?appid=X
この例では、利用許可証配布サーバ” example-CAserver.com”に対して、appidでラベル付けされた値"X"でWebアプリの固有IDを指定している。
また、以下のような形式であってもよい。
https://example-CAserver.com/appidX/token.dat
この場合、利用許可証は”token.dat”という名前で指定される単なるファイルにすぎないため、利用許可証配布サーバ６はWebアプリ配布サーバ４と同じ構成を取ればよい。
第４の実施形態では、利用許可証はWebアプリ毎に固有の値であるが、情報出力装置２には固有ではないため要求メッセージの中に情報出力装置２に固有のIDは含めない。さらに利用許可証はPINを含めて計算する必要がないため、要求メッセージにPINの値も含めない。
利用許可証配布サーバ６は、利用許可証要求メッセージを受信すると、Webアプリの固有IDを元にWebアプリ情報蓄積部７７に蓄積された署名済み利用許可証を取得し、利用許可証要求メッセージへの応答として、利用許可証を情報操作装置１に送信する（ステップＳ１７６）。
Webアプリ#5は受信した利用許可証を利用許可証蓄積部２４に保存する（ステップＳ１７７）。なお、第３の実施形態では情報操作装置１が利用許可証を保存する際、利用許可証配布サーバ６が利用許可証を利用可能なWebアプリの範囲を指定し、Webアプリが利用許可証を利用する際に、利用許可証アクセス制御部２３を用いて、保存した利用許可証のアクセス制御の処理を行っていたが、第４の実施形態では必ずしもこの処理は必要ない。つまり、第４の実施形態では利用許可証アクセス制御部２３は必須の構成ではない。
次に、Webアプリ#5は情報操作装置１の中にPINが含まれているかどうかを検査する（ステップＳ１７８）。既にPINが含まれている場合は、Webアプリ#5の中に含まれるURLを元に機器操作Webアプリを取得する。PINが含まれていない場合、Webアプリ#5の中に含まれるURLを元にPIN画面の要求メッセージを生成し（ステップＳ１７９）、情報出力装置２にPIN入力用Webアプリの送信を要求する（ステップＳ１８０）。具体的には情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでPIN入力用Webアプリ（Webアプリ#6）の取得要求を情報出力装置２に送信する。この要求メッセージの例を以下に示す。
http://example-Webserver.com/input_pin.php?appid=X&origin=xxxx&signature=yyyy&signature_method=rsa-sha1
上述したように情報出力装置２が利用許可証の署名検証を行えるように、署名済み利用許可証をURLのパラメタに添付している。
また、この要求メッセージには機器操作Webアプリ(Webアプリ#7)のURLを含める。
http://example-Webserver.com/input_pin.php?appid=X&origin=xxxx&signature=yyyy&signature_method=rsa-sha1&url=example-Webserver.com/appid7
情報出力装置２はPIN画面の要求メッセージを受信すると、PIN入力Webアプリ生成・送信部５８にてPIN入力用Webアプリ（Webアプリ#6）を生成する（ステップＳ１８２）。この際、公開鍵管理部３８に蓄積されている公開鍵を用いて利用許可証の署名の検証を行っても良い（ステップＳ１８１）。
情報操作装置１はWebアプリ#6を受信すると（ステップＳ１８３）、Webアプリ実行部２２にてWebアプリ#6を実行する。PIN入力用WebアプリであるWebアプリ#6の画面イメージは図１５に示したとおりである。Webアプリ#6は入力受信部１５で入力したPINの値を取得すると（ステップＳ１８４）、PINを保存して（ステップＳ１８５）、Webアプリ#6に含まれるURLまたはWebアプリ#5に含まれるURLを取得して（ステップＳ１８６）、そのURLから機器操作Webアプリ(Webアプリ#7)の取得要求を生成して、Webアプリ配布サーバ４に送信する（ステップＳ１８７）。具体的にはWebアプリ#6の指示に従って情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルで機器操作Webアプリ(Webアプリ#7)の取得要求をWebアプリ配布サーバ４に送信する。これを受けて、Webアプリ配布サーバ４はWebアプリ#7を情報操作装置１に送信する（ステップＳ１８８）。
なお、第３の実施形態では、情報操作装置１が利用許可証を取得するために入力したPINの値が利用許可証要求のメッセージに含まれて情報出力装置２に送信されたが、本実施形態では利用許可証を取得するためにPINの値は不要である。このため、利用許可証を取得するためにPINは送信されない。
その後、情報操作装置１はWebアプリ配布サーバ４からWebアプリ#7を取得して（ステップＳ１８９）、Webアプリ実行部２２にて実行する。
Webアプリ#7はPINと保存しておいた利用許可証を取得する（ステップＳ１９０）。ここでは、ステップＳ１８５で入力して保存してあったPINを利用する。ステップＳ１８５にてPINを保存しておく方法として、利用許可証と同様にブラウザのcookieにファイルとして保存しておく方法と、ハッシュフラグメントとして保存しておく方法の二通りがある。
cookieとして保存しておく場合、Webアプリ#6はPINの値がWebアプリ#7で取得可能なようにURLの範囲を設定しておく。Webアプリ#7はPINの値をcookieから取得する際、利用許可証と同様に利用許可証アクセス制御部２３にてWebアプリ#7で取得可能であると判定される。
ハッシュフラグメントとして保存する場合、Webアプリ#6はPIN画面入力用のプログラムを以下のように構成すればよい。
<form method="POST" action=" http://example-Webserver.com/webapp7.php?getWebapp.php#">
<input type="text" name="PIN">
<input type="submit" value="送信">
ここで、PINが入力された場合、Webアプリ配布サーバ４に対してWebアプリ#7を取得するメッセージを送信するように指示している。ハッシュフラグメントのためPINはWebアプリ配布サーバ４には送信されない。なお、PIN入力用Webアプリの構成を容易にするために、Webアプリ配布サーバ４にPINの値を送信するようにしてもよい。
Webアプリ#7は取得したPINと利用許可証をWebsocketのコネクションを利用して情報出力装置２に送信する（ステップＳ１９２、Ｓ１９３）。具体的には、Webアプリ#7の指示に基づき、情報操作装置１のWebsocketクライアント処理部１８はWebsocketコネクションにて情報出力装置２にPINと利用許可証を送信する。この時、Websocketクライアント処理部１８内のドメイン付与部７０はWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行う。すなわち、PINと利用許可証を送信するWebsocketのコネクションのヘッダにはWebアプリ実行部２２で実行中のWebアプリ（Webアプリ#7）のドメイン名が含まれて情報操作装置１から情報出力装置２に送信される。情報出力装置２は、利用許可証に含まれるWebアプリのドメイン名がWebsocketヘッダに含まれるドメイン名が一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。
情報出力装置２は受信した利用許可証とPINの値を検査する（ステップＳ１９４）。利用許可証の検査は利用許可証検査部４２が行い、利用許可証に含まれる署名が正しいか否かを検査する。PINの検査はPIN検査部５９が行い、PIN管理部３９で管理している値と一致するか否かを検査する。情報操作装置１は、ドメインの検査と利用許可証の検査とPINの検査のすべてに成功したか否かを判定する。判定結果は、情報出力装置２から情報操作装置１に送信してもよい（ステップＳ１９５）し、検査結果が失敗した場合、情報出力装置２はWebsocketのコネクションを切断するようにしてもよい。
情報出力装置２から情報操作装置１に判定結果を送信する場合、情報操作装置１はその判定結果に基づき、判定結果が失敗の場合にはエラー処理を行い（ステップＳ１９８）、判定結果が成功の場合には機器操作命令を送信する（ステップＳ１９７）。
なお、情報出力装置２が判定処理を失敗と判定してWebsocketのコネクションを切断した場合、情報操作装置１はコネクション切断をもって判定結果が失敗と判断し、エラー処理を行い（ステップＳ１９８）、Websocketコネクションが切断されなかった場合は機器操作命令を送信するようにしてもよい（ステップＳ１９７）。
そして機器操作Webアプリ(Webアプリ#7)の指示に基づき、情報操作装置１のWebsocketクライアント処理部１８はWebsocketコネクションにて情報出力装置２に機器操作命令を送信する（ステップ１９９）。
利用許可証とPINの両方の検査が成功すると、情報出力装置２は、その後に情報操作装置１から送信される機器操作命令を受け付ける。もし片方でも検査が失敗していれば、機器操作命令は拒否してエラー処理を行い、以降の機器操作命令は受け付けない。第３の実施形態と同様、両方の検査が成功した場合に限り、操作命令リストに含まれる機器操作命令を解釈して、どの機器操作命令を許可するかを機器操作命令処理部３４に通知する。その後の処理（ステップＳ１９９、Ｓ２００）は図１９と同じでよい。
なお、図４６〜図４８ではWebアプリ#5と、Webアプリ#7が異なるWebアプリである場合を説明してきたが、Webアプリ#5とWebアプリ#7は同一のWebアプリでもよい。その場合、Webアプリ#7のURLはWebアプリ#5と同一であり、Webアプリ#7を取得する処理（ステップＳ１８５〜Ｓ１８７）は省略され、Webアプリ#5が利用許可証の取得から機器操作命令の送信までを行う（ステップＳ１８８〜ステップＳ１９７）。
このように、第４の実施形態では、複数の情報出力装置２が共通の利用許可証を所持するように利用許可証のデータ構造を変更した。これにより、利用許可証配布サーバ４の処理内容を削減する事ができる。
（第５の実施形態）
第３の実施形態ではWebアプリごとに許可される機器操作命令を分ける構成を示した。また、第４の実施形態では、同一ドメイン内の複数のWebアプリが同一の利用許可証を利用する構成を取り、かつ情報操作装置１はPIN入力用Webアプリを情報出力装置２から取得する例を示した。以下に説明する第５の実施形態では、Webアプリごとに許可される機器操作命令を分け、同一ドメイン内の複数のWebアプリが同一の利用許可証を利用する構成を取るが、情報操作装置１はPIN入力用WebアプリをPIN入力用Webアプリ配布サーバ４ａから取得する構成を取る。
図４９Ａは第５の実施形態に係る情報操作装置１の内部構成を示すブロック図である。図２４との違いは、Webアプリ実行部２２内にPIN保存部６０を備えていることと、PFアプリ実行部２１内のWebsocketクライアント処理部１８ａは利用許可証に加えてPINも送信する点である。
PIN保存部６０は、ユーザが入力したPINの値を保存する処理を行う。PINを保存する方法として、たとえばブラウザのcookieにファイルとして保存する方法がある。
なお、利用許可証アクセス制御部２３は利用許可証蓄積部２４に蓄積した利用許可証をWebアプリ配布サーバ４のドメイン毎に管理する機能と共に、PIN保存部６０に蓄積したPINの値をWebアプリ配布サーバ４のドメイン毎に管理する機能も有する。
図５０は第５の実施形態に係るPIN入力用Webアプリ配布サーバ４ａの内部構成を示すブロック図である。PIN入力用Webアプリ配布サーバ４ａは、HTTPサーバ処理部５１、Webアプリ蓄積部５２、Webアプリ登録処理部５３、Webアプリ配布部５４、利用許可証検査部６５、および公開鍵管理部６６を備えている。HTTPサーバ処理部５１、Webアプリ蓄積部５２およびWebアプリ登録処理部５３は図５に示したWebアプリ配布サーバ４と同等の機能を有する。
公開鍵管理部６６は、情報操作装置１からPIN入力用Webアプリ送信要求と共に送信されてくる利用許可証を検証するための公開鍵を蓄積する処理部である。
利用許可証検査部６５は、情報操作装置１からPIN入力用Webアプリ送信要求と共に送信されてくる利用許可証を、公開鍵管理部６６に蓄積された公開鍵を用いて署名検証処理を行う。
Webアプリ配布部５４は、PIN入力用Webアプリを情報操作装置１に送信するに先立ち、利用許可証検査部６５に利用許可証を送信し、その応答として署名検証の結果を受信する。署名検証の結果が成功した場合にのみPIN入力用Webアプリを情報操作装置１に送信する。署名検証処理が失敗した場合には、PIN入力用Webアプリを情報操作装置１に送信しない。なお、この署名検証処理は必須の構成ではない。
図５１Ａは第５の実施形態に係る情報出力装置２の内部構成を示すブロック図である。図４４との違いは、HTTP処理部３１とPIN入力Webアプリ生成・送信部５８を備えていない点である。第５の実施形態では情報操作装置１はPIN入力用WebアプリをPIN入力用Webアプリ配布サーバ４ａから受信するため、情報出力装置２がこの機能を備える必要はない。それ以外の構成は図４４と同じである。
図５２と図５３Ａは第５の実施形態における情報出力装置操作フェーズ(レベル1、レベル2)の情報操作装置１と、PIN入力用Webアプリ配布サーバ４、Webアプリ配布サーバ４、および情報出力装置２の処理手順を示すシーケンス図である。情報出力装置セットアップフェーズは第４の実施形態と同様に不要である。情報操作装置セットアップフェーズは第１の実施形態または第２の実施形態と同様の手順でよい。
ステップＳ１７８までは図４６と同様の処理手順をふめばよい。
PINが存在しない場合、情報操作装置１のローカルWebアプリ(Webアプリ#5)はPIN入力用Webアプリ取得要求をPIN入力用Webアプリ配布サーバ４ａに送信する（ステップＳ２０１、Ｓ２０２）。具体的にはWebアプリ#5の命令に基づき、情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでPIN入力用Webアプリ（Webアプリ#8）の取得要求をPIN入力用Webアプリ配布サーバ４ａに送信する。情報操作装置１がPIN入力用Webアプリ配布サーバ４ａに送信するPIN入力用Webアプリの要求メッセージの一例を以下に示す。
http://example-PINserver.com/req_pin.php?appid=X&perm=xxxx&origin=xxxx&signature=xxxx&signature_method=rsa-sha1&url= example-Webserver.com/appid5
この例では、PIN入力用Webアプリ配布サーバ” example-PINserver.com”に対して、利用許可証を送信している。具体的にはappidでラベル付けされた値”X”でWebアプリの固有IDを指定し、originでラベル付けされた値”xxxx”でこのWebアプリに対応する出所情報(ドメイン名)を指定し、signatureでラベル付けされた値”yyyy”で利用許可証の署名を指定し、signature_methodでラベル付けされた値”rsa-sha1”で署名方式がRSA-SHA1である事を指定している。urlはPFアプリが指定するURL、すなわちローカルWebアプリ(Webアプリ#5)のURLを指定する。PIN入力用Webアプリ配布サーバ４ａにPIN入力用Webアプリを要求する際のリクエストとして利用許可証を送信する理由は、第４の実施形態と同様、通信経路上での許可された操作命令リストの改ざんを検出し、PIN入力用Webアプリに、利用許可証と同じ許可された操作命令リストを表示させる事ができるようにするためである。ローカルWebアプリのURLを指定している理由は、Webアプリ#8でPINを入力後に、ローカルWebアプリに移動できるようにするためである。
PIN入力用Webアプリ配布サーバ４ａは公開鍵管理部６６に蓄積されている利用許可証検証用の公開鍵を使って、情報操作装置１から送信されてきた利用許可証の内容が正しいか、利用許可証に含まれる署名を検証する（ステップＳ２０３）。署名検証が成功すれば、利用許可証の情報を利用してWebアプリ#8(PIN入力用Webアプリ)を生成し（ステップＳ２０４）、情報操作装置１に送信する（ステップＳ２０５）。
情報操作装置１は、Webアプリ#8を受信してWebアプリ実行部２２で実行する（ステップＳ２０６〜Ｓ２１０）。Webアプリ#8は図３９に示したような画面を画面出力部１７に表示する。Webアプリ#8は下記のようなプログラムを内包している。
<form method="POST" action=" http://example-Webserver.com/appid5#">
<input type="text" name="PIN">
<input type="submit" value="送信">
PINが入力されると、以下のURLに移動する。具体的にはWebアプリ#8の指示に従って情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでWebアプリ#5の取得要求をWebアプリ配布サーバ４に送信する。
http://example-Webserver.com/appid5#pin
ここで”pin”は入力されたPINの値を示す。ハッシュフラグメントのためPINの値はWebアプリ配布サーバ４には送信されない。Webアプリ#5は、PINの値をPIN保存部６０に保存する。この時、PINの値がWebアプリ#5で取得可能なようにURLの範囲を設定しておく。Webアプリ#5はPINの値をcookieから取得する際、利用許可証と同様に利用許可証アクセス制御部２３にてWebアプリ#5で取得可能かどうか判定され、取得可能である場合にはWebアプリ#5はPIN保存部６０からPINを取得する事ができる。
なお、Webアプリ#5がアプリキャッシュ部１３のWebアプリキャッシュ部２９に保存されている場合、Webアプリ取得部２７はHTTP処理部３１を使ってWebアプリ配布サーバ４にWebアプリ#5の取得要求を送信する必要はなく、その代わりにWebアプリ取得部２７はWebアプリキャッシュ部２９に保存されているWebアプリ#5を取得し、Webアプリ実行部２２で実行するようにしてもよい。
Webアプリ#5がPINと、保存しておいた利用許可証を取得する処理からPINと利用許可証を送信する処理（ステップＳ２１１〜Ｓ２１３）までは図４８のステップＳ１９０〜Ｓ１９２までと同様である。
その後、機器操作Webアプリ（Webアプリ#5）の指示に従って、情報操作装置１は、Websocketクライアント処理部１８ａを使って情報出力装置２とWebsocketのコネクション(Websocketコネクション#1)を確立し、情報出力装置２に対して、WebsocketのコネクションにてPINと利用許可証を送信する（ステップＳ２１４）。
情報出力装置２は受信した利用許可証とPINの値を検査し（ステップＳ２１５）、判定結果を情報操作装置１に送信してもよい（ステップＳ２１６）。この処理は図４８で示したステップＳ１９４〜Ｓ１９５の処理と同じである。
情報出力装置２の検査結果が成功した場合、機器操作Webアプリ(Webアプリ#5)の指示に基づき、情報操作装置１は、Websocketクライアント処理部１８を使って情報出力装置２とWebsocketのコネクション(Websocketコネクション#2)を確立し、情報出力装置２に機器操作命令を送信する（ステップ２２０）。
なお、ここではPINと利用許可証を送信するWebsocketコネクション#1をWebsocketクライアント処理部１８ａを使って確立し、機器操作命令を送信するWebsocketコネクション#2をWebsocketクライアント処理部１８を使って確立する例について示したが、この他に以下のバリエーションが可能である。
(1)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部１８ａを使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図を図４９Ｂに示す。図４９Ａとの違いは、PFアプリ実行部２１内に機器命令送信部１９ａを備える点と、PFアプリ実行部２１から機器操作命令を送信するために、PFアプリ実行部２１がWebアプリ実行部２２からPINと利用許可証に加えて機器操作命令を取得する点と、PFアプリ実行部２１内の機器命令送信部１９ａがWebsocketクライアント処理部１８ａを使って機器命令を情報出力装置２に送信する点である。
(2)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部１８を使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図を図４９Ｃに示す。図４９Ａとの違いは、PFアプリ実行部２１内にWebsocketクライアント処理部１８ａと利用許可証送信部２５ａを備えず、Webアプリ実行部２２内に利用許可証送信部２５を備え、Websocketクライアント処理部１８を使って利用許可証を情報出力装置２に送信する点である。
上述の例ではPINと利用許可証を送信するWebsocketコネクションと機器操作命令を送信するWebsocketコネクションを別々のWebsocketコネクションとする例について説明したが、以下のように同一のWebsocketコネクションで送信してもよい。この場合の情報操作装置１と情報出力装置２の処理手順を示すシーケンス図を図５３Ｂに示す。
(3)PINと利用許可証と、機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部１８ａを使って確立する。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成は図４９Ｂと同一で良い。
(4)PINと利用許可証と、機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部１８を使って確立する。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成は図４９Ｃと同一で良い。
また、図５３ＢではPINと利用許可証を送信するコネクションと機器操作命令を送信するコネクションをWebsocketコネクションで送信していたが、HTTPコネクション（またはHTTPSコネクション）で送信してもよい。この場合の情報操作装置１と情報出力装置２の処理手順を示すシーケンス図を図５３Ｃに示す。
(5) PINと利用許可証と、機器操作命令を送信するコネクションはHTTP処理部１１を使って確立する。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成を図４９Ｄに示す。図４９Ｃとの違いはWebsocketクライアント処理部１８の代わりにHTTP処理部１１でPINと利用許可証と、機器操作命令を送信するようにしている点である。
なお、図４９ＣではWebsocketクライアント処理部１８内のドメイン付与部７０はWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行っていたが、図４９Ｄに示す情報操作装置１ではHTTP処理部１１がWebアプリ実行部２２で実行中のWebアプリのドメイン名をHTTPヘッダ（特許請求の範囲のコネクションのヘッダに対応）に付与する処理を行う。またこの情報操作装置１に対応する情報出力装置２の内部構成を図５１Ｂに示す。図５１Ａとの違いは、Websocketサーバ処理部の代わりにHTTPサーバ処理部を備えている点である。PINと利用許可証と機器操作命令はHTTPサーバ処理部５１によって受信される。さらに、HTTPヘッダに付与されているドメイン名はアプリ出所検査部４３に送られ、アプリ出所検査部４３によって利用許可証に含まれるドメインとの一致検査処理が行われる。
なお、図５３Ａの処理フローではPINの値が情報操作装置１と情報出力装置２との間で平文にてやりとりされていた。以下にPINを平文で送信せずにMAC値を送信して情報出力装置２がMAC値を検証することでPINが正しいかどうかを確かめる方法を示す。
図５４Ａは情報操作装置１の別の構成を示すブロック図である。PFアプリ実行部２１で実行されるPFアプリ内にMAC計算部（暗号情報生成部）６７を新たに備えている。
MAC計算部６７は、PFアプリ実行部２１内のWebsocketクライアント処理部１８で情報出力装置２に対して利用許可証を送信した応答として受信したチャレンジ（乱数）を、以下の計算式によってMAC値を計算する処理部である。
MAC値 = HMAC-SHA1(MAC鍵、PIN||チャレンジ)
すなわち、暗号アルゴリズムHMAC-SHA1を利用し、MAC鍵にて、PINとチャレンジの結合値の鍵付きハッシュ値を計算している。ここで、MAC鍵はMAC計算部６７にあらかじめ蓄積される秘密鍵であり、これと同じ値が情報出力装置２にも蓄積されている。PINはPIN保存部６０に蓄積されているPINの値である。MAC値を計算する際、Webアプリ実行部２２のWebアプリがPFアプリ実行部２１のPFアプリのMAC計算部６７にPINの値を通知する。
MAC計算部６７は、このMAC値を計算して、Webアプリ実行部２２で実行しているWebアプリにMAC値を送信する。Webアプリは機器操作命令を機器操作命令送信部１９に送信するのに先立ち、このMAC値を機器操作命令送信部１９に送信する。
図５５Ａは図５４Ａの情報操作装置１に対応する情報出力装置２の構成を示すブロック図である。図５１Ａに示す情報出力装置２とは、チャレンジ生成部６８を新たに備えている点と、PIN検査部５９の代わりにMAC検査部６９を備えている点が異なる。
チャレンジ生成部６８は、情報操作装置１から利用許可証を受信し、その利用許可証の検証が成功した場合に、チャレンジ(乱数)を生成して、情報操作装置１に送信する処理部である。なお、このチャレンジ乱数は情報操作装置１がMAC値を受信するか、Websocketコネクションが切断するまでは一時的に保存しておく。
MAC検査部６９は、情報操作装置１からMAC値が送信された場合、以下の計算式によってMAC値を計算する処理部である。
MAC値 = HMAC-SHA1(MAC鍵、PIN||チャレンジ)
ここで、MAC鍵は情報出力装置２のMAC検査部６９にあらかじめ記憶されている値である。チャレンジは、チャレンジ生成部６８によって生成されて情報操作装置１に送信した値である。PINはPIN管理部３９に記憶されている値を用いる。暗号アルゴリズムとしてHMAC-SHA1を利用する。MAC検査部６９は、この計算によって求めたMAC値と、情報操作装置１から送信されてきたMAC値が一致するか否かを判定し、判定結果を機器操作命令処理部３４に通知する。機器操作命令処理部３４は、MAC検査部６９が成功した場合に限り、以降情報操作装置１から送信されてくる機器操作命令を受け付ける。
図５６ＡはPINを平文で送信する代わりにMAC値を利用する場合の情報操作装置１と情報出力装置２の処理手順を示すシーケンス図である。
まず、Webアプリ#5がPINと保存しておいた利用許可証を取得し、入力受信部１５から命令を受信する処理（ステップＳ２３１）までは図５３Ａと同様の手順でよい。
つぎにWebアプリ#5はPFアプリ実行部２１が実行するPFアプリ９に利用許可証を送信するように依頼する（ステップＳ２３２）。PFアプリ９はWebsocketコネクション#1にて利用許可証を情報出力装置２に送信する（ステップＳ２３３）。具体的には、PFアプリ９の指示に基づき、情報操作装置１のWebsocketクライアント処理部１８ａはWebsocketのコネクション(Websocketコネクション#1)を確立し、情報出力装置２に利用許可証を送信する。
情報出力装置２は、利用許可証の署名が正しいかどうか署名検証処理を実行する（ステップＳ２３４）。もし署名検証に失敗すれば、以降の処理は行わず、機器操作命令を受け付けないか、あるいはWebsoketコネクションを切断してもよい。署名検証に成功すると、情報出力装置２はチャレンジ生成部６８を用いてチャレンジ(乱数)を生成し、Websocketコネクション#1にてチャレンジを情報操作装置１に送信する（ステップＳ２３５）。
情報操作装置１は、Websocketクライアント処理部１８ａにてチャレンジを受信すると、PFアプリ実行部２１のMAC計算部６７は受信したチャレンジの値と、MAC計算部６７に蓄積されているMAC鍵と、PIN保存部６０に蓄積されているPINの値を利用してMAC値を計算し（ステップＳ２３６）、Webアプリ#5にその結果を通知する。Webアプリ#5は機器命令送信部１９を経由してWebsocketコネクション#2にてMAC値を情報出力装置２に送信する（ステップＳ２３７）。具体的には、Webアプリ#5の指示に基づき、情報操作装置１のWebsocketクライアント処理部１８はWebsocketのコネクション(Websocketコネクション#2)を確立し、情報出力装置２にMAC値を送信する。
情報出力装置２は、MAC検査部６９は、MAC検査部６９に蓄積されているMAC鍵と、PIN管理部に蓄積されているPINの値と、チャレンジ生成部６８にて生成したチャレンジの値を利用してMAC値を計算し、情報操作装置１から受信したMAC値と一致するか判定処理を行い、判定結果を情報操作装置１に通知する（ステップＳ２３８）。もし一致していない場合、以降情報操作装置１から送信されてくる機器操作命令を受け付けないか、Websocketコネクションを切断する（ステップＳ２３９）。
情報操作装置１は情報出力装置２の判定結果が失敗すればエラー処理を行う。判定結果が成功だった場合（検証が成功した場合）、Webアプリ実行部２２のWebアプリはWebsocketコネクション#2にて機器操作命令を送信する（ステップＳ２４０、Ｓ２４１）。具体的には、Webアプリ#5の指示に基づき、情報操作装置１のWebsocketクライアント処理部１８はWebsocketのコネクション(Websocketコネクション#2)にて、情報出力装置２に機器操作命令を送信する。情報出力装置２は、受信した機器操作命令に従って機器を操作する（ステップＳ２４２）。
なお、ここでは利用許可証を送信するWebsocketコネクション#1をWebsocketクライアント処理部１８ａを使って確立し、MAC値と機器操作命令を送信するWebsocketコネクション#2をWebsocketクライアント処理部１８を使って確立する例について示したが、この他に以下のバリエーションが可能である。
(1)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部１８ａを使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図を図５４Ｂに示す。図５４Ａとの違いは、PFアプリ実行部内に機器命令送信部を備える点と、PFアプリ実行部から機器操作命令を送信するために、PFアプリ実行部がWebアプリ実行部から利用許可証、MAC値、PINに加えて機器操作命令を取得する点と、PFアプリ実行部内の機器命令送信部がWebsocketクライアント処理部１８ａを使って機器命令を情報出力装置２に送信する点である。
(2)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部１８を使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成の一例を示すブロック図を図５４Ｃに示す。図５４Ａとの違いは、PFアプリ実行部内にWebsocketクライアント処理部１８ａと利用許可証送信部２５ａを備えず、Webアプリ実行部２２内に利用許可証送信部２５を備え、Websocketクライアント処理部１８を使って利用許可証を情報出力装置２に送信する点である。
上述の例では利用許可証を送信するWebsocketコネクションと、MAC値および機器操作命令を送信するWebsocketコネクションを別々のWebsocketコネクションとする例について説明したが、以下のように同一のWebsocketコネクションに送信してもよい。この場合の情報操作装置１と情報出力装置２の処理手順を示すシーケンス図は図５３Ｂに示される。
(3)利用許可証と、MAC値と機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部１８ａを使って確立する。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成は図５４Ｂと同一で良い。
(4)利用許可証と、MAC値と機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部１８を使って確立する。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成は図５４Ｃと同一で良い。
なお、情報操作装置１は機器操作命令を送信するコネクション、すなわちWebsocketコネクション#2を確立してMAC値を送信する際（ステップＳ２３７）、Websocketクライアント処理部１８内のドメイン付与部７０がWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与して情報出力装置２に送信してもよい。さらに、情報出力装置２のアプリ出所検査部（検証部）４３は機器操作命令の送受信に使うWebsocketコネクション（Websocketコネクション#2）のWebsocketヘッダに含まれるドメイン名が利用許可証に含まれるWebアプリのドメイン名と一致するかの検査を行い、検査結果を機器操作命令処理部３４に通知する。一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。情報出力装置２の機器操作命令処理部は、検査が成功した時のみ以降の処理で情報操作装置１から送信される機器操作命令を受け付けるようにしてもよい。同様に、情報操作装置１は利用許可証を送信するコネクション、すなわちWebsocketコネクション#1を確立してMAC値を送信する際（ステップＳ２３３）、Websocketクライアント処理部１８内のドメイン付与部７０がWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与して情報出力装置２に送信してもよい。さらに、情報出力装置２のアプリ出所検査部（検証部）４３は機器操作命令の送受信に使うWebsocketコネクション（Websocketコネクション#1）のWebsocketヘッダに含まれるドメイン名が利用許可証に含まれるWebアプリのドメイン名と一致するかの検査を行い、検査結果を機器操作命令処理部３４に通知する。一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。情報出力装置２の機器操作命令処理部は、検査が成功した時のみ以降の処理で情報操作装置１から送信される機器操作命令を受け付けるようにしてもよい。
図５６Ａでは、利用許可証とチャレンジの送受信にはWebsocketコネクション#1を用い、ＭＡＣ値、その検査結果および機器操作命令の送受信にはWebsocketコネクション#2を用いる例を説明したが、図５６Ｂに示すように、これらすべての送受信を同一のWebsocketコネクション#3で行ってもよい。
また、図５６Ｃに示すように、これらすべての送受信を同一のHTTPコネクションで行ってもよい。この場合の情報操作装置１内のアプリ実行部１６、アプリ取得部１２、およびアプリキャッシュ部１３の内部構成を図５４Ｄに示す。図５４Ｃとの違いはWebsocketクライアント処理部１８の代わりにHTTP処理部１１で利用許可証とMAC値と、機器操作命令を送信するようにしている点である。なお、図５４ＣではWebsocketクライアント処理部１８内のドメイン付与部７０はWebアプリ実行部２２で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行っていたが、図５４Ｄに示す情報操作装置ではHTTP処理部１１がWebアプリ実行部２２で実行中のWebアプリのドメイン名をHTTPヘッダに付与する処理を行う。またこの情報操作装置１に対応する情報出力装置２の内部構成を図５５Ｂに示す。図５５Ａとの違いは、Websocketサーバ処理部４０の代わりにHTTPサーバ処理部５１を備えている点である。PINとMAC値と機器操作命令はHTTPサーバ処理部５１によって受信される。さらに、HTTPヘッダに付与されているドメイン名はアプリ出所検査部４３に送られ、アプリ出所検査部４３によって利用許可証に含まれるドメインとの一致検査処理が行われる。
ところで、図５２の処理フローでは、PIN入力用Webアプリ(Webアプリ#8)はローカルWebアプリ(Webアプリ#5)から遷移して実行されていたが、PIN入力用Webアプリ(Webアプリ#8)をローカルWebアプリ(Webアプリ#5)のインラインフレーム(iframe)として実行してもよい。その場合の処理手順を図５７から図５９Ａに示す。
まず、ステップＳ１７８までは図５２と同じである。PIN保存部６０にPINが存在しない場合、ローカルWebアプリ(Webアプリ#5)はインラインフレーム(iframe)を作成し（ステップＳ２５１）、そのインラインフレームの中でPIN入力用Webアプリ(Webアプリ#8)のURLを指定してWebアプリ#8の取得要求をPIN入力用Webアプリ配布サーバ４ａに送信する（ステップＳ２５２，Ｓ２５３）。具体的にはWebアプリ#5の指示に従って情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでPIN入力用Webアプリ(Webアプリ#8)の取得要求をWebアプリ配布サーバ４に送信する。情報操作装置１がPIN入力用Webアプリ配布サーバ４ａに送信するPIN入力用Webアプリの要求メッセージの一例を以下に示す。
http://example-PINserver.com/req_pin.php?appid=X&perm=xxxx&origin=xxxx&signature=xxxx&signature_method=rsa-sha1&url= example-Webserver.com/appid9
先ほどと異なり、PIN入力後のURLはPIN記録Webアプリ(Webアプリ#9)に移動するようにPIN記録Webアプリ(Webアプリ#9)がPIN入力用Webアプリ配布サーバ４ａに送信されている。
PIN入力用Webアプリ配布サーバ４ａの処理は図５２と同一である。情報操作装置１はインラインフレームの中でPIN入力用Webアプリ(Webアプリ#8)を実行する。PIN入力用Webアプリ(Webアプリ#8)は下記のようなプログラムを内包している。すなわち、PINが入力されると、インラインフレームはPIN記録Webアプリ(Webアプリ#9)に移動するように指示されている。
<form method="POST" action=" http://example-Webserver.com/appid9#">
<input type="text" name="PIN">
<input type="submit" value="送信">
PINが入力されると、インラインフレームは以下のURLでPIN記録Webアプリ(Webアプリ#9)に移動する（ステップＳ２５９）。具体的にはWebアプリ#8の指示に従って情報操作装置１のWebアプリ取得部２７はHTTP処理部３１を使ってHTTP（またはHTTPS）のプロトコルでPIN記録Webアプリ(Webアプリ#9)の取得要求をWebアプリ配布サーバ４に送信する。そしてPIN記録Webアプリ(Webアプリ#9)を実行する。
http://example-Webserver.com/appid9#pin
ここで”pin”は入力されたPINの値を示す。ハッシュフラグメントのためPINの値はWebアプリ配布サーバ４には送信されない。PIN記録Webアプリ(Webアプリ#9)は、PINの値をPIN保存部６０に保存する。この時、PINの値がWebアプリ#5で取得可能なようにURLの範囲を設定しておく。Webアプリ#5はPINの値をcookieから取得する際、利用許可証と同様に利用許可証アクセス制御部２３にてWebアプリ#5で取得可能かどうか判定され、取得可能である場合にはWebアプリ#5はPIN保存部６０からPINを取得する事ができる。PINの保存が完了すると、PIN記録Webアプリ(Webアプリ#9)はPINの保存が完了した事を親フレームであるWebアプリ#5に通知する。Webアプリ#5は自らが生成したインラインフレームを終了させる。つまり、PIN記録Webアプリ(Webアプリ#9)は終了する。その後、Webアプリ#5は先ほどPIN記録Webアプリ(Webアプリ#9)が蓄積したPINをPIN保存部６０から取得する。この時、利用許可証アクセス制御部２３にてPINを取得するWebアプリのドメインが検査されるが、PIN記録Webアプリ(Webアプリ#9)はWebアプリ#5で取得可能なようにURLの範囲を設定しておいたため、Webアプリ#5はPINを取得することができる。Webアプリ#5はPINと保存しておいた利用許可証を取得し（ステップＳ２６４）、その後は図５６で示した処理フローと同じ手順を実行する。
なお、図５８Ａ、図５９ＡではWebsocketコネクションを用いて利用許可証、チャレンジ（乱数）、MAC値、機器操作命令を送受信する場合の例について示したが、HTTPコネクション（またはHTTPSコネクション）で送受信してもよい。この場合の処理フローを図５８Ｂ、図５９Ｂに示す。コネクションに用いるプロトコルが異なる以外は図５８Ａ、図５９Ａと同一である。
このように、第５の実施形態では、Webアプリごとに許可される機器操作命令を分け、同一ドメイン内の複数のWebアプリが同一の利用許可証を利用するが、情報操作装置１はPIN入力用WebアプリをPIN入力用Webアプリ配布サーバ４ａから取得する構成をとる。さらに、情報操作装置１から情報処理装置２にPINを平文で送信するのではなく、情報操作装置１と情報出力装置２が共有する秘密鍵を用いてPINを暗号化したMAC値を計算して、このMAC値を情報操作装置１から情報出力装置２に送信するため、情報操作装置１と情報出力装置２の間に不正な機器が存在していたとしても、その不正な機器にPINが渡るおそれがなく、利用者のPINを保護する事が可能となる。
上述した実施形態で説明した情報操作装置１と情報出力装置２、Webアプリ配布サーバ４、PFアプリ配布サーバ５、利用許可証配布サーバ６の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、装置・サーバの少なくとも一部の機能を実現するプログラムをフロッピーディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の携帯可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
また、情報操作装置１と情報出力装置２、Webアプリ配布サーバ４、PFアプリ配布サーバ５、利用許可証配布サーバ６の少なくとも一部の機能を実現するプログラムを、インターネット８等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット８等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
ここで、上述した実施形態に係る発明の利用場面について、説明する。
近年、タブレットやスマートフォンと呼ばれる無線LANや3G網を経由してインターネットに接続する機能を有する端末が普及している。それらの端末の多くはWebブラウザを備え、タッチパッドによって文字を入力したり、画面をスクロールしたり、Webページの中に埋め込まれたリンク(ハイパーリンク)を選択したりする操作を容易に行うことができる。また、インターネットからアプリケーションソフトウェア（以下、アプリ）をダウンロードすることにより、端末を自由にカスタマイズしたり、機能を追加・拡張したりすることができる。
その一方で、近年では、放送波を受信するだけでなく、インターネット接続機能とWebブラウザ機能を備えて、インターネットから映像コンテンツを受信できるようにしたデジタルＴＶが普及しつつある。デジタルＴＶはデジタル放送など高精細の動画を大画面で再生する機能は優れているものの、デジタルＴＶを操作するリモートコントローラ（以下、リモコン）はもともと放送番組を選局したり音量を調節したりすることを目的としているため、操作するための赤外線リモコンも一般的にはダイレクトチャンネル選局やアップダウン操作を行うキーしか備えていない。
しかし、Webブラウザ操作などのインターネット機能を利用したり、ＴＶに録画したコンテンツリストの一覧から特定のコンテンツを選択したりするような操作を行うには、複数のリストの中から任意の項目を選択したり、PCのマウスのように画面上の任意の部分をポイント(クリック)したりする必要があり、従来の赤外線リモコンでは機能が不十分である。
一方、スマートフォンやタブレットは、インターネットに接続することを前提としており、無線LANインタフェースが標準搭載されている場合が多い。また、タッチパッドインタフェースを備えているため、任意のポイントを選択(クリック)したり、画面の任意の部分を拡大・縮小させたりすること(ピンチ操作)を容易に行うことができる。そこで、スマートフォンとＴＶを無線LANインタフェースで接続し、スマートフォンやタブレットのタッチパッドインタフェースをＴＶのリモコン機能として利用することができれば、ユーザにとって便利である。
しかし、ここで考えなければいけないのはセキュリティである。赤外線リモコンの場合は赤外線という物理特性上、操作可能なＴＶとリモコン間の距離が制限される。また、一般的に赤外線リモコンは、組立後に機能を追加することはできない。
しかしながら、スマートフォンやタブレットとＴＶを無線LANインタフェースで接続し、スマートフォンやタブレットにダウンロードしたアプリからＴＶを操作することを考えた場合、不正なアプリがＴＶを操作したり、ユーザが意図しない操作を勝手にリモコンアプリがＴＶに対して行ったりするおそれがあり、そのような場合に、上述した実施形態に係る発明は、ユーザの許諾なしに情報出力装置が勝手に操作されることを防止しつつ、情報操作装置から情報出力装置を操作できるようにして利便性を向上させることができる。
本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。
１ 情報操作装置、２ 情報出力装置、３ 情報処理システム、４ Webアプリ配布サーバ、５ PFアプリ配布サーバ、６ 利用許可証配布サーバ、１１ HTTP処理部、１２ アプリ取得部、１３ アプリキャッシュ部、１４ 利用許可証取得部、１５ 入力受信部、１６ アプリ実行部、１７ 画面出力部、１８ Websocketクライアント処理部、１９ 機器操作命令送信部、２０ 機器検索処理部、２１ PFアプリ実行部、２２ Webアプリ実行部、２３ 利用許可証アクセス制御部、２４ 利用許可証蓄積部、２５ 利用許可証送信部、２６ PFアプリ取得部、２７ Webアプリ取得部、３０ アプリ蓄積部、３１ HTTP処理部、３２ チューナ部、３３ 画面出力部、３４ 機器操作命令処理部、３５ リモコン命令処理部、３６ 固有ID管理部、３７ ID登録要求送信部、３８ 公開鍵管理部、３９ PIN管理部、４０ Websocketサーバ処理部、４１ 機器検索処理部、４２ 利用許可証検査部、４３ アプリ出所検査部

Claims (18)

  1. 第１通信装置から機器操作用ウェブアプリケーションおよび暗証コード入力用ウェブアプリケーションを取得するための接続確立処理を行う第１コネクション部と、
    前記機器操作命令の送信を指示する前記機器操作用ウェブアプリケーションが正規の前記第１通信装置から取得されたものであることを証明する利用許可証と、情報出力装置を操作するための機器操作命令と、を前記情報出力装置に送信するための接続確立処理を行う第２コネクション部と、
    前記第２コネクション部で情報出力装置とコネクションを確立し、前記コネクションを用いて前記情報出力装置を操作するための機器操作命令を送信する際に、前記機器操作用ウェブアプリケーションの送信元である前記第１通信装置のドメイン名を前記コネクションのヘッダに付与するドメイン名付与部と、
    前記第１通信装置から前記第１コネクション部を介して取得した前記暗証コード入力用ウェブアプリケーションを実行するとともに、前記第１コネクション部を介して取得した前記機器操作用ウェブアプリケーションを実行し、前記機器操作用ウェブアプリケーションに対応する前記ウェブアプリケーションの利用許可証を前記第１通信装置から受信するアプリケーション実行部と、
    前記実行された暗証コード入力用ウェブアプリケーションに応じてユーザが入力した前記暗証コード、および乱数に基づいて、前記情報出力装置と共有する共通鍵を用いて暗号情報を生成して前記情報出力装置に送信する暗号情報生成部と、
    前記第２コネクション部を介して前記情報出力装置に前記利用許可証と前記暗号情報とを送信し、前記情報出力装置が検査した前記利用許可証と前記暗号情報との検査結果が正しければ前記機器操作用ウェブアプリケーションに含まれる前記機器操作命令を、前記第２コネクション部を介して前記情報出力装置に送信するクライアント処理部と、を備えることを特徴とする情報操作装置。
  2. 第１通信装置からウェブアプリケーションを取得するための接続確立処理を行う第１コネクション部と、
    情報出力装置を操作するための機器操作命令と前記機器操作命令の送信を指示する前記ウェブアプリケーションが正規の前記第１通信装置から取得されたものであることを証明する利用許可証とを前記情報出力装置に送信するための接続確立処理を行う第２コネクション部と、
    前記第１コネクション部を介して取得したウェブアプリケーションを実行し、前記ウェブアプリケーションに含まれる命令に従って、前記ウェブアプリケーションを識別するための第１識別情報と前記情報出力装置を識別するための第２識別情報とユーザが入力した前記情報出力装置に対応付けられた識別情報である第３識別情報とを含む前記ウェブアプリケーションの利用許可証送信要求メッセージを、前記第１コネクション部を介して前記利用許可証を発行する第２通信装置に送信するとともに、これらの情報に基づいて前記第２通信装置が発行した前記利用許可証を受信するアプリケーション実行部と、
    前記ウェブアプリケーションの利用許可証と前記機器操作命令とを、前記第２コネクション部を介して前記情報出力装置に送信するクライアント処理部と、を備えることを特徴とする情報操作装置。
  3. 前記利用許可証送信要求メッセージは、前記第１識別情報と、前記第２識別情報と、ユーザが入力した前記情報出力装置に固有の暗証コードと、を含み、
    前記利用許可証は、前記第１識別情報と、前記第２識別情報、前記ウェブアプリケーションの取得先を示す出所情報および前記暗証コードを前記第２通信装置の秘密鍵で公開鍵暗号を行って生成した署名情報と、を含むことを特徴とする請求項２に記載の情報操作装置。
  4. 前記利用許可証は、前記ウェブアプリケーションの取得先を示す出所情報を含み、かつ許可される前記機器操作命令のリスト情報を含み得ることを特徴とする請求項１または２に記載の情報操作装置。
  5. 前記アプリケーション実行部は、前記ウェブアプリケーションの取得先を示すＵＲＬアドレスと、前記アプリケーション実行部が受信した前記利用許可証に含まれる出所情報とが一致するか否かを検証する検証部を備え、
    前記第２コネクション部は、前記ウェブアプリケーションの取得先を示すＵＲＬアドレスと、前記アプリケーション実行部が受信した前記利用許可証に含まれる出所情報とが一致しない場合は、前記機器操作命令および前記利用許可証を前記情報出力装置に送信するための接続確立を禁止することを特徴とする請求項４に記載の情報操作装置。
  6. 前記第２コネクション部は、前記機器操作命令の送信に先立ち、前記ウェブアプリケーションの取得先である前記第１通信装置のＵＲＬアドレスのドメイン名をヘッダに付与して送信することを特徴とする請求項２に記載の情報操作装置。
  7. 前記第１コネクション部を介して、第３通信装置から少なくともＵＲＬとオペレーティングシステムまたは仮想マシンに依存する命令を含む実行ファイルとを含むアプリケーションを取得する第１アプリ取得部を備え、
    前記アプリケーション実行部は、
    前記第１コネクション部を介して前記第１アプリ取得部で前記第３通信装置から取得したアプリケーションを実行して、前記アプリケーションに含まれる命令に従って、対応するウェブアプリケーションの取得先を示すＵＲＬアドレスを取得し、第２アプリ実行部を起動する第１アプリ実行部と、
    第２アプリ実行部は前記第１アプリ実行部が取得したＵＲＬアドレスから前記第１コネクション部を介して、前記対応するウェブアプリケーションを取得して実行するブラウザ部と、を有することを特徴とする請求項１または２に記載の情報操作装置。
  8. 前記情報出力装置の識別情報を取得するための接続確立処理を行う第３コネクション部を備え、
    前記第２コネクション部は、前記第３コネクション部にて取得した前記情報出力装置の識別情報に基づいて、前記機器操作命令および前記利用許可証を前記情報出力装置に送信するための接続確立処理を行うことを特徴とする請求項２に記載の情報操作装置。
  9. 前記第２通信装置は、前記情報出力装置の内部に設けられることを特徴とする請求項２に記載の情報操作装置。
  10. 前記第１コネクション部は、HTTPコネクションの接続確立処理を行い、
    前記第２コネクション部は、ウェブソケットコネクションの接続確立処理を行うことを特徴とする請求項１または２に記載の情報操作装置。
  11. 前記クライアント処理部は、前記アプリケーション実行部に統合され、
    前記アプリケーション実行部は、前記クライアント処理部の処理を実行することを特徴とする請求項１乃至１０のいずれかに記載の情報操作装置。
  12. 情報操作装置から利用許可証、機器操作命令、および暗号情報を受信するための接続確立処理を行うコネクション部と、
    前記コネクション部で前記機器操作命令を受信する際に、機器操作用ウェブアプリケーションの送信元を示すドメイン名を受信し、該ドメイン名が前記利用許可証に含まれるドメイン名に含まれるか否かを検査するアプリ出所検査部と、
    暗証コードを管理する暗証コード管理部と、
    前記利用許可証に含まれる署名を検証するための公開鍵を管理する公開鍵管理部と、
    前記情報操作装置から受信した前記利用許可証の内容が正しいか否かを前記公開鍵で検証する利用許可証検査部と、
    乱数を生成するチャレンジ生成部と
    前記暗証コード、前記乱数、前記情報出力装置と共有する共通鍵を用いて暗号情報を生成し、前記情報操作装置から受信した前記暗号情報と一致するか否かを検査する暗号情報検査部と、
    前記アプリ出所検査部と、前記暗号情報検査部の検査に成功した場合に限り、前記情報操作装置から受信した前記機器操作命令を実行する機器操作命令処理部と、を備える事を特徴とする情報出力装置。
  13. 第２通信装置との間で通信を行うための接続確立処理を行う第１コネクション部と、
    情報操作装置から送信された機器操作命令と、前記機器操作命令の送信を指示するウェブアプリケーションが正規の第１通信装置から取得されたものであることを証明する利用許可証と、前記機器操作命令の送信を指示する前記ウェブアプリケーションの取得先を示す出所情報と、を受信するための接続確立処理を行う第２コネクション部と、
    前記第１コネクション部を介して、自装置に固有の識別情報を前記第１通信装置に登録するとともに、その応答として公開鍵を受信して管理する公開鍵管理部と、
    暗証コードを管理する暗証コード管理部と、
    前記第２コネクション部を介して受信した前記利用許可証に付属する署名を前記公開鍵および前記暗証コードを用いて検証する利用許可証検査部と、
    前記第２コネクション部を介して受信し、コネクションのヘッダに含まれる前記機器操作命令の送信を指示する前記ウェブアプリケーションの取得先を示す出所情報と、前記利用許可証に含まれる前記ウェブアプリケーションの取得先情報とが一致するか否かを検査する出所検査部と、
    前記利用許可証検査部による検証と前記出所検査部による検査とに成功した場合に限り、前記機器操作命令の実行を許可する機器操作命令処理部と、を備えることを特徴とする情報出力装置。
  14. 前記情報操作装置からの要求に応答して、自装置の識別情報を送信するための接続確立処理を行う第３コネクション部を備えることを特徴とする請求項１３に記載の情報出力装置。
  15. 前記第１コネクション部は、HTTPコネクションの接続確立処理を行い、
    前記第２コネクション部は、ウェブソケットコネクションの接続確立処理を行うことを特徴とする請求項１２乃至１４のいずれかに記載の情報出力装置。
  16. 前記利用許可証は、操作命令リストを含み、
    前記利用許可証検査部による検証と前記出所検査部による検査とに成功した場合、前記情報操作装置から送信された前記機器操作命令が前記操作命令リストに含まれているか否かを検査し、含まれている場合に限り、前記機器操作命令の実行を許可する機器操作命令処理部と、を備えることを特徴とする請求項１２乃至１５のいずれかに記載の情報出力装置。
  17. 第１通信装置から機器操作用ウェブアプリケーションおよび暗証コード入力用ウェブアプリケーションを取得するための接続確立処理を行う第１コネクション部と、
    前記機器操作用ウェブアプリケーションの取得先を示す第１出所情報を含む利用許可証と、情報出力装置を操作するための機器操作命令と、を前記情報出力装置に送信するための接続確立処理を行う第２コネクション部と、
    前記第２コネクション部で情報出力装置を操作するための機器操作命令を送信する際に、前記機器操作用ウェブアプリケーションの送信元である前記第１通信装置のドメイン名を付与するドメイン名付与部と、
    前記第１通信装置から前記第１コネクション部を介して取得した前記暗証コード入力用ウェブアプリケーションを実行するとともに、前記第１コネクション部を介して取得した前記機器操作用ウェブアプリケーションを実行し、前記機器操作用ウェブアプリケーションに対応する前記ウェブアプリケーションの利用許可証を前記第１通信装置から受信するアプリケーション実行部と、
    前記実行された暗証コード入力用ウェブアプリケーションに応じてユーザが入力した前記暗証コード、および乱数に基づいて、前記情報出力装置と共有する共通鍵を用いて暗号情報を生成して前記情報出力装置に送信する暗号情報生成部と、
    前記第２コネクション部を介して前記情報出力装置に前記利用許可証と前記情報出力装置から前記暗号情報を送信し、検査結果が正しければ前記機器操作用ウェブアプリケーションに含まれる前記機器操作命令を、前記第２コネクション部を介して前記情報出力装置に送信するクライアント処理部と、を備え、
    前記クライアント処理部は、実行中の前記機器操作用ウェブアプリケーションの取得先を示す出所情報であることを特徴とする情報操作装置。
  18. 情報操作装置から情報出力装置に、前記情報出力装置の操作を行うための機器操作命令を送信する情報処理方法において、
    第１通信装置から機器操作用ウェブアプリケーションおよび暗証コード入力用ウェブアプリケーションを取得するための第１コネクション部の接続確立処理を行うステップと、
    前記機器操作命令の送信を指示する前記機器操作用ウェブアプリケーションが正規の前記第１通信装置から取得されたものであることを証明する利用許可証と情報出力装置を操作するための機器操作命令を前記情報出力装置に送信するための第２コネクション部の接続確立処理を行うステップと、
    前記第２コネクション部で情報出力装置を操作するための機器操作命令を送信する際に、前記機器操作用ウェブアプリケーションの送信元である前記第１通信装置のドメイン名を付与するステップと、
    前記第１通信装置から前記第１コネクション部を介して取得した前記暗証コード入力用ウェブアプリケーションを実行するとともに、前記第１コネクション部を介して取得した前記機器操作用ウェブアプリケーションを実行し、前記機器操作用ウェブアプリケーションに対応する前記ウェブアプリケーションの利用許可証を前記第１通信装置から受信するステップと、
    前記実行された暗証コード入力用ウェブアプリケーションに応じてユーザが入力した前記暗証コード、および乱数に基づいて、前記情報出力装置と共有する共通鍵を用いて暗号情報を生成して前記情報出力装置に送信するステップと、
    前記第２コネクション部を介して前記情報出力装置に前記利用許可証と前記暗号情報とを送信し、前記情報出力装置が検査した前記利用許可証と前記暗号情報との検査結果が正しければ前記機器操作用ウェブアプリケーションに含まれる前記機器操作命令と前記利用許可証とを、前記第２コネクション部を介して前記情報出力装置に送信するステップと、を備えることを特徴とする情報処理方法。
JP2012181067A 2012-08-17 2012-08-17 情報操作装置、情報出力装置および情報処理方法 Active JP5662391B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012181067A JP5662391B2 (ja) 2012-08-17 2012-08-17 情報操作装置、情報出力装置および情報処理方法
US13/967,616 US9391961B2 (en) 2012-08-17 2013-08-15 Information operating device, information output device, and information processing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012181067A JP5662391B2 (ja) 2012-08-17 2012-08-17 情報操作装置、情報出力装置および情報処理方法

Publications (2)

Publication Number Publication Date
JP2014038521A true JP2014038521A (ja) 2014-02-27
JP5662391B2 JP5662391B2 (ja) 2015-01-28

Family

ID=50100953

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012181067A Active JP5662391B2 (ja) 2012-08-17 2012-08-17 情報操作装置、情報出力装置および情報処理方法

Country Status (2)

Country Link
US (1) US9391961B2 (ja)
JP (1) JP5662391B2 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015228076A (ja) * 2014-05-30 2015-12-17 三菱電機株式会社 設備機器システム、および、コントローラ
US9544644B2 (en) 2013-10-03 2017-01-10 Kabushiki Kaisha Toshiba Broadcast receiving device and information processing system
JP2017130052A (ja) * 2016-01-20 2017-07-27 株式会社リコー 情報処理システム、情報処理方法、情報処理装置および情報処理プログラム
JP2020123978A (ja) * 2016-03-18 2020-08-13 株式会社リコー 情報処理システム、情報処理装置、情報処理方法、及びプログラム
JPWO2020144758A1 (ja) * 2019-01-09 2021-03-11 三菱電機株式会社 クライアント装置
CN113381061A (zh) * 2020-03-10 2021-09-10 精工爱普生株式会社 固体电解质、固体电解质的制造方法及复合体
WO2023219086A1 (ja) * 2022-05-13 2023-11-16 渡辺浩志 オンライン認証技術

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9049176B2 (en) 2011-06-22 2015-06-02 Dropbox, Inc. File sharing via link generation
US9219607B2 (en) * 2013-03-14 2015-12-22 Arris Technology, Inc. Provisioning sensitive data into third party
US20150052256A1 (en) * 2013-08-15 2015-02-19 Unisys Corporation Transmission of network management data over an extensible scripting file format
US9853956B2 (en) * 2014-02-11 2017-12-26 Texas Instruments Incorporated JSON encryption and hashing with indication added to key-value
JP6379699B2 (ja) * 2014-06-05 2018-08-29 株式会社リコー 情報処理装置、情報処理システム、情報処理プログラム、および情報処理方法
WO2016114822A1 (en) 2015-01-16 2016-07-21 Cyph Inc. A system and method of cryprographically signing web applications
US9942209B2 (en) * 2015-04-27 2018-04-10 Intel Corporation Technologies for secure extensible inter-device I/O redirection across a network
KR101637863B1 (ko) * 2016-01-05 2016-07-08 주식회사 코인플러그 본인인증용 정보 보안 전송시스템 및 방법
CN107197077B (zh) * 2016-03-15 2021-02-02 阿里巴巴集团控股有限公司 设备间通信方法、装置和系统
US10445035B2 (en) * 2016-04-26 2019-10-15 Canon Kabushiki Kaisha Control method and recording medium
US10230700B2 (en) * 2016-08-09 2019-03-12 Lenovo (Singapore) Pte. Ltd. Transaction based message security
EP3435265A1 (de) * 2017-07-25 2019-01-30 Skidata Ag Verfahren zur sicheren authentifizierung bei mit einem server verbindbaren geräten, insbesondere bei zugangskontrollvorrichtungen oder bezahl- bzw. verkaufsautomaten eines zugangskontrollsystems
CN108259486B (zh) * 2018-01-10 2020-12-01 河南芯盾网安科技发展有限公司 基于证书的端到端密钥交换方法
US11025628B2 (en) * 2018-04-17 2021-06-01 Cisco Technology, Inc. Secure modification of manufacturer usage description files based on device applications
US11057368B2 (en) * 2018-07-19 2021-07-06 Fortanix, Inc. Issuing a certificate based on an identification of an application
CN109905380B (zh) * 2019-02-15 2021-07-27 腾讯科技（深圳）有限公司 一种分布式系统中的节点控制方法和相关装置
US10601806B1 (en) * 2019-02-22 2020-03-24 Capital One Services, Llc Runtime identity confirmation for restricted server communication control
DE102019130067B4 (de) * 2019-11-07 2022-06-02 Krohne Messtechnik Gmbh Verfahren zur Durchführung einer erlaubnisabhängigen Kommunikation zwischen wenigstens einem Feldgerät der Automatisierungstechnik und einem Bediengerät
CN112689014A (zh) * 2020-12-24 2021-04-20 百果园技术(新加坡)有限公司 一种双全工通信方法、装置、计算机设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002162899A (ja) * 2000-11-27 2002-06-07 Hitachi Ltd プログラム認証機能付き電子機器およびプログラム認証処理方法
JP2003230186A (ja) * 2002-02-05 2003-08-15 Canon Inc 遠隔操作システム、その制御方法および該制御方法を実現するためのプログラム
JP2005102163A (ja) * 2003-09-03 2005-04-14 Sony Corp 機器認証システム、機器認証サーバ、端末機器、機器認証方法、機器認証プログラム、及び記憶媒体
JP2007141091A (ja) * 2005-11-21 2007-06-07 Nippon Telegr & Teleph Corp <Ntt> 遠隔操作支援システムとそのユーザ装置及びエージェント装置、並びに遠隔操作支援方法
WO2008093868A1 (ja) * 2007-02-02 2008-08-07 Nec Corporation 周辺装置などの被制御装置を制御する制御システム、制御方法、及び制御用コンピュータプログラム
JP2009539172A (ja) * 2006-06-30 2009-11-12 ポスデータ カンパニー リミテッド ネットワーク基盤のｄｖｒシステムにおけるｄｖｒサーバー及びモニタリング対象端末接近制御方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760746B1 (en) * 1999-09-01 2004-07-06 Eric Schneider Method, product, and apparatus for processing a data request
US7484089B1 (en) * 2002-09-06 2009-01-27 Citicorp Developmemt Center, Inc. Method and system for certificate delivery and management
US7565536B2 (en) * 2005-09-02 2009-07-21 Gemalto Inc Method for secure delegation of trust from a security device to a host computer application for enabling secure access to a resource on the web
DE102010030590A1 (de) * 2010-06-28 2011-12-29 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Zertifikats
JP5073032B2 (ja) 2010-09-27 2012-11-14 株式会社東芝 情報出力装置、情報処理システムおよび情報処理方法
JP5686046B2 (ja) * 2011-03-31 2015-03-18 富士通株式会社 アプリ提供システム、アプリ提供方法及びアプリ提供プログラム
JP5575071B2 (ja) 2011-08-26 2014-08-20 株式会社東芝 情報処理装置、情報処理方法、およびプログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002162899A (ja) * 2000-11-27 2002-06-07 Hitachi Ltd プログラム認証機能付き電子機器およびプログラム認証処理方法
JP2003230186A (ja) * 2002-02-05 2003-08-15 Canon Inc 遠隔操作システム、その制御方法および該制御方法を実現するためのプログラム
JP2005102163A (ja) * 2003-09-03 2005-04-14 Sony Corp 機器認証システム、機器認証サーバ、端末機器、機器認証方法、機器認証プログラム、及び記憶媒体
JP2007141091A (ja) * 2005-11-21 2007-06-07 Nippon Telegr & Teleph Corp <Ntt> 遠隔操作支援システムとそのユーザ装置及びエージェント装置、並びに遠隔操作支援方法
JP2009539172A (ja) * 2006-06-30 2009-11-12 ポスデータ カンパニー リミテッド ネットワーク基盤のｄｖｒシステムにおけるｄｖｒサーバー及びモニタリング対象端末接近制御方法
WO2008093868A1 (ja) * 2007-02-02 2008-08-07 Nec Corporation 周辺装置などの被制御装置を制御する制御システム、制御方法、及び制御用コンピュータプログラム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9544644B2 (en) 2013-10-03 2017-01-10 Kabushiki Kaisha Toshiba Broadcast receiving device and information processing system
JP2015228076A (ja) * 2014-05-30 2015-12-17 三菱電機株式会社 設備機器システム、および、コントローラ
JP2017130052A (ja) * 2016-01-20 2017-07-27 株式会社リコー 情報処理システム、情報処理方法、情報処理装置および情報処理プログラム
JP2020123978A (ja) * 2016-03-18 2020-08-13 株式会社リコー 情報処理システム、情報処理装置、情報処理方法、及びプログラム
JPWO2020144758A1 (ja) * 2019-01-09 2021-03-11 三菱電機株式会社 クライアント装置
CN113381061A (zh) * 2020-03-10 2021-09-10 精工爱普生株式会社 固体电解质、固体电解质的制造方法及复合体
WO2023219086A1 (ja) * 2022-05-13 2023-11-16 渡辺浩志 オンライン認証技術

Also Published As

Publication number Publication date
JP5662391B2 (ja) 2015-01-28
US9391961B2 (en) 2016-07-12
US20140052993A1 (en) 2014-02-20

Similar Documents

Publication Publication Date Title
JP5662391B2 (ja) 情報操作装置、情報出力装置および情報処理方法
US9122544B2 (en) Information processing apparatus, resource providing apparatus, and information processing system
JP5597230B2 (ja) 情報操作装置、情報出力装置および情報操作プログラム
JP5792732B2 (ja) モジュラーデバイス認証フレームワーク
US8776203B2 (en) Access authorizing apparatus
US9338164B1 (en) Two-way authentication using two-dimensional codes
US7979913B2 (en) Home network system and method therefor
US9979725B1 (en) Two-way authentication using two-dimensional codes
EP2106087A1 (en) Method and apparatus for handling security level of device on network
JP5248505B2 (ja) 制御デバイス、再生デバイス、及び許可サーバ
US20090300360A1 (en) Application setting terminal, application executing terminal, and setting information managing server
JP6296253B2 (ja) セキュリティ更新可能性のために配布されるホワイトリスト
JP6109617B2 (ja) 情報出力装置、情報操作装置、およびプログラム
JP6786830B2 (ja) 証明書管理システム、証明書管理方法及びプログラム
US9544644B2 (en) Broadcast receiving device and information processing system
JP5834118B2 (ja) 情報操作装置、情報出力装置および情報操作プログラム
JP6351000B2 (ja) 放送受信システム及び放送通信連携システム
JP6044850B2 (ja) 情報端末、情報処理方法及び制御プログラム
JP2016028532A (ja) 情報操作装置、情報出力装置および情報操作プログラム
WO2023080075A1 (ja) Ｎｆｔ発行方法、コンピュータ、及びプログラム
JP6334275B2 (ja) 認証装置、認証方法、認証プログラム、及び認証システム
JP2017098697A (ja) 署名検証システム及び署名検証方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140214

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140716

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140722

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140922

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141107

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141204

R151 Written notification of patent or utility model registration

Ref document number: 5662391

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151