JP4547996B2 - コミュニケーション装置及びコミュニケーション概要作成方法 - Google Patents

Description

本発明は、コミュニケーションサービスを利用して複数のユーザとマルチメディアデータを送受信するコミュニケーション装置、及びそこでやりとりされるコミュニケーションの概要を把握するコミュニケーション概要作成方法に関する。

近年、コミュニケーションシステムの発達により、従来にまして、多くのユーザ、コミュニティとの関係を保つために、様々なツールを利用できるようになった。それ故に、個人が関わるコミュニティやユーザが多くなり、自分宛に送られてくるメッセージ、コミュニティで共有するメッセージなどの閲覧が困難になってきている。例えば、迷惑メールや、登録人数の多いコミュニティでの自分に関係のない対話等がノイズとなって、自分の必要なメッセージの確認をより困難にする要因となっている。現在、これらの状況に対して、ユーザとのメッセージの確認、自分の関わるコミュニティでのメッセージ交換状況の把握を簡単に行う方法が求められている。

従来から、数多くのメッセージを受信した場合に、その送信者や特定のキーワードごとに自動的に分類する方法が提案されてきた。例えば、無線テキスト送受信システムや、電子メールシステムにおいて、送信者ごとに分類を行い、ユーザが対話の相手別に内容を把握できるようにしている（例えば、特許文献１及び２参照。）。また、送信者を指定することによって、メッセージを一括表示させることにより、閲覧の手間を減らす方法が提案されている（例えば、特許文献３参照。）。
特許第３２０３１８７号 特開平８−１９４６５４号公報 特開平１０−１３８８１号公報

しかしながら、これら特許文献１〜３に記載の手法では、個人対個人のメッセージの整理には役立つが、グループの動向の把握はできていない。また、１つのコミュニケーション手段に特化したものであり、１人のユーザ、１つのコミュニティに対して複数の手段が用いられる昨今の状況に即していない。さらに、送信者をキーにメールを閲覧できたとして、ユーザが常時対話を行っている相手が多数いる場合、いま注目すべき送信者が誰であるかはわかりにくい。

斯かる点に鑑み、本発明は、一人のユーザが、多くのユーザ、コミュニティと交換する大量のメッセージやコンテンツ等に対して、特定のメッセージやコンテンツの動向など概要を把握でき、また、１人のユーザ、１つのコミュニティに対して複数のコミュニケーション手段が用いられる環境に対応できるようにすることを目的とする。

上記課題を解決し、目的を達成するため、本発明は、コミュニケーションサービスを利用して行われた複数のユーザとのコミュニケーションの概要を作成する際、利用者がコミュニケーションサービスを利用して受信したデータ内容を、ユーザリスト及び利用者が属するコミュニティリストからなるアドレスデータを用い、所定の規則に従って抽出し、この抽出された内容を通信履歴データとして通信履歴データベースに記録し、この通信履歴データベースに記録された通信履歴データについて、このアドレスデータと、利用者のユーザ及びコミュニティに対する優先度順を示すユーザ嗜好データとを用いて、利用者が属するコミュニティのうち優先度の高いコミュニティ宛毎の受信件数の集計、優先度の高い発信元ユーザ毎の受信件数の集計、及び受信データの宛先が利用者宛かコミュニティ内の他人宛かを区別して行う受信件数の集計を組み合わせて実行し、この集計結果をコミュニケーションの概要として抽出し、利用者の指示に応じて、抽出されたコミュニケーションの概要から表示部の仕様に従い必要な情報を選択し表示部に送出することを特徴とする。

斯かる本発明によれば、コミュニケーション相手からの対話やメッセージ等の内容を、ユーザリスト及び利用者が属するコミュニティリストからなるアドレスデータベースを用い、所定の規則に従い抽出して通信履歴データとし、この通信履歴データについて、アドレスデータベースと、利用者のユーザ及びコミュニティに対する優先度順を示すユーザ嗜好データとを用いて、利用者が属するコミュニティのうち優先度の高いコミュニティ宛毎の受信件数の集計、優先度の高い発信元ユーザ毎の受信件数の集計、及び受信データの宛先が利用者宛かコミュニティ内の他人宛かを区別して行う受信件数の集計を組み合わせて実行することにより、送られてきたメッセージが自分宛なのか、コミュニティ宛であるのか、また、それが優先度の高い気にかけている人か、コミュニティからのものなのかといったコミュニケーションの概要を、利用者が簡単に把握することができる。

また、上述の本発明において、好適な他の形態は、例えばトピックとして、
・あるコミュニティで特定の人の発言があった場合である「特定発言者」
・普段発言しない人が発言していること、音沙汰がない人からメッセージを受けた場合である「まれな発言者」
・特定のコミュニティにおいて、一定時間内に多数のメッセージがあった場合である「盛り上がり」
・自分のメッセージに対する返答である場合である「返答」
・特定の人から、自分に対して、一定時間内に多数のメッセージがあった場合である「多数アクセス」
・メッセージ発信者の重要度と、受信ユーザとの優先度が共に高い時である「重要度マッチ」
・特定のコミュニティにおいて、ある期間、発言が全く無い場合である「沈黙」
のうちの少なくとも１つを設定して、このトピックの判定の基準となるトピック判定設定データを登録し、通信履歴データからこのトピック判定設定データに基づきトピック件数を集計することである。

この場合、ユーザが単なる集計データだけではなく、コミュニティや相手の様子、重要なトピックなどに気付きやすくなる。

本発明によれば、利用者は多くのユーザ、コミュニティと交換する大量のメッセージに対して、以下に述べる様々な観点から、他ユーザやコミュニティの概要を把握しやすくなるという効果がある。

まず、一般的な着信件数及びメール未読件数表示に比べて、送られてきたメッセージが自分宛なのか、コミュニティ宛であるのか、また、それが優先度の高い気にかけている人か、コミュニティからのものなのかといったコミュニケーションの概要を、利用者が簡単に把握することができる。また、トピックの判定により概要抽出した場合、ユーザが単なる集計データだけではなく、コミュニティや相手の様子、重要なトピックなどに気付きやすくすることができる。また、根本的に迷惑メールに惑わされることがなくなるので、大事なメッセージを確認しやすくなる。

したがって、上述のコミュニケーションの概要情報を基に、利用者は今後の対話をどのように処理していくかを的確に判断することができる効果がある。

さらに、本発明は、１つのコミュニケーションサービスにとどまらず、ユーザが利用している数に合わせて複数のコミュニケーションサービスに同時に適用することができる。

以下、図面を参照して、本発明の一実施の形態の例について説明する。まず、コミュニケーションサービスとして、電子メールシステム（以下、単にメールという。）、電話を利用する場合について、図１〜図１８を参照しながら述べる。

図１は、本発明の一実施の形態の例のシステム構成を示す図である。図１に示すシステムの概要を説明する。図１において、クライアント１は、コミュニケーションサービス１０として、電話やメールの利用が可能であり、例えば電話交換機１１を介して通話を行ったり、ネットワーク上のメールサーバ１２にアクセスしてメールの送受信を行うことができる。また、ウェブブラウザを備え、複数のユーザ間でコンテンツを共有することができるコンテンツ共有システム１３を閲覧する機能も兼ね備える。

上述のクライアント１は、電話着信探知部２及びメール監視部３を備え、電話着信探知部２では、電話の着信時に発呼者と日時を内容抽出部３０に送信し、またメール監視部３では、メールを受信した際に送信者、宛先、タイトル、内容全てのデータを内容抽出部３０に送信する。

また、コンテンツ共有システム監視部１４は、コンテンツ共有システム１３において、ユーザがアクセスできるコンテンツコンテナにおける新たな投稿を全て内容抽出部３０に送信することができる。

さらに、ユーザ設定管理部２０は、アドレス帳（アドレスデータベース）２１やユーザ嗜好データベース２２を備え、クライアント１からの指示によって、アドレス帳、ユーザ嗜好データを開示、変更する。アドレス帳は、図２に示すようなユーザのリストや、図３に示すようなユーザが属するコミュニティとそのメンバーなどが記録されている。例えば図２に示されるようにユーザリストは、コミュニケーションシステム内のユーザを識別するユーザＩＤ、名称、電話番号、メールアドレスなどの情報が登録される。また図３に示されるようにコミュニティリストには、コミュニティＩＤ、名称、メンバー、メーリングリストなどの情報が登録されている。

