JP6098110B2 - 情報処理装置、データ保護方法、およびプログラム - Google Patents

Description

本発明は、データを保護する情報処理装置、データ保護方法、およびプログラムに関する。

技術の進歩により、コンピュータ（情報処理装置）の小型化が進んでいる。その結果、携帯情報端末のように、携帯可能なコンピュータも作られている。携帯情報端末には、無線によるデータ通信や電話機能を備えたものがある。昨今では、特に「スマートフォン」と呼ばれる、電話機能を備えた高機能の携帯情報端末に注目が集まっている。

スマートフォンに代表される携帯情報端末は、オフィスで使われるコンピュータと同様に、さまざまなアプリケーションソフトウェア（以下単に「アプリケーション」と呼ぶ）がインストール可能である。そのため、業務用のアプリケーションを携帯情報端末にインストールすれば、携帯情報端末を業務に利用することができる。携帯情報端末をオフィスのコンピュータと同じように業務に利用するニーズは実際にあり、既に携帯情報端末が業務に活用され始めている。

ところで、携帯情報端末にインストールできるアプリケーションには、いろいろな用途のものがある。携帯情報端末用のアプリケーションの１つに、例えば携帯情報端末内のデータをアクセスし外部ネットワークへ送信するものがある。このようなアプリケーションを業務アプリケーションと併用すると、ユーザの意図に反して、業務データが外部ネットワークへ送信されてしまう可能性がある。例えば、携帯情報端末用のアプリケーションとして、クラウドストレージとのデータの同期を取るアプリケーションがある。クラウドストレージとは、携帯情報端末から無線または有線で接続可能なネットワークに接続された、ストレージシステムである。データの同期を取るアプリケーションは、特定の同期用フォルダに格納されたファイルと、クラウドストレージに保存しておいた同名のファイルとを比較し、両方のファイルの内容を一致させる。このアプリケーション自体は有用なものである。しかし、このアプリケーションを業務アプリケーションと同時に利用すると、ユーザが同期用フォルダに業務データなどを配置してしまうような誤操作をしてしまった場合に、意図せずに業務データの外部送信が行われてしまう。

これまでは、企業は、業務に利用する携帯情報端末にインストール可能なアプリケーションを制限することで、携帯情報端末内の業務データの漏洩を防止してきた。ところが、携帯情報端末においてインストール可能なアプリを制限してしまうと、その携帯情報端末の利便性が損なわれてしまう。しかも、個人所有の携帯情報端末を業務に利用すること（ＢＹＯＤ（Bring Your Own Devices））へのニーズも高まりつつある。ＢＹＯＤを導入することで、個人用と業務用との２台の携帯情報端末を持ち歩く必要がなくなるとともに、普段から使い慣れた携帯情報端末を用いて業務を遂行できる。このことから、ＢＹＯＤは、ユーザにとって利便性が高い。ところが、ＢＹＯＤを導入していながら、携帯情報端末にインストール可能な業務以外のアプリケーションを制限したのでは、業務以外で携帯情報端末を使用する際の利便性が格段に悪くなり、ＢＹＯＤ本来の利点が損なわれてしまう。

なお、インストール可能なアプリケーションの制限以外にも、データの漏洩の防止策が考えられている。例えば、機密プログラムを実行する実行手段や、機密プログラム実行後、機密プログラムを記憶手段から削除する削除手段等、を備えるセキュリティシステムにおいて、一連の手続が完了するまでの間、タスクの切り替えを禁止する技術が考えられている。また、通信プログラムが活性化した場合、通信プログラムを実行するコンピュータのクリップボードをクリアさせ、他のプログラムを非活性化させる技術も考えられている。

特開平１０−２８３３２０号公報 特表２００３−５３５３９８号公報

しかし、タスクの切り替え禁止や、他のプログラムの非活性化技術により、業務アプリケーションの動作中に、他のアプリケーションの実行を禁止すると、携帯情報端末の利便性が損なわれてしまう。なお、業務アプリケーションの動作中とは、例えば業務アプリケーションが起動されてから終了するまでの期間である。

例えば、業務アプリケーションを一時的にバックグラウンドに移して、他のアプリケーションを利用できれば、他のアプリケーションの利用が容易となる。ところが、業務アプリケーション動作中における他のアプリケーションの実行を禁止した場合、他のアプリケーションを実行するには、業務アプリケーションを停止させることとなり、手間と時間がかかる。また、他のアプリケーションの中には、ユーザの起動操作をしなくても自動で起動するものもある。このようなアプリケーションは、ユーザが停止したつもりでも、バックグラウンドでは動作中の場合がある。このような自動で起動するアプリケーションが存在すると、ユーザが、業務アプリケーションを利用しているときに他のアプリケーションが実行されてしまい、非常に危険である。

なお、上記の説明では、業務アプリケーションが取り扱う業務データを保護する場合について説明したが、業務データ以外にも、他のアプリケーションのアクセスから保護すべきデータは存在する。そのようなデータを保護する場合も、そのデータを取り扱うアプリケーション動作中における他のアプリケーションの実行を禁止すると、利便性が損なわれてしまう。

また、携帯情報端末に限らず、オフィスなどで使用するコンピュータにおいても同様の問題が生じる。すなわち、業務とは無関係のアプリケーションの動作を抑止すれば、コンピュータ内の業務データを強固に保護できるが、コンピュータの利便性が低下してしまう。

一側面では、本発明は、データの保護に伴う利便性の低下を抑止できる情報処理装置、データ保護方法、およびプログラムを提供することを目的とする。

１つの案では、判断手段と制御手段とを有する情報処理装置が提供される。判断手段は、保護対象のデータを取り扱う第１のプログラムの起動から終了までの間に資源アクセスが行われたとすると、データの保護に対する脅威となる資源アクセスを示す脅威アクセス情報と、第２のプログラムの実行によりアクセスする可能性のある資源を示すアクセス対象資源情報とを参照し、第２のプログラムの実行により、データの保護に対する脅威となる資源アクセスが行われる可能性があるか否かを判断する。制御手段は、データの保護に対する脅威となる資源アクセスが行われる可能性がある場合、第１のプログラムの起動から終了までの間は、データに対する第２のプログラムに基づくアクセスが行われないように、第２のプログラムの実行を制御する。

１態様によれば、データ保護に伴う利便性の低下を抑止できる。

第１の実施の形態に係る情報処理装置の機能構成例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 携帯情報端末のハードウェア構成例を示す図である。 第２の実施の形態における業務データの保護方法の概要を示す図である。 携帯情報端末の機能を示すブロック図である。 制御対象アクセス記憶部のデータ構造の一例を示す図である。 リソースアクセス情報記憶部のデータ構造の一例を示す図である。 アプリケーションの実行制限処理の手順の一例を示すフローチャートである。 スケジューラとディスパッチャとの動作の一例を示す図である。 タスク制御処理の手順を示すフローチャートである。 タスクのスケジューリングの一例を示す図である。 第３の実施の形態における業務データ保護方法の概要を示す図である。 第３の実施の形態に係る携帯情報端末の機能を示すブロック図である。 制御対象アクセス記憶部のデータ構造の一例を示す図である。 第３の実施の形態におけるアプリケーション実行制限処理の手順を示すフローチャートである。 データ退避処理の手順を示すフローチャートである。 データ復元処理の手順を示すフローチャートである。 第３の実施の形態によるタスクスケジューリングの一例を示す図である。 第４の実施の形態におけるタスク管理構造体の一例を示す図である。 第４の実施の形態におけるスケジューラとディスパッチャの動作の一例を示す図である。 第４の実施の形態のタスク制御処理の手順を示すフローチャートである。 第５の実施の形態の制御対象テーブルの一例を示す図である。 第５の実施の形態のリソースアクセステーブルの一例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、保護対象のデータが漏洩することを防止することができる情報処理装置である。この情報処理装置は、例えば、オフィスなどに設置されるパーソナルコンピュータであってもよく、携帯情報端末であってもよい。

図１は、第１の実施の形態に係る情報処理装置の機能構成例を示す図である。情報処理装置Ｓは、１または複数の第１のプログラム１ａと１または複数の第２のプログラム１ｂ，１ｃを実行する。第１のプログラム１ａは、保護対象のデータ７を取り扱うプログラムである。第２のプログラムは、そのデータ７の取り扱いを想定していないプログラムである。なお、第１のプログラム１ａと第２のプログラム１ｂ，１ｃとは、例えば情報処理装置Ｓが有する記憶媒体に予め格納されている。

情報処理装置Ｓは、データ７を適切に保護するために、記憶手段２、判断手段３、制御手段４、実行時間割り当て手段６を有する。
記憶手段２は、脅威アクセス情報２ａとアクセス対象資源情報２ｂとを記憶する。脅威アクセス情報２ａは、保護対象のデータ７を取り扱う第１のプログラム１ａの起動から終了までの間（動作中）に資源アクセスが行われたとすると、データ７の保護に対する脅威となる資源アクセスを示す情報である。図１の例では、名称「プログラムα」である第１のプログラム１ａが取り扱うデータ７に対して脅威となるのは、メモリカードやネットワークへのアクセスであることが示されている。アクセス対象資源情報２ｂは、第２のプログラム１ｂ，１ｃの実行によりアクセスする可能性のある資源を示す情報である。図１の例では、名称「プログラムβ」である第２のプログラム１ｂの実行により、ネットワークとメモリカードとにアクセスされる可能性があることが示されている。また名称「プログラムγ」である第２のプログラム１ｃの実行により、カメラにアクセスされる可能性があることが示されている。

判断手段３は、脅威アクセス情報２ａとアクセス対象資源情報２ｂとを参照し、第２のプログラム１ｂ，１ｃの実行により、データ７の保護に対する脅威となる資源アクセスが行われる可能性があるか否かを判断する。例えば判断手段３は、脅威アクセス情報２ａに示されている資源アクセスの対象の資源を、アクセス対象資源として含む第２のプログラムをアクセス対象資源情報２ｂから検出する。そして判断手段３は、検出した第２のプログラムについて、そのプログラムの実行により、データ７の保護に対する脅威となる資源アクセスが行われる可能性があると判断する。

制御手段４は、第２のプログラム１ｂの実行により、データ７の保護に対する脅威となる資源アクセスが行われる可能性がある場合、第２のプログラム１ｂを制御対象とする。そして制御手段４は、第１のプログラム１ａの処理が開始されてから終了するまで、データ７に対する第２のプログラム１ｂに基づくアクセスが行われないように、第２のプログラム１ｂの実行を制御する。例えば制御手段４は、第１のプログラム１ａの処理が開始されてから終了するまで、データ７の保護に対する脅威となる資源アクセスが行われる可能性がある第２のプログラム１ｂの実行を抑止する。

実行時間割り当て手段６は、制御手段４からの指示に従って、プロセッサに実行させるタスク（プロセス）を切り替える。例えば第１のプログラム１ａと第２のプログラム１ｂ，１ｃそれぞれが起動されると、各プログラムを実行するためのタスク５ａ，５ｂ，５ｃが生成される。実行時間割り当て手段６は、プロセッサに実行させるタスクを切り替えることで、複数のタスク５ａ，５ｂ，５ｃを時分割で、プロセッサに実行させる。例えば実行時間割り当て手段６は、制御手段４により、第２のプログラム１ｂの実行を抑止する旨の指示を受けると、その第２のプログラム１ｂを実行するためのタスク５ｂに対して、プロセッサの実行時間の割り当てを抑止する。これにより、第２のプログラム１ｂは、実行されなくなる。

このような情報処理装置Ｓにおいて、例えば、最初に名称「プログラムβ」の第２のプログラム１ｂが起動されたものとする。第２のプログラム１ｂの起動により、第２のプログラム１ｂ実行用のタスク５ｂが生成される。この段階では、第１のプログラム１ａは起動されておらず、実行時間割り当て手段６により、タスク５ｂにプロセッサの実行時間が割り当てられ、プロセッサによりタスク５ｂを介して第２のプログラム１ｂが実行される。

次に、名称「プログラムα」の第１のプログラム１ａが起動されたものとする。第１のプログラム１ａの起動により、第１のプログラム１ａ実行用のタスク５ａが生成される。ここで、判断手段３は、脅威アクセス情報２ａを参照し、第１のプログラム１ａの動作中に、データ７の保護に対して脅威となる資源アクセスが、メモリカードとネットワークへのアクセスであることを認識する。そして判断手段３は、アクセス対象資源情報２ｂを参照する。そして判断手段３は、名称「プログラムβ」の第２のプログラム１ｂは、実行中にメモリカードとネットワークとへのアクセスの可能性があり、データ７の保護に対する脅威となる資源アクセスが行われる可能性があると判断する。他方、判断手段３は、名称「プログラムγ」の第２のプログラム１ｃは、実行中にメモリカードまたはネットワークにアクセスする可能性がなく、データ７の保護に対する脅威となる資源アクセスが行われる可能性がないと判断する。すると、制御手段４は、データ７に対する第２のプログラム１ｂに基づくアクセスが行われないように、第２のプログラム１ｂの実行を制御する。例えば制御手段４は、実行時間割り当て手段６に、プロセッサに実行させるタスクを、第２のプログラム１ｂ実行用のタスク５ｂに切り替えるのを抑止するように指示する。この指示に従って、実行時間割り当て手段６が、タスク５ｂへの切り替えを抑止する。その結果、名称「プログラムβ」の第２のプログラム１ｂの実行が抑止され、名称「プログラムα」の第１のプログラム１ａ実行用のタスク５ａに対してのみ、プロセッサの実行時間が割り当てられる。プロセッサは、タスク５ａを介して第１のプログラム１ａを実行し、その実行過程で、第１のプログラム１ａ内の命令に従って保護対象のデータ７へアクセスする。

