特開 2022-32588 コミュニケーション管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022032588

(43)【公開日】2022-02-25

(54)【発明の名称】コミュニケーション管理システム

(51)【国際特許分類】

   G06Q 10/10 20120101AFI20220217BHJP

【ＦＩ】

G06Q10/10

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2020136486

(22)【出願日】2020-08-12

(71)【出願人】

【識別番号】518429539

【氏名又は名称】サークレイス株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】特許業務法人はるか国際特許事務所

(72)【発明者】

【氏名】井上 賢

(72)【発明者】

【氏名】深谷 正人

(72)【発明者】

【氏名】フェレイラ アマラル ジョアォン パウロ

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA11

5L049AA20

(57)【要約】      （修正有）

【課題】ビジネスシーンにおけるコミュニケーションを、そのビジネスの目的に即した単位毎に可視化可能にする。
【解決手段】クライアント端末３において、コミュニケーション管理システム１００は、ユーザの指示に基づいて、コミュニケーショングループを作成するコミュニケーショングループ作成部１０５と、外部コミュニケーションクライアントからの通知及び外部コミュニケーションクライアントへの通知要求に基づいて、前記外部コミュニケーションクライアントによりなされたコミュニケーションを取得するコミュニケーション取得部１０７と、取得したコミュニケーションに、グループ特定情報に基づいて、コミュニケーションが属するコミュニケーショングループを特定し紐づけるコミュニケーション紐づけ部１０８と、一又は複数のコミュニケーショングループに紐づけられたコミュニケーションを一覧表示するコミュニケーション一覧表示部１０４と、を有する。
【選択図】図３

【特許請求の範囲】

【請求項1】

ユーザの指示に基づいて、コミュニケーショングループを作成する、コミュニケーショングループ作成部と、
外部コミュニケーションクライアントからの通知及び、外部コミュニケーションクライアントへの通知要求に基づいて、前記外部コミュニケーションクライアントによりなされたコミュニケーションを取得するコミュニケーション取得部と、
取得した前記コミュニケーションに、グループ特定情報に基づいて、当該コミュニケーションが属するコミュニケーショングループを特定し紐づける、コミュニケーション紐づけ部と、
一又は複数のコミュニケーショングループに紐づけられた前記コミュニケーションを一覧表示する、コミュニケーション一覧表示部と、
を有するコミュニケーション管理システム。

【請求項2】

前記グループ特定情報は、前記コミュニケーションに含まれるメタデータ、前記コミュニケーションのユーザ、及び、前記コミュニケーションのコンテンツ内容の少なくともいずれかを含む、
請求項１に記載のコミュニケーション管理システム。

【請求項3】

前記コミュニケーション紐づけ部は、複数種類の前記グループ特定情報に基づいて、当該コミュニケーションが属するコミュニケーショングループを特定するとともに、
前記グループ特定情報の種類ごとに優先順位が設けられているか、または、前記グループ特定情報ごとにスコア付けをする、
請求項２に記載のコミュニケーション管理システム。

【請求項4】

前記コミュニケーション紐づけ部により、その属するコミュニケーショングループの特定がなされなかった前記コミュニケーションに対し、当該コミュニケーションが属するコミュニケーショングループを作成する自動コミュニケーショングループ作成部を有する、
請求項１～３のいずれか１項に記載のコミュニケーション管理システム。

【請求項5】

前記外部コミュニケーションクライアントにソフトフォンが含まれ、前記コミュニケーション取得部は、通話音声をコミュニケーションとして取得する、
請求項１～４のいずれか１項に記載のコミュニケーション管理システム。

【請求項6】

前記コミュニケーション取得部は、通話音声データをテキストデータに変換し、
前記コミュニケーション紐づけ部は、前記テキストデータを前記グループ特定情報として用いる、
請求項５に記載のコミュニケーション管理システム。

【請求項7】

前記コミュニケーショングループは、自己のグループに対し、上位及び下位の少なくともいずれかとなる他のコミュニケーショングループへの参照を持つことにより、前記コミュニケーショングループ間の階層構造を保存可能である、
請求項１～６のいずれか１項に記載のコミュニケーション管理システム。

【請求項8】

前記コミュニケーショングループ間の階層構造及び、前記コミュニケーショングループの期間情報に基づいて、前記コミュニケーショングループを一の軸に、前記期間情報を他の軸とするガントチャートを作成するガントチャート作成部を有する、
請求項７に記載のコミュニケーション管理システム。

【請求項9】

前記コミュニケーショングループには、アクティブ又はノンアクティブの属性が設定され、
前記コミュニケーション紐づけ部は、取得した前記コミュニケーションに、ノンアクティブのコミュニケーショングループを紐づけない、
請求項１～８のいずれか１項に記載のコミュニケーション管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コミュニケーション管理システムに関する。

【背景技術】

【0002】

現在ビジネスシーンにおいてコミュニケーション手段は多様化しており、電話やメールに加え、チャット、インスタントメッセージなど種々の手段が使用されている。そして、同じ形式のコミュニケーション手段であったとしても、当該サービスの提供元が異なればコミュニケーション手段は独立しており、専用のコミュニケーションクライアントを用いる必要がある。

【0003】

このような事情を踏まえ、複数のコミュニケーション手段を統合して扱うことのできる統合アプリケーションもリリースされている。しかしながら、かかる統合アプリケーションは、一種のソフトウェアランチャーにすぎず、結局のところ、統合アプリケーションを起動した後、利用しようとする特定のコミュニケーション手段を選択するにとどまるため、各コミュニケーション手段が互いに独立していることに変わりはない。

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、ビジネスシーンにおけるコミュニケーションは、そのビジネスの目的に即した単位毎に行われ、コミュニケーション手段毎に分割された単位ではない。そして、一のビジネスは、特定の組織内の人間に閉じたものではなく、関係する顧客、サプライヤー、協力事業者といった様々な組織外の人間をも含めたプロジェクトとして遂行される場面が大多数となりつつあるところ、一般に、それぞれの立場のメンバーが利用し、または利用可能なコミュニケーション手段は互いに異なる。例えば、組織内の人間は社内チャット、顧客とはメールや電話、サプライヤーや協力事業者はそれぞれ異なるチャットツールやグループウェアといった具合である。

【0005】

このようにプロジェクトに関るメンバーが用いるコミュニケーションツールがばらばらであると、そのプロジェクトの遂行にあたって、メンバー間でどのような情報のやり取りがあり、どのような情報が共有されあるいはされていないのか追跡することはきわめて困難である。

【0006】

プロジェクトのメンバー全員が特定のコミュニケーション手段のみを用いるよう強制すればこの問題はある程度の解決を見るが、立場の異なるメンバーにこれを強制することは非現実的であるし、また、そのようにしたとしても、参加するメンバーが行うコミュニケーションの全てが一のプロジェクトに関するもののみであるとは限らない以上、結局、プロジェクトに関してなされたコミュニケーションを可視化する目的においては全く不十分である。

【0007】

本発明は、上述した事情に鑑みてなされたものであり、その解決しようとする課題は、ビジネスシーンにおけるコミュニケーションを、そのビジネスの目的に即した単位毎に可視化可能にすることである。

【課題を解決するための手段】

【0008】

上記課題を解決すべく本出願において開示される発明は種々の側面を有しており、それら側面の代表的なものの概要は以下のとおりである。

【0009】

（１）ユーザの指示に基づいて、コミュニケーショングループを作成する、コミュニケーショングループ作成部と、外部コミュニケーションクライアントからの通知及び、外部コミュニケーションクライアントへの通知要求に基づいて、前記外部コミュニケーションクライアントによりなされたコミュニケーションを取得するコミュニケーション取得部と、取得した前記コミュニケーションに、グループ特定情報に基づいて、当該コミュニケーションが属するコミュニケーショングループを特定し紐づける、コミュニケーション紐づけ部と、一又は複数のコミュニケーショングループに紐づけられた前記コミュニケーションを一覧表示する、コミュニケーション一覧表示部と、を有するコミュニケーション管理システム。

【0010】

（２）（１）において、前記グループ特定情報は、前記コミュニケーションに含まれるメタデータ、前記コミュニケーションのユーザ、及び、前記コミュニケーションのコンテンツ内容の少なくともいずれかを含む、コミュニケーション管理システム。

【0011】

（３）（２）において、前記コミュニケーション紐づけ部は、複数種類の前記グループ特定情報に基づいて、当該コミュニケーションが属するコミュニケーショングループを特定するとともに、前記グループ特定情報の種類ごとに優先順位が設けられているか、または、前記グループ特定情報ごとにスコア付けをする、コミュニケーション管理システム。

【0012】

（４）（１）～（３）のいずれかにおいて、前記コミュニケーション紐づけ部により、その属するコミュニケーショングループの特定がなされなかった前記コミュニケーションに対し、当該コミュニケーションが属するコミュニケーショングループを作成する自動コミュニケーショングループ作成部を有する、コミュニケーション管理システム。

【0013】

（５）（１）～（４）のいずれかにおいて、前記外部コミュニケーションクライアントにソフトフォンが含まれ、前記コミュニケーション取得部は、通話音声をコミュニケーションとして取得する、コミュニケーション管理システム。

【0014】

（６）（５）において、前記コミュニケーション取得部は、通話音声データをテキストデータに変換し、前記コミュニケーション紐づけ部は、前記テキストデータを前記グループ特定情報として用いる、コミュニケーション管理システム。

【0015】

（７）（１）～（６）のいずれかにおいて、前記コミュニケーショングループは、自己のグループに対し、上位及び下位の少なくともいずれかとなる他のコミュニケーショングループへの参照を持つことにより、前記コミュニケーショングループ間の階層構造を保存可能である、コミュニケーション管理システム。

【0016】

（８）（７）において、前記コミュニケーショングループ間の階層構造及び、前記コミュニケーショングループの期間情報に基づいて、前記コミュニケーショングループを一の軸に、前記期間情報を他の軸とするガントチャートを作成するガントチャート作成部を有する、コミュニケーション管理システム。

【0017】

（９）（１）～（８）のいずれかにおいて、前記コミュニケーショングループには、アクティブ又はノンアクティブの属性が設定され、前記コミュニケーション紐づけ部は、取得した前記コミュニケーションに、ノンアクティブのコミュニケーショングループを紐づけない、コミュニケーション管理システム。

【図面の簡単な説明】

【0018】

【図1】コミュニケーション管理システムの概念図である。

【図2】サーバ及びクライアント端末の物理構成を示す一般的なコンピュータの構成図である。

【図3】コミュニケーション管理システムの機能的構成を示す機能ブロック図である。

【図4】コミュニケーショングループデータベースに登録されるコミュニケーショングループについての情報の具体的な例を示す図である。

【図5】コミュニケーションデータベースに登録されるコミュニケーションについての情報の具体的な例を示す図である。

【図6】ユーザデータベースに登録されるユーザについての情報の具体的な例を示す図である。

【図7】コミュニケーション管理システムにより管理されるコミュニケーショングループ全体の空間を示す。

【図8】コミュニケーション一覧表示部により一覧表示されるコミュニケーションのユーザインタフェースの例を示す図である。

