JP2005182154A - メッセージ処理システムおよびメッセージ処理方法 - Google Patents

Abstract

【課題】 メッセージを重要／不要による選別，内容による分類や、メッセージの重要度の変化を把握するための作業を、他の送受信者の作業を参照しながら、容易に正しく行えるようにし、メッセージを処理する労力を軽減する。
【解決手段】 ユーザが送受信した複数のメッセージを表示するためのメッセージ表示部１５５と、ユーザが送受信したメッセージに対して、当該メッセージの属性情報を任意の時点に、自動または手動で設定するためのメッセージ属性設定部１５３と、メッセージを送受信した複数の送受信者の各々がメッセージ属性設定部１５３を用いて当該メッセージに対して設定した属性情報を、当該送受信者の間で共有するためのメッセージ属性共有手段を具備しており、メッセージ表示部１５６は、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、ユーザ本人が指定した一つまたは複数の属性情報に基づいてメッセージの表示方法を変更する。
【選択図】 図１

Description

本発明は、複数のユーザが相互にメッセージを交換して議論や情報共有を行うための、電子メールや電子掲示板などのメッセージ処理システムおよびメッセージ処理方法に係わる。

近年、計算機とネットワークを利用して複数のユーザ間でメッセージを交換するための電子的なコミュニケーション手段が広く普及している。電子メールや電子掲示板などのコミュニケーション手段は、誰もが比較的容易に利用できるため、企業内の業務一般での利用をはじめ、電子的な商取引での契約や広告、家族や友人との会話や連絡、さらには、興味を同じくする不特定多数の人同士の情報交換といった、様々な目的に活用されている。その結果、例えば、電子メールを利用するユーザに対して送られてくるメッセージは大量になり、１日に数十件から数百件ものメッセージを受信する場合がある。インターネット上に設置された電子掲示板にも、多人数のユーザによって、日々大量のメッセージが登録されている。

これらのメッセージの中には、ユーザにとって重要な内容のもの、たとえば緊急の連絡事項などがある一方で、ユーザにとって全く不要な広告や、誹謗、中傷、コンピュータ・ウイルスなどの悪質な内容を含むものも少なくない。このように、大量で、かつ、目的や内容が各々異なるメッセージの中から、有用なもののみを選別したり、とくに重要なものを忘れないようにしたり、必要なものを必要なときに取り出す作業は、非常に繁雑で困難である。このため例えば、重要な連絡事項を見落としてしまったり、過去に行われた議論の経緯を失念したため内容の理解に手間取ったり、不要なメッセージを除去するのに時間を費されたり、返答を要するメッセージへの対処を忘れてしまうという不具合が、日常的に生じている。

ユーザが電子的メッセージを利用するための手段は、電子メールの場合は、一般にメーラーと呼ばれる、電子メールの送受信と閲覧、作成、管理等の機能を有したクライアント・プログラムである。近年普及しているウェブ・メールと呼ばれるシステムでは、ウェブ・ブラウザ、すなわち、ウェブ・サイト上に公開されたコンテンツを閲覧するためのプログラムが、メーラーとして用いられる。この場合のユーザ・インタフェースの実体は、上述のメーラーとほぼ同等の機能をＨＴＭＬ等の形式で記述したドキュメントである。一方、電子掲示板の場合も、ウェブ・ブラウザがユーザ・インタフェース手段として用いられる。これらの従来技術の手段が、上記の問題を解決するために具備する機能には、下記のものがある。

まず、メッセージを分類する機能としては、階層的な分類構造（フォルダと呼ばれることが多い）に、自動または手作業で、メッセージを振り分ける機能がある。メッセージを自動で分類する場合には、メッセージのヘッダ情報（送信者、受信者、表題、受信日時など）や、本文の内容が、ユーザが設定した条件を満足する場合に、所定のフォルダに振り分けるという処理が自動的に行われる。ユーザが削除したメッセージや、送信したメッセージも、各々「削除済み」「送信済み」などと名付けられた特別なフォルダに配置される場合がある。さらに、システムによっては、複数のユーザ間でフォルダを共有する機能を有するものもある。この共有機能は、上述のウェブ・メールのように複数のユーザのメッセージをメールサーバが一元管理するシステムや、ＩＭＡＰ等のメール送受信プロトコルに基づいた電子メールシステムで実現されている。

次に、重要なメッセージを見落とさないようにしたり、忘れずに記憶にとどめておくために用いられる機能としては、ユーザがメッセージを送信する際、これに重要度を表す属性情報を設定して、当該メッセージが重要であることを受信者に通知する機能がある。メッセージの受信者が自ら、重要度の属性を設定して、最初に送信者が設定した値と異なる値に変更することができるメーラーもある。このような属性情報を用いれば、ユーザは、メッセージがその重要度の高低に応じて強調して表示されるようにしたり、メッセージを重要な順に並び替えて表示されるようにするといったことが可能になる。

一方、このようなメッセージの重要度を表す特別な属性情報を使わなくても、メッセージの送信者が表題に手作業で「重要」「至急」といった文字列を記すことによって、送信者に注意を促すことも一般的によく行われている。メッセージの表題には、重要度や緊急性を示す文字列以外にも、例えば、当該メッセージが返信や転送であることを示す「Re:」や「Fwd:」、メッセージの意図や内容を表す「質問」「参考」「広告」、さらには、メーリングリスト名や連番を示す文字列などが、慣例として、あるいは、メッセージをやり取りするユーザ同士の同意のもとに、広く用いられている。ユーザは、これらの文字列をキーにしてメッセージを選別したり並び替えたりすることができる。また、上述のメッセージの分類や重要度判定の処理を、このような表題の記述に基づいて自動的に行う方法もある。

また、メッセージの受信者がメッセージを閲覧したかどうかの状況を表す属性情報を用いて、まだ閲覧していないメッセージを強調して表示する機能もある。受信者に対してメッセージが正しく送信されたかどうかを表す属性情報や、受信者がメッセージを閲覧した（既読）かしていない（未読）かを表す属性情報を、送信者に返送することによって、送信者が受信者の状況を把握できるようにしたメーラーも実現されている。この機能を用いれば、送信者は、例えば、正しく送信されなかったメッセージがあればこれを再送したり、未読状態の受信者に対してメッセージを閲覧するよう催促したりすることができる。

以上に説明した機能は、比較的多くのメーラーや電子掲示板によって実現され、すでに普及している機能であるが、大量のメッセージを処理するためにユーザが費す労力は依然として軽減されておらず、多くの課題が残されている。

まず、メッセージを分類したり、重要なメッセージをユーザが識別しやすくする機能に関しては、従来の多くのメーラーが採用している、階層型フォルダのＧＵＩを用いたメッセージ表示方法では、一覧性や操作性が悪いという問題があり、これを解決する発明として「電子メール整理検索装置（特許第２７６５５３６号）」（特許文献１）がある。この発明では、観点が異なる複数の分類、たとえば「重要」「会議」「資料」という三つの分類に対し、一つのメールが属すような場合に、フォルダを用いたＧＵＩでは表現や操作が難しいという点を改善し、１行の表示でメールの多重な属性情報をユーザに示す方法を提案している。また、同発明では、ユーザが入力した検索条件でメールを検索し、検索結果のメールを指定した分類に格納する機能も有している。この機能によって、ユーザがメールの分類や重要度の判定を手作業で行う労力が軽減される。

