JP7420268B2 - データ処理装置、データ処理方法及びデータ処理プログラム - Google Patents

Description

本開示は、データ処理装置、データ処理方法及びデータ処理プログラムに関する。

今日、多くの企業が、様々なソフトウェアを使って業務を行っている。業務に使われるソフトウェアとしては、業務システム（例えば、顧客管理、会計管理）や、汎用的なアプリケーション（例えば、メーラ、ブラウザ）等が挙げられる。

業務担当者は、ソフトウェアのマニュアルを、業務担当者の間で共有する場合がある。例えば、企業によっては、商品やサービスは、業務システムでの端末操作を中心とした業務を通して、顧客に提供される。この場合、例えば、マニュアルは、商品やサービスを提供するための業務システムの操作手順を規定する。マニュアルでは、例えば、同一の商品やサービスを提供するための操作手順が、商品やサービスごとに決められている。

業務の実施に関しては、一般的には、業務担当者は、商品やサービスの提供に必要な処理を、マニュアルに沿って行うことが期待される。マニュアルに沿った業務では、同一の商品やサービスを処理する手順が、同一の操作手順になることが望ましい。

しかしながら、実際には、様々なイレギュラーな事象が、業務において発生する。イレギュラーな事象としては、顧客が注文後に注文内容を変更するという事象や、商品の欠品があるという事象や、操作ミスが端末操作において発生するという事象等が挙げられる。実際の業務には、マニュアルの作成時に想定されていない様々なイレギュラーな事象があるため、イレギュラーな事象に対して全ての操作手順を予め規定することは、現実的ではないことが多い。また、イレギュラーな事象のために多様な操作方法を覚えることは、業務担当者にとって困難である。

このように、全ての案件を予め規定された手順で処理することは、現実的ではないことが多く、実際には、同一の商品やサービスを処理する手順は、それぞれの案件によって一般的に異なる。

業務分析の観点からは、上述したようなイレギュラーな事象を把握することは、業務改善に役立つ。業務改善を目的とした検討においては、通常の操作の他にイレギュラーな事象を含む業務実態を、網羅的に把握することが望ましい。

例えば、通常業務に関しては、業務がマニュアルに規定された操作手順に則って実施されているかを確認することが望ましい。さらに、より効率的な手順や自動化可能な手順を検討するために、業務実態を把握することが望ましい。

一方、イレギュラーな事象に関しては、どのようなイレギュラーな事象が普段発生するか、どの程度イレギュラーな事象が発生するか、またはどのように業務担当者がイレギュラーな事象を処理しているか等の、業務実態を把握することが望ましい。

このような業務実態を把握することが可能であれば、企業は、業務実態を、業務担当者がスムーズに業務を実施することを可能にするための対応策の検討のために役立てることができる。

そこで、業務実態を把握するために、操作手順をフローチャート形式で表示することが提案されている（非特許文献１）。操作手順をフローチャート形式で表示する表示手法は、ＲＰＡ（Robotic Process Automation）を導入する企業のために自動化の対象となる業務や作業を特定することを目的とした業務分析に有効である。

上述の表示手法では、複数の操作手順が、ノードとしてそれぞれ表示され、業務プロセスは、これらのノードを並べることによって可視化される。具体的には、はじめに、操作ログが、各種サービスへの申し込み等の案件に対して記録される。操作ログは、例えば、操作者の操作時刻、操作の種類（操作種別とも呼ばれる）、案件を特定するための識別情報（すなわち、案件ＩＤ）等を含む。次いで、操作ログが、ノードを生成するための入力として使用される。その後、案件ごとの操作の違いが、案件ごとにノードを並べ、かつ同一の操作の種類の操作手順を同じノードとして重ね合わせることによって把握される。

操作ログの取得に関しては、ＧＵＩ（Graphical User Interface）の表示状態を効率的に取得するための技術が提案されている（特許文献１）。この技術は、操作者によるＧＵＩ部品への操作の粒度に基づいて操作ログを取得する仕組みを提供するものである。この技術では、ＧＵＩ部品が、ＧＵＩアプリケーションの操作画面を構成する。イベントが発生した時に、ＧＵＩ部品の属性値が、操作画面から取得される。そして、ＧＵＩ部品の変更箇所が、イベントの発生前後で発見される。このようにして、属性値の変更を生じさせたイベント（すなわち、業務において意味を持つ操作イベント）が抽出されるとともに、操作箇所が特定される。

特開２０１５－１５３２１０号公報

小笠原志朗、土川公雄、兵藤守、丸山勉、"業務の実行履歴を活用した業務プロセス可視化・分析システムの開発"［online］、［２０２０年９月１１日検索］、インターネット（https://www.ntt.co.jp/journal/0902/files/jn200902040.pdf）

しかしながら、上記の従来技術では、操作ログを容易に収集できるとはいえなかった。

例えば、実際の業務においては、業務は、一般的には、業務システムだけでなく、メーラ、ブラウザ、パッケージソフト（例えば、文書作成、表計算、プレゼンテーション）等の様々なアプリケーションを使用しながら進められる。業務担当者による業務実施の状況を把握するためには、これらの全てのアプリケーションの実行環境に応じてＧＵＩ部品の属性値を取得し、ＧＵＩ部品の変更箇所を特定する仕組みを開発することが考えられる。しかしながら、ＧＵＩ部品の状態を取得する仕組みは、アプリケーションの実行環境によって異なる場合がある。このため、企業がＧＵＩ部品を取得する仕組みをアプリケーションごとに開発する場合に、この仕組みは、いくらかの開発コストを必要とする。実際には、開発コストが高く、このような仕組みを開発することが、現実的ではない場合がある。

仮に、企業が、特定のアプリケーションについて上述したような仕組みを開発したものとする。しかしながら、この場合、アプリケーション仕様変更が対象のアプリケーションのバージョンアップに伴い発生すると、企業は、その仕様変更に合わせた仕組みの改造が必要になる場合がある。その結果、改造に関するコストが発生する場合がある。

また、シンクライアント環境が、コンピュータ資源の有効活用や、セキュリティ対策を目的に、近年企業で普及している。シンクライアント環境では、アプリケーションは、業務担当者が直接操作を行う端末であるクライアント端末に、インストールされていない。代わりに、アプリケーションは、クライアント端末に接続された別の端末にインストールされている。

シンクライアント環境では、アプリケーションによって提供される操作画面は、クライアント端末上で、画像として表示される。業務担当者は、表示された画像を通して、別の端末にインストールされたアプリケーションを操作する。この場合、操作画面は、業務担当者が実際に操作を行う端末上で、単に画像として表示される。このため、ＧＵＩ部品およびＧＵＩ部品の変更箇所をクライアント端末から特定することは困難である。

このように、多様なアプリケーションを用いた業務や、シンクライアント環境においては、業務担当者のアプリケーション上で行われるＧＵＩ部品への操作を、操作ログとして収集することは、容易ではない。

本願は、上記に鑑みてなされたものであって、操作ログを容易に収集することを目的とする。

本開示の実施形態に係るデータ処理装置は、ウィンドウの複数の画像を取得する取得部と、前記取得部によって取得された複数の画像の各々から、ＧＵＩ部品候補の画像部分を抽出し、取得された画像ごとに、抽出された画像部分が配置される配置場所に関する配置データを生成する生成部と、前記生成部によって生成された複数の配置データについて、配置場所が互いに対応する所定のＧＵＩ部品候補の画像部分同士を比較し、当該所定のＧＵＩ部品候補の画像部分が互いに異なる場合に、当該所定のＧＵＩ部品候補を、操作可能なＧＵＩ部品として認識する認識部とを備える。

実施形態の一態様によれば、操作ログを容易に収集することができる。

図１は、実施形態に係る操作ログ取得システムの一例を示す図である。 図２Ａは、操作イベントを取得する取得処理の一例を示す説明図である。 図２Ｂは、操作イベントを取得する取得処理の一例を示す説明図である。 図３は、同一のウィンドウを分類する分類処理の一例を示す説明図である。 図４は、ＧＵＩ部品のグラフ構造を生成する生成処理の一例を示す説明図である。 図５は、ＧＵＩ部品のグラフ構造から操作のあるＧＵＩ部品のノードに固有のＩＤを付与する付与処理の一例を示す説明図である。 図６は、キャプチャ画像および操作イベントから操作箇所のＧＵＩ部品を特定するＧＵＩ部品特定処理の一例を示す説明図である。 図７は、操作箇所の固有のＩＤを特定する固有ＩＤ特定処理の一例を示す説明図である。 図８は、実施形態に係るデータ処理装置によって実行される、操作イベントを取得するための処理の一例を示すフローチャートである。 図９は、実施形態に係るデータ処理装置によって実行される、見本ＧＵＩグラフ構造を生成するための処理の一例を示すフローチャートである。 図１０は、実施形態に係るデータ処理装置によって実行される、操作ログを生成するための処理の一例を示すフローチャートである。 図１１は、ハードウェア構成の一例を示す図である。

