JP2003233564A - コミュニケーション相手リスト表示方法、コミュニケーション相手リスト表示装置及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 コミュニケーション相手の選択効率化と手間
の軽減を図る。 【解決手段】 任意の相手との間で通信インフラを介し
て行われるコミュニケーションの際に、当該相手を選択
するために用いられるアドレス帳１７（コミュニケーシ
ョン相手リスト）を表示し、前記アドレス帳１７は、登
録済みのコミュニケーション相手と登録者との親しさの
度合いを表す評価値でソートされた順番で、登録済みの
コミュニケーション相手をリスト表示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コミュニケーショ
ン相手リスト表示方法、コミュニケーション相手リスト
表示装置及び記録媒体に関し、特に、メールやチャット
等のコミュニケーション機能を搭載したパーソナルコン
ピュータや携帯情報端末又は携帯電話端末等に適用可能
なコミュニケーション相手リスト表示方法、コミュニケ
ーション相手リスト表示装置及び記録媒体に関する。

【０００２】

【従来の技術】近年、インターネット等の通信インフラ
の整備ならびにパーソナルコンピュータや携帯情報端末
などの通信端末の普及により、通信によるコミニケーシ
ョンが盛んに行われるようになってきた。例えば、電子
メールはその代表格であり、これによれば、指定したコ
ミュニケーション相手（以下単に「相手」ということも
ある。）に所要の通信文を送信することができ、相手は
自分の都合のよいときに当該通信文をダウンロードして
読むことができるという、郵便や電話といった既存のコ
ミニケーション手段にない利便性が得られるうえ、さら
に現在では、携帯電話やＰＨＳ（Personal Handy Phone
System）などからも電子メールを送信したり受信した
りできるようになったことから、老若男女を問わず、様
々な状況下で通信によるコミニケーションが日常的に行
われるようになってきた。

【０００３】電子メールの送受信手順を概説すると、ま
ず、送信者は、電子メールソフトを起動してメール作成
画面をオープンする。メール作成画面には、相手先のア
ドレスやメールの表題等を入力するヘッダ部と、メール
本文を入力するボディ部とが設けられており、送信者
は、所要のヘッダ情報とボディ情報を入力した後、送信
処理を実行してネット上のメールサーバにアップロード
する。メールサーバは、受信者からメール受信要求があ
ったとき、当該受信者宛ての着信メールが保管されてい
るか否かを調べ、保管されている場合に、そのメールデ
ータを当該受信者の端末に送信（端末側から見るとダウ
ンロード）する。受信者は、電子メールソフトのメール
閲覧画面をオープンして受信内容を確認した後、電子メ
ールソフトの終了処理、または所望により、メールの返
信処理を実行する。

【０００４】ここで、電子メールの宛先情報（アドレ
ス）はネット上で唯一無二（ユニーク）となっており、
例えば、インターネットメール（いわゆる“Ｅ−ＭＡＩ
Ｌ”）の場合、ＲＦＣ１０３４およびＲＦＣ１０３５の
定めに従った特定の文字列（任意文字列＋＠＋メールサ
ーバのドメイン名またはエイリアス名）で表されるが、
相手先の名前そのものではないため、覚えにくいことも
事実である。

【０００５】このため、コミュニケーション相手が増え
るにつれて、アドレスの入力ミスや間違った相手に送信
したりするという事故が散発することから、何らかのア
ドレス管理ツールが必要不可欠となる。

【０００６】このようなアドレス管理ツールの代表は、
いわゆるアドレス帳と呼ばれるものである。アドレス帳
は、少なくとも相手先の名前（またはニックネーム）と
アドレスをリストで管理するもので、メール送信時にリ
ストを表示してそのなかから選択するだけで、簡単に宛
先指定を行うことができるというものである。アドレス
帳への登録時にタイプミスをしない限り、また、リスト
選択を正確に行う限り、上述の事故を回避することがで
きる。

【０００７】ところで、アドレス帳に登録されたコミュ
ニケーション相手の数は、人によって一概には言えない
が、例えば、広範囲な交友関係や仕事関係を持つ人の場
合、数十人はおろか数百人に及ぶこともあり得る。この
ような場合、リストから所望のコミュニケーション相手
を探し出すのは一苦労であり、何らかの工夫が必要であ
る。かかる工夫として、従来から、（１）読み仮名等で
ソートしてリスト表示するもの、（２）利用頻度や利用
日付の順にソートしてリスト表示するものなどが知られ
ており、また、（３）カテゴリー分類やフラグ識別を行
ってリスト表示するものなども知られている。

【０００８】

【発明が解決しようとする課題】しかしながら、上記公
知の工夫にあっては、以下の不都合があった。 （１）読み仮名等でソートしてリスト表示するもの 名前の他に読み仮名を入力する必要があり、コミュニケ
ーション相手の登録に手間がかかるという不都合があ
る。一般に名前は漢字を使用することが多く、漢字その
ものをソート項目に指定できないからである。

【０００９】（２）利用頻度や利用日付の順にソートし
てリスト表示するもの 例えば、コミュニケーション相手ごとの利用回数をカウ
ントしてそれを利用頻度値とし、その利用頻度値をソー
ト項目とするものがある。これによれば、降順ソートを
行うことにより、利用頻度の最も多いコミュニケーショ
ン相手をリストの最上位に位置させることができる。し
かしながら、この方法は、古くからのコミュニケーショ
ン相手の利用頻度値が常に高い値を維持するから、その
値を上回らない限り、新しいコミュニケーション相手を
リストの上位に位置させることができないという不都合
がある。また、利用日付の順にリスト表示するものは、
常に最新のコミュニケーション相手（または直近のメー
ル送信に利用したコミュニケーション相手）をリストの
上位に位置させることができる点で好ましいものの、上
位付近の入れ替わりが激しく、また、必ずしも今後利用
する可能性の高いコミュニケーション相手が上位に位置
するとは限らないという不都合がある。

【００１０】（３）カテゴリー分類やフラグ識別を行っ
てリスト表示するもの カテゴリー分類は、例えば、「友人」や「仕事関係」な
どの区分ごとにコミュニケーション相手を分類する方法
である。また、フラグ識別は、例えば、よく利用する相
手先にフラグをセットして区別するものである。いずれ
の方法も適切なカテゴリー区分及びフラグ設定を行うこ
とにより、コミュニケーション相手の分類管理を行うこ
とができ、検索効率の改善を期待することができる。し
かし、カテゴリーやフラグの設定作業や分類作業が別途
に必要であるから、相手先の登録に相応の手間がかかる
という不都合がある。

【００１１】したがって、本発明が解決しようとする課
題は、コミュニケーション相手の選択効率化と手間の軽
減を図るために、登録済みコミュニケーション相手と当
該コミュニケーション相手を登録した登録者との間にお
ける親しさの度合いを表すとみなされる評価値を、コミ
ュニケーション相手のソート項目に利用できるように
し、以て、便宜的にその評価値のことを親密度と呼ぶこ
とにすれば、親密度の順にソートされた登録済みコミュ
ニケーション相手のリスト表から親しい間柄のコミュニ
ケーション相手を選択することができるようにしたコミ
ュニケーション相手リスト表示方法、コミュニケーショ
ン相手リスト表示装置及び記録媒体を提供することにあ
る。