さらに「電子メール分類装置（特許第２８８５１６１号）」（特許文献２）の発明では、ユーザがある分類に手作業で追加したメール群と、当該分類から手作業で削除したメール群について、共通のパターンを各々抽出し、当該分類にメールを追加すべきかどうかを判断する肯定ルールと否定ルールとを、半自動的に生成または修正する手段を有する。この手段によって、分類ルールを作成する知識を持たないユーザでも簡単に自動分類が行えると、この発明では主張している。なお、特許文献１と特許文献２の発明では、メールが重要かどうかを判定する処理も、分類の処理に含めている。

しかしながら、このような自動分類機能は、一般的に言って、全てのメッセージが、誤りや矛盾がなく、正しく分類されることを保証するものではない。誤って分類されてしまったメールがあるかどうかを調べるには、ユーザは結局のところ、多くのメールの内容を逐一読んで確認する以外に方法はない。また、特許文献２の発明の場合には、今までユーザの意図通りに分類されていたメールや、ユーザが手作業で分類したメールが、分類ルールを修正したために、正しく分類されなくなるという可能性もある。さらに、電子メールなどのメッセージは、過去には重要であったが、そのメッセージの用件が済んだり情報が古くなったりしたために、重要でなくなる場合が多いし、逆に、時間の経過とともに重要度が増すメッセージもある。このような動的な変化に対応して、分類や重要度を最新の状態に保守する作業を、特許文献１や特許文献２の発明は支援するものではない。

一方、メッセージの重要度や内容、意図等を、送信者が手作業で、所定の属性情報や表題の文字列を用いて明示的に設定して受信者に送信する方法では、特別な技術を用いることなく、送信者の少ない手間によって、受信者側でのメッセージの分類を手助けしたり注意を喚起したりすることが効果的に行える場合がある。しかしながら、まず問題なのは、送信者にとっての重要度と受信者にとっての重要度が異なるという点である。悪意のある送信者が受信者の注意を喚起する目的で、不適切な属性情報や表題を設定する場合もある。多数のユーザに送信されるニュース配信などのように、ある一部のユーザ集団にとってのみ重要な情報を含んだメッセージもある。また、分類の観点が複数の送受信者間で異なる場合も多い。さらに、送信者がメッセージに設定する重要度や分類の属性情報は、通常、送信の時点で設定されるものであるため、上述のように、重要度や分類が時間の経過に伴って変化することがある。

これに対応するためには、ユーザ一人一人が手作業で、重要度や分類の設定を変更する必要があるが、その作業には労力がかかるし、メッセージの存在自体をユーザが失念してしまった場合には対処する方法がない。一方、上述の、フォルダを複数ユーザで共有する機能を用いれば、ユーザ全員が個別にメッセージの振り分けを行う必要がなく、一人のユーザが振り分けた結果を他のユーザが利用できるという利点があるが、ユーザ毎に分類や重要度についての考え方が異なる場合には対応できない。次に、メッセージに対するユーザの状況を把握するための機能については、通常のメーラーでは、主に受信や閲覧といった、限られた種類の状況しか把握できないという問題がある。

また、多くの場合、メッセージの送信者の側が、受信者の状況を一方的に確認することしかできないという問題がある。これに対して「電子メールシステムおよびメールサーバ（特開平１０−１０７８４０号）」（特許文献３）は、メールの修正や削除の操作を通知する機能を有する。すなわち、すでに送信済みのメールを修正したり削除する必要が生じた場合に、その変更を送信者が行えるようにするとともに、受信者に対しては、そのメールが既読か未読かの状況に応じて、メールの内容を置き換えたり、変更を通知する処理を行う。また、「電子メールシステム（特開２００１−２２６５９）」（特許文献４）は、メールの受信者側における受信、開封の操作に加え、転送、返信、再送、削除の操作を、送信者のみならず同報先の受信者全員で互いに確認できるようにしている。

しかしながら、特許文献３の発明は、メールの受信者の側は、メッセージを修正することができないため、例えばメッセージの内容に誤りがあることを受信者の一人が気付いた場合にも、これを修正して他の送受信者に通知するということはできない。

また、特許文献４の発明では、ユーザが操作状況を他の送受信者に知られたくない場合に対する考慮がなされていない点が問題である。例えば、同じ職場で業務上密接に関係する者同士や、家族や友人などの親密な者同士が、それぞれ共有し合うメッセージについての状況を互いに共有することには、あまり不都合はなく、コミュニケーションを円滑化する効果があるが、インターネット上の大規模なメーリングリストなど、互いに知らないユーザを多く含む送受信者間で操作状況を陽に共有することは、プライバシー上の問題がある。また、多数の送受信者の個々の操作状況そのものが確認できたとしてもあまり効果はなく、ユーザは、あるメッセージの内容や有用性に関する、自分と親密な人による信頼できる意見か、もしくは、多数の送受信者による全体的な意見の、いずれかを知るための材料として、操作状況を確認したい場合が多い。このような目的のために特許文献３や特許文献４の発明を用いることはできない。

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

本発明は、上記の問題を鑑み、大量に送受信したメッセージを処理するためのユーザの労力を軽減し、対処の遅れや失念などの不具合を防ぐことを課題とする。具体的には、大量のメッセージを重要なメッセージと不要なメッセージに選別したり、内容に応じてメッセージを分類したり、メッセージの重要度の変化を把握するための作業を、ユーザが、他の送受信者の作業を参照しながら、容易に正しく行えるようにする。

上記の目的を達成するために、この発明においては、ユーザが送受信した複数のメッセージを表示するためのメッセージ表示手段と、ユーザが送受信したメッセージに対して、当該メッセージの属性情報を任意の時点に、自動または手動で設定するためのメッセージ属性設定手段と、メッセージを送受信した複数の送受信者の各々が前記メッセージ属性設定手段を用いて当該メッセージに対して設定した属性情報を、当該送受信者の間で共有するためのメッセージ属性共有手段とを具備し、前記メッセージ表示手段は、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、ユーザ本人が指定した一つまたは複数の属性情報に基づいてメッセージの表示方法を変更することを特徴とするメッセージ処理システムを提供する。

各ユーザが全てのメッセージに対して自分で一から属性情報を設定しなくても、同じメッセージを共有する他の送受信者によって設定された属性情報を参照しながら、大量のメッセージを共同で選別したり、分類したり、重要なメッセージに対して注意を喚起し合うことが、容易に行えるようになる。

また、前記メッセージ属性共有手段は、ユーザが設定した属性情報を、他の送受信者と共有するか否かの制御または前記他の送受信者と共有する度合の制御を、前記他の送受信者が所定の条件を満たすか否かに基づいて行う手段を有することを特徴とするメッセージ処理システムを提供する。

例えば、既知のユーザとは共有し、未知のユーザとは共有しないようにすることができる。更に、例えば、自分と密接な関係にあるユーザとは実名で共有し、あまり関係のないユーザとは匿名で共有するといった、共有の度合いの制御も適切に行える。従って、プライバシー上の問題が解決される。

また、前記メッセージ属性設定手段は、メッセージのヘッダ情報または本文の内容に基づいて自動的に当該メッセージに属性情報を設定する手段を含むことを特徴とするメッセージ処理システムを提供する。

従来より、表題や送受信者、本文などの情報に基づいて、メッセージの重要度の判定や分類の処理を、自動的に行うシステムが考案されているが、本発明では、個々のユーザが自分の目的に応じてこのような自動処理を行った結果の属性情報をも、前記のメッセージ属性共有手段を用いて共有できるようにする。

また、前記メッセージ属性設定手段は、メッセージに対してユーザが行った、送信、閲覧、分類、削除、訂正、返信、転送、再送、添付、検索の内、少なくとも１つの操作に基づいて、自動的に当該メッセージに属性情報を設定する手段を含むことを特徴とするメッセージ処理システムを提供する。