以下、本開示の実施形態について、図面を参照しつつ詳細に説明する。なお、この実施形態により本発明が限定されるものではない。１つまたは複数の実施形態の詳細は、以下の説明および図面に記載される。また、複数の実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の１つまたは複数の実施形態において同一の部位には同一の符号を付し、重複する説明は省略する。

〔１．概要〕
本節では、本明細書に記載されるいくつかの実装形態の概要について説明する。なお、この概要は、読者の便宜のために提供されるものであって、本発明や、以下の節で説明される実施形態を限定することを意図するものではない。

従来、ＰＣ（Personal Computer）等の端末を使った業務を改善するために、様々な業務分析が提案されている。業務分析の１つは、ＰＣ上の操作の操作ログから、ＲＰＡが適用可能な作業を発見することである。

ＲＰＡが適用可能な作業は、例えば、一連の操作手順を周期的に繰り返すこと等の、機械的な作業である。もし、ＲＰＡが適用可能な作業が操作ログから発見されれば、ＲＰＡの適用によって、機械的な作業を自動化することが可能になる。

ところで、ＲＰＡの適用は、細かな操作ログを必要とする場合がある。細かな操作ログは、例えば、粒度がＧＵＩ部品への操作のレベルの操作ログである。粒度という用語は、データの細かさや詳しさを意味する。例えば、ＧＵＩ部品への操作のレベルの操作ログは、ＧＵＩ部品の部品名（例えば、テキストボックス、ラジオボタン）、入力値（例えば、文字列、数値）等を含む。

上述の操作ログの取得に関しては、ＧＵＩ部品のオブジェクトデータを使用した操作ログ取得技術が提案されている（特許文献１）。この操作ログ取得技術では、はじめに、ブラウザのＨＴＭＬ（Hyper Text Markup Language）情報が、ブラウザへの操作イベントのタイミングで取得される。次いで、取得されたＨＴＭＬ情報が解析され、ＧＵＩ部品の状態（例えば、ＧＵＩ部品の部品名、入力値）が取得される。言い換えると、ＧＵＩ部品の状態が、操作画面に含まれるオブジェクトのオブジェクトデータとして取得される。その後、ＧＵＩ部品の状態が、前の操作イベント時に取得されたＧＵＩ部品の状態と比較される。ＧＵＩ部品の状態が変化した場合に、ＧＵＩ部品の状態が、操作ログに記録される。

しかしながら、実際には、多様なアプリケーションが業務で使用される場合に、上述の操作ログ取得技術では、開発コストが問題となる場合がある。

具体的には、ＧＵＩ部品の状態を取得する方法は、アプリケーションの実行環境ごとに異なる。操作ログを取得するソフトウェアが実行環境ごとに開発される場合に、ソフトウェアの開発は、かなりのコストがかかる場合がある。

そこで、実施形態に係るデータ処理装置は、多様なアプリケーションを使用した業務に対して、ＲＰＡの適用等の、ＧＵＩ部品への操作のレベルの操作ログを必要とする業務分析を適用するために、以下に説明される操作ログ取得処理を実行する。データ処理装置は、３つの段階を経て、操作ログを取得する。

第１の段階は、操作イベントの取得である。第１の段階では、データ処理装置は、イベント種別（マウス、キーボード）、操作発生箇所、およびアプリケーションの操作画面のキャプチャ画像を、操作イベントのタイミングで取得する。

第２の段階は、見本ＧＵＩ部品グラフ構造の生成である。第２の段階では、はじめに、データ処理装置は、操作画面のキャプチャ画像から、枠（例えば、矩形）または文字列の箇所を、ＧＵＩ部品候補の画像部分として取得する。そして、データ処理装置は、取得された箇所の位置情報に基づいて、ＧＵＩ部品グラフ構造を生成する。ＧＵＩ部品グラフ構造は、ＧＵＩ部品候補の画像部分がどのように操作画面内に配置されているかを示す。

データ処理装置は、操作イベントのタイミングごとに、上述のイベント種別、操作発生箇所、および操作画面のキャプチャ画像を取得する。そして、データ処理装置は、同一の操作画面（すなわち、同一のウィンドウ）の複数のキャプチャ画像から、複数のＧＵＩ部品グラフ構造を生成する。

次いで、データ処理装置は、データ処理装置は、複数のＧＵＩ部品グラフ構造を比較し、ＧＵＩ部品候補の画像部分の変化が生じる箇所を、操作可能なＧＵＩ部品が配置される箇所として特定する。データ処理装置は、特定された箇所に固有のＩＤを割り当てることによって、操作可能なＧＵＩ部品の配置箇所の見本となるグラフ構造として、見本ＧＵＩ部品グラフ構造を生成する。

第３の段階は、操作ログの生成である。第３の段階では、はじめに、データ処理装置は、時系列の操作イベントごとの操作画面のキャプチャ画像から、ＧＵＩ部品グラフ構造を新たに生成する。そして、データ処理装置は、各操作イベントにおける操作の発生箇所に基づいて、新たに生成されたＧＵＩ部品グラフ構造のうちのどの箇所が操作されたかを特定する。

次いで、データ処理装置は、新たに生成されたＧＵＩ部品グラフ構造と、見本ＧＵＩ部品グラフ構造とを比較する。データ処理装置は、見本ＧＵＩ部品グラフ構造に含まれる固有のＩＤの中から、新たに生成されたＧＵＩ部品グラフ構造のうちの操作された箇所に対応する固有のＩＤを取得する。データ処理装置は、取得された固有のＩＤに基づいて、この箇所に配置されたＧＵＩ部品が何であるかを特定する。

その後、データ処理装置は、操作イベントと、前の操作イベントとを比較する。操作イベントに変化がある場合に、データ処理装置は、操作イベントを操作ログに記録する。このようにして、データ処理装置は、操作ログを取得することができる。

上述のように、データ処理装置は、アプリケーションの操作画面から、ＧＵＩ部品への操作のレベルの操作ログを、汎用的に生成する。これにより、データ処理装置は、アプリケーションに依らず、ＧＵＩ部品への操作の粒度で、操作ログを生成することができる。

〔２．操作ログ取得システムの構成〕
まず、図１を参照して、実施形態に係る操作ログ取得システムの構成について説明する。

図１は、実施形態に係る操作ログ取得システム１の一例を示す図である。図１に示されるように、操作ログ取得システム１は、データ処理装置１００と、端末装置２００とを含む。図１中では図示していないが、操作ログ取得システム１は、複数台のデータ処理装置１００や、複数台の端末装置２００を含んでもよい。

操作ログ取得システム１において、データ処理装置１００および端末装置２００は、それぞれネットワークＮと有線又は無線により接続される。ネットワークＮは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）等のネットワークである。操作ログ取得システム１の構成要素は、ネットワークＮを介して互いに通信を行うことができる。

データ処理装置１００は、ソフトウェアの操作のログを取得するための処理を実行する情報処理装置である。データ処理装置１００は、サーバを含む、任意のタイプの情報処理装置であってもよい。

端末装置２００は、ユーザによって利用される情報処理装置である。ユーザは、例えば、業務担当者である。業務担当者は、端末装置２００上で、業務システムや、汎用的なアプリケーション等の、各種ソフトウェアを使用する。端末装置２００は、スマートフォン、デスクトップ型ＰＣ、ノート型ＰＣ、タブレット型ＰＣ等のクライアント装置を含む、任意のタイプの情報処理装置であってもよい。

なお、図１の例では、データ処理装置１００は、端末装置２００の外部に配置されたデータ理装置として示されているが、これに限定されるものではない。データ処理装置１００は、端末装置２００の内部に配置されたデータ処理器として実装されてもよい。

次に、データ処理装置１００の構成例について説明する。

図１に示されるように、データ処理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、データ処理装置１００は、データ処理装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボード、マウス等）や、各種情報を表示するための表示部（有機ＥＬ（Electro Luminescence）、液晶ディスプレイ等）を有してもよい。

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部１１０は、有線または無線によりネットワーク網と接続される。通信部１１０は、端末装置２００に、ネットワークＮを介して、通信可能に接続されてもよい。通信部１１０は、端末装置２００との間で、ネットワーク網を介して、情報の送受信を行うことができる。

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図１に示されるように、記憶部１２０は、操作データ記憶部１２１と、配置データ記憶部１２２と、見本配置データ記憶部１２３と、ログデータ記憶部１２４とを有する。

（操作データ記憶部１２１）
操作データ記憶部１２１は、ソフトウェアの操作に関する操作データを記憶する。操作データ記憶部１２１は、後述する取得部１３１によって取得された操作データを記憶する。例えば、操作データ記憶部１２１は、操作データとして、ユーザの操作イベント（例えば、マウスＹキーボードの操作）の発生時間、操作イベントの発生位置、および操作画面（すなわち、ウィンドウ）のキャプチャ画像を記憶する。

