JP2019003290A - 表示制御装置、表示制御方法及び表示制御プログラム - Google Patents

Abstract

【課題】アプリケーション自体への作り込みを不要としながら、操作手順や時系列、重要度等の不足なく操作全体のリコメンドを表示できる。【解決手段】表示制御装置１０は、制御対象となるアプリケーションに対する操作イベント或いはシステムイベントに対応して設定された１ステップ以上先の操作手順を示す次操作候補要素を生成し、表示するための可視化ルールを複数記憶する記憶部１３と、アプリケーションに対する操作イベント或いはシステムイベントを検知する検知部１４１と、制御対象のアプリケーションウィンドウ上に透明ウィンドウを生成かつ重畳表示し、記憶部が記憶する複数の可視化ルールのうち検知部によって検知されたイベント列に対応する可視化ルールを基に次操作候補要素を生成し、該生成した次操作候補要素を透明ウィンドウ上に表示させる表示制御部１４３と、を有する。【選択図】図１

Description

本発明は、表示制御装置、表示制御方法及び表示制御プログラムに関する。

企業における業務の複雑化に伴い、業務システムの導入によって業務効率を高める試みが行われている。しかしながら、業務実態とシステムの操作性とに乖離があることも多く、必要な手順を飛ばしてしまう、誤操作を引き起こす等のミスオペレーションを誘発する可能性がある。

このような問題に対し、従来では、現場用の運用マニュアルや業務フローの作成によって対処するのが一般的である。ただし、これらのマニュアルや業務フローはシステムごと、業務ごとに存在することが多く、膨大な量となる傾向があるため、作成及びメンテナンスの担当者の負担が大きい。また、現場作業者に対しては、膨大なマニュアルの中から現在の作業に関係する部分を発見するという負担が生じるため、マニュアルが作成されても参照されず、ミスオペレーションが発生する可能性がある。また、業務に不慣れなユーザが操作に迷った際に熟練者に尋ね、対応に時間が取られる可能性もある。

一方で、業務システムにミスオペレーションを防ぐ機能や参照情報を追加するという対応も一般的であるものの、現場ごとの業務実態に合わせたシステムの作り込み、更改は容易ではない。

そこで、近年、ユーザの操作イベントや操作対象のＧＵＩ（Graphical User Interface）要素を監視及び取得し、ログとして蓄積し、今後遷移する可能性のある複数の画面候補や操作フロー、動画、テキスト情報等を操作画面上に提示する方法が提案されている（例えば、特許文献１参照）。この手法では、ユーザの現在の操作に応じて遷移先候補の画面サムネイルが提示されるため、ユーザが操作に迷った際にも、マニュアル等を参照することなく数ステップ先までの操作の流れを把握することが可能である。

また、操作ログの統計から、対象アプリケーション上に自分もしくは他のユーザの操作履歴をヒートマップ表示し、比較することが可能なシステムも提案されている（非特許文献１参照）。このシステムは、ユーザがメニュータブを操作したとき、次に操作する可能性のある当該タブ配下のＧＵＩ要素上にヒートマップを動的に表示することによって、ユーザの現在の操作に応じて次操作をレコメンドする機能を備えている。

このように、特許文献１記載の方法及び非特許文献１記載のシステムは、ユーザの操作ログを用いることによって、各現場の業務実態を反映したレコメンドを実現している。

特許第６００４４４０号公報

J. Matejka, T. Grossman, and G. Fitzmaurice, "Patina: Dynamic Heatmaps for Visualizing Application Usage", In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '13), pp.3227-3236, 2013.

しかしながら、従来技術に係る方法では、操作手順や時系列、重要度等を不足なく表現できないという課題、及び、複数画面に適用できないという課題がある。

具体的には、特許文献１記載の方法では、実際のユーザ操作と候補の表示結果の粒度とに差異があるため、対象アプリケーションに慣れていないユーザが直観的に操作できない可能性がある。

例えば、特許文献１記載の実施例では、メニューバーに対する操作について、ユーザがメニューバーにカーソルを当てると、操作候補提示用の画面上に次に遷移する画面のサムネイルと遷移するまでに何ステップの操作を要するか等の情報を表示する。しかしながら、ユーザの実際の操作内容には、メニューバーにマウスカーソルを当てるとプルダウンメニューが出現し（ステップ１）、プルダウンメニューから１項目を選択すると（ステップ２）、新たな画面が出現する（ステップ３）という３ステップが含まれている。

このため、特許文献１記載の方法では、遷移先の画面とプルダウンメニュー内の項目の紐づけができず、操作手順を直観的に把握することが難しい。さらに、特許文献１記載の方法では、一つの操作に対して複数個の画面候補が提示されるため、ディスプレイ上に提示できる画面候補数に限界がある。特に特許文献１記載の実施例４のように、再帰的な画面表示により数ステップ先の操作フローを入れ子状に表示する場合には、画面候補数の提示に多くの画面領域が必要となると考えられる。また、このように一度に複数ステップを提示した場合、ユーザが提示された情報の中から操作対象の部分を探す必要があるため、操作順の把握に時間がかかる可能性がある。

このように、特許文献１記載の方法では、粒度の細かな操作手順を不足なく提示できていない点、及び、画面上での操作候補表示数に限りがある点に課題がある。

また、非特許文献１記載のヒートマップによる表現は、テキストやフロー等によるレコメンド方法に比べ直観的であり、このような操作画面上に直接次操作候補を重ねるアプローチは、限られた描画領域であっても適用可能という点で有効である。一方で、非特許文献１で提案されているユーザの識別や操作頻度を反映したヒートマップでは、操作の時系列や重要度が十分に表現されないという問題がある。

例えば、非特許文献１のFigure 15では、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｗｏｒｄの「Page Layout」メニュータブをクリックした場合のヒートマップの例が掲載されている。非特許文献１記載の方法では、ユーザの現在の操作に応じて、１ステップ先の操作候補を、彩度で頻度、色相でユーザ種別を表現したヒートマップを数秒間表示することによって、操作のナビゲーションを実現している。しかしながら、非特許文献１の方法では、複数個のヒートマップが短時間に同時に提示されるため、特にシステムに不慣れなユーザは次操作の判断に迷う可能性がある。

さらに、特許文献１及び非特許文献１記載の方法は、いずれも複数画面を対象にしたものではない。実際のオペレーションの現場においては、一つの業務に対して複数のアプリケーションを使用する場合が多い。

例えば、サービス申込みの場面では、顧客管理用のシステム画面に帳票形式で送られてきた顧客情報を転記する、設備情報管理用の業務システム画面を参照するなどの作業が考えられる。このような運用実態を踏まえると、操作画面上への重畳表示による次操作の提示を複数画面に拡大すること、及び、アプリケーションによらず表示可能であることが重要である。前者を考えた場合、画面どうしの重なり、スクロールつきの画面など、操作対象画面としてディスプレイ上に表示されていない部分に次操作候補が存在する場合の表現方法に新たな課題が生じる。後者を考えた場合、アプリケーション自体の作り込みを回避する必要があるという課題が生じる。

本発明は、上記に鑑みてなされたものであって、アプリケーション自体への作り込みを不要としながら、操作手順や時系列、重要度等の不足なく操作全体のリコメンドを表示できる表示制御装置、表示制御方法及び表示制御プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る表示制御装置は、表示装置の表示処理を制御する表示制御装置であって、制御対象となるアプリケーションに対する操作イベント或いはシステムイベントに対応して設定された１ステップ以上先の操作手順を示す次操作候補要素を生成し、表示するための可視化ルールを複数記憶する記憶部と、制御対象となるアプリケーションに対する操作イベント或いはシステムイベントを検知する検知部と、制御対象のアプリケーションウィンドウ上に透明ウィンドウを生成かつ重畳表示し、記憶部が記憶する複数の可視化ルールのうち検知部によって検知されたイベント列に対応する可視化ルールを基に次操作候補要素を生成し、該生成した次操作候補要素を透明ウィンドウ上に表示させる表示制御部と、を有することを特徴とする。

本発明によれば、アプリケーション自体への作り込みを不要としながら、操作手順や時系列、重要度等の不足なく操作全体のリコメンドを表示できる。

