JP2011166640A - 在席管理システム、装置、及び、端末 - Google Patents

Abstract

【課題】
相手が所有する端末の物理的な位置情報の変化を検出して通知を発行しても、次のアクションを決定するためには“相手の状態の変化”が必要になるが、従来は、相手がどういったアクションで連絡が取れる状態にあるのかを明確に通知する手段はなかった。
【解決手段】
監視対象ユーザのクライアントの状態情報の変化が在席状態となった旨を示すか、および、他のユーザに監視されているかを判定して、在席状態になった場合に、監視するユーザのクライアントにその旨を通知し、表示するシステムを提供する。
【選択図】図２

Description

監視対象のユーザの着席情報を通知する在席管理システム、装置、及び、端末に関する。

近年、ネットワークシステムの進化やＩＰ電話に代表されるコミュニケーション機器の進化により、企業内のワークスタイルにも変革がおきている。従業員に固定の席を用意せずに毎日任意の机で仕事が行えるフリーアドレスと言われるワークスタイルである。従業員はその日の気分や、業務プロジェクトなどに応じて自由に席を変更でき、レイアウトフリーなオフィススタイルが可能となる。

しかし、前記フリーアドレススタイルを導入したオフィスでは、誰が何処に座っているかが判りにくくなったと言う新たな課題が発生した。フリーアドレススタイルのオフィス拠点であれば、フロアやビルが違っても、同じように業務が行えるためである。この様な課題を解決するため、特許文献１、特許文献２に示される在席管理システムの実施例がある。

特許文献１は、ＬＡＮスイッチなどのネットワーク機器が管理する端末接続情報を元に、その端末を使用する者がどの席に在席するかを解決でき、さらに解決結果を図表上に表示することが可能な技術である。特許文献２は、端末を使用する者の座席位置解決にあたり、複数ユーザで使用される共用端末に対しても、ユーザ識別子を利用することで該ユーザの座席位置を特定できる技術である。これらの技術により、例えば特許文献１の図９のように、表示図を見るだけで何処に誰が在席しているのかが一目で判り、前記課題を解決できるようになる。

上記の公知例を代表とする技術を利用した在席管理システムでは、フリーアドレスのオフィスでも、社員が好きな席に座りＰＣなどの端末をＬＡＮに接続すると、その接続位置が図表上に表示され、離れた拠点に居る者でもその図表を見る事で誰が何処に座っているのかを把握することが可能となる。

また、各ＰＣにそのＰＣの状態（ログイン状態、スクリーンセーバ状態、電源ＯＮ／ＯＦＦなど）を検出してサーバへ自動的に通知する機能が構成されており、例えば、ログイン状態ならログインした該ユーザがＰＣ設置位置に「在席中」である。スクリーンセーバ状態なら座席位置で仕事をしているはずだが一時的に席を外している、または席には居るが他のことに取り込み中などでＰＣを使用していない状態として「離席中」である、などおおよその状態に解釈して表現することで、１００％の精度ではないものの図表を見るだけで、該ユーザの座席位置とその状態を表示することが可能となる。

これにより例えば、目的の社員に電話を掛けようとして図表を確認したときに、該社員の表示が「離席中」状態であれば、今電話をしても席を外している可能性が高いから少し様子を見て「在席中」状態となってから電話を掛けよう、などの判断を利用者が行えるようになる。

一方で、ユーザの状態（プレゼンス情報）を管理・閲覧可能なプレゼンス管理システムというものが様々なケースで開発されており、その中でも、プレゼンス情報が特定の状態になったことを通知可能なシステムとして特許文献３の実施例がある。

特許文献３は、例えばユーザが特定のユーザに対し会議室に入ったら通知が欲しいという条件をサーバに登録しておく、一方で位置測位システムが端末の位置を測位してサーバに通知しており、特定のユーザの端末が会議室に入ったという物理的な位置情報の変化を条件判定して、条件が成立したときに条件登録者に通知するという技術である。

また一方で、前記プレゼンス情報を管理するプレゼンス管理システムの１技術として、プレゼンス情報が自動入力できない場合や、利用者が手動で入力しない場合などに、スケジュール管理装置と連携することでそれを補おうという特許文献４記載の技術がある。

特許文献４は、オフライン状態などでプレゼンス情報を入手できない場合に、スケジュール管理装置と連携して、スケジュール管理装置上に現在の予定が記載されている場合は、その情報を取り込んでプレゼンス情報として表示できる技術である。

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

在席管理システムの利用において、例えば、コンタクトを取ろうとした相手が“不在”や“離席中”の場合、相手が“在席中”状態になるまでずっと図表を監視していなくてはならず大変である。ここに特許文献３の技術を用いた場合、確かに不在者に対して、その者が決められた会議室や、予め場所が決まっている自席など、位置の指定が可能な場合は、その位置を指定しておく事で、相手が所有する端末の位置が指定位置に入ったときに通知することが可能となる。

しかし、フリーアドレスの職場などで自席場所が決まってない場合や、地域に複数拠点のオフィスがある会社で、目的の社員が何処の拠点に出社するのかも不明の場合などは、通知の判定条件の登録における位置指定が出来ないことに課題がある。

また、離席の時は、本人の位置を特定できる端末がＰＣだけの場合は、ちょっとトイレに行って戻ってきたときなどに、端末の物理的な位置情報の変化を検出できないため、席に戻ったことを通知出来ない所に課題がある。

また現在、パーティションで区切られたオフィスや、広大なオフィス、フリーアドレスのオフィスも数多く見受けられる中、必ずしも無線ＬＡＮやＧＰＳで計測した大まかな範囲特定のみでは、相手が本当に自席に戻ったのか、次の会議室へ行くために席を横切っただけなのかなどを明確に決定できない課題もある。

