JP2000224251A - メッセ―ジ格納構造内のデ―タへ高速アクセスする方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】競合を低減したマルチスレッド・システムのメ
ッセージ格納構造内のメッセージへアクセスするための
方法及び装置を提供する。 【解決手段】新規接続を受理するために使用可能なプロ
セスが存在するか否かを最初に決定し、次いで、前記の
新規接続の責務を１つ以上のスレッドを有する前記のプ
ロセスへ転送することによって競合を低減する。１つの
スレッドが選択され、かつ初期化され、そして、同スレ
ッドはメッセージ格納構造内のメッセージまたはデータ
へのアクセスを求めるクライアント・リクエストを管理
する。終了リクエストを受信した際、または所定の条件
が満たされた際、スレッドは終了する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】一般的に、本発明はコンピュ
ータ・ソフトウェア及びクライアント−サーバー・アプ
リケーションの分野に関する。特に、本発明は分散コン
ピューティング環境内のデータへアクセスする方法に関
する。

【０００２】

【従来の技術】１９９０年代におけるネットワーク・コ
ンピューティングの急速な成長は、電子メールと最も一
般的に称される普及した通信形態をともなう。家庭、企
業、小規模ビジネス、高等教育機関または政府組織で
は、更に多くの個人がある種のコンピュータ・ネットワ
ークへ接続されたコンピュータへアクセスできるように
なった。これによって、電子メールは好ましい通信方式
として急速に受け入れられつつある（多くの環境では、
既に好ましい通信方式となっている）。一度限りの簡単
なメッセージの送信であるか、長い論議若しくは会話で
あるかを問わず、人々は電子メールが通信のための能率
的かつ効果的な方法であることを認識している。

【０００３】電子メールは企業及び大学などの大きな組
織の内部ネットワーク内でのメッセージ送信に過去何年
間も使用されている。そして、電子メールは固有のフォ
ーマット及びプロトコルに一般的に基づいている。その
一方、インターネットは電子メールを大企業の領域から
メインストリームへ導き出した。インターネットは公的
にアクセス可能な世界的コンピュータ・ネットワークで
ある。このため、インターネットの電子メール能力に起
因して、インターネットは広く使われている。更に、固
有のフォーマット及びプロトコルに代わって、ＴＣＰ／
ＩＰ（“トランスミッション・コントロール・プロトコ
ル／インターネット・プロトコル”）、即ち、インター
ネットの通信レイヤーはＴＣＰ／ＩＰに基づくイントラ
ネットとして知られるコンピュータ・ネットワークを私
的組織内で構築すべく使用されている。例えば、このア
プローチは企業または大学による内部コンピュータ・ネ
ットワークの保有を可能にし、同内部コンピュータ・ネ
ットワークはインターネットと互換性を有し、かつウェ
ブ・サイト、ハイパーリンクを形成する能力及び電子メ
ールの送受信を含むインターネットの全ての特徴を有す
る。

【０００４】電子メールに関しては、インターネットの
爆発的成長及びイントラネットの拡大する魅力が電子メ
ール・メッセージの急増を招来した。一般的に、電子メ
ール・メッセージは受信され、かつネットワーク・サー
バーまたはクライアント・マシン及び独立型マシンのハ
ード・ドライブへ格納される。電子メール・メッセージ
を電子的に保存し、かつ要求に応じて簡単に検索する傾
向または営み及び必要性がある。例えば、アイデア、コ
メントまたは分析を含むメッセージを異なる複数の国の
研究者間などで数年間にわたって送信するような任意の
研究環境では、これは重要となり得る。例えば、連絡の
取れなくなった２人の研究者間で２年前の特定の時刻に
送信された特定のメッセージを検索する必要性が予測で
きる。勿論、この能力はビジネス環境または他の環境に
おける重要かつ有効な特徴であり得る。

【０００５】電子メールの急増と、保存するメッセージ
の増大する数量と、保存メッセージを検索することを求
める増大する要求とは、現在のインデックス付け方式及
びメッセージ記憶領域（メッセージ格納構造）に関する
問題点を露呈した。メッセージをクライアント・マシン
の代わりにサーバー内へ保存する傾向が強まりつつあ
る。メール・サーバーはメッセージの中心的保管庫とし
て機能する。更に、メール・サーバーは定期的にバック
アップされ、管理者によってメンテナンスされ、さら
に、壊れた際（例：クラッシュした際）には、（ほとん
どの場合）迅速に修理されるという利点を有する。従っ
て、ユーザーがリクエストを送信した際、同リクエスト
はサーバーによって取り扱われ、かつクライアントへ送
信される。

【０００６】今日の電子メール・メッセージの構成はリ
クエストの種類同様に様々である。簡単なケースでは、
所定のヘッダー以外に、電子メール・メッセージは数行
のテキストからなる簡単なメッセージ部分を有し得る。
その一方、電子メールは幾つかの添付ファイルを有し得
る。添付ファイルの例は、複雑なグラフィックス、オー
ディオ・セグメント、ビデオ、アニメーション、特別な
エンコーディング（例えば、非ラテン語系言語で記述さ
れている場合）を有するテキスト、及び他の電子メール
・メッセージ全体を含む。

【０００７】メッセージに関するリクエストは、所望の
情報の深度及び幅の点で様々である。例えば、リクエス
トは２人の間で数年前に送信された１つのメッセージの
全内容を求めるリクエストであり得る。また、リクエス
トは過去２４時間の間に送信された特定の主題に関する
任意のメッセージの受取人のリスト（リクエストはメッ
セージを開いた受取人及びメッセージを開かなかった受
取人を区分けしている）を求めるリクエストであり得
る。つまり、電子メール・メッセージの性質及び電子メ
ール・メッセージ・データに関するリクエストの性質は
更に複雑になってきており、これによって、メッセージ
の格納及び検索を取り扱ううえでの現在のメール・サー
バーの弱点が露呈される。

【０００８】前記のメッセージの格納及び検索に現在使
用されている殆どのメール・サーバーはインターネット
・メッセージ・アクセス・プロトコル、即ち、ＩＭＡＰ
に基づいて構築されている。ＩＭＡＰプロトコルはメッ
セージを操作するためのコマンドと、同メッセージに関
連する全ての情報及びこれらに対して実施されたアクシ
ョンを分類して格納するためのインデックスとのコレク
ションである。ＩＭＡＰに基づいて構築されたサーバー
がＩＭＡＰプロトコルの全ての効果を得るためには、メ
ッセージの内容と、メッセージに関するメタ・データと
を含むネットワーク上のユーザー及びメッセージに関す
る情報を、ＩＭＡＰインデックス付けの効果を利用する
方法で格納する必要がある。ＩＭＡＰサーバーはデータ
をＩＭＡＰインデックス付けにある程度基づいて格納す
る。しかし、迅速で信頼でき、かつ競合を生じないデー
タの検索及び格納を最適化する方法で、これを実施する
ＩＭＡＰサーバーは存在しない。

【０００９】現在のＩＭＡＰサーバーは、競合問題と、
低いパフォーマンスを招来する他の非能率性とに直面し
ている。これらのＩＭＡＰサーバーはレコードを形成す
るフィールドのコレクションとしてメッセージ・データ
を取り扱う、即ち、同ＩＭＡＰサーバーはレコードに基
づいている。その一方、ユーザー・インボックスへの新
規メッセージの書き込みは、インボックス内における他
のオペレーションの実施からユーザーを締め出す。これ
らのＩＭＡＰサーバーのメッセージ格納構造は、ＩＭＡ
Ｐ内で利用可能なインデックス付けを効果的に使用すべ
く設計されていない。例えば、ユーザーは特定のフィー
ルド（例：日付、受取人、主題など）に関する情報のみ
をメールボックス内の全てのメッセージから望み得る。
ＩＭＡＰサーバーはデータに関する一般的なユーザーの
リクエストを満たすのに必要な情報より更に多くの情報
を検索する。従って、特定のユーザーへ送信された特定
の主題に関するメッセージの数量を単に得るために、Ｉ
ＭＡＰサーバーは全てのメッセージの全ての内容をディ
スクから読み込み得る。更に、現在のＩＭＡＰサーバー
はＩＭＡＰ内で可能な完全性及び整合性の強力なチェッ
ク能力に欠けている。

【００１０】他のメール・プロトコル及びオペレーティ
ング・システムは、メッセージ全体の読み込みまたはコ
ピーを、メッセージに関するリクエストされた情報の種
類に関係なく必要とする。例えば、ポスト・オフィス・
プロトコル（ＰＯＰ）に基づいて構築されたサーバーは
メッセージ全体をそのオペレーションにおいて配信す
る。これはＵＮＩＸオペレーティング・システム内のフ
ァイルベースの古いメール環境であるＶＡＲＭＡＩＬに
類似している。ＶＡＲＭＡＩＬでは、メッセージの配信
はメール・フォルダへの全ての書き込みオペレーション
をロックアウトする。この誤ったプロシージャはメール
配信システムの速度を大幅に低下させる。更に、ＶＡＲ
ＭＡＩＬ環境は同じ電子メール・メッセージの複数のコ
ピーをクライアント・マシンのメモリ内に格納すること
を要する。

【００１１】

【発明が解決しようとする課題】従って、サーバーをベ
ースとしたメッセージ格納構造内のメール・メッセージ
へアクセスし、かつ同メール・メッセージを操作する方
法であって、ロッキング競合を最小限に抑制し、かつメ
ッセージ格納構造の構成の効果を利用することによって
メール・メッセージへの高速アクセスを提供する方法が
必要である。メッセージのメモリ効率の良い高速検索及
び操作をハイエンド・ユーザー・ハイボリューム分散コ
ンピューティング環境内で可能にすべく、この方法はメ
ッセージ格納構造内に提供された高いレベルのインデッ
クス付けの効果及びメッセージ・データを利用する。

【００１２】

【課題を解決するための手段】本発明の目的を達成すべ
く、メッセージ格納構造内のデータへアクセスするため
の方法、装置及びコンピュータ読み取り可能媒体を提供
する。本発明の１つの態様に基づき、マルチスレッド・
システムのメッセージ格納構造内のデータへアクセスす
るための方法を開示する。プロセスを新規接続の受理に
使用可能か否かをシステムは決定し、同新規接続に関す
る責務を前記のプロセスへ転送し、同プロセスは１つ以
上のスレッドを有する。１つのスレッドを選択し、かつ
初期化する。そして、メッセージ格納構造内のメッセー
ジまたはデータへのアクセスを求めるクライアント・リ
クエストを前記のスレッドは管理する。終了リクエスト
を受信した際、または所定の条件が満たされた際、同ス
レッドを終了させる。