図１は、実施の形態に係る表示制御装置の概略構成を示す模式図である。 図２は、図１に示すログデータのデータ構成の一例を示す図である。 図３は、作業及び業務を説明する図である。 図４は、可視化パラメータのデータ構成を示す図である。 図５は、図１に示す検知部による検知処理の処理手順を示すフローチャートである。 図６は、図１に示す判定部による判定処理の処理手順を示すフローチャートである。 図７は、図１に示す次操作候補表示制御部による表示制御処理の処理手順を示すフローチャートである。 図８は、図１に示す表示制御装置の表示制御処理を説明する図である。 図９は、図１に示す表示制御装置の表示制御処理を説明する図である。 図１０は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１１は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１２は、図１に示す可視化ルールの一例を示す図である。 図１３は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１４は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１５は、図１に示す可視化ルールの一例を示す図である。 図１６Ａは、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１６Ｂは、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１７は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１８は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図１９は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２０は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２１は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２２は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２３は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２４は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２５は、図１に示す表示制御装置の表示制御処理の結果を示す画面の一例を示す図である。 図２６は、プログラムが実行されることにより、表示制御装置が実現されるコンピュータの一例を示す図である。

以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

［実施の形態］
まず、実施の形態に係る表示制御装置について、概略構成、表示制御処理の流れ及び具体例を説明する。

実施の形態に係る表示制御装置は、検知されたイベントに対応させて、アプリケーションウィンドウに対する１ステップ以上先の操作手順を示す次操作候補要素を、制御対象のアプリケーションウィンドウ上に重畳表示した透明ウィンドウに表示させる。このため、実施の形態に係る表示制御装置は、アプリケーションウィンドウ上に透明ウィンドウを重ねることで、対象のアプリケーションを限定せず、複数ウィンドウに対しても適用可能である。また、本実施の形態に係る表示制御装置は、アプリケーションウィンドウ上に次操作候補要素を重畳表示するため、表示可能な画面領域が限られている場合であっても、操作の流れに沿った効率的なナビゲーションを実現できる。

図１は、実施の形態に係る表示制御装置の概略構成を示す模式図である。図１に示すように、実施の形態に係る表示制御装置１０は、制御装置４０が有するＯＳ４１及びアプリケーション４２を介して、入力装置２０と接続する。表示制御装置１０は、制御装置４０が有するＯＳ４１を介して、表示装置３０と接続する。本実施の形態では、以下、入力にイベントログを用いた場合の代表的な実現方法について説明する。

入力装置２０は、表示制御装置１０の操作者からの各種操作を受け付ける装置である。入力装置２０は、例えば、マウス、キーボード、タッチパネル、マイクといった入力デバイスによって実現される。入力装置２０が受け付けた各種操作は、操作イベントとして、表示制御装置１０において処理される。

表示装置３０は、表示制御装置１０の表示制御にしたがい画面に画像を表示する装置である。表示装置３０は、例えば、モニタ等により実現される。

制御装置４０は、ＯＳ４１とアプリケーション４２とを有する。ＯＳ４１は、制御装置４０の動作環境を提供するソフトウェアである。アプリケーション４２は、ＯＳ４１上で動作する。アプリケーション４２は、入力装置２０が受け付けたユーザが要求する情報処理を直接実行するソフトウェアである。アプリケーション４２は、Ｗｅｂアプリケーションやネイティブアプリケーションである。

表示制御装置１０は、表示装置３０の表示処理を制御する。表示制御装置１０は、制御部１００及び記憶部１３を有する。

記憶部１３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光ディスク等の記憶装置である。なお、記憶部１３は、ＲＡＭ（Random Access Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non Volatile Static Random Access Memory）等のデータを書き換え可能な半導体メモリであってもよい。記憶部１３は、表示制御装置１０で実行されるＯＳ（Operating System）や各種プログラムを記憶する。さらに、記憶部１３は、プログラムの実行で用いられる各種情報を記憶する。

記憶部１３は、知識ＤＢ１３１を有する。知識ＤＢ１３１は、アプリケーションウィンドウに対する次回以降の操作手順を示す次操作候補要素の生成に要する各種情報を記憶する。例えば、知識ＤＢ１３１は、ログデータ１３２、文脈データ１３３、可視化ルールデータ１３４を記憶する。

ログデータ１３２は、ユーザによる操作イベントやシステムイベント、その他任意のイベントのログデータである。操作イベントは、ユーザのマウスクリック、マウスの軌跡、ショートカットキーによる操作等のイベントである。システムイベントは、ＯＳやミドルウェアに関するログ、Windows（登録商標）のシステムイベントなどである。その他任意のイベントは、例えば、Syslog、サービスやアプリケーション独自のログ、ユーザ認証や任意のリソースに対するアクセス権に関するログなどのセキュリティ関連のイベント等である。

図２は、図１に示すログデータ１３２のデータ構成の一例を示す図である。図２のログデータ１３２ａに示すように、ログデータ１３２には、各イベントの識別子（ＩＤ）、ログの開始時刻及びログの終了時刻すなわちタイムスタンプ、イベントの種別を示すカテゴリ、イベントの内容、イベントソース（Ａｐｐ）、ＧＵＩ要素のＩＤ（部品ＩＤ）、対象となるウィンドウＩＤ、及び、アカウントが登録される。

例えば、イベントＩＤ「Ｓｅ１」のログは、「１１：００」に開始し、「１１：０３」に終了したカテゴリ「Ｓｙｓｔｅｍ」のログであり、「ログオン成功」を示し、イベントソース「Ｓｅｃｕｒｉｔｙ Ａｕｄｉｔｉｎｇ」において、「ｓｙｓｔｅｍ」アカウントで実行されたものである。なお、ログデータ１３２のデータ構成は図２の構成に限らず、各イベントに、部品ＩＤ、ウィンドウＩＤ及びイベントソースを関連付ける別のテーブルを用意してもよい。また、図２の構成では、各行が一つのイベントを示しているが、各行がイベント列で構成されてもよい。

文脈データ１３３は、イベント列に基づく文脈を示すデータである。文脈は、一以上のイベントであるイベント列からイベント列の状態遷移で示される作業と該作業の状態遷移で示される業務とを導出したものである。言い換えると、「文脈」とは、特定のアプリケーションないしは画面、ＧＵＩ要素に対して行われたイベント列から、「作業」、「業務」、ユーザ属性等を導出したものである。この文脈データ１３３は、予め知識ＤＢ１３１に登録されている。

図３は、作業及び業務を説明する図である。図３に示すように、「作業」は、イベント列の状態遷移で表現される。また、「業務」は「作業」の状態遷移で表現される。例えば、イベント列「ｅ１」，「ｅ３」〜「ｅ５」から、「作業Ａ」が導出される。そして、「作業Ａ」〜「作業Ｃ」から、「業務」が導出される。文脈データ１３３は、イベント列と、「作業」や「業務」とのマッピング表である。また、文脈データ１３３は、「文脈」ごとに算出した頻度や重要度を含む。この「文脈」の頻度や重要度は、判定部１４２（後述）によって更新される。

なお、「文脈」の重要度は、例えば、特定の「文脈」におけるユーザの熟練度によって指定してもよい。また、「文脈」の重要度は、特定のキー操作を境に、以降の手順の分散が大きくなる部分を抽出し、当該部分の重要度を高く設定してもよい。また、「文脈」の重要度は、キーとなる操作かどうかによって算出する他、習熟度に応じて高低を設定してもよい。或いは、「文脈」に対し、直前の操作からの経過時間やマウスの動き、予め指定しておいた入力操作等のユーザからの明示的なシグナルにより、ユーザの迷いが発生していると自動または手動で判定される場合に当該部分の重要度を高く設定することも可能である。

可視化ルールデータ１３４は、制御対象となるアプリケーション４２に対する操作イベント或いはシステムイベントに対応して設定された１ステップ以上先の操作手順を示す次操作候補要素を生成し、表示するための可視化ルールである。可視化ルールデータ１３４には、複数の可視化ルールが含まれる。可視化ルールは、可視化パラメータ、対応ルール及び割り当てルールを含む。可視化パラメータは、文脈ごとに、次操作候補要素の可視化方法、次操作候補要素に対する視覚変数、提示ステップ数及び優先度を示す各パラメータが対応付けられた可視化パラメータを示すデータである。対応ルールは、文脈、文脈に対応する頻度及び重要度と可視化パラメータ内のパラメータとの対応関係を示すデータである。また、割り当てルールは、文脈における作業或いは重要度或いは頻度に応じて設定された視覚変数の割り当てルールを示すデータである。

図４は、可視化パラメータのデータ構成の一例を示す図である。図４の可視化パラメータ１３４ａに示すように、可視化パラメータは、文脈ごとに、次操作候補要素の可視化方法、次操作候補要素に対する視覚変数、提示ステップ数及び優先度を示す各パラメータが対応付けられたデータ構成を有する。次操作候補要素に対する視覚変数は、具体的には、図４に示すように、次操作候補要素のノードサイズ、色相、彩度、時系列の示し方である。

