JP4456877B2 - 電子メールメッセージの最適なメッセージボディの提供方法 - Google Patents

Description

本発明は、一般的にはコンピュータネットワークに関し、より詳細には、電子メールアプリケーションのようなクライアントのアプリケーションとサーバのアプリケーションとの間の通信方法に関する。

電子メールは、通信のための重要な手段となっている。電子メールシステムは典型的には、サーバの構成要素（たとえばＭｉｃｒｏｓｏｆｔ（登録商標） Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ）とクライアントの構成要素（たとえばＭｉｃｒｏｓｏｆｔ（登録商標） ＯｕｔｌｏｏｋまたはＭｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ）を含む。これらの構成要素は、典型的にはソフトウェアアプリケーションプログラムであり、計算装置（たとえばサーバ、ＰＣ、ラップトップパソコン、ＰＤＡ（Personal Digital Assistance））の上で実行するように構成される。

電子メールシステムのクライアントの構成要素とサーバの構成要素のようなクライアントとサーバは、通信を容易にするため、多くの場合は通信プロトコルを決めている。このプロトコルは、通信中の各パーティに期待される動作、たとえば要求と応答の期待される順序、を定義する規則を定める。複雑なプロトコルは予期しない動作を処理する規則を有する。

クライアントとサーバの構成要素が改良されると、改良されたバージョンがエンドユーザに分配される。新しい構成要素の機能およびネットワーク機能を利用するため、新しい通信プロトコルが発明されることも多い。サーバの構成要素の設置台数が相当数に上る場合には、クライアントの構成要素は、プロトコルのセットを用いて、サーバの構成要素の選択された以前のバージョンと通信する能力を有するかもしれない。

新しいプロトコルが、全体を置き換えるのではなく、以前のバージョンのプロトコルに基礎を置く場合も時々発生する。このような場合には、新しいプロトコルは、以前のバージョンのプロトコルを装うために、機能を有効または無効にできるプロトコル要素により構成されるかもしれない。同様に、クライアントの構成要素の設置台数が相当数に上る場合には、サーバの構成要素は、プロトコルを用いて、クライアントの構成要素の選択された以前のバージョンと通信する能力を有するかもしれない。

本発明は、このようなシステムと方法を提供する。追加的な発明の特徴とともに、本発明のこれらおよびその他の利点は、本明細書に提供される本発明の説明により明確になるであろう。

本発明は、改良されたクライアントおよびサーバの通信のためのシステムと方法を提供する。より詳細には、本発明は、クライアントとサーバとの間の通信に用いられることができる改良されたプロトコルに関する。本発明は、電子メールサーバの環境に対して特に関連を有するが、本明細書に述べられる特徴は他のクライアント−サーバネットワークにおいても使用することができる。

本発明の一態様によれば、電子メールクライアントの構成要素は、電子メールサーバの構成要素に対し、電子メールメッセージについて利用可能な最適なメッセージのボディを受信することに関心があることを指示することができる。電子メールサーバの構成要素は、メッセージの要求を受信することができ、その要求はメールの最適なメッセージのボディが望まれていることを示す指示を有することができる。電子メールサーバの構成要素は、電子メールサーバの構成要素と関連付けられたデータストアにアクセスし、利用可能なメッセージのボディのフォーマットの変換と無関係に利用可能なそのメッセージの最適なメッセージのボディを決定し、最適なメッセージのボディのフォーマットを変換すること無く、最適なメッセージボディを取り出して返すことができる。このように、電子メールサーバの構成要素では電子メールボディの変換を行わないため、電子メールサーバの構成要素での処理時間が削減される。

本発明の別の態様では、電子メールサーバの構成要素は、特定のプロパティまたはプロパティのセット（たとえばメールヘッダ）の転送の要求があった場合に、プロパティまたはプロパティのセットがデータオブジェクト内に適切に定義されていないときは、データオブジェクト全体を転送することができる。電子メールクライアントの構成要素は、フォルダ内のデータオブジェクトの要求を生成することができ、この要求は、データオブジェクトの少なくとも一つのプロパティを望むことの指示を含む。電子メールサーバの構成要素は要求を受信し、フォルダとフォルダ内のデータオブジェクトにアクセスする。フォルダ内の各データオブジェクトについて、そのデータオブジェクト内で少なくとも一つのプロパティが適切に定義されている場合は、電子メールサーバの構成要素は、そのデータオブジェクトについて少なくとも一つのプロパティを電子メールクライアントの構成要素へ読み出し返送する。そのデータオブジェクトにつき、少なくとも一つのプロパティも適切に定義されていない場合には、電子メールサーバの構成要素は、電子メールクライアントの構成要素へのデータオブジェクトを取り出して返す。

本発明の更に別の態様では、電子メールクライアントの構成要素は、電子メールサーバの構成要素に強制して電子メールメッセージをＵｎｉｃｏｄｅで供給させることができる。電子メールクライアントの構成要素は、少なくとも一つの電子メールメッセージに対する要求、およびその電子メールクライアントの構成要素が、電子メールメッセージがＵｎｉｃｏｄｅフォーマットであることを望む旨の指示を送信する。電子メールサーバの構成要素は、その要求と指示の受信に応答し、少なくとも一つのメッセージを読み出し、各電子メールメッセージについて、電子メールメッセージがＵｎｉｃｏｄｅフォーマットで利用可能な場合は、Ｕｎｉｃｏｄｅフォーマットを電子メールクライアントの構成要素に供給する。電子メールメッセージがＵｎｉｃｏｄｅフォーマットで利用可能でない場合は、電子メールサーバの構成要素は、その電子メールメッセージをＵｎｉｃｏｄｅフォーマットに変換し、Ｕｎｉｃｏｄｅフォーマットを電子メールクライアントの構成要素に提供する。

本発明の更に別の態様では、電子メールクライアントの構成要素により送信された要求は、その要求に対する応答のサイズについての制限を指示せずに、必要あれば電子メールサーバの構成要素がバッファを満たすことを可能とする。電子メールクライアントの構成要素は、要求の中で複数の小要求を送信し、各小要求は、電子メールサーバの構成要素における操作を要求し、サイズ情報を指示する。各小要求に応じて、サイズ情報が電子メールサーバの構成要素によって予期された範囲中のサイズ限界を含む場合には、電子メールサーバの構成要素は、応答をそのサイズ限界で制限する。サイズ情報が電子メールサーバの構成要素によって予期された範囲外のサイズ限界を含む場合には、電子メールサーバの構成要素は、サイズ情報の以内で新しいサイズ限界を探す。新しいサイズ限界は、「利用可能なバッファを満たせ」というような任意の表現とすることができる。

本発明の種々の実施例の説明に進む前に、本発明の種々の実施形態を実施することができるコンピュータおよびネットワークの環境の説明を行う。必須ではないが、本発明は、コンピュータで実行されるプログラムにより実施することができる。一般に、プログラムはルーチン、オブジェクト、コンポーネント、データ構造その他を含み、特定のタスクを実行し、または特定の抽象データ型を実装する。ここで用いられる用語「プログラム」は、単一のプログラムモジュールまたは協働する複数のプログラムモジュールを包含する。ここで用いられる用語「コンピュータ」は、一つまたは複数のプログラムを電子的に実行する、パーソナルコンピュータ（ＰＣ）、携帯型装置、マルチプロセッサシステム、マイクロプロセッサ搭載のプログラム可能な電子製品、ネットワークＰＣ、ミニコンピュータ、タブレットＰＣ、メインフレームコンピュータ、マイクロプロセッサやマイクロコントローラを持つ電化製品、ルータ、ゲートウェイ、ハブ、その他の任意の装置を含む。本発明を分散処理環境においても採用することができ、タスクは通信ネットワークを介してリンクされたリモート処理装置によって処理される。分散処理環境においては、プログラムはローカルとリモートの両方の記憶装置に配置される場合がある。

本発明を用いることができるネットワーク化された環境の一例を、図１を参照して説明する。例示的ネットワークは雲状に表現されたネットワーク１１を介して互いに通信するいくつかのコンピュータ１０を含む。ネットワーク１１はルータ、ゲートウェイ、ハブ等の多数の良く知られた構成要素を含み、コンピュータ１０は有線および／または無線媒体を介して通信することを可能とする。ネットワーク１１上で互いに影響し合うとき、一つまたは複数のコンピュータは、クライアント、サーバまたは他のコンピュータに関するピアとして動作することができる。したがって、本明細書に含まれる特定の例は、これらすべてのコンピュータの類型を参照しないが、本発明の種々の実施形態は、クライアント、サーバ、ピアまたはそれらの組合せで実施することができる。

図２を参照すると、ここで説明される本発明のすべてまたは部分を実施することができるコンピュータの基本構成の一例が示されている。その最も基本的な構成において、コンピュータ１０は典型的には、少なくとも一つの処理ユニット１４とメモリ１６を含む。処理ユニット１４は、本発明の種々の実施形態にしたがってタスクを実行するため命令を実行する。これらのタスクを実行する際に、処理ユニット１４は、電子信号をコンピュータ１０およびコンピュータ１０の外部の装置に伝送し、ある結果を生じさせる。コンピュータ１０の厳密な構成および類型によって、メモリ１６は、揮発性（たとえばＲＡＭ（Random Access Memory））、不揮発性（たとえばＲＯＭ（Read Only Memory）またはフラッシュメモリ）または両者のある組合せとなる。この最も基本的な構成は、図２では線で囲まれた１８に示される。また加えて、コンピュータは追加的特徴／機能を有することがある。コンピュータ１０は、たとえば、限定するものではないが、磁気または光ディスク若しくはテープを含む付加的な記憶装置（取り外し可能な記憶装置２０１や取り外し不可能な記憶装置２０２の）を含むことがある。コンピュータの記憶媒体は、揮発性または不揮発性、取り外し可能または取り外し不可能な媒体を含み、コンピュータで実行可能な命令、データ構造、プログラムモジュールまたその他のデータを含む情報の蓄積のための任意の方法または技術により実現されている。コンピュータの記憶媒体は、限定するものではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）、フラッシュメモリ、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（digital versatile disk）またはその他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置もしくは任意の他の媒体を含み、所望の情報を格納し、コンピュータ１０によりアクセスすることができる。これらのコンピュータの記憶装置媒体のいずれをもコンピュータ１０の記憶装置の一部とすることができる。

また、コンピュータ１０は、好ましくは他の装置との通信を可能とする通信接続装置２０５を含む。通信接続装置は通信媒体の一例である。通信媒体は、典型的にはコンピュータ読み取り可能な命令、データ構造、プログラムモジュールまたその他のデータを搬送波または他の伝送機構のような変調データの信号中に具現化し、任意の情報伝達媒体を含む。限定するものでないが例として、用語「通信媒体」は、有線ネットワークや直接配線接続のような有線媒体と、音響、ＲＦ（Radio Frequency）、赤外線および他の無線媒体のような無線媒体を含む。ここで用いられる用語「コンピュータ読み取り可能な記録媒体」はコンピュータの記憶媒体と通信媒体の両方を含む。

またコンピュータ１０は、キーボード、マウス、ペン、音声入力装置、タッチ式入力装置などのような入力装置２０４を含む。また表示装置２０、スピーカ、プリンタなどのような出力装置２０３も含まれる。これらの装置のすべては本技術分野でよく知られており、ここで詳細に説明するまでもない。