【００１２】

【課題を解決するための手段】本発明は、任意の相手と
の間で通信インフラを介して行われるコミュニケーショ
ンの際に、当該相手を選択するために用いられるコミュ
ニケーション相手リストを表示し、該コミュニケーショ
ン相手リストは、所定の項目でソートされた順番で登録
済みのコミュニケーション相手をリスト表示するもので
あり、且つ、前記所定の項目は、登録済みのコミュニケ
ーション相手と登録者との親しさの度合いを表す評価値
であることを特徴とする。

【作用】本発明では、登録済みコミュニケーション相手
と当該コミュニケーション相手を登録した登録者との間
における親しさの度合いを表すとみなされる評価値を用
いて、コミュニケーション相手のリストがソートされ
る。

【００１３】

【発明の実施の形態】以下、本発明の実施の形態を、電
子メールシステムへの適用を例にして、図面を参照しな
がら説明する。なお、以下の説明における様々な細部の
特定ないし実例および数値や文字列その他の記号の例示
は、本発明の思想を明瞭にするための、あくまでも参考
であって、それらのすべてまたは一部によって本発明の
思想が限定されないことは明らかである。また、周知の
手法、周知の手順、周知のアーキテクチャおよび周知の
回路構成等（以下「周知事項」）についてはその細部に
わたる説明を避けるが、これも説明を簡潔にするためで
あって、これら周知事項のすべてまたは一部を意図的に
排除するものではない。かかる周知事項は本発明の出願
時点で当業者の知り得るところであるので、以下の説明
に当然含まれている。

【００１４】まず、電子メールシステムを構築するうえ
で、一般的にはメールクライアントとメールサーバの二
つのマシンが必要になる。クライアントマシンは電子メ
ールの利用者によって操作されるいわゆるメール端末で
あり、メールの作成や閲覧及び送受信に供される。一
方、サーバマシンは各利用者からアップロードされた電
子メールを保管し、利用者からの要求に応じて当該利用
者宛ての着信メールを配信するサービスを提供するもの
で、例えば、インターネット（ＴＣＰ／ＩＰ）プロトコ
ル対応の電子メールシステムの場合は、送信サーバ（Ｓ
ＭＴＰサーバともいう。）と受信サーバ（ＰＯＰサーバ
ともいう。）とによって構成される。

【００１５】送信サーバ及び受信サーバは、少なくとも
ドメインごとに設けられており、各サーバにはＤＮＳ
（Domain Name System）サーバによって“名前解決”さ
れる一意のホスト名が割り当てられている。例えば、ド
メイン“ａａａ．ｃｏ．ｊｐ”に設けられた送信サーバ
には“ｍａｉｌ．ａａａ．ｃｏ．ｊｐ”というホスト名
を割り当てることができると共に、同受信サーバには
“ｐｏｐ．ａａａ．ｃｏ．ｊｐ”というホスト名を割り
当てることができる。

【００１６】図１（ａ）は、ドメイン“ａａａ．ｃｏ．
ｊｐ”における電子メールシステムの概念図である。図
において、代表的に示す２台のクライアントマシン１、
２には、それぞれメールクライアントソフト（ＭＵＡ：
Mail User Agent）がインストールされている。また、
送信サーバ３と受信サーバ４には、それぞれメールサー
バソフト（ＭＴＡ：Mail Transport Agent）がインスト
ールされている。一般に送信サーバ３は、ＭＴＡのＳＭ
ＴＰ（Simple Mail Transfer Protocol）サービスを提
供し、受信サーバ４はＭＴＡのＰＯＰ（Post Office Pr
otocol）サービスを提供する。なお、小規模な電子メー
ルシステムの場合、ＳＭＴＰサービスおよびＰＯＰサー
ビスを同一のマシンで実行することもある。

【００１７】ここで、送信サーバ３のホスト名を上記例
示の“ｍａｉｌ．ａａａ．ｃｏ．ｊｐ”とし、受信サー
バ４のホスト名を同“ｐｏｐ．ａａａ．ｃｏ．ｊｐ”と
すると、送信側のクライアントマシン１は、ＭＵＡを利
用してＳＭＴＰでホスト名“ｍａｉｌ．ａａａ．ｃｏ．
ｊｐ”の送信サーバ３にログインし、送信サーバ３に任
意の相手（コミュニケーション相手）先の電子メールを
アップロードする。

【００１８】今、電子メールの送信先を同一ドメイン
“ａａａ．ｃｏ．ｊｐ”に所属する任意ユーザ“ｘｘｘ
＠ａａａ．ｃｏ．ｊｐ”であるとすると、アップロード
された電子メールは、送信サーバ３からホスト名“ｐｏ
ｐ．ａａａ．ｃｏ．ｊｐ”の受信サーバ４へと転送さ
れ、その受信サーバ４にあらかじめ設定された当該ユー
ザのメールボックス（“ｘｘｘ＠ａａａ．ｃｏ．ｊｐ”
宛の着信メールを保存する記憶領域）に格納される。

【００１９】そして、受信側のクライアントマシン２の
操作者をユーザ“ｘｘｘ＠ａａａ．ｃｏ．ｊｐ”である
とすると、この操作者は、クライアントマシン２のＭＵ
Ａを利用してＰＯＰでホスト名“ｐｏｐ．ａａａ．ｃ
ｏ．ｊｐ”の受信サーバ４にログインし、この受信サー
バ４のメールボックス“ｘｘｘ＠ａａａ．ｃｏ．ｊｐ”
から電子メールをダウンロードする。

【００２０】図１（ｂ）は、複数（図では便宜的に４
台）のクライアントマシン５ａ〜５ｄ（コミュニケーシ
ョン相手リスト表示装置）を含む電子メールシステムの
概念図であり、各々のクライアントマシン５ａ〜５ｄは
いずれもＭＵＡをインストールしたものであり、図１
（ａ）の送信側クライアントマシン１または受信側クラ
イアントマシン２に相当するものである。すなわち、各
々のクライアントマシン５ａ〜５ｄは、メールを送信す
る際はクライアントマシン１として機能し、メールを受
信する際はクライアントマシン２として機能するもので
ある。

【００２１】クライアントマシン５ａ〜５ｄの間に位置
するネットワーク６は、図１（ａ）の送信サーバ３や受
信サーバ４及び名前解決のためのＤＮＳサーバならびに
通信回線などのネットワークインフラ全般を一括して模
式化したものである。今、それぞれのクライアントマシ
ン５ａ〜５ｄの利用者をユーザＡ、ユーザＢ、ユーザＣ
及びユーザＤとし、各ユーザの名前と電子メールアドレ
スを、以下のとおりであると想定する。

【００２２】＜ユーザＡ＞ 名前＝“阿部” 電子メールアドレス＝“ａｂｅ＠ａａａ．ｃｏ．ｊｐ” ＜ユーザＢ＞ 名前＝“千葉” 電子メールアドレス＝“ｃｈｉｂａ＠ｂｂｂ．ｃｏ．ｊ
ｐ” ＜ユーザＣ＞ 名前＝“藤井” 電子メールアドレス＝“ｆｕｊｉｉ＠ｃｃｃ．ｃｏ．ｊ
ｐ” ＜ユーザＤ＞ 名前＝“土井” 電子メールアドレス＝“ｄｏｉ＠ｄｄｄ．ｃｏ．ｊｐ”