例えば、文脈「作業Ａ」に対する次操作候補要素は、ヒートマップ方式で可視化され、ノードサイズは、頻度に応じて調節され、「Ｂｌｕｅ」の色相で、明度の違いによって時系列が表示される。そして、文脈「作業Ａ」ついては、３ステップ先までの操作を示す画像が優先度「１」で表示される。これに対し、文脈「作業Ａ，熟練者」に対する次操作候補要素は、グラフ方式で可視化され、ノードサイズは、頻度に応じて調節され、作業については「Ｂｌｕｅ」の色相を使用し、熟練度については彩度によって調節される。そして、文脈「作業Ａ，熟練者」については、矢印によって時系列が表示され、３ステップ先までの操作を示す画像が優先度「２」で表示される。このように、可視化パラメータ１３４ａは、「文脈」と各パラメータの組み合わせとを示す。

制御部１００は、表示制御装置１０全体を制御する。制御部１００は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等の電子回路や、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路である。また、制御部１００は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。また、制御部１００は、各種のプログラムが動作することにより各種の処理部として機能する。制御部１００は、次操作候補要素表示制御部１４及び可視化アプリケーション１５を有する。

次操作候補要素表示制御部１４は、表示装置３０に表示させる、次操作候補要素を導出し、アプリケーションウィンドウ上に重畳した可視化レイヤの描画及び更新を行う。次操作候補要素表示制御部１４は、検知部１４１、判定部１４２及び表示制御部１４３を有する。

検知部１４１は、制御対象となるアプリケーション４２に対する操作イベント、システムイベント、その他イベントを検知する。検知部１４１は、検知した一以上のイベント、すなわち、イベント列を判定部１４２に入力する。

例えば、検知部１４１は、Ｗｉｎｄｏｗｓ ＯＳであれば、Ｅｎｕｍ Ｗｉｎｄｏｗｓ関数等のウィンドウ一覧を列挙できる方法を用いて、アプリケーションの一覧を取得する。そして、検知部１４１は、ＧｅｔＷｉｎｄｏｗ関数等のＺオーダを列挙できる方法を用いて、取得したウィンドウ一覧のうち、アクティブなウィンドウを判定する。検知部１４１は、判定したアクティブウィンドウのイベント、システムイベントやその他イベント、もしくはこれらイベントの列を検知するごとに、判定部１４２にアプリケーション一覧やアクティブウィンドウの情報、取得したイベント列を流し続ける。

判定部１４２は、記憶部１３が記憶する複数の可視化ルールのうち、検知部１４１によって検知されたイベント列に対応する可視化ルールを判定する。判定部１４２は、検知部１４１で検知したイベント列を基に知識ＤＢ１３１に問い合わせを行い、検知部１４１によって検知されたイベント列に対応する可視化ルールを決定する。判定部１４２は、イベント列の部分集合の表す「作業」、及び「作業」の集合である「業務」といったイベント列の「文脈」、可視化パラメータ、対応ルール、割り当てルールを決定する。言い換えると、判定部１４２は、文脈データ１３２を参照して、検知部１４１によって検知されたイベント列に合致する文脈を求め、文脈とともに、該文脈の作業及び業務、該文脈に対応付けられた頻度及び重要度を取得する。そして、判定部１４２は、知識ＤＢ１３１が記憶する複数の可視化パラメータ、対応ルール、割り当てルールのうち、取得した文脈、該文脈の作業及び業務、該文脈に対応付けられた頻度及び重要度に対応する可視化パラメータ、対応ルール、割り当てルールを求める。

表示制御部１４３は、記憶部１３が記憶する複数の可視化ルールのうち、検知部１４１によって検知されたイベント列に対応する可視化ルールを基に、制御対象のアプリケーションウィンドウ上に透明ウィンドウを生成かつ重畳表示し、該透明ウィンドウ上に次操作候補要素を表示させる。

すなわち、表示制御部１４３は、制御対象のアプリケーションウィンドウ上に透明ウィンドウを生成かつ重畳表示する。そして、表示制御部１４３は、判定部１４２によって求められた、イベント列に合致する文脈、該文脈の作業及び業務、該文脈に対応付けられた頻度及び重要度に対応する可視化パラメータ、対応ルール、割り当てルールを基に次操作候補要素を生成する。表示制御部１４３は、生成した次操作候補要素を表示させる。

表示制御部１４３は、判定部１４２から取得した可視化パラメータ、対応ルール、割り当てルールを基に、アプリケーションウィンドウ上に重ねた透明ウィンドウ上に次操作候補要素を描画する描画処理を行う。透明ウィンドウは、例えば、htmlやJavaScript（登録商標）による描画指定をサポートしたレンダリングエンジン（WebKitやGeckoなど）を搭載したブラウザをベースに、背景の透明化およびツールバーを非表示とした新たなウィンドウを生成することにより実現する。なお、他の実装方法でも可能である。前述のように、表示制御装置１０は、透明ウィンドウ上に実装することにより、対象アプリケーション自体を改変せずに操作手順を示すことが可能になる。また、表示制御装置１０は、複数のアプリケーションに対しての描画にも対応可能である。

可視化アプリケーション１５は、次操作候補要素表示制御部１４から出力された可視化レイヤの描画や更新の指示にしたがい、透明ウィンドウをアプリケーションウィンドウに重畳表示し、次操作候補要素を表示した可視化レイヤを表示装置３０に表示させるアプリケーションである。

［検知処理の処理手順］
次に、検知部１４１による検知処理について説明する。図５は、図１に示す検知部１４１による検知処理の処理手順を示すフローチャートである。

図５に示すように、検知部１４１は、アプリケーションの一覧を取得する（ステップＳ１１）。続いて、検知部１４１は、取得したウィンドウ一覧のうち、アクティブなウィンドウを判定する（ステップＳ１２）。検知部１４１は、アクティブなウィンドウに対するイベントを検知したか否かを判定する（ステップＳ１３）。検知部１４１は、イベントを検知したと判定する場合（ステップＳ１３：Ｙｅｓ）、検知したイベントを判定部１４２へ通知する（ステップＳ１４）。一方、検知部１４１は、イベントを検知していないと判定した場合（ステップＳ１３：Ｎｏ）、ステップＳ１１に戻り、処理を繰り返す。

［判定処理の処理手順］
次に、判定部１４２による判定処理について説明する。図６は、図１に示す判定部１４２による判定処理の処理手順を示すフローチャートである。

図６に示すように、判定部１４２は、知識ＤＢ１３１に問い合わせを行い、検知部１４１から連続して入力されたイベント列が、知識ＤＢ１３１内の「文脈」とマッチするか否かを判定する（ステップＳ２１）。判定部１４２は、イベント列が、知識ＤＢ１３１内の「文脈」とマッチしないと判定した場合（ステップＳ２１：Ｎｏ）、ステップＳ２１に戻り、検知部１４１が検知した新たなイベント列を追加して、再度ステップＳ２１の判定処理を行う。

判定部１４２は、イベント列が、知識ＤＢ１３１内の「文脈」とマッチすると判定した場合（ステップＳ２１：Ｙｅｓ）、イベント列とマッチした「文脈」の頻度及び重要度に変更があるか否かを判定する（ステップＳ２２）。判定部１４２は、イベント列とマッチした「文脈」の頻度及び重要度に変更があると判定した場合（ステップＳ２２：Ｙｅｓ）、イベント列とマッチした「文脈」の頻度及び重要度を再算出し、知識ＤＢ１３１を更新する（ステップＳ２３）。

判定部１４２は、イベント列とマッチした「文脈」の頻度及び重要度に変更がないと判定した場合（ステップＳ２２：Ｎｏ）、または、ステップＳ２３の処理後、知識ＤＢ１３１内の可視化ルールデータ１３４のうち、イベント列と合致した「文脈」から可視化ルールを導出する（ステップＳ２４）。言い換えると、判定部１４２は、知識ＤＢ１３１内の可視化ルールデータ１３４のうち、検知部１４１によって検知されたイベント列に合致する文脈、該文脈の作業及び業務、該文脈に対応付けられた頻度及び重要度、該文脈に対応する可視化パラメータ、対応ルール、割り当てルールを求める。そして、判定部１４２は、求めた可視化ルールを表示制御部１４３へ通知する（ステップＳ２５）。

［表示制御処理の処理手順］
次に、表示制御部１４３による表示制御処理について説明する。図７は、図１に示す表示制御部１４３による表示制御処理の処理手順を示すフローチャートである。

図７に示すように、表示制御部１４３は、判定部１４２によって求められた可視化パラメータ、対応ルール及び割り当てルールを基に、指定されたステップ数の次操作候補要素を生成する（ステップＳ３１）。表示制御部１４３は、透明ウィンドウをアプリケーションウィンドウ上に生成かつ重畳表示させる（ステップＳ３２）。そして、表示制御部１４３は、透明ウィンドウ上に、ステップＳ３１において生成した次操作候補要素を表示装置３０に表示させる（ステップＳ３３）。