ユーザがメッセージに対して行った操作は、ユーザがそのメッセージをどう処理したかの状況を表すのみならず、メッセージの有用性や、要確認、要返信といった性質を判断する材料になるので、これを属性情報として共有できるようにする。

また、前記メッセージ属性設定手段は、メッセージと返信、転送、再送などの関係がある他のメッセージに対して、当該メッセージの属性情報を設定する手段を含むことを特徴とするメッセージ処理システムを提供する。

例えば、あるメッセージとその返信のメッセージは、同じ分類に属する場合が多いし、ある重要なメッセージの転送として送信されたメッセージも重要な場合がある。メッセージの属性情報を、このようなメッセージ間の関係に従って継承させることにより、全てのメッセージに対してユーザが属性情報を逐一設定しなくてもよいようにする。

また、前記メッセージ表示手段にて、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、一つまたは複数の属性情報に基づいて、メッセージの表示方法を変更する処理において、当該複数の属性情報が設定された回数、または、設定を行った送受信者の人数の、いずれかまたは両方に基づいて、メッセージの表示方法を変更することを特徴とするメッセージ処理システムを提供する。

この処理により、ユーザは、メッセージに数多く設定された属性情報や、大部分の送受信者によって設定された属性情報に着目した方法、例えば端的には、多数意見を優先するかたちで、メッセージを表示することができる。

また、前記メッセージ表示手段にて、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、一つまたは複数の属性情報に基づいて、メッセージの表示方法を変更する処理において、当該複数の属性情報の各々を設定した送受信者の特徴、または、設定を行った手段に基づいて、メッセージの表示方法を変更することを特徴とするメッセージ処理システムを提供する。

ユーザは、複数の送受信者が各々設定した属性情報のうち、例えば、メッセージの送信者が自ら設定した属性情報を利用したい場合もあるし、自分自身あるいは自分と密接な関係にあるユーザが設定した属性情報を優先して利用したい場合もある。また、メッセージに対する属性情報の設定は、送受信者の手作業によって行われることもあるし、前述のような複数の方式の自動手段のうちのいずれかを用いて行われることもあるが、例えばユーザは、手作業による属性情報のみを利用したい場合もあるし、ある方式の自動手段の結果のみに注目したい場合もある。このような様々な場合に対応して、属性情報を設定したユーザの特徴や、設定手段の種類、手作業と自動処理の区別などを反映したかたちで、メッセージの表示を行えるようにする。

また、前記メッセージ表示手段にて、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、一つまたは複数の属性情報に基づいて、メッセージの表示方法を変更する処理において、当該複数の属性情報の各々が設定された日時の特徴に基づいて、メッセージの表示方法を変更することを特徴とするメッセージ処理システムを提供する。

メッセージの重要度や内容の有用性は、時間の経過に伴って動的に変化するものであるし、例えばメッセージに誤りがあった場合の訂正などは、全ての送受信者に早急に通知されることが望ましい。このような問題に対処するため、ユーザに対して、属性情報の時間的な変化を反映した方法でメッセージの表示を行えるようにする。

この発明によれば、各ユーザが全てのメッセージに対して自分で一から属性情報を設定しなくても、大量のメッセージを重要なメッセージと不要なメッセージに選別したり、内容に応じてメッセージを分類したり、メッセージの重要度の変化を把握するための作業を、ユーザが、他の送受信者の作業を参照しながら、容易に正しく行うことができる。この結果、大量に送受信したメッセージを処理するためのユーザの労力を軽減し、対処の遅れや失念などの不具合を防ぐことができる。

以下、図面を用いて本発明の実施の形態を説明する。
図１は、本発明の一実施形態であるメッセージ処理システムの構成を表す図である。
本実施形態はサーバ部１００と複数のクライアント部１５０が計算機ネットワーク１を介して接続された形で構成されており、サーバ部１００は従来技術のメールシステムやウェブ・メールシステム、電子掲示板システム等のサーバ・プログラムに相当する手段である。一方のクライアント部１５０は、複数のユーザが各々の計算機端末にて個別に利用するメーラー等のクライアント・プログラムに相当する。ハードウェア的には、ＣＰＵ，ＲＯＭ，ＲＡＭ等を備えた計算機（コンピュータ）がプログラムを実行することにより、サーバ・プログラム及びクライアント・プログラムの機能が実現される。更に、クライアント・プログラムを実行する計算機は、ディスプレイ装置、キーボード、ポインティング・デバイス等の、従来のユーザ・インタフェース装置を必要に応じて具備するものとする。

サーバ部１００の送受信部１０４は、メッセージすなわち電子メールや電子掲示板の記事等のデータを、複数のクライアント部１５０と送受信するための手段であり、後述するメッセージの属性情報もこの手段にて送受信する。

サーバ部１００のメッセージ記憶部１０１は、クライアント部１５０から送信されたメッセージを記憶する手段である。
メッセージ属性共有部１０３は、メッセージの属性情報を複数のクライアントのユーザが共有するための手段である。その属性情報のデータは、メッセージ属性記憶部１０２にて記憶される。

一方、クライアント部１５０は、メッセージやその属性情報のデータをサーバ部１００との間で送受信するための送受信部１５１を持つ。
サーバ部１００から受信したメッセージはクライアント部１５０のメッセージ記憶部１５４に記憶される。このメッセージは主には、当該クライアント部１５０を利用するユーザに対して送信された電子メール等のメッセージである。

メッセージ表示部１５５は、メッセージ記憶部１５４に記憶されたメッセージを表示するための手段である。
メッセージ操作部１５６は、メッセージの作成や削除などの操作を行うための手段である。
メッセージ属性設定部１５３は、メッセージに対して、ユーザが手作業で、あるいは、自動処理によって、メッセージの属性情報を設定するための手段である。その属性情報のデータは、クライアント部１５０のメッセージ属性記憶部１５２に記憶される。

クライアント部１５０のユーザが利用するメッセージの属性情報には、当該クライアント部１５０のメッセージ属性設定部１５３によって設定された属性情報以外にも、他のユーザが設定した、サーバ部１００のメッセージ属性記憶部１０２に記憶されている属性情報がある。このような他のユーザが設定した属性情報のうち、クライアント部１５０のユーザにとって必要かつ共有可能なものが、前記メッセージ属性共有部１０３および送受信部１０４を介してクライアント部１５０と送受信され、クライアント部１５０のメッセージ属性記憶部１５２にも記録される。

メッセージ表示部１５５は、メッセージ属性記憶部１５２に記憶されている属性情報に基づいた方法で、メッセージの表示を行う。
また、メッセージに対して属性情報を自動的に設定する処理は、メッセージ記憶部１５４に記憶されているメッセージのヘッダーや本文の情報を参照して、メッセージ属性設定部１５３にて行われる。さらに、ユーザからの指示に応じてメッセージ操作部１５６が行ったメッセージの操作に基づいて、メッセージへの属性の設定が同じくメッセージ属性設定部１５３にて行われる。

以上が本実施形態の基本的な構成であるが、以下に記すような変形も可能である。
図１のサーバ部１００は、送受信部１０４とメッセージ記憶部１０１で実現されるメッセージの送受信の処理と、送受信部１０４とメッセージ属性共有部１０３およびメッセージ属性記憶部１０２によって実現されるメッセージの属性情報の共有の処理の、両方の処理を行うように構成されているが、これらの二つの処理を別々の計算機で行うようにサーバ部１００の機能を分割して構成してもよい。この場合には、メッセージの送受信の処理は、従来技術のメールサーバ等で実現することも可能である。

