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

情報所在管理方法及び情報所在管理装置 Download PDF

Info

Publication number
JP2009230576A
JP2009230576A JP2008076670A JP2008076670A JP2009230576A JP 2009230576 A JP2009230576 A JP 2009230576A JP 2008076670 A JP2008076670 A JP 2008076670A JP 2008076670 A JP2008076670 A JP 2008076670A JP 2009230576 A JP2009230576 A JP 2009230576A
Authority
JP
Japan
Prior art keywords
information
location
mail
destination
url
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008076670A
Other languages
English (en)
Other versions
JP4985509B2 (ja
Inventor
Takehisa Ando
剛寿 安藤
Satoko Shiga
聡子 志賀
Akira Sato
陽 佐藤
Tatsuya Asai
達哉 浅井
Aoshi Okamoto
青史 岡本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008076670A priority Critical patent/JP4985509B2/ja
Priority to US12/409,612 priority patent/US8122025B2/en
Publication of JP2009230576A publication Critical patent/JP2009230576A/ja
Application granted granted Critical
Publication of JP4985509B2 publication Critical patent/JP4985509B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/107Computer-aided management of electronic mailing [e-mailing]

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

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

Description

本発明は情報所在管理方法及び情報所在管理装置に関し、特にネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法及び情報所在管理装置に関する。
近年、コンピュータ及びネットワークシステムの進展に伴って、ネットワーク上に存在する所望の情報を収集することが可能となっている。たとえば、インターネット上のドキュメントシステムとして広く普及しているWWW(World Wide Web)は、現在では世界規模での巨大なWWW網が構築されている。しかし、このように膨大な情報の中から必要な情報を取り出すことは容易ではない。その解決策のひとつとして、ウェブサイト(Webサイト)の情報収集を目的とするRSS(Rich Site Summary)リーダが普及し始めている。RSSリーダは、ウェブサイトを巡回して、RSSで記述されたウェブサイトの更新情報などを自動収集し、収集した情報を表示する機能を有する。利用者は、自らウェブサイトを巡回することなく、ウェブサイトの最新情報を収集することができる。RSSリーダによって、ウェブサイトが提供する情報の収集効率を飛躍的に向上させることができるようになった。
また、情報の所在を管理する方法として、ブラウザが提供するブックマークがある。利用者は、所望のウェブサイトの所在をブックマークに登録しておくことができる。以下、情報資源の所在を指示する記述は、記述方式として最も一般的な、URL(Uniform Resource Locator)を用いるとして説明する。ブックマークにより、すぐに必要なウェブサイトへアクセスすることができるようになる。
しかし、利用者にとって必要な情報は、時間の経過とともに変化する。そこで、ウェブサイトへのアクセス回数を監視し、アクセス回数が所定の追加基準を超えたときはこのウェブサイトのURLをブックマークのリストに載せ、所定の削除基準を下回ったときは削除するアドレス管理方法が知られている(たとえば、特許文献1参照)。また、電子メールの宛先管理方法として、所定の時間単位で受信発信の使用頻度を求め、使用頻度に応じて宛先のアドレスを管理する技術も知られている(たとえば、特許文献2参照)。
特開2002−49541号公報(図9) 特開2002−197027号公報(図2)
しかし、従来の情報所在管理方法では、取得したい情報の所在先を管理するための負担が大きいという問題点があった。
RSSリーダは、指定したウェブサイトからの情報収集には非常に有効であるが、巡回先のウェブサイトを予め利用者が登録しなければならないため、手間がかかるという問題点がある。アクセス回数の高いウェブサイトをブックマークに登録する方法は開示されているが、その前の段階として新たな情報の取得先を発見するのは、利用者自身で行わなければならない。新たな情報の取得先は、たとえば、検索エンジンを用いて検索を行ってウェブサイトを探し出したり、現在リストに登録されているウェブサイトの情報から必要な情報が掲載されているウェブサイトを探し出したりしなければならない。
また、不要になったときは、リストから削除しなければならない。アクセス回数の低いウェブサイトをブックマークから削除する方法は開示されているが、登録先が自動的に巡回され、登録先の情報が収集されるRSSリーダにそのまま適用することは難しい。
利用者にとって取得したい有益な情報は、時間経過とともに変化する。特に、業務に必要な情報は常に変化するため、継続的にリストをメンテナンスすることは非常に難しい。このため、リストのメンテナンスがされず、リストに登録されている巡回先のウェブサイトの情報が不要となっていたり、必要な情報の所在先が登録されていないなど、リストが利用者の状況と離れてしまうことが度々あった。この結果、利用者は有益な情報を得ることができなくなってしまう。
本発明はこのような点に鑑みてなされたものであり、利用者が取得したい情報の所在先に対応する情報所在先情報を適宜更新することができる情報所在管理方法及び情報所在管理装置を提供することを目的とする。
上記課題を解決するために、ネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法が提供される。情報所在管理方法は、取得先選別手段が、送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の通信ログを読み出し、対象の利用者が少なくとも一往復の電子メールの送受信を一定回数以上行った電子メールの相手先を特定して情報取得先に選別する手順と、情報所在先作成手段が、情報取得先との間で送受信された電子メールに含まれる情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する手順と、を有する。
このような情報所在管理方法によれば、取得先選別手段によって、通信ログ記憶手段から所定の期間の電子メールの通信ログが読み出される。そして、通信ログに基づき、対象の利用者が少なくとも一往復の電子メールの送受信を一定回数以上行った相手先が特定され、情報の取得先に選別される。続いて情報所在先作成手段によって、該情報取得先との間で送受信された電子メールに含まれる情報取得先の情報の所在に関連するキー情報が抽出される。そして、キー情報に基づいてこの情報取得先の情報所在先情報が生成され、情報所在先蓄積手段に記憶される。
また、上記課題を解決するために、上記の情報所在管理方法の処理手順を実行する取得先選別手段と、情報所在先作成手段と、を有する情報所在管理装置が提供される。
開示の情報所在管理方法及び情報所在管理装置によれば、通信ログを用いて、対象の利用者が電子メールの送受信を一定回数以上行った情報取得先が選別される。そして送受信された電子メールからキー情報が抽出され、キー情報に基づいて情報取得先に関する情報所在先情報が生成されて情報所在先蓄積手段に記憶される。これにより、電子メールのやり取りを行っている相手先の情報所在先情報が適宜取得され、情報所在先蓄積情報に蓄積される。これを利用することにより、相手先に関連する取得したい情報を容易に取得することができる。
以下、本発明の実施の形態を図面を参照して説明する。
図1は、実施の形態に適用される発明の概念図である。
情報所在管理装置1は、通信ログ記憶手段1a、情報所在先蓄積手段1b、メール情報取得手段1c、取得先選別手段1d、及び情報所在先作成手段1eを有し、外部ネットワーク4に接続するメールサーバ2と、情報取得装置3とに接続する。そして、ネットワーク上に存在する所定の情報の所在を管理する。
通信ログ記憶手段1aには、メールサーバ2を介して送受信された電子メールの通信記録が記憶される。通信記録の中には、対象の利用者が相手先と行った電子メールのやり取りも記録されている。なお、やり取りとは、同一アドレスの相手と電子メールの送受信を一往復以上行うことを表すとする。すなわち、ユーザと相手先でやり取りがあるということは、ユーザから相手先、及び相手先からユーザに電子メールが送受信されたことを言う。
情報所在先蓄積手段1bは、情報所在先作成手段1eによって生成された情報取得先に関する情報所在先を示した情報所在先情報が蓄積される記憶手段である。
メール情報取得手段1cは、メールサーバ2を介して送受信された電子メールの情報を通信ログとして通信ログ記憶手段1aに記憶する。全ての電子メールの送受信はメールサーバ2を介して行われるため、メール情報取得手段1cは送受信された全ての電子メールに関する情報を取得することができる。通信ログには、電子メールの発信元の送信者、宛先の受信者、件名、受信時刻などのほか、必要であればメール本文も保存される。
取得先選別手段1dは、通信ログ記憶手段1aから新着の通信ログを読み出し、対象の利用者が所定の期間に、やり取りした、すなわち、少なくとも一往復以上の電子メールを一定回数以上送受信した相手先を特定し、情報取得先に選別する。所定の期間は、利用者の状況が変わらない期間、たとえば、1週間や10日などが設定される。期間は利用者の状況に応じて適宜決められる。また、業務上の大きな変化があったときなどは、その都度期間が設定されるとしてもよい。一往復以上とするのは、広告メールやスパムメールなどを排除し、利用者が何らかの情報交換を行っている相手先を情報取得先に選別するためである。また、一定回数には、1または2以上の任意の整数が予め登録される。重要な相手先であれば、複数回の電子メールのやり取りがあると予想されることによる。こうして、情報取得先が選別される。また、業務上の相手先であれば、対象利用者との間の電子メールのやり取りの回数が少なくても、対象利用者と同じ部署や会社など、同じグループに所属する他の利用者と電子メールのやり取りを行っている可能性が高い。そこで、対象利用者との間の電子メールの送受信回数が少なくても、他の利用者とやり取りを行っていれば、情報取得先に選別するとしてもよい。また、逆に、相手先と同じグループに属する相手と電子メールのやり取りを行っている場合も、同様に、有益な情報取得先として選別できる。
情報所在先作成手段1eは、選別された情報取得先との間で送受信された電子メールに関する情報、さらに必要に応じて電子メール本文を通信ログ記憶手段1aから読み出す。読み出した電子メールに関する情報に含まれる情報取得先の情報の所在に関連するキー情報を抽出する。そして、抽出されたキー情報に基づいて情報取得先の情報の所在を示す情報所在先情報を生成し、情報所在先蓄積手段1bに記憶する。キー情報には、メールアドレスに含まれるドメイン(domain)名や、電子メール本文に含まれるURLなどの情報所在先情報がある。企業などの組織では、組織の人が使用するメールアドレスに含まれるドメイン名と、その組織に関する情報の所在先を示す情報所在先とは、組織名に対応する部分などの一部が一致する場合が多い。そこで、ドメイン名から情報所在先候補を生成し、情報所在先候補が外部ネットワーク4上に存在するか否かを判定する。存在していれば、情報所在先候補を情報所在先に確定し、その情報所在先情報を情報所在先蓄積手段1bに記憶する。また、同一利用者の電子メールに度々出現する情報所在先は、署名に書かれた所属会社のウェブサイトなど、その利用者と関連が深いものが多いと予想される。そこで、メール本文に一定回数以上出現する情報所在先を相手先の情報所在先に特定し、情報所在先蓄積手段1bに記憶する。
メールサーバ2は、外部ネットワーク4を介して送受信される電子メールを管理する。
情報取得装置3は、所定の周期で、情報所在先蓄積手段1bに記憶される情報所在先に対し外部ネットワーク4を介してアクセスし、提供される情報を収集する。
外部ネットワーク4は、インターネットなどのネットワークで、情報所在先情報を用いて外部ネットワーク4に接続する企業などが提供する情報を収集することができる。
このような構成の情報所在管理装置1による情報所在管理方法の処理手順について説明する。
メール情報取得手段1cは、メールサーバ2を介して送受信された電子メールの情報を取得し、通信ログ記憶手段1aに格納する。取得先選別手段1dは、通信ログ記憶手段1aから新着の通信ログを読み出し、調査対象の利用者が所定の期間に少なくとも一往復以上の電子メールを送受信した相手先を特定する。その相手先との送受信回数が一定回数以上であれば、相手先を情報取得先とする。これは、頻繁に電子メールをやり取りする相手の情報は利用者にとって重要と予想されることに基づく。また、対象利用者との直接の送受信回数が一定回数以上でなくても、対象利用者の属するグループの他の利用者との間で電子メールのやり取りがされていれば、相手先を情報取得先とすることもできる。所定の期間、情報取得先と選別する電子メールの送受信回数、同じグループの他の利用者との電子メール交換を参照するかなどは、予め選別ルールとして決めておいてもよい。
こうして情報取得先が選別されると、情報所在先作成手段1eは、通信ログ記憶手段1aから、情報取得先と送受信された電子メールに関する情報を読み出す。読み出した電子メールに関する情報に含まれる情報取得先の情報の所在に関連するキー情報を抽出する。そして、抽出されたキー情報に基づいて情報取得先の情報の所在を示す情報所在先情報を生成し、情報所在先蓄積手段1bに記憶する。たとえば、電子メールのメールアドレスや、電子メール本文中のURLなどの情報所在先をキー情報として情報所在先を設定する。情報取得装置3は、情報所在先蓄積手段1bに記憶される情報取得先に対し、外部ネットワーク4を介してアクセスし、情報取得先に関する情報を得ることができる。
このような処理が行われることにより、所定期間に一定回数以上電子メールをやり取りした相手の情報所在先情報が情報所在先蓄積手段1bに蓄積される。頻繁に電子メールをやり取りする相手先の情報は重要であると予想されることから、情報所在先蓄積手段1bに自動的に蓄積される情報所在先情報に基づいて取得したい有益な情報を容易に得ることができるようになる。利用者は、情報の所在先を自ら検索して設定する必要がなくなるため、取得したい情報の所在先を管理するための負担を軽減することができる。取得された情報所在先は、ウェブブラウザのブックマークや、RSSリーダの巡回先のウェブサイトの登録などに用いることができる。
以下、実施の形態を、RSSリーダの巡回先リストの管理に適用した場合を例に図面を参照して詳細に説明する。巡回先リストには、RSSリーダが定期的にアクセスして情報を自動収集するウェブサイトのURLが登録される。
図2は、実施の形態のシステムの構成例を示した図である。
実施の形態の情報所在管理装置11は、インターネット40に接続するB社システム10内に配置される。B社システム10は、内部ネットワーク17に情報所在管理装置11、利用者の端末12a,12b、メールサーバ13が、ファイアウォール14を介してDMZ(DeMilitarized Zone)にある公開ウェブサーバ15、メール中継サーバ16と、外部のインターネット40に接続する。また、相手先のA社システム20も同様に、内部ネットワーク27に端末22a,22b、メールサーバ23が、ファイアウォール24を介してDMZにある公開ウェブサーバ25、メール中継サーバ26と、インターネット40に接続する。
メールサーバ13は、メールボックスを管理し、端末12a,12bのメール送受信を監視する。端末12a,12bは、メール処理を行うメーラーと、RSSリーダとを有し、情報所在管理装置11から配信される巡回先リストに基づき、RSSリーダの巡回先を設定する。公開ウェブサーバ15は、インターネット40を介してアクセス可能なウェブサイトを管理する。所定のURLを用いてアクセスすることにより、A社が提供するウェブサイトの情報を取得することができる。メール中継サーバ16は、インターネット40を介して接続する外部の端末22a,22bと、内部ネットワーク17に接続される端末12a,12bとの間で送受信される電子メールを中継する。なお、A社システム20の各装置も同様の機能を有する。
情報所在管理装置11は、内部ネットワーク17に接続する端末12a,12bと外部の端末(たとえば、A社の端末22a,22b)との間でやり取りされるメールを監視し、必要であれば、やり取りされているメールに基づいて、A社の公開ウェブサーバ25が提供する情報のURLを取得し、取得されたURL情報を端末12a,12bのRSSリーダに配信する。また、必要がなくなったと判断されれば、このURLを削除する。
なお、図の例では、ネットワーク上に情報所在管理装置11を設け、取得されたURL情報を各端末12a,12bに配信するとしたが、情報所在管理装置11を端末12a、12bなどに組み込んでおく構成とすることもできる。また、URL情報は、端末12a,12bが必要に応じて情報所在管理装置11から取得するとしてもよい。
ここで、情報所在管理装置11のハードウェア構成について説明する。図3は、情報所在管理装置のハードウェア構成例を示すブロック図である。
情報所在管理装置11は、CPU(Central Processing Unit)101によって装置全体が制御されている。CPU101には、バス107を介してRAM(Random Access Memory)102、ハードディスクドライブ(HDD:Hard Disk Drive)103、グラフィック処理装置104、入力インタフェース105、通信インタフェース106が接続されている。
RAM102には、CPU101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に記憶される。また、RAM102には、CPU101による処理に必要な各種データが記憶される。HDD103には、OSやアプリケーションのプログラムが記憶される。グラフィック処理装置104には、モニタ108が接続されており、CPU101からの命令に従って画像をモニタ108の画面に表示させる。入力インタフェース105には、キーボード109aやマウス109bが接続されており、キーボード109aやマウス109bから送られてくる信号を、バス107を介してCPU101に送信する。通信インタフェース106は、内部ネットワーク17に接続されており、内部ネットワーク17を介して他装置との間でデータの送受信を行う。
このようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図3には、情報所在管理装置11のハードウェア構成を示したが、端末12a,12bなど、図2のシステムにおける他の装置のハードウェア構成も同様である。
次に、情報所在管理装置11の処理機能を実現するソフトウェア構成例について説明する。まず、第1の実施の形態として、情報所在管理装置11全体の処理機能を説明するとともに、メールアドレスに基づいてURLを生成する処理について説明する。
図4は、第1の実施の形態における情報所在管理装置の主要部の機能構成例を示したブロック図である。
第1の実施の形態の情報所在管理装置11の主要部は、記憶部110、取得先選別部120、URL生成部130、URL削除部140、及びRSSリーダ登録部150を有し、RSSリーダ300が巡回する情報所在先のURLが登録される巡回先リストを管理する。
記憶部110には、電子メールの送受信が記録される通信ログ111、取得先選別部120が選別した情報取得先の候補リスト112、及びURL生成部130によって生成されたURLを蓄積するURL蓄積情報113などが記憶される。各情報の詳細は後述する。
取得先選別部120は、相手先特定部121と、候補リスト登録部122とを有し、取得先選別手段1dとして機能する。相手先特定部121は、対象利用者(以下、ユーザとする)について、所定の期間に少なくとも一往復以上の電子メールを送受信した相手先を特定する。候補リスト登録部122は、相手先特定部121によって特定された相手先が、情報取得先の候補となるかどうかを判定する。たとえば、ユーザとの間の電子メールの送受信回数が一定回数以上であればその相手先を情報取得先に選別し、候補リスト112に載せる。また、ユーザが属するグループの他のメンバとの間で一定回数以上の電子メール送受信が行われていれば、その相手先を候補リスト112に載せるとしてもよい。また、その組み合わせでもよい。このような選別のための基準を以下、選別ルールとする。
URL生成部130は、URL候補作成部131と、URL確認登録部132とを有し、情報所在先作成手段1eとして機能する。URL候補作成部131は、取得先選別部120が候補リスト112に設定した情報取得先のメールアドレスを読み出し、ドメイン名を抽出する。そして、ドメイン名を用いて、URLを予測したURL候補を作成する。URL確認登録部132は、URL候補作成部131が作成したURL候補がインターネット上に存在するかどうかを実際にアクセスするなどして判定する。存在が確認できたときは、このURL候補を情報取得先としてURL蓄積情報113に登録する。URL蓄積情報113には、URLがユーザと特定された情報取得先と関連付けて記憶される。
URL削除部140は、送受信状況確認部141と、削除判定部142とを有し、URL蓄積情報113に登録されているが、電子メールでのやり取りがなくなった情報取得先のURLをURL蓄積情報113から削除する。送受信状況確認部141は、通信ログ111を読み出し、URL蓄積情報113に登録されたユーザと情報取得先との間で電子メールの送受信が行われているかどうか、送受信状況を確認する。削除判定部142は、送受信状況確認部141の確認結果に基づいて、所定の期間送受信がされていなければ、URL蓄積情報113から対応するURL登録レコードを削除する。また、必要に応じてRSSリーダ300の巡回先リストからも削除する。
RSSリーダ登録部150は、記憶部110に記憶されるURL蓄積情報113に基づいて、各端末12a,12bのRSSリーダ300の巡回先が登録される巡回先リストを更新する。
ここで、記憶部110に記憶される情報について説明する。図5は、通信ログの一例を示した図である。
通信ログ1110は、送信者のメールアドレス1112、宛先である受信者のメールアドレス1113、件名1114、及び日付1115の情報項目を有する。なお、説明のため各レコードには、識別のためのID1111を付与している。
ここで、一往復の電子メールとは、件名1114が同じ少なくとも一組の電子メールで、かつ、一方の送信者1112と宛先1113のメールアドレスが他方では宛先1113と送信者1112になっている組み合わせを言う。たとえば、点線で結ばれているID=1は、A1@a.co.jpからB1@b.co.jpに送信された件名「S1」の電子メールである。ID=2は、逆に、B1@b.co.jpからA1@a.co.jpに送信された件名「S1」の電子メールである。このような通信ログのID=1に記録される電子メールと、ID=2に記録される電子メールは、一往復の電子メールである。図では、このような電子メールの組を点線1116で結んでいる。
図6は、候補リストの一例を示した図である。
候補リスト1120には、取得先選別部120によって情報取得先として選別された相手先のアドレスが登録されている。ユーザ1122及び宛先1123の情報項目を有する。各レコードにID1121を付与していることは通信ログ1110と同様である。ユーザ1122は、ユーザのメールアドレスが登録される。ここでは、B社システム10内をユーザとしているので、ユーザはBn(nは任意の整数)によって表す。宛先1123には、情報取得先として選別された相手先のメールアドレスが登録される。
図7は、URL蓄積情報の一例を示した図である。
URL蓄積情報1130には、URL生成部130によって生成された情報取得先のURLが登録されている。ユーザ1132、宛先1133、及び収集先URL1134の情報項目を有する。各レコードにID1131を付与していることは通信ログ1110と同様である。また、ユーザ1132及び宛先1133は、候補リスト1120のユーザ1122及び宛先1123と同じである。収集先URL1134には、URL生成部130が、宛先1123のメールアドレスに基づいて生成され、存在が確認されたURLが登録される。
以下、上記の記憶部110に記憶される各情報を用いて、取得先選別部120、URL生成部130、RSSリーダ登録部150、及びURL削除部140において実行される処理手順を詳細に説明する。
取得先選別部120では、通信ログ1110に基づいてユーザが頻繁に電子メールをやり取りする相手先を特定し、所定の条件を満たした相手先を情報取得先に選別する。ここでは、選別ルール1及び選別ルール2の2つの場合について説明する。選別ルール1は、所定の期間に、ユーザと相手先との間で直接やり取りされた電子メールの送受信回数に基づいて選別を行うとする。たとえば、「1週間以内の直接のメールのやり取り回数が2回以上」というルールである。また、選別ルール2は、ユーザに加え、ユーザと同じグループに属する他のメンバとの通信状況も加味して選別を行うとする。たとえば、「1週間以内の直接のメールのやり取りがあり、他のユーザとのやり取り回数が2回以上」というルールである。
図8は、取得先選別処理の具体例を示した図である。[A]は選別ルール1が適用された場合、[B]は選別ルール2が適用された場合を示している。ここでは、ユーザをB1(ユーザのメールアドレスは、B1@b.co.jp)として説明する。
[A]選別ルール1「1週間以内の直接のメールのやり取り回数が2回以上」が適用された場合は、通信ログ1110から、11月28日から過去1週間以内にユーザB1(B1@b.co.jp)とやり取りを行った相手先が抽出される。ID=1とID=2には、件名「S1」について宛先「A1@a.co.jp」とやり取りをしたことが記録されている。ID=4とID=5には、件名「S3」について宛先「A1@a.co.jp」とやり取りをしたことが記録されている。ID=6とID=7には、件名「S4」について宛先「A2@a.co.jp」とやり取りをしたことが記録されている。ID=8とID=13には、件名「S5」について宛先「A1@a.co.jp」とやり取りをしたことが記録されているが、一週間以内という条件は満たさない。以上より、宛先として「A1@a.co.jp」と、「A2@a.co.jp」とが抽出される。さらに、ユーザ「B1@b.co.jp」と「A1@a.co.jp」との送受信回数は2回であり、2回以上という条件を満たすので、「A1@a.co.jp」は、候補リストに登録される。しかし、ユーザ「B1@b.co.jp」と「A2@a.co.jp」との送受信回数は1回であり、2回以上という条件を満たさないので、「A2@a.co.jp」は、候補リストに登録されない。以上より、候補リスト(選別ルール1)1120aには、ユーザ「B1@b.co.jp」に対して宛先「A1@a.co.jp」が登録される。
なお、件名の一致は、部分一致とする。実際には、送受信される電子メールの件名が必ずしも一致しない。たとえば、応答を示す「RE:」が付加されたりする。そこで、ある程度一致すれば、同じ件名であるとみなす。件名の文字列を形態素分析し、一致する文字列が全体の文字列に含まれる割合が一定値を超えるものを同じ件名と見なすとしてもよい。
[B]選別ルール2「1週間以内の直接のメールのやり取りがあり、他のユーザとのやり取り回数が2回以上」が適用された場合は、同様にして、宛先として「A1@a.co.jp」と、「A2@a.co.jp」とが抽出される。このうち、「A1@a.co.jp」については、1週間以内にB1と同じグループの他のユーザ(B2,B3)と通信を行っていない。このため、候補リスト(選別ルール2)1120bには、登録されない。一方、「A2@a.co.jp」については、ID=9とID=10に、件名「S6」についてユーザ「B2@b.co.jp」とやり取りをしたことが記録されている。同様に、ID=11とID=12に、件名「S7」についてユーザ「B3@b.co.jp」とやり取りをしたことが記録されている。したがって、選別ルール2を満たす。この場合、候補リストには、やり取りを行った全てのユーザを登録する。以上より、候補リスト(選別ルール2)1120bには、ユーザ「B1@b.co.jp」、ユーザ「B2@b.co.jp」、ユーザ「B3@b.co.jp」に対して宛先「A2@a.co.jp」が登録される。
このように、選別ルールに基づいて、情報所在先の候補リストが登録される。なお、選別ルールは、参照される期間、やり取り回数、他のユーザとのやり取りを参照するか、などを適用システムに応じて適宜設定される。また、たとえば、選別ルール1と選別ルール2を組み合わせ、いずれかに適合する宛先を候補としてもよい。
以上の処理手順により、候補リスト1120が生成され、処理がURL生成部130に引き継がれる。
図9は、URL生成処理の具体例を示した図である。図の例では、候補リスト1120に、情報所在先として宛先「A1@a3.a2.a1.com」が設定されたとする。以下、次の手順を実行する。
[1]最初に、宛先のメールアドレスからドメイン名を抽出する。@マークの次がドメイン名であり、ここでは「a3.a2.a1.com」200が抽出される。
[2]抽出されたドメイン名「a3.a2.a1.com」200に、スキームを付加する。スキームには、たとえば、一般的な、HTTPプロトコルを定義する「http://」と「https://」を用いる。これにより、URL候補、「http://a3.a2.a1.com」211と、「https://a3.a2.a1.com」212が作成される。
こうして生成されたURL候補がインターネット40上に存在するか否かを判定する。このURLにアクセスし、アクセスできるかどうかによって存在の有無を判定する。アクセスできれば、このURL候補をURL蓄積情報1130に登録する。アクセスできなければ、次のURL候補を生成する。
[3]次のURL候補は、ドメインが提供するサービスに応じた文字列を前の候補のドメイン名の最左に付加する。情報収集の対象となるウェブサイトが提供するサービスはwwwであるので、「www.」を付加する。ここでは、「http://a3.a2.a1.com」211と、「https://a3.a2.a1.com」212に「www.」を付加し、「http://www.a3.a2.a1.com」221と、「https://www.a3.a2.a1.com」222が作成される。このURLにアクセスし、アクセスできるかどうかを確認し判定を行う。アクセスできれば、このURL候補をURL蓄積情報1130に登録する。アクセスできなければ、次のURL候補を生成する。
[4]次のURL候補は、ドメイン名の一部を削除して生成する。一般に、組織名に応じたドメイン名は所定の階層構造を有することが知られており、最も左側が組織の最下層になる。そこで、最下層に対応する文字列を削除してURL候補を生成する。上位の階層に行くほど、URLが存在する可能性が高くなると予想される。ここでは、前の候補の「www.」と、ドメイン名の最左から「.(ピリオド)」までを削除する。図の例では、「http://www.a3.a2.a1.com」221と、「https://www.a3.a2.a1.com」222から「www.」と「a3.」が削除され、「http://a2.a1.com」231と、「https://a2.a1.com」232が作成される。このURLにアクセスし、アクセスできれば、このURL候補をURL蓄積情報1130に登録する。アクセスできなければ、次のURL候補を生成する。
[5]次のURL候補は、前の候補のドメイン名の最左に「www.」を付加する。ここでは、「http://a2.a1.com」231と、「https://a2.a1.com」232に「www.」を付加し、「http://www.a2.a1.com」241と、「https://www.a2.a1.com」242が作成される。このURLにアクセスし、アクセスできるかどうかを確認し存在有無の判定を行う。アクセスできれば、このURL候補をURL蓄積情報1130に登録する。アクセスできなければ、次のURL候補を生成する。
[6]次のURL候補は、前の候補の「www.」と、ドメイン名の最左から「.」までを削除する。図の例では、「http://www.a2.a1.com」241と、「https://www.a2.a1.com」242から「www.」と「a2.」が削除され、「http://a1.com」251と、「https://a1.com」252が作成される。このURLにアクセスし、アクセスできるかどうかを確認し、存在有無の判定を行う。アクセスできれば、このURL候補をURL蓄積情報1130に登録する。アクセスできなければ、次のURL候補を生成する。
[7]次のURL候補は、前の候補のドメイン名の最左に「www.」を付加する。ここでは、「http://a1.com」251と、「https://a1.com」252に「www.」を付加し、「http://www.a1.com」261と、「https://www.a1.com」262が作成される。このURLにアクセスし、アクセスできるかどうかを確認して存在有無の判定を行う。アクセスできれば、このURL候補をURL蓄積情報1130に登録する。アクセスできない場合、これ以上の削除はできないので、URL生成を中止する。
以上のように、メールアドレスから抽出されたドメイン名を用いて、URL候補が生成され、インターネット40上に存在があることが判定されれば、このURL候補がURL蓄積情報1130に登録される。
こうしてURL蓄積情報1130に登録されたURLは、RSSリーダ300に配信される。RSSリーダ登録部150では、URL蓄積情報1130に新たに登録されたURLをRSSリーダ300に登録する。
図10は、RSSリーダ登録処理後のリスト例を示した図である。
図の例では、図7に示したURL蓄積情報1130に登録されるID=1のユーザ「B1@b.co.jp」、収集先URL「http://a.co.jp」と、ID=2のユーザ「B2@b.co.jp」、収集先URL「http://a.co.jp」とが新規登録であったとしている。
RSSのリストは、ユーザB1のリスト310を例にとると、サイトのタイトル310a、そのサイトの情報所在先を示すURL310b、及び取得した情報を保存する保存先フォルダ310cの情報項目を有する。これは、ユーザB2でも同様である。
RSSリーダ登録部150は、ユーザB1とユーザB2のRSSリーダ300のリストに、「http://a.co.jp」が登録されていなければ、これを登録する。サイトのタイトルは、電子メールのアドレス情報などから取得できるのであれば、これを用いる。これにより、ユーザB1のリスト310には、「株式会社A社」のURL「http://a.co.jp」311が新たに登録される。同様に、ユーザB2のリスト320には、「株式会社A社」のURL「http://a.co.jp」321が新たに登録される。
各ユーザのRSSリーダ300は、新規登録された「株式会社A社」のURL「http://a.co.jp」を自動巡回サイトに加え、情報収集を行う。こうして、頻繁に電子メールのやり取りを行う相手先に関する情報が自動的に収集されるようになる。
ところで、業務の変化とともに、情報を取得したい宛先のリストに登録されていた相手先の情報を必要としなくなる場合がある。このような場合には、その相手先との電子メールのやり取りもなくなると予想される。URL削除部140では、電子メールの送受信状況を確認し、一定期間やり取りがされていなければ、URL蓄積情報1130から宛先を削除する。必要に応じてRSSリーダ300の巡回先リストからも削除する。
たとえば、図7に示したURL蓄積情報1130のID=1には、ユーザ「B1@b.co.jp」、宛先「A1@a.co.jp」に対応付けられて収集先URL「http://a.co.jp」が登録されている。URL削除部140では、通信ログ1110を検索し、ユーザ「B1@b.co.jp」、宛先「A1@a.co.jp」の組み合わせで電子メールが送受信されているかどうかをチェックする。ここでは、「10日間電子メールが送受信されていなければ削除」という設定がされているとする。なお、削除するための期限は任意に設定される。通信ログ1110には、10日以内に、ユーザ「B1@b.co.jp」と宛先「A1@a.co.jp」との間で電子メールの送受信が行われたことが記録されている(たとえば、ID=1とID=2)。したがって、この登録レコードは維持する。同様の手順でURL蓄積情報1130の登録を順次調べていくと、ID=5のユーザ「B2@b.co.jp」と宛先「C1@xxx.co.jp」との電子メールの送受信は、通信ログ1110から検出されない。最後にユーザ「B2@b.co.jp」と、宛先「C1@xxx.co.jp」との間で送受信された電子メールは、10日以上前であると判定されるので、URL蓄積情報1130からID=5のレコードを削除する。また、ユーザB2のRSSリーダの対応する巡回リストの登録も削除する。これにより、電子メールのやり取りが所定の期間行われていない相手先が、情報の収集先から削除される。
なお、URL削除部140は、各ユーザのRSSリーダの巡回先リストを自動で削除するのではなく、一定期間電子メールのやり取りがされていない相手先であることをユーザに通知し、登録削除を承認するか否かを問い合わせてから削除するとしてもよい。
次に、情報所在管理装置11によって実行される情報所在管理方法の処理手順についてフローチャートを用いて説明する。
図11は、情報所在管理方法における全体の処理手順を示したフローチャートである。
所定の周期で処理が開始される。
[ステップS01] 電子メールの送受信が記録されている通信ログ111を用いて、情報取得先を選別する取得先選別処理を行う。選別された情報取得先の候補リスト112が作成される。
[ステップS02]ステップS01の取得先選別処理で生成された候補リスト112に基づいて、情報取得先のURLを生成するURL生成処理を行う。情報収集先のURLが蓄積されたURL蓄積情報113に生成されたURLが登録される。
[ステップS03] URL蓄積情報113に基づいて、該当するユーザのRSSリーダの巡回先リストに新たに検出されたURLを登録する。
[ステップS04] URL蓄積情報113に登録されている宛先との間の電子メール通信状況を調べる。一定期間電子メールが送受信されていなければ、URL蓄積情報113から該当のレコードを削除する登録メンテナンス処理を行う。このとき、ユーザのRSSリーダの登録更新も行われる。
なお、上記の処理手順では、登録メンテナンス処理(ステップS04)を、新規の情報所在先を登録するためのステップS01からステップS03の後に続けて行うとしたが、別のタイミングで実行させるとしてもよい。
続いて、各処理の詳細を説明する。
図12は、取得先選別処理の手順を示したフローチャートである。ここでは、まず、検出された宛先に選別ルール1(ユーザと相手先との直接のやり取りが一定回数以上)を適用し、選別ルール1が満たされなかった宛先についてさらに、選別ルール2(ユーザと直接のやり取りがあり、ユーザと同じグループに属する他のメンバとのやり取り回数が一定回数以上)が成立するかを判定する処理を行う。なお、選別ルール2の処理手順は、図13に示している。
[ステップS101] 通信ログ111から未処理の新着メールに関する送受信状況の記録を取得する。
[ステップS102] 取得された新着メールの送受信状況記録に基づき、通信記録のあるユーザを対象として宛先を抽出する。対象のユーザと少なくとも一往復以上の電子メールの送受信を行っている相手先の宛先を抽出し、この宛先が候補リスト112またはURL蓄積情報113に登録済みであるかどうかを判定する。登録済みでないときは、処理をステップS103に進める。登録済みであれば、処理をステップS106に進める。
[ステップS103] 所定期間の通信ログを抽出し、対象のユーザと宛先との間で電子メールが送受信された回数を算出する。
[ステップS104] ステップS103で算出された送受信回数が一定回数以上であるかどうかを判定する。一定回数以上であれば、処理をステップS105に進める。一定回数以上でなければ、図13に示した分岐点Aへ処理を進める。
[ステップS105] 対象ユーザと、抽出された宛先との間で電子メールが一定回数以上送受信されていたので、宛先を候補リスト112に追加する。
[ステップS106] この宛先に関する処理が終了したので、全新着メールについて処理が終了したかどうかを判定する。全新着メールが終了していれば、処理を終了する。終了していないときは、ステップS102に戻って、次の宛先を抽出処理からの手順を行う。
図13は、取得先選別処理に選別ルール2を適用したときの手順を示したフローチャートである。図12の分岐点Aからの続きの処理が開始される。
[ステップS111] 通信ログから所定期間における宛先と、ユーザと同じグループに属する他のユーザとの間の電子メールの送受信に関する記録を取得する。
[ステップS112] 他のユーザと宛先との間で電子メールが送受信された回数を算出する。
[ステップS113] ステップS112で算出された他のユーザと宛先との間における電子メールの送受信回数が一定回数以上であるかどうかを判定する。一定回数以上であれば、処理をステップS114に進める。一定回数以上でなければ、図12の分岐点Bへ処理を進める。
[ステップS114] 対象ユーザと同一グループの他のユーザと、抽出された宛先との間で電子メールが一定回数以上送受信されていたので、他のメンバもユーザに加え、ユーザと宛先とを候補リスト112に追加する。図12の分岐点Bに戻って、全新着メールのチェックが終わったかどうかの判定からの処理を行う。
以上の処理手順が実行されることにより、選別ルールに基づいて、情報の取得対象となる情報所在先が候補リストに登録される。
図14は、URL生成処理の手順を示したフローチャートである。
[ステップS201] 候補リスト112を読み出し、宛先を取得する。
[ステップS202] URL蓄積情報113と照合し、このユーザと宛先とに対応する収集先URLが登録されているか、未登録であるかを判定する。未登録であれば、処理をステップS203に進める。登録されていれば、処理をステップS211に進める。
[ステップS203] 候補リスト112から宛先のメールアドレスを抽出する。
[ステップS204] ステップS203で抽出された宛先のメールアドレスからドメイン名を抽出する。ドメイン名は、メールアドレスの@マーク以降の文字列を言う。
[ステップS205] ドメイン名にスキームを追加し、URL候補を生成する。スキームには、たとえば、HTTPプロトコルを定義する「http://」や「https://」を用いる。
[ステップS206] ステップS205で生成されたURL候補を用いて、このURLにアクセスが可能であるかどうかをチェックする。アクセス不可であれば、処理をステップS207に進める。アクセス可であれば、処理をステップS212に進める。
[ステップS207] ステップS205で生成されたURL候補を用いたアクセスが不可であったときは、ドメイン名の最左に「www.」を付加する。
[ステップS208] ステップS207で生成されたURL候補を用いて、このURLにアクセスが可能であるかどうかをチェックする。アクセス不可であれば、処理をステップS209に進める。アクセス可であれば、処理をステップS212に進める。
[ステップS209] ステップS207で生成されたURL候補を用いたアクセスが不可であったときは、ドメイン名の最左をピリオドまで削除する。これにより、ドメイン名の最下層が削除される。
[ステップS210] ステップS209による先所処理によって文字列が残っているかどうかを判定する。残っていないときはURL生成を中止してステップS211に処理を進める。残っているときは処理をステップS205に進め、ステップS209で修正されたドメイン名を用いて、処理を繰り返す。
[ステップS211] 候補リスト112に登録された全候補の処理が終了したかどうかを判定する。終了していなければ、ステップS201に戻って次の宛先の処理を行う。全候補終了していれば、処理を終了する。
[ステップS212] 生成されたURL候補がネットワーク上に存在することが確認されたので、このURL候補をURL蓄積情報113に登録する。
以上の処理手順が実行されることにより、電子メールの送受信記録に基づいて候補リストに登録された相手先のURLが生成され、URL蓄積情報113に蓄積される。
図15は、RSSリーダ登録処理の手順を示したフローチャートである。
[ステップS301] URL蓄積情報113に新規追加されたURLのひとつを選択する。
[ステップS302] ステップS301で選択されたURLが該ユーザのRSSリーダの巡回先リストに登録されているかどうかを判定する。未登録であれば、処理をステップS303に進める。登録されていれば、処理をステップS304に進める。
[ステップS303] 未登録であれば、ステップS301で選択されたURLをRSSリーダの巡回先リストに登録する。
[ステップS304] URL蓄積情報113に新規登録されたURLについての処理がすべて終了したか否かを判定する。終了していなければ、処理をステップS301に進め、次の新規登録URLについての処理を行う。終了していれば、処理を終了する。
以上の処理手順が実行されることにより、各ユーザのRSSリーダに、電子メールでのやり取りを頻繁に行っている相手に関する情報を収集することが可能となる。
こうして登録されたURL蓄積情報113及びRSSリーダの巡回先リストに登録されるURLも時間経過とともに不要となる場合がある。
図16は、登録メンテナンス処理の手順を示したフローチャートである。
[ステップS401] URL蓄積情報からデータをひとつ読み出し、ユーザ及び宛先のメールアドレスを取得する。
[ステップS402] 通信ログ111を読み出し、ステップS401で取得されたユーザと宛先との間で電子メールの送受信が行われているかどうか、メール送受信状況を取得する。
[ステップS403] メール送受信状況に基づいて、ステップS401で読み出されたユーザのメールアドレスと、宛先のメールアドレスとの間でやり取りが行われた最新の日付を抽出する。そして、最後の電子メールのやり取りからの経過日数を算出する。
[ステップS404] 経過日数が所定の日数(図では、d日としている)未満であるかどうかを判定する。所定の日数以上であれば、処理をステップS405に進める。所定の日数未満であれば、処理をステップS407に進める。
[ステップS405] 最後のやり取りからの経過日数が、所定の日数以上であれば、対象ユーザのRSSリーダの登録から該当URLを削除する。
[ステップS406] 続けて、URL蓄積情報113から該当レコードを削除する。これにより、対象ユーザについてURL蓄積情報113に登録された宛先と収集先URLとが削除される。
[ステップS407] 全登録URLについて処理が終わったかどうかを判定する。終わっていないときは、処理をステップS401に戻し、次のURL登録のメンテナンスを行う。全登録URLのメンテナンスが終わっていれば、処理を終了する。
以上の処理手順が実行されることにより、一定期間電子メールのやり取りがされなくなった宛先に関するURLの登録が削除される。これにより、RSSリーダの巡回先リストから不要な巡回先が削除される。
次に、第2の実施の形態について説明する。第1の実施の形態では、URL生成部130において相手先のメールアドレスを用いるとしたが、第2の実施の形態ではメール本文を用いる。なお、第2の実施の形態における情報所在管理装置が有する処理機能の構成要素は、図4に示した第1の実施の形態の構成要素と同様である。そこで、図4に示した構成要素の符号を用いて、第2の実施の形態における機能を説明する。
ただし、URL生成部130については、第1の実施の形態と異なる処理が行われる。第2の実施の形態では、URL候補作成部131は、メール本文に記載されているURLを抽出し、これをURL候補とする。メール本文中に記載されているURLは実在のURLであるので、URL確認登録部132では同じURLが一定回数以上出現していれば、これを情報所在先としてURL蓄積情報113に登録する。
具体例を用いて説明する。図17は、メール本文から生成されるURL情報例を示した図である。
URL生成部130は、ユーザと相手先との間でやり取りされた電子メール本文を取得する。図の電子メール410、420が取得された電子メールの一例である。電子メール410,420は、ユーザ(図2のB社システム10側の利用者)が、相手先(図2のA社システム20側の利用者)から受け取った電子メールである。相手先であって、Aシステム側の利用者のメールアドレスは、図6の候補リスト1120に示したように、「宛先」に登録されている。電子メール410には、署名情報として、相手先(候補リスト112の「宛先」、以下同様)であるA1の所属する組織のURL411が記載されている。同様に、他の電子メール420にもA1の所属する組織のURL421が記載されている。このように、同一の相手先から取得される電子メールに度々出現するURLは、相手先の所属会社のウェブサイトなど、関連が深いものであると予想できる。したがって、このURLを抽出し、情報所在先としてURL蓄積情報113に設定すれば、有益な情報所在先が登録される。
図18は、第2の実施の形態のURL生成処理の手順を示したフローチャートである。
[ステップS221] 電子メールの相手先として、候補リスト112の「宛先」に登録される宛先アドレスを取得する。
[ステップS222] ステップS221で抽出された相手先(宛先アドレス)が、URL蓄積情報113の収集先URLに登録されているか否かを判定する。未登録であれば、処理をステップS223に進める。登録されていれば、処理をステップS227に進める。
[ステップS223] 通信ログ111から、ユーザと、相手先(宛先アドレス)との間でやり取りされた電子メールを取得する。
[ステップS224] ステップS223で取得した電子メール本文に出現したURLを抽出し、その出現回数をカウントする。複数の電子メールから検出されたときは、すべてを合算する。
[ステップS225] ステップS224で算出された出現回数が所定回数以上であるかどうかを判定する。所定回数以上であれば、処理をステップS226に進める。所定回数に達していなければ、処理をステップS227に進める。
[ステップS226] 一定回数以上出現したURLを、ユーザ、該宛先アドレスに関連付け、URL蓄積情報113に登録する。
[ステップS227] 候補リスト112に登録される全候補の処理が終了したかどうかを判定する。終了していなければ、ステップS221に戻って、次の候補の処理を行う。全候補終了していれば、URL作成処理を終了する。
以上の処理手順が実行されることにより、電子メールを頻繁にやり取りする相手先の電子メールに度々出現するURLをURL蓄積情報113に登録することができる。URL蓄積情報113に登録されたURLは、RSSリーダ登録部150によってRSSリーダ300の巡回先リストに登録することができる。この結果、電子メールを頻繁にやり取りする相手先と関連が深いと予測されるURLから情報を定期的に取得できるようになる。なお、必要なくなったと判定されれば、巡回先リストから削除されることは、第1の実施の形態と同様である。
次に、第3の実施の形態について説明する。第3の実施の形態では、URL生成の基とする情報として、他メンバのURL登録情報を用いる。なお、第3の実施の形態における情報所在管理装置が有する処理機能の構成要素は、図4に示した第1の実施の形態の構成要素と同様である。そこで、図4に示した構成要素の符号を用いて、第3の実施の形態における機能を説明する。ただし、情報取得先URL生成部130については、第1の実施の形態及び第2の実施の形態と異なる処理が行われる。
第3の実施の形態では、候補リスト112に登録された候補のURLが、ユーザと同じグループに属する他のメンバに関連付けてURL蓄積情報113に登録されているときは、このURL蓄積情報113に登録されるURLを読み出す。そして、読み出したURLを、該ユーザと相手先とに対応付けてURL蓄積情報113に登録する。
図19は、他のユーザの登録情報から生成されるURL情報例を示した図である。
[1]候補リスト取得処理では、候補リスト1120cを取得する。図の例では、URL生成部130が取得した候補リスト1120cには、ユーザ「B1@b.co.jp」と、宛先「A5@a.co.jp」とが記憶されている。
次に、[2」URL蓄積情報取得処理では、URL生成部130は、宛先「A5@a.co.jp」について、URL蓄積情報1130aに、「A5@a.co.jp」が宛先に登録される他のメンバ「B2@b.co.jp」、「B3@b.co.jp」、「B4@b.co.jp」、「B5@b.co.jp」が検出される。利用者B2,B3,B4,B5は、ユーザB1(メールアドレスは、B1@b.co.jp」と同じグループに所属する。したがって、これらのユーザと、宛先「A5@a.co.jp」とに対応付けられた収集先URL、「http://a.co.jp」、「http://a/a.co.jp」、「http://aaa.a/co.jp」がURL蓄積情報1130aより抽出される。重複するものは省いている。そして、これらのURLがユーザ「B1@b.co.jp」と、宛先「A5@a.co.jp」とに関連付けられ、ユーザの収集先URLとして登録される。なお、既に他のメンバについて登録されているURLであるので、ネットワーク上に存在するかどうかの判定は必要ない。
[3]URL蓄積情報登録が終了した後のURL蓄積情報1130bには、ID=5、ID=6、及びID=7の各レコードに登録されている。
このように、他のメンバについて既に登録されているURLを登録することもできる。
図20は、第3の実施の形態のURL生成処理の手順を示したフローチャートである。
[ステップS241] 候補リスト112から宛先を取得する。
[ステップS242] ステップS241で抽出された宛先が、URL蓄積情報113の収集先URLに登録されているか否かを判定する。未登録であれば、処理をステップS243に進める。登録されていれば、処理をステップS249に進める。
[ステップS243] 通信ログ111から、宛先との間でやり取りされた他のメンバとのメールアドレスを取得する。
[ステップS244] ステップS243で取得したメールアドレスからひとつを選択する。
[ステップS245] ステップS244で取得したメールアドレスを使って、URL蓄積情報113からURLを取得する。すなわち、他のメンバのメールアドレスがユーザ、宛先に所望の宛先のメールアドレスが登録されるURLを収集先URLから検出し、そのURLを取得する。
[ステップS246] ステップS245で取得されたURLが、すでにこのユーザについてURL蓄積情報113に登録されているか否かを判定する。登録されていなければ、処理をステップS247に進める。登録されていれば、処理をステップS248に進める。
[ステップS247] URLをURL蓄積情報113に登録する。
[ステップS248] 他のメンバの全メールアドレスを確認したかどうかを判定する。終了していなければ、ステップS244に戻って、次のメンバのメールアドレスの処理を行う。
[ステップS249] 候補リスト112に登録された全候補について処理が終了したかどうかを判定する。終了していなければ、ステップS241に戻って、候補リスト112に登録された次のユーザの処理を行う。全候補について終了していれば、URL生成処理を終了する。
以上の処理手順が実行されることにより、他のメンバについて登録されるURLが、該ユーザの収集先URLに登録される。この結果、電子メールを頻繁にやり取りする相手先と関連が深いと予測されるURLから情報を定期的に取得できるようになる。なお、必要なくなったと判定されれば、巡回先リストから削除されることは、第1及び第2の実施の形態と同様である。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、情報所在管理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
プログラムを流通させる場合には、たとえば、そのプログラムが記録されたDVD(Digital Versatile Disc)、CD−ROM(Compact Disc Read Only Memory)などの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
以上の実施の形態1〜3を含む実施の形態に関し、さらに以下の付記を開示する。
(付記1) ネットワーク上に存在する所定の情報の所在を管理する情報所在管理方法において、
取得先選別手段が、送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する手順と、
情報所在先作成手段が、前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する手順と、
を有することを特徴とする情報所在管理方法。
(付記2) 前記取得先選別手段が前記情報取得先を選別する手順は、前記対象の利用者と少なくとも一往復の前記電子メールの送受信を行った前記相手先が、前記対象の利用者と同じグループに所属する他の利用者との間で一往復以上の前記電子メールの送受信を行ったときは前記情報取得先に選別する、ことを特徴とする付記1記載の情報所在管理方法。
(付記3) 前記取得先選別手段が前記情報取得先を選別する手順は、前記対象の利用者が前記所定の期間に前記電子メールの送受信を一定回数以上行っていなかったとき、前記対象の利用者と同じグループに所属する前記他の利用者と前記相手先との通信状況に基づいて選別を行うことを特徴とする付記2記載の情報所在管理方法。
(付記4) 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記相手先のメールアドレスを取得し、前記メールアドレスからドメイン名を抽出し、前記ドメイン名に基づいて所在先候補を生成するとともに、前記所在先候補が前記ネットワーク上に存在するか否かを判定し、前記所在先候補が存在するときは前記所在先候補を前記情報所在先蓄積手段に記憶する、ことを特徴とする付記1または付記2記載の情報所在管理方法。
(付記5) 前記ドメイン名に基づいて前記所在先候補を生成する手順は、
抽出された前記ドメイン名に所定のスキーム名を付加して前記所在先候補を生成するステップと、
前記所在先候補が前記ネットワーク上に存在するか否かを判定するステップと、
前記スキームを付加して生成した前記所在先候補が存在せず、前記ドメイン名が所定の階層構造を有するときは、最下層に対応する文字列を削除して前記スキーム名を付加して前記所在先候補を生成するステップと、
を有し、前記所在先候補の存在が確認されるか、前記ドメイン名の文字列がなくなるまで前記ドメイン名の最下層に対応する文字列を削除して前記所在先候補を生成するステップと、前記所在先候補が存在するか否かを判定するステップとを繰り返す、ことを特徴とする付記4記載の情報所在管理方法。
(付記6) 前記所在先候補を生成する手順は、前記スキーム名としてHTTPプロトコルを定義するhttpまたはhttpsを用いる、ことを特徴とする付記5記載の情報所在管理方法。
(付記7) 前記所在先候補を生成する手順は、さらに、前記所在先候補が前記ネットワーク上に存在しなかったときは、前記所在先候補の前記スキーム名と前記ドメイン名との間に当該ドメインが提供するサービスに応じた文字列を付加するステップを有することを特徴とする付記5記載の情報所在管理方法。
(付記8) 前記所在先候補を生成する手順は、ドメインが提供するサービスに応じた文字列としてwwwを用いる、ことを特徴とする付記5記載の情報所在管理方法。
(付記9) 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記情報取得先との間で送受信されたメール本文を取得し、前記メール本文に所定の情報所在先が記載されているときは前記所定の情報所在先を読み出し、前記所定の情報所在先が前記メール本文に一定回数以上出現するときは、前記所定の情報所在先を前記情報所在先蓄積手段に記憶する、ことを特徴とする付記1または付記2記載の情報所在管理方法。
(付記10) 前記情報所在先作成手段が前記情報所在先情報を生成する手順は、前記キー情報として前記情報取得先のメールアドレスを用い、前記対象の利用者と同じグループに属する他のメンバについて前記情報所在先蓄積手段に前記情報取得先のメールアドレスに対応する前記情報所在先情報が登録されていないかどうかを調べ、登録されているときは該情報所在先情報を前記対象の利用者に関連付け、前記情報所在先蓄積手段に登録する、ことを特徴とする付記1または付記2記載の情報所在管理方法。
(付記11) 情報所在先削除手段が、前記情報所在先蓄積手段に記憶される前記情報所在先情報に関連付けられた前記対象の利用者のメールアドレスと、前記情報取得先の前記メールアドレスとを読み出し、前記メールアドレスに基づいて前記通信ログを検索して前記対象の利用者と前記情報取得先との間で最後に前記電子メールが送受信されてからの経過時間を算出し、算出された前記経過時間が所定の時間を超えていたときは、前記情報所在先蓄積情報に記憶される前記対象の利用者と、前記情報取得先と、前記対象の利用者及び前記情報取得先に関連付けられた前記情報所在先情報と、を前記情報所在先蓄積手段より削除する、ことを特徴とする付記1または付記2記載の情報所在管理方法。
(付記12) RSSリーダ登録処理手段が、前記情報所在先蓄積手段に新規の情報所在先情報が登録されたときは、前記新規の情報所在先情報の前記対象の利用者に対応する前記RSSリーダの巡回先リストに前記新規の情報所在先情報を登録する手順、
を有することを特徴とする付記1または付記2記載の情報所在管理方法。
(付記13) ネットワーク上に存在する所定の情報の所在を管理する情報所在管理装置において、
送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する取得先選別手段と、
前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する情報所在先作成手段と、
を有することを特徴とする情報所在管理装置。
(付記14) ネットワーク上に存在する所定の情報の所在を管理するための情報所在管理プログラムにおいて、
コンピュータを、
送受信された電子メールに関する通信ログが記憶される通信ログ記憶手段から所定の期間の前記通信ログを読み出し、対象の利用者が少なくとも一往復の前記電子メールの送受信を一定回数以上行った前記電子メールの相手先を特定して情報取得先に選別する取得先選別手段、
前記情報取得先との間で送受信された前記電子メールに含まれる前記情報取得先の情報の所在に関連するキー情報を抽出し、該キー情報に基づいて前記情報取得先の情報の所在を指し示す情報所在先情報を生成して情報所在先蓄積手段に記憶する情報所在先作成手段、
として機能させることを特徴とする情報所在管理プログラム。
実施の形態に適用される発明の概念図である。 実施の形態のシステムの構成例を示した図である。 情報所在管理装置のハードウェア構成例を示すブロック図である。 第1の実施の形態における情報所在管理装置の主要部の機能構成例を示したブロック図である。 通信ログの一例を示した図である。 候補リストの一例を示した図である。 URL蓄積情報の一例を示した図である。 取得先選別処理の具体例を示した図である。 URL生成処理の具体例を示した図である。 RSSリーダ登録処理後のリスト例を示した図である。 情報所在管理方法における全体の処理手順を示したフローチャートである。 取得先選別処理の手順を示したフローチャートである。 取得先選別処理に選別ルール2を適用したときの手順を示したフローチャートである。 URL生成処理の手順を示したフローチャートである。 RSSリーダ登録処理の手順を示したフローチャートである。 登録メンテナンス処理の手順を示したフローチャートである。 メール本文から生成されるURL情報例を示した図である。 第2の実施の形態のURL生成処理の手順を示したフローチャートである。 他のユーザの登録情報から生成されるURL情報例を示した図である。 第3の実施の形態のURL生成処理の手順を示したフローチャートである。
符号の説明
1 情報所在管理装置
1a 通信ログ記憶手段
1b 情報所在先蓄積手段
1c メール情報取得手段
1d 取得先選別手段
1e 情報所在先作成手段
2 メールサーバ
3 情報取得装置
4 外部ネットワーク

Claims (6)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008076670A JP4985509B2 (ja) 2008-03-24 2008-03-24 情報所在管理方法及び情報所在管理装置
US12/409,612 US8122025B2 (en) 2008-03-24 2009-03-24 Method of managing locations of information and information location management device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008076670A JP4985509B2 (ja) 2008-03-24 2008-03-24 情報所在管理方法及び情報所在管理装置

Publications (2)

Publication Number Publication Date
JP2009230576A true JP2009230576A (ja) 2009-10-08
JP4985509B2 JP4985509B2 (ja) 2012-07-25

Family

ID=41089873

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008076670A Expired - Fee Related JP4985509B2 (ja) 2008-03-24 2008-03-24 情報所在管理方法及び情報所在管理装置

Country Status (2)

Country Link
US (1) US8122025B2 (ja)
JP (1) JP4985509B2 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8600343B2 (en) 2007-07-25 2013-12-03 Yahoo! Inc. Method and system for collecting and presenting historical communication data for a mobile device
US9584343B2 (en) 2008-01-03 2017-02-28 Yahoo! Inc. Presentation of organized personal and public data using communication mediums
WO2010141216A2 (en) 2009-06-02 2010-12-09 Xobni Corporation Self populating address book
US20110191717A1 (en) 2010-02-03 2011-08-04 Xobni Corporation Presenting Suggestions for User Input Based on Client Device Characteristics
US9514466B2 (en) * 2009-11-16 2016-12-06 Yahoo! Inc. Collecting and presenting data including links from communications sent to or from a user
US8982053B2 (en) 2010-05-27 2015-03-17 Yahoo! Inc. Presenting a new user screen in response to detection of a user motion
JP6020031B2 (ja) 2012-10-19 2016-11-02 富士通株式会社 抽出プログラム、抽出装置及び抽出方法
JP6003561B2 (ja) 2012-11-15 2016-10-05 富士通株式会社 抽出プログラム、抽出装置及び抽出方法
JP5962471B2 (ja) * 2012-11-30 2016-08-03 富士通株式会社 抽出プログラム、抽出装置及び抽出方法
US9426101B2 (en) 2013-01-30 2016-08-23 Microsoft Technology Licensing, Llc Systems and methods of automatically ordering and selecting recipients for electronic mail
CN105488040A (zh) * 2014-09-15 2016-04-13 上海天脉聚源文化传媒有限公司 一种绘制个人行踪轨迹的方法、装置及系统
US11188615B2 (en) * 2016-06-10 2021-11-30 OneTrust, LLC Data processing consent capture systems and related methods

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002049541A (ja) * 2000-05-24 2002-02-15 Fujitsu Ltd ウェブサイトのアドレス管理装置,そのアドレス管理方法,記録媒体,及びプログラム
JP2002197027A (ja) * 2000-12-27 2002-07-12 Hitachi Ltd 電子メールの宛先管理方法及び電子メールシステム
JP2003233564A (ja) * 2002-02-13 2003-08-22 Sony Corp コミュニケーション相手リスト表示方法、コミュニケーション相手リスト表示装置及び記録媒体
JP2003281050A (ja) * 2002-03-22 2003-10-03 Casio Comput Co Ltd 電子メール装置およびメール処理プログラム
WO2005036409A1 (ja) * 2003-10-10 2005-04-21 Altage Limited Partnership Company 携帯端末用情報サーバ

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6952805B1 (en) * 2000-04-24 2005-10-04 Microsoft Corporation System and method for automatically populating a dynamic resolution list
JP2002190904A (ja) 2000-12-20 2002-07-05 Ricoh Co Ltd ネットワークファクシミリ装置
US7216227B2 (en) * 2002-04-23 2007-05-08 Amiram Grynberg Method and system for controlling the use of addresses using address computation techniques
US20050149507A1 (en) * 2003-02-05 2005-07-07 Nye Timothy G. Systems and methods for identifying an internet resource address
JP2007053569A (ja) 2005-08-18 2007-03-01 Matsushita Electric Works Ltd 電子メールセキュリティ化装置及び該システム
US8732250B2 (en) * 2005-10-23 2014-05-20 Silverpop Systems Inc. Provision of secure RSS feeds using a secure RSS catcher
US8307038B2 (en) * 2006-06-09 2012-11-06 Microsoft Corporation Email addresses relevance determination and uses
US7904459B2 (en) * 2008-03-19 2011-03-08 International Business Machines Corporation Generating a recipient list for propagating contact information changes based on contact metrics involving a user and the recipients on the list

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002049541A (ja) * 2000-05-24 2002-02-15 Fujitsu Ltd ウェブサイトのアドレス管理装置,そのアドレス管理方法,記録媒体,及びプログラム
JP2002197027A (ja) * 2000-12-27 2002-07-12 Hitachi Ltd 電子メールの宛先管理方法及び電子メールシステム
JP2003233564A (ja) * 2002-02-13 2003-08-22 Sony Corp コミュニケーション相手リスト表示方法、コミュニケーション相手リスト表示装置及び記録媒体
JP2003281050A (ja) * 2002-03-22 2003-10-03 Casio Comput Co Ltd 電子メール装置およびメール処理プログラム
WO2005036409A1 (ja) * 2003-10-10 2005-04-21 Altage Limited Partnership Company 携帯端末用情報サーバ

Also Published As

Publication number Publication date
US20090240669A1 (en) 2009-09-24
JP4985509B2 (ja) 2012-07-25
US8122025B2 (en) 2012-02-21

Similar Documents

Publication Publication Date Title
JP4985509B2 (ja) 情報所在管理方法及び情報所在管理装置
US10904186B1 (en) Email processing for enhanced email privacy and security
US7359941B2 (en) Method and apparatus for filtering spam email
US8095551B2 (en) Annotating shared contacts with public descriptors
US8600965B2 (en) System and method for observing communication behavior
US10366055B2 (en) Decreasing duplicates and loops in an activity record
CN101155153A (zh) 用于管理电子邮件附件的方法和数据处理系统
RU2008106895A (ru) Организация сетей посредством обмена электронными сообщениями и электронной почтой
JP2014505922A (ja) テキスト・メッセージを使用したスプレッドシートとの対話
Karagiannis et al. Behavioral profiles for advanced email features
US9055018B2 (en) Related message detection and indication
JPWO2009004724A1 (ja) 電子メール処理装置、電子メール処理方法、電子メール処理プログラムおよび電子メール処理システム
US20080133756A1 (en) Explicit casualty control in a client/server system
US8805942B2 (en) Storing and partitioning email messaging data
US20080065719A1 (en) Method and system for managing rejected messages
JP5369826B2 (ja) 重要度を加味したスケジュール表示方法及びプログラム
JP2010079674A (ja) ファイル関連付け装置、方法及びプログラム
JP5090305B2 (ja) 迷惑メール処理方法、システム、装置及びプログラム
JP2001111601A (ja) 電子メールシステムおよび方法、並びに電子メールアドレス変更通知システムプログラムを記録した記録媒体
JP2009128982A (ja) 送信制御装置、送信制御方法、およびプログラム
KR20100050817A (ko) 네트워크 주소록 기반의 관심사 공유자 검색 서비스 제공 방법
JP2007233468A (ja) 情報処理装置、及び、情報処理方法
KR101086547B1 (ko) 메일에 첨부된 url을 분석하여 스팸을 처리하는 시스템 및 방법
JP2006065655A (ja) スパムメール判定システムおよびその方法
JP2006184957A (ja) 情報処理装置及び方法、情報処理プログラム、及び、ピアシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101119

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120322

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120403

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120416

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150511

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees