JP2007527557A - 分散ソフトウェア・アプリケーションを含むデータ・アクセス、複製または通信システム - Google Patents

Abstract

本発明は、端末上で実行される端末側の構成要素とサーバ側の構成要素とに分散されるソフトウェア・アプリケーションを含むデータ・アクセス、複製または通信システムであって、前記端末側構成要素とサーバ側構成要素とが（ｉ）共にサーバへのクライアントを構成し、（ii）ネットワーク上でメッセージ・キューイング・システムを用いてメッセージを送信することで協働するシステムを想定している。したがって、クライアント−サーバ構成内のクライアントとして機能するアプリケーションの機能は、メッセージ指向ミドルウェアなどのメッセージ・キューイング・システムを用いたネットワーク接続上で相互に通信する複数の物理デバイス上で実行される構成要素部分に分割（分散）される。構成要素部分はまとめてより大きいクライアント−サーバ構成内のクライアントとして機能し、例えば、サーバはメール・サーバである。これを「分散クライアント」モデルと呼ぶ。分散クライアント・モデルの基本的な利点は、処理容量、処理能力、コネクティビティが限られた移動体デバイスなどの端末が、通常はクライアントに関連する機能の一部をそれほどリソースの制約がないサーバ側に分散することで移動体デバイス上の最小のリソースを用いてサーバ環境へのフル装備のクライアント・アクセスを享受する。

Description

本発明は、分散ソフトウェア・アプリケーションを含むデータ・アクセス、複製または通信システムに関する。

スマートホン、携帯電話、無線ＰＤＡなどの無線端末は、通常、メモリ、処理能力、バッテリの制約が厳しい。その結果、この種の端末を用いてデータにアクセスし、複製し、または通信することが重大な課題を提起する。例えば、無線端末を用いて連絡先やカレンダを記憶し、Ｅメールを送受信する場合、従来、データセットをリモート・サーバ上のマスタ・データセットに同期させる必要が生じた。サーバと移動体デバイスとの間での同期化は、従来、比較的高い帯域幅、低い待ち時間、計測されないコネクティビティ（例えば、ＵＳＢまたはＩＲ）を用いて実行される。その結果、同期化システムは大量のデータを送信し、送信中にデータ損失が発生したり基本伝送が中断した時にあまり堅牢でない方法を使用することが多い。例えば、サーバ・ベースのデータセット同期化は、通常、すべての接続されたデバイスがその全データセット（例えば、すべてのＥメール、すべての連絡先など）を単一のセッションでサーバにダウンロードすることを要求し、サーバは、マスタ、すなわち、すべてのその他のデータセットを更新するために最後の完全に同期化されたデータセットのマスタ・コピーとの比較を実行できる。この手法は、必要な消費電力、潜在的に長い接続時間、高コストのデータ転送が理由で、無線デバイスの同期化にとっては魅力的でない。

本発明は、端末上で実行される端末側の構成要素とサーバ側の構成要素とに分散されるソフトウェア・アプリケーションを含むデータ・アクセス、複製または通信システムであって、
前記端末側構成要素とサーバ側構成要素とが（ｉ）共にサーバへのクライアントを構成し、（ii）ネットワーク上でメッセージ・キューイング・システムを用いてメッセージを送信することで協働するシステムである。

したがって、クライアント−サーバ構成内（例えば、Ｍｉｃｒｏｓｏｆｔ ＥｘｃｈａｎｇｅのＥメール環境内）のクライアントとして機能するアプリケーションの機能は、メッセージ指向ミドルウェアなどのメッセージ・キューイング・システムを用いたネットワーク接続上で相互に通信する複数の物理デバイス上で実行される構成要素部分に分割（分散）される。構成要素部分はまとめられると、より大きいクライアント−サーバ構成内のクライアントとして機能する。例えば、サーバはＥｘｃｈａｎｇｅのメール・サーバである。これを「分散クライアント」モデルと呼ぶ。分散クライアント・モデルの基本的な利点は、処理容量、処理能力、コネクティビティが限られた移動体デバイスなどの端末が、通常はクライアントに関連する機能の一部をそれほどリソースの制約がないサーバ側に分散することで移動体デバイス上の最小のリソースを用いてサーバ環境へのフル装備のクライアント・アクセスを享受することができる。（したがって、本発明は端末が無線端末（例えば、スマートホン）でネットワークが無線ネットワーク（例えば、ＧＰＲＳ）の特定のユーティリティを有する一方、本発明はこれらの実施態様に限定されない。例えば、本発明は有線ネットワーク上でリモート・サーバと通信するデスクトップＰＣである端末をカバーする。）

他の分散モデルとは異なり、本発明の一実施態様では、各構成要素部分は、ネットワーク接続がない時でも他方から独立して機能（キャッシュされた／記憶されたータにアクセスする機能に留まらない）を提供できる。例えば、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅメール・サーバにアクセスするウェブ・ブラウザやウェブ・サーバ分散クライアントを用いたＥメール・ウェブ・アクセスなどの従来の分散クライアントでは、ブラウザとウェブ・サーバとの接続を切断すると、ブラウザはキャッシュされたＥメールの表示を継続する以外の機能を持たなくなる。

ただし、本発明の一実施態様では、端末側構成要素は、ネットワーク上の接続が接続を再確立する準備が出来た状態でメッセージをキューイングすることによって切断される場合に、端末プログラム（例えば連絡先、カレンダ、Ｅメールなど）が影響を受けるのを防止できる。この結果、端末プログラムは次のタスクに移行できる。したがって、ＥメールまたはＰＩＭアプリケーションを端末（スマートホン、ＰＣなど）上で使用するユーザの経験は接続のあるなしに関わらず全く同じである。ユーザはその端末上でＥメールを作成し連絡先を編集するなどの作業ができる。端末は接続が再確立され、自動的にメッセージを送信できる時点まで、メッセージ・キューイング・システムを用いてメッセージをキューイングできるので、ユーザはネットワーク接続の状態から隔離されている。同様に、サーバ側の構成要素は、ネットワーク上の接続が接続を再確立する準備が出来た状態でメッセージをキューイングすることで切断される場合に、サーバ・プログラムが影響を受けるのを防止できる。この結果、サーバ・プログラムは次のタスクに移行できる。

この手法は、メッセージ・キューイング・プラットフォームをネットワーク内に挿入することでネットワーク・パフォーマンスの気まぐれから端末を隔離することを容易にするため、ネットワークが極めて予測不可能な帯域幅、通信可能範囲、可用性を備えた無線ネットワークである時にもより優れている。したがって、分散クライアント・モデルは、端末に重大なリソースの制約があり接続に重大な制約があっても、端末で優れたユーザ経験を提供するという問題に直接対処する（例えば、エンド・ユーザはネットワーク通信範囲に関わらず、常にそのＰＩＭ、カレンダ、Ｅメール・アプリケーションと対話できる）。

分散クライアントのために最適化された一実施態様の詳細は、各々のキューイングされたメッセージが「イベント」の一部または全部を定義し、メッセージ内でイベントは端末またはサーバに記憶されたデータの変更を詳細に記述し、従来の同期化エンジンを必要とせずにデータ複製を実行する。こうして、データ複製は、同期化のための記憶されたデータのデータセット一式（またはデータセットのサブセット）ではなく、「イベント」を送信することで達成される。端末側構成要素はイベントを作成して自らおよび／またはメッセージ・キューイング・システム内にキューイングできる。こうして、ネットワーク接続が切断されていても端末側構成要素は次のタスクに移行できる。同様に、サーバ側構成要素もイベントを作成して自らおよび／またはメッセージ・キューイング・システム内にキューイングできる。こうして、ネットワーク接続が切断されていてもサーバ側構成要素は次のタスクに移行できる。キューイングされたイベントは無線端末の電源がオフになっても端末の不揮発性メモリ内に存続できる。同様に、キューイングされたイベントはサーバの電源がオフになってもサーバ側構成要素を実行するホストの不揮発性メモリ内に存続できる（サーバ側構成要素を実行するホストはサーバを実行するホストと同じ場合もあるが違うことが多いことに注目されたい）。

端末側構成要素とサーバ側構成要素は、無線端末上で実行されている端末プログラムとサーバ上で実行されているサーバ・プログラムとの間のミドルウェアを集合的に構成している。

アプリケーションはまたメッセージ・キューイング機能を提供する分散通信プラットフォームを呼び出し、それによって、通信プラットフォームが「セッション非依存」方式で動作する不確実なプロトコルが使用されている場合であっても、通信プラットフォームはネットワーク上のメッセージを確実に配信することができる。

詳細説明
１．序論
本発明をＶｉｓｔｏ Ｃｏｒｐｏｒａｔｉｏｎの一実施形態に関連して説明する。この実施形態はＭｏｂｉｌｅＭＱ（商標）と呼ばれるミドルウェア通信プラットフォームとＴｒａｎｓｃｅｎｄ Ｍａｉｌ（商標）と呼ばれる分散アプリケーション・レイヤとを含む。

Ｔｒａｎｓｃｅｎｄ ＭａｉｌはＳｙｍｂｉａｎＯＳ（商標）スマートホン無線端末とＷｉｎｄｏｗｓ ２０００サーバ上で実行される（すなわち、これらに分散される）エンドツーエンドのＧＰＲＳ接続アプリケーションである。これによって、ＳｙｍｂｉａｎＯＳスマートホン上のＥメール、連絡先、カレンダ・アプリケーションはＭｏｂｉｌｅＭＱプラットフォームを用いてＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ（商標）メール・サーバでＧＰＲＳ上に自動データ複製を実行することができる。ＭｏｂｉｌｅＭＱはスマートホンとサーバ間に分散されたメッセージ指向ミドルウェア・プラットフォームである。ＭｏｂｉｌｅＭＱは、Ｔｒａｎｓｃｅｎｄ Ｍａｉｌのユーザ経験の多くの態様を可能にするＧＰＲＳが有効な、確実で安全な通信手段を提供する。ＭｏｂｉｌｅＭＱは、ネットワーク（有線、無線を問わず）上でリモート・データ・アクセス、複製または通信の要求がある場所のどこでも使用できる。ＭｏｂｉｌｅＭＱは不確実な、セッションから独立した基本トランスポート・プロトコルを使用する。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌを用いて移動体利用者は、ＳｙｍｂｉａｎベースのＧＰＲＳスマートホンからその会社のＥメール、連絡先、カレンダ項目にアクセスできる。Ｔｒａｎｓｃｅｎｄ Ｍａｉｌは以下の３つの移動体利用者のニーズを満たすように構成されている。
１．離席していても「連絡」が可能で、顧客、市場、ビジネス・ニーズに応答できる。
２．同僚との協働が可能なように連絡先やカレンダを常に「更新」しておく。
３．アポイントメント、移動待機、または出張中の「空き時間」を有効活用できる。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌは以下の機能を実現する。
・端末デバイスのユーザ・インタフェースがローカル・データを処理してＧＰＲＳレイテンシ、貴重な低帯域幅、断続する通信可能範囲によってＥメール、連絡先、カレンダ・アプリケーションが常時利用可能で応答できるようにする。
・ローカル・データとサーバ側データの変更をタイムリにかつユーザを邪魔しないようにバックグランドで自動複製する。
・顧客がネットワーク運用会社のＧＰＲＳ料金から適当な値を得て「ビル・ショック」とも呼ばれるものを得ないようにＧＰＲＳの使用を少なくする。
・顧客の組織が従業員のＧＰＲＳ携帯電話を企業ＬＡＮに接続する方法の柔軟性を確保する。
・ユーザが新しいシステムを学習しないで済むように携帯電話のアプリケーション・スイートと可能な限りシームレスに統合する。
・ＩＴアドミニストレータが快適でありユーザ経験が良好なようにバック・エンドのＥメール・サーバと可能な限りシームレスに統合する。
・端末デバイス上の異なるアプリケーションは個別に送受信が可能なため、大容量のＥメール添付ファイルをダウンロードしていてもカレンダの更新が可能である。