つまり、本願が着目する課題として、相手が所有する端末の物理的な位置情報の変化を検出して通知を発行しても、直接相手の席へ会いに行く、電話を掛ける、メールを送るなどの“次のアクション”を決定するためには“相手の状態の変化”が必要になるが、従来は、ＧＰＳなどによる大まかな物理的な位置を通知することはできても、相手がどういったアクションで連絡が取れる状態にあるのかを明確に通知する手段はなかった。

さらに、在席管理システムと特許文献３記載の通知技術を組み合わせた時、指定の条件になったことを利用者に伝えることは出来ても、その通知を受けて“次のアクション”に繋がるユーザへの利便性を追求できていない所にも課題がある。

具体的な例を示すと、利用者はＡさんが自席に戻ったときにすぐ連絡したいという目的から、Ａさんが自席位置に戻ったら通知するようにサーバへ通知条件を登録する。暫くしてＡさんが自席に戻ると、特許文献３記載の物理的な位置情報の変化を検出して、例えば利用者の携帯電話にＡさんが自席に戻った旨のメッセージが送られる。しかし、利用者がそのメッセージを受け実際にＡさんにコンタクトを取ろうとした場合、Ａさんの電話番号を携帯電話のアドレス帳から探して電話を掛ける、あるいは近くの内線電話から相手の内線番号を探して電話を掛けなくてはならず、不便である。

相手とコンタクトを取りたいという目的で設定する通知条件の登録であるのだから、通知を受けたらすぐに次のアクションに繋がる手段や情報を示すことが出来れば、より利用者に優しい通知機能の提供が可能になると考えられるのだが、そこまで想定されたシステムは提案されていない。

次に、在席管理システムの利用において、目的のユーザが不在の場合、どこの図表上にも目的のユーザが表示されない、または、目的のユーザを前記システムで検索したときに、そのユーザの詳細情報を表示し「在席場所＝“不在”」と言う情報を示すのみであった。

そこで特許文献４記載の技術を組み込むことにより、例えばスケジュール管理装置に「１０時〜１２時、顧客Ａ社訪問」と登録してあれば、１０時から１２時の間は「在席場所＝“顧客Ａ社訪問”」と示す事が出来、利用者が目的の人とコンタクトを取りたいと思って在席管理システムを利用する時に、より具体的な情報の提供が可能となる。

しかし前記技術では、１０時から１２時までは「顧客Ａ社訪問」と言うことが判るが、１２時以降の情報は１２時を過ぎなくては判らないという点に課題があった。

この場合、目的のユーザが１２時の後にすぐ帰社するのか、その後、顧客Ｂ社を訪問するかは、その時間にならないと把握できず、利用者としては「１２時の後にすぐ帰社するなら少し待ってみよう」とか、「その後にも予定が入っているなら要件だけをメールで送っておくか」といった判断を即座にすることが出来ない点に課題があった。

すなわち、在席管理システムの利用において目的のユーザを検索したときに、そのユーザが不在の場合、不在であるということと、特許文献４記載の技術を用いれば現時点（今の）のスケジュール管理装置に記録される情報は表示されるが、今後の予定や、直前の予定を見たいと思ったときに、すぐ目的の情報が得られない所に課題がある。

上記問題点を鑑み、本発明は、在席管理システムの利用において、目的とする相手が離席や不在などの状態時に、相手の物理的な位置の変化だけでなく“相手の状態の変化”にも着目した通知方法を提供し、さらにその通知を受けて、利用者を次のアクションへ繋げる手段や情報を提供することと、プレゼンス情報は現在の情報を表示するという概念を一歩進め、目的とするコンタクト相手の直前の予定や、今後の予定までも、ワンストップで提供可能なコミュニケーションシステムを提供することを目的とする。

上記課題の少なくとも一つを解決するために、本発明では、複数のクライアントとサーバからなる在席通知システムであって、前記クライアントは、監視対象のユーザの在席通知情報を表示する通知表示部と、前記クライアントを使用するユーザの状態情報の変化を前記サーバに通知する状態通知部とを有し、前記サーバは、前記複数のクライアントの何れかから通知された状態情報の変化が在席状態となった旨を示すか、および、他のユーザに監視されているかを判定する判定部と、前記監視対象のユーザが在席状態になった旨を前記他のユーザのクライアントに通知する通知部を有することを特徴とする在席通知システムを提供する。

本発明によれば、端末の物理的な位置情報の変化だけでなく、“次のアクション”を明確に決定できるための“状態情報の変化”を通知する機能を提供することができる。

本実施例１を実施するための基本的な通信システム構成図 本実施例１を実施するための論理機能図 本実施例１を実施するための通知登録の画面インタフェース例１ 本実施例１を実施するための通知登録の画面インタフェース例２ 通知登録ＤＢ211に格納されるテーブルの内容を示す図 本実施例１を実施するための通知登録部212の処理フローを示すフローチャート 本実施例１を実施するための通知判定部209の処理フローを示すフローチャート 本実施例１を実施するための通知送信部210の処理フローを示すフローチャート 本実施例１を実施するためのメッセージ画面例 本実施例１を説明した利用シーンのシーケンス 本実施例２を実施するための基本的な通信システム構成図 本実施例２を実施するためのメッセージの画面インタフェース例 本実施例３を実施するための基本的な通信システム構成図 本実施例３を実施するための画面インタフェース例 本実施例３を実施するためのメッセージの画面インタフェース例

