JP2009230576A - 情報所在管理方法及び情報所在管理装置 - Google Patents

Abstract

【課題】情報所在先情報を適宜更新する。
【解決手段】通信ログ記憶手段１ａには、外部ネットワーク４を介して外部装置とやり取りされた電子メールの通信記録が記憶される。取得先選別手段１ｄは、通信ログを読み出し、対象の利用者が電子メールの送受信を一定回数以上行った相手先を特定し、情報取得先に選別する。情報所在先作成手段１ｅは、取得先選別手段１ｄによって選別された情報取得先との間で送受信された電子メールに含まれる情報取得先の情報の所在に関連するキー情報を抽出し、情報所在先情報を生成する。生成された情報所在先情報は、情報所在先蓄積手段１ｂに記憶される。情報取得装置３は、情報所在先蓄積手段１ｂに蓄積される情報所在先情報に基づいて、この情報を取得する。
【選択図】図１

Description

本発明は情報所在管理方法及び情報所在管理装置に関し、特にネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法及び情報所在管理装置に関する。

近年、コンピュータ及びネットワークシステムの進展に伴って、ネットワーク上に存在する所望の情報を収集することが可能となっている。たとえば、インターネット上のドキュメントシステムとして広く普及しているＷＷＷ（World Wide Web）は、現在では世界規模での巨大なＷＷＷ網が構築されている。しかし、このように膨大な情報の中から必要な情報を取り出すことは容易ではない。その解決策のひとつとして、ウェブサイト（Ｗｅｂサイト）の情報収集を目的とするＲＳＳ（Rich Site Summary）リーダが普及し始めている。ＲＳＳリーダは、ウェブサイトを巡回して、ＲＳＳで記述されたウェブサイトの更新情報などを自動収集し、収集した情報を表示する機能を有する。利用者は、自らウェブサイトを巡回することなく、ウェブサイトの最新情報を収集することができる。ＲＳＳリーダによって、ウェブサイトが提供する情報の収集効率を飛躍的に向上させることができるようになった。

また、情報の所在を管理する方法として、ブラウザが提供するブックマークがある。利用者は、所望のウェブサイトの所在をブックマークに登録しておくことができる。以下、情報資源の所在を指示する記述は、記述方式として最も一般的な、ＵＲＬ（Uniform Resource Locator）を用いるとして説明する。ブックマークにより、すぐに必要なウェブサイトへアクセスすることができるようになる。

しかし、利用者にとって必要な情報は、時間の経過とともに変化する。そこで、ウェブサイトへのアクセス回数を監視し、アクセス回数が所定の追加基準を超えたときはこのウェブサイトのＵＲＬをブックマークのリストに載せ、所定の削除基準を下回ったときは削除するアドレス管理方法が知られている（たとえば、特許文献１参照）。また、電子メールの宛先管理方法として、所定の時間単位で受信発信の使用頻度を求め、使用頻度に応じて宛先のアドレスを管理する技術も知られている（たとえば、特許文献２参照）。
特開２００２−４９５４１号公報（図９） 特開２００２−１９７０２７号公報（図２）

しかし、従来の情報所在管理方法では、取得したい情報の所在先を管理するための負担が大きいという問題点があった。
ＲＳＳリーダは、指定したウェブサイトからの情報収集には非常に有効であるが、巡回先のウェブサイトを予め利用者が登録しなければならないため、手間がかかるという問題点がある。アクセス回数の高いウェブサイトをブックマークに登録する方法は開示されているが、その前の段階として新たな情報の取得先を発見するのは、利用者自身で行わなければならない。新たな情報の取得先は、たとえば、検索エンジンを用いて検索を行ってウェブサイトを探し出したり、現在リストに登録されているウェブサイトの情報から必要な情報が掲載されているウェブサイトを探し出したりしなければならない。

また、不要になったときは、リストから削除しなければならない。アクセス回数の低いウェブサイトをブックマークから削除する方法は開示されているが、登録先が自動的に巡回され、登録先の情報が収集されるＲＳＳリーダにそのまま適用することは難しい。

利用者にとって取得したい有益な情報は、時間経過とともに変化する。特に、業務に必要な情報は常に変化するため、継続的にリストをメンテナンスすることは非常に難しい。このため、リストのメンテナンスがされず、リストに登録されている巡回先のウェブサイトの情報が不要となっていたり、必要な情報の所在先が登録されていないなど、リストが利用者の状況と離れてしまうことが度々あった。この結果、利用者は有益な情報を得ることができなくなってしまう。

本発明はこのような点に鑑みてなされたものであり、利用者が取得したい情報の所在先に対応する情報所在先情報を適宜更新することができる情報所在管理方法及び情報所在管理装置を提供することを目的とする。

上記課題を解決するために、ネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法が提供される。情報所在管理方法は、取得先選別手段が、送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の通信ログを読み出し、対象の利用者が少なくとも一往復の電子メールの送受信を一定回数以上行った電子メールの相手先を特定して情報取得先に選別する手順と、情報所在先作成手段が、情報取得先との間で送受信された電子メールに含まれる情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する手順と、を有する。

このような情報所在管理方法によれば、取得先選別手段によって、通信ログ記憶手段から所定の期間の電子メールの通信ログが読み出される。そして、通信ログに基づき、対象の利用者が少なくとも一往復の電子メールの送受信を一定回数以上行った相手先が特定され、情報の取得先に選別される。続いて情報所在先作成手段によって、該情報取得先との間で送受信された電子メールに含まれる情報取得先の情報の所在に関連するキー情報が抽出される。そして、キー情報に基づいてこの情報取得先の情報所在先情報が生成され、情報所在先蓄積手段に記憶される。

また、上記課題を解決するために、上記の情報所在管理方法の処理手順を実行する取得先選別手段と、情報所在先作成手段と、を有する情報所在管理装置が提供される。

開示の情報所在管理方法及び情報所在管理装置によれば、通信ログを用いて、対象の利用者が電子メールの送受信を一定回数以上行った情報取得先が選別される。そして送受信された電子メールからキー情報が抽出され、キー情報に基づいて情報取得先に関する情報所在先情報が生成されて情報所在先蓄積手段に記憶される。これにより、電子メールのやり取りを行っている相手先の情報所在先情報が適宜取得され、情報所在先蓄積情報に蓄積される。これを利用することにより、相手先に関連する取得したい情報を容易に取得することができる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、実施の形態に適用される発明の概念図である。
情報所在管理装置１は、通信ログ記憶手段１ａ、情報所在先蓄積手段１ｂ、メール情報取得手段１ｃ、取得先選別手段１ｄ、及び情報所在先作成手段１ｅを有し、外部ネットワーク４に接続するメールサーバ２と、情報取得装置３とに接続する。そして、ネットワーク上に存在する所定の情報の所在を管理する。

通信ログ記憶手段１ａには、メールサーバ２を介して送受信された電子メールの通信記録が記憶される。通信記録の中には、対象の利用者が相手先と行った電子メールのやり取りも記録されている。なお、やり取りとは、同一アドレスの相手と電子メールの送受信を一往復以上行うことを表すとする。すなわち、ユーザと相手先でやり取りがあるということは、ユーザから相手先、及び相手先からユーザに電子メールが送受信されたことを言う。

情報所在先蓄積手段１ｂは、情報所在先作成手段１ｅによって生成された情報取得先に関する情報所在先を示した情報所在先情報が蓄積される記憶手段である。
メール情報取得手段１ｃは、メールサーバ２を介して送受信された電子メールの情報を通信ログとして通信ログ記憶手段１ａに記憶する。全ての電子メールの送受信はメールサーバ２を介して行われるため、メール情報取得手段１ｃは送受信された全ての電子メールに関する情報を取得することができる。通信ログには、電子メールの発信元の送信者、宛先の受信者、件名、受信時刻などのほか、必要であればメール本文も保存される。

取得先選別手段１ｄは、通信ログ記憶手段１ａから新着の通信ログを読み出し、対象の利用者が所定の期間に、やり取りした、すなわち、少なくとも一往復以上の電子メールを一定回数以上送受信した相手先を特定し、情報取得先に選別する。所定の期間は、利用者の状況が変わらない期間、たとえば、１週間や１０日などが設定される。期間は利用者の状況に応じて適宜決められる。また、業務上の大きな変化があったときなどは、その都度期間が設定されるとしてもよい。一往復以上とするのは、広告メールやスパムメールなどを排除し、利用者が何らかの情報交換を行っている相手先を情報取得先に選別するためである。また、一定回数には、１または２以上の任意の整数が予め登録される。重要な相手先であれば、複数回の電子メールのやり取りがあると予想されることによる。こうして、情報取得先が選別される。また、業務上の相手先であれば、対象利用者との間の電子メールのやり取りの回数が少なくても、対象利用者と同じ部署や会社など、同じグループに所属する他の利用者と電子メールのやり取りを行っている可能性が高い。そこで、対象利用者との間の電子メールの送受信回数が少なくても、他の利用者とやり取りを行っていれば、情報取得先に選別するとしてもよい。また、逆に、相手先と同じグループに属する相手と電子メールのやり取りを行っている場合も、同様に、有益な情報取得先として選別できる。