２．基本設計原理
本発明の一実施形態では、クライアント−サーバ構成（例えば、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ環境の）のクライアントとして機能するＴｒａｎｓｃｅｎｄ Ｍａｉｌアプリケーションの機能が、ＭｏｂｉｌｅＭＱメッセージ指向ミドルウェアを用いてワイド・エリア接続を介して相互に通信する複数の物理デバイス上で実行される構成要素部分に分割（分散）される。構成要素部分は、サーバがＥｘｃｈａｎｇｅのメール・サーバである、より大規模のクライアント−サーバ構成内で集合的に動作する。これを「分散クライアント」モデルと呼ぶ。分散クライアント・モデルの基本的な利点は、処理容量、処理能力、コネクティビティが限られた移動体デバイスなどの端末が、通常はクライアントに関連する機能の一部をそれほどリソースの制約がないサーバ側に分散することで移動体デバイス上の最小のリソースを用いてサーバ環境へのフル装備のクライアント・アクセスを享受することを可能にするという点である。

ただし、他の分散モデルとは異なり、Ｔｒａｎｓｃｅｎｄ Ｍａｉｌでは、各構成要素部分はネットワーク接続がない時でも他方から独立して機能（キャッシュされた／記憶されたデータにアクセスする機能に留まらない）を提供できる。例えば、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅメール・サーバにアクセスするウェブ・ブラウザとウェブ・サーバ分散クライアントを用いたＥメール・ウェブ・アクセスなどの従来の分散クライアントでは、ブラウザとウェブ・サーバとの接続を切断すると、ブラウザはキャッシュされたＥメールの表示を継続する以外の機能を持たなくなる。Ｔｒａｎｓｃｅｎｄ Ｍａｉｌでは、スマートホンでＥメールまたはＰＩＭ（連絡先、カレンダ）アプリケーションを使用するユーザ経験は接続のあるなしに関わらず同じである。ユーザは依然としてスマートホンでＥメールを作成し、連絡先を編集するなどの作業ができる。接続が再確立され、次のキューイングされたメッセージを自動送信できる時までＭｏｂｉｌｅＭＱを用いて（またＭｏｂｉｌｅＭＱが満杯の場合は端末キューを用いて）端末はメッセージをキューイングできるのでユーザはネットワーク接続の状態から隔離されている。同様に、サーバ側に記憶された次のキューイングされたメッセージは接続が再確立されると自動的に送信できる。

この手法は、メッセージ・キューイング・プラットフォーム（つまりＭｏｂｉｌｅ ＭＱ）をネットワーク内に挿入することでネットワーク・パフォーマンスの不安定さから端末を隔離することを容易にするため、ネットワークが極めて予測不可能な帯域幅、通信可能範囲、可用性を備えた無線ネットワークである時にもより優れている。したがって、分散クライアント・モデルは、端末に重大なリソースの制約があり接続に重大な制約があっても、端末で優れたユーザ経験を提供するという問題だけでなくその他の問題に直接対処する（例えば、エンド・ユーザはネットワーク通信範囲に関わらず、常にその連絡先、カレンダ、Ｅメール・アプリケーションと対話できる）。この概略を図１に示す。

ＭｏｂｉｌｅＭＱメッセージ指向ミドルウェア（ＭＯＭ）通信プラットフォームによって、構成要素部分は構成要素部分の間で送信するメッセージを効果的かつ効率的に記憶し、実際に確実に送信することができる。基本トランスポート・プログラムの確実性いかんに関わらず、またいかなるセッションにも依存せずに、ＭｏｂｉｌｅＭＱ ＭＯＭはネットワーク上のメッセージ送信を確実に実行する。このためトランスポート・プロトコルは「セッション非依存」と呼ばれる。このことは、セッション・ベースのＷＡＰなどの通常のネットワーキング・プロトコルからの大きな前進である。したがって、「セッション非依存」（上記の）はセッション・ベースとは対照的である。セッション・ベースのプロトコルはデータ転送速度がしきい値を下回るか、タイムアウト発生時にセッションを終了する。新しいセッションの開始時には、データ・トラヒックの交換が必要である。このことは、（ａ）ユーザが送信データ量に対して課金される無線システムではコスト高であり、かつ（ｂ）無線ネットワークに関連する極めて貴重な帯域幅のために頻発する。セッション非依存プロトコルは接続の終了をうまく回避する。（ここでは、基本ＰＤＰコンテキストが他のアプリケーションが使用するために解放されたか再割り当てされた、あるいは現在の基本ＰＤＰコンテキストが失われ、またはその他タイムアウトになったケースを区別する。これらのタイプのケースでは、上位レイヤのセッション非依存プロトコルは通信アクティビティのＰＤＰコンテキストの再獲得をペンディング状態にする−したがって、「セッション」を再確立する必要はない。）

図２に示すように、ＭｏｂｉｌｅＭＱ ＭＯＭとセッション非依存との組み合わせは多数の接続規制の問題を扱うことになる。

さらに、セッション非依存プロトコルでは、セッションの再確立はない。送信側構成要素はメッセージを分散クライアントの受信側構成要素に宛てる方法が分かるとすぐに送信を再開する。無線デバイスは全くＩＰアドレスを有せず（ＩＰｖ６が利用可能でないか利用可能になるまで）、頻繁に変更される任意の選択したＩＰアドレスを介してしかＩＰベースのメッセージを受信できないので、この方法は無線デバイスに時に有用である。したがって、セッション非依存は、一時的なアドレスを有するが、これらの変動するアドレスに対処するオーバヘッドが最小である無線デバイスにメッセージを送信する要件によく適合する。これはセッション再確立のオーバヘッドがないためである。

またＴｒａｎｓｃｅｎｄ Ｍａｉｌは「イベント」ベースのデータ複製を採用する。すなわち、クライアントまたはサーバ側に記憶されたデータの変更を定義するすべての新しいイベントの記録が保存される。これらのイベントはログにキューイングされる。分散クライアントの各々の側の間に接続が再確立されると各々のキューイングされたイベント（イベントの複雑さに応じて１つまたは複数のメッセージで表される）が送信され、１つのメッセージが１つまたは複数のパケットによって搬送される。ＭｏｂｉｌｅＭＱによってメッセージの効率的で確実な転送が可能になったので、メッセージの効率的で確実な転送のみを要求するイベント・ベースのデータ複製システムにはよく適合する。

ＭＯＭを用いた上位レベル・アプリケーションは接続ステータスを認識していない。すなわち、ＭｏｂｉｌｅＭＱは、ＭｏｂｉｌｅＭＱを使用するアプリケーションを基本接続（アクティブなＰＤＰコンテキストなど）の存否を認識する必要から隔離するＭＯＭレイヤである。アプリケーション・レイヤで、システムは「接続非依存」である。したがって、「セッション非依存」という用語は、接続が中断後に再確立されると、アプリケーションが停止した全く同じ場所からメッセージ転送を再開できる、すなわち、アプリケーションが送信する次のメッセージは接続中断がなければ送信されたはずのメッセージであるという意味で、アプリケーション・レイヤでは、実際の接続が確立されているか否かに関わらず存続する単一のセッションがあるシステムに概念的に相当する。セッション・ベースのシステムでは、これは起こらない。逆に、セッションを再確立するためのかなりのオーバヘッドが最初にかかる。セッションが再確立されると、メッセージ転送の再開が、さらに非生産的なデータ転送である以前に送信した大量のメッセージ・データの送信を含むとしても、メッセージ転送が再開する。

ＭｏｂｉｌｅＭＱでは確実性（すなわち、メッセージが受信されたことを保証できること）がオーバヘッドが高いセッション・べースのプロトコルに頼らずに達成される。本発明では、送信側デバイスで、別のメッセージが送信できるまでに受信側デバイスで個々のメッセージが受信されて正しく処理されたという確認を受信することが要求される。この「メッセージ・レベル」の確実性は、セッション・べース・システムと対照的に接続が中断した場合に通信を再開する際のオーバヘッドが最小であるために、はるかにデータ効率がよい。これは、接続の中断がまれでない無線ネットワークでは特に重要な利点である。

従来技術では、認証はセッション開始時に高いデータ転送オーバヘッドを伴って達成される。ＭｏｂｉｌｅＭＱ ＭＯＭはセッション非依存のため、メッセージごとの認証（「メッセージ・レベル」認証）を提供する。これはデバイス再ブート時に常にカウントアップするセッション番号に基いて、セッション・レベル認証と組み合わすことができる。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌと組み合わされたＭｏｂｉｌｅＭＱは、図３に示すように、端末リソースと接続の制約を効率的に扱うという双子の問題の包括的で有効な解決策である。

図４は、この組み合わされた構成によって、セッション・べースのシステムが通常提供するＭＯＭによって提供されるセッション非依存機能を、スマートホンなどのリソースが限られた端末に適した方法で配備することができる様子を示す。これらの特徴は以下を含む。
（ａ）メッセージ配信の確実性
（ｂ）送信側の認証
（ｃ）メッセージのセキュリティ
（ｄ）データ速度のフロー制御
（ｅ）パケット・ルーティング

同様に、図４は、この組み合わされた構成が分散クライアントの目的に適するように構成された機能が接続の制約を扱う様子を示す。主要な特徴は「イベント」べースのデータの使用であり、このために、セッション非依存の性格を帯びる。

３．基本設計原理の詳細
３．１ 分散クライアント
分散クライアントの目的は、処理容量、処理能力、コネクティビティが限られた移動体デバイスが、通常はクライアントに関連する機能の一部をそれほどリソースの制約がないサーバ側に分散することで移動体デバイス上の最小のリソースを用いてサーバ環境へのフル装備のクライアント・アクセスを享受することを可能にするという点である。クライアント・アプリケーションはＰＩＭ（カレンダ、アドレス帳など）やメッセージング（Ｅメール、ＭＭＳ、ファックス、ＳＭＳなど）である。

実際、本発明では、より大規模なクライアント−サーバ・アプリケーション内で集合してクライアントとして機能するようにクライアント−サーバ・アプリケーションの機能が分割される。代表的な構成は、スマートホン（スモール・クライアント）などの移動体デバイスにソフトウェアをインストールし、対応するソフトウェアをサーバ・デバイス（スモール・サーバ）にインストールする方法である。これら２つのソフトウェアは、ＭｏｂｉｌｅＭＱなどのＭＯＭを介して、ＧＰＲＳまたはＵＭＴＳなどの高レイテンシ、低帯域幅、計測される無線コネクティビティを通常用いて互いに通信する。スモール・クライアントとスモール・サーバは従来のクライアント−サーバ環境内で集合してクライアント（「ラージ・クライアント」または「分散クライアント」として動作する）として機能する。次いで、ラージ・クライアントは標準としてもＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ（ラージ・サーバ）などの関連するサーバと通信する。したがって、ラージ・サーバはラージ・クライアントと通信していることしか認識していない。ラージ・サーバ側からはラージ・クライアントは普通に通信している相手の他のどのクライアントとも区別がつかない。このため、ラージ・サーバからはラージ・クライアントの分散的な性質は見えない。（代表的な構成では、スモール・サーバはラージ・サーバが常駐する同じデバイス上またはその付近に常駐する）。図５は以上の概略を示す。