以下、この発明の実施の形態を添付図面に基づいて説明する。図１は本実施例を実施するための基本的な通信システム構成図である。ＰＣ101a〜ＰＣ101cが、ＬＡＮスイッチ（以下、ＳＷと略す）102に接続されている。また、在席管理サーバ103とＬＤＡＰ（Lightweight Directory Access Protocol）システム104がＳＷ102に接続されている。

ＳＷ102はパケットを転送する機能を有し、ＭＩＢ（Management information base）といわれる管理情報ベースを備え、その情報は、ＳＮＭＰ（Simple Network Management Protocol）を用いて他の機器によって取得することができる。

在席管理サーバ103は、座席とＰＣ101の位置関係を管理し、ＰＣ101から状態情報の変化の通知を受け、さらには、他のＰＣ101を利用しているユーザの状態情報（着席した等）の変化を通知する。そのために、定期的にあるいは、状態の変化があった場合に、ＰＣ101から状態情報の変化を受信する。

ＬＤＡＰシステム104は、社員の名前や所属情報を格納するＤＢで、社員を一意に識別する社員ＩＤをキーに紐付く詳細情報を取得することができる。

図２は、本実施例を実施するための機能ブロック図である。

ＰＣ101は、在席管理サーバから監視相手の状態情報の変化を受信して表示する通知表示部201と、PC101を利用するユーザの状態情報の変化を通知するＡｇｅｎｔ部202を有する。

Ａｇｅｎｔ部202は、該ＰＣ101のＭＡＣアドレス、該ＰＣ101を利用する社員の社員ＩＤ、該ＰＣの利用状態（ステータス）を取得してＡｇｅｎｔ通知処理部208へ送信する。該ＰＣ101を利用する社員の社員ＩＤとは、例えば該ＰＣ101のログインＩＤなどをさし、ここではログインＩＤとして社員ＩＤが使われていることとする。

また、該ＰＣの利用状態（ステータス）とは、ログイン状態、スクリーンセーバ状態、電源ＯＮ／ＯＦＦ状態、ソフトフォンによる通話状態、一定時間のキー入力やマウス入力が続いている状態など、ＰＣ内で取得可能な操作状況や稼働状況を示す値のことである。ここでは簡潔に説明するため、ログイン状態を“ステータス＝１”、スクリーンセーバ状態を“ステータス＝２”という２つの状態を取得でき、表示上では、“１（ログイン状態）＝在席中”、“２（スクリーンセーバ状態）＝離席中”、“０（電源ＯＦＦ状態）＝不在”と仮定した実施例を記載する。

通知表示部201は、後述する通知送信部210からの通知情報を画面に表示する機能を示す。通知送信部210からの通知情報を受け取った際は、メッセージ表示ウィンドウを生成しメッセージを画面に出力する。

在席管理サーバ102は、通信部203、ＭＩＢ収集部204と、ＳＷポート・ＭＡＣ対応ＤＢ205と、場所・ＳＷポート対応ＤＢ206と、在席管理ＤＢ207と、Ａｇｅｎｔ通知処理部208と、通知判定部209と、通知送信部210と、通知登録ＤＢ211と、通知登録部212と、ＬＤＡＰ検索部213と、描画処理部214と、ウェブサーバ部215とを備える。

通信部203は、在席管理サーバ103がネットワークを介して通信するときの通信を行う機能部を示す。

座席とＰＣ101の位置関係の管理について説明する。

ＭＩＢ収集部204が、通信部203を介して、前記ＳＮＭＰを用いてＳＷ102からＳＷポート・ＭＡＣ対応情報を定期的に収集し、その情報をＳＷポート・ＭＡＣ対応ＤＢ205に格納する。場所・ＳＷポート対応ＤＢ206には、あらかじめ、場所（座席）とＳＷポートの対応関係が記憶されており、ＳＷポート・ＭＡＣ対応ＤＢ205と、場所・ＳＷポート対応ＤＢ206を用いることにより、どのＰＣ101がどの座席にあるかを判別することが可能となる。

具体的には、ＳＷポート・ＭＡＣ対応ＤＢ205は、前記ＳＷ102から取得した“ＳＷ−ＩＤ＆ＳＷ−ポート”と“ＭＡＣアドレス”の対応情報を格納しており、その情報から「どのＳＷの何番ポートにＭＡＣアドレスＸが繋がる」という事実が判る。

場所・ＳＷポート対応ＤＢ206は、事前に定義される情報で“ＳＷ−ＩＤ＆ＳＷ−ポート”と“場所名”の対応情報を格納しており、その情報から「どのＳＷの何番ポートが座席Ｘ」という位置名情報が判る。

次に、座席表示機能について説明する。

描画処理部214は、在席管理ＤＢ207の情報とＬＤＡＰシステム104の情報を紐づけて、座席表画面データを生成する。Ｗｅｂサーバ部215は、描画処理部214が生成した画面データをＷＷＷ（World Wide Web）技術を用いて表示させる機能部を示す。Ｗｅｂサーバ部215と描画処理部214を併せて画面表示機能部としてもよい。

ＬＤＡＰ検索部213は、別機能部からの検索要求を受け、前記ＬＤＡＰシステム104に対して社員情報の検索を実施する機能部を示す。ユーザは、これらの機能を用いて、図３，４で後述するように、通知を受けたい相手を指定することができる。

次に、状態情報の収集について説明する。

