(57)【要約】      （修正有）【課題】利用者の操作を促すことなく、かつ、アプリケーションプログラムの保存領域の消費を抑制することができる情報処理装置を提供する。【解決手段】アプリケーションプログラムのアプリリソース及びランタイムを格納する格納部と、前記アプリケーションプログラムの起動指示ごとに、メモリ内にプロセス空間を生成するメモリ管理部と、前記ランタイムを前記プロセス空間に読み込むランタイム読み込み部と、前記アプリリソースを、前記ランタイムが読み込まれたプロセス空間に読み込むアプリリソース読み込み部と、前記プロセス空間に読み込まれたアプリリソース及びランタイムに基づき、前記アプリケーションプログラムのプロセスを生成するプロセス生成部と、前記アプリケーションプログラムのプロセスを実行するプロセス実行部と、を備える。【選択図】図５
2018097898.tif 000002
【特許請求の範囲】
【請求項１】
複数の異なるアプリケーションプログラムに対する複数のアプリリソース及び前記複数のアプリリソースの各々に用いられるランタイムを格納する格納部と、
前記複数の異なるアプリケーションプログラムに含まれる各アプリケーションプログラムの起動指示ごとに、メモリ内に前記各アプリケーションプログラムの各々に対応した複数のプロセス空間を生成するメモリ管理部と、
前記ランタイムを前記複数のプロセス空間のそれぞれに読み込むランタイム読み込み部と、
前記各アプリケーションプログラムに対応した各アプリリソースを、前記ランタイムが読み込まれた複数のプロセス空間のうち対応するプロセス空間に読み込むアプリリソース読み込み部と、
前記複数のプロセス空間のそれぞれに読み込まれたアプリリソース及びランタイムから、前記各アプリケーションプログラムのプロセスを生成するプロセス生成部と、
前記複数のプロセス空間上で生成された前記各アプリケーションプログラムのプロセスを実行するプロセス実行部と、
を備え、前記ランタイムは、オペレーティングシステムが解釈及び実行可能なネイティブアプリケーションプログラムであり、前記複数のアプリケーションプログラムの各々は、前記ランタイムと、前記ランタイムが解釈可能なリソースとで構成されたハイブリッドアプリケーションプログラムであり、前記アプリケーションプログラムをダウンロードする際にユーザへの確認表示の生成処理を実行し、前記複数のアプリリソースをダウンロードする際、前記確認表示の前記生成処理を実行しない情報処理装置。
【請求項２】
請求項１に記載の情報処理装置に於いて、
前記格納部は、暗号化されたアプリリソースを格納し、
前記アプリリソース読み込み部は、前記ランタイムが読み込まれたプロセス空間に、前記暗号化されたアプリリソースを読み込み、
前記情報処理装置は、さらに、
前記暗号化されたアプリリソースを復号化するための鍵を管理する鍵管理部と、
前記プロセス空間に読み込まれた前記暗号化されたアプリリソースを、前記鍵を用いて復号化する復号化部と、を備える情報処理装置。
【請求項３】
請求項２に記載の情報処理装置に於いて、
前記鍵管理部は、前記鍵を暗号化して、前記復号化部に引き渡し、
前記復号化部は、前記鍵管理部から引き渡された鍵を復号化するとともに、前記復号化された鍵を用いて、前記プロセス空間に読み込まれた前記暗号化されたアプリリソースを復号化する情報処理装置。
【請求項４】
請求項３に記載の情報処理装置に於いて、さらに、
前記各アプリケーションプログラムの起動指示に基づき、前記鍵管理部に前記鍵を要求する鍵要求部を備え、
前記鍵管理部は、前記鍵要求部から前記鍵を要求されたことを契機に、前記鍵を前記復号化部に引き渡す情報処理装置。
【請求項５】
請求項２乃至４の何れかに記載の情報処理装置に於いて、
前記格納部は、互いに異なる鍵を用いて暗号化された複数のアプリリソースを格納する情報処理装置。
【請求項６】
コンピュータが実行する情報処理方法に於いて、
複数の異なるアプリケーションプログラムに含まれる各アプリケーションプログラムの起動指示ごとに、メモリ内に前記各アプリケーションプログラムに対応した複数のプロセス空間を生成する工程と、
前記複数の異なるアプリケーションプログラムに対する複数のアプリリソース及び前記複数のアプリリソースの各々に用いられるランタイムを格納する格納部から、前記複数のプロセス空間のそれぞれに前記ランタイムを読み込む工程と、
前記各アプリケーションプログラムに対応した各アプリリソースを、前記ランタイムが読み込まれた前記複数のプロセス空間のうち対応するプロセス空間に読み込む工程と、
前記複数のプロセス空間のそれぞれに読み込まれたアプリリソース及びランタイムから、前記各アプリケーションプログラムのプロセスを生成する工程と、
前記複数のプロセス空間上で生成された前記各アプリケーションプログラムのプロセスを実行する工程と、
を備え、前記ランタイムは、オペレーティングシステムが解釈及び実行可能なネイティブアプリケーションプログラムであり、前記複数のアプリケーションプログラムの各々は、前記ランタイムと、前記ランタイムが解釈可能なリソースとで構成されたハイブリッドアプリケーションプログラムであり、前記アプリケーションプログラムをダウンロードする際にユーザへの確認表示の生成処理を実行し、前記複数のアプリリソースをダウンロードする際、前記確認表示の前記生成処理を実行しない情報処理方法。
【請求項７】
請求項６に記載の情報処理方法に於いて、
前記アプリリソースを読み込む工程では、暗号化されたアプリリソースを前記プロセス空間に読み込み、
前記情報処理方法は、さらに、
前記プロセス空間に読み込まれたアプリリソースを復号化する工程を備える情報処理方法。
【請求項８】
アプリケーションプログラムをダウンロードする際にユーザへの確認表示の生成処理を実行する情報処理装置のプロセッサに実行させるプログラムに於いて、
前記プロセッサに、
複数の異なる前記アプリケーションプログラムに含まれる各アプリケーションプログラムの起動指示ごとに、メモリ内に前記各アプリケーションプログラムに対応した複数のプロセス空間を生成し、
前記複数の異なるアプリケーションプログラムに対する複数のアプリリソース及び前記複数のアプリリソースの各々に用いられるランタイムを格納する格納部から、前記複数のプロセス空間のそれぞれに前記ランタイムを読み込ませ、
前記各アプリケーションプログラムに対応した各アプリリソースを、前記ランタイムが読み込まれた前記複数のプロセス空間のうち対応するプロセス空間に読み込ませ、
前記複数のプロセス空間のそれぞれに読み込ませたアプリリソース及びランタイムから、前記各アプリケーションプログラムのプロセスを生成させ、
前記複数のプロセス空間上で生成された前記各アプリケーションプログラムのプロセスを実行させ、前記ランタイムは、オペレーティングシステムが解釈及び実行可能なネイティブアプリケーションプログラムであり、前記複数のアプリケーションプログラムの各々は、前記ランタイムと、前記ランタイムが解釈可能なリソースとで構成されたハイブリッドアプリケーションプログラムであり、前記アプリケーションプログラムに対するアプリリソースがダウンロードされる際にユーザへの前記確認表示の前記生成処理が実行されない、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
開示の技術は、情報処理装置、情報処理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、３Ｇ／ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）／ホットスポットの充実に伴い、例えばスマートフォンなどの情報処理装置が、常時ネットワークに接続できる環境が整ってきている。
【０００３】
このような環境を活かし、アプリケーションサーバ（アプリストア）から情報処理装置に、必要なタイミングでアプリケーションプログラムを配信して、情報処理装置に実行させる情報処理システムが開発されている。また、アプリケーションサーバに登録されたアプリケーションプログラムを、利用者からの要求に応じて、情報処理装置に提供する情報処理システムも開発されている。当該システムに於いて、情報処理装置は、アプリケーションサーバから配信されるアプリケーションプログラムをダウンロードして、例えばフラッシュメモリなどにインストールすることとなる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１８２３０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、アプリケーションプログラムには、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が直接解釈・実行可能な形式のもの（ネイティブアプリと呼ぶ）の他に、ＯＳが直接解釈・実行可能なランタイムと、ランタイムが解釈可能なリソースとで構成されたもの（ハイブリッドアプリと呼ぶ）がある。ここで言うリソースとは、例えばＨＴＭＬやＪａｖａ（登録商標）ｓｃｒｉｐｔで記述されたプログラムである。ハイブリッドアプリとしては、例えばＰｈｏｎｅＧａｐなどがある。ハイブリッドアプリは、リソース部分はＯＳに依存しないため、ＯＳに依存するランタイムだけを入れ替えることによって、互いに異なるＯＳ上で動作するアプリケーションプログラムを開発者が簡単に作成できるメリットがある。
【０００６】
このようなハイブリッドアプリを、特定のＯＳが動作する情報処理装置に配布する場合、通常、対象となるＯＳに対応したランタイムとリソースとを一体化してコンパイルし、対象ＯＳのネイティブアプリ形式に変換したものを配布する。
【０００７】
ところが、複数種のハイブリッドアプリを同一の情報処理装置にインストールする場合、同じランタイムがすべてのハイブリッドアプリに含まれているため、保存領域を無駄に多く消費してしまう。また、ＯＳによっては、ネイティブアプリをインストールする際に必ず利用者への同意を促す画面を表示し、利用者の操作が必要となるものがある。例えば、Ａｎｄｒｏｉｄでは、アプリのインストール時に、該アプリが使用するデバイス（ＧＰＳや加速度センサなど）の使用を許可するかどうかの画面を表示し、利用者が同意ボタンを押して初めてアプリケーションプログラムをインストールすることができる。これは、悪意のあるアプリケーションプログラムをインストールすることを防ぐために、セキュリティ上有意義な方法であるが、利用者の操作が必要なため、多くのインストール操作を行うようなシステムでは使い勝手が悪くなる問題がある。一般的なハイブリッドアプリは、ネイティブアプリ形式に変換された形で配布されるため、同様の問題を抱えることになる。
【０００８】
従って、多くのハイブリッドアプリを自動インストール・実行させるようなシステムを考えたとき、保存領域の非効率な消費と利用者の操作の増加による使い勝手に課題がある。
【０００９】
開示の技術は、利用者の操作を促すことなく、かつ、アプリケーションプログラムの保存領域の消費を抑制することができる情報処理装置を提供する。
【課題を解決するための手段】
【００１０】
開示の技術の一観点によれば、複数の異なるアプリケーションプログラムに対する複数のアプリリソース及び前記複数のアプリリソースの各々に用いられるランタイムを格納する格納部と、前記複数の異なるアプリケーションプログラムに含まれる各アプリケーションプログラムの起動指示ごとに、メモリ内に前記各アプリケーションプログラムの各々に対応した複数のプロセス空間を生成するメモリ管理部と、前記ランタイムを前記複数のプロセス空間のそれぞれに読み込むランタイム読み込み部と、前記各アプリケーションプログラムに対応した各アプリリソースを、前記ランタイムが読み込まれた複数のプロセス空間のうち対応するプロセス空間に読み込むアプリリソース読み込み部と、前記複数のプロセス空間のそれぞれに読み込まれたアプリリソース及びランタイムから、前記各アプリケーションプログラムのプロセスを生成するプロセス生成部と、前記複数のプロセス空間上で生成された前記各アプリケーションプログラムのプロセスを実行するプロセス実行部と、を備え、前記ランタイムは、オペレーティングシステムが解釈及び実行可能なネイティブアプリケーションプログラムであり、前記複数のアプリケーションプログラムの各々は、前記ランタイムと、前記ランタイムが解釈可能なリソースとで構成されたハイブリッドアプリケーションプログラムであり、前記アプリケーションプログラムをダウンロードする際にユーザへの確認表示の生成処理を実行し、前記複数のアプリリソースをダウンロードする際、前記確認表示の前記生成処理を実行しない情報処理装置が提供される。
【００１１】
開示の技術によれば、利用者の操作を促すことなく、かつ、アプリケーションプログラムの保存領域の消費を抑制することができる。
【図面の簡単な説明】
【００１２】
【図１】一実施形態にかかる情報処理システムの概略図である。
【図２】一実施形態にかかる携帯端末のハードウェア構成の概略図である。
【図３】一実施形態にかかるアプリサーバのハードウェア構成の概略図である。
【図４】一実施形態にかかるアプリケーションプログラムの模式図である。
【図５】一実施形態にかかる携帯端末の機能ブロックの概略図である。
【図６】一実施形態にかかるアクセス権テーブルの模式図である。
【図７】一実施形態にかかるアプリサーバの機能ブロックの概略図である。
【図８】一実施形態にかかる携帯端末のＣＰＵによるアプリリソースのダウンロードのフローチャートである。
【図９】一実施形態にかかる携帯端末のＣＰＵによるアプリケーションの実行のフローチャートである。
【図１０】一実施形態にかかる格納部に格納されたファイルへのアクセス制限を説明するための模式図である。
【図１１】一実施形態にかかる格納部に格納されたファイルへのアクセス制限を説明するための模式図である。
【図１２】一実施形態の変形例にかかる情報処理システムの概略図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、一実施形態を説明する。
【００１４】
図１は、一実施形態にかかる情報処理システムの概略図である。
【００１５】
図１に示すように、本実施形態にかかる情報処理システムは、携帯端末１００とアプリサーバ２００を備える。携帯端末１００とアプリサーバ２００は、ネットワーク３００により相互に接続されている。携帯端末１００は、ランタイムを実行環境として、アプリリソースを実行することで、アプリケーション（アプリ）を実現する。以下、「アプリケーション（アプリ）」を、ＣＰＵ１０１がアプリケーションプログラムを実行することで実現される機能として説明する。
【００１６】
（携帯端末１００のハードウェア構成）
図２は、一実施形態にかかる携帯端末１００のハードウェア構成の概略図である。
【００１７】
本実施形態では、携帯端末１００として、例えばスマートフォンやタブレットＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などを想定している。
【００１８】
図２に示すように、本実施形態にかかる携帯端末１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、メインメモリ１０２、補助メモリ１０３、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）回路１０４、アンテナ１０５、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）１０６、タッチスクリーン１０７、各種センサ１０８を備える。
【００１９】
ＣＰＵ１０１、メインメモリ１０２、補助メモリ１０３、ＲＦ回路１０４、ＬＣＤ１０６、タッチスクリーン１０７、各種センサ１０７は、例えばバスＢ１により相互に接続されている。
【００２０】
ＣＰＵ１０１は、携帯端末１００の各種ハードウェアを制御する。さらに、ＣＰＵ１０１は、補助メモリ１０３に格納された各種プログラムを、メインメモリ１０２に読み込むとともに、該メインメモリ１０２に読み込んだ各種プログラムを実行することで、各種機能を実現する。各種機能の詳細は、後述することとする。
【００２１】
メインメモリ１０２は、ＣＰＵ１０１により実行される各種プログラムを格納する。さらに、メインメモリ１０２は、ＣＰＵ１０１のワークエリアとして使用され、ＣＰＵ１０１による処理に必要な各種データを記憶する。メインメモリ１０２としては、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを用いても良い。
【００２２】
補助メモリ１０３は、携帯端末１００を動作させる各種プログラムを格納している。各種プログラムとしては、例えば、ＣＰＵ１０１により実行されるアプリケーションプログラム１０００、アプリマネージャー１５００、鍵マネージャー１６００、これらの実行環境であるＯＳ１１００、アプリサーバ２００からダウンロードするアプリリソース１２００ａ、１２００ｂやランタイム１３００などが格納される。さらに、各種プログラムとして、アプリサーバ２００からダウンロードするアプリケーションプログラムを格納しても良い。
【００２３】
ＯＳ１１００の種類は、特に限定されるものではないが、本実施形態では、Ａｎｄｒｏｉｄ（登録商標）を使用することとする。ＯＳ１１００は、ＣＰＵ１０１により実行されることで、後述するメモリ管理部１１２、ランタイム読み込み部１１３、プロセス実行部１１７、アクセス管理部１１８を実現する。
【００２４】
ランタイム１３００は、ＯＳ１１００が直接解釈・実行可能な所謂ネイティブアプリであって、アプリリソース１２００ａ、１２００ｂと共にコンパイルされることで、所謂ハイブリッドアプリを構成する。ランタイム１３００は、ＣＰＵ１０１により実行されることで、後述するアプリリソース読み込み部１１４及びプロセス生成部１１６を実現する。さらに、ランタイム１３００は、Ｉ／Ｏドライバ１３００Ｄを含む。Ｉ／Ｏドライバ１３００Ｄは、ＣＰＵ１０１により実行されることで、後述する復号化部１１５を実現する。なお、本実施形態では、Ｉ／Ｏドライバ１３００Ｄをランタイム１３００に含めているが、本発明は、これに限定されるものではない。
【００２５】
アプリマネージャー１５００は、ランチャー１５００ａ及びダウンローダ１５００ｂを含む（図２では省略）。ランチャー１５００ａは、ＣＰＵ１０１により実行されることで、後述するアプリ起動指示受け付け部１１０及びランチャー部１１１を実現する。ダウンローダ１５００ｂは、ＣＰＵ１０１により実行されることで、後述するダウンロード部１２１を実現する。鍵マネージャー１６００は、ＣＰＵ１０１により実行されることで、鍵管理部１２０を実現する。
【００２６】
補助メモリ２０３としては、例えば、ハードディスクやフラッシュメモリ等の不揮発メモリを用いても良い。アプリリソース１２００ａ、１２００ｂ及びランタイム１３００の詳細は、後述することとする。
【００２７】
ＲＦ回路１０４は、ＣＰＵ１０１により制御され、アンテナ１０５から他の無線通信装置に高周波信号を送信する。さらに、ＲＦ回路１０４は、アンテナ１０５により受信された高周波信号をベースバンド信号に変換して、該ベースバンド信号をＣＰＵ１０１に出力する。
【００２８】
ＬＣＤ１０６は、ＣＰＵ１０１により制御され、利用者に画像情報を表示する。タッチスクリーン１０７は、ＬＣＤ１０６の表示画面に貼り付けられ、例えば利用者の指先などによる接触位置を検出する。タッチスクリーン１０７は、タッチパネルと呼ばれることもある。
【００２９】
各種センサ１０８は、それぞれＣＰＵ１０１により制御され、携帯端末１００の状態情報を取得する。センサ１０８としては、例えば、加速度センサ、ジャイロセンサ、照度センサ、地磁気センサ、傾きセンサ、加圧センサ、接近センサ、温度センサ、３Ｇ、無線ＬＡＮ、ＧＰＳモジュール、などを用いても良い。
【００３０】
（アプリサーバ２００のハードウェア構成）
図３は、一実施形態にかかるアプリサーバ２００のハードウェア構成の概略図である。
【００３１】
図３に示すように、本実施形態にかかるアプリサーバ２００は、ＣＰＵ２０１、主記憶装置２０２、システムコントローラ２０３、ネットワークコントローラ２０４、ディスクコントローラ２０５、補助記憶装置２０６を備える。
【００３２】
ＣＰＵ２０１、主記憶装置２０２、システムコントローラ２０３、ネットワークコントローラ２０４、ディスクコントローラ２０５は、例えばバスＢ２により相互に接続されている。
【００３３】
ＣＰＵ２０１は、アプリサーバ２００の各種ハードウェアを制御する。さらに、ＣＰＵ２０１は、補助記憶装置２０６に格納された各種プログラムを、主記憶装置２０２に読み込むとともに、該主記憶装置２０２に読み込んだ各種プログラムを実行することで、各種機能を実現する。各種機能の詳細は、後述することとする。
【００３４】
主記憶装置２０２は、ＣＰＵ２０１により実行される各種プログラムを格納する。さらに、主記憶装置２０２は、ＣＰＵ２０１のワークエリアとして使用され、ＣＰＵ２０１による処理に必要な各種データを格納する。主記憶装置２０２としては、例えば、ＲＡＭを用いても良い。
【００３５】
システムコントローラ２０３は、ＣＰＵ２０１及び主記憶装置２０２の双方に接続されている。システムコントローラ２０３は、ＣＰＵ２０１及び主記憶装置２０２間のデータ送信や、ＣＰＵ２０１及びバス２０８間のデータ送信を制御する。さらに、システムコントローラ２０３は、バス２０８を介して、ネットワークコントローラ２０４及びディスクコントローラ２０５に接続されている。
【００３６】
ネットワークコントローラ２０４は、ネットワーク３００を介して、携帯端末１００に接続され、携帯端末１００との間で各種データの送受信を実行する。
【００３７】
補助記憶装置２０６は、ディスクコントローラ２０５に接続されている。補助記憶装置２０６は、各種プログラムを格納している。各種プログラムとしては、例えば、ＣＰＵ２０１により実行されるアプリケーションプログラム２０００、アプリケーションプログラム２０００の実行環境であるＯＳ２１００、携帯端末１００にダウンロードされるアプリリソース１２００ａ、１２００ｂやランタイム１３００などが格納される。ＯＳ２１００が直接解釈・実行可能な形式のアプリケーションプログラム（ネイティブアプリ）を携帯端末１００にダウンロードする場合、該アプリケーションプログラム（ネイティブアプリ）を格納しても良い。補助記憶装置２０６としては、例えば、ハードディスクなどを用いても良い。
【００３８】
（アプリケーションプログラム１４００ａ、１４００ｂの構成）
ここでは、所謂ハイブリッドアプリとしてのアプリケーションプログラム１４００ａ、１４００ｂの構成を説明する。
【００３９】
図４は、一実施形態にかかるアプリケーションプログラム１４００ａ、１４００ｂの模式図であって、（ａ）（ｂ）は、互いに異なるアプリケーション用のアプリケーションプログラム１４００ａ、１４００ｂを示している。
【００４０】
図４（ａ）、（ｂ）に示すように、携帯端末１００により実行されるアプリケーションプログラム１４００ａ、１４００ｂは、所謂ハイブリッドアプリであって、アプリケーションごとに作成されるアプリリソース１２００ａ、１２００ｂと、アプリケーションに共通のランタイム１３００と、を含む。
【００４１】
アプリリソース１２００ａ、１２００ｂは、例えばアプリ開発者により開発されるプログラムファイルである。これらのアプリリソース１２００ａ、１２００ｂは、ＯＳ１１００が解釈可能な実行形式ではないため、ＯＳ１１００には単なるデータファイルとして認識される。アプリリソース１２００ａ、１２００ｂは、例えばＨＴＭＬやＪａｖａ（登録商標）ｓｃｒｉｐｔなどで記述される。
【００４２】
ランタイム１３００は、アプリリソース１２００ａ、１２００ｂを、アプリケーションプログラムとして実行するための実行環境を携帯端末１００に提供する。ランタイム１３００は、所謂ネイティブアプリであって、ＯＳ１１００が解釈可能な実行形式であるため、ＯＳ１１００にはアプリケーションプログラムとして認識される。
【００４３】
（携帯端末１００の機能ブロック）
図５は、一実施形態にかかる携帯端末１００の機能ブロックの概略図である。
【００４４】
図５に示すように、本実施形態にかかる携帯端末１００は、アプリ起動指示受け付け部１１０、ランチャー部１１１、メモリ管理部１１２、ランタイム読み込み部１１３、アプリリソース読み込み部１１４、復号化部１１５、プロセス生成部１１６、プロセス実行部１１７、アクセス管理部１１８、鍵管理部１２０、ダウンロード部１２１、格納部１２３、鍵ストア１２４を備える。
【００４５】
アプリ起動指示受け付け部１１０、ランチャー部１１１、メモリ管理部１１２、ランタイム読み込み部１１３、アプリリソース読み込み部１１４、復号化部１１５、プロセス生成部１１６、プロセス実行部１１７、アクセス管理部１１８、鍵管理部１２０、ダウンロード部１２１、格納部１２３、鍵ストア１２４は、何れもＣＰＵ１０１が、メインメモリ１０２に読み込まれた各種プログラムを実行することで実現される。
【００４６】
アプリ起動指示受付部１１０は、アプリサーバ２００からのアプリ起動指示を受け付けて、ランチャー部１１１に通知する。アプリ起動指示は、アプリリソース１２００ａ、１２００ｂを指定して、該アプリリソース１２００ａ、１２００ｂの起動を指示するものである。
【００４７】
ランチャー部１１１は、アプリ起動指示受け付け部１１０からのアプリ起動指示に基づき、指定されたアプリリソース１２００ａもしくは１２００ｂを引数として、ランタイム１３００の起動指示を出力する。さらに、ランチャー部１１１は、指定されたアプリリソース１２００ａ、１２００ｂを復号化する為の鍵を鍵管理部１２０に要求する。但し、本実施形態は、これに限定されるものではなく、例えばランチャー部１１１は、利用者によるアイコンへのタップを契機に、該アイコンに対応するアプリリソース１２００ａ、１２００ｂを引数として、ランタイム１３００の起動指示を出力しても良い。
【００４８】
メモリ管理部１１２は、ランタイム１３００の起動指示に基づき、指定されたアプリリソース１２００ａもしくは１２００ｂを実行するためのプロセス空間をメインメモリ１０２に生成する。プロセス空間とは、ＣＰＵ１０１により実行されるプログラムのプロセスごとに隔離されたセキュアなメモリ空間である。
【００４９】
ランタイム読み込み部１１３は、メモリ管理部１１２により生成されたプロセス空間に、格納部１２３に格納されたランタイム１３００を読み込む。
【００５０】
アプリリソース読み込み部１１４は、ランタイム読み込み部１１３からの指示に基づき、ランタイム１３００が読み込まれたプロセス空間に、指定されたアプリリソース１２００ａもしくは１２００ｂを読み込む。さらに、アプリリソース読み込み部１１４は、プロセス実行部１１７から指示に基づき、ランタイム１３００が読み込まれたプロセス空間に、リソースを読み込むこともある。
【００５１】
復号化部１１５は、鍵管理部１２０から引き渡される鍵を復号化する。さらに、復号化部１１５は、ランタイム１３００の一部として動作して、プロセス空間に読み込まれたアプリリソース１２００ａもしくは１２００ｂを、復号化された鍵を用いて、プロセス空間の内部で復号化する。
【００５２】
プロセス生成部１１６は、プロセス空間に読み込まれたアプリリソース１２００ａもしくは１２００ｂ及びランタイム１３００を一体化してコンパイルすることで、アプリケーションプログラム１４００ａもしくは１４００ｂのプロセスを生成する。
【００５３】
プロセス実行部１１７は、プロセス空間に生成されたアプリケーションプログラム１４００ａもしくは１４００ｂのプロセスを実行する。さらに、プロセス実行部１１７は、プロセスの実行時に必要なリソースの読み込みを、プロセス実行中にアプリリソース読み込み部１１４に指示することもある。
【００５４】
アクセス管理部１１８は、アクセス権テーブルＴのアクセス権に基づき、プロセス実行部１１７もしくはアプリリソース読み込み部１１４によるファイルアクセスを許可もしくは制限する。ファイルアクセスとは、格納部１２３に格納されたアプリリソース１２００ａ、１２００ｂ及び各種アプリケーションプログラムへの読み込み／書き込み／実行の何れかである。
【００５５】
鍵管理部１２０は、ランチャー部１１１からの要求に基づき、アプリリソース１２００ａもしくは１２００ｂを復号化する為の鍵を鍵ストア１２４から取得する。鍵ストア１２４から取得された鍵は、鍵管理部１２０に保管される。さらに、鍵管理部１２０は、例えば携帯端末１００に固有の情報を基に生成した鍵などを用いて、鍵ストア１２４から取得した鍵を暗号化して復号化部１１５に引き渡す。なお、鍵の引き渡しには、例えばＯＳ１１００により提供されるプロセス間通信の機能を利用しても良い。本実施形態では、ＯＳ１１００としてＡｎｄｒｏｉｄを利用しているので、例えばＡｎｄｒｏｉｄのＩｎｔｅｎｔ機能を利用しても良い。
【００５６】
ダウンロード部１２１は、アプリサーバ２００から送信されるアプリリソース１２００ａもしくは１２００ｂを、送受信部１２２から受け取り、格納部１２３のデータ領域Ｒｄに配置する。さらに、ダウンロード部１２１は、アプリリソース１２００ａ、１２００ｂの他に、例えばアプリサーバ２００に格納された、ネイティブアプリとしてのランタイムやアプリケーションプログラムなどを、送受信部１２２から受け取り、格納部１２３に配置しても良い。但し、ネイティブアプリとしてのランタイムやアプリケーションプログラムなどは、格納部１２３のデータ領域Ｒｄとは異なるアプリ領域に格納される。
【００５７】
なお、アプリサーバ２００からアプリリソース１２００ａ、１２００ｂのＵＲＬ１７００が送信された場合、ダウンロード部１２１は、アプリリソース１２００ａ、１２００ｂの送信依頼の送信を送受信部１２２に指示しても良い。
【００５８】
送受信部１２２は、アプリサーバ２００から送信された、暗号化されたアプリリソース１２００ａを受信する。なお、アプリサーバ２００からアプリリソース１２００ａ、１２００ｂのＵＲＬ１７００が送信された場合、送受信部１２２は、ダウンロード部１２１からの指示に基づき、ＵＲＬ１７００により指定されたアプリリソース１２００ａ、１２００ｂの送信依頼をアプリサーバ２００に送信する。トークンがある場合は、送受信部１２２は、トークンを付加情報として付けて送信しても良い。
【００５９】
格納部１２３は、例えば携帯端末１００の補助メモリ１０３に構築される。格納部１２３は、例えばアプリケーションプログラム１０００、ＯＳ１１００、アプリリソース１２００ａ、１２００ｂ、ランタイム１３００などを格納する。さらに、格納部１２３に格納されるファイルには、ＯＳ１１００が提供するアクセス権が設定される。
【００６０】
鍵ストア１２４は、例えば携帯端末１００の補助メモリ１０３に構築される。鍵ストア１２４は、アプリリソース１２００ａ、１２００ｂを復号化する為の鍵を格納する。鍵ストア１２４内に保存される鍵は、ハードウェアの機能などを使って、他のデータに比べて安全に保護されていることが望ましい。例えば、ＡＲＭが持つＴＲＵＳＴＺＯＮＥ機能を用いることにより、悪意のあるソフトウェアが鍵を取り出せないようにすることができる。
【００６１】
なお、本実施形態では、鍵ストア１２４を補助メモリ１０３に構築しているが、本発明は、これに限定されるものではない。例えば、アプリリソース１２００ａもしくは１２００ｂが格納される補助メモリ１０３とは別個にメモリチップを容易して、該メモリチップに鍵ストア１２４を構築しても良い。
【００６２】
（アクセス権テーブルＴ）
ここでは、ＯＳ１１００がアプリケーションプログラムに設定するアクセス権を説明する。
【００６３】
図６は、一実施形態にかかるアクセス権テーブルＴの模式図である。
【００６４】
図６に示すように、本実施形態にかかるアクセス権テーブルＴは、アプリケーションプログラムのＵｓｅｒＩＤと、アプリケーションプログラムへのアクセス権（アクセスコントロール）と、を紐づける。本実施形態では、ＯＳ１１００としてＡｎｄｒｏｉｄを使用しているので、ＵｓｅｒＩＤには、アプリケーションの名前（「Ｒｕｎｔｉｍｅ」や「Ａｐｐ」など）に紐づけられた一意な名前が割り当てられている。例えば、「Ｒｕｎｔｉｍｅ」には「ａｐｐ−１２３４５」が、「Ａｐｐ」には「ａｐｐｐ−６７８９０」という名前が割り当てられているとする。なお、図中の「ｒ」、「ｗ」、「ｘ」は、それぞれ読み込み可能、書き込み可能、実行可能を示している。
【００６５】
例えば、アクセス権テーブルＴの枠Ｗに着目すると、ＵｓｅｒＩＤが「ａｐｐ−１２３４５」であるアプリケーションプログラム、即ちランタイム１３００には、Ｕｓｅｒ（所有者）のアクセス権として、「ｒ」、「ｗ」、「ｘ」が割り当てられている。従って、ランタイム１３００のＵｓｅｒであれば、即ちランタイム１３００のプロセスであれば、格納部１２３に格納されたランタイム１３００への読み込み／書き込み／実行の何れのアクセスも許可されることとなる。
【００６６】
（アプリサーバ２００の機能ブロック）
図７は、一実施形態にかかるアプリサーバ２００の機能ブロックの概略図である。
【００６７】
図７に示すように、本実施形態にかかるアプリサーバ２００は、アプリ受付部２１１、アプリ鍵生成部２１２、アプリ暗号化部２１３、アプリ配置部２１４、鍵暗号化部２１５、プッシュ制御部２１６、送受信部２１７、格納部２１８を備える。
【００６８】
アプリ受付部２１１、アプリ鍵生成部２１２、アプリ暗号化部２１３、アプリ配置部２１４、鍵暗号化部２１５、プッシュ制御部２１６、送受信部２１７は、何れもＣＰＵ２０１が、主記憶装置２０２に読み込まれた各種プログラムを実行することで実現される。
【００６９】
アプリ受付部２１１は、例えばアプリ開発者により開発されたアプリリソース１２００ａ、１２００ｂの登録を受け付ける。アプリ受付部２１１は、アプリリソースの他に、ネイティブアプリとしてのアプリケーションプログラムの登録を受け付けても良い。
【００７０】
アプリ鍵生成部２１２は、指定されたアプリリソース１２００ａ、１２００ｂを暗号化する為の鍵を生成する。鍵は、アプリリソース１２００ａ、１２００ｂ及び送信先の携帯端末１００に固有の情報に基づいて生成され、個々のアプリケーションと送信先の携帯端末１００ごとに固有の鍵となる。暗号化の方式は、特に限定されるものではない。
【００７１】
アプリ暗号化部２１３は、アプリ鍵生成部２１２により生成された鍵を用いて、アプリリソース１２００ａ、１２００ｂを暗号化する。
【００７２】
アプリ配置部２１４は、アプリ暗号化部２１３により暗号化されたアプリリソース１２００ａ、１２００ｂを格納部２１８に配置する。
【００７３】
鍵暗号化部２１５は、携帯端末１００に固有の情報を基に生成した鍵を用いて、アプリリソース１２００ａ、１２００ｂを暗号化する為の鍵そのものを暗号化する。
【００７４】
プッシュ制御部２１６は、例えば携帯端末１００のセンサから取得した位置情報やコンテキスト情報などに基づき、アプリリソース１２００ａ、１２００ｂもしくは該アプリリソース１２００ａ、１２００ｂのＵＲＬ１７００と、アプリ鍵生成部２１２で生成した鍵の送信を送受信部２１７に指示する。さらに、付加情報として、指定されたアプリケーションを取得するためのトークン情報を付加しても良い。
【００７５】
送受信部２１７は、例えばプッシュ制御部２１６からの指示に基づき、格納部２１８に格納されたＵＲＬ１７００もしくはアプリリソース１２００ａ、１２００ｂと、これらを復号化する為の鍵を携帯端末１００に送信する。
【００７６】
格納部２１８は、例えばアプリサーバ２００の補助記憶装置２０６に構築される。格納部２１８は、例えばアプリケーションプログラム２０００、ＯＳ２１００、アプリリソース１２００ａ、１２００ｂなどを格納する。さらに、格納部２１８は、ランタイム１３００を格納しても良い。
【００７７】
（携帯端末１００のＣＰＵ１０１によるアプリリソースのダウンロード）
図８は、一実施形態にかかる携帯端末１００のＣＰＵ１０１によるアプリリソース１２００ａ、１２００ｂのダウンロードのフローチャートである。
【００７８】
図８に示すように、送受信部１２２は、アプリサーバ２００から送信されたアプリケーションのＵＲＬ１７００を受信したかどうか判断する（ステップＳ１２１）。
【００７９】
ここで、アプリケーションのＵＲＬ１７００を受信したと判断されたら（ステップＳ１２１のＹｅｓ）、ダウンロード部１２１は、該ＵＲＬ１７００により指定されるアプリリソース（ここでは、アプリリソース１２００ａとする）のダウンロード要求の送信を、送受信部１２２に指示する（ステップＳ１２２）。
【００８０】
一方、アプリケーションのＵＲＬ１７００を受信したと判断されなければ（ステップＳ１２１のＮｏ）、送受信部１２２は、アプリケーションのＵＲＬ１７００を受信したかどうかの判断を継続する（ステップＳ１２１）。
【００８１】
なお、アプリサーバ２００は、アプリケーションのＵＲＬ１００の送信と同時に、アプリリソース１２００ａを複合化する為の鍵も送信する。送受信部１２２は、アプリサーバ２００から送信された鍵を、鍵管理部１２０に引き渡す。そして、鍵管理部１２０は、送受信部１２２から引き渡された鍵を鍵ストア１２４に格納する（ステップＳ１２６）。このとき、鍵管理部１２０は、携帯端末１００に固有の鍵を用いて、アプリサーバ２００から引き渡された鍵を復号化してから、鍵ストア１２４に格納する。
【００８２】
次に、送受信部１２２は、ダウンロード部１２１からのダウンロード要求に基づき、指定されたアプリリソース１２００ａの送信依頼をアプリサーバ２００に送信する（ステップＳ１２３）。トークンがある場合、トークンも付加情報として付けて送信しても良い。これにより、アプリサーバ２００は、指定されたアプリリソース１２００ａを、携帯端末１００に送信する。
【００８３】
なお、アプリサーバ２００から送信されるアプリリソース１２００ａは、アプリリソース１２００ａ及び携帯端末１００に固有の鍵で暗号化されている。このため、携帯端末１００の送受信部１２２は、暗号化されたアプリリソース１２００ａを受け取ることとなる（ステップＳ１２４）。そして、送受信部１２２は、アプリリソース１２００ａをダウンロード部１２１に引き渡す。
【００８４】
次に、ダウンロード部１２１は、送受信部１２２から引き渡されたアプリリソース１２００ａを格納部１２３に格納する（ステップＳ１２５）。このとき、携帯端末１００は、アプリリソース１２００ａを、単なるデータファイルと認識するため、格納部１２３のデータ領域Ｒｄに配置することとなる。
【００８５】
但し、それぞれのデータファイルには、ランタイム１３００をＵｓｅｒ（所有者）とするアクセス権を設定する。このため、ランタイム１３００のプロセスでなければ、格納部１２３のデータ領域Ｒｄに格納されたデータファイルにアクセスすることができない。逆に言えば、ランタイム１３００のプロセスであれば、如何なるプロセスであっても、格納部１２３のデータ領域Ｒｄに格納されたデータファイルにアクセスすることができる。
【００８６】
以上でアプリリソース１２００ａのダウンロードが終了する。
【００８７】
アプリリソースのダウンロードは、アプリケーションの実行指示のたびに実施される。このため、例えばアプリリソース１２００ａのダウンロード後、さらに他のアプリケーション（ここでは、アプリリソース１２００ｂのアプリケーションとする）の実行指示が行われた場合、同様の手順を経て、格納部１２３にアプリリソース１２００ｂが格納される。このときも、アプリリソース１２００ｂは、単なるデータファイルとして認識されるため、アプリリソース１２００ａが格納されているデータ領域Ｒｄに格納されることとなる。
【００８８】
以上のように、本実施形態にかかる携帯端末１００では、アプリサーバ２００から複数のアプリリソース１２００ａ、１２００ｂをダウンロードする場合、全てのアプリリソース１２００ａ、１２００ｂが、データファイルとして共通のデータ領域Ｒｄに格納され、それぞれのデータファイルにランタイム１３００をＵｓｅｒ（所有者）とするアクセス権が設定されることとなる。
【００８９】
なお、ここでは、アプリサーバ２００から送信されたアプリケーションのＵＲＬ１７００に基づき、携帯端末１００がアプリサーバ２００にダウンロード要求を送信しているが、本発明は、これに限定されるものではない。例えば、携帯端末１００のセンサから取得した位置情報やコンテキスト情報などに基づき、アプリサーバ２００が必要と判断したアプリリソース１２００ａ、１２００ｂを携帯端末１００に送信しても良い。即ち、アプリサーバ２００の判断に基づき、必要なアプリリソース１２００ａ、１２００ｂが携帯端末１００に送信される場合、前述のステップＳ１２１〜ステップ１２４が省略されることとなる。
【００９０】
（携帯端末１００のＣＰＵ１０１によるアプリケーションの実行）
図９は、一実施形態にかかる携帯端末１００のＣＰＵ１０１によるアプリケーションの実行のフローチャートである。図１０は、一実施形態にかかる格納部１２３に格納されたファイルへのアクセス制限を説明するための模式図である。図１１は、一実施形態にかかる格納部１２３に格納されたファイルへのアクセス制限を説明するための模式図である。
【００９１】
以下の説明は、携帯端末１００の格納部１２３にアプリリソース１２００ａ、１２００ｂ及びランタイム１３００が格納されていることを想定する。
【００９２】
図９に示すように、先ず、アプリ起動指示受付部１１０は、例えばアプリサーバ２００から送信されたアプリケーション（ここでは、アプリリソース１２００ａのアプリケーションとする）の起動指示を受け付けたかどうか判断する（ステップＳ１０１）。アプリサーバ２００からアプリリソース１２００ａが送信されるときに、アプリケーションの起動指示を受け付けたと判断しても良い。
【００９３】
ここで、アプリケーションの起動指示を受け付けたと判断されたら（ステップＳ１０１のＹｅｓ）、アプリ起動指示受付部１１０は、ランチャー部１１１にアプリ実行指示を出力する（ステップＳ１０２）。
【００９４】
一方、アプリケーションの起動指示を受け付けたと判断しなければ（ステップＳ１０１のＮｏ）、アプリ起動指示受付部１１０は、アプリケーションの起動指示を受け付けたかどうかの判断を継続する（ステップＳ１０１）。
【００９５】
次に、ランチャー部１１１は、アプリ起動指示受付部１１０からのアプリ実行指示に基づき、指定されたアプリリソース１２００ａのファイル名を引数として、ランタイム１３００の起動指示を出力する（ステップＳ１０３）。
【００９６】
さらに、ランチャー部１１１は、指定されたアプリリソース１２００ａを復号化する為の鍵を鍵管理部１２０に要求する（ステップＳ１０７）。
【００９７】
次に、メモリ管理部１１２は、ランタイム１３００及びアプリリソース１２００ａを実行するためのプロセス空間Ｍ１をメインメモリ１０２に生成する（ステップＳ１０４）。
【００９８】
次に、ランタイム読み込み部１１３は、メモリ管理部１１２により生成されたプロセス空間Ｍ１に、格納部１２３に格納されたランタイム１３００を読み込む（ステップＳ１０５）。これにより、プロセス空間Ｍ１にランタイム１３００のプロセスが生成される。
【００９９】
次に、アプリリソース読み込み部１１４は、ランタイム１３００が読み込まれたプロセス空間Ｍ１に、さらにアプリリソース１２００ａを読み込む（ステップＳ１０６）。
【０１００】
そして、これらと並行して、鍵管理部１２０は、ランチャー部１１１からの要求に基づき、アプリリソース１２００ａを復号化する為の鍵を鍵ストア１２４から取得する（ステップＳ１０８）。さらに、鍵管理部１２０は、鍵ストア１２４から取得した鍵を暗号化する。暗号化された鍵は、例えばＯＳ１１００のプロセス間通信の機能を利用して、復号化部１１５に引き渡される。暗号化の方式は、特に限定されるものではない。
【０１０１】
次に、復号化部１１５は、鍵管理部１２０から引き渡された鍵を復号化するとともに（ステップＳ１０９）、復号化された鍵を用いて、プロセス空間Ｍ１に読み込まれたアプリリソース１２００ａを復号化する（ステップＳ１１０）。即ち、アプリリソース１２００ａは、プロセス空間Ｍ１に読み込まれた後に復号化（平文化）される。
【０１０２】
次に、プロセス生成部１１６は、復号化部１１５により復号化されたアプリリソース１２００ａ及びランタイム１３００を一体化してコンパイルすることで、プロセス空間Ｍ１に、アプリケーションプログラム１４００ａのプロセスＰ１を生成する（ステップＳ１１１）。
【０１０３】
プロセスＰ１は、アプリリソース１２００ａ及びランタイム１３００により構成されるハイブリッドアプリとしてのアプリケーションプログラム１４００ａのプロセスである。しかし、ＯＳ１１００は、アプリリソース１２００ａを単なるデータとして認識するため、プロセスＰ１をランタイム１３００のプロセスであると認識する。
【０１０４】
次に、プロセス実行部１１７は、アプリケーションプログラム１４００ａのプロセスＰ１を実行する（ステップＳ１１２）。
【０１０５】
次に、アクセス管理部１１８は、プロセス実行部１１７により実行されるプロセスＰ１が、格納部１２３に格納されたファイルへのアクセスを伴うものか判断する（ステップＳ１１３）。
【０１０６】
ここで、プロセスＰ１がアプリリソース（例えばアイコン画像など）へのアクセスを伴うものであると判断されたら（ステップＳ１１３のＹｅｓ）、アクセス管理部１１８は、アクセス権テーブルＴのアクセス権を参照して、ファイルへのアクセスを許可するかどうか判断する（ステップＳ１１４）。
【０１０７】
一方、プロセスＰ１がアプリリソースへのアクセスを伴うものであると判断されなければ（ステップＳ１１３のＮｏ）、プロセス実行部１１７は、アプリケーションプログラム１４００ａのプロセスＰ１の実行を継続する（ステップＳ１１２）。
【０１０８】
プロセスＰ１がアプリリソースへのアクセスを伴うものであると判断され（ステップＳ１１３のＹｅｓ）、かつ、アプリリソースへのアクセスを許可すると判断された場合（ステップＳ１１４のＹｅｓ）、プロセス実行部１１７は、アプリリソースへのアクセス、例えば格納部１２３に格納されたアプリリソースへの読み込み／書き込み／実行の何れかを実行する（ステップＳ１１５）。
【０１０９】
本実施形態にかかる携帯端末１００は、アプリケーションの実行ごとに、以上の一連の処理を実施する。このため、例えばアプリケーションプログラム１４００ａのプロセスＰ１の生成後に、別のアプリケーション（ここでは、アプリリソース１２００ｂのアプリケーションとする）が実行された場合、さらにアプリケーションプログラム１４００ｂのプロセスＰ２が生成される。しかも、アプリケーションプログラム１４００ａ、１４００ｂのプロセスＰ１、Ｐ２は、何れもランタイム１３００のプロセスと認識される。
【０１１０】
従って、プロセスＰ１及びプロセスＰ２は、図１０に矢印Ａで示すように、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａ、１２００ｂの双方へのアクセスが許可される。これを放置すると、例えばプロセスＰ１が悪意のあるプロセスである場合、該プロセスＰ１が、格納部１２３に格納されたアプリリソース１２００ｂに不正アクセスして、該アプリリソース１２００ｂを改竄するようなことも起こり得る。
【０１１１】
そこで、本実施形態では、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａ、１２００ｂを、互いに異なる鍵で別個に暗号化している。しかも、プロセスＰ１は、自身のアプリリソース１２００ａを復号化する為の鍵しか持たず、プロセスＰ２は、自身のアプリリソース１２００ｂを復号化する為の鍵しか持たない。
【０１１２】
このため、プロセスＰ１は、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ｂへの読み込み／書き込み／実行の何れも行うことができない。同様に、プロセス２は、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａへの読み込み／書き込み／実行の何れも行うことができない。
【０１１３】
これにより、携帯端末１００にダウンロードしたアプリリソースが、携帯端末１００内で悪意ある動作をするものであっても、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａ、１２００ｂを、例えば不正アクセスなどの脅威から保護することができる。
【０１１４】
また、アプリリソース読み込み部１１４は、ランタイム１３００のプロセスとして、アプリリソース１２００ａ、１２００ｂの読み込みを実行する。このため、ランタイム１３００のプロセスは、図１１に矢印Ｂで示すように、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａ、１２００ｂの双方へのアクセスが許可される。
【０１１５】
ところが、本実施形態では、前述のように、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａ、１２００ｂを、互いに異なる鍵で別個に暗号化している。しかも、ランタイム１３００のプロセスは、指定されたアプリリソース１２００ａもしくは１２００ｂを復号化する為の鍵しか持たない。
【０１１６】
このため、アプリリソース１２００ａを引数として起動されたランタイム１３００のプロセスは、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ｂへの読み込みを行うことができない。同様に、アプリリソース１２００ｂを引数として起動されたランタイム１３００のプロセスは、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａへの読み込みを行うことができない。
【０１１７】
これにより、携帯端末１００がアプリケーションプログラム１４００ａを実行しようとしたときに、ランタイム１３００のプロセスが、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ｂを読み込むことがない。逆に、携帯端末１００がアプリケーションプログラム１４００ｂを実行しようとしたときに、ランタイム１３００のプロセスが、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａを読み込むことがない。即ち、本実施形態にかかる携帯端末１００は、指定されたアプリケーションを、確実に実行することができる。
【０１１８】
本実施形態によれば、アプリサーバ２００からアプリリソース１２００ａ、１２００ｂをダウンロードして、携帯端末１００にプレインストールされたランタイム１３００上で実行することで、アプリケーションプログラム１４００ａ、１４００ｂのプロセスＰ１、Ｐ２を生成している。
【０１１９】
このため、アプリサーバ２００からダウンロードするデータ量を、ランタイム１３００の分量だけ削減することができる。しかも、携帯端末１００は、アプリリソース１２００ａ、１２００ｂをアプリケーションプログラムとして認識しないので、アプリリソース１２００ａ、１２００ｂをダウンロードする際に、携帯端末１００の利用者への確認表示（同意ボタンなど）が発生することがない。従って、携帯端末１００の利用者への煩わしさ感の低減と、携帯端末１００の保存領域の非効率な消費と、を実現することができる。
【０１２０】
さらに、本実施形態によれば、アプリリソース１２００ａ、１２００ｂを実行するたびに、互いに隔離されたプロセス空間Ｍ１、Ｍ２を生成して、それぞれのプロセス空間Ｍ１、Ｍ２にランタイム１３００及びアプリリソース１２００ａ、１２００ｂを１つずつ読み込む。即ち、プロセス空間Ｍ１、Ｍ２に複数のアプリリソース１２００ａ、１２００ｂが読み込まれることがない。このため、複数のアプリリソース１２００ａ、１２００ｂ同士がプロセス空間Ｍ１、Ｍ２内で干渉することがない。
【０１２１】
また、本実施形態によれば、格納部１２３のデータ領域Ｒｄに格納されたアプリリソース１２００ａ、１２００ｂを、互いに異なる鍵で別個に暗号化している。しかも、それぞれのプロセスＰ１、Ｐ２は、自身のアプリリソース１２００ａ、１２００ｂを復号化する為の鍵しか与えられない。このため、プロセスＰ１、Ｐ２は、格納部１２３のデータ領域Ｒｄに格納されたアプリリソースのうち、自身のアプリリソースしかアクセスすることができない。これにより、携帯端末１００の格納部１２３に格納されたアプリリソース１２００ａ、１２００ｂを、例えば悪意あるアプリリソースに起因する不正アクセスなどの脅威から保護することができる。
【０１２２】
しかも、ランタイム１３００により実現されるアプリリソース読み込み部１１４、復号化部１１５、プロセス生成部１１６と、アプリマネージャー１５００により実現されるランチャー部１１１及びダウンロード部１２１と、鍵マネージャー１６００により実現される鍵管理部１２０と、を追加するだけで（即ち、既存のＯＳ１１００を利用したまま）、前述の機能を得ることができる。
【０１２３】
（変形例）
図１２は、一実施形態の変形例にかかる情報処理システムの概略図である。
【０１２４】
前述の実施形態では、アプリサーバ２００がアプリリソースを格納する機能及びアプリリソースをプッシュする機能を備えていたが、本発明は、これに限定されるものではない。
【０１２５】
例えば、図１２に示すように、アプリサーバ２００の代わりに、アプリリソースを格納する機能及びアプリリソースをプッシュする機能を備えていないアプリサーバ２００Ａを用いても良い。この場合、アプリリソースを格納する格納部２１８を備えるアプリストア４００と、アプリリソースのプッシュを制御するプッシュ制御部２１６を備えるプッシュサーバ５００と、を別途に用意して、それぞれネットワーク３００で接続すれば良い。
【符号の説明】
【０１２６】
１００：  携帯端末（情報処理装置）
１０２：  メインメモリ（メモリ）
１１２：  メモリ管理部
１１３：  ランタイム読み込み部
１１４：  アプリリソース読み込み部
１１５：  復号化部
１１６：  プロセス生成部
１１７：  プロセス実行部
１２０：  鍵管理部
１２３：  格納部
１２４：  鍵ストア
２００：  アプリサーバ
２００Ａ：  アプリサーバ
３００：  ネットワーク
４００：  アプリストア
５００：  プッシュサーバ
Ｍ１：  プロセス空間
Ｍ２：  プロセス空間
Ｐ１：  プロセス
Ｐ２：  プロセス
１２００ａ：  アプリリソース
１２００ｂ：  アプリリソース
１３００：  ランタイム
【図１】
2018097898.tif 000003
【図２】
2018097898.tif 000004
【図３】
2018097898.tif 000005
【図４】
2018097898.tif 000006
【図５】
2018097898.tif 000007
【図６】
2018097898.tif 000008
【図７】
2018097898.tif 000009
【図８】
2018097898.tif 000010
【図９】
2018097898.tif 000011
【図１０】
2018097898.tif 000012
【図１１】
2018097898.tif 000013
【図１２】
2018097898.tif 000014