JPH1115759A - 全テキストインデックス型のメール保存装置 - Google Patents

Abstract

(57)【要約】 【課題】 電子メールメッセージをアクセスする装置を
提供する。 【解決手段】 メールメッセージをアクセスする装置
は、メールメッセージを記憶する第１メモリと、メール
メッセージの全テキストインデックスを記憶する第２メ
モリとを含む。ネットワークにより第１及び第２メモリ
に接続されたクライエントコンピュータで構成された問
合せを用いてメールメッセージをアクセスする手段が設
けられる。問合せは、全テキストインデックスをサーチ
して、その問合せを満足するメールメッセージを探索す
る。又、この装置は、その探索されたメールメッセージ
をネットワークを経てクライエントコンピュータへ送信
するための手段も含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に、電子メー
ルに係り、より詳細には、分散型コンピュータシステム
における電子メールメッセージ処理に係る。

【０００２】

【従来の技術】インターネットのような大規模な分散型
コンピュータシステムの出現に伴い、コンピュータシス
テムのユーザに利用できる情報の量が飛躍的に増大し
た。この情報の中に電子メール（ｅ−メール）がある。
文書化メッセージを構成しそして配布する手段の改善に
伴い、インターネットにおけるｅ−メールトラフィック
の量が増大した。活動的なインターネットユーザが年間
に数万通のｅ−メールメッセージを受けることは例外で
はない。

【０００３】１つの効果として、インターネットは、ユ
ーザが有用な情報を適時に且つ便利に交換できるように
する。しかしながら、膨大な量の情報を追跡することが
問題となってきている。付加的な効果として、インター
ネットは、現在、ユーザが、テキストや音声や静止像及
び動画像のような多数の異なる提示方式で交換できるよ
うにする。このような複雑な情報を編成するようにｅ−
メールシステムを適応させ、そして情報をコヒレントに
検索する効率的な手段を提供することは、簡単ではな
い。

【０００４】

【発明が解決しようとする課題】１つの欠点として、イ
ンターネットのユーザは、メールリストへ送信したり、
ニュースグループに参加したりするときに、ジャンクメ
ールを受け取ることがある。特定のユーザが数千もの不
所望なメールメッセージで困惑されたという事例が多数
報告されている。現在のフィルタシステムは、このよう
な殺到を取り扱うのに充分ではない。ｅ−メールを構成
しそしてアクセスするための既知の分散型システムは、
通常は、ＩＭＡＰ、ＰＯＰ又はＳＭＴＰのようなプロト
コルのまわりに構築される。通常、ユーザは、メールサ
ービスがアクセスされようとしているクライエントコン
ピュータに互換性のあるユーザエージェントソフトウェ
アをインストールしなければならない。ユーザのクライ
エントコンピュータには著しい量の状態情報がしばしば
維持される。例えば、特定のユーザの全メールデータベ
ースをユーザのデスクトップコンピュータ又はラップト
ップコンピュータに記憶することも例外ではない。通
常、ユーザは、明らかに、メールメッセージをサブジェ
クトフォールダへと編成する。メールのアクセスは、一
般に、全メッセージをネットワークを経てクライエント
コンピュータへ搬送することを含む。

【０００５】このようなシステムは、多くの点で欠点が
ある。ユーザが遭遇するほとんどのコンピュータは、ユ
ーザのメールサービスに適合するユーザエージェントで
構成されない。ユーザの状態は、特定のクライエントコ
ンピュータにしばしば捕らえられ、これは、ユーザが別
のコンピュータへ移動するときに作業ができないことを
意味する。明確なフォールダ編成により多量の文書メー
ルメッセージを管理することは、ほとんどのユーザにと
って困難である。帯域巾の狭いネットワークを経てメー
ルをアクセスすることは、不充分になり勝ちである。そ
こで、これらの欠点を克服するメールシステムを提供す
ることが望まれる。

【０００６】

【課題を解決するための手段】本発明は、その広い形態
において、請求項１に記載の電子メールメッセージをア
クセスするための装置に係る。メールメッセージをアク
セスする装置について以下に説明する。この装置は、メ
ールメッセージを記憶する第１メモリと、メールメッセ
ージの全テキストインデックスを記憶する第２メモリと
を含む。メールメッセージは、ネットワークにより第１
及び第２メモリに接続されたクライエントコンピュータ
で構成された問合せを用いてアクセスされる。問合せ
は、全テキストインデックスをサーチし、その問合せを
満足するメールメッセージを探索する。探索されたメー
ルメッセージは、ネットワークを経てクライエントコン
ピュータに送られる。

【０００７】以下に述べるように、第１メモリは複数の
ファイルに仕切られ、そして各メールメッセージはメッ
セージ識別により独特に識別される。別の特徴において
は、独特のメッセージ識別は、複数のファイルの１つを
識別するファイル識別と、メッセージ番号とを含む。更
に、上記装置は、好ましくは、メールメッセージに関連
したラベルを追加及び除去する手段と、ラベル及びラベ
ルに関連した位置を記憶する第３メモリとを備えてい
る。

【０００８】

【発明の実施の形態】以下、添付図面を参照し、好まし
い実施形態を一例として詳細に説明する。システムの概要 図１において、構成体１００は、本発明による特徴を有
する分散型メールサービスを提供する。図１において、
１つ以上のクライエントコンピュータ１１１−１１３が
ネットワーク１２０を経て以下に述べるメールサービス
システム２００に接続される。

【０００９】クライエントコンピュータ クライエントコンピュータ１１１−１１３は、ワークス
テーション、ＰＣ、ラップトップ、パルムトップ、ネッ
トワークコンピュータ（ＮＣ）又は他の同様の構成のコ
ンピュータシステムである。クライエント１１１−１１
３は、所有することもできるし、借りることもできるし
又はレンタルすることもできる。実際には、クライエン
ト１１１−１１３は、潜在的に、現存してネットワーク
に接続された数百万のパーソナルコンピュータシステム
のいずれかである。時間と共に、ユーザは、異なるクラ
イエントコンピュータを異なる位置で使用する。

【００１０】コンピュータ１１１について示したよう
に、各クライエントコンピュータは、例えば、ＵＮＩＸ
（登録商標）、Ｗｉｎｄｏｗｓ９５（登録商標）、Ｍａ
ｃＯＳ（登録商標）又はＮＴ（登録商標）のような標準
的なオペレーティングシステムソフトウェア（Ｏ／Ｓ）
１１４を実行する。Ｏ／Ｓ１１４は、アプリケーション
ソフトウェアプログラムを実行するのに使用される。ク
ライエント１１０において実行できるアプリケーション
プログラムの１つは、ウェブブラウザ１１５である。ウ
ェブブラウザ１１５は、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇ
ａｔｏｒ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｅｘｐｌ
ｏｒｅｒ（登録商標）、Ｈｏｔ Ｊａｖａ（登録商
標）、及び他の同様のブラウザである。

【００１１】ブラウザ１１５の機能は、参照番号１１６
で一般に示されたフォーム、アプレット及びプラグイン
により拡張できる。好ましい実施形態では、ブラウザの
拡張は、以下に詳細に述べるクライエントメールアプリ
ケーションプログラムの形態である。クライエントメー
ルアプリケーションプログラムは、メールサーバシステ
ム２００からネットワーク１２０を経てダウンロードさ
れる。拡張は、最大のポータブル性を与えるように、Ｈ
ＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｊａｖａアプレット、
Ｍｉｃｒｏｓｏｆｔ ＡｃｔｉｖｅＸ（登録商標）又は
その組合せを用いて実施できる。