Ａｇｅｎｔ通知処理部208は、通信部203を介して、ＰＣ101のＡｇｅｎｔ部202からの状態情報の変化の通知を受け取り、その情報を在席管理ＤＢ207に格納する。また、後述する通知判定部209にもその情報を受け渡す。在席管理ＤＢ207は、ＳＷポート・ＭＡＣ対応ＤＢ205と場所・ＳＷポート対応ＤＢ206から導き出される在席場所情報（“ＭＡＣアドレス”＝“場所名”）と、Ａｇｅｎｔ通知処理部208から渡される該Ａｇｅｎｔが存在する端末のＭＡＣアドレス、その端末を利用する社員の社員ＩＤ、その社員のＰＣ利用状態（ステータス）が紐付けされて格納されている。

通知判定部209、通知送信部210、通知登録部212、通知登録ＤＢ211については後述にて詳細を説明する。

図３は、本実施例を実施するための通知登録の画面インタフェース例の一つである。本インタフェースは、Ｗｅｂサーバ部215に画面データ216として格納される。ＰＣ101のディスプレイなどの画面インタフェースで登録画面301が表示される。画面データは、一部を予めＰＣ101のメモリなどの記憶媒体に格納しておいてもよい。

登録画面301にて、テキストボックス304に検索キーを入力し、検索実行ボタン305の押下により、検索が行われ検索結果306が表示される。検索結果306にて、在席状態が“離席中”および“不在”の場合は、通知登録ボタン307が表示される。そして、通知登録ボタン307を押下すると、登録情報が通知登録部212に渡される。

また、図４の座席表401（フロアマップともいう）を表示するための座席表表示ボタン302と、図３の検索画面を表示するための検索画面表示ボタン303があり、これらのボタンで画面を切り替えることができる。フロアマップを表示したまま検索できるようにしてもよい。

具体例を用いて説明すると、営業部のＢさんに対して、帰社して席に着いたタイミングで連絡を取りたいと考えた場合、テキストボックス304に「営業部」と入力し、検索実行ボタン305を押下する。すると営業部の一覧が検索結果306に表示される。検索結果306の中から「Ｂさん」の在席状態を確認すると“不在”となっているため、Ｂさんの通知登録ボタン307を押下することで通知の登録が実行できる。

図４は、本実施例を実施するための通知登録の画面インタフェース例の二つ目である。図３との相違点は、座席表401として、フロアの座席が表示されビジュアル的に探したい相手を見つけられることである。

具体的には、離席中のＡさんの座席404を、マウスのカーソルでクリックするなどして、選択すると、詳細情報画面402が表示され、登録通知ボタン403により登録が実行できる。尚、Ａさんの座席部分を選択した時点で通知登録がされてもよい。

図５は、通知登録ＤＢ211に格納されるテーブルの内容を示す図である。通知登録ＤＢ211は、通知を受けたい対象相手の社員ＩＤ（＝ウォッチ対象ＩＤ501）と、通知登録者の社員ＩＤ（＝登録者ＩＤ502）と、通知失敗フラグ503と、データ更新時刻504との対応を記述した表である。すなわち、行511においては「社員ＩＤ“１００”」という人が「社員ＩＤ“１６４”」という人の通知登録を「データ更新時刻“2009.08.28.13:20”」に登録したということを記述している。行512においては通知失敗フラグ503は、通知送信部210が、該レコードの通知登録者の社員ＩＤ「３２４」へ、ウォッチ対象ＩＤ「２００」の在席状態への更新を通知したが、何らかの原因によって通知が届かなかった場合、通知失敗フラグ503を「１」にして処理を終える。通知失敗フラグ503が「１」のレコードについては、一定時間ごとに通知送信部210が通知の再送を試みる。

図６は、本実施例を実施するための通知登録部212の処理フローである。通知登録部212は、本機能利用者が通知を受けたい対象相手の社員ＩＤ（＝ウォッチ対象ＩＤ501）を登録するための処理機能部である。本機能利用者の社員ＩＤとウォッチ対象社員ＩＤを登録する。登録は図３、４に記載した画面インタフェースを介して行われる。

本フローは、前記画面インタフェースにて登録ボタン307または403を押下した際に処理が始まる。S601において、図３の通知登録ボタン307または図４の通知登録ボタン403を押下した社員ＩＤと、ウォッチ対象ＩＤをＷｅｂサーバ部215より取得する。

S602において、前記登録者ＩＤとウォッチ対象ＩＤのセットが既に登録されていないかを判定し、既に登録されている場合（S602：Ｙｅｓ）は処理フローを終了させる。登録されていない場合（S602：Ｎｏ）は、S603において、通知登録ＤＢ211を参照し、ウォッチ対象ＩＤの“ステータス＝１”かを判定し、一致する場合（S603：Ｙｅｓ）は、S605において、既に在席状態である旨のメッセージを登録画面301、または、401に表示させる。一致しない場合（S603：Ｎｏ）は、S604において、「登録者ＩＤ」と「ウォッチ対象ＩＤ」と「通知失敗フラグ＝０」と「データ更新時刻」を通知登録ＤＢ211に登録し、本処理フローを終了させる。

図７は、本実施例を実施するための通知判定部209の処理フローである。通知判定部209は、Ａｇｅｎｔ通知処理部208から通知情報を受け取り、対象社員ＩＤが通知登録ＤＢ211にあるかを判定する機能部である。

本フローは、Ａｇｅｎｔ通知処理部208から通知情報を受け取った際に処理が始まる。S701において、受け取った通知から、社員ＩＤとステータス値を取り出す。S702において、“ステータス＝１”を判定し、一致しない場合（S702：Ｎｏ）は処理フローを終了させる。一致する場合（S702：Ｙｅｓ）は、S703において、通知登録ＤＢ211に該社員ＩＤの対象レコードがあるかを判定し、一致しない場合（S703：Ｎｏ）は処理フローを終了させる。一致する場合（S703：Ｙｅｓ）は、S704において、メッセージの送信を通知送信部210に指示して本処理フローを終了させる。尚、S704の前に、登録の追加条件の設定・判定機能を設けても良い。例えば、スクリーンセーバ状態からログイン状態になった場合のみ通知などの条件を設定する。このような追加条件により、少しの間、離席中のユーザのみを通知登録の対象とするなどが可能となる。