分散クライアント内の機能はスモール・サーバとスモール・クライアントとに分割される。この分割は移動体デバイスの限られたリソースへの影響を抑えつつ移動体デバイスの「スマートな」性質を利用するように最適化されている。

したがって、移動体デバイス上に常駐するスモール・クライアント（すなわち、この例ではローカル・Ｅメール・アプリケーションと連携して動作するＴｒａｎｓｃｅｎｄ Ｍａｉｌ）は、一般に移動体ユーザのユーザ・インタフェースとして動作し、ローカル・データ記憶として動作し、ある種のデータ処理タスクをローカルに引き受ける。スモール・クライアントはとりわけ以下の機能を引き受ける。
・移動体インボックス内のＥメールのリストを表示する。
・Ｅメール・テキストの本文のビューワとして機能する。
・Ｅメール送信、作成または応答のユーザ要求を受け付ける。
・新しいＥメール・テキストのユーザ入力を受け付ける、
・ユーザ入力に応答して移動体デバイスのメモリからだけＥメールを解放する（解放動作）
・ユーザ入力に応答して移動体デバイスのメモリからＥメールを解放し、同じＥメールをラージ・サーバから解放する通知を生成する（削除動作）。
・ラージ・サーバのログオン・パスワードのエンド・ユーザ入力を受け付けてこれをスモール・サーバに渡す（「分散ログオン」の説明については以下を参照）。
・データの変更（新規、変更または削除エントリなど）についてローカル・データ記憶をモニタし、変更を詳述するイベントを作成し、これらをスモール・サーバに送信する。
・スモール・サーバからイベントを受信し、変更データの詳細を用いてローカル・データ記憶を更新する。

スモール・クライアントが、ＰＩＭと非Ｅメール（例えば、他の種類のメッセージング）機能を処理し、統合する場合、同等のまたは類似のＰＩＭと非Ｅメール機能が処理される。

同様に、スモール・サーバは他の媒体（通常、ラージ・サーバに接続されたＬＡＮ）に常駐し、無線インフラストラクチャ（例えば、ＧＰＲＳ）を横断するデータ・ネットワーク接続を介して移動体デバイスと通信し、一般にラージ・サーバ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅなどの）への直接のインタフェースとして機能し、ラージ・クライアントに普通関連する多数のデータ処理タスクを引き受ける。スモール・サーバはとりわけ以下の機能を引き受ける。
・必要に応じてスモール・クライアント、スモール・サーバ、ラージ・サーバから受信した構成要素を取り出してラージ・サーバＡＰＩに従って移動体ユーザが要求したＥメールの構成を完成する。
・ラージ・サーバからＥメールを受け取り、これらを構成要素部分に分割し、スモール・クライアントにとって絶対に必要な部分のみを送信する。
・スモール・クライアントからの要求に応じて追加のＥメール・コンテンツ（例えば、長文Ｅメールの追加テキストおよび／または添付ファイル）を配信する。
・ログオン・パスワード・データ（スモール・クライアントを介してエンド・ユーザが供給した）を受け取り、これをローカル・メモリ内に保存し、ラージ・サーバへの拡張ログオンを可能にする（分散ログオンの説明については以下を参照）。
・データの変更（新規、変更または削除エントリなど）についてラージ・サーバのローカル・データ記憶をモニタし、変更を詳述するイベントを作成し、これらをスモール・クライアントに送信する。
・スモール・クライアントからイベントを受信し、変更データの詳細を用いてラージ・サーバのローカル・データ記憶の更新を処理する。

スモール・クライアントが、ＰＩＭと非Ｅメール（例えば、他の種類のメッセージング）機能を処理し、統合する場合、同等のまたは類似のＰＩＭと非Ｅメール機能が処理される。

この手法の１つの結果は、ラージ・サーバ上のメールは従来のプッシュ・Ｅメール方式のやり方でデバイスに「送信」または「リダイレクト」されるとは言えないということである。デバイス（スモール・サーバが常駐する）とスモール・サーバとはメール・サーバにとっては別のクライアントにすぎない（また、そのクライアントも単なる無線デバイス・クライアントではない）。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌのスモール・サーバとスモール・クライアントはＭｏｂｉｌｅＭＱ ＭＯＭを介して相互に通信する。上記のように、これによって、スモール・サーバとスモール・クライアント（共に分散クライアント−サーバ・システム内のラージ・クライアントを構成する）が互いに非同期で動作することができる。

スモール・クライアントはさまざまに並べ替えられる。例えば、図６に示すように、スモール・クライアントは、クライアント側ＭＯＭを含むかこれと通信する端末側構成要素として実装できる。スモール・サーバは、サーバ側ＭＯＭを含むかこれと通信するサーバ側構成要素として実装できる。

図７は、スモール・クライアントがプログラム−例えば、Ｅメール・アプリケーション、プラスそれを端末側構成要素にプラグイン・リンクすること−を含む方法を示す。

図８は、スモール・クライアントが連絡先プログラムなどのプログラムも除外できることを示す。端末側構成要素は連絡先データベースを介して連絡先プログラムと通信する（そのデータベースからのイベント・トリガは端末側構成要素に送信される）。図９はこれがミドルウェア・アーキテクチャと概念的に等しいことを示す。

３．２ 分散ログイン
分散クライアントはログイン機能をスモール・クライアントとスモール・サーバとに分割する。スモール・クライアントはエンド・ユーザ入力からユーザ・パスワードを入手する。パスワード入力を受信すると、スモール・クライアントはこのデータをスモール・サーバに送信する。スモール・サーバはこのデータをメモリ内にローカルに保持し、ラージ・サーバにログインを送信する。

したがって、Ｔｒａｎｓｃｅｎｄ Ｍａｉｌはサーバ上の無線端末ユーザのエージェントとして動作する。Ｔｒａｎｓｃｅｎｄ Ｍａｉｌはパスワードをキャッシュに入れ、メール・サーバとの通信時にユーザが通常実行するその他のログイン関連動作を実行する。パスワードがメール・サーバ・アドミニストレータによって満了させられた時だけは、ユーザは新しいパスワードで自分でログインしなければならない。これは、すべてのＥメール・アカウントにアクセス可能なスーパユーザとしてのログインを必要とする他のメール・リダイレクト方法と比較してセキュリティの面で大幅な進歩である。

このようにログインを分散する別の利点は、スモール・サーバとスモール・クライアントとの間の通信が中断しても、これによって分散クライアントが追加のログイン動作（および関連する無線データ・トラヒック）なしにラージ・サーバとの通信を継続できるということである。また、これにより移動体デバイスの所有と使用（自身用のセキュリティ・プロトコルがあってよい）が追加のラージ・サーバのログイン動作の代理として機能することができる。スモール・サーバがパスワード情報を有すると、移動体デバイスの制御がログイン情報の一種の代理として働くという前提に基いて、ラージ・サーバへのログインを複製することが可能になる。これによって分散クライアントはユーザに追加のパスワード・データを促すことなくサービス中断後にラージ・サーバにアクセスすることができる。その結果、ログイン動作に関連するデータ・トラヒックを低減することで利点を提供し、特にパスワード・データを入力するのが不便な小型キーボードを備えた移動体デバイス上での、エンド・ユーザからのラージ・サーバへのアクセスが高速化される。

３．３ リモート・メッセージ構成
また、Ｔｒａｎｓｃｅｎｄ Ｍａｉｌはリモート側でメッセージを構成する方法を使用して無線伝送の使用を最小限にする。分散クライアントがラージ・サーバからメッセージを「受信」すると、このデータの一部はスモール・サーバでキューイングされ、スモール・サーバはこのデータのどの程度の量をスモール・クライアントに送信するか決定する。スモール・クライアントに送信する特定のデータ量はエンド・ユーザ構成と特定の要求に影響される。例えば、エンド・ユーザは最大行数のＥメール・テキストをスモール・クライアントに配信するよう指定でき、ついで、スモール・サーバが追加のテキストおよび／または添付ファイルを送信するよう要求できる。リモート・メッセージ構成は、エンド・ユーザがＥメールに応答するか転送するなどの動作を指示する時に有効になる。添付ファイルを変更せずにＥメールを転送する時には、スモール・サーバはスモール・クライアントから全体を伝送することなく大量のＥメール・メッセージをローカルに構成できる。キューイングされたメッセージはラージ・サーバ（この例では添付ファイル）上に保持された関連する変更されていないデータを参照するだけである。実際、スモール・クライアントはスモール・クライアント・デバイスでユーザが変更したメッセージ部分のみを送信すれば済む。同じ原理がＥメールの応答にも適用される。スモール・クライアントは元のメッセージの本文すべてを送信する必要はない。スモール・サーバは、スモール・クライアントからスモール・サーバに送信される新しいテキストを受信し、これを、ラージ・サーバに記憶されているためにスモール・サーバが認識している元のＥメール・テキストと組み合わせることで応答全体を構成する。実際、スモール・クライアントはスモール・サーバがスモール・クライアントとラージ・サーバとからの全メッセージ受信部分を組み立てる命令を発行している。小型キーボードのスマートホンにとって不要なキー入力がないことは貴重である。これらは両方ともスモール・クライアントとスモール・サーバ間のデータ・トラヒック量を大幅に低減する方法である。

３．４ 整頓プロセス
Ｔｒａｎｓｃｅｎｄ Ｍａｉｌは自動メモリ「整頓」プロセスを用いて移動体デバイス上のメモリを保守する手助けをする。スモール・クライアントは移動体デバイス上の不揮発性メモリの使用をモニタする。使用中の不揮発性メモリがトリガ量（例えば、使用中のメモリの８０％）を超えると、デバイス上のＥメール情報に関連するローカル・データの「整頓」を自動的に開始する。これは長期間アクセスされなかったある種のＥメールを選択してこれらのＥメールに関連するデータ（例えば、添付ファイルとメッセージ・テキスト）の大半をローカル・メモリから解放し、Ｅメールのヘッダ情報をローカル・メモリに保存するステップからなる。ローカル・メモリから解放されるデータは関連するＥメール・メッセージの古さなどのプリセット判定基準（先入れ先出し）またはこのＥメールへのユーザのアクセス履歴を用いて選択される。長期間アクセスされなかったＥメール・メッセージはより新しいまたは最近アクセスされたＥメール・メッセージより先にローカル・メモリから削除される。

関連するメッセージに未読の印が付いているか、ユーザの閲覧または操作のためにのみ開ける、またはラージ・サーバからの追加データを要求するＥメールに関連するペンディング操作がある場合、メッセージ・データはメモリから解放されない。