【００１２】コンピュータ１１２について示したよう
に、クライエントは、バス１２０により互いに接続され
た１つ以上のプロセッサ（Ｐ）１１７、メモリ（Ｍ）１
１８、入力／出力インターフェイス（Ｉ／Ｏ）１１９を
含む。プロセッサ１１７は、３２、６４又は他のビット
長さのデータ構造でＣＩＳＣ又はＲＩＳＣアーキテクチ
ャーを実施することができる。メモリ１１８は、ソリッ
ドステートダイナミックランダムアクセスメモリ（ＤＲ
ＡＭ）と、固定及び取り外し可能なメモリ、例えば、ハ
ードディスクドライブ、ＣＤ−ＲＯＭ、ディスケット及
びテープとを含むことができる。Ｉ／Ｏ１１９は、キー
ボード及びマウスのような入力装置と、ディスプレイ及
びプリンタのような出力装置に接続することができる。
又、Ｉ／Ｏ１１９は、サウンドカード、イメージプロセ
ッサ等のマルチメディアデバイスに接続するように構成
することもできる。又、Ｉ／Ｏは、ネットワーク１２０
への必要な通信リンクも与える。

【００１３】ネットワーク 好ましい実施形態では、ネットワーク１２０は、多数の
公衆アクセスポイントを含み、通信は、インターネット
プロトコル（ＩＰ）を用いて実行される。インターネッ
トプロトコルは、データを通信する標準的な方法として
広く認識されている。ＨＴＴＰ及びＦＴＰのような高レ
ベルプロトコルは、アプリケーションレイヤにおいて通
信し、一方、ＴＣＰ／ＩＰのような低レベルプロトコル
は、搬送及びネットワークレベルで動作する。

【００１４】インターネットの部分は、ワールドワイド
ウェブ又は省略して「ウェブ」と称するデータ交換イン
ターフェイスを含む。ウェブは、多数のソフトウェアパ
ッケージにより認識された規格に基づいて、データをフ
ォーマットし、通信し、相互接続しそしてアドレスする
ための方法を与える。例えば、ウェブを使用し、マルチ
メディア（テキスト、音声及び映像）データをウェブペ
ージとして構成することができる。ウェブページは、ユ
ニフォームリソースロケータ（ＵＲＬ）を用いてブラウ
ザ１１５により位置決めすることができる。

【００１５】ＵＲＬは、サーバやデータ記録のようなウ
ェブベースのリソースの正確な位置を特定する。この位
置は、ドメイン、サーバ、ユーザ、ファイル及び記録情
報、例えば、ＨＴＴＰ：／／ｗｗｗ．ｄｉｇｉｔａｌ／
ｃｏｍ／〜ｕｓｅｒｉｄ／ｆｉｌｅ．ｈｔｍｌ／〜ｒｅ
ｃｏｒｄを含むことができる。インターネットサービス
は、メールメッセージを送信及び受信するのに使用でき
る。例えば、メールメッセージは、ＳＭＴＰプロトコル
を用いて、アドレス「ｊｏｎｅｓ＠ｍａｉｌ．ｄｉｇｉ
ｔａｌ．ｃｏｍ」へメールを送ることができる。１つの
効果として、インターネット及びウェブは、ユーザが、
僅かな実際的な制約しかもたずに、どんな形式のコンピ
ュータシステムを使用するかに係わりなく、データを交
換できるようにする。

【００１６】イントラネット メールサービスシステム２００は、１つ以上のサーバコ
ンピュータを含む。通常、システム２００は、公衆ネッ
トワーク１２０に接続されたあるプライベートネットワ
ーク（イントラネット）の一部分である。一般に、イン
トラネットは、選択されたユーザベース、例えば、会社
のネットワーク、政府のネットワーク、又はある商業的
ネットワークに対してあるプライベートなエンティティ
によって動作される分散型コンピュータシステムであ
る。

【００１７】ファイアウオール 機密保護を与えるために、インターネットの要素とイン
トラネットの要素との間の通信は、ファイアウオール１
３０により頻繁にフィルタされそして制御される。ファ
イアウオール１３０の目的は、プライベートイントラネ
ットの機密方針を実施することである。１つのこのよう
な方針は、「クライエントコンピュータがインターネッ
トの公衆部分を経てイントラネットサーバへ直接接続す
ることを決して許さない」ことである。ファイアウオー
ルは、イントラネットの重要なリソース（サーバ及びデ
ータ）へのアクセスを保護するという役割も果たす。

【００１８】ある形式のデータトラフィックのみがファ
イアウオール１３０を横切ることが許される。ファイア
ウオール１３０の貫通は、トンネル１３１により得られ
る。トンネル１３１は、一般に、アクセスが許される前
に、機密のチャレンジ・アンド・レスポンスのシーケン
スを実行する。クライエントのユーザの認識が確証を得
ると、イントラネットの要素との通信が、ＳＳＬ及び
Ｘ．５０９証明書のような機密プロトコルを使用してプ
ロキシサーバ（図示せず）を経て実行される。

【００１９】メールサービスシステム メールサービスシステム２００は、局部的に又は広い地
域にわたり互いに接続された１つ以上のサーバコンピュ
ータとして実施することができる。サーバコンピュータ
は、その名前が示すように、クライエントコンピュータ
１１１−１１３に代わってサーバソフトウェアプログラ
ムを実行するように構成される。「サーバ」という用語
は、時には、ハードウェア、ソフトウェア又はその両方
を意味することができる。というのは、ソフトウェアプ
ログラムは、負荷条件に基づいて異なるサーバコンピュ
ータに動的に指定できるからである。サーバは、一般
に、多数のユーザのための大きな集中型データ貯蔵庫を
維持する。メールシステム２００において、サーバは、
ユーザの口座情報を維持し、メールメッセージを受け取
り、フィルタしそして編成し、メッセージの情報がいか
にエンコードされるかに係わりなく、それらを容易に位
置決めしそして検索できるようにする。

【００２０】一般的な動作 構成体１００の動作中に、クライエントコンピュータ１
１１−１１２のユーザは、ｅ−メールサービスを行うこ
とを希望する。これらの活動は、一般に、ｅ−メールメ
ッセージを構成し、読み取りそして編成することを含
む。それ故、クライエントコンピュータは、ＡＴ＆Ｔ又
はアースリンクのような公衆インターネットサービスプ
ロバイダー（ＩＳＰ）を用いてネットワーク１２０に接
続を行うことができる。或いは又、クライエントコンピ
ュータは、サイバースミスのような「サイバー・カフ
ェ」においてインターネットに接続することもできる
し、又はローカルエリアネットワークを経てイントラネ
ットそれ自体に接続することもできる。多数の他の接続
機構を使用することもできる。接続がなされると、ユー
ザは、メールサービスを実行することができる。

【００２１】１つの効果として、構成体１００の構造的
及び機能的特性は次のものを含む。システム２００のメ
ールサービスは、ウェブに接続されたいかなるクライエ
ントコンピュータによっても使用できる。サービスのユ
ーザは、全く移動可能であって、いかなるメール活動の
間にも異なるクライエント間を任意に移動することがで
きる。メールメッセージの構成は、あるクライエントに
おいてスタートし、別のクライエントにおいて完成し、
そして更に別のコンピュータから送信することができ
る。

【００２２】これらの特性の一部分は、後でアクセスが
行えない場合にユーザの状態をクライエントコンピュー
タの１つに決してロックしないことにより達成される。
これは、クライエントコンピュータのローカル記憶装置
に重要なデータが全く存在しないためにそのローカル記
憶装置をバックアップする必要がないという付加的な利
点を有する。本質的に、これは、オペレーティングプラ
ットホームがウェブであり、従って、ウェブを経てメー
ルサービスシステムへアクセスすれば、ユーザデータを
アクセスするのに充分であるという概念をベースとす
る。

【００２３】サービスシステムは、マルチメディアの形
態のデータを含むメールメッセージについても、広範囲
の接続帯域巾にわたって充分に機能する。大きな貯蔵庫
からのメッセージの検索は、複雑な分類機構を必要とせ
ずに、全テキストインデックスの問合せを用いて行われ
る。構成体１００は、多数のアクセス経路のような冗長
性技術、及び独立ディスクの冗長アレー（ＲＡＩＤ）技
術を用いた複製ファイルを組み込むように設計される。