（配置データ記憶部１２２）
配置データ記憶部１２２は、ＧＵＩ部品の配置に関する配置データを記憶する。配置データ記憶部１２２は、後述する生成部１３２によって生成された配置データを記憶する。例えば、配置データ記憶部１２２は、配置データとして、ＧＵＩ部品グラフ構造を記憶する。ＧＵＩ部品グラフ構造は、図４を参照して以下で詳述される。

（見本配置データ記憶部１２３）
見本配置データ記憶部１２３は、操作可能なＧＵＩ部品として認識されたＧＵＩ部品の配置に関する見本配置データを記憶する。見本配置データ記憶部１２３は、後述する認識部１３３によって生成された見本配置データを記憶する。例えば、見本配置データ記憶部１２３は、見本配置データとして、見本ＧＵＩ部品グラフ構造を記憶する。見本ＧＵＩ部品グラフ構造は、図５を参照して以下で詳述される。

（ログデータ記憶部１２４）
ログデータ記憶部１２４は、ソフトウェアの操作のログに関するログデータを記憶する。ログデータ記憶部１２４は、後述する記録部１３６によって記録されたログデータを記憶する。例えば、ログデータ記憶部１２４は、ログデータとして、ＧＵＩ部品に対する操作のログを記憶する。

（制御部１３０）
制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサによって、データ処理装置１００内部の記憶装置に記憶されている各種プログラム（データ処理プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路により実現されてもよい。

制御部１３０は、図１に示されるように、取得部１３１と、生成部１３２と、認識部１３３と、特定部１３４と、判定部１３５と、記録部１３６とを有し、以下に説明する情報処理の機能や作用を実現又は実行する。データ処理装置１００の１つまたは複数のプロセッサは、データ処理装置１００の１つまたは複数のメモリに記憶された命令を実行することによって、制御部１３０内の各制御部の機能を実現することができる。なお、制御部１３０の内部構成は、図１に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。例えば、認識部１３３は、認識部１３３以外の部に関して後述する情報処理の全部または一部を行ってもよい。

（取得部１３１）
取得部１３１は、ソフトウェアの操作のログを取得するための処理を実行するのに使用される各種情報を取得する。例えば、取得部１３１は、ソフトウェアの操作に関する操作データを取得する。

取得部１３１は、操作データを、端末装置２００から受信する。取得部１３１は、操作データ記憶部１２１に、受信された操作データを格納する。

取得部１３１は、操作データとして、操作イベントを取得する。また、取得部１３１は、操作イベントのタイミングで、操作の発生時間、操作の発生箇所および操作画面のキャプチャ画像を取得する。

図２Ａおよび図２Ｂは、操作イベントを取得する取得処理の一例を示す説明図である。取得部１３１は、ユーザの操作イベント（例えば、マウスやキーボードの操作）の発生時間および発生位置を取得する。また、取得部１３１は、操作画面（すなわち、ウィンドウ）のキャプチャ画像を取得する。取得部１３１は、操作イベントのタイミングごとに、イベント種別（例えば、マウス、キーボード）、操作発生箇所、および操作画面のキャプチャ画像を取得する。

図２Ａの例では、取得部１３１は、操作イベントとして、マウスクリックを取得する。取得部１３１は、操作イベント１１と、キャプチャ画像１２とを取得する。操作イベント１１は、左マウスクリックである。操作イベント１１の発生時間は、２０２０年６月３０日の１１時００分０３秒である。操作イベント１１の発生位置のＸ座標は、２５０ｐｘである。また、操作イベント１１の発生位置のＹ座標は、６５０ｐｘである。キャプチャ画像１２は、顧客情報登録画面のキャプチャ画像である。

図２Ｂの例では、取得部１３１は、操作イベントとして、キーボード入力を取得する。取得部１３１は、操作イベント２１と、キャプチャ画像２２とを取得する。操作イベント２１は、「ＤＥ（で）のＥの入力」である。操作イベント２１の発生時間は、２０２０年６月３０日の１１時００分０３秒である。操作イベント１１の発生位置のＸ座標は、２００ｐｘである。また、操作イベント１１の発生位置のＹ座標は、１８０ｐｘである。ＤＥ（で）のＥが入力されたテキストボックスの幅Ｗは、２０ｐｘである。また、このテキストボックスの高さＨは、２０ｐｘである。キャプチャ画像２２は、顧客情報登録画面のキャプチャ画像である。

取得部１３１は、ユーザの操作イベント（例えば、マウスやキーボードの操作）のタイミングで、端末装置２００から、操作イベントに関する情報を取得する。

取得部１３１は、操作イベントに関する情報として、イベントの種別（クリック、キー）を取得する。

取得部１３１は、操作イベントに関する情報として、操作イベントの位置を取得する。取得部１３１が操作イベントの位置を取得できない場合に、取得部１３１は、前後の操作によって生じた操作画面の変化から、操作イベントの位置を特定してもよい。

アプリケーションが端末装置２００で動作している場合に、取得部１３１は、アクティブウィンドウの識別情報を取得してもよい。アクティブウィンドウは、マウスやキーボードによる操作を受け付けているウィンドウである。アクティブウィンドウの識別情報は、例えば、ウィンドウハンドル、ウィンドウタイトル等のデータである。

取得部１３１は、操作イベントに関する情報として、ウィンドウのキャプチャ画像を取得する。アプリケーションが端末装置２００で動作している場合に、アクティブウィンドウのキャプチャ画像を取得する。端末装置２００がシンクライアント環境で使用されている場合に、操作画面全体のキャプチャ画像を取得する。

取得部１３１は、ユーザの操作イベントの直後ではなく、指定時間ごとに、操作画面のキャプチャ画像を取得してもよい。そして、取得部１３１は、ユーザの操作イベントの発生時間と、キャプチャ画像の取得時間とを、後から比較し、操作イベントの発生時間の直後にキャプチャされた画像に、操作イベントの発生時間を関連付けてもよい。

（生成部１３２）
図１に戻ると、生成部１３２は、ソフトウェアの操作のログを取得するための処理を実行するのに使用される各種情報を生成する。例えば、生成部１３２は、ＧＵＩ部品の配置に関する配置データを生成する。生成部１３２は、配置データとして、後述するＧＵＩ部品グラフ構造を生成する。生成部１３２は、生成された配置データを、配置データ記憶部１２２に格納する。

生成部１３２は、操作データ記憶部１２１から、操作データを取得する。例えば、生成部１３２は、操作データ記憶部１２１に記憶されたキャプチャ画像から、同一の操作画面（すなわち、同一のウィンドウ）のキャプチャ画像を収集する。同一の操作画面を収集する方法として、次の２通りの方法が考えられる。１つ目の方法は、アプリケーション名とウィンドウタイトルが同一のウィンドウが同一の操作画面構成を有することを前提に、アプリケーション名とウィンドウタイトルが同一のウィンドウを収集する方法である。しかし、ウィンドウのアプリケーション名とウィンドウタイトルが同一であっても、ウィンドウが、異なる操作画面構成を有する場合がある。そのため、２つ目の方法として、見た目が類似するウィンドウを収集する方法がある。

図３は、同一のウィンドウを分類する分類処理の一例を示す説明図である。生成部１３２は、ウィンドウのキャプチャ画像を、同一のウィンドウごとに集約する。図３の例では、生成部１３２は、ウィンドウの複数のキャプチャ画像３０を、同一のウィンドウの複数のキャプチャ画像３１と、同一のウィンドウの複数のキャプチャ画像３２とに分類する。分類後、同一のウィンドウの複数のキャプチャ画像３１は、第１のクラスに属する。同一のウィンドウの複数のキャプチャ画像３２は、第２のクラスに属する。

一例として、生成部１３２は、アクティブウィンドウの識別情報に基づいて、キャプチャ画像を、同一のウィンドウごとに収集する。別の例として、生成部１３２は、キャプチャ画像をクラスタリングしてもよい。すなわち、生成部１３２は、キャプチャ画像の見た目の類似度に基づいて、キャプチャ画像を分類してもよい。クラスタリングの方法に関しては、例えば、生成部１３２は、キャプチャ画像のピクセルを使用して、キャプチャ画像をベクトル化してもよい。そして、生成部１３２は、K-means法等のクラスタリングの手法を使用して、キャプチャ画像を、Ｋ個のクラスタに分類してもよい（Ｋは、任意の自然数）。

図１に戻ると、生成部１３２は、操作画面のキャプチャ画像から、ＧＵＩ部品候補の部分画像を抽出する。そして、生成部１３２は、ＧＵＩ部品候補の部分画像と、この部分画像の座標に基づいて、グラフ構造を生成する。

生成部１３２は、同一のウィンドウの複数のキャプチャ画像の各々から、ＧＵＩ部品候補の部分画像を抽出する。そして、生成部１３２は、部分画像の座標に基づいて、ＧＵＩ部品グラフ構造を生成する。このように、生成部１３２は、操作画面のキャプチャ画像から、ＧＵＩ部品グラフ構造を生成する。

