JP2000003321A

JP2000003321A - 高性能なメッセ―ジ格納構造

Info

Publication number: JP2000003321A
Application number: JP11119493A
Authority: JP
Inventors: William J Yeager; ウイリアム・ジェイ．・イーガー
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1998-04-27
Filing date: 1999-04-27
Publication date: 2000-01-07
Also published as: GB2340269A; DE19919146A1; GB2340269B; US6167402A; GB9909139D0

Abstract

(57)【要約】【課題】効率的なメッセージ格納構造、及び配信シ
ステムを生成するための方法、装置、及びコンピュータ
読み取り可能媒体を提供する。【解決手段】メッセージ格納構造は、全てページベース
のインデックスディレクトリ、インデックスファイル、
及びデータバケット領域を有する。各ページは、例えば
日のような期間に対応している。各データバケットは、
メッセージデータ及びメッセージの実コンテンツを含
む。インデックスファイルは、関連メッセージを特徴付
けるインデックス情報を格納するインデックスファイル
セルを含む。インデックスディレクトリは、関連インデ
ックスファイルセルのロケーション上に情報を格納する
インデックスディレクトリセルを含み、これによりイン
デックスディレクトリは、メッセージと関連付けられ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的に、コンピ
ュータソフトウェア及びクライアント−サーバの技術に
関する。より詳細には、本発明は、コンピュータネット
ワークを介してクライアントによりアクセスされる電子
メールメッセージデータの編成及び格納構造に関する。

【０００２】

【従来の技術】１９９０年代におけるネットワークコン
ピューティングの急速な成長は、最も一般的に「電子メ
ール」と呼ばれる、ますます広まりつつある通信形式を
伴ってきた。家庭、勤務先、小規模企業、学術機関、あ
るいは、政府組織において、何らかの種類のコンピュー
タネットワークに接続されているコンピュータにより多
くの個人がアクセスするにつれ、電子メールは、瞬く間
に好ましい通信形式になりつつある（多くの場面では既
になっている）。人々は、簡単な一度きりのメッセージ
を送る場合であれ、長期にわたり討論、又は、会話を継
続する場合であれ、電子メールが、通信のための有用で
効率的な手段であることを認識している。

【０００３】電子メールは、組織の内部ネットワーク内
でメッセージを送るために、企業、及び大学といった大
規模組織内では長年にわたり用いられ、また、一般的
に、独自のフォーマット及びプロトコルに基づいてい
る。大規模組織の外部へ電子メールを持ち出し、社会の
本流に持ち込んだのはインターネットである。インター
ネットは、公的にアクセス可能でグローバルなコンピュ
ータネットワークなので、その電子メール能力に鑑み徐
々に利用されるようになってきた。さらに、インターネ
ットプロトコル（ＩＰ）、及びインターネットの通信層
（ＴＣＰ／ＩＰ）は、独自のフォーマット及びプロトコ
ルに代わって、ＩＰ及びＴＣＰ／ＩＰに基づき私的組織
内におけるイントラネットとして知られているコンピュ
ータネットワークを開発するために用いられてきた。こ
の解決手段は、例えば、企業又は大学が、インターネッ
トとの互換性を有すると共に、ウェブサイト、ハイパー
リンク能力、そして、当然ながら電子メールの送受信を
含むインターネットの全ての特徴を有する、内部コンピ
ュータネットワークを所有することを許容する。

【０００４】インターネットの爆発的な成長、及びイン
トラネットの魅力の増加は、電子メールメッセージの急
激な増加をもたらした。一般的に、電子メールメッセー
ジは、ネットワークサーバ、あるいは、クライアント及
びスタンドアローンマシンのハードドライブ上で受信及
び格納される。電子メールメッセージを電子的に保存
し、また、所望のときに簡単に取り出すという増大しつ
つある傾向又は実践及び多くの場合ニーズがある。この
ことは、例えば、アイデア、コメント又は分析を含むメ
ッセージが、例えば、異なる国の研究者の間で数年の期
間にわたり送られる場合には、あらゆる類型の研究状況
において重要になり得る。例えば、今はその立場にない
２人の研究者の間で２年前のある時に送られたあるメッ
セージを取り出さざる負えない状況が予測される。もち
ろん、この能力は、ビジネス環境、または、他の状況に
おいても重要且つ有用な特徴になり得る。

【０００５】セーブ済メッセージの取り出しについての
増大する要求と結びつく電子メールの増大、及びセーブ
されるべきメッセージ数の増加は、現在のインデックス
修飾方式及びメッセージについての問題を露呈した。メ
ッセージをクライアントマシン上でなく、サーバ上にセ
ーブする傾向が増えつつある。メールサーバは、メッセ
ージの中央集積所として機能すると共に、定期的にバッ
クアップされ、管理者によって維持され、壊れた（クラ
ッシュした）ときには（ほとんどの場合）迅速に復旧さ
れるという利点を有している。したがって、ユーザがリ
クエストすると、リクエストはサーバによって処理され
ると共にクライアントに配信される。

【０００６】今日における電子メールメッセージの文法
は、リクエストの類型によって幅広く変化し得る。簡単
な例では、電子メールメッセージは、要求ヘッダに加え
て、２，３行の本文からなる簡単なメッセージ部を含み
得る。あるいは、電子メールは、圧縮画像、オーディオ
セグメント、ビデオ、アニメーション、特別なエンコー
ディングを有するテキスト（例えば、非ラテン語ベース
言語の場合）及び他の全電子メールメッセージをも含み
得るいくつかの添付物を有し得る。

【０００７】メッセージのリクエストは、要求される情
報の深さ及び幅の点から変化し得る。例えば、リクエス
トは、２人の個人の間で数年前に送られた１つのメッセ
ージの全コンテンツに関するものであり得る。あるい
は、リクエストは、直近２４時間内に特定の標題に関し
て送られた任意のメッセージの受取者のリストであっ
て、メッセージを開封した受取者及び未だ開封していな
い受取者を区別するリストであっても良い。要するに、
電子メールメッセージ及び電子メールメッセージデータ
についてのリクエストの性質は、より複雑になり、これ
により、メッセージの格納及び検索を処理する際におけ
る現在のメールサーバの弱点が露呈する。

【０００８】上述したメッセージ格納及び検索の類型の
ために現在用いられているほとんどのメールサーバは、
インターネットメッセージプロトコル、すなわち、ＩＭ
ＡＰに従って構成されている。ＩＭＡＰは、メッセージ
操作のための命令、メッセージに関連する全ての情報の
ソート及び格納のためのインデックス、及びメッセージ
上で実行される動作の集合である。ＩＭＡＰ構成サーバ
では、ＩＭＡＰを十分に活用するために、メッセージコ
ンテンツ及びメッセージに関するメタデータを含むネッ
トワーク及びメッセージ上のユーザに関連する情報が、
ＩＭＡＰのインデックス修飾を活用する方法で格納され
なければならない。ＩＭＡＰサーバが概ねＩＭＡＰイン
デックス修飾に従ってデータを格納するのに対して、こ
のような、高速で確かで非連続なデータの検索及び格納
を最適化する方法でデータを格納するサーバは他にはな
い。

【０００９】現在のＩＭＡＰサーバは、競合問題、及び
低性能によってもたらされる他の非能率性を有してい
る。これらサーバは、レコードを構成するフィールド集
合としてメッセージデータを扱う（すなわち、メッセー
ジデータはレコードベース）が、新規メッセージのユー
ザズインボックス（ユーザが新規メールを受け取るメー
ルボックス）への書き込みは、インボックス上における
ユーザによる他の操作の実行を阻害する結果をもたらし
易い。これらＩＭＡＰサーバのメッセージ格納構造は、
ＩＭＡＰにて利用可能なインデックス修飾を効率よく利
用するようには設計されなかった。例えば、ユーザはメ
ールボックス内の全てのメッセージから所定のフィール
ド（例えば、日付、受取人、標題等）に関する情報のみ
を要求し得る。ＩＭＡＰサーバは、一般的なユーザのデ
ータに関する要求を満たすために必要な情報よりも多く
の情報を検索するように思われる。したがって、特定の
標題について特定のユーザに送られたメッセージ数を単
に取得するために、ＩＭＡＰサーバは、メッセージ数を
引き出すべく全メッセージの全コンテンツを読み出し得
る。現在のＩＭＡＰサーバは、ＩＭＡＰ内で可能な完全
性及び整合性の強力なチェック能力にも欠けている。

【００１０】他のメールサーバのインプリメンテーショ
ンは、メッセージに関する情報の類型に関係なく配信及
びコピーされるメッセージ全体がリクエストされること
を要求する。この問題は、メッセージの配信によってメ
ールフォルダに対する全ての書き込み操作が禁止され
る、ＵＮＩＸオペレーティングシステムにおける古いフ
ァイルベースのメール環境であるＶＡＲＭＡＩＬにおけ
るものと類似している。このデフォルト手続きは、メー
ル配信システムが著しく遅延するという問題をもたらし
た。さらに、ＶＡＲＭＡＩＬ環境は、クライアントマシ
ンのメモリ中に格納される同一電子メールメッセージの
複数のコピーをも要求した。

【００１１】

【発明が解決しようとする課題】したがって、メッセー
ジの格納及び検索時間、及び強力なデータ整合性の維持
を向上するために、インデックス、メッセージデータ、
及びユーザデータが論理的に配列されるように分割され
ている、サーバベースのメッセージ格納構造が必要とさ
れている。メッセージ格納構造は、競合を低減すると共
に、ユーザ及びサーバがメッセージ及びメールフォルダ
上で読み出し及び書き込みを同時に実行することを許容
するべきである。検索速度を高速化すると共にメモリを
セーブすべく、リクエストされたデータ及び減少した無
関係なデータだけをサーバが検索するように、データに
対するユーザのリクエストを処理するときに、サーバに
よって識別可能な特定水準を引き上げることが望まし
い。

【００１２】

【課題を解決するための手段】以上の事項を達成するた
めに、また、本発明に目的に従えば、効率的なメッセー
ジ格納構造、及び配信システムを生成するための方法、
装置、及びコンピュータ読み取り可能媒体が提供され
る。本発明の一つの局面に従えば、全てページベースで
ある、インデックスディレクトリ、インデックスファイ
ル、及びバケットデータを有するメッセージ格納構造が
記載されている。各ページは、１つの実施形態では、例
えば日のような期間に対応している。各データバケット
は、メッセージデータ及びメッセージの実コンテンツを
含む。インデックスファイルは、関連メッセージを特徴
付けるインデックス情報を格納するインデックスファイ
ルセルを含む。インデックスディレクトリは、関連イン
デックスファイルセルのロケーション上に情報を格納す
るインデックスディレクトリセルを含み、これによりイ
ンデックスディレクトリは、メッセージと関連付けられ
る。

【００１３】一つの実施形態では、メッセージ格納構造
はまた、各々がユーザ格納構造内でユーザに関連付けら
れると共に、メッセージを参照するユーザセルを含むペ
ージベースユーザフォルダを有する。他の実施形態で
は、各ユーザセルは、インデックスディレクトリ内のイ
ンデックスディレクトリセルに対する参照を含む。さら
に、他の実施形態では、各ユーザフォルダは、定義済ユ
ーザベース条件に従って類別される。

【００１４】本発明の他の実施形態では、インデックス
ディレクトリセルは、現在、関連メッセージを参照して
いるユーザー数、及び関連インデックスファイルセルに
対する参照指示器（参照ポインタ）を含む。さらに他の
実施形態では、インデックスファイルセルは、データバ
ケット内の関連メッセージに対する参照指示器、及び関
連メッセージのサイズを含む。

