JPH0836548A

JPH0836548A - システム状況情報管理装置

Info

Publication number: JPH0836548A
Application number: JP6169334A
Authority: JP
Inventors: Takashi Ishitani; 高志石谷
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 1994-07-21
Filing date: 1994-07-21
Publication date: 1996-02-06

Abstract

(57)【要約】【構成】クライアント１２，１３からの要求に応じて
システムとして管理する情報の提供を行ったり、低次元
デバイスとクライアントとのインターフェースを司るシ
ステム基幹部１１と、さまざまなデータ情報を管理する
管理部８，９及び記憶するための情報ファイル１５，１
６とのデータベース機構を備え、クライアント１２，１
３からシステム基幹部１１に対する操作手順，命令を時
系列に従って履歴情報として履歴情報ファイル１５，１
６に保存しておき、システム基幹部１１が管理する情報
をクライアント１２，１３に対して提示する際に、保存
しておいた操作履歴情報，命令履歴情報を参照すること
により、クライアント１２，１３に提示する情報を変
更，加工，修正するものである。【効果】種々の形態を持ったシステム状況情報管理モ
ジュールをシステム側に持たせ、クライアントへの情報
提供を行う前にシステム状況に対応させて情報の修正を
行い、クライアント側ではシステム側から提供された情
報に基づいて、クライアント本来の処理を行うだけでよ
い。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コンピュータ等の情報
処理装置，ワードプロセッサ等の文書作成支援装置に適
用されるシステム状況情報管理装置に関するものであ
る。

【０００２】

【従来の技術】クライアント（部）からの要求としてヘ
ルプを取り上げた場合、ユーザーが現在使用しているモ
ードに応じたヘルプを提示することはなされている。こ
れは、各クライアントがモードを持っており、それに応
じたヘルプ文書をクライアントが選択し、表示すること
により、実現されているものが多い。

【０００３】履歴情報の利用に関しては、検索などを行
なう際に過去の履歴情報を参照することにより、検索条
件の設定を調整する機構がとられることが多い。

【０００４】例えば、特開平３ー２９６８３７号公報に
記載された「文書検索方法」では、データベースに対す
る更新・削除などの操作履歴を記憶しておき、この操作
履歴を元にしてデータベースの再現を行なうことで、任
意の時点でのデータベース検索を可能にしている。ま
た、特開平４ー４７３６６号公報に記載された「文書検
索方法」では、データベースに再現用履歴情報と出来事
の履歴情報をリンクして保持し、出来事の内容から履歴
情報を検索することによって、出来事発生時点を特定
し、データベースを再現している。

【０００５】

【発明が解決しようとする課題】例えば、コンピュータ
等の情報処理装置において、クライアント（部）が、或
る動作を行う場合、必要な情報をシステムに要求し、提
示された情報によって次のクライアントの動作が決まる
場合、システムはクライアントからの要求に対して、た
だ単に求められたものを提示するだけでは、状況に即し
た情報を提示することができず、その情報を元にして動
作するクライアントの動作は時間的に固定的なものにな
る。

【０００６】従来、このようなシステムの元で動作する
クライアントを幅広く、状況に応じて動的に動作するよ
うに対応させようとすると、クライアント内にモードを
保存し、クライアントが自分自身でモードを管理するだ
けではなく、ユーザーの操作履歴やクライアント自身の
挙動の履歴などあらゆる情報を保存しておく必要がある
とともにそのような情報から、現在の状況を推測し、次
の挙動を決めていくといった複雑なモジュールを組み込
まなくてはならない。たとえ、それができたとしても、
ユーザーからシステムに対して直接行なわれた操作や、
他のクライアントに対して行なわれた操作状況、さらに
他のクライアントとシステムや他のクライアント同士で
行なわれた命令履歴などを得ることは、システム部に管
理部をおかない限り、不可能である。

【０００７】例えばヘルプシステムにおいては、上記の
従来技術のように、同じモードを使っている場合におい
ても、それぞれのユーザーのその時点での独自の目的が
有り、その目的を達成するための手段・方法が不明であ
る時にヘルプを参照することが多い。このとき、モード
によって一意に決まる項目を提示した場合、ユーザーへ
いらだたしさを感じさせる原因となっていた。また、オ
ンラインヘルプシステムにおいては、さまざまなクライ
アントに応じてヘルプデータは存在する必要があるが、
そのうち、どのデータをどのように提示するかについて
は、各クライアントが判断しようとすると、システム的
な情報やユーザーの挙動に関する情報を取得することが
できず、それぞれのクライアント内で閉じた情報にのみ
基づいたヘルプ情報の提示しかできない。

【０００８】

【課題を解決するための手段】上述のような問題点を解
決する手段として、本発明では、さまざまな形態を持っ
たシステム状況情報管理モジュールをシステム側に持た
せ、クライアント（部）への情報提供を行なうまえにさ
まざまなシステム状況に対応させて情報の修正を行な
い、クライアント側ではシステム側から提供された情報
に基づいて、クライアント本来の処理を行なうだけで良
いようにしている。

