最初に、センサ端末を有する人物がマルチサイト間を移動することを想定したシステム構成について、図1を用いて説明する。
図1は、マルチサイト間を移動する端末が存在した場合を示している。マルチサイトとは、物理的に離れたサイトが複数存在し、各サイトには基地局が設置してあり、人が各サイトを行き来する場合は一定時間以上を要するサイト構成を言う。
図1では、マルチサイトとしてAサイトとBサイトを示している。Aサイトは、各端末と無線又は有線で接続される基地局A1(GWA1)、各端末を充電する機能を有し端末が取得したデータを有線で基地局A1に送信するクレイドルからなる。Bサイトも同様に、基地局B1(GWB1)、クレイドルからなる。さらに、基地局A1と基地局B1はネットワークを介してデータベース(DB)に接続されている。
端末A1について、Aサイトが自オフィスであったとする。すなわち、通常は、端末A1は、Aサイトにある基地局A(GWA1)を経由して、データをデータベースに送信する。端末と基地局間のデータ通信は、無線・有線、どちらでも可である。また、リアルタイム通信でも、非リアルタイム通信でも、どちらでも可である。端末は定期的に自身のIDを含んだ赤外線を送信しており、別の端末がその赤外線を受信すると、端末同士が対面していたことが判定される。つまり端末を身につけたユーザ同士が対面すると、それを検出できる。
このように端末が取得したデータは、データベースに格納される。データベース(DB)には、各端末のIDと、端末が赤外線送受信機を用いてデータを取得した時刻を示すセンシング時刻(DBTM)と、その対面相手を示す対面データ(IR)と、データベースにデータを送信した基地局を示す基地局(GW)、基地局が端末からデータを受信した時刻を示すDB登録時刻(UPTM)、各端末が存在する場所を示すサイト(SITE)が格納される。
ここで、端末A1のユーザが、はじめAサイトにおり、端末A1を身につけたままBサイトへ移動する場合を考える。Bサイトにおいて端末A1が端末B1と対面しその対面が検出され、かつ、端末A1は基地局B1(GWB1)に捕捉されることがなかった、つまり基地局B1(GWB1)経由でデータ転送がされなかった、とする。このとき、端末A1がBサイトに存在していた位置情報は、直接的には端末A1のデータには含まれない。本実施例ではこのような状況下であっても、端末A1がBサイトにおいて端末B1と対面したことを検出する手段を提供する。つまり、データベースにおける端末A1のデータにおいて、基地局GWA1が格納されていたとしても、サイト(SITE)にAサイトではなくBサイトを格納する手段を提供する。なお、図1では、端末A1がAサイトに戻って基地局A1を介してデータ送信した例を示しているため、センシング時刻とDB登録時刻に開きがある。
その結果、図1に示す統合ネットワーク図(NWJO)を作成することが可能となる。ここでは、サイトAにおいて、端末A1とA2が、端末A1とA3が、端末A3とA4が、端末A4とA2が対面し、サイトBにおいて、端末A1とB1が、端末B1とA3が、端末B1とA4が対面していたとする。この場合、サイトAについて、および、サイトBについてのネットワーク図が作成される(NWA、NWB)。これは、一定時間以上対面していた人同士を線で結んだ図である。なお、このネットワーク図は、後述する対面時間に基づいてばねモデルなどの公知の手法を用いることができる。NWA、NWBについては、Aサイト、Bサイト内での人と人とのつながりのネットワーク図であるが、データベースに格納されるサイト情報を参照して、Aサイト、Bサイトを統合して作成されるネットワーク図は統合ネットワーク図(NWJO)となる。
Aサイトのネットワーク図は端末A1とA3が、Bサイトのネットワーク図は端末A1とB1、B1とA3がつながっている。サイトを統合したネットワーク図(NWJO)においては、端末A1とB1、B1とA3、A3とA1がそれぞれつながっていることが示されている。すなわち、サイトを統合したネットワーク図によって、人と人との総合的なつながりが取得できる。さらに、DBテーブルにおいて各IDが振られた端末の対面が発生した時刻にサイト情報が補完されているため、各端末同士のネットワークのつながりが、どのサイトで生じたかを示すことができる。
<全体の処理の流れの概要>
第1の実施の形態では、センサ端末(TR)を組織の各メンバが装着し、その端末(TR)によって各メンバ間の交流(インタラクション)や各メンバの活動状況に関するデータを取得する。取得したデータは無線または有線によって基地局(GW)に送信され、さらにセンサネットサーバ(SS)に格納される。そして、センサネットサーバは、デーベースの各端末におけるサイトを特定、補完する。組織コミュニケーションに関する表示を作成する際には、クライアント(CL)からアプリケーションサーバ(AS)に依頼を出し、組織に属するメンバに関するデータをセンサネットサーバ(SS)から取り出す。それをアプリケーションサーバ(AS)において、各メンバのコミュニケーションの量と多様性に基づいて処理・プロットし画像を作成する。さらにその画像をクライアント(CL)に戻し表示する。
<全体システム>
図2は、本発明の第1の実施の形態における、インタラクションおよびセンシングデータを取得する端末から、取得したデータを表示するアプリケーションまでを含むシステム全体の構成の説明図である。
ユーザは、クライアント(CL)を操作することによって、組織コミュニケーションに関する表示を受信する。クライアント(CL)は、ネットワーク(NW)を経由してアプリケーションサーバ(AS)に接続し、アプリケーションサーバで作成されたデータ処理結果情報(組織コミュニケーション表示)を受信し、ディスプレイ(CLWD)などに出力する。
アプリケーションサーバ(AS)はネットワーク(NW)を経由してセンサネットサーバ(SS)に接続し、データベース部(SSDB)に格納されているセンシングデータを受信する。受信した情報を処理・プロットすることによって、画像を作成する。
センサネットサーバ(SS)は、ネットワーク(NW)を経由して基地局(GW)に接続し、センシングデータを受信する。基地局(GW)は、ネットワーク(NW)を経由してセンサネットサーバ(SS)にセンシングデータを送信する。
基地局(GW)は、送信・受信部(GWSR)を経由して端末(TR)からセンシングデータを受信する。
端末(TR)は、人物に装着され、センシング部(TRSE)によってセンシングデータを取得する。基地局(GW)が通信可能なエリア内に、端末2(TR2)から端末4(TR4)が存在する。端末2(TR2)から端末4(TR4)のそれぞれは、各人物に装着され、端末(TR)と同様、センシング部(図示省略)によってセンシングデータを取得する。端末(TR)及び端末2(TR2)から端末4(TR4)は、取得したセンシングデータを、送信・受信部(TRSR)を用いて基地局(GW)に送信する。端末(TR)及び端末2(TR2)から端末4(TR4)によって送信されたセンシングデータには、そのデータを取得した端末(TR)及び端末2(TR2)から端末4(TR4)を識別する情報が含まれる。
<端末>
端末(TR)は小型端末であり、センシングの対象となる人物によって装着される。以下、端末(TR)の構成を説明する。図2には、さらに、端末2(TR2)から端末4(TR4)までの3個の端末が図示されている。これらの端末に関する説明は端末(TR)と同様であるため以降省略する。よって以下の説明は、端末(TR)を端末2(TR2)から端末4(TR4)までの任意のものに置き換えても成立する。なお、同様の端末が任意の数存在する場合にも、本実施例を適用することができる。
端末(TR)には赤外線送信器(TRIS)と赤外線受信器(TRIR)が搭載されている。これらを用い、端末(TR)間で赤外線を送受信することによって、その端末(TR)が他の端末(TR)と対面したか否かが検出される。このため、端末(TR)は、人物の正面部に装着されることが望ましい。例えば、端末(TR)を名札型にし、紐によって人物の首からぶら下げてもよい。端末(TR)が人物の正面部に装着された場合、端末(TR)が他の端末(TR)と対面したことは、それらの端末(TR)を装着した人物が対面したことを意味する。
なお、以下、端末(TR)が赤外線信号を送受信することによって、その端末(TR)が他の端末(TR)と対面したか否かを判別する例を記載する。しかし実際には、赤外線信号以外の無線信号をやり取りすることによって対面の有無が判別されてもよい。
また端末(TR)は、送信・受信部(TRSR)、センシング部(TRSE)、入出力部(TRIO)、制御部(TRCO)、記録部(TRME)によって構成されており、センシング部(TRSE)にてセンシングされたデータを送信・受信部(TRSR)を介して基地局(GW)に送信する。
送信・受信部(TRSR)は、基地局(GW)との間でデータを送信及び受信する。例えば、送信・受信部(TRSR)は、基地局(GW)から送られてきた制御コマンドに応じてセンシングデータを送信してもよいし、定期的にセンシングデータを送信してもよいし、センシングデータを取得した時に直ちにそのセンシングデータを送信してもよい。さらに、送信・受信部(TRSR)は、基地局(GW)から送られる制御コマンドを受信してもよい。受信した制御コマンドに従って、端末(TR)に関する制御情報の変更、又は、入出力部(TRIO)内の出力デバイスへの出力が実行される。また、送信・受信部(TRSR)は、入出力部(TRIO)内の入力デバイスによって選択された事項を、制御コマンドとして基地局(GW)へ送信する。
センシング部(TRSE)は、端末(TR)の状態を示す物理量をセンシングする。具体的には、センシング部(TRSE)は、種々の物理量をセンシングする一つ以上のセンサを備える。例えば、センシング部(TRSE)は、センシングに用いるセンサとして、赤外線送信器(TRIS)、赤外線受信器(TRIR)、温度センサ(TRTE)、マイクロホン(TRMI)、加速度センサ(TRAC)及び照度センサ(TRIL)を備える。
赤外線受信器(TRIR)は、他の端末(TR)の赤外線送信器(TRIS)から送信された赤外線信号をセンシングする。後述するように、センシングされた赤外線の情報は、端末(TR)が他の端末(TR)と対面したか否かを判定するために使用される。加速度センサ(TRAC)は、X、Y及びZ軸方向の加速度をセンシングする。後述するように、センシングされた加速度の情報は、端末(TR)を装着した人物の動作の激しさや行動(例えば、歩行又は静止等)を判断するために使用される。マイクロホン(TRMI)は、音声をセンシングする。センシングされた音声の情報は、例えば、端末(TR)を装着した人物が会話しているか否かを判別するために使用されてもよい。温度センサ(TRTE)及び照度センサ(TRIL)は、それぞれ、温度及び照度をセンシングする。センシングされた温度及び照度の情報は、例えば、端末(TR)が置かれている環境を判断するために使用されてもよい。
センシング部(TRSE)は、上記のセンサの任意の一つ以上を備えてもよいし、他の種類のセンサを備えてもよい。さらに、センシング部(TRSE)は、外部入力(TROU)を用いることによって、新たにセンサを追加することもできる。なお、既に説明したように、端末(TR)は、赤外線信号以外の無線信号を送受信することによって対面の有無を判別してもよい。その場合、センシング部(TRSE)は、赤外線センサ(TRIR)以外の無線信号受信機を備えてもよい。あるいは、外部入力(TROU)に赤外線センサ(TRIR)以外の無線信号受信機が接続されてもよい。
入出力部(TRIO)は、ボタン等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となる人物が所望する情報の取得及びセンシングデータの表示を行う。入出力部(TRIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
制御部(TRCO)は、CPU(図示省略)を備える。CPUが記録部(TRME)に格納されているプログラムを実行することによって、センサ情報の取得タイミング、センサ情報の解析、及び、基地局(GW)への送受信のタイミングが制御される。
記録部(TRME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部(TRME)は、データ形式(TRDFI)及び内部情報部(TRIN)を含む。データ形式(TRDFI)は、各センサから取得したデータ及び時刻情報を送信する際に、それらのデータをまとめる形式を指定する。内部情報部(TRIN)は、端末(TR)に関する情報を格納する。端末(TR)に関する情報は、例えば、バッテリ残量(TRBA)、時計(TRTI)(すなわち時刻情報)及び端末情報(TRTR)である。バッテリ残量(TRBA)には、端末(TR)の電源の残量が記録される。時計(TRTI)には、端末(TR)が内蔵するタイマで計測された現在の時刻が格納される。現在の時刻は、定期的に基地局(GW)から送信されたものに基づいて修正される。端末情報(TRTR)は、端末(TR)を識別するために使用される端末固有の情報であり、固有IDとも呼ばれる。
基地局(GW)の時刻を端末(TR)の時刻として定期的に修正することによって、複数の端末(TR)間で時刻が同期される。これによって、異なる端末から得られたデータを時刻に基づいて整列させ、照らし合わせることが可能になる。コミュニケーションは必ず複数のメンバによって行われるため、双方の視点からデータを分析するためには時刻を同期させることは必須となる。なお、時刻修正は基地局(GW)をトリガとするのではなく、センサネットサーバ(SS)がトリガとなって基地局(GW)を介して端末(TR)に時刻を送信してもよい。
<基地局>
基地局(GW)は、情報を取得したいエリアに設置され、そのエリア内にある端末(TR)から無線または有線によって送信されてくるセンシングデータを受信し、受信したセンシングデータをネットワーク(NW)を介してセンサネットサーバ(SS)へ送信する。基地局(GW)は、送信・受信部(GWSR)、制御部(GWCO)、入出力部(GWIO)、記録部(GWME)及び内部情報部(GWIN)を備える。
図2には、さらに、基地局2(GW2)から基地局3(GW3)までの2個の基地局が図示されている。これらの基地局に関する説明は基地局(GW)と同様であるため以降省略する。よって以下の説明は、基地局(GW)を基地局2(GW2)から基地局3(GW4)までの任意のものに置き換えても成立する。なお、同様の基地局が任意の数存在する場合にも、本実施例を適用することができる。いずれの基地局も、無線を使用した場合は、無線の到達可能圏内に存在する0から複数個の端末(TR)とコネクションを確立し、データのやり取りを行う。
送信・受信部(GWSR)は、端末(TR)との間でデータを送信及び受信する。また、ネットワークを介して接続されるセンサネットサーバに、端末から受信したセンシングデータを送信する。その送信において基地局IDを付与して送信する。また、例えば、送信・受信部(GWSR)は、端末(TR)に対して制御コマンドを送信してもよいし、定期的にセンシングデータを端末(TR)から受信してもよいし、端末(TR)がセンシングデータを送信したら直ちに端末(TR)からそのセンシングデータを受信してもよい。さらに、送信・受信部(GWSR)は、端末(TR)から送られてきた制御コマンドに従って、センサネットサーバ(SS)へ要求を送信し、その要求に応じてセンサネットサーバ(SS)から取得したデータを端末(TR)へ送信してもよい。また、送信・受信部(GWSR)は、入出力部(GWIO)における入力デバイスによって選択された事項を、制御コマンドとして端末(TR)やセンサネットサーバ(SS)に送信してもよい。逆に、送信・受信部(GWSR)は、センサネットサーバ(SS)又は端末(TR)から送られてきた制御コマンドを受信してもよい。受信した制御コマンドに従って出力デバイスの表示が変更される。
制御部(GWCO)は、CPU(図示省略)を備える。CPUが記録部(GWME)に格納されているプログラムを実行することによって、センサ情報の取得タイミング、センサ情報の解析、及び、端末(TR)又はセンサネットサーバ(SS)への送受信のタイミングが制御される。
入出力部(GWIO)は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部(GWIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
記録部(GWME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部(GWME)は、データ形式(GWDFI)及び内部情報部(GWIN)を含む。データ形式(GWDFI)は、端末(TR)から受信したデータ及び時刻情報の形式であり、この形式に基づいてデータが各要素に判別される。内部情報部(GWIN)は、基地局(GW)に関する情報を格納する。基地局(GW)に関する情報は、例えば、時計(GWTI)(すなわち時刻情報)、及び、基地局固有の情報である基地局情報(GWBA)、つまり基地局IDである。
<ネットワーク>
ネットワーク(NW)は、基地局(GW)、センサネットサーバ(SS)、アプリケーションサーバ(AS)及びクライアント(CL)を接続するネットワークである。ネットワーク(NW)は、Local Area Network(LAN)、Wide Area Network(WAN)又はその他の任意のネットワークであってよい。
<センサネットサーバ>
センサネットサーバ(SS)は、基地局(GW)から送られてくるセンシングデータを格納し、また、アプリケーションサーバ(AS)からの要求に基づいてセンシングデータを送信する。また、センサネットサーバ(SS)は、基地局(GW)からの制御コマンドを受信し、その制御コマンドによって得られた結果を基地局(GW)に送信する。センサネットサーバ(SS)は、データベース部(SSDB)、制御部(SSCO)、送信・受信部(SSSR)、入出力部(SSIO)、記録部(SSME)を備える。
データベース部(SSDB)は、端末(TR)から基地局(GW)を介して送られてきたセンシングデータを格納する。さらに、データベース部(SSDB)は、基地局(GW)からの制御コマンドに対する対処方法を格納する。データベース部(SSDB)は、後述する記録部(SSME)が備えるハードディスク(図示省略)等に格納されてもよい。
制御部(SSCO)は、CPU(図示省略)を備える。CPUが記録部(SSME)に格納されているプログラムを実行することによって、データベース部(SSDB)の管理、及び、アプリケーションサーバ(AS)及び基地局(GW)から送信される情報の処理を行う。より具体的には、基地局(GW)から受信したデータをデータベース部(SSDB)に格納する。
送信・受信部(SSSR)は、基地局(GW)及びアプリケーションサーバ(AS)へのデータの送信、及び、それらからのデータの受信を行う。具体的には、送信・受信部(SSSR)は、基地局(TR)から送られてきたセンシングデータを受信し、アプリケーションサーバ(AS)へセンシングデータを送信する。また、送信・受信部(SSSR)は、基地局(GW)から制御コマンドを受信した場合、データベース部(SSDB)から選択した結果を基地局(GW)に送信する。
入出力部(SSIO)は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部(SSIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
記録部(SSME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム及びセンシングデータを格納する。さらに、記録部(SSME)は、データ形式(SSDFI)を含む。データ形式(SSDFI)は、基地局(GW)から受信したデータ及び時刻情報の形式であり、この形式に基づいてデータが各要素に判別され、データベース部(SSDB)の適切な要素に振り分けられる。
<アプリケーションサーバ>
アプリケーションサーバ(AS)は、センサネットサーバ(SS)に格納されているセンシングデータの処理を行う計算機である。アプリケーションサーバ(AS)は、データ処理部(ASDP)、制御部(ASCO)、記録部(ASME)、送信・受信部(ASSR)、及び入出力部(ASIO)を備える。なお、アプリケーションサーバ(AS)は、クライアント(CL)が兼ねても、センサネットサーバ(SS)が兼ねてもよい。
データ処理部(ASDP)は、センシングデータを処理し、組織コミュニケーションを表現するための画像を作成する。データ処理部(ASDP)は、対面マトリクス計算(APIM)、対面人数・時間計算(APIC)、データプロット(APIP)を実行する。変形例として他の処理が追加される場合、それらの処理は、データ処理部(ASDP)によって実行される。データ処理部(ASDP)は、処理したデータを記録部(ASME)に一時的に格納する。データ処理部(ASDP)は、例えば、記録部(ASME)に格納されたプログラムを制御部(ASCO)のCPUが実行することによって実現されてもよい。その場合、対面マトリクス計算(APIM)、対面人数・時間計算(APIC)、データプロット(APIP)などのデータ処理部内の処理は、実際には、制御部(ASCO)のCPUによって実行される。
制御部(ASCO)は、CPU(図示省略)を備える。CPUが記録部(ASME)に格納されているプログラムを実行し、センサネットサーバ(SS)へのデータ取得依頼、データ処理の実行、及び、実行結果の管理等の処理を行う。
記録部(ASME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、プログラム、センシングデータ、及び、データ処理部(ASDP)による処理結果を格納する。さらに、記録部(ASME)は、初期条件設定(ASSII)及び結合テーブル(ASCNT)等、処理のために一時的に保管すべき値を記録する。これらの値は、データの種類及び処理の種類に応じて随時追加・削除・変更することができる。また、ノードを装着しているユーザとノードの固有IDとの対応を示すユーザID対応表(ASUIT)や、プロジェクトとそれに属するユーザ(メンバ)との対応を示すプロジェクト対応表(ASPUT)を記録しておく。ユーザID対応表(ASUIT)やプロジェクト対応表(ASPUT)はセンサネットサーバ(SS)内の記録部(SSME)やクライアント(CL)内の記録部(CLME)に記録してもよい。また、対面マトリクス(ASTMX)は、対面マトリクス計算(APIM)によって作成される配列である。ユーザID対応表(ASUIT)の例は図8に、プロジェクト対応表(ASPUT)の例は図9に、対面マトリクス(ASTMX)の例は図14(a)にそれぞれ示している。なお、ユーザID対応表(ASUIT)やプロジェクト対応表(ASPUT)はプログラム内に直接記述しても良いが、対応表のみを分けて保管することで、ユーザの変更、ノードIDの変更、プロジェクトの組織構成の変更などに柔軟に対応することができる。
送信・受信部(ASSR)は、センサネットサーバ(SS)からセンシングデータを受信し、クライアント(CL)からの処理結果要求に基づくデータ送信を行う。入出力部(ASIO)は、ボタン又はキーボード等の入力デバイスと、液晶ディスプレイ等の出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示することができる。入出力部(ASIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。
<クライアント>
クライアント(CL)は、ユーザからの依頼に基づいてデータ処理要求をアプリケーションサーバ(AS)に送信し、その処理結果をアプリケーションサーバ(AS)から受信し、受信した処理結果を画面に表示する。クライアント(CL)は、送信・受信部(CLSR)、入出力部(CLIO)、記録部(CLME)及び制御部(CLCO)を備える。
制御部(CLCO)は、記録部(CLME)に格納されているプログラムを実行するCPU(図示省略)を備える。制御部(CLCO)は、ユーザからの要求に基づいて、アプリケーションサーバ(AS)から受信した画像の大きさなどを調整し、作成された画面を入出力部(CLIO)のディスプレイ(CLWD)などの出力デバイスに表示することによってユーザに提供する。
送信・受信部(CLSR)は、ユーザが指定した範囲のセンシングデータの処理結果を送信させる要求をアプリケーションサーバ(AS)に対して送信し、その処理結果(すなわち、アプリケーションサーバ(AS)によって処理された画像またはセンシングデータ)を受信する。
入出力部(CLIO)は、マウス(CLIM)やキーボード(CLIK)などの入力デバイスと、ディスプレイ(CLWD)などの出力デバイスとを備え、対象となるエリア内の状況等の情報及びセンシングデータを表示する。入出力部(CLIO)として、入力デバイスと出力デバイスを統合したものであるタッチパネルが用いられてもよい。またそれ以外の入出力装置を接続するために外部入出力(CLOU)が用いられてもよい。
記録部(CLME)は、ハードディスク、メモリ又はSDカード等の外部記録装置を備え、メインプログラム、センシングデータ、及び、アプリケーションサーバから送られてきた画像や制御部(CLCO)による処理結果を格納する。また、記録部(CLME)は、初期条件設定(CLISI)に、画面の大きさなどユーザによって設定された条件を記録する。
<全体シーケンス図>
図3は、第1の実施の形態において、センシングデータが端末(TR)からデータベース部(SSDB)に格納されるまでの処理を示すシーケンス図である。
端末(TR)で取得されたセンシングデータは、定期的に基地局(GW)を介してセンサネットサーバ(SS)に届けられ、データベース(SSDB)に保管される。この流れが、図3のセンシングデータの取得(TRGE)からデータ格納(SSPU)までにあたる。また、時刻修正(GWTM)〜時刻修正(TRTM)は、センシングデータの取得の流れとは別の周期で実行される。
センシングデータの取得(TRGE)については、サンプリング周期、取得時間などセンシングデータを取得するために必要な情報が記録部(TRME)に記載されており、この情報を基にして端末(TR)内のセンシング部(TRSE)がセンシングを行う。また、端末(TR)は一定の周期で端末(TR)自身を識別する情報を載せた赤外線を送信し続ける(TRIS)。端末(TR)が別の端末2(TR2)と対面した場合には、つまり端末(TR)と端末2(TR2)のユーザ同士が対面した場合には、端末(TR)は、端末2が送信した赤外線(TRIS2)を受信する(TRIR)。また対称的に、端末(TR)が送信した赤外線は、端末2(TR2)で受信される(TRIR2)。端末同士の角度など、条件によっては一方しか受信されない場合もありうる。さらに、端末(TR)は、センシングされたデータを記録部(TRME)に記録する。
時刻添付(TRAD)において、端末(TR)は、センシングしたデータの取得時刻として、時計(TRTI)の時刻をセンシングデータと共に記録する。データ形式(TRDF)において、端末(TR)は、記録部(TRME)内のデータ形式(TRDFI)を参照し送信用データ形式にデータを統一する。
データ送信(TRSE)において、端末(TR)は、センシングデータの取得(TRGE)によってセンシングしたセンシングデータを、送信・受信部(TRSR)を経由し基地局(GW)に送信する。より詳細には、端末(TR)は、記録部(TRME)に記録されているセンシングデータを記録部(TRME)に格納されている基地局(TR)用の送信フォーマットを用いて制御部(TRCO)によって変換する。そして、端末(TR)は、送信フォーマットに変換されたセンシングデータを送信・受信部(TRSR)を経由して基地局(GW)に送信する。
データ受信(GWRE)において、基地局(GW)は、端末(TR)から基地局(GW)用の送信フォーマットで送信・受信部(TRSR)から送信されたセンシングデータを送信・受信部(GWSR)によって受信する。受信したセンシングデータは記録部(GWME)に格納される。
データ形式判断(GWDF)において、基地局(GW)は、取得したデータの形式を記録部(GWME)のデータ形式(GWDFI)と比較してデータの形式を判断する。さらに、基地局(GW)は、基地局情報付与(GWAD)において、データ形式(GWDFI)が示す適切な位置に基地局情報(GWBA)を追加する。
データ送信(GWSE)において、基地局(GW)は、記録部(GWME)に格納されたセンシングデータを、送信・受信部(GWSR)を経由してセンサネットサーバ(SS)に送信する。より詳細には、基地局(GW)の制御部(GWCO)は、記録部(GWME)に記録されているセンシングデータを記録部(GWME)に格納されているセンサネットサーバ(SS)用の送信フォーマットに変換する。そして、基地局(GW)は、送信フォーマットに変換されたセンシングデータを送信・受信部(GWSR)を経由してセンサネットサーバ(SS)に送信する。
データ受信(SSRE)において、センサネットサーバ(SS)の送信・受信部(SSSR)は、基地局(GW)の送信・受信部(GWSR)からセンサネットサーバ(SS)用の送信フォーマットで送信されたセンシングデータを受信する。受信したセンシングデータは記録部(SSME)に格納される。
データ形式判断(SSDF)において、センサネットサーバ(SS)は、取得したデータの形式を記録部(SSME)のデータ形式(SSDFI)と比較することによって、データの形式を判断する。さらに、データ分類(SSDE)において、センサネットサーバ(SS)は、各データを要素ごとに切り分ける。
データ格納(SSPU)において、センサネットサーバ(SS)の制御部(SSCO)は、センシングデータをデータベース部(SSDB)のフォーマットに変換する。変換されたセンシングデータは、データベース部(SSDB)に格納される。データベース部(SSDB)への格納方法は、後で検索する際に有効なクエリとして用いることができるようにすることが好ましい。有効なクエリとしては、例えば、センシングデータ名、時刻、端末固有ID及び基地局固有IDがある。
データ補完(SSSU)において、センサネットサーバ(SS)の制御部(SSCO)は、センシングデータにおけるサイト情報を補完する。これは、図1において、端末A1であるセンシングデータのセンシング時刻での対面データと基地局とDB登録時間に基づき補完する処理である。
図4を用いて、データ補完(SSSU)処理を説明する。図4では、端末1と端末2が対面し、端末1のサイトを特定する場合の処理を説明する。本処理は、全ての端末の全てのデータについて行われる。端末1のデータベース内のセンシング時刻とDB登録時刻を比較して、所定時間内(例えば数十秒)である場合には、その基地局固有のIDと対応するサイトを特定して処理を終了する。端末2と対面後、対面がなされたサイトにある基地局を介してデータが送信されたと考えられるからである。所定時間内でない場合には、対面がなされたサイトにある基地局を介してデータが送信されなかったと判断し、端末2のデータに端末1との対面検出データがあるか否かを検索する。
対面検出データがあった場合には、端末2のセンシング時刻と端末1のセンシング時刻が一定時間内であるか否か判定する。一定時間内である場合には、端末2のデータにおいてサイトが特定されているか判定しサイトが特定されている場合には、そのサイト情報を端末1のサイトとして特定する。サイトが特定されていない場合には、処理を終了する。
端末1と端末2のセンシング時刻が一定時間内でない場合、端末2のデータで、他に端末1との対面検出データがあるか否かを検索する。ある場合には、それらのセンシング時刻が一定以内か否かを判定する。他に対面検出データがない場合には、処理を終了する。
図1の例を用いて説明すると、端末A1のセンシングデータはサイトAに存在する基地局GWA1を通じて取得されている。基地局IDに基づけば、端末A1は端末B1とサイトAにて対面していると判断されるが、所定時間内でないため対面相手である端末B1のデータを検索する。端末B1のデータには端末A1との対面検出データがあり、それらのセンシング時刻が一定時間である(図1では同時刻)。これより、端末A1は、端末B1と対面したとき、サイトBにいたと判定可能であり、この時刻の端末A1のサイト情報としてBサイトを補完できる。以上のようなセンシングデータの取得(TRGE)からデータ補完(SSSU)までの一連の処理は定期的に行なわれる。
図3に示す時刻修正(GWTM)は、基地局(GW)の時計(GWTA)の時刻を合わせるために行われる。基地局(GW)は、現在の時刻をネットワーク(NW)網にあるNTPサーバ(図示省略)から取得する。時刻修正(GWTM)の処理は定期的に行なわれる。
時刻修正依頼(GWTR)は、端末(TR)の時刻を合わせるために、基地局(GW)から端末(TR)へ依頼される。時刻修正(TRTM)は、時刻修正依頼(GWTR)によって基地局(GW)から送信された時刻に基づいて、時計(TRTI)の時刻を修正する処理である。時刻修正依頼(GWTR)から時刻修正(TRTM)までの処理は定期的に行なわれる。
次に、端末(TR)のセンシング部(TRSE)におけるセンシングの間隔と、送信・受信部(TRSR)における送信のタイミングについて、本実施形態の例の一つを挙げて述べる。端末(TR)は、三軸加速度センサ及び赤外線送受信器を備え、これらが全て10秒サイクルでセンシング及びデータ送信を行う。
加速度センサは、10秒中の始めの2秒間でX、Y、Z軸方向各100回のセンシングを行う。センシングの結果として取得された加速度情報は、端末(TR)の状態を示す。端末(TR)が人物に装着されている場合、取得された加速度情報は、端末(TR)を装着した人物の活動の状態(例えば、その人物が静止しているか否か)を示す。
赤外線送信器は、10秒間あたり6回ずつ端末(TR)の正面に向かって赤外線信号を送信する。送信される赤外線信号には、端末情報(TRTR)、すなわち、自端末(TR)のID(識別子)を示す信号が含まれる。二つの端末(TR)が向かい合ったとき、つまり二人の人物が対面したときには、一方の端末(TR)の受信器が、もう一方の端末(TR)のIDを受信する。すなわち、一つの端末(TR)が他の端末(TR)のIDを受信したとき、それらの二つの端末が対面していることを意味する。つまり、それぞれの端末(TR)が人物の前面に装着されている場合、二つの端末(TR)が対面していることは、それらを装着した二人の人物が対面していることを意味する。赤外線の受信器側は、常に待機状態となっており、10秒間のうちに受信したIDと、受信した回数を記録する。
そして、端末(TR)は、これらのセンシングデータにタイムスタンプ及び端末情報(TRTR)つまり自身の固有IDを付与した後、それらのセンシングデータを基地局(GW)に一括して無線送信する。上記の例において、端末(TR)から送信されるセンシングデータには、その端末の加速度を示す情報と、その端末の固有IDと、その端末が他の端末と対面したことを示す情報と、それらの情報に対応付けられた時刻情報とが含まれる。これらのセンシングデータが、人物の交流を示すインタラクションデータとして利用される。なお、これらは一例に過ぎず、センシング間隔及び送信タイミングは、任意に設定することができる。
図5は、本発明の第1の実施の形態において、アプリケーションの立ち上げから表示画面がユーザ(US)に提供されるまでの大まかな処理の流れを示すフローチャートである。
表示画面を作成するために、開始(APST)から、初期条件設定(CLIS)、データ取得(APDG)、対面マトリクス作成(APIM)、対面人数・対面時間のカウント(APIC)、データプロット(APIP)、画面表示(CLWO)の各手順が順次実行され、終了(APEN)となる。
図6は、第1の実施の形態において、ユーザがデータベース部(SSDB)のデータを使用するまでの処理を示すシーケンス図である。
アプリケーション起動(USST)は、ユーザによるクライアント(CL)のアプリケーションの起動である。初期条件設定(CLIS)において、クライアント(CL)は、図の提示に必要な情報を設定する。ユーザのボタン選択によって、表示の対象となるデータの時刻及び端末情報、表示方法の条件設定などを取得する。ここで設定した条件は、記録部(CLME)に格納される。
データ依頼(CLSQ)において、クライアント(CL)は、初期条件設定(CLIS)に基づき、アプリケーションサーバ(AS)に対して、データもしくは画像の依頼を行う。記録部(CLME)には、検索対象のアプリケーションサーバ(AS)の名称、アドレス等、センシングデータを取得するために必要な情報が格納されている。クライアント(CL)は、データの依頼コマンドを作成し、アプリケーションサーバ(AS)用の送信フォーマットに変換される。送信フォーマットに変換されたコマンドは、送信・受信部(CLSR)を経由して、アプリケーションサーバ(AS)に送信される。
アプリーションサーバ(AS)は、データ依頼(ASRQ)において、クライアント(CL)からの依頼を受信し、さらにセンサネットサーバ(SS)に対して取得すべきデータの時刻の範囲及びデータ取得対象である端末の固有IDを送信しセンシングデータを要求する。送信される時刻及び端末の固有IDは、アプリーションサーバ(AS)の記録部(ASME)又はクライアント(CL)の記録部(CLME)に格納されたものから自動的に設定されるものであってもよいし、クライアント(CL)の入出力部(CLIO)を通してユーザが指定したものであってもよい。
データ検索(ASSE)において、アプリーションサーバ(AS)は、データ依頼(ASRQ)に基づき、センサネットサーバ(SS)に対して、検索を行う。記録部(ASME)には、検索対象のセンサネットサーバ(SS)の名称、アドレス、データベース名及びテーブル名等、データ信号を取得するために必要な情報が記載されている。アプリーションサーバ(AS)は、データ検索(ASSE)を行う際、データ依頼(ASRQ)を通して検索内容を依頼し、データベースの情報を記録部(ASME)から取得し、検索に用いるコマンドを作成する。作成されたコマンドは、制御部(ASCO)によって、記録部(ASME)に格納されているセンサネットサーバ(SS)用の送信フォーマットに変換される。送信フォーマットに変換されたコマンドは、送信・受信部(ASSR)を経由してセンサネットサーバ(SS)に送信される。
センサネットサーバ(SS)内データベース(SSDB)は、受け取ったコマンドを実行してクエリし、アプリケーションサーバ(AS)にデータを送信する。
データ受信(ASRE)において、アプリーションサーバ(AS)は、データ検索(ASSE)のコマンドに基づいて、センサネットサーバ(SS)内のデータベース部(SSDB)から送信されたセンシングデータを受信する。送信・受信部(ASSR)が受信したセンシングデータは記録部(ASME)に格納される。データ分類(ASDE)において、アプリーションサーバ(AS)は、取得したデータを適切な各要素に分類する。その際、時刻情報とセンシングデータは必ず関連付けたままで分類される。
ここまでの、データ依頼(CLSQ)からデータ分類(ASDE)までの流れが、図5のフローチャートにおけるデータ取得(APDG)に相当する。
次に、対面マトリクス作成(APIS)、対面人数・対面時間のカウント(APIC)、データプロット(APIP)のそれぞれの処理を順に行う。処理の詳細な内容は図7以降のフローチャートにて示す。これらの処理を行うプログラムは、記録部(ASME)に格納されており、データ処理部(ASDP)によって実行し、画像が作成される。画像は、画像送信(APWS)においてクライアントに送信され、クライアントの出力デバイス、例えばディスプレイ(CLWD)に表示される(CLWO)。最後のアプリケーション終了(USEN)はユーザによるアプリケーションの終了である。
<初期条件設定のフローチャート>
初期条件設定(CLIS)の中での手順を図7のフローチャートに示す。初期条件設定(CLIS)は、開始(ISST)から、ユーザID対応表読み込み(ISUI)、プロジェクト対応表読み込み(ISPU)、表示期間の設定(ISRT)、プロットするメンバの設定(ISRM)、役職の区別を設定(ISSM)、特定プロジェクトの強調の有無を設定(ISPO)の手順を行う。また、特定プロジェクトを強調する(ISPY)場合には強調するプロジェクトを設定(ISPS)して終了する(ISEN)。
ユーザID対応表読み込み(ISUI)では、例として図8のような、ノードの固有ID(ASUIT3)とそれを装着しているユーザ名(ASUIT2)とを一対一で対応づけているユーザID対応表(ASUIT)を読み込む。ユーザには今後処理するときに用いるユーザ番号(ASUIT1)を振っておく。必要があれば、役職(ASUIT4)を示す列も用意する。図8の例の場合では、部長を2、課長を1、一般社員を0として数値化して表現している。役職の区別の仕方は自由に設定して良い。組織のメンバや職位などに変更があった場合には、ユーザID対応表(ASUIT)のみを書き換えれば対応できる。
プロジェクト対応表読み込み(ISPU)では、例として図9のような、組織内に存在するプロジェクトの名前と、それに属するメンバとを対応付けるためのプロジェクト対応表(ASPUT)を読み込む。なお、部や課という組織全体に対するグループやユニットなどの固定した組織、またプロジェクトなどの柔軟に変化する組織など、全ての下位組織を指して以降ではプロジェクトと統一して呼ぶものとする。
プロジェクト対応表(ASPUT)は、誰がどのプロジェクトに属しているか、が明確であれば良いのでユーザID対応表(ASUIT)に一体化して、各一行で表されているユーザに対して属するプロジェクト名を書く列が存在するという形式でも良い。また、プロジェクトによって表示を区分する必要がなければプロジェクト対応表(ASPUT)は必要ない。図9のプロジェクト対応表(ASPUT)では、一人のメンバが複数のプロジェクトに掛け持ちして属することにも対応しているが、必ずしも対応していなくてもよい。
プロジェクト対応表(ASPUT)には、プロジェクト名(ASPUT2)と所属ユーザ番号(ASPUT3)の項目がある。また各プロジェクトには、今後処理するときに用いるプロジェクト番号(ASPUT1)を振っておく。所属ユーザ番号(ASPUT3)の項目の数字は、ユーザID対応表(ASUIT)におけるユーザ番号(ASUIT1)に対応している。プロジェクト対応表(ASPUT)をプログラム本体とは別に用意することで、プロジェクトのメンバ構成に変更があった場合には、このプロジェクト対応表(ASPUT)のみを書き換えることで容易に対応できる。プログラム本体に、直接記述しても良い。
表示期間の設定(ISRT)、プロットするメンバの設定(ISRM)、役職の区別を設定(ISSM)、特定プロジェクトの強調の有無を設定(ISPO)では、例えば図10のような初期条件設定ウィンドウ(ASISWD)をクライアント(CL)のディスプレイ(CLWD)などの出力装置に表示し、マウス(CLIM)やキーボード(CLIK)などの入力装置を用いてユーザ(US)に入力させることで、各々の設定を行う。初期条件設定ウィンドウ(ASISWD)は、始めからクライアント(CL)内に保管しておいても良い。
表示期間の設定(ISRT)は、ウィンドウの表示期間選択(ASISPT)のテキストボックス(PT01〜03、PT11〜13)にて日付を設定し、端末(TR)で取得された時刻がこの範囲内にあるデータを、表示のための計算に用いるものとする。必要があれば時刻の範囲設定を追加しても良い。
プロットするメンバの設定(ISRM)は、ウィンドウの表示メンバ選択(ASISPM)において行う。ウィンドウには、ユーザID対応表読み込み(ISUI)で読み込んだ全ユーザ名、また必要ならばノードIDを反映させる。ユーザ(US)はチェックボックス(PM01〜PM09)にチェックを入れる、もしくは入れないことでどのメンバのデータを表示するかを設定する。直接個々のメンバを指定するのではなく、既定のグループ単位、年齢などの条件によって表示メンバをまとめて指定させても良い。
役職の区別を設定(ISSM)、特定プロジェクトの強調の有無を設定(ISPO)は、ウィンドウの表示設定(ASISPD)において行う。役割の区別のチェックボックス(PD1)にチェックを入れた場合には、表示において役職によって四角や丸などの異なる記号でプロットされる。役職によるコミュニケーションの行い方の違いを検証したい場合に用いる。特定プロジェクトの強調のチェックボックス(PD2、PD21〜PD25)にチェックを入れた場合には、表示において特定のプロジェクトに属するメンバに対応する記号が、塗りつぶすなどして他の記号よりも強調して表示される。プロジェクトごとに、どのようなコミュニケーションの行い方をしているのかを検証したい場合に用いる。さらに、チェックボックス(PD2)にチェックが入れられた場合には、図7のフローチャートにおいて特定プロジェクトを強調する(ISPY)がyesとなり、強調するプロジェクトの設定(ISPS)を行う。強調するプロジェクトの設定(ISPS)は、プロジェクト対応表(ASPUT)から読み込んだ各プロジェクト名を反映したチェックボックス(PD21〜PD25)にユーザがチェックを入れることで設定される。チェックの数は1つに限定しても良いし、複数であっても良い。
表示サイズ(ASISPS)領域では、表示される画像のサイズが設定される。本実施の形態では、画面に表示される画像が長方形であることを前提とする。画像の縦の長さがテキストボックス(PS01)に、横の長さがテキストボックス(PS02)に入力される。入力される数値の単位として、ピクセル又はセンチメートル等、何らかの長さの単位が指定される。
全てを入力したら最後に、表示開始ボタン(ASISST)をユーザ(US)が押すことで以上の初期条件を決定とし、図5におけるデータ取得(APDG)のステップに進む。
<データ取得〜対面マトリクスのフローチャート>
図11は、本発明の第1の実施の形態において、図5のデータ取得(APDG)と対面マトリクス作成(APIM)のステップの詳細を示したフローチャートである。開始(DGST)からデータ取得(APDG)と対面マトリクス作成(APIM)を行い、終了(DGEN)する。データ取得(APDG)は、クライアントからのデータ依頼(CLSQ)を受けたアプリケーションサーバがセンサネットサーバにセンシングデータを要求し、センサネットサーバ(SS)内のデータベース部(SSDB)の中から必要なデータを取得するプロセスである。
データベース部(SSDB)には複数のメンバの複数種類のセンシングデータが記録されているが、そのうちの赤外線送受信による対面データをまとめたテーブルの例を図12(a)(b)に示す。図12(a)は、対面テーブル(SSDB_1002)であり、ノードIDが1002である端末(TR)から取得されたデータを集めたテーブルであることを想定している。同様に、図12(b)は、対面テーブル(SSDB_1003)であり、ノードIDが1003である端末(TR)から取得されたデータを集めたテーブルとする。なお、取得したノードごとにテーブルを分けなくても良く、他の加速度や温度などのデータも同じテーブルに含んでも良い。
対面テーブルには端末(TR)からデータを送信した時刻(DBTM)、赤外線送信側ID(DBR1)と受信回数(DBN1)を10組(DBR1〜DBR10、DBN1〜DBN10)分格納できる。本実施例は10秒間に1回データ送信を行うようにしているため、前回の送信からの10秒間のうちにどの端末(TR)から何回赤外線を受信したかを表しているものである。10秒間中に複数の端末(TR)と対面した場合にも、10組まで格納できるということである。なお、組の数は自由に設定することができる。対面、つまり赤外線の受信がなかった場合にはnullとなる。また、図12では時刻はミリ秒まで表記している。時刻の形式は統一されていればどのようなものでも良い。
図11のデータ取得(APDG)では、まずセンサネットサーバ(SS)のデータベース部(SSDB)に接続(DGCD)し、前述の初期条件設定(CLIS)で設定した表示期間(ASISPT)と表示メンバ(ASISPM)の条件に基づきSQLコマンドを作成し、データベース(SSDB)から、その時刻(DBTM)が設定した表示期間に含まれているデータを表示すべき全メンバの対面テーブルから取得する(DGSG)。
対面マトリクスの作成(APIM)では、表示すべきメンバから一組(二人)を選択し(IMMS)、その二人のデータの時刻を揃えて結合テーブルを作成する(IMAD)。図12(a)の1002番の端末(TR)のデータと、図12(b)の1003番の端末(TR)データから作成した結合テーブルの例が図13の結合テーブル(ASCNT1002‐1003)である。結合テーブルの作成(IMAD)の際には、それぞれの対面テーブルの時刻(DBTM)を揃え、結合テーブルの時刻(CNTTM)とする。また、図12(b)の一行目(RE01)と二行目(RE02)の間のように、データがセンシング周期(ここでは10秒間隔)で入っていない場合には、補完する。また、二つの対面テーブルの時刻が完全に一致していない場合には、どちらかに合わせるか、完全に10秒刻みになる時刻を設定し、それに近いデータをそれぞれ同時刻として扱うなどして、同じ時刻とみなせる行同士を見比べる。その中で、設定した二つの端末(TR)間での対面データが少なくとも一方の対面テーブルに存在した場合には、その時刻に二人のメンバが対面したとみなし、結合テーブルの対面の有無(CNTIO)の欄を1とする。そうでないときは0とする。このようにして結合テーブルを作成する。さらに、全ての時刻の対面があった回数を合計する。
対面したと判別するための基準は、赤外線受信回数が閾値以上であった場合のみとする、など別の基準を用いても良い。また、結合テーブルは合計対面回数(REsum)が計算できれば良いので、テーブルを作成せず、時刻をそろえながら対面回数をカウントしても良い。
次に、求めた合計対面回数の値を10倍し、対面マトリクス(ASTMX)の選択した二人のメンバを示す二箇所の要素に入れる(IMCI)。10倍するのは、合計対面回数1に対して10秒間対面したとみなし、対面マトリクスの値の単位を秒にそろえる目的である。必要がなければそろえなくても良い。
図14(a)に対面マトリクス(ASTMX)の例を示す。行と列はそれぞれユーザID対応表(ASUIT)におけるユーザ番号(ASUIT1)に対応している。今の場合ではノードIDが1002番のユーザ番号は2、ノードIDが1003番のユーザ番号は3となるため、要素(TMX2_3)に値を入れる。また、対面に関しては一方が対面したならもう一方も対面したと考えるのが自然であるため、対面マトリクス(ASTMX)が対称行列となるように対称要素(TMX3_2)にも同じ値を入れる。しかし、意図がある場合には非対称行列とすることも可能である。一組のメンバについて対面マトリクス(ASTMX)の要素を埋めたら、別の一組を選択し、全ての組の処理を完了するまで繰り返す(IMAM)。
さらに、本実施例で特徴となる対面マトリクスの例を図15に示す。図14(a)と同様に、行と列はそれぞれユーザID対応表におけるユーザ番号に対応している。図14(a)の対面マトリクスにおいては、i行目、j列目の要素には、i行目のユーザIDを持つ端末が、j列目のユーザIDを持つ端末と何秒対面したかというデータが入っていた。
一方、図15の例の場合では、その対面時間を、その対面が行なわれたサイトごとに区分する。このサイトは、上述した方法で特定すればよい。これによって、ユーザi、jの対面は、単にその対面時間のみならず、どのサイトでの対面であったかというサイト情報を含めることができる。
<対面時間・人数のカウント>
図16は、本発明の第1の実施の形態において、図5の対面人数・対面時間のカウント(APIC)のステップの詳細を示したフローチャートである。開始(ICST)から終了(ICEN)までのステップでは、メンバごとに対面時間の合計と対面人数のカウントを行う。
まずメンバを一人選択し(ICMS)、対面マトリクス(ASTMX)においてそのメンバのユーザ番号(ASUIT1)に対応する行を決める。次にその一行の対面マトリクスの値を合計する。合計したものが、図14(b)の対面カウント(ASTMC)の対面時間(TMTI)となる(ICTI)。対面時間(TMTI)はつまり、そのメンバが設定した表示期間(ASISPT)内で何らかの人物とコミュニケーションを行った合計時間であり、コミュニケーションの量だとみなせる。またさらに、その一行の対面マトリクス(ASTMX)の、要素が正の値、つまり0より大きい値である要素の数をカウントし、それを図14(b)の対面カウント(ASTMC)の対面人数(TMNM)とする(ICNM)。対面人数は、表示期間(ASISPT)内において関わりを持った他者の数であり、そのメンバの持つ関係の多様性と捉えることができる。なお、図14(b)の対面カウント(ASTMC)は、対面人数(TMNM)と対面時間(TMTI)を合わせたテーブルとしている、各メンバに対応する対面人数と対面時間の値が明確になっていれば、テーブル以外の形式でも良い。
以上の対面時間の合計(ICTI)と対面人数のカウント(TCNM)の手順を、全てのメンバについて終了するまで繰り返す(ICAM)。
<データプロットのフローチャート>
図17は、本発明の第1の実施の形態において、図5のデータプロット(APIP)のステップの詳細を示したフローチャートである。データプロット(APIP)では、カウントした対面人数(TMNM)と対面時間(TMTI)をそれぞれ横軸・縦軸に取った座標上に各メンバをプロットする。このとき、初期条件設定(APIS)で設定した事項に基づき、メンバごとにプロットする記号の形や塗りつぶしの有無などを決定する。
データプロットの開始(IPST)後、まずグラフ領域の大きさを決める(IP10)。グラフ領域の大きさは表示画面のうちのグラフが占める領域の大きさであり、初期条件設定ウィンドウ(ASISWD)で設定した表示サイズ(ASISPS)から、縦横それぞれタイトルや軸の値、余白の部分を引いた値となるように計算する。
次に、横軸と縦軸それぞれの最大値を決定する(IP20)。ここではプロットすべき全データ、つまり図14(b)の対面カウント(ASTMC)の対面人数(TMNM)、対面時間(TMTI)のそれぞれの最大値を参考にし、最大値以上のきりのいい数字となるように軸の値を設定する。他に比べて突出した大きな値がある場合には対面カウント(ASTMC)の最大値より小さな値を軸の最大値としてもよい。また、各軸は等差数列となるように目盛を区切った通常の軸(等差目盛)を想定しているが、対面人数(TMNM)または対面時間(TMTI)の分布によってはどちらか、もしくは両方を対数軸(対数目盛)としても良い。次に、メンバを一人選択し、そのユーザ番号(ASUIT1)に対応した対面カウント(ASTMC)の対面人数(TMNM)・対面時間(TMTI)のデータから、先ほど決定した目盛を基準とし、プロットする座標を決定する(IP40)。
さらに、初期条件設定(CLIS)の表示設定(ASISPD)において役職の区別チェックボックス(PD1)がONであった場合には(IP50)、そのメンバの役職(ASUIT4)をユーザID対応表(ASUIT)から引き出し、役職に対応する記号を選択する(IP51)。記号とはプロットする際に役職を区別するためのものであり、例えば部長は四角、課長は三角、一般社員は丸などとしてあらかじめ設定しておく。役職の区別を行わない場合には、デフォルトとして設定してある記号を用いる(IP55)。役職の区別をするためには、プロットする記号を変える以外の方法を用いても良い。
また、初期条件設定(CLIS)の表示設定(ASISPD)において特定プロジェクトの強調チェックボックス(PD2)がONであった場合には(IP60)、プロジェクト対応表(ASPUT)を参照し(IP61)、強調すべきとして設定されているプロジェクトにそのメンバが属している場合には(IP70)、計算した座標上に記号を塗りつぶしてプロットする(IP71)。メンバが該当プロジェクトに属していない場合には記号を塗りつぶさずに座標上にプロットする(IP75)。なお、塗りつぶすのは該当プロジェクトに属しているメンバのみを強調させるためであるので、他の方法を用いて強調しても良い。また、必要であればプロットした記号に隣接するように、そのメンバの氏名を表示させることも可能である。全メンバに関してプロットが完了するまでIP30〜IP71の手順を繰り返す(IP80)。
また最後に、特定プロジェクトの強調チェックボックス(PD2)がONになっている場合には(IP90)、プロジェクトに属する全メンバ、つまり表示上ですでに塗りつぶされて表示されている全ての記号を、なるべく小さなもので包括するように楕円を描画する(IP91)。これは、プロジェクトのメンバが座標上にどのように分布しているかをつかみやすくするためであるが、必要ない場合には行わなくても良い。以上を終えると終了(IPEN)とする。
<名札型センサノードの概観図>
図18は、名札型センサノードの構造の一実施例を示す外観図である。名札型センサノードはストラップ取り付け部NSHにネックストラップまたはクリップを取り付け、人の首または胸に装着して使用する。
本明細書では、ストラップ取り付け部NSHがある面を上面、対向する面を下面と定義する。また、名札型センサノードを装着した際に相手方に向く面を前面、前面に対向する面を裏面と定義する。さらに、名札型センサノード前面から見て左側に位置する面を左側面、左側面に対向する面を右側面と定義する。同図(A)は上面図、同図(B)は前面図、同図(C)は下面図、同図(D)は裏面図、同図(E)は左側面図を示す。
図18(B)の前面図に示すとおり、名札型センサノードの前面には液晶表示装置(LCDD)が配置される。本液晶表示装置に表示される内容は、後述するとおり相手方に向いている際には装着者の所属や名前などの名札としての表示Bを、装着者の方に向いている際には、装着者向けの組織アクティビティフィードバックデータが表示される。
名札型センサノードの表面の材質は透明であり、内部に挿入したカードCRDがケース材質を通して外から見えるようにする。名札型センサノードの内部に挿入したカード(CRD)を交換することにより名札表面のデザインを変更することができる。以上により、本名札型センサノードは一般の名札とまったく同様に人間に装着でき、なんら装着者に違和感を感じさせること無くセンサによる物理量の取得を行なうことを可能にする。
同図(A)、(B)の上面図、前面図中のLEDランプLED1、LED2は、装着者および装着者に対面する人間に名札型センサノードの状態を通知するために使用される。LED1、LED2は前面及び上面に導光され、名札型センサノードを装着した状態で、点灯状態を装着者と、装着者と対面する者の双方から視認することができる。
名札型センサノードはスピーカSPを内蔵し、装着者および装着者に対面する人間にブザーや音声で名札型センサノードの状態を通知するために使用される。マイクMICは、名札型センサノード装着者の発話及び周囲の音を取得する。照度センサLS1F、LS1Bは、それぞれ名札型センサノード前面と裏面にそれぞれ配置される。LS1F、LS1Bで取得される照度値から、装着した名札型センサノードが裏返っていることを検出し、装着者に通知する。
同図(E)から明らかなように、名札型センサノード左側面には、BTN1、BTN2、BTN3の3個のボタンが配置され、無線通信の動作モードの変更や、液晶表示画面の切り替えを行なう。名札型センサノードの下面には、電源スイッチPSW、リセットボタンRBTN、クレイドルコネクタCRDIF、外部拡張コネクタEXPTを備える。
名札型センサノードの前面には、複数の赤外線送受信部TRIR1〜4を配置する。赤外線送受信部を複数備えることが本実施例の名札型センサノードに特有な構造である。名札型センサノード自身の識別番号(TRUD)を赤外線によって間欠的に送信し、また対面者の装着する名札型センサノードが送信する識別番号を受信する機能を持つ。これにより、いつ、どの名札型センサノードが対面したかが記録され、装着した人間同士の対面状況が検出できる。図18では、TRIR1〜4の4個の赤外線送受信部をセンサノード上部に配置した例を示している。