JP5028170B2 - ユーザ連携システムおよびサーバ装置 - Google Patents

Description

本発明は、組織業務の生産性の向上に寄与する新しいユーザ連携技術に関する。

従来、センサノードを使った組織内コミュニケーションを使用し、組織業務の効率向上

を図ろうとする試みがあった（例えば、特許文献１参照）。

特開２００７−１０８８１３号公報

製品開発、システムインテグレーション、コンサルティング等の多数の業務において、その円滑な遂行のためにはメンバ間の緊密な連携が必須である。

交渉・調整といった要素を含む多くの組織業務では、各メンバ間の業務遂行には依存関係があり、そのような依存関係は非同期的に発生・変化する。そのような依存関係は、メンバ間のコミュニケーションによって調整・解決される必要がある。

最も直接的なコミュニケーションは、フェイス・トゥ・フェイスで行うミーティングであるが、メンバ間で距離的な隔たりがある場合や、時間的な都合が合わない場合には、フェイス・トゥ・フェイスでのコミュニケーションは困難である。このような場面においては、固定電話をはじめ、携帯電話、電子メール、インスタントメッセンジャー、ウェブログ等、多様なテレ・コミュニケーション手段を用いてきた。

しかしながら、従来のテレ・コミュニケーション手段によって実現されるコミュニケーションの量や質は、連携業務の遂行にとって決して十分なものとはなっていなかった。

業務現場では、各メンバは各々の担当業務を持ち、その主要部分については各々が自律的に遂行している。そのため、業務の細かい状況は非同期的に絶えず更新されていき、依存関係も絶えず更新される。従って、そのような連携業務が全体として良好に遂行されていくためには、各メンバが、自分の担当業務に関係する依存関係の最新状況について絶えず把握している必要がある。そしてそのためには、関連するメンバと緊密なコミュニケーションを行うことによって情報の伝達・共有を進めていくことが必須である。

しかし、従来のテレ・コミュニケーション技術は、非同期的に遂行される組織連携業務の中でタイムリーに情報の伝達や共有を進める効果が十分に発揮できていなかった。結果として、上記のような連携業務を成功させるために十分な質と量のコミュニケーションが維持できず、連携業務全体が思うように進行しないという状況が往々にして発生していた。

また、必要性の高い直接的な連携に関しては十分なコミュニケーションが取れており、一見すると連携業務全体も十分なパフォーマンスで遂行されているように見える場合でも、実際には伝達・共有されることのなかった潜在的な情報が多数存在していた場合が多かった。例えば、実際には連携することのなかった2人のメンバが、各々にとって有用であったはずの知識やアイディアを持っていたという事実が後になって判明するといった状況である。

そこで、本出願人は特許文献１に示すような、センサノードを利用してビジネス組織内コミュニケーションを活性化し、メンバ（作業者）間の連携強化を実現できる支援システムを提案した。しかし、関連するメンバへの接触の可否を作業開始前に指定する必要があるなど、機敏性、融通性、リアルタイム性に対する配慮が十分でなかった。

本件発明は、連携業務の現場において必要な時に必要な相手と機敏にコミュニケーションが取れ、また潜在的な連携情報をユーザにリアルタイムで提示することのできるユーザ連携システムとその装置を提供することをその目的とする。

本発明は、上記の目的を達成するため、ユーザが装着したセンサや各ユーザの周囲に設置された多種多数のセンサからユーザのリアルタイムの状況を検出する手段とユーザ状況に基づいて各ユーザの忙しさ度合いを判定する手段と、忙しさ度合いに基づき各ユーザ間のコミュニケーションを制御する手段を備えるユーザ連携システムを提供する。

本発明においては、好適には、複数のユーザ間のコミュニケーションを実現するユーザ連携システムであって、ユーザ各々のユーザ状況をリアルタイムで検出する検出部と、この検出部で検出されたユーザ状況に基づき、ユーザ各々の従事業務の忙しさ度合いを判定する処理部とを有し、判定した忙しさ度合いに基づき、ユーザ間のコミュニケーションを制御するユーザ連携システムを提供する。

また、本発明において好適には、複数のユーザ間のコミュニケーションを実現するユーザ連携システムであって、ユーザ各々のユーザ状況を検出する複数のセンサノードと、これらセンサノードとネットワークを介して接続される、通信部と記憶部と処理部とを含むサーバ装置とからなり、このサーバ装置は、センサノードで検出されたユーザ各々のユーザ状況を通信部で受信してその記憶部に記憶し、処理部において、受信したユーザ状況に基づき、ユーザの従事業務の忙しさ度合いを判定し、
判定された忙しさ度合いに基づき、ユーザ間のコミュニケーションを制御するユーザ連携システム、及びサーバ装置を提供する。

本発明によれば、業務現場において必要な時に必要な相手と機敏に連絡が取り合える軽快なコミュニケーションシステムを提供することができる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、第一の実施例におけるユーザ連携システム全体の構成図である。本システムは、デスクワーク空間、会議室、作業室を含むオフィス環境において適用されている。図に示した範囲内には4人のユーザ（User-1、User-2、User-3、User-4）がいる。ユーザUser-1は自身のデスクまたはその近傍（User-1’s Desk Area）におり、デスクワークに従事している（at Desk）。ユーザUser-2は会議室（Meeting Room）におり、会議中である（in Meeting）。ユーザUser-3とユーザUser-4は製造室（Manufacturing Room）におり、製造作業に従事している（at Manufacturing）。

システムのバックエンド部分（通信インフラやデータ処理を行う部分）は、1台のサーバ装置（Server）と、ローカルエリアネットワーク（LAN）等のIP（インターネット・プロトコル）ネットワーク（LAN/IP Network）と、IPネットワークとの通信インタフェースを備えたジグビー無線（ZigBee Communication、ZigBeeは登録商標）の基地局装置GW-1、GW-2と、必要に応じてZigBee無線の通信エリアを拡大するためのZigBee無線のルータ装置RT-1とから構成される。

システムのフロントエンド部分（データを生成したりユーザとのインタフェースを提供する部分）は、各ユーザが装着する腕時計型（Wrist Band）や名札型（Name Tag）などのウェアラブル型のセンサノードSN-1、SN-2、SN-3と、オフィス環境の適切な位置に設置された据付型（Stationary）のセンサノードSN-4、SN-5、SN-6と、アイアールディーエー（IrDA）無線で自身の識別信号（IrDA Signal）を定期的に発信する小型タグ（IrDA Tag-1、IrDA Tag-2、IrDA Tag-3、IrDA Tag-4、IrDA Tag-5、IrDA Tag-6）、また、ユーザUser-1のデスクワーク用のパーソナルコンピュータPC-1にインストールされたキー入力文字列（Keystroke）を記録するためのソフトウェアであるキー入力文字モニタ（Keystroke Monitor）とによって構成される。

センサノードSN-1〜SN-6には多種多様なセンサが内蔵されており、定期的にセンシングした測定情報を、ZigBee無線を用いてリアルタイムに送信する。送信された測定情報はZigBee無線のレベルでまず基地局装置まで到達し、センサノードSN-2やSN-4のが送信したデータの場合はルータ装置RT-1を経由する、さらに基地局装置からはIP ネットワークを経由することによってサーバ装置(Server)へと集約される。また、これらのセンサノードSNはIrDAの無線通信手段を有しており、近距離に存在する他のセンサノードや小型タグが発信するIrDA信号を検知することができる。このIrDA 信号の検知情報も、前述のセンサ測定情報と同様にZigBee無線を用いて送信され、サーバへと集約される。

また、PC-1にインストールされたキーストロークモニタ（Keystroke Monitor）は、ユーザUser-1がPC-1を使用したデスクワーク中に入力したキー入力文字列を記録し、リアルタイムにサーバ（Server）へ送信する。

ウェアラブル型のセンサノードSN-1、SN-2、SN-3に搭載されたセンサにより取得される情報は、そのセンサノードを装着したユーザに関わる環境情報または生体情報とみなすことができる。例えばユーザUser-1の装着した腕時計型のセンサノードSN-1では、表面に実装された温湿度センサによって、ユーザUser-1の居る場所（User-1’s Desk Area）の環境温度や環境湿度が取得される。一方、センサノードSN-1の裏面に実装された音湿度センサによって、ユーザUser-1の体温や発汗量といった生体情報が取得される。