【００２４】メールサービスシステム 図２に示すように、メールサービスシステムは、次の要
素を含む。システム２００は、フロントエンドとしてウ
ェブサーバ２１０を有するように構成される。サーバ２
１０は、ＷＷＷコンソーティウムから入手できる「Ａｐ
ａｃｈｅ」ウェブサーバである。ウェブサーバ２１０
は、バックエンドの共通のゲートウェイインターフェイ
ス（ＣＧＩ）プログラム２２０と対話する。このプログ
ラムは、口座マネージャー３００、ＳＴＭＰメールサー
バ２４０、及びインデックスサーバ２５０とインターフ
ェイスする。ＣＧＩプログラム２２０は、１つの考えら
れる機構である。又、このプログラムは、ウェブサーバ
２１０にコードを直接追加するか、又はＮｅｔｓｃａｐ
ｅからＮＳＡＰＩへの拡張を追加することにより実施す
ることもできる。

【００２５】システム２００の最上位レベルの機能は、
メール送信２４１、メール受信２４２、問合せインデッ
クス２４３、メールへの／からのラベル追加／除去２４
４、及びメール検索２４５を含む。機能２４１−２４５
を実施するプロセスに対して異なるサーバを使用するこ
とができる。口座マネージャー３００は、口座情報を維
持する。メールサーバ２４０は、ネットワークに接続さ
れた他のサーバへメールメッセージを送信したりそこか
ら受信したりするのに使用される。インデックスサーバ
２５０は、メッセージファイル４００のメールメッセー
ジ、及びメッセージに対する全テキストインデックス５
００を維持する。ＣＧＩプログラム２２０は、メールメ
ッセージの検索のためにフィルタ２８０を経てメッセー
ジファイル４００と対話する。

【００２６】ウェブサーバ２１０は、ＨＴＴＰプロトコ
ル２０１を用いてネットワークを経て通信するために適
当なプロトコルを実施する標準的なウェブサーバ、例え
ば、Ａｐａｃｈｅサーバである。ＣＧＩバックエンドプ
ログラム２２０は、ウェブサーバ２１０とメールサービ
スシステムの動作要素との間でトランザクションをルー
ト指定する。ＣＧＩバックエンド２２０は、サーバにお
いて実行されるＣ及びＴＣＬプログラムとして実施する
ことができる。

【００２７】口座マネージャー 図３に示すように、口座マネージャー３００は、メール
システム２００にアクセスすることが許されたユーザに
対する口座情報３０１−３０３を維持する。各口座に対
して維持される情報は、例えば、ポストオフィスプロト
コル（ＰＯＰ−３）アドレスの形態のメールボックスア
ドレス３１０と；ユーザパスワード３２０と；ラベル状
態３３０と；名前付けされた問合せ３４０と；フィルタ
問合せ３５０と；問合せ位置情報３６０と；ユーザの好
み３７０と；セーブされる構成状態３８０とを含むこと
ができる。口座情報の完全な意味及び使用は、システム
２００の他の要素を説明するときに明らかとなろう。

【００２８】最初に、パスワード３２０は、ユーザの確
証を得るのに使用される。ラベル３３０は、メールメッ
セージを編成しそして検索するのに使用される。ラベル
は、メッセージの寿命にわたってメッセージに追加した
り除去したりすることのできる注釈ノートに類似させる
ことができ、換言すれば、ラベルは変更可能である。ラ
ベルは、ユーザがそのメッセージをサブジェクトエリア
へと編成するのを助成する。ラベル状態は、いつでも、
特定のユーザに対してアクティブである全てのラベルを
捕獲する。ラベルについては、以下に詳細に説明する。

【００２９】システム２００において、メールメッセー
ジは、問合せを使用することによりアクセスされる。こ
れは、多数の既知のメールシステムに使用されるように
サブジェクトフォールダを明確に特定するのとは対照的
である。問合せは、１つ以上のスピーチ項で構成され、
これらのスピーチ項は、おそらく論理演算子で接続さ
れ、メッセージを検索するのに使用することができる。
問合せの名前を特定することにより、ユーザは、特定の
題目、フレーズ、日付、送信者等に関連したメッセージ
を容易に検索することができる。名前付きの問合せ３４
０は、口座情報の一部分として記憶される。

【００３０】ある問合せは、「フィルタ」問合せ３４０
として呼称することができる。これは、ユーザが、例え
ば、スパムとして一般に知られている「ジャンクメー
ル」を選別できるようにする。又、フィルタ問合せは、
特定のメールリストから受け取ったメッセージを予め分
類するのに使用することもできる。問合せ位置情報は、
ユーザが問合せで最後に選択したのがどのメッセージで
あるかを記録する。このように、ユーザインターフェイ
スは、問合せが再発行されたときに選択されたメッセー
ジに対してメッセージの表示を位置決めすることができ
る。ユーザの好み３７０は、図１の拡張されたブラウザ
１１６により実施されるメールサービスに対するユーザ
インターフェイスの外観及び機能を特定する。セーブさ
れる構成状態３８０は、ユーザが、メッセージを作成す
る間に多数の異なるクライエントコンピュータを使用し
てメッセージを構成しそして送信できるようにする。

【００３１】口座マネージャー３００は、新たな口座を
発生したり又は既存の口座を削除したりすることができ
る。口座は、ユーザの名前及びパスワードを特定するこ
とによりユーザに対して発生される。骨格となる口座が
発生されると、ユーザは、ラベル、名前付けされた問合
せ、フィルタ問合せ、等々の残りの情報を供給すること
ができる。

【００３２】メールサーバ ここで、図２を参照すると、メールサーバシステム２０
０は、ＰＯＰ−３プロトコルを用いてメールサーバ２４
０と通信することにより新たなメールメッセージを受け
取る（２４２）。メールメッセージは、ＳＭＴＰプロト
コルを使用して送られる（２４１）。メールサーバ２４
０は、ライン２４９によりインターネットに接続され
る。特定のユーザに対するメールサーバ２４０の適当な
ルート情報を、ユーザの口座が発生された後に、発生す
ることができる。「ＰＯＰ口座名」は、ユーザの名前と
して特定されねばならない。ほとんどのシステムにおい
て、名前は、ケースに敏感である。「ＰＯＰホスト」
は、メールサーバ２４０のインターネットドメイン名で
なければならない。ここで、レターのケースは無視され
る。「１６．４．０．１６」のようなＩＰアドレスを使
用できるが、ドメイン名が好ましい。ある場合には、特
定のユーザの好ましいインターネットｅ−メールアドレ
スは、ＰＯＰ口座名にもＰＯＰホストにも無関係とされ
る。メールサーバ２４０は、リンク２４９によりインタ
ーネットに接続される。

【００３３】現在オンラインで使用できる情報の量の急
速な拡張は、当該情報の探索を著しく困難なものにし
た。「私はそのメッセージをどのフォールダに記憶した
のか」という質問は、セーブしようとするメッセージの
数が長い時間周期にわたり数千にも増加した場合に、答
えることが困難なものとなる。アクセスされるメッセー
ジの重要性及び頻度は、変化し得る。従来の解決策は、
メールメッセージをハイアラーキ式に、例えば、ファイ
ル、フォールダ、サブフォールダ、サブ・サブフォール
ダ、等に構成するものであった。しかしながら、このよ
うな構造は、ファイリングの戦略が時間と共に一貫して
いないので、容易に拡張できないことが認識される。多
くのユーザは、長年にわたって累積される相当量のｅ−
メールメッセージに対してハイアラーキ構造が充分でな
いことが分かった。特に、メッセージの意味や関係が時
間と共に変化するからである。明確なファイリング戦略
を伴うほとんどのシステムは、ハイアラーキの順序を現
在の要求に一貫するよう保つために常に飽き飽きするほ
どの注意を必要とする。

【００３４】メッセージ貯蔵庫 メッセージは、メッセージファイル４００及び全テキス
トインデックスに記憶される。メッセージファイルの編
成について先ず説明する。これに続いて、全テキストイ
ンデックス５００の説明をする。本発明の特徴として、
メールメッセージとのユーザの対話は、主として、全テ
キストインデックス５００に予め形成された問合せによ
る。図４に示すように、インデックスサーバ２５０は、
各受け取ったメッセージ４０１−４０２に独特の識別
（ＭｓｇＩＤ）４１０を指定する。ＭｓｇＩＤ４１０
は、ファイル識別（ＦｉｌｅＩＤ）４１１及びメッセー
ジ番号（ＭｓｇＮｕｍ）４１２より成る。ＦｉｌｅＩＤ
は、「名前」であり、即ち特定のメッセージファイル４
２０に対するポインタであり、そしてＭｓｇＮｕｍは、
ファイル内のメッセージのある任意の番号、例えば、フ
ァイル４２０へのインデックスである。