同様に、クライアント部１５０においても、従来のメーラー等で実現されているメッセージの送受信および表示、操作の処理、すなわち、図１のクライアント部１５０の送受信部１５１、メッセージ記憶部１５４、メッセージ表示部１５５、およびメッセージ操作部１５６にて実現される処理は、従来のメーラー等のプログラムをそのまま用いて実現し、メッセージの属性情報を設定し利用する手段のみを、付加的なプログラムとして実現するという方法も可能である。

次に、メッセージやその属性情報の記憶管理の方法については、サーバ部１００にて全てのユーザのメッセージを永続的に一元管理し、クライアント部１５０では個々のユーザが利用するメッセージのみを一時的に記憶するという、従来のＩＭＡＰに基づくメールサーバやウェブ・メール、電子掲示板システム等に類似した構成で実現してもよい。この場合、メッセージの属性情報についても、クライアント部１５０の側では必要なもののみ一時的に記憶するようにすればよい。

逆に、従来のＰＯＰに基づくメールサーバに相当するような構成、すなわち、サーバ部１００では、クライアント部１５０にまだ送信していないメッセージのみを記憶し、クライアント部１５０へ送信済みのメッセージは、サーバ部１００のメッセージ記憶部１０１からは削除するという構成も可能である。さらに、サーバ部１００を複数設けて、サーバ間でメッセージの属性情報を共有するように構成してもよい。

次に図２は、本実施形態のメッセージ処理システムが処理の対象とするメッセージの例を示す図である。図２に示したメッセージの形式は、従来の電子メールと全く同じである。なお、電子掲示版システムにおけるメッセージは、従来より標準的な形式は特に定められておらず、個々のシステムに固有の形式であるが、概ねは、電子メールのメッセージと同等もしくはより単純な形式であり、送受信等の処理も単純である。したがって、本発明は電子メールおよび電子掲示版の両方の形態で実現可能であるが、本実施形態では電子メールの形態を中心に説明する。

図２は、メッセージの一例を示す図である。図２の符号２０１，２１１は、メッセージのヘッダー部分であり、図２の符号２０２，２１２は、メッセージの本文である。

ヘッダー部分には、メッセージの送信日「Date」、送信者のメールアドレス「From」や受信者のメールアドレス「To」「CC」などの情報が所定のフィールドに記されている。ヘッダー情報のうち、「Message-ID」（図２の符号２０３，２１４）は、当該メッセージのユニークな識別子であるメッセージＩＤである。図２（ｂ）のメッセージは、図２（ａ）のメッセージに対する返信メッセージの例であるが、この場合には、「References」というフィールド２１３に、返信元メッセージのメッセージＩＤが記述されている。図２（ｂ）に示すメッセージは図２（ａ）のメッセージに対する返信メッセージであり、メッセージのヘッダー情報２１１の「References」フィールド２１３には、返信元メッセージのメッセージＩＤであるｍ５が記述されている。

後述するように、メッセージの属性情報は、メッセージの送信者が、メッセージの送信時に、メッセージに付与してサーバに送信することも可能であるが、この場合には、メッセージのヘッダーの、例えば「X-Property」２０４というフィールドに属性名と属性値を記述する。この図２（ａ）に示す例では、“X-Property：分類＝開発”と記述されており、図２（ａ）のメッセージは属性名が「分類」であり、属性値が「開発」という属性情報が付与されている。

なお、例えば電子メールの重要度に関しては、従来の電子メール・プログラムでは一般的あるいは慣例的に、ヘッダーの「Priority」もしくは「X-Priority」なるフィールドに重要度を表す数値を指定して送受信するということが行われている。したがって、このような既存の電子メールのプログラムとの互換性を保つために、本発明の属性情報についても、当該属性に相当する、従来から一般的に用いられているフィールドが存在する場合には、そのフィールドを用いてヘッダーに記述してもよい。

前述の通り、ＰＯＰ等の電子メール送受信プロトコルに基づく構成においては、サーバは、クライアントにまだ送信していないメッセージのみを記憶管理すればよく、クライアントへ送信済みのメッセージのデータを全て記憶管理する必要はない。したがって、この場合の実施形態では、クライアントへ未送信のメッセージについては、図２に例示した、ヘッダー情報と本文からなる全てのデータを記憶する。

一方、既にクライアントへ送信済みのメッセージについては、メッセージのヘッダのうち、後述する属性情報の共有の処理において必要となるフィールドのデータのみを、サーバ部のメッセージ記憶部（図１の符号１０１）にて記憶管理する。具体的には、メッセージのＩＤと送受信者のデータを図３に示すようなかたちで記憶する。

図３の符号３０１と３０２は各々図２（ａ），（ｂ）のメッセージに対応している。図に示したとおり、メッセージの日時、メッセージＩＤ、返信元メッセージＩＤ、送信者、受信者（To、CC）の情報が記憶される。なお、送信者と受信者の情報は、本実施形態ではメールアドレスを用いて記述し識別する。

図４は、サーバ部１００のメッセージ属性記憶部（図１の符号１０２）に記憶される、メッセージの属性情報の例を示す図である。
図４に示した通り、属性情報のデータは、当該属性がメッセージに対して設定された「日時」と、メッセージの「メッセージＩＤ」、および、設定を行った「ユーザ」のメールアドレスを持つ。また、当該属性の内容である「属性名」と「属性値」を持つ。さらに、当該属性がどのような方法で設定されたかを示す「設定方法」の項目を持つ。本実施形態の場合、「設定方法」の項目は、当該属性がユーザの手作業によって設定されたことを意味する「手動」と、自動処理によって設定されたことを意味する「自動」との、区別を表すために設けられているが、これ以外にも、たとえば自動処理の種類を表すデータを記述してもよい。

次に、「共有レベル」の項目は、当該属性情報が、どのようなユーザに対して、どのように共有すべきかを示す項目である。
本実施形態の場合には、４段階の共有レベルが設けられている。
「共有レベル１」は、属性を設定したユーザと同一のドメインに属し、かつ、当該ユーザと親しい関係にあるユーザを意味するレベルである。なお、属性を設定したユーザ自身もこのレベルに属するとする。「共有レベル２」は属性を設定したユーザと親しい関係にあるユーザを意味するレベル、「共有レベル３」は属性を設定したユーザと同一のドメインに属するユーザを意味するレベル、「共有レベル４」は、上記の共有レベル１から３以外の全てのユーザを意味するレベルである。

これらの４つの共有レベルに対し、どのような共有を行うかの値としては、共有しないことを意味する「０」、匿名で共有することを意味する「１」、実名で共有することを意味する「２」が設けられている。これらの値は全て、当該属性情報を設定したユーザが指定する。匿名で共有するよう指定された場合には、そのレベルのユーザに対しては、属性情報の「ユーザ」の内容は開示しないようにして、当該属性を設定したユーザが誰であるかを特定できないようにする。一方、実名で共有するよう指定された場合、そのレベルのユーザは、当該属性を設定したユーザを特定して、そのメールアドレスなどを知ることができるようにする。

例えば図４の属性情報４０５は、共有レベル１の値として２が設定されているので、ユーザ「okuda@aaa.co.jp」と同じドメインに属すユーザ（メールアドレスのドメインが「aaa.co.jp」であるようなユーザ）で、かつ、「okuda@aaa.co.jp」と親しい関係にあるユーザに対しては、実名でこの属性情報を共有できると指定されている。他方、共有レベル２，３，４の値として１が設定されているので、ドメインが同じだが親しい関係にないユーザや、親しい関係にあるがドメインが異なるユーザとは、匿名で共有し、それ以外をユーザとは共有しない。