その後、名称「プログラムγ」の第２のプログラム１ｃが起動されたものとする。第２のプログラム１ｃの起動により、第２のプログラム１ｃ実行用のタスク５ｃが生成される。判断手段３では、第２のプログラム１ｃについては、既に、データ７の保護に対する脅威となる資源アクセスが行われる可能性がないと判断している。そのため、制御手段４では、第２のプログラム１ｃの実行に関して、特別な制御は行わない。この場合、実行時間割り当て手段６は、名称「プログラムγ」の第２のプログラム１ｃへのプロセッサの実行時間の割り当てを許容する。その結果、名称「プログラムα」の第１のプログラム１ａと名称「プログラムγ」の第２のプログラム１ｃとが、時分割で実行される。

その後、名称「プログラムα」の第１のプログラム１ａの処理が終了したものとする。第１のプログラム１ａの動作中ではなくなったため、制御手段４は、実行時間割り当て手段６に対して、第２のプログラム１ｂの実行の抑止を解除するように指示する。すると、実行時間割り当て手段６は、第２のプログラム１ｂ実行用のタスク５ｂに対しても、プロセッサの実行時間を割り当てるようになる。その結果、２つの第２のプログラム５ｂ，５ｃが時分割で並行して実行される。

このようにして、第１のプログラム１ａの動作中は、データ７の保護に対して脅威となる資源アクセスを行う第２のプログラム１ｂの実行が抑止され、データ７の安全性を担保できる。他方、データ７の保護に対して脅威となる資源アクセスを行わない第２のプログラム１ｃについては、第１のプログラム１ａの動作中であっても実行可能である。そのため、情報処理装置Ｓの利便性の低下を最小限に抑えることができる。

なお制御手段４は、第１のプログラム１ａの実行が中断した場合、データ７を、第２のプログラム１ｂの実行によりアクセスされない記憶領域に退避し、その後、第２のプログラム１ｂを実行させてもよい。中断していた第１のプログラム１ａの実行を再開する際には、制御手段４は、記憶領域に退避していたデータ７を退避前の場所に復元し、その後、第１のプログラム１ａの実行を再開させる。

また、判断手段３は、第２のプログラム１ｂ，１ｃが安全であることが設定された場合、第２のプログラム１ｂ，１ｃの実行により、データ７の保護に対する脅威となる資源アクセスが行われる可能性はないと判断するようにしてもよい。

なお、判断手段３、制御手段４、および実行時間割り当て手段６は、例えば情報処理装置Ｓが有するプロセッサにより実現することができる。また、記憶手段２は、例えば情報処理装置Ｓが有するＲＡＭ（Random Access Memory）により実現することができる。

また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、スマートフォンなどの携帯情報端末にインストールした業務アプリケーションで利用されるデータ（業務データ）を保護するものである。すなわち、第２の実施の形態は、業務データを守りつつ、業務アプリケーションとさまざまな有用なアプリケーションとを携帯情報端末上に共存させるものである。

ここで、第２の実施の形態の詳細を説明する前に、他の技術における問題点について説明する。
業務データを守りつつ、業務アプリケーションとさまざまな有用なアプリケーションとを携帯情報端末上に共存させる方法として、いくつかの方法が考えられる。例えば、業務アプリ起動時に他のアプリケーションを停止させ、以降、業務アプリ終了までは他のアプリケーションの起動を制限するという方法が考えられる。また、業務アプリと併用してよいアプリケーション／併用してはいけないアプリケーションを管理するリストを持ち、そのリストから業務アプリ起動時に停止すべきアプリケーションを決める方法も考えられる。

しかし、これらの方法にはいくつかの問題点がある。まず、リストに基づいて併用可能なアプリケーションを管理する場合、リストが適正に管理される必要がある。しかし、スマートフォンではだれでもアプリケーションを作成でき、リストの管理者が知らないアプリケーションも数多く存在する。そのため、このようなリストを日々適切に更新して行くことは不可能である。リストに含まれないアプリケーションは業務アプリケーションと併用できてしまうため、業務データが危険にさらされることになる。

また、他のアプリケーションを確実に停止させることができない点も問題である。スマートフォンのアプリケーションはユーザが実際に操作するアプリケーション以外にも、ユーザには直接感知させずにバックグラウンドでさまざまな処理を行うアプリケーション（サービスアプリケーション）もある。このようなサービスアプリケーションは、一度停止をしても自動で再起動するものや停止要求を無視するものがある。また、バグなどにより、停止要求を無視するようなアプリケーションもある。業務アプリケーションと併用すると問題があるアプリケーションが、そのような停止できないアプリケーションであった場合、業務データが危険にさらされることになる。

また、業務データの存在を考慮に入れていない点も問題である。業務アプリケーションが終了しても、業務データが残っている場合には、業務アプリと併用すると問題があるアプリケーションが、業務データがあるにもかかわらず、起動、実行できてしまう。すると、その残された業務データを、問題のあるアプリケーションが外部ネットワークに送信してしまう可能性があり、業務データが危険にさらされることになる。

第２の実施の形態では、解決するアプローチとして、携帯情報端末において、業務利用の開始・終了を検出する。なお業務利用開始・終了の検出は、例えば業務アプリケーションの起動・終了や業務データの有無などから検出できる。そして携帯情報端末は、業務利用の開始から終了までの間、業務データの保護に対して脅威となるアプリケーションにとっては業務アプリケーションや業務データがあたかも存在しないかのように見えるように動作を制御する。

ここで、業務のデータの保護に対して脅威となるアプリケーションは、例えば「業務データの外部ネットワークへの送信」を行うアプリケーションである。「業務データの外部ネットワークへの送信」という処理を実行するアプリケーションが行うリソースアクセスとして、「業務データを読み出すリソースアクセス」と「業務データを外部に送信するリソースアクセス」の２種類のリソースアクセスがある。以下、これらのリソースアクセスが具体的にはどのようなリソースアクセスとなるのかを考える。

「業務データを読み出すリソースアクセス」は、業務アプリケーションと他のアプリケーションとで共用するリソースへのアクセスである。業務アプリケーション以外も読み書きできる領域に業務データが置かれる場合には、その領域の読み書きに必要なリソースアクセスを登録しているアプリケーションは、ユーザの意図に反して業務データを読み出してしまう可能性があると考える。このようなリソースアクセス制限を持つアプリケーションを制御対象とすることで、例えば、ストレージ同期サービスにおけるバックグラウンドでの同期動作など、ユーザが把握できないタイミングでの業務データの読み出しを抑止できる。スマートフォンでは、例えばメモリカードのような外部補助記憶領域へのアクセスが、「業務データを読み出すリソースアクセス」に相当する。

「業務データを外部に送信するリソースアクセス」は、ネットワークなどを用いて外部と通信を行うリソースの利用である。外部との通信を行うアプリケーションは、ユーザの意図に反して業務データの外部送信を行ってしまう可能性がある。このようなリソースアクセスを行う可能性のあるアプリケーションを制御対象とすることで、例えば、ストレージ同期サービスのフォルダに業務データを誤ってコピーしてしまった場合など、ユーザのミスによる業務データの外部送信を抑止できる。スマートフォンでは、「インターネット利用」や「ＳＭＳ利用（ＳＭＳ送信）」といった、外部との通信に必要なリソースアクセスが、「業務データを外部に送信するリソースアクセス」に相当する。

第２の実施の形態では、業務データの保護に対して脅威となるアプリケーションは、特定のリソースアクセスを行うアプリケーションとして、業務アプリケーションごとに設定できるものとする。

以下、第２の実施の形態について詳細に説明する。
図２は、第２の実施の形態のシステム構成例を示す図である。携帯情報端末１００は、無線によって携帯基地局２１と通信する。携帯基地局２１は、ネットワーク１０を介してサーバ１１に接続されている。

携帯情報端末１００は、携帯型のコンピュータである。例えば携帯情報端末１００は、タッチセンサ付き表示装置１１０を有している。タッチセンサ付き表示装置１１０は、ユーザが画面に触れた位置を示す位置情報を取得することができる。携帯情報端末１００は、例えばタッチセンサ付き表示装置１１０に、アプリケーションに対応するアイコン３１〜３５を表示する。そしてユーザが、タッチセンサ付き表示装置１１０の画面の任意のアイコンの位置に指で触れると、携帯情報端末１００は、指が接触した位置のアイコンに対応するアプリケーションを実行する。

第２の実施の形態では、携帯情報端末１００に、業務用のアプリケーションと、業務以外のアプリケーションとがインストールされているものとする。例えば、図２の例では、アイコン３１，３２が業務用のアプリケーションに対応付けられており、アイコン３３〜３５が業務以外のアプリケーションに対応付けられている。

また、携帯情報端末１００には、複数の機能ボタンが設けられている。例えば携帯情報端末１００に、ホームボタン１２７ａが設けられる。ホームボタン１２７ａは、画面表示をホーム画面に切り替えるためのボタンである。ホーム画面とは、携帯情報端末１００の電源投入後に最初に表示される画面である。

次に、携帯情報端末１００のハードウェア構成について説明する。
図３は、携帯情報端末のハードウェア構成例を示す図である。携帯情報端末１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１の機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。プロセッサ１０１には、バス１０３を介してメモリ１０２と複数の周辺機器が接続されている。

メモリ１０２は、携帯情報端末１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションの少なくとも一部が一時的に格納される。またメモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭなどの半導体記憶装置が用いられる。

バス１０３に接続されている周辺機器には、タッチセンサ付き表示装置１１０が構成要素であるＬＣＤ（Liquid Crystal Display）装置１１１とタッチセンサ１１２とがある。ＬＣＤ装置１１１は、液晶を利用した表示装置である。タッチセンサ１１２は、接触を検知するための素子を配置した透明なスクリーンである。ＬＣＤ装置１１１は、タッチセンサ１１２で表面が覆われている。そのため、ＬＣＤ装置１１１に表示された要素をユーザが触れると、接触位置がタッチセンサで検出される。

バス１０３にはさらに、フラッシュメモリ１２１、カメラ１２２、モーションセンサ１２３、方位センサ１２４、位置センサ１２５、スピーカ１２６、機能ボタン１２７、無線通信インタフェース１２８、マイク１２９、およびメモリカードリーダライタ１３０が接続されている。

フラッシュメモリ１２１は、不揮発性記憶素子の一種である。フラッシュメモリ１２１としては、例えばＮＡＮＤ型フラッシュメモリがある。フラッシュメモリ１２１には、例えばＯＳ、ドライバ、およびアプリケーションなどのソフトウェアが格納される。フラッシュメモリ１２１に格納されるソフトウェアには、業務に利用するアプリケーションや、ユーザが個人的に使用するアプリケーションがある。プロセッサ１０１は、フラッシュメモリ１２１からソフトウェアを読み出して、処理を実行する。

カメラ１２２は、ＣＣＤイメージセンサ（Charge Coupled Device Image Sensor）などの撮像素子によって、レンズを介して入射した画像を電気信号に変換する。モーションセンサ１２３は、３次元で加速度を検出するセンサである。方位センサ１２４は、携帯情報端末１００の向き（方位）を検出するセンサである。位置センサ１２５は、例えばＧＰＳ（Global Positioning System）の衛星からの信号を受信して、携帯情報端末１００の位置を検出する。スピーカ１２６は、プロセッサ１０１から送られた電気信号を音声に変換して出力する。機能ボタン１２７は、電源ボタンなどハードウェア的なボタンである。図２に示したホームボタン１２７ａは、機能ボタン１２７の一種である。無線通信インタフェース１２８は、無線によって通話やデータ通信を行う。無線通信インタフェース１２８は、例えば第３世代移動通信システムによる通信、Ｗｉ−Ｆｉ（Wireless Fidelity）、ＬＴＥ（Long Term Evolution）などによる通信を行うことができる。マイク１２９は、音を音声信号に変換する。マイク１２９は、音声信号をアナログ信号からディジタル信号に変換し、プロセッサ１０１に送信する。

