JP3724068B2

JP3724068B2 - Information sharing system

Info

Publication number: JP3724068B2
Application number: JP19046896A
Authority: JP
Inventors: 敏奥山; 安英松本; 純代岡田; 愛真鍋
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1996-07-19
Filing date: 1996-07-19
Publication date: 2005-12-07
Anticipated expiration: 2016-07-19
Also published as: JPH1040317A

Description

【０００１】
【発明の属する技術分野】
本発明は、複数のクライアント端末から共通のサーバ機を利用して情報を共有化するネットワークシステムの改良に関し、特に各クライアント端末個別の利用者の在席状態等の状態情報を共有化して、オフィス活動の効率化を図る情報共有化システムに関するものである。
【０００２】
【従来の技術】
近年、パソコンの普及およびネットワークの発達により、端末間のデータのやりとりが可能となり、居ながらにして各種情報を共有化できる環境が普及している。
前記状態情報の例として在席状態を取り上げてみると、その環境を利用し、各クライアント端末の利用者の在席状態をサーバ機で一元管理し、クライアント端末にその情報を参照する機能を設けることにより、居ながらにして他の利用者の在席状態の確認が行える在席状態管理システムが提案されている。
【０００３】
このような在席管理システムの一例が、特開平８−８７６８５号公報に開示されている。
その構成は、複数の端末をネットワークで接続したシステムであり、サーバ機で各クライアント端末の利用者の在席状態を一元管理しているものである。
そして、在席状態の変更が発生した場合、各クライアント端末の利用者は自状態設定部を通じて、サーバ機上の在席状態情報の更新を行う。サーバ機ではその当該利用者の在席状態を変更するとともに、接続されている全クライアント端末に対して、その利用者の在席状態を伝送している。
【０００４】
【発明が解決しようとする課題】
このような従来の技術では、利用者の必要の有無に関わらず無条件に全クライアント端末に対して状態情報が伝送されるため、無駄な伝送処理が発生する。また、各クライアント端末への状態情報の伝送処理がすべてサーバ機へ集中するため、サーバ機の負荷が高くなる。このため、更新処理が頻発したり、他の処理が重なると、処理待ちが発生し、状態情報が変化しているにも関わらず、その利用者の状態情報をリアルタイムに確認できないことがあった。
【０００５】
【課題を解決するための手段】
上記の課題は、状態情報更新時にサーバ機に接続されている全クライアント端末に対して無条件に状態情報を伝送していること、及び、その伝送処理をサーバ機で一括して行っていることに起因している。
本発明では、状態情報を更新した際に、関連付けられている要求データをクライアント端末に送出することにより、クライアント端末から直接他のクライアント端末へ状態情報を伝送することができるようにする。
【０００６】
これにより、状態情報の無駄な伝送を防止できるとともに、サーバ機の負荷を軽減することが可能となる。即ち、サーバ機と複数の特定されたクライアント端末を含むネットワークシステムにおいて、サーバ機は、クライアント端末から送出されてきた当該クラアイント端末の第１の利用者が状態情報の参照を希望する第２の利用者を特定する識別情報と当該第２の利用者の状態情報の変化を通知する通知条件とを含む要求データ設定情報を受信すると、前記要求データ設定情報に含まれる通知条件と前記第１の利用者を特定する識別情報とを対応づけて要求データを生成し、生成した要求データと前記要求データ設定情報に含まれる第２の利用者を特定する識別情報と対応づけて記憶しておく要求データ記憶部と、クライアント端末から送出されてきた当該クライアント端末の第２の利用者の状態情報を受信すると、前記要求データ記憶部から当該クライアント端末の第２の利用者を特定する識別情報に対応づけて記憶されている要求データを取得して当該クライアント端末に送出する要求データ送出部とを備え、クライアント端末は、入力手段を介して入力された当該クライアント端末の第２の利用者の状態情報と当該クライアント端末の第２の利用者を特定する識別情報とをサーバ機に送出する状態情報通知部と、前記第２の利用者の状態情報をサーバ機に送出したことに応じて、サーバ機から送出されてきた要求データを受信する要求データ取得部と、前記状態情報通知部にて入力された当該クライアント端末の第２の利用者の状態情報と前記要求データ取得部にて受信した前記要求データに含まれる状態情報の変化を通知する通知条件とが一致した場合に、前記要求データに含まれる前記一致した状態情報の変化を通知する通知条件に対応づけて記憶されている第１の利用者を特定する識別情報に対応づけられるクライアント端末に前記入力された第２の利用者の状態情報を直接伝送する状態情報配信部とを備えたことを特徴とする。
【０００７】
【発明の実施の形態】
在席状態管理システムを例に本発明の実施例を説明する。
本発明の実施例の構成を図１に示す。
本構成は、複数のクライアント端末20,30 と、それらを接続するサーバ機10とからなり、各クライアント端末20,30 およびサーバ機10はＬＡＮ(L1)で接続されている。
【０００８】
サーバ機10は、在席状態管理テーブル11と在席状態情報管理部12を有する。
在席状態管理テーブル11は、図２に示すように、各クライアント端末20,30 の利用者の在席状態情報40と各利用者に関連付けて管理されている要求データ50とを蓄積している。
在席状態情報40は、以下の項目を管理している。
【０００９】

【００１０】

【００１１】

【００１２】

【００１３】

【００１４】

在席状態情報管理部12は、前記在席状態管理テーブル11の管理及び各利用者の在席状態情報40（要求データ50を含む）の送受信を行う。
【００１５】
各クライアント端末20、30 は、相手状態表示部22,32 と自状態設定部21,31 、さらにコミュニケーション実行部23,33 を有する。
相手状態表示部22,32 は、サーバ機10で管理されている在席状態情報40を取得して希望する相手の在席状態42を表示する機能および要求データ50を設定する機能、在席状態確認後のコミュニケーションの実行をコミュニケーション実行部23,33 へ依頼する機能を有する。
【００１６】
自状態設定部21,31 は、自分の在席状態の表示および変更を行う利用者インターフェースと自状態変更時の変更情報をサーバ機10に通知する機能を有する。
コミュニケーション実行部23,33 は、相手状態表示部22,32 からの依頼を受けて、電話／メール／ＦＡＸなどの各種コミュニケーション手段を実行する機能を有する。
【００１７】
図３は各クライアント端末20、30 での自状態設定部21,31 および相手状態表示部22,32 、コミュニケーション実行部23,33 の画面例である。
画面61は、在席状態管理システムの各種操作のメニューが表示されている。メニュー名をマウスなどにより選択することにより、さらに下位のメニューや詳細操作画面が表示される。
【００１８】
画面62は、コミュニケーション手段を選択するメニューであり、希望するコミュニケーション手段をマウスなどで選択することにより、相手状態表示部22,32 を通じてコミュニケーション実行部が起動される。なお、画面61のメニューの中の [Communication]を選択しても同様の操作が行える。
画面63は、相手状態表示部22,32 により参照相手の在席状態が表示される画面であり、参照相手として登録されている利用者毎にその利用者名41と在席状態42を表す絵及びメモ43の先頭行が表示されている。また、参照相手をマウスなどで選択することにより、メモ43に設定された内容を先頭行だけでなくすべてを参照することができる。画面下のＮＥＷボタン66は表示されている在席状態表示を最新状態にすることを指示するものである。画面67は、最後に最新状態を参照した時刻を表示している。
【００１９】
画面64は、自状態設定部21,31 で自状態の表示／更新を行う際のインターフェース画面であり、右側の在席／不在などの在席状態を表す言葉の左にある○印をマウスなどにより選択することにより、現時点の自分の在席状態を設定する。在席状態の設定により、在席状態42の登録／更新を待ち、設定された状態を表す絵が左側に表示される。
【００２０】
画面65は、利用者が自分のスケジュールなどのメモ43を入力する画面であり、メモ登録ボタン68により画面65で設定したメモ43の登録／更新を行う。
図５は、クライアント端末20,30 上にある在席状態表示リスト24,34 の例である。在席状態表示リストは、自情報71から相手在席状態参照リスト72からなる。
自情報71には、以下の情報が管理されている。
【００２１】

【００２２】

【００２３】

【００２４】

【００２５】