【００１３】本発明の１つの実施形態では、リクエスト
をクライアント・リクエスト待ち行列から受信すること
によって、クライアント接続が確立される。プロセスを
選択し、接続を同プロセスへ通知する。システム内の選
択したプロセス及び他のプロセスによるアクセスが可能
な共有メモリから前記の接続に関する情報を、前記の選
択したプロセスは検索する。別の実施形態では、プロセ
ス及びスレッド識別子を格納するために、共有メモリ内
でセルを割り当てる。そして、スレッドを入力ポーリン
グへ関連付けして、スレッドを待ち状態にする。これに
よって、選択したスレッドは初期化される。更に別の実
施形態では、選択したプロセスは着信データを知らせる
警告を入力ポーリング・スレッドから受ける。そして、
着信データはプロセスと、同プロセス内のスレッドとに
対してルーティングされる。更に別の実施形態では、選
択したプロセス内の接続スレッドへのクリティカル信号
はクリティカル信号スレッドによって取り扱われる。ク
リティカル信号スレッドは選択したプロセス全体の終了
（さらに、同プロセス内の全ての接続スレッドの突然終
了）を防止し、かつクリティカル信号の原因となった接
続スレッドのみを規則正しく終了させる。

【００１４】本発明の別の態様では、メッセージ格納構
造内のメッセージを複製する方法を開示する。別のユー
ザー・フォルダがメッセージを参照していることを表示
するために、メッセージに関連するメッセージ格納構造
内のリファレンス・カウンタを更新する。メッセージに
関連する複製ユーザー・フォルダ・セルを宛先ユーザー
・フォルダへ付加する間、メッセージを格納する宛先ユ
ーザー・フォルダへのアクセスを制限する。そして、前
記のユーザー・フォルダ・セルはメッセージ上の情報を
含む一方で、同メッセージの実際の内容を含まない。本
発明の更に別の態様では、宛先ユーザー・フォルダを閉
じる前に、他のロックが宛先ユーザー・フォルダ上に存
在するか否かを決定する。本発明の更に別の態様では、
リファレンス・カウンタを更新する間、メッセージに対
応するインデックス・ディレクトリ・セルへのアクセス
を一時的に制限する。

【００１５】本発明の更に別の態様では、ユーザー・フ
ォルダ、インデックス・フォルダ及びデータ・バケット
を含むメッセージ格納構造内のメッセージの特定の部分
へアクセスする方法を開示する。対応するインデックス
・フォルダ・セルの位置を知るために、メッセージに関
連するメール・フォルダ・セルを検査する。次いで、デ
ータ・バケット内に含まれるメッセージの特定のセクシ
ョンの位置を決定するために必要な情報を獲得するため
に、インデックス・フォルダ・セルを検査する。そし
て、メッセージの特定のセクションを検索する。別の実
施形態では、インデックス・ディレクトリ及びインデッ
クス・ファイルを識別するために、メッセージをメール
・フォルダ・セルへ書き込んだ日付は使用される。メッ
セージに関連するインデックス・ファイル・セルの位置
を決定するために、インデックス・ディレクトリ・セル
は使用され、インデックス・ファイル・セルは探索して
いるメッセージの特定のセクションへ導く情報を含む。

【００１６】本発明の別の態様では、メッセージ格納構
造内のメッセージへアクセスするためのコンピュータ・
システムを開示する。メッセージ格納構造への接続を要
求するクライアント・リクエストはリクエスト・ルータ
によって受信され、かつルーティングされる。リクエス
ト・ルータは１つ以上のマルチスレッド・リクエスト・
ハンドラへ接続されており、各ハンドラは１つ以上の接
続スレッドを有する。リクエスト・ハンドラ識別器（識
別子）及び接続スレッド識別器（識別子）を有する共有
メモリがリクエスト・ルータに関連している。リクエス
ト・ルータへ接続された全てのリクエスト・ハンドラは
共有メモリへアクセス可能である。

【００１７】１つの実施形態では、リクエスト・ルータ
はリクエスト・ハンドラ生成器を有する。新規接続スレ
ッドを維持するために使用可能なリクエスト・ハンドラ
の不在が確定した際、リクエスト・ハンドラ生成器は新
規リクエスト・ハンドラを形成可能である。別の実施形
態では、リクエスト・ルータは同リクエスト・ルータへ
接続された１つ以上のリクエスト・ハンドラを管理す
る。更に別の実施形態では、リクエスト・ハンドラ内の
アクティブ接続スレッドへの入力イベントを検出するた
めの入力ポーリング・スレッドを各リクエスト・ハンド
ラは有する。更に別の実施形態では、各リクエスト・ハ
ンドラは同リクエスト・ハンドラ内の特定のアクティブ
接続スレッドへのクリティカル信号を検出するためのク
リティカル信号スレッドを有する。クリティカル信号ス
レッドはクリティカル信号の原因となった特定のアクテ
ィブ接続スレッドのみを終了し、これによって、リクエ
スト・ハンドラ内の他のアクティブ接続スレッドを機能
した状態に維持する。更に別の実施形態では、リクエス
ト・ルータによって割り当てられた共有メモリは接続ス
レッドに関連したスレッド固有データ・セルを有し、同
スレッド固有データ・セルはリクエスト・ハンドラ識別
器（識別子）及び接続スレッド識別器（識別子）を含
む。

【００１８】本発明とその更なる効果は添付図面に基づ
く以下の説明から最もよく理解できる。

【００１９】

【発明の実施の形態】本発明の好ましい実施形態を以下
に詳述する。好ましい実施形態の一例を添付図面に示
す。本発明を好ましい実施形態に関連して詳述するが、
これは本発明を１つの好ましい実施形態に制限すること
を意図するものではない。逆に、請求の範囲により定義
される本発明の趣旨及び範囲を逸脱しない改良例、変更
例及び等価等を包含することを意図する。

【００２０】メッセージ格納構造（格納装置）内のデー
タへアクセスし、かつ同データを操作するための改善さ
れた方法であって、フォルダ内の競合を最小限に抑制す
るとともに、インデックス付けの効果及び他の参照デー
タを利用する方法を複数の図面に示す。本実施形態にお
いて、メッセージ格納構造内のメッセージ・データを操
作する際、フォルダの必要な部分のみを保護するため
に、本発明の方法はセクション・ロッキングを使用す
る。更に、メッセージ格納構造内のメッセージ・データ
の位置の迅速な検出、同メッセージ・データの複製、ま
たは同メッセージ・データの操作を行うために、本発明
の方法はカウンタと、レコードのサイズ及びオフセット
と、リファレンス・ポインタとを使用する。前記のよう
に、本実施形態では、電子メール・メッセージをサーバ
ーへ格納し、かつ同電子メール・メッセージへインデッ
クス付けを行うことが望ましい。そして、サーバーはク
ライアントのメッセージに関するデータに対するクライ
アント・リクエストに応答する。これを行う２つのプロ
トコルはインターネット・メッセージ・アクセス・プロ
トコル（ＩＭＡＰ）及びポスト・オフィス・プロトコル
（ＰＯＰ）である。本実施形態では、サーバーは最も一
般的に使用されているメール・プロトコルのメッセージ
を管理し、かつ格納すべく構成可能である。本実施形態
において、サーバーはＩＭＡＰコマンド及びＩＭＡＰメ
ッセージに主に応答すべく構成されているが、ＰＯＰま
たは他のメール・プロトコルに基づくメッセージを処理
し、かつ格納し得る。本実施形態において、ＩＭＡＰサ
ーバーはある程度のインデックス付けを現時点で有す
る。しかし、メッセージ格納構造の全体的な構成及びイ
ンデックス付けのレベルはデータに関する複雑で厳しい
ユーザー・リクエストを効果的に処理できない。

【００２１】従って、例えば、本実施形態のサーバーは
ＩＭＡＰに基づいて構成されたサーバーであり、同サー
バーは一般的に数千のユーザーのインターネット電子メ
ールを格納する。従って、本実施形態で使用するインタ
ーネット電子メール・メッセージの構成を簡単に説明す
ることは効果的といえる。当業者に知られているよう
に、インターネット電子メール・メッセージはＭＩＭＥ
に基づいてフォーマットされている。ＭＩＭＥメッセー
ジはＭＩＭＥヘッダー及び１つ以上の本体部分、即ちセ
クションからなり、各本体部分はヘッダーを有する。電
子メール・メッセージがオーディオ、ビデオ・イメー
ジ、非英語テキスト及びＨＴＭＬ等の様々な種類のメデ
ィアを含むことを、ＭＩＭＥフォーマットは可能にす
る。本実施形態のメッセージ格納構造はＭＩＭＥセクシ
ョンを以下に詳述する各種インデックスを介して格納す
る。本発明のメッセージ・アクセス方法は特殊なリクエ
ストの効果的な取り扱いを可能にする。例えば、特定の
メッセージの全てを検索することなく、同メッセージの
特定のＭＩＭＥセクションのみを検索することを本発明
のメッセージ・アクセス方法は可能にする。

【００２２】図１は本発明の１つの実施形態に基づくメ
ッセージ・アクセス・コンフィギュレーションの各種コ
ンポーネント及び方法を示すブロック図である。本実施
形態では、格納され、かつアクセスされるメッセージは
インターネット電子メール・メッセージである。インタ
ーネット・メッセージ（ＩＭ）アクセス・デーモン１０
０はメッセージ格納構造を有するＩＭＡＰサーバー等の
ネットワーク・メール・サーバー上に常駐する。本発明
で使用するメッセージ及びインデックス情報を格納する
ためのＩＭＡＰメッセージ格納構造の例は、メッセージ
格納構造と称する同時係属出願に開示されている。デー
モン１００内の親プロセス１０２はクライアント１０４
から送信された（一般的には、接続のコマンドまたはリ
クエストである）データに応答する。クライアントから
の接続のリクエスト１０６は待ち行列内に格納される。
そして、リクエスト１０６を形成するプロトコルに基づ
き決定されたポートで、サーバーは同リクエスト１０６
を受信する。例えば、ポート番号１４３はＩＭＡＰコマ
ンドのために予約されており、ポート１１０はＰＯＰコ
マンドのために予約されている。これらのプロトコルの
詳細は以下に開示する以外に、メッセージ格納構造と称
する同時係属出願に開示されている。メール・トランス
ファ・エージェント（ＭＴＡ）がサーバー（図１におけ
る図示略）上に常駐し、かつクライアントからのリクエ
ストに応答することは当業者に周知である。サーバーが
リクエスト１０６に応答した後、クライアントとの接続
１０８が確立される。そして、クライアントはメールへ
のアクセス及びメールの操作に用いるコマンド等のデー
タの送信を開始することができる。

【００２３】親プロセス１０２は並行動作する数種類の
子プロセス１１０の制御権を有する。親プロセス１０２
の制御下にある子プロセスのリスト１１２は親プロセス
１０２によって維持されている。各子プロセス１１０は
数種類のスレッドを有し、各スレッドは幾つかの状態の
うちの１つを有し得る。本実施形態では、５０〜２００
個のスレッドが各子プロセス内に存在する。スレッドの
数量は経験的に決定可能であり、かつシステムが動作す
る特定のプラットフォームに基づいている。クライアン
ト及びサーバーの間の接続が確立された後、線１１４で
示すスレッド及びクライアントの間のセッションが確立
される。