あるユーザが他のあるユーザと親しい関係にあるかどうかの判断する方法は、本実施形態のシステムでは、ユーザ同士のメッセージの送受信の頻度によって行う。すなわち例えば、ユーザｕとユーザｖについて、ｕがｖに送信したメッセージの集合をＭuv、ｖがｕに送信したメッセージの集合をＭvuとすると、ユーザｕとｖの親しさを表すｋuvの値は、例えば次の式（１）により求めることができる。

式（１）により求められるｋuvの値は、uとvが送信し合うメールの件数が多いほど、大きな値となり、逆にＭuvまたはＭvuが空集合だと０になる。したがってこのｋuvの値は、ユーザuとvの親しさを表す値となる。ここで、Ｍuv等のメッセージ集合は、図３に例示したデータの、送信者と受信者の項を用いて求めることができる（|Ｍuv|等はメッセージ集合の要素数、すなわちメッセージの件数を表す。）。

式（１）は、ユーザ同士の親しさを求めるための比較的簡単な計算方法であるが、単純にメッセージの件数を用いるのではなく、メッセージの種類に応じた重みを加味してもよい。例えば、ユーザuがユーザvに送信したメッセージに対し、vがuに返信した場合には、その返信メッセージの重みを通常の重みより重くすることが考えられる。また、メッセージの送受信の日時に基づいた重みを加味することにより、ユーザ同士の現時点における親しさをより正確に求めることもできる。このようにして、メッセージの送受信の頻度によってユーザ間の親しさを数値として求めることができるが、頻度以外の情報、例えば、ユーザが所属するドメインや、実際の組織の近さなどを加味してもよい。あるユーザに対して、このようにして求めた親しさを表す数値が、ある閾値より大きいようなユーザの集合を、上記の「共有レベル１」および「共有レベル２」であるとする。

図５は、クライアント部のメッセージ属性記憶部（図１の符号１５２）に記憶される、メッセージの属性情報の例を示す図であり、例としてメールアドレス「okuda@aaa.co.jp」を持つユーザが利用するクライアントが記憶する属性情報を示している。その内容は図４に示したものと類似しているが、クライアント側では、当該クライアント部を利用するユーザ自身が設定した属性情報と、他のユーザが設定した属性情報のうち当該ユーザと共有可能な属性情報だけが記憶される。例えば図４の属性情報４０４は、ユーザ「okuda@aaa.co.jp」とは共有すべきでないと指定されている（ユーザ「okuda@aaa.co.jp」とユーザ「tanaka@aaa.co.jp」と親しい関係にない場合）ため、図５に示した属性情報の中には、この属性情報４０４に相当する属性情報は存在しない。

また例えば、図５の属性情報５１，５２，５３，５６，５８は、各々、図４の属性情報４１，４２，４３，４６，４８に相当するが、ユーザ「okuda@aaa.co.jp」に対しては匿名で共有するように指定されている属性情報であるため、その「ユーザ」の項すなわち当該属性情報を設定されたユーザは匿名化されている。ただし、匿名化されても対象メッセージにおけるユーザのユニーク性を保つように、「m2anonymous1」などの形で記述されるようにしており、これは後述するように、属性情報を設定したユーザの人数を計算する際に用いられる。

図５の属性情報５５，５７，５９は、各々、図４の属性情報４５，４７，４９に対応するが、これらの属性情報は、ユーザ「okuda@aaa.co.jp」自身によって設定されたものである。これら属性情報５５，５７，５９以外の属性情報は、ユーザ「okuda@aaa.co.jp」以外のユーザによって設定されたものであり、図１に示したサーバ部１００のメッセージ属性記憶部１０２からクライアント部１５０に対して送信された属性情報である。なお、これらの属性情報の、共有レベルに関わる情報は、ユーザ「okuda@aaa.co.jp」が該当しないレベルについては不要であるため、クライアント部１５０では記憶されていない。

本発明の目的は、後に図１０から図１３までの画面例で示すように、日々大量に送信されるメッセージについて、その重要度や緊急度、意図や内容上の分類、処理や操作の状況などの情報が、ユーザ自身だけでなく他のユーザに関する情報も含めて、一目で把握できるようなかたちで、メッセージを表示することにある。この表示の処理は、図５に示したような、適切な制御のもとに共有されたメッセージの属性情報に基づいて行われる。

図６から図９は、メッセージの属性情報をサーバとクライアントの間でやり取りする処理の流れを示している。
以下、図６から図９のフローチャートを用いて、メッセージの属性情報をサーバ部１００とクライアント部１５０との間でやり取りする処理の流れについて詳細に説明する。

図６は、クライアント部がメッセージの属性情報をサーバ部に送信する処理の流れを示す図である。ここでクライアント部１５０がサーバ部１００に送信するのは、クライアント部１５０を利用するユーザ自身が設定した属性情報である。属性情報の送信は、ユーザが属性を設定するごとに一つずつ送信するという方法で行ってもよいが、この方法は通信の効率が良くないし、サーバ部１００とクライアント部１５０は常時接続しているとは限らない。したがって、例えば、ある一定期間中に設定された属性情報を複数、所定の時間間隔で、あるいはメッセージを送信するタイミングに合わせて、サーバ部１００に一括して送信する方法が考えられる。

図６（ａ）は、メッセージの送信とは関係なく、属性情報のみを、主にはある時間間隔ごとにサーバ部１００に送信する場合の送受信部１５１における処理であり、図６（ｂ）は、メッセージを送信する際、当該メッセージに対して設定された属性情報を、メッセージのヘッダー情報の中に記述する形でサーバ部１００に送信する方法である。

図６（ａ）では、まず、Ｓ６０１にて、ユーザが設定した属性情報について、すでに送信済みの属性情報を除き、新たに設定された属性情報の集合Ｐを求める。次に、集合Ｐの要素である各々の属性情報ｐについて繰り返して（Ｓ６０２）、Ｓ６０３とＳ６０４の処理を実行する。Ｓ６０３にて、先に説明した共有レベルとその値に基づいて、属性情報が他のユーザと共有可能かどうかを調べる。図４や図５で示した例では、共有レベルの１から４のユーザ全てに共有しないよう指定されている場合（図４と図５の記述方法によれば、共有レベルの１から４の値が全て０の場合）には、共有すべきないので、集合Ｐからｐを除く（Ｓ６０４）。こうして求めた集合Ｐが空集合（Φ）でなければ（Ｓ６０５）、集合Ｐをサーバ部１００に送信する。

図６（ｂ）の処理は、図６（ａ）の処理とほぼ同じであるが、Ｓ６１１にて、送信の対象とする属性情報の集合Ｐを、送信メッセージｍに対して設定された属性情報とする点と、Ｓ６１６およびＳ６１７にて、集合Ｐをｍのヘッダーに記述した形で、メッセージｍと共に送信する点が、図６（ａ）の処理と異なる。

一方、サーバ部１００の側は、クライアント部１５０から送られる属性情報を記録する処理を行う。その処理の流れを示したのが図７である。Ｓ７０１は、図６（ａ）で説明したクライアント部１５０側の送信処理に対応しており、クライアント部１５０から属性情報の集合Ｐを受信し、これをメッセージ属性記憶部１０２に記憶する（Ｓ７０５）。一方、Ｓ７０２からＳ７０４の処理は、図６（ｂ）で説明した送信処理に対応しており、クライアント部１５０からメッセージｍを受信した時、ｍのヘッダーから（図２の符号２０４に例示したような形の）属性情報の集合Ｐを抽出し（Ｓ７０３）、抽出できた場合に（Ｓ７０４）、これをメッセージ属性記憶部１０２に記憶する（Ｓ７０５）。