【０００９】請求項１では、システム状況情報管理モジ
ュールで管理する情報として、クライアントからシステ
ムに対する命令履歴情報を保存，管理し、命令履歴情報
に基づいて、システム状況情報に対して修正を加えた上
でクライアントシステム情報を提供する。請求項２で
は、システム状況情報管理モジュールで管理する情報と
して、ユーザーのクライアントに対する操作履歴情報を
保存しておくことにより、操作履歴情報に基づいて、シ
ステム状況情報に対して修正を加えた上でクライアント
システムに情報を提供する。

【００１０】請求項３では、システム状況情報管理モジ
ュールで管理する情報として、ユーザーの個人情報を保
存しておくことにより、個人情報に基づいて、システム
状況情報に対して修正を加えた上でクライアントシステ
ムに情報を提供する。請求項４では、システム状況情報
管理モジュールで管理する情報として、クライアントか
らシステムに対する命令履歴情報とユーザーのクライア
ントに対する操作履歴情報を保存しておくことにより、
両者を統合して判断し、システム状況情報に対して修正
を加えた上でクライアントシステムに情報を提供する。

【００１１】請求項５では、システム状況情報管理モジ
ュールで管理する情報として、クライアントからシステ
ムに対する命令履歴情報とユーザーの個人情報を保存し
ておくことにより、両者を統合して判断し、システム状
況情報に対して修正を加えた上でクライアントシステム
に情報を提供する。

【００１２】請求項６では、システム状況情報管理モジ
ュールで管理する情報として、ユーザーのクライアント
に対する操作履歴情報とユーザーの個人情報を保存して
おくことにより、両者を統合して判断し、システム状況
情報に対して修正を加えた上でクライアントシステムに
情報を提供する。

【００１３】請求項７では、システム状況情報管理モジ
ュールで管理する情報として、クライアントからシステ
ムに対する命令履歴情報とユーザーのクライアントに対
する操作履歴情報とユーザーの個人情報を保存しておく
ことにより、３つの管理情報を統合して判断し、システ
ム状況情報に対して修正を加えた上でクライアントシス
テムに情報を提供する。請求項８では、クライアントに
対して提示するヘルプデータをシステム状況情報に応じ
て適切に変更したうえで提示する。

【００１４】請求項９では、単なるユーザー操作履歴情
報では、実際にユーザーがどの項目を過去に参照したの
かがわからなくなるおそれがあるため、ユーザーが参照
したヘルプ項目をヘルプ参照履歴情報として保存してお
く。請求項１０では、システム状況情報管理部が利用す
るデータとして、請求項９で保存したヘルプ参照履歴情
報を用い、クライアントに対して提示するヘルプデータ
を変更する際に利用するようにするものである。

【００１５】請求項１１では、あらゆる命令をあらかじ
めベクトル表現化して、命令履歴情報を保存する際、命
令をそのままの命令名としてではなく、ベクトル表記化
して保存する。請求項１２では、あらゆる命令をあらか
じめクラスわけしておき、命令履歴情報を保存する際
に、命令をそのままの命令名としてではなく、命令の属
するクラス名により保存する。

【００１６】請求項１３では、履歴情報，個人情報，そ
の他システム情報などのシステム状況情報をあらかじめ
ベクトル表記化しておき、クライアントに対して提示す
る際、提示情報をベクトル表記化し、ベクトルにより提
示する。請求項１４では、個人情報の一つであるユーザ
ーのスキル情報をあらかじめベクトル表記化しておき、
クライアントに対して提示する際に、分野毎のスキルを
各要素に持つベクトル表記化したスキル情報により提示
する。

【００１７】請求項１５では、クライアントに対してシ
ステム側が提示した情報がユーザーあるいはクライアン
トによって拒否された場合、次回の提示時には、同じ情
報をトップ候補として提示することのないように学習す
る。このようにシステム内に状況情報管理部を有するこ
とで、ユーザーの操作状況や履歴情報、個人情報などの
統一的な情報管理を行なうとともに、ある時点での最適
な情報の選択・提示を行なうとともに、管理している情
報のレベルを適当な形に加工したり、学習したりするこ
とができる。

【００１８】

【作用】請求項１乃至請求項７では、システム状況情報
管理部が管理する履歴情報や個人情報などによって、ク
ライアントに対して提示する情報を変更することによっ
て、クライアントが、ある時点で本当に必要な情報を簡
単に得ることができる。請求項８乃至請求項１０では、
システム状況情報として同種の情報は、同じベクトル表
現や同じクラスに属することになり、若干の情報の違い
による情報提示方法を吸収することができる。

【００１９】請求項１１乃至請求項１４では、システム
状況情報として同種の情報は、同じベクトル表現や同じ
クラスに属することになり、若干の情報の違いによる情
報提示手段を吸収することができる。請求項１５では、
システム状況情報管理部が適当として提示した情報であ
っても、クライアントやユーザーには受け入れ難い情報
の場合がある。このような場合で、他に候補が存在する
ならば、提示情報をそちらに変更するなどの学習を行な
うことで、クライアントの処理変更をなくすことができ
る。上述したように、状況情報管理装置により、システ
ム内の様々な種類の情報をシステムとして総合的に判断
し、最も最適な情報を各クライアントが利用することが
できるようになる。また、ユーザーは利用しているアプ
リケーションに関係なく利用情報，個人情報が常に反映
されているため、アプリケーション毎に個人設定を行な
う必要がなくなる。

【００２０】

