"ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存するアプリ範囲管理部と、前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する終了判定部と、前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する利用可否判定部と、実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す拡張機能呼出し部と、を備えることを特徴とする情報処理装置。ウェブアプリケーションの実行開始時に、該ウェブアプリケーションで利用が許可された前記拡張機能を表す情報である利用証明書を受信して前記記憶部に保存する利用証明書保存部をさらに備え、前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する利用証明書が前記記憶部に保存されているか否かにより、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用することが許可されているか否かを判定することを特徴とする請求項1に記載の情報処理装置。前記アプリ範囲情報および前記利用証明書は、ウェブアプリケーションにおいて最初に実行されるページファイルに格納されており、前記アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションにおいて最初に実行されるページファイルから前記アプリ範囲情報を読み出して前記記憶部に保存し、前記利用証明書保存部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションにおいて最初に実行されるページファイルから前記利用証明書を読み出して前記記憶部に保存することを特徴とする請求項2に記載の情報処理装置。前記アプリ範囲情報および前記利用証明書は、ウェブアプリケーションを構成するページファイルと異なるコンフィギュレーションファイルに格納されており、前記アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、前記コンフィギュレーションファイルから前記アプリ範囲情報を読み出して前記記憶部に保存し、前記利用証明書保存部は、ウェブアプリケーションの実行開始時に、前記コンフィギュレーションファイルから前記利用証明書を読み出して前記記憶部に保存することを特徴とする請求項2に記載の情報処理装置。前記拡張機能は複数の関数を含み、前記拡張機能ごとに、複数の関数のうち利用を許可する関数の組み合わせであるセキュリティポリシ要素を複数記述したセキュリティポリシ情報を受信して前記記憶部に保存するセキュリティポリシ保存部をさらに備え、前記利用証明書は、実行中のウェブアプリケーションに対して適用される前記セキュリティポリシ要素を含み、前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する利用証明書が保存されている場合に、呼出しが要求された前記拡張機能のうち、利用証明書に含まれる前記セキュリティポリシ要素で示される関数の利用が許可されていると判定することを特徴とする請求項2に記載の情報処理装置。実行中のウェブアプリケーションに固有のデータを用いて前記利用証明書の正当性を検証する証明書検証部をさらに備えることを特徴とする請求項2に記載の情報処理装置。前記拡張機能は複数の関数を含み、前記拡張機能ごとに、複数の関数のうち利用を許可する関数の組み合わせであるセキュリティポリシ要素を複数記述するとともに、各セキュリティポリシ要素を適用するウェブアプリケーションを記述したセキュリティポリシ情報を受信して前記記憶部に保存するセキュリティポリシ保存部をさらに備え、前記利用可否判定部は、呼出しが要求された前記拡張機能に対応する複数のセキュリティポリシ要素のなかに、実行中のウェブアプリケーションに対して適用されるセキュリティポリシ要素がある場合に、該セキュリティポリシ要素で示される関数の利用が許可されていると判定することを特徴とする請求項1に記載の情報処理装置。前記ブラウザ部が複数のウェブアプリケーションを並列実行している場合に、前記拡張機能の呼出しがあったウェブアプリケーションを判別する判別部をさらに備え、前記利用可否判定部は、呼出しが要求された前記拡張機能が、前記判別部が判別したウェブアプリケーションで利用が許可されているか否かを判定することを特徴とする請求項1または7に記載の情報処理装置。前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルに前記アプリ範囲情報および前記利用証明書が格納されている場合に、新たなウェブアプリケーションの実行が開始されたと判定する開始判定部をさらに備え、前記アプリ範囲管理部は、前記開始判定部により新たなウェブアプリケーションの実行が開始されたと判定された場合に、新たなウェブアプリケーションに対応する前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項3に記載の情報処理装置。予め定められた所定の命令を検出した場合に、新たなウェブアプリケーションの実行が開始されたと判定する開始判定部をさらに備え、前記アプリ範囲管理部は、前記開始判定部により新たなウェブアプリケーションの実行が開始されたと判定された場合に、新たなウェブアプリケーションに対応する前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項1または7に記載の情報処理装置。前記ブラウザ部が複数のページファイルを含むアーカイブファイルを受信した場合に、該アーカイブファイルを複数のページファイルに展開するファイル展開部と、前記ファイル展開部により展開された複数のページファイルと、前記アーカイブファイルに含まれないファイルとを含む前記アプリ範囲情報を生成する生成部と、をさらに備え、前記アプリ範囲管理部は、前記生成部が生成した前記アプリ範囲情報を受信して前記記憶部に保存することを特徴とする請求項1または7に記載の情報処理装置。ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、記憶部と、を備える情報処理装置において実行される情報処理方法であって、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する工程と、前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する工程と、前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する工程と、実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す工程と、を含むことを特徴とする情報処理方法。ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行するブラウザ部と、記憶部と、を備える情報処理装置に、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する機能と、前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する機能と、前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する機能と、実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す機能と、を実現させるプログラム。本発明が解決しようとする課題は、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができる情報処理装置、情報処理方法、およびプログラムを提供することである。実施形態の情報処理装置は、ブラウザ部と、アプリ範囲管理部と、終了判定部と、利用可否判定部と、拡張機能呼出し部と、を備える。ブラウザ部は、ウェブアプリケーションを構成するページファイルをサーバ装置から受信して、受信したページファイルを処理してウェブアプリケーションを実行する。アプリ範囲管理部は、ウェブアプリケーションの実行開始時に、該ウェブアプリケーションに含まれるページファイルを表すアプリ範囲情報を受信して記憶部に保存する。終了判定部は、前記ブラウザ部が処理するページファイルが切り替わったときに、切り替え後のページファイルが前記アプリ範囲情報に含まれるか否かにより、実行中のウェブアプリケーションが終了したか否かを判定する。利用可否判定部は、前記ブラウザ部が対応していない機能である拡張機能の呼出しが要求されたときに、呼出しが要求された前記拡張機能が、実行中のウェブアプリケーションで利用が許可されているか否かを判定する。拡張機能呼出し部は、実行中のウェブアプリケーションで利用が許可されていると判定された場合に、呼出しが要求された前記拡張機能を呼出す。以下、実施形態の情報処理装置、情報処理方法、およびプログラムについて、図面を参照して説明する。第1の実施形態図1は、第1の実施形態の情報処理装置10を含む情報処理システムのハードウェア構成図である。図1に示す情報処理システムは、情報処理装置10と、サーバ装置20と、を備える。サーバ装置20は、クライアントとなる情報処理装置10に対してウェブアプリケーションを提供する。情報処理装置10は、サーバ装置20からウェブアプリケーションを実行するために必要な各種ファイルを受信して、ウェブアプリケーションを実行する。情報処理装置10とサーバ装置20は、例えばインターネットなどのネットワーク30により接続される。ウェブアプリケーションとは、ネットワークを介してプログラムやデータのやりとりを行うアプリケーションソフトウェアのことである。クライアント単体で実行できるアプリケーションであっても、そのアプリケーションのプログラムやデータの一部または全体をネットワークを介してやりとりすることが可能であれば、そのアプリケーションのことをウェブアプリケーションと呼ぶ。情報処理装置10は、主要なハードウェア構成として、CPU11、主記憶メモリ12、ストレージ13、ネットワークインタフェース14、ディスプレイ15、および入力機器16を備える。ストレージ13には、ブラウザプログラムと、拡張機能アクセス制御プログラムと、各種の拡張機能用のプログラム以下、単に拡張機能という。と、が格納されている。入力機器16は、例えば、マウス、キーボード、タッチパネルなどである。サーバ装置20は、主要なハードウェア構成として、ストレージ21およびネットワークインタフェース22を備える。ストレージ21には、ウェブアプリケーションの構成部品であるページファイルやメディアファイルが格納されている。ページファイルとは、ページを構成するための情報が記述されたファイルであり、ページを構成するための情報としては、例えば、文章の構造や画面表示方法や画面遷移に関する指定がある。ページファイルやメディアファイルは、URLと呼ばれる位置識別子を用いて、その位置サーバ装置20の位置とサーバ装置20内での位置が特定される。情報処理装置10とサーバ装置20は、ネットワークインタフェース14,22を用い、ネットワーク30を介して情報のやりとりを行う。情報処理装置10がサーバ装置20から提供されるウェブアプリケーションを実行する際には、まず下準備として、ウェブアプリケーションの実行環境であるブラウザプログラムの実行を行う。具体的には、CPU11が実行しているOSOperatingSystemなどのシェルプログラムが、ユーザの要求等に従い、ブラウザプログラムをストレージ13から読み出して主記憶メモリ12に保存する。そして、CPU11が、主記憶メモリ12に保存されたブラウザプログラムを実行する。その際、CPU11は、ブラウザプログラムとは別プログラムとなっている各種の拡張機能プラグインをストレージ13から読み出し、主記憶メモリ12に保存する。ウェブアプリケーションは、ユーザもしくはプログラム中からウェブアプリケーションに含まれるページファイルのURLが指定されることにより、その実行が開始される。その際、CPU11は、ネットワークインタフェース14に対して、指定されたURLのページファイルの取得命令を出す。ネットワークインタフェース14は、指定されたURLにより特定されるサーバ装置20に接続し、指定されたURLに該当するページファイルのダウンロード命令を出す。サーバ装置20のネットワークインタフェース22は、このダウンロード命令に応じてストレージ21から該当するページファイルを読み取り、クライアントである情報処理装置10に返す。情報処理装置10のネットワークインタフェース14は、サーバ装置20から取得したページファイルを主記憶メモリ12に保存する。ページファイルには、そのページファイルで利用するメディアファイルのURLが列挙されている。CPU11は、ページファイルの取得時と同様に、ネットワークインタフェース14に対してこれらメディアファイルの取得命令を出す。そして、ネットワークインタフェース14がサーバ装置20に対してこれらメディアファイルのダウンロード命令を出し、このダウンロード命令に応じてサーバ装置20のストレージ21から読み取られ、情報処理装置10に送られたメディアファイルを取得して、主記憶メモリ12やストレージ13に保存する。ウェブアプリケーションの実行に必要なファイルが用意された時点で、ブラウザプログラムは、主記憶メモリ12に保存されたページファイルをCPU11が解釈できる命令に変換する。そして、CPU11が、変換された命令を実行する。実行結果は、ページファイルに含まれる配置情報に従ってディスプレイ15に出力される。配置情報には、別のページファイルへ遷移するためのリンクが含まれている。このリンクは、遷移先のページファイルのURLと関連付けられている。ユーザ操作などによりそのリンクが選択されると、CPU11は、ネットワークインタフェース14に対して、そのリンクに関連付けられたURLのページファイルの取得命令を出す。そして、上記と同様に、サーバ装置20からそのURLにあるページファイルおよび当該ページファイルで利用するメディアファイルを取得し、必要なファイルがそろった時点で新たなページファイルの表示、実行を開始する。図2-1は、CPU11がページファイルを実行した場合にディスプレイ15に表示される画面の一例を示す図である。この図2-1の画面例では、動画メニュー画面という文字データ1や起動したい画面を選んで下さいという文字データ3、画像データ2に加えて、動画検索画面へのリンク4、本日の動画再生画面へのリンク5、およびお気に入りリスト画面へのリンク6が存在する。ユーザ操作などによりこれらのリンク4,5,6のいずれかが選択されると、リンク先のページファイルが実行されて、ディスプレイ15の表示が例えば図2-2のように変化する。図2-2は、図2-1の画面で本日の動画再生画面へのリンク5が選択された場合にディスプレイ15に表示される画面の一例を示している。本実施形態の情報処理装置10は、ストレージ13に、ブラウザプログラムに加えて、拡張機能アクセス制御プログラムを格納している。図3は、情報処理装置10のCPU11が、ブラウザプログラムおよび拡張機能アクセス制御プログラムを実行することにより実現される情報処理装置10内部の機能的な構成を示す機能ブロック図である。図3に示すように、情報処理装置10では、ブラウザプログラムの実行によりブラウザ部200が実現され、拡張機能アクセス制御プログラムの実行により拡張機能アクセス制御部100が実現される。ブラウザ部200は、アプリケーション実行部210と、拡張機能呼出し依頼部220と、を備える。アプリケーション実行部210は、ページファイル間の遷移要求に応じて、ページファイルおよびそのページファイルで利用されるメディアファイルを、サーバ装置20からネットワーク30を介して受信し、配置情報をもとに文字や画像をディスプレイ15に表示する機能を持つ。また、アプリケーション実行部210は、ページファイルに含まれるJava登録商標Scriptなどで記述された制御プログラムを実行する機能を持つ。拡張機能呼出し依頼部220は、ブラウザ部200の起動時に、ストレージ13に格納されている拡張機能の初期化を依頼する機能を持つ。また、拡張機能呼出し依頼部220は、ページファイルに含まれるプログラムの実行中に拡張機能の呼出しを検知し、拡張機能アクセス制御部100に対して呼出し先の拡張機能の識別子と呼び出す関数名を通知し、拡張機能の呼出しを依頼する機能を持つ。拡張機能アクセス制御部100は、拡張機能の読み込みや呼出しを行う拡張機能管理部110と、拡張機能の呼出し時に呼出し可否の判定を行うアクセス制御実行部120と、実行中のウェブアプリケーションのアプリ構成情報の管理を行うライフサイクル管理部130と、を備える。本実施形態の情報処理装置10では、ブラウザ部200が起動する際に、拡張機能呼出し依頼部220が呼び出される。拡張機能呼出し依頼部220は、拡張機能アクセス制御部100に対して拡張機能の初期化を依頼する。拡張機能アクセス制御部100の拡張機能管理部110は、拡張機能の初期化の依頼を検出し、ストレージ13から拡張機能を主記憶メモリ12に読み込み、拡張機能が持つ命令関数の呼出し先アドレスを格納する。このとき、ストレージ13から主記憶メモリ12に読み込む拡張機能は複数であってもよい。例えば、DLNA動画プレーヤ拡張機能と、ローカルファイルアクセス拡張機能とが別個の拡張機能として提供されてストレージ13に格納されている場合、これらDLNA動画プレーヤ拡張機能とローカルファイルアクセス拡張機能とをストレージ13から主記憶メモリ12に読み込む。DLNA動画プレーヤ拡張機能には、再生命令、再生停止命令、動画リスト取得命令などが含まれる。ローカルファイルアクセス拡張機能には、ファイル削除命令、ファイルリスト取得命令などが含まれる。さらに、拡張機能管理部110は、各拡張機能を識別するための識別子のリストを主記憶メモリ12に格納する。この識別子は、後述の拡張機能呼出し部112が拡張機能を呼出す際に、呼出す拡張機能を決定するために利用される。この識別子としては、具体的にはMIMEタイプ、ファイルの拡張子などを用いればよい。例えばMIMEタイプで拡張機能を識別する場合、DLNA動画プレーヤ拡張機能にはvideo/dlna-player、ローカルファイルアクセス拡張機能にはapplication/file-managerなどの名前を付ける。この識別子は、独自の拡張機能であれば、拡張機能の開発者が自由に決めることができる。拡張機能は複数の命令関数を持つことができ、個々の関数は、拡張機能の識別子と関数名の指定により、ウェブアプリケーションから呼出される。拡張機能管理部110は拡張機能の管理テーブルを持ち、個々の拡張機能で同じ関数名の関数があっても拡張機能の識別子で呼出す関数を区別できる。図4は、拡張機能管理部110が生成、管理する拡張機能管理テーブルの一例を示す図である。この図4に示す拡張機能管理テーブルの例では、拡張機能の識別子として、video/dlna-playerとapplication/file-managerとが存在し、関数名getfilelistは両方の拡張機能に存在する。拡張機能の呼出し時には、識別子と関数名との組が渡される。例えば、識別子application/file-managerと、関数名getfilelistとの組の呼出し依頼が拡張機能呼出し依頼部220から拡張機能管理部110にあった場合には、拡張機能管理部110は、図4に示すような拡張機能管理テーブルを参照し、指定された識別子と関数名に合致するアドレス56789に格納された関数を呼出す。アプリケーション実行部210は、ページファイル間の遷移時に、拡張機能アクセス制御部110に対して遷移先ページファイルの位置識別子であるURLを通知し、アプリ構成情報の更新を依頼する。アプリ構成情報は、対応するウェブアプリケーションに含まれる1つ以上のページファイルを表すアプリ範囲情報と、当該ウェブアプリケーションで利用が許可された拡張機能を表す情報である利用証明書と、を含む。アプリ範囲情報は、ウェブアプリケーションに含まれる各ページファイルの位置情報である。例えば、ウェブアプリケーションに含まれる各ページファイルの位置情報をリスト、具体的には位置識別子のリスト以下、URLリストという。にした情報などである。このURLリストは、ウェブアプリケーションがファイルを利用する場合に使用される。このとき、ブラウザ部10はファイルをサーバ装置20から能動的に取得しても、受動的に受け取ってもよい。以下の実施形態では、リストの形式で説明するが、アプリ範囲情報は特にリストに限定されるものではなく、ウェブアプリケーションに含まれる各ページファイルの位置情報が特定できるものであればよい。また、利用証明書も対応するウェブアプリケーションにおいて利用することが許可されたすべての拡張機能に対する利用証明書がリスト形式以下、利用証明書リストという。で記述されている。これらURLリストと利用証明書リストとを含むアプリ構成情報は、例えば、対応するウェブアプリケーションで最初に実行されるページファイルに組み込まれて提供される。図5-1は、ページファイルに組み込まれたアプリ構成情報のデータ構造の一例を示す図であり、図5-2は、図5-1のデータ構造に従って記述されたアプリ構成情報の一例を示す図である。この図5の例では、アプリ構成情報開始識別子である<appinfo>のタグとアプリ構成情報終了識別子である</appinfo>のタグとに挟まれた部分の情報が、アプリ構成情報である。また、アプリ構成情報内の位置識別子情報開始識別子である<url_list>のタグと位置識別子情報終了識別子である</url_list>のタグとに挟まれた部分の情報が、URLリストである。また、アプリ構成情報内の拡張機能利用証明書開始識別子である<cert_list>のタグと拡張機能利用証明書終了識別子である</cert_list>のタグとに挟まれた部分の情報が、利用証明書リストである。なお、本実施形態では、ウェブアプリケーションを構成するページファイルの一覧としてURLリストを用いるが、ウェブアプリケーションの範囲を特定可能な情報であれば、URLリスト以外の情報、例えばウェブアプリケーションを構成するページファイルのファイル名一覧などを用いてもよい。アクセス制御実行部120は、拡張機能呼出し依頼部220から呼出しが依頼された拡張機能の呼出し可否を判定し、拡張機能へのアクセス制御を実行する機能を有する。アクセス制御実行部120は、拡張機能呼出し依頼部220から呼出しが依頼された拡張機能が呼出し可能と判断すれば、拡張機能管理部110に対して拡張機能の呼出しを依頼する。ライフサイクル管理部130は、アプリ構成情報の更新依頼があった場合に起動され、必要に応じて、現在実行中のウェブアプリケーションに対応するアプリ構成情報の更新を行う機能を有する。このため、ライフサイクル管理部130は、遷移先ページにアプリ構成情報が含まれるか判定する機能や、ウェブアプリケーションの開始、終了、実行継続の判定を行う機能を持つ。本実施形態の情報処理装置10では、ライフサイクル管理部130が、ウェブアプリケーションの実行中にページの遷移があるたびに、遷移先ページの内容によってウェブアプリケーションの開始、終了、継続実行を自動的に判断する。そして、ウェブアプリケーションの実行中に拡張機能の呼出し要求があった場合には、アクセス制御実行部120が、ライフサイクル管理部130が管理しているアプリ構成情報に含まれる利用証明書リストをもとに、拡張機能のアクセス制御を行う。図6は、図3に示した情報処理装置10内部の機能的な構成をより詳細化した機能ブロック図である。以下、図6を用いて情報処理装置10の詳細な構成を説明する。拡張機能管理部110は、拡張機能ロード部111と、拡張機能呼出し部112と、を備える。拡張機能ロード部111は、ストレージ13に格納されている拡張機能を列挙して主記憶メモリ12へロードする。ストレージ13に格納されている拡張機能の列挙には、特定の拡張子を持つファイル名による区別や、拡張機能に特定関数が用意されているかどうかによる区別、特定のファイルに予め拡張機能のファイル名を列挙しておくなどの手段を用いればよい。拡張機能のロードに際して、拡張機能ロード部111は、各拡張機能の識別子ごとに、拡張機能が持つ関数のアドレスと関数名の対応関係を、図4に示した管理テーブルとして主記憶メモリ12に保存する。この対応関係の取得には、拡張機能の特定関数を呼び出す方法や、予め別ファイルに対応関係を記述しておく方法などがある。拡張機能呼出し部112は、ブラウザ部200の拡張機能呼出し依頼部220から拡張機能の呼出し依頼があった場合に、呼出す拡張機能の識別子と関数名を受け取り、拡張機能の呼出しを行う。拡張機能呼出し部112は、拡張機能ロード部111が主記憶メモリ12に保存した拡張機能の管理テーブルから、受け取った識別子と関数名に対応する関数のアドレスを取得し、そのアドレスに存在する拡張機能の関数を実際に呼出す処理を行う。アクセス制御実行部120は、拡張機能アクセス検出部121と、拡張機能呼出し可否判定部122と、を備える。拡張機能アクセス検出部121は、拡張機能呼出し依頼部220からの呼出し依頼と呼出し情報を受信し、拡張機能呼出し可否判定部122を呼出す。呼出し情報には、呼出す拡張機能の識別子と関数名が含まれる。拡張機能アクセス検出部121は、この拡張機能の識別子と関数名を渡して拡張機能呼出し可否判定部122を呼出し、該当する拡張機能の呼出し可否の判定および拡張機能の呼出しを依頼する。拡張機能呼出し可否判定部122は、拡張機能アクセス検出部121からの依頼を受け、呼出す拡張機能の識別子と関数名を受け取り、拡張機能の呼出し可否を判定する。この呼出し可否の判定のために、拡張機能呼出し可否判定部122は、ライフサイクル管理部130の後述する拡張機能利用証明書保存部136から現在実行中のウェブアプリケーションに対応するアプリ管理情報の利用証明書リストを取得する。そして、拡張機能呼出し可否判定部122は、呼出す拡張機能についての利用証明書が利用証明書リストに含まれていれば、呼出しが許可されていると判断し、拡張機能呼出し部112に対して、呼出す拡張機能の識別子と関数名を渡して呼出しを依頼する。ライフサイクル管理部130は、ページ遷移検出部131と、ページ種別振分け部132と、アプリ設定ロード部133と、アプリ終了判定部134と、アプリ範囲管理部135と、拡張機能利用証明書保存部136と、を備える。ページ遷移検出部131は、ブラウザ部200で実行中のページが切り替わったことを検出し、ページ種別振分け部132に対して、遷移先ページの位置識別子であるURLを通知する。ページ種別振分け部132は、遷移先ページのページファイルのMIMEタイプや拡張子、ページファイルの内容に特定タグが付加された情報が存在するかどうかなどにより、そのページファイルにアプリ構成情報が含まれているか否かを判定する。そして、ページ種別振分け部132は、ページファイルにアプリ構成情報が含まれているか否かの判定結果に基づき、新たなウェブアプリケーションの開始かどうかを判定する。本実施形態では、ウェブアプリケーションで最初に実行されるページファイルに、アプリ構成情報が含まれている。したがって、ページ種別振分け部132は、遷移先ページのページファイルにアプリ構成情報が含まれていれば、新たなウェブアプリケーションの開始であると判定することができる。新たなアプリケーションの開始と判定した場合、ページ種別振分け部132は、アプリ設定ロード部133を呼出す。アプリ設定ロード部133は、遷移先ページのページファイルに含まれる、新たなウェブアプリケーションに対応したアプリ構成情報をロードする。その際、アプリ設定ロード部133は、アプリ範囲管理部135に対して、アプリ構成情報のURLリストを渡し、URLリストの保存命令を出す。さらに、アプリ設定ロード部133は、拡張機能利用証明書保存部136に対して、アプリ構成情報の利用証明書リストを渡し、利用証明書リストの保存命令を出す。アプリ終了判定部134は、ページファイルの遷移時に、現在実行中のウェブアプリケーションが終了したかどうかを判定する。具体的には、アプリ終了判定部134は、アプリ範囲管理部135から現在実行中のウェブアプリケーションの範囲を表すURLリストを取得し、遷移先ページの位置識別子であるURLが、そのURLリストに含まれるか否かを判定する。そして、アプリ終了判定部134は、遷移先ページのURLがURLリストに含まれる場合にはウェブアプリケーションの実行継続と判定し、遷移先ページのURLがURLリストに含まれない場合には、ウェブアプリケーションの終了と判定する。アプリ終了判定部134は、ウェブアプリケーションの終了と判定した場合、アプリ範囲管理部135に対して、保存しているURLリストの消去命令を出すとともに、拡張機能利用証明書保存部136に対して、保存している利用証明書リストの消去命令を出す。アプリ範囲管理部135は、URLリストの保存命令、取得命令、消去命令を受け取り、その命令に応じて、主記憶メモリ12に保存してあるURLリストの更新や取得を行う。拡張機能利用証明書保存部136は、利用証明書リストの保存命令、取得命令、消去命令を受け取り、その命令に応じて、主記憶メモリ12に保存してある利用証明書リストの更新や取得を行う。次に、図7を参照して、ブラウザ部200の起動時の処理手順について説明する。図7は、ブラウザ部200が起動した際の処理手順を示すフローチャートである。ブラウザ部200が起動すると、拡張機能のロード処理、より詳しくは拡張機能の識別子を取得する処理と、拡張機能が持つ関数を列挙する処理とが行われる。以下は、その詳細である。ブラウザ部200が起動すると、ブラウザ部200は、まず、拡張機能アクセス制御プログラムをストレージ13から主記憶メモリ12にロードするステップS101。これにより、拡張機能アクセス制御部100が実現される。続いて、ブラウザ部200の拡張機能呼出し依頼部220が、拡張機能アクセス制御部100の拡張機能ロード部111に対して、拡張機能初期化要求を送信するステップS102。拡張機能ロード部111は、拡張機能呼出し依頼部220からの初期化要求を受け取り、ストレージ13から拡張機能を1件取り出す処理を行うステップS103。ここで、拡張機能ロード部111は、未処理の拡張機能がストレージ13内に存在するか否かを判定しステップS104、未処理の拡張機能が存在した場合にはステップS104:Yes、その拡張機能の識別子を取得するステップS105。さらに拡張機能ロード部111は、取得した識別子で示される拡張機能が持つ関数名と、その関数が格納されたアドレス関数アドレスとの対応関係を取得するステップS106。そして、拡張機能ロード部111は、ステップS105で取得した識別子と、ステップS106で取得した関数名およびその関数アドレスとを対応付けて、主記憶メモリ12に保存するステップS107。その後、拡張機能ロード部111は、拡張機能の初期化関数を呼出すステップS108。この際、初期化関数については予め関数名が決まっているため、関数名と関数アドレスとの対応関係から関数アドレスを決定できる。その後、拡張機能ロード部111は、ステップS103に戻って、ストレージ13内に未処理の拡張機能が存在しなくなるまで、ステップS103~ステップS108の処理を繰り返す。その結果、拡張機能ロード部111により図4に示したような管理テーブルが構築される。そして、ストレージ13内のすべての拡張機能に対する処理が終了するとステップS104:No、拡張機能ロード部111は、拡張機能呼出し依頼部220に対して、拡張機能の識別子のリストを返すステップS109。これにより、起動処理が完了し、ブラウザ部200は、ストレージ13に存在する拡張機能の一覧を知ることができる。次に、図8および図9を参照して、ページ遷移時の処理手順について説明する。図8は、ページ遷移時の概略的な処理手順を示すフローチャートであり、図9は、ページ遷移時の詳細な処理手順を示すフローチャートである。ページ遷移時にはウェブアプリケーションの開始、終了、実行継続の判定と、アプリ構成情報の更新処理が行われる。まず、図8を用いて、ページ遷移時の処理の概略について説明する。ページ遷移が発生すると、まず、遷移先ページの位置識別子であるURLが取得されステップS201、遷移先ページのページファイルがアプリ構成情報を含んでいるか否かが判定されるステップS202。そして、遷移先のページのページファイルにアプリ構成情報が含まれていればステップS202:Yes、新たなウェブアプリケーションの開始と判断され、それまで実行していたウェブアプリケーションに対応するアプリ構成情報が削除されステップS203、新たに実行するウェブアプリケーションに対応するアプリ構成情報が保存されるステップS204。このアプリ構成情報には、上述したように、ウェブアプリケーションの範囲ウェブアプリケーションに含まれるページファイルを表すURLリストと、ウェブアプリケーションでどの拡張機能の利用が許可されているかを示す利用証明書リストとが含まれる。一方、遷移先のページのページファイルにアプリ構成情報が含まれていなければステップS202:No、現在実行中のウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストが取得されステップS205、遷移先ページのURLがURLリストに含まれているか否かが判定されるステップ206。そして、遷移先のページのURLがURLリストに含まれていればステップS206:Yes、ウェブアプリケーションの実行継続と判断され、そのまま処理を終了する。一方、遷移先のページのURLがURLリストに含まれていなければステップS206:No、ウェブアプリケーションの終了と判断され、それまで実行していたウェブアプリケーションに対応するアプリ構成情報が削除されるステップS207。次に、図9を用いて、ページ遷移時の処理をより詳細に説明する。ページ遷移が発生すると、まずブラウザ部200のアプリケーション実行部210が、拡張機能アクセス制御部100のライフサイクル管理部130内にあるページ遷移検出部131に対して、ページ遷移が発生したことを遷移先ページのURLとともに通知するステップS301。ページ遷移検出部131は、アプリケーション実行部210から遷移先ページのURLを取得するとステップS302、遷移先ページのURLを渡してページ種別振分け部132を呼出すステップS303。ページ種別振分け部132は、新たなウェブアプリケーションの開始かどうかを判断するために、遷移先ページのページファイルを取得し、そのページファイルにアプリ構成情報が含まれているか否かを判定するステップS304。この判定は、例えば、遷移先ページのページファイルの拡張子やMIMEタイプが、アプリ構成情報を含むページファイルに特有の拡張子やMIMEタイプであるか否か、あるいはページファイル内に図5-2に示した<appinfo>や</appinfo>といった特別なタグが含まれているか否かを判定基準として実施すればよい。遷移先ページのページファイルにアプリ構成情報が含まれている場合ステップS304:Yes、ページ種別振分け部132は、新たなウェブアプリケーションが開始されたものと判断し、遷移先ページファイルに含まれるアプリ構成情報を渡してアプリ設定ロード部133を呼出すステップS305。アプリ設定ロード部133は、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135に対してURLリストの削除命令を出すとともにステップS306、拡張機能利用証明書保存部136に対して利用証明書リストの削除命令を出すステップS307。その後、アプリ設定ロード部133は、新たなウェブアプリケーションに対応するアプリ構成情報を保存するために、アプリ範囲管理部135に対して、アプリ構成情報に含まれるURLリストを通知して保存命令を出すとともにステップS308、拡張機能利用証明書保存部136に対して、アプリ構成情報に含まれる利用証明書リストを通知して保存命令を出すステップS309。アプリ範囲管理部135および拡張機能利用証明書保存部136は、アプリ設定ロード部133からの命令に従ってURLリストや利用証明書リストの削除、保存を行う。これにより、新たなウェブアプリケーションに対応したアプリ構成情報に含まれるURLリストおよび利用証明書リストが主記憶メモリ12に保存される。一方、遷移先ページのページファイルにアプリ構成情報が含まれていない場合ステップS304:No、ページ種別振分け部132は、現在実行中のアプリケーションが継続実行、終了のいずれかであると判断し、そのどちらかであるかを判断するために、遷移先ページのURLを渡してアプリ終了判定部134を呼出す。アプリ終了判定部134は、ページ種別振分け部132から遷移先ページのURLを取得すると、まず、アプリ範囲管理部135に対してURLリストの取得命令を出す。アプリ範囲管理部135は、アプリ終了判定部134からのURLリストの取得命令に応じて、主記憶メモリ12に保存されているURLリストを取得する処理を行って、取得したURLリストをアプリ終了判定部134に返すステップS310。このとき、アプリ終了判定部134は、アプリ範囲管理部135が取得したURLリストの有無を判定しステップS311、アプリ範囲管理部135が取得したURLリストがなければステップS311:No、そのまま処理を終了する。一方、アプリ範囲管理部135が取得したURLリストがあればステップS311:Yes、ページ種別振分け部132から取得した遷移先ページのURLがそのURLリストに含まれているか否かを判定するステップS312。そして、遷移先ページのURLがURLリストに含まれている場合ステップS312:Yes、アプリ終了判定部134は、同一のウェブアプリケーションの実行が継続されているものと判断し、そのまま処理を終了する。一方、遷移先ページのURLがURLリストに含まれていない場合ステップS312:No、アプリ終了判定部134は、それまで実行していたウェブアプリケーションが終了したものと判断し、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135に対してURLリストの削除命令を出すとともにステップS313、拡張機能利用証明書保存部136に対して利用証明書リストの削除命令を出すステップS314。アプリ範囲管理部135および拡張機能利用証明書保存部136は、アプリ設定ロード部133からの命令に従って、URLリストや利用証明書リストの削除を行う。次に、図10を参照して、拡張機能呼出し時の処理手順について説明する。図10は、拡張機能呼出し時の処理手順を示すフローチャートである。拡張機能呼出し時には、主に拡張機能呼出し可否判定部122が現在実行中のウェブアプリケーションの利用証明書リストに基づいて、呼出す拡張機能の利用が現在実行中のウェブアプリケーションで許可されているかどうかを判定し、利用が許可されていれば、実際にその拡張機能を呼出す処理を行う。拡張機能の呼出し要求が発生すると、まず、ブラウザ部200の拡張機能呼出し依頼部220が、呼び出し要求のあった拡張機能の識別子、関数名、関数に渡す引数などを渡して拡張機能アクセス制御部100のアクセス制御実行部120内の拡張機能アクセス検出部121を呼出し、拡張機能の呼出しを依頼するステップS401。拡張機能アクセス検出部121は、それを受け取り、拡張機能呼出し可否判定部122に対して、呼出し要求のあった拡張機能の識別子、関数名、関数に渡す引数を渡して、拡張機能呼出し可否の判定と呼出しを依頼するステップS402。拡張機能呼出し可否判定部122は、呼出し要求のあった拡張機能の識別子を取得しステップS403、実際にその拡張機能が存在するか確認するために、拡張機能ロード部111が主記憶メモリ12に保存した拡張機能の識別子のリストを主記憶メモリ12から読み出すステップS404。次に、拡張機能呼出し可否判定部122は、そのリストの中に呼出し要求があった拡張機能の識別子があるかどうか判定するステップS405。そして、呼出し要求のあった拡張機能の識別子がリストの中に存在しなければステップS405:No、拡張機能呼出し依頼部220に対してエラーを通知するステップS406。一方、呼出し要求のあった拡張機能の識別子がリストの中に存在する場合にはステップS405:Yes、拡張機能呼出し可否判定部122は、現在実行しているウェブアプリケーションでその拡張機能の利用が許可されているか否かを判断するために、まず拡張機能利用証明書保存部136に対して利用証明書リストの取得要求を出し、拡張機能利用証明書保存部136から利用証明書リストを取得するステップS407。そして、拡張機能呼出し可否判定部122は、取得した利用証明書リストの中に呼出し要求のあった拡張機能の識別子に対応する利用証明書があるかどうかを判定しステップS408、対応する利用証明書がない場合にはステップS408:No、現在実行されているウェブアプリケーションでは呼出し要求のあった拡張機能の利用が許可されていないものと判断して、拡張機能呼出し依頼部220にエラーを通知するステップS406。一方、利用証明書リストの中に対応する利用証明書があった場合にはステップS408:Yes、拡張機能呼出し可否判定部122は、呼出し要求のあった拡張機能の利用が許可されているものと判断し、拡張機能呼出し部112に対して、拡張機能の識別子、関数名、関数に渡す引数などを渡して、拡張機能の呼び出しを依頼する。拡張機能呼出し部112は、実際に拡張機能を呼出すために、拡張機能ロード部111が保存した図4のような管理テーブルを参照し、呼出す拡張機能の識別子に対応する関数名から呼出す関数のアドレスを取得するステップS409。そして、拡張機能呼出し部112は、関数に渡す引数を引数として、取得したアドレスの関数拡張機能の呼出しを実行するステップS410。そして、拡張機能呼出し部112は、拡張機能呼出し依頼部220に対して、関数の呼出し結果、すなわち拡張機能の呼出した関数の戻り値を返すステップS411。以上説明したように、本実施形態では、ウェブアプリケーションの範囲を表すURLリストを含むアプリ構成情報を、ウェブアプリケーションで最初に実行されるページファイルに格納している。そして、情報処理装置10がウェブアプリケーションを実行する際に、実行中のウェブアプリケーションに対応するアプリ構成情報を保存し、ウェブアプリケーションの実行中にページ遷移が発生した場合に、遷移先ページのページファイルがアプリ構成情報を含んでいるか、さらに、遷移先ページのページファイルがアプリ構成情報を含まない場合には、遷移先のページのURLがURLリストに含まれるか否かを判定することで、ウェブアプリケーションの開始、実行継続、実行終了を判定するようにしている。したがって、本実施形態によれば、従来は困難であったウェブアプリケーション間の遷移を検出できるので、ウェブアプリケーション単位で拡張機能へのアクセス制御を行うことができる。これにより、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができるため、従来はセキュリティ上の理由から公開が困難であった一部の拡張機能について、アクセス許可を限定して公開することができるようになり、ウェブアプリケーションで作成できるアプリケーションの幅を広げることが可能となる。例えば、前述のローカルファイルアクセス拡張機能の一部としてファイル削除などの機能を提供したい場合には、すべてのウェブアプリケーション作成者に機能を公開してしまうとユーザ環境を破壊するようなウィルスも作成されてしまう危険性があるが、本実施形態により、拡張機能の利用者を限定することによりリスクを軽減することができる。また、本実施形態により拡張機能の利用の幅が広がることで、従来はC/Cなどの言語で開発していたプラットホーム特有のアプリケーションを、従来のウェブアプリケーションで記述できない機能のみをC/C言語などにより拡張機能として開発し、残りのユーザインタフェースの部分などをウェブアプリケーションで開発できるといった利点もある。一般に、C/Cのようなネイティブアプリケーションでアプリケーションを開発するコストに比べて、ウェブアプリケーションの開発コストは低いため、ソフトウェア開発コストが削減できる。このように、本実施形態では、ウェブアプリケーションを構成するページファイルの一覧URLリストを用意し、その一覧を元にウェブアプリケーションを識別しその範囲でセキュリティを適用する。従来のOMTPOpenMobileTerminalPlatformBONDI規格非特許文献1などのウィジェット規格の中には、ウェブアプリケーションの技術を用いてアプリケーションを構成するものもある。しかし、従来のウィジェット規格の多くは、予めアプリケーションの開発者が複数のページファイルやメディアファイルを圧縮技術により一つのファイルウィジェットアーカイブファイルにまとめておき、それを一つのアプリケーションとみなし、セキュリティ適用を行うものが多い。しかし、ウィジェットアーカイブファイルにまとめてしまうと、ページファイルの一部を修正した場合でも、ウィジェットアーカイブファイルを再度アップデートする必要があるため効率が悪い。また、ウェブアプリケーションにおいては、サーバ装置側で動的にページファイルやメディアファイルを生成するような場合もあり、それらにウィジェットアーカイブファイルによる方式を適用するのは困難である。これに対して、本実施形態では、ページの一部を更新する場合には修正したいページファイルのみを修正するだけでよく、アプリケーションアップデートの手間が小さいという利点がある。また、従来の一部の技術特許文献1、非特許文献1では、ページファイル単位でセキュリティポリシを記述することも可能である。しかし、特許文献1、非特許文献1では、ページ単位でセキュリティポリシを記述するため、アプリケーションが多くのページファイルから構成される場合、セキュリティポリシが膨大になる。また、アプリケーション全体でセキュリティポリシをアップデートする場合には、個々のページファイルのセキュリティポリシをアップデートする必要があり、セキュリティポリシ管理の手間が大きい。これに対して、本実施形態では、ウェブアプリケーション単位でセキュリティポリシを記述すればよいため、ウェブアプリケーション全体のセキュリティポリシをアップデートする場合にもコストが小さく、また、セキュリティポリシも膨大になりにくいという利点がある。また、従来、複数のページ単位で同一のセキュリティポリシを適用する規格としては、HTML5規格のSame-originpolicy非特許文献2が存在する。これは、同一ドメインのページファイルではオブジェクトへの相互アクセスを許可するものであり、ドメイン間でのアクセス許可やセキュリティポリシの使い分けはできない。ウェブアプリケーションにおいては、マッシュアップと呼ばれる複数のサービスを連携させて新しいアプリケーションを作る技術が一般的なものとなっているが、Same-originpolicyは、マッシュアップ時のアプリケーション作成の枷となっている。これに対して、本実施形態では、ウェブアプリケーションを構成するページファイルを記述する際に、個々のページファイルのドメインが一致している必要はない。すなわち、ドメインを跨いでの同一セキュリティポリシの適用が可能となるため、機器機能を利用するマッシュアップも可能になるという利点がある。第2の実施形態次に、第2の実施形態について説明する。図11は、第2の実施形態の情報処理装置10-2を含む情報処理システムのハードウェア構成図である。図1に示した第1の実施形態の構成と比較すると、サーバ装置20-2のストレージ21-2に、コンフィギュレーションファイルと呼ばれるファイルが格納されている点が異なっている。以下、第1の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第2の実施形態の特徴部分についてのみ説明する。第1の実施形態では、ページファイルの内部に、ページ表示情報や配置情報に加えて、アプリ構成情報が含まれていた。これに対して、第2の実施形態では、ページファイルとは別のファイルとして、アプリ構成情報のみが含まれるファイルを用意する。このアプリ構成情報のみが含まれるファイルをコンフィギュレーションファイルと呼ぶ。図12は、コンフィギュレーションファイルのデータ構造の一例を示す図である。コンフィギュレーションファイル中には、ウェブアプリケーションの範囲と利用可能な拡張機能を示すアプリ構成情報が含まれている。アプリ構成情報開始識別子とアプリ構成情報終了識別子とに挟まれた部分の情報が、アプリ構成情報である。アプリ構成情報内の位置識別子情報開始識別子と位置識別子情報終了識別子とに挟まれた部分の情報がURLリストであり、アプリ構成情報内の拡張機能利用証明書開始識別子と拡張機能利用証明書終了識別子とに挟まれた部分の情報が、利用証明書リストである。また、コンフィギュレーションファイル中のアプリ構成情報には、当該コンフィギュレーションファイルのロード後に遷移する先のページファイルウェブアプリケーションで最初に実行されるページファイルの位置識別子スタートアップURLが記述されている。図13は、第2の実施形態の情報処理装置10-2内部の機能的な構成を示す機能ブロック図である。図6に示した第1の実施形態の構成と比較すると、拡張機能アクセス制御部100-2のライフサイクル管理部130-2内のアプリ設定ロード部133-2の機能が、第1の実施形態のアプリ設定ロード部133と異なっている。すなわち、第2の実施形態のアプリ設定ロード部133-2は、第1の実施形態におけるアプリ設定ロード部133の機能に加えて、さらに、コンフィギュレーションファイルへのアクセス時に自動的に遷移するページファイルの情報スタートアップURLを得る機能と、遷移命令を出す機能とを有する。図14は、第2の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、利用証明書リストを保存する処理ステップS509の後に、コンフィギュレーションファイルからウェブアプリケーションで最初に実行されるページファイルへと自動的に遷移する処理ステップS510、ステップS511が加わっている点が異なる。図14のステップS501からステップS509までの処理は、図9に示したステップS301からステップS309までの処理と同じである。ただし、ステップS504でYesと判定されるのは、遷移先ページがコンフィギュレーションファイルの場合となる。第2の実施形態では、ステップS509で利用証明書リストを保存した後、アプリ設定ロード部133-2が、コンフィギュレーションファイルから実行するページファイルの位置識別子スタートアップURLを取得しステップS510、アプリケーション実行部210に対してスタートアップURLと遷移命令を通知して、スタートアップURLに遷移するステップS511。その後の処理、すなわち、図14のステップS512からステップS516までの処理は、図9に示したステップS310からステップS314までの処理と同じである。第2の実施形態では、ウェブアプリケーションの範囲と利用可能な拡張機能を示すアプリ構成情報が、ページファイルとは分離された独立のコンフィギュレーションファイルとして提供されるため、ページファイルには手を加える必要がなくなる。すなわち、ページファイルは従来のページファイルを全く変更しなくてもよいため、ウェブアプリケーションの既存資産を最大限活用することができる。また、第2の実施形態では、新たにコンフィギュレーションファイルを生成するだけでよいため、アプリケーション開発コストも従来のアプリケーション開発コストと大きく変わらないという利点がある。第3の実施形態次に、第3の実施形態について説明する。第1の実施形態では、拡張機能利用証明書保存部136が拡張機能ごとの利用証明書のリストである利用証明書リストを管理し、拡張機能呼出し可否判定部122が、拡張機能ごとに呼出し可否を判定するようにしていた。これに対して第3の実施形態では、拡張機能に付随するセキュリティポリシを管理し、1つの拡張機能に含まれる複数の機能のうちで利用を許可する機能を限定できるようにしている。図15は、第3の実施形態の情報処理装置10-3内部の機能的な構成を示す機能ブロック図である。図6に示した第1の実施形態の構成と比較すると、拡張機能アクセス制御部100-3の拡張機能管理部110-3内にセキュリティポリシ管理部113が付加されている点が異なっている。以下、第1の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第3の実施形態の特徴部分についてのみ説明する。図16は、セキュリティポリシ管理部113の内部構成を示すブロック図である。セキュリティポリシ管理部113は、図16に示すように、セキュリティポリシロード部113aと、セキュリティポリシ取得部113bと、を備える。セキュリティポリシロード部113aは、拡張機能の識別子を受信して、対応する拡張機能のセキュリティポリシを主記憶メモリ12にロードする。図17-1は、第3の実施形態においてセキュリティポリシロード部113aによりロードされるセキュリティポリシのデータ構造の一例を示す図である。図17-1のデータ構造を持った拡張機能のセキュリティポリシが格納されたファイルセキュリティポリシファイルは、拡張機能ごとに用意される。セキュリティポリシファイルは、例えば、拡張機能の識別子と同名のファイル名など、識別子からファイル名が決定できるように命名されていてもよい。また、セキュリティポリシファイルは、特定の拡張子が決められており、セキュリティポリシのデータ構造の中に対応する識別子が記述されるようにしてもよい。セキュリティポリシファイルは、ストレージ13内に配置されている。セキュリティポリシは、1個以上のセキュリティポリシエレメント部から構成される。セキュリティポリシエレメント部には、セキュリティポリシエレメント識別子とそのセキュリティポリシエレメントを適用した場合に呼出しを許可する関数の関数名が列挙されている。関数名は、ワイルドカードや正規表現などを使って条件を指定してもよい。図17-2は、図17-1のデータ構造に従って記述されたセキュリティポリシファイルの一例を示す図である。例えば、dlna-player-policy1という識別子を持ったセキュリティポリシエレメントを適用する場合には、hoge、foo、barといった名前の関数呼出しが許可される。セキュリティポリシ取得部113bは、拡張機能の識別子とセキュリティポリシエレメント識別子を受信して、対応するセキュリティポリシエレメントの内容を返す。図18-1は、第3の実施形態におけるアプリ構成情報のデータ構造の一例を示す図であり、図18-2は、図18-1のデータ構造に従って記述されたアプリ構成情報の一例を示す図である。この図18に例示するアプリ構成情報は、図5に示した第1の実施形態におけるアプリ構成情報と比較して、URLリストの各利用証明書の中に適用するセキュリティポリシの識別子が含まれている点が異なっている。すなわち、図5の例では、利用証明書リストに、利用が許可された拡張機能の識別子MIMEタイプなどのみが記述されていたが、図18の例では、利用が許可された拡張機能の識別子に加えて、適用するセキュリティポリシエレメント識別子も記述されている。このセキュリティポリシエレメント識別子は、図17に示したセキュリティポリシファイルのセキュリティポリシエレメント識別子と対応する。図19は、図17-2に示したセキュリティポリシファイルと図18-2に示したアプリ構成情報との対応関係を示す図である。図18-2に示したアプリ構成情報を持つウェブアプリケーションでは、識別子がvideo/dlna-playerという拡張機能を利用する場合、dlna-player-policy2というセキュリティポリシエレメントが適用され、そのセキュリティポリシの内容は、図17-2から、hoge、bar2などの関数の呼出しを許可するものであることがわかる。第3の実施形態では、アクセス制御実行部120-3の拡張機能呼出し可否判定部122-3が、セキュリティポリシ管理部113と拡張機能利用証明書保存部136との双方と連携し、ウェブアプリケーション単位でセキュリティポリシの適用を行うようにしている。これにより、同じ拡張機能であっても、ウェブアプリケーションによって適用するセキュリティポリシを切り替えることが可能となる。図20は、第3の実施形態においてブラウザ部200が起動した際の処理手順を示すフローチャートである。図7に示した第1の実施形態の処理手順と比較すると、ストレージ13内の拡張機能の識別子を取得ステップS605した後に、セキュリティポリシロード部113aがセキュリティポリシをロードする処理ステップS606~ステップS609が加わっている点が異なる。図20のステップS601からステップS605までの処理は、図7に示したステップS101からステップS105までの処理と同じである。第3の実施形態では、拡張機能ロード部111がステップS605で拡張機能の識別子を取得した後、その識別子をセキュリティポリシロード部113aに渡し、対応するセキュリティポリシのロードを依頼する。セキュリティポリシロード部113aは、受け取った拡張機能の識別子などから対応するセキュリティポリシのファイル名に変換を行い、セキュリティポリシファイルを取り出す処理を行うステップS606。例えば、セキュリティポリシのファイル名の命名規則を、識別子.cfgというように決めておけば、単純に、識別子がvideo/dlna-playerの拡張機能については、video/dlna-player.cfgのように変換することができる。次に、セキュリティポリシロード部113aは、ステップS605で取得した識別子に対応するセキュリティポリシファイルをステップS606で取り出せたかどうか対応するセキュリティポリシファイルが存在したかどうかを判定するステップS607。そして、セキュリティポリシファイルが存在しなかった場合にはステップS607:No、セキュリティポリシロード部113aは、予め定めたデフォルトのセキュリティポリシを取り出すステップS608。このデフォルトのセキュリティポリシは、例えば、全関数の呼び出し拒否、呼出し許可などといった単純なポリシとしておく。一方、セキュリティポリシファイルが存在した場合はステップS607:Yes、ステップS608の処理は行わずに、ステップS609に進む。その後、セキュリティポリシロード部113aは、ステップS606またはステップS608で取り出したセキュリティポリシを、拡張機能の識別子と対応付けて主記憶メモリ12に保存しステップS609、拡張機能ロード部111に処理を返す。その後の処理、すなわち、図20のステップS610からステップS613までの処理は、図7に示したステップS106からステップS109までの処理と同じである。図21は、第3の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図10に示した第1の実施形態の処理手順と比較すると、呼出し要求のあった拡張機能に対応する利用証明書があると判定された後にステップS708:Yes、呼出し要求のあった拡張機能に対応するセキュリティポリシエレメントを取得して、拡張機能の利用証明書とセキュリティポリシとの双方から拡張機能の利用可否を判定する処理ステップS709~ステップS711が加わっている点が異なる。図21のステップS701からステップS708までの処理は、図10に示したステップS401からステップS408までの処理と同じである。第3の実施形態では、拡張機能呼出し可否判定部122-3が、適用するセキュリティポリシエレメントの内容を得るために、呼出し要求のあった拡張機能に対応する利用証明書があると判定した場合にステップS708:Yes、アプリ構成情報に記述されている適用するセキュリティポリシエレメントの識別子を取得するステップS709。その後、拡張機能呼出し可否判定部122-3は、取得したセキュリティポリシエレメント識別子と拡張機能の識別子とをセキュリティポリシ取得部113bに渡し、対応するセキュリティポリシエレメントの取得を依頼する。セキュリティポリシ取得部113bは、セキュリティポリシロード部113aが主記憶メモリ12に保存したセキュリティポリシから、該当するセキュリティポリシエレメントを返すステップS710。拡張機能呼出し可否判定部122-3は、呼び出す関数名が、取得したセキュリティポリシエレメントにあるかどうか、もしくはセキュリティポリシエレメントの関数名が条件で指定されている場合には、その条件に合致するかどうかにより、関数の呼出しが許可されているか否かを判定するステップS711。そして、関数の呼出しが許可されていないと判定した場合はステップS711:No、ステップS706において拡張機能呼出し依頼部220にエラーを通知する。一方、関数の呼出しが許可されていると判定した場合はステップS711:Yes、拡張機能呼出し部112に対して、拡張機能の識別子、関数名、関数に渡す引数などを渡して、拡張機能の呼び出しを依頼する。その後の処理、すなわち、図21のステップS712からステップS714までの処理は、図10に示したステップS409からステップS411までの処理と同じである。以上説明したように、第3の実施形態によれば、アプリ構成情報の利用証明書リストにセキュリティポリシの情報を付加して提供するようにしているので、ウェブアプリケーションに対して利用を許可する拡張機能の内容を、拡張機能に含まれる個々の機能単位で限定することができる。また、アプリ構成情報の利用証明書リストにセキュリティポリシの識別子を記述するとともに、拡張機能のセキュリティポリシを識別子で管理するようにしているので、拡張機能の開発者が利用を許可する拡張機能のポリシを変えたい場合には、ウェブアプリケーション側の利用証明書を更新する必要なく、ポリシを更新するだけで利用を許可する拡張機能のポリシを変更することができる。すなわち、第3の実施形態により、ウェブアプリケーションのリボーク機能を実現することが可能である。なお、第3の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。第4の実施形態次に、第4の実施形態について説明する。上述した第1乃至第3の実施形態では、拡張機能の利用証明書に対する安全性検証を行っていなかった。このため、悪意あるアプリケーション開発者が開発したウェブアプリケーションのページファイルやコンフィギュレーションファイルに拡張機能の不正な利用証明書を添付して、不正に拡張機能を利用される虞があった。第4の実施形態では、拡張機能の作成者など信頼できる者がウェブアプリケーションごとに署名の付いた正当な拡張機能の利用証明書を発行し、アプリケーション開発者は、アプリ構成情報にその正当な拡張機能の利用証明書を含めるようにする。さらに、第4の実施形態では、情報処理装置10-4が拡張機能の利用証明書についての完全性検証を行うことにより、拡張機能の作成者の意図しない拡張機能の不正利用を防止するようにしている。図22は、第4の実施形態の情報処理装置10-4内部の機能的な構成を示す機能ブロック図である。図15に示した第3の実施形態の構成と比較すると、拡張機能アクセス制御部100-4にデータ検証部150が付加されている点が異なっている。以下、第1乃至第3の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第4の実施形態の特徴部分についてのみ説明する。データ検証部150は、署名検証部151を備える。図23は、署名検証部151の内部構成を示すブロック図である。署名検証部151は、図23に示すように、データ正規化部151aと、アプリケーション固有データ生成部151bと、ハッシュ計算部151cと、鍵保存部151dと、証明書有効性検証部151eと、証明書解析部151fと、復号処理部151gと、を備える。図24は、第4の実施形態においてセキュリティポリシロード部113aによりロードされるセキュリティポリシのデータ構造の一例を示す図である。図17-1に示した第3の実施形態におけるセキュリティポリシのデータ構造と比較して、証明書検証用公開鍵が含まれる点が異なっている。第4の実施形態では、この証明書検証用公開鍵を用いて利用証明書の検証を行う。この証明書検証用公開鍵は、拡張機能ごともしくは拡張機能の制作者ごとに生成される。また、証明書検証用公開鍵に対応する秘密鍵は、拡張機能の制作者のみが持ち、アプリ構成情報に含まれる拡張機能の利用証明書に付加する利用証明書検証用データを作成する際に利用される。図25は、第4の実施形態におけるアプリ構成情報のデータ構造の一例を示す図である。図18-1に示した第3の実施形態におけるアプリ構成情報のデータ構造と比較して、利用証明書検証データが含まれている点が異なっている。この利用証明書検証データは、拡張機能の利用証明書1件につき、1つずつ含まれている。署名検証部151は、アプリ構成情報に含まれる利用証明書を検証する。具体的には、署名検証部151は、データ正規化部151aにより、拡張機能の利用証明書の正規化処理を行う。そして、正規化処理後のデータとアプリケーション固有データ生成部151bが生成したデータを合成した後、ハッシュ計算部151cにより、そのデータのハッシュ値を計算する。さらに、復号処理部151gにより、拡張機能の利用証明書に添付されたハッシュ値を鍵保存部151dが保存した拡張機能の証明書検証用公開鍵で復号し、ハッシュ計算部151cが計算したハッシュ値と比較することで改ざん検証を行う。さらに、証明書有効性検証部151eによる利用証明書の有効期間の検証や、リボークリストに基づく有効性の検証などを、必要に応じて行うようにしてもよい。第4の実施形態では、拡張機能の利用証明書に、拡張機能の秘密鍵で暗号化されたハッシュ値利用証明書検証データと、対象拡張機能の識別子と、セキュリティポリシの管理を行う場合にはセキュリティポリシエレメントの識別子と、が少なくとも含まれる。署名検証部151は、証明書解析部151fが、アプリケーション固有データ生成部151bと連携して、拡張機能の利用証明書の改ざん検証を行うようにしている。以下、第4の実施形態において特徴的な署名検証部151の処理についてさらに詳しく説明する。証明書解析部151fは、アプリ構成情報を受け取り、拡張機能の利用証明書を解析する。アプリ構成情報に複数の利用証明書が含まれる場合には利用証明書を分離して、データ正規化部151a、アプリケーション固有データ生成部151b、ハッシュ計算部151c、鍵保存部151d、証明書有効性検証部151e、および復号処理部151gと連携して、利用証明書が改ざんされていないか、現在実行中のウェブアプリケーション向けに発行された利用証明書であるかどうか判断する。さらに、これらの結果から利用証明書が有効と判断された場合には、その利用証明書を主記憶メモリ12に保存する。データ正規化部151aは、利用証明書データを受け取り、この利用証明書データの正規化処理を行う。なお、拡張機能の利用証明書やセキュリティポリシファイルは、例えばXMLなどのデータ記述言語を用いて記述することができる。XMLなどのデータ記述言語では、データの順序などが異なった場合でも同じ意味をなす場合があり、処理によってはデータを正規化する必要があるために、データ正規化部151aを利用する。拡張機能の利用証明書の正規化が必要ない場合には、データ正規化部151aは不要となる。アプリケーション固有データ生成部151bは、ウェブアプリケーションに固有なデータを生成する。このアプリケーション固有データとしては、例えば、アプリ構成情報に含まれるURLリストのハッシュ値や、署名が付いたウェブアプリケーションのIDなどを用いることができる。また、第2の実施形態のようにアプリ構成情報をコンフィギュレーションファイルとして独立のファイルで提供する場合には、コンフィギュレーションファイルのURL自体をアプリケーション固有データとして用いるようにしてもよい。ただし、アプリケーション固有データは、偽装や他者がコピー不可能な情報である必要がある。ハッシュ計算部151cは、データ正規化部151aにより正規化処理が行われたデータとアプリケーション固有データ生成部151bが生成したデータとを合成したデータのハッシュ値を計算する。ハッシュ値の計算アルゴリズムとしては、SHA1やMD5などの一般的に知られたアルゴリズムを用いればよい。また、ハッシュ値の格納形式などは、X.509、XMLSignatureなどの既存の方式を用いればよい。復号処理部151gは、利用証明書に格納されたデータから暗号化されたハッシュ値を抜き出し、鍵保存部151dから取得した鍵データ証明書検証用公開鍵でハッシュ値を復号する。暗号復号アルゴリズムとしては、RSAなど、よく知られた公開鍵暗号の仕組みを使えばよい。鍵保存部151dは、各拡張機能に対応する証明書検証用公開鍵を命令に応じて保存または取得する。証明書有効性検証部151eは、利用証明書が有効かどうか判定する。判定の方法としては、例えば、利用証明書に有効期限のデータが格納されている場合には、現在の日時との比較を行い有効期限の範囲内かどうかを判定するといった方法が考えられる。また、利用証明書のリボークリストを別途用意して利用証明書が有効であるかどうかを判定するといった方法も考えられる。なお、条件に合致しない利用証明書を失効させる必要がない場合には、この証明書有効性検証部151eは不要である。図26は、第4の実施形態においてブラウザ部200が起動した際の処理手順を示すフローチャートである。図20に示した第3の実施形態の処理手順と比較すると、セキュリティポリシロード部113aがステップS805で取得した識別子に対応するセキュリティポリシファイルが存在する場合にステップS807:Yes、署名検証部151の鍵保存部151dが、ステップS805で取得した識別子で示される拡張機能に対応する証明書検証用公開鍵を保存する処理ステップS809が加わっている点が異なる。図26のステップS801からステップS807までの処理は、図20に示したステップS601からステップS608までの処理と同じである。第4の実施形態では、セキュリティポリシロード部113aが、ステップS805で取得した識別子に対応するセキュリティポリシファイルが存在すると判定した場合にステップS807:Yes、拡張機能ごとの証明書検証用公開鍵を保存するために、鍵保存部151dを呼出して拡張機能の識別子とセキュリティポリシデータを渡す。そして、鍵保存部151dは、セキュリティポリシに含まれる鍵データ証明書検証用公開鍵を、拡張機能の識別子と対応付けて主記憶メモリ12に保存するステップS809。これにより、拡張機能ごとの鍵データが主記憶メモリ12に保存され、拡張機能の識別子から対応する鍵データを取得できるようになる。その後の処理、すなわち、図26のステップS810からステップS814までの処理は、図20に示したステップS609からステップS613までの処理と同じである。図27は、第4の実施形態におけるページ遷移時の処理手順のうち、拡張機能の利用証明書リストを保存する処理図9のステップS309に相当を抜き出したものである。第4の実施形態におけるページ遷移時の処理のうち、拡張機能の利用証明書リストを保存する処理以外の処理は、図9に示した第1の実施形態の処理手順と同様である。利用証明書リストの保存処理が開始されると、まず、署名検証部151の証明書解析部151fが、アプリケーション固有データ生成部151bに対してアプリケーション固有データの生成を依頼する。アプリケーション固有データ生成部151bは、アプリケーション固有データを取り出して、証明書解析部151fに返すステップS901。このアプリケーション固有データとしては、例えば、アプリ構成情報に含まれるURLリストのハッシュ値や、偽装や他者がコピー不可能な署名が付いたウェブアプリケーションのアプリケーションIDなどを用いることができる。また、アプリ構成情報をページファイルとは別のコンフィギュレーションファイルとして提供する場合には、そのコンフィギュレーションファイルのURLなどをアプリケーション固有データとして用いることができる。このアプリケーション固有データは、拡張機能の利用証明書がどのウェブアプリケーションに対して発行されたか、不正に別アプリケーションの拡張機能の利用証明書を利用していないか確認するためのデータである。次に、証明書解析部151fは、各拡張機能の利用証明書を検証するために、アプリ構成情報に含まれる利用証明書リストから利用証明書を1件取り出す処理を行い、利用証明書が取り出せたか否かを判定するステップS902。ここで、利用証明書を取り出せなかった場合にはステップS902:No、そのまま処理を終了する。一方、利用証明書を取り出せた場合にはステップS902:Yes、利用証明書のデータからその証明書に対応する拡張機能の識別子を取得するステップS903。さらに証明書解析部151fは、利用証明書の予め定められた部分改ざんされては困る部分であり、図25に示したアプリ構成情報の例では、対応拡張機能識別子や対応セキュリティポリシエレメント識別子のデータを取り出し、正規化部151aに渡してデータの正規化を依頼する。正規化部151aは、証明書解析部151fから渡されたデータに対して正規化処理を行い、その結果を証明書解析部151fに返すステップS904。この際の計算には、暗号化されたハッシュ値データ図25に示した検証データは含まれない。さらに証明書解析部151fは、ステップS901で取り出したアプリケーション固有データとステップS904で正規化されたデータとの結合を行うステップS905。この結合は、データが文字列データの場合は、単純に、ステップS901で取り出したアプリケーション固有データの後に、ステップS904で正規化されたデータを結合すればよい。この結合によって得られるデータが、改ざん検出用の元データとなる。さらに証明書解析部151fは、検証データを生成するためにステップS905で結合したデータをハッシュ計算部151cに渡してハッシュの計算を依頼する。ハッシュ計算部151cは、何らかのハッシュ計算アルゴリズムを用いて、与えられたハッシュ値を計算して証明書解析部151fに返すステップS906。さらに証明書解析部151fは、利用証明書に添付された暗号化されたハッシュ値図25に示した利用証明書検証データを復号するために、鍵保存部151dに拡張機能の識別子を渡し、鍵保存部151dが起動時に保存した拡張機能に対応する鍵データ証明書検証用公開鍵を取得するステップS907。そして、証明書解析部151fは、ステップS907で取得した鍵データと、利用証明書に添付された暗号化されたハッシュ値図25に示した検証データとを復号処理部151gに渡し、復号を依頼する。なお、利用証明書に添付された暗号化されたハッシュ値図25に示した検証データは、拡張機能の作成者が利用証明書の作成時に上記の証明書検証用公開鍵に対応する暗号鍵で暗号化したハッシュ値である。復号処理部151gは、この暗号化されたハッシュ値を、証明書検証用公開鍵を用いて復号し、結果を証明書解析部151fに返すステップS908。証明書解析部151fは、ステップS906で計算されたハッシュ値と、ステップS908で復号されたハッシュ値とを比較し、両者が一致するかどうかを判定するステップS909。そして、両者が一致しない場合ステップS909:No、証明書解析部151fは、利用証明書が改ざんされた、あるいは不正に別のウェブアプリケーション向けの拡張機能の利用証明書を利用していると判断して、エラーの発生を通知するステップS910。一方、両者が一致した場合にはステップS909:Yes、証明書解析部151fは、その拡張機能の利用証明書が正しいと判断する。すなわち、アプリケーション固有データや、証明書データのうちの一部のデータとして何を用いるか、ハッシュ計算のアルゴリズム、暗号化のアルゴリズムとして何を使うかを予め決めておき、拡張機能の作成者は、アプリケーションの作成者に対して拡張機能の利用証明書を発行する際に、これらの決まりに従って、暗号化されたハッシュ値図25の検証データのデータを生成するアプリケーション固有データと証明書データの一部のデータを結合し、結合したデータのハッシュ値を計算し、そのハッシュ値を拡張機能の作成者が持つ暗号鍵で暗号化することで、上記の処理により、拡張機能の利用証明書の不正利用を判定することができる。さらに、証明書有効性検証部151eを設けた場合には、証明書有効性検証部151eに利用証明書データを渡し、利用証明書が有効かどうかの判定を依頼する。証明書有効性検証部151eは、例えば、利用証明書に有効期限のデータが格納されている場合には、現在の日時との比較を行い有効期限の範囲内かどうかを判定するといった方法や、利用証明書のリボークリストを用意する場合には、そのリストのデータから利用証明書が有効であるか判定することといった方法で、利用証明書データの有効性を検証し、結果を証明書解析部151fに返すステップS911。証明書解析部151fは、検証結果を受け取り、利用証明書が有効でない場合にはステップS911:No、ステップS910においてエラーの発生を通知する。一方、利用証明書が有効な場合にはステップS911:Yes、主記憶メモリ12に利用証明書を保存してステップS912、ステップS902に戻る。その後、拡張機能の利用証明書がなくなるまでステップ902以降の処理を繰り返す。その結果、正当な拡張機能の利用証明書のみが主記憶メモリ12に保存されることになる。以上説明したように、第4の実施形態によれば、拡張機能の利用証明書に対する完全性検証を行うようにしているため、拡張機能の不正利用を有効に防止することができる。なお、第4の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。第5の実施形態次に、第5の実施形態について説明する。ウェブアプリケーションにおいては、複数のアプリケーションをタブもしくはウィンドウと呼ばれる実行単位に分けて並列実行することができる。この1つの実行単位のことをコンテキストと呼ぶ。第1乃至第4の実施形態においては、複数のコンテキストを同時に実行する場合、ブラウザ部200や拡張機能アクセス制御部100をコンテキストの数だけ用意する必要がある。これは、いわば複数のブラウザを立ち上げた状態になり、主記憶メモリ12などのリソースの使用効率の悪化を招く。これに対して、第5の実施形態では、実行中のコンテキストを識別する機能を拡張機能アクセス制御部100-5に付加することで、複数のコンテキストを並列実行する場合にも、リソースの重複を最低限にして効率のよい処理を行えるようにしている。図28は、第5の実施形態の情報処理装置10-5内部の機能的な構成を示す機能ブロック図である。図22に示した第4の実施形態の構成と比較すると、拡張機能アクセス制御部100-5のライフサイクル管理部130-5内にコンテキスト判定部137が付加されている点が異なっている。以下、第1乃至第4の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第5の実施形態の特徴部分についてのみ説明する。コンテキスト判定部137は、ページ遷移時や拡張機能の呼出しなどの各イベント発生時に、そのイベントがどのコンテキストで発生したかを判定する。コンテキスト判定部137は、コンテキスト識別子取得命令を受け取り、コンテキストごとに一意の番号や文字列で表現されるコンテキスト識別子を返す。第5の実施形態におけるアプリ範囲管理部135-5は、アプリ構成情報に含まれるURLリストの保存命令、取得命令、消去命令を受け取り、命令に応じた処理をコンテキストごとに行う。すなわち、アプリ範囲管理部135-5は、URLリストの保存命令を受け取った場合には、コンテキスト判定部137からコンテキスト識別子を取得し、呼出し元から渡されたURLリストを、コンテキスト識別子に対応付けて主記憶メモリ12に保存する。また、アプリ範囲管理部135-5は、URLリストの取得命令を受け取った場合には、主記憶メモリ12に保存してあるURLリストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応するURLリストを返す。また、アプリ範囲管理部135-5は、URLリストの消去命令を受け取った場合には、主記憶メモリ12に保存してあるURLリストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応するURLリストを消去する処理を行う。第5の実施形態における拡張機能利用証明書保存部136-5は、利用証明書リストの保存命令、取得命令、消去命令を受け取り、命令に応じた処理をコンテキストごとに行う。すなわち、拡張機能利用証明書保存部136-5は、利用証明書リストの保存命令を受け取った場合には、コンテキスト判定部137からコンテキスト識別子を取得し、呼出し元から渡された利用証明書リストを、コンテキスト識別子に対応付けて主記憶メモリ12に保存する。また、拡張機能利用証明書保存部136-5は、利用証明書リストの取得命令を受け取った場合には、主記憶メモリ12に保存してある利用証明書リストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応する利用証明書リストを返す。また、拡張機能利用証明書保存部136-5は、利用証明書リストの消去命令を受け取った場合には、主記憶メモリ12に保存してある利用証明書リストのうち、コンテキスト判定部137から取得したコンテキスト識別子に対応する利用証明書リストを消去する処理を行う。以上のように、第5の実施形態の情報処理装置10-5はコンテキスト判定部137を備え、アプリ範囲管理部135-5と拡張機能利用証明書保存部136-5が、コンテキスト判定部137と連携してコンテキストごとにアプリ構成情報のURLリストや利用証明書リストを管理するようにしている。図29は、第5の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、ステップS1006、ステップS1008、ステップS1010、ステップS1012、ステップS1014、ステップS1018、およびステップS1020でコンテキストを取得する処理が加わっている点が異なっている。図29のステップS1001からステップS1005までの処理は、図9に示したステップS301からステップS305までの処理と同じである。第5の実施形態では、遷移先ページのページファイルにアプリ構成情報が含まれていると判定されステップS1004:Yes、アプリ設定ロード処理が開始されるとステップS1005、アプリ設定ロード部133が、イベントが発生したコンテキストで今まで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135-5に対してURLリストの削除命令を出す。アプリ範囲管理部135-5は、アプリ設定ロード部133からのURLリストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1006、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストを削除する処理を行うステップS1007。次に、アプリ設定ロード部133は、拡張機能利用証明書保存部136-5に対して利用証明書リストの削除命令を出す。拡張機能利用証明書保存部136-5は、アプリ設定ロード部133からの利用証明書リストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1008、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを削除する処理を行うステップS1009。また、アプリ設定ロード部133は、イベントが発生したコンテキストで新たに実行するウェブアプリケーションに対応するアプリ構成情報を保存するために、アプリ範囲管理部135-5に対してURLリストの保存命令を出す。アプリ範囲管理部135-5は、アプリ設定ロード部133からのURLリストの保存命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1010、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に、新たなウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストを保存する処理を行うステップS1011。次に、アプリ設定ロード部133は、拡張機能利用証明書保存部136-5に対して利用証明書リストの保存命令を出す。拡張機能利用証明書保存部136-5は、アプリ設定ロード部133からの利用証明書リストの保存命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1012、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に、新たなウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを保存する処理を行うステップS1013。これにより、新たなウェブアプリケーションに対応したアプリ構成情報に含まれるURLリストおよび利用証明書リストが主記憶メモリ12に保存される。一方、遷移先ページのページファイルにアプリ構成情報が含まれていない場合ステップS1004:No、ページ種別振分け部132は、現在実行中のウェブアプリケーションが継続実行、実行終了のいずれかであると判断し、そのどちらかであるかを判断するためにアプリ終了判定部134を呼び出して、遷移先ページのURLを渡す。アプリ終了判定部134は、ページ種別振分け部132から遷移先ページのURLを取得すると、まず、アプリ範囲管理部135-5に対してURLリストの取得命令を出す。アプリ範囲管理部135-5は、アプリ終了判定部134からのURLリストの取得命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1014、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域に保存されているURLリストを取得する処理を行って、取得したURLリストをアプリ終了判定部134に返すステップS1015。このとき、アプリ終了判定部134は、アプリ範囲管理部135-5が取得したURLリストの有無を判定しステップS1016、アプリ範囲管理部135-5が取得したURLリストがなければステップS1016:No、そのまま処理を終了する。一方、アプリ範囲管理部135-5が取得したURLリストがあればステップS1016:Yes、ページ種別振分け部132から取得した遷移先ページのURLがそのURLリストに含まれているか否かを判定するステップS1017。そして、遷移先ページのURLがURLリストに含まれている場合ステップS1017:Yes、アプリ終了判定部134は、同一のウェブアプリケーションの実行が継続されているものと判断し、そのまま処理を終了する。一方、遷移先ページのURLがURLリストに含まれていない場合ステップS1017:No、アプリ終了判定部134は、それまで実行していたウェブアプリケーションが終了したものと判断し、それまで実行していたウェブアプリケーションに対応するアプリ構成情報を削除するために、アプリ範囲管理部135-5に対してURLリストの削除命令を出す。アプリ範囲管理部135-5は、アプリ終了判定部134からのURLリストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1018、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれるURLリストを削除する処理を行うステップS1019。次に、アプリ終了判定部134は、拡張機能利用証明書保存部136-5に対して利用証明書リストの削除命令を出す。拡張機能利用証明書保存部136-5は、アプリ設定ロード部133からの利用証明書リストの削除命令に応じて、コンテキスト判定部137からページ遷移が起きたコンテキストの識別子を取得しステップS1020、取得した識別子に対応するコンテキストについて、実行していたウェブアプリケーションに対応するアプリ構成情報に含まれる利用証明書リストを削除する処理を行うステップS1021。図30は、第5の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図21に示した第3の実施形態の処理手順と比較すると、ステップS1104で取得した拡張機能識別子のリストの中に、呼出し要求のあった拡張機能の識別子があると判定された場合にステップS1105:Yes、拡張機能の呼出しが起きたコンテキストが持つ拡張機能の利用証明書を元に拡張機能のアクセス制御を行う処理が加わっている点が異なる。図30のステップS1101からステップS1106までの処理は、図21に示したステップS701からステップS706までの処理と同じである。第5の実施形態では、呼出し要求のあった拡張機能の識別子がリストの中に存在する場合ステップS1105:Yes、拡張機能呼出し可否判定部122は、拡張機能利用証明書保存部136-5に対して利用証明書リストの取得命令を出す。拡張機能利用証明書保存部136-5は、拡張機能呼出し可否判定部122からの利用証明書リストの取得命令に応じて、コンテキスト判定部137から拡張機能の呼出し要求があったコンテキストの識別子を取得しステップS1107、主記憶メモリ12のコンテキストごとに確保された領域のうち、取得した識別子に対応するコンテキストの領域から利用証明書リストを取得して、拡張機能呼出し可否判定部122に返すステップS1108。その後の処理、すなわち、図30のステップS1109からステップS1115までの処理は、図21に示したステップS708からステップS714までの処理と同じである。これにより、コンテキストで実行中のウェブアプリケーションごとに、利用証明書の使い分けが可能になる。図31は、コンテキスト判定部137によるコンテキスト識別子の取得時の処理手順を示すフローチャートである。コンテキスト判定部137は、コンテキスト識別子の取得要求が来た場合、まず発生したイベントの種別を取得するステップS1201。このイベントには、ページ遷移と、拡張機能へのアクセスとが存在する。そこで、コンテキスト判定部137は、ステップS1201で取得したイベントの種別から、発生したイベントが拡張機能へのアクセスか否かを判定するステップS1202。ここで、発生したイベントが拡張機能へのアクセスではない、つまりページ遷移である場合はステップS1202:No、コンテキスト判定部137は、イベントが発生したコンテキストのコンテキスト識別子を取得するステップS1203。一方、拡張機能はオブジェクトという形でコンテキストに紐付けされるが、発生したイベントが拡張機能へのアクセスである場合はステップS1202:Yes、コンテキスト判定部137は、拡張機能のオブジェクトが存在するコンテキスト識別子ではなく、拡張機能のアクセス命令を発行したコンテキストの識別子を取得するステップS1204。もちろんオブジェクトが存在するコンテキスト識別子とアクセス命令を発行したコンテキストの識別子が一致してもよい。最後に、コンテキスト判定部137の呼出し元に対して、取得したコンテキスト識別子を返してステップS1205、処理が終了する。拡張機能はオブジェクトで管理され、別コンテキストで実行しているウェブアプリケーションから別コンテキストの拡張機能を参照して間接的に拡張機能を呼出すことが可能である。第5の実施形態のコンテキスト判定部137は、拡張機能へのアクセス時には、拡張機能のオブジェクトが存在するコンテキストではなく、拡張機能のオブジェクトへのアクセスを行ったコンテキストを判定する。これにより、拡張機能の利用証明書を持つウェブアプリケーションの拡張機能が、拡張機能の利用証明書を持たないウェブアプリケーションのコンテキストから間接的に不正利用されることを有効に防止することが可能となる。さらに、第5の実施形態において、第4の実施形態で説明したセキュリティポリシ管理部113や署名検証部151と連携してセキュリティポリシの分離や利用証明書の安全性検証を行う場合には、利用証明書の保存処理において図27のフローチャートで示した処理を行い、起動時の処理として図26のフローチャートで示した処理を行うようにすればよい。以上説明したように、第5の実施形態によれば、拡張機能アクセス制御部100-5のライフサイクル管理部130-5内にコンテキスト判定部137を付加するのみで、複数のウェブアプリケーションの並列実行を効率的に行うことが可能になる。主記憶メモリ12についても、URLリストおよび利用証明書リストの格納領域をコンテキスト数に応じて増やすだけで、複数のウェブアプリケーションの並列実行が可能になるため、利用効率がよい。ウェブアプリケーションでは、並列実行しているコンテキスト間のオブジェクトの相互アクセスも可能である。拡張機能もオブジェクトで管理されるため、別コンテキストで実行しているウェブアプリケーションから間接的に拡張機能を呼出すことが可能である。第5の実施形態におけるコンテキスト判定部137は、拡張機能へのアクセス時には、拡張機能のオブジェクトが存在するコンテキストではなく、拡張機能のオブジェクトへアクセスを行ったコンテキストを判定する。これにより、拡張機能の利用証明書を持たないウェブアプリケーションから拡張機能の利用証明書を持つウェブアプリケーションの拡張機能のオブジェクトが不正利用されることを防ぐことが可能となる。また、コンテキスト間のオブジェクトアクセスによる拡張機能の不正アクセスについても防止することが可能である。なお、第5の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。第6の実施形態次に、第6の実施形態について説明する。第1乃至第5の実施形態では、アプリ構成情報を含むページファイルへのアクセスをもってウェブアプリケーション起動と判定していた。これに対して、第6の実施形態では、ウェブアプリケーションの起動に専用命令を用いるようにしている。これにより、ページ遷移時の処理が単純になり、処理負荷の軽減を図ることが可能となる。図32は、第6の実施形態の情報処理装置10-6内部の機能的な構成を示す機能ブロック図である。図28に示した第5の実施形態の構成と比較すると、拡張機能アクセス制御部100-6のライフサイクル管理部130-6内に、ページ種別振分け部132に代えて起動命令検出部138が設けられている点が異なっている。以下、第1乃至第5の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第6の実施形態の特徴部分についてのみ説明する。第6の実施形態のブラウザ部200-6のアプリケーション実行部210-6は、ページ遷移時にページ遷移検出部131-6を呼び出す機能に加え、アプリ起動命令の実行時に、起動命令の引数として設定されたウェブアプリケーションの識別情報を渡して起動命令検出部138を呼出す機能を有する。このウェブアプリケーションの識別情報としては、例えば、アプリ構成情報が含まれるページファイルウェブアプリケーションで最初に実行されるページファイルのURLを用いればよい。また、アプリ構成情報をページファイルとは別のコンフィギュレーションファイルとして提供する場合は、コンフィギュレーションファイルのURLを用いればよい。起動命令検出部138は、アプリケーション実行部210-6から渡されたウェブアプリケーションの識別情報を元に、アプリ構成情報を含むページファイルのダウンロードを行い、アプリ構成情報を取得する。さらに、起動命令検出部138は、アプリ設定ロード部133に対して取得したアプリ構成情報を渡し、アプリ構成情報に含まれるURLリストや利用証明書リストの読み込み依頼を出す。第6の実施形態のページ遷移検出部131-6は、アプリケーション実行部210-6から渡されたページファイルのURLなどの識別情報をアプリ終了判定部134に渡して、ウェブアプリケーションが実行継続か、実行終了かの判定依頼を出す。第1乃至第5の実施形態では、さらにページ種別振分け部132が、遷移先ページのページファイルのURLがアプリ構成情報のURLリストに含まれるかの判断を行っていたが、第6の実施形態においてはその処理は必要ない。図33は、第6の実施形態におけるウェブアプリケーション起動時の処理手順を示すフローチャートである。第6の実施形態では、アプリ起動命令を実行することでウェブアプリケーションが起動する。まず、アプリケーション実行部210-6が、アプリ構成情報を更新するために、起動命令検出部138にアプリ起動命令を出す。この際、アプリ起動命令の引数として指定されるページファイルのURLなどのウェブアプリケーションの識別情報を渡すステップS1301。次に、起動命令検出部138が、アプリケーション実行部210-6から渡されたウェブアプリケーションの識別情報を元に、対応するウェブアプリケーションのアプリ構成情報を含むページファイルをダウンロードするステップS1302。なお、アプリ構成情報を含むページファイルとは別のコンフィギュレーションファイルとして提供する場合は、起動命令検出部138は、このコンフィギュレーションファイルをダウンロードする。次に、起動命令検出部138は、ダウンロードしたページファイルの中からアプリ構成情報を取り出し、アプリ構成情報を保存するために、アプリ設定ロード部133に渡す。これにより、アプリ設定ロード処理が開始されステップS1303、それまで実行していたウェブアプリケーションに対応するURLリストおよび利用証明書リストの削除ステップS1304、ステップS1305と、新たに実行されるウェブアプリケーションに対応するURLリストおよび利用証明書リストの保存ステップS1306、ステップS1307が行われる。図34は、第6の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、図9のステップS303からステップS309に相当する処理は行わず、ステップS1403の処理が加わっている点が異なっている。図34のステップS1401、ステップS1402の処理は、図9に示したステップS301、ステップS302の処理と同じである。第6の実施形態では、上述したように、ウェブアプリケーションの起動には専用のアプリ起動命令を用いるため、ページ遷移時にウェブアプリケーションの開始かどうかを判定する必要がない。したがって、ページ遷移検出部131-6は、遷移先ページのURLを取得した後、ページ種別振分け部132を呼出すのではなく、アプリ終了判定部134を直接呼出すステップS1403。その後の処理、すなわち、図34のステップS1404からステップS1408までの処理は、図9に示したステップS310からステップS314までの処理と同じである。以上説明したように、第6の実施形態によれば、ウェブアプリケーションの起動に専用のアプリ起動命令を用いるようにしているので、ページ遷移時の処理が単純になり、処理負荷が軽減される。したがって、本実施形態は、リソースが限られる環境にも適用することができる。なお、第6の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。第7の実施形態次に、第7の実施形態について説明する。第1乃至第6の実施形態では、ウェブアプリケーションを構成する複数のページファイルやメディアファイルがパッケージングされずに、独立してサーバ装置20に格納されている場合を想定していた。このようにページファイルやメディアファイルを独立させる構成では、ウェブアプリケーションのアップデートやページファイルを動的に生成する場合などにおいて自由度が高くなる一方で、ウェブアプリケーションのデータを一括して配布し、端末にインストールして利用するような場合に手間がかかる。このため、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部を1つのアーカイブファイルにパッケージングしてサーバ装置20に格納しておくことも想定される。第7の実施形態は、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が1つのアーカイブファイルにパッケージングされている場合に対応できるようにしたものである。図35は、第7の実施形態の情報処理装置10-7内部の機能的な構成を示す機能ブロック図である。図28に示した第5の実施形態の構成と比較すると、拡張機能アクセス制御部100-7のライフサイクル管理部130-7内にアプリ展開部139およびコンフィグ生成部140が付加されている点が異なっている。以下、第1乃至第6の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第7の実施形態の特徴部分についてのみ説明する。アプリ展開部139は、複数のファイルがパッケージングされたアーカイブファイルのデータを受け取り、アーカイブファイルを複数のファイルの状態に展開してストレージ13もしくは主記憶メモリ12に格納する。また、アプリ展開部139は、展開したアーカイブファイルの中に格納されているページファイルアプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合はコンフィギュレーションファイルに含まれるアプリ構成情報を読み取り、その内容を渡してコンフィグ生成部140を呼出し、コンフィグ生成部140に対してアプリ構成情報の動的な生成を依頼する。アーカイブファイルの方式としては、例えばzip形式など一般に知られた方式を使えばよい。コンフィグ生成部140は、アプリ展開部139が展開したファイルの中から特定ファイル名例:index.htmlが付けられたページファイルに含まれるアプリ構成情報を読み取る。また、コンフィグ生成部140は、アプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合は、アプリ展開部139が展開したファイルの中から特定ファイル名例:configuration.datが付けられたコンフィギュレーションファイルの内容を読み取る。さらに、コンフィグ生成部140は、アーカイブファイルに含まれるページファイルを列挙してURLリストを動的に生成し、アプリ範囲情報と結合する。ウェブアプリケーションがアーカイブファイルに含まれるページファイルのみから構成される場合には、アプリ構成情報にURLリストを含める必要はない。これは、1つのアーカイブファイルにパッケージングされているページファイルは、同一のウェブアプリケーションのファイルであることは明白なためである。一方で、アーカイブファイルに含まれないページファイルが、同じセキュリティポリシを適用するウェブアプリケーションの一部となる場合には、アプリ構成情報には、アーカイブファイルに含まれないページファイルのURLと、利用証明書リストとが含まれる。このため、コンフィグ生成部140は、アーカイブファイルに含まれるページファイルを列挙して動的に生成したURLリストをアプリ範囲情報と結合することで、アーカイブファイルに含まれないページファイルも含めて、1つのウェブアプリケーションの範囲を表すURLリストを生成する。第7の実施形態におけるページ種別振分け部132-7は、第1の実施形態におけるページ種別振分け部132の機能に加えて、遷移先ページファイルのMIMEタイプや遷移先ページファイルの拡張子からそのファイルがアーカイブファイルであるかどうか判定する機能を持つ。さらにページ種別振分け部132-7は、遷移先ファイルがアーカイブファイルである場合には、アプリ展開部139にファイルのデータを渡し、パッケージングされたアーカイブファイルの展開を依頼する。さらにページ種別振分け部132-7は、コンフィグ生成部140で動的に生成されたURLリストが結合されたアプリ構成情報をアプリ展開部139から受け取り、アプリ設定ロード部133に対してアプリ構成情報の保存を依頼する。第7の実施形態におけるアプリ終了判定部134-7は、第1の実施形態におけるアプリ終了判定部134の機能に加えて、ウェブアプリケーションの終了時に、アプリ展開部139が展開したデータを削除する機能を持つ。図36は、第7の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、ページ種別振分け部132-7の呼出しステップS1503の後に、遷移先ページのファイルがアーカイブファイルか否かを判定する処理ステップS1504と、遷移先ページのファイルがアーカイブファイルの場合に、アーカイブファイルを展開してからウェブアプリケーションを実行するための処理ステップS1516~ステップS1519が加わっている点が異なる。図36のステップS1501からステップS1503までの処理は、図9に示したステップS301からステップS303までの処理と同じである。第7の実施形態では、ページ種別振分け部132-7が、ページ遷移検出部131から遷移先ページのURLを受け取ると、まず、遷移先ページのファイルのMIMEタイプや拡張子から、そのファイルがアーカイブファイルであるかどうかを判定するステップS1504。遷移先ページのファイルがアーカイブファイルでない場合にはステップS1504:No、遷移先ページのページファイルにアプリ構成情報が含まれるか否かの判定ステップS1505に移り、その後のステップS1506からステップS1515において、第1の実施形態と同様の処理、すなわち、図9に示したステップS305からステップS314までと同じ処理を行う。一方、遷移先ページのファイルがアーカイブファイルである場合にはステップS1504:Yes、ページ種別振分け部132-7は、アーカイブファイル内に格納されたウェブアプリケーションの実行を開始するために、アーカイブファイルのデータをアプリ展開部139に渡して、アーカイブファイルの展開を依頼する。そして、アプリ展開部139は、ページ種別振分け部132-7から受け取ったアーカイブファイルを複数のファイルの状態に展開してストレージ13もしくは主記憶メモリ12に格納するステップS1516。その後、アプリ展開部139は、展開を行ったファイルの中からウェブアプリケーションで最初に実行するページファイルアプリ構成情報が独立のコンフィギュレーションファイルとして提供される場合はコンフィギュレーションファイルを探し、そのページファイルに含まれるアプリ構成情報を読み込んで、ページ種別振分け部132-7に返すステップS1517。ここでページファイルから読み込まれたアプリ構成情報には、アーカイブファイルに含まれないウェブアプリケーションを構成するページファイルのURLや利用証明書リストが含まれる。ただし、このアプリ構成情報には、アーカイブファイルにパッケージングされたページファイルのURLは含まれないため、アーカイブファイルにパッケージングされたページファイルを含めたアプリ範囲情報を生成する必要がある。そこで、ページ遷移振分け部132-7は、コンフィグ生成部140にステップS1517で読み込まれたアプリ構成情報を渡して、アプリ構成情報の生成を依頼する。コンフィグ生成部140は、まず、アーカイブファイルに含まれるページファイルを列挙して、アーカイブファイルに含まれる各ページファイルのURLを取得するステップS1518。そして、コンフィグ生成部140は、ページ種別振分け部132-7から渡されたアプリ構成情報と、ステップS1518で取得した各ページファイルのURLを結合して、ウェブアプリケーションに対応するアプリ構成情報を生成して、ページ種別振分け部132-7に返すステップS1519。その後、ページ種別振分け部132-7は、コンフィグ生成部140が生成したアプリ構成情報をアプリ設定ロード部133に渡して、アプリ設定ロード処理を依頼する。そして、アプリ設定ロード部133は、ステップS1506からステップS1510において、第1の実施形態と同様の処理、すなわち、図9のステップS305からステップS309までの処理と同じ処理を行う。以上説明したように、第7の実施形態によれば、遷移先ページがアーカイブファイルにパッケージングされている場合に、アプリ展開部139がアーカイブファイルを展開し、コンフィグ生成部140がアーカイブファイルに含まれるページファイルのURLとアプリ構成情報とを結合して、ウェブアプリケーションに対応するアプリ構成情報を生成する。したがって、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部もしくは全部が1つのアーカイブファイルにパッケージングされていたとしても、自動的にウェブアプリケーションの開始処理を行うことができる。また、ウェブアプリケーションを構成する複数のページファイルやメディアファイルの一部のみをアーカイブファイルとしてパッケージングし、動的に変更する部分はアーカイブしないようにすることもでき、ウェブアプリケーションを構成するページファイルの提供の形態によらず、ウェブアプリケーションにおいて同じセキュリティポリシで拡張機能のアクセス制御を行えるようになるため、ウェブアプリケーションの開発の幅を広げることが可能となる。なお、第7の実施形態では、第1の実施形態と同様に、アプリ構成情報がページファイルに含まれるものとして説明したが、第2の実施形態と同様に、アプリ構成情報をコンフィギュレーションファイルとして、通常のページファイルとは独立した別のファイルで提供するようにしてもよい。第8の実施形態次に、第8の実施形態について説明する。第1乃至第7の実施形態では、ウェブアプリケーションごとのアプリ構成情報に拡張機能の利用証明書が付属していた。これに対して、第8の実施形態では、アプリ構成情報に拡張機能の利用証明書は付属せず、拡張機能のセキュリティポリシのみからアクセス制御を行う。これにより、ウェブアプリケーションの作成者がウェブアプリケーションを開発する際に利用証明書を添付する手間を減らすことが可能になる。図37は、第8の実施形態の情報処理装置10-8内部の機能的な構成を示す機能ブロック図である。図15に示した第3の実施形態の構成と比較すると、拡張機能アクセス制御部100-8のライフサイクル管理部130-8内に、拡張機能利用証明書保存部136に代えてアプリケーション固有データ生成部141が設けられている点が異なっている。以下、第1乃至第7の実施形態と共通の部分は同一の符号を付して重複した説明を省略し、第8の実施形態の特徴部分についてのみ説明する。アプリケーション固有データ生成部141は、アクセス制御実行部120-8内の拡張機能呼出し可否判定部122-8からの依頼に応じて、アプリ構成情報が格納されたページファイルのURLなど、アプリケーション作成者による偽装が不可能なアプリケーション固有データを生成する。第8の実施形態における拡張機能管理部110-8内のセキュリティポリシ管理部113-8は、図38に示すようなセキュリティポリシの管理を行う。図38は、第8の実施形態においてセキュリティポリシ管理部113-8によりロードされるセキュリティポリシのデータ構造の一例を示す図である。図17-1に示したセキュリティポリシのデータ構造と比較すると、個々のセキュリティポリシエレメントの適用対象となるウェブアプリケーションのアプリケーション固有データを含む点が異なっている。一つのセキュリティポリシエレメントに複数の対象アプリケーションの固有データを含んでいてもよい。第8の実施形態におけるセキュリティポリシ管理部113-8は、第3の実施形態におけるセキュリティポリシ管理部113と同じく、拡張機能の識別子を受信して対応する拡張機能のセキュリティポリシを主記憶メモリ12にロードする機能を持つ。さらに、第8の実施形態におけるセキュリティポリシ管理部113-8は、アプリケーション固有データを受けて、対応するセキュリティポリシエレメントを返す機能を有する。図39は、第8の実施形態における拡張機能呼出し時の処理手順を示すフローチャートである。図21に示した第3の実施形態の処理手順と比較すると、呼出し要求のあった拡張機能があると判定された後にステップS1605:Yes、アプリケーション固有データを取得するとともに、セキュリティポリシ管理部113-8が管理するセキュリティポリシから対応するセキュリティポリシエレメントを取得する処理ステップS1607、ステップS1608が加わり、対応する利用証明書があるかどうかを判定する処理がない点が異なる。図39のステップS1601からステップS1606までの処理は、図21に示したステップS701からステップS706までの処理と同じである。第8の実施形態では、呼出し要求のあった拡張機能があると判定されるとステップS1605:Yes、拡張機能呼出し可否判定部122-8が、呼出し要求のあった拡張機能をウェブアプリケーションで利用することが許可されているかどうかを判定するために、アプリケーション固有データ生成部141に対して、アプリケーション固有データの取得を依頼する。アプリケーション固有データ生成部141は、現在実行中のウェブアプリケーションのアプリケーション固有データ、例えばアプリ構成情報が格納されたページファイルのURLなどを取得して、拡張機能呼出し可否判定部122-8に返すステップS1607。次に、拡張機能呼出し可否判定部122-8は、セキュリティポリシ管理部113-8に対して、アプリケーション固有データ生成部141から取得したアプリケーション固有データに対応するセキュリティポリシエレメントの取得を依頼する。セキュリティポリシ管理部113-8は、起動時にロードしたセキュリティポリシの中から、アプリケーション固有データ生成部141から取得したアプリケーション固有データに対応するセキュリティポリシエレメントを取得して拡張機能呼出し可否判定部122-8に返すステップS1608。次に、拡張機能呼出し可否判定部122-8は、呼び出す関数がセキュリティポリシエレメントに含まれるかどうかにより、呼出し要求があった拡張機能の呼出しが許可されているか否かを判定するステップS1609。その後の処理、すなわち、図39のステップS1610からステップS1612までの処理は、図21に示したステップS712からステップS713までの処理と同じである。図40は、第8の実施形態におけるページ遷移時の処理手順を示すフローチャートである。図9に示した第1の実施形態の処理手順と比較すると、アプリケーション固有データを生成する処理ステップS1708やアプリケーション固有データを削除する処理ステップS1713が加わり、利用証明書リストを削除する処理ステップS307、ステップS314や利用証明書リストを保存する処理ステップS309がない点が異なる。図40のステップS1701からステップS1707までの処理は、図9に示したステップS301からステップS308ステップS307は除くまでの処理と同じである。また、図40のステップS1709からステップS1712までの処理は、図9に示したステップS310からステップS313までの処理と同じである。第8の実施形態では、ウェブアプリケーション終了時に、アプリ設定ロード部133-8がアプリケーション固有データ生成部141を呼出し、それまで実行していたウェブアプリケーションに対応するアプリケーション固有データの削除処理を行うステップS1713。また、アプリケーションの開始時には、アプリ設定ロード部133-8がアプリケーション固有データ生成部141を呼出し、アプリケーション固有のデータの生成と保存を依頼するステップS1708。以上説明したように、第8の実施形態によれば、アプリ構成情報に拡張機能の利用証明書は付属せず、セキュリティポリシのみから拡張機能のアクセス制御を行うようにしているので、ウェブアプリケーションの作成者はウェブアプリケーションを開発する際に利用証明書を添付する必要はなく、ウェブアプリケーションの作成者の負担を軽減することができる。また、セキュリティポリシデータは拡張機能に付属するため、ウェブアプリケーションの作成者による改ざんなどの心配がない。すなわち、ウェブアプリケーションから拡張機能の不正利用を防ぎたい場合にも、第4の実施形態で説明したような拡張機能の利用証明書の検証処理を行うことなく、拡張機能の不正利用を有効に防止することが可能となる。以上説明したとおり、第1乃至第8の実施形態によれば、ウェブアプリケーション単位で利用を許可する拡張機能を限定することができる。第1乃至第8の実施形態の情報処理装置10~10-8において、拡張機能アクセス制御部100~100-8による上述した各機能は、情報処理装置10~10-8のCPU11がストレージ13に格納された拡張機能アクセス制御プログラムを実行することにより実現できる。情報処理装置10~10-8のCPU11が実行する拡張機能アクセス制御プログラムは、例えば、インストール可能な形式又は実行可能な形式のファイルでCD-ROMCompactDiskReadOnlyMemory、フレキシブルディスクFD、CD-RCompactDiskRecordable、DVDDigitalVersatileDiscなどのコンピュータで読み取り可能な記録媒体に記録されてコンピュータプログラムプロダクトとして提供される。また、情報処理装置10~10-8のCPU11が実行する拡張機能アクセス制御プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、情報処理装置10~10-8のCPU11が実行する拡張機能アクセス制御プログラムを、インターネットなどのネットワーク経由で提供または配布するように構成してもよい。また、情報処理装置10~10-8のCPU11が実行する拡張機能アクセス制御プログラムを、情報処理装置10~10-8のストレージ13に予め組み込んで提供するように構成してもよい。情報処理装置10~10-8のCPU11が実行する拡張機能アクセス制御プログラムは、拡張機能アクセス制御部100~100-8の各処理部拡張機能管理部110~110-8、アクセス制御実行部120~120-8およびライフサイクル管理部130~130-8などを含むモジュール構成となっており、実際のハードウェアとしては、例えば、CPU11プロセッサがストレージ13から拡張機能アクセス制御プログラムを主記憶メモリ12に読み出して実行することにより、上記各部が主記憶メモリ12上にロードされ、上述した各部が主記憶メモリ12上に生成されるようになっている。以上、本発明の実施形態を説明したが、ここで説明した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。ここで説明した新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここで説明した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。"