【００１５】本発明の更に他の実施形態では、メッセー
ジは関連インデックスファイルセルに対する参照指示
器、及び関連インデックスディレクトリセルに対する参
照指示器を有する。本発明の更に他の実施形態では、ユ
ーザセル内のインデックスディレクトリ指示器（インデ
ックスディレクトリポインタ）、インデックスディレク
トリセル内のインデックスファイル指示器（インデック
スファイルポインタ）、インデックスファイルセル内の
メッセージ指示器（メッセージポインタ）、及びメッセ
ージ内の２つの指示器（ポインタ）は、必要に応じてメ
ッセージ格納構造が自身を復元することを許容する。

【００１６】本発明の他の局面では、新規メッセージを
メッセージ格納構造に対して効率的に配信する方法が提
供される。１つの実施形態では、到着データ及び関連イ
ンデックスデータは、実質的に同時に、メッセージ格納
構造の特定の部分に付加される。到着データ及びインデ
ックスデータがメッセージ格納構造に書き込まれている
間、クライアントは、実質的に阻害されないメッセージ
格納構造内の既存データアクセスできる。更に他の実施
形態では、到着データが付加される場合には、アクセス
は、メッセージ格納構造の不使用部分に制限される。

【００１７】本発明のさらなる効果は以下の詳細な説
明、及び種々の図面を参照することにより、より良く理
解されるであろう。

【００１８】

【発明の実施の形態】好適な発明の実施の形態について
詳細に説明する。好適な発明の実施の形態の例を図面と
共に説明する。本発明を好適な発明の実施の形態に関し
て説明するが、以下の説明は、本発明を１つの好適な発
明の実施の形態に限定することを意図するものではな
い。むしろ、特許請求の範囲によって画定される本発明
の範囲、及び本発明の趣旨を逸脱しない範囲で、変形
物、改良物、及び等価物が含まれることを意図するもの
である。

【００１９】電子メールメッセージ、関連情報、及びユ
ーザ情報といったデータを格納するための改良メッセー
ジ格納構造（格納装置）が、いくつもの図面に図示され
ている。本発明の実施の形態では、改良メッセージ格納
構造は、例えば、インターネットの電子メールメッセー
ジのようなメールメッセージを格納するために構成され
ているが、他の類型の情報を格納するためにも用いられ
得る。本発明の実施の形態に関して、サーバがクライア
ントのメッセージに関するデータに対するクライアント
（すなわち、ユーザ）のリクエストに応答する場合に
は、メールメッセージをサーバ上で記憶し、インデック
ス修飾することが望ましい。本発明の実施形態によれ
ば、メッセージ格納構造は、メールプロトコルにおいて
最も一般的に用いられている命令及びメッセージに対応
するために構成され得る。これらプロトコルのうち２つ
は、インターネットメッセージアクセスプロトコル（Ｉ
ＭＡＰ）及びポストオフィスプロトコル（ＰＯＰ）であ
ることは周知の通りである。本発明の実施形態に従い本
発明を説明し、記述するために、メッセージ格納構造を
含むサーバは、主に、ＩＭＡＰ及びＰＯＰ命令及びメッ
セージ（以下、ＩＭＡＰサーバという）に対応するよう
に構成されている。本発明の実施の形態では、ＩＭＡＰ
サーバは、現在、ある程度のインデックス修飾を有して
いるが、ＩＭＡＰメッセージ格納構造の全体の構成、及
びインデックス修飾の水準は、徐々に複雑化すると共に
止まるところを知らないデータに対するユーザのリクエ
ストを効率よく処理することはできない。

【００２０】したがって、本発明に係るメッセージ格納
構造の潜在的なページベース構成、及び高水準のインデ
ックス修飾は、本発明の実施の形態にサーバが、高効率
な方法で着信メッセージを処理すると共に、（既存デー
タを操作するために）ユーザリクエストを取り扱うこと
を許容する。メッセージ格納構造の潜在的なページベー
ス構成は、データが、例えば、日、または、週といった
期間のような定義済み条件に基づいて類別されることを
許容し、これにより、その大部分が不必要であるデータ
の本体全体を通したサーチ、あるいは、その処理の必要
性が排除される。以下に述べる、インデックスディレク
トリ及びファイルといったメッセージ格納構造及び種々
の記憶構成要素のインデックス修飾の高い細分性もま
た、整合性のチェック及びデータ冗長性の低減を促進す
るする（他の記憶構成要素に対する）参照及びカウンタ
を用いることによって、システムがデータ整合性を確実
にすることを許容する。さらに、レコードが本質的にメ
ッセージ格納構造内の種々の記憶構成要素内におけるフ
ィールドの組み合わせである場合には、後述するよう
に、ユーザリクエスト及び着信メッセージは、レコード
ベース上で取り扱われる。一般的に、ユーザリクエスト
に応えるために、あるいは、着信メッセージを処理する
ためには、所定のフィールドのみが必要とされるので、
サーバは、フォルダ全体、あるいは、ディレクトリ全体
のロックに代えて、セクションのロックを実行し得る。
このことは、サーバへの書き込み（例えば、着信メッセ
ージの処理）及び同一のメールボックスに対するアクセ
スを要求するユーザリクエストの処理の間における競合
を大幅に低減する。

【００２１】本発明に係る発明の実施の形態の１つに従
うメッセージ格納構造は、大規模分散型計算機環境（す
なわち、何万人ものユーザ）、または、例えば、１０人
未満のユーザを有するもっと小さなコンピュータネット
ワークにて用いられるサーバ中にデータを格納するため
に好適である。改良メッセージ格納構造の利点は、これ
ら両状況、及び両状況の間の状況において実現される。
例として、本発明の実施形態におけるサーバは、大規模
分散型計算機環境におけるユーザのためのインターネッ
ト電子メールを格納するＩＭＡＰサーバである。したが
って、ここで用いられるインターネット電子メールメッ
セージの構成を簡単に説明することは有益である。当業
者に周知であるように、インターネット電子メールメッ
セージは、ＭＩＭＥ規格に従ってフォーマットされてい
る。ＭＩＭＥメッセージは、ＭＩＭＥヘッダ、及びその
各々がヘッダを有する１つ以上の本体部、又はセクショ
ンから構成されている。ＭＩＭＥフォーマットは、電子
メールメッセージが、オーディオ、ビデオイメージ、非
英語テキスト、ＨＴＭＬ等といった種々のメディアを含
むことを許容する。本発明の実施形態のメッセージ格納
構造は、後述する種々のインデックスを通じてＭＩＭＥ
セクションを調整する。他の好適な発明の実施形態で
は、他のデータフォーマットを調整するために既述のイ
ンデックス構造が用いられ得る。本発明の実施形態に従
うメッセージ格納構造は、他の非常に特定的なリクエス
トの取り扱いに加えて、メッセージ全体を検索すること
なく特定のメッセージの特定のＭＩＭＥセクションを検
索することを許容する。

【００２２】図１は、本発明に係る発明の実施の形態の
一つに従うメッセージ格納構造を示すブロック図であ
る。メッセージ格納構造１００は、データバケットディ
レクトリ１０２、インデックスディレクトリ１０４、イ
ンデックスファイル１０６、及びユーザフォルダディレ
クトリ１１０を含む。データバケットディレクトリ１０
２は、一連のデータバケット１１２を含んでいる。イン
デックスディレクトリ１０４は、ヘッダ１１４及び一連
のインデックスディレクトリセル１１６を含んでいる。
インデックスファイル１０６は、ヘッダ１１８及び一連
のインデックスファイルセル１２０を含んでいる。ユー
ザフォルダディレクトリ１１０は、一連のユーザフォル
ダ１２２を含んでいる。

【００２３】メッセージ格納構造１００は、２つの記憶
カテゴリ、データ格納構造及びユーザ格納構造、に類別
される。図２は、本発明の実施形態の一つに従うデータ
格納領域の記憶構成要素を図示するブロック図である。
図２に図示されるデータ格納領域１２４は、インデック
スディレクトリ１０４、インデックスファイル１０６、
及びデータバケットディレクトリ１０２を有している。
これら記憶構成要素の各々は、ページベース構成に従っ
て構築されている。各ページは、例えば、特定の時間周
期のような定義済み条件に対応し得る。本発明の実施形
態では、例えば、各記憶構成要素が特定のメッセージが
受信された日に基づくトップレベルで組織されている場
合には、記憶構成要素の各ページは日ベースである。他
の好適な発明の実施の形態では、各ページは、システム
上のデータトラフィック量によって週周期又は８時間周
期に対応し得る。データバケットディレクトリ１０２
は、データバケット１０８により構成される。一般的な
データバケット１０８が、ヘッダ１２６及び代表的なメ
ッセージ領域１２８と共に図示されている。データバケ
ットディレクトリ１０２、すなわち、データバケットホ
ルダは、本質的には一連のデータバケットを予め定めら
れた時間周期、例えば１日、保持するための容器であ
る。したがって、本発明の実施の形態では、所定の日に
受信された全てのメッセージは、通常、その特定日に対
応するデータバケット内に格納される。

【００２４】本発明の実施形態では、データバケットデ
ィレクトリ１０２は、当初、３つのデータバケットを含
むか保持する。バケットは、本質的にデータバケット１
０８に対して構造的に同一である。３つのバケットデー
タのうちいずれか１つが構成可能なディスクファイルサ
イズを超える場合には、１つ以上の追加データバケット
１３０が、データバケットディレクトリ１０２に加えら
れる。他の好適な発明の実施形態では、追加のデータバ
ケットが加えられる方法は変化し得る。例えば、メッセ
ージ格納構造は、当初、１つのデータバケットだけを有
し、初期バケットのいずれか１つが満たされると追加デ
ータバケットを１つ加える。本発明の実施形態に戻る
と、特定日に対する着信メッセージは、３つのデータバ
ケット間の配分をほぼ等しくする意図で、最初の３つの
データバケット間でランダムに分配される。このメッセ
ージの分配は、追加のデータバケットがデータバケット
ディレクトリ１０２に加えられたときに、継続、また
は、維持される。本発明の実施形態では、３つの初期デ
ータバケットが満たされると、３つの追加データバケッ
トが加えられると共に、メッセージは新規のデータバケ
ット間でランダムに分配される。上述のように、本発明
のメッセージ格納構造は、大規模で、量の大きな計算機
環境、あるいは、小規模コンピュータネットワークにお
いて用いられ得る。例として、本発明の実施形態におい
て、大規模分散型計算機環境では、一般的なデータバケ
ットホルダは５００メガバイトの最大ディスクファイル
サイズを有し得る。

