JP5004779B2 - マルチウインドウ・システム、マルチウインドウ・システムのセキュリティ保護方法、及びマルチウインドウ・システムのセキュリティ保護プログラム - Google Patents

Description

この発明は、一般的には、コンピュータのセキュリティ管理に関し、より詳しくは、マルチセキュリティ・レベルに対応したコンピュータに接続された画面における出力情報を保護するためのグラフィック・インターフェースの技術に関するものである。

マルチレベルセキュリティに対応したシステムでは、セキュリティレベルの異なる主体間の情報フローを厳密に管理する必要がある。一般に、マルチレベルセキュリティシステムでは、プロセスにラベル付けを行ない、ラベルに基づいて、ファイルやデバイスに対するアクセス制御を行なう。軍事などの一部の分野では、マルチレベルセキュリティに対応した専用のオペレーティング・システム（ＯＳ）が用いられているが、近年は、Ｗｉｎｄｏｗｓ（Ｒ）などの一般商用ＯＳにおいて、強制アクセス制御機構を後から付加することで、簡易的なマルチレベルセキュリティを実現する手法も存在する。

クライアント端末として利用されることの多いＷｉｎｄｏｗｓ（Ｒ）などの一般商用ＯＳでは、マルチウィンドウ・システムによるＧＵＩが提供されており、これによれば、ユーザーはウィンドウを切り替えながら、複数のタスクを同時に処理できる。しかし、このようなマルチタスクのウィンドウシステムに、マルチレベルセキュリティの概念を持ち込むと、ユーザビリティの観点から問題が生じる。具体的には、同一デスクトップ画面上でセキュリティレベルの異なる複数の作業を同時に行なう場合、現在どのレベルの作業を行なっており、何が許可されて、何が禁止されているか、ユーザーには直感的にわかりにくい。

例えば、印刷やコピーが禁止されている機密文書と、制限のない通常の文書を同時に編集しているとき、ウィンドウを切り替えても画面の見た目がほぼ同じため、操作が許可されているのか、禁止されているのか、実際に実行するまでユーザーは判断できない。そのため、誤って禁止された操作をしてしまい、意図せずに警告が管理者に通知されるなど、不都合が生じる。

そこで、セキュリティレベルごとにデスクトップ画面を隔離することで、どのレベルで作業しているのか直感的にわかるようにしたＧＵＩが提供されている。例えば、仮想化技術を用いてデスクトップ画面をセキュリティレベルごとに隔離する方法がある。これによれば、個別にポリシーを割り当てた専用の仮想環境でプログラムを動かすため、自分がどのレベルで作業しており、何が禁止されているのか、ユーザーは直感的に理解できる。ただし、仮想環境間で自由にデータをやり取りできないため、本来許可されても問題のないコピー＆ペーストやドラッグ＆ドロップなどの便利な操作も過度に制限され、利便性が大きく犠牲になる。また、レベルごとに準備する仮想環境のセットアップやソフトウェアライセンスなどのコストも無視できない。

異なるセキュリティレベルのプログラムを同一デスクトップ内で動かす方法として、下記非特許文献１では、専用のウィンドウマネージャの管理下で、複数のウィンドウシステムを透過的に合成表示する手法が示されている。ウィンドウマネージャが、画像の合成出力と、入力デバイスイベントの振り分けを担い、ウィンドウシステム間での情報流通を遮断する。一つのデスクトップ画面内で複数のセキュリティレベルの作業を同時に実現できるが、異なるレベル間の情報流通は一律に遮断されるため、仮想化技術を用いた方法と同様、過度の制限を受け、操作性が低下する。