【００２３】例えば、ユーザＡからユーザＤ（“土
井”）宛てに電子メールを送信する場合、ユーザＡはク
ライアントマシン５ａのＭＵＡを操作してメール作成画
面を開き、そのヘッダ部にユーザＤのアドレス“ｄｏｉ
＠ｄｄｄ．ｃｏ．ｊｐ”とメール表題を入力し、ボディ
部にメール本文を入力した後、ＭＵＡを操作して送信処
理を実行する。クライアントマシン５ａから送信された
電子メールは、所定の送信サーバ（ユーザＡのＭＵＡに
よって指定された送信サーバ３）にアップロードされ、
ユーザＤの電子メールアドレスを手がかりに名前解決さ
れた後、当該名前解決によって指定された受信サーバ４
に転送され、その受信サーバ４にあらかじめ設定されて
いるユーザＤのメールボックス（“ｄｏｉ＠ｄｄｄ．ｃ
ｏ．ｊｐ”）に格納される。しかる後、任意の時点でユ
ーザＤがクライアントマシン５ｄのＭＵＡを操作してメ
ールの受信動作を行うと、受信サーバ４のメールボック
ス（“ｄｏｉ＠ｄｄｄ．ｃｏ．ｊｐ”）に格納されてい
た着信メールがユーザＤのクライアントマシン５ｄにダ
ウンロードされる。

【００２４】以上のとおり、電子メールシステムにあっ
ては、共通のネットワークに接続された多数のメールク
ライアントマシンの間で自由に電子メールをやり取りす
ることができるうえ、しかも、メールクライアントマシ
ンは、当該ネットワークプロトコルに対応したＭＵＡを
搭載していればよく、パーソナルコンピュータはもちろ
んのこと、今日では携帯電話機やＰＨＳなどの携帯情報
端末からも電子メールのやり取りができることから、メ
ールの利用者はますます増加する傾向にある。したがっ
て、多くのメールアドレスを効率的に管理できるアドレ
ス帳などの支援ツールが欠かせないものとなっている。

【００２５】図２は、電子メールシステムに用いられる
クライアントマシン（図では便宜的にクライアントマシ
ン５ａ）の概念的なブロック構成を示す図である。な
お、この概念図は、実際の機器構成（パーソナルコンピ
ュータや携帯情報端末等の機器構成）を特定するもので
はない。ＭＵＡと共に、アドレス帳などの支援ツールを
実行可能なハードウェアの構成を簡略化して示すもので
ある。

【００２６】図２において、クライアントマシン５ａ
は、ＣＰＵ７（コミュニケーション実行手段）、プログ
ラムメモリ８、ワークメモリ９、データメモリ１０、表
示部１１、操作部１２、通信部１３およびバス１４など
を備えて構成されている。ＣＰＵ７は所定のオペレーテ
ィングシステム上でＭＵＡやアドレス帳などの機能を実
現するためのアプリケーションプログラムを実行する。
オペレーティングシステムは電子メールシステムのネッ
トワークプロトコル（インターネット上の電子メールシ
ステムであればＴＣＰ／ＩＰ）をサポートするか、ある
いは、当該プロトコルを実装することができる汎用のオ
ペレーティングシステムである。この種の汎用オペレー
ティングシステムは各種のＡＰＩ（Application Progra
mming Interface）を備えており、例えば、ＭＵＡに対
してＳＭＴＰやＰＯＰの利用環境を提供することができ
る。

【００２７】プログラムメモリ８はオペレーティングシ
ステムおよびＭＵＡやアドレス帳などの各種アプリケー
ションプログラムを格納する。ワークメモリ９はＣＰＵ
７の作業空間を提供するもので、ＣＰＵ７はこのワーク
メモリ９にオペレーティングシステムや各種アプリケー
ションプログラムを展開（ロード）して実行する。一般
にワークメモリ９には高速の半導体記憶デバイスが用い
られる。データメモリ１０はユーザ固有のデータを記憶
する領域であり、例えば、ＭＵＡを用いて送受信された
電子メールのデータ（送信簿や受信簿など）を記憶した
り、アドレス帳のデータを記憶したりするための領域で
ある。

【００２８】なお、図示のメモリ分類は機能的なものに
過ぎない。例えば、多くのパーソナルコンピュータはプ
ログラムとユーザデータをそれぞれハードディスクに格
納しているので、図示のプログラムメモリ８とデータメ
モリ１０は、それぞれハードディスク内のプログラム領
域およびデータ領域と読み替えることができる。

【００２９】表示部１１はクライアントマシン５ａと一
体または外付けのディスプレイおよび表示制御部からな
り、ユーザインターフェースのための画面出力を行う。
操作部１２はクライアントマシン５ａと一体または外付
けのキーボードやマウス等のポインティングデバイスお
よび操作制御部からなり、ユーザインターフェースのた
めの情報入力を行う。通信部１３はネットワークとの間
の情報入出力を行うもので、特にＳＭＴＰやＰＯＰ対応
の送信サーバおよび受信サーバを含むネットワーク（図
１（ｂ）のネットワーク６参照）との間の情報入出力を
行うものである。なお、クライアントマシン５ａが電話
機（携帯電話機やＰＨＳ）として用いられるものである
場合、通信部１３は電話機能をサポートする。

【００３０】このような構成を有するクライアントマシ
ン５ａは、ＣＰＵ７でＭＵＡを実行することにより、電
子メールの作成、電子メールの送信および着信メールの
受信ならびに閲覧等を行うことができる。すなわち、電
子メールを作成し、その電子メールを通信部１３を介し
てネットワーク上の送信サーバにアップロードすると共
に、受信サーバ上の自分宛ての着信メールをダウンロー
ドして閲覧することができる。

【００３１】図３は、データメモリ１０に格納された送
信簿１５および受信簿１６の概念図であり、いずれもユ
ニークなコード（以下「ＩＤ」という。）によって識別
されたレコード単位の情報構造（またはデータベース構
造）を有している。送信簿１５の各レコードは、ＩＤフ
ィールド１５ａ、送信日時フィールド１５ｂ、宛先フィ
ールド１５ｃ、差出人フィールド１５ｄ、表題フィール
ド１５ｅ、内容フィールド１５ｆおよびメールサイズフ
ィールド１５ｇなどからなり、また、受信簿１６の各レ
コードは、ＩＤフィールド１６ａ、受信日時フィールド
１６ｂ、差出人フィールド１６ｃ、宛先フィールド１６
ｄ、表題フィールド１６ｅ、内容フィールド１６ｆおよ
びメールサイズフィールド１６ｇなどからなっている。

