JP3954030B2

JP3954030B2 - アプリケーションを使用する際にユーザのプライバシを保護する方法とシステム

Info

Publication number: JP3954030B2
Application number: JP2003568522A
Authority: JP
Inventors: アダムズ、マイケル、チャールズ; フィリップス、ジョナサン; ワイリー、クリストファー、ジョン、マーチン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-02-15
Filing date: 2003-02-06
Publication date: 2007-08-08
Anticipated expiration: 2023-02-06
Also published as: KR20040074050A; CN100487643C; WO2003069465A3; US10216375B2; EP1483665A2; US20160077697A1; KR100602533B1; GB0203617D0; WO2003069465A2; US9223588B2; CA2475355A1; EP1483665B1; ATE340383T1; US20050091382A1; US20070266320A1; JP2005518014A; DE60308489T2; CN1633639A; AU2003244992A1; US7299474B2

Description

本発明はインターネット技術の分野とユーザが秘密情報すなわち機密情報を閲覧するのを可能にするアプリケーションを使用する際にユーザのプライバシを保護することとに関する。特に、本発明はアプリケーション・ウインドウの親ウインドウに付随するイベントに応答して当該アプリケーション・ウインドウを閉じる方法に関する。

消費者はワールト・ワイド・ウェブが提供するサービスを利用して秘密取引（たとえば個人バンキング、株式取引、オンラインでの商品購入、ポータル環境内からの他のサービスの開始など）を実行する。

ユーザは世界中に存在するサーバと通信することによりネットワークを介してこれらのサービスにアクセスし情報を取得することができる。情報はサーバに格納されており、ネットワーク・サーバのリソースから要求元のクライアント・アプリケーションへファイルすなわちデータ・パケットを送付することにより配送する。

このような取引をオンラインで行なうとき、消費者は自分たちの情報のプライバシとセキュリティについて懸念を抱く。特に、同じ場所において多数の異なるユーザが共用コンピュータを使用する場合、秘密情報が他のユーザが見うる状態で開放アプリケーション・ウインドウに表示されるから、これらの懸念が増大する。

多数のユーザが同じコンピュータを共用する場合、ユーザはログオフしない可能性がある、すなわちユーザは自分のアプリケーションを正確にシャットダウンせずに引き続くユーザが見うる状態で開放アプリケーション・ウインドウに機密情報、秘密情報、または個人情報を表示させたままにしておく可能性がある。開放アプリケーション・ウインドウに含まれる情報は別のユーザによって使用され、別人の銀行口座、株式取引口座、またはクレジット・カードの明細に不許可の状態でアクセスされる可能性がある。これは秘密情報にオンラインでアクセスするネットワーク・アプリケーションに特有の問題である。セキュリティ上の懸念はセッションを明示的に管理することにより大部分低減させることができる。

ＨＴＴＰ（Hypertext Transfer Protocol)はネットワーク・アプリケーションがネットワーク・サーバと相互作用する方法を規定するものであるが、セッションの管理を行なう。ＨＴＴＰは「要求−応答」プロトコルである。すなわち、クライアントは要求されたリソースのＵＲＬを保持しているサーバに要求メッセージを送信する。サーバはパス名をルックアップする（すなわち一覧表から探索する）。パス名が存在する場合、サーバはファイルの内容を応答に含めてクライアントに返送する。ＨＴＴＰはコンテンツ・ネゴシエーションと認証を考慮に入れている。

認証にはパスワードで保護された領域に初めてアクセスを試みる際におけるユーザによるパスワードの入力が含まれる。サーバの応答には当該リソースに適用可能なユーザ確認方法たとえばディジタル署名が含まれる。ユーザ確認方法を受信すると、クライアントはユーザに名前とパスワードをタイプ入力するように促したのち、引き続く要求に付随する資格証明を送信する。

しかしながら、上述した方法は要求−応答の交換ごとにコネクションを確立して閉じることが必要になるので、サーバを過負荷状態にする点およびネットワークを介して過度のメッセージを送信する点の双方において高くつく。そこで、クライアントとサーバとの間における一連の要求−応答交換の間開き続ける永続的コネクションが使用される。永続的コネクションは他の参加者にその旨の表示を送付することにより、クライアントまたはサーバによっていつでも閉じることができる。サーバは所定期間アイドルである場合には永続的コネクションを閉じるように構成することができる。ネットワークをまたぐアプリケーションが所定期間アイドルである場合、コネクションはタイムアウトになり、ユーザは認証の詳細をアプリケーションに再入力することが必要になる。