例えば、生成部１３２は、操作画面のキャプチャ画像から、枠（例えば、矩形）または文字列の箇所を取得する。生成部１３２は、例えば、キャプチャ画像のうちの矩形の箇所を、ＧＵＩ部品候補の部分画像として抽出する。生成部１３２は、取得された箇所の位置情報に基づいて、ＧＵＩ部品グラフ構造を生成する。生成部１３２は、例えば、矩形の箇所の位置に基づいて、ＧＵＩ部品グラフ構造を生成する。

ＧＵＩ部品のグラフ構造の生成の一例では、まず、生成部１３２は、操作画面のキャプチャ画像から枠または文字列の箇所の部分画像と、その部分画像の座標とを取得する。次に、生成部１３２は、キャプチャ画像を、キャプチャ画像の左上（例えば、座標が（ｘ，ｙ）＝（０，０））からキャプチャ画像の右下へと走査し、最も左上に出現する部分画像を特定する。そして、生成部１３２は、部分画像のｙ座標および高さｈに着目し、人手で設定された閾値ｔを用いて、（ｙ－ｔ）ｐｘから（ｙ＋ｈ＋ｔ）ｐｘまでの範囲内に他の部分画像があるかを判定する。この範囲内に他の部分画像があれば、生成部１３２は、部分画像および他の部分画像をグラフにおいて同一の行にする。さらに、生成部１３２は、部分画像のｘ座標に着目し、ｘ座標の小さい順に部分画像を並べ、部分画像をエッジでつなげる。

生成部１３２は、上記の処理を、全ての部分画像が処理されるまで続ける。最後に、生成部１３２は、各行のｙ座標に基づいて、行の順番を決定する。

アプリケーションがブラウザである場合に、生成部１３２は、ＨＴＭＬ情報からＧＵＩ部品の状態を直接取得するのではなく、ＧＵＩ部品候補の画像部分として、テキストラベルの箇所や、テキストボックスの箇所等を取得する。そして、生成部１３２は、このような箇所の位置情報に基づいて、ＧＵＩ部品グラフ構造を生成する。アプリケーションがWindows（登録商標）アプリケーションである場合に、生成部１３２は、ＵＩオートメーションを用いてＧＵＩ部品の状態を直接するのではなく、ＧＵＩ部品候補の画像部分として、テキストラベルの箇所やチェックボックスの箇所、テキストボックスの箇所等を取得する。そして、生成部１３２は、このような箇所の位置情報に基づいて、ＧＵＩ部品グラフ構造を生成する。

ＧＵＩ部品グラフ構造は、ＧＵＩ部品候補の画像部分がどのように操作画面内に配置されているかを示すグラフ構造である。ＧＵＩ部品グラフ構造は、ＧＵＩ部品候補の画像部分を、ノードで表現し、ＧＵＩ部品候補の画像部分同士間の配置関係を、エッジで表現する。

図４は、ＧＵＩ部品のグラフ構造を生成する生成処理の一例を示す説明図である。図４の例では、生成部１３２は、操作画面のキャプチャ画像４１ａから、ＧＵＩ部品候補の部分画像５１ａを抽出する。例えば、生成部１３２は、操作画面のキャプチャ画像４１ａ矩形または文字列の箇所を抽出する。

図４に示されるように、ＧＵＩ部品候補の部分画像５１ａは、テキストラベル、テキストボックス、プルダウンメニュー、ラジオボタン、ボタン等の部分画像を含む。例えば、ＧＵＩ部品「顧客情報登録画面」は、テキストラベルである。ＧＵＩ部品「北海道」は、プルダウンメニューである。ＧＵＩ部品「電電花子」は、テキストボックスである。ＧＵＩ部品「白丸」は、ラジオボタンである。

図４に示されるように、ＧＵＩ部品候補の部分画像は、座標に関連付けられている。座標（ｘ，ｙ，ｗ，ｈ）は、ＧＵＩ部品候補の位置（すなわち、ｘｙ座標）、幅および高さを表す。例えば、ＧＵＩ部品「顧客情報登録画面」の座標は、（２００，５０，１５０,１５）である。

生成部１３２は、操作画面のキャプチャ画像から、ＧＵＩ部品の外観に関する所定の条件を満たす部分画像を、ＧＵＩ部品候補の部分画像として抽出する。例えば、ＧＵＩ部品の外観に関する所定の条件は、オブジェクトの形状が枠形状であるという条件である。また、例えば、この所定の条件は、オブジェクトがテキストであるという条件である。例えば、生成部１３２は、キャプチャ画像から、ＧＵＩ部品となり得る矩形または文字列を切り出す。さらに、生成部１３２は、切り出された矩形または文字列の座標（ｘ，ｙ，ｗ，ｈ）を特定する。生成部１３２は、OpenCV（Open Source Computer Vision Library）、Tesseract等のＯＣＲ（Optical Character Recognition）技術を使用することによって、矩形または文字列を切り出すことができる。

図４の例では、生成部１３２は、ＧＵＩ部品候補の部分画像５１ａから、ＧＵＩ部品グラフ構造６１ａを生成する。ＧＵＩ部品グラフ構造６１ａは、ＧＵＩ部品候補の部分画像がノードとして表現され、ＧＵＩ部品候補の部分画像同士の位置関係がエッジとして表現されたデータ構造である。例えば、ＧＵＩ部品「顧客情報登録画面」は、ノードである。また、ＧＵＩ部品「案件ＩＤ：」およびＧＵＩ部品「１１１１１１」も、ノードである。ＧＵＩ部品「案件ＩＤ：」をＧＵＩ部品「１１１１１１」に接続する線は、エッジである。

ＧＵＩ部品グラフ構造の生成に関しては、はじめに、生成部１３２は、ＧＵＩ部品候補の部分画像のｙ座標および高さｈに着目する。複数のＧＵＩ部品候補の部分画像のｙ座標および高さｈが予め設定された閾値に該当する場合に、生成部１３２は、これらの複数のＧＵＩ部品候補の部分画像が同じ行に配置されるように、ＧＵＩ部品グラフ構造を生成する。例えば、閾値が５ｐｘに設定されている場合に、生成部１３２は、第１のＧＵＩ部品候補の画像の行が、ｙ座標が第１のＧＵＩ部品候補の画像のｙ座標から「－５ｐｘ」から「ｈ＋５ｐｘ」の範囲内の第２のＧＵＩ部品候補の画像の行と同一になるように、ＧＵＩ部品グラフ構造を生成する。

次いで、生成部１３２は、これらの複数のＧＵＩ部品候補の部分画像のｘ座標に着目する。生成部１３２は、ｘ座標の大きさに基づいて、同一の行内のＧＵＩ部品候補の画像の順番を決定する。

図４の例では、例えば、ＧＵＩ部品「顧客情報登録画面」のｙ座標は、「５０」である。座標ｙの値が低いほど、ＧＵＩ部品は、上位に位置し、ｙ座標の値が大きいほど、ＧＵＩ部品は、下位に位置する。ＧＵＩ部品「顧客情報登録画面」のｙ座標の値は、ＧＵＩ部品候補の部分画像５１ａのｙ座標値の中で最も低い値である。したがって、生成部１３２は、ＧＵＩ部品「顧客情報登録画面」、第１の行に配置する。

図４の例では、例えば、ＧＵＩ部品「案件ＩＤ：」およびＧＵＩ部品「１１１１１１」のｙ座標は、「１２０」である。ＧＵＩ部品「案件ＩＤ：」およびＧＵＩ部品「１１１１１１」のｙ座標の値は、ＧＵＩ部品候補の部分画像５１ａでの２番目に大きいｙ座標の値である。したがって、生成部１３２は、ＧＵＩ部品「案件ＩＤ：」およびＧＵＩ部品「１１１１１１」を、第２の行に配置する。ＧＵＩ部品「案件ＩＤ：」およびＧＵＩ部品「１１１１１１」は、同一の行に配置されているため、生成部１３２は、ＧＵＩ部品「案件ＩＤ：」と、ＧＵＩ部品「１１１１１１」とをエッジによって接続する。

（認識部１３３）
図１に戻ると、認識部１３３は、生成部１３２の場合と同様に、ソフトウェアの操作のログを取得するための処理を実行するのに使用される各種情報を生成する。例えば、認識部１３３は、操作可能なＧＵＩ部品として認識されたＧＵＩ部品の配置に関する見本配置データを生成する。認識部１３３は、見本配置データとして、ＧＵＩ部品をノードで表現し、ＧＵＩ部品の配置関係をエッジで表現する見本グラフ構造を生成する。例えば、認識部１３３は、見本グラフ構造として、後述する見本ＧＵＩ部品グラフ構造を生成する。認識部１３３は、生成された見本配置データを、見本配置データ記憶部１２３に格納する。

認識部１３３は、生成部１３２によって生成された配置データを取得する。例えば、認識部１３３は、配置データ記憶部１２２から、生成部１３２によって生成された配置データを取得する。