図８は、クライアント部１５０のメッセージ表示部１５５にてメッセージを表示する際に、必要とする属性情報をサーバ部１００から受信し、これに基づいた方法で個々のメッセージを表示する処理の流れを示す図である。

まずＳ８０１にて、表示の対象とするメッセージの集合Ｍについて、集合Ｍのいずれかのメッセージに対して設定された属性情報のうち、すでにクライアント部１５０がメッセージ属性記憶部１５２にて記憶している属性情報の集合を検索し、これを集合Ｐとする。集合Ｐは主に、当該クライアント部を利用するユーザ自身が設定した属性情報と、以前にサーバ部１００から取得した属性情報からなる。

次にＳ８０２では、サーバ部１００が記憶している、集合Ｍのいずれかのメッセージに対して設定された属性情報の集合Ｐｓを取得する。ただしこの処理は、メッセージを表示するたびに毎回行う必要はなく、以前に所得した属性情報が十分新しい情報であるなら、この処理を省略することも可能である。あるいは例えば、メッセージをサーバから受信する際に、最新の属性情報も併せてサーバから取得するようにしてもよい。

Ｓ８０３では、こうして取得した集合Ｐｓを集合Ｐに追加して、これを集合Ｍの表示に用いる属性情報の集合とする。以降の処理は集合Ｍの要素である個々のメッセージを表示する処理であり、集合Ｍの要素ｍについて繰り返して（Ｓ８０４）実行される。

Ｓ８０５では、集合Ｐから、ｍに関する属性情報の集合Ｐｍを検索し、Ｓ８０６では、集合Ｐｍに基づいた方法でｍを表示する。具体的には、属性情報Ｐｍをメッセージｍに関連づけて表示したり、属性値にしたがってｍを選別したり、並び変えたり、強調して表示するといった処理を行う。その例は図１０以降に説明する。集合Ｐｍが空集合であるならば、ユーザの指定に応じて、所定の属性情報を持つメッセージのみを表示するようにしたり、逆に、所定の属性情報を持つメッセージは表示しないようにするという処理も可能である。

一方、図９は、サーバ部１００がクライアント部１５０の要求に応じて属性情報を送信する処理の流れを示した図であり、クライアント側の図８のＳ８０２の処理に対応して行われる処理を示す。

まずＳ９０１で、クライアント部１５０からの属性情報の取得要求があった場合、上述の通り、クライアント側は、表示の対象とするメッセージの集合Ｍについての属性情報を送信するようサーバ部１００に要求するので、サーバ側では、Ｓ９０２で、集合Ｍのいずれかのメッセージに設定された属性情報の集合Ｐを、サーバ部１００のメッセージ属性記憶部１０２で検索する。次に、次に、集合Ｐの要素である属性情報ｐについて繰り返して（Ｓ９０３）、ｐがクライアントのユーザｕと共有可能かどうかを調べる（Ｓ９０４）。

前記の図４で説明したように、ユーザｕが、属性情報を設定したユーザｖに対して、どの共有レベルに属するユーザであるかを、ユーザｕとユーザｖのドメインや、前述の方法で計算した親しさの度合に基づいて決定する。共有が可能であるなら（Ｓ９０５）、図５で説明したように、その共有レベルに対応する形（本実施形態の場合は匿名または実名）に、ｐを加工する（Ｓ９０５）。一方、共有可能でないなら、ｐを集合Ｐから除く（Ｓ９０６）。

こうして、集合Ｍに関して共有可能な属性集合Ｐを求めて、Ｓ９０６ではこの集合Ｐを、要求したクライアントに送信する。このようにして、図４で示した、サーバ部１００が記憶する属性情報のうち、図５で示したような、クライアント部１５０が必要かつ利用可能な属性情報が送信される。

図１０は、図８と図９で説明した処理によってクライアント部１５０が得た属性情報に基づき、メッセージの一覧を表示した画面の例を示す図である。図１０の符号１００１の部分には、メッセージが１行につき１件ずつ表示されている。符号１００２の列には、各メッセージに対して複数のユーザが設定した属性情報が表示されており、ユーザはこの部分を見ることにより、個々のメッセージの重要度や緊急度、状況（すなわち、メッセージの用件に自分または他のユーザが対処したかどうかの情報）、ユーザがメッセージに対して行った操作（送信，閲覧，削除，訂正，返信，転送，再送，添付，検索等が行われたことを示す情報）、分類などを把握することができる。表示される属性情報は、前述の通り、ユーザ自身だけでなく、他のユーザが設定した属性情報も含んでいるため、例えばあるユーザが重要だと考えるメッセージに対して、他のユーザの注意を喚起するようにできるし、また例えば、あるユーザが行ったメッセージの分類の結果を、他のユーザが利用することもできる。

メッセージに設定された属性の個数や種類が多い場合には、表示が繁雑になる恐れがあるが、これを解決するため、図１０の符号１００３に示したように、属性情報のうちユーザが指定したもののみを表示するための、チェックボックス等のＧＵＩ手段が設けられている。例えば図１１は、属性情報のうち、メッセージの「重要度」１１０１、「状況」１１０２、および「分類」１１０３を表す属性を選択して表示した画面の例を示している。これらの属性のうち特に「重要度」１１０１について関心のあるユーザは、この属性を（図に示したようにマウス等の指示手段で）選択することによって、重要度の属性が設定されたメッセージのみを選別したり、重要度の高い順に並び替えて表示することができる。このユーザにより選択された「重要度」１１０１は、太字により強調され示される。

同様に図１２は、「分類」１２０１を表す属性情報が設定されているメッセージのみを一覧した画面例を示す図であり、同じ分類に属するメッセージごとにまとまって形で、メッセージの一覧が表示されている。

前述のように、属性情報には、ユーザ自身が設定したものもあるし、ユーザと親しい他のユーザが設定したもの、ユーザと同じドメインに属する他のユーザが設定したもの、などもある。また別の観点では、メッセージの送信者が設定したもの、受信者が設定したものという区別がある。さらに、ユーザが手作業で設定した属性情報と、自動処理によって設定された属性情報という区別もある。ユーザは、このように設定者や設定方法が異なる属性情報のうち、所定の属性情報を持つメッセージのみを選別して表示したい場合がある。

図１２の（ａ）は、「分類」１２０１を表す属性情報を、全て表示した画面例である。図１２の１２０２は、属性情報の表示と非表示を切り替えるためにユーザが用いるメニューであり、例えばマウスの右ボタンで「分類」１２０１の部分をクリックした時にユーザに提示されるものである。このメニュー１２０２に示されているように、図１２（ａ）の画面は、「分類」１２０１を表す属性について、「全てのユーザ」１２０３が、「手動設定」１２０４または「自動設定」１２０５で設定した属性情報を全て表示した画面である。なお、自動で設定された属性情報は、図１２の符号１２０６のように斜体で示している。

図１２（ａ）に対し、図１２（ｂ）は、「ドメイン内の親しいユーザ」１２１３が「手動設定」１２１４で設定した属性情報を持つメッセージに限って表示を行った画面である。このように、属性情報の設定者や設定方法に関する特徴を用いて、メッセージを選別して表示する機能を提供することにより、ユーザは、所望のメッセージを探したり、関心のあるメッセージのみに注目したりすることができるし、さらには、自分と親密な関係にあるユーザ、例えば共同に仕事を行っているユーザが設定した属性情報のみに注目するといったことも可能になる。

属性情報は、一つのメッセージに対し、複数のユーザによって、任意の時点に、複数件設定されるものであるが、ユーザは、どの属性情報が、誰に、いつごろ、何件設定されたかを知りたい場合がある。目的によっては、属性情報を設定したユーザを特定したい場合もあるし、件数の全体的な比率や、増減の傾向を知りたい場合もある。また例えば、重要度が変化して高くなったメッセージを見落とすことなく確認したい場合もある。このような種々の要求を満たす機能を本発明は提供する。