情報所在先作成手段１ｅは、選別された情報取得先との間で送受信された電子メールに関する情報、さらに必要に応じて電子メール本文を通信ログ記憶手段１ａから読み出す。読み出した電子メールに関する情報に含まれる情報取得先の情報の所在に関連するキー情報を抽出する。そして、抽出されたキー情報に基づいて情報取得先の情報の所在を示す情報所在先情報を生成し、情報所在先蓄積手段１ｂに記憶する。キー情報には、メールアドレスに含まれるドメイン（domain）名や、電子メール本文に含まれるＵＲＬなどの情報所在先情報がある。企業などの組織では、組織の人が使用するメールアドレスに含まれるドメイン名と、その組織に関する情報の所在先を示す情報所在先とは、組織名に対応する部分などの一部が一致する場合が多い。そこで、ドメイン名から情報所在先候補を生成し、情報所在先候補が外部ネットワーク４上に存在するか否かを判定する。存在していれば、情報所在先候補を情報所在先に確定し、その情報所在先情報を情報所在先蓄積手段１ｂに記憶する。また、同一利用者の電子メールに度々出現する情報所在先は、署名に書かれた所属会社のウェブサイトなど、その利用者と関連が深いものが多いと予想される。そこで、メール本文に一定回数以上出現する情報所在先を相手先の情報所在先に特定し、情報所在先蓄積手段１ｂに記憶する。

メールサーバ２は、外部ネットワーク４を介して送受信される電子メールを管理する。
情報取得装置３は、所定の周期で、情報所在先蓄積手段１ｂに記憶される情報所在先に対し外部ネットワーク４を介してアクセスし、提供される情報を収集する。

外部ネットワーク４は、インターネットなどのネットワークで、情報所在先情報を用いて外部ネットワーク４に接続する企業などが提供する情報を収集することができる。
このような構成の情報所在管理装置１による情報所在管理方法の処理手順について説明する。

メール情報取得手段１ｃは、メールサーバ２を介して送受信された電子メールの情報を取得し、通信ログ記憶手段１ａに格納する。取得先選別手段１ｄは、通信ログ記憶手段１ａから新着の通信ログを読み出し、調査対象の利用者が所定の期間に少なくとも一往復以上の電子メールを送受信した相手先を特定する。その相手先との送受信回数が一定回数以上であれば、相手先を情報取得先とする。これは、頻繁に電子メールをやり取りする相手の情報は利用者にとって重要と予想されることに基づく。また、対象利用者との直接の送受信回数が一定回数以上でなくても、対象利用者の属するグループの他の利用者との間で電子メールのやり取りがされていれば、相手先を情報取得先とすることもできる。所定の期間、情報取得先と選別する電子メールの送受信回数、同じグループの他の利用者との電子メール交換を参照するかなどは、予め選別ルールとして決めておいてもよい。

こうして情報取得先が選別されると、情報所在先作成手段１ｅは、通信ログ記憶手段１ａから、情報取得先と送受信された電子メールに関する情報を読み出す。読み出した電子メールに関する情報に含まれる情報取得先の情報の所在に関連するキー情報を抽出する。そして、抽出されたキー情報に基づいて情報取得先の情報の所在を示す情報所在先情報を生成し、情報所在先蓄積手段１ｂに記憶する。たとえば、電子メールのメールアドレスや、電子メール本文中のＵＲＬなどの情報所在先をキー情報として情報所在先を設定する。情報取得装置３は、情報所在先蓄積手段１ｂに記憶される情報取得先に対し、外部ネットワーク４を介してアクセスし、情報取得先に関する情報を得ることができる。

このような処理が行われることにより、所定期間に一定回数以上電子メールをやり取りした相手の情報所在先情報が情報所在先蓄積手段１ｂに蓄積される。頻繁に電子メールをやり取りする相手先の情報は重要であると予想されることから、情報所在先蓄積手段１ｂに自動的に蓄積される情報所在先情報に基づいて取得したい有益な情報を容易に得ることができるようになる。利用者は、情報の所在先を自ら検索して設定する必要がなくなるため、取得したい情報の所在先を管理するための負担を軽減することができる。取得された情報所在先は、ウェブブラウザのブックマークや、ＲＳＳリーダの巡回先のウェブサイトの登録などに用いることができる。

以下、実施の形態を、ＲＳＳリーダの巡回先リストの管理に適用した場合を例に図面を参照して詳細に説明する。巡回先リストには、ＲＳＳリーダが定期的にアクセスして情報を自動収集するウェブサイトのＵＲＬが登録される。

図２は、実施の形態のシステムの構成例を示した図である。
実施の形態の情報所在管理装置１１は、インターネット４０に接続するＢ社システム１０内に配置される。Ｂ社システム１０は、内部ネットワーク１７に情報所在管理装置１１、利用者の端末１２ａ，１２ｂ、メールサーバ１３が、ファイアウォール１４を介してＤＭＺ（DeMilitarized Zone）にある公開ウェブサーバ１５、メール中継サーバ１６と、外部のインターネット４０に接続する。また、相手先のＡ社システム２０も同様に、内部ネットワーク２７に端末２２ａ，２２ｂ、メールサーバ２３が、ファイアウォール２４を介してＤＭＺにある公開ウェブサーバ２５、メール中継サーバ２６と、インターネット４０に接続する。

メールサーバ１３は、メールボックスを管理し、端末１２ａ，１２ｂのメール送受信を監視する。端末１２ａ，１２ｂは、メール処理を行うメーラーと、ＲＳＳリーダとを有し、情報所在管理装置１１から配信される巡回先リストに基づき、ＲＳＳリーダの巡回先を設定する。公開ウェブサーバ１５は、インターネット４０を介してアクセス可能なウェブサイトを管理する。所定のＵＲＬを用いてアクセスすることにより、Ａ社が提供するウェブサイトの情報を取得することができる。メール中継サーバ１６は、インターネット４０を介して接続する外部の端末２２ａ，２２ｂと、内部ネットワーク１７に接続される端末１２ａ，１２ｂとの間で送受信される電子メールを中継する。なお、Ａ社システム２０の各装置も同様の機能を有する。

情報所在管理装置１１は、内部ネットワーク１７に接続する端末１２ａ，１２ｂと外部の端末（たとえば、Ａ社の端末２２ａ，２２ｂ）との間でやり取りされるメールを監視し、必要であれば、やり取りされているメールに基づいて、Ａ社の公開ウェブサーバ２５が提供する情報のＵＲＬを取得し、取得されたＵＲＬ情報を端末１２ａ，１２ｂのＲＳＳリーダに配信する。また、必要がなくなったと判断されれば、このＵＲＬを削除する。

なお、図の例では、ネットワーク上に情報所在管理装置１１を設け、取得されたＵＲＬ情報を各端末１２ａ，１２ｂに配信するとしたが、情報所在管理装置１１を端末１２ａ、１２ｂなどに組み込んでおく構成とすることもできる。また、ＵＲＬ情報は、端末１２ａ，１２ｂが必要に応じて情報所在管理装置１１から取得するとしてもよい。

ここで、情報所在管理装置１１のハードウェア構成について説明する。図３は、情報所在管理装置のハードウェア構成例を示すブロック図である。
情報所在管理装置１１は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ：Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に記憶される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが記憶される。ＨＤＤ１０３には、ＯＳやアプリケーションのプログラムが記憶される。グラフィック処理装置１０４には、モニタ１０８が接続されており、ＣＰＵ１０１からの命令に従って画像をモニタ１０８の画面に表示させる。入力インタフェース１０５には、キーボード１０９ａやマウス１０９ｂが接続されており、キーボード１０９ａやマウス１０９ｂから送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。通信インタフェース１０６は、内部ネットワーク１７に接続されており、内部ネットワーク１７を介して他装置との間でデータの送受信を行う。

このようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、情報所在管理装置１１のハードウェア構成を示したが、端末１２ａ，１２ｂなど、図２のシステムにおける他の装置のハードウェア構成も同様である。

次に、情報所在管理装置１１の処理機能を実現するソフトウェア構成例について説明する。まず、第１の実施の形態として、情報所在管理装置１１全体の処理機能を説明するとともに、メールアドレスに基づいてＵＲＬを生成する処理について説明する。