詳細な説明に入る前に、図４に基づいて、本システムの情報伝送手順について説明する。
図４では、クライアント端末Ａ20の利用者が、クライアント端末Ｂ30の利用者を参照する場合について説明する。
【００２６】
本システムは、大きく下記の２つの機能に大別される。
１．相手状態参照機能 400
２．自状態更新機能 401
まず、相手状態参照機能400 から説明する。
相手状態参照機能400 は、大きく３つの機能から構成される。
【００２７】
（１）在席状態参照機能 410
（２）要求データ設定機能 450
（３）コミュケーション実行依頼機能 460
〔在席状態参照機能 410〕
在席状態参照には、以下の３パターンがある。
【００２８】
▲１▼ 初回参照 420
▲２▼ 最新状態参照 430
▲３▼ 状態自動通知 440
＜初回参照 420＞
参照する側のクライアント端末Ａ20の利用者は、クライアント端末Ｂ30の利用者を参照することを申請することにより、相手状態表示部22から参照相手登録要求421 をサーバ機10の在席状態情報管理部12に送出する。サーバ機10の在席状態情報管理部12は、クライアント端末Ａ20からの要求を受け、クライアント端末Ｂ30の利用者の要求データ50にクライアント端末Ａ20の利用者に関する情報を登録する（参照相手登録422)と同時に、クライアント端末Ｂの利用者の在席状態情報40および要求データ50をクライアント端末Ａ20の相手状態表示部22に送出する。クライアント端末Ａ20は、サーバ機10の在席状態情報管理部12から送出されてきた在席状態情報40および要求データ50を受け、クライアント端末Ｂ30の利用者の在席状態を表示する（参照相手状態表示423)。
【００２９】
登録した参照相手は、図３の画面63に、参照時点の在席状態が表示される（但し、前項（２）の状態自動通知機能を使用している場合は、常に最新状態が表示されている）。
＜最新状態参照 430＞
参照側のクライアント端末Ａ20の利用者がクライアント端末Ｂ30の利用者など参照相手登録422 を行っている利用者の最新の在席状態を参照する場合、図３の画面中央下のＮＥＷボタン66をマウスなどでクリックすることにより、相手状態表示部22から最新状態表示要求431 がサーバ機10の在席状態情報管理部12に送出される。サーバ機10の在席状態情報管理部12は、クライアント端末Ａ20からの要求を受け、登録されている要求データ50に基づいて、クライアント端末Ｂ30の利用者を含む登録されている全参照相手の在席状態情報40を在席状態管理テーブル11から取り出し、クライアント端末Ａ20の相手状態表示部22に送出する（参照相手状態送出432)。クライアント端末Ａ20の相手状態表示部22は、サーバ機10の在席状態情報管理部12から送出されてきた在席状態情報40を受け、クライアント端末Ａ20の全参照相手の在席状態を再表示する（参照相手状態表示433)。
＜状態自動通知 440＞
参照相手登録を行った際に、その後の参照相手の在席状態の変化に応じて、通知するレベルを指定しておくことにより（要求データ設定 450）、クライアント端末Ｂ30の利用者が在席状態情報40を更新した場合に、要求データ50に基づいて、クライアント端末Ａ20に更新内容を送出することができる。これは、参照される側のクライアント端末Ｂ30の利用者が自状態を変更することにより、自状態設定部31がサーバ機10へ自状態更新通知471 を発行し、通知を受けとったサーバ機10の在席状態情報管理部12が、クライアント端末Ｂ30の利用者の在席状態情報40を更新する（在席状態情報更新472)とともに、クライアント端末Ｂ30の自状態設定部31に要求データ50が送出されてくる（要求データ送出473)ことにより実現する。
【００３０】
クライアント端末Ｂ30の自状態設定部31はサーバ機10から送出されてくる要求データ50を基に、在席状態の更新を通知すべき利用者を選択し（要求データ確認 441）、この場合であれば、クライアント端末Ａ20の相手状態表示部22にクライアント端末Ｂ30の利用者の在席状態情報40を送出する（状態更新通知442)。クライアント端末Ａ20の相手状態表示部22は、クライアント端末Ｂ30から送出されてきた在席状態情報40に基づいて、クライアント端末Ｂ30の利用者の在席状態を再表示する（状態更新通知表示443)。
〔要求データ設定機能 450〕
在席状態を参照する相手を登録した後、参照相手の在席状態が更新された時に自動的に通知されるようにすることにより、設定相手の状態変化をリアルタイムに知ることが可能となる。クライアント端末Ａ20の利用者が、参照相手のクライアント端末Ｂ30の利用者が在席状態が更新された時の通知レベルを設定すると、相手状態表示部22は要求データ設定451 をサーバ機10の在席状態情報管理部12に送出する。サーバ機10の在席状態情報管理部12は要求を受け、クライアント端末Ｂ30の利用者に関連づけて要求データ50に申請された通知レベルを設定する（要求データ登録452)。この要求データ50に基づいて、前項（１）の▲３▼項の状態自動通知440 が行われる。
〔コミュニケーション実行依頼機能 460〕
在席状態を確認した後は、その状態に応じて、電話、電子メール、ＦＡＸ等のコミュニケーションを行う。クライアント端末Ａ20の利用者は、クライアント端末Ｂ30の利用者の在席状態を確認後、図３の画面61の[Communication] あるいは画面62のコミュニケーションボタンによりコミュニケーション手段を選択することにより、例えば電話を選択すると、クライアント端末Ｂ30の利用者が予め登録しているコミュニケーション情報45から電話番号46を取得し、コミュニケーション実行部23に実行を依頼する（コミュニケーション実行要求461)。これにより、コミュニケーション実行部23が起動され、クライアント端末Ｂ30の利用者に電話を掛けることができる（コミュニケーション受信462)。
【００３１】
次に、自状態更新機能について説明する。
自状態更新機能は、大きく２つの機能から構成される。
（１）在席状態更新機能 470
（２）在席状態変更通知機能 480
〔在席状態更新機能 470〕
在席状態更新機能については、被参照側のクライアント端末Ｂ30の利用者を起点に説明する。
【００３２】
クライアント端末Ｂ30の利用者は、在席状態が変われば、図３の画面64の自状態更新画面で自状態の変更を行うことにより、自状態設定部21から自状態更新通知471 をサーバ機10の在席状態情報管理部12に送出する。サーバ機10の在席状態情報管理部12では通知を受け、クライアント端末Ｂ30の利用者の在席状態情報40を更新する（在席状態情報更新 472）とともに、関連づけて管理されている要求データ50をクライアント端末Ｂ30に送出する（要求データ送出 473）。
〔在席状態変更通知機能 480〕
クライアント端末Ｂ30の自状態設定部31は、サーバ機10の在席状態情報管理部12から送出されてきた要求データ50を基に、自状態の変更を通知すべき利用者を選択し（要求データ確認 481）、本例ではクライアント端末Ａ20に対して、在席状態情報40を直接送出する（状態更新通知 482）。クライアント端末Ａ20の相手状態表示部22では、クライアント端末Ｂ30の自状態設定部31から送出されてきた在席状態情報40を基に、参照相手の最新状態を再表示する（状態更新通知表示 483)。これは、相手状態参照機能410 の中の状態自動通知440 と連動している機能である。
【００３３】
以上が、本システムの情報伝送手順である。
次に、各機能をフローチャートを使用して、詳細に説明する。
図６、図７、図８はクライアント端末20,30 の自状態設定部21,31 の処理を示すフローチャート、図９、図１０、図１１はクライアント端末20,30 の相手状態表示部22,32 の処理を示すフローチャート、図１２、図１３、図１４はサーバ機10の在席状態情報管理部12の処理を示す処理フローチャートである。
【００３４】
図１及び図４のクライアント端末Ａ20（参照側）の利用者は図２の在席管理テーブル中の奥山さん、クライアント端末Ｂ30（被参照側）の利用者は図２の在席管理テーブル中の鈴木さんを基本的に想定する。
〔在席状態情報管理部12の起動〕
サーバ機10上の在席状態情報管理部12は起動されると、バックアップファイル13に待避してある在席状態情報40および要求データ50を読み込んで、在席状態管理テーブル11に展開する（図１２ステップ 302）。その後、クライアント端末20,30 からの要求を待つ（図１２ステップ 303）。反対に、終了が指示されると、在席状態管理テーブル11の内容をバックアップファイル13に保存して終了する（図１２ステップ 304,305）。
〔自状態設定部21,31 の起動〕
クライアント端末Ａ20を例にして説明する。クライアント端末Ａ20の自状態設定部21は起動されると、まず自利用者名を取得するため、図５の在席状態表示リスト24中の自情報71の[DIRNAME=]に設定された値（本例では "奥山敏" ）を読み込む。ここで在席状態表示リスト24に自利用者名が設定されていなければ、利用者に入力を促す画面を表示する（図６ステップ 102）。自利用者名を取得すると、これをパラメータにしてサーバ機10上の在席状態情報管理部12に自状態の最新の在席状態情報40を要求する（図６ステップ 103）。サーバ機10の在席状態情報管理部12は、その要求を受けて、渡されてきた利用者名をキーにして、在席状態管理テーブル11からクライアント端末Ａ20の利用者（奥山さん）の在席状態情報40を取得し、クライアント端末Ａ20に送出する（図１２ステップ 307,308）。クライアント端末20の自状態設定部21は、サーバ機10から送出されてきた在席状態情報40を基にクライアント端末Ａ20の利用者（奥山さん）の在席状態を表示する（図６ステップ 104,105）。この際、サーバ機10の在席状態管理テーブル11にクライアント端末Ａ20の利用者（奥山さん）の在席状態情報40が無ければ、初期値（在席状態42は "在席" 、他情報は無し）を設定して、自状態の新規登録をサーバ機10上の在席状態情報管理部12へ要求する（図６ステップ 104,106）と同時に、自状態を表示する（図６ステップ 107）。サーバ機10の在席状態情報管理部12は、この要求を受け、在席状態管理テーブル11に在席状態情報40を追加する（図１２ステップ 309,310）。その後、クライアント端末20の自状態設定部21は、自状態の更新を待つ（図６ステップ 108）。
【００３５】
上記操作の画面例が図３の画面64である。この例は、クライアント端末Ａ20の画面であり、奥山さんが自利用者として登録されている。画面64にはクライアント端末Ａ20の利用者である奥山さんの名前と在席状態が表示されている。在席状態は、在席状態種別の左横の○をマウスなどでポインティングすることで設定される。在席状態種別の左横の絵は、設定された在席状態に応じて表示される。
〔相手状態表示部22,32 の起動〕
相手状態表示部22,32 が起動されると、クライアント端末20,30 に保存されている在席状態表示リスト24,34 を読み込む（図９ステップ 202）。在席状態表示リスト24,34 中の相手在席状態参照リスト72（図５）と、自利用者名、自クライアント端末20,30 のネットワークアドレスをパラメータにして相手状態参照要求をサーバ機10に送出する（図９ステップ 203）。サーバ機10上の在席状態情報管理部12は、渡された参照相手利用者名で在席状態管理テーブル11の参照相手の利用者に関連付けられた要求データ50を検索し、自利用者名が登録されているかを確認する（図１３ステップ 314,315,317）。自利用者名が登録されていれば、自クライアント端末20,30 のネットワークアドレス52を更新し（図１３ステップ 318,321）、登録されていなければ、要求データ50欄に自利用者名、自クライアント端末20,30 のネットワークアドレス52を追加する（図１３ステップ 318-319）。さらに、参照相手の在席状態情報40を仮領域にセットする（図１３ステップ 320,323）。相手在席状態参照リスト72に登録されている参照相手全員の処理が完了したことを確認して（図１３ステップ 315）、仮領域にセットされた参照相手の在席状態情報40をクライアント端末20,30 に送出する（図１３ステップ 316）。クライアント端末20,30 の相手状態表示部22、32 は、サーバ機10 から送出された在席状態情報40により各参照相手の在席状態を表示する（図９ステップ 204）。この表示例が図３の画面63である。各相手の様子が相手の名前（図５の[name=] で設定された名前）とともに絵（図５の[args=] で設定された位置および[color=]で設定された色）で示されて表示される。在席状態は、文字で表示することも可能である。名前の下には、各利用者が入力したメモ43の内容の先頭行が表示されている。各利用者のメモ43のすべてを参照したい場合は相手をマウスなどで選択することにより、その上にホップアップ表示される（図１１ステップ 235）。
〔在席状態更新機能 470〕
一方参照された利用者、本例ではクライアント端末Ｂ30の利用者（鈴木さん）が在席状態を変更した場合、自状態設定部31はサーバ機10の在席状態情報管理部12に自状態更新通知471 を送出する（図６ステップ 108、図７ステップ 111）。サーバ機10の在席状態情報管理部12は通知を受け、クライアント端末Ｂ30の利用者（鈴木さん）の在席状態情報40を更新するとともに（図１２ステップ 311-312）、クライアント端末Ｂ30の利用者（鈴木さん）に関連付けられて管理されている要求データ50をクライアント端末30に送出する（図１２ステップ 313）。
〔在席状態変更通知 480〕
クライアント端末Ｂ30の自状態設定部31は、サーバ機10の在席状態情報管理部12から送出されてきたクライアント端末Ｂ30の利用者（鈴木さん）の要求データ50を受取ると（図７ステップ 112）、まずネットワークアドレス52が登録されているかを確認し（図７ステップ 115）、登録されていなければ更新内容の送付対象とせず、登録されていればさらに状態通知フラグ53の内容を確認する（図７ステップ 116-117）。状態通知フラグ53の７ビット目のみの指定、つまり在席状態の自動変更のみであれば、在席状態情報40のみをクライアント端末Ａ20に送出し（図７ステップ 118-1）、状態通知フラグ53の０から４ビット目の指定、つまり特定の在席状態に変更になった場合に通知されるようになっていれば、在席状態情報40および通知メッセージをクライアント端末Ａ20に送出する（図７ステップ 118）。図２の例で説明すると、奥山さんは鈴木さんの在席状態の変更を自動更新するのみであり、田中さんは鈴木さんの在席状態のすべての変更をメッセージとともに通知してもらい、太田さんは鈴木さんが在席状態になったときのみメッセージとともに通知してもらうように設定されている。
【００３６】
クライアント端末Ａ20の相手状態表示部22は、クライアント端末Ｂ30からの通知を受信すると（図９ステップ 206）、クライアント端末Ｂ30の利用者（鈴木さん）の相手在席状態表示リスト72を更新し、更新内容を再表示する（図１０ステップ 216,217）。クライアント端末Ａ20の利用者が田中さんあるいは太田さんであった場合は、更新のみならず状態更新のメッセージを表示する（図１０ステップ 218-219）。
【００３７】
以上により、参照相手の在席状態の更新が自動的に、かつ、相手の状態変化に追従した表示が行え、なおかつ最小限の負荷で実現可能とする。
図３の画面65では、クライアント端末20、30 の利用者が自分の簡易スケジュールなど簡単なメモを書くことができるようになっている。この欄にスケジュールなどを入力し、画面上のメモ登録ボタン68を押すと、サーバ機10に送出される（図６ステップ 108、図７ステップ 111）。サーバ機10の在席状態情報管理部12は、送出されてきたメモの内容を在席状態管理テーブル11のメモ43欄に登録する（図１２ステップ 311,312）。このメモ43は、相手状態表示部22,32 により、参照者側の画面にも表示される。図３の画面63の相手状態表示画面で、参照相手利用者名の下に表示されているのがメモ43の先頭行である。メモの内容をすべて表示する場合は、参照したい利用者をマウスなどでクリックすることにより、メモ43の内容がホップアップ表示される（図１1 ステップ 235）。
〔最新状態参照 430〕
最新状態の表示は、図３の画面中央下のＮＥＷボタン66を押下することにより（図１１ステップ 227）、相手在席状態参照リスト72とともに、自利用者名および在席状態を最後に参照した時刻（図３の画面67）をパラメータにしてサーバ機10へ最新状態を要求する（図１１ステップ 228）。サーバ機10上の在席状態情報管理部12は、前記の相手の在席状態情報40の取得と同様のステップで、クライアント端末20,30 に相手在席状態参照リスト24、34 に登録されている参照相手全員の在席状態情報40を送出する（図１３ステップ 315-321）。この際、クライアント端末20,30 から送出された最後に参照した時刻（図３の画面67）と、各利用者の在席状態の設定日時44とを比較し（図１３ステップ 322）、各利用者の在席状態の設定日時44の方が大きい場合のみ、在席状態情報40を送出するようにし（図１３ステップ 323）、サーバ機10とクライアント端末20,30 間のデータの伝送量を削減することを可能にしている。
【００３８】
参考までに、本システムでの、相手状態参照機能22,32 で参照する利用者の登録および削除方法を述べる。
参照相手の登録は図３の画面61にあるメニュー[Awareness] を選択することにより行う。メニュー[Awareness] を開き、さらにメニューの中の [登録] を選択すると、サーバ機10に登録された利用者一覧が表示される。そこから参照したい利用者を選択する（図９ステップ 208,209）。選択が終了したら、選択した相手リストをサーバ機10に送出する（図９ステップ 210）。サーバ機10の在席状態情報管理部12は、送出されてきたデータを参照相手の在席状態情報40に要求データ50として追加する（図１３ステップ 314-323）。さらに、参照相手の在席状態情報40をクライアント端末20,30 に送出する（図１３ステップ 314 -323）。相手状態表示部22,32 は、サーバ機10より送出されてきた在席状態情報40を基に、参照相手の在席状態を画面63に表示する（図９ステップ 210）。
また削除は、図３の画面63に表示されている参照相手を選択し、メニュー [Awareness] を開き、さらにメニュー [削除] を選択することにより、削除する利用者名を自利用者名とともにサーバ機10に送出する（図９ステップ 208-210）。サーバ機10上の在席状態情報管理部12は、クライアント端末20,30 より送出されてきた削除する利用者名をキーに該当利用者の要求データ50を検索し、自利用者名のネットワークアドレス52を削除する（図１３ステップ 324-328）。
〔コミュニケーション実行依頼機能〕
参照相手の在席状態を確認したあと、その状態に応じてコミュニケーション手段を選択し、参照相手にアクセスすることがある。その際は、図３の画面63でアクセスしたい相手の絵を選択し、画面61の[Communication] から [電話] 、 [メール] 、 [ＦＡＸ] を選択する、ないしは、画面62のツールボタンにより [電話] 、 [メール] 、 [ＦＡＸ] を選択すると、選択した相手のコミュニケーション情報45（電話なら電話番号46、メールならメールアドレス47、ＦＡＸならＦＡＸ番号）を取得し、コミュニケーション種別とともに、コミュニケーション実行部23,33 に処理を依頼する（図９ステップ 211,212）。コミュニケーション実行部23,33 は、該当データを用いてコミュニケーションを実行する。
〔在席状態参照終了〕
在席状態参照を終了する際は、サーバ機に参照終了を通知し（図９ステップ 207、図１０ステップ 213、図１４ステップ 329-333）、相手在席状態参照リスト72に現在の参照相手を保存し終了する（図１０ステップ 214,215）。合わせて、自状態設定部21,31 も終了する。（図６ステップ 109-110）。
〔要求データ設定機能 450〕
相手状態参照時または参照登録後に、参照相手の在席状態に変更が発生した場合に、その更新内容の通知レベルを設定しておける。
【００３９】
図３の画面63で通知レベルを設定する相手を選択し、画面61の中の[Option]を選択し、その中のメニュー [通知レベルの設定] を選択すると（図１１ステップ 223）、通知レベル設定画面（図１５）が表示される（図１１ステップ 224）。通知レベル設定画面の例を図１５に示す。図１５の通知レベル設定画面に示す状態種別80,81 を選択することにより、あらゆる状態の変化を通知するか、特定の状態に変化したときのみ通知するのかが設定される。この設定内容をサーバ機10に送出することにより（図１１ステップ 225、226）、サーバ上の在席状態情報管理部12は、在席状態管理テーブル11の状態通知フラグ53を設定する（図１４ステップ 334,335）。この情報により、自状態設定部21,31 は、参照者の在席状態に変更が発生した場合に、更新内容を送出すべき利用者を特定している。
【００４０】
また、特定の状態に変更した時に通知すると指定した場合、在席状態の更新だけでなく、在席状態を更新したことがわかるように、在席状態に変更があった旨の通知メッセージを表示する（図１０ステップ 220）。通知メッセージの例を図１６に示す。
以上により、設定した条件に相手の状態が変わると、確実に認識することができる。
【００４１】
さらに、通知メッセージを表示する際に、図１６にあるようにコミュニケーションボタンも合わせて表示し、状態変化通知からすぐその相手に適当なコミュニケーションがとれるようにすることもできる。コミュニケーションボタンによりコミュニケーション実行依頼機能が起動される（図１０ステップ 221,222）。
コミュニケーション実行依頼機能については、前述と同様である。
〔簡易メッセージ機能〕
本例では、要求データ50に、簡易メッセージ54およびメッセージ通知条件55、メッセージ確認フラグ56を持たせることにより、相手の在席状態変更時に簡単なメッセージを送出することも可能としている。
【００４２】
図３の画面63で相手を選択後、画面61のメニュー[Option]を選択し、さらにメニュー [簡易メッセージ機能] を選択することにより、相手状態表示部22、32 は、選択した利用者に対して、既に設定した簡易メッセージがあるかを、サーバ機10に問い合わせる（図１１ステップ 230,231）。サーバ機10の在席状態情報管理部12は在席状態管理テーブル11の参照相手の要求データ50を検索し、簡易メッセージ54にメッセージが設定されているか確認する（図１４ステップ 336）。設定されていれば、その簡易メッセージ54をクライアント端末20,30 に送出する（図１４ステップ 337）。サーバ機10からの回答を受けたクライアント端末20,30 の相手状態表示部22,32 は、メッセージがあればそのメッセージを、無ければ初期値で図１７にあるような簡易メッセージ設定画面を表示する（図１１ステップ 232）。利用者がメッセージを入力ないしは変更し、表示条件を設定して送信ボタン93を操作すると、サーバ機10の在席状態情報管理部12に送信される（図１１ステップ 233,234）。サーバ機10の在席状態情報管理部12ではクライアント端末20,30 から送出されてきた簡易メッセージを在席状態管理テーブル11の該当利用者の要求データ50の中に格納する（図１４ステップ 338, 339 ）。被参照側で在席状態を変更すると、自状態設定部21,31 が在席状態更新通知をサーバ機10の在席状態情報管理部12に送出し、それによりサーバ機10から要求データ50が送出されてくる。自状態設定部21,31 は、メッセージ通知条件55が合うかを確認し（図８ステップ 119）、メッセージ通知条件が合えば簡易メッセージ54の内容を参照利用者名51とともに図１８のように表示する（図８ステップ 120）。
【００４３】
具体的な例を示すと、図１７の簡易メッセージ設定画面で田中さんが鈴木さんへ「資料、今日中にチェック下さい」というメッセージを、鈴木さんが "在席" 状態になった時に通知するよう設定している。これにより、図２の在席状態管理テーブル11の鈴木さんの要求データ50の中の簡易メッセージ54にメッセージの内容、メッセージ通知条件55の０ビット目に "１" が設定される。これにより鈴木さんが席に戻り在席状態を "在席" に変更すると、要求データ50に設定された簡易メッセージ54が図１８のように表示される。
【００４４】
以上により、相手の自状態変更にあわせてメッセージ表示が可能となる。
さらに、簡易メッセージ表示画面（図１８）に確認ボタン98を用意し、これを押すと、自状態設定部21,31 はサーバ機10にメッセージが既読状態であることを通知し、簡易メッセージ表示画面を消去する（図８ステップ 121,122,123）。サーバ機10の在席状態情報管理部12は通知を受けて、要求データ50のメッセージ確認フラグ56をオン（０ビット目に "１" を設定）にする（図１４ステップ 340,341）。利用者が再度同じ相手に簡易メッセージを設定しようとしたときには、相手状態表示部22,32 が前述したように設定されている簡易メッセージ内容とともに、メッセージ確認フラグ56の内容を確認し、既読かどうかも表示する（図１１ステップ 231,232）。図１７の簡易メッセージ設定画面において、既読92の左横の白四角が既読の場合は黒四角になる。
【００４５】
図１７の画面で、メッセージ内容を書き換えて送信93、または、書き換えずに再通知94を選択すると、メッセージ確認フラグ56をオフ（０ビット目に "０" を設定）にして（既読状態を未読状態に変更）、メッセージ内容とともにサーバ機10に送出される（図１１ステップ 233,234）。サーバ機10の在席状態情報管理部10は、送出されてきた情報に基づいて、要求データ50を更新する（図１４ステップ 339）。
【００４６】
以上により、設定した簡易メッセージを相手が見たかどうかの判別できる。
なお、クライアント端末20,30 側の自状態設定部21,31 ・相手状態表示部22, 32・コミュニケーション実行部23,33 の３つの処理は、同一アプリケーションとして１つのプログラムで包含されても良い。
サーバ機10上の在席状態情報管理部12についても、在席状態管理テーブル11の管理を行っているが、サーバ機10はファイル共用サーバとし、在席管理テーブル11をファイルとして扱い、在席状態情報管理部12の機能をクライアント端末20, 30の自状態設定部21,31 、相手状態表示部22,32 が行うようにしてもよい。
【００４７】
在席状態管理テーブル11の要求データ50についても、利用者の在席状態情報と同一レコード内に格納するようになっているが、要求データ50に利用者名41の項目を追加し、利用者名によって関連付けが可能とすることにより、在席状態情報40と要求データ50とを、別テーブルとして管理してもよい。
クライアント端末20,30 の利用者も、１台に１人ではなく、１台を複数で使用していてもよく、さらに、１人の利用者が特定のクライアント端末だけでなく、他のクライアント端末を使用しても、実施は可能である。
【００４８】
利用者からの要求データ50の申請についても、クライアント端末20,30 からの申請に限らず、システム導入時に利用者からの申請のあったものを設定しておくなど、申請の方式はクライアント端末に限定しない。
【００４９】
【発明の効果】
以上により、本発明では、サーバ機と複数の特定されたクライアント端末を含むネットワークシステムにおいて、各利用者の状態情報を共有化する際に、各利用者の状態情報と予め他の利用者からの申請で登録された要求データとを関連付けて管理しておくことにより、利用者の状態情報に更新された場合に、要求データを参照して、その要求データに応じて選択された他のクライアント端末に直接利用者の状態情報を伝送することを可能とする。
【００５０】
これにより、サーバ機の負荷を軽減しながら、相手の状態情報を適切に把握することが可能となる。
【図面の簡単な説明】
【図１】本発明の構成図
【図２】サーバ機の在席状態管理テーブルのレコードフォーマット例
【図３】自状態設定部および相手状態表示部の画面例
【図４】本システムの情報伝送手順を示す図
【図５】クライアント端末の在席状態表示リストの例
【図６】クライアント端末の自状態設定部の処理を示すフローチャート（その１）
【図７】クライアント端末の自状態設定部の処理を示すフローチャート（その２）
【図８】クライアント端末の自状態設定部の処理を示すフローチャート（その３）
【図９】クライアント端末の相手状態表示部の処理を示すフローチャート（その１）
【図１０】クライアント端末の相手状態表示部の処理を示すフローチャート（その２）
【図１１】クライアント端末の相手状態表示部の処理を示すフローチャート（その３）
【図１２】サーバ機の在席状態情報管理部の処理を示すフローチャート（その１）
【図１３】サーバ機の在席状態情報管理部の処理を示すフローチャート（その２）
【図１４】サーバ機の在席状態情報管理部の処理を示すフローチャート（その３）
【図１５】在席状態通知設定画面例
【図１６】相手在席状態更新時のメッセージ画面例
【図１７】簡易メッセージ設定画面例
【図１８】簡易メッセージ表示画面例[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an improvement of a network system for sharing information from a plurality of client terminals by using a common server machine, and in particular, sharing status information such as the presence status of each client terminal individual user, The present invention relates to an information sharing system for improving the efficiency of activities.
[0002]
[Prior art]
In recent years, with the spread of personal computers and the development of networks, it has become possible to exchange data between terminals, and an environment where various information can be shared while living has become widespread.
Taking the presence status as an example of the status information, use the environment, centrally manage the presence status of each client terminal user with a server machine, and provide a function to refer to the information on the client terminal Therefore, an attendance state management system that can confirm the presence state of another user while staying is proposed.
[0003]
An example of such an attendance management system is disclosed in Japanese Patent Laid-Open No. 8-87855.
The configuration is a system in which a plurality of terminals are connected via a network, and a server machine centrally manages the presence status of users of each client terminal.
When a change in the presence state occurs, the user of each client terminal updates the presence state information on the server machine through the own state setting unit. The server machine changes the presence status of the user and transmits the presence status of the user to all connected client terminals.
[0004]
[Problems to be solved by the invention]
In such a conventional technique, state information is unconditionally transmitted to all client terminals regardless of whether or not the user needs, and therefore wasteful transmission processing occurs. In addition, since all transmission processing of status information to each client terminal is concentrated on the server machine, the load on the server machine increases. For this reason, if update processing occurs frequently or other processing overlaps, processing wait occurs, and the status information of the user may not be confirmed in real time even though the status information has changed. .
[0005]
[Means for Solving the Problems]
The above problem is that the state information is unconditionally transmitted to all client terminals connected to the server machine when the state information is updated, and that the transmission process is performed collectively by the server machine. Due to
In the present invention, when the status information is updated, the associated request data is sent to the client terminal, so that the status information can be transmitted directly from the client terminal to another client terminal.
[0006]
As a result, useless transmission of status information can be prevented and the load on the server machine can be reduced. That is, in a network system including a server machine and a plurality of identified client terminals, The server machine transmits the identification information for identifying the second user that the first user of the client terminal wishes to refer to the status information and the change in the status information of the second user transmitted from the client terminal. When the request data setting information including the notification condition for notifying is received, the request data is generated by associating the notification condition included in the request data setting information with the identification information for identifying the first user. A request data storage unit that stores the requested data in association with identification information that identifies the second user included in the request data setting information, and a second of the client terminal sent from the client terminal. When the user status information is received, the request data stored in association with the identification information for identifying the second user of the client terminal from the request data storage unit. Acquires a request data generating portion for sending to the client terminal, Client terminal via input means Entered The client terminal Second User status Information and identification information for identifying the second user of the client terminal, To the server machine Send A status information notification unit to perform, The second User status information on the server machine Send According to what , Sa Machine Has been sent from Request data Receive Request data acquisition unit and the state information notification unit The input second of the client terminal User status information and Received by the request data acquisition unit Notification condition for notifying a change in status information included in the request data When If matches , Associated with the identification information for identifying the first user stored in association with the notification condition for notifying the change of the matched state information included in the request data The client terminal Entered second And a status information distribution unit that directly transmits user status information.
[0007]
DETAILED DESCRIPTION OF THE INVENTION
An embodiment of the present invention will be described by taking an attendance state management system as an example.
The configuration of an embodiment of the present invention is shown in FIG.
This configuration includes a plurality of

client terminals

20 and 30 and a server machine 10 connecting them, and each

client terminal

20 and 30 and the server machine 10 are connected via a LAN (L1).
[0008]
The server machine 10 includes an attendance state management table 11 and an attendance state information management unit 12.
As shown in FIG. 2, the presence status management table 11 stores the presence status information 40 of the users of the

client terminals

20 and 30 and request data 50 managed in association with each user. .
The presence status information 40 manages the following items.
[0009]

[0010]

[0011]

[0012]

[0013]

[0014]

The presence status information management unit 12 performs management of the presence status management table 11 and transmission / reception of presence status information 40 (including request data 50) of each user.
[0015]
Each

client terminal

20, 30 has a partner

state display unit

22, 32, a self state setting unit 21, 31, and further a

communication execution unit

23, 33.
The partner

status display units

22 and 32 acquire the presence status information 40 managed by the server machine 10 to display the desired partner's presence status 42 and set the request data 50. It has a function of requesting the

communication execution units

23 and 33 to execute communication after confirmation.
[0016]
The own state setting units 21 and 31 have a function of notifying the server machine 10 of a user interface for displaying and changing his / her presence state and change information when the own state is changed.
The

communication execution units

23 and 33 have a function of executing various communication means such as telephone / mail / FAX in response to requests from the partner

status display units

22 and 32.
[0017]
FIG. 3 is a screen example of the own state setting units 21 and 31, the partner

state display units

22 and 32, and the

communication execution units

23 and 33 in the

client terminals

20 and 30.
The screen 61 displays menus for various operations of the presence status management system. By selecting the menu name with the mouse etc., lower menus and detailed operation screens are displayed.
[0018]
The screen 62 is a menu for selecting a communication means. When the desired communication means is selected with a mouse or the like, the communication execution section is activated through the partner

status display sections

22 and 32. The same operation can be performed by selecting [Communication] in the menu of the screen 61.
The screen 63 is a screen on which the presence status of the reference partner is displayed by the partner

status display units

22 and 32, and is a picture showing the user name 41 and the presence status 42 for each user registered as the reference partner. And the first line of the memo 43 is displayed. Further, by selecting a reference partner with a mouse or the like, it is possible to refer not only to the first line but also to the contents set in the memo 43. The NEW button 66 at the bottom of the screen is used to instruct the displayed presence status display to be updated. The screen 67 displays the time when the latest state was last referenced.
[0019]
The screen 64 is an interface screen for displaying / updating the self status in the self status setting unit 21, 31. By selecting, the present attendance state is set. Depending on the setting of the presence state, registration / update of the presence state 42 is awaited, and a picture representing the set state is displayed on the left side.
[0020]
The screen 65 is a screen for the user to input the memo 43 such as his / her schedule, and the memo 43 set on the screen 65 is registered / updated by the memo registration button 68.
FIG. 5 is an example of the presence status display lists 24 and 34 on the

client terminals

20 and 30. The presence status display list includes self information 71 and a partner presence status reference list 72.
The own information 71 manages the following information.
[0021]

[0022]

[0023]

[0024]

[0025]

Prior to detailed description, an information transmission procedure of the present system will be described with reference to FIG.
FIG. 4 illustrates a case where the user of the client terminal A20 refers to the user of the client terminal B30.
[0026]
This system is roughly divided into the following two functions.
1. Opponent status reference function 400
2. Self-state update function 401
First, the partner state reference function 400 will be described.
The partner status reference function 400 is mainly composed of three functions.
[0027]
(1) Attendance status reference function 410
(2) Request data setting function 450
(3) Communication execution request function 460
[Attendance status reference function 410]
There are the following three patterns for presence status reference.
[0028]
▲ 1 ▼ First time reference 420
▲ 2 ▼ Refer to the latest status 430
(3) Automatic status notification 440
<First reference 420>
The user of the client terminal A20 on the referencing side makes an application for referring to the user of the client terminal B30, so that the reference partner registration request 421 is sent from the partner state display unit 22 to the presence state information management unit of the server machine 10. Send to 12. In response to a request from the client terminal A20, the presence state information management unit 12 of the server machine 10 registers information about the user of the client terminal A20 in the request data 50 of the user of the client terminal B30 (reference partner registration 422). At the same time, the presence status information 40 and request data 50 of the user of the client terminal B are sent to the partner status display unit 22 of the client terminal A20. The client terminal A20 receives the presence status information 40 and the request data 50 sent from the presence status information management unit 12 of the server machine 10, and displays the presence status of the user of the client terminal B30 (reference partner status) Display 423).
[0029]
The registered reference partner displays the presence status at the time of reference on the screen 63 in FIG. 3 (however, if the automatic status notification function in (2) above is used, the latest status is always displayed). )
<Refer to latest status 430>
When the user of the client terminal A20 on the reference side refers to the latest attendance state of the user who is performing reference partner registration 422, such as the user of the client terminal B30, the NEW button 66 at the bottom center of the screen in FIG. When the user clicks, for example, the latest status display request 431 is sent from the partner status display unit 22 to the presence status information management unit 12 of the server machine 10. The presence status information management unit 12 of the server machine 10 receives a request from the client terminal A20 and, based on the registered request data 50, the presence of all registered reference partners including the user of the client terminal B30. The seat status information 40 is extracted from the presence status management table 11 and sent to the partner status display unit 22 of the client terminal A20 (reference partner status sending 432). The partner status display unit 22 of the client terminal A20 receives the presence status information 40 sent from the presence status information management unit 12 of the server machine 10, and redisplays the presence status of all reference partners of the client terminal A20. (Reference partner status display 433).
<Automatic status notification 440>
When the reference partner is registered, the level of notification is specified according to the subsequent change in the presence status of the reference partner (request data setting 450), so that the user of the client terminal B30 is in the presence state. When the information 40 is updated, the updated contents can be sent to the client terminal A20 based on the request data 50. This is because when the user of the client terminal B30 on the reference side changes its own state, the own state setting unit 31 issues the own state update notification 471 to the server machine 10, and the server machine 10 that has received the notification The presence status information management unit 12 updates the presence status information 40 of the user of the client terminal B30 (attention status information update 472), and the request data 50 is sent to the own status setting unit 31 of the client terminal B30. This is realized by (request data transmission 473).
[0030]
The own state setting unit 31 of the client terminal B30 selects a user to be notified of the update of the presence state based on the request data 50 sent from the server machine 10 (request data confirmation 441). For example, the presence status information 40 of the user of the client terminal B30 is sent to the partner status display unit 22 of the client terminal A20 (status update notification 442). The partner status display unit 22 of the client terminal A20 redisplays the presence status of the user of the client terminal B30 based on the presence status information 40 sent from the client terminal B30 (status update notification display 443).
[Request data setting function 450]
After registering a partner who refers to the presence state, it is possible to know in real time the state change of the set partner by automatically notifying when the presence state of the reference partner is updated. When the user of the client terminal A20 sets the notification level when the user of the client terminal B30 as the reference partner is updated, the partner status display unit 22 sets the request data setting 451 to the presence of the server machine 10. It is sent to the status information management unit 12. The presence status information management unit 12 of the server machine 10 receives the request and sets the applied notification level in the request data 50 in association with the user of the client terminal B30 (request data registration 452). On the basis of the request data 50, the state automatic notification 440 of the item (3) in the previous item (1) is performed.
[Communication execution request function 460]
After confirming the presence state, communication such as telephone, e-mail, FAX is performed according to the state. After confirming the presence of the user of the client terminal B30, the user of the client terminal A20 selects, for example, a telephone by selecting a communication means using the [Communication] on the screen 61 in FIG. Then, the user of the client terminal B30 acquires the telephone number 46 from the communication information 45 registered in advance, and requests the communication execution unit 23 to execute it (communication execution request 461). As a result, the communication execution unit 23 is activated, and the user of the client terminal B30 can be called (communication reception 462).
[0031]
Next, the self-state update function will be described.
The self-state update function is mainly composed of two functions.
(1) Attendance status update function 470
(2) Attendance status change notification function 480
[Attendance status update function 470]
The presence status update function will be described starting from the user of the client terminal B30 on the referenced side.
[0032]
When the user's presence status changes, the user of the client terminal B30 changes his / her state on the own state update screen of the screen 64 of FIG. Is sent to the presence status information management unit 12. The presence status information management unit 12 of the server machine 10 receives the notification, updates the presence status information 40 of the user of the client terminal B30 (attention status information update 472), and requests data 50 managed in association with it. Is transmitted to the client terminal B30 (request data transmission 473).
[Attendance status change notification function 480]
The own state setting unit 31 of the client terminal B30 selects a user who should be notified of the change of own state based on the request data 50 sent from the presence state information management unit 12 of the server machine 10 (request data). Confirmation 481), in this example, the presence status information 40 is sent directly to the client terminal A20 (status update notification 482). The partner status display unit 22 of the client terminal A20 redisplays the latest status of the reference partner based on the presence status information 40 sent from the own status setting unit 31 of the client terminal B30 (status update notification display 483). . This is a function linked to the state automatic notification 440 in the partner state reference function 410.
[0033]
The above is the information transmission procedure of this system.
Next, each function will be described in detail using a flowchart.
6, 7, and 8 are flowcharts showing the processing of the own state setting units 21 and 31 of the