【００３５】メッセージは、それがファイルされた後に
は決して変化しない。又、ＭｓｇＩＤ４１０は、同じメ
ッセージを永久に識別し、そしてそのメッセージのみの
ＩＤである。参照されたメッセージファイル２４０にお
いて、メッセージエントリー４３０は、フィールド４３
１に記憶されたＭｓｇＮｕｍと、ラベル４３２と、フィ
ールド４３３におけるメッセージ自体の内容とを含む。
メッセージを記憶するために維持される個別ファイル２
４０の数は、基礎となるファイルシステムの設計及び特
定の実施細部に依存する。例えば、特定のファイルのエ
ントリーのサイズ及び数は、ファイルシステムにより制
限される。又、多数のファイルをもつことは、バックア
ップ及び回復のようなファイル保守機能を容易にする。

【００３６】ラベルログ メッセージは決して変化しないが、メッセージに関連し
たラベルのセットは、変化し得る。ラベルは変化できる
ので、トランザクションログ４４０も維持される。ログ
４４０は、「加算」エントリー（＋ラベル）４５０と、
「除去」エントリー（−ラベル）４６０とを含む。各エ
ントリーは、作用を受けるメッセージエントリーのＭｓ
ｇＩＤ４５１又は４５３と、追加（４５２）又は削除
（４５３）されるラベルとを含む。ログ４４０の内容
は、時々、メッセージファイル２４０と合体される。合
体されたエントリーは、ログ４４０から除去される。ラ
ベルログ４４０は、ラベル、及びラベルの付けられたデ
ータが同じインデックスで記憶される場合に、メールメ
ッセージのようなデータ記録に取り付けられるラベルの
変化を考慮するものである。

【００３７】全テキストインデックス 図５及び６は、インデックスサーバ２５０が全テキスト
インデックス５００をいかに発生するかを示す。新たに
受け取られたメールメッセージは、バッチ４０３−４０
４で処理される。バッチのメッセージ４０１及び４０２
は、個々のワード５１０へとパーズされる。大きなメー
ルサービスシステムのバッチ４０３は、数百又は数千の
メッセージを含むことができる。メッセージのワード
は、それらがバッチにおいて受け取られた順序でパーズ
される。各ワードには、逐次の位置番号５２０が任意に
指定される。

【００３８】例えば、第１のバッチの第１のメッセージ
の第１のワードには、位置「１」が指定され、次のワー
ドには位置「２」が指定され、そして最後のワードには
位置「３」が指定される。次にメッセージの第１ワード
には、次の逐次位置「４」が指定され、等々となる。あ
る位置がワードに指定されると、その指定は決して変化
しない。位置が６４ビットの数字として表される場合に
は、位置に重畳が生じることはほとんどあり得ない。メ
ッセージがパーズされるときに、インデックスプロセス
が付加的な「メタワード」５３０を発生する。例えば、
メッセージ終了（ｅｏｍ）メタワードは、各メッセージ
の最後のワードについて発生される。メタワードには、
それらの発生を引き起こしたワードと同じ位置が指定さ
れる。ここに示す例では、第１のｅｏｍメタワードの位
置が「３」であり、そして第２が「５」である。

【００３９】例えば、「Ｔｏ」、「Ｆｒｏｍ」、「Ｓｕ
ｂｊｅｃｔ」及び「Ｄａｔｅ」フィールドのようなメッ
セージの他の部分は、全テキストインデックス５００の
編成を助けるための他の個別のメタワードを発生するこ
とができる。メタワードは、インデックスのサーチを容
易にするよう助成する。メタワードには所定のキャラク
タが添付され、メタワードが実際のパーズされたワード
と混同する機会がないようにされる。例えば、メタワー
ドは、ワードにおいて決して許されない「スペース」の
ようなキャラクタを含む。以下、「ワード」という用語
は、実際のワードと、合成されたメタワードの両方を意
味するものとする。

【００４０】メッセージのバッチがパーズされた後に、
ワード及びそれらの指定の位置が、第１に、ワードの照
合順序に基づき、そして第２に、それらの逐次位置に基
づいて分類される（５４０）。例えば、ワード「ｍｅ」
は、ボックス５５０で示すように、位置「３」及び
「５」に現れる。ワード及び位置の分類されたバッチ５
５０は、インデックスを発生するのに使用される。各分
類されたバッチ５５０は、最初は空のインデックス５０
０に合体される。

【００４１】インデックス構造 図６は、好ましい実施形態によるインデックス６００の
論理構造を示す。インデックスは、複数のワードエント
リー６１０を含む。各ワードエントリー６１０は、ある
インデックスされたメッセージに少なくとも一度は現れ
た独特の「ワード」に関連される。「ワード」という用
語は、ここでは、非常に漠然と使用される。というの
は、ワードのパージングは、実際に、どのマーク／キャ
ラクタがワードセパレータとして使用されるかに依存す
るからである。ワードは、辞書に見ることのできる真の
ワードである必要はない。セパレータは、スペース及び
句読点マークである。

【００４２】インデックス２５０は、ワードセパレータ
により輪郭定めされた別々の組のキャラクタとして識別
できるメッセージのいずれをもパーズする。日付もパー
ズされてインデックスに入れられる。日付は、日付範囲
のサーチが行えるようにインデックスされる。アクティ
ブなインデックスには数百万の異なるワードがある。そ
れ故、実際には、ファイルを適度なサイズに保持すると
共に、インデックス５００が使用されるときにこれを更
新できるように、圧縮技術が広範囲に使用される。

【００４３】ワードエントリー６１０は、ワードの照合
順序で記憶される。ワードは、エントリー６１０のワー
ドフィールド６１１に記憶される。ワードフィールド６
１１の後に、位置フィールド（ｌｏｃｓ）６１２が続
く。ワード６１１が発生するたびに１つの位置フィール
ド６１２がある。ブローズの参照文献に説明されたよう
に、位置は、実際には、記憶量を減少するためにデルタ
値のシーケンスとして記憶される。

【００４４】ラベル ラベルは、ユーザがメールメッセージに注釈を付ける方
法を与える。メッセージにラベルを付けることは、印刷
された文書に注を付けることに類似している。ラベル
は、多数の公知メールシステムにより使用されるフォー
ルダ機構に取って代わるように使用できる。しかしなが
ら、単一のメールメッセージに多数のラベルで注釈を付
けることができる。これは、好都合にも、メッセージを
単一のフォールダのみに記憶できるフォールダベースの
システムに匹敵する。

【００４５】ユーザは、機能すべき１組のラベルを定義
することができる。ラベルは、予め定められたテキスト
ストリング以外の何物でもない。特定のユーザに対する
現在アクティブな１組のラベル、例えば、図３のラベル
状態３３０は、口座マネージャー３００により維持さ
れ、そしてグラフィックユーザインターフェイスのウイ
ンドウに表示される。ラベルは、システム又はユーザに
より追加及び除去することができる。

【００４６】図６に示すように、ラベルは、全テキスト
インデックス５００の機能と並列で且つそれを拡張する
データ構造体６５０に記憶される。ラベルは、インデッ
クスワードと同じ制約を受ける。又、全テキストインデ
ックス５００の問合せは、ラベル及びワードをサーチ項
として含むことができる。ラベルは、特定のラベルによ
り参照される位置の組にメッセージ内の特定のインデッ
クス位置（１つ又は複数）を追加することにより、メー
ルメッセージに追加される。ラベルの除去は、これと反
対である。ラベルに対するオペレーションは、全テキス
トインデックスの状態を変化させる他のオペレーション
よりも非常に効率的である。

