JP2014143555A - 撮影装置及びその制御方法、プログラム - Google Patents

Abstract

【課題】 アプリケーションのアクセス要求とデバイスポリシーに不整合が生じた場合でも、適応的にデバイスＡＰＩの実行を許可することで、ユーザの利便性を向上する。
【解決手段】 特定の機能の動作の準備状態を検知している場合において、アプリケーションによる、特定の機能へのアクセス要求の実行をデバイスポリシーが許可しているか否かを確認する。確認の結果、アクセス要求の実行をデバイスポリシーが許可している場合、特定の機能の動作を実行する。確認の結果、アクセス要求の実行をデバイスポリシーが許可していない場合、警告情報を出力する。特定の機能の動作の開始状態が検知され、デバイスポリシーの第１の許可レベルがデフォルトポリシーの第２の許可レベルよりも厳しい場合、デバイスポリシーの第１の許可レベルをデフォルトポリシーの第２の許可レベルよりも緩くならない範囲で変更する。
【選択図】 図３

Description

本発明は、アプリケーションからのアクセス要求に従って、装置が備える機能の動作を制御する撮影装置及びその制御方法、プログラムに関するものである。

Ｗｅｂブラウザ上で動作するアプリケーションとして、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルとＪａｖａＳｃｒｉｐｔ（登録商標）ファイルから構成されるアプリケーションが存在する。これらのアプリケーションはＷｉｄｇｅｔ（ウィジェット）やＷｅｂアプリケーションと呼ばれることもある。これらのアプリケーションは、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）ファイルや画像ファイル、ＸＭＬファイル等を含むこともある。

これらＨＴＭＬファイルとＪａｖａＳｃｒｉｐｔ（登録商標）ファイルから構成されるアプリケーションは、今やＰＣ（パーソナルコンピュータ）のみならず様々なデバイス上でも利用されている。ＷＡＣ（Ｗｈｏｌｅｓａｌｅ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｍｍｕｎｉｔｙ）（非特許文献１参照）では、アプリケーションストアを通じてアプリケーションをデバイスに配信するフレームワークを標準仕様として策定している。

ＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）から構成されるアプリケーションには、デバイス固有の機能をＪａｖａＳｃｒｉｐｔ（登録商標）コードから呼びだせるようにする機能がある。デバイス固有の機能をＪａｖａＳｃｒｉｐｔ（登録商標）コードから呼び出す仕組みは、標準化団体のＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）によって標準仕様が策定されている。この機能は、デバイスＡＰＩとも呼ばれる。また、ＷＡＣでもデバイスＡＰＩ仕様が参照されている。

デバイスＡＰＩには、様々な種類のＡＰＩが存在する。例えば、個人情報を管理するＡＰＩやデバイスの位置情報を取得するＡＰＩ、また、ネットワークを通じて外部と通信するＡＰＩ等が挙げられる。アプリケーションがデバイス固有機能を利用できることにより、アプリケーションが実現できる機能の幅が増える。これらのアプリケーションは携帯電話やタブレットＰＣ等で動作し、ユーザエクスペリエンスを向上させることが期待されている。

一方、デバイスＡＰＩの仕組みはデバイスのアプリケーションに対するセキュリティリスクを高めている。例えば、アプリケーションが個人情報にアクセスするＡＰＩとネットワークを通じて外部と通信するＡＰＩを利用する場合、デバイス所有者の個人情報が外部に流出する恐れがある。

デバイスＡＰＩを利用するアプリケーションのセキュリティを管理する方法として、ＷＡＣの枠組みでは、セキュリティポリシーを利用する方法を採用している。

ＷＡＣアプリケーションには、ＷＡＣアプリケーションが使用するデバイスＡＰＩをリスト化した、アクセス要求が設定ファイルに記述されている。ＷＡＣにおいては、ＷＡＣアプリケーションのインストール時に、アプリケーションに付随するアクセス要求にリスト化されたデバイスＡＰＩがセキュリティポリシーで許可されているか突き合わせを行う。そして、アクセス要求が、デバイスのセキュリティポリシー、即ち、デバイスポリシーが満たす場合に限って、アプリケーションのインストールが許可される。

WAC2.0 Device Specification http://specs.wacapps.net/2.0/jun2011/

従来技術では、追加アプリケーションのインストール後に、デバイスポリシーが変更され、変更前まで使用可能であったデバイスＡＰＩが使用不能になり、アプリケーションの動作に支障が出る場合の処理方法が記述されていない。従来技術では、アプリケーション起動時に使用不能なデバイスＡＰＩが存在する時、アプリケーションを起動させることができなかった。

ところが、デジタルカメラやデジタルビデオカメラにアプリケーションを実行する環境を実装した場合、以下の課題が浮き彫りになる。

例えば、拡張現実アプリケーション等、撮影が従属的な役割を果たすアプリケーションにおいては、主な機能が使える限りは起動を許すべきである。起動許可後、アプリケーション実行中に撮影を実行しようとしたにもかかわらず撮影実行に必須となるデバイスＡＰＩが使用不能である場合、撮影の実行が困難となる。しかしながら、デジタルカメラ上で動作するような即時性が求められるアプリケーションにおいて、ユーザの利便性を損なわずに、ただちに撮影実行可能にする方法がなかった。