図８は、本実施例を実施するための通知送信部210の処理フローである。通知送信部210は、通知判定部209のS704の指示により処理が始まる。S801において、通知判定部209から、「通知先アドレス情報」と「通知先社員ＩＤ」と「在席場所情報」を取得する。通知先アドレス情報とは在席管理ＤＢ207の「ＭＡＣアドレス」のことであり、通知先社員ＩＤとは通知登録ＤＢ211の「登録者ＩＤ」のことであり、在席場所情報とは在席管理ＤＢ207の「在席場所名」のことである。通知先アドレス情報と在席場所情報についてはS704の指示を受けて、在席管理ＤＢ207を直接参照しても構わない。また、通知先アドレス情報については、Ａｇｅｎｔ部202が自ＰＣ101のＩＰアドレスを送信するように構成し、在席管理ＤＢ207に格納されるＩＰアドレス情報を利用しても構わない。

S802において、前記取得した登録者ＩＤからＬＤＡＰ検索部213を利用してＬＤＡＰシステム104から氏名情報を解決する。そして、S803において、通知するメッセージデータを組み立てて「通知先アドレス情報」宛の通知表示部201へ通知を送信する。通知表示部201は正常に通知を受信した際に、受信成功を示す情報を通知送信部210へ返信する構成をとっており、S804において、前記受信成功返答を待ち、返答を受信した場合（S804：Ｙｅｓ）は、S806において、通知登録ＤＢ211から該当のレコードを削除する。一定時間が経過しても返答を受信できない場合（S804：Ｎｏ）は、S805において、通知失敗フラグ４０３に“１”をセットして本処理フローを終了させる。

図９は、本実施例を実施するためのメッセージ画面例である。図８のS803により通知表示部201が生成するメッセージ表示ウィンドウである。ウィンドウ901は、通知時間を表示するテキストと、メッセージ内容を表示するテキストと、在席場所名を表示するテキストから構成される。これらはテキスト情報でなくともよい。このメッセージの受信により、ウォッチ対象ＩＤの社員が、何処の場所で“ステータス＝在席中”の状態になり電話やインスタントメッセージ（以下、ＩＭと略す）などで連絡を取ることが可能な状態になったということを登録者が認知できる。

図１０は、本実施例で説明した利用シーンのシーケンスである。ＡさんがＢさんに対する通知登録を行うシーンをシーケンスにて説明する。尚、これ以降ＡさんとＢさんの行動は、実際にはPC101a,bが操作を受け付けて動作しているものであり、ＡさんとＢさんが直接行動しているわけではない。

S1001において、Ｂさんが社内で在席状態（ログイン状態）となったことを受け、S1002において、Ａｇｅｎｔ部202が“ステータス＝１”を在席管理サーバ102へ送信する。S1003において、Ａｇｅｎｔ通知処理部208は前記通知を受け、受信データを在席管理ＤＢ207に登録する、また、通知判定部209は、Ａｇｅｎｔ通知処理部208から通知情報を受け取り、対象社員ＩＤが通知登録ＤＢ211にあるかを判定する。この時点では通知登録ＤＢ211に該当レコードがないため無視する。

続いてS1004において、ＡさんのＰＣ101aがＢさんの在席情報を確認する。この時点でＢさんは在席中の状態なので、S1005において、画面データ216を参照して在席情報が確認出来る。次にS1006において、Ｂさんが離席し、席から一定時間離れたことによりスクリーンセーバが起動し、S1007において、スクリーンセーバが起動したことを受けてＡｇｅｎｔ部202が“ステータス＝２”を在席管理サーバ103へ送信する。

S1008において、Ａｇｅｎｔ通知処理部208は前記通知を受け、受信データを在席管理ＤＢ207に登録する、また、通知判定部209は、Ａｇｅｎｔ通知処理部208から通知情報を受け取るが、 “ステータス＝２”のため無視する。

次にS1009、S1010において、Ａさんが電話を掛けようと再びＢさんの在席情報を確認する。この時点でＢさんは離席中なので、今Ｂさんへ電話を掛けても居ない可能性が高いと判断できるため、S1011、S1012において、図３、４の登録画面301または登録画面401を用いてＢさんが在席状態になったときに知らせて貰うよう登録する。S1013において、通知登録部212が通知登録ＤＢ211に前記登録情報を登録する。

次にS1014、S1015において、Ｂさんが席に戻りＰＣでの作業を始めたため（ログイン状態となった）、Ａｇｅｎｔ部202が“ステータス＝１”を在席管理サーバ103へ送信する。S1016において、Ａｇｅｎｔ通知処理部208は前記通知を受け、受信データを在席管理ＤＢ207に登録する。また、S1017において、通知判定部209は、Ａｇｅｎｔ通知処理部208から通知情報を受け取り、対象社員ＩＤが通知登録ＤＢ211にあるかを判定する。ここで、通知登録ＤＢ211にＢさんをウォッチ対象ＩＤとして登録しているレコードがあるため、通知送信部210へメッセージの通知を指示する。

S1018、S1019において、通知送信部210がＡさんのＰＣ101aの通知表示部201へメッセージを送る。S1020において、ＰＣ101aの通知表示部201は、メッセージの受信を受けて図９のウィンドウ901をディスプレイ等に表示する。また、S1021において、通知送信部210に対し、受信成功返答を送る。S1022において、通知送信部210は通知表示部201からの受信成功返答を受けて、通知登録ＤＢ211から該当のレコードを削除する。

