JP2009123148A - 作業担当者選択装置およびその方法 - Google Patents

Abstract

【課題】複数人の処理によって処理がなされるシステムによって、依頼元・依頼先のユーザ間の関係、あるいは情報の受け手である依頼先の状態に応じて、情報の受け手にとっての受容性が変わることへ対応する。
【解決手段】本発明は、処理依頼を行う際に、依頼先のユーザの感情情報及び感情情報の変化履歴をベースにして、依頼先の状態を推定する。あるいは、必要に応じて、今までの依頼元のユーザの依頼タイミング履歴と合わせることで依頼元・依頼先のユーザ間の関係と考える。これらの情報に基づき、通知先、あるいは、通知タイミングを判断する。これにより、複数人による作業の進捗をスムースにすることが可能となるという利点がある。
【選択図】図７

Description

本発明は、分散システムを利用した設計・開発業務のプロジェクトマネジメントや人対人によるサービス業務の担当者割り振りにおいて提供される機能であり、作業の割り振りを行う作業管理システムに関する。

感情情報に基づき、業務支援を行うシステムが実用に供されている。

ユーザが共有された情報を利用する際における感情状態を推定し、情報に対するラベルとして利用する。このラベルに基づき、共有先のユーザ選択時の条件として利用するものである(特許文献１)。

特開２００３−１９６５４６号公報

しかしながら、上記特許文献１に開示されている、推定した感情状態は、登録された情報のラベリングに用いるものである。そのため、通知先のユーザや、あるいは、ユーザ間の関係性に基づく感情変化に基づくものではなく、作業を滞りなく進捗させるという点で問題があった。

解決しようとする問題点は、ユーザ間の関係、あるいは情報の受け手の状態に応じて、情報の受け手にとっての受容性が変わることへの対応が難しい点である。

本発明は、処理依頼を行う際に、依頼先のユーザの感情情報とその履歴を管理し、あるいは、今までの依頼元のユーザの依頼タイミング履歴と合わせて、その情報から依頼先、あるいは、依頼タイミングを判断することを最も主要な特徴とする。

本発明の具体的態様は、システム利用者の感情状態情報を履歴として管理する管理テーブルとシステム利用者が行う作業の内容である担当業務情報を格納する業務情報テーブルとを設け、作業の要求に応答して、業務情報テーブルを参照して、要求された作業に対応するシステム利用者を選択し、選択されたシステム利用者から、管理テーブルを参照し、それまでの作業通知時点における感情状態情報の変化が最もよいシステム利用者を選択する作業担当者選択装置及びその方法である。

本発明によれば、処理依頼を行う際に、依頼先のユーザの感情情報、及び、感情情報の変化履歴をベースにして、必要に応じて、今までの依頼元のユーザの依頼タイミング履歴と合わせて、通知先、あるいは、通知タイミングを判断することにより、複数人による作業の進捗をスムースにすることが可能となるという利点がある。

本発明を実施するための最良の形態は、処理を依頼する際に、依頼先となるユーザの感情情報、および、感情情報の変化履歴を蓄積し、必要に応じて、今までの依頼元のユーザの依頼タイミング履歴と組み合わせることで、通知先、あるいは、通知タイミングを判断することである。

図１は、実施例1のシステム構成図である。本実施例はワークフローを活用して作業の進捗を管理する際に、どのユーザに割り振るかを決定する方式に関する。サーバ１は作業フローの管理を行い、かつ、作業フローの構成要員の感情情報を収集する。サーバ１はネットワーク２経由で、構成要員が操作する端末であるクライアント(パーソナルコンピュータ)３、及び構成要因の感情情報の元となる収集を行うセンサ４と接続される。