図４は、第１の実施の形態における情報所在管理装置の主要部の機能構成例を示したブロック図である。
第１の実施の形態の情報所在管理装置１１の主要部は、記憶部１１０、取得先選別部１２０、ＵＲＬ生成部１３０、ＵＲＬ削除部１４０、及びＲＳＳリーダ登録部１５０を有し、ＲＳＳリーダ３００が巡回する情報所在先のＵＲＬが登録される巡回先リストを管理する。

記憶部１１０には、電子メールの送受信が記録される通信ログ１１１、取得先選別部１２０が選別した情報取得先の候補リスト１１２、及びＵＲＬ生成部１３０によって生成されたＵＲＬを蓄積するＵＲＬ蓄積情報１１３などが記憶される。各情報の詳細は後述する。

取得先選別部１２０は、相手先特定部１２１と、候補リスト登録部１２２とを有し、取得先選別手段１ｄとして機能する。相手先特定部１２１は、対象利用者（以下、ユーザとする）について、所定の期間に少なくとも一往復以上の電子メールを送受信した相手先を特定する。候補リスト登録部１２２は、相手先特定部１２１によって特定された相手先が、情報取得先の候補となるかどうかを判定する。たとえば、ユーザとの間の電子メールの送受信回数が一定回数以上であればその相手先を情報取得先に選別し、候補リスト１１２に載せる。また、ユーザが属するグループの他のメンバとの間で一定回数以上の電子メール送受信が行われていれば、その相手先を候補リスト１１２に載せるとしてもよい。また、その組み合わせでもよい。このような選別のための基準を以下、選別ルールとする。

ＵＲＬ生成部１３０は、ＵＲＬ候補作成部１３１と、ＵＲＬ確認登録部１３２とを有し、情報所在先作成手段１ｅとして機能する。ＵＲＬ候補作成部１３１は、取得先選別部１２０が候補リスト１１２に設定した情報取得先のメールアドレスを読み出し、ドメイン名を抽出する。そして、ドメイン名を用いて、ＵＲＬを予測したＵＲＬ候補を作成する。ＵＲＬ確認登録部１３２は、ＵＲＬ候補作成部１３１が作成したＵＲＬ候補がインターネット上に存在するかどうかを実際にアクセスするなどして判定する。存在が確認できたときは、このＵＲＬ候補を情報取得先としてＵＲＬ蓄積情報１１３に登録する。ＵＲＬ蓄積情報１１３には、ＵＲＬがユーザと特定された情報取得先と関連付けて記憶される。

ＵＲＬ削除部１４０は、送受信状況確認部１４１と、削除判定部１４２とを有し、ＵＲＬ蓄積情報１１３に登録されているが、電子メールでのやり取りがなくなった情報取得先のＵＲＬをＵＲＬ蓄積情報１１３から削除する。送受信状況確認部１４１は、通信ログ１１１を読み出し、ＵＲＬ蓄積情報１１３に登録されたユーザと情報取得先との間で電子メールの送受信が行われているかどうか、送受信状況を確認する。削除判定部１４２は、送受信状況確認部１４１の確認結果に基づいて、所定の期間送受信がされていなければ、ＵＲＬ蓄積情報１１３から対応するＵＲＬ登録レコードを削除する。また、必要に応じてＲＳＳリーダ３００の巡回先リストからも削除する。

ＲＳＳリーダ登録部１５０は、記憶部１１０に記憶されるＵＲＬ蓄積情報１１３に基づいて、各端末１２ａ，１２ｂのＲＳＳリーダ３００の巡回先が登録される巡回先リストを更新する。

ここで、記憶部１１０に記憶される情報について説明する。図５は、通信ログの一例を示した図である。
通信ログ１１１０は、送信者のメールアドレス１１１２、宛先である受信者のメールアドレス１１１３、件名１１１４、及び日付１１１５の情報項目を有する。なお、説明のため各レコードには、識別のためのＩＤ１１１１を付与している。

ここで、一往復の電子メールとは、件名１１１４が同じ少なくとも一組の電子メールで、かつ、一方の送信者１１１２と宛先１１１３のメールアドレスが他方では宛先１１１３と送信者１１１２になっている組み合わせを言う。たとえば、点線で結ばれているＩＤ＝１は、Ａ１＠ａ．ｃｏ．ｊｐからＢ１＠ｂ．ｃｏ．ｊｐに送信された件名「Ｓ１」の電子メールである。ＩＤ＝２は、逆に、Ｂ１＠ｂ．ｃｏ．ｊｐからＡ１＠ａ．ｃｏ．ｊｐに送信された件名「Ｓ１」の電子メールである。このような通信ログのＩＤ＝１に記録される電子メールと、ＩＤ＝２に記録される電子メールは、一往復の電子メールである。図では、このような電子メールの組を点線１１１６で結んでいる。

図６は、候補リストの一例を示した図である。
候補リスト１１２０には、取得先選別部１２０によって情報取得先として選別された相手先のアドレスが登録されている。ユーザ１１２２及び宛先１１２３の情報項目を有する。各レコードにＩＤ１１２１を付与していることは通信ログ１１１０と同様である。ユーザ１１２２は、ユーザのメールアドレスが登録される。ここでは、Ｂ社システム１０内をユーザとしているので、ユーザはＢｎ（ｎは任意の整数）によって表す。宛先１１２３には、情報取得先として選別された相手先のメールアドレスが登録される。

図７は、ＵＲＬ蓄積情報の一例を示した図である。
ＵＲＬ蓄積情報１１３０には、ＵＲＬ生成部１３０によって生成された情報取得先のＵＲＬが登録されている。ユーザ１１３２、宛先１１３３、及び収集先ＵＲＬ１１３４の情報項目を有する。各レコードにＩＤ１１３１を付与していることは通信ログ１１１０と同様である。また、ユーザ１１３２及び宛先１１３３は、候補リスト１１２０のユーザ１１２２及び宛先１１２３と同じである。収集先ＵＲＬ１１３４には、ＵＲＬ生成部１３０が、宛先１１２３のメールアドレスに基づいて生成され、存在が確認されたＵＲＬが登録される。

以下、上記の記憶部１１０に記憶される各情報を用いて、取得先選別部１２０、ＵＲＬ生成部１３０、ＲＳＳリーダ登録部１５０、及びＵＲＬ削除部１４０において実行される処理手順を詳細に説明する。

取得先選別部１２０では、通信ログ１１１０に基づいてユーザが頻繁に電子メールをやり取りする相手先を特定し、所定の条件を満たした相手先を情報取得先に選別する。ここでは、選別ルール１及び選別ルール２の２つの場合について説明する。選別ルール１は、所定の期間に、ユーザと相手先との間で直接やり取りされた電子メールの送受信回数に基づいて選別を行うとする。たとえば、「１週間以内の直接のメールのやり取り回数が２回以上」というルールである。また、選別ルール２は、ユーザに加え、ユーザと同じグループに属する他のメンバとの通信状況も加味して選別を行うとする。たとえば、「１週間以内の直接のメールのやり取りがあり、他のユーザとのやり取り回数が２回以上」というルールである。

図８は、取得先選別処理の具体例を示した図である。［Ａ］は選別ルール１が適用された場合、［Ｂ］は選別ルール２が適用された場合を示している。ここでは、ユーザをＢ１（ユーザのメールアドレスは、Ｂ１＠ｂ．ｃｏ．ｊｐ）として説明する。

［Ａ］選別ルール１「１週間以内の直接のメールのやり取り回数が２回以上」が適用された場合は、通信ログ１１１０から、１１月２８日から過去１週間以内にユーザＢ１（Ｂ１＠ｂ．ｃｏ．ｊｐ）とやり取りを行った相手先が抽出される。ＩＤ＝１とＩＤ＝２には、件名「Ｓ１」について宛先「Ａ１＠ａ．ｃｏ．ｊｐ」とやり取りをしたことが記録されている。ＩＤ＝４とＩＤ＝５には、件名「Ｓ３」について宛先「Ａ１＠ａ．ｃｏ．ｊｐ」とやり取りをしたことが記録されている。ＩＤ＝６とＩＤ＝７には、件名「Ｓ４」について宛先「Ａ２＠ａ．ｃｏ．ｊｐ」とやり取りをしたことが記録されている。ＩＤ＝８とＩＤ＝１３には、件名「Ｓ５」について宛先「Ａ１＠ａ．ｃｏ．ｊｐ」とやり取りをしたことが記録されているが、一週間以内という条件は満たさない。以上より、宛先として「Ａ１＠ａ．ｃｏ．ｊｐ」と、「Ａ２＠ａ．ｃｏ．ｊｐ」とが抽出される。さらに、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」と「Ａ１＠ａ．ｃｏ．ｊｐ」との送受信回数は２回であり、２回以上という条件を満たすので、「Ａ１＠ａ．ｃｏ．ｊｐ」は、候補リストに登録される。しかし、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」と「Ａ２＠ａ．ｃｏ．ｊｐ」との送受信回数は１回であり、２回以上という条件を満たさないので、「Ａ２＠ａ．ｃｏ．ｊｐ」は、候補リストに登録されない。以上より、候補リスト（選別ルール１）１１２０ａには、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」に対して宛先「Ａ１＠ａ．ｃｏ．ｊｐ」が登録される。