【００２５】データバケット１０８は、一般的に、ヘッ
ダセル１２６から始まる。ヘッダ１２６の次は、バケッ
ト１０８内の電子メールメッセージのように、連続的に
データが格納される。他の好適な発明の実施形態では、
データはビデオ、又は、オーディオセグメント、データ
ベースレコード、他のフォーマットのデータであり得
る。本発明の実施形態では、メッセージは、特定のデー
タバケットに加えられる一方で、セル又は固定記憶領域
内には含ませられない。メッセージのサイズは、幅広く
変化し得るが、一般的な、電子メールメッセージは、２
〜１０キロバイトの範囲にある。上述のように、本発明
の実施形態では、着信メッセージは、ランダムに且つ、
好ましくは特定日のための３個の当初データバケット間
に格納される。データバケットが満たされると、メッセ
ージを格納するために新規のデータバケット１３０が生
成される。したがって、特定の受取者に割り当てられた
着信メッセージは、一旦、データバケット内に格納され
る。本発明のメッセージ格納構造の特徴は、メッセージ
の受取者（あるいは、所有者、作成者等）が全員、１つ
のメッセージのコピーに対して参照を有することを許容
する。この特徴は、詳しく後述する。本発明の実施形態
では、一般的なデータバケットは、約２００，０００、
２．５キロバイトのメッセージを保持し得る。したがっ
て、３つのデータバケット（すなわち、特定日に割り当
てられたデータバケットの初期数）は、約６００，００
０通までの電子メールメッセージを保持し得る。当然な
がら、それらメッセージの多くは、メッセージ及び添付
物の類型によっては、２．５キロバイトをゆうに超え得
る。

【００２６】メッセージが受信されると、データバケッ
ト中への格納に加え、インデックス及び関連情報がイン
デックスディレクトリ１０４及びインデックスファイル
１０６内に格納され得るように、メッセージはインデッ
クス修飾スレッドによって分析される。この情報は、デ
ィレクトリ１０４及びファイル１０６の特定のページ内
に格納される。本発明の実施の形態では、インデックス
ディレクトリ及びインデックスファイルは日ベースであ
り、それぞれの日が新規のディレクトリ及びファイルに
割り当てられる。追加インデックスディレクトリページ
１０７は、インデックスディレクトリページ１０４の
「後ろに」図示されている。インデックスディレクトリ
１０４は、ヘッダ１１４から始まりインデックスディレ
クトリセルがそれに続く。サンプルセルが領域１１６に
図示されている。着信メッセージが受信されると、その
メッセージは分析され、インデックス情報が引き出され
ると共にインデックスディレクトリセル１１６内に格納
される。例として、本発明の実施形態では、インデック
スセル１１６は、２４バイトの固定レコードサイズを有
する。他の好適な実施の形態では、インデックスディレ
クトリセル１１６は、格納されるデータの類型及び要求
インデックス修飾レベルに応じて、より短い場合あるい
は長い場合がある。

【００２７】着信メッセージが分析されると、そのメッ
セージに関するインデックス修飾情報がインデックスフ
ァイル１０６内に格納される。インデックスディレクト
リ及びデータバケットディレクトリを備えているので、
本発明の実施形態では、インデックスファイルの１ペー
ジは特定の日に対応する。同様に、２日目及び３日目に
ついてのインデックスファイルページ１１５がインデッ
クスファイル１０６の「後ろに」図示されている。これ
らのページ１１５は、他の定義済み時間間隔、あるい
は、他の条件に対応し得る。インデックスファイル１０
６は、インデックスファイルヘッダ１１８から始まり、
インデックスファイルセル、例えば、セル１２０がそれ
に続く。以下に詳述するように、インデックスファイル
自身は、各着信メッセージに関する詳細インデックス修
飾情報を含むと共に、いくつかの異なるフィールドを含
む。本発明の実施形態では、インデックスファイルヘッ
ダ１１８は固定レコードサイズである。

【００２８】図３は、本発明に係る発明の実施の形態に
従うメッセージ格納構造のユーザ格納領域を示すブロッ
ク図である。上述のように、メッセージ格納構造は、概
念的にデータ格納領域及びユーザ格納領域に分割され得
る。この区別は、図１に図示されているメッセージ格納
構造の機能性のために要求されるものではない。本発明
の実施形態では、区別は、メッセージ格納構造のメッセ
ージデータの局面及びユーザデータの局面を説明するた
めに用いられる。

【００２９】メッセージ格納構造によってサービスされ
るネットワークのサイズ及び特にユーザ数によって、一
般ユーザ格納領域１３２は、ディレクトリ１３４と同様
に数千のユーザフォルダディレクトリを含み得る。ある
いは、わずか２、３のユーザがメッセージ格納構造にア
クセスしている場合には、ユーザ格納領域１３２は、
２、３のユーザフォルダディレクトリ、あるいは１つの
ディレクトリだけを含み得る。ユーザフォルダディレク
トリ１３４は、本質的に、ユーザのグループに対するユ
ーザフォルダ１３６の集合体である。一般的に、ユーザ
は常に、インボックスと呼ばれる新規メールを受信する
ためのユーザメールフォルダを１つ以上有している。電
子メールの場合には、ユーザは、特定の標題、あるい
は、ユーザ選択条件でメッセージを保持するためのカス
タマイズフォルダを生成し得る。ユーザフォルダ１３６
は、ヘッダ１３８から始まり、それにユーザフォルダセ
ル１４０が続く。本発明の実施形態では、一般ユーザフ
ォルダセル１４０は、メッセージに関するインデックス
修飾及び他の情報を含むが、メッセージの実データ、あ
るいは、実コンテンツは含まない。特定メッセージの実
コンテンツは、図２のデータバケットディレクトリ１０
２内に格納される。このことは、特定のユーザフォルダ
に対する参照を有することにより、一度だけメッセージ
格納構造に対して格納、または、書き込みが行われるネ
ットワーク上における幾人かのユーザに割り当てられた
メッセージをメッセージ格納構造が有することを許容す
る。他の好適な発明の実施形態では、データは、ネット
ワーク上の幾人かのユーザによって参照される必要のあ
る、他の類型のデータであり得る。ユーザフォルダディ
レクトリ１３４内に含まれている他のフォルダは、管理
フォルダ及び、例えば、ＩＭＡＰ情報を保持するための
フォルダである。本発明の実施の形態では、各ユーザフ
ォルダディレクトリ１３４には、一般的に、整数の識別
子（識別器）が与えられる。例えば、ユーザの名字がそ
の特定の整数に対してハッシュされ得る。このことは、
各ユーザフォルダディレクトリ１３４におけるユーザネ
ームの実質的に均一な分布を許容する。

【００３０】データバケットディレクトリ１０２、イン
デックスディレクトリ１０４、インデックスファイル１
０６、及びユーザフォルダ（データスペース）ディレク
トリ１３４は、メッセージ格納構造が確実に無矛盾であ
ると共に、エラーの場合には、容易に修復され得るよう
に論理的に結合されている。一連の参照は、特定のフィ
ールド及び、インデックスディレクトリセル１１６、イ
ンデックスファイルセル１２０、ユーザフォルダセル１
３８、及びデータバケット１０８内の特定フィールドの
値を参照して詳細に後述するように、記憶構成要素間に
パスを形成する。メッセージが受信されると、インデッ
クス修飾スレッドは、メッセージの構造及びコンテンツ
を検査する。受信済みメッセージのヘッダのダイジェス
トは、分析され、インデックスファイルセル１２０内に
収容される。同様に、メッセージの本体構造は分析さ
れ、そして、本体情報は、そのメッセージに対応するイ
ンデックスファイルセル内に格納される。本発明の実施
形態では、特定のメッセージが予め定められた長さより
長い場合には、メッセージは、配信中に、全体性能を遅
延させるボトルネックをサーバ上に生成しないように、
接続時に分析される。メッセージの構造を予め分析する
ことにより、本発明に係る１つの発明の実施の形態に従
うメッセージ格納構造を使用するクライアントは、例え
ば、メッセージが格納されているデータバケットから特
定のメッセージに関する全てのヘッダデータを一回の読
み取りによって取得し得る。詳細に後述するように、イ
ンデックスファイルセル１１６は、ユーザが、メッセー
ジ全体にアクセスする必要なく、一読操作によって特定
のメッセージから要求されたプロパティを取得し得るよ
うに、封筒情報、及び本体構造情報といった十分なメタ
データを有する。

【００３１】図４は、本発明に係る発明の実施の形態の
１つに従う、インデックスディレクトリセル１１６内に
おけるフィールドを示すデータ構造図である。インデッ
クスディレクトリセル１１６内の情報は、本質的に、イ
ンデックスファイルセル１２０内に格納されている情報
上のメタデータである。したがって、インデックスファ
イルセル１２０内に収容されているデータにアクセスす
るためのシステムでは、システムは、先ず、インデック
スファイル１０６内の適当なロケーションに対する参照
用のインデックスディレクトリセル１１６にアクセスす
る。インデックスディレクトリセル１１６は、インデッ
クスファイルオフセット２０３、インデックスファイル
セルサイズ２０５、参照カウント２０７、ユニバーサル
格納識別子２０９、及び使用中フラグ２１１についての
値を含む。インデックスディレクトリセル１２０内のイ
ンデックスファイルオフセットフィールド２０２は、そ
のポイントで適当なインデックスファイルセル１２０が
始まるインデックスファイル１０６内のロケーションで
ある、インデックスファイルオフセット値２０３を提供
する。インデックスファイルセルサイズフィールド２０
４は、インデックスファイルオフセットフィールド２０
２内に示されている、オフセット２０３で始まるインデ
ックスファイルセルのセルサイズ２０５を提供する。こ
の情報を備えることにより、システムは、インデックス
ファイル１０６内の適当なインデックスファイルセル１
２０にアクセスし得る。参照カウントフィールド２０６
は、メッセージ、または、（特定のインデックスディレ
クトリセルに関連する）他のデータを参照するユーザフ
ォルダ１３６の数の参照カウント２０７を含む。参照カ
ウント２０７は、特定のメッセージにアクセスしたユー
ザ数である。ユニバーサル格納識別子フィールド２０８
は、各メッセージ、または、データ項目の唯一的な識別
を確実なものとする、ユニバーサル格納識別２０９を格
納する。したがって、本発明の実施形態では、特定のメ
ッセージに対して１つのユニバーサル格納識別子２０９
だけが存在し、その識別子は、システム内の他の任意の
メッセージを識別するためには用いられ得ない。使用中
フラグフィールド２１０は、データが依然としてメッセ
ージ格納構造内に存在するか否かを示す、使用中フラグ
２１１を含む。メッセージ格納構造は、たとえ、特定の
メッセージに対する参照が存在しない、すなわち、その
メッセージについての参照カウント２０７がゼロの場合
であっても、特定のメッセージを含み得る。メッセージ
は、削除され、または、ガベージコレクションが実行さ
れるまで格納構造内に留まる。これは、他のユーザがそ
の特定メッセージにアクセスしたい場合に、メッセージ
を検索する際に有用である。システムは、単純に参照カ
ウント２０７を１に増加させ、メッセージは、特定のユ
ーザによってビューされ得る。

【００３２】図５は、本発明に係る発明の実施形態の１
つに従う、図２に図示されているインデックスディレク
トリヘッダ１１４内のフィールドを示すデータ構造図で
ある。データバケットカウントフィールド２１２は、特
定日に用いられるデータバケット１０８のデータバケッ
トカウントを含むと共に、主に整合性チェックのために
用いられる。複雑フラグフィールド２１４は、システム
がメッセージデータをインデックス修飾しているか否か
を表示するためのフラグを含んでいる。インデックスデ
ィレクトリセルカウントフィールド２１６は、現在、イ
ンデックスディレクトリ１０４中に在るインデックスデ
ィレクトリセル１１６の数を含んでいる。次期利用可能
セルフィールド２１８は、次に利用可能なインデックス
ディレクトリセルのロケーションを含む。本発明の実施
形態では、上記フィールドは、所定の順序でリストされ
ているが、他の好適な発明の実施形態では、フィールド
は、メッセージ格納構造の具体的なインプリメンテーシ
ョンに応じて、異なる順序で順序づけられ得る。さら
に、他の好適な発明の実施形態では、いくつかのフィー
ルドは、必要とされないことがあり得、あるいは、値を
含んでいないことがあり得る。繰り返して述べると、ど
のフィールドが用いられるかは、メッセージ格納構造の
具体的なインプリメンテーションに部分的に依存する。