この削除プロセスはスモール・クライアントが使用中の不揮発性メモリがプリセットの「安全」レベル（例えば、使用中のメモリの７０％）を下回ったと判定するまで継続する。ラージ・サーバはすべてのＥメール・データを保持し、スモール・クライアントはＥメール・ヘッダ・データを保持するため、Ｅメール・データは「削除」されない。

削除されたデータは、ユーザ要求（「取り出し」動作）があればサーバから移動体デバイスに再びダウンロードすることでローカル・メモリ内に戻すことができる。ユーザはそのような取り出しが実行される前に明示的に警告される。これでユーザはメッセージ・データの取り出しがコスト効率が高いか否かを判断できる。

整頓機能は、特に大量のＥメールまたは添付ファイルがダウンロード内容を確認する機会がないのに、整頓のトリガポイントを超えて移動体デバイスから押し出すかもしれない状況を処理する安全機構をさらに備える。言い換えれば、移動体デバイスがＥメール・データをそれが読まれる前に削除する状況を回避する設計になっている。この場合、システムは一時的にメモリ使用のトリガ・レベルと安全レベルを調整して、エンド・ユーザに大量の着信Ｅメールを確認する機会を与える。

３．５ 変換された添付ファイルのダウンロード・オプション
複製データをサーバと共用する移動体デバイス内の恒常的な困難は、ユーザがいかにして移動体デバイスの限られたメモリと処理能力とを最大限に利用するかである。移動体Ｅメール・アプリケーションでは、この問題は従来、（ＭＳ ＡｃｔｉｖｅＳｙｎｃその他で）移動体デバイスと共用するＥメール・データの量を制限することで対処されてきた。この制限は普通、限られた日数のＥメール・データのみを複製し、共用するＥメール・データのサイズを制限するという形式をとる。複製するデータの量を制限する１つの一般的な方法は、移動体デバイス上の複製からＥメール添付ファイルを除くことである。通常、エンド・ユーザは、含まれた配信時間とメモリ・オーバヘッドを受忍すると考えるならば、添付ファイルを要求することができる。その他のシステムも、簡単なビューワ・プログラム上で使用できる制限された形式の添付ファイルのみをユーザに送信する方法を作成している。

Ｔｒａｎｓｃｅｎｄ ＭａｉｌはＥメール添付ファイルを移動体デバイスにダウンロードする２つのオプションをエンド・ユーザに提供する。ユーザが添付ファイルをダウンロードしたい場合は、以下のいずれかをダウンロードできる。
（１）無線端末に常駐する簡単なビューワ・プログラムを用いた表示専用の、元の形式から変換されたより小さいバージョン（例えば、ＭＳ ＷｏｒｄまたはＰＤＦファイルのテキスト・バージョン）、
（２）元の変更されていない添付ファイル、
Ｔｒａｎｓｃｅｎｄ Ｍａｉｌではこれらのオプションはメニュー階層の同じレベルでユーザに提示される。

３．６ ワンタッチ解放
従来の移動体デバイスに古いＥメールがたまり始めると問題が発生する。ユーザが移動体デバイスからこれらのＥメールを「削除」しようとすると、Ｅメールは次の同期化でサーバからも削除される。これは、移動体デバイスのメモリを解放し、サーバにはＥメールを保存しておきたいというユーザの希望を直接に公然と打ち砕く可能性がある。これに対処するため、いくつかの同期化システムはエンド・ユーザに以下のいずれかのオプションを提供する。
（１）移動体デバイスとサーバからＥメールを完全に削除する（本発明では「削除」命令と呼ぶ）
（２）移動体デバイス上に常駐しているＥメールだけを削除し、サーバに変更は加えない（本発明では「解放」命令と呼ぶ）。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌでは。これらのオプションはメニュー階層の同じレベルで提示される。システムによっては、一連の異なるメニュー・レベル内にこれらのオプションを隠すか、削除要求があるたびにエンド・ユーザが実際に完全に削除したいのかまたはローカル・メモリだけを削除したいのかをユーザに尋ねることでこの問題に対処するものがある。これらの解決策は、移動体メールボックスを管理する際の柔軟性が低下し、達成するのに複数のキーの入力が必要なため、いずれもユーザ・フレンドリではない。

３．７ セッション非依存
ＧＰＲＳなどの技術を用いた移動体通信デバイスとのデータ通信は、高レイテンシ、間欠的で中断する通信可能範囲、計測される帯域幅のコストのために、極めて困難になっている。従来の通信方法やプロトコルは、このタイプの環境に十分適してはいない。例えば、ＧＰＲＳなど、無線リンク上でのネットワーク接続を必要とするアプリケーションは、普通、確実なセッション・ベースの接続を提供するＴＣＰ接続を使用する。ただし、ＴＣＰアルゴリズムは有線の比較的低レイテンシの接続用に開発され、「無線フレンドリ」ではない。通信が届きにくい領域では、利用可能な帯域幅が低減し、これが、ネットワークが輻輳し、「バックオフ」であると考えるＴＣＰによって構成される。この純粋な結果は、セルラ無線ネットワーク上のＴＣＰ接続は効率的なトランスポートでないということである。その結果、再送パケットの大きいオーバヘッドが発生し、低速でコスト高のデータ転送となる。さらに、ＴＣＰなどのプロトコルはサーバとの通信「セッション」という概念に依存する。セッションは通常、定義された期間にトラヒックが通過しないと（タイムアウト）、期限切れになる。各々の新しいセッションを確立するには追加のデータ・トラヒックの使用が必要で、また時間を消費する。

ＭｏｂｉｌｅＭＱは生のＵＤＰパケット転送のみを用いるＴＣＰの無線最適化された代替方式を想定する。ＭｏｂｉｌｅＭＱは（１）無線ネットワークを用いる移動体デバイスと（２）そのデバイスと通信するサーバ（無線ネットワークに接続されているか否かを問わず）との間でＵＤＰベースのメッセージを配信し、高レイテンシの間欠的な接続の結果として浪費されたデータ・トラヒックを最小化する。ＭｏｂｉｌｅＭＱはメッセージ伝送プロセス内に高レベルの弾力性を提供し、効果的にメッセージ配信を保証することに主眼を置く。

これは従来の「セッション」という概念に依存しないデータ通信を管理するシステムを採用することで達成される。このシステムは「セッション非依存」である。さらに、本発明はメッセージは宛先デバイスと宛先アプリケーションの両方に正しく配信され、一方で送信されるデータ・トラヒックを最小限にする。これは最小のデータ・トラヒックで高度な弾力性を確保するという新たな利点を有する。

ＭｏｂｉｌｅＭＱは、送信側デバイスと受信側デバイスの両方に常駐するという分散方式で、通常、同じハードウェア・プラットフォーム上の別のシステムからのメッセージ・トラヒックが容易になる。

基本送信ユニットである送信側デバイスは送信側アプリケーション（例えば、Ｅメール・プログラム）からメッセージを入手する。各メッセージはデータ・トラヒックを最適化するためにサイズが制限される。送信側アプリケーションがシステムにメッセージを送信するよう依頼すると、システムは最初にメッセージを送信側デバイスのローカルの不揮発性メモリ内に存続させる（記憶する）。これで送信側デバイスがリセットされても、メッセージは生き残る。次いでメッセージは圧縮されて任意選択として暗号化される。

次いでメッセージは送信のためにセグメント化される。各セグメントは各々のパケットが、低帯域幅で高レイテンシのネットワークの基本トランスポート・プロトコルに関連する比較的短いバイト長を越えないという意図でＵＤＰパケット内に配置される。ＧＰＲＳ環境内の通常の実施形態では、ＵＤＰパケット長はＧＰＲＳパケットの通常の最大ペイロードである１５００バイトに制限される。そうでなく、ＵＤＰパケットが例えば２ＧＰＲＳフラグメントを占めるとした場合、１つのＧＰＲＳパケットの障害があると両方のＧＰＲＳパケットを再送しなければならない。ＭｏｂｉｌｅＭＱはメッセージをスケーリングしてベアラ・パケットのメッセージに合わせることでこれを回避する。

３．８ フロー制御
セグメント・サイズと伝送速度の両方は送信側デバイスの着信と発信トラヒックを分析し、伝送のコスト効果を上げるために伝送速度と伝送ビットの最大数を平衡させるフロー制御によって制御される。ＵＤＰパケットは受信側デバイスによってどの順序でも受信でき、受信側デバイスは各パケットの受信に続けてパケット確認応答を送信する。送信側デバイスがパケットのパケット確認応答を受信しない場合、フロー制御システムは合理的な期間が経過するまでパケット伝送を遅延させる。遅延の正確な長さは、送信側デバイスでフロー制御システムが観察するネットワーク応答時間に依存する。遅延期間とパケット・サイズは両方共観察された返送時間の変化に基いて連続的に再計算される。パケット確認が事前定義された時間内に受信されると、フロー制御はデータ速度を最大まで漸進的に増加させる。

また、フロー制御システムはデータ伝送デバイスでしばしば使用される「セッション」と「タイムアウト」の通常の概念の代替物としても機能する。通信デバイスの１つが重大なコネクティビティ障害（例えば、無線基地局の範囲外に移動する場合、またはローミング・ネットワーク間を移動する場合）に陥った場合、フロー制御機構はこれを徐々に遅くなるネットワーク応答と解釈し、それに応じて伝送速度を逓減する。サービス停止が継続する場合、フロー制御は「再試行」間の期間を長くし続ける。この純粋な効果は、送信側デバイスが受信側デバイスから返送トラヒックの受信を開始するまで伝送努力がほぼ完全に停止するということである。受信側デバイスから送信側デバイスに戻る応答パケットの数が増えるにつれ、プロセスは逆転する。すなわち、フロー制御システムは「ウェークアップ」を開始し、パケット送信をより積極的に行おうとする。接続がより堅固に再確立されると、伝送速度は合理的に理想的なレベルに達するまで再び増加し、パケット損失を厳格に制限する必要と共に全体の速度を平衡させる（損失パケットはネットワーク送信料金を引き起こすおそれがある）。こうして、ＭｏｂｉｌｅＭＱは「セッション」の概念に依存せず、「タイムアウト」という概念を認識しない。

メッセージを構成する全パケットの受信に続いて、受信側デバイスは全メッセージを受信した旨の短い確認応答を送信する。このメッセージ確認応答が送信側デバイスに到達すると、送信側デバイスは、個々のパケット確認応答が送信側デバイスに送信または送信側デバイスで受信されなくでも、メッセージを構成するパケットの再送を以後行わない。これは主としてデータ・トラヒックの量を制限するためである。メッセージ配信シーケンスはまだ完了していない。

メッセージ受信の確認応答を送信すると、受信側デバイスはメッセージを関連する宛先アプリケーション（Ｅメールなど）に渡す。次いで受信側デバイスは該当メッセージが受信され、受信側アプリケーションによって採用された規則のセットに従って処理されたことを示す宛先アプリケーションからの信号を待つ。本発明では、受信側アプリケーションは受信メッセージを処理してシステム・リセットなどの受信側デバイスの停止があっても消失しないようにする。ＭｏｂｉｌｅＭＱからメッセージを取り出せない状態で受信したことに受信側アプリケーションが満足すると、受信側アプリケーションはメッセージ「消費」という最終確認で応答する。受信側アプリケーションからのこの最終確認によって、ＭｏｂｉｌｅＭＱの受信側デバイスは送信側デバイスに短い「メッセージ消費」確認応答を送信する。