据付け型のセンサノードSN-4、SN-5、SN-6に搭載されたセンサにより取得される情報は、そのセンサノードSNを据付けた場所に関わる環境情報とみなすことができる。例えば会議室（Meeting Room）内に据付けたセンサノードSN-4では、温湿度センサによって会議室（Meeting Room）内の環境温度や環境湿度が取得され、マイク（音声センサ）によって会議室（Meeting Room）で行われている会議の音声が取得される。一方、製造室（Manufacturing Room）内の常時運転中の大型装置（Large Equipment）に据付けたセンサノードSN-7では、温湿度センサによって装置温度や装置湿度が取得され、振動センサによって装置振動が取得される。

このように、オフィス環境の主要な人や場所、物にセンサノードを設置し、各種の測定情報を取得してリアルタイムにサーバ措置（Server）へ集約することによって、業務に関連するコンテキスト情報を推定するための材料となる生データが揃うことになる。サーバ装置(Server)は通常のコンピュータ装置の構成を有し、処理部である中央処理部（CPU）と、半導体メモリやハードディスクドライブ（HDD）などの記憶部と、入出力部、データをIPネットワークなどを使って送受信する通信部などから構成されることは言うまでもない。

図１中では、このようにして収集されるデータ（Gathered Data）の例として、パーソナルコンピュータ（PC）からのデータ（from PC）としてキーストローク情報（Keystroke）、センサノードからの情報（from SN）として、温度情報（Temperature）、湿度情報（Humidity）、加速度情報（Acceleration）、音声情報（Sound）、脈拍情報（Pulsebeat）、IrDA Signalの検出情報（IrDA Signal Detection）、照度情報（Illuminance）、振動情報（Vibration）、粉塵検出情報（Particle）を示している。

これらのセンサ測定情報、IrDA Signalの検知情報、キーストローク（Keystroke）情報は、各ユーザの業務行動を推定するための生データとしてサーバ（Server）に集約され、まずサーバ（Server）の記憶部上に蓄積される生データ基盤（RawData Base）に格納される。

コンテキスト解析部（Context Analyzer）は、生データ基盤（RawData Base）にリアルタイムに入力されてくるこれらの情報と、予め設定されたメンバリスト（Member List）、モデル定義（Model Definition）、行動判定用データベース（Behavior DB）、キーワード判定用データベース（Keyword DB）、忙しさ度合い判定用データベース（Busyness DB）の情報を用いることによって、各ユーザの従事業務(Task)と忙しさ度合いを含むコンテキスト情報を算出し、コンテキスト基盤（Context Base）へ格納する。後述するように、このときの処理は、コンテキスト解析部（Context Analyzer）内のモデル解析部（Model Analyzer）、行動解析部（Behavior Analyzer）、キーストローク解析部（Keystroke Analyzer）、忙しさ度合い評価部（Busyness Evaluator）とによって実現される。

なお、上述のメンバリスト（Member List）、モデル定義（Model Definition）、或いは行動判定用データベース（Behavior DB）などの各種データベース、及びコンテキスト基盤（Context Base）は、生データ基盤（RawData Base）同様、サーバ（Server）内の記憶部や外部の記憶装置に記憶される。また、コンテキスト解析部（Context Analyzer）を構成する各機能ブロックである、モデル解析部（Model Analyzer）、行動解析部（Behavior Analyzer）、キーストローク解析部（Keystroke Analyzer）、忙しさ度合い評価部（Busyness Evaluator）は、サーバ(Server)の処理部である中央処理部（CPU）で実行されるプログラム処理、あるいは一部ハードウェアとして構成される。なお、どちらの場合もコンテキスト解析部（Context Analyzer）の機能は処理部としての機能であることは言うまでもない。

上述のように、サーバ（Server）は、本実施例のシステムのフロントエンド部分からリアルタイムに受信、収集された各種データを元に、各ユーザのリアルタイムのコンテキスト情報を算出している状況にある。この状況の下で、各ユーザは自分自身の業務を自律的に遂行しているのであるが、業務の状況に応じて、他のユーザと連絡を取る必要性が発生する。しかし、ユーザUser-1がユーザUser-3と連絡を取ろうと思った時に、ユーザUser-3が自席にいるとは限らず、その時点では電話等では連絡が付かない状況にあるかもしれないし、仮に連絡が付いても、他のより優先度の高い業務の遂行している最中であるために連絡を受けるのが好ましくない状況にあるかもしれない。すなわち、連絡を取ろうと思った時が必ずしも自分と相手の双方にとってベストのタイミングであるとは限らない。

本実施例のユーザ連携システムでは、各ユーザの業務状況をリアルタイムに把握しているサーバ（Server）が、相手のリアルタイムの業務状況や、自分と相手の双方が都合の良いタイミングや、自分と潜在的に関係性の高い相手を提示してくれることによって、ユーザはそれをトリガとしてより良いタイミングで連絡を取り合うことができるようになり、結果として組織全体としての情報共有や連携が密になり、組織業務の生産性向上に役立つ。

ユーザ同士の具体的な連絡手段としては、本実施例では、各ユーザが装着するウェアラブル型のセンサノード（SN-1、SN-2、SN-3）に備えられた無線音声通話機能を利用する場合を中心に説明する。すなわち、各ユーザUser-1、User-2、User-3はそれぞれ、無線音声通話機能を備えたウェアラブル型のセンサノードSN-1、SN-2、SN-3を装着しており、ユーザUser-1とユーザUser-2が連絡を取り合う場合にはセンサノードSN-1とセンサノードSN-2の間での音声通信が起動され、ユーザUser-1とユーザUser-3が連絡を取り合う場合にはセンサノードSN-1とセンサノードSN-3の間での音声通信が起動される。

このとき、サーバ（Server）中の連携制御部（Collaboration Controller）が、連絡相手の業務状況等の提示、実際の音声通信の起動やその際に必要となる経路制御を実行してくれる。後で詳述するように、連携制御部（Collaboration Controller）は、設定部（Configurator）、経路制御部（Route Controller）、セッション制御部（Session Controller）、情報提示制御部（Presentation Controller）の各機能ブロックから構成されている。これらの機能ブロックは、コンテキスト解析部(Context Analyzer)の各機能ブロック同様、サーバ(Server)内の処理部であるCPUで実行されるプログラム処理、或いは一部ハードウェアで構成される。この連携制御部（Collaboration Controller）の機能は処理部としての機能である。

さて、ウェアラブル型のセンサノードSN-1とSN-3は腕時計型（WristBand）の形状をしており、センサノードSN-2は名札型（NameTag）の形状をしている。腕時計型と名札型のセンサノードは、形状だけでなく装着形態、通話形態、搭載するセンサ等に若干の違いがあるため、業務中に邪魔にならないかどうかや、サーバ（Server）がコンテキスト情報をより高精度に算出することができるかどうかといった基準によってどちらの形状のものを使用するかを選択すれば良い。例えば製造業務に従事しているユーザUser-3の場合、前屈みの体勢になる作業を行うことが多く、首から掛ける名札型のセンサノードでは作業の邪魔になってしまうかもしれない。そのような場合には、手首または腕の所定の位置に固定する腕時計型のセンサノードを装着する方が適しているであろう。また、火や水を使ったり、非常に狭い場所に入ったりする等の特殊な作業環境の場合には、名札型のセンサノードも腕時計型のセンサノードも邪魔になってしまうよう場合も考えられる（ユーザUser-4）。

そのような場合には、ユーザはセンサノードの代わりにさらに小さくて邪魔になりにくい小型タグ（IrDA Tag-5）を装着しても良い。小型タグ（IrDA Tag-5）のIrDA信号発信機能のおかげでユーザUser-4は据付型のセンサノードSN-7の近くに所在していることが検出されるので、センサノードSN-7の測定情報はユーザUser-4に関わる環境情報とみなすことができ、またユーザUser-4は他のユーザと連絡を取り合うのに、ウェアラブル型のセンサノードの代わりにセンサノードSN-7に備えられた無線音声通話機能を利用することができる。