メモリカードリーダライタ１３０は、メモリカード２２に対するデータの書き込み、またはメモリカード２２からのデータの読み出しを行う。メモリカードリーダライタ１３０には、メモリカード２２を挿抜することができる。メモリカード２２は、可搬型の記憶装置である。例えばメモリカード２２には、フラッシュメモリが内蔵される。メモリカード２２としては、例えばＳＤ（商標）メモリカードがある。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置も、図３に示した携帯情報端末１００と同様のハードウェアにより実現することができる。

携帯情報端末１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。携帯情報端末１００に実行させる処理内容を記述したプログラムは、さまざまな記録媒体に記録しておくことができる。例えば、携帯情報端末１００に実行させるフラッシュメモリ１２１に格納しておくことができる。プロセッサ１０１は、フラッシュメモリ１２１内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また携帯情報端末１００に実行させるプログラムを、メモリカード２２などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、フラッシュメモリ１２１にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

次に、第２の実施の形態における業務データの保護方法について説明する。
図４は、第２の実施の形態における業務データの保護方法の概要を示す図である。第２の実施の形態では、業務用のアプリケーション（業務アプリケーション）を実行するためのタスク１３１の生成と終了とに基づいて、携帯情報端末１００の業務の利用開始・終了が判断される。業務アプリケーションを実行するためのタスク１３１が存在している間は、業務データの保護に対して脅威となるアプリケーションを実行するためのタスク１３３の実行を制御する。ここで、業務データの保護に対して脅威となるアプリケーションとは、例えば、業務アプリケーションと共通のリソースへのアクセス命令が含まれるアプリケーションや、外部へのデータ送信命令が含まれるアプリケーションである。

例えば図４の例では、タスク１３１は、業務アプリケーションを実行しており、メモリカード２２に業務データ２３を格納している。この場合、メモリカード２２へのアクセス要求が含まれるアプリケーションは、業務データの保護に対して脅威となる。すなわち、そのアプリケーションのタスク１３３の実行により、メモリカード２２に対してアクセスされる場合がある。すると、業務データ２３が格納された記憶領域にアクセスされる可能性もある。業務アプリケーション以外のアプリケーションの実行により、業務データ２３に対するアクセスが行われたのでは、業務データ２３の安全性が損なわれる。他方、タスク１３４により実行されるアプリケーションは、メモリカード２２へのアクセス命令を含まないものとする。この場合、タスク１３４を実行しても、業務データの保護に対して脅威とはならないものと判断できる。

このような場合、業務アプリケーションを実行するためのタスク１３１が生成されてからそのタスク１３１が終了するまでの間、脅威の対象となるタスク１３３の実行が抑止される。タスク１３３の実行の抑止は、例えばスケジューラ１４０とディスパッチャ１５０の機能を利用できる。

スケジューラ１４０は、どのタスクに実行権を与えるのかを制御する。例えばスケジューラ１４０は、プロセッサ１０１の処理の実行時間を、細かい時間単位に分割し、その単位時間をタスクに割り当てる。プロセッサ１０１は、各単位時間において、その単位時間が割り当てられたタスクを実行する。これにより、マルチタスクと呼ばれる処理が実現され、ユーザからみると、複数のタスクが並列で実行されているように見える。

ディスパッチャ１５０は、スケジューラ１４０の立てたタスク実行のスケジュールに沿ってプロセッサ１０１がタスクを実行するように、タスクの切り替えを行う。ディスパッチャ１５０は、例えば、プロセッサ１０１のレジスタの値をメモリ１０２に退避し、次に実行するためのタスクに対応付けて退避されていた値を、レジスタに書き込むことで、プロセッサ１０１に実行させるタスクを切り替える。

ここで、スケジューラ１４０は、業務データの保護に対して脅威となるアプリケーションを実行するためのタスク１３３へは、プロセッサ１０１の実行時間を割り当てないように、タスクの実行スケジュールを立てる。すると、ディスパッチャ１５０は、業務アプリケーション実行用のタスク１３１や、業務データの保護に対して脅威とならないアプリケーション実行用のタスク１３４には、プロセッサ１０１の実行時間を割り当てる。これにより、各タスク１３１，１３４がプロセッサ１０１で実行される。他方、業務データの保護に対して脅威となるタスク１３３には、実行時間の割り当てが抑止される。プロセッサ１０１がタスク１３３を実行することがなくなる。このような制御が、例えば、業務アプリケーションを実行するためのタスク１３１が終了するまで継続される。

これにより、携帯情報端末１００が業務で利用されている間は、業務データの保護に対して脅威となるアプリケーションの実行が抑止される。その結果、業務データ２３の安全性が保たれる。また、携帯情報端末１００が業務で利用されている間であっても、業務データの保護に対して脅威とならないアプリケーションであれば実行することができる。そのため、携帯情報端末１００の高い利便性を維持することができる。

次に、図４に示したような業務データの保護を実現するための具体的な機能について説明する。
図５は、携帯情報端末の機能を示すブロック図である。なお図５に、携帯情報端末１００が有する機能のうち、業務データの保護に使用される機能のみを示している。

携帯情報端末１００はマルチタスクＯＳで制御されており、時分割で実行可能なタスク１３１〜１３５を有する。なおタスク１３１〜１３５は、ユーザからの要求などにより適宜生成され、処理が終了すれば消滅する。

タスク１３１〜１３５には、業務アプリケーションを実行するためのタスク１３１，１３２と、業務以外のアプリケーションを実行するためのタスク１３３〜１３５とがある。ここで、タスク１３１を用いて実行されている業務アプリケーションのアプリケーション名を「アプリＡ」とする。タスク１３２を用いて実行されている業務アプリケーションのアプリケーション名を「アプリＢ」とする。また、タスク１３３を用いて実行されているアプリケーションのアプリケーション名を「アプリＸ」とする。タスク１３４を用いて実行されているアプリケーションのアプリケーション名を「アプリＹ」とする。タスク１３５を用いて実行されているアプリケーションのアプリケーション名を「アプリＺ」とする。

また携帯情報端末１００は、図４に示したように、スケジューラ１４０とディスパッチャ１５０とを有している。さらに携帯情報端末１００は、制御対象アクセス記憶部１６０、リソースアクセス情報記憶部１７０、制御対象アクセス抽出部１８１、制御対象アプリケーション抽出部１８２、業務利用判断部１８３、およびスケジューリング指示部１８４を有している。

制御対象アクセス記憶部１６０は、業務アプリケーションごとに、その業務アプリケーションの利用中に、業務データの保護に対して脅威となるアプリケーションからのアクセス制限を行うリソースアクセスを示す情報（制御対象アクセス情報）を記憶する。例えばメモリ１０２、フラッシュメモリ１２１、またはメモリカード２２の記憶領域の一部が、制御対象アクセス記憶部１６０として使用される。

リソースアクセス情報記憶部１７０は、アプリケーションごとに、そのアプリケーションの実行時にアクセスされる可能性のあるリソースを記憶する。例えばメモリ１０２、フラッシュメモリ１２１、またはメモリカード２２の記憶領域の一部が、リソースアクセス情報記憶部１７０として使用される。

制御対象アクセス抽出部１８１は、業務アプリケーションが利用中であれば、制御対象アクセス記憶部１６０から、その業務アプリケーションの業務データを保護するための制御対象のリソースアクセスを抽出する。また制御対象アクセス抽出部１８１は、利用中の業務アプリケーションの名称を、制御対象アクセス記憶部１６０から抽出する。

制御対象アプリケーション抽出部１８２は、リソースアクセス情報記憶部１７０から、制御対象のリソースアクセスを行うアプリケーションを抽出する。
業務利用判断部１８３は、携帯情報端末１００の業務利用の開始・終了を判断する。例えば業務利用判断部１８３は、制御対象アクセス記憶部１６０に業務アプリケーションとして設定されているアプリケーションの起動や終了、アプリが生成したファイルの有無などから、業務利用の開始・終了を検出する。そして業務利用判断部１８３は、携帯情報端末１００が業務利用の開始・終了をスケジューリング指示部１８４に通知する。例えば業務利用判断部１８３は、携帯情報端末１００のプロセスの実行状況を監視し、制御対象アクセス情報に示されている業務アプリケーションが起動した段階で、業務の開始と判断する。そして業務利用判断部１８３は、その業務アプリケーションの終了をもって、業務の終了と判断する。携帯情報端末１００が業務に利用されている状態において、さらに別の業務アプリケーションが開始されたときは、業務利用判断部１８３は、別の業務アプリケーションが起動されたことをスケジューリング指示部１８４に通知してもよい。また、開始された業務アプリを区別するために、業務利用判断部１８３は、開始された業務アプリケーションのアプリケーション名とともに、スケジューリング指示部１８４に通知してもよい。

スケジューリング指示部１８４は、業務利用の開始または終了の通知を受けると、制御対象アクセス抽出部１８１や制御対象アプリケーション抽出部１８２を用いて、業務アプリケーションを示す情報と制御対象アプリケーションを示す情報とを取得する。例えばスケジューリング指示部１８４は、制御対象アクセス抽出部１８１から、業務アプリケーションのアプリケーション名のリスト（業務アプリケーションリスト）を取得する。またスケジューリング指示部１８４は、制御対象アクセス抽出部１８１から、利用されている業務アプリケーションに応じた制御対象のリソースアクセスの名称のリスト（制御対象アクセスリスト）を取得する。またスケジューリング指示部１８４は、制御対象アプリケーション抽出部１８２から、制御対象リソースに応じた制御対象アプリケーションのアプリケーション名のリスト（制御対象アプリケーションリスト）を取得する。スケジューリング指示部１８４は、制御対象アクセス抽出部１８１や制御対象アプリケーション抽出部１８２から取得した情報に基づいて、スケジューラ１４０およびディスパッチャ１５０に対して、特定のタスクへのスイッチの可否などの制御指示を行う。なおスケジューリング指示部１８４は、動作指示をスケジューラ１４０に対してのみ行い、動作指示の内容をスケジューラ１４０からディスパッチャ１５０へ伝達するようにしてもよい。

このような機能の携帯情報端末１００により、業務データを保護することができる。なお、図５に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。

また、図５に示したスケジューラ１４０とディスパッチャ１５０以外の各機能を持つコンポーネントの配置としては、ミドルウェアとして実装してもよいし、ＯＳのカーネル（kernel）に実装してもよい。ミドルウェアに実装する場合には、業務利用判断部１８３は、例えばＯＳのアプリケーションの起動・停止のフレームワークと連動して動作し、スケジューリング指示部１８４によるスケジューラへの指示はシステムコールとして実現できる。

またスケジューラ１４０とディスパッチャ１５０以外の各機能を、カーネルで実装する場合、スケジューリング指示部１８４からスケジューラへの指示は関数コールとして実現することができる。またリソースアクセス情報記憶部１７０がミドルウェア上に構築されている場合、スケジューリング指示部１８４は、リソースアクセス情報記憶部１７０内の情報をシステムコールなどの方法で入手することができる。

さらに、図５に示すスケジューリング指示部１８４は、図１に示す第１の実施の形態の判断手段３と制御手段４とを合わせた機能の一例である。また、図５に示すスケジューラ１４０とディスパッチャ１５０とを合わせた機能は、図１に示す第１の実施の形態の実行時間割り当て手段６の一例である。さらに、制御対象アクセス記憶部１６０とリソースアクセス情報記憶部１７０とを合わせた機能は、図１に示す第１の実施の形態の記憶手段１の一例である。

次に、制御対象アクセス記憶部１６０に記憶される制御対象アクセス情報について説明する。
図６は、制御対象アクセス記憶部のデータ構造の一例を示す図である。制御対象アクセス記憶部１６０には、制御対象テーブル１６１が格納されている。制御対象テーブル１６１には、業務アプリケーションごとの制御対象アクセス情報が登録されている。

制御対象テーブル１６１には、業務アプリ名、制御対象リソースアクセス、および制御要否の欄が設けられている。業務アプリ名の欄には、業務アプリケーションのアプリケーション名が設定される。制御対象リソースアクセスの欄には、対応する業務アプリケーションの利用中に、業務アプリケーション以外のアプリケーションからのアクセスの制限などの制御を行うリソースアクセス（制御対象リソースアクセス）の名称が設定される。リソースアクセスの名称には、リソースアクセスでのアクセス先となるリソースの名称が用いられる。制御要否の欄には、対応する業務アプリケーションの業務データを保護する制御を行うか否かを示すフラグが設定される。図６の例では、業務データの保護制御を行う場合、制御要否の欄に「要」と設定され、業務データの保護制御を行わない場合、制御要否の欄に「不要」と設定される。

ここで、制御対象リソースアクセスは、業務データの保護に対して脅威となるアプリケーションを、そのアプリケーションの行うリソースアクセスから判断するためのものである。例えばスマートフォンでは、各アプリケーションは、自身が行うリソースアクセスをＯＳ上のデータベース（ＤＢ）に登録し、登録されていないアプリケーションからのリソースアクセスは禁止とすることができる。これにより、アプリが勝手にリソース（例えば電話帳など）へのアクセスを行うことが抑止される。このＤＢを、制御対象テーブル１６１として利用して、業務データの保護に対して脅威となるアプリケーションを抽出してもよい。