なお、件名の一致は、部分一致とする。実際には、送受信される電子メールの件名が必ずしも一致しない。たとえば、応答を示す「ＲＥ：」が付加されたりする。そこで、ある程度一致すれば、同じ件名であるとみなす。件名の文字列を形態素分析し、一致する文字列が全体の文字列に含まれる割合が一定値を超えるものを同じ件名と見なすとしてもよい。

［Ｂ］選別ルール２「１週間以内の直接のメールのやり取りがあり、他のユーザとのやり取り回数が２回以上」が適用された場合は、同様にして、宛先として「Ａ１＠ａ．ｃｏ．ｊｐ」と、「Ａ２＠ａ．ｃｏ．ｊｐ」とが抽出される。このうち、「Ａ１＠ａ．ｃｏ．ｊｐ」については、１週間以内にＢ１と同じグループの他のユーザ（Ｂ２，Ｂ３）と通信を行っていない。このため、候補リスト（選別ルール２）１１２０ｂには、登録されない。一方、「Ａ２＠ａ．ｃｏ．ｊｐ」については、ＩＤ＝９とＩＤ＝１０に、件名「Ｓ６」についてユーザ「Ｂ２＠ｂ．ｃｏ．ｊｐ」とやり取りをしたことが記録されている。同様に、ＩＤ＝１１とＩＤ＝１２に、件名「Ｓ７」についてユーザ「Ｂ３＠ｂ．ｃｏ．ｊｐ」とやり取りをしたことが記録されている。したがって、選別ルール２を満たす。この場合、候補リストには、やり取りを行った全てのユーザを登録する。以上より、候補リスト（選別ルール２）１１２０ｂには、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」、ユーザ「Ｂ２＠ｂ．ｃｏ．ｊｐ」、ユーザ「Ｂ３＠ｂ．ｃｏ．ｊｐ」に対して宛先「Ａ２＠ａ．ｃｏ．ｊｐ」が登録される。

このように、選別ルールに基づいて、情報所在先の候補リストが登録される。なお、選別ルールは、参照される期間、やり取り回数、他のユーザとのやり取りを参照するか、などを適用システムに応じて適宜設定される。また、たとえば、選別ルール１と選別ルール２を組み合わせ、いずれかに適合する宛先を候補としてもよい。

以上の処理手順により、候補リスト１１２０が生成され、処理がＵＲＬ生成部１３０に引き継がれる。
図９は、ＵＲＬ生成処理の具体例を示した図である。図の例では、候補リスト１１２０に、情報所在先として宛先「Ａ１＠ａ３．ａ２．ａ１．ｃｏｍ」が設定されたとする。以下、次の手順を実行する。

［１］最初に、宛先のメールアドレスからドメイン名を抽出する。＠マークの次がドメイン名であり、ここでは「ａ３．ａ２．ａ１．ｃｏｍ」２００が抽出される。
［２］抽出されたドメイン名「ａ３．ａ２．ａ１．ｃｏｍ」２００に、スキームを付加する。スキームには、たとえば、一般的な、ＨＴＴＰプロトコルを定義する「ｈｔｔｐ：//」と「ｈｔｔｐｓ：//」を用いる。これにより、ＵＲＬ候補、「ｈｔｔｐ：//ａ３．ａ２．ａ１．ｃｏｍ」２１１と、「ｈｔｔｐｓ：//ａ３．ａ２．ａ１．ｃｏｍ」２１２が作成される。

こうして生成されたＵＲＬ候補がインターネット４０上に存在するか否かを判定する。このＵＲＬにアクセスし、アクセスできるかどうかによって存在の有無を判定する。アクセスできれば、このＵＲＬ候補をＵＲＬ蓄積情報１１３０に登録する。アクセスできなければ、次のＵＲＬ候補を生成する。

［３］次のＵＲＬ候補は、ドメインが提供するサービスに応じた文字列を前の候補のドメイン名の最左に付加する。情報収集の対象となるウェブサイトが提供するサービスはｗｗｗであるので、「ｗｗｗ．」を付加する。ここでは、「ｈｔｔｐ：//ａ３．ａ２．ａ１．ｃｏｍ」２１１と、「ｈｔｔｐｓ：//ａ３．ａ２．ａ１．ｃｏｍ」２１２に「ｗｗｗ．」を付加し、「ｈｔｔｐ：//ｗｗｗ．ａ３．ａ２．ａ１．ｃｏｍ」２２１と、「ｈｔｔｐｓ：//ｗｗｗ．ａ３．ａ２．ａ１．ｃｏｍ」２２２が作成される。このＵＲＬにアクセスし、アクセスできるかどうかを確認し判定を行う。アクセスできれば、このＵＲＬ候補をＵＲＬ蓄積情報１１３０に登録する。アクセスできなければ、次のＵＲＬ候補を生成する。

［４］次のＵＲＬ候補は、ドメイン名の一部を削除して生成する。一般に、組織名に応じたドメイン名は所定の階層構造を有することが知られており、最も左側が組織の最下層になる。そこで、最下層に対応する文字列を削除してＵＲＬ候補を生成する。上位の階層に行くほど、ＵＲＬが存在する可能性が高くなると予想される。ここでは、前の候補の「ｗｗｗ．」と、ドメイン名の最左から「．（ピリオド）」までを削除する。図の例では、「ｈｔｔｐ：//ｗｗｗ．ａ３．ａ２．ａ１．ｃｏｍ」２２１と、「ｈｔｔｐｓ：//ｗｗｗ．ａ３．ａ２．ａ１．ｃｏｍ」２２２から「ｗｗｗ．」と「ａ３．」が削除され、「ｈｔｔｐ：//ａ２．ａ１．ｃｏｍ」２３１と、「ｈｔｔｐｓ：//ａ２．ａ１．ｃｏｍ」２３２が作成される。このＵＲＬにアクセスし、アクセスできれば、このＵＲＬ候補をＵＲＬ蓄積情報１１３０に登録する。アクセスできなければ、次のＵＲＬ候補を生成する。

［５］次のＵＲＬ候補は、前の候補のドメイン名の最左に「ｗｗｗ．」を付加する。ここでは、「ｈｔｔｐ：//ａ２．ａ１．ｃｏｍ」２３１と、「ｈｔｔｐｓ：//ａ２．ａ１．ｃｏｍ」２３２に「ｗｗｗ．」を付加し、「ｈｔｔｐ：//ｗｗｗ．ａ２．ａ１．ｃｏｍ」２４１と、「ｈｔｔｐｓ：//ｗｗｗ．ａ２．ａ１．ｃｏｍ」２４２が作成される。このＵＲＬにアクセスし、アクセスできるかどうかを確認し存在有無の判定を行う。アクセスできれば、このＵＲＬ候補をＵＲＬ蓄積情報１１３０に登録する。アクセスできなければ、次のＵＲＬ候補を生成する。

［６］次のＵＲＬ候補は、前の候補の「ｗｗｗ．」と、ドメイン名の最左から「．」までを削除する。図の例では、「ｈｔｔｐ：／／ｗｗｗ．ａ２．ａ１．ｃｏｍ」２４１と、「ｈｔｔｐｓ：／／ｗｗｗ．ａ２．ａ１．ｃｏｍ」２４２から「ｗｗｗ．」と「ａ２．」が削除され、「ｈｔｔｐ：／／ａ１．ｃｏｍ」２５１と、「ｈｔｔｐｓ：／／ａ１．ｃｏｍ」２５２が作成される。このＵＲＬにアクセスし、アクセスできるかどうかを確認し、存在有無の判定を行う。アクセスできれば、このＵＲＬ候補をＵＲＬ蓄積情報１１３０に登録する。アクセスできなければ、次のＵＲＬ候補を生成する。

［７］次のＵＲＬ候補は、前の候補のドメイン名の最左に「ｗｗｗ．」を付加する。ここでは、「ｈｔｔｐ：／／ａ１．ｃｏｍ」２５１と、「ｈｔｔｐｓ：／／ａ１．ｃｏｍ」２５２に「ｗｗｗ．」を付加し、「ｈｔｔｐ：／／ｗｗｗ．ａ１．ｃｏｍ」２６１と、「ｈｔｔｐｓ：／／ｗｗｗ．ａ１．ｃｏｍ」２６２が作成される。このＵＲＬにアクセスし、アクセスできるかどうかを確認して存在有無の判定を行う。アクセスできれば、このＵＲＬ候補をＵＲＬ蓄積情報１１３０に登録する。アクセスできない場合、これ以上の削除はできないので、ＵＲＬ生成を中止する。