本発明は、改良されたクライアントおよびサーバの通信のためのシステムと方法に関し、より詳細には、クライアントとサーバとの間の通信に用いられることができる改良されたプロトコルに関する。本発明は、電子メールサーバの環境に特別な関連を有するが、ここに述べられる特徴は他のクライアント−サーバのネットワークにおいても使用することができる。しかしながら、説明を容易にするために、本発明はクライアント−サーバの電子メールの環境を参照して説明される。

本発明は、クライアントのアプリケーションまたは構成要素が複数のバージョン、および／またはサーバのアプリケーションまたは構成要素が複数のバージョンであるクライアント−サーバの環境で実施することができる。この目的のため、図３は、ネットワークの電子メール環境においてクライアントとサーバの構成要素の両方が多様なバージョンである場合を示す図である。一般には、クライアントとサーバの構成要素は、以前のバージョンと互換性を有するように構成される。すなわち、クライアントの構成要素は、サーバの構成要素の新しいバージョンおよび前のバージョンと通信することができ、逆もまた同様である。プロトコルのセットは、各々が自己完結型である幾つかの異なるプロトコルを構成することができる。あるいはまた、プロトコルの構成要素のセットが利用可能であり、特定の構成要素をそのプロトコルのセット内で特定のプロトコルを構成するために用いることができる。

とにかく、図３に示すネットワークの電子メールの環境において、最新のバージョンの電子メールクライアントの構成要素３０３は、プロトコル３０７を用いて最新のバージョンの電子メールサーバの構成要素３０６と最も良く通信できる。しかしながら、最新のバージョンの電子メールサーバの構成要素３０６は、プロトコルのセット内の他のプロトコル（たとえば図３のプロトコル３０８や３０９）を用いて選択された以前のバージョンの電子メールクライアントの構成要素、たとえば電子メールクライアントの構成要素３０２や電子メールクライアントの構成要素３０１とも、通信することができる。電子メールクライアントの構成要素３０３はまた、選択された以前のバージョンの電子メールサーバの構成要素と、プロトコル３１０や３１１のようなプロトコルを用いて、電子メールサーバの構成要素３０５や電子メールサーバの構成要素３０４と、通信することができる。

ここで用いられるように、一般的に、本発明のプロトコルを説明する目的のため、「最新の」電子メール（サーバまたはクライアント）の構成要素、または電子メール（サーバまたはクライアント）の構成要素の最新のバージョンは、説明される新しい機能または機能群を認識し、利用し、実行し、および／またはそれら機能に基づいて動作することができるサーバまたはクライアントの構成要素である。これらの用語は本明細書中で、本発明のプロトコルの種々の態様を認識するクライアントとサーバの構成要素を説明するために用いられるが、説明される特定の態様のみを、あるいは説明される態様の一つ以上を認識する構成要素を含む。同様に、「以前の」電子メールの構成要素、または電子メールの構成要素の以前のバージョンは、本発明のプロトコルの態様を認識せず、それに基づいて動作することができない構成要素である。

プロトコルのネゴシエーション手順（procedure）を、クライアントとサーバ（たとえば、最新のバージョンの電子メールサーバの構成要素３０６および最新のバージョンの電子メールクライアントの構成要素３０３）との間のプロトコルを確立するためにしばしば用いる。このようなプロトコルのネゴシエーション手順は公知ではあるが、電子メールクライアントの構成要素４０１（図４）と電子メールサーバの構成要素４０２（同じく図４）との間のプロトコルのネゴシエーション手順の簡単な説明を、読む者の便のために提供する。電子メールクライアントの構成要素４０１と電子メールサーバの構成要素４０２との間の通信のセッションのはじめに、電子メールクライアントの構成要素４０１は、電子メールサーバの構成要素４０２へ、たとえばクライアントの構成要素バージョンスタンプの形態で、クライアントのバージョン情報を含むメッセージ４０３を送信する。電子メールサーバの構成要素４０２は、たとえばサーバの構成要素バージョンスタンプの形態で、サーバのバージョン情報を含むメッセージ４０４によりメッセージ４０３に対して応答する。

クライアントとサーバのバージョン情報を、電子メールクライアントの構成要素４０１と電子メールサーバの構成要素４０２との間の通信の確立を試みるために多様な方法で用いることができる。例えば、バージョン情報を使用して、通信を継続するための適したプロトコルを選択し、あるいはさらに通信が可能か否かを決定することができる。プロトコルを確立する際に、バージョン情報を使用して、例えば、特定の利用可能なプロトコルの態様または構成要素を動作可能または動作不可能にすることができる。

電子メールサーバの構成要素は、多数の電子メールクライアントの構成要素からの要求を並行して受信し処理することができる。単一のクライアントが示される場合には、明示的に記述が他にない限り、単に図と付随する説明を簡略にするためである。

本発明の電子メールネットワークはネットワークにおけるクライアントおよびサーバの構成要素間でクエリおよびデータを渡すにため、要求と応答の交換を利用する。実際には、プロトコルの性能は、電子メールネットワークにおけるクライアントとサーバとの間の通信を実現するために用いた潜在する通信ネットワークの伝送機構により影響される。たとえば、潜在する通信ネットワークの伝達機構として遠隔手続き読み出し（ＲＰＣ）を用いる電子メールネットワークにおいて、よりサイズの大きな（たとえば３２ＫＢの）単一のＲＰＣを使用する方が、より小さなサイズ（たとえば２ＫＢ）のいくつかのＲＰＣを使用するよりも、はるかに効率的かもしれない。このような電子メールネットワークにおける性能を改善するための既知の方法の１つは、複数の要求や応答をバッファして、単一のＲＰＣとして送信することである。

一例として図５は、電子メールクライアントの構成要素５０１と電子メールサーバの構成要素５０２との間の要求と応答のやり取りを示す。電子メールクライアントの構成要素５０１と電子メールサーバの構成要素５０２は、各々決まったサイズの通信バッファ５０３、５０４、５０５および５０６を有する。バッファ５０３、５０４、５０５および５０６は、一次的にデータを保持するためにメモリ上に確保された領域である。電子メールクライアントの構成要素５０１は、バッファ５０３の内容をバッファ５０４へ転送する前に、バッファ５０３に一つまたは複数の小要求（sub request）あるいは遠隔操作（ＲＯＰｓ：remote operations）で満たすことで、リクエスト−応答のサイクルを開始する。

バッファ５０４に受信された後、各ＲＯＰは電子メールサーバの構成要素５０２によって順番に処理され、対応する結果がバッファ５０５に書き込まれる。各ＲＯＰは何らかの結果を生み出す。その結果は、電子メールクライアントの構成要素５０１により要求されたデータ、たとえば特定の電子メールメッセージのセットを含むことができる。電子メールサーバの構成要素５０２はバッファ５０５を監視し、ほぼ一杯（たとえば残り８ＫＢ以下）になると、電子メールサーバの構成要素５０２は未処理のＲＯＰのいずれをもバッファ５０５の末尾に書き込み、そしてバッファ５０５の内容をバッファ５０６へ送信する。電子メールクライアントの構成要素５０１は、次いで、バッファ５０３が再び一杯になったときに電子メールサーバの構成要素５０２に再依頼するために未処理のＲＯＰをバッファ５０３に書き込み、新たな要求―応答サイクルを開始する。

典型的には応答のサイズは平均では要求のサイズより大きい。このため、応答用のバッファ５０５および５０６のサイズは典型的には要求用のバッファ５０３および５０４のサイズより大きく構成される。本発明の一実施形態では、応答用のバッファ５０５および５０６の最適サイズは９６ＫＢとなるように決められ、要求用のバッファ５０３および５０４の３２ＫＢのサイズに対して３対１の比率である。一実施形態では、電子メールクライアントの構成要素が５０３、５０４、５０５および５０６の任意のバッファのサイズを設定することができる。

例えば図５に示す電子メールネットワークでは、バッファを用いる一部の電子メールネットワークは、電子メールクライアントの構成要素と電子メールサーバの構成要素との間で高速転送モードを使用する。高速転送モードは、ＲＯＰのように、クライアントによる要求を含み、結果としてサーバでの高速転送のデータソースの初期化を伴う要求と、結果として高速転送のデータソースからクライアントへのデータの効率的転送をもたらす要求との２種類に分類される。高速転送のデータソースは、たとえばデータベース表である。高速転送のデータソースは、すぐに使える一次的なデータストアとして働き、後のデータの要求が他の方法に比較してより少ない遅延で提供されることを可能にする。時として、第２の種類の高速転送モードの要求を用いて、明示的に応答のサイズを特定することによりデータの効率的転送を実現しようとする、たとえば応答のサイズをクライアント受信バッファ全体のサイズに設定し、応答のオーバーヘッドを少なくする。

図６Ａは少なくとも二つの要求―応答のサイクルを有する高速転送操作を示す。第１の要求６０１において、ＲＯＰ（たとえばFXPrepare）はサーバ５０２の高速転送のデータソースを初期化する。サーバにおいては、FXPrepareのみが処理され（すなわち高速転送のデータソースが初期化され）、その結果が第１の応答６０２で返信される。第２の要求６０３において、ＲＯＰ（たとえばFXGetBuffer）は、サーバが高速転送のデータソースからバッファ５０５に書き込むことを要求する。サーバは高速転送のデータソースをバッファへ移し、結果を第２の応答６０４で返信する。電子メールサーバの構成要素の出力バッファ５０５が、高速転送のデータソースが空になる前に一杯になると、追加のFXGetBufferのＲＯＰが要求されることがある。

図６Ｂは単一の要求―応答サイクルのみを有する高速転送操作を示す。第１の要求６０５において、FXPrepareとFXGetBufferの両方が電子メールサーバの構成要素５０２によって処理され、両操作の結果が第１の応答６０６で返信される。電子メールサーバの構成要素５０２において、FXPrepareの結果はFXGetBufferが利用できる。なぜならば、各バッファ５０３、５０４、５０５および５０６の共有データテーブルとして明示的に定義されているからである。より効率的なデータ転送をもたらすことから、要求―応答のサイクルの数を減らすことが望まれる。２サイクル以上の要求―応答サイクルを有する高速転送操作は、バッファ５０５が一杯でFXGetBufferの結果を保持できない場合に発生するであろう。

図６Ａおよび６Ｂならびに本明細書中の同様な図におけるＲＯＰは、特に言及しない限り、ＲＯＰの連続によって実際に実施される場合の概略であると理解されたい。

典型的には、ＲＯＰの結果のサイズはＲＯＰの要求のサイズとは異なる。ＲＯＰの結果のサイズを予測することは常に可能なわけではない。ＲＯＰの結果のサイズを削減するためにデータ圧縮技術が用いられると、ＲＯＰの結果のサイズを予測することはさらに難しい。ＲＯＰの結果のサイズを予測することができないということは、たとえば全新規メッセージを単一の要求―応答サイクルでクライアントにダウンロードしようとするような、特定のクライアントの操作を完了するために要求される要求―応答サイクルの数を最小にするための、プロトコルのマニュアルによる調整を防ぐことができる。プロトコルのマニュアルによる調整は、プロトコルの要求、応答および／またはＲＯＰの順序やサイズのマニュアルでの設定が含まれる。

本発明の一つの態様にしたがえば、キーとなるＲＯＰ（たとえばFXGetBuffer）がその結果のサイズを予測するための要求に囚われないと指定することで、要求―応答サイクルの数は自動的に最小化される。その代わりに、そのようなＲＯＰは、電子メールサーバの構成要素５０２により、バッファ５０５（バッファ５０６も同様）の限界に到達するまで処理される。

一例として、複数のバージョンの電子メールサーバの構成要素を含む環境においては、以前のバージョンのサーバの構成要素と新しいバージョンのサーバの構成要素とに対し、別個のＲＯＰが定義されることがある。新しいバージョンはその結果のサイズを予測するための要求に囚われない。これらのＲＯＰの特徴は次の表に明らかにされる。