したがって、ユーザがログオンしうる様々な異なるアプリケーションに対してユーザが不許可状態でアクセスするのを停止させるのに、セッション管理が役に立つ可能性かある。しかし、セッション管理によってはウインドウ管理を実現することはできない。それゆえ、不許可のユーザは開放アプリケーション・ウインドウに表示される秘密情報をすべて見ることができる。

アプリケーション・ウインドウでログオフを明示的に行なわない場合、ウインドウ管理に関するユーザ・インタフェースを設計する際に考慮しうる設計上の含意には多くのものがある。それらは広義には次に示すカテゴリに分類することができる。すなわち、モーダル・ビヘイビア（モード上の振る舞い）を呈示するアプリケーション・ウインドウには所定時に単一のアプリケーション・ウインドウのみを表示し、さらなるアプリケーション・ウインドウを表示しないもの、または、アプリケーションのファイル−終了経路もしくはオペレーティング・システムに装備された機能（たとえば「Ｘ」アイコンもしくはタスク・マネージャ）を用いてアプリケーションのホーム・ページ・ウインドウを閉じるものである。

アプリケーションにおけるウインドウ管理を実現する１つの方法はイタープリタ型のクライアント側プログラミング言語を用いて必要な機能を実現することである。イタープリタ型のクライアント側プログラミング言語（たとえばＪａｖａＳｃｒｉｐｔ）を用いると、ウインドウ管理を高さ、幅、色、およびスタイルから成る特性で規定された新たなアプリケーション・ウインドウを生成することに限定することができる。クライアント側プログラミング言語（たとえばＪａｖａＳｃｒｉｐｔ）では、いわゆる「モーダル・ウインドウ」を用いて特定のオペレーションを実行するか否かに関するユーザのフィードバックを取得している。典型的なモーダル・ウインドウは「はい」、「いいえ」、「取り消し」、および「ＯＫ」のうちの少なくとも１つのボタンと、たとえば「このアプリケーションを閉じたいですか？」とユーザに促す質問とを備えている。モーダル・ウインドウはユーザが「はい」、「いいえ」、「取り消し」、または「ＯＫ」ボタンをクリックするまで消失しない。

クライアント側コードによって実現するモーダル・アプリケーション・ウインドウには、たとえばＪａｖａＳｃｒｉｐｔにおいてshowModalDialog ()関数を使用するときに制限がある。showModalDialog ()関数は所定のＵＲＬのｈｔｍｌページを表示する別のポップアップ・アプリケーション・ウインドウを生成する。このアプリケーション・ウインドウによって、ユーザは親アプリケーション・ウインドウに戻る前に当該アプリケーション・ウインドウのデータにアクセスすることが可能になる。

showModalDialog ()関数はＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ（Ｒ）ブラウザに特有のものであり、Ｎｅｔｓｃａｐｅ（Ｒ）ブラウザまたはＷ３Ｃのドキュメント・オブジェクト・モデル（ＤＯＭ）ではサポートされていない。showModalDialog ()関数は表示中のアプリケーション・ウインドウとの間に記述可能な関係を有さない完全にスタンドアロンなアプリケーション・ウインドウを生成する。Ｍａｃｉｎｔｏｓｈ（Ｒ）オペレーティング・システム・プラットフォームでは、幅、高さ、および色から成る特性を設定することができない。

親ウインドウでonFocus ()関数を実行すると、親アプリケーション・ウインドウを選択することが可能になるとともに、onFocus ()関数が生成したイベントを獲得することができる。onFocus ()関数は表示済みのアプリケーション・ウインドウが存在するか否かを判断するチェックを行なうものである。onFocus イベント・ハンドラはonFocus ()が生成したイベントの存在下でＪａｖａＳｃｒｉｐｔの特定のコードすなわち関数を実行するものである。onFocus イベントはユーザがウインドウ要素、フレーム要素、またはフォーム要素に焦点を当てると発生する。onFocus ()はＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ（Ｒ）ブラウザおよびＮｅｔｓｃａｐｅ４．ｘｘ（Ｒ）ブラウザ、Ｍａｃｉｎｔｏｓｈ（Ｒ）プラットフォームおよびＬＩＮＵＸ（Ｒ）プラットフォームで機能する。