【００２４】本実施形態では、子プロセス、スレッド、
及び同スレッドに関連する接続は、番号または識別子を
それぞれ有する。この情報は一連のデータ・セルを有す
る共有メモリ内に格納され、同共有メモリは全ての子プ
ロセスによる読み出し及び更新が可能である。一般的
に、子プロセス同士は互いの存在を認識しないうえ、互
いに通信できないため、共有メモリの使用は効果的であ
る。別の好ましい実施形態では、子プロセス同士が互い
に直接通信可能な場合、共有メモリを削除してもよい。
他の子プロセス内の他のスレッドがメールボックスに対
して書き込みを実行している場合に、特定の子プロセス
内のスレッドがメールボックスを開こうとすると、競合
が発生し得る。本実施形態では、子プロセスが形成され
た際、親プロセスは同子プロセスに関連する共有メモリ
・セルを即座に割り当てる。

【００２５】スレッドが子プロセス内で形成された後、
スレッド固有データ・セル（Thread-specific data cel
l）が同スレッドへ割り当てられる。本実施形態では、
サーバーを起動した際、共有メモリは親プロセスによっ
て構築され、かつ事前割り当てされる。別の好ましい実
施形態では、必要に応じて、共有メモリをオペレーティ
ング・システム内の他のエンティティによって構築し得
る。共有メモリのサイズは親プロセスが管理し得るプロ
セス及びスレッドの最大数に基づいている。更に、共有
メモリのサイズは異なる複数のプラットフォーム上でそ
れぞれ異なる。前記のように、共有メモリは一連のデー
タ・セルからなる。これらのセルはプロセスに対応する
座標“ｉ”と、このプロセス内のスレッドに対応する座
標“ｊ”とによって識別される。従って、セル（Ｐ_i，
Ｔ_j）はスレッド固有データ・セルであり、同スレッド
固有データ・セルは派生メールボックス・インデックス
“ｋ，”をさらに含む。メールボックスの更新またはメ
ールボックスからのメッセージのコピー等の１つのスレ
ッドのアクションを同スレッドから他のスレッドへ通知
することを、派生メールボックス・インデックス
“ｋ，”は可能にする。１つのスレッドのアクションを
同スレッドが同じ親プロセスの下にある他の全てのスレ
ッドへ通知することを、共有メモリ内に存在する本実施
形態のスレッド固有データ・セルは可能にする。主にロ
ッキング競合に関する前記のセルの目的は以下に詳述す
る。従って、共有メモリはサーバー上に常駐し、親プロ
セスが起動した後、共有メモリは親プロセスによって事
前割り当てされ、かつ制御される。本実施形態では、ス
レッド固有データ・セルはユーザー名と、ログイン時刻
または接続時間と、使用するメール・プロトコル（例：
ＩＭＡＰまたはＰＯＰ）とをさらに含む。

【００２６】図２は本発明の１つの実施形態に基づくメ
ッセージ・アクセス方法の概略を示すフローチャートで
ある。前記のように、ネットワーク上のメール・データ
を受信し、かつ操作する複数のユーザー間でのロッキン
グ競合を減少するために、本発明のメッセージ・アクセ
ス方法はメッセージ格納構造と共に用いられる方法であ
る。ステップ２００では、サーバーは接続リクエストを
ネットワーク上のクライアントからのリクエストの待ち
行列から受信する。別の好ましい実施形態では、本発明
のメッセージ・アクセス方法はメッセージ格納構造への
アクセスを行う独立ユーザーによる使用が可能である。
スレッド及びクライアントの間のセッションを形成する
接続を確立すべく、クライアントはサーバーへ接続する
ためのリクエストを最初に生成する必要がある。クライ
アントが使用するメール・プロトコルに基づいて決定さ
れたポートにおいて、サーバーは接続リクエストを受信
する。ステップ２０２では、許容可能なスレッドの最大
数より少ない数のスレッドを有する子プロセスが存在す
るか否かをシステムは決定する。前記のように、子プロ
セス内のスレッドの最大数は特定のプラットフォームに
おけるパフォーマンスに基づいて決定可能である。例え
ば、ハイボリューム分散型環境では、スレッドの数量は
５０〜２００個の範囲である。これは親プロセスに含ま
れる子プロセスのリストをチェックすることによって決
定される。全ての既存子プロセスが最大数のスレッドを
有する場合、ステップ２０４に示すように、親プロセス
は新規子プロセスを形成する。本実施形態のこの段階に
おいて、親プロセスは共有メモリ内の所定量のスペース
を子プロセスに対して割り当てる。本実施形態では、子
プロセスが形成され、かつ接続が確立されることによっ
て、親プロセスがクライアント・リクエストの処理を再
開できるようになるまで、親プロセス及びクライアント
・リクエストの間の更なるアクティビティをブロックす
るために、親プロセスはセマフォを共有メモリ内で使用
する。新規子プロセスを適切に形成し、同子プロセスに
よる新規接続の受理を保証するために、これは望まし
い。ステップ２０６では、新規子プロセスが形成された
後、親プロセスは接続責務を選択した子プロセスへ渡
す。子プロセスがステップ２０２で使用可能な場合、親
プロセスは接続責務を最低数のスレッドを有する子プロ
セスへステップ２０６において渡す。別の好ましい実施
形態では、親プロセスは適切な子プロセスを選択するた
めの他の基準を使用可能である。

【００２７】ステップ２０８では、受理した接続を管理
するために、選択した子プロセスはスレッドを初期化す
る。受理した接続はクライアントが使用するプロトコル
（例：ＩＭＡＰまたはＰＯＰ）に基づいて管理される。
本実施形態では、各子プロセスは新規アクティブ接続ス
レッドを初期化する初期化スレッドを有する。別の好ま
しい実施形態では、新規アクティブ接続スレッドは子プ
ロセスの外側で初期化可能である。ステップ２１０で
は、選択した子プロセス及びスレッドはクライアント・
リクエストを管理する。メッセージのコピーまたはメッ
セージの検索などのクライアント・リクエストを管理す
るスレッドの例は以下に詳述する。このステージでは、
マスター及びスレーブの関係がクライアント（マスタ
ー）と、同クライアントに対して新たに形成されたスレ
ッド（スレーブ）との間に形成される。ステップ２１２
では、クライアントが接続を終了するか、または所定時
間のアイドル状態からタイムアウトした際、親プロセス
はスレッド・クリーンアップを開始する。スレッド・ク
リーンアップ及びイグジット（exit）では、スレッドに
関連する全てのリソースは他のスレッドが利用できるよ
うに解放される。スレッド・クリーンアップの後、クラ
イアントのためのメッセージ・アクセス・プロシージャ
が完了する。

【００２８】図３は図２のステップ２０６に示す接続責
務を子プロセスへ渡すステップの詳細を示すフローチャ
ートである。ステップ３００では、親プロセスは選択し
た子プロセスへ信号を送信する。接続メンバーによって
識別され、かつ子プロセスによって管理される新規接続
が存在することを、この信号は示す。別の好ましい実施
形態では、セマフォを信号に代えて使用可能である。子
プロセスはＳＬＥＥＰ（スリープ）状態にあり得る。こ
の場合、信号は選択した子プロセスを目覚めさせる。ス
テップ３０２では、子プロセスは図１ｂで示す共有メモ
リへアクセスする。子プロセスは新規接続番号をスレッ
ド固有データ・セルから読み取る。コマンドがＰＯＰ若
しくはＩＭＡＰまたは他のメール・プロトコールで記述
されているか否かを、スレッド固有データ・セルはさら
に示す。ステップ３０４では、新規接続が子プロセスに
よって受理され、メールを操作及び検索するための新規
リクエストをこの時点で受理可能なことを親プロセスへ
通知する。ステップ３０６では、親プロセスは選択した
子プロセスのための接続カウンタをインクリメントす
る。選択した子プロセスのための接続カウンタまたはス
レッド・カウンタを親プロセスがインクリメントした
後、同親プロセスは次の接続リクエストを受信するまで
システム・コールを待つ。次いで、受理した接続を管理
すべく、選択した子プロセスがスレッドを初期化する図
２のステップ２０８をプロセスは続ける。

【００２９】図４は図２のステップ２０８に示すスレッ
ドを初期化するステップの詳細を示すフローチャートで
ある。ステップ４００では、システムは共有メモリ内の
スレッド固有データ・セルを割り当てる。スレッド固有
データ・セルは座標Ｐ_i及びＴ_iを有し、Ｐはプロセス番
号を示し、Ｔはスレッド番号を示す。これらの座標また
は番号はスレッドをグローバル・コンテキスト内で管理
するために使用される。本実施形態では、スレッド固有
データ・セルは接続番号を有する。ステップ４０２で
は、選択した子プロセス内において、システムはアクテ
ィブ接続スレッドを形成し、かつ実行する。コマンドを
受信したポート・アドレスによって決定されるプロトコ
ル固有をアクティブ接続スレッドは有する（即ち、ＩＭ
ＡＰまたはＰＯＰに適合している）。本実施形態では、
新規アクティブ接続スレッドはステップ４０４で待ち状
態となり、同新規アクティブ接続スレッドはユーザー・
リクエストまたはシステム割り込みなどの入力イベント
の発生を待つ。アクティブ接続スレッドは入力待ち状態
にあり、同アクティブ接続スレッドはリクエストを受信
するか、またはアイドル・タイムアウトになる。ステッ
プ４０６では、メッセージ格納構造内のデータへのアク
セスを求めるクライアント・リクエストまたは同データ
を読み取ることを求めるクライアント・リクエストの管
理を子プロセス及び新規スレッドは開始する。次いで、
アクティブ接続スレッドによってクライアント・リクエ
ストを管理する図２のステップ２１０をプロセスは続け
る。

