(57)【特許請求の範囲】
【請求項１】
協同作業に関係する人物を含む周囲の状況を撮影して画像を入力するための画像入力手段を有する複数の情報処理装置と、
前記複数の情報処理装置の間で相互に情報の送受信を行なう通信手段とを有し、
前記情報処理装置は、
前記画像入力手段によって入力された画像をもとに、画像中に含まれる人物が誰であるかを個人認証すると共に個人認証された人物の現在の状況を判別し、前記人物とこの人物の現在の状況とを表わす状況情報を生成し、前記通信手段を介して他の情報処理装置に送信する状況情報変換手段と、
何れかの情報処理装置における前記状況情報変換手段によって生成された状況情報を前記通信手段を介して受信し、前記人物の現在の状況に応じて、協同作業に関係する人物の中で協同作業に参加可能な人物を決定し、前記参加可能な人物に対するメッセージを生成して前記通信手段を介して何れかの情報処理装置に提供する応用サービス提供手段と
を具備したことを特徴とする協同作業調整装置。
【請求項２】
前記応用サービス提供手段は、
前記状況情報変換手段によって生成され前記通信手段を介して送信される状況情報から、協同作業に関係する人物についての状況情報を受信して蓄積する状況情報参照手段と、
協同作業の依頼入力と、入力された依頼に応じた協同作業の調整結果についての応答出力を行なうアプリケーション入出力手段と、
前記アプリケーション入出力手段によって入力された依頼に応じて、前記状況情報参照手段に蓄積された状況情報を用いて協同作業の調整を行なうアプリケーション制御手段と、
前記アプリケーション制御手段による協同作業の調整結果に応じて、協同作業に関係する人物に対してメッセージを通知するアクション作成手段とを具備したことを特徴とする請求項１記載の協同作業調整装置。
【請求項３】
前記アプリケーション制御手段は、
前記アプリケーション入出力手段によって入力された協同作業の依頼に含まれる協同作業条件を記憶するための協同作業情報記憶手段と、
前記協同作業情報記憶手段に記憶された協同作業条件に基づいて、協同作業の関係者についての状況情報をもとに協同作業の時間調整を行なう当日時間管理手段とを具備したことを特徴とする請求項２記載の協同作業調整装置。
【請求項４】
前記当日時間管理手段は、
協同作業の関係者についての状況情報をもとに、各人についての協同作業への参加受入れの可能性を示す依頼受託評価値と、前記依頼受託評価値に基づく協同作業の開催の適当性を示す開催評価値とを求めて、協同作業の調整を行なうことを特徴とする請求項３記載の協同作業調整装置。
【請求項５】
複数の前記応用サービス提供手段の間で、ある応用サービス提供手段で実行するプロセスを再帰的に分割し、分割された部分プロセスを他の応用サービス提供手段において起動することで、部分プロセスの処理結果を共通利用することを特徴とする請求項１記載の協同作業調整装置。
【請求項６】
画像入力手段を有する複数の情報処理装置が通信手段を介して互いに接続された情報処理システムにおいて、
前記情報処理装置において、
前記画像入力手段から協同作業に関係する人物を含む周囲の状況を撮影して画像を入力し、この入力された画像をもとに、画像中に含まれる人物が誰であるかを個人認証すると共に個人認証された人物の現在の状況を判別し、前記人物とこの人物の現在の状況を表わす状況情報を生成して、前記通信手段を介して何れかの情報処理装置に送信し、
この送信された状況情報が表わす人物の現在の状況に応じて協同作業に関係する人物の中で協同作業に参加可能な人物を決定し、
この決定された参加可能な人物に対するメッセージを生成して前記通信手段を介して何れかの情報処理装置に提供する協同作業調整方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、計算機ネットワークが整備されたオフィス環境等において利用されるもので、協同作業、例えば会議などの運営を支援する協同作業調整装置及び協同作業調整方法に関する。
【０００２】
【従来の技術】
近年、オフィス環境には計算機ネットワーク環境が整備され、一人に一台の計算機システムを保有することは当り前になった。また、マルチメディア環境も急速に発展している。一方、各種システムはますます複雑化、増大化しており、こうしたシステムを開発する場合など、個人作業でなく協同作業を必要とする状況はますます増加している。
【０００３】
協同作業、特に会議などの重要性はますます増加しており、またネットワーク環境の整備やマルチメディア環境が発達してきていることから、ネットワークを介したマルチメディア会議（離れた場所どうしで画像や音声をやりとりして行なう会議）なども行なわれるようになって来ている。
【０００４】
しかしながら、その会議の日程や時間を決める段階では、発起人が会議に出席すべき各メンバ（協同作業の参加者）に、電話なり手紙なりで各人のスケジュールを聞き出して調整すると言った、昔ながらの作業方法がしばしばとられている。この作業によって会議に出席すべき全員を招集するためには、一旦全員のスケジュールを確実に聞き出し、日程と時間を決めた上で、再度全員に伝達事項（日程、時間等）を確実に伝えなければならない。すなわち、全員との間で、情報をやりとりをする必要が少なくとも２回発生するために、大きな作業負担となっており、特に会議の出席者が多くなると膨大な作業量となってしまう。
【０００５】
伝達事項を全員に確実に伝える方法としては、ページャ等の各メンバが携帯する通信機器へメッセージを送信すれば良いため比較的作業負担は軽い。従って、作業負担を軽減するためには、いかに全員の予定を把握し、会議を開催する日程と時間を適切に設定するかという点にかかっている。
【０００６】
従来、会議出席者全員の予定を把握し、会議を開催する日程と時間を適切に設定する方法として、計算機ネットワークが整ったオフィス環境等において、各メンバが自己のスケジュールを計算機に入力し、そのデータを元にスケジュール自動調整装置が会議の開催時間を決める方法が提唱されている（例えば：”松下温、岡田謙一：コラボレーションとコミュニケーション（共立出版）（１９９５）”のグループ電子手帳（ＴｅａｍＤｅｓｋ））。この方法であれば、電話や手紙などを用いて会議出席者のスケジュールを収集する必要がないため作業負担は軽減される。
【０００７】
しかし、各自が自己のスケジュールを計算機に入力するのは、日付レベルでの予定の登録までが限界であって、その日の細かい時間的スケジュールを予め入力する事は、（１）手間がかかり煩わしい、（２）仕事の進み具合により予定は頻繁に変更されるので真のスケジュールを入力することは実際上不可能、（３）計算機に入力したスケジュールの修正が遅れてしまうと多忙であるにも関わらず強制的に呼出しを受ける場合がある、などの問題がある。
【０００８】
しかし、協同作業を行なう当日においてスケジュール調整を行なう場合、すなわち協同作業を行なう時間（特に開始時間）を決定するためには、各メンバの時間的仕事状況が把握できなければ、調整することは不可能である。
【０００９】
【発明が解決しようとする課題】
このように従来では、会議等の協同作業を行なう時間を調整する場合には、協同作業の参加者のスケジュールを、電話や手紙等を用いて収集し、それに基づいて日程と時間を決定した上で、伝達事項を参加者全員に通知していたために作業負担が大きかった。
【００１０】
また、計算機ネットワークが整ったオフィス環境等において、協同作業の参加者のそれぞれに自己のスケジュールを入力させることで、スケジュール自動調整装置によって自動的に各参加者のスケジュールを収集して調整を行なう方法もあるが、参加者に各自のスケジュールを入力する作業を強いるものであるため、日付レベルでの予定の登録までが限界であって、日程的なスケジュールの調整を行なう事はできても、時間的なスケジュールの調整を行なうことが困難となっていた。
【００１１】
本発明は前記のような事情を考慮してなされたもので、協同作業の参加者に特別な作業を強いることなく、時間的なスケジュールまでを確実かつ容易に調整することが可能な協同作業調整装置及び協同作業調整方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明に係る協同作業調整装置は、協同作業に関係する人物を含む周囲の状況を撮影して画像を入力するための画像入力手段を有する複数の情報処理装置と、前記複数の情報処理装置の間で相互に情報の送受信を行なう通信手段とを有し、前記情報処理装置は、前記画像入力手段によって入力された画像をもとに、画像中に含まれる人物が誰であるかを個人認証すると共に個人認証された人物の現在の状況を判別し、前記人物とこの人物の現在の状況とを表わす状況情報を生成し、前記通信手段を介して他の情報処理装置に送信する状況情報変換手段と、何れかの情報処理装置における前記状況情報変換手段によって生成された状況情報を前記通信手段を介して受信し、前記人物の現在の状況に応じて、協同作業に関係する人物の中で協同作業に参加可能な人物を決定し、前記参加可能な人物に対するメッセージを生成して前記通信手段を介して何れかの情報処理装置に提供する応用サービス提供手段とを具備したことを特徴とする。
【００１３】
これにより、画像入力手段から入力された画像情報から得られる現在の状況を表わす状況情報に基づいて、協同作業の開始時間等の調整を行ない、適切なタイミングで適切な情報を通知することができる。
【００１４】
また、前記応用サービス提供手段は、前記状況情報変換手段によって生成され前記通信手段を介して送信される状況情報から、協同作業に関係する人物についての状況情報を受信して蓄積する状況情報参照手段と、協同作業の依頼入力と、入力された依頼に応じた協同作業の調整結果についての応答出力を行なうアプリケーション入出力手段と、前記アプリケーション入出力手段によって入力された依頼に応じて、前記状況情報参照手段に蓄積された状況情報を用いて協同作業の調整を行なうアプリケーション制御手段と、前記アプリケーション制御手段による協同作業の調整結果に応じて、協同作業に関係する人物に対してメッセージを通知するアクション作成手段とを具備したことを特徴とする。
【００１５】
これにより、協同作業の参加者ではない第３者（グループ外の人）から、グループに協同作業の依頼をする場合に、アプリケーション入出力手段を用いることで協同作業の調整できる。
【００１６】
また前記アプリケーション制御手段は、前記アプリケーション入出力手段によって入力された協同作業の依頼に含まれる協同作業条件を記憶するための協同作業情報記憶手段と、前記協同作業情報記憶手段に記憶された協同作業条件に基づいて、協同作業の関係者についての状況情報をもとに協同作業の時間調整を行なう当日時間管理手段とを具備したことを特徴とする。
【００１７】
これにより、協同作業の参加対象となる人物の現在の状況を状況情報として入力し、この状況情報と協同作業の協同作業条件に基づいて、時間レベルの調整ができる。
【００１８】
また前記当日時間管理手段は、協同作業の関係者についての状況情報をもとに、各人についての協同作業への参加受入れの可能性を示す依頼受託評価値と、前記依頼受託評価値に基づく協同作業の開催の適当性を示す開催評価値とを求めて、協同作業の調整を行なうことを特徴とする。
【００１９】
これにより、協同作業の各参加者についての参加受入れの可能性と、それらを考慮した協同作業の開催の適当性を判別することで、状況情報を用いて協同作業の的確な調整が可能である。
【００２０】
また複数の前記応用サービス提供手段の間で、ある応用サービス提供手段で実行するプロセスを再帰的に分割し、分割された部分プロセスを他の応用サービス提供手段において起動することで、部分プロセスの処理結果を共通利用することを特徴とする。
【００２１】
これにより、複数の応用サービス提供手段が接続された場合、再起的にプロセスを分割することで、複数のアプリケーション（応用サービスプロセス）間で、処理部品（各プロセスによる処理結果）の共有化が可能となる。
【００２２】
例えば、現在の実際のオフィス環境では、メンバの一人が実際にオフィスの中を歩き回って各メンバの様子を「観察」し、声を掛けてメンバを「召集」する必要などがあったが、各メンバーの時間的仕事状況は、時間表として入力しないでも、例えばカメラを介して個別にメンバの仕事状況を観察すれば「今は忙しそうだ」「今は全員が集合できるようだ」などと判定することが可能である。
【００２３】
従って、カメラ（画像）の入力と画像処理（および各種入力デバイス）を用いれば、各メンバの様子の観察が可能であり、スケジューラと判定装置により開催時間を決定し、ネットワークを介してメンバにメッセージを伝達しメンバを召集することが可能となる。
【００２４】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。図１は第１の実施形態に係わる協同作業調整装置の構成を示すブロック図である。図１には、構成要素と信号の流れが表現されている。
【００２５】
第１の実施形態における協同作業調整装置による調整の対象は、例えば会議の開催、オフィスの協同利用部分の掃除、協同で行なう荷物運びなど、複数人について日程的、時間的スケジュールの決定が必要な協同作業が考えられる。また、協同作業は、必ずしも複数人による作業に限らず、一人以上の人に仕事を依頼する作業であれば本発明を適用することができる。
【００２６】
図１に示すように、本実施形態における協同作業調整装置は、１つ以上の入力部１０、状況情報通信部１２、１つ以上の応用サービス提供部１４、出力情報通信部１６、１つ以上の出力部１８によって構成されている。
【００２７】
入力部１０は、例えばオフィス環境において利用される計算機によって構成されるもので、画像入力部１０ｂを少なくとも１つ、あるいは画像入力部１０ｂを少なくとも一つと複数の入力デバイス１０ａ、及び状況情報変換部１０ｃを有している。
【００２８】
状況情報変換部１０ｃは、入力デバイス１０ａと画像入力部１０ｂからの入力データを、協同作業の参加者の周囲環境または状況を示す状況情報に変換する。状況情報変換部１０ｃの詳細については後述する。
【００２９】
入力デバイス１０ａには、例えばキーボード、マウス等のポインティングデバイス、マイクなどの計算機に対する入力を行なうデバイスである。
【００３０】
画像入力部１０ｂは、計算機の近傍（またはディスプレイ装置や本体に）設置されたカメラであり、計算機を使用するための位置（計算機に相対する位置）にいる人物やその周囲の画像を撮影する。画像入力部１０ｂは、例えばＣＣＤカメラ、赤外線カメラ、高感度カメラ等によって構成される。本実施形態では、画像入力部１０ｂとしてカラーＣＣＤカメラが設けられ、濃淡画像情報をもつカラー画像を撮影するものとして説明する。
【００３１】
状況情報通信部１２は、１つ以上の入力部１０と１つ以上の応用サービス提供部１４との間を相互に接続する。状況情報通信部１２は、例えば情報をパケットの形式で伝送するもので、形態（有線あるいは無線）やプロトコルのレベルなどは問わない。物理的に複数の電線で構成されるバス構造をとっていても良い。いずれにしろ、入力部１０の状況情報変換部１０ｃと応用サービス提供部１４が相互に情報を伝達可能な構成であれば良い。
【００３２】
図２に状況情報通信部１２を伝送されるパケットの形態の一例を示している。パケットのヘッダ部の発信ＩＤ、宛先ＩＤ、内容ＩＤに続いて、内容（情報）のデータが含まれている。パケットは、後述する応用サービス提供部１４から特に要求されて情報を送信する場合でなければ、通常、宛先ＩＤの部分が「応用サービス提供部一般（応用サービス提供部１４を構成する何れの装置がとっても良い）」ことを示すパケットになる。パケットの内容（情報）には、時間的な差分情報、すなわち状況情報変換部１０ｃによって変換された状況情報がある状態からある状態に変化したことを表わす情報が含まれる。
【００３３】
応用サービス提供部１４は、入力部１０の状況情報変換部１０ｃによって得られる状況情報を状況情報通信部１２を介して入力し、状況情報をもとに協同作業参加可能な人物を把握し、協同作業実行の日時を調停するための応用サービスを提供する。
【００３４】
出力情報通信部１６は、１つ以上の応用サービス提供部１４と１つ以上の出力部１８との間を相互に接続する。
【００３５】
出力部１８は、応用サービス提供部１４によって把握された協同作業参加可能な人物に対してメッセージを伝達するために用いられる。
【００３６】
本実施形態における協同作業調整装置は、例えば複数の計算機（入力部１０）が、ネットワーク等の通信手段（状況情報通信部１２、出力情報通信部１６）を介して互いに接続された計算機システムによって実現される。
【００３７】
一般的な計算機は、キーボード等の入力デバイスとディスプレイ装置等の出力デバイスとの対を少なくとも一対有している。従って、計算機には、入力部１０と出力部１８が一対備わった構成とみなすことができる。
【００３８】
また、出力部１８は、計算機におけるディスプレイなどの表示装置に限らず、メモリやハードディスクなどの記憶部や、プリンタ、電化製品のスイッチ、ページャ等の通信機器、スピーカなどであっても良く、協同作業の参加者に何等かの方法でメッセージを通知できるものであれば良い。なお、記憶部に出力（記憶）されたメッセージは、例えばディスプレイ上での表示に供されることで協同作業の参加者に通知される。
【００３９】
次に、入力部１０における状況情報変換部１０ｃの詳細について説明する。
【００４０】
状況情報変換部１０ｃは、入力デバイス１０ａに相対する人物あるいは環境の状況情報を、入力デバイス１０ａあるいは画像入力部１０ｂから得られるデータをもとに抽出する。
【００４１】
状況情報は、画像入力部１０ｂ（カメラ）によって撮影された画像内に写った人の属性、例えば入力画像から抽出できる情報では、「誰であるか」「着座している、いない」「立ち上がっている、いない」「ある方向を向いている、いない」「電話中である、ない」「視線方向」「表情」などを示す情報を含む。また、入力デバイス１０ａから入力されるデータに基づいて判別される属性、例えばキーボードに対するタイピングリズムから判別される「仕事が順調に進んでいるか」、入力データから「今、何の仕事をしているか」などを示す情報を含む。入力データから実行中の処理を判別する方法としては、計算機がディスプレイの表示画面上で任意のウィンドウを設定しながら処理を実行するシステムを実現している場合、入力データ（コマンド等）に応じて実行しているプロセス番号を調べることで、どの種のウィンドウを用いて動作しているか（どのウィンドウを見ているか）を認識することによって行なう。
【００４２】
図３は状況情報変換部１０ｃの詳細な構成を示している。図３に示すように、状況情報変換部１０ｃは、人検出部２０、個人認証部２１、頭部方向推定部２２、視線方向推定部２３、口形状動作推定部２４、腕動作推定部２５、及び状況情報生成部２６を含んで構成される。以下、それぞれの構成部について説明する。
【００４３】
人検出部２０は、画像入力部１０ｂ（カメラ）によって撮影された画像中から人間に該当する領域（顔、肢体に該当する領域等）を判別・抽出するもので、図４に示すように構成されている。
【００４４】
図４に示すように、人検出部２０は、差分検出部２０ａ、顔検出部２０ｂ、肢体検出部２０ｃ、スコア統合部２０ｄ、人数計数部２０ｅによって構成されている。
【００４５】
差分検出部２０ａは、画像入力部１０ｂ（カメラ）が設置された撮影環境において、誰も撮影されていない状況での画像を予め取得しておき、その画像との差分画像を生成することによって変化のあった領域を、人物の顔または肢体に該当する領域の候補を検出する。差分画像を生成あるいは検出する技術には、（H.Nakai:''Non-Parametrized Bayes Decision Method for Moving Object Detection'',Proc. Second ACCV. Vol 3.pp447-451(1995) ）などがある。
【００４６】
差分検出部２０ａによって検出された領域について、２つの処理を行なう。一方は顔検出部２０ｂによる、検出された領域の濃淡画像情報をそのまま用いて顔の検出を行なうもの、他方は肢体検出部２０ｃによる、検出された領域を二値画像として扱い、領域の配置を含む各種の属性（後述する）の関係を用いて肢体の検出を行なうものである。
【００４７】
顔検出部２０ｂは、予めさまざまな方向から顔を撮影して得た画像データをもとに作成された、それぞれの方向の平均顔画像データ（辞書画像）と、差分検出部２０ａによって検出された領域の画像データとについてマッチングを行なうことにより人物の顔の検出を行なう。
【００４８】
本実施形態では、顔検出部２０ｂによって扱われる辞書画像の大きさは固定とする。一般に、大きな画像を辞書画像として用意すると、マッチング処理に非常に多くの時間を要するため、例えば３０×３０程度の大きさの辞書画像を用意する。大きさが固定の辞書画像を用いて、撮影して得た画像中に含まれるさまざまな大きさの顔を検出できるようにするため、撮影した画像の解像度を辞書画像の大きさに応じて変化させた上で、辞書画像とのマッチングを行なうものとする。
【００４９】
マッチングの度合（類似度）については、使用するマッチング方法に応じた類似度、例えば相関、単純、複合、混合類似度などにより設定する。顔検出部２０ｂは、差分検出部２０ａによって検出された領域の画像データに対する類似度値が、ある閾値以下であった場合には顔の領域とする候補から除き、閾値を越える場合には顔の領域とする候補として判定する。なお、候補数は、複数であってもよい。
【００５０】
肢体検出部２０ｃは、差分検出部２０ａによって生成された二値画像を用いて得た、差分画像の場所について再度、撮影したカラー画像から、例えば色相情報、彩度情報、明度情報に基づいて、領域分割を行ない、ラベリングする。肢体検出部２０ｃは、それらの領域の位置情報、形状情報、色相、明度といった属性情報を用いて、人間の肢体の部分に該当する領域と考えられる組合せを抽出する。肢体検出部２０ｃは、抽出した領域の組合わせ（人間の肢体の部分に該当すると考えられる領域）の形状、面積などから、足、胴、腕などとの形状モデルに対する信頼度を定義し、その信頼度の総和が最も最大となる組合せの領域を人間の肢体の部分（この段階では仮説）として抽出する。
【００５１】
顔検出部２０ｂ及び肢体検出部２０ｃは、入力画像中の人間（顔、肢体等）が存在すると考えられる画像中の領域について、顔の位置、肢体の位置（足、胴、腕等）の位置を示すデータと信頼度を記述した情報をスコア統合部２０ｄに送る。
【００５２】
スコア統合部２０ｄは、顔検出部２０ｂと肢体検出部２０ｃから得られた顔位置と肢体位置の仮説を統合し、それぞれの存在確率を２次元空間に投票する。
【００５３】
人数係数部２０ｅは、スコア統合部２０ｄによって投票された、仮説についての存在確率を統合的に判断し、画像中に何人の人がどのように撮影されているかを判別する。
【００５４】
スコア統合部２０ｄによって存在確率が投票された空間に対し、ある閾値を設定し、その閾値よりも高い部分を人間に該当する領域として、撮影された人数、撮影された人の位置、大きさ（画像中の領域）、概略向き、顔位置、足位置、胴位置、腕位置など位置の情報を判別して記憶する。
【００５５】
ここで閾値は、予測できる情報、環境の場合に応じて変化させる。例えば、午前と午後などの日照条件の変化による全体的な閾値の設定方向の改善や、人間が、ある場所から画像入力部１０ｂによる撮影範囲内に動いていることがわかっている場合には、前の場所において、肢体の大きさなどが推定されているため、撮影範囲においては、予測される画像中の位置によって、予めその領域付近の閾値を変化させるなどの制御を行なう。これらに用いるパラメータは、実験によって求められる。
【００５６】
次に、個人認証部２１について説明する。個人認証部２１は、人検出部２０によって検出された顔位置に撮影されている顔が誰であるかを認証する。個人認証部２１は、先に人検出部２０で検出された人数分について、それぞれの領域の画像について照合を行なう。認証の方法としては、予め、認識対象として登録された人の中からの識別が主となる。
【００５７】
図５には人検出部２０による処理過程を示している。画像入力部１０ｂによって撮影された画像中から差分検出部２０ａによって検出された図５（ａ）に示す入力画像（差分画像）をもとに、顔検出部２０ｂは、図５（ｂ−１）に示すように、顔位置の候補とそれぞれの信頼度を求め、肢体検出部２０ｃは、図５（ｂ−２）に示すように、肢体位置の候補とそれぞれの信頼度を求める。スコア統合部２０ｄは、顔検出部２０ｂと肢体検出部２０ｃによって投票された各候補と信頼度を、図５（ｃ）に示すようにして統合する。人数計数部２０ｅは、スコア統合部２０ｄによって図５（ｃ）に示すように統合された中から、例えばしきい値を「１．０」としてしきい値処理を行ない、図５（ｄ）に示すような結果を得る。この例では、２人が撮影されているものと推定される。
【００５８】
個人認証部２１は、図６に示すように構成され、人検出部２０によって得られた顔位置に撮影されている顔が誰であるかを認証する。認証の方法としては、登録された人の中からの識別が主となる。個人認証部２１は、図６に示すように、個人認証部２１は、正規化部２１ａ、照合部２１ｂ、辞書蓄積部２１ｃ、及び評価部２１ｄによって構成されている。
【００５９】
正規化部２１ａは、人検出部２０（顔検出部２０ｂ）によって検出された顔位置の画像から目の位置を検出し、その目の位置をもとにして後段の照合部２１ｂにおける処理のために、辞書蓄積部２１ｃに蓄積された辞書画像と同じ大きさの画像（正規化画像）を生成（正規化）する。
【００６０】
照合部２１ｂは、正規化部２１ａによって正規化された顔の部分に画像について、辞書蓄積部２１ｃに蓄積された複数の辞書画像とそれぞれ照合する。本実施形態において照合部２１ｂは、複合または混合類似度を用いて入力画像と辞書画像との類似度を算出する。
【００６１】
辞書蓄積部２１ｃは、認識対象とする人のそれぞれについての辞書画像が予め蓄積されている。
【００６２】
評価部２１ｄは、辞書蓄積部２１ｃに登録された辞書画像（認識対象とする人の数分）のそれぞれについて得られた複数の類似度値のうち最大の類似度値をもつ辞書画像を認識結果、すなわち辞書画像に対応する人の顔が入力画像に含まれているものと決定する。ただし、類似度値が、予め指定した閾値よりも低い場合は、撮影された人が誰であるかを決定せずに認識不能とする。
【００６３】
個人認証部２１は、先に人検出部２０で検出された人の数だけ、複数人の照合が行なう。
【００６４】
次に、頭部方向推定部２２について説明する。頭部方向推定部２２は、人検出部２０によって検出された、顔の向き、肢体の見え方（頭位置、胴位置、腕位置など）から頭部方向を推定する。
【００６５】
頭部方向推定部２２は、人検出部２０によって検出された顔位置の付近の濃淡情報を用いて、複数の顔モデルのパターンと照合することにより顔が向いている方向を推定する。パターンと照合する際の類似度としては、相関を用いた公知例（塚本、李、辻：複数のモデルによる頭の動き推定、電子情報通信学会論文誌Ｖｏｌ７７−Ｄ−ＩＩ，Ｎｏ．８，ＰＰ．１５８２−１５９０（１９９４））が存在するが、ここでは、複合類似度を用いてパターンの類似度を調べ、顔の向きを決定する。
【００６６】
また、頭部方向推定部２２は、目、鼻などの特徴点から顔の向きを出す方法として（ディシルバリヤナゲ、相澤清晴、羽鳥光俊：人間の顔の向きの推定：信学技報ＰＲＵ−４９−１８（１９９４））などを用いて、顔の向きを決定しても良い。
【００６７】
また、頭部方向推定部２２は、肢体の方向も同様に、人検出部２０で検出された領域グループ（足、胴、腕等を含む）の画像とパターンとを照合して向きを求める。
【００６８】
次に、視線方向推定部２３について説明する。視線方向推定部２３は、画像入力部１０ｂ（カラーＣＣＤカメラ）によって、離れた位置から撮影された画像中の顔の位置の目または目の付近から得られる特徴量を使って視線方向を推定する。
【００６９】
視線方向の検出方法としては、特開平４−２５５０１５号における、視線の相対的な移動量を瞳の輪郭データを抽出瞳の中心座標の変化から求める方法や、特開平３−１７６９６号における、ワードプロセッサ等のカーソル位置を視線によって制御することを目的として、目の領域を瞳孔中心を通る垂直線と水平線で分割し、分けられた領域の面積比を特徴量として、視点位置を算出する方法を利用することができる。
【００７０】
本実施例では、目頭、目尻と瞳の中心の相対的な位置関係を特徴ベクトルとして、その特徴ベクトルを線形識別し、パターン認識によって、顔の方向に対してどの方向を見ているかを推定する。
【００７１】
次に、口形状動作推定部２４について説明する。口形状動作推定部２４は、人検出部２０によって検出された顔位置の画像中の口の部分から、口の開閉を検出する。口の開閉の検出方法として、（間瀬、A.Pentland：オプティカルフローを用いた読唇の試み、電子情報通信学会論文誌D-II,Vo173-D-II,No.6,pp.796-803,(1990)）や（A.L.Yuille, P.W.Hallman, D.S.Cohen:Feature Extraction from Faces Using Deformable Templates, International Journal on Computer Vision,Vo18,no.2,pp,99-111(1992) ）を用いることができる。
【００７２】
本実施例では、例えば口の多段階の開閉具合（開閉度）に応じた開閉パターンをそれぞれ５種類用意し、各パターンと入力画像中の口の部分とマッチングした結果、一番近いパターンに応じた開閉度を、現在、画像入力部１０ｂにより撮影の対象となっている人の口の開閉状態とする。時間の経過に伴って各時点での口の開閉度を判別し、それら口の開閉度の頻度情報を求めることによって、話している、あくびをしているなどを検出する。
【００７３】
次に、腕動作推定部２５について説明する。腕動作推定部２５は、例えば色相情報を用いた手検出による方法を用いる。腕動作推定部２５は、人検出部２０で行った領域分割の結果から、顔領域ではなく、肌色の色相をもつ領域を手領域候補とする。この手領域候補は、顔位置との相対的な位置関係や、領域の大きさなどのいくつかの制約に基づいて選択される。腕動作推定部２５は、手領域の重心位置を特徴量として取り出し、時間の経過に伴って入力される画像中の手領域の重心位置の変化から腕の動作を推定し、さらには歩いている、手を振っているなどの動作の検出を行なう。
【００７４】
次に、状況情報生成部２６について説明する。状況情報生成部２６は、上記した各処理部２１〜２５における画像解析の情報を統合し、ある人間の状態の記述（状態情報）を生成する。状況情報生成部２６は、図７に示すように、統合部２６ａ、時刻発生部２６ｂ、場所情報記憶部２６ｃ、履歴記憶部２６ｄ、統合行動認識部２６ｅ、統合情報記憶部２６ｆから構成される。
【００７５】
統合部２６ａは、各処理部２１〜２５における検出結果（認識結果、推定候補）を入力して統合する。統合部２６ａは、統合結果を統合行動認識部２６ｅに出力すると共に、人検出部２０において検出されている人数に対応して履歴記憶部２６ｄに用意される、図８に示すようような状況登録テーブルのスロットに、各処理部２１〜２５におけるそれぞれの検出結果を登録する。
【００７６】
時刻発生部２６ｂは、画像取得、認識処理時間の間隔を考慮して、その間隔が表現できる単位まで記録できるように日付、時刻を発生する。時刻については、画像取得が行われた時刻を記録する。
【００７７】
場所情報記憶部２６ｃは、画像入力部１０ｂ（カラーＣＣＤカメラ）が設置されている場所に基づく情報について記述したもので、例えば撮影範囲を考慮したとき、撮影された画像中での人の大きさから、人とカメラまでの距離がどの程度になるかといった情報や、先に各情報の検出時に使用した画像に対する座標系の設定方法、大域的な設置場所の位置情報が記憶される。なお、これらの情報は、ある記憶場所に統合的に管理しておき、その識別番号のみを各状況情報変換部１０ｃで発生させる方法でもよい。
【００７８】
履歴記憶部２６ｄは、統合部２６ａで生成された情報を時系列で記憶、蓄積するもので、統合行動認識部２６ｅが過去の情報を必要とする際に参照される。
【００７９】
統合行動認識部２６ｅは、統合部２６ａで生成された情報の時間的変化から新たなレベルの状況情報を生成する。例えば口の開閉が連続的に行われている時には「話をしている」という状況情報を生成したり、人の位置が連続的に移動し腕が降られていることから「歩いている」などの状況情報を、時系列パターンを入力し、統合情報記憶部２６ｆに記憶された行動認識用の辞書を参照することにより認識する。他には例えば、「会話中である・ない」「笑っている・いない」「画面を軽くながめている・いない」「画面を凝視している・いない」「書類を読んでいる・いない」などの状況情報が生成される。
【００８０】
このように時間的変化から認識される状況情報を、ここでは「比較的高度なレベルの状況情報」と呼んで説明する。
【００８１】
これらの比較的高度なレベルの状況情報を、統合部２６ａで保有する情報の時間変化から認識するためには、例えば以下の方法を用いる。まず、統合部２６ａで生成されるレベルの状況情報の時系列（時間的推移）と、比較的高度なレベルの状況情報の関係をＨＭＭ（Hidden Markov Model ）やニューラルネットワークなどを用いて学習する。統合情報記憶部２６ｆは、この学習データを辞書として記憶しておく。この学習データと実際の場面で入力された時系列データを比較することで、比較的高度なレベルの状況情報を得る。
【００８２】
センサレベルで得られた状況情報は、図８に示すような状況登録テーブル（その１）にして履歴記憶部２６ｄに登録した。統合行動認識部２６ｅで得られた比較的高度なレベルの状況情報も、図９に示すように状況登録テーブル（その２）にして履歴記憶部２６ｄに登録する。
【００８３】
状況情報変換部１０ｃは、画像入力部１０ｂからの入力画像だけに基づいて状況情報を生成するのに限らない。例えば、入力デバイス１０ａから得られる情報、例えばキーボードのタイピングリズムの測定や、椅子の移動量、椅子に座った人物の重心位置なども状況情報として利用することができる。
【００８４】
キーボードのタイピングリズムを測定する場合では、その基本周波数を測定するとスケールの異なる二つの周波数が抽出される。高周波のリズムは単語のスペルを入力する時のような早いリズムである。低周波のリズムは、文章や文節ごとに考える間が入ることにより生ずるゆっくりしたリズムである。この二つのリズムの基本周波数を測定しておき、その基本周波数からの乱れを測定することで、仕事の進捗状況をリズムとして認識することができる。
【００８５】
また、椅子の移動量や、椅子への重心位置の変動を検出する場合は、操作者が集中していないことを示すもので、基本位置からのずれや、安定位置から変化した頻度を測定することで、操作者の集中度を表す状況として利用することができる。
【００８６】
以上のように、各種のレベルの状況情報が状況情報統合部２６によって生成される。状況情報統合部２６は、変化のあった状況情報の時間的な差分情報をパケットとして状況情報通信部１２を介して送信する。
【００８７】
状況情報通信部１２への情報の流し方（パケットの形態）については、後述する第２の実施形態の説明の中で様々な方法があることを詳しく説明する。
【００８８】
次に、応用サービス提供部１４の詳細について説明する。図１０は応用サービス提供部１４の基本構成と信号の流れを示すブロック図である。図１０に示すように、応用サービス提供部１４は、状況情報参照部３０、アプリケーション制御部３２、アプリケーション入出力部３４、及びアクション作成部３６によって構成されている。各部３０，３２，３４，３６のそれぞれの詳細な構成は、アプリケーションの内容によって、さまざまな構成をとる。
【００８９】
応用サービス提供部１４は、状況情報参照部３０により状況情報通信部１２と接続されている。アプリケーション制御部３２は、応用サービス提供部１４の中枢をなす部分で、状況情報参照部３０、アプリケーション入出力部３４、アクション作成部３６と接続されている。アクション作成部３６は、出力情報通信部１６と接続されている。
【００９０】
状況情報参照部３０は、状況情報通信部１２を流れる情報（図２に示すパケットの形式で伝送されている）を送受信する。状況情報参照部３０は、宛先ＩＤと自らのＩＤを比較して、一致していれば内容を取り込んで記憶、更新する。あるいは、状況情報参照部３０は、入力部１０に状況情報を問い合わせるときは、宛先ＩＤの部分を「入力部一般」に設定し、全ての入力部１０を対象としてパケットを発信する。
【００９１】
アプリケーション制御部３２は、状況情報参照部３０を介して得られる状況情報に基づいて、協同作業の日時を調整するサービスを行なうための、サービス処理あるいはデータ管理等を実行する。
【００９２】
アプリケーション入出力部３４は、アプリケーションの制御に必要かつ状況情報でないような情報、例えば協同作業の日程（日時）の調整の依頼あるいは応答のためのメール等を状況情報通信部１２とは別の通信経路（図示せず）を介して入出力する。ただし、ここでの通信経路は、論理的には状況情報通信部１２または出力情報通信部１６とは別であっても、物理的に同じネットワーク経路上であっても勿論良い。
【００９３】
アクション作成部３６は、出力部１８の選択、出力部１８への協同作業依頼のメッセージを表わす出力情報の作成、出力部１８への送信などを行なう。
【００９４】
応用サービス提供部１４は図１０に示すような基本構成を持つが、応用アプリケーションの内容次第で、構成要素の細かい構造は異なって来る。本実施形態における応用サービス提供部１４の詳細な構造については後述する。
【００９５】
次に、出力部１８の詳細については説明する。
【００９６】
出力部１８は、出力情報通信部１６を介して応用サービス提供部１４からの送信信号（出力情報）を受けて、例えばディスプレイの画面上におけるウィンドウ表示方法を更新したり、ウィンドウにメッセージ文字列を表示する。あるいは、応用サービス提供部１４が、ある部屋のスイッチをオンする制御信号を出す構成をとることも可能であり、この場合は部屋のスイッチが出力部１８にあたる。
【００９７】
出力情報通信部１６を流れるパケットも、図１２に示すように発信ＩＤ、宛先ＩＤを持つ構造をとり、宛先と発信元がわかる様になっている。出力部１８は、宛先ＩＤが自分のＩＤであるパケットを受信して、出力情報に応じて、文字、音、絵などのメディアに変換し（あるいは機器の制御信号に変換し）出力する。
【００９８】
次に、本実施形態の協同作業調整装置を実現するための応用サービス提供部１４の構成方法について説明する。
【００９９】
図１１は本実施例の応用サービス提供部１４の詳細な構成図である。
【０１００】
状況情報参照部３０は、通信部３０ａ、メンバ情報制御部３０ｂ、メンバ情報記憶部３０ｃから構成され、状況情報通信部１２において通信されるパケットの、送信、受信、解読や、協同作業を依頼されたメンバについての状況情報の管理、記憶、更新を行なう。
【０１０１】
通信部３０ａは、要求パケットの生成、状況情報パケットの受信、解釈を行なう。メンバ情報制御部３０ｂは、アプリケーション制御部３２からの要求に基づいて、メンバ情報記憶部３０ｃに登録されているメンバ情報（協同作業のメンバに関する状態を表わす情報（状態テーブルに設定される））の送信、管理、更新などを行なう。メンバ情報記憶部３０ｃは、アプリケーション制御部３２の当日時間管理部３２ｃで必要となるメンバ情報を記憶する。
【０１０２】
アプリケーション制御部３２は、協同作業情報記憶部３２ａ、日程管理部３２ｂ、当日時間管理部３２ｃ、スケジュール記憶部３２ｄから構成される。アプリケーション制御部３２は、アプリケーション入出力部３４を介して得られる依頼要求を記憶し、日程スケジュールや、当日の時間調整を行なう機能を有する。
【０１０３】
アプリケーション入出力部３４は、依頼入力部３４ａ、依頼応答部３４ｂ、スケジュール入力部３４ｃから構成される。アプリケーション入出力部３４は、状況情報とは別の必要なデータの入出力や、作業依頼を入力する部分である。依頼入力部３４ａにおいて作業依頼を入力し、スケジュール入力部３４ｃにおいてスケジュールデータを入力し、各入力に対する応答を依頼応答部３４ｂから行なう。
【０１０４】
アクション作成部３６は、メッセージ作成部３６ａにより構成され、出力情報通信部１６を介して依頼先の出力部１８にメッセージを送出する。
【０１０５】
次に、図１１に示す応用サービス提供部１４の構成を用いた場合の、依頼の入力と日程の決定を行なう処理の流れについて、図１２に示すフローチャートに基づき説明する。
【０１０６】
まず、各メンバが自分のスケジュールをスケジュール入力部３４ｃを用いて入力する事から始まる（ステップＡ１）。ここで入力するスケジュールは日程レベルのスケジュールであり、例えば図１３の様なスケジュール表の中の自分の行（自分の人物インデックスに該当する行）を埋めることになる。ここでは細かい時間レベルのスケジュールを入力する必要は無く、休暇（休暇予定Ｒ）や外出（外出予定ｇ）など、オフィスから不在となる時間帯を入力するだけでよい。
【０１０７】
各メンバのスケジュールは、アプリケーション入出力部３４のスケジュール入力部３４ｃから入力され、アプリケーション制御部３２のスケジュール記憶部３２ｄに出力される。スケジュール表は、日付インデックスに基づき日程テーブルとして記録されるので、週間の予定でも月間、年間の予定でも何でも良い。入力された各メンバのスケジュールは、図１３の日程テーブルの形式で整理され、スケジュール記憶部３２ｄに記憶される（ステップＡ２）
一方、協同作業の依頼者（むろんメンバに当人を含んでいて構わない）は、依頼入力部３４ａに対して依頼する協同作業の情報（協同作業条件）を入力する。例えば、依頼する協同作業が会議の場合であれば、入力される依頼情報には、期日、期日時間、メンバ（参加者）、打ち合わせ内容、最小興行人数、作業の優先度、会議開催から終了までの見込み時間（見通し所要時間）などが入力される。依頼入力部３４ａは、入力した依頼情報を、協同作業情報記憶部３２ａに記憶させる（ステップＡ３）。
【０１０８】
日程管理部３２ｂは、依頼者からの依頼要求の入力に応じて動作を開始し、日程調整処理を行なう。日程調整処理の詳細については後述する。（ステップＡ４）。
【０１０９】
次に、依頼応答部３４ｂは、依頼入力部３４ａから入力された依頼内容が受託できるか否かを依頼者に通知するための依頼応答を出力する。例えば、「承りました」というメッセージであったり、「この条件では会議開催が不可能です」という応答であったりする（ステップＡ５）。依頼が受託できない場合は、依頼内容を入力可能な状態に復帰し、新たな依頼（あるいは修正された依頼）を待つ（ステップＡ６）。
【０１１０】
依頼要求は依頼入力部３４ａから入力されるものとして説明しているが、実際にはネットワークを構成している計算機のキーボードなどを通して入力されると考えて良い。情報と信号の流れを明確にするために、あえて依頼入力部３４ａを別にして説明している。
【０１１１】
また、本発明の構成では、各メンバの状況情報を応用サービス提供部１４が利用できるので、作業の依頼者は、メンバを名前で特定するのでなく、状況情報に対して属性で指定することもできる。例えば「今、座席に座っている人を１０人集める」「これから１時間の間に１０分以上電子メールを読んでいた人を５人集める」といった属性の指定が可能である。
【０１１２】
日程管理部３２ｂは、指定された属性に該当する状況情報を抽出することで、指定された条件に一致するメンバを求めることができる。
【０１１３】
日程管理部３２ｂによる日程調整処理の結果に基づき、会議の開催予定候補日が決定される。依頼された会議が終了する時点まで、開催可能な開催候補日が日程管理部３２ｂに記憶され候補日待機状態となる。日程管理部３２ｂは、内部に持つカレンダカウンタによって日の経過を計数しており、カレンダカウンタが候補日に一致した場合は、当日時間管理部３２ｃに当日時間調整処理を起動する制御信号を送信する（ステップＡ７）。
【０１１４】
当日時間管理部３２ｃは、日程管理部３２ｂからの起動制御信号を受信し、当日時間調整処理を行う。当日時間調整処理の詳細については後述する（ステップＡ８）。
【０１１５】
会議開催に適した時間になると、当日時間管理部３２ｃは、当日時間調整処理の処理結果に基づくメッセージ作成処理起動信号をメッセージ作成部３６ａに送信する（ステップＡ９）。
【０１１６】
制御信号を受信したメッセージ作成部３６ａは、協同作業情報記憶部３２ａの情報をもとに各構成メンバへの作業開始メッセージを作成し、出力情報通信部１６を介して、各構成メンバに例えば会議を開催する旨メッセージを送信する。図１４は、本発明の協同作業調整装置を用いた際に、会議の開催時間が通知されているイメージを示した様子である。図１４では出力部１８としてディスプレイが用いられ、文字によってメッセージが通知されている。スピーカなどの他の出力部１８が用いられても良い。
【０１１７】
以上が全体の処理の流れである。
【０１１８】
次に、日程調整処理について詳しく説明する。日程調整処理の流れを図１５のフローチャートに基づき説明する。
【０１１９】
ネットワーク環境に接続された計算機を使用する各メンバはそれぞれの予定をスケジュール入力部３４ｃを用いて入力している。この結果、スケジュール記憶部３２ｄには図１３に示すような日程テーブルが記憶されている。
【０１２０】
依頼者の入力に応じて日程管理部３２ｂは、スケジュール記憶部３２ｄの日程テーブルの中から依頼メンバの行を抽出する（ステップＢ１）。この抽出されたテーブルの情報を、日程管理部３２ｂは、各時間帯毎に論理和をとる処理を行い、誰の予定も入っていない時間帯を抽出する（ステップＢ２）。
【０１２１】
日程管理部３２ｂは、抽出した時間帯の中で、見通し所要時間より長い時間帯のみを抽出する（ステップＢ３）。ここで抽出される区間が会議を行うことが可能な時間帯（開催候補時間帯）である。
【０１２２】
日程管理部３２ｂは、この時間帯に優先順位をつけ（依頼者が特殊な仕様を入力していない限り一般には早い日ほど優先順位が高いことが多い）、開催候補時間として当日時間管理部３２ｃに送信する（ステップＢ４）。
【０１２３】
依頼者の入力内容を満たす候補時間が存在する場合は依頼受託となるが（ステップＢ５，Ｂ６）、存在しない場合は、依頼非受託となる（ステップＢ７）。この場合、依頼応答部３４ｂから依頼者に対して、依頼非受託の旨のメッセージを伝達し、再度依頼入力待ち状態に復帰する。
【０１２４】
この時点で開催候補日が決定するが、この時点で協同作業の依頼メンバに、開催候補日や会議の内容、会議の主旨などを通知するメッセージを送信することも可能である。この場合は、日程管理部３２ｂからメッセージ作成部３６ａに制御信号を送信することで、メッセージ作成部３６ａが協同作業情報記憶部３２ａに記憶された情報をもとに、構成メンバへのメッセージを作成し、出力情報通信部１６を通して各メンバに対応する各出力部１８へメッセージを伝達する。
【０１２５】
以上が、日程調整処理の説明である。
【０１２６】
次に、当日時間調整処理について詳しく説明する。当日時間調整処理の流れを図１６のフローチャートに基づき説明する。
【０１２７】
当日時間管理部３２ｃは、日程管理部３２ｂからの開催候補日となったことを通知する制御信号を受信すると、状況情報参照部３０のメンバ情報制御部３０ｂに、図１７に示すような状態テーブルの参照を要求する。状態テーブルは、メンバ情報記憶部３０ｃに記憶されるもので、状況情報通信部１２を流れる状況情報に応じて、各メンバ（人物インデックス）毎に現在の状況を示す情報が更新される。
【０１２８】
状況情報通信部１２には、何らかの状況情報が変化した時に変化情報だけが流れているので、処理の初期段階では状況情報の初期状態が存在しない。つまりメンバ情報記憶部３０ｃの内容が初期設定値のままであるので、メンバ情報制御部３０ｂは、通信部３０ａに当該メンバの初期状態の獲得を要求することで、通信部３０ｃが問い合わせ信号を作成し、状況情報通信部１０４を介して初期状態を獲得する（ステップＣ２）。
【０１２９】
一方、状況情報通信部１２には状況の変化情報が流れているので、初期状態の獲得以後は、メンバ情報制御部３０ｂは、通信部３０ａが受信した情報に基づきメンバ情報記憶部３０ｃを更新する処理を続ければ良い（ステップＣ１）。
【０１３０】
状況情報通信部１０４を流れている状況情報信号は、例えば「着席している・いない」「電話中である・ない」「文章執筆中・そうではない」など、画像入力部１０ｂから入力された画像情報あるいは各種入力デバイス１０ａから入力された入力情報に基づいて判別された各種状況である。
【０１３１】
応用サービス提供部１４が提供するサービス内容、あるいは依頼者の依頼内容によっては、より複雑な状態の解釈が必要となる場合もある。例えば、「忙しい仕事をしている・そうではない」「単調な仕事を続けているので刺激を与えた方が良い・そうではない」などの解釈である。
【０１３２】
アプリケーション制御部３２は、状況情報通信部１２に流れる状況情報を状況情報参照部３０を介して受けとり、この状況情報から状態の解釈が可能となるように装置が構成されている。
【０１３３】
例えば、状況情報を特徴ベクトルとして、状態の解釈を出力パターンとするように、学習型ニューラルネットワークやパターン認識理論を応用して装置を構成すれば良い。特徴ベクトルの入力から、パターン出力を得るための構成方法は、例えば「舟久保登”パターン認識”共立出版（１９９１）」「飯島泰蔵”パターン認識理論”森北出版（１９８９）」などに詳しい。また、状況の解釈を決定論的に処理するのが難しければ、暖味性を持たせたデータ属性の処理を行う方法も、例えば「馬場”ファジィ・データベースの現状と動向”Advanced Database System Symposium '90, pp.207-214(1989)」において記載されている。
【０１３４】
ここでは、特徴ベクトルの重みつき線形和に基づく状況の解釈方法を例として説明する。
【０１３５】
当日時間管理部３２ｃは、これらの状況情報から、各個人の会議を受け入れる可能性を示す評価値として依頼受託評価値Ｐを計算する。依頼受託評価値Ｐは前述した状態の判別値（状況情報）を用いて、式（１）の重み付き線形和により計算される。
【０１３６】
【数１】
0003540494.tif 000002
【０１３７】
式（１）式において、ｘ（ｉ）はｉ番目の状態の解釈結果に応じて“１”または“０”の値をとる関数であり、例えば「着席している・いない」を解釈した場合のｘの値は“１”で「着席しているとき」、“０”で「着席していないとき」を表わす。
【０１３８】
同様に「電話中である・ない」「文章執筆中である・ない」なども同様に１または０の値をとる。
【０１３９】
式（１）式において、ａ（ｉ）はｉ番目の状態の解釈結果に与える重みであって、ｉ＝１からＮまでのＮ個の状態の相対的重みを与える値である。
【０１４０】
Ｎ個の重みａ（ｉ）（ｉ＝１，…，Ｎ）は、各人の協同作業を受け入れる可能性が高い場合に、依頼受託評価値Ｐが大きくなるようにそれぞれ調整する。調整は実験的、経験的に設定すれば良い。
【０１４１】
例えば、着席している時は、着席していないときより、出力したメッセージが伝わる可能性は高く作業に参加できる可能性は高い。したがって、重みは正の値になる。逆に、電話中である場合は、電話中で無い場合より、作業に参加できる可能性は低い。したがって、重みは負の値になる。また、例えば、視点移動が少なくディスプレイの文字を凝視している場合は、仕事に集中している可能性が高いので、参加できる可能性は低くなる。このように、画像情報には、各メンバの仕事状況を推測できるデータが多く存在し、それらが、状況情報として伝送されてくるので、メンバの現在の状態を把握することができる。
【０１４２】
また、もし、全く作業に参加できる可能性がない場合（例えば席をはずしていて居所が不明な場合などが考えられる）は、依頼受託評価値Ｐが“０”となるように調整する。
【０１４３】
当日時間管理部３２ｃによって計算された依頼受託評価値Ｐは、メンバ情報制御部３０ｂを介してメンバ情報記憶部３０ｃに状態テーブルのデータとして記憶される。メンバの状況情報に変化がある度に、状況情報参照部は３０は、当日時間管理部３２ｃにメンバ情報の依頼受託評価値Ｐの更新を要求する。当日時間管理３２ｃは、変化のあったメンバの依頼受託評価値Ｐを計算する（ステップＣ３）。ステップＣ２の後、作業開始のメッセージを作成処理に移行するまでは、順次、全メンバの依頼受託評価値Ｐについて計算される。
【０１４４】
当日時間管理部３２ｃによる依頼受託評価値Ｐについての計算結果に応じて、メンバ情報記憶部３０ｃの依頼受託評価値（状態テーブル）が更新される（ステップＣ４）。
【０１４５】
次に、当日時間管理部３２ｃは、作業（会議）を開催すべきか否かを判断するための開催評価値Ｖの計算を行なう（ステップＣ５）。会議の開催評価値Ｖの計算は以下のように行う。
【０１４６】
各個人の依頼受託評価値Ｐは式（１）に基づいて求められている。会議の構成メンバがＭ人いるとして、各メンバの依頼受託評価値をＰ(j) （ｊ＝１，…，Ｍ）と表す。この依頼受託評価値の重み付き線形和をとり、これを会議開催をすべきか否かを判断するため適当性を示す評価値Ｖとし、開催評価値Ｖと呼ぶ。開催評価値Ｖは式（２）により計算される。
【０１４７】
【数２】
0003540494.tif 000003
【０１４８】
Ｗ(j) （ｊ＝１，…，Ｍ）は、会議を構成するメンバの参加必要度に応じて設定する重みである。全員が同等な必要度であれば全てのｊに対して一定値（例えば１）を設定すればよい。あるいは、例えばグループのリーダーがどうしても参加する必要があれば、リーダーにかかる重みｗは大きい値となろう。あるいは、協同作業が会議でなく、例えば荷物運びであれば若いメンバの重みを大きくするなどの応用が考えられる。
【０１４９】
この重みは、協同作業依頼者が設定してもいいし、慣例によく従うように予め調整しておくことも可能であるし、協同作業の依頼内容から自動設定することが可能であれば（例えば同メンバで前回利用した重みを再利用するなどの方法がある）、そのように決めれば良い。依頼者の入力も、自動設定値もなければ、全員を一定値にすれば良い。
【０１５０】
次に、当日時間管理部３２ｃは、開催評価値Ｖと比較するための評価判断値を用意する（ステップＣ６）。この評価判断値は時間変化する値とする。この評価判断値をしきい値として、開催が適切か否か判定する。以後の説明では、このしきい値をＴと表す。
【０１５１】
図１８には評価判断値（しきい値Ｔ）を説明するための一例を示している。
【０１５２】
図１８（ｅ）において、縦軸は開催評価値Ｖの軸、横軸は時間軸である。時間軸方向には、日程管理部３２ｂから送信された開催候補時間帯を時間軸原点から時間順に並べる。
【０１５３】
例えば、図１８（ａ）に示すように開催候補時間帯が８：００から１４：００であったとする。ここでは、図１８（ｂ）に示すように会議の見通し所要時間が２時間なので、会議は８：００から１２：００までの間に始めなければ、全員の参加可能な時間内に終了しない。よって、図１８（ｃ）に示すように、８：００から１２：００までの時間を開始候補帯として抽出し、図１８（ｅ）に示す時間軸のＯ（原点）から配置する。
【０１５４】
図１８（ｅ）において、会議終了の期日時間を横軸方向の終端Ｅとし、会議の見通し所要時間分を時間的に遡った位置Ｄとする。Ｄと評価値軸上のＳの間に直線を引き、これをしきい値Ｔとする。Ｓの高さは各メンバの依頼受託評価値Ｐを満点にした時の開催評価値Ｖの値である。
【０１５５】
当日時間管理部３２ｃは、作動している時間内では開催評価値Ｖを計算し、Ｖがしきい値Ｔと等しいかそれ以上の時点で、会議開催可能と判断する（ステップＣ７）。
【０１５６】
図１８に示すしきい値Ｔは、時間的に早いほど高く、遅いほど低い。従って、時間的に余裕のある間は、開催評価値Ｖが十分高くなるまで開催可能と判断しないが、時間的余裕がなくなってくると開催可能の判断が容易になされる。また、期日より、会議所用見込み時間前までには確実に開催可能の判断をする。
【０１５７】
また、図１８（ｅ）に示す例では、ＳからＤに直線的にしきい値Ｔを変化させたが、半減期を８時間などと設定し、減少型の指数関数で変化させても良い。この半減期は構成メンバの経験に応じて設定すれば良い。あるいは、午前中に優先的に会議が設定される方が望ましい場合は、午前中のしきい値Ｔが低めになるように折れ線的に設定すれば良い。この、しきい値Ｔの時間変化のさせ方は、環境を利用するメンバの慣習や経験に基づいて決めれば良いのである。ただ減少関数を使い、期限より見通し時間分遡った時点までには必ず会議が開かれる様に設定する必要がある。
【０１５８】
もし、最小興行人数の設定がなされている場合は、依頼受託評価値Ｐが０でないメンバの人数が、最小興行人数を超えていることを確認する処理を追加する（ステップＣ８）。
【０１５９】
以上のステップで、当日時間管理部３２ｃは、協同作業を開始するのに適した時間を判断することができる（会議招集システムの場合は会議開催時間が決まる）。
【０１６０】
協同作業の開始時間を決定すると、当日時間管理部３２ｃは、メッセージ作成部３６ａに制御信号を送信する。
【０１６１】
制御信号を受信したアクション作成部３６は、協同作業情報記憶部３２ａの情報をもとに各構成メンバへの作業開始メッセージを作成し、出力情報通信部１６を通してメンバがいる出力部１８に送信する（ステップＣ９）。
【０１６２】
本実施形態の場合、出力部１８は計算機ディスプレイや計算機に接続されたスピーカとすると、入力部１０と出力部１８は対になっている。従って、メッセージ作成部３６ａは、状況情報変換部１０ｃからの状況情報により得られる個人認証結果に基づき、該当するメンバがいる計算機の出力部１８宛てにメッセージを送信する（ステップＣ９）。この場合、メッセージの送信先のメンバが本来いるべき場所（計算機）にいなくても、ネットワーク環境中の何れかの出力部１８が存在する場所にいればメッセージの伝達が可能である。
【０１６３】
また、メッセージの作成に時間がかかる場合は、候補日程が決定した段階で、伝達メッセージの予め作成できる部分をメッセージ作成部３６ａが作成しておくことで、当日時間管理部３２ｃの制御信号は発信タイミングの制御だけに用いる方法をとることも可能である。
【０１６４】
以上詳しく説明してきたが、本発明を利用する事により、時間的に細かいスケジュールを入力する事なく、協同作業の参加メンバの現在の状況に応じて開始時間を調整することが可能な協同作業調整装置を構成する事ができる。
【０１６５】
次に、第２の実施形態として、情報の流し方の変形例について説明する。
【０１６６】
第１の実施の形態では、状況情報通信部１２を流れる状況情報は、入力部１０の状況情報に変化が起きた場合に変化分に限って通信される形態で説明してきた。この際、通信経路上（状況情報通信部１２）に流れるパケットの形式は図２に示す構造とした。
【０１６７】
この他にも通信される情報の形態を様々に変形させることができる。
【０１６８】
（１）ブロードキャストタイプ
これは、状況情報の変化の有無に関わらず、ある一定の時間間隔で状況情報の構造体が伝送される形態である。この場合、例えば図１９に示す様な構造化されたパケットが、例えば１００分の１秒おきに通信経路上を流れる。図１９の構造化されたパケットの内容は、例えば図１７に示す状態テーブルの個人ごとの内容に対応する。
【０１６９】
この形態の場合、状況情報参照部３０は、記憶部（図１１のメンバ情報記憶部３０ｃ）を有する必要がなく、通信部３０ａが分解した状況情報中の情報をアプリケーション制御部３２が利用すれば良い。
【０１７０】
（２）要求と応答タイプ
応用サービス提供部１４が解釈に必要な状況情報を、状況情報通信部１２を介して入力部１０に問い合わせる形態である。この場合は、応用サービス提供部１４の状況情報参照部３０の内部（例えば通信部３０ａ）では、アプリケーション制御部３２の要求に従って、必要な情報を問い合わせるパケットを作成し、状況情報通信部１２に送信する。
【０１７１】
（３）情報差分タイプ
この形態は、第１の実施の形態で説明して来たパケットの形態である。
【０１７２】
何れの形態にしろ、応用サービス提供部１４が状況情報を利用できる通信形式であれば、本発明を応用することは容易である。
【０１７３】
次に、第３の実施の形態として、状況情報の入力対象が一人の場合について説明する。
【０１７４】
第１の実施の形態では、協同作業として複数のメンバが参加する特に会議の招集について説明したが、状況情報を検出する対象が一人の場合であっても、本発明の構成を応用することができる。この場合、協同作業を行うのが一人の場合と解釈すればよいだけである。例えば、到着と同時に電子メールが読まれる可能性を、従来の方式よりも高くする電子メールシステムを構成することができる。
【０１７５】
以下、到着すると同時に相手が電子メールを読む可能性が従来の方法より高くなる電子メールシステムの実現方法について説明する。
【０１７６】
第１の実施の形態では、アプリケーション制御部３２の内部手続きとして、依頼受託評価値Ｐを定義し、式（１）に基づいて重みつき線形和によって求めた。第３の実施形態では、依頼受託評価値Ｐに変わって、文章を読む可能性の高い状況で数値が高くなる評価値を導入する。
【０１７７】
届いた電子メールをその場で読む可能性は、例えばディスプレイに視線を向けている状況の方が高いし、タイピングがリズム良く行われている時は文章執筆に集中している可能性があるので読まれる可能性は低い。一方、タイピングが止まり、体の姿勢もあまり変わらず、じっとディスプレイを見つめている時は、何か考え事をしている状況なので、読まれる可能性は高い。
【０１７８】
このように、画像入力部１０ｂから入力される画像情報の中には、電子メールが読まれる可能性をある程度推測するための情報が多数含まれている。この情報を個人性も含めて、パターン認識手法あるいはファジー測度手法を用いて推測することは可能である。
【０１７９】
以上のことから、第３の実施形態の処理の流れについて、図２０に示すフローチャートを参照しながら説明する。
【０１８０】
まず、応用サービス提供部１４のアプリケーション入出力部３４から電子メールの送信要求（宛先、本文）を入力する（ステップＤ１）。アプリケーション制御部３２は、状況情報参照部３０からメンバ情報の初期状態である状況情報を抽出する（ステップＤ２〜ステップＤ４）。
【０１８１】
予め調整された式（１）の係数に基づいて依頼受託評価値を計算する（ステップＤ５）。ここでの、依頼受託評価値は、前述のように、文章を読む可能性の高い状況で数値が高くなる。
【０１８２】
依頼受託評価値が予め設定したしきい値Ｔより大きい場合、アプリケーション制御部３２は、アクション作成部３６に、メール到着のメッセージを表示するための制御信号を送信する（ステップＤ６，Ｄ７）。例えば、アイコン型の小さなマークを、ディスプレイの画面中に表示させる。
【０１８３】
次に、第４の実施の形態として、アプリケーションの複数化について説明する。
【０１８４】
ここで説明する実施の形態ではアプリケーション実行手段の複数化について詳しく説明する。
【０１８５】
本発明の基本構成を示した図１では、複数の入力部１０（Ｎ個）、複数の応用サービス提供部１４（Ｍ個）、出力部１８（Ｌ個）ある。本発明の構成に従い応用サービス提供部１４が複数存在する場合は、複数の応用サービス提供部１４同士で解釈結果を利用し合う状況が発生する。
【０１８６】
例えば、人物認証処理は第１の実施の形態では各入力部１０の状況情報変換部１０ｃで行った。人物認証処理は参照データも多く、入力部１０にとって負荷の大きい処理である。いま、新たな形態として、入力部１０の処理量を減らすために、この人物認証処理を応用サービス提供部１４の１つが集中的に行う構成を取る。つまり、処理の一元化を図る。
【０１８７】
この構成にはいつか利点がある。第１の利点は、人物認証処理のために必要なデータ量は膨大であるが、このデータを一元管理できるので、更新、及び修正が容易になるということ。第２の利点は、「同一人物は複数箇所に同時に存在することはない」という知識を利用できるので、効率的に人物認証処理を実行できること、である。
【０１８８】
しかし、人物認証処理の結果が必要な応用サービス提供部１４は多く存在する。例えば第１の実施の形態の協同作業調整装置でも、第３の実施の形態の電子メールシステムでも「誰がどこにいる」という情報が必要であるから、人物認証処理は欠かせない。
【０１８９】
しかしながら、複数の応用サービス提供部１４で同一の処理が行われることは効率的ではない。
【０１９０】
このため、人物認証処理が応用サービス提供部１４で解釈結果（この場合は人物認証処理処理結果）を共有できる構成が必要である。
【０１９１】
以上の例のように、本発明の構成の中に、応用サービス提供部１４が複数接続されてくると、共通するデータや中間処理結果が発生する。全体の効率を上げるためには、複数の応用サービス提供部１４同士でデータを転送しあう仕組みが必要になる。
【０１９２】
複数の応用サービス提供部１４同士でデータを転送し合う仕組みを作るためには、例えば人物認証処理の結果の共有化を例にして説明すれば、以下のようにすれば実現できる。
【０１９３】
いま、第１の実施の形態で説明したように、状況情報通信部１２を流れるパケットは、データの変化時にだけ伝送される情報差分タイプのパケットで、形式は図２の構成であるとする。
【０１９４】
人物認証処理を行った応用サービス提供部は、宛先ＩＤを「不定（全ての応用サービス提供部１４宛て）」にして、状況情報通信部１２にパケットを送信する。応用サービス提供部１４の構成要素である状況情報参照部３０には、転送されたパケットの宛先ＩＤが「不定」であるから、内容ＩＤを調べ、人物認証処理の結果を示すＩＤであれば、その情報を取り込み、自分の解釈部の入力情報として使用する。
【０１９５】
人物認証処理のように、複数の応用サービス提供部１４で参照されることが明かなデータは本発明の全体システム（図１）を作成した初期段階から、一つの応用サービス提供部１４として接続することが可能だか、これと別の立ち上げ形態もとることが可能である。
【０１９６】
例えば、本発明の全体システム（図１）に新たな応用サービス提供部１４を接続した時に、当該応用サービス提供部１４が自己の処理プロセスを再帰的に分割して、一部の処理プロセスを別の応用サービス提供部１４として独立させるという構成をとることができる。この新たに分割された応用サービス提供部１４を「子の応用サービス提供部」と呼び、母体となった応用サービス提供部１４を「親の応用サービス提供部」と呼ぶ。再帰的に分割された場合は、複数の「子の応用サービス提供部」が起動されることになる。
【０１９７】
プロセスが分割しても、「人物認証処理を集中的に行う応用サービス提供部」の説明と同様に、状況情報通信部１２を介して情報をやりとりすることにより、親と子の応用サービスが一体の場合と同様な処理を行うことができる。
【０１９８】
このように再帰的に分割する応用サービス提供部１４が全体のシステム（図１）に複数接続されてくると、子の応用サービス提供部を共有できる確率が増加し、全体の処理量を抑えることができるようになる。
【０１９９】
親の応用サービス提供部は、自らの処理プロセスを分離分割する前に、状況情報通信部１２を流れるパケットの内容ＩＤを予め規定した時間調査し、分離しようとしている子の応用サービス提供部と同じ処理プロセスである応用サービス提供部１４が、全体のシステムに存在しないことを確認してから、プロセスを分離する手続きを取ればよい。
【０２００】
また、例えば、パケットの流通量が少ないために、同じ処理プロセスである応用サービス提供部１４が複数起動された場合でも、処理結果が矛盾するのでなければ問題はない。もし、冗長な処理プロセスを省いて全体の効率を上げたい場合には、各応用サービス提供部１４は、他の応用サービス提供部１４が送信するパケットを調べ、自らが発信するパケットの内容ＩＤと一致し、かつ、送信元を示す発信ＩＤが自らと異なるパケットを検知したときに、時間的に後から起動された側の応用サービス提供部１４が自ら終了する構成を取れば良い。応用サービス提供部１４の起動された時間の比較が必要な場合は、応用サービス提供部１４の送信するパケットの発信ＩＤは、起動された時間順に通し番号をつけて行けば良い。発信ＩＤを比較することで、起動された時間の比較は容易である。
【０２０１】
【発明の効果】
以上説明したように本発明によれば、協同作業の参加者に特別な作業を強いることなく、時間的なスケジュールまでを確実かつ容易に調整することを可能にする。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係わる協同作業調整装置の構成を示すブロック図。
【図２】図１中の状況情報通信部１２を伝送されるパケットの形態の一例を示す図。
【図３】図１中の状況情報変換部１０ｃの詳細な構成を示す図。
【図４】図３中の人検出部２０の詳細な構成を示す図。
【図５】人検出部２０による処理過程を説明するための図。
【図６】図３中の個人認証部２１の詳細な構成を示す図。
【図７】図３中の状況情報生成部２６の詳細な構成を示す図。
【図８】図７中の統合部２６ａによってセンサレベルで得られた状況情報が登録される状況登録テーブル（その１）の一例を示す図。
【図９】図７中の統合行動認識部２６ｅによって生成される比較的高度なレベルの状況情報が登録される状況登録テーブル（その２）の一例を示す図。
【図１０】応用サービス提供部１４の基本構成と信号の流れを示すブロック図。
【図１１】応用サービス提供部１４の詳細な構成を示すブロック図。
【図１２】応用サービス提供部１４における依頼の入力と日程の決定を行なう処理の流れを説明するためのフローチャート。
【図１３】日程レベルのスケジュールを登録するためのスケジュール表の一例を示す図。
【図１４】本実施形態における協同作業調整装置を用いた際に会議の開催時間が通知されているイメージを示す図。
【図１５】第１の実施形態における日程調整処理の流れを説明するためのフローチャート。
【図１６】第１の実施形態における当日時間調整処理の流れを説明するためのフローチャート。
【図１７】メンバ情報記憶部３０ｃに記憶される状態テーブルの一例を示す図。
【図１８】第１の実施形態における評価判断値（しきい値Ｔ）を説明するための図。
【図１９】第２の実施形態において用いられる構造化されたパケットの一例を示す図。
【図２０】第３の実施形態の動作を説明するためのフローチャート。
【符号の説明】
１０…入力部
１０ａ…入力デバイス
１０ｂ…画像入力部
１０ｃ…状況情報変換部
１２…状況情報通信部
１４…応用サービス提供部
１６…出力情報通信部
１８…出力部
２０…人検出部
２０ａ…差分検出部
２０ｂ…顔検出部
２０ｃ…肢体検出部
２０ｄ…スコア統合部
２０ｅ…人数計数部
２１…個人認証部
２１ａ…正規化部
２１ｂ…照合部
２１ｃ…辞書蓄積部
２１ｄ…評価部
２２…頭部方向推定部
２３…視線方向推定部
２４…口形状動作推定部
２５…腕動作推定部
２６…状況情報生成部
２６ａ…統合部
２６ｂ…時刻発生部
２６ｃ…場所情報記憶部
２６ｄ…履歴記憶部
２６ｅ…統合行動認識部
２６ｆ…統合情報記憶部
３０…状況情報参照部
３０ａ…通信部
３０ｂ…メンバ情報制御部
３０ｃ…メンバ情報記憶部
３２…アプリケーション制御部
３２ａ…協同作業情報記憶部
３２ｂ…日程管理部
３２ｃ…当日時間管理部
３２ｄ…スケジュール記憶部
３４…アプリケーション入出力部
３４ａ…依頼入力部
３４ｂ…依頼応答部
３４ｃ…スケジュール入力部
３６…アクション作成部
３６ａ…メッセージ作成部
【図１】
0003540494.tif 000004
【図２】
0003540494.tif 000005
【図３】
0003540494.tif 000006
【図４】
0003540494.tif 000007
【図５】
0003540494.tif 000008
【図６】
0003540494.tif 000009
【図７】
0003540494.tif 000010
【図８】
0003540494.tif 000011
【図９】
0003540494.tif 000012
【図１０】
0003540494.tif 000013
【図１１】
0003540494.tif 000014
【図１２】
0003540494.tif 000015
【図１３】
0003540494.tif 000016
【図１４】
0003540494.tif 000017
【図１５】
0003540494.tif 000018
【図１６】
0003540494.tif 000019
【図１７】
0003540494.tif 000020
【図１８】
0003540494.tif 000021
【図１９】
0003540494.tif 000022
【図２０】
0003540494.tif 000023