以上の処理により、本機能利用者は在席表示システムの利用において、コンタクトを取ろうとした相手が不在や離席中の場合、相手が着席するまでずっと図表を監視していなくても、対象相手を通知登録しておくことで、メッセージの受信により、ウォッチ対象ＩＤの社員が、何処の場所で“ステータス＝在席中”の状態になり電話やＩＭなどで連絡を取ることが可能な状態になったということを登録者が認知できるようになる。

なお、ここでは在席状態が“離席中”および“不在”の場合のみ通知登録が可能で、“在席中”になった契機のみで通知判断を行う例を示しているが、例えば図３の画面インタフェースにて、登録時に「会議室Ａで」や「Ｂ支社のオフィスで」といった追加条件を指定できるように拡張することも可能である。その場合は通知登録ＤＢ211に追加条件を格納するカラムを追加し、通知登録ＤＢ211に追加の判定条件が指定されている場合には通知判定部209のS703の判定の後、さらに在席管理ＤＢ207を参照して追加の条件を判定させ、一致する場合のみS704の処理を実行することで実現できる。

次に、第２の実施するための形態を添付図面に基づいて説明する。

図１１は本実施例２を実施するための基本的な通信システム構成図である。図１の構成に、電話システム1102、ＩＭシステム1103、メールシステム1104が構成されている。また各システムや装置は社内ＬＡＮ1101に接続されている。また、ＰＣ101a〜ＰＣ101cには、前記、電話システム1102、ＩＭシステム1103、メールシステム1104を利用するためのクライアントソフトもしくはハードウェア構成を含む。

電話システム1102は、一般的な企業内内線電話などを実現するシステムであり、具体的にはＩＰテレフォニーサーバと呼ばれるサーバと、ＰＣ101a〜ＰＣ101cにはソフトフォンと呼ばれるクライアントソフトから構成される。

ＩＭシステム1103は、企業内でのインスタントメッセージングを実現するシステムであり、同じくＩＭサーバと、ＰＣ101a〜ＰＣ101cにはＩＭクライアントと呼ばれるクライアントソフトから構成される。

メールシステム1104は、一般的な電子メールを実現するシステムであり、同じく電子メールサーバと、ＰＣ101a〜ＰＣ101cにはメーラーなどと呼ばれるクライアントソフトから構成される。

図１２は、本実施例２を実施するためのメッセージの画面インタフェース例である。ウィンドウ1201は、前記図９にて記載したウィンドウ901と同様に、通知送信部210と通知表示部201の処理にて該社員が利用する端末に通知される画面である。ウォッチ対象として登録した社員が、指定の状態になったことをテキストで記載されている。なお、テキスト以外にも絵や音声で通知しても良い。

図９との相違点として、ボタン1202〜1205を配置したことを特徴とする。ボタン1202は、座席表を画面に表示するためのリンクインタフェースである。ボタン1202を通知受信者が押下すると、描画処理部214が生成する座席表画面のうち、ウォッチ対象社員が在席するフロアの座席表画面をＰＣ101のＷｅｂブラウザに表示させる。これにより、通知を受けてボタン1202を押下することで、該社員が何処に在席しているのかを座席表を用いて視覚的に指し示すことが可能となる。

ボタン1203は、クリックｔｏコールによる電話発信を実行するためのリンクインタフェースである。ボタン1203を通知受信者が押下すると、例えば自ＰＣ内に構成されるソフトフォンに対し、該ユーザの発信先の電話番号を引数に起動させる。これにより、通知を受けてボタン1203を押下することで、該社員へワンクリックで掛け間違えることもなく電話発信することが可能となる。

ボタン1203押下時の発信先電話番号の受け渡し方法としては、色々な手段が考えられ、一例としてはクリップボード連携による受け渡しが上げられる。クリップボード連携とは、ソフトフォンは常にクリップボードと呼ばれるＯＳ上の共通的なメモリ空間を監視しており、予め決められているマジックワード（例えば“Ｃ２Ｃ−ＴＥＬ：”）の入力を監視している。また、ソフトフォンが前記マジックワードを見つけた際は、「：」以下の文字列を電話番号と認識して発信することがプログラムされている。よって、ボタン1203は、押下された時に、クリップボードへ「Ｃ２Ｃ−ＴＥＬ：２００１」と書き込むと、ソフトフォンが２００１番に対して電話発信を行うことが可能となる。

ボタン1204は、ＩＭクライアントを起動するためのリンクインタフェースである。ボタン1204を通知受信者が押下すると、自ＰＣ内に構成されるＩＭクライアントに対し、該ユーザの宛先アドレスを引数に起動させる。これにより、通知を受けてボタン1204を押下することで、メッセージ送信画面を素早く起動し、該社員へのインスタントメッセージを発信することが可能となる。

ボタン1205は、メーラーを起動するためのリンクインタフェースである。ボタン1205を通知受信者が押下すると、自ＰＣ内に構成されるメーラーに対し、該ユーザの宛先アドレスを引数に起動させる。これにより、通知を受けてボタン1205を押下することで、メッセージ送信画面を素早く起動し、該社員への電子メールを発信することが可能となる。

以上の機能を実施例１と組み合わせて提供することにより、会議室、同じフロア、他の建物のフロアなど一切関係なく、“連絡が取れる状態”になった場合に通知を受け取ることが出来、更に通知メッセージから受信者が“次のアクション”を容易に選択できるようにする一連の仕組みを提供することが可能となる。