図６の例では、名称「アプリＡ」の業務アプリケーションが利用されているときの制御対象リソースアクセスは、「メモリカード、ネットワーク、ＳＭＳ（Short Message Service）」である。名称「アプリＢ」の業務アプリケーションが利用されているときの制御対象リソースアクセスは、「メモリカード、ネットワーク、ＳＭＳ、カメラ」である。また名称「アプリＡ」および「アプリＢ」それぞれの業務アプリケーションの業務データを保護する制御を行うことが設定されている。

次に、リソースアクセス情報記憶部１７０に記憶されるリソースアクセス情報について説明する。
図７は、リソースアクセス情報記憶部のデータ構造の一例を示す図である。リソースアクセス情報記憶部１７０には、リソースアクセステーブル１７１が格納されている。リソースアクセステーブル１７１には、アプリケーションごとのリソースアクセス情報が登録されている。

リソースアクセステーブル１７１には、アプリ名とリソースアクセスとの欄が設けられている。アプリ名の欄には、携帯情報端末１００に実装されたアプリケーションのアプリケーション名が設定される。アクセス対象リソースの欄には、対応するアプリケーションの実行中にアクセスされる可能性のあるリソースの名称が設定される。

図７の例では、名称「アプリＡ」のアプリケーションの実行中は、メモリカードにアクセスが行われる可能性がある。また例えば名称「アプリＸ」のアプリケーションの実行中は、ネットワークとメモリカードとにアクセスが行われる可能性がある。

なお、図７に示したようなリソースアクセステーブル１７１は、例えば携帯情報端末１００のＯＳによって生成され、保持される。
次に、業務データを保護するためのアプリケーションの実行制限処理の手順を説明する。

図８は、アプリケーションの実行制限処理の手順の一例を示すフローチャートである。
［ステップＳ１０１］業務利用判断部１８３は、業務利用の開始／終了のイベントを待つ。例えば業務利用判断部１８３は、タスクの実行状況を監視し、アプリケーションの開始または終了のイベントを検出する。業務利用判断部１８３は、アプリケーションの開始または終了のイベントを検出すると、制御対象テーブル１６１を参照し、開始または終了したアプリケーションのアプリケーション名が、業務アプリ名の欄に登録されているか否かを判断する。起動または終了したアプリケーションのアプリケーション名が、業務アプリ名の欄に登録されている場合、業務利用判断部１８３は、業務利用の開始または終了イベントが発生したと判断する。

［ステップＳ１０２］業務利用判断部１８３は、制御対象テーブル１６１における開始または終了イベントの対象となる業務アプリケーションの制御要否の値を更新する。例えば業務利用判断部１８３は、業務アプリケーションの開始イベントを検出した場合、その業務アプリケーションの制御要否を「要」に設定する。また業務利用判断部１８３は、業務アプリケーションの終了イベントを検出した場合、その業務アプリケーションの制御要否を「不要」に設定する。そして業務利用判断部１８３は、業務利用の開始または終了イベントの発生を、スケジューリング指示部１８４に通知する。

［ステップＳ１０３］スケジューリング指示部１８４は、制御対象アクセス抽出部１８１と連携し、利用されている業務アプリケーションを示す業務アプリケーションリスト、および利用されている業務アプリケーションに応じた制御対象アクセスリストを取得する。

例えばスケジューリング指示部１８４は、制御対象アクセス抽出部１８１に対して、業務アプリケーションリストと制御対象アクセスリストとを要求する。すると制御対象アクセス抽出部１８１は、制御対象テーブル１６１から、制御要否「要」と設定されている制御対象アクセス情報の業務アプリ名の欄に設定されているアプリケーション名を抽出する。次に制御対象アクセス抽出部１８１は、業務アプリ名の欄から抽出したアプリケーション名を列挙した、業務アプリケーションリストを作成する。さらに制御対象アクセス抽出部１８１は、制御対象テーブル１６１から、制御要否「要」と設定されている制御対象アクセス情報の制御対象リソースの欄に設定されているリソースアクセスの名称を抽出する。次に制御対象アクセス抽出部１８１は、抽出したリソースアクセスの名称を列挙した、制御対象アクセスリストを作成する。そして制御対象アクセス抽出部１８１は、業務アプリケーションリストと制御対象アクセスリストとを、スケジューリング指示部１８４に送信する。

［ステップＳ１０４］スケジューリング指示部１８４は、制御対象アプリケーション抽出部１８２と連携し、制御対象リソースに応じた制御対象アプリケーションリストを取得する。

例えばスケジューリング指示部１８４は、制御対象アプリケーション抽出部１８２に対して、制御対象アプリケーションリストを要求する。すると制御対象アプリケーション抽出部１８２は、リソースアクセステーブル１７１から、制御対象アクセスリストに含まれるリソースの少なくとも１つを、アクセス対象リソースとするリソースアクセス情報を検出する。次に制御対象アプリケーション抽出部１８２は、検出したリソースアクセス情報のアプリ名の欄に設定されているアプリケーション名を列挙した、制御対象アプリケーションリストを作成する。そして制御対象アプリケーション抽出部１８２は、作成した制御対象アプリケーションリストを、スケジューリング指示部１８４に送信する。

［ステップＳ１０５］スケジューリング指示部１８４は、制御対象アプリケーションから、利用中の業務アプリケーションを除外する。例えばスケジューリング指示部１８４は、制御対象アプリケーションリストに含まれるアプリケーション名のうち、業務アプリケーションリストにも含まれるアプリケーション名を特定する。そして、スケジューリング指示部１８４は、特定したアプリケーション名を、制御対象アプリケーションリストから削除する。

［ステップＳ１０６］スケジューリング指示部１８４は、制御対象アプリケーションがあるか否かを判断する。例えばスケジューリング指示部１８４は、制御対象アプリケーションリストに少なくとも１つのアプリケーション名が含まれていれば、制御対象アプリケーションがあると判断する。制御対象アプリケーションがある場合、処理がステップＳ１０７に進められる。制御対象アプリケーションがない場合、処理がステップＳ１０８に進められる。

［ステップＳ１０７］スケジューリング指示部１８４は、スケジューラ１４０への指示内容を、「制御対象アプリケーションへのタスクスイッチ不可」に決定する。その後、処理がステップＳ１０９に進められる。

［ステップＳ１０８］スケジューリング指示部１８４は、スケジューラ１４０への指示内容を、「すべてのアプリケーションへのタスクスイッチ可」に決定する。
［ステップＳ１０９］スケジューリング指示部１８４は、スケジューラ１４０およびディスパッチャ１５０へ、ステップＳ１０７またはＳ１０８で決定した指示内容での動作指示を送信する。制御対象アプリケーションへのタスクスイッチ不可を指示する場合、動作指示には、制御対象アプリケーションリストが含まれる。なおスケジューリング指示部１８４は、動作指示をスケジューラ１４０にのみ送信し、スケジューラ１４０からディスパッチャ１５０へ動作指示の内容を伝達するようにしてもよい。その後、処理がステップＳ１０１に進められる。

このようにして業務利用の開始／終了のイベントがあるごとに、スケジューリング指示部１８４から、スケジューラ１４０およびディスパッチャ１５０に動作指示が出される。 次に、スケジューリング指示部１８４からの動作指示を受けた、スケジューラ１４０とディスパッチャ１５０との動作について説明する。

図９は、スケジューラとディスパッチャとの動作の一例を示す図である。スケジューラ１４０は、実行待ちキュー１４１と待機状態キュー１４２とを有している。
実行待ちキュー１４１には、実行可能な状態のタスクが登録される。図９の例では、業務アプリケーションを実行するためのタスク４１と、アイドルループ処理を実行するためのタスク４２とが登録されている。アイドルループ処理は、プロセッサ１０１に実行させるプログラムがないときに、実行させる処理である。アイドルループ処理のタスク４２は、優先順位が最も低く設定されており、実行待ちキュー１４１内のタスクがアイドルループ処理のタスク４２のみとなったときに実行される。

待機状態キュー１４２には、待機状態のタスクが登録される。待機状態のタスクとは、例えばＩＯ待ちなどで、すぐには実行できない状態のタスクである。図９の例では、一般のアプリケーション（業務アプリケーションと制御対象アプリケーション以外のアプリケーション）を実行するためのタスク４３と、制御対象アプリケーションを実行するためのタスク４４とが、待機状態キュー１４２に登録されている。

スケジューラ１４０は、さらに制御対象アプリケーション記憶部１４３とキュー操作部１４４とを有している。
制御対象アプリケーション記憶部１４３は、スケジューリング指示部１８４からの動作指示で指定に含まれる、制御対象アプリケーションリストを記憶する。制御対象アプリケーション記憶部１４３は、例えばスケジューラ１４０に割り当てられた、メモリ１０２内の記憶領域である。

キュー操作部１４４は、実行待ちキュー１４１と待機状態キュー１４２へのタスクの登録、実行待ちキュー１４１内のタスクのディスパッチャ１５０への実行指示、待機状態キュー１４２から実行待ちキュー１４１へのタスクの移動などを制御する。例えばキュー操作部１４４は、実行待ちキュー１４１に登録されているタスクを、優先度などに基づいた所定の順番でディスパッチャ１５０に出力する。

またキュー操作部１４４は、待機状態キュー１４２に登録されているタスクが実行可能な状態になると、そのタスクを実行待ちキュー１４１に移動する。ただし、キュー操作部１４４は、制御対象アプリケーション記憶部１４３を参照し、実行可能になったタスクで実行するアプリケーションが制御対象アプリケーションか否かを判断する。そして、キュー操作部１４４は、実行可能になったタスクで実行するアプリケーションが制御対象アプリケーションの場合、そのタスクは実行待ちキュー１４１に移動せずに、待機状態キュー１４２に留めておく。例えば図９の例では、タスク４３は、制御対象アプリケーションを実行するためのものではないため、実行可能状態になると実行待ちキュー１４１に移される。他方、タスク４４は、制御対象アプリケーションを実行するためのものであるため、実行可能状態となっても、実行待ちキュー１４１には移されない。なお、制御対象アプリケーションを実行するためのタスク４４は、例えば携帯情報端末１００の業務利用が終了した後であれば、実行待ちキュー１４１に移すことができる。

ディスパッチャ１５０は、アプリケーション判断部１５１とタスクスイッチ部１５２とを有する。ディスパッチャ１５０は、スケジューラ１４０からタスク４５を取得すると、そのタスク４５で実行されるアプリケーションが制御対象アプリケーションか否かを判断する。そしてアプリケーション判断部１５１は、取得したタスク４５が、制御対象アプリケーション以外のアプリケーションを実行するためのタスクであれば、取得したタスク４５をタスクスイッチ部１５２に渡す。なお、制御対象アプリケーション以外のアプリケーションには、業務アプリケーションが含まれる。またアプリケーション判断部１５１は、取得したタスク４５が、制御対象アプリケーションを実行するためのタスクであれば、取得したタスク４５をスケジューラ１４０に戻す。スケジューラ１４０に戻されたタスク４５は、キュー操作部１４４により待機状態キュー１４２に登録される。

タスクスイッチ部１５２は、プロセッサ１０１に実行させるタスクを、渡されたタスクに切り替える。タスクの切り替え処理では、実行中のタスクのプリエンプションと、次に実行するタスクのディスパッチとが行われる。プリエンプションは、プロセッサ１０１が実行中のタスクを中断する処理である。ディスパッチは、プロセッサ１０１の計算応力をタスクに割り当てる処理である。プリエンプションを行う場合、タスクスイッチ部１５２は、中断するタスクを実行するためのプロセッサの状態（コンテキスト）をメモリに書き出す。またディスパッチを行う場合、タスクスイッチ部１５２は、プロセッサ１０１に実行させるタスクのコンテキストを、レジスタに書き込む。このようなプロセッサ１０１のレジスタ内のコンテキストの書き換え（コンテキストスイッチ）によって、プロセッサ１０１が実行するタスクが切り替えられる。

このように制御対象アプリケーションを実行するためのタスクは、待機状態キュー１４２から実行待ちキュー１４１に移されない。また、タスクが実行待ちキュー１４１に登録された後に、そのタスクにより実行するアプリケーションが制御対象アプリケーションになったとしても、そのタスクはディスパッチャ１５０でディスパッチが拒否され、スケジューラ１４０に戻される。これにより、制御対象アプリケーションを実行するためのタスクには、プロセッサ１０１の実行時間の割り当てが行われなくなり、そのタスクの実行が抑止される。

次に、１つのタスクの生成から終了までの、タスク制御処理の手順について説明する。
図１０は、タスク制御処理の手順を示すフローチャートである。なおタスク制御処理は、タスクの生成により開始される。