図１３はその画面例であり、属性情報の付加情報として、当該属性が設定された件数と、設定を行ったユーザの人数とを、表示する例を示している。
図１３（ａ）は、ユーザが着目する「操作」１３０１の属性について、その「件数」１３０２と「ユーザ数」１３０３とを表示するよう指示された場合の、表示画面の例である。この場合の属性情報の表示１３０４では、属性とともにその件数とユーザ数が表示されている。ユーザは、この情報を利用して、例えば多くのユーザに返信されたメッセージを重要であると判断したり、逆に、大部分のユーザに削除されたメッセージは不要であると判断することができる。例えば、図１３（ａ）の１行目に表示されている表題が“職場環境アンケートのお願い”のメッセージに対しては、当該メッセージへの返信メッセージが１２件存在し、９人が返信をしており、また、削除が１０件存在し、１０人が削除をしていることをユーザが知ることができる。

一方、図１３（ｂ）は、同じく「操作」の属性について、その「件数」１３１１とその「増減傾向」１３１２を表示するよう指示された場合の、表示結果の画面である。この場合の属性情報の表示１３１３では、属性とともにその件数と最近の（例えば最近３日間などの）件数の増減が、矢印によって示されている。上向きの矢印は件数が著しく増加（所定の件数よりも増加）した場合、下向きの矢印は件数が著しく減少（所定の件数よりも減少）した場合に表示され、ユーザの注意を喚起する働きをする。

例えば、図１３（ｂ）の１行目に表示されている表題が“職場環境アンケートのお願い”のメッセージに対しては、当該メッセージへの返信メッセージが１２件存在し、削除が１０件存在していることをユーザが知ることができる。また、同メッセージに対して、例えば最近３日間の返信メッセージが１１件，削除が９件あったとする。すると図３（ｂ）の矢印により、最近３日間の返信メッセージが所定の件数（例えば１０件）を超えて存在し、最近３日間の削除が所定の件数（例えば８件）を超えて存在していることをユーザが知ることができる。

図１４は、ユーザが着目する「状況」１４０１の属性、すなわち、メッセージに記された用件が対処されたかどうかを表す属性について、当該属性情報を設定した「ユーザ名」を表示した例である。図１４のメニューによる指定１４０２に従い、「状況」を表す属性、すなわち「対処中」や「対処済」等の属性情報に対し、表示１４０３に示したように、対処を行っているユーザのユーザ名として、「ikeda」や「okuda」が表示されている。属性情報が実名で共有されている場合には、このように属性情報を設定したユーザを、他のユーザが特定するための情報を、サーバを介して共有することができる。

一方、属性情報が匿名で共有されている場合にも、図１３に示したように、ユーザは属性情報の設定件数やユーザ数を知ることができる。
なお、以上に述べた属性情報の設定件数やユーザ数、増減傾向の表示方法は上記の例だけに限らず、例えば設定件数やユーザ数の割合をパーセントで表示したり、件数の多い属性を強調して表示するようにしてもよい。

さらには、所定の属性情報の件数やユーザ数が多い（もしくは少ない）メッセージのみを選別して表示するようにしたり、増減が著しい属性情報を持つメッセージのみを選別して表示するようにしたり、所定のユーザによって設定された属性情報を持つメッセージのみを選別して表示するといった機能も、本発明によれば容易に実現可能である。

図１５は、ユーザがメッセージに属性情報を設定するための手段の画面例を示した図である。ユーザが選択したメッセージ（例えば図１５の符号１５０１）に対して、属性情報の設定や削除を行うためのＧＵＩ手段が提供される。例えば図１５に示した例では、メッセージの属性の項目をマウスの右ボタンでクリックしたときに、メニュー１５１０のようなかたちでユーザに提示される。属性情報の設定は、メニュー１５１０の「属性の設定」からさらに階層的に展開されるメニュー１５３０や１５４０を用いて、簡単に行えるようになっている。メニュー１５４０は、メニュー１５３０の中の特に「分類」１５３２を表す属性を設定するために用いられるメニューである。ユーザはメニュー１５３０の中から、例えば「重要度」の「高」１５３１、メニュー１５４０の中から「分類」の「開発」１５４１および「分類」の「会議」１５４２、などを選択することにより、メッセージに属性を設定することができる。

一方、属性情報の共有方法を指定する場合には、ユーザは、図１５に示したメニュー１５２０を用い、上述の複数の共有レベルの各々に対して、どのような共有を行うかを容易に指定できるようになっている。ユーザがこのようにして設定した属性情報は、前述のように、図１のクライアント部１５０のメッセージ属性記憶部１５２に記憶される。

なお、メッセージの属性情報には、図１５に示したような設定手段を用いて明示的に設定しなくても、ユーザがメッセージに対して行う操作と連動して設定されるものがある。本実施形態の場合、図１０や図１３などで説明した「操作」の属性がこれに相当する。ユーザの指示により、図１のクライアント部１５０のメッセージ操作部１５６が行ったメッセージの削除や返信、転送などの操作に応じて、その操作の種類を表す属性情報が操作対象のメッセージに設定される。メッセージの閲覧や削除、返信などのような通常よく行われる操作の他にも、例えば、ユーザがメッセージの内容を訂正したり、メッセージを検索機能などを用いて検索した結果を利用したときに、「操作」の属性が設定されるようにすることも可能である。

メッセージに対して設定する属性情報には、例えば重要度や緊急度、操作などのように、適用分野に依らず（例えば家庭でも職場でも）一般的に利用されるものもあるが、その一方で、分類などを表す属性は、ユーザが必要に応じて自由に定義できることが好ましい。また、図１２、図１３、図１４で説明した、属性情報の選択的な表示方法や、属性の付加情報の表示方法は、ユーザが通常利用する表示方法が属性毎に定まっている場合には、デフォルトの表示方法として定義できることが好ましい。さらに、属性情報の共有方法も、図１５のメニュー１５２０で示したような手段で属性情報ごとに逐一指定しなくても、毎に適切な共有方法が予め想定できるならば、これをデフォルトの共有方法として定義できることが好ましい。

図１６、図１７、図１８は、このような目的でユーザが用いる、属性の定義および変更のための画面を表す図である。
図１６は、分類を表す属性を定義する例であり、属性名「分類」１６０１に対して属性名「試験」１６０２を、親分類「開発」１６０３の子分類として新しく定義する場合の画面例を示す。属性に定義できる内容としては、共有方法１６０４、表示方法１６０５、および自動設定の方法１６０６がある。共有方法の指定１６０４では、図４や図１５のメニュー１５２０で説明したように、共有レベルの１から４に相当するユーザに対して、当該属性情報をどのように共有するかを指定する。

なお、この指定は属性「試験」１６０２についてのデフォルトの指定であり、図１５で説明したように、メッセージ毎に個別の共有方法を指定したい場合はメニュー１５２０の手段を用いて指定することができる。

表示方法の指定１６０５は、図１２、図１３、図１４に説明した種々の表示方法について、そのデフォルトの方法を予め指定するものである。なお、特に分類を表す属性については、これら共有方法および表示方法の指定は、親分類の指定を継承してもよい。

自動設定１６０６の指定では、メッセージに対して、当該属性情報を自動的に設定したい場合に、その条件や設定方法を指定する。図１６の１６０７は、返信元メッセージの属性を継承するよう指定しているが、これは、返信元メッセージの属性「分類」の値が「試験」である場合には、その返信メッセージの属性「分類」の値を自動的に、返信元と同じ値の「試験」に設定することを意味する。