【００３２】送信日時フィールド１５ｂには送信メール
の送信日付と時間の情報（ヘッダ部のDate）が格納さ
れ、宛先フィールド１５ｃには送信メールの宛先アドレ
ス情報（ヘッダ部のTo）が格納される。また、差出人フ
ィールド１５ｄには送信メールの差出人アドレス、すな
わち自分のアドレス情報（ヘッダ部のFrom）が格納さ
れ、表題フィールド１５ｅには送信メールの表題情報
（ヘッダ部のSubject）が格納される。また、内容フィ
ールド１５ｆには送信メールのメール本文情報（ボディ
部の情報）が格納され、メールサイズフィールド１５ｇ
には送信メールのメールサイズ（例えば、ボディ部の文
字数またはバイナリデータサイズ）が格納される。

【００３３】同様に、受信日時フィールド１６ｂには受
信メールの受信日付と時間の情報（ヘッダ部のDate）が
格納され、差出人フィールド１６ｃには受信メールの差
出人アドレス情報（ヘッダ部From）が格納される。ま
た、宛先フィールド１６ｄには受信メールの宛先アドレ
ス、すなわち自分のアドレス情報（ヘッダ部のTo）が格
納され、表題フィールド１６ｅには受信メールの表題情
報（ヘッダ部のSubject）が格納される。また、内容フ
ィールド１６ｆには受信メールのメール本文情報（ボデ
ィ部の情報）が格納され、メールサイズフィールド１５
ｇには受信メールのメールサイズ（例えば、ボディ部の
文字数またはバイナリデータサイズ）が格納される。

【００３４】図４（ａ）は、データメモリ１０に格納さ
れたアドレス帳１７（コミュニケーション相手リスト）
の概念図である。このアドレス帳１７も、上記の送信簿
１５や受信簿1６と同様にユニークなＩＤによって識別
さレコード単位の情報構造を有しており、各レコード
は、ＩＤフィールド１７ａ、名前フィールド１７ｂ、ア
ドレスフィールド１７ｃおよび親密度フィールド１７ｄ
などからなっている。

【００３５】ここで、名前フィールド１７ｂには、メー
ルの送信相手の名前（フルネームでもニックネームでも
よい）が格納され、アドレスフィールド１７ｃには同送
信相手の電子メールアドレスが格納される。また、親密
度フィールド１７ｄには、各々の送信相手ごとの“親密
度”（親密度についての定義および説明は後述する。）
を表す数値情報が格納される。例えば、図４（ｂ）は、
アドレス帳１７に記憶された情報の一例を示す図であ
り、ＩＤ“１００１”のレコードには、名前＝“安
部”、アドレス＝“ａｂｅ＠ａａａ．ｃｏ．ｊｐ”およ
び親密度＝“２１”の情報が格納されており、ＩＤ“１
００２”のレコードには、名前＝“千葉”、アドレス＝
“ｃｈｉｂａ＠ｂｂｂ．ｃｏ．ｊｐ”および親密度＝
“６０”の情報が格納されており、ＩＤ“１００３”の
レコードには、名前＝“藤井”、アドレス＝“ｆｕｊｉ
ｉ＠ｃｃｃ．ｃｏ．ｊｐ”および親密度＝“１００”の
情報が格納されており、ＩＤ“１００４”のレコードに
は、名前＝“土井”、アドレス＝“ｄｏｉ＠ｄｄｄ．ｃ
ｏ．ｊｐ”および親密度＝“９１”の情報が格納されて
いる。

【００３６】今、親密度の数値が高いほど、親しい間柄
であるとすると、図示の例における四人の送信相手の親
密度順は、“藤井”（１００）、“土井”（９１）、
“千葉”（６０）、“安部”（２１）・・・・となる。親密
度フィールド１７ｄをソート項目に指定して降順ソート
（値の大きい順からの並べ替え）を行えば、リストの最
上位に最も親しい送信相手（上記例では“藤井”）が位
置し、その下位に“土井”、“千葉”、“安部”、・・・
が順番に並ぶこととなる。

【００３７】さて、かかる親密度によるソートを効果的
に行うためには、親密度をどのようにとらえ、そしてそ
の度合いをどのようにして計算するかが重要な鍵とな
る。一般的に親密度は親しい間柄の度合いということが
できるものの、どのような尺度を持ってその度合いを決
めるかについての明確な定義はない。しかし、例えば、
親しい相手との間では、電子メールのやり取り回数（送
受信回数）が増えるという事実を指摘できるから、本実
施の形態では、基本的にこの事実に基づいて親密度を計
算することにする。

【００３８】すなわち、図５に示すように、送信簿１
５や受信簿１６の記憶データに基づいて送信相手ごとの
親密度計算処理を実行し、その計算結果を用いてアド
レス帳１７の親密度フィールド１７ｄを更新すると共
に、親密度フィールド１７ｄをソート項目に指定して
降順ソートを実行し、そのソート結果でアドレス値要
１７を書き換えるという一連の操作を実行することにす
る。

【００３９】親密度計算処理は、基本的に送信簿１５や
受信簿１６の記憶データに基づいて行うが、そのアルゴ
リズムについては、図６や図７に示す種々のものが考え
られる。親密度計算結果の信頼性や処理のオーバヘッド
等を勘案して適切なものを選択し、または組み合わせて
採用すればよい。

【００４０】＜単純型＞（図６（ａ）参照） 上記のとおり、親しい相手との間では、電子メールのや
り取り回数（送受信回数）が増えることは事実である。
したがって、この単純型では、送信簿１５および受信簿
１６から各ユーザごとの送信回数および受信回数を取り
出し、これらの送受信回数の総和を加算回路２０で計算
して、その計算結果（評価値Ａ）を親密度フィールド１
７ｄに格納する。

【００４１】＜積演算型＞（図６（ｂ）参照） しかし、電子メールのやり取り回数（送受信回数）は、
親しくない相手との間でも大きな値を示すことがある。
例えば、頻繁に送りつけられる嫌がらせメールの送信者
は、到底“親しい間柄”であるはずがない。そこで、上
記単純型の改良であるこの“積演算型”では、送信簿１
５および受信簿１６から各ユーザごとの送信回数および
受信回数を取り出し、これらの送受信回数の積を積演算
回路２１で計算して、その計算結果（評価値Ｂ）を親密
度フィールド１７ｄに格納する。評価値Ｂは、例えば、
頻繁に送りつけられる嫌がらせメールの受信回数が大き
な値を示した場合でも、そのメールに対する返信回数
（当該嫌がらせメールの送信者宛てのメール送信回数）
が少なければ小さな値を示す。例えば、送信回数を０と
すると、評価値Ｂも０になる。したがって、上記単純型
の欠点を解消することができる。