またユーザ嗜好データには、そのユーザが、どのような人物、コミュニティに注目しているかを表すデータが格納されている（図４参照）。例えば図４に示されるようにユーザ嗜好データには、優先度と対応付けられたユーザＩＤが登録されている。なお、ユーザ設定管理部２０を構成するトピック判定設定データベース２３については、後に詳述する。

内容抽出部（内容抽出手段）３０は、宛先判定部３１及びキーワード判定部３２を備え、メール、着信履歴、コンテンツ共有システムより送信されたデータから、予め定められた規則に従って、内容を抽出し、履歴管理部４０に送信する。宛先判定部３１は、電話やメール等の履歴から、例えば電話の発呼者、メールの送信者及び宛先が上記ユーザリストに登録されたどのユーザ又はコミュニティであるかを判定し、履歴管理部４０に情報を提供する。キーワード判定部３２は、メールデータから特定の文字列を抽出するものである。

履歴管理部（履歴管理手段）４０は、通信履歴データベース４１に格納された通信履歴データの読み書きの要求に応えてこれを実行する。なお、嗜好データ更新部４２については、後に詳述する。

概要抽出部（概要抽出手段）５０は、履歴管理部４０から通信履歴データを読み出し、ユーザに伝えるべき概要情報を抽出する。より具体的には、例えば集計管理部６１及び対話集計データベース６２を備える対話集計部（対話集計手段）６０が、ユーザ嗜好データとアドレス帳と通信履歴のデータから、未読であるメッセージの件数を概要として抽出し、概要選択部８０に送信する。なお、概要抽出部５０を構成するトピック集計部（トピック集計手段）７０については、後に詳述する。

概要選択部（概要選択手段）８０は、表示構成部（表示構成手段）９０からの要求に従って、概要抽出部５０が作成した概要から、画面に表示できるだけの情報を抽出して、表示構成部９０に送出する。

表示構成部９０は、概要選択部から送られた情報を所定形式に整え、クライアント１の画面に表示する。

図１に示すコミュニケーションサービス１０を除く、クライアント１及びその他ブロックは、携帯電話やＰＣ（パーソナルコンピュータ）などのコンピュータ上のアプリケーションプログラムとして動作し、データは図示しない不揮発性の記録媒体に記録される。

上述のシステム構成の詳細な動作について、具体例を用いて説明する。本例で、中心となる第１ユーザの氏名を仮に「朝倉すみか」（１６歳）とする。その他のユーザとして、第２ユーザ「山本こずえ」、第３ユーザ「田中かおり」、第３ユーザ「朝倉健二」がいるとする。そして、第１ユーザの「朝倉すみか」は、テニスクラブ、仲良し三人組、朝倉家という３つのコミュニティに所属しているものとする。このような設定において、ある日の、「朝倉すみか」が関係するメッセージのやりとりが、図５に示されるようであったとする。これは、メッセージのやり取りを時系列に表したものである。

この状況において、まず、一般的な表示方式を適用した場合について述べる。図５に示される履歴データに対して、一般的な携帯電話などの端末では例えば図６に示すような待ち受け画面を表示する。ユーザ（朝倉すみか）が、この待ち受け画面を見て、さらに確認することは、誰から電話があったか、どんなメールが来ているか、ということである。そこでユーザは、「着信履歴」及び「メール一覧」を確認する。

図７は、一般的な着信履歴表示画面の一例を示すものである。ここで、ユーザは、まず図７に示す着信履歴を見て、誰から着信があったのかを確認する。このとき、４件の着信のうち、アドレス帳に登録されていない番号は、名前ではなく、電話番号で表示される。ユーザはこれを、迷惑電話と判断し、無視する。本例では、２人の友人からの着信があったが、一人は親友（山本こずえ）、もう一人はクラブの友達である。

図８は、メール一覧表示画面の一例を示すものである。ユーザは、メール一覧を確認すると、広告のメールである迷惑メールが多数来ており、どんな人からのメールがどの程度きているのか分かりづらい。また、画面の表示面積がもっと大きかったとしても、メーリングリストにおいて、誰に対してメッセージを発信しているのか、分かりづらい。さらに対話手段が増えた場合、同じユーザ、同じコミュニティでも複数のコミュニケーション手段を利用するため、ユーザは全体の状況の把握が困難になり、メッセージを端から一つずつ処理して行かなくてはならない。もしくは、１つのメッセージに対応している内に、処理時間がなくなってしまい大切なメッセージを読み落としたり、返事を忘れたりする可能性が高くなる。

上述のような状況に対して、本例では、下記のような観点で件数をまとめることにより、ユーザが対話状況を把握しやすくする。すなわち、
・自分に対してどんなメッセージが来ているのか。
・自分の属するコミュニティがどんな対話状況なのか。
・気になる人はどんな対話をしているのか。
という点である。これらの概要を提供することによって、ユーザがまずどこを確認すべきか、どのメッセージの返答を先に行うべきか、などを判断しやすくする。

以下、さらに具体的に説明する。まず、ユーザ（朝倉すみか）が電話を受けると、クライアント１内部にある電話着信探知部２が、着信日時、発信者番号、受話したか否か、の情報を内容抽出部３０に送信する。例えば、図５に示す履歴データの事象９で電話を着信した場合、電話着信探知部２は、内容抽出部３０に対し図９Ａに示す内容の内容抽出履歴登録コマンドを送信する。

内容抽出部３０は、電話である場合は、アドレス帳を用いて、上記内容抽出履歴登録コマンド中の電話番号に対応するユーザＩＤを検索する。ユーザＩＤが見つかった場合、電話番号をユーザＩＤに変更して、通信履歴登録コマンドを履歴管理部４０に送信する。

履歴管理部４０は、履歴更新コマンドを受信し、例えば図１０に示す通信履歴一覧のＮｏ．９の項目の履歴を、通信履歴データベース４１に記録する。この通信履歴には、例えば受付日時、タイプ（コミュニケーション手段の種類）、参照ＩＤ、送信者、電話に出たか又はメールが既読であるかを示す未対応、宛先、自分宛、メールタイトル等の情報が記録されている。なお、未対応について、メールの対応は、全て読んだときだけでなく、一度開いただけでも対応済みとすることもできる。

また図５に示す事象３において、ユーザがメールを受信すると、メール監視部３は、受信したメールを基に、図９Ｂに示す内容抽出履歴登録コマンドを、内容抽出部３０に送信する。

内容抽出部３０は、入力されたメールデータに対して、宛先の抽出作業を行うとともに、宛先判定部３１において宛先の判定を行う。メールヘッダのＴｏ（宛先）、ＣＣ（同報宛先）のアドレスに対して、図２に示したユーザリスト、図３に示したコミュニティリストとの照合を行い、アドレスをユーザＩＤもしくはコミュニティＩＤに変換する。この例では、宛先はＴｏにＵ００１が記載されているのみであるので、宛先はＵ００１となり、宛先判定部３１は自分宛フラグをＴＲＵＥ（真）とする。その結果、最終的には、図１０に示す通信履歴データのＮｏ．３のように通信履歴に記録される。

異なる例として、例えば、事象７（図５参照）でのメール受信においては、メールヘッダのＴｏがＣＭ００１というコミュニティの宛先になっているため、自分宛フラグはＦＡＬＳＥ（偽）となっている。この履歴は、図１０に示す着信履歴データの７行目の通り記録される。

また、事象１１（図５参照）では、メールヘッダのＴｏにＣＭ００１とＵ００１が含まれている。これはつまり、発信者が明示的にＵ００１を指定することによって、コミュニティの話題であっても、特に宛先をしていることになる。このため、宛先判定部３１は、この場合においては、自分宛フラグをＴＲＵＥにする。この履歴は、通信履歴データ（図１０参照）のＮｏ．１１のように記録される。このようにして、通信履歴が通信履歴データベース４１に登録、蓄積されていく。

次に、ユーザが対話概要を見たいと思った時に、クライアント１上で所定の操作を行い指示すると、クライアント１は表示構成部９０に対して、概要表示を要求する概要出力コマンドを送信する。そして、表示構成部９０は、概要出力コマンドを、クライアント１の表示能力（ドット数、文字表示行数、一行当たりの文字数）と共に、概要選択部８０に送信する。概要選択部８０は、予め決められたルールに従って、クライアント１の表示能力から、表示できる項目数、項目別の内容を決定する。

概要選択のルールの例としては、例えば、
・全体の行数のうち、1行を総合集計に用いる。
・全体の行数のうち、３行をボタン、見出しなどに用いる。
・全体の行数のうち、その他の行で個別の集計結果を表示する。
などとする。