本システムにおいて、ユーザ間連絡に手軽に適用可能な他の連絡手段としては、IP電話やPC上のメッセンジャーソフト等も考えられる。これらはIP（インターネット・プロトコル）という共通プロトコルの上に構築されており、仕様がオープンであり、連携や拡張を行うための開発環境が整っている。固定電話や携帯電話の場合、仕様がクローズであり、相互接続のための専用装置が必要である等の点で手軽さの面では劣るが、本実施例で用いる連絡手段として活用可能であることには本質的には変わりがない。

さて、ユーザUser-1がユーザUser-3と連絡を取ろうとしてセンサノードSN-1を操作した場合、本実施例のシステムでは、センサノードSN-1とセンサノードSN-3の間で実際に音声通信を確立する前段階の手順(1)として、情報提示制御部（Presentation Controller）が、上記のようにしてコンテキスト基盤（Context Base）に入力されてくるリアルタイムのコンテキスト情報を元に、センサノードSN-1に対してユーザUser-3のコンテキスト情報を提示する(Suggestion for Partners’ Context)。このことによってユーザUser-1は、その時点でユーザUser-3と連絡を取ることが相応しいかどうかを判断することができ、もし相応しくない場合には、より相応しいタイミングが来た時に情報提示制御部（Presentation Controller）が通知してくれるのを待つことができる。

そして実際に連絡を取ることを決めた時点で、改めて手順(2)として、セッション制御部（Session Controller）によってセンサノードSN-1とセンサノードSN-3の間の音声セッションが起動される（Session Initiation）。このようにして手順(3)の音声セッション（Voice Session）が最終的に確立し、ユーザUser-1とユーザUser-3の実際の通話が行われる。また、この一連の手順の際のセンサノードSN-1とサーバ（Server）との通信、およびセンサノードSN-1とセンサノードSN-3との通信を成立させるための制御は、各センサノードの識別情報と通常の経路制御プロトコルを用いて経路制御部（Route Controller）によって行われるので、説明を省略する。

さて、設定部（Configurator）は、ユーザや管理者からの各種設定（Configurations）を受け付け、各機能部へ反映する。各種設定とは、例えばシステム管理者によるメンバリスト（Member List）、モデル定義（Model Definition）、行動判定用データベース（Behavior DB）、キーワードデータベース（Keyword DB）、忙しさ度合い判定用データベース（Busyness DB）の登録や変更や、各ユーザによる自分の連絡相手のリスト（Partner List）の登録や変更である。以下、これらの各種設定を図面を用いて説明する。

図２（Ａ）〜（Ｃ）は、モデル定義（Model Definition）の定義内容を示したものである。生データ基盤（RawData Base）に入力されてくる生データから各ユーザの業務状況等のコンテキスト情報を算出するためには、オフィス環境に存在する業務と関係したモノや事柄をモデル化して、生データをそのモデルに対応付けることが必要になる。そのための定義集がモデル定義（Model Definition）である。

図２（Ａ）は、実物とモデルとの対応付けの定義を示している。実オブジェクト（Real Object）には、センサノード(SN)や小型タグ（IrDA Tag）のような、システムの構成要素である各々のデバイスが登録され、象徴オブジェクト（Symbolic Object）には、そのデバイスが概念的に表している実体が何であるかが示されており、さらに象徴種別（Symbolic Type）には、その概念的な実体の種別を表す分類が示されている。例えば実オブジェクト（Real Object）としてのセンサノードSN-1は、象徴オブジェクト（Symbolic Object）としてのユーザUser-1を表すものであって、その種別は人物（Person）である。本定義によって、ユーザUser-1が装着しているセンサノードSN-1は、モデル上はユーザUser-1の象徴物として扱われる。すなわち、センサノードSN-1が存在する位置はユーザUser-1が存在する位置であり、センサノードSN-1からサーバServerに送信されてくる測定情報等は、ユーザUser-1の行動もしくはユーザUser-1を取り巻く環境に関係する情報であると解釈されることができる。

各ユーザの所在位置の情報や、他のユーザやモノとの近接関係は、各ユーザのコンテキスト情報を算出する上で非常に大きな役割を果たす情報である。本実施例では、センサノードや小型タグ（IrDA-Tag）が近接通信手段を備え、センサノードが小型タグ（IrDA-Tag）や他のセンサノードの発信したIrDA Signalの情報を検出することによって、このような近接関係の情報を非常に効率的に、かつリアルタイムに取得することができる。センサノードや小型タグ（IrDA-Tag）のような実オブジェクト（Real Object）間の近接関係は、図２（Ａ）を用いることによって象徴オブジェクト（Symbolic Object）間の近接関係に読み替えることができる。ここで、象徴オブジェクト（Symbolic Object）間の近接関係は、その種別間の関係によって具体的な解釈が異なってくる。

図２（Ｂ）は、図２（Ａ）に示された象徴種別（Symbolic Type）間で、相互の近接関係がどのように解釈されるべきかの定義を示している。例えば人物（Person）同士の近接は、文字通り「人物（Person）同士が互いに近接している」ことを表すが、人物（Person）と位置（Location）の近接は、「その人物がその位置に所在している」ことを表している。また、人物（Person）と固定物（Fixed Object）との近接関係も、固定物（Fixed Object）は移動しないので、「人物が固定物の近くに所在している」状況を表している。一方、人物（Person）と移動物（Mobile Object）との近接関係の場合には、双方が移動する物体であるため、位置関係の定義に際してどちらが主とみさされるべきかは状況による。ここでは、移動物（Mobile Object）を人が持ち運ぶ道具等であるとみなした場合を想定し、「人が移動物を所持している」と定義した場合を示している。

これらの近接関係は、それ自体としても象徴オブジェクト（Symbolic Object）の位置に関するコンテキストを表すものであるが、この近接関係からより業務内容との関連性を持ったコンテキストとして解釈することができる。図２（Ｃ）は、象徴オブジェクト（Symbolic Object）または象徴種別（Symbolic Type）の置かれた近接関係を元に業務におけるタスク情報を導き出すための、IF-THENルールに基づいた定義を示している。例えば、ユーザUser-1が自身のデスクの近傍に所在している場合には、ユーザUser-1はデスクワークに従事していると解釈することができる（2C-A）。また、ある人物が会議室（Meeting Room）に所在している場合は、その人は会議に出席していると解釈することができる（2C-B）。以下、2C-C〜2C-Fも図２（Ｃ）に示されている通りに解釈できる。

コンテキスト解析部（Context Analyzer）内のモデル解析部（Model Analyzer）は、図２に示したモデル定義を用いて象徴オブジェクト（Symbolic Object）間の関係性を解釈し、最終的にユーザの従事業務(Task)の内容に関連する情報を導き出す。図３（Ａ）、（Ｂ）はモデル解析部（Model Analyzer）の実行する手順、すなわち、関係性分析フローを示したものであり、図３（Ａ）が一般的な処理フローを、図３（Ｂ）の点線で囲った部分が具体的な入力データに対する実際の処理の一例を示している。

図３（Ａ）において、モデル解析部（Model Analyzer）には、実オブジェクト（Real Object）に対応する情報として、センサノードが検出したIrDA信号の情報が入力される（3A）。具体的には、図２（Ｂ）に見るように、「SN-3がIrDA Tag-4のIrDA Signalを検出した」という情報（3A-1）や、「SN-3がSN-6のIrDA Signalを検出した」ということを意味する情報（3A-2）である。この入力情報をフォーマットのレベルで表現すれば、例えばIrDA Signalの検知情報であることを示す第１フィールド、検知主体を規定する第2フィールド、検知対象を規定する第3フィールドを有しているということである。そして情報3A-1の場合であれば、第2フィールドの値がセンサノードSN-3を表す識別情報、第3フィールドの値が小型タグIrDA Tag-4を表す識別情報になっているということである。