【図9】コミュニケーショングループ作成部の動作を示すフロー図である。

【図10】ユーザ編集部の動作を示すフロー図である。

【図11】コミュニケーション取得部の動作を示すフロー図である。

【図12】コミュニケーション紐づけ部の動作を示すフロー図である。

【図13】図４のグループについてガントチャート作成部が作成しユーザに表示するガントチャートの例である。

【発明を実施するための形態】

【0019】

以下、本発明の実施形態に係るコミュニケーション管理システム１００を、図面を参照して説明する。

【0020】

図１は、コミュニケーション管理システム１００の概念図である。コミュニケーション管理システム１００は、コンピュータを利用した情報処理システムであり、単体のコンピュータそれぞれにシステムソフトウェアをインストールすることにより、スタンドアロンの形式で実現することもできるが、本実施形態では、情報通信ネットワークＮを介したサーバ＝クライアントシステムとして実現されている例を示す。すなわち、主たる情報処理及びユーザに紐づけられたデータの保持はネットワークＮに接続されたサーバ２によりなされ、サーバ２と情報通信可能にネットワークＮに接続されたクライアント端末３では、コミュニケーション管理システム１００を利用するユーザに対するインタフェースを主として提供する。

【0021】

なお、図１ではクライアント端末３を一台のみ示しているが、コミュニケーション管理システム１００に含まれるクライアント端末３の数に特に制限はなく、複数のユーザが同時にコミュニケーション管理システム１００を利用してよい。また、クライアント端末３として、図１ではヘッドセット４が接続されたラップトップＰＣの形態を示しているが、クライアント端末３の形式に限定はなく、据え置き型ＰＣでもよく、スマートフォンやタブレット端末などの携帯情報端末であっても差し支えない。

【0022】

ネットワークＮは情報通信可能なコンピュータネットワークであればその態様は特に限定されず、どのようなものであってもよいが、本例ではインターネットであり、上述の態様により、コミュニケーション管理システム１００は、クライアント端末３を使用するユーザに対して、いわゆるクラウドコンピューティングにより、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供されることになる。

【0023】

なお、図１では、サーバ２として１台の機器を示したが、これは一例であり、サーバ２を複数台用意し、分散コンピューティングの手法により動作させ、あるいはミラーリングを行ってもよい。また、コミュニケーション管理システム１００を共用するユーザのグループが複数ある場合には、ユーザが、自身が属さないユーザグループの情報を参照することができないよう、各ユーザに発行されたアカウントによりアクセス権限に制限が設けられるほか、いわゆるテナントシステムにより、ユーザグループ毎に使用するサーバ２上の領域を区分し、他のユーザに割り当てられた領域にアクセスできないようにすることで、情報セキュリティを確保するようにしてよい。

【0024】

また、図１では、ネットワークＮに接続されたコミュニケーション管理システム１００外の機器として、ＰＣ５、スマートフォン６、タブレット端末７を同時に示している。これら機器は、コミュニケーション管理システム１００には含まれないため、ネットワークＮとの接続を破線で示している（ＰＣ５については有線、スマートフォン６及びタブレット端末７は無線によるものとして図示している）。これらの機器は、ネットワークＮを経由して、適宜のコミュニケーション手段によりクライアント端末３と情報通信を行う。

【0025】

図２はサーバ２及びクライアント端末３の物理構成を示す一般的なコンピュータ１の構成図である。基本的には、サーバ２およびクライアント端末３は標準的なコンピュータであり、その差は情報処理能力と記憶容量の違いである。ただし、クライアント端末３としてどのようなコンピュータを使用するかはユーザの任意であるため、サーバ２に匹敵するあるいはこれを上回る処理能力を有するコンピュータを用意することも可能であるが、本例では、クラウドコンピューティングにより主要な情報処理及びデータの記憶はサーバ２が担うため、ユーザは、クライアント端末３として安価で処理能力の低いコンピュータを利用できる。

【0026】

コンピュータ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１ａ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１ｂ、外部記憶装置１ｃ、ＧＣ（Ｇｒａｐｈｉｃｓ Ｃｏｎｔｒｏｌｌｅｒ）１ｄ、入力デバイス１ｅ及びＩ／Ｏ（Ｉｎｐｕｒ／Ｏｕｔｐｕｔ）１ｆがデータバス１ｇにより相互に電気信号のやり取りができるよう接続されている。ここで、外部記憶装置１ｃはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の静的に情報を記録できる装置である。またＧＣ１ｄからの信号はＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）やいわゆるフラットパネルディスプレイ等の、使用者が視覚的に画像を認識するモニタ１ｈに出力され、画像として表示される。入力デバイス１ｅはキーボードやマウス、タッチパネル等の、ユーザが情報を入力するための機器であり、Ｉ／Ｏ１ｆはコンピュータ１が外部の機器と情報をやり取りするためのインタフェースである。ＣＰＵ１ａはコンピュータ１が必要とする情報処理の負荷に応じて、複数用意されて並列演算がなされるように構成されていてもよい。

【0027】

コンピュータ１をサーバ２あるいはクライアント端末３として機能させるためのアプリケーションプログラムは外部記憶装置１ｃにインストールされ、必要に応じてＲＡＭ１ｂに読みだされてＣＰＵ１ａにより実行される。また、かかるプログラムは、適宜の光ディスク、光磁気ディスク、フラッシュメモリ等の適宜のコンピュータ可読情報記録媒体に記録されて提供されても、インターネット等の情報通信回線を介して提供されてもよい。コンピュータ１をクライアント端末３として機能させるアプリケーションに関しては、ｗｅｂブラウザのような汎用のソフトウェアを用い、Ｉ／Ｏ１ｆを介してサーバ２により機能が提供される、いわゆるクラウドコンピューティングにより提供されてもよい。

【0028】

図３は、コミュニケーション管理システム１００の機能的構成を示す機能ブロック図である。同図に示したコミュニケーション管理システム１００の各機能は、サーバ２あるいはクライアント端末３のＣＰＵ１ａがＲＡＭ１ｂ上に展開されたプログラムコードを読み込み実行し、あるいはＲＡＭ１ｂ又は外部記憶装置１ｃの所定の領域が特定の機能に割り当てられ、もしくはその両方等により実現されるものであり、同図に示す各機能ブロックは、そのようにして実現されるコミュニケーション管理システム１００の機能を概念的に示したものである。

【0029】

また、図３には、コミュニケーション管理システム１００だけでなく、クライアント端末３とクライアント端末３上で実行される他のアプリケーションである、メールクライアント３０、チャットクライアント３１及びソフトフォン３２と、適宜の通信回線を介してクライアント端末３と情報通信を行う外部の機器である、ＰＣ５、スマートフォン６、タブレット端末７及び電話機８が示されている。

【0030】

ここで、メールクライアント３０、チャットクライアント３１及びソフトフォン３２は、クライアント端末３上で実行され、コミュニケーション管理システム１００に含まれないコミュニケーションを目的としたアプリケーションの例として示したものであり、以降、かかるアプリケーションを外部コミュニケーションクライアントと総称する。クライアント端末３上で実行される外部コミュニケーションクライアントの種別及び数には全く限定がなく、クライアント端末３を使用するユーザが必要とするアプリケーションを適宜使用するものである。

【0031】

なお、図３では図示の都合上、コミュニケーション管理システム１００及び外部コミュニケーションクライアント（メールクライアント３０、チャットクライアント３１及びソフトフォン３２）がクライアント端末３に含まれるように示しているが、これらのソフトウェアによる処理は必ずしもクライアント端末３上ですべて実行される必要はなく、ネットワークＮを介したクラウドコンピューティングにより提供されてよい。すなわち、図３に示したコミュニケーション管理システム１００の機能ブロックは、実際には図１に示したサーバ２により実行されてよく、クライアント端末３は、コミュニケーション管理システム１００のユーザインタフェースと、場合によって情報処理の一部を提供するのみであっても差し支えない。外部コミュニケーションクライアントについても同様であり、それらソフトウェアの一部または全部がスタンドアロンで実行されるか、クラウドコンピューティングにより実行されるかは任意である。

【0032】

メールクライアント３０及びチャットクライアント３１はインターネット等の一般的な電気通信回線により、ＰＣ５、スマートフォン６、タブレット端末７等の外部機器と情報通信を行う。なお、図３では理解を容易とするため、クライアント端末３がこれら外部機器と直接通信をするかのように示しているが、一般的には、メール、チャット、インスタントメッセージといったサービスではそのサービスを提供するサーバを介して間接的に情報通信を行う。もちろん、いわゆるピアツーピアにより外部機器と直接情報通信を行うものであっても差し支えない。

【0033】

また、ソフトフォン３２は、電話回線を介して外部の電話機８と音声通話を行う。クライアント端末３は電話回線と接続するためのモデムを備えていてもよいし、ネットワークＮ上に設置されたＶＯＩＰゲートウェイを介して電話回線と接続するものであってもよい。また、相手方の電話機８自体がネットワークＮに接続されたＩＰ電話機である場合には、ネットワークＮを介して直接音声通話を行えばよい。

【0034】

なお、以降本明細書では、「コミュニケーション」という語を、ユーザが何らかのコミュニケーション手段を用いて行う意思疎通のための情報の一単位を指すものとして用いる。例えば、コミュニケーション手段が電子メールであれば、一通のメールが一のコミュニケーションに相当し、コミュニケーション手段がチャットであれば、一のチャットにおける発言が一のコミュニケーションに相当し、コミュニケーション手段が電話であれば、一連の音声通話が一のコミュニケーションに該当することになる。「コミュニケーション」は、そういった、種々の相異なるコミュニケーション手段を用いて行われる意思疎通において認識さされる基本単位を総称するものである。

【0035】

そして、本明細書では、コミュニケーションは、特定の達成すべき目的に即して行われるものを対象としている。ここで、特定の達成すべき目的は、多くの場合にはビジネス上の理由により設定されるものであるが、必ずしも営利目的を必要とするものではない。しかしながら、達成すべき目的がないコミュニケーション、例えば、単なる雑談などは、コミュニケーション管理システム１００により管理すべきコミュニケーションの主たる対象とはされない。ただし、特定の達成すべき目的に関してなされるコミュニケーションに付随してなされる雑談などのコミュニケーションは、コミュニケーション管理システム１００により管理されて一向に差し支えない。

【0036】

そうした特定の達成すべき目的の例として、本明細書で取り上げるものは、プロジェクトの遂行、タスクの実行、問い合わせの解決である。こういったある共通の目的に関してなされるコミュニケーションを取りまとめる概念を以降では、「コミュニケーショングループ」と呼ぶ。上で挙げた例、プロジェクト、タスクおよび問い合わせは、「コミュニケーショングループ」の事例となっている。すなわち、複数のコミュニケーションがあるプロジェクトに関してなされると、それらのコミュニケーションは、そのプロジェクトに属し、一つのグループにまとめられる。タスクや問い合わせ等についても同様である。

【0037】