以前のバージョンのサーバの構成要素のためのＲＯＰは、その構成において既存の従来技術のＲＯＰと同様である。すなわち、ＲＯＰは、出力バッファ（たとえば送信バッファ５０５）において、応答を保持するために確保されねばならないサイズを予測し要求する。一方、サーバの構成要素の最新バージョンの出力バッファに対して要求されるサイズは、予測されず、代わりに以前のバージョンのサーバの構成要素により予期された最大を超える値、たとえば３２ＫＢより大きな値に設定される。出力バッファのサイズがサーバの構成要素によって予期された値を超えて定義されるという事実は、サーバの構成要素が新しいサイズ制限のパラメータを探すようにする合図となり、新しいサイズが、たとえばサーバの構成要素の出力バッファの書き込みとなる場合がある。これらの特徴により、ＲＯＰを処理する電子メールサーバの構成要素の複雑性を僅かに増加するのみで、要求―応答サイクルの数は自動的に最小化される。

上記表および本明細書中の同様な表に示されるパラメータの順序は、特に相反する明示的記述を伴わない限り、たとえば、ネットワークを介して送信され、もしくは電子メールクライアントの構成要素または電子メールサーバの構成要素のいずれのメモリに格納されるパラメータの順序とは必ずしも関連しないことに注意すべきである。さらに、分かり易くするため、変更のないパラメータは省略しているものがある。

電子メールネットワークにおいて、プロトコルの一つの典型的な役割は、電子メールクライアントの構成要素と電子メールサーバの構成要素との間で、データオブジェクト、たとえば電子メールメッセージの転送を実現することである。このようなデータオブジェクトの更なる例は、電子メールメッセージおよび他のデータオブジェクトを含む電子メールフォルダ、および、たとえば電子メールを処理するための規則を含み、またはフォルダに含まれるデータオブジェクトを如何に表示するかを定義する、フォルダ関連情報(ＦＡＩ) データオブジェクトを含む。データオブジェクトは電子メールクライアントの構成要素にとっては捉えにくい可能性がある。すなわち電子メールクライアントの構成要素はデータオブジェクトの内容を解釈する何の手段も持たないことがある。一方、データオブジェクトは名前付けされたプロパティから構成される場合があり、たとえば電子メールメッセージは「to」、「from」、「subject」、「importance」、「body1」、「body2」、「body3」、「attachment1」、「attachment2」などの名前付けされたプロパティを含む。

データオブジェクトが不明瞭な電子メールネットワークと比べて、データオブジェクトが名前付けされたプロパティから構成される電子メールネットワークの一つの利点は、データオブジェクトの一部のみを転送するというプロトコルの能力ゆえに、プロトコル性能を改善できる可能性があるということである。名前付けされたプロパティを有することは、データオブジェクト全体を送信することなく、データオブジェクトの特定のプロパティのみを送信することを可能にする。

たとえば、電子メールメッセージはヘッダプロパティのセットとボディプロパティのセットにより構成される場合がある。電子メールクライアントの構成要素の希望が、ヘッダプロパティを先に転送し、その後にボディプロパティを転送するかまたはまったく転送しないというようなものとすることができる。この機能は、すべてのメッセージの全体をダウンロードされる前に、ユーザがいくつかのメッセージのヘッダ情報を見ることを可能にする。この機能を用いることにより、帯域幅利用についてのよりきめ細かな制御をクライアントの構成要素によって実現することができ、このことにより確実にプロトコル性能が改善されるであろう。加えて、クライアントの構成要素は、この機能を用いることにより（たとえばボディは選択されたヘッダについてのみダウンロードされるようにできる）結果として帯域幅の使用を減らすことができ、これは狭帯域幅の環境において特に望ましい。

サーバの構成要素がボディとヘッダのプロパティを二つの個別の要求―応答サイクル（すなわち、ヘッダとボディの各々に一つずつ）で送信するように設定していると、プロトコルの性能は必ずしも向上しない。たとえば、電子メールクライアントの構成要素の希望がヘッダとボディ両方のプロパティを同時に要求するようなものである場合には、単一の要求―応答サイクルがヘッダとボディの両方を読み出せる状況に対して、プロトコルの性能は低下する可能性がある。このように、単にデータオブジェクトが名前付けされたプロパティから構成されるようにするだけで、改善されたプロトコルの性能に自動的に結びつくわけではない。改善されたプロトコル性能の達成は、データオブジェクトを構成するプロパティの選択と、それらがプロトコルにより如何に用いられるかに依存する。その選択は、最新のバージョンと以前のバージョンの電子メールクライアントの構成要素の要件および最新のバージョンと以前のバージョンの電子メールサーバの構成要素の要件を含む要因の数に依存する場合がある。電子メールクライアントの構成要素の要件の例は、異なる情報を表示する際の異なる緊急性のレベルを満足させること、また電子メールクライアントの構成要素のユーザによってセットされた趣向が含まれる。電子メールサーバの構成要素の要件の例は、データの効率的な格納と読み出し、およびプロトコルの要求の効率的な処理が含まれる。

通常の従来技術による電子メール環境は、名前付けされたプロパティで構成されることができるデータオブジェクト、たとえば名前付けされたプロパティからなるヘッダのセットおよびボディのセットを含むことができる電子メールメッセージを用い、二つのセットがそれぞれ個別に要求されおよび／または処理されることができる。別の従来技術による例は、名前付けされたプロパティよりなるボディのセットが、たとえばプレーンテキスト、ＨＴＭＬ（hypertext mark-up language）、ＲＴＦ（rich text format）などのような複数の電子メールメッセージフォーマットの複数のバージョンの電子メールメッセージのボディを含むような電子メールメッセージの場合である。この状況では、従来技術による電子メールサーバの構成要素は、電子メールメッセージのボディに対するプロトコルの要求に対して多くの方法で応答することができる。最も複雑性の低い応答方法は、その電子メールメッセージのボディのすべてのバージョンを送信することであろうが、この方法は結果として帯域幅の利用を増加させる。

図７Ａは、この状況で以前の(従来技術の)バージョンの電子メールサーバの構成要素が応答するために使用する手順の一部を示す。ステップ７０１で電子メールサーバの構成要素は各電子メールメッセージのボディのフォーマットを調査する。フォーマットの一つが予め定められた標準のフォーマット(たとえばＲＴＦ)であれば、手順はステップ７０３に移動し、標準フォーマットの電子メールメッセージのボディを要求している電子メールクライアントの構成要素に送信する。いずれのフォーマットも予め定められた標準のフォーマットでなかった場合は、ステップ７０１はステップ７０２へ分岐し、電子メールメッセージのボディバージョンのひとつが標準フォーマットに変換される。図７Ａにより示される部分処理手順（subprocedure）は、単一のバージョンのみの電子メールメッセージのボディしかなく、電子メールメッセージのボディがプロトコルにより要求されている標準フォーマットではない場合にも用いることができる。

図７Ｂは、本発明の態様にしたがって、最新のバージョンの電子メールサーバの構成要素によって用いられる手順の一部を示す。ステップ７０４で、プロトコルは、電子メールサーバの構成要素により用いられるこの部分処理手順によってBEST_BODYフラグの調査を要求する。この例のフラグおよび本明細書中で用いられる他のフラグは、電子メールサーバの構成要素に向けられ、電子メールクライアントの構成要素が最新のバージョンでありフラグと関連付けられた機能が実行されることを要求していることを示す。他の指示を用いることもできる。たとえば、この機能は、最新のバージョンの電子メールクライアントの構成要素が検出された場合にデフォルトで実行されるようにしてもよい。

いずれにせよ、BEST_BODYフラグが見付からなければ、次にステップ７０４はステップ７０１に分岐し、図7Ａを参照して説明したように処理される。

フラグが見付かれば、手続きは、ステップ７０５に移動し、最適な電子メールメッセージのボディが、要求している電子メールクライアントの構成要素に送信されるために選択される。要求された電子メールメッセージと関連付けられた電子メールメッセージのボディが一つしかない場合は、それが最適なものである。いくつかの電子メールメッセージのボディが利用できる場合、例えば異なるフォーマットで、電子メールサーバの構成要素は、たとえば予め定められた電子メールメッセージのボディフォーマット（たとえば、ＲＴＦ、ＨＴＭＬ、プレーンテキスト）の優先順位にしたがい、それらの中から最適なものを選択する。次いで、処理はステップ７０３に移動し、選択された電子メールメッセージのボディが電子メールクライアントの構成要素へ送信される。この実施例において、電子メールクライアントの構成要素は複数の電子メールメッセージのボディフォーマットを表示することができ、したがって電子メールサーバの構成要素が電子メールメッセージのボディを標準フォーマットに変換する要求から開放される。さらに、電子メールクライアントの構成要素は、希望ならば、最適な電子メールメッセージのボディを異なるフォーマットに変換することもできる。

電子メールサーバの構成要素が電子メールメッセージのボディを変換するタスクを離れているため、本発明は性能の改善をもたらしたことになる。さらに、最新のバージョンの電子メールサーバの構成要素は、中程度の複雑性の増加のみで、以前のバージョンの電子メールクライアントの構成要素からのプロトコルの要求に応答することができる。

ＲＯＰを用いて電子メールサーバの構成要素と電子メールクライアントの構成要素との間で電子メールフォルダの複製（replication）を得ることができる。フォルダを同期する要求は、たとえば、SynchFolderＲＯＰにより行われることができる。電子メールクライアントの構成要素が標準外の電子メールメッセージのボディフォーマットを表示することができる場合は、SynchFolderＲＯＰの中でBEST_BODYフラグをセットし、電子メールサーバの構成要素に電子メールメッセージのボディを標準フォーマットで返送するよう要求するのでなく、電子メールサーバの構成要素が最適なフォーマットを使用可能な電子メールメッセージのボディの中から選択するよう指示する。電子メールサーバの構成要素は、中程度の複雑性の増加のみで、BEST_BODYフラグを伴うＲＯＰおよびBEST_BODYフラグを伴わないＲＯＰの両方を適切に処理することができるようになる。以前のバージョンおよび最新のバージョンのサーバと通信するためのＲＯＰは、たとえば、次の表に列挙される特徴を含む。

図８Ａ−８Ｃは、電子メールサーバの構成要素と電子メールクライアントの構成要素との間で電子メールメッセージのセットを転送する既存のいくつかの異なるモードを示す。各モードについて、各電子メールメッセージはヘッダのセットおよびボディのセットを含む名前付けされたプロパティを有し、いくつかの電子メールメッセージはフォルダに格納されている。図８Ａは全アイテム転送モードを示す。図では、まず第１の電子メールメッセージのヘッダ８０１が送信され、次に第２の電子メールメッセージのヘッダ８０３の前に第１の電子メールメッセージのボディ８０２、次いで、第２の電子メールメッセージのボディ８０４など、電子メールメッセージのセットが転送されるまでを示す。図８Ｂはヘッダ先送り転送モードを示す。このモードでは、第１の電子メールメッセージのヘッダ８０５が転送され、次いで、第２の電子メールメッセージのヘッダ８０６など、すべての電子メールメッセージのヘッダが転送され、その後にはじめて第１の電子メールメッセージのボディ８０７が転送され、次いで第２の電子メールメッセージのボディ８０８など、電子メールメッセージのセットが転送されるまでを示す。図８Ｃは、ヘッダのみ転送モードを示す。名称が示唆するように、電子メールメッセージのヘッダ８０９のみが電子メールメッセージのセットの転送要求に対する応答として転送される。電子メールメッセージのボディ８１０は、さらに明示的な要求があればそれに対する応答としてのみ転送される。これらのモードの何れにおいても、転送の順序は、より高い優先順位の電子メールクライアントの構成要素の要求、たとえば特定の電子メールメッセージのボディの要求によって、一時的に割り込まれるようにできる。