本例において、クライアント１が７行程度の表示能力の携帯電話とした場合、個別集計の表示数は３となる。

次に、概要選択部８０は、トータル件数、個別件数、残集計数を計算していく。

まず、トータル件数の集計である。これは、自分に対して発信されたメッセージ数、自分が所属するコミュニティに対して発信されたメッセージの合計である。概要選択部８０は、概要抽出部５０に対して、トータル件数集計要求コマンドを送信する。そして、概要抽出部５０は、対話集計部６０の集計管理部６１において、履歴管理部４０から「未対応欄がＴＲＵＥである」全ての履歴を読み出す。

そこで「自分宛フラグ」が「ＴＲＵＥ」の件数を「自分宛メッセージ数」とし、「ＦＡＬＳＥ」である件数を「コミュニティ宛メッセージ」として集計する。例えば、図１０に示す通信履歴では、未対応の自分宛メッセージは１３件、コミュニティ宛メッセージは３件となる。

次に、個別件数集計を行う。本例では個別件数集計表示ができるのは３件となっている。対話集計部６０は、ユーザ嗜好データベース２２のユーザ嗜好データのうち優先度の高い上位の３つを選択する。この場合は、図４に示されるＵ００２、Ｕ００３、ＣＭ００１のＩＤを持つユーザが選択される。

この対話集計部６０の集計管理部６１では、図１１に示すフローチャートに従って個別集計処理が行われる。まず、履歴管理部４０より、通信履歴の未対応欄がＴＲＵＥである履歴を１つ読み出す（ステップＳ１）。その履歴の送信者を確認し、集計対象である送信者かどうかを確認する（ステップＳ２）。例えば、履歴Ｎｏ．１（図１０参照）の場合は、送信者が対象者でないので、ステップＳ６に進む。履歴Ｎｏ．４（図１０参照）の場合には、送信者がＵ００２であるので、ステップＳ３に進む。上述ステップＳ１において、未対応履歴が無い場合は処理を終了する。

続いて自分宛の通信履歴があるか、すなわち自分宛の項目がＴＲＵＥであるかどうかを確認する（ステップＳ３）。自分宛の項目がある場合、該当ユーザ集計の自分宛に加算する（ステップＳ４）。図１２は、集計データの構造を示すものであり、この集計データの該当するユーザＩＤの行の自分宛のカウントを１つ追加して、ステップＳ６へ進む。例えば、履歴Ｎｏ．４の場合には、図１２に示す送信者Ｕ００２の行の自分宛のカウントを１つインクリメントする。

また、判断ステップＳ３において自分宛の通信履歴がない場合、すなわちコミュニティ宛ての場合は、該当ユーザ集計のコミュニティ宛てに加算する（ステップＳ５）。図１２に示す集計データの該当するユーザＩＤの行の、コミュニティ宛のカウントを１つ追加して、ステップＳ６へ進む。例えば、履歴Ｎｏ．６（図１０参照）の場合には、図１２に示すＵ００３の行のコミュニティ宛のカウントを１つインクリメントする。

ステップＳ２、Ｓ４、Ｓ５のいずれかにおいて処理が終了したら、宛先が対象コミュニティであるかどうかを確認する（ステップＳ６）。例えば、履歴Ｎｏ．１（図１０参照）の場合には、宛先が対象コミュニティではないので、ステップＳ１に戻る。履歴Ｎｏ．１に対して、集計管理部６１は、集計に加えていない。

ステップＳ６において、対象コミュニティが宛先となっている場合、次いで履歴情報が自分宛かどうかを確認する（ステップＳ７）。そして、自分宛である場合、該当コミュニティ集計の自分宛のカウントを１つ加算し（ステップＳ８）、ステップＳ１に戻る。例えば、履歴Ｎｏ．１１（図１０参照）の場合は、図１２に示す集計データのコミュニティＩＤ（ＣＭ００１）の行の、自分宛のカウントをインクリメントする。

またステップＳ７において、履歴情報が自分宛でない場合、該当コミュニティ集計のコミュニティ宛のカウントを１つ加算し（ステップＳ９）、ステップＳ１に戻る。例えば、履歴Ｎｏ．６（図１０参照）の場合は、図１２に示す集計データのコミュニティＩＤ（ＣＭ００１）の行の、コミュニティ宛のカウントをインクリメントする。

このようにして、本例では、対話集計部６０が、通信履歴より図１２に示される集計データを作成し、概要選択部８０に送信する。そして、概要選択部８０は、表示構成部９０から得られた画面仕様に従ってその範囲で表示できる、集計情報を送信する。表示構成部９０は、レイアウト情報や装飾情報を加えて、クライアント１の画面に対話集計結果を表示する。

図１３は、対話集計結果表示画面の例を示し、注目項目として、上から図１２の集計データにある山本こずえ（Ｕ００２）、田中かおり（Ｕ００３）、テニスクラブ（ＣＭ００１）が順に表示されている。図１３の例では、注目ユーザ又はコミュニティを写真や絵で表示している。例えば、「山本こずえ」と「田中かおり」は図面上同じ顔だが、実際には写真表示なので区別は容易である。必要であれば、写真周辺（横など）にユーザ名を表示するようにしてもよい。このようにすると、顔を見ても名前が思い出せない場合に重宝する。その逆に、名前から顔が浮かばないような場合にもユーザ個人を認識するのに役立つ。

図１３において、ユーザがクライアント１上でカーソルキー（図示略）を操作することによって、各項目を選択して、より詳細を確認することができる。なお、一般的な着信件数、メール未読件数表示を一緒に表示するようにしてもよい。

例えば、ユーザが対話集計結果表示画面を見て、注目項目の１番目を選択した場合、クライアント１から表示構成部９０を通じて、概要選択部８０に、項目別リスト表示要求(１ページ目)が送信される。この要求はパラメータとして山本こずえのユーザＩＤ（Ｕ００２）を含んでいる。表示構成部９０から項目別リスト表示要求を受けた概要選択部８０は、概要抽出部５０に対して、項目別リスト作成要求を送信し、概要抽出部５０は、項目別リスト作成要求を受信すると、図１４に示すフローチャートに従って、項目別リストの作成を行う。

図１４は、項目別リスト作成処理を示すフローチャートである。まず要求されたものがユーザ別リストかどうかを確認し（ステップＳ１１）、ユーザ別リストである場合はステップＳ１２に進み、ユーザ別リストでない場合はステップＳ１５に進む。

上述ステップＳ１１にて、ユーザ別リストであった場合、未対応履歴があるかどうかを確認する（ステップ１２）。未対応履歴があるときにはその送信者が対象者であるかどうかを確認し（ステップＳ１３）、未対応履歴がないときには処理を終了する。そして、送信者が対象者である場合は、項目別（ユーザ別）リストに追加し（ステップＳ１４）、追加後さらにステップＳ１２に戻り、次の未対応履歴があるかどうかを確認する。送信者が対象者でなかった場合も、ステップＳ１２に戻り、次の未対応履歴を探す。

一方、上述ステップＳ１１にて、要求がユーザ別リストではない、すなわちコミュニティ別リストであった場合、未対応履歴があるかどうかを確認する（ステップ１５）。未対応履歴があるときには宛先が対象コミュニティであるかどうかを確認し（ステップＳ１６）、未対応履歴がないときには処理を終了する。そして、宛先が対象コミュニティである場合は、項目別（コミュニティ別）リストに追加し（ステップＳ１７）、追加後さらにステップＳ１５に戻り、次の未対応履歴があるかどうかを確認する。宛先が対象コミュニティでなかった場合も、ステップＳ１５に戻り、次の未対応履歴を探す。

例えば、山本こずえ（Ｕ００２）に関する項目別リストを作成すると、図１５に示す項目別リストが作成され、最終的にクライアント１には、図１６に示す画面が表示される。図１８に示す表示画面には、例えば、自分宛件として２件表示され、タイプ、日時、タイトルなどが表示される。

また、テニスクラブ（ＣＭ００１）に関する項目別リストを作成すると、図１７に示すリストが作成され、最終的にクライアント１には、図１８に示す画面が表示される。図１８に示す表示画面には、自分宛として１件、コミュニティ宛として３件が表示される。なお、図１８の例では、表示画面の制約からコミュニティ宛として２件しか表示されていないが、「次ページ」ボタンを押下することで、３件目を表示できる。

なお、上述の対話集計データは、ユーザの表示要求時に作成するのではなく、定期的又は履歴が更新されるたびに作成しておき、表示要求時にはすぐに結果を返して、クライアント１に表示させるようにすることもできる。また、集計された未読メッセージについて、人、コミュニティなどのひとくくりでクリア（消去又は既読化）することができる。