【００４２】＜送受信間隔判定型＞（図６（ｃ）参照） 例えば、仕事関係の打ち合わせのように、何度もメール
を交換し合いながら、互いの意思疎通を図ったり、業務
スケジュール等を詰めたりすることが行われるが、この
ような電子メールの利用形態においては、短期間にメー
ルの送受信回数が大きな値になってしまい、親しさの関
係に関わらず、すぐに親密度が高くなってしまうので好
ましくない。そこで、上記積演算型の改良であるこの
“送受信間隔判定型”では、送信簿１５および受信簿１
６から各ユーザごとの送信回数および受信回数を取り出
し、これらの送受信回数の間隔を送受信間隔判定回路２
２で判定して、送受信間隔が短い場合には、判定の対象
となった回数（送信回数または受信回数）の値を平方根
または対数換算回路２３で換算した後、当該換算値を積
演算回路２１で計算して、その計算結果（評価値Ｃ）を
親密度フィールド１７ｄに格納する。例えば、送信簿１
５から取り出した送信回数をｎとし、そのｎを平方根や
対数換算によって丸めることにより、換算後のｎ′をｎ
＞ｎ′とすることができ、上記の不都合、すなわち、短
期間にメールのやり取りが頻繁に行われた場合の意図し
ない親密度増加問題を解消できる。なお、ここでは、換
算手法を平方根または対数としたが、これに限定しな
い。要はｎ＞ｎ′とするための換算手法であればよい。

【００４３】＜経過時間考慮型＞（図７（ａ）参照） 古くからの友人（以下「友人Ａ」）と最近知り合った友
人（以下「友人Ｂ」）を考える。当事者の感覚で友人Ｂ
の方が親しいとすると、友人Ａの親密度よりも友人Ｂの
親密度が高くならなければならないが、上記三つのアル
ゴリズム（単純型、積演算型および送受信間隔型）はい
ずれもこれに応えることができない。古くからの友人Ａ
のメール送受信回数が友人Ｂよりも多いからである。そ
こで、この経過時間考慮型においては、送信簿１５およ
び受信簿１６から各ユーザごとの送信回数および受信回
数を取り出し、これらの回数に“送受信経過時間”に応
じた重み値を与える重み付け回路２４を設け、その重み
付けされた後の送信回数Ｔｎおよび受信回数Ｒｎを前記
送受信間隔型（図６（ｃ）参照）に入力する。

【００４４】ここで、送受信経過時間とは、現在日時を
Ｄ_CURRENTとしたとき、送信簿１５の送信日時フィール
ド１５ｂに格納された送信日時データＤ_TXからＤ
_CURRENTまでの経過時間（送信経過時間）、および、受
信簿１６の受信日時フィールド１６ｂに格納された受信
日時データＤ_RXからＤ_CURRENTまでの経過時間（受信経
過時間）のことをいう。送受信経過時間の長い送受信デ
ータについては小さな重み値を、また、送受信経過時間
の短い送受信データについては大きな重み値を与えるこ
とにより、例えば、上記例示の友人Ｂの親密度を適正化
することができる。

【００４５】図７（ｂ）は、送受信経過時間と重み値の
関係を示す図である。便宜的に線形で示す特性線２５
は、送受信経過時間の長い送受信データについては小さ
な重み値を、また、送受信経過時間の短い送受信データ
については大きな重み値を与える特性をもっている。な
お、図７（ｂ）の特性を図７（ｃ）のように変形させる
と好ましい。図７（ｃ）も、送受信経過時間と重み値の
関係を示す図であり、便宜的に線形で示す特性線２６
は、送受信経過時間の長い送受信データについては小さ
な重み値を、また、送受信経過時間の短い送受信データ
については大きな重み値を与える特性をもっている点
で、図７（ｂ）の特性線２５と共通するが、送受信経過
時間が所定値Ｔａ以上に長くなると、重み値を“０”と
する点で相違する。このようにすると、送受信経過時間
が所定値Ｔａ以上に古い送受信データに適用する重み値
を“０”にして、実質的にその送受信データの存在を無
視することができ、相対的に、上記例示の友人Ｂの親密
度をより一層適正化することができる。

【００４６】以上のとおり、上記の「単純型」、「積演
算型」、「送受信間隔判定型」または「経過時間考慮
型」によれば、送信簿１５や受信簿１６の記憶データに
基づいて送信相手ごとの親しさの度合いを表すとみなさ
れる評価値（親密度）を計算することができる。したが
って、その計算結果（上記の評価値Ａ、ＢまたはＣ）を
アドレス帳１７の親密度フィールド１７ｄに格納すると
共に、親密度フィールド１７ｄをソート項目に指定して
降順ソートを実行することにより、親密度の高い順にア
ドレス帳１７のレコードデータを並べ替えることがで
き、最も親密度の高い送信相手のレコードをリストの最
上位に位置させて表示させることができる。その結果、
スクロール等の操作を行うことなく、親しい間柄の送信
相手を速やかに選択することができ、電子メール作成時
の操作性の改善を図ることができるという、本発明の課
題達成に有益な格別の効果を奏することができるのであ
る。

【００４７】なお、上述の親密度計算処理は、以下のよ
うに変形することもできる。 ＜変形例１＞一般に、親しさの変化は、強固になる方向
（より親しくなる方向）だけでなく、弱体化する方向
（親しさが失われる方向）にも当然ながらある。親密度
は、これら両方向への追随特性をもつことが望ましい。
上述の親密度計算処理の演算結果（親密度）は、最初小
さな値からスタートし、電子メールのやり取りの増加に
伴って大きな値に変化するという漸増傾向を示す。した
がって、この変化の“加速度”（または微分値）に着目
すると、加速度が大きい場合は短時間のうちに親密度が
増したことになり、一方、加速度が小さい場合は長い時
間をかけて徐々に親密度が増したことになるから、上記
の各アルゴリズムによって計算された親密度は、より親
しくなる方向への緩急変化については適切な追随特性を
有しているということができる。

【００４８】しかしながら、逆方向への変化、すなわ
ち、親しさが失われる方向への変化については、必ずし
も適切な追随特性を有していない点で改良の余地があ
る。例えば、上記の「経過時間考慮型」では、送受信経
過時間の長い送受信データに小さな重み値を与えること
により、送受信経過時間の短いユーザに対する相対的な
親密度を小さくしているが、重み値と送受信経過時間と
の関係が一定（図７（ｂ）（ｃ）参照）であるため、親
しさが失われる方向への“緩急”の変化に追随していな
い。

【００４９】そこで、この改良例においては、より親し
くなる方向への親密度変化とその逆方向（親しさが失わ
れる方向）への親密度変化との間に相関を持たせるため
に、親密度の上記加速度の値を保持しておき、親密度を
減少方向に変化させる際には、この加速度値を用いて親
密度を計算するようにする。これによれば、比較的短時
間で上昇した親密度に対しては比較的急激にその度合い
を減少させることができる一方、時間をかけて徐々に上
昇した親密度に対しては穏やかに減少させることがで
き、親しさが失われる方向への緩急変化にも適切に追随
する親密度特性を得ることができる。

【００５０】＜変形例２＞上述の各アルゴリズムにおい
ては、送受信回数や送受信間隔または送受信経過時間な
どのパラメータを用いて親密度を計算しているが、これ
に限定されない。例えば、メールのサイズ情報（送信簿
１５や受信簿１６のメールサイズフィールド１５ｇ、１
６ｇの格納情報）も親密度に相関するパラメータとして
利用することが可能である。親しい間柄でやり取りされ
るメールは文字数等が多くなりやすく、また、しばしば
画像や音声などのファイル添付が行われることがあるか
らである。但し、この方法はあくまでも補助的な手段と
すべきである。単なる業務連絡であっても、その内容に
よってはメールサイズの増加が否めないからである。ま
た、メールのサイズ情報以外にも、例えば、メールの表
題情報（送信簿１５や受信簿１６の表題フィールド１５
ｅ、１６ｅの格納情報）や本文情報（送信簿１５や受信
簿１６の内容フィールド１５ｆ、１６ｆの格納情報）も
親密度に相関するパラメータとして利用することが可能
である。

