(57)【要約】【課題】  アプリケーションにおける通知情報の見落しを防止するための方法およびシステムを提供する。【解決手段】  アプリケーション・インターフェース、例えば、インスタント・メッセージング・セッション・ウィンドウのクローズに対する要求に応答して、チェックに関する２つの実施例が開示される。第１の実施例では、その方法は、最後の通知情報以後にアプリケーション・インターフェースが選択されたかどうかをチェックするステップ、およびアプリケーション・インターフェースがそのように選択されなかった場合、クローズの確認を求めるステップを含む。第２の実施例では、その方法は、最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするステップ、およびその期間が閾値期間よりも短い場合、クローズの確認を求めるステップを含む。【選択図】  図４
2006155605.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションにおける通知情報の見落しを防止するための方法であって、
アプリケーション・インターフェースのクローズを要求するステップと、
通知情報が見落された可能性があるかどうかを決定するステップと、
前記可能性があるという決定に応答して前記クローズの確認を求めるステップと、
を含む方法。
【請求項２】
前記決定するステップが、
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されたかどうかをチェックするステップと、
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されなかった場合、前記クローズの確認を求めるステップと、
を含む、請求項１に記載の方法。
【請求項３】
前記チェックするステップにおいて、前記アプリケーション・インターフェースが選択された場合、
事前定義された閾値期間よりも短い期間の間に前記アプリケーション・インターフェースが選択されたかどうかをチェックするステップと、
該チェックの結果が肯定的である場合、前記クローズの確認を求めるステップと、
を実行するステップを含む、請求項２に記載の方法。
【請求項４】
前記アプリケーション・インターフェースがアプリケーション・グラフィカル・ウィンドウである、請求項１、２、または３に記載の方法。
【請求項５】
前記アプリケーション・インターフェースを選択することが、前記アプリケーション・グラフィカル・ウィンドウにフォーカスすることである、請求項４に記載の方法。
【請求項６】
前記アプリケーションがインスタント・メッセージング・クライアント・アプリケーションであり、前記アプリケーション・インターフェースがインスタント・メッセージング・セッション・ウィンドウであり、前記通知情報がインスタント・メッセージング・セッションにおける受信されたメッセージである、請求項１乃至５のいずれかに記載の方法。
【請求項７】
アプリケーション・インターフェースのクローズを要求する前記ステップの後、
最後の通知が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするステップと、
前記期間が前記閾値期間よりも短い場合、前記クローズの確認を求めるステップと、
を更に含む、請求項１乃至６のいずれかに記載の方法。
【請求項８】
前記決定するステップが、
最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするステップと、
前記期間が前記閾値期間よりも短い場合、前記クローズの確認を求めるステップと、
を含む、請求項１に記載の方法。
【請求項９】
前記最後の通知情報が受信された後に前記アプリケーションに関するアクションが実行された場合、クローズの確認を求める前記ステップをスキップする、請求項７または８に記載の方法。
【請求項１０】
前記アプリケーション・インターフェースがアプリケーション・グラフィカル・ウィンドウである、請求項８または９に記載の方法。
【請求項１１】
前記アプリケーション・インターフェースを選択することが前記アプリケーション・グラフィカル・ウィンドウにフォーカスすることである、請求項１０に記載の方法。
【請求項１２】
前記アプリケーションがインスタント・メッセージング・クライアント・アプリケーションであり、前記アプリケーション・インターフェースがインスタント・メッセージング・セッション・ウィンドウであり、前記通知情報がインスタント・メッセージング・セッションにおける受信されたメッセージである、請求項８乃至１１のいずれかに記載の方法。
【請求項１３】
アプリケーション・インターフェースのクローズを要求する前記ステップの後、
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されたかどうかをチェックするステップと、
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されなかった場合、前記クローズの確認を求めるステップと、
を更に含む、請求項８乃至１２のいずれかに記載の方法。
【請求項１４】
アプリケーションにおける通知情報の見落しを防止するためのシステムであって、
通知情報を受信するための手段を含むアプリケーションと、
前記アプリケーションのためのアプリケーション・インターフェースと、
前記アプリケーション・インターフェースのクローズを要求するための手段と、
通知情報が見落された可能性があるかどうかを決定するための手段と、
前記可能性があるという決定に応答して、前記クローズの確認を求めるための手段と、
を含むシステム。
【請求項１５】
前記決定するための手段が、クローズ要求に応答して、前記アプリケーション・インターフェースが、最後の通知情報の受信以後に選択されたかどうかをチェックするための手段を含み、
アプリケーション・インターフェースが最後の通知情報の受信以後に選択されなかった場合、前記クローズの確認を求めるための手段を更に含む、請求項１４に記載のシステム。
【請求項１６】
前記アプリケーション・インターフェースが、事前定義された閾値期間よりも短い期間の間に選択されたかどうかをチェックするための手段と、
事前定義された閾値期間よりも短い期間の間に前記アプリケーション・インターフェースが選択されたという決定に応答して、前記クローズの確認を求めるための手段と、
を更に含む、請求項１５に記載のシステム。
【請求項１７】
前記アプリケーション・インターフェースがアプリケーション・グラフィカル・ウィンドウである、請求項１４乃至１６に記載のシステム。
【請求項１８】
前記アプリケーション・インターフェースを選択するための手段が前記アプリケーション・グラフィカル・ウィンドウにフォーカスする、請求項１７に記載のシステム。
【請求項１９】
前記アプリケーションがインスタント・メッセージング・クライアント・アプリケーションであり、前記アプリケーション・インターフェースがインスタント・メッセージング・セッション・ウィンドウであり、前記通知情報がインスタント・メッセージング・セッションにおける受信されたメッセージである、請求項１４乃至１８のいずれかに記載のシステム。
【請求項２０】
最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするための手段と、
前記期間が前記閾値期間よりも短いことに応答して、前記クローズの確認を求めるための手段と、
を更に含む、請求項１４乃至１９のいずれかに記載のシステム。
【請求項２１】
前記決定するための手段が、
クローズ要求に応答して、最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするための手段と、
前記期間が前記閾値期間よりも短い場合、前記クローズの確認を求めるための手段と、
を更に含む、請求項１４に記載のシステム。
【請求項２２】
最後の通知情報が受信された後にアプリケーションに関するアクションが実行されなかったことを決定し、従って、前記クローズの確認を求めない手段を更に含む、請求項２０または２１に記載のシステム。
【請求項２３】
前記アプリケーション・インターフェースがアプリケーション・グラフィカル・ウィンドウである、請求項２１または２２に記載のシステム。
【請求項２４】
前記アプリケーション・インターフェースを選択するためのシステムが前記アプリケーション・グラフィカル・ウィンドウにフォーカスする、請求項２３に記載のシステム。
【請求項２５】
前記アプリケーションがインスタント・メッセージング・クライアント・アプリケーションであり、前記アプリケーション・インターフェースがインスタント・メッセージング・セッション・ウィンドウであり、前記通知情報がインスタント・メッセージング・セッションにおける受信されたメッセージである、請求項２１乃至２４のいずれかに記載のシステム。
【請求項２６】
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されたかどうかをチェックするための手段と、
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されなかったという決定に応答して、前記クローズの確認を求めるための手段と、
を更に含む、請求項２１乃至２５のいずれかに記載のシステム。
【請求項２７】
コンピュータ可読記憶媒体に記憶され、アプリケーションにおける通知情報の見落しを防止するためのコンピュータ・プログラムであって、
アプリケーション・インターフェースのクローズを要求するステップと、
通知情報が見落された可能性があるかどうかを決定するステップと、
前記可能性があるという決定に応答して前記クローズの確認を求めるステップと、
を遂行するためのコンピュータ可読プログラム・コード手段を含むコンピュータ・プログラム。
【請求項２８】
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されたかどうかをチェックするステップと、
前記アプリケーション・インターフェースが最後の通知情報の受信以後に選択されなかった場合、前記クローズの確認を求めるステップと、
を遂行するためのコンピュータ可読プログラム・コード手段を含む、請求項２７に記載のコンピュータ・プログラム。
【請求項２９】
最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするステップと、
前記期間が前記閾値期間よりも短い場合、前記クローズの確認を求めるステップと、
を遂行するためのプログラム・コード手段を含む、請求項２７または２８に記載のコンピュータ・プログラム。
【請求項３０】
アプリケーションにおける通知情報の見落しを防止するためのコンピュータ・プログラムであって、該プログラムがコンピュータ上で稼動するとき、請求項１乃至１３に記載の方法を遂行するように適応したプログラム・コード手段を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションにおける通知情報の見落しを防止する分野に関するものである。特に、インスタント・メッセージング・アプリケーションにおいて未読のメッセージの見落しを防止することに関するものである。
【背景技術】
【０００２】
本発明は、発明の実現方法の実施例に関する詳細な説明およびこれらが従来技術の短所に対処する方法を提供するために、インスタント・メッセージングに関連して説明される。しかし、本発明は、他のアプリケーションにも同様に適用することが可能であり、インスタント・メッセージング・アプリケーションに限定されるものと解釈されるべきではない。本発明は、アプリケーションが受け取り且つユーザが知るべき非ユーザ作成のイベント、通知情報、または警告を含むいずれのアプリケーションにも適用可能である。
【０００３】
インスタント・メッセージング（ＩＭ）は、ユーザがリアル・タイムでメッセージを他のユーザに送ることおよび他のユーザから受け取ることを可能にする。第１のユーザは、自分のコンピュータを動作させるＩＭクライアント・ソフトウェア・アプリケーションを有する。その第１のユーザが、インターネットのようなネットワークに接続されることによってオンラインであるとき、ＩＭクライアント・アプリケーションがＩＭサーバへの接続をオープンする。ＩＭクライアント・アプリケーションは、ＩＭサーバに対してログ・オンするためにユーザ識別子およびパスワードを送る。ＩＭサーバは、ＩＭ機能を可能にする通信プロトコルを使用する。
【０００４】
ＩＭクライアント・アプリケーションはコンタクト・リストを含む。そのコンタクト・リストは、第１のユーザがメッセージを送りたい宛先である他のユーザのリストである。そのコンタクト・リストにおいて識別されたユーザがオンラインとなり、ＩＭサーバに対してログ・オンするとき、第１のユーザは、メッセージを送信および受信することが可能であることを通知される。メッセージがＩＭサーバに送られ、ＩＭサーバは、識別されたユーザまでそのメッセージを経路指定する。ＩＭシステムの或るアプリケーションでは、メッセージがＩＭクライアント相互間で直接に送られ、ＩＭサーバはメッセージの転送に関与しない。
【０００５】
ＩＭアプリケーションは、主として、テキスト・ベースのチャット、スクリーン共用、ホワイト・ボーディング等に対して使用される。テキスト・ベースのチャットの場合、ＩＭクライアント・アプリケーションは、ユーザがコンタクト時に持とうとしている各チャットまたはセッションのためのウィンドウをユーザのコンピュータ・ディスプレイ上に与えるグラフィカル・ユーザ・インターフェースを有する。ウィンドウは、第１のユーザおよびそのユーザのコンタクトの間におけるチャットのスクロール対話を表示する。
【０００６】
ＩＭセッションにおける参加は、ちょっと多忙な人が他の仕事を遂行するのと並行して行うことが多い。そのような他の仕事は、他の人と別のＩＭセッションを行うこと、書類を読むこと、作成すること、プログラムを作ること、または他の任意の活動を含む。ユーザのコンピュータ・ディスプレイを使用して他の活動が遂行されるとき、ＩＭウィンドウは注意を集中されてない。他のアプリケーション・ウィンドウまたは他のＩＭセッション・ウィンドウは、当初のＩＭセッション・ウィンドウにオーバラップするかまたは隠れてしまうことがある。
【０００７】
ユーザは、マウスのようなポインティング装置を使用してウィンドウを選択することによって、または新たなアプリケーションをオープンしてユーザのグラフィカル・ディスプレイにおける前面にその新たなアプリケーションに対するウィンドウを自動的に表示することによって、種々のアプリケーションのグラフィカル・ウィンドウにおけるフォーカスを変更する。既存のウィンドウはフォーカス外れであり、ユーザから部分的または全体的に隠蔽されることがある。隠蔽されるオープン・ウィンドウは、通常、グラフィカル・ディスプレイの端部に、例えば、ツールバーにオープン・ウィンドウの小型アイコンまたは表示として与えられる。そこで、ユーザは、オープンしているが他のウィンドウの後に隠蔽されているウィンドウがあることに気づく。
【０００８】
フォーカス状態にないアプリケーションのウィンドウは、そのウィンドウがグラフィカル・ディスプレイから排除されているがクローズされてはいないことを意味するものに最小化されることもある。再び、最小化されたウィンドウの小型アイコンまたは表示がグラフィカル・ディスプレイの端部に設けられる。
【０００９】
未読のメッセージを含むＩＭウィンドウをクローズすることは非常に起り易い。これは、例えば、新たなメッセージがまさに表示されるときにＩＭウィンドウ・クローズ・ボタンが押されると生じることがある。これは、１つまたは複数のＩＭセッション・ウィンドウを有するＩＭクライアント・アプリケーションをクローズするときにも生じることがある。これは、隠蔽されたまたは最小化されたＩＭウィンドウが存在するときにオペレーティング・システムまたはホストがクローズされた結果としてすべてのウィンドウをクローズするときにも生じ得ることである。
【００１０】
ＩＭクライアント・アプリケーションが受け取ったメッセージは、それらがディスクに保存されず、アプリケーションの再開時に回復されないという点で永続性のものではないかもしれない。非永続性のメッセージにとって、ユーザがアプリケーションをクローズする前にすべての受け取ったメッセージを読むということは非常に重要である。しかし、それは、ディスクに保存される永続性のメッセージに対しても、そのメッセージが緊急性のものであるときには重要であることがある。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、アプリケーションにより受信されたがエンド・ユーザにより読まれていないメッセージのような通知情報の喪失を最小にするための技術を提供することにある。
【課題を解決するための手段】
【００１２】
本発明の１つの局面によれば、アプリケーションにおける通知情報の見落しを防止するための方法が提供される。その方法は、アプリケーション・インターフェースのクローズを要求するステップと、通知情報が見落された可能性があるかどうかを決定するステップと、この可能性があるという決定に応答してクローズの確認を求めるステップとを含む。
【００１３】
１つの実施例では、最後の通知情報以後にアプリケーション・インターフェースが選択されたかどうかをチェックすること、および、アプリケーション・インターフェースが選択されなかった場合、クローズの確認を求めることによって、通知情報が見落された可能性があるかどうかが決定される。
【００１４】
前記チェックするステップにおいて、アプリケーション・インターフェースが選択された場合、その方法は、事前定義された閾値期間よりも短い期間の間にアプリケーション・インターフェースが選択されたかどうかをチェックするステップと、それが肯定された場合、クローズの確認を求めるステップとを実行するステップを含む。
【００１５】
アプリケーション・インターフェースのクローズを要求するステップの後、その方法は、最後の通知情報が受信された以後の期間が事前定義された閾値期間よりも短いかどうかをチェックするステップと、その期間が閾値期間よりも短い場合、クローズの確認を求めるステップとを更に含む。
【００１６】
本発明の第２の局面に基づく１つの実施例によれば、本発明は、アプリケーション・インターフェースのクローズを要求するステップと、最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするステップと、その期間が閾値期間よりも短い場合、クローズの確認を求めるステップとを含む。
【００１７】
最後の通知情報が受信された後にアプリケーションに関するアクションが実行された場合、その方法は、クローズの確認を求めるステップをスキップするステップを含んでもよい。
【００１８】
アプリケーション・インターフェースのクローズを要求するステップの後、その方法は、最後の通知情報以後にアプリケーション・インターフェースが選択されたかどうかをチェックするステップと、アプリケーション・インターフェースが選択されなかった場合、クローズの確認を求めるステップを更に含んでもよい。
【００１９】
本発明の第３の局面によれば、アプリケーションにおける通知情報の見落しを防止するためのシステムが提供される。そのシステムは、通知情報を受信するための手段を含むアプリケーションと、そのアプリケーションに対するアプリケーション・インターフェースと、そのアプリケーション・インターフェースのクローズを要求するための手段と、通知情報が見落された可能性があるかどうかを決定するための手段と、この可能性があるという決定に応答してクローズの確認を求めるための手段とを含む。
【００２０】
１つの実施例によれば、そのシステムは、クローズの要求に応答して、最後の通知情報が受信された以後にアプリケーション・インターフェースが選択されたかどうかをチェックするための手段と、アプリケーション・インターフェースが選択されなかった場合、クローズの確認を求めるための手段とを提供することが望ましい。
【００２１】
そのシステムは、アプリケーション・インターフェースが、事前定義された閾値期間よりも短い期間の間に選択されたかどうかをチェックするための手段を含んでもよい。アプリケーション・インターフェースがその事前定義された閾値期間よりも短い期間の間に選択された場合、システムはクローズの確認を求めることが望ましい。
【００２２】
そのシステムは、最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするための手段を含んでもよい。このチェックの結果が肯定的である場合、クローズの確認が要求されることが望ましい。
【００２３】
本発明の第４の局面に基づく１つの実施例によれば、そのシステムは、クローズの要求に応答して、最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするための手段と、その期間が閾値期間よりも短い場合、クローズの確認を求めるための手段とを含む。
【００２４】
そのシステムは、アプリケーション・インターフェースが最後の通知情報以後に選択されたかどうかをチェックするための手段を含んでもよい。この結果が否定的である場合、システムはクローズの確認を求めることができることが望ましい。
【００２５】
１つの実施例によれば、最後の通知情報が受信された後にアプリケーションに関するアクションが実行されたということが決定される場合、クローズの確認は求められない。
【００２６】
本発明の第５の局面によれば、アプリケーションにおける通知情報の見落しを防止するためのコンピュータ・プログラムが提供される。コンピュータ可読記憶媒体に記憶されたそのコンピュータ・プログラムは、アプリケーション・インターフェースのクローズを要求するステップと、通知情報が見落された可能性があるかどうかを決定するステップと、この可能性があるという決定に応答してクローズの確認を求めるステップとを遂行するためのコンピュータ可読プログラム手段を含む。
【００２７】
通知情報が見落された可能性があるかどうかを決定するために、そのコンピュータ・プログラムは、最後の通知情報が受信された以後の期間が、事前定義された閾値期間よりも短いかどうかをチェックするステップと、その期間が閾値期間よりも短い場合、クローズの確認を求めるステップとを更に遂行するように適応することが望ましい。もう１つの実施例では、最後の通知情報以後にアプリケーション・インターフェースが選択されたかどうかがチェックされ、その結果が否定的である場合、クローズの確認が求められる。
【００２８】
本発明の上記の局面すべてにおいて、アプリケーション・インターフェースがアプリケーション・グラフィカル・ウィンドウであってもよく、アプリケーション・インターフェースの選択がアプリケーション・グラフィカル・ウィンドウにおいてフォーカスしてもよい。
【００２９】
アプリケーションはインスタント・メッセージング・クライアント・アプリケーションであり、アプリケーション・インターフェースはインスタント・メッセージング・セッション・ウィンドウであり、通知情報はインスタント・メッセージング・セッションにおける受信されたメッセージである。
【００３０】
本発明はコンピュータ・ソフトウェアとして実施されることが望ましい。本発明は、添付図面を参照することにより単に例を通して説明される。
【発明を実施するための最良の形態】
【００３１】
図１は、通知情報の見落しを防止する方法およびシステムを適用することが可能なインスタント・メッセージング・システムを示す。インスタント・メッセージング（ＩＭ）クライアント・アプリケーション１０２が第１ユーザのコンピュータにおいて動作する。ＩＭサーバ１０４とも呼ばれるＩＭサービス・アプリケーションがインターネット１０６のようなネットワークを介してＩＭ機能を提供する。
【００３２】
ＩＭクライアント・アプリケーション１０２がＩＭサーバ１０４にログ・オンする時、サーバ１０４はスクリーン名およびパスワードをチェックする。これは、別個のログイン・サーバによって行われてもよい。ＩＭサーバ１０４は、ＩＭ機能を可能にする通信プロトコルを使用する。ＩＭクライアント・アプリケーション１０２はグラフィカル・ユーザ・インターフェース（ＧＵＩ）を有し、そのＧＵＩは第１ユーザのグラフィカル・ディスプレイ上に第１ユーザに対するインスタント・メッセージング機能を表示する。
【００３３】
ＩＭクライアント・アプリケーション１０２はコンタクト・リスト機能を含む。第１ユーザがメッセージを送信および受信したい人のリストが、そのＩＭクライアント・アプリケーション１０２に記憶される。リストされた人がオンラインになるとき、第１ユーザがＩＭサーバ１０４によって通知されるよう、コンタクトのスクリーン名に関するこのリストがＩＭサーバ１０４に通信される。
【００３４】
各コンタクトは、それ自身のＩＭクライアント・アプリケーション１０７、１０８、１０９を有し、そのアプリケーションがそれらのコンピュータの各々において動作する。それらのコンタクトのいずれかがログ・オンするとき、それらがオンラインであるということを、第１ユーザのＩＭクライアント・アプリケーション１０２が通知される。そこで、インスタント・メッセージをリアル・タイムで送信および受信することが可能となる。各メッセージはＩＭサーバ１０４に送られ、ＩＭサーバ１０４は意図された受信者にそのメッセージを経路指定する。
【００３５】
図２を参照すると、例えば、コンピュータ・スクリーン上に設けることが可能なユーザのグラフィカル・ディスプレイ２００が示される。デスクトップとも呼ばれることがあるグラフィカル・ディスプレイ２００は、通常、そのグラフィカル・ディスプレイ２００から稼動されるべき、ユーザにとって利用可能なアプリケーションを表す多数のアイコン２０１を有する。グラフィカル・ディスプレイ２００の一例は、Windows（マイクロソフト・コーポレーションの商標）ディスプレイ・システムである。
【００３６】
現在グラフィカル・ディスプレイ２００上で動作しているアプリケーションは、それぞれ、１つまたは複数のグラフィカル・ウィンドウ２０２、２０３、２０４を有する。複数のウィンドウが表示される場合、それらのウィンドウは最前面におけるフォーカス状態のウィンドウ２０４と重なることがある。現在フォーカス状態にないウィンドウ２０２、２０３は部分的にまたは全体的に他のウィンドウの背後に隠されることがある。オープンしているがフォーカス状態にないウィンドウは、それを更に小さくするようにまたはそれらをアイコンまたは表示まで縮小するように最小化されることもある。最小化されたウィンドウを含むオープンしているがフォーカス状態にないいずれのウィンドウもフォーカス外れであると呼ばれる。
【００３７】
現在フォーカス状態にあるアプリケーションの動作にオプションの選択を提供するアプリケーション・ツールバー２０５が、グラフィカル・ディスプレイの最上部に設けられることが多い。
【００３８】
オープンしているアプリケーションおよびウィンドウの小型グラフィカル標識２０７〜２１０を含むことが可能である汎用ツールバー２０６も設けられる。それら標識の１つ２１０は、現在使用中であり且つフォーカス状態にあるウィンドウ２０４を有するアプリケーションを表すことが可能である。他の標識２０７、２０８は、現在使用中ではないアプリケーションであって、表示されてはいるがフォーカス外れであるウィンドウ２０２、２０３を有するアプリケーションを表すことが可能である。他の標識２０９は、オープンしているが現在使用中ではないアプリケーションであって、最小化されたウィンドウを有し、従って、グラフィカル・ディスプレイ２００上には示されていないアプリケーションを表すことが可能である。汎用ツールバー２０６における小型グラフィカル標識２０７〜２１０によって表されたアプリケーションのこれらの種々のステータスは、種々の方法で標識２０７〜２１０を強調表示することによって示されてもよい。
【００３９】
ＩＭクライアント・アプリケーション１０２のグラフィカル・ユーザ・インターフェースは１つまたは複数のＩＭウィンドウ２０２、２０３、２０４を表示し、それらのＩＭウィンドウの各々は第１ユーザとコンタクトとの間のチャットを示す。第１ユーザが、送信すべきテキストをウィンドウに入れようとしているとき、または受信したテキストを読もうとしているとき、そのウィンドウはフォーカス状態（ウィンドウ２０４の状態）である。しかし、第１ユーザがそのウィンドウを使用しようとしていないとき、例えば、第１ユーザが自分のコンタクトからの応答を待っているとき、そのウィンドウは、最小化されることによってまたはフォーカス状態にあり且つ第１ユーザにより使用中である他のＩＭセッションまたは他のアプリケーションのウィンドウ２０４でもって覆われることによって、フォーカス外れ（ウィンドウ２０２、２０３の状態）であることが多い。
【００４０】
ＩＭウィンドウ２０２、２０３がフォーカス外れであるとき、ＩＭウィンドウの小型グラフィカル標識２０７〜２０９が、通常、第１ユーザのグラフィカル・ディスプレイ２００のツールバー２０６に設けられる。ツールバー２０６は、一般に、ディスプレイ上でオープンしているウィンドウに関係なく第１ユーザから見えるところにある。一般に、既知のＩＭクライアント・アプリケーションでは、新たなメッセージが受信されるときに小型グラフィカル標識２０７〜２０９が何らかの方法で強調表示され、第１ユーザが、ＩＭウィンドウ２０２、２０３の上にフォーカスしてその新たなメッセージを読むことを可能にする。その強調表示は、色の変化、アイコン、音、または他の効果によるものであってもよい。
【００４１】
ＩＭウィンドウは、それらが未読のメッセージを含むとき、クローズされないということを保証することが重要である。これは、ＩＭウィンドウがフォーカス外れにあることからクローズされる場合に生じ得る。特に、これは、オペレーティング・システムまたはホストがシャット・ダウンされると同時にグラフィカル・ディスプレイ上のすべてのウィンドウがクローズされるときに起りそうである。メッセージは、新たなメッセージが受信されるときにウィンドウに対するクローズ・コマンドが動作する場合に見落されることもある。
【００４２】
アプリケーション・ウィンドウをクローズするときに未読メッセージを見落とすという問題に対処するための機能を持ったＩＭクライアント・アプリケーションを説明する。
【００４３】
図３は、個々のチャット・セッションに機能を提供するＩＭセッション３０３と共にＩＭクライアント・アプリケーション３０２を示す。ＩＭクライアント・アプリケーション３０２は、並行して動作する複数のＩＭセッション３０３を有することも可能である。ＩＭセッション３０３は、チャット・セッションに関連したメッセージ３０６を入力するためのメッセージ受信手段３０４およびメッセージ３０６を出力するためのメッセージ送信手段３０５を有する。
【００４４】
ディスプレイ・コントローラ３０７は、グラフィカル・ユーザ・インターフェース（ＧＵＩ）におけるＩＭセッション３０３の表示を制御する。図３には、ＧＵＩウィジェット（widgets）は示されない。フォーカス変更ハンドラ３０９は、ＧＵＩからのフォーカス変更イベントを受け取り、フォーカス状態とフォーカス外れ状態との間でセッション表示の状態を変更する。クローズ・イベント・ハンドラ３１０は、ＩＭセッション・クローズ・イベント３１２、ＩＭアプリケーション・クローズ・イベント３１３、またはシステム・シャットダウン・イベント３１４のようなクローズ・イベントを受信する。それらのクローズ・イベントは、すべて、ＩＭセッション３０３がクローズするという結果を生じさせる。
【００４５】
ＩＭセッション３０３は、ＩＭセッション状態に関する情報の保存を含むセッション状態保存手段３０８を有する。その情報は、
フォーカス状態フラッグのようなフォーカス標識と、
最後のフォーカス変更時間および最後のメッセージ到着時間と、
最後のメッセージ送信時間および「フォーカス変更後の待機時間」（waitForTimeAfterFocusChange）（後述する第１実施例において使用される）と、
「メッセージ受信時間後の待機時間」（waitAfterMessageReceivedTime）と呼ばれるメッセージ受信後の待機期間（後述する第２実施例において使用される）と、
を含む。
【００４６】
セッション状態パラメータに対する時間を記録するためのタイミング手段３１５が設けられる。
【００４７】
ＩＭウィンドウ・クローズ要求を受け取ったときに未読のメッセージを有するＩＭウィンドウを検出するための２つの技法を説明する。ウィンドウは、一旦検出されると、クローズすることが受容可能であることをユーザが確認するまで、クローズしないようにされる。
【００４８】
未読のメッセージの見落しを防止するための方法の第１実施例は、新たなメッセージが到着した後にＩＭウィンドウがユーザによって選択されたかどうかを、ＩＭクライアント・アプリケーションが覚えておくことを必要とする。新たなメッセージが到着した後にＩＭウィンドウが選択されなかったか、または短い事前定義された期間の間だけ選択され、そしてウィンドウ・クローズ要求が受信される場合、そのウィンドウ・クローズ要求の確認が要求される。
【００４９】
いつウィンドウがユーザによって使用されたか、選択されたかの決定は、標準的なグラフィカル・ウィンドウ技法を使用して、例えば、ユーザがマウスによってウィンドウを選択するときに、あるいは、更に一般的に言えば、ウィンドウがフォーカスを与えられたときに行うことが可能である。ウィンドウがフォーカスを得た最後の時間およびウィンドウがフォーカスを得た以後にメッセージが到着したかどうかが共に記憶される。
【００５０】
図３を参照して第１実施例の説明を行うことにする。
【００５１】
ＩＭセッションが開始するとき、
（１）フォーカス変更ハンドラ３０９のフォーカス・イベント処理ルーチンがＩＭセッションＧＵＩウィンドウに対するＧＵＩフォーカス変更イベントにおける関連を登録する。
（２）クローズ・イベント・ハンドラ３１０のクローズ・イベント処理ルーチンが種々のクローズ・イベントにおける関連を登録する。これは次のようなイベントを含む。
−ＩＭセッション・クローズ・イベント３１２（これは、セッション・ウィンドウをクローズすることまたはクローズ・ボタンを作動させることによるものであってもよい）。
−ＩＭアプリケーション・クローズ・イベント３１３（これはすべてのＩＭセッションをクローズする）。
−システム・シャットダウン・イベント３１４。
（３）ＩＭセッション状態保存手段３０８におけるインフォーカス・フラッグが真にセットされる。
（４）ＩＭセッション状態保存手段３０８における最後のフォーカス変更時間が現在の時間にセットされる。
（５）ＩＭセッション状態保存手段３０８における最後のメッセージ到着時間が０にセットされる。
（６）ＩＭセッション状態保存手段３０８における最後のメッセージ送信時間が０にセットされる。
（７）ディスプレイ・コントローラ３０７がメッセージ送信ボタンのクリックおよびエントリ・キーの押下げにおける関連を登録する。
（８）ＩＭセッション状態保存手段３０８における「フォーカス変更後の待機時間」フィールドが或る値、例えば、１０００ミリ秒の値にセットされる。
【００５２】
新たなメッセージ３０６が到着するとき、それはメッセージ受信手段３０４によって処理される。このメッセージ３０６をメッセージ・テキスト領域ウィジェットに表示するために、ディスプレイ・コントローラ３０７が呼び出される。メッセージ３０６が受信された時間を反映するように、ＩＭセッション状態保存手段３０８における最後のメッセージ到着時間が更新される。
【００５３】
ディスプレイ・コントローラ３０７がメッセージ送信ボタンのクリックまたはエンター・キー押下げイベントを受信するとき、それは送信済みメッセージ・テキスト・ウィジェットからメッセージを読み取り、送信のためにそれをメッセージ送信手段３０５に渡す。メッセージ送信手段３０５はメッセージ３０６をＩＭサーバに送る。ＩＭセッション状態保存手段３０８における最後のメッセージ送信時間が現在の時間に更新される。ディスプレイ・コントローラ３０７はテキスト領域ウィジェットにおける送信されたメッセージを表示する。メッセージ・テキスト送信ウィジェットがクリアされる。
【００５４】
フォーカス・イベント処理ルーチン（ハンドラ）３０９がフォーカス変更イベント３１１を知らされるとき、ＩＭセッション・ウィンドウが現在フォーカス状態にあるか否かを表すように、フォーカス状態フラッグがセットされる。フォーカス状態変更時間が現在の時間にセットされる。
【００５５】
イベント・クローズ・ルーチン（ハンドラ）３１０が「クローズ」要求を知らされるとき、クローズ確認対話が表示されるべきか否かを決定するために、次のようなアルゴリズムが使用される。
・メッセージが到着しているかどうか、およびそれが到着した以後、ＩＭセッション・ウィンドウがフォーカス状態を保っているかどうかを決定する。
（ａ）フォーカス状態フラッグが間違っている場合、および
（ｂ）最後のメッセージ受信時間が最後のフォーカス変更時間の後に来る場合、
クローズ確認プロンプトを表示する。
・ＩＭセッション・ウィンドウがフォーカス状態を得る前にメッセージが受信されたかどうかおよびウィンドウが短い期間だけフォーカス状態にあったかどうかを決定する。
（ａ）フォーカス状態フラッグが真である場合、
（ｂ）メッセージ受信時間がフォーカス変更時間の前である場合、および
（ｃ）現在の時間が最後のフォーカス変更時間と「フォーカス変更後の待機時間」との和よりも前である場合、
クローズ確認プロンプトを表示する。
・２つの前の状態が保持されてない場合、クローズ確認プロンプトを示すことなくＩＭセッションをクローズすることが可能である。
【００５６】
複数のＩＭセッションが存在する場合、ロジックが同じように働く。別の方法としては、システム・シャットダウン要求およびＩＭアプリケーション・シャットダウン要求に対して、いかに多くのセッションが未読のメッセージを持っていようとも、１つのクローズ確認対話だけを表示するようにロジックを修正することも可能である。
【００５７】
図４を参照すると、第１実施例の方法の流れ図が示される。ＩＭウィンドウに対するクローズ要求が受信される（４０１）。
【００５８】
最後のメッセージが到着した後にウィンドウが選択されたかどうかが決定される（４０２）。それが肯定される場合（４０３）、事前定義された短い閾値期間よりも長い期間の間ウィンドウがフォーカス状態であったかどうかが決定される（４０４）。このステップは、ユーザがメッセージを読むための十分な時間なしにウィンドウが瞬間的にフォーカスされる（例えば、偶発的にウィンドウを瞬間表示する）場合、これは、ウィンドウがフォーカス状態であったものとは見なさないことを保証する。フォーカス状態の時間が、事前定義された閾値よりも長いこと（４０５）が決定される場合（４０４）、クローズ要求が進行することを許される（４０６）。
【００５９】
フォーカス状態の時間が、事前定義された閾値よりも大きくないこと（４０７）が決定される場合（４０４）、または、最後のメッセージが到着した（４０８）後にウィンドウが選択されなかったことが決定される場合（４０２）、ウィンドウがクローズされるべきであるということの確認がユーザから要求される（４０９）。そのような確認要求は、何らかの更なるアクションが取られる前に返答を要求する関連の音声と共にスクリーン上に現れる対話ボックスの形式で与えられてもよい。
【００６０】
確認が受信されたかどうかが決定される（４１０）。それが肯定される場合（４１１）、ウィンドウ・クローズ要求が進行することが可能である（４０６）。それが否定される場合（４１２）、ウィンドウはオープンのままであろう（４１３）。
【００６１】
未読のメッセージの見落しを防止するための方法の第２実施例は、ＩＭクライアント・アプリケーションが最後のメッセージの到着時間を覚えておくことを必要とする。ＩＭウィンドウをクローズするための要求が新たなメッセージの到着直後に行われる場合、ウィンドウのシャットダウンは、それが安全に行われることをユーザが確認するまで、停止することが可能である。最後のメッセージが到着した以後にメッセージが送られた場合、ユーザは応答前にいずれのメッセージも読んでしまわなければならないと思われるので、このルールは使用されない。
【００６２】
最後のｎミリ秒中にメッセージを受信しており且つ最後のメッセージの到着以後にメッセージを送っていないＩＭウィンドウに対してクローズ要求が行われる場合、ウィンドウ・クローズ要求の確認が、それが安全に行われることをユーザが確認するまで停止されるウィンドウのシャットダウンと共に求められるであろう。
【００６３】
図３を参照して、第２実施例の説明を行うことにする。
【００６４】
ＩＭセッション３０３が開始するとき、上述の第１実施例のステップ（１）乃至（７）の同じステップが実行される。ステップ（８）は次のようなステップと置換される。
（８）ＩＭセッション状態保存手段３０８における「メッセージ受信時間後の待機時間」フィールドが、例えば、５０００ミリ秒の値にセットされる。
【００６５】
新たなメッセージ３０６が到着するときの手順、ディスプレイ・コントローラ３０７が第２メッセージを受信するときの手順、およびフォーカス・イベント処理ルーチン３０９がフォーカス変更を知らされるときの手順はすべて上記の第１実施例に対するものと同じである。
【００６６】
第２実施例では、イベント・クローズ・ルーチン３１０が「クローズ」要求３１２、３１３、３１４を知らされたとき、クローズ確認対話が表示されるべきか否かを決定するために、次のようなアルゴリズムが使用される。
・  （ａ）最後のメッセージ受信時間が最後のメッセージ送信時間の後である場合、および
（ｂ）メッセージ受信時間が現在の時間から「メッセージ受信時間後の待機時間」を引いた時間の後である場合、
クローズ確認プロンプトを表示する。
・  前の条件が持続しない場合、ＩＭセッションはクローズ確認プロンプトを示すことなくクローズすることが可能である。
【００６７】
第１実施例におけるように、複数のＩＭセッションが存在する場合、ロジックは同じように働く。代替方法として、システム・シャットダウン要求およびＩＭアプリケーション・シャットダウン要求に対し、いかに多くのセッションが未読のメッセージを持っていても、１つのクローズ確認対話に対してのみロジックを修正することが可能である。
【００６８】
図５を参照すると、第２実施例の方法の流れ図５００が示される。ＩＭウィンドウに対するクローズ要求が受信される（５０１）。
【００６９】
最後のメッセージが到着した以後の時間が閾値期間よりも長いかどうかが決定される（５０２）。それが肯定される場合（５０３）、ユーザは、最後に受信したメッセージを見るために多くの時間を使ったであろう。そして、ウィンドウ・クローズ要求が進行する（５０４）。
【００７０】
それが否定される場合（５０５）、最後のメッセージの到着とクローズ要求の間の時間は、ユーザが最後のメッセージを読むためには短すぎることがある。
【００７１】
次に、最後のメッセージが到着した以後にメッセージがユーザによって送られたかどうかが決定される（５０６）。それが肯定される場合（５０７）、ユーザは、自分のメッセージを送る前の最後に受信したメッセージを見たに違いないので、クローズ要求が進行してもよい（５０４）。
【００７２】
それが否定される場合（５０８）、ウィンドウがクローズされるべきであるという確認がユーザから要求される（５０９）。そのような確認要求は、何らかの更なるアクションが取られる前に、返答を要求する関連の音声と共にスクリーン上に現れる対話ボックスの形式で提供されてもよい。
【００７３】
確認が受信されたかどうかが決定される（５１０）。それが肯定される場合（５１１）、ウィンドウ・クローズ要求が進行する（５０４）。それが否定される場合（５１２）、ウィンドウはオープンのままであろう。
【００７４】
これらの技法を使用することは、ウィンドウが余りに早くクローズされた結果としてＩＭユーザがメッセージを手離すことを防止する。
【００７５】
本発明は、メッセージがＩＭクライアントにおけるディスクに残らないとき、即ち、メッセージが再開始時に回復されないときに最も適用可能である。しかし、それは、クライアントがクローズされる前にユーザがメッセージを見ることを保証するため、メッセージが残らない場合でも依然として使用可能である。
【００７６】
上記の説明は、インスタント・メッセージングおよびインスタント・メッセージング・ウィンドウのクローズに関するものである。その説明された方法は、非ユーザが生成した通知情報または警報を包含する他のアプリケーションにも適用する。その場合、そのアプリケーションまたはそのアプリケーションのセッションをクローズするときに、ユーザが通知情報または警報を見落とさないようにすることことが重要である。
【００７７】
問題点に関する警報を受け取るもう１つの実施例は管理コンソールであろう。そのコンソールのグラフィカル・ユーザ・インターフェースは、警報が見られなかった場合にはクローズされてはならない。上述の方法は、最後の警報が受信された以後にインターフェースがフォーカスされたかどうか、またはインスタント・メッセージング・アプリケーションに関連して詳細に説明したような閾値期間よりも最後の警報以後の時間経過が長いかどうか、をテストすることによって適用することが可能である。
【００７８】
本発明は、一般的には、コンピュータまたは同様の装置を制御するためのプログラム命令のセットを含むコンピュータ・プログラムとして具現化される。これらの命令は、システムにプリロードされてまたはＣＤ−ＲＯＭのような記憶媒体上に記録されて供給されてもよく、あるいは、インターネットもしくは電話網のようなネットワークを介してダウンロードして利用し得るようにすることも可能である。
【００７９】
本発明の範囲から逸脱することなく、前述の技法に対して改良および修正を施すことが可能である。
【図面の簡単な説明】
【００８０】
【図１】本発明を適用し得るインスタント・メッセージング・システムのブロック図である。
【図２】本発明を適用し得るアプリケーション・インターフェース・ウィンドウを示すグラフィカル・ディスプレイの概略図である。
【図３】本発明に従ってインスタント・メッセージング・クライアント・アプリケーションの概略図である。
【図４】本発明の１つの局面に従って通知の見落しを防止するための方法に関する第１実施例の流れ図である。
【図５】本発明の１つの局面に従って通知の見落しを防止するための方法に関する第２実施例の流れ図である。
【図１】
2006155605.tif 000003
【図２】
2006155605.tif 000004
【図３】
2006155605.tif 000005
【図４】
2006155605.tif 000006
【図５】
2006155605.tif 000007