コミュニケーショングループデータベース１０１は、コミュニケーショングループについての情報を記憶するデータベースであり、コミュニケーションデータベース１０２は、コミュニレーションについての情報を記憶するデータベースである。また、ユーザデータベース１０３は、コミュニケーション管理システム１００を利用するユーザについての情報を記憶するデータベースである。

【0038】

図４、図５及び図６はそれぞれ、コミュニケーショングループデータベース１０１、コミュニケーションデータベース１０２及びユーザデータベース１０３に登録される情報の具体的な例を示す図である。以下、図４～図１２を参照してコミュニケーションがコミュニケーション管理システム１０４によりどのように管理されるか概要を説明する。

【0039】

図４はコミュニケーショングループデータベース１０１に登録されるコミュニケーショングループについての情報の例を示す図である。同図では、一のコミュニケーショングループについての情報が一行に対応する形式で示されている。

【0040】

コミュニケーショングループの管理情報には種々のものがあり、図４に示した例では、グループ名、種別、コミュニケーショングループＩＤ（図中「ＣＧＩＤ」として示している）、ステータス、説明、期間、上位コミュニケーショングループＩＤ（図中「上位ＣＧＩＤ」として示している）及びメンバーである。

【0041】

グループ名は、コミュニケーショングループの名称であり、図４ではグループ１、グループ２、・・・のように示しているが、コミュニケーション管理システム１０４を利用するユーザがわかりやすいように任意に定めるとよい。例えば、「○○プロジェクト」、「○○様お問い合わせ対応」、「○○の件」などである。

【0042】

種別は、コミュニケーショングループの種類を示している。本実施形態に係るコミュニケーション管理システム１０４では、プロジェクト、タスク、問い合わせの３種を用意しているので、種別はこのいずれかを指し示すことになる。これらコミュニケーショングループの種類の違いについては後ほど改めて説明する。

【0043】

コミュニケーショングループＩＤは、登録されるコミュニケーショングループに一意に定められる標識である。図４ではコミュニケーショングループとして、グループ１からグループ１０までが示されており、そのコミュケーショングループＩＤは互いに異なる。また、この例ではコミュニケーショングループがプロジェクトの場合は「ＰＲ」から始まる通し番号が与えられ、タスク、問い合わせの場合はそれぞれ「ＴＫ」「ＩＮ」から始まる通し番号がコミュケーショングループＩＤとして与えられているが、コミュケーショングループＩＤをどのように発番し割り当てるかは任意であり、ここで示した例に限定されない。また、コミュケーショングループＩＤは人間が理解できるような情報でなくともよく、バイナリデータであってもよいが、後述する理由により、テキストデータである方が望ましい。

【0044】

ステータスは、コミュニケーショングループがアクティブであるかノンアクティブであるかを示すものである。コミュニケーショングループがアクティブであるとは、そのコミュニケーショングループがその目的に沿った活動を継続中であることを意味し、コミュニケーショングループがノンアクティブであるとは、そのコミュニケーショングループがその目的に沿った活動を終了したことを意味している。例えば、プロジェクトの場合、そのプロジェクトが進行中である場合にはプロジェクトはアクティブであり、プロジェクト目標が達成され、あるいはプロジェクトが中止となった場合にはプロジェクトはノンアクティブとなる。タスク、問い合わせについても同様であり、そのタスクが完了したり、問い合わせに対する対応が完了したりすればそれらはノンアクティブとなる。プロジェクト、タスク、問い合わせ以外のコミュニケーショングループを設けた場合にも、同様である。

【0045】

説明は、これを参照したユーザに、コミュニケーショングループの内容を説明するための説明文である。図４では例として、簡潔な説明のみを掲載したが、必要に応じた分量のテキストとしてよいほか、写真などの画像や文書ファイルなどのドキュメントデータ、外部リンクなどを含めてよい。説明の記述形式に限定はないが、ＨＴＭＬやＸＭＬなどのマークアップ言語を用いて記述するようにしてよい。

【0046】

期間は、コミュニケーショングループの目的の遂行に際し定めた期間であって、これを参照したユーザに行動の指針を与えるものである。そのため、期間は必ずしも定める必要があるわけではなく、また、期間の超過や、期間内であるか期間外であるかによって、コミュニケーショングループの管理に影響を及ぼすものではない。ただし、本実施形態では、コミュニケーショングループがタスクである場合には、必ず期間を定める必要があるようにコミュニケーション管理システム１００が設計されている。

【0047】

上位コミュケーショングループＩＤは、コミュニケーショングループ間の従属関係を示す。自己のコミュニケーショングループが他のコミュニケーショングループに従属する場合、従属先のコミュニケーショングループが上位となり、また、自己のコミュニケーショングループに他のコミュニケーショングループが従属する場合、従属先のコミュニケーショングループが下位となる。ここでは、上位となるコミュニケーショングループのコミュケーショングループＩＤを記憶することで、コミュニケーショングループ間の従属関係が保持されるようになっている。なお、本実施形態では上位コミュケーショングループＩＤのみを保持するようになっているが、これに替えて、下位コミュケーショングループＩＤを保持するようにしても、上位と下位の両方のコミュケーショングループＩＤを保持するようにしてもよい。なお、コミュニケーショングループ間の従属関係は、異なる種類のコミュニケーショングループにおいても成立してよい。例えば、図４の例では、グループ３はタスクであるが、プロジェクトであるグループ２に従属している。

【0048】

なお、本例では、コミュニケーショングループ間の従属関係を特定するために、コミュニケーショングループＩＤを用いたが、厳密には、相手方のコミュニケーショングループを特定するに足る情報であればどのようなものを用いてもよいことは明らかである。このように、ＩＤを含む、相手方を特定することができる情報を「参照」と称することとすると、コミュニケーショングループは、自己のグループに対し、上位及び下位の少なくともいずれかとなる他のコミュニケーショングループへの参照を持つことにより、コミュニケーショングループ間の階層構造を保持可能であることになる。このような参照として、ＩＤ以外の情報としては、例えば、コミュニケーショングループの情報の格納先を示すアドレス、例えばＵＲＬやポインタを用いることが考えられる。

【0049】

メンバーは、コミュニケーショングループに属するユーザを示す。あるコミュニケーショングループに属するコミュニケーションは、基本的にそのコミュニケーショングループに属するユーザ（コミュニケーショングループのメンバー）によってなされる。このメンバーは、必ずしも、コミュニケーション管理システム１００の利用権限をもつユーザに限定されない。ユーザの詳細については後述する。

【0050】

図５はコミュニケーションデータベース１０１に登録されるコミュニケーションについての情報の例を示す図である。同図においても、一のコミュニケーショングループについての情報が一行に対応する形式で示されている。

【0051】

コミュニケーションの管理情報にもまた種々のものがあり、図５に示した例では、コミュニケーションＩＤ（図中「ＣＩＤ」として示している）、日時、種別、送信元、受信先、コミュニケーショングループＩＤ（図中「ＣＧＩＤ」として示している）及びコンテンツである。

【0052】

コミュニケーションＩＤは、登録されるコミュニケーションに一意に定められる標識である。図５の例では、コミュニケーションＩＤとして、「ＣＭ」から始まる通し番号が与えられているが、コミュニケーションＩＤをどのように発番し割り当てるかは任意であり、コミュニケーションの種別や送信元または受信先のユーザ、コミュニケーションの日時などの情報をコミュニケーションＩＤの一部または全部として使用してもよい。また、コミュケーションＩＤは必ずしもテキストデータでなくともよく、バイナリデータであってもよい。

【0053】

日時は、コミュニケーションがなされた時点を記録するものであり、例えば、コミュニケーションがメールやチャットであれば、メッセージが送信された時刻、電話であれば着信時刻とすればよい。なお、コミュニケーションが電話のように、時間的に継続する性質のものである場合には、コミュニケーションの終了時刻を併せて記録するようにしてもよい。

【0054】

種別はコミュニケーションの手段を示す。図５では、メール、チャット、電話の区別で示しているが、より詳しく区別してよい。例えば、メールであればそのアカウント毎、またチャットであれば、使用されたチャットツール毎に区別できるように種別を記録してよい。

【0055】

送信元及び受信先は、コミュニケーションの当事者を記録するものであり、そのコミュニケーションの送り手と受け手を記録するものである。ここでの記録は、次に説明するユーザデータベース１０３に登録されたユーザのユーザ名によりなされている。

【0056】

コミュニケーショングループＩＤは、そのコミュニケーションが属するコミュニケーショングループを特定するものであり、コミュニケーショングループデータベース１０１に登録されている既存のコミュニケーショングループのいずれかとなる（例外的に、コミュニケーショングループ自体を新規に作成する場合があるが、それについては後述する）。コミュニケーション管理システム１００では、コミュニケーションを新規に登録する際に、そのコミュニケーションが属するコミュニケーショングループを特定して、そのコミュニケーショングループと紐づける点に特徴がある。

【0057】

本実施形態で示した例では、コミュニケーションに対して、その属するコミュニケーショングループのコミュニケーショングループＩＤを付与することにより、両者を紐づけているが、これは紐づけを行う具体的な手法の一例である。この他には、コミュニケーショングループ側で、同コミュニケーショングループに属するコミュニケーションのコミュニケーションＩＤをまとめて保持するようにしてもよいし、コミュニケーショングループとコミュニケーションとの紐づけによる対応関係を記録したテーブルなどのデータベースを別途保持するようにしてもよい。また、ＩＤによる対応関係の保持に替え、前述したなんらかの参照を用いるようにしてもよい。

【0058】

ここで、コミュニケーションがあるコミュニケーショングループに属するとは、そのコミュニケーションが、その特定のコミュニケーショングループに関してなされているということを意味する。例えば、コミュニケーショングループがプロジェクトの場合、メールやチャット、電話などのコミュニケーションがそのプロジェクトに関してなされているという意味である。その結果、あるプロジェクトに関して、互いに異なる手段によりなされた複数のコミュニケーションがある場合において、当該プロジェクトとの対応関係（紐づけ）を利用することにより、それらコミュニケーションを容易に抽出することができるから、これを後述するように一覧することも可能となる。

【0059】

コンテンツは、コミュニケーションの内容そのものである。メールであれば、そのメールの内容、チャットであれば発言、電話であればその通話内容がコンテンツにあたる。なお、図５ではコミュニケーションの種類がメールの場合に、コンテンツを「（メール本文）」として示しているが、登録されるコンテンツはメールの通信文だけでなく、メールヘッダなどのメタデータもすべて含めるものとすることが望ましい。チャットについても同様であり、同図にはコンテンツとして「（発言）」と示しているが、ユーザ情報や通信経路その他のメタデータを含むものとしてよい。電話については、通話の音声記録を記録してよいほか、これに加え、又は、これに替えて、通話内容を記録したテキストデータを記録してよい。テキストデータの作成については後述する。

【0060】

図６はユーザデータベース１０３に登録されるユーザについての情報の例を示す図である。同図においても、一のユーザについての情報が一行に対応する形式で示されている。

【0061】

ユーザの管理情報として図６に示した例では、ユーザ名、権限、所属、メールアドレス、チャットＩＤ、電話番号が示されている。

【0062】