【００５１】これらの情報に、親しい間柄でよく用いら
れる語彙や言葉遣いが含まれている場合、その語彙や言
葉遣いの出現頻度に基づいて親しさの度合い（親密度）
を計算することができる。あるいは、表題や内容の意味
解析を行って、感情や欲求に対する語彙を抽出し、各々
の語彙に対して重み付けを行ってもよい。但し、この方
法は、基準となる語彙や言葉遣いを収めた辞書ファイル
が必要になるうえ、語彙抽出や意味解析などに相応の処
理能力が求められるため、おそらくサーバサイドで行う
のが現実的であり、クライアントサイドで行う場合は、
クライアントマシンの処理性能などを考慮して、採用の
可否を決定すべきである。

【００５２】＜変形例３＞上記のとおり、本実施の形態
では親密度が高い順番でリストを表示することができ、
スクロール等を行うことなく、親しい間柄の送信相手を
選択することができるというメリットが得られる。しか
し、各送信相手の親しさの度合いを目視確認する場合、
親密度の値（数値）からしか確認することができず、ユ
ーザインターフェースの点で改善の余地がある。図８は
その改良例であり、親密度をいくつかのレベルに区分
し、各レベルごとにグラフィカルなオブジェクトアイコ
ンを割り当てるようにした例である。

【００５３】図８（ａ）において、親密度オブジェクト
テーブル２７は、親密度レベルフィールド２７ａおよび
オブジェクトフィールド２７ｂからなっており、各フィ
ールドは、例えば、高、中、低の三つのレベルに分けら
れたレコードを有すると共に、オブジェクトフィールド
２７ｂには、三つのハートマークを持つ高レベル用オブ
ジェクト２７ｃ、二つのハートマークを持つ中レベル用
オブジェクト２７ｄおよび一つのハートマークを持つ低
レベル用オブジェクト２７ｅが格納されている。

【００５４】ここに、便宜的に、高レベルの範囲を“１
００”〜“６７”、中レベルの範囲を“６６”〜“３
３”、低レベルの範囲を“３２”〜“０”とし、前記ア
ドレス帳１７の各ユーザ（“藤井”、“土井”、“千
葉”、“安部”）のそれぞれの親密度（“１００”、
“９１”、“６０”、“２１”）を当てはめると、“藤
井”と“土井”は高レベル、“千葉”は中レベルおよび
“安部”は低レベルになる。したがって、図８（ｂ）に
アドレスリスト２８の表示例を示すように、これらのレ
ベル判定結果に基づいて、名前等の情報と共に、高レベ
ル用オブジェクト２７ｃ、中レベル用オブジェクト２７
ｄおよび低レベル用オブジェクト２７ｅをアドレスリス
ト２８に併設表示することにより、ひと目で親密度のレ
ベル判定を行うことができ、リストの判読性および選択
性の向上を図ることができる。

【００５５】＜他の実施の形態＞以上の実施の形態はメ
ールクライアントマシン５ａ上で主要な機能を実現す
る、いわゆるクライアントサイドスクリプト環境を例と
したが、これに限定されない。以下に説明するように、
サーバサイドスクリプト環境にも適用することができ
る。

【００５６】図９は、複数のクライアント３０ａ〜３０
ｃに対し、インターネット等のネットワーク３１を介し
て所定のコミニケーションサービスを提供するサーバ３
２の概念構成図である。サーバ３２はコミニケーション
サービス処理部３３（コミュニケーション実行手段）お
よびデータベース部３４を有し、図示の全体構成は、ク
ライアント３０ａ〜３０ｃをユーザインターフェース層
３５、コミニケーション処理部３３をデータ処理層３
６、データベース部２４をデータベース層３７とする、
いわゆる三階層モデルのネットワークサービス構造を有
している。なお、データ処理層３６とデータベース層３
７は、一つのサーバマシンに実装されてもよいし、別の
サーバマシンに実装されていもよい。別のマシンに実装
する場合、マシンの物理的設置位置は問わない。両層間
のデータ通信が可能になっていればよい。

【００５７】ここで、コミニケーションサービス処理部
３３は、例えば、会員向のチャットサービスを提供する
ものとする。すなわち、コミニケーションサービス処理
部３３は、各クライアント３０ａ〜３０ｃからのログイ
ンを受け付けると共に、登録クライアントに対し、動的
に形成されたチャット画面を返送する。チャット画面
は、例えば、ＨＴＭＬ（Hyper Text Markup Language）
言語で記述されており、各クライアント３０ａ〜３０ｃ
はＨＴＭＬドキュメント対応の閲覧ソフト（いわゆるプ
ラウザ）を実行できる環境を有していればよい。なお、
チャットとはログイン中のユーザ同士でもっぱら文字列
による会話を楽しむ仕組みである。

【００５８】一般にチャットの参加者は自分のニックネ
ーム（チャットネームともいう。）と共に発言したい文
章を入力する。これらの入力情報は、クライアントのプ
ラウザからサーバ３２に伝えられ、サーバ３２のコミニ
ケーションサービス処理部３３でニックネームと一緒に
チャット画面に追加された後、このチャット画面が再び
クライアントに届けられる。コミニケーションサービス
処理部３３は、かかるチャット画面の更新処理を実行す
ると共に、ログイン参加者のリスト情報を構成して、そ
の画面情報をすべてのログインクライアントに提供す
る。ログインクライアントに表示されるリスト情報は、
前述のアドレス帳の情報と同様に、親密度の高い順番で
ソートされており、リスト選択の利便性を向上する。

【００５９】本実施の形態における親密度の計算も、前
記実施の形態と同様の考え方で行う。すなわち、あるチ
ャット参加者の発言に対する書き込みの回数は、前述の
実施の形態における電子メールの送信回数に相当し、当
該チャット参加者から見た上記書き込み回数（書き込ま
れた回数）は、前述の実施の形態における電子メールの
受信回数に相当する。また、書き込み間隔は前述の実施
の形態における電子メールの送受信間隔に相当し、書き
込み経過時間は前述の実施の形態における電子メールの
送受信経過時間に相当する。

【００６０】図１０は、サーバ３２のコミニケーション
サービス処理部３３におけるコミニケーションサービス
処理の要部のフローチャートである。このフローチャー
トでは、まず、ログインを判定し（ステップＳ１）、ロ
グインであれば、ログインユーザの認証（ステップＳ
２）を行い、認証ＮＧであればＮＧメッセージを返送
（ステップＳ３）して再びログイン判定のステップに戻
り、一方、認証ＯＫであればチャットメッセージの書き
込みであるか否かを判定する（ステップＳ４）。