【００３０】図５は図２のステップ２１０に示す選択し
た子プロセス及びスレッドによるクライアント・リクエ
ストの管理のステップの詳細を示すフローチャートであ
る。本実施形態では、ステップ５００に示すように、子
プロセスの入力ポーリング・スレッドは親プロセスが新
規データを受信したことを知らせる警告を受ける。本実
施形態では、オペレーティング・システム内に存在する
ライト・ウェイト・プロセスのプールから選択された１
つのライト・ウェイト・プロセスによって入力ポーリン
グ・スレッドは実現される。別の好ましい実施形態で
は、子プロセスは入力を監視するために別個のスレッド
を使用しない。例えば、各接続スレッドは入力データを
直接待つ責務を有し得る。新規データは新規ＩＭＡＰコ
マンドまたはＰＯＰコマンドであり得る。新規データは
３つの状態、即ち、１）新規コマンド（クライアント・
スレッドが新規コマンドを処理する）、２）アイドル・
タイム・アウト（スレッドはクライアント・コマンドを
継続する一方で、アイドル・タイム・アウト・コンディ
ションをクライアントへ通知する）及び３）突然終了接
続（接続が突然切断され、子プロセスはクライアント・
コマンドの処理を継続する一方で、接続が切断されたこ
とをクライアントへ通知する）のうちのいずれか１つの
状態となり得る。ステップ５０２では、入力ポーリング
・スレッドは新規受信データをアクティブ接続スレッド
に対してポストする。アクティブ接続スレッドは待ち状
態にある。そして、アクティブ接続スレッドがデータを
受信したことを、同アクティブ接続スレッドが入力ポー
リング・スレッドから通知された後、アクティブ接続ス
レッドは目覚める。ステップ５０４では、アクティブ接
続スレッドは受信データ（一般的には、コマンド）を処
理する。これは図６に詳細に示す。親プロセスから新規
データを受信するために入力ポーリング・スレッドを使
用する技術は、オペレーティング・システム内の限られ
た数のライト・ウェイト・プロセスの使用を最小限に抑
制する。しかし、前記のように、別の好ましい実施形態
では、着信データを監視するために、入力ポーリング・
スレッドなどの別個のスレッドを子プロセスは使用しな
い。着信データを検出するために、各アクティブ接続ス
レッドは独自のライト・ウェイト・プロセスを有し得
る。前記のように、本実施形態では、ポーリング・スレ
ッドを実現するために、１つのライト・ウェイト・プロ
セスのみを要する。ポーリング・スレッドは任意の着信
データを監視し、かつ同データを適切なアクティブ接続
スレッドに対してポストする。着信データを監視し、同
データが特定の接続スレッドのためのデータであるか否
かを決定するために、各アクティブ接続スレッドが独自
のライト・ウェイト・プロセスを有することの必要性を
入力ポーリング・スレッドは低減する。

【００３１】ステップ５０６では、受信データが終了コ
マンドであるか否か、または接続が他の任意の方法によ
って終了されたか否かをシステムは決定する。例えば、
終了コマンドはログアウト・コマンドまたはクイット・
コマンド（quit command）であり得る。データが終了コ
マンドである場合、または接続が終了した場合、制御は
図２のステップ２１２へ移行し、システムはスレッド・
クリーンアップ及びイグジットを行う。受信データが終
了コマンドでない場合、システムはステップ５０８に示
すように次のアクティベーションを待つ待ち状態へ戻
る。

【００３２】接続を終了する別の方法としては、クリテ
ィカル信号スレッドと称される専用の特別スレッドによ
る終了が挙げられる。クリティカル信号はオペレーティ
ング・システムからクリティカル信号の原因となったア
クティブ接続を有するプロセスへ送信される。そして、
クリティカル信号スレッドがクリティカル信号を検出す
る。本実施形態では、クリティカル信号は不正メモリア
クセスまたは不正インストラクションを試みる接続スレ
ッドが原因となって生じる。例えば、スレッド内のコー
ドは不正命令（例えば、値をゼロで除算すること）を試
みるか、または存在しないメモリ・アドレスへのアクセ
スを行い得る。クリティカル・コンディションが発生し
た際、クリティカル信号スレッドはオペレーティング・
システムから送信された信号を受信し（オペレーティン
グ・システムはハードウェアから直接通知を受ける）、
クリティカル信号の原因となった接続スレッドを規則正
しく終了させる。複数のスレッドのうちの１つがクリテ
ィカル信号の原因となった際、プロセス全体の終了と、
同プロセス内の全ての接続スレッドの終了とを引き起こ
すクリティカル信号への望ましくないリアクションを、
クリティカル信号スレッドは防止する。本実施形態で
は、各接続スレッドのコンテキストはプロセス内の他の
接続から効果的に隔離されている、即ち、ファイアウォ
ールで隔てられている。この結果、有害なスレッドまた
はクラッシング・スレッドによって、無害なスレッドの
リソースまたはデータが破壊されることを恐れずに、無
害なスレッドは動作の継続が可能である。従って、プロ
セス全体をダウンさせることなく、クリティカル信号ス
レッドは全てのファイルをアンロックして閉じたうえ、
全ての接続を切断し、さらにクラッシュする全ての接続
スレッドの接続の共有メモリをクリアする。

【００３３】図６はクライアントから送られた一般的な
ＣＯＰＹ（コピー）コマンドをアクティブ接続スレッド
によって管理する本発明の１つの実施形態に基づく方法
を示すフローチャートである。これは図２のステップ２
１０で示す選択した子プロセス及びアクティブ接続スレ
ッドによるクライアント・リクエストの管理の方法を示
す一例である。図６に示すクライアント・リクエストは
ＩＭＡＰ ＣＯＰＹコマンドである。ＣＯＰＹコマンド
はＤＥＬＥＴＥ（デリート）、ＲＥＡＤ（リード）、Ｍ
ＯＶＥ（ムーブ）などの様々なコマンドのうちの一例で
ある。ＣＯＰＹコマンドでは、クライアント（Ｃ１）は
メッセージ（ｍ）をインボックス・フォルダからフォル
ダ（またはメールボックス）ｆへコピーすることを望
む。背景説明として述べると、新規着信メッセージを受
信し、かつ保持するインボックス以外に、ユーザーは特
定のトピックに関するメッセージを保持するためのカス
タム・フォルダを形成可能である。ＣＯＰＹコマンドが
有効であるためには、メッセージ及びフォルダｆが実在
する必要がある。クライアントはｆへの接続（ｃｎ１）
を有し、これによって、ｆは選択され、かつアクティブ
になる（即ち、関連するスレッドｔを有する）。クライ
アントはメッセージをインボックスからコピーすること
を望んでいるため、同クライアントは選択されて開かれ
たインボックスを有する。別のクライアント（Ｃ２）は
同じフォルダｆを選択して開いており、同別のクライア
ント（Ｃ２）はフォルダを活発に使用している。メッセ
ージｍをインボックスからフォルダｆへコピーすべく、
Ｃ１はＩＭＡＰ ＣＯＰＹコマンドをサーバーへ送信す
る。本実施形態では、メッセージをコピーした際、メッ
セージ格納構造と称する同時係属出願に開示されている
ように、システムはメッセージ・リファレンスをフォル
ダｆの末端へ付加し、かつメッセージ格納構造内の適切
なカウンタを更新する。以下に詳述するように、本実施
形態のメッセージ格納構造及びスレッド・ロッキング機
構の構造を使用することによって、メッセージの長さに
左右されることなく、ＣＯＰＹコマンドは約５０バイト
のデータをシステム内で複製することを要するのみであ
る。別の好ましい実施形態では、複製するバイト数は変
化し得る。その一方、メッセージ全体の内容をコピーす
る必要があり得る。

【００３４】フォルダｆは開かれており、かつ同一子プ
ロセスの２つのアクティブ接続スレッドを有する。Ｃ１
からの複数の接続のうちの１つの接続ｃｎ１は待ち状態
にある。接続ｃｎ１はＣＯＰＹコマンドで目覚める。ｆ
が選択された際、ｆのファイル記述子またはオペレーテ
ィング・システム識別子ｉを有するフォルダのためのユ
ーザー・コンテキストがこれによって形成される。ステ
ップ６００では、別のフォルダｆによるｍの参照を反映
させるために、システムはｍに関連するインデックス・
ディレクトリ・セル（メッセージ格納構造と称する出願
におけるアイテム１１６）内のリファレンス・カウント
（メッセージ格納構造と称する出願におけるアイテム２
０６）をインクリメントする。リファレンス・カウント
及びインデックス・ディレクトリ・セル並びに以下に詳
述する他のフィールド及びセルは、メッセージ格納構造
と称する同時係属出願に詳述されている。このステップ
は図７に関連して以下に詳述する。コピー・プロシージ
ャ中におけるエラーまたはクラッシュのイベントでは、
リファレンス・カウントは低過ぎるより高過ぎるほうが
常に安全である。このため、メッセージを実際に付加す
る後よりも、その前に、リファレンス・カウントをイン
クリメントすることが望ましい。

【００３５】ステップ６０２では、Ｃ１はｆを開き、こ
れによって、前記のように、ｆのためのユーザー・コン
テキストと、識別子またはファイル記述子Ｉとが形成さ
れる。ＣＯＰＹコマンドを説明する目的で、Ｃ２がｆを
既に選択して開いた状態を想定する。本実施形態では、
スレッドがフォルダを選択して開いた際、これは他のス
レッドのロック・アウトが可能なことを意味しない。即
ち、同じ子プロセス内の別のスレッドによってフォルダ
がロックされたことを認識していない他のスレッドは、
同フォルダへの書き込みオペレーションを試み得る。１
つのスレッドがフォルダを閉じた際、同フォルダ上の全
てのロックが消失する。そして、これらのロックを保持
していた全てのスレッドには同ロックの消失が通知され
ない。別のプロシージャはこれらの特徴に取り組むもの
であり、以下に詳述する。

【００３６】ステップ６０４では、スレッドｔはｆをロ
ックする。フォルダｆは同フォルダｆを選択して開いて
いたスレッドのリスト、即ち、ファイル記述子リスト
と、同フォルダｆ上のロックの数をカウントするための
カウンタとを有する。フォルダｆが開かれた際、ファイ
ル記述子Ｉはステップ６０２でリストへ付加される。ｆ
がロックされた際、ロック・カウンタはステップ６０４
でインクリメントされる。ステップ６０６では、システ
ムはメッセージをフォルダｆへコピーする。メッセージ
ｍに関連するセルはｆのユーザー・フォルダへ付加され
る。ユーザー・フォルダの詳細はメッセージ格納構造と
称する同時係属出願に開示されている。このステップは
図８に関連して以下に詳述する。ｍをｆへコピーした
後、スレッドｔはｆ上における同スレッドｔのロックを
ステップ６０８で除去する。このステージでは、ｔがそ
のロックを解放した直後、同じプロセス内の別のスレッ
ドはｆをロック可能である。次いで、スレッドはステッ
プ６１０でｆを閉じることを試みる。しかし、ステップ
６１２に示すように、ｆが同じ子プロセス内の別のスレ
ッドによってロックされているか否かをシステムが決定
するまで、スレッドはフォルダを閉じることができな
い。前記のように、スレッドがフォルダを閉じた場合、
フォルダ上の全てのロックは消失する。従って、本実施
形態では、フォルダを閉じる前に、フォルダに関連する
ロック・カウンタをチェックすることによって、システ
ムはフォルダ上の他のロックをチェックする。残された
ロックが存在する場合、ステップ６１６において、ファ
イル記述子リスト内の適切なファイル記述子をマークす
ることによって、システムはｆを“クローズド”として
マークする。しかし、システムはフォルダを実際に閉じ
はない。これはフォルダ上のスレッド・ロックを取り扱
うプロシージャの一部である。スレッドｔはフォルダが
実際に閉じられていないことを認識していない。しか
し、スレッドｔはフォルダが閉じられているかのように
オペレーションを継続する。フォルダをスレッドｔの視
野から閉じた後、ＣＯＰＹコマンドは完了する。他のロ
ックがフォルダ上に存在しない場合（即ち、ロック・カ
ウンタがゼロの場合）、ステップ６１４において、子プ
ロセスはｆを閉じ、プロセス・ライブラリからのプロシ
ージャを使用して他の全てのファイルをクローズドとし
てマークする。このステージにおいて、コピーは完了す
る。