【００４７】ラベル状態３２０を表すラベルインデック
ス６５０のディスク上のデータ構造は、インデックスワ
ードエントリー６００について述べたものと同じであ
る。これは、ラベル状態が全テキストインデックス５０
０の拡張と考えられることを意味する。従って、ラベル
インデックス拡張は、インデックス５００と同様に、ラ
ベル（ワード）６５１をインデックス位置６５２のシー
ケンスへとマップする。

【００４８】ラベル拡張６５０及び全テキストインデッ
クス５００の構造フォーマットは、効率性の理由で同じ
であるが、インデックスのラベル部分は、全テキストイ
ンデックス５００を管理するソフトウェアとは異なるソ
フトウェア成分により管理される。問合せストリングの
項がラベルであると分かった場合には、ラベルインデッ
クス６５０がサーチされて、必要な位置マップが与えら
れる。このマップは、更に、最新の全てのラベル変化
（追加又は除去）を含むラベルログ４４０により修正さ
れる。ラベルログ４４０は、メモリ内バージョン６６０
を含むことができる。この構造に対するオペレーション
はメモリ内であるから、最新のラベル変化６６０に対す
る更新は、比較的高速であるが、ラベルインデックス６
５０の更新は、バックグランドで行うことができる。

【００４９】図７に示すように、メッセージ７００はヘ
ッダ７０１及び本体７０２を含む。ヘッダ７０１は、通
常、「Ｔｏ」、「Ｆｒｏｍ」、「Ｄａｔｅ」及び「Ｓｕ
ｂｊｅｃｔ」フィールドを含む。又、ヘッダは、ルート
情報も含む。本体７０２は、メールメッセージのテキス
トである。各メールメッセージは、２つのラベル、即ち
「ボックス内」７１０及び「非読み取り」７２０を最初
に受け取ることができる。「非読み取り」７２０とラベ
ル付けされたメッセージは、読み取りのためのまだ露出
されていない。「ボックス内」ラベル７１０をもつメッ
セージは、ユーザの注意を必要とすると思われる。以下
に説明するように、メッセージに非読み取りとラベル付
けすることはできるが、ボックス内ラベルをもつことは
できない。これらの重要性の低いメッセージは、必要に
応じてユーザにより読み取ることができる。

【００５０】メッセージの出力、例えば、メッセージの
表示又は印刷は、それが読み取られたという仮定のもと
で非読み取りラベル７２０を除去する。ユーザは、非読
み取りラベルを明確に追加又は除去することができる。
メッセージは、「削除」ラベル７３０を付けることによ
り削除できる。これは、削除というラベルの付いたメッ
セージが通常はサーチ中に除外されるので、メッセージ
が再び見られることはないという作用を有する。削除ラ
ベルの除去は、メッセージの「非削除」の作用を有す
る。

【００５１】好ましい実施形態では、メールメッセージ
であるデータ記録に対してラベルを使用するが、他の形
式のデータ記録に対して「変化可能」なラベルを使用す
ることもできる。例えば、追加及び除去することのでき
るラベルは、ウェブページ、又はニュースグループノー
トのようなデータ記録と共に使用することができる。こ
こでの重要な特徴は、ラベル付けされる記録と同じイン
デックスでラベルがインデックスされそしてラベルを追
加及び除去できることである。

【００５２】問合せ ｅ−メールメッセージがインデックスされそしてラベル
付けされた後に、全テキスト問合せを発行することによ
りメッセージを検索することができる。問合せは、その
問合せで特定されたワード及びラベルに一致するメッセ
ージをサーチする。これは、ユーザがどのファイル、フ
ォールダ又はサブフォールダにメッセージが入れられた
かを思い出すことによってメールをアクセスし、従っ
て、フォールダをサーチできる公知のメールシステムと
は対照的である。本発明のシステムの効果として、ユー
ザは、一致するメッセージを見出すのに、あるワード及
びラベルを想起するだけでよい。

【００５３】問合せ言語の構文は、ブローズの参照文献
に説明されたものと同様である。問合せは、「ａｎ
ｄ」、「ｏｒ」、「ｎｏｔ」、「ｎｅａｒ」等々の演算
子により結合された一連の原始的問合せ項を含む。原始
的な項とは、句読点マークを伴わない一連のアルファニ
ューメリックキャラクタ、即ち「ワード」である。項が
引用符（”）なしで包囲される場合には、引用されたス
トリングにおいて厳密な一致がサーチされる。項は、ラ
ベルであってもよい。「ｆｒｏｍ：ｆｒｅｄ」のような
項は、メッセージヘッダの「ｆｒｏｍ」フィールドにお
いてワード「ｆｒｅｄ」を有するメッセージをサーチす
る。ヘッダの「ｔｏ」、「ｆｒｏｍ」、「ｃｃ」及び
「ｓｕｂｊｅｃｔ」フィールドについても、同様の問合
せを形成することができる。

【００５４】「１１／２／９６−２５／Ｄｅｃ／９６」
のような項は、特定された日付範囲の全てのメッセージ
をサーチする。日付のパージングは融通性があり、例え
ば、１２／２５／９６、２５／１２／１９９６、及びＤ
ｅｃ／２５／９６は、全て同じ日付を意味する。あいま
いな場合には（２／１／９６）、ヨーロッパ式の順序
（日／月）が採用される。通常のオペレーション中に、
ＣＧＩプログラム２２０は、「削除」ラベル、例えば、
「ａｎｄ ｎｏｔ ｄｅｌａｔｅｄ」を除外する項を付
けることにより、各々の発行された問合せを変更する。
これは、クライエントのユーザから全ての削除されたメ
ッセージを隠すという作用を有する。削除されたメッセ
ージを見えるようにするためにこの作用を禁止するオプ
ションがユーザインターフェイスに存在する。

【００５５】名前付けされた問合せ 問合せは「名前付け」することができる。名前付けされ
た問合せは、口座マネージャー３００により維持され
る。問合せの名前を特定することにより、ユーザは、頻
繁に使用される項を含むｅ−メールメッセージのサーチ
を迅速に実行することができる。ユーザは、インデック
スされたメッセージのあるパターン、おそらく、特定の
テキスト又はラベルを有するメッセージについての混合
状態に一致するように複雑な問合せを構成し、そして後
で使用するように問合せを保持することができる。

【００５６】名前付けされた問合せは、公知のサブジェ
クトフォールダに取って代わるものとして考えることが
できる。メッセージを所定の条件に基づいてフォールダ
へと静的に編成するのではなく、問合せは、ユーザが現
在の１組のサーチ項に基づいてメッセージの特定の集合
を検索できるようにする。換言すれば、集合を定義する
条件が問合せとして動的に表現される。経過リスト 最近実行された問合せは、「経過」リストに保持され
る。従って、頻繁に実行される問合せは、例えば、新た
に受信したメールのために、又は他のクライエントコン
ピュータにより行われたアクションのために、インデッ
クスが変化されたときに、容易に再発行することができ
る。

【００５７】動的なアドレスブック 又、問合せは、公知の「アドレスブック」の機能を遂行
するように使用することもできる。多数の既知のｅ−メ
ールシステムにおいては、ユーザが頻繁に使用されるア
ドレスのアドレスブックを保持する。時々、ユーザは、
アドレスを追加及び除去することができる。従って、ア
ドレスブックは、個別のデータ構造体又はアドレスブッ
クファイルとして静的に維持される。例えば、「パーソ
ナル」及び「公衆」に関連したアドレスブックが存在し
得る。これに対して、ここでは、個別に記憶されるアド
レスブックは存在しない。むしろ、「アドレスブック」
は必要に応じて動的に発生される。動的なアドレスブッ
クは、ファイル４００及び全テキストインデックス５０
０から次のように発生される。

【００５８】図８に示すように、クライエントコンピュ
ータ８２０のユーザは、クライエントメールアプリケー
ションプログラム１１６の１つにより供給されるフォー
ム８００を使用してアドレスブック型の情報を発生する
ことができる。このフォーム８００は、例えば、名前、
電話番号、（ハードコピー）メールアドレス及び（ソフ
トコピー）ｅ−メールアドレス等のアドレス関連情報の
ためのエントリーフィールド８０１−８０３を含む。或
いは又、アドレス情報は、メッセージ８０５のヘッダ又
は本体の適当なフィールドでクリックすることにより、
以前に受け取ったメールメッセージ８０５から選択する
こともできる。