ユーザは、これらの項目別リストから、カーソルにより項目を選択して、メールの内容を閲覧したり、相手に電話したりすることをメニューなどによって簡単に行うことができる。

以上のようにして、上述した実施の形態により、ユーザは、メール、電話といった手段別の状況ではなく、メッセージの一覧などをいちいち確認せずに、自分に対するメッセージ、コミュニティに対するメッセージという観点で状況を把握できる。さらに、特に気にかけている人、コミュニティというフィルタリングを行って容易に確認することができる。

したがって、一般的な着信件数及びメール未読件数表示に比べて、メッセージが自分宛なのか、コミュニティ宛であるのか、また、それが気にかけている人、コミュニティからのものなのかを把握することができ、大事なメッセージの内容を優先して確認し、返答をしていく、といったことを効率的に進めることができる。また、迷惑メールに惑わされず、簡単に大事なメッセージのみを確認できる。また、人やコミュニティの状況の把握が容易である。

例えば、図１５に示す対話集計結果表示画面から、ユーザは、山本こずえからのものは自分に用事がある一方、同じ親友の田中かおりの発言が自分宛でない、ということを簡単に確認できる。また、テニスクラブというコミュニティにおけるメッセージのなかでも、自分に向けられたメッセージが１件あることを知ることができるため、このメッセージを先に確認する、という判断を容易に行うことができる。

さらに、図１において、内容抽出部３０に特定の文字列判定機能を持つキーワード判定部３２を設けるようにした場合、人、コミュニティだけなく、特定のキーワードを軸としてメッセージを集計することも可能である。例えば「緊急」というキーワードについて、「自分宛の件数」「コミュニティ宛の件数」を集計して、人、コミュニティと同様に並べて表示することもできる。

また、宛先の判定方法として、メールヘッダのＴｏの記載内容だけでなく、メール本文中のキーワード（自分の名前など）を検索して、そのキーワードが存在した場合には、自分宛フラグをＴＲＵＥにする、という手法も適用可能である。

さらに、特定の文字列判定（「未承諾広告」などの文字列）によって、自分が読むべきメールであるかどうかの判定精度を上げることも可能である。

なお、図１０に示した通信履歴の項目は一例であり、内容抽出部３０で抽出して履歴に残す項目を増やすことによって、より細かい集計データを作成することができる。

また、集計方法として、発信者がアドレス帳に存在する場合とそうでない場合を分けるという方法も迷惑通信を除外する上で効果的であり、本実施例に容易に適用することができる。また、集計時にタイプを区別することによって、より細かな集計データを作成することができる。

また、ユーザが総合の件数（図１３参照）を選択した場合に、ユーザ嗜好リスト（図４参照）に登録されている全てのユーザ、コミュニティについて、集計を行って表示をすることにより、最初の画面で概要ができなかったユーザ、コミュニティに対しても、少ない手順で、概要情報を確認することができる。

また、コミュニケーションシステムの数は、ユーザが利用している数に合わせればよい。ただし、アドレス帳２１と通信履歴データベース４１は、複数のコミュニケーションシステムで共有し１つであってもよい。

次に、図１に示すシステム構成において、コンテンツ共有システム１３に対応した場合について述べる。

図１に示すように、コンテンツ共有システム１３の投稿状態を監視する、コンテンツ共有システム監視部１４が設置され、ユーザが関係するコンテンツコンテナ（以下、コンテナともいう。）に対して、対話を監視する。また、本実施例において、アドレス帳データにおけるユーザリストは、図２７に示すように、図２に対しコンテンツ共有システムＩＤの項目が追加される。同様に、コミュニティリストは、図２８に示すように、図３に対しそのコミュニティが利用しているコンテナＩＤの項目が追加されている。

以下、コンテンツ共有システムの概要について、図１９〜図２６を用いて説明する。コンテンツ共有システムは、複数のユーザが、静止画像、動画、音声、テキストを例とするマルチメディアデータをインターネット等の通信網を介して記録、読み出すことができるシステムである。このシステムの基本的な構成は、インターネット等の通信網上のサーバと、各ユーザが操作する複数のクライアントからなる。

図１９は、コンテンツ共有システムの概略構成を示す図である。図１９において、コンテンツ管理部２００は、後述するメディアデータとメタデータからなるコンテンツ（図２２参照）を管理するモジュールであり、コンテンツの保存、修正、コメント追加、閲覧等を制御する。また、適切な認証手段により、許可されたクライアントのみが各種操作を実行することができるようになっている。

またクライアント１００及び４００は、ユーザが直接操作を行うアプリケーションプログラムであり、メディアのキャプチャ、テキスト入力などのユーザインターフェース、位置情報などのメタデータの取得、コンテンツ管理部２００へのコンテンツの登録、コンテンツの表示等の機能を提供するものである。ユーザはクライアントを介して、システム上に公開されたコンテンツの閲覧、登録、取得、削除、変更等の操作を行うことができる。

また表示構成部３００は、図１に示す表示構成部９０と同様の機能を備え、コンテンツ管理部２００からコンテンツデータを取得し、適切な形にレイアウトするものであり、サーバ上又はクライアント端末のいずれかに格納されていればよい。レイアウト方法は、例えば複数ユーザのコンテンツを最新順に表示したり、特定ユーザのコンテンツのみを表示する等、種々の方法が適用できる。

図１９に示されるコンテンツ共有システムの具体的な構成方法の一例は、例えばコンテンツ管理部をJava（登録商標）Servletとし、表示構成部及びクライアントを携帯電話上で動作するJavaアプリケーションプログラムとするものである。

また、コンテンツ共有システムの異なる構成方法の一例は、例えばコンテンツ管理部と表示構成部をJava Servletとし、クライアントをＰＣ（パーソナルコンピュータ）上などのウェブブラウザとするものである。

本実施例で説明するコンテンツ管理部２００等のクライアント１００，４００以外のブロックは、全てサーバで動作するが、各ブロックがネットワーク上に分散していたり、クライアントを操作するユーザに依存する情報や、一部の機能が、クライアントに含まれていてもよい。また、各ブロックは、異なるサーバ上で動作するネットワーク上のサービスでもよいし、同一サーバで動作する異なるプログラムでもよいし、同一プログラム内のライブラリでもよい。

クライアント、サーバ、いずれもコンピュータ上のプログラムとして動作し、データはそれらの図示しない不揮発性の記録媒体に記録される。

以下、コンテンツ共有システムについてより具体的な例を用いて説明する。図２０は、例えばコンテンツ共有システムを用いた電子掲示板システムのユーザ利用画面である、コンテンツコンテナ表示画面の一例である。ここでは６人のユーザ（山田、佐藤、加藤、佐々木、木村、飯島）が互いにコンテンツを共有している。本システムでは、特定のコンテンツの集合を、コンテンツコンテナ（単にコンテナともいう。）と呼ぶ。

コンテンツコンテナには複数のユーザが複数のコンテンツを書き込み、また読み出すことができる。更に、コンテンツコンテナにはユーザごとのアクセス権を設定することができる。この例では説明の簡略化のため、コンテンツの書き込み方法を２つに定義している。１つは、画像投稿であり、画像データとそのタイトルを書き込みの単位とする。もう１つは、コメント投稿であり、テキストデータによる文章を書き込みの単位とするものである。

図２０においては、「９０年度３年Ｂ組の部屋」というコンテナ名称１１１のコンテンツコンテナに、ユーザが画像やコメントを投稿した例を表している。例えば、画像データ表示１１３は、山田というユーザによって投稿された画像であり、投稿者・タイトル表示１１４において、投稿者名と投稿者が設定したタイトルが表示されている。投稿者・コメント表示１１６は、この山田の投稿に対して、他のユーザがコメントを投稿した結果の表示である。図では１つのコメントは１行に表示されているがこの限りではない。

また、図２０において、１１２はこのコンテンツコンテナに画像を投稿する際に押下する画像投稿ボタン、１１５はコメントを投稿する際に使用するコメントボタン、１１７はコンテンツコンテナを作成する際に使用するコンテナ作成ボタンである。

次に、本システムにおいて、投稿、コメント、閲覧がどのような方法によって実現されているかを説明する。まず、図２０〜図２４を参照して、画像投稿時の動作について述べる。

図２１は、コンテンツ管理部２００の内部構成を示したものである。コンテンツ管理部２００は、制御部２０１、コンテンツデータ部２０２、アクションデータ部２０３、認証データ部２０４から構成されている。