IrDA Signal検知情報の入力後、モデル解析部（Model Analyzer）はまず図２（Ａ）の定義に従って、実オブジェクト（Real Object）の情報をそれが意味する象徴オブジェクト（Symbolic Object）の情報へと変換する（3B）。具体的には、入力情報3A-1に含まれるセンサノードSN-3を表す識別情報はユーザUser-3の情報を表す識別情報へ、小型タグIrDA Tag-4を表す識別情報は小型ツール（Small Tool）を表す識別情報へと変換される（3B-1）。入力情報3A-2に関しても同様である（3B-2）。

次に、モデル解析部（Model Analyzer）は図２（Ｂ）の定義に従って、象徴オブジェクト（Symbolic Object）間の近接関係を、象徴種別（Symbolic Type）間の関係に基づいて位置関係と主従関係を含めた関係として解釈し直す（3C）。この結果、入力情報3A-1は「User-3はSmall Toolを所持している」という関係情報に解釈し直され（3C-1）、入力情報3A-2は「User-3はManufacturing Room内のArea-2に居る」という関係情報に解釈し直される（3C-2）。

入力情報が複数ある場合、各々から導き出された象徴オブジェクト（Symbolic Object）間の関係情報の間に依存関係が存在する場合がある。そのような場合には、述語論理（Predicate Logic）の手法を用い、それら複数の関係情報から間接的に導き出せる暗黙的な関係情報を抽出する（3D）。例えば、関係情報3C-1と関係情報3C-2とからは、小型ツール（Small Tool）の所在に関する暗黙的な関係情報3D-1を導き出すことができる。

さらに、そのようにして得られた関係情報の各々を、図２（Ｃ）の定義に照合することによって、ユーザの従事業務の内容に関連する情報を導き出す（3E）。本例では、関係情報3C-1は図２（Ｃ）の定義2C-Dに、関係情報3C-2は図２（Ｃ）の定義2C-Cに該当しており、この両方共が「User-3はManufacturingに従事している」という従事タスク情報を意味している（3E-1）。

このようにして得られた従事タスクの情報は、コンテキスト情報の構成要素としてコンテキスト基盤（Context Base）へ格納される（3F）。本例では、最低限の場合で従事タスク情報3E-1のみを格納すれば良い。ただし途中で導き出された3C-1、3C-2、3D-1といった関係情報も、業務に関係するある種のコンテキスト情報を示しているので、これらも同時にコンテキスト基盤（Context Base）へ格納しても良い。

本実施例におけるコンテキスト解析部（Context Analyzer）は、上記のような近接関係に基づく大まかな従事業務(Task)推定だけでなく、各ユーザの行動情報や周囲の環境情報を元に、各ユーザの細かい行動を推定することができる。図４は、コンテキスト解析部（Context Analyzer）内の行動解析部（Behavior Analyzer）が実行するユーザUser-1の行動の推定手順を示し、図５は、キーストローク解析部（Keystroke Analyzer）がユーザUser-1の業務に関係するキーワードを検出する手順を示している。

図４では、センサノードSN-3がその内部の加速度センサが計測した加速度データを用いて、ユーザUser-3が従事業務(Task)として製造作業（Manufacturing）に従事している時の行動の推定、即ち、更に細かい作業履歴を推定する例を示している。

センサノードSN-3はユーザUser-3が装着しているので、センサノードSN-3が計測した加速度データ（4A）は、ユーザUser-3の行動を反映している。一方、行動判定用データベース（Behavior DB）には、ユーザが製造作業（Manufacturing）業務の中で行う各作業工程において計測される典型的なパターンデータが予め登録されている（4B）。行動解析部（Behavior Analyzer）はこれらのパターンデータ（Process-1、Process-2等）を参照しながら、センサノードSN-3が測定した加速度データの時系列の中から各々のパターンデータにマッチする時間小区間を抽出していく（4C）。そして、特定作業Process-1のパターンデータへの相関度が持続的に高い時間小区間を、まとめてProcess-1へ従事している時間区間としてラベリングする。同様に、Process-2、Process-3等の各特定作業に対するラベリングが行われ、結果としてUser-3が製造作業（Manufacturing）に従事している最中の詳細な作業工程である従事業務の詳細状況の推定が時系列的に完成する（4D）。このような作業履歴の情報は、サーバ（Server）内で扱いやすい形式、例えばテーブル形式（4E）に変換された上で、User-3のコンテキストを構成する情報としてコンテキスト基盤（Context Base）へ格納される（4F）。

次に、図５のユーザUser-1の業務に関係するリアルタイムでキーワードを検出する手順を説明する。

User-1がPC-1において文書作成等の業務作業を行うと、User-1の行ったキー操作はPC-1内のキーストロークモニタ（Keystroke Monitor）によって記録され、リアルタイムにServerへ送信される。図５では簡単のためにUser-1が英文を入力した場合を例として説明している。このとき、User-1によるPC-1へのキー入力系列（5A）に対して、キーストロークモニタ（Keystroke Monitor）は入力文字の各々に対応する文字コード（Code）と、各々が入力された時刻（Time）の情報を記録し、これをKeystroke情報としてサーバServerへ送信する（5B）。ここで5Bは、入力系列5Aの一部分、s'、e'、 '、s'、t'の5文字から成る系列に対するKeystroke情報を示している（ 'は空白文字を表している）。このとき、例えばs'という文字（Character）に対するCode情報は0x73であり（一般的にアスキーコードと呼ばれている）、そのTime情報はT-5aである。このCodeとTimeの2つの情報が実際にサーバServerへ送信されるKeystroke情報である。

サーバ（Server）では、コンテキスト解析部（Context Analyzer）内のキーストローク解析部（Keystroke Analyzer）が、まず入力系列5Aの個々の文字をタイプされた時刻順に結合し、ユーザが入力した実際の文字列をで復元する（5C）。そして、専門業務や業務コンテキストを特徴的に表すキーワードが予め格納されたキーワードデータベース（Keyword DB）を参照することにより、上記の文字列の中から業務に関連するキーワードを抽出する（5D）。抽出されたキーワードは、User-1の業務に関わるコンテキスト情報としてコンテキスト基盤（Context Base）へ格納される（5E）。

キーワードデータベース（Keyword DB）には、抽出したい業務コンテキストに関係するキーワードを登録しておけば良い。専門性の高い業務であればその分野の専門用語を登録すれば良いし、それほど専門性の高くない業務であっても多くの場合にはその業務の状況を表す特徴的な表現が存在するので、そのような一般的なキーワードを登録しておけば良い。例えば資材調達業務のような場合には、「資材」「調達」「発注」「承認」「契約」「決済」といったキーワードを用いれば良い。あるいは図２の説明において示したように、小型ツール（Small Tool）や大型装置（Large Equipment）といった、特定業務（ここではManufacturing）に強く関連する物品等の名称を登録しておいても良い。このように、キーワードデータベース（Keyword DB）に登録するキーワードには、その種別や意味にはいかなる制約もなく、単純に、検出したい業務コンテキストにおいてユーザが入力するであろう特徴的な単語であればどのようなものを登録しても構わない。

なお入力系列5Aは、理解のしやすさのために、ユーザUser-1がタイプミス等をすることもなく理想的な手順で文章入力を行った場合の例を示している。しかし実際のPC作業におけるキー入力では、入力行を移動したり、ミスタイプした文字を後から訂正するといった操作が相応の頻度で発生するのが普通であるため、生の入力系列にはこれらの操作に付随して移動キーやバックスペース等の制御文字も含まれることになり、しかもこれらはそのまま時系列的に記録されるため、復元文字列5Bでは、ユーザUser-1が入力した最終形の文章が忠実に再現されるわけではなく、最終形の文章を用いた場合と比較すれば、正しい単語として抽出できる割合も相応に低下してしまう。しかし、ここで抽出したいのは特定の業務コンテキストに特徴的なキーワードであり、そのようなキーワードあるいはそれに類する別のキーワードは、1回だけでなく繰り返し入力される場合が多いので、上記のようなゴミ情報を多数含んだ生の入力系列からであっても、実用上十分な効率で必要なキーワードの抽出が達成されると期待することができる。

このように、キーストローク解析部（Keystroke Analyzer）が行うのは時系列データの結合やキーワードマッチングのような単純な処理のみであり、最終形の文章を復元したり文章全体の構文解析を行ったりといった複雑な処理が不要であるにも関わらず、リアルタイムで業務に関わるコンテキストを効率的に抽出できるという点で、実装上も実用上も大きなメリットがある。