以上のように、メールアドレスから抽出されたドメイン名を用いて、ＵＲＬ候補が生成され、インターネット４０上に存在があることが判定されれば、このＵＲＬ候補がＵＲＬ蓄積情報１１３０に登録される。

こうしてＵＲＬ蓄積情報１１３０に登録されたＵＲＬは、ＲＳＳリーダ３００に配信される。ＲＳＳリーダ登録部１５０では、ＵＲＬ蓄積情報１１３０に新たに登録されたＵＲＬをＲＳＳリーダ３００に登録する。

図１０は、ＲＳＳリーダ登録処理後のリスト例を示した図である。
図の例では、図７に示したＵＲＬ蓄積情報１１３０に登録されるＩＤ＝１のユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」、収集先ＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」と、ＩＤ＝２のユーザ「Ｂ２＠ｂ．ｃｏ．ｊｐ」、収集先ＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」とが新規登録であったとしている。

ＲＳＳのリストは、ユーザＢ１のリスト３１０を例にとると、サイトのタイトル３１０ａ、そのサイトの情報所在先を示すＵＲＬ３１０ｂ、及び取得した情報を保存する保存先フォルダ３１０ｃの情報項目を有する。これは、ユーザＢ２でも同様である。

ＲＳＳリーダ登録部１５０は、ユーザＢ１とユーザＢ２のＲＳＳリーダ３００のリストに、「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」が登録されていなければ、これを登録する。サイトのタイトルは、電子メールのアドレス情報などから取得できるのであれば、これを用いる。これにより、ユーザＢ１のリスト３１０には、「株式会社Ａ社」のＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」３１１が新たに登録される。同様に、ユーザＢ２のリスト３２０には、「株式会社Ａ社」のＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」３２１が新たに登録される。

各ユーザのＲＳＳリーダ３００は、新規登録された「株式会社Ａ社」のＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」を自動巡回サイトに加え、情報収集を行う。こうして、頻繁に電子メールのやり取りを行う相手先に関する情報が自動的に収集されるようになる。

ところで、業務の変化とともに、情報を取得したい宛先のリストに登録されていた相手先の情報を必要としなくなる場合がある。このような場合には、その相手先との電子メールのやり取りもなくなると予想される。ＵＲＬ削除部１４０では、電子メールの送受信状況を確認し、一定期間やり取りがされていなければ、ＵＲＬ蓄積情報１１３０から宛先を削除する。必要に応じてＲＳＳリーダ３００の巡回先リストからも削除する。

たとえば、図７に示したＵＲＬ蓄積情報１１３０のＩＤ＝１には、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」、宛先「Ａ１＠ａ．ｃｏ．ｊｐ」に対応付けられて収集先ＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」が登録されている。ＵＲＬ削除部１４０では、通信ログ１１１０を検索し、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」、宛先「Ａ１＠ａ．ｃｏ．ｊｐ」の組み合わせで電子メールが送受信されているかどうかをチェックする。ここでは、「１０日間電子メールが送受信されていなければ削除」という設定がされているとする。なお、削除するための期限は任意に設定される。通信ログ１１１０には、１０日以内に、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」と宛先「Ａ１＠ａ．ｃｏ．ｊｐ」との間で電子メールの送受信が行われたことが記録されている（たとえば、ＩＤ＝１とＩＤ＝２）。したがって、この登録レコードは維持する。同様の手順でＵＲＬ蓄積情報１１３０の登録を順次調べていくと、ＩＤ＝５のユーザ「Ｂ２＠ｂ．ｃｏ．ｊｐ」と宛先「Ｃ１＠ｘｘｘ．ｃｏ．ｊｐ」との電子メールの送受信は、通信ログ１１１０から検出されない。最後にユーザ「Ｂ２＠ｂ．ｃｏ．ｊｐ」と、宛先「Ｃ１＠ｘｘｘ．ｃｏ．ｊｐ」との間で送受信された電子メールは、１０日以上前であると判定されるので、ＵＲＬ蓄積情報１１３０からＩＤ＝５のレコードを削除する。また、ユーザＢ２のＲＳＳリーダの対応する巡回リストの登録も削除する。これにより、電子メールのやり取りが所定の期間行われていない相手先が、情報の収集先から削除される。

なお、ＵＲＬ削除部１４０は、各ユーザのＲＳＳリーダの巡回先リストを自動で削除するのではなく、一定期間電子メールのやり取りがされていない相手先であることをユーザに通知し、登録削除を承認するか否かを問い合わせてから削除するとしてもよい。

次に、情報所在管理装置１１によって実行される情報所在管理方法の処理手順についてフローチャートを用いて説明する。
図１１は、情報所在管理方法における全体の処理手順を示したフローチャートである。

所定の周期で処理が開始される。
［ステップＳ０１］ 電子メールの送受信が記録されている通信ログ１１１を用いて、情報取得先を選別する取得先選別処理を行う。選別された情報取得先の候補リスト１１２が作成される。
［ステップＳ０２］ステップＳ０１の取得先選別処理で生成された候補リスト１１２に基づいて、情報取得先のＵＲＬを生成するＵＲＬ生成処理を行う。情報収集先のＵＲＬが蓄積されたＵＲＬ蓄積情報１１３に生成されたＵＲＬが登録される。
［ステップＳ０３］ ＵＲＬ蓄積情報１１３に基づいて、該当するユーザのＲＳＳリーダの巡回先リストに新たに検出されたＵＲＬを登録する。
［ステップＳ０４］ ＵＲＬ蓄積情報１１３に登録されている宛先との間の電子メール通信状況を調べる。一定期間電子メールが送受信されていなければ、ＵＲＬ蓄積情報１１３から該当のレコードを削除する登録メンテナンス処理を行う。このとき、ユーザのＲＳＳリーダの登録更新も行われる。

なお、上記の処理手順では、登録メンテナンス処理（ステップＳ０４）を、新規の情報所在先を登録するためのステップＳ０１からステップＳ０３の後に続けて行うとしたが、別のタイミングで実行させるとしてもよい。

続いて、各処理の詳細を説明する。
図１２は、取得先選別処理の手順を示したフローチャートである。ここでは、まず、検出された宛先に選別ルール１（ユーザと相手先との直接のやり取りが一定回数以上）を適用し、選別ルール１が満たされなかった宛先についてさらに、選別ルール２（ユーザと直接のやり取りがあり、ユーザと同じグループに属する他のメンバとのやり取り回数が一定回数以上）が成立するかを判定する処理を行う。なお、選別ルール２の処理手順は、図１３に示している。
［ステップＳ１０１］ 通信ログ１１１から未処理の新着メールに関する送受信状況の記録を取得する。
［ステップＳ１０２］ 取得された新着メールの送受信状況記録に基づき、通信記録のあるユーザを対象として宛先を抽出する。対象のユーザと少なくとも一往復以上の電子メールの送受信を行っている相手先の宛先を抽出し、この宛先が候補リスト１１２またはＵＲＬ蓄積情報１１３に登録済みであるかどうかを判定する。登録済みでないときは、処理をステップＳ１０３に進める。登録済みであれば、処理をステップＳ１０６に進める。
［ステップＳ１０３］ 所定期間の通信ログを抽出し、対象のユーザと宛先との間で電子メールが送受信された回数を算出する。
［ステップＳ１０４］ ステップＳ１０３で算出された送受信回数が一定回数以上であるかどうかを判定する。一定回数以上であれば、処理をステップＳ１０５に進める。一定回数以上でなければ、図１３に示した分岐点Ａへ処理を進める。
［ステップＳ１０５］ 対象ユーザと、抽出された宛先との間で電子メールが一定回数以上送受信されていたので、宛先を候補リスト１１２に追加する。
［ステップＳ１０６］ この宛先に関する処理が終了したので、全新着メールについて処理が終了したかどうかを判定する。全新着メールが終了していれば、処理を終了する。終了していないときは、ステップＳ１０２に戻って、次の宛先を抽出処理からの手順を行う。