送信側デバイスは、「メッセージ消費」確認応答を受信すると、この情報を送信側アプリケーションに転送し、送信側アプリケーションから次の利用可能なメッセージを送信する準備をする。こうして、ＭｏｂｉｌｅＭＱは送信側アプリケーションからの追加のメッセージ・トラヒックを受け付ける前の全メッセージの配信を保証する。

ＭｏｂｉｌｅＭＱは複数のアプリケーションからのメッセージを同時に処理できるが、同じアプリケーションからのメッセージは一度に１つのメッセージしか処理しない。

３．９ イベント・ベースのデータ複製
サーバと移動体デバイスとの間の同期化は、従来、比較的高い帯域幅、低レイテンシ、計測されないコネクティビティ（例えば、ＵＳＢまたはＩＲ）を用いて実行されている。その結果、同期化システムは大量のデータを送信し、送信中にデータ損失が発生したり基本伝送が中断した時にあまり堅牢でない方法を使用することが多い。例えば、サーバ・ベースのデータセット同期化は、通常、すべての接続されたデバイスがその全データセット（例えば、すべてのＥメール、すべての連絡先など）を単一のセッションでサーバにダウンロードすることを要求し、サーバは、マスタ、すなわち、すべてのその他のデータセットを更新するために最後の完全に同期化されたデータセットのマスタ・コピーとの比較を実行できる。この手法は、必要な消費電力、潜在的に長い接続時間、高コストのデータ転送が理由で、無線デバイスの同期化にとっては魅力的でない。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌでは、無線デバイスがその全データセットをダウンロードする代わりに、データセットの変更（または新しい「イベント」）のみをログ（これに限定はされないが、好ましくは時間シーケンスの）に記録し、サーバ接続時にこれらのイベントのログをサーバに送信する。イベントは従来の同期化エンジンを必要とせずにデータ複製を実行できるための詳細を提供する。データ複製は、同期化のためのスモール・サーバの同期化エンジンによって記憶されたデータのデータセット一式（またはデータセットのサブセット）ではなく、「イベント」を送信することで簡単に達成される。

デバイス上のレコードの変更がなされる場合（例えば、新しいメールが作成されてデバイスから送信される、古いメールが削除される、新しい連絡先が作成されるなど）、このイベントまたは変更を定義するエントリがデバイスのタイム・シーケンシャル・ログ内に記憶される。このイベント・ログは、接続が存在するまで記憶される。接続がなされると、ログのコンテンツはサーバに送信され、サーバは該当データセットのマスタ・コピーを更新する。例えば、イベントは「削除レコードｎｏ．ｘ」またはレコード「ｚ」の削除フィールド「ｙ」である。これは受信者がイベントを生成した送信側での変更を複製するのに十分な情報である。

デバイスは、データセット全体が送受信されている間に変更されたレコードを決定するか単一のセッションの保守を確実にするためにデータセット全体を検索する必要はない。サーバ上のデータセットのいかなる変更（例えば、新しいメールの受信）もイベント・ログとして記憶され、ログはＭｏｂｉｌｅＭＱを用いて無線デバイスに送信される。比較的小さいイベント・ログだけが生成され交換されるので、ＣＰＵやデータ転送のオーバヘッドは従来の同期化機構よりはるかに小さい。

したがって、複製するデータが入力、変更、または削除されると（ラージ・サーバまたはスモール・クライアント上で）、送信側デバイスは「イベント」を作成し、送信側デバイス上に記憶する。

イベントは受信側デバイスに１つまたは複数のメッセージとして送信される。メッセージは、より前からあるＴＣＰではなくＵＤＰパケット転送を用いて送信される。ＴＣＰが確実な接続を提供し、現在商業活動の中心にある一方、無線通信が届きにくい時によく起こり、再送パケットの大きいオーバヘッドが発生し、低速でコスト高のデータ転送となる観測されたネットワーク輻輳時に宣言されたバックオフのため、ＴＣＰは（上記に説明したように）効率的な無線トランスポートではない。効率化のため、ＵＤＰが使用され（上記を参照）、ＵＤＰパケット・サイズはＧＰＲＳで利用可能な伝送パケット・サイズのすぐ下の１４００バイトに制限される。

受信側デバイスはイベントを定義する個々のメッセージを該当する宛先アプリケーション（Ｅメール・プログラムなどの）に渡す。次いで送信側デバイスはイベントを定義する該当メッセージが受信され、受信側アプリケーションによって採用された規則のセットに従って処理されたことを示す宛先アプリケーションからの信号を待つ。本発明では、受信側アプリケーションは受信メッセージを処理してシステム・リセットなどの受信側デバイスの停止があっても消失しないようにする。メッセージを取り出せない状態で受信したことに受信側アプリケーションが満足すると、受信側アプリケーションはメッセージ「消費」という最終確認で応答する。受信側アプリケーションからのこの最終確認によって、受信側デバイスは送信側デバイスに短い「メッセージ消費」確認応答を送信する。

送信側デバイスは、「メッセージ消費」確認応答を受信すると、イベントが受信側デバイスで安全に受信され「消費される」までイベントを定義するすべてのメッセージの処理を繰り返す。次いで送信側デバイスは送信側デバイスのメモリから［イベント命令情報？］を削除することで「イベント」プロセスを終了する。送信側デバイスはイベント・ログまたはキュー内のすべての他のイベントについてこのプロセスを繰り返す。

こうして、Ｔｒａｎｓｃｅｎｄ Ｍａｉｌは、送信側アプリケーションからの追加のメモリ・トラヒックを受け付ける前のメッセージ全体の配信を保証する。複数のアプリケーションからのメッセージは同時に処理できるが、同じアプリケーションからのメッセージは一度に１つのメッセージしか処理しない。

こうして、不確実なＵＤＰを使用していても、イベント全体を無線リンク上で確実に送信できる。

３．１０ Ａ／Ｂ／Ｘフラグ
システムはまた、各メッセージを３つの状態オプション、すなわち、Ａ，Ｂ、またはＸを備えたフラグで符号化することでメッセージ送信の複製を防止する。通常動作では、［アプリケーションからの］各メッセージは送信側デバイスによってＡまたはＢフラグを交互に立てて送信される。受信側デバイスがメッセージの受信を開始すると、受信側デバイスはローカル・メモリ内にＡまたはＢフラグを書き込む。送信側デバイスからメッセージ全体を受信し、消費信号を宛先アプリケーションから受信すると、受信側デバイスは処理したばかりのメッセージの識別をローカル・メモリ内に書き込み、次いでメッセージ終了／消費確認応答を送信する。受信側デバイスがメッセージ終了／消費確認応答信号の送信後、返送される確認応答の受信前にリセットすると、メッセージ消費が受信されたか否かを確認できない。ただし、所与のメッセージに関連する確認応答のシーケンスに１つのタイプのフラグを付与すると、該当確認のため返送される確認応答がフラグに一致しなければならないことを認識する。異なるフラグの確認応答は次のメッセージに関連しなければならず、したがって、実行してはならない。

フラグＸはこのフラグを無視するように受信側デバイスに知らせる。受信側デバイスのメモリ内にはフラグは書き込まれない。これは、送信側アプリケーションが複製メッセージ送信の危険に関心がない場合に送信側アプリケーションがＸフラグを使用するためである。

３．１１ クライアント・デバイス・アドレッシングとネットワーク更新
多数の現在の移動体データ・ネットワーク（ＧＰＲＳを用いるネットワークなど）上の移動体デバイスにデータを送信することは移動体デバイスが固定ＩＰアドレスを有しないために困難である。移動体デバイスがネットワーク（ホーム・ネットワークまたはローミング・ネットワーク）に接続する時には、ネットワーク運用会社はＩＰアドレスを動的にデバイスに割り当てる。さらに、この動的に割り当てられたアドレスは、普通、私設ＩＰアドレスであり、公衆インターネット上で直接使用できない。デバイスからのデータ・トラヒックはネットワーク運用会社によってネットワーク・アドレス変換機能（ＮＡＴ）にルーティングされ、ＮＡＴは私設ＩＰアドレスを公衆ＩＰアドレスと、公衆アドレスの極めて制限されたリストから引き出された一時ポート番号と、ネットワーク運用会社が使用できるより大きいブロックの一時ポート番号（普通、数千件）とに割り当てる。

したがって、移動体デバイスが同じ動的に割り当てられたＩＰアドレスと一時ポート番号とを長い期間（例えば、何時間も）保持している場合でも、移動体デバイスはネットワーク運用会社によって割り当てられた複数の「公衆」ＩＰアドレスと一時ポート番号を利用することができる。さらに、移動体デバイスはネットワーク運用会社によって割り当てられた私設ＩＰアドレスを認識しているが、ＮＡＴによって割り当てられた公衆ＩＰアドレスと一時ポート番号のレコードの記録を有しない。移動体デバイスと通信している任意の相手側からは、ＮＡＴによって割り当てられた公衆ＩＰアドレスと一時ポート番号しか「認識」できない。所与のデバイスに関連する最後に知られている公衆ＩＰアドレスと一時ポート番号が数分間を超えて有効である保証はないので、そのようなネットワークを使用する移動体デバイスに送信するデータ・メッセージを発信して送信しようとする当事者にとって、これは重大な課題である。

ＭｏｂｉｌｅＭＱはスモール・サーバにネットワーク・アドレス・データを定期的に提供してスモール・サーバから移動体デバイスへの定期的なメッセージ送信を可能にする。実施形態の例はオフィスのＥメール・サーバが移動体ユーザの介入なしに移動体ユーザにＥメール・トラヒックを送信できるようにする処理を含む。

この方法は、以下のイベントのいずれかが発生すると移動体デバイスからスモール・サーバに極めて短いメッセージ（「ネットワーク更新」）を送信するステップを含む。
・移動体デバイスが最初に電源オンになり移動体ネットワーク運用会社からアドレスを獲得した時
・移動体デバイスが移動体ネットワーク運用会社から新しいアドレスを獲得した時（おそらくは、移動体デバイスをホーム・ネットワークメッセージ通信範囲からローミング・ネットワークに移動した結果、またはローミング・ネットワーク間で移動した結果）
・介入ＮＡＴによって割り当てられている可能性がある新しい公衆アドレスと一時ポート番号を獲得する努力で定期的に移動体デバイスに新しいアドレスが割り当てられているか否かに関わらず、この新しい公衆アドレスと一時ポート番号をスモール・サーバに通知する。

短いネットワーク更新メッセージを受信すると、スモール・サーバはパケットの発信ＩＰアドレスと一時ポート番号（関係する当事者が同じ私設ＩＰネットワークに直接接続されていないという前提で、ＮＡＴからの割り当てられた公衆ＩＰアドレスと一時ポート番号）とを書き止め、この情報を逆ルックアップ・テーブルに入力する。

ネットワーク更新メッセージはデータ・トラヒックが計測ベースで課金されるという前提で意図的に短くなっている。代表的な実施形態は移動体デバイスによって送信されるわずか１７バイトのデータと各ネットワーク更新メッセージ周期で返送される５バイト（パケット損失がないものとして）とを含む。

これらのメッセージ周期の各々は、以下を確認する。
（１）公衆ネットワーク・アドレスの連続する有効性
（２）移動体デバイスを用いてトラヒックを受信できること