ユーザ名は、ユーザ名称であり、ここでは、ユーザ名をユーザの識別に用いているため、ユーザ毎に固有の名称が用いられる。なお、ユーザ名として個人の本名（あるいはその一部）や役職など、他のユーザとの重複を許容する名称をユーザ名として用いる場合には、別途、ユーザに固有のユーザＩＤを付与すればよい。

【0063】

権限は、ユーザがコミュニケーション管理システム１００に対して実行できる操作の権限を示すものである。本実施形態に係るコミュニケーション管理システム１００では、アドミニストレータ、エディタ、ユーザ及びゲストの４種の権限を設定しているが、よりきめ細かく権限を設定できるようにしてもよいし、操作の種別ごとに権限を設定できるようにするなどしてもよい。いずれにせよ、コンピュータによる情報処理技術における権限管理は多様なものが実用されており、適した管理技術を適宜設計しあるいは選択すればよい。

【0064】

本例におけるユーザの権限として、アドミニストレータは、コミュニケーション管理システム１００の全ての操作権限を有する管理者を示しており、各データベースへの自由なアクセスや、コミュニケーション管理システム１００のアップデートなどの更改、コミュニケーション管理システム１００へのユーザの登録及び全ての権限の付与を行うことができる。

【0065】

エディタは、コミュニケーション管理システム１００の通常の動作における操作権限を有するユーザであり、後述するコミュニケーショングループの作成や、ユーザ及びゲストの権限を有する者の登録を実行できる。

【0066】

ユーザは、コミュニケーション管理システム１００にアクセスして他のユーザとコミュニケーションを行うユーザを指す。また、ゲストは、コミュニケーション管理システム１００へのアクセス権限を持っておらず、コミュニケーション管理システム１００を利用することはできないが、コミュニケーショングループのメンバーとして、そのコミュニケーションがコミュニケーション管理システム１００により管理されるユーザを指している。

【0067】

上で示した例では、アドミニストレータがコミュニケーション管理システム１００それ自体の管理者、エディタがコミュニケーション管理システム１００により管理されるプロジェクトなどのコミュニケーショングループにおけるリーダ（及びそれに準じる者）、ユーザがプロジェクトなどのコミュニケーショングループの一般メンバー、ゲストがプロジェクトに関してなされる外注先の協力会社や個人事業者、問い合わせを行ってきた一般顧客などを想定しているが、想定されるユーザの実勢に合わせてユーザの権限は柔軟に設計してよい。

【0068】

所属はユーザの所属先を示す情報である。ユーザデータベース１０３には所属のほか、ポジションやデモグラフィックなど管理上必要な管理情報を登録してよい。ただし、これらのユーザの管理情報は、コミュニケーション管理システム１００の技術的な動作自体に関しては必ずしも必要ではなく、どのような情報を管理し、又は管理しないかは任意である。

【0069】

メールアドレス、チャットＩＤ、電話番号はユーザがコミュニケーションを行う際に発信元及び受信先を特定する際に必要となる情報であり、これらをコミュニケーション情報と称する。コミュニケーション情報は、コミュニケーション管理システム１００により捕捉しようとするコミュニケーション手段の数だけ登録すればよく、メールアドレスはアカウント毎、チャットＩＤは使用するチャットツール毎、電話番号は、固定電話と携帯電話など、使用する電話毎に登録して差し支えない。インスタントメッセージやその他のコミュニケーション手段を用いる場合にも同様である。

【0070】

したがって、少なくとも、ユーザデータベース１０３には、ユーザ識別情報（ユーザ名）と紐づけられる形で権限とコミュニケーション情報が登録され、また、ユーザデータベース１０３に登録されるユーザには、コミュニケーション管理システム１００へのアクセス権限を持たないユーザ（上で示した「ゲスト」）が含まれる。

【0071】

さて、図４及び図５で例示したコミュニケーショングループとコミュニケーションがどのような関係にあるのかを、図７に観念的に示す。図７は、コミュニケーション管理システム１００により管理されるコミュニケーショングループ全体の空間を示しており、その中に含まれるコミュニケーショングループと、各コミュニケーショングループに属するコミュニケーションの例が示されている。

【0072】

図７では、コミュニケーショングループを実線太枠で、コミュニケーションを破線太枠で示している。また、自己を示すコミュニケーショングループＩＤを実線細枠で、他のコミュニケーショングループＩＤへの参照を点線細枠で示している。また、各コミュニケーショングループを示す枠の右上のチェックマークは、コミュニケーショングループのアクティブ／ノンアクティブの別を示しており、黒塗りがノンアクティブ、白抜きがアクティブを意味している。また、各コミュニケーショングループのグループ名の隣に、理解を容易にするため、コミュニケーショングループの説明を付した。

【0073】

図４に示したコミュニケーショングループはグループ１～グループ１０の１０グループであり、各コミュニケーショングループ間には上位下位の関係があるため、図７に示すように入れ子構造を取ることができる。すなわち、グループ３、グループ４、グループ７はグループ２に属し、グループ９はグループ８に属している。さらに、グループ５及び６はグループ４に属しているため、グループ２に対して二重の入れ子構造となっている。

【0074】

このような入れ子構造は、コミュニケーショングループが上位又は下位のいずれかとなる他のコミュニケーショングループのコミュニケーショングループＩＤを保持することで実現している。例えば、グループ３は、上位となるグループ２のコミュニケーショングループＩＤである「ＰＲ００００２」を持つことで、グループ２の下位となる。

【0075】

また、上位のコミュニケーショングループとなるグループ２がプロジェクトであるのに対して、下位のコミュニケーショングループであるグループ３、グループ４、グループ７はタスクである。さらに、上位のコミュニケーショングループとなるグループ８が問い合わせであるのに対して、下位のコミュニケーショングループであるグループ９はタスクである。加えて、下位のコミュニケーショングループであるグループ５及び６はタスクであり、その上位となるコミュニケーショングループであるグループ４もまたタスクであるなど、上位下位の関係となるコミュニケーショングループは、その種別に特段の限定はない。

【0076】

また、コミュニケーションは、その入れ子構造中の階層によらず、いずれかのコミュニケーショングループに属する。例えば、コミュニケーションＩＤが「ＣＭ００００１」のコミュニケーションはグループ１に、コミュニケーションＩＤが「ＣＭ００００２」～「ＣＭ００００６」のコミュニケーションはグループ２に属しており、コミュニケーションＩＤが「ＣＭ００００７」及び「ＣＭ００００８」のコミュニケーションは、グループ２の下位となるグループ４に属している。

【0077】

各コミュニケーションがいずれのコミュニケーショングループに属しているかは、コミュニケーションにその属するコミュニケーショングループＩＤが付与されることにより示されている。例えば、コミュニケーションＩＤが「ＣＭ００００１」のコミュニケーションは、コミュニケーショングループＩＤとして「ＰＲ００００１」を持つことで、グループ１に属していることがわかる。

【0078】

このようなデータ構造を有していることで、コミュニケーション管理システム１００は、ある特定のコミュニケーショングループに属するコミュニケーションを、そのコミュニケーションの種別によらず、一覧して表示することができるほか、コミュニケーショングループを限定して検索できるなど、コミュニケーショングループ単位でなされたコミュニケーション全体を容易に把握できるとともに、コミュケーショングループに属するメンバー間での共有が可能である。

【0079】

すなわち、図3に示すように、コミュニケーション管理システム１００は、コミュニケーション一覧表示部１０４を有しており、特定のコミュニケーショングループに属するコミュニケーションを一覧表示することができる。一覧表示されるコミュニケーションは、例えば、図２に示したモニタ１ｈ上に適宜のユーザインタフェースを用いてユーザに提示されてよい。

【0080】

図８は、コミュニケーション一覧表示部１０４により一覧表示されるコミュニケーションのユーザインタフェースの例を示す図である。同図は、ブラウザあるいは専用のクライアントソフトウェアにより、クライアント端末３のモニタ上に表示されるコミュニケーション管理システム１００のＧＵＩの一部分を示している。

【0081】

ＧＵＩ上部のタイトル欄には、コミュニケーション管理システム１００にアクセスし利用しているユーザの情報やその他の情報が適宜表示されてよい。図８では詳細な表示内容は省略しているが、同タイトル欄右端にある２つのシンボルは、右側が選択することによりユーザアカウントに関する操作および表示をするもの、左側が後ほど説明するガントチャートの表示を指示するものとなっている。

【0082】

ＧＵＩ下部左側の欄には、ここでは、コミュニケーション管理システム１００に登録され管理されているコミュニケーショングループのリストが示されている。各グループ名（「グループ１」～「グループ１０」）の左側に示されているシンボルは、コミュニケーショングループの種別を示しており、歯車のシンボルはプロジェクト、チェックマーク付きクリップボードのシンボルはタスク、そして、クエスチョンマーク入り吹き出しのシンボルは問い合わせをそれぞれ意味している。なお、コミュニケーショングループの種別をリスト上で示すか否か、またその表示の方法は任意であり、ここではその一例を示しているにすぎない。以下の説明においても、具体的な情報の配置やその表現方法は例示であり、デザインにより任意に変更される。

【0083】

コミュニケーショングループの種別を示すシンボルの左側に示されているシンボルは、コミュニケーショングループの階層の伸長表示の操作を示すものである。すなわち、「－」のシンボルを、ユーザが画面をタッチしたりマウスでクリックしたりするなどして選択すると、そのコミュニケーショングループの下位の階層にあたるコミュニケーショングループが折り畳まれ、「＋」のシンボルを選択すると、そのコミュニケーショングループの下位の階層にあたるコミュニケーショングループが展開される。また、「・」のシンボルは、そのコミュニケーショングループには下位のコミュニケーショングループが存在しないことを意味している。また、各コミュニケーショングループの階層は、その表示位置のインデントにより示されている。このような階層構造を含むリストの表示は、一般的にコンピュータにおける情報処理の分野で常用されるものであって構わない。図８に示した例では、グループ９はグループ８が折り畳まれた状態であるため表示されていない。

【0084】

また、図８に示した状態では、コミュニケーショングループのリスト中、グループ２がユーザにより選択されており、そのことを同図では破線で囲むことにより示している。特定のコミュニケーショングループが選択されていることは、クライアント端末３のモニタ１ｈ上では、当該コミュニケーショングループの表示をハイライトとしたり、太字や色彩の変更などにより強調表示したりするなど、任意の方法により示してよい。また、ユーザの権限によって、選択できるコミュニケーショングループに制限が加えられてもよい。例えば、ユーザの権限を持つユーザは、自分がメンバーとして登録されているコミュニケーショングループしか選択することができず、他のコミュニケーショングループに属するコミュニケーションを一覧することができない。

【0085】

ＧＵＩ下部右側の欄には、ユーザにより選択されたコミュニケーショングループに属するコミュニケーションの一覧が、コミュニケーション一覧表示部１０４により表示される。なお、ここでは、各コミュニケーションを時系列順に表示するものとして示しているが、コミュニケーションの並べ方は任意に選択できるものとしてよく、その基準はコミュニケーションがなされた日時のほか、ユーザやコミュニケーションの種別等を選択できるようにしてよく、また昇降順も選択できるようにしてよい。