従って、アプリケーションの起動後、撮影時にポリシー不整合の警告と迅速なアクセス許可を行えるようにしなければならない。

本発明は上記の課題を解決するためになされたものである。その目的は、アプリケーションのアクセス要求とデバイスポリシーに不整合が生じた場合でも、適応的にデバイスＡＰＩの実行を許可することで、ユーザの利便性を向上する撮影装置及びその制御方法、プログラムを提供することである。

上記の目的を達成するための本発明による撮影装置は以下の構成を備える。即ち、
アプリケーションからのアクセス要求に従って、装置が備える機能の動作を制御する撮影装置であって、
当該撮影装置の特定の機能の動作の状態を検知する検知手段と、
当該撮影装置の機能に対するアクセスポリシーを記述したデバイスポリシーを読み込む読込手段と、
前記検知手段によって前記特定の機能の動作の準備状態を検知している場合において、前記アプリケーションによる、前記特定の機能へのアクセス要求の実行を前記デバイスポリシーが許可しているか否かを確認する確認手段と、
前記確認手段の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可している場合、前記特定の機能の動作を実行する実行手段と、
前記確認手段の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可していない場合、警告情報を出力する出力手段と、
前記検知手段によって前記特定の機能の動作の開始状態が検知され、前記デバイスポリシーにおいて前記アクセス要求に付与された第１の許可レベルが、当該撮影装置の機能に対する既定の許可状態を記述したデフォルトポリシーで記述されている第２の許可レベルよりも厳しい場合、前記デバイスポリシーの前記第１の許可レベルを前記デフォルトポリシーの前記第２の許可レベルよりも緩くならない範囲で変更する変更手段と
を備える。

本発明によれば、その目的は、アプリケーションのアクセス要求とデバイスポリシーに不整合が生じた場合でも、適応的にデバイスＡＰＩの実行を許可することで、ユーザの利便性を向上することができる。

実施形態１の撮影装置の機能構成を示すブロック図である。 実施形態１の撮影装置のハードウェア構成を示す図である。 実施形態１の撮影装置の動作手順を示すフローチャートである。 実施形態１における警告表示の例である。 実施形態１のデフォルトポリシーの例である。 実施形態１の変形例３におけるデバイスポリシー設定画面の例である。 実施形態２の撮影装置の機能構成を示すブロック図である。 実施形態２の撮影装置の動作手順を示すフローチャートである。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

＜実施形態１＞
図１は実施形態１の撮影装置の機能構成を示す図である。

アプリケーション起動部１０９は、ユーザが選択したアプリケーションを起動する。撮影準備状態検知部１０１は、撮影装置１００のシャッターボタンの半押し状態を検知する。アプリケーション設定ファイル読込部１０２は、ＷＡＣアプリケーションのアプリケーション設定ファイルを読み込み、アプリケーションが使用するデバイスＡＰＩが列挙されているアクセス要求等を読み込む。

デバイスポリシー読込部１０３は、デバイスのアクセスポリシー（セキュリティポリシー）である、デバイスＡＰＩの呼出の可否を定めるデバイスポリシーを読み込む。デバイスポリシーでは、各デバイスＡＰＩに対して、
ｐｅｒｍｉｔ：「許可」
ｐｒｏｍｐｔ−ｂｌａｎｋｅｔ：「初回のデバイスＡＰＩ呼出時にユーザに確認を促し、その後は常時許可」
ｐｒｏｍｐｔ−ｓｅｓｓｉｏｎ：「初回のデバイスＡＰＩ呼出時にユーザに確認を促し、アプリケーション実行中は許可」
ｐｒｏｍｐｔ−ｏｎｅｓｈｏｔ：「デバイスＡＰＩ呼出毎にユーザの確認が必要」
ｄｅｎｙ：「不許可」
のいずれかの許可レベルが付与されている。

デフォルトポリシー読込部１０４は、通常、撮影装置１００の製造者が作成し設定した、デバイスの既定の許可状態を記述したデフォルトポリシーを読み込む。通常、デフォルトポリシーは、デバイスにとって最低限必要な制限を記述している。即ち、デバイスポリシーは、デフォルトポリシーで不許可になっている機能の実行を許可することはできないし、許可レベルをデフォルトポリシーの許可レベルより緩めることはできない。

ポリシー整合性確認部１０５は、アプリケーション設定ファイル読込部１０２が読み込んだアクセス要求で列挙されているデバイスＡＰＩがデバイスポリシー内で許可されているか否かを確認する。警告表示部１０６は、アプリケーションが使用するデバイスＡＰＩの内、許可されていないものが存在する時、警告を表示する。撮影開始状態検知部１０７は、シャッターボタンの全押し状態を検知する。デバイスポリシー変更部１０８は、ポリシー整合性確認部１０５の確認結果に基づいて、デバイスポリシーを変更する。

［ハードウェア構成］
図２は実施形態１の撮影装置のハードウェア構成を示す図である。尚、撮影装置１００の実現に当たっては、図２に示される全ての機能を使用することは必須ではない。