また、Trusted Solaris(商標）など、一部のセキュアＯＳでは、セキュリティラベルをサポートするウィンドウシステムが提供されているが、ウィンドウ・プロパティ情報へのアクセス制御やクリップボード操作の可否を制御するのみであり、ＧＵＩの表示状態を制御するわけではなく、直感的なわかりやすさが実現されているわけではない。

特開平５−５３７４８号公報は、マルチウィンドウ管理に関するもので、個々のウィンドウに対して別個に入出力を禁止することで、個々のウィンドウに対して機密保護を可能とするマルチウィンドウ管理装置を開示する。これにおいては、ウィンドウ入出力制御部が、機密保護属性テーブル部の機密保護属性を参照することでウィンドウ別に入出力を管理して機密保護を行う。

特開平６−１４９５２５号公報は、ロックを必要とする画像の特定領域に重ね合わせるようにロック用ウインドウ１２を表示する技術を開示する。この場合、ロック用ウインドウ以外の領域にカーソルを移動させて所定の入出力処理を行うと、その画像の加工や命令の入出力が可能となる。しかしながら、ロック用ウインドウ上にカーソルを重ねて操作しても、その操作命令はロック用ウインドウの下にある画像についての処理とは見なされず、その特定領域に限ってデータ入出力処理が禁止される。

特開平７−２８１８６０号公報は、グラフィカル・ユーザ・インタフェースのコントロールにアクセス・セキュリティを提供するための技術に関し、グラフィカル・ユーザ・インタフェースのウィンドウ内の個別のコントロールにセキュリティを提供する方法およびシステムを提供することを開示する。この技術によれば、コントロールを有するウィンドウの作成またはオープン時に、コントロール情報を隠して見えなくする覆い隠し領域が定義される。その後、許可パスワードを入力することでアクセス権を獲得することができる。

特開平１１−１９５０３３号公報は、二次元画像情報の提示装置において、各レイヤーごとにセキュリティーを確保し、複数ファイル間でのレイヤーを一元的に取り扱うようにすることを開示する。

特開２０００−１８１５９７号公報は、コンピュータ・システムのグラフィック・ユーザ・インタフェース（ＧＵＩ）内の制御を保護する方法及び装置に関し、これによれば、ＧＵＩが、ユーザ入力に応答して、１つ以上の制御領域を表示する。すると、制御は、保護状態をユーザに伝える透過のオーバレイにより、入力から保護される。許可されたユーザはポインティング・デバイスにより、制御に近接するグリップ面を活動化し、次に該デバイスを移動して、ボタンまたはコマンド行入力のフィールドなどに相当する下側の制御を露出し、カバーを除去し得る。こうして、制御領域との不注意な対話が回避される。

特開２００７−６５８４６号公報は、本出願人と同一の出願人に係る発明であり、オペレーティングシステム上で第１および第２アプリケーションプログラムを含む複数のアプリケーションプログラムを並行に動作させる情報処理装置であって、第１アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、または、第１アプリケーションプログラムおよびオペレーティングシステム間で送受信されるメッセージを監視する監視部と、監視部による監視結果に基づいて、第２アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、若しくは、第２アプリケーションプログラムおよびオペレーティングシステム間のメッセージ送受信の処理を変更または禁止する制御部とを備える情報処理装置を開示する。本願発明の１つの背景技術として参考までに示す。

上記のような従来技術では、セキュリティ保護という目的は達成されるが、依然として、ＧＵＩのわかりやすさと、情報フロー制御の柔軟性を両立することが難しい。また、上記のような従来技術では、どのウインドウが高いセキュリティ・レベルにあり、どのウインドウが低いセキュリティ・レベルにあるか、ということが明確でない。
特開平５−５３７４８号公報 特開平６−１４９５２５号公報 特開平７−２８１８６０号公報 特開平１１−１９５０３３号公報 特開２０００−１８１５９７公報 特開２００７−６５８４６号公報 Norman Feske and Christian Helmuth. Overlay Window Management: User interaction with multiple security domains. Technical Report TUD-FI04-02-Marz 2004, TU Dresden, 2004

この発明の目的は、マルチセキュリティレベルのシステムにおいて、ユーザのＧＵＩの操作性を改善することにある。

この発明の他の目的は、マルチセキュリティレベルのシステムにおいて、ウインドウのセキュリティ・レベルの分かりやすさを改善するマルチウインドウ・システムを提供することにある。

本発明の一側面では、セキュリティレベルと、画面上のＺ軸方向の位置情報（Ｚオーダー）を対応づけし、低セキュリティレベルのプログラムが、高セキュリティレベルのプログラムよりＺ軸方向で高くならないように制限を課す。同時に、クリップボードやウィンドウメッセージによる情報フローに関して、Ｚ軸方向の高いプログラムから低いプログラムへの流れを制限する。アクセスするファイルや表示する文書の属性などに応じて、ウィンドウ単位でセキュリティレベルを細粒度に管理し、ユーザーが実際に作業しているウィンドウのセキュリティレベルに応じて、デスクトップ内の各ウィンドウの表示状態を動的に制御する。また、セキュリティレベルに応じて、プリンタやドライブなどのシステムリソースの可視状態も制御する。

本発明においては、各プロセス内には、ウィンドウのアクティブ状態やＺ軸方向の位置などを監視する状態監視部、状態変化に応じてセキュリティレベルを再評価するセキュリティレベル判定部、ウィンドウの可視状態を制御する状態制御部、クリップボードやウィンドウメッセージなどのリソースアクセスを制御するアクセス制御部が常駐する。状態監視部は、ウィンドウのＺ軸方向の位置変更イベントを監視し、自分よりセキュリティレベルの高いウィンドウの上位に移動しようとしていることを検出すると、システムは、各ウィンドウを所有するプロセス内の状態制御部に状態変更要求を通知する。通知を受けた上位セキュリティレベルの各プロセス内の状態制御部は、ウィンドウを不可視状態に変更し、画面上から消去する。また、アクセス制御部は、状態変更時にクリップボード内に残されたデータを消去すると同時に、上位プログラムからクリップボードへのデータ出力や、上位プログラムから下位プログラムへのメッセージ送信を制限する。なお、クリップボード内のデータの所有者を判定するために、アクセス制御部は、プログラムがクリップボードにデータを出力する時は常に、書き込み元プログラムのセキュリティレベルを付加情報としてユーザー定義領域に書き込む。また、状態監視部とセキュリティレベル判定部が連携し、ＧＵＩの状態変化に応じてセキュリティレベルの再評価を行なう。

一方、セキュリティレベル復元ＧＵＩ表示部がシステムに常駐し、高レベル・プログラムへの復帰を要求するためのＧＵＩをユーザーに提供する。ＧＵＩは、例えばタスクバーのウィンドウアイコンをクリックする方法でもよいし、タスクトレイに常駐するレベル選択のスライドバーでもよい。また、特定のホットキー（Shiftキーなど）が長時間押されたときに、不可視上位ウィンドウを半透明表示させる方式でもよい。これらのＧＵＩを用いてユーザーが高レベルプログラムへの復帰を要求すると、高レベルプログラム内の状態制御部に状態変更要求を通知する。通知を受けた状態制御部は、不可視状態のウィンドウを元のZ軸方向の位置で可視化する。その結果、それまでフォーカスされていた低セキュリティレベルのウィンドウはフォーカスを失い、Ｚ軸方向で下位に移される。

なお、本発明の別の側面では、セキュリティ・レベルと、ウインドウのＺオーダーの関係が逆になり、高セキュリティレベルのプログラムが、低セキュリティレベルのプログラムよりＺ軸方向で高くならないように制御される。

この発明によれば、セキュリティレベルと、画面上のＺ軸方向の位置情報を対応づけし、低セキュリティレベルのプログラムのウインドウが高いＺ値をもつように操作されたことに応答して、高セキュリティレベルのプログラムのウインドウを隠すようにシステムが自動的に制御するので、ユーザが、使用するウインドウのセキュリィ・レベルでとまどうことが少なくなり、操作性が向上する。

以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。

図１を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・パス１０２には、ＣＰＵ１０４と、主記憶（ＲＡＭ）１０６と、ビデオメモリ（ＶＲＡＭ）１０８と、ハードディスク・ドライブ（ＨＤＤ）１１０と、キーボード１１２と、マウス１１４と、ディスプレイ１１６が接続されている。ＣＰＵ１０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標） ４、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１０６は、好適には、５１２ＫＢ以上の容量をもつものである。ビデオメモリ１０８は、ディスプレイ１１６に画面出力するためのイメージを保持するために使用される。

ハードディスク・ドライブ１１０には、個々に図示しないが、オペレーティング・システム及び本発明に係る処理プログラム、及びそのワードプロセッサ、表計算プログラム、プレゼンテーション作成プログラム、データベース・プログラムなどのアプリケーション・プログラムが、予め格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃ ＯＳ（商標）などの、マルチウインドウのグラフィック・ユーザー・インターフェースをサポートし、ＣＰＵ１０４に適合する任意のものでよい。なお、以下の説明では、便宜上、オペレーティング・システムとして、Ｗｉｎｄｏｗｓ ＸＰ（商標）を使用し、ＡＰＩとしてＷｉｎ３２ ＡＰＩを使用するものとして説明する。しかし、この分野の当業者なら、Ｌｉｎｕｘ（商標）などの他のオペレーティング・システムでも、同等のＡＰＩを具備しており、そのような別のオペレーティング・システムでも本発明を実現できることを理解するであろう。

ディスプレイ１１６は、これには限定されないが、好適には、１０２４×７６８以上の解像度をもち、３２ビットtrue colorのＬＣＤモニタである。

キーボード１１０及びマウス１１２は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ１１６に表示されたアイコン、タスクバー、ウインドウなどのグラフィック・オブジェクトを操作するために使用される。

図２は、本発明の機能ブロック図を示す。図２において、オペレーティング・システム２０２は、ハードディスク１１０に格納されて、図１に示すコンピュータの電源投入時に、ＲＡＭ１０６にロードされて、動作する。オペレーティング・システム２０２の主要な機能として、ハードディスク１１０、キーボード１１２、マウス１１４、及びディスプレイ１１６などの周辺装置との入出力制御機能、プログラムのロード及び機能、タスクの切り替え機能などを有する。

ウインドウ・マネジャ２０４は、ディスプレイ１１６にウインドウを表示したり、ウインドウをリサイズしたり、ウインドウを隠したり、ウインドウを消滅させたり、ユーザのマウス・クリック操作に応答して、指定したウインドウを前面にもってきたり、１つのウインドウから別のウインドウに、クリップボードを介してデータをコピーしたりする操作をコントロールするなどのＧＵＩ環境を提供するシステムであり、Ｌｉｎｕｘ（商標）では、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍなどがそれに当たる。Ｗｉｎｄｏｗｓ ＸＰ（商標）においては、ウインドウ・マネジャ２０４は、オペレーティング・システム２０２の機能の一部として含まれており、具体的には、Win32k.sys、GDI32.DLLなどからなるが、これらの機能自体は周知なので、ここでは詳細な説明は省略する。

アプリケーション・プログラム２０６ａ、２０６ｂ・・・２０６ｚは、例えば、ワードプロセッサ、表計算プログラム、プレゼンテーション作成プログラムなどであり、ハードディスク・ドライブ１１０に保存されており、ユーザのマウス１１４やキーボード１１２の操作により、オペレーティング・システム２０２の機能によって、主記憶１０６にロードされ、ウインドウ・マネジャ２０４の機能により、個別のウインドウに表示されて、並列に実行される。

次に、本発明の特徴的な機能である、状態監視部２０８、セキュリティレベル判定部２１０、状態制御部２１２、アクセス制御部２１４、及びセキュリティレベル復元ＧＵＩ表示部２１６について説明する。これらの機能は、オペレーティング・システム２０２が提供するＡＰＩ関数を呼び出して、プロセスやスレッドを監視し得る機能を記述可能な、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）などの任意の適当なプログラム言語処理系で書かれて、ハードディスク・ドライブ１１０に保存されて、スタートアップ・ルーチンに組み込まれて、図１のコンピュータ・システムの電源投入時に、自動的に主記憶１０８にロードされて実行されるように、オペレーティング・システム２０２に制御される。

なお、図２には、状態監視部２０８、セキュリティレベル判定部２１０、状態制御部２１２、アクセス制御部２１４は、アプリケーション・プログラム２０６ａ、２０６ｂ・・・２０６ｚと機能的に別のものとして表示されているが、好適には、セキュリティレベル判定部２１０、状態制御部２１２、アクセス制御部２１４がアプリケーション・プログラム２０６ａ、２０６ｂ・・・２０６ｚ内部のプロセスに介在し常駐して、１つのアプリケーション・プログラムから別のアプリケーション・プログラムを、監視する機能をもつ。

状態監視部２０８は、ウィンドウマネージャ２０４が提供するメッセージフック機構を利用する。状態監視部２０８は、ウィンドウマネージャ２０４から通知されるメッセージを監視し、ウィンドウのＺオーダーの変更やアクティブ状態の変更を検出する。例えば、WM_WINDOWPOSCHANGINGメッセージを監視することで、Ｚ軸方向の位置、すなわち、ウインドウの重なりの上下、が変更されることを検出する。また、WM_ACTIVATEメッセージを監視することで、フォーカスを得るまたは失うことを検出する。ウィンドウの状態変化を検出すると、必要に応じて、各プロセス内の状態制御部に対して、ウィンドウの可視状態の変更を要求する。また、後述するセキュリティレベル判定部２１０に対して、セキュリティレベルの再評価を要請する。

セキュリティレベル判定部２１０は、状態監視部２０８から通知されるイベントに応じて、当該プロセスの所有するウィンドウのセキュリティレベルを再評価する。例えば、アプリケーションが別の文書を開いた場合などに、開いた文書の属性に応じて、ウィンドウのセキュリティレベルを再評価する。なお、Windowsの電卓のような単純なプログラムの場合、一つのプロセスに一つのセキュリティレベルを固定的に適用できるので、セキュリティレベル判定部を省略してもよい。

本発明によれば、アプリケーション・プログラム２０６ａ、２０６ｂ、・・・２０６ｚには、１〜３のようなセキュリティ・レベルが付与される。ここでは、その数字が多いほど、セキュリティ・レベルが高いとする。アプリケーション・プログラム、あるいはアプリケーション・プログラムが生成するプロセスにセキュリティ・レベルを付与する技術としては、例えば、特開２００７−６５８４６に記載されている技術がある。これにより開示される技術は、オペレーティング・システム２０２上で、アプリケーション・プログラム間で送受信されるメッセージを監視し、別途記述されているポリシーに基づき、処理の変更、禁止などを行う。

下記は、ファイル毎にセキュリティ・ラベルを設定するポリシーの例であり、<Rule RuleId="urn:rule1">が、設定されるセキュリティ・レベルを記述する。すなわち、urn:rule1以外に、"urn:rule0, "urn:rule2など複数用意しておく。また、<AttributeValue DataType="file:path"> 〜 </AttributeValue>のところで、そのセキュリティ・ラベルが適用されるアプリケーション・プログラムを記述する。
<!-- Group 1 -->
<Rule RuleId="urn:rule1">
<Description>Deny clipboad copy and print by notepad and calc</Description>
<Subjects>
<Subject>
<AttributeValue DataType="file:path">calc.exe</AttributeValue>
</Subject>
<Subject>
<AttributeValue DataType="file:path">notepad.exe</AttributeValue>
</Subject>
</Subjects>
<Resources>
<Resource DataType="clipboard" Lib="SBLCLIP">
<!-- クリップボードへのコピー禁止 -->
<AttributeValue DataType="clipboard:type">
<AnyClipboardDataType/>
</AttributeValue>
<Actions>
<Action Effect="Deny">write</Action>
</Actions>
</Resource>
...........
...........
</Rule>

同様に、アプリケーション・プログラムによって生成されるプロセス毎に、セキュリティ・レベルを設定することが可能であり、例えば、あるウインドウが生成する子ウインドウに別のセキュリティ・レベルを設定することも可能である。しかし、このようなセキュリティ・レベル設定機能自体は、本発明の要旨ではないので、これ以上の詳しい説明は省略する。必要に応じて、特開２００７−６５８４６その他の従来技術を参照されたい。セキュリティレベル判定部２１０は、状態監視部２０８からの要求に応じて、このような機能を利用して、アプリケーション・プログラムのセキュリティ・レベルを検出し、状態監視部２０８にその検出結果を返す。

状態制御部２１２は、常駐先プロセス内でウィンドウ可視状態変更ＡＰＩを呼び出すことで、ウィンドウの可視状態を制御する。例えば、SetWindowPlacement、SetWindowPos、SetLayeredWindowAttributesなどのＡＰＩを呼び出して、ウィンドウの可視状態やＺオーダーを変更したり、半透明表示に変更したりする。この際、基本的には、個々のウィンドウを個別に制御するのではなく、ウィンドウ間の親子関係や被所有関係に基づいて、グループ単位で制御する。例えば、アプリケーションがモーダルダイアログを表示している場合でも、モーダルダイアログ・ウィンドウと、その所有者ウィンドウであるアプリケーションの主ウィンドウとを、一体として扱う。また、必要に応じて、状態制御部２１２は、その他のウィンドウ属性を変更する。例えば、低セキュリティレベルのウィンドウが、最上位属性（WS_EX_TOPMOST）ウィンドウを表示している場合、それより高いセキュリティレベルのウィンドウを表示するために、一時的に最上位属性を取り除き、高セキュリティレベルのウィンドウより下位に表示されるように、Ｚオーダーを調整する。

セキュリティレベル復元ＧＵＩ表示部２１６は、高レベルプログラムのウインドウが非表示の時、高レベルプログラムのウインドウの復帰を要求するためのＧＵＩをユーザに提供する。このＧＵＩは、ユーザの指示に応じて、各プロセス内の状態制御部に対して状態変更要求を通知し、通知を受けた状態制御部は、不可視状態のウィンドウを元のＺ軸方向の位置で、復元し可視化する。そのＧＵＩとしては、さまざまな形態を実現することができる。例えば、タスクバーやタスクトレイ常駐アイコンのような専用の単体プログラムとして実装してもよいし、状態監視部２０８・状態制御部２１２と連携して、ウィンドウマネージャ２０４内でシームレスなＧＵＩを実現してもよい。後者のシームレスなＧＵＩの具体的な方法は、特定のホットキー（Shiftキーなど）が長時間押されること、あるいは特定のキーの押し下げの組み合わせ（例えば、「前面」キー＋上カーソル・キー）を状態監視部２１２が検出すると、不可視状態の上位レベルプロセスの状態制御部に要求して、ウィンドウを一斉に復元表示させる。

また、セキュリティレベル復元ＧＵＩ表示部２１６によるセキュリティレベルの復元要求以外に、新規に高いレベルのプログラムを起動することでＧＵＩ状態を復元させようにしてもよい。この場合、ＧＵＩやそれに類する操作の結果、それまでフォーカスされていた低レベルウィンドウはフォーカスを失い、Z軸方向で下位に移される。

オペレーティング・システム２０２はさらに、ウインドウ・マネジャ２０４からの描画命令に基づき、ＶＲＡＭ１０８にビットマップの値を書き込み、あるいはコピーや移動させて、実際にディスプレイ１１６に、ウインドウその他のグラフィックスを描画する。具体的には、ＶＲＡＭ１０８には、画面表示領域１０８ａと、複数のオフスクリーン・バッファ領域１０８ａ、１０８ｂ・・・１０８ｚがある。オフスクリーン・バッファ領域１０８ａ、１０８ｂ・・・１０８ｚは、アプリケーション・プログラム２０６ａ、２０６ｂ・・・２０６ｚの、子ウインドウも含む個々のウインドウに対応し、アプリケーション・プログラムが生成されて、そのウインドウが存在するようになったときに、そのオフスクリーン・バッファ領域が、CreateBitmapなどのＡＰＩ関数により、ＶＲＡＭ１０８中にアロケートされる。そうして、実際のディスプレイ１１６への表示は、オフスクリーン・バッファ領域のビットマップ値を、BitBltなどのＡＰＩ関数により、画面表示領域１０８ａにビットブロック転送することによって、達成される。ウインドウの画面からの消去は、画面表示領域１０８ａから、対応するオフスクリーン・バッファ領域に、表示内容を退避させることによって、達成される。

図３は、本発明に係る処理のフローチャートの図である。図３において、ステップ３０２では、状態監視部２０８が、イベント発生を待機する。ここでいうイベントとは、ウインドウのＺオーダーの変更、ウインドウの消去、消去されたウインドウの再表示、ウインドウの破棄、などの処理のことである。

そのようなイベントが、状態監視部２０８により検出されると、ステップ３０４では、ウインドウがＺオーダー上位に移動したかどうかが、判断される。ウインドウがＺオーダー上位に移動した、ということは、例えば下位Ｚオーダーにあるウインドウをマウスでクリックして、最上位のＺオーダーにする、ということである。ウインドウがＺオーダー上位に移動したことが検出されると、ステップ３０６では、より高いＺオーダーにあり、且つ、その上位に移動したウインドウよりも高いセキュリティ・レベルのウインドウが消去される。これを行うためには、各ウインドウのセキュリティ・レベルが必要であるが、それは、状態監視部２０８が、セキュリティ・レベル判定部２１０に問い合わせすることによって知ることができる。

ウインドウがＺオーダー上位に移動したのでないなら、ステップ３０８で、イベントが、他ウインドウからの消去要求かどうかが判断される。他ウインドウからの消去要求とは例えば、当該ウィンドウより低いセキュリティレベルの他のウィンドウが，Ｚ軸上で当該ウィンドウより上位に移動するために，画面から消えるように要求することであったり、親ウィンドウが消去されるとき、その子ウィンドウに対しても消去が指示されるような場合のことである。そのような場合、ステップ３１０で、その消去されるウインドウのＺオーダーを記憶して、ウインドウが消される。この場合、消すとは、単にウインドウを最小化してもよく、セキュリティ・レベル復元ＧＵＩ表示部２１６によって表示される、適当な専用のＧＵＩで表示されたタスクトレイに入れてもよく、あるいは、半透明化してもよい。なお、記憶されるＺオーダーの値は、例えば、状態監視部２０８が保持する主記憶１０６上の所定の領域に、後で読み出し可能に保存される。

他ウインドウからの消去要求でないなら、ステップ３１２では、セキュリティ・レベル復元ＧＵＩ表示部２１６からの再表示要求かどうかが判断され、もし再表示要求であるなら、ステップ３１４で、その再表示要求されたウインドウに関連して記憶されていたＺオーダー位置に、そのウインドウが表示される。例えば、セキュリティ・レベル復元ＧＵＩ表示部２１６によって表示された、図５に示すようなＧＵＩのタスクトレイ領域５０４から、指定された操作により復元されることができる。あるいは、タスクトレイ中の所望のウインドウ・アイコンにマウス・カーソルを合わせて、例えば、Ctrl + Rのキーが押されたことをトリガするようにしてもよい。

なお、ステップ３１２での「復元ＧＵＩ表示部からの再表示要求」という記述は例示的な記述であって、ウインドウが最小化されたのであれば、それを元に戻す表示であり、ウインドウが半透明化されたのであれば、それをもとの非透明表示に戻すことを意味する。

もし再表示要求でないなら、ステップ３１６で、ウインドウ破棄かどうかが判断される。ここでウインドウ破棄とは、例えば、ウインドウ右上のＸをクリックするなどによって、監視中のウインドウを破棄することを意味する。すなわち、もし、監視中のウインドウを破棄するなら、最早イベントを監視する必要はなくなるので、この処理を完了する。

監視中のウインドウを破棄するのでないなら、処理は、ステップ３０２に戻って、次のイベントの発生を待機することになる。また、図３には示さないが、セキュリティ管理の目的で、高いセキュリティ・レベルのウインドウから低いセキュリティ・レベルのウインドウへの、クリップ・ボード等を介しての文書やデータ、グラフィック・データ、ビットマップなどのコピーは禁止される。このような禁止の仕組みは、例えば、特開２００７−６５８４６によって提供される。このとき、図３のフローチャートに示す処理は、ウィンドウの数だけ、マルチタスクで並行動作される、と理解されたい。

また、図３には示していないが、この実施例の処理によると、新規に起動されたアプリケーションのウインドウのＺオーダーは、そのアプリケーションよりも低いセキュリティ・レベルのウインドウよりは高く、そのアプリケーションよりも高いセキュリティ・レベルのウインドウよりは低くなるように選ばれる。

図４は、セキュリティ・レベル復元ＧＵＩ表示操作の処理のフローチャートである。ステップ４０２では、セキュリティ・レベル復元ＧＵＩが表示される。これは、例えば、「前面」キー＋上向きカーソルの組み合わせの押し下げなでに応答して表示される。

図５に、セキュリティ・レベル復元ＧＵＩ５００の一例を示す。図５において、コンボボックス５０２は、復元すべきウインドウのセキュリティ・レベルを設定するためのもので、コンボボックス５０２によるレベルの切り替えに応答して、その指定したセキュリティ・レベルにあり且つ非表示状態にあるウインドウのアイコン５０４ａ、５０４ｂ・・・が、領域５０４に表示される。

図５に示すＧＵＩはさらに、「すべて復元」というボタン５０６と、「選択復元」というボタン５０８をもつ。図４のステップ４０４は、コンボボックス５０２によって指定したセキュリティ・レベルにあるウインドウの復元要求かどうか、すなわち、ユーザが、「すべて復元」のボタン５０６をクリックしたかどうかの判断である。

そこで、ユーザが、「すべて復元」のボタン５０６をクリックすると、処理はステップ４０６に移行し、そこで、消去状態にあり、要求されたレベルの全ウインドウ（図５では、領域５０４にあるアイコン化されたウインドウすべて）の復元が要求される。ここでいう復元とは、図３のステップ３１０に関連して説明したように、もともと記憶されていたＺオーダーでウインドウを表示させることである。

図４のフローチャートには明示しないが、図５のＧＵＩにおいて、領域５０４に表示されているウインドウのアイコン５０４ａ、５０４ｂ・・・を、Ctrlキーを押しながらマウス・カーソルでクリックするなどのインターフェースにより１つまたは複数の非表示ウインドウのアイコンを選択し、「選択復元」のボタン５０８をクリックすることにより、選択されたウインドウのみ復元する、という操作も可能である。

図４に戻って、こうしてステップ４０８で、すべてのセキュリティ・レベルのウインドウの復元表示が完了したと判断されたなら、復元処理は完了である。復元表示するウインドウがなくなったことに応答して、システムは、図５のＧＵＩを自動的に終了してもよいし、ユーザが手動で図５のＧＵＩを終了してもよい。

まだ復元表示すべきウインドウが残っていて、ユーザが処理を続けたいなら、図４の処理は、ステップ４０２に戻る。

次に図６以下を参照して、本発明によるウインドウの非表示・復元処理について、具体的に説明する。図６の（ａ）は、ディスプレイ１１６に複数のウインドウ６０２、６０４、６０６、６０８、６１０、６１２が表示されている状態を示す。図６の（ｂ）には、図６の（ａ）に示したウインドウ６０２、６０４、６０６、６０８、６１０、６１２のＺオーダー（Ｚ座標）と、そのセキュリティ・レベルが示されている。このとき、図６の（ａ）のウインドウの参照番号と、図６の（ｂ）の参照番号とは対応していることに留意されたい。このことは、図７乃至図９でも同様である。

図６の（ｂ）に示すように、ウインドウ６０２、６０４はセキュリティ・レベル３にあり、ウインドウ６０６、６０８はセキュリティ・レベル２にあり、ウインドウ６１０、６１２はセキュリティ・レベル１にあるとする。

そこで、ユーザが、マウスカーソル６２０で、ウインドウ６０６をクリックするとする。この操作は、ウインドウ６０６のＺオーダーを最上位にもってくることを意味する。しかし、本発明のこの実施例によれば、状態監視部２０８がこの状態変化を検出し、ウインドウ６０６において、図３のステップ３０４での肯定的な判断をもたらす。これにより、ウインドウ６０６のステップ３０６において、ウインドウ６０６よりも高いＺオーダーをもち、且つ高いセキュリティ・レベルのウインドウ、すなわち、ウインドウ６０２、６０４に、消去が要求される。その要求が、ウインドウ６０２とウインドウ６０４におけるステップ３０８のＹｅｓ及び、それによるステップ３１０の実行へと伝播し、結果的に、ウインドウ６０２、６０４が消去されることになる。この処理は、状態制御部２１２が、ウインドウマネジャ２０４にリクエストを出すことによってなされる。

この結果、図７（ａ）に示すように、ウインドウ６０２、６０４が消去され、ウインドウ６０６が最上位ウインドウとなる。図７（ｂ）では、このように消去状態にあるウインドウ６０２、６０４は、破線で表示している。

さらに図７（ａ）で、ユーザが、マウスカーソル６２０で、ウインドウ６１０をクリックするとする。この操作は、ウインドウ６１０のＺオーダーを最上位にもってくることを意味する。こうして、図６に説明したのと同様の処理で、ウインドウ６０６、６０８に、消去が要求される。その状態を、図８に示す。

この状態で、「前面」キー＋上向きカーソル・キーを押し下げると、このキー入力が、状態監視部２０８によって検出されて、図５に示すＧＵＩ５００が、画面１１６に現れる。そこで、コンボボックス５０２で、レベル２を選ぶと、領域５０４には、レベル２で且つ現在非表示状態にあるウインドウ６０６、６０８の最小化アイコンが表示される。そこで、「すべて復元」のボタン５０６をクリックすると、図４のステップ４０６に従い、より具体的には図３のステップ３１４により、ウインドウ６０６、６０８が元のＺオーダーで、復元される。その状態は、図７に示すとおりである。

さらに、コンボボックス５０２で、レベル３を選ぶと、領域５０４には、レベル３で且つ現在非表示状態にあるウインドウ６０２、６０４の最小化アイコンが表示される。そこで、「すべて復元」のボタン５０６をクリックすると、図４のステップ４０６に従い、より具体的には図３のステップ３１４により、ウインドウ６０２、６０４が元のＺオーダーで、復元される。その状態は、図６に示すとおりである。

なお、上記の復元操作では、レベル２→レベル３、とウインドウを復元したが、この復元順序は任意であって、レベル３→レベル２の順であっても、問題はない。その場合は、ウインドウ６１０の上に、レベル３のウインドウ６０２、６０４がまず復元され、次に、ウインドウ６１０の上に、レベル２のウインドウ６０６、６０８が復元されることになるが、図３のステップ３１０で、ウインドウのＺオーダーを記憶してウインドウが消去されているので、復元時に、記憶されているＺオーダーが使用され、以って正しいＺ位置にウインドウが復元されることになる。

図９は、本発明の別の実施例を示す図である。すなわち、図７では、セキュリティ・レベル２のウインドウ６０６を選ぶと、その上にあった高いセキュリティ・レベルのウインドウ６０２、６０４は、ディスプレイ画面から完全に消去されたが、図９では、消去する代わりに単に、ウインドウ６０２、６０４の属性を変更して、点線で示すように、消去する代わりに、単に半透明化する。こうして、ウインドウ６０２、６０４は、仮に表示されているが、アクティブではなく、下位のウインドウ６０６などに対して、半透明化されたウインドウ６０２、６０４に関係なく、操作を行うことができる。この場合、図５のようなＧＵＩで復元させてもよいし、Ctrl+Ｒのような特定のホットキーの組み合わせを押しながら、半透明化されたウインドウをマウスボタンでクリックすることによって、半透明化されたウインドウをもとのアクティブな機能に復元させてもよい。

ところで、今まで説明してきた実施例では、個々のウインドウが、異なるアプリケーションによって管理される場合であったが、単一プロセス内で複数の文書を異なるウインドウで開くことができる、いわゆるＭＤＩ（multiple document interface)にも、本発明を適用することができる。この場合、例えば、２００７年５月３１日に出願の、本出願人に係る米国特許出願第１１／７５５７６９号に記載されている技術によって、各文書のウインドウに異なるセキュリティ・レベルを付与することができる。この場合は、ＭＤＩアプリケーションの内部の子ウィンドウ同士の位置関係を制御することで、同様の効果を実現できる。例えば、状態監視部は、親ウィンドウの位置関係に関するWM_ACTIVATE、WM_WINDOWPOSCHANGINGなどのメッセージに加えて、子ウィンドウの位置関係に関するWM_MDIACTIVATE、WM_MDIMAXIMIZEなどのMDI専用メッセージを監視することにより、子ウィンドウの位置関係を監視することができる。同様に、状態制御部は、ＭＤＩ制御メッセージを送信することにより、子ウィンドウ間の位置関係を制御できる。