【0086】

図８では、コミュニケーショングループとして選択されているグループ２に属するコミュニケーションである、図５に示したコミュニケーションＩＤが「ＣＭ００００２」～「ＣＭ００００６」の５つのコミュニケーションが一覧表示されている。これらのコミュニケーションがグループ２に属することは、その上位のコミュニケーショングループＩＤとして、グループ２のものである「ＰＲ００００２」がコミュニケーションデータベース１０２に登録されていることから判別される。

【0087】

各コミュニケーションの表示欄上部のタイトル欄には、コミュニケーションの種別を示すシンボルと、どのユーザによりコミュニケーションがなされたか、すなわち、コミュニケーションの発信元と受信先と、コミュニケーションの日時が示されている。ここでコミュニケーションの種別を示すシンボルは、丸吹き出しがチャット、手紙が電子メール、受話器が電話通話によるものであることを示している。なお、シンボルの選択は任意であり、外部コミュニケーションクライアント自体のアイコンをシンボルとして用いることも可能である。

【0088】

各コミュニケーションの表示欄下部には、各コミュニケーションの内容が示される。コミュニケーションの内容が長い場合には、右端にスクロールバーを表示するなどしてスクロール表示できるようにしてもよい（図８の例では、一番下のコミュニケーションと、ＧＵＩ下部右側の欄にスクロールバーが示されている）。

【0089】

ここで、図８に示した一番下のコミュニケーションの表示欄下部には、電話通話の内容がテキスト化された情報が表示されている。これは、本実施形態に係るコミュニケーション管理システム１００が通話による音声記録をテキスト化する機能を備えているためであり、これにより、ユーザは音声記録の内容を視覚的に把握でき、また、その内容をテキストによる検索対象とすることができる。また、音声による通話記録自体は、コミュニケーションの表示欄上部のタイトル欄に示されたスピーカーのシンボルを選択することで、音声として再生し確認できるようになっている。これは、コミュニケーション管理システム１００が、クライアント端末３にインストールされている適宜の音声再生アプリケーションやデコーダを起動することにより容易に実現できる。

【0090】

なお、コミュニケーション管理システム１００が電話通話の内容をテキスト化することは必須のものではなく、機能として省略してもよい。その場合には、ＧＵＩには単に通話記録が示されるか、または音声の再生のみがなされるように表示されてよい。あるいは、電話通話の内容として、テキスト化された情報のみが表示され、通話記録の再生の機能を省略することもできる。

【0091】

なお、図４～図６では、便宜上、コミュニケーショングループデータベース１０１に記憶された各コミュニケーショングループ、コミュニケーションデータベース１０２に記憶された各コミュニケーション及び、ユーザデータベースに記憶された各ユーザの情報を、それぞれレコードとして記憶するカード型データベースに準じる形式で例示したが、それぞれのデータベースの構造はこれに限定される必要はなく、個々の情報のエントリは例えば、ＸＭＳなどを利用したマークアップ形式で記述されてもよく、また、必要な情報がより柔軟な形で埋め込まれる形、例えば、上位のコミュニケーショングループを示す情報が説明のテキスト文書中にコミュニケーショングループＩＤが記述されることにより示されたり、上位のコミュニケーショングループへの参照が記述されることにより示されたりしてもよい。

【0092】

以上説明したように、コミュニケーション管理システム１００では、特定のコミュニケーショングループに属するコミュニケーションを、その種別によらず一覧表示して確認することができるため、コミュニケーション管理システム１００を利用するユーザが、特定のコミュニケーショングループにおいてなされたコミュニケーションを容易に把握し、コミュニケーションに関する情報のユーザ間の共有を図ることが可能となる。

【0093】

そのためには、コミュニケーション管理システム１００により把握されるコミュニケーションが、どのコミュニケーショングループに属するのかを特定し、これらを紐づけることが必要である。以下、この点を含むコミュニケーション管理システム１００の技術的な構成を説明する。

【0094】

図３に戻り、コミュニケーショングループ作成部１０５は、コミュニケーション管理システム１００のユーザが明示的にコミュニケーショングループを作成するための機能を実現する部分である。コミュニケーショングループ作成部１０５は、コミュニケーション管理システム１００にアクセスしたユーザから、新規にコミュニケーショングループを作成する旨の指示と、必要な情報、例えば、コミュニケーショングループの種別、説明、期間、上位のコミュニケーショングループの指定やコミュニケーショングループに属するメンバーなどを受け付け、コミュニケーショングループデータベース１０１に登録することにより、コミュニケーショングループを作成する。

【0095】

コミュニケーショングループ作成部１０５は、コミュニケーショングループを作成しようとするユーザの権限に応じて、作成できるコミュニケーショングループを制限してよい。例えば、アドミニストレータ及びエディタは全ての種別のコミュニケーショングループを作成できるが、ユーザはプロジェクトを作成できず、タスクと問い合わせのみ作成可能とするなどである。また、コミュニケーショングループ作成部１０５は、原則として、コミュニケーショングループをその作成時においてはアクティブとする。コミュニケーショングループの情報の編集、メンバーの追加、ステータスのアクティブからノンアクティブへの変更などの際にも、ユーザの権限に応じた制限を行ってよい。この制限をどのように定めるかは任意であるが、一例として、コミュニケーショングループ作成時と同様の制限としてよい。

【0096】

図９は、コミュニケーショングループ作成部１０５の動作を示すフロー図である。ユーザがコミュニケーション管理システム１００に対し、コミュニケーショングループを作成する旨の指示をすると、ステップＳ１１にて、コミュニケーショングループ作成部１０５はコミュニケーショングループの作成にあたって必要な情報の入力を受け付ける。続くステップＳ１２にて、作成指示のあったコミュニケーショングループがプロジェクトであるか、タスクまたは問い合わせであるかを判別する。

【0097】

作成指示のあったコミュニケーショングループがプロジェクトである場合、ステップＳ１３へと進み、作成指示をしたユーザの権限がアドミニストレータ又はエディタの何れかであるか否かを判別する。アドミニストレータ又はエディタの権限をユーザが有していない場合、ステップＳ１４へと進み、コミュニケーショングループの作成ができない旨のエラーメッセージを表示し、ステップＳ１１へと戻る。

【0098】

それ以外の場合、すなわち、ステップＳ１２で作成指示のあったコミュニケーショングループがタスクまたは問い合わせである場合と、ステップＳ１３でユーザが必要な権限を有している場合には、ステップＳ１５へと進み、新規にコミュニケーショングループＩＤを発行する。このコミュニケーショングループＩＤは、作成指示のあったコミュニケーショングループに一意のものであって、他の既に登録されているコミュニケーショングループに付与されているコミュニケーションＩＤとは重複しない。その後ステップＳ１６にて、必要な情報に発行されたコミュニケーションＩＤを付与してコミュニケーショングループデータベース１０１に登録し、コミュニケーショングループの作成を終える。

【0099】

なお、上の例では、ユーザの権限に応じてコミュニケーショングループの作成の可否を判断するフローとなっていたが、ユーザに提示するユーザインタフェースの段階で、権限に応じて実行可能な選択肢のみを提示するようにしてもよい。

【0100】

再び図３に戻り、ユーザ編集部１０６は、ユーザ情報の追加や編集を行うための機能を実現する部分である。ユーザ編集部１０６は、コミュニケーション管理システム１００にアクセスしたユーザからの入力に応じて、ユーザの新規登録や登録内容の変更、削除等を行うが、これらについても、ユーザの権限に応じた制限を加えてよい。

【0101】

具体的に本実施形態の例では、アドミニストレータ又はエディタの権限を持つユーザを新規に作成し、削除し、あるいは既存のユーザの権限をアドミニストレータ又はエディタに変更したり、あるいはアドミニストレータ又はエディタから変更したりすることはアドミニストレータの権限を持つユーザのみに許可される。エディタの権限を持つユーザは、ユーザ又はゲストの権限を持つユーザの追加・削除及び変更が許可され、ユーザの権限を持つユーザはゲストの権限を持つユーザの追加・削除及び変更のみが許可される。

【0102】

これは、本実施形態で想定している例においては、エディタの権限を持つユーザはコミュニケーショングループを管理する立場であることが想定されるから、コミュニケーショングループに参加するメンバーとなるユーザ及びゲストの権限を持つユーザに対する管理権限が必要であるからであり、ユーザの権限を持つユーザは、問い合わせを受けた際に、その相手をゲストの権限を持つユーザとしてコミュニケーション管理システム１００に追加・管理する必要があるからである。

【0103】

図１０は、ユーザ編集部１０６の動作を示すフロー図である。ユーザがコミュニケーション管理システム１００に対し、ユーザの新規登録・削除または登録内容の変更をする旨の指示をすると、ステップＳ２１にて、ユーザ編集部１０６は必要な情報の入力を受け付ける。続くステップＳ２２にて、登録・削除または登録内容の変更の対象となるユーザの権限がアドミニストレータ又はエディタであるか、ユーザであるか、あるいはゲストであるかを判別する。

【0104】

対象となるユーザの権限がアドミニストレータ又はエディタであれば、ステップＳ２３へと進み、作成指示をしたユーザの権限がアドミニストレータであるか否かを判別する。アドミニストレータの権限をユーザが有していない場合、ステップＳ２４へと進み、ユーザの登録・削除または登録内容の変更ができない旨のエラーメッセージを表示し、ステップＳ２１へと戻る。

【0105】

また、ステップＳ２２において、対象となるユーザの権限がユーザである場合、ステップＳ２５へと進み、作成指示をしたユーザの権限がアドミニストレータ又はエディタであるか否かを判別する。アドミニストレータ又はエディタの権限をユーザが有していない場合には、やはりステップＳ２４へと進み、ユーザの登録・削除または登録内容の変更ができない旨のエラーメッセージを表示し、ステップＳ２１へと戻る。

【0106】

ステップＳ２２において、対象となるユーザの権限がゲストである場合、ステップＳ２３においてユーザがアドミニストレータの権限を有している場合、及び、ステップＳ２５においてユーザがアドミニストレータ又はエディタの権限を有している場合には、ステップＳ２６へと進み、受け付けた情報にて、ユーザテータベース１０３に対し、ユーザの新規登録・削除または登録内容の変更を行い、ユーザの登録・削除または登録内容の変更を終える。

【0107】

なお、上の例においても、ユーザの権限に応じてユーザの新規登録・削除または登録内容の変更の可否を判断するフローとなっていたが、ユーザに提示するユーザインタフェースの段階で、権限に応じて実行可能な選択肢のみを提示するようにしてもよい。

【0108】

続いて、図３のコミュニケーション取得部１０７の機能を説明する。コミュニケーション取得部１０７は、ユーザがクライアント端末３の外部コミュニケーションクライアントを用いて行ったコミュニケーションを捕捉し、これを取得する機能を実現する部分である。すなわち、クライアント端末３を利用するユーザがコミュニケーションのやり取りをするに際し、どのコミュニケーション手段をとるかに制限はないから、コミュニケーション管理システム１００によりそれらコミュニケーションを把握し管理するためには、コミュニケーション管理システム１００を通じることなく、外部コミュニケーションクライアントによりなされたコミュニケーションを、コミュニケーション管理システム１００が取得できなくてはならない。