【００３７】図７は図６のステップ６００に示す適切な
インデックス内のリファレンス・カウンタをインクリメ
ントするステップの詳細を示すフローチャートである。
ステップ７００では、メッセージ格納構造と称する同時
係属出願に開示されている対応するインデックス・ディ
レクトリ・セル（図１のアイテム１１６）を含む図１の
インデックス・ディレクトリ１０４等のインデックス・
ディレクトリをシステムは開く。ステップ７０２では、
システムはインデックス・ディレクトリに関連するファ
イル記述子を検索する。ステップ７０４では、システム
はメッセージｍに関連するインデックス・ディレクトリ
・セルへのセクション・ロックの適用を試みる。各メッ
セージは関連するインデックス・ディレクトリ・セルを
有する。同インデックス・ディレクトリ・セルは、セル
内のリファレンス・カウント（メッセージ格納構造と称
する同時係属出願の図２の参照カウント・フィールド２
０６）を更新するためにロックを要するインデックス・
ディレクトリの唯一の部分である。別のスレッドがロッ
クをセル上に既に有し得る。このため、ステップ７０６
において、システムはセクション・ロックが成功したか
否かをチェックする。ロックが不成功であった場合に
は、例えば、アイドル・タイムアウト・フラグによって
表示され、ステップ７０８において、コピー失敗を示す
エラー・メッセージがクライアントへ返される。ロック
が成功した場合、システムは、メッセージｍに関連する
インデックス・ディレクトリ・セル内のリファレンス・
カウントをインクリメントする。リファレンス・カウン
トをインクリメントした後、システムはステップ７０４
で取得したインデックス・ディレクトリ・セル上のセク
ション・ロックを除去する。セル上のセクション・ロッ
クを除去するために、システムはセルのオフセット及び
バイト数を必要とする。インデックス・ディレクトリ内
の複数のセルは同時にセクション・ロックされ得るの
で、リファレンス・カウントをインクリメントする際の
ロッキング競合を低減する。

【００３８】オペレーションがフォルダｆの代わりにイ
ンデックス・ディレクトリ・フォルダを使用する点を除
いて、プロセス内の残りのステップは図６のステップ６
１０〜６１６に類似している。従って、ステップ７１４
では、スレッドｔはインデックス・ディレクトリ・フォ
ルダを閉じることを試みる。ステップ７１６では、イン
デックス・ディレクトリ・フォルダが同じプロセス内の
別のスレッドによってロックされているか否かをシステ
ムは決定する。インデックス・ディレクトリ・フォルダ
が別のスレッドによってロックされている場合、ステッ
プ７１８において、子プロセスはインデックス・ディレ
クトリ・フォルダをクローズドとしてマークする。しか
し、フォルダが安全に閉じられ得る状態になるまでは、
子プロセスはフォルダを実際に閉じない。フォルダｆの
場合のように、スレッドｔはインデックス・ディレクト
リ・フォルダが閉じられているかのようにオペレーショ
ンを継続する。他のスレッドによるロックがフォルダ上
に存在しない場合、子プロセスはインデックス・ディレ
クトリ・フォルダをステップ７２０で閉じる。インデッ
クス・ディレクトリ・フォルダが閉じられた後、または
クローズドとしてマークされた後、ＣＯＰＹコマンド・
プロセスはフォルダｆを開く図６のステップ６０２を続
ける。

【００３９】図８はメッセージｍをフォルダｆへコピー
する図６のステップ６０６の詳細を示すフローチャート
である。ステップ７００において、システムはメッセー
ジｍに対応するユーザー・フォルダ・セル（メッセージ
格納構造と称する同時係属出願の図１ｃ及び図６に詳細
を開示）をフォルダｆの末端で複製する。セルは特定の
メッセージに関するデータを含む。そして、セルはユー
ザー・フォルダ・ディレクトリ（メッセージ格納構造と
称する同時係属出願の図２に示す）内のユーザー・フォ
ルダ内に含まれる。本実施形態では、セルは約５４バイ
トの長さを有し、かつ約１３のフィールドを含む。別の
好ましい実施形態では、セルの長さ及びフィールド数は
変化し得る。プロセスはフォルダｆの末端を探索し、メ
モリ内に既にキャッシュしておいた５４バイト・セルを
フォルダの末端へ書き込む。これは超高速書き込みオペ
レーションである。そして、全てのステージにおいて、
メッセージｍ全体を複製またはコピーする必要はない。
ステップ８０２では、メッセージｍがインデックス・フ
ァイル内でグローバル（プライベートの逆）にインデッ
クス付けされたか否かをプロセスは決定する。メッセー
ジが例えば２５６キロバイトなどの特定サイズ未満であ
る場合、同メッセージはグローバルにインデックス付け
可能である。メッセージ・サイズが大きすぎる場合、同
メッセージはクライアント・マシンにおいてインデック
ス付けされる。そして、インデックス・データがメール
・サーバー上へ配置される。メッセージ格納構造と称す
る同時係属出願の図１ｃ及び図６のユーザー・フォルダ
・セル内のフィールド６２０に示す可変インデックス・
レコードのオフセットの値を検査することによって、メ
ッセージがグローバルにインデックス付けされたか否か
を決定できる。可変インデックス・レコード・オフセッ
トがゼロである場合、メッセージｍはグローバルにイン
デックス付けされている。この場合、スレッドｔがその
ロックをフォルダｆから除去する図６のステップ６０８
をプロセスは続ける。可変インデックス・レコード・オ
フセットがゼロでない場合、ステップ８０４に示すよう
に、プロセスはメッセージｍに関するプライベート・イ
ンデックス・データをフォルダｆのプライベート・イン
デックス・ファイル内で複製する。次いで、プロセスは
図６のステップ６０８を続ける。

【００４０】図９は本発明と、メッセージ格納構造と称
する同時係属出願に開示されているメッセージ格納構造
と称する発明とにそれぞれ開示する１つの実施形態に基
づくメッセージ格納構造内に含まれるメッセージ内のデ
ータの特定部分へアクセスする方法のフローチャートで
ある。本実施形態で使用するＩＭＡＰプロトコルでは、
ＦＥＴＣＨ（フェッチ）コマンドはメッセージの特定の
本体部分（例：ＭＩＭＥセクション）を検索するために
使用するデータへアクセスするために使用可能である。
当業者が認めるように、インターネット電子メール・メ
ッセージはＭＩＭＥフォーマットに基づいて常には構成
されている。ＦＥＴＣＨコマンドは図２のステップ２１
０に示す一般的なクライアント・リクエストを管理する
選択した子プロセス及びスレッドの別例である。

【００４１】ステップ９００では、メッセージ格納構造
と称する同時係属出願に開示するメッセージに対応する
ユーザー・フォルダ・セル１３０内の到達時刻フィール
ド６１０を読み取ることによって、スレッドはメッセー
ジがメッセージ格納構造へ書き込まれた日付を決定す
る。ステップ９０２では、スレッドは直前のステップで
確定したメッセージ格納構造へのメッセージの書き込み
の日付に関するトークンを検索する機能を起動する。Ｆ
ＥＴＣＨコマンドを実行するために必要な全てのファイ
ルをスレッドが開くことをトークンは可能にする。本実
施形態では、スレッドによって最初に開かれたファイル
はインデックス・ディレクトリ及びインデックス・ファ
イルを有するインデックス・ファイルである。後の時点
で、スレッドはメッセージ格納構造と称する同時係属出
願に開示されているデータ・バケット識別子を使用し
て、その日付の適切なデータ・バケットを開く。その特
定の日付におけるこれらのファイルが既に開かれている
場合、同ファイルを開くために、スレッドはトークンを
取得する必要がない。

【００４２】ステップ９０４では、メッセージ格納構造
と称する同時係属出願に開示されているメッセージに対
応するユーザー・フォルダ・セル１３８内に格納された
インデックス・ディレクトリ・セル番号６０７をスレッ
ドは獲得する。ステップ９０６では、直前のステップで
取得したインデックス・ディレクトリ番号に対応するイ
ンデックス・ディレクトリ・セルをスレッドは読み取
る。本実施形態では、インデックス・ディレクトリ・セ
ルはインデックス・ファイル・オフセット及びインデッ
クス・ファイル・レコード・サイズを含む。別の好まし
い実施形態では、対応するインデックス・ファイル・セ
ルを直接指し示すポインタまたはアドレスをセルまたは
レコードは含み得る。ステップ９０８に示すように、こ
のオフセット及びレコード・サイズに基づき、スレッド
はメッセージに関連した対応するインデックス・ファイ
ル・セルを読み取る。ＦＥＴＣＨコマンドで探索した特
定の本体部分へアクセスするために現在必要な全ての情
報をインデックス・ファイル・セルは含む。メッセージ
格納構造と称する同時係属出願に詳細を開示するよう
に、データ・バケット内に格納されたメッセージの様々
なセクションのサイズ及び開始位置またはオフセットを
スレッドが迅速に決定することを可能にする幾つかの情
報アイテムを、インデックス・ファイル・セルは含む。
例えば、インデックス・ファイル・セルはメッセージ・
エンベロップ・データ及び本体データと、メッセージ・
ヘッダー・サイズと、データ・バケット識別情報と、デ
ータ・バケット内に格納されたメッセージの様々なセク
ションの位置を決定するために使用可能なＭＩＭＥセク
ション・オフセット・リストとを有する。別の好ましい
実施形態では、様々なメッセージ・セクションの位置を
決定するために、他のフィールドまたはポインタを使用
可能である。

【００４３】前記のように、ＦＥＴＣＨコマンドは潜在
的に長いメッセージの特定部分へアクセスするために使
用できる。例えば、メッセージ内のヘッダーを除いた特
定のＭＩＭＥセクションのみを検索することをユーザー
は望み得る。また、ユーザーはメッセージの添付ファイ
ルのみを検索することを望み得る。ステップ９１０はク
ライアントがリクエストしたものが有効であるか否かを
スレッドが決定する検証ステップである。ＦＥＴＣＨコ
マンドが特定のＭＩＭＥ本体部分（即ち、セクション）
に対するものである場合、ステップ９０８で読み取った
インデックス・ファイル・セル内のセクション・オフセ
ット・リストをチェックすることによって、スレッドは
リクエストされたセクションが有効であるか否かを本実
施形態で決定する。セクション・オフセット・リストは
セクション、セクション番号及びセクションのオフセッ
トのリストを含む。別の好ましい実施形態では、この情
報は特定のフィールドまたはリスト内でグループ分けせ
ずにインデックス・データ内へ分散させ得る。スレッド
はリクエストされたセクション番号がリスト内に存在す
るか否かをチェックする。リクエストされたセクション
番号がリスト内に存在しない場合、エラー・メッセージ
がステップ９１２においてクライアントへ返される。リ
クエストされたセクションが有効である場合、インデッ
クス・ファイル・セル内で識別されたデータ・バケット
内のリクエストされたＭＩＭＥセクションのオフセット
及びサイズをスレッドは算出する。メッセージ格納構造
と称する同時係属出願に開示するように、セクション・
オフセット・リストは本体データの開始位置からのデー
タのオフセットを有する。ステップ９１４では、クライ
アントがＭＩＭＥヘッダーの検索を望まない場合、ヘッ
ダー・サイズと、ヘッダーの末端からセクションの開始
位置までのバイト数と、セクションのサイズと、必要な
ＭＩＭＥヘッダーのサイズとを使用して、スレッドはデ
ータ・バケット内のリクエストされたセクションのオフ
セット及びサイズを算出する。ステップ９１６では、ス
レッドは識別されたデータ・バケット内のセクションを
探索し、かつ読み取る。このステージにおいて、子プロ
セス及びスレッドはクライアントからのＦＥＴＣＨコマ
ンドの管理を完了している。