client terminals

20 and 30, and FIGS. 9, 10, and 11 are the partner

state display units

22 and 32 of the

client terminals

20 and 30. FIG. 12, FIG. 13, FIG. 14 are processing flowcharts showing processing of the presence status information management unit 12 of the server machine 10.
[0034]
The user of the client terminal A20 (reference side) in FIGS. 1 and 4 is Mr. Okuyama in the presence management table of FIG. 2, and the user of the client terminal B30 (reference side) is in the presence management table of FIG. Basically, Mr. Suzuki is assumed.
[Activation of presence status information management unit 12]
When the presence status information management unit 12 on the server machine 10 is activated, the presence status information 40 and the request data 50 saved in the backup file 13 are read and expanded in the presence status management table 11 (see FIG. 12 Step 302). Thereafter, it waits for a request from the client terminals 20 and 30 (step 303 in FIG. 12). On the contrary, when the end is instructed, the contents of the presence status management table 11 are stored in the backup file 13 and the process ends (

steps

304 and 305 in FIG. 12).
[Activation of self-status setting unit 21, 31]
A description will be given by taking the client terminal A20 as an example. When the own state setting unit 21 of the client terminal A20 is activated, first, in order to obtain the own user name, the value set in [DIRNAME =] of the own information 71 in the presence state display list 24 of FIG. In this example, "Satoshi Okuyama") is read. Here, if the user name is not set in the presence status display list 24, a screen prompting the user to input is displayed (step 102 in FIG. 6). When the own user name is acquired, this is used as a parameter to request the latest attendance state information 40 in the present state from the attendance state information management unit 12 on the server machine 10 (step 103 in FIG. 6). Upon receiving the request, the presence status information management unit 12 of the server machine 10 uses the passed user name as a key and the presence of the user (Mr. Okuyama) of the client terminal A20 from the presence status management table 11. The seat status information 40 is acquired and sent to the client terminal A20 (

steps

307 and 308 in FIG. 12). The own state setting unit 21 of the client terminal 20 displays the presence state of the user of the client terminal A20 (Mr. Okuyama) based on the presence state information 40 sent from the server machine 10 (steps 104 and 105 in FIG. 6). . At this time, if there is no presence status information 40 of the user (Mr. Okuyama) of the client terminal A20 in the presence status management table 11 of the server machine 10, the initial value (the presence status 42 is "attended", other information is (None) is set, and a new registration of the own state is requested to the attendance state information management unit 12 on the server machine 10 (steps 104 and 106 in FIG. 6), and at the same time, the own state is displayed (step 107 in FIG. 6). Upon receiving this request, the presence status information management unit 12 of the server machine 10 adds the presence status information 40 to the presence status management table 11 (

steps

309 and 310 in FIG. 12). Thereafter, the own state setting unit 21 of the client terminal 20 waits for an update of the own state (step 108 in FIG. 6).
[0035]
A screen example of the above operation is a screen 64 in FIG. This example is the screen of the client terminal A20, and Mr. Okuyama is registered as the own user. On the screen 64, the name and presence status of Mr. Okuyama who is the user of the client terminal A20 are displayed. The presence status is set by pointing the left side of the presence status type with a mouse. The picture on the left of the presence status type is displayed according to the set presence status.
[Activation of partner status display units 22 and 32]
When the partner

status display units

22 and 32 are activated, the presence status display lists 24 and 34 stored in the

client terminals

20 and 30 are read (step 202 in FIG. 9). Attendance status reference list 72 (Fig. 5) in the

display list

24, 34, the user name, and the network address of the

client terminal

20, 30 are used as parameters for the partner status reference request to the server 10. It is sent out (step 203 in FIG. 9). The attendance status information management unit 12 on the server machine 10 searches the request data 50 associated with the reference partner user in the presence status management table 11 with the passed reference partner user name, and finds the own user name. Is registered (

steps

314, 315, and 317 in FIG. 13). If the own user name is registered, the network address 52 of the

own client terminal

20 or 30 is updated (

steps

318 and 321 in FIG. 13). If not registered, the own user name and own client terminal are entered in the request data 50 column. Network addresses 52 of 20,30 are added (steps 318-319 in FIG. 13). Further, the presence status information 40 of the reference partner is set in the temporary area (steps 320 and 323 in FIG. 13). After confirming that all of the reference partners registered in the partner presence status reference list 72 have been processed (step 315 in FIG. 13), the presence status information 40 of the reference partner set in the temporary area is stored in the client terminal 20. , 30 (step 316 in FIG. 13). The partner

status display units

22 and 32 of the

client terminals

20 and 30 display the presence status of each reference partner based on the presence status information 40 sent from the server machine 10 (step 204 in FIG. 9). This display example is the screen 63 of FIG. Each partner's appearance is indicated by a picture (the position set by [args =] and the color set by [color =] in Fig. 5) together with the name of the opponent (name set by [name =] in Fig. 5). Displayed. The presence status can also be displayed in text. Below the name, the first line of the contents of the memo 43 input by each user is displayed. When it is desired to refer to all of the memos 43 of each user, a partner is selected with a mouse or the like, and a hop-up display is performed thereon (step 235 in FIG. 11).
[Attendance status update function 470]
On the other hand, when the user referred to, in this example, the user of the client terminal B30 (Mr. Suzuki) changes the presence state, the own state setting unit 31 updates the present state to the presence state information management unit 12 of the server machine 10. Notification 471 is sent out (step 108 in FIG. 6 and step 111 in FIG. 7). The presence status information management unit 12 of the server machine 10 receives the notification, updates the presence status information 40 of the user (Mr. Suzuki) of the client terminal B30 (steps 311-312 in FIG. 12), and uses the client terminal B30. Request data 50 managed in association with the user (Mr. Suzuki) is sent to the client terminal 30 (step 313 in FIG. 12).
[Attendance status change notification 480]
When the own state setting unit 31 of the client terminal B30 receives the request data 50 of the user (Mr. Suzuki) of the client terminal B30 sent from the presence state information management unit 12 of the server machine 10 (step 112 in FIG. 7). First, it is confirmed whether the network address 52 is registered (step 115 in FIG. 7). If it is not registered, the update contents are not sent, and if it is registered, the contents of the status notification flag 53 are further confirmed (FIG. 7). 7 Step 116-117). If only the seventh bit of the status notification flag 53 is specified, that is, only the presence status is automatically changed, only the presence status information 40 is sent to the client terminal A20 (step 118-1 in FIG. 7). If the notification is made when the 0th to 4th bits are specified, that is, when a change is made to a specific presence status, presence status information 40 and a notification message are sent to the client terminal A20 (FIG. 7). Step 118). In the example of Fig. 2, Mr. Okuyama only updates the changes in Mr. Suzuki's presence status, and Mr. Tanaka is notified of all changes in Mr. Suzuki's presence status with a message. Is set to be notified with a message only when Mr. Suzuki is present.
[0036]
Upon receiving the notification from the client terminal B30 (FIG. 9, step 206), the partner status display unit 22 of the client terminal A20 updates the partner presence status display list 72 of the user (Mr. Suzuki) of the client terminal B30, and updates it. The contents are displayed again (

steps

216 and 217 in FIG. 10). When the user of the client terminal A20 is Mr. Tanaka or Mr. Ota, a status update message is displayed in addition to the update (steps 218-219 in FIG. 10).
[0037]
As described above, the presence status of the reference partner can be updated automatically and in accordance with the status change of the partner, and can be realized with a minimum load.
In the screen 65 of FIG. 3, the user of the