【００５９】メールサービスシステム２００及びインデ
ックスサーバ２５０の各々から、アドレスブック情報
は、受け取ったメールメッセージとして厳密に取り扱わ
れる。これは、例えば、フィールド８０１−８０３のデ
ータが「アドレスブック」メールメッセージ８１０へと
合成されることを意味する。又、「アドレス」ラベル８
０９は、ここに述べるラベル付け規定を用いてエントリ
ーに追加することができる。アドレスブックメールメッ
セージ８１０及びラベル８０９は、メッセージファイル
４００の１つに記憶することができる。更に、メッセー
ジ８１０は、他のメールメッセージのワード及びラベル
のように、パーズされて全テキストインデックス５００
へと挿入される。換言すれば、フォーム８００のアドレ
ス情報は、全テキストインデックス５００と合体及び混
合される。

【００６０】アドレス情報がファイルされてインデック
スされた後に、アドレス情報は、おそらくラベル「アド
レス」を問合せ項の１つとして標準的な問合せインター
フェイスを用いて問合せ８３０を構成するクライエント
コンピュータ８２０のユーザにより検索することができ
る。検索されるべき厳密な内容は、問合せ８３０の項及
び演算子がユーザにより構成されるときに決定される。
問合せを満足するアドレス情報即ち１つ以上のアドレス
ブックメールメッセージは、動的なアドレスブック８４
０としてクライエントコンピュータ８２０へ返送され
る。次いで、ユーザは、アドレスの１つを新たな応答又
は送りメールメッセージに対する「ｔｏ」アドレスとし
て選択することができる。

【００６１】メッセージの類似性 又、現在選択されたメッセージに類似するメッセージを
サーチすることもできる。この場合には、文書類似性技
術を使用できる。このような技術は、参考としてここに
取り上げる１９９６年８月９日にブローダ氏等により出
願された米国特許出願第０８／７３１，４５２号「文書
の類似性(Document Resemblance)」に説明されている。
これは、ユーザが、互いに密接に関連した全てのメッセ
ージを見出すことができるようにする。サーチ結果の分類 発行された問合せのサーチが完了したときには、サーチ
の結果がそれらのＭｅｓｓａｇｅＩＤ（図４）に基づく
順序で与えられる。実際に、これは、メッセージを受け
取ったときの時間的な順序で定質化メッセージが与えら
れることを意味する。

【００６２】ほとんどの公知のｅ−メールシステムは、
送信者によるか又はメッセージスレッド（関連メッセー
ジのシーケンス）によるような他の分類順序を許す。こ
のような機能は、ここでは、必要とされない。次のよう
な能力について考える。特定のユーザからのメッセージ
は、「ｆｒｏｍ：ｊｏｎｅｓ．」のような項を問合せに
含ませることにより特定できる。これは、特定のユーザ
からのメッセージのみを探索する。以下に述べるユーザ
インターフェイスの「ビュー・ディスカッション」オプ
ションを使用することにより特定の「スレッド」のメッ
セージを選択することができる。上記のように、特定の
データ範囲に対するメッセージは問合せにおいて指定す
ることができる。

【００６３】メッセージのフィルタ動作 特に多量のｅ−メールを受信する者に対するメールの取
り扱いを容易にするために、ユーザは、図９に示すよう
に、ユーザ自身の好みでフィルタ２８０を構成すること
ができる。メッセージフィルタは、１つ以上の名前付け
された「フィルタ」問合せ９１０として特定される。こ
の名前付けされた問合せ９１０は、図３の口座情報の一
部分として記憶される。名前付けされた問合せ９１０
は、メールサービスシステム２００からダウンロードさ
れるクライエントメールアプリケーションプログラムを
用いてクライエントコンピュータ９２０において構成す
ることができる。

【００６４】メールサービスシステム２００により受信
された新たなメッセージ９３０は、上記のように、メッ
セージファイル４００及び全テキストインデックス５０
０において記憶され、パーズされそしてインデックスさ
れる。更に、各新たなメッセージ９３０は、名前付きの
問合せ９１０と比較することができる。新たなメッセー
ジ９３０の内容が名前付きフィルタ問合せ９１０のいず
れとも一致しない場合には、新たなメッセージ９３０に
ボックス内ラベル７１０及び非読み取りラベル７２０が
与えられ、即ちメッセージは、ユーザの注意のために
「インボックス」９４０に入れられる。さもなくば、新
たなメッセージ９２０には、非読み取りラベル７２０が
与えられるだけである。

【００６５】例えば、送出されるメールは、通常、送信
者の名前を含む「ｆｒｏｍ」フィールド、例えば、「Ｆ
ｒｏｍ：Ｊｏｎ Ｄｏｅ」をメッセージヘッダに有す
る。或いは又、メールメッセージの本体がテキスト「Ｙ
ｏｕ ａｒｅ ｇｅｔｔｉｎｇｔｈｉｓ ｍｅｓｓａｇ
ｅ ｆｒｏｍ ｙｏｕｒ ｇｏｏｄ ｆｒｉｅｎｄＪｏ
ｎ Ｄｏｅ」を含んでもよい。ユーザＪｏｎ Ｄｏｅ
は、名前付きフィルタ問合せ「ＳｅｎｔＢｙＭｅ」を
「ｆｒｏｍ ｎｅａｒ（Ｊｏｎ Ｄｏｅ）」と設定する
ことができる。この問合せは、ワードフレーズ「Ｊｏｎ
Ｄｏｅ」付近のワード「ｆｒｏｍ」を含むメッセージ
に一致する。その作用は、ユーザが、フィルタ問合せ９
１０に一致するメッセージが明確に分からないようにす
ることである。例えば、ユーザは、自分への「ｃｃ」コ
ピーであるメッセージをフィルタすることを希望しても
よい。又、ユーザは、既知のドメインにおける商業上の
ｅ−メール分配者から到着するジャンクｅ−メールメッ
セージ、又はメールリストを経て受け取られる予め分類
されたメッセージをフィルタ除去することを希望しても
よい。

【００６６】メッセージ表示オプション ユーザの見地から、メールサービスへのアクセスは、Ｊ
ａｖａアプレットのようなウェブブラウザへの拡張によ
り実施される。メッセージは、通常は、それらの主たる
成分がＨＴＭＬフォーマットでクライエントに送信され
そしてＪａｖａアプレットのウインドウに表示されるこ
とにより表示される。表示されたメッセージの第１行
は、「ホットリンク」を含み、ユーザはこれをクリック
して、メッセージを、ＨＴＭＬフォーマット又はシステ
ムで理解されないオリジナルテキストとしてウェブブラ
ウザのウインドウの１つに表示することができる。イン
ターネットメッセージのヘッダは、ルートに基づいて、
かなりの長さになることを理解されたい。それ故、ヘッ
ダの「ｆｒｏｍ」、「ｔｏ」、「ｃｃ」、「ｄａｔａ」
及び「ｓａｂｊｅｃｔ」フィールドのみを見るように制
限することができる。

【００６７】埋め込まれたリンク 検索されたメッセージを表示するときには、システム２
００は、ｅ−メールアドレスの構文を有するテキストス
トリングを発見的に探索する。ユーザがこれらのアドレ
スの１つにおいてクリックすると、システムは、以下に
述べる構成ウインドウを表示し、従って、ユーザは、選
択されたｅ−メールアドレスへの応答メッセージを容易
に発生することができる。

【００６８】同様に、検索されたメッセージを表示する
ときには、システム２００は、ＵＲＬの構文を有するテ
キストストリングを発見的に探索し、そしてそのストリ
ングをホットリンクにする。ユーザがホットリンクにお
いてクリックすると、ＵＲＬは、ブラウザへ通され、ブ
ラウザは、ネットワークを経て内容を検索すると共に内
容を通常のやり方で処理する。又、システムは、明確に
「取り付けられた」又は暗示的に「埋め込まれた」ファ
イルのようなメッセージの成分を検出するよう試みる。
ファイルは、いかなる数の考えられるフォーマットであ
ってもよい。これらファイルの内容は、ブラウザ１１５
により表示される。使用する特定の表示動作は、異なる
成分ファイルフォーマットに応答するようにブラウザを
いかに構成するかによって左右される。