［ステップＳ１２１］スケジューラ１４０は、生成されたタスクを管理対象のタスクとし、そのタスクを待機状態キュー１４２に登録する。
［ステップＳ１２２］スケジューラ１４０は、管理対象のタスクが実行可能となったことを検知する。例えばＩＯの応答待ちをしていたタスクに関し、ＩＯの応答が返されたことを検知する。

［ステップＳ１２３］スケジューラ１４０は、制御対象アプリケーション記憶部１４３を参照し、制御対象アプリケーションのアプリケーション名を取得する。
［ステップＳ１２４］スケジューラ１４０は、管理対象のタスクを実行待ちキューに移動してよいか否かを判断する。例えばスケジューラ１４０は、管理対象のタスクにより実行するアプリケーションが、制御対象アプリケーションでなければ、実行待ちキューに移動してよいと判断する。実行待ちキューに移動してよい場合、処理がステップＳ１２５に進められる。また実行待ちキューに移動できない場合、処理がステップＳ１２１に進められる。

［ステップＳ１２５］スケジューラ１４０は、管理対象のタスクを、実行待ちキュー１４１に移動する。移動されたタスクは、実行待ちキュー１４１で保持される。
［ステップＳ１２６］スケジューラ１４０は、実行待ちキュー１４１におけるディスパッチの順番が、管理対象のタスクの実行順になると、管理対象のタスクをディスパッチの対象として、ディスパッチャ１５０に渡す。

［ステップＳ１２７］ディスパッチャ１５０は、制御対象アプリケーション記憶部１４３を参照し、制御対象アプリケーションのアプリケーション名を取得する。
［ステップＳ１２８］ディスパッチャ１５０は、管理対象のタスクが、ディスパッチをしてよいタスクか否かを判断する。例えばディスパッチャ１５０は、管理対象のタスクにより実行するアプリケーションが、制御対象アプリケーションでなければ、ディスパッチしてよいと判断する。ディスパッチしてよい場合、処理がステップＳ１２９に進められる。またディスパッチできない場合、処理がステップＳ１３１に進められる。

［ステップＳ１２９］ディスパッチャ１５０は、管理対象のタスクをディスパッチし、プロセッサ１０１に所定時間実行させる。その後、ディスパッチャ１５０は、管理対象のタスクをプリエンプションする。

［ステップＳ１３０］スケジューラ１４０は、管理対象のタスクが終了したか否かを判断する。例えば管理対象のタスクで実行するアプリケーションの処理が終了した場合、そのタスクは終了する。タスクが終了した場合、タスク制御処理が終了する。タスクが終了していなければ、処理がステップＳ１３１に進められる。

［ステップＳ１３１］スケジューラ１４０は、管理対象のタスクを待機状態キュー１４２へ移動する。移動されたタスクは、待機状態キュー１４２で保持される。その後、処理がステップＳ１２１に進められる。

このようにして、タスクに対してプロセッサ１０１の処理能力が時分割で割り当てられる。ただし、携帯情報端末１００が業務に利用されている間は、制御対象アプリケーションを実行するためのタスクに対しては、プロセッサ１０１の処理能力の割り当ては行われない。これにより、業務アプリケーションの実行中は、業務データの保護に対して脅威となるプリケーションの実行が抑止される。

図１１は、タスクのスケジューリングの一例を示す図である。各業務アプリケーションの制御対象リソースは、図６の制御対象テーブル１６１に示した通りであるものとする。すなわち「アプリＡ」は、メモリカード利用、ネットワーク、ＳＭＳのリソースアクセスによる脅威があり、「アプリＢ」はメモリカード利用、ネットワーク、ＳＭＳに加えて、カメラも脅威であると考えている。

またリソースアクセステーブル１７１の内容は図７に示した通りであるものとする。すなわち、業務用の「アプリＡ」、「アプリＢ」および、業務以外の「アプリＸ」、「アプリＹ」、「アプリＺ」がある。また、「アプリＡ」のアクセス対象リソースは、メモリカードである。「アプリＢ」のアクセス対象リソースは、ネットワーク・カメラ・メモリカードである。「アプリＸ」のアクセス対象リソースは、ネットワーク・メモリカードである。「アプリＹ」のアクセス対象リソースは、カメラである。「アプリＺ」のアクセス対象リソースは、ＧＰＳである。

図１１の例では、まず「アプリＸ」が実行されている。そして時刻ｔ１に「アプリＡ」のタスク１３１が起動されている。するとタスク１３１の起動が業務利用判断部１８３で検知される。そして業務利用判断部１８３からスケジューリング指示部１８４へ、「アプリＡ」の業務開始が通知される。

スケジューリング指示部１８４は、業務開始の通知を受けて、制御対象アクセス抽出部１８１に問い合わせる。制御対象アクセス抽出部１８１は、制御対象テーブル１６１を参照して、現在動作している業務アプリケーションは「アプリＡ」であり、「アプリＡ」の制御対象リソースアクセスは、メモリカード、ネットワーク、ＳＭＳへのアクセスであること判断する。そして、制御対象アクセス抽出部１８１は、スケジューリング指示部１８４へ、「アプリＡ」を含む業務アプリケーションリストと、「メモリカード」、「ネットワーク」、「ＳＭＳ」を含む制御対象アクセスリストとを、スケジューリング指示部１８４に返答する。

さらに、スケジューリング指示部１８４は、「制御対象リソースアクセス」のアクセス先である「メモリカード、ネットワーク、ＳＭＳ」を制御対象アプリケーション抽出部１８２に渡して、制御対象アプリケーションを問い合わせる。制御対象アプリケーション抽出部１８２は、リソースアクセステーブル１７１を参照して、「メモリカード、ネットワーク、ＳＭＳ」のいずれかにアクセスする可能性のあるアプリケーション「アプリＡ」、「アプリＢ」、「アプリＸ」を抽出する。そして制御対象アプリケーション抽出部１８２は、抽出したアプリケーションの名称を列挙した制御対象アプリケーションリストをスケジューリング指示部１８４に返答する。

この段階でスケジューリング指示部１８４は、利用されている業務アプリケーションの名称として「アプリＡ」を取得し、制御対象アプリケーションの名称として、「アプリＡ」、「アプリＢ」、「アプリＸ」を取得したことになる。この情報を元に、スケジューリング指示部１８４は、「制御対象アプリケーション」から「業務アプリケーション」を除外した、「アプリＢ」、「アプリＸ」に対してタスクスイッチを抑止するようにスケジューラ１４０およびディスパッチャ１５０に指示を出す。なお「アプリＢ」は業務アプリケーションとして登録されているが、この段階では起動していないので、タスクスイッチの対象となることもない。これにより、「アプリＡ」を起動したことで「アプリＸ」へのタスクスイッチが抑止される。

その後、「アプリＹ」のタスク１３４が起動されている。「アプリＹ」は制御対象アプリケーションではない。そのため、「アプリＡ」を用いて携帯情報端末１００が業務に利用されていても、「アプリＹ」のタスク１３４は実行される。

時刻ｔ２に「アプリＢ」の業務が開始されると、「アプリＢ」は業務アプリケーションであるため、「アプリＢ」による業務開始が業務利用判断部１８３からスケジューリング指示部１８４に通知される。するとスケジューリング指示部１８４は、制御対象アクセス抽出部１８１から、業務アプリケーションリストと制御対象アクセスリストとを取得する。制御対象アクセス抽出部１８１から取得した業務アプリケーションリストには、「アプリＡ」、「アプリＢ」が含まれる。また制御対象アクセス抽出部１８１から取得した制御対象アクセスリストには、「メモリカード」、「ネットワーク」、「ＳＭＳ」、「カメラ」が含まれる。またスケジューリング指示部１８４は、制御対象アプリケーション抽出部１８２から、制御対象アプリケーションリストを取得する。リソースアクセステーブル１７１を参照すると、「メモリカード、ネットワーク、ＳＭＳ、カメラ」の少なくとも１つをアクセス対象リソースとしているのは、「アプリＡ」、「アプリＢ」、「アプリＸ」、「アプリＹ」である（図７参照）。そのため、制御対象アプリケーション抽出部１８２から取得した制御対象アプリケーションリストには、「アプリＡ」、「アプリＢ」、「アプリＸ」、「アプリＹ」が含まれる。ここで、業務アプリケーションは制御対象アプリケーションから除外され、制御対象アプリケーションに特定されるのは「アプリＸ」、「アプリＹ」となる。その結果、「アプリＢ」の業務開始の通知が出された後は、「アプリＸ」のタスク１３３と「アプリＹ」のタスク１３４とへのタスクスイッチが抑止される。

この状況でも「アプリＺ」は制御対象アプリに含まれていないため、通常通り起動し、利用することができる。
時刻ｔ３に「アプリＡ」のタスク１３１が終了している。すると、業務利用判断部１８３が「アプリＡ」の終了を検知する。そして業務利用判断部１８３からスケジューリング指示部１８４へ、「アプリＡ」の業務終了が通知される。この時点は「アプリＢ」のタスク１３２は依然として存在している。そのため制御対象アクセス抽出部１８１からスケジューリング指示部１８４へ、「アプリＢ」を含む業務アプリケーションリストが送信される。また制御対象アクセス抽出部１８１からスケジューリング指示部１８４へ、「メモリカード」、「ネットワーク」、「ＳＭＳ」、「カメラ」を含む制御対象アクセスリストが送信される。さらに制御対象アプリケーション抽出部１８２からスケジューリング指示部１８４へ、「アプリＸ」、「アプリＹ」を含む制御対象アプリケーションリストが送信される。その結果、制御対象アプリケーションから業務アプリケーションを除外した、「アプリＡ」、「アプリＸ」、「アプリＹ」へのタスクスイッチが抑止される。なお、「アプリＡ」は終了済みであるためタスクスイッチの対象となることもなく、「アプリＡ」のタスクへのタスクスイッチを抑止しても動作上の問題はない。

その後、「アプリＺ」のタスク１３５が起動されている。「アプリＺ」は制御対象アプリケーションではないため、「アプリＺ」のタスク１３５は実行される。
時刻ｔ４に「アプリＢ」のタスク１３２が終了している。すると、業務利用判断部１８３からスケジューリング指示部１８４へ、「アプリＢ」の業務終了が通知される。この場合、制御対象アクセス抽出部１８１は、空の業務アプリケーションリストと、空の制御対象アクセスリストを、スケジューリング指示部１８４に送信する。さらに制御対象アプリケーション抽出部１８２は、空の制御対象アプリケーションリストを、スケジューリング指示部１８４へ送信する。制御対象アプリケーションリストが空となった場合には、すべてのアプリケーションのタスクへのタスクスイッチを許可するように、スケジューリング指示部１８４からスケジューラ１４０やディスパッチャ１５０に指示が出される。その結果、なにも制限されていない通常状態になる。移行は、すべてのアプリケーションが実行可能となり、「アプリＸ」、「アプリＹ」、「アプリＸ」が時分割で実行される。

このようにして、携帯情報端末１００を業務で利用中は、実行されている業務アプリケーションに対応付けて制御対象リソースとして指定されているリソースにアクセスするアプリケーションは、プロセッサ１０１の実行時間の割り当て対象から除外される。その結果、業務データが、業務以外のアプリケーションの実行により外部に漏洩することが抑止され、業務データの安全性が確保される。

また、アプリケーションを停止させるのではなく、スケジューラにより実行させないようにすることで、業務利用が終わった後も速やかに業務開始前の状況を復元できるといった効果もある。

また、動作を制御する対象のアプリケーションをアプリケーション名ではなく特定のリソースアクセスとすることで、未知の危険性をはらんでいるアプリケーションとの併用を抑止することができ、業務データを安全に保つことができる。

さらに、携帯情報端末１００上へのアプリケーション導入に特に制限がなく、携帯情報端末１００を業務利用していない時には、ユーザが自由に使うことができる。
〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、業務データを一時的に退避することで、携帯情報端末を業務で利用中であっても、業務以外の任意のアプリケーションを利用できるようにしたものである。

図１２は、第３の実施の形態における業務データ保護方法の概要を示す図である。第３の実施の形態では、第２の実施の形態と同様に、業務アプリケーションを実行するためのタスク２３１の生成と終了とに基づいて、携帯情報端末２００の業務の利用開始・終了が判断される。第３の実施の形態では、業務アプリケーションを実行するためのタスク２３１の動作中は、業務データ２４の保護に対して脅威となるアプリケーションを実行するためのタスク２３３を実行する前に、業務データ２４が退避データ記憶部２９０に退避される。退避データ記憶部２９０は、例えば携帯情報端末２００のＲＡＭ内の、カーネル空間として管理されている記憶領域である。カーネルとは、ＯＳの中核となる部分である。ＯＳは、カーネル空間として管理されている記憶領域には、アプリケーションの実行に基づいたアクセスができないように設計されている。そのため、カーネルの管理領域に退避された業務データ２５に、アプリケーションを実行に基づいてアクセスすることはできない。