認識部１３３は、生成部１３２によって生成された配置データとして、ＧＵＩ部品グラフ構造を取得する。より具体的には、認識部１３３は、生成部１３２によって複数のキャプチャ画像から生成された複数のＧＵＩ部品グラフ構造を取得する。そして、認識部１３３は、複数のＧＵＩ部品グラフ構造を比較する。認識部１３３は、比較結果に基づいて、ＧＵＩ部品のグラフ構造から操作のあるＧＵＩ部品のノードに固有のＩＤを付与する。これより、認識部１３３は、見本ＧＵＩ部品グラフ構造を生成する。見本ＧＵＩ部品グラフ構造は、操作可能なＧＵＩ部品の配置箇所の見本となるグラフ構造である。

認識部１３３は、同一の操作画面（すなわち、ウィンドウ）を横並びで見ることによって、画像部分（例えば、矩形）が変化する箇所を、操作箇所として特定する。そして、認識部１３３は、特定された操作箇所に固有のＩＤを付与することによって、見本ＧＵＩ部品グラフ構造を生成する。

例えば、認識部１３３は、ＧＵＩ部品候補の画像部分の変化が生じる箇所を、操作可能なＧＵＩ部品が配置される箇所として特定する。そして、認識部１３３は、特定された箇所に固有のＩＤを割り当てることによって、操作画面（すなわち、ウィンドウ）ごとの見本ＧＵＩ部品グラフ構造を生成する。

認識部１３３は、同一の操作画面（すなわち、同一のウィンドウ）のグラフ構造を横並びに見ることによって、画像部分の変化がある箇所を、操作可能なＧＵＩ部品の箇所として特定する。例えば、テキストラベルの箇所は、画像部分の変化がない箇所である。一方、テキストボックスの箇所は、画像部分の変化がある箇所である。この場合、認識部１３３は、テキストボックスの箇所に、固有のＩＤを割り当てる。認識部１３３は、テキストボックス、ラジオボタン、ボタン等の、画像部分の変化がある箇所に固有のＩＤを割り当てることによって、見本ＧＵＩ部品グラフ構造を生成する。

図５は、ＧＵＩ部品のグラフ構造から操作のあるＧＵＩ部品のノードに固有のＩＤを付与する付与処理の一例を示す説明図である。図５の例では、認識部１３３は、同一の操作画面（すなわち、同一のウィンドウ）に対応する複数の操作画面の複数のＧＵＩ部品グラフ構造を重ね合わせることによって、操作が行われるＧＵＩ部品を識別する。すなわち、認識部１３３は、複数のＧＵＩ部品グラフ構造を重ね合わせ、ＧＵＩ部品が変化した配置箇所を特定する。

図５の例では、ＧＵＩ部品グラフ構造６１ａ、ＧＵＩ部品グラフ構造６２ａ、ＧＵＩ部品グラフ構造６３ａおよびＧＵＩ部品グラフ構造６４ａは、操作画面のキャプチャ画像４１ａ、操作画面のキャプチャ画像４２ａ、操作画面のキャプチャ画像４３ａおよび操作画面のキャプチャ画像４４ａから、生成部１３２によってそれぞれ生成される。認識部１３３は、ＧＵＩ部品グラフ構造６１ａ、ＧＵＩ部品グラフ構造６２ａ、ＧＵＩ部品グラフ構造６３ａおよびＧＵＩ部品グラフ構造６４ａを、横通して見ることによって、色や入力値が変化するＧＵＩ部品を、操作可能なＧＵＩ部品として認識する。

例えば、ＧＵＩ部品グラフ構造６１ａ、ＧＵＩ部品グラフ構造６２ａ、ＧＵＩ部品グラフ構造６３ａおよびＧＵＩ部品グラフ構造６４ａでは、ＧＵＩ部品は、ＧＵＩ部品「顧客情報登録画面」が配置された箇所で変化しない。一方、ＧＵＩ部品は、ＧＵＩ部品「電電花子」またはＧＵＩ部品「山田太郎」が配置された箇所で変化する。認識部１３３は、このようなＧＵＩ部品の変化から、操作のあるＧＵＩ部品を特定する。

認識部１３３は、操作可能なＧＵＩ部品として認識されたＧＵＩ部品が配置された箇所に、固有のＩＤを付与する。図５の例では、認識部１３３は、ＧＵＩ部品「６３５４９８」の配置箇所、ＧＵＩ部品「山田太郎」の配置箇所、ＧＵＩ部品「神奈川」の配置箇所、ＧＵＩ部品「横須賀市滝川町・・・」の配置箇所、ＧＵＩ部品「黒丸」の配置箇所、ＧＵＩ部品「白丸」の配置箇所、ＧＵＩ部品「保存」の配置箇所およびＧＵＩ部品「登録」の配置箇所に、ＩＤ「１」、ＩＤ「２」、ＩＤ「３」、ＩＤ「４」、ＩＤ「５」、ＩＤ「６」、ＩＤ「７」およびＩＤ「８」をそれぞれ付与する。

固有のＩＤの付与に関しては、例えば、認識部１３３は、複数のＧＵＩ部品グラフ構造から、代表のＧＵＩ部品グラフ構造を抽出する。認識部１３３は、代表のＧＵＩ部品グラフ構造と、残りのＧＵＩ部品グラフ構造とのマッチング問題を解くことによって、最も共通するグラフ構造を見つける。認識部１３３は、各種グラフマッチングアルゴリズムを使用して、最も共通するグラフ構造を見つけることができる。

認識部１３３が最も共通するグラフ構造を見つけた場合に、認識部１３３は、対応する箇所のＧＵＩ部品同士が一致するかを確認する。例えば、認識部１３３は、画像または文字列の一致を確認する。対応する箇所のＧＵＩ部品同士が一致しない場合に、認識部１３３は、この箇所に配置されたＧＵＩ部品が操作可能なＧＵＩ部品であると判定する。そして、認識部１３３は、この箇所に固有のＩＤを付与する。

認識部１３３は、ＧＵＩ部品が変化した配置箇所に固有のＩＤを付与することによって、見本ＧＵＩグラフ構造を生成する。認識部１３３は、生成された見本ＧＵＩグラフ構造を、見本配置データ記憶部１２３に格納する。また、認識部１３３は、配置箇所に付与された固有のＩＤを、見本配置データ記憶部１２３に格納する。加えて、認識部１３３は、アクティブウィンドウの識別情報を、見本配置データ記憶部１２３に格納してもよい。このように、認識部１３３は、固有のＩＤが配置箇所に付与されたグラフ構造を、見本ＧＵＩ部品グラフ構造として、データベース（例えば、見本配置データ記憶部１２３）に登録する。

（特定部１３４）
図１に戻ると、特定部１３４は、ソフトウェアの操作に関する各種情報を特定する。例えば、特定部１３４は、アプリケーションの操作画面（すなわち、ウィンドウ）に配置されたＧＵＩ部品に対する操作に関する情報を特定する。

特定部１３４は、ユーザの操作イベントを取得する。そして、特定部１３４は、取得された操作イベントごとに、操作画面に配置されたＧＵＩ部品のうちのどれが取得された操作イベントに対応するかを決定する。特定部１３４は、操作イベントを、端末装置２００から取得する。特定部１３４は、操作データ記憶部１２１から、操作イベントを取得してもよい。

特定部１３４は、取得部１３１の場合と同様に、各種操作イベントに関する情報を取得する。例えば、特定部１３４は、操作イベントに関する情報として、イベントの種別（クリック、キー）、操作イベントの位置、アクティブウィンドウの識別情報およびウィンドウのキャプチャ画像等の情報を取得する。

特定部１３４は、操作イベントで取得された、操作画面のキャプチャ画像から、ＧＵＩ部品グラフ構造を生成する。特定部１３４は、見本配置データ記憶部１２３に記憶された見本ＧＵＩ部品グラフ構造のうち、生成されたＧＵＩ部品グラフ構造に最も類似する見本ＧＵＩ部品グラフ構造を抽出する。そして、特定部１３４は、操作の発生位置に基づいて、見本グラフ構造から操作箇所（例えば、矩形の箇所）を特定する。特定部１３４は、見本ＧＵＩ部品グラフ構造から、操作箇所に対応する固有のＩＤを取得する。このようにして、特定部１３４は、操作イベントの発生位置から、操作のあるＧＵＩ部品を特定する。

例えば、はじめに、特定部１３４は、操作イベントの取得処理で取得された操作イベント（例えば、取得部１３１によって取得された操作イベント）を、時系列に見ていく。特定部１３４は、時系列の操作イベントごとの操作画面のキャプチャ画像から、ＧＵＩ部品が操作された操作箇所を特定する。特定部１３４は、操作画面のキャプチャ画像から、ＧＵＩ部品グラフ構造を新たに生成する。そして、特定部１３４は、各操作イベントにおける操作の発生箇所に基づいて、新たに生成されたＧＵＩ部品グラフ構造から、ＧＵＩ部品が操作された操作箇所を特定する。すなわち、特定部１３４は、新たに生成されたＧＵＩ部品グラフ構造のうちのどのＧＵＩ部品が操作されたかを特定する。