図２は、システムを構成するソフトウェア構成図である。サーバ１−クライアント３間、あるいは、サーバ１−センサ４間でのデータのやり取りを行う通信１１がサーバ１、クライアント３、及びセンサ４に存在する。サーバ１には、センサ４からが取得した情報を収集し、収集した情報をユーザ毎に分けて管理する情報蓄積１２、及びワークフローの管理を実現するフロー管理１３がある。さらには、サーバ１には、情報蓄積１２、および、フロー管理１３によって管理される情報に基づき、次のフローに進むにあたり、どのユーザが適切かを判定する優先度判定１４がある。クライアント３には、ユーザからの要求に応じて、フロー管理１３とやり取りを行い、フローを進めるための要求を出す処理１５とセンサ４の情報収集に誰のデータとして蓄積すべきか指示する機器管理１６がある。

機器管理１６はクライアント３の立ち上げ時に選択したユーザに応じて、センサ４への要求を出す。あるいは、処理１５へのユーザのログインに応じて、センサ４への要求を出してもよい。機器管理１４は周期的にログインメッセージの通知を行い、ログアウト時にもその旨をセンサ４にその旨を通知する。なお機器管理１４は構成するセンサ４についての情報を初回立ち上げ時、もしくは、必要に応じて設定する。

センサ４には、センシングした情報を蓄積し、サーバ１の情報蓄積１２に送信する情報収集１７がある。情報収集１７は、機器管理１６からの要求に基づき、情報を送付するため、該当するユーザがログアウトしている際には通知されない。ここで、指定時間ログインメッセージの通知が来ない場合にもログアウトしているものと認識する。

図３は、ユーザ毎の想定されるステータスを示すユーザの感情状態のテーブル構成図である。このテーブルは、本システムのユーザの識別子であるユーザＩＤ２１に対応したユーザの感情状態を示すステータス２２、及び感情状態の強さを示す強度２３からなる。本データは、図４（後述）に示すステータスイベントログに基づき生成されるデータである。また、本データは、ユーザのクライアント３へのログインに応じて生成され、ユーザのクライアント３へのログアウトに応じて削除される。なお、このデータはユーザからのログインがあってから、ユーザ毎に定周期で更新してもよく、あるいは、システム全体として定周期で更新してもよい。

ここで、センサ４が強度２３まで取得できる場合には、図３のデータをヒストリとして管理してもよい。すなわち、そうしたケースの場合には、図３、図４のデータをあわせて図１１のように管理する。すなわち、センサ４がイベントを検出した場合にデータを収集し、それを履歴として管理する。さらには、ユーザがシステムにログイン・ログアウトなどの利用開始・終了したイベントについても、このテーブルの中で管理してもよい。ここで、イベントが検出された時刻である検出時刻６１（図１１）を見て、ユーザは最新のイベントの感情情報であると推定する。さらに、検出されていない時刻については、前後のイベントから推定(線形の値とするなど)してもよい。

図４は、ユーザの感情（ステータス）イベントログのテーブル構成図である。このテーブルは、本システムのユーザの識別子であるユーザＩＤ２１とそのイベントを検知したセンサ４の識別子である機器ＩＤ３１、検出したイベントの種類であるステータス２２、検出開始時刻である開始時間３２、検出終了時刻である終了時間３３からなる。