【００６１】そして、チャットメッセージの書き込みの
場合は、チャットメッセージの書き込み処理とチャット
画面の更新処理（ステップＳ５）を行った後、親密度処
理（ステップＳ６）を実行し、チャットメッセージの書
き込みでない場合は、ログインユーザのリスト要求であ
るか否かを判定（ステップＳ７）して、ログインユーザ
のリスト要求であれば、当該リスト情報を送信し（ステ
ップＳ８）、そうでなければその他のコミニケーション
処理を実行する（ステップＳ９）。

【００６２】親密度処理（ステップＳ６）では、前述の
実施の形態における親密度計算処理と同様のアルゴリズ
ム（前記の「単純型」、「積演算型」、「送受信間隔判
定型」または「経過時間考慮型」を参照のこと。）に従
ってメッセージ書き込み相手の親密度の計算を行う（ス
テップＳ６ａ）と共に、その計算結果でログインユーザ
のリスト表示順をソートして更新する（ステップＳ６
ｂ）。

【００６３】したがって、この実施の形態においても、
チャット参加者の画面上に、親密度の高い順番でソート
された参加者リストを表示することができ、スクロール
等を行うことなく、親しい間柄のチャット相手を選択す
ることができるというメリットが得られる。

【００６４】なお、本実施の形態においても、前期実施
の形態と同様に、親密度をいくつかのレベルに区分し、
各レベルごとにグラフィカルなオブジェクトアイコンを
割り当てるようにしてもよい。すなわち、チャット参加
者の画面上に表示する参加者リストを、図８（ｂ）のよ
うにしてもよい。ひと目でチャット参加者の親密度のレ
ベル判定を行うことができ、リストの判読性および選択
性の向上を図ることができるから好ましい。

【００６５】本実施の形態の主要な機能は、マイクロコ
ンピュータを含むハードウェア資産と、オペレーティン
グシステムや各種プログラムなどのソフトウェア資産と
の有機的結合によって機能的に実現されるものである
が、ハードウェア資産およびオペレーティングシステム
は汎用のものを利用できるから、本発明にとって欠くこ
とのできない必須の事項は、実質的に、前述の親密度計
算処理及びその付帯処理（図５参照）に集約されている
ということがいえる。したがって、本発明は、前述の親
密度計算処理及びその付帯処理のためのプログラムのす
べてまたはその要部を格納した、フロッピィディスク、
光ディスク、コンパクトディスク、磁気テープ、ハード
ディスクまたは半導体メモリなどの記録媒体若しくはこ
れらの記録媒体を含む構成品（ユニット品や完成品また
は半完成品）を包含する。なお、上記記録媒体または構
成品は、それ自体が流通経路にのるものはもちろんのこ
と、ネットワーク上にあって記録内容だけを提供するも
のも含まれる。なお、上述の親密度計算処理は、以下の
ように変形することもできる。

【００６６】＜ＦＩＲフィルタを使用した本発明の変形
例＞次に、ＦＩＲフィルタを使用した本発明の変形例に
ついて説明する。上述したように親密度の計算方法は各
種のものがあるが、ＦＩＲフィルタを使用して親密度の
計算を行うことも可能である。例えば、所定期間内の過
去履歴でリストアップが決定するが、このような処理に
ＦＩＲフィルタを使用する。その場合、例えばメールイ
ベントの時刻・イベント固有の数値・時刻に従って掛け
られる重み関数があって、全アドレスについて、この演
算をして、その結果値（スカラー量）順にリストアップ
するような処理を行う。ここで、フィルタとは、ある周
波数帯域の信号を通過させ、それ以外の信号を阻止する
ものである。フィルタの分類には、線形／非線形、時不
変／時変等の種類の他に、インパルス応答が有限長のＦ
ＩＲ（Finite Impulse Response）フィルタと、インパ
ルス応答が無限長のＩＩＲ（Infinite Impulse Respons
e）フィルタとがある。一般に、デジタルフィルタの入
出力関係は、インパルス応答｛ｈ（ｎ）｝によって、次
式で表される。

【００６７】

【数１】

【００６８】式において、インパルス応答の値がｈ
（ｎ）が０≦ｎ≦Ｎ−１に対してのみ定義され、それ以
外のｎに対してはｈ（ｎ）＝０となるとき、インパルス
応答｛ｈ（ｎ）｝によって定まる線形システムをＦＩＲ
フィルタという。Ｎは、インパルス応答の持続時間であ
る。ＦＩＲフィルタは、ＩＩＲフィルタに比べて演算誤
差が小さい、安定性が良い、直線位相特性の実現が可能
等の特長がある。ＦＩＲフィルタはデジタル式のシフト
レジスタと加算器、乗算器によって構成できる。したが
って、このようなＦＩＲフィルタをシフトレジスタと加
算器、乗算器によって構成し、その特性を本発明の目的
に沿った親密度計算処理に適合するように設計すること
により、上記変形例１〜３とは別タイプの親密度計算シ
ステムとして実現することができる。その場合、上述し
た「単純型」、「積演算型」、「送受信間隔判定型」又
は「経過時間考慮型」に類似したものや、それらを組合
せたようなかなり複雑なシステム設計も可能であり、親
密度計算に多様性を持たせながら本発明を実現すること
ができる。

【００６９】

【発明の効果】本発明によれば、登録済みコミュニケー
ション相手と当該コミュニケーション相手を登録した登
録者との間における親しさの度合いを表すとみなされる
評価値を用いて、コミュニケーション相手のリストがソ
ートされるので、便宜的にその評価値のことを親密度と
呼ぶことにすれば、親密度の順にソートされた登録済み
コミュニケーション相手のリスト表から親しい間柄のコ
ミュニケーション相手を選択でき、コミュニケーション
相手の選択効率化と手間の軽減とを図ることができる。

【図面の簡単な説明】

【図１】電子メールシステムの概念図である。

【図２】電子メールシステムに用いられるクライアント
マシンの概念的なブロック構成を示す図である。

【図３】データメモリ１０に格納された送信簿１５およ
び受信簿１６の概念図である。

【図４】データメモリ１０に格納されたアドレス帳１７
の概念図及びアドレス帳１７に記憶された情報の一例を
示す図である。

【図５】本実施の形態における親密度計算処理を含む動
作概念図である。

【図６】親密度計算処理の一例（単純型、積演算型、送
受信間隔判定型）を示す概念図である。

【図７】親密度計算処理の一例（経過時間考慮型）を示
す概念図及び送受信経過時間と重み値の関係を示す図で
ある。

【図８】リスト表示の改良例を示す図である。

【図９】他の実施の形態の構成図である。

【図１０】他の実施の形態におけるコミニケーションサ
ービス処理の要部のフローチャートである。

【符号の説明】

７……ＣＰＵ（コミュニケーション実行手段）、１７…
…アドレス帳（コミュニケーション相手リスト）、１１
……表示部（表示手段）、５ａ〜５ｄ……クライアント
マシン（コミュニケーション相手リスト表示装置）、３
３……コミュニケーションサービス処理部（コミュニケ
ーション実行手段）。

Claims (18)