また、上記実施例では、高いセキュリティ・レベルのウインドウを、相対的に上のＺオーダーに配置するようにしたが、目的に応じて、全く逆に、低いセキュリティ・レベルのウインドウを、相対的に上のＺオーダーに配置するようにしてもよい。この場合は、高いセキュリティ・レベルのウインドウのＺオーダーが、低いセキュリティ・レベルのウインドウのＺオーダーより高くなったとき、低いセキュリティ・レベルのウインドウを消去または、半透明化する。それ以外の処理は、復元表示を含めて、上記実施例の場合と基本的に同じである。

さらに、上記実施例では、オペレーティング・システム上で走る監視プログラムより描画命令を監視することによって、ラベルマップを操作し、以って所望の画面のセキュリティ管理機能を達成しているが、オペレーティング・システムのソースコードを作成・編集できる権限を有し、またはその立場にある場合は、本発明の機能を、オペレーティング・システムのネイティブな機能として、実装するようにしてもよい。

本発明を実施するためのコンピュータのハードウェアのブロック図である。 本発明の実施例に係るウインドウ監視の仕組みの機能ブロック図である。 本発明の実施例に係るウインドウ監視処理のフローチャートである。 本発明の実施例に係るウインドウ復元表示処理のフローチャートである。 セキュリティ・レベル復元ＧＵＩ表示のウインドウを示す図である。 ウインドウの表示状態と、セキュリティ・レベルの対応を示す図である。 ウインドウの表示状態と、セキュリティ・レベルの対応を示す図である。 ウインドウの表示状態と、セキュリティ・レベルの対応を示す図である。 ウインドウの表示状態と、セキュリティ・レベルの対応を示す図である。