【実施例】本発明では、実施例の１つとして、ヘルプを
表示する機構を備えた文書編集システム（エディタ）を
クライアント（部）とするシステムにより説明する。代
表的なハードウェア構成の例は図１のようになる。符号
１はＣＰＵ、２はマウス，ペン，キーボードなどのユー
ザーからの入力デバイスの制御を司るＫｅｙＣＰＵ、３
は表示装置に直結したＶＲＡＭ、４はプログラムやデー
タ格納のためのＲＡＭメモリ、５はプログラム格納ＲＯ
Ｍメモリ、６は外部ファイルデバイスとの入出力ポート
を表わし、これらがバスを通じて結合されている。ま
た、入出力ポート６からは、記憶メディアの他にネット
ワークが接続される場合もある。この場合、ネットワー
クの先には、２次記憶（とその管理システム）やクライ
アントが存在する場合もある。

【００２１】本発明のシステム構成は図２に示すように
なる。図２において、符号７は状況情報管理部、８は操
作履歴管理部、９は命令履歴管理部、１０は個人情報管
理部、１１はシステム基幹部、１２，１３はクライアン
トであるが、ここでは、１２をユーザー操作主体となる
クライアントＡ、１３をユーザーへの情報提示を行なう
クライアントＢとする。１４〜１７は情報格納部で、１
４は実際にクライアントに提示する元データを全て格納
し、１５は２からアクセスされる操作履歴情報を格納
し、１６は３からアクセスされる命令履歴情報を格納
し、１７はメモリ４により管理される個人情報を格納す
るファイルである。本システムは、ネットワークを経由
したネットワークファイル管理システムやファイルサー
バーを用いたシステムとすることも可能であるが、構成
上、同一に考えることができるので、図２には明示して
いない。

【００２２】本実施例によるヘルプ表示機構を備えた文
書編集システムに適用したシステム構成は、図３とな
る。図３では、図２の符号１２，１３，１４がクライア
ントの具体例に置き換えたものであり、１２は文書エデ
ィタ（クライアントＡ）、１３はヘルプアプリケーショ
ン（クライアントＢ）、１４はヘルプ文書（提示情報）
である。本システムの動作フローを図４，図６を用いて
説明する。なお、従来のシステムでは、フロー図中、２
重線で囲ったステップが存在しない。図４は、文書エデ
ィタ（クライアントＡ）の操作履歴を記録する時の動作
フローを表す。ここで操作履歴とは、いつ、誰が、どの
ような操作をおこなったかを逐一記録したもので、時間
情報とユーザーの操作情報とをペアにして、ユーザー毎
に管理されたファイルなどに記録することが多く、ここ
でもつぎのステップ２で示すように、履歴情報ファイル
に格納していく。命令履歴など他の履歴情報についても
同様であり、命令履歴であれば、「操作」の記述が、
「命令」に変わっている。まず、ステップ（以下に
「Ｓ」と略す）１で、ユーザーが文書エディタ１２に対
して編集や入力などの操作を行うと、Ｓ２で、操作履歴
管理部がユーザーの操作情報を取得し、履歴情報ファイ
ル１５へ格納する。ユーザーの操作情報とは、対象とす
るアプリケーションによって異なるが、例えば、あるメ
ニューを選択したとか、１字抹消キーを押したとかその
他ユーザーがクライアントに対してアクションするさま
ざまな操作情報を取得／格納する。これは操作履歴管理
部２がイベント部をフックすることで実現できる。

【００２３】つぎに、Ｓ３で、文書エディタ１２がユー
ザーの操作に基づいて、システム１１へ命令を発行する
と、Ｓ４で命令履歴管理部９が命令を取得し、時間情報
とともに履歴情報ファイル１６へ格納する。Ｓ５でシス
テム１１がクライアントからの命令に基づいて実行し、
命令実行結果を命令発行元の文書エディタ１２へ返し、
Ｓ７で文書エディタ１２がシステムの命令実行結果に対
する処理を施し、場合によっては画面表示の変更やユー
ザーへの処理結果の提示を行なう。

【００２４】上記動作フロー中、Ｓ４において、命令履
歴管理部９が履歴情報ファイル１６へ格納する命令は、
時間情報をつけた命令自体でも構わないが、命令をそれ
ぞれの命令に応じたベクトル表記化することにより、同
じ方向を持ったベクトルや命令間の距離などの、履歴情
報検索時の処理が簡単なベクトル演算により算出可能と
なる。ベクトル化の手法については、命令を多くの要素
に分解し、因子分析する手法などがある。これは請求項
１１に該当する。

【００２５】また、同じくＳ４において、命令をクラス
タリング手法などによってクラス分けを行ない履歴情報
ファイル１６へ格納することにより、履歴情報検索時の
検索処理が、命令クラスというあらかじめ分類された構
造によって行なうことができ、処理の高速化や同じ実行
結果をもたらす別命令などを吸収することができる。こ
れは請求項１２に該当する。

【００２６】図５に、履歴情報ファイル１６の例を示
す。（ａ）は命令と時間情報だけが入った基本的な情報
ファイルの例、（ｂ）は命令をベクトル表記した例、
（ｃ）は命令をクラス分けして格納した情報ファイルの
例を示している。図の履歴ファイルの例では、各行毎に
１つの命令履歴を表しており、命令実行時の時間情報と
して日付と時間が各行の先頭の２フィールドに記録され
ている。（フィールドとは、連続する空白またはタブ記
号で区切られた連続する文字列の固まりをいう。）ま
た、‘＃’記号から行末までは、わかりやすくするため
につけた注釈であり、本来の履歴情報に含まれるもので
はない。