図２において、撮影装置１００は、一般に普及しているデジタルカメラやデジタルビデオカメラと同様である。撮影装置１００の内部では、バス８１５により、各種構成要素が接続され、種々のデータの受け渡しが可能である。ＭＰＵ８１１は、撮影装置１００内部の各種構成要素の動作を制御し、あるいは内部に記憶されたプログラムを実行することができる。主記憶装置８１０は、ＭＰＵ８１１において実行される処理のために、一時的にプログラムや処理対象の画像データを格納する。

アプリケーション実行環境及びアプリケーションは、ＲＯＭ８０９もしくはフラッシュメモリ８０５から主記憶装置８１０にロードされ、ＭＰＵ８１１上で実行される。使用可能なアプリケーションは、ディスプレイ８１２に一覧表示され、タッチセンサ８０６による操作により起動される。

操作スイッチ８０７もしくはタッチセンサ８０６の操作により、インタフェース（Ｉ／Ｆ）８０８を介して撮影開始命令を受け、レンズ８０１から受光した画像は撮像素子８０２で画像信号に変換される。画像信号は、画像信号処理回路８０３で、ＪＰＥＧやＨ．２６４等の記録フォーマットに変換され、ＳＤカード８０４もしくはフラッシュメモリ８０５に記録される。

尚、アプリケーションから実行される撮影もしくは通常の撮影において、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信装置８１３によって受信された現在位置情報を利用することもある。また、ネットワークインタフェース（Ｉ／Ｆ）８１４は、主に、アプリケーションのダウンロードや、アプリケーションからのネットワークへのデータ送信のために利用される。

次に、撮影装置１００の動作手順について説明する。

［アプリケーション設定ファイルの拡張］
実施形態１では、ＷＡＣアプリケーションに付随するアプリケーション設定ファイルに対し、以下の拡張を行う。

該当アプリケーションにおいて、撮影が主たる機能であるか否かを表明するＩｍａｇｅＣａｐｔｕｒｅ＿ｄｏｍｉｎａｎｔフラグを立てる。

この拡張は、ＸＭＬで記述されるアプリケーション設定ファイルに新たなタグを定義することによって実現することが可能である。

例えば、撮影が主たる機能である場合、
＜ＩｍａｇｅＣａｐｔｕｒｅ＿ｄｏｍｉｎａｎｔ＞
Ｙｅｓ
＜／ＩｍａｇｅＣａｐｔｕｒｅ＿ｄｏｍｉｎａｎｔ＞
のように記述する。

［動作手順］
図３は実施形態１の撮影装置の動作手順を示すフローチャートである。

まず、ユーザの操作に応じて、アプリケーション起動部１０９が、アプリケーションを起動する（ステップＳ２０１）。起動後、アプリケーション設定ファイル読込部１０２が、アプリケーション設定ファイルを読み込み、アプリケーションにとって、特定の機能としての撮影機能が主たる機能であるか否かを判定する（ステップＳ２０２）。この判定は、アプリケーション設定ファイル中に、ＩｍａｇｅＣａｐｔｕｒｅ＿ｄｏｍｉｎａｎｔフラグが立っているかどうかで識別可能である。

撮影機能が主たる機能である場合（ステップＳ２０２でＹＥＳ）、以下の処理を行う。デバイスポリシー読込部１０３が、デバイスポリシーを読み込み、実行可能なデバイスＡＰＩを識別する。そして、アプリケーション設定ファイル中に記述されたアクセス要求を、デバイスポリシーが満たさない場合、アプリケーションを終了する（ステップＳ２０５）。

一方、撮影機能が主たる機能でない場合（ステップＳ２０２でＮＯ）、アプリケーションの起動を続行する。次に、撮影準備状態検知部１０１が、アプリケーション実行中にシャッターボタンが半押し状態になることを検知する（ステップＳ２０３）。

これを受けて、デバイスポリシー読込部１０３が、デバイスポリシーを読み込む。さらに、ポリシー整合性確認部１０５が、アプリケーションがアクセスしなければならない確認対象のデバイスＡＰＩをアプリケーション設定ファイル中のアクセス要求項目で識別し、該当するデバイスＡＰＩが実行を許可されているか否かを確認する。つまり、ポリシー整合性確認部１０５で、デバイスポリシーが、アプリケーションが要求するアクセスレベルを満たしているか否かを確認する（ステップＳ２０４）。

判定の結果、アクセスレベルを満たしている場合（ステップＳ２０４でＹＥＳ）、撮影を実行する。

一方、アクセスレベルを満たしていない場合（ステップＳ２０４でＮＯ）、問題があるデバイスＡＰＩが複数ある場合、デバイスＡＰＩ毎に以下の処理を行う。まず、警告表示部１０６が、警告を表示（警告情報を出力）する（ステップＳ２０６）。例えば、撮影時にデバイスの現在位置取得が必須である場合、かつ、現在位置情報取得機能に対応するＡＰＩであるＧｅｏｌｏｃａｔｉｏｎ．ｇｅｔＣｕｒｒｅｎｔＰｏｓｉｔｉｏｎ（）の実行が許可されていない場合、例えば、図４に示すように、
「ＧＰＳ情報が取得できませんが、ＧＰＳをＯＮにして撮影実行しますか？実行する場合はそのままシャッターボタンを押してください。」
と表示する。