次いで、特定部１３４は、新たに生成されたＧＵＩ部品グラフ構造と、見本配置データ記憶部１２３に記憶された見本ＧＵＩ部品グラフ構造とを比較することによって、操作箇所に配置されたＧＵＩ部品を特定する。特定部１３４は、見本ＧＵＩ部品グラフ構造に含まれる固有のＩＤから、新たに生成されたＧＵＩ部品グラフ構造から特定された操作箇所に対応する固有ＩＤを取得する。そして、特定部１３４は、取得された固有ＩＤに基づいて、特定された操作箇所に配置されたＧＵＩ部品が何であるかを特定する。例えば、取得された固有ＩＤ「７」がボタンに割り当てられている場合に、特定部１３４は、操作されたＧＵＩ部品がボタンであることを特定する。

図６は、キャプチャ画像および操作イベントから操作箇所のＧＵＩ部品を特定するＧＵＩ部品特定処理の一例を示す説明図である。図６の例では、はじめに、特定部１３４は、操作イベント８１と、操作画面のキャプチャ画像８２とを取得する。図６に示されるように、操作イベント８１の発生位置のＸ座標は、２２０ｐｘである。また、操作イベント８１の発生位置のＹ座標は、６１０ｐｘである。キャプチャ画像８２は、顧客情報登録画面のキャプチャ画像である。

次いで、特定部１３４は、操作画面のキャプチャ画像８２から、枠（例えば、矩形）および文字列の箇所を抽出する。図６に示されるように、特定部１３４は、生成部１３２の場合と同様に、操作画面のキャプチャ画像８２から、ＧＵＩ部品候補の部分画像８３を抽出する。そして、特定部１３４は、ＧＵＩ部品候補の部分画像８３のうちのどれが、操作イベントのＧＵＩ部品に対応するかを決定するために、ＧＵＩ部品候補の部分画像８３から、ＧＵＩ部品グラフ構造８４を生成する。特定部１３４は、操作イベントの座標に基づいて、ＧＵＩ部品候補の配置箇所のうちのどれが操作箇所に対応するかを決定する。

図６の例では、特定部１３４は、ＧＵＩ部品「保存」の配置箇所が操作Ｏに対応することを特定する。ＧＵＩ部品「保存」の配置箇所は、操作イベントの発生位置を含む。特定部１３４は、操作イベントの発生位置から、操作イベントが発生したＧＵＩ部品の箇所を特定する。図６の例では、操作イベント８１の発生位置の座標「Ｘ：２２０ｐｘ，Ｙ：６１０ｐｘ」は、ＧＵＩ部品「保存」の配置箇所内に存在する。このため、特定部１３４は、操作イベントが発生したＧＵＩ部品の箇所として、ＧＵＩ部品「保存」の配置箇所を特定する。

図１に戻ると、特定部１３４は、データベース（例えば、見本配置データ記憶部１２３）に登録された見本ＧＵＩ部品グラフ構造の中から、生成されたＧＵＩ部品グラフ構造に対応する見本ＧＵＩ部品グラフ構造を特定する。そして、特定部１３４は、特定された見本ＧＵＩ部品グラフ構造の中から、操作イベントが発生したＧＵＩ部品に対応する配置箇所を特定し、特定された配置箇所に付与された固有のＩＤを特定する。

見本ＧＵＩ部品グラフ構造の特定に関しては、一例として、特定部１３４は、識別情報が対象とする（すなわち、ターゲットの）操作イベントのアクティブウィンドウの識別情報と一致する見本ＧＵＩ部品グラフ構造を特定する。別の例として、特定部１３４は、対象とする操作イベントから生成されたＧＵＩ部品グラフ構造と、データベース（例えば、見本配置データ記憶部１２３）内の見本ＧＵＩ部品グラフ構造とのグラフマッチング問題を解くことによって、最大共通部分グラフを抽出する。例えば、特定部１３４は、編集距離を使用したアルゴリズムに従って、編集距離が最も小さい見本ＧＵＩ部品グラフ構造を特定する。あるいは、特定部１３４は、編集距離が設定された閾値以下の見本ＧＵＩ部品グラフ構造を特定する。

固有のＩＤの特定に関しては、一例として、特定部１３４は、対象となる操作イベントのキャプチャ画像から生成されたＧＵＩ部品グラフ構造と、上述の特定された見本ＧＵＩ部品グラフ構造とのグラフマッチング問題を解くことによって、最大共通部分グラフを抽出する。この場合、対象となる操作イベントのＧＵＩ部品グラフ構造および見本ＧＵＩ部品グラフ構造に共通する箇所のＧＵＩ部品の対応関係を、処理結果として取得することが望ましい。そして、特定部１３４は、予め特定された操作箇所のＧＵＩ部品に対応する見本ＧＵＩ部品グラフ構造に付与された固有のＩＤを、この操作箇所の固有のＩＤとして取得する。固有のＩＤが対応する見本ＧＵＩ部品グラフ構造に付与されていない場合に、見本ＧＵＩ部品グラフ構造内の配置箇所は、操作箇所ではない。この場合、特定部１３４は、操作ログを生成しない。

図７は、操作箇所の固有のＩＤを特定する固有ＩＤ特定処理の一例を示す説明図である。図７の例では、特定部１３４は、図６を参照して上述したＧＵＩ部品グラフ構造８４と、見本配置データ記憶部１２３に記憶された見本ＧＵＩ部品グラフ構造との一致度に基づいて、ＧＵＩ部品グラフ構造８４との共通性が高い見本ＧＵＩ部品グラフ構造を特定する。

例えば、特定部１３４は、グラフマッチング問題の手法を使用して、ＧＵＩ部品グラフ構造８４との共通性が高い見本ＧＵＩ部品グラフ構造を特定する。例えば、特定部１３４は、編集距離を使用したアルゴリズムを使用して、複数の見本ＧＵＩ部品グラフ構造７０に含まれる見本ＧＵＩ部品グラフ構造７０ａおよび見本ＧＵＩ部品グラフ構造７０ｂの編集距離を算出する。そして、特定部１３４は、編集距離が最も小さい見本ＧＵＩ部品グラフ構造を特定する。あるいは、特定部１３４は、編集距離が設定された閾値以下の見本ＧＵＩ部品グラフ構造を特定する。

図７の例では、例えば、特定部１３４は、各ノードの記載内容を考慮せずに、グラフ構造に基づいて編集距離を算出する。例えば、ＧＵＩ部品グラフ構造８４および見本ＧＵＩ部品グラフ構造７０ａを、上から順にみて、ノードの構造同士を比較する。ＧＵＩ部品グラフ構造８４の１行目から９行目までのノードの構造は、見本ＧＵＩ部品グラフ構造７０ａの１行目から９行目までのノードの構造と一致する。したがって、見本ＧＵＩ部品グラフ構造７０ａの編集距離は、「０」である。

一方、ＧＵＩ部品グラフ構造８４の１行目から５行目までのノードの構造は、見本ＧＵＩ部品グラフ構造７０ｂの１行目から５行目までのノードの構造と一致する。しかしながら、ＧＵＩ部品グラフ構造８４の６行目では、ノードの数は「３」であり、見本ＧＵＩ部品グラフ構造７０ｂの６行目では、ノードの数は「４」である。したがって、６行目における編集距離は、「１」である。ＧＵＩ部品グラフ構造８４の７行目では、ノードの数は「２」であり、見本ＧＵＩ部品グラフ構造７０ｂの７行目では、ノードの数は「３」である。したがって、７行目における編集距離は、「１」である。ＧＵＩ部品グラフ構造８４の８行目では、ノードの数は「２」であり、見本ＧＵＩ部品グラフ構造７０ｂの８行目では、ノードの数は「２」である。したがって、８行目における編集距離は、「０」である。ＧＵＩ部品グラフ構造８４の９行目では、ノードの数は「３」であるが、見本ＧＵＩ部品グラフ構造７０ｂの９行目には、ノードが存在しない。したがって、９行目における編集距離は、「３」である。特定部１３４は、これらの編集距離の和をとり、見本ＧＵＩ部品グラフ構造７０ｂの編集距離として、「５」を算出する。

なお、特定部１３４は、各ノードの記載内容を考慮して、編集距離を算出してもよい。特定部１３４は、ノードの構造と、ノードの記載内容とに基づいて、見本ＧＵＩ部品グラフ構造の編集距離を算出してもよい。例えば、特定部１３４は、ＯＣＲを使用して、各ノードの記載内容を、テキストとして取得してもよい。そして、特定部１３４は、取得された文字列を比較してもよい。文字列同士が異なる場合に、特定部１３４は、編集距離をインクリメントしてもよい。テキストによる比較では、例えば、特定部１３４は、文字列の編集距離を算出してもよい。

