操作予測装置及び操作予測方法
【課題】 ユーザのソフトウェア（システム）の実際の操作履歴と、システム開発者が想定するシステムの使用例とのマッチングを行って、実操作履歴を最もよく表現しているユースケースを決定し、それを元にユーザのシステム利用目的を推定と、次にとる操作を決定する。
【解決手段】 ユーザの利用目的に応じて、アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースのデータベースから複数のユースケース候補と、アプリケーションから次操作の予測の要求であるサービス要求に基づく依頼信号に基づいて、逐次入力されるユーザ操作から依頼時点での操作実績パスである依頼時実績パスと、を取得し、依頼時実績パスと複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力することとした。
【解決手段】 ユーザの利用目的に応じて、アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースのデータベースから複数のユースケース候補と、アプリケーションから次操作の予測の要求であるサービス要求に基づく依頼信号に基づいて、逐次入力されるユーザ操作から依頼時点での操作実績パスである依頼時実績パスと、を取得し、依頼時実績パスと複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力することとした。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザのシステム利用目的を推定し、次操作を予測して、ユーザへのガイダンス表示等に利用する操作予測装置及び操作予測方法に関するものである。
【背景技術】
【０００２】
近年のソフトウェア／システム開発では、上流設計において、そのシステムのターゲットとするユーザが、どのようにシステムを使用するのかについて検討する「ユースケース分析」フェーズがある。このフェーズでは、ユーザのシステムの使い方（ユースケース）を作成している。この分析結果はシステムの機能構成の設計に用いられている。つまり最終的に開発されるシステムは、この分析フェーズで挙げられたユースケースを実施するのに最適な機能構成となっているはずであり、各ユースケースは、実際に完成したシステムを利用する上で、最も効率的な利用手順を表していると考えることができる。従って、実際にユーザがシステムを利用している際に、ユーザがどのような目的で（何が行いたくて）操作をしているのかが判り、それを表したユースケースに従ってユーザを誘導すれば、そのシステムにとって最も効率の良い手順で、ユーザがシステムに望んでいる作業を実施させることが可能となる。
【０００３】
以下、ユーザどのような目的で（何が行いたくて）操作をしているのかを推定する手法の従来例について示す。
【０００４】
ネットショッピング等で広く利用されている商品レコメンダシステムは、不特定多数のユーザが利用するシステムである点を生かした技術である。レコメンダシステムでは、例えばあるユーザがネットショッピングサイトにていつかの商品の詳細を表示させると、「この商品を選択したユーザはこれらの商品も選択しています」というように、推薦商品を提示する。レコメンダシステムでは、操作予測を行いたい対象ユーザと同様な嗜好を持つ、他ユーザを過去のユーザ履歴データベースより抽出して、その同様な嗜好を持つ他ユーザの操作実績を元に、対象ユーザの操作・選択項目予測をして、操作や選択項目の提示を行っている。
【０００５】
しかし、レコメンダシステムにおいては、ユーザの利用目的自体を推定するのではなく、他ユーザの過去の操作実績が格納された知識ベースによりユーザを嗜好別に分類し、その典型例を基準に推薦項目を決定している。このため、Webブラウジングやネットショッピングのように、根本的にユーザの思いのままに自由に操作や商品選択ができる場合には有用だが、ある目的を持ったシステムの場合、そのシステムの正しい使用手順がユーザに的確に伝わらないと、通常は使い勝手が低下する。このため、ある目的を持ち、システムがその目的を実現するための最良の方法が存在する場合（正解がある場合）は、レコメンダシステムのような、統計的な手法だけでは正確な答えを得られる保証はなく、あらかじめシステム設計者などが最良の方法をシステムに保持させておく必要がある。
【０００６】
また、レコメンダシステムでは、既に他ユーザの操作実績が知識ベースとして保持されていないと、対象ユーザの推奨項目を提示できない。つまり、基本的に不特定多数のユーザが利用するシステムに限られてしまう点が問題点として挙げられる。このため、スタンドアローンシステムでの実装は難しいという問題もある。
【０００７】
一方、一連の機能から成り、ある程度決まった操作手順が存在する作業を実行するシステムには、その複雑な操作手順を、ユーザにとって簡単に実行できるように支援する技術としてウィザード機能がある。ウィザード機能では、ユーザは最初に利用目的を明示的に選択し、システムはあらかじめ用意された利用目的別の作業順序に従って、ユーザに必要な内容を問い合わせながら、一連の機能を実行していく。ウィザード機能は、例えば、複数ファイルを圧縮して自動解凍実行可能ファイル形式で保存する作業や、ハードウェアのパラメータ設定ソフトウェアにおいて、ハードウェアと通信するための各種設定を行う際に用いられる。
【０００８】
しかし、ウィザード機能は、ユーザにいくつかの選択肢は与えるものの、ほぼ決まった一連の操作にしか適用できないという問題がある。また通常はウィザード上の操作しかできなくなる（モーダルダイアログで実装される）ことが多いため、ウィザード機能実行中にユーザがウィザードを一時中断して他の作業を行うことはできず、ユーザ操作の自由度を狭めてしまうという問題もある。
【０００９】
システムを利用するユーザの利用目的を推定し、次の推奨操作を提示することを目的とする先行技術として、表示機器等の設定メニューに対するユーザ操作実績からベイズ定理を用いてユーザの意図を推定し、ユーザの次の推奨操作を表示するものがある（例えば、特許文献１参照）。
【００１０】
この文献によると、まずｎ個の操作目的Ｈｒ（ｒ＝１．．．ｎ）を設定し、ユーザがある操作目的Ｈｒで各機能項目Ｄｓ(ｓ＝１．．．ｍ)を操作する確率を示す事前確率Ｐ（Ｈｒ）をあらかじめ決定してシステムに記憶させておく。また操作目的Ｈｒごとに、その推奨操作もシステムに記憶させておく。実際のユーザが機能項目Ｄｓを選択するごとに、ベイズ定理を用い、操作目的Ｈｒのために各機能項目Ｄｓが選択される条件付確率Ｐ（Ｄｓ|Ｈｒ)と事前確率Ｐ（Ｈｒ）に基づいて、事後確率Ｐ（Ｈｒ｜Ｄｓ）を算出する。これを繰返し、事後確率Ｐ（Ｈｒ）があらかじめ決められた閾値を越えた場合に、Ｈｒを推定操作目的として推定し、その操作目的から推奨操作をユーザに提示できるとしている。
【００１１】
一方、階層構造を持つメニューの操作履歴から、ユーザが所望する具体的な機能を推定することを目的とする技術がある（例えば、特許文献２参照）。
【００１２】
この文献によると、まずシステムの持つ各機能へ至るための、ユーザによるメニュー選択操作列を定義し、ユーザの実操作で得た誤操作例と、各ケースにおける正解操作列とを関連付けたものを、知識ベースとしてあらかじめシステムに格納しておくことにより、実使用時にユーザが誤操作しても、正解操作列から、ユーザに操作手順を提示できるとしている。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−３１３４５４号公報
【特許文献２】特開２００８−１４６４５５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
特許文献１では、ベイズ推定を用いるため、少なくとも各操作目的Ｈｒ（ｒ＝１．．．ｎ）ごと、各機能項目Ｄｓ(ｓ＝１．．．ｍ)ごと、つまりｎ×ｍ個の事前確率Ｐ（Ｈｒ）をあらかじめ用意しておく必要がある。表示装置の設定メニューや家電製品などの場合は、システムが提供する機能ｍが比較的少ないため、事前確率決定が比較的容易だが、一般的な多機能なソフトウェアやシステムの場合は、この数の確率をあらかじめ用意しておくことは現実的でない。
【００１５】
さらにベイズ定理を用いた推定の精度は、事前確率と条件付確率Ｐ（Ｄｓ|Ｈｒ）のみに依存するため、この事前確率がある程度正確でなければ、有用な推定が行えない。このため、システムの実運用の前に、試使用を繰返すなどして、あらかじめ適当な精度を持つ事前確率を確定しておく必要があり、準備工数がかかるという問題もある。
【００１６】
また、推定操作目的を特定した後に推奨操作を提示するとしているが、一般的なソフトウェアの場合は、作業を行う際の操作の順序が複雑であることが多く、このユーザに的確な操作手順を提示することが重要となるため、この推奨操作の順序を明示的に定義できるような仕組みが必要である。
【００１７】
特許文献２では、ユーザが、システムによって提供される特定の機能を意識して、これを探していることが前提となっており、ユーザの目的は単一の機能の実行である。このため、システムの提供する複数の機能間の関係について、ユーザの操作を予測することができないという問題がある。
【００１８】
携帯電話のシステムを例とすると、特許文献２が提供できるのは、受信したメールを閲覧するために、ユーザがメニュー階層を試行錯誤している状況を感知して、その操作履歴から受信したメール閲覧がユーザの目的機能であると推定し、メール閲覧機能を実行するまでの操作をサポートすることである。システムはメール閲覧中に、やがてメール閲覧を終えたユーザが、そのメールに対して返信メールを編集することを予測することはできない。
【００１９】
この発明は上記のような問題点を解決するためになされたものであり、ある時点までのユーザのソフトウェア（システム）の実際の操作履歴と、システム開発者が想定するシステムの使用例が表現されたユースケースとのマッチングを行って、実操作履歴を最もよく表現しているユースケースを決定するとともに、そのユースケースを元にユーザのシステム利用目的を推定し、推定されたユーザのシステム利用目的を元に、ユースケースに従って、ユーザが次にとる「べき」操作（同時にユーザが次にとる「であろう」操作）を決定することを目的とする。
【課題を解決するための手段】
【００２０】
本発明は、アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースと、前記アプリケーションに対するユーザ操作であるＵＩリソースと、前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表と、逐次入力される前記ユーザ操作から前記ＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力する操作実績変換部と、前記操作実績変換部から入力された前記操作実績パスを格納する操作履歴ベースと、依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するとともに、前記依頼信号の内容である操作目的別に応じて、前記ユースケース知識ベースからユースケース候補を取得し、依頼時実績パスとすべてユースケース候補とから依頼時操作実績パスとの適合度を算出し、推定されるユーザのシステム利用目的と次操作の予測とを含む予測結果を出力するユースケース候補適合度算出部と、前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ前記依頼信号を出力するとともに、前記予測結果から、前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するインターフェースと、を備えたことを特徴とするものである。
【発明の効果】
【００２１】
本発明によれば、アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースと、前記アプリケーションに対するユーザ操作であるＵＩリソースと、前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表と、逐次入力される前記ユーザ操作から前記ＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力する操作実績変換部と、前記操作実績変換部から入力された前記操作実績パスを格納する操作履歴ベースと、依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するとともに、前記依頼信号の内容である操作目的別に応じて、前記ユースケース知識ベースからユースケース候補を取得し、依頼時実績パスとすべてユースケース候補とから依頼時操作実績パスとの適合度を算出し、推定されるユーザのシステム利用目的と次操作の予測とを含む予測結果を出力するユースケース候補適合度算出部と、前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ前記依頼信号を出力するとともに、前記予測結果から、前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するインターフェースと、を備えたので、ユーザのソフトウェア（システム）の実際の操作履歴と、システム開発者が想定するシステムの使用例が表現されたユースケースとのマッチングを行って、実操作履歴を最もよく表現しているユースケースを決定するとともに、そのユースケースを元にユーザのシステム利用目的を推定し、推定されたユーザのシステム利用目的を元に、ユースケースに従って、ユーザが次にとる「べき」操作（同時にユーザが次にとる「であろう」操作）を決定することができる。
【図面の簡単な説明】
【００２２】
【図１】実施の形態１における操作予測装置の構成図。
【図２】実施の形態１におけるＵＩリソース−モデル要素対応表１０３の例。
【図３】実施の形態１におけるユースケース知識ベース１０５に格納されるユースケース候補の例。
【図４】実施の形態１における図５の状態遷移図５００のモデル要素である状態と遷移を表に列挙したモデル要素一覧表である。
【図５】実施の形態１におけるｗｉｎｄｏｗｓ上でテキストファイルの編集とファイルへのシリアライズが可能なアプリケーションの状態遷移グラフ空間５００の例。
【図６】実施の形態１における図３におけるユースケース候補３００「新規ドキュメント編集保存」のグラフ構造を簡略化した図。
【図７】実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集更新」のグラフ構造図。
【図８】実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集コピー保存」のグラフ構造図。
【図９】実施の形態１における図５における状態遷移図５００の振舞いを持つアプリケーション１０１に対してユーザが行った操作履歴の例を示す図。
【図１０】実施の形態１における図９の操作履歴から作成した状態遷移のグラフ構造図。
【図１１】図１０におけるグラフ構造図を基に、操作実績パス１０００の最新からの道の長さとユースケース候補６００，７００，８００ごとに計算した適合度を示す図。
【発明を実施するための形態】
【００２３】
実施の形態１．
実施の形態１では、ユースケースを用いてユーザのシステム利用目的を推定し、次操作を予測して、ユーザへのガイダンス表示等に利用する操作予測装置について説明する。
【００２４】
図１は、実施の形態１における操作予測装置の構成図である。
【００２５】
まず、操作予測装置は、ユーザのシステム利用目的を推定し、次操作を予測する操作予測ユニット１００と、例えばｗｉｎｄｏｗｓ上で動作するソフトウェアや、あるいは制御システムを制御するソフトウェアなどの、操作項目を推定する対象となるアプリケーション１０１とから構成されている。
【００２６】
また、アプリケーション１０１は、ユーザインタフェース部１０８と連動しており、ユーザが、ユーザインタフェース部１０８を通じてアプリケーション１０１に対して操作を行う入力情報を操作予測ユニット１００に送ると共に、入力情報の履歴から得られた操作予測ユニット１００からのアプリケーション形式予測結果１２９をユーザインタフェース部１０８を通じて表示する。
【００２７】
次操作を予測する操作予測ユニット１００の構成について説明する。
操作予測ユニット１００は、インタフェース部１０２、ＵＩリソース−モデル要素対応表１０３、操作実績変換部１０４、ユースケース知識ベース１０５、ユースケース候補適合度算出部１０６、操作履歴ベース１０７から構成されている。
【００２８】
操作実績変換部１０４は、アプリケーション１０１から、アプリケーション１０１そのものの操作開始を知らせる機能開始トリガ１２２を受けとった後、アプリケーション１０１を通じて、ユーザインタフェース部１０８に入力されるアプリケーション１０１に対するユーザ操作１３０の取得を開始する。
【００２９】
また、操作実績変換部１０４は、ユーザインタフェース部１０８に逐次入力されるユーザ操作１３０を逐次受け取り、操作予測ユニット１００で後に、解析に利用する操作実績パス１２６を作成するために、各ユーザ操作１３０に使用されたＵＩリソースを、ＵＩリソース−モデル要素対応表１０３を用いて、各ユーザ操作１３０に使用されたＵＩリソースに対応する各モデル要素１２４を取得し、各モデル要素１２４の履歴に相当する操作実績パス１２６を生成してそれを格納するため、操作履歴ベース１０７へ送信する。
【００３０】
ＵＩリソース−モデル要素対応表１０３は、アプリケーション１０１のユーザインタフェース部１０８に入力されるユーザ操作１３０と、操作予測ユニット１００がユースケース知識ベース１０５や操作履歴ベース１０７に用いる、システム全体の振舞いを表すグラフ空間を構成するモデル要素１２４（グラフ要素）との間の変換テーブルである。このテーブルは、操作実績変換部１０４が、アプリケーション１０１のユーザインタフェース部１０８に対して行われたユーザ操作１３０を、操作予測ユニット１００で使用するモデル要素１２４へ変換する際に用いられる。また、操作予測ユニット１００が導き出した、ユーザのシステム利用目的や次操作の予測結果を、アプリケーション１０１で解釈できるＵＩリソースに対応する操作形式１２３に逆変換する際にも用いられる。上記変換テーブルについては後述する。
【００３１】
操作履歴ベース１０７は、操作実績変換部１０４から渡された、モデル要素１２４を時系列で連結した操作実績パス１２６を内部に格納しておく。この操作実績パス１２６はユースケース候補適合度算出部１０６によって、ユースケース候補を選出する際に利用される。
【００３２】
インタフェース部１０２は、アプリケーション１０１から、次操作の予測の要求であるサービス要求１２１を解釈し、サービス要求１２１の内容に従ってユースケース適合度算出部１０６を制御するための依頼信号１２５をユースケース適合度算出部１０６に送信する。
【００３３】
ユースケース候補適合度算出部１０６は、インタフェース部１０２からの依頼信号１２５を受けて、依頼時点での、操作履歴ベース１０７に格納されているモデル要素を時系列で連結した、依頼時操作実績パス１２８を取得する。一方で、あらかじめユースケース知識ベース１０５に格納されている、アプリケーション１０１の操作目的別に表現されたユースケース候補１２７を取得し、それぞれのユースケースについて、依頼時操作実績パス１２８との適合度を算出する。
【００３４】
ユースケース知識ベース１０５は、ユースケース候補適合度算出部１０６によって操作履歴ベース１０７との適合度を算出するためのユースケース候補１２７が格納される知識ベースである。ユースケース知識ベース１０５は、アプリケーション１０１を開発する際の上流設計で行われるユースケース分析フェーズで挙げられたアプリケーション１０１のユーザの利用目的に応じて、アプリケーション１０１の機能を満たすための操作履歴（ユースケース）を格納している。
【００３５】
その結果、依頼時操作実績パス１２８の操作履歴そのものを最もよく説明しているユースケース候補１２７を選出して、「推定されるユーザのシステム利用目的」として、予測結果１３１に含めてインタフェース部１０２へ返す。
【００３６】
また、操作履歴ベース１０７から取得した依頼時操作実績パス１２８から、アプリケーション１０１の状態を把握して、依頼時操作実績パス１２８最もよく説明しているユースケース候補１２７を辿って、次に遷移する内容と遷移先の情報を「次操作の予測」として、予測結果１３１に含めてインタフェース部１０２へ返す。詳細については後述する。
【００３７】
インタフェース部１０２はまた、ユースケース適合度算出部１０６によって導き出されたユーザのシステム利用目的や次操作に関する予測結果１３１を、アプリケーション１０１に理解できる形で返すため、ＵＩリソース−モデル要素対応表１０３で、モデル要素１２４の表現形式である次操作をＵＩリソースに対する操作形式１２３の形に変換し、アプリケーション形式予測結果１２９としてアプリケーション１０１に返却する。
【００３８】
次に、ＵＩリソース−モデル要素対応表１０３の詳細について説明する。
図２は、ＵＩリソース−モデル要素対応表１０３の例を示したものである。
【００３９】
２０１，２０３，２０４列は、アプリケーション１０１のユーザインタフェース部１０８に入力されるＵＩリソースの情報を表している。このうち実装が必要なのは２０４列のＩＤのみで、他は便宜上記したものであって、表２００内にはなくともよい。このＩＤは、例えばｗｉｎｄｏｗｓアプリケーションであれば、アプリケーション開発プロジェクトにリソースＩＤとして定義されているものや、キーボードからの入力コードなど、アプリケーションが持つ入力ＵＩの種類を特定するＩＤである。
【００４０】
一方の２０５列と２０６列は、ＵＩリソースの情報に対応させた、操作履歴ベース１０７やユースケース知識ベース１０５に格納される部分グラフを構成するモデル要素１２４を示している。尚、これらは後述する図４のモデル要素一覧表４００のうち、抽象レベルが１であるものである。
【００４１】
２０７列は、各モデル要素の種別を示し、「状態」か「遷移」を表すものである。
【００４２】
また、２０４列最下行の（編集操作キー入力）のように、ＵＩリソースＩＤからモデル要素ＩＤへの対応は一意である必要があるが、２０４列最下行の（編集操作キー入力）のように、モデル要素ＩＤからＵＩリソースＩＤへの対応は一意である必要はない。実際にアプリケーションを操作する際には、２０４列に列挙したＵＩリソースＩＤ以外の操作も数多く行われる。例えば「開く」ダイアログ上で行われる実際のユーザ操作は「開く」ボタン押下以外にもあるが、それらは、ユースケース知識ベース１０５内に定義されているユースケース群の中で定義されていないため、ＵＩリソース−モデル要素対応表１０３の対象とはならない。
【００４３】
ユースケース知識ベース１０５に格納されるユースケース候補は、アプリケーション１０１の開発の上流設計で用意できる内容であるが、ＵＩリソース−モデル要素対応表１０３は、アプリケーション１０１が完成し、そこで使用されるＵＩリソースＩＤが確定されてから作成する必要がある。
【００４４】
以下に、状態遷移図で表現されるアプリケーション１０１に、本特許の操作予測ユニット１００を適用する際、操作予測ユニット１００を実現する上であらかじめ用意されている必要がある２つの静的データ、ユースケース知識ベース１０５、ＵＩリソースモデル要素対応表１０３について説明する。
【００４５】
図５は、ｗｉｎｄｏｗｓ上でテキストファイルの編集とファイルへのシリアライズが可能なアプリケーションの状態遷移グラフ空間５００の例である。なお、この状態遷移グラフ空間５００の全体図は、アプリケーション１０１が操作予測ユニット１００のサービスを利用する際に、操作履歴ベース１０７に格納されていてもよいが、必ずしも用意されている必要はない。
【００４６】
図４は、図５の状態遷移図５００のモデル要素である状態と遷移を表に列挙したモデル要素一覧表４００である。ユースケース知識ベース１０５にユースケースを格納する時は、同時に、ユースケースで使用しているモデル要素の一覧表を定義しておく必要がある。
【００４７】
モデル要素一覧表４００のパラメータについて説明する。モデル要素は、列４０１に示した「状態」４１１と「遷移」４１２に分けられる。状態は状態遷移グラフ空間５００でいうノード、遷移はエッジにあたる。
【００４８】
列４０２に示したモデル要素ＩＤはＵＩリソース−モデル要素対応表１０３で参照されるＩＤである。このＩＤはモデル内で一意に定義される必要がある。４０３列の抽象レベルは、ユースケースが多重定義される際に意味を持つ値で、ＵＩリソース−モデル要素対応表１０３で参照されるＩＤは全て抽象レベルが１、つまりユースケースで使用されるモデル要素の抽象度としては最低値とする。４０４列は便宜上付けた列で、実際に操作予測ユニット１００を実現する際にはなくても良い。
【００４９】
図３は、ユースケース知識ベース１０５に格納されるユースケース候補の例を示したものである。ユースケース３００において、太線、太字、太枠にて示されているものは、図５の状態遷移図５００に示したアプリケーション１０１における「新規ドキュメント編集保存」のユースケースの例である。前述したようにこのユースケースは、アプリケーション開発の上流設計過程において、開発者が想定ユーザの典型的な使用方法を記述したものである。このユースケースでは、ユーザの利用目的として「ドキュメントを新規作成して編集して名前を付けてファイルへ保存する」という一連の操作の流れを定義している。以降、順に説明する。
【００５０】
図３において、まずアプリケーションが起動された状態では編集ウィンドウの編集なし・保存履歴なしの状態（Ａ）３０１である。ここで「新規作成」操作を行うと、４アプリケーション側では新しいドキュメントが生成される３２３。しかしユーザ操作上の状態遷移は行われず、状態は編集ウィンドウの編集なし・保存履歴なしの状態３０１のままである。それから５ドキュメントに対する編集作業３２０を行うと、編集の結果、状態は、編集ウィンドウの編集なし・保存履歴なしの状態（Ａ）３０１から、編集ウィンドウの編集あり・保存履歴なしの状態（Ｃ）３０３へ遷移する。その後に２ドキュメントをファイルへ保存するために「名前を付けて保存」操作３１５を行うと、「名前を付けて保存」ダイアログが表示され、状態も「名前を付けて保存」ダイアログ（Ｇ）３０７へ遷移する。最後に９「名前を付けて保存」ダイアログ内で「保存」ボタンが押下される３１４と、ダイアログを抜けて、編集ウィンドウの編集なし・保存履歴ありの状態（Ｂ）３０２へ遷移する。
【００５１】
このようにして「新規ドキュメント編集保存」のユースケースは、Ａ→４→Ａ→５→Ｃ→２→Ｇ→９→Ｂと表すことができる。このため、ユースケース知識ベース１０５には、図３の太線、太字、太枠にて示されているグラフ構造が表現できる形でユースケース候補が格納されていれば良く、その一例としては、モデル要素一覧表４００の種別４０１、モデル要素ＩＤ４０２及び記号４０５と具体的なユースケース候補を表現したシーケンス「Ａ→４→Ａ→５→Ｃ→２→Ｇ→９→Ｂ」などとなる。
【００５２】
以下、動作について図１に基づいて説明する。
まず、アプリケーション１０１の起動後の任意のタイミングで、アプリケーション１０１は、機能開始トリガ１２２を操作実績変換部１０４へ送る。このタイミングは、アプリケーション起動直後でなくても良いが、アプリケーションがユーザのアプリケーション利用目的と次操作予測結果を必要とする時点よりも前に行う。操作実績変換部１０４はこのトリガによって、アプリケーション１０１内にあるユーザインタフェース１０８に入力されるユーザの操作から、そのリソースＩＤを含むユーザ操作１３０の情報を取得して、逐次、その操作実績をモデル要素１２４へ変換する。この際に、操作実績変換部１０４はリソースＩＤと対応するモデル要素１２４を得るために、ＵＩリソース−モデル対応表１０３を参照する。
モデル要素１２４に変換された結果は、操作実績パス１２６として操作履歴ベース１０７へ格納される。
【００５３】
操作実績変換部１０４が、アプリケーション１０１に対するユーザ操作１３０を、逐次、モデル要素１２４へ変換し、操作履歴ベース１０７へ格納していく。操作履歴ベース１０７では、操作実績変換部１０４から送られ、ユーザ操作１３０から変換された操作実績パス１２６の個々の断片を時系列で接続し、依頼時操作実績パス１２８を作成する。
【００５４】
以上の状態が続いて、操作履歴ベース１０７内にある程度の長さの依頼時操作実績パス１２８ができあがった後に、アプリケーション１０１が、ユーザのアプリケーション操作目的を知りたいタイミングや、ユーザの次操作予測を行いたいタイミングで、インタフェース部１０２へサービス要求１２１を発信する。インタフェース部１０２は要求の内容を解釈して、ユースケース候補適合度算出部１０６へ機能の実行を指示する依頼信号１２５を送信する。
【００５５】
これを受けて、ユースケース候補適合度算出部１０６は、まず、その時点での操作履歴ベース１０７に格納されている依頼時操作実績パス１２８を取り出す。そして、その依頼時操作実績パス１２８を基準として、ユースケース知識ベース１０５内にある全てのユースケース候補１２７を対象として、適合度を計算していく。
【００５６】
次にユースケース適合度算出部１０６によって、ユースケース知識ベース１０５内のユースケース候補それぞれについて、操作履歴ベース１０７の実績パスとどの程度合致しているかを表す適合度が計算される。
【００５７】
以下は、ユースケース適合度算出部１０６内で行う適合度の計算過程について説明する。
【００５８】
まず操作履歴ベース１０７から取得した依頼時操作実績パス１２８を解釈し、最初のステップでは、依頼時操作実績パス１２８中の最新のモデル要素１２４から過去に遡って長さ１の道、すなわち「状態」−「遷移」−「状態」を含むモデル要素１２４の履歴について、全てのユースケース候補１２７との適合度を計算する。図３にて説明した状態遷移図の場合だと、「Ｇ→９→Ｂ」の部分に相当する。
【００５９】
次にもう一つ遡って、実績パスの最新のモデル要素から長さ２の道について適合度を計算する。すなわち、「状態」−「遷移」−「状態」−「遷移」−「状態」を含むモデル要素１２４の履歴であり、図３の場合だと、「Ｃ→２→Ｇ→９→Ｂ」の部分に相当する。
【００６０】
更に、と１つずつ「遷移」を過去に遡り、それぞれについて、ユースケース知識ベース１０５内のユースケース候補の適合度を算出しておく。
【００６１】
いくつ前の履歴まで遡るかについては、予め定義された長さとしてもよいし、アプリケーション１０１から機能開始トリガ１２２が送られた時からとしてもよい。またアプリケーション１０１からインタフェースに送られるサービス要求時のパラメータとしてもよい。
【００６２】
ユーザの操作実績とユーザの目的を考えると、現時点のユーザの目的は、一般的に過去の操作のうち、その時間軸的な距離が近いものに大きな影響を与えると考えられる。従って、先に計算しておいた、長さ１，２，３．．．の実績パスの部分グラフのそれぞれについて、長さが短い道に対する適合度については大きな重みをつけ、長さが長い道については小さな重みをつけて、全ての実績パスの部分グラフに関する適合度を合計して、総合適合度を計算する時間的局所性を考慮した適合度の計算方法をとる。
【００６３】
この結果得られた最も適合度の高いユースケース候補１２７を、ユーザの目的を表しているユースケースであると推定する。
【００６４】
図１に戻って説明する。
【００６５】
ユースケース候補適合度算出部１０６は、この最適合ユースケースを含む予測結果１３１をインタフェース部１０２へ返す。
【００６６】
また、この時に、操作履歴ベース１０７からアプリケーション１０１上の現時点の状態が判明する場合は、現時点の「状態」を表すモデル要素１２４のＩＤを予測結果１３１に含めてインタフェース部１０２へ渡す。
【００６７】
最後にインタフェース部１０２がＵＩリソース−モデル要素対応表１０３を用いて、ユースケース候補適合度算出部１０６から取得した予測結果１３１に含まれる最適合ユースケースと、現時点のアプリケーション１０１上の「状態」を示すモデル要素１２４を、モデル要素からＵＩリソースのＩＤの形に逆変換する。この時、ＵＩリソース−モデル要素対応表のＵＩリソースＩＤとモデル要素ＩＤがｎ対１の関係であるため、変換後のＩＤが特定できないケースもある。その場合はモデル要素と１対１に関連づいた文字列リソースなどをあらかじめ定義しておき、モデル要素のＩＤのままでユーザへのガイダンス等が可能なように実装することもできる。そしてＵＩリソースのＩＤの形に逆変換された最適合のユースケースと、最適合ユースケースに基づいて現在の状態から次操作に関連づいたＵＩリソースＩＤとをアプリケーション形式予測結果１２９としてアプリケーション１０１へ提供する。
【００６８】
以下、実例を元に動作を説明する。
図６は、実施の形態１における図３におけるユースケース候補３００「新規ドキュメント編集保存」のグラフ構造を簡略化したものである。
【００６９】
図７は、実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集更新」のグラフ構造図である。
【００７０】
図７におけるユースケース候補「既存ファイル編集更新」状態遷移は、「Ａ→３→Ｅ→６→Ｂ→５→Ｄ→１→Ｂ」のようになる。
【００７１】
図８は、実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集コピー保存」のグラフ構造図である。
【００７２】
図８におけるユースケース候補「既存ファイル編集コピー保存」状態遷移は、「Ａ→３→Ｅ→６→Ｂ→５→Ｄ→２→Ｇ→９→Ｂ」のようになる。
【００７３】
以降、ユースケース知識ベース１０５内には、この３つのユースケース候補１２７があらかじめ入っているものとして説明する。
【００７４】
次に操作履歴ベース１０７の説明を行うため、アプリケーション１０１を使用するユーザの操作履歴を仮定する。
【００７５】
図９は、図５における状態遷移図５００の振舞いを持つアプリケーション１０１に対してユーザが行った操作履歴の例９００を示している。９０１列の順序で、９０２列にある対象の操作が行われたとする。ユーザインタフェース部１０８では、ＵＩリソースＩＤとして９０４列のＩＤが特定できる。このような操作入力が行われると、操作実績変換部１０４はＵＩリソース−モデル要素対応表１０３を参照して、各ＵＩリソースＩＤに対応するモデル要素ＩＤを取得する。その結果、９０５列のモデル要素ＩＤが得られる。
【００７６】
この時、順序３番目のＵＩリソースＩＤに対するモデル要素ＩＤが存在せず、その前後の状態は同じであるため、３の操作は無視される。この結果、操作予測ユニット１００として扱うユーザ操作１３０の履歴は、９０６列の記号でＡ→４→Ａ→３→Ｅ→６→Ｂとなる。
図１０は、図９の操作履歴から作成した状態遷移のグラフ構造図であり、図９のユーザの操作履歴９００を、図６〜８と同様、グラフ構造に示したものである。
【００７７】
次に、ユースケース候補適合度算出部１０６において算出される適合度の計算例に関して説明する。以上に記したように、ユースケース候補適合度算出部１０６にて行われる適合度計算は、図１０における操作実績パス１０００に対する適合度を、図６、図７、図８に示したユースケース候補６００，７００，８００それぞれについて算出することに他ならない。ここでは操作実績パス１０００の時間的局所性を考慮したユースケース候補の適合度計算方法について説明する。
【００７８】
まず、操作実績パス１０００を時系列にみて最新の状態Ｂとその直前の状態Ｅ、さらにその間を遷移する６のモデル要素から成る長さ１の道として考える。この道（Ｅ→６→Ｂ）に対する各ユースケース候補６００，７００，８００の適合度を求める。さらにその次には、一つ過去に遡り、道（Ｅ→６→Ｂ）に対する適合度を求める。さらに一つ遡って、道（Ａ→４→Ａ→３→Ｅ→６→Ｂ）つまり実績パス全体についての適合度を求める。このようにして実績パスを複数に分割したものとユースケース候補を比較して、それぞれの適合度に対する重み付けを変更させることで、ユーザ目的の時間的局所性を考慮した比較が行える。
【００７９】
実際の適合度計算方法は、一般的なグラフ理論で行われる２つのグラフのマッチングで行う場合や、２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用し、適合度の計算する場合があげられる。
例えば、２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用する場合では、操作実績パス１０００の道の長さごとである（Ｅ→６→Ｂ）、（Ｅ→６→Ｂ）、（Ａ→４→Ａ→３→Ｅ→６→Ｂ）の各々に対し、各ユースケース候補６００，７００、８００とのレーベンシュタイン距離（編集距離）を求め、それを負の相関とした適合度の値を求めることができる。また、エッジ（遷移）とノード（状態）の２つに分けて各々、各ユースケース候補６００，７００、８００とのレーベンシュタイン距離（編集距離）を求め、その各々の距離に対して負の相関とした評価値（一致割合）を求めて、それぞれを加算することで適合値とすることもできる。
【００８０】
以下では、一般的なグラフ理論で行われる２つのグラフのマッチングで行う場合であって、単純にエッジ（遷移）とノード（状態）の２つに分けて、適合度を計算する方法について説明する。
図１１は、図１０におけるグラフ構造図を基に、操作実績パス１０００の最新からの道の長さごとにとユースケース候補６００，７００，８００ごとに計算した適合度を示す図である。
【００８１】
まず表１１００の実績パス１１０１欄に示された、道の長さが１の実績パス（Ｅ→６→Ｂ）に対して、１１０２欄に示されたユース知識ベース１０５にあらかじめ記憶された各ユースケース候補６００，７００，８００の適合度を求める。
【００８２】
総数のエッジ１１０３欄、ノード１１０４欄は、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）が持つエッジ、ノード数をそれぞれ示している。
【００８３】
一致エッジ数１１０５欄は、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）に対して、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつエッジ（６のみ）が一致している個数を示し、一致エッジ率１１０６欄が、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）が各々もつエッジ数に対する、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつエッジ（６のみ）の一致率を示している。
【００８４】
ノードについても同様に、一致ノード数１１０７欄は、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）に対して、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつノード（Ｅ，Ｂ）が一致している個数を示し、一致エッジ率１１０６欄が、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）が各々もつノード数に対する、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつノード（Ｅ，Ｂ）の一致率を示している。
【００８５】
重み１１０９欄は、道の長さごとに実績パスに対して重みが設定されている。
【００８６】
適合度計算例１１１０欄は、各ユースケース候補の適合度を算出した結果を示したものである。ここでは一例として、エッジの一致数とエッジの一致率とノードの一致率を単純に加えて、それぞれ重みを乗じたものを適合度計算例としている。
【００８７】
同様に、道の長さが２の操作実績パス（Ａ→３→Ｅ→６→Ｂ）に対する適合度と、長さ３の操作実績パス（Ａ→４→Ａ→３→Ｅ→６→Ｂ）に対して適合度が各々計算されている。
【００８８】
最後に３つの実績パスのケースを、ユースケース候補１２７ごとに全て加算して、ユースケース候補６００「新規ドキュメント編集保存」が適合度６．５、ユースケース候補７００「既存ファイル編集更新」が適合度２６．７５、ユースケース候補８００「既存ファイル編集コピー保存」が適合度２４．６となる。
【００８９】
この結果、図７ユースケース候補７００の「既存ファイル編集更新」が最適合ユースケースと判定される。また、現時点の「状態」を表すモデル要素１２４のＩＤ（図４における記号Ｂに相当するモデル要素のＩＤはＭ＿ＳＴ＿ＥＤＩＴＷＩＮ＿Ｈであり、この二つの情報を含む予測結果１３１が図１におけるインタフェース部１０２へ返される。
最後に図１におけるインタフェース部１０２がＵＩリソース−モデル要素対応表１０３を用いて、ユースケース候補適合度算出部１０６から取得した予測結果１３１に含まれる最適合ユースケースと、現時点のアプリケーション１０１上の「状態」を示すモデル要素１２４を、モデル要素からＵＩリソースのＩＤの形に逆変換する。
【００９０】
そしてＵＩリソースのＩＤの形に逆変換された最適合のユースケースと、最適合ユースケースに基づいて現在の状態から次操作に関連づいたＵＩリソースＩＤとをアプリケーション形式予測結果１２９としてアプリケーション１０１へ提供する。このようにすることで、アプリケーションは再適合のユースケース「既存ファイル編集更新」に基づいて、図７におけるモデル要素Ｂの次の「遷移」に相当する５、図４におけるモデル要素Ｍ＿ＥＤＩＤＯＣにあたる、ＵＩリソースである図２の意味における「編集ウィンドウ 編集」をユーザに示すことができる。
【００９１】
以下、ユースケースを利用した場合のメリットについて記載する。尚、一般的なグラフ理論で行われる２つのグラフのマッチングで適合度の計算する場合や、２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用し、適合度の計算する場合の両方に適用できることである。
≪ユースケースの無順序表現≫
ユースケースでは順序が問われる手順と順序が問われない手順を表現できる。
【００９２】
システムを使用してある作業を行う場合に、通常は作業を構成する操作の実施手順が一意に決まるが、作業全体や作業の一部分によっては、作業を構成する操作間の順序関係が問われないケースもある。例えば編集したファイルに名前を付けて保存する際に、保存ダイアログ上でユーザは、保存ファイル名を指定することと保存ファイルフォーマットを選択することの順序は問われない。保存ボタンを押下する時点で、両操作が既に実施されていれば問題ない。ユースケースでは、この無順序条件を表現することができる。例えば、上記実例においても、適合度を計算する際に、長さによる重みづけという係数とするだけで、順序については考慮がなされていない。
【００９３】
グラフ空間の例として、各操作手順の関係がエッジで表現されているような状態遷移図を考えると、順序関係が問われる場合は有向エッジによって状態間の関係を表し、順序関係が問われない場合は、それらの状態間は無向エッジによって表す方法がある。またダイアログ内の選択項目など、単純なデータ構造に対する設定については、それぞれを状態として定義するのではなく、フラグや遷移チェック表を使用するなどの方法を取ることもできる。
【００９４】
≪ユースケースの分岐遷移定義≫
ユースケースは分岐を含む部分グラフとして表現できる。
【００９５】
システムでは似た目的の機能が存在しており、それらの操作手順は必ずしも一致しない。その似た機能を実行するユースケースを定義する場合、ユースケース内に分岐部分が発生する可能性がある。このため、一般的にユースケースを表す部分グラフは道ではなく、分岐を含む形となる。例えば「ファイルに上書き保存する」と「ファイルに名前を付けて保存する」という２つのユースケースを別々に定義する場合は良いが、これらをまとめて「ファイルに保存する」というユースケースを定義したい（その粒度でユーザの目的を推定したい）場合には、そのユースケースとして、前述の２つのユースケースを表す２つの部分グラフの和を取ったものを定義することで対応可能である。
その場合、定義の範囲が広いユースケースは、定義の範囲が狭いユースケースよりも評価値が低く算出されてしまう傾向はでるが、広く「ファイルに保存する」というユースケースを定義することでも、それなりの評価値を当該ユースケースに与えることができる。
≪ユースケースの個別抽象度表現≫
ユースケースを表す部分グラフの構成要素（ノード、エッジ）は、それぞれ個別の抽象度を持つことができる。
【００９６】
例えば「ファイルに名前を付けて保存」というユースケースを状態遷移図で表す場合、ユーザ操作の粒度（抽象度が最も低い状態）での操作手順を、ユースケースとして定義することもできるが、名前を付けるために表示されるダイアログ上での各種設定や状態遷移は考慮せず、ダイアログが表示されたことだけに注目するユースケース定義を行いたい場合には、「名前を付けて保存ダイアログ表示」という状態のみを用意して、ダイアログ上での操作は抽象化（グラフ理論的には状態遷移エッジの縮約）を行って定義することもできる。
【００９７】
なお後述するが、本発明で対象とするシステムでは、実績パス部分グラフの抽象度が最低である場合とした。なぜなら実績パス以下の抽象度（実績パス以上の詳細）ではユーザの操作を検出できないためである。
【００９８】
≪時間的局所性を考慮したユースケース候補評価≫
実績パスの比較時点のノード（有向エッジを追っていった最後のノード）を基点として、実績パスのグラフ要素それぞれについて、時間的距離と不の相関を持つ重みを付けてグラフ構造による比較を行う。一般的にユーザの操作は判定時（現在）に時間的に近い操作の方が、判定時のユーザの利用目的に大きな影響を与えていると考えられるため、現時刻からの時間的距離と負の相関を持った重み付けを行って比較を行うことで、ユーザ目的の時間的局所性を考慮した比較が行える。
【００９９】
≪ユースケースの多重定義≫
ユースケースはその定義において、他のユースケースを参照することができる。
【０１００】
ユースケースの定義方法として、システムの利用開始から終了までの一連の操作を全て１つのユースケースに表現する方法もあるが、通常、複数のユースケースを定義する上では、冗長な部分が多く存在するため、多重なユースケース定義を可能とし、他ユースケースを参照して定義したものを新たなユースケースとして定義することができる。
【０１０１】
これにより、例えば、文書作成ソフトウェアにおいて、特定の箇所の文書をコピーして、他の箇所へ貼り付けしたい場合、「クリップボードへコピー」というユースケースによって、当該文書の選択とクリップボードへの貼り付けを行い、別の「クリップボードから貼り付け」というユースケースによって、目的位置への貼り付け作業を定義する。そして「文書コピー」というユースケースで、これら２つのユースケースを参照することもできる。つまり、各々の個別操作のユースケースを多重して長い操作のユースケースとして独自に登録しておくことで、別に独自のユースケース定義を作らなくても、すでにある複数のユースケース定義を多重した独自のユースケース定義を作ることで、参照して評価することが可能となる。したがって、図１におけるユースケース知識ベースのデータ量の圧縮化を図ることができる。
【０１０２】
≪グラフ構造によるユースケース候補評価≫
適合度算出の他のやり方として、ユースケース候補と実績パスの２つの部分グラフのトポロジについて、純粋にグラフ理論的な比較を行う。例えば、ユースケース候補と実績パスを、ノード集合とエッジ集合に分割して、それぞれマッチしている要素数、集合内の全要素数とマッチしている要素数との割合、等のパラメータで比較して、それらを総合して適合度を算出することもできる。又は２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用し、適合度の計算に用いることもできる。
【０１０３】
≪異なる抽象度を考慮した評価≫
ユースケース候補を表現する部分グラフの各要素は、抽象度が一定でない可能性がある。一方で実績パス部分グラフの抽象度は常に最低である。このため、抽象度の異なる部分グラフ同士を比較する必要が生じる。この比較に関しては、ユースケース候補の各比較部分について、実績パスの抽象度との相対的な抽象度と不の相関を持つ重み付け比較を行う。
【０１０４】
一般的に、グラフ構造の比較を行った場合、抽象度の低いもの同士について厳密な比較を行うよりも、抽象度の低いものと高いものについて大まかな比較を行う方が、適合度が高くなるためである。（抽象度は相対的で離散的な値しかとれない）
以下例示にて説明する。
【０１０５】
例えば２つのユースケースＡ，Ｂがあり、両方とも以下のようにユースケースの途中に、ファイルに名前を付けて保存する部分を含んでいるとする。以下のｎ，ｍ，ｐはユースケースの順序（ステップ）を表している。
１ユースケースＡ（抽象度低）の場合
ｎ−１：．．．
ｎ ：メニューの「ファイルー名前を付けて保存」選択
（→「名前を付けて保存」ダイアログ表示状態に遷移）
ｎ＋１：表示された「名前を付けて保存」ダイアログ内で保存先フォルダ選択
（→「保存先フォルダ選択済み」状態に遷移）
ｎ＋２：同上のダイアログ内でファイル名入力
（→「ファイル名入力済み」状態に遷移）
ｎ＋３：同上のダイアログ内でファイルの種類選択
（→「ファイル種類選択済み」状態に遷移）
ｎ＋４：同上のダイアログ内で「保存」ボタン押下
ｎ＋５：．．．
【０１０６】
２ユースケースＢ（抽象度高）の場合
※ユースケースＡにある「保存先フォルダ選択済み」「ファイル名入力済み」「ファイル種類選択済み」の各状態は「名前を付けて保存」ダイアログ表示に縮約されている
ｍ−１：．．．
ｍ ：メニューの「ファイルー名前を付けて保存」選択
（→「名前を付けて保存」ダイアログ表示状態に遷移）
ｍ＋１：表示された「名前を付けて保存」ダイアログ内で「保存」ボタン押下
ｍ＋２：．．．
【０１０７】
ユースケースＡでは、名前を付けて保存ダイアログ内の操作に関しても手順を明確に定義していますが、Ｂではダイアログ内については抽象化している。これらは、ユースケース定義者が「どこに重きを置いてユースケース定義をしているか？」により、いずれが間違いというわけではない。
つまり、ユースケースＢ（抽象度高）において、ユースケースＡにある「保存先フォルダ選択済み」「ファイル名入力済み」「ファイル種類選択済み」の各状態は「名前を付けて保存」ダイアログ表示に縮約されている。
【０１０８】
ユーザの行った操作（実績パス）が、以下であったする。
３実績パス（抽象度最低）
ｐ−１：．．．
ｐ ：メニューの「ファイルー名前を付けて保存」選択
ｐ＋１：表示された「名前を付けて保存」ダイアログ内でファイル名入力
ｐ＋２：同上のダイアログ内で「保存」ボタン押下
ｐ＋３：．．．
【０１０９】
そして、評価する過程において、抽象度の低い（操作を厳密に定義している）ユースケースＡに注目すると、実績パスのステップｐに相当するのはステップｎである。しかしｐ＋１に相当するのはｎ＋２であり、またｐ＋２に相当するのはｎ＋４と、ステップｎ＋１とｎ＋３が抜けてしまっており、その分、評価値が低くなる。
一方、抽象度の高いユースケースＢに注目すると、実績パスのステップｐに相当するのはステップｍである。そしてｐ＋１に相当するものはないものの、Ｐ＋１はユースケースＢの「名前を付けて保存」ダイアログ表示状態において遷移を伴わない操作として無視される。そしてステップｐ＋２に相当するのがステップｍ＋１となり、抽象度の違いを別とすれば、ユースケースＢのステップｍ〜ｍ＋１は、実績パスのｐ〜ｐ＋２までと完全に一致していると判断され、評価値が高くなる。
【０１１０】
したがって、このユースケースの抽象度の高低による評価値の傾向を打ち消すよう、実績パスの抽象度との相対的な抽象度と不の相関を持つ重み付け比較を行うことで、異なる抽象度であってもユースケースによる評価を行うことができる。
【０１１１】
≪ユースケース候補の無順序条件部分の評価≫
比較部分が無順序表現されている場合は、相対的に重みを軽くして比較する
ユースケース候補の特定箇所が無順序条件である場合、同じグラフ構造で順序条件があるユースケース候補とくらべると、上記抽象度の場合と同様に、操作順序という制約がない分、比較制約が甘いため実績パスと一致しやすい傾向が出て、評価値が高くなる傾向がある。このため、無順序条件が設定されている部分については、順序条件が設定されている場合と比較して、重みを低く設定して比較を行うことで、無順序条件であってもユースケースによる評価を行うことができる。
【０１１２】
したがって、本実施の形態では、アプリケーション１０１に対するユーザの利用目的に応じて、アプリケーション１０１の機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素１２４及びその組み合わせであるユースケースとし、ユースケースを複数蓄積したデータベースであるユースケース知識ベース１０５と、アプリケーション１０１に対するユーザ操作１３０であるＵＩリソースと、モデル要素１２４との対応を示すデータベースであるＵＩリソース−モデル要素対応表１０３と、逐次入力されるユーザ操作１３０からＵＩリソース−モデル要素対応表１０３を用いてモデル要素１２４を取得し、モデル要素１２４の時系列の履歴である操作実績パス１２６を生成して出力する操作実績変換部と１０４、操作実績変換部１０４から入力された操作実績パス１２６を格納する操作履歴ベース１０７と、依頼信号１２５に基づいて、依頼時点での操作実績パスである依頼時実績パス１２８を操作履歴ベース１０７から取得するとともに、依頼信号１２５の内容である操作目的別に応じて、ユースケース知識ベース１０５からユースケース候補１２７を取得し、依頼時実績パス１２８とすべてユースケース候補１２７とから依頼時操作実績パス１２８との適合度を算出し、推定されるユーザのシステム利用目的と次操作の予測とを含む予測結果１３１を出力するユースケース候補適合度算出部１２７と、アプリケーション１０１から次操作の予測の要求であるサービス要求１２１を解釈して、サービス内容に従ってユースケース候補適合度算出部１０６へ依頼信号１２５を出力するとともに、予測結果１３１から、ＵＩリソース−モデル要素対応表１０３を用いてアプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果１３１としてアプリケーション１０１へ出力するインターフェース１０２とを備えたことにより、システム開発の上流設計に検討するユースケースをベースにユーザの実操作履歴との照合を行うことにより、実際にユーザがシステムを利用している際に、ユーザがどのような目的で（何が行いたくて）操作をしているのかが判り、それを表したユースケースに従ってユーザを誘導すれば、そのシステムにとって最も効率の良い手順で、ユーザがシステムに望んでいる作業を実施させることが可能となる。
【符号の説明】
【０１１３】
１００ 操作予測ユニット
１０１ アプリケーション
１０２ インターフェース部
１０３ ＵＩリソースモデル要素対応表
１０４ 操作実績変換部
１０５ ユースケース知識ベース
１０６ ユースケース候補適合度算出部
１０７ 操作履歴ベース
１０８ ユーザインターフェース部
１２１ サービス要求
１２２ 機能開始トリガ
１２３ ＵＩリソースに対する操作形式
１２４ モデル要素
１２５ 依頼信号
１２６ 操作実績パス
１２７ ユースケース候補
１２８ 依頼時操作実績パス
１２９ アプリケーション形式予測結果
１３０ ユーザ操作
１３１ 予測結果
【技術分野】
【０００１】
本発明は、ユーザのシステム利用目的を推定し、次操作を予測して、ユーザへのガイダンス表示等に利用する操作予測装置及び操作予測方法に関するものである。
【背景技術】
【０００２】
近年のソフトウェア／システム開発では、上流設計において、そのシステムのターゲットとするユーザが、どのようにシステムを使用するのかについて検討する「ユースケース分析」フェーズがある。このフェーズでは、ユーザのシステムの使い方（ユースケース）を作成している。この分析結果はシステムの機能構成の設計に用いられている。つまり最終的に開発されるシステムは、この分析フェーズで挙げられたユースケースを実施するのに最適な機能構成となっているはずであり、各ユースケースは、実際に完成したシステムを利用する上で、最も効率的な利用手順を表していると考えることができる。従って、実際にユーザがシステムを利用している際に、ユーザがどのような目的で（何が行いたくて）操作をしているのかが判り、それを表したユースケースに従ってユーザを誘導すれば、そのシステムにとって最も効率の良い手順で、ユーザがシステムに望んでいる作業を実施させることが可能となる。
【０００３】
以下、ユーザどのような目的で（何が行いたくて）操作をしているのかを推定する手法の従来例について示す。
【０００４】
ネットショッピング等で広く利用されている商品レコメンダシステムは、不特定多数のユーザが利用するシステムである点を生かした技術である。レコメンダシステムでは、例えばあるユーザがネットショッピングサイトにていつかの商品の詳細を表示させると、「この商品を選択したユーザはこれらの商品も選択しています」というように、推薦商品を提示する。レコメンダシステムでは、操作予測を行いたい対象ユーザと同様な嗜好を持つ、他ユーザを過去のユーザ履歴データベースより抽出して、その同様な嗜好を持つ他ユーザの操作実績を元に、対象ユーザの操作・選択項目予測をして、操作や選択項目の提示を行っている。
【０００５】
しかし、レコメンダシステムにおいては、ユーザの利用目的自体を推定するのではなく、他ユーザの過去の操作実績が格納された知識ベースによりユーザを嗜好別に分類し、その典型例を基準に推薦項目を決定している。このため、Webブラウジングやネットショッピングのように、根本的にユーザの思いのままに自由に操作や商品選択ができる場合には有用だが、ある目的を持ったシステムの場合、そのシステムの正しい使用手順がユーザに的確に伝わらないと、通常は使い勝手が低下する。このため、ある目的を持ち、システムがその目的を実現するための最良の方法が存在する場合（正解がある場合）は、レコメンダシステムのような、統計的な手法だけでは正確な答えを得られる保証はなく、あらかじめシステム設計者などが最良の方法をシステムに保持させておく必要がある。
【０００６】
また、レコメンダシステムでは、既に他ユーザの操作実績が知識ベースとして保持されていないと、対象ユーザの推奨項目を提示できない。つまり、基本的に不特定多数のユーザが利用するシステムに限られてしまう点が問題点として挙げられる。このため、スタンドアローンシステムでの実装は難しいという問題もある。
【０００７】
一方、一連の機能から成り、ある程度決まった操作手順が存在する作業を実行するシステムには、その複雑な操作手順を、ユーザにとって簡単に実行できるように支援する技術としてウィザード機能がある。ウィザード機能では、ユーザは最初に利用目的を明示的に選択し、システムはあらかじめ用意された利用目的別の作業順序に従って、ユーザに必要な内容を問い合わせながら、一連の機能を実行していく。ウィザード機能は、例えば、複数ファイルを圧縮して自動解凍実行可能ファイル形式で保存する作業や、ハードウェアのパラメータ設定ソフトウェアにおいて、ハードウェアと通信するための各種設定を行う際に用いられる。
【０００８】
しかし、ウィザード機能は、ユーザにいくつかの選択肢は与えるものの、ほぼ決まった一連の操作にしか適用できないという問題がある。また通常はウィザード上の操作しかできなくなる（モーダルダイアログで実装される）ことが多いため、ウィザード機能実行中にユーザがウィザードを一時中断して他の作業を行うことはできず、ユーザ操作の自由度を狭めてしまうという問題もある。
【０００９】
システムを利用するユーザの利用目的を推定し、次の推奨操作を提示することを目的とする先行技術として、表示機器等の設定メニューに対するユーザ操作実績からベイズ定理を用いてユーザの意図を推定し、ユーザの次の推奨操作を表示するものがある（例えば、特許文献１参照）。
【００１０】
この文献によると、まずｎ個の操作目的Ｈｒ（ｒ＝１．．．ｎ）を設定し、ユーザがある操作目的Ｈｒで各機能項目Ｄｓ(ｓ＝１．．．ｍ)を操作する確率を示す事前確率Ｐ（Ｈｒ）をあらかじめ決定してシステムに記憶させておく。また操作目的Ｈｒごとに、その推奨操作もシステムに記憶させておく。実際のユーザが機能項目Ｄｓを選択するごとに、ベイズ定理を用い、操作目的Ｈｒのために各機能項目Ｄｓが選択される条件付確率Ｐ（Ｄｓ|Ｈｒ)と事前確率Ｐ（Ｈｒ）に基づいて、事後確率Ｐ（Ｈｒ｜Ｄｓ）を算出する。これを繰返し、事後確率Ｐ（Ｈｒ）があらかじめ決められた閾値を越えた場合に、Ｈｒを推定操作目的として推定し、その操作目的から推奨操作をユーザに提示できるとしている。
【００１１】
一方、階層構造を持つメニューの操作履歴から、ユーザが所望する具体的な機能を推定することを目的とする技術がある（例えば、特許文献２参照）。
【００１２】
この文献によると、まずシステムの持つ各機能へ至るための、ユーザによるメニュー選択操作列を定義し、ユーザの実操作で得た誤操作例と、各ケースにおける正解操作列とを関連付けたものを、知識ベースとしてあらかじめシステムに格納しておくことにより、実使用時にユーザが誤操作しても、正解操作列から、ユーザに操作手順を提示できるとしている。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−３１３４５４号公報
【特許文献２】特開２００８−１４６４５５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
特許文献１では、ベイズ推定を用いるため、少なくとも各操作目的Ｈｒ（ｒ＝１．．．ｎ）ごと、各機能項目Ｄｓ(ｓ＝１．．．ｍ)ごと、つまりｎ×ｍ個の事前確率Ｐ（Ｈｒ）をあらかじめ用意しておく必要がある。表示装置の設定メニューや家電製品などの場合は、システムが提供する機能ｍが比較的少ないため、事前確率決定が比較的容易だが、一般的な多機能なソフトウェアやシステムの場合は、この数の確率をあらかじめ用意しておくことは現実的でない。
【００１５】
さらにベイズ定理を用いた推定の精度は、事前確率と条件付確率Ｐ（Ｄｓ|Ｈｒ）のみに依存するため、この事前確率がある程度正確でなければ、有用な推定が行えない。このため、システムの実運用の前に、試使用を繰返すなどして、あらかじめ適当な精度を持つ事前確率を確定しておく必要があり、準備工数がかかるという問題もある。
【００１６】
また、推定操作目的を特定した後に推奨操作を提示するとしているが、一般的なソフトウェアの場合は、作業を行う際の操作の順序が複雑であることが多く、このユーザに的確な操作手順を提示することが重要となるため、この推奨操作の順序を明示的に定義できるような仕組みが必要である。
【００１７】
特許文献２では、ユーザが、システムによって提供される特定の機能を意識して、これを探していることが前提となっており、ユーザの目的は単一の機能の実行である。このため、システムの提供する複数の機能間の関係について、ユーザの操作を予測することができないという問題がある。
【００１８】
携帯電話のシステムを例とすると、特許文献２が提供できるのは、受信したメールを閲覧するために、ユーザがメニュー階層を試行錯誤している状況を感知して、その操作履歴から受信したメール閲覧がユーザの目的機能であると推定し、メール閲覧機能を実行するまでの操作をサポートすることである。システムはメール閲覧中に、やがてメール閲覧を終えたユーザが、そのメールに対して返信メールを編集することを予測することはできない。
【００１９】
この発明は上記のような問題点を解決するためになされたものであり、ある時点までのユーザのソフトウェア（システム）の実際の操作履歴と、システム開発者が想定するシステムの使用例が表現されたユースケースとのマッチングを行って、実操作履歴を最もよく表現しているユースケースを決定するとともに、そのユースケースを元にユーザのシステム利用目的を推定し、推定されたユーザのシステム利用目的を元に、ユースケースに従って、ユーザが次にとる「べき」操作（同時にユーザが次にとる「であろう」操作）を決定することを目的とする。
【課題を解決するための手段】
【００２０】
本発明は、アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースと、前記アプリケーションに対するユーザ操作であるＵＩリソースと、前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表と、逐次入力される前記ユーザ操作から前記ＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力する操作実績変換部と、前記操作実績変換部から入力された前記操作実績パスを格納する操作履歴ベースと、依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するとともに、前記依頼信号の内容である操作目的別に応じて、前記ユースケース知識ベースからユースケース候補を取得し、依頼時実績パスとすべてユースケース候補とから依頼時操作実績パスとの適合度を算出し、推定されるユーザのシステム利用目的と次操作の予測とを含む予測結果を出力するユースケース候補適合度算出部と、前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ前記依頼信号を出力するとともに、前記予測結果から、前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するインターフェースと、を備えたことを特徴とするものである。
【発明の効果】
【００２１】
本発明によれば、アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースと、前記アプリケーションに対するユーザ操作であるＵＩリソースと、前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表と、逐次入力される前記ユーザ操作から前記ＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力する操作実績変換部と、前記操作実績変換部から入力された前記操作実績パスを格納する操作履歴ベースと、依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するとともに、前記依頼信号の内容である操作目的別に応じて、前記ユースケース知識ベースからユースケース候補を取得し、依頼時実績パスとすべてユースケース候補とから依頼時操作実績パスとの適合度を算出し、推定されるユーザのシステム利用目的と次操作の予測とを含む予測結果を出力するユースケース候補適合度算出部と、前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ前記依頼信号を出力するとともに、前記予測結果から、前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するインターフェースと、を備えたので、ユーザのソフトウェア（システム）の実際の操作履歴と、システム開発者が想定するシステムの使用例が表現されたユースケースとのマッチングを行って、実操作履歴を最もよく表現しているユースケースを決定するとともに、そのユースケースを元にユーザのシステム利用目的を推定し、推定されたユーザのシステム利用目的を元に、ユースケースに従って、ユーザが次にとる「べき」操作（同時にユーザが次にとる「であろう」操作）を決定することができる。
【図面の簡単な説明】
【００２２】
【図１】実施の形態１における操作予測装置の構成図。
【図２】実施の形態１におけるＵＩリソース−モデル要素対応表１０３の例。
【図３】実施の形態１におけるユースケース知識ベース１０５に格納されるユースケース候補の例。
【図４】実施の形態１における図５の状態遷移図５００のモデル要素である状態と遷移を表に列挙したモデル要素一覧表である。
【図５】実施の形態１におけるｗｉｎｄｏｗｓ上でテキストファイルの編集とファイルへのシリアライズが可能なアプリケーションの状態遷移グラフ空間５００の例。
【図６】実施の形態１における図３におけるユースケース候補３００「新規ドキュメント編集保存」のグラフ構造を簡略化した図。
【図７】実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集更新」のグラフ構造図。
【図８】実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集コピー保存」のグラフ構造図。
【図９】実施の形態１における図５における状態遷移図５００の振舞いを持つアプリケーション１０１に対してユーザが行った操作履歴の例を示す図。
【図１０】実施の形態１における図９の操作履歴から作成した状態遷移のグラフ構造図。
【図１１】図１０におけるグラフ構造図を基に、操作実績パス１０００の最新からの道の長さとユースケース候補６００，７００，８００ごとに計算した適合度を示す図。
【発明を実施するための形態】
【００２３】
実施の形態１．
実施の形態１では、ユースケースを用いてユーザのシステム利用目的を推定し、次操作を予測して、ユーザへのガイダンス表示等に利用する操作予測装置について説明する。
【００２４】
図１は、実施の形態１における操作予測装置の構成図である。
【００２５】
まず、操作予測装置は、ユーザのシステム利用目的を推定し、次操作を予測する操作予測ユニット１００と、例えばｗｉｎｄｏｗｓ上で動作するソフトウェアや、あるいは制御システムを制御するソフトウェアなどの、操作項目を推定する対象となるアプリケーション１０１とから構成されている。
【００２６】
また、アプリケーション１０１は、ユーザインタフェース部１０８と連動しており、ユーザが、ユーザインタフェース部１０８を通じてアプリケーション１０１に対して操作を行う入力情報を操作予測ユニット１００に送ると共に、入力情報の履歴から得られた操作予測ユニット１００からのアプリケーション形式予測結果１２９をユーザインタフェース部１０８を通じて表示する。
【００２７】
次操作を予測する操作予測ユニット１００の構成について説明する。
操作予測ユニット１００は、インタフェース部１０２、ＵＩリソース−モデル要素対応表１０３、操作実績変換部１０４、ユースケース知識ベース１０５、ユースケース候補適合度算出部１０６、操作履歴ベース１０７から構成されている。
【００２８】
操作実績変換部１０４は、アプリケーション１０１から、アプリケーション１０１そのものの操作開始を知らせる機能開始トリガ１２２を受けとった後、アプリケーション１０１を通じて、ユーザインタフェース部１０８に入力されるアプリケーション１０１に対するユーザ操作１３０の取得を開始する。
【００２９】
また、操作実績変換部１０４は、ユーザインタフェース部１０８に逐次入力されるユーザ操作１３０を逐次受け取り、操作予測ユニット１００で後に、解析に利用する操作実績パス１２６を作成するために、各ユーザ操作１３０に使用されたＵＩリソースを、ＵＩリソース−モデル要素対応表１０３を用いて、各ユーザ操作１３０に使用されたＵＩリソースに対応する各モデル要素１２４を取得し、各モデル要素１２４の履歴に相当する操作実績パス１２６を生成してそれを格納するため、操作履歴ベース１０７へ送信する。
【００３０】
ＵＩリソース−モデル要素対応表１０３は、アプリケーション１０１のユーザインタフェース部１０８に入力されるユーザ操作１３０と、操作予測ユニット１００がユースケース知識ベース１０５や操作履歴ベース１０７に用いる、システム全体の振舞いを表すグラフ空間を構成するモデル要素１２４（グラフ要素）との間の変換テーブルである。このテーブルは、操作実績変換部１０４が、アプリケーション１０１のユーザインタフェース部１０８に対して行われたユーザ操作１３０を、操作予測ユニット１００で使用するモデル要素１２４へ変換する際に用いられる。また、操作予測ユニット１００が導き出した、ユーザのシステム利用目的や次操作の予測結果を、アプリケーション１０１で解釈できるＵＩリソースに対応する操作形式１２３に逆変換する際にも用いられる。上記変換テーブルについては後述する。
【００３１】
操作履歴ベース１０７は、操作実績変換部１０４から渡された、モデル要素１２４を時系列で連結した操作実績パス１２６を内部に格納しておく。この操作実績パス１２６はユースケース候補適合度算出部１０６によって、ユースケース候補を選出する際に利用される。
【００３２】
インタフェース部１０２は、アプリケーション１０１から、次操作の予測の要求であるサービス要求１２１を解釈し、サービス要求１２１の内容に従ってユースケース適合度算出部１０６を制御するための依頼信号１２５をユースケース適合度算出部１０６に送信する。
【００３３】
ユースケース候補適合度算出部１０６は、インタフェース部１０２からの依頼信号１２５を受けて、依頼時点での、操作履歴ベース１０７に格納されているモデル要素を時系列で連結した、依頼時操作実績パス１２８を取得する。一方で、あらかじめユースケース知識ベース１０５に格納されている、アプリケーション１０１の操作目的別に表現されたユースケース候補１２７を取得し、それぞれのユースケースについて、依頼時操作実績パス１２８との適合度を算出する。
【００３４】
ユースケース知識ベース１０５は、ユースケース候補適合度算出部１０６によって操作履歴ベース１０７との適合度を算出するためのユースケース候補１２７が格納される知識ベースである。ユースケース知識ベース１０５は、アプリケーション１０１を開発する際の上流設計で行われるユースケース分析フェーズで挙げられたアプリケーション１０１のユーザの利用目的に応じて、アプリケーション１０１の機能を満たすための操作履歴（ユースケース）を格納している。
【００３５】
その結果、依頼時操作実績パス１２８の操作履歴そのものを最もよく説明しているユースケース候補１２７を選出して、「推定されるユーザのシステム利用目的」として、予測結果１３１に含めてインタフェース部１０２へ返す。
【００３６】
また、操作履歴ベース１０７から取得した依頼時操作実績パス１２８から、アプリケーション１０１の状態を把握して、依頼時操作実績パス１２８最もよく説明しているユースケース候補１２７を辿って、次に遷移する内容と遷移先の情報を「次操作の予測」として、予測結果１３１に含めてインタフェース部１０２へ返す。詳細については後述する。
【００３７】
インタフェース部１０２はまた、ユースケース適合度算出部１０６によって導き出されたユーザのシステム利用目的や次操作に関する予測結果１３１を、アプリケーション１０１に理解できる形で返すため、ＵＩリソース−モデル要素対応表１０３で、モデル要素１２４の表現形式である次操作をＵＩリソースに対する操作形式１２３の形に変換し、アプリケーション形式予測結果１２９としてアプリケーション１０１に返却する。
【００３８】
次に、ＵＩリソース−モデル要素対応表１０３の詳細について説明する。
図２は、ＵＩリソース−モデル要素対応表１０３の例を示したものである。
【００３９】
２０１，２０３，２０４列は、アプリケーション１０１のユーザインタフェース部１０８に入力されるＵＩリソースの情報を表している。このうち実装が必要なのは２０４列のＩＤのみで、他は便宜上記したものであって、表２００内にはなくともよい。このＩＤは、例えばｗｉｎｄｏｗｓアプリケーションであれば、アプリケーション開発プロジェクトにリソースＩＤとして定義されているものや、キーボードからの入力コードなど、アプリケーションが持つ入力ＵＩの種類を特定するＩＤである。
【００４０】
一方の２０５列と２０６列は、ＵＩリソースの情報に対応させた、操作履歴ベース１０７やユースケース知識ベース１０５に格納される部分グラフを構成するモデル要素１２４を示している。尚、これらは後述する図４のモデル要素一覧表４００のうち、抽象レベルが１であるものである。
【００４１】
２０７列は、各モデル要素の種別を示し、「状態」か「遷移」を表すものである。
【００４２】
また、２０４列最下行の（編集操作キー入力）のように、ＵＩリソースＩＤからモデル要素ＩＤへの対応は一意である必要があるが、２０４列最下行の（編集操作キー入力）のように、モデル要素ＩＤからＵＩリソースＩＤへの対応は一意である必要はない。実際にアプリケーションを操作する際には、２０４列に列挙したＵＩリソースＩＤ以外の操作も数多く行われる。例えば「開く」ダイアログ上で行われる実際のユーザ操作は「開く」ボタン押下以外にもあるが、それらは、ユースケース知識ベース１０５内に定義されているユースケース群の中で定義されていないため、ＵＩリソース−モデル要素対応表１０３の対象とはならない。
【００４３】
ユースケース知識ベース１０５に格納されるユースケース候補は、アプリケーション１０１の開発の上流設計で用意できる内容であるが、ＵＩリソース−モデル要素対応表１０３は、アプリケーション１０１が完成し、そこで使用されるＵＩリソースＩＤが確定されてから作成する必要がある。
【００４４】
以下に、状態遷移図で表現されるアプリケーション１０１に、本特許の操作予測ユニット１００を適用する際、操作予測ユニット１００を実現する上であらかじめ用意されている必要がある２つの静的データ、ユースケース知識ベース１０５、ＵＩリソースモデル要素対応表１０３について説明する。
【００４５】
図５は、ｗｉｎｄｏｗｓ上でテキストファイルの編集とファイルへのシリアライズが可能なアプリケーションの状態遷移グラフ空間５００の例である。なお、この状態遷移グラフ空間５００の全体図は、アプリケーション１０１が操作予測ユニット１００のサービスを利用する際に、操作履歴ベース１０７に格納されていてもよいが、必ずしも用意されている必要はない。
【００４６】
図４は、図５の状態遷移図５００のモデル要素である状態と遷移を表に列挙したモデル要素一覧表４００である。ユースケース知識ベース１０５にユースケースを格納する時は、同時に、ユースケースで使用しているモデル要素の一覧表を定義しておく必要がある。
【００４７】
モデル要素一覧表４００のパラメータについて説明する。モデル要素は、列４０１に示した「状態」４１１と「遷移」４１２に分けられる。状態は状態遷移グラフ空間５００でいうノード、遷移はエッジにあたる。
【００４８】
列４０２に示したモデル要素ＩＤはＵＩリソース−モデル要素対応表１０３で参照されるＩＤである。このＩＤはモデル内で一意に定義される必要がある。４０３列の抽象レベルは、ユースケースが多重定義される際に意味を持つ値で、ＵＩリソース−モデル要素対応表１０３で参照されるＩＤは全て抽象レベルが１、つまりユースケースで使用されるモデル要素の抽象度としては最低値とする。４０４列は便宜上付けた列で、実際に操作予測ユニット１００を実現する際にはなくても良い。
【００４９】
図３は、ユースケース知識ベース１０５に格納されるユースケース候補の例を示したものである。ユースケース３００において、太線、太字、太枠にて示されているものは、図５の状態遷移図５００に示したアプリケーション１０１における「新規ドキュメント編集保存」のユースケースの例である。前述したようにこのユースケースは、アプリケーション開発の上流設計過程において、開発者が想定ユーザの典型的な使用方法を記述したものである。このユースケースでは、ユーザの利用目的として「ドキュメントを新規作成して編集して名前を付けてファイルへ保存する」という一連の操作の流れを定義している。以降、順に説明する。
【００５０】
図３において、まずアプリケーションが起動された状態では編集ウィンドウの編集なし・保存履歴なしの状態（Ａ）３０１である。ここで「新規作成」操作を行うと、４アプリケーション側では新しいドキュメントが生成される３２３。しかしユーザ操作上の状態遷移は行われず、状態は編集ウィンドウの編集なし・保存履歴なしの状態３０１のままである。それから５ドキュメントに対する編集作業３２０を行うと、編集の結果、状態は、編集ウィンドウの編集なし・保存履歴なしの状態（Ａ）３０１から、編集ウィンドウの編集あり・保存履歴なしの状態（Ｃ）３０３へ遷移する。その後に２ドキュメントをファイルへ保存するために「名前を付けて保存」操作３１５を行うと、「名前を付けて保存」ダイアログが表示され、状態も「名前を付けて保存」ダイアログ（Ｇ）３０７へ遷移する。最後に９「名前を付けて保存」ダイアログ内で「保存」ボタンが押下される３１４と、ダイアログを抜けて、編集ウィンドウの編集なし・保存履歴ありの状態（Ｂ）３０２へ遷移する。
【００５１】
このようにして「新規ドキュメント編集保存」のユースケースは、Ａ→４→Ａ→５→Ｃ→２→Ｇ→９→Ｂと表すことができる。このため、ユースケース知識ベース１０５には、図３の太線、太字、太枠にて示されているグラフ構造が表現できる形でユースケース候補が格納されていれば良く、その一例としては、モデル要素一覧表４００の種別４０１、モデル要素ＩＤ４０２及び記号４０５と具体的なユースケース候補を表現したシーケンス「Ａ→４→Ａ→５→Ｃ→２→Ｇ→９→Ｂ」などとなる。
【００５２】
以下、動作について図１に基づいて説明する。
まず、アプリケーション１０１の起動後の任意のタイミングで、アプリケーション１０１は、機能開始トリガ１２２を操作実績変換部１０４へ送る。このタイミングは、アプリケーション起動直後でなくても良いが、アプリケーションがユーザのアプリケーション利用目的と次操作予測結果を必要とする時点よりも前に行う。操作実績変換部１０４はこのトリガによって、アプリケーション１０１内にあるユーザインタフェース１０８に入力されるユーザの操作から、そのリソースＩＤを含むユーザ操作１３０の情報を取得して、逐次、その操作実績をモデル要素１２４へ変換する。この際に、操作実績変換部１０４はリソースＩＤと対応するモデル要素１２４を得るために、ＵＩリソース−モデル対応表１０３を参照する。
モデル要素１２４に変換された結果は、操作実績パス１２６として操作履歴ベース１０７へ格納される。
【００５３】
操作実績変換部１０４が、アプリケーション１０１に対するユーザ操作１３０を、逐次、モデル要素１２４へ変換し、操作履歴ベース１０７へ格納していく。操作履歴ベース１０７では、操作実績変換部１０４から送られ、ユーザ操作１３０から変換された操作実績パス１２６の個々の断片を時系列で接続し、依頼時操作実績パス１２８を作成する。
【００５４】
以上の状態が続いて、操作履歴ベース１０７内にある程度の長さの依頼時操作実績パス１２８ができあがった後に、アプリケーション１０１が、ユーザのアプリケーション操作目的を知りたいタイミングや、ユーザの次操作予測を行いたいタイミングで、インタフェース部１０２へサービス要求１２１を発信する。インタフェース部１０２は要求の内容を解釈して、ユースケース候補適合度算出部１０６へ機能の実行を指示する依頼信号１２５を送信する。
【００５５】
これを受けて、ユースケース候補適合度算出部１０６は、まず、その時点での操作履歴ベース１０７に格納されている依頼時操作実績パス１２８を取り出す。そして、その依頼時操作実績パス１２８を基準として、ユースケース知識ベース１０５内にある全てのユースケース候補１２７を対象として、適合度を計算していく。
【００５６】
次にユースケース適合度算出部１０６によって、ユースケース知識ベース１０５内のユースケース候補それぞれについて、操作履歴ベース１０７の実績パスとどの程度合致しているかを表す適合度が計算される。
【００５７】
以下は、ユースケース適合度算出部１０６内で行う適合度の計算過程について説明する。
【００５８】
まず操作履歴ベース１０７から取得した依頼時操作実績パス１２８を解釈し、最初のステップでは、依頼時操作実績パス１２８中の最新のモデル要素１２４から過去に遡って長さ１の道、すなわち「状態」−「遷移」−「状態」を含むモデル要素１２４の履歴について、全てのユースケース候補１２７との適合度を計算する。図３にて説明した状態遷移図の場合だと、「Ｇ→９→Ｂ」の部分に相当する。
【００５９】
次にもう一つ遡って、実績パスの最新のモデル要素から長さ２の道について適合度を計算する。すなわち、「状態」−「遷移」−「状態」−「遷移」−「状態」を含むモデル要素１２４の履歴であり、図３の場合だと、「Ｃ→２→Ｇ→９→Ｂ」の部分に相当する。
【００６０】
更に、と１つずつ「遷移」を過去に遡り、それぞれについて、ユースケース知識ベース１０５内のユースケース候補の適合度を算出しておく。
【００６１】
いくつ前の履歴まで遡るかについては、予め定義された長さとしてもよいし、アプリケーション１０１から機能開始トリガ１２２が送られた時からとしてもよい。またアプリケーション１０１からインタフェースに送られるサービス要求時のパラメータとしてもよい。
【００６２】
ユーザの操作実績とユーザの目的を考えると、現時点のユーザの目的は、一般的に過去の操作のうち、その時間軸的な距離が近いものに大きな影響を与えると考えられる。従って、先に計算しておいた、長さ１，２，３．．．の実績パスの部分グラフのそれぞれについて、長さが短い道に対する適合度については大きな重みをつけ、長さが長い道については小さな重みをつけて、全ての実績パスの部分グラフに関する適合度を合計して、総合適合度を計算する時間的局所性を考慮した適合度の計算方法をとる。
【００６３】
この結果得られた最も適合度の高いユースケース候補１２７を、ユーザの目的を表しているユースケースであると推定する。
【００６４】
図１に戻って説明する。
【００６５】
ユースケース候補適合度算出部１０６は、この最適合ユースケースを含む予測結果１３１をインタフェース部１０２へ返す。
【００６６】
また、この時に、操作履歴ベース１０７からアプリケーション１０１上の現時点の状態が判明する場合は、現時点の「状態」を表すモデル要素１２４のＩＤを予測結果１３１に含めてインタフェース部１０２へ渡す。
【００６７】
最後にインタフェース部１０２がＵＩリソース−モデル要素対応表１０３を用いて、ユースケース候補適合度算出部１０６から取得した予測結果１３１に含まれる最適合ユースケースと、現時点のアプリケーション１０１上の「状態」を示すモデル要素１２４を、モデル要素からＵＩリソースのＩＤの形に逆変換する。この時、ＵＩリソース−モデル要素対応表のＵＩリソースＩＤとモデル要素ＩＤがｎ対１の関係であるため、変換後のＩＤが特定できないケースもある。その場合はモデル要素と１対１に関連づいた文字列リソースなどをあらかじめ定義しておき、モデル要素のＩＤのままでユーザへのガイダンス等が可能なように実装することもできる。そしてＵＩリソースのＩＤの形に逆変換された最適合のユースケースと、最適合ユースケースに基づいて現在の状態から次操作に関連づいたＵＩリソースＩＤとをアプリケーション形式予測結果１２９としてアプリケーション１０１へ提供する。
【００６８】
以下、実例を元に動作を説明する。
図６は、実施の形態１における図３におけるユースケース候補３００「新規ドキュメント編集保存」のグラフ構造を簡略化したものである。
【００６９】
図７は、実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集更新」のグラフ構造図である。
【００７０】
図７におけるユースケース候補「既存ファイル編集更新」状態遷移は、「Ａ→３→Ｅ→６→Ｂ→５→Ｄ→１→Ｂ」のようになる。
【００７１】
図８は、実施の形態１における図３及び図４に基づいたユースケース候補「既存ファイル編集コピー保存」のグラフ構造図である。
【００７２】
図８におけるユースケース候補「既存ファイル編集コピー保存」状態遷移は、「Ａ→３→Ｅ→６→Ｂ→５→Ｄ→２→Ｇ→９→Ｂ」のようになる。
【００７３】
以降、ユースケース知識ベース１０５内には、この３つのユースケース候補１２７があらかじめ入っているものとして説明する。
【００７４】
次に操作履歴ベース１０７の説明を行うため、アプリケーション１０１を使用するユーザの操作履歴を仮定する。
【００７５】
図９は、図５における状態遷移図５００の振舞いを持つアプリケーション１０１に対してユーザが行った操作履歴の例９００を示している。９０１列の順序で、９０２列にある対象の操作が行われたとする。ユーザインタフェース部１０８では、ＵＩリソースＩＤとして９０４列のＩＤが特定できる。このような操作入力が行われると、操作実績変換部１０４はＵＩリソース−モデル要素対応表１０３を参照して、各ＵＩリソースＩＤに対応するモデル要素ＩＤを取得する。その結果、９０５列のモデル要素ＩＤが得られる。
【００７６】
この時、順序３番目のＵＩリソースＩＤに対するモデル要素ＩＤが存在せず、その前後の状態は同じであるため、３の操作は無視される。この結果、操作予測ユニット１００として扱うユーザ操作１３０の履歴は、９０６列の記号でＡ→４→Ａ→３→Ｅ→６→Ｂとなる。
図１０は、図９の操作履歴から作成した状態遷移のグラフ構造図であり、図９のユーザの操作履歴９００を、図６〜８と同様、グラフ構造に示したものである。
【００７７】
次に、ユースケース候補適合度算出部１０６において算出される適合度の計算例に関して説明する。以上に記したように、ユースケース候補適合度算出部１０６にて行われる適合度計算は、図１０における操作実績パス１０００に対する適合度を、図６、図７、図８に示したユースケース候補６００，７００，８００それぞれについて算出することに他ならない。ここでは操作実績パス１０００の時間的局所性を考慮したユースケース候補の適合度計算方法について説明する。
【００７８】
まず、操作実績パス１０００を時系列にみて最新の状態Ｂとその直前の状態Ｅ、さらにその間を遷移する６のモデル要素から成る長さ１の道として考える。この道（Ｅ→６→Ｂ）に対する各ユースケース候補６００，７００，８００の適合度を求める。さらにその次には、一つ過去に遡り、道（Ｅ→６→Ｂ）に対する適合度を求める。さらに一つ遡って、道（Ａ→４→Ａ→３→Ｅ→６→Ｂ）つまり実績パス全体についての適合度を求める。このようにして実績パスを複数に分割したものとユースケース候補を比較して、それぞれの適合度に対する重み付けを変更させることで、ユーザ目的の時間的局所性を考慮した比較が行える。
【００７９】
実際の適合度計算方法は、一般的なグラフ理論で行われる２つのグラフのマッチングで行う場合や、２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用し、適合度の計算する場合があげられる。
例えば、２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用する場合では、操作実績パス１０００の道の長さごとである（Ｅ→６→Ｂ）、（Ｅ→６→Ｂ）、（Ａ→４→Ａ→３→Ｅ→６→Ｂ）の各々に対し、各ユースケース候補６００，７００、８００とのレーベンシュタイン距離（編集距離）を求め、それを負の相関とした適合度の値を求めることができる。また、エッジ（遷移）とノード（状態）の２つに分けて各々、各ユースケース候補６００，７００、８００とのレーベンシュタイン距離（編集距離）を求め、その各々の距離に対して負の相関とした評価値（一致割合）を求めて、それぞれを加算することで適合値とすることもできる。
【００８０】
以下では、一般的なグラフ理論で行われる２つのグラフのマッチングで行う場合であって、単純にエッジ（遷移）とノード（状態）の２つに分けて、適合度を計算する方法について説明する。
図１１は、図１０におけるグラフ構造図を基に、操作実績パス１０００の最新からの道の長さごとにとユースケース候補６００，７００，８００ごとに計算した適合度を示す図である。
【００８１】
まず表１１００の実績パス１１０１欄に示された、道の長さが１の実績パス（Ｅ→６→Ｂ）に対して、１１０２欄に示されたユース知識ベース１０５にあらかじめ記憶された各ユースケース候補６００，７００，８００の適合度を求める。
【００８２】
総数のエッジ１１０３欄、ノード１１０４欄は、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）が持つエッジ、ノード数をそれぞれ示している。
【００８３】
一致エッジ数１１０５欄は、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）に対して、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつエッジ（６のみ）が一致している個数を示し、一致エッジ率１１０６欄が、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）が各々もつエッジ数に対する、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつエッジ（６のみ）の一致率を示している。
【００８４】
ノードについても同様に、一致ノード数１１０７欄は、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）に対して、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつノード（Ｅ，Ｂ）が一致している個数を示し、一致エッジ率１１０６欄が、各ユースケース候補６００（新規ドキュメント編集保存），７００（既存ファイル編集更新），８００（既存ファイル編集コピー保存）が各々もつノード数に対する、実績パス１１０１欄の実績パス（Ｅ→６→Ｂ）がもつノード（Ｅ，Ｂ）の一致率を示している。
【００８５】
重み１１０９欄は、道の長さごとに実績パスに対して重みが設定されている。
【００８６】
適合度計算例１１１０欄は、各ユースケース候補の適合度を算出した結果を示したものである。ここでは一例として、エッジの一致数とエッジの一致率とノードの一致率を単純に加えて、それぞれ重みを乗じたものを適合度計算例としている。
【００８７】
同様に、道の長さが２の操作実績パス（Ａ→３→Ｅ→６→Ｂ）に対する適合度と、長さ３の操作実績パス（Ａ→４→Ａ→３→Ｅ→６→Ｂ）に対して適合度が各々計算されている。
【００８８】
最後に３つの実績パスのケースを、ユースケース候補１２７ごとに全て加算して、ユースケース候補６００「新規ドキュメント編集保存」が適合度６．５、ユースケース候補７００「既存ファイル編集更新」が適合度２６．７５、ユースケース候補８００「既存ファイル編集コピー保存」が適合度２４．６となる。
【００８９】
この結果、図７ユースケース候補７００の「既存ファイル編集更新」が最適合ユースケースと判定される。また、現時点の「状態」を表すモデル要素１２４のＩＤ（図４における記号Ｂに相当するモデル要素のＩＤはＭ＿ＳＴ＿ＥＤＩＴＷＩＮ＿Ｈであり、この二つの情報を含む予測結果１３１が図１におけるインタフェース部１０２へ返される。
最後に図１におけるインタフェース部１０２がＵＩリソース−モデル要素対応表１０３を用いて、ユースケース候補適合度算出部１０６から取得した予測結果１３１に含まれる最適合ユースケースと、現時点のアプリケーション１０１上の「状態」を示すモデル要素１２４を、モデル要素からＵＩリソースのＩＤの形に逆変換する。
【００９０】
そしてＵＩリソースのＩＤの形に逆変換された最適合のユースケースと、最適合ユースケースに基づいて現在の状態から次操作に関連づいたＵＩリソースＩＤとをアプリケーション形式予測結果１２９としてアプリケーション１０１へ提供する。このようにすることで、アプリケーションは再適合のユースケース「既存ファイル編集更新」に基づいて、図７におけるモデル要素Ｂの次の「遷移」に相当する５、図４におけるモデル要素Ｍ＿ＥＤＩＤＯＣにあたる、ＵＩリソースである図２の意味における「編集ウィンドウ 編集」をユーザに示すことができる。
【００９１】
以下、ユースケースを利用した場合のメリットについて記載する。尚、一般的なグラフ理論で行われる２つのグラフのマッチングで適合度の計算する場合や、２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用し、適合度の計算する場合の両方に適用できることである。
≪ユースケースの無順序表現≫
ユースケースでは順序が問われる手順と順序が問われない手順を表現できる。
【００９２】
システムを使用してある作業を行う場合に、通常は作業を構成する操作の実施手順が一意に決まるが、作業全体や作業の一部分によっては、作業を構成する操作間の順序関係が問われないケースもある。例えば編集したファイルに名前を付けて保存する際に、保存ダイアログ上でユーザは、保存ファイル名を指定することと保存ファイルフォーマットを選択することの順序は問われない。保存ボタンを押下する時点で、両操作が既に実施されていれば問題ない。ユースケースでは、この無順序条件を表現することができる。例えば、上記実例においても、適合度を計算する際に、長さによる重みづけという係数とするだけで、順序については考慮がなされていない。
【００９３】
グラフ空間の例として、各操作手順の関係がエッジで表現されているような状態遷移図を考えると、順序関係が問われる場合は有向エッジによって状態間の関係を表し、順序関係が問われない場合は、それらの状態間は無向エッジによって表す方法がある。またダイアログ内の選択項目など、単純なデータ構造に対する設定については、それぞれを状態として定義するのではなく、フラグや遷移チェック表を使用するなどの方法を取ることもできる。
【００９４】
≪ユースケースの分岐遷移定義≫
ユースケースは分岐を含む部分グラフとして表現できる。
【００９５】
システムでは似た目的の機能が存在しており、それらの操作手順は必ずしも一致しない。その似た機能を実行するユースケースを定義する場合、ユースケース内に分岐部分が発生する可能性がある。このため、一般的にユースケースを表す部分グラフは道ではなく、分岐を含む形となる。例えば「ファイルに上書き保存する」と「ファイルに名前を付けて保存する」という２つのユースケースを別々に定義する場合は良いが、これらをまとめて「ファイルに保存する」というユースケースを定義したい（その粒度でユーザの目的を推定したい）場合には、そのユースケースとして、前述の２つのユースケースを表す２つの部分グラフの和を取ったものを定義することで対応可能である。
その場合、定義の範囲が広いユースケースは、定義の範囲が狭いユースケースよりも評価値が低く算出されてしまう傾向はでるが、広く「ファイルに保存する」というユースケースを定義することでも、それなりの評価値を当該ユースケースに与えることができる。
≪ユースケースの個別抽象度表現≫
ユースケースを表す部分グラフの構成要素（ノード、エッジ）は、それぞれ個別の抽象度を持つことができる。
【００９６】
例えば「ファイルに名前を付けて保存」というユースケースを状態遷移図で表す場合、ユーザ操作の粒度（抽象度が最も低い状態）での操作手順を、ユースケースとして定義することもできるが、名前を付けるために表示されるダイアログ上での各種設定や状態遷移は考慮せず、ダイアログが表示されたことだけに注目するユースケース定義を行いたい場合には、「名前を付けて保存ダイアログ表示」という状態のみを用意して、ダイアログ上での操作は抽象化（グラフ理論的には状態遷移エッジの縮約）を行って定義することもできる。
【００９７】
なお後述するが、本発明で対象とするシステムでは、実績パス部分グラフの抽象度が最低である場合とした。なぜなら実績パス以下の抽象度（実績パス以上の詳細）ではユーザの操作を検出できないためである。
【００９８】
≪時間的局所性を考慮したユースケース候補評価≫
実績パスの比較時点のノード（有向エッジを追っていった最後のノード）を基点として、実績パスのグラフ要素それぞれについて、時間的距離と不の相関を持つ重みを付けてグラフ構造による比較を行う。一般的にユーザの操作は判定時（現在）に時間的に近い操作の方が、判定時のユーザの利用目的に大きな影響を与えていると考えられるため、現時刻からの時間的距離と負の相関を持った重み付けを行って比較を行うことで、ユーザ目的の時間的局所性を考慮した比較が行える。
【００９９】
≪ユースケースの多重定義≫
ユースケースはその定義において、他のユースケースを参照することができる。
【０１００】
ユースケースの定義方法として、システムの利用開始から終了までの一連の操作を全て１つのユースケースに表現する方法もあるが、通常、複数のユースケースを定義する上では、冗長な部分が多く存在するため、多重なユースケース定義を可能とし、他ユースケースを参照して定義したものを新たなユースケースとして定義することができる。
【０１０１】
これにより、例えば、文書作成ソフトウェアにおいて、特定の箇所の文書をコピーして、他の箇所へ貼り付けしたい場合、「クリップボードへコピー」というユースケースによって、当該文書の選択とクリップボードへの貼り付けを行い、別の「クリップボードから貼り付け」というユースケースによって、目的位置への貼り付け作業を定義する。そして「文書コピー」というユースケースで、これら２つのユースケースを参照することもできる。つまり、各々の個別操作のユースケースを多重して長い操作のユースケースとして独自に登録しておくことで、別に独自のユースケース定義を作らなくても、すでにある複数のユースケース定義を多重した独自のユースケース定義を作ることで、参照して評価することが可能となる。したがって、図１におけるユースケース知識ベースのデータ量の圧縮化を図ることができる。
【０１０２】
≪グラフ構造によるユースケース候補評価≫
適合度算出の他のやり方として、ユースケース候補と実績パスの２つの部分グラフのトポロジについて、純粋にグラフ理論的な比較を行う。例えば、ユースケース候補と実績パスを、ノード集合とエッジ集合に分割して、それぞれマッチしている要素数、集合内の全要素数とマッチしている要素数との割合、等のパラメータで比較して、それらを総合して適合度を算出することもできる。又は２つの文字列間で定義されるレーベンシュタイン距離（編集距離）をグラフに適用し、適合度の計算に用いることもできる。
【０１０３】
≪異なる抽象度を考慮した評価≫
ユースケース候補を表現する部分グラフの各要素は、抽象度が一定でない可能性がある。一方で実績パス部分グラフの抽象度は常に最低である。このため、抽象度の異なる部分グラフ同士を比較する必要が生じる。この比較に関しては、ユースケース候補の各比較部分について、実績パスの抽象度との相対的な抽象度と不の相関を持つ重み付け比較を行う。
【０１０４】
一般的に、グラフ構造の比較を行った場合、抽象度の低いもの同士について厳密な比較を行うよりも、抽象度の低いものと高いものについて大まかな比較を行う方が、適合度が高くなるためである。（抽象度は相対的で離散的な値しかとれない）
以下例示にて説明する。
【０１０５】
例えば２つのユースケースＡ，Ｂがあり、両方とも以下のようにユースケースの途中に、ファイルに名前を付けて保存する部分を含んでいるとする。以下のｎ，ｍ，ｐはユースケースの順序（ステップ）を表している。
１ユースケースＡ（抽象度低）の場合
ｎ−１：．．．
ｎ ：メニューの「ファイルー名前を付けて保存」選択
（→「名前を付けて保存」ダイアログ表示状態に遷移）
ｎ＋１：表示された「名前を付けて保存」ダイアログ内で保存先フォルダ選択
（→「保存先フォルダ選択済み」状態に遷移）
ｎ＋２：同上のダイアログ内でファイル名入力
（→「ファイル名入力済み」状態に遷移）
ｎ＋３：同上のダイアログ内でファイルの種類選択
（→「ファイル種類選択済み」状態に遷移）
ｎ＋４：同上のダイアログ内で「保存」ボタン押下
ｎ＋５：．．．
【０１０６】
２ユースケースＢ（抽象度高）の場合
※ユースケースＡにある「保存先フォルダ選択済み」「ファイル名入力済み」「ファイル種類選択済み」の各状態は「名前を付けて保存」ダイアログ表示に縮約されている
ｍ−１：．．．
ｍ ：メニューの「ファイルー名前を付けて保存」選択
（→「名前を付けて保存」ダイアログ表示状態に遷移）
ｍ＋１：表示された「名前を付けて保存」ダイアログ内で「保存」ボタン押下
ｍ＋２：．．．
【０１０７】
ユースケースＡでは、名前を付けて保存ダイアログ内の操作に関しても手順を明確に定義していますが、Ｂではダイアログ内については抽象化している。これらは、ユースケース定義者が「どこに重きを置いてユースケース定義をしているか？」により、いずれが間違いというわけではない。
つまり、ユースケースＢ（抽象度高）において、ユースケースＡにある「保存先フォルダ選択済み」「ファイル名入力済み」「ファイル種類選択済み」の各状態は「名前を付けて保存」ダイアログ表示に縮約されている。
【０１０８】
ユーザの行った操作（実績パス）が、以下であったする。
３実績パス（抽象度最低）
ｐ−１：．．．
ｐ ：メニューの「ファイルー名前を付けて保存」選択
ｐ＋１：表示された「名前を付けて保存」ダイアログ内でファイル名入力
ｐ＋２：同上のダイアログ内で「保存」ボタン押下
ｐ＋３：．．．
【０１０９】
そして、評価する過程において、抽象度の低い（操作を厳密に定義している）ユースケースＡに注目すると、実績パスのステップｐに相当するのはステップｎである。しかしｐ＋１に相当するのはｎ＋２であり、またｐ＋２に相当するのはｎ＋４と、ステップｎ＋１とｎ＋３が抜けてしまっており、その分、評価値が低くなる。
一方、抽象度の高いユースケースＢに注目すると、実績パスのステップｐに相当するのはステップｍである。そしてｐ＋１に相当するものはないものの、Ｐ＋１はユースケースＢの「名前を付けて保存」ダイアログ表示状態において遷移を伴わない操作として無視される。そしてステップｐ＋２に相当するのがステップｍ＋１となり、抽象度の違いを別とすれば、ユースケースＢのステップｍ〜ｍ＋１は、実績パスのｐ〜ｐ＋２までと完全に一致していると判断され、評価値が高くなる。
【０１１０】
したがって、このユースケースの抽象度の高低による評価値の傾向を打ち消すよう、実績パスの抽象度との相対的な抽象度と不の相関を持つ重み付け比較を行うことで、異なる抽象度であってもユースケースによる評価を行うことができる。
【０１１１】
≪ユースケース候補の無順序条件部分の評価≫
比較部分が無順序表現されている場合は、相対的に重みを軽くして比較する
ユースケース候補の特定箇所が無順序条件である場合、同じグラフ構造で順序条件があるユースケース候補とくらべると、上記抽象度の場合と同様に、操作順序という制約がない分、比較制約が甘いため実績パスと一致しやすい傾向が出て、評価値が高くなる傾向がある。このため、無順序条件が設定されている部分については、順序条件が設定されている場合と比較して、重みを低く設定して比較を行うことで、無順序条件であってもユースケースによる評価を行うことができる。
【０１１２】
したがって、本実施の形態では、アプリケーション１０１に対するユーザの利用目的に応じて、アプリケーション１０１の機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素１２４及びその組み合わせであるユースケースとし、ユースケースを複数蓄積したデータベースであるユースケース知識ベース１０５と、アプリケーション１０１に対するユーザ操作１３０であるＵＩリソースと、モデル要素１２４との対応を示すデータベースであるＵＩリソース−モデル要素対応表１０３と、逐次入力されるユーザ操作１３０からＵＩリソース−モデル要素対応表１０３を用いてモデル要素１２４を取得し、モデル要素１２４の時系列の履歴である操作実績パス１２６を生成して出力する操作実績変換部と１０４、操作実績変換部１０４から入力された操作実績パス１２６を格納する操作履歴ベース１０７と、依頼信号１２５に基づいて、依頼時点での操作実績パスである依頼時実績パス１２８を操作履歴ベース１０７から取得するとともに、依頼信号１２５の内容である操作目的別に応じて、ユースケース知識ベース１０５からユースケース候補１２７を取得し、依頼時実績パス１２８とすべてユースケース候補１２７とから依頼時操作実績パス１２８との適合度を算出し、推定されるユーザのシステム利用目的と次操作の予測とを含む予測結果１３１を出力するユースケース候補適合度算出部１２７と、アプリケーション１０１から次操作の予測の要求であるサービス要求１２１を解釈して、サービス内容に従ってユースケース候補適合度算出部１０６へ依頼信号１２５を出力するとともに、予測結果１３１から、ＵＩリソース−モデル要素対応表１０３を用いてアプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果１３１としてアプリケーション１０１へ出力するインターフェース１０２とを備えたことにより、システム開発の上流設計に検討するユースケースをベースにユーザの実操作履歴との照合を行うことにより、実際にユーザがシステムを利用している際に、ユーザがどのような目的で（何が行いたくて）操作をしているのかが判り、それを表したユースケースに従ってユーザを誘導すれば、そのシステムにとって最も効率の良い手順で、ユーザがシステムに望んでいる作業を実施させることが可能となる。
【符号の説明】
【０１１３】
１００ 操作予測ユニット
１０１ アプリケーション
１０２ インターフェース部
１０３ ＵＩリソースモデル要素対応表
１０４ 操作実績変換部
１０５ ユースケース知識ベース
１０６ ユースケース候補適合度算出部
１０７ 操作履歴ベース
１０８ ユーザインターフェース部
１２１ サービス要求
１２２ 機能開始トリガ
１２３ ＵＩリソースに対する操作形式
１２４ モデル要素
１２５ 依頼信号
１２６ 操作実績パス
１２７ ユースケース候補
１２８ 依頼時操作実績パス
１２９ アプリケーション形式予測結果
１３０ ユーザ操作
１３１ 予測結果
【特許請求の範囲】
【請求項１】
アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースと、
前記アプリケーションに対するユーザ操作であるＵＩリソースと、前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表と、
逐次入力される前記ユーザ操作から前記ＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力する操作実績変換部と、
前記操作実績変換部から入力された前記操作実績パスを格納する操作履歴ベースと、
依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するとともに、前記ユースケース知識ベースから複数のユースケース候補を取得し、依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するユースケース候補適合度算出部と、
前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ前記依頼信号を出力するとともに、前記予測結果から、次に遷移する内容と遷移先の情報を示すモデル要素について前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するインターフェースと、
を備えたことを特徴とする操作予測装置。
【請求項２】
前記ユースケース候補には、分岐を含むモデル要素列の情報を含むことを特徴とする請求項１に記載の操作予測装置。
【請求項３】
前記ユースケース候補には、前記アプリケーションの操作内容の具体性に応じた抽象度情報を含むことを特徴とする請求項１または２に記載の操作予測装置。
操作予測装置。
【請求項４】
前記ユースケース候補には、個別のユースケースを組み合わせた情報を含むことを特徴とする請求項１乃至３のいずれかに記載の操作予測装置。
【請求項５】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり、依頼時実績パスとユースケース候補間の編集距離を用いて算出すること特徴とする請求項１乃至４のいずれかに記載の操作予測装置。
【請求項６】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり、状態の情報を持つモデル要素の一致割合と、遷移の情報を持つモデル要素の一致割合とを用いて算出すること特徴とする請求項１乃至５のいずれかに記載の操作予測装置。
【請求項７】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり、対応するモデル要素同士について時間的距離と不の相関をもつ重み付けを用いて算出すること特徴とする請求項１乃至６のいずれかに記載の操作予測装置。
【請求項８】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり前記ユースケース候補がもつ各々のモデル要素がもつ抽象度について不の相関をもつ重み付けを用いて算出することを特徴とする請求項１乃至７のいずれかに記載の操作予測装置。
【請求項９】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり前記ユースケース候補に無順序条件が設定されている場合は、無順序条件が設定されていない場合と比べて低い重み付けを用いて算出することを特徴とする請求項１乃至８のいずれかに記載の操作予測装置。
【請求項１０】
アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースから抽出された複数のユースケース候補と、
アプリケーションから次操作の予測の要求であるサービス要求に基づく依頼信号に基づいて、逐次入力されるユーザ操作から依頼時点での操作実績パスである依頼時実績パスと、
を取得し、依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するユースケース候補適合度算出部と、
を備えたことを特徴とする操作予測装置。
【請求項１１】
ユースケース候補適合度算出部が、アプリケーションから次操作の予測の要求であるサービス要求による依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスと、前記アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースを複数蓄積したデータベースであるユースケース知識ベースから複数のユースケース候補と、を取得するステップと、
前記ユースケース候補適合度算出部が、前記依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するステップと、
を含む操作予測方法。
【請求項１２】
操作実績変換部が、逐次入力されるユーザ操作から、アプリケーションに対するユーザ操作であるＵＩリソースと前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力するステップと、
操作履歴ベースが、前記操作実績変換部から入力された前記操作実績パスを格納するステップと、
インターフェースが、前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ依頼信号を出力するステップと、
ユースケース候補適合度算出部が、前記依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するステップと、
前記ユースケース候補適合度算出部が、前記依頼信号に基づいて、前記アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースを複数蓄積したデータベースであるユースケース知識ベースから複数のユースケース候補を取得し、依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するステップと、
インターフェースが、前記予測結果から、次に遷移する内容と遷移先の情報を示すモデル要素について前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するステップと、
を含む操作予測方法。
【請求項１】
アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースと、
前記アプリケーションに対するユーザ操作であるＵＩリソースと、前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表と、
逐次入力される前記ユーザ操作から前記ＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力する操作実績変換部と、
前記操作実績変換部から入力された前記操作実績パスを格納する操作履歴ベースと、
依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するとともに、前記ユースケース知識ベースから複数のユースケース候補を取得し、依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するユースケース候補適合度算出部と、
前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ前記依頼信号を出力するとともに、前記予測結果から、次に遷移する内容と遷移先の情報を示すモデル要素について前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するインターフェースと、
を備えたことを特徴とする操作予測装置。
【請求項２】
前記ユースケース候補には、分岐を含むモデル要素列の情報を含むことを特徴とする請求項１に記載の操作予測装置。
【請求項３】
前記ユースケース候補には、前記アプリケーションの操作内容の具体性に応じた抽象度情報を含むことを特徴とする請求項１または２に記載の操作予測装置。
操作予測装置。
【請求項４】
前記ユースケース候補には、個別のユースケースを組み合わせた情報を含むことを特徴とする請求項１乃至３のいずれかに記載の操作予測装置。
【請求項５】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり、依頼時実績パスとユースケース候補間の編集距離を用いて算出すること特徴とする請求項１乃至４のいずれかに記載の操作予測装置。
【請求項６】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり、状態の情報を持つモデル要素の一致割合と、遷移の情報を持つモデル要素の一致割合とを用いて算出すること特徴とする請求項１乃至５のいずれかに記載の操作予測装置。
【請求項７】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり、対応するモデル要素同士について時間的距離と不の相関をもつ重み付けを用いて算出すること特徴とする請求項１乃至６のいずれかに記載の操作予測装置。
【請求項８】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり前記ユースケース候補がもつ各々のモデル要素がもつ抽象度について不の相関をもつ重み付けを用いて算出することを特徴とする請求項１乃至７のいずれかに記載の操作予測装置。
【請求項９】
前記ユースケース候補適合度算出部の適合度算出において、依頼時実績パスとユースケース候補との適合度を算出するにあたり前記ユースケース候補に無順序条件が設定されている場合は、無順序条件が設定されていない場合と比べて低い重み付けを用いて算出することを特徴とする請求項１乃至８のいずれかに記載の操作予測装置。
【請求項１０】
アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースとし、前記ユースケースを複数蓄積したデータベースであるユースケース知識ベースから抽出された複数のユースケース候補と、
アプリケーションから次操作の予測の要求であるサービス要求に基づく依頼信号に基づいて、逐次入力されるユーザ操作から依頼時点での操作実績パスである依頼時実績パスと、
を取得し、依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するユースケース候補適合度算出部と、
を備えたことを特徴とする操作予測装置。
【請求項１１】
ユースケース候補適合度算出部が、アプリケーションから次操作の予測の要求であるサービス要求による依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスと、前記アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースを複数蓄積したデータベースであるユースケース知識ベースから複数のユースケース候補と、を取得するステップと、
前記ユースケース候補適合度算出部が、前記依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するステップと、
を含む操作予測方法。
【請求項１２】
操作実績変換部が、逐次入力されるユーザ操作から、アプリケーションに対するユーザ操作であるＵＩリソースと前記モデル要素との対応を示すデータベースであるＵＩリソース−モデル要素対応表を用いて前記モデル要素を取得し、前記モデル要素の時系列の履歴である操作実績パスを生成して出力するステップと、
操作履歴ベースが、前記操作実績変換部から入力された前記操作実績パスを格納するステップと、
インターフェースが、前記アプリケーションから次操作の予測の要求であるサービス要求を解釈して、前記サービス内容に従ってユースケース候補適合度算出部へ依頼信号を出力するステップと、
ユースケース候補適合度算出部が、前記依頼信号に基づいて、依頼時点での前記操作実績パスである依頼時実績パスを前記操作履歴ベースから取得するステップと、
前記ユースケース候補適合度算出部が、前記依頼信号に基づいて、前記アプリケーションに対するユーザの利用目的に応じて、前記アプリケーションの機能を満たすための操作履歴を、状態または遷移の情報を含むモデル要素及びその組み合わせであるユースケースを複数蓄積したデータベースであるユースケース知識ベースから複数のユースケース候補を取得し、依頼時実績パスと前記複数のユースケース候補とから依頼時操作実績パスとの適合度を算出し、最も適合度の高いユースケース候補を予測結果として出力するステップと、
インターフェースが、前記予測結果から、次に遷移する内容と遷移先の情報を示すモデル要素について前記ＵＩリソース−モデル要素対応表を用いて前記アプリケーションのＵＩリソースに対する操作形式に変換し、アプリケーション形式予測結果として前記アプリケーションへ出力するステップと、
を含む操作予測方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−１７０６７２（Ｐ２０１１−１７０６７２Ａ）
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１０−３４６２２（Ｐ２０１０−３４６２２）
【出願日】平成２２年２月１９日（２０１０．２．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２２年２月１９日（２０１０．２．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]