client terminals

20 and 30 can write a simple memo such as his simple schedule. When a schedule or the like is entered in this field and the memo registration button 68 on the screen is pressed, it is sent to the server machine 10 (step 108 in FIG. 6, step 111 in FIG. 7). The presence status information management unit 12 of the server machine 10 registers the contents of the sent memo in the memo 43 column of the presence status management table 11 (

steps

311 and 312 in FIG. 12). The memo 43 is also displayed on the screen on the referrer side by the partner

status display units

22 and 32. In the partner status display screen of the screen 63 in FIG. 3, the first line of the memo 43 is displayed below the reference partner user name. To display all the contents of the memo, the user wants to refer to the contents of the memo 43 by clicking on the user with a mouse or the like (step 235 in FIG. 11).
[Refer to latest status 430]
The latest status is displayed by pressing the NEW button 66 at the bottom center of the screen in FIG. 3 (step 227 in FIG. 11) and referring to the user's user name and presence status last together with the partner presence status reference list 72. Using the time (screen 67 in FIG. 3) as a parameter, the server machine 10 is requested for the latest state (step 228 in FIG. 11). The presence status information management unit 12 on the server machine 10 is registered in the partner presence status reference lists 24 and 34 in the

client terminals

20 and 30 in the same steps as the acquisition of the partner presence status information 40. The presence status information 40 of all the reference partners who are present is transmitted (steps 315-321 in FIG. 13). At this time, the last referred time (screen 67 in FIG. 3) sent from the