図１３は、取得先選別処理に選別ルール２を適用したときの手順を示したフローチャートである。図１２の分岐点Ａからの続きの処理が開始される。
［ステップＳ１１１］ 通信ログから所定期間における宛先と、ユーザと同じグループに属する他のユーザとの間の電子メールの送受信に関する記録を取得する。
［ステップＳ１１２］ 他のユーザと宛先との間で電子メールが送受信された回数を算出する。
［ステップＳ１１３］ ステップＳ１１２で算出された他のユーザと宛先との間における電子メールの送受信回数が一定回数以上であるかどうかを判定する。一定回数以上であれば、処理をステップＳ１１４に進める。一定回数以上でなければ、図１２の分岐点Ｂへ処理を進める。
［ステップＳ１１４］ 対象ユーザと同一グループの他のユーザと、抽出された宛先との間で電子メールが一定回数以上送受信されていたので、他のメンバもユーザに加え、ユーザと宛先とを候補リスト１１２に追加する。図１２の分岐点Ｂに戻って、全新着メールのチェックが終わったかどうかの判定からの処理を行う。

以上の処理手順が実行されることにより、選別ルールに基づいて、情報の取得対象となる情報所在先が候補リストに登録される。
図１４は、ＵＲＬ生成処理の手順を示したフローチャートである。
［ステップＳ２０１］ 候補リスト１１２を読み出し、宛先を取得する。
［ステップＳ２０２］ ＵＲＬ蓄積情報１１３と照合し、このユーザと宛先とに対応する収集先ＵＲＬが登録されているか、未登録であるかを判定する。未登録であれば、処理をステップＳ２０３に進める。登録されていれば、処理をステップＳ２１１に進める。
［ステップＳ２０３］ 候補リスト１１２から宛先のメールアドレスを抽出する。
［ステップＳ２０４］ ステップＳ２０３で抽出された宛先のメールアドレスからドメイン名を抽出する。ドメイン名は、メールアドレスの＠マーク以降の文字列を言う。
［ステップＳ２０５］ ドメイン名にスキームを追加し、ＵＲＬ候補を生成する。スキームには、たとえば、ＨＴＴＰプロトコルを定義する「ｈｔｔｐ：／／」や「ｈｔｔｐｓ：／／」を用いる。
［ステップＳ２０６］ ステップＳ２０５で生成されたＵＲＬ候補を用いて、このＵＲＬにアクセスが可能であるかどうかをチェックする。アクセス不可であれば、処理をステップＳ２０７に進める。アクセス可であれば、処理をステップＳ２１２に進める。
［ステップＳ２０７］ ステップＳ２０５で生成されたＵＲＬ候補を用いたアクセスが不可であったときは、ドメイン名の最左に「ｗｗｗ．」を付加する。
［ステップＳ２０８］ ステップＳ２０７で生成されたＵＲＬ候補を用いて、このＵＲＬにアクセスが可能であるかどうかをチェックする。アクセス不可であれば、処理をステップＳ２０９に進める。アクセス可であれば、処理をステップＳ２１２に進める。
［ステップＳ２０９］ ステップＳ２０７で生成されたＵＲＬ候補を用いたアクセスが不可であったときは、ドメイン名の最左をピリオドまで削除する。これにより、ドメイン名の最下層が削除される。
［ステップＳ２１０］ ステップＳ２０９による先所処理によって文字列が残っているかどうかを判定する。残っていないときはＵＲＬ生成を中止してステップＳ２１１に処理を進める。残っているときは処理をステップＳ２０５に進め、ステップＳ２０９で修正されたドメイン名を用いて、処理を繰り返す。
［ステップＳ２１１］ 候補リスト１１２に登録された全候補の処理が終了したかどうかを判定する。終了していなければ、ステップＳ２０１に戻って次の宛先の処理を行う。全候補終了していれば、処理を終了する。
［ステップＳ２１２］ 生成されたＵＲＬ候補がネットワーク上に存在することが確認されたので、このＵＲＬ候補をＵＲＬ蓄積情報１１３に登録する。

以上の処理手順が実行されることにより、電子メールの送受信記録に基づいて候補リストに登録された相手先のＵＲＬが生成され、ＵＲＬ蓄積情報１１３に蓄積される。
図１５は、ＲＳＳリーダ登録処理の手順を示したフローチャートである。
［ステップＳ３０１］ ＵＲＬ蓄積情報１１３に新規追加されたＵＲＬのひとつを選択する。
［ステップＳ３０２］ ステップＳ３０１で選択されたＵＲＬが該ユーザのＲＳＳリーダの巡回先リストに登録されているかどうかを判定する。未登録であれば、処理をステップＳ３０３に進める。登録されていれば、処理をステップＳ３０４に進める。
［ステップＳ３０３］ 未登録であれば、ステップＳ３０１で選択されたＵＲＬをＲＳＳリーダの巡回先リストに登録する。
［ステップＳ３０４］ ＵＲＬ蓄積情報１１３に新規登録されたＵＲＬについての処理がすべて終了したか否かを判定する。終了していなければ、処理をステップＳ３０１に進め、次の新規登録ＵＲＬについての処理を行う。終了していれば、処理を終了する。

以上の処理手順が実行されることにより、各ユーザのＲＳＳリーダに、電子メールでのやり取りを頻繁に行っている相手に関する情報を収集することが可能となる。
こうして登録されたＵＲＬ蓄積情報１１３及びＲＳＳリーダの巡回先リストに登録されるＵＲＬも時間経過とともに不要となる場合がある。

図１６は、登録メンテナンス処理の手順を示したフローチャートである。
［ステップＳ４０１］ ＵＲＬ蓄積情報からデータをひとつ読み出し、ユーザ及び宛先のメールアドレスを取得する。
［ステップＳ４０２］ 通信ログ１１１を読み出し、ステップＳ４０１で取得されたユーザと宛先との間で電子メールの送受信が行われているかどうか、メール送受信状況を取得する。
［ステップＳ４０３］ メール送受信状況に基づいて、ステップＳ４０１で読み出されたユーザのメールアドレスと、宛先のメールアドレスとの間でやり取りが行われた最新の日付を抽出する。そして、最後の電子メールのやり取りからの経過日数を算出する。
［ステップＳ４０４］ 経過日数が所定の日数（図では、ｄ日としている）未満であるかどうかを判定する。所定の日数以上であれば、処理をステップＳ４０５に進める。所定の日数未満であれば、処理をステップＳ４０７に進める。
［ステップＳ４０５］ 最後のやり取りからの経過日数が、所定の日数以上であれば、対象ユーザのＲＳＳリーダの登録から該当ＵＲＬを削除する。
［ステップＳ４０６］ 続けて、ＵＲＬ蓄積情報１１３から該当レコードを削除する。これにより、対象ユーザについてＵＲＬ蓄積情報１１３に登録された宛先と収集先ＵＲＬとが削除される。
［ステップＳ４０７］ 全登録ＵＲＬについて処理が終わったかどうかを判定する。終わっていないときは、処理をステップＳ４０１に戻し、次のＵＲＬ登録のメンテナンスを行う。全登録ＵＲＬのメンテナンスが終わっていれば、処理を終了する。

以上の処理手順が実行されることにより、一定期間電子メールのやり取りがされなくなった宛先に関するＵＲＬの登録が削除される。これにより、ＲＳＳリーダの巡回先リストから不要な巡回先が削除される。

次に、第２の実施の形態について説明する。第１の実施の形態では、ＵＲＬ生成部１３０において相手先のメールアドレスを用いるとしたが、第２の実施の形態ではメール本文を用いる。なお、第２の実施の形態における情報所在管理装置が有する処理機能の構成要素は、図４に示した第１の実施の形態の構成要素と同様である。そこで、図４に示した構成要素の符号を用いて、第２の実施の形態における機能を説明する。

ただし、ＵＲＬ生成部１３０については、第１の実施の形態と異なる処理が行われる。第２の実施の形態では、ＵＲＬ候補作成部１３１は、メール本文に記載されているＵＲＬを抽出し、これをＵＲＬ候補とする。メール本文中に記載されているＵＲＬは実在のＵＲＬであるので、ＵＲＬ確認登録部１３２では同じＵＲＬが一定回数以上出現していれば、これを情報所在先としてＵＲＬ蓄積情報１１３に登録する。

具体例を用いて説明する。図１７は、メール本文から生成されるＵＲＬ情報例を示した図である。
ＵＲＬ生成部１３０は、ユーザと相手先との間でやり取りされた電子メール本文を取得する。図の電子メール４１０、４２０が取得された電子メールの一例である。電子メール４１０，４２０は、ユーザ（図２のＢ社システム１０側の利用者）が、相手先（図２のＡ社システム２０側の利用者）から受け取った電子メールである。相手先であって、Ａシステム側の利用者のメールアドレスは、図６の候補リスト１１２０に示したように、「宛先」に登録されている。電子メール４１０には、署名情報として、相手先（候補リスト１１２の「宛先」、以下同様）であるＡ１の所属する組織のＵＲＬ４１１が記載されている。同様に、他の電子メール４２０にもＡ１の所属する組織のＵＲＬ４２１が記載されている。このように、同一の相手先から取得される電子メールに度々出現するＵＲＬは、相手先の所属会社のウェブサイトなど、関連が深いものであると予想できる。したがって、このＵＲＬを抽出し、情報所在先としてＵＲＬ蓄積情報１１３に設定すれば、有益な情報所在先が登録される。