【００６９】例えば、ＧＩＦ及びＪＰＥＧのようなある
ファイルフォーマットについては、成分を直接表示する
ことができる。又、「アイコン」のような特定のフォー
マット形式を有する取り付けられたファイルを「表示」
するために、「ヘルパー」アプレットでブラウザを構成
することもできる。例えば、メッセージは、音声メッセ
ージの形態でもよく、この場合は、メッセージを「言
う」必要があり、表示されない。あるメッセージフォー
マットについては、ブラウザは、ある内容をクライエン
トコンピュータのファイルシステムに記憶する。

【００７０】低帯域巾のフィルタ動作 クライエントコンピュータ１１１−１１３は、低帯域巾
のネットワーク接続を経てメールサービスシステムにア
クセスするので、メールサービスシステムからクライエ
ントコンピュータへ送られるデータの量を最小にする試
みがなされる。高速通信チャンネルを経る場合でも、ネ
ットワークトラフィックの量を最小にすることは、ユー
ザの対話を改善することができる。メールサービスシス
テム２００は、取り付けられた又は埋め込まれたマルチ
メディアファイルをメールメッセージに含ませることが
できるので、メールメッセージは、かなり長いものとな
る。公知技術においては、ファイルを含む全メールメッ
セージは、通常、クライエントコンピュータへ搬送され
る。従って、メールメッセージのいかなる部分も、メッ
セージがクライエントに受信された後にユーザにより直
ちに読み取ることができる。

【００７１】図１０に示すように、メールサービスシス
テム２００は、このように含まれたメッセージ成分を確
認することができる。システム２００は、メッセージ１
０００に明確に取り付けられたファイル１０１０を見つ
けることができ、そしてシステム２００は、メッセージ
にＭＩＭＥ構造を伴わずに暗示的に埋め込まれたテキス
ト成分１０２０−１０２１を発見的に見つけることがで
きる。例えば、システム２００は、埋め込まれた「非エ
ンコード」の開示、ベース６４の開示、ポストスクリプ
ト（及びＰＤＦ）文書、ＨＴＭＬページ、及びＭＩＭＥ
断片を確認することができる。

【００７２】従って、システム２００は、「ＭＩＭＥ」
フィルタ１００１を用いて異なるフォーマットでエンコ
ードされたこのような成分１０１０、１０２０−１０２
１を「ホールドバック」するように構成される。取り付
けられた及び埋め込まれた成分は、縮小サイズのメッセ
ージ１０３０においてホットリンク１０３１に置き換え
られる。ホットリンク１０３１の１つにおいてユーザが
クリックしたときだけそれら成分がその要求を発してい
るクライエントコンピュータに送信される。

【００７３】クライエントコンピュータのユーザインタ
ーフェイス システム００のｅ−メールサービスを提供するようにウ
ェブブラウザ１１５がいかに構成されるかについて説明
する。ここに述べる機能は、プルダウンメニューとして
表示することもできるし、又は所望の見掛けに基づいて
ボタンバーとして表示することもできる。好ましくは、
これら機能は、Ｊａｖａアプレットとして実施される。ファイルメニュー ファイルメニューは、次のオプション、即ち管理(Admin
istration)、好み(Preference)及び退出(Quit)を有す
る。ユーザが管理オプションボタンでクリックした場合
には、システム２００は、システム管理ページをブラウ
ザ１１６にロードする。アクセス制御を受ける管理ウイ
ンドウを使用して、ユーザは、口座を見て変更すること
ができると共に、サーバログファイルを見ることができ
る。好みのオプションは、ユーザの好み３７０を変更す
るのに使用される。退出は、主たるログインウインドウ
へ復帰する。

【００７４】問合せメニュー このメニューは、「見て検討する」、「名前現在問合
せ」、「名前付きの問合せを忘れる」、「削除されたメ
ッセージを除外する」及び「あなたの問合せ」のオプシ
ョンを含む。「見て検討する」オプションは、現在選択
されたメッセージに関連するメッセージのための問合せ
を発行する。ここで、「関連する」とは、ほぼ同じサブ
ジェクトラインを共用するメッセージを意味し、及び／
又は共通の標準的な「ＲＦＣ８２２」メッセージＩＤに
よりリンクされたメッセージ（１つ又は複数）に対する
応答である。

【００７５】「名前現在問合せ」は、ユーザがテキスト
ストリングを現在問合せに取り付けられるようにする。
これは、ユーザがその後に使用することを考慮してシス
テム２００が問合せを入れるようにする。「名前付きの
問合せを忘れる」オプションは、名前付きの問合せを削
除する。「削除されたメッセージを除外する」オプショ
ンは、削除されたラベルを有する全てのメッセージを問
合せ結果から除去する。これは、デフォールトオプショ
ンである。このオプションにおいてクリックすると、問
合せに応答して「削除」されたメッセージを含むように
システム２００の振る舞いを変更する。「あなたの名前
付き問合せ」オプションは、特定のユーザの１組の名前
付き問合せ３４０を表示する。表示された名前のいずれ
かにおいてクリックすると、問合せを発行する。

【００７６】ラベルメニュー このメニューは、「ラベルの記録」及び「ラベルの忘
却」オプションを含む。これらのオプションは、ラベル
状態３３０へのラベルの追加及びそこからのラベルの除
去を各々考慮するものである。経過メニュー クライエントは、問合せの再発行を許すために、例え
ば、最後の１０個の問合せの経過を保持する。このメニ
ューのオプションは、「逆行」、「現在問合せのやり直
し」、「前進」及び「経過リスト」である。「逆行」
は、現在問合せに先行する問合せを再発行する。「やり
直し」は、現在問合せを再発行する。このオプション
は、最近受け取ったメッセージを処理するのに有用であ
り、又はユーザの動作がメッセージファイル４００を他
の何らかの仕方で変更した場合に有用である。「前進」
は、現在問合せに続く問合せを再発行する。「経過リス
ト」は、最近発行された問合せの全てを表示する。リス
トされたいかなる問合せも、その問合せにおいてクリッ
クすることにより再発行することができる。

【００７７】メッセージメニュー ここでのオプションは、「全部を選択」、「非読み取り
を選択」、「読み取りを選択」、「非読み取りとマー
ク」、「読み取りとマーク」、「ラベル追加」、「ラベ
ル除去」及び「内蔵ビューアの使用」を含む。「全部を
選択」にオプションは、現在問合せに一致する全てのメ
ッセージを選択する。次の２つのオプションは、非読み
取りラベルをもたない及びもつメッセージを各々選択す
る。これに続く２つのオプションは、現在選択されたメ
ッセージにラベルを追加及び削除する。ユーザインター
フェイスは、通常、メッセージをＨＴＭＬフォーマット
に変換しそしてそれをＨＴＭＬビューアに送ることによ
りメッセージを表示し、ＨＴＭＬビューアは、ブラウザ
の主たるウインドウにあってもよいし又は内蔵ビューア
であってもよい。メッセージメニューの最後のオプショ
ンは、ビューアを選択する。

【００７８】ヘルプメニュー ヘルプオプションは、システムの種々の特徴をいかに使
用するかについて情報ページを表示するのに使用でき
る。ヘルプページは、要求に応じて、メールサービスシ
ステム２００からクライエントコンピュータへダウンロ
ードされる。主たるウインドウニューバー このメニューバーは、次の機能のためのボタンを含む。
これら機能は、ボタンをクリックすることにより可能に
される。 「追加」：このボタンは、選択されたラベルをメッセー
ジに追加するのに使用される。 「再ラベル」：このボタンは、ラベルを除去しそして追
加する機能を組み合わせたものである。

【００７９】「削除」：このボタンでは、削除されたラ
ベルがメッセージに追加される。 「ラベル除去」：問合せに示された単一のラベルをメッ
セージから除去するのに使用される。 「次」：次のメッセージを選択する。 「Ｐｒｅｖ」：手前のメッセージを選択する。 「ニューメール」：ボックス内ラベルを有する全てのメ
ッセージのための問合せを発行する。 「問合せ」：問合せを構成しそして発行するダイアログ
を与える。