次いでスモール・サーバは、割り当てられた公衆ＩＰアドレスと一時ポート番号がネットワーク更新メッセージの時点から再度割り当てられていないという前提で、逆ルックアップ・テーブルで見つかったデバイスの最新のアドレスを用いて移動体デバイスでスモール・クライアントへのデータ送信を、促されることなく、自ら試みることができる。したがって、スモール・サーバ側でのデバイスからのネットワーク更新メッセージの受信は、イベント・ログ内にキューイングされたあらゆるイベントの送信開始をトリガするものである（３．９項、イベント・ベースのデータ複製を参照）。システムはネットワーク更新メッセージを受信した時点でログ内にあるイベントのみを送信するように構成できる。その後のイベントは次のネットワーク更新メッセージ受信まで待たなければならない。これは連続プッシュ・Ｅメールとは異なる。

逆ルックアップ・テーブル内のエントリも時限式で、一定量を超える時間が経過すると、スモール・サーバは新しいネットワーク更新メッセージを受信するまでスモール・クライアントへのメッセージ送信は不可能であると考える。この場合、スモール・サーバからの発信メッセージは新しいネットワーク更新メッセージを受信するまでキュー内に保持される。時間は、ＮＡＴが公衆ＩＰアドレスを移動体デバイスに再割り当てするために使用する通常の間隔よりかなり短く設定する（例えば、ＮＡＴ再割り当て間隔が２０分なら５分）。システムは、はるかに短いＮＡＴ再割り当て間隔に合わせてネットワーク使用率が高くなった時に時間を短縮できるように、時間を動的に調整する。

まとめて考えると、これは、スモール・サーバとスモール・クライアントとが、スモール・サーバがスモール・クライアントにトラヒックを送信できる時間ウィンドウを確立することができることを意味する。このウィンドウはネットワーク更新メッセージの時点で開始し、事前プログラミングされた空き時間が満了すると終了する。例えば、ネットワーク更新メッセージがスモール・クライアントによって６０分ごとに送信され、空きタイムアウトが１０分に設定されている場合、６０分以上の周期で繰り返す１０分間の通信ウィンドウが表示される。ネットワーク更新メッセージの周期を増加させることで、スモール・クライアントはスモール・サーバの連続的な通信伝送機会を多少作成することもできる。

３．１２ セキュリティ
安全でないデータ通信インフラストラクチャ（ＳＳＬなどの）上での安全なエンドツーエンドの通信を保証する既存のセキュリティ方法は、高プロセッサ・オーバヘッド、高帯域幅オーバヘッド、高レイテンシ、アドレッシング情報の移動体デバイスへの動的割り当てを含むいくつかの要因により、無線データ通信環境にはあまり適していない。

ＭｏｂｉｌｅＭＱは、移動体通信デバイス専用に設計された暗号化態様を用いて移動体デバイスとサーバ間の安全なエンドツーエンドのメッセージングを提供する。

このプロセスは、システムが最初に移動体通信デバイスにインストールされた時に開始する。移動体デバイス（例えば、無線ネットワークに接続された移動体Ｅメール読取装置）とサーバ（例えば、有線インターネット・サービスに接続された企業Ｅメール・サーバ）は共に共用秘密情報をロードされる。それらの間のメッセージを安全にするために、送信側デバイス（移動体通信デバイスまたはサーバ）は最初に以下の入力からハッシュ値を計算するハッシュ関数を用いてメッセージ・キーを計算する。
・該当する移動体デバイスに一意のコード、例えば、ＧＳＭ電話ハンドセットのＩＭＥＩコード（移動体デバイスが送信側デバイスの場合、それ自体の一意のコードを使用し、サーバが送信側デバイスの場合、所期の受信側デバイスの一意のコードを使用する）。
・共通秘密鍵
・各メッセージに関連する（ただし必ずしも一意ではない）送信側デバイスと受信側デバイスとが個別に計算できる追加データ（すなわち、カウントアップ・メッセージ番号、アプリケーション／ポート番号、セッション番号）

次いでこのキーを対称暗号化アルゴリズム内で用いてメッセージを暗号化する。各メッセージは個々の移動体デバイス識別コードに数学的に関連するキー・シーケンスと、移動体デバイスとサーバとにインストールされた共通秘密鍵と、各メッセージに数学的に関連する送信側デバイスと受信側デバイスの両方から別々に引き出すことができる追加データとを用いて暗号化される。

暗号化メッセージの信憑性と完全性を保証するため、送信側デバイスは、入力がメッセージ自体とメッセージを暗号化するために使用したキーである暗号化ハッシュ関数を用いてメッセージ認証コード（「ＭＡＣ」）を計算する。結果として得られたＭＡＣは暗号化メッセージに付加される。

受信側デバイスは該当メッセージの第１のハッシュ関数（キー）を計算し（移動体デバイスが知っている移動体デバイスの一意のコード番号、共通秘密鍵、追加トラヒック・データに基いて）、このキーを用いてメッセージを解読する。最後に、受信側デバイスは解読されたメッセージとキーを受信し、これらを用いてメッセージに付加されたＭＡＣとの比較のための第２のハッシュ値を計算する。第２のハッシュ値がメッセージと共に受信したＭＡＣと同一の場合、メッセージは真正で変更されていないと判定される。逆に、受信側デバイスによって計算された第２のハッシュ値がメッセージと共に受信したＭＡＣと一致しない場合、受信側デバイスは安全な通信を確立しようとして送信側デバイスにチャレンジを発行する。セキュリティが確立すると、メッセージの再送がトリガされる。認証システムはバックアップ・ロールで動作し、メッセージのデータの完全性を保証する。送信時にビット誤りがあればＭＡＣ、セキュリティ・チャレンジ、メッセージ再送が無効になる。

メッセージ自体の機密保護、信憑性、完全性の保証に加えて、セキュリティ・システムは、第三者が適正の移動体デバイスのユーザになりすまそうとした場合の移動体デバイスのユーザに与えるコストとパフォーマンスの影響を低減するように働く。

スモール・サーバは移動体デバイスに割り当てられた最近報告されたアドレス（および一時ポート番号）を備えた逆ルックアップ・テーブルを維持する（３．１１項、ネットワーク更新を参照）。スモール・サーバは移動体デバイスからのすべての着信データ・パケットが、スモール・サーバの逆ルックアップ・テーブルにリストされたデバイスの現在有効なアドレスと一時ポート番号に一致するアドレスと一時ポート番号から発呼されたものという前提で動作する。

同じ移動体デバイスから発呼されたとされているが新しい返送アドレス（および／または新しい一時ポート番号）を有するデータが受信された場合、スモール・サーバは、上に概説した同じ暗号化機構を用いて新しいアドレスのデバイスにセキュリティ・チャレンジを発行する。新しいアドレスがチャレンジに対して正しい応答を返すと、スモール・サーバは新しいアドレスからの着信トラヒックの処理を継続し、逆ルックアップ・テーブルを新しいアドレスで更新する。これは、一般には、移動体デバイスに通知される変更がすでにネットワーク更新メッセージをトリガしたため、移動体デバイスが変更を認識しない（例えば、ネットワーク運用会社のＮＡＴボックスがそのような割り当てを行った場合）ような形で移動体デバイスが新しいアドレスまたは一時ポート番号を割り当てられている場合にのみ実行される（３．１１項、ネットワーク更新の説明を参照）。

逆に、新しいアドレスがセキュリティ・チャレンジに正しく応答できない場合、スモール・サーバは逆ルックアップ・テーブルを更新せずに新しいアドレスから受信したデータを単に無視する。（これは、例えば、悪意の第三者がスモール・サーバにスプーフ・データ・トラヒックを送信することで適正な移動体デバイスとの通信を中断しようとした時に実行される。）適正なデバイス（旧一次ポート番号を備えた旧アドレスの）との通信は中断せず継続し、旧アドレスへの追加のチャレンジを用いてセキュリティを再確立する必要はない。スモール・サーバからスモール・クライアントへの不要なデータ・トラヒックは生成されない。多くのＧＰＲＳおよび／またはＵＭＴＳ料金では、ユーザのコストは受信したデータ・トラヒック量に依存するので、スモール・サーバでのサービス拒否攻撃を防止できることは極めて貴重である。

セキュリティ・チャレンジと応答は比較的大量の処理時間とデータ転送を使用するため、このシステムは適正なユーザに大きなコストとパフォーマンスの利益をもたらす。

３．１３ 端末アプリケーション・ロック
移動体通信端末（ＧＰＲＳを用いる「スマート」ホンなど）はデバイスのユーザとその基本的な通信サーバ（雇用者が運用するビジネス・Ｅメール・サーバなど）として動作する組織にある種のセキュリティ・リスクを提示する。デバイスの被害の結果、通信アプリケーション（Ｅメール・クライアント・アプリケーションなど）への無権限のアクセスが発生することがあり、エンド・ユーザとバックグラウンドのサーバ機能を提供する組織の両方にマイナスの結果が生じることがある。現在、このセキュリティ・リスクはさまざまなシステムによって扱われ、（１）移動体デバイス自体へのローカル・アクセスのロック−一般にエンド・ユーザの要求による、（２）移動体オペレータの手でデバイスとの通信を拒否する、（３）メイン通信サーバへのリモート・アクセスを拒否する、といった処理が行われる。第１の方法は、デバイスのロックの結果、エンド・ユーザがデバイスに常駐する他のアプリケーションにアクセスできなくなることがあるのでエンド・ユーザにとって不便である。第２の方法は移動体運用会社による阻止命令の迅速で適切な実施形態に依拠する。これは、無線ネットワークとの認証が移動体デバイスから独立して実行される状況（ＳＩＭカードを使用するＧＳＭネットワークなど）ではさらに制約がある。すなわち、デバイスの所有者はローカルな常駐データに依然としてアクセスできる。第３の方法は、組織サーバへのアクセスしか阻止せず、移動体デバイスにローカルに常駐するデータへのアクセスは無効にしないため、欠陥がある。

Ｔｒａｎｓｃｅｎｄ Ｍａｉｌは指定された状況で通信アプリケーション全体の動作を「ロックして」、移動体デバイスからのトラヒックを一般に搬送する無線ネットワーク運用会社による介入を必要とせずに、エンド・ユーザとそれに対応する通信サーバを収容する組織の両方を保護する。

移動体デバイス上の関連する通信アプリケーションへのアクセスは、エンド・ユーザが適当なロッキング・コードを移動体デバイスに入力した後でのみ進行できる。システムは最小コード長を指定できるが、別の方法でエンド・ユーザがロッキング・コードを変更できるようにすることもある。組織アドミニストレータ（Ｔｒａｎｓｃｅｎｄ Ｍａｉｌサーバも管理する）はリモート・ベースでロック・コードを変更し、エンド・ユーザがコードを忘れた場合、またはデバイスが紛失したかまたは盗難にあった場合にコードのリセットができるようにする。これによって、エンド・ユーザまたはネットワーク運用会社ではなく組織の制御下で、デバイスに常駐するＥメールとメール・サーバが保護される。これは決定的な違いである。

ロック状態では、アプリケーションのロックは適当なロック・コードを移動体デバイスに入力することで非活動状態にすることができる。