なお、図５ではユーザUser-1が英文を入力した場合を示したが、日本語や中国語のように、キーボードをタイプしたときに発生するコード（キーコード）と実際に文章として入力されるコード（文字コード）が異なる言語の場合は、キーストロークモニタ（Keystroke Monitor）が記録するCodeとして（キーコードではなく）文字コードを採用すれば良い。これらの言語におけるキーコードと文字コードとの変換は、「インプットメソッドエディタ（IME）」や「フロントエンドプロセッサ（FEP）」と呼ばれる、オペレーティングシステム（OS）に付属の言語入力ソフトウェアが行うのが普通である。従ってキーストロークモニタ（Keystroke Monitor）は、いかなる言語が対象であってもこれらの言語入力ソフトウェアから出力される文字コードを記録すれば良いだけであり、図５における処理と同様に単純な記録機能および送信機能のみを備えていれば良い。ただし、日本語のように、複数の文字コード（JISコード、Shift-JISコード、EUCコード、UTF-8コード等）を有する言語の場合で、もしPC側で使用している文字コードとキーワードデータベース（Keyword DB）に格納されたキーワードに使用している文字コードとが異なっていた場合には、キーストロークモニタ（Keystroke Monitor）かキーストローク解析部（Keystroke Analyzer）のいずれかが、互いの文字コードを変換する機能を備えている必要がある。

また、関連技術として、特許文献１に開示されているように、User-1がPC-1において現在作成もしくは閲覧しているドキュメントに含まれる文章を解析することによってキーワードを抽出するという技術を適用しても良い。この場合には、自分が入力したキーワードだけでなく他人が書いた文章に含まれるキーワードも幅広く抽出対象となり、本願と比べると検索対象となる文字列の量が膨大になるという特徴がある。この特徴を効果的に生かすためには、User-1に真に関連性の高いキーワードの絞り込みを行う手段や、通信データ量が増大しすぎないようにPC-1において名詞句のみを抽出するための構文解析手段を併せて具備することが好適である。このようにすれば、幅広い検索対象データを用いて効率的にUser-1に関連性の高いキーワードを抽出することが可能となる。

続いて、図６は、本実施例のシステム中の、忙しさ度合い判定用データベース(Busyness DB)に格納されている忙しさ度合い（Busyness）値を算出するための基礎データと、それに基づき忙しさ度合い解析部（Busyness Evaluator）が忙しさ度合い(Busyness)を算出する手順とを示している。

忙しさ度合い（Busyness）の定義としては、例えばその時点で従事している業務を一時的に中断して通話呼び出しに応じるという行動を取るためのコストを表すものとして定義すれば良い。これを百分率で数値表現し、その値が大きいほど通話呼び出しに応じるコストが大きい、つまりより忙しい状況を表していると定義することができる。

忙しさ度合い解析部（Busyness Evaluator）に入力されるのは、モデル解析部（Model Analyzer）、行動解析部（Behavior Analyzer）、キーストローク解析部（Keystroke Analyzer）によって検出され、コンテキスト基盤（Context Base）に蓄積された、ユーザの従事業務に関わるコンテキスト情報である。忙しさ度合い解析部（Busyness Evaluator）は、業務の大分類や詳細状況に対応して予め定義されて忙しさ度合い判定用データベース(Busyness DB)に格納されている忙しさ度合い（Busyness）値算出のための基礎データ（6A）を参照しながら、これらの入力情報から各ユーザの忙しさ度合い（Busyness）値を算出していく。

具体的な手順として、忙しさ度合い解析部（Busyness Evaluator）はまず、モデル解析部（Model Analyzer）が検出した各ユーザの従事業務の大分類（Desk Work、Meeting、Manufacturing等）に基づき、忙しさ度合い判定用データベース（Busyness DB）を参照することによって各ユーザの忙しさ度合い（Busyness）値に大局的な重み付けを行う（6B）。例えばデスクワーク（Desk Work）という業務を大局的に評価した場合、通話呼び出しに応じるために一時的に中断することは比較的容易であるため、大局的な忙しさ度合い（Busyness）値は20という小さな値が定義されている（6C）。一方、会議（Meeting）の場合には、その場を一時退出する等の周囲への配慮が必要とされる場合が多く、大局的に評価すれば通話呼び出しに応じることは比較的困難であるため、大局的な忙しさ度合い（Busyness）値は60という大きな値が定義されている（6D）。また製造作業（Manufacturing）の場合、作業内容によっては中断しても全く問題ない場合もあれば全く中断不可能な場合もあり一概にどちらとは言えないので、大局的な忙しさ度合い（Busyness）値は40という中間的な値が定義されている（6E）。

上記のようにして業務の大分類に基づいた大局的な重み付けを行った後に、評価の後に、忙しさ度合い解析部（Busyness Evaluator）は、行動解析部（Behavior Analyzer）やキーストローク解析部（Keystroke Analyzer）によって検出された業務の詳細状況に基づき、忙しさ度合い判定用データベース（Busyness DB）を参照することによって各ユーザの忙しさ度合い（Busyness）値の詳細評価を行う（6F）。図６中に示したのはそのほんの一部であるが、例えばデスクワーク（Desk Work）という大局的な業務の場合、キーストローク解析部（Keystroke Analyzer）によって重要なキーワードが多数検出された場合には重要度の高い業務に従事していると評価することができ、結果として先に算出した大局的な忙しさ度合い（Busyness）値に対して30という値が加算される（6G）。同時に、ユーザのキーストロークの入力頻度に基づく評価も行われる。入力頻度が高い（キー入力のペースが速い）場合には繁忙な状況にあると評価することができ、結果として忙しさ度合い（Busyness）値にはさらに20という値が加算されることになる（6H）。同様にして、会議（Meeting）や製造作業（Manufacturing）という大局的な業務に従事している場合の詳細状況に基づく評価も実行することができる。

本実施例では、忙しさ度合い解析部（Busyness Evaluator）はまずモデル解析部（Model Analyzer）が検出した大局的な業務状況に基づいて忙しさ度合い（Busyness）値の大局的な重み付けを行い、その後行動解析部（Behavior Analyzer）やキーストローク解析部（Keystroke Analyzer）によって検出された詳細な業務状況に基づいて忙しさ度合い（Busyness）値の詳細な評価を行うという、二段構えの手順を行っている。これは、各ユーザの業務状況が常に完全な形で算出できるとは限らないため、算出できた業務状況の精度に応じて柔軟に忙しさ度合い（Busyness）値を算出するための工夫である。

具体的には、センサの測定情報が十分な解像度で収集できなかったり、情報量は十分であってもユーザが典型的でない行動を取ったりした場合には、行動解析部（Behavior Analyzer）やキーストローク解析部（Keystroke Analyzer）はユーザの詳細状況を正確に推定することができないので、モデル解析部（Model Analyzer）が検出した業務の大分類のみの情報しか分からないという場合が起こり得る。

逆に、センサの測定情報は十分でも近接通信の情報が十分でなければ、業務の非常に細かい状況は分かるのに大局的な状況が分からないという場合も起こり得る。そのような場合でも、本実施例のように業務の大分類と詳細状況とに分けて段階を踏んで忙しさ度合い（Busyness）値を評価するという手順を取ることにより、どちらの情報が欠けた場合であっても、得られた不完全な情報を手掛かりにしてそれなりの信頼性を有する忙しさ度合い（Busyness）値を柔軟に算出することができるということになる。このように、本実施例はユーザの置かれた状況を評価するための非常に柔軟かつロバストな仕組みを備えており、極めて実用的なシステムを構築することができる。

図７は、コンテキスト解析部(Context Analyzer)の動作により、時間の経過とともにコンテキスト基盤（Context Base）に格納されていくユーザUser-1〜User-4各々のコンテキスト情報の詳細を示したものである。