具体的には、図１２のメッセージウィンドウ1201を閲覧する利用者は、もし直接会って会話したいと考えたならば、その相手が座る在席位置を座席表画面上に視覚的に表示することが可能であり、もし電話を掛けたいと考えたならば、その相手の電話番号情報を表示させ、かつクリックｔｏコールによる電話発信機能を提供することも可能であり、もしインスタントメッセージにて連絡を取りたいと考えたならば、その相手へのＩＭによるメッセージ送信画面を即座に開く機能を提供することが可能であり、もし電子メールにて連絡を取りたいと考えたならば、その相手への電子メールによるメッセージ送信画面を即座に開く機能を提供することが可能という、“次のアクション”に繋がる情報または機能を提供できるようになる。

このように、相手の状態がわかったとしても、相手の居場所や自分との位置関係により、次のアクションが異なるのが通常である。本実施例によると、相手の変化の状態通知に併せて適切なアクションを選択肢としてユーザに提示し、コミュニケーションを円滑化することが可能となる。

次に、第３の実施例を実施するための形態を添付図面に基づいて説明する。

図１３は本実施例を実施するための基本的な通信システム構成図である。図１または図１１の構成に、スケジュールシステム1301が追加されている。

スケジュールシステム1301は、一般的な企業内での社員のスケジュール管理を実現するシステムである。スケジュールシステム1301は、単一のサーバとしてもよいし、機能として在席管理サーバ103にもたしてもよい。スケジュールシステム1301との様々な連携が可能であるが、ここでは、ＵＲＬによるＷｅｂインタフェースを備えるスケジュールシステム1301との連携例を記載する。

ＵＲＬによるＷｅｂインタフェースとは、スケジュールシステム1301の利用がＷｅｂ画面を通して利用可能であり、さらにスケジュールシステム1301のＷｅｂ画面へアクセスする為のＵＲＬに社員ＩＤなどの引数を付けてアクセスすることで、該社員ＩＤの利用者画面を直接表示することが可能なインタフェースのことである。具体的な例を用いて説明すると、スケジュールシステム1301のＷｅｂ画面へアクセスする為のＵＲＬが、“http://www.schedulesystem.do”であった場合に、スケジュールシステム1301に登録されている「Ａさん」の利用者ＩＤが“２００”であった例を示すと、（１）“http://www.schedulesystem.do?user-id=200”というＵＲＬを入力することにより、Ａさんのスケジュール画面を表示することが可能なインタフェースのことである。

図１４は、本実施例を実施するための画面インタフェース例である。在席管理システムで表示される図３の画面に、スケジュール表示ボタン1402を追加したことを特徴とする。その他の構成は図３と同様である。

スケジュール表示ボタン1402は、押下するとＷｅｂブラウザソフトへ、前記（１）のＵＲＬ情報にスケジュール表示ボタン1402が表示される行の該社員ＩＤをセットした情報を渡す。Ｗｅｂブラウザソフトは、前記（１）にて例示したインタフェースを用いて、利用者の画面にコンタクトを取りたい相手のスケジュール画面を表示する。これにより、ちょっと打ち合わせで席を離れているだけだから、通知登録しよう、または、出張で戻ってきそうにないので通知登録しないなどの、相手の予定に合わせた通知登録処理が可能となる。

図１５は、実施例２記載の構成に、本実施例を実施するためのメッセージの画面インタフェース例である。ウィンドウ1501は、前記図１２にて記載したメッセージ画面と同じで、通知送信部210と通知表示部201の処理にて該社員が利用する端末に通知される画面で、さらに実施例２記載の“次のアクション”に繋がる情報または機能を構成した画面インタフェース例である。ここに、スケジュール表示ボタン1502 を配置したことを特徴とする。

スケジュール表示ボタン1502は、前記スケジュール表示ボタン1402と同様の処理を行うリンクインタフェースである。スケジュール表示ボタン1502を通知受信者が押下すると、Ｗｅｂブラウザソフトへ、前記（１）のＵＲＬ情報にウォッチ対象の社員ＩＤをセットした情報を渡す。Ｗｅｂブラウザソフトは、前記（１）にて例示したインタフェースを用いて、利用者の画面にコンタクトを取りたい相手のスケジュール画面を表示する。

以上により、在席管理システムを代表としたプレゼンスシステムやコミュニケーションシステムにおいて、今現在のスケジュール情報だけでなく、直前の予定や、今後の予定を、コンタクトを取りたいと考えた利用者が手軽に把握できる仕組みを提供することが可能となる。

具体的には、図１４にてコンタクトを取りたい相手が不在だった場合、スケジュール表示ボタン1402を押下して相手のスケジュール画面を表示し、例えば後３０分くらいで出張から帰る予定となっている場合は、通知登録ボタンの機能を用いて、帰社して連絡を取ることが可能な状態になった時に知らせてくれるように登録し、もし本日は夕刻まで顧客先を回っているという予定の場合は、メールなどで要件を伝えておこうと利用者が判断することが可能となる。

また、図１５にてコンタクトを取りたい相手が連絡を取ることが可能な状態になったという通知が来た時に、スケジュール表示ボタン1502を押下して相手のスケジュール画面を表示し、例えば５分後から会議の予定が入っていることが確認出来た場合は、とりあえずＩＭにて要件だけを相手に伝えておこうという判断ができ、もし今後の予定が入っていないことが確認出来た場合は、相手の在席位置まで行って直接じっくりと会話することが出来そうだな、などと利用者が判断することが可能となる。