【特許請求の範囲】
1. 【請求項１】 任意の相手との間で通信インフラを介し
   て行われるコミュニケーションの際に、当該相手を選択
   するために用いられるコミュニケーション相手リストの
   表示方法であって、 前記コミュニケーション相手リストは、所定の項目でソ
   ートされた順番で登録済みのコミュニケーション相手を
   リスト表示するものであり、 且つ、前記所定の項目は、登録済みのコミュニケーショ
   ン相手と登録者との親しさの度合いを表す評価値である
   ことを特徴とするコミュニケーション相手リスト表示方
   法。
2. 【請求項２】 任意の相手との間で通信インフラを介し
   て行われるコミュニケーションの際に、当該相手を選択
   するために用いられるコミュニケーション相手リストの
   表示方法であって、 前記コミュニケーション相手リストは、所定の項目でソ
   ートされた順番で登録済みのコミュニケーション相手を
   リスト表示するものであり、 且つ、前記所定の項目は、登録済みのコミュニケーショ
   ン相手と登録者との親しさの度合いを表す評価値であ
   り、 さらに、コミュニケーション相手それぞれに前記評価値
   を区分分けした各区分ごとの画像オブジェクト若しくは
   それに相当する可視化表現オブジェクトを表示すること
   を特徴とするコミュニケーション相手リスト表示方法。
3. 【請求項３】 前記評価値は、コミュニケーション相手
   と登録者との間で行われるコミュニケーション送受回数
   の総和値又は該総和値に相関する値であることを特徴と
   する請求項１又は請求項２いずれかに記載のコミュニケ
   ーション相手リスト表示方法。
4. 【請求項４】 前記評価値は、コミュニケーション相手
   と登録者との間で行われるコミュニケーション送受回数
   の積値又は該積値に相関する値であることを特徴とする
   請求項１又は請求項２いずれかに記載のコミュニケーシ
   ョン相手リスト表示方法。
5. 【請求項５】 前記評価値は、コミュニケーション相手
   と登録者との間で行われるコミュニケーション送受間隔
   の長短に応じて変化する値であることを特徴とする請求
   項１又は請求項２いずれかに記載のコミュニケーション
   相手リスト表示方法。
6. 【請求項６】 前記評価値は、コミュニケーション相手
   と登録者との間で行われるコミュニケーション送受回数
   に、送受間隔に応じた重み付けをした値であることを特
   徴とする請求項１又は請求項２いずれかに記載のコミュ
   ニケーション相手リスト表示方法。
7. 【請求項７】 前記評価値は、親しさの度合いが高くな
   る場合と、低くなる場合の双方について、類似の追随特
   性を持たせたことを特徴とする請求項１乃至請求項６い
   ずれかに記載のコミュニケーション相手リスト表示方
   法。
8. 【請求項８】 前記評価値は、コミュニケーション情報
   のサイズ又はコミュニケーション情報の内容に基づいて
   設定されることを特徴とする請求項１乃至請求項７いず
   れかに記載のコミュニケーション相手リスト表示方法。
9. 【請求項９】 任意の相手との間で通信インフラを介し
   て行われるコミュニケーションを実行するコミュニケー
   ション実行手段と、 前記コミュニケーション実行の際に、コミュニケーショ
   ン相手を選択するために用いられるコミュニケーション
   相手リストを表示する表示手段とを備え、前記コミュニ
   ケーション相手リストは、所定の項目でソートされた順
   番で登録済みのコミュニケーション相手をリスト表示
   し、 且つ、前記所定の項目は、登録済みのコミュニケーショ
   ン相手と登録者との親しさの度合いを表す評価値である
   ことを特徴とするコミュニケーション相手リスト表示装
   置。
10. 【請求項１０】 任意の相手との間で通信インフラを介
    して行われるコミュニケーションを実行するコミュニケ
    ーション実行手段と、 前記コミュニケーション実行の際に、コミュニケーショ
    ン相手を選択するために用いられるコミュニケーション
    相手リストを表示する表示手段とを備え、 前記コミュニケーション相手リストは、所定の項目でソ
    ートされた順番で登録済みのコミュニケーション相手を
    リスト表示し、 且つ、前記所定の項目は、登録済みのコミュニケーショ
    ン相手と登録者との親しさの度合いを表す評価値であ
    り、 さらに、コミュニケーション相手それぞれに前記評価値
    を区分分けした各区分ごとの画像オブジェクト若しくは
    それに相当する可視化表現オブジェクトを表示すること
    を特徴とするコミュニケーション相手リスト表示装置。
11. 【請求項１１】 前記評価値は、コミュニケーション相
    手と登録者との間で行われるコミュニケーション送受回
    数の総和値又は該総和値に相関する値であることを特徴
    とする請求項９又は請求項１０いずれかに記載のコミュ
    ニケーション相手リスト表示装置。
12. 【請求項１２】 前記評価値は、コミュニケーション相
    手と登録者との間で行われるコミュニケーション送受回
    数の積値又は該積値に相関する値であることを特徴とす
    る請求項９又は請求項１０いずれかに記載のコミュニケ
    ーション相手リスト表示装置。
13. 【請求項１３】 前記評価値は、コミュニケーション相
    手と登録者との間で行われるコミュニケーション送受間
    隔の長短に応じて変化する値であることを特徴とする請
    求項９又は請求項１０いずれかに記載のコミュニケーシ
    ョン相手リスト表示装置。
14. 【請求項１４】 前記評価値は、コミュニケーション相
    手と登録者との間で行われるコミュニケーション送受回
    数に、送受間隔に応じた重み付けをした値であることを
    特徴とする請求項９又は請求項１０いずれかに記載のコ
    ミュニケーション相手リスト表示装置。
15. 【請求項１５】 前記評価値は、親しさの度合いが高く
    なる場合と、低くなる場合の双方について、類似の追随
    特性を持たせたことを特徴とする請求項９乃至請求項１
    ４いずれかに記載のコミュニケーション相手リスト表示
    装置。
16. 【請求項１６】 前記評価値は、コミュニケーション情
    報のサイズ又はコミュニケーション情報の内容に基づい
    て設定されることを特徴とする請求項９乃至請求項１５
    いずれかに記載のコミュニケーション相手リスト表示装
    置。
17. 【請求項１７】 コンピュータに所定の処理機能を実行
    させるためのプログラムであって、前記処理機能は、任
    意の相手との間で通信インフラを介して行われるコミュ
    ニケーションを実行するコミュニケーション実行手段
    と、登録済みのコミュニケーション相手と登録者との親
    しさの度合いを表す評価値でソートされた順番で登録済
    みのコミュニケーション相手をリスト表示する表示手段
    とを含むことを特徴とするプログラム。
18. 【請求項１８】 コンピュータに所定の処理機能を実行
    させるためのプログラムであって、前記処理機能は、任
    意の相手との間で通信インフラを介して行われるコミュ
    ニケーションを実行するコミュニケーション実行手段
    と、登録済みのコミュニケーション相手と登録者との親
    しさの度合いを表す評価値でソートされた順番で登録済
    みのコミュニケーション相手をリスト表示するととも
    に、コミュニケーション相手それぞれに前記評価値を区
    分分けした各区分ごとの画像オブジェクト若しくはそれ
    に相当する可視化表現オブジェクトを表示する表示手段
    とを含むことを特徴とするプログラム。