(57)【特許請求の範囲】
【請求項１】
ブラウザエンジンと、
前記ブラウザエンジンで実行されるアプリケーションを格納するための格納部と、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示する指示部と、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する提供部と
を有し、
前記仮想ＵＲＬは、オリジンを含んでおり、
前記ブラウザエンジンに実行されるアプリケーションが使用するローカルストレージは、当該アプリケーションに対する仮想ＵＲＬに含まれるオリジンに対して割り当てられる
情報処理装置。
【請求項２】
前記ブラウザエンジンと、前記格納部と、前記指示部と、前記提供部とを含む、前記アプリケーションの実行環境を複数有する
請求項１記載の情報処理装置。
【請求項３】
前記指示部は、前記アプリケーションの配信元である、所定の外部リソースのＵＲＬを、前記仮想ＵＲＬとして用いる
請求項１又は２記載の情報処理装置。
【請求項４】
前記指示部は、前記アプリケーションに付加されているグループ識別データに基づき、同一のグループに属するアプリケーションについて、共通のオリジンに該当する仮想ＵＲＬを用いる
請求項１又は２記載の情報処理装置。
【請求項５】
ブラウザエンジンと、前記ブラウザエンジンで実行されるアプリケーションを格納するための格納部とを有する情報処理装置により実行され、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示し、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する
処理を含み、
前記仮想ＵＲＬは、オリジンを含んでおり、
前記ブラウザエンジンに実行されるアプリケーションが使用するローカルストレージは、当該アプリケーションに対する仮想ＵＲＬに含まれるオリジンに対して割り当てられる
情報処理方法。
【請求項６】
ブラウザエンジンと、前記ブラウザエンジンで実行されるアプリケーションを格納するための格納部とを有するコンピュータに、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示し、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する
処理を実行させ、
前記仮想ＵＲＬは、オリジンを含んでおり、
前記ブラウザエンジンに実行されるアプリケーションが使用するローカルストレージは、当該アプリケーションに対する仮想ＵＲＬに含まれるオリジンに対して割り当てられる
情報処理プログラム。
【請求項７】
配信サーバと情報処理装置とを含む情報配信システムであって、
前記配信サーバは、所定の外部リソースのＵＲＬが付加されているアプリケーションを配信し、
前記情報処理装置は、
前記アプリケーションを実行するブラウザエンジンと、
前記アプリケーションを取得する取得部と、
前記アプリケーションを格納するための格納部と、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示する指示部と、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する提供部と
を有し、
前記指示部は、前記所定の外部リソースのＵＲＬを、前記仮想ＵＲＬとして用い、
前記仮想ＵＲＬは、オリジンを含んでおり、
前記ブラウザエンジンに実行されるアプリケーションが使用するローカルストレージは、当該アプリケーションに対する仮想ＵＲＬに含まれるオリジンに対して割り当てられる
情報配信システム。
【請求項８】
配信サーバと情報処理装置とを含む情報配信システムであって、
前記配信サーバは、アプリケーションが属するグループの識別データが付加されている当該アプリケーションを配信し、
前記情報処理装置は、
前記アプリケーションを実行するブラウザエンジンと、
前記アプリケーションを取得する取得部と、
前記アプリケーションを格納するための格納部と、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示する指示部と、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する提供部と
を有し、
前記指示部は、前記識別データに基づき、同一のグループに属するアプリケーションについて、共通のオリジンに該当する仮想ＵＲＬを用いる
情報配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションをブラウザエンジンで実行させる技術に関する。
【背景技術】
【０００２】
ブラウザエンジンで実行されるＨＴＭＬ（HyperText Markup Language）５アプリケーションが使用するローカルストレージは、当該ＨＴＭＬ５アプリケーションのオリジン毎に設けられる。オリジンとは、ＵＲＬ（Uniform Resource Locator）に含まれるスキーム、ホスト及びポートの組み合わせのことである。例えば、ブラウザエンジンから配信サーバにアクセスして複数のＨＴＭＬ５アプリケーションを実行する態様の場合、提供元の配信サーバがそれぞれ異なれば、各ＨＴＭＬ５アプリケーションが使用するローカルストレージは別個に設けられる。
【０００３】
図１に示した例で、ブラウザエンジン１１１は、インターネットを介して配信サーバ１０３ａにアクセスし、ＨＴＭＬ５アプリケーション１１３ａをロードする。このとき、ブラウザエンジン１１１から配信サーバ１０３ａへＵＲＬ「ｈｔｔｐ：／／ａｐｌｓｔｏｒｅ１．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」が設定されたＨＴＴＰ（Hypertext Transfer Protocol）リクエストが送られる。また、ブラウザエンジン１１１は、インターネットを介して配信サーバ１０３ｂにアクセスし、ＨＴＭＬ５アプリケーション１１３ｂをロードする。このとき、ブラウザエンジン１１１から配信サーバ１０３ｂへＵＲＬ「ｈｔｔｐ：／／ａｐｌｓｔｏｒｅ２．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」が設定されたＨＴＴＰリクエストが送られる。
【０００４】
ＨＴＭＬ５アプリケーション１１３ａのオリジンは、「ｈｔｔｐ：／／ａｐｌｓｔｏｒｅ１．ｃｏｍ／」であり、ＨＴＭＬ５アプリケーション１１３ｂのオリジンは、「ｈｔｔｐ：／／ａｐｌｓｔｏｒｅ２．ｃｏｍ／」であり、両者は一致しない。従って、ＨＴＭＬ５アプリケーション１１３ａが使用するローカルストレージ１１５ａと、ＨＴＭＬ５アプリケーション１１３ｂが使用するローカルストレージ１１５ｂとは別個に設けられる。
【０００５】
尚、ＨＴＭＬ５アプリケーション１１３ａ、ＨＴＭＬ５アプリケーション１１３ｂ、ローカルストレージ１１５ａ及びローカルストレージ１１５ｂは、ブラウザエンジン１１１の管理範囲１１７に含まれる。
【０００６】
別の態様として、一旦内部に保持される状態となったＨＴＭＬ５アプリケーション１１３をブラウザエンジン１１１で動作させる場合には、ＨＴＭＬ５アプリケーション１１３のオリジンは、例えば「ｆｉｌｅ：／／／」のように、提供元のＷｅｂサイトに関らず同じになる。その結果、異なる配信サーバ１０３から提供されたＨＴＭＬ５アプリケーション１１３であっても、同じローカルストレージ１１５を使用することになる。
【０００７】
図２に示した例で、取得部２０１は、ＨＴＭＬ５アプリケーション１１３ａを含むアプリケーションパッケージ２０３ａを配信サーバ１０３ａから取得し、ユーザ端末１０１は、内部にＨＴＭＬ５アプリケーション１１３ａを保持する状態となる。また、取得部２０１は、ＨＴＭＬ５アプリケーション１１３ｂを含むアプリケーションパッケージ２０３ｂを配信サーバ１０３ｂから取得し、ユーザ端末１０１は、内部にＨＴＭＬ５アプリケーション１１３ｂを保持する状態となる。アプリケーションパッケージ２０３は、当該ＨＴＭＬ５アプリケーション１１３の実行に用いられるファイルやメタデータを含むパッケージである。ユーザ端末１０１は、例えばスマートフォンである。
【０００８】
そして、ブラウザエンジン１１１は、内部的にアプリケーションパッケージ２０３ａからＨＴＭＬ５アプリケーション１１３ａをロードする。このときのリクエストには、ＵＲＬ「ｆｉｌｅ：／／／ｄａｔａ／ａｐｐｓ／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」が設定されている。また、ブラウザエンジン１１１は、内部的にアプリケーションパッケージ２０３ｂからＨＴＭＬ５アプリケーション１１３ｂをロードする。このときのリクエストには、ＵＲＬ「ｆｉｌｅ：／／／ｄａｔａ／ａｐｐｓ／ａｐｐ２／ｉｎｄｅｘ．ｈｔｍｌ」が設定されている。
【０００９】
ＨＴＭＬ５アプリケーション１１３ａのオリジンは、「ｆｉｌｅ：／／／」であり、ＨＴＭＬ５アプリケーション１１３ｂのオリジンは、「ｆｉｌｅ：／／／」であり、両者は一致する。従って、ＨＴＭＬ５アプリケーション１１３ａとＨＴＭＬ５アプリケーション１１３ｂは、ローカルストレージ１１５ｃを共用することになる。尚、取得部２０１、アプリケーションパッケージ２０３ａ、アプリケーションパッケージ２０３ｂ及び管理範囲１１７は、ＨＴＭＬ５アプリケーション１１３の実行環境２０５に含まれる。そして、実行環境２０５は一体として制御される。
【００１０】
このように、ローカルストレージ１１５を共用すると、提供元が異なるＨＴＭＬ５アプリケーション１１３によってデータを参照され、或いは改変される恐れがある。尚、ＨＴＭＬ５アプリケーション１１３は、Ｗｅｂアプリケーションの例である。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００１−０５１８３９号公報
【特許文献２】国際公開第２００９−１３９４３７号
【特許文献３】特開２００７−３３６３３５号公報
【特許文献４】特開２００７−３２３１１５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、一側面では、内部に格納されている複数のアプリケーションをブラウザエンジンで実行させる際に、アプリケーション毎に独自のオリジンを割り当てることである。
【課題を解決するための手段】
【００１３】
一態様の情報処理装置は、（Ａ）ブラウザエンジンと、（Ｂ）ブラウザエンジンで実行されるアプリケーションを格納するための格納部と、（Ｃ）アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードをブラウザエンジンに指示する指示部と、（Ｄ）プロキシとして、ブラウザエンジンから仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、仮想ＵＲＬに対応するパスにより特定されるアプリケーションをブラウザエンジンに提供する提供部とを有する。
【発明の効果】
【００１４】
一側面においては、内部に格納されている複数のアプリケーションをブラウザエンジンで実行させる際に、アプリケーション毎に独自のオリジンを割り当てることができる。
【図面の簡単な説明】
【００１５】
【図１】図１は、ユーザ端末におけるブラウザエンジンが配信サーバからＨＴＭＬ５アプリケーションをロードする例を示す図である。
【図２】図２は、ユーザ端末におけるブラウザエンジンが内部で保持するＨＴＭＬ５アプリケーションをロードする例を示す図である。
【図３】図３は、ユーザ端末におけるブラウザエンジンが内部サーバからＨＴＭＬ５アプリケーションをロードする例を示す図である。
【図４】図４は、ユーザ端末に２つの実行環境を設ける例を示す図である。
【図５】図５は、本実施の形態における概要を示す図である。
【図６】図６は、本実施の形態において２つの実行環境を設ける例を示す図である。
【図７】図７は、ネットワーク構成例を示す図である。
【図８】図８は、ユーザ端末のモジュール構成例を示す図である。
【図９】図９は、配信元テーブルの例を示す図である。
【図１０】図１０は、配信サーバのモジュール構成例を示す図である。
【図１１】図１１は、初期設定フェーズのシーケンスを示す図である。
【図１２Ａ】図１２Ａは、配備フェーズのシーケンスを示す図である。
【図１２Ｂ】図１２Ｂは、配備フェーズのシーケンスを示す図である。
【図１３Ａ】図１３Ａは、仮想ＵＲＬテーブルの例を示す図である。
【図１３Ｂ】図１３Ｂは、パッケージ格納部のディレクトリ構成例を示す図である。
【図１４】図１４は、指示フェーズのシーケンスを示す図である。
【図１５】図１５は、提供フェーズのシーケンスを示す図である。
【図１６】図１６は、提供フェーズのシーケンスを示す図である。
【図１７】図１７は、提供フェーズのシーケンスを示す図である。
【図１８】図１８は、仮想ＵＲＬテーブルの例を示す図である。
【図１９Ａ】図１９Ａは、実施の形態２における配備フェーズのシーケンスを示す図である。
【図１９Ｂ】図１９Ｂは、実施の形態２における配備フェーズのシーケンスを示す図である。
【図２０Ａ】図２０Ａは、実施の形態３における配備フェーズのシーケンスを示す図である。
【図２０Ｂ】図２０Ｂは、実施の形態３における配備フェーズのシーケンスを示す図である。
【図２１】図２１は、実施の形態３における仮想ＵＲＬテーブルの例を示す図である。
【図２２Ａ】図２２Ａは、実施の形態３における配備フェーズのシーケンスを示す図である。
【図２２Ｂ】図２２Ｂは、実施の形態３における配備フェーズのシーケンスを示す図である。
【図２３】図２３は、実施の形態３における仮想ＵＲＬテーブルの例を示す図である。
【図２４】図２４は、ユーザ端末のハードウエア構成例を示す図である。
【図２５】図２５は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１６】
［実施の形態１］
本実施の形態の例について説明する前に、内部に保持されている複数のＨＴＭＬ５アプリケーション１１３が使用するローカルストレージ１１５を分離する或る方法について触れる。
【００１７】
或る方法では、各ＨＴＭＬ５アプリケーション１１３に対して、オリジンの異なる内部サーバを設けて、ブラウザエンジン１１１がその内部サーバにアクセスしてＨＴＭＬ５アプリケーション１１３を読み込む。内部サーバは、機能的にはＷｅｂサーバに相当する。例えば、各内部サーバが使用するソケットに別個のポート番号を割り当てれば、ＨＴＭＬ５アプリケーション１１３毎にオリジンを区別することができる。従って、ＨＴＭＬ５アプリケーション１１３毎に別個のローカルストレージ１１５が割り当てられることになる。
【００１８】
図３に、ユーザ端末１０１におけるブラウザエンジン１１１が内部サーバ３０１からＨＴＭＬ５アプリケーション１１３をロードする例を示す。図２の場合と同様に、ユーザ端末１０１は、アプリケーションパッケージ２０３ａ及びアプリケーションパッケージ２０３ｂを保持しているものとする。この例で、アプリケーションパッケージ２０３ａには内部サーバ３０１ａが割り当てられ、アプリケーションパッケージ２０３ｂには内部サーバ３０１ｂが割り当てられる。内部サーバ３０１ａ及び内部サーバ３０１ｂは、実行環境２０５に含まれる。
【００１９】
そして、ブラウザエンジン１１１は、ポート番号「１０００１」のソケットによって内部サーバ３０１ａにアクセスし、ＨＴＭＬ５アプリケーション１１３ａをロードする。このとき、ブラウザエンジン１１１から内部サーバ３０１ａへＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」が設定されたＨＴＴＰリクエストが送られる。また、ブラウザエンジン１１１は、ポート番号「１０００２」のソケットによって内部サーバ３０１ｂにアクセスし、ＨＴＭＬ５アプリケーション１１３ｂをロードする。このとき、ブラウザエンジン１１１から内部サーバ３０１ｂへＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００２／ａｐｐ２／ｉｎｄｅｘ．ｈｔｍｌ」が設定されたＨＴＴＰリクエストが送られる。
【００２０】
ＨＴＭＬ５アプリケーション１１３ａのオリジンは、「ｈｔｔｐ：／／０．０．０．０：１０００１」であり、ＨＴＭＬ５アプリケーション１１３ｂのオリジンは、「ｈｔｔｐ：／／０．０．０．０：１０００２」であり、両者は一致しない。従って、ＨＴＭＬ５アプリケーション１１３ａが使用するローカルストレージ１１５ａと、ＨＴＭＬ５アプリケーション１１３ｂが使用するローカルストレージ１１５ｂとは別個に設けられる。
【００２１】
ここで、ブラウザエンジン１１１を含むＨＴＭＬ５アプリケーション１１３の実行環境２０５を複数設けることを想定する。例えば学校向けのアプリケーショングループのための実行環境２０５と、商業施設向けのアプリケーショングループのための実行環境２０５とを、ユーザ端末１０１内に共存させる。
【００２２】
このような態様で、各実行環境２０５において独自の手順でポート番号を割り当てると、それぞれの実行環境２０５において内部サーバ３０１に割り当てられるポート番号が重複してしまうことも考えられる。仮にポート番号が重複すれば、一方の内部サーバ３０１を起動できない。つまり、複数の実行環境２０５におけるＨＴＭＬ５アプリケーション１１３の並行動作は、保証されないことになる。
【００２３】
図４に示した例では、ユーザ端末１０１に実行環境２０５ａと実行環境２０５ｂとが設けられている。実行環境２０５ａにおいて内部サーバ３０１ａがポート番号「１０００１」を使用している場合、実行環境２０５ｂにおいて内部サーバ３０１ｂもポート番号「１０００１」を使用しようとすれば、ソケットを生成できない。つまり、内部サーバ３０１ｂが起動されず、実行環境２０５ｂにおいてアプリケーションパッケージ２０３ｂを実行できない事態となる。
【００２４】
続いて、図５を用いて、本実施の形態における概要について説明する。図２の場合と同様に、ユーザ端末１０１は、アプリケーションパッケージ２０３ａ及びアプリケーションパッケージ２０３ｂを保持しているものとする。本実施の形態では、実行環境２０５にローカルプロキシ５０１が設けられる。ローカルプロキシ５０１は、ポート番号「８０８０」のソケットを介してブラウザエンジン１１１からリクエストを受け付ける。
【００２５】
ブラウザエンジン１１１がＨＴＭＬ５アプリケーション１１３ａをロードする場合には、ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」が設定されたリクエストがローカルプロキシ５０１へ送られる。また、ブラウザエンジン１１１がＨＴＭＬ５アプリケーション１１３ｂをロードする場合には、ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００２／ａｐｐ２／ｉｎｄｅｘ．ｈｔｍｌ」が設定されたリクエストがローカルプロキシ５０１へ送られる。このとき使用されるＵＲＬは、仮想のものであって、実在するものでなくてもよい。
【００２６】
ローカルプロキシ５０１は、この仮想のＵＲＬに対応するパスを特定する。具体的には、ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」に対応するアプリケーションパッケージ２０３ａのパス「／ｄａｔａ／ａｐｐｓ／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」を特定する。また、ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００２／ａｐｐ２／ｉｎｄｅｘ．ｈｔｍｌ」に対応するアプリケーションパッケージ２０３ｂのパス「／ｄａｔａ／ａｐｐｓ／ａｐｐ２／ｉｎｄｅｘ．ｈｔｍｌ」を特定する。そして、ローカルプロキシ５０１は、各パスが示す格納位置からファイルを読んで、ブラウザエンジン１１１へ渡す。
【００２７】
この例で、ＨＴＭＬ５アプリケーション１１３ａのオリジンは、「ｈｔｔｐ：／／０．０．０．０：１０００１」であり、ＨＴＭＬ５アプリケーション１１３ｂのオリジンは、「ｈｔｔｐ：／／０．０．０．０：１０００２」であり、両者は一致しない。従って、ＨＴＭＬ５アプリケーション１１３ａが使用するローカルストレージ１１５ａと、ＨＴＭＬ５アプリケーション１１３ｂが使用するローカルストレージ１１５ｂとは別個に設けられる。
【００２８】
本実施の形態では、ローカルプロキシ５０１においてオリジンに含まれるポート番号によるソケットを生成しない。この例で、ポート番号「１０００１」のソケットも、ポート番号「１０００２」のソケットも生成しない。
【００２９】
従って、ポート番号の重複によるエラーは起きない。図６に、本実施の形態において２つの実行環境２０５を設ける例を示す。この例で、実行環境２０５ａに設けられるローカルプロキシ５０１ａは、ポート番号「８０８０」のソケットを使用し、実行環境２０５ｂに設けられるローカルプロキシ５０１ｂは、ポート番号「８０８１」のソケットを使用する。
【００３０】
この例で、ＨＴＭＬ５アプリケーション１１３ａのオリジン「ｈｔｔｐ：／／０．０．０．０：１０００１」とＨＴＭＬ５アプリケーション１１３ｂのオリジン「ｈｔｔｐ：／／０．０．０．０：１０００１」とが一致する。しかし、ＨＴＭＬ５アプリケーション１１３ａが使用するローカルストレージ１１５ａと、ＨＴＭＬ５アプリケーション１１３ｂが使用するローカルストレージ１１５ｂとは、異なる実行環境２０５に属するので、別個に設けられる。
【００３１】
また、実行環境２０５ａ及び実行環境２０５ｂは、共にポート番号「１０００１」のソケットを設けずに動作するので、ポートが競合することは無い。従って、並列動作に関して、上述した支障は生じない。以上で本実施の形態における概要の説明を終える。
【００３２】
改めて、図７を用いて、本実施の形態に係る配信システムのネットワーク構成について説明する。配信サーバ１０３は、ネットワークに接続している。ネットワークは、イントラネットであってもよい。
【００３３】
ユーザ端末１０１は、ネットワークを介して配信サーバ１０３にアクセスする。無線ＬＡＮ（Local Area Network）を利用するアクセス形態であってもよい。
【００３４】
以下の例では、ユーザ端末１０１においてＨＴＭＬ５アプリケーション１１３を実行する際に、外部サーバ７０１にアクセスすることも想定する。詳しくは、後述する。
【００３５】
尚、配信サーバ１０３を複数設けるようにしてもよい。ユーザ端末１０１を複数設けるようにしてもよい。外部サーバ７０１を複数設けるようにしてもよい。
【００３６】
図８に、ユーザ端末１０１のモジュール構成例を示す。ユーザ端末１０１は、ＯＳ（オペレーティングシステム）８００及び実行環境２０５を有する。実行環境２０５を複数有するようにしてもよい。
【００３７】
実行環境２０５は、ブラウザエンジン１１１及び取得部２０１の他に、提供部８０１、配備部８０３、設定部８０５及び指示部８０７を有する。ブラウザエンジン１１１は、ＨＴＭＬ５に従ってブラウジング処理を行う。そのために、ブラウザエンジン１１１は、例えば、通常のブラウザに含まれるモジュールのうちユーザインターフェースを除き、レンダリングエンジン、ネットワーキング、ＵＩ（User Interface）バックエンド、データストレージに関するモジュールを有する。取得部２０１は、配信サーバ１０３からアプリケーションパッケージ２０３を取得する。提供部８０１は、上述したローカルプロキシ５０１に相当し、アプリケーションパッケージ２０３に含まれるファイルをブラウザエンジン１１１に提供する。配備部８０３は、アプリケーションパッケージ２０３を所定の格納位置に配備する。設定部８０５は、実行環境２０５に関する初期設定を行う。指示部８０７は、ＨＴＭＬ５アプリケーション１１３のロード（以下、アプリケーションロードという。）を指示する。なお、ローカルプロキシ５０１は、従来のプロキシサーバと同様に、ユーザ端末１０１の外部にあっても良い。 この場合、プロキシサーバは、提供部８０１、配備部８０３、取得部２０１、配信元記憶部８２１、仮想ＵＲＬ記憶部８２５及びパッケージ格納部８２７を有する。
【００３８】
実行環境２０５は、更に配信元記憶部８２１、ポート番号記憶部８２３、仮想ＵＲＬ記憶部８２５及びパッケージ格納部８２７を有する。配信元記憶部８２１は、配信元テーブルを記憶する。配信元テーブルについては、図９を用いて後述する。ポート番号記憶部８２３は、提供部８０１が使用するポート番号を記憶する。仮想ＵＲＬ記憶部８２５は、仮想ＵＲＬテーブルを記憶する。仮想ＵＲＬテーブルについては、図１３Ａを用いて後述する。パッケージ格納部８２７は、アプリケーションパッケージ２０３を格納する。
【００３９】
上述した提供部８０１、配備部８０３、取得部２０１、設定部８０５及び指示部８０７は、ハードウエア資源（例えば、図２４）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【００４０】
上述した配信元記憶部８２１、ポート番号記憶部８２３、仮想ＵＲＬ記憶部８２５及びパッケージ格納部８２７は、ハードウエア資源（例えば、図２４）を用いて実現される。
【００４１】
図９に、配信元テーブルの例を示す。この例における配信元テーブルは、ＨＴＭＬ５アプリケーション１１３に対応するレコードを有している。配信元テーブルのレコードは、アプリケーションＩＤを設定するためのフィールドと、配信元ＵＲＬを設定するためのフィールドとを有している。図示した１番目のレコードは、ＩＤ「ａｐ１」のＨＴＭＬ５アプリケーション１１３が配信元ＵＲＬ「ｈｔｔｐ：／／ａｐｌｓｔｏｒｅ１．ｃｏｍ／ａｐｐ１．ｚｉｐ」にアクセスすることによって得られることを示している。
【００４２】
図１０に、配信サーバ１０３のモジュール構成例を示す。配信サーバ１０３は、配信部１００１、設定部１００３及びパッケージ記憶部１０１１を有する。配信部１００１は、アプリケーションパッケージ２０３を配信する。設定部１００３は、アプリケーションパッケージ２０３のメタデータに所定のパラメータを設定する。設定部１００３については、実施の形態２及び３において説明する。パッケージ記憶部１０１１は、アプリケーションパッケージ２０３を記憶する。
【００４３】
上述した配信部１００１及び設定部１００３は、ハードウエア資源（例えば、図２５）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【００４４】
上述したパッケージ記憶部１０１１は、ハードウエア資源（例えば、図２５）を用いて実現される。
【００４５】
以下、初期設定フェーズ、配備フェーズ、指示フェーズ及び提供フェーズの各シーケンスについて説明する。
【００４６】
図１１に、初期設定フェーズのシーケンスを示す。初期設定フェーズでは、提供部８０１が使用するソケットを設ける。提供部８０１が例えばユーザインターフェースを介して起動指示を受け付けると（Ｓ１１０１）、提供部８０１は、任意のポート番号によるソケット生成をＯＳ８００に要求する（Ｓ１１０３）。
【００４７】
ＯＳ８００は、未使用のポートを選択し、当該ポートによるソケットを生成する（Ｓ１１０５）。そして、当該ソケットのポート番号を提供部８０１へ返す。
【００４８】
提供部８０１が当該ソケットのポート番号をＯＳ８００から受け付けると（Ｓ１１０７）、提供部８０１は、当該ポート番号をポート番号記憶部８２３に書き込む（Ｓ１１０９）。提供部８０１は、更にソケットの用途をＯＳ８００に設定する（Ｓ１１１１）。この場合のソケットの用途は、ブラウザエンジン１１１からのリクエスト受け付けである。
【００４９】
続いて、配備フェーズについて説明する。図１２Ａ及び図１２Ｂに、配備フェーズのシーケンスを示す。配備フェーズでは、ＨＴＭＬ５アプリケーション１１３を含むアプリケーションパッケージ２０３をパッケージ格納部８２７に配備する。
【００５０】
まず、取得部２０１は、配信元テーブルから配信元ＵＲＬ（例えば、「ｈｔｔｐ：／／ａｐｌｓｔｏｒｅ１．ｃｏｍ／ａｐｐ１．ｚｉｐ」）を１つ得る（Ｓ１２０１）。そして、取得部２０１は、配信サーバ１０３にアプリケーションパッケージ２０３を要求する（Ｓ１２０３）。このとき送られるＨＴＴＰリクエストには、当該配信元ＵＲＬが設定されている。
【００５１】
配信サーバ１０３の配信部１００１がアプリケーションパッケージ２０３の要求を受け付けると（Ｓ１２０５）、配信サーバ１０３は、パッケージ記憶部１０１１に記憶しているアプリケーションパッケージ２０３を送信する（Ｓ１２０７）。つまり、このとき送られるＨＴＴＰレスポンスには、アプリケーションパッケージ２０３のファイル（例えば、ａｐｐ１．ｚｉｐ）が含まれる。
【００５２】
取得部２０１は、当該ＨＴＴＰレスポンスを受信する（Ｓ１２０９）。取得部２０１は、アプリケーションパッケージ２０３に付加されているデジタル署名を検証するようにしてもよい。取得部２０１の処理は、端子Ａを介して図１２Ｂへ移る。
【００５３】
配備部８０３は、仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／」）を決定する（Ｓ１２１１）。具体的には、仮想ＵＲＬに設定されるスキーム名は「ｈｔｔｐ」である。仮想ＵＲＬに設定されるＩＰアドレスは、ユーザ端末１０１自身を意味するＩＰアドレス（例えば、「０．０．０．０」）である。仮想ＵＲＬに設定されるポート番号には、定数（例えば、１００００）に順次１加えた値を用いる。仮想ＵＲＬに設定されるパス名には、取得部２０１で取得したアプリケーションパッケージ２０３のファイル基底名（例えば、「ａｐｐ１」）を用いる。この段階の仮想ＵＲＬは、ファイル名を含まない。配備部８０３は、仮想ＵＲＬを仮想ＵＲＬ記憶部８２５に書き込む（Ｓ１２１３）。
【００５４】
配備部８０３は、アプリケーションパッケージ２０３の格納位置を示すパス（例えば、「／ｄａｔａ／ａｐｐｓ／ａｐｐ１」）を決定する（Ｓ１２１５）。具体的には、パッケージ格納部８２７における上位ディレクトリのパス（例えば、「／ｄａｔａ／ａｐｐｓ」）に、取得部２０１で取得したアプリケーションパッケージ２０３のファイル基底名と同じ名前の下位ディレクトリ（例えば、「／ａｐｐ１」）を加えることによってパスが定まる。配備部８０３は、当該パスによってアプリケーションパッケージ２０３をパッケージ格納部８２７に格納する（Ｓ１２１７）。
【００５５】
図１３Ａに、仮想ＵＲＬテーブルの例を示す。この例における仮想ＵＲＬテーブルは、ＨＴＭＬ５アプリケーション１１３に対応するレコードを有している。仮想ＵＲＬテーブルのレコードは、アプリケーションＩＤを設定するためのフィールドと、仮想ＵＲＬを設定するためのフィールドとを有している。
【００５６】
図示した１番目のレコードは、ＩＤ「ａｐ１」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／」が割り当てられていることを示している。この場合、オリジンは「ｈｔｔｐ：／／０．０．０．０：１０００１」である。
【００５７】
同じく２番目のレコードは、ＩＤ「ａｐ２」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００２／ａｐｐ２／」が割り当てられていることを示している。この場合、オリジンは「ｈｔｔｐ：／／０．０．０．０：１０００２」である。
【００５８】
同じく３番目のレコードは、ＩＤ「ａｐ３」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００３／ａｐｐ３／」が割り当てられていることを示している。この場合、オリジンは「ｈｔｔｐ：／／０．０．０．０：１０００３」である。
【００５９】
図１３Ｂに、パッケージ格納部８２７のディレクトリ構成例を示す。パッケージ格納部８２７の上位ディレクトリは、「／ｄａｔａ／ａｐｐｓ」である。上位ディレクトリの下位にＨＴＭＬ５アプリケーション１１３毎のディレクトリが設けられる。
【００６０】
例えばディレクトリ「／ａｐｐ１」には、ａｐｐ１．ｚｉｐに相当するアプリケーションパッケージ２０３ａが格納される。アプリケーションパッケージ２０３ａには、「ｉｎｄｅｘ．ｈｔｍｌ」及び「ｃｏｍｍｏｎ．ｃｓｓ」などのファイルが含まれている。尚、下位のディレクトリもａｐｐ１．ｚｉｐにおいて定義されている。また、ＺＩＰファイルから随時所望のファイルが抽出されるものとする。
【００６１】
続いて、指示フェーズについて説明する。図１４に、指示フェーズのシーケンスを示す。指示フェーズでは、ブラウザエンジン１１１にアプリケーションロードを指示する。
【００６２】
まず、設定部８０５は、ポート番号記憶部８２３からポート番号を読む（Ｓ１４０１）。設定部８０５は、ブラウザエンジン１１１に対してプロキシの設定を行う（Ｓ１４０３）。具体的には、ユーザ端末１０１のホスト名と当該ポート番号とを設定する。尚、Ｓ１４０１及びＳ１４０３の処理を、初期設定フェーズにおいて行うようにしてもよい。
【００６３】
指示部８０７は、パッケージ格納部８２７からアプリケーションパッケージ２０３のメタデータに含まれるファイル名（例えば、「ｉｎｄｅｘ．ｈｔｍｌ」）を読む（Ｓ１４０５）。当該ファイル名は、最初のロード対象を特定する。
【００６４】
指示部８０７は、仮想ＵＲＬ記憶部８２５から仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／」）を読む（Ｓ１４０７）。指示部８０７は、ファイル名を加えた仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」）に基づくアプリケーションロードをブラウザエンジン１１１に指示する（Ｓ１４０９）。
【００６５】
続いて、提供フェーズについて説明する。図１５に、提供フェーズのシーケンスを示す。提供フェーズでは、提供部８０１がブラウザエンジン１１１にアプリケーションパッケージ２０３に含まれるファイルを提供する。
【００６６】
まず、提供部８０１は、ファイル取得リクエスト（ＨＴＴＰリクエスト）をブラウザエンジン１１１から受け付ける（Ｓ１５０１）。当該ファイル取得リクエストには、図１４のＳ１４０９において指示された仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」）が設定されている。
【００６７】
提供部８０１は、仮想ＵＲＬ記憶部８２５から仮想ＵＲＬ（ファイル名を含まない）を取得して、ファイル取得リクエストが仮想ＵＲＬ記憶部８２５に記憶されている仮想ＵＲＬに該当するか否かを判定する。この例では、提供部８０１は、当該ファイル取得リクエストが仮想ＵＲＬ記憶部８２５に記憶されている仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／」）に該当すると判定する（Ｓ１５０３）。
【００６８】
ファイル取得リクエストが仮想ＵＲＬ記憶部８２５に記憶されている仮想ＵＲＬに該当すると判定した場合には、提供部８０１は、ファイル取得リクエストに設定されている仮想ＵＲＬに対応するパス（例えば、「／ｄａｔａ／ａｐｐｓ／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」）を特定する（Ｓ１５０５）。具体的には、ファイル取得リクエストに設定されている仮想ＵＲＬに含まれるパス名（例えば、「／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」）を、パッケージ格納部８２７における上位パス（例えば、「／ｄａｔａ／ａｐｐｓ」）に加えてファイルの格納位置を示すパスが定まる。なお、パスとしては、「／」で始まる形式（例えば、「／ｄａｔａ／ａｐｐｓ／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」）以外に、ＵＲＬ形式（例えば、「ｆｉｌｅ：／／／ｄａｔａ／ａｐｐｓ／ａｐｐ１／ｉｎｄｅｘ．ｈｔｍｌ」）でも良い。
【００６９】
提供部８０１は、パッケージ格納部８２７から当該パスが示す格納位置のファイルを読む（Ｓ１５０７）。提供部８０１は、読んだファイル（例えば、「ｉｎｄｅｘ．ｈｔｍｌ」）をブラウザエンジン１１１に提供する（Ｓ１５０９）。
【００７０】
ブラウザエンジン１１１は、当該ファイルに基づくブラウジング処理を開始する（Ｓ１５１１）。その他のファイル（例えば、「ｃｏｍｍｏｎ．ｃｓｓ」）は、ブラウジング処理においてパッケージ格納部８２７から読み込まれる。
【００７１】
尚、ブラウザエンジン１１１におけるブラウジング処理において、外部ＵＲＬが設定されているＨＴＴＰリクエストを提供部８０１に渡すことがある。この場合のシーケンスを図１６に示す。
【００７２】
提供部８０１がブラウザエンジン１１１から外部ＵＲＬが設定されているＨＴＴＰリクエストを受け付けると（Ｓ１６０１）、提供部８０１は、当該ＨＴＴＰリクエストが仮想ＵＲＬ記憶部８２５に記憶されている仮想ＵＲＬに該当しないと判定する（Ｓ１６０３）。外部ＵＲＬは、外部サーバ７０１を指しているからである。
【００７３】
ＨＴＴＰリクエストが仮想ＵＲＬ記憶部８２５に記憶されている仮想ＵＲＬに該当しないと判定した場合には、提供部８０１は従来のプロキシと同様に動作する。従って、提供部８０１は、ネットワークを介して当該ＨＴＴＰリクエストを外部サーバ７０１へ転送する（Ｓ１６０５）。
【００７４】
そして、提供部８０１が外部サーバ７０１からＨＴＴＰレスポンスを受信すると（Ｓ１６０７）、提供部８０１は、受信したＨＴＴＰレスポンスをブラウザエンジン１１１へ転送する（Ｓ１６０９）。尚、外部サーバ７０１においてＣＯＲＳ（Cross-Origin Resource Sharing）の設定が行われているものとする。ＣＯＲＳについては、後で説明する。
【００７５】
続いて、初期設定フェーズを開始する時点で、ブラウザエンジン１１１に既に外部プロキシ１７３１が設定されていた場合について説明する。この場合には、提供部８０１は、外部プロキシ１７３１の設定に関するデータを退避した上で、初期設定フェーズにおける処理を行う。
【００７６】
そして、提供フェーズでは、当該外部プロキシ１７３１へＨＴＴＰリクエストを転送する。図１７を用いて、この場合のシーケンスについて説明する。
【００７７】
図１６の場合と同様に、提供部８０１がブラウザエンジン１１１からＨＴＴＰリクエストを受け付けると（Ｓ１７０１）、提供部８０１は、ＨＴＴＰリクエストが仮想ＵＲＬに該当しないと判定する（Ｓ１７０３）。そして、提供部８０１は、初期設定フェーズにおいて退避したデータに基づいて外部プロキシ１７３１を特定する（Ｓ１７０５）。
【００７８】
提供部８０１は、外部プロキシ１７３１へＨＴＴＰリクエストを転送する（Ｓ１７０７）。ＨＴＴＰリクエストは、外部プロキシ１７３１を介して外部サーバ７０１へ伝えられる。その後、提供部８０１は、外部プロキシ１７３１を介してＨＴＴＰレスポンスを受信する（Ｓ１７０９）。提供部８０１は、ＨＴＴＰレスポンスをブラウザエンジン１１１へ転送する（Ｓ１７１１）。
【００７９】
上述した例では、ポート番号を替えることによってオリジンが重複しないようにする。但し、ＩＰアドレス或いはホスト名を替えることによってオリジンが重複しないようにしてもよい。
【００８０】
図１８に、ＩＰアドレスを替える場合の仮想ＵＲＬテーブルの例を示す。図示した１番目のレコードは、ＩＤ「ａｐ１」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／１２７．０．０．１：１００００／ａｐｐ１／」が割り当てられていることを示している。この場合、オリジンは「ｈｔｔｐ：／／１２７．０．０．１：１００００」である。
【００８１】
同じく２番目のレコードは、ＩＤ「ａｐ２」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／１２７．０．０．２：１００００／ａｐｐ２／」が割り当てられていることを示している。この場合、オリジンは「ｈｔｔｐ：／／１２７．０．０．２：１００００」である。
【００８２】
同じく３番目のレコードは、ＩＤ「ａｐ３」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／１２７．０．０．３：１００００／ａｐｐ３／」が割り当てられていることを示している。この場合、オリジンは「ｈｔｔｐ：／／１２７．０．０．３：１００００」である。
【００８３】
仮想ＵＲＬは、実際のアクセスに用いられないので、ＵＲＬの形式に従っていれば足りる。つまり、ブラウザエンジン１１１がオリジンを認識するようになっていればよい。
【００８４】
本実施の形態によれば、内部に格納されている複数のＨＴＭＬ５アプリケーション１１３をブラウザエンジン１１１で実行させる際に、ＨＴＭＬ５アプリケーション１１３毎に独自のオリジンを割り当て、夫々ローカルストレージ１１５を専有させることができる。また、例えばポートの競合のような現実のリソースに関する制約が生じないという面もある。
【００８５】
また、実行環境２０５を複数有するようにすれば、ＨＴＭＬ５アプリケーション１１３のグループが複数有る場合に、グループ毎に管理範囲１１７を設けて、各グループの独立性を保つように運用できる。また、異なる管理範囲１１７で同一の仮想ＵＲＬが用いられる事態が生じても支障がないという面もある。
【００８６】
［実施の形態２］
ブラウザエンジン１１１が同一オリジンポリシーに従って動作する場合について述べる。この場合、ブラウザエンジン１１１で実行されているＨＴＭＬ５アプリケーション１１３が、当該ＨＴＭＬ５アプリケーション１１３の提供元以外の外部サーバ７０１に対してアクセスするとエラーになる。ＨＴＭＬ５アプリケーション１１３の提供元のオリジンは、リクエストの宛先のオリジンと異なるからである。このようにオリジンが異なる場合でもリクエストを正常に処理するためには、外部サーバ７０１側でＣＯＲＳの設定を行っておくことが条件となる。
【００８７】
本実施の形態では、外部サーバ７０１においてＣＯＲＳの設定を行っていなくても、エラーにならないようにする。具体的には、ＨＴＭＬ５アプリケーション１１３がアクセスしようとしている外部サーバ７０１のＵＲＬを、当該ＨＴＭＬ５アプリケーション１１３の仮想ＵＲＬに流用する。このようにすれば、オリジンが同一になる。オリジンが同一であればエラーにはならない。
【００８８】
そのため、配信サーバ１０３が、パッケージ記憶部１０１１に記憶されているアプリケーションパッケージ２０３のメタデータに、予め所定外部サーバ７０１のＵＲＬを設定しておくものとする。
【００８９】
図１９Ａ及び図１９Ｂに、実施の形態２における配備フェーズのシーケンスを示す。実施の形態１の場合と同様に、取得部２０１が配信元ＵＲＬを得ると（Ｓ１９０１）、取得部２０１は、アプリケーションパッケージ２０３を要求する（Ｓ１９０３）。
【００９０】
配信サーバ１０３の配信部１００１がアプリケーションパッケージ２０３の要求を受け付けると（Ｓ１９０５）、配信サーバ１０３は、外部ＵＲＬ（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ」）が設定されたメタデータを含むアプリケーションパッケージ２０３を送信する（Ｓ１９０７）。
【００９１】
取得部２０１は、当該アプリケーションパッケージ２０３を受信する（Ｓ１９０９）。取得部２０１の処理は、端子Ｂを介して図１９Ｂへ移る。
【００９２】
配備部８０３は、取得部２０１が受信したアプリケーションパッケージ２０３のメタデータから外部ＵＲＬを読む（Ｓ１９１１）。そして、配備部８０３は、仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ／ａｐｐ１／」）を決定する（Ｓ１９１３）。具体的には、外部ＵＲＬに取得部２０１で取得したアプリケーションパッケージ２０３のファイル基底名（例えば、「ａｐｐ１」）を加えることによって仮想ＵＲＬが定まる。この仮想ＵＲＬは、ファイル名を含まない。配備部８０３は、当該仮想ＵＲＬを仮想ＵＲＬ記憶部８２５に書き込む（Ｓ１９１５）。
【００９３】
実施の形態１の場合と同様に、配備部８０３は、アプリケーションパッケージ２０３の格納位置を示すパスを決定し（Ｓ１９１７）、アプリケーションパッケージ２０３を格納する（Ｓ１９１９）。
【００９４】
提供フェーズにおけるシーケンスは、実施の形態１の場合と同様である。但し、図１６及び図１７に示したシーケンスにおいて、外部サーバ７０１がＣＯＲＳの設定を行っていなくてもエラーにならない。
【００９５】
本実施の形態によれば、ＨＴＭＬ５アプリケーション１１３の実行中に所定の外部リソースにアクセスする場合に、同一オリジンポリシー違反によるエラーを回避できる。
【００９６】
［実施の形態３］
上述した実施の形態では、ＨＴＭＬ５アプリケーション１１３毎にオリジンを区別した。本実施の形態では、ＨＴＭＬ５アプリケーション１１３のグループ毎にオリジンを区別する。そうすれば、所定のグループ単位でローカルストレージ１１５を共用できる。
【００９７】
具体的には、配信サーバ１０３の設定部１００３が、予めアプリケーションパッケージ２０３のメタデータにグループキーを設定しておく。グループキーは、当該ＨＴＭＬ５アプリケーション１１３が属するグループを識別する。そして、グループキーが同じアプリケーションについては、同じオリジンを設定する。
【００９８】
図２０Ａ及び図２０Ｂに、実施の形態３における配備フェーズのシーケンスを示す。実施の形態１の場合と同様に、取得部２０１が配信元ＵＲＬを得ると（Ｓ２００１）、取得部２０１は、アプリケーションパッケージ２０３を要求する（Ｓ２００３）。
【００９９】
配信サーバ１０３の配信部１００１がアプリケーションパッケージ２０３の要求を受け付けると（Ｓ２００５）、配信サーバ１０３は、グループキー（例えば、「ｇ１」）が設定されたメタデータを含むアプリケーションパッケージ２０３を送信する（Ｓ２００７）。
【０１００】
取得部２０１は、当該アプリケーションパッケージ２０３を受信する（Ｓ２００９）。取得部２０１の処理は、端子Ｃを介して図２０Ｂへ移る。
【０１０１】
配備部８０３は、取得部２０１が受信したアプリケーションパッケージ２０３のメタデータからグループキーを読む（Ｓ２０１１）。そして、配備部８０３は、仮想ＵＲＬテーブルに同一のグループキーが設定されているか否かを判定する。
【０１０２】
図２１を用いて、実施の形態３における仮想ＵＲＬテーブルについて説明する。実施の形態３における仮想ＵＲＬテーブルのレコードは、更にグループキーを設定するためのフィールドを有している。
【０１０３】
図示した１番目のレコードは、ＩＤ「ａｐ１」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／」が割り当てられていることを示している。また、当該ＨＴＭＬ５アプリケーション１１３は、キー「ｇ１」で識別されるグループに属することを示している。
【０１０４】
同じく２番目のレコードは、ＩＤ「ａｐ２」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ２／」が割り当てられていることを示している。また、当該ＨＴＭＬ５アプリケーション１１３も、キー「ｇ１」で識別されるグループに属することを示している。この場合のオリジン（「ｈｔｔｐ：／／０．０．０．０：１０００１」）は、１番目の場合と同様である。
【０１０５】
同じく３番目のレコードは、ＩＤ「ａｐ３」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／０．０．０．０：１０００２／ａｐｐ３／」が割り当てられていることを示している。また、当該ＨＴＭＬ５アプリケーション１１３は、キー「ｇ２」で識別されるグループに属することを示している。この場合のオリジン（「ｈｔｔｐ：／／０．０．０．０：１０００２」）は、１番目及び２番目の場合と異なる。
【０１０６】
図２０Ｂの説明に戻る。この例では、仮想ＵＲＬテーブルにいずれのレコードも設けられていないものとする。従って、仮想ＵＲＬテーブルに同一のグループキーが設定されていないと判定される（Ｓ２０１３）。仮想ＵＲＬテーブルに同一のグループキーが設定されていない場合には、配備部８０３は、新規のオリジンに基づく仮想ＵＲＬを決定する（Ｓ２０１５）。新規のオリジンに基づく仮想ＵＲＬの決定方法は、実施の形態１における仮想ＵＲＬの決定方法と同様である。そして、配備部８０３は、仮想ＵＲＬとグループキーとを仮想ＵＲＬ記憶部８２５に書き込む（Ｓ２０１７）。
【０１０７】
実施の形態１の場合と同様に、配備部８０３は、アプリケーションパッケージ２０３の格納位置を示すパスを決定し（Ｓ２０１９）、アプリケーションパッケージ２０３を格納する（Ｓ２０２１）。未知のグループキーがメタデータに設定されていた場合には、このように処理する。この処理によって、図２１に示した仮想ＵＲＬテーブルにおける１番目のレコードが設けられたものとする。
【０１０８】
続いて、既知のグループキーがメタデータに設定されていた場合の処理について、図２２Ａ及び図２２Ｂに示した配備フェーズのシーケンスを用いて説明する。図２０Ａの場合と同様に、取得部２０１が配信元ＵＲＬを得ると（Ｓ２２０１）、取得部２０１は、アプリケーションパッケージ２０３を要求する（Ｓ２２０３）。
【０１０９】
配信サーバ１０３の配信部１００１がアプリケーションパッケージ２０３の要求を受け付けると（Ｓ２２０５）、配信サーバ１０３は、グループキー（例えば、「ｇ１」）が設定されたメタデータを含むアプリケーションパッケージ２０３を送信する（Ｓ２２０７）。
【０１１０】
取得部２０１は、当該アプリケーションパッケージ２０３を受信する（Ｓ２２０９）。取得部２０１の処理は、端子Ｄを介して図２２Ｂへ移る。
【０１１１】
配備部８０３は、取得部２０１が受信したアプリケーションパッケージ２０３のメタデータからグループキー（例えば、「ｇ１」）を読む（Ｓ２２１１）。そして、配備部８０３が仮想ＵＲＬテーブルに同一のグループキーが設定されていると判定すると（Ｓ２２１３）、配備部８０３は、既存のオリジンに基づく仮想ＵＲＬを決定する（Ｓ２２１５）。具体的には、配備部８０３は、仮想ＵＲＬテーブルから当該グループキーに対応する仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ１／」）を読む。そして、読んだ仮想ＵＲＬにおけるオリジン（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１」）にアプリケーションパッケージ２０３のファイル基底名（例えば、「ａｐｐ２」）を加えることによって、新たな仮想ＵＲＬ（例えば、「ｈｔｔｐ：／／０．０．０．０：１０００１／ａｐｐ２／」）が定まる。
【０１１２】
配備部８０３は、決定した仮想ＵＲＬとグループキーとを仮想ＵＲＬテーブルに書き込む（Ｓ２２１７）。上述した実施の形態と同様に、配備部８０３は、アプリケーションパッケージ２０３の格納位置を示すパスを決定し（Ｓ２２１９）、アプリケーションパッケージ２０３を格納する（Ｓ２２２１）。
【０１１３】
この例では、ポート番号によってグループを区別した。但し、ホスト名或いはＩＰアドレスによってグループを区別してもよい。
【０１１４】
図２３に、ホスト名によってグループを区別する場合の仮想ＵＲＬテーブルの例を示す。図示した１番目のレコードは、ＩＤ「ａｐ１」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／ｇ１．ｃｏｍ／ａｐｐ１／」が割り当てられていることを示している。また、当該ＨＴＭＬ５アプリケーション１１３は、キー「ｇ１」で識別されるグループに属することを示している。
【０１１５】
同じく２番目のレコードは、ＩＤ「ａｐ２」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／ｇ１．ｃｏｍ／ａｐｐ２／」が割り当てられていることを示している。また、当該ＨＴＭＬ５アプリケーション１１３も、キー「ｇ１」で識別されるグループに属することを示している。この場合のオリジン（「ｈｔｔｐ：／／ｇ１．ｃｏｍ」）は、１番目の場合と同様である。
【０１１６】
同じく３番目のレコードは、ＩＤ「ａｐ３」のＨＴＭＬ５アプリケーション１１３に、仮想ＵＲＬ「ｈｔｔｐ：／／ｇ２．ｃｏｍ／ａｐｐ３／」が割り当てられていることを示している。また、当該ＨＴＭＬ５アプリケーション１１３は、キー「ｇ２」で識別されるグループに属することを示している。この場合のオリジン（「ｈｔｔｐ：／／ｇ２．ｃｏｍ」）は、１番目及び２番目の場合と異なる。
【０１１７】
本実施の形態によれば、ＨＴＭＬ５アプリケーション１１３のグループ単位でローカルストレージ１１５を共用できる。ローカルストレージ１１５を共用すれば、例えば重複するデータを減らして、データ伝送量を減らすことができる。また、ＨＴＭＬ５アプリケーション１１３同士の連携を図ることにも役立つ面がある。
【０１１８】
図２４に、ユーザ端末１０１のハードウエア構成例を示す。ユーザ端末１０１は、プロセッサ２４０１、記憶部２４０３、アンテナ２４１１、無線制御部２４１３、オーディオ制御部２４１５、スピーカ２４１７、マイク２４１９、ディスプレイ２４２１、タッチセンサ２４２３、カメラ２４２５及びＧＰＳ（Global Positioning System）装置２４２７を有している。
【０１１９】
プロセッサ２４０１は、モデムＣＰＵ（Central Processing Unit）とアプリケーションＣＰＵからなることもある。記憶部２４０３は、例えば、ＲＯＭ（Read Only Memory）２４０５とＲＡＭ（Random Access Memory）２４０７とフラッシュメモリ２４０９を有している。ＲＯＭ２４０５は、例えば、予め設定されているデータやプログラムを格納している。ＲＡＭ２４０７は、例えば、アプリケーションなどのプログラムやデータを展開する領域を含んでいる。フラッシュメモリ２４０９は、例えば、オペレーティングシステムやアプリケーションなどのプログラムを格納しており、更に随時データを格納する。
【０１２０】
タッチセンサ２４２３は、例えば、ディスプレイ２４２１の表示面上に配置されたパネル状のセンサであり、タッチ操作を受け付ける。ディスプレイ２４２１は、例えば、アプリケーションが表示させる各種画面を表示する。具体的には、ディスプレイ２４２１とタッチセンサ２４２３とを一体としたタッチパネルとして用いられる。タッチセンサ２４２３へのタッチ操作によって、タッチイベントが発生する。タッチセンサ２４２３の他に、キーを設けるようにしてもよい。
【０１２１】
アンテナ２４１１は、例えばセルラー方式の無線データを受信する。無線制御部２４１３は、無線通信の制御を行う。無線通信の制御により、電話の音声通信やデータ通信が行われる。
【０１２２】
オーディオ制御部２４１５は、音データに関するアナログ／デジタル変換とデジタル／アナログ変換を行う。スピーカ２４１７は、アナログデータを音として出力する。マイク２４１９は、音をアナログデータに変換する。
【０１２３】
カメラ２４２５は、動画や写真画像の撮影に用いられる。ＧＰＳ装置２４２７は、位置を計測する。
【０１２４】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成はプログラムモジュール構成に一致しない場合もある。
【０１２５】
また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ、処理の順番を入れ替えることや複数の処理を並列に実行させるようにしても良い。
【０１２６】
なお、上で述べた配信サーバ１０３は、コンピュータ装置であって、図２５に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティングシステム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【０１２７】
以上述べた実施の形態をまとめると、以下のようになる。
【０１２８】
一態様の情報処理装置は、（Ａ）ブラウザエンジンと、（Ｂ）ブラウザエンジンで実行されるアプリケーションを格納するための格納部と、（Ｃ）アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードをブラウザエンジンに指示する指示部と、（Ｄ）プロキシとして、ブラウザエンジンから仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、仮想ＵＲＬに対応するパスにより特定されるアプリケーションをブラウザエンジンに提供する提供部とを有する。
【０１２９】
このようにすれば、内部に格納されている複数のアプリケーションをブラウザエンジンで実行させる際に、アプリケーション毎に独自のオリジンを割り当て、夫々ローカルストレージを専有させることができる。また、例えばポートの競合のような現実のリソースに関する制約が生じないという面もある。
【０１３０】
更に、ブラウザエンジンと、格納部と、指示部と、提供部とを含む、アプリケーションの実行環境を複数有するようにしてもよい。
【０１３１】
このようにすれば、アプリケーションのグループが複数有る場合に、グループ毎に実行環境を設けて、各グループの独立性を保つように運用できる。また、異なる実行環境で同一の仮想ＵＲＬが用いられる事態が生じても支障がないという面もある。
【０１３２】
更に、指示部は、アプリケーションに付加されている、所定の外部リソースのＵＲＬを、仮想ＵＲＬとして用いるようにしてもよい。
【０１３３】
このようにすれば、アプリケーションの実行中に所定の外部リソースにアクセスする場合に、同一オリジンポリシー違反によるエラーを回避できる。
【０１３４】
更に、指示部は、アプリケーションに付加されているグループ識別データに基づき、同一のグループに属するアプリケーションについて、共通のオリジンに該当する仮想ＵＲＬを用いるようにしてもよい。
【０１３５】
このようにすれば、グループ単位でローカルストレージを共用できる。
【０１３６】
なお、上で述べた情報処理装置における処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。
【０１３７】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１３８】
（付記１）
ブラウザエンジンと、
前記ブラウザエンジンで実行されるアプリケーションを格納するための格納部と、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示する指示部と、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する提供部と
を有する情報処理装置。
【０１３９】
（付記２）
前記ブラウザエンジンと、前記格納部と、前記指示部と、前記提供部とを含む、前記アプリケーションの実行環境を複数有する
付記１記載の情報処理装置。
【０１４０】
（付記３）
前記指示部は、前記アプリケーションに付加されている、所定の外部リソースのＵＲＬを、前記仮想ＵＲＬとして用いる
付記１又は２記載の情報処理装置。
【０１４１】
（付記４）
前記指示部は、前記アプリケーションに付加されているグループ識別データに基づき、同一のグループに属するアプリケーションについて、共通のオリジンに該当する仮想ＵＲＬを用いる
付記１又は２記載の情報処理装置。
【０１４２】
（付記５）
ブラウザエンジンと、前記ブラウザエンジンで実行されるアプリケーションを格納するための格納部とを有する情報処理装置により実行され、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示し、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する
処理を含む情報処理方法。
【０１４３】
（付記６）
ブラウザエンジンと、前記ブラウザエンジンで実行されるアプリケーションを格納するための格納部とを有するコンピュータに、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示し、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する
処理を実行させる情報処理プログラム。
【０１４４】
（付記７）
配信サーバと情報処理装置とを含む情報配信システムであって、
前記配信サーバは、所定の外部リソースのＵＲＬが付加されているアプリケーションを配信し、
前記情報処理装置は、
前記アプリケーションを実行するブラウザエンジンと、
前記アプリケーションを取得する取得部と、
前記アプリケーションを格納するための格納部と、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示する指示部と、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する提供部と
を有し、
前記指示部は、前記所定の外部リソースのＵＲＬを、前記仮想ＵＲＬとして用いる
情報配信システム。
【０１４５】
（付記８）
配信サーバと情報処理装置とを含む情報配信システムであって、
前記配信サーバは、アプリケーションが属するグループの識別データが付加されている当該アプリケーションを配信し、
前記情報処理装置は、
前記アプリケーションを実行するブラウザエンジンと、
前記アプリケーションを取得する取得部と、
前記アプリケーションを格納するための格納部と、
前記アプリケーションの格納位置を示すパスに対応する仮想ＵＲＬに基づくアプリケーションロードを前記ブラウザエンジンに指示する指示部と、
プロキシとして、前記ブラウザエンジンから前記仮想ＵＲＬによるデータ取得のリクエストを受け付けた場合に、前記仮想ＵＲＬに対応する前記パスにより特定される前記アプリケーションを前記ブラウザエンジンに提供する提供部と
を有し、
前記指示部は、前記識別データに基づき、同一のグループに属するアプリケーションについて、共通のオリジンに該当する仮想ＵＲＬを用いる
情報配信システム。
【符号の説明】
【０１４６】
１０１  ユーザ端末    １０３  配信サーバ
１１１  ブラウザエンジン    １１３  ＨＴＭＬ５アプリケーション
１１５  ローカルストレージ    １１７  管理範囲
２０１  取得部    ２０３  アプリケーションパッケージ
２０５  実行環境    ３０１  内部サーバ
５０１  ローカルプロキシ    ７０１  外部サーバ
８００  ＯＳ    ８０１  提供部
８０３  配備部    ８０５  設定部
８０７  指示部    ８２１  配信元記憶部
８２３  ポート番号記憶部    ８２５  仮想ＵＲＬ記憶部
８２７  パッケージ格納部    １００１  配信部
１００３  設定部    １０１１  パッケージ記憶部
１７３１  外部プロキシ
【図１】
0006736943.tif 000002
【図２】
0006736943.tif 000003
【図３】
0006736943.tif 000004
【図４】
0006736943.tif 000005
【図５】
0006736943.tif 000006
【図６】
0006736943.tif 000007
【図７】
0006736943.tif 000008
【図８】
0006736943.tif 000009
【図９】
0006736943.tif 000010
【図１０】
0006736943.tif 000011
【図１１】
0006736943.tif 000012
【図１２Ａ】
0006736943.tif 000013
【図１２Ｂ】
0006736943.tif 000014
【図１３Ａ】
0006736943.tif 000015
【図１３Ｂ】
0006736943.tif 000016
【図１４】
0006736943.tif 000017
【図１５】
0006736943.tif 000018
【図１６】
0006736943.tif 000019
【図１７】
0006736943.tif 000020
【図１８】
0006736943.tif 000021
【図１９Ａ】
0006736943.tif 000022
【図１９Ｂ】
0006736943.tif 000023
【図２０Ａ】
0006736943.tif 000024
【図２０Ｂ】
0006736943.tif 000025
【図２１】
0006736943.tif 000026
【図２２Ａ】
0006736943.tif 000027
【図２２Ｂ】
0006736943.tif 000028
【図２３】
0006736943.tif 000029
【図２４】
0006736943.tif 000030
【図２５】
0006736943.tif 000031