【００３３】図６は、発明の実施形態の１つに従う、イ
ンデックスファイルセル１２０内のフィールドを詳細に
示すデータ構造図である。インデックスファイルセルサ
イズ３０２は、インデックスファイルセルのサイズを提
供すると共に内部整合性チェックに用いられる、インデ
ックスファイルレコードサイズ３０３を含む。この値を
用いることにより、システムは、一つのレコードから他
のレコードへジャンプすることができると共に、新規の
インデックスファイルセルが、ディスクファイル上の予
測ロケーションにて開始し、終了するかを確認するため
にチェックすることにより整合性を確実にし得る。フィ
ールド３０４は、フィールド３０６のバイト数、また
は、長さを含む点で、識別長フィールド３０４及びデー
タバケット識別フィールド３０６は、関連付けられてい
る。データバケット識別フィールド３０６は、データバ
ケット識別子３０５を含むと共に、本発明の実施形態に
おいては、年のための４桁のアラビア数字、月のための
２桁のアラビア数字、日のための２桁のアラビア数字、
及び３桁の整数から構成される。これらの数字は、特定
のインデックスファイルセルに対応するメッセージを含
む、データバケット１０８に関する唯一識別子を構成す
る。識別長フィールド３０４は、単に、適当な長さであ
ることを保証することにより、データバケット識別子の
整合性を確実にするために用いられる。データバケット
オフセットフィールド３０８は、特定のインデックスフ
ァイルセルに関連付けられているメッセージを含むデー
タバケット内にオフセット３０９を含む。それは、本質
的にメッセージが配置されているデータバケット内のロ
ケーションを提供する。データレコードサイズフィール
ド３１０は、データバケット中にデータ３１１のサイズ
を含むと共に、メッセージのサイズ及び任意のプリアン
ブルデータのサイズを構成する。したがって、フィール
ド３０８及び３１０を備えることにより、システムは、
特定のデータバケット内のロケーションに直接進み、そ
して、一回の読み出しでインデックスファイルセルに関
連するデータレコード（すなわち、メッセージ）全体を
引き出すことができる。

【００３４】ハッシュキーフィールド３１２は、特定の
メッセージが既にメッセージ格納構造内に在るか否かを
システムに通知するために用いられるハッシュテーブル
に関連付けられているハッシュキーを含む。したがっ
て、特定のメッセージがハッシュされ、そして、ハッシ
ュ値はハッシュテーブル内に存在すると決定された場合
には、システムは、メッセージが既にメッセージ格納構
造内に在ることを知り、これにより冗長さが低減され
る。I18nフラグフィールド３１４は、I18nフラグを含
む。これらのフラグは、メッセージが１６ビットの言語
エンコーディング、あるいは、他の特別なエンコーディ
ングを有するか否かを示す。有する場合には、サーチの
ために特別な要件が必要とされる。RFC822ヘッダ長フィ
ールド３１６及びRFC822本体長フィールド３１８は、共
にRFC822ヘッダと呼ばれるインターネットメールヘッダ
に関連する値を含むという点で関連付けられている。RF
C822は、全てのインターネットメールに要求されるイン
ターネットメールのヘッダフォーマットである。RFC822
は、受信者、送信者、標題及び日付といったフィールド
を含んでいる。ヘッダ長フィールド３１６は、RFC822ヘ
ッダ長を含み、フィールド本体長３１８は、RFC822本体
長を含む。RFC822ヘッダ長３１７及びRFC822本体長の合
計は、添付物、ヘッダ及び全ＭＩＭＥ本体部を含むメッ
セージ全体の長さとなる。本発明の実施形態では、フィ
ールド３０２〜３１８は、各メッセージ中に存在し、し
たがって、インデックスファイルセルのデフォルトプリ
アンブルをひとまとめにして定義する。他の好適な発明
の実施形態では、格納されているデータの類型によっ
て、これら全てが必要とされないこともある。例えば、
RFC822ヘッダ長フィールド及びRFC822本体長フィールド
は、インターネットメールメッセージが格納されなかっ
た場合には、必要とされない。本発明に実施形態では、
ＩＭＡＰが他のフィールド及びインデックスの付加を許
容するので、インデックスファイルセル１２０は可変長
である。

【００３５】フィールド３２０〜３２８は、インデック
スファイルセルのインデックスファイル１０６のデータ
部の一部分である。本発明の実施形態では、格納分析水
準は、ＩＭＡＰについては２であり、ＰＯＰについては
０である。封筒フラグフィールド３２０は、封筒フラグ
値３１９を含むと共に、システムがメッセージデータを
分析したか否かを表示する。本発明の実施形態では、メ
ッセージがＩＭＡＰ形式の場合には封筒フラグは１であ
り、メッセージがＰＯＰ形式の場合には封筒フラグは０
である。したがって、封筒フラグ３１９を使用すること
により、システムは、ＰＯＰメッセージの分析を試行す
る時間を浪費することはない。封筒データフィールド３
２２は、サイズ及びメッセージが（ＩＭＡＰメッセージ
であると）分析された場合には他のデータ、といった全
ての封筒情報３２３を含む。本体フラグフィールド３２
４は、本体フラグを含むと共に、値３１９と同一の実効
を有する。同様にして、本体データフィールド３２６
は、本体サイズ及び分析水準がＩＭＡＰの場合には他の
本体構造情報を含む。オフセットリストフィールド３２
８は、データバケット内の特定のメッセージにおいてＭ
ＩＭＥ本体部分（すなわち、セクション）を発見するた
めの迅速な方法をシステムに提供する、セクションオフ
セットリストを含む。セクションオフセットリスト３２
９は、特定の本体部分が一回のディスクデータアクセス
で位置決定されるように、ＭＩＭＥメッセージ中の各Ｍ
ＩＭＥ本体部分のオフセット及び長さを提供する。他の
好適な発明の実施形態では、これらのフィールドには、
メッセージ格納構造が用いられる特定のアプリケーショ
ンのより記述的な他の名前が与えられ得る。さらに、イ
ンデックスファイルセル１２０は、格納されているデー
タの類型によってより多くの、あるいは、より少ないフ
ィールドを有し得る。

【００３６】図７は、図６のセクションオフセットリス
トフィールド３２８を詳細に示すデータ構造図である。
他の好適な発明の実施形態では、セクションオフセット
リスト３２８は、格納済データの類型によって、データ
の他の類型に関するより具体的な情報を含むこともあ
り、あるいは、全く利用されないこともある。本体部分
フィールド４００は、データバケット内に格納されてい
るメッセージの開始位置からのＭＩＭＥ本体部分のオフ
セットを含んでいる。このことは、システムがインデッ
クスファイルセル１２０にアクセスするだけで、メッセ
ージ内のＭＩＭＥセクションを取得することを許容す
る。ヘッダサイズフィールド４０２は、ＭＩＭＥヘッダ
サイズを含んでいる。各ＭＩＭＥ本体部分は、コンテン
ツ、類型、本体エンコーディングといった情報、及び公
開鍵情報といった他の情報を含む、ＭＩＭＥヘッダを有
する。セクション類型フィールド４０４は、テキスト、
イメージ、あるいは、オーディオといったＭＩＭＥセク
ション類型を含む。セクション番号フィールド４０６
は、システムが本体部分番号をインデックスファイルセ
ルから直接取得することを許容する、ＭＩＭＥセクショ
ン番号を含む。本発明の実施形態では、ＭＩＭＥメッセ
ージが、その内の１つが他のＭＩＭＥ本体部分であり得
るいくつかの本体部分を有し得る場合には、このことは
重要である。特定のＭＩＭＥセクション番号が発見され
得ない場合には、システムは、データバケット内のメッ
セージにアクセスする必要なく、そのセクション番号は
存在しない旨をユーザに対して通知する。上記したセク
ションオフセットリストフィールド３２８内の全ての値
３２９は、これまで達成可能であった時間と比較して極
めて少ない時間でより多くの情報量を提供するために用
いられ得る。セクションオフセットリストフィールド３
２８は、同様の利益を得るために他の好適な発明の実施
形態でも用いられ得る。

【００３７】図８は、本発明に係る発明の実施形態の１
つに従う、データバケット１０８内のヘッダセル１２６
及びメッセージ１２８を詳細に示すデータ構造図であ
る。ヘッダフィールド５００は、メッセージ１２８より
上位である特定のデータバケット１０８についてのメッ
セージヘッダを含む。ヘッダフィールドは、データバケ
ット１０８内のレコード数を表示するファイル終了ポイ
ンタを含む。本発明の実施形態ではマジック番号と呼ば
れるポインタは、データバケット１０８の整合性を確実
にする。データレコードサイズフィールド５０２は、プ
リアンブル情報と実メッセージのサイズである、データ
レコードサイズ５０３を含む。したがって、実メッセー
ジデータサイズは、一般的に、データレコードサイズ５
０２内に収容されている総データレコードサイズよりも
小さい。この値は、システムが、あるデータレコードか
ら次のデータレコードへ素早くスキップすること、及び
データレコードの整合性をチェックすることを許容す
る。メッセージオフセットフィールド５０４は、データ
バケット内における、特定のメッセージ内のメッセージ
データ及び実データが始まるロケーションに対するオフ
セット長５０５を含む。本発明の実施形態では、後述す
るように、それは、メッセージデータフィールド５２２
内に含まれるメッセージデータの開始位置に対するポイ
ンタである。インデックスファイルポインタフィールド
５０６は、図６のデータバケット識別子フィールド３０
６内の値３０５と同一のフォーマットを有する、インデ
ックスファイルポインタ５０７を含む。このフォーマッ
トは、値３０５のフォーマットと似ており、４桁の年、
次にそれぞれ２桁の月及び日、続いて３桁の整数を含
む。インデックスファイルポインタフィールド５０６
は、システムがデータのみから格納構造を復元しなけれ
ば場合に、及び整合性チェックのために用いられるイン
デックスファイルポインタ５０７を含む。システムは、
本質的にインデックスディレクトリ、インデックスファ
イル、及びユーザファイル内の情報をバックトラックす
ることにより、メッセージ格納構造を復元することがで
きる。

【００３８】インデックスディレクトリポインタフィー
ルド５０８は、インデックスディレクトリ１０４、より
具体的にはインデックスディレクトリセル１１６に対す
るポインタ５０９を含む。本発明の実施の形態では、整
数形式のポインタは、インデックスディレクトリ内の特
定のセルのロケーションを特定するために用いられる。
インデックスディレクトリセルのサイズは固定値５０９
なので、メッセージ又はデータに対応する特定ディレク
トリセルの開始ロケーションを決定するためにセルのサ
イズが掛け合わされる。この値は、メッセージ格納構造
内における記憶構成要素内のポインタにより形成された
閉ループが壊れていないことを確実にするためにも用い
られる。書き込み時間フィールド５１０は、メッセージ
がメッセージ格納構造に書き込まれた時間を含むと共
に、例えば、メッセージが他のシステムにエクスポート
される場合に、一定時間を維持するために用いられる。
本発明の実施形態では、時間は１９７０年１月１日から
計時され始めている。長さフィールド５１２及び送信者
名フィールド５１４は、フィールド５１２が送信者名の
長さを含むと共に、フィールド５１４が送信者の氏名を
含むメッセージの送信者を参照する。受信者カウントフ
ィールド５１６は、メッセージ受信者５１７の数を格納
し、あるいは、他の好適な発明の実施形態では、特定の
データ片の所有者又は創作者数を含む。受信者リストフ
ィールド５１８は、受信者（すなわち、所有者、創作者
等）の名前のリストを含む。メッセージサイズフィール
ド５２０は、（フィールド５０２内のデータレコードサ
イズ５０３とは異なる）実メッセージのサイズ５２１を
含む。メッセージサイズ５２１は、添付物を含み得る実
データのサイズであると共に、メッセージ中におけるヘ
ッダからデータの最終バイトまでのサイズである。