ロック・コードが移動体デバイス上にローカルに記憶されている場合、以下の入力に基いて暗号化ハッシュ値を用いて記憶できる。
・移動体デバイスのための一意的なデバイスＩＤ（ＧＳＭハンドセット上のＩＭＥＩコードなど）
・秘密鍵
・アンロック・コード

こうして、１つのデバイスからハッシュ値を単に取り出して別のデバイス上のハッシュ値を置き換えることで簡単にロックを破ることはできない。

アンロックされた後で、アプリケーション・ロックは以下のようないくつかの異なるイベントによってトリガされる。
・アプリケーションにアクセスしない時間の経過（事前定義された空き時間）
・システム・アドミニストレータによるロック・コードのリモート変更
・エンド・ユーザがアプリケーションのロックを要求
・移動体デバイスまたは該当するアプリケーションが何かの理由で再ブートまたは再起動された
・アプリケーションをロック状態にさせるリモート・メッセージ

アプリケーションがロック状態の場合、エンド・ユーザはローカル・データにアクセスできず、またリモート・サーバにもアクセスできない。

付録１
付録１は、ＭｏｂｉｌｅＭＱとＴｒａｎｓｃｅｎｄ Ｍａｉｌシステムに関連するさまざまなその他の論点をリストし、論じるものである。ＶｅｇａはＴｒａｎｓｃｅｎｄ Ｍａｉｌの旧名である。

１．異なるカテゴリのメッセージの独立した配信
説明
ある種のメッセージ・タイプがよりタイムリな形で配信されるような異なるタイプのメッセージの異なる送信「チャネル」の使用
・新しいメッセージ・チャネル
・追加の本文テキスト・チャネル
・添付ファイル・チャネル
これらのチャネルの使用は、新しいＥメールが添付ファイルと本文テキストが取り出されているか否かに関わらず部分的に配信できることを意味する。

分析
この概念は異なるアプリケーションに関するデータの別々の転送に使用されている。例えば、Ｅメールは連絡先またはカレンダのチャネルとは別のチャネルを有し、共通の多重化技術である。

ただし、この技術を用いて従来技術の単一のアプリケーション内で通信をスピードアップできるという証拠はない。

この技術を使用する利点は、大容量のＥメールを送受信することで、大容量のメッセージのバックグラウンド転送と同時に実行されるより短いメッセージとの対話が阻害されることがないという点である。一定のサイズを超えるメッセージは異なるメッセージ・チャネルによって転送でき、より短いメッセージ用の別のチャネルの帯域幅を求めて等しく競合する。したがって、大容量のＥメールの送信後に送信を始めた小容量のＥメールは大容量のＥメールの前に配信を完了することがある。極めて大容量のＥメールの場合は、これは、小容量のＥメールへの応答が大容量のＥメールの配信完了前に受信されたという意味の場合もある。ただし、現在の多くのＥメール・システムではサイズに関わらずＥメールをキューイングするので、これはありえない。

メール・システムによっては、メールごとに１回ずつ、メール・リレーへの同時接続を行う。ただし、サイズに基くメールの「ソート」は行われない。

２．「マジック」Ｅメール・アドレス
説明
サーバによって、解決されたＥメール・アドレスに変換される識別子文字列の使用。これは以下の２つの局面を有する。
・「応答」または「転送」Ｅメール内の文字列＜ａｌｌ＞はＶｅｇａサーバによって、元のＥメールに復帰して新しいメッセージの「Ｃｃ」フィールドにメッセージのすべての受信者を追加するコマンドと解釈される。
・端末上のＥメールへの「愛称」の追加。Ｅメールを送信する時、有効なＥメール・アドレスに一致しないすべての文字列は交換機内のアカウント名と比較され、一致すると、その名前はそのユーザのＥメール・アドレスに解決され、そこに配信される。

分析
以前のＥメールのコンテキストによって変わる意味を持たせるためにＥメール・アドレスの代わりに固定文字列を使用することはおそらく新しい方法である。

そのような文字列の使用は、サーバが認識している何らかの以前のＥメールの内容に基いて新しいＥメールのアドレッシングをするようサーバに指示する「コマンド」を効果的に構成する。この場合、コマンドは「ｒｅｐｌｙ ｔｏ ａｌｌ」、「ｃｏｎｔｅｎｔ」は以前のＥメール内のＥメール・アドレスのリスト、「ｐｒｅｖｉｏｕｓ ｅｍａｉｌ」はクライアントが応答するＥメールである。アドレスのリストもＥメールそれ自体もこの概念が有効になるためにクライアント上に常駐する必要がない。以前のＥメール（ヘッダなど）を参照して、クライアントがそのＥメールへの一種のハンドルを有するようにすればよい。

受信者への配信に先立ってクライアントまたはサーバによって解決されるＥメール・アドレスの代わりに短い名前（または「愛称」）を使用することは一般に可能である。ただし、これは無線の分散クライアント空間内では新しい概念である。

３．イネーブル／ディセーブル
説明
リモートの相手側エンドでのキューに影響を与えずにローカル・キューイングを使用不可にする機能。

分析
この機能の目的は、ピアが片方向または双方向のイベントの同期の加入を一時的に停止することを可能にすることである。これは、１つ、それ以上、またはすべてのチャネルに適用できる。

この例は以下を含む。
・ローカル保守（例えば、不要な項目の削除、ＰＣとのローカルの有線による同期化）を行いながら、リモート・エンドを同期化する過剰なトラヒックを生成するはずであったユーザによる連絡先の同期化を停止する。
・コスト制御または濫用防止のためのアドミニストレータによるユーザごとのサービスの停止。

４．スケジューリングされたキューへの追加
説明
項目を直ちに送信せずに送信のためにキューイングする操作ができる機能。Ｖｅｇａが使用不可の時のＥメール作成など。ソフトウェアはＶｅｇａが再び使用可能になるまでメッセージを送信しない。

分析
この機能は有線と無線のＥメール・クライアントにとっては目新しいものではない。ただし、無線の分散クライアント空間内では新しい概念である。

５．自動／手動モード動作
説明
自動および手動接続モードを切り替える機能。

分析
外見ではこの機能は有線と無線のＥメール・クライアントにとっては目新しいものではない。ただし、この機能には調査を保証する側面がある。

この機能は、ユーザが定期的にメールをチェックし、またはユーザ・インタフェースでボタンを押すのに応答してメールをチェックできるＯｕｔｌｏｏｋ Ｅｘｐｒｅｓｓに概念が似ている。

ただし、そのようなシステムは、タイマの満了時またはユーザ・インタフェースによる起動によって明示的なポーリングが実行されるポール・システムである。Ｖｅｇａでの機能は、時限オプションまたは手動起動が項目をプッシュインできる事前定義された期間だけ「ゲートをオープンする」ということを指しているプッシュ・ソリューションに適用される。この概念は無線の分散クライアント空間では新しい。

６．インライン添付ファイル交換
説明
添付ファイルの「プレースホルダ」を実際の添付ファイルが取り出せなかった理由を述べた管理メッセージと差し替える機能。

分析
この機能は、Ｅメール・サーバは目新しいものではない。例えば、いくつかのサーバ側ウィルス・スキャナはウィルス感染のために添付ファイルを送信しなかった理由を述べるＥメールの本文テキスト内に管理メッセージを表示する。

ただし、無線の分散クライアントに添付ファイルを送信しない理由は多い。

いくつかの理由は選択的である。
・サイズがアドミニストレータが設定したサイズを超えている。
・ユーザは添付ファイルをダウンロードできない（例えば、コスト管理の理由から）

いくつかの理由は状況的である。
・添付ファイルが端末に適合せず、サーバが変換できない。
・添付ファイルがウィルスに感染している。
・添付ファイルが以前に削除されている。

７．リモート添付ファイル表現
説明
添付ファイルがＥメールに物理的に添付されておらず、最終的な配信前に添付されるということを示すための添付ファイル表現の表示。送信されるフォルダでは、その添付ファイルのローカル・コピーを保持する必要がなく、添付ファイルが送信されたという表現。

分析
外見ではこの機能は有線と無線のＥメール・クライアントにとっては目新しいものではない。
この機能は添付ファイルの存在を表示するために、ペーパークリップまたは他のアイコンを示すいくつかのＥメール・クライアントの機能に似ている。ＩＭＡＰ４クライアントでは、添付ファイルは実際に存在していなくてもよいし存在していてもよい。

ただし、この機能は無線の分散クライアント空間では新しい。添付ファイルの存在または不存在についての説明の本文テキストの異なるアイコンまたはローカルな包含によって表示と組み合わされた場合には特にそうである。

８．Ｅメール受信者リストの切捨て
説明
各受信者について解決されたＥメール・アドレスを送信する必要がないＥメール・メッセージの追加の受信者の数の表現。

分析
この機能は無線の分散クライアント空間では新しい。
分散リスト内のユーザの数が一定のカウント（例えば、１０）を超えると、メールの受信者はおそらくリスト内の実際の個々のユーザには興味がない。したがって、データ量はＥメール・ヘッダ内の他の受信者の名前とＥメール・アドレスを含めないことで低減できる。これに代えて簡単なテキスト（例えば、「他の受信者３８」）で置き換える。要求があれば受信者の完全なリストがダウンロードできる。

この特別のテキストは、ユーザの「ｒｅｐｌｙ ｔｏ ａｌｌ」の権能に影響しない。これは、実際のＥメールではサーバは実際のアドレスを認識しているからである。

９．セキュリティが絡む場合に内容を非表示にする
説明
代替表示を用いて画面上のユーザ・データを非表示にする機能。これは端末が「Ｐａｓｓｗｏｒｄ ｃｈａｌｌｅｎｇｅ」または「Ａｐｐｌｏｃｋｅｄ」状態を入力すると全ユーザ・データを非表示にする機能である。

分析
この機能は無線の分散クライアント空間では新しい。
この機能の目的は、認証を受けた人物がセキュリティ・チャレンジを完了するまで特権的な情報を非表示にすることである。画面情報の窃取を防止することを主眼とする。

１０．インテリジェント・ユーザ作成リスト
説明
Ｖｅｇａアカウント作成に適したユーザのリストをアドミニストレータに提供する機能。実際、Ａｃｔｉｖｅディレクトリを選択し、どのサーバを使っているか、またＶｅｇａアカウントがそのユーザについてすでに存在するか否かによってユーザをソートすることを意味する。結果リストは（「Ｎｅｗ Ｕｓｅ」ＵＩに表示される）はＶｅｇａアカウントを有することができるユーザのみ表示する。

分析
ユーザの各々または全員に関する特性によってユーザのリストをソートする機能は新しくはない。ただし、この機能の無線空間への適用は、特に、このリストが分散クライアントで構成されていないユーザを参照する場合には新しい。

１１．カスタマイズド・イベント・ログ
説明
製品に関するイベントのみが表示されるようにフィルタリングされた１つまたは複数のリモート・サーバからのログ情報の表示。

分析
リモート・サーバのリモートでフィルタリングされたログ情報を遠隔表示する機能は新しくない。ただし、この場合の「サーバ」はより大きいクライアント／サーバ・システムのクライアントを構成する分散システムの構成要素である。リモート表示はこのクライアント／サーバ・システムの一部ではなく、分散クライアントの一部でもない。この機能は新しい。