次に、撮影開始状態検知部１０７が、シャッターボタンの全押し状態を検知して、シャッターボタンが押下された否かを判定する。シャッターボタンが押下された場合（ステップＳ２０７でＹＥＳ）、次のステップＳ２０８に進む。

一方、全押し状態を検知しない、即ち、使用者がシャッターボタンから指を離している場合（ステップＳ２０７でＮＯ）、撮影を中止する（ステップＳ２１３）。

次に、デフォルトポリシー読込部１０４が、デフォルトポリシーを読み込む。そして、現在のデバイスポリシーにおいて、該当するデバイスＡＰＩに付与された許可レベル（第１の許可レベル）がデフォルトポリシーの許可レベル（第２の許可レベル）より厳しいか否かを判定する（ステップＳ２０８）。尚、厳しいか否かの判定は、例えば、上述の許可レベルの厳しさを、例えば、ｐｅｒｍｉｔ＜ｐｒｏｍｐｔ−ｂｌａｎｋｅｔ＜ｐｒｏｍｐｔ−ｓｅｓｓｉｏｎ＜ｐｒｏｍｐｔ−ｏｎｅｓｈｏｔ＜ｄｅｎｙとして判定すれば良い。

判定の結果、厳しい場合（ステップＳ２０８でＹＥＳ）、許可レベルを緩める余地があるので、次のステップＳ２０９に進む。一方、厳しくない場合（ステップＳ２０８でＮＯ）、現在よりも許可レベルを緩めることはできないので、撮影を中止する（ステップＳ２１３）。

次に、ポリシー整合性確認部１０５が、デフォルトポリシーの許可レベルが「許可」（ｐｅｒｍｉｔ）であるか否かを判定する（ステップＳ２０９）。「許可」である場合（ステップＳ２０９でＹＥＳ）、許可レベルが最大という意味となる。そこで、この場合、デバイスポリシー変更部１０８が、デバイスポリシーの許可レベルを「初回のデバイスＡＰＩ呼出時にユーザに確認を促し、アプリケーション実行中は許可」（ｐｒｏｍｐｔ−ｓｅｓｓｉｏｎ）に変更する（ステップＳ２１０）。

一方、「許可」でない場合（ステップＳ２０９でＮＯ）、デバイスポリシー変更部１０８が、「不許可」（ｄｅｎｙ）から１レベル緩めた「デバイスＡＰＩ呼出毎にユーザの確認が必要」（ｐｒｏｍｐｔ−ｏｎｅｓｈｏｔ）に変更する（ステップＳ２１１）。

デバイスポリシー変更後、ポリシー整合性確認部１０５が、変更が必要な全てのデバイスポリシーが変更されたか否かを判定する（ステップＳ２１２）。全てのデバイスポリシーが変更された場合（ステップＳ２１４でＹＥＳ）、撮影を実行する（ステップＳ２１４）。一方、全てのデバイスポリシーが変更されてない場合（ステップＳ２１４でＮＯ）、ステップＳ２０６に戻る。

以上説明したように、実施形態１によれば、シャッターボタン半押し状態でアプリケーションのアクセス要求とデバイスポリシーの整合性を確認する。不整合が生じた場合、シャッターボタンをＯＫボタンの代用とすることによって、撮影のタイミングを逃さずにアプリケーションが必要とするデバイスＡＰＩの実行許可を出すことが可能となる。

つまり、アプリケーションのアクセス要求とデバイスポリシーに不整合が生じた場合、ユーザに警告を表示し、デジタルカメラやデジタルビデオカメラのシャッターボタンや撮影開始ボタンをＯＫボタンの代用とする。そのことによって、撮影のタイミングを逃さずにアプリケーションが必要とするデバイスＡＰＩの実行許可を出すことが可能となる。

＜変形例１＞
実施形態１では、デバイスポリシーは１種類であることを前提として説明しているが、これに限定されない。例えば、本発明で拡張したアプリケーション設定ファイルの記載事項を利用すれば、デバイスポリシーを２種類以上使用することも可能である。例えば、撮影が主たる機能であるアプリケーション用のデバイスポリシーと、撮影が主たる機能ではないアプリケーション用のデバイスポリシーを用意する。図５にその例を示す。

デバイスポリシーを２種類使用する場合の動作手順を図３を用いて説明する。

ステップＳ２０２での判定後、ステップＳ２０５でデバイスポリシー読込部１０３がデバイスポリシーを読み込む。この場合、アプリケーション設定ファイル中のＩｍａｇｅＣａｐｔｕｒｅ＿ｄｏｍｉｎａｎｔフラグが立っているため、撮影が主たる機能であるアプリケーション用のデバイスポリシー(図５の上段)を読み込む。

ステップＳ２０２での判定後、ステップＳ２０４でデバイスポリシー読込部１０３がデバイスポリシーを読み込む。この場合、アプリケーション設定ファイル中のＩｍａｇｅＣａｐｔｕｒｅ＿ｄｏｍｉｎａｎｔフラグが立っていないため、撮影が主たる機能ではないアプリケーション用のデバイスポリシー(図５の下段)を読み込む。