【００３９】本発明の実施形態では、フィールド５００
〜５２０は、特定メッセージに対するプリアンブルを構
成すると共に、メッセージ格納構造が整合しており、あ
らゆる局面において破壊されていないことを確実にする
ために用いられ得る。メッセージデータフィールド５２
２は、送信者名フィールド５１４内に含まれる送信者デ
ータ構造から送信された実メッセージを含む。

【００４０】図９は、本発明に係る発明の実施形態の一
つに従う、図３のユーザフォルダ内のユーザフォルダセ
ル１３８を詳細に図示するデータ構造図である。各ユー
ザが１個以上のフォルダを有し得る一連のユーザフォル
ダは、ユーザフォルダディレクトリ１３４内に含まれて
いる。本発明の実施形態では、フラグフィールド６００
は、メッセージの個々の状態を示すＩＭＡＰフラグを含
む。本発明の実施形態では、これらは、消去、読み取
り、返答、フラグ及び下書きを含む。他の好適な発明の
実施形態では、このフィールドは、メッセージ格納構造
内に格納されている他の類型のデータの状態を示すフラ
グを含み得る。インデックスディレクトリポインタフィ
ールド６０２は、インデックスディレクトリ１０４に対
するポインタ６０３を含む。本発明の実施形態では、そ
れは、年のための４桁のアラビア数字、続いて、月及び
日のためのそれぞれ２桁のアラビア数字を含む。値６０
３は、インデックスディレクトリ１０４内の適当なセル
１１６に対するポインタとして用いられる。フォルダ識
別子フィールド６０４は、フォルダの生存期間中に１度
しか用いられないユニバーサルフォルダ識別ラベルを含
む。このフォルダ識別ラベルは、メッセージの同期化の
維持を補助する。フォルダが０に縮小すると、次期メッ
セージのための識別ラベルが１又は０といった開始値に
割り当てられ、そして、メッセージが到着する毎にイン
クリメントされる。インデックスフィールド６０６は、
インデックスディレクトリ１０４内の適当なロケーショ
ンに対するインデックス６０７を含むと共に、図８の値
５０９に類似する。本発明の実施形態では、それはイン
デックス１０４内の参照ポインタを示す整数である。こ
の整数は、インデックスディレクトリ１０４内のセル１
１６の適当なロケーションを決定するために、固定イン
デックスディレクトリセルサイズと共に用いられる。

【００４１】ユニバーサル識別子フィールド６０８は、
特定メッセージのためのユニバーサル識別ラベル番号を
含むと共に、必要に応じて、データのバックアップ及び
復元に用いられる。到着時間フィールド６１０は、メッ
セージが受信された時間を含むと共に、メッセージ格納
構造内におけるデータの時間順序付けのために用いられ
得る。本発明の実施形態において、RFC822サイズフィー
ルド６１２は、RFC822メッセージのサイズであると共
に、主に、ＩＭＡＰ及びＰＯＰによって利用される。そ
れはネットワーク上に出現するバイト形式での実サイズ
なので、ＰＯＰはそれを使用する。それは、図３００の
フィールド３１８内の値と同一である。メッセージ格納
構造がインターネットメールメッセージを含まない他の
好適な発明の実施形態では、このフィールド及び既述の
他のフィールドは、異なる名前を有し得ると共に、メッ
セージ格納構造の他のインプリメンテーションに対する
具体的な値を含むことができ、あるいは、全く必要とさ
れないこともある。封筒フラグフィールド６１４は、メ
ッセージのための封筒がメッセージ格納構造内に存在す
るか否かを示す封筒フラグを含む。封筒がインデックス
ディレクトリ１０４内でインデックス修飾済みの場合に
は、システムは、その特定のメッセージ封筒のためのロ
ーカルインデックスを生成する必要はない。封筒がイン
デックス修飾済みでなく、インデックスディレクトリ中
にない場合には、システムはローカルインデックス分析
を実行する。同様に、本体フラグフィールド６１６は、
本体が存在するか否か、本体が既にインデックス修飾さ
れてインデックスディレクトリ内に存在するか否かを示
す。この場合、システムはローカルインデックス分析を
実行する必要がない。キーワードレコードフィールド６
１８は、ユーザが特定のメッセージに割り当てたキーワ
ードを列挙するキーワードレコードを含む。本発明の実
施形態では、キーワードは、メッセージに関連するユー
ザ割当フラグである。オフセットフィールド６２０及び
サイズフィールド６２２は、オフセット６２１及びサイ
ズ６２３をそれぞれ含む。本発明の実施形態では、初回
アクセス時にメッセージがインデックス修飾された（す
なわち、封筒フラグ及び本体フラグが、封筒及び本体が
存在しない旨を示す０である）場合、あるいは、ヘッダ
が６４キロバイトよりも大きな場合に、オフセットフィ
ールド６２０及びサイズフィールド６２２は用いられ
る。メッセージがそのサイズに起因して局所的にインデ
ックス修飾される場合には、レコードがユーザインボッ
クス内のＶＡＲフォルダに生成される。ＶＡＲフォルダ
は、特定のインデックスレコードを含むと共に、メッセ
ージが局所的にインデックス修飾されるときに生成され
る。ＶＡＲフォルダ内においてこのインデックスレコー
ドのロケーションを決定するために、システムは、イン
デックスレコードのためのオフセット６２１（すなわ
ち、フォルダの開始点からレコードの開始点までの距
離）、及びフィールド６２２内に提供されたインデック
スレコードのサイズ６２３を使用する。この選択インデ
ックス修飾機能は、例外的な大きなメッセージをインデ
ックス修飾することに起因するサーバ上の遅れを排除す
る。

【００４２】図１０は、本発明に係る発明の実施の形態
の一つに従う、ユーザフォルダ１３６の詳細を示すデー
タ構造図である。ユーザフォルダの一般的な例は、新規
メッセージを保持するためのインボックスである。ユー
ザは種々の標題、あるいは、トピックスにに関するメー
ルを保持するために他のカスタマイズフォルダを生成し
得る。ユーザヘッダフィールド７００は、特定のフォル
ダについてのユーザヘッダを含む。有効フィールド７０
２は、ＩＭＡＰによって利用されるユニバーサル識別ラ
ベル（ＵＩＤ）有効標識を含む。ＵＩＤが変更される
と、無効となる。これは、例えば、ＵＩＤが番号を付け
替えるときに発生すると共に、ＩＭＡＰを知るために有
用な状態である。このフィールド及び他のフィールドに
関して、他の好適な発明の実施形態では、このフィール
ドは、他のインプリメンテーションの際に有用な他のフ
ラグ又は標識を格納するために用いられ得る。次標識フ
ィールド７０４は、次の着信メッセージ、あるいは、新
規に生成されたフォルダに対して割り当てられるべき次
期ＵＩＤを含む。メッセージカウンタフィールド７０６
は、特定のフォルダに関するメッセージ７０７の数、あ
るいは、データ項目数を含む。最新メッセージフィール
ド７０８は、ユーザが一見した最後のメッセージを格納
する。この値は、新規メールが到着してユーザがそのコ
ンテンツを見るときに変化する。書き込みデータフィー
ルド７１０は、本発明の実施形態においてマジック番号
と呼ばれる最後の書き込み日付を含む。それは、ユーザ
が特定のフォルダ上で書き込み操作を実行した最後の日
時である。マジック番号の一つの使用方法は、キャッシ
ュの再同期化である。マジック番号が、最後にチェック
されてから変更されていない場合には、そのメールボッ
クス内に何の動きもないので、システムは、その特定の
フォルダのためにキャッシュ再同期化を実行する必要は
ない。サイズフィールド７１２は、この特定フォルダか
らメッセージ格納構造内へ格納された実バイトの総数を
含む。それは、ユーザ上にインポーズされたメモリに関
する割り当てに有用なデータの総実バイト数を含む。続
くフィールド７１２は、図９に図示されるようにユーザ
セルを含むユーザセル領域７１４である。

【００４３】図１１は、本発明の実施形態に従う、電子
メールメッセージを受信するための構成要素、及びメッ
セージ格納構造へメッセージを配布するための構成要素
を示すブロック図である。メッセージ８０２は、ＳＭＴ
Ｐ（シンプルメール転送プロトコル）ポートを介してマ
ルチスレッド化され得るメール転送エージェント（ＭＴ
Ａ）８０４によって受け取られる。本発明の実施形態で
は、メッセージ８０２は、クライアントが受け付けたメ
ールによって、ローカルチャネル８０６、又は、メッセ
ージ格納チャネル８０８のいずれか一方に送信される。
メッセージ格納チャネルは、各ファイルが１つのメッセ
ージに対応するファイルのリストである。メッセージが
メッセージ格納チャネルに入るとき、メッセージは連続
的にファイルされる。ローカルチャネルは、同様に構成
されると共に当業者にとって周知である。メッセージ格
納マスタ８１０は、メッセージ格納チャネル８０８から
のメッセージ８０２を読み込む。メッセージ格納マスタ
８１０は、稼働中でない場合には、稼働を開始してから
チャネル８０８内の第１メッセージを読み取る。大規模
マルチスレッドシステムにおいては、メッセージ格納マ
スタ８１０は、一度に１０個までのメッセージを読み取
ることができる。メッセージ格納マスタ８１０は、自身
によるメッセージ格納チャネル８０８からのメッセージ
８０２の読み取りを可能にする、ＡＰＩ（アプリケーシ
ョンプログラミングインターフェース）８１２を介して
メッセージ８０２を読み取る。メッセージ格納マスタ８
１０は、メッセージ８０２をメッセージ格納構造１００
に配信する。上述のように、本発明の実施形態は、電子
メールメッセージを格納するための、本発明に係るメッ
セージ格納構造の使用方法を説明している。メッセージ
格納構造は、以下に説明する図１１及び図１２に図示さ
れているシステム以外の配信システムを有し得る他の類
型のデータを格納するためにも用いられ得る。他の好適
な発明の実施形態では、データは、ユーザ又は、ブラウ
ザ、ワードプロセッサといった他のアプリケーションに
よってメッセージ格納ディレクトリ内に配置され得る。