１０１ ＰＣ
１０２ ＬＡＮスイッチ
１０３ 在席管理サーバ
１０４ ＬＤＡＰシステム
２０１ 通知表示部
２０２ Ａｇｅｎｔ部
２０３ 通信部
２０４ ＭＩＢ収集部
２０５ ＳＷポート・ＭＡＣ対応ＤＢ
２０６ 場所・ＳＷポート対応ＤＢ
２０７ 在席管理ＤＢ
２０８ Ａｇｅｎｔ通知処理部
２０９ 通知判定部
２１０ 通知送信部
２１１ 通知登録ＤＢ
２１２ 通知登録部
２１３ ＬＤＡＰ検索部
２１４ 描画処理部
２１５ ウェブサーバ部

Claims (18)

1. 複数のクライアントとサーバからなる在席通知システムであって、
   前記クライアントは、
   監視対象のユーザの在席通知情報を表示する通知表示部と、
   前記クライアントを使用するユーザの状態情報の変化を前記サーバに通知する状態通知部とを有し、
   前記サーバは、
   前記複数のクライアントの何れかから通知された状態情報の変化が在席状態となった旨を示すか、および、他のユーザに監視されているかを判定する判定部と、
   前記監視対象のユーザが在席状態になった旨を前記他のユーザのクライアントに通知する通知部を有することを特徴とする在席通知システム。
2. 請求項１記載の在席通知システムであって、
   前記在席通知情報を監視する他のユーザにより、さらに監視条件が設定されている場合、
   前記判定部は、前記通知された在席通知情報が前記監視条件を満たすかを判定し、当該監視条件を満たした場合のみ前記通知部に前記監視対象のユーザが在席状態になった旨の通知をさせることを特徴とする在席通知システム。
3. 請求項２記載の在席通知システムであって、
   前記クライアントの前記通知表示部は、前記監視対象のユーザの名前と、前記監視対象のユーザのいる建物名と、フロアと、前記フロア内での在席場所を表示することを特徴とする在席通知システム。
4. 請求項３記載の在席通知システムであって、
   前記クライアントの前記状態通知部は、前記クライアントがユーザにログインされると、在席状態になったと判断し、在席状態となった旨を示す前記状態情報の変化を前記サーバに通知することを特徴とする在席通知システム。
5. 請求項３または４に記載の在席通知システムであって、
   前記クライアントの前記通知表示部は、前記監視対象のユーザのいる建物名と、フロアと、前記フロア内での在席場所と共に、前記監視対象のユーザへの連絡手段を提示することを特徴とする在席通知システム。
6. 請求項３乃至５のいずれかに記載の在席通知システムであって、
   前記通知表示部の提示内容には、座席表を表示するためのリンクが設定されていることを特徴とする在席通知システム。
7. 請求項５記載の在席通知システムであって、
   前記連絡手段は電話またはインスタントメッセンジャーまたはメールであることを特徴とする在席通知システム。
8. 複数のクライアントと接続される在席通知サーバであって、
   前記複数のクライアントの何れかから通知された状態情報の変化が在席状態となった旨を示すか、および、他のユーザに監視されているかを判定する判定部と、
   監視対象のユーザが在席状態になった旨を前記他のユーザのクライアントに通知する通知部を有することを特徴とする在席通知サーバ。
9. 請求項８記載の在席通知サーバであって、
   前記在席通知情報を監視する他のユーザにより、さらに監視条件が設定されている場合、
   前記判定部は、前記通知された在席通知情報が前記監視条件を満たすかを判定し、当該監視条件を満たした場合のみ前記通知部に前記監視対象のユーザが在席状態になった旨の通知をさせることを特徴とする在席通知サーバ。
10. 請求項９記載の在席通知サーバであって、
    前記監視対象のユーザの名前と、前記監視対象のユーザのいる建物名と、フロアと、前記フロア内での在席場所を含む通知をすることを特徴とする在席通知サーバ。
11. 請求項８記載の在席通知サーバであって、
    登録されているユーザの在籍状況をフロアマップによりクライアントに表示させ、前記フロアマップから選択されたユーザの在席状態の監視登録を受け付ける画面表示機能部を有することを特徴とする在席通知サーバ。
12. 請求項１１記載の在席通知サーバであって、
    前記画面表示機能部は、ユーザ検索機能により検索したユーザが使用する座席を含むフロアマップを表示することを特徴とする在席通知サーバ。
13. 在席通知機能を有するクライアントであって、
    監視対象のユーザの在席通知情報を表示する通知表示部と、
    前記クライアントを使用するユーザの状態情報の変化を通知する状態通知部と、を有することを特徴とするクライアント。
14. 請求項１３記載のクライアントであって、
    前記クライアントの前記通知表示部は、前記監視対象のユーザの名前と、前記監視対象のユーザのいる建物名と、フロアと、前記フロア内での在席場所を表示することを特徴とするクライアント。
15. 請求項１４記載のクライアントであって、
    前記クライアントの前記状態通知部は、前記クライアントがユーザにログインされると、在席状態になったと判断し、在席状態となった旨を示す前記状態情報の変化をユーザの在席状況を管理するサーバに通知することを特徴とするクライアント。
16. 請求項１４または１５に記載のクライアントであって、
    前記クライアントの前記通知表示部は、前記監視対象のユーザのいる建物名と、フロアと、前記フロア内での在席場所と共に、前記監視対象のユーザへの連絡手段を提示することを特徴とするクライアント。
17. 請求項１４乃至１６のいずれかに記載のクライアントであって、
    前記通知表示部の提示内容には、座席表を表示するためのリンクが設定されていることを特徴とするクライアント。
18. 請求項１６記載のクライアントであって、
    前記連絡手段は電話またはインスタントメッセンジャーまたはメールであることを特徴とするクライアント。

Images