【0109】

そのため、コミュニケーション取得部１０７は、外部コミュニケーションクライアントからの通知、及び、外部コミュニケーションクライアントへの通知要求に基づいて、外部コミュニケーションクライアントによりなされたコミュニケーションを取得するようになっている。前者のタイプ、すなわち、外部コミュニケーションクライアントからの通知に基づくコミュニケーションの取得は、一般的にプッシュ型、後者のタイプ、すなわち、外部コミュニケーションクライアントへの通知要求に基づくコミュニケーションの取得は、一般的にプル型と呼ばれるアプリケーション間通信の方式に該当する。

【0110】

このプッシュ型、プル型のアプリケーション間通信は、外部コミュニケーションクライアントが備えるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍａｂｌｅ Ｉｎｔｅｒｆａｃｅ）を利用して行うものであってよい。プッシュ型、プル型のいずれを用いるかは、外部コミュニケーションクライアントがどのようなＡＰＩを実装しているかに依存する。プッシュ型ＡＰＩを備えた外部コミュニケーションクライアントの場合には、当該外部コミュニケーションクライアントにコミュニケーション管理システム１００のユーザアカウントを登録しておくことにより、外部コミュニケーションクライアントは、コミュニケーションが発生する都度、そのコミュニケーションをコミュニケーション管理システム１００に通知し、コミュニケーション取得部１０７が当該コミュニケーションを取得する。

【0111】

プル型ＡＰＩを備えた外部コミュニケーションクライアントの場合には、コミュニケーション管理システム１００に当該外部コミュニケーションクライアントのユーザアカウントを登録しておき、コミュニケーション取得部１０７から所定のタイミング、例えば５分毎や１時間毎などに外部コミュニケーションクライアントに対して通知要求を送信する。この通知要求は、外部コミュニケーションクライアントのＡＰＩの仕様にもよるが、新規のコミュニケーションがあればそれを通知するよう要求するものであり、これにより、コミュニケーション管理システム１００のコミュニケーション取得部１０７は外部コミュニケーションクライアントからコミュニケーションを取得する。

【0112】

図１１は、コミュニケーション取得部１０７の動作を示すフロー図である。まず、外部コミュニケーションクライアントがプッシュ型通知のＡＰＩを有しており、かかる通知がなされた場合、ステップＳ３１において、通知がなされたことを検出する。通知があればステップＳ３５へと進み、通知に係るコミュニケーションを取得する。

【0113】

外部コミュニケーションクライアントからの通知を検出したのでない場合には、ステップＳ３２へと進み、プル型通知のＡＰＩを有する外部コミュニケーションクライアントに対する処理を行う。ステップＳ３２では、外部コミュニケーションクライアントに対する通知要求するタイミングが到来しているか否かを判定する。このタイミングはあらかじめ定めておいたタイミングとしてもよいし、ユーザが任意に設定できるようにしておいてもよい。タイミングが到来していなければ処理を終了する一方、タイミングが到来していればステップＳ３３へと進み、外部コミュニケーションクライアントに対して通知要求を送信する。

【0114】

さらに、ステップＳ３４で、通知要求に対する外部コミュニケーションクライアントの応答に基づいて、未収得の新規コミュニケーションが当該外部コミュニケーションクライアントにおいてなされているか否かを判定する。新規コミュニケーションがなければ、取得すべきコミュニケーションは存在しないことになるから、処理を終了する。新規コミュニケーションがあれば、ステップＳ３５へと進み、当該新規コミュニケーションを取得する。

【0115】

コミュニケーション取得部１０７は、新規コミュニケーションを取得した時点でこれをコミュニケーション紐づけ部１０８へと引き渡し処理を終えてもよいが、本実施形態では、さらに、ステップＳ３６へと進み、取得したコミュニケーションのコンテンツが電話の通話記録などの音声データであるか否かを判定する。コミュニケーションのコンテンツが音声データである場合には、ステップＳ３７へと進み、音声データをテキストデータに変換する。この理由は、ユーザによる画面上でコンテンツ内容の確認を可能とし、テキスト検索可能とするほか、後述するコミュニケーションとコミュニケーショングループとの紐づけにも用いられるためである。テキストデータへの変換の有無にかかわらず、コミュニケーション取得部１０７は処理を終了し、取得したコミュニケーションをコミュニケーション紐づけ部１０８へと引き渡す。

【0116】

コミュニケーション取得部１０７により取得されたコミュニケーションは、コミュニケーション紐づけ部１０８において、コミュニケーショングループとの紐づけがなされる。とはいえ、外部コミュニケーションクライアントは、コミュニケーション管理システム１００により管理されるコミュニケーショングループをそもそも把握していないため、コミュニケーション取得部１０７により取得されたコミュニケーションがどのコミュニケーショングループに関してなされたものかは直ちに明らかではない。そのため、コミュニケーション紐づけ部１０８においては、まず取得されたコミュニケーションがどのコミュニケーショングループに属するかを特定することになる。

【0117】

この特定は、取得されたコミュニケーションに含まれる特定の情報、これを以降グループ特定情報と称する、に基づいてなされる。逆説的ではあるが、コミュニケーションに含まれる情報であって、そのコミュニケーションが属するコミュニケーショングループの特定に用いられる情報がグループ特定情報である。本実施形態に係るコミュニケーション管理システム１００では、グループ特定情報として、コミュニケーションに含まれるメタデータ、コミュニケーションのユーザ、及び、コミュニケーションのコンテンツ内容の３種を用いる。

【0118】

メタデータを用いるコミュニケーショングループの特定は、メタデータ中にコミュニケーショングループを特定できる情報を書き込んでおくことにより容易に可能である。例えば、コミュニケーション手段が電子メールである場合、メールヘッダは通常、ＲＦＣ５３２２に従って記述されるため、適宜のフィールドにコミュニケーショングループＩＤを記載しておくことにより、明確にコミュニケーショングループを特定できる。例えば、「Ｋｅｙｗｏｒｄｓ：ＰＲ００００２」のようにＫｅｙｗｏｒｄｓフィールドを用いたり、ＲＦＣ５３２２に定義はないが、「ＣｏｍｍｕｎｉｃａｔｉｏｎｇｒｏｕｐＩＤ：ＰＲ００００２」のように新規にフィールドを定義したりしてもよい。

【0119】

なお、一般にメタデータはテキストデータにより記述されることが一般的である。そのため、コミュニケーショングループＩＤを、バイナリデータでなく、テキストデータにより記述しておくことで、メタデータへの埋め込みが容易となる。

【0120】

一旦メタデータ中にコミュニケーショングループを特定できる情報が書き込まれた電子メールの送受信がなされると、その電子メールに対する返信や転送による電子メールには、Ｒｅｆｅｒｅｎｃｅｓフィールドに元となる電子メールの識別フィールドの情報が保存されているため、コミュニケーショングループの特定は直ちに可能である。また、電子メールによるやり取りの過程でコミュニケーショングループを特定できる情報が直接的な形では失われたとしても、Ｍｅｓｓａｇｅ－ＩＤを追跡することにより元となる電子メールの特定は可能であるから、やはりコミュニケーショングループの特定ができる。

【0121】

コミュニケーション手段がチャットやインスタントメッセージの場合においても同様であり、コミュニケーショングループを特定できる情報の書き込みが可能なメタデータ領域が利用できる場合には、当該領域にメタデータとしてかかる情報、例えば、コミュニケーショングループＩＤを書き込んでおくことで、一連のやり取りを特定のコミュニケーショングループに属するものとして特定することができる。具体的にコミュニケーショングループを特定できる情報をどのようにメタデータ中に書き込むかは、利用しようとするコミュニケーション手段の仕様に合わせて設計すればよい。

【0122】

以上のようにメタデータを用いるコミュニケーショングループの特定方法においては、最初にメタデータにコミュニケーショングループを特定する情報、例えば、コミュニケーショングループＩＤを書き込んだコミュニケーションがなされなければならない。そのため、コミュニケーション管理システム１００では、システムコミュニケーションクライアント１０９が用意されている。

【0123】

システムコミュニケーションクライアント１０９は、外部コミュニケーションクライアントをコミュニケーション管理システム１００から利用するためのミドルウェア及びユーザインタフェースである。すなわち、ＡＰＩを利用して外部コミュニケーションクライアントの機能を利用することで、外部コミュニケーションクライアントを別途起動することなく、コミュニケーション管理システム１００に対する操作により外部コミュニケーションクライアントを利用する機能を実現する部分である。

【0124】

ユーザは、コミュニケーション管理システム１００にアクセスすると、コミュニケーション管理システム１００のＧＵＩから電子メール、チャット、インスタントメッセージといったコミュニケーションを作成し送受信し、あるいはヘッドセット４を利用して電話による通話が可能とされている。この動作は実際には、システムコミュニケーションクライアント１０９がユーザから受け取ったコミュニケーションの実行指示を、ＡＰＩを介して外部コミュニケーションクライアントに実行させることにより実現される。

【0125】

この際、ユーザが特定のコミュニケーショングループを指定した状態で（例えば、図８の破線枠で示すように、あるコミュニケーショングループ（同図では、グループ２）が選択されている状態で）、システムコミュニケーションクライアント１０９によるコミュニケーションの実行指示を行うと、システムコミュニケーションクライアント１０９は、当該指定されたコミュニケーショングループのコミュニケーショングループＩＤをメタデータとして付与するよう各外部コミュニケーションクライアントにＡＰＩを用いて指令する。

【0126】

このようにすることで、コミュニケーション管理システム１００のシステムコミュニケーションクライアント１０９を利用してなされたコミュニケーションがいったんなされると、当該コミュニケーションに対してなされる一連のコミュニケーションは、必ずしもシステムコミュニケーションクライアント１０９を通さずに行われたとしても、そのメタデータを参照することにより、コミュニケーション紐づけ部により容易にコミュニケーショングループが特定され、紐づけられる。

【0127】

しかしながら、システムコミュニケーションクライアント１０９を通さずになされたコミュニケーションや、これまでのコミュニケーションに対する返答や転送でない外部機器から受信したコミュニケーション、メタデータに対応していないコミュニケーション手段によりなされたコミュニケーションは、メタデータによりその属するコミュニケーショングループを明確に特定することができない。

【0128】

そこで、さらに、グループ特定情報として、コミュニケーションのユーザ情報を用いる。コミュニケーションには、その送信元と受信先の情報が含まれるため、コミュニケーション紐づけ部１０８は、そのコミュニケーションに関るユーザを容易に特定することができる。すなわち、コミュニケーションが電子メールであれば、ＦｒｏｍフィールドとＴｏフィールドに記載された電子メールアドレスを参照し、また、コミュニケーションがチャットやインスタントメッセージであれば、その送信元と受信先の宛先となるＩＤを参照し、さらに、コミュニケーションが電話通話であれば、発信元と着信先の電話番号を参照して、ユーザデータベース１０３に記憶されたユーザの情報と照合すれば直ちにユーザが特定できるからである。

【0129】