生データ基盤（RawData Base）に入力された生の測定データ等がコンテキスト解析部（Context Analyzer）において図３〜図６で示したような処理を受けた結果、メンバリスト（Member List）に登録されている各々のユーザUser-1〜User-4の従事業務の情報とその時々の忙しさ度合い（Busyness）値の情報とが算出され、それらが時々刻々とコンテキスト基盤（Context Base）へ蓄積されていく（7A）。図中では、コンテキスト基盤（Context Base）へ蓄積されたUser-1〜User-4の情報の時系列変化の例を示している（7B）。各ユーザUserの情報は、大分類としての従事業務の情報（Task）、その業務の詳細状況の情報（Detailed Context）、および忙しさ度合いの情報（Busyness）とを含んでおり、これらの時系列的な変遷が蓄積されていく（7C）。例えば、User-1's Taskの変遷から、User-1はまずデスクワーク（Desk Work）を行い、次に会議（Meeting）に出席し、再び短時間のデスクワーク（Desk Work）を行った後に出張（Outside Job）に出るというスケジュールを辿っていることが分かる。そのときの忙しさ度合い（Busyness）値の変遷から、デスクワークに従事している時間帯は概ね連絡を受けやすい状況にあり、会議や出張の時間帯は連絡を受けるのは困難であることが分かる。他のユーザも各々が自律的に業務を遂行しているため、全体として各メンバの従事業務の変遷も、忙しさ度合い（Busyness）値が示す連絡の受けやすさの変遷も非同期的なものとなっている。

ここで、時刻Time-1におけるコンテキスト情報の詳細（7D）を具体的に見ると、User-1の従事業務（Task）はデスクワーク（Desk Work）であり、詳細状況（Detailed Context）はくつろいだ状態（Relaxed）であり、忙しさ度合い（Busyness）は15である。同様に、User-2の従事業務（Task）は会議（Meeting）、詳細状況（Detailed Context）は発言中（in Speech）、忙しさ度合い（Busyness）値は90であり、User-3の従事業務（Task）は製造作業（Manufacturing）、詳細状況（Detailed Context）は自動運転中（on Autopilot）、忙しさ度合い（Busyness）値は35であり、User-4の従事業務（Task）は製造作業（Manufacturing）、詳細状況（Detailed Context）は整備中（on Maintenance）、忙しさ度合い（Busyness）値は60である。この時刻Time-1は、User-1とUser-3の双方の忙しさ度合い（Busyness）値が十分に小さい時間帯であり、すなわち両者が連絡を取るのに最も都合の良い時間帯であるということを意味している。

次に、図８は、User-1が自分に関係するメンバと連絡を取る必要がある状況において、User-1が各メンバのコンテキスト情報を取得する手順と、ウェアラブル型センサノードSN-1における表示画面の例を示している。

User-1の業務において、User-3への問合せや依頼を行う必要が生じたとする。真に緊急を要する用件である場合には、User-3が他の重要業務の遂行中であっても、強制的に割り込む形で電話をかけたり、直接面会しに行ったりするであろう。しかしここでは、従来技術で言えば電子メールを活用していた場合のように、特別に緊急性の高いわけではない一般的な用件であったとする。このような場合、従来であれば相手の置かれている状況が分からなかったため、不在であるタイミングに電話をかけてしまう無駄が発生したり、相手の業務を中断させてしまうことを遠慮して電話をかけにくい心理状態が生まれたりすることがあり、結果的に必要なコミュニケーションが十分に取れなくなったり、必要なはずのコミュニケーションを無意識的に抑制しまうといった問題点を生んでいた。また、電子メールは一見このような状況に最適な効果を生む従来技術に思えるかもしれないが、電子メールはテキスト入力が必要であり、簡単な会話で済む用件をその何倍もの時間を費やして文章を作成するのは非常に効率が悪く、連絡事項が多い場合には結果的に自身の業務効率が低下する要因になってしまっていた。このような状況において、本実施例のシステムは自分の業務効率も相手の業務効率も低下させることがなく簡単な操作で軽快に音声コミュニケーションを実現できるため、絶大な効果を発揮する。

まず、図８において、User-1が時刻Time-0の頃にUer-3へ連絡を取りたいと考えたとする。このときUser-1は、自身が身に付けているウェアラブル型センサノードSN-1を操作することによって、自分の業務に関連のあるメンバであるパートナー（Partner）の業務状況を取得しようとする（8A）。この操作によってセンサノードSN-1ではサーバ（Server）への問合せ手順が起動し（8B）、User-1のパートナー（Partner）の業務状況を問い合わせるメッセージが送信される（8C）。このメッセージはサーバ（Server）において情報提示制御部（Presentation Controller）が受信し、User-1のパートナーリスト（User-1's Partner List）に登録されているメンバの現在（時刻Time-0）の業務状況をコンテキスト基盤（Context Base）から取得する（8D）。取得された情報は問い合わせメッセージ8Cへの応答メッセージの形でセンサノードSN-1へ返送される（8E）。応答メッセージ8Eには、User-1のパートナー（Partner）一人一人の名前を表す情報、現在の従事業務の情報（Task）、現在の忙しさ度合い（Busyness）の情報とが含まれている（8F）。応答メッセージ8Eを受信したセンサノードSN-1は、その情報を画面に表示する（8G）。ウェアラブル型センサノードの小さな画面へ表示する際には、各パートナー（Partner）の名前、従事業務、忙しさを文字ベースで簡潔に表示するのが好適である（8H）。User-1は、この画面表示を視覚的に認識（8I）することにより、User-3を含む各パートナー（Partner）の業務状況を確認することができる。

図９は、図８に引き続く操作として、User-1がUser-3への連絡を予約した場合の処理手順と、ウェアラブル型センサノードSN-1における表示画面の例を示している。

User-1のパートナー（Partner）の業務情報を表示した画面表示8Hでは、各パートナー（Partner）の名前の左側に三角のマークが付されている（8J）。これは、各パートナー（Partner）に対して何らかの操作が可能であることを示している。ここでは、ボタン操作によりこのマークの付いた各項目を選択し、その項目に対するアクションを指示することができる。ここでUser-1が連絡したい相手であるUser-3を選択するボタン操作を行う（9A）と、SN-1の画面表示が更新され（9B）、User-3の名前の左側に付されたマークがハイライト表示され（9C）、さらにUer-3に対して指定することのできるアクションの一覧が表示される（9D）。ここで、この時点（時刻Time-0）でのUser-3の忙しさ度合い（Busyness）値は95であり、User-3は非常に忙しい状況であることが予想される。そのためUser-1はこの時点ではUser-3へ連絡を入れることはせず、代わりにUser-3への通話の予約を意味する”Reserve”を選択したとする（9E）。するとこの予約を実行するための手順が起動され（9F）、サーバ（Server）へUser-3との通話を予約するメッセージが送信される（9G）。サーバ（Server）において情報提示制御部（Presentation Controller）がこの予約メッセージを受信すると、User-1とUser-3の業務状況の監視を開始し（9H）、SN-1へ予約完了メッセージを返送する（9I）。

手順9H以降、情報提示制御部（Presentation Controller）は、User-1とUser-3の双方の忙しさ度合い（Busyness）値が十分に小さくなるまで、コンテキスト基盤（Context Base）を監視し続ける。

図１０は、図９に引き続く動作として、User-3との通話の条件が満たされ実際に通話が開始されるまでの動作を示している。

時刻がTime-1の頃になると、User-1とUser-3の双方の忙しさ度合い（Busyness）値が十分に小さくなり、このことは手順9H以降、忙しさ度合い（Busyness）値を監視を続けていた情報提示制御部（Presentation Controller）により検出される（10A）。このとき、情報提示制御部（Presentation Controller）は監視を停止し（10B）、センサノードSN-1へUser-3の業務状況を示す情報を送信する（10C）。この情報はセンサノードSN-1の画面に表示され、同時にUser-3に対して通話を開始するかどうかの選択が促される（10D）。表示情報10Dでは、User-3の現在（時刻Time-1）の従事業務が製造作業（Manufacturing）であること、忙しさ度合い（Busyness）値が35であることが表示されているのに加えて、User-3との通話を開始するかどうかを問い合わせる質問メッセージ（Now Communicate to User-3 ?）と、この質問メッセージに対して「Yes」か「No」のいずれかを選択できることを表す丸いマークが表示されている（10E）。