【００８０】メッセージ表示ボタンバー このボタンバーは、次の機能を実行するのに使用され
る。 「取り外し」：選択されたメッセージを表示するために
新たな最上位レベルのウインドウを形成する。 「構成」：新たなメールメッセージを構成するためのウ
インドウを発生する。 「送り」：この機能は、新たなメッセージを構成するた
めのウインドウを設定する。選択されたメッセージは、
新たなメッセージに取り付けられる。取り付けられたメ
ッセージは、クライエントコンピュータにメッセージを
ダウンロードする必要なく送られる。 「全てに対する応答」：この機能は、選択されたメッセ
ージの場合と同じ受信者と共に新たなメッセージを構成
するためのウインドウを設定する。

【００８１】「送信者に対する応答」：選択されたメッ
セージの送信者への新たなメッセージを構成するための
ウインドウを設定する。

【００８２】構成ウインドウ 構成ウインドウへのアクセスは、「構成」、「送り」、
「応答」又は「変更」ボタンにおいてクリックするか、
又は表示されたメッセージの「ｍａｉｌ−ｔｏ」ホット
リンクにおいてクリックすることにより得られる。構成
は、新たなメッセージを開始し、送りは、既に受け取っ
たメッセージを誰かに送信するのに使用され、応答は、
メッセージに応答することであり、そして変更は、まだ
送られていないメッセージを変更できるようにする。メ
ールサービスは、ユーザが一度に多数のメッセージを構
成できるようにする。

【００８３】メッセージのテキストは、使用可能な構成
ウインドウを用いるか、又は何れも使用できない場合に
はウインドウを発生してタイプされる。構成ウインドウ
のタイプエリアの厳密な形態は、特定のクライエントコ
ンピュータに使用されるウインドウシステムの性質に依
存する。典型的に、タイプ動作の間に、ユーザは、カッ
ト、ペースト、コピー、削除、取り消し等の編集動作の
ための近道を使用することができる。

【００８４】別のメッセージからの次の部分は、「ｉｎ
ｓｅｒｔ Ｍｓｇ」又は「Ｑｕｏｔｅ Ｍｓｇ」ボタン
を使用することにより挿入することができる。全メッセ
ージを含ませるべき場合には、「送り」ボタンを使用し
なければならない。メッセージは、「送信」機能が選択
されるまで実際には送られない。メッセージが構成され
る間には、それがメールシステムにより周期的にセーブ
される。従って、オフィスの１つのクライエントコンピ
ュータを使用してスタートした構成セッションは、ある
時間の後に別のコンピュータを用いて容易に構成するこ
とができる。 「送信」：メッセージを送信する。メッセージを送信す
る前に添付物が含まれる。ユーザは、状態メッセージに
より無効の受信が通知され、メッセージの編集を続ける
ことができる。さもなくば、ウインドウは、読み取り専
用モードに切り換えられる。

【００８５】「閉止」：メッセージが送信された後又は
破棄ボタンがクリックされた後に、このボタンは、送信
ボタンに取って代わり、構成ウインドウを閉じることが
できるようにする。 「破棄」：このボタンは、構成されているメッセージを
破棄しそしてウインドウを読み取り専用に切り換えるの
に使用される。ユーザは、次いで、閉止又は変更ボタン
をクリックすることができる。

【００８６】「変更」：メッセージが首尾良く送られる
か、又は破棄ボタンがクリックされた後に、このボタン
は、破棄ボタンに代わって現れ、ユーザが、現在メッセ
ージから導出された別のメッセージを構成できるように
する。 「包み」：この機能は、１行のキャラクタ数を、あるメ
ールシステムに必要とされる８０に制限するのに使用さ
れる。 「ｉｎｓｅｒｔ Ｍｓｇ」：選択されたテキストを、選
択されたメッセージからの表示テキストに置き換える。 「Ｑｕｏｔｅ Ｍｓｇ」：各行の前に「＞」キャラクタ
がくるように、選択されたテキストを、選択されたメッ
セージからの表示テキストに置き換える。 以上、本発明の好ましい実施形態を説明したが、本発明
の概念を組み込んだ他の実施形態も本発明の範囲内で使
用できることが当業者に明らかであろう。

【図面の簡単な説明】

【図１】本発明を使用する分散型メールサービスシステ
ムの構成を示すブロック図である。

【図２】図１の構成のメールサービスシステムのブロッ
ク図である。

【図３】図２のシステムの課金マネージャー及び課金記
録を示すブロック図である。

【図４】図２のシステムにより維持されるメッセージ及
びログファイルのブロック図である。

【図５】図２のシステムによって処理されるメールメッ
セージに使用されるパージング機構の流れ線図である。

【図６】図４のメッセージファイルのための全テキスト
インデックスのブロック図である。

【図７】ラベル付きメッセージを示す図である。

【図８】アドレスブックエントリーの図である。

【図９】問合せをフィルタするための流れ線図である。

【図１０】ＭＩＭＥフィルタのブロック図である。

【符号の説明】

１００ 分散型メールサービスシステムの構成体 １１１−１１３ クライエントコンピュータ １１４ オペレーティングシステムソフトウェア １１５ ブラウザ １１７ プロセッサ １１８ メモリ １１９ 入力／出力インターフェイス １２０ ネットワーク １３０ ファイアウオール １３１ トンネル ２００ メールサービスシステム ２１０ ウェブサーバ ２２０ ゲートウェイインターフェイスプログラム ２４０ ＳＴＭＰメールサーバ ２５０ インデックスサーバ ４００ メッセージファイル ３００ 口座マネージャー

───────────────────────────────────────────────────── フロントページの続き (72)発明者 エドワード ピー ウォーバー アメリカ合衆国 カリフォルニア州 94025 メンロ パーク サンタ モニカ アベニュー 460 (72)発明者 マイケル シュローダー アメリカ合衆国 カリフォルニア州 95014 クーパーティノ ウェスターン ドライヴ 10151

Claims (7)

【特許請求の範囲】
1. 【請求項１】 電子メールメッセージをアクセスしそし
   て送信する装置において、 メールメッセージを記憶する第１メモリと、 メールメッセージの全テキストインデックスを記憶する
   第２メモリと、 ネットワークにより第１及び第２メモリに接続されたク
   ライエントコンピュータで構成された問合せを用いてメ
   ールメッセージをアクセスする手段とを備え、上記問合
   せは、全テキストインデックスをサーチして、その問合
   せを満足するメールメッセージを探索するものであり、
   そして探索されたメールメッセージをネットワークを経
   てクライエントコンピュータに送信するための手段を更
   に備えたことを特徴とする装置。
2. 【請求項２】 上記第１メモリは複数のファイルに仕切
   られ、そして各メールメッセージはメッセージ識別によ
   り独特に識別される請求項１に記載の装置。
3. 【請求項３】 上記独特のメッセージ識別は、複数のフ
   ァイルの１つを識別するファイル識別と、メッセージ番
   号を含む請求項２に記載の装置。
4. 【請求項４】 メールメッセージに関連したラベルを追
   加及び除去する手段を更に含み、そしてラベル及びラベ
   ルに関連した位置を記憶する第３メモリを更に含む請求
   項３に記載の装置。
5. 【請求項５】 ラベルログファイルを複数のファイルと
   合体するための手段を更に含む請求項４に記載の装置。
6. 【請求項６】 各メールメッセージはヘッダ及び本体を
   含み、そして更に、ヘッダ及び本体をワードへとパーズ
   するための手段と、各パーズされたワードに独特の位置
   を関連させそしてワード及びそれに関連した独特の位置
   を全テキストインデックスとして第２メモリに記憶する
   ための手段とを備えた請求項１に記載の装置。
7. 【請求項７】 特定のメッセージに関連した特定のラベ
   ルに、特定のメッセージのワードの１つに関連した位置
   の１つが指定され、そして第３メモリに記憶されたラベ
   ル及びラベルの関連位置が問合せにより組合せに使用さ
   れる請求項４又は６に記載の装置。