電子メールフォルダは、電子メールメッセージのセットの転送要求のターゲットの一例である。しかしながら、電子メールフォルダは、電子メールメッセージのほかにデータオブジェクトを含む場合がある。上記したように、転送モードは、ヘッダ先送りやヘッダみの転送モードのように、電子メールメッセージのヘッダおよび電子メールメッセージのボディを参照して定義されることが多い。このような転送モードでは、名前付けされたプロパティよりなるヘッダのセットや名前付けされたプロパティよりなるボディのセットが適切に定義されていないデータオブジェクトを転送しようと試みると、結果としてプロトコル障害をもたらす場合が多い。本発明の一態様は、名前付けされたプロパティよりなるヘッダおよびボディのセットが適切に定義されていないデータオブジェクトを、部分でなく常に全体を転送されるよう規定することにより、このような状態を回避する。この実施形態は図８Ｄで例示される。この例では、電子メールサーバの構成要素と電子メールクライアントの構成要素との間の転送はヘッダのみ転送モードで行われている。したがって、第１の電子メールメッセージのヘッダ８１１が転送され、それからデータオブジェクト８１２が次の転送の候補になる。名前付けされたプロパティよりなるヘッダのセットが、データオブジェクト８１２について、ＦＡＩのように適切に定義されていない場合には、データオブジェク全体が転送される。次の転送の候補が適切に定義された名前付けされたプロパティよりなるヘッダのセットを有する（すなわち、候補となるデータオブジェクが所有する名前付けされたプロパティのすべてが、名前付けされたプロパティよりなるヘッダのセットに属していると、電子メールクライアントの構成要素によって明示的に定義されている）場合は、電子メールメッセージのヘッダ８１３のみが転送される。

本発明の態様を実施する一つの方法の例は、IGNORE_MODE_ON_FAIのように、上記したSynchFolderＲＯＰのような同期ＲＯＰに含まれるであろう、フラグを使用することである。電子メールサーバの構成要素は、中程度の複雑性の増加のみにより、IGNORE_MODE_ON_FAIフラグを伴う、およびIGNORE_MODE_ON_FAIフラグを伴わない両方のＲＯＰを適切に処理することができる。ＲＯＰは、電子メールサーバの構成要素と電子メールクライアントの構成要素との間で電子メールフォルダの複製を得るために、次の表に明らかにされる特徴を含む。

電子メールメッセージは、典型的には１または複数の電子メールネットワークユーザに向けられる。電子メールメッセージは、それが電子メールサーバの構成要素によって格納のために受け付けられた場合に、配達されたと見なされることがある。電子メールネットワークはいくつかの電子メールサーバの構成要素を有することがある。典型的には電子メールネットのワークプロトコルは、電子メールネットワークユーザが新規メッセージについて調べなければならない電子メールサーバの構成要素の数を制限するための、ある仕組みを有する。よくある例はホームサーバの仕組みであり、そこでは特定の電子メールネットワークユーザに向けられた電子メールメッセージは、そのユーザのホームサーバと呼ばれる一つの特定の電子メールサーバの構成要素によってのみ受け付けられるよう規定される。このような場合、電子メールクライアントの構成要素は、たとえば新規電子メールメッセージの有無のチェックまたは新規電子メールメッセージ通知の登録の際に、そのホームサーバのみを考慮するように設定される。

図９は、単純なホームサーバの仕組み例であっても、複雑な関係を有するであろうことを示す。図９に示す例では、最初に特定の電子メールサーバの構成要素９０１が特定の電子メールネットワークユーザのためのホームサーバとして指定される。時間の経過につれ、そのユーザに対して指定されるホームサーバは、典型的には管理上の理由により、異なる電子メールサーバの構成要素９０３、そして９０５へ遷移する。電子メールサーバの構成要素９０１、９０３、９０５は、たとえば、物理的に異なりまたは論理的に異なり、もしくはバージョンが異なるかもしれない。電子メールクライアントの構成要素９０２は、時刻Ｔ_０から時刻Ｔ_１までの間に電子メールサーバの構成要素９０１とのみ通信し、次いで、電子メールクライアントの構成要素９０４は、時刻Ｔ_２まで、電子メールサーバの構成要素９０３とのみ通信し、そして次に電子メールクライアントの構成要素９０６は、電子メールサーバの構成要素９０５とのみ通信することになる。電子メールクライアントの構成要素９０２、９０４、９０６は同一でも別でもよい。電子メールサーバの構成要素９０１と９０３は時間Ｔ_２の以降に存続してもしなくてもよい。これらの複雑な関係は次に説明される電子メールメッセージのストアの複製に特に密接に関連する。

電子メールメッセージは、電子メールサーバの構成要素により明示的な電子メールメッセージストアに格納され、たとえば公知のデータベース技術を用いて実行されることができる。電子メールサーバの構成要素は一つまたは複数のこのようなメッセージストアを有することができる。電子メールネットワークユーザは、ホームメッセージストアを有することができる。ホームメッセージストアを変更することは、ホームサーバを変更することについて説明したのと同様の効果を持つであろう。

いくつかの電子メールネットワークプロトコルは、電子メールメッセージストアの一部を電子メールクライアントの構成要素のローカルの記憶装置に複製する能力を含む。リモートの電子メールメッセージストアの一部をローカルの電子メール記憶装置に複製することは、たとえば電子メールネットワークユーザがそれらの閲覧を明示的に要求する前に、すべての新規電子メールメッセージをローカルの電子メール記憶設備に複製することで、プロトコル性能および／または体感のプロトコル性能が改善する。またこのような複製は、追加的な電子メールクライアントの構成要素の機能を提供することにもなり、たとえば、電子メールクライアントの構成要素の電子メールネットワークユーザが、ネットワークの接続が中断されている間に、電子メールメッセージを閲覧することを可能にする。

電子メールネットワーク環境においては、単純な複製はすぐに非効率になるであろう。たとえば、電子メールサーバの構成要素が、特定の電子メールネットワークユーザと関連付けされた一つの電子メールメッセージを有し、そのメッセージがそのネットワークユーザについてのクライアントの構成要素で既に複製されており、かつその電子メールネットワークユーザへの新規電子メールメッセージが到着すると、そのときには、単純な複製要求に対する応答として、二つの電子メールメッセージを送信しなければならない必要があることになる。この二つの電子メールメッセージの複製の後にもう一つの新規電子メールメッセージが到着すると、そのときには、単純な複製要求に対する応答として、今度は三つの電子メールメッセージを送信しなければならない必要があることになり、それが続くことになる。一部の電子メールネットワークプロトコルは、この問題を軽減するために電子メールメッセージストアの増加分の複製を提供している。増加分を複製では、電子メールメッセージストアに対する、前回の正常な増加分の複製の後に発生した変更のみが、複製要求に対する応答として必ず送信されることになる。たとえば、最後の正常な増加分複製以後の変更が、一つの新規電子メールメッセージの到着のみであれば、複製要求に対する応答としてその新規電子メールメッセージのみが必ず送信されることになる。

図１０は、増加分を複製する機能を備えるプロトコルのより詳細な一例を示す。電子メールメッセージストアは、いくつかの電子メールフォルダに小分けにされているかもしれない。各電子メールフォルダは他とは独立に複製され、複製処理においてよりきめの細かい制御を提供することができる。この例では、増加分複製処理は同期と称せられる。なぜなら、電子メールクライアントの構成要素５０１から電子メールサーバの構成要素５０２への、そして電子メールサーバの構成要素５０２から電子メールクライアントの構成要素５０１への変更の伝達を含むからである。同期要求信号１００１に続き、SynchFolderＲＯＰが電子メールサーバの構成要素５０２によって処理される。ＲＯＰはfolderIDパラメータ（表示せず）およびstateblob_０パラメータを含む。folderIDパラメータは、同期要求１００１のターゲットである電子メールフォルダを識別する。stateblob_０パラメータは、電子メールサーバの構成要素５０２が、あるとすれば、最後に同期されてからどの変更が電子メールフォルダに発生したかを判断することができるようにする情報を含む。要求１００１が、ターゲットのフォルダに対する電子メールクライアントの構成要素５０１による最初の同期要求を表している場合は、電子メールサーバの構成要素５０２は、電子メールメッセージストアにおけるターゲットの電子メールフォルダを空のフォルダと比較して変化しているかを判定する。要求１００１に対する応答１００２において、電子メールサーバの構成要素５０２は、電子メールクライアントの構成要素５０１に対して、そのターゲットのフォルダに追加された任意の電子メールメッセージおよび／または他のデータオブジェクト、およびそのターゲットのフォルダから削除された任意の電子メールメッセージおよび／または他のデータオブジェクトの一覧を含む任意の変更を送信する。また電子メールサーバの構成要素５０２は、電子メールクライアントの構成要素５０１におけるターゲットのフォルダの同期直後の状態を表す新規のstateblob_１を生成し、そのstateblob_１を応答１００２において送信する。電子メールクライアントの構成要素５０１が要求１００１と同一のフォルダに対する次の同期要求１００３を送信する場合には、要求１００３は、応答１００２とともに返信された同一のstateblob_１をパラメータとして含むであろう。前述同様に、電子メールサーバの構成要素５０２はstateblob_１に含まれる情報を用いて、あるとすれば、どの変更が目標のフォルダに発生したかを判断し、それらの変更を新規に生成されたstateblob_２とともに応答１００４により電子メールクライアントの構成要素５０１へ返信する。

stateblobデータオブジェクトのサイズが大きいと、たとえば、各々の電子メールフォルダ同期要求とともに、電子メールサーバの構成要素との間で送受信されるため、プロトコル性能に不利に働く。電子メールフォルダの同期を提供する一部の電子メールネットワークプロトコルでは、大部分において、stateblobは、電子メールクライアントの構成要素によって閲覧された電子メールメッセージについての変更を識別するメッセージ変更ＩＤデータオブジェクトのセットより構成される。変更された電子メールメッセージがその構成要素に転送されたときに、その電子メールメッセージの変更は、電子メールクライアントの構成要素および／または電子メールサーバの構成要素により閲覧されたとされることができる。

メッセージ変更ＩＤデータオブジェクトの一つの目的は、電子メールネットワーク全体の環境において電子メールメッセージについての変更を一意に識別することである。ホームサーバ方式を適用する電子メールネットワークにおいては、ユーザのホームサーバは、メッセージ変更ＩＤデータオブジェクトを以前に閲覧されていない電子メールメッセージの変更と結びつける責任がある場合がある。たとえば、ホームサーバは、サーバＩＤデータオブジェクトおよび通し番号を備えるメッセージ変更ＩＤデータオブジェクトを利用することができる。サーバＩＤデータオブジェクトは、全世界で一意に決まる識別子（ＧＵＩＤ）のような公知の技術を用いて、電子メールネットワーク全体の環境において電子メールサーバの構成要素を一意に識別することができる。このように識別子がそれ自体大きいサイズである場合には、サーバＩＤデータオブジェクトを、代わりに電子メールサーバの構成要素によって維持されている識別子参照テーブルの見出しとすることができる。通し番号は、たとえば、電子メールサーバの構成要素内で６バイトカウンターにより提供され、電子メールサーバの構成要素がまだ閲覧されていない電子メールメッセージを格納のために受け付けるたびに増加されるだろう。