図１８は、第２の実施の形態のＵＲＬ生成処理の手順を示したフローチャートである。
［ステップＳ２２１］ 電子メールの相手先として、候補リスト１１２の「宛先」に登録される宛先アドレスを取得する。
［ステップＳ２２２］ ステップＳ２２１で抽出された相手先（宛先アドレス）が、ＵＲＬ蓄積情報１１３の収集先ＵＲＬに登録されているか否かを判定する。未登録であれば、処理をステップＳ２２３に進める。登録されていれば、処理をステップＳ２２７に進める。
［ステップＳ２２３］ 通信ログ１１１から、ユーザと、相手先（宛先アドレス）との間でやり取りされた電子メールを取得する。
［ステップＳ２２４］ ステップＳ２２３で取得した電子メール本文に出現したＵＲＬを抽出し、その出現回数をカウントする。複数の電子メールから検出されたときは、すべてを合算する。
［ステップＳ２２５］ ステップＳ２２４で算出された出現回数が所定回数以上であるかどうかを判定する。所定回数以上であれば、処理をステップＳ２２６に進める。所定回数に達していなければ、処理をステップＳ２２７に進める。
［ステップＳ２２６］ 一定回数以上出現したＵＲＬを、ユーザ、該宛先アドレスに関連付け、ＵＲＬ蓄積情報１１３に登録する。
［ステップＳ２２７］ 候補リスト１１２に登録される全候補の処理が終了したかどうかを判定する。終了していなければ、ステップＳ２２１に戻って、次の候補の処理を行う。全候補終了していれば、ＵＲＬ作成処理を終了する。

以上の処理手順が実行されることにより、電子メールを頻繁にやり取りする相手先の電子メールに度々出現するＵＲＬをＵＲＬ蓄積情報１１３に登録することができる。ＵＲＬ蓄積情報１１３に登録されたＵＲＬは、ＲＳＳリーダ登録部１５０によってＲＳＳリーダ３００の巡回先リストに登録することができる。この結果、電子メールを頻繁にやり取りする相手先と関連が深いと予測されるＵＲＬから情報を定期的に取得できるようになる。なお、必要なくなったと判定されれば、巡回先リストから削除されることは、第１の実施の形態と同様である。

次に、第３の実施の形態について説明する。第３の実施の形態では、ＵＲＬ生成の基とする情報として、他メンバのＵＲＬ登録情報を用いる。なお、第３の実施の形態における情報所在管理装置が有する処理機能の構成要素は、図４に示した第１の実施の形態の構成要素と同様である。そこで、図４に示した構成要素の符号を用いて、第３の実施の形態における機能を説明する。ただし、情報取得先ＵＲＬ生成部１３０については、第１の実施の形態及び第２の実施の形態と異なる処理が行われる。

第３の実施の形態では、候補リスト１１２に登録された候補のＵＲＬが、ユーザと同じグループに属する他のメンバに関連付けてＵＲＬ蓄積情報１１３に登録されているときは、このＵＲＬ蓄積情報１１３に登録されるＵＲＬを読み出す。そして、読み出したＵＲＬを、該ユーザと相手先とに対応付けてＵＲＬ蓄積情報１１３に登録する。

図１９は、他のユーザの登録情報から生成されるＵＲＬ情報例を示した図である。
［１］候補リスト取得処理では、候補リスト１１２０ｃを取得する。図の例では、ＵＲＬ生成部１３０が取得した候補リスト１１２０ｃには、ユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」と、宛先「Ａ５＠ａ．ｃｏ．ｊｐ」とが記憶されている。

次に、［２」ＵＲＬ蓄積情報取得処理では、ＵＲＬ生成部１３０は、宛先「Ａ５＠ａ．ｃｏ．ｊｐ」について、ＵＲＬ蓄積情報１１３０ａに、「Ａ５＠ａ．ｃｏ．ｊｐ」が宛先に登録される他のメンバ「Ｂ２＠ｂ．ｃｏ．ｊｐ」、「Ｂ３＠ｂ．ｃｏ．ｊｐ」、「Ｂ４＠ｂ．ｃｏ．ｊｐ」、「Ｂ５＠ｂ．ｃｏ．ｊｐ」が検出される。利用者Ｂ２，Ｂ３，Ｂ４，Ｂ５は、ユーザＢ１（メールアドレスは、Ｂ１＠ｂ．ｃｏ．ｊｐ」と同じグループに所属する。したがって、これらのユーザと、宛先「Ａ５＠ａ．ｃｏ．ｊｐ」とに対応付けられた収集先ＵＲＬ、「ｈｔｔｐ：／／ａ．ｃｏ．ｊｐ」、「ｈｔｔｐ：／／ａ／ａ．ｃｏ．ｊｐ」、「ｈｔｔｐ：／／ａａａ．ａ／ｃｏ．ｊｐ」がＵＲＬ蓄積情報１１３０ａより抽出される。重複するものは省いている。そして、これらのＵＲＬがユーザ「Ｂ１＠ｂ．ｃｏ．ｊｐ」と、宛先「Ａ５＠ａ．ｃｏ．ｊｐ」とに関連付けられ、ユーザの収集先ＵＲＬとして登録される。なお、既に他のメンバについて登録されているＵＲＬであるので、ネットワーク上に存在するかどうかの判定は必要ない。

［３］ＵＲＬ蓄積情報登録が終了した後のＵＲＬ蓄積情報１１３０ｂには、ＩＤ＝５、ＩＤ＝６、及びＩＤ＝７の各レコードに登録されている。
このように、他のメンバについて既に登録されているＵＲＬを登録することもできる。

図２０は、第３の実施の形態のＵＲＬ生成処理の手順を示したフローチャートである。
［ステップＳ２４１］ 候補リスト１１２から宛先を取得する。
［ステップＳ２４２］ ステップＳ２４１で抽出された宛先が、ＵＲＬ蓄積情報１１３の収集先ＵＲＬに登録されているか否かを判定する。未登録であれば、処理をステップＳ２４３に進める。登録されていれば、処理をステップＳ２４９に進める。
［ステップＳ２４３］ 通信ログ１１１から、宛先との間でやり取りされた他のメンバとのメールアドレスを取得する。
［ステップＳ２４４］ ステップＳ２４３で取得したメールアドレスからひとつを選択する。
［ステップＳ２４５］ ステップＳ２４４で取得したメールアドレスを使って、ＵＲＬ蓄積情報１１３からＵＲＬを取得する。すなわち、他のメンバのメールアドレスがユーザ、宛先に所望の宛先のメールアドレスが登録されるＵＲＬを収集先ＵＲＬから検出し、そのＵＲＬを取得する。
［ステップＳ２４６］ ステップＳ２４５で取得されたＵＲＬが、すでにこのユーザについてＵＲＬ蓄積情報１１３に登録されているか否かを判定する。登録されていなければ、処理をステップＳ２４７に進める。登録されていれば、処理をステップＳ２４８に進める。
［ステップＳ２４７］ ＵＲＬをＵＲＬ蓄積情報１１３に登録する。
［ステップＳ２４８］ 他のメンバの全メールアドレスを確認したかどうかを判定する。終了していなければ、ステップＳ２４４に戻って、次のメンバのメールアドレスの処理を行う。
［ステップＳ２４９］ 候補リスト１１２に登録された全候補について処理が終了したかどうかを判定する。終了していなければ、ステップＳ２４１に戻って、候補リスト１１２に登録された次のユーザの処理を行う。全候補について終了していれば、ＵＲＬ生成処理を終了する。

以上の処理手順が実行されることにより、他のメンバについて登録されるＵＲＬが、該ユーザの収集先ＵＲＬに登録される。この結果、電子メールを頻繁にやり取りする相手先と関連が深いと予測されるＵＲＬから情報を定期的に取得できるようになる。なお、必要なくなったと判定されれば、巡回先リストから削除されることは、第１及び第２の実施の形態と同様である。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、情報所在管理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

以上の実施の形態１〜３を含む実施の形態に関し、さらに以下の付記を開示する。
（付記１） ネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法において、
取得先選別手段が、送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する手順と、
情報所在先作成手段が、前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する手順と、
を有することを特徴とする情報所在管理方法。

（付記２） 前記取得先選別手段が前記情報取得先を選別する手順は、前記対象の利用者と少なくとも一往復の前記電子メールの送受信を行った前記相手先が、前記対象の利用者と同じグループに所属する他の利用者との間で一往復以上の前記電子メールの送受信を行ったときは前記情報取得先に選別する、ことを特徴とする付記１記載の情報所在管理方法。