【００２７】（ａ）に示した基本的な履歴情報ファイル
の例では、各行の時間情報の次の第３フィールドに命令
名、第４フィールド以降に命令に対する引数が記録され
ている。

【００２８】（ｂ）に示したベクトル表記した履歴ファ
イルの例では、各行の第３フィールドに命令のベクトル
表記したものが記録されている。ベクトル表記した履歴
を後で処理のために利用する場合には、このフィールド
のデータが用いられる。この例で示したベクトル表記の
方法は、ベクトルであることを表すためのタグ（”＠Ｃ
ｏｍＶＥＣ”）とその後ろの括弧の中にベクトルの各数
値要素をコンマで区切って並べている。

【００２９】ベクトル表記の仕方としては、これに限る
ものではなく、さまざまな表現法がありうるが、ここで
は表現法に関しては、なんら特定するものではない。し
たがって、この例ではベクトルは３つの要素（３字元）
で表しているが、システムによっては、何次元にしても
構わない。命令をベクトル化するための手法としてもさ
まざまなものが考えられ、例えば、いろいろな観点から
抽出し、設定した分類属性（仮に２５６属性とする。）
に対して、各命令がどの属性をもつかを調査し、それを
多変量解析の一つである主因子分析法に基づいて解析を
行なうと命令を分類するに必要な要素を導き出すことが
できる。（仮に３ベクトル導いたとする。）この主要素
を各ベクトル成分として、各命令をその属性から表現す
ることにより、命令をベクトル表記にすることができ
る。（ここではこのようにして３次元になっている。）
履歴情報ファイルの第４フィールド以降には各命令実行
時の引数を記述してある。ただし、通常この情報はあと
の処理で用いないことが多いので、記述しておかなくて
も良い。

【００３０】（ｃ）に示したクラスわけした履歴情報フ
ァイルの例では、各行の第３フィールドに命令のクラス
表記したものが記録されている。クラス表記した履歴情
報を後で処理のために利用する場合には、このフィール
ドのデータが用いられる。この例で示したクラス表記の
方法は、クラスであることを表すためのタグ（”＠Ｃｏ
ｍＣｌ”）とその後ろの括弧の中にクラスを表す文字列
が記述されている。クラスは断層的に構成され、クラス
の各断層は上位から順にピリオド（”．”）で区切った
クラス名を記述していく。第４フィールド以降には各命
令実行時の引数を記述してある。ただし、通常この情報
はあとの処理で用いないことが多いので、記述しておか
なくても良い。

【００３１】図６は、ヘルプアプリケーション（クライ
アントＢ）にて情報の提示を行なう際の、提示情報の生
成に関する動作フローを表している。まず、Ｓ１１でヘ
ルプアプリケーション１３がシステム１１へユーザーへ
の提示情報の提供を求める。この例では、提示情報はヘ
ルプ文書を指している。Ｓ１２でシステム１１は情報提
供命令を受け付けると、状況情報管理部７へ情報提供命
令を発行し、情報の提供を待つ。Ｓ１３で状況情報管理
部７は他の情報管理部からよせられる情報を元に全ての
ヘルプ文書が格納された提示情報１４から該当する情報
のみを取り出し、Ｓ１４でシステム１１へ返す。これを
受けて、Ｓ１５でシステム１１はヘルプアプリケーショ
ン１３へ提示情報を返し、Ｓ１６でヘルプアプリケーシ
ョン１３はユーザーに獲られた提示情報を提示する。

【００３２】上記過程において、後述するＳ１３の状況
情報管理部７の機構によって、提示情報を変更すること
ができ、これは請求項１〜８に相当する。上記Ｓ１１に
おいて、ヘルプアプリケーション１３がシステム１１へ
提示情報の要求命令を発行する過程は、上述した履歴記
録時の例における対象が文書エディタに代わってヘルプ
アプリケーションにおきかわっており、命令履歴管理部
９により履歴情報に記述することができる。この場合、
ヘルプアプリケーションの独自操作履歴としてユーザー
が参照したヘルプ項目をユーザーが参照した時間情報と
ともに履歴情報として記述するため、ヘルプアプリケー
ションは疑似的なシステムへの命令を発行することによ
り実現できる。このようにして記録したヘルプ参照履歴
は以後、システム内での履歴情報として利用することが
できる。これは請求項９，１０に該当する。