【００４４】コンピュータ・システム内に格納されたデ
ータを使用する様々なコンピュータ実行オペレーション
を本発明は用いる。これらのオペレーションは物理量の
物理操作を必要とするオペレーションを含む（但し、同
オペレーションに限定されない）。一般的に、必ずしも
必要でないが、これらの量は格納、転送、結合、比較及
び他の操作が可能な電気信号または磁気信号の形態をな
す。本発明の一部を構成する本明細書中に開示するオペ
レーションは、効果的なマシン・オペレーションであ
る。実施する操作は生成（producing)、識別（identify
ing）、実行（running）、決定（determining）、比較
（comparing）、実行（executing）、ダウンローディン
グ（downloading）または検出（detecting）等の用語で
示されることが多い。特に、共通の用法を確立するため
に、これらの電気信号または磁気信号をビット、値、エ
レメント、変数、特性またはデータ等として示すと都合
が良い。しかし、これらの用語またはこれらに類似する
用語の全ては適切な物理量に関連すべきであり、かつこ
れらの物理量に適用された都合の良いラベルにすぎない
点を覚えておく必要がある。

【００４５】更に、本発明は前記のオペレーションを実
施するためのデバイス、システムまたは装置に関する。
システムは要求された目的のために特別に構築可能であ
る。また、システムは汎用コンピュータとすることが可
能である。汎用コンピュータに格納されたコンピュータ
・プログラムによって、同汎用コンピュータは選択的に
作動または設定される。前記の複数のプロセスは特定の
コンピュータまたは他のコンピューティング装置に固有
のものではない。特に、本明細書の開示内容に基づいて
記述されたプログラムを様々な汎用コンピュータと併用
可能である。これに代えて、要求されたオペレーション
を実施するために、更に特別なコンピュータ・システム
を形成することは更に都合が良い。

【００４６】図１０は本発明の１つの実施形態に基づく
処理の実施に適した汎用コンピュータ・システム１００
０のブロック図である。図１０は汎用コンピュータ・シ
ステムの１つの例を示す。本発明の処理を実施するため
に、他のコンピュータ・システム・アーキテクチャ及び
構成を使用し得る。以下に詳述する様々なサブシステム
からなるコンピュータ・システム１０００は少なくとも
１つのマイクロプロセッサ・サブシステム（中央処理装
置、即ち、ＣＰＵとも称される）１００２を含む。即
ち、ＣＰＵ１００２はシングルチップ・プロセッサまた
は複数のプロセッサによって実現し得る。ＣＰＵ１００
２はコンピュータ・システム１０００のオペレーション
を制御する汎用デジタル・プロセッサである。メモリか
ら検索した命令を使用して、ＣＰＵ１００２は入力デー
タの受信及び操作と、出力デバイス上でのデータの出力
及び表示とを制御する。

【００４７】ＣＰＵ１００２は一般的にランダム・アク
セス・メモリ（ＲＡＭ）からなる第１の一次記憶装置１
００４へメモリ・バス１００８を通じて双方向接続され
ている。更に、ＣＰＵ１００２は一般的にリード・オン
リ・メモリ（ＲＯＭ）からなる第２の一次記憶装置１０
０６へメモリ・バス１００８を通じて単方向接続されて
いる。当該技術分野でよく知られているように、一次記
憶装置１００４は汎用記憶領域及び作業メモリとして使
用可能であり、さらには入力データ及び処理済みデータ
を格納するためにも使用できる。更に、ＣＰＵ１００２
上のオペレーションを処理するためのデータ及び命令を
格納する以外に、一次記憶装置１００４はメッセージ格
納構造の形態でプログラミング命令及びデータを格納可
能である。更に、データ及び命令をメモリ・バス１００
８を通じて双方向に高速転送するために、一次記憶装置
１００４は一般的に使用される。同様に、当該技術分野
でよく知れられているように、ＣＰＵ１００２がその機
能を果たすために使用する基本オペレーティング命令、
プログラム・コード、データ及びオブジェクトを一次記
憶装置１００６は一般的に含む。データ・アクセスが両
方向または単方向のいずれを必要とするかなどの条件に
基づいて、一次記憶装置１００４，１００６は以下に詳
述する任意の適切なコンピュータ読み取り可能記憶媒体
を含み得る。ＣＰＵ１００２は頻繁に必要となるデータ
をキャッシュ・メモリ１０１０内へ超高速で直接検索
し、かつ格納できる。

【００４８】取り外し可能大容量記憶装置１０１２はコ
ンピュータ・システム１０００のための別のデータ記憶
能力を提供し、かつペリフェラル・バス１０１４を通じ
てＣＰＵ１００２に対して双方向または単方向に接続さ
れている。例えば、ＣＤ−ＲＯＭとして一般的に知られ
ている特定の取り外し可能大容量記憶装置はＣＰＵ１０
０２に対してデータを単方向に送信する。その一方、フ
ロッピー・ディスクはＣＰＵ１００２に対してデータを
双方向に送信し得る。記憶装置１０１２は磁気テープ、
フラッシュ・メモリ、搬送波に組み込まれた信号、ＰＣ
カード、ポータブル大容量記憶装置、ホログラフィック
記憶装置及び他の記憶装置等のコンピュータ読み取り可
能媒体を更に含み得る。固定大容量記憶装置１０１６は
追加のデータ記憶能力を提供し、かつペリフェラル・バ
ス１０１４を通じてＣＰＵ１００２に対して双方向接続
されている。大容量記憶装置１０１６の最も一般的な例
としては、ハード・ディスク・ドライブが挙げられる。
一般的に、これらの媒体へのアクセスは一次記憶装置１
００４，１００６へのアクセスより遅い。ＣＰＵ１００
２が頻繁に使用しない他のプログラミング命令及びデー
タ等を大容量記憶装置１０１２，１０１６は一般的に格
納する。大容量記憶装置１０１２，１０１６内に保持さ
れた情報は、必要に応じて、一次記憶装置１００４
（例：ＲＡＭ）の一部を構成するバーチャル・メモリと
して標準的な方法で組込み可能である。

【００４９】記憶装置サブシステムへのＣＰＵ１００２
のアクセスを提供する以外に、ペリフェラル・バス１０
１４は他のサブシステム及びデバイスへのアクセスを提
供するために使用できる。本実施形態では、これらは、
ディスプレイ・モニタ１０１８及びアダプタ１０２０、
プリンタ・デバイス１０２２、ネットワーク・インター
フェース１０２４、補助入出力装置インターフェース１
０２６、サウンド・カード１０２８及びスピーカー１０
３０、並びに必要とされる他のサブシステムを含む。

【００５０】図示するように、ネットワーク接続を使用
することにより、ネットワーク・インターフェース１０
２４はＣＰＵ１００２を別のコンピュータ、コンピュー
タ・ネットワークまたはテレコミュニケーション・ネッ
トワークへ接続可能にする。前記の方法のステップを実
行するうえで、ＣＰＵ１００２はデータ・オブジェクト
またはプログラム命令などの情報を別のネットワークか
らネットワーク・インターフェース１０２４を通じて受
信するか、または情報をネットワーク・インターフェー
ス１０２４を通じて別のネットワークへ送信し得る。Ｃ
ＰＵで実行する複数の命令のシーケンスに代表される情
報は、搬送波に組み込まれたコンピュータ・データ信号
などの形態で別のネットワークに対して送受信可能であ
る。インターフェース・カードまたはこれに類似するデ
バイスと、ＣＰＵ１００２によって実行される適切なソ
フトウェアとは、コンピュータ・システム１０００を外
部ネットワークへ接続し、かつデータを標準プロトコル
に基づいて転送するために使用できる。即ち、本発明の
方法はＣＰＵ１００２上で単独で実行し得る。その一
方、処理の一部を共有する遠隔ＣＰＵと協動することに
より、本発明の方法をインターネット、イントラネット
ワーク若しくはローカル・エリア・ネットワーク等のネ
ットワークを通じて実行し得る。別の大容量記憶装置
（図示略）をネットワーク・インターフェース１０２４
を通じてＣＰＵ１００２へ接続し得る。

【００５１】マイクロホン、タッチ・ディスプレイ、ト
ランスデューサ・カード・リーダー、テープ・リーダ
ー、音声認識装置、手書き文字認識装置、バイオメトリ
クス・リーダー、カメラ、ポータブル大容量記憶装置及
び他のコンピュータ等の装置に対するＣＰＵ１００２に
よるデータの送受信を可能にする汎用インターフェース
及びカスタム・インターフェースを補助入出力装置イン
ターフェース１０２６は表す。

【００５２】キーボード１０３６またはポインタ・デバ
イス１０３８からの入力を受信し、さらにはデコードし
たシンボルをキーボード１０３６またはポインタ・デバ
イス１０３８からＣＰＵ１００２へ送信するために、キ
ーボード・コントローラ１０３２がローカル・バス１０
３４を通じてＣＰＵ１００２へ接続されている。ポイン
タ・デバイスはマウス、スタイラス、トラック・ボール
またはタブレットであり得る。そして、ポインタ・デバ
イスはグラフィカル・ユーザー・インターフェースとの
インターフェースに効果的である。

【００５３】更に、本発明の実施形態は様々なコンピュ
ータ実行オペレーションを実施するためのプログラム・
コードを含むコンピュータ読み取り可能媒体を有するコ
ンピュータ記憶装置に関する。コンピュータ読み取り可
能媒体は、コンピュータ・システムによる後からの読み
取りが可能なデータを格納し得る任意のデータ記憶装置
である。媒体及びプログラム・コードは本発明の目的の
ために特別に設計され、かつ構築されたものであるか、
またはコンピュータ・ソフトウェア技術分野の当業者に
よく知られたものであり得る。コンピュータ読み取り可
能媒体の例としては、ハード・ディスク、フロッピー・
ディスク及び磁気テープなどの磁気媒体と、ＣＤ−ＲＯ
Ｍディスクなどの光媒体と、光フロッピー・ディスクな
どの磁気光媒体と、特定用途向け集積回路（ＡＳＩ
Ｃ）、プログラム可能論理回路（ＰＬＤ）、ＲＯＭデバ
イス及びＲＡＭデバイスなどの特別に構成されたハード
ウェア・デバイスとを含めた前記の全ての媒体が挙げら
れる（但し、これらに限定されない）。コンピュータ読
み取り可能媒体は搬送波に組み込まれたデータ信号とし
て結合コンピュータ・システムのネットワーク上に分散
させ得る。従って、コンピュータ読み取り可能コードは
分散した形態で格納及び実行できる。プログラム・コー
ドの例としては、コンパイラなどによって形成されたマ
シン・コード、またはインタプリタを使用して実行でき
る高レベル・コードを含むファイルが挙げられる。