一方、図１７は、別の「分類」１７０１として、親分類「Ｑ＆Ａ」１７０３の子分類「質問」１７０２を定義する例を示しているが、この場合の自動設定の条件１７０４では、メッセージの表題に「質問」という表現を含むか、または、本文に「教えてください」を含む場合に、当該メッセージの属性「分類」の値を自動的に「質問」に設定するように指定されている。図１のクライアント部１５０のメッセージ属性設定部１５３は、このような自動設定の指定を参照して、メッセージ記憶部１５４に記憶されたメッセージの内容に基づき、メッセージに所定の属性情報を自動的に設定する処理を行う。

次に図１８は、新しい属性「投票」１８０１を定義する場合の画面例を示す。この属性はその名称が意味する通り、メッセージの内容に対する受信者の賛否を集計するために利用される属性の例であり、属性値として「賛成」「反対」「保留」１８０２のいずれかの値を取るように定義されている。この属性はその用途に適した方法で表示されるようにも定義されており、すなわち、ユーザが「手動」１８０３で設定した属性値を、「ユーザ数」１８０４とともに表示するよう定義されている。

図１９は、この新しく定義した属性「投票」を利用する画面の例を示している。定義された属性は、まず、１９０１に示すようにその属性情報の表示方法を指定するための手段１９０１がユーザに提供され、当該属性が設定されたメッセージ１９０２について、その属性情報が表示されるようになる。

さらにユーザには、当該属性の属性値を設定するための手段であるメニュー１９０３も提供され、このメニュー１９０３から自分の意図するものを選択することにより、属性値の設定すなわち投票を、簡単に行うことができるようになる。この属性の例が示すように、本発明では、複数のユーザ間で、電子メール等のメッセージを介して、各自の意図を伝達し合うための属性を、自由に定義して簡単に利用することができる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明のメッセージ処理システムの一実施形態の構成を示す図。 メッセージの例を示す図。 サーバ部で記憶されるメッセージのヘッダー情報の例を示す図。 サーバ部で記憶されるメッセージの属性情報を示す図。 クライアント部で記憶されるメッセージの属性情報を示す図。 クライアント部がメッセージの属性情報をサーバ部に送信する処理の流れを示すフローチャート。 サーバ部がクライアント部から送信されたメッセージの属性情報を受信して記憶する処理の流れを示すフローチャート。 クライアント部がサーバ部から取得したメッセージの属性情報を用いてメッセージを表示する処理の流れを示すフローチャート。 サーバ部がクライアント部からの要求を受けてメッセージの属性情報を送信する処理の流れを示すフローチャート。 メッセージの一覧とその属性情報を表示する画面の例を示す図。 メッセージの一覧とその属性情報を表示する画面の例を示す図。 メッセージの一覧とその属性情報を表示する画面において、属性情報の設定者および設定方法に基づいて表示を変更する例を示す図。 メッセージの一覧とその属性情報を表示する画面において、属性情報の付加情報の表示を変更する例を示す図。 メッセージの一覧とその属性情報を表示する画面において、属性情報の付加情報の表示を変更する例を示す図。 メッセージの属性情報およびその共有方法を設定する画面の例を示す図。 属性情報の定義および変更を行う画面の例を示す図。 属性情報の定義および変更を行う画面の例を示す図。 属性情報の定義および変更を行う画面の例を示す図。 メッセージの属性情報を設定する画面の例を示す図。

符号の説明

１…計算機ネットワーク、１００…サーバ部、１０１…サーバ部のメッセージ記憶部、１０２…サーバ部のメッセージ属性記憶部、１０３…サーバ部のメッセージ属性共有部、１０４…サーバ部の送受信部、１５０…クライアント部、１５１…クライアント部の送受信部、１５２…クライアント部のメッセージ属性記憶部、１５３…クライアント部のメッセージ属性設定部、１５４…クライアント部のメッセージ記憶部、１５５…クライアント部のメッセージ表示部、１５６…クライアント部のメッセージ操作部。

Claims (9)

1. ユーザが送受信した複数のメッセージを表示するためのメッセージ表示手段と、
   ユーザが送受信したメッセージに対して、当該メッセージの属性情報を任意の時点に、自動または手動で設定するためのメッセージ属性設定手段と、
   メッセージを送受信した複数の送受信者の各々が前記メッセージ属性設定手段を用いて当該メッセージに対して設定した属性情報を、当該送受信者の間で共有するためのメッセージ属性共有手段とを具備し、
   前記メッセージ表示手段は、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、ユーザ本人が指定した一つまたは複数の属性情報に基づいてメッセージの表示方法を変更することを特徴とするメッセージ処理システム。
2. 前記メッセージ属性共有手段は、ユーザが設定した属性情報を、他の送受信者と共有するか否かの制御または前記他の送受信者と共有する度合の制御を、前記他の送受信者が所定の条件を満たすか否かに基づいて行う手段を有することを特徴とする請求項１記載のメッセージ処理システム。
3. 前記メッセージ属性設定手段は、メッセージのヘッダ情報または本文の内容に基づいて自動的に当該メッセージに属性情報を設定する手段を含むことを特徴とする請求項１または２記載のメッセージ処理システム。
4. 前記メッセージ属性設定手段は、メッセージに対してユーザが行った、送信、閲覧、分類、削除、訂正、返信、転送、再送、添付、検索の内、少なくとも１つの操作に基づいて、自動的に当該メッセージに属性情報を設定する手段を含むことを特徴とする請求項１乃至３のいずれか１項に記載のメッセージ処理システム。
5. 前記メッセージ属性設定手段は、メッセージと返信、転送、再送などの関係がある他のメッセージに対して、当該メッセージの属性情報を設定する手段を含むことを特徴とする請求項１乃至４のいずれか１項に記載のメッセージ処理システム。
6. 前記メッセージ表示手段にて、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、一つまたは複数の属性情報に基づいて、メッセージの表示方法を変更する処理において、
   当該複数の属性情報が設定された回数、または、設定を行った送受信者の人数の、いずれかまたは両方に基づいて、メッセージの表示方法を変更することを特徴とする請求項１乃至５のいずれか１項に記載のメッセージ処理システム。
7. 前記メッセージ表示手段にて、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、一つまたは複数の属性情報に基づいて、メッセージの表示方法を変更する処理において、
   当該複数の属性情報の各々を設定した送受信者の特徴、または、設定を行った手段に基づいて、メッセージの表示方法を変更することを特徴とする請求項１乃至６のいずれか１項に記載のメッセージ処理システム。
8. 前記メッセージ表示手段にて、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、一つまたは複数の属性情報に基づいて、メッセージの表示方法を変更する処理において、
   当該複数の属性情報の各々が設定された日時の特徴に基づいて、メッセージの表示方法を変更することを特徴とする請求項１乃至７のいずれか１項に記載のメッセージ処理システム。
9. メッセージ表示手段により、ユーザが送受信した複数のメッセージを表示し、
   メッセージ属性設定手段により、ユーザが送受信したメッセージに対して、当該メッセージの属性情報を任意の時点に、自動または手動で設定し、
   メッセージ属性共有手段により、メッセージを送受信した複数の送受信者の各々が前記メッセージ属性設定手段を用いて当該メッセージに対して設定した属性情報を、当該送受信者の間で共有し、
   前記メッセージ表示手段は、ユーザ本人を含む複数の送受信者が設定した複数の属性情報のうち、ユーザ本人が指定した一つまたは複数の属性情報に基づいてメッセージの表示方法を変更することを特徴とするメッセージ処理方法。

Images