client terminals

20 and 30 is compared with the setting date 44 of each user's presence status (step 322 in FIG. 13). The presence status information 40 is sent only when the setting date 44 of the presence status of the person is larger (step 323 in FIG. 13), and the data transmission amount between the server machine 10 and the

client terminals

20 and 30 is reduced. It is possible to do.
[0038]
For reference, this section describes how to register and delete users to be referenced by the partner

status reference function

22,32.
The reference partner is registered by selecting the menu [Awareness] on the screen 61 in FIG. When the menu [Awareness] is opened and [Register] is selected from the menu, a list of users registered in the server machine 10 is displayed. A user to be referred to is selected from there (

steps

208 and 209 in FIG. 9). When the selection is completed, the selected partner list is sent to the server machine 10 (step 210 in FIG. 9). The presence status information management unit 12 of the server machine 10 adds the transmitted data as request data 50 to the presence status information 40 of the reference partner (steps 314-323 in FIG. 13). Further, the presence status information 40 of the reference partner is transmitted to the client terminals 20 and 30 (steps 314 to 323 in FIG. 13). The partner

status display units

22 and 32 display the presence status of the reference partner on the screen 63 based on the presence status information 40 sent from the server machine 10 (step 210 in FIG. 9).
To delete, select the reference partner displayed on screen 63 in Fig. 3, open the menu [Awareness], and then select the menu [Delete]. It is sent to the machine 10 (FIG. 9, steps 208-210). The presence status information management unit 12 on the server machine 10 searches the request data 50 of the corresponding user using the user name to be deleted sent from the