例えば、業務アプリケーション実行用のタスク２３１の実行により、メモリカード２２に業務データ２４を格納されているものとする。このとき、メモリカード２２にアクセスする可能性のあるアプリケーションのタスク２３３を実行させる場合を想定する。この場合、スケジューラ２４０は、そのタスク２３３へ切り替えの前に、退避アプリケーションのタスク２３６への切り替えをディスパッチャ２５０に指示する。すると、ディスパッチャ２５０は、退避アプリケーションのタスク２３６に、プロセッサ１０１の実行時間を割り当てる。これにより、プロセッサ１０１でタスク２３６が実行される。タスク２３６の実行により、メモリカード２２に格納されている業務データ２４が、退避データ記憶部２９０に移動される。さらにメモリカード２２から業務データ２４が削除される。

その後、ディスパッチャ２５０は、業務以外のアプリケーションのタスク２３３に、プロセッサの実行時間を割り当てる。するとプロセッサ１０１は、タスク２３３を用いてアプリケーションを実行する。このとき、アプリケーション内の命令に従ってプロセッサ１０１がメモリカード２２にアクセスしても、業務データ２４は既に退避されており、退避された業務データ２５にアクセスされることはない。これにより、業務データの安全性が保たれる。

なお、第３の実施の形態に係る携帯情報端末２００のハードウェア構成は、図３に示した第２の実施の形態に係る携帯情報端末１００のハードウェア構成と同様である。
図１３は、第３の実施の形態に係る携帯情報端末の機能を示すブロック図である。携帯情報端末２００は、時分割で実行可能なタスク２３１〜２３７を有する。なおタスク２３１〜２３７は、ユーザからの要求などにより適宜生成され、処理が終了すれば消滅する。

タスク２３１〜２３５は、それぞれ第２の実施の形態のタスク１３１〜１３５と同じアプリケーションを実行する。タスク２３６は、退避アプリケーションを実行する。退避アプリケーションは、業務データを退避データ記憶部２９０に退避するためのアプリケーションである。タスク２３７は、データ復元アプリケーションを実行する。データ復元アプリケーションは、退避データ記憶部２９０に退避された業務データを、元の場所に復元するためのアプリケーションである。

また携帯情報端末２００は、図１２に示したように、スケジューラ２４０、ディスパッチャ２５０、および退避データ記憶部２９０を有している。さらに携帯情報端末２００は、制御対象アクセス記憶部２６０、リソースアクセス情報記憶部２７０、制御対象アクセス抽出部２８１、制御対象アプリケーション抽出部２８２、業務利用判断部２８３、およびスケジューリング指示部２８４を有している。

リソースアクセス情報記憶部２７０、制御対象アプリケーション抽出部２８２は、図５に示した第２の実施の形態の同名の要素と同じ機能を有する。
制御対象アクセス記憶部２６０は、業務アプリケーションごとの制御対象アクセス情報を記憶する。第３の実施の形態における制御対象アクセス情報には、業務アプリケーションに対応する退避アプリケーションの名称や、復元アプリケーションの名称が含まれる。

制御対象アクセス抽出部２８１は、スケジューリング指示部２８４からの要求に応じて、制御対象アクセス記憶部２６０に基づいて、業務アプリケーションリストと制御対象サクセスリストとを生成する。そして、制御対象アクセス抽出部２８１は、生成した業務アプリケーションリストと制御対象サクセスリストとを、スケジューリング指示部２８４に渡す。なお第３の実施の形態における制御対象アクセス抽出部２８１は、業務アプリケーションリストに、各業務アプリケーション対応する退避アプリケーションと復元アプリケーションとの名称を含める。

業務利用判断部２８３は、業務アプリケーションの起動イベントや終了イベントを検知により、携帯情報端末２００の業務利用開始・終了を判断する。また業務利用判断部２８３は、業務利用の中断・再開のイベントを検知する。例えば、業務利用判断部２８３は、アプリケーションの切り替え操作を検知して、業務アプリケーションを背面へ回す操作が行われた場合、退避アプリケーションを実行するためのタスク２３６を動作させるようにスケジューリング指示部２８４に通知する。そして業務利用判断部２８３は、退避アプリケーションを実行するためのタスク２３６から、データ退避完了の報告を受け取ると、業務利用が中断したと判断する。また業務利用判断部２８３は、業務アプリケーションを前面へ出す操作が行われた場合、復元アプリケーションを実行するためのタスク２３７を動作させるように、スケジューリング指示部２８４に通知する。そして業務利用判断部２８３は、復元アプリケーションを実行するためのタスク２３７から、データ復元完了の報告を受け取ると、業務利用が再開したと判断する。そして業務利用判断部２８３は、業務利用の開始・中断・再開・終了などの情報をスケジューリング指示部２８４に通知する。

スケジューリング指示部２８４は、業務利用判断部２８３からのデータ退避／復元要求を受け、退避・復元アプリケーションを起動する。退避アプリケーションを起動した場合、スケジューリング指示部２８４は、スケジューラ２４０とディスパッチャ２５０とに対して、制御対象アプリケーションと業務アプリケーションへのタスクスイッチの不可を指示する。データ復元アプリケーションを起動した場合も同様に、スケジューリング指示部２８４は、スケジューラ２４０とディスパッチャ２５０とに対して、制御対象アプリケーションと業務アプリケーションへのタスクスイッチの不可を指示する。

またスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、業務アプリケーションリストと制御対象アクセスリストとを取得する。またスケジューリング指示部２８４は、制御対象アプリケーション抽出部２８２から制御対象アプリケーションリストを取得する。そしてスケジューリング指示部２８４は、取得した情報を用い、業務利用の開始・中断・再開・終了の通知に応じて、スケジューラ２４０とディスパッチャ２５０とに対して、タスクスイッチを指示する。

次に、第３の実施の形態における、第２の実施の形態と相違する部分の詳細について説明する。
図１４は、制御対象アクセス記憶部のデータ構造の一例を示す図である。制御対象アクセス記憶部２６０には、制御対象テーブル２６１が格納されている。第３の実施の形態の制御対象テーブル２６１は、第２の実施の形態の制御対象テーブル１６１（図６参照）に対して、退避アプリと復元アプリとの欄が追加されている。退避アプリの欄には、業務アプリ名に示される業務アプリケーションの業務データを退避させるための退避アプリケーションの名称が設定される。復元アプリの欄には、業務アプリ名に示される業務アプリケーションの業務データを復元させるための復元アプリケーションの名称が設定される。

次に、業務データを保護するためのアプリケーションの実行制限処理の手順を説明する。
図１５は、第３の実施の形態におけるアプリケーション実行制限処理の手順を示すフローチャートである。

［ステップＳ２０１］業務利用判断部２８３は、業務利用の開始／中断／再開／終了／中断操作／再開操作のイベントを待つ。例えば業務利用判断部２８３は、タスクの実行状況を監視し、アプリケーションの開始／中断／再開／終了／中断操作／再開操作のイベントを検出する。業務利用判断部２８３は、アプリケーションの開始／中断／再開／終了／中断操作／再開操作のイベントを検出すると、制御対象テーブル２６１を参照し、イベント対象のアプリケーションが、業務アプリケーションか否かを判断する。イベント対象のアプリケーションが業務アプリケーションであれば、業務利用判断部２８３は、業務利用の開始／中断／再開／終了／中断操作／再開操作のイベントが発生したと判断する。

なお、業務利用の中断イベントは、例えば業務データの退避完了の通知の取得である。また業務利用の再開イベントは、例えば業務データの復元完了の通知の取得である。また業務利用の中断操作のイベントは、例えば業務アプリケーションを、画面上で背面へ移動させる操作入力である。また業務利用の再開操作のイベントは、例えば業務アプリケーションを、画面上で前面へ移動させる操作入力である。

［ステップＳ２０２］業務利用判断部２８３は、開始／終了のイベントを検出した場合、制御対象テーブル２６１における開始または終了イベントの対象となる業務アプリケーションの制御要否の値を更新する。そして業務利用判断部２８３は、業務利用の開始／中断／再開／終了のイベントが発生した場合、そのイベントの発生をスケジューリング指示部２８４に通知する。また業務利用判断部２８３は、業務利用の中断操作のイベントが発生した場合、業務データの退避要求をスケジューリング指示部２８４に通知する。さらに業務利用判断部２８３は、業務利用の再開操作のイベントが発生した場合、業務データの復元要求をスケジューリング指示部２８４に通知する。なお各通知には、イベントの対象となる業務アプリケーションの名称が含まれる。

［ステップＳ２０３］スケジューリング指示部２８４は、制御対象アクセス抽出部２８１と連携し、利用されている業務アプリケーションを示す業務アプリケーションリスト、および利用されている業務アプリケーションに応じた制御対象アクセスリストを取得する。なお、業務アプリケーションリストには、業務アプリケーションごとの退避／復元アプリケーションの名称が含まれるものとする。

［ステップＳ２０４］スケジューリング指示部２８４は、制御対象アプリケーション抽出部２８２と連携し、制御対象リソースに応じた制御対象アプリケーションリストを取得する。

［ステップＳ２０５］スケジューリング指示部２８４は、制御対象アプリケーションから、利用中の業務アプリケーションを除外する。
［ステップＳ２０６］スケジューリング指示部２８４は、業務利用判断部２８３からの通知内容を判断する。通知内容が退避要求であれば、処理がステップＳ２０７に進められる。通知内容が復元要求であれば、処理がステップＳ２０９に進められる。通知内容が業務利用の中断であれば、処理がステップＳ２１１に進められる。通知内容が業務利用の開始／再開／終了のいずれかであれば、処理がステップＳ２１２に進められる。

［ステップＳ２０７］スケジューリング指示部２８４は、退避要求を受け取った場合、イベントの対象となった業務アプリケーションの退避アプリケーションを起動する。
［ステップＳ２０８］スケジューリング指示部２８４は、指示内容を、「制御対象アプリケーションと業務アプリケーションへのタスクスイッチ不可」に決定する。その後、処理がステップＳ２１５に進められる。

［ステップＳ２０９］スケジューリング指示部２８４は、復元要求を受け取った場合、イベントの対象となった業務アプリケーションの復元アプリケーションを起動する。
［ステップＳ２１０］スケジューリング指示部２８４は、指示内容を、「制御対象アプリケーションと業務アプリケーションへのタスクスイッチ不可」に決定する。その後、処理がステップＳ２１５に進められる。

［ステップＳ２１１］スケジューリング指示部２８４は、指示内容を、「業務アプリケーションへのタスクスイッチ不可」に決定する。その後、処理がステップＳ２１５に進められる。

［ステップＳ２１２］スケジューリング指示部２８４は、通知が、業務利用の開始／再開／終了のいずれかであれば、制御対象アプリケーションがあるか否かを判断する。制御対象アプリケーションがある場合、処理がステップＳ２１３に進められる。制御対象アプリケーションがない場合、処理がステップＳ２１４に進められる。

［ステップＳ２１３］スケジューリング指示部２８４は、制御対象アプリケーションがあれば、指示内容を「制御対象アプリケーションへのタスクスイッチ不可」に決定する。その後、処理がステップＳ２１５に進められる。

［ステップＳ２１４］スケジューリング指示部２８４は、制御対象アプリケーションがなければ、指示内容を「すべてのアプリケーションへのタスクスイッチ可」に決定する。
［ステップＳ２１５］スケジューリング指示部２８４は、スケジューラ２４０およびディスパッチャ２５０へ、決定した指示内容での動作指示を送信する。なお、制御対象アプリケーションへのタスクスイッチ不可を指示する場合、動作指示には、制御対象アプリケーションリストが含まれる。また業務アプリケーションへのタスクスイッチ不可を指示する場合、動作指示には、業務アプリケーションリストが含まれる。

このようにして、スケジューリング指示部２８４からスケジューラ２４０およびディスパッチャ２５０へ、動作指示が出される。動作指示は、例えば図９に示した第２の実施の形態と同様に、スケジューラ２４０内の制御対象アプリケーション記憶部に格納される。そして、格納された動作指示に従って、スケジューラ２４０とディスパッチャ２５０とが、スイッチ不可に設定されたアプリケーションを実行するためのタスクへのスイッチを抑止する。

次にデータ退避／復元アプリケーションに関してさらに詳細に説明する。退避アプリケーションやデータ復元アプリケーションは、業務に固有なファイル（業務データを含んだファイル）を特定のデータ退避領域に退避・復元するものである。データ退避領域としてはメモリ空間、ストレージ空間、ネットワーク空間が考えられる。