それ以外の処理は、実施形態１で説明した処理と同様である。

この変形例１により、起動対象のアプリケーションの種別によって、読込対象のデバイスポリシーを切り替えて、あらかじめユーザの意図を反映し、きめ細かくデバイスポリシーを設定できる効果が得られる。

＜変形例２＞
実施形態１では、シャッターボタン半押し時に、デバイスポリシーとアプリケーション設定ファイル中のアクセス要求項目を照合し、アプリケーションが使用するデバイスＡＰＩが使用可能であるか否かを判定している。ここで、アクセス要求項目に多数のデバイスＡＰＩが記述してある一方で、撮影実行時に必要不可欠なデバイスＡＰＩが少数である場合、この判定は、必要以上に時間がかかりすぎてしまう。

そこで、変形例２では、撮影実行に必要十分なデバイスＡＰＩを識別し、そのデバイスＡＰＩのみ判定を行う。

［アプリケーションのプログラム上の規定］
変形例２を実施する上で、アプリケーションが従わなければならない規約がある。アプリケーション中には、ｐｒｅｐａｒｅ（）関数と、ｅｘｅｃｕｔｅ（）関数を用意する。ｐｒｅｐａｒｅ（）関数中には、撮影に付随して必要となる動作、例えば、現在位置取得関数の呼出を記述する。ｅｘｅｃｕｔｅ（）関数には、撮影動作を実行する関数の呼出を記述する。

［動作手順］
動作手順において実施形態と異なる部分を図３を用いて説明する。

アプリケーション実行中にシャッターボタンが半押し状態になることを、撮影準備状態検知部１０１が検知すると（ステップＳ２０３）、次のステップＳ２０４で、アプリケーション中のｐｒｅｐａｒｅ（）関数を呼び出す。

次に、デバイスポリシー読込部１０３が、デバイスポリシーを読み込む。さらに、ｐｒｅｐａｒｅ（）関数中で呼び出されるデバイスＡＰＩが実行を許可されているかをポリシー整合性確認部１０５で確認する。

判定の結果、アクセスレベルを満たしている場合（ステップＳ２０４でＹＥＳ）、ｅｘｅｃｕｔｅ（）関数を呼び出し、撮影を実行する（ステップＳ２１４）。

一方、アクセスレベルを満たしていない場合（ステップＳ２０４でＮＯ）、ステップＳ２０９で、デバイスポリシー変更後、ｅｘｅｃｕｔｅ（）関数を呼び出し、撮影を実行する（ステップＳ２１４）。

それ以外の処理は、実施形態１で説明した処理と同様である。

この変形例２により、撮影に付随して実行が必須なデバイスＡＰＩがｐｒｅｐａｒｅ（）関数の呼出時に識別可能となる。アクセス要求に記述があり、ｐｒｅｐａｒｅ（）関数から呼び出されないデバイスＡＰＩの実行許可・不許可を確認する必要がないため、撮影時のデバイスポリシー確認時の処理量を削減することができる。

＜変形例３＞
実施形態１では、デバイスポリシーによって表明されたユーザの意図を尊重しつつ、アプリケーションからの撮影実行時に、撮影が実行可能なレベルにデバイスＡＰＩの使用制限を最小限の範囲で緩めている。具体的には、ｐｒｏｍｐｔ−ｓｅｓｓｉｏｎもしくはｐｒｏｍｐｔ−ｏｎｅｓｈｏｔに変更している。ｐｒｏｍｐｔ−ｏｎｅｓｈｏｔの場合は、同一のデバイスＡＰＩを呼び出すときに、再度ユーザの許可が必要になる。ｐｒｏｍｐｔ−ｓｅｓｓｉｏｎの場合、アプリケーションを終了し再度起動した場合や、他のアプリケーションから同一のデバイスＡＰＩを呼び出す際、再度ユーザの許可が必要になる。

しかし、ユーザの同意を得た上で、さらに使用制限を緩めたほうが、他のアプリケーション実行時に再度警告画面が表示されることがなくなるため、ユーザにとっての利便性が増す。

そのため、以下のような変形を施す。

撮影実行完了後（ステップＳ２１４）、つまり、特定の機能の動作の実行後、デバイスポリシー設定画面を表示する。その際、変更前のデバイスポリシー及びデフォルトポリシーを表示する。図６に表示例を示す。ユーザは、変更前のデバイスポリシー及びデフォルトポリシーを参照しながら、デバイスポリシーを設定することができる。

＜変形例４＞
実施形態１では、デバイスポリシーによって表明されたユーザの意図を尊重しつつ、アプリケーションからの撮影実行時に、撮影が実行可能なレベルにデバイスＡＰＩの使用制限を最小限の範囲で緩めている。しかし、ユーザによっては、最小限ではなく、最大限、つまり、「常に許可」（ｐｅｒｍｉｔ）に変更したい場合もありうる。

その場合は、ステップＳ２０９−Ｓ２１１でデフォルトポリシーの許可レベルに応じてデバイスポリシーを変更する代わりに、デフォルトポリシーの許可レベルと等しくするようにしても良い。