client terminals

20 and 30 as a key, and the network address of the own user name 52 is deleted (steps 324-328 in FIG. 13).
[Communication execution request function]
After confirming the presence status of the reference partner, the communication partner may be selected according to the status, and the reference partner may be accessed. In that case, select the picture of the person you want to access on screen 63 in FIG. 3 and select [Phone], [Mail], [FAX] from [Communication] on screen 61, or use the tool button on screen 62 to select [ Selecting [Telephone], [Mail], [FAX] obtains communication information 45 of the selected partner (phone number 46 for telephone, mail address 47 for mail, FAX number for FAX), and communication execution unit along with the

communication type

23 and 33 are requested for processing (

steps

211 and 212 in FIG. 9). The

communication execution units

23 and 33 execute communication using the corresponding data.
[End presence reference]
When the presence status reference is ended, the server machine is notified of the reference end (step 207 in FIG. 9, step 213 in FIG. 10, step 329-333 in FIG. 14), and the current reference partner is displayed in the partner presence status reference list 72. Save and finish (

steps

214 and 215 in FIG. 10). At the same time, the own state setting units 21 and 31 are also terminated. (Fig. 6, steps 109-110).
[Request data setting function 450]
You can set the notification level of the updated content when the status of the reference partner changes when the partner status is referenced or after reference registration.
[0039]
Select the person whose notification level is to be set on the screen 63 in FIG. 3, select [Option] in the screen 61, and select the menu [Set notification level] (step 223 in FIG. 11). The setting screen (FIG. 15) is displayed (step 224 in FIG. 11). An example of the notification level setting screen is shown in FIG. By selecting the state types 80 and 81 shown on the notification level setting screen in FIG. 15, it is set whether to notify any state change or only when it changes to a specific state. By sending this setting content to the server machine 10 (

steps

225 and 226 in FIG. 11), the presence status information management unit 12 on the server sets the status notification flag 53 of the presence status management table 11 (FIG. 14). Step 334,335). Based on this information, the self-status setting units 21 and 31 specify the user who should send the updated contents when a change occurs in the presence status of the referrer.
[0040]
In addition, if you specify that you want to be notified when you change to a specific status, you will receive a notification message that the presence status has changed so that you can see that the presence status has been updated as well as the presence status update. (Step 220 in FIG. 10). An example of the notification message is shown in FIG.
As described above, when the other party's state changes to the set condition, it can be surely recognized.
[0041]
Further, when a notification message is displayed, a communication button can also be displayed as shown in FIG. 16 so that appropriate communication can be immediately made to the other party from the state change notification. The communication execution request function is activated by the communication button (

steps

221, 222 in FIG. 10).
The communication execution request function is the same as described above.
[Simple message function]
In this example, by providing the request data 50 with a simple message 54, a message notification condition 55, and a message confirmation flag 56, it is possible to send a simple message when the partner's presence state is changed.
[0042]
After selecting a partner on the screen 63 in FIG. 3, by selecting the menu [Option] on the screen 61 and further selecting the menu [Simple Message Function], the partner