［実施の形態の効果］
このように、本実施の形態に係る表示制御装置１０は、検知されたイベントに対応させて、アプリケーションウィンドウに対する１ステップ以上先の次操作候補要素を含む透明ウィンドウを生成し、該生成した透明ウィンドウをアプリケーションウィンドウ上に重畳して表示装置の画面に表示させる。

具体的には、本実施の形態に係る表示制御装置１０は、イベントを基にアプリケーションウィンドウにおけるユーザの操作状況を、時系列を表現したヒートマップもしくはグラフ等の形で提示する。これによって、本実施の形態に係る表示制御装置１０によれば、１ステップ以上先の次操作候補についてリアルタイムかつ直観的にユーザに提示することができる。さらに、本実施の形態に係る表示制御装置１０によれば、ヒートマップへの視覚変数の割り当てを工夫することによって、ユーザは、操作手順や時系列、重要度等を把握しながら、操作全体の「文脈」を読み取ることができる。具体的には、本実施の形態に係る表示制御装置１０では、習熟度やキーとなる操作かどうかによって算出される重要度によって、ノードの彩度などの視覚変数を調整するため、ユーザの操作全体の「文脈」の読み取りを支援することができる。

さらに、本実施の形態に係る表示制御装置１０では、対象となるアプリケーションウィンドウ上に重ねた透明ウィンドウ上に次操作候補要素を描画する。すなわち、表示制御装置１０は、次操作候補要素の描画処理をアプリケーションに新たに組み込むのではない。表示制御装置１０は、透明ウィンドウを、アプリケーションのアプリケーションウィンドウに重ねて、透明ウィンドウ上に、１ステップ以上先の次操作候補要素を表示するだけである。したがって、表示制御装置１０によれば、アプリケーションに依存せず次操作候補要素の描画が適用可能であり、システム改修のコストがかからない。そして、表示制御装置１０によれば、対象のアプリケーションを限定せず、複数ウィンドウに対しても適用可能である。

そして、本実施の形態に係る表示制御装置は、アプリケーションウィンドウ上に透明ウィンドウを重畳表示し、次操作候補要素を表示させるため、表示可能な画面領域が限られている場合であっても、操作手順や時系列等の不足なく、操作の流れに沿った効率的なナビゲーションを実現できる。

したがって、本実施の形態に係る表示制御装置１０によれば、アプリケーション自体への作り込みを不要としながら、操作手順や時系列等の不足なく操作全体のリコメンドを表示できる。

実際に、表示制御装置１０の制御によって表示される次操作候補要素の表示例について説明する。まず、実施例１について説明する。実施例１では、表示制御装置１０は、次操作候補要素として時系列を表現したヒートマップ画像を表示する。

すなわち、表示制御装置１０が、ユーザに入力支援が必要なＧＵＩ要素に対して操作を行った際に１ステップ以上先の操作候補となる画面上のＧＵＩ要素にヒートマップ画像を重畳表示する。このとき、ヒートマップの表現として、例えば大きさで頻度を表し、色相で操作順を表し、彩度で重要度を表すことによって、同一画面上に複数の次操作候補要素が提示された場合においても、ユーザがそれぞれの次操作候補の時系列変化を把握可能になる。ここでいう重要度とはユーザの熟練度等を指し、具体的には、ユーザ全体の操作の集計値よりも、予め設定したベテランの操作列の重要度を高く設定する等をいう。

まず、図８を参照して、彩度で重要度を表したヒートマップの表示例について説明する。図８は、図１に示す表示制御装置１０の表示制御処理を説明する図である。図８の（ａ）の左方には、表示装置３０に表示されるアプリケーションウィンドウＭ１を示す。図８の（ａ）の右方には、表示制御装置１０が生成する透明ウィンドウＴ１及び次操作候補要素を示す。図８の（ｂ）は、表示装置３０に表示される画面の一例を示す図である。

図８の例では、彩度で重要度を表したヒートマップを表示する。例えば、図８の（ａ）の左方に示す業務システムのアプリケーションウィンドウＭ１への入力作業の際、多くのユーザは全項目に順番に入力を行い、熟練ユーザはＩＤを入力して直接検索を行っているとする。

この場合、表示制御部１４３は、「ネットワーク情報を入力する『作業』」という「文脈」における次操作候補を提示したヒートマップＨ１，Ｈ２を、対応する入力欄の位置に合わせて表示した透明ウィンドウＴ１を生成する（図８の（ａ）の右方参照）。なお、ヒートマップＨ１は、一例として、カラーコードが「＃ｆｆ００００」（高彩度）であり、ヒートマップＨ２は、一例として、カラーコードが「＃６６３ｄ３ｄ」（低彩度）である。そして、表示制御部１４３は、生成した透明ウィンドウＴ１を、アプリケーションウィンドウＭ１に重畳し、さらに、彩度の高さで重要度を区別できるように示した各ヒートマップＨ１，Ｈ２を表示装置３０に表示させる。この結果、図８の（ｂ）に示すように、表示装置３０には、アプリケーションウィンドウＭ１上に１ステップ以上先の次操作候補を示すヒートマップＨ１，Ｈ２が表示される。この場合、表示制御部１４３は、図８の（ｂ）のように、ヒートマップの大きさによってユーザ操作の頻度を示し、彩度の高さで習熟度の高さを示すことによって、前述のような習熟度による操作の違いを表現することが可能である。

なお、パラメータと視覚変数との組み合わせはこの限りではなく、他の視覚変数を用いてもよい。ヒートマップの表示位置については、先行特許文献１記載のＰｏｔｅｎｔｉａｌ Ｐｏｉｎｔｓの算出と同様に行う。

次に、図９を参照して、色相で操作順を表したヒートマップの表示例について説明する。図９は、図１に示す表示制御装置１０の表示制御処理を説明する図である。図９では、プルダウン表示や新規ウィンドウなど、ユーザの操作時点で非表示になっているＧＵＩ要素に対し、ユーザの操作に応じてヒートマップを動的に提示する場合を示す。このとき、複数ステップを同時に提示する場合は、色相で操作順を表現することも可能である。図９の例では、操作開始から現在に渡る操作順を、青、青紫、紫、赤紫、赤の順で表現する（図９の（ｃ）の凡例参照）。

例えば、図９の（ａ）の設備構築メニューＭ３ａの項目のうち、「工事管理」が１ステップ先の次操作候補になっている。そして、この「工事管理」項目への操作に伴い表示されるプルダウンメニュー内に２ステップ以上先の次操作候補が存在するとする。ここで、現在のユーザ操作をｉ番目とする。そして、図９の（ａ）はｉ番目の操作状態を示し、図９の（ｂ）は（ｉ＋１）番目の操作状態を示し、図９の（ｃ）は（ｉ＋２）番目の操作状態を示す。

まず、設備構築メニューＭ３ａの項目「工事管理」上に（ｉ＋１）番目の操作候補であることを示すヒートマップＨ３ａ（色相：青）が表示される（図９の（ａ）参照）。このとき、表示制御部１４３は、表示装置３０に、透明ウィンドウＴ３ａを、設備構築メニューＭ３ａ上に重畳表示し、この青のヒートマップＨ３ａを描画する。

そして、設備構築メニューＭ３ｂのうち、ユーザが「工事管理」にマウスカーソルＣを当てると、展開されたプルダウンメニューのうち「自工事選択」上に、（ｉ＋２）番目の操作候補であることを示すヒートマップＨ３ｂ（色相：紫）が表示される（図９の（ｂ）参照）。このとき、表示制御部１４３は、表示装置３０に、透明ウィンドウＴ３ｂを、設備構築メニューＭ３ｂ上に重畳表示し、ヒートマップＨ３ｂを描画する。

続いて、設備操作メニューＭ３ｃのうち、ユーザが「自工事選択」にマウスカーソルＣを当てることにより展開する「リスト選択」メニュー上に、（ｉ＋３）番目の操作候補であることを示すヒートマップＨ３ｃ（色相：赤）が表示される（図９の（ｃ）参照）。このとき、表示制御部１４３は、表示装置３０に、透明ウィンドウＴ３ｃを、設備操作メニューＭ３ｃ上に重畳表示し、青のヒートマップＨ３ａ及び紫のヒートマップＨ３ｂとともに、この赤のヒートマップＨ３ｃを描画する。なお、図９の（ａ）〜（ｃ）では、透明ウィンドウＴ３ｃの下方に凡例を示す例を示したが、この凡例は、必ずしも透明ウィンドウ上に表示してもしなくてもよい。