また、特定部１３４は、ノードの画像部分を比較してもよい。これらの画像部分が互いに異なる場合に、特定部１３４は、編集距離をインクリメントしてもよい。例えば、特定部１３４は、画像部分をベクトルで表現する。そして、特定部１３４は、ベクトル間の類似度を算出する。算出された類似度が閾値以上である場合に、特定部１３４は、これらの画像部分が同一であると判定する。算出された類似度が閾値未満である場合に、これらの画像部分は互いに異なると判定する。

図７の例では、特定部１３４は、ＧＵＩ部品グラフ構造８４との共通性が高い見本ＧＵＩ部品グラフ構造として、見本ＧＵＩ部品グラフ構造７０ａを特定する。特定部１３４は、グラフマッチングの問題によって、ＧＵＩ部品グラフ構造８４の各ＧＵＩ部品の配置箇所に対応する配置箇所を、見本ＧＵＩ部品グラフ構造７０ａから特定する。図７の例では、ＩＤ「７」が、ＩＤ「１」、ＩＤ「２」、ＩＤ「３」、ＩＤ「４」、ＩＤ「５」、ＩＤ「６」、ＩＤ「７」およびＩＤ「８」の中から、操作Ｏに対応する配置箇所の固有のＩＤとして特定される。図５を参照して上述したように、ＩＤ「７」は、ＧＵＩ部品「保存」の配置箇所に付与されている。言い換えると、取得された固有ＩＤ「７」がボタン「保存」に割り当てられている。このため、特定部１３４は、操作ＯがＧＵＩ部品「保存」に対する操作であることを特定することができる。また、特定部１３４は、操作されたＧＵＩ部品がボタン「保存」であることを特定することができる。

（判定部１３５）
図１に戻ると、判定部１３５は、ソフトウェアの操作に関する各種情報を記録するかを判定する。判定部１３５は、操作イベントに変化があるかを判定する。判定部１３５は、時系列順に操作イベントを見ていくことによって、前の操作イベントが操作対象のＧＵＩ部品と異なるかを判定する。例えば、判定部１３５は、特定部１３４によって取得された操作イベントを、イベントの発生時間の順に処理する。そして、判定部１３５は、対象とする操作イベントの操作箇所が前に発生した操作イベントの操作箇所と異なるかを判定する。

例えば、判定部１３５は、操作イベントと、この操作イベントの直前に発生した前の操作イベントとを比較し、比較結果に基づいて、操作箇所のＧＵＩ部品が互いに異なるかを判定する。より具体的には、判定部１３５は、操作に対応する配置箇所の固有のＩＤが前の操作に対応する配置箇所の固有のＩＤと一致するかを判定する。これにより、判定部１３５は、操作イベントに変化があるかを判定する。

（記録部１３６）
記録部１３６は、ソフトウェアの操作に関する各種情報を記録する。判定部１３５がソフトウェアの操作に関する各種情報を記録すると判定した場合に、記録部１３６は、各種情報を記録する。例えば、記録部１３６は、ソフトウェアの操作のログに関するログデータを、ログデータ記憶部１２４に記憶する。

判定部１３５が、対象とする操作イベントの操作箇所が前に発生した操作イベントの操作箇所と異なると判定した場合に、記録部１３６は、対象とする操作イベントを、操作ログ（例えば、ログデータ記憶部１２４）に記録する。例えば、操作箇所のＧＵＩ部品が互いに異なる場合に、記録部１３６は、操作イベントを、操作ログとして記録する。より具体的には、操作に対応する配置箇所の固有のＩＤが前の操作に対応する配置箇所の固有のＩＤと一致しない場合に、操作イベントを、操作ログとして記録する。このように、記録部１３６は、操作イベントに変化がある場合に、操作イベントを操作ログに記録する。

〔３．操作ログ取得処理のフロー〕
次に、図８、図９および図１０を参照して、実施形態に係るデータ処理装置１００による操作ログ取得処理の手順について説明する。

図８は、実施形態に係るデータ処理装置１００によって実行される、操作イベントを取得するための処理の一例を示すフローチャートである。

図８に示されるように、はじめに、データ処理装置１００の取得部１３１は、ユーザが処理を停止した、または端末装置２００の電源を落としたかを判定する（ステップＳ１０１）。

ユーザが処理を停止しておらず、かつ端末装置２００の電源を落としていないと判定された場合に（ステップＳ１０１：Ｎｏ）、取得部１３１は、操作イベントを取得する（ステップＳ１０２）。例えば、取得部１３１は、操作イベントとして、操作の発生時間、イベント種別、操作の発生箇所およびウィンドウのキャプチャ画像を取得する。そして、取得部１３１は、再度ステップＳ１０１を実行する。

ユーザが処理を停止した、または端末装置２００の電源を落としたと判定された場合に（ステップＳ１０１：Ｙｅｓ）、操作イベントを取得するための処理は終了する。

図９は、実施形態に係るデータ処理装置１００によって実行される、見本ＧＵＩグラフ構造を生成するための処理の一例を示すフローチャートである。

図９に示されるように、はじめに、データ処理装置１００の生成部１３２は、取得部１３１によって取得された、同一のウィンドウのキャプチャ画像を収集し、ＧＵＩ部品のグラフ構造を作成する（ステップＳ２０１）。例えば、生成部１３２は、ＧＵＩ部品候補の画像部分の位置に基づいて、ＧＵＩ部品のグラフ構造を生成する。

次いで、データ処理装置１００の認識部１３３は、同一のウィンドウのキャプチャ画像を横通しで見ていき、生成部１３２によって生成されたＧＵＩ部品のグラフ構造から、操作のあるＧＵＩ部品を特定する（ステップＳ２０２）。例えば、認識部１３３は、グラフ構造から、操作のあるＧＵＩ部品の配置箇所を特定する。

次いで、認識部１３３は、操作のあるＧＵＩに固有のＩＤを付与する（ステップＳ２０３）。例えば、認識部１３３は、操作のあるＧＵＩ部品の配置箇所に、固有のＩＤを付与する。一例として、認識部１３３は、同一のウィンドウのグラフ構造同士を比較することによって、操作可能なＧＵＩ部品の配置箇所の見本として、上述の見本ＧＵＩ部品グラフ構造を生成する。

次いで、認識部１３３は、ＧＵＩ部品のグラフ構造と、固有のＩＤとをデータベースに登録する（ステップＳ２０４）。例えば、認識部１３３は、複数のＧＵＩ部品のグラフ構造と、複数のＧＵＩ部品のグラフ構造から生成された見本ＧＵＩ部品グラフ構造を、見本配置データ記憶部１２３に記憶する。

図１０は、実施形態に係るデータ処理装置１００によって実行される、操作ログを生成するための処理の一例を示すフローチャートである。

図１０に示されるように、はじめに、データ処理装置１００の特定部１３４は、全ての操作イベントがターゲットとされたかを判定する（ステップＳ３０１）。

全ての操作イベントがターゲットとされたと判定された場合に（ステップＳ３０１：Ｙｅｓ）、操作ログを生成するための処理は終了する。

全ての操作イベントがターゲットとされていないと判定された場合に（ステップＳ３０１：Ｎｏ）、特定部１３４は、ターゲットとする操作イベントを決定する（ステップＳ３０２）。

次いで、特定部１３４は、操作イベントの操作位置と、操作画面から抽出されたＧＵＩ部品のグラフ構造とから、操作箇所のＧＵＩ部品を特定する（ステップＳ３０３）。

次いで、特定部１３４は、データベースから、ＧＵＩ部品のグラフ構造と共通性の高い見本ＧＵＩ部品グラフ構造を特定し、操作箇所のＧＵＩ部品に対応するノードを特定する（ステップＳ３０４）。

例えば、特定部１３４は、見本配置データ記憶部１２３から、ＧＵＩ部品のグラフ構造との共通性が最も高い見本ＧＵＩ部品グラフ構造を特定する。あるいは、特定部１３４は、見本配置データ記憶部１２３から、グラフ構造の共通度が閾値を満たす見本ＧＵＩ部品グラフ構造を特定する。一例として、特定部１３４は、見本配置データ記憶部１２３から、編集距離が閾値以下の見本ＧＵＩ部品グラフ構造を特定する。

次いで、特定部１３４は、固有のＩＤが特定されたノードに付与されているかを判定する（ステップＳ３０５）。

固有のＩＤが特定されたノードに付与されていないと判定された場合に（ステップＳ３０５：Ｎｏ）、特定部１３４は、再度ステップＳ３０１を実行する。

固有のＩＤが特定されたノードに付与されていると判定された場合に（ステップＳ３０５：Ｙｅｓ）、データ処理装置１００の判定部１３５は、ＧＵＩ部品への操作が前の操作イベントと異なるかを判定する（ステップＳ３０６）。

ＧＵＩ部品への操作が前の操作イベントと同じであると判定された場合に（ステップＳ３０６：Ｎｏ）、特定部１３４は、再度ステップＳ３０１を実行する。