１２．ファイル・レコードＯＥＭカスタマイズ
説明
コア２進数を全く再コンパイルする必要なしに新しいＯＥＭパートナーのための製品をカスタマイズする機能。「ＯＥＭ」ファイルの交換をするだけで製品をカスタマイズできる。

分析
２進数を再構築しソース・コードにアクセスすることなく、事前定義された境界内でソフトウェアをカスタマイズする機能は新しい概念ではない。

ただし、無線分散クライアント／サーバ・システムに適用されるこの技法は新しい。

１３．「インテリジェント」キューイング
説明
キューの内容を分析するための「インテリジェント」アルゴリズムに従ってペンディングの送信キューの項目について、追加、並べ替え、交換および／または削除を行う機能。

分析
必要なデータ転送量を低減するために送信キューの内容を統合することは新しい概念ではない。例えば、キューが新しい連絡先を含みその直後にその連絡先が削除された場合、簡単なアルゴリズムがその事態の発生を検出して新しい連絡先とその削除の両方を解消することができる。これはこの両方が互いを打ち消すからである。

ただし、無線分散クライアント／サーバ・システムに適用されたこの技法は、特に、その目的が計測されるネットワーク上で転送されるデータの量を低減することであるため新しい。

１４．送信前の検索の取り消し
説明
データ転送の開始前に検索要求を取り消す機能。

分析
この機能は、アウトボックスの項目を削除する機能に類似し、Ｅメール、連絡先、議事項目に適用できる。多くのＥメールとグループウェア・クライアントがこの機能を提供しているので確かに新しい概念ではない。

ただし、無線分散クライアント／サーバ・システムに適用されたこの技法は、特に、「アウトボックス」内の項目の宛先がメールまたはグループウェア・サーバではなく分散クライアント内の別の構成要素であるため新しい。リモート構成要素分散クライアントへの送信後に初めて項目はどこか別の宛先（例えば、インターネット上の）への送信待ちの「アウトボックス」に実際に入る。この機能によって取り消されるのは最初の転送である。

１５．ポールとプッシュ・ユーザ
説明
単一の組織または施設内に「ポール」と「プッシュ」動作ユーザ・アカウントを作成する機能。

分析
この機能によって、一部のユーザは真のプッシュ・モードで、また別のユーザは厳格ポール・モードで、さらに別のユーザはポール周期のために「効果的プッシュ」であるモード内で動作できる。

この概念は一般のＥメール・クライアントにとっては新しくない。Ｅメール配信のユーザの好みの選択は、通常、ユーザの選択に全く影響しない。

ただし、
・この機能は、特に無線空間で動作するＶｅｇａに適用される。そのようなシステムは普通、システムが採用した設計思想が指示する「オール・プッシュ」または「オール・ポール」である。
・「プッシュ」と「ポール」という用語は、常に「プッシュ」であるより大きいクライアント／サーバ・モデル内ではなく、分散クライアント内の通信に適用される。
したがって、新しい概念がある。

１６．プロビジョニング論理
説明
ユーザ選択アカウントと、接続されたハンドセットとに関する情報に基いてハンドセット・プロビジョニング・プロセスを変更、否定、または拒否する機能。

分析
本発明の目的は、既存のアカウントと接続されたハンドセットのステータスが示す状況に基いてユーザにオープンの可能なオプションのリストをプロビジョニング・ユーザに向けることである。

この概念は新しくないかもしれないが、本発明は分散クライアント・モデルの２つの構成要素とその間のリンクの構築と切断に適用される。
・選択されたユーザ・アカウントがＶｅｇａを使用できるがハンドセットを割り当てられていない場合
。ハンドセットが他のユーザに現在割り当てられている場合
・構成は不可能：アドミニストレータは割り当てを削除しなければならない。
。ハンドセットが現在プロビジョニングされていない場合
・ソフトウェアがインストールされており、基本同期化が実行されている。
・選択されたユーザ・アカウントがＶｅｇａを使用できハンドセットを割り当てられている場合
。ハンドセットがユーザに現在割り当てられている場合
・必要に応じてハンドセットのソフトウェア・インストールが修理される。
・適宜ハンドセットは変更されない。
。ハンドセットが他のユーザに現在割り当てられている場合
・構成は不可能：アドミニストレータは割り当てを削除しなければならない。
。ハンドセットが現在アンプロビジョニングされている場合
・割り当ては変更される。ユーザの現在のハンドセットはワイプされる。
・ソフトウェアがインストールされており、基本同期化が実行されている。
・選択されたユーザ・アカウントがＶｅｇａを使用できない場合
。そのユーザについて操作はできない。

１７．ハンドセットのワイプ
説明
ユーザのデバイスから全データを削除するコマンドをそのデバイスに送信する機能。

分析
このコマンドの目的は、デバイス上の全データのリモート削除を開始することである。アドミニストレータはハンドセット紛失または盗難時にこの多少極端な操作を実行する。デバイスの機能が停止するのを阻止するためにユーザができることはほとんどない。

この機能は、特に無線分散クライアント内では新しい。

１８．データ転送タイムスタンプ
説明
ユーザの端末からのデータが送信されまたは受信された最後の時間のタイムスタンプの記憶と表示。

分析
この機能の目的は、分散クライアントのリモート構成要素から受信した最後の転送データの日時を記録することである。この機能は、システムがアプリケーション・データなしに動作しているという信頼度チェックをユーザに提供する。

この機能の主要な要素は当然ながら当業者には明らかであろう。ただし、トランスポートの基本の低い信頼度のために、端末からサーバへの最後の転送の正確な時間を決定することは不可能である。ただし、いずれかの方向のすべての通信について少なくとも逆の方向の何らかの種類の確認が行われるので、最後の着信データの記録は少なくとも何らかの発信データを受信したという証拠を提供する。

１９．ソフトウェアのインストール
説明
標準の（ＳＩＳファイル）ソフトウェア・インストール方法を使用せずにＳｙｍｂｉａｎ ＯＳ製品のソフトウェアをインストールする（またその後アンインストールする）機能。

分析
Ｓｙｍｂｉａｎ ＳＩＳファイルの目的は、ＩｎｓｔａｌｌＳｈｉｅｌｄその他などによって他のソフトウェア環境内でしばしば達成されるのとほぼ同じ方法でインストールを容易にすることである。

ただし、Ｓｙｍｂｉａｎ ＯＳデバイスが使用するコネクティビティプラットフォームではＳＩＳファイルの自動実行ができないので、アドミニストレータがデバイスと物理的に対話する（すなわち、ボタンの押下、インボックスとの対話など）ことなくソフトウェアのインストールを開始することはできない。

この機能の本質は、デバイスの再起動時に、デバイスのインストールと環境設定とを行うある種の「１回実行」構成要素が実行されるいくつかのフォルダにファイルをコピーすることによってインストールシステムを全て回避することである。その結果、そうでなければＳＩＳファイルの複雑な再コンパイルが必要なデバイスごとのインストールが可能になる。

インストール担当者に必要な唯一の動作は、デバイスの電源を切ってからユーザに渡すことである。これによってインストール・シーケンスが完了する。

２０．現場でのセキュリティ更新
説明
アドミニストレータが現場のユーザ端末の端末セキュリティ・ポリシーを更新できる機能（例えば、アプリケーション・ロックの最小桁数またはタイムアウト期間を増やすなど）。

分析
本発明の目的は、アドミニストレータがデバイスのある種のセキュリティ証明書を再プロビジョニングまたは変更を実施するためにアドミニストレータに返送させることなく証明書をリモートに変更できるようにすることである。

そのような変更は以下を含む。
・ユーザが選択しなければならないアプリケーション・ロック・コードの最小強度のポリシーの変更。これは一部のユーザにとってコードの変更を伴う
・デバイスによって使用される共通秘密鍵のスケジューリングされた変更
・ユーザにログオン・パスワードを変更させる要求

上記の機能は無線分野、特に再構成の宛先が分散クライアントの構成要素の場合には新しい。

２１．現場でのポール／プッシュ更新
説明
アドミニストレータがマイクロポーリングの周期をリモートに変更し、または個々の端末とユーザについてコネクティビティをポールからプッシュ（またはその逆）に変える機能。

分析
アドミニストレータは、場合によって以下に応答してある種のユーザについてポーリングの周期を変更する必要がある。
・ある種のユーザが許可する費用のタイプに関するポリシーの変更
・特定のユーザに量の習慣を変更させる。

本発明の特徴によってアドミニストレータはユーザごとに以下のいずれかまたはすべてを変更できる。
・マイクロポーリングの周期を変更して任意のアプリケーション・データがない場合に背景データ量を変更する
・マイクロポーリングの周期を変更して任意のネットワーク運用会社のＮＡＴマッピング・タイムアウトを参照して「効果的プッシュ」を使用可能または使用不可にする
・マイクロポールを使用しない真の「プッシュ」モードに変更、またはその終了

この機能は無線空間内の分散クライアントの構成要素の内部通信に特有である。一実施形態では、ユーザは上記を制御できない。アドミニストレータだけがこれらの設定を行う特権を有する。

従来の分散クライアント・モデルの端末で優れたユーザ経験を提供するという問題の対処の概略示したブロック図。 ＭｏｂｉｌｅＭＱ ＭＯＭとセッション非依存との組み合わせは多数の接続規制の問題を扱う方法を示すブロック図。 Ｔｒａｎｓｃｅｎｄ Ｍａｉｌと組み合わされたＭｏｂｉｌｅＭＱが、端末リソースと接続の制約を効率的に扱うという双子の問題の包括的で有効な解決策を示す図である。 セッション・べースのシステムが通常提供するＭＯＭによって提供されるセッション非依存機能を、スマートホンなどのリソースが限られた端末に適した方法で配備することができる様子を示す図である。 ラージ・サーバ側からはラージ・クライアントは普通に通信している相手の他のどのクライアントとも区別がつかないため、ラージ・サーバからはラージ・クライアントの分散的な性質は見えないことを示す図である。 スモール・クライアントが、クライアント側ＭＯＭを含むかこれと通信する端末側構成要素として実装できる状態を示す図である。 スモール・クライアントがプログラム−例えば、Ｅメール・アプリケーション、プラスそれを端末側構成要素にプラグイン・リンクすること−を含む方法を示す図である。 スモール・クライアントが連絡先プログラムなどのプログラムを除外できることを示す図である。 端末側構成要素が連絡先データベースを介して連絡先プログラムと通信することがミドルウェア・アーキテクチャと概念的に等しいことを示す図である。

Claims (37)

1. 端末上で実行される端末側構成要素とサーバ側構成要素とに分散されるソフトウェア・アプリケーションを含むデータ・アクセス、複製または通信システムであって、
   前記端末側構成要素とサーバ側構成要素とが（ｉ）共にサーバへのクライアントを構成し、（ii）ネットワーク上でメッセージ・キューイング・システムを用いてメッセージを送信することで協働するシステム。
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. 前記ソフトウェア・アプリケーションが請求項１から３３のいずれか一項に記載のシステムの要素である請求項３４に記載の方法。
36. 請求項１から３３のいずれか一項に記載のシステムの要素である前記端末側構成要素でプログラミングされた端末。
37. 請求項１から３３のいずれか一項に記載のシステムの要素である前記サーバ側構成要素でプログラミングされたサーバ。

Images