そして、コミュニケーション紐づけ部１０８は、コミュニケーショングループデータベース１０２を参照し、登録されたコミュニケーショングループのメンバーとして、特定されたユーザが含まれるものを探索し抽出する。コミュニケーションが特定のコミュニケーショングループに属するメンバー間でなされているならば、そのコミュニケーションは当該コミュニケーショングループに関してなされたものであると推定できるからである。

【0130】

さらに、このユーザを用いたコミュニケーショングループの探索の際に、コミュニケーション紐づけ部１０８は、アクティブなコミュニケーショングループのみを探索の対象とし、ノンアクティブなコミュニケーショングループは探索対象としない。これは、その目的がすでに達せられ、終了したコミュニケーショングループに関して新たなコミュニケーションはなされないと考えられるとともに、すでに終了しノンアクティブとなったコミュニケーショングループのメンバーは、現在アクティブである新しいコミュニケーショングループのメンバーである可能性が高いと考えられるから、すでに終了した過去のコミュニケーショングループをも探索の対象とすると、無意味に多数のコミュニケーショングループが抽出されてしまい、コミュニケーショングループを特定することができなくなるからである。

【0131】

しかしながら、アクティブなコミュニケーショングループのみを探索することとしたとしても、あるユーザが、複数のコミュニケーショングループ、例えば、同時に複数のプロジェクトに参加しており、また同時に複数のタスクを担当しているということは大いにあり得ることであり、その場合には、ユーザによるコミュニケーショングループの探索及び抽出によっては、複数のコミュニケーショングループの候補が抽出され、一意に定まらないといいうことが起こり得る。

【0132】

そこで、そうした場合には、コミュニケーション紐づけ部１０８は、コミュニケーションのコンテンツ内容をグループ特定情報として用い、コミュニケーションが属するコミュニケーショングループを特定する。すなわち、コミュニケーションのコンテンツ内容それ自体によって、どのコミュニケーショングループに属するかの尤度を見積もり、尤も尤度の高いコミュニケーショングループをその所属先として推定する手法である。

【0133】

この手法としては、一般に自然言語解析・文章解析として開発されている種々の手法を用いてよい。以下、かかる手法の具体的な例をいくらか示す。

【0134】

（１）Ｄｏｃ２Ｖｅｃｔｏｒを用いる手法
Ｄｏｃ２Ｖｅｃｔｏｒの解析技術を用い、コミュニケーションのコンテンツ内容それ自体をベクトルに変換し、ベクトル間のノルムによってコミュニケーショングループとの遠近を判断する。コミュニケーショングループに対しても、その説明及び、これまで当該コミュニケーショングループに関してなされたコミュニケーションのコンテンツ内容をＤｏｃ２Ｖｅｃｔｏｒによりベクトルに変換して記憶しておくとよい。コミュニケーションのベクトルにより近い（ノルムが小さい）ベクトルを持つコミュニケーショングループを、そのコミュニケーションの所属先と推定する。この手法では、全体的な文脈の近いコミュケーションを共通のコミュニケーショングループに属するものと判別しやすく、一般的に利用しやすい利点がある。

【0135】

（２）Ｗｏｒｄ２Ｖｅｃｔｏｒを用いる手法
Ｗｏｒｄ２Ｖｅｃｔｏｒの解析技術を用いて、コミュニケーションのコンテンツ内容それ自体をベクトルに変換する。この場合、いわゆる形態素解析などによりコンテンツ内容を形態素に分解し、個々の形態素をＷｏｒｄ２Ｖｅｃｔｏｒによりベクトル化する。得られたベクトルは、形態素の出現頻度から、ｔｆ／ｉｄｆなどの指標により重み付けをして合成重心を得る。コミュニケーショングループに対しても同様の手法により合成重心を得ておき、それら合成重心間のノルムによってコミュニケーショングループとの遠近を判断する点は先の例と同じである。この手法では、特徴的な単語が共通するコミュニケーションを共通のコミュニケーショングループに属するものと判別しやすい利点があり、技術的な内容にかかわるコミュニケーションにおいて精度が高い利点がある。

【0136】

（３）ＲＮＮ（再帰的ニューラルネットワーク）を用いる手法
ＲＮＮを用いて、コミュニケーションのコンテンツ内容及びコミュニケーショングループ（の説明及びこれまでになされたコミュニケーション）をベクトルに変換する手法である。この場合においても、コンテンツ内容は形態素に分解したうえでＷｏｒｄ２Ｖｅｃｔｏｒによりベクトル化され、ＲＮＮに入力され、特徴量ベクトルを出力する。ＲＮＮは、あらかじめ、適宜のコーパスを用いた事前学習がなされるほか、新たにコミュニケーション管理システム１００に登録されるコミュニケーションに基づく追加学習をしていくことで、その精度を向上させていくことが可能である。この手法では、コミュニケーションの性質によらず適用できるほか、使用につれて推定精度を向上させられる利点がある一方、事前学習のコーパスの用意にコストを要することや、コーパスの選択如何によって推定精度に大きな影響がある点などが欠点である。

【0137】

コミュニケーション紐づけ部１０８は、上のいずれの手法を用い、あるいは組み合わせ、さらにはその他の手法、例えばＳＶＭ（サポートベクトルマシン）を用いたクラスタリングなどの手法を用い、コミュニケーションが属するコミュニケーショングループを特定し、図５に示すように、そのコミュニケーショングループＩＤを付与してコミュニケーションデータベース１０２へと登録する。

【0138】

ところで、コミュニケーション紐づけ部１０８による、コンテンツ内容をグループ特定情報とするコミュニケーショングループの特定のためには、そのコンテンツ内容は自然言語解析が可能な形となっていなければならない。電子メール、チャット、インスタントメッセージといったテキストベースのデジタルコミュニケーション手段においては、解析に何らの問題もないが、コミュニケーション手段が電話であり、コンテンツ内容が通話記録の場合には、これは直ちに解析可能ではない。

【0139】

そこで、コミュニケーション管理システム１００のコミュニケーション取得部１０７は、コミュニケーションが電話などの音声によるコミュニケーションであり、そのコンテンツ内容が通話記録などの音声データである場合には、この音声データを音声認識によりテキストデータに変換する。この音声認識は、一般的に利用される手法、例えば、ＬＳＴＭ（長期短期記憶）を用いた音声認識により行ってよい。また、同時に、この音声データに各国言語が含まれる場合には、特定の言語へと翻訳したテキストデータを生成してもよい。

【0140】

以上のように、コミュニケーション紐づけ部１０８は、種々のグループ特定情報に基づいてコミュニケーションが属するコミュニケーショングループを特定するが、コミュニケーショングループの特定ができない場合が存在する。上説明した例においては、コミュニケーションの当事者であるユーザが、登録済みのコミュニケーショングループのメンバーと一致しない場合や、コミュニケーションのコンテンツ内容に基づく所属先のコミュニケーショングループの推定において、近しいと推定されるコミュニケーショングループが存在しない場合などが考えられる。

【0141】

こういった場合は、既存でない（未登録の）コミュニケーショングループに関するコミュニケーションがなされた可能性が高いと考えられる。具体例でいうと、商品やサービスの顧客から新規の問い合わせを電話にて受けた場合、事前にその問い合わせがコミュニケーショングループとしてあらかじめ登録されていることはあり得ないから、このコミュニケーションが属するコミュニケーショングループとして登録されたものは存在しないはずである。

【0142】

このように、その属するコミュニケーショングループの特定がなされなかったコミュニケーションが見いだされた場合には、コミュニケーション紐づけ部１０８は自動コミュニケーショングループ作成部１１０を呼び出す。自動コミュニケーショングループ作成部１１０は、その属するコミュニケーショングループの特定がなされなかったコミュニケーションが属するコミュニケーショングループを自動で新たに作成し、コミュニケーショングループデータベース１０１に登録する。コミュニケーション紐づけ部１０８は、新たなコミュニケーショングループの作成があった後、改めて、当該コミュニケーションを当該新たなコミュニケーショングループに紐づけ、コミュニケーションデータベース１０２に登録する。

【0143】

ここで、本実施形態では、自動コミュニケーション作成部１１０により新規に作成されるコミュニケーショングループは、その種別を問い合わせとし、そのメンバーとして、コミュニケーショングループが新規に作成される契機となったコミュニケーションの当事者を登録する。

【0144】

その他、コミュニケーショングループの登録に際してどのような内容を登録するかは任意である。例えば、説明は自動登録である旨を記載した文章データとしてもよい。また、メンバーとして、コミュニケーションの当事者以外のユーザを加えるようにするなどしてもよい（例えば、ユーザデータベース１０３に登録された所属その他のユーザの管理情報に基づいて、そのユーザの上司など管理者にあたる別のユーザを追加したり、特定のユーザを管理者として追加したりするなど）。

【0145】

以上の通り、本実施形態に係るコミュニケーション管理システム１００では、コミュニケーショングルーブの種類としてプロジェクト、タスクおよび問い合わせの３種を取り扱っているが、これらは、その作成がユーザの明示的な指示に限られるか、またユーザの権限による制限はあるか、さらには、期間など必須の情報はあるかといった差異により区別されるものであり、コミュニケーション管理システム１００の利用シーンに応じたものを用いてよい。ここでは、プロジェクトはアドミニストレータ又はエディタの権限を持つユーザにより作成され管理される、他のコミュニケーショングループを取りまとめる入れ物であり、タスクは個々のユーザにより管理される個別のプロセスに対応するコミュニケーショングループであり、問い合わせは外部からの要請などにより突発的に発生する、事前の計画外で発生するコミュニケーションを管理するためのコミュニケーショングループとして設計されている。このように、コミュニケーショングループの種類ごとにその性質を異なるものとすることで、多様なコミュニケーションに応じた管理が可能である。

【0146】

図１２は、コミュニケーション紐づけ部１０８の動作を示すフロー図である。コミュニケーション紐づけ部１０８は、まず、ステップＳ４１にて、取得したコミュニケーションのメタデータを取得する。そして、ステップＳ４２にて、メタデータから、そのコミュニケーションが属するコミュニケーショングループを特定可能か、すなわち、メタデータにコミュニケーショングループを特定する情報が含まれており、それにより特定可能かを判定する。

【0147】

特定可能ならば、ステップＳ５０へと進み、特定されたコミュニケーショングループに取得したコミュニケーションを紐づけ、コミュニケーションデータベース１０２にコミュニケーションを記録し、処理を終了する。これに対し、メタデータのみからではコミュニケーショングループを明確に特定できない場合は、ステップＳ４３へと進む。

【0148】

ステップＳ４３では、コミュニケーションから、ユーザ情報、すなわち、送信元と受信先のユーザを特定する情報を取得する。なお、一般的には、ユーザ情報もメタデータの一部として取り扱われることが多いが、上ですでに説明したように、ユーザ情報はその情報単独でコミュニケーショングループを特定することができず、登録済みのコミュニケーショングループのメンバーとの照合が必要であるから、ここでは、メタデータからそのコミュニケーションが属するコミュニケーショングループを特定可能なものとしては取り扱わない。

【0149】