status display units

22 and 32 will respond to the selected user. The server 10 is inquired whether there is a simple message that has already been set (

steps

230 and 231 in FIG. 11). The presence status information management unit 12 of the server machine 10 searches the request data 50 of the reference partner in the presence status management table 11 and confirms whether a message is set in the simple message 54 (step 336 in FIG. 14). If set, the simple message 54 is sent to the client terminals 20 and 30 (step 337 in FIG. 14). The partner

status display units

22 and 32 of the

client terminals

20 and 30 that have received the response from the server machine 10 display the message if there is a message, and display a simple message setting screen as shown in FIG. (Figure 11 Step 232). When the user inputs or changes a message, sets display conditions, and operates the send button 93, the message is sent to the presence status information management unit 12 of the server machine 10 (

steps

233 and 234 in FIG. 11). The presence status information management unit 12 of the server machine 10 stores the simple message transmitted from the

client terminals

20 and 30 in the request data 50 of the user in the presence status management table 11 (step 338 in FIG. 14). , 339). When the seating state is changed on the referenced side, the own state setting units 21 and 31 send a seating state update notification to the seating state information management unit 12 of the server machine 10, whereby the request data 50 is received from the server machine 10. It will be sent out. The own state setting units 21 and 31 check whether the message notification condition 55 is met (step 119 in FIG. 8). If the message notification condition is met, the contents of the simple message 54 are displayed together with the reference user name 51 as shown in FIG. (Step 120 in FIG. 8).
[0043]
As a specific example, Mr. Tanaka will notify Mr. Suzuki on the simple message setting screen shown in FIG. 17 when Mr. Suzuki is in the “Attendance” state with the message “Please check the document today.” It is set. As a result, “1” is set to the 0th bit of the message content and message notification condition 55 in the simple message 54 in the request data 50 of Mr. Suzuki in the attendance state management table 11 of FIG. As a result, when Mr. Suzuki returns to the seat and changes the seating status to “attended”, the simple message 54 set in the request data 50 is displayed as shown in FIG.
[0044]
As described above, it is possible to display a message in accordance with the change of the partner's own state.
Furthermore, a confirmation button 98 is prepared on the simple message display screen (FIG. 18), and when this button is pressed, the own state setting units 21 and 31 notify the server machine 10 that the message is already read, and a simple message display is displayed. The screen is erased (

steps

121, 122, and 123 in FIG. 8). Upon receiving the notification, the presence status information management unit 12 of the server machine 10 turns on the message confirmation flag 56 of the request data 50 (sets “1” in the 0th bit) (

steps

340 and 341 in FIG. 14). When the user tries to set a simple message for the same person again, the other party's