【００３３】上記Ｓ１４において状況情報管理部７から
提示する情報の形態は、通常、提示する情報そのものの
形式であるが、情報をベクトル表記化することによっ
て、次に上げる特徴を持つ。（１）伝達情報量の圧縮情報を伝達する場合、そのままの情報を送ると、たとえ
ば、次のようなそれぞれの場合が考えられる。文字列として送る場合：１文字のサイズ×文字数（ｎ）アスキー文字（１ｂｙｔｅ）では、ｎｂｙｔｅ必要ＩＤ化して送る場合：ＩＤの最大値＝情報の種類数情報数が６５，０００種類であれば、２ｂｙｔｅ必要しかし、現実的には、すべての命令をシステムで統一し
たＩＤ化すること自体が非常に困難なため、現実的では
ない。それに対して、情報のベクトル化を行なうと、３字元８レベルの場合：１つの要素の取り得る値の範囲
を８段階に設定したとすると、８段階を表すのに３ｂｉ
ｔ必要であるから、３×３＝９ｂｉｔ必要４字元１６レベルの場合：１つの要素の取り得る値の範
囲を１６段階に設定したとすると、１６段階を表すのに
４ｂｉｔ必要であるから、４×４＝１６ｂｉｔ＝２ｂｙ
ｔｅ必要このようにベクトル化することによって、ベクトル要素
数と量子化レベル（各要素を表す数値の範囲）を適当な
値に決めることにより、ベクトル化を行わない時の現実
的方法である文字列による情報提示に比べて情報量の圧
縮を行なうことができる。また、ベクトル化を行なう際
に重要な要素となるベクトル要素数や量子化レベルは、
分析法とどこまで分類するかと言う決断によっていくら
でも情報量を押えることができる。

【００３４】（２）ユーザー提示時の情報の加工を容
易にするベクトル化することによって、提示すべき情報が同じ系
統（ベクトル方向）のものであるかどうかが、容易に判
別できる。したがって、細かい実際の命令名までも区別
して処理を行なう必要のある場合を除いて、処理を簡単
にすることができる。すなわち、細かい命令名までも区
別して処理を行なう必要性が少ない場合により効果があ
る。

【００３５】（３）クライアントでの情報の選択の幅
を残す厳密な情報をクライアントに対して提示すると、クライ
アントはその厳密な情報に基づいて処理の分岐を行なう
必要があり、命令の違いによって処理が明らかなことと
なり、また、明確に分離される。

【００３６】ベクトル化した情報を提示することによっ
て、クライアント側でベクトル方向成分のみを対象にし
た処理の分岐を行なうこともできるし、ベクトルの大き
さを対象にした処理の分岐を行なうこともできるし、あ
るいは、両者を合わせて、ベクトル空間内での位置や領
域による分岐などが可能であり、さらにこれらの処理が
簡単なベクトル演算で可能にある。このことで、クライ
アント側でこれらの判断基準をさまざまに設けることで
簡単でしかも幅の広い処理の選択を行なうことができ
る。

【００３７】（４）ベクトル情報同士の演算が可能前項（３）でも記述したとおり、処理の判断に、単なる
文字列比較などを行なうのではなく、ベクトルとしての
演算として判断をできる。また、複数の情報同士の演算
も可能となる。ベクトルの演算として、基本的なものに
は、加減および内積などがある。

【００３８】情報のベクトル表記化を行なうための手段
の１つとして、あらかじめ抽出しておいた情報の主要要
素をベクトルの要素とし、各情報にそれぞれの要素がど
の程度含まれているかを設定しておき、これをベクトル
として利用する手法や因子分析した結果を利用する手法
が上げられる（履歴情報における命令のベクトル表記化
の手法の場合と同じ手法の適用も可能。）。これは請求
項１３に該当する。

【００３９】上記図６の情報提示時の全体動作フロー中
のＳ１３の状況情報管理部７の動作内容を、図７に示す
フローを用いて説明する。Ｓ１１で状況情報管理部７は
操作履歴管理部８へ操作履歴情報を要求する。このとき
要求する操作履歴情報は、場合により異なって良いが、
例えば、最新のＮ個の操作履歴を求めたり、ある時点か
らの操作情報を頻度毎に求めたりすることができる。

【００４０】同様に、図７に示すＳ２２で、命令履歴管
理部９へは命令履歴情報の要求を行なう。ここで要求す
る命令履歴についてもＳ２１で操作履歴管理部８へ求め
た方法と同様、最新Ｎ個や頻度情報などがある。つぎに
Ｓ２３で個人情報管理部１０へ個人情報を要求する。個
人情報管理部１０が管理する個人情報には、現在使用し
ているユーザーや登録されているユーザーとそれぞれの
クライアントに応じたスキル情報、情報の好みなどが含
まれている。Ｓ１３で要求する個人情報についても限定
することはできないが、その１例として現在利用してい
るユーザーの文書エディタ（クライアントＡ）に対する
スキルをｎ段階表記で返すこととする。Ｓ２４で状況情
報管理部７は各情報管理部から得られた情報を元に、適
当な提示情報を判定し、Ｓ２５で提示情報１４から該当
する情報を取り出す。

【００４１】つぎにＳ２５において、他の情報管理部か
ら得られた情報によって提示情報を判定する手法につい
て具体例を示す。（ａ）他の１つの情報管理部から得られる非ベクトル
情報にもとづく判断手法の例まず、一番最初（履歴情報と過去に提示した提示情報が
ない）に情報提示を行なう場合には、過去の実績がない
ため、クライアントが欲する情報に対してなんの加工を
行なうこともせずに提供する。たとえば、クライアント
がヘルプデータの要求を行なってきたとする。ヘルプデ
ータは、あらかじめクライアント毎、および、モードや
キーワードによるインデックスは付けられており、クラ
イアントのモードや欲しい機能名などによるキーワード
検索はヘルプデータ管理部にて行なうことができる。こ
のとき状況情報管理部７は、ヘルプデータを要求してき
たクライアントから現在のモード情報を取得し、そのモ
ード情報を記述するヘルプデータをヘルプ管理部より取
得し、そのままクライアントに提示する。