説明の目的で、メッセージ変更ＩＤデータオブジェクトは、たとえば、“Ｓ_１：１”のように表現する。ここで、‘Ｓ_１’は第１の電子メールサーバの構成要素のサーバＩＤデータオブジェクトを表し、‘１’は通し番号を表す。メッセージ変更ＩＤデータオブジェクトのセットは、たとえば、“Ｓ_１：１、Ｓ_１：２、Ｓ_１：３”のように表され、ここで“Ｓ_１：１”、“Ｓ_１：２”および“Ｓ_１：３”は、サーバＩＤがＳ_１である電子メールサーバの構成要素によって採用される連続するメッセージ変更ＩＤデータオブジェクトである。

stateblobの大部分が、電子メールクライアントの構成要素により閲覧された電子メールメッセージの変更を表すメッセージ変更ＩＤデータオブジェクト（“Message Changes Seen”セット）より構成される場合には、そのセットを、たとえば、“Ｓ_１：１、Ｓ_１：２、Ｓ_１：３、Ｓ_１：４”のセットを“Ｓ_１：１−４”のように符号化しサイズを削減するある技術が開発されている。さらに、電子メールサーバの構成要素は、自身の通し番号が常に増加していくことを確認できる。連続しないMessage Changes Seenセット、たとえば“Ｓ_１：１、Ｓ_１：３、Ｓ_１：５、Ｓ_１：７”、が“Ｓ_１：１−７”のように符号化された場合でも範囲として最小と最大の通し番号を含んでいれば、機能を損なうことはない。

図９に示された例では、Message Changes Seenセットは、現在のホームサーバ（たとえば、Ｓ_３）でなく電子メールサーバの構成要素（たとえば、Ｓ_１、Ｓ_２）により生成されたメッセージ変更ＩＤデータオブジェクトを含む場合がある。現在のホームサーバにより生成されたメッセージ変更ＩＤデータオブジェクトを固有の（native）メッセージ変更ＩＤと称し、他のホームサーバにより生成されたメッセージ変更ＩＤデータオブジェクトを外来の（foreign）メッセージ変更ＩＤと称すこととする。以前のバージョンの電子メールサーバの構成要素と通信するための電子メールネットワークのプロトコルは、連続しない外来のメッセージ変更ＩＤシーケンスを、最小と最大の通し番号を含む幅として最適化する機能を備えていない。次の表は本発明の実施形態においてこのような最適化を含む利点を示すものである。

本発明の一実施形態では、次の表に明らかにされる特徴を含むＲＯＰを用いて、電子メールサーバの構成要素と電子メールクライアントの構成要素との間の電子メールフォルダの同期を得る。電子メールサーバの構成要素は、改良されたstateblob符号化技術を中程度の複雑性の増加のみにより実装することができる。

図１１Ａと図１１Ｂは、SynchFolderＲＯＰに応答するために、以前のバージョンのサーバと最新のバージョンのサーバによって、それぞれに使用される部分処理手順の差異を示す。図１１Ａは、ステップ１１０１、１１０２および１１０３を示す。ステップ１１０１で、最初のMessage Changes Seenセットが構成される。ステップ１１０２で、そのMessage Changes Seenセットの要素（固有のメッセージ変更ＩＤデータオブジェクト）が最適化される。ステップ１１０３で最適化されたMessage Changes Seenセットがstateblobデータオブジェクトに追加され、同期を要求した電子メールクライアントの構成要素への応答とともに送信されることができる。図１１Ｂは追加のステップ１１０４を含み、ステップ１１０３で、Message Changes Seenセットが、今度は改良された最適化を伴って、stateblobデータオブジェクトに追加される前に、Message Changes Seenセットの要素である外来のメッセージ変更ＩＤデータオブジェクトもまた最適化されることを示す。

電子メールメッセージストアを電子メールフォルダに小分けにすることは、同期処理上のよりきめの細かい制御をもたらす一方で、それによりプロトコル性能の改善が自動的にできるわけではなく、プロトコル性能の低下をもたらす場合もある。たとえば、一部のプロトコルは、各メッセージストアのフォルダが個別に同期されることを要求する。典型的に、各同期操作はいくらかのオーバーヘッドを有し、そのオーバーヘッドはかなりの量になる場合がある。stateblobデータオブジェクトを利用する同期操作は、かなりの量のオーバーヘッドを有する操作の一例である。メッセージストアの全体を同期する場合、各メッセージストアのフォルダを個別に同期することを要求するプロトコルは、同期操作をほとんど要求しないプロトコルと比較して不利になるであろう。

メッセージストアの全体を同期することおよび同期を維持することは、電子メールクライアントの構成要素にとって望ましい目標である。通常の従来技術による電子メールクライアントの構成要素は、この目標を実現する方法を求めているが、時としてプロトコル性能に逆の影響を及ぼすことさえある。本発明の一態様は、深い階層テーブルを利用することによりこの目標を達成しつつ、プロトコルへの逆の影響を最小にすることができることである。通常の従来技術による電子メールサーバの構成要素は、深い階層テーブルを提供することができていなかった。

電子メールメッセージストアを電子メールフォルダに小分けされている場合、それらの電子メールフォルダを階層に編成することができる。図１２は電子メールフォルダの階層の一例を示す。図１２では、フォルダ１２０４がフォルダ１２０３のサブフォルダとなる。順に、フォルダ１２０３がフォルダ１２０２のサブフォルダとなる。フォルダ１２０１はルートフォルダである。ルートフォルダは他のどのフォルダのサブフォルダでもない。他のすべてのフォルダは、フォルダ１２０１をルートとするフォルダ階層の要素である。典型的に、フォルダ階層の各フォルダは、他のすべてのフォルダに直接の関連を有するわけではない。フォルダはそのサブフォルダにのみ直接の関連を有し、またフォルダは自身がサブフォルダとなっているフォルダのいずれにも直接の関連を有する。多くの場合には、すべてのフォルダが直接の関連を有する唯一のフォルダは、その階層のルートフォルダである。

深い階層テーブルは、フォルダ階層のすべてのフォルダについての情報を含むことができる。各フォルダは深い階層テーブルの中に一つの列を有する。深い階層テーブル内の情報は、それを用いて、特定の時間間隔の間に電子メールフォルダの内容が更新したかどうかを判定するために使用されるようなものである。特定の時間間隔における電子メールフォルダの内容の更新を判定することは、その時間間隔の始めに取ったフォルダの列の写しと、その時間間隔の終りに取ったそのフォルダの行の写しとの単純比較を使用することで実現できる。一実施形態においては、深い階層テーブルの各行は次の属性を有する。

深い階層テーブルにおける電子メールフォルダの列の属性は、フォルダの内容に変更がなされる度に更新されることができる。深い階層テーブルの更新を効率良く実現するためには、深い階層テーブルの迅速かつ直接な参照が役立つことを見出した。深い階層テーブルにアクセスしようとする場合には、最低限、小さくてそして予測可能な間接参照レベルの数があることを見出した。たとえば、深い階層テーブルをフォルダ階層にける任意のレベルに位置決めすることは、予測可能な間接参照レベルの数を実現することにはならない。本発明の一実施形態においては、この理由から深い階層テーブルは、電子メールネットワークユーザの電子メールメッセージストアのフォルダ階層のルートフォルダと関連付けられている。

電子メールクライアントの構成要素と電子メールサーバの構成要素との間の通信を、通信セッションに分割することができる。電子メールメッセージストアの同期の消失は、セッションの合間、たとえばネットワーク接続の中断の間に発生する。通信セッションの開始時おいて電子メールメッセージストアの同期を再確立するため、以前のバージョンの電子メールサーバの構成要素と通信するための一部のプロトコルは、フォルダ階層内の各フォルダに対するSynchFolderＲＯＰを採用した。典型的には、いくつかのフォルダの内容はセッションの合間で変更されていない。変更されていないフォルダをそのターゲットとしたSynchFolderＲＯＰは、“同期不要”の結果となる。“同期不要”は、電子メールクライアントの構成要素に対し何れのフォルダの変更も転送されない結果となるが、それでも、たとえばstateblobデータオブジェクト関連するかなりの量のオーバーヘッドを有する場合がある。

図１３は、深い階層テーブルを利用することで、この“同期不要”の結果を回避する本発明の実施形態を示す。第１の要求１３０１において、電子メールクライアントの構成要素５０１は、深い階層テーブルを要求するＲＯＰ（たとえばGetHierarchyTable）を電子メールサーバの構成要素５０２に送信する。第１の応答１３０２において、深い階層テーブルの複製が電子メールクライアントの構成要素５０１に供給される。典型的には、電子メールクライアントの構成要素５０１は、深い階層テーブルについての以前の複製を有する。電子メールクライアントの構成要素５０１は、二つの複製の列と列の比較を用いることによって電子メールサーバの構成要素５０２のユーザの電子メールメッセージストア内のどのフォルダが変更されているかを迅速に決定することができる。次に、ＲＯＰ（たとえばSynchFolder）を、変更されたフォルダのみを同期するために用いる。要求１３０３および応答１３０４は、変更されたフォルダを同期するために必要なだけ繰返されるだろう。同期が成功すると、電子メールクライアントの構成要素の深い階層テーブルの複製が応答１３０２で送信された最新の複製に合致するように更新されるであろう。電子メールクライアントの構成要素５０１が深い階層テーブルの以前の複製を有さない場合は、最新の複製内に列を有するすべてのフォルダが同期されるだろう。

一旦、ユーザの電子メールメッセージストアの同期が確立されると、同期は、周期的に上記したセッションのスタートのステップを繰返すことで（すなわち電子メールサーバの構成要素をポーリングして）維持されるが、この方法には欠点がある。たとえばポーリング間隔がユーザの電子メールメッセージストアの変更間隔より非常に短い場合がある。このような場合、深い階層テーブルの比較のうちの比較的多くが、フォルダが変化していないと示すことになるであろう。このような比較は、実際には、無駄な努力であり、このような無駄を回避できるプロトコルがより効率的であることになる。

一部の電子メールネットワークは、電子メールクライアントの構成要素が登録して、たとえば、特定の電子メールフォルダの内容が変化したとき、電子メールサーバの構成要素によって通知される機能を含む。一部の以前のバージョンの電子メールクライアントの構成要素は、そのような機能を使用し、ユーザの電子メールメッセージストアの同期を維持するため、ユーザのフォルダ階層内の各フォルダと関連付けられた変更通知のために別個の登録を行うようなにしている。本発明の実施形態においては、電子メールクライアントの構成要素は、深い階層テーブルと関連付けられた変更通知のための単一の登録のみを行う。単一の登録はより効果的である。なぜなら、確立するため要求されるＲＯＰがより少なく、サーバ側で使われるリソースがより少ないからである。

さらに図１３を参照して、最新のバージョンの電子メールクライアントの構成要素５０１は、本発明の態様によれば、電子メールサーバの構成要素５０２との通信セッションの開始時に第１の要求１３０１でGetHierarchyTableＲＯＰを用い、電子メールクライアントの構成要素５０１は、応答１３０２で返信される深い階層テーブルと関連付けられた変更通知に自動的に加えられる（subscribed）。電子メールクライアントの構成要素でユーザの電子メールメッセージストア中の電子メールフォルダに変更が生ずると、たとえば、電子メールメッセージがフォルダに追加され、また深い階層テーブルが上記したように更新される。深い階層テーブルが変更されると電子メールクライアントの構成要素５０１への通知アラート１３０５が起動される。通知アラートは、要求１３０１によりなされたサブスクリプションに対する応答中にあって、明示的な要求-応答サイクルを構成するものではない。したがって、本発明により提供されるような通知システムの使用は、電子メールネットワークのオーバーヘッドを大幅に減らす結果となる。