status display units

22 and 32 check the contents of the message confirmation flag 56 together with the simple message contents set as described above. Whether or not is displayed (steps 231, 232 in FIG. 11). In the simple message setting screen of FIG. 17, when the white square on the left side of the read 92 is already read, it becomes a black square.
[0045]
When the message content is rewritten and sent 93 or re-notification 94 is selected without rewriting on the screen of FIG. 17, the message confirmation flag 56 is turned off (set to “0” in the 0th bit) (the read state is changed). The message is changed to the unread state) and sent to the server machine 10 together with the message content (

steps

233 and 234 in FIG. 11). The presence status information management unit 10 of the server machine 10 updates the request data 50 based on the transmitted information (step 339 in FIG. 14).
[0046]
As described above, it is possible to determine whether the other party has seen the set simple message.
It should be noted that the three processes of the own state setting units 21 and 31 on the

client terminal

20 and 30 side, the partner

state display units

22 and 32, and the

communication execution units

23 and 33 may be included in one program as the same application. .
The attendance status information management unit 12 on the server machine 10 also manages the attendance status management table 11, but the server machine 10 is a file sharing server, and the attendance management table 11 is treated as a file. The functions of the state information management unit 12 may be performed by the own state setting units 21 and 31 and the partner

state display units

22 and 32 of the

client terminals

20 and 30.
[0047]
The request data 50 of the presence status management table 11 is also stored in the same record as the presence status information of the user. However, an item of the user name 41 is added to the request data 50, and the user By making the association possible by name, the presence status information 40 and the request data 50 may be managed as separate tables.
The users of the

client terminals

20 and 30 may be used by not only one person but plural one, and one user is not only a specific client terminal but also other client terminals. Even if is used, implementation is possible.
[0048]
The application for request data 50 from the user is not limited to the application from the

client terminals

20 and 30, but the application method is set on the client terminal, such as setting the application from the user at the time of system introduction. Not limited.
[0049]
【The invention's effect】
As described above, according to the present invention, when sharing the status information of each user in a network system including a server machine and a plurality of identified client terminals, the status information of each user and the information from other users in advance are shared. By managing the request data registered in the application in association with each other, when the status information of the user is updated, other client terminals selected according to the request data with reference to the request data It is possible to transmit user status information directly to
[0050]
As a result, it is possible to properly grasp the other party's status information while reducing the load on the server machine.
[Brief description of the drawings]
FIG. 1 is a block diagram of the present invention.
FIG. 2 is a record format example of an attendance state management table of a server machine.
FIG. 3 shows a screen example of the own state setting unit and the partner state display unit.
FIG. 4 is a diagram showing an information transmission procedure of the system
FIG. 5 is an example of an attendance state display list of a client terminal.
FIG. 6 is a flowchart (part 1) showing processing of the client terminal's own state setting unit
FIG. 7 is a flowchart (part 2) showing processing of the own state setting unit of the client terminal.
FIG. 8 is a flowchart (No. 3) showing the processing of the own state setting unit of the client terminal.
FIG. 9 is a flowchart (part 1) showing processing of the partner state display unit of the client terminal.
FIG. 10 is a flowchart (part 2) illustrating processing of the partner state display unit of the client terminal.
FIG. 11 is a flowchart (part 3) illustrating processing of the partner state display unit of the client terminal.
FIG. 12 is a flowchart (part 1) illustrating processing of an attendance state information management unit of a server machine.
FIG. 13 is a flowchart (part 2) showing processing of the presence state information management unit of the server machine.
FIG. 14 is a flowchart (No. 3) showing processing of the presence status information management unit of the server machine.
FIG. 15: Attendance status notification setting screen example
FIG. 16: Message screen example when updating the presence status of a partner
FIG. 17: Simple message setting screen example
FIG. 18: Simple message display screen example

Claims

In a network system including a server machine and a plurality of identified client terminals,
Server machine
The notification sent from the client terminal to notify the first user of the client terminal identifying the second user who wants to refer to the status information and the change of the status information of the second user When request data setting information including a condition is received, request data is generated by associating a notification condition included in the request data setting information with identification information for identifying the first user, and the generated request data A request data storage unit that stores information associated with identification information for identifying the second user included in the request data setting information;
When the status information of the second user of the client terminal sent from the client terminal is received, it is stored in association with the identification information for identifying the second user of the client terminal from the request data storage unit. A request data sending unit that obtains the requested request data and sends it to the client terminal;
With
The client terminal
A status information notifying unit for sending the identification information identifying the second user of the second user of the state information and the client terminal of the client terminal which is input through the input means to the server machine,
The status information of the second user in response to the sent to the server machine, and the request data acquisition unit for receiving a request data sent from the servers machine,
Matching the notification condition for notifying a change of state information included in the request data received second user of the state information of the client terminal that is input by the state information notifying unit and at the request data acquisition unit In this case, the input is made to the client terminal associated with the identification information for identifying the first user stored in association with the notification condition for notifying the change of the matched state information included in the request data. An information sharing system comprising: a status information distribution unit that directly transmits status information of the second user.

In a system for sharing status information among multiple terminal users who own terminal devices connected to a network that includes a common server,
In each terminal device , the notification condition indicating the change of the identification information for identifying the second user for whom the first user of the terminal device desires to acquire the status information and the status information for which notification is desired via the input means a step of sending bets is inputted, the identification information and notification condition for identifying a second user input to the server machine,
In the server, request data is generated by associating the notification condition received from the terminal device with the identification information identifying the first user, and the second user who has received the generated request data from the terminal device Registering and storing in the server in association with identification information for identifying
In each terminal device , a plurality of status displays representing the status of the second user of the terminal device are displayed on the display means, and the second user selects from among the plurality of status displays displayed via the input means. Sending status information corresponding to the status display to the server;
In the server, the status information received from each terminal device is stored in association with the identification information for specifying the second user, and is stored in association with the identification information for specifying the second user of the terminal device . acquires identification information and notification condition for identifying the first user, notify the sending side of the terminal device,
In the terminal device , a notification condition indicating a change in the state information corresponding to the state display selected from the plurality of state displays displayed by the second user via the input means and the state information desired to be received from the server And a step of transmitting status information corresponding to the selected status display to a terminal device associated with the identification information for identifying the first user received from the server. A state information notification method in the state information sharing system.