User-1がボタン操作により「Yes」を選択する（10F）と、通話セッションの確立手順が起動され（10G）、User-3とのセッション確立を要求するメッセージがサーバ（Server）へ送信される（10H）。ここで、メッセージ10HはUser-3に宛てたものであるが、センサノードSN-1はUser-3と通話するためにどの装置との間でセッションを確立すれば良いのかを知らないため、本メッセージはサーバ（Server）への依頼メッセージとして送信される。サーバ（Server）内ではセッション制御部（Session Controller）が本メッセージを受信し、図２（Ａ）で示した定義情報を元に、User-3と通話するためにはセンサノードSN-3との間でセッションを確立すれば良いと判断し（10I）、セッション確立要求のメッセージをセンサノードSN-3へ転送する（10J）。

本メッセージを受信したセンサノードSN-3は通話の着信であることを識別し（10K）、アラーム音を発し（10L）、着信を知らせる画面を表示する（10M）。表示画面10Nには、User-1からの着信であることを示すメッセージ（Call from User-1）と共に、着信を受けるかどうかを問い合わせる質問メッセージ（Now Communicate to User-1 ?）と、この質問メッセージに対する選択肢が「Yes」と「No」で提示される。User-3が「Yes」を選択する（10O）ことにより、セッションを確立するための応答メッセージをサーバへ返送する（10P）。ここで、メッセージ10PはUser-1に宛てたものであるが、センサノードSN-3はUser-1と通話するためにどの装置との間でセッションを確立しようとしているのかを知らないため、本メッセージはサーバ（Server）への依頼メッセージとして送信される。そしてサーバ（Server）内のセッション制御部（Session Controller）によって返送先がセンサノードSN-1であることが判断され（10Q）、セッション確立応答のメッセージがセンサノードSN-1へ転送される（10R）。この時点で、SN-1とSN-3の双方で音声セッションがオープンされ（10S、10T）、以後の音声セッションが開始される（10U）。音声セッション10Uにおいても、手順10Iや10Qにおけるのと同様に、セッション制御部（Session Controller）がセンサノードSN-1とセンサノードSN-3との間の通信を仲介する（10V）。

なお、手順10I、10Q、10Vが示すように、本実施例においてはセンサノードSN-1とセンサノードSN-3の間の通信は必ずサーバ（Server）を経由する。セッション制御部（Session Controller）がユーザ情報から宛先の物理アドレスを識別することにより、センサノードSN-1もセンサノードSN-3も互いの物理アドレスを知る必要がなく、どの装置との通信であってもサーバ（Server）との間で通信すれば良いので、各センサノードや基地局における経路制御が非常に単純化され、これらの小型装置の制御論理の設計が容易となる効果がある。同様に、ユーザからもこれらの物理アドレスは完全に隠蔽されているので、電話や電子メールのように通信手段に固有のアドレス情報をユーザが意識する必要はなく、単に連絡相手を選択するだけで良いという効果がある。

以上詳述してきた図８〜図１０のフローでは、ユーザ自身が特定の人物と連絡したい状況にある場合における本実施例のシステムの動作を示した。次に説明する実施例では、ユーザ自身では誰かと連絡を取る必要性を意識していない状況において、潜在的なコミュニケーションの必要性が自動的に発見され、そのことをシステム側からユーザに喚起することで、従来であれば実現することのなかった組織内の新たな連携の創出や緊密な情報共有が実現されるという例を示す。

図１１は、本システムにおいて、ユーザUser-1の業務内容について詳細な知識を持っているメンバの情報が提示される場合の一実施例の動作を示している。

User-1がデスクワーク（Desk Work）を行っている間、PC-1にインストールされたキーストロークモニタ（Keystroke Monitor）によりUser-1のキー入力（11A）が監視され（11B）、サーバ（Server）へ収集されている（11C）。サーバ（Server）ではキーストローク解析部（Keystroke Analyzer）によって入力文字列が復元される（11D）。このとき、User-1が入力した文章の中に「high throughput」および「congestion control」という専門用語が含まれていたとする。キーストローク解析部（Keystroke Analyzer）は、キーワードデータベース（Keyword DB）を参照することによってこの文章の中から業務に関連するキーワードの抽出を試み、結果として上記2つの専門用語が抽出される（11E）。

サーバ(Server)のCPUで実行されるキーストローク解析部（Keystroke Analyzer）は次にコンテキスト基盤（Context Base）を検索し、この2つの専門用語に関連するキーワードが他のユーザのキーワードに含まれているかどうかを調べる。このとき、ユーザUser-9の業務に関連するキーワード（11F）の中に、「Congestion Control」という全く同じキーワードと、「Throughput Monitoring」という、同じ単語を含む類似のキーワードとが見付かったとする（11G）。すると今度はサーバ(Server)内の情報提示制御部（Presentation Controller）が、User-1が使用しているPC-1に対して通知メッセージ（11I）を送信し（11H）、User-9がUser-1の従事分野に対して詳細な知識を持っていると思われることを提示（11L）し、情報交換を行うことを喚起する（11J）。PC-1上に表示される画面（11K）では、User-9の業務に関連するキーワード（11M）に加えてUser-9の現在の従事業務と忙しさ度合い（Busyness）値の情報（11N）も表示されるので、この情報に基づいてUser-9と今すぐ連絡を取ることができるか、後にした方が良いかを判断することができる。

User-1はそれまでUser-9とのコミュニケーションの必要性を自覚していなかったので、自覚していた場合と比べると電話等をかけることによりUser-9の業務を中断させてしまうことに対する遠慮の心理がより強く作用する可能性があり、ただ単にUse-9の存在を提示しただけでは実際のコラボレーションにまで発展しない可能性がある。このような場合、相手にとって都合の良いタイミングを見計らって連絡を取ることのできる本発明の効果がいっそう際立って現れる。遠慮の心理を除去することにより、従来であれば決して行われることのなかった新たなコラボレーションを成立させることができるので、結果として組織全体の生産性や創造性を飛躍的に向上させるという効果が期待できる。

また、ユーザ(User-1)のPC-1の画面11Kでは、User-9の詳細情報へのリンクも提示される（11O）ので、User-1がUser-9と面識がない場合であっても、User-1はUser-9の所属や担当業務等の詳細情報を素早く確認することができる。また、また、User-1、User-9共にデスクワークに従事している場合には、連絡手段としてはウェアラブル型のセンサノードを用いるだけでなく、電子メールやインスタントメッセンジャー等の従来型の手段を用いることも当然可能である。そこで画面11Kでは連絡手段としてこれらの複数の選択肢を提示しており、また図９で説明したのと同様に後で連絡を行うための予約を行うという選択肢も提示している（11P）。このように、複数の連絡手段を用いることが可能な環境においては、ユーザが好む手段を選択することができるようにすることで、従来技術と組み合わせながら本発明の応用の幅をさらに広げることができる。

なお本例では、分かりやすさのために画面11Kは独立した描画ウィンドウのイメージで示した。ただし、User-1がワードプロセッサ等で文章を入力している時に、頻繁にこのような描画ウィンドウがポップアップされた場合、User-1の文章入力が中断され、業務効率が低下してしまう懸念がある。従って、PC-1条での画面表示11Jの具体的な方法としては、提示情報を効果的に通知しつつも、User-1のデスクワークを中断しないような配慮が望ましい。例えば、画面の端に情報提示用の小領域を設け、そこに提示情報の有無や要約のみを表示するようにして、それ以上の詳細情報はUser-1がその領域を選択した時にはじめて表示されるようにするといった方法が有効である。

以上、具体的な実施例を用い、ユーザ連携システム、及びそのシステムで用いるサーバなどの各装置を詳述してきた本発明は、必要な時に必要な相手と機敏に連絡が取り合える、軽快なコミュニケーションツールを実現することができる。更に、自分と相手の双方が都合の良いタイミング、更には自分と潜在的に関係性の高い相手をリアルタイムでシステムが提示してくれるのでそれをトリガとして簡単にコミュニケーションが開始でき、結果として組織全体としての情報共有や連携が密になり、組織業務の生産性向上に役立つことが出来る。