図２１において、コンテンツ管理部２００内の制御部２０１は、外部からの各種コマンドの受付、内部のデータの管理、表示構成部３００への表示指示などを行う。またコンテンツデータ部２０２は、コンテンツ及びコンテンツコンテナのデータを保存する。またアクションデータ部２０３は、何らかの処理を行うコードが保存されている。さらに認証データ部２０４は、ユーザデータ、パスワードなどの認証に必要なデータが保存される。この認証データは外部に保存されていてもよい。

図２２は、コンテンツデータ部２０２のデータ構成を図示したものであり、Ａはコンテンツコンテナ部２０２の構成、Ｂはコンテンツコンテナの構成、Ｃはコンテンツの構成を示す。コンテンツデータ部２０２は、複数の例えばコンテンツコンテナ２１１，２１２…を保存、管理している。さらに、ひとつのコンテンツコンテナ２１１の内部は、アクセス定義データ２２１と、複数のコンテンツ２３１，２３２…からなるコンテンツリスト２２２で構成される。なお、コンテンツコンテナは、新規作成時にはコンテンツを含まない場合もある。

また、コンテンツ２３１は、メディアデータ２４１とメタデータ２５１から構成され、メディアデータ２４１はマルチメディアデータが格納され、メタデータ２５１にはメディアデータに関する情報が格納される。本実施例の場合、画像も、コメントも、１つのコンテンツとしてここに格納される。

図２３は、図２０に対するコンテンツコンテナの具体的なデータの格納構造を示すものであり、コンテナのタイトルを表すコンテナメタデータ２１０、アクセス定義データ２２１、コンテンツリスト２２２を格納する。

図２３に示されるように、アクセス定義データ２２１には、各ユーザ毎の投稿及び閲覧許可情報（アクセス権）が登録されている。本実施例においては、ＩＤがＵ００１は山田、Ｕ００２は佐藤、Ｕ００３は加藤、Ｕ００４は佐々木、Ｕ００５は木村、Ｕ００６は飯島としている。なお、アクセス権の設定については、投稿許可、閲覧許可を個別に設定することもできる。

また、例えば、コンテンツリスト２２２内の画像コンテンツ２３１には、メディアデータ２４１に画像データが格納され、メタデータ２５１には、投稿者ＩＤ（Identification）、タイトル、子コンテンツＩＤ（０個以上）が格納される。一方、画像コンテンツ２３１の投稿コメントであるコメントコンテンツ２３２には、メディアデータ２４２にコメント文が格納され、メタデータ２５２には、投稿者ＩＤ、親コンテンツＩＤが格納される。なお、２１１ａはコンテンツコンテナを識別するためのコンテンツコンテナＩＤ、２３１ａはコンテンツを識別するためのコンテンツＩＤである。

具体的な投稿作業について、一例として図２０に示した画像データ１１３を投稿するときの流れを解説する。ユーザ（山田）が投稿を行う際、まず、図２０の画像投稿ボタン１１１２を選択し、画像とタイトルを指定する。この結果、図２１において、クライアント１００はコンテンツ管理部２００の制御部２０１に対して、画像投稿コマンドを送信する。画像投稿コマンドの内容は、投稿対象コンテンツコンテナＩＤ、投稿者ＩＤ、タイトル、画像データから構成される。

画像投稿コマンドを受信した制御部２０１は、図２４に示すフローチャートに従って、投稿コマンド処理を実行する。まず、制御部２０１は投稿先のコンテンツコンテナをコンテンツデータ部２０２から検索する（ステップＳ１０１）。指定のコンテンツコンテナが有るかどうかを判断し（ステップＳ１０２）、指定のコンテナが見つかった場合、その内部のアクセス定義データ２２１を確認してアクセス許可判定を行う（ステップＳ１０３）。制御部２０１は、アクセス定義データ２２１を参照し、投稿者である山田（ＩＤ Ｕ００１）が、投稿を許可されていること（アクセス権）を確認し（ステップＳ１０４）、投稿コンテンツを作成し、データを格納し、コンテンツＩＤ(Ｃ００１)を生成してコンテンツリスト２２２に格納する（ステップＳ１０５）。コンテンツリスト２２２への格納処理が終了したら、投稿コマンド処理が終了した旨を画面に表示し（ステップＳ１０６）、投稿コマンド処理を終了する。

上述判断ステップＳ１０２及びステップＳ１０４において、投稿先コンテナが無い場合、又はユーザがアクセス権を持たない場合、それぞれエラーである旨のメッセージを表示し（ステップＳ１０７）、投稿コマンド処理を終了する。

なお、図２３では、コンテンツ２３１のメタデータ２５１に子コンテンツが２つ格納された表現となっているが、この段階では、コンテンツ２３１に子コンテンツはないので、この項目は存在しない。

次に、ユーザがコンテンツコンテナの内容を閲覧する場合の処理について、図２０、図２１、図２５を用いて説明する。ユーザが、クライアント１００（図２１参照）に対し入力操作を行いこのコンテンツコンテナ２１１を閲覧することを指示すると、クライアント１００は、制御部２０１に対して、閲覧コマンドを送信する。このときの閲覧コマンドの中身は、閲覧対象コンテンツコンテナＩＤ、要求者のユーザＩＤである。

制御部２０１は、閲覧コマンドを受信すると、図２５に示すフローチャートに従って、閲覧コマンド処理を実行する。まず、制御部２０１は閲覧対象となるコンテンツコンテナを検索し（ステップＳ１１１）、閲覧対象のコンテンツコンテナが有るかどうかを判断する（ステップＳ１１２）。閲覧対象コンテンツコンテナが見つかった場合、投稿時と同様に、その内部のアクセス定義データ２２１を確認してアクセス許可判定を行う（ステップＳ１１３）。制御部２０１は、アクセス定義データ２２１を参照し、要求者が閲覧を許可されていること（アクセス権）を確認し（ステップＳ１１４）、要求者が閲覧を許可（閲覧ＯＫ）されていれば、表示構成部３００に画面構成用コンテンツデータを送信して（ステップＳ１１５）、閲覧コマンド処理を終了する。

上述判断ステップＳ１１２及びステップＳ１１４において、閲覧先コンテナが無い場合、又はユーザがアクセス権を持たない場合、それぞれエラーである旨のメッセージを表示し（ステップＳ１１６）、閲覧コマンド処理を終了する。

表示構成部３００では、コンテンツデータを解析し、画面構成データを作成する。表示構成部３００は、コンテンツデータから、タイトル、投稿コンテンツ、コメントコンテンツを抽出し、図２０に示されるように配置する。また、１つの画像投稿ボタンと、投稿(画像データ)ごとのコメントボタン１１５をレイアウトする。画面構成データは、例えばＨＴＭＬなどを利用して構成する。

次に、ユーザが閲覧したコンテンツに対してコメントを行う場合について、図２０、図２１、図２６を用いて説明する。図２０において、画像データ表示１１３に対してユーザ（佐藤）がコメントをする場合について述べる。ユーザ（佐藤）がコメントボタン１１５を選択すると、クライアント１００（図２１参照）から、制御部２０１に対して、コメント投稿コマンドが発行される。コメント投稿コマンドの内容は、要求者ＩＤ、コンテンツコンテナＩＤ、コンテンツＩＤ、コメントテキスト、となっている。

制御部２０１は、コメント投稿コマンドを受信すると、図２６に示すフローチャートに従って、コメント投稿処理を実行する。まず、制御部２０１は、投稿時と同様に、コメント先コンテナの検索（ステップＳ１２１）を行い、コメント先コンテナが有るかどうかを判断する（ステップＳ１２２）。コメント先コンテナが見つかった場合、投稿時と同様に、その内部のアクセス定義データ２２１を確認してアクセス許可判定を行う（ステップＳ１２３）。制御部２０１は、アクセス定義データ２２１を参照し、要求者が閲覧を許可されていること（アクセス権）を確認し（ステップＳ１２４）、要求者が閲覧を許可（閲覧ＯＫ）されていれば、次に、コメント先となる、画像コンテンツを検索し（ステップＳ１２５）、コンテンツを格納する（ステップＳ１２６）。そして、コマンド実行処理が終了した旨のメッセージを表示し（ステップＳ１２７）、処理を終了する。