また、表示制御装置１０は、色相を、操作順で割り当てる代わりに、一連の「作業」の操作開始時刻からの経過時間に割り当てることもできる。この場合、ユーザは、経過時間に相当する色相のヒートマップを確認することによって、一連の操作内で滞留が発生している操作を把握可能になる。なお、同時に表示するステップ数や候補数は設定により変更可能であり、システムに不慣れなユーザにはベテランの理想的な操作候補のみ提示し、システムに慣れたユーザには複数の候補を提示する等、柔軟な表示が可能である。

本実施例１のように、表示制御装置１０は、複数ステップの次操作候補要素を同時に表示することによって、ユーザは、直近の操作履歴と併せて現在の次操作候補を把握することができる。このため、非特許文献１記載の方法のように１ステップ先の次操作が短時間で提示され、それにしたがって各ステップの操作を行う方法と比して、実施例１の方が、操作の流れの習得が容易になる。

次に、実施例２について説明する。実施例２では、表示制御装置１０は、実施例１のようにＧＵＩ要素上に大きさを反映したヒートマップを重ねる代わりに、ＧＵＩ要素全体をハイライト表示する。

まず、表示制御装置１０は、画面構造をＷｉｎｄｏｗｓ ＡＰＩで取得する。続いて、表示制御部１４３は、透明ウィンドウをアプリケーションウィンドウに重畳表示し、ＧＵＩ要素全体を覆う矩形のヒートマップを表示させる。矩形のヒートマップは、例えば色相で操作順を示し、彩度で頻度を示す。そして、次操作候補として、ベテランのデータを表示するか、或いは、全ユーザのデータを表示するかは、ユーザが切り替え可能である。図１０の例では、図９と同様に、操作開始から現在に渡る操作順を、青、青紫、紫、赤紫、赤の順で表現する。そして、彩度が強くなると頻度が高いことを示す。

図１０は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。図１０の設備構築メニューＭ４は、図９に示す設備構築メニューに相当する。図９では、円形のヒートマップで表現されていた次操作候補要素が、図１０では、ＧＵＩ要素を覆う矩形のヒートマップに置き換えられる。

具体的には、設備備操作メニューＭ４のうち、ユーザが「自工事選択」にマウスカーソルＣを当てると、矩形のヒートマップＨ４ａ（色相：紫）が表示される。そして、展開されたプルダウンメニューのうち「リスト選択」メニュー上に、次操作候補であることを示す矩形のヒートマップＨ４ｂ（色相:赤）が表示される（図１０参照）。これによって、次操作候補であるＧＵＩ要素全体が赤のハイライトで表示される。このとき、表示制御部１４３は、透明ウィンドウＴ４を設備操作メニューＭ４上に重畳表示させ、透明ウィンドウＴ４上にヒートマップＨ４ａ，Ｈ４ｂを表示させ、表示装置３０に出力する。

次に、実施例３について説明する。実施例３では、表示制御装置１０は、複数ウィンドウを併用する場合に、透明ウィンドウを複数ウィンドウに重畳表示させて、これら複数の透明ウィンドウ上に次操作候補要素を表示する。図１１、図１３及び図１４は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。図１２及び図１５は、図１に示す可視化ルールの一例を示す図である。

図１１〜図１５を参照し、同一オーダに対して顧客情報や工事情報など複数の帳票（アプリケーションウィンドウ）が存在し、単一の業務システム画面上の入力欄に帳票の内容を転記する事例について説明する。この事例では、システム上の入力対象と各帳票上の入力項目との対応を取りながら、適切な項目に転記する必要がある。ここで、入力対象のシステムの作りが複雑な場合または帳票上に含まれる情報が多岐にわたる場合、業務に不慣れなユーザにとっては対応が取りづらいことが考えられる。このような複数のアプリケーションウィンドウでの操作の場合も、表示制御装置１０は、実施例１，２と同様、各アプリケーションウィンドウにわたる操作の順序に応じた色相を割り当ててヒートマップを動的に表示することによって、操作の流れを把握しながら、次操作候補を提示可能である。

図１１は、それぞれ「顧客情報の入力（『作業Ａ』）」「設備情報の入力（『作業Ｂ』）」という各「作業」ごとに色相を割り当てた場合のヒートマップ表示画面例である。また、図１１に示すヒートマップ表示は、図１２に示す可視化ルール１３４ａに基づいて行われる。なお、この例では、知識ＤＢ１３１がリレーショナルデータベースで実装されているとし、可視化ルールは「文脈」をプライマリーキーとして登録されており、最長一致で検索を行うものとする。

図１１及び図１２を参照して、表示制御装置１０において、判定部１４２は、「文脈」として「作業Ａ」（文脈１）と「作業Ｂ」（文脈２）とを指定した場合について説明する。この場合、判定部１４２は、図１２に示す可視化ルール１３４ａの「作業Ａ」に応じた可視化パラメータ（図１２の行Ｒ１参照）、対応ルール、割り当てルール、及び、「作業Ｂ」に応じた可視化パラメータ（図１２の行Ｒ３参照）、対応ルール、割り当てルールを取得する。具体的には、「作業Ａ」（文脈１）の可視化ルールは、ヒートマップで表示し、大きさで頻度を表し、色相が「Ｂｌｕｅ（青系列）」であり、明度で操作順を表し、３ステップ先までの操作候補を示すルールである。また、「作業Ｂ」（文脈２）の可視化ルールは、ヒートマップで表示し、大きさで頻度を表し、色相が「Ｒｅｄ（赤系列）」であり、明度で操作順を表し、３ステップ先までの操作候補を示すルールである。また、図１１の例では、明度には、操作開始から現在に渡ってレベル１〜３が対応付けられている。

表示制御部１４３は、「作業Ａ」の３ステップ先までの次操作候補を提示した青系列のヒートマップＨ５１〜Ｈ５３を、対応する操作メニューＭ５ａ，Ｍ５ｂの入力欄の位置に合わせて生成する。なお、ヒートマップのＨ５１〜Ｈ５３の明度は、順に、レベル１、レベル２、レベル３である。このため、「作業Ａ」については、ヒートマップＨ５１〜５３の順で操作するよう３ステップ先までの次操作候補が示される。そして、表示制御部１４３は、「作業Ｂ」の３ステップ先までの次操作候補を提示した赤系列のヒートマップＨ５４〜Ｈ５６を、対応する操作メニューＭ５ａ，Ｍ５ｃの入力欄の位置に合わせて生成する。なお、ヒートマップのＨ５４〜Ｈ５６の明度は、順に、レベル１、レベル２、レベル３である。このため、「作業Ｂ」については、ヒートマップＨ５４〜５６の順で操作するよう３ステップ先までの次操作候補が示される。そして、表示制御部１４３は、透明ウィンドウＴ５を生成する。この透明ウィンドウＴ５は、複数のアプリケーションウィンドウＭ５ａ〜Ｍ５ｃの全てを覆う大きさである。そして、表示制御部１４３は、生成した透明ウィンドウＴ５を、アプリケーションウィンドウＭ５ａ〜Ｍ５ｃに重畳表示し、この透明ウィンドウＴ５上に生成したヒートマップＨ５１〜Ｈ５６を表示装置３０に表示させる。この結果、図１１に示すように、表示装置３０には、複数のアプリケーションウィンドウＭ５ａ〜Ｍ５ｃ上に作業Ａ，Ｂのそれぞれに対する３ステップ先の次操作候補を示すヒートマップＨ５１〜５６が表示される。

このように、表示制御装置１０は、複数のアプリケーションウィンドウに対するユーザの操作イベントを含むイベント列に合致する文脈に対応した可視化パラメータ、対応ルール及び割り当てルールを基に、１ステップ以上先の次操作候補を色ないしはグラフ等で示した次操作候補要素を生成する。そして、表示制御装置１０は、複数のアプリケーションウィンドウ上に重畳表示した透明ウィンドウ上に生成した次操作候補要素を表示し、ユーザに提示する。すなわち、本実施の形態に係る表示制御装置１０は、アプリケーションウィンドウ上に透明ウィンドウを重ねることで、対象のアプリケーションを限定せず、複数ウィンドウに対しても適用可能である。

さらに、実施の形態に係る表示制御装置１０は、ヒートマップへの視覚変数の割り当てを工夫することによって、ユーザは、複数ウィンドウに対する操作であっても操作順を直観的に把握することができる。すなわち、このように複数の作業に対して複数ステップを同時に提示した場合であっても、作業ごとにそれぞれ区別可能となるようにヒートマップへの視覚変数を割り当てているため、ユーザが提示された情報の中から操作対象の部分を探すことも容易となり、操作順を短時間で把握することができる。