この関数の不都合な点はＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（Ｒ）オペレーティング・システムにおいてモーダル・ウインドウを最小化することができないという点である。また、この関数はＮｅｔｓｃａｐｅ６（Ｒ）ブラウザでは致命的になる可能性がある。モーダル・アプリケーション・ウインドウが開いたまま親アプリケーション・ウインドウで閉じるボタンを選択すると、親ウインドウは閉じるがモーダル・アプリケーション・ウインドウは開いたままである。

子アプリケーション・ウインドウでself.focus () 関数を繰り返し呼び出すと、タイマはドキュメントをアプリケーション・ウインドウにロードしたときに開始することが可能になる。タイマは表示済みウインドウでself.focus () 関数を迅速に呼び出してそれを繰り返す。self.focus () 関数を実装する不都合はそれが他のすべてのアプリケーションにとってモーダル（modal)である点であり、この関数が他の表示済みアプリケーション・ウインドウにアクセスできない点である。なぜなら、アプリケーション・ウインドウとモーダル・ウインドウとの間に記述可能な関係が存在しないからである。self.focus () 関数はオペレーティング・システムの関数呼び出しによって表示済みアプリケーション・ウインドウを閉じることもできる。これにより、無効なセッションにおけるトランザクション・アプリケーションを含んでいる可能性のある表示済みウインドウを開いたままにすることができる。

親ウインドウでonFocus ()関数またはonClick ()関数を実行すると、onOpenedWindow () 関数が呼び出される。親アプリケーション・ウインドウに焦点を当てる、またはそれをクリックをすると、表示済みアプリケーション・ウインドウの存在を検査するチェックが呼び出される。チェックが真を返すと、表示済みアプリケーション・ウインドウはwindowname.focus () 関数によって前面に表示される。windowname.focus () 関数にはＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ４（Ｒ）ブラウザでは無矛盾の結果を生成しえないとうい弱点がある。

インタープリタ型のクライアント側言語を用いてアプリケーションを生成する際に主に考慮すべき点は互換性問題である。アプリケーションが異なると、それがサポートするＨＴＭＬのレベルも異なる。アプリケーションがサポートしうるＪａｖａＳｃｒｉｐｔ機能の個数は当該アプリケーションで使用するインタープリタタによって決まる。

開かれているアプリケーション・ウインドウを閉じる別の方法にはシステムが装備している機能（たとえばアプリケーション・タスク・バー上の「Ｘ」アイコン、タスク・マネージャ）によるもの、あるいはメニュー・バー上のファイル／終了を使用するものがある。これにより開かれているアプリケーション・ウインドウは閉じられるが、それは始めのアプリケーション・ウインドウ内から表示されネットワーク化された、またはネットワーク化されていないアプリケーション・ウインドウを閉じる動作を自動化するものではなく、ユーザが行なう閉じる動作に依存している。

本発明によれば、次に示す方法が提供される。アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じる方法であって、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じるステップを備えた方法。本発明は子アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して当該子アプリケーション・ウインドウを自動的に閉じる方法を提供する。本発明では、親アプリケーション・ウインドウがもはや存在しない場合、子アプリケーション・ウインドウを閉じる。表示済みの各アプリケーション・ウインドウは当該表示済みの各アプリケーション・ウインドウに付随するアプリケーション・ウインドウ制御によって親および子の役割を演じる。ウインドウ制御を表示済みの各アプリケーション・ウインドウに関連付けることにより、表示済みのアプリケーション・ウインドウはそれが表示される元を成すアプリケーション・ウインドウが存在するか否かを検出することができる。

本発明に係る方法は前記アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するインジケータをポーリングして前記インジケータの存在を確認し、前記アプリケーション・ウインドウを閉じるべきでないか否かを判断するステップを備えているのが望ましい。本発明は前記アプリケーション・ウインドウまたは引き続いて表示されたアプリケーション・ウインドウであってユーザがまだ必要としているアプリケーション・ウインドウを閉じることなく、前記アプリケーション・ウインドウ内のデータをリフレッシュまたは再ロードするステップを備えている。

本発明に係る方法はアプリケーションの環境の外部にあるリソースへナビゲートするイベントを備えているのが望ましい。リソースがアプリケーションの環境の外部へナビゲートされたら、アプリケーション・ウインドウを閉じる。

本発明に係る方法はアプリケーション・ウインドウの親アプリケーション・ウインドウのインジケータの状態をモニタするステップを備えているのが望ましい。本発明に係る方法はネットワーク環境において動作するアプリケーション・ウインドウを備えているのが望ましい。