ＧＵＩ部品への操作が前の操作イベントと異なると判定された場合に（ステップＳ３０６：Ｙｅｓ）、データ処理装置１００の記録部１３６は、ＧＵＩ部品への操作を、操作ログとして出力する（ステップＳ３０７）。そして、特定部１３４は、再度ステップＳ３０１を実行する。

なお、図９を参照して上述した「見本ＧＵＩグラフ構造を生成するための処理」は、図１０を参照して上述した「操作ログを生成するための処理」と同じプロセスにおいて実行されてもよい。この場合、ステップＳ２０２、ステップ２０３およびステップＳ２０４は、ステップＳ３０１の前に実行される。

〔４．その他〕
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

例えば、図１に示した記憶部１２０の一部又は全部は、データ処理装置１００によって保持されるのではなく、ストレージサーバ等に保持されてもよい。この場合、データ処理装置１００は、ストレージサーバにアクセスすることで、操作データ等の各種情報を取得する。

〔５．ハードウェア構成〕
図１１は、ハードウェア構成の一例を示す図である。上述してきた実施形態に係るデータ処理装置１００は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。

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

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

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

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

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

〔６．効果〕
上述してきたように、実施形態に係るデータ処理装置１００は、取得部１３１と、生成部１３２と、認識部１３３とを有する。

実施形態に係るデータ処理装置１００において、取得部１３１は、ウィンドウの複数の画像を取得する。また、実施形態に係るデータ処理装置１００において、生成部１３２は、取得部１３１によって取得された複数の画像の各々から、ＧＵＩ部品候補の画像部分を抽出し、取得された画像ごとに、抽出された画像部分が配置される配置場所に関する配置データを生成する。また、実施形態に係るデータ処理装置１００において、認識部１３３は、生成部１３２によって生成された複数の配置データについて、配置場所が互いに対応する所定のＧＵＩ部品候補の画像部分同士を比較し、当該所定のＧＵＩ部品候補の画像部分が互いに異なる場合に、この所定のＧＵＩ部品候補を、操作可能なＧＵＩ部品として認識する。

これにより、実施形態に係るデータ処理装置１００は、操作ログを容易に収集することができる。

また、実施形態に係るデータ処理装置１００において、生成部１３２は、取得部１３１によって取得された複数の画像から、同一のウィンドウの複数の画像を収集し、収集された各画像から、ＧＵＩ部品候補の画像部分を抽出し、収集された画像ごとに、配置データを生成する。

これにより、実施形態に係るデータ処理装置１００は、ウィンドウにおいて操作可能なＧＵＩ部品をウィンドウの画像から特定することができるので、アプリケーションに依らずに、操作ログを容易に収集することができる。

また、実施形態に係るデータ処理装置１００において、認識部１３３は、複数の配置データに基づいて、操作可能なＧＵＩ部品として認識された所定のＧＵＩ部品候補が配置される配置場所に関する見本配置データを生成する。

これにより、実施形態に係るデータ処理装置１００は、ＧＵＩ部品の画像部分の拡縮に対して頑健な操作認識を行うことができる。

また、実施形態に係るデータ処理装置１００は、操作イベントが発生した所定のウィンドウの画像から生成された配置データと、生成部１３２によって生成された見本配置データとを比較し、見本配置データから、この操作イベントが発生した位置に対応する配置場所を特定し、特定された配置場所に配置されたＧＵＩ部品が操作されたことを特定する特定部１３４を有する。

これにより、実施形態に係るデータ処理装置１００は、ウィンドウから操作ログを自動的に収集することができる。

また、実施形態に係るデータ処理装置１００において、生成部１３２は、配置データとして、ＧＵＩ部品候補の画像部分をノードで表現し、ＧＵＩ部品候補の画像部分の配置関係をエッジで表現するグラフ構造を生成する。また、実施形態に係るデータ処理装置１００において、認識部１３３は、生成部１３２によって生成された複数のグラフ構造を比較し、比較結果に基づいて、見本配置データとして、ＧＵＩ部品をノードで表現し、ＧＵＩ部品の配置関係をエッジで表現する見本グラフ構造を生成する。また、実施形態に係るデータ処理装置１００において、特定部１３４は、操作イベントが発生した所定のウィンドウの画像から生成されたグラフ構造と、見本グラフ構造との類似度を算出し、算出された類似度が閾値を満たす場合に、見本グラフ構造から、操作イベントが発生した位置に対応する配置場所を特定する。

これにより、実施形態に係るデータ処理装置１００は、操作ログを収集する仕組みをアプリケーションごとに開発することなく、共通的に操作ログを収集することができる。

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、本発明を特定の例に限定するものではない。本明細書に記載された特徴は、発明を実施するための形態の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で実施されることが可能である。

また、上述したデータ処理装置１００は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、認識部は、認識手段や認識回路に読み替えることができる。

１ 操作ログ取得システム
１００ データ処理装置
１１０ 通信部
１２０ 記憶部
１２１ 操作データ記憶部
１２２ 配置データ記憶部
１２３ 見本配置データ記憶部
１２４ ログデータ記憶部
１３０ 制御部
１３１ 取得部
１３２ 生成部
１３３ 認識部
１３４ 特定部
１３５ 判定部
１３６ 記録部
２００ 端末装置

Claims (7)

1. ウィンドウの複数の画像を取得する取得部と、
   前記取得部によって取得された複数の画像の各々から、ＧＵＩ部品候補の画像部分を抽出し、取得された画像ごとに、抽出された画像部分が配置される配置場所に関する配置データを生成する生成部と、
   前記生成部によって生成された複数の配置データについて、配置場所が互いに対応する所定のＧＵＩ部品候補の画像部分同士を比較し、当該所定のＧＵＩ部品候補の画像部分が互いに異なる場合に、当該所定のＧＵＩ部品候補を、操作可能なＧＵＩ部品として認識する認識部と
   を備えることを特徴とするデータ処理装置。
2. 前記生成部は、前記取得部によって取得された複数の画像から、同一のウィンドウの複数の画像を収集し、収集された各画像から、前記ＧＵＩ部品候補の画像部分を抽出し、収集された画像ごとに、前記配置データを生成する
   ことを特徴とする請求項１に記載のデータ処理装置。
3. 前記認識部は、前記複数の配置データに基づいて、操作可能なＧＵＩ部品として認識された前記所定のＧＵＩ部品候補が配置される配置場所に関する見本配置データを生成する
   ことを特徴とする請求項１又は２に記載のデータ処理装置。
4. 操作イベントが発生した所定のウィンドウの画像から生成された前記配置データと、前記生成部によって生成された見本配置データとを比較し、前記見本配置データから、当該操作イベントが発生した位置に対応する配置場所を特定し、特定された配置場所に配置されたＧＵＩ部品が操作されたことを特定する特定部をさらに備える
   ことを特徴とする請求項３に記載のデータ処理装置。
5. 前記生成部は、前記配置データとして、ＧＵＩ部品候補の画像部分をノードで表現し、ＧＵＩ部品候補の画像部分の配置関係をエッジで表現するグラフ構造を生成し、
   前記認識部は、前記生成部によって生成された複数のグラフ構造を比較し、比較結果に基づいて、前記見本配置データとして、ＧＵＩ部品をノードで表現し、ＧＵＩ部品の配置関係をエッジで表現する見本グラフ構造を生成し、
   前記特定部は、前記操作イベントが発生した前記所定のウィンドウの画像から生成された前記グラフ構造と、前記見本グラフ構造との類似度を算出し、算出された類似度が閾値を満たす場合に、前記見本グラフ構造から、前記操作イベントが発生した位置に対応する配置場所を特定する
   ことを特徴とする請求項４に記載のデータ処理装置。
6. コンピュータが実行するデータ処理方法であって、
   ウィンドウの複数の画像を取得する取得工程と、
   前記取得工程によって取得された複数の画像の各々から、ＧＵＩ部品候補の画像部分を抽出し、取得された画像ごとに、抽出された画像部分が配置される配置場所に関する配置データを生成する生成工程と、
   前記生成工程によって生成された複数の配置データについて、配置場所が互いに対応する所定のＧＵＩ部品候補の画像部分同士を比較し、当該所定のＧＵＩ部品候補の画像部分が互いに異なる場合に、当該所定のＧＵＩ部品候補を、操作可能なＧＵＩ部品として認識する認識部と
   を含むことを特徴とするデータ処理方法。
7. ウィンドウの複数の画像を取得する取得手順と、
   前記取得手順によって取得された複数の画像の各々から、ＧＵＩ部品候補の画像部分を抽出し、取得された画像ごとに、抽出された画像部分が配置される配置場所に関する配置データを生成する生成手順と、
   前記生成手順によって生成された複数の配置データについて、配置場所が互いに対応する所定のＧＵＩ部品候補の画像部分同士を比較し、当該所定のＧＵＩ部品候補の画像部分が互いに異なる場合に、当該所定のＧＵＩ部品候補を、操作可能なＧＵＩ部品として認識する認識手順と
   をコンピュータに実行させることを特徴とするデータ処理プログラム。

Images