単一の登録は多数の通知をもたらすことができる。一実施形態では、アラートは、コネクションレスネットワークのトランスポート機構、たとえば、ＵＤＰ／ＩＰ（User Datagram Ptotocol/Internet Protocol）を使用して配信されるが、任意の適したネットワークのトランスポート機構を用いることができる。アラートに応答して、電子メールクライアントの構成要素５０１は、電子メールサーバの構成要素５０２に対して、ＲＯＰ（たとえばGetNotification）を含む要求１３０６を送信する。応答１３０７で、深い階層テーブル何れの変更された列(すなわち、通知のトリガとなった変更されたフォルダに相当する列)は、電子メールクライアントの構成要素５０１へ送信される。電子メールクライアントの構成要素５０１は、ＲＯＰ（たとえばSynchFolder）を用いて、変更されたフォルダのみを同期する。

複数の電子メールクライアントの構成要素５０１が、同一のデータオブジェクト（たとえば、同一の電子メールフォルダ）と関連付けられた変更通知に加えられることができ、たとえば、協業機能を提供することができる。図１８に示されるように、電子メールクライアントの構成要素１８０１、１８０２および１８０３は、電子メールサーバの構成要素１８０４に配置された同一のデータオブジェクト（図示しない）と関連付けられた変更通知に加えられている。電子メールクライアントの構成要素１８０３は、ＲＯＰ１８０５を電子メールサーバの構成要素１８０４に送信し、これがデータオブジェクトに変更をきたす。変更の結果として、電子メールサーバの構成要素１８０４は、変更通知１８０６、１８０７および１８０８を電子メールクライアントの構成要素１８０１、１８０２および１８０３に送信する。変更通知は、変更されたデータオブジェクトを識別する以上の情報はほとんど運ばないため、たとえば電子メールクライアントの構成要素が特定の変更の原因を判定する方法がない場合がある。たとえばデータオブジェクトが電子メールフォルダであれば、変更通知１８０６、１８０７および１８０８によって、電子メールクライアントの構成要素１８０１、１８０２および１８０３の各々が変更されたフォルダの同期を開始するであろう。この例では、電子メールクライアントの構成要素１８０３は、この変更の原因であるため、結果は“同期不要”となる。

前述した理由により、“同期不要”となる同期は除くことが望ましい。しかしながら、説明した通知の振る舞いは常に望ましくないわけではなく、一部の電子メールクライアントの構成要素はこれに依存している場合がある。本発明の態様は、プロトコル性能を改善するために、電子メールクライアントの構成要素が最新のバージョンの電子メールサーバの構成要素の通知の振る舞いを設定することができる能力を提供し、同時に以前のバージョンの電子メールクライアントの構成要素に従来通りの通知の振る舞いを提供する。

図１９Ａは、以前のバージョンの電子メールクサーバの構成要素により提供されることができる通知の振る舞いを示す。図１９Ｂは、本発明の態様にしたがって、設定可能な通知の振る舞いを示す。望むならば、最新のバージョンの電子メールクライアントの構成要素は、たとえば要求とともにフラグ、図１９Ｂの例ではIGNORE_OWNフラグを供給することによって、電子メールサーバの構成要素に図１９Ｂ示す通知の振る舞いができることを示すことができる。

ステップ１９０１で、通知されるサブスクライバのセットの中から次に候補が選択される。ステップ１９０４で、サブスクライバにIGNORE_OWNフラグが有るかを調査する。フラグが無ければ、ステップ１９０４からステップ１９０２へ分岐し、その候補のサブスクライバに通知が送信される。フラグが見付かれば、ステップ１９０４からステップ１９０５へ分岐し、そこでこの通知のトリガとなったかどうかについてサブスクリプションを再び調査する。この決定は、たとえば、そのサブスクリプションがなされた際に使用されたセッションの通信セッション識別子（「セッションＩＤ」）を調査することによってなされる。セッションＩＤは、たとえば全世界で一意に決まる識別子（ＧＵＩＤ）および６バイトの通し番号を含む。また通知は、その原因と関連付けられたセッションＩＤかどうかが調査される。この二つが一致すると、その通知は削除される。結果として、通知の原因となった電子メールクライアントの構成要素もまたその通知を受け取らない。次に処理は以下に説明するステップ１９０３に進む。

サブスクライバが通知のトリガとなっておらず、サブスクリプションと関連付けられたセッションＩＤが通知の原因と関連付けられたセッションＩＤと同一でなければ、ステップ１９０５はステップ１９０２へ分岐し、通知が送信される。次いで、処理はステップ１９０３に進み、そこで通知されるべきサブスクライバがさらに存在するかを判定する。存在すれば部分処理手順はステップ１９０１へ戻り、そうでなければこの処理を終了する。

上記のように、電子メールメッセージのキャッシュ記憶装置を利用する電子メールクライアントの構成要素は、たとえばＲＯＰを介して、ローカルのクライアントデータストアと電子メールサーバの構成要素で使用可能なデータストアとの間のメッセージまたは他のデータオブジェクトを同期することを要求できる。電子メールクライアントの構成要素は、同様にメッセージがサーバのストアからクライアントのストアへ複写されるよう要求することができる。どちらの場合にも、要求は高速転送モードを用いてなされることができる。

典型的には、メッセージまたはファイルのような他のデータが同期または複写のために要求される場合、その要求（たとえばＲＯＰ）は同期が要求されるすべてのメッセージの指示を含む。このリストは、電子メールサーバの構成要素により、たとえば上述したstateblob機能を利用して、自動的に構成されることができる。以前のバージョンの（従来技術の）電子メールサーバの構成要素にとって、ＲＯＰの要求における一つのメッセージまたはデータオブジェクト内のエラーは、その要求におけるすべての項目の障害原因となり得る。この過程は図１４Ａに示され、ＲＯＰ(たとえばFXPrepare)を含む要求が、ステップ１４０１で複写または同期の対象として指定されたメッセージＩＤのセットとともに送信される。電子メールサーバの構成要素５０２において高速転送機構が設定され、ステップ１４０２で高速転送ＩＤが電子メールクライアントの構成要素５０１に送信される。次いで、電子メールクライアントの構成要素５０１は、たとえばFXGetBufferＲＯＰを含む要求を通じて、データオブジェクトを複写または同期を要求する（ステップ１４０３）。電子メールサーバの構成要素５０２が要求されたメッセージを開こうとするとき、一つまたは複数のメッセージまたはデータオブジェクトでエラーが発生する。エラーの例には、メッセージまたはデータオブジェクトの破損、サーバの障害、電子メールサーバの構成要素５０２のメモリ不足またはデータオブジェクトについてのウィルスの発見が含まれる。

エラーが起こると、電子メールサーバの構成要素５０２は、ステップ１４０４で電子メールクライアントの構成要素５０１に向けて流されるデータの中に致命的ＲＯＰエラーを送信する。このようにして、同期が失敗すると、メッセージＩＤのセット内のメッセージは同期または複写されず、stateblobまたは類似する更新情報は電子メールクライアントの構成要素５０１によって受信されない。この場合、電子メールクライアントの構成要素５０１は、データオブジェクトの同期または複写を別の機会に要求しなければならない。エラーが電子メールサーバの構成要素５０２で修復されない場合、エラーメッセージが送信され続け、メッセージＩＤのセット内のメッセージは、絶対に同期または複写されない、ということも起こり得る。

本発明の一つの態様によると、最新の電子メールサーバの構成要素は、致命的ＲＯＰエラーの代わりに、同期が失敗する特定のデータオブジェクト(たとえば電子メールメッセージ)のみに関するエラー情報を送信することができる。この機能は、エラーを有するメッセージまたは他のデータオブジェクトが応答の中に含まれていても、ＲＯＰ内のメッセージまたは他のデータオブジェクトもしくは他の要求は、送信され、同期または複写されることを可能とする。

オブジェクト特有のエラーを扱う方法の一例として、最新のバージョンの電子メールサーバの構成要素は、オブジェクトエラーを有するデータオブジェクトについてのデータの流れの中でエラーメッセージを送信することができる。この例では、参照の容易のため、エラーをFXErrorInfoと表する。望むならば、さらに以下に述べるように、FXErrorInfoは、エラーを有するデータオブジェクトのメッセージＩＤ、メッセージの脱落の原因に関する追加的情報のような情報を含んでも良い。

図１４Ｂは、メッセージＭ_３にエラーが発生した場合の同期を示す。エラーは、メッセージＭ_１、メッセージＭ_２、続いてFXErrorInfo、およびメッセージＭ_４を含むFXGetBufferの応答１４０５の結果となる。FXErrorInfo情報は、電子メールクライアントの構成要素５０１がどのメッセージがエラーを有するかを知り、応答中の他のすべてのメッセージを同期することを可能にする。エラーメッセージFXErrorInfoがエラーの理由についての情報を含む場合、その情報はそれに応じて、クライアントの構成要素によって、たとえばエラーメッセージをユーザに表示することによって、使用される。

下表はFXErrorInfoが取り得るフォーマットの一例を示す。

例示的フォーマットはバージョン属性、エラーコード属性およびメッセージＩＤ属性を含むことが判るであろう。加えて、もし望むならば、一つまたは複数の属性を追加してもよい。さらに、上記したように、補助フィールドをエラーの詳細の通信のために定義することもできる。このように、属性が、エラーの詳細のフィールド（たとえば配列）のサイズを指定するために定義され、たとえば、エラーの詳細の通信のための非構造化配列を提供することができる。上述のように、エラーの詳細を、電子メールクライアントの構成要素５０１が望むように、処理することができる。

FXErrorInfoは、第１の応答の同期が完了、たとえばstateblobまたは他の情報が電子メールクライアントの構成要素５０１に提供される結果となることを可能にする。電子メールクライアントの構成要素は、今メッセージＭ_４まで同期されているので、同期のための次の要求１４０６は、Ｍ_４の後のメッセージ（たとえばＭ_５、Ｍ_６）を有する応答１４０７の結果となるであろう。

電子メールクライアントの構成要素５０１が最新のバージョンであり、したがってFXErrorInfoメッセージを処理することができることを示すため、たとえばFXRecoverModeのようなフラグを定義することができ、それを同期または複写を要求するＲＯＰとともに伝達することができる。他の指示を、電子メールクライアントの構成要素５０１がFXErrorInfoメッセージを処理することができる電子メールサーバの構成要素５０２と通信するために、使用することもできる。

電子メールサーバの構成要素５０２が一つまたは複数のメッセージまたは他のデータオブジェクトを電子メールクライアントの構成要素５０１へ送信する場合、電子メールクライアントの構成要素へのデータの流れは、プロパティタグ(たとえばptag)により分離または定義されることができる。たとえばメッセージのリストは、各メッセージについてメッセージ開始ptagおよびメッセージ終了ptagを含むことができる。開始および終了ptagの間にプロパティリストptagおよびサブジェクトptagがあり、文字列のプロパティを有することができる。サブジェクトptagは、後ろにサブジェクトそのものが来る場合がある。他のプロパティタグを含むこともできる。