【００５４】前記のハードウェア・エレメント及びソフ
トウェア・エレメントが標準的なデザイン及び構成を有
することを当業者は認める。本発明に適した他のコンピ
ュータ・システムは別のサブシステムまたは更に少ない
数のサブシステムを含み得る。更に、メモリ・バス１０
０８、ペリフェラル・バス１０１４及びローカル・バス
１０３４は複数のサブシステムをリンクするために使用
する任意の相互接続方式の実例である。例えば、ローカ
ル・バスはＣＰＵを固定大容量記憶装置１０１６及びデ
ィスプレイ・アダプタ１０２０へ接続するために使用可
能である。図１０に示すコンピュータ・システムは本発
明に適したコンピュータ・システムの例である。サブシ
ステムの別のコンフィギュレーションを有する他のコン
ピュータ・アーキテクチャを使用し得る。

【００５５】以上、理解を容易にする目的で、本発明を
ある程度詳しく説明したが、特定の変更及び修正を本発
明の請求の範囲内で実施しても良い。例えば、サーバー
はＩＭＡＰまたはＰＯＰ以外のメール・プロトコルを取
り扱う構成としても良い。別の例では、選択した子プロ
セス内の接続スレッドは着信データを検出する責務を有
することが可能であり、さらには同着信データを監視す
るために入力ポーリング・スレッドを使わなくても良
い。更に別の例では、メッセージ・アクセス方法はＭＩ
ＭＥ規格以外の規格に基づいてフォーマットされたメッ
セージへアクセス可能である。更に、本発明のプロセス
及び装置の両方を実現する他の方法があることを認識す
る必要がある。従って、本実施形態は例示目的であっ
て、限定目的ではない。更に。本発明は本明細書に開示
する詳細部分に限定されることなく、請求の範囲及びそ
れに等価な範囲内で変更し得る。

【図面の簡単な説明】

【図１】本発明の一実施形態に基づくメッセージ・アク
セス・コンフィギュレーションの各種コンポーネント及
び方法を示すブロック図である。

【図２】本発明の一実施形態に基づくメッセージ・アク
セス方法の概要を示すフローチャートである。

【図３】図２のステップ２０６に示す接続責務を子プロ
セスへ渡すステップの詳細を示すフローチャートであ
る。

【図４】図２のステップ２０８に示すスレッドを初期化
するステップの詳細を示すフローチャートである。

【図５】図２のステップ２１０に示す選択した子プロセ
ス及びスレッドがクライアント・リクエストを管理する
ステップの詳細を示すフローチャートである。

【図６】アクティブ接続スレッドがクライアントから送
信された一般的なＣＯＰＹコマンドを管理する本発明の
一実施形態に基づく方法を示すフローチャートである。

【図７】図６のステップ６００に示す適切なインデック
ス・ディレクトリ・セル内のリファレンス・カウンタを
インクリメントするステップの詳細を示すフローチャー
トである。

【図８】図６のステップ６０６に示すメッセージを宛先
フォルダへコピーするステップの詳細を示すフローチャ
ートである。

【図９】メッセージ格納構造に含まれるメッセージ内の
データの特定の部分へアクセスする本発明の一実施形態
に基づく方法のフローチャートである。

【図１０】本発明の実施形態の実現に適した一般的なコ
ンピュータ・システムのブロック図である。

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

Claims (35)

【特許請求の範囲】
1. 【請求項１】 メッセージ格納構造内のメッセージへア
   クセスする方法であって、 接続リクエストをリクエスト・ルーティング・プロセス
   で受信する工程と、 前記接続リクエストに対応する接続を取り扱うために使
   用可能な接続スレッドをマルチスレッド・リクエスト・
   ハンドリング・プロセスが有するか否かを決定する工程
   と、 前記接続リクエストの転送責務を、選択したリクエスト
   ・ハンドリング・プロセスへ転送する工程と、 前記接続を管理するために、前記選択したリクエスト・
   ハンドリング・プロセス内の選択した接続スレッドを初
   期化する工程と、 前記メッセージ格納構造内の前記メッセージへのアクセ
   スを求めるクライアント・リクエストを前記選択した接
   続スレッドを使用して管理する工程と、 前記スレッド選択接続を終了する工程とを含む方法。
2. 【請求項２】 前記接続リクエストを受信する工程は、
   接続リクエスト待ち行列を読み取る工程を含む請求項１
   に記載の方法。
3. 【請求項３】 前記使用可能な接続スレッドをマルチス
   レッド・リクエスト・ハンドリング・プロセスが有する
   か否かを決定する工程は、前記選択した接続スレッド及
   び前記選択したリクエスト・ハンドリング・プロセスに
   関する情報を共有メモリ内へ格納する工程を含み、前記
   共有メモリは他のマルチスレッド・リクエスト・ハンド
   リング・プロセスによるアクセスが可能である請求項１
   または２に記載の方法。
4. 【請求項４】 前記使用可能な接続スレッドをマルチス
   レッド・リクエスト・ハンドリング・プロセスが有する
   か否かを決定する工程は、 前記リクエスト・ルーティング・プロセスに含まれるリ
   クエスト・ハンドリング・プロセスのリストをスキャン
   することによって、所定数量未満のアクティブ接続スレ
   ッドを有するリクエスト・ハンドリング・プロセスを探
   索する工程と、 実質的に全ての既存リクエスト・ハンドリング・プロセ
   スが所定数の接続スレッドを有する場合、新規リクエス
   ト・ハンドリング・プロセスを形成する工程とを含む請
   求項１乃至３のいずれか一項に記載の方法。
5. 【請求項５】 前記選択したリクエスト・ハンドリング
   ・プロセス内の選択した接続スレッドを初期化する工程
   は、 リクエスト・ハンドラ・プロセス識別子及び接続スレッ
   ド識別子を格納するために、前記選択した接続スレッド
   に対応するセルを共有メモリ内で割り当てる工程を含む
   請求項１乃至４のいずれか一項に記載の方法。
6. 【請求項６】 前記選択したリクエスト・ハンドリング
   ・プロセス内の選択した接続スレッドを初期化する工程
   は、 前記選択した接続スレッドを前記選択したリクエスト・
   ハンドリング・プロセス内の入力ポーリング・スレッド
   へ関連付けし、かつ前記接続スレッドを待ち状態にする
   工程を含む請求項１乃至５のいずれか一項に記載の方
   法。
7. 【請求項７】 前記クライアント・リクエストを管理す
   る工程は、 着信クライアント・リクエストを知らせる警告を前記選
   択したリクエスト・ハンドリング・プロセスへ行う工程
   と、 前記着信クライアント・リクエストを処理するために、
   同着信クライアント・リクエストを前記選択したリクエ
   スト・ハンドリング・プロセスに関連する接続スレッド
   へルーティングする工程とを含む請求項１乃至６のいず
   れか一項に記載の方法。
8. 【請求項８】 前記着信クライアント・リクエストを知
   らせる警告を前記選択したリクエスト・ハンドリング・
   プロセスへ行う工程は、前記選択したリクエスト・ハン
   ドリング・プロセスが前記着信クライアント・リクエス
   トを受信した際、検出のための入力ポーリング・スレッ
   ドを実行する工程を含む請求項７に記載の方法。
9. 【請求項９】 前記クライアント・リクエストを管理す
   る工程は、前記選択したリクエスト・ハンドリング・プ
   ロセス内のクリティカル信号スレッドを実行し、前記選
   択したリクエスト・ハンドリング・プロセス内のアクテ
   ィブ接続スレッドへのクリティカル信号を管理し、これ
   によって、前記アクティブ接続スレッドのみが終了し、
   前記選択したリクエスト・ハンドリング・プロセス内の
   他の接続スレッドを動作可能に残す工程を含む請求項１
   乃至８のいずれか一項に記載の方法。
10. 【請求項１０】 メッセージ格納構造内のメッセージを
    コピーする方法であって、前記メッセージ格納構造がイ
    ンデックス・ディレクトリ及びユーザー・フォルダを有
    し、前記メッセージが既存ユーザー・フォルダ・セルを
    有する方法において、 前記メッセージ格納構造のインデックス・ディレクトリ
    内のリファレンス・カウンタをインクリメントし、前記
    メッセージ格納構造内の別のユーザー・フォルダがメッ
    セージを参照していることを表示する工程と、 前記メッセージのコピーを格納する宛先ユーザー・フォ
    ルダへのアクセスを制限する工程と、 前記メッセージに関連する前記既存ユーザー・フォルダ
    ・セルの複製を前記宛先ユーザー・フォルダへ付加する
    工程であって、前記既存ユーザー・フォルダ・セルがコ
    ピーするメッセージ上の情報を含む工程と前記メッセー
    ジの内容は前記メッセージ格納構造内へ一度格納される
    ことを含む方法。
11. 【請求項１１】 前記インデックス・ディレクトリ内の
    リファレンス・カウンタをインクリメントする工程は、
    前記メッセージに対応するインデックス・ディレクトリ
    ・セルへのアクセスを制限する工程を含む請求項１０に
    記載の方法。
12. 【請求項１２】 前記宛先ユーザー・フォルダへのアク
    セスを制限する工程は、前記宛先ユーザー・フォルダに
    関連するロック・カウンタをインクリメントする工程を
    さらに含む請求項１０または１１に記載の方法。
13. 【請求項１３】 前記ユーザー・フォルダ・セルはメッ
    セージ上のデータを含み、かつメッセージの実際のデー
    タ内容を含まない請求項１０乃至１２のいずれか一項に
    記載の方法。
14. 【請求項１４】 メッセージの特定のセクションを検索
    する方法であって、前記メッセージがメッセージ格納構
    造内に含まれ、前記メッセージ格納構造がユーザー・フ
    ォルダ、インデックス・フォルダ及びデータ・バケット
    を有する方法において、 前記メッセージに関連するメール・フォルダ・セルを検
    査し、前記メッセージに関連した対応するインデックス
    ・フォルダ・セルの位置を獲得する工程と、 前記複数のデータ・バケットのうちの１つにおいて探索
    している前記メッセージの特定のセクションの位置を決
    定するために必要な情報を獲得すべく、前記対応するイ
    ンデックス・フォルダ・セルを検査する工程と、 前記データ・バケット内の前記メッセージの特定のセク
    ションを検索する工程と、 前記メッセージ格納構造内の前記データ・バケット内に
    格納されたメッセージの様々なセクションのサイズ及び
    開始位置を決定するために使用可能な情報を前記インデ
    ックス・フォルダ・セルが有することを含む方法。