（付記３） 前記取得先選別手段が前記情報取得先を選別する手順は、前記対象の利用者が前記所定の期間に前記電子メールの送受信を一定回数以上行っていなかったとき、前記対象の利用者と同じグループに所属する前記他の利用者と前記相手先との通信状況に基づいて選別を行うことを特徴とする付記２記載の情報所在管理方法。

（付記４） 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記相手先のメールアドレスを取得し、前記メールアドレスからドメイン名を抽出し、前記ドメイン名に基づいて所在先候補を生成するとともに、前記所在先候補が前記ネットワーク上に存在するか否かを判定し、前記所在先候補が存在するときは前記所在先候補を前記情報所在先蓄積手段に記憶する、ことを特徴とする付記１または付記２記載の情報所在管理方法。

（付記５） 前記ドメイン名に基づいて前記所在先候補を生成する手順は、
抽出された前記ドメイン名に所定のスキーム名を付加して前記所在先候補を生成するステップと、
前記所在先候補が前記ネットワーク上に存在するか否かを判定するステップと、
前記スキームを付加して生成した前記所在先候補が存在せず、前記ドメイン名が所定の階層構造を有するときは、最下層に対応する文字列を削除して前記スキーム名を付加して前記所在先候補を生成するステップと、
を有し、前記所在先候補の存在が確認されるか、前記ドメイン名の文字列がなくなるまで前記ドメイン名の最下層に対応する文字列を削除して前記所在先候補を生成するステップと、前記所在先候補が存在するか否かを判定するステップとを繰り返す、ことを特徴とする付記４記載の情報所在管理方法。

（付記６） 前記所在先候補を生成する手順は、前記スキーム名としてＨＴＴＰプロトコルを定義するｈｔｔｐまたはｈｔｔｐｓを用いる、ことを特徴とする付記５記載の情報所在管理方法。

（付記７） 前記所在先候補を生成する手順は、さらに、前記所在先候補が前記ネットワーク上に存在しなかったときは、前記所在先候補の前記スキーム名と前記ドメイン名との間に当該ドメインが提供するサービスに応じた文字列を付加するステップを有することを特徴とする付記５記載の情報所在管理方法。

（付記８） 前記所在先候補を生成する手順は、ドメインが提供するサービスに応じた文字列としてｗｗｗを用いる、ことを特徴とする付記５記載の情報所在管理方法。
（付記９） 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記情報取得先との間で送受信されたメール本文を取得し、前記メール本文に所定の情報所在先が記載されているときは前記所定の情報所在先を読み出し、前記所定の情報所在先が前記メール本文に一定回数以上出現するときは、前記所定の情報所在先を前記情報所在先蓄積手段に記憶する、ことを特徴とする付記１または付記２記載の情報所在管理方法。

（付記１０） 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記情報取得先のメールアドレスを用い、前記対象の利用者と同じグループに属する他のメンバについて前記情報所在先蓄積手段に前記情報取得先のメールアドレスに対応する前記情報所在先情報が登録されていないかどうかを調べ、登録されているときは該情報所在先情報を前記対象の利用者に関連付け、前記情報所在先蓄積手段に登録する、ことを特徴とする付記１または付記２記載の情報所在管理方法。

（付記１１） 情報所在先削除手段が、前記情報所在先蓄積手段に記憶される前記情報所在先情報に関連付けられた前記対象の利用者のメールアドレスと、前記情報取得先の前記メールアドレスとを読み出し、前記メールアドレスに基づいて前記通信ログを検索して前記対象の利用者と前記情報取得先との間で最後に前記電子メールが送受信されてからの経過時間を算出し、算出された前記経過時間が所定の時間を超えていたときは、前記情報所在先蓄積情報に記憶される前記対象の利用者と、前記情報取得先と、前記対象の利用者及び前記情報取得先に関連付けられた前記情報所在先情報と、を前記情報所在先蓄積手段より削除する、ことを特徴とする付記１または付記２記載の情報所在管理方法。

（付記１２） ＲＳＳリーダ登録処理手段が、前記情報所在先蓄積手段に新規の情報所在先情報が登録されたときは、前記新規の情報所在先情報の前記対象の利用者に対応する前記ＲＳＳリーダの巡回先リストに前記新規の情報所在先情報を登録する手順、
を有することを特徴とする付記１または付記２記載の情報所在管理方法。

（付記１３） ネットワーク上に存在する所定の情報の所在を管理する情報所在管理装置において、
送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する取得先選別手段と、
前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する情報所在先作成手段と、
を有することを特徴とする情報所在管理装置。

（付記１４） ネットワーク上に存在する所定の情報の所在を管理するための情報所在管理プログラムにおいて、
コンピュータを、
送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する取得先選別手段、
前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する情報所在先作成手段、
として機能させることを特徴とする情報所在管理プログラム。

実施の形態に適用される発明の概念図である。 実施の形態のシステムの構成例を示した図である。 情報所在管理装置のハードウェア構成例を示すブロック図である。 第１の実施の形態における情報所在管理装置の主要部の機能構成例を示したブロック図である。 通信ログの一例を示した図である。 候補リストの一例を示した図である。 ＵＲＬ蓄積情報の一例を示した図である。 取得先選別処理の具体例を示した図である。 ＵＲＬ生成処理の具体例を示した図である。 ＲＳＳリーダ登録処理後のリスト例を示した図である。 情報所在管理方法における全体の処理手順を示したフローチャートである。 取得先選別処理の手順を示したフローチャートである。 取得先選別処理に選別ルール２を適用したときの手順を示したフローチャートである。 ＵＲＬ生成処理の手順を示したフローチャートである。 ＲＳＳリーダ登録処理の手順を示したフローチャートである。 登録メンテナンス処理の手順を示したフローチャートである。 メール本文から生成されるＵＲＬ情報例を示した図である。 第２の実施の形態のＵＲＬ生成処理の手順を示したフローチャートである。 他のユーザの登録情報から生成されるＵＲＬ情報例を示した図である。 第３の実施の形態のＵＲＬ生成処理の手順を示したフローチャートである。

符号の説明

１ 情報所在管理装置
１ａ 通信ログ記憶手段
１ｂ 情報所在先蓄積手段
１ｃ メール情報取得手段
１ｄ 取得先選別手段
１ｅ 情報所在先作成手段
２ メールサーバ
３ 情報取得装置
４ 外部ネットワーク

Claims (6)

1. ネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法において、
   取得先選別手段が、送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する手順と、
   情報所在先作成手段が、前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する手順と、
   を有することを特徴とする情報所在管理方法。
2. 前記取得先選別手段が前記情報取得先を選別する手順は、前記対象の利用者と少なくとも一往復の前記電子メールの送受信を行った前記相手先が、前記対象の利用者と同じグループに所属する他の利用者との間で一往復以上の前記電子メールの送受信を行ったときは前記情報取得先に選別する、ことを特徴とする請求項１記載の情報所在管理方法。
3. 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記相手先のメールアドレスを取得し、前記メールアドレスからドメイン名を抽出し、前記ドメイン名に基づいて所在先候補を生成するとともに、前記所在先候補が前記ネットワーク上に存在するか否かを判定し、前記所在先候補が存在するときは前記所在先候補を前記情報所在先蓄積手段に記憶する、ことを特徴とする請求項１または請求項２記載の情報所在管理方法。
4. 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記情報取得先との間で送受信されたメール本文を取得し、前記メール本文に所定の情報所在先が記載されているときは前記所定の情報所在先を読み出し、前記所定の情報所在先が前記メール本文に一定回数以上出現するときは、前記所定の情報所在先を前記情報所在先蓄積手段に記憶する、ことを特徴とする請求項１または請求項２記載の情報所在管理方法。
5. 情報所在先削除手段が、前記情報所在先蓄積手段に記憶される前記情報所在先情報に関連付けられた前記対象の利用者のメールアドレスと、前記情報取得先の前記メールアドレスとを読み出し、前記メールアドレスに基づいて前記通信ログを検索して前記対象の利用者と前記情報取得先との間で最後に前記電子メールが送受信されてからの経過時間を算出し、算出された前記経過時間が所定の時間を超えていたときは、前記情報所在先蓄積情報に記憶される前記対象の利用者と、前記情報取得先と、前記対象の利用者及び前記情報取得先に関連付けられた前記情報所在先情報と、を前記情報所在先蓄積手段より削除する、ことを特徴とする請求項１または請求項２記載の情報所在管理方法。
6. ネットワーク上に存在する所定の情報の所在を管理する情報所在管理装置において、
   送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する取得先選別手段と、
   前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する情報所在先作成手段と、
   を有することを特徴とする情報所在管理装置。

Images