まず、メモリ空間に業務データを退避する場合、例えば、制御対象アプリケーションからはアクセスできないメモリ空間領域に業務データが退避される。スマートフォンのＯＳは従来の汎用ＯＳをベースとしていることが多い。そのため、タスクごとのメモリ空間は互いに独立している。そこで、例えば、退避アプリケーションのタスクの実行の生成により、保存したいファイルの大きさのメモリ空間を確保し、ファイルをそのメモリ空間上に展開し、元のファイルそのものは消去することがきる。この場合、退避アプリケーションとテータ復元アプリケーションとは同一のアプリケーションとすることができる。データ退避／復元アプリケーションを実行するためのタスクが実行されると、復元要求があった段階で、自身のメモリ空間に展開したファイル（業務データを含んだファイル）が、ファイルシステム上の既定の場所に戻される。また、多くのメモリが必要となる可能性があることから、退避アプリケーションを実行することで、業務データを圧縮して退避されるようにしてもよい。また退避／復元アプリケーションが、他のアプリの影響を受けないようにカーネルの機能として実行されるようにしてもよい。

また、ストレージ空間に業務データを退避させる場合、例えば制御対象アプリケーションからはアクセスできないファイルシステム領域に、業務データが退避される。スマートフォンでは、アプリケーション間で共通して利用できるストレージ空間以外に、アプリケーション専用のストレージを用意しているものもある。携帯情報端末２００がこのようなスマートフォンであれば、退避／復元アプリケーションの実行により、退避／復元アプリケーション専用のストレージ領域を確保し、確保したストレージ領域をデータの退避先として利用することができる。なおアプリケーション専用のストレージ領域は利用可能な大きさが限定されていることも多い。そのため、圧縮などによりファイルサイズを小さくして、業務データを退避させてもよい。

また、ネットワーク空間に業務データを退避される場合、例えば制御対象アプリケーションからはアクセスできない退避用クラウドストレージ領域に、業務データが退避される。この場合、退避アプリケーションと復元アプリケーションのみアクセス可能なネットワーク上のストレージ装置の内の領域を定義する。そして、退避アプリケーションを実行することで、ネットワーク上のストレージ装置内の予め定義された領域に業務データが退避される。また復元アプリケーションを実行することで、その領域に退避された業務データが、携帯情報端末２００内に復元される。この場合、途中の通信路の盗聴などを防ぐために、暗号化された通信路を、退避・復元のための通信路として用いることができる。また、退避・復元アプリケーションであることを確認するような認証の機構を組み込んでもよい。

図１６は、データ退避処理の手順を示すフローチャートである。この処理は、退避アプリケーションが起動されたときに実行される。
［ステップＳ２２１］退避アプリケーションを実行するためのタスク２３６は、業務データの含まれるファイル（退避ファイル）一覧を取得する。例えば退避アプリケーションには、対応する業務アプリケーションの業務データを含むファイルの保管領域（フォルダなど）が予め定義されている。そして退避アプリケーションを実行するためのタスク２３６は、その保管領域に格納されているファイルを、退避ファイルとして抽出する。

［ステップＳ２２２］タスク２３６は、データ退避領域の必要量を算出する。例えばタスク２３６は、退避ファイルのファイルサイズの合計に、退避ファイルの復元場所を示す情報のデータ量を加算した値を、データ退避領域の必要量とする。

［ステップＳ２２３］タスク２３６は、データ退避領域を確保する。データ退避領域は、メモリ内、ストレージ装置内、ネットワーク上のサーバ内などに確保することができる。

［ステップＳ２２４］タスク２３６は、業務データの含まれる退避ファイルを、１つ読み込む。
［ステップＳ２２５］タスク２３６は、退避ファイルの退避前の保管場所を示す情報（例えば保管場所のディレクトリパス）を、データ退避領域に書き込む。

［ステップＳ２２６］タスク２３６は、退避ファイルの退避前の場所を示す情報に関連付けて、退避ファイルをデータ退避領域に書き込む。
［ステップＳ２２７］タスク２３６は、退避前の保管場所から退避ファイルを削除する。

［ステップＳ２２８］タスク２３６は、すべての退避ファイルの退避処理が完了したか否かを判断する。未処理の退避ファイルがあれば、処理がステップＳ２２４に進められる。すべての退避ファイルの退避処理が完了していれば、処理がステップＳ２２９に進められる。

［ステップＳ２２９］タスク２３６は、データ退避処理の完了を、業務利用判断部２８３に通知する。
このようにして、業務データを退避させることができる。次にデータ復元処理について説明する。

図１７は、データ復元処理の手順を示すフローチャートである。この処理は、復元アプリケーションが起動されたときに実行される。
［ステップＳ２４１］復元アプリケーションを実行するためのタスク２３７は、データ退避領域のファイル一覧を取得する。

［ステップＳ２４２］タスク２３７は、データ退避領域から、退避ファイルの退避前の場所を示す情報を、１つ読み込む。
［ステップＳ２４３］タスク２３７は、データ退避領域から退避ファイルを読み込む。

［ステップＳ２４４］タスク２３７は、退避ファイルの退避前の場所に、読み込んだ退避ファイルを書き込む。
［ステップＳ２４５］タスク２３７は、書き込んだ退避ファイルを、データ退避領域から削除する。この際、タスク２３７は、削除した退避ファイルに関連付けられた、退避ファイルの退避前の場所を示す情報も、データ退避領域から削除する。

［ステップＳ２４６］タスク２３７は、すべての退避ファイルの復元処理が完了したか否かを判断する。未処理の退避ファイルがあれば、処理がステップＳ２４２に進められる。すべての退避ファイルの復元処理が完了した場合、処理がステップＳ２４７に進められる。

［ステップＳ２４７］タスク２３７は、データ復元処理の完了を、業務利用判断部２８３に通知する。
このようにして、業務データを復元することができる。

次に、業務データの退避と復元とを伴うタスクスケジューリング例について説明する。
図１８は、第３の実施の形態によるタスクスケジューリングの一例を示す図である。図１８の例では、業務アプリケーション「アプリＡ」、および、業務以外のアプリケーション「アプリＸ」があるものとする。また、それぞれのアプリのリソースアクセスは、図７のリソースアクセステーブル１７１に示した通りであるものとする。すなわち、業務アプリケーション「アプリＡ」に基づいて、メモリカードへのアクセスが行われる。またアプリケーション「アプリＸ」に基づいて、ネットワークまたはメモリカードへのアクセスが行われる。

また、業務アプリケーション「アプリＡ」に関する制御対象リソースは、図１４に示した制御対象テーブル２６１の通りであるものとする。すなわち業務アプリケーション「アプリＡ」の業務データの保護に対して、メモリカード、ネットワーク、ＳＭＳのリソースアクセスによる脅威が存在する。

図１８には、フォアグラウンドで実行されているアプリケーションの時間に伴う遷移が示されている。図１８の例では、アプリＸを実行するためのタスク２３３（図１３参照）にプロセッサの時間が割り当てられ、タスク２３３が実行させているとき、時刻ｔ２１に、業務アプリケーション「アプリＡ」が起動されている。業務アプリケーション「アプリＡ」の起動により、業務利用判断部２８３からスケジューリング指示部２８４へ、「アプリＡ」による業務開始が通知される。するとスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、「アプリＡ」を含む業務アプリケーションリストと、メモリカード、ネットワーク、ＳＭＳを含む制御対象アクセスリストとを取得する。

またスケジューリング指示部２８４は、制御対象アプリケーション抽出部２８２から、「アプリＡ」と「アプリＸ」とを含む制御対象アプリケーションリストを取得する。スケジューリング指示部２８４は、取得した制御対象アプリケーションリストから、業務アプリケーションリストに含まれる「アプリＡ」を削除する。そしてスケジューリング指示部２８４は、制御対象アプリケーションリストに残った「アプリＸ」を実行するためのタスク２３３をスケジューリング対象から外すように、スケジューラ２４０とディスパッチャ２５０とに指示を出す。その結果、「アプリＡ」を実行するためのタスク２３１がフォアグラウンドに表示され、プロセッサで実行される。

その後、時刻ｔ２２に、「アプリＡ」のタスク２３１をバックグラウンドに回し、「アプリＸ」のタスク２３３をフォアグラウンドに表示する操作が行われたものとする。業務利用判断部２８３は、その操作を検知し、業務データの退避要求を、スケジューリング指示部２８４に通知する。

退避要求を受けたスケジューリング指示部２８４は、制御対象アクセス抽出部２８１からの情報の取得により、実行されている業務アプリケーションが「業務アプリＡ」であることを認識する。このときスケジューリング指示部２８４は、退避アプリケーションが「退避アプリＡ」であること、および復元アプリケーションが「復元アプリＡ」ことも合わせて認識する。またスケジューリング指示部２８４は、制御対象アクセス抽出部２８１と制御対象アプリケーション抽出部２８２とからの情報の取得により、制御対象のアプリケーションが「アプリＸ」であることを認識する。

このときの通知は、退避要求である。そこでスケジューリング指示部２８４は、「退避アプリＡ」が起動していなかったら、「退避アプリＡ」を起動する。そしてスケジューリング指示部２８４は、業務アプリケーション「アプリＡ」のタスク２３１と制御対象アプリケーション「アプリＸ」のタスク２３３とをスケジューリング対象から外すように、スケジューラ２４０とディスパッチャ２５０とに指示する。その後「退避アプリＡ」を実行するためのタスク２３６により、業務データ２４が退避データ記憶部２９０に格納される。このようにすることで、業務データの退避中は業務アプリケーションも制御対象のアプリケーションも動作せず、安全な退避が可能となる。

時刻ｔ２３に業務データの退避が完了すると、退避アプリケーション「退避アプリＡ」を実行するためのタスク２３６は、業務利用判断部２８３に対して、「アプリＡ」の業務データ退避の完了を通知する。すると業務利用判断部２８３は、スケジューリング指示部２８４に対して、「アプリＡ」を用いた業務利用の中断を通知する。中断通知を受けたスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、業務アプリケーションが「アプリＡ」、退避アプリケーションが「退避アプリＡ」、復元アプリケーションが「復元アプリＡ」であることを取得する。またスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、制御対象アクセスが「メモリカード、ネットワーク、ＳＭＳ」であることを取得する。さらにスケジューリング指示部２８４は、制御対象アプリケーション抽出部２８２から、制御対象アプリケーションが「アプリＡ」と「アプリＸ」とであることを取得する。このとき、スケジューリング指示部２８４は、通知内容が業務利用の中断であることから、業務アプリケーション「アプリＡ」をスケジューリングの対象から外すように、スケジューラ２４０とディスパッチャ２５０とに指示する。

時刻ｔ２４に、再び、業務アプリケーション「アプリＡ」をフォアグラウンドに回す操作（再開操作）が行われると、業務利用判断部２８３がその操作を検知する。操作を検知した業務利用判断部２８３は、「アプリＡ」の業務データの復元要求をスケジューリング指示部２８４に対して通知する。復元要求を受けたスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、業務アプリケーションが「アプリＡ」、退避アプリケーションが「退避アプリＡ」、復元アプリケーションが「復元アプリＡ」であることを取得する。またスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、制御対象アクセスが「メモリカード、ネットワーク、ＳＭＳ」であることを取得する。さらにスケジューリング指示部２８４は、制御対象アプリケーション抽出部２８２から、制御対象アプリケーションが「アプリＡ」と「アプリＸ」とであることを取得する。

ここで、通知が復元要求であることから、スケジューリング指示部２８４は、「復元アプリＡ」が起動していなかったら起動する。そしてスケジューリング指示部２８４は、業務アプリケーション「アプリＡ」と制御対象アプリケーション「アプリＸ」とをスケジューリング対象から外すように、スケジューラ２４０とディスパッチャ２５０とに指示する。その後「復元アプリＡ」を実行するためのタスク２３７により、業務データ２４が退避データ記憶部２９０から読み出され、元あった場所に格納される。

時刻ｔ２５に業務データ２４の復元処理が完了すると、「復元アプリＡ」のタスク２３７から業務利用判断部２８３に対して、「アプリＡ」の業務データ２４の復元処理の完了が通知される。すると業務利用判断部２８３は、スケジューリング指示部２８４に対して、「アプリＡ」を用いた業務利用の再開を通知する。業務利用の再開の通知を受けたスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、業務アプリケーションが「アプリＡ」、退避アプリケーションが「退避アプリＡ」、復元アプリケーションが「復元アプリＡ」であることを取得する。またスケジューリング指示部２８４は、制御対象アクセス抽出部２８１から、制御対象アクセスが「メモリカード、ネットワーク、ＳＭＳ」であることを取得する。さらにスケジューリング指示部２８４は、制御対象アプリケーション抽出部２８２から、制御対象アプリケーションが「アプリＡ」と「アプリＸ」とであることを取得する。

スケジューリング指示部２８４は、通知内容が再開であることから、制御対象アプリケーションである「アプリＡ」と「アプリＸ」とから、業務アプリケーションである「アプリＡ」を除外する。そしてスケジューリング指示部２８４は、業務アプリケーションを除外後の制御対象アプリケーションである「アプリＸ」を、スケジューリングの対象から外すように、スケジューラ２４０とディスパッチャ２５０とに指示する。

