(57)【要約】【課題】コンピュータの表示画面の変化を、検知漏れなく且つ少ない負荷で検知可能とすること。【解決手段】スキャンラインパターン生成部２１により表示画面のＸ方向またはＹ方向またはその両方に所定間隔で配置したスキャンラインの組み合わせからなるスキャンラインパターンを生成し、キャプチャ処理部２２によりスキャンラインごとに画面上の帯状の矩形の画像をキャプチャし、キャプチャ結果蓄積部２３にキャプチャした画像のデータを蓄積し、スキャンライン差異比較部２４により以前に蓄積した結果と最新の結果との差異を比較して画面変化の開始または継続または終了を検知し、画面変化通知部２５により外部へ向けて通知する。【選択図】図１１
2014167711.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータの表示画面の変化を検知する装置であって、
表示画面のＸ方向またはＹ方向またはその両方に所定の間隔を空けて指定したスキャンラインの組み合わせによりパターンを生成するスキャンラインパターン生成部と、
スキャンラインごとに画面上の帯状の矩形の画像をキャプチャするキャプチャ処理部と、
キャプチャした画像のデータを蓄積するキャプチャ結果蓄積部と、
以前の周期で蓄積した結果と最新の結果との差異を比較するスキャンライン差異比較部と、
画面変化の開始または継続または終了を外部へ向けて通知する画面変化通知部とを少なくとも備えた
ことを特徴とする画面変化検知装置。
【請求項２】
請求項１に記載の画面変化検知装置において、
スキャンラインパターン生成部が、分解能の異なる複数のスキャンラインを重畳したパターンを、キャプチャ周期の所定のタイミングで生成する
ことを特徴とする画面変化検知装置。
【請求項３】
請求項１または２に記載の画面変化検知装置において、
スキャンラインパターン生成部が、高分解能のパターンのスキャンラインの集合を、キャプチャ周期内の各タイミングに分散配置する
ことを特徴とする画面変化検知装置。
【請求項４】
請求項１乃至３のいずれかに記載の画面変化検知装置において、
前記に加え、
画面変化通知部の通知内容を記憶し、現在の表示画面上の状態および／または外部環境の状態の組み合わせに応じて検知モードを変更し保持する検知モード制御部を備え、
スキャンラインパターン生成部で当該検知モードを参照し生成するパターンを変化させる
ことを特徴とする画面変化検知装置。
【請求項５】
請求項４に記載の画面変化検知装置において、
スキャンラインの幅を、設定によって所定の固定幅に増大する、または検知モード制御部およびスキャンラインパターン生成部によって実行時の状況に応じて動的に増大する
ことを特徴とする画面変化検知装置。
【請求項６】
コンピュータを、請求項１乃至５のいずれかに記載の画面変化検知装置の各部として機能させるためのプログラム。
【請求項７】
コンピュータの表示画面の変化を検知する方法であって、
スキャンラインパターン生成部により、表示画面のＸ方向またはＹ方向またはその両方に所定の間隔を空けて指定したスキャンラインの組み合わせによりパターンを生成する工程と、
キャプチャ処理部により、スキャンラインごとに画面上の帯状の矩形の画像をキャプチャする工程と、
キャプチャ結果蓄積部により、キャプチャした画像のデータを蓄積する工程と、
スキャンライン差異比較部により、以前の周期で蓄積した結果と最新の結果との差異を比較する工程と、
画面変化通知部により、画面変化の開始または継続または終了を外部へ向けて通知する工程とを少なくとも含む
ことを特徴とする画面変化検知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータの表示装置に表示された画面（表示画面）を短い時間間隔で定期的にキャプチャ（画像データ取得）し、最新の画像データとそれ以前の画像データとの間で内容に違いがあるかどうかによって、画面の変化を検知するための技術に関するものである。
【背景技術】
【０００２】
一般に、表示画面のキャプチャの時間間隔を５０ｍｓｅｃなどに設定することで、画面の変化を即時に検知することが可能である。また、表示画面の全領域をキャプチャすることにより、変化を漏れなく検出することが保証される。しかしながら、短周期かつ全領域で画像をキャプチャする処理は、処理能力が向上した現在のコンピュータ（ＰＣ）であっても、その負荷を無視できるほど軽くはない。本来の計算処理の負荷が重い場合は、ユーザ（オペレータ）がキャプチャの設定を変更し、検知精度を下げる必要がある。
【０００３】
一方で、検知の目的によっては、あえて検知精度を下げたい場合もある。
【０００４】
例えば、表示画面の全領域をキャプチャすると、テキスト編集の位置を表すカーソルの点滅表示、現在時刻表示、ネットワーク接続状態表示など、ユーザの操作に関係なく随時変化する領域が含まれる場合が多い。
【０００５】
また、例えば、短周期でキャプチャして最新の画像データとその直前の画像データだけで差異を比較すると、マウスのホバリングによってＧＵＩ要素の表示が変化（ボタンの上をポインタが移動するだけで、ハイライト表示されるなど）する状態が一瞬であっても検知されるため、単にマウスがＧＵＩ上を通過した程度でも画面の変化として逐一反応してしまう。
【０００６】
このように、本来、検知したい画面の変化とは関係ないものも含んだ検知が頻繁に行われる。ここでは実用上の目的に照らして検出を望まない、これらの画面状態の変化を「背景雑音的な画面変化」と呼ぶ。
【０００７】
これに対する従来技術として、小さい面積や短時間の変化を、変化検知の対象から外すために、所定の設定により閾値を与えてフィルタをかける対処が行われる。具体的には、面積に対しては、一旦、画面の全領域をキャプチャして変化領域を検出し、これに対してその面積や縦横の長さを算出し、閾値以下であれば無視するなど、また時間に対しては、比較画像の差異の持続時間を算出し、閾値以下であれば無視するなどであり、フィルタをかける必要が実用的に発生する。
【０００８】
また、負荷を抑制することと上記フィルタをかけることとを兼ねた対策として、画面変化の検知を実行する環境（ＰＣの性能やウィンドウシステム上で発生する背景雑音的な画面変化の内容）や目的（検知させたい画面変化の内容）に応じて、キャプチャする領域の範囲や時間間隔の長さをユーザが設定する手段を提供することも行われる。ユーザはこの手段を使って、所定の幅で設定値を変化させ、実際の画面と検知結果を観察しながら、設定値を決定する。
【０００９】
そのほかの検知方法としては、画面上にランダムもしくは所定のパターンでサンプリングピクセルを設定し、それらの画素値の変化を比較する方法が考えられる。
【００１０】
ＰＣの表示画面の画像データをオペレーティングシステム（ＯＳ）を介して取得し、そのデータを応用するソフトウェアが存在する。例えば、従来技術１（特許文献１参照）では、ＰＣの操作を自動的に実行するエージェント（ソフトウェア）が、自動実行の操作の合間の画像データを取得し、操作の対象となるウィンドウの位置や状態を知る手がかりとする。
【００１１】
この場合、ＰＣ上でのユーザの操作やアプリケーションプログラム（ＡＰ）のプロセスの実行と並行してリアルタイムに画像データを取得することが求められる。そして、ユーザが入力デバイス（マウス、キーボードなど）を通して発行する操作イベントや、ＡＰ自身がソフトウェア的に発行する内部イベントをもとにしたタイミングで取得することが考えられるが、後述する図１、図２に示すような問題が発生する。表示画面上の画像内容の変化の開始や完了を監視し、データ取得タイミングを検知できれば有用である。
【００１２】
またこれらエージェントの機能としてＰＣの表示画面の監視を行う場合、当該ＰＣのハードウェア的な構成変更や、ＯＳおよびデバイスドライバなどのソフトウェア構成上の低レベルの改造・変更、具体的にはＰＣのグラフィックボードを監視のための特別なものに差し替える、ＯＳのグラフィック処理に特別なパッチをあてる、特別なグラフィックスデバイスドライバをインストールする、ＯＳがＡＰに提供するランタイムライブラリを特別なものに差し替える等が必要かどうかは重要なポイントである。
【００１３】
これらの改造や変更が必要であれば、その導入費用や準備作業を必要とするというだけではなく、当該ＰＣ上での任意のＡＰ実行に必要なリソースに変更を与えることになり、ＰＣ、ＯＳ、ＡＰ等の提供元のサポート（バージョンアップや障害対応支援）を受けられなくなったり、エージェント導入前の状態に完全に戻すことが技術的に難しくなり、何らかの影響を残す場合があるなどの問題を生じる。
【００１４】
このように、画面変化の検知を実行するに際して、ＰＣ環境の改造や変更を必要としないことは、不特定の一般ユーザが所有するＰＣや既存の業務運用中の端末などに導入する観点では、必須の要件といえる。
【００１５】
画像の時系列変化を検知するために標本点を設定する手法（従来技術２：特許文献２参照）が存在する。そこではこの手法を基本として、検知対象が存在する画像領域に対し高密度に標本点を設定することで、検知精度を向上する工夫も行われている。
【００１６】
本発明が前提とする表示画面の主な変化は、ウィンドウシステムのデスクトップ上で発生する頻度の高い変化に相当し、標本点を高密度に配置しても検知することができない場合が多く存在する。デスクトップ上で発生する変化の主な事例は、
・フレームウィンドウに相当する矩形領域の出現、移動、変形、消滅
・フレームウィンドウのアクティブ時のハイライト色の表示
・ポップアップウィンドウに相当する矩形領域の出現、消滅
・スクロールビュー内部のイメージの上下左右のスクロール移動
・テキストの文字描画内容の変化
・テキスト選択によるハイライト色の表示
・テキスト入力待機のキャレットの点滅
・ＧＵＩ要素のアクション時のボタン押下など見た目の変化
・ＧＵＩ要素のフォーカス時のハイライト色の表示
・ＧＵＩ要素のマウスホバリング時のハイライト色の表示
などである。
【００１７】
これらは考え得る事例にすぎず、これらに限定されるものではない。例えば、フレームウィンドウ上に配置されるＧＵＩ要素（ボタン、テキストフィールド、タブパネル、スクロールパネルなど）の出現、消滅が動的に行われるＡＰも考えられる。さらに一般的ではないが、それらの移動や変形が行われるＡＰも稀に存在する。これらは、フレームウィンドウの出現、消滅並びに移動、変形と類似したイメージ変化になると考えられる。異なる特徴としては、ＧＵＩ要素同士はフレームウィンドウのように、相互の重なり合いがないため、均一の背景色の上に、たまたま描画要素が重なりなく存在する状況に相当するという違いになる。このように、個々の表示更新事象を全て列挙することはできないが、イメージの変化の特徴は、上記事例に含まれると考えられる。
【００１８】
なお、上記においてポップアップウィンドウとは、メニュー選択時に表示されるメニューウィンドウやサブメニューウィンドウ、コンボボックス選択時に表示されるリストウィンドウ、マウス右ボタン押下時に表示されるコンテキストメニューウィンドウ、などを総称している。また、ＧＵＩ要素とは、ボタン、テキストフィールド、タブパネル、スクロールパネル、メニューアイテム、ウィンドウそのものも含めて総称している。また、ウィンドウとはフレームウィンドウやポップアップウィンドウを総称している。
【００１９】
これら変化の事例において、標本点を用いる方法では検知できない場合を以下に列挙する。
【００２０】
・例えば、フレームの幅が小さく（フレームウィンドウの境界部分として描画される帯状のイメージが幅方向に占めるピクセル数が少なく）、標本点に重ならない場合は検知できない。特に、ウィンドウ内部のイメージが変化せず、フレーム部分だけのイメージが変化するケース（ウィンドウがアクティブ時のハイライト表示になった場合など）では、ウィンドウ全体の占有領域が標本点に重なっていても、変化を検知できない場合が発生し得る。
【００２１】
・例えば、スクロールパネル内のテキストエリアに文字がまばらに存在する場合、スクロール移動した前後で、標本点が全て背景に位置していて、偶然にも検知できない場合が発生し得る。
【００２２】
・例えば、横書き文字列の高さが小さく、標本点に重ならない場合は検知できない。
【００２３】
・例えば、ＧＵＩ要素の矩形領域が小さく、標本点に重ならない場合は検知できない。
【００２４】
・例えば、キャレットが小さく、標本点に重ならない場合は検知できない。
【００２５】
標本点の間隔を狭くしても、これらのケースが発生する最悪の場合の確率を抑えることはできない。これは、極端に縦長もしくは横長の矩形に対しては、対象の位置によって標本点に重ならない場合があり、検知できるかどうかが実行時の状況に依存するためである。
【００２６】
本発明のスキャンラインは縦横の組み合わせからなる格子状のパターンであるため、このような検知対象の位置への依存性が小さく、間隔を狭くすると効果的に検知感度を向上できる。また、格子の１マスの縦横の長さが、確実に検知できる変化矩形の最小サイズに相当するため、検知を保証できる対象の条件が明確・簡潔に与えられる。これは、従来技術２のような自然界の対象物のイメージではなく、本発明がデスクトップ上のＧＵＩ要素のイメージに由来する画像特徴を利用していることによる。
【００２７】
また、カメラ画像を監視し、差異を検出する手段において、「サンプリング画像と基準画像とを比較して当該サンプリング画像と基準画像とが互いに異なる状態が検出された後、所定時間以上、サンプリング画像が同じである状態が継続した場合に撮像手段を異常動作状態と判断する異常検出手段」並びに「撮像手段により撮像された監視対象の画像のうちの一部を部分画像として抽出する部分画像抽出手段をさらに備え、基準画像記録手段が監視対象に異常がない状態において、部分画像抽出手段により抽出された部分画像を基準画像として記録するものであり、画像取得手段も監視対象について、部分画像抽出手段により抽出された部分画像をサンプリング画像として取得するもの」が存在する（従来技術３：特許文献３参照）。
【００２８】
本発明では、時系列上の直近とその前の画像の比較により差異が発見された場合、画面変化の開始と判定し、所定時間以上、画像が同じである状態が継続した場合、画像変化の終了と判定する、というように、判定の結果として上位モジュールに通知する状態が２種類存在する。また、監視対象を部分画像に分割してサンプリングする際のパターンが、タイル状の矩形領域ではなく、スキャンライン状の帯状領域の格子で構成する。これによって、縦長・横長の領域の変化を検知することができる。さらに、異なる分解能のパターンを重ね合せたものを動的に生成する。これによって計算負荷を軽減しながら画面全体をカバーできる。
【００２９】
「画像の取込み時間間隔をΔｔとしたときに、連続して取込んだそれぞれの画像に対して、ｎ×Δｔ（ｎ≧２、ｎは整数）離れた画像間で所定の演算を行うことにより、侵入物体の検知（変化領域の抽出）を行うことによって、侵入物体の検知性能が従来と変わらない一方で、速い時間間隔で侵入物体の検知結果が得られる」方法が存在する（従来技術４：特許文献４参照）。画像の取り込みと画像間の演算は、全てのタイミングで画像領域全体が対象となっている。ここでは速い時間間隔で検知結果が得られる状況を、検知の反応速度が高いと呼ぶこととする。
【００３０】
本発明では、１つのタイミングで対象とするのは全画像領域ではなく、その中の所定の部分であり、処理負荷を低く抑えることができる。また、検知性能について一律に速い時間間隔で検知結果を得ることはできないが、条件によって適応的に速い時間間隔で検知結果が得られる。この特徴は実用において重要である。理想的にいえば、検知の反応速度は、速い時間間隔であることが望ましいが、このために検知処理の負荷が大きくなってしまっては、当該ＰＣにおけるＡＰ処理に割り当てる能力を低下させることになり、本来の目的をはたせない。このため、性能に影響のない負荷の範囲で、大きい領域ほどできるだけ遅れの少ない検知ができ、小さい領域については検知の反応速度は多少犠牲にして、全体的な負荷を小さくできるほうが実用上重要である。
【００３１】
具体的には、ある分解能におけるスキャンラインパターンを取り上げて考えた場合、次のことが言える。パターンの中の１つのスキャンラインについて着目すると、その取り込みと画像間の演算は、１周期（１６分割の場合、１６×△ｔ）の間隔があいている。従ってその領域内の１つのピクセルだけについて考えると、実際に変化があってから最悪の場合（（１６−１）＋１６）×△ｔの時間後に変化の検知が行われる。これは従来技術４を適用しない、従来の方法と同じである。
【００３２】
その代わりに本発明では、１周期内の各キャプチャタイミング（△ｔ）のそれぞれで、取り込む画像領域がキャプチャパターンの各スキャンラインに対応し、位置が少しずつずれている。検知対象の変化は、実用の場面においては実際には１ピクセルだけではなく、多くのピクセルがまとまって変化する。これら変化領域の縦横のサイズが大きければ大きいほど、複数のスキャンラインに同時に重なる本数が多くなるため、実際には１周期よりも速い時間間隔で検知結果が得られる。
【００３３】
ここで注意すべきなのは、本発明では、検知対象に応じて単に確率的に分解能や検知速度を変えるのではなく、その最悪値を分解能ごとのキャプチャパターンに応じて厳密に保証できる点である。例えば、４分割のキャプチャパターンのスキャンラインの間隔が２５６ピクセルでそれぞれのスキャンラインについて４０ｍｓｅｃごとに画像の取り込みと前後画像間の比較演算などの処理を行い、１６分割のキャプチャパターンのスキャンラインの間隔が６４ピクセルで同様に１６０ｍｓｅｃごとに処理を行う場合、長辺が２５６ピクセルを超える矩形は最悪でも実際の変化開始後８０ｍｓｅｃ未満の遅れで検知でき、６４ピクセルを超える矩形は最悪でも３２０ｍｓｅｃ未満の遅れで検知できる。
【００３４】
小さい領域になるほど検知が遅れる時間は長くなるが、領域の長辺の長さの範囲に応じて最悪の場合の時間が保証される。このことは、本発明を、ＧＵＩの自動操作やユーザの操作監視のように、不特定の対象ＡＰに対して別プロセスからアタッチし、ＣＰＵリソースをシェアしながら実時間で動作することが求められる汎用的なエージェント型プロダクトとして実現する場合には、検知にかかる時間が実行時タイミングや表示内容などの偶然性に依存し明確な保証が与えられない従来の方法に比較すると、有用なアプローチである。そして、自動操作や操作監視の性能を利用者に対して明確に提示し、その実行時の制限をユーザサポートの際に合意する観点から、エージェント型プロダクトの特性上重要である。
【００３５】
また、「画面を横方向のラインで間引くことにより監視する領域を設定し、前記領域を順次ずらして前記画面の監視を行うことを特徴とする」方法が存在する（従来技術５：特許文献５参照）。
【００３６】
本発明では、スキャンラインを横方向だけではなく縦方向にも設定する。また、複数の分解能で同時に判定可能とするため、複数のパターンを重畳して設定する。また、細かい分解能のパターンは長い周期で、粗い分解能のパターンは短い周期でキャプチャする。これにより、検知対象の領域の大きさに応じた分解能を同時に実現できる。
【００３７】
またこれは、２つの点に配慮した実装が可能である。１つは、細かい分解のパターンが粗い分解能のパターンを含むことを利用して、キャプチャ回数を半分にできる。１つは、キャプチャタイミングごとのスキャンライン本数のばらつきをなくし、負荷を平準化できる。
【００３８】
またその他には、１つの周期において、どの順序でスキャンラインをキャプチャするかを動的に制御することで、変化中の領域を優先的に判定することができる。
【００３９】
またその他には、実際にキャプチャするスキャンライン状の矩形領域の幅を動的に制御することで、画面変化中やＣＰＵ使用率が高いときの負荷は低減したまま、画面静止中やＣＰＵ使用率が低いときの分解能を適応的に向上することができる。通常の方法ではどちらか一方を犠牲にした実装となる。
【００４０】
また、画面変化がおさまるかあるいはＣＰＵ使用率が低下する度合に応じて連続的に分解能を調節することで、自然な判定動作を実現することができる。通常の方法では設定値が粗い段階値であるため、動的制御の切り替えによって判定動作が不自然に変化する。
【００４１】
また、分解能の動的な制御のための閾値や重みなどの設定値が細かい段階値の中から選択できるため、本発明を適用するＰＣの性能や画面の画素数、ＧＵＩ画像の変化傾向など（適用先の環境条件）に応じた調整が可能である。通常の方法では、適用先の環境条件が変わると、それに応じて、要求される分解能や許容されるＣＰＵ負荷のバランスをとりながら、キャプチャ周期やキャプチャパターン（領域の形状や面積）や判定ロジック（比較アルゴリズムにおける判定の基準・条件や判定の位置・周期）を実装し直す必要がある。
【発明の概要】
【発明が解決しようとする課題】
【００４２】
背景雑音的な画面変化は、一般的に考えると、ユーザに対してあまり目立たない表示とすることで、ユーザに伝えたい表示内容やその変化に対する人の認識を邪魔しないようになっている。ウィンドウシステムで提供される各種の表示形式やアプリケーションの開発者が設計するＵＩは、結果的にこれに沿ったものになっていると考えられる。従って、領域の面積が小さいほど、また、表示が変化してからさらに別の内容に変化しあるいは元の内容に戻るなどまでの持続時間が短かいほど、検知したい状態である度合が低いと仮定できる。この考え方（段階検知モデル）に基づいたフィルタ設定が可能な検知方法が望まれる。
【００４３】
従来の方法の課題として、この仮定に基づいた段階的・複合的なフィルタ閾値を扱うことができない。例えば、面積的、時間的な閾値は１つの組み合わせしか設定できないため、面積が大きいものであれば短時間の変化であっても通知したり、小さいものであれば長時間の変化にならないと通知しない、などの設定はできない。
【００４４】
ランダムにサンプリングピクセルを設定する方法では、確率的に上記仮定に沿った検知を行うことができるが、検知漏れの最悪値も確率的にしか保証できない。これは、エージェントの設定値に対して動作保証を必要とする場合、例えば画面履歴を開発者によるテストやユーザによる重要操作のエビデンスとして用いる場合や、エージェントにミッションクリティカルな自動操作を実行させる場合、などに実際的（契約規定上、責任分界上）に問題となる。
【００４５】
所定パターンでサンプリングピクセルを設定する方法では、極端に縦長・横長な矩形領域の画面変化を見逃す場合がある。また、段階的・複合的なフィルタ閾値を提供するパターンは提示されていない。さらにこれらパターンを設定値によって変化させる手段は提示されていない。さらにその設定値と検知できる領域面積や変化時間との直感的な対応がとれる検知モデルも提示されていない。
【００４６】
また、このような段階的なフィルタ閾値を扱うにあたっては、フィルタを粗くすることにより負荷を抑制する対策は、一般に有効に働かない。つまり、段階的なフィルタ閾値の精細な方の設定に基づいて、キャプチャの面積（あるいは領域的な粒度）や時間（あるいは周期的な粒度）を固定して処理を行う必要がある。これによって得られるデータはオーバースペックであり、条件を満たさない変化を大量に無視することになる。すなわち、無駄なキャプチャ処理実行や画像データ領域確保が頻発することを意味する。結果として、コンピュータの負荷は、最も重いフィルタ設定の組み合わせに支配されるため、期待したように低くはならない。
【課題を解決するための手段】
【００４７】
本発明では、前記課題を解決するため、
コンピュータの表示画面の変化を検知する装置であって、
表示画面のＸ方向またはＹ方向またはその両方に所定の間隔を空けて指定したスキャンラインの組み合わせによりパターンを生成するスキャンラインパターン生成部と、
スキャンラインごとに画面上の帯状の矩形の画像をキャプチャするキャプチャ処理部と、
キャプチャした画像のデータを蓄積するキャプチャ結果蓄積部と、
以前の周期で蓄積した結果と最新の結果との差異を比較するスキャンライン差異比較部と、
画面変化の開始または継続または終了を外部へ向けて通知する画面変化通知部とを少なくとも備えた
ことを特徴とする。
【００４８】
また、本発明では、前記課題を解決するため、
コンピュータの表示画面の変化を検知する方法であって、
スキャンラインパターン生成部により、表示画面のＸ方向またはＹ方向またはその両方に所定の間隔を空けて指定したスキャンラインの組み合わせによりパターンを生成する工程と、
キャプチャ処理部により、スキャンラインごとに画面上の帯状の矩形の画像をキャプチャする工程と、
キャプチャ結果蓄積部により、キャプチャした画像のデータを蓄積する工程と、
スキャンライン差異比較部により、以前の周期で蓄積した結果と最新の結果との差異を比較する工程と、
画面変化通知部により、画面変化の開始または継続または終了を外部へ向けて通知する工程とを少なくとも含む
ことを特徴とする。
【発明の効果】
【００４９】
本発明によれば、サンプルピクセルではなく、スキャンラインのパターンで画面状態を取得することにより、検出漏れのないことが保証される変化領域の最小高・最小幅を与えることができる。
【００５０】
また、パターンを分解能ごとに複数用意し、所定の周期・頻度で重ね合せて適用することにより、前述した段階検出モデルに基づいた検出を可能にする。
【００５１】
また、高分解能のパターンは分解し、１周期内に複数回に分けて適用することにより、キャプチャ処理の負荷を平滑化することができる。
【００５２】
また、画面検知の状況に応じて、動的にパターンを変更することにより、処理の枠組みを変えることなく、キャプチャ処理の許容負荷と要求検知精度に応じて、動作を適応させることができる。
【００５３】
さらにまた、スキャンラインの幅を静的もしくは動的に増大させることにより、スキャンラインに変化領域がかかる割合を拡大し、実効的な感度を向上させることができる。
【図面の簡単な説明】
【００５４】
【図１】ウィンドウを前面化する場合の表示更新のようすを示す説明図
【図２】ウィンドウを前面化する場合の一般的な表示更新処理のシーケンス図
【図３】画面変化検知処理の基本的なフローチャート
【図４】サンプリングパターンの種類による検知漏れ領域の説明図
【図５】分解能の異なる複数のスキャンラインパターンの説明図
【図６】分解能の異なる複数のスキャンラインパターンを適切な間隔で実施する場合の説明図
【図７】スキャンラインパターン中のスキャンラインを複数回に分けて実施する場合の説明図
【図８】分解能の異なる複数のスキャンラインパターン間における重複を除去したスキャンラインの説明図
【図９】分解能の異なる複数のスキャンラインパターンを適切な間隔で重複を除去し且つ複数回に分けて実施する場合の説明図
【図１０】本発明の画面変化検知装置を含むＰＣ環境の構成図
【図１１】本発明の画面変化検知装置の実施の形態の一例を示す機能構成図
【図１２】本発明の画面変化検知装置における処理のフローチャート
【図１３】検知モード制御部およびスキャンラインパターン生成部の処理のフローチャート
【図１４】スキャンライン差異比較部の処理のフローチャート
【図１５】キャプチャ結果蓄積部の処理のフローチャート
【図１６】内部処理のデータ構造の説明図
【図１７】検知モード制御部およびスキャンラインパターン生成部の他の処理のフローチャート
【図１８】従来技術と本発明との差異の判定周期の説明図
【図１９】差異の判定周期およびパターンの分解能を動的に変化させた場合の説明図
【図２０】スキャンラインパターン生成関数の疑似コードを示す説明図
【図２１】スキャンラインの表示位置のインデックスの説明図
【図２２】スキャンラインの表示位置の座標の説明図
【発明を実施するための形態】
【００５５】
図１は、従来の画面キャプチャ処理での課題の一例、ここでは一のウィンドウを他のウィンドウの前面にもってくる場合の例を示している。従来の画面キャプチャでは、表示更新途中の画像データを取得してしまう場合があった。これに対して、予め設定した待機時間を空けてキャプチャする方法が一般的であるが、動作環境や対象とするアプリケーションやウィンドウによって最適な待機時間が異なる。また実行時の状況によって、表示更新にかかる時間が変動する場合もあり、固定的な時間設定では途中の状態をキャプチャしてしまう可能性が常にある。本発明は、画像内容の変化を監視し、変化の開始を検知するとともに、所定の条件で変化が継続しているかどうかを観察し、変化の終了を検知する、ことを目的とする（背景技術の項では変化の開始の検知を念頭に説明しているが、実際には、変化の継続の認識と変化の終了の検知も目的とする。）。
【００５６】
図２は、ウィンドウを前面化する場合の一般的な表示更新処理のシーケンスを示している。この図からわかるように、操作イベントを検知できたとしても表示更新、すなわち描画処理の終了のタイミングと同期をとることが、処理フローを工夫することによっても原理的に不可能である。
【００５７】
その理由として最も大きなものは、図中(1)に示すように、ＯＳ仕様でフック返却を待たずに非同期に続行することがあり、実行時の状況に大きく依存するためである。具体的には、Windows（登録商標） XP，Vista，７などのMicrosoft（登録商標）社のＯＳでは、ＧＵＩに関するオペレーションのイベントを、他のプロセスで検知する目的で、Windows（登録商標）メッセージのグローバルフックのしくみを使用するのが一般的である。このしくみの仕様として、当該イベントを発生したプロセスをフリーズさせることのないよう、一定時間以上フックプロシージャから処理が戻らない場合、その返却を待つことなく次の処理を続行するようになっている。従って、キャプチャ処理などの時間がかかる処理を行うと、キャプチャ完了時点で既に描画処理が開始されている可能性がある。Windows（登録商標）メッセージで「ウィンドウアクティベイトをこれから開始する」（操作開始直前）というイベントを検知し、操作開始直前の画像を取得しようとしても、実際には既に操作直後のイメージの描画が開始されている状態が発生する場合を避けることができない。
【００５８】
一方でWindows（登録商標）メッセージで「ウィンドウアクティベイトを実行し完了した」（操作完了直後）というイベントを検知し、操作完了直後の画像を取得しようとしても、実際にはまだ描画が途中の状態が発生する場合を避けることもできない。これは、図中(2)〜(5)に示すことから、キャプチャが描画完了のタイミングよりも早くなることがあり、実行時の状況に大きく依存するためである。これが前記に次ぐ理由である。具体的には、(2)、(4)で処理の契機がキューに登録され、別のスレッドからこれを取り出して後続の処理を実行する点や、(3)、(5)でそれぞれの当該処理の実際の効果を得るまでに必要な実行時間が異なったり、当該処理部の内部での他の処理依頼との優先順位が異なったりする点に由来する。
【００５９】
(2)〜(5)について個々の実際の処理内容は以下の通りである。(2)については、検知対象ＡＰのＧＵＩプラットフォームにおけるリペイント（repaint）アルゴリズムによるが、一般にはリペイントを依頼したスレッドで再描画が必要なＧＵＩ要素にフラグをたてることのみを行い、ＧＵＩプラットフォームのウィンドウマネージャにおけるイベントループのスレッドに制御が渡った時点で、実際の描画処理が実行される。(3)については、ＧＵＩプラットフォームとＯＳのグラフィック環境の仕様によるが、ハードウェアアクセラレーションが有効な場合などは、描画処理で生成された図形の描画命令が、Open GLなどの描画エンジンに送信・蓄積され、それがハードウェア的に実行されるというように、グラフィックメモリ上に書き込まれるまでの一連の処理が、所定の実行時間を使って行われる。
【００６０】
(4)については、前記の通りフックプロシージャでの処理時間を短くするために、イベントをエージェント内部の独自のイベントキューに登録し処理を速やかに返却する実装とし、エージェント自身のポーリングイベントで当該登録内容を取り出すことにより、イベント内容に応じた処理が行われる。エージェントは、単に画面キャプチャを行うだけではなく、同じイベントフックの機構を使って、ユーザ操作のログを取得・蓄積したり、シナリオに基づいた自動操作を実行するなど、他の処理も行う。このため、前記イベントキューから取り出したイベント内容に応じた処理にかかるエージェントの実行時間は異なっており、イベント内容によっては処理順序の優先順位を変えるなどの制御も行う必要がある。これにより、画面キャプチャが必要なイベントがキューに登録されてから、実際にＯＳにキャプチャ処理依頼を送信するまでのタイミングは、エージェントの内部実装や前後のイベント内容など実行時の状況に依存する。
【００６１】
さらに、(2)と(3)については、検知対象のＡＰの内部実装やＧＵＩプラットフォームに依存し、またエージェントとは異なる外部の開発ベンダが提供するものであるため、それらに改造を加えることはもちろん、ソースコードを見ることも不可能であること、(4)と(5)については、複数種類の検知対象に汎用的に適用できる実装とする必要があり、従って特定の検知対象や実行時条件に特化した実装が許されないこと、などに注意すべきである。
【００６２】
なお、別途記載した通り、本発明の前提として、ＯＳやハードウェアに手を加えるような対応も許容されない点に留意する必要がある。また、以上はWindows（登録商標） ＯＳとその上でのＧＵＩプラットフォームの環境を前提に述べたが、Linux（登録商標） ＯＳとその上でのＧＵＩプラットフォームなど、別の環境においても同様の問題が発生すると考えられる。しかしながら、それを前記の表示更新の一般的な処理フロー上での工夫として対応しようとすると、個別の実装となり、開発にもコストがかかる。さらにまた、ウィンドウ前面化以外の表示更新の場合（ボタンの押下など）についても、上記と処理フローは共通するが、必要な工夫は個々に異なり、それぞれに対応方法を検討することも現実的に困難である。このため、画像内容の変化を画面キャプチャを通して直接監視し比較検知する方法は、実用性の観点から重要な方法である。
【００６３】
図３は、画面全体もしくは指定された所定の部分領域をキャプチャすることにより、画面の変化を検知する方法の基本的なフローを示している。この方法では、キャプチャする矩形領域が広すぎると処理負荷が重くなる。またキャプチャ周期が短いと変化の検知感度は高まるが、表示更新の途中で瞬間的に静止するなどがあるとそれを逐一検知してしまい、人が変化を認識できる粒度の時間の流れの中で、全体的な変化が収まったかどうかを判定できない。さらに、矩形領域をビットマップにより画像データ取得すると、１ピクセルも漏らさずに比較する点では有利であるが、微小領域の変化に対して全て検知を行ってしまうために感度が高すぎ、やはり領域の広がりの中での全体的な変化が収まったかどうかを判定できない。
【００６４】
図示はしていないが、ランダムに位置指定したピクセルサンプリングでは、確率的に上記の要件を満たす検知が可能であるが、最低検知感度を保証することができない。
【００６５】
図４（ａ）は、規則的に位置指定したピクセルサンプリングの事例である。ピクセルの間隔によって検知感度の保証を与えることができる。しかしながら、ピクセル単位での比較では、破線で示す領域のように、検知できる変化領域の最小高または最小幅のどちらか一方でも下回ると、検知を保証できない。これは表示画面上で発生する画像変化に対して人の直感に反するもので、実用に際して適用環境と設定との適切性の判断が難しい。例えば、図１で示したウィンドウ前面化の際の最初に行われるウィンドウ枠の表示更新に対して、検知漏れの可能性が高いことがわかる。
【００６６】
そこで、図４（ｂ）、（ｃ）、（ｄ）に示す考え方でキャプチャ矩形領域を１ピクセル幅（複数ピクセル幅で設定することは本発明内での工夫の範囲である）のスキャンライン状にすることで処理負荷を抑えながら、上記課題を解決できる。なお、図４（ｂ）は縦方向のスキャンラインパターン（Ｘ方向に一定間隔）、図４（ｃ）は横方向のスキャンラインパターン（Ｙ方向に一定間隔）、図４（ｄ）は同図（ｂ）、（ｃ）のスキャンラインパターンを重畳した例をそれぞれ示す。
【００６７】
さらに、図５に示す考え方で、検知できる変化領域の最小高、最小幅（分解能）を変えた複数のスキャンラインパターンを生成する。また、図６に示す考え方で、キャプチャ周期上の各タイミングにおいて、分解能ごとのスキャンラインパターンを適切な間隔で重畳したパターンに基づいてキャプチャ処理を行うことで、面積が大きいものであれば短時間の変化であっても通知したり、小さいものであれば長時間の変化にならないと通知しないといった動作を実現できる。さらに、図７に示す考え方で、パターン上の多数のスキャンラインをキャプチャ周期上の各タイミングに分散配置し、１つのスキャンラインは１周期で再キャプチャ・比較が行われることを保証すれば、負荷の平準化を実現できる。
【００６８】
さらに図８に示すように、分解能の細かいパターンは分解能の粗いパターンと重なるスキャンラインを持つため、図７で複数回のタイミングに分散配置する際に処理すべきスキャンラインの本数を、半分にできるという効果が得られる。また、これによって、図９に示すように、複数の分解能の異なるパターンを重ね合せながら、１周期内にキャプチャタイミングを分散する場合、各タイミングでキャプチャするライン数を平準化できる、という効果も得られる。
【００６９】
図１０は、本発明の画面変化検知装置（画面変化検知エージェント）を含むＰＣ環境の構成図であり、図中、１はコンピュータ、２はディスプレイ（表示装置）、３はキーボード（入力装置）、４はマウス（入力装置）である。また、コンピュータ１は、ハードディスク（記憶装置）５、内部メモリ６、システムバス７およびＣＰＵ８を含み、内部メモリ６上にはWindows（登録商標） ＯＳ（オペレーティングシステム）１０とともに本発明の画面変化検知装置２０が実装される。
【００７０】
図１１は、本発明の画面変化検知装置２０の実施の形態の一例を示す機能構成図であり、表示画面のＸ方向およびＹ方向に所定の間隔を空けて指定したスキャンラインの組み合わせによりパターンを生成するスキャンラインパターン生成部２１と、スキャンラインごとに画面上の帯状の矩形の画像をキャプチャするキャプチャ処理部２２と、キャプチャした画像のデータを蓄積するキャプチャ結果蓄積部２３と、以前の周期で蓄積した結果と最新の結果との差異を比較するスキャンライン差異比較部２４と、画面変化の開始または継続または終了を装置外部へ向けて通知する画面変化通知部２５と、画面変化通知部２５の通知内容を記憶し、現在の表示画面上の状態および／または外部環境の状態の組み合わせに応じて検知モードを変更し保持する検知モード制御部２６とを備えている。
【００７１】
図１２は、本発明の画面変化検知装置２０における処理の流れを示すものである。ｓ１では、スキャンライン生成部２１においてスキャンラインパターンを生成する。スキャンライン生成部２１では、キャプチャ処理部２２で参照されるパターンをカレントパターンとして保持する。以前のパターンと同じであれば、以降の処理のためのカレントパターンは更新しない。異なっていれば更新する。処理の詳細は図１３に示す。ｓ２ではスキャンラインごとの画像のキャプチャを行う。処理の詳細は図１４に示す。ｓ３では取得したキャプチャ内容（画像）と前回のキャプチャ内容とを比較する。これは、後述の画面バッファ上のキャプチャ領域と当該キャプチャ内容との比較によって実現できるが、キャプチャ内容の１つ前の取得内容を保持する配列を用意して比較するなど、他の実装方法でも等価な処理が実現できる。
【００７２】
ｓ４では、１つ前のキャプチャ内容と現在のキャプチャ内容を比較し、１つでも差異が生じているか否かの条件分岐を行う。前記分岐がYes（１つでも差異が生じている）の場合、ｓ５で現在の更新中フラグがＯＦＦならばＯＮに設定し、画面の変化開始を上位機能に通知する。通知は画面変化通知部２５を介して実行される。前記分岐がNo（差異が１つも生じていない）の場合、ｓ６以降を実行する。
【００７３】
ｓ６では、各スキャンラインごとに保持されている直近変化時刻のタイムスタンプを参照し、現在の時刻と比較する。１つでも時間差が１周期の時間差を超えるものがあれば条件分岐を行う。これは、ｓ４の結果である変化開始時刻lastTime[]を参照し、全てがnull、すなわち未設定の場合をもって判定が可能である。前記が偽の場合、ｓ７で現在の更新中フラグがＯＮならばＯＦＦに設定し、画面の変化終了を上位機能に通知する。前記が真の場合、更新中フラグは変更せず上位機能への通知も特に行わない。これは変化途中であることを意味する。
【００７４】
ここで、ｓ４とｓ６の判定で条件分岐したフローは、以上の処理を経て、ｓ８で合流する。ここでは、現在のキャプチャ内容を後の比較のため保存する。その具体的な方法は、ｓ３の説明でも述べたように、多様に考えられる。ここでは、画面サイズと同じ画面バッファとしてイメージオブジェクトを予め生成しておき、そこに現在キャプチャした内容を所定の位置にコピーする。この位置は、スキャンラインごとの矩形領域のｘ，ｙ、ｗ、ｈ（ｘ，ｙは画面左上隅を起点（０，０）とする領域左上隅の座標位置、ｗは領域の幅、ｈは領域の高さ）を保持したスキャンライン領域rect[]配列に予め準備しておき、これを参照することで決定する。
【００７５】
図１３に検知モード制御部２６およびスキャンラインパターン生成部２１の動作フローの詳細を示す。ここでは、検知モード制御部２６の機能により、現時点での画面変化検知の状態として更新フラグの値とＣＰＵ負荷の値を取得している。そして、その値の範囲によって条件分岐を行い、スキャンラインパターン生成部２１の機能により、適切なパターンを生成し（ｓ１１，ｓ１２）、ループ処理においてここまでで用いてきたカレントパターンとの比較を行い、必要があれば更新する（ｓ１３）。この実施の形態では、画像内容の変化の状態に加えて、当該ＰＣのＣＰＵ負荷を計測し、それが閾値より上か下かによってパターンを適応させている。
【００７６】
すなわち、負荷が高いときは、画像変化が瞬間的に停止しても表示更新は継続している可能性が高いため、分解能を落とすことで、無駄に静止を検知しないようにしている。具体的には、負荷が低い場合は、できるだけ早く静止を検知するため２〜６４分割パターンを生成する（ｓ１１）。負荷が高い場合は、特定の変化サイズ分解能、変化タイミング分解能の分割パターンのみに処理を限定して検知するため１６分割パターンのみを有効にし、他を休止させたパターンを生成する（ｓ１２）。
【００７７】
図１４にスキャンライン差異比較部の動作フローの詳細を示す。ｓ２１ではloopIndexをインクリメントし、１周期の最大値Ｔmax以上ならばゼロに再初期化する。ｓ２２では、関数calcIndex()を呼び出し、現在のloopIndexとpatternIndexに対応するインデックス番号をscanIndex変数に代入する。ｓ２３では、画面上で実際にキャプチャする矩形領域をscanRect[]配列から取得し、その領域をキャプチャする。ｓ２４では、画面バッファscreenBufferイメージ上から以前のキャプチャ内容を再取得し、前記キャプチャ内容と比較する。ｓ２５では、画像の比較の結果、差異があった場合、変化開始のタイムスタンプを直近変化時刻lastTime[]に記憶する。具体的には当該時点でキャプチャしたスキャンラインごとに変化開始時刻lastTime[]を参照し、画像の比較結果が差異なしで、現在の時刻から１周期の時間差を超えていた場合は、nullで上書きし未設定とする。また画像の比較結果が差異ありの場合は、新たに現在の時刻で上書きする。ｓ２６では、２，４，８，１６，３２，６４の各分割パターンについて、patternIndexのループにおいて対応するパターンに関する処理を完了したかにより、条件分岐を行う。
【００７８】
図１５にキャプチャ結果蓄積部の動作フローの詳細を示す。ｓ３１では、スキャンラインごとにキャプチャ内容を次のループで比較対象とするため、メモリ上に保存する。具体的には、画面バッファのイメージオブジェクト上の当該領域にキャプチャ内容を上書きする。
【００７９】
ここで、フローの内容を理解する上で、注意すべき点がある。まず、図１４の詳細フローは、図１２のｓ２とｓ３の２つに対応する。また、図１５の詳細フローは、図１２のｓ８に対応するが、実際の処理は図１４のｓ２４とｓ２６の間で実施しても良い。さらに、図１２のｓ４、ｓ６の条件分岐は、実質的な比較処理が図１４のｓ２４で行われており、その結果をlastTime[]に格納して参照しているだけである。これらの点は、図１２のフローを説明上分かり易くするために、従来の方法である図３のフローとの対応を残した構造としているために生じている。詳細な処理内容としては、上記の通り表記としては異なる箇所があるが、フローとしては実質同じものである。
【００８０】
図１６は、上記で説明した内部処理で必要となる作業用変数、固定変数値、関数を示している。Pattern class，Rectangle class，Image classは、それぞれ実装プログラミング言語がオブジェクト指向言語であることを想定し、当該実行環境で既に存在すればそのライブラリクラスを、存在しなければ個別に定義したクラスを意味している。Pattern classは２〜６４分割のスキャンラインパターンごとの作業用変数や固定変数値をオブジェクト化するためのクラスである。これらにインスタンスは内部処理において１つずつ、すなわちsingletonとして生成される。Rectangle classは表示画面の座標上での矩形図形の幾何情報をオブジェクト化するためのクラスである。左上隅のｘ座標、ｙ座標、並びに矩形の幅ｗ（widthの略）、高さｈ（heightの略）を内部変数として保持する。Image classは当該実装における画像イメージデータをオブジェクト化するためのクラスである。
【００８１】
他の実施の形態として、変化の開始の検知において、変化サイズ感度（所定時間での検知を保証する最小サイズ）を粗くする代わりに、変化タイミング分解能（検知の反応速度、すなわち速い時間間隔で検知結果を得る能力）を細かくする事例を説明する。
【００８２】
図１７は、図１３のｓ１１、ｓ１２を基本に、実行時状況やユーザ設定による適応的な制御方法について示している。
【００８３】
ここで、ｓ４１は、上記の考え方を反映するために追加するステップである。これは更新中フラグがＯＦＦで表示更新が行われていない状態においては、無駄な負荷を避ける観点で、一定以上の領域が一気に変化した場合のみに更新開始とみなす方法である。これを実現するために、小さい領域の変化に対してあえて変化開始の検知を行わないよう、変化サイズ分解能が高いパターンを休止させる。具体的には、８分割パターンのみを動作させ、残りの２、４、１６、３２分割パターンを休止させることで、処理負荷は５分の１になる。そこで、空いた処理余力を使って、当該の変化サイズ分解能について、変化タイミング分解能を高くする。具体的には、１回のタイミングで８分割パターンを４スキャンライン分キャプチャすることにより、従来の２分割パターンと同じ変化タイミング分解能を実現する。この図中ではこれを４倍速型のパターンと呼んでいる。
【００８４】
これはウィンドウの前面化の表示更新を想定している。ウィンドウの前面化では、図１で明らかなように、まずウィンドウフレーム（枠）の表示によって表示更新が開始され（すなわち変化領域の高さ、幅が大きい）、表示更新が進むに従い内部の領域が変化していく、という特性に基づいており、更新の開始をできるだけタイムラグがないよう検知し、更新の終了をできるだけキャプチャ処理負荷が抑えられるような制御を意図している。
【００８５】
ｓ４２は、上記においてさらに、変化タイミング分解能は悪いながらも最低限の変化サイズ分解能を保証するために追加するステップである。これは、予めユーザ設定によって、小領域の変化を無視する設定がＯＦＦにされ、最悪時においての検知感度を従来レベルに維持する指示がされることで有効となる。具体的には、上記８分割パターン４倍速型と並行して３２分割パターンを動作させ、１回のタイミングで５スキャンライン分キャプチャすることにより、処理負荷はｓ１１に相当する従来と同じ負荷レベルでありながら、最悪の場合の変化サイズ、変化タイミングの検知感度も同程度となる検知処理が実現できる。
【００８６】
このようにして生成されるパターンは、格子状であるため小領域の検知漏れは本来的に不可避である。本発明において、変化サイズ分解能をどこまでも細かく設定できれば、小さい領域の検知漏れは理論上極限まで少なくできる。しかし、一般的な表示画面のサイズである１０２４ピクセルもしくは２０４８ピクセルをカバーするには、１回のタイミングで１０本もしくは１１本のスキャンラインを扱う必要がある。グラフィックスエンジンの特性・性能によっては、数多くの細長い矩形領域をキャプチャするよりも、ある程度広い面積の矩形領域を１回でキャプチャする方が、処理時間や消費記憶の観点で負荷が小さい場合もある。また、実用上も一定以上に検知保証される矩形領域サイズが小さくなると、検知遅れ時間の保証をきめ細かい段階を刻んで設定する有用性はほとんどないと考えられる。
【００８７】
そこで、一定以上の分割パターンについては、スキャンラインを太くすることで表示画面領域全体を隙間なくカバーすることが考えられる。ｓ４３はその考え方を反映するために追加するステップである。具体的には、ＣＰＵ負荷が５０％未満の場合のみ、スキャンラインの幅を１６ピクセル（表示画面の辺が１０２４以下の方向）もしくは３２ピクセル（表示画面の辺が２０４８以下の方向）にすることで、これを実現する。ここでは画面全面をマスクするパターンという意味で、これをスキャンラインパターンのマスク版と表記している。
【００８８】
以上のように、検知モード制御部２６の状態定義とスキャンラインパターン生成部２１の生成ロジックによって、これらの調整は、適用対象に応じた変更が容易に行える。特に動的変更も可能であるため、適応的な制御も本発明の構成において、簡易に実装・カスタマイズが可能である。例えば、６４分割、２５６分割など、とびとびに高分解能のパターンのスキャンラインを追加したり、２５６分割のパターンを１回のタイミングで２本ずつスキャンラインを処理する２倍速型とするなど、ＰＣやグラフィックスエンジンの性能に応じて選択組み合わせが可能であり、多段階に設定された各分解能の間のロジック的な依存性はないため、扱いが簡単である、という効果がある。
【００８９】
図１８は実際の画面変化が発生してから検知結果を得るまでの時間差が、従来の方法より短く抑えられる様子を示している。変化開始の検知についての効果は明らかであるが、変化完了の検知については従来と変わらず１周期の時間差が存在する。しかし、変化完了の可能性が存在することは、従来よりも短い時間差で検知できる。これは、図面下部の実線の矢印が短い時間差で現れていることから明らかである。そのため、変化完了の可能性が存在する状態になったら、適応的に分解能を上げることにより、短い時間差での検知が可能となる。
【００９０】
図１９は、上記状態において、分解能の高いパターンを有効にし、２倍速、４倍速に設定した様子を示している。さらに、分解能の高いパターンのスキャンラインの幅を拡大し、ライン間の隙間がないようにすることで、表示画面全体をカバーした検知判定が可能となる。一方、ＣＰＵ負荷が大きい場合は、適応的に分解能の高いパターンを休止させることで、当該端末上で画面変化検知エージェントが他の処理のＣＰＵリソースを奪わないようにすることができる。
【００９１】
なお、以上の説明では、表示画面上の１方向のスキャンラインについて述べているが、実際には、縦方向、横方向の２方向について同じ方法・実装を行い、両方を同時に動作させることを前提としている。これは本発明が適用対象としている問題領域で、極端に横方向に細長い矩形や縦方向に細長い矩形の両方に対応するためであり、検知対象がどちらか一方について対応すれば良い場合に他方を省略して用いても、本発明の効果は基本的に有効である。
【００９２】
画面キャプチャを行う際に必要な、スキャンラインを格子状に配置したパターンを生成するアルゴリズムについて、具体的な事例を説明する。
【００９３】
ここでは横方向についてだけ考慮しており、１回にキャプチャするスキャンラインの本数を５、画面のサイズを１０２４ピクセルとした場合の考え方を示す。パターンは、検知が保証される変化領域のサイズが１０２４の２分の１の場合、４分の１の場合、というように２分の１ずつ分解能が詳細になるものとする。また、１つの分解能のパターンにおける各タイミングでのスキャンラインの位置は、単純に左から右に移動していくものとする。これらの前提を変えて、既に他の部分で述べたように、画面全体がキャプチャ周期内で分散したタイミングで調査されるよう順序を入れ替えたり、逆に領域ごと変化ごとに重点的に前倒しもしくは先延ばしで調査されるよう順位を制御したり、任意に変えて実装することが考えられる。また、設定ファイル等の内容により起動ごとに変化させるよう実装することも、実行時の状況に適応して動的に変化するよう実装することも可能である。これらは、ここで説明するアルゴリズムを基本として任意に応用することで容易に実現できる。
【００９４】
生成アルゴリズムを実際のプログラミング言語上で処理する場合、キャプチャタイミングごとにカウンターをインクリメントし、その数値を引数として関数を呼び出すことで実行する。計算結果は、当該タイミングでキャプチャすべきスキャンラインの位置が、横方向の座標値として得られる。１回のタイミングで複数のスキャンラインをキャプチャするため、複数の結果を返す必要があり、関数の返却値の型は整数の配列変数となる。
【００９５】
図２０に上記関数の疑似コードを示す。この関数内では、当該アルゴリズムで計算する分解能ごとのパターン数だけ、ループを実行する。以下では具体的事例としてｉ＝２のときの計算過程を説明する。このときの考え方を、図２１および図２２に示す。
【００９６】
このアルゴリズム上でｉ＝２を計算するときは、スキャンラインの位置が移動する周期は４（変数freqに代入される）であり、分解能は細かいほうから３番目のパターンに相当する。予め本処理で扱う表示画面の横方向のピクセル数を考慮して、ssize＝１０と設定されているものとし、分解能はこれをもとに計算で得られる（変数resoに代入される）。この事例では、counter＝２７９１のときのタイミングとする。
【００９７】
couterを4で剰余した結果「３」は、図２１から、当該分解能パターンにおける「０」を初期値とする「３」、すなわち４番目のタイミングに相当する。図２２から、表示画面の横方向を分解能の幅で分割した場合の４番目の座標位置を、分解能の半分の幅だけ右にずらした座標値が、算出すべき数値となる。上記アルゴリズムでは、この計算をｉを扱うべき分解能パターンの数だけ繰り返すことで、必要とする複数のスキャンラインの座標位置を算出する。
【００９８】
なお、タイミングを表すcounter変数は正の整数でなければならない。よって、当該アルゴリズムを動作させる上で最も長い周期（この例では、２5＝３２）の任意の倍数（例えば、３２０や２０４８など）を超えたら０に再初期化する必要がある。
【００９９】
なお、本発明は、周知のコンピュータに媒体もしくは通信回線を介して、図１１の構成図に示された機能を実現するプログラムあるいは図１２〜図１５、図１７のフローチャートに示された手順を備えるプログラムをインストールすることによっても実現可能である。
【符号の説明】
【０１００】
１：コンピュータ、２：ディスプレイ、３：キーボード、４：マウス、５：ハードディスク、６：内部メモリ、７：システムバス、８：ＣＰＵ、１０：オペレーティングシステム、２０：画面変化検知装置（画面変化検知エージェント）、２１：スキャンラインパターン生成部、２２：キャプチャ処理部、２３：キャプチャ結果蓄積部、２４：スキャンライン差異比較部、２５：画面変化通知部、２６：検知モード制御部。
【先行技術文献】
【特許文献】
【０１０１】
【特許文献１】特開２０１０−２０４８４０号公報
【特許文献２】特許第４４７６１２５号公報
【特許文献３】特許第３４８１５１５号公報
【特許文献４】特許第３１７５９４７号公報
【特許文献５】特許第４３９４５９５号公報
【図１】
2014167711.tif 000003
【図２】
2014167711.tif 000004
【図３】
2014167711.tif 000005
【図４】
2014167711.tif 000006
【図５】
2014167711.tif 000007
【図６】
2014167711.tif 000008
【図７】
2014167711.tif 000009
【図８】
2014167711.tif 000010
【図９】
2014167711.tif 000011
【図１０】
2014167711.tif 000012
【図１１】
2014167711.tif 000013
【図１２】
2014167711.tif 000014
【図１３】
2014167711.tif 000015
【図１４】
2014167711.tif 000016
【図１５】
2014167711.tif 000017
【図１６】
2014167711.tif 000018
【図１７】
2014167711.tif 000019
【図１８】
2014167711.tif 000020
【図１９】
2014167711.tif 000021
【図２０】
2014167711.tif 000022
【図２１】
2014167711.tif 000023
【図２２】
2014167711.tif 000024