【００４２】情報管理部では、いつどのような状況情報
の元でどのような情報を提示し、それが受け入れられ
たかどうかをすべて記録（保存）しておくか、あるい
は、このような状況情報と提示情報との関連を管理する
ための情報管理部で管理しておく。この例では、提示し
たヘルプデータとその時の状況情報が記録される。つぎ
にクライアントが再度ヘルプデータを要求してきたとす
ると、この場合には、履歴情報や以前にどのような情報
を提示したかという情報が残っているので、現在の状況
とどのような状況の元でヘルプを提示した過去の履歴情
報がないかを調査し、“同じような状況”の元での提示
があり、かつ、それが受け入れられていれば、その情報
を提示する。もし、過去に複数の同じ状況でのこととな
る提示情報が存在したなら、もっとも最近に提示したも
のか、あるいはもっとも多く提示している情報を第１候
補として提示する。

【００４３】最近の候補と最多の候補のうちどちらを選
択するかについては、次式で表される計算式の値の大き
い方とし、α，βという重み係数は、どちらにどの程度
の重みをおくかによる経験値により決まる。最近提示情報の指数：α×（提示情報時点までの現在か
らの経過時間）最多提示情報の指数：β×（提示情報の提示回数） “同じような状況”の判定の方法は、個々の情報につい
てのマッチングは文字列のマッチングでしかできない
が、履歴情報の時系列方向については、｛マッチングをとる履歴時間の長さ＝Ｌｍａｔｃｈ｝｛マッチングしない情報を認める数＝Ｎｍｉｓｓ｝をキーにする。このため、全く同じ時系列がなく、Ｎｍ
ｉｓｓ個以下なら別の情報が間にはいっていても、“同
じ状況”と判断することができる。それでも“同じよう
な状況”が存在しなければ、一番最初に提示したアルゴ
リズムと同様ヘルプ管理部より素直に得たデータを提示
する。

【００４４】（ｂ）他の１つの情報管理部から得られ
るベクトル情報にもとづく判断手法の例基本的なプロセスは前項（ａ）と同じ。ただし、得られ
た情報がベクトル情報であるので、マッチングのとり方
が異なる。現在のベクトル化された状況情報Ｖｎｏｗと
過去のベクトル化されて保存されている状況情報｛Ｖ
０，Ｖ１，Ｖ２，・・・Ｖｍ｝とが同じかどうかを判定
するための具体的な手法の例を次にあげる。

【００４５】ベクトル距離による方法：ベクトルの距離
計算を行ない、その値がある閾値Ｌｔｈ以下であれば、
同じとする。（次式） │Ｖｎｏｗ−Ｖｍ│≦Ｌｔｈここで、Ｌｔｈ＝０とするとベクトルが全く一致する場
合を意味する。

【００４６】ベクトルの距離計算は、二乗和による距
離、要素毎の差の絶対値の和による距離などがある。

【００４７】ベクトル方向による方法：ベクトルの大き
さは無視し、方向成分のみの比較を行ない、それがある
閾値Ａｔｈ以下であれば、同じとする。（次式） │ａｎｇｌｅ（Ｖｎｏｗ）−ａｎｇｌｅ（Ｖｍ）│≦Ａ
ｔｈただし、ここで、ａｎｇｌｅ（Ｖ）は、ベクトルｖの方
向成分を取り出す関数を意味する。

【００４８】ここで、Ａｔｈ＝０とすると、方向成分が
全く一致するマッチングになる。ベクトルの大きさによ
る方法：ベクトルの方向成分は無視し、大きさのみの比
較を行ない、それがある閾値Ｒｔｈ以下であれば、同じ
とする。（次式） ││Ｖｎｏｗ│−Ｖｍ││≦Ｒｔｈここで、Ｒｔｈ＝０とすると、大きさが全く一致するマ
ッチングになる。

【００４９】（ｃ）複数の情報管理部から得られる非
ベクトル情報にもとづく判断手法の例基本的なプロセスは、（ａ）の場合と同じだが、判定す
るための状況情報が複数あるため、マッチングをとる場
合にすべての状況情報同士のマッチングをとる必要があ
る。この場合、すべての状況情報が全く一致する場合
や、部分的な情報のみが一致する場合があるため、それ
ぞれの状況情報に対して情報の重みづけを行なってお
き、一致した情報の重み係数を加えたものを情報のマッ
チング度として算出する。これを時系列に沿って行な
い、マッチング度の総和が大きいものからマッチしたと
して判定する。

【００５０】（ｄ）複数の情報管理部から得られるベ
クトル情報にもとづく判断手法の例基本的なプロセスは、（ａ）の場合と同じであり、ま
た、複数の状況情報に対する処理は（ｃ）、ベクトル同
士のマッチング処理方法は（ｂ）と同じ手法により判定
を行なう。