15. 【請求項１５】 メール・フォルダ内の対応するメール
    ・フォルダ・セルを検査することによって、メッセージ
    をメッセージ格納構造へ書き込んだ日付を決定する工程
    を含む請求項１４に記載の方法。
16. 【請求項１６】 前記メール・フォルダ・セルを検査す
    る工程は、インデックス・ディレクトリ及びインデック
    ス・ファイルを有するインデックス・フォルダを開く工
    程を含む請求項１４または１５に記載の方法。
17. 【請求項１７】 前記対応するインデックス・フォルダ
    ・セルを検査する工程は、インデックス・ディレクトリ
    ・セルを検査する工程を含む請求項１４乃至１６のいず
    れか一項に記載の方法。
18. 【請求項１８】 前記メッセージに関連するインデック
    ス・ファイル・セルの位置を前記インデックス・ディレ
    クトリ・セルから獲得する工程をさらに含む請求項１７
    に記載の方法。
19. 【請求項１９】 インデックス・フォルダ・セル内の情
    報を検査することによって、前記メッセージの特定のセ
    クションが存在するか否かを確認する工程を含む請求項
    １４乃至１７のいずれか一項に記載の方法。
20. 【請求項２０】 メッセージ格納構造内のデータへアク
    セスするためのコンピュータ・システムであって、 複数のクライアントからのメッセージ格納構造接続リク
    エストを受理することに適したリクエスト・ルータと、 前記リクエスト・ルータに関連し、かつ接続スレッドの
    多重度を維持することにそれぞれ適した複数のマルチス
    レッド・リクエスト・ハンドラと、 前記リクエスト・ルータに関連し、かつリクエスト・ハ
    ンドラ識別器及び接続スレッド識別器を含む共有メモリ
    とを有し、前記共有メモリは前記複数のリクエスト・ハ
    ンドラによるアクセスが可能であり、これによって、１
    つの前記リクエスト・ハンドラはアクティビティ情報を
    他のリクエスト・ハンドラと共有し得るコンピュータ・
    システム。
21. 【請求項２１】 新規接続スレッドを維持するために使
    用可能なリクエスト・ハンドラの不在が確定した際、新
    規リクエスト・ハンドラを形成し得るリクエスト・ハン
    ドラ生成器を前記リクエスト・ルータはさらに有する請
    求項２０に記載のコンピュータ・システム。
22. 【請求項２２】 前記リクエスト・ルータへ接続された
    リクエスト待ち行列からのメッセージ格納構造接続リク
    エストを受理可能なリクエスト待ち行列スキャナをさら
    に有する請求項２０または２１に記載のコンピュータ・
    システム。
23. 【請求項２３】 メッセージ格納構造接続リクエストを
    受信した際、任意の既存リクエスト・ハンドラが接続リ
    クエストを受理可能であるか否かを前記リクエスト・ル
    ータは決定し、不可能な場合、同リクエスト・ルータは
    新規リクエスト・ハンドラを形成する請求項２０乃至２
    ２のいずれか一項に記載のコンピュータ・システム。
24. 【請求項２４】 前記各リクエスト・ハンドラは入力ポ
    ーリング・スレッドを有し、同入力ポーリング・スレッ
    ドは前記リクエスト・ハンドラ内のアクティブ接続スレ
    ッドへの入力イベントを検出する請求項２０または２１
    に記載のコンピュータ・システム。
25. 【請求項２５】 前記各リクエスト・ハンドラはクリテ
    ィカル信号スレッドを有し、同クリティカル信号スレッ
    ドはリクエスト・ハンドラ内の特定のアクティブ接続ス
    レッドへのクリティカル信号を検出し、前記クリティカ
    ル信号スレッドは前記特定のアクティブ接続スレッドの
    みを終了させ、これによって、リクエスト・ハンドラ内
    の他のアクティブ接続スレッドを機能した状態に維持す
    る請求項２０乃至２４のいずれか一項に記載のコンピュ
    ータ・システム。
26. 【請求項２６】 前記リクエスト・ルータによって割り
    当てられた前記共有メモリはリクエスト・ハンドラ識別
    器及び接続スレッド識別器を含む複数のスレッド固有デ
    ータ・セルをさらに有し、前記各スレッド固有データ・
    セルは接続スレッドに関連する請求項２０に記載のコン
    ピュータ・システム。
27. 【請求項２７】 メッセージ格納構造内のデータへアク
    セスするためのコンピュータ・システムであって、 複数のクライアントからのメッセージ格納構造接続リク
    エストを受理するための手段と、 接続スレッドの多重度を維持するための手段と、 １つ以上のリクエスト・ハンドラ識別器及び１つ以上の
    接続スレッド識別器を有する共有メモリとを有し、前記
    共有メモリは複数のリクエスト・ハンドラによるアクセ
    スが可能であり、これによって、前記複数のリクエスト
    ・ハンドラのうちの１つはアクティビティ情報を他のリ
    クエスト・ハンドラと共有し得るコンピュータ・システ
    ム。
28. 【請求項２８】 新規接続スレッドを維持するために使
    用可能なリクエスト・ハンドラの不在が確定した際、新
    規リクエスト・ハンドラを形成する手段を、前記メッセ
    ージ格納構造接続リクエストを受理するための手段はさ
    らに有する請求項２７に記載のコンピュータ・システ
    ム。
29. 【請求項２９】 前記メッセージ格納構造接続リクエス
    トを受理するための手段は、アクティブ接続スレッドへ
    の入力イベントを検出するための手段をさらに有する請
    求項２７または２８に記載のコンピュータ・システム。
30. 【請求項３０】 前記メッセージ格納構造接続リクエス
    トを受理するための各手段は、特定のアクティブ接続ス
    レッドへのクリティカル信号を検出する手段をさらに有
    し、前記クリティカル信号スレッドは前記特定のアクテ
    ィブ接続スレッドのみを終了させ、他のアクティブ接続
    スレッドを機能した状態に維持する請求項２７乃至２９
    のいずれか一項に記載のコンピュータ・システム。
31. 【請求項３１】 前記共有メモリはリクエスト・ハンド
    ラ識別器及び接続スレッド識別器を格納するための複数
    のスレッド固有データ・セルをさらに有し、前記各スレ
    ッド固有データ・セルは接続スレッドに関連する請求項
    ２７乃至３０のいずれか一項に記載のコンピュータ・シ
    ステム。
32. 【請求項３２】 メッセージ格納構造内のメッセージへ
    アクセスするためのプログラミング命令を含むコンピュ
    ータ読み取り可能媒体であって、このコンピュータ読み
    取り可能媒体はコンピュータ・プログラム・コード・デ
    バイスを有し、同コンピュータ・プログラム・コード・
    デバイスは、 接続リクエストをリクエスト・ルーティング・プロセス
    で受信する工程と、 前記接続リクエストに対応する接続を取り扱うために使
    用可能な接続スレッドをマルチスレッド・リクエスト・
    ハンドリング・プロセスが有するか否かを決定し、前記
    接続リクエストの転送責務を、選択したリクエスト・ハ
    ンドリング・プロセスへ転送する工程と、 前記接続を管理するために、前記選択したリクエスト・
    ハンドリング・プロセス内の選択した接続スレッドを初
    期化する工程と、 前記メッセージ格納構造内のメッセージへのアクセスを
    求めるクライアント・リクエストを管理する工程であっ
    て、前記選択した接続スレッドが前記クライアント・リ
    クエストを管理する責務を有する工程と、 終了リクエストを受信した際、または所定の条件が満た
    された際、前記スレッドを終了する工程とをコンピュー
    タに実行させるべく構成されているコンピュータ読み取
    り可能媒体。
33. 【請求項３３】 前記使用可能な接続スレッドをマルチ
    スレッド・リクエスト・ハンドリング・プロセスが有す
    るか否かをコンピュータに決定させるべく構成された前
    記コンピュータ・プログラム・コード・デバイスは、 前記リクエスト・ルーティング・プロセスに含まれるリ
    クエスト・ハンドリング・プロセスのリストをスキャン
    することによって、所定数量未満のアクティブ接続スレ
    ッドを有するリクエスト・ハンドリング・プロセスが存
    在するか否かを決定する工程と、 全ての既存リクエスト・ハンドリング・プロセスが所定
    数の接続スレッドを有する場合、新規リクエスト・ハン
    ドリング・プロセスを形成する工程とをコンピュータに
    実行させるべく構成されたコンピュータ・プログラム・
    コード・デバイスを含む請求項３２に記載のコンピュー
    タ読み取り可能媒体。
34. 【請求項３４】 インデックス・ディレクトリ及びユー
    ザー・フォルダを有するメッセージ格納構造内において
    既存ユーザー・フォルダ・セルを有するメッセージをコ
    ピーするためのプログラミング命令を含むコンピュータ
    読み取り可能媒体であって、このコンピュータ読み取り
    可能媒体はコンピュータ・プログラム・コード・デバイ
    スを有し、同コンピュータ・プログラム・コード・デバ
    イスは、 前記メッセージ格納構造のインデックス・ディレクトリ
    内のリファレンス・カウンタをインクリメントし、前記
    メッセージ格納構造内の別のユーザー・フォルダがメッ
    セージを参照していることを表示する工程と、 前記メッセージのコピーを格納する宛先ユーザー・フォ
    ルダへのアクセスを制限する工程と、 前記メッセージに関連する前記既存ユーザー・フォルダ
    ・セルの複製を前記宛先ユーザー・フォルダへ付加する
    工程であって、前記既存ユーザー・フォルダ・セルがコ
    ピーするメッセージ上の情報を含む工程とをコンピュー
    タに実行させるべく構成され、前記メッセージの内容は
    前記メッセージ格納構造内へ一度格納されるコンピュー
    タ読み取り可能媒体。
35. 【請求項３５】 ユーザー・フォルダ、インデックス・
    フォルダ及びデータ・バケットを有するメッセージ格納
    構造内に含まれているメッセージの特定のセクションを
    検索するためのプログラミング命令を含むコンピュータ
    読み取り可能媒体であって、前記コンピュータ読み取り
    可能媒体はコンピュータ・プログラム・コード・デバイ
    スを有し、同コンピュータ・プログラム・コード・デバ
    イスは、 前記メッセージに関連するメール・フォルダ・セルを検
    査し、前記メッセージに関連した対応するインデックス
    ・フォルダ・セルの位置を獲得する工程と、 前記複数のデータ・バケットのうちの１つにおいて探索
    している前記メッセージの特定のセクションの位置を決
    定するために必要な情報を獲得すべく、前記対応するイ
    ンデックス・フォルダ・セルを検査する工程と、 前記データ・バケット内の前記メッセージの特定のセク
    ションを検索する工程とをコンピュータに実行させるべ
    く構成され、前記メッセージ格納構造内のデータ・バケ
    ット内に格納されたメッセージの様々なセクションのサ
    イズ及び開始位置を決定するために使用可能な情報を前
    記インデックス・フォルダ・セルが有するコンピュータ
    読み取り可能媒体。