本システムにて検出されるステータス２２はセンサ４の情報収集１７にて判断される。たとえば、センサ４がマイクである場合には、音声情報に応じて感情情報を抽出する。音声からの感情情報の抽出は、韻律リズムから発話者の感情・情動情報を推定するAGI社の 「Sensibility Technology」(http://www.agi-web.co.jp/)などに記載される。あるいは、独り言の回数が多くなった場合にストレスがかかっていると認識してもよい。独り言の判定としては、指向性マイクを利用し、音声が発生された前後一定時間(たとえば10秒間程度)に他の方向から音声を認識できなかった場合としてもよい。この回数が通常より多くなっている場合にストレスがかかっていると認識する。すなわち通常時のデータが正規分布であると仮定し、９５％信頼区間より外れるデータが得られた場合に、ストレスがかかっていると認識する。あるいは一定期間における独り言の音量データや長さデータの群と他の時間(通常時と認定)のデータ間でｔ検定することで評価してもよい。ここで、通常時と認定する際には、脳波計測をしながら、α波が出ているときの独り言データを通常データとして利用してもよい。あるいは、唾液中のクロモグラニンＡの測定を業務遂行前後で実施することにより、通常時データを採取するとしてもよい。ここで、通常時と同等である場合にはリラックス状態と認識する。

センサ４がキーボードである場合には、打鍵音が通常時と比較して大きくなったり、スピードが上がった場合、あるいは、バックスペースまたはデリートキーを通常より多く(回数、あるいは割合)押した場合にストレスがかかっていると認識する。すなわち通常時のデータが正規分布であると仮定し、９５％信頼区間より外れるデータが得られた場合に、ストレスがかかっていると認識する(図９参照。平均１分に３回押し、標準偏差が２のケースを表記。この場合は平均６回以上となったケースでストレスがかかっていると判定する。)。あるいは一定期間におけるキー押下からキー解除までの時間のデータ、あるいは、一回のキー入力における圧力値の群と他の時間(通常時と認定)のデータ間でｔ検定することで評価してもよい。ここで、通常時と認定する際には、脳波計測をしながら、α波が出ているときの打鍵データを通常データとして利用してもよい。あるいは、唾液中のクロモグラニンＡの測定を打鍵前後で実施することにより、通常時データを採取するとしてもよい。ここで、通常時と同等である場合にはリラックス状態と認識する。

センサ４がカメラである場合には、小刻みな動作回数が通常時と比較して多いときにはストレスがかかっていると認識してもよい。動きベクトルの方向変化回数が大きく、かつ、動き量が小さい場合に小刻みな動作と認識する。この回数が通常より多くなっている場合にストレスがかかっていると認識する。すなわち通常時のデータが正規分布であると仮定し、９５％信頼区間より外れるデータが得られた場合に、ストレスがかかっていると認識する。あるいは一定期間における独り言の音量データや長さデータの群と他の時間(通常時と認定)のデータ間でｔ検定することで評価してもよい。ここで、通常時と認定する際には、脳波計測をしながら、α波が出ているときの独り言データを通常データとして利用してもよい。あるいは、唾液中のクロモグラニンＡの測定を業務遂行前後で実施することにより、通常時データを採取するとしてもよい。

ここで、図４にて蓄積された感情イベントログのテーブルのレコードからの図３の過去一定時間における感情情報の推定においては、過去一定時間のイベントログ情報に基づき計算がなされる。ステータス２２種別ごとのステータス検出時間(終了時間３３から開始時間３２を引く)の累積により求める。ここで、複数ステータスがある場合には、該当するステータスと判定された積算時間の比率に応じて強度を計算してもよく、あるいは、一番累積が多いステータスの累積時間としてもよい。あるいは、一定時間内に送出されたすべてのステータス２２種別ごとにレコードを保持してもよい。

図５は、本システムにて保持される業務情報のテーブル構成図である。ユーザID２１とユーザが実施することの出来る業務の種類を示す業務種別４１毎にレコードを持つ。レコードには１階層目の承認者である一次承認者４２、２階層目の承認者である二次承認者４３がある。一次承認者４２、二次承認者４３は複数あってもよい。また、三次承認者、四次承認者と必要に応じて拡張してもよい。通知先となるユーザID21毎に電子メールアドレス、内線電話番号などの連絡手段についての情報を持つなどしてもよい。

図６に、業務毎の処理履歴情報のテーブル構成図を示す。業務の識別子である業務ID５１とその業務を開始したユーザID21、業務の種別である業務種別41を持つ。さらには、その業務のステータス変化時点ごとにレコードを持つために、処理されたステータスである処理ステータス５２、処理したユーザIDを示す処理ユーザ５３、処理した日時を示す処理日時５４を持つ。なお、処理ステータス５２には、業務の開始を示す「作成」、処理の承認したことを示す「承認」、処理を拒絶したことを示す「拒絶」、処理をスキップしたことを示す「スキップ」、最終的な処理終了を示す「終了」などがある。

図７に、これらのデータを活用して業務の通知先を判断する処理フローを示す。本処理フローにおいて、まず、処理の登録を行う（ST１）。処理の登録はクライアント３の処理１５によって要求され、サーバ１のフロー管理４３により、図６に示す処理履歴情報のテーブルへの登録処理がなされる。図５の業務情報のテーブルに示される通知先情報であるユーザIDや電子メールアドレスなどの連絡手段が取得される（ST２）。通知先となるユーザID毎の感情情報である図３の情報をサーバ1の情報蓄積１２により取得する（ST３）。それでOKかどうかという判定基準の確認をサーバ1の優先度判定１４とクライアント３の処理１５が連携して行う（ST４）。

本判定基準はユーザに対してGUIで問い合わせるとしてもよい。あるいは、ユーザが初回立上げ時、あるいは、要求を出した際に設定した例えばリラックス状態で強度５７以上といった閾値情報に基づいてもよい。あるいは、通知先ユーザIDを一つ以上指定し、そのユーザIDのユーザの感情の強度が閾値情報を越えた場合にOKとするとしてもよい。あるいは、これらの情報のログを保持しておき、過去一年間の平均値から判断するとしてもよい。また、過去一年間の利用時間数(ログアウトからログインを引いた総時間)で重み付けをした上で、平均値をとり判断してもよい。あるいは、過去一年間の感情情報のステータスから分散値を取得し、上記条件を満たすユーザのうち、分散値がもっとも少ないユーザを優先度の最も高いユーザとしてもよい。あるいはこの分散値で重み付けをした上で、平均値を取ってもよい。あるいは、今までの作業通知履歴から通知時点前後の感情状態変化が良好(ステータスがリラックスの場合には強度がプラスに変化し、その幅が大きいケース。ステータスがストレスの場合には強度がマイナスに変化し、その幅が大きいケース)となったユーザから判断してもよい。

ここで、今までの作業通知履歴から判断する際に、要求元となっているユーザからの作業通知に限定して評価をしてもよい。さらには、大元のユーザが一致する作業通知に限定して評価してもよく、また、大元のユーザが一致し、かつ、要求元のユーザが一致する作業通知に限定して評価してもよい。

ここでOKでないとすると感情情報が変化するまで待つ（ST５）。この処理は優先度判定１４と情報蓄積１２が連携して行う。

OKであれば、通知先となるユーザが利用するクライアント３の処理１５により、業務情報の通知処理を行う。業務情報の通知処理においては、添付ファイルの送付をしてもよく、あるいは、メッセージのみの送付としてもよい。

図８に、これらのデータを活用して業務の通知タイミングを判断する処理フローを示す。本処理フローにおいては、まず、処理の登録を行う（ST１１）。本登録はクライアント３の処理１５によって要求され、サーバ１のフロー管理13により、図６に示す処理履歴情報のテーブルへ登録される。図５の業務情報のテーブルに示される通知先情報であるユーザIDや電子メールアドレスなどの連絡手段が取得される（ST１２）。続いて、処理１５により、通知条件を設定する（ST１３）。

ここで設定する条件としては、ユーザID２１を選択し、ステータス２２と通知すべき強度２３を設定する。この情報は図３と同等である。あるいは、ユーザID２１のみを指定し、該当するユーザがログインしたらすぐ通知するとしてもよい。あるいは、先回同じ種別の処理を行ったときの判定条件を流用してもよい。あるいは、今までの作業通知履歴から、通知時点前後の感情状態変化が良好(ステータスがリラックスの場合には強度がプラスに変化し、その幅が大きいケース。ステータスがストレスの場合には強度がマイナスに変化し、その幅が大きいケース。)となったケースや通知時点後の感情状態が良好のケースを選択し、通知時点前の感情状態を閾値として設定してもよい。こうした評価をする際に、要求元となっているユーザからの作業通知に限定して評価した後に設定してもよい。さらには大元のユーザが一致する作業通知に限定して評価してもよく、また、大元のユーザが一致し、かつ、要求元のユーザが一致する作業通知に限定して評価した後に、設定してもよい。

通知先となるユーザID毎の感情情報である図３の情報をサーバ1の情報蓄積１２により取得する（ST１４）。これらの情報のログを保持しておき、過去一年間の平均値を取得するとしてもよい。あるいは、過去一年間の利用時間数(ログアウトからログインを引いた総時間)で重み付けをした上で、平均値をとり取得するとしてもよい。あるいは、該当する通知先のユーザの感情がよい基準として、処理却下頻度が一定値以下であるという指定をしてもよい。あるいは、該当する通知先のユーザが疲れている基準として、処理却下頻度が一定値以上となるという指定をしてもよい。

それでOKかどうかという判定基準の確認をサーバ1の優先度判定１４とクライアント３の処理１５が連携して行う（ST１５）。本判定基準はST１３にて設定した条件に基づく。OKでないならば、ST１４に戻る。この処理は優先度判定１４と情報蓄積１２が連携して行う。OKならば、通知先となるユーザが利用するクライアント３の処理１５により、業務情報の通知処理を行う(ST16)。

ここで、業務情報の通知処理においては、添付ファイルの送付をしてもよく、あるいは、メッセージのみの送付としてもよい。あるいは、ここではST１３にて条件を設定したクライアント３の処理１５を通じてユーザに最終通知OKか否かの問い合わせを行ってもよい。あるいは、ST１３にて条件を設定した該クライアント３の処理１５を通じてユーザに通知するのみとしてもよい。ここで、今までの作業通知履歴から通知時点の感情変化時点前後の感情状態変化が良好でないケースには、通知元であるユーザID２１を通知せずに処理依頼メッセージの送付をするとしてもよい。あるいは一定時間後に、該当するメッセージの送付元を通知するとしてもよい。あるいは、ユーザID２１への通知メッセージが複数ある場合には、過去の履歴から感情変化履歴が良好なメッセージから通知するように通知順序を制御してもよい。

これらのシステムはワークフローに適用するのではなく、作業担当者の割り振りに適用してもよい。本実施例は医療・介護・健康分野などにおける従事者の担当するサービス受益者を決定する方式に関する。なお、システム構成などは実施例１と同等のものでよく、管理されるデータとしては、図５の一次承認者４２が作業の割り振り先の候補者となり、かつ、図５のユーザＩＤ２１に示すユーザが、作業担当者が担当する対象のユーザとなる。

なお、本実施例では、図５のユーザＩＤ２１は処理の登録を行ったユーザではない。あるいは、図５のユーザＩＤ２１が処理の登録をするユーザとしてもよく、その場合には、図５の一次承認者４２が作業の割り振り先の候補者となる。また、その場合には、図６で管理される業務ＩＤ５１を作業担当者が担当する対象のユーザとしてもよい。

図１０に、作業が発生した場合の担当者の割り振り処理フローを示す。本処理フローにおいては、まず処理を登録する（ST２１）。本登録はクライアント３の処理１５によって要求され、サーバ１のフロー管理13により、図６に示す処理履歴情報のテーブルへの登録処理がなされる。図５の業務情報のテーブルに示される、サービス受益者であるユーザＩＤ２１に加えて、通知先であるユーザIDや電子メールアドレスなどの連絡手段が取得される（ST２２）。これらのユーザID毎の感情情報である図３の情報をサーバ1の情報蓄積１２により取得する（ST２３）。それでOKかどうかという判定基準の確認をサーバ1の優先度判定１４とクライアント３の処理１５が連携して行う（ST２４）。

本判定基準はユーザに対してGUIで問い合わせるとしてもよい。あるいは、システムの初回立上げ時、該ユーザＩＤ２１の登録時点、あるいは、要求を出した際に設定した例えばリラックス状態で強度５７以上に両者がなっている組といった閾値情報に基づいてもよい。あるいは、今までの作業実施履歴から実施時点前後の感情状態変化が良好(ステータスがリラックスの場合には強度がプラスに変化し、その幅が大きいケース。ステータスがストレスの場合には強度がマイナスに変化し、その幅が大きいケース。)となったユーザから判断してもよい。ここで、作業担当候補者、作業担当者が担当する対象となるユーザの組で限定して、過去の履歴から判断してもよい。あるいは、処理を登録したユーザ、作業担当候補者、作業担当者が担当する対象となるユーザの組で限定して、過去の履歴から判断してもよい。

ここでOKでないならば、感情情報が変化するまで新規担当者候補者の登録処理を行う（ST25）。この処理はフロー管理１３、および処理１５が連携して行う。OKならば、通知先となるユーザが利用するクライアント３の処理１５により、業務情報の通知処理を行う（ST26）。ここで、業務情報の通知処理においては、添付ファイルの送付をしてもよく、あるいは、メッセージのみの送付としてもよい。

本実施の形態は、分散システムを利用した、プロジェクトマネジメントや担当者の割り振り支援などにおいて、進捗支援機能の一形態として適用することが出来る。

実施例のシステム構成図である。 実施例のソフトウェア構成図である。 ユーザの感情状態のテーブル構成図である。 ユーザの感情イベントログのテーブル構成図である。 業務情報のテーブル構成図である。 業務毎の処理履歴情報のテーブル構成図である。 業務の通知先を判断する処理のフローである。 業務の通知タイミングを決定する処理のフローである。 キーボードのBackspace/Deleteキーを押下した回数の平均値の分布例を示す図である。 担当者の割り振り処理のフローである。 ユーザイベントログのテーブル構成図である。

符号の説明

１：サーバ、２：ネットワーク、３：クライアント、４：センサ、１１：通信、１２：情報蓄積、１３：フロー管理、１４：優先度判定、１５：処理、１６：情報収集。

Claims (14)

1. システム利用者の感情状態情報を履歴として管理する管理テーブル、前記システム利用者が行う作業の内容を示す担当業務情報を格納する業務情報テーブル、作業の要求に応答して、前記業務情報テーブルを参照して、前記要求された作業に対応する前記システム利用者を選択する第1の選択手段、及び前記第１の選択手段によって選択された前記システム利用者から、前記管理テーブルを参照し、それまでの作業通知時点における感情状態情報の変化が最もよい前記システム利用者を選択する第２の選択手段を有することを特徴とする作業担当者選択装置。
2. 請求項１に記載の作業担当者選択装置において、前記作業を要求する要求者も前記システム利用者として、その感情状態情報を履歴として前記管理テーブルで管理し、前記第２の選択手段は、前記第１の選択手段によって選択された前記システム利用者から、前記管理テーブルを参照し、それまでの前記要求者からの作業通知時点における感情状態情報の変化が最もよい前記システム利用者を選択することを特徴とする作業担当者選択装置。
3. 請求項２に記載の作業担当者選択装置において、前記システム利用者の所有するパーソナルコンピュータのキーボードの入力情報、前記システム利用者の近傍に設置されたマイクで検知する音声情報、及び前記システム利用者の近傍に設置されたカメラで検知する画像情報の少なくとも一つ以上の情報に基づいて、前記システム利用者の感情状態情報を推定する手段を有し、前記推定結果を前記管理テーブルに格納することを特徴とする作業担当者選択装置。
4. 請求項３に記載の作業担当者選択装置において、前記第２の選択手段は、前記管理テーブルに格納されている感情状態の、（1）平均値が最もよい、及び（2）分散値が最も小さいのいずれか一つに基づいて、前記システム利用者を選択することを特徴とする作業担当者選択装置。
5. 請求項３に記載の作業担当者選択装置において、前記第２の選択手段により選択された前記システム利用者の感情状態及び作業に対する却下頻度を取得し、前記取得した前記システム利用者の（1）感情状態が一定値以上及び（2）作業に対する却下頻度が一定値以下になった際に前記作業を通知する通知手段を有することを特徴とする作業担当者選択装置。
6. 請求項３に記載の作業担当者選択装置において、前記第２の選択手段により選択された前記システム利用者に対して、それまでの前記要求者からの作業通知時点における感情状態情報の変化が一定値以下の場合に前記要求者の情報を秘匿する手段を有することを特徴とする作業担当者選択装置。
7. 請求項３に記載の作業担当者選択装置において、前記第２の選択手段により選択された前記システム利用者に関し、前記管理テーブルを参照し、それまでの前記要求者からの作業通知時点における感情状態情報の変化および前記システム利用者の感情状態に基づき、通知する情報の順序を制御する手段を有することを特徴とする作業担当者選択装置。
8. 管理テーブルにシステム利用者の感情状態情報を履歴として管理し、業務情報テーブルに前記システム利用者が行う作業の内容である担当業務情報を格納し、作業の要求に応答して、前記業務情報テーブルを参照して、前記要求された作業に対応する前記システム利用者を選択し、前記選択された前記システム利用者から、前記管理テーブルを参照し、それまでの作業通知時点における感情状態情報の変化が最もよい前記システム利用者を選択することを特徴とする作業担当者選択方法。
9. 請求項８に記載の作業担当者選択方法において、前記作業を要求する要求者も前記システム利用者として、その感情状態情報を履歴として前記管理テーブルで管理し、前記業務情報テーブルを参照して選択された前記システム利用者から、前記管理テーブルを参照し、それまでの前記要求者からの作業通知時点における感情状態情報の変化が最もよい前記システム利用者を選択することを特徴とする作業担当者選択方法。
10. 請求項９に記載の作業担当者選択方法において、前記システム利用者の所有するパーソナルコンピュータのキーボードの入力情報、前記システム利用者の近傍に設置されたマイクで検知する音声情報、及び前記システム利用者の近傍に設置されたカメラで検知する画像情報の少なくとも一つ以上の情報に基づいて、前記システム利用者の感情状態情報を推定し、前記推定した結果を前記管理テーブルに格納することを特徴とする作業担当者選択方法。
11. 請求項10に記載の作業担当者選択方法において、前記管理テーブルに格納されている感情状態の、（1）平均値が最もよい、及び（2）分散値が最も小さいのいずれか一つに基づいて、前記業務情報テーブルを参照して選択された前記システム利用者から前記システム利用者を選択することを特徴とする作業担当者選択方法。
12. 請求項10に記載の作業担当者選択方法において、前記業務情報テーブルを参照して選択された前記システム利用者の感情状態及び作業に対する却下頻度を取得し、前記取得した前記システム利用者の（1）感情状態が一定値以上及び（2）作業に対する却下頻度が一定値以下になった際に前記作業を通知することを特徴とする作業担当者選択方法。
13. 請求項10に記載の作業担当者選択方法において、前記業務情報テーブルを参照して選択された前記システム利用者に対して、それまでの前記要求者からの作業通知時点における感情状態情報の変化が一定値以下の場合に前記要求者の情報を秘匿することを特徴とする作業担当者選択方法。
14. 請求項10に記載の作業担当者選択方法において、前記選択された前記システム利用者に関し、前記管理テーブルを参照し、それまでの前記要求者からの作業通知時点における感情状態情報の変化および前記システム利用者の感情状態に基づき、通知する情報の順序を制御することを特徴とする作業担当者選択方法。

Images