【００５１】上記Ｓ２４において提示情報を判定する手
段として、Ｓ２１〜Ｓ２３で得られた情報を入力とし提
示情報種を出力とするニューロモデルを利用することが
できる。この手段を用いることで、入力情報が動的に変
わることに対応して出力も動的に変化し、その過程はあ
らかじめ行なった学習に依存するのみで、困難な規制作
りを行なう必要がない。さらに、学習過程をあらかじめ
行なうだけでなく、システム動作中に行なうことで初期
学習を省き、ユーザーの要望に合わせた提示情報を選び
出すようにできる。本実施例ではヘルプアプリケーショ
ン１３がユーザーへ情報提示後、その情報に対するユー
ザーの反応を聞き、その反応を状況情報管理部へフィー
ドバックすれば実現できる。これは請求項１５に該当す
る。ここでは、文書編集システムにおけるヘルプ情報の
提示を例にとり実施例を説明したが、何らかの情報・デ
ータをユーザーあるいは他のシステムやクライアントに
提供するシステムになら同様に適用することができる。

【００５２】

【発明の効果】請求項１乃至請求項７では、さまざまな
形態を持ったシステム状況情報管理モジュールをシステ
ム側に持たせ、クライアントへの情報提供を行なうまえ
にさまざまなシステム状況に対応させて情報の修正を行
ない、クライアント側ではシステム側から提供された情
報に基づいて、クライアント本来の処理を行なうだけで
良いようにしている。さらにある時点で本当に必要な情
報をクライアントに特別な処理を組み込むことなしに、
簡単に得ることができる。

【００５３】請求項８乃至請求項１０では、ヘルプデー
タの管理をシステム側の状況情報管理部に持たせること
により、ヘルプデータを各クライアントが管理する必要
をなくし、さらにユーザー操作履歴や他のシステム状況
情報によって、最適なヘルプデータをクライアントが得
ることができる。請求項１１乃至請求項１４では、シス
テム状況情報として同種の情報は、同じベクトル表現や
同じクラスに属することになり、若干の情報の違いによ
る情報提示方法を吸収することができる、伝達情報量の
圧縮，情報の容易な加工の実現，クライアントでの選択
の幅の広い情報提供，ベクトル化による情報同士の演算
が可能という効果を得ることができる。

【００５４】請求項１５では、システム状況情報管理部
が適当として提示した情報であっても、クライアントや
ユーザーには受け入れ難い情報の場合に対し、他に候補
が存在するならば、提示情報をそちらに変更するなどの
学習を行なうことで、クライアントの処理変更をなくす
ことができる。このように状況情報管理装置により、シ
ステム内の様々な種類の情報を総合的に判断し、最も最
適な情報を提示することができ、かつ、この情報をどの
ようなクライアントも簡単に利用することができる。

【図面の簡単な説明】

【図１】本発明の一実施例である文書編集システムのハ
ードウェア構成例を示す図である。

【図２】本発明の一実施例である文書編集システムのシ
ステム構成例を示す図である。

【図３】本発明の一実施例である文書システムのヘルプ
システム構成例を示す図である。

【図４】本装置の履歴記録時の全体動作フローチャート
である。

【図５】本装置の履歴情報ファイルの例を示す図であ
る。

【図６】本装置の情報提示時の全体動作フローチャート
である。

【図７】本装置の状況情報管理部の動作フローチャート
である。

【符号の説明】

１ＣＰＵ２マウス，ペン，キーボードなどのユーザーからの入
力デバイスの制御を司るキーＣＰＵ３ビデオＲＡＭ４ＲＡＭ５ＲＯＭ６入出力ポート７状況情報管理部８操作履歴管理部９命令履歴管理部１０個人情報管理部１１システム基幹部１２クライアントＡ（エディタ）１３クライアントＢ（ヘルプアプリケーション）１４提示情報ファイル１５操作履歴情報ファイル１６命令履歴情報ファイル１７個人情報ファイル

Claims

【特許請求の範囲】