このように第３の実施の形態では、業務アプリケーションのタスクの実行を中断する場合には、その業務アプリケーションの業務データを、脅威となるアプリケーションから安全な場所に退避させる。これにより、業務アプリケーションの実行を中断している間は、業務データの保護に対して脅威となるアプリケーションを実行しても、業務データが保護される。その結果、業務アプリケーションの実行を中断している間は、業務データの保護に対して脅威となるアプリケーションについても実行可能となり、携帯情報端末２００の利便性が向上する。

〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、スケジューラにおける制御対象アプリケーションの管理を、図９に示した制御対象アプリケーション記憶部１４３ではなく、各タスク（プロセス）の管理情報を用いて行うものである。

図１９は、第４の実施の形態におけるタスク管理構造体の一例を示す図である。第４の実施の形態におけるタスク管理構造体５０には、タスクの名前（Process Name）やタスクの識別子（ProcessID）に加え、「IsScheduleable」という追加フラグ５１が設定されている。追加フラグ５１は、タスク管理構造体で示されるタスクを実行してよいか否かを示すフラグである。例えば追加フラグ５１には、「true」または「false」が設定される。「true」はタスクを実行してよいことを示し、「false」はタスクを実行してはならないことを示す。

このような追加フラグ５１を用いて、各タスクの実行の要否を管理することができる。
図２０は、第４の実施の形態におけるスケジューラとディスパッチャの動作の一例を示す図である。なお図２０において、第２の実施の形態と同じ機能の要素には、図９に示した第２の実施の形態の要素と同じ符号を付し、説明を省略する。

第４の実施の形態におけるスケジューラ１４０ａは、第２の実施の形態の制御対象アプリケーション記憶部１４３に代えて、フラグ設定部１４５を有する。フラグ設定部１４５は、スケジューリング指示部１８４からの指示を受け取ると、その指示に従って、各タスクのタスク管理構造体に追加フラグを設定する。例えばフラグ設定部１４５は、スケジューリング指示部１８４からタスクスイッチ不可と指定されたアプリケーションのタスクには、「IsScheduleable=false」という追加フラグを設定する。またフラグ設定部１４５は、スケジューリング指示部１８４からタスクスイッチ可と指定されたアプリケーションのタスクには、「IsScheduleable=true」という追加フラグを設定する。

図２０の例では、業務アプリケーションのタスク４１の追加フラグの値は「true」、制御対象アプリケーションのタスク４４の追加フラグの値は「false」に設定されている。
キュー操作部１４４ａは、追加フラグの値を参照して、各タスクへのスイッチの可否を判断する。例えばキュー操作部１４４ａは、追加フラグの値が「false」のタスクのみを、待機状態キュー１４２から実行待ちキュー１４１に移動する。すなわち、追加フラグの値が「false」に設定されているタスク４４は、実行可能状態となっても待機状態キュー１４２から実行待ちキュー１４１には移動されない。

またディスパッチャ１５０ａのアプリケーション判断部１５１ａは、スケジューラ１４０ａから渡されたタスク４５の追加フラグの値に基づいて、そのタスク４５をディスパッチするか否かを判断する。例えばアプリケーション判断部１５１ａは、タスク４５の追加フラグの値が「false」であれば、そのタスク４５をタスクスイッチ部１５２に渡し、プロセッサが実行するタスクを、タスク４５に切り替えさせる。他方、タスク４５の追加フラグの値が「false」であれば、アプリケーション判断部１５１ａは、タスク４５をスケジューラ１４０ａの待機状態キュー１４２に戻す。このようにアプリケーション判断部１５１ａは、追加フラグの値が「false」のタスクへのディスパッチを抑止する。

次に、１つのタスクの生成から終了までの、タスク制御処理の手順について説明する。
図２１は、第４の実施の形態のタスク制御処理の手順を示すフローチャートである。なおタスク制御処理は、タスクの生成により開始される。なお図２１のステップＳ３０１，Ｓ３０２，Ｓ３０５，Ｓ３０６，Ｓ３０９〜Ｓ３１１の処理は、それぞれ第２の実施の形態における図１０のステップＳ１２１，Ｓ１２２，Ｓ１２５，Ｓ１２６，Ｓ１２９〜Ｓ１３１の処理と同様である。以下、第２の実施の形態と異なるステップＳ３０３，Ｓ３０７の処理について説明する。

［ステップＳ３０３］スケジューラ１４０ａは、実行可能となった管理対象のタスクのタスク管理構造体における「IsScheduleable」の追加フラグを参照する。
［ステップＳ３０４］スケジューラ１４０ａは、管理対象のタスクを実行待ちキューに移動してよいか否かを判断する。例えばスケジューラ１４０は、管理対象のタスクの「IsScheduleable」の値が「true」であれば、実行待ちキューに移動してよいと判断する。またスケシューら１４０ａは、管理対象のタスクの「IsScheduleable」の値が「false」であれば、実行待ちキューに移動できないと判断する。実行待ちキューに移動してよい場合、処理がステップＳ３０５に進められる。また実行待ちキューに移動できない場合、処理がステップＳ３０１に進められる。

［ステップＳ３０７］ディスパッチャ１５０ａは、スケジューラ１４０ａから取得した管理対象のタスクのタスク管理構造体における「IsScheduleable」の追加フラグを参照する。

［ステップＳ３０８］ディスパッチャ１５０ａは、管理対象のタスクに、ディスパッチをしてよいタスクか否かを判断する。例えばディスパッチャ１５０ａは、管理対象のタスクの「IsScheduleable」の値が「true」であれば、ディスパッチしてよいと判断する。またスケシューら１４０ａは、管理対象のタスクの「IsScheduleable」の値が「false」であれば、ディスパッチできないと判断する。ディスパッチしてよい場合、処理がステップＳ３０９に進められる。またディスパッチできない場合、処理がステップＳ３１１に進められる。

このようにして、タスク管理構造体に設定した追加フラグにより、タスクのスイッチの要否を判断することができる。タスク管理構造体は、タスクの管理上スケジューラ１４０ａやディスパッチャ１５０ａで受け渡されている。そのためタスク管理構造体内の追加フラグでタスクスイッチの可否判断を可能とすることで、タスクスイッチの可否判断の処理を効率的に行うことができる。例えば図９に示した制御対象アプリケーション記憶部１４３を用いた場合、タスクスイッチの可否判断のためには、制御対象アプリケーション記憶部１４３の内容と、判断対象のタスクを用いて実行するアプリケーションの名称との照合が必要となる。一方、判断対象のタスクのタスク構造体内に、タスクスイッチの可否を示すフラグが設定されていれば、そのフラグを参照するだけで、タスクスイッチの可否を判断できる。その結果、タスクスイッチの可否判断の処理効率が向上する。タスクスイッチは、マルチタスクのＯＳにおいて頻繁に行われる処理である。そのため、タスクスイッチの処理の効率化により、携帯情報端末のシステム全体として、大幅な処理効率の向上が期待できる。

〔第５の実施の形態〕
次に第５の実施の形態について説明する。第５の実施の形態は、実行中の業務アプリケーションに対して脅威となるリソースアクセスを行う他のアプリケーションであっても、予め指定したアプリケーションは実行できるようにしたものである。以下、第４の実施の形態における第２の実施の形態との相違点を中心に説明する。

図２２は、第５の実施の形態の制御対象テーブルの一例を示す図である。第５の実施の形態では、制御対象テーブル１６１ａが拡張され、実行可能アプリの欄が追加されている。実行可能アプリの欄には、制御対象アプリケーションとして抽出されたとしても、実行を許容するアプリケーションの名称が設定される。実行可能アプリの欄に設定されたアプリケーションを実行するためのタスクは、タスクスイッチの抑制対象から除外される。

以下、図５に示した第２の実施の形態の要素を用いて、制御対象アクセス記憶部１６０に図２２に示すような制御対象テーブル１６１ａを格納した場合の、タスク管理処理について説明する。

図２３は、第５の実施の形態のリソースアクセステーブルの一例を示す図である。第５の実施の形態では、業務アプリケーションとして、「アプリＡ」と「アプリＢ」があり、業務以外のアプリケーションとして、「アプリＸ」、「アプリＹ」、「アプリＺ」がある。アプリケーション「アプリＡ」は、メモリカードへのアクセス命令を含む。アプリケーション「アプリＢ」は、カメラとメモリカードへのアクセス命令を含む。アプリケーション「アプリＸ」は、ネットワークとメモリカードへのアクセス命令を含む。アプリケーション「アプリＹ」は、カメラへのアクセス命令を含む。アプリケーション「アプリＺ」は、メモリカードとカメラへのアクセス命令を含む。

図２２に示すように、業務アプリケーションである「アプリＡ」については、メモリカード、ネットワーク、ＳＭＳへのリソースアクセスが脅威となる。また業務アプリケーションである「アプリＢ」については、メモリカード、ネットワーク、ＳＭＳ、カメラへのリソースアクセスが脅威となる。

ここで「アプリＺ」は十分に安全が確認されており、「アプリＺ」がカメラへアクセスしても、「アプリＢ」の脅威とはなりえないものとする。この場合、ユーザによって、図２２に示すように、業務アプリケーション「アプリＢ」に対応する実行可能アプリの欄に、「アプリＺ」が設定される。

アプリケーション「アプリＢ」が起動されると、「アプリＢ」は業務アプリケーションであるため、「アプリＢ」による業務利用開始が業務利用判断部１８３からスケジューリング指示部１８４に通知される。スケジューリング指示部１８４は、制御対象アクセス抽出部１８１からは、「アプリＢ」を含む業務アプリケーションリストを取得する。またスケジューリング指示部１８４は、制御対象アクセス抽出部１８１から、制御対象リソースとして、「メモリカード、ネットワーク、ＳＭＳ、カメラ」を含む制御対象リソースリストを取得する。さらにスケジューリング指示部１８４は、制御対象アクセス抽出部１８１から、実行可能なアプリケーションの名称として「アプリＺ」を取得する。またスケジューリング指示部１８４は、制御対象アプリケーション抽出部１８２から、「アプリＡ、アプリＢ、アプリＸ、アプリＹ、アプリＺ」を含む制御対象アプリケーションリストを取得する。

スケジューリング指示部１８４は、制御対象アプリケーションリストから、業務アプリケーションリストに含まれている「アプリＢ」を除外する。さらにスケジューリング指示部１８４は、制御対象アプリケーションリストから、実行可能アプリケーションの名称「アプリＺ」も除外する。その結果、制御対象アプリケーションリストには、「アプリＡ、アプリＸ、アプリＹ」が残る。制御対象アプリケーションリストに残されたアプリケーションを実行するためのタスクは、タスクスイッチの抑止対象となり、スケジューリングから外される。このようにすると、カメラを使うアプリでも、安全が確認されていない「アプリＹ」は動作しないが、安全が確認されている「アプリＺ」は動作させることができ、利便性が向上する。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ａ 第１のプログラム
１ｂ，１ｃ 第２のプログラム
２ 記憶手段
２ａ 脅威アクセス情報
２ｂ アクセス対象資源情報
３ 判断手段
４ 制御手段
５ａ，５ｂ，５ｃ タスク
６ 実行時間割り当て手段
７ データ
Ｓ 情報処理装置

Claims (4)

1. 保護対象のデータを取り扱う第１のプログラムの起動から終了までの間に資源アクセスが行われたとすると、前記データの保護に対する脅威となる資源アクセスを示す脅威アクセス情報と、第２のプログラムの実行によりアクセスする可能性のある資源を示すアクセス対象資源情報とを参照し、前記第２のプログラムの実行により、前記データの保護に対する脅威となる資源アクセスが行われる可能性があるか否かを判断する判断手段と、
   前記データの保護に対する脅威となる資源アクセスが行われる可能性がある場合、前記第１のプログラムを実行するための第１のタスクへのプロセッサの実行時間の割り当てを許容している間、前記第２のプログラムを実行するための第２のタスクへの前記プロセッサの実行時間の割り当てを抑止すると共に、前記第１のプログラムの実行が中断した場合、前記データを、前記第２のプログラムの実行によりアクセスされない記憶領域に退避し、前記第２のプログラムを実行させる制御手段と、
   を有する情報処理装置。
2. 前記制御手段は、中断していた前記第１のプログラムの実行を再開する場合、前記記憶領域に退避していた前記データを退避前の場所に復元し、前記第１のプログラムの実行を再開させる、
   請求項１記載の情報処理装置。
3. 前記第２のプログラムの実行によりアクセスされない記憶領域は、オペレーティングシステムのカーネル空間として管理されている記憶領域である、
   請求項１または２記載の情報処理装置。
4. 前記判断手段は、前記第２のプログラムが安全であることが設定された場合、前記第２のプログラムの実行により、前記データの保護に対する脅威となる資源アクセスが行われる可能性はないと判断する、
   請求項１乃至３のいずれかに記載の情報処理装置。
   

Images