(第1の実施形態)
図1は第1の実施形態に係る情報操作装置1と情報出力装置2を備えた情報処理システム3の概略構成を示す図である。図1の情報処理システム3は、放送波に含まれるAVデータや文字情報を映像として出力可能な情報出力装置2と、情報出力装置2を操作する情報操作装置1と、ウェブアプリケーション(以下、Webアプリ)を配布するWebアプリ配布サーバ4と、プラットホームに固有のアプリ(以下、PFアプリ)を配布するPFアプリ配布サーバ5と、情報出力装置2を操作する時に必要となる利用許可証を配布する利用許可証配布サーバ6と、を備えている。
ここで、利用許可証とは、情報出力装置2に機器操作命令を送信する権利を有するWebアプリ開発者が開発した正規のWebアプリであり、なおかつ正規のWebアプリ配布サーバ4から配布されたものであることを証明する情報であり、利用許可証はWebアプリごとに発行される。すべてのWebアプリに対応して利用許可証が発行されるわけではなく、後述するように、利用許可証を利用できるWebアプリは制限されている。
情報操作装置1と情報出力装置2は、有線または無線のネットワーク7で接続されており、情報操作装置1は情報出力装置2の各種機能を操作するための機器操作命令を情報出力装置2に送信する。また、情報操作装置1は、上述した利用許可証を情報出力装置2に送信し、機器操作命令が正規のWebアプリからのものであることを情報出力装置2に把握させる。
情報操作装置1は、インターネット8を介してWebアプリ配布サーバ4、PFアプリ配布サーバ5、および利用許可証配布サーバ6と接続されており、それぞれWebアプリ、PFアプリ、および利用許可証を受信する。情報出力装置2はインターネット8を介して利用許可証配布サーバ6と接続されている。
情報操作装置1から情報出力装置2に機器操作命令を送るための物理レイヤとリンクレイヤとして、赤外線、IEEE802.11規格に準拠した無線LAN、イーサネット(登録商標)などの種々の通信形態が採用可能であるが、図1では一例として無線LAN7を示している。
なお、これらインタフェースが有線であるか無線であるかは問わない。ネットワークレイヤとして、インターネットプロトコル(IP)を使用する場合は、IPv4でもよいし、IPv6でもよい。インタフェースがIPの場合には、情報操作装置1と情報生成装置の間に不図示の無線アクセスポイント機器やルータ機器等が接続されていてもよい。ここでは一例として、情報操作装置1から情報出力装置2に無線LAN7を介して機器操作命令を送る例を説明するが、ネットワーク形態は特に問わない。
ここで、機器操作命令とは、情報出力装置2の機能を制御する命令であり、例えば、情報出力装置2が有するチューナ部を制御する命令(チューナ部に対する選局命令など)や音量調節命令、入力切り替え命令(放送チューナ入力から外部入力に切り替える等)などを指す。情報出力装置2が放送コンテンツを録画・蓄積する機能を備えている場合は、機器操作命令に録画コンテンツの一覧表示命令、指定した録画コンテンツに対する再生命令、指定した録画コンテンツの特定の位置から再生を指示する再生命令、指定した録画コンテンツに対する削除命令なども含まれる。
情報操作装置1は、情報出力装置2と通信するコネクションとは別に、Webアプリ配布サーバ4、PFアプリ配布サーバ5、および利用許可証配布サーバ6と通信するためのIPインタフェースを備えている。同様に、情報出力装置2も情報操作装置1と通信するコネクションとは別に、利用許可証配布サーバ6と通信するためのIPインタフェースを備えている。これらIPインタフェースは、後述するHTTP処理部に内蔵される。
IPインタフェースの物理レイヤとリンクレイヤとして、IEEE802.11規格に準拠した無線LANやイーサネットなど種々の通信形態が採用可能である。ネットワークレイヤとして、インターネットプロトコル(IP)を使用する場合は、IPv4でもよいし、IPv6でもよい。
また、情報操作装置1とWebアプリサーバ、PFアプリ配布サーバ5、利用許可証配布サーバ6は、例えばインターネット8を介してインターネットプロトコル(IP)で接続されている。同様に情報出力装置2と利用許可証配布サーバ6は、例えばインターネット8を介してIPで接続されている。
情報操作装置1は、PFアプリ配布サーバ5からPFアプリをダウンロードし、Webアプリ配布サーバ4からWebアプリをそれぞれダウンロードして実行する。情報操作装置1は複数のPFアプリ配布サーバ5からそれぞれ異なる複数のPFアプリをダウンロードしたり、複数のWebアプリ配布サーバ4からそれぞれ異なる複数のWebアプリをダウンロードしたりしてもよい。
図2は第1の実施形態に係る情報操作装置1の内部構成を示すブロック図である。図2の情報操作装置1は、アプリ蓄積部30、HTTP処理部11、アプリ取得部12、アプリキャッシュ部13、利用許可証取得部14、入力受信部15、アプリ実行部16、画面出力部17、Websocketクライアント処理部(クライアント処理部)18、機器操作命令送信部19、リダイレクト処理部、機器検索処理部20、アプリ蓄積部30およびリダイレクト部55を有する。
アプリ蓄積部30は、PFアプリ、Webアプリのキャッシュ、PFアプリが利用するデータ、及びWebアプリが格納するデータを記録する処理を行う。PFアプリ、Webアプリのキャッシュなどアプリ蓄積部30がデータを記録する媒体としては情報操作装置2に内蔵のハードディスクドライブやフラッシュメモリ、外付けハードディスクドライブやSDカードなどの汎用の記録媒体が使用可能である。
HTTP処理部11は、Webサーバ(HTTPサーバ)との間で、HTTP(Hypertext Transfer Protocol)もしくはHTTPS(Hypertext Transfer Protocol over Secure Socket Layer)のプロトコルで通信し、後述するWebアプリ、利用許可証の要求、取得に必要なHTTPクライアント処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。
HTTP処理部11は、Webアプリ配布サーバ4からWebアプリを取得するための接続確立処理を行う第1コネクション部を内蔵する。
HTTP処理部11は、後述するアプリ取得部12からの要求に応じて、所定のWebサーバ(Webアプリ配布サーバ4、PFアプリ配布サーバ5)に後述するPFアプリとWebアプリの取得要求を送信し、取得要求したPFアプリとWebアプリを受信する。HTTP処理部11は、受信したPFアプリとWebアプリをアプリ取得部12に送信する。
HTTP処理部11は、後述する利用許可証取得部14からの要求に応じて、利用許可証配布サーバ6に後述する利用許可証の取得要求を送信し、要求した利用許可証を利用許可証取得部14で受信する。HTTP処理部11は、受信した利用許可証を利用許可証取得部14に送信する。
アプリ取得部12は、HTTP処理部11を使って、所定のWebサーバ(Webアプリ配布サーバ4、PFアプリ配布サーバ5)から後述するPFアプリとWebアプリを取得する処理を行う。
アプリキャッシュ部13は、アプリ取得部12で取得したPFアプリもしくはWebアプリの全部もしくは一部のデータをキャッシュとしてアプリ蓄積部30に格納する処理を行う。Webアプリのうち、どの部分をキャッシュとしてアプリ蓄積部30に格納するかは、Webアプリの開発者があらかじめ設定ファイルに記述しておく。アプリキャッシュ部13はその設定ファイルに従って、指定された部分をキャッシュとしてアプリ蓄積部30に格納する。
利用許可証取得部14は、HTTP処理部11を使って利用許可証配布サーバ6から利用許可証を取得する。
入力受信部15は、タッチパッドやキーボード、マウスなどの入力機器を介してユーザが入力した情報を受信し、入力した情報をアプリ実行部16に通知する。
アプリ実行部16は、アプリ取得部12で取得したWebアプリやPFアプリ、アプリ蓄積部30に蓄積されているWebアプリやPFアプリを実行する。アプリがWebアプリの場合はWebブラウザを用いて実行する。詳細は後述する。
画面出力部17は、アプリ実行部16で生成した画面を自装置内の不図示のモニターに表示もしくは外部出力インタフェースに出力する。外部出力インタフェースとは、例えばHDMI(High-Definition Multimedia Interface)やコンポジット、S-Video、コンポーネントのようなインタフェースのことを指す。
Websocketクライアント処理部18は、RFC6455規格で定められたウェブソケット(Websocket)と呼ばれるプロトコルに従って情報出力装置2と通信を行うためのクライアント処理を行う。機器操作命令送信部19やアプリ実行部16から送られてくるデータ(機器操作命令、利用許可証)は、このWebsocketクライアント処理部18で処理され、RFC6455規格で定められたフォーマットに従って、ヘッダなどを付与して情報出力装置2に送信される。Websocketクライアント処理部18はドメイン付与部70を備えている。Websocketクライアント処理部18のドメイン付与部70はWebアプリ実行部22で実行中のWebアプリのドメイン名(出所情報)をWebsocketヘッダ(Websocketコネクションのヘッダ(特許請求の範囲のコネクションのヘッダに対応))に付与する処理を行う。その理由については後述する。
Websocketクライアント処理部18は、機器操作命令と利用許可証を情報出力装置2に送信するための接続確立処理を行う第2コネクション部を内蔵する。
機器操作命令送信部19は、アプリ実行部16からの命令に基づいて機器操作命令をWebsocketクライアント処理部18を使って情報出力装置2に送信する処理を行う。
リダイレクト処理部55は、HTTP処理部11で受信したメッセージの中に、HTTPリダイレクト命令に含まれる場合には、その命令の中に含まれるURLを取得し、そのURLで指示されたWebアプリを取得するようアプリ取得部12に指示する。
機器検索処理部20は、アプリからの要求に基づいてネットワーク上に情報出力装置2など他の装置が存在するかどうかを検索し、存在する場合は情報出力装置2のIPアドレスやWebsocketのTCPポート番号などを取得する。具体的には、アプリからの要求に基づいてアプリ実行部16が機器検索処理部20に機器検索要求を送信し、機器検索処理部20はその結果をアプリ実行部16に通知し、アプリ実行部16はアプリにその結果を通知する。
このように、機器検索処理部20は、情報出力装置2に装置検索要求を送信して、情報出力装置2から送信された、情報出力装置2の名前やIPアドレス等を受信するためのネットワークセッション確立処理を行うコネクション部を有する。機器検索の詳細は後述する。なお、機器検索処理部20は必須の構成ではない。
より具体的には、機器検索処理部20は、情報出力装置のID等の識別情報を取得するためのネットワークセッション確立処理を行う第3コネクション部を内蔵する。この第3コネクション部で情報出力装置2のIPアドレス等を取得した後に、上述したWebsocketクライアント処理部18は、機器検索処理部20が受信した情報出力装置2のIPアドレス等に基づいて、情報出力装置2に対して機器操作命令と利用許可証を送信するための第2コネクション部の接続確立処理を行う。
なお、本実施形態では、Webアプリとプラットホーム固有アプリ(PFアプリ)の二種類のアプリケーション・ソフトウェアが存在することを念頭に置いている。
Webアプリは、HTML(HyperText Markup Language)やJavaScript(登録商標)などが解釈できるWebブラウザの実行環境で実行されるアプリケーションのことを指す。なお、HTMLのバージョンは4でもよいし5でもよい。Webアプリは一般に、複数のページファイルとメディアファイルを有する。
ここで、メディアファイルとは、JPEG、GIF、およびMPEGなどの動画像データが納められたファイルや、MP3などの音声データが納められたファイルを指す。これに対して、ページファイルには、HTMLなどで記述する文字や画像等の配置情報、表示文字データなどに加えて、JavaScriptのような制御プログラム情報が格納される場合がある。また、HTML5またはJavaScriptからはHTTP(XMLHTTPRequest)やWebSocketと呼ばれるプロトコルでHTTPサーバや、WebSocketサーバと通信することができる。
プラットホーム固有アプリとは、Webブラウザ上ではなく、オペレーティングシステム(OS)あるいは仮想マシン(Virtual Machine)上で実行されるアプリケーションを指し、プロセッサやOSや仮想マシンに依存するアプリを意味する。これらのプラットホーム固有アプリは、アプリの実行ファイル(実行バイナリファイル)と、静止画データやテキストデータなどのアプリで利用するデータが一つのファイルとしてパッケージ化された形で配布される。以下、PFアプリと省略して記述する。
図3は情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図である。
図3のアプリ実行部16は、PFアプリ9を実行するPFアプリ実行部(第1アプリ実行部)21と、Webアプリ10を実行するWebアプリ実行部(第2アプリ実行部)22とを有する。
Webアプリ実行部22は、汎用のWebブラウザで実現され、Webブラウザの機能としては、利用許可証アクセス制御部23と、利用許可証蓄積部24と、利用許可証送信部25とを有する。
アプリ取得部12はさらに、HTTP処理部11を介してWebサーバ(PFアプリ配布サーバ5)と通信してPFアプリ9を取得するPFアプリ取得部(第1アプリ取得部)26と、同じくHTTP処理部11を介してWebサーバ(Webアプリ配布サーバ4)と通信してWebアプリ10を取得するWebアプリ取得部27とを有する。
アプリキャッシュ部13はさらに、PFアプリ取得部26で取得したPFアプリ9をアプリ蓄積部30に格納するPFアプリキャッシュ部28と、Webアプリ取得部27で取得したWebアプリ10をアプリ蓄積部30に格納するWebアプリキャッシュ部29とを有する。 Webアプリ10をキャッシュとしてアプリ蓄積部30に蓄積する際の技術としてW3Cで規格化されているHTML5仕様のAppCache機能を利用してもよい。
次にWebアプリ実行部22の詳細について説明する。
利用許可証蓄積部24は、利用許可証取得部14で利用許可証配布サーバ6から取得した利用許可証をアプリ蓄積部30に格納する処理を行う。
Webアプリ実行部22はWebブラウザであるため、W3Cで規格化が進められているWeb Storage仕様に従って情報操作装置1内のアプリ蓄積部30にWebアプリを記憶してもよいし、RFC 6265で規定されたHTTP Cookieに従って情報操作装置1内のアプリ蓄積部30にWebアプリを記憶してもよい。
利用許可証アクセス制御部23は、利用許可証蓄積部24に蓄積した利用許可証をWebアプリ配布サーバ4のドメイン毎に管理する。情報操作装置1は複数のWebアプリ配布サーバ4と通信し、それぞれ異なる複数のWebアプリを取得して実行する可能性がある。利用許可証配布サーバ6は利用許可証を利用できるWebアプリを制限するために、利用許可証の利用を許可するWebアプリのドメインの範囲を指定して情報操作装置1に保存する。具体的には、Cookieとして情報操作装置1に利用許可証を保存する場合、利用許可証配布サーバ6はRFC 2965やRFC6265で規定されたSet-CookieヘッダなどのCookieを保存する命令のパラメタとしてドメイン名を指定するようにすればよい。
利用許可証アクセス制御部23は、Webアプリから利用許可証蓄積部24内に蓄積された利用許可証の利用要求があった場合、Webアプリのドメイン名が利用許可証配布サーバ6で指定されたドメインの範囲に含まれるか否かを検査し、含まれる場合のみWebアプリに対して利用許可証の利用を許可する処理を行う。たとえば、情報操作装置1が利用許可証をCookieとして保存する際、利用許可証配布サーバ6がexample.foo.bar.comとして利用範囲(ドメイン)を指定した場合、利用許可証を利用するWebアプリのドメイン名はexample.foo.bar.comやa.example.foo.bar.comなど、example.foo.bar.comを含むドメインでなければならない。仮にWebアプリのドメインがfoo.foo.bar.comだった場合、そのドメインは利用許可証配布サーバ6が指定したドメインに含まれないため、利用許可証アクセス制御部23はそのWebアプリから利用許可証の利用要求があったとしても、利用許可証を返さないように制限する。
なお、Webアプリのドメイン名が利用許可証配布サーバ6が指定したドメインの範囲外で、Webアプリから利用許可証蓄積部24内に蓄積された利用許可証の利用要求があった場合には、何も返さないか、エラーを返す処理を行う。
利用許可証送信部25は、Webアプリからの指示に基づいて利用許可証蓄積部24に蓄積された利用許可証をWebsocketクライアント処理部18に送信する処理を行う。
図4は第1の実施形態に係る情報出力装置2の内部構成を示すブロック図である。図4の情報出力装置2は、HTTP処理部31と、チューナ部32、画面出力部33、機器操作命令処理部34、リモコン命令処理部35、固有ID管理部36、ID登録要求送信部37、MAC鍵管理部56、公開鍵管理部38、PIN管理部39、Websocketサーバ処理部40、機器検索処理部41、利用許可証検査部42、およびアプリ出所検査部43を有する。
HTTP処理部31は、Webサーバ(HTTPサーバ)との間で、HTTP(Hypertext Transfer Protocol)もしくはHTTPS(Hypertext Transfer Protocol over Secure Socket Layer)のプロトコルで通信し、後述するID登録要求を送信したり公開鍵を受信したりするのに必要なHTTPクライアント処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。
チューナ部32は、アンテナ等から受信した放送波から、特定の放送番組や放送関連情報を抽出し、デコード処理を行う。
画面出力部33は、チューナ部32から出力された動画データや音声データを不図示の内部液晶モニターや外部出力インタフェースに出力する。外部出力インタフェースとは、例えばHDMI(High-Definition Multimedia Interface)やコンポジット、S-Video、コンポーネントのようなインタフェースのことを指す。
機器操作命令処理部34は、情報操作装置1や赤外線リモコンから受信した機器操作命令を処理し、チューナ部32を制御したり、画面出力部33に表示する映像等を切り替える指示を送ったりする。
リモコン命令処理部35は、不図示の赤外線リモコンから受信した命令を処理し、機器操作命令処理部34にその命令を通知する処理を行う。なお、リモコン命令処理部は必須の構成ではない。
固有ID管理部36は、情報出力装置2に固有のIDを管理する処理を行う。固有IDの生成方法として、情報出力装置2の工場出荷時に一意のIDを書きこむ方法、情報出力装置2の初回起動時に不図示の乱数生成器を用いて乱数を生成して保存する方法、HTTP処理部31のイーサネット物理アドレス(MACアドレス)を利用する方法、MACアドレスを元に乱数生成する方法、情報出力装置2がユーザの指示に基づき赤外線リモコン命令を経由して固有IDを生成する命令を受信し、不図示の乱数生成器を用いて乱数を生成して保存する方法、それらを組み合わせる方法などがあり、いずれを採用してもよい。
ID登録要求送信部37は、利用許可証配布サーバ6とHTTPのプロトコルで通信し、利用許可証配布サーバ6に対して公開鍵を要求するメッセージに固有ID管理部36で管理する固有IDを添付して登録要求として送信し、その応答として利用許可証配布サーバ6から公開鍵を受信する処理を行う。
MAC鍵管理部56は、利用許可証配布サーバ6と共有する共通鍵を管理し、その鍵を用いてメッセージ認証コード(Message Authentication Code:MAC)を生成する処理を行う。なお、MAC鍵管理部56は必須の構成ではない。
公開鍵管理部38は、利用許可証配布サーバ6から受信した公開鍵を保存して管理する処理を行う。
PIN管理部39はパスワード(暗証コード、より具体的にはPINコード、以下PINと省略して表記する)を管理する処理を行う。PINの生成方法として、情報出力装置2の工場出荷時にPINの値を書きこむ方法、情報出力装置2が不図示の乱数生成器を用いて乱数を生成し、その乱数をPINの値とする方法、情報出力装置2がユーザの指示に基づき赤外線リモコン命令を経由してPINを生成する命令を受信し、不図示の乱数生成器を用いて乱数を生成してPINの値とする方法、情報出力装置2がユーザの指示に基づき赤外線リモコン命令を経由して文字列データや数字列データを受信し、その受信したデータをPINの値とする方法、HTTP処理部のMACアドレスを元に乱数生成する方法、それらを組み合わせる方法などがあり、いずれを採用してもよい。
Websocketサーバ処理部40は、RFC6455規格で定められたWebsocketと呼ばれるプロトコルに従って情報操作装置1と通信を行うためのサーバ処理を行う。機器操作命令送信部19や利用許可証など情報操作装置1から送信されるデータを受信し、利用許可証検査部42やアプリ出所検査部43、機器操作命令処理部34にデータを振り分ける処理を行う。
機器検索処理部41は、後述する情報操作装置1からの装置検索要求に応答して自装置の名前やIPアドレス、Websocketサーバ処理部40のTCPポート番号を返信する処理を行う。装置検索のプロトコルとして、DLNA (Digital Living Network Alliance)規格や、UPnP (Universal Plug and Play)規格で定められた方式、あるいはNetBIOS (Network Basic Input Output System)による名前検索方式を用いてもよい。このように、機器検索処理部41は、情報操作装置1からの装置検索要求に応答して、自装置の名前やIPアドレス等を返信するためのネットワークセッション確立処理を行うコネクション部を有する。なお、この機器検索処理部41は必須の構成ではない。
利用許可証検査部42は、情報操作装置1から送信されてWebsocketサーバ処理部40で受信した利用許可証が正しいかどうかの検査処理を行い、その結果を機器操作命令処理部34に通知する。利用許可証検査部42の検査処理の詳細は後述する。
アプリ出所検査部43は、情報操作装置1から送信されてWebsocketサーバ処理部40で受信した機器操作命令に含まれるヘッダ情報が正しいかどうかの検査処理を行い、その結果を機器操作命令処理部34に通知する。アプリ出所検査部43の検査処理の詳細は後述する。
図5は第1の実施形態に係るWebアプリ配布サーバ4の内部構成を示すブロック図である。Webアプリ配布サーバ4は、情報操作装置1とHTTPまたはHTTPSのプロトコルで通信し、情報操作装置1からの要求に従ってWebアプリを配布する。図5のWebアプリ配布サーバ4は、HTTPサーバ処理部51、Webアプリ蓄積部52、Webアプリ登録処理部53、およびWebアプリ配布部54を有する。
HTTPサーバ処理部51は、情報操作装置1とHTTPもしくはHTTPSのプロトコルで通信し、Webアプリの取得要求やWebアプリの配布処理に必要なHTTPサーバ処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。
Webアプリ蓄積部52は、Webアプリを蓄積する処理を行う。Webアプリは固有のID(WebアプリID)が付与されて蓄積される。
Webアプリ登録処理部53は、WebアプリをWebアプリ蓄積部52に蓄積する処理を行う。図5ではHTTPサーバ処理部51を介してネットワーク経由でWebアプリを蓄積する構成について示したが、必ずしもネットワーク経由で蓄積する必要はなく、USBメモリなど外部メモリを経由してWebアプリを蓄積してもよい。なお、このWebアプリ登録処理部53は必須の構成ではない。
Webアプリ配布部54は、情報操作装置1からアプリに固有のIDを指定してWebアプリを送信するようネットワークを経由して指示を受けると、Webアプリ蓄積部52に蓄積されたWebアプリの中から指定されたIDに対応するWebアプリを検索し、そのWebアプリに属する各種リソースをHTTPサーバ処理部51を経由して情報操作装置1に送信する処理を行う。なお、アプリに固有のIDはURLでもよい。
なお、Webアプリ配布サーバ4は複数のWebアプリを配布してもよいが、その場合にはWebアプリ配布サーバ4の同一ドメインの中に複数の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アプリを格納する例について説明する。
図6は第1の実施形態に係るPFアプリ配布サーバ5の内部構成を示すブロック図である。PFアプリ配布サーバ5は、情報操作装置1とHTTPまたはHTTPSのプロトコルで通信し、情報操作装置1からの要求に基づいてPFアプリを配布する処理を行う。図6のPFアプリ配布サーバ5は、HTTPサーバ処理部61、PFアプリ蓄積部62、PFアプリ登録処理部63およびPFアプリ配布部64を有する。
HTTPサーバ処理部61は、Webアプリ配布サーバ4のHTTPサーバ処理部51と同等の処理を行う。
PFアプリ蓄積部62は、PFアプリを蓄積する処理を行う。PFアプリは固有のIDが付与されて蓄積される。なお、Webアプリは上述したように静止画データやテキストデータなど複数のリソース(ファイル)で構成されることが一般的だが、PFアプリはそれらリソースを一つのファイルに圧縮して配布する。従って、PFアプリは固有のIDにつき一つのPFアプリファイルとして提供される。
PFアプリ登録処理部63は、PFアプリをPFアプリ蓄積部62に蓄積(登録)する処理を行う。図6ではHTTPサーバ処理部61を介してネットワーク経由でPFアプリを登録する構成について示したが、必ずしもネットワーク経由で登録する必要はなく、USBメモリなど外部メモリを経由してWebアプリを登録してもよい。なお、このPFアプリ登録処理部63は必須の構成ではない。
PFアプリ配布部64は、情報操作装置1からアプリに固有のIDを指定してPFアプリを送信するようネットワークを経由して指示を受けると、PFアプリ蓄積部62に蓄積されたPFアプリの中から指定されたIDに該当するPFアプリを検索し、そのPFアプリに該当するファイルをHTTPサーバ処理部61を経由して情報操作装置1に送信する処理を行う。
図7Aは第1の実施形態に係る利用許可証配布サーバ6の内部構成を示すブロック図である。利用許可証配布サーバ6は、情報操作装置1および情報出力装置2とHTTPまたはHTTPSのプロトコルで通信し、情報操作装置1に利用許可証を配布したり、情報出力装置2に公開鍵を配布したりする処理を行う。図7Aの利用許可証配布サーバ6は、HTTPサーバ処理部71、情報出力装置情報蓄積部72、情報出力装置固有ID登録部73、鍵ペア生成部74、鍵ペア送信部75、情報出力装置登録受付処理部76、Webアプリ情報蓄積部77、利用許可証登録受付処理部78、利用許可証生成部79、および利用許可証要求受付処理部80を有する。
HTTPサーバ処理部71は、情報操作装置1とHTTPもしくはHTTPSのプロトコルで通信し、利用許可証の取得要求や利用許可証の配布処理に必要なHTTPサーバ処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。HTTPサーバ処理部71はまた、情報出力装置2とHTTPもしくはHTTPSのプロトコルで通信し、情報出力装置2から送信される登録要求メッセージを受信したり、その応答として公開鍵を配布したりする処理に必要なHTTPサーバ処理及びTCP/IP処理、リンクレイヤ処理・物理レイヤ処理を行う。また、受信したメッセージが情報出力装置2からの登録要求メッセージであれば、情報出力装置登録受付処理部76にメッセージの内容を渡し、情報操作装置1からの利用許可証生成要求であれば利用許可証要求受付処理部80にメッセージの内容を渡し、利用許可証の登録要求であれば利用許可証登録受付処理部78にメッセージの内容を渡す処理も行う。
情報出力装置情報蓄積部72は、情報出力装置2の固有IDとそれに対応する公開鍵ペアを蓄積および管理する処理を行う。
情報出力装置固有ID登録部73は、画面生成装置から送信される登録要求メッセージに含まれる情報出力装置2の固有IDを情報出力装置情報蓄積部72に蓄積する処理を行う。
鍵ペア生成部74は、情報出力装置固有ID登録部73が情報出力装置情報蓄積部72に情報出力装置2の固有IDを登録する際、公開鍵ペアを生成して情報出力装置2の固有IDとセットにして情報出力装置情報蓄積部72に登録する処理を行う。公開鍵のアルゴリズムとしてはRSA暗号や楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。なお、ここで生成した公開鍵ペアのうち、公開鍵は情報出力装置2に送信され、秘密鍵は利用許可証配布サーバ6が管理して利用許可証の署名を生成する際に用いられる。
鍵ペア送信部75は、登録要求メッセージの応答として、鍵ペア生成部74が生成した公開鍵、もしくは情報出力装置情報蓄積部72に登録された公開鍵を取得する処理を行う。登録要求メッセージに含まれる固有IDに対応する公開鍵がまだ情報出力装置情報蓄積部72に登録されていない場合は鍵ペア生成部74から公開鍵を取得し、既に情報出力装置情報蓄積部72に登録されている場合は情報出力装置情報蓄積部72から公開鍵を取得する。
なお、鍵ペア生成部74は、鍵ペアを生成したら必ず情報出力装置情報蓄積部72に登録し、鍵ペア送信部75は情報出力装置情報蓄積部72から公開鍵を取得してもよい。
また、情報出力装置2に公開鍵を送信する際、情報出力装置2と利用許可証配布サーバ6との間の通信経路上で公開鍵の値が改ざんされることを防止するために、利用許可証配布サーバ6はメッセージ認証コード秘密鍵(Message Authentication Code秘密鍵、以下MAC鍵と略して表記する)を生成して、公開鍵にMAC鍵を使って作成したメッセージ認証コードを添付してもよい。なお、メッセージ認証コードの生成アルゴリズムとしてはHMAC-MD5, HMAC-SHA1など良く知られたアルゴリズムを用いればよい。このMAC鍵は情報出力装置2とMAC鍵管理部56に蓄積された鍵と同じ値である。なお、利用許可証配布サーバ6は情報出力装置2毎にMAC鍵を管理してもよいし、複数の情報出力装置2で同一のMAC鍵を管理しても良い。
情報出力装置登録受付処理部76は、情報出力装置2から送信された登録要求メッセージを受信し、その応答として登録要求メッセージに含まれる固有IDに対応する公開鍵を情報出力装置2に送信する処理を行う。
なお、既に情報出力装置情報蓄積部72に登録されている情報出力装置2から登録要求メッセージが来た場合、鍵ペア生成部74にて新しい鍵ペアを生成して情報出力装置情報蓄積部72に登録してもよいし、新しい鍵ペアを生成せず情報出力装置情報蓄積部72に蓄積されている固有IDに対応する公開鍵を送信してもよい。
Webアプリ情報蓄積部77は、各Webアプリ、すなわちWebアプリIDに対応した利用許可証を蓄積する処理を行う。利用許可証登録受付処理部78からWebアプリIDに対応したドメイン名も受信し、WebアプリIDとペアにして蓄積する。すなわち、Webアプリ情報蓄積部77はWebアプリの固有ID、Webアプリのドメイン名のペアが蓄積される。利用許可証やドメイン名については後述する。
利用許可証登録受付処理部78は、利用許可証を登録する処理を行う。図7AではHTTPサーバ処理部71を介してネットワーク経由で利用許可証を登録する構成を示すが、必ずしもネットワーク経由で登録する必要はなく、USBメモリなど外部メモリを経由してWebアプリを登録してもよい。なお、この利用許可証登録処理部は必須の構成ではない。なお、この登録した状態では利用許可証に署名は付与されていない。
利用許可証生成部79は、利用許可証要求メッセージに含まれるWebアプリに固有のIDに対応する利用許可証をWebアプリ情報蓄積部77から取得し、利用許可証、WebアプリID、利用許可証要求メッセージに含まれるPINに対して秘密鍵管理部に格納した秘密鍵を使って署名を施し、署名付き利用許可証を生成する処理を行う。なお、署名のほかにオプションとして署名方式を付与してもよい。
利用許可証要求受付処理部80は、情報操作装置1から送信された利用許可証要求メッセージを受信し、その応答として署名付き利用許可証を情報操作装置1に送信する処理を行う。
なお、図1では、Webアプリ配布サーバ4、PFアプリ配布サーバ5、および利用許可証配布サーバ6を別々の装置として図示したが、これら三つのサーバをまとめて一つの装置で実現してもよい。すなわち、これら3つのサーバのうち任意の2つ以上を1つの装置にまとめてもよい。
図7Bは利用許可証配布サーバ6に図5に示したWebアプリ配布サーバ4の機能を持たせた場合の内部構成を示すブロック図である。図7Aとの違いはWebアプリ蓄積部52とWebアプリ配布部54を新たに備えている点である。Webアプリ蓄積部52は図5に示したWebアプリ配布サーバ4内のWebアプリ蓄積部52と同一の機能を持っていればよい。Webアプリ配布部54は図5に示したWebアプリ配布部54の機能に加えて、Webアプリの取得要求メッセージの中に情報出力装置2の固有IDが含まれている場合、情報出力装置情報蓄積部72の中に、その固有IDを持つ情報出力装置2に関する情報が登録されているかどうかを確認し、含まれている場合に限り要求されたWebアプリの配布を行う機能を有する。このようにする事で、利用許可証配布サーバ6に未登録の固有IDを持つ情報出力装置2の固有IDを付けてWebアプリの取得要求メッセージを送信するような不正な装置からWebアプリを配信する事を防止できる。
図8は第1の実施形態における情報操作装置1、情報出力装置2、利用許可証配布サーバ6、PFアプリ配布サーバ5、およびWebアプリ配布サーバ4の処理手順を示すフローチャートである。図8に示すように、処理シーケンスは大きく分けて、情報出力装置セットアップフェーズ(ステップS1)、情報操作装置セットアップフェーズ(ステップS2)、情報出力装置操作フェーズ(ステップS3〜S6)の3つのフェーズを有する。まずここでは全体処理シーケンスを示し、各フェーズの詳細な処理シーケンスに関しては後述する。
情報出力装置セットアップフェーズでは、情報出力装置2が利用許可証配布サーバ6と通信し、情報出力装置2を利用許可証配布サーバ6に登録する処理を行う。
情報操作装置セットアップフェーズでは、情報操作装置1がPFアプリ配布サーバ5と通信し、情報操作装置1がPFアプリをPFアプリ配布サーバ5からダウンロードして情報操作装置1にインストールする処理を行う。
情報出力装置操作フェーズは、レベル1(ステップS3,S4)とレベル2(ステップS5,S6)の二つのフェーズに分かれている。レベル1では、情報操作装置1がWebアプリ配布サーバ4と通信し、情報操作装置1がWebアプリをWebアプリ配布サーバ4からダウンロードする処理(ステップS3)と、情報操作装置1が利用許可証配布サーバ6から利用許可証をダウンロードする処理(ステップS4)とを行う。
なお、情報操作装置1上でWebアプリをダウンロードして実行する処理のトリガーは、情報操作装置セットアップフェーズにてインストールしておいたPFアプリが行う。
レベル2では、情報操作装置1が情報出力装置2と通信し(ステップS5)、情報操作装置1から情報出力装置2に機器操作命令を送信して情報出力装置2を制御する処理を行う(ステップS6)。
図9は第1の実施形態における情報出力装置セットアップフェーズの情報出力装置2と利用許可証配布サーバ6の処理手順を示すシーケンス図である。
まず情報出力装置2は、利用許可証配布サーバ6のURLを取得し(ステップS11)、取得したURLにHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでアクセスして、利用許可証配布サーバ6に対して、固有ID管理部36で管理する情報出力装置2の固有IDを添付して、情報出力装置2の固有IDの登録要求を送信する(ステップS12)。このメッセージはHTTP GETリクエストとして送信すればよい。以下にメッセージの一例を示す。
http://example-CAserver.com/register.php?device_id=xxxx
このメッセージでは、利用許可証配布サーバ6のサーバ名を"example-CAserver.com"、情報出力装置2の固有IDをdevice_idでラベル付けされた値"xxxx"として、利用許可証配布サーバ6に送信している。利用許可証配布サーバ6のURLは、情報出力装置2の工場出荷時に情報出力装置2内に登録しておいてもよいし、赤外線リモコンを利用してユーザにURLを入力させてもよいし、情報出力装置2がアクセスするトップページからリンク情報として利用許可証配布サーバ6のURLにたどれるようにWebページを構成してもよい。
なお、登録要求メッセージの中でも固有IDが情報出力装置2と利用許可証配布サーバ6との間の通信経路上で改ざんされないようにするために、MAC鍵管理部56で情報出力装置2に利用許可証配布サーバ6と共有する共通鍵を管理し、その鍵を用いてメッセージ認証コードを生成してもよい。情報出力装置2が生成するメッセージ認証コードの計算方法の一例を以下に示す。
signature = keyed_hash (key、device_id)
ここで、keyは利用許可証配布サーバ6と共有する共通鍵を示し、device_idは情報出力装置2の固有IDを示し、keyを鍵としてdevice_idをkeyed_hashアルゴリズムを使って計算した値がSignatureである事を示す。keyed_hashアルゴリズムとしてHMAC-SHA1アルゴリズムやHMAC-MD5、HMAC-SHA256などを利用すればよい。
情報出力装置2がメッセージ認証コードを添付して利用許可証配布サーバ6に送信する登録要求メッセージの一例を以下に示す。
http://example-CAserver.com/register.php?device_id=xxxx&signature=yyyy&signature_method=hmac-sha1
この例では、signatureでラベル付けされた値"yyyy"をメッセージ認証コードとしてURLに付与し、さらに利用許可証配布サーバ6に対してメッセージ認証コードの生成アルゴリズムを通知している。なお、ここではsignature_methodでラベル付けされた値"hmac-sha1"にてHMAC-SHA1アルゴリズムを利用してメッセージ認証コードを情報出力装置2が生成する例を示している。
次に、利用許可証配布サーバ6が登録要求を受信すると、情報出力装置登録受付処理部76は登録要求メッセージに含まれる固有IDを取り出し、その固有IDに対応する公開鍵ペアが情報出力装置情報蓄積部72に登録されているかどうかを検査する(ステップS13)。
もし既に登録されている場合は、この登録要求は二度目以降の要求であると判断して情報出力装置情報蓄積部72から公開鍵を取得し(ステップS14)、情報出力装置2に公開鍵を含めて応答メッセージを送信する(ステップS15、S16)。
もしまだ登録されていない場合、利用許可証配布サーバ6は、その固有IDを持つ情報出力装置2から初めての登録要求であると判断して公開鍵ペアを生成し(ステップS17)、情報出力装置情報蓄積部72の中に公開鍵ペアと固有IDをセットにして登録し(ステップS18)、生成した公開鍵ペアのうち公開鍵の方だけを含めて応答メッセージを送信する(ステップS15、S16)。
この時のHTTP GETリクエストに対するレスポンスメッセージボディの一例を以下に示す。
pubkey=xyxyxy
上述した例では、pubkeyでラベル付けされた値"xyxyxy"を公開鍵として送信している。なお、通信経路上でのメッセージ改変を防止するために、登録要求メッセージ同様、メッセージ認証コードを付与してもよい。その場合の登録要求メッセージに対する応答メッセージの一例を以下に示す。
pubkey=xyxyxy&signature=zyzyzy&signature_method=hmac-sha1
上述した例では、signatureでラベル付けされた値"zyzyzy"は、利用許可証配布サーバ6が情報出力装置2と共有する共通鍵にてHMAC-SHA1アルゴリズムを利用して生成したメッセージ認証コードである。
情報出力装置2は公開鍵を受信すると公開鍵管理部38に保存する(ステップS19)。この公開鍵は情報出力装置操作フェーズにて用いる。
図10は第1の実施形態における情報操作装置セットアップフェーズの情報操作装置1とPFアプリ配布サーバ5の処理手順を示すシーケンス図である。
なお、情報操作装置1に情報出力装置2操作用のPFアプリがプリインストールされている場合は図10に示したシーケンスを実行する必要はない。
まず情報操作装置1はPFアプリ配布サーバ5からPFアプリの一覧を取得する(ステップS21)。その時の情報操作装置1の画面出力部17の画面に出力されるPFアプリの一覧の表示例を図11に示す。このアプリ一覧は、例えばWebコンテンツとしてWebアプリ実行部22で画面を生成すればよい。その場合のWebコンテンツは予め機器出荷時に設定されたURLを元にPFアプリ配布サーバ5から、一覧を表示させるWebコンテンツを取得するようにすればよい。
図11に示す例では、PFアプリの一覧をアイコンとして表示し、そのアイコンの下に簡単な説明を記述している。情報操作装置1のユーザは、マウスやタッチパッド等を利用して入力受信部15からPFアプリを選択する(ステップS22)。図11の例では、PFアプリAが情報出力装置2操作用のPFアプリであるため、このPFアプリが選択されたと仮定する。するとPFアプリAに関連づけられたアプリ固有IDを含むPFアプリ送信要求(URL)が情報操作装置1からPFアプリ配布サーバ5に送信される(ステップS23)。情報操作装置1はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでPFアプリ送信要求をPFアプリ配布サーバ5に送信する。
PFアプリ配布サーバ5は、PFアプリ蓄積部62に蓄積されたPFアプリ群の中から、情報操作装置1によって指定されたアプリ固有IDを持つPFアプリを検索して取得し(ステップS24)、取得したPFアプリをアプリ送信要求に対する応答としてPFアプリ配布部64は情報操作装置1に送信する(ステップS25)。
情報操作装置1は、PFアプリ取得部26を利用して、PFアプリAをPFアプリ配布サーバ5から受信してダウンロードし(ステップS26)、PFアプリAをインストールする(ステップS27)。インストールされたPFアプリAはアプリ蓄積部30に保存される。
図12は第1の実施形態におけるPFアプリの構造を示す図である。PFアプリは、PFアプリ初期化命令81、ローカルWebアプリ#1 82、WebアプリURL83、Webアプリ実行部呼び出し命令84、およびリソース85を有する。
PFアプリ初期化命令81は、初期化処理などPFアプリをPFアプリ実行部21で実行させる際に最初に実行する汎用の処理と、Webアプリ実行部呼び出し命令84を呼び出す処理を行うプログラムである。
ローカルWebアプリ#1 82は、利用許可証が情報操作装置1の利用許可証蓄積部24に保存されているかどうかを検査する。このローカルWebアプリ#1 82はHTML4/5またはJavaScriptによって記述されており、情報操作装置1のWebアプリ実行部22(ブラウザ)で実行される。ローカルWebアプリはPFアプリのパッケージ内に含めても良いし、Webアプリ配布サーバ4に置き、アプリ取得部12を使ってネットワーク経由で取得するようにしてもよい。ネットワーク経由で取得する場合、ローカルWebアプリはPFアプリには含まれない。
WebアプリURL83はWebアプリ#0の場所を示すURLである。WebアプリがPFアプリのパッケージ内に含めて配布される場合は情報操作装置1内のローカルWebアプリが保存されたロケーションを示し、Webアプリ配布サーバ4に置かれている場合は、Webアプリ配布サーバ4のローカルWebアプリが置かれているロケーションを示す。以下では、まずWebアプリがPFアプリのパッケージ内に含めて配布される場合について説明する。
Webアプリ実行部呼び出し命令84はWebアプリURL83を引数としてWebアプリ実行部22を起動するプログラムである。すなわち、WebアプリURL83で示すWebアプリがWebアプリ実行部22で実行されることになる。
リソース85は、情報操作装置1にインストールされたPFアプリ一覧を表示させる際のPFアプリのアイコン(静止画データ)や説明文、バージョン番号などである。
図13は第1の実施形態における情報出力装置操作フェーズ(レベル1)の情報操作装置1、Webアプリ配布サーバ4、および利用許可証配布サーバ6の処理手順を示すシーケンス図である。
まず情報操作装置1はPFアプリ実行部21でPFアプリを実行する(ステップS31)。PFアプリ実行のトリガーは入力受信部15によるPFアプリ選択によって行われる。PFアプリはPFアプリ初期化命令81で初期化処理等を実行した後、Webアプリ実行部呼び出し命令84を実行する。Webアプリ実行部呼び出し命令84はWebアプリURL83で指定され、PFアプリに含まれるローカルWebアプリ(Webアプリ#1)をWebアプリ実行部22で実行する(ステップS32)。以降の処理はWebアプリ実行部22でなされる。
次に、情報操作装置1はローカルWebアプリ(Webアプリ#1)を実行する。上述のようにWebアプリ#1は利用許可証が情報操作装置1の利用許可証蓄積部24に保存されているかどうかを検査する(ステップS33)。Webアプリ#1は利用許可証蓄積部24に利用許可証が保存されていないと判断した場合には、ローカルWebアプリ#1 82内に記述されたWebアプリ#2のURLを参照して(ステップS34)、そのURLが示すWebアプリ(Webアプリ#2)をWebアプリ配布サーバ4から取得して実行させる(ステップS35,S36)。具体的には情報操作装置1はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでWebアプリ送信要求をWebアプリ配布サーバ4に送信し、Webアプリ(Webアプリ#2)をWebアプリ配布サーバ4から取得して実行させる。
この例ではWebアプリ#2の保存先はWebアプリ配布サーバ4としているため、情報操作装置1はWebアプリ配布サーバ4からWebアプリ#2を取得し(ステップS37)、Webアプリ実行部22で実行する(ステップS38)。
もし、利用許可証が利用許可証蓄積部24に保存されていると判断した場合には、ローカルWebアプリ#1 82内に記述されたWebアプリ#4のURLを参照して、そのURLが示すWebアプリ(Webアプリ#4)を実行させる。
なお、Webアプリ#1が利用許可証が蓄積されているかどうかを検査する処理の前に、情報操作装置1の機器検索処理部20を利用して、これから操作する対象となる情報出力装置2を検索し、検索された情報出力装置2に固有のIDを取得してもよい。
図14は、機器検索処理部20で検索した結果、情報操作装置1の画面出力部17の画面に取得した情報出力装置2の一覧をアイコンとして表示する例を示している。情報操作装置1のユーザはマウスやタッチパッドを利用して入力受信部15から情報出力装置2を選択する。ここでは、情報出力装置2Aを選択したとする。
次に、Webアプリ#2について説明する。Webアプリ#2は、情報操作装置1の入力受信部15からPINを入力させるユーザインタフェースを提供し、利用許可証配布サーバ6に送信する処理を行うWebアプリである(PIN入力用Webアプリ)。情報操作装置1がWebアプリ#2を取得するために、ステップS35でWebアプリ配布サーバ4に送信するURLの例を以下に示す。
http://example-Webserver.com/input_pin.php?appid=X
この例では、Webアプリ配布サーバ4"example-Webserver.com"に対して、Webアプリの固有ID"X"を指定してWebアプリ取得要求を送信している。
また、別のURLの例を以下に示す。
http:// example-Webserver.com/appidX/
なお、ここでは、WebアプリごとにPIN入力ユーザインタフェースを異なるようにする例を示したが、複数のWebアプリで同一のPIN入力ユーザインタフェースを提供してもよい。また、Webアプリ#2の取得を要求する際、上述の情報出力装置2に固有のIDを添付してもよい。後述するように、この後、情報操作装置1は利用許可証配布サーバ6に対して利用許可証を要求するメッセージを送信するが、そのメッセージの中で情報出力装置2に固有のIDが必要になる。Webアプリ#2の取得を要求する際に、情報出力装置2に固有のIDをWebアプリ配布サーバ4に送信し、Webアプリ配布サーバ4がWebアプリ#2の中に固有IDを含めて返信することで、その固有IDを利用許可証を要求するメッセージで再利用する事ができるため、情報操作装置1が情報出力装置2に固有のIDを記憶しておく必要がないという利点がある。
Webアプリ#2を取得する目的でWebアプリ配布サーバ4に送信するURLに、情報出力装置2の固有IDを添付するURLの例を以下に示す。
http://example-Webserver.com/input_pin.php?device_id=xxxx&appid=X
図7Bに示すように、利用許可証配布サーバ6にWebアプリ配布サーバ4の機能を持たせる場合、Webアプリ配布サーバ4は情報出力装置2に固有のIDを受信し、その固有IDが情報出力装置情報蓄積部72に登録されているか否かを判断し、登録されている場合に限り、Webアプリ#2を配布するようにしてもよい。これにより、不正なWebアプリからのWebアプリ#2(PIN入力用Webアプリ)の取得要求を拒否する事ができる。
次に、Webアプリ#2は、図15に示すように、情報出力装置2のPINの入力を促すメッセージを情報操作装置1の画面出力部17の画面に表示させる(ステップS39)。入力受信部15から情報出力装置2のPINが入力されると、Webアプリ#2は利用許可証の要求メッセージを生成し(ステップS40)、利用許可証配布サーバ6に送信する(ステップS41)。情報操作装置1はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルで利用許可証の要求メッセージを利用許可証配布サーバ6に送信する。情報操作装置1が利用許可証配布サーバ6に送信する利用許可証の要求メッセージの一例を以下に示す。
https://example-CAserver.com/req_token.php?device_id=xxxx&appid=X&pin=ZZZZ
この例では、利用許可証配布サーバ6” example-CAserver.com”に対して、device_idでラベル付けされた値"xxxx"で情報出力装置2に固有のIDを指定し、appidでラベル付けされた値"X"でWebアプリの固有IDを指定し、pinでラベル付けされた値"ZZZZ"で入力受信部15から入力された値を指定している。
利用許可証配布サーバ6は、情報操作装置1から利用許可証要求メッセージを受信すると、情報出力装置情報蓄積部72とWebアプリ情報蓄積部77に蓄積されたデータを用いて、利用許可証生成部79で利用許可証を生成する(ステップS42)。
図16は利用許可証のフォーマットの一例を示す図である。利用許可証は、必須のフィールドとして、Webアプリ固有ID91、Webアプリの出所(ドメイン名)92、および署名93を有する。Webアプリ固有ID91は、情報操作装置1から送信された利用許可証要求メッセージに含まれていた値である。Webアプリの出所92は、後述する機器操作命令を情報出力装置2に送信するWebアプリ(Webアプリ#4)の送信元Webサーバのドメイン名である。
利用許可証配布サーバ6は、利用許可証生成部79を使い、情報操作装置1から送信された利用許可証要求メッセージに含まれる情報出力装置2の固有IDに対応した秘密鍵を情報出力装置情報蓄積部72から取得する。さらに情報操作装置1から送信された利用許可証要求メッセージに含まれるWebアプリの固有IDに対応したWebアプリのドメイン名をWebアプリ情報蓄積部77から取得する。そして、Webアプリの固有ID、Webアプリのドメイン名、情報操作装置1から送信された利用許可証要求メッセージに含まれるPINの値に対して、ハッシュ値を計算し、情報出力装置情報蓄積部72から取得した秘密鍵を利用して公開鍵暗号方式に従った署名93を生成する。このハッシュアルゴリズムとしてはMD5やSHA1などよく知られた方式を用い、署名93生成アルゴリズムとしてはRSAや楕円曲線暗号などよく知られた方式を用いればよい。署名の計算方法の一例を以下に示す。
署名=rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名 || PIN))
秘密鍵は情報出力装置情報蓄積部72から取得した情報出力装置2に固有の秘密鍵であり、この値を秘密鍵として署名を計算する。署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名、PINを結合してSHA1アルゴリズムを使って計算した値とする。これらの計算結果からRSAアルゴリズムを使って署名が求められる。ここでは署名計算アルゴリズムとしてRSAを使った例を示したが、このほかにも楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。
なお、オプションの情報として署名93がどのハッシュ・署名93アルゴリズムを用いて生成されたものであるかを示すための署名方式94の情報を添付してもよい。利用許可証配布サーバ6は利用許可証要求メッセージへの応答として、利用許可証とWebアプリ#4のURLを情報操作装置1に送信する(ステップS43)。利用許可証配布サーバ6からWebアプリ#4のURLを情報操作装置1に送信する手段として、HTTPリダイレクト(HTTP redirect)を使っても良い。HTTPリダイレクトの場合、HTTPレスポンスのLocationヘッダの中にURLが含まれる。このURLはWebアプリの固有IDに関連づけられて利用許可証配布サーバ6のWebアプリ情報蓄積部77に保存されている。情報操作装置1の利用許可証要求のメッセージにはWebアプリの固有IDが含まれているため、利用許可証要求受付処理部80はこのWebアプリに固有のIDを元にWebアプリ情報蓄積部77からURLを取得し、Locationヘッダの中に取得したURLを含めればよい。情報操作装置1はHTTPリダイレクトを受信すると、リダイレクト処理部55でLocationヘッダの中に含まれるURLを取得し、アプリ取得部12にそのURLで指示されたWebアプリを取得するように指示する。URLには利用許可証の内容が含まれるため、URLで指示されたWebアプリはURLの引数として利用許可証を取得できる。ステップ41で示したように、利用許可証はWebアプリ#4のURLと共に送信される。すなわち、HTTPリダイレクトを用いる事で、利用許可証がWebアプリ#4以外に入手できないように制限できる点が重要である。
Webアプリ配布サーバ4の説明で述べたように、Webアプリ配布サーバ4は同一ドメインの中に複数のWebアプリを格納する場合がある。この時、WebアプリXとWebアプリYは同一のドメイン名を有するWebアプリ配布サーバ4から配布されることになり、利用許可証に含まれるWebアプリの出所も同じ値となる。
仮にWebアプリYがWebアプリX用の利用許可証を入手し、情報装置操作フェーズ(レベル2)でそのWebアプリX用の利用許可証を使って機器操作命令を情報出力装置2に送信したとしても、WebアプリXとWebアプリYは出所が同一のため、情報出力装置2はその利用許可証を見てWebアプリを判別し、利用許可証に含まれるアプリIDからその利用許可証がWebアプリXから送信されたものだと解釈してしまい、正しく動作しない。従って、WebアプリXとWebアプリYはアプリIDが異なるため、WebアプリYがWebアプリX用の利用許可証を取得して利用する事を防ぐ必要がある。そこで、HTTPリダイレクトを利用して、利用許可証配布サーバ6が、その利用許可証を取得するWebアプリをURLによって指定する事で、利用許可証配付サーバ6は利用許可証が取得可能なWebアプリを制限する事ができる。つまり、WebアプリX用の利用許可証を情報操作装置1に送信する際、HTTPリダイレクトでWebアプリXのURLを指定しておけば、WebアプリX用の利用許可証を取得できるのはWebアプリXに限定することができる。言い換えると、HTTPリダイレクトによって利用許可証配布サーバ6が指定したWebアプリ以外のWebアプリに利用許可証が渡る事を防止することができる。これによりWebアプリYはWebアプリXの利用許可証を取得する事を防止でき、上述のように情報出力装置2がWebアプリを混同する事も避けられる。
情報操作装置1は、利用許可証を利用許可証蓄積部24に保存し、Webアプリ実行部22にてWebアプリ#4を実行する(ステップS44)。
以上では、PFアプリ配布サーバ5が配布するPFアプリにローカルWebアプリを含める形態について説明したが、PFアプリ配布サーバ5が配布するPFアプリにWebアプリを含めない形態も可能である。図17はローカルWebアプリを含めない場合のPFアプリの構成を示すブロック図である。図12との違いはローカルWebアプリ#1 82がない点と、WebアプリURL83の値が異なる点である。
図18はPFアプリにローカルWebアプリが含まれない場合における情報出力装置操作フェーズの情報操作装置1、Webアプリ配布サーバ4、利用許可証配布サーバ6の処理手順を示すシーケンス図である。PFアプリを選択して実行する処理(ステップS51)は図13に示した処理と同様である。PFアプリはPFアプリ初期化命令81で初期化処理等を実行した後、Webアプリ実行部呼び出し命令84を実行する。Webアプリ実行部呼び出し命令84はWebアプリURL83で指定されたWebアプリ(Webアプリ#3)をWebアプリ実行部22で実行しようとする。この時、Webアプリ#3はWebサーバ上のURLを示している(ステップS52)。従って、情報操作装置1のWebアプリ取得部27はURLの情報を元にWebアプリ#3を取得するようネットワーク経由でWebアプリ配布サーバ4に要求する(ステップS53)。具体的には情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでWebアプリ(Webアプリ#3)取得要求をWebアプリ配布サーバ4に送信する。この要求は通常のHTTP GETリクエストで行えばよい。
http://example-Webserver.com/input_pin.php?appid=XX
また、HTTP GETリクエストを使う別のURLの例を以下に示す。
http:// example-Webserver.com/appidXX/
Webアプリ配布サーバ4は応答としてWebアプリ#3を返す(ステップS54、S55)。情報操作装置1は取得したWebアプリ#3をWebアプリ実行部22で実行する(ステップS56)。
以降の処理はWebアプリ実行部22でなされる。Webアプリ#3の処理内容はWebアプリ#1と同じでよい。すなわち、利用許可証が情報操作装置1の利用許可証蓄積部24に保存されているかどうかを検査する(ステップS57)。利用許可証蓄積部24に利用許可証が蓄積されていないと判断した場合には、ローカルWebアプリ#3内に記述されたWebアプリ#2のURLを参照して(ステップS58)、そのURLが示すWebアプリ(Webアプリ#2)をWebサーバから取得して実行させる。もし蓄積されていると判断した場合には、ローカルWebアプリ#3内に記述されたWebアプリ#4のURLを参照して、そのURLが示すWebアプリ(Webアプリ#4)を実行させる。
このように、PFアプリにWebアプリを含めないことで、PFアプリの全体ファイルサイズを削減することができるだけでなく、PFアプリをインストールした後でもPFアプリ実行後に実行されるWebアプリの挙動を変更することができる利点がある。
図18に示したように、Webアプリ#3はWebアプリ配布サーバ4上に置かれている。Webアプリ#3をPFアプリに含める場合、Webアプリ#3の開発者は情報操作装置セットアップフェーズまでにWebアプリ#3の実装を完了させておく必要がある。一方、Webアプリ#3をPFアプリに含めない場合、情報出力装置操作フェーズ(レベル1)でWebアプリをダウンロードするまではWebアプリ#3の処理内容や画面デザインを確定させておく必要がない。そればかりか、情報出力装置操作フェーズ(レベル1)を実行するタイミングは各ユーザによって異なるため、キャラクターロゴや案内文など、ある期間にWebアプリ#3に表示させる内容と、別な期間にWebアプリ#3に表示させる内容を別々のものにすることができる。その他にも、ユーザごとにWebアプリ#3で表示させる内容を切り替えることができるといった利点もある。
次に、第1の実施形態における情報出力装置操作フェーズ(レベル2)について説明する。図19はこのフェーズにおける情報操作装置1、Webアプリ配布サーバ4、情報出力装置2の処理手順を示すシーケンス図である。図19は図13及び図18の続きの処理である。
情報操作装置1はWebアプリ#4のURLを取得すると(ステップS61)、Webアプリ配布サーバ4からWebアプリ#4を取得する(ステップS62〜S64)。具体的には情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでWebアプリ(Webアプリ#4)取得要求をWebアプリ配布サーバ4に送信する。ステップS61で取得したURLにはWebアプリ#4のURLと共に利用許可証も含まれているため、Webアプリ#4はこのURLに含まれる利用許可証を利用許可証蓄積部24に保存する(ステップS65)。
その後、Webアプリ#4は情報出力装置2を操作するための画面を生成し、画面出力部17に表示させる。
図20はWebアプリ#4が生成し、情報操作装置1の画面出力部17に出力されるリモコン画面の表示例を示す。情報操作装置1のユーザはマウスやタッチパッドを利用して入力受信部15からボタンやスクロールバーを操作して情報出力装置2を操作する。
ここで、仮に情報出力装置2に対する機器操作命令としてVolume UPボタン(音量(上)ボタン)を押したとする。Webアプリ実行部22上で実行されているWebアプリ#4は入力受信部15から音量(上)命令を受信すると(ステップS66)、利用許可証蓄積部24に保存しておいた利用許可証を取得する。ここで重要な点は情報操作装置1の利用許可証アクセス制御部23である。利用許可証アクセス制御部23は、Webアプリが利用許可証を利用許可証蓄積部24に保存する際、利用可能なWebアプリの範囲を指定する。Webアプリから利用許可証蓄積部24内に蓄積された利用許可証の取得要求があった時には、そのWebアプリが範囲内に一致するか否かを検査し、一致する時のみそのWebアプリに利用許可証の利用を許可する処理を行い、許可する場合には利用許可証を送信する処理を行う(ステップS67)。
利用可能なWebアプリの範囲を指定する情報として、WebアプリのURLの範囲を利用する。つまり、Webアプリ#4は利用許可証を利用許可証蓄積部24に保存する際、URLのドメインの範囲を指定する(ステップS65)。ここではWebアプリ#4は自身のURLのドメインを指定したとする。Webアプリ#4が利用許可証の利用を利用許可証蓄積部24に要求する際、利用許可証アクセス制御部23はWebアプリがWebアプリ#4が指定したドメインの範囲と一致するか否かを検査する。この場合は同一のWebアプリ#4であるためWebアプリ#4は利用許可証を取得することができる。
このように、Webアプリが利用許可証の利用を利用許可証蓄積部24に要求する際、利用許可証アクセス制御部23は、そのWebアプリを配布したWebアプリ配布サーバ4のドメインがWebアプリ#4が指定した範囲と一致するか否かを検査する。
仮にWebアプリ配布サーバ4とは別のドメイン名を持つWebサーバから送信されてきたWebアプリが利用許可証の利用を要求した場合、Webアプリ#4のドメイン名とそのWebアプリのドメイン名は異なるため、利用許可証アクセス制御部23は別のWebサーバから送信されてきたWebアプリに利用許可証を渡さない。これにより、利用許可証の利用を、利用許可証を保存したWebアプリに制限する、または特定のWebサーバ(Webアプリ配布サーバ4)から配布されたWebアプリのみ利用許可証を利用できるようにすることが実現でき、不正なWebアプリが利用許可証を取得することを防止できる。
次に、Webアプリ#4は利用許可証送信部25を使い、Websocketクライアント処理部18を経由してWebsocketのプロトコルにて利用許可証を情報出力装置2に送信する(ステップS68)。この時、情報操作装置1のWebsocketクライアント処理部18内のドメイン付与部70はWebアプリ実行部22で実行中のWebアプリのドメイン名(出所情報)をWebsocketヘッダに付与する処理を行う。Websocketにて利用許可証を送信する方法として、たとえばJSON (JavaScript Object Notation)を用いればよい。
情報出力装置2は、情報操作装置1から利用許可証を受信すると、利用許可証検査部42にて(1)利用許可証に含まれる署名93が正しいか、(2) PIN管理部に蓄積されているPINの値と利用許可証に含まれるPINの値が一致するか検査を行う。さらにアプリ出所検査部43にて(3)利用許可証に含まれるWebアプリのドメイン名がWebsocketヘッダに含まれるドメイン名と一致するか検査を行い(ステップS69)、その検査結果をWebsocketで情報操作装置1に返信する(ステップS70)。
(1)と(2)の検査に関して、利用許可証検査部42はPIN管理部39が予め管理していたPINの値を取得する。そして利用許可証に含まれるWebアプリ固有ID91とWebアプリのドメイン名にPINの値を加えてハッシュ値を求め、そのハッシュ値に対する署名93が正当か否かを公開鍵管理部38に保存されている公開鍵の値を利用して検証する。検証に成功した場合、検査成功と判断する。
(3)の検査に関して、利用許可証にはWebアプリのドメイン名が含まれる。さらに利用許可証を受信したWebsocketコネクションのヘッダにはWebアプリのドメイン名が含まれている。これらのドメイン名が一致もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。
情報操作装置1は、利用許可証を送信した後、Websocketのコネクションで機器操作命令を送信する(ステップS74)が、情報出力装置2の利用許可証検査部42とアプリ出所検査部43は(1)〜(3)のすべての検査が成功した場合には機器利用命令を受け入れるよう機器操作命令処理部34に指示する(ステップS71、S72)。(1)〜(3)の検査が一つでも失敗した場合には、Websocketコネクションを切断するか、あるいは機器操作命令処理部34に対して利用許可証を受信したのと同じWebsocketコネクションで送信されてくる機器操作命令を拒絶するよう指示する(ステップS73)。
機器操作命令処理部34は、利用許可証検査部42とアプリ出所検査部43が許可した時のみ、情報操作装置1からWebsocketで送信された機器操作命令を受け付けて、機器操作命令に従った処理を行う(ステップS74、S75)。例えば、機器操作命令が音量(上)ボタンの場合、画面出力部17に対して出力する音量を上げるように指示する。
なお、これまでの説明では、Webアプリ#2、Webアプリ#3、およびWebアプリ#4を初めてWebアプリ配布サーバ4から取得する場合のシーケンスについて述べてきたが、情報操作装置1がひとたびそれらのWebアプリを取得したならば、Webアプリキャッシュ部13がWebアプリ蓄積部52に保存し、次回、それらのWebアプリを取得する場合にはその都度Webサーバから取得するのではなくWebアプリ蓄積部52に保存されている内容を利用してもよい。このようにする事で、高速にWebアプリの読み込みを行い、機器の反応速度を速める事ができるだけでなく、WebアプリがWebアプリ蓄積部52に保存されている状態になれば情報操作装置1が情報出力装置2と接続可能な状態にあれば、かりに情報操作装置1がインターネットに接続していなくても情報出力装置2に機器操作命令を送信することができる。
なお、これまでの説明では利用許可証の存在を確認するWebアプリ#3と、機器操作WebアプリであるWebアプリ#4が異なるWebアプリである場合を説明してきたが、Webアプリ#3とWebアプリ#4は同一のWebアプリでもよい。その場合、Webアプリ#4のURLはWebアプリ#3と同一であり、Webアプリ#4を取得する処理(ステップS62〜S64)は省略され、Webアプリ#3が利用許可証の保存から機器操作命令の送信までを行う(ステップS65〜ステップS74)。
なお、図3ではWebアプリ実行部22で実行するWebアプリが情報出力装置2に利用許可証を送信する形態を示したが、PFアプリ実行部21が利用許可証を送信してもよい。図21はその場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図である。図3との違いは、Websocketクライアント処理部18がWebアプリ実行部22に接続されていない点と、PFアプリ実行部21に利用許可証送信部25aとWebsocketクライアント処理部18aを備えている点である。
利用許可証送信部25aは、Webアプリ実行部22のWebアプリから渡された利用許可証を受け取ると共に、利用許可証を渡してきたWebアプリを特定し、そのWebアプリの配布元Webサーバのドメイン名を取得する処理を行う。
Websocketクライアント処理部18aは情報出力装置2とWebsocketのプロトコルで通信を行うためのクライアント処理を行う。すなわち図2で示したWebsocketクライアント処理部18と同等の処理を行う。図21はWebsocketクライアント処理部18aがPFアプリ実行部21の中で実行される点が特徴である。装置の構成として冗長ではあるが、情報操作装置1はWebsocketのプロトコルで通信を行うためのクライアント処理を行う処理部として、Websocketクライアント処理部18とWebsocketクライアント処理部18aの両方を備えていても良い。
Webアプリは、利用許可証を情報出力装置2に送信するにあたって、まずPFアプリ実行部21に利用許可証を渡す。この際、情報出力装置2のWebsocketサーバのIPアドレスやTCPポート番号も合わせて渡してもよい。PFアプリ実行部21は、利用許可証送信部25aでWebアプリ実行部22から渡された利用許可証を受け取ると共に、利用許可証を渡してきたWebアプリを特定し、Webアプリ実行部22からそのWebアプリの配布元Webサーバのドメイン名を取得する。そしてWebsocketクライアント処理部18aを使って情報出力装置2とWebsocketのコネクションを確立し、利用許可証を情報出力装置2に送信する。この際、PFアプリ実行部21のWebsocketクライアント処理部18a内のドメイン付与部70aはWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与して情報出力装置2に送信してもよい。
なお、機器操作命令は機器操作命令送信部19によってWebsocketクライアント処理部18aを介して送信されるが、図19と同様にWebsocketクライアント処理部18a内のドメイン付与部70aはWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行う。
図22はこの形態における情報出力装置操作フェーズ(レベル2)における情報操作装置1、Webアプリ配布サーバ4、情報出力装置2の処理手順を示すシーケンス図である。図19との違いは利用許可証の送受信に使うWebsocketコネクション(ステップS88、S90)と、機器操作命令の送受信に使うWebsocketコネクション(ステップS94)が別々になっている点である。利用許可証の送受信に使うWebsocketコネクション(ステップS88、S90)はWebsocketクライアント処理部18aがコネクション確立処理と以降のコネクション管理処理を行い、機器操作命令の送受信に使うWebsocketコネクション(ステップS94)はWebsocketクライアント処理部18がコネクション確立処理と以降のコネクション管理処理を行う。これらの処理以外は、図19と同様である。
情報出力装置2のアプリ出所検査部(検証部)43は機器操作命令の送受信に使うWebsocketコネクション(Websocketコネクション#2)のWebsocketヘッダに含まれるドメイン名が利用許可証に含まれるWebアプリのドメイン名と一致するか検査を行う。一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。利用許可証の送受信に使うWebsocketコネクション(Websocketコネクション#1)のWebsocketヘッダにドメイン名を示すヘッダが含まれている場合、利用許可証に含まれるWebアプリのドメイン名と一致するか検査しても良いししなくても良い。検証する場合、一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。
また、利用許可証送信部25aは、Webアプリのドメイン名と利用許可証に含まれるドメイン名との比較検査処理を行い、一致もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれるか検査し、検査に失敗した場合は以降の情報出力装置2と機器操作命令送信用のコネクションを切断してもよい。
図23はこの形態における情報出力装置操作フェーズ(レベル2)における情報操作装置1、Webアプリ配布サーバ4、情報出力装置2の処理手順を示すシーケンス図を示す。図22との違いは、情報操作装置1が利用許可証を情報出力装置2に送信するに先立って、Webアプリのドメイン名と利用許可証のドメイン名を比較して(ステップS96)、一致しているか否かを検証し(ステップS97)、一致している場合に限り、Websocketコネクション#1で利用許可証を送信する(ステップS87、S88)点である。利用許可証の送受信に使うWebsocketコネクション(ステップS88、S90)はWebsocketクライアント処理部18aがコネクション確立処理と以降のコネクション管理処理を行う。なお、一致していない場合はコネクションを切断するなどのエラー処理を行う(ステップS93)。ステップS97の検証は、例えばPFアプリ実行部21内で実行されるPFアプリが行う。
また、情報操作装置1は、ドメイン名のリストを保持し、そのリストにWebアプリのドメイン名が含まれているか検査処理を行い、含まれない場合には情報出力装置2と機器操作命令送信用のコネクションを切断してもよい。
図24はこの形態における情報操作装置1内のアプリ実行部16、アプリ取得部12、アプリキャッシュ部13の内部構成の一例を示すブロック図である。図21との違いはPFアプリ内にドメインリスト95を備えている点である。ドメインリスト95はPFアプリ内に埋め込まれており、PFアプリ配布サーバ5からPFアプリと共に配布してもよいし、PFアプリ配布サーバ5からドメインリスト95なしのPFアプリを配布してからPFアプリ実行時に不図示のドメインリスト95配布サーバからドメインリスト95をダウンロードするようにしてもよい。
なお、図22、図23でも図19と同様にWebアプリ#3と、Webアプリ#4が異なるWebアプリである場合を説明してきたが、Webアプリ#3とWebアプリ#4は同一のWebアプリでもよい。その場合、Webアプリ#4のURLはWebアプリ#3と同一であり、Webアプリ#4を取得する処理(ステップS82〜S84)は省略され、Webアプリ#3が利用許可証の保存から機器操作命令の送信までを行う(ステップS85〜ステップS94)。
図25はこの形態における情報出力装置操作フェーズ(レベル2)における操作装置、Webアプリ配布サーバ4、情報出力装置2の処理手順を示すシーケンス図を示す。図19との違いは操作装置が利用許可証を情報出力装置2に送信する処理に先立って、PFアプリ内のドメインリスト95にWebアプリのドメイン名が含まれているか検査処理を行い(ステップS98、S99)、含まれている場合に限り利用許可証を送信する(ステップS87、S88)点である。なお、含まれていない場合はコネクションを切断するなどのエラー処理を行う(ステップS93)。
以上の説明では、情報操作装置1が情報出力装置2に対して利用許可証や機器操作命令を送信するためにWebsocketのプロトコルを利用していたが、HTTPまたはHTTPSのプロトコルを利用してもよい。
図26は利用許可証や機器操作命令を送信するためにHTTPまたはHTTPSのプロトコルを利用する形態の情報操作装置1の内部構成を示すブロック図である。図2との違いはWebsocketクライアント処理部18がない点と、機器操作命令送信部19がHTTP処理部11に接続されている点である。
図2ではアプリ実行部16からの命令に基づいて利用許可証と機器操作命令を送信する送信機器操作命令送信部19はWebsocketのプロトコルを用いていたが、図26ではHTTP処理部11を用いてそれらを送信する。なお、図2のWebsocketクライアント処理部18内のドメイン付与部70はWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行っていたが、図26ではHTTP処理部11がWebアプリ実行部22で実行中のWebアプリのドメイン名をHTTPヘッダに付与する処理を行う。
図27は利用許可証や機器操作命令をHTTPまたはHTTPSのプロトコルを利用して受信する形態の情報出力装置2の内部構成を示すブロック図である。図4との違いはWebsocketサーバ処理部40の代わりにHTTPサーバ処理部44がある点である。なお、図4ではアプリ出所検査部43は、Websocketサーバ処理部40で受信した機器操作命令に含まれるWebsocketヘッダの情報が正しいかどうかの検査処理を行っていたが、図27ではWebアプリのドメイン名がHTTPヘッダに含まれるため、アプリ出所検査部43は、その代わりの処理としてHTTPサーバ処理部44で受信した機器操作命令に含まれるヘッダ情報が正しいかどうかの検査処理を行う。具体的には、機器操作命令に含まれるヘッダ情報が、利用許可証に含まれるWebアプリのドメイン名と一致するか検査処理を行い、一致した場合には検査成功と判断する。
次に利用許可証や機器操作命令を送信するためにHTTPまたはHTTPSのプロトコルを利用する場合の情報出力装置操作フェーズ(レベル2)について説明する。図28は情報操作装置1、Webアプリ配布サーバ4、および情報出力装置2の処理手順を示すシーケンス図である。
図19との違いは、利用許可証、利用許可証検査結果、および機器操作命令がHTTPまたはHTTPSのプロトコルにてなされる点である(ステップS108、S110、S114)。これらの処理以外は図19と同様である。
なお、情報操作装置1が情報出力装置2に利用許可証を送信するメッセージの一例を以下に示す。
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である事を送信している。
図28では、Webアプリ#4がHTTP処理部31を使ってHTTPまたはHTTPSのプロトコルにて利用許可証を情報出力装置2に送信する。その際、POSTリクエストを用いればよい。もちろん、PUTリクエストやGETリクエストを用いてもよい。
以上述べてきたように、本実施形態では、情報操作装置1上で動作させるWebアプリから情報出力装置2をネットワーク経由で操作する際、情報操作装置1から送信される機器操作命令の受付に先立ち、情報出力装置2がWebアプリの配布元Webサーバ(Webアプリ配布サーバ4)のドメイン名をチェックする。さらに、情報出力装置2は、情報操作装置1から送信されてくる利用許可証に含まれる情報及び署名93をチェックする。この二つの検査が成功した場合に限り、それ以降、情報操作装置1から送信される機器操作命令を受け付ける。
このようにすることで、以下の効果が得られる。
第一の効果として、機器操作命令の受信を許可されたWebアプリ配布サーバ4に限定することができる。仮に、攻撃者によって情報出力装置2に機器操作命令を送信する命令(例えばWebアプリ#4に含まれる命令)を記述した部分をコピーされてしまい、WebコンテンツXとしてあるWebサーバXにアップロードされてしまったとする。上述したようにWebアプリはHTMLやJavaScriptなどから構成されるが、これらはいわゆるPC上のWebブラウザで表示させるホームページ等のWebコンテンツと変わりはない。従って、情報操作装置1上でWebブラウザ(Webアプリ実行部22)を利用して、各種ホームページなどを閲覧する際、WebコンテンツXを実行してしまうと、情報操作装置1の利用者が気付かぬうちに機器操作命令が情報出力装置2に送信されてしまう。したがって、何も制限がない場合、仮に機器操作命令が情報出力装置2内に録画された放送コンテンツをすべて削除するといった命令であった場合、情報操作装置1上でWebコンテンツXを閲覧しただけで利用者の気が付かないうちに情報出力装置2上の録画コンテンツが消去されてしまう。そこで、Webアプリ配布サーバ4の管理外のWebサーバにWebコンテンツXのような不正なWebアプリが置かれたとしても、情報出力装置2がWebアプリの配布元Webサーバのドメイン名をチェックすることで、それら不正なWebアプリからの操作命令を拒否することができる。
第二の効果として、情報出力装置2の操作をユーザが許可したWebアプリに限定できる。情報出力装置2はデジタルTV等を想定しており、本実施形態に係る情報出力装置2は各家庭あるいは各個人によって所有される。ユーザAの情報操作装置1上で動作させる正規のWebアプリ(例えばWebアプリ#4)からユーザAの情報出力装置2を操作することは問題ない。しかし、ユーザAの情報操作装置1上で動作させる正規のWebアプリから、ユーザBの許諾なしにユーザBの情報出力装置2を操作することは防止する必要がある。情報操作装置1から機器操作命令を送信する度に情報出力装置2の赤外線リモコンを使って確認操作を強いることも可能であるが煩雑である。そこで、情報出力装置2にPINを設定し、情報出力装置2のパスワード(PIN)を含んだ利用許可証を情報操作装置1にインストールする。情報出力装置2は、情報操作装置1から送信された機器操作命令を実行する前に、利用許可証に含まれるPINが正しいか確認する。さらに通信経路上でのPINの値の改ざんを防止するために利用許可証に署名93を添付し、情報出力装置2で署名93を検証する。これにより、情報出力装置2のPINの値を知らないWebアプリによって情報出力装置2が勝手に操作されるのを防止できる。
以上により、TV等の情報出力装置がユーザの許諾なく勝手に操作されるのを確実に防止しつつ、スマートフォンやタブレット等の情報操作装置から情報出力装置を操作できるようになり、情報操作装置を有効活用できるとともに、情報出力装置の使い勝手も向上する。
(第2の実施形態)
第1の実施形態では、利用許可証を発行する利用許可証配布サーバ6と利用許可証を検査して機器操作命令を受け付ける情報出力装置2とが別々の装置であったのに対して、第2の実施形態では、利用許可証配布サーバ6と情報出力装置2とを一体構成にするものである。
図29は第2の実施形態に係る情報出力装置2の内部構成を示すブロック図である。図4に示した情報出力装置2との違いは、ID登録要求送信部37と固有ID管理部36がない点、HTTPサーバ処理部44、利用許可証要求受付処理部45、許可証生成部46、およびWebアプリ情報蓄積部47を新たに備えている点、公開鍵管理部38の代わりに鍵管理部48を備えている点である。
HTTPサーバ処理部44、利用許可証要求受付処理部45、およびWebアプリ情報蓄積部47は図7Aの利用許可証配布サーバ6と同等の機能を有する。
機器検索処理部41は、情報操作装置1からの装置検索要求に応答して、自装置の名前やIPアドレス、Websocketサーバ処理部40のTCPポート番号に加えて、HTTPサーバ処理部44のTCPポート番号を返信する処理を行ってもよい。
鍵管理部48は、利用許可証の署名93の生成に用いる秘密鍵と、利用許可証の署名93の検証に用いる公開鍵の公開鍵ペアを管理する処理を行う。公開鍵のアルゴリズムとしてはRSA暗号や楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。公開鍵ペアの生成方法として、情報出力装置2の工場出荷時に鍵管理部48に書き込む方法、情報出力装置2が鍵管理部48にて公開鍵ペアを生成する方法がある。
利用許可証生成部46は、利用許可証要求メッセージに含まれるWebアプリに固有のIDに対応する利用許可証をWebアプリ情報蓄積部47から取得し、利用許可証、WebアプリID、利用許可証要求メッセージに含まれるPINに対して鍵管理部48に格納した秘密鍵を使って署名93を施し、署名93付き利用許可証を生成する処理を行う。
Webアプリ情報蓄積部47は、WebアプリIDに対応した署名前の利用許可証を蓄積する処理を行う記憶装置であるが、利用許可証は工場出荷時に予めWebアプリ情報蓄積部47に書きこまれるか、HTTPのプロトコルで利用許可証配布サーバ6からインターネット8経由で書き込むようにしておけばよい。以下の例では工場出荷時にWebアプリ情報蓄積部47に書きこまれているものとして説明する。
図30は第2の実施形態における情報操作装置1、情報出力装置2、PFアプリ配布サーバ5、Webアプリ配布サーバ4の処理手順を示すシーケンス図である。図8に示した第1の実施形態のシーケンス図との違いは、図8のステップS1に示す情報出力装置セットアップフェーズがない点と、情報出力装置操作フェーズ(レベル1)で情報操作装置1が利用許可証を情報出力装置2からダウンロードする点(ステップS123)である。
第1の実施形態では、利用許可証配布サーバ6が公開鍵ペアを生成して情報出力装置2に公開鍵を配布したり、その公開鍵に対応する秘密鍵で利用許可証の署名93を生成したりする処理を行っていたが、第2の実施形態では、情報出力装置2に公開鍵ペアが埋め込まれているため、情報出力装置セットアップフェーズは不要である。また、第2の実施形態では、情報出力装置2が利用許可証を生成するため、情報操作装置1は、利用許可証配布サーバ6ではなく、情報出力装置2から利用許可証をダウンロードする。
情報操作装置セットアップフェーズと情報出力装置操作フェーズ(レベル2)は第一の実施形態と同じである。
図31は第2の実施形態における情報出力装置操作フェーズ(レベル1)の情報操作装置1とWebアプリ配布サーバ4の処理手順を示すシーケンス図である。
Webアプリ#2を実行し、PINの入力を促すようなメッセージを情報操作装置1の画面出力部17の画面に表示させるまで(ステップS131〜S139)は図13で示した手順と同様である。入力受信部15からPINが入力されると、Webアプリ#2は利用許可証の要求メッセージを生成する(ステップS140)。具体的にはWebアプリ#2の命令に基づき、情報操作装置1はHTTP処理部31を使ってHTTPS(またはHTTP)のプロトコルで利用許可証の要求メッセージを情報出力装置2に送信する。情報操作装置1が情報出力装置2に送信する利用許可証の要求メッセージの一例を以下に示す。
https://homeTV/req_token.php?appid=X&pin=ZZZZ
この例では、情報出力装置2”homeTV”に対して、appidでラベル付けされた値"X"でWebアプリの固有IDを指定し、pinでラベル付けされた値"ZZZZ"で入力受信部15から入力されたPINの値を指定している。この例から分かるように、情報操作装置1はHTTPS(またはHTTPでもよい)のプロトコルで情報出力装置2に利用許可証の要求メッセージを送信する(ステップS141)。
情報出力装置2は、利用許可証要求メッセージを受信すると、Webアプリ情報蓄積部47に蓄積されたデータを用い、利用許可証生成部46で利用許可証を生成する(ステップS142)。具体的には、情報操作装置1から送信された利用許可証要求メッセージに含まれるWebアプリの固有IDに対応したWebアプリのドメイン名をWebアプリ情報蓄積部47から取得する。そして、Webアプリの固有ID、Webアプリのドメイン名、情報操作装置1から送信された利用許可証要求メッセージに含まれるPINの値に対して、ハッシュ値を計算し、鍵管理部48に保存されている秘密鍵を利用して公開鍵暗号方式に従った署名93を生成する。そして利用許可証要求メッセージへの応答として、利用許可証とWebアプリ#4のURLを情報操作装置1に送信する(ステップS143)。
なお、第1の実施形態と同様に、利用許可証をWebアプリ#4のURLとともに情報操作装置1に送信する手段として、HTTPリダイレクト(HTTP redirect)を使っても良い。その場合、情報出力装置2はHTTPレスポンスのLocationヘッダにWebアプリ#4のURLと利用許可証を含めることになる。情報出力装置2がWebアプリ#4のURLを取得する方法として、情報出力装置2にあらかじめ記憶させておく方法、情報操作装置1が利用許可証の送信要求メッセージを生成する際、Webアプリ#2が送信要求メッセージにWebアプリ#4のURLを含めて情報操作装置1が情報出力装置2に送信し、情報出力装置2が入手する方法がある。
Webアプリ#2が利用許可証の送信要求メッセージにWebアプリ#4のURLを含めて情報出力装置2に送信する際の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と利用許可証を含めて情報操作装置1に送信する。
以降の処理(ステップS144以降)は第一の実施形態と同様である。
以上の例では利用許可証配布サーバ6と情報出力装置2が一体となった構成を示したが、利用許可証要求メッセージ及び利用許可証の送受信は第一の実施形態と同様にHTTP(またはHTTPS)のプロトコルを用いてなされたが、必ずしもこれに限定するものではなくWebsocketのプロトコルを用いてなされてもよい。
図32はWebsocketのプロトコルを用いて利用許可証要求メッセージを情報出力装置2に送信する際の情報操作装置1の構成を示すブロック図である。図2との違いは利用許可証取得部14がHTTP処理部11に接続されておらずWebsocketクライアント処理部18に接続されている点である。
図33はWebsocketのプロトコルを用いて情報操作装置1から利用許可証要求メッセージを受信し、利用許可証を送信する情報出力装置2の構成を示すブロック図である。図29との違いはHTTPサーバ接続部が存在せず、利用許可証要求受付処理部45がHTTPサーバ接続部ではなくWebsocketサーバ処理部40に接続されている点である。
また、情報操作装置1がWebアプリ#2を使って情報出力装置2に送信する利用許可証の要求メッセージがHTTPまたはHTTPSのプロトコルであったのに対し、図32及び図33に示す構成ではWebsocketのプロトコルでなされる点が異なる。それ以外の処理フローは図31に示したものと同様である。
なお、ユーザが入力するPINの値は以降の処理で通信する情報出力装置2に保存されているPINと同じ値である必要がある。ユーザが情報出力装置2のPINを忘れてしまった場合を考慮し、情報操作装置1から情報出力装置2の画面出力部にPINを表示させるよう情報出力装置2に指示してもよい。
図34に情報出力装置2に表示されるPINの画面の表示例を示す。
図35はこの形態における情報出力装置操作フェーズ(レベル1)の情報操作装置1とWebアプリ配布サーバ4の処理手順を示すシーケンス図である。Webアプリ#2を実行し、PINの入力を促すようなメッセージを情報操作装置1の画面出力部17の画面に表示させるまで(ステップS131〜S137)は図31で示した手順と同様である。
図35では、PINの入力を促すようなメッセージを情報操作装置1の画面出力部17の画面に表示させると共に、Webアプリ#2は機器操作命令送信部19に対してPIN表示命令を送信する(ステップS151)。機器操作命令送信部19はWebsocketクライアント処理部18を使ってWebsocketのコネクションでPIN表示命令を情報出力装置2に送信する。
図36はこの形態に係る情報出力装置2の内部構成を示すブロック図である。図33との違いはPIN表示操作部49を備えている点である。
PIN表示操作部49は、情報操作装置1から受信したPIN表示命令を取得し、PIN管理部39からPINを取得して情報出力装置2の画面出力部33に出力する処理を行う(ステップS152)。この際、この画面出力を行う前にアプリ出所検査部43でヘッダ情報の検査処理を行ってもよい。
情報操作装置1のユーザは、PIN管理部39に記憶されているPINの値を覚えておく必要がなく、情報出力装置2の画面出力部33に表示されたPINを見ながら、情報操作装置1の入力受信部15にてPINを入力する(ステップS153)ことができるため、利便性を向上させる事ができる。
次に、情報操作装置1は、Websocketクライアント処理部18を使って情報出力装置2とWebsocketのコネクションを確立し、情報出力装置2に対して、WebsocketのコネクションにてPIN表示終了通知を行う(ステップS154)。この通知を受けて、情報出力装置2は画面出力部33のPIN表示を終了する(ステップS155)。その後は、図31のステップS140〜S144と同様の処理を行う(ステップS156〜S160)。
なお、上記では情報出力装置2が情報出力装置2ごとに固有の公開鍵ペアを使って利用許可証の署名93を生成する例について示したが、機器出荷時に共通の公開鍵ペアを鍵管理部48に設定し、PFアプリに利用許可証を含めてもよい。このようにすることで、情報出力装置操作フェーズ(レベル1)の処理手順を省略してもよい。
このように、第2の実施形態では、利用許可証配布サーバ6と情報出力装置2とを一体化するため、情報操作装置1は、情報出力装置2だけと通信を行うことで利用許可証を取得でき、情報出力装置セットアップフェーズも不要となって、全体的な処理を簡略化できる。
(第3の実施形態)
第1および第2の実施形態で示した利用許可証は図16に示すようにWebアプリ固有ID91、Webアプリの出所92、署名93が含まれていた。第3の実施形態では、Webアプリごとに許可される機器操作命令を分ける構成を示すものである。
図37に第3の実施形態に係る利用許可証のフォーマットの一例を示す。図16に示した利用許可証との違いは、許可された操作命令リスト95を備えている点である。この許可された操作命令リストもWebアプリIDに対応したドメイン名等と同様にWebアプリ情報蓄積部77に蓄積されている。
第1および第2の実施形態では、署名対象のデータとしてWebアプリの固有ID、Webアプリのドメイン名、PINが含まれていたが、第3の実施形態ではこれらのデータに加えて許可された操作命令リストが含まれる。署名の計算方法の一例を以下に示す。
署名=rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名 || PIN || 操作命令リスト))
秘密鍵は情報出力装置情報蓄積部72から取得した情報出力装置2に固有の秘密鍵であり、この値を秘密鍵として署名を計算する。署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名、PIN、操作命令リストを結合してSHA1アルゴリズムを使って計算した値とする。これらの計算結果からRSAアルゴリズムを使って署名が求められる。ここでは署名計算アルゴリズムとしてRSAを使った例を示したが、このほかにも楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。
図38は第3の実施形態に係る情報出力装置2の内部構成を示すブロック図である。第2の実施形態では利用許可証配布サーバ6と情報出力装置2とを一体構成にした例を示したが、ここでは第1の実施形態のように別々の構成の場合について説明する。すなわち、利用許可証は利用許可証配布サーバ6から取得する。図4との違いは、機器操作命令処理部34の中に命令判断部50を備えている点である。
命令判断部50は、情報操作装置1から送信された機器操作命令が利用許可証検査部42から通知された操作命令のリストに含まれていればその機器操作命令を受け付け、含まれていなければ拒絶する処理を行う。
処理のシーケンスに関しては第1の実施形態、第2の実施形態と同様である。
なお、第3の実施形態ではWebアプリごとに利用可能な機器操作命令が異なる事を想定しているが、Webアプリがどのような機器操作命令を実行する可能性があるか、情報操作装置1上の画面でユーザに通知するようにしてもよい。具体的には、図39に示すように、PIN入力用WebアプリにてユーザにPIN入力を促す際、PIN入力Webアプリは情報出力装置2の画面出力部33にWebアプリが操作可能な命令の一覧を出力させるようにしても良い。もちろん、許可された命令の一覧ではなく、上述したカテゴリー番号を表示させるようにしてもよい。
図39に示したPIN入力用Webアプリは、Webアプリ配布サーバ4から情報操作装置1に配信される。Webアプリ配布サーバ4の構成は図7Bに示したものと同様の構成でよいが、Webアプリ蓄積部52にはWebアプリの固有IDに対応したドメイン名と許可された操作命令リストのセットが記憶されている。
第1の実施形態で示したように、情報操作装置1は以下のようなURLでPIN入力用Webアプリの取得要求をWebアプリ配布サーバ4に送信する。
http://example-Webserver.com/input_pin.php?appid=X
Webアプリ配布サーバ4のWebアプリ配布部54はWebアプリの固有IDを元にWebアプリ蓄積部52からその固有IDを持つWebアプリに対応した操作命令リストを取得し、図39に示した操作可能な命令の一覧を出力させる。これにより、ユーザはWebアプリにPIN入力をする前に、Webアプリの操作可能な命令の一覧を知ることができる。たとえば、Webアプリから情報出力装置2に対して特定の操作命令を送信したくないとユーザが判断すれば、PIN入力をしなければよい。このようにしてユーザは危険なWebアプリかどうかを自分で判断することができる利点がある。情報出力装置2は情報出力装置操作フェーズ(レベル2)で利用許可証を受信し、利用許可証検査部42とアプリ出所検査部43で検査が成功すると、操作命令リスト95に含まれる機器操作命令を解釈して、どの機器操作命令を許可するかを機器操作命令処理部34に通知する。機器操作命令処理部34の命令判断部50は、情報操作装置1から送信された機器操作命令が利用許可証検査部42から通知された操作命令のリストに含まれていればその機器操作命令を受け付け、含まれていなければ拒絶する処理を行う。
利用許可証配布サーバ6の利用許可証生成部79(第1の実施形態)、または情報出力装置2の利用許可証生成部46(第2の実施形態)で利用許可証を生成する際、どのWebアプリにどの機器操作命令を許可するか、すなわち利用許可証の操作命令リスト95をWebアプリごとに異なるものにすることで、Webアプリ#Xは情報出力装置2に対してチャンネル変更命令とコンテンツの一覧表示命令、コンテンツの消去機能命令を許可するが、Webアプリ#Yは情報出力装置2に対してチャンネル変更命令とコンテンツの一覧表示命令しか許可しないといったことが実現できる。
なお、操作命令リスト95は機器命令を一つ一つリストしてもよいし、複数の機器命令をカテゴリーに分類してもよい。その場合、例えばチャンネル変更命令とコンテンツの一覧表示命令はカテゴリー1、コンテンツの消去命令をカテゴリー2と分類し、操作命令リスト95にはWebアプリに許可するカテゴリー番号を含めるようにし、命令判断部50は情報操作装置1から送信された機器操作命令が属するカテゴリーが操作命令リスト95に含まれるか否かの検査を行い、含まれる場合のみその機器操作命令を許可するようにしても良い。
さらに、カテゴリーに優先順位をつけたレベルとしてとらえ、操作命令リスト95にはWebアプリに許可する最も高い番号を含めるようにする。操作命令リスト95にカテゴリー2と記されている場合はカテゴリー1とカテゴリー2に含まれる機器操作命令を許可すると定義してもよい。命令判断部50は情報操作装置1から送信された機器操作命令が属するカテゴリーと、操作命令リスト95に含まれるカテゴリーの番号の大きさを比較し、機器操作命令が属するカテゴリーが操作命令リスト95に含まれるカテゴリーの番号より小さければ機器操作命令を許可するようにする。例えば、操作命令リスト95にはカテゴリー2を含め、情報操作装置1が送信する機器操作命令がチャンネル変更命令だった場合 、チャンネル変更命令はカテゴリー1のため、この命令を許可する。一方、操作命令リスト95にはカテゴリー1を含め、情報操作装置1が送信する機器操作命令がコンテンツ削除命令だった場合 、コンテンツ削除命令はカテゴリー2で操作命令リスト95に含まれているカテゴリー1より大きいためこの命令を拒否する。
このように、第3の実施形態では、Webアプリごとに利用可能な機器操作命令を分ける事を実現している。例えば、WebアプリXはチャンネル変更命令とコンテンツの一覧表示命令が許可されており、WebアプリYはチャンネル変更命令のみ許可されている場合を考える。つまり、WebアプリX用の利用許可証に含まれる許可された操作命令リストとWebアプリYの利用許可証に含まれる許可された操作命令リストは異なる。さらに、Webアプリ配布サーバ4の説明で述べたように、Webアプリ配布サーバ4が同一ドメインの中に複数のWebアプリを格納する場合を考える。この時、WebアプリXとWebアプリYは同一のドメイン名を有するWebアプリ配布サーバ4から配布されることになり、利用許可証に含まれるWebアプリの出所も同じ値となる。
ここで、WebアプリYがWebアプリWebアプリX用の利用許可証を入手し、情報装置操作フェーズ(レベル2)でそのWebアプリX用の利用許可証を使って機器操作命令を情報出力装置2に送信したとしても、WebアプリXとWebアプリYは出所が同一のため、情報出力装置2はその利用許可証を見てWebアプリXに許可された操作が可能となってしまう。つまり、WebアプリYは本来許可されていないにも関わらず、コンテンツの一覧表示命令を情報出力装置2で実行させる事が可能になってしまう。
そこで、HTTPリダイレクトを利用して、利用許可証配布サーバ6が、その利用許可証を取得するWebアプリをURLによって指定する事で、利用許可証配付サーバ6は利用許可証が取得可能なWebアプリを制限する事ができる。つまり、WebアプリX用の利用許可証を情報操作装置1に送信する際、HTTPリダイレクトでWebアプリXのURLを指定しておけば、WebアプリX用の利用許可証を取得できるアプリをWebアプリXに限定することができる。これにより、WebアプリX用の利用許可証がWebアプリX以外に取得される事を防ぐ事ができる。
また、第1の実施形態では、情報操作装置1のPFアプリ内にドメインリストを持たせ、ダウンロードしたWebアプリのドメイン名がドメインリストに含まれるかどうか検査処理を行う例について示したが、その場合、利用許可証にWebアプリのドメイン名を含める必要は必ずしもない。その場合の利用許可証のフォーマットの一例を図40に示す。図37に示した利用許可証との違いは、許可されたWebアプリの出所92を備えていない点である。
このように、第3の実施形態では、Webアプリに許可される機器操作命令のリストを利用許可証に含めることで、許可する機器操作命令をWebアプリ毎に異ならせることができる。例えば、情報出力装置2の製造メーカーが開発するWebアプリに対してはすべての機器操作命令を許可し、情報出力装置2の製造メーカーのパートナー企業が開発したWebアプリには許可する機器操作命令を制限することが可能となる。また、特別なライセンスを締結した情報出力装置2の製造メーカーのパートナー企業に対してはその制限を緩めるといったようなビジネスを展開することも可能となる。
(第4の実施形態)
第1、第2および第3の実施形態では、Webアプリ配布サーバ4が同一ドメインの中に複数のWebアプリを格納する場合を想定していた。以下に説明する第4の実施形態では、Webアプリ配布サーバ4は同一ドメインの中に複数のWebアプリを格納してもよいが、それらのWebアプリが同一の利用許可証を利用するという制限をつけることで、利用許可証配布サーバ6の処理内容を削減するものである。
図41は第4の実施形態における情報操作装置1、情報出力装置2、PFアプリ配布サーバ5、およびWebアプリ配布サーバ4の処理手順を示すシーケンス図である。図30に示した第2および第3の実施形態のシーケンス図との違いは、情報出力装置操作フェーズ(レベル1)で情報操作装置1が利用許可証配布サーバ6との通信を介さずPINを入力する手順(ステップS162)が追加された点と、情報出力装置操作フェーズ(レベル2)で利用許可証をダウンロードする手順(ステップS161)と、情報操作装置1が情報出力装置2と通信する処理手順(ステップS163)とが異なる点である。
なお、以後の説明では第3の実施形態との差分を示すが、この実施形態のポイントは利用許可証のフォーマットの中でも署名部分を変更し、利用許可証配布サーバ6の処理内容を削減する点にある。第4の実施形態の特徴部分は、第1の実施形態または第2の実施形態にも適用可能である。
第3の実施形態では、情報出力装置操作フェーズ(レベル1)で情報操作装置1は情報出力装置2から利用許可証を受信する際に、入力されたPINを情報出力装置2に送信していたが、第4の実施形態では、PINは情報操作装置1に保存され(ステップS162)、利用許可証要求時には情報出力装置2に送信しない。さらに第3の実施形態では利用許可証を情報出力装置2から受信していたが、第4の実施形態では第1の実施形態と同様、情報操作装置1は利用許可証配布サーバ6から利用許可証を受信する(ステップS161)。なお、この実施形態では利用許可証は情報出力装置2に固有の値ではない。また、利用許可証は事前に計算しておくことが可能であるため、利用許可証配布サーバ6から配信される必要もなく、Webアプリ配布時またはPFアプリ配布時に生成しておく事が可能であり、利用許可証をPFアプリ配布時にリソースの一つとして配布する事が可能である。このような場合、利用許可証は利用許可証からダウンロードする必要はない。つまり、ステップS161は省略可能である。以下では、まず利用許可証配布サーバ6から配信する例について述べる。ただし、利用許可証のフォーマット(データ構造)は異なる。利用許可証のフォーマットについては後述する。
さらに、第3の実施形態では、情報出力装置操作フェーズ(レベル2)で情報操作装置1は利用許可証のみを情報出力装置2に送信していたが、第4の実施形態では利用許可証に加えて、情報出力装置操作フェーズ(レベル1)で保存しておいたPINを送信する(ステップS163)。
図42に第4の実施形態に係る利用許可証のフォーマットの一例を示す。図37に示した利用許可証との違いは、署名93aの計算方法である。第3の実施形態では署名対象のデータとしてWebアプリの固有ID、Webアプリのドメイン名、およびPINが含まれていた。第4の実施形態ではPINを含まず、Webアプリの固有IDとWebアプリのドメイン名しか含まない。さらに、第3の実施形態では秘密鍵は情報出力装置2に固有の値となっていたが、第4の実施形態では複数の情報出力装置2に共通の値となる。署名の計算方法の一例を以下に示す。
署名=rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名|| 操作命令リスト)) 秘密鍵に対応する公開鍵は複数の情報出力装置2で共有される。この値を秘密鍵として署名を計算する。署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名、操作命令リストを結合してSHA1アルゴリズムを使って計算した値とする。これらの計算結果からRSAアルゴリズムを使って署名が求められる。ここでは署名計算アルゴリズムとしてRSAを使った例を示したが、このほかにも楕円曲線暗号など良く知られた公開鍵アルゴリズムを用いればよい。
なお、操作命令リストはオプションであり、必ずしも署名の計算に含める必要はない。その場合の署名計算の方法の一例を以下に示す。
署名=rsa (秘密鍵, sha1(Webアプリの固有ID || Webアプリのドメイン名))
この場合、署名の対象となるデータとしては、Webアプリの固有ID、Webアプリのドメイン名を結合してSHA1アルゴリズムを使って計算した値とする。
図43は第4の実施形態に係る利用許可証配布サーバ6の内部構成を示すブロック図である。図7Aとの違いは、図7Aの利用許可証配布サーバ6よりも内部構成を簡略化させ、HTTPサーバ処理部71、利用許可証登録受付処理部80、利用許可証生成部79、Webアプリ情報蓄積部77、および利用許可証検索処理部57のみを有する点である。
HTTPサーバ処理部71、利用許可証登録受付処理部80は、図7Aに示したものと同等の処理を行う。なお、利用許可証登録受付処理部80は必須の構成ではない。
Webアプリ情報蓄積部77は署名済み利用許可証を蓄積する処理を行う。
利用許可証生成部79は、利用許可証を生成する処理を行う。利用許可証のフォーマットは第3の実施形態と異なるため、利用許可証を生成する処理も異なる。図7Aでは情報出力装置2に固有の秘密鍵を生成し、情報出力装置情報蓄積部72に保存し、その秘密鍵で利用許可証の署名を生成していた。第4の実施形態では複数の情報出力装置2に共通の秘密鍵によって利用許可証の署名を生成する。なお、この秘密鍵に対応する公開鍵は情報出力装置2の公開鍵管理部38にあらかじめ蓄積されている。つまり、第4の実施形態では利用許可証を生成するために情報出力装置2の情報は不要であるため、情報出力装置2と通信する事なく利用許可証を生成することが可能である。利用許可証は、情報出力装置2に共通の公開鍵に対応する秘密鍵を持った装置であれば生成することができるため、必ずしも利用許可証配布サーバ6で行う必要はない。不図示の情報出力装置2に共通の公開鍵に対応する秘密鍵を備えた装置で利用許可証を生成し、Webアプリ情報蓄積部77に登録してもよい。利用許可証配布サーバ6で利用許可証の署名計算処理を行わない場合は、利用許可証生成部79は必須の構成ではない。その場合、利用許可証登録受付処理部80は署名済み利用許可証を受け付け、そのままWebアプリ情報蓄積部77に蓄積する処理を行う。
利用許可証検索処理部57は、情報操作装置1からの要求に基づいてWebアプリ情報蓄積部77に蓄積しておいた署名済み利用許可証を検索し、HTTPサーバ処理部71を利用して情報出力装置2に送信する処理を行う。具体的な処理の例としては、情報操作装置1はWebアプリ固有IDを指定し、利用許可証検索処理部57はその指定されたWebアプリ固有IDをキーとしてWebアプリ情報蓄積部77に蓄積されている利用許可証を取得して、情報操作装置1に送信する処理を行う。
第3の実施形態では情報操作装置1からの利用許可証要求に基づき、その利用許可証要求に含まれる情報出力装置2に固有のIDを元に、情報出力装置2とWebアプリに固有の利用許可証を生成する処理が必要であった。しかし、第4の実施形態ではWebアプリ情報蓄積部77に蓄積されている利用許可証を検索して取得する処理を行えばよく、署名生成のための暗号処理などを行う必要がないため、利用許可証配布サーバ6にとって必要とする計算処理能力を大幅に削減することができる。また、第3の実施形態では生成する利用許可証の個数はWebアプリの数に情報出力装置の数を掛け合わせた数となっていた。しかし、第4の実施形態では利用許可証は情報出力装置2に固有ではなく、Webアプリにのみ固有であるため、生成すべき利用許可証の数はWebアプリの数と同一になり利用許可証の生成処理を大幅に削減することができる。また、第3の実施形態では利用許可証の生成処理を情報操作装置1からの利用許可証要求に基づき都度行う事を想定していたが、第4の実施形態ではWebアプリの個数分だけ事前に利用許可証を生成しておくことも可能である。このように、第4の実施形態では利用許可証配布サーバ6の処理を簡略化することができる。
図44は第4の実施形態に係る情報出力装置2の内部構成を示すブロック図である。図38との違いは、PIN入力Webアプリ生成・送信部58とPIN検査部59を新たに備えている点と、図38の固有ID管理部36、MAC鍵管理部56、およびID登録要求送信部37を備えていない点である。
PIN入力Webアプリ生成・送信部58は図15に示したように情報操作装置1でPIN入力画面を表示するためのWebアプリ(PIN入力用Webアプリ)を生成し、情報操作装置1に送信する処理を行う。なお、画面操作装置1からPIN入力用Webアプリの要求メッセージの中に利用許可証の署名が含まれている場合、PIN入力Webアプリ生成・送信部58は公開鍵管理部38に蓄積されている公開鍵で利用許可証の署名の正当性を検証し、検証が成功した場合のみPIN入力用Webアプリを画面操作装置1に送信するようにしても良い。これは、画面操作装置1から送信される利用許可証に含まれる情報、たとえば許可された操作命令リストが通信途中で改ざんされていた時に有用である。たとえば、あるWebアプリがチャンネル変更命令とコンテンツの一覧表示命令が許可されているとする。しかし通信経路上で許可された操作命令リストがコンテンツの一覧表示命令しか要求しないと改ざんされてしまうと、それを受信した画面出力装置2は図39の画面として「コンテンツの一覧表示命令」が可能と表示してしまう。これを見たユーザは、本来、そのWebアプリがチャンネル変更命令とコンテンツの一覧表示命令実行可能であるにも関わらず、コンテンツの一覧表示命令しか実行する権限がないと誤って判断してPINを入力してしまうかもしれない。一方で、情報出力装置2はWebアプリ情報蓄積部を有しないため、そのWebアプリがどのような許可された操作命令リストを有しているか分からない。しかし、情報出力装置2で利用許可証の署名検証処理を行うことで、利用許可証の内容が正しいか確かめることができるため、PIN入力用Webアプリに、利用許可証と同じ許可された操作命令リストを表示させる事ができるようになる。これにより、ユーザにPIN入力Webアプリの正しい表示内容を出力させる事が可能となる。
PIN検査部59は情報操作装置1からWebsocketのコネクションで送信されてきたPINがPIN管理部39に登録されている値と一致するか否か検査を行い、その結果を機器操作命令処理部34に通知する処理を行う。
図45は第4の実施形態に係る情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図である。図3との違いはPIN保存部60を備えている点である。
PIN保存部60は入力受信部15で受信したPINの値を一時的に保存する処理を行う。
図46乃至図48は第4の実施形態における情報出力装置操作フェーズ(レベル1、レベル2)の情報操作装置1と、利用許可証配布サーバ6、Webアプリ配布サーバ4、および情報出力装置2の処理手順を示すシーケンス図である。情報出力装置セットアップフェーズは第2の実施形態と同様不要である。情報操作装置セットアップフェーズは第1の実施形態または第2の実施形態と同様の手順でよい。
PFアプリを実行し(ステップS171)、ローカルWebアプリを実行する(ステップS172)までは図31のステップS131,S132と同じである。なお、この例ではローカルWebアプリとしているが、図18で示したようにPFアプリはURLのみ備え、PFアプリ実行部21からWebアプリ取得部27にURLを渡し、Webアプリ取得部27がWebアプリ配布サーバ4に対してそのURLを元にWebアプリの送信要求を送信してWebアプリ配布サーバ4からWebアプリをダウンロードし、Webアプリ実行部22にてそのWebアプリを実行するようにしてもよい。
ローカルWebアプリ(Webアプリ#5)は、まず情報操作装置1の中に利用許可証が存在するかどうかチェックする(ステップS173)。もし既に利用許可証を取得している場合はステップS178に進む。
なお、前述のように本実施形態では利用許可証は情報出力装置2の固有IDには依存せず、操作対象の情報出力装置が異なっていたとしても、同じWebアプリであれば利用許可証も同じものとなる。従って、利用許可証を含んだ形でPFアプリをパッケージ化して配布してもよい。その場合、PFアプリがインストールされる際、利用許可証はアプリ蓄積部30にPFアプリのデータの一部として記憶される。その場合は、利用許可証が存在するかどうかを検査する処理を省略し、Webアプリはアプリ蓄積部30から利用許可証を取得するようにしても良い。
情報操作装置1の中に利用許可証がない場合、Webアプリごとに決められ、あらかじめアプリケーションパッケージの中に含まれているURLを取得して(ステップS174)、このURLを元に利用許可証取得要求を利用許可証配布サーバ6に送信する(ステップS175)。この処理はHTTP処理部11を用いてHTTP(またはHTTPS)のプロトコルで送信する。情報操作装置1が利用許可証配布サーバ6に送信する利用許可証の要求メッセージの一例を以下に示す。
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”という名前で指定される単なるファイルにすぎないため、利用許可証配布サーバ6はWebアプリ配布サーバ4と同じ構成を取ればよい。
第4の実施形態では、利用許可証はWebアプリ毎に固有の値であるが、情報出力装置2には固有ではないため要求メッセージの中に情報出力装置2に固有のIDは含めない。さらに利用許可証はPINを含めて計算する必要がないため、要求メッセージにPINの値も含めない。
利用許可証配布サーバ6は、利用許可証要求メッセージを受信すると、Webアプリの固有IDを元にWebアプリ情報蓄積部77に蓄積された署名済み利用許可証を取得し、利用許可証要求メッセージへの応答として、利用許可証を情報操作装置1に送信する(ステップS176)。
Webアプリ#5は受信した利用許可証を利用許可証蓄積部24に保存する(ステップS177)。なお、第3の実施形態では情報操作装置1が利用許可証を保存する際、利用許可証配布サーバ6が利用許可証を利用可能なWebアプリの範囲を指定し、Webアプリが利用許可証を利用する際に、利用許可証アクセス制御部23を用いて、保存した利用許可証のアクセス制御の処理を行っていたが、第4の実施形態では必ずしもこの処理は必要ない。つまり、第4の実施形態では利用許可証アクセス制御部23は必須の構成ではない。
次に、Webアプリ#5は情報操作装置1の中にPINが含まれているかどうかを検査する(ステップS178)。既にPINが含まれている場合は、Webアプリ#5の中に含まれるURLを元に機器操作Webアプリを取得する。PINが含まれていない場合、Webアプリ#5の中に含まれるURLを元にPIN画面の要求メッセージを生成し(ステップS179)、情報出力装置2にPIN入力用Webアプリの送信を要求する(ステップS180)。具体的には情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでPIN入力用Webアプリ(Webアプリ#6)の取得要求を情報出力装置2に送信する。この要求メッセージの例を以下に示す。
http://example-Webserver.com/input_pin.php?appid=X&origin=xxxx&signature=yyyy&signature_method=rsa-sha1
上述したように情報出力装置2が利用許可証の署名検証を行えるように、署名済み利用許可証を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
情報出力装置2はPIN画面の要求メッセージを受信すると、PIN入力Webアプリ生成・送信部58にてPIN入力用Webアプリ(Webアプリ#6)を生成する(ステップS182)。この際、公開鍵管理部38に蓄積されている公開鍵を用いて利用許可証の署名の検証を行っても良い(ステップS181)。
情報操作装置1はWebアプリ#6を受信すると(ステップS183)、Webアプリ実行部22にてWebアプリ#6を実行する。PIN入力用WebアプリであるWebアプリ#6の画面イメージは図15に示したとおりである。Webアプリ#6は入力受信部15で入力したPINの値を取得すると(ステップS184)、PINを保存して(ステップS185)、Webアプリ#6に含まれるURLまたはWebアプリ#5に含まれるURLを取得して(ステップS186)、そのURLから機器操作Webアプリ(Webアプリ#7)の取得要求を生成して、Webアプリ配布サーバ4に送信する(ステップS187)。具体的にはWebアプリ#6の指示に従って情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルで機器操作Webアプリ(Webアプリ#7)の取得要求をWebアプリ配布サーバ4に送信する。これを受けて、Webアプリ配布サーバ4はWebアプリ#7を情報操作装置1に送信する(ステップS188)。
なお、第3の実施形態では、情報操作装置1が利用許可証を取得するために入力したPINの値が利用許可証要求のメッセージに含まれて情報出力装置2に送信されたが、本実施形態では利用許可証を取得するためにPINの値は不要である。このため、利用許可証を取得するためにPINは送信されない。
その後、情報操作装置1はWebアプリ配布サーバ4からWebアプリ#7を取得して(ステップS189)、Webアプリ実行部22にて実行する。
Webアプリ#7はPINと保存しておいた利用許可証を取得する(ステップS190)。ここでは、ステップS185で入力して保存してあったPINを利用する。ステップS185にてPINを保存しておく方法として、利用許可証と同様にブラウザのcookieにファイルとして保存しておく方法と、ハッシュフラグメントとして保存しておく方法の二通りがある。
cookieとして保存しておく場合、Webアプリ#6はPINの値がWebアプリ#7で取得可能なようにURLの範囲を設定しておく。Webアプリ#7はPINの値をcookieから取得する際、利用許可証と同様に利用許可証アクセス制御部23にて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アプリ配布サーバ4に対してWebアプリ#7を取得するメッセージを送信するように指示している。ハッシュフラグメントのためPINはWebアプリ配布サーバ4には送信されない。なお、PIN入力用Webアプリの構成を容易にするために、Webアプリ配布サーバ4にPINの値を送信するようにしてもよい。
Webアプリ#7は取得したPINと利用許可証をWebsocketのコネクションを利用して情報出力装置2に送信する(ステップS192、S193)。具体的には、Webアプリ#7の指示に基づき、情報操作装置1のWebsocketクライアント処理部18はWebsocketコネクションにて情報出力装置2にPINと利用許可証を送信する。この時、Websocketクライアント処理部18内のドメイン付与部70はWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行う。すなわち、PINと利用許可証を送信するWebsocketのコネクションのヘッダにはWebアプリ実行部22で実行中のWebアプリ(Webアプリ#7)のドメイン名が含まれて情報操作装置1から情報出力装置2に送信される。情報出力装置2は、利用許可証に含まれるWebアプリのドメイン名がWebsocketヘッダに含まれるドメイン名が一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。
情報出力装置2は受信した利用許可証とPINの値を検査する(ステップS194)。利用許可証の検査は利用許可証検査部42が行い、利用許可証に含まれる署名が正しいか否かを検査する。PINの検査はPIN検査部59が行い、PIN管理部39で管理している値と一致するか否かを検査する。情報操作装置1は、ドメインの検査と利用許可証の検査とPINの検査のすべてに成功したか否かを判定する。判定結果は、情報出力装置2から情報操作装置1に送信してもよい(ステップS195)し、検査結果が失敗した場合、情報出力装置2はWebsocketのコネクションを切断するようにしてもよい。
情報出力装置2から情報操作装置1に判定結果を送信する場合、情報操作装置1はその判定結果に基づき、判定結果が失敗の場合にはエラー処理を行い(ステップS198)、判定結果が成功の場合には機器操作命令を送信する(ステップS197)。
なお、情報出力装置2が判定処理を失敗と判定してWebsocketのコネクションを切断した場合、情報操作装置1はコネクション切断をもって判定結果が失敗と判断し、エラー処理を行い(ステップS198)、Websocketコネクションが切断されなかった場合は機器操作命令を送信するようにしてもよい(ステップS197)。
そして機器操作Webアプリ(Webアプリ#7)の指示に基づき、情報操作装置1のWebsocketクライアント処理部18はWebsocketコネクションにて情報出力装置2に機器操作命令を送信する(ステップ199)。
利用許可証とPINの両方の検査が成功すると、情報出力装置2は、その後に情報操作装置1から送信される機器操作命令を受け付ける。もし片方でも検査が失敗していれば、機器操作命令は拒否してエラー処理を行い、以降の機器操作命令は受け付けない。第3の実施形態と同様、両方の検査が成功した場合に限り、操作命令リストに含まれる機器操作命令を解釈して、どの機器操作命令を許可するかを機器操作命令処理部34に通知する。その後の処理(ステップS199、S200)は図19と同じでよい。
なお、図46〜図48ではWebアプリ#5と、Webアプリ#7が異なるWebアプリである場合を説明してきたが、Webアプリ#5とWebアプリ#7は同一のWebアプリでもよい。その場合、Webアプリ#7のURLはWebアプリ#5と同一であり、Webアプリ#7を取得する処理(ステップS185〜S187)は省略され、Webアプリ#5が利用許可証の取得から機器操作命令の送信までを行う(ステップS188〜ステップS197)。
このように、第4の実施形態では、複数の情報出力装置2が共通の利用許可証を所持するように利用許可証のデータ構造を変更した。これにより、利用許可証配布サーバ4の処理内容を削減する事ができる。
(第5の実施形態)
第3の実施形態ではWebアプリごとに許可される機器操作命令を分ける構成を示した。また、第4の実施形態では、同一ドメイン内の複数のWebアプリが同一の利用許可証を利用する構成を取り、かつ情報操作装置1はPIN入力用Webアプリを情報出力装置2から取得する例を示した。以下に説明する第5の実施形態では、Webアプリごとに許可される機器操作命令を分け、同一ドメイン内の複数のWebアプリが同一の利用許可証を利用する構成を取るが、情報操作装置1はPIN入力用WebアプリをPIN入力用Webアプリ配布サーバ4aから取得する構成を取る。
図49Aは第5の実施形態に係る情報操作装置1の内部構成を示すブロック図である。図24との違いは、Webアプリ実行部22内にPIN保存部60を備えていることと、PFアプリ実行部21内のWebsocketクライアント処理部18aは利用許可証に加えてPINも送信する点である。
PIN保存部60は、ユーザが入力したPINの値を保存する処理を行う。PINを保存する方法として、たとえばブラウザのcookieにファイルとして保存する方法がある。
なお、利用許可証アクセス制御部23は利用許可証蓄積部24に蓄積した利用許可証をWebアプリ配布サーバ4のドメイン毎に管理する機能と共に、PIN保存部60に蓄積したPINの値をWebアプリ配布サーバ4のドメイン毎に管理する機能も有する。
図50は第5の実施形態に係るPIN入力用Webアプリ配布サーバ4aの内部構成を示すブロック図である。PIN入力用Webアプリ配布サーバ4aは、HTTPサーバ処理部51、Webアプリ蓄積部52、Webアプリ登録処理部53、Webアプリ配布部54、利用許可証検査部65、および公開鍵管理部66を備えている。HTTPサーバ処理部51、Webアプリ蓄積部52およびWebアプリ登録処理部53は図5に示したWebアプリ配布サーバ4と同等の機能を有する。
公開鍵管理部66は、情報操作装置1からPIN入力用Webアプリ送信要求と共に送信されてくる利用許可証を検証するための公開鍵を蓄積する処理部である。
利用許可証検査部65は、情報操作装置1からPIN入力用Webアプリ送信要求と共に送信されてくる利用許可証を、公開鍵管理部66に蓄積された公開鍵を用いて署名検証処理を行う。
Webアプリ配布部54は、PIN入力用Webアプリを情報操作装置1に送信するに先立ち、利用許可証検査部65に利用許可証を送信し、その応答として署名検証の結果を受信する。署名検証の結果が成功した場合にのみPIN入力用Webアプリを情報操作装置1に送信する。署名検証処理が失敗した場合には、PIN入力用Webアプリを情報操作装置1に送信しない。なお、この署名検証処理は必須の構成ではない。
図51Aは第5の実施形態に係る情報出力装置2の内部構成を示すブロック図である。図44との違いは、HTTP処理部31とPIN入力Webアプリ生成・送信部58を備えていない点である。第5の実施形態では情報操作装置1はPIN入力用WebアプリをPIN入力用Webアプリ配布サーバ4aから受信するため、情報出力装置2がこの機能を備える必要はない。それ以外の構成は図44と同じである。
図52と図53Aは第5の実施形態における情報出力装置操作フェーズ(レベル1、レベル2)の情報操作装置1と、PIN入力用Webアプリ配布サーバ4、Webアプリ配布サーバ4、および情報出力装置2の処理手順を示すシーケンス図である。情報出力装置セットアップフェーズは第4の実施形態と同様に不要である。情報操作装置セットアップフェーズは第1の実施形態または第2の実施形態と同様の手順でよい。
ステップS178までは図46と同様の処理手順をふめばよい。
PINが存在しない場合、情報操作装置1のローカルWebアプリ(Webアプリ#5)はPIN入力用Webアプリ取得要求をPIN入力用Webアプリ配布サーバ4aに送信する(ステップS201、S202)。具体的にはWebアプリ#5の命令に基づき、情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでPIN入力用Webアプリ(Webアプリ#8)の取得要求をPIN入力用Webアプリ配布サーバ4aに送信する。情報操作装置1がPIN入力用Webアプリ配布サーバ4aに送信する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アプリ配布サーバ4aにPIN入力用Webアプリを要求する際のリクエストとして利用許可証を送信する理由は、第4の実施形態と同様、通信経路上での許可された操作命令リストの改ざんを検出し、PIN入力用Webアプリに、利用許可証と同じ許可された操作命令リストを表示させる事ができるようにするためである。ローカルWebアプリのURLを指定している理由は、Webアプリ#8でPINを入力後に、ローカルWebアプリに移動できるようにするためである。
PIN入力用Webアプリ配布サーバ4aは公開鍵管理部66に蓄積されている利用許可証検証用の公開鍵を使って、情報操作装置1から送信されてきた利用許可証の内容が正しいか、利用許可証に含まれる署名を検証する(ステップS203)。署名検証が成功すれば、利用許可証の情報を利用してWebアプリ#8(PIN入力用Webアプリ)を生成し(ステップS204)、情報操作装置1に送信する(ステップS205)。
情報操作装置1は、Webアプリ#8を受信してWebアプリ実行部22で実行する(ステップS206〜S210)。Webアプリ#8は図39に示したような画面を画面出力部17に表示する。Webアプリ#8は下記のようなプログラムを内包している。
<form method="POST" action=" http://example-Webserver.com/appid5#">
<input type="text" name="PIN">
<input type="submit" value="送信">
PINが入力されると、以下のURLに移動する。具体的にはWebアプリ#8の指示に従って情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでWebアプリ#5の取得要求をWebアプリ配布サーバ4に送信する。
http://example-Webserver.com/appid5#pin
ここで”pin”は入力されたPINの値を示す。ハッシュフラグメントのためPINの値はWebアプリ配布サーバ4には送信されない。Webアプリ#5は、PINの値をPIN保存部60に保存する。この時、PINの値がWebアプリ#5で取得可能なようにURLの範囲を設定しておく。Webアプリ#5はPINの値をcookieから取得する際、利用許可証と同様に利用許可証アクセス制御部23にてWebアプリ#5で取得可能かどうか判定され、取得可能である場合にはWebアプリ#5はPIN保存部60からPINを取得する事ができる。
なお、Webアプリ#5がアプリキャッシュ部13のWebアプリキャッシュ部29に保存されている場合、Webアプリ取得部27はHTTP処理部31を使ってWebアプリ配布サーバ4にWebアプリ#5の取得要求を送信する必要はなく、その代わりにWebアプリ取得部27はWebアプリキャッシュ部29に保存されているWebアプリ#5を取得し、Webアプリ実行部22で実行するようにしてもよい。
Webアプリ#5がPINと、保存しておいた利用許可証を取得する処理からPINと利用許可証を送信する処理(ステップS211〜S213)までは図48のステップS190〜S192までと同様である。
その後、機器操作Webアプリ(Webアプリ#5)の指示に従って、情報操作装置1は、Websocketクライアント処理部18aを使って情報出力装置2とWebsocketのコネクション(Websocketコネクション#1)を確立し、情報出力装置2に対して、WebsocketのコネクションにてPINと利用許可証を送信する(ステップS214)。
情報出力装置2は受信した利用許可証とPINの値を検査し(ステップS215)、判定結果を情報操作装置1に送信してもよい(ステップS216)。この処理は図48で示したステップS194〜S195の処理と同じである。
情報出力装置2の検査結果が成功した場合、機器操作Webアプリ(Webアプリ#5)の指示に基づき、情報操作装置1は、Websocketクライアント処理部18を使って情報出力装置2とWebsocketのコネクション(Websocketコネクション#2)を確立し、情報出力装置2に機器操作命令を送信する(ステップ220)。
なお、ここではPINと利用許可証を送信するWebsocketコネクション#1をWebsocketクライアント処理部18aを使って確立し、機器操作命令を送信するWebsocketコネクション#2をWebsocketクライアント処理部18を使って確立する例について示したが、この他に以下のバリエーションが可能である。
(1)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部18aを使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図を図49Bに示す。図49Aとの違いは、PFアプリ実行部21内に機器命令送信部19aを備える点と、PFアプリ実行部21から機器操作命令を送信するために、PFアプリ実行部21がWebアプリ実行部22からPINと利用許可証に加えて機器操作命令を取得する点と、PFアプリ実行部21内の機器命令送信部19aがWebsocketクライアント処理部18aを使って機器命令を情報出力装置2に送信する点である。
(2)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部18を使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図を図49Cに示す。図49Aとの違いは、PFアプリ実行部21内にWebsocketクライアント処理部18aと利用許可証送信部25aを備えず、Webアプリ実行部22内に利用許可証送信部25を備え、Websocketクライアント処理部18を使って利用許可証を情報出力装置2に送信する点である。
上述の例ではPINと利用許可証を送信するWebsocketコネクションと機器操作命令を送信するWebsocketコネクションを別々のWebsocketコネクションとする例について説明したが、以下のように同一のWebsocketコネクションで送信してもよい。この場合の情報操作装置1と情報出力装置2の処理手順を示すシーケンス図を図53Bに示す。
(3)PINと利用許可証と、機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部18aを使って確立する。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成は図49Bと同一で良い。
(4)PINと利用許可証と、機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部18を使って確立する。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成は図49Cと同一で良い。
また、図53BではPINと利用許可証を送信するコネクションと機器操作命令を送信するコネクションをWebsocketコネクションで送信していたが、HTTPコネクション(またはHTTPSコネクション)で送信してもよい。この場合の情報操作装置1と情報出力装置2の処理手順を示すシーケンス図を図53Cに示す。
(5) PINと利用許可証と、機器操作命令を送信するコネクションはHTTP処理部11を使って確立する。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成を図49Dに示す。図49Cとの違いはWebsocketクライアント処理部18の代わりにHTTP処理部11でPINと利用許可証と、機器操作命令を送信するようにしている点である。
なお、図49CではWebsocketクライアント処理部18内のドメイン付与部70はWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行っていたが、図49Dに示す情報操作装置1ではHTTP処理部11がWebアプリ実行部22で実行中のWebアプリのドメイン名をHTTPヘッダ(特許請求の範囲のコネクションのヘッダに対応)に付与する処理を行う。またこの情報操作装置1に対応する情報出力装置2の内部構成を図51Bに示す。図51Aとの違いは、Websocketサーバ処理部の代わりにHTTPサーバ処理部を備えている点である。PINと利用許可証と機器操作命令はHTTPサーバ処理部51によって受信される。さらに、HTTPヘッダに付与されているドメイン名はアプリ出所検査部43に送られ、アプリ出所検査部43によって利用許可証に含まれるドメインとの一致検査処理が行われる。
なお、図53Aの処理フローではPINの値が情報操作装置1と情報出力装置2との間で平文にてやりとりされていた。以下にPINを平文で送信せずにMAC値を送信して情報出力装置2がMAC値を検証することでPINが正しいかどうかを確かめる方法を示す。
図54Aは情報操作装置1の別の構成を示すブロック図である。PFアプリ実行部21で実行されるPFアプリ内にMAC計算部(暗号情報生成部)67を新たに備えている。
MAC計算部67は、PFアプリ実行部21内のWebsocketクライアント処理部18で情報出力装置2に対して利用許可証を送信した応答として受信したチャレンジ(乱数)を、以下の計算式によってMAC値を計算する処理部である。
MAC値 = HMAC-SHA1(MAC鍵、PIN||チャレンジ)
すなわち、暗号アルゴリズムHMAC-SHA1を利用し、MAC鍵にて、PINとチャレンジの結合値の鍵付きハッシュ値を計算している。ここで、MAC鍵はMAC計算部67にあらかじめ蓄積される秘密鍵であり、これと同じ値が情報出力装置2にも蓄積されている。PINはPIN保存部60に蓄積されているPINの値である。MAC値を計算する際、Webアプリ実行部22のWebアプリがPFアプリ実行部21のPFアプリのMAC計算部67にPINの値を通知する。
MAC計算部67は、このMAC値を計算して、Webアプリ実行部22で実行しているWebアプリにMAC値を送信する。Webアプリは機器操作命令を機器操作命令送信部19に送信するのに先立ち、このMAC値を機器操作命令送信部19に送信する。
図55Aは図54Aの情報操作装置1に対応する情報出力装置2の構成を示すブロック図である。図51Aに示す情報出力装置2とは、チャレンジ生成部68を新たに備えている点と、PIN検査部59の代わりにMAC検査部69を備えている点が異なる。
チャレンジ生成部68は、情報操作装置1から利用許可証を受信し、その利用許可証の検証が成功した場合に、チャレンジ(乱数)を生成して、情報操作装置1に送信する処理部である。なお、このチャレンジ乱数は情報操作装置1がMAC値を受信するか、Websocketコネクションが切断するまでは一時的に保存しておく。
MAC検査部69は、情報操作装置1からMAC値が送信された場合、以下の計算式によってMAC値を計算する処理部である。
MAC値 = HMAC-SHA1(MAC鍵、PIN||チャレンジ)
ここで、MAC鍵は情報出力装置2のMAC検査部69にあらかじめ記憶されている値である。チャレンジは、チャレンジ生成部68によって生成されて情報操作装置1に送信した値である。PINはPIN管理部39に記憶されている値を用いる。暗号アルゴリズムとしてHMAC-SHA1を利用する。MAC検査部69は、この計算によって求めたMAC値と、情報操作装置1から送信されてきたMAC値が一致するか否かを判定し、判定結果を機器操作命令処理部34に通知する。機器操作命令処理部34は、MAC検査部69が成功した場合に限り、以降情報操作装置1から送信されてくる機器操作命令を受け付ける。
図56AはPINを平文で送信する代わりにMAC値を利用する場合の情報操作装置1と情報出力装置2の処理手順を示すシーケンス図である。
まず、Webアプリ#5がPINと保存しておいた利用許可証を取得し、入力受信部15から命令を受信する処理(ステップS231)までは図53Aと同様の手順でよい。
つぎにWebアプリ#5はPFアプリ実行部21が実行するPFアプリ9に利用許可証を送信するように依頼する(ステップS232)。PFアプリ9はWebsocketコネクション#1にて利用許可証を情報出力装置2に送信する(ステップS233)。具体的には、PFアプリ9の指示に基づき、情報操作装置1のWebsocketクライアント処理部18aはWebsocketのコネクション(Websocketコネクション#1)を確立し、情報出力装置2に利用許可証を送信する。
情報出力装置2は、利用許可証の署名が正しいかどうか署名検証処理を実行する(ステップS234)。もし署名検証に失敗すれば、以降の処理は行わず、機器操作命令を受け付けないか、あるいはWebsoketコネクションを切断してもよい。署名検証に成功すると、情報出力装置2はチャレンジ生成部68を用いてチャレンジ(乱数)を生成し、Websocketコネクション#1にてチャレンジを情報操作装置1に送信する(ステップS235)。
情報操作装置1は、Websocketクライアント処理部18aにてチャレンジを受信すると、PFアプリ実行部21のMAC計算部67は受信したチャレンジの値と、MAC計算部67に蓄積されているMAC鍵と、PIN保存部60に蓄積されているPINの値を利用してMAC値を計算し(ステップS236)、Webアプリ#5にその結果を通知する。Webアプリ#5は機器命令送信部19を経由してWebsocketコネクション#2にてMAC値を情報出力装置2に送信する(ステップS237)。具体的には、Webアプリ#5の指示に基づき、情報操作装置1のWebsocketクライアント処理部18はWebsocketのコネクション(Websocketコネクション#2)を確立し、情報出力装置2にMAC値を送信する。
情報出力装置2は、MAC検査部69は、MAC検査部69に蓄積されているMAC鍵と、PIN管理部に蓄積されているPINの値と、チャレンジ生成部68にて生成したチャレンジの値を利用してMAC値を計算し、情報操作装置1から受信したMAC値と一致するか判定処理を行い、判定結果を情報操作装置1に通知する(ステップS238)。もし一致していない場合、以降情報操作装置1から送信されてくる機器操作命令を受け付けないか、Websocketコネクションを切断する(ステップS239)。
情報操作装置1は情報出力装置2の判定結果が失敗すればエラー処理を行う。判定結果が成功だった場合(検証が成功した場合)、Webアプリ実行部22のWebアプリはWebsocketコネクション#2にて機器操作命令を送信する(ステップS240、S241)。具体的には、Webアプリ#5の指示に基づき、情報操作装置1のWebsocketクライアント処理部18はWebsocketのコネクション(Websocketコネクション#2)にて、情報出力装置2に機器操作命令を送信する。情報出力装置2は、受信した機器操作命令に従って機器を操作する(ステップS242)。
なお、ここでは利用許可証を送信するWebsocketコネクション#1をWebsocketクライアント処理部18aを使って確立し、MAC値と機器操作命令を送信するWebsocketコネクション#2をWebsocketクライアント処理部18を使って確立する例について示したが、この他に以下のバリエーションが可能である。
(1)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部18aを使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図を図54Bに示す。図54Aとの違いは、PFアプリ実行部内に機器命令送信部を備える点と、PFアプリ実行部から機器操作命令を送信するために、PFアプリ実行部がWebアプリ実行部から利用許可証、MAC値、PINに加えて機器操作命令を取得する点と、PFアプリ実行部内の機器命令送信部がWebsocketクライアント処理部18aを使って機器命令を情報出力装置2に送信する点である。
(2)Websocketコネクション#1とWebsocketコネクション#2ともにWebsocketクライアント処理部18を使って確立する。Websocketコネクション#1とWebsocketコネクション#2は異なるWebsocketコネクションである。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成の一例を示すブロック図を図54Cに示す。図54Aとの違いは、PFアプリ実行部内にWebsocketクライアント処理部18aと利用許可証送信部25aを備えず、Webアプリ実行部22内に利用許可証送信部25を備え、Websocketクライアント処理部18を使って利用許可証を情報出力装置2に送信する点である。
上述の例では利用許可証を送信するWebsocketコネクションと、MAC値および機器操作命令を送信するWebsocketコネクションを別々のWebsocketコネクションとする例について説明したが、以下のように同一のWebsocketコネクションに送信してもよい。この場合の情報操作装置1と情報出力装置2の処理手順を示すシーケンス図は図53Bに示される。
(3)利用許可証と、MAC値と機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部18aを使って確立する。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成は図54Bと同一で良い。
(4)利用許可証と、MAC値と機器操作命令を送信するWebsocketコネクションはWebsocketクライアント処理部18を使って確立する。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成は図54Cと同一で良い。
なお、情報操作装置1は機器操作命令を送信するコネクション、すなわちWebsocketコネクション#2を確立してMAC値を送信する際(ステップS237)、Websocketクライアント処理部18内のドメイン付与部70がWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与して情報出力装置2に送信してもよい。さらに、情報出力装置2のアプリ出所検査部(検証部)43は機器操作命令の送受信に使うWebsocketコネクション(Websocketコネクション#2)のWebsocketヘッダに含まれるドメイン名が利用許可証に含まれるWebアプリのドメイン名と一致するかの検査を行い、検査結果を機器操作命令処理部34に通知する。一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。情報出力装置2の機器操作命令処理部は、検査が成功した時のみ以降の処理で情報操作装置1から送信される機器操作命令を受け付けるようにしてもよい。同様に、情報操作装置1は利用許可証を送信するコネクション、すなわちWebsocketコネクション#1を確立してMAC値を送信する際(ステップS233)、Websocketクライアント処理部18内のドメイン付与部70がWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与して情報出力装置2に送信してもよい。さらに、情報出力装置2のアプリ出所検査部(検証部)43は機器操作命令の送受信に使うWebsocketコネクション(Websocketコネクション#1)のWebsocketヘッダに含まれるドメイン名が利用許可証に含まれるWebアプリのドメイン名と一致するかの検査を行い、検査結果を機器操作命令処理部34に通知する。一致するか、もしくはWebsocketコネクションのヘッダに含まれるWebアプリのドメイン名が利用許可証に含まれるWebアプリの出所情報(ドメイン名)に含まれる場合には検査成功と判断する。情報出力装置2の機器操作命令処理部は、検査が成功した時のみ以降の処理で情報操作装置1から送信される機器操作命令を受け付けるようにしてもよい。
図56Aでは、利用許可証とチャレンジの送受信にはWebsocketコネクション#1を用い、MAC値、その検査結果および機器操作命令の送受信にはWebsocketコネクション#2を用いる例を説明したが、図56Bに示すように、これらすべての送受信を同一のWebsocketコネクション#3で行ってもよい。
また、図56Cに示すように、これらすべての送受信を同一のHTTPコネクションで行ってもよい。この場合の情報操作装置1内のアプリ実行部16、アプリ取得部12、およびアプリキャッシュ部13の内部構成を図54Dに示す。図54Cとの違いはWebsocketクライアント処理部18の代わりにHTTP処理部11で利用許可証とMAC値と、機器操作命令を送信するようにしている点である。なお、図54CではWebsocketクライアント処理部18内のドメイン付与部70はWebアプリ実行部22で実行中のWebアプリのドメイン名をWebsocketヘッダに付与する処理を行っていたが、図54Dに示す情報操作装置ではHTTP処理部11がWebアプリ実行部22で実行中のWebアプリのドメイン名をHTTPヘッダに付与する処理を行う。またこの情報操作装置1に対応する情報出力装置2の内部構成を図55Bに示す。図55Aとの違いは、Websocketサーバ処理部40の代わりにHTTPサーバ処理部51を備えている点である。PINとMAC値と機器操作命令はHTTPサーバ処理部51によって受信される。さらに、HTTPヘッダに付与されているドメイン名はアプリ出所検査部43に送られ、アプリ出所検査部43によって利用許可証に含まれるドメインとの一致検査処理が行われる。
ところで、図52の処理フローでは、PIN入力用Webアプリ(Webアプリ#8)はローカルWebアプリ(Webアプリ#5)から遷移して実行されていたが、PIN入力用Webアプリ(Webアプリ#8)をローカルWebアプリ(Webアプリ#5)のインラインフレーム(iframe)として実行してもよい。その場合の処理手順を図57から図59Aに示す。
まず、ステップS178までは図52と同じである。PIN保存部60にPINが存在しない場合、ローカルWebアプリ(Webアプリ#5)はインラインフレーム(iframe)を作成し(ステップS251)、そのインラインフレームの中でPIN入力用Webアプリ(Webアプリ#8)のURLを指定してWebアプリ#8の取得要求をPIN入力用Webアプリ配布サーバ4aに送信する(ステップS252,S253)。具体的にはWebアプリ#5の指示に従って情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでPIN入力用Webアプリ(Webアプリ#8)の取得要求をWebアプリ配布サーバ4に送信する。情報操作装置1がPIN入力用Webアプリ配布サーバ4aに送信する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アプリ配布サーバ4aに送信されている。
PIN入力用Webアプリ配布サーバ4aの処理は図52と同一である。情報操作装置1はインラインフレームの中で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)に移動する(ステップS259)。具体的にはWebアプリ#8の指示に従って情報操作装置1のWebアプリ取得部27はHTTP処理部31を使ってHTTP(またはHTTPS)のプロトコルでPIN記録Webアプリ(Webアプリ#9)の取得要求をWebアプリ配布サーバ4に送信する。そしてPIN記録Webアプリ(Webアプリ#9)を実行する。
http://example-Webserver.com/appid9#pin
ここで”pin”は入力されたPINの値を示す。ハッシュフラグメントのためPINの値はWebアプリ配布サーバ4には送信されない。PIN記録Webアプリ(Webアプリ#9)は、PINの値をPIN保存部60に保存する。この時、PINの値がWebアプリ#5で取得可能なようにURLの範囲を設定しておく。Webアプリ#5はPINの値をcookieから取得する際、利用許可証と同様に利用許可証アクセス制御部23にてWebアプリ#5で取得可能かどうか判定され、取得可能である場合にはWebアプリ#5はPIN保存部60からPINを取得する事ができる。PINの保存が完了すると、PIN記録Webアプリ(Webアプリ#9)はPINの保存が完了した事を親フレームであるWebアプリ#5に通知する。Webアプリ#5は自らが生成したインラインフレームを終了させる。つまり、PIN記録Webアプリ(Webアプリ#9)は終了する。その後、Webアプリ#5は先ほどPIN記録Webアプリ(Webアプリ#9)が蓄積したPINをPIN保存部60から取得する。この時、利用許可証アクセス制御部23にてPINを取得するWebアプリのドメインが検査されるが、PIN記録Webアプリ(Webアプリ#9)はWebアプリ#5で取得可能なようにURLの範囲を設定しておいたため、Webアプリ#5はPINを取得することができる。Webアプリ#5はPINと保存しておいた利用許可証を取得し(ステップS264)、その後は図56で示した処理フローと同じ手順を実行する。
なお、図58A、図59AではWebsocketコネクションを用いて利用許可証、チャレンジ(乱数)、MAC値、機器操作命令を送受信する場合の例について示したが、HTTPコネクション(またはHTTPSコネクション)で送受信してもよい。この場合の処理フローを図58B、図59Bに示す。コネクションに用いるプロトコルが異なる以外は図58A、図59Aと同一である。
このように、第5の実施形態では、Webアプリごとに許可される機器操作命令を分け、同一ドメイン内の複数のWebアプリが同一の利用許可証を利用するが、情報操作装置1はPIN入力用WebアプリをPIN入力用Webアプリ配布サーバ4aから取得する構成をとる。さらに、情報操作装置1から情報処理装置2にPINを平文で送信するのではなく、情報操作装置1と情報出力装置2が共有する秘密鍵を用いてPINを暗号化したMAC値を計算して、このMAC値を情報操作装置1から情報出力装置2に送信するため、情報操作装置1と情報出力装置2の間に不正な機器が存在していたとしても、その不正な機器にPINが渡るおそれがなく、利用者のPINを保護する事が可能となる。
上述した実施形態で説明した情報操作装置1と情報出力装置2、Webアプリ配布サーバ4、PFアプリ配布サーバ5、利用許可証配布サーバ6の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、装置・サーバの少なくとも一部の機能を実現するプログラムをフロッピーディスクやCD−ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の携帯可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
また、情報操作装置1と情報出力装置2、Webアプリ配布サーバ4、PFアプリ配布サーバ5、利用許可証配布サーバ6の少なくとも一部の機能を実現するプログラムを、インターネット8等の通信回線(無線通信も含む)を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット8等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
ここで、上述した実施形態に係る発明の利用場面について、説明する。
近年、タブレットやスマートフォンと呼ばれる無線LANや3G網を経由してインターネットに接続する機能を有する端末が普及している。それらの端末の多くはWebブラウザを備え、タッチパッドによって文字を入力したり、画面をスクロールしたり、Webページの中に埋め込まれたリンク(ハイパーリンク)を選択したりする操作を容易に行うことができる。また、インターネットからアプリケーションソフトウェア(以下、アプリ)をダウンロードすることにより、端末を自由にカスタマイズしたり、機能を追加・拡張したりすることができる。
その一方で、近年では、放送波を受信するだけでなく、インターネット接続機能とWebブラウザ機能を備えて、インターネットから映像コンテンツを受信できるようにしたデジタルTVが普及しつつある。デジタルTVはデジタル放送など高精細の動画を大画面で再生する機能は優れているものの、デジタルTVを操作するリモートコントローラ(以下、リモコン)はもともと放送番組を選局したり音量を調節したりすることを目的としているため、操作するための赤外線リモコンも一般的にはダイレクトチャンネル選局やアップダウン操作を行うキーしか備えていない。
しかし、Webブラウザ操作などのインターネット機能を利用したり、TVに録画したコンテンツリストの一覧から特定のコンテンツを選択したりするような操作を行うには、複数のリストの中から任意の項目を選択したり、PCのマウスのように画面上の任意の部分をポイント(クリック)したりする必要があり、従来の赤外線リモコンでは機能が不十分である。
一方、スマートフォンやタブレットは、インターネットに接続することを前提としており、無線LANインタフェースが標準搭載されている場合が多い。また、タッチパッドインタフェースを備えているため、任意のポイントを選択(クリック)したり、画面の任意の部分を拡大・縮小させたりすること(ピンチ操作)を容易に行うことができる。そこで、スマートフォンとTVを無線LANインタフェースで接続し、スマートフォンやタブレットのタッチパッドインタフェースをTVのリモコン機能として利用することができれば、ユーザにとって便利である。
しかし、ここで考えなければいけないのはセキュリティである。赤外線リモコンの場合は赤外線という物理特性上、操作可能なTVとリモコン間の距離が制限される。また、一般的に赤外線リモコンは、組立後に機能を追加することはできない。
しかしながら、スマートフォンやタブレットとTVを無線LANインタフェースで接続し、スマートフォンやタブレットにダウンロードしたアプリからTVを操作することを考えた場合、不正なアプリがTVを操作したり、ユーザが意図しない操作を勝手にリモコンアプリがTVに対して行ったりするおそれがあり、そのような場合に、上述した実施形態に係る発明は、ユーザの許諾なしに情報出力装置が勝手に操作されることを防止しつつ、情報操作装置から情報出力装置を操作できるようにして利便性を向上させることができる。
本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。