【００４４】図１２は、本発明に係る発明の実施形態に
従う、メッセージ格納構造にメッセージを配信するため
のメッセージ格納マスタの処理過程を示すフローチャー
トである。図１１を参照して説明したように、メッセー
ジ格納マスタは、新規電子メールメッセージを、ユーザ
用のメッセージ格納構造に配信する。図１２を説明する
ために、メッセージ格納マスタは、稼働である、すなわ
ち、メッセージ格納チャネル内の第１メッセージを既に
読み込み済みであるとする。ステップ９００では、メッ
セージ配信エージェントは、ｎ個までの新規メッセージ
のファイル名を読み取る。本発明の実施形態では、エー
ジェントは１０個までの新規メッセージを読み取ること
ができる。他の好適な発明の実施形態では、エージェン
トは、より多くの、あるいは、より少ないメッセージを
読み取り得る。ステップ９０２では、各ファイル、すな
わち、メッセージが１つの検索スレッドに割り当てられ
る。検索スレッドは、ＡＰＩをコールすることによって
ファイルに割り当てられる。ステップ９０４では、各検
索スレッドは、図１１のメッセージ格納チャネル８０８
内における自身に割り当てられたファイルにアクセスす
る。ステップ９０６では、処理過程は、並行してアクセ
スされるｎ個のメッセージ全てを待つ。一旦、ステップ
９００にて読み取られた全てのファイル名が割り当てら
れると共にアクセスされると、検索スレッドは、追加の
メッセージをチェックするステップ９０８に移行する。
検索スレッドは、一旦、ｎ個の空きバッファを取得し得
ると決定すると、これを実行することができる。メッセ
ージが存在しない場合には、スレッドはステップ９０８
にて新規メッセージのチェックを継続する。新規の着信
メッセージが存在する場合には、検索スレッドは、メッ
セージ配信エージェントが新規メッセージのファイル名
を読み取るステップ９００にリターンする。

【００４５】検索スレッドは新規メッセージをチェック
し、一方、インデックススレッド及び書き込みスレッド
は、検索スレッドによって先に割り当てられると共にア
クセスされたｎ個のメッセージを管理する。メッセージ
格納構造に対してｎ個のメッセージを書き込む際の最初
のステップがステップ９１０に図示されている。ステッ
プ９１０では、書き込みスレッドは、ランダムバケット
番号を発生させることによりデータバケットを選択す
る。本発明の実施形態では、一般的に、メッセージが駐
在可能な３個の空データバケットが存在する。ステップ
９１２では、処理過程は、選択済データバケット１０８
がいくらかでも残存メモリを有しているか否かを決定す
る。有していない場合には、他のランダムデータバケッ
ト番号を発生させるために、処理過程はステップ９１０
にリターンし、メッセージがメッセージ格納構造に書き
込まれ得るまで、必要に応じて追加のデータバケットを
生成しながらこの処理過程を継続する。データバケット
が一杯でない場合には、ステップ９１４において、書き
込みスレッドはｎ個のメッセージを選択済データバケッ
トの末端に付加する。ステップ９１６では、書き込みス
レッドは、データバケット番号のインデックススレッ
ド、バケットオフセット３０９、及びステップ９１４に
て付加された各メッセージのメッセージサイズ５２１を
通知する。ステップ９１８では、書き込みスレッドは、
検索スレッドによって割り当て済みであると共にアクセ
ス済みであり、メッセージ格納構造に書き込まれる必要
のあるメッセージがまだ存在するか否かをチェックす
る。存在する場合には、書き込みスレッドはステップ９
１０にリターンする。新規メッセージが存在しない場合
には、書き込みスレッドはステップ９１８にてチェック
を継続する。

【００４６】インデックススレッドは、書き込みインデ
ックスがメッセージ格納構造に対する書き込みを一旦終
えたインデックスディレクトリ及びファイル内へインデ
ックス情報の格納を開始する。ステップ９２０では、ス
テップ９１６にて説明したように、格納構造に対するｎ
個のメッセージの書き込みを終了し、インデックス修飾
情報をリターンするために、インデックススレッドは書
き込みスレッドを待つ。自身の先回のインデックス修飾
タスクを終了すると共にメッセージ格納構造に対する書
き込みを終えるために、インデックススレッドは書き込
みスレッドを待たなくてはならない場合がある。ステッ
プ９２２では、インデックススレッドは、インデックス
情報をインデックスディレクトリ及びインデックスファ
イルに書き込む。ステップ９２４では、インデックスデ
ィレクトリ及びインデックスファイル内でデータを検索
するために必要な参照情報は、ユーザフォルダセルに書
き込まれる。ステップ９２４では、対応インデックスス
ペースを参照するために十分な情報は、受信者数によっ
て、１つのインボックスフォルダセル、または、複数の
インブックスフォルダセルに書き込まれる。ステップ９
２６では、新規メッセージの追加を表示するために、ユ
ーザフォルダヘッダ内の情報が更新される。ステップ９
２６が終了した後、インデックススレッドは、ステップ
９２８にて、インデックス修飾されることを待っている
インデックス情報が存在するか否かをチェックする。存
在する場合には、メッセージ格納構造に既に書き込み済
みのメッセージに関する情報のインデックス修飾を開始
するために、インデックススレッドは、ステップ９２０
にリターンする。

【００４７】本発明は、コンピュータシステム中に格納
されているデータに影響を与える種々のコンピュータ実
行動作を利用する。これらの動作は、これに限られるも
のではないが、物理量の物理的操作を必要とする動作を
含む。一般的に、必ずしも必要ではないが、これらの量
は、格納、転送、結合、比較、及びその他の操作が可能
な電気的又は磁気的信号の形を採る。ここに記載される
本発明の一部を形成する動作は、有用な機械動作であ
る。実行される動作はしばしば、例えば、製造、識別、
実行、決定、比較、演算、ダウンロード、あるいは、検
出といった用語で表現される。一般的に用いられている
ことを主な理由として、これら電気的又は磁気的信号
を、ビット、値、要素、変数、文字、データ等と呼ぶこ
とが時に便利である。しかしながら、これら用語及び類
似の用語の全ては適当な物理量と関連付けられ、また、
これら量に対して適用された都合の良いラベルにすぎな
いことに留意すべきである。

【００４８】本発明はまた、前記動作を実行するための
デバイス、システム、又は装置に関連する。システム
は、特定の用途のために特別に構成され得る他、コンピ
ュータ中に格納されているコンピュータプログラムによ
って選択に起動され、または構成される汎用コンピュー
タたり得る。上記プロセスは、いかなる特定のコンピュ
ータ、または演算装置に対しても本質的に関連付けられ
るものではない。特に、種々の汎用コンピュータが、本
明細書中の開示に従い記述されたプログラムと共に用い
られ得る、あるいは、要求動作を実行するために更に特
定化されたコンピュータシステムを構成することがより
都合の良い場合もある。

【００４９】図１３は、本発明の１つの発明の実施の形
態に従う処理を実行するために好適な汎用コンピュータ
システム１０００のブロック図である。図１３は汎用コ
ンピュータシステムの一例を図示する。他のコンピュー
タシステムアーキテクチャ及び構成も本発明の処理を実
行するために用いられ得る。後述する種々のサブシステ
ムから成るコンピュータシステム１０００は、１つ以上
の（中央処理装置、すなわちＣＰＵとも呼ばれる）マイ
クロプロセッササブシステム１００２を備えている。す
なわち、ＣＰＵ１００２はシングルチッププロセッサ若
しくはマルチプルプロセッサによって実現され得る。Ｃ
ＰＵ１００２はコンピュータシステム１０００の動作を
制御する汎用ディジタルプロセッサである。メモリから
受けた命令を用いて、ＣＰＵ１００２は、入力データの
受け取り並びに操作、及び出力並びに出力デバイス上に
おけるデータの表示を制御する。

【００５０】ＣＰＵ１００２は、メモリバス１００８を
介して、一般的にランダムアクセスメモリ（ＲＡＭ）で
ある第１主記憶装置１００４と双方向接続され、一般的
にリードオンリメモリ（ＲＯＭ）である第２主記憶装置
１００６と単方向接続されている。当業者に知られてい
るように、主記憶装置１００４は汎用記憶領域及びスク
ラッチパッドメモリとして用いられ得ると共に、入力デ
ータ及び処理データを格納するためにも用いられ得る。
主記憶装置はまた、ＣＰＵ１００２上の動作を処理する
ための他のデータ及び命令の他に、メッセージ格納構造
形式のプログラム命令及びデータを記憶し得ると共に、
一般的に、メモリバス１００８上で双方向にデータ及び
命令を高速に伝送するために用いられる。当業者に周知
であるように、主記憶装置１００６は、一般的に、自身
の機能を実行するためにＣＰＵ１００２によって用いら
れる基本動作命令、プログラムコード、データ、及びオ
ブジェクトを有する。主記憶装置１００４、１００６
は、例えば、データアクセスが双方向あるいは単方向接
続のどちらを必要とするかに基づいて、後述する任意の
好適なコンピュータ読み取り可能記憶媒体を含み得る。
ＣＰＵ１００２はまた、直接且つ高速に繁用データをキ
ャッシュメモリ（図示しない）内に格納し得ると共にキ
ャッシュメモリ１０１０内から検索し得る。

【００５１】リムーバブル大容量記憶装置１０１２は、
コンピュータシステム１０００に対して追加データ記憶
容量を提供し、ＣＰＵ１０２に対して双方向あるいは単
方向接続されている。例えば、具体的なリムーバブル大
容量記憶装置としては、一般的に、ＣＤ−ＲＯＭは一般
的にＣＰＵ１００２に対して単方向にデータを伝送する
のに対して、フロッピーディスクはＣＰＵ１００２に対
して双方向にデータを伝送可能であるとして知られてい
る。大容量記憶装置１０１２はまた、磁気テープ、フラ
ッシュメモリ、搬送波に具現化された信号、ＰＣカー
ド、携帯大容量記憶装置、ホログラフィック記憶装置、
及び他の記憶装置といったコンピュータ読み取り可能媒
体を含み得る。固定式大容量記憶装置１０１６もまた追
加のデータ記憶容量を提供し得るものであり、ペリフェ
ラルバス１０１４を介してＣＰＵ１００２に対して双方
向伝送可能に結合されている。大容量記憶装置１０１６
の最も一般的な例は、ハードディスクドライブである。
一般的に、これら媒体に対するアクセスは主記憶装置１
００４、１００６に対するアクセスよりも遅い。大容量
記憶装置１０１２、１０１６は、一般的に、ＣＰＵ１０
０２によって使用されていない追加プログラム命令、デ
ータ等を記憶する。大容量記憶装置１０１２、１０１６
内に格納される情報は、必要に応じて、一般的な方法で
仮想メモリとして主記憶装置１００４（例えば、ＲＡ
Ｍ）の一部として組み込まれ得ることは理解されるべき
である。

【００５２】記憶サブシステムに対するアクセスをＣＰ
Ｕ１００２に提供する他に、ペリフェラルバス１０１４
は、他のサブシステム及びデバイスに対するアクセスを
提供するためにも用いられ得る。本発明の実施の形態で
は、他のサブシステム並びにデバイスには、表示モニタ
１０１８、ディスプレイアダプタ１０２０、プリンタ装
置１０２２、ネットワークインターフェース１０２４、
補助入力／出力デバイスインターフェース１０２６、サ
ウンドカード１０２８及びスピーカ１３０、及び必要に
応じて他のサブシステム