Claims (15)

1. コンピュータによって、各々にセキュリティ・レベルを関連付けられた複数のウインドウを重ねて表示するマルチウインドウ・システムであって、
   前記表示されるウインドウのＺオーダーの変化を監視し、相対的に低いセキュリティ・レベルのウインドウが、相対的に高いセキュリティ・レベルのウインドウよりも高いＺオーダーをもつようになったことに応答して、該相対的に高いセキュリティ・レベルのウインドウを消去または半透明化する手段を有する、
   マルチウインドウ・システム。
2. ユーザー操作に応答して、前記消去または半透明化されたウインドウを復元する手段を更に有する、請求項１のマルチウインドウ・システム。
3. 前記ウインドウを復元する手段は、消去または半透明化状態にある複数の同一レベルにあるウインドウを、一度に復元させる、請求項２のマルチウインドウ・システム。
4. コンピュータによって、各々にセキュリティ・レベルを関連付けられた複数のウインドウを重ねて表示するマルチウインドウ・システムの制御方法であって、
   前記表示されるウインドウのＺオーダーの変化を監視し、相対的に低いセキュリティ・レベルのウインドウが、相対的に高いセキュリティ・レベルのウインドウよりも高いＺオーダーをもつようになったことに応答して、該相対的に高いセキュリティ・レベルのウインドウを消去または半透明化するステップを有する、
   マルチウインドウ・システムの制御方法。