コンテンツ格納のステップＳ１２６では、図２３に示すように、コメントをコンテンツとして格納する。その際に、例えばコメントコンテンツ２３２のメタデータ２５２の親コンテンツの項目に、画像コンテンツのコンテンツＩＤ（Ｃ００１）を格納し、かつ、コメント先となるコンテンツ２３１のメタデータ２５１の子コンテンツの項目に、格納されたコメントコンテンツのＩＤ（Ｃ００２）を格納する。閲覧時において、表示構成部３００が画像コンテンツのメタデータを解析し、子コンテンツを、その画像のコメントとして抽出していて、画面構成データを作成する。

なお、上述判断ステップＳ１２２及びステップＳ１２４において、コメント先コンテナが無い場合、又はユーザがアクセス権を持たない場合、それぞれエラーである旨のメッセージを表示し（ステップＳ１２８）、コメントコマンド処理を終了する。

以上が、コンテンツ共有システムの基本的な説明である。

続いて、コンテンツ共有システムに適用した場合の具体的な流れについて、山本こずえがコンテンツ共有システム１３のコンテナＴ００３に、朝倉すみかが以前投稿した画像コンテンツに対しコメントデータＣ０１４を投稿した場合を例にとり説明する。

まず、コンテンツ共有システム監視部１４は、この一連の操作から、図９Ｃに示すような内容抽出履歴登録コマンドを内容抽出部３０に送信する。

内容抽出部３０では、メールや電話の場合と同様に、アドレス帳２１と発信者を照会して、送信者のユーザＩＤを特定し、ヘッダ情報中のコンテナＩＤとコミュニティリスト（図２８参照）から、宛先となるコミュニティＩＤを特定する。また、親コンテンツＩＤ投稿者を確認し、存在すればそのＩＤをアドレス帳と照合して、ユーザＩＤを特定し、宛先とする。

この場合、コメントの元となる画像コンテンツを投稿したユーザは、コンテンツ共有システムＩＤ「ｓｕｍｉｋａ」とあり、アドレス帳２１との照合により、ユーザＩＤはＵ００１となる。

内容抽出部３０は、履歴管理部４０に対して、図２９に示す履歴データを登録するコマンドを送信し、最終的に図２９に示す履歴データを、図１０に示す通信履歴に加える。

以降の流れは、電話及びメールを利用して説明した実施の形態の場合と同様であり、ユーザが概要を表示する際に、表示画面の総合（図１３参照）において、自分宛が１件加えられ、項目別において、Ｕ００２すなわち山本こずえからのメッセージ件数が１つ追加される。

本実施の形態によって、ユーザは、メーリングリストだけではなく、コンテンツ共有システムを含めた複数のコミュニケーションシステムにおける対話の概要把握を、電話及びメールを利用して説明した実施の形態の場合と同様に行うことができる。

同様に、コミュニティ、対話のやりとりを監視して、内容抽出履歴登録要求を行い、そこから宛先を判定する手段によって、新たなコミュニケーションシステムに対して本発明を適用することができる。

なお、親コンテンツがあった場合であっても、そのコメントの宛先を特定の個人としない場合も考えられ、コミュニティ内の文化によって切り替える仕組みも容易に提供することができる。

次に、図１に示すシステム構成において、ユーザに下記のようなトピック（話題）を知らせる場合について述べる。本例のトピックとして、特定発言者、まれな発言者、盛り上がり、返答、多数アクセス、重要度マッチ、沈黙の７タイプを設定しており、それぞれの定義について下記に示す。

・特定発言者：あるコミュニティで特定の人（幹事の人など）の発言があった場合
・まれな発言者：普段発言しない人が発言していること、音沙汰がない人からメッセージを受けた場合
・盛り上がり：特定のコミュニティにおいて、一定時間内に多数のメッセージがあった場合
・返答：自分のメッセージに対する返答である場合
・多数アクセス：特定の人から、自分に対して、一定時間内に多数のメッセージがあった場合
・重要度マッチ：メッセージ発信者の重要度と、受信ユーザとの優先度が共に高い時
・沈黙：特定のコミュニティにおいて、ある期間、発言が全く無い場合

本実施の形態では、図１に示すように、全体の構成において、概要抽出部５０にトピック集計部７０が設けられるとともに、ユーザ設定管理部２０にトピック判定設定データベース２３が設けられる。

概要抽出部５０に設けられるトピック集計部７０は、トピック判定部７１、トピック管理部７２及びトピック集計データベース７３から構成される。

また、ユーザ設定管理部２０のトピック判定設定データベース２３は、図３０で示されるようなデータが保存されており、本例では上記のトピックについてそれぞれ１つずつ、ユーザが定義した場合の内容となっている。設定項目としては一例として、トピックＩＤ、タイプ、条件、優先度、設定更新日時等がある。

図３０において、ＴＲ００１は、ＣＭ００２（図２８参照）、つまり家族のコミュニティにおいて、Ｕ００４（図２７参照）すなわち朝倉健二が発言した場合にトピック（特定発言者）と判定し、その際の優先度を８とする、というルールである。

この優先度は、複数のトピックが発生した場合にどれを優先して表示するかを決定する時に用いられ、１０を最大、１を最小としている。

またＴＲ００２は、ＣＭ００１において、あるsilentdays（沈黙設定期間）だけ、つまり過去６０日間発言しなかった人が発言した場合にトピック（まれな発言者）と判定し、その優先度を５とする、というルールである。

またＴＲ００３は、ＣＭ００３において、msgPerDayすなわち１日あたり１０通の割合でメッセージが発信された場合にトピック（盛り上がり）と判定し、優先度６とする、というルールである。

またＴＲ００４は、ＣＭ００２又はＣＭ００３において、自分のメッセージに対する返答である場合にトピック（返答）と判定し、優先度を５とする、というルールである。

またＴＲ００５は、自分に対する特定の人からのメッセージが１日３通の割合以上になった場合にトピック（多数アクセス）と判定し、優先度を９とする、というルールである。

またＴＲ００６は、Ｕ００２が、メッセージ優先度（Low、Mid、Highの３段階とする）がHighであるメッセージを発信（自分宛、コミュニティ宛に限らず）した場合にトピック（重要度マッチ）と判定し、優先度を９とする、というルールである。

またＴＲ００７は、ＣＭ００３において、２日間だれも発言しなかった場合にトピック（沈黙）として判定し、優先度を５とする、というルールである。

図３１に、トピック集計部７０によるトピック集計処理のフローチャートを示す。トピック集計部７０のトピック判定部７１は、通信履歴データベース４１内の通信履歴が更新されるたび、もしくはタイマーによって定期的に、トピック判定設定データに基づいて通信履歴を解析する。

まず、通信履歴更新又はタイマーによりトピック集計処理が開始されると、トピック集計部７１は、ユーザが指定したトピック判定設定があるかどうかを判断する（ステップＳ２０１）。トピック判定設定がない場合には処理を終了する。

ここで、トピック判定設定がある場合は、トピック判定設定データに基づいて履歴データからトピック条件を判定する（ステップＳ２０２）。そして、トピック条件にあてはまるかどうかを判断し（ステップＳ２０３）、トピック条件にあてはまる場合には、トピック管理部７２を通じて、トピック集計データとしてトピック集計データベース７３に記録していく（ステップＳ２０４）。ステップＳ２０３にて、トピック条件に当てはまらなかった場合には、ステップＳ２０１に戻り、次のトピック判定設定があるかどうかを確認し、あれば処理を継続する。

トピック判定部７１は、最後にトピック判定を行ったタイムスタンプを保持しており、このタイムスタンプを前回判定時刻と呼ぶ。

例えば、ステップＳ２０２のトピック条件判定処理において、特定者発言を確認するために、トピック判定部７１は、前回判定時刻以降の履歴を確認し、ユーザが指定した条件に当てはまった場合、トピック集計データに記録を追加する。

また、まれな発言者を確認するために、トピック判定部７１は、通信履歴を確認し、トピック判定部７１にて定義された対象者が発信者であるメッセージがきていることを確認すると、次に発言者ＩＤと最終発言時刻の組み合わせからなる発言者テーブルを確認する。本例では、発言者テーブルは通信履歴データベース４１に登録されている。このとき、最終発言時刻と、メッセージの受信時刻を比較し、トピック判定設定データ（図３０参照）にて指定された時間以上経っていることを確認すると、これを「まれな発言」としてトピック管理部７２にトピック集計データ７３への登録を依頼する。このときの発言者のユーザＩＤを発言者テーブルに加える。