【００５３】ネットワークインターフェース１０２４に
より、ＣＰＵ１００２は、図示するネットワーク接続を
用いて、他のコンピュータ、コンピュータネット、ある
いは、電気通信ネットワークと接続することができる。
ネットワークインターフェース１０２４を通じて、ＣＰ
Ｕ１００２は、上述の方法ステップの実行に従って、例
えば、データオブジェクト又はプログラム命令といった
情報を他のネットワークから受け取り、あるいは、他の
ネットワークに対して情報を出力し得ることが予期され
る。しばしばＣＰＵ上で実行される命令のシーケンスと
して表される情報は、例えば、搬送波に具現化されたコ
ンピュータデータ信号の形式で他のネットワークから受
け取られ得ると共に他のネットワークに対して出力され
得る。インターフェースカード又は類似のデバイス、及
びＣＰＵ１００２によって実行される適当なソフトウェ
アは、標準プロトコルに従ってコンピュータシステム１
０００を外部ネットワークに対して接続するために用い
られ得ると共に、データを伝送するために用いられ得
る。すなわち、本発明に係る方法の発明の実施の形態
は、ＣＰＵ１００２単独で実行され得ると共に、例え
ば、インターネット、イントラネット、若しくはローカ
ルエリアネットワークといったネットワークを横断し
て、処理の一部を共有する遠隔ＣＰＵと共に実行され得
る。追加大容量記憶装置（図示しない）もまた、ネット
ワークインターフェース１０２４を介してＣＰＵ１００
２と接続され得る。

【００５４】補助Ｉ／Ｏデバイスインターフェース１０
２６は、コンピュータシステム１０００が、マイクロフ
ォン、接触感応ディスプレイ、トランスジューサカード
リーダ、テープリーダ、音声又は手書き認識装置、生物
測定リーダ、カメラ、携帯式大容量記憶装置、及び他の
コンピュータといった他のデバイスとの間でデータを送
受信することを許容する、汎用及び専用インターフェー
スを表し得る。

【００５５】ＣＰＵ１００２には、キーボード１０３
６、あるいは、ポインタデバイス１０３８からの入力を
受信すると共にキーボード１０３６、あるいは、ポイン
タデバイス１０３８からＣＰＵ１００２へデコード済シ
ンボルを送信するためのキーボードコントローラ１０３
２がローカルバス１０３４を介して結合されている。ポ
インタデバイスは、マウス、スタイラス、トラックボー
ル、または、タブレットを含み得ると共に、グラフィカ
ルユーザフェースとの対話に有用である。

【００５６】さらに、本発明の実施の形態は、種々のコ
ンピュータ実行動作を実行するためのプログラムコード
を含むコンピュータ読み取り可能媒体を備えるコンピュ
ータ記憶製品に関する。コンピュータ読み取り可能媒体
は、後にコンピュータによって読み取られ得るデータを
格納する任意のデータ記憶装置である。媒体及びプログ
ラムコードは、本発明の目的のために特別に設計され且
つ構成されたもの、あるいは、コンピュータソフト業界
における当業者にとって周知の種類のものであり得る。
コンピュータ読み取り可能媒体には、これらに限られる
ものではないが、例えば、上述の全ての媒体、すなわ
ち、ハードディスク、フロッピーディスク、及び磁気テ
ープといった磁気媒体、ＣＤ−ＲＯＭディスクのような
光媒体、フロプティカルディスクのような磁気−光媒
体、特定用途向け集積回路（ＡＳＩＣ）プログラマブル
論理回路（ＰＬＤ）及びＲＯＭ及びＲＡＭデバイスが含
まれる。コンピュータ読み取り可能媒体はまた、コンピ
ュータ読み取り可能コードが分散方式にて格納及び実行
されるように、搬送波に具現化されたデータ信号として
コンピュータシステムに接続されているネットワークを
通じて分散され得る。プログラムコードの例には、例え
ばコンパイラにより生成されたマシンコード、あるい
は、インタプリタを使用して実行され得る高レベルコー
ドを含むファイルの双方が含まれる。

【００５７】当業者によって理解されるように、上記ハ
ードウェア及びソフトウェア要素は、標準的な設計及び
構成である。本発明に用いることが適当な他のコンピュ
ータシステムは、付加的な、あるいは、より少ないサブ
システムを含み得る。さらに、メモリバス１００８、ペ
リフェラルバス１０１４、及びローカルバス１０３４
は、サブシステムにリンクするために機能する任意の相
互結合方式の例示である。例えば、ローカルバスは、Ｃ
ＰＵを固定大容量記憶装置１０１６及びディスプレイア
ダプタ１０２０に接続するために用いられ得る。図１３
に図示されるコンピュータシステムは、本発明に用いる
ことが好ましいコンピュータシステムの例示にすぎな
い。異なるサブシステム構成を有する他のコンピュータ
アーキテクチャもまた用いられ得る。

【００５８】以上、本発明に対する理解を明瞭にするた
めに詳細に本発明を説明したが、特許請求の範囲から逸
脱することなく、一定の変更及び改良が実行され得るこ
とは明白である。さらに、本発明の方法及び装置の双方
を実現する代わりの方法が存在することに留意すべきで
ある。例えば、メッセージ格納構造は、ＩＭＡＰインデ
ックスを用いて説明されているが、メッセージ格納構造
は、マルチメディアデータ、又は他の類型のデータを格
納するために他のメールプロトコルに対して同様に構成
され得る。また例えば、種々のセルのフィールドが特定
の順序で記載されているが、フィールドの順序はメッセ
ージ格納構造の特徴として要求されない。フィールド
は、異なる順序で順序付けられ得ると共に、本発明の性
能及び利点に影響を与えることなく省略あるいは付加さ
れ得る。したがって、記載されている例示は説明と考え
られるべきであり、制限と考えられるべきでない。ま
た、本発明は、本明細書の詳細な記載に限定されるもの
でなく、特許請求の範囲に記載、並びに、その均等の範
囲によって定義されるべきである。

【図面の簡単な説明】

【図１】本発明に係る発明の実施の形態の一つに従う、
メッセージ格納構造のブロック図。

【図２】本発明に係る発明の実施の形態の一つに従う、
メッセージ格納構造のデータ格納領域を示すブロック
図。

【図３】本発明に係る発明の実施の形態の一つに従う、
メッセージ格納構造のユーザ格納領域を示すブロック
図。

【図４】図２に図示されるインデックスディレクトリセ
ル内のフィールドを示すデータ構造図。

【図５】図２に図示されるインデックスディレクトリヘ
ッダ内のフィールドを示すデータ構造図。

【図６】インデックスファイルセル内のフィールドを詳
細に示すデータ構造図。

【図７】本発明のセクションオフセットリストを詳細に
示すデータ構造図。

【図８】図２に図示されるデータバケットディレクトリ
内のヘッダ及びメッセージを詳細に示すデータ構造図。

【図９】図３のユーザフォルダ内のメッセージセルを詳
細に示すデータ構造図。

【図１０】図３のユーザフォルダを詳細に示すデータ構
造図。

【図１１】本発明に係るメッセージ格納構造に対してメ
ッセージを配信、及び電子メールメッセージの受取に必
要な構成要素を示すデータ構造図。

【図１２】本発明に係るメッセージ格納構造に対してメ
ッセージを配信する処理過程を示すフローチャート。

【図１３】本発明に係る既述の発明の実施形態を実現す
るために好適な一般的なコンピュータシステムのブロッ
ク図。

フロントページの続き (71)出願人 591064003 901 ＳＡＮＡＮＴＯＮＩＯＲＯＡＤＰＡＬＯＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者ウイリアム・ジェイ．・イーガーアメリカ合衆国カリフォルニア州94025 メンロ・パーク，バークレー・アベニュー，620

Claims

【特許請求の範囲】