ステップＳ４４では、取得したユーザ情報と登録済みのコミュニケーショングループのメンバーとの照合を行い、ユーザが一致する、すなわち、取得したコミュニケーションに係るユーザがメンバーに含まれるコミュニケーショングループ、すなわち、紐づけの候補となるコミュニケーショングループの有無を判定する。コミュニケーショングループの候補がある場合、さらにステップＳ４５へと進み、その候補の数を判定する。

【0150】

コミュニケーショングループの候補の数が１であれば、そのコミュニケーショングループが、当該コミュニケーションが属するコミュニケーショングループと特定できるから、ステップＳ５０へと進み、特定されたコミュニケーショングループに取得したコミュニケーションを紐づけ、コミュニケーションデータベース１０２にコミュニケーションを記録し、処理を終了する。一方、コミュニケーショングループの候補の数が複数であれば、ステップＳ４６へと進み、コンテンツ内容から、登録済みのコミュニケーショングループとの一致の度合いである尤度を導出する。この尤度の導出は、上ですでに述べたＤｏｃ２Ｖｅｃｔｏｒを使用する方法、Ｗｏｒｄ２Ｖｅｃｔｏｒを使用する方法及びＲＮＮを使用する方法の他、実用的にコミュニケーションが特定のコミュニケーショングループに属していることを推定することができる方法であれば任意のものを用いてよい。

【0151】

続くステップＳ４７では、当該コミュニケーションが、登録済みのいかなるコミュニケーショングルーブとも近接していないか否かを判定する。すなわち、当該コミュニケーションがどのコミュニケーショングループともその内容（説明及び、そのコミュニケーショングループに関してなされた過去のコミュニケーション）が似ていない場合には、無理に特定のコミュニケーションに紐づけることはせず、ステップＳ４８へと進む。一方、当該コミュニケーションと近接するコミュニケーショングループが存在する場合には、ステップＳ４９へと進む。

【0152】

ステップＳ４９では、当該コミュニケーションが最も近いと考えられるコミュニケーショングループを、その属するコミュニケーショングループであると決定する。以降は、ステップＳ５０へと進み、特定されたコミュニケーショングループに取得したコミュニケーションを紐づけ、コミュニケーションデータベース１０２にコミュニケーションを登録し、処理を終了する。

【0153】

そして、ステップＳ４４にてユーザの一致する登録済みのコミュニケーショングループがないと判定された場合、及び、ステップＳ４７にて、内容の近しい登録済みのコミュニケーショングループが存在しないと判定された場合にはステップＳ４８へと進み、コミュニケーション紐づけ部１０８は、自動コミュニケーショングループ作成部１１０に新規にコミュニケーショングループを作成させ、コミュニケーショングループデータベース１０１に登録させる。そして、その新規登録されたコミュニケーショングループが、当該コミュニケーションの属するコミュニケーショングループであるから、その後ステップＳ５０へと進み、新規作成されたコミュニケーショングループに取得したコミュニケーションを紐づけ、コミュニケーションデータベース１０２にコミュニケーションを登録し、処理を終了する。

【0154】

以上説明したコミュニケーション紐づけ部１０８の動作のフローにおいては、グループ特定情報として、メタデータ、ユーザ情報及びコンテンツ内容の３種を用い、これらのグループ特定情報の種類ごとにその優先順位を定めているフローとなっている。すなわち、メタデータが他の２種よりまず優先されており、続いて、ユーザ情報が優先され、メタデータとユーザ情報に基づいても、そのコミュニケーションが属するコミュニケーショングループが特定できない場合に、そのコンテンツ内容を利用するようになっている。

【0155】

これは、グループ特定情報の種類間において、特定の種類のグループ特定情報を用いたコミュニケーショングループの推定の確度に大きな差がある場合には有効であり、また、一部のグループ特定情報の取り扱いに大きな情報処理上の負荷が発生する場合には、コミュニケーション管理システム１００の情報処理の負荷を低減する上で有効である。上で説明した実施例に即して言えば、コンテンツ内容に基づくコミュニケーショングループの特定は、計算負荷の大きな自然言語処理を伴う情報処理であるから、その他の種類のグループ特定情報により十分な精度でコミュニケーショングループの特定ができるのであれば、かかる情報処理の実行を避けるフローとした方が、情報処理上の負荷を全体的に低減できる。

【0156】

一方、コミュニケーショングループの種類やコミュニケーションの性質によっては、グループ特定情報間の、コミュニケーショングループ特定の精度についての差異が必ずしも大きくない場合も想定される。そのような場合には、グループ特定情報の種類ごとに、その推定のスコアを算出し、かかるスコアに基づいてコミュニケーショングループを特定するようにしてもよい。

【0157】

例えば、上の例に即して言えば、メタデータの一致度に０～１００のスコア、ユーザの一致度に０～５０のスコア、コンテンツ内容の一致度に０～５０のスコアといったように、グループ特定情報の種類ごとに重みを変え又は一致させたスコアを付し、当該スコアの合計値が最も高いコミュニケーショングループを、そのコミュニケーションが属するコミュニケーショングループであると特定してよい。

【0158】

以上の通り、本実施形態に係るコミュニケーション管理システム１００では、ビジネスシーンにおけるコミュニケーション、すなわち、ある特定の目的に関してなされるコミュニケーションを、そのコミュニケーションがなされる手段によらず、コミュニケーショングループという単位にまとめて管理し、一覧表示できるようにすることで、その特定の目的に即した単位毎にコミュニケーションが可視化され、容易に把握できるようになる。

【0159】

それに加え、本実施形態に係るコミュニケーション管理システム１００は、コミュニケーショングループにプロジェクト、タスクといった機能を割り当てることにより、ビジネス、ここでは、ある特定の目的の遂行状況の管理を容易化するとともに可視化することができる。そのため、図３に示すように、コミュニケーション管理システム１００は、ガントチャート作成部１１１を備えている。

【0160】

ガントチャート作成部１１１は、コミュニケーショングループ間の階層構造及び期間情報に基づいて、コミュニケーショングループを一の軸（通常は縦軸）に、期間情報を他の軸（通常は横軸）とするガントチャートを作成する。この点詳しく説明すると、コミュニケーショングループには、コミュニケーショングループ間の階層構造を記録することができるから、あるコミュニケーショングループ、例えばプロジェクトの下にどのコミュニケーショングループ、例えばタスクが含まれるかは容易に把握することができる。

【0161】

従って、上位のコミュニケーショングループを一の軸、ここでは縦軸の上方に配置し、下位のコミュニケーショングループを下方に配置することで、コミュニケーショングループを階層的に配置することができる。また、コミュニケーショングループのうち、タスクには必ず期間情報が含まれるため、他の軸、ここでは横軸を時間軸とすることにより、各コミュニケーショングループを横棒グラフとして示すことができ、容易にガントチャートとして示すことができる。

【0162】

ここで、タスク以外のコミュニケーショングループについても、その期間が示されていれば、当該期間を期間情報として使用すればよい。また、期間が示されていないコミュニケーショングループについては、その下位に属するコミュニケーショングループの期間の最先の開始時から最後の終了時までの期間をその期間とすればよい。自身に期間が設定されておらず、またその下位のコミュニケーショングループが存在しないか、存在しても期間が設定されていないものについては、特に期間を表示する必要はなく、後から期間が設定され、あるいは、その下位に期間の設定のあるコミュニケーショングループが追加された時点で改めて期間が表示されることになる。

【0163】

ガントチャート上では、プロジェクト、タスク、問い合わせといったコミュニケーショングループの種別が示されるとともに、そのアクティブ及びノンアクティブの別が一見して明らかなように示されることが望ましい。すなわち、アクティブは未着手又は進行中のプロセスを、ノンアクティブは完了済みのプロセスを意味するためである。

【0164】

図１３は、図４のグループについてガントチャート作成部１１１が作成しユーザに表示するガントチャートの例である。ここでは、ユーザは、例えば、図８に示したユーザインタフェースで、上部タイトル欄右側のシンボルのうち、左側のシンボルを選択することにより、現在選択中のコミュニケーショングループであグループ２についてのガントチャートの作成および表示をコミュニケーション管理システム１００に指示する。

【0165】

その結果、クライアント端末３のモニタ上には、図１３のようなガントチャートが表示される。ここで、グループ２の下位にあたるコミュニケーショングループは、グループ３～７であるから、ガントチャート作成の対象となるのはグループ２～７となり、ガントチャート左側欄には、これらグループ名が縦に並んで示される。

【0166】

なお、ガントチャート上でのコミュニケーショングループの並び順は、ユーザの操作により適宜変更できてもよい。ここでは、階層が上位のものの下に階層が下位のものが配置される階層順を優先とし、同階層のコミュニケーショングループ同士であれば、期間の開始時の早いものが上側になるように配置しているが、この配置の優先順は変更できてもよい。また、階層や期間の開示時だけでなく、コミュニケーショングループの種別、コミュニケーショングループの作成順、期間の終了時等に基づいて配置を変更できるようにしてもよい。

【0167】

ガントチャート右側欄には、それぞれのコミュニケーショングループの期間が横棒の形式で示される。ここで、ノンアクティブのコミュニケーショングループの期間は黒塗りで示し、アクティブのコミュニケーショングループの期間は白抜きで示すなど色分けして示しているため、全体における進捗具合が直ちに把握できるようになっている。また、図４に示されているように、グループ２には期間は設定されていないが、ガントチャート上では、その下位に属するコミュニケーショングループの期間の最先の開始時、すなわち、グループ３の期間の開始時と、最後の終了時、すなわち、グループ７の終了時をその期間として示している。

【0168】

なお、図１３の例では最上位のコミュニケーショングループがプロジェクトであり、その下位のコミュニケーショングループは全てタスクである場合を示しているが、これに限られず、プロジェクトの下にさらに別のプロジェクトが子プロジェクトあるいは孫プロジェクトとして存在してもよいし、問い合わせが下位に存在してもよく、また、最上位のコミュニケーショングループの種別も限定されるものではないから、複数種類のコミュニケーショングループが関係する複雑なビジネスプロセスも簡単に一覧及び管理することができる。

【符号の説明】

【0169】

１ コンピュータ、１ａ ＣＰＵ、１ｂ ＲＡＭ、１ｃ 外部記憶装置、１ｄ ＧＣ、１ｅ 入力デバイス、１ｆ Ｉ／Ｏ、１ｇ データバス、１ｈ モニタ、２ サーバ、３ クライアント端末、４ ヘッドセット、５ ＰＣ、６ スマートフォン、７ タブレット端末、８ 電話機、３０ メールクライアント、３１ チャットクライアント、３２ ソフトフォン、１００ コミュニケーション管理システム、１０１ コミュニケーショングループデータベース、１０２ コミュニケーションデータベース、１０３ ユーザデータベース、１０４ コミュニケーション一覧表示部、１０５ コミュニケーショングループ作成部、１０６ ユーザ編集部、１０７ コミュニケーション取得部、１０８ コミュニケーション紐づけ部、１０９ システムコミュニケーションクライアント、１１０ 自動コミュニケーショングループ作成部、１１１ ガントチャート作成部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】