一方で、あるユーザが指定した期間、発言が無かった場合には、そのユーザの発言記録を発言者テーブルから削除する。これにより受信したメッセージの送信者が発言テーブルにない場合も、「まれな発言」として判定する。また、ユーザ設定管理部２０は、ユーザが新たに設定した、もしくは設定を変更した時刻を設定更新時刻として、トピック判定設定データベース２３に保持している。メッセージ受信時刻が設定更新時刻からsilentdays内である場合は、未登録のユーザＩＤであっても、まれな発言者としての判定を行わない。

また、コミュニティの盛り上がりを判定するために、トピック判定部７１は、過去１日の間に発生したメッセージ量をカウントし、それがmsgPerDayの設定値よりも上回っている場合にトピック集計データにトピック登録を行う。

また、返答であることを確認するために、トピック判定部７１は、履歴データ（図１０参照）において、自分宛かつ、宛先のコミュニティＩＤが、トピック判定設定データと一致した場合、これをトピック集計データにトピックとして登録する。

また、多数アクセスを判定するために、トピック判定部７１は、履歴データ（図１０参照）において、自分宛の履歴を送信者毎に集計し、msgPerDayの設定値を超えたものを、トピック集計データにトピックとして記録する。

また、重要度マッチを判定するために、トピック判定部７１は、トピック判定設定データにおいて指定されたユーザＩＤの履歴を検索し、そのコンテンツＩＤからコンテンツのメタデータを獲得し、その値がユーザの設定した優先度（ＰＲＩＯ）以上である場合に、トピックとして記録する。また、効率化のため、履歴データに優先度の項目をもうけておき、履歴蓄積時に優先度を一緒に記録するという方法でもよい。

また、沈黙を判定するために、トピック判定部７１は、ユーザがトピック判定データにおいて指定したコミュ二ティＩＤ又はユーザＩＤに対して、履歴を確認し、silentdaysメッセージが無かった場合にトピックとして登録を行う。また、沈黙の判定のために、履歴データを確認するたびに、沈黙の判定の対象となっているコミュニティ、ユーザＩＤ毎に、最後に確認したタイムスタンプを記録しておくことによって、より効率的に判定を行うことができる。

以上の処理により、図３２に示すトピック集計データが作成される。集計項目として、例えば、トピックＩＤ、トピックのタイプ、注目ＩＤ、参照先タイプ、参照ＩＤ、優先度が登録される。参照ＩＤはトピックの判定の元となった参照先タイプのＩＤである。ユーザがそのトピックを選択したとき、例えばそれがメールの場合、そのメールＩＤから該当するメールが呼び出され、画面に表示される。

クライアント１が概要の表示を要求すると、先に述べた実施の形態と同様に、表示構成部９０を通じて、概要選択部８０に概要項目取得要求が送信される。概要選択部８０は予め用意されたレイアウトルールに従って、トピックの件数を表示構成部９０に渡し、最終的にクライアント１は図３３に示すようなトピック集計結果表示画面を表示する。

図３３のトピック集計結果表示画面にて、ユーザがトピック件数の表示部分を選択すると、クライアント１は表示構成部９０に対して、トピック一覧表示要求（１ページ目）を送信する。概要選択部８０は、クライアント１が表示可能な行数だけ、トピック判定部７１からトピックデータを優先度の高いものから取得し、表示構成部９０に送信する。そして、表示構成部９０は、予め用意されたフォーマットを用いて、概要選択部８０から受け取ったデータを表示する。なお、図３３において未読クリアボタンを押下することで、ユーザ、コミュニティ、トピックといったまとまりでクリアすることができる。

上記ユーザ操作により、クライアント１は、最終的に図３３に示すようなトピックの一覧を表示する。図３３において、ユーザは任意のトピックを選択すると、図３２のトピック集計データの参照ＩＤを基にして、ユーザが参照すべきコンテンツが表示される。

以上述べた本実施の形態によれば、ユーザは、単なる集計データだけではなく、コミュニティや相手の様子の変化、重要なトピックに気づきやすくなるという利点がある。

例えば、図３４に示すようなトピック一覧が表示された場合、ユーザ（朝倉すみか）は、普段注目していない山下猛から多数のメッセージが来ていることを簡単に確認することができる。また、朝倉家のコミュニティにおいて、父が発言していると同時に、最近多くのメッセージがやりとりされていることが分かる。これらの情報は、ユーザが注目する人やコミュニティを指定して集計するだけでは判定できない事柄である。それと同時に、ユーザが対話をどのように処理していくかを判断する材料として役立てることができる。

なお、まれな発言者の判定において、ユーザが設定を更新した時に、一度silentdaysまで過去にさかのぼり、指定されたコミュニティにおいて、silentdaysの期間発言した人のユーザＩＤをすべて発言者テーブルに加える、ということも容易に実現できる。この場合の方が、設定を変更しても、正確に、まれな発言者を抽出することができる。上記実施例の場合も、コミュニティができてからsilentdaysの間の期間については、正確に、まれな発言者を抽出することができる。

トピック集計データのテーブルに、未読、既読、確認済み、要返答などの項目（フラグ）を設け、これをユーザがクライアント１から、変更できるようにすることもできる。これによって、トピック集計データを利用した様々なアプリケーションを実現することができる。

次に、図１に示すシステム構成において、ユーザ嗜好データの内容を、コミュニケーション履歴を基に変更していく場合について述べる。この場合、図１に示されるように嗜好データ更新部４２が設けられる。

嗜好データ更新部４２は、履歴データが更新される度に、もしくはタイマーなどにより定期的に履歴データを参照する。そして、予め定められたルールにより、注目すべき人のユーザＩＤ、コミュニティＩＤと、その優先度を決定する。例えば、本例では予め定められたルールを下記のようなものをする。

＜ユーザ嗜好データの変更ルールの例＞
１．１日１回以上、かつ継続して３日間以上対話があった相手、コミュニティを優先度１として登録する。
２．条件１を満たしつつ、１日の対話回数が３回を超えた場合に、優先度を１つ上げる。
３．条件１を満たしつつ、対話のない日が２日続いた場合に、優先度を１つ下げる。
４．優先度が０になった段階でユーザ嗜好データから削除する。

このようなルールは、ユーザによって設定されてもよい。また、ルールが交換できるようになっていて、予め用意されたルールから、ユーザが好みのルールを選択する、という方法も適用することができる。

以上述べた実施の形態によれば、嗜好データ更新部４２が上記のルールに従って、ユーザ嗜好データを変更することによって、ユーザは、急に仲が良くなった対話相手や、入ったばかりのコミュニティに対して自然に状況を把握しやすくなる。また同時に、対話が減ってきた相手及びコミュニティは自動的に注目対象から外れる。さらに、一時的に対話を密にとった相手、コミュニティに対応することもできる。したがって、ユーザは、注意すべき対話相手、コミュニティを逐次設定する必要がなく、ユーザのコミュニケーション状況の変化に柔軟に対応することができる。

上述したこれらの実施の形態の例によって、ユーザは多くのユーザ、コミュニティと交換する大量のメッセージに対して、以下に述べる様々な観点から、メッセージやコミュニティの状況を把握しやすくなる。

例えば、一般的な着信件数及びメール未読件数表示に比べて、メッセージが自分宛なのか、コミュニティ宛であるのか、また、それが気にかけている人、コミュニティからのものなのかを、ユーザが簡単に把握することができ、大事なメッセージを優先して内容の確認し、返答をしていく、といったことを効率的に進めることができる。

また、ユーザが根本的に迷惑メールに惑わされず、大事なメッセージを確認しやすくすることができる。

また、ユーザが人やコミュニティの状況をつかみやすくすることができる。

また、ユーザが単なる集計データの閲覧だけではなく、コミュニティや相手の様子の変化、重要なトピックに気づきやすくすることができる。

そして、上述の効果は、１つのコミュニケーションシステムにとどまらず、ユーザが利用している数に合わせて複数のコミュニケーションシステムに同時に適用することができる。

また、動的に変化するメッセージの交換状況にも対応が可能であり、ユーザの設定を最小限にした上で、ユーザの振る舞いや、対話相手やコミュニティの動向の変化に合わせた概要の表示が可能である。

そして、ユーザはこれらの概要情報を基にして、今後の対話をどのように処理していくかを判断することができる。

なお、本発明は上述した実施の形態の例に限られるものではなく、本発明の要旨を逸脱することなくその他種々の構成を取り得ることは勿論である。

