JP5575071B2 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Description

本発明の実施の形態は、情報処理装置、情報処理方法、およびプログラムに関する。

近年、ＨＴＭＬやＪａｖａ(登録商標）Ｓｃｒｉｐｔなどのウェブ記述言語を用いてリッチなクライアントアプリケーション（ウェブアプリケーション）を記述することが一般的になりつつある。ウェブアプリケーションとは、ネットワークを介してプログラムやデータのやりとりを行うアプリケーションソフトウェアのことである。クライアント単体で実行できるアプリケーションであっても、そのアプリケーションのプログラムやデータの一部または全体をネットワークを介してやりとりすることが可能であれば、そのアプリケーションのことをウェブアプリケーションと呼ぶ。これに伴い、デジタルテレビやスレート端末、スマートフォンといった情報処理装置で実行されるアプリケーションを、ウェブアプリケーションとして記述することも行われている。例えば、デジタルテレビにおけるＩＰＴＶなどでは、ウェブアプリケーションの技術を用いてメニュー画面や動画再生画面を表示する規格が登場している。

ウェブアプリケーションは、ＨＴＭＬやＪａｖａ(登録商標）Ｓｃｒｉｐｔなどを解釈できるブラウザベースの実行環境で実行される。このウェブアプリケーションは、一般に複数のページファイルとメディアファイルから構成される。ここで、メディアファイルとは、ＪＰＥＧ、ＧＩＦ、ＭＰＥＧなどの動画像データが納められたファイルや、ＭＰ３などの音声データが納められたファイルのことをいう。一方、ページファイルとは、文章の構造や画面表示方法や画面遷移に関する指定が記述されたファイルのことである。具体的には、表示文字データなどのページ表示情報、文字の色や大きさなどの装飾情報、画像などの配置を表す配置情報などを含む。さらに、ページファイルには、Ｊａｖａ(登録商標）Ｓｃｒｉｐｔなどで記述された制御プログラムが格納される場合がある。また、Ｊａｖａ(登録商標）Ｓｃｒｉｐｔなどで記述された制御プログラムだけを独立したファイルとして用意することもできる。

ページファイルに含まれる配置情報には、別のページファイルを表示、実行するためのボタン（リンク）が存在する。リンクは、そのページファイルのＵＲＬ情報を含む。ウェブアプリケーションの実行中にユーザ要求などによりそのボタンが選択されると、ブラウザは、そのボタンに対応する新たなページファイルのダウンロード要求を出し、そのページファイルで利用するメディアファイルも含め、必要なファイルがそろった時点で新たなページファイルの表示、実行を開始する。この新たに表示、実行されるページファイルは、先に表示、実行していたページファイルと同一のウェブアプリケーションの場合もあれば、別のウェブアプリケーションの場合もある。

新たなページファイルの表示、実行が行われた場合、人間の目から見れば、ウェブアプリケーションが別のウェブアプリケーションに遷移したか否かを容易に識別できることが多い。しかし、ブラウザの処理としては、同一のウェブアプリケーションのページファイルを実行する方法と、別のウェブアプリケーションのページファイルを実行する方法とに違いはなく、ウェブアプリケーション間の遷移を機械的に検出することは困難である。

一方、ＨＴＭＬやＪａｖａ(登録商標）Ｓｃｒｉｐｔなどの仕様だけでは実現できない機能をソフトウェアとして実装し、ＨＴＭＬやＪａｖａ(登録商標）Ｓｃｒｉｐｔから利用できるようにしたソフトウェア部品のことを拡張機能もしくはプラグインと呼ぶ。ウェブアプリケーションでは、拡張機能を利用することが一般的になっている。例えば、ブラウザは基本機能として、単純な画像表示機能や文字表示機能、文字列操作機能、数値演算機能などを持っている。一方で、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）規格に準じた動画再生機能やローカルファイルへのアクセス機能、デジタルテレビのチャンネル変更機能や音量変更機能などは、ブラウザの基本機能として備えられていない。このようにブラウザの基本機能だけでは、実現できるアプリケーションの幅が限定されるため、デジタルテレビなどにおいては、拡張機能としてこれらブラウザの基本機能では実現できない機能を実装し、ＨＴＭＬやＪａｖａ(登録商標）Ｓｃｒｉｐｔからその機能を呼出すこととなる。このほか、著名な拡張機能の例としては、Ａｄｏｂｅ社のＦＬＡＳＨ Ｐｌａｙｅｒなどが存在する。

拡張機能はいわゆるネイティブコードで記述されることも多く、実現できる機能に自由度が高い。このため、セキュリティ上の観点では、使われるウェブアプリケーションを限定したい場合も多い。具体的には、ローカルファイルアクセス機能を拡張機能として提供すると、ユーザ情報流出やローカルファイルの削除、改ざんなどの危険を伴う。このため、ローカルファイルアクセス機能は、実行環境が限定された特定のウェブアプリケーションのみで利用を許可するようにしたいといったニーズがある。

しかし、上述したように、これまでウェブアプリケーション間の遷移を機械的に検出することが困難であったため、ウェブアプリケーション単位で利用を許可する拡張機能を限定するといったセキュリティポリシの使い分けが困難である。

米国特許出願公開第２００９／０１７７９７２号明細書

ＯＭＴＰ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ Ｐｌａｔｆｏｒｍ）、ＢＯＮＤＩ規格、［online］、［平成２３年８月２５日検索］、インターネット＜ＵＲＬ：http://bondi.omtp.org/＞ Ｗ３Ｃ ＨＴＭＬ５規格、Ｓａｍｅ−ｏｒｉｇｉｎ ｐｏｌｉｃｙ、［online］、［平成２３年８月２５日検索］、インターネット＜ＵＲＬ：http://dev.w3.org/html5/spec/Overview.html＞

本発明が解決しようとする課題は、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができる情報処理装置、情報処理方法、およびプログラムを提供することである。

実施形態の情報処理装置は、ブラウザ部と、アプリ範囲管理部と、終了判定部と、利用可否判定部と、拡張機能呼出し部と、を備える。ブラウザ部は、ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行する。アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する。終了判定部は、前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する。利用可否判定部は、前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する。拡張機能呼出し部は、実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す。

第１の実施形態の情報処理システムのハードウェア構成図。 ディスプレイに表示される画面の一例を示す図。 ディスプレイに表示される画面の一例を示す図。 第１の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 拡張機能管理部が生成、管理する拡張機能の管理テーブルの一例を示す図。 アプリ構成情報のデータ構造の一例を示す図。 アプリ構成情報の一例を示す図。 情報処理装置内部の機能的な構成をより詳細化したブロック図。 第１の実施形態の起動時の処理手順を示すフローチャート。 第１の実施形態のページ遷移時の概略的な処理手順を示すフローチャート。 第１の実施形態のページ遷移時の詳細な処理手順を示すフローチャート。 第１の実施形態の拡張機能呼出し時の処理手順を示すフローチャート。 第２の実施形態の情報処理システムのハードウェア構成図。 コンフィギュレーションファイルのデータ構造の一例を示す図。 第２の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 第２の実施形態のページ遷移時の処理手順を示すフローチャート。 第３の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 セキュリティポリシ管理部の内部構成を示すブロック図。 セキュリティポリシのデータ構造の一例を示す図。 セキュリティポリシファイルの一例を示す図。 アプリ構成情報のデータ構造の一例を示す図。 アプリ構成情報の一例を示す図。 セキュリティポリシファイルとアプリ構成情報との対応関係を示す図。 第３の実施形態の起動時の処理手順を示すフローチャート。 第３の実施形態の拡張機能呼出し時の処理手順を示すフローチャート。 第４の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 署名検証部の内部構成を示すブロック図。 セキュリティポリシのデータ構造の一例を示す図。 アプリ構成情報のデータ構造の一例を示す図。 第４の実施形態の起動時の処理手順を示すフローチャート。 利用証明書リストを保存する処理の詳細を示すフローチャート。 第５の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 第５の実施形態のページ遷移時の処理手順を示すフローチャート。 第５の実施形態の拡張機能呼出し時の処理手順を示すフローチャート。 コンテキスト識別子の取得時の処理手順を示すフローチャート。 第６の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 ウェブアプリケーション起動時の処理手順を示すフローチャート。 第６の実施形態のページ遷移時の処理手順を示すフローチャート。 第７の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 第７の実施形態のページ遷移時の処理手順を示すフローチャート。 第８の実施形態の情報処理装置内部の機能的な構成を示すブロック図。 セキュリティポリシのデータ構造の一例を示す図。 第８の実施形態の拡張機能呼出し時の処理手順を示すフローチャート。 第８の実施形態のページ遷移時の処理手順を示すフローチャート。

以下、実施形態の情報処理装置、情報処理方法、およびプログラムについて、図面を参照して説明する。

（第１の実施形態）
図１は、第１の実施形態の情報処理装置１０を含む情報処理システムのハードウェア構成図である。図１に示す情報処理システムは、情報処理装置１０と、サーバ装置２０と、を備える。サーバ装置２０は、クライアントとなる情報処理装置１０に対してウェブアプリケーションを提供する。情報処理装置１０は、サーバ装置２０からウェブアプリケーションを実行するために必要な各種ファイルを受信して、ウェブアプリケーションを実行する。情報処理装置１０とサーバ装置２０は、例えばインターネットなどのネットワーク３０により接続される。ウェブアプリケーションとは、ネットワークを介してプログラムやデータのやりとりを行うアプリケーションソフトウェアのことである。クライアント単体で実行できるアプリケーションであっても、そのアプリケーションのプログラムやデータの一部または全体をネットワークを介してやりとりすることが可能であれば、そのアプリケーションのことをウェブアプリケーションと呼ぶ。

情報処理装置１０は、主要なハードウェア構成として、ＣＰＵ１１、主記憶メモリ１２、ストレージ１３、ネットワークインタフェース１４、ディスプレイ１５、および入力機器１６を備える。ストレージ１３には、ブラウザプログラムと、拡張機能アクセス制御プログラムと、各種の拡張機能用のプログラム（以下、単に拡張機能という。）と、が格納されている。入力機器１６は、例えば、マウス、キーボード、タッチパネルなどである。

サーバ装置２０は、主要なハードウェア構成として、ストレージ２１およびネットワークインタフェース２２を備える。ストレージ２１には、ウェブアプリケーションの構成部品であるページファイルやメディアファイルが格納されている。ページファイルとは、ページを構成するための情報が記述されたファイルであり、ページを構成するための情報としては、例えば、文章の構造や画面表示方法や画面遷移に関する指定がある。ページファイルやメディアファイルは、ＵＲＬと呼ばれる位置識別子を用いて、その位置（サーバ装置２０の位置とサーバ装置２０内での位置）が特定される。情報処理装置１０とサーバ装置２０は、ネットワークインタフェース１４，２２を用い、ネットワーク３０を介して情報のやりとりを行う。

情報処理装置１０がサーバ装置２０から提供されるウェブアプリケーションを実行する際には、まず下準備として、ウェブアプリケーションの実行環境であるブラウザプログラムの実行を行う。具体的には、ＣＰＵ１１が実行しているＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）などのシェルプログラムが、ユーザの要求等に従い、ブラウザプログラムをストレージ１３から読み出して主記憶メモリ１２に保存する。そして、ＣＰＵ１１が、主記憶メモリ１２に保存されたブラウザプログラムを実行する。その際、ＣＰＵ１１は、ブラウザプログラムとは別プログラムとなっている各種の拡張機能（プラグイン）をストレージ１３から読み出し、主記憶メモリ１２に保存する。

ウェブアプリケーションは、ユーザもしくはプログラム中からウェブアプリケーションに含まれるページファイルのＵＲＬが指定されることにより、その実行が開始される。その際、ＣＰＵ１１は、ネットワークインタフェース１４に対して、指定されたＵＲＬのページファイルの取得命令を出す。ネットワークインタフェース１４は、指定されたＵＲＬにより特定されるサーバ装置２０に接続し、指定されたＵＲＬに該当するページファイルのダウンロード命令を出す。サーバ装置２０のネットワークインタフェース２２は、このダウンロード命令に応じてストレージ２１から該当するページファイルを読み取り、クライアントである情報処理装置１０に返す。情報処理装置１０のネットワークインタフェース１４は、サーバ装置２０から取得したページファイルを主記憶メモリ１２に保存する。ページファイルには、そのページファイルで利用するメディアファイルのＵＲＬが列挙されている。ＣＰＵ１１は、ページファイルの取得時と同様に、ネットワークインタフェース１４に対してこれらメディアファイルの取得命令を出す。そして、ネットワークインタフェース１４がサーバ装置２０に対してこれらメディアファイルのダウンロード命令を出し、このダウンロード命令に応じてサーバ装置２０のストレージ２１から読み取られ、情報処理装置１０に送られたメディアファイルを取得して、主記憶メモリ１２やストレージ１３に保存する。

ウェブアプリケーションの実行に必要なファイルが用意された時点で、ブラウザプログラムは、主記憶メモリ１２に保存されたページファイルをＣＰＵ１１が解釈できる命令に変換する。そして、ＣＰＵ１１が、変換された命令を実行する。実行結果は、ページファイルに含まれる配置情報に従ってディスプレイ１５に出力される。

配置情報には、別のページファイルへ遷移するためのリンクが含まれている。このリンクは、遷移先のページファイルのＵＲＬと関連付けられている。ユーザ操作などによりそのリンクが選択されると、ＣＰＵ１１は、ネットワークインタフェース１４に対して、そのリンクに関連付けられたＵＲＬのページファイルの取得命令を出す。そして、上記と同様に、サーバ装置２０からそのＵＲＬにあるページファイルおよび当該ページファイルで利用するメディアファイルを取得し、必要なファイルがそろった時点で新たなページファイルの表示、実行を開始する。

図２−１は、ＣＰＵ１１がページファイルを実行した場合にディスプレイ１５に表示される画面の一例を示す図である。この図２−１の画面例では、「動画メニュー画面」という文字データ１や「起動したい画面を選んで下さい」という文字データ３、画像データ２に加えて、「動画検索画面」へのリンク４、「本日の動画再生画面」へのリンク５、および「お気に入りリスト画面」へのリンク６が存在する。ユーザ操作などによりこれらのリンク４，５，６のいずれかが選択されると、リンク先のページファイルが実行されて、ディスプレイ１５の表示が例えば図２−２のように変化する。図２−２は、図２−１の画面で「本日の動画再生画面」へのリンク５が選択された場合にディスプレイ１５に表示される画面の一例を示している。

本実施形態の情報処理装置１０は、ストレージ１３に、ブラウザプログラムに加えて、拡張機能アクセス制御プログラムを格納している。図３は、情報処理装置１０のＣＰＵ１１が、ブラウザプログラムおよび拡張機能アクセス制御プログラムを実行することにより実現される情報処理装置１０内部の機能的な構成を示す機能ブロック図である。図３に示すように、情報処理装置１０では、ブラウザプログラムの実行によりブラウザ部２００が実現され、拡張機能アクセス制御プログラムの実行により拡張機能アクセス制御部１００が実現される。

ブラウザ部２００は、アプリケーション実行部２１０と、拡張機能呼出し依頼部２２０と、を備える。

アプリケーション実行部２１０は、ページファイル間の遷移要求に応じて、ページファイルおよびそのページファイルで利用されるメディアファイルを、サーバ装置２０からネットワーク３０を介して受信し、配置情報をもとに文字や画像をディスプレイ１５に表示する機能を持つ。また、アプリケーション実行部２１０は、ページファイルに含まれるＪａｖａ(登録商標）Ｓｃｒｉｐｔなどで記述された制御プログラムを実行する機能を持つ。

拡張機能呼出し依頼部２２０は、ブラウザ部２００の起動時に、ストレージ１３に格納されている拡張機能の初期化を依頼する機能を持つ。また、拡張機能呼出し依頼部２２０は、ページファイルに含まれるプログラムの実行中に拡張機能の呼出しを検知し、拡張機能アクセス制御部１００に対して呼出し先の拡張機能の識別子と呼び出す関数名を通知し、拡張機能の呼出しを依頼する機能を持つ。

拡張機能アクセス制御部１００は、拡張機能の読み込みや呼出しを行う拡張機能管理部１１０と、拡張機能の呼出し時に呼出し可否の判定を行うアクセス制御実行部１２０と、実行中のウェブアプリケーションのアプリ構成情報の管理を行うライフサイクル管理部１３０と、を備える。

本実施形態の情報処理装置１０では、ブラウザ部２００が起動する際に、拡張機能呼出し依頼部２２０が呼び出される。拡張機能呼出し依頼部２２０は、拡張機能アクセス制御部１００に対して拡張機能の初期化を依頼する。拡張機能アクセス制御部１００の拡張機能管理部１１０は、拡張機能の初期化の依頼を検出し、ストレージ１３から拡張機能を主記憶メモリ１２に読み込み、拡張機能が持つ命令（関数）の呼出し先アドレスを格納する。このとき、ストレージ１３から主記憶メモリ１２に読み込む拡張機能は複数であってもよい。例えば、ＤＬＮＡ動画プレーヤ拡張機能と、ローカルファイルアクセス拡張機能とが別個の拡張機能として提供されてストレージ１３に格納されている場合、これらＤＬＮＡ動画プレーヤ拡張機能とローカルファイルアクセス拡張機能とをストレージ１３から主記憶メモリ１２に読み込む。ＤＬＮＡ動画プレーヤ拡張機能には、再生命令、再生停止命令、動画リスト取得命令などが含まれる。ローカルファイルアクセス拡張機能には、ファイル削除命令、ファイルリスト取得命令などが含まれる。

さらに、拡張機能管理部１１０は、各拡張機能を識別するための識別子のリストを主記憶メモリ１２に格納する。この識別子は、後述の拡張機能呼出し部１１２が拡張機能を呼出す際に、呼出す拡張機能を決定するために利用される。この識別子としては、具体的にはＭＩＭＥタイプ、ファイルの拡張子などを用いればよい。例えばＭＩＭＥタイプで拡張機能を識別する場合、ＤＬＮＡ動画プレーヤ拡張機能にはｖｉｄｅｏ／ｄｌｎａ−ｐｌａｙｅｒ、ローカルファイルアクセス拡張機能にはａｐｐｌｉｃａｔｉｏｎ／ｆｉｌｅ−ｍａｎａｇｅｒなどの名前を付ける。この識別子は、独自の拡張機能であれば、拡張機能の開発者が自由に決めることができる。

拡張機能は複数の命令（関数）を持つことができ、個々の関数は、拡張機能の識別子と関数名の指定により、ウェブアプリケーションから呼出される。拡張機能管理部１１０は拡張機能の管理テーブルを持ち、個々の拡張機能で同じ関数名の関数があっても拡張機能の識別子で呼出す関数を区別できる。図４は、拡張機能管理部１１０が生成、管理する拡張機能管理テーブルの一例を示す図である。この図４に示す拡張機能管理テーブルの例では、拡張機能の識別子として、ｖｉｄｅｏ／ｄｌｎａ−ｐｌａｙｅｒとａｐｐｌｉｃａｔｉｏｎ／ｆｉｌｅ−ｍａｎａｇｅｒとが存在し、関数名ｇｅｔｆｉｌｅｌｉｓｔは両方の拡張機能に存在する。拡張機能の呼出し時には、識別子と関数名との組が渡される。例えば、識別子ａｐｐｌｉｃａｔｉｏｎ／ｆｉｌｅ−ｍａｎａｇｅｒと、関数名ｇｅｔｆｉｌｅｌｉｓｔとの組の呼出し依頼が拡張機能呼出し依頼部２２０から拡張機能管理部１１０にあった場合には、拡張機能管理部１１０は、図４に示すような拡張機能管理テーブルを参照し、指定された識別子と関数名に合致するアドレス５６７８９に格納された関数を呼出す。

アプリケーション実行部２１０は、ページファイル間の遷移時に、拡張機能アクセス制御部１１０に対して遷移先ページファイルの位置識別子であるＵＲＬを通知し、アプリ構成情報の更新を依頼する。

アプリ構成情報は、対応するウェブアプリケーションに含まれる１つ以上のページファイルを表すアプリ範囲情報と、当該ウェブアプリケーションで利用が許可された拡張機能を表す情報である利用証明書と、を含む。アプリ範囲情報は、ウェブアプリケーションに含まれる各ページファイルの位置情報である。例えば、ウェブアプリケーションに含まれる各ページファイルの位置情報をリスト、具体的には位置識別子のリスト（以下、ＵＲＬリストという。）にした情報などである。このＵＲＬリストは、ウェブアプリケーションがファイルを利用する場合に使用される。このとき、ブラウザ部１０はファイルをサーバ装置２０から能動的に取得しても、受動的に受け取ってもよい。以下の実施形態では、リストの形式で説明するが、アプリ範囲情報は特にリストに限定されるものではなく、ウェブアプリケーションに含まれる各ページファイルの位置情報が特定できるものであればよい。また、利用証明書も対応するウェブアプリケーションにおいて利用することが許可されたすべての拡張機能に対する利用証明書がリスト形式（以下、利用証明書リストという。）で記述されている。これらＵＲＬリストと利用証明書リストとを含むアプリ構成情報は、例えば、対応するウェブアプリケーションで最初に実行されるページファイルに組み込まれて提供される。

図５−１は、ページファイルに組み込まれたアプリ構成情報のデータ構造の一例を示す図であり、図５−２は、図５−１のデータ構造に従って記述されたアプリ構成情報の一例を示す図である。この図５の例では、「アプリ構成情報開始識別子」である＜ａｐｐｉｎｆｏ＞のタグと「アプリ構成情報終了識別子」である＜／ａｐｐｉｎｆｏ＞のタグとに挟まれた部分の情報が、アプリ構成情報である。また、アプリ構成情報内の「位置識別子情報開始識別子」である＜ｕｒｌ＿ｌｉｓｔ＞のタグと「位置識別子情報終了識別子」である＜／ｕｒｌ＿ｌｉｓｔ＞のタグとに挟まれた部分の情報が、ＵＲＬリストである。また、アプリ構成情報内の「拡張機能利用証明書開始識別子」である＜ｃｅｒｔ＿ｌｉｓｔ＞のタグと「拡張機能利用証明書終了識別子」である＜／ｃｅｒｔ＿ｌｉｓｔ＞のタグとに挟まれた部分の情報が、利用証明書リストである。なお、本実施形態では、ウェブアプリケーションを構成するページファイルの一覧としてＵＲＬリストを用いるが、ウェブアプリケーションの範囲を特定可能な情報であれば、ＵＲＬリスト以外の情報、例えばウェブアプリケーションを構成するページファイルのファイル名一覧などを用いてもよい。

アクセス制御実行部１２０は、拡張機能呼出し依頼部２２０から呼出しが依頼された拡張機能の呼出し可否を判定し、拡張機能へのアクセス制御を実行する機能を有する。アクセス制御実行部１２０は、拡張機能呼出し依頼部２２０から呼出しが依頼された拡張機能が呼出し可能と判断すれば、拡張機能管理部１１０に対して拡張機能の呼出しを依頼する。

ライフサイクル管理部１３０は、アプリ構成情報の更新依頼があった場合に起動され、必要に応じて、現在実行中のウェブアプリケーションに対応するアプリ構成情報の更新を行う機能を有する。このため、ライフサイクル管理部１３０は、遷移先ページにアプリ構成情報が含まれるか判定する機能や、ウェブアプリケーションの開始、終了、実行継続の判定を行う機能を持つ。

本実施形態の情報処理装置１０では、ライフサイクル管理部１３０が、ウェブアプリケーションの実行中にページの遷移があるたびに、遷移先ページの内容によってウェブアプリケーションの開始、終了、継続実行を自動的に判断する。そして、ウェブアプリケーションの実行中に拡張機能の呼出し要求があった場合には、アクセス制御実行部１２０が、ライフサイクル管理部１３０が管理しているアプリ構成情報に含まれる利用証明書リストをもとに、拡張機能のアクセス制御を行う。

図６は、図３に示した情報処理装置１０内部の機能的な構成をより詳細化した機能ブロック図である。以下、図６を用いて情報処理装置１０の詳細な構成を説明する。

拡張機能管理部１１０は、拡張機能ロード部１１１と、拡張機能呼出し部１１２と、を備える。

拡張機能ロード部１１１は、ストレージ１３に格納されている拡張機能を列挙して主記憶メモリ１２へロードする。ストレージ１３に格納されている拡張機能の列挙には、特定の拡張子を持つファイル名による区別や、拡張機能に特定関数が用意されているかどうかによる区別、特定のファイルに予め拡張機能のファイル名を列挙しておくなどの手段を用いればよい。拡張機能のロードに際して、拡張機能ロード部１１１は、各拡張機能の識別子ごとに、拡張機能が持つ関数のアドレスと関数名の対応関係を、図４に示した管理テーブルとして主記憶メモリ１２に保存する。この対応関係の取得には、拡張機能の特定関数を呼び出す方法や、予め別ファイルに対応関係を記述しておく方法などがある。

拡張機能呼出し部１１２は、ブラウザ部２００の拡張機能呼出し依頼部２２０から拡張機能の呼出し依頼があった場合に、呼出す拡張機能の識別子と関数名を受け取り、拡張機能の呼出しを行う。拡張機能呼出し部１１２は、拡張機能ロード部１１１が主記憶メモリ１２に保存した拡張機能の管理テーブルから、受け取った識別子と関数名に対応する関数のアドレスを取得し、そのアドレスに存在する拡張機能の関数を実際に呼出す処理を行う。

アクセス制御実行部１２０は、拡張機能アクセス検出部１２１と、拡張機能呼出し可否判定部１２２と、を備える。

拡張機能アクセス検出部１２１は、拡張機能呼出し依頼部２２０からの呼出し依頼と呼出し情報を受信し、拡張機能呼出し可否判定部１２２を呼出す。呼出し情報には、呼出す拡張機能の識別子と関数名が含まれる。拡張機能アクセス検出部１２１は、この拡張機能の識別子と関数名を渡して拡張機能呼出し可否判定部１２２を呼出し、該当する拡張機能の呼出し可否の判定および拡張機能の呼出しを依頼する。

拡張機能呼出し可否判定部１２２は、拡張機能アクセス検出部１２１からの依頼を受け、呼出す拡張機能の識別子と関数名を受け取り、拡張機能の呼出し可否を判定する。この呼出し可否の判定のために、拡張機能呼出し可否判定部１２２は、ライフサイクル管理部１３０の後述する拡張機能利用証明書保存部１３６から現在実行中のウェブアプリケーションに対応するアプリ管理情報の利用証明書リストを取得する。そして、拡張機能呼出し可否判定部１２２は、呼出す拡張機能についての利用証明書が利用証明書リストに含まれていれば、呼出しが許可されていると判断し、拡張機能呼出し部１１２に対して、呼出す拡張機能の識別子と関数名を渡して呼出しを依頼する。

ライフサイクル管理部１３０は、ページ遷移検出部１３１と、ページ種別振分け部１３２と、アプリ設定ロード部１３３と、アプリ終了判定部１３４と、アプリ範囲管理部１３５と、拡張機能利用証明書保存部１３６と、を備える。

ページ遷移検出部１３１は、ブラウザ部２００で実行中のページが切り替わったことを検出し、ページ種別振分け部１３２に対して、遷移先ページの位置識別子であるＵＲＬを通知する。

ページ種別振分け部１３２は、遷移先ページのページファイルのＭＩＭＥタイプや拡張子、ページファイルの内容に特定タグが付加された情報が存在するかどうかなどにより、そのページファイルにアプリ構成情報が含まれているか否かを判定する。そして、ページ種別振分け部１３２は、ページファイルにアプリ構成情報が含まれているか否かの判定結果に基づき、新たなウェブアプリケーションの開始かどうかを判定する。本実施形態では、ウェブアプリケーションで最初に実行されるページファイルに、アプリ構成情報が含まれている。したがって、ページ種別振分け部１３２は、遷移先ページのページファイルにアプリ構成情報が含まれていれば、新たなウェブアプリケーションの開始であると判定することができる。新たなアプリケーションの開始と判定した場合、ページ種別振分け部１３２は、アプリ設定ロード部１３３を呼出す。

アプリ設定ロード部１３３は、遷移先ページのページファイルに含まれる、新たなウェブアプリケーションに対応したアプリ構成情報をロードする。その際、アプリ設定ロード部１３３は、アプリ範囲管理部１３５に対して、アプリ構成情報のＵＲＬリストを渡し、ＵＲＬリストの保存命令を出す。さらに、アプリ設定ロード部１３３は、拡張機能利用証明書保存部１３６に対して、アプリ構成情報の利用証明書リストを渡し、利用証明書リストの保存命令を出す。

アプリ終了判定部１３４は、ページファイルの遷移時に、現在実行中のウェブアプリケーションが終了したかどうかを判定する。具体的には、アプリ終了判定部１３４は、アプリ範囲管理部１３５から現在実行中のウェブアプリケーションの範囲を表すＵＲＬリストを取得し、遷移先ページの位置識別子であるＵＲＬが、そのＵＲＬリストに含まれるか否かを判定する。そして、アプリ終了判定部１３４は、遷移先ページのＵＲＬがＵＲＬリストに含まれる場合にはウェブアプリケーションの実行継続と判定し、遷移先ページのＵＲＬがＵＲＬリストに含まれない場合には、ウェブアプリケーションの終了と判定する。アプリ終了判定部１３４は、ウェブアプリケーションの終了と判定した場合、アプリ範囲管理部１３５に対して、保存しているＵＲＬリストの消去命令を出すとともに、拡張機能利用証明書保存部１３６に対して、保存している利用証明書リストの消去命令を出す。

アプリ範囲管理部１３５は、ＵＲＬリストの保存命令、取得命令、消去命令を受け取り、その命令に応じて、主記憶メモリ１２に保存してあるＵＲＬリストの更新や取得を行う。

拡張機能利用証明書保存部１３６は、利用証明書リストの保存命令、取得命令、消去命令を受け取り、その命令に応じて、主記憶メモリ１２に保存してある利用証明書リストの更新や取得を行う。

次に、図７を参照して、ブラウザ部２００の起動時の処理手順について説明する。図７は、ブラウザ部２００が起動した際の処理手順を示すフローチャートである。ブラウザ部２００が起動すると、拡張機能のロード処理、より詳しくは拡張機能の識別子を取得する処理と、拡張機能が持つ関数を列挙する処理とが行われる。以下は、その詳細である。

ブラウザ部２００が起動すると、ブラウザ部２００は、まず、拡張機能アクセス制御プログラムをストレージ１３から主記憶メモリ１２にロードする（ステップＳ１０１）。これにより、拡張機能アクセス制御部１００が実現される。続いて、ブラウザ部２００の拡張機能呼出し依頼部２２０が、拡張機能アクセス制御部１００の拡張機能ロード部１１１に対して、拡張機能初期化要求を送信する（ステップＳ１０２）。

拡張機能ロード部１１１は、拡張機能呼出し依頼部２２０からの初期化要求を受け取り、ストレージ１３から拡張機能を１件取り出す処理を行う（ステップＳ１０３）。ここで、拡張機能ロード部１１１は、未処理の拡張機能がストレージ１３内に存在するか否かを判定し（ステップＳ１０４）、未処理の拡張機能が存在した場合には（ステップＳ１０４：Ｙｅｓ）、その拡張機能の識別子を取得する（ステップＳ１０５）。さらに拡張機能ロード部１１１は、取得した識別子で示される拡張機能が持つ関数名と、その関数が格納されたアドレス（関数アドレス）との対応関係を取得する（ステップＳ１０６）。そして、拡張機能ロード部１１１は、ステップＳ１０５で取得した識別子と、ステップＳ１０６で取得した関数名およびその関数アドレスとを対応付けて、主記憶メモリ１２に保存する（ステップＳ１０７）。

その後、拡張機能ロード部１１１は、拡張機能の初期化関数を呼出す（ステップＳ１０８）。この際、初期化関数については予め関数名が決まっているため、関数名と関数アドレスとの対応関係から関数アドレスを決定できる。

その後、拡張機能ロード部１１１は、ステップＳ１０３に戻って、ストレージ１３内に未処理の拡張機能が存在しなくなるまで、ステップＳ１０３〜ステップＳ１０８の処理を繰り返す。その結果、拡張機能ロード部１１１により図４に示したような管理テーブルが構築される。そして、ストレージ１３内のすべての拡張機能に対する処理が終了すると（ステップＳ１０４：Ｎｏ）、拡張機能ロード部１１１は、拡張機能呼出し依頼部２２０に対して、拡張機能の識別子のリストを返す（ステップＳ１０９）。これにより、起動処理が完了し、ブラウザ部２００は、ストレージ１３に存在する拡張機能の一覧を知ることができる。

次に、図８および図９を参照して、ページ遷移時の処理手順について説明する。図８は、ページ遷移時の概略的な処理手順を示すフローチャートであり、図９は、ページ遷移時の詳細な処理手順を示すフローチャートである。ページ遷移時にはウェブアプリケーションの開始、終了、実行継続の判定と、アプリ構成情報の更新処理が行われる。

まず、図８を用いて、ページ遷移時の処理の概略について説明する。ページ遷移が発生すると、まず、遷移先ページの位置識別子であるＵＲＬが取得され（ステップＳ２０１）、遷移先ページのページファイルがアプリ構成情報を含んでいるか否かが判定される（ステップＳ２０２）。そして、遷移先のページのページファイルにアプリ構成情報が含まれていれば（ステップＳ２０２：Ｙｅｓ）、新たなウェブアプリケーションの開始と判断され、それまで実行していたウェブアプリケーションに対応するアプリ構成情報が削除され（ステップＳ２０３）、新たに実行するウェブアプリケーションに対応するアプリ構成情報が保存される（ステップＳ２０４）。このアプリ構成情報には、上述したように、ウェブアプリケーションの範囲（ウェブアプリケーションに含まれるページファイル）を表すＵＲＬリストと、ウェブアプリケーションでどの拡張機能の利用が許可されているかを示す利用証明書リストとが含まれる。

一方、遷移先のページのページファイルにアプリ構成情報が含まれていなければ（ステップＳ２０２：Ｎｏ）、現在実行中のウェブアプリケーションに対応するアプリ構成情報に含まれるＵＲＬリストが取得され（ステップＳ２０５）、遷移先ページのＵＲＬがＵＲＬリストに含まれているか否かが判定される（ステップ２０６）。そして、遷移先のページのＵＲＬがＵＲＬリストに含まれていれば（ステップＳ２０６：Ｙｅｓ）、ウェブアプリケーションの実行継続と判断され、そのまま処理を終了する。一方、遷移先のページのＵＲＬがＵＲＬリストに含まれていなければ（ステップＳ２０６：Ｎｏ）、ウェブアプリケーションの終了と判断され、それまで実行していたウェブアプリケーションに対応するアプリ構成情報が削除される（ステップＳ２０７）。

次に、図９を用いて、ページ遷移時の処理をより詳細に説明する。ページ遷移が発生すると、まずブラウザ部２００のアプリケーション実行部２１０が、拡張機能アクセス制御部１００のライフサイクル管理部１３０内にあるページ遷移検出部１３１に対して、ページ遷移が発生したことを遷移先ページのＵＲＬとともに通知する（ステップＳ３０１）。ページ遷移検出部１３１は、アプリケーション実行部２１０から遷移先ページのＵＲＬを取得すると（ステップＳ３０２）、遷移先ページのＵＲＬを渡してページ種別振分け部１３２を呼出す（ステップＳ３０３）。

ページ種別振分け部１３２は、新たなウェブアプリケーションの開始かどうかを判断するために、遷移先ページのページファイルを取得し、そのページファイルにアプリ構成情報が含まれているか否かを判定する（ステップＳ３０４）。この判定は、例えば、遷移先ページのページファイルの拡張子やＭＩＭＥタイプが、アプリ構成情報を含むページファイルに特有の拡張子やＭＩＭＥタイプであるか否か、あるいはページファイル内に図５−２に示した＜ａｐｐｉｎｆｏ＞や＜／ａｐｐｉｎｆｏ＞といった特別なタグが含まれているか否かを判定基準として実施すればよい。

遷移先ページのページファイルにアプリ構成情報が含まれている場合（ステップＳ３０４：Ｙｅｓ）、ページ種別振分け部１３２は、新たなウェブアプリケーションが開始されたものと判断し、遷移先ページファイルに含まれるアプリ構成情報を渡してアプリ設定ロード部１３３を呼出す（ステップＳ３０５）。

アプリ設定ロード部１３３は、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部１３５に対してＵＲＬリストの削除命令を出すとともに（ステップＳ３０６）、拡張機能利用証明書保存部１３６に対して利用証明書リストの削除命令を出す（ステップＳ３０７）。その後、アプリ設定ロード部１３３は、新たなウェブアプリケーションに対応するアプリ構成情報を保存するために、アプリ範囲管理部１３５に対して、アプリ構成情報に含まれるＵＲＬリストを通知して保存命令を出すとともに（ステップＳ３０８）、拡張機能利用証明書保存部１３６に対して、アプリ構成情報に含まれる利用証明書リストを通知して保存命令を出す（ステップＳ３０９）。アプリ範囲管理部１３５および拡張機能利用証明書保存部１３６は、アプリ設定ロード部１３３からの命令に従ってＵＲＬリストや利用証明書リストの削除、保存を行う。これにより、新たなウェブアプリケーションに対応したアプリ構成情報に含まれるＵＲＬリストおよび利用証明書リストが主記憶メモリ１２に保存される。

一方、遷移先ページのページファイルにアプリ構成情報が含まれていない場合（ステップＳ３０４：Ｎｏ）、ページ種別振分け部１３２は、現在実行中のアプリケーションが継続実行、終了のいずれかであると判断し、そのどちらかであるかを判断するために、遷移先ページのＵＲＬを渡してアプリ終了判定部１３４を呼出す。

アプリ終了判定部１３４は、ページ種別振分け部１３２から遷移先ページのＵＲＬを取得すると、まず、アプリ範囲管理部１３５に対してＵＲＬリストの取得命令を出す。アプリ範囲管理部１３５は、アプリ終了判定部１３４からのＵＲＬリストの取得命令に応じて、主記憶メモリ１２に保存されているＵＲＬリストを取得する処理を行って、取得したＵＲＬリストをアプリ終了判定部１３４に返す（ステップＳ３１０）。このとき、アプリ終了判定部１３４は、アプリ範囲管理部１３５が取得したＵＲＬリストの有無を判定し（ステップＳ３１１）、アプリ範囲管理部１３５が取得したＵＲＬリストがなければ（ステップＳ３１１：Ｎｏ）、そのまま処理を終了する。一方、アプリ範囲管理部１３５が取得したＵＲＬリストがあれば（ステップＳ３１１：Ｙｅｓ）、ページ種別振分け部１３２から取得した遷移先ページのＵＲＬがそのＵＲＬリストに含まれているか否かを判定する（ステップＳ３１２）。

そして、遷移先ページのＵＲＬがＵＲＬリストに含まれている場合（ステップＳ３１２：Ｙｅｓ）、アプリ終了判定部１３４は、同一のウェブアプリケーションの実行が継続されているものと判断し、そのまま処理を終了する。一方、遷移先ページのＵＲＬがＵＲＬリストに含まれていない場合（ステップＳ３１２：Ｎｏ）、アプリ終了判定部１３４は、それまで実行していたウェブアプリケーションが終了したものと判断し、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部１３５に対してＵＲＬリストの削除命令を出すとともに（ステップＳ３１３）、拡張機能利用証明書保存部１３６に対して利用証明書リストの削除命令を出す（ステップＳ３１４）。アプリ範囲管理部１３５および拡張機能利用証明書保存部１３６は、アプリ設定ロード部１３３からの命令に従って、ＵＲＬリストや利用証明書リストの削除を行う。

次に、図１０を参照して、拡張機能呼出し時の処理手順について説明する。図１０は、拡張機能呼出し時の処理手順を示すフローチャートである。拡張機能呼出し時には、主に拡張機能呼出し可否判定部１２２が現在実行中のウェブアプリケーションの利用証明書リストに基づいて、呼出す拡張機能の利用が現在実行中のウェブアプリケーションで許可されているかどうかを判定し、利用が許可されていれば、実際にその拡張機能を呼出す処理を行う。

拡張機能の呼出し要求が発生すると、まず、ブラウザ部２００の拡張機能呼出し依頼部２２０が、呼び出し要求のあった拡張機能の識別子、関数名、関数に渡す引数などを渡して拡張機能アクセス制御部１００のアクセス制御実行部１２０内の拡張機能アクセス検出部１２１を呼出し、拡張機能の呼出しを依頼する（ステップＳ４０１）。拡張機能アクセス検出部１２１は、それを受け取り、拡張機能呼出し可否判定部１２２に対して、呼出し要求のあった拡張機能の識別子、関数名、関数に渡す引数を渡して、拡張機能呼出し可否の判定と呼出しを依頼する（ステップＳ４０２）。

拡張機能呼出し可否判定部１２２は、呼出し要求のあった拡張機能の識別子を取得し（ステップＳ４０３）、実際にその拡張機能が存在するか確認するために、拡張機能ロード部１１１が主記憶メモリ１２に保存した拡張機能の識別子のリストを主記憶メモリ１２から読み出す（ステップＳ４０４）。次に、拡張機能呼出し可否判定部１２２は、そのリストの中に呼出し要求があった拡張機能の識別子があるかどうか判定する（ステップＳ４０５）。そして、呼出し要求のあった拡張機能の識別子がリストの中に存在しなければ（ステップＳ４０５：Ｎｏ）、拡張機能呼出し依頼部２２０に対してエラーを通知する（ステップＳ４０６）。

一方、呼出し要求のあった拡張機能の識別子がリストの中に存在する場合には（ステップＳ４０５：Ｙｅｓ）、拡張機能呼出し可否判定部１２２は、現在実行しているウェブアプリケーションでその拡張機能の利用が許可されているか否かを判断するために、まず拡張機能利用証明書保存部１３６に対して利用証明書リストの取得要求を出し、拡張機能利用証明書保存部１３６から利用証明書リストを取得する（ステップＳ４０７）。そして、拡張機能呼出し可否判定部１２２は、取得した利用証明書リストの中に呼出し要求のあった拡張機能の識別子に対応する利用証明書があるかどうかを判定し（ステップＳ４０８）、対応する利用証明書がない場合には（ステップＳ４０８：Ｎｏ）、現在実行されているウェブアプリケーションでは呼出し要求のあった拡張機能の利用が許可されていないものと判断して、拡張機能呼出し依頼部２２０にエラーを通知する（ステップＳ４０６）。

一方、利用証明書リストの中に対応する利用証明書があった場合には（ステップＳ４０８：Ｙｅｓ）、拡張機能呼出し可否判定部１２２は、呼出し要求のあった拡張機能の利用が許可されているものと判断し、拡張機能呼出し部１１２に対して、拡張機能の識別子、関数名、関数に渡す引数などを渡して、拡張機能の呼び出しを依頼する。拡張機能呼出し部１１２は、実際に拡張機能を呼出すために、拡張機能ロード部１１１が保存した図４のような管理テーブルを参照し、呼出す拡張機能の識別子に対応する関数名から呼出す関数のアドレスを取得する（ステップＳ４０９）。そして、拡張機能呼出し部１１２は、関数に渡す引数を引数として、取得したアドレスの関数（拡張機能）の呼出しを実行する（ステップＳ４１０）。そして、拡張機能呼出し部１１２は、拡張機能呼出し依頼部２２０に対して、関数の呼出し結果、すなわち拡張機能の呼出した関数の戻り値を返す（ステップＳ４１１）。

以上説明したように、本実施形態では、ウェブアプリケーションの範囲を表すＵＲＬリストを含むアプリ構成情報を、ウェブアプリケーションで最初に実行されるページファイルに格納している。そして、情報処理装置１０がウェブアプリケーションを実行する際に、実行中のウェブアプリケーションに対応するアプリ構成情報を保存し、ウェブアプリケーションの実行中にページ遷移が発生した場合に、遷移先ページのページファイルがアプリ構成情報を含んでいるか、さらに、遷移先ページのページファイルがアプリ構成情報を含まない場合には、遷移先のページのＵＲＬがＵＲＬリストに含まれるか否かを判定することで、ウェブアプリケーションの開始、実行継続、実行終了を判定するようにしている。

したがって、本実施形態によれば、従来は困難であったウェブアプリケーション間の遷移を検出できるので、ウェブアプリケーション単位で拡張機能へのアクセス制御を行うことができる。これにより、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができるため、従来はセキュリティ上の理由から公開が困難であった一部の拡張機能について、アクセス許可を限定して公開することができるようになり、ウェブアプリケーションで作成できるアプリケーションの幅を広げることが可能となる。例えば、前述のローカルファイルアクセス拡張機能の一部としてファイル削除などの機能を提供したい場合には、すべてのウェブアプリケーション作成者に機能を公開してしまうとユーザ環境を破壊するようなウィルスも作成されてしまう危険性があるが、本実施形態により、拡張機能の利用者を限定することによりリスクを軽減することができる。

また、本実施形態により拡張機能の利用の幅が広がることで、従来はＣ／Ｃ＋＋などの言語で開発していたプラットホーム特有のアプリケーションを、従来のウェブアプリケーションで記述できない機能のみをＣ／Ｃ＋＋言語などにより拡張機能として開発し、残りのユーザインタフェースの部分などをウェブアプリケーションで開発できるといった利点もある。一般に、Ｃ／Ｃ＋＋のようなネイティブアプリケーションでアプリケーションを開発するコストに比べて、ウェブアプリケーションの開発コストは低いため、ソフトウェア開発コストが削減できる。

このように、本実施形態では、ウェブアプリケーションを構成するページファイルの一覧（ＵＲＬリスト）を用意し、その一覧を元にウェブアプリケーションを識別しその範囲でセキュリティを適用する。

従来のＯＭＴＰ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ Ｐｌａｔｆｏｒｍ）ＢＯＮＤＩ規格（非特許文献１）などのウィジェット規格の中には、ウェブアプリケーションの技術を用いてアプリケーションを構成するものもある。しかし、従来のウィジェット規格の多くは、予めアプリケーションの開発者が複数のページファイルやメディアファイルを圧縮技術により一つのファイル（ウィジェットアーカイブファイル）にまとめておき、それを一つのアプリケーションとみなし、セキュリティ適用を行うものが多い。しかし、ウィジェットアーカイブファイルにまとめてしまうと、ページファイルの一部を修正した場合でも、ウィジェットアーカイブファイルを再度アップデートする必要があるため効率が悪い。また、ウェブアプリケーションにおいては、サーバ装置側で動的にページファイルやメディアファイルを生成するような場合もあり、それらにウィジェットアーカイブファイルによる方式を適用するのは困難である。

これに対して、本実施形態では、ページの一部を更新する場合には修正したいページファイルのみを修正するだけでよく、アプリケーションアップデートの手間が小さいという利点がある。

また、従来の一部の技術（特許文献１、非特許文献１）では、ページファイル単位でセキュリティポリシを記述することも可能である。しかし、特許文献１、非特許文献１では、ページ単位でセキュリティポリシを記述するため、アプリケーションが多くのページファイルから構成される場合、セキュリティポリシが膨大になる。また、アプリケーション全体でセキュリティポリシをアップデートする場合には、個々のページファイルのセキュリティポリシをアップデートする必要があり、セキュリティポリシ管理の手間が大きい。

これに対して、本実施形態では、ウェブアプリケーション単位でセキュリティポリシを記述すればよいため、ウェブアプリケーション全体のセキュリティポリシをアップデートする場合にもコストが小さく、また、セキュリティポリシも膨大になりにくいという利点がある。

また、従来、複数のページ単位で同一のセキュリティポリシを適用する規格としては、ＨＴＭＬ５規格のＳａｍｅ−ｏｒｉｇｉｎ ｐｏｌｉｃｙ（非特許文献２）が存在する。これは、同一ドメインのページファイルではオブジェクトへの相互アクセスを許可するものであり、ドメイン間でのアクセス許可やセキュリティポリシの使い分けはできない。ウェブアプリケーションにおいては、マッシュアップと呼ばれる複数のサービスを連携させて新しいアプリケーションを作る技術が一般的なものとなっているが、Ｓａｍｅ−ｏｒｉｇｉｎ ｐｏｌｉｃｙは、マッシュアップ時のアプリケーション作成の枷となっている。

これに対して、本実施形態では、ウェブアプリケーションを構成するページファイルを記述する際に、個々のページファイルのドメインが一致している必要はない。すなわち、ドメインを跨いでの同一セキュリティポリシの適用が可能となるため、機器機能を利用するマッシュアップも可能になるという利点がある。

（第２の実施形態）
次に、第２の実施形態について説明する。図１１は、第２の実施形態の情報処理装置１０−２を含む情報処理システムのハードウェア構成図である。図１に示した第１の実施形態の構成と比較すると、サーバ装置２０−２のストレージ２１−２に、コンフィギュレーションファイルと呼ばれるファイルが格納されている点が異なっている。以下、第１の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第２の実施形態の特徴部分についてのみ説明する。

第１の実施形態では、ページファイルの内部に、ページ表示情報や配置情報に加えて、アプリ構成情報が含まれていた。これに対して、第２の実施形態では、ページファイルとは別のファイルとして、アプリ構成情報のみが含まれるファイルを用意する。このアプリ構成情報のみが含まれるファイルをコンフィギュレーションファイルと呼ぶ。

図１２は、コンフィギュレーションファイルのデータ構造の一例を示す図である。コンフィギュレーションファイル中には、ウェブアプリケーションの範囲と利用可能な拡張機能を示すアプリ構成情報が含まれている。「アプリ構成情報開始識別子」と「アプリ構成情報終了識別子」とに挟まれた部分の情報が、アプリ構成情報である。アプリ構成情報内の「位置識別子情報開始識別子」と「位置識別子情報終了識別子」とに挟まれた部分の情報がＵＲＬリストであり、アプリ構成情報内の「拡張機能利用証明書開始識別子」と「拡張機能利用証明書終了識別子」とに挟まれた部分の情報が、利用証明書リストである。また、コンフィギュレーションファイル中のアプリ構成情報には、当該コンフィギュレーションファイルのロード後に遷移する先のページファイル（ウェブアプリケーションで最初に実行されるページファイル）の位置識別子（スタートアップＵＲＬ）が記述されている。

図１３は、第２の実施形態の情報処理装置１０−２内部の機能的な構成を示す機能ブロック図である。図６に示した第１の実施形態の構成と比較すると、拡張機能アクセス制御部１００−２のライフサイクル管理部１３０−２内のアプリ設定ロード部１３３−２の機能が、第１の実施形態のアプリ設定ロード部１３３と異なっている。すなわち、第２の実施形態のアプリ設定ロード部１３３−２は、第１の実施形態におけるアプリ設定ロード部１３３の機能に加えて、さらに、コンフィギュレーションファイルへのアクセス時に自動的に遷移するページファイルの情報（スタートアップＵＲＬ）を得る機能と、遷移命令を出す機能とを有する。

図１４は、第２の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図９に示した第１の実施形態の処理手順と比較すると、利用証明書リストを保存する処理（ステップＳ５０９）の後に、コンフィギュレーションファイルからウェブアプリケーションで最初に実行されるページファイルへと自動的に遷移する処理（ステップＳ５１０、ステップＳ５１１）が加わっている点が異なる。図１４のステップＳ５０１からステップＳ５０９までの処理は、図９に示したステップＳ３０１からステップＳ３０９までの処理と同じである。ただし、ステップＳ５０４でＹｅｓと判定されるのは、遷移先ページがコンフィギュレーションファイルの場合となる。

第２の実施形態では、ステップＳ５０９で利用証明書リストを保存した後、アプリ設定ロード部１３３−２が、コンフィギュレーションファイルから実行するページファイルの位置識別子（スタートアップＵＲＬ）を取得し（ステップＳ５１０）、アプリケーション実行部２１０に対してスタートアップＵＲＬと遷移命令を通知して、スタートアップＵＲＬに遷移する（ステップＳ５１１）。その後の処理、すなわち、図１４のステップＳ５１２からステップＳ５１６までの処理は、図９に示したステップＳ３１０からステップＳ３１４までの処理と同じである。

第２の実施形態では、ウェブアプリケーションの範囲と利用可能な拡張機能を示すアプリ構成情報が、ページファイルとは分離された独立のコンフィギュレーションファイルとして提供されるため、ページファイルには手を加える必要がなくなる。すなわち、ページファイルは従来のページファイルを全く変更しなくてもよいため、ウェブアプリケーションの既存資産を最大限活用することができる。また、第２の実施形態では、新たにコンフィギュレーションファイルを生成するだけでよいため、アプリケーション開発コストも従来のアプリケーション開発コストと大きく変わらないという利点がある。

（第３の実施形態）
次に、第３の実施形態について説明する。第１の実施形態では、拡張機能利用証明書保存部１３６が拡張機能ごとの利用証明書のリストである利用証明書リストを管理し、拡張機能呼出し可否判定部１２２が、拡張機能ごとに呼出し可否を判定するようにしていた。これに対して第３の実施形態では、拡張機能に付随するセキュリティポリシを管理し、１つの拡張機能に含まれる複数の機能のうちで利用を許可する機能を限定できるようにしている。

図１５は、第３の実施形態の情報処理装置１０−３内部の機能的な構成を示す機能ブロック図である。図６に示した第１の実施形態の構成と比較すると、拡張機能アクセス制御部１００−３の拡張機能管理部１１０−３内にセキュリティポリシ管理部１１３が付加されている点が異なっている。以下、第１の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第３の実施形態の特徴部分についてのみ説明する。

図１６は、セキュリティポリシ管理部１１３の内部構成を示すブロック図である。セキュリティポリシ管理部１１３は、図１６に示すように、セキュリティポリシロード部１１３ａと、セキュリティポリシ取得部１１３ｂと、を備える。

セキュリティポリシロード部１１３ａは、拡張機能の識別子を受信して、対応する拡張機能のセキュリティポリシを主記憶メモリ１２にロードする。

図１７−１は、第３の実施形態においてセキュリティポリシロード部１１３ａによりロードされるセキュリティポリシのデータ構造の一例を示す図である。図１７−１のデータ構造を持った拡張機能のセキュリティポリシが格納されたファイル（セキュリティポリシファイル）は、拡張機能ごとに用意される。セキュリティポリシファイルは、例えば、拡張機能の識別子と同名のファイル名など、識別子からファイル名が決定できるように命名されていてもよい。また、セキュリティポリシファイルは、特定の拡張子が決められており、セキュリティポリシのデータ構造の中に対応する識別子が記述されるようにしてもよい。セキュリティポリシファイルは、ストレージ１３内に配置されている。セキュリティポリシは、１個以上のセキュリティポリシエレメント部から構成される。セキュリティポリシエレメント部には、セキュリティポリシエレメント識別子とそのセキュリティポリシエレメントを適用した場合に呼出しを許可する関数の関数名が列挙されている。関数名は、ワイルドカードや正規表現などを使って条件を指定してもよい。

図１７−２は、図１７−１のデータ構造に従って記述されたセキュリティポリシファイルの一例を示す図である。例えば、ｄｌｎａ−ｐｌａｙｅｒ−ｐｏｌｉｃｙ１という識別子を持ったセキュリティポリシエレメントを適用する場合には、ｈｏｇｅ、ｆｏｏ、ｂａｒといった名前の関数呼出しが許可される。

セキュリティポリシ取得部１１３ｂは、拡張機能の識別子とセキュリティポリシエレメント識別子を受信して、対応するセキュリティポリシエレメントの内容を返す。

図１８−１は、第３の実施形態におけるアプリ構成情報のデータ構造の一例を示す図であり、図１８−２は、図１８−１のデータ構造に従って記述されたアプリ構成情報の一例を示す図である。この図１８に例示するアプリ構成情報は、図５に示した第１の実施形態におけるアプリ構成情報と比較して、ＵＲＬリストの各利用証明書の中に適用するセキュリティポリシの識別子が含まれている点が異なっている。すなわち、図５の例では、利用証明書リストに、利用が許可された拡張機能の識別子（ＭＩＭＥタイプなど）のみが記述されていたが、図１８の例では、利用が許可された拡張機能の識別子に加えて、適用するセキュリティポリシエレメント識別子も記述されている。このセキュリティポリシエレメント識別子は、図１７に示したセキュリティポリシファイルのセキュリティポリシエレメント識別子と対応する。

図１９は、図１７−２に示したセキュリティポリシファイルと図１８−２に示したアプリ構成情報との対応関係を示す図である。図１８−２に示したアプリ構成情報を持つウェブアプリケーションでは、識別子がｖｉｄｅｏ／ｄｌｎａ−ｐｌａｙｅｒという拡張機能を利用する場合、ｄｌｎａ−ｐｌａｙｅｒ−ｐｏｌｉｃｙ２というセキュリティポリシエレメントが適用され、そのセキュリティポリシの内容は、図１７−２から、ｈｏｇｅ、ｂａｒ２などの関数の呼出しを許可するものであることがわかる。

第３の実施形態では、アクセス制御実行部１２０−３の拡張機能呼出し可否判定部１２２−３が、セキュリティポリシ管理部１１３と拡張機能利用証明書保存部１３６との双方と連携し、ウェブアプリケーション単位でセキュリティポリシの適用を行うようにしている。これにより、同じ拡張機能であっても、ウェブアプリケーションによって適用するセキュリティポリシを切り替えることが可能となる。

図２０は、第３の実施形態においてブラウザ部２００が起動した際の処理手順を示すフローチャートである。図７に示した第１の実施形態の処理手順と比較すると、ストレージ１３内の拡張機能の識別子を取得（ステップＳ６０５）した後に、セキュリティポリシロード部１１３ａがセキュリティポリシをロードする処理（ステップＳ６０６〜ステップＳ６０９）が加わっている点が異なる。図２０のステップＳ６０１からステップＳ６０５までの処理は、図７に示したステップＳ１０１からステップＳ１０５までの処理と同じである。第３の実施形態では、拡張機能ロード部１１１がステップＳ６０５で拡張機能の識別子を取得した後、その識別子をセキュリティポリシロード部１１３ａに渡し、対応するセキュリティポリシのロードを依頼する。

セキュリティポリシロード部１１３ａは、受け取った拡張機能の識別子などから対応するセキュリティポリシのファイル名に変換を行い、セキュリティポリシファイルを取り出す処理を行う（ステップＳ６０６）。例えば、セキュリティポリシのファイル名の命名規則を、識別子．ｃｆｇというように決めておけば、単純に、識別子がｖｉｄｅｏ／ｄｌｎａ−ｐｌａｙｅｒの拡張機能については、ｖｉｄｅｏ／ｄｌｎａ−ｐｌａｙｅｒ．ｃｆｇのように変換することができる。

次に、セキュリティポリシロード部１１３ａは、ステップＳ６０５で取得した識別子に対応するセキュリティポリシファイルをステップＳ６０６で取り出せたかどうか（対応するセキュリティポリシファイルが存在したかどうか）を判定する（ステップＳ６０７）。そして、セキュリティポリシファイルが存在しなかった場合には（ステップＳ６０７：Ｎｏ）、セキュリティポリシロード部１１３ａは、予め定めたデフォルトのセキュリティポリシを取り出す（ステップＳ６０８）。このデフォルトのセキュリティポリシは、例えば、全関数の呼び出し拒否、呼出し許可などといった単純なポリシとしておく。

一方、セキュリティポリシファイルが存在した場合は（ステップＳ６０７：Ｙｅｓ）、ステップＳ６０８の処理は行わずに、ステップＳ６０９に進む。その後、セキュリティポリシロード部１１３ａは、ステップＳ６０６またはステップＳ６０８で取り出したセキュリティポリシを、拡張機能の識別子と対応付けて主記憶メモリ１２に保存し（ステップＳ６０９）、拡張機能ロード部１１１に処理を返す。その後の処理、すなわち、図２０のステップＳ６１０からステップＳ６１３までの処理は、図７に示したステップＳ１０６からステップＳ１０９までの処理と同じである。

図２１は、第３の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図１０に示した第１の実施形態の処理手順と比較すると、呼出し要求のあった拡張機能に対応する利用証明書があると判定された後に（ステップＳ７０８：Ｙｅｓ）、呼出し要求のあった拡張機能に対応するセキュリティポリシエレメントを取得して、拡張機能の利用証明書とセキュリティポリシとの双方から拡張機能の利用可否を判定する処理（ステップＳ７０９〜ステップＳ７１１）が加わっている点が異なる。図２１のステップＳ７０１からステップＳ７０８までの処理は、図１０に示したステップＳ４０１からステップＳ４０８までの処理と同じである。

第３の実施形態では、拡張機能呼出し可否判定部１２２−３が、適用するセキュリティポリシエレメントの内容を得るために、呼出し要求のあった拡張機能に対応する利用証明書があると判定した場合に（ステップＳ７０８：Ｙｅｓ）、アプリ構成情報に記述されている適用するセキュリティポリシエレメントの識別子を取得する（ステップＳ７０９）。その後、拡張機能呼出し可否判定部１２２−３は、取得したセキュリティポリシエレメント識別子と拡張機能の識別子とをセキュリティポリシ取得部１１３ｂに渡し、対応するセキュリティポリシエレメントの取得を依頼する。セキュリティポリシ取得部１１３ｂは、セキュリティポリシロード部１１３ａが主記憶メモリ１２に保存したセキュリティポリシから、該当するセキュリティポリシエレメントを返す（ステップＳ７１０）。

拡張機能呼出し可否判定部１２２−３は、呼び出す関数名が、取得したセキュリティポリシエレメントにあるかどうか、もしくはセキュリティポリシエレメントの関数名が条件で指定されている場合には、その条件に合致するかどうかにより、関数の呼出しが許可されているか否かを判定する（ステップＳ７１１）。そして、関数の呼出しが許可されていないと判定した場合は（ステップＳ７１１：Ｎｏ）、ステップＳ７０６において拡張機能呼出し依頼部２２０にエラーを通知する。一方、関数の呼出しが許可されていると判定した場合は（ステップＳ７１１：Ｙｅｓ）、拡張機能呼出し部１１２に対して、拡張機能の識別子、関数名、関数に渡す引数などを渡して、拡張機能の呼び出しを依頼する。その後の処理、すなわち、図２１のステップＳ７１２からステップＳ７１４までの処理は、図１０に示したステップＳ４０９からステップＳ４１１までの処理と同じである。

以上説明したように、第３の実施形態によれば、アプリ構成情報の利用証明書リストにセキュリティポリシの情報を付加して提供するようにしているので、ウェブアプリケーションに対して利用を許可する拡張機能の内容を、拡張機能に含まれる個々の機能単位で限定することができる。また、アプリ構成情報の利用証明書リストにセキュリティポリシの識別子を記述するとともに、拡張機能のセキュリティポリシを識別子で管理するようにしているので、拡張機能の開発者が利用を許可する拡張機能のポリシを変えたい場合には、ウェブアプリケーション側の利用証明書を更新する必要なく、ポリシを更新するだけで利用を許可する拡張機能のポリシを変更することができる。すなわち、第３の実施形態により、ウェブアプリケーションのリボーク機能を実現することが可能である。

なお、第３の実施形態では、第１の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第２の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。

（第４の実施形態）
次に、第４の実施形態について説明する。上述した第１乃至第３の実施形態では、拡張機能の利用証明書に対する安全性検証を行っていなかった。このため、悪意あるアプリケーション開発者が開発したウェブアプリケーションのページファイルやコンフィギュレーションファイルに拡張機能の不正な利用証明書を添付して、不正に拡張機能を利用される虞があった。第４の実施形態では、拡張機能の作成者など信頼できる者がウェブアプリケーションごとに署名の付いた正当な拡張機能の利用証明書を発行し、アプリケーション開発者は、アプリ構成情報にその正当な拡張機能の利用証明書を含めるようにする。さらに、第４の実施形態では、情報処理装置１０−４が拡張機能の利用証明書についての完全性検証を行うことにより、拡張機能の作成者の意図しない拡張機能の不正利用を防止するようにしている。

図２２は、第４の実施形態の情報処理装置１０−４内部の機能的な構成を示す機能ブロック図である。図１５に示した第３の実施形態の構成と比較すると、拡張機能アクセス制御部１００−４にデータ検証部１５０が付加されている点が異なっている。以下、第１乃至第３の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第４の実施形態の特徴部分についてのみ説明する。

データ検証部１５０は、署名検証部１５１を備える。図２３は、署名検証部１５１の内部構成を示すブロック図である。署名検証部１５１は、図２３に示すように、データ正規化部１５１ａと、アプリケーション固有データ生成部１５１ｂと、ハッシュ計算部１５１ｃと、鍵保存部１５１ｄと、証明書有効性検証部１５１ｅと、証明書解析部１５１ｆと、復号処理部１５１ｇと、を備える。

図２４は、第４の実施形態においてセキュリティポリシロード部１１３ａによりロードされるセキュリティポリシのデータ構造の一例を示す図である。図１７−１に示した第３の実施形態におけるセキュリティポリシのデータ構造と比較して、証明書検証用公開鍵が含まれる点が異なっている。第４の実施形態では、この証明書検証用公開鍵を用いて利用証明書の検証を行う。この証明書検証用公開鍵は、拡張機能ごともしくは拡張機能の制作者ごとに生成される。また、証明書検証用公開鍵に対応する秘密鍵は、拡張機能の制作者のみが持ち、アプリ構成情報に含まれる拡張機能の利用証明書に付加する利用証明書検証用データを作成する際に利用される。

図２５は、第４の実施形態におけるアプリ構成情報のデータ構造の一例を示す図である。図１８−１に示した第３の実施形態におけるアプリ構成情報のデータ構造と比較して、利用証明書検証データが含まれている点が異なっている。この利用証明書検証データは、拡張機能の利用証明書１件につき、１つずつ含まれている。

署名検証部１５１は、アプリ構成情報に含まれる利用証明書を検証する。具体的には、署名検証部１５１は、データ正規化部１５１ａにより、拡張機能の利用証明書の正規化処理を行う。そして、正規化処理後のデータとアプリケーション固有データ生成部１５１ｂが生成したデータを合成した後、ハッシュ計算部１５１ｃにより、そのデータのハッシュ値を計算する。さらに、復号処理部１５１ｇにより、拡張機能の利用証明書に添付されたハッシュ値を鍵保存部１５１ｄが保存した拡張機能の証明書検証用公開鍵で復号し、ハッシュ計算部１５１ｃが計算したハッシュ値と比較することで改ざん検証を行う。さらに、証明書有効性検証部１５１ｅによる利用証明書の有効期間の検証や、リボークリストに基づく有効性の検証などを、必要に応じて行うようにしてもよい。

第４の実施形態では、拡張機能の利用証明書に、拡張機能の秘密鍵で暗号化されたハッシュ値（利用証明書検証データ）と、対象拡張機能の識別子と、セキュリティポリシの管理を行う場合にはセキュリティポリシエレメントの識別子と、が少なくとも含まれる。署名検証部１５１は、証明書解析部１５１ｆが、アプリケーション固有データ生成部１５１ｂと連携して、拡張機能の利用証明書の改ざん検証を行うようにしている。以下、第４の実施形態において特徴的な署名検証部１５１の処理についてさらに詳しく説明する。

証明書解析部１５１ｆは、アプリ構成情報を受け取り、拡張機能の利用証明書を解析する。アプリ構成情報に複数の利用証明書が含まれる場合には利用証明書を分離して、データ正規化部１５１ａ、アプリケーション固有データ生成部１５１ｂ、ハッシュ計算部１５１ｃ、鍵保存部１５１ｄ、証明書有効性検証部１５１ｅ、および復号処理部１５１ｇと連携して、利用証明書が改ざんされていないか、現在実行中のウェブアプリケーション向けに発行された利用証明書であるかどうか判断する。さらに、これらの結果から利用証明書が有効と判断された場合には、その利用証明書を主記憶メモリ１２に保存する。

データ正規化部１５１ａは、利用証明書データを受け取り、この利用証明書データの正規化処理を行う。なお、拡張機能の利用証明書やセキュリティポリシファイルは、例えばＸＭＬなどのデータ記述言語を用いて記述することができる。ＸＭＬなどのデータ記述言語では、データの順序などが異なった場合でも同じ意味をなす場合があり、処理によってはデータを正規化する必要があるために、データ正規化部１５１ａを利用する。拡張機能の利用証明書の正規化が必要ない場合には、データ正規化部１５１ａは不要となる。

アプリケーション固有データ生成部１５１ｂは、ウェブアプリケーションに固有なデータを生成する。このアプリケーション固有データとしては、例えば、アプリ構成情報に含まれるＵＲＬリストのハッシュ値や、署名が付いたウェブアプリケーションのＩＤなどを用いることができる。また、第２の実施形態のようにアプリ構成情報をコンフィギュレーションファイルとして独立のファイルで提供する場合には、コンフィギュレーションファイルのＵＲＬ自体をアプリケーション固有データとして用いるようにしてもよい。ただし、アプリケーション固有データは、偽装や他者がコピー不可能な情報である必要がある。

ハッシュ計算部１５１ｃは、データ正規化部１５１ａにより正規化処理が行われたデータとアプリケーション固有データ生成部１５１ｂが生成したデータとを合成したデータのハッシュ値を計算する。ハッシュ値の計算アルゴリズムとしては、ＳＨＡ１やＭＤ５などの一般的に知られたアルゴリズムを用いればよい。また、ハッシュ値の格納形式などは、Ｘ．５０９、ＸＭＬ Ｓｉｇｎａｔｕｒｅなどの既存の方式を用いればよい。

復号処理部１５１ｇは、利用証明書に格納されたデータから暗号化されたハッシュ値を抜き出し、鍵保存部１５１ｄから取得した鍵データ（証明書検証用公開鍵）でハッシュ値を復号する。暗号・復号アルゴリズムとしては、ＲＳＡなど、よく知られた公開鍵暗号の仕組みを使えばよい。

鍵保存部１５１ｄは、各拡張機能に対応する証明書検証用公開鍵を命令に応じて保存または取得する。

証明書有効性検証部１５１ｅは、利用証明書が有効かどうか判定する。判定の方法としては、例えば、利用証明書に有効期限のデータが格納されている場合には、現在の日時との比較を行い有効期限の範囲内かどうかを判定するといった方法が考えられる。また、利用証明書のリボークリストを別途用意して利用証明書が有効であるかどうかを判定するといった方法も考えられる。なお、条件に合致しない利用証明書を失効させる必要がない場合には、この証明書有効性検証部１５１ｅは不要である。

図２６は、第４の実施形態においてブラウザ部２００が起動した際の処理手順を示すフローチャートである。図２０に示した第３の実施形態の処理手順と比較すると、セキュリティポリシロード部１１３ａがステップＳ８０５で取得した識別子に対応するセキュリティポリシファイルが存在する場合に（ステップＳ８０７：Ｙｅｓ）、署名検証部１５１の鍵保存部１５１ｄが、ステップＳ８０５で取得した識別子で示される拡張機能に対応する証明書検証用公開鍵を保存する処理（ステップＳ８０９）が加わっている点が異なる。図２６のステップＳ８０１からステップＳ８０７までの処理は、図２０に示したステップＳ６０１からステップＳ６０８までの処理と同じである。

第４の実施形態では、セキュリティポリシロード部１１３ａが、ステップＳ８０５で取得した識別子に対応するセキュリティポリシファイルが存在すると判定した場合に（ステップＳ８０７：Ｙｅｓ）、拡張機能ごとの証明書検証用公開鍵を保存するために、鍵保存部１５１ｄを呼出して拡張機能の識別子とセキュリティポリシデータを渡す。そして、鍵保存部１５１ｄは、セキュリティポリシに含まれる鍵データ（証明書検証用公開鍵）を、拡張機能の識別子と対応付けて主記憶メモリ１２に保存する（ステップＳ８０９）。これにより、拡張機能ごとの鍵データが主記憶メモリ１２に保存され、拡張機能の識別子から対応する鍵データを取得できるようになる。その後の処理、すなわち、図２６のステップＳ８１０からステップＳ８１４までの処理は、図２０に示したステップＳ６０９からステップＳ６１３までの処理と同じである。

図２７は、第４の実施形態におけるページ遷移時の処理手順のうち、拡張機能の利用証明書リストを保存する処理（図９のステップＳ３０９に相当）を抜き出したものである。第４の実施形態におけるページ遷移時の処理のうち、拡張機能の利用証明書リストを保存する処理以外の処理は、図９に示した第１の実施形態の処理手順と同様である。

利用証明書リストの保存処理が開始されると、まず、署名検証部１５１の証明書解析部１５１ｆが、アプリケーション固有データ生成部１５１ｂに対してアプリケーション固有データの生成を依頼する。アプリケーション固有データ生成部１５１ｂは、アプリケーション固有データを取り出して、証明書解析部１５１ｆに返す（ステップＳ９０１）。このアプリケーション固有データとしては、例えば、アプリ構成情報に含まれるＵＲＬリストのハッシュ値や、偽装や他者がコピー不可能な署名が付いたウェブアプリケーションのアプリケーションＩＤなどを用いることができる。また、アプリ構成情報をページファイルとは別のコンフィギュレーションファイルとして提供する場合には、そのコンフィギュレーションファイルのＵＲＬなどをアプリケーション固有データとして用いることができる。このアプリケーション固有データは、拡張機能の利用証明書がどのウェブアプリケーションに対して発行されたか、不正に別アプリケーションの拡張機能の利用証明書を利用していないか確認するためのデータである。

次に、証明書解析部１５１ｆは、各拡張機能の利用証明書を検証するために、アプリ構成情報に含まれる利用証明書リストから利用証明書を１件取り出す処理を行い、利用証明書が取り出せたか否かを判定する（ステップＳ９０２）。ここで、利用証明書を取り出せなかった場合には（ステップＳ９０２：Ｎｏ）、そのまま処理を終了する。一方、利用証明書を取り出せた場合には（ステップＳ９０２：Ｙｅｓ）、利用証明書のデータからその証明書に対応する拡張機能の識別子を取得する（ステップＳ９０３）。さらに証明書解析部１５１ｆは、利用証明書の予め定められた部分（改ざんされては困る部分であり、図２５に示したアプリ構成情報の例では、対応拡張機能識別子や対応セキュリティポリシエレメント識別子のデータ）を取り出し、正規化部１５１ａに渡してデータの正規化を依頼する。正規化部１５１ａは、証明書解析部１５１ｆから渡されたデータに対して正規化処理を行い、その結果を証明書解析部１５１ｆに返す（ステップＳ９０４）。この際の計算には、暗号化されたハッシュ値データ（図２５に示した検証データ）は含まれない。

さらに証明書解析部１５１ｆは、ステップＳ９０１で取り出したアプリケーション固有データとステップＳ９０４で正規化されたデータとの結合を行う（ステップＳ９０５）。この結合は、データが文字列データの場合は、単純に、ステップＳ９０１で取り出したアプリケーション固有データの後に、ステップＳ９０４で正規化されたデータを結合すればよい。この結合によって得られるデータが、改ざん検出用の元データとなる。

さらに証明書解析部１５１ｆは、検証データを生成するためにステップＳ９０５で結合したデータをハッシュ計算部１５１ｃに渡してハッシュの計算を依頼する。ハッシュ計算部１５１ｃは、何らかのハッシュ計算アルゴリズムを用いて、与えられたハッシュ値を計算して証明書解析部１５１ｆに返す（ステップＳ９０６）。

さらに証明書解析部１５１ｆは、利用証明書に添付された暗号化されたハッシュ値（図２５に示した利用証明書検証データ）を復号するために、鍵保存部１５１ｄに拡張機能の識別子を渡し、鍵保存部１５１ｄが起動時に保存した拡張機能に対応する鍵データ（証明書検証用公開鍵）を取得する（ステップＳ９０７）。そして、証明書解析部１５１ｆは、ステップＳ９０７で取得した鍵データと、利用証明書に添付された暗号化されたハッシュ値（図２５に示した検証データ）とを復号処理部１５１ｇに渡し、復号を依頼する。なお、利用証明書に添付された暗号化されたハッシュ値（図２５に示した検証データ）は、拡張機能の作成者が利用証明書の作成時に上記の証明書検証用公開鍵に対応する暗号鍵で暗号化したハッシュ値である。復号処理部１５１ｇは、この暗号化されたハッシュ値を、証明書検証用公開鍵を用いて復号し、結果を証明書解析部１５１ｆに返す（ステップＳ９０８）。

証明書解析部１５１ｆは、ステップＳ９０６で計算されたハッシュ値と、ステップＳ９０８で復号されたハッシュ値とを比較し、両者が一致するかどうかを判定する（ステップＳ９０９）。そして、両者が一致しない場合（ステップＳ９０９：Ｎｏ）、証明書解析部１５１ｆは、利用証明書が改ざんされた、あるいは不正に別のウェブアプリケーション向けの拡張機能の利用証明書を利用していると判断して、エラーの発生を通知する（ステップＳ９１０）。一方、両者が一致した場合には（ステップＳ９０９：Ｙｅｓ）、証明書解析部１５１ｆは、その拡張機能の利用証明書が正しいと判断する。

すなわち、アプリケーション固有データや、証明書データのうちの一部のデータとして何を用いるか、ハッシュ計算のアルゴリズム、暗号化のアルゴリズムとして何を使うかを予め決めておき、拡張機能の作成者は、アプリケーションの作成者に対して拡張機能の利用証明書を発行する際に、これらの決まりに従って、暗号化されたハッシュ値（図２５の検証データ）のデータを生成する（アプリケーション固有データと証明書データの一部のデータを結合し、結合したデータのハッシュ値を計算し、そのハッシュ値を拡張機能の作成者が持つ暗号鍵で暗号化する）ことで、上記の処理により、拡張機能の利用証明書の不正利用を判定することができる。

さらに、証明書有効性検証部１５１ｅを設けた場合には、証明書有効性検証部１５１ｅに利用証明書データを渡し、利用証明書が有効かどうかの判定を依頼する。証明書有効性検証部１５１ｅは、例えば、利用証明書に有効期限のデータが格納されている場合には、現在の日時との比較を行い有効期限の範囲内かどうかを判定するといった方法や、利用証明書のリボークリストを用意する場合には、そのリストのデータから利用証明書が有効であるか判定することといった方法で、利用証明書データの有効性を検証し、結果を証明書解析部１５１ｆに返す（ステップＳ９１１）。証明書解析部１５１ｆは、検証結果を受け取り、利用証明書が有効でない場合には（ステップＳ９１１：Ｎｏ）、ステップＳ９１０においてエラーの発生を通知する。一方、利用証明書が有効な場合には（ステップＳ９１１：Ｙｅｓ）、主記憶メモリ１２に利用証明書を保存して（ステップＳ９１２）、ステップＳ９０２に戻る。その後、拡張機能の利用証明書がなくなるまでステップ９０２以降の処理を繰り返す。その結果、正当な拡張機能の利用証明書のみが主記憶メモリ１２に保存されることになる。

以上説明したように、第４の実施形態によれば、拡張機能の利用証明書に対する完全性検証を行うようにしているため、拡張機能の不正利用を有効に防止することができる。

なお、第４の実施形態では、第１の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第２の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。

（第５の実施形態）
次に、第５の実施形態について説明する。ウェブアプリケーションにおいては、複数のアプリケーションをタブもしくはウィンドウと呼ばれる実行単位に分けて並列実行することができる。この１つの実行単位のことをコンテキストと呼ぶ。第１乃至第４の実施形態においては、複数のコンテキストを同時に実行する場合、ブラウザ部２００や拡張機能アクセス制御部１００をコンテキストの数だけ用意する必要がある。これは、いわば複数のブラウザを立ち上げた状態になり、主記憶メモリ１２などのリソースの使用効率の悪化を招く。これに対して、第５の実施形態では、実行中のコンテキストを識別する機能を拡張機能アクセス制御部１００−５に付加することで、複数のコンテキストを並列実行する場合にも、リソースの重複を最低限にして効率のよい処理を行えるようにしている。

図２８は、第５の実施形態の情報処理装置１０−５内部の機能的な構成を示す機能ブロック図である。図２２に示した第４の実施形態の構成と比較すると、拡張機能アクセス制御部１００−５のライフサイクル管理部１３０−５内にコンテキスト判定部１３７が付加されている点が異なっている。以下、第１乃至第４の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第５の実施形態の特徴部分についてのみ説明する。

コンテキスト判定部１３７は、ページ遷移時や拡張機能の呼出しなどの各イベント発生時に、そのイベントがどのコンテキストで発生したかを判定する。コンテキスト判定部１３７は、コンテキスト識別子取得命令を受け取り、コンテキストごとに一意の番号や文字列で表現されるコンテキスト識別子を返す。

第５の実施形態におけるアプリ範囲管理部１３５−５は、アプリ構成情報に含まれるＵＲＬリストの保存命令、取得命令、消去命令を受け取り、命令に応じた処理をコンテキストごとに行う。すなわち、アプリ範囲管理部１３５−５は、ＵＲＬリストの保存命令を受け取った場合には、コンテキスト判定部１３７からコンテキスト識別子を取得し、呼出し元から渡されたＵＲＬリストを、コンテキスト識別子に対応付けて主記憶メモリ１２に保存する。また、アプリ範囲管理部１３５−５は、ＵＲＬリストの取得命令を受け取った場合には、主記憶メモリ１２に保存してあるＵＲＬリストのうち、コンテキスト判定部１３７から取得したコンテキスト識別子に対応するＵＲＬリストを返す。また、アプリ範囲管理部１３５−５は、ＵＲＬリストの消去命令を受け取った場合には、主記憶メモリ１２に保存してあるＵＲＬリストのうち、コンテキスト判定部１３７から取得したコンテキスト識別子に対応するＵＲＬリストを消去する処理を行う。

第５の実施形態における拡張機能利用証明書保存部１３６−５は、利用証明書リストの保存命令、取得命令、消去命令を受け取り、命令に応じた処理をコンテキストごとに行う。すなわち、拡張機能利用証明書保存部１３６−５は、利用証明書リストの保存命令を受け取った場合には、コンテキスト判定部１３７からコンテキスト識別子を取得し、呼出し元から渡された利用証明書リストを、コンテキスト識別子に対応付けて主記憶メモリ１２に保存する。また、拡張機能利用証明書保存部１３６−５は、利用証明書リストの取得命令を受け取った場合には、主記憶メモリ１２に保存してある利用証明書リストのうち、コンテキスト判定部１３７から取得したコンテキスト識別子に対応する利用証明書リストを返す。また、拡張機能利用証明書保存部１３６−５は、利用証明書リストの消去命令を受け取った場合には、主記憶メモリ１２に保存してある利用証明書リストのうち、コンテキスト判定部１３７から取得したコンテキスト識別子に対応する利用証明書リストを消去する処理を行う。

以上のように、第５の実施形態の情報処理装置１０−５はコンテキスト判定部１３７を備え、アプリ範囲管理部１３５−５と拡張機能利用証明書保存部１３６−５が、コンテキスト判定部１３７と連携してコンテキストごとにアプリ構成情報のＵＲＬリストや利用証明書リストを管理するようにしている。

図２９は、第５の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図９に示した第１の実施形態の処理手順と比較すると、ステップＳ１００６、ステップＳ１００８、ステップＳ１０１０、ステップＳ１０１２、ステップＳ１０１４、ステップＳ１０１８、およびステップＳ１０２０でコンテキストを取得する処理が加わっている点が異なっている。図２９のステップＳ１００１からステップＳ１００５までの処理は、図９に示したステップＳ３０１からステップＳ３０５までの処理と同じである。

第５の実施形態では、遷移先ページのページファイルにアプリ構成情報が含まれていると判定され（ステップＳ１００４：Ｙｅｓ）、アプリ設定ロード処理が開始されると（ステップＳ１００５）、アプリ設定ロード部１３３が、イベントが発生したコンテキストで今まで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部１３５−５に対してＵＲＬリストの削除命令を出す。アプリ範囲管理部１３５−５は、アプリ設定ロード部１３３からのＵＲＬリストの削除命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１００６）、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれるＵＲＬリストを削除する処理を行う（ステップＳ１００７）。

次に、アプリ設定ロード部１３３は、拡張機能利用証明書保存部１３６−５に対して利用証明書リストの削除命令を出す。拡張機能利用証明書保存部１３６−５は、アプリ設定ロード部１３３からの利用証明書リストの削除命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１００８）、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを削除する処理を行う（ステップＳ１００９）。

また、アプリ設定ロード部１３３は、イベントが発生したコンテキストで新たに実行するウェブアプリケーションに対応するアプリ構成情報を保存するために、アプリ範囲管理部１３５−５に対してＵＲＬリストの保存命令を出す。アプリ範囲管理部１３５−５は、アプリ設定ロード部１３３からのＵＲＬリストの保存命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１０１０）、主記憶メモリ１２のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に、新たなウェブアプリケーションに対応するアプリ構成情報に含まれるＵＲＬリストを保存する処理を行う（ステップＳ１０１１）。

次に、アプリ設定ロード部１３３は、拡張機能利用証明書保存部１３６−５に対して利用証明書リストの保存命令を出す。拡張機能利用証明書保存部１３６−５は、アプリ設定ロード部１３３からの利用証明書リストの保存命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１０１２）、主記憶メモリ１２のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に、新たなウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを保存する処理を行う（ステップＳ１０１３）。これにより、新たなウェブアプリケーションに対応したアプリ構成情報に含まれるＵＲＬリストおよび利用証明書リストが主記憶メモリ１２に保存される。

一方、遷移先ページのページファイルにアプリ構成情報が含まれていない場合（ステップＳ１００４：Ｎｏ）、ページ種別振分け部１３２は、現在実行中のウェブアプリケーションが継続実行、実行終了のいずれかであると判断し、そのどちらかであるかを判断するためにアプリ終了判定部１３４を呼び出して、遷移先ページのＵＲＬを渡す。

アプリ終了判定部１３４は、ページ種別振分け部１３２から遷移先ページのＵＲＬを取得すると、まず、アプリ範囲管理部１３５−５に対してＵＲＬリストの取得命令を出す。アプリ範囲管理部１３５−５は、アプリ終了判定部１３４からのＵＲＬリストの取得命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１０１４）、主記憶メモリ１２のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に保存されているＵＲＬリストを取得する処理を行って、取得したＵＲＬリストをアプリ終了判定部１３４に返す（ステップＳ１０１５）。このとき、アプリ終了判定部１３４は、アプリ範囲管理部１３５−５が取得したＵＲＬリストの有無を判定し（ステップＳ１０１６）、アプリ範囲管理部１３５−５が取得したＵＲＬリストがなければ（ステップＳ１０１６：Ｎｏ）、そのまま処理を終了する。一方、アプリ範囲管理部１３５−５が取得したＵＲＬリストがあれば（ステップＳ１０１６：Ｙｅｓ）、ページ種別振分け部１３２から取得した遷移先ページのＵＲＬがそのＵＲＬリストに含まれているか否かを判定する（ステップＳ１０１７）。

そして、遷移先ページのＵＲＬがＵＲＬリストに含まれている場合（ステップＳ１０１７：Ｙｅｓ）、アプリ終了判定部１３４は、同一のウェブアプリケーションの実行が継続されているものと判断し、そのまま処理を終了する。一方、遷移先ページのＵＲＬがＵＲＬリストに含まれていない場合（ステップＳ１０１７：Ｎｏ）、アプリ終了判定部１３４は、それまで実行していたウェブアプリケーションが終了したものと判断し、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部１３５−５に対してＵＲＬリストの削除命令を出す。アプリ範囲管理部１３５−５は、アプリ終了判定部１３４からのＵＲＬリストの削除命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１０１８）、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれるＵＲＬリストを削除する処理を行う（ステップＳ１０１９）。

次に、アプリ終了判定部１３４は、拡張機能利用証明書保存部１３６−５に対して利用証明書リストの削除命令を出す。拡張機能利用証明書保存部１３６−５は、アプリ設定ロード部１３３からの利用証明書リストの削除命令に応じて、コンテキスト判定部１３７からページ遷移が起きたコンテキストの識別子を取得し（ステップＳ１０２０）、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを削除する処理を行う（ステップＳ１０２１）。

図３０は、第５の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図２１に示した第３の実施形態の処理手順と比較すると、ステップＳ１１０４で取得した拡張機能識別子のリストの中に、呼出し要求のあった拡張機能の識別子があると判定された場合に（ステップＳ１１０５：Ｙｅｓ）、拡張機能の呼出しが起きたコンテキストが持つ拡張機能の利用証明書を元に拡張機能のアクセス制御を行う処理が加わっている点が異なる。図３０のステップＳ１１０１からステップＳ１１０６までの処理は、図２１に示したステップＳ７０１からステップＳ７０６までの処理と同じである。

第５の実施形態では、呼出し要求のあった拡張機能の識別子がリストの中に存在する場合（ステップＳ１１０５：Ｙｅｓ）、拡張機能呼出し可否判定部１２２は、拡張機能利用証明書保存部１３６−５に対して利用証明書リストの取得命令を出す。拡張機能利用証明書保存部１３６−５は、拡張機能呼出し可否判定部１２２からの利用証明書リストの取得命令に応じて、コンテキスト判定部１３７から拡張機能の呼出し要求があったコンテキストの識別子を取得し（ステップＳ１１０７）、主記憶メモリ１２のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域から利用証明書リストを取得して、拡張機能呼出し可否判定部１２２に返す（ステップＳ１１０８）。その後の処理、すなわち、図３０のステップＳ１１０９からステップＳ１１１５までの処理は、図２１に示したステップＳ７０８からステップＳ７１４までの処理と同じである。これにより、コンテキストで実行中のウェブアプリケーションごとに、利用証明書の使い分けが可能になる。

図３１は、コンテキスト判定部１３７によるコンテキスト識別子の取得時の処理手順を示すフローチャートである。

コンテキスト判定部１３７は、コンテキスト識別子の取得要求が来た場合、まず発生したイベントの種別を取得する（ステップＳ１２０１）。このイベントには、ページ遷移と、拡張機能へのアクセスとが存在する。そこで、コンテキスト判定部１３７は、ステップＳ１２０１で取得したイベントの種別から、発生したイベントが拡張機能へのアクセスか否かを判定する（ステップＳ１２０２）。ここで、発生したイベントが拡張機能へのアクセスではない、つまりページ遷移である場合は（ステップＳ１２０２：Ｎｏ）、コンテキスト判定部１３７は、イベントが発生したコンテキストのコンテキスト識別子を取得する（ステップＳ１２０３）。

一方、拡張機能はオブジェクトという形でコンテキストに紐付けされるが、発生したイベントが拡張機能へのアクセスである場合は（ステップＳ１２０２：Ｙｅｓ）、コンテキスト判定部１３７は、拡張機能のオブジェクトが存在するコンテキスト識別子ではなく、拡張機能のアクセス命令を発行したコンテキストの識別子を取得する（ステップＳ１２０４）。もちろんオブジェクトが存在するコンテキスト識別子とアクセス命令を発行したコンテキストの識別子が一致してもよい。最後に、コンテキスト判定部１３７の呼出し元に対して、取得したコンテキスト識別子を返して（ステップＳ１２０５）、処理が終了する。

拡張機能はオブジェクトで管理され、別コンテキストで実行しているウェブアプリケーションから別コンテキストの拡張機能を参照して間接的に拡張機能を呼出すことが可能である。第５の実施形態のコンテキスト判定部１３７は、拡張機能へのアクセス時には、拡張機能のオブジェクトが存在するコンテキストではなく、拡張機能のオブジェクトへのアクセスを行ったコンテキストを判定する。これにより、拡張機能の利用証明書を持つウェブアプリケーションの拡張機能が、拡張機能の利用証明書を持たないウェブアプリケーションのコンテキストから間接的に不正利用されることを有効に防止することが可能となる。

さらに、第５の実施形態において、第４の実施形態で説明したセキュリティポリシ管理部１１３や署名検証部１５１と連携してセキュリティポリシの分離や利用証明書の安全性検証を行う場合には、利用証明書の保存処理において図２７のフローチャートで示した処理を行い、起動時の処理として図２６のフローチャートで示した処理を行うようにすればよい。

以上説明したように、第５の実施形態によれば、拡張機能アクセス制御部１００−５のライフサイクル管理部１３０−５内にコンテキスト判定部１３７を付加するのみで、複数のウェブアプリケーションの並列実行を効率的に行うことが可能になる。主記憶メモリ１２についても、ＵＲＬリストおよび利用証明書リストの格納領域をコンテキスト数に応じて増やすだけで、複数のウェブアプリケーションの並列実行が可能になるため、利用効率がよい。

ウェブアプリケーションでは、並列実行しているコンテキスト間のオブジェクトの相互アクセスも可能である。拡張機能もオブジェクトで管理されるため、別コンテキストで実行しているウェブアプリケーションから間接的に拡張機能を呼出すことが可能である。第５の実施形態におけるコンテキスト判定部１３７は、拡張機能へのアクセス時には、拡張機能のオブジェクトが存在するコンテキストではなく、拡張機能のオブジェクトへアクセスを行ったコンテキストを判定する。これにより、拡張機能の利用証明書を持たないウェブアプリケーションから拡張機能の利用証明書を持つウェブアプリケーションの拡張機能のオブジェクトが不正利用されることを防ぐことが可能となる。また、コンテキスト間のオブジェクトアクセスによる拡張機能の不正アクセスについても防止することが可能である。

なお、第５の実施形態では、第１の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第２の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。

（第６の実施形態）
次に、第６の実施形態について説明する。第１乃至第５の実施形態では、アプリ構成情報を含むページファイルへのアクセスをもってウェブアプリケーション起動と判定していた。これに対して、第６の実施形態では、ウェブアプリケーションの起動に専用命令を用いるようにしている。これにより、ページ遷移時の処理が単純になり、処理負荷の軽減を図ることが可能となる。

図３２は、第６の実施形態の情報処理装置１０−６内部の機能的な構成を示す機能ブロック図である。図２８に示した第５の実施形態の構成と比較すると、拡張機能アクセス制御部１００−６のライフサイクル管理部１３０−６内に、ページ種別振分け部１３２に代えて起動命令検出部１３８が設けられている点が異なっている。以下、第１乃至第５の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第６の実施形態の特徴部分についてのみ説明する。

第６の実施形態のブラウザ部２００−６のアプリケーション実行部２１０−６は、ページ遷移時にページ遷移検出部１３１−６を呼び出す機能に加え、アプリ起動命令の実行時に、起動命令の引数として設定されたウェブアプリケーションの識別情報を渡して起動命令検出部１３８を呼出す機能を有する。このウェブアプリケーションの識別情報としては、例えば、アプリ構成情報が含まれるページファイル（ウェブアプリケーションで最初に実行されるページファイル）のＵＲＬを用いればよい。また、アプリ構成情報をページファイルとは別のコンフィギュレーションファイルとして提供する場合は、コンフィギュレーションファイルのＵＲＬを用いればよい。

起動命令検出部１３８は、アプリケーション実行部２１０−６から渡されたウェブアプリケーションの識別情報を元に、アプリ構成情報を含むページファイルのダウンロードを行い、アプリ構成情報を取得する。さらに、起動命令検出部１３８は、アプリ設定ロード部１３３に対して取得したアプリ構成情報を渡し、アプリ構成情報に含まれるＵＲＬリストや利用証明書リストの読み込み依頼を出す。

第６の実施形態のページ遷移検出部１３１−６は、アプリケーション実行部２１０−６から渡されたページファイルのＵＲＬなどの識別情報をアプリ終了判定部１３４に渡して、ウェブアプリケーションが実行継続か、実行終了かの判定依頼を出す。第１乃至第５の実施形態では、さらにページ種別振分け部１３２が、遷移先ページのページファイルのＵＲＬがアプリ構成情報のＵＲＬリストに含まれるかの判断を行っていたが、第６の実施形態においてはその処理は必要ない。

図３３は、第６の実施形態におけるウェブアプリケーション起動時の処理手順を示すフローチャートである。第６の実施形態では、アプリ起動命令を実行することでウェブアプリケーションが起動する。

まず、アプリケーション実行部２１０−６が、アプリ構成情報を更新するために、起動命令検出部１３８にアプリ起動命令を出す。この際、アプリ起動命令の引数として指定されるページファイルのＵＲＬなどのウェブアプリケーションの識別情報を渡す（ステップＳ１３０１）。

次に、起動命令検出部１３８が、アプリケーション実行部２１０−６から渡されたウェブアプリケーションの識別情報を元に、対応するウェブアプリケーションのアプリ構成情報を含むページファイルをダウンロードする（ステップＳ１３０２）。なお、アプリ構成情報を含むページファイルとは別のコンフィギュレーションファイルとして提供する場合は、起動命令検出部１３８は、このコンフィギュレーションファイルをダウンロードする。

次に、起動命令検出部１３８は、ダウンロードしたページファイルの中からアプリ構成情報を取り出し、アプリ構成情報を保存するために、アプリ設定ロード部１３３に渡す。これにより、アプリ設定ロード処理が開始され（ステップＳ１３０３）、それまで実行していたウェブアプリケーションに対応するＵＲＬリストおよび利用証明書リストの削除（ステップＳ１３０４、ステップＳ１３０５）と、新たに実行されるウェブアプリケーションに対応するＵＲＬリストおよび利用証明書リストの保存（ステップＳ１３０６、ステップＳ１３０７）が行われる。

図３４は、第６の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図９に示した第１の実施形態の処理手順と比較すると、図９のステップＳ３０３からステップＳ３０９に相当する処理は行わず、ステップＳ１４０３の処理が加わっている点が異なっている。図３４のステップＳ１４０１、ステップＳ１４０２の処理は、図９に示したステップＳ３０１、ステップＳ３０２の処理と同じである。

第６の実施形態では、上述したように、ウェブアプリケーションの起動には専用のアプリ起動命令を用いるため、ページ遷移時にウェブアプリケーションの開始かどうかを判定する必要がない。したがって、ページ遷移検出部１３１−６は、遷移先ページのＵＲＬを取得した後、ページ種別振分け部１３２を呼出すのではなく、アプリ終了判定部１３４を直接呼出す（ステップＳ１４０３）。その後の処理、すなわち、図３４のステップＳ１４０４からステップＳ１４０８までの処理は、図９に示したステップＳ３１０からステップＳ３１４までの処理と同じである。

以上説明したように、第６の実施形態によれば、ウェブアプリケーションの起動に専用のアプリ起動命令を用いるようにしているので、ページ遷移時の処理が単純になり、処理負荷が軽減される。したがって、本実施形態は、リソースが限られる環境にも適用することができる。

なお、第６の実施形態では、第１の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第２の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。

（第７の実施形態）
次に、第７の実施形態について説明する。第１乃至第６の実施形態では、ウェブアプリケーションを構成する複数のページファイルやメディアファイルがパッケージングされずに、独立してサーバ装置２０に格納されている場合を想定していた。このようにページファイルやメディアファイルを独立させる構成では、ウェブアプリケーションのアップデートやページファイルを動的に生成する場合などにおいて自由度が高くなる一方で、ウェブアプリケーションのデータを一括して配布し、端末にインストールして利用するような場合に手間がかかる。このため、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部を１つのアーカイブファイルにパッケージングしてサーバ装置２０に格納しておくことも想定される。第７の実施形態は、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が１つのアーカイブファイルにパッケージングされている場合に対応できるようにしたものである。

図３５は、第７の実施形態の情報処理装置１０−７内部の機能的な構成を示す機能ブロック図である。図２８に示した第５の実施形態の構成と比較すると、拡張機能アクセス制御部１００−７のライフサイクル管理部１３０−７内にアプリ展開部１３９およびコンフィグ生成部１４０が付加されている点が異なっている。以下、第１乃至第６の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第７の実施形態の特徴部分についてのみ説明する。

アプリ展開部１３９は、複数のファイルがパッケージングされたアーカイブファイルのデータを受け取り、アーカイブファイルを複数のファイルの状態に展開してストレージ１３もしくは主記憶メモリ１２に格納する。また、アプリ展開部１３９は、展開したアーカイブファイルの中に格納されているページファイル（アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合はコンフィギュレーションファイル）に含まれるアプリ構成情報を読み取り、その内容を渡してコンフィグ生成部１４０を呼出し、コンフィグ生成部１４０に対してアプリ構成情報の動的な生成を依頼する。アーカイブファイルの方式としては、例えばｚｉｐ形式など一般に知られた方式を使えばよい。

コンフィグ生成部１４０は、アプリ展開部１３９が展開したファイルの中から特定ファイル名（例：ｉｎｄｅｘ．ｈｔｍｌ）が付けられたページファイルに含まれるアプリ構成情報を読み取る。また、コンフィグ生成部１４０は、アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合は、アプリ展開部１３９が展開したファイルの中から特定ファイル名（例：ｃｏｎｆｉｇｕｒａｔｉｏｎ．ｄａｔ）が付けられたコンフィギュレーションファイルの内容を読み取る。さらに、コンフィグ生成部１４０は、アーカイブファイルに含まれるページファイルを列挙してＵＲＬリストを動的に生成し、アプリ範囲情報と結合する。

ウェブアプリケーションがアーカイブファイルに含まれるページファイルのみから構成される場合には、アプリ構成情報にＵＲＬリストを含める必要はない。これは、１つのアーカイブファイルにパッケージングされているページファイルは、同一のウェブアプリケーションのファイルであることは明白なためである。一方で、アーカイブファイルに含まれないページファイルが、同じセキュリティポリシを適用するウェブアプリケーションの一部となる場合には、アプリ構成情報には、アーカイブファイルに含まれないページファイルのＵＲＬと、利用証明書リストとが含まれる。このため、コンフィグ生成部１４０は、アーカイブファイルに含まれるページファイルを列挙して動的に生成したＵＲＬリストをアプリ範囲情報と結合することで、アーカイブファイルに含まれないページファイルも含めて、１つのウェブアプリケーションの範囲を表すＵＲＬリストを生成する。

第７の実施形態におけるページ種別振分け部１３２−７は、第１の実施形態におけるページ種別振分け部１３２の機能に加えて、遷移先ページファイルのＭＩＭＥタイプや遷移先ページファイルの拡張子からそのファイルがアーカイブファイルであるかどうか判定する機能を持つ。さらにページ種別振分け部１３２−７は、遷移先ファイルがアーカイブファイルである場合には、アプリ展開部１３９にファイルのデータを渡し、パッケージングされたアーカイブファイルの展開を依頼する。さらにページ種別振分け部１３２−７は、コンフィグ生成部１４０で動的に生成されたＵＲＬリストが結合されたアプリ構成情報をアプリ展開部１３９から受け取り、アプリ設定ロード部１３３に対してアプリ構成情報の保存を依頼する。

第７の実施形態におけるアプリ終了判定部１３４−７は、第１の実施形態におけるアプリ終了判定部１３４の機能に加えて、ウェブアプリケーションの終了時に、アプリ展開部１３９が展開したデータを削除する機能を持つ。

図３６は、第７の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図９に示した第１の実施形態の処理手順と比較すると、ページ種別振分け部１３２−７の呼出し（ステップＳ１５０３）の後に、遷移先ページのファイルがアーカイブファイルか否かを判定する処理（ステップＳ１５０４）と、遷移先ページのファイルがアーカイブファイルの場合に、アーカイブファイルを展開してからウェブアプリケーションを実行するための処理（ステップＳ１５１６〜ステップＳ１５１９）が加わっている点が異なる。図３６のステップＳ１５０１からステップＳ１５０３までの処理は、図９に示したステップＳ３０１からステップＳ３０３までの処理と同じである。

第７の実施形態では、ページ種別振分け部１３２−７が、ページ遷移検出部１３１から遷移先ページのＵＲＬを受け取ると、まず、遷移先ページのファイルのＭＩＭＥタイプや拡張子から、そのファイルがアーカイブファイルであるかどうかを判定する（ステップＳ１５０４）。遷移先ページのファイルがアーカイブファイルでない場合には（ステップＳ１５０４：Ｎｏ）、遷移先ページのページファイルにアプリ構成情報が含まれるか否かの判定（ステップＳ１５０５）に移り、その後のステップＳ１５０６からステップＳ１５１５において、第１の実施形態と同様の処理、すなわち、図９に示したステップＳ３０５からステップＳ３１４までと同じ処理を行う。

一方、遷移先ページのファイルがアーカイブファイルである場合には（ステップＳ１５０４：Ｙｅｓ）、ページ種別振分け部１３２−７は、アーカイブファイル内に格納されたウェブアプリケーションの実行を開始するために、アーカイブファイルのデータをアプリ展開部１３９に渡して、アーカイブファイルの展開を依頼する。そして、アプリ展開部１３９は、ページ種別振分け部１３２−７から受け取ったアーカイブファイルを複数のファイルの状態に展開してストレージ１３もしくは主記憶メモリ１２に格納する（ステップＳ１５１６）。

その後、アプリ展開部１３９は、展開を行ったファイルの中からウェブアプリケーションで最初に実行するページファイル（アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合はコンフィギュレーションファイル）を探し、そのページファイルに含まれるアプリ構成情報を読み込んで、ページ種別振分け部１３２−７に返す（ステップＳ１５１７）。ここでページファイルから読み込まれたアプリ構成情報には、アーカイブファイルに含まれないウェブアプリケーションを構成するページファイルのＵＲＬや利用証明書リストが含まれる。ただし、このアプリ構成情報には、アーカイブファイルにパッケージングされたページファイルのＵＲＬは含まれないため、アーカイブファイルにパッケージングされたページファイルを含めたアプリ範囲情報を生成する必要がある。

そこで、ページ遷移振分け部１３２−７は、コンフィグ生成部１４０にステップＳ１５１７で読み込まれたアプリ構成情報を渡して、アプリ構成情報の生成を依頼する。コンフィグ生成部１４０は、まず、アーカイブファイルに含まれるページファイルを列挙して、アーカイブファイルに含まれる各ページファイルのＵＲＬを取得する（ステップＳ１５１８）。そして、コンフィグ生成部１４０は、ページ種別振分け部１３２−７から渡されたアプリ構成情報と、ステップＳ１５１８で取得した各ページファイルのＵＲＬを結合して、ウェブアプリケーションに対応するアプリ構成情報を生成して、ページ種別振分け部１３２−７に返す（ステップＳ１５１９）。

その後、ページ種別振分け部１３２−７は、コンフィグ生成部１４０が生成したアプリ構成情報をアプリ設定ロード部１３３に渡して、アプリ設定ロード処理を依頼する。そして、アプリ設定ロード部１３３は、ステップＳ１５０６からステップＳ１５１０において、第１の実施形態と同様の処理、すなわち、図９のステップＳ３０５からステップＳ３０９までの処理と同じ処理を行う。

以上説明したように、第７の実施形態によれば、遷移先ページがアーカイブファイルにパッケージングされている場合に、アプリ展開部１３９がアーカイブファイルを展開し、コンフィグ生成部１４０がアーカイブファイルに含まれるページファイルのＵＲＬとアプリ構成情報とを結合して、ウェブアプリケーションに対応するアプリ構成情報を生成する。したがって、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が１つのアーカイブファイルにパッケージングされていたとしても、自動的にウェブアプリケーションの開始処理を行うことができる。また、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部のみをアーカイブファイルとしてパッケージングし、動的に変更する部分はアーカイブしないようにすることもでき、ウェブアプリケーションを構成するページファイルの提供の形態によらず、ウェブアプリケーションにおいて同じセキュリティポリシで拡張機能のアクセス制御を行えるようになるため、ウェブアプリケーションの開発の幅を広げることが可能となる。

なお、第７の実施形態では、第１の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第２の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。

（第８の実施形態）
次に、第８の実施形態について説明する。第１乃至第７の実施形態では、ウェブアプリケーションごとのアプリ構成情報に拡張機能の利用証明書が付属していた。これに対して、第８の実施形態では、アプリ構成情報に拡張機能の利用証明書は付属せず、拡張機能のセキュリティポリシのみからアクセス制御を行う。これにより、ウェブアプリケーションの作成者がウェブアプリケーションを開発する際に利用証明書を添付する手間を減らすことが可能になる。

図３７は、第８の実施形態の情報処理装置１０−８内部の機能的な構成を示す機能ブロック図である。図１５に示した第３の実施形態の構成と比較すると、拡張機能アクセス制御部１００−８のライフサイクル管理部１３０−８内に、拡張機能利用証明書保存部１３６に代えてアプリケーション固有データ生成部１４１が設けられている点が異なっている。以下、第１乃至第７の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第８の実施形態の特徴部分についてのみ説明する。

アプリケーション固有データ生成部１４１は、アクセス制御実行部１２０−８内の拡張機能呼出し可否判定部１２２−８からの依頼に応じて、アプリ構成情報が格納されたページファイルのＵＲＬなど、アプリケーション作成者による偽装が不可能なアプリケーション固有データを生成する。

第８の実施形態における拡張機能管理部１１０−８内のセキュリティポリシ管理部１１３−８は、図３８に示すようなセキュリティポリシの管理を行う。図３８は、第８の実施形態においてセキュリティポリシ管理部１１３−８によりロードされるセキュリティポリシのデータ構造の一例を示す図である。図１７−１に示したセキュリティポリシのデータ構造と比較すると、個々のセキュリティポリシエレメントの適用対象となるウェブアプリケーションのアプリケーション固有データを含む点が異なっている。一つのセキュリティポリシエレメントに複数の対象アプリケーションの固有データを含んでいてもよい。

第８の実施形態におけるセキュリティポリシ管理部１１３−８は、第３の実施形態におけるセキュリティポリシ管理部１１３と同じく、拡張機能の識別子を受信して対応する拡張機能のセキュリティポリシを主記憶メモリ１２にロードする機能を持つ。さらに、第８の実施形態におけるセキュリティポリシ管理部１１３−８は、アプリケーション固有データを受けて、対応するセキュリティポリシエレメントを返す機能を有する。

図３９は、第８の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図２１に示した第３の実施形態の処理手順と比較すると、呼出し要求のあった拡張機能があると判定された後に（ステップＳ１６０５：Ｙｅｓ）、アプリケーション固有データを取得するとともに、セキュリティポリシ管理部１１３−８が管理するセキュリティポリシから対応するセキュリティポリシエレメントを取得する処理（ステップＳ１６０７、ステップＳ１６０８）が加わり、対応する利用証明書があるかどうかを判定する処理がない点が異なる。図３９のステップＳ１６０１からステップＳ１６０６までの処理は、図２１に示したステップＳ７０１からステップＳ７０６までの処理と同じである。

第８の実施形態では、呼出し要求のあった拡張機能があると判定されると（ステップＳ１６０５：Ｙｅｓ）、拡張機能呼出し可否判定部１２２−８が、呼出し要求のあった拡張機能をウェブアプリケーションで利用することが許可されているかどうかを判定するために、アプリケーション固有データ生成部１４１に対して、アプリケーション固有データの取得を依頼する。アプリケーション固有データ生成部１４１は、現在実行中のウェブアプリケーションのアプリケーション固有データ、例えばアプリ構成情報が格納されたページファイルのＵＲＬなどを取得して、拡張機能呼出し可否判定部１２２−８に返す（ステップＳ１６０７）。

次に、拡張機能呼出し可否判定部１２２−８は、セキュリティポリシ管理部１１３−８に対して、アプリケーション固有データ生成部１４１から取得したアプリケーション固有データに対応するセキュリティポリシエレメントの取得を依頼する。セキュリティポリシ管理部１１３−８は、起動時にロードしたセキュリティポリシの中から、アプリケーション固有データ生成部１４１から取得したアプリケーション固有データに対応するセキュリティポリシエレメントを取得して拡張機能呼出し可否判定部１２２−８に返す（ステップＳ１６０８）。

次に、拡張機能呼出し可否判定部１２２−８は、呼び出す関数がセキュリティポリシエレメントに含まれるかどうかにより、呼出し要求があった拡張機能の呼出しが許可されているか否かを判定する（ステップＳ１６０９）。その後の処理、すなわち、図３９のステップＳ１６１０からステップＳ１６１２までの処理は、図２１に示したステップＳ７１２からステップＳ７１３までの処理と同じである。

図４０は、第８の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図９に示した第１の実施形態の処理手順と比較すると、アプリケーション固有データを生成する処理（ステップＳ１７０８）やアプリケーション固有データを削除する処理（ステップＳ１７１３）が加わり、利用証明書リストを削除する処理（ステップＳ３０７、ステップＳ３１４）や利用証明書リストを保存する処理（ステップＳ３０９）がない点が異なる。図４０のステップＳ１７０１からステップＳ１７０７までの処理は、図９に示したステップＳ３０１からステップＳ３０８（ステップＳ３０７は除く）までの処理と同じである。また、図４０のステップＳ１７０９からステップＳ１７１２までの処理は、図９に示したステップＳ３１０からステップＳ３１３までの処理と同じである。

第８の実施形態では、ウェブアプリケーション終了時に、アプリ設定ロード部１３３−８がアプリケーション固有データ生成部１４１を呼出し、それまで実行していたウェブアプリケーションに対応するアプリケーション固有データの削除処理を行う（ステップＳ１７１３）。また、アプリケーションの開始時には、アプリ設定ロード部１３３−８がアプリケーション固有データ生成部１４１を呼出し、アプリケーション固有のデータの生成と保存を依頼する（ステップＳ１７０８）。

以上説明したように、第８の実施形態によれば、アプリ構成情報に拡張機能の利用証明書は付属せず、セキュリティポリシのみから拡張機能のアクセス制御を行うようにしているので、ウェブアプリケーションの作成者はウェブアプリケーションを開発する際に利用証明書を添付する必要はなく、ウェブアプリケーションの作成者の負担を軽減することができる。また、セキュリティポリシデータは拡張機能に付属するため、ウェブアプリケーションの作成者による改ざんなどの心配がない。すなわち、ウェブアプリケーションから拡張機能の不正利用を防ぎたい場合にも、第４の実施形態で説明したような拡張機能の利用証明書の検証処理を行うことなく、拡張機能の不正利用を有効に防止することが可能となる。

以上説明したとおり、第１乃至第８の実施形態によれば、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができる。

第１乃至第８の実施形態の情報処理装置１０〜１０−８において、拡張機能アクセス制御部１００〜１００−８による上述した各機能は、情報処理装置１０〜１０−８のＣＰＵ１１がストレージ１３に格納された拡張機能アクセス制御プログラムを実行することにより実現できる。

情報処理装置１０〜１０−８のＣＰＵ１１が実行する拡張機能アクセス制御プログラムは、例えば、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などのコンピュータで読み取り可能な記録媒体に記録されてコンピュータプログラムプロダクトとして提供される。

また、情報処理装置１０〜１０−８のＣＰＵ１１が実行する拡張機能アクセス制御プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、情報処理装置１０〜１０−８のＣＰＵ１１が実行する拡張機能アクセス制御プログラムを、インターネットなどのネットワーク経由で提供または配布するように構成してもよい。

また、情報処理装置１０〜１０−８のＣＰＵ１１が実行する拡張機能アクセス制御プログラムを、情報処理装置１０〜１０−８のストレージ１３に予め組み込んで提供するように構成してもよい。

情報処理装置１０〜１０−８のＣＰＵ１１が実行する拡張機能アクセス制御プログラムは、拡張機能アクセス制御部１００〜１００−８の各処理部（拡張機能管理部１１０〜１１０−８、アクセス制御実行部１２０〜１２０−８およびライフサイクル管理部１３０〜１３０−８など）を含むモジュール構成となっており、実際のハードウェアとしては、例えば、ＣＰＵ１１（プロセッサ）がストレージ１３から拡張機能アクセス制御プログラムを主記憶メモリ１２に読み出して実行することにより、上記各部が主記憶メモリ１２上にロードされ、上述した各部が主記憶メモリ１２上に生成されるようになっている。

以上、本発明の実施形態を説明したが、ここで説明した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。ここで説明した新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここで説明した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０ 情報処理装置
２０ サーバ装置
１００ 拡張機能アクセス制御部
１１０ 拡張機能管理部
１１１ 拡張機能ロード部
１１２ 拡張機能呼出し部
１１３ セキュリティポリシ管理部
１２０ アクセス制御実行部
１２１ 拡張機能アクセス検出部
１２２ 拡張機能呼出し可否判定部
１３０ ライフサイクル管理部
１３１ ページ遷移検出部
１３２ ページ種別振分け部
１３３ アプリ設定ロード部
１３４ アプリ終了判定部
１３５ アプリ範囲管理部
１３６ 拡張機能利用証明書保存部
１３７ コンテキスト判定部
１３８ 起動命令検出部
１３９ アプリ展開部
１４０ コンフィグ生成部
１４１ アプリケーション固有データ生成部
１５０ データ検証部
１５１ 署名検証部
２００ ブラウザ部

Claims (13)

1. ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、
   ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存するアプリ範囲管理部と、
   前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する終了判定部と、
   前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する利用可否判定部と、
   実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す拡張機能呼出し部と、を備えることを特徴とする情報処理装置。
2. ウェブアプリケーションの実行開始時に、該ウェブアプリケーションで利用が許可された前記拡張機能を表す情報である利用証明書を受信して前記記憶部に保存する利用証明書保存部をさらに備え、
   前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する利用証明書が前記記憶部に保存されているか否かにより、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用することが許可されているか否かを判定することを特徴とする請求項１に記載の情報処理装置。
3. 前記アプリ範囲情報および前記利用証明書は、ウェブアプリケーションにおいて最初に実行されるページファイルに格納されており、
   前記アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションにおいて最初に実行されるページファイルから前記アプリ範囲情報を読み出して前記記憶部に保存し、
   前記利用証明書保存部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションにおいて最初に実行されるページファイルから前記利用証明書を読み出して前記記憶部に保存することを特徴とする請求項２に記載の情報処理装置。
4. 前記アプリ範囲情報および前記利用証明書は、ウェブアプリケーションを構成するページファイルと異なるコンフィギュレーションファイルに格納されており、
   前記アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、前記コンフィギュレーションファイルから前記アプリ範囲情報を読み出して前記記憶部に保存し、
   前記利用証明書保存部は、ウェブアプリケーションの実行開始時に、前記コンフィギュレーションファイルから前記利用証明書を読み出して前記記憶部に保存することを特徴とする請求項２に記載の情報処理装置。
5. 前記拡張機能は複数の関数を含み、
   前記拡張機能ごとに、複数の関数のうち利用を許可する関数の組み合わせであるセキュリティポリシ要素を複数記述したセキュリティポリシ情報を受信して前記記憶部に保存するセキュリティポリシ保存部をさらに備え、
   前記利用証明書は、実行中のウェブアプリケーションに対して適用される前記セキュリティポリシ要素を含み、
   前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する利用証明書が保存されている場合に、呼出しが要求された前記拡張機能のうち、利用証明書に含まれる前記セキュリティポリシ要素で示される関数の利用が許可されていると判定することを特徴とする請求項２に記載の情報処理装置。
6. 実行中のウェブアプリケーションに固有のデータを用いて前記利用証明書の正当性を検証する証明書検証部をさらに備えることを特徴とする請求項２に記載の情報処理装置。
7. 前記拡張機能は複数の関数を含み、
   前記拡張機能ごとに、複数の関数のうち利用を許可する関数の組み合わせであるセキュリティポリシ要素を複数記述するとともに、各セキュリティポリシ要素を適用するウェブアプリケーションを記述したセキュリティポリシ情報を受信して前記記憶部に保存するセキュリティポリシ保存部をさらに備え、
   前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する複数のセキュリティポリシ要素のなかに、実行中のウェブアプリケーションに対して適用されるセキュリティポリシ要素がある場合に、該セキュリティポリシ要素で示される関数の利用が許可されていると判定することを特徴とする請求項１に記載の情報処理装置。
8. 前記ブラウザ部が複数のウェブアプリケーションを並列実行している場合に、前記拡張機能の呼出しがあったウェブアプリケーションを判別する判別部をさらに備え、
   前記利用可否判定部は、呼出しが要求された前記拡張機能が、前記判別部が判別したウェブアプリケーションで利用が許可されているか否かを判定することを特徴とする請求項１または７に記載の情報処理装置。
9. 前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルに前記アプリ範囲情報および前記利用証明書が格納されている場合に、新たなウェブアプリケーションの実行が開始されたと判定する開始判定部をさらに備え、
   前記アプリ範囲管理部は、前記開始判定部により新たなウェブアプリケーションの実行が開始されたと判定された場合に、新たなウェブアプリケーションに対応する前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項３に記載の情報処理装置。
10. 予め定められた所定の命令を検出した場合に、新たなウェブアプリケーションの実行が開始されたと判定する開始判定部をさらに備え、
    前記アプリ範囲管理部は、前記開始判定部により新たなウェブアプリケーションの実行が開始されたと判定された場合に、新たなウェブアプリケーションに対応する前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項１または７に記載の情報処理装置。
11. 前記ブラウザ部が複数のページファイルを含むアーカイブファイルを受信した場合に、該アーカイブファイルを複数のページファイルに展開するファイル展開部と、
    前記ファイル展開部により展開された複数のページファイルと、前記アーカイブファイルに含まれないファイルとを含む前記アプリ範囲情報を生成する生成部と、をさらに備え、
    前記アプリ範囲管理部は、前記生成部が生成した前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項１または７に記載の情報処理装置。
12. ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、記憶部と、を備える情報処理装置において実行される情報処理方法であって、
    ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する工程と、
    前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する工程と、
    前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する工程と、
    実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す工程と、を含むことを特徴とする情報処理方法。
13. ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、記憶部と、を備える情報処理装置に、
    ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する機能と、
    前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する機能と、
    前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する機能と、
    実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す機能と、を実現させるプログラム。

Images