(57)【要約】【課題】  アプリケーションが使用するデバイス機能のセキュリティ危険度を考慮して、アプリケーションのセキュリティポリシーを決定できる技術を提供することを目的とする。【解決手段】  アプリケーションが使用するデバイス機能を特定し、特定されたデバイス機能のセキュリティ危険度を取得し、取得したデバイス機能のセキュリティ危険度から、前記アプリケーションのセキュリティ危険度を算出する。【選択図】  図２
2013077297.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションが使用するデバイス機能を特定する特定手段と、
前記特定されたデバイス機能のセキュリティ危険度を取得する取得手段と、
前記取得したデバイス機能のセキュリティ危険度から、前記アプリケーションのセキュリティ危険度を算出する算出手段と、
前記アプリケーションのセキュリティ危険度と閾値とに基づいて、前記アプリケーションをインストールするかを制御する制御手段を有することを特徴とする情報処理装置。
【請求項２】
さらに、前記閾値を変更する変更手段を有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記算出手段で算出する際に用いる、デバイス機能の重み付けを設定する設定手段を有することを特徴とする請求項１又は請求項２に記載の情報処理装置。
【請求項４】
デバイス機能のセキュリティ危険度を示すセキュリティ危険度表を保持する保持手段を有し、
前記取得手段は、前記セキュリティ危険度表から、前記特定されたデバイス機能のセキュリティ危険度を取得することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
【請求項５】
前記保持手段は、アプリケーションのセキュリティ危険度を算出するための算出式を保持し、
前記算出手段は、前記算出式と、前記取得したデバイス機能のセキュリティ危険度から、前記アプリケーションのセキュリティ危険度を算出することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
【請求項６】
情報処理装置の制御方法であって、
特定手段が、アプリケーションが使用するデバイス機能を特定する特定工程と、
取得手段が、前記特定されたデバイス機能のセキュリティ危険度を取得する取得工程と、
算出手段が、前記取得したデバイス機能のセキュリティ危険度から、前記アプリケーションのセキュリティ危険度を算出する算出工程と、
制御手段が、前記アプリケーションのセキュリティ危険度と閾値とに基づいて、前記アプリケーションをインストールするかを制御する制御工程を有することを特徴とする情報処理装置の制御方法。
【請求項７】
さらに、変更手段が、前記閾値を変更する変更工程を有することを特徴とする請求項６に記載の情報処理装置の制御方法。
【請求項８】
前記算出工程で算出する際に用いる、デバイス機能の重み付けを設定する設定工程を有することを特徴とする請求項６又は請求項７に記載の情報処理装置の制御方法。
【請求項９】
前記取得工程は、デバイス機能のセキュリティ危険度を示すセキュリティ危険度表から、前記特定されたデバイス機能のセキュリティ危険度を取得することを特徴とする請求項６乃至８の何れか１項に記載の情報処理装置の制御方法。
【請求項１０】
前記保持工程は、アプリケーションのセキュリティ危険度を算出するための算出式を保持し、
前記算出工程は、前記算出式と、前記取得したデバイス機能のセキュリティ危険度から、前記アプリケーションのセキュリティ危険度を算出することを特徴とする請求項６乃至８の何れか１項に記載の情報処理装置の制御方法。
【請求項１１】
コンピュータを、請求項１乃至５の何れか１項に記載の情報処理装置が有する各手段として機能させるためのコンピュータプログラム。
【請求項１２】
請求項１１に記載のコンピュータプログラムを格納した、コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションのセキュリティポリシーの設定処理に関する。
【背景技術】
【０００２】
ＰＣ上、とりわけＷｅｂブラウザ上で動作するアプリケーションとして、ＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ファイルとＪａｖａＳｃｒｉｐｔ（登録商標）ファイルから構成されるアプリケーションが存在する。これらのアプリケーションはＷｉｄｇｅｔ（ウィジェット）やＷｅｂＦアプリケーションと呼ばれる事もある。これらのアプリケーションはＣＳＳ（Ｃａｓｃａｄｉｎｇ  Ｓｔｙｌｅ  Ｓｈｅｅｔｓ）ファイルや画像ファイル、ＸＭＬファイル等を含むことも考えられる。
【０００３】
これらＨＴＭＬファイルとＪａｖａＳｃｒｉｐｔ（登録商標）ファイルから構成されるアプリケーションは、今やＰＣのみならず様々なデバイス上でも利用されている。ＷＡＣ（Ｗｈｏｌｅｓａｌｅ  Ａｐｐｌｉｃａｔｉｏｎｓ  Ｃｏｍｍｕｎｉｔｙ）では、アプリケーションストアを通じてアプリケーションをデバイスに配信するフレームワークを標準仕様として策定している。
【０００４】
ＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）から構成されるアプリケーションには、デバイス固有の機能をＪａｖａＳｃｒｉｐｔ（登録商標）コードから呼びだせるようにする機能がある。デバイス固有の機能をＪａｖａＳｃｒｉｐｔ（登録商標）コードから呼び出す仕組みは、標準化団体のＷ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）によって標準仕様が策定されている。この機能はＤｅｖｉｃｅ  ＡＰＩとも呼ばれる。またＷＡＣでもＤｅｖｉｃｅ  ＡＰＩと同様の仕様が策定されている。
【０００５】
Ｄｅｖｉｃｅ  ＡＰＩには様々な種類のＡＰＩが存在する。例えば、個人情報を管理するＡＰＩやデバイスの位置情報を取得するＡＰＩ、またネットワークを通じて外部と通信するＡＰＩなどが挙げられる。アプリケーションがデバイス固有機能を利用できることは、アプリケーションが実現できる機能の幅を増やす。これらのアプリケーションは携帯電話やタブレットＰＣなどで動作し、ユーザエクスペリエンスを向上させることが期待されている。
【０００６】
一方でＤｅｖｉｃｅ  ＡＰＩの仕組みは、デバイスのアプリケーションに対するセキュリティリスクを高めている。例えば、アプリケーションが個人情報にアクセスするＡＰＩとネットワークを通じて外部と通信するＡＰＩを利用する場合、デバイス所有者の個人情報が外部に流出する恐れがある。
【０００７】
Ｄｅｖｉｃｅ  ＡＰＩを利用するアプリケーションのセキュリティを管理する方法として、ＷＡＣの枠組みではセキュリティポリシーを利用する方法を採用している。セキュリティポリシーを利用したアプリケーションの管理方法として、専用アプリケーションと専用サーバを利用した従来技術がある（特許文献１）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−７９９０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１は、アプリケーションの評判を専用サーバに蓄積し、管理アプリケーションが所定の閾値とアプリケーションの評判とを比較して、アプリケーションがアクセス可能なリソースを決定する手法である。
【００１０】
しかし特許文献１は、アプリケーションの評判で決定するため、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩ（デバイス機能）のセキュリティが危険であっても、アプリケーションがアクセス可能なリソースとして決定されていた。
【００１１】
本発明は、このような問題を鑑みてなされたものであり、アプリケーションが使用するデバイス機能のセキュリティ危険度を考慮して、アプリケーションのセキュリティポリシーを決定できる技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の目的を達成するために、例えば、本発明の情報処理装置は、アプリケーションが使用するデバイス機能を特定する特定手段と、前記特定されたデバイス機能のセキュリティ危険度を取得する取得手段と、前記取得したデバイス機能のセキュリティ危険度から、前記アプリケーションのセキュリティ危険度を算出する算出手段と、前記アプリケーションのセキュリティ危険度と閾値とに基づいて、前記アプリケーションをインストールするかを制御する制御手段を有することを特徴とする。
【発明の効果】
【００１３】
プリケーションが使用するデバイス機能のセキュリティ危険度を考慮して、アプリケーションのセキュリティポリシーを決定できる。
【図面の簡単な説明】
【００１４】
【図１】実施例１における情報処理装置のフローチャート。
【図２】情報処理装置のブロック図。
【図３】セキュリティ危険度表の一例。
【図４】セキュリティ危険度に関係する用語の説明。
【図５】実施例２における、セキュリティ項目の変更フローチャート。
【図６】セキュリティ項目を設定するためのユーザインタフェースの例。
【図７】情報処理装置に適用可能なコンピュータのハードウェア構成例を示すブロック図。
【図８】実施例２の変形例１における、セキュリティ項目の変更フローチャート。
【図９】実施例１の変形例における情報処理装置のフローチャート。
【図１０】実施例３における情報処理装置のフローチャート。
【図１１】セキュリティ項目の変更例を提示するユーザインタフェースの例。
【発明を実施するための形態】
【００１５】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施例の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一な構成については、同じ符号を付して説明する。
【実施例１】
【００１６】
本実施例では、ユーザがＷｉｄｇｅｔ形式のアプリケーションをデバイスにインストールする事例を考える。
【００１７】
ここで言うＷｉｄｇｅｔとは、Ｗ３ＣやＷＡＣが規定するアプリケーションのフォーマットである。Ｗｉｄｇｅｔはパッケージ形式であり、含有物としてＸＭＬで記述される設定ファイルとＨＴＭＬファイルを含む。その他、ＪａｖａＳｃｒｉｐｔ（登録商標）ファイル、ＣＳＳファイル、画像ファイル等を含んでいてもよい。Ｗ３ＣやＷＡＣではＸＭＬで記述された設定ファイルをｃｏｎｆｉｇ．ｘｍｌと呼ぶ。
【００１８】
本実施例の情報処理装置に適用可能なコンピュータ装置の構成について、図７のブロック図を参照して説明する。図７において、１００１は情報処理装置２００全体を制御するＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）である。１００２は変更を必要としないプログラムやパラメータを格納するＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）である。１００３は外部装置などから供給されるプログラムやデータを一時記憶するＲａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）である。１００４は保持するデータや供給されたデータを表示するためのインタフェースである。１００５は１００１〜１００４の各ユニットを通信可能に接続するシステムバスである。ユーザからの操作を受けてデータを入力するマウスなどのポインティングデバイスやキーボードなどの入力デバイスとのインタフェース等があってもよい。また情報処理装置２００に固定して設置されたハードディスクやメモリカード等があってもよい。あるいは情報処理装置２００から着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ  Ｄｉｓｋ（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む外部記憶装置等があってもよい。さらにインターネットなどのネットワーク回線に接続するためのネットワークインターフェイス等があってもよい。
【００１９】
図２（Ａ）は、実施例１における情報処理装置２００のブロック図である。図１は、実施例１における情報処理装置２００のフローチャートである。
【００２０】
図１ではまず、操作部２０８で、ユーザにより、インストールしたいアプリケーションを選択する（Ｓ１０１）。Ｄｅｖｉｃｅ  ＡＰＩ特定部２０１にて、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩ（デバイス機能）の使用宣言を取得する。そして、取得した使用宣言からアプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩの一覧を取得することで、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩを特定する（Ｓ１０２）。尚、Ｗ３Ｃ仕様やＷＡＣ仕様では、Ｄｅｖｉｃｅ  ＡＰＩの使用宣言はｃｏｎｆｉｇ．ｘｍｌ内に記載されている。
【００２１】
次に、Ｄｅｖｉｃｅ  ＡＰＩ特定部２０１で、アプリケーションがＤｅｖｉｃｅ  ＡＰＩを使用するか否かを判定する（Ｓ１０３）。Ｓ１０３は、Ｓ１０２で取得した一覧に、Ｄｅｖｉｃｅ  ＡＰＩが含まれる場合は、アプリケーションがＤｅｖｉｃｅ  ＡＰＩを使用すると判定される。
【００２２】
Ｓ１０３において、アプリケーションがＤｅｖｉｃｅ  ＡＰＩを使用しないと判定された場合、制御部２０６は、アプリケーションが安全であると判断し、アプリケーションをインストールする（Ｓ１０８）。
【００２３】
Ｓ１０３において、アプリケーションがＤｅｖｉｃｅ  ＡＰＩを使用すると判定された場合、セキュリティ危険度取得部２０２にて、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度を取得する（Ｓ１０４）。Ｓ１０４は、セキュリティ危険度取得部２０２が、Ｓ１０２で特定したＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度を取得する。保持部２０９は、予め、セキュリティ危険度表を保持しており、セキュリティ危険度取得部２０２は、Ｄｅｖｉｃｅ  ＡＰＩのセキュリティ危険度を、保持部２０９に保持されたセキュリティ危険度表から取得する。
【００２４】
図３（Ａ）は、セキュリティ危険度表の一例である。セキュリティ危険度表は、各Ｄｅｖｉｃｅ  ＡＰＩとそのＡＰＩのセキュリティ危険度を示している。セキュリティ危険度とは、セキュリティのリスクレベルを表したものであって、ここでは、数値が高い方が、より危険であることを示す。本実施形態では、「セキュリティ危険度」という表現を用いて説明するが、「セキュリティ危険度」は、セキュリティのリスクレベルと等価である。尚、各Ｄｅｖｉｃｅ  ＡＰＩが、それぞれ、どのようなＤｅｖｉｃｅ  ＡＰＩかについての説明は、図３（Ｃ）に記載されている通りである。また、各Ｄｅｖｉｃｅ  ＡＰＩのセキュリティ危険度に関係する用語の説明を図４に示す。
【００２５】
Ｓ１０５は、算出部２０４で、Ｓ１０４で取得したＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度と、算出式を用いて、アプリケーションのセキュリティ危険度を算出する。本実施例における算出式の例を式１−１に示す。式１−１は、Ｄｅｖｉｃｅ  ＡＰＩの中でも、特にネットワークを通じて外部と通信するＡＰＩのセキュリティ危険度を高く考慮したものである。尚、算出式は、保持部２０９に保持されており、本実施例では、以下の式１−１と、式１−１を導出するための式１−２、式１−３を保持する。
【００２６】
アプリケーションセキュリティ危険度  ＝  ｄｅｖｉｃｅａｐｉｓセキュリティ危険度＋（ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ×  ｎｅｔｗｏｒｋセキュリティ危険度）  …（式１−１）
ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ＝  ＭＡＸ（ａｃｃｅｌｅｒｏｍｅｔｅｒセキュリティ危険度、ｏｒｉｅｎｔａｔｉｏｎセキュリティ危険度、ｃａｍｅｒａセキュリティ危険度、ｄｅｖｉｃｅｓｔａｔｕｓセキュリティ危険度、ｆｉｌｅｓｙｓｔｅｍセキュリティ危険度、ｍｅｓｓａｇｉｎｇセキュリティ危険度、ｇｅｏｌｏｃａｔｉｏｎセキュリティ危険度、ｐｉｍセキュリティ危険度、ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎセキュリティ危険度）  …（式１−２）
ｐｉｍセキュリティ危険度  ＝  ＭＡＸ（ｃｏｎｔａｃｔセキュリティ危険度、ｃａｌｅｎｄａｒセキュリティ危険度、ｔａｓｋセキュリティ危険度）  …（式１−３）
ここで、式１−１のｄｅｖｉｃｅａｐｉｓセキュリティ危険度は式１−２から算出される。また式１−２のｐｉｍセキュリティ危険度は式１−３から算出される。
【００２７】
式１−１の算出式では、算出結果におけるｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度の割合を大きくするために、ｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度を独立項として扱っている。また、式１−１ではｄｅｖｉｃｅａｐｉｓ  ＡＰＩのセキュリティ危険度は９つのＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度の最大値としている。これはＷＡＣ仕様では、ｄｅｖｉｃｅａｐｉｓ  ＡＰＩとａｃｃｅｌｅｒｏｍｅｔｅｒ〜ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎ  ＡＰＩとは親ＡＰＩと子ＡＰＩとして定義されているためである。また同様にして、ｐｉｍ  ＡＰＩとｃｏｎｔａｃｔ、ｃａｌｅｎｄａｒ、ｔａｓｋ、それぞれのＡＰＩはＷＡＣ仕様上親子関係である。そのため、ｐｉｍ  ＡＰＩのセキュリティ危険度は、ｃｏｎｔａｃｔ  ＡＰＩ〜ｔａｓｋ  ＡＰＩのセキュリティ危険度の最大値としている。
【００２８】
Ｓ１０６は、制御部２０６で、算出部２０４で算出したアプリケーションの危険度と、予め決められた閾値とを比較する。尚、閾値は、アプリケーションセキュリティ限界値を表し、予め、保持部２０９に保持されているとする。Ｓ１０６において、アプリケーションの危険度が閾値よりも小さいと判定された場合は、制御部２０６は、アプリケーションが安全であると判断し、アプリケーションをインストールする（Ｓ１０８）。
【００２９】
一方で、Ｓ１０６においてアプリケーションの危険度が閾値より以上であると判定された場合は、制御部２０６は、アプリケーションが危険であると判断し、アプリケーションをインストールせず、アプリケーションが危険であることを通知する（Ｓ１０７）。表示部２１０に、アプリケーションが危険である旨を示す情報を表示することで、通知する。
【００３０】
本実施例を適用した場合の、一例を以下に示す。
【００３１】
まず、アドレス帳バックアップアプリケーションの例を考える。アドレス帳バックアップアプリケーションの機能は、デバイスに記録されているアドレス帳を、ネットワーク上のサーバに保存することである。このアプリケーションの機能に必要なＤｅｖｉｃｅ  ＡＰＩは、アドレス帳にアクセスするためのｃｏｎｔａｃｔ  ＡＰＩと、ネットワークを利用するためのｎｅｔｗｏｒｋ  ＡＰＩと特定される。ｃｏｎｔａｃｔ  ＡＰＩのセキュリティ危険度と、ｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度と、式１−１から、アドレス帳バックアップアプリケーションのセキュリティ危険度が算出される。
【００３２】
次に、位置情報付き撮影アプリケーションの例を考える。位置情報付き撮影アプリケーションの機能は、撮影時の位置情報を写真に付与することである。このアプリケーションの機能に必要なＤｅｖｉｃｅ  ＡＰＩは、位置情報にアクセスするためのｇｅｏｌｏｃａｔｉｏｎ  ＡＰＩと、カメラを使用するためのｃａｍｅｒａ  ＡＰＩと特定される。ｇｅｏｌｏｃａｔｉｏｎ  ＡＰＩのセキュリティ危険度と、ｃａｍｅｒａ  ＡＰＩのセキュリティ危険度と、式１−１から、アドレス帳バックアップアプリケーションのセキュリティ危険度が算出される。
【００３３】
尚、Ｓ１０２において、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩの一覧を取得するために、使用宣言を利用した。しかしながら、使用宣言を利用するのではなく、アプリケーションに含まれるＪａｖａＳｃｒｉｐｔ（登録商標）コード内でＤｅｖｉｃｅ  ＡＰＩと一致する文字列を検索してもよい。その場合は、アプリケーションからＪａｖａＳｃｒｉｐｔ（登録商標）コードを取得し、ＪａｖａＳｃｒｉｐｔ（登録商標）コード内を、Ｄｅｖｉｃｅ  ＡＰＩと一致する文字列があるか文字列検索する。一致する文字列があれば、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩを取得することができる。
【００３４】
＜実施例１の変形例１＞
以上説明した、実施例１では、閾値を用いて、アプリケーションをインストールするかを決定していたたが、実施例１の変形例では、アプリケーションのセキュリティ危険度を通知し、ユーザがインストールを行うかを判断する例を以下で説明する。
【００３５】
図９は、実施例１の変形例における、情報処理装置２００のフローチャートである。Ｓ１０９、Ｓ１１０以外は、実施例１と同じ処理なので、説明は省略する。
【００３６】
Ｓ１０９は、制御部２０６が、表示部２１０に、Ｓ１０５で算出したアプリケーションのセキュリティ危険度を表示する。
【００３７】
Ｓ１１０は、操作部２０８を用いて、インストールをするかどうかの指示を受け付け、制御部２０６が、インストールするという指示を受け取ったかどうかを判定する。Ｓ１１０で、インストールするという指示を受け取ったと判定された場合は、Ｓ１０８に進み、アプリケーションをインストールし、インストールするという指示を受け取ったと判定されなかった場合は、フローを終了する。
【実施例２】
【００３８】
実施例１では、セキュリティ危険度表、算出式、閾値が、予め、設定されて、保持部２０９に保持されている例を説明した。本実施例２では、ユーザが操作部２０８を通して、セキュリティ危険度表、算出式、閾値のいずれかを変更する場合を説明する。ここでは、セキュリティ危険度表、算出式、閾値など、アプリケーションのセキュリティ危険度を求めるために必要なアプリケーションのセキュリティに関する情報を、セキュリティ項目と呼ぶとする。本実施例の構成図を、図２（Ｂ）に示す。
【００３９】
具体的には、実施例１のｎｅｔｗｏｒｋ  ＡＰＩのように、アプリケーションの危険性を判断する上で、ユーザが特にセキュリティに気をつけたいＤｅｖｉｃｅ  ＡＰＩの影響度を高くする場合について説明する。またユーザがデバイスのアプリケーションに対するセキュリティ強度を高くする場合について説明する。実施例２におけるアプリケーションの危険性判定の処理フローは、図１と同じである。ただし、Ｓ１０１の処理の前に、ユーザがデバイスのアプリケーションに対するセキュリティ項目を変更する処理フローが入る。ユーザがデバイスのアプリケーションに対するセキュリティ項目を変更する処理フローの例を図５（Ａ）に示す。
【００４０】
図５（Ａ）は、セキュリティ項目を変更する際の、フローチャートである。
【００４１】
Ｓ５０１は、ユーザにより、操作部２０８で、セキュリティに関する変更を、設定部２１１が検知する。ユーザの操作は、全て図２（Ｂ）の操作部２０８を通して行われる。ここで、アプリケーションに対するセキュリティ重点項目を決定するユーザインタフェースの例を図６（Ａ）に示す。図６（Ａ）に示しているように、セキュリティ重点項目とは、アプリケーションのセキュリティのうち、特に、セキュリティ強度を上げたい機能を選択するためのものである。ここでは、機能（セキュリティ重点項目）として、ネットワーク、個人情報、ファイルシステム、メール、カメラ、現在地情報の例を示す。図３（Ｄ）に、セキュリティ重点項目と、それに対応するＤｅｖｉｃｅ  ＡＰＩを示す。ここでは、セキュリティ強度を上げたい機能を、Ｄｅｖｉｃｅ  ＡＰＩ毎に選択するのではなく、ユーザに選択しやすいように、関連するＤｅｖｉｃｅ  ＡＰＩをまとめて、セキュリティ重点項目を選択するようにしている。
【００４２】
Ｓ５０２は、設定部２１１が、ユーザが操作した内容が、セキュリティ重点項目の変更であるか否かを判定する。Ｓ５０２において、ユーザがセキュリティ重点項目を変更したと判定された場合、Ｓ５０３で、設定部（変更部）２１１が、算出式を変更する。
【００４３】
ここで、図６（Ａ）を用いて、具体的な操作例を説明する。まずユーザは図６（Ａ）に示されている画面上で、重点的にセキュリティ強度を上げたい機能（セキュリティ重点項目）を選択する。実施例２では、ネットワーク通信に加えて、ユーザが個人情報の管理に特に気をつけたい場合を考える。図６（Ａ）ではネットワーク通信と個人情報の二つの項目が選択されている。
【００４４】
ユーザがセキュリティ項目の変更を行う前、つまりデバイスの初期設定では、ユーザのセキュリティ項目の設定画面において個人情報項目にチェックがなく、アプリケーションの危険性判断において、個人情報にアクセスする機能が重要視されていないとする。このとき算出部２０４で使用する算出式は、式１−１に示す算出式とする。
【００４５】
図５（Ｂ）は、Ｓ５０３の詳細フローチャートである。算出式の変更フローの例を示す。設定部２１１が算出式の基本項を保持部２０９から取得する（Ｓ５１１）。ユーザがセキュリティ重点項目の設定画面で選択した項目に対応する追加項を保持部２０９から取得する（Ｓ５１２）。尚、図３（Ｄ）は、セキュリティ重点項目に対する追加項と、Ｄｅｖｉｃｅ  ＡＰＩの基本項であり、いずれも、保持部２０９に保持されている。
【００４６】
図６（Ａ）の例では、ユーザがセキュリティ項目の設定画面においてネットワークと個人情報にチェックを入れて、選択をしている。この場合、得られる追加項は（ｄｅｖｉｃｅａｐｉｓ×ｎｅｔｗｏｒｋ）と（ｄｅｖｉｃｅａｐｉｓ×ｐｉｍ）である。ここで、ｐｉｍは図３（Ｄ）に記載の通り、ｃｏｎｔａｃｔとｃａｌｅｎｄａｒとｔａｓｋの最大値から取得される。
【００４７】
続いて、設定部２１１が、Ｓ５１１で得られた基本項にＳ５１２で得られた追加項を追加する（Ｓ５１３）。図３（Ｄ）に記載の基本項はｄｅｖｉｃｅａｐｉｓである。また追加項は（ｄｅｖｉｃｅａｐｉｓ×ｎｅｔｗｏｒｋ）と（ｄｅｖｉｃｅａｐｉｓ×ｐｉｍ）である。そこで、算出部２０４で使用する算出式を式２−１のように変更する。
【００４８】
アプリケーションセキュリティ危険度  ＝  ｄｅｖｉｃｅａｐｉｓセキュリティ危険度＋（ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ×  ｎｅｔｗｏｒｋセキュリティ危険度）＋（ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ×  ｐｉｍセキュリティ危険度）…（式２−１）
ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ＝  ＭＡＸ（ａｃｃｅｌｅｒｏｍｅｔｅｒセキュリティ危険度、ｏｒｉｅｎｔａｔｉｏｎセキュリティ危険度、ｃａｍｅｒａセキュリティ危険度、ｄｅｖｉｃｅｓｔａｔｕｓセキュリティ危険度、ｆｉｌｅｓｙｓｔｅｍセキュリティ危険度、ｍｅｓｓａｇｉｎｇセキュリティ危険度、ｇｅｏｌｏｃａｔｉｏｎセキュリティ危険度、ｐｉｍセキュリティ危険度、ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎセキュリティ危険度）  …（式２−２）
ｐｉｍセキュリティ危険度  ＝  ＭＡＸ（ｃｏｎｔａｃｔセキュリティ危険度、ｃａｌｅｎｄａｒセキュリティ危険度、ｔａｓｋセキュリティ危険度）  …（式２−３）
ここで、式２−１のｄｅｖｉｃｅａｐｉｓセキュリティ危険度は式２−２から算出される。また式２−２のｐｉｍセキュリティ危険度は式２−３から算出される。
【００４９】
Ｓ５０７で、Ｓ５０３で変更された算出式を保持部２０９に記憶する。
【００５０】
ユーザがセキュリティ重点項目にネットワークと個人情報以外を選択した場合も、図５（Ｂ）のフローを適用する。例えば、ファイルシステムが選択された場合、Ｓ５１２で得られる追加項は、図３（Ｄ）から（ｄｅｖｉｃｅａｐｉｓ×ｆｉｌｅｓｙｓｔｅｍ）となる。
【００５１】
図３（Ｄ）でセキュリティ重点項目がセンサ、デバイス情報に対応する追加項は複数存在する。この場合は全て基本項に追加する。例えば、ユーザがセキュリティ項目の設定画面においてデバイス情報にチェックを入れたとする。この場合、得られる追加項は（ｄｅｖｉｃｅａｐｉｓ×ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎ）と（ｄｅｖｉｃｅａｐｉｓ×ｄｅｖｉｃｅｓｔａｔｕｓ）である。そのため、この二つの追加項を両方とも基本項に追加する。
【００５２】
実施例１では式１−１の算出式のように、算出結果におけるｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度の割合を大きくするために、ｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度を独立項として扱っている。実施例２では式２−１のように、ｎｅｔｗｏｒｋ  ＡＰＩに加えてｃｏｎｔａｃｔ  ＡＰＩのセキュリティ危険度の割合を大きくするために、ｃｏｎｔａｃｔ  ＡＰＩのセキュリティ危険度を独立項として扱っている。
【００５３】
Ｓ５０２にて、ユーザの操作がセキュリティ重点項目の変更でないと判断された場合、ユーザの操作がセキュリティ強度の変更であるか否かを設定部２１１が判定する（Ｓ５０４）。Ｓ５０４において、ユーザの操作がセキュリティ強度の変更であると判定された場合、閾値対応表から、セキュリティ強度に対応する値を取得する（Ｓ５０５）。続いて、設定部２１１が、閾値をＳ５０５で取得した値に変更する（Ｓ５０６）。Ｓ５０７で、Ｓ５０６で変更された値を保持部２０９に記憶する。
【００５４】
ここで、ユーザがデバイスのアプリケーションに対するセキュリティ強度を高くした場合を例にしてＳ５０５とＳ５０６を説明する。ユーザがデバイスのアプリケーションに対するセキュリティ強度を変更するインタフェースの例を図６（Ｂ）に示す。
【００５５】
図６（Ｂ）ではデバイスのアプリケーションのセキュリティ強度を“小”、“中”、“大”から選択できる。ここではユーザは“大”を選んだとする。
【００５６】
設定部２１１は、ユーザが選択した“小”、“中”、“大”のセキュリティ強度に対応する値を、図６（Ｃ）の閾値対応表から取得する。
【００５７】
図６（Ｃ）では、セキュリティ強度“小”、“中”、“大”の値は、それぞれ、３０、２０、１０である。“小”が選択された場合、アプリケーションのセキュリティ危険度が比較的大きくても、アプリケーションは安全であると判断される。一方で、“大”が選択された場合、アプリケーションのセキュリティ危険度が比較的小さくても、アプリケーションは危険であると判断される。本実施例では、“大”が選択されたので、閾値は１４となる。
【００５８】
このように、図３（Ａ）の危険度表と式２−１の算出式を利用すると、アドレス帳を扱うアプリケーションやネットワーク通信を行うアプリケーションのセキュリティ危険度が飛躍的に大きくなる。本実施例を利用すれば、ユーザが特に重点的にセキュリティを強化したいセキュリティ項目について、アプリケーションのセキュリティチェックを強化することができる。
【００５９】
＜実施例２の変形例１＞
以上説明した実施例２では、セキュリティ強度を上げたいＤｅｖｉｃｅ  ＡＰＩの影響度を高くするために、算出式を変更した。以下、実施例２の変形例として、セキュリティ強度を上げたいＤｅｖｉｃｅ  ＡＰＩの影響度を高くするために、セキュリティ危険度表を変更する処理フローを説明する。ここで、実施例２の変形例２における具体的な操作例は、実施例２で説明したものと同じである。変形例１の処理フローの例を図８（Ａ）に示す。図８（Ａ）に処理において、Ｓ８０３以外は図５（Ａ）における処理と同じであるので、説明を省略する。
【００６０】
セキュリティ危険度表の変更処理（Ｓ８０３）について説明する。セキュリティ危険度表は設定部２１１で変更される。設定部２１１は、操作部２０８の情報を読み取り、セキュリティ危険度表に反映させる。ここで、ｎｅｔｗｏｒｋ  ＡＰＩとｐｉｍ  ＡＰＩを使用するアプリケーションのセキュリティ危険度が高くなるようなセキュリティ危険度表の変更方法について説明する。
【００６１】
図８（Ｂ）は、Ｓ８０３の詳細フローチャートである。まず、Ｄｅｖｉｃｅ  ＡＰＩセキュリティ危険度最大値を取得する（Ｓ８１１）。ここで、セキュリティ危険度最大値は予め決められた値であり保持部２０９に保持されているものとする。あるいは、セキュリティ危険度最大値は、図３（Ａ）のセキュリティ危険度表における、セキュリティ危険度の中で最大の値としてもよい。本実施例では、セキュリティ危険度最大値を５とする。
【００６２】
セキュリティ重点項目対応表から変更するＤｅｖｉｃｅ  ＡＰＩ名を取得する（Ｓ８１２）。ここで、セキュリティ重点項目対応表は図５（Ｃ）と同じである。
【００６３】
続いて、Ｓ８１２で取得したＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度をＳ８１１で取得した値に変更する（Ｓ８１３）。本実施例ではＳ８１１で取得した値は５である。また本実施例では、Ｓ８１２で取得されるＤｅｖｉｃｅ  ＡＰＩ名は、ｎｅｔｗｏｒｋとｐｉｍである。
【００６４】
そこで、ｎｅｔｗｏｒｋ  ＡＰＩとｐｉｍ  ＡＰＩのセキュリティ危険度を共に５とする。この変更を加えた２０３の例を図３（Ｂ）に示す。
【００６５】
図３（Ｂ）ではｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度を５に変更した。また、ｐｉｍ  ＡＰＩの子ＡＰＩであるｃｏｎｔａｃｔ  ＡＰＩ、ｃａｌｅｎｄａｒ  ＡＰＩ、ｔａｓｋ  ＡＰＩをそれぞれ５に変更した。
【００６６】
このように、図３（Ｂ）の危険度表と式１−１の算出式を利用すると、アドレス帳を扱うアプリケーションやネットワーク通信を行うアプリケーションのセキュリティ危険度が飛躍的に大きくなる。本実施例を利用すれば、ユーザが特に重点的にセキュリティを強化したいセキュリティ項目について、アプリケーションのセキュリティチェックを強化することができる。
【００６７】
＜実施例２の変形例２＞
以上説明した、実施例１と実施例２ではアプリケーションの危険度を算出する算出式に、各Ｄｅｖｉｃｅ  ＡＰＩの最大値を利用した。以下、変形例２ではアプリケーションの危険度を算出する算出式に、各Ｄｅｖｉｃｅ  ＡＰＩの総和を利用する場合について説明する。
【００６８】
変形例２におけるアプリケーションの危険性判定の処理フローは、図１と同じである。本変形例では２０４で利用する算出式が実施例１とは異なる。実施例３における算出式を式３−１に示す。
【００６９】
アプリケーションセキュリティ危険度  ＝  ｄｅｖｉｃｅａｐｉｓセキュリティ危険度＋（ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ×  ｎｅｔｗｏｒｋセキュリティ危険度）  …（式３−１）
ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ＝  ＳＵＭ（ａｃｃｅｌｅｒｏｍｅｔｅｒセキュリティ危険度、ｏｒｉｅｎｔａｔｉｏｎセキュリティ危険度、ｃａｍｅｒａセキュリティ危険度、ｄｅｖｉｃｅｓｔａｔｕｓセキュリティ危険度、ｆｉｌｅｓｙｓｔｅｍセキュリティ危険度、ｍｅｓｓａｇｉｎｇセキュリティ危険度、ｇｅｏｌｏｃａｔｉｏｎセキュリティ危険度、ｐｉｍセキュリティ危険度、ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎセキュリティ危険度）  …（式３−２）
ｐｉｍセキュリティ危険度  ＝  ＳＵＭ（ｃｏｎｔａｃｔセキュリティ危険度、ｃａｌｅｎｄａｒセキュリティ危険度、ｔａｓｋセキュリティ危険度）  …（式３−３）
ここで、式３−１のｄｅｖｉｃｅａｐｉｓセキュリティ危険度は式３−２から算出される。また式３−２のｐｉｍセキュリティ危険度は式３−３から算出される。
【００７０】
式３−１の算出式を利用すると、各Ｄｅｖｉｃｅ  ＡＰＩのセキュリティ危険度の総和を取るため、アプリケーションが使用するＤｅｖｉｃｅ  ＡＰＩの種類が多い程、そのアプリケーションは危険性が高いと判断される。
【００７１】
＜実施例２の変形例３＞
以下、変形例３では、特定のセキュリティ項目のセキュリティ危険度をアプリケーションの危険性判定に含めない場合について説明する。
【００７２】
ＷＡＣ仕様で定められるＤｅｖｉｃｅ  ＡＰＩには、他のどのＤｅｖｉｃｅ  ＡＰＩと複合しても危険性が少ないと考えられるＡＰＩが存在する。
【００７３】
例えば、加速度センサ情報を取得するａｃｃｅｌｅｒｏｍｅｔｅｒ  ＡＰＩや軸センサ情報を取得するｏｒｉｅｎｔａｔｉｏｎ  ＡＰＩはｎｅｔｗｏｒｋ  ＡＰＩやｃｏｎｔｅｎｔ  ＡＰＩと複合して利用しても、セキュリティ危険度は上がらない。
【００７４】
そのため、ユーザがアプリケーションの危険性判定において、アプリケーションがａｃｃｅｌｅｒｏｍｅｔｅｒ  ＡＰＩやｏｒｉｅｎｔａｔｉｏｎ  ＡＰＩを利用しているか否かを考慮したくないと考える場合がある。そこで、特定のＤｅｖｉｃｅ  ＡＰＩを危険性判定から除外する事を考える。
【００７５】
２０４で使用する算出式からａｃｃｅｌｅｒｏｍｅｔｅｒ  ＡＰＩとｏｒｉｅｎｔａｔｉｏｎ  ＡＰＩを除外した式を式４−１と式５−１に示す。
【００７６】
アプリケーションセキュリティ危険度  ＝  ｄｅｖｉｃｅａｐｉｓセキュリティ危険度＋（ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ×  ｎｅｔｗｏｒｋセキュリティ危険度）  …（式４−１）
ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ＝  ＭＡＸ（ｃａｍｅｒａセキュリティ危険度、ｄｅｖｉｃｅｓｔａｔｕｓセキュリティ危険度、ｆｉｌｅｓｙｓｔｅｍセキュリティ危険度、ｍｅｓｓａｇｉｎｇセキュリティ危険度、ｇｅｏｌｏｃａｔｉｏｎセキュリティ危険度、ｐｉｍセキュリティ危険度、ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎセキュリティ危険度）  …（式４−２）
ｐｉｍセキュリティ危険度  ＝  ＭＡＸ（ｃｏｎｔａｃｔセキュリティ危険度、ｃａｌｅｎｄａｒセキュリティ危険度、ｔａｓｋセキュリティ危険度）  …（式４−３）
ここで、式４−１のｄｅｖｉｃｅａｐｉｓセキュリティ危険度は式４−２から算出される。また式４−２のｐｉｍセキュリティ危険度は式４−３から算出される。
【００７７】
アプリケーションセキュリティ危険度  ＝  ｄｅｖｉｃｅａｐｉｓセキュリティ危険度＋（ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ×  ｎｅｔｗｏｒｋセキュリティ危険度）  …（式５−１）
ｄｅｖｉｃｅａｐｉｓセキュリティ危険度  ＝  ＳＵＭ（ｃａｍｅｒａセキュリティ危険度、ｄｅｖｉｃｅｓｔａｔｕｓセキュリティ危険度、ｆｉｌｅｓｙｓｔｅｍセキュリティ危険度、ｍｅｓｓａｇｉｎｇセキュリティ危険度、ｇｅｏｌｏｃａｔｉｏｎセキュリティ危険度、ｐｉｍセキュリティ危険度、ｄｅｖｉｃｅｉｎｔｅｒａｃｔｉｏｎセキュリティ危険度）  …（式５−２）
ｐｉｍセキュリティ危険度  ＝  ＳＵＭ（ｃｏｎｔａｃｔセキュリティ危険度、ｃａｌｅｎｄａｒセキュリティ危険度、ｔａｓｋセキュリティ危険度）  …（式５−３）
ここで、式５−１のｄｅｖｉｃｅａｐｉｓセキュリティ危険度は式５−２から算出される。また式５−２のｐｉｍセキュリティ危険度は式５−３から算出される。
【００７８】
式４−１は親ＡＰＩのセキュリティ危険度の算出に最大値を利用した場合である。式５−１は親ＡＰＩのセキュリティ危険度の算出に総和を利用した場合である。式４−１と式５−１では、アプリケーションがａｃｃｅｌｅｒｏｍｅｔｅｒ  ＡＰＩやｏｒｉｅｎｔａｔｉｏｎ  ＡＰＩを利用していてもアプリケーションのセキュリティ危険度は上がらない。
【００７９】
＜実施例２の変形例４＞
ｃａｍｅｒａ  ＡＰＩとｍｅｓｓａｇｉｎｇ  ＡＰＩを組み合わせれば、カメラを起動し、写真を撮影した後メールに添付して任意のユーザに送信するアプリケーションを作成することができる。またｆｉｌｅｓｙｓｔｅｍ  ＡＰＩとｍｅｓｓａｇｉｎｇ  ＡＰＩを組み合わせれば、デバイス上に保存されている任意のファイルをメールに添付して任意のユーザに送信するアプリケーションを作成することができる。
【００８０】
上記のようにファイルを扱うＤｅｖｉｃｅ  ＡＰＩとｍｅｓｓａｇｉｎｇ  ＡＰＩを組み合わせるとセキュリティ危険度の高いアプリケーションを作成することができる。またｃｏｎｔａｃｔ  ＡＰＩとｎｅｔｗｏｒｋ  ＡＰＩの組み合わせのように、ＤｅｖｉｃｅＡＰＩは特定の組み合わせ同士でセキュリティ危険度が大きく上がる。
【００８１】
２０４で使用する算出式を、Ｄｅｖｉｃｅ  ＡＰＩは特定の組み合わせ同士でセキュリティ危険度が大きく上がるように変更した式を式６−１に示す。
【００８２】
アプリケーションセキュリティ危険度  ＝  ｛  ＭＡＸ（ｃａｍｅｒａセキュリティ危険度＋ｆｉｌｅｓｙｓｔｅｍセキュリティ危険度）  ×  ｍｅｓｓａｇｉｎｇセキュリティ危険度  ｝  ＋  （ｐｉｍセキュリティ危険度  ×  ｎｅｔｗｏｒｋセキュリティ危険度）  …（式６−１）
ｐｉｍセキュリティ危険度  ＝  ＭＡＸ（ｃｏｎｔａｃｔセキュリティ危険度、ｃａｌｅｎｄａｒセキュリティ危険度、ｔａｓｋセキュリティ危険度）  …（式６−２）
ここで、式６−１のｐｉｍセキュリティ危険度は式６−２から算出される。
【００８３】
式６−１の算出式を利用すると、ファイルを扱うＤｅｖｉｃｅ  ＡＰＩとｍｅｓｓａｇｉｎｇ  ＡＰＩのセキュリティ危険度の積を取ることで、二つが同時に使用されるアプリケーションのセキュリティ危険度は大きくなる。また、ｃｏｎｔａｃｔ  ＡＰＩとｎｅｔｗｏｒｋ  ＡＰＩのセキュリティ危険度の積を取ることで、二つが同時に使用されるアプリケーションのセキュリティ危険度も大きくなる。
【実施例３】
【００８４】
実施例３では、危険と判断されたアプリケーションをユーザがインストールしたい場合に、アプリケーションをインストールするために必要となる変更をユーザに提示する場合を説明する。本実施例のフローチャートを図１０に示す。また本実施例の構成図は、図２（Ｂ）と同じである。
【００８５】
具体的には、Ｃａｍｅｒａ  ＡＰＩとＮｅｔｗｏｒｋ  ＡＰＩを利用するアプリケーションが危険と判断された場合に、アプリケーションをインストールするために必要となる変更をユーザに提示する場合を説明する。ここで、ユーザが予め指定したｃａｍｅｒａセキュリティ危険度は４、ｎｅｔｗｏｒｋセキュリティ危険度は５、セキュリティ限界値は１５であるとする。またこのとき、ユーザがインストールしたいアプリケーションのセキュリティ危険度は式１−１〜式１−３から２４である。
【００８６】
図１０においてアプリケーションの危険性判定の処理フローは、図１の処理フローと同じである。図１０ではＳ１０９以降の処理が図１とは異なる。
【００８７】
ここで、ユーザにインストールを促すユーザインタフェース例を図１１（Ａ）に示す。ユーザが領域１２０１を選択すると、Ｓ１０１〜Ｓ１０５までの処理が行われる。また本実施例ではＳ１０６の処理結果は、Ｙｅｓであり、Ｓ１０６の処理後はＳ１０７が処理されたとする。引き続きＳ１０９が処理され、ユーザにインストールを希望したアプリケーションが危険であることを通知する。このときのユーザインタフェース例を図１１（Ｂ）に示す。
【００８８】
本実施例では、ユーザは図１１（Ｂ）が提示された後、領域１２０２を押下したと仮定する。ユーザが領域１２０２を選択した場合、Ｓ３００１にて、ユーザがインストール方法の提示を希望したと判定する。その後、算出部２０４にて、変更対象となるＤｅｖｉｃｅ  ＡＰＩを決定する（Ｓ３００２）。本実施例ではアプリケーションが使用する全てのＤｅｖｉｃｅ  ＡＰＩが変更対象として列挙される。続いて算出部２０４にて、アプリケーションが危険と判断されないセキュリティ危険度を算出する（Ｓ３００３）。
【００８９】
Ｓ３００２とＳ３００３の具体的な処理手順を以下に示す。まず、インストールするアプリケーションが利用するＤｅｖｉｃｅ  ＡＰＩを取得する。本実施例ではＣａｍｅｒａ  ＡＰＩとＮｅｔｗｏｒｋ  ＡＰＩである。
【００９０】
まず、ｃａｍｅｒａセキュリティ危険度を変更する場合を考える。セキュリティ限界値は１５であるため、アプリケーションのセキュリティ危険度が１５未満となるような、ｃａｍｅｒａセキュリティ危険度を求める。求めるｃａｍｅｒａセキュリティ危険度をＣｄとすると、式１−２と式１−３からｄｅｖｉｃｅｐｉｓセキュリティ危険度もＣｄとなる。つまり、Ｃｄ＋（Ｃｄ×５）が１５未満となるようなＣｄを求める。この場合、求めるＣｄは２となる。
【００９１】
続いて、ｎｅｔｗｏｒｋセキュリティ危険度を変更する場合を考える。セキュリティ限界値は１５であるため、アプリケーションのセキュリティ危険度が１５未満となるような、ｎｅｔｗｏｒｋセキュリティ危険度を求める。求めるｎｅｔｗｏｒｋセキュリティ危険度をＮｄとすると、式１−２と式１−３からｄｅｖｉｃｅｐｉｓセキュリティ危険度は４となる。つまり、４＋（４×Ｎｄ）が１５未満となるようなＮｄを求める。この場合、求めるＮｄは２となる。
【００９２】
続いて、表示部２１０が、Ｓ３００２で決定したＤｅｖｉｃｅ  ＡＰＩの種類をユーザに提示する（Ｓ３００４）。このときにユーザインタフェース例を図１１（Ｃ）に示す。
【００９３】
ユーザが図１１（Ｃ）を提示された後に領域１２０３を選択した場合、Ｓ３００５にて、制御部２０６が、ユーザがＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度を変更するよう指示したと判定する。続いて算出部２０４が、Ｓ３００２で決定したＤｅｖｉｃｅ  ＡＰＩをＳ３００３で算出した値に変更する。最後にアプリケーションをインストールする（Ｓ１１０）。
【００９４】
ユーザが図１１（Ｃ）を提示された後に領域１２０４を選択した場合、Ｓ３００５にてユーザがＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度を変更するよう指示したと判定せず、Ｓ３００７にてユーザがセキュリティ限界値を変更するよう指示したと判定する。続いて、算出部２０４にてセキュリティ限界値としてアプリケーションが危険と判断されない値を決定する（Ｓ３００８）。
【００９５】
Ｓ３００８の具体的な処理手順を以下に示す。アプリケーションのセキュリティ危険度が２４であるため、セキュリティ限界値を２５にすれば良い事が分かる。求めるセキュリティ限界値は２５である。
【００９６】
続いて、表示部２１０が、Ｓ３００８で算出した変更後のセキュリティ限界値をユーザに提示する（Ｓ３００９）。
【００９７】
Ｓ３００９の処理後、制御部２０６が、Ｓ３０１０にてユーザがＤｅｖｉｃｅ  ＡＰＩのセキュリティ危険度を変更するよう指示したと判定した場合、２１１にてアプリケーションセキュリティ限界値をＳ３００８で算出した値に変更する。最後に制御部２０６が、アプリケーションをインストールする（Ｓ１１０）。
【００９８】
Ｓ３００７の判定、またはＳ３０１０の判定でいずれかが、Ｎｏであった場合は、アプリケーションをインストールしない。以上本発明に係る実施形態を説明したが、先に説明したように、情報処理装置は、通常のパーソナルコンピュータ等の汎用情報処理装置であって、それ上で動作するコンピュータプログラムで実現できるものである。よって、本発明はコンピュータプログラムをその範疇とすることは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ読み取り可能な記憶媒体に格納されており、それをコンピュータの対応するドライブにセットしてシステムにコピーやインストール処理することで実行可能となる。よって、本発明は当然にそのようなコンピュータ可読記憶媒体をもその範疇とすることも明らかである。
【図１】
2013077297.tif 000003
【図２】
2013077297.tif 000004
【図３】
2013077297.tif 000005
【図４】
2013077297.tif 000006
【図５】
2013077297.tif 000007
【図６】
2013077297.tif 000008
【図７】
2013077297.tif 000009
【図８】
2013077297.tif 000010
【図９】
2013077297.tif 000011
【図１０】
2013077297.tif 000012
【図１１】
2013077297.tif 000013