プログラム起動制御方法、プログラム起動制御プログラム、携帯端末、ネットワークシステム
【課題】携帯端末上で動作するアプリケーションプログラムを安全に実行することのできる技術手法を提供する。
【解決手段】本発明に係るアプリケーション起動制御方法は、アプリケーションプログラム本体から取得した属性情報と、携帯端末があらかじめ保持しているアプリケーションプログラムの属性情報とを比較し、両者が合致すればアプリケーションプログラムの起動を許可する。
【解決手段】本発明に係るアプリケーション起動制御方法は、アプリケーションプログラム本体から取得した属性情報と、携帯端末があらかじめ保持しているアプリケーションプログラムの属性情報とを比較し、両者が合致すればアプリケーションプログラムの起動を許可する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末上で動作するアプリケーションプログラムの起動制御に関するものである。
【背景技術】
【０００２】
従来、アプリケーションプログラムが不正に改変されたことを検出するための様々な手法が開発されている。下記特許文献１には、アプリケーションプログラムを実行する時に、アプリケーションに内蔵されているチェック機構により、アプリケーションが不正に変更されているか否かをチェックする技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】平４−１４９７５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記特許文献１は、外部と接続されていない閉じた環境下にある端末上で動作するアプリケーションのセキュリティを確保することを目的としている。一方現在では、ネットワーク環境が整備され、アプリケーションを実行する端末として、パソコンの他にも携帯端末が広く使用されている。
【０００５】
アプリケーションを実行する端末がネットワークに接続された環境下では、ネットワークを経由してアプリケーションを配布する場合がある。このとき、ネットワーク経由でアプリケーションをダウンロードする手軽さゆえに、コンピュータウイルスによる被害やアプリケーションプログラムの不正書き換えなどのセキュリティ被害につながる可能性がある。特に携帯端末のセキュリティ対策は、パソコンやサーバなどの一般コンピュータと比較して遅れる傾向があるため、安全性を高めることのできる有用な手法が望まれる。
【０００６】
本発明は、上記のような課題を解決するためになされたものであり、携帯端末上で動作するアプリケーションプログラムを安全に実行することのできる技術手法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るアプリケーション起動制御方法は、アプリケーションプログラム本体から取得した属性情報と、携帯端末があらかじめ保持しているアプリケーションプログラムの属性情報とを比較し、両者が合致すればアプリケーションプログラムの起動を許可する。
【発明の効果】
【０００８】
本発明に係るアプリケーション起動制御方法によれば、アプリケーションプログラムが不正に書き換えられている場合、属性情報があらかじめ保持しているものと異なっていることが分かる。これにより、不正な書き換えがあったことを検出することができるので、アプリケーションプログラムを安全に起動することができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態１に係るネットワークシステム１０００の構成図である。
【図２】サーバ２００の機能ブロック図である。
【図３】携帯端末１００の機能ブロック図である。
【図４】携帯端末１００が保持するアプリケーションメタ情報データ１４３の構成とデータ例を示す図である。
【図５】サーバ２００が保持するアプリケーションメタ情報データベース２２０の構成とデータ例を示す図である。
【図６】管理端末４００からサーバ２００にアプリケーションプログラムを登録する手順を説明する図である。
【図７】携帯端末１００上でアプリケーションプログラム１４１を起動する際の動作手順を示す図である。
【図８】アプリケーション起動制御部１４２が提供する、アプリケーションプログラム１４１を起動するための操作画面イメージを示す図である。
【図９】携帯端末１００上でアプリケーションプログラム１４１を起動する際に最新バージョンであるか否かをチェックする動作手順を示す図である。
【図１０】実施形態３において携帯端末１００上でアプリケーション１４１を起動する手順を説明する図である。
【発明を実施するための形態】
【００１０】
＜実施の形態１＞
図１は、本発明の実施形態１に係るネットワークシステム１０００の構成図である。ネットワークシステム１０００は、携帯端末１００、サーバ２００、基地局３００、管理端末４００を有する。サーバ２００、基地局３００、管理端末４００は、ネットワーク５００を介して接続されている。携帯端末１００は、無線通信回線を介して基地局３００に接続し、さらに基地局３００を介してネットワーク５００に接続されている。
【００１１】
携帯端末１００は、ユーザが携帯する端末であり、１以上のアプリケーションプログラムを内部の記憶装置に記憶し、これを実行するように構成されている。携帯端末１００の構成は、後述の図３で改めて説明する。携帯端末１００の例として、携帯電話、ＰＤＡ（Ｐｏｒｔａｂｌｅ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）端末、などが挙げられる。
【００１２】
サーバ２００は、携帯端末１００が実行するアプリケーションプログラムを保持するサーバ装置であり、アプリケーションファイル２１０、アプリケーションメタ情報データベース２２０を備える。サーバ２００のその他の詳細構成については、後述の図２で改めて説明する。
【００１３】
アプリケーションファイル２１０は、携帯端末１００が実行するアプリケーションプログラムのプログラムファイルである。アプリケーションファイル２１０は、少なくとも携帯端末１００が実行するアプリケーションプログラムの最新バージョンのプログラムファイルを保持する。古いバージョンのプログラムファイルを併せて保持しておいてもよい。アプリケーションメタ情報データベース２２０については後述の図５で改めて説明する。
【００１４】
管理端末４００は、携帯端末１００が実行するアプリケーションプログラムをサーバ２００にアップロードするなどの管理作業を実施するための端末である。オペレータは、管理端末４００を用いてアプリケーションプログラムをサーバ２００に新規登録する、最新バージョンに更新する、などの管理作業を実施する。
【００１５】
図２は、サーバ２００の機能ブロック図である。サーバ２００は、アプリケーションファイル２１０、アプリケーションメタ情報データベース２２０の他、中央演算部２３０、主記憶部２４０、送受信部２５０、記憶部２６０を備える。アプリケーションファイル２１０、アプリケーションメタ情報データベース２２０は、サーバ２００の外部に接続されている記憶装置に格納してもよいし、記憶部２６０内に格納してもよい。ここではサーバ２００の外部記憶装置に格納されている例を示した。
【００１６】
中央演算部２３０は、サーバ２００が備えるプログラムを実行する。ここでは後述するＡＰ更新部２６１と検索処理部２６２をプログラムとして構成し、これらを実行するものとするが、これら以外のプログラムを実行することもできる。
【００１７】
主記憶部２４０は、中央演算部２３０がプログラムを実行する際に使用するデータ等を一時的に記憶する。送受信部２５０は、サーバ２００とネットワーク５００を接続するネットワークインターフェースである。
【００１８】
記憶部２６０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶装置で構成されており、ＡＰ更新部２６１、検索処理部２６２を格納している。ＡＰ更新部２６１は、管理端末４００からアプリケーションプログラムを受け取ってＡＰファイル２１０として格納する処理を実行するプログラムである。検索処理部２６２は、アプリケーションメタ情報データベース２２０内のレコードを検索する処理を実行するプログラムである。
【００１９】
図３は、携帯端末１００の機能ブロック図である。携帯端末１００は、中央演算部１１０、主記憶部１２０、送受信部１３０、記憶部１４０を備える。また、無線通信回線を介して基地局３００と通信するアンテナ、送受信回路などの構成を適宜備える。
【００２０】
中央演算部１１０は、携帯端末１００が備えるプログラムを実行する。ここでは後述するアプリケーション１４１とアプリケーション起動制御部１４２をプログラムとして構成し、これらを実行するものとするが、これら以外のプログラムを実行することもできる。
【００２１】
主記憶部１２０は、中央演算部１１０がプログラムを実行する際に使用するデータ等を一時的に記憶する。送受信部１３０は、アンテナ等を介して携帯端末１００と基地局３００を接続するネットワークインターフェースである。
【００２２】
記憶部１４０は、ＨＤＤなどの記憶装置で構成されており、アプリケーションプログラム１４１、アプリケーション起動制御部１４２、アプリケーションメタ情報データ１４３を格納している。
【００２３】
アプリケーションプログラム１４１は、携帯端末１００のユーザが使用するアプリケーション機能を提供するプログラムである。例えば、顧客情報検索プログラム、商品管理プログラム、スケジュール管理プログラム、電子メールクライアントプログラム、などのプログラムが挙げられる。説明の便宜上、１以上のアプリケーションプログラムを総称してアプリケーションプログラム１４１と呼称するが、アプリケーションプログラム１４１の個数は任意でよい。
【００２４】
アプリケーション起動制御部１４２は、アプリケーションプログラム１４１の起動を制御する機能部である。携帯端末１００のユーザがアプリケーションプログラム１４１を起動しようとするとき、アプリケーション起動制御部１４２はその起動指示を受け取り、後述する判定基準にしたがって当該アプリケーション起動プログラム１４１を起動してよいか否かを判定する。判定基準に合致しない場合、ユーザはそのアプリケーションプログラム１４１を起動することができない。
【００２５】
アプリケーション起動制御部１４２は、ＡＰ自動更新チェック部１４２１、ＡＰメタ情報チェック部１４２２、端末情報チェック部１４２３を備える。これらの機能部は、アプリケーション起動制御部１４２の一部として一体的に構成することもできるし、アプリケーション起動制御部１４２と連動する別のプログラムモジュールとして構成することもできる。これらの機能部の詳細については、後述の図７で改めて説明する。
【００２６】
アプリケーションメタ情報データ１４３は、各アプリケーションプログラム１４１の属性情報を記述したデータである。アプリケーションメタ情報データ１４３の例については後述する図４で改めて説明する。
【００２７】
図４は、携帯端末１００が保持するアプリケーションメタ情報データ１４３の構成とデータ例を示す図である。アプリケーションメタ情報データ１４３は、アプリケーションプログラム１４１の属性情報を携帯端末１００側で保持するためのデータファイルであり、アプリケーションＩＤフィールド１４３１、バージョンフィールド１４３２、サイズフィールド１４３３、更新日時フィールド１４３４、アプリケーション名称フィールド１４３５を有する。
【００２８】
アプリケーションＩＤフィールド１４３１は、個々のアプリケーションプログラム１４１を識別するための識別情報を保持する。
【００２９】
バージョンフィールド１４３２は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１のバージョン情報を保持する。
【００３０】
サイズフィールド１４３３は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１のプログラムファイルのファイルサイズを示す数値を保持する。
【００３１】
更新日時フィールド１４３４は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１のプログラムファイルが最後に更新された日時を保持する。本フィールドは、サーバ２００上にアプリケーションファイル２１０がアップロードされた日時に相当する。
【００３２】
アプリケーション名称フィールド１４３５は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１の名称を保持する。
【００３３】
図５は、サーバ２００が保持するアプリケーションメタ情報データベース２２０の構成とデータ例を示す図である。アプリケーションメタ情報データベース２２０は、各アプリケーションファイル２１０の属性情報をサーバ２００側で保持するためのデータベースであり、アプリケーションＩＤフィールド２２１、バージョンフィールド２２２、サイズフィールド２２３、更新日時フィールド２２４、アプリケーション名称フィールド２２５、登録ステータスフィールド２２６を有する。
【００３４】
アプリケーションファイル２１０の実体は、携帯端末１００が実行するアプリケーションプログラム１４１と同一であるため、アプリケーションメタ情報データベース２２０が保持するフィールドは、登録ステータスフィールド２２６を除いてアプリケーションメタ情報データ１４３と同一である。
【００３５】
登録ステータスフィールド２２６は、アプリケーションＩＤフィールド２２１の値で識別されるアプリケーションファイル２１０がサーバ２００に登録されているか否かを示す値を保持する。本フィールドは、管理端末４００のオペレータがアプリケーションプログラムを管理するための便宜上設けられたものである。本フィールドが「登録済み」になっているアプリケーションは携帯端末１００からダウンロード可能であり、「削除済み」になっているアプリケーションはダウンロード不可とする。
【００３６】
携帯端末１００上でアプリケーションプログラム１４１が不正に書き換えられるなどしている場合、アプリケーションメタ情報データベース２２０が保持する情報とアプリケーションメタ情報データ１４３が保持する情報の間に差異が生じる場合がある。携帯端末１００のアプリケーション起動制御部１４２は、このことを用いてアプリケーションプログラム１４１の不正書き換えを検出する。詳細は後述の図７で説明する。
【００３７】
以上、ネットワークシステム１０００の各機器の構成について説明した。次に、各機器の動作手順について説明する。
【００３８】
図６は、管理端末４００からサーバ２００にアプリケーションプログラムを登録する手順を説明する図である。以下、図６の各ステップについて説明する。
（図６：ステップ１：管理端末４００側）
管理端末４００のオペレータは、管理端末４００を用いて、サーバ２００へ登録するアプリケーションプログラムのプログラムファイルをサーバ２００へアップロードする。このとき、当該アプリケーションプログラムのアプリケーションメタ情報も一緒にアップロードする。
（図６：ステップ１：サーバ２００側）
サーバ２００のＡＰ更新部２６１は、プログラムファイルを受け取り、アプリケーションファイル２１０として格納する。また、ＡＰ更新部２６１は、アプリケーションメタ情報を受け取り、アプリケーションメタ情報データベース２２０内に格納する。ＡＰ更新部２６１は、必要に応じて、アプリケーションプログラムやそのメタ情報が所定の規則にしたがって作成されているか否かをチェックしてもよい。ＡＰ更新部２６１は、登録が完了すると、登録ステータスフィールド２２６の値を「登録済み」に変更する。また、古いバージョンのアプリケーションを最新バージョンに更新するときは、古いバージョンの登録ステータスフィールド２２６の値を「削除済み」に変更してもよい。
【００３９】
（図６：ステップ２：登録状況を問い合せる）
管理端末４００は、アプリケーションＩＤフィールド２２１の値などをキーにして、アプリケーションプログラムの登録状況をサーバ２００に問い合わせる。サーバ２００の検索処理部２６２は、アプリケーションメタ情報データベース２２０の登録ステータスフィールド２２６の値に基づき登録状況を確認し、管理端末４００に返信する。
（図６：ステップ３：登録完了）
ＡＰ更新部２６１は、アプリケーションプログラムの登録が完了すると、その旨を管理端末４００に返信する。管理端末４００がその返信を受け取った時点で、アプリケーションプログラムの登録が完了する。
【００４０】
図７は、携帯端末１００上でアプリケーションプログラム１４１を起動する際の動作手順を示す図である。以下、図７の各ステップについて説明する。
（図７：ステップ１：携帯端末１００側その１）
携帯端末１００のユーザは、携帯端末１００を用いてサーバ２００にアクセスし、アプリケーションＩＤ２２１の値などをキーにして、アプリケーションファイル２１０のダウンロードを要求する。ＡＰ自動更新チェック部１４２１は、サーバ２００に対し、そのリクエストを送信する。
（図７：ステップ１：サーバ２００側）
サーバ２００の検索処理部２６２は、アプリケーションメタ情報データベース２２０内のアプリケーションメタ情報を検索し、対応するアプリケーションメタ情報とアプリケーションファイル２１０を特定して携帯端末１００に送信する。
【００４１】
（図７：ステップ１：携帯端末１００側その２）
携帯端末１００のＡＰ自動更新チェック部１４２１は、サーバ２００からダウンロードしたアプリケーションファイル２１０とアプリケーションメタ情報を、それぞれアプリケーションプログラム１４１、アプリケーションメタ情報データ１４３として記憶部１４０に格納する。
（図７：ステップ２：属性情報を生成する）
携帯端末１００のユーザは、サーバ２００からダウンロードしたアプリケーションプログラム１４１を起動するように、携帯端末１００へ指示する。このとき、後述する図８の画面を介して、起動指示されたアプリケーションプログラム１４１のアプリケーションＩＤなどが、アプリケーション起動制御部１４２に通知される。ＡＰ起動制御部１４２は、その起動指示を受け取る。ＡＰメタ情報チェック部１４２２は、起動指示されたアプリケーションプログラム１４１にアクセスして、そのプログラム本体から当該アプリケーションプログラムの属性情報を生成する。
【００４２】
（図７：ステップ２：属性情報を生成する：補足その１）
本ステップでＡＰメタ情報チェック部１４２２が生成するアプリケーションプログラム１４１の属性情報は、アプリケーションプログラム１４１のプログラム本体そのものから直接取得することのできるものである。例えば、プログラムファイルのファイルサイズ、プログラムファイルの更新日時、などがこれに相当する。その他の属性情報を取得することができるのであれば、ファイルサイズや更新日時に限るものではない。
（図７：ステップ２：属性情報を生成する：補足その２）
本ステップは、アプリケーションプログラム１４１の現時点における属性情報を取得する意義を有する。すなわち、アプリケーションプログラム１４１が不正に書き換えられていれば、ダウンロードしたときの属性情報とは異なる属性情報を有していると想定されるので、正しい属性情報と比較するために本ステップで現時点の属性情報を取得することとした。
【００４３】
（図７：ステップ３：属性情報をマッチングする）
ＡＰメタ情報チェック部１４２２は、ステップ２でアプリケーションプログラム１４１本体から生成した属性情報と、あらかじめサーバ２００から取得しておいたアプリケーションメタ情報データ１４３内の属性情報とを比較する。ここでは、ステップ２で取得したファイルサイズとサイズフィールド１４３３、ステップ２で取得した更新日時と更新日時フィールド１４３４を、それぞれ比較するものとする。
（図７：ステップ４：起動許可）
ＡＰメタ情報チェック部１４２２は、ステップ３の結果、両者が合致した場合は、当該アプリケーションプログラム１４１を起動することを許可する。ＡＰ起動制御部１４２は当該アプリケーションプログラム１４１を起動する。
（図７：ステップ５：起動不可）
ＡＰメタ情報チェック部１４２２は、ステップ３の結果、両者が合致しなかった場合は、当該アプリケーションプログラム１４１を起動することを許可しない。ＡＰ起動制御部１４２はエラーメッセージを携帯端末１００の画面上に表示し、起動不可である旨を携帯端末１００のユーザに通知する。
【００４４】
図８は、アプリケーション起動制御部１４２が提供する、アプリケーションプログラム１４１を起動するための操作画面イメージを示す図である。以下、図８に示す各画面について説明する。
【００４５】
携帯端末１００のユーザは、メインメニュー画面からアプリケーション一覧画面、アプリケーション検索画面などを介して、携帯端末１００にアプリケーションプログラム１４１のリストを画面表示させる。
【００４６】
携帯端末１００のユーザは、アプリケーションプログラム１４１のリストからいずれかを選択し、当該アプリケーションプログラム１４１を起動するように携帯端末１００へ指示する。
【００４７】
アプリケーション起動制御部１４２のＡＰメタ情報チェック部１４２２は、起動指示されたアプリケーションプログラム１４１について、図７で説明した処理手順を実行し、起動許可するか否かを判定する。
【００４８】
＜実施の形態１：まとめ＞
以上のように、本実施形態１において、アプリケーション起動制御部１４２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、当該アプリケーションプログラム１４１のプログラム本体から属性情報を取得し、あらかじめサーバ２００から取得しておいたアプリケーションメタ情報データ１４３と比較する。これにより、携帯端末１００上のアプリケーションプログラム１４１が不正に書き換えられている場合、その属性情報がアプリケーションメタ情報データ１４３に記述されているものと異なっていると想定されるので、不正書き換えを検出することができる。すなわち、不正に書き換えられたアプリケーションプログラム１４１を不用意に起動してしまう前に、これを防止することができる。
【００４９】
また、本実施形態１では、アプリケーションプログラム１４１本体とは異なるアプリケーション起動制御部１４２が属性情報をチェックする。これにより、アプリケーションプログラム１４１本体が自らチェックする場合と比較して、セキュリティを高めることができると考えられる。すなわち、アプリケーションプログラム１４１は外部からダウンロード取得する機会が多く、その分だけ不正書き換えされる可能性が高いといえるので、本実施形態１ではアプリケーションプログラム１４１本体によるチェック機構とは別のチェック機構を設けることにより、セキュリティの向上を図ることとした。
【００５０】
＜実施の形態２＞
本発明の実施形態２では、実施形態１で説明した動作に加えて、またはこれとは別に、アプリケーションプログラム１４１を起動するときに当該アプリケーションプログラム１４１が最新バージョンであるか否かをチェックする動作手順を説明する。ネットワークシステム１０００および各機器の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５１】
図９は、携帯端末１００上でアプリケーションプログラム１４１を起動する際に最新バージョンであるか否かをチェックする動作手順を示す図である。以下、図９の各ステップについて説明する。
（図９：ステップ１：携帯端末１００側）
携帯端末１００のユーザは、アプリケーションプログラム１４１を起動するように、携帯端末１００へ指示する。このとき、図８の画面を介して、起動指示されたアプリケーションプログラム１４１のアプリケーションＩＤなどが、アプリケーション起動制御部１４２に通知される。ＡＰ起動制御部１４２は、その起動指示を受け取る。ＡＰ自動更新チェック部１４２１は、アプリケーションＩＤ２２１の値などをキーにして、起動指示されたアプリケーションプログラム１４１の最新バージョンの値を、サーバ２００へ問い合わせる。
（図９：ステップ１：サーバ２００側）
サーバ２００の検索処理部２６２は、アプリケーションメタ情報データベース２２０から、指定されたアプリケーションファイル２１０に対応するバージョンフィールド２２２の値を取得する。アプリケーションＩＤフィールド２２１の値が同じレコードが複数ある場合は、登録ステータスフィールド２２６の値が「登録済み」であるもののうち、更新日時フィールド２２４の値が最新であるものについて、バージョンフィールド２２２の値を取得する。検索処理部２６２は、その値を携帯端末１００へ返信する。
【００５２】
（図９：ステップ２：バージョン情報を比較する）
携帯端末１００のＡＰ自動更新チェック部１４２１は、ステップ１でサーバ２００から取得したバージョンフィールド２２２の値と、あらかじめ記憶部１４０に格納しておいたアプリケーションメタ情報データ１４３内のバージョンフィールド１４３２の値とを比較する。
（図９：ステップ３：最新バージョンをダウンロードする）
ＡＰ自動更新チェック部１４２１は、ステップ２の結果、サーバ２００が保持しているバージョンフィールド２２２の値の方がより新しいバージョンであることが分かった場合は、サーバ２００より最新バージョンのアプリケーションプログラムをダウンロードする。ダウンロードの手順は図７のステップ１と同様である。
（図９：ステップ４：アプリケーションを起動する）
ＡＰ自動更新チェック部１４２１は、ステップ２の結果、サーバ２００が保持しているバージョンフィールド２２２の値がバージョンフィールド１４３２の値と同じであることが分かった場合は、当該アプリケーションプログラム１４１の起動を許可する。
【００５３】
＜実施の形態２：まとめ＞
以上のように、本実施形態２において、アプリケーション起動制御部１４２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、当該アプリケーションプログラム１４１に対応するバージョンフィールド１４３２の値を取得し、サーバ２００が保持しているバージョンフィールド２２２の値と比較する。これにより、携帯端末１００が保持しているアプリケーションプログラム１４１のバージョンが最新バージョンでない場合、自動的に最新版に更新することができるので、アプリケーションプログラム１４１本体にバージョンアップ機構を設ける必要がなくなり、開発負担を低減することができる。
【００５４】
また、本実施形態２において、実施形態１で説明した手法を併用することもできる。例えば、最新バージョンのアプリケーションプログラム１４１をダウンロードした以後、実施形態１と同様の手法により属性情報をチェックしてもよい。
【００５５】
＜実施の形態３＞
本発明の実施形態３では、実施形態１〜２で説明した手順を併用する動作手順の１例を説明する。また、携帯端末１００の機器状態を加味して、アプリケーションプログラム１４１を起動するか否かを判定する動作を新たに設ける。ネットワークシステム１０００および各機器の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５６】
図１０は、本実施形態３において携帯端末１００上でアプリケーション１４１を起動する手順を説明する図である。以下、図１０の各ステップについて説明する。
（図１０：ステップＳ１００１〜Ｓ１００２）
携帯端末１００は、アプリケーション起動制御部１４２を起動し、図８で例示したメインメニューを画面表示する（Ｓ１００１）。携帯端末１００のユーザは、メインメニューからアプリケーションリストを選び、起動するアプリケーションプログラム１４１を選択する（Ｓ１００２）。ここではアプリケーションＡを選択したものと仮定する。
（図１０：ステップＳ１００３）
端末情報チェック部１４２３は、携帯端末１００のバッテリー残量をチェックする。バッテリー残量が規定の残量に満たない場合は、アプリケーションを起動することを許可せず、その旨のメッセージを画面表示するなどしてステップＳ１００１に戻る。バッテリー残量が規定の残量以上である場合は、ステップＳ１００４へ進む。
（図１０：ステップＳ１００３：補足）
本ステップでチェックするバッテリー残量の規定値は、記憶部１４０内の適当な記憶領域などにあらかじめ格納しておけばよい。
【００５７】
（図１０：ステップＳ１００４）
端末情報チェック部１４２３は、携帯端末１００が基地局３００と通信することができるか否かをチェックする。例えば、携帯端末１００が通信可能圏内にあるか否かをチェックする。通信可能である場合はステップＳ１００５へ進み、通信できない場合はステップＳ１００８へ進む。
（図１０：ステップＳ１００４：補足）
本ステップは、サーバ２００にアプリケーションプログラムの最新バージョンを問い合わせる処理を実行するか否かを切り分けるための前処理としての意義を有する。携帯端末１００がネットワークに接続できない場合は、最新バージョンをサーバ２００に問い合わせることができないからである。
（図１０：ステップＳ１００５）
アプリケーション起動制御部１４２は、実施形態２の図９で説明した手順を実行し、アプリケーションＡの最新バージョンをサーバ２００に問い合わせる。
【００５８】
（図１０：ステップＳ１００６）
携帯端末１００が保持しているアプリケーションＡよりも新しいバージョンがサーバ２００に存在する場合はステップＳ１００７へ進み、既に携帯端末１００が最新バージョンを保持している場合はステップＳ１００８へ進む。
（図１０：ステップＳ１００７、Ｓ１０１１）
アプリケーション起動制御部１４２は、実施形態２の図９で説明した手順を実行し、アプリケーションＡの最新バージョンをサーバ２００からダウンロードする（Ｓ１００７）。ダウンロードが完了すると、そのアプリケーションプログラムを起動する（Ｓ１０１１）。
（図１０：ステップＳ１００７、Ｓ１０１１：補足）
ここでは、サーバ２００からダウンロードしたアプリケーションは正規の最新バージョンであり、不正書き換えはされていないと想定して、属性情報をチェックせずに即座にアプリケーションＡを起動している。これに代えて、ステップＳ１００７の後にステップＳ１００１に戻って改めてユーザにアプリケーションＡを起動するように促してもよい。
【００５９】
（図１０：ステップＳ１００８〜Ｓ１００９）
アプリケーション起動制御部１４２は、実施形態１の図７で説明した手順を実行し、アプリケーションＡの属性情報がサーバ２００上の属性情報と合致するか否かをチェックする（Ｓ１００８）。両者が合致すればステップＳ１０１１へ進み、合致しなければステップＳ１０１０へ進む（Ｓ１００９）。
（図１０：ステップＳ１０１０）
アプリケーション起動制御部１４２は、アプリケーションＡが不正書き換えされているため起動できない旨のメッセージを画面表示する。
（図１０：ステップＳ１０１１）
アプリケーション起動制御部１４２は、アプリケーションＡを起動する。
【００６０】
＜実施の形態３：まとめ＞
以上のように、本実施形態３において、アプリケーション起動制御部１４２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、携帯端末１００がネットワークと通信できるか否かをチェックし、通信できる場合は最新バージョンをチェックし、通信できない場合は最新バージョンのチェックを省略する。これにより、通信できない環境下でバージョン確認を実行してユーザを待たせてしまうような事態を回避し、携帯端末１００の使用感を向上させることができる。
【００６１】
また、本実施形態３において、携帯端末１００が通信できない場合は、実施形態１で説明した手順で属性情報をチェックする。これにより、アプリケーションプログラム１４１が最新バージョンでない可能性がある場合でも、属性情報のチェックによって不正書き換えを検出することができるので、セキュリティを向上させることができる。また、携帯端末１００が既にアプリケーションプログラム１４１の最新バージョンを保持している場合も、実施形態１と同様の手順を実施して同様の効果を発揮することができる。
【００６２】
＜実施の形態４＞
実施形態１〜３では、アプリケーションプログラム１４１のファイルサイズと更新日時をプログラム本体から取得してアプリケーションメタ情報データ１４３と比較する例を説明した。本発明の実施形態４では、その他の属性情報をアプリケーションプログラム１４１のプログラム本体から取得してアプリケーションメタ情報データ１４３と比較する例を説明する。その他の属性情報として、以下のような例が考えられる。
【００６３】
（属性情報の例１：ファイルハッシュ値）
サーバ２００のアプリケーションメタ情報データベース２２０、および携帯端末１００のアプリケーションメタ情報データ１４３は、アプリケーションプログラム１４１のファイル本体から計算することのできるハッシュ値を、実施形態１〜３で説明したサイズフィールド（２２３、１４３３）および更新日時フィールド（２２４、１４３４）に加えて、またはこれらに代えて保持する。ＡＰメタ情報チェック部１４２２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、そのアプリケーションプログラム１４１のプログラム本体のハッシュ値を計算し、アプリケーションメタ情報データ１４３が保持している当該アプリケーションプログラム１４１のハッシュ値と比較する。
【００６４】
（属性情報の例２：埋め込みキー値）
各アプリケーションファイル２１０およびアプリケーションプログラム１４１のプログラム本体内部に、当該アプリケーションを識別することのできる固有のキー値を埋め込んでおく。サーバ２００のアプリケーションメタ情報データベース２２０、および携帯端末１００のアプリケーションメタ情報データ１４３は、そのキー値を、実施形態１〜３で説明したサイズフィールド（２２３、１４３３）および更新日時フィールド（２２４、１４３４）に加えて、またはこれらに代えて保持する。ＡＰメタ情報チェック部１４２２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、そのアプリケーションプログラム１４１のプログラム本体からキー値を取得し、アプリケーションメタ情報データ１４３が保持している当該アプリケーションプログラム１４１のキー値と比較する。
【００６５】
＜実施の形態４：まとめ＞
以上、本実施形態４では、ファイルサイズと更新日時以外の属性情報を用いて、アプリケーションプログラム１４１の不正書き換えをチェックする例を説明した。以上説明した属性情報は、単独で用いることもできるし、いずれか複数を組み合わせてチェックに用いることもできる。
【００６６】
＜実施の形態５＞
以上の実施形態１〜４において、サーバ２００は、アプリケーションプログラムを管理端末４００から受け取るとき、当該アプリケーションプログラムがアプリケーション起動制御部１４２によってチェックすることのできる形式で作成されているか否かをチェックするようにしてもよい。
【００６７】
例えば、アプリケーション起動制御部１４２が、実施形態３の属性情報例２で説明した埋め込みキー値を用いて起動可否を判断する場合、各アプリケーションプログラム１４１はその埋め込みキー値を内部に保持している必要がある。そこでサーバ２００は、管理端末４００からアプリケーションプログラムを受け取るとき、埋め込みキー値が存在しているか否かをチェックし、存在していない場合は登録拒否するようにしてもよい。
【００６８】
すなわち、サーバ２００は、アプリケーション制御部１４２が属性情報を取得することができるようにするためのインターフェースとなる機能をアプリケーションプログラムが備えているかをチェックし、備えていない場合は登録拒否するようにしてもよい。
【００６９】
＜実施の形態６＞
以上の実施形態１〜５において、ファイルサイズ、更新日時などの属性情報は、アプリケーションファイル２１０およびアプリケーションプログラム１４１のプログラムファイル本体から取得することを説明したが、必ずしも単一のプログラムファイルからこれら属性情報を取得する必要はない。例えば、アプリケーションプログラム１４１が複数のプログラムモジュールによって構成されている場合、個々のプログラムモジュールのファイルサイズ、更新日時などを個別に属性情報として保持しておき、個々に比較するようにしてもよい。
【００７０】
また、以上の実施形態１〜５において、アプリケーション起動制御部１４２はプログラムとして構成することを説明したが、同様の機能を実現する回路デバイスなどのハードウェアを用いて構成することもできる。この場合、アプリケーション起動制御部１４２は、ＡＰ自動更新チェック部１４２１、ＡＰメタ情報チェック部１４２２、端末情報チェック部１４２３の機能を実現する、ハードウェアによって実装された各機能部を備える。
【符号の説明】
【００７１】
１００：携帯端末、１１０：中央演算部、１２０：主記憶部、１３０：送受信部、１４０：記憶部、１４１：アプリケーションプログラム、１４２：アプリケーション起動制御部、１４２１：ＡＰ自動更新チェック部、１４２２：ＡＰメタ情報チェック部、１４２３：端末情報チェック部、１４３：アプリケーションメタ情報データ、１４３１：アプリケーションＩＤフィールド、１４３２：バージョンフィールド、１４３３：サイズフィールド、１４３４：更新日時フィールド、１４３５：アプリケーション名称フィールド、２００：サーバ、２１０：アプリケーションファイル、２２０：アプリケーションメタ情報データベース、２２１：アプリケーションＩＤフィールド、２２２：バージョンフィールド、２２３：サイズフィールド、２２４：更新日時フィールド、２２５：アプリケーション名称フィールド、２２６：登録ステータスフィールド、２３０：中央演算部、２４０：主記憶部、２５０：送受信部、２６０：記憶部、２６１：ＡＰ更新部、２６２：検索処理部、３００：基地局、４００：管理端末、５００：ネットワーク。
【技術分野】
【０００１】
本発明は、携帯端末上で動作するアプリケーションプログラムの起動制御に関するものである。
【背景技術】
【０００２】
従来、アプリケーションプログラムが不正に改変されたことを検出するための様々な手法が開発されている。下記特許文献１には、アプリケーションプログラムを実行する時に、アプリケーションに内蔵されているチェック機構により、アプリケーションが不正に変更されているか否かをチェックする技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】平４−１４９７５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記特許文献１は、外部と接続されていない閉じた環境下にある端末上で動作するアプリケーションのセキュリティを確保することを目的としている。一方現在では、ネットワーク環境が整備され、アプリケーションを実行する端末として、パソコンの他にも携帯端末が広く使用されている。
【０００５】
アプリケーションを実行する端末がネットワークに接続された環境下では、ネットワークを経由してアプリケーションを配布する場合がある。このとき、ネットワーク経由でアプリケーションをダウンロードする手軽さゆえに、コンピュータウイルスによる被害やアプリケーションプログラムの不正書き換えなどのセキュリティ被害につながる可能性がある。特に携帯端末のセキュリティ対策は、パソコンやサーバなどの一般コンピュータと比較して遅れる傾向があるため、安全性を高めることのできる有用な手法が望まれる。
【０００６】
本発明は、上記のような課題を解決するためになされたものであり、携帯端末上で動作するアプリケーションプログラムを安全に実行することのできる技術手法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るアプリケーション起動制御方法は、アプリケーションプログラム本体から取得した属性情報と、携帯端末があらかじめ保持しているアプリケーションプログラムの属性情報とを比較し、両者が合致すればアプリケーションプログラムの起動を許可する。
【発明の効果】
【０００８】
本発明に係るアプリケーション起動制御方法によれば、アプリケーションプログラムが不正に書き換えられている場合、属性情報があらかじめ保持しているものと異なっていることが分かる。これにより、不正な書き換えがあったことを検出することができるので、アプリケーションプログラムを安全に起動することができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態１に係るネットワークシステム１０００の構成図である。
【図２】サーバ２００の機能ブロック図である。
【図３】携帯端末１００の機能ブロック図である。
【図４】携帯端末１００が保持するアプリケーションメタ情報データ１４３の構成とデータ例を示す図である。
【図５】サーバ２００が保持するアプリケーションメタ情報データベース２２０の構成とデータ例を示す図である。
【図６】管理端末４００からサーバ２００にアプリケーションプログラムを登録する手順を説明する図である。
【図７】携帯端末１００上でアプリケーションプログラム１４１を起動する際の動作手順を示す図である。
【図８】アプリケーション起動制御部１４２が提供する、アプリケーションプログラム１４１を起動するための操作画面イメージを示す図である。
【図９】携帯端末１００上でアプリケーションプログラム１４１を起動する際に最新バージョンであるか否かをチェックする動作手順を示す図である。
【図１０】実施形態３において携帯端末１００上でアプリケーション１４１を起動する手順を説明する図である。
【発明を実施するための形態】
【００１０】
＜実施の形態１＞
図１は、本発明の実施形態１に係るネットワークシステム１０００の構成図である。ネットワークシステム１０００は、携帯端末１００、サーバ２００、基地局３００、管理端末４００を有する。サーバ２００、基地局３００、管理端末４００は、ネットワーク５００を介して接続されている。携帯端末１００は、無線通信回線を介して基地局３００に接続し、さらに基地局３００を介してネットワーク５００に接続されている。
【００１１】
携帯端末１００は、ユーザが携帯する端末であり、１以上のアプリケーションプログラムを内部の記憶装置に記憶し、これを実行するように構成されている。携帯端末１００の構成は、後述の図３で改めて説明する。携帯端末１００の例として、携帯電話、ＰＤＡ（Ｐｏｒｔａｂｌｅ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）端末、などが挙げられる。
【００１２】
サーバ２００は、携帯端末１００が実行するアプリケーションプログラムを保持するサーバ装置であり、アプリケーションファイル２１０、アプリケーションメタ情報データベース２２０を備える。サーバ２００のその他の詳細構成については、後述の図２で改めて説明する。
【００１３】
アプリケーションファイル２１０は、携帯端末１００が実行するアプリケーションプログラムのプログラムファイルである。アプリケーションファイル２１０は、少なくとも携帯端末１００が実行するアプリケーションプログラムの最新バージョンのプログラムファイルを保持する。古いバージョンのプログラムファイルを併せて保持しておいてもよい。アプリケーションメタ情報データベース２２０については後述の図５で改めて説明する。
【００１４】
管理端末４００は、携帯端末１００が実行するアプリケーションプログラムをサーバ２００にアップロードするなどの管理作業を実施するための端末である。オペレータは、管理端末４００を用いてアプリケーションプログラムをサーバ２００に新規登録する、最新バージョンに更新する、などの管理作業を実施する。
【００１５】
図２は、サーバ２００の機能ブロック図である。サーバ２００は、アプリケーションファイル２１０、アプリケーションメタ情報データベース２２０の他、中央演算部２３０、主記憶部２４０、送受信部２５０、記憶部２６０を備える。アプリケーションファイル２１０、アプリケーションメタ情報データベース２２０は、サーバ２００の外部に接続されている記憶装置に格納してもよいし、記憶部２６０内に格納してもよい。ここではサーバ２００の外部記憶装置に格納されている例を示した。
【００１６】
中央演算部２３０は、サーバ２００が備えるプログラムを実行する。ここでは後述するＡＰ更新部２６１と検索処理部２６２をプログラムとして構成し、これらを実行するものとするが、これら以外のプログラムを実行することもできる。
【００１７】
主記憶部２４０は、中央演算部２３０がプログラムを実行する際に使用するデータ等を一時的に記憶する。送受信部２５０は、サーバ２００とネットワーク５００を接続するネットワークインターフェースである。
【００１８】
記憶部２６０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶装置で構成されており、ＡＰ更新部２６１、検索処理部２６２を格納している。ＡＰ更新部２６１は、管理端末４００からアプリケーションプログラムを受け取ってＡＰファイル２１０として格納する処理を実行するプログラムである。検索処理部２６２は、アプリケーションメタ情報データベース２２０内のレコードを検索する処理を実行するプログラムである。
【００１９】
図３は、携帯端末１００の機能ブロック図である。携帯端末１００は、中央演算部１１０、主記憶部１２０、送受信部１３０、記憶部１４０を備える。また、無線通信回線を介して基地局３００と通信するアンテナ、送受信回路などの構成を適宜備える。
【００２０】
中央演算部１１０は、携帯端末１００が備えるプログラムを実行する。ここでは後述するアプリケーション１４１とアプリケーション起動制御部１４２をプログラムとして構成し、これらを実行するものとするが、これら以外のプログラムを実行することもできる。
【００２１】
主記憶部１２０は、中央演算部１１０がプログラムを実行する際に使用するデータ等を一時的に記憶する。送受信部１３０は、アンテナ等を介して携帯端末１００と基地局３００を接続するネットワークインターフェースである。
【００２２】
記憶部１４０は、ＨＤＤなどの記憶装置で構成されており、アプリケーションプログラム１４１、アプリケーション起動制御部１４２、アプリケーションメタ情報データ１４３を格納している。
【００２３】
アプリケーションプログラム１４１は、携帯端末１００のユーザが使用するアプリケーション機能を提供するプログラムである。例えば、顧客情報検索プログラム、商品管理プログラム、スケジュール管理プログラム、電子メールクライアントプログラム、などのプログラムが挙げられる。説明の便宜上、１以上のアプリケーションプログラムを総称してアプリケーションプログラム１４１と呼称するが、アプリケーションプログラム１４１の個数は任意でよい。
【００２４】
アプリケーション起動制御部１４２は、アプリケーションプログラム１４１の起動を制御する機能部である。携帯端末１００のユーザがアプリケーションプログラム１４１を起動しようとするとき、アプリケーション起動制御部１４２はその起動指示を受け取り、後述する判定基準にしたがって当該アプリケーション起動プログラム１４１を起動してよいか否かを判定する。判定基準に合致しない場合、ユーザはそのアプリケーションプログラム１４１を起動することができない。
【００２５】
アプリケーション起動制御部１４２は、ＡＰ自動更新チェック部１４２１、ＡＰメタ情報チェック部１４２２、端末情報チェック部１４２３を備える。これらの機能部は、アプリケーション起動制御部１４２の一部として一体的に構成することもできるし、アプリケーション起動制御部１４２と連動する別のプログラムモジュールとして構成することもできる。これらの機能部の詳細については、後述の図７で改めて説明する。
【００２６】
アプリケーションメタ情報データ１４３は、各アプリケーションプログラム１４１の属性情報を記述したデータである。アプリケーションメタ情報データ１４３の例については後述する図４で改めて説明する。
【００２７】
図４は、携帯端末１００が保持するアプリケーションメタ情報データ１４３の構成とデータ例を示す図である。アプリケーションメタ情報データ１４３は、アプリケーションプログラム１４１の属性情報を携帯端末１００側で保持するためのデータファイルであり、アプリケーションＩＤフィールド１４３１、バージョンフィールド１４３２、サイズフィールド１４３３、更新日時フィールド１４３４、アプリケーション名称フィールド１４３５を有する。
【００２８】
アプリケーションＩＤフィールド１４３１は、個々のアプリケーションプログラム１４１を識別するための識別情報を保持する。
【００２９】
バージョンフィールド１４３２は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１のバージョン情報を保持する。
【００３０】
サイズフィールド１４３３は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１のプログラムファイルのファイルサイズを示す数値を保持する。
【００３１】
更新日時フィールド１４３４は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１のプログラムファイルが最後に更新された日時を保持する。本フィールドは、サーバ２００上にアプリケーションファイル２１０がアップロードされた日時に相当する。
【００３２】
アプリケーション名称フィールド１４３５は、アプリケーションＩＤフィールド１４３１の値で識別されるアプリケーションプログラム１４１の名称を保持する。
【００３３】
図５は、サーバ２００が保持するアプリケーションメタ情報データベース２２０の構成とデータ例を示す図である。アプリケーションメタ情報データベース２２０は、各アプリケーションファイル２１０の属性情報をサーバ２００側で保持するためのデータベースであり、アプリケーションＩＤフィールド２２１、バージョンフィールド２２２、サイズフィールド２２３、更新日時フィールド２２４、アプリケーション名称フィールド２２５、登録ステータスフィールド２２６を有する。
【００３４】
アプリケーションファイル２１０の実体は、携帯端末１００が実行するアプリケーションプログラム１４１と同一であるため、アプリケーションメタ情報データベース２２０が保持するフィールドは、登録ステータスフィールド２２６を除いてアプリケーションメタ情報データ１４３と同一である。
【００３５】
登録ステータスフィールド２２６は、アプリケーションＩＤフィールド２２１の値で識別されるアプリケーションファイル２１０がサーバ２００に登録されているか否かを示す値を保持する。本フィールドは、管理端末４００のオペレータがアプリケーションプログラムを管理するための便宜上設けられたものである。本フィールドが「登録済み」になっているアプリケーションは携帯端末１００からダウンロード可能であり、「削除済み」になっているアプリケーションはダウンロード不可とする。
【００３６】
携帯端末１００上でアプリケーションプログラム１４１が不正に書き換えられるなどしている場合、アプリケーションメタ情報データベース２２０が保持する情報とアプリケーションメタ情報データ１４３が保持する情報の間に差異が生じる場合がある。携帯端末１００のアプリケーション起動制御部１４２は、このことを用いてアプリケーションプログラム１４１の不正書き換えを検出する。詳細は後述の図７で説明する。
【００３７】
以上、ネットワークシステム１０００の各機器の構成について説明した。次に、各機器の動作手順について説明する。
【００３８】
図６は、管理端末４００からサーバ２００にアプリケーションプログラムを登録する手順を説明する図である。以下、図６の各ステップについて説明する。
（図６：ステップ１：管理端末４００側）
管理端末４００のオペレータは、管理端末４００を用いて、サーバ２００へ登録するアプリケーションプログラムのプログラムファイルをサーバ２００へアップロードする。このとき、当該アプリケーションプログラムのアプリケーションメタ情報も一緒にアップロードする。
（図６：ステップ１：サーバ２００側）
サーバ２００のＡＰ更新部２６１は、プログラムファイルを受け取り、アプリケーションファイル２１０として格納する。また、ＡＰ更新部２６１は、アプリケーションメタ情報を受け取り、アプリケーションメタ情報データベース２２０内に格納する。ＡＰ更新部２６１は、必要に応じて、アプリケーションプログラムやそのメタ情報が所定の規則にしたがって作成されているか否かをチェックしてもよい。ＡＰ更新部２６１は、登録が完了すると、登録ステータスフィールド２２６の値を「登録済み」に変更する。また、古いバージョンのアプリケーションを最新バージョンに更新するときは、古いバージョンの登録ステータスフィールド２２６の値を「削除済み」に変更してもよい。
【００３９】
（図６：ステップ２：登録状況を問い合せる）
管理端末４００は、アプリケーションＩＤフィールド２２１の値などをキーにして、アプリケーションプログラムの登録状況をサーバ２００に問い合わせる。サーバ２００の検索処理部２６２は、アプリケーションメタ情報データベース２２０の登録ステータスフィールド２２６の値に基づき登録状況を確認し、管理端末４００に返信する。
（図６：ステップ３：登録完了）
ＡＰ更新部２６１は、アプリケーションプログラムの登録が完了すると、その旨を管理端末４００に返信する。管理端末４００がその返信を受け取った時点で、アプリケーションプログラムの登録が完了する。
【００４０】
図７は、携帯端末１００上でアプリケーションプログラム１４１を起動する際の動作手順を示す図である。以下、図７の各ステップについて説明する。
（図７：ステップ１：携帯端末１００側その１）
携帯端末１００のユーザは、携帯端末１００を用いてサーバ２００にアクセスし、アプリケーションＩＤ２２１の値などをキーにして、アプリケーションファイル２１０のダウンロードを要求する。ＡＰ自動更新チェック部１４２１は、サーバ２００に対し、そのリクエストを送信する。
（図７：ステップ１：サーバ２００側）
サーバ２００の検索処理部２６２は、アプリケーションメタ情報データベース２２０内のアプリケーションメタ情報を検索し、対応するアプリケーションメタ情報とアプリケーションファイル２１０を特定して携帯端末１００に送信する。
【００４１】
（図７：ステップ１：携帯端末１００側その２）
携帯端末１００のＡＰ自動更新チェック部１４２１は、サーバ２００からダウンロードしたアプリケーションファイル２１０とアプリケーションメタ情報を、それぞれアプリケーションプログラム１４１、アプリケーションメタ情報データ１４３として記憶部１４０に格納する。
（図７：ステップ２：属性情報を生成する）
携帯端末１００のユーザは、サーバ２００からダウンロードしたアプリケーションプログラム１４１を起動するように、携帯端末１００へ指示する。このとき、後述する図８の画面を介して、起動指示されたアプリケーションプログラム１４１のアプリケーションＩＤなどが、アプリケーション起動制御部１４２に通知される。ＡＰ起動制御部１４２は、その起動指示を受け取る。ＡＰメタ情報チェック部１４２２は、起動指示されたアプリケーションプログラム１４１にアクセスして、そのプログラム本体から当該アプリケーションプログラムの属性情報を生成する。
【００４２】
（図７：ステップ２：属性情報を生成する：補足その１）
本ステップでＡＰメタ情報チェック部１４２２が生成するアプリケーションプログラム１４１の属性情報は、アプリケーションプログラム１４１のプログラム本体そのものから直接取得することのできるものである。例えば、プログラムファイルのファイルサイズ、プログラムファイルの更新日時、などがこれに相当する。その他の属性情報を取得することができるのであれば、ファイルサイズや更新日時に限るものではない。
（図７：ステップ２：属性情報を生成する：補足その２）
本ステップは、アプリケーションプログラム１４１の現時点における属性情報を取得する意義を有する。すなわち、アプリケーションプログラム１４１が不正に書き換えられていれば、ダウンロードしたときの属性情報とは異なる属性情報を有していると想定されるので、正しい属性情報と比較するために本ステップで現時点の属性情報を取得することとした。
【００４３】
（図７：ステップ３：属性情報をマッチングする）
ＡＰメタ情報チェック部１４２２は、ステップ２でアプリケーションプログラム１４１本体から生成した属性情報と、あらかじめサーバ２００から取得しておいたアプリケーションメタ情報データ１４３内の属性情報とを比較する。ここでは、ステップ２で取得したファイルサイズとサイズフィールド１４３３、ステップ２で取得した更新日時と更新日時フィールド１４３４を、それぞれ比較するものとする。
（図７：ステップ４：起動許可）
ＡＰメタ情報チェック部１４２２は、ステップ３の結果、両者が合致した場合は、当該アプリケーションプログラム１４１を起動することを許可する。ＡＰ起動制御部１４２は当該アプリケーションプログラム１４１を起動する。
（図７：ステップ５：起動不可）
ＡＰメタ情報チェック部１４２２は、ステップ３の結果、両者が合致しなかった場合は、当該アプリケーションプログラム１４１を起動することを許可しない。ＡＰ起動制御部１４２はエラーメッセージを携帯端末１００の画面上に表示し、起動不可である旨を携帯端末１００のユーザに通知する。
【００４４】
図８は、アプリケーション起動制御部１４２が提供する、アプリケーションプログラム１４１を起動するための操作画面イメージを示す図である。以下、図８に示す各画面について説明する。
【００４５】
携帯端末１００のユーザは、メインメニュー画面からアプリケーション一覧画面、アプリケーション検索画面などを介して、携帯端末１００にアプリケーションプログラム１４１のリストを画面表示させる。
【００４６】
携帯端末１００のユーザは、アプリケーションプログラム１４１のリストからいずれかを選択し、当該アプリケーションプログラム１４１を起動するように携帯端末１００へ指示する。
【００４７】
アプリケーション起動制御部１４２のＡＰメタ情報チェック部１４２２は、起動指示されたアプリケーションプログラム１４１について、図７で説明した処理手順を実行し、起動許可するか否かを判定する。
【００４８】
＜実施の形態１：まとめ＞
以上のように、本実施形態１において、アプリケーション起動制御部１４２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、当該アプリケーションプログラム１４１のプログラム本体から属性情報を取得し、あらかじめサーバ２００から取得しておいたアプリケーションメタ情報データ１４３と比較する。これにより、携帯端末１００上のアプリケーションプログラム１４１が不正に書き換えられている場合、その属性情報がアプリケーションメタ情報データ１４３に記述されているものと異なっていると想定されるので、不正書き換えを検出することができる。すなわち、不正に書き換えられたアプリケーションプログラム１４１を不用意に起動してしまう前に、これを防止することができる。
【００４９】
また、本実施形態１では、アプリケーションプログラム１４１本体とは異なるアプリケーション起動制御部１４２が属性情報をチェックする。これにより、アプリケーションプログラム１４１本体が自らチェックする場合と比較して、セキュリティを高めることができると考えられる。すなわち、アプリケーションプログラム１４１は外部からダウンロード取得する機会が多く、その分だけ不正書き換えされる可能性が高いといえるので、本実施形態１ではアプリケーションプログラム１４１本体によるチェック機構とは別のチェック機構を設けることにより、セキュリティの向上を図ることとした。
【００５０】
＜実施の形態２＞
本発明の実施形態２では、実施形態１で説明した動作に加えて、またはこれとは別に、アプリケーションプログラム１４１を起動するときに当該アプリケーションプログラム１４１が最新バージョンであるか否かをチェックする動作手順を説明する。ネットワークシステム１０００および各機器の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５１】
図９は、携帯端末１００上でアプリケーションプログラム１４１を起動する際に最新バージョンであるか否かをチェックする動作手順を示す図である。以下、図９の各ステップについて説明する。
（図９：ステップ１：携帯端末１００側）
携帯端末１００のユーザは、アプリケーションプログラム１４１を起動するように、携帯端末１００へ指示する。このとき、図８の画面を介して、起動指示されたアプリケーションプログラム１４１のアプリケーションＩＤなどが、アプリケーション起動制御部１４２に通知される。ＡＰ起動制御部１４２は、その起動指示を受け取る。ＡＰ自動更新チェック部１４２１は、アプリケーションＩＤ２２１の値などをキーにして、起動指示されたアプリケーションプログラム１４１の最新バージョンの値を、サーバ２００へ問い合わせる。
（図９：ステップ１：サーバ２００側）
サーバ２００の検索処理部２６２は、アプリケーションメタ情報データベース２２０から、指定されたアプリケーションファイル２１０に対応するバージョンフィールド２２２の値を取得する。アプリケーションＩＤフィールド２２１の値が同じレコードが複数ある場合は、登録ステータスフィールド２２６の値が「登録済み」であるもののうち、更新日時フィールド２２４の値が最新であるものについて、バージョンフィールド２２２の値を取得する。検索処理部２６２は、その値を携帯端末１００へ返信する。
【００５２】
（図９：ステップ２：バージョン情報を比較する）
携帯端末１００のＡＰ自動更新チェック部１４２１は、ステップ１でサーバ２００から取得したバージョンフィールド２２２の値と、あらかじめ記憶部１４０に格納しておいたアプリケーションメタ情報データ１４３内のバージョンフィールド１４３２の値とを比較する。
（図９：ステップ３：最新バージョンをダウンロードする）
ＡＰ自動更新チェック部１４２１は、ステップ２の結果、サーバ２００が保持しているバージョンフィールド２２２の値の方がより新しいバージョンであることが分かった場合は、サーバ２００より最新バージョンのアプリケーションプログラムをダウンロードする。ダウンロードの手順は図７のステップ１と同様である。
（図９：ステップ４：アプリケーションを起動する）
ＡＰ自動更新チェック部１４２１は、ステップ２の結果、サーバ２００が保持しているバージョンフィールド２２２の値がバージョンフィールド１４３２の値と同じであることが分かった場合は、当該アプリケーションプログラム１４１の起動を許可する。
【００５３】
＜実施の形態２：まとめ＞
以上のように、本実施形態２において、アプリケーション起動制御部１４２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、当該アプリケーションプログラム１４１に対応するバージョンフィールド１４３２の値を取得し、サーバ２００が保持しているバージョンフィールド２２２の値と比較する。これにより、携帯端末１００が保持しているアプリケーションプログラム１４１のバージョンが最新バージョンでない場合、自動的に最新版に更新することができるので、アプリケーションプログラム１４１本体にバージョンアップ機構を設ける必要がなくなり、開発負担を低減することができる。
【００５４】
また、本実施形態２において、実施形態１で説明した手法を併用することもできる。例えば、最新バージョンのアプリケーションプログラム１４１をダウンロードした以後、実施形態１と同様の手法により属性情報をチェックしてもよい。
【００５５】
＜実施の形態３＞
本発明の実施形態３では、実施形態１〜２で説明した手順を併用する動作手順の１例を説明する。また、携帯端末１００の機器状態を加味して、アプリケーションプログラム１４１を起動するか否かを判定する動作を新たに設ける。ネットワークシステム１０００および各機器の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５６】
図１０は、本実施形態３において携帯端末１００上でアプリケーション１４１を起動する手順を説明する図である。以下、図１０の各ステップについて説明する。
（図１０：ステップＳ１００１〜Ｓ１００２）
携帯端末１００は、アプリケーション起動制御部１４２を起動し、図８で例示したメインメニューを画面表示する（Ｓ１００１）。携帯端末１００のユーザは、メインメニューからアプリケーションリストを選び、起動するアプリケーションプログラム１４１を選択する（Ｓ１００２）。ここではアプリケーションＡを選択したものと仮定する。
（図１０：ステップＳ１００３）
端末情報チェック部１４２３は、携帯端末１００のバッテリー残量をチェックする。バッテリー残量が規定の残量に満たない場合は、アプリケーションを起動することを許可せず、その旨のメッセージを画面表示するなどしてステップＳ１００１に戻る。バッテリー残量が規定の残量以上である場合は、ステップＳ１００４へ進む。
（図１０：ステップＳ１００３：補足）
本ステップでチェックするバッテリー残量の規定値は、記憶部１４０内の適当な記憶領域などにあらかじめ格納しておけばよい。
【００５７】
（図１０：ステップＳ１００４）
端末情報チェック部１４２３は、携帯端末１００が基地局３００と通信することができるか否かをチェックする。例えば、携帯端末１００が通信可能圏内にあるか否かをチェックする。通信可能である場合はステップＳ１００５へ進み、通信できない場合はステップＳ１００８へ進む。
（図１０：ステップＳ１００４：補足）
本ステップは、サーバ２００にアプリケーションプログラムの最新バージョンを問い合わせる処理を実行するか否かを切り分けるための前処理としての意義を有する。携帯端末１００がネットワークに接続できない場合は、最新バージョンをサーバ２００に問い合わせることができないからである。
（図１０：ステップＳ１００５）
アプリケーション起動制御部１４２は、実施形態２の図９で説明した手順を実行し、アプリケーションＡの最新バージョンをサーバ２００に問い合わせる。
【００５８】
（図１０：ステップＳ１００６）
携帯端末１００が保持しているアプリケーションＡよりも新しいバージョンがサーバ２００に存在する場合はステップＳ１００７へ進み、既に携帯端末１００が最新バージョンを保持している場合はステップＳ１００８へ進む。
（図１０：ステップＳ１００７、Ｓ１０１１）
アプリケーション起動制御部１４２は、実施形態２の図９で説明した手順を実行し、アプリケーションＡの最新バージョンをサーバ２００からダウンロードする（Ｓ１００７）。ダウンロードが完了すると、そのアプリケーションプログラムを起動する（Ｓ１０１１）。
（図１０：ステップＳ１００７、Ｓ１０１１：補足）
ここでは、サーバ２００からダウンロードしたアプリケーションは正規の最新バージョンであり、不正書き換えはされていないと想定して、属性情報をチェックせずに即座にアプリケーションＡを起動している。これに代えて、ステップＳ１００７の後にステップＳ１００１に戻って改めてユーザにアプリケーションＡを起動するように促してもよい。
【００５９】
（図１０：ステップＳ１００８〜Ｓ１００９）
アプリケーション起動制御部１４２は、実施形態１の図７で説明した手順を実行し、アプリケーションＡの属性情報がサーバ２００上の属性情報と合致するか否かをチェックする（Ｓ１００８）。両者が合致すればステップＳ１０１１へ進み、合致しなければステップＳ１０１０へ進む（Ｓ１００９）。
（図１０：ステップＳ１０１０）
アプリケーション起動制御部１４２は、アプリケーションＡが不正書き換えされているため起動できない旨のメッセージを画面表示する。
（図１０：ステップＳ１０１１）
アプリケーション起動制御部１４２は、アプリケーションＡを起動する。
【００６０】
＜実施の形態３：まとめ＞
以上のように、本実施形態３において、アプリケーション起動制御部１４２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、携帯端末１００がネットワークと通信できるか否かをチェックし、通信できる場合は最新バージョンをチェックし、通信できない場合は最新バージョンのチェックを省略する。これにより、通信できない環境下でバージョン確認を実行してユーザを待たせてしまうような事態を回避し、携帯端末１００の使用感を向上させることができる。
【００６１】
また、本実施形態３において、携帯端末１００が通信できない場合は、実施形態１で説明した手順で属性情報をチェックする。これにより、アプリケーションプログラム１４１が最新バージョンでない可能性がある場合でも、属性情報のチェックによって不正書き換えを検出することができるので、セキュリティを向上させることができる。また、携帯端末１００が既にアプリケーションプログラム１４１の最新バージョンを保持している場合も、実施形態１と同様の手順を実施して同様の効果を発揮することができる。
【００６２】
＜実施の形態４＞
実施形態１〜３では、アプリケーションプログラム１４１のファイルサイズと更新日時をプログラム本体から取得してアプリケーションメタ情報データ１４３と比較する例を説明した。本発明の実施形態４では、その他の属性情報をアプリケーションプログラム１４１のプログラム本体から取得してアプリケーションメタ情報データ１４３と比較する例を説明する。その他の属性情報として、以下のような例が考えられる。
【００６３】
（属性情報の例１：ファイルハッシュ値）
サーバ２００のアプリケーションメタ情報データベース２２０、および携帯端末１００のアプリケーションメタ情報データ１４３は、アプリケーションプログラム１４１のファイル本体から計算することのできるハッシュ値を、実施形態１〜３で説明したサイズフィールド（２２３、１４３３）および更新日時フィールド（２２４、１４３４）に加えて、またはこれらに代えて保持する。ＡＰメタ情報チェック部１４２２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、そのアプリケーションプログラム１４１のプログラム本体のハッシュ値を計算し、アプリケーションメタ情報データ１４３が保持している当該アプリケーションプログラム１４１のハッシュ値と比較する。
【００６４】
（属性情報の例２：埋め込みキー値）
各アプリケーションファイル２１０およびアプリケーションプログラム１４１のプログラム本体内部に、当該アプリケーションを識別することのできる固有のキー値を埋め込んでおく。サーバ２００のアプリケーションメタ情報データベース２２０、および携帯端末１００のアプリケーションメタ情報データ１４３は、そのキー値を、実施形態１〜３で説明したサイズフィールド（２２３、１４３３）および更新日時フィールド（２２４、１４３４）に加えて、またはこれらに代えて保持する。ＡＰメタ情報チェック部１４２２は、アプリケーションプログラム１４１に対する起動指示を受け取ると、そのアプリケーションプログラム１４１のプログラム本体からキー値を取得し、アプリケーションメタ情報データ１４３が保持している当該アプリケーションプログラム１４１のキー値と比較する。
【００６５】
＜実施の形態４：まとめ＞
以上、本実施形態４では、ファイルサイズと更新日時以外の属性情報を用いて、アプリケーションプログラム１４１の不正書き換えをチェックする例を説明した。以上説明した属性情報は、単独で用いることもできるし、いずれか複数を組み合わせてチェックに用いることもできる。
【００６６】
＜実施の形態５＞
以上の実施形態１〜４において、サーバ２００は、アプリケーションプログラムを管理端末４００から受け取るとき、当該アプリケーションプログラムがアプリケーション起動制御部１４２によってチェックすることのできる形式で作成されているか否かをチェックするようにしてもよい。
【００６７】
例えば、アプリケーション起動制御部１４２が、実施形態３の属性情報例２で説明した埋め込みキー値を用いて起動可否を判断する場合、各アプリケーションプログラム１４１はその埋め込みキー値を内部に保持している必要がある。そこでサーバ２００は、管理端末４００からアプリケーションプログラムを受け取るとき、埋め込みキー値が存在しているか否かをチェックし、存在していない場合は登録拒否するようにしてもよい。
【００６８】
すなわち、サーバ２００は、アプリケーション制御部１４２が属性情報を取得することができるようにするためのインターフェースとなる機能をアプリケーションプログラムが備えているかをチェックし、備えていない場合は登録拒否するようにしてもよい。
【００６９】
＜実施の形態６＞
以上の実施形態１〜５において、ファイルサイズ、更新日時などの属性情報は、アプリケーションファイル２１０およびアプリケーションプログラム１４１のプログラムファイル本体から取得することを説明したが、必ずしも単一のプログラムファイルからこれら属性情報を取得する必要はない。例えば、アプリケーションプログラム１４１が複数のプログラムモジュールによって構成されている場合、個々のプログラムモジュールのファイルサイズ、更新日時などを個別に属性情報として保持しておき、個々に比較するようにしてもよい。
【００７０】
また、以上の実施形態１〜５において、アプリケーション起動制御部１４２はプログラムとして構成することを説明したが、同様の機能を実現する回路デバイスなどのハードウェアを用いて構成することもできる。この場合、アプリケーション起動制御部１４２は、ＡＰ自動更新チェック部１４２１、ＡＰメタ情報チェック部１４２２、端末情報チェック部１４２３の機能を実現する、ハードウェアによって実装された各機能部を備える。
【符号の説明】
【００７１】
１００：携帯端末、１１０：中央演算部、１２０：主記憶部、１３０：送受信部、１４０：記憶部、１４１：アプリケーションプログラム、１４２：アプリケーション起動制御部、１４２１：ＡＰ自動更新チェック部、１４２２：ＡＰメタ情報チェック部、１４２３：端末情報チェック部、１４３：アプリケーションメタ情報データ、１４３１：アプリケーションＩＤフィールド、１４３２：バージョンフィールド、１４３３：サイズフィールド、１４３４：更新日時フィールド、１４３５：アプリケーション名称フィールド、２００：サーバ、２１０：アプリケーションファイル、２２０：アプリケーションメタ情報データベース、２２１：アプリケーションＩＤフィールド、２２２：バージョンフィールド、２２３：サイズフィールド、２２４：更新日時フィールド、２２５：アプリケーション名称フィールド、２２６：登録ステータスフィールド、２３０：中央演算部、２４０：主記憶部、２５０：送受信部、２６０：記憶部、２６１：ＡＰ更新部、２６２：検索処理部、３００：基地局、４００：管理端末、５００：ネットワーク。
【特許請求の範囲】
【請求項１】
携帯端末上で動作するアプリケーションプログラムの起動を制御する方法であって、
前記アプリケーションプログラムに対する起動指示を受け取る起動指示ステップと、
前記アプリケーションプログラムの属性情報を、当該アプリケーションプログラムのプログラム本体から取得する属性取得ステップと、
前記アプリケーションプログラムの属性情報を記述した属性情報データを前記携帯端末が備える記憶装置から読み出す属性データ読出ステップと、
前記属性取得ステップで取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とを比較する比較ステップと、
前記属性取得ステップで取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とが合致した場合は前記アプリケーションプログラムの起動を許可し、合致しなかった場合は許可しない、アプリケーション起動判定ステップと、
を有することを特徴とするプログラム起動制御方法。
【請求項２】
前記属性情報データは、前記アプリケーションプログラムのバージョン情報を記述しており、
前記アプリケーションの最新バージョンについてのバージョン情報をネットワーク経由で問い合わせる最新バージョン照会ステップと、
前記属性情報データが記述している前記アプリケーションプログラムのバージョン情報が、前記最新バージョン照会ステップで問い合わせたバージョン情報よりも古い場合、ネットワーク経由で前記アプリケーションプログラムの最新バージョンを取得する最新バージョン取得ステップと、
を有することを特徴とする請求項１記載のプログラム起動制御方法。
【請求項３】
前記携帯端末が前記ネットワークと通信することができるか否かを判定するステップを有し、
前記携帯端末が前記ネットワークと通信することができない場合は、前記最新バージョン照会ステップと前記最新バージョン取得ステップを実行しない
ことを特徴とする請求項２記載のプログラム起動制御方法。
【請求項４】
前記携帯端末が前記ネットワークと通信することができる場合は、
前記最新バージョン照会ステップを実行して、前記属性情報データが記述している前記アプリケーションプログラムのバージョン情報が当該アプリケーションプログラムの最新バージョンであるか否かを確認し、
最新バージョンであった場合は、前記最新バージョン取得ステップを実行せずに、前記属性取得ステップ、前記属性データ読出ステップ、前記比較ステップ、前記アプリケーション起動判定ステップを実行し、
最新バージョンでなかった場合は、前記最新バージョン取得ステップを実行する
ことを特徴とする請求項３記載のプログラム起動制御方法。
【請求項５】
前記携帯端末のバッテリー残量を確認し、所定閾値未満である場合は前記アプリケーションプログラムの起動を許可しないステップを有する
ことを特徴とする請求項１から４のいずれか１項記載のプログラム起動制御方法。
【請求項６】
前記属性情報データは、前記アプリケーションプログラムのファイルサイズを前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイルサイズを前記属性情報として取得する
ことを特徴とする請求項１から５のいずれか１項記載のプログラム起動制御方法。
【請求項７】
前記属性情報データは、前記アプリケーションプログラムのファイル更新日時を前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイル更新日時を前記属性情報として取得する
ことを特徴とする請求項１から６のいずれか１項記載のプログラム起動制御方法。
【請求項８】
前記属性情報データは、前記アプリケーションプログラムのファイルハッシュ値を前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイルハッシュ値を前記属性情報として取得する
ことを特徴とする請求項１から７のいずれか１項記載のプログラム起動制御方法。
【請求項９】
前記属性情報データは、前記アプリケーションプログラムのファイル内に埋め込まれた識別情報を前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイル内に埋め込まれた識別情報を前記属性情報として取得する
ことを特徴とする請求項１から８のいずれか１項記載のプログラム起動制御方法。
【請求項１０】
請求項１から９のいずれか１項記載のプログラム起動制御方法を前記携帯端末が備える演算装置に実行させることを特徴とするプログラム起動制御プログラム。
【請求項１１】
アプリケーションプログラムと、前記アプリケーションプログラムの属性情報を記述した属性情報データと、を記憶する記憶部と、
前記アプリケーションプログラムを実行する演算部と、
前記アプリケーションプログラムの起動を制御するプログラム起動制御部と、
を備え、
前記プログラム起動制御部は、
前記アプリケーションプログラムに対する起動指示を受け取る起動指示部と、
前記アプリケーションプログラムの属性情報を、当該アプリケーションプログラムのプログラム本体から取得する属性取得部と、
前記属性情報データを前記記憶部から読み出す属性データ読出部と、
前記属性取得部が取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とを比較する比較部と、
前記属性取得部が取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とが合致した場合は前記アプリケーションプログラムの起動を許可し、合致しなかった場合は許可しない、アプリケーション起動判定部と、
を備えることを特徴とする携帯端末。
【請求項１２】
前記属性情報データは、前記アプリケーションプログラムのバージョン情報を記述しており、
前記プログラム起動制御部は、
前記アプリケーションの最新バージョンについてのバージョン情報をネットワーク経由で問い合わせる最新バージョン照会部と、
前記属性情報データが記述している前記アプリケーションプログラムのバージョン情報が、前記最新バージョン照会ステップで問い合わせたバージョン情報よりも古い場合、ネットワーク経由で前記アプリケーションプログラムの最新バージョンを取得する最新バージョン取得部と、
を備えることを特徴とする請求項１１記載の携帯端末。
【請求項１３】
請求項１２記載の携帯端末と、
前記アプリケーションプログラムの最新バージョンを保持するサーバと、
を有し、
前記携帯端末は、
前記アプリケーションの最新バージョンのバージョン情報をネットワーク経由で前記サーバに問い合わせ、
ネットワーク経由で前記アプリケーションプログラムの最新バージョンを前記サーバから取得する
ことを特徴とするネットワークシステム。
【請求項１４】
前記サーバは、
前記アプリケーションプログラムの最新バージョンを受け取った後、
前記プログラム起動制御部が前記アプリケーションプログラムの属性情報を取得することのできるインターフェースを当該アプリケーションプログラムが備えているか否かをチェックし、備えていない場合は受け取りを拒否する
ことを特徴とする請求項１３記載のネットワークシステム。
【請求項１】
携帯端末上で動作するアプリケーションプログラムの起動を制御する方法であって、
前記アプリケーションプログラムに対する起動指示を受け取る起動指示ステップと、
前記アプリケーションプログラムの属性情報を、当該アプリケーションプログラムのプログラム本体から取得する属性取得ステップと、
前記アプリケーションプログラムの属性情報を記述した属性情報データを前記携帯端末が備える記憶装置から読み出す属性データ読出ステップと、
前記属性取得ステップで取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とを比較する比較ステップと、
前記属性取得ステップで取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とが合致した場合は前記アプリケーションプログラムの起動を許可し、合致しなかった場合は許可しない、アプリケーション起動判定ステップと、
を有することを特徴とするプログラム起動制御方法。
【請求項２】
前記属性情報データは、前記アプリケーションプログラムのバージョン情報を記述しており、
前記アプリケーションの最新バージョンについてのバージョン情報をネットワーク経由で問い合わせる最新バージョン照会ステップと、
前記属性情報データが記述している前記アプリケーションプログラムのバージョン情報が、前記最新バージョン照会ステップで問い合わせたバージョン情報よりも古い場合、ネットワーク経由で前記アプリケーションプログラムの最新バージョンを取得する最新バージョン取得ステップと、
を有することを特徴とする請求項１記載のプログラム起動制御方法。
【請求項３】
前記携帯端末が前記ネットワークと通信することができるか否かを判定するステップを有し、
前記携帯端末が前記ネットワークと通信することができない場合は、前記最新バージョン照会ステップと前記最新バージョン取得ステップを実行しない
ことを特徴とする請求項２記載のプログラム起動制御方法。
【請求項４】
前記携帯端末が前記ネットワークと通信することができる場合は、
前記最新バージョン照会ステップを実行して、前記属性情報データが記述している前記アプリケーションプログラムのバージョン情報が当該アプリケーションプログラムの最新バージョンであるか否かを確認し、
最新バージョンであった場合は、前記最新バージョン取得ステップを実行せずに、前記属性取得ステップ、前記属性データ読出ステップ、前記比較ステップ、前記アプリケーション起動判定ステップを実行し、
最新バージョンでなかった場合は、前記最新バージョン取得ステップを実行する
ことを特徴とする請求項３記載のプログラム起動制御方法。
【請求項５】
前記携帯端末のバッテリー残量を確認し、所定閾値未満である場合は前記アプリケーションプログラムの起動を許可しないステップを有する
ことを特徴とする請求項１から４のいずれか１項記載のプログラム起動制御方法。
【請求項６】
前記属性情報データは、前記アプリケーションプログラムのファイルサイズを前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイルサイズを前記属性情報として取得する
ことを特徴とする請求項１から５のいずれか１項記載のプログラム起動制御方法。
【請求項７】
前記属性情報データは、前記アプリケーションプログラムのファイル更新日時を前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイル更新日時を前記属性情報として取得する
ことを特徴とする請求項１から６のいずれか１項記載のプログラム起動制御方法。
【請求項８】
前記属性情報データは、前記アプリケーションプログラムのファイルハッシュ値を前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイルハッシュ値を前記属性情報として取得する
ことを特徴とする請求項１から７のいずれか１項記載のプログラム起動制御方法。
【請求項９】
前記属性情報データは、前記アプリケーションプログラムのファイル内に埋め込まれた識別情報を前記属性情報として記述しており、
前記属性取得ステップでは、前記アプリケーションプログラムのファイル内に埋め込まれた識別情報を前記属性情報として取得する
ことを特徴とする請求項１から８のいずれか１項記載のプログラム起動制御方法。
【請求項１０】
請求項１から９のいずれか１項記載のプログラム起動制御方法を前記携帯端末が備える演算装置に実行させることを特徴とするプログラム起動制御プログラム。
【請求項１１】
アプリケーションプログラムと、前記アプリケーションプログラムの属性情報を記述した属性情報データと、を記憶する記憶部と、
前記アプリケーションプログラムを実行する演算部と、
前記アプリケーションプログラムの起動を制御するプログラム起動制御部と、
を備え、
前記プログラム起動制御部は、
前記アプリケーションプログラムに対する起動指示を受け取る起動指示部と、
前記アプリケーションプログラムの属性情報を、当該アプリケーションプログラムのプログラム本体から取得する属性取得部と、
前記属性情報データを前記記憶部から読み出す属性データ読出部と、
前記属性取得部が取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とを比較する比較部と、
前記属性取得部が取得した前記属性情報と、前記属性データ読出ステップで読み出した前記属性情報とが合致した場合は前記アプリケーションプログラムの起動を許可し、合致しなかった場合は許可しない、アプリケーション起動判定部と、
を備えることを特徴とする携帯端末。
【請求項１２】
前記属性情報データは、前記アプリケーションプログラムのバージョン情報を記述しており、
前記プログラム起動制御部は、
前記アプリケーションの最新バージョンについてのバージョン情報をネットワーク経由で問い合わせる最新バージョン照会部と、
前記属性情報データが記述している前記アプリケーションプログラムのバージョン情報が、前記最新バージョン照会ステップで問い合わせたバージョン情報よりも古い場合、ネットワーク経由で前記アプリケーションプログラムの最新バージョンを取得する最新バージョン取得部と、
を備えることを特徴とする請求項１１記載の携帯端末。
【請求項１３】
請求項１２記載の携帯端末と、
前記アプリケーションプログラムの最新バージョンを保持するサーバと、
を有し、
前記携帯端末は、
前記アプリケーションの最新バージョンのバージョン情報をネットワーク経由で前記サーバに問い合わせ、
ネットワーク経由で前記アプリケーションプログラムの最新バージョンを前記サーバから取得する
ことを特徴とするネットワークシステム。
【請求項１４】
前記サーバは、
前記アプリケーションプログラムの最新バージョンを受け取った後、
前記プログラム起動制御部が前記アプリケーションプログラムの属性情報を取得することのできるインターフェースを当該アプリケーションプログラムが備えているか否かをチェックし、備えていない場合は受け取りを拒否する
ことを特徴とする請求項１３記載のネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−８８７６５（Ｐ２０１２−８８７６５Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１０−２３２４９１（Ｐ２０１０−２３２４９１）
【出願日】平成２２年１０月１５日（２０１０．１０．１５）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２２年１０月１５日（２０１０．１０．１５）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
[ Back to top ]