(57)【特許請求の範囲】
【請求項１】
端末装置間の通信状況を把握するサーバ装置であって、
コミュニケーション履歴情報と、ユーザ管理情報と、を格納する記憶装置と、
端末装置を利用するユーザの情報であるコミュニケーション元ユーザの情報とコミュニケーション先ユーザの情報とをユーザ情報として前記端末装置から受信する通信装置と、
前記ユーザ情報を用いて前記端末装置間の通信状況を推定する処理を実行するプロセッサと、を有し、
前記ユーザ管理情報は、登録されている各ユーザの所属組織および役職の情報を含み、
前記プロセッサは、
前記ユーザ情報に基づいてユーザ管理情報を検索し、前記コミュニケーション元ユーザと前記コミュニケーション先ユーザが所属する組織の情報を取得し、当該組織の間でコミュニケーションしたユーザの組み合わせを、状況を推定するための経路として特定する状況推定経路特定処理と、
前記状況推定経路特定処理によって特定した経路ごとの状況を推定する状況推定処理と、を実行し、
前記プロセッサは、前記状況推定処理において、前記コミュニケーション履歴情報に含まれるコミュニケーションの頻度が第１の閾値を超える場合、前記コミュニケーション履歴情報に含まれる時刻が所定の時間帯を含む場合、前記ユーザ管理情報及び前記コミュニケーション履歴情報から取得した部門の数が第２の閾値を超える場合、或いは、前記ユーザ管理情報及び前記コミュニケーション履歴情報から取得した役職の数が第３の閾値を超える場合、対象の経路において問題がある可能性ありと推定する、サーバ装置。
【請求項２】
請求項１において、
前記プロセッサは、前記状況推定経路特定処理において、前記コミュニケーション元ユーザと前記コミュニケーション先ユーザの組み合わせ以外の組み合わせを、前記状況を推定するための経路として特定する、サーバ装置。
【請求項３】
請求項１において、
前記記憶装置は、さらに、前記端末装置を利用するユーザが指定した前記コミュニケーション先ユーザと、前記状況推定処理によって推定された経路におけるコミュニケーション先ユーザとの密接度を示す部署関連度情報を保持し、
前記プロセッサは、さらに、前記部署関連度情報に基づいて、前記状況推定処理によって推定した結果を前記端末装置に通知するか否かを判断する推定結果報告判断処理を実行する、サーバ装置。
【請求項４】
サーバ装置において、端末装置間の通信状況を把握する通信状況把握方法であって、
前記サーバ装置は、コミュニケーション履歴情報と、ユーザ管理情報と、を格納する記憶装置と、端末装置を利用するユーザの情報であるコミュニケーション元ユーザの情報とコミュニケーション先ユーザの情報とをユーザ情報として前記端末装置から受信する通信装置と、前記ユーザ情報を用いて前記端末装置間の通信状況を推定する処理を実行するプロセッサと、を有し、
前記ユーザ管理情報は、登録されている各ユーザの所属組織および役職の情報を含み、
前記方法は、
前記プロセッサが、前記ユーザ情報に基づいてユーザ管理情報を検索し、前記コミュニケーション元ユーザと前記コミュニケーション先ユーザが所属する組織の情報を取得し、当該組織の間でコミュニケーションしたユーザの組み合わせを、状況を推定するための経路として特定する状況推定経路特定処理を実行することと、
前記プロセッサが、前記状況推定経路特定処理によって特定した経路ごとの状況を推定する状況推定処理を実行することと、を含み、
前記プロセッサは、前記状況推定処理において、前記コミュニケーション履歴情報に含まれるコミュニケーションの頻度が第１の閾値を超える場合、前記コミュニケーション履歴情報に含まれる時刻が所定の時間帯を含む場合、前記ユーザ管理情報及び前記コミュニケーション履歴情報から取得した部門の数が第２の閾値を超える場合、或いは、前記ユーザ管理情報及び前記コミュニケーション履歴情報から取得した役職の数が第３の閾値を超える場合、対象の経路において問題がある可能性ありと推定する、通信状況把握方法。
【請求項５】
請求項４において、
前記プロセッサは、前記状況推定経路特定処理において、前記コミュニケーション元ユーザと前記コミュニケーション先ユーザの組み合わせ以外の組み合わせを、前記状況を推定するための経路として特定する、通信状況把握方法。
【請求項６】
請求項４において、
前記記憶装置は、さらに、前記端末装置を利用するユーザが指定した前記コミュニケーション先ユーザと、前記状況推定処理によって推定された経路におけるコミュニケーション先ユーザとの密接度を示す部署関連度情報を保持し、
前記方法は、
前記プロセッサが、前記部署関連度情報に基づいて、前記状況推定処理によって推定した結果を前記端末装置に通知するか否かを判断する推定結果報告判断処理を実行することを含む、通信状況把握方法。
【請求項７】
複数の端末装置と、当該複数の端末装置における通信状況を把握するサーバ装置と、を備える通信状況把握システムであって、
前記サーバ装置は、コミュニケーション履歴情報と、ユーザ管理情報と、を格納する記憶装置と、前記複数の端末装置と通信するための通信装置と、を少なくとも、有し、
前記複数の端末装置のそれぞれは、前記サーバ装置と通信するための通信装置を少なくとも有し、
前記ユーザ管理情報は、登録されている各ユーザの所属組織および役職の情報を含み、
前記端末装置は、当該端末装置を利用するユーザの情報であるコミュニケーション元ユーザの情報とコミュニケーション先ユーザの情報とをユーザ情報として前記サーバ装置に送信し、
前記サーバ装置は、前記端末装置から前記ユーザ情報を受信し、
前記ユーザ情報に基づいてユーザ管理情報を検索し、前記コミュニケーション元ユーザと前記コミュニケーション先ユーザが所属する組織の情報を取得し、当該組織の間でコミュニケーションしたユーザの組み合わせを、状況を推定するための経路として特定する状況推定経路特定処理と、前記状況推定経路特定処理によって特定した経路ごとの状況を推定する状況推定処理と、を実行し、
前記サーバ装置は、前記状況推定処理において、前記コミュニケーション履歴情報に含まれるコミュニケーションの頻度が第１の閾値を超える場合、前記コミュニケーション履歴情報に含まれる時刻が所定の時間帯を含む場合、前記ユーザ管理情報及び前記コミュニケーション履歴情報から取得した部門の数が第２の閾値を超える場合、或いは、前記ユーザ管理情報及び前記コミュニケーション履歴情報から取得した役職の数が第３の閾値を超える場合、対象の経路において問題がある可能性ありと推定する、通信状況把握システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ装置、通信状況把握方法、及び通信状況把握システムに関する。
【背景技術】
【０００２】
企業と企業の通信経路の繋がりは、一本の経路のみで繋がっていることは稀で、複数の経路、すなわち、Ａ会社の保守部門とＢ会社の事業部門Ｘとが繋がる経路ＡやＡ会社の営業部門とＢ会社の事業部門Ｙとが繋がる経路Ｂが同時に夫々でやりとり（通信）を行っていることがよくある。ここで、経路Ａでのやりとりの状況が、経路Ｂのやりとりに影響を及ぼすことがある。例えば、経路Ａでのやりとりでトラブルが発生し、経路Ａを使用するＢ会社の部署が不満を感じている場合に、経路Ｂを用いてＡ会社の営業部門がＢ会社に営業をかけたとき、経路Ａでの不満が理由で営業活動が成功しないことがある。このため、自らが把握している経路以外での経路におけるやりとりの状況を把握することが望まれている。
【０００３】
企業間のやりとりはメールで行われることが多く、そのような文字情報から相手の感情を読み取る技術として、例えば特許文献１がある。
【０００４】
特許文献１には、電子文書が有する各単語の感情ベクトルを文書全体について積算し、その電子文書が有する感情を自動的に判定する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−２３００１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、企業間のやりとり、とりわけメールのような証拠が残るものについては、ビジネスライクな文面になることが多く、感情が文面に表現されるとは限らない。従って、この場合、特許文献１に開示されているような技術を用いたとしても企業間でのやりとりの状況を推定することができるはできない。このため、言語化されていない部分から感情を推定する必要がある。
【０００７】
本発明はこのような状況に鑑みてなされたものであり、２者間の通信において言語化されていない部分から状況を推定することを可能にする技術を提供するものである。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明は、端末装置間の通信状況を把握するサーバ装置に関し、当該サーバ装置は、コミュニケーション履歴情報と、ユーザ管理情報と、を格納する記憶装置と、端末装置を利用するユーザの情報であるコミュニケーション元ユーザの情報とコミュニケーション先ユーザの情報とをユーザ情報として端末装置から受信する通信装置と、ユーザ情報を用いて端末装置間の通信状況を推定する処理を実行するプロセッサと、を有する。そして、プロセッサは、ユーザ情報に基づいてユーザ管理情報を検索し、コミュニケーション元ユーザとコミュニケーション先ユーザが所属する組織の情報を取得し、当該組織の間でコミュニケーションしたユーザの組み合わせを、状況を推定するための経路として特定する状況推定経路特定処理と、状況推定経路特定処理によって特定した経路ごとの状況を推定する状況推定処理と、を実行する。
【０００９】
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本発明の態様は、要素及び多様な要素の組み合わせ並びに以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。
【００１０】
本明細書の記述は典型的な例示に過ぎず、本発明の特許請求の範囲又は適用例を如何なる意味においても限定するものではないことを理解する必要がある。
【発明の効果】
【００１１】
本発明により、言語化されていない部分から状況を推定することが可能になり、さらには、自らが把握している経路以外の経路の状況を把握することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態による通信状況把握システムのハードウェア構成及び機能構成を示す図である。
【図２】ユーザ管理情報ＤＢのデータ構成例を示す図である。
【図３】コミュニケーション履歴ＤＢのデータ構成例を示す図である。
【図４】関連部署情報ＤＢのデータ構成例を示す図である。
【図５】経路状況の推定結果の表示例を示す図である。
【図６】通信状況把握処理全体を説明するためのフローチャートである。
【図７】通信状況推定処理（ステップ６０５）の詳細を説明するためのフローチャートである。
【図８】通信状況把握処理における推定結果報告処理（ステップ６０６）の詳細を説明するためのフローチャートである。
【発明を実施するための形態】
【００１３】
本発明は、メール等で複数回文章をやりとりする際の応答内容に基づいて、当該やりとりの状況を把握する技術に関する。
【００１４】
以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。
【００１５】
本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。
【００１６】
更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。
【００１７】
なお、以後の説明では「テーブル」形式によって本発明の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。
【００１８】
また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。
【００１９】
以下では「プログラム」である各処理部（例えば、履歴記録部、状況推定処理部等）を主語（動作主体）として本発明の実施形態における各処理について説明を行うが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００２０】
＜通信状況把握システムの構成＞
図１は、本発明の実施形態による通信状況把握システム１のハードウェア構成及び機能構成を示す図である。
【００２１】
通信状況把握システム１は、少なくとも１つのサーバ装置１１０と、複数の端末装置１０１と、を備え、これらがネットワーク１６０を介して接続されている。端末装置１０１は、他の端末装置１０１及びサーバ装置１１０とネットワーク１６０（例えば、インターネットやＬＡＮ等）を介して通信することができるようになっている。
【００２２】
サーバ装置１１０は、各種プログラムを実行するＣＰＵ（プロセッサ）１１２と、各種データや情報を格納するメモリ１１３と、外部装置と通信を実行する通信部（通信装置）１１４と、各種プログラムを格納する記憶装置１２０と、各種データベース（ＤＢ）を格納する記憶装置１３０と、を備え、これらがバス１５０を介して接続されている。
【００２３】
端末装置１０１は、各種プログラムを実行するＣＰＵ（プロセッサ）１０２と、各種データや情報を格納するメモリ１０３と、情報（例えば、サーバ装置１１０による処理結果（取得した経路の状況））を画面上に表示する表示部（表示装置）１０４と、各種プログラムを格納する記憶装置１０５と、通信部（通信装置）１０８と、を備え、これらがバス１０９を介して接続されている。
【００２４】
サーバ装置１１０において、記憶装置１２０は、オペレーティングシステム（ＯＳ）１２１と、プログラムとしての、履歴記録部１２２と、状況推定経路特定処理部１２３と、状況推定処理部１２４と、推定結果報告判断処理部１２５と、を保持している。また、記憶装置１３０は、コミュニケーション履歴データベース（ＤＢ）１３１と、ユーザ管理情報ＤＢ１３２と、関連部署情報ＤＢ１３３と、を格納している。図１において、記憶装置１２０と記憶装置１３０は分離して設けられているが、１つの記憶装置として構成しても良い。
【００２５】
履歴記録部１２２は、端末装置間のコミュニケーション部１０７を通したコミュニケーションの情報を、コミュニケーションのまとまりごとに、「いつ」、「誰が」、「誰に」コミュニケーションを行ったかを、コミュニケーション履歴情報としてコミュニケーション履歴ＤＢ１３１に記録する。
【００２６】
状況推定経路特定処理部１２３は、ユーザ情報に基づいてユーザ情報管理ＤＢ１３２を検索し、当該コミュニケーション元ユーザとコミュニケーション先ユーザが所属する組織名を抽出し、当該組織間でコミュニケーションしたユーザの組み合わせを、状況を推定するための経路として特定する。
【００２７】
状況推定処理部１２４は、コミュニケーション履歴情報とユーザ管理情報から、コミュニケーションの状況を推定する。例えば、自社と取引先の事業部Ｘの経路のコミュニケーションの状況は、該当経路のコミュニケーション履歴情報から特徴を見出し、これに基づいて推定する。詳細は、後述する。
【００２８】
推定結果報告判断処理部１２５は、状況推定処理部１２４によって推定した結果について報告を行うか否か判断する。
【００２９】
ユーザ管理情報ＤＢ１３２は、コミュニケーションを行っているユーザの情報、つまり、端末装置１０１を利用しているユーザの情報であるユーザ管理情報を保持している。例えば、企業活動の場合、自社の組織階層や個人情報、取引先の組織階層や個人情報を保持しており、経路ごとにユーザの情報を簡単に取得できる。
【００３０】
関連部署情報ＤＢ１３３は、同一企業内における各部署の関係を示す情報を保持している。
【００３１】
コミュニケーション履歴ＤＢ１３１は、上述のように、コミュニケーションのまとまりごとにコミュニケーション履歴を保持している。
【００３２】
一方、端末装置１０１において、記憶装置１０５は、オペレーティングシステム（ＯＳ）１０６と、プログラムとしてのコミュニケーション部１０７を保持している。
【００３３】
端末装置１０１間においては、コミュニケーション部１０７を通してコミュニケーションを行うことができるようになっている。また、コミュニケーション部１０７は、コミュニケーション開始時に、サーバ装置１１０の状況推定処理部１２４に問い合わせを行い、コミュニケーションを実施する経路以外の経路の状況を取得する。
【００３４】
＜ユーザ管理情報ＤＢの構成例＞
図２は、通信状況把握システム１が利用するユーザ管理情報ＤＢ１３２の構成例を示す図である。ユーザ管理情報ＤＢ１３２には、ユーザがどの組織に属しているかという情報が記憶されている。
【００３５】
ユーザ管理情報ＤＢ１３２は、ユーザ名２０１と、当該ユーザが所属する企業を示す組織名２０２と、当該ユーザが所属する部署を示す部署名２０３と、当該ユーザの役職２０４と、を構成情報として有している。ユーザ管理情報ＤＢ１３２は、例えば、図１に図示しない顧客情報管理システム（ＣＲＭ）などを利用して予め作成しておいてもよいし、コミュニケーションの内容からコミュニケーション先及びコミュニケーション元の情報を抽出して作成しても良い。さらに、予めユーザ管理情報ＤＢ１３２を作成し、不足する情報をコミュニケーションの内容から補充するようにしても良い。
【００３６】
ユーザ名２０１、組織名２０２、部署名２０３、及び役職２０４を自動的に取得する方法として、コミュニケーションの内容（例えば、メールの本文）から類推する場合、例えば、ビジネスにおけるコミュニケーションに存在する一定のルール（作法）を用いても良い。例えば、メールの場合、初対面や関係が深くない相手には、「ＸＹＺ商事株式会社  営業本部  営業１部  部長  ｘｘｘｘ様」のように会社名や部署名、役職を含めて宛先（コミュニケーション先）をきちんと書くケースが多い。また、コミュニケーション元については、例えばメールの場合、署名（シグネイチャ）の情報を抽出するようにしても良い。なお、何回かのやりとりの後、宛先が簡略化されていくことが予想されるが、初回は書かれている可能性が高い。このため、コミュニケーション内容（文章）を監視し、マッチング辞書を用いてパターンマッチングを行うことで、ユーザ名２０１、組織名２０２、部署名２０３、役職２０４を自動的に取得できる。
【００３７】
取得した、ユーザ名２０１、組織名２０２、部署名２０３、及び役職２０４の情報は、ユーザ情報管理ＤＢ１３２に記録され、状況を推定すべき経路を特定する処理に用いられる。
【００３８】
＜コミュニケーション履歴ＤＢの構成例＞
図３は、通信状況把握システム１が利用するコミュニケーション履歴ＤＢ１３１の構成例を示す図である。
【００３９】
コミュニケーション履歴ＤＢ１３１は、一まとまりのコミュニケーションを特定し、識別するための情報であるＣＯＭＩＤ３０１と、特定のコミュニケーションにおけるコミュニケーション元の情報を示すコミュニケーション元３０２、特定のコミュニケーションにおけるコミュニケーション先の情報を示すコミュニケーション先３０３、当該コミュニケーションが行われた時刻を示す時刻３０４と、を構成情報として有している。
【００４０】
ＣＯＭＩＤ３０１は、コミュニケーションのまとまりを識別するためのＩＤである。例えば、メールにおけるコミュニケーションのまとめ方として、あるメールに対する返信や転送のやりとりを１つのコミュニケーションとしてまとめたり、ある単位時間あたりに、タイトルに同一文字列が含まれているメールを１つのコミュニケーションとしてまとめたりしても良い。また、例えば、メールに限定すれば、付与されるメッセージＩＤが同一であるメールを１つのコミュニケーションとしてまとめるようにしても良い。なお、コミュニケーションの形態としては、メールに限定されるものではなく、例えばＳＮＳのメッセージなども含まれる。
【００４１】
コミュニケーション元３０２は、経路において、コミュニケーションの内容の発信元である。コミュニケーション先３０３は、受信先である。例えば、メールの場合、コミュニケーション元３０２がメールの発信元であり、コミュニケーション先３０３がメールの受信先である。時刻３０４は、コミュニケーションが発生した時刻である。
【００４２】
コミュニケーション履歴ＤＢ１３１の各情報であるＣＯＭＩＤ３０１、コミュニケーション元３０２、コミュニケーション先３０３、及び時刻３０４を用いて、特定した経路ごとの状況が推定される。経路の状況を推定する処理については後述する。
【００４３】
＜関連部署情報ＤＢの構成例＞
図４は、通信状況把握システム１が利用する関連部署情報ＤＢ１３３の構成例を示す図である。
【００４４】
関連部署情報ＤＢ１３３は、部署１_４０１と、部署２_４０２と、企業規模４０３と、部署類似度４０４と、部署１特性４０５と、部署２特性４０６と、関連度４０７と、を構成情報として有している。関連部署情報ＤＢ１３３は、例えば、予め作成され、提供される。
【００４５】
部署１_４０１と部署２_４０２は、同一企業内における部署を示す情報であり、関連部署情報ＤＢ１３３においては、特にこれらの２つの部署がどのような関係にあるかが示されている。
【００４６】
企業規模４０３は、企業が大規模、中規模、或いは小規模かを示す情報である。例えば、「事業部−本部−部」のように、部までの階層が３つであれば、「大規模」とし、「本部−部」のように階層が２つであれば「中規模」と記録される。
【００４７】
部署類似度４０４は、部署１_４０１と部署２_４０２が部署として同一性や類似性を有するかを示す情報である。
【００４８】
部署１特性４０５は部署１_４０１の特性を、部署２特性４０６は部署２_４０２の特性を示す情報である。例えば、顧客接点となる部署である「営業」や「保守」は「全社またがり」とし、それ以外の部署は「単独」として記録される。
【００４９】
関連度４０７は、部署１_４０１と部署２_４０２がどの程度密接に関連するかを示す情報であり、値が高いほど関連性が高いことを示している。部署の関連度４０７は、部署類似度４０４と、企業規模４０３と、部署特性４０５及び４０６とに基づいて決定される。例えば、企業規模４０３が大きい場合、「事業部」、「本部」、「部」と階層化されており、「部」という組織もかなり大きく、同一本部内の「部」であっても、「部」と「部」の間の交流は少なく、関連度４０７の値は小さくなる。一方、企業規模４０３が小さい場合、組織の階層が浅いため、「部」という組織も企業規模４０３が大きい場合の「部」に比べて小さく、「部」と「部」の間の交流も多くなりやすい。このため、関連度４０７の値は高くなる。また、企業規模４０３と部署類似度４０４が同一であっても、部署特性４０５、４０６が「全社またがり」である部署は、部署特性４０５、４０６が「単独」である部署よりも関連度４０７の値が大きくなる。例えば、図４の１行目と２行目は、企業規模４０３と部署類似度４０４が同一であるが、部署２特性４０６が異なる。このため、２行目の方が関連度４０７の値が大きくなる。
【００５０】
この関連部署情報ＤＢ１３３の関連度４０７を用いて、推定した状況の推定結果報告を行うか否かの判断が行われる。詳細については後述する。
【００５１】
＜経路状況推定結果表示例＞
図５は、経路状況の推定結果の表示例を示す図である。経路ごとにコミュニケーションの状況が表示されている。経路には向きがあり、この例では、「企業Ｂ」から「企業Ａ−事業部Ｘ」に対する経路が「問題あり」という状況であることが示されている。また、この例では、「問題あり」と「問題なし」の２値であるが、「企業Ａ−事業部Ｚ」から「企業Ｂ」に対する経路に「興味あり」、「興味なし」や「満足」、「不満」などの状況を表示しても良い。どういった状況を表示するかは、状況把握処理の実現方式に依存する。
【００５２】
＜通信状況把握システムの動作（全体処理）＞
図６は、本発明の実施形態による通信状況把握システム１において実行される状況把握処理全体を説明するためのフローチャートである。
【００５３】
（i）ステップ６０１
コミュニケーションを行うユーザ（コミュニケーション元：例えば、これからメールを作成しようとするある企業のある部署に属するユーザ）が端末装置１０１を用いてコミュニケーションを行う対象であるコミュニケーション先（例えば、メールの送信先の情報）を入力すると、当該コミュニケーション元の端末装置１０１のコミュニケーション部１０７は、当該コミュニケーション先の情報を取得する。
【００５４】
（ii）ステップ６０２
コミュニケーション元のユーザが状況推定粒度を入力すると、コミュニケーション元の端末装置１０１のコミュニケーション部１０７は、当該状況推定粒度の情報を受け取る。ユーザによる状況推定粒度の入力方法としては、例えば、コミュニケーション部１０７のインターフェースを利用し、状況推定粒度として、コミュニケーション元の組織階層とコミュニケーション先の組織階層を指定する。他にも例えば、特定の企業の部署との関係を知りたいときには、状況推定粒度として、状況推定対象の経路を直接指定する（コミュニケーション先の企業の部署名で指定する）ようにしても良い。この場合、サーバ装置１１０のユーザ管理情報ＤＢ１３２に問い合わせを行い、ユーザ情報をインターフェースに表示しても良い。なお、この処理は、予め端末装置１０１に状況推定粒度を設定しておくことで、スキップすることも可能である。
【００５５】
（iii）ステップ６０３
コミュニケーション元の端末装置１０１のコミュニケーション部１０７は、経路として、コミュニケーションを行うユーザの情報（コミュニケーション元とコミュニケーション先を一意に識別できる情報）をサーバ装置１１０に送信する。例えば、図２の場合、ユーザを一意に識別できるユーザ情報としてユーザ名と状況推定粒度をサーバ装置１１０の状況推定経路特定処理部１２３に送信する。
【００５６】
（iv）ステップ６０４
サーバ装置１１０の状況推定経路特定処理部１２３は、受け取ったユーザ情報と状況推定粒度とユーザ管理情報ＤＢ１３２を利用して、状況を推定する経路の特定を行う。例えば、受信したユーザ情報として、コミュニケーション元が「ＩＩＩ」、「コミュニケーション先」が「ＪＪＪ」であり、受信した状況推定粒度として、コミュニケーション元の階層が１、コミュニケーション先の階層が２の場合を考える。図２の９行目と１０行目から、コミュニケーション元が「企業Ｂ」、コミュニケーション先が「企業Ａ−事業部Ｙ」という経路となることが分かる。よって、この経路以外の経路として、「企業Ｂ」と「企業Ａ−事業部Ｘ」、「企業Ｂ」と「企業Ａ−事業部Ｚ」の２つが取得される。この例の場合、コミュニケーション元の階層が１の「企業Ｂ」であるため、コミュニケーション元は１つしかないが、コミュニケーション元の階層を２とした場合、「企業Ｂ−保守Ｌ」や「企業部−設計Ｍ」というコミュニケーション元もあり得るため、「企業Ｂ−保守Ｌ」と「企業Ａ−事業部Ｘ」、「企業Ｂ−保守Ｌ」と「企業Ａ−事業部Ｚ」、「企業Ｂ−設計Ｍ」と「企業Ａ−事業部Ｘ」、「企業Ｂ−設計Ｍ」と「企業Ａ−事業部Ｚ」という経路も取得することとなる。
【００５７】
（v）ステップ６０５
サーバ装置１１０の状況推定処理部１２４は、ステップ６０４で特定された経路ごとの状況を推定する。状況推定処理（ステップ６０５）の詳細については、後述する。
【００５８】
（vi）ステップ６０６
サーバ装置１１０の推定結果報告判断処理部１２５は、ステップ６０５による推定結果を端末装置１０１の表示部１０４に表示するか否かを判断する。推定結果報告判断処理（ステップ６０６）の詳細については、後述する。
【００５９】
（vii）ステップ６０７
最後に、推定結果報告判断処理部１２５により、報告「要」と判断された場合、ステップ６０５で得られた推定結果が端末装置１０１に送信され、コミュニケーション部１０７は、表示部１０４にコミュニケーションを行うべきか否かの推奨を行う推定結果報告を表示する。
【００６０】
＜通信状況把握システムの動作（状況推定処理）＞
図７は、ステップ６０５（図６）の状況推定処理部１２４による状況推定処理の詳細を説明するためのフローチャートである。
【００６１】
（i）ステップ７０１
状況推定処理部１２４は、推定していない経路があるか判断する。推定していない経路がある場合、処理はステップ７０２に移行する。全ての経路に関して推定処理を実行している場合、状況推定処理は終了する。上述の例を用いて説明すると、これからコミュニケーション（例えばメール送信）する対象（コミュニケーション先）が「企業Ａ−事業部Ｙ」であるので、「企業Ｂ」と「企業Ａ−事業部Ｙ」以外の経路が状況推定処理の対象となる。この場合、上述のように「企業Ｂ」と「企業Ａ−事業部Ｘ」と「企業Ｂ」と「企業Ａ−事業部Ｚ」の２つの経路が存在することになるので、２回処理を行うことになる。
【００６２】
（ii）ステップ７０２
状況推定処理部１２４は、コミュニケーション元の詳細情報を取得する。例えば、コミュニケーション元が「企業Ｂ」の場合、状況推定処理部１２４は、図２のユーザ管理情報ＤＢ１３２から、３行目〜９行目の情報を取得する。
【００６３】
（iii）ステップ７０３
状況推定処理部１２４は、コミュニケーション先の詳細情報を取得する。例えば、コミュニケーション先が「企業Ａ−事業部Ｘ」の場合、状況推定処理部１２４は、図２のユーザ管理情報ＤＢ１３２から、１行目と２行目の情報を取得する。
【００６４】
（iv）ステップ７０４
状況推定処理部１２４は、コミュニケーション履歴ＤＢ１３１の検索を行う。ここでは、状況推定処理部１２４は、ステップ７０２とステップ７０３で取得したコミュニケーション元とコミュニケーション先の詳細情報をコミュニケーションの開始時に含むコミュニケーション履歴ＤＢ１３１を検索する。
【００６５】
ステップ７０４について、図２及び図３を用いて具体的に説明する。状況推定処理部１２４は、ステップ７０２とステップ７０３で取得した図２の３行目〜９行目と１行目と２行目の情報が、各ＣＯＭＩＤ３０１の時系列の最初の履歴（コミュニケーションの開始時）のコミュニケーション元３０２とコミュニケーション先３０３に同時に存在するか検索する。例えば、ＣＯＭ００００１の場合、図２の１行目のユーザ名２０１が図３の１行目のコミュニケーション元３０２に存在し、図２の４行目のユーザ名２０１が図３の１行目のコミュニケーション先３０３に存在する。従って、状況推定処理部１２４は、対応するＣＯＭＩＤであるＣＯＭ００００１のコミュニケーション履歴情報（図３の１行目〜１１行目）を取得する。図２の例では、ＣＯＭ００００１しか存在しないが、条件に該当するＣＯＭＩＤ３０１のコミュニケーション履歴情報はすべて取得する。
【００６６】
（v）ステップ７０５
状況推定処理部１２４は、ステップ７０４で取得したコミュニケーション履歴情報から、コミュニケーションの頻度をチェックする。例えば、該当するコミュニケーション履歴情報がＣＯＭ００００１のみの場合（以下の処理も同様とする）、頻度は、２９回となる。一実施形態として、頻度が設定した閾値（例えば、２０）を超えていた場合、「該当あり（関係に問題がある可能性あり）」と判定する。
【００６７】
（vi）ステップ７０６
状況推定処理部１２４は、ステップ７０４で取得したコミュニケーション履歴情報からコミュニケーションが行われた時間をチェックする。ここでは、異常と想定される時間にコミュニケーションを行った履歴があるかどうかをチェックする。例えば、異常と想定される時間をＡＭ００：００〜ＡＭ０６：００までと設定すると、この時間帯にコミュニケーションが行われていれば「該当あり（関係に問題がある可能性あり）」と判定する。
【００６８】
（vii）ステップ７０７
状況推定処理部１２４は、ステップ７０４で取得したコミュニケーション履歴情報から、コミュニケーションに関わる部門（部署）の数、すなわち、コミュニケーション履歴情報におけるコミュニケーション元３０２とコミュニケーション先３０３の部署数をチェックする。上記例では、該当するコミュニケーション履歴情報から、部門の数としては３となる。例えば、部門の数が設定した閾値（例えば、２）を超えていた場合、「該当あり（関係に問題がある可能性あり）」と判定する。
【００６９】
（viii）ステップ７０８
状況推定処理部１２４は、ステップ７０４で取得したコミュニケーション履歴情報から、コミュニケーション元３０２とコミュニケーション先３０３の役職の数のチェックをする。上記例では、役職の数としては３となる（企業ごとの役職は、区別する）。例えば、役職の数が設定した閾値（例えば、２）を超えていた場合、「該当あり（関係に問題がある可能性あり）」と判定する。
【００７０】
（ix）ステップ７０９
最後に、状況推定処理部１２４は、状況判別処理を行う。判別処理は、さまざまな定義が可能であるが、最小の判定項目として、ステップ７０８の処理（役職）において「該当あり」だった場合、経路の状況として「報告推奨」と判定する。そして、状況推定処理部１２４は、「報告推奨」と判定された結果（状況推定結果）を記憶装置１３０に蓄積する。なお、蓄積された状況推定結果に関しては、ユーザが端末装置１０１から検索処理を実行することにより、ユーザが入力した検索条件に合致する状況推定結果がサーバ装置１１０から対象の端末装置１０１に送信され、表示部１０４に表示されるようにしても良い。
【００７１】
＜処理高速化のための変形例＞
図６のステップ６０５の処理において、大企業同士のコミュニケーションにおいては、組織階層が深くなり、ユーザも増えるため、状況推定対象の経路が大量となってしまう可能性がある。このような場合において、処理を高速化するための手段としてはいくつか考えることができる。
【００７２】
（i）変形例１
１つ目のバリエーションとしては、経路計算対象の組織階層を浅く設定することが挙げられる。例えば、図２のケースでは、２段階（例：企業Ａ−事業部Ｘ）までしか表現されていない。このため、３段階、４段階・・・と表現した場合に比べ、状況推定対象となり得る経路を少なくすることができ、処理を高速化することができる。該当するユーザが所属する組織以外の組織からの経路（別の経路）における状況を推定するものであるため、組織階層を浅くすれば別経路の数が少なくなり、推定対象を絞ることができるようになるからである。
【００７３】
（ii）変形例２
２つ目のバリエーションとしては、古いコミュニケーション履歴情報を状況推定対象から除外することがある。経路の状況は、時間とともに変化するものであるので、状況推定対象とするコミュニケーション履歴情報は、状況推定をする時点から、一定期間にすべきである。例えば、最新のコミュニケーションの時間が所定時刻よりも前であった場合には対象から除外することが考えられる。これにより、処理を高速化することができる。
【００７４】
（iii）変形例３
３つ目のバリエーションとしては、状況推定結果をキャッシュする方法である。図１に示されるように、状況推定処理部１２４はサーバ装置１１０で動作しているため、ある端末装置１０１が計算した経路の状況と同じ経路の状況を別の端末装置１０１が要求する場合がある。この場合、状況推定結果をキャッシュしておくことで、処理を高速化することができる。
【００７５】
（iv）変形例４
４つ目のバリエーションとしては、定期的に、図７のような各経路の状況を事前計算したインデックスを作り（例えば、バッチ処理時にインデックスを作成）、状況推定時は、コミュニケーション履歴ＤＢ１３１ではなく、インデックスを参照する方法である。この方法を採用した場合は、状況推定結果まで得られるので、インデックスを参照して結果が得られる経路については、ステップ６０５の処理をスキップすることができる。インデックスは定期的に更新する。インデックスの容量とインデックス作成コストはかかるが、状況推定処理は非常に高速になる。ただし、インデックスを参照するため、最新のコミュニケーション履歴ＤＢ１３１による状況推定結果とはズレが生じる場合がある。
【００７６】
（v）変形例５
５つ目のバリエーションとしては、コミュニケーション元が明示的に状況推定を除外する経路を指定する処理である。例えば、状況推定する必要がない場合や、状況推定処理時に考慮する必要がない場合に、ユーザはこれを指定できる。具体的には、ステップ６０２の処理でコミュニケーション元のユーザが指定することになる。
【００７７】
（vi）その他
これら、５つの方法は、相反する仕組みではないため、組み合わせて実施することで、より効果を高めることができる。
【００７８】
また、図７のステップ７０２の処理において、コミュニケーション元のユーザがコミュニケーションの内容を入力し終える（例えば、これから送ろうとするメールを作成完了する）前に、状況推定処理を完了するには処理を高速化する必要がある。上述の５つの方法をさらに高速化するために、コミュニケーション元の端末装置１０１のコミュニケーション部１０７は、コミュニケーション元のユーザがコミュニケーション先の情報を入力するより前に（ステップ７０１より前に）、入力するコミュニケーション先を予測して、状況推定処理を行っておき、状況推定結果を端末内にキャッシュしておく方法が考えられる。具体的には、例えば、コミュニケーション部１０７が定期的（例えば、毎日午前９時）にサーバ装置１１０のコミュニケーション履歴を参照し、当該コミュニケーション履歴から、その日にコミュニケーションする相手を予測することで、状況推定処理を高速化する。
【００７９】
＜通信状況把握システムの動作（推定結果報告処理）＞
図８は、ステップ６０６（図６）の推定結果報告判断処理部１２５による推定結果報告処理の詳細を説明するためのフローチャートである。
【００８０】
（i）ステップ８０１
推定結果報告判断処理部１２５は、状況推定処理部１２４による推定結果が「報告推奨（該当あり）」と判断されたかチェックする。報告推奨と判断されている場合、処理はステップ８０２に移行する。報告推奨と判断されていない場合、処理は終了する。
【００８１】
（ii）ステップ８０２
推定結果報告判断処理部１２５は、ユーザがこれからコミュニケーションするコミュニケーション先（ユーザがステップ６０１で入力したコミュニケーション先：部署１_４０１に該当）の情報と報告推奨と判断された推定経路のコミュニケーション先（部署２_４０２に該当）の情報に基づいて、関連部署情報ＤＢ１３３からこれらの部署間の関連度４０７の情報を取得する。
【００８２】
（iii）ステップ８０３
推定結果報告判断処理部１２５は、ステップ８０２で取得した関連度４０７が所定の閾値（例えば、３）以下か判断する。取得した関連度４０７が当該閾値以下である場合、処理はステップ８０４に移行する。当該関連度４０７が当該閾値より大きい場合、処理はステップ８０５に移行する。
【００８３】
（iv）ステップ８０４
推定結果報告判断処理部１２５は、通信部１１４を介して、対象のユーザが使用する端末装置１０１に報告すべき問題がない可能性が高いことを通知する。これを受けて、端末装置１０１は、表示部１０４には何も表示しない、或いは、問題なしと表示する。なお、図５の＃２は、問題ないことを積極的に表示する例を示している。
【００８４】
このように、関連度４０７が当該閾値以下の場合、ステップ６０５で状況推定結果が「報告推奨」と推定されたときであっても、状況推定結果を推定結果報告表示する対象から除外する。これは、状況推定結果として「報告推奨」と推定されても、コミュニケーション先との関連性が薄いため、通常のコミュニケーションをしても問題ないからであり、ユーザにとって不要な情報を報告することによる煩わしさを回避するためである。
【００８５】
（v）ステップ８０５
推定結果報告判断処理部１２５は、通信部１１４を介して、対象のユーザ使用する端末装置１０１に状況推定処理によって推定した結果（問題がある可能性あり）を通知する。これを受けて、当該端末装置１０１は、表示部１０４に問題がある可能性があることを表示する。
【００８６】
＜まとめ＞
（i）本実施形態では、サーバ装置は、端末装置を利用するユーザ（例えば、これからメールを作成し、特定の企業の特定のユーザに送信しようとしているユーザ）の情報であるコミュニケーション元の情報とコミュニケーション先の情報とを端末装置から受信する。そして、サーバ装置は、受信したコミュニケーション元及びコミュニケーション先の情報に基づいて、コミュニケーション元とコミュニケーション先が所属する組織名を取得し、当該組織の間でコミュニケーションしたユーザの組み合わせを、状況を推定するための経路として特定する。より詳細には、これから通信しようといているコミュニケーション元とコミュニケーション先との間の経路以外の経路（ただし、同一企業間（Ａ企業とＢ企業）内の経路）が通信状況を推定する対象として特定される。サーバ装置は、この特定した経路ごとに状況を推定する。この推定結果は記憶装置に蓄積しておいても良いし、積極的に当該ユーザに知らせるようにしても良い。このようにすることにより、当該ユーザ自身が使用する経路以外の別の経路において問題が発生している可能性があるか否か知ることができる。よって、これから実施するコミュニケーションを慎重に行うべきかの判断材料とすることができるようになる。
【００８７】
サーバ装置は、全ての推定結果をユーザに知らせる必要はない。当該ユーザが所属する組織と密接に関係する同一企業の別組織以外の通信経路で問題の可能性があったとしても特に影響がない場合が多いからである。そのため、サーバ装置は、端末装置を利用するユーザが指定したコミュニケーション先と、状況推定処理によって推定された経路におけるコミュニケーション先との密接度を示す部署関連度情報に基づいて、状況推定処理によって推定した結果を当該ユーザの端末装置に通知するか否かを判断する。これにより、処理や通信の無駄を回避することができ、当該ユーザによる確認作業を課さなくても良くなる。
【００８８】
サーバ装置は、通信状況を推定する際に、コミュニケーションの頻度、時刻、部門、及び役職のいずれか１つの情報を用いるようにする。より具体的には、コミュニケーション履歴情報に含まれるコミュニケーションの頻度が第１の閾値を超える場合、コミュニケーション履歴情報に含まれる時刻が所定の時間帯を含む場合、ユーザ管理情報及びコミュニケーション履歴情報から取得した部門の数が第２の閾値を超える場合、或いは、ユーザ管理情報及びコミュニケーション履歴情報から取得した役職の数が第３の閾値を超える場合、対象の経路において問題がある可能性ありと推定する。これらのうち何れか１つに該当する場合に、問題発生の可能性を検出しても良いし、任意の組み合わせによって問題の可能性を検出しても良い。このようにすることにより、コミュニケーション（例えば、メール）内容（キーワード）からは問題の可能性があるか否か検出できない場合であっても、効率的に問題が生じている可能性を検出することができるようになる。
【００８９】
（ii）本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００９０】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【００９１】
さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【００９２】
最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。
【００９３】
さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
【００９４】
加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する特許請求の範囲で示される。
【符号の説明】
【００９５】
１０１  端末装置
１０２  ＣＰＵ
１０３  メモリ
１０４  表示部
１０５  記憶装置
１０６  オペレーティングシステム（ＯＳ）
１０７  コミュニケーション部
１０８  通信部
１０９  バス
１１０  サーバ装置
１１２  ＣＰＵ
１１３  メモリ
１１４  通信部
１２０  記憶装置
１３０  記憶装置
１５０  バス
１６０  ネットワーク
【図１】
0006676344.tif 000002
【図２】
0006676344.tif 000003
【図３】
0006676344.tif 000004
【図４】
0006676344.tif 000005
【図５】
0006676344.tif 000006
【図６】
0006676344.tif 000007
【図７】
0006676344.tif 000008
【図８】
0006676344.tif 000009