本発明の第２の側面によれば、次に示すプログラムが提供される。アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じるプログラムであって、コンピュータに、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じるステップを実行させるプログラム。

本発明の第３の側面によれは、次に示すシステムが提供される。アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じるシステムであって、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じる手段を備えたシステム。

本発明に係るシステムは前記アプリケーション・ウインドウの親アプリケーション・ウインドウに付随する前記インジケータをポーリングして前記インジケータの存在を確認し、前記アプリケーション・ウインドウを閉じるべきでないか否かを判断する手段を備えているのが望ましい。本発明に係るシステムは前記アプリケーションの環境の外部にあるリソースへのナビゲーションであるイベントの発生を検出する手段を備えているのが望ましい。

本発明に係るシステムは前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随する前記インジケータの状態をモニタする手段を備えているのが望ましい。本発明に係るシステムは前記アプリケーション・ウインドウ内のデータを破壊することなく前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウをリフレッシュする手段を備えているのが望ましい。

本発明に係るシステムは必要なアプリケーション・ウインドウを閉じることなく前記親アプリケーション・ウインドウを閉じる手段を備えているのが望ましい。

本発明はネットワーク環境で動作するときに、ネットワーク・ページ配送遅延に固有の問題を考慮している。本発明はアプリケーションがそのウインドウ内のデータを再ロードまたはリフレッシュしているときに、インジケータの存在をポーリングし当該インジケータの存在を確認する手段を備えている。それが存在しない場合、上記方法はｍ秒間停止したのち当該インジケータの存在をチェックする。これにより、従属アプリケーション・ウインドウを閉じることなくアプリケーション・ウインドウ内のデータをリフレッシュすることが可能になる。これにより、リフレッシュしているアプリケーション・ウインドウのデータ構造を破壊しないという利点も実現する。既存のデスクトップ・システムとは異なり、ユーザ・セッションを通じてフラグが存在するから、データが失われない。したがって、本発明によれば、任意の所定時にどのアプリケーション・ウインドウが開いているか、どのイベント・ハンドラが使用中であるかを示すリストを保持している必要がない。

本発明によれば、本発明に係る方法、プログラム、およびシステムは様々なアプリケーションを通じて動作することができ、特定のアプリケーションに固有のものではないという点でさらなる利点が得られる。

図１を参照する。ネットワーク・アプリケーション２がネットワーク３を介してアクセスするポータル環境１は他のサービス４への複数のハイパーテキスト・リンク（たとえばバンキング５、保険６、投資７、ローン８、年金１０、および貯蓄１１）を備えている。

サービスのハイパーテキスト・リンクをクリックするとサービス４にアクセスすることができる。アプリケーションは要求されたリソースのＵＲＬ１２を含む要求メッセージ１３をネットワーク３を介してネットワーク・サーバ１５に送付する。ネットワーク・サーバ１５は要求されたリソースのパス名１２をルックアップする。そして、ネットワーク・サーバ１５は応答メッセージ１４にファイル内容を含めネットワーク３を介してアプリケーション２に返送する。要求されたリソース１２はポータル環境１のアプリケーション・ウインドウにロードされる。

始めのアプリケーション・ウインドウでポータル・ホームページにアクセスしたまま、複数のサービスにアクセスし、当該複数のサービスを表示済みの複数のアプリケーション・ウインドウにロードすることができる。

図２を参照する。ポータル・ホームページ２１のインターネット・バンキング・セクションから「署名」ハイパーテキスト・リンク２０を選択してインターネット・バンキングにアクセスする。新たなアプリケーション・ウインドウ２２がポータル・ホームページ２１とともに表示される。アプリケーションにユーザを特定するために、アプリケーションの様式フィールド２５に秘密情報を入力する必要がある。ログオンが成功裏に完了すると、第２のアプリケーション・ウインドウ２３が表示される。第２のアプリケーション・ウインドウ２３には口座管理ウインドウに属す選択肢のリストがハイパーテキスト・リンク２６を選択するものとして表示される。現在の口座を管理するには、現在の口座２６なるハイパーテキスト・リンクを選択する。すると、第３のアプリケーション・ウインドウ２４が表示される。新たに表示されたアプリケーション・ウインドウにはさらなる選択肢が表示される。図２の例では、単なる例示として、コンピュータ画面に合計で４重に入れ子状態にされたアプリケーション・ウインドウが開かれている。各アプリケーション・ウインドウはそれが表示される元を成したアプリケーション・ウインドウに従属している。