それ以外の処理は、実施形態１で説明した処理と同様である。

＜変形例５＞
実施形態１では、シャッターボタン半押し状態を検知することが前提となっている。ところが、ユーザの使用形態によっては、シャッターボタン半押し状態を経由することなく、シャッター全押し状態になる場合もある。そこで、このような使用形態に対応するべく、以下のような変形を施す。

動作手順の変更について、図３を用いて説明する。

ステップＳ２０３において、シャッターボタンが半押し状態になることを撮影準備状態検知部１０１が検知する代わりに、シャッターボタンが全押し状態になることを撮影開始状態検知部１０７が検知する。

また、ステップＳ２０７において、警告表示後もシャッターボタン全押し状態が一定期間、例えば、１秒間継続していることを確認する。

それ以外の処理は、実施形態１で説明した処理と同様である。

＜変形例６＞
実施形態１では、ステップＳ２０２において、アプリケーション設定ファイルを読み込み、アプリケーションにとって撮影機能が主たる機能であるか否かを判定している。しかし、このステップを省略し、全てのアプリケーションに対して起動を許し、撮影に関する操作をした時点でアプリケーションのアクセス要求とデバイスポリシーの突き合わせを行ってもよい。

＜変形例７＞
アプリケーション設定ファイル、デバイスポリシー、デフォルトポリシー読込のタイミングは、アプリケーション起動時に行ってもよいし、それぞれの情報が必要になる直前に読み込んでもよい。

尚、実施形態１は、デジタルカメラを例として動作を説明している。しかし、撮影機能やキャプチャー機能を持つ装置、即ち、デジタルビデオカメラ、スマートフォン、タブレットＰＣ、スマートテレビ等にも適用可能である。その場合、シャッターボタンは物理的なボタンである必要はない。例えば、タッチデバイス上に表示されたボタンでもよい。あるいは、音声による指示、セルフタイマーによる撮影、カメラが被写体の笑顔を認識したタイミングで上記の動作を発動してもよい。

＜実施形態２＞
実施形態２は、撮影装置のネットワークへの画像送信機能に関する。

図７は実施形態２の撮影装置を機能構成を示す図である。

アプリケーション起動部５０９は、ユーザが選択したアプリケーションを起動する。画像送信準備状態検知部５０１は、画像送信準備状態を検知する。これは、ユーザが送信先を選択した時が好適である。アプリケーション設定ファイル読込部５０２は、ＷＡＣアプリケーションのアプリケーション設定ファイルを読み込み、アプリケーションが使用するデバイスＡＰＩが列挙されているアクセス要求等を読み込む。

デバイスポリシー読込部５０３は、デバイスＡＰＩの呼出の可否を定めるデバイスポリシーを読み込む。デフォルトポリシー読込部５０４は、デバイスの既定の許可状態を記述したデフォルトポリシーを読み込む。ポリシー整合性確認部５０５は、アプリケーション設定ファイル読込部５０２が読み込んだアクセス要求で列挙されているデバイスＡＰＩがデバイスポリシー内で許可されているかを確認する。警告表示部５０６は、アプリケーションが使用するデバイスＡＰＩの内、許可されていないものが存在する時、警告を表示する。画像送信開始状態検知部５０７は、撮影装置１００の画像送信ボタンが押された状態を検知する。デバイスポリシー変更部５０８は、ポリシー整合性確認部１０５の確認結果に基づいて、デバイスポリシーを変更する。

尚、撮影装置１００のハードウェア構成は、図２に準じるため、その詳細については省略する。

［動作手順］
図８は実施形態２の撮影装置の動作手順を示すフローチャートである。

まず、ユーザの操作に応じて、アプリケーションを起動する（ステップＳ６０１）。起動後、画像送信準備状態検知部５０１が、画像送信の準備状態としてアプリケーション実行中に画像の送信先リストが選択されたことを検知する（ステップＳ６０２）。

次に、デバイスポリシー読込部５０３が、デバイスポリシーを読み込む。さらに、ポリシー整合性確認部５０５が、アプリケーションがアクセスしなければならないデバイスＡＰＩをアプリケーション設定ファイル中のアクセス要求項目で識別し、該当するデバイスＡＰＩが実行を許可されているかを判定する。つまり、ポリシー整合性確認部５０５で、デバイスポリシーが、アプリケーションが要求するアクセスレベルを満たしているか否かを判定する（ステップＳ６０３）。

判定の結果、アクセスレベルを満たしている場合（ステップＳ６０３でＹＥＳ）、画像送信を実行する（ステップＳ６１２）。

一方、アクセスレベルを満たしていない場合（ステップＳ６０３でＮＯ）、警告表示部５０６が、警告を表示する（ステップＳ６０４）。例えば、送信する画像にデバイスの現在位置情報が必須であり、かつ、現在位置情報取得機能に対応するＡＰＩであるＧｅｏｌｏｃａｔｉｏｎ．ｇｅｔＣｕｒｒｅｎｔＰｏｓｉｔｉｏｎ（）の実行が許可されていない場合、図４に示すように、
「ＧＰＳ情報が取得できませんが、ＧＰＳをＯＮにして送信実行しますか？実行する場合はそのままシャッターボタンを押してください。」
と表示する。