5. ユーザー操作に応答して、前記消去または半透明化されたウインドウを復元するステップを更に有する、請求項４のマルチウインドウ・システムの制御方法。
6. 前記ウインドウを復元するステップは、消去または半透明化状態にある複数の同一レベルにあるウインドウを、一度に復元させる、請求項５のマルチウインドウ・システムの制御方法。
7. コンピュータによって、各々にセキュリティ・レベルを関連付けられた複数のウインドウを重ねて表示するマルチウインドウ・システムの制御プログラムであって、
   前記コンピュータに、
   前記表示されるウインドウのＺオーダーの変化を監視し、相対的に低いセキュリティ・レベルのウインドウが、相対的に高いセキュリティ・レベルのウインドウよりも高いＺオーダーをもつようになったことに応答して、該相対的に高いセキュリティ・レベルのウインドウを消去または半透明化するステップを実行させる、
   マルチウインドウ・システムの制御プログラム。
8. ユーザー操作に応答して、前記消去または半透明化されたウインドウを復元するステップを更に有する、請求項７のマルチウインドウ・システムの制御プログラム。
9. 前記ウインドウを復元するステップは、消去または半透明化状態にある複数の同一レベルにあるウインドウを、一度に復元させる、請求項８のマルチウインドウ・システムの制御プログラム。
10. コンピュータによって、各々にセキュリティ・レベルを関連付けられた複数のウインドウを重ねて表示するマルチウインドウ・システムであって、
    前記表示されるウインドウのＺオーダーの変化を監視し、相対的に高いセキュリティ・レベルのウインドウが、相対的に低いセキュリティ・レベルのウインドウよりも高いＺオーダーをもつようになったことに応答して、該相対的に低いセキュリティ・レベルのウインドウを消去または半透明化する手段を有する、
    マルチウインドウ・システム。
11. ユーザー操作に応答して、前記消去されたウインドウを復元する手段を更に有する、請求項１０のマルチウインドウ・システム。
12. 前記ウインドウを復元する手段は、消去または半透明化状態にある複数の同一レベルにあるウインドウを、一度に復元させる、請求項１１のマルチウインドウ・システム。
13. コンピュータによって、各々にセキュリティ・レベルを関連付けられた複数のウインドウを重ねて表示するマルチウインドウ・システムの制御プログラムであって、
    前記コンピュータに、
    前記表示されるウインドウのＺオーダーの変化を監視し、相対的に高いセキュリティ・レベルのウインドウが、相対的に低いセキュリティ・レベルのウインドウよりも高いＺオーダーをもつようになったことに応答して、該相対的に低いセキュリティ・レベルのウインドウを消去または半透明するステップを実行させる、
    マルチウインドウ・システムの制御プログラム。
14. ユーザー操作に応答して、前記消去または半透明されたウインドウを復元するステップを更に有する、請求項１３のマルチウインドウ・システムの制御プログラム。
15. 前記ウインドウを復元するステップは、消去または半透明状態にある複数の同一レベルにあるウインドウを、一度に復元させる、請求項１４のマルチウインドウ・システムの制御プログラム。

Images