なお、表示制御部１４３は、複数のアプリケーションウィンドウＭ５ａ〜Ｍ５ｃの全てを覆う大きさの透明ウィンドウＴ５を生成したが、もちろん、これに限らない。表示制御部１４３は、図１３に示すように、複数のアプリケーションウィンドウＭ５ａ〜Ｍ５ｃごとに、透明ウィンドウＴ５１〜Ｔ５３を生成する。そして、表示制御部１４３は、各アプリケーションウィンドウＭ５ａ〜Ｍ５ｃに、それぞれ対応する透明ウィンドウＴ５１〜Ｔ５３を重畳して、表示装置３０に表示させる。そして、表示制御部１４３は、透明ウィンドウＴ５１〜Ｔ５３上に、作業Ａ，Ｂのそれぞれに対する３ステップ先の次操作候補を示すヒートマップＨ５１〜５６を表示させる。

次に、図１４及び図１５を参照して、ＧＵＩ要素に対する時系列の操作ごとに色相を割り当ててヒートマップを表示させた例を説明する。この場合、表示制御装置１０において、判定部１４２は、「文脈」として、「業務Ａ，時系列」を指定した場合について説明する。この場合、判定部１４２は、図１５に示す可視化ルール１３４ｂの「作業Ａ，時系列」に応じた可視化パラメータ（図１５の行Ｒ１’参照）、対応ルール及び割り当てルールを取得する。具体的には、「作業Ａ，時系列」の可視化ルールは、ヒートマップで表示し、大きさで頻度を表し、時系列を色相で表し、６ステップ先までの操作候補を示すルールである。図１４の例では、操作開始から現在に渡る操作順を、青、薄青、緑、黄色、橙、赤の順で表現する。

表示制御部１４３は、「作業Ａ，時系列」の６ステップ先までの次操作候補を提示したヒートマップＨ６１〜Ｈ６６を、対応するアプリケーションウィンドウＭ６ａ〜Ｍ６ｃの入力欄の位置に合わせて生成する。ヒートマップＨ６１〜Ｈ６６は、順に、青、薄青、緑、黄色、橙、赤である。そして、表示制御部１４３は、生成した透明ウィンドウＴ６を、アプリケーションウィンドウＭ６ａ〜Ｍ６ｃに重畳する。続いて、表示制御部１４３は、表示装置３０に、生成したヒートマップＨ６１〜Ｈ６６を透明ウィンドウＴ６上に表示させる。この結果、図１４に示すように、表示装置３０には、複数のアプリケーションウィンドウＭ６ａ〜Ｍ６ｃ上に、作業Ａの６ステップ先までの次操作候補であって、操作順序にそれぞれ対応する色相で示されたヒートマップＨ６１〜Ｈ６６が表示される。この結果、ユーザは、これらのヒートマップを確認することによって、作業Ａの時系列を把握することができる。

次に、実施例４について説明する。実施例４では、表示制御装置１０が、次操作候補要素として、ノード及びノード間のリンクで時系列を表現したグラフ画像を表示する。図１６Ａ及び図１６Ｂは、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。実施例３と同様に、グラフ画像は、大きさで頻度を示し、彩度で重要度を示す。

図１６Ａは、ノードＮ７１〜Ｎ７４・リンク（一方のノードから他方のノードを示す矢印）とも単色（例えば、赤系列）の有向グラフＧ７ａで示し、ノードの矢印によって操作順序を示した場合を示す。この場合、表示制御部１４３は、図１６Ａに示すように、透明ウィンドウＴ７ａを生成してアプリケーションウィンドウＭ７ａに重畳し、表示装置３０に、ノードの矢印によって操作順序を示した有向グラフＧ７ａを透明ウィンドウＴ７ａ上に表示させる。

また、図１６Ｂは、ノードの色相、及び、リンクの配色を、ノードの両端の色のグラデーションで表現することによって操作順序を表現した例を示す。この場合、表示制御部１４３は、図１６Ｂに示すように、透明ウィンドウＴ７ｂを生成してアプリケーションウィンドウＭ７ｂに重畳し、ノードの両端の色のグラデーションで操作順序を示した有向グラフＧ７ｂを表示装置３０に表示させる。図１６Ｂの例では、操作開始から現在に渡る操作順を、青、薄青、緑、黄の順で表現する。有向グラフＧ７ｂは、ノードＮ７５（青）、ノードＮ７６（薄青）、ノードＮ７７（緑）、ノードＮ７８（黄）と、リンク（一方のノードから他方のノードを示す矢印であってノードの両端の色のグラデーションで示される。）を有する。ユーザは、表示装置３０の画面上のこれらのグラフＧ７ａ，Ｇ７ｂを確認することによって、操作手順や時系列等の不足なく所定数のステップの操作を把握することができる。なお、ノード・リンクの表現は、もちろん、図１６Ａ及び図１６Ｂに示す例に限らない。

次に、図１７及び図１８を参照して、次操作候補に複数の「文脈」が考えられる場合の表示例について説明する。図１７及び図１８は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。

図１７は、次操作候補に複数の「文脈」が考えられる場合の表示例を示す。図１７に示すように、例えば「文脈」ごとに色相を割り当て、各々の操作順を明度で表現することにより、複数の「文脈」を同時に表現することが考えられる。具体的には、表示制御部１４３は、可視化ルールに従って、「文脈１」に赤系列の色相を割り当て、「文脈２」に青系列の色相を割り当てる。そして、文脈１，２ともに、明度で操作順を表す。明度には、操作開始から現在に渡ってレベル１〜５が対応付けられている。具体的には、表示制御部１４３は、「文脈１」に対する次操作候補要素として、ノードの矢印によって操作順序を示した赤系列の有向グラフＧ８１を生成する。有向グラフＧ８１は、赤系列のノードＮ８１〜Ｎ８５を有し、各ノードＮ８１〜Ｎ８５の明度は、順に、レベル１、レベル２、レベル３、レベル４、レベル５である。また、有向グラフＧ８１のリンクは、ノードの両端の明度のグラデーションで示される。表示制御部１４３は、「文脈２」に対する次操作候補要素として、ノードの矢印によって操作順序を示した青系列の有向グラフＧ８２を生成する。そして、有向グラフＧ８２は、青系列のノードＮ８６〜Ｎ８８を有し、各ノードＮ８１〜Ｎ８８の明度は、順に、レベル１、レベル２、レベル３である。また、有向グラフＧ８２のリンクは、ノードの両端の色及び明度のグラデーションで示される。続いて、表示制御部１４３は、ウィンドウＴ８を生成してアプリケーションウィンドウＭ８上に透明ウィンドウＴ８を重畳し、生成した有向グラフＧ８１，Ｇ８２を表示させる。

また、図１８の左図のように、「文脈１」，「文脈２」のそれぞれの始点・終点のノードＮ９１，Ｎ９２，Ｎ９４，Ｎ９６のみ表現しておき、ユーザの操作に従って、図１８の右図のように、着目した「文脈」の操作候補のみグラフの形で表現することによって、煩雑さを回避することも可能である。すなわち、表示制御部１４３は、「文脈１」，「文脈２」のそれぞれの始点・終点のノードＮ９１，Ｎ９２，Ｎ９４，Ｎ９６のみを生成して、アプリケーションウィンドウＭ９ａ上に重畳表示させた透明ウィンドウＴ９ａ上に表示する（図１８の左図参照）。そして、ユーザが「文脈１」に着目した操作を行った場合には、表示制御部１４３は、この操作にしたがって、ユーザが着目した「文脈１」の操作候補のみを示すグラフＧ９３を生成する（図１８の右図参照）。有向グラフＧ９３は、赤系列のノードＮ９１，Ｎ９２及び青系列のノードＮ９３，Ｎ９５，Ｎ９６を、各ノードを、一方のノードから他方のノードを示す矢印であってノードの両端の色のグラデーションで示されるリンクで結ぶ。そして、表示制御部１４３は、生成した透明ウィンドウＴ９ｂをアプリケーションウィンドウＭ９ｂ上に重畳表示させ、透明ウィンドウＴ９ｂ上に有向グラフＧ９３を表示させる。

次に、実施例５について説明する。実施例５では、操作対象画面としてディスプレイ上に表示されていない部分に次操作候補が存在する場合の次操作候補表示方法について説明する。例えば、表示制御部１４３は、判定部１４２によって求められた可視化ルール及びパラメータを基に、画面の重なりが生じる複数ウィンドウに対し、次操作候補の領域の位置方向を示すグリフ画像を、次操作候補要素として表示装置３０に表示させる。

図１９は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。図１９に示すように、スクロールや画面の重なり等で次操作対象のＧＵＩ要素或いは操作対象画面が隠れている場合、表示制御部１４３は、現在操作中の画面上に矢印など画面の移動を促すグリフ画像Ｇ１０を重畳表示する。図１９の例では、グリフ画像Ｇ１０は、スクロール付き画面で非表示になっている部分に次操作候補があることを示す。このグリフ画像Ｇ１０を認識することによって、ユーザは、次操作候補が非表示になっている部分に存在することを直観的に読み取ることができる。