本発明の一実施の形態の例のシステム構成を示す図である。 本発明の一実施の形態の例のユーザリストを示す図である 本発明の一実施の形態の例のコミュニティリストを示す図である。 本発明の一実施の形態の例のユーザ嗜好データを示す図である。 本発明の一実施の形態の例の履歴データを示す図である。 待ち受け画面の一例を示す図である。 着信表示画面の一例を示す図である。 メール一覧表示画面の一例を示す図である。 本発明の一実施の形態の例の内容抽出履歴登録コマンドを示す図である。 本発明の一実施の形態の例の通信履歴を示す図である。 本発明の一実施の形態の例の個別集計処理示すフローチャートである。 本発明の一実施の形態の例の集計データの構造を示す図である。 本発明の一実施の形態の例の対話集計結果表示画面を示す図である。 本発明の一実施の形態の例の項目別リスト作成処理を示すフローチャートである。 本発明の一実施の形態の例の項目別リスト（Ｕ００２）を示す図である。 本発明の一実施の形態の例の項目別リスト表示画面（Ｕ００２）を示す図である。 本発明の一実施の形態の例の項目別リスト（ＣＭ００１）を示す図である。 本発明の一実施の形態の例の項目別リスト表示画面（ＣＭ００１）を示す図である。 コンテンツ共有システムの概要を説明するための図である。 コンテンツコンテナ表示画面の一例を示す図である。 図１９のコンテンツ管理部の構成を示す図である。 図１９のコンテンツデータ部のデータ構成を示す図である。 コンテンツコンテナのデータ格納構造の一例を示す図である。 投稿コマンド処理を示すフローチャートである。 閲覧コマンド処理を示すフローチャートである。 コメントコマンド処理を示すフローチャートである。 本発明の一実施の形態の例のユーザリストを示す図である。 本発明の一実施の形態の例のコミュニティリストを示す図である。 本発明の一実施の形態の例の履歴データを示す図である。 本発明の一実施の形態の例のトピック判定設定データを示す図ある。 本発明の一実施の形態の例のトピック集計処理を示すフローチャートである。 本発明の一実施の形態の例のトピック集計データを示す図である。 本発明の一実施の形態の例のトピック集計結果表示画面を示す図である。 本発明の一実施の形態の例のトピック一覧表示画面を示す図である。

符号の説明

１…クライアント、２…電話着信探知部、３…メール監視部、
１０…コミュニケーションサービス、１１…電話交換機、１２…メールサーバ、１３…コンテンツ共有システム、１４…コンテンツ共有システム監視部、
２０…ユーザ設定管理部、２１…アドレス帳、２２…ユーザ嗜好データベース、２３…トピック判定設定データベース、
３０…内容抽出部、３１…宛先判定部、３２…キーワード判定部、
４０…履歴管理部、４１…通信履歴、４２…嗜好データ更新部、
５０…概要抽出部、
６０…対話集計部、６１…集計管理部、６２…対話集計データベース、
７０…トピック集計部、７１…トピック判定部、７２…トピック管理部、７３…トピック集計データベース、
８０…概要選択部、
９０…表示構成部

Claims (9)

1. コミュニケーションサービスを利用して複数のユーザとマルチメディアデータをやりとりするコミュニケーション装置であって、
   ユーザリスト及び利用者が属するコミュニティリストからなるアドレスデータベースと、
   利用者のユーザ及びコミュニティに対する優先度順を示すユーザ嗜好データが記憶されたユーザ嗜好データベースと、
   前記コミュニケーションサービスを利用して受信したデータ内容を、前記アドレスデータベースを用い、所定の規則に従って抽出する内容抽出手段と、
   前記内容抽出手段で抽出された内容を通信履歴データとして通信履歴データベースに記録する履歴管理手段と、
   前記通信履歴データベースに記録された通信履歴データに対する所定の集計処理の結果をコミュニケーションの概要として抽出する概要抽出手段と、
   前記利用者の指示に応じて、前記概要抽出手段で抽出された前記コミュニケーションの概要から表示部の仕様に従い必要な情報を選択し前記表示部に送出する概要選択手段とを有し、
   前記概要抽出手段は、前記通信履歴データについて、前記アドレスデータベースと前記ユーザ嗜好データとを用いて、前記利用者が属するコミュニティのうち優先度の高いコミュニティ宛毎の受信件数の集計、優先度の高い発信元ユーザ毎の受信件数の集計、及び受信データの宛先が前記利用者宛かコミュニティ内の他人宛かを区別して行う受信件数の集計を組み合わせて実行する対話集計部を備える
   コミュニケーション装置。
2. 前記内容抽出手段は、受信したデータについて特定の文字列の有無を判定するキーワード判定部を備え、
   前記対話集計部が、前記キーワード判定部により判定された特定の文字列を持つデータ件数を集計する
   請求項１記載のコミュニケーション装置。
3. トピックとして、
   ・あるコミュニティで特定の人の発言があった場合である「特定発言者」
   ・普段発言しない人が発言していること、音沙汰がない人からメッセージを受けた場合である「まれな発言者」
   ・特定のコミュニティにおいて、一定時間内に多数のメッセージがあった場合である「盛り上がり」
   ・自分のメッセージに対する返答である場合である「返答」
   ・特定の人から、自分に対して、一定時間内に多数のメッセージがあった場合である「多数アクセス」
   ・メッセージ発信者の重要度と、受信ユーザとの優先度が共に高い時である「重要度マッチ」
   ・特定のコミュニティにおいて、ある期間、発言が全く無い場合である「沈黙」
   のうちの少なくとも１つが設定されており、前記トピックの判定の基準となるトピック判定設定データが登録されたトピック判定設定データベースを備えるとともに、
   前記概要抽出手段は、前記通信履歴データから前記トピック判定設定データに基づき所定のトピック件数を集計するトピック集計部を備える
   請求項１記載のコミュニケーション装置。
4. 前記通信履歴データを基にして、前記ユーザ嗜好データの優先度を更新する
   請求項１記載のコミュニケーション装置。
5. 前記コミュニケーションの概要である前記通信履歴データに関する複数の集計結果を、前記ユーザ嗜好データの優先度順に前記表示部の画面に表示する
   請求項１記載のコミュニケーション装置。
6. コミュニケーションサービスを利用して行われた複数のユーザとのコミュニケーションの概要を作成するコミュニケーション概要作成方法であって、
   利用者が前記コミュニケーションサービスを利用して受信したデータ内容を、ユーザリスト及び利用者が属するコミュニティリストからなるアドレスデータを用い、所定の規則に従って抽出するデータ内容抽出ステップと、
   前記抽出された内容を通信履歴データとして通信履歴データベースに記録する履歴記録ステップと、
   前記通信履歴データベースに記録された通信履歴データについて、前記アドレスデータと、利用者のユーザ及びコミュニティに対する優先度順を示すユーザ嗜好データとを用いて、前記利用者が属するコミュニティのうち優先度の高いコミュニティ宛毎の受信件数の集計、優先度の高い発信元ユーザ毎の受信件数の集計、及び受信データの宛先が前記利用者宛かコミュニティ内の他人宛かを区別して行う受信件数の集計を組み合わせて実行する集計ステップと、
   該集計結果を前記コミュニケーションの概要として抽出する概要抽出ステップと、
   前記利用者の指示に応じて、前記抽出された前記コミュニケーションの概要から表示部の仕様に従い必要な情報を選択し前記表示部に送出する表示ステップとを有する
   コミュニケーション概要作成方法。
7. トピックとして、
   ・あるコミュニティで特定の人の発言があった場合である「特定発言者」
   ・普段発言しない人が発言していること、音沙汰がない人からメッセージを受けた場合である「まれな発言者」
   ・特定のコミュニティにおいて、一定時間内に多数のメッセージがあった場合である「盛り上がり」
   ・自分のメッセージに対する返答である場合である「返答」
   ・特定の人から、自分に対して、一定時間内に多数のメッセージがあった場合である「多数アクセス」
   ・メッセージ発信者の重要度と、受信ユーザとの優先度が共に高い時である「重要度マッチ」
   ・特定のコミュニティにおいて、ある期間、発言が全く無い場合である「沈黙」
   のうちの少なくとも１つを設定し、前記トピックの判定の基準となるトピック判定設定データを登録するステップ
   をさらに有し、
   前記集計ステップにおいて、前記通信履歴データから前記トピック判定設定データに基づき所定のトピック件数を集計する
   請求項６記載のコミュニケーション概要作成方法。
8. 前記通信履歴データを基にして、前記ユーザ嗜好データの優先度を更新する
   請求項６記載のコミュニケーション概要作成方法。
9. 前記コミュニケーションの概要である前記通信履歴データに関する複数の集計結果を、前記ユーザ嗜好データの優先度順に前記表示部の画面に表示する
   請求項６記載のコミュニケーション概要作成方法。

Images