(57)【特許請求の範囲】
【請求項１】
全メールデータのうち、新しい一部のメールデータについての索引情報が蓄積された索引記憶装置を含む複数の記憶装置であって、上記メールデータに含まれる情報をその情報の種別毎に異なる記憶装置に蓄積した複数の記憶装置から、検索条件に該当するメールデータを検索するメールデータ検索装置であり、
上記索引記憶装置が記憶したメールデータの日付情報が示す日付の範囲を記憶する状態記憶部と、
メールデータが有する上記日付情報を条件として含む検索条件を入力する検索条件入力部と、
上記状態記憶部が記憶した上記索引記憶装置の日付の範囲に、上記検索条件入力部が入力した検索条件に含まれる日付情報が示す日付が含まれるか否かを判断し、含まれる場合には、上記索引記憶装置に記憶された情報に基づきメールデータを絞り込みして、さらに他の記憶装置に記憶された情報であって、絞込みされたメールデータに係る情報に基づきメールデータを検索する検索制御部と
を備えることを特徴とするメールデータ検索装置。
【請求項２】
上記状態記憶部は、各記憶装置が有効か否かを示す状態情報を記憶し、
上記検索制御部は、上記複数の記憶装置のうち、上記状態記憶部が記憶した状態情報が有効であると示す記憶装置が記憶した情報に基づき、上記検索情報が示す検索条件に該当するメールデータを検索する
ことを特徴とする請求項１に記載のメールデータ検索装置。
【請求項３】
上記メールデータ検索装置は、さらに、
上記状態記憶部が記憶する状態情報を変更する状態変更部
を備えることを特徴とする請求項２に記載のメールデータ検索装置。
【請求項４】
全メールデータのうち、新しい一部のメールデータについての索引情報が蓄積された索引記憶装置を含む複数の記憶装置であって、上記メールデータに含まれる情報をその情報の種別毎に複数の記憶装置の各記憶装置に蓄積するとともに、上記各記憶装置から検索条件に該当するデータを検索するメールアーカイブ装置であり、
メールデータを入力するメール入力部と、
上記メール入力部が入力したメールデータから情報を抽出して、各記憶装置へ記憶する蓄積制御部と
上記索引記憶装置が記憶したメールデータの日付情報が示す日付の範囲を記憶する状態記憶部と、
メールデータが有する上記日付情報を条件として含む検索条件を入力する検索条件入力部と、
上記状態記憶部が記憶した上記索引記憶装置の日付の範囲に、上記検索条件入力部が入力した検索条件に含まれる日付情報が示す日付が含まれるか否かを判断し、含まれる場合には、上記索引記憶装置が記憶した情報に基づきメールデータを絞り込みして、さらに他の記憶装置が記憶した情報であって、絞込みされたメールデータに係る情報に基づきメールデータを検索する検索制御部と
を備えることを特徴とするメールアーカイブ装置。
【請求項５】
上記状態記憶部は、各記憶装置が有効か否かを示す状態情報を記憶し、
上記検索制御部は、上記複数の記憶装置のうち、上記状態記憶部が記憶した状態情報が有効であると示す記憶装置が記憶した情報に基づき、上記検索情報が示す検索条件に該当するメールデータを検索する
ことを特徴とする請求項４に記載のメールアーカイブ装置。
【請求項６】
上記メールアーカイブ装置は、さらに、
上記状態記憶部が記憶する状態情報を変更する状態変更部
を備えることを特徴とする請求項５に記載のメールアーカイブ装置。
【請求項７】
全メールデータのうち、新しい一部のメールデータについての索引情報が蓄積された索引記憶装置を含む複数の記憶装置であって、上記メールデータに含まれる情報をその情報の種別毎に異なる記憶装置に蓄積した複数の記憶装置から、検索条件に該当するメールデータを検索するメールデータ検索方法であり、
処理装置が、上記索引記憶装置が記憶したメールデータの日付情報が示す日付の範囲を記憶する状態記憶ステップと、
入力装置が、メールデータが有する上記日付情報を条件として含む検索条件を入力する検索条件入力ステップと、
処理装置が、上記状態記憶ステップで記憶した上記索引記憶装置の日付の範囲に、上記検索条件入力ステップで入力した検索条件に含まれる日付情報が示す日付が含まれるか否かを判断し、含まれる場合には、上記索引記憶装置に記憶された情報に基づきメールデータを絞り込みして、さらに他の記憶装置に記憶された情報であって、絞込みされたメールデータに係る情報に基づきメールデータを検索する検索制御ステップと
を備えることを特徴とするメールデータ検索方法。
【請求項８】
全メールデータのうち、新しい一部のメールデータについての索引情報が蓄積された索引記憶装置を含む複数の記憶装置であって、上記メールデータに含まれる情報をその情報の種別毎に異なる記憶装置に蓄積した複数の記憶装置から、検索条件に該当するメールデータを検索するメールデータ検索プログラムであり、
上記索引記憶装置が記憶したメールデータの日付情報が示す日付の範囲を記憶する状態記憶処理と、
メールデータが有する上記日付情報を条件として含む検索条件を入力する検索条件入力処理と、
上記状態記憶処理で記憶した上記索引記憶装置の日付の範囲に、上記検索条件入力処理で入力した検索条件に含まれる日付情報が示す日付が含まれるか否かを判断し、含まれる場合には、上記索引記憶装置に記憶された情報に基づきメールデータを絞り込みして、さらに他の記憶装置に記憶された情報であって、絞込みされたメールデータに係る情報に基づきメールデータを検索する検索制御処理と
をコンピュータに実行させることを特徴とするメールデータ検索プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、電子メールデータの蓄積技術及び検索技術に関する。
【背景技術】
【０００２】
企業等における情報セキュリティの分野を中心に、送受信された電子メールのメールデータを収集・保存する動きが進んでいる。メールデータを例えば数年の単位で保存しておき、証拠保全に役立てる。また同時に、万が一情報漏洩事故等が発生した場合には、その原因究明等にメールデータを活用する。大企業になると、送受信されるメールデータの量は、１日当たり１００ＧＢ程度にもなり、蓄積すると数年で１ＴＢの大きなデータ量に達するような場合もある。そこで、大量のメールデータを効率よく蓄積・保存する必要がある。また、必要なときに、短時間で所望のメールデータを検索・取得する必要がある。このようにメールデータを蓄積し、蓄積したメールデータから所定のメールデータを検索する装置を、メールアーカイブ装置と呼ぶ。
【０００３】
特許文献１には、メールデータ本体を蓄積するためのＤＢ（データベース、記憶装置の一例）と、全文検索エンジン（インデックスサーバ）から構成される電子メール検索システムについての記載がある。ここで、メールデータは、ヘッダ、本文、添付ファイル等の複数のパートから構成されるが、ヘッダ、本文、添付ファイル等のメールデータを構成する全てのパートのデータをメールデータ本体と呼ぶ。つまり、メールデータ本体を蓄積するためのＤＢとは、メールデータを構成する全てのパートのデータを記憶するＤＢのことである。
【特許文献１】特開２００２−３５１７９７号公報
【特許文献２】特開２００７−１４０８２１号公報
【非特許文献１】「大規模ログデータベースの実現」情報処理学会第６８回全国大会  講演論文集（３）  ｐｐ２９−３０
【非特許文献２】「スケーラブルインテリジェントストレージによる高性能特許検索システム」，情報処理学会第６６回全国大会  講演論文集（３）  ｐｐ６３−６４
【発明の開示】
【発明が解決しようとする課題】
【０００４】
メールデータ本体を保存すると同時に、メールデータの高速な検索を実現する方式として、特許文献１に示す電子メール検索システムがある。しかし、特許文献１に係る電子メール検索システムには、次の課題がある。
（１）ヘッダ情報だけを取り出したい場合でも、ＤＢからメールデータ本体を一度読み出し、読み出したメールデータ本体からヘッダ情報だけを切り出す必要がある。メールデータによってはメールデータの全体のサイズが、ヘッダ情報の数千倍以上にもなるものがあり、必要以上のストレージＩ／Ｏ負荷がかかる。そのため、ヘッダ情報だけ取り出したい場合の読み出し効率が悪い。
（２）メールデータ中には、メールアドレス等の形式の決まった文字列が含まれることが多い。インデックスサーバによる検索は、原則として固定文字列を対象とした検索である。そのため、同じ形式を持った文字列を検索したい場合には、その検索条件の指定が困難で、適していない。
（３）インデックスサーバが記憶する情報のサイズは、その情報の元となるテキスト情報のサイズの数倍（２〜３倍）になることが多く、長期間メールを蓄積した場合には大容量のストレージが必要となり、ストレージにかかるコストが膨大なものとなる。
【０００５】
本発明は、例えば、どのような環境でも、効率的にメールデータの蓄積及び検索を行うことを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係るメールデータ検索装置は、例えば、メールデータに含まれる所定の情報をその情報の種別毎に異なる記憶装置に蓄積した複数の記憶装置から、検索条件に該当するメールデータを検索するメールデータ検索装置であり、
上記複数の記憶装置の各記憶装置が有効か否かを示す状態情報を記憶する状態記憶部と、
検索条件を示す検索情報を入力する検索条件入力部と、
上記検索条件入力部が検索情報を入力すると、上記複数の記憶装置のうち、上記状態記憶部が記憶した状態情報が有効であると示す記憶装置が記憶した情報に基づき、上記検索情報が示す検索条件に該当するメールデータを検索する検索制御部と
を備えることを特徴とする。
【発明の効果】
【０００７】
本発明に係るメールデータ検索装置によれば、メールデータをその情報の種別毎に異なる記憶装置に蓄積した記憶装置から検索する。そのため、メールデータの検索効率がよい。
また、状態記憶部が記憶した状態情報が有効であると示す記憶装置からメールデータを検索する。そのため、環境に合わせて使用する記憶装置の切り替えが可能である。検索に使用しない記憶装置にはメールデータを記憶させておく必要はないので、環境に合わせて使用する記憶装置を切り替えることにより、メールデータの蓄積量をコントロールすることが可能である。
【発明を実施するための最良の形態】
【０００８】
実施の形態１．
この実施の形態では、使用する環境に合わせて、メールデータの効率的な蓄積及び検索を可能とするメールアーカイブ装置１００について説明する。
【０００９】
まず、メールデータおよびメールアーカイブ装置１００の特徴について説明する。
メールデータは、一度送信されると、途中で削除されることも、書き換えられることも無い。つまり、メールアーカイブ装置１００に蓄積されるメールデータは、時間の経過と共に増加する一方で、既にメールアーカイブ装置１００に蓄積されたメールデータが更新されることは無い。
また、上述したように、メールデータは、ヘッダ、本文、添付ファイル等の複数のパートから構成される。さらにヘッダは、複数のフィールドから構成される。特にヘッダには、送信者や受信者、送信日時等の有益な情報が含まれるため、統計処理の対象とされることがある。統計処理の対象とする場合には、メールアーカイブ装置１００でも、大量のヘッダだけを効率的に取り出す仕組が求められる。
【００１０】
次に、この実施の形態に係るメールアーカイブ装置１００の基礎となる事項について説明する。
この実施の形態に係るメールアーカイブ装置１００は、メールデータを記憶するメールアーカイブＤＢを、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８等の複数の個別ＤＢで構成する。つまり、メールデータに含まれる所定の情報をその情報の種別毎に異なるＤＢに記憶するが、ここでは一例としてメールデータに含まれる情報を索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８のＤＢに分けて記憶する。ここでは各個別ＤＢに蓄積されたメールデータの情報は、ＩＤ等の識別情報（以降、メールＩＤと呼ぶ）を付加して蓄積することにより、関連付けるものとする。
【００１１】
索引記憶装置１１５は、メールデータのテキスト情報を高速に検索するための全文検索索引を蓄積する。全文検索索引の方式にも様々あるが、メールアーカイブ装置１００は、全文検索の索引の方式はＮ−ｇｒａｍを利用したものでも、形態素解析を利用したものでも、その他の方式を利用したものであってもよい。また、検索を高速に行えるものであれば、概念検索的な検索エンジンでもよい。索引記憶装置１１５の特徴として、検索速度が非常に高速ではあるが、その為に索引のサイズが元のメールデータのテキスト情報のサイズの数倍（２〜３倍程度）になる場合がある。
【００１２】
メール記憶装置１１６は、メールデータ本体を復元可能な形式で蓄積するためのＤＢである。特に、メールデータのような、可変長で長大な（数ＫＢ〜１００ＭＢ）データの管理には、例えば、非特許文献１に示すログＤＢのようなシステムが適している。非特許文献１に示すログＤＢを適用したメール記憶装置１１６では、メールデータを圧縮して蓄積することで、蓄積に必要なサイズを元のメールデータの１／１０以下にすることができる。この蓄積されたメールデータは、前記のメールＩＤをキーにして取り出すことができるものとする。一方、メールデータ中において、ＪＩＳの２バイト文字等で記述された文字列は、ＭＩＭＥ方式等でエンコードされているため、キーワード等による検索が困難である。
【００１３】
ヘッダ記憶装置１１７は、メールデータのヘッダのテキスト情報を切り出して、復元可能な形式で蓄積するためのＤＢである。ここでのヘッダは、ＭＩＭＥ形式からデコードされたものである。ヘッダ記憶装置１１７にも、上記ログＤＢが適している。ヘッダ記憶装置１１７は、ヘッダを圧縮して蓄積することで、蓄積に必要なサイズを元のヘッダの１／１０以下にすることができる。ヘッダ記憶装置１１７は、正規表現キーワードを条件にした検索を行うことができるものとする。正規表現による検索は、全文検索索引による検索より、検索速度が遅いという短所があるが、全文検索索引の検索キーワードは固定文字列に限定されるのに対して、正規表現による検索では文字列のパターンの検索ができるという長所がある。正規表現を利用することにより、ヘッダの特定のフィールドを対象にした検索を行うことができる。
【００１４】
テキスト記憶装置１１８は、メールデータのヘッダ以外のパートのテキスト情報を切り出して、復元可能な形式で蓄積するためのＤＢである。テキスト記憶装置１１８にも、上記ログＤＢが適している。ヘッダ記憶装置１１７とは、蓄積する対象が異なるだけで、同様の特徴を持つものとする。
【００１５】
以上のような構成にして、ヘッダを予め抽出して蓄積するヘッダ記憶装置１１７を備えることにより、メールデータからヘッダだけを取り出す場合にも、不要なストレージＩ／Ｏ負荷がかからず、ヘッダだけを効率的に取り出せる効果がある。
また、メールデータのテキスト情報を、復元可能な形式で保存したヘッダ記憶装置１１７やテキスト記憶装置１１８を備えることにより、ヘッダや本文等のテキスト情報を対象に、正規表現キーワードによる検索を行えるようになる。正規表現キーワードによる検索を行えるようにすることで、同じ形式を持った文字列を効率的に検索することができる。なお、上述したように、メールデータ中には、メールアドレス等の形式の決まった文字列が含まれることが多い。
【００１６】
しかし、単にメールデータに含まれる所定の情報をその情報の種別毎に異なるＤＢに記憶するだけでは、メールアーカイブ装置１００を使用する環境によっては、メールデータの蓄積に必要なストレージ容量が増大する。特に、全文検索用の索引は、元となるテキスト情報のサイズの数倍（２〜３倍）になることが多く、長期間メールデータを蓄積した場合等にストレージにかかるコストが膨大なものとなる。
そこで、この実施の形態に係るメールアーカイブ装置１００は、使用する環境に合わせて、メールデータの効率的な蓄積及び検索を可能とする。
【００１７】
なお、これ以降、索引記憶装置１１５は、非特許文献２に示す、属性検索や、タグ検索の機能を備えた全文検索エンジンであるとして説明する。つまり、属性情報として、メールデータのヘッダの情報の一部を保持して検索可能とすると同時に、ヘッダの特定のフィールドや、メールデータ本文、添付ファイルの位置をタグ情報として保持することにより、テキスト情報の特定の領域に限定して全文検索を行うことができるものとする。具体的には、索引記憶装置１１５には、属性情報としてＤａｔｅフィールド（ここでは、一例としてメールデータの送信日時）の情報があり、送信日時の検索ができるものとする。また、ここでは、一例としてＦｒｏｍ（送信者）、Ｔｏ（宛先）、Ｓｕｂｊｅｃｔ（表題）等のフィールドにタグが設定されており、送信者や宛先を対象とした検索が行えるものとする。もちろん、属性情報として、Ｄａｔｅフィールド以外のメールデータのメタ情報を保存するようにしてもよいし、上記以外のタグを設定しておいてもよい。
【００１８】
図１は、この実施の形態に係るメールアーカイブ装置１００の機能を示す機能ブロック図である。
この実施の形態に係るメールアーカイブ装置１００は、メール入力部１０１、テキスト属性入力部１０２、蓄積制御部１０３、ＤＢ構成管理テーブル１０４（状態記憶部）、検索条件入力部１０５、検索条件解析部１０６、検索制御部１０７、検索結果出力部１０８、検索結果管理部１０９、ＤＢ定義部１１０（状態変更部）、索引管理部１１１、メール管理部１１２、ヘッダ管理部１１３、テキスト管理部１１４を備える。
メール入力部１０１は、蓄積するメールデータの入力を入力装置、通信装置を介して受け付ける。つまり、所定の装置やプログラムから入力された蓄積するメールデータを受け付ける。
テキスト属性入力部１０２は、後述するＤＢ構成管理テーブル１０４が記憶した情報を参照し、メール入力部１０１が入力を受け付けたメールデータから、ヘッダ、本文、添付ファイルのテキスト情報や、ヘッダ情報から取り出すことのできる属性、タグの情報を処理装置により抽出する。つまり、各ＤＢが記憶する情報を、メールデータから抽出する。
蓄積制御部１０３は、後述するＤＢ構成管理テーブル１０４が記憶した状態情報を参照し、テキスト属性入力部１０２がメールデータやメールデータから処理装置により抽出した情報を、適切な個別ＤＢ管理部（索引管理部１１１、メール管理部１１２、ヘッダ管理部１１３、テキスト管理部１１４）へ処理装置により分配する。
ＤＢ構成管理テーブル１０４は、１個のメールアーカイブＤＢを構成する各個別ＤＢ（索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８）の有効／無効を示す状態情報、その他の情報を記憶装置に管理・記憶する。
検索条件入力部１０５は、メールデータの検索条件を示す検索情報の入力を入力装置、通信装置を介して受け付ける。
検索条件解析部１０６は、検索条件入力部１０５が入力された検索条件を処理装置により解析し、検索命令のリストを処理装置により生成する。
検索制御部１０７は、検索条件解析部１０６が生成した検索命令リストを入力とし、ＤＢ構成管理テーブル１０４が記憶した情報を参照して、適切な個別ＤＢ管理部へ検索要求（検索命令リスト）を処理装置により振り分け、検索処理を実行する。つまり、検索制御部１０７は、ＤＢ構成管理テーブル１０４が記憶した状態情報が有効であると示す個別ＤＢへ検索要求を振り分けることにより、状態情報が有効であると示す個別ＤＢが記憶した情報に基づき検索条件に該当するメールデータを検索する。
検索結果出力部１０８は、最終的なメールデータの検索結果を表示装置等へ出力する。
検索結果管理部１０９は、個別ＤＢの検索結果を集計するとともに、検索結果を処理装置によりソートする。
ＤＢ定義部１１０は、複数のパラメータを入力とし、個別ＤＢを処理装置により生成または消去して、ＤＢ構成管理テーブル１０４が記憶した情報を処理装置により更新する。つまり、ＤＢ定義部１１０は、状態情報を変更することができる。
索引管理部１１１は、メールデータのテキスト情報を入力として、索引を生成してＤＢ（索引記憶装置１１５）に蓄積する。検索時には、索引管理部１１１は、キーワードと検索対象のタグを入力として、そのキーワードを含むメールデータの情報を出力する。また、索引管理部１１１は、属性検索条件を入力として、その条件に適合する属性条件を持つメールデータの情報を出力する。
メール管理部１１２は、入力されたままのメールデータを入力とし、メールデータを復元可能な形式でＤＢ（メール記憶装置１１６）に蓄積する。メールＩＤを入力として、そのＩＤのメールデータを出力する。
ヘッダ管理部１１３は、ヘッダのテキスト情報を入力として、ＤＢ（ヘッダ記憶装置１１７）に蓄積する。検索時には、正規表現キーワードを入力として、その正規表現キーワードに適合する文字列を含むヘッダの情報を出力する。また、メールＩＤを入力として、そのＩＤのメールデータのヘッダを出力する。
テキスト管理部１１４は、本文・添付ファイルのテキスト情報を入力として、ＤＢ（テキスト記憶装置１１８）に蓄積する。検索時には、正規表現キーワードを入力として、その正規表現キーワードに適合する文字列を含むメールデータの情報を出力する。
【００１９】
なお、図１において、Ａで示す破線で囲まれた部分をメールデータ蓄積装置と呼び、Ｂで示す破線で囲まれた部分をメールデータ検索装置と呼ぶ。
また、図１では、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８は、メールアーカイブ装置１００が備えていないものとして示している。しかし、メールアーカイブ装置１００は、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８を内部に備えていてもよい。
【００２０】
図２は、ＤＢ構成管理テーブル１０４の一例を示す図である。
図２に示すＤＢ構成管理テーブル１０４は、個別ＤＢのＤＢ種別２０１、ＤＢ名２０２、個別ＤＢの有効／無効を表す状態情報２０３をテーブルで管理する。その他の付加情報を、同テーブルで管理するようにしてもよい。
【００２１】
次に、メールアーカイブＤＢ生成時の処理の流れを説明する。
メールアーカイブ装置１００の管理者は、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８の有効／無効を指定するパラメータを入力として、ＤＢ生成要求を発行する。ＤＢ定義部１１０は、入力されたパラメータに従って、個別ＤＢの生成要求を各個別ＤＢ管理部（索引管理部１１１、メール管理部１１２、ヘッダ管理部１１３、テキスト管理部１１４）に発行する。また、ＤＢ定義部１１０は、各個別ＤＢの有効／無効を状態情報としてＤＢ構成管理テーブル１０４に記憶する。
【００２２】
次に、メールアーカイブＤＢ消去時の処理の流れを説明する。
メールアーカイブ装置１００の管理者は、消去するＤＢを指定したＤＢ消去要求を発行する。ＤＢ定義部１１０は、指定されたＤＢを管理する個別ＤＢ管理部（索引管理部１１１、メール管理部１１２、ヘッダ管理部１１３、テキスト管理部１１４）に、個別ＤＢの消去要求を発行する。また、ＤＢ定義部１１０は、ＤＢ構成管理テーブル１０４が記憶した状態情報であって、指定されたＤＢの状態情報を有効から無効に更新する。
【００２３】
次に、図３に基づき、メールデータの蓄積処理について説明する。つまり、メールデータ蓄積装置の動作について説明する。図３は、メールデータの蓄積時の処理を示すフローチャートである。
メール入力部１０１がメールデータの入力を１通受付する毎に、以下の処理が実行される。
（Ｓ３０１）：メール入力部１０１は、メールデータの入力を受け付ける。メール入力部１０１は、受け付けたメールデータをテキスト属性入力部１０２へ送る。
（Ｓ３０２）：テキスト属性入力部１０２は、ＤＢ構成管理テーブル１０４の状態情報を参照し、索引記憶装置１１５、ヘッダ記憶装置１１７、テキスト記憶装置１１８の各ＤＢが有効であるか、無効であるかを判定する。全てのＤＢが無効である場合（Ｓ３０２でＹＥＳ）、メールアーカイブＤＢにテキスト情報は蓄積されないので、（Ｓ３０４）へ進む。一方、少なくとも１つのＤＢが有効である場合（Ｓ３０２でＮＯ）、メールデータのテキスト情報や、属性・タグの情報もメールアーカイブＤＢに蓄積されるので、（Ｓ３０３）へ進む。
（Ｓ３０３）：テキスト属性入力部１０２は、メールデータのテキスト情報や、属性・タグの情報を抽出する。ここで、テキスト属性入力部１０２は、ＤＢ構成管理テーブル１０４の状態情報を参照して、蓄積に必要な情報だけを抽出するようにしてもよい。つまり、索引記憶装置１１５が有効である場合は、テキスト属性入力部１０２は、メールデータのヘッダ、本文、添付ファイルのテキスト情報と、属性・タグ情報の全てを抽出する。しかし、ヘッダ記憶装置１１７だけが有効である場合は、テキスト属性入力部１０２は、ヘッダ部分のテキスト情報だけを抽出するようにしてもよい。テキスト属性入力部１０２は、抽出したテキスト、属性、タグの情報をメールデータ本体と合わせて蓄積制御部１０３へ送る。
（Ｓ３０４）：蓄積制御部１０３は、ＤＢ構成管理テーブル１０４の状態情報を参照し、索引記憶装置１１５が有効であるか否か判定する。索引記憶装置１１５が有効である場合（Ｓ３０４でＹＥＳ）、（Ｓ３０５）へ進む。一方、索引記憶装置１１５が無効である場合（Ｓ３０４でＮＯ）、（Ｓ３０６）へ進む。
（Ｓ３０５）：蓄積制御部１０３は、メールデータのテキスト、属性、タグの情報を索引管理部１１１へ送る。そして、索引管理部１１１は、送られた情報を索引記憶装置１１５に蓄積する。
（Ｓ３０６）：蓄積制御部１０３は、ＤＢ構成管理テーブル１０４の状態情報を参照し、メール記憶装置１１６が有効であるか否か判定する。メール記憶装置１１６が有効である場合（Ｓ３０６でＹＥＳ）、（Ｓ３０７）へ進む。メール記憶装置１１６が無効である場合（Ｓ３０６でＮＯ）、（Ｓ３０８）へ進む。
（Ｓ３０７）：蓄積制御部１０３は、メールデータ本体をメール管理部１１２へ送る。そして、メール管理部１１２は、送られた情報をメール記憶装置１１６に蓄積する。
（Ｓ３０８）：蓄積制御部１０３は、ＤＢ構成管理テーブル１０４の状態情報を参照し、ヘッダ記憶装置１１７が有効であるか否か判定する。ヘッダ記憶装置１１７が有効である場合（Ｓ３０８でＹＥＳ）、（Ｓ３０９）へ進む。ヘッダ記憶装置１１７が無効である場合（Ｓ３０８でＮＯ）、（Ｓ３１０）へ進む。
（Ｓ３０９）：蓄積制御部１０３は、ヘッダのテキスト情報をヘッダ管理部１１３へ送る。そして、ヘッダ管理部１１３は、送られた情報をヘッダ記憶装置１１７に蓄積する。
（Ｓ３１０）：蓄積制御部１０３は、ＤＢ構成管理テーブル１０４の状態情報を参照し、テキスト記憶装置１１８が有効であるか否か判定する。テキスト記憶装置１１８が有効である場合（Ｓ３１０でＹＥＳ）、（Ｓ３１１）へ進む。テキスト記憶装置１１８が無効である場合（Ｓ３１０でＮＯ）、そのまま処理を終了し、メールアーカイブＤＢへのメールデータの書き込みを確定する。
（Ｓ３１１）：蓄積制御部１０３は、メールデータ本文と添付ファイルのテキスト情報をテキスト管理部１１４へ送る。そして、テキスト管理部１１４は、送られた情報をテキスト記憶装置１１８に蓄積する。その後、処理を終了し、メールアーカイブＤＢへのメールデータの書き込みを確定する。
【００２４】
次に、図４に基づき、メールデータの検索処理について説明する。つまり、メールデータ検索装置の動作について説明する。図４は、メールデータの検索処理を示すフローチャートである。
（Ｓ４０１）：検索条件入力部１０５は、検索条件を示す検索情報の入力を受け付ける。検索条件入力部１０５は、入力された検索条件を検索条件解析部１０６へ送る。
（Ｓ４０２）：検索条件解析部１０６は、検索条件から検索命令リストを生成する。検索条件解析部１０６は、生成した検索命令リストを検索制御部１０７へ送る。検索命令リストの生成方法については後述する。
（Ｓ４０３）：検索制御部１０７は、検索命令リストの先頭の命令に応じて、適切な個別ＤＢ管理部に検索要求を発行する。そして、検索要求を受けた個別ＤＢ管理部は、検索を実行し、検索結果を検索制御部１０７に返す。検索制御部１０７は、検索結果を検索結果管理部１０９へ送る。
（Ｓ４０４）：検索制御部１０７は、検索命令リストに、次の検索命令があるか否か判定する。次の検索命令がある場合（Ｓ４０４でＹＥＳ）、（Ｓ４０３）へ進み、上記と同様に次の検索命令を実行する。一方、次の検索命令が無い場合（Ｓ４０４でＮＯ）、（Ｓ４０５）へ進む。
（Ｓ４０５）：検索結果管理部１０９は、検索制御部１０７が送った個別ＤＢでの検索結果と、検索条件解析部１０６が生成した検索命令リストとに基づき、検索結果を集計する。検索結果管理部１０９は、集計した検索結果を検索結果出力部１０８へ送る。検索結果の集計方法については後述する。
（Ｓ４０６）：検索結果出力部１０８は、検索結果を出力する。検索結果の出力先は、標準出力や、予め指定されたファイルでもよい。また検索結果の出力先は、同一装置上の別のプログラムへ送って、検索結果に応じた動作を実行させるのでもよい。さらに、検索結果の出力先は、ネットワークを経由して、異なる装置へ送信してもよい。
【００２５】
図５は検索条件の一例を示す図である。
図５に示す検索条件は、
（１）「２００７／４／１  ００：００：００．０００〜２００７／９／３０  ２３：５９：５９．９９９」に送信されたメールデータを検索する部分検索条件と、
（２）表題に「議事録」という文字列を含むメールデータを検索する部分検索条件と、
（３）メールアドレスに「Ｓａｔｏｈ」という文字列を含むドメイン「ａｂｃ．ｃｏ．ｊｐ」から送信されたメールデータを検索する部分検索条件と、
（４）メールデータ本文に「情報セキュリティ」または「メールアーカイブ」と、「開発計画」との文字列を含むメールデータを検索する部分検索条件と
の（１）から（４）までの部分検索条件で構成される検索条件である。
【００２６】
図６は、図５に示す検索条件から、検索条件解析部１０６が生成する検索命令リストの一例を示す図である。図６の例では、少なくとも索引記憶装置１１５とヘッダ記憶装置１１７が有効になっているものとする。
図６に示す検索命令リストは、
（ａ）索引管理部１１１において、Ｄａｔｅ属性とＳｕｂｊｅｃｔタグと本文とに対する検索を実行する。つまり、図５に示す検索条件の（１）（２）（４）を索引管理部１１１において実行する。
（ｂ）ヘッダ管理部１１３において、Ｆｒｏｍフィールドに対する検索を実行する。つまり、図５に示す検索条件の（３）をヘッダ管理部１１３において実行する。
そして、（ａ）と（ｂ）とのそれぞれの検索結果を、検索結果管理部１０９において集計（ＡＮＤ）するということを意味している。つまり、（ａ）と（ｂ）との検索結果のいずれにも含まれるメールデータを検索結果とする。
ここで、ヘッダ管理部１１３における検索条件の、ダブルクォーテーションで囲まれた文字列が、Ｆｒｏｍフィールドを検索するための正規表現キーワードになる。このような、特定のヘッダフィールドを検索する正規表現キーワードは、機械的に生成することができる。
【００２７】
図７は、図５に示す検索条件から、検索条件解析部１０６が生成する検索命令リストのもう１つの例を示す図である。図７の例では、索引記憶装置１１５が無効で、少なくともヘッダ記憶装置１１７とテキスト記憶装置１１８が有効になっているものとする。
図７に示す検索命令リストは、
（ａ）ヘッダ管理部１１３において、ＤａｔｅフィールドとＳｕｂｊｅｃｔフィールドとＦｒｏｍフィールドに対する検索を実行する。つまり、図５に示す検索条件の（１）（２）（３）をヘッダ管理部１１３において実行する。
（ｂ）テキスト管理部１１４において、メールデータ本文に対する検索を実行する。つまり、図５に示す検索条件の（４）をテキスト管理部１１４において実行する。
そして、（ａ）と（ｂ）とのそれぞれの検索結果を、検索結果管理部１０９において集計（ＡＮＤ）するということを意味している。
ここで、各個別ＤＢにおける検索条件の、ダブルクォーテーションで囲まれた文字列が、ヘッダフィールドやメールデータ本文を検索するための正規表現キーワードになる。
【００２８】
次に、図８に基づき、検索条件解析部１０６が検索命令リストを生成する処理について説明する。図８は、検索条件解析部１０６が検索命令リストを生成する処理を示すフローチャートである。つまり、図８は、図４に示す検索処理の（Ｓ４０２）の処理を詳細に示すフローチャートである。なお、図８に示すフローチャートでは、索引記憶装置１１５のみが有効／無効の切り替えがされ、その他の個別ＤＢは有効であるとする。
（Ｓ８０１）：検索条件解析部１０６は、検索条件の中から部分検索条件を取得する。
（Ｓ８０２）：検索条件解析部１０６は、部分検索条件がヘッダフィールドに対して検索するものであるか否か判定する。ヘッダフィールドに対して検索するものである場合は（Ｓ８０２でＹＥＳ）、（Ｓ８０３）へ進む。一方、ヘッダフィールドに対して検索するものでない場合、つまりメールデータ本文を検索する条件である場合（Ｓ８０２でＮＯ）、（Ｓ８０６）へ進む。
（Ｓ８０３）：検索条件解析部１０６は、ＤＢ構成管理テーブル１０４の状態情報を参照して、索引記憶装置１１５が無効であるか否か判定するとともに、部分検索条件が正規表現キーワードで指定されているか否か判定する。索引記憶装置１１５が有効であって、かつ、部分検索条件が正規表現キーワードで指定されていない場合（Ｓ８０３でＮＯ）、（Ｓ８０４）へ進む。索引記憶装置１１５が無効である場合（Ｓ８０３でＹＥＳ）、（Ｓ８０５）へ進む。また、索引記憶装置１１５が有効であっても、部分検索条件が正規表現キーワードで指定されている場合（Ｓ８０３でＹＥＳ）、（Ｓ８０５）へ進む。
（Ｓ８０４）：検索条件解析部１０６は、部分検索条件を索引管理部１１１に対する検索命令に追加する。その後、（Ｓ８０９）へ進む。
（Ｓ８０５）：検索条件解析部１０６は、部分検索条件をヘッダ管理部１１３に対する検索命令に追加する。このとき、検索条件解析部１０６は、部分検索条件を対応するヘッダフィールドを検索するための正規表現キーワードに変換する。その後、（Ｓ８０９）へ進む。
（Ｓ８０６）：検索条件解析部１０６は、ＤＢ構成管理テーブル１０４の状態情報を参照して、索引記憶装置１１５が無効であるか判定するとともに、部分検索条件が正規表現キーワードで指定されているか否か判定する。索引記憶装置１１５が有効であって、かつ、部分検索条件が正規表現キーワードで指定されていない場合（Ｓ８０６でＮＯ）、（Ｓ８０７）へ進む。索引記憶装置１１５が無効である場合（Ｓ８０６でＹＥＳ）、（Ｓ８０８）へ進む。また、索引記憶装置１１５が有効であっても、部分検索条件が正規表現キーワードで指定されている場合（Ｓ８０６でＹＥＳ）、（Ｓ８０８）へ進む。
（Ｓ８０７）：検索条件解析部１０６は、部分検索条件を索引管理部１１１に対する検索命令に追加する。
（Ｓ８０８）：検索条件解析部１０６は、部分検索条件をテキスト管理部１１４に対する検索命令に追加する。
（Ｓ８０９）：検索条件解析部１０６は、検索条件に、部分検索条件が残っているか否か判定する。部分検索条件が残っていない場合（Ｓ８０９でＮＯ）、処理を終了する。一方、部分検索条件が残っている場合（Ｓ８０９でＹＥＳ）、（Ｓ８０１）へ進む。
【００２９】
なお、上記説明では、索引記憶装置１１５のみが有効／無効の切り替えがされ、その他の個別ＤＢは有効であるとした。しかし、これに限らず、その他の個別ＤＢの有効／無効を切り替えしてもよい。その他の個別ＤＢの有効／無効が切り替えされる場合には、個別ＤＢ毎に有効であるか否かの判定を行い、個別ＤＢが有効である場合に、その個別ＤＢの検索命令に部分検索条件を追加するようにすればよい。また、処理の順序は、どの個別ＤＢを優先的に検索するかを予め決めておき、優先的に検索する個別ＤＢに優先的に部分検索条件が追加されるようにすればよい。
【００３０】
以上のように、この実施の形態に係るメールアーカイブ装置１００はＤＢ構成管理テーブル１０４を備えることにより、性質の異なる複数の個別ＤＢを有効または無効にすることができる。これにより、メールデータの送受信量が少ない環境や、ストレージ容量の削減よりも検索速度が高速であることを優先したい環境では、索引記憶装置１１５を有効にして、高速な検索を実行できるメールアーカイブ装置１００を構成することができる。一方、メールデータの送受信量も多い環境や、検索速度よりもストレージ容量の削減を優先したい環境では、索引記憶装置１１５を無効にして、ヘッダ記憶装置１１７やテキスト記憶装置１１８を有効にすることにより、少ないストレージ容量で、検索機能を備えたメールアーカイブ装置１００を構成することができる。
また、所定のパターンに適合する文字列を含むメールデータを検索したい場合には、ヘッダ記憶装置１１７とテキスト記憶装置１１８を有効にすることにより、正規表現キーワードによる検索が行えるメールアーカイブ装置１００を構成することができる。
さらに、ヘッダ記憶装置１１７を有効にすることにより、メールデータのヘッダだけの取り出しが効率的な、メールアーカイブ装置１００を構成することができる。
つまり、この実施の形態に係るメールアーカイブ装置１００は、あらゆる環境おいても、効率的にメールデータを蓄積し、検索することが可能である。
【００３１】
なお、図１に示したこの実施の形態に係るメールアーカイブ装置１００の各機能部は、それぞれが個別の専用のプロセッサに置いて実現されていてもよいし、１つまたは複数の汎用プロセッサにより動作するソフトウェアによって実現されていてもよい。また、各機能部が同一の計算機で実現されている必要は無く、ネットワークで接続された複数の異なる計算機上で実現されている構成でもよい。
【００３２】
実施の形態２．
この実施の形態では、実施の形態１のメールアーカイブ装置１００において、ＤＢ構成管理テーブル１０４の異なる形態について説明する。この実施の形態におけるメールアーカイブ装置１００の構成は、実施の形態１（図１）と同様である。また、メールアーカイブＤＢの生成、消去、メールデータの蓄積処理の流れも、実施の形態１で説明した通りである。
【００３３】
図９は、この実施の形態に係るＤＢ構成管理テーブル１０４の一例を示す図である。
図９に示すＤＢ構成管理テーブル１０４は、個別ＤＢの種別９０１、ＤＢ名９０２、個別ＤＢの有効／無効を表す状態情報９０３、各個別ＤＢの検索速度９０４をテーブルで管理する。つまり、実施の形態１（図２）で示したＤＢ構成管理テーブル１０４の項目に加え、さらに、各個別ＤＢの検索処理速度を示す速度情報である検索速度９０４をテーブルで管理する。
図９の例では、索引記憶装置１１５の検索速度は高速（高）であるが、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８の検索速度は低速（低）であることを意味する。検索速度の情報として、事前に統計的な調査によって平均検索速度を測定しておき、それを記録しておくようにしてもよい。
【００３４】
図１０は、図５に示す検索条件から、検索条件解析部１０６が生成する検索命令リストのもう１つの例を示す図である。図１０の例では、少なくとも索引記憶装置１１５とヘッダ記憶装置１１７が有効になっているものとする。
図１０に示す検索命令リストは、
（ａ）索引管理部１１１において、Ｄａｔｅ属性とＳｕｂｊｅｃｔタグと本文にと対する検索を実行する。ここで“ＴＨＥＮ”とあるのは、“Ａ  ＴＨＥＮ  Ｂ”  の形式で、「検索命令Ａの実行結果と同じメールＩＤを持つメールデータに対してだけ、検索命令Ｂの検索を実行する」を意味するものとする。つまり、索引記憶装置１１５の検索でヒットしたメールデータに対してだけ、以下の（ｂ）を実行する。
（ｂ）ヘッダ管理部１１３において、Ｆｒｏｍフィールドに対する検索を実行する。
そして、結果を出力する。ここでは、このように、一度絞り込みをかけた後に、絞込されたデータに対して検索を行う検索処理の方法をフィルター検索と呼ぶこととする。
【００３５】
図１０に示す例では、次の考え方に基づき検索処理時間を短縮している。
図９に示す通り、ヘッダ記憶装置１１７に対する検索速度が低い。そのため、単純に各個別ＤＢに対する検索を実行した後で、それらの結果を集計すると、検索に長い時間がかかってしまう場合がある。
そこで、検索速度が高速な個別ＤＢと、検索速度が低速な個別ＤＢに検索要求が発行されるような検索条件においては、先に検索が高速な個別ＤＢに対して検索命令を発行し、検索結果を得る。そして、得られた検索結果と同じメールＩＤを持つメールデータだけを検索対象にするという条件付で検索が低速な個別ＤＢに検索命令を発行する。このようにすることにより、検索が低速な個別ＤＢに対して検索命令を発行する前に、検索の対象となるメールデータを削減することができ、検索時間を短縮できる。
つまり、検索条件解析部１０６は、状態情報が有効であると示すＤＢのうち、検索速度が速いＤＢが記憶した情報に基づきメールデータを絞り込みして、さらに、検索速度が上記ＤＢより速くないＤＢが記憶した情報であって、絞込みされたメールデータに係る情報に基づきメールデータを検索するように検索命令リストを生成する。そして、検索制御部１０７は生成された検索命令リストに基づきメールデータの検索を行う。
【００３６】
また、検索速度が低速な複数の個別ＤＢに対して検索命令が発行されるような検索条件においても、２つめ以降の個別ＤＢに対する検索を、フィルター検索とすることで、検索時間を短縮することができる。
逆に、検索速度が高速な複数の個別ＤＢに対して検索命令が発行されるような検索条件においては、実施の形態１で示したように、個々に検索命令を発行し、最後に検索結果を集計するようにしてもよい。
【００３７】
検索条件によっては、複数の個別ＤＢの内のいずれを選択しても同等の検索が実行できる場合がある。例えば、メールデータ本文に対する固定文字列キーワードによる検索は、索引記憶装置１１５でもテキスト記憶装置１１８でも可能である。このような場合でも、より検索速度が高速な方を選択することで、検索時間を短縮することができる。
【００３８】
以上のように、この実施の形態に係るメールアーカイブ装置１００は、ＤＢ構成管理テーブル１０４に、各個別ＤＢの検索速度に関する情報を記録する。これにより、検索条件解析部１０６における検索命令リストの生成において、より検索時間が短縮できるように、個別ＤＢを選択し、検索命令の発行順序を変更し、検索結果の集計方法を変更して、検索命令リストを発行することができる。
【００３９】
実施の形態３．
この実施の形態では、実施の形態１のメールアーカイブ装置１００において、蓄積のためのストレージ容量を削減する方法について説明する。この実施の形態におけるメールアーカイブ装置１００の構成は、実施の形態１（図１）と同様である。また、メールアーカイブＤＢの消去の手順も、実施の形態１で説明した通りである。
【００４０】
まず、ここでは、索引記憶装置１１５やメール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８は、メールデータを削除する機能を備えたＤＢであるとする。
索引記憶装置１１５やメール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８は、特許文献２に示すＤＢをレコード方向に複数の「範囲」に区切ることができ、その範囲単位でメールデータを削除したり、バックアップ／リストアしたりする、範囲管理機能を備えたＤＢであってもよい。
また、各個別ＤＢは、その蓄積サイズ（記憶したデータ量）を取得する機能を備えているものとする。蓄積サイズを取得する機能としては、各個別ＤＢ管理部が、蓄積サイズを記録する手段を備えていてもよいし、ストレージに作成されるファイルのサイズを取得するとしてもよい。
【００４１】
図１１は、この実施の形態に係るＤＢ構成管理テーブル１０４の一例を示す図である。
図１１に示すＤＢ構成管理テーブル１０４は、個別ＤＢの種別１１０１、ＤＢ名１１０２、個別ＤＢの有効／無効を表す状態情報１１０３、個別ＤＢのサイズの上限１１０４、実際に個別ＤＢに蓄積されている蓄積期間１１０５をテーブルで管理する。つまり、実施の形態１（図２）で示したＤＢ構成管理テーブル１０４の項目に加え、さらに、個別ＤＢのサイズの上限１１０４と、実際に個別ＤＢに蓄積されている蓄積期間１１０５をテーブルで管理する。
ここで、蓄積されている期間とは、個別ＤＢに蓄積されている最も古いメールデータの送信日時と、最も新しい送信日時とを、それぞれ蓄積期間の開始の日時と終了の日時として記録するものである。ここでは、送信日時に基づき期間の開始と終了を判断したが、これに限らず、メールデータの受信日時やメールデータ中に含まれるその他の日時情報に基づき期間の開始と終了を判断してもよい。
【００４２】
次に、この実施の形態に係るメールアーカイブ装置１００のメールアーカイブＤＢ生成時の処理の流れを説明する。
メールアーカイブ装置１００の管理者は、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８の有効／無効と、サイズの上限を指定するパラメータとを入力として、ＤＢ生成要求を発行する。ＤＢ定義部１１０は、入力パラメータに従って、個別ＤＢの生成要求を各個別ＤＢ管理部（索引管理部１１１、メール管理部１１２、ヘッダ管理部１１３、テキスト管理部１１４）に発行する。また、ＤＢ定義部１１０は、各個別ＤＢの有効／無効と、サイズの上限とをＤＢ構成管理テーブル１０４に記録する。
【００４３】
次に、図１２に基づき、この実施の形態に係るメールアーカイブ装置１００のメールデータの蓄積処理について説明する。つまり、この実施の形態に係るメールアーカイブ装置１００のメールデータ蓄積装置の動作について説明する。図１２は、この実施の形態に係るメールアーカイブ装置１００のメールデータの蓄積時の処理を示すフローチャートである。
（Ｓ１２０１）：実施の形態１におけるメールデータの蓄積処理（図３のＳ３０１からＳ３１１まで）と同様にして、メールデータを各個別ＤＢへ蓄積する。
（Ｓ１２０２）：蓄積制御部１０３は、ＤＢ構成管理テーブル１０４が記憶したメールデータの蓄積期間１１０５を更新する。つまり、蓄積制御部１０３は、ＤＢ構成管理テーブル１０４の蓄積期間１１０５の終了の日時を、最後に蓄積したメールデータの送信日時に設定する。メールアーカイブＤＢ生成後に初めて蓄積されたメールデータの場合に限り、蓄積制御部１０３は、ＤＢ構成管理テーブル１０４が記憶したメールデータの蓄積期間１１０５の開始の日時も設定する。
（Ｓ１２０３）：蓄積制御部１０３は、ＤＢ構成管理テーブル１０４のサイズの上限１１０４に設定されたサイズと、索引記憶装置１１５のサイズ（記憶しているデータ量）とを比較する。索引記憶装置１１５のサイズがサイズの上限１１０４以下である場合（Ｓ１２０３でＹＥＳ）、そのまま処理を終了する。一方、索引記憶装置１１５のサイズがサイズの上限１１０４を超えている場合には（Ｓ１２０３でＮＯ）、（Ｓ１２０４）へ進む。
（Ｓ１２０４）：蓄積制御部１０３は、索引記憶装置１１５に蓄積されているメールデータの索引の中から、最も古いメールデータを削除する。そして、（Ｓ１２０２）へ戻り、蓄積期間の開始の日時を、索引記憶装置１１５に蓄積されている最も古いメールデータの送信日時に設定する。
【００４４】
なお、上記説明では、索引記憶装置１１５についてのみデータを削除する処理を説明したが、他の個別ＤＢについても同様にサイズの上限を超えたか否かを判定し、サイズの上限を超えている場合には古いメールデータから削除するとしてもよい。
【００４５】
つまり、蓄積制御部１０３は、個別ＤＢの記憶容量が足らず、メールデータから抽出された情報をその個別ＤＢに記憶できない場合、メールデータに含まれる日時情報が示す日時が古い情報を上記個別ＤＢから削除する。
【００４６】
索引記憶装置１１５が範囲管理機能を備えたＤＢであった場合は、索引記憶装置１１５に存在する最も古い範囲のメールデータを削除するとしてもよい。そして、削除後に最も古い範囲となった範囲の先頭の送信日時を、蓄積期間の開始の日時としてもよい。このとき、範囲の先頭のメールデータの送信日時と、最後のメールデータの送信日時とを範囲管理テーブルの範囲のキーとしておくことにより、蓄積期間の開始日時を容易に取得することができる。
【００４７】
次に、図１３に基づき、この実施の形態に係るメールアーカイブ装置１００の検索条件解析部１０６が検索命令リストを生成する処理について説明する。図１３は、この実施の形態に係る検索条件解析部１０６が検索命令リストを生成する処理の流れを示すフローチャートである。検索処理の全体の流れは、実施の形態１（図４）と同様である。つまり、図１３は、図８と同様に、図４に示す検索処理の（Ｓ４０２）の処理を詳細に示すフローチャートである。また、ここでは、図１１に示すように索引記憶装置１１５の蓄積期間は短く、他の個別ＤＢの蓄積期間は長い（例えば、蓄積開始から現在までの全期間）であるとする。
（Ｓ１３０１）：検索条件解析部１０６は、検索条件の中から部分検索条件を取得する。
（Ｓ１３０２）：検索条件解析部１０６は、部分検索条件が送信日時を条件にして検索するものであるか否か判定する。部分検索条件が送信日時を条件にして検索するものである場合（Ｓ１３０２でＹＥＳ）、（Ｓ１３０３）へ進む。一方、部分検索条件が送信日時を条件にして検索するものでない場合（Ｓ１３０２でＮＯ）、（Ｓ１３０７）へ進む。
（Ｓ１３０３）：検索条件解析部１０６は、ＤＢ構成管理テーブル１０４の状態情報を参照して、索引記憶装置１１５が無効であるか否か判定する。索引記憶装置１１５が有効である場合（Ｓ１３０３でＮＯ）、（Ｓ１３０４）へ進む。索引記憶装置１１５が無効である場合（Ｓ１３０３でＹＥＳ）、（Ｓ１３０６）へ進む。
（Ｓ１３０４）：検索条件解析部１０６は、ＤＢ構成管理テーブル１０４の状態情報を参照して、検索条件に指定された送信日時が、索引記憶装置１１５の蓄積期間１１０５の範囲内であるか否か判定する。蓄積期間１１０５の範囲内である場合（Ｓ１３０４でＹＥＳ）、（Ｓ１３０５）へ進む。一方、蓄積期間１１０５の範囲内でない場合（Ｓ１３０４でＮＯ）、（Ｓ１３０６）へ進む。
（Ｓ１３０５）：検索条件解析部１０６は、部分検索条件を索引管理部１１１の検索命令に追加する。その後、（Ｓ１３０８）へ進む。
（Ｓ１３０６）：検索条件解析部１０６は、部分検索条件をヘッダ管理部１１３に対する検索命令に追加する。このとき、検索条件解析部１０６は、部分検索条件を送信日時を検索するための正規表現キーワードに変換する。その後、（Ｓ１３０８）へ進む。
（Ｓ１３０７）：検索条件解析部１０６は、図８の（Ｓ８０２）から（Ｓ８０８）までと同様の処理を実行する。
（Ｓ１３０８）：検索条件解析部１０６は、検索条件に、部分検索条件が残っているか否か判定する。部分検索条件が残っていない場合（Ｓ１３０８でＮＯ）、処理を終了する。一方、部分検索条件が残っている場合（Ｓ１３０８でＹＥＳ）、（Ｓ１３０１）へ進む。
【００４８】
つまり、検索条件解析部１０６は、検索条件にメールデータが有する日時情報が含まれる場合には、ＤＢ構成管理テーブル１０４が記憶した実際に個別ＤＢに蓄積されている蓄積期間に、検索条件に含まれる日付情報が示す日付が含まれるか否かをＤＢ毎に判断するとともに、ＤＢ構成管理テーブル１０４の状態情報が有効であると示すＤＢであって、検索条件に含まれる日時情報が示す日時が含まれると判断された記憶装置が記憶した情報に基づき、検索情報が示す検索条件に該当するメールデータを検索する検索命令リストを生成する。そして、検索制御部１０７は、生成された検索命令リストに基づきメールデータを検索する。
【００４９】
（Ｓ１３０４）において、検索条件に指定された送信日時の期間が、索引記憶装置１１５の蓄積期間１１０５と一部だけ重なる場合、すなわち索引記憶装置１１５の蓄積期間以前から蓄積期間内までの日時が指定されていた場合、ヘッダ管理部１１３の検索命令リストに送信日時の期間の条件を追加してもよい。
また、索引記憶装置１１５の蓄積期間以前の条件と、蓄積期間内の条件とに検索条件を分割して、索引記憶装置１１５の蓄積期間以前の条件をヘッダ管理部１１３の検索命令リストに追加し、蓄積期間内の条件を索引管理部１１１の検索命令リストに追加してもよい。この場合、検索結果管理部１０９は、索引記憶装置１１５の蓄積期間以前の条件で検索した結果と、蓄積期間内の条件で検索した結果との和集合（ＯＲ）をとるように、検索結果を集計する必要がある。
【００５０】
図１４は、図５に示す検索条件から、この実施の形態に係るメールアーカイブ装置１００の検索条件解析部１０６によって生成された検索命令リストの一例を示す図である。図１４に示す例では、索引記憶装置１１５の蓄積期間以前の条件と、蓄積期間内の条件とに検索条件を分割して検索命令リストを生成している。ここでは、ＤＢ構成管理テーブル１０４は、図１１に示す情報を記憶しているとする。
図１４に示す検索命令リストは、
（ａ）ヘッダ管理部１１３において、２００７年の４月から６月のメールデータの検索を実行する。つまり、索引記憶装置１１５の蓄積期間以前の期間のメールデータをヘッダ管理部１１３において検索する。
（ｂ）索引管理部１１１において、２００７年の７月から９月までのメールデータの検索を実行する。つまり、索引記憶装置１１５の蓄積期間のメールデータを索引管理部１１１において検索する。
そして、（ａ）と（ｂ）とのそれぞれの検索結果を、検索結果管理部１０９において集計（ＯＲ）するということを意味している。つまり、（ａ）と（ｂ）との検索結果のいずれかに含まれるメールデータを検索結果とする。
【００５１】
上述したように、ここでは、索引記憶装置１１５の削除についてだけ説明した。その理由は、索引記憶装置１１５が他の個別ＤＢに比べ一般にサイズが大きくなるためである（例えば、テキスト記憶装置１１８の数十倍）。古いメールデータについては、検索できなくてもよいという場合は、索引記憶装置１１５の削除と同時に、ヘッダ記憶装置１１７やテキスト記憶装置１１８のデータも削除してもよい。また、メールデータの取り出しができなくてもよいという場合は、メール記憶装置１１６のデータも削除してもよい。また、削除する前に、削除されるメールデータのバックアップをとるようにしてもよい。
【００５２】
以上のように、この実施の形態に係るメールアーカイブ装置１００によれば、ＤＢ構成管理テーブル１０４に、個別ＤＢのサイズの上限と、メールデータの蓄積期間を記憶する。各個別ＤＢへのメールデータの蓄積時に、個別ＤＢの蓄積サイズ（データ量）が、サイズの上限を超えてしまう場合には、蓄積されているメールデータの古い順にメールデータを削除する。メールデータを長期間蓄積・保存するメールアーカイブ装置１００では、新しいメールデータほど検索の対象となる頻度が高く、古いメールデータほどその頻度は低いと考えられる。そのため、この実施の形態に係るメールアーカイブ装置１００によれば、検索頻度の高いメールデータに対しては高速な検索が可能であるとともに、蓄積のためのストレージ容量を削減することが可能になる。
【００５３】
実施の形態４．
この実施の形態では、実施の形態１のメールアーカイブ装置１００において、蓄積のためのストレージ容量を削減する実施の形態３とは異なる方法について説明する。この実施の形態におけるメールアーカイブ装置１００の構成は、実施の形態１（図１）と同様である。また、メールアーカイブＤＢの消去の手順も、実施の形態１で説明した通りである。
【００５４】
ここでは、実施の形態３同様に、索引記憶装置１１５やメール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８は、メールデータを削除する機能を備えたＤＢであるとする。
【００５５】
図１５は、この実施の形態に係るＤＢ構成管理テーブル１０４の一例を示す図である。
図１５に示すＤＢ構成管理テーブル１０４は、個別ＤＢの種別１５０１、ＤＢ名１５０２、個別ＤＢの有効／無効を表す状態情報１５０３、個別ＤＢの最大蓄積期間１５０４、実際に個別ＤＢに蓄積されている蓄積期間１５０５をテーブルで管理する。つまり、実施の形態１（図２）で示したＤＢ構成管理テーブル１０４の項目に加え、さらに、個別ＤＢの最大蓄積期間１５０４、実際に個別ＤＢに蓄積されている蓄積期間１５０５をテーブルで管理する。
ここで、蓄積されている期間とは、実施の形態３同様に、個別ＤＢに蓄積されている最も古いメールデータの送信日時と、最も新しい送信日時とを、それぞれ蓄積期間の開始の日時と終了の日時として記録するものである。また、最大蓄積期間とは、各個別ＤＢが記憶するメールデータの日時情報が示す日時の範囲を示す情報であり、図１５では、現在から遡ってどれだけの期間分の情報を記憶するかを示す。つまり、最大蓄積期間は、各個別ＤＢが記憶する日時の制限範囲を示す。
【００５６】
この実施の形態に係るメールアーカイブ装置１００のメールアーカイブＤＢ生成時の処理の流れを説明する。
メールアーカイブ装置１００の管理者は、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８の有効／無効と、最大蓄積期間とを指定するパラメータを入力として、ＤＢ生成要求を発行する。ＤＢ定義部１１０は、入力パラメータに従って、個別ＤＢの生成要求を各個別ＤＢ管理部（索引管理部１１１、メール管理部１１２、ヘッダ管理部１１３、テキスト管理部１１４）に発行する。また、ＤＢ定義部１１０は、各個別ＤＢの有効／無効と、最大蓄積期間とをＤＢ構成管理テーブル１０４に記録する。
【００５７】
この実施の形態に係るメールアーカイブ装置１００のメールデータの蓄積処理について説明する。
この実施の形態に係るメールアーカイブ装置１００の蓄積制御部１０３によるメールデータ蓄積処理は、実施の形態３における蓄積処理の流れ（図１２）と概ね同様である。この実施の形態では、図１２の（Ｓ１２０４）において、蓄積制御部１０３がＤＢ構成管理テーブル１０４を参照して、索引記憶装置１１５の実際の蓄積期間１５０５が、最大蓄積期間１５０４未満であるか否かを判定する。そして、蓄積制御部１０３は、索引記憶装置１１５の実際の蓄積期間１５０５が、最大蓄積期間１５０４を超えていると判定した場合、索引記憶装置１１５の最も古いメールデータを削除する。つまり、蓄積制御部１０３は、各個別ＤＢが記憶した情報のうち、メールデータに含まれる日時情報が示す日時が、最大蓄積期間１５０４に入らないメールデータから抽出された情報を各個別ＤＢから削除する。
【００５８】
この実施の形態に係るメールアーカイブ装置１００の検索処理は、実施の形態３に係るメールアーカイブ装置１００の検索処理と同様である。
【００５９】
以上のように、この実施の形態に係るメールアーカイブ装置１００によれば、ＤＢ構成管理テーブル１０４に、個別ＤＢの最大蓄積期間と、メールデータの蓄積期間とを記憶する。各個別ＤＢへのメールデータの蓄積時に、個別ＤＢの蓄積期間が、最大蓄積期間を超えていた場合には、蓄積されているメールデータの古い順に削除する。メールデータを長期間蓄積・保存するメールアーカイブ装置１００では、新しいメールデータほど検索の対象となる頻度が高く、古いメールデータほどその頻度は低いと考えられる。この実施の形態に係るメールアーカイブ装置１００によれば、検索頻度の高いメールデータに対しては高速な検索が可能であるとともに、蓄積のためのストレージ容量を削減することが可能になる。
【００６０】
以下に上記実施の形態の特徴をまとめる。
上記実施の形態に係るメールアーカイブ装置１００は、
メールデータを、メールデータ本体用のＤＢ、全文検索索引用のＤＢ、ヘッダのテキスト情報用のＤＢ、ヘッダ以外のテキスト情報用のＤＢと、複数の個別ＤＢに分けて蓄積するメールアーカイブ装置１００において、
各個別ＤＢが有効であるか無効であるかを管理するＤＢ構成管理テーブル１０４を備え、
メールデータの蓄積時には、ＤＢ構成管理テーブル１０４を参照して、有効な個別ＤＢに対してのみ、対応する情報を蓄積し、
検索時には、有効になっている個別ＤＢに対して検索要求を発行して検索結果を得ることを特徴とする。
【００６１】
また、上記メールアーカイブ装置１００において、そのＤＢ構成管理テーブル１０４に各個別ＤＢの検索速度を記録しておき、個別ＤＢの検索速度に応じて、検索要求を発行する個別ＤＢを選択するとともに、検索要求を発行する順序を変更することを特徴とする。
【００６２】
さらに、上記メールアーカイブ装置１００において、全文検索索引用ＤＢは、１以上のメールデータを削除する機能を備えているものとする。
つまり、ＤＢ構成管理テーブル１０４には、全文検索索引用ＤＢのサイズの上限と、索引の蓄積期間を記録しておき、
全文検索索引用ＤＢのサイズが、前記サイズの上限を超えた場合は、蓄積されているメールデータの中から最も古い順に削除して索引の蓄積期間を更新し、
検索時には、検索対象のメールデータが蓄積期間の範囲内であれば全文検索索引用ＤＢに検索要求を発行し、範囲外であればメールデータのテキスト情報用のＤＢに検索要求を発行することを特徴とする。
【００６３】
また、さらに、上記メールアーカイブ装置１００において、全文検索索引用ＤＢは、１以上のメールデータを削除する機能を備えているものとする。
つまり、ＤＢ構成管理テーブル１０４には、全文検索索引用ＤＢの最大蓄積期間と、索引の蓄積期間を記録しておき、
全文検索索引用ＤＢの蓄積期間が、前記最大蓄積期間を超えた場合は、蓄積されているメールデータの中から最も古い順に削除して索引の蓄積期間を更新し、
検索時には、検索対象のメールデータが蓄積期間の範囲内であれば全文検索索引用ＤＢに検索要求を発行し、範囲外であればメールデータのテキスト情報用のＤＢに検索要求を発行することを特徴とする。
【００６４】
なお、上記実施の形態では、索引記憶装置１１５、メール記憶装置１１６、ヘッダ記憶装置１１７、テキスト記憶装置１１８の４種の個別ＤＢからなる構成としたが、テキスト記憶装置１１８をさらにメールデータ本文のテキストと、添付ファイルのテキスト情報とに分けて蓄積するようにしてもよい。また、添付ファイルを元のファイルの形式のまま蓄積するようなＤＢを備えていてもよい。さらに、メールデータのメタ情報だけを、リレーショナルＤＢのような仕組で蓄積するようにしてもよい。
【００６５】
次に、上記実施の形態におけるのハードウェア構成について説明する。
図１６は、メールアーカイブ装置１００のハードウェア構成の一例を示す図である。
図１６に示すように、メールアーカイブ装置１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３、ＲＡＭ９１４、ＬＣＤ９１６（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）、キーボード９１７、通信ボード９１５、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
【００６６】
ＲＯＭ９１３、磁気ディスク装置９２０は、不揮発性メモリの一例である。ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３とＲＡＭ９１４とは、記憶装置の一例である。通信ボード９１５とキーボード９１７とは、入力装置の一例である。また、通信ボード９１５は、出力装置の一例である。さらに、通信ボード９１５は、通信装置の一例である。また、さらに、ＬＣＤ９１６は、表示装置の一例である。
【００６７】
磁気ディスク装置９２０又はＲＯＭ９１３などには、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【００６８】
プログラム群９２３には、上記の説明において「メール入力部１０１」、「テキスト属性入力部１０２」、「蓄積制御部１０３」、「ＤＢ構成管理テーブル１０４」、「検索条件入力部１０５」、「検索条件解析部１０６」、「検索制御部１０７」、「検索結果出力部１０８」、「検索結果管理部１０９」、「ＤＢ定義部１１０」、「索引管理部１１１」、「メール管理部１１２」、「ヘッダ管理部１１３」、「テキスト管理部１１４」等として説明した機能を実行するプログラムやその他のプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、上記の説明において「状態情報」等として説明した情報やデータや信号値や変数値やパラメータが、「ファイル」や「データベース」の各項目として記憶される。「ファイル」や「データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵ９１１の動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵ９１１の動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
また、上記の説明におけるフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、その他光ディスク等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００６９】
また、上記の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。また、「〜装置」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。さらに、「〜処理」として説明するものは「〜ステップ」であっても構わない。すなわち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、ＲＯＭ９１３等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、上記で述べた「〜部」としてコンピュータ等を機能させるものである。あるいは、上記で述べた「〜部」の手順や方法をコンピュータ等に実行させるものである。
【図面の簡単な説明】
【００７０】
【図１】実施の形態１に係るメールアーカイブ装置１００の機能を示す機能ブロック図。
【図２】実施の形態１に係るＤＢ構成管理テーブル１０４の一例を示す図。
【図３】実施の形態１に係るメールアーカイブ装置１００のメールデータの蓄積時の処理を示すフローチャート。
【図４】実施の形態１に係るメールアーカイブ装置１００のメールデータの検索処理の全体の流れを示したフローチャート。
【図５】検索条件の一例を示す図。
【図６】図５に示す検索条件から、生成される検索命令リストの一例を示す図。
【図７】図５に示す検索条件から、生成される検索命令リストの一例を示す図。
【図８】実施の形態１に係る検索条件解析部１０６が検索命令リストを生成する処理の流れを示すフローチャート。
【図９】実施の形態２に係るＤＢ構成管理テーブル１０４の一例を示す図。
【図１０】図５に示す検索条件から、生成される検索命令リストの一例を示す図。
【図１１】実施の形態３に係るＤＢ構成管理テーブル１０４の一例を示す図。
【図１２】実施の形態３に係るメールアーカイブ装置１００のメールデータの蓄積時の処理を示すフローチャート。
【図１３】実施の形態に係る検索条件解析部１０６が検索命令リストを生成する処理の流れを示すフローチャート。
【図１４】図５に示す検索条件から、生成される検索命令リストの一例を示す図。
【図１５】実施の形態４に係るＤＢ構成管理テーブル１０４の一例を示す図。
【図１６】メールアーカイブ装置１００のハードウェア構成の一例を示す図。
【符号の説明】
【００７１】
１００  メールアーカイブ装置、１０１  メール入力部、１０２  テキスト属性入力部、１０３  蓄積制御部、１０４  ＤＢ構成管理テーブル、１０５  検索条件入力部、１０６  検索条件解析部、１０７  検索制御部、１０８  検索結果出力部、１０９  検索結果管理部、１１０  ＤＢ定義部、１１１  索引管理部、１１２  メール管理部、１１３  ヘッダ管理部、１１４  テキスト管理部、１１５  索引記憶装置、１１６  メール記憶装置、１１７  ヘッダ記憶装置、１１８  テキスト記憶装置、９１１  ＣＰＵ、９１２  バス、９１３  ＲＯＭ、９１４  ＲＡＭ、９１５  通信ボード、９１６  ＬＣＤ、９１７  キーボード、９２０  磁気ディスク装置、９２１  オペレーティングシステム、９２２  ウィンドウシステム、９２３  プログラム群、９２４  ファイル群。
【図１】
0005121414.tif 000002
【図２】
0005121414.tif 000003
【図３】
0005121414.tif 000004
【図４】
0005121414.tif 000005
【図５】
0005121414.tif 000006
【図６】
0005121414.tif 000007
【図７】
0005121414.tif 000008
【図８】
0005121414.tif 000009
【図９】
0005121414.tif 000010
【図１０】
0005121414.tif 000011
【図１１】
0005121414.tif 000012
【図１２】
0005121414.tif 000013
【図１３】
0005121414.tif 000014
【図１４】
0005121414.tif 000015
【図１５】
0005121414.tif 000016
【図１６】
0005121414.tif 000017