この場合、表示制御部１４３は、図１９に示すように、透明ウィンドウＴ１０を生成し、アプリケーションウィンドウＭ１０に透明ウィンドウＴ１０を重畳し、透明ウィンドウＴ１０上にグリフ画像Ｇ１０を表示した結果を示装置３０に表示させる。

また、表示制御部１４３は、次操作候補要素として、次操作候補の領域をハイライト表示した表示画面全体を示すマップ画像を、次操作候補要素として表示装置３０に表示させてもよい。

図２０は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。図２０に示すように、次操作対象のＧＵＩ要素或いは操作対象画面が隠れている場合、表示制御部１４３は、表示装置３０に、操作対象画面の端或いは操作対象画面外のディスプレイ上の空白部分に、表示画面全体のマップ画像Ｍ１１ａを表示させる。マップ画像Ｍ１１ａは、スクロールつきの画面全体もしくはディスプレイ上の操作対象画面群を俯瞰できる画像である。そして、マップ画像Ｍ１１ａは、次の操作候補となる部分Ｇ１１を他の部分とは異なる色を用いてハイライト表示したものである。

この場合、表示制御部１４３は、図２０に示すように、透明ウィンドウＴ１１を生成し、アプリケーションウィンドウＭ１１に透明ウィンドウＴ１１を重畳して、透明ウィンドウＴ１１上にマップ画像Ｍ１１ａを表示させる。

このように、表示制御装置１０は、画面どうしの重なりやスクロールつきの画面など、操作対象画面としてディスプレイ上に表示されていない部分に次操作候補部分が存在する場合であっても、グリフ画像Ｇ１０やマップ画像Ｍ１１ａを表示して、表示されていない部分に次操作候補部分が存在することを提示する。

また、図２１及び図２２は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。図２１は、ディスプレイ上に４つのアプリケーションウィンドウＭ１２１〜Ｍ１２４が表示されている場合の例である。

図２１は、例えば、「オーダ管理システム」ウィンドウＭ１２１の下に隠れているウィンドウＭ１２４上に次の操作候補が存在する場合を示す。この場合、表示制御部１４３は、操作対象画面の右端に、表示画面全体のマップ画像Ｍ１２ａを表示させる。そして、表示制御部１４３は、マップ画像Ｍ１２ａのうち、次の操作候補が存在するウィンドウＭ１２４に対応する部分Ｍ１２４ａを、「オーダ管理システム」ウィンドウＭ１２１に対応する部分Ｍ１２１ａの前面に表示させるとともに、赤くハイライト表示させる。

この場合、表示制御部１４３は、図２１に示すように、透明ウィンドウＴ１２を生成し、アプリケーションウィンドウＭ１２に透明ウィンドウＴ１２を重畳して、透明ウィンドウＴ１２上にマップ画像Ｍ１２ａを表示させる。

このように、表示制御装置１０では、画面どうしの重なり、スクロールつきの画面など、操作対象画面としてディスプレイ上に表示されていない部分に次操作候補が存在する場合であっても、グリフ画像や俯瞰用のマップ画像を表示することによって、ユーザは、次操作候補を認識することができる。

さらに、表示制御部１４３は、俯瞰用のマップ画像Ｍ１２ａを、次操作候補の提示が必要な場合のみポップアップ表示してもよい。また、表示制御部１４３は、次操作候補の提示が不要な場合には、図２２に示すように、マップ画像Ｍ１２ｂの不透明度を低くしてもよい。なお、表示制御部１４３は、次操作候補の提示が必要な場合には、図２１のように、マップ画像Ｍ１２ｂの不透明度を高く表示する。これらの工夫を施すことにより、ユーザが作業中であっても、次操作候補の領域変化を検知しやすくなる。

次に、実施例６について説明する。実施例６では、表示制御部１４３は、判定部１４２によって求められた可視化ルール及びパラメータを基に、次操作候補要素として、次操作候補を示す画像を含む仮想の新規ウィンドウ画像を、表示装置３０に表示させる。

図２３は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。例えば、表示制御部１４３が、図２３の「オーダ管理システム」ウィンドウＭ１３上に、１ステップ先の青のヒートマップＨ１３ａを表示している場合を例に説明する。この場合、表示制御部１４３は、表示されているＧＵＩ要素上でユーザがマウスオーバ操作をすると（図２３の（１）参照）、当該ＧＵＩ要素をクリックした際に展開する新規ウィンドウＭ１３１をディスプレイ上に仮想で表示する（図２３の（２）参照）。表示制御部１４３は、新規ウィンドウＭ１３１上に、さらに次のステップに対応したヒートマップＨ１３ｂ（赤）を重ねる。

この場合、表示制御部１４３は、図２３に示すように、透明ウィンドウＴ１３を生成し、アプリケーションウィンドウＭ１３に透明ウィンドウＴ１３を重畳して、透明ウィンドウＴ１３上にヒートマップＨ１３ｂを含む仮想の新規ウィンドウＭ１３１を、表示装置３０に表示させる。

複数ウィンドウへの適用を考えた場合、ディスプレイ上に現在表示されているウィンドウ以外に、ユーザ操作に従って表示される新規ウィンドウ上に次操作候補が存在することが想定される。この場合、表示制御部１４３は、図２３に示すように、ユーザが実際の操作を行わなくても、仮想のウィンドウ上に次操作候補を示すヒートマップを表示し、ユーザが数ステップ先の操作の流れを把握可能にする。言い換えると、表示制御装置１０は、実際に新規ウィンドウが展開される位置に仮想のウィンドウＭ１３１を表示することで、ディスプレイ上に複数の画面が表示されている場合でも、ユーザのメンタルマップを保つことが可能になる。

なお、図２３では、次操作候補要素としてヒートマップを適用しているが、次操作候補要素は他の表現方法あってもよい。

図２４は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。図２４では、図２３で示すシステムと同一システムにおいて、欄Ｌ１４に示すように「申込サービス」に複数の選択肢があり、各々その後展開する新規ウィンドウ上での入力に違いがある場合について説明する。

例えば、ユーザがオーダ管理システムウィンドウＭ１４の「申込サービス」にマウスカーソルＣを当てて、「申込サービス」のプルダウン部分Ｌ１４を展開する（図２４の（１）参照）。「申し込みサービス」には、「サービスＡ」と「サービスＢ」とがある。図２４では、「サービスＡ」についての次操作候補要素は、赤系列のヒートマップであり、操作順を明度で表現する。一方、「サービスＢ」についての次操作候補要路は、青系列のヒートマップであり、操作順を明度で表現する。サービスＡ，Ｂともに、明度には、操作開始から現在に渡ってレベル１〜３が対応付けられている。

図２４の例では、サービスＡ，Ｂの上には、それぞれの色で明度がレベル１のヒートマップＨ１４１ｅ，Ｈ１４１ｆが表示される。そして、ユーザによる「申込サービス」の展開に応じて、表示制御部１４３は、サービスＡ，サービスＢの１ステップ先の操作箇所である「工事情報入力画面」ボタン上にヒートマップＨ１４１ｇ，Ｈ１４１ｈを作成する。このヒートマップは、各サービスに対応する色及びレベル１の明度で示される。続いて、表示制御部１４３は、「工事情報入力画面」ボタンを選択した場合、各サービスＡ，Ｂの２ステップ以上先の次操作候補欄上に、ヒートマップＨ１４１ａ〜Ｈ１４１ｄを示した仮想の新規ウィンドウＭ１４１を作成する。

ヒートマップＨ１４１ａ，Ｈ１４１ｃは、サービスＡに対応し、赤で示され、明度は、順に、レベル２、レベル３である。ヒートマップＨ１４１ｂ，Ｈ１４１ｄは、サービスＢに対応し、青で示され、明度は、順に、レベル２、レベル３である。表示制御部１４３は、透明ウィンドウＴ１４をオーダ管理システムウィンドウＭ１４上に重畳表示させ、透明ウィンドウＴ１４上に、ヒートマップＨ１４１ａ〜Ｈ１４１ｄを示した仮想の新規ウィンドウＭ１４１を表示装置３０に表示させる（図２４の（２）参照）。これによって、ユーザは、遷移先の画面とプルダウンメニュー内の項目との紐づけが可能になり、操作手順を直観的に把握することができる。

ここでは、表示制御部１４３は、図２４に示すように、アプリケーションウィンドウＭ１４に透明ウィンドウＴ１４を重畳し、透明ウィンドウＴ１４上に、生成したヒートマップＨ１４１ａ〜Ｈ１４１ｄを含む仮想の新規ウィンドウＭ１４１を表示させる。