本発明はネットワーク環境および非ネットワーク環境の双方に等しく適用することができる。ネットワーク環境とは必要な情報がネットワーク上に配置されたサーバに格納されている環境のことであり、非ネットワーク環境とは必要な情報がユーザのコンピュータのディスク記憶装置に格納されておりオフラインでアクセスしうる環境のことである。

次に図３を参照する。ポータル環境内またはポータル環境外の他のサービスへのハイパーテキスト・リンクを表示したポータル・ホームページ・アプリケーションを表示する（３１）。表示したポータル・ホームページ・ウインドウで「KeepOpen」と呼ばれる変数をインスタンス化する（３２）。ポータル・ホームページ１からハイパーテキスト・リンクを選択して従属アプリケーション・ウインドウを表示する（３３）。

表示したアプリケーション・ウインドウのｈｔｍｌページの＜body＞タグはonLoad () 関数を含んでいる。onLoad () 関数は初期関数を呼び出す。この初期関数はアプリケーションの親ウインドウに現在ロードされているデータがたとえば「KeepOpen」と呼ばれる変数を含んでいる否かを確認するチェックを実行する（３４）。

初期関数が「偽」値を返したら（３５）、初期関数は上記変数が存在するか否かのチェックをｍ秒間停止する（３６）。これにより、ユーザまたは別のアプリケーションが親アプリケーションをリフレッシュすることが可能になる。

ｍ秒後、初期関数は「KeepOpen」変数に関するチェックを再開する（３７）。初期関数が「KeepOpen」変数が存在することを見いだしたら、初期関数は真値を返す（３８）。初期関数は上記変数の存在のチェックをｎ秒間停止する（３９）。ｎ秒後、初期関数は「KeepOpen」変数に関するチェックを再開する

初期関数は当該初期関数が「偽」値を返すまで（３５）、このプロセスを続ける。初期関数は「KeepOpen」変数に関するチェックをｍ秒間停止する。これにより、親アプリケーションをリフレッシュすることが可能になる。ｍ秒後、初期関数は「KeepOpen」変数に関するチェックを再開する。「KeepOpen」変数が存在しない場合には「偽」値を返す（４１）。そして、子ウインドウを閉じる（４２）。

本発明はアプリケーションがそのウインドウ内のデータを再ロードまたはリフレッシュしているときにネットワーク・ページの配送遅延に固有の問題を考慮している。本発明はインジケータ（標識）の存在下でポーリングして当該インジケータの存在を確認する方法を提供するものである。それが存在しない場合、上記方法はｍ秒間停止したのち当該変数の存在をチェックする。このプロセスによって、従属アプリケーション・ウインドウを閉じることなくアプリケーション・ウインドウ内のデータをリフレッシュすることが可能になる。これにより、リフレッシュしているアプリケーション・ウインドウのデータ構造を破壊しないという利点も実現する。既存のデスクトップ・システムとは異なり、ユーザ・セッションを通じてフラグが存在する。したがって、本発明によれば、任意の所定時にどのアプリケーション・ウインドウが開いているか、どのイベント・ハンドラが使用中であるかを示すリストを保持している必要がない。

次に本発明の図４を参照する。ポータル環境内から複数のアプリケーション・ウインドウを表示することができる。各アプリケーション・ウインドウはそれが表示された元をなすアプリケーションに従属している。

ポータル環境の外部にあるリソースへナビゲートする、または閉じるボタンをクリックして金融アプリケーション・ウインドウ５１を閉じると、個人銀行口座アプリケーション・ウインドウ５２と現在の口座アプリケーション・ウインドウ５３が閉じられる。現在の口座アプリケーション・ウインドウ５３は個人銀行口座アプリケーション・ウインドウ５２に従属している。個人銀行口座アプリケーション・ウインドウ５２は金融アプリケーション・ウインドウ５１に従属している。各ウインドウはそれが表示された元を成すウインドウに従属している。なぜなら、論理は従属ウインドウで実行されているからである。表示済みの各アプリケーション・ウインドウは親および子の役割を演じる。しかし、親アプリケーション・ウインドウ内からアプリケーション・ウインドウをさらに表示した場合にのみ、子アプリケーション・ウインドウが生成される。

現在の口座アプリケーション・ウインドウ４３を閉じると、現在の口座アプリケーション・ウインドウ５３が閉じられる。なぜなら、この例では従属ウインドウは存在しないからである。

ポータル・ホームページ・ウインドウ５０を閉じると、金融アプリケーション・ウインドウ５１、個人銀行口座アプリケーション・ウインドウ５２、および現在の口座アプリケーション・ウインドウ５３が閉じられる。

従来技術におけるのと同様にネットワーク環境または非ネットワーク環境でアクセスするポータル環境を示す図である。従来技術におけるポータル環境での複数のアプリケーションを示す図である。本発明に係るアプリケーション・ウインドウを閉じる方法を示すフローチャートを示す図である。本発明によって説明される複数のアプリケーション・ウインドウ間の関係を示す図である。

符号の説明

１ポータル環境
２ネットワーク・アプリケーション
３ネットワーク
４サービス
５バンキング
６保険
７投資
８ローン
９モーゲージ
１０年金
１１貯蓄
１２ＵＲＬ
１３要求メッセージ
１４応答メッセージ
１５ネットワーク・サーバ
２０「署名」ハイパーテキスト・リンク
２１ポータル・ホームページ
２２新たなアプリケーション・ウインドウ
２３第２のアプリケーション・ウインドウ
２４第３のアプリケーション・ウインドウ
２５様式フィールド
２６ハイパーテキスト・リンク

Claims

アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じる方法であって、
前記アプリケーション・ウインドウが、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウが、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じるステップ
を備えた
方法。
さらに、
前記アプリケーション・ウインドウの親アプリケーション・ウインドウに付随する前記インジケータをポーリングして前記インジケータの存在を確認し、前記アプリケーション・ウインドウを閉じるべきでないか否かを判断するステップ
を備えた、
請求項１に記載の方法。
前記インジケータをポーリングする前記ステップがさらに、
前記アプリケーション・ウインドウの親アプリケーション・ウインドウに付随する前記インジケータの状態をモニタするステップ
を備えている、
請求項２に記載の方法。
前記アプリケーション・ウインドウの親アプリケーション・ウインドウの前記インジケータの状態をモニタする前記ステップが、
前記アプリケーション・ウインドウ内のデータを破壊することなく前記アプリケーション・ウインドウの親アプリケーション・ウインドウをリフレッシュするステップ
を備えている、
請求項３に記載の方法。
前記イベントが、前記アプリケーションの環境の外部にあるリソースへのナビゲーションである、
請求項１に記載の方法。
アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じるプログラムであって、
コンピュータに、
前記アプリケーション・ウインドウが、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウが、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じるステップ
を実行させる
プログラム。
アプリケーション・ウインドウの親アプリケーション・ウインドウに付随するイベントに応答して前記アプリケーション・ウインドウを閉じるシステムであって、
前記アプリケーション・ウインドウにより、前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウに付随するインジケータをポーリングし、前記インジケータが存在しない場合、前記アプリケーション・ウインドウにより、システムに備えられた関数にアクセスし前記アプリケーション・ウインドウを閉じる手段
を備えた
システム。
さらに、
前記アプリケーション・ウインドウの親アプリケーション・ウインドウに付随する前記インジケータをポーリングして前記インジケータの存在を確認し、前記アプリケーション・ウインドウを閉じるべきでないか否かを判断する手段
を備えた、
請求項７に記載のシステム。
前記イベントが、前記アプリケーションの環境の外部にあるリソースへのナビゲーションである、
請求項７に記載のシステム。
前記インジケータをポーリングする前記手段がさらに、
前記アプリケーション・ウインドウの親アプリケーション・ウインドウに付随する前記インジケータの状態をモニタする手段
を備えている、
請求項９に記載のシステム。
前記アプリケーション・ウインドウの親アプリケーション・ウインドウの前記インジケータの状態をモニタする前記手段が、前記アプリケーション・ウインドウ内のデータを破壊することなく前記アプリケーション・ウインドウの前記親アプリケーション・ウインドウをリフレッシュするよう考慮している、
請求項１０に記載のシステム。
前記アプリケーション・ウインドウの親アプリケーション・ウインドウの前記インジケータの状態をモニタする前記手段が、必要なアプリケーション・ウインドウを閉じることなく前記親アプリケーション・ウインドウを閉じる手段を備えている、
請求項１０に記載のシステム。