【請求項１】各々が複数のメッセージを含むために好
適である複数のページベースデータバケットと、各々が複数のインデックスファイルセルを含むために好
適である１つ以上のインデックスファイルページを含む
ページベースインデックスファイルと、各インデックス
ファイルセルは前記メッセージの内の関連する１つのメ
ッセージを特徴付けるインデックス情報を格納するため
に構成されていることと、各々が複数のインデックスディレクトリセルを含むため
に好適である１つ以上のインデックスディレクトリペー
ジを含むページベースインデックスディレクトリと、各
インデックスディレクトリセルは、関連インデックスフ
ァイルセルのロケーションを検知するために好適なディ
レクトリ情報を格納するために構成されていると共に、
これにより前記インデックスファイルに関連付けられて
いる前記特定のメッセージに関連付けられることを備え
る、メッセージ格納構造。
【請求項２】請求項１に記載のメッセージ格納構造は
さらに、各々がユーザに関連付けられていると共に複数
のユーザセルを含むために好適である複数のページベー
スユーザフォルダを備え、前記各ユーザセルは前記ユー
ザに関連するメッセージを参照する、メッセージ格納構
造。
【請求項３】請求項２に記載のメッセージ格納構造に
おいて、各ユーザセルは、このユーザセルをインデック
スディレクトリセル自身の参照済メッセージに関連付け
るインデックスディレクトリセルに対する第１インデッ
クスディレクトリ参照指示器を含む、メッセージ格納構
造。
【請求項４】請求項２又は請求項３に記載のメッセー
ジ格納構造において、各ユーザセルはさらに、どのユー
ザフォルダが前記ユーザセルを含んでいるかを示すユー
ザフォルダ識別器を有する、メッセージ格納構造。
【請求項５】請求項２又は請求項３に記載のメッセー
ジ格納構造において、各ユーザセルはさらに、参照済メ
ッセージが前記格納構造内に到着した時間を表示する到
着時間を有する、メッセージ格納構造。
【請求項６】請求項２に記載のメッセージ格納構造に
おいて、各ユーザフォルダは、前記メッセージのサイズ
を示す総サイズ値を含む、メッセージ格納構造。
【請求項７】請求項２又は請求項６に記載のメッセー
ジ格納構造において、各ユーザフォルダはさらに、新規
ユーザセルを識別するための次期ユニーク識別器を有す
る、メッセージ格納構造。
【請求項８】請求項２、請求項６又は請求項７のいず
れかの請求項に記載のメッセージ格納構造において、各
ユーザフォルダはさらに、前記ユーザフォルダによって
参照された前記最近のメッセージが前記メッセージ格納
構造に書き込まれた日を示す最終書き込み日を有する、
メッセージ格納構造。
【請求項９】請求項２又は請求項６に記載のメッセー
ジ格納構造において、各ユーザフォルダはさらに、前記
ユーザフォルダ内において参照されたメッセージ数を示
すメッセージカウントを有する、メッセージ格納構造。
【請求項１０】請求項１に記載のメッセージ格納構造
において、各データバケットページ、各インデックスフ
ァイルページ及び各インデックスディレクトリページ
は、予め定められた長さの時間と関連付けられる、メッ
セージ格納構造。
【請求項１１】請求項１に記載のメッセージ格納構造
において、各インデックスディレクトリセルは、現在、
前記関連メッセージを参照しているユーザ数を示す参照
カウンタを有する、メッセージ格納構造。
【請求項１２】請求項１に記載のメッセージ格納構造
において、各インデックスディレクトリセルは、関連イ
ンデックスファイルセルに対する第１インデックスファ
イル参照指示器を有する、メッセージ格納構造。
【請求項１３】請求項１２に記載のメッセージ格納構
造において、前記第１インデックスファイル参照指示器
は、インデックスファイル内における前記インデックス
ファイルセルのロケーションを示すインデックスファイ
ルオフセット、及び前記インデックスファイルセルの前
記サイズを示す関連インデックスファイルセルサイズを
有する、メッセージ格納構造。
【請求項１４】請求項１に記載のメッセージ格納構造
はさらに、特定のインデックスディレクトリページ内に
おけるインデックスディレクトリセル数を示すセル数カ
ウンタを含むインデックスディレクトリヘッダを備え
る、メッセージ格納構造。
【請求項１５】請求項１４に記載のメッセージ格納構
造において、前記インデックスディレクトリヘッダはさ
らに、前記インデックスディレクトリにおける新規イン
デックスディレクトリセルのロケーションを示す次期ロ
ケーションを含む、メッセージ格納構造。
【請求項１６】請求項１５に記載のメッセージ格納構
造において、前記インデックスディレクトリヘッダはさ
らに、インデックスディレクトリページによって用いら
れるデータバケット数を示すデータバケットカウンタを
含む、メッセージ格納構造。
【請求項１７】請求項１に記載のメッセージ格納構造
において、各インデックスファイルセルは、前記インデ
ックスファイルセルのサイズを示すインデックスファイ
ルセルサイズを含み、これにより、内部整合性試験が促
進される、メッセージ格納構造。
【請求項１８】請求項１または請求項１７のいずれか
の請求項に記載のメッセージ格納構造において、各イン
デックスファイルセルは、前記関連データバケット内に
おける前記関連メッセージに対するメッセージ指示器を
含む、メッセージ格納構造。
【請求項１９】請求項１８に記載のメッセージ格納構
造において、前記メッセージ指示器は、前記関連メッセ
ージを含むデータバケットを識別するデータバケット識
別器、及び前記識別済データバケット内における前記関
連メッセージのロケーションを示すデータバケットオフ
セットを有する、メッセージ格納構造。
【請求項２０】請求項１に記載のメッセージ格納構造
において、各インデックスファイルセルは、関連メッセ
ージサイズを含む、メッセージ格納構造。
【請求項２１】請求項１、請求項１７、請求項１８ま
たは請求項２０の内いずれか一つの請求項に記載のメッ
セージ格納構造において、各インデックスファイルセル
は、関連データバケット内におけるメッセージセクショ
ンのロケーションを示す関連メッセージセクションオフ
セットリストを含む、メッセージ格納構造。
【請求項２２】請求項１に記載のメッセージ格納構造
において、メッセージはプリアンブルデータ及びユーザ
によって伝達された実データを含むメッセージデータを
含む、メッセージ格納構造。
【請求項２３】請求項２２に記載のメッセージ格納構
造において、前記プリアンブルデータは前記メッセージのサイズを示
すメッセージサイズを含み、前記プリアンブルデータは関連インデックスファイルセ
ルに対する第２インデックスファイル参照指示器を有す
る、メッセージ格納構造。
【請求項２４】請求項２２または請求項２３に記載の
メッセージ格納構造において、前記プリアンブルデータ
は、関連インデックスディレクトリセルに対する第２イ
ンデックスディレクトリ参照指示器を含む、メッセージ
格納構造。
【請求項２５】請求項２４に記載のメッセージ格納構
造はさらに、ユーザセル内に第１インデックスディレクトリ参照指示
器を、インデックスディレクトリセル内に第１インデックスフ
ァイル参照指示器を、前記メッセージ内に第２インデックスファイル参照指示
器を、前記インデックスファイルセル内にメッセージ指示器を
備え、これら指示器は、要求された場合に、前記プリアンブル
データ内における前記第２インデックスディレクトリ参
照指示器と協働して、前記メッセージ格納構造が、前記
メッセージ格納構造のページの内部整合性試験、及び復
元を実行することを可能にする、メッセージ格納構造。
【請求項２６】請求項２４に記載のメッセージ格納構
造はさらに、インデックスディレクトリセル内に第１インデックスフ
ァイル参照指示器を、前記インデックスファイルセル内にメッセージ指示器
を、前記メッセージ内に第２インデックスファイル参照指示
器を備え、これら指示器は、前記プリアンブルデータ内の前記第２
インデックスディレクトリ参照指示器と協働して、前記
データバケット、インデックスファイル、及びインデッ
クスディレクトリ内に自立参照機構を形成する、メッセ
ージ格納構造。
【請求項２７】請求項２２乃至請求項２４の内いずれ
か一つの請求項に記載のメッセージ格納構造において、
前記プリアンブルデータは、メッセージ送信者名、及び
前記メッセージを参照するユーザ数を示す受信者カウン
トを含む、メッセージ格納構造。
【請求項２８】着信メッセージをメッセージ格納構造
内に格納するための方法であって、前記着信メッセージを前記メッセージ格納構造のデータ
バケット部に付加し、インデックスデータを生成すべく、前記着信メッセージ
をインデックス修飾し、少なくともいくつかのインデッ
クス修飾は、前記着信メッセージが前記データバケット
に付加される間に完了され、前記インデックスデータを前記メッセージ格納構造のイ
ンデックス部に付加する、方法。
【請求項２９】請求項２８に記載の方法において、前
記着信メッセージは、前記メッセージ格納構造内に既存
するインデックスメッセージに対するアクセスを実質的
に妨げることなく、前記メッセージ格納構造の前記デー
タバケット部に付加される、方法。
【請求項３０】請求項２８または請求項２９に記載の
方法において、前記着信メッセージのインデックス修飾
は、前記インデックスデータ中に含まれるべき前記メッ
セージ格納構造の前記データバケット部上のデータを取
得することを含む、方法。
【請求項３１】請求項２８乃至請求項３０の内いずれ
か一つの請求項に記載の方法はさらに、前記着信メッセ
ージが前記メッセージ格納構造の前記データバケット部
に付加される間は、アクセスを前記メッセージ格納構造
の前記データバケット部の不使用セクションに対するア
クセスに制限する、方法。
【請求項３２】着信メッセージをメッセージ格納構造
内に格納するための方法であって、前記メッセージ格納構造内に既存するメッセージに対す
るアクセスを実質的に妨げることなく、前記着信メッセ
ージを前記メッセージ格納構造のデータバケット部に付
加し、インデックスデータを生成すべく、前記着信メッセージ
をインデックス修飾し、前記インデックスデータを前記メッセージ格納構造のイ
ンデックス部に付加する、方法。
【請求項３３】請求項３２に記載の方法において、少
なくともいくつかのインデックス修飾は、前記着信メッ
セージが前記メッセージ格納構造の前記データバケット
に付加される間に完了される、方法。
【請求項３４】請求項３２または請求項３３に記載の
方法はさらに、前記着信メッセージが前記メッセージ格
納構造の前記データバケット部に付加される間は、アク
セスを前記メッセージ格納構造の前記データバケット部
の不使用セクションに対するアクセスに制限する、方
法。
【請求項３５】請求項３２乃至請求項３４の内いずれ
か一つの請求項に記載の方法において、前記着信メッセ
ージのインデックス修飾はさらに、前記インデックスデ
ータ中に含まれるべき前記メッセージ格納構造の前記デ
ータバケット部上のデータを取得することを含む、方
法。
【請求項３６】メッセージ格納構造が埋め込まれてい
るコンピュータ読み取り可能媒体であって、前記メッセ
ージ格納構造は、各々が複数のメッセージを含むために好適である複数の
ページベースデータバケットと、その各ページが複数のインデックスファイルセルを含む
ために好適であるページベースインデックスファイル
と、各インデックスファイルセルは前記メッセージの内
の関連する１つのメッセージを特徴付けるインデックス
情報を格納するために構成されていることと、その各ページが複数のインデックスディレクトリセルを
含むために好適であるページベースインデックスディレ
クトリと、各インデックスディレクトリセルは、関連イ
ンデックスファイルセルのロケーションを検知するため
に好適なディレクトリ情報を格納するために構成されて
いると共に、これにより前記インデックスファイルに関
連付けられている前記特定のメッセージに関連付けられ
ることとを備える、コンピュータ読み取り可能媒体。
【請求項３７】請求項３６に記載のコンピュータ読み
取り可能媒体はさらに、各々がユーザに関連付けられて
いると共に複数のユーザセルを含むために好適である複
数のページベースユーザフォルダを備え、各ユーザセル
は前記ユーザに関連するメッセージ格納構造内における
メッセージを参照する、コンピュータ読み取り可能媒
体。
【請求項３８】請求項３７に記載のコンピュータ読み
取り可能媒体において、各ユーザセルは、インデックス
ディレクトリセルに対する第１インデックスディレクト
リ参照ポインタを有し、これによりこれらユーザセルを
インデックスディレクトリセル自身の参照済メッセージ
に関連付ける、コンピュータ読み取り可能媒体。
【請求項３９】請求項３７又は請求項３８に記載のコ
ンピュータ読み取り可能媒体において、各ユーザセルは
さらに、どのユーザフォルダが前記ユーザセルを含んで
いるかを示すユーザフォルダ識別子を有する、コンピュ
ータ読み取り可能媒体。
【請求項４０】着信メッセージをメッセージ格納構造
内に格納するためのプログラムコードを格納するコンピ
ュータ読み取り可能媒体であって、前記着信メッセージを前記メッセージ格納構造のデータ
バケット部に付加するステップと、インデックスデータを生成すべく、前記着信メッセージ
をインデックス修飾するステップであって、少なくとも
いくつかのインデックス修飾は、前記着信メッセージが
前記データバケットに付加される間に完了される、イン
デックス修飾ステップと、前記インデックスデータを前記メッセージ格納構造のイ
ンデックス部に付加するステップとを、コンピュータに
実行させるために構成されているコンピュータプログラ
ムデバイスを備える、コンピュータ読み取り可能媒体。
【請求項４１】請求項４０に記載のコンピュータ読み
取り可能媒体はさらに、前記着信メッセージが前記メッ
セージ格納構造の前記データバケット部に付加される間
は、アクセスを前記メッセージ格納構造の前記データバ
ケット部の不使用セクションに対するアクセスに制限す
るステップを、コンピュータに実行させるために構成さ
れているコンピュータプログラムデバイスを備える、コ
ンピュータ読み取り可能媒体。
【請求項４２】着信メッセージをメッセージ格納構造
内に格納するためのプログラムコードを格納するコンピ
ュータ読み取り可能媒体であって、前記メッセージ格納構造内に既存するメッセージに対す
るアクセスを実質的に妨げることなく、前記着信メッセ
ージを前記メッセージ格納構造のデータバケット部に付
加するステップと、インデックスデータを生成すべく、前記着信メッセージ
をインデックス修飾するステップと、前記インデックスデータを前記メッセージ格納構造のイ
ンデックス部に付加するステップとを、コンピュータに
実行させるために構成されているコンピュータプログラ
ムデバイスを備える、コンピュータ読み取り可能媒体。
【請求項４３】搬送波に具現化されていると共に命令
シーケンスを表すコンピュータデータ信号であって、処
理装置によって実行されるとき、着信メッセージを前記メッセージ格納構造のデータバケ
ット部に付加するステップと、インデックスデータを生成すべく、前記着信メッセージ
をインデックス修飾するステップであって、少なくとも
いくつかのインデックス修飾は、前記着信メッセージが
前記データバケットに付加される間に完了される、イン
デックス修飾ステップと、前記インデックスデータを前記メッセージ格納構造のイ
ンデックス部に付加するステップとを、実行することに
よって前記処理装置に着信メッセージをメッセージ格納
構造内に格納させる、コンピュータデータ信号。
【請求項４４】搬送波に具現化されていると共に命令
シーケンスを表すコンピュータデータ信号であって、処
理装置によって実行されるとき、前記メッセージ格納構造内に既存するメッセージに対す
るアクセスを実質的に妨げることなく、着信メッセージ
を前記メッセージ格納構造のデータバケット部に付加す
るステップと、インデックスデータを生成すべく、前記着信メッセージ
をインデックス修飾するステップと、前記インデックスデータを前記メッセージ格納構造のイ
ンデックス部に付加するステップとを、実行することに
よって前記処理装置に着信メッセージをメッセージ格納
構造内に格納させる、コンピュータデータ信号。