次に、画像送信開始状態検知部５０７が、画像送信ボタンの押下状態を検知して、画像送信ボタンが押下された否かを判定する（ステップＳ６０５）。画像送信ボタンが押下された場合（ステップＳ６０５でＹＥＳ）、次のステップＳ６０６に進む。

一方、押下状態を検知しない、即ち、ある一定期間、画像送信ボタンが押下されない場合（ステップＳ６０５でＮＯ）、送信を中止する（ステップＳ６１１）。

次に、デフォルトポリシー読込部５０４が、デフォルトポリシーを読み込む。現在のデバイスポリシーにおいて、該当するデバイスＡＰＩに付与された許可レベルが、デフォルトポリシーより厳しいか否かを判定する（ステップＳ６０６）。尚、厳しいか否かの判定は、実施形態１と同様である。

判定の結果、厳しい場合（ステップＳ６０６でＹＥＳ）、許可レベルを緩める余地があるので、次のステップＳ６０７に進む。一方、厳しくない場合（ステップＳ６０６でＮＯ）、現在よりも許可レベルを緩めることはできないので、画像送信を中止する（ステップＳ６１１）。

次に、ポリシー整合性確認部５０５が、デフォルトポリシーの許可レベルが「許可」（ｐｅｒｍｉｔ）であるか否かを判定する（ステップＳ６０７）。「許可」である場合（ステップＳ６０７でＹＥＳ）、許可レベルが最大という意味となる。そこで、この場合、デバイスポリシー変更部５０８が、デバイスポリシーを「初回のデバイスＡＰＩ呼出時にユーザに確認を促し、アプリケーション実行中は許可」（ｐｒｏｍｐｔ−ｓｅｓｓｉｏｎ）に変更する（ステップＳ６０８）。

一方、「許可」でない場合（ステップＳ６０７でＮＯ）、デバイスポリシー変更部５０８が、「不許可」（ｄｅｎｙ）から１レベル緩めた「デバイスＡＰＩ呼出毎にユーザの確認が必要」（ｐｒｏｍｐｔ−ｏｎｅｓｈｏｔ）に変更する（ステップＳ６０９）。

デバイスポリシー変更後、ポリシー整合性確認部５０５が、変更が必要な全てのデバイスポリシーが変更されたか否かを判定する（ステップＳ６１１）。全てのデバイスポリシーが変更された場合（ステップＳ６１１でＹＥＳ）、画像送信を実行する（ステップＳ６１２）。一方、全てのデバイスポリシーが変更されていない場合（ステップＳ６１１でＮＯ）、ステップＳ６０４に戻る。

以上説明したように、実施形態２によれば、画像送信ボタンの押下状態でアプリケーションのアクセス要求とデバイスポリシーの整合性を確認する。不整合が生じた場合、シャッターボタンをＯＫボタンの代用とすることによって、画像送信のタイミングを逃さずにアプリケーションが必要とするデバイスＡＰＩの実行許可を出すことが可能となる。

＜実施形態３＞
実施形態１や２では、装置の動作状態として、撮影準備／開始状態や画像送信準備／開始状態を検知する構成としているが、これに限定されない。例えば、画像受信準備／開始状態、画像記録準備／開始状態、画像印刷準備／開始状態等の、撮影装置が実現可能な特定の機能の動作の状態（準備、開始等）についても、本発明を適用できることは言うまでもない。

また、撮影装置が実現可能な特定の機能の動作の状態は、撮影装置が備えるボタンやスイッチに対する操作に基づいて検知しているが、これに限定されない。例えば、撮影装置がマイク等の音声入力部を備えている場合には、音声入力部に対する音声を認識することで、撮影装置が実現可能な特定の機能の動作の状態を検知するようにしても良い。

あるいは、撮影装置がタイマー等の計時部を備えている場合には、撮影装置の電源がＯＮに（起動）されてからの経過時間を計時することで、撮影装置が実現可能な特定の機能の動作の状態を検知するようにしても良い。

更には、撮影装置の被写体の特定の状態（例えば、笑顔、静止時間）を検知することで、撮影装置が実現可能な特定の機能の動作の状態を検知するようにしても良い。

尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (12)

1. アプリケーションからのアクセス要求に従って、装置が備える機能の動作を制御する撮影装置であって、
   当該撮影装置の特定の機能の動作の状態を検知する検知手段と、
   当該撮影装置の機能に対するアクセスポリシーを記述したデバイスポリシーを読み込む読込手段と、
   前記検知手段によって前記特定の機能の動作の準備状態を検知している場合において、前記アプリケーションによる、前記特定の機能へのアクセス要求の実行を前記デバイスポリシーが許可しているか否かを確認する確認手段と、
   前記確認手段の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可している場合、前記特定の機能の動作を実行する実行手段と、
   前記確認手段の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可していない場合、警告情報を出力する出力手段と、
   前記検知手段によって前記特定の機能の動作の開始状態が検知され、前記デバイスポリシーにおいて前記アクセス要求に付与された第１の許可レベルが、当該撮影装置の機能に対する既定の許可状態を記述したデフォルトポリシーで記述されている第２の許可レベルよりも厳しい場合、前記デバイスポリシーの前記第１の許可レベルを前記デフォルトポリシーの前記第２の許可レベルよりも緩くならない範囲で変更する変更手段と
   を備えることを特徴とする撮影装置。