第一の実施例のユーザ連携システムの全体構成を示す図である。 第一の実施例におけるモデル定義（Model Definition）の定義内容を示す図であって、特に、実物とモデルとの対応付けの定義と、象徴種別間で、相互の近接関係がどのように解釈されるべきかの定義と、象徴オブジェクトまたは象徴種別の置かれた近接関係を元に業務におけるタスク情報を導き出すための、IF-THENルールに基づいた定義を示す図である。 第一の実施例におけるモデル解析部（Model Analyzer）の実行する手順（関係性分析フロー）を示す図であって、一般的な処理フローと、具体的な入力データに対する実際の処理の一例を示す図である。 第一の実施例における行動解析部（Behavior Analyzer）によるユーザ行動の詳細推定を説明するための図である。 第一の実施例におけるキーストローク解析部（Keystroke Analyzer）によるキーワード検出を説明するための図である。 第一の実施例における忙しさ度合い（Busyness）の算出方法を説明するための図である。 第一の実施例におけるコンテキスト基盤（Context Base）に格納された時系列的なコンテキスト情報を示す図である。 第一の実施例におけるユーザによるパートナーズコンテキスト（Partners' Context）取得フローを示す図である。 第一の実施例における連絡相手の予約が完了するまでの予約フローを示す図である。 第一の実施例における予約セッションの確立フローを示す図である。 第二の実施例におけるシステムによる潜在的な連携相手の発見・提示を説明するための図である。

符号の説明

User…ユーザ、
SN…センサノード、
GW…基地局装置、
RT…ルータ装置、
IrDA Tag…小型タグ、
Meeting Room…会議室、
Manufacturing Room…製造室、
Server…サーバ、
RawData Base…生データ基盤、
Model Definition…モデル定義、
Member List…メンバリスト、
Context Analyzer…コンテキスト解析部、
Busyness Evaluator…忙しさ度合い評価部、
Behavior DB…行動判定用データベース、
Keyword DB…キーワードデータベース、
Context Base…コンテキスト基盤、
Busyness DB…忙しさ度合い判定用データベース、
Collaboration Controller…連携制御部。

Claims (10)

1. 複数のユーザ間のコミュニケーションを実現するユーザ連携システムであって、
   前記ユーザ各々のユーザ状況情報をリアルタイムで検出する検出部と、
   前記検出部で検出された前記ユーザ状況情報に基づき、前記ユーザ各々の従事業務の忙しさ度合いを判定する処理部と、
   前記従事業務に関するタスク定義と、前記従事業務の内容に応じて予め定めた忙しさ度合い判定用データベースを記憶する記憶部と、
   前記ユーザのキー入力を検出するキーストロークモニタとを有し、
   前記処理部は、
   前記ユーザの前記従事業務、あるいは前記忙しさ度合いを他の前記ユーザに通知することで、前記ユーザ間のコミュニケーションに関する情報を制御し、
   前記処理部は、
   記憶された前記タスク定義と、受信した前記ユーザ状況情報とに基づき、前記ユーザの前記従事業務を抽出するモデル解析部と、
   前記キーストロークモニタが出力するキーストローク情報を受信し、前記従事業務の詳細状況を解析するキーストローク解析部と、
   記憶された前記忙しさ度合い判定用データベースを用いて、抽出された前記従事業務の前記忙しさ度合いを評価する忙しさ度合い評価部を備え、
   前記忙しさ度合い評価部は、前記忙しさ度合い判定用データベースを用いて、抽出された前記従事業務から前記忙しさ度合いの大局分類情報を推定し、前記キーストローク解析部が解析した前記従事業務の詳細状況から前記忙しさ度合いの詳細分類情報を推定し、
   判定した前記忙しさ度合いに基づき、前記ユーザ間のコミュニケーションを実現する
   ユーザ連携システム。
2. 請求項１記載のユーザ連携システムであって、
   前記処理部は、選択された第一、第二の前記ユーザの忙しさ度合いが所定値より小さいタイミングを検出し、前記第一、第二のユーザに前記タイミングを通知する
   ユーザ連携システム。
3. 請求項２記載のユーザ連携システムであって、
   通知を受けた前記第一、第二のユーザは、通知された前記タイミングに基づき、通話を開始する
   ユーザ連携システム。
4. 請求項１記載のユーザ連携システムであって、
   前記処理部は、第一の前記ユーザの前記従事業務と関連性が高い第二の前記ユーザを検出し、前記第一のユーザに検出した前記第二のユーザを通知する
   ユーザ連携システム。
5. 請求項１記載のユーザ連携システムであって、
   前記検出部は、前記ユーザが装着する第一のセンサノードと、据え置き型の第二のセンサノードを含み、
   前記処理部は、前記第一、第二のセンサノードの出力から、前記ユーザの前記従事業務を推定する
   ユーザ連携システム。
6. 請求項１記載のユーザ連携システムであって、
   前記検出部は加速度データを出力する加速度センサを有し、
   前記処理部は、
   前記加速度センサの出力である前記加速度データを受信し、前記従事業務の詳細状況を解析する行動解析部を有し、
   前記忙しさ度合い評価部は、前記忙しさ度合い判定用データベースを用いて、抽出された前記従事業務から前記忙しさ度合いの前記大局分類情報を推定し、前記行動解析部が解析した前記従事業務の詳細状況から前記忙しさ度合いの前記詳細分類情報を推定する
   ユーザ連携システム。
7. 複数のユーザ間のコミュニケーションを実現するサーバ装置であって、
   検出部がリアルタイムで検出する前記ユーザ各々のユーザ状況情報と、前記ユーザのキー入力を検出するキーストロークモニタが出力するキーストローク情報を受信する通信部と、
   前記ユーザ状況情報に基づいて、前記ユーザ各々の従事業務の忙しさ度合いを判定する処理部と、
   前記従事業務に関するタスク定義と、前記従事業務の内容に応じて予め定めた忙しさ度合い判定用データベースを記憶する記憶部と、を有し、
   前記処理部は、
   前記ユーザの前記従事業務、あるいは前記忙しさ度合いを他の前記ユーザに通知することで、前記ユーザ間のコミュニケーションに関する情報を制御し、
   前記処理部は、
   記憶された前記タスク定義と、受信した前記ユーザ状況情報とに基づき、前記ユーザの前記従事業務を抽出するモデル解析部と、
   前記キーストローク情報を受信し、前記従事業務の詳細状況を解析するキーストローク解析部と、
   記憶された前記忙しさ度合い判定用データベースを用いて、抽出された前記従事業務の前記忙しさ度合いを評価する忙しさ度合い評価部を備え、
   前記忙しさ度合い評価部は、前記忙しさ度合い判定用データベースを用いて、抽出された前記従事業務から前記忙しさ度合いの大局分類情報を推定し、前記キーストローク解析部が解析した前記従事業務の詳細状況から前記忙しさ度合いの詳細分類情報を推定し、
   判定した前記忙しさ度合いに基づき、前記ユーザ間のコミュニケーションを実現する
   サーバ装置。
8. 請求項７記載のサーバ装置であって、
   前記処理部は、選択された第一、第二の前記ユーザの忙しさ度合いが所定値より小さいタイミングを検出し、前記第一、第二のユーザに前記タイミングを通知する
   サーバ装置。
9. 請求項７記載のサーバ装置であって、
   前記処理部は、第一の前記ユーザの前記従事業務と関連性が高い第二の前記ユーザを検出し、前記第一のユーザに前記第二のユーザを通知する
   サーバ装置。
10. 請求項７記載のサーバ装置であって、
    前記ユーザ各々の前記ユーザ状況情報は、加速度センサが出力する加速度データを含み、
    前記処理部は、
    前記加速度データを受信し、前記従事業務の詳細状況を解析する行動解析部を更に備え、
    前記忙しさ度合い評価部は、前記忙しさ度合い判定用データベースを用いて、抽出された前記従事業務から前記忙しさ度合いの前記大局分類情報を推定し、前記行動解析部が解析した前記従事業務の詳細状況から前記忙しさ度合いの前記詳細分類情報を推定する
    サーバ装置。

Images