さらに、表示制御部１４３は、選択肢によって展開する新規ウィンドウ候補が複数ある場合、可視化パラメータ内の優先度によって表示する仮想の新規ウィンドウの不透明度を調節してもよい。この結果、表示制御装置１０が、表示装置３０に、複数の次操作候補を提示させた場合であっても、ユーザがいずれの操作が次に必要であるかを判断可能にすることもできる。なお、１ウィンドウに複数の文脈が存在する場合、優先度は最大値を採用したり、平均を取るなどすればよい。

また、表示制御部１４３は、仮想の新規ウィンドウの代わりに、仮想のサムネイルを表示し、サムネイル上に操作内容をヒートマップ表示してもよい。図２５は、図１に示す表示制御装置１０の表示制御処理の結果を示す画面の一例を示す図である。

例えば、ユーザが「申込サービス」にマウスカーソルＣを当てて、「申込サービス」のプルダウン部分（欄Ｌ１５）を展開する（図２５の（１）参照）。これに応じて、表示制御部１４３は、仮想のサムネイルＭ１５１ａ〜Ｍ１５１ｄを表示し（図２５の（２）参照）、サムネイルＭ１５１ａ〜Ｍ１５１ｄ上の次操作候補欄上にヒートマップＨ１５１ａ〜Ｈ１５１ｄを表示する。ヒートマップＨ１５１ａ，Ｈ１５１ｂ，Ｈ１５１ｂ´、サービスＡに対応し、赤で示され、明度は、順に、レベル１、レベル２、レベル３である。ヒートマップＨ１５１ｃ，Ｈ１５１ｄ，Ｈ１５１ｄ´は、サービスＢに対応し、青で示され、明度は、順に、レベル１、レベル２、レベル３である。したがって、仮想のサムネイルＭ１５１ａは、サービスＡを選択した場合の１ステップ先のアプリケーションウィンドウを示し、仮想のサムネイルＭ１５１ｂは、サービスＡを選択した場合の２ステップ先のアプリケーションウィンドウを示す。また、仮想のサムネイルＭ１５１ｃは、サービスＢを選択した場合の１ステップ先のアプリケーションウィンドウを示し、仮想のサムネイルＭ１５１ｄは、サービスＢを選択した場合の２ステップ先のアプリケーションウィンドウを示す。

ここでは、表示制御部１４３は、図２５に示すように、透明ウィンドウＴ１５を生成し、アプリケーションウィンドウＭ１５に透明ウィンドウＴ１５を重畳して、透明ウィンドウＴ１５上に、ヒートマップＨ１５１ａ〜Ｈ１５１ｄを示したサムネイルＭ１５１ａ〜Ｍ１５１ｄを表示させる。

なお、この場合、表示制御部１４３は、検知部１４１によって検知されたイベント列に合致する文脈に対応した優先順位に従ってサムネイルＭ１５１ａ〜Ｍ１５１ｄの不透明度を調整してもよい。このような工夫を施すことによって、ユーザが作業中であっても、次操作候補の領域変化を検知しやすくなる。すなわち、表示制御部１４３は、可視化パラメータ内の優先度によって、表示する仮想のウィンドウの不透明度を調節することで、複数の次操作候補要素を提示した場合でも、ユーザが次操作候補の優先度を判断できるようにする。なお、優先度の計算は最終的に遷移する先のウィンドウに対して計算すればよい。

このように、表示制御装置１０が、新規の仮想ウィンドウや仮想のサムネイルによる先読み機能を追加することによって、ユーザは、次操作候補を円滑に認識することができる。

［実施の形態のシステム構成について］
図１に示した表示制御装置１０の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、表示制御装置１０の機能の分散及び統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散または統合して構成することができる。

また、表示制御装置１０においておこなわれる各処理は、全部または任意の一部が、ＣＰＵ、ＧＰＵ（Graphics Processing Unit）、及び、ＣＰＵ、ＧＰＵにより解析実行されるプログラムにて実現されてもよい。また、表示制御装置１０においておこなわれる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。

また、実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的に行うこともできる。もしくは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。

［プログラム］
図２６は、プログラムが実行されることにより、表示制御装置１０が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、表示制御装置１０の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、表示制御装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤにより代替されてもよい。

また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等は全て本発明の範疇に含まれる。

１０ 表示制御装置
１１ ＯＳ
１２ アプリケーション
１３ 記憶部
１４ 次操作候補要素表示制御部
１５ 可視化アプリケーション
２０ 入力装置
３０ 表示装置
１００ 制御部
１３１ 知識ＤＢ
１３２ ログデータ
１３３ 文脈データ
１３４ 可視化ルールデータ
１４１ 検知部
１４２ 判定部
１４３ 表示制御部

Claims (8)

1. 表示装置の表示処理を制御する表示制御装置であって、
   制御対象となるアプリケーションに対する操作イベント或いはシステムイベントに対応して設定された１ステップ以上先の操作手順を示す次操作候補要素を生成し、表示するための可視化ルールを複数記憶する記憶部と、
   制御対象となるアプリケーションに対する操作イベント或いはシステムイベントを検知する検知部と、
   制御対象のアプリケーションウィンドウ上に透明ウィンドウを生成かつ重畳表示し、前記記憶部が記憶する複数の可視化ルールのうち前記検知部によって検知されたイベント列に対応する可視化ルールを基に前記次操作候補要素を生成し、該生成した前記次操作候補要素を前記透明ウィンドウ上に表示させる表示制御部と、
   を有することを特徴とする表示制御装置。
2. 前記記憶部は、一以上のイベントであるイベント列からイベント列の状態遷移で示される作業と該作業の状態遷移で示される業務とを導出したものである文脈と、該文脈に対応付けられた頻度及び重要度を含む文脈データを記憶し、
   前記可視化ルールは、前記文脈ごとに、前記次操作候補要素の可視化方法、前記次操作候補要素に対する視覚変数、提示ステップ数及び優先度を示す各パラメータが対応付けられた可視化パラメータ、前記文脈、前記文脈に対応する頻度及び重要度と前記パラメータとの対応ルール、及び、前記文脈における前記作業、前記頻度或いは前記重要度に応じて設定された前記視覚変数の割り当てルールであり、
   前記表示制御部は、前記記憶部が記憶する複数の可視化ルールのうち、前記検知部によって検知されたイベント列に合致する文脈に対応した可視化パラメータ、前記対応ルール及び前記割り当てルールを基に生成した前記次操作候補要素を表示することを特徴とする請求項１に記載の表示制御装置。
3. 前記表示制御部は、前記次操作候補要素として、時系列を表現したヒートマップ画像或いはグラフ画像のいずれかを表示し、
   前記ヒートマップ画像及び前記グラフ画像は、習熟度やキーとなる操作かどうかによって算出される重要度によって、ノードの彩度などの視覚変数が調整されることを特徴とする請求項２に記載の表示制御装置。
4. 前記表示装置は、前記アプリケーションウィンドウを複数表示し、
   前記表示制御部は、複数の前記アプリケーションウィンドウの全てを覆う大きさの透明ウィンドウを生成し、または、複数の前記アプリケーションウィンドウごとに前記透明ウィンドウを生成することを特徴とする請求項１〜３のいずれか一つに記載の表示制御装置。
5. 前記表示制御部は、前記表示装置に複数の前記アプリケーションウィンドウが重畳して表示されている場合、前記次操作候補要素として、次操作候補の領域の位置方向を示すグリフ画像、前記次操作候補の領域をハイライト表示した表示画面全体を示すマップ画像、次操作候補を示す画像を含む仮想の新規ウィンドウ画像のいずれかを表示することを特徴とする請求項４に記載の表示制御装置。
6. 前記表示制御部は、前記検知部によって検知されたイベント列に合致する文脈に対応した優先度に応じて、前記仮想の新規ウィンドウ画像の不透明度を調整することを特徴とする請求項５に記載の表示制御装置。
7. 表示装置の表示処理を制御する表示制御装置が実行する表示制御方法であって、
   前記表示制御装置は、制御対象となるアプリケーションに対する操作イベント或いはシステムイベントに対応して設定された１ステップ以上先の操作手順を示す次操作候補要素を生成し、表示するための可視化ルールを複数記憶する記憶部を有し、
   前記表示制御装置のアプリケーションに対する操作イベント或いはシステムイベントを検知する検知工程と、
   制御対象のアプリケーションウィンドウ上に透明ウィンドウを生成かつ重畳表示し、前記記憶部が記憶する複数の可視化ルールのうち前記検知部によって検知されたイベント列に対応する可視化ルールを基に前記次操作候補要素を生成し、該生成した前記次操作候補要素を前記透明ウィンドウ上に表示させる表示制御工程と、
   を含んだことを特徴とする表示制御方法。
8. コンピュータを、請求項１〜６のいずれか一つに記載の表示制御装置として機能させるための表示制御プログラム。

Images