メッセージの送信中にエラーが生ずる場合には、FXErrorInfoはptagとして提供され、上表に定義されたようにバイナリのプロパティを有するかもしれない。成功のメッセージおよびエラーが発生した場合のメッセージを有するデータの流れの一例を次に示す。エラーが生ずる場合には、メッセージ終了ptagはその特定のメッセージ対して用いられず、ptagFXErrorInfoがそのメッセージの最後のptagとなる。
ptagMessageListStart
ptagMessageStart
ptagPropList
ptagSubject [PT_STRING]
”Re; Your email”
…
ptagMessageEnd
ptagMessageStart
…
ptagFXErrorInfo [PT_BINARY]
[Contents as described by table]
ptagMessageStart
…
ptagMessageEnd
ptagMessageListEnd

図１５Ａは、電子メールサーバの構成要素５０２が以前のバージョンの電子メールクライアントの構成要素５０１にメッセージを転送するために使用する手順を示す。最初のステップ１５０１で、メッセージのセットは、たとえば高速転送データストアにメッセージのセットを配置することにより、準備される。ステップ１５０２で、たとえば電子メールサーバの構成要素５０２の送信バッファに配置されるとすぐに、メッセージのストリーム（streaming）が始まる。メッセージをストリーム中にエラーが発生すると、ステップ１５０４で、致命的ＲＯＰエラーが電子メールクライアントの構成要素５０１にストリームされる。そこで部分処理手順は終了する。メッセージの送出中にエラーが発生しなかった場合、ステップ１５０３でそのセット内にもっとメッセージがあるか判定がなされる。メッセージがあれば、処理はステップ１５０２に戻り、次のメッセージがストリームされ、メッセージがなければ、この部分処理手順は終了する。

図１５Ｂは、電子メールサーバの構成要素５０２の最新のバージョンによってメッセージのセットを操作する手順を示す。ステップは、電子メールクライアントの構成要素が最新のバージョンか以前のバージョンかにより異なる。ステップ１５０１乃至１５０４は、以前のバージョンの電子メールクライアントの構成要素に対して取る手順であり、前の段落における同一参照番号のステップと同一の処理を行う。

ステップ１５０２で、メッセージのストリーム中にエラーが発見されると、ステップ１５０５で、要求がFXRecoverModeのようなフラグを含むかを判定する。要求がフラグを含む場合、すなわち電子メールクライアントの構成要素５０１が最新のバージョンである場合には、ステップ１５０５はステップ１５０６に分岐し、FXErrorInfoが電子メールクライアントの構成要素５０１に向けてストリームされ、次いで、処理はステップ１５０３に続く。要求がフラグを含まない場合は、ステップ１５０５はステップ１５０４に分岐し、そこで致命的ＲＯＰエラーがストリームされ、この部分処理手順は終了する。

見て解るように、要求の中のフラグの存在は、失敗し致命的ＲＯＰエラーを送出する代わりに、FXErrorInfoをストリームすることを可能とすることで、ストリーム処理が継続することを可能にする。フラグは最新のバージョンの電子メールクライアントの構成要素５０１により送信される。以前のバージョンの電子メールクライアントの構成要素はフラグを含まず、したがって、上記したように、エラーが発生すると致命的ＲＯＰエラーが送出される。

望むならば、別の実施形態により、エラーメッセージ(たとえばFXErrorInfo)を、メッセージ全体についてではなく、メッセージの特定のプロパティまたは他のデータオブジェクトについて、送出することができる。たとえばFXErrorInfoは、メッセージのボディについてまたはメッセージへの添付に対して送出されることができる。したがって電子メールクライアントの構成要素５０１では、エラーを有するプロパティだけは同期または複写されないが、エラー無しで正しく送信されたプロパティを同期または複写することができる。

ときとして、メッセージまたは他のデータオブジェクトは、多数のFXGetBufferの応答にわたる程十分なサイズである場合がある。このようなメッセージを処理するため、電子メールクライアントの構成要素５０１は、ロールバック論理を含み、部分的に受信されたメッセージのいずれを部分的に処理し、エラーメッセージを受信した後に、続けてさらにメッセージを適切に受信することができる。

ときには、電子メールクライアントの構成要素が、電子メールメッセージのようなデータオブジェクトの複写または同期の進捗に関するフィードバックを与えられることが望まれる。本発明の一態様では、電子メールクライアントの構成要素５０１の最新のバージョンは、たとえば電子メールサーバの構成要素５０２にデータオブジェクトの同期や複写の要求するときに、PROGRESS_MODEのようなフラグを送信することにより、進捗モードを扱うことができることを示すことができる。応答において、電子メールサーバの構成要素５０２の最新のバージョンは、メッセージとともに、全メッセージの合計サイズ、メッセージの合計数、各メッセージの合計サイズまたはこれらの任意一つまたは組み合わせといった、多様な情報を送信することができる。

以前のバージョンの電子メールクライアントの構成要素５０１についての例として図１６Ａに示すように、電子メールクライアントの構成要素５０１は、メッセージのセットのための高速転送要求(１６０１と１６０３)に対する応答で、メッセージを受信する。図１６Ａにおいて、メッセージは、二つの応答１６０４および１６０６で受信される。高速転送機構を使用する以前のバージョンの電子メールクライアントの構成要素５０１においては、クライアントへストリームされるメッセージの進捗指示は提供されていなかった。

しかしながら、図１６Ｂに示すように、電子メールクライアントの構成要素によるメッセージのセットへの要求に対する応答１６０７において、電子メールサーバの構成要素５０２は、転送されるデータオブジェクトの合計数および転送される全データオブジェクトの合計サイズを提供することができる。この情報は図１６ＢではＰ_ａｌｌと表現されている。また電子メールサーバの構成要素５０２の最新のバージョンは、図１６Ｂでは“Ｐ_１、Ｐ_２、Ｐ_３、…”によって示された各メッセージのサイズを供給する。加えて、望むならば、各メッセージおよびメッセージのグループ全体と関連付けられた情報は、各メッセージがＦＡＩか実際の電子メールメッセージかどうかに関する追加的情報を含むこともできる。一実施形態では、図１６Ｂで“Ｐ_ａｌｌ”で表現された情報は、高速転送要求に対する応答の中で送信され、データストリームの処理を単純にするために、零のデータオブジェクトが転送される場合でさえも常に送信される。

転送されるすべてのデータオブジェクトのサイズと数に関するフォーマットの一例を下表に示す。

ＦＡＩデータオブジェクトの数、すべてのＦＡＩデータオブジェクトの合計サイズ、転送される電子メールメッセージの数および転送されるすべての電子メールメッセージの合計サイズについて別個の属性が定義されていることが判るであろう。他の組合せおよび追加的属性を希望通りにフォーマットに追加することができる。

次の表は、各メッセージとともに供給されるサイズおよび他の情報に関するフォーマットを示す。

フォーマットは、次のメッセージのサイズおよび次のメッセージがＦＡＩであるか否かの表示を含むことが判るであろう。

図１７Ａと図１７Ｂは、電子メール構成要素の以前のバージョンと、電子メール構成要素の最新のバージョンの各々にしたがってメッセージのセットをストリームするための手順を示す。図１７Ａの手順は、図１５Ａの手順１５０１−１５０３と同様である。図１７Ｂにおいては、最新のバージョンの電子メールクライアントの構成要素５０１によって、たとえばＲＯＰとともに、PROGRESS_MODEフラグが送信されている。メッセージのセットが準備された後ステップ１７０１で、そのフラグがあるかどうかが判定される。フラグがあれば、ステップ１７０２で全体の進捗データが送信され、次いで、処理はステップ１５０２に進み、そこで最初のメッセージがストリームされる。フラグが無ければステップ１７０１は直接ステップ１５０２に分岐する。

最初のメッセージがストリームされた後、処理はステップ１７０３に進み、そこでフラグが利用可能かどうかを判定する。利用可能であれば、次いでステップ１７０３はステップ１７０４に分岐し、そこでメッセージ毎の進捗データがストリームされる。次いで、処理は前述のステップ１５０３に進む。フラグが利用可能でなければステップ１７０３は直接ステップ１５０３に分岐する。

最新のバージョンのサーバの構成要素が最新のバージョンのクライアントの構成要素へデータを送信するデータのストリームの一例を以下に示す。このデータのストリームは上述したデータの流れと類似しているが、追加的に総データの進捗のためのptag（ptagIncrSyncProgressMode）を含み、たとえばバイナリのプロパティを有する。加えて、各メッセージについて、メッセージ毎の進捗データが、たとえばptagIncrSyncProgressModePerMsgとして供給される。
ptagIncrSyncProgressMode [PT_BINARY]
[Contents as described by table]
ptagMessageListStart
ptagIncrSyncProgressModePerMsg [PT_BINARY]
[Contents as described by table]
ptagMessageStart
ptagPropList
ptagSubject [PT_STRING]
”Re; Your email”
…
ptagMessageEnd
ptagIncrSyncProgressModePerMsg [PT_BINARY]
[Contents as described by table]
PtagMessageStart
…
ptagMessageEnd
ptagIncrSyncProgressModePerMsg [PT_BINARY]
[Contents as described by table]
PtagMessageStart
…
ptagMessageEnd
ptagMessageListEnd

この例では、総データの進捗を含むptag（ptagIncrSyncProgressMode）およびメッセージの進捗データのためのptag（ptagIncrSyncProgressModePerMsg）は、各々、メッセージのリストの前と、各メッセージの前に位置している。しかしながら、データオブジェクトのストリームの構造を修正して、進捗データがメッセージの中やメッセージリストの中に含まれるようにすることもできる。さらにデータオブジェクトのストリームの構造をメッセージおよび／またはメッセージリストを区切るptagをすべて除去するよう修正することも可能である。

進捗データを受信する電子メールクライアントの構成要素は、このデータを電子メールサーバの構成要素からのデータオブジェクトの同期または複写の進捗を判定するために利用することができ、メッセージ毎の進捗データを利用して個別のメッセージ毎の進捗を判定することができる。この情報は、たとえば同期の進捗についての実時間の情報を監視する際に、有益な場合がある。

いくつかの異なる文字セットが電子メールメッセージあるいは他のデータオブジェクトを格納するために使用される。たとえば、英語の文字を格納するためにＡＳＣＩＩ（American Standard Code for Information Interchange）が最も一般的に使用されている。しかしながら、ＡＳＣＩＩは、８ビット文字を基本としているため、すべての言語のための文字を格納するためには充分ではない。すなわち、ＡＳＣＩＩコードは、２５６文字のみで使用することができ、英語では充分であるが、より多くの文字を有する言語には不充分である。他方、Ｕｎｉｃｏｄｅは、各文字につき１６ビット(２バイト)を使用する文字コード体系であり、したがってＡＳＣＩＩより多くの文字を含むことができる。Ｕｎｉｃｏｄｅは、６５、５３６の文字を持つことができ、したがって世界のほとんどすべての言語を符号化するために使用することができる。Ｕｎｉｃｏｄｅは、ＡＳＣＩＩ文字コード体系をその中に包含する。

一般に、電子メールクライアントの構成要素５０１の以前のバージョンは、指定されたコードページすなわち文字コード体系、および／またはそれと関連付けられた言語を有する。たとえば、電子メールクライアントの構成要素５０１の特定のバージョンは、ドイツ語のコードページを有し、他のバージョンはＡＮＳＩ（American National Standard Institute）のコードページを有する場合がある。ときとして、電子メールクライアントの構成要素５０１は、指定されたコードページでない文字コード体系で電子メールを受信したいことがある。本発明の一つの態様によれば、最新バージョンのクライアントの構成要素は、電子メールサーバの構成要素がすべての電子メールをＵｎｉｃｏｄｅで供給するよう強制することができる。一旦電子メールが電子メールクライアントの構成要素５０１によって受信されると、そのＵｎｉｃｏｄｅの電子メールをクライアントのコードページに変換でき、あるいはまたＵｎｉｃｏｄｅフォーマットで維持することができる。