【請求項１】ユーザーインターフェイス部を介してユ
ーザーとのインタラクションをとり、あるいはユーザー
インターフェース部を持たずに、システムから得られる
情報に基づいて目的とする処理を行うクライアントと、
該クライアントからの要求に応じてシステムとして管理
する情報の提供を行ったり、低次元デバイスとクライア
ントとのインターフェイスを行うシステム基幹部と、種
々のデータ情報を管理記憶するデータベース機構部とを
備え、クライアントからシステム部に対する命令を時系
列にしたがって命令履歴情報として履歴情報ファイルに
格納しておき、上記システム基幹部が管理する情報をク
ライアントに対して提示する際に、時系列にしたがって
格納された命令履歴データを参照することにより、クラ
イアントが求める情報を情報提供する毎に、変更，加
工，修正することを特徴とするシステム状況情報管理装
置。
【請求項２】上記ユーザーインターフェース部をクラ
イアントに対しては、ユーザーのクライアントに対する
操作手順を履歴情報として履歴情報ファイルに格納して
おき、システム基幹部が管理する情報をクライアントに
対して提示する際に、格納されていたユーザーの操作履
歴情報を参照することにより、クライアントに提示する
情報を変更することを特徴とする、請求項１に記載のシ
ステム状況情報管理装置。
【請求項３】ユーザーを識別する機能を持ち、ユーザ
ー毎にユーザーの性別，年令，種々のスキル情報などの
ユーザーが明示的に設定した情報および学習機構などに
より自動あるい半自動的に設定された個人情報を格納し
ておくことにより、システム基幹部が管理する情報をク
ライアントに対して提供する際に、格納しておいた個人
情報を参照することにより、クライアントに提示する情
報を変更することを特徴とする、請求項１に記載のシス
テム状況情報管理装置。
【請求項４】クライアントからシステムに対する命令
を時系列にしたがって格納した命令履歴情報と、ユーザ
ーインターフェース部を持つクライアントに対するユー
ザー操作手順を格納したユーザー操作履歴情報を一括管
理し、両情報を統合し判断する機構を有し、システム基
幹部が管理する情報をクライアントに対して提供する際
に、命令操作履歴情報とユーザー操作履歴情報を統合し
た判断にもとづいて、提示情報をその度毎に変更するこ
とを特徴とする、請求項１に記載のシステム状況情報管
理装置。
【請求項５】ユーザー識別機構を持つシステムにおい
て、クライアントからシステムに対する命令を時系列に
したがって保存した命令履歴情報と、ユーザー毎に設定
された個人情報とを一括管理し、両情報を統合して判断
する機構を有し、システム基幹部が管理する情報をクラ
イアントに対して提供する際に、命令操作履歴情報とユ
ーザー毎の個人情報を統合した判断に基づいて、情報提
示毎に提示情報を変更することを特徴とする、請求項２
に記載のシステム状況情報管理装置。
【請求項６】ユーザー識別機構を持つシステムにおい
て、ユーザーインターフェース部を持つクライアントに
対するユーザー操作手順を保存したユーザー操作履歴情
報と、ユーザー毎に設定された個人情報とを一括管理
し、両情報を統合して判断する機構を有し、システム基
幹部が管理する情報をクライアントに対して提供する際
に、ユーザーがクライアントに対して行なった操作の履
歴情報と、ユーザー毎の個人情報を統合した判断に基づ
いて、情報提示毎に提示情報を変更することを特徴とす
る、請求項２に記載のシステム状況情報管理装置。
【請求項７】ユーザー識別機構を持つシステムにおい
て、クライアントからシステムに対する命令履歴情報
と、ユーザーインターフェース部を持つクライアントに
対するユーザー操作手順を保存したユーザー操作履歴情
報と、ユーザー毎に設定された個人情報とを一括管理
し、該命令履歴情報，該ユーザー操作履歴情報および個
人情報の三者を統合して判断する機構を有し、システム
基幹部が管理する情報をクライアントに対して提供する
際に、クライアントからシステムに対して発行された命
令履歴情報と、ユーザーがクライアントに対して行なっ
た操作履歴情報と、ユーザー毎の個人情報を統合するこ
とで、総合的な判断の元、情報提示の度に提示情報を変
更することが可能な機構を持つことを特徴とする、シス
テム状況情報管理装置。
【請求項８】ユーザーに対するヘルプ画面の表示機構
を有するシステムにおいて、ユーザーに対して提示すべ
きヘルプ内容データを管理する状況情報管理部を有し、
ユーザーからの要求やクライアントあるいはシステム基
幹部の判断によりヘルプ表示を行なう際、上記状況情報
管理部から得られるデータに基づき、その時点に応じた
ヘルプデータを検索し、提示することを特徴とする、請
求項１に記載のシステム状況情報管理装置。
【請求項９】ユーザー操作履歴情報とヘルプデータを
ユーザーに提示し、またユーザーに対してヘルプ操作の
インターフェースを提供するヘルプクライアントに対し
て、ユーザー操作からヘルプ項目への変換を行った上、
参照したヘルプ項目としてユーザー操作履歴情報を保存
して置くことを特徴とする、請求項２に記載のシステム
状況情報管理装置。
【請求項１０】ユーザーが過去に参照したヘルプ項目
のユーザー操作履歴情報を利用して、次回の提示すべき
ヘルプデータを変更し得ることを特徴とする、請求項９
に記載のシステム状況情報管理装置。
【請求項１１】クライアントからシステムに対する命
令履歴情報を保存する過程において、命令をそのままの
命令名としてではなくベクトル表記化して保存し、検索
やその他命令履歴情報に対する管理を行うことを特徴と
する、請求項１に記載のシステム状況情報管理装置。
【請求項１２】クライアントからシステムに対する命
令履歴情報を保存する過程において、命令をクラス分け
しておくことにより、命令を命令名としてではなく命令
の属するクラス名により保存し、管理することを特徴と
する、請求項１に記載のシステム状況情報管理装置。
【請求項１３】クライアントに対して、履歴情報，個
人情報，その他システム情報などのシステム状況情報を
提示する手段として、提示情報をベクトル表記化し、ベ
クトルにより提示することを特徴とする、請求項３に記
載のシステム状況情報管理装置。
【請求項１４】ユーザー毎の個人情報の１つとして管
理する、ユーザーのスキル情報を保存，検索，管理し、
また必要に応じてクライアントに提示する際、分野毎の
スキルを各要素に持つベクトル表記化したスキル情報を
用いることを特徴とする、請求項３に記載のシステム状
況情報管理装置。
【請求項１５】上記システム状況情報の提示におい
て、提示した情報がユーザーあるいはクライアントによ
って拒否された場合、次回の提示時には、同じ情報をト
ップ候補として提示することのないように学習すること
を特徴とする、請求項１０に記載のシステム状況情報管
理装置。