2. 前記特定の機能は、画像の撮影、画像の送信、画像の受信、画像の記録、画像の印刷の少なくとも１つを含む
   ことを特徴とする請求項１に記載の撮影装置。
3. 前記変更手段は、前記デフォルトポリシーの前記第２の許可レベルに応じて、前記デバイスポリシーの前記第１の許可レベルを変更する
   ことを特徴とする請求項１または２に記載の撮影装置。
4. 前記アプリケーションにおいて、前記特定の機能が主たる機能でない場合、前記実行手段は、該特定の機能を実行する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の撮影装置。
5. 前記読込手段は、起動対象のアプリケーションの種別に応じて、読込対象のデバイスポリシーを切り替える
   ことを特徴とする請求項１乃至４のいずれか１項に記載の撮影装置。
6. 前記確認手段は、前記アプリケーションが使用するアクセス要求の内、前記特定の機能の動作の実行時に必要不可欠なアクセス要求について、その実行を前記デバイスポリシーが許可しているか否かを確認する
   ことを特徴とする請求項１乃至５のいずれか１項に記載の撮影装置。
7. 前記特定の機能の動作の実行後に、前記デバイスポリシーを設定する設定手段を更に備える
   ことを特徴とする請求項１乃至６のいずれか１項に記載の撮影装置。
8. 前記変更手段は、前記デバイスポリシーの前記第１の許可レベルを、前記デフォルトポリシーの前記第２の許可レベルと等しい許可レベルに変更する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の撮影装置。
9. 前記確認手段は、前記検知手段によって前記特定の機能の動作の準備状態を検知することなく、該特定の機能の動作の開始状態を検知している場合においても、前記アプリケーションによる、前記特定の機能へのアクセス要求の実行を前記デバイスポリシーが許可しているか否かを確認する
   ことを特徴とする請求項１乃至８のいずれか１項に記載の撮影装置。
10. 前記検知手段は、当該撮影装置に対する音声入力、当該撮影装置が起動されてからの経過時間、あるいは当該撮影装置の被写体の状態に基づいて、前記特定の機能の動作の状態を検知する
    ことを特徴とする請求項１乃至９のいずれか１項に記載の撮影装置。
11. アプリケーションからのアクセス要求に従って、装置が備える機能の動作を制御する撮影装置の制御方法であって、
    当該撮影装置の特定の機能の動作の状態を検知する検知工程と、
    当該撮影装置の機能に対するアクセスポリシーを記述したデバイスポリシーを読み込む読込工程と、
    前記検知工程によって前記特定の機能の動作の準備状態を検知している場合において、前記アプリケーションによる、前記特定の機能へのアクセス要求の実行を前記デバイスポリシーが許可しているか否かを確認する確認工程と、
    前記確認工程の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可している場合、前記特定の機能の動作を実行する実行工程と、
    前記確認工程の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可していない場合、警告情報を出力する出力工程と、
    前記検知工程によって前記特定の機能の動作の開始状態が検知され、前記デバイスポリシーにおいて前記アクセス要求に付与された第１の許可レベルが、当該撮影装置の機能に対する既定の許可状態を記述したデフォルトポリシーで記述されている第２の許可レベルよりも厳しい場合、前記デバイスポリシーの前記第１の許可レベルを前記デフォルトポリシーの前記第２の許可レベルよりも緩くならない範囲で変更する変更工程と
    を備えることを特徴とする撮影装置の制御方法。
12. アプリケーションからのアクセス要求に従って、装置が備える機能の動作を制御する撮影装置の制御をコンピュータに機能させるためのプログラムであって、
    前記コンピュータを、
    当該撮影装置の特定の機能の動作の状態を検知する検知手段と、
    当該撮影装置の機能に対するアクセスポリシーを記述したデバイスポリシーを読み込む読込手段と、
    前記検知手段によって前記特定の機能の動作の準備状態を検知している場合において、前記アプリケーションによる、前記特定の機能へのアクセス要求の実行を前記デバイスポリシーが許可しているか否かを確認する確認手段と、
    前記確認手段の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可している場合、前記検知手段が検知する前記特定の機能の動作を実行する実行手段と、
    前記確認手段の確認の結果、前記アクセス要求の実行を前記デバイスポリシーが許可していない場合、警告情報を出力する出力手段と、
    前記検知手段によって前記特定の機能の動作の開始状態が検知され、前記デバイスポリシーにおいて前記アクセス要求に付与された第１の許可レベルが、当該撮影装置の機能に対する既定の許可状態を記述したデフォルトポリシーで記述されている第２の許可レベルよりも厳しい場合、前記デバイスポリシーの前記第１の許可レベルを前記デフォルトポリシーの前記第２の許可レベルよりも緩くならない範囲で変更する変更手段と
    して機能させることを特徴とするプログラム。

Images