電子メールクライアントの構成要素５０１が、電子メールがＵｎｉｃｏｄｅで提供されるよう要求することを示すために、電子メールクライアントの構成要素５０１は、電子メールサーバの構成要素５０２に、たとえばFORCEUNICODEのようなフラグを提供する。フラグは、ＲＯＰのような要求とともに提供することができる。電子メールサーバの構成要素５０２が最新のバージョンである場合には、電子メールサーバの構成要素５０２は、その電子メールのＵｎｉｃｏｄｅ版を提供することができ、あるいは利用できるならば、他の文字コード体系の電子メールメッセージをＵｎｉｃｏｄｅに変換することができる。

図２０は、本発明の一態様にしたがって、メッセージに対して特定の文字コード体系を提供するための手順を示す。まずステップ２００１で、電子メールサーバの構成要素５０２はそのデータストアからメッセージを読み出す。ステップ２００２で、FORCEUNICODEフラグの有無が判断される。フラグがなければ、ステップ２００２はステップ２００３に分岐し、そこで電子メールサーバの構成要素５０２は、必要ならば変換して、電子メールクライアントの構成要素の指定されたコードページで電子メールメッセージを提供する。

FORCEUNICODEフラグがあれば、次にステップ２００２はステップ２００４に分岐し、そこでメッセージがＵｎｉｃｏｄｅで格納されているかどうかが判定される。Ｕｎｉｃｏｄｅで格納されていれば、ステップ２００４はステップ２００５に分岐し、そこでメッセージがＵｎｉｃｏｄｅ文字コード体系で電子メールクライアントの構成要素５０１に供給される。メッセージがＵｎｉｃｏｄｅで格納されていなければ、ステップ２００４はステップ２００６に分岐し、そこでメッセージはＵｎｉｃｏｄｅに変換され、次に処理はステップ２００５へ続き、そこでメッセージが電子メールクライアントの構成要素にＵｎｉｃｏｄｅで供給される。

ここで引用した出版物、特許出願および特許を含むすべての引例は、各引例が個別にかつ明確に参照により開示されることが表記されかつその内容がその中に述べられているのと同一の範囲まで、その参照によりその開示内容を本明細書の一部とする。

用語「一つの」、「前記」および本発明(特に以下の請求範囲)を説明するのに使用する同様な言葉は、本明細書中で指示しないまたは文脈から明らかに否定されない限り、単一および複数の両方を意味するものと解釈されるべきである。用語「備える」、「含む」、「有す」、「持つ」、「包含する」および「よりなる」は、特に言及しない限り、制限の無い用語（すなわち、「―――を含むが、それに限定されない」という意味）と解釈されるべきである。本明細書中の値の範囲の説明は、本明細書中で指示しない限り、単にある範囲の中にある各個の数値を別個に引用する代わりの簡略な方法を意図したものであり、各個の値は明細書中で個別に説明されるのと同じように詳細な説明に包含される。ここで述べられるすべての方法は、本明細書中で指示しないまたは文脈から明らかに否定されない限り、任意の適切な順序で実行されることができる。ここで提供された任意のおよびすべての例または例示的表現（たとえば「のような」、「に類する」）の使用は、単に本発明をより明らかにすることを意図してのものであり、特許請求しない限り、発明の範囲に制限をつけようとするものではない。明細書中のいずれの表現も、特許請求の範囲に記載されていない要素であり、本発明の実施に関し本質的であると解釈されてはならない。

本明細書中で、本発明を実施する上で発明者が最良の形態であると承知しているものを含む本発明の好ましい実施形態が説明されている。上記した説明を読むことで当業者にはこれらの好ましい実施形態の変更態様が明らかになるであろう。発明者等は、当業者がこれら変更態様を適切に採用することを予期し、かつ発明者等は、発明がここで明確に説明されたものと異なる方法で実施されることを予定している。したがって、適用する法律により認められるように、本発明は、添付した特許請求範囲に記載される内容に対するすべての改造および均等なものを含む。さらに、本明細書中で指示しないまたは文脈から明らかに否定されない限り、すべての可能な変更態様における上述の要素の組合せのいずれもが本発明の請求範囲に包含される。

ネットワークによって接続されたコンピュータの概略図である。 本発明の実施形態の実施に用いることができる例示的なコンピュータシステムを示す概略図である。 電子メールクライアントの構成要素と電子メールサーバの構成要素の両方が複数のバージョンを有する環境を示す概略図である。 電子メールクライアントの構成要素と電子メールサーバの構成要素の間のプロトコルネゴシエーション手順の例を示すプロトコル図である。 電子メールクライアントの構成要素と電子メールサーバの構成要素が決まったサイズの通信バッファを有する例示的電子メールネットワークを示す概略図である。 高速転送操作を完成するため二つの要求―応答サイクルを必要とする例示的プロトコルを示すプロトコル図である。 高速転送操作を完成するため一つの要求―応答サイクルを必要とする例示的プロトコルを示すプロトコル図である。 電子メールクライアントの構成要素へ電子メールメッセージのボディを送信するための例示的手順を示すフローチャートである。 本発明の態様にしたがって、電子メールクライアントの構成要素へ電子メールメッセージのボディを送信するための手順を示すフローチャートである。 全アイテム転送モードを示すシーケンス図である。 ヘッダ先送り転送モードを示すシーケンス図である。 ヘッダのみ転送モードを示すシーケンス図である。 ヘッダ先送りまたはヘッダのみ転送モードの例外を示すシーケンス図である。 電子メールクライアントの構成要素のホーム電子メールサーバの構成要素が時間の経過とともに変更されることを示す概略図である。 電子メールクライアントの構成要素と電子メールサーバの構成要素との間で電子メールフォルダを同期するための例示的プロトコルを示すプロトコル図である。 stateblobの部分を最適化する例示的手順を示すフローチャートである。 本発明にしたがって、stateblobの部分を最適化する手順を示すフローチャートである。 電子メールフォルダの階層を示す概略図である。 本発明の態様にしたがって、電子メールメッセージストアの同期を行い、同期を維持するための例示的プロトコルを示すプロトコル図である。 ＲＯＰレベルでエラー情報を通信するための例示的プロトコルを示すプロトコル図である。 本発明の態様にしたがって、メッセージごとのエラー情報を通信するための例示的プロトコルを示すプロトコル図である。 ＲＯＰレベルでのエラー情報を生成する手順を示すフローチャートである。 本発明の態様にしたがって、メッセージごとのエラー情報を生成する手順を示すフローチャートである。 高速転送操作を実行するための例示的プロトコルを示すプロトコル図である。 本発明の態様にしたがって、高速転送操作を実行中に進捗情報を供給するための例示的プロトコルを示すプロトコル図である。 メッセージのセットをストリームするための手順を示すフローチャートである。 本発明の態様にしたがって、進捗情報を伴ってメッセージのセットをストリームするための手順を示すフローチャートである。 電子メールサーバの構成要素の同一のデータオブジェクトに対する変更の結果として、通知がなされる複数の電子メールクライアントの構成要素を示す概略図である。 複数のサブスクライバに通知するための手順を示すフローチャートである。 本発明の態様にしたがって、複数のサブスクライバに通知するための手順を示すフローチャートである。 本発明の態様にしたがって、所望のコードページを使用する電子メールメッセージを提供するための手順を示すフローチャートである。

符号の説明

１０ コンピュータ
１１ ネットワーク
１４ 処理ユニット
１６ メモリ
１８ 基本的な構成
２０ 表示装置
２０１ 取り外し可能な記憶装置
２０２ 取り外し不可能な記憶装置
２０３ 出力装置
２０４ 入力装置
２０５ 通信接続装置
３０７〜３１１ プロトコル
９０１，９０３，９０５ 電子メールサーバの構成要素
９０２，９０４，９０６ 電子メールクライアントの構成要素

Claims (10)

1. 電子メールメッセージの最適なメッセージボディが望まれている旨の指示を含む、電子メールメッセージに対する要求を、電子メールサーバの構成要素で受信することであって、前記指示は、要求された電子メールメッセージと関連付けられた電子メールメッセージのボディが一つしかない場合は、当該電子メールメッセージのボディが前記最適なメッセージボディとして望まれ、要求された電子メールメッセージと関連付けられた電子メールメッセージのボディがいくつか利用できる場合は、予め定められた電子メールメッセージの複数のボディフォーマットの優先順位にしたがい前記電子メールサーバの構成要素により選択される当該電子メールメッセージのボディが前記最適なメッセージボディとして望まれている旨を指示する、こと、
   電子メールサーバの構成要素が、前記電子メールサーバの構成要素と関連付けられたデータストアにアクセスし、前記予め定められた電子メールメッセージの複数のボディフォーマットの優先順位にしたがい、要求された電子メールメッセージと関連付けられた電子メールメッセージの前記最適なメッセージボディを選択すること、および
   電子メールサーバの構成要素が、前記最適なメッセージボディのフォーマットを変換すること無く、選択した前記最適なメッセージボディを読み出して前記要求の要求元である電子メールクライアント構成要素へ返すこと
   を含むコンピュータ実行可能命令を記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
2. 前記要求は、前記メッセージが配置されるフォルダの同期の要求を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
3. 前記要求は、電子メールメッセージの複写の要求を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
4. 前記指示は、前記要求とともに含まれるフラグを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
5. 前記選択することは、利用できる電子メールメッセージのボディを前記優先順位にしたがって評価することを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
6. 電子メールクライアントの構成要素と電子メールサーバの構成要素との間で電子メールメッセージを転送する方法であって、
   電子メールクライアントの構成要素が、メッセージに対する要求を生成し前記電子メールサーバの構成要素へ送ることであって、前記要求は電子メールの最適なメッセージボディが望まれている旨の指示を含み、前記指示は、要求された電子メールメッセージと関連付けられた電子メールメッセージのボディが一つしかない場合は、当該電子メールメッセージのボディが前記最適なメッセージボディとして望まれ、要求された電子メールメッセージと関連付けられた電子メールメッセージのボディがいくつか利用できる場合は、予め定められた電子メールメッセージの複数のボディフォーマットの優先順位にしたがい前記電子メールサーバの構成要素により選択される当該電子メールメッセージのボディが前記最適なメッセージボディとして望まれている旨を指示する、こと、
   前記電子メールサーバの構成要素が、前記要求を受信すること、
   前記電子メールサーバの構成要素が、前記電子メールサーバの構成要素と関連付けられたデータストアにアクセスし、前記予め定められた電子メールメッセージの複数のボディフォーマットの優先順位にしたがい、要求された電子メールメッセージと関連付けられた電子メールメッセージの前記最適なメッセージボディを選択すること、および
   前記電子メールサーバの構成要素が、前記最適なメッセージボディのフォーマットを変換すること無く、選択された前記最適なメッセージボディを読み出して前記電子メールクライアントの構成要素へ返すこと
   を含むことを特徴とする方法。
7. 前記要求は、前記メッセージが配置されるフォルダの同期の要求を含むことを特徴とする請求項６に記載の方法。
8. 前記要求は、電子メールメッセージの複写の要求を含むことを特徴とする請求項６に記載の方法。
9. 前記指示は、前記要求とともに含まれるフラグを含むことを特徴とする請求項６に記載の方法。
10. 前記選択することは、利用できる電子メールメッセージのボディを前記優先順位にしたがって評価することを含むことを特徴とする請求項６に記載の方法。

Images