JP2010525740A - ワイヤレス・データ・サービス内において電子メール・メッセージをキャッシュする装置および方法 - Google Patents

Abstract

データ・サービス内において電子メール・メッセージをキャッシュするシステムおよび方法について記載する。例えば、本発明の一実施形態によるコンピュータ実装方法は、ワイヤレス・データ処理デバイスの代わりに、第１電子メール・サーバから第１電子メール・メッセージ集合を取り出すステップと、第１電子メール・メッセージ集合からメタデータを抽出するステップと、メタデータを第１キャッシュに格納するステップであって、第１キャッシュ管理方針にしたがって第１キャッシュを管理する、ステップと、電子メール・メッセージの少なくともメッセージ本体を第２キャッシュに格納するステップであって、第２キャッシュ管理方針にしたがって第２キャッシュを管理する、ステップとを備えている。
【選択図】図１

Description

本発明は、一般的には、データ処理システムの分野に関する。更に特定すれば、本発明は、ワイヤレス・データ・サービス内において電子メール・メッセージをキャッシュするためのアーキテクチャの改良に関する。

電子メールは、今日世界において代用することができない通信ツールになっている。業務の世界では、事実上全ての従業員が電子メールを拠り所として、外部の顧客および内部の他の従業員と通信を行う。加えて、殆どの電子メール・ユーザは、少なくとも１つの個人的な電子メール・アカウントを有する。個人的電子メール・アカウントは、ユーザのインターネット・サービス・プロバイダ（例えば、Pacific Bell、AT&T Worldnet（商標）、America Online（商標）、．．．等）によって、またはインターネット・ウェブ・サイト（例えば、Yahoo（商標）メールまたはHotmail（商標））が提供することができる。

存在する問題の１つに、ユーザが複数の異なる電子メール・アカウント間で調整することを厄介であると感じることがあげられる。例えば、ユーザが仕事中１日を通じて彼／彼女の会社の電子メール・アカウントをチェックしていてもよいが、ユーザは彼／彼女の個人的な電子メール・アカウントをチェックするのを忘れる場合や、チェックできない場合がある。同様に、自宅における夜間または週末の間、ユーザは彼／彼女の個人の電子メール・アカウントにしかアクセスできない場合もある。このため、ユーザが彼／彼女の個人アカウントから会社の同僚に電子メールを送る場合、ユーザが自宅に戻って彼／彼女の個人電子メール・アカウントにログ・インするまで、ユーザは会社の同僚の回答を点検できない場合もある。逆に、ユーザが彼／彼女の会社のアカウントから友人に電子メールを送る場合、ユーザが作業に戻って彼／彼女の個人電子メール・アカウントにログ・インするまでは、友人の回答にアクセスできない場合もある。ユーザが同じ場所から双方の電子メール・アカウントにアクセスすることができる場合であっても、２つ以上の異なる電子メール・システムにユーザがログ・インしなければならないのは、いくらか厄介であり、特に、ユーザのデスクトップ・コンピュータおよび／またはワイヤレス・クライアント（例えば、Microsoft Outlook（商標）およびLotus Notes（商標））に、２つ以上の異なるユーザ・エージェントが必要となり得る場合には厄介である。

前述の問題は、多くの電子メール・システムが異なる、互換性のない電子メール規格によって動作するという事実によって更に悪化する。２つの最も普及している電子メール規格は、Post Office Protocol 3 （「ＰＯＰ３）」）およびInternet Messaging Access Protocol（「ＩＭＡＰ」）である。

ＰＯＰ３は、インターネット電子メール・アカウントに広く一般に用いられている。ＰＯＰ３サーバは、着信電子メール・メッセージがログ・インしたユーザによってダウンロードされるまで、この電子メール・メッセージを一時的に格納する。ユーザは、電子メールがダウンロードされると直ぐに電子メールを削除するように、またはユーザがこれらを削除することを指示するまで待つように、サーバを構成することができる。ＰＯＰ３は、構成変更可能な選択肢が制限された、比較的単純なプロトコルである。係属中の全てのメッセージおよび添付ファイルは、サーバ上の１つの電子メール・フォルダからユーザのクライアント・コンピュータまたはワイヤレス・デバイス上にある１つの電子メール・フォルダ（即ち、ユーザ・エージェントの「インボックス」）にダウンロードする。一意のメッセージ識別コードに基づいてメッセージを識別する。

ＩＭＡＰは、一般に普及しているが、いくらか精巧になった別の電子メール規格であり、インターネット電子メール・アカウントおよび社内電子メール・アカウントの双方に広く用いられている。ＩＭＡＰ４が最新バージョンである。ＰＯＰ３とは異なり、これはメッセージ・データベースを設けて、その中でメッセージをフォルダ（例えば、インボックス、発送済みメール、保存メール、．．．等）に保管し、更にユーザ間で共有できる電子メールボックスを設けている。また、ＩＭＡＰは多目的インターネット・メール拡張機能（「ＭＩＭＥ」）との統合改善にも備えている。ＭＩＭＥは、ファイルを電子メール・メッセージに添付するために用いられるプロトコルである（例えば、ユーザは、添付ファイルを自動的に受け入れそれをダウンロードするのを待つ必要なく、メッセージ・ヘッダのみを読むことができる）。

データ・サービス内において電子メール・メッセージをキャッシュするシステムおよび方法について記載する。例えば、本発明の一実施形態によるコンピュータ実装方法は、ワイヤレス・データ処理デバイスの代わりに、第１電子メール・サーバから第１電子メール・メッセージ集合を取り出すステップと、第１電子メール・メッセージ集合からメタデータを抽出するステップと、メタデータを第１キャッシュに格納するステップであって、第１キャッシュ管理方針にしたがって第１キャッシュを管理する、ステップと、電子メール・メッセージの少なくともメッセージ本体を第２キャッシュに格納するステップであって、第２キャッシュ管理方針にしたがって第２キャッシュを管理する、ステップとを備えている。

本発明の更に深い理解は、以下の図面と関連付けた以下の詳細な説明から得ることができる。
図１は、本発明の一実施形態による電子メール・システム・アーキテクチャを示す。 図２は、インターネットＩＭＡＰアカウントおよび外部ＰＯＰアカウントを含む、本発明の更に具体的な実施形態を示す。 図３は、本発明の一実施形態による、内部アカウント・コードの外部アカウント・コードとのマッピングを示す。 図４は、内部および外部アカウントの双方がＩＭＡＰアカウントである、電子メール・システムの一実施形態を示す。 図５は、本発明の一実施形態による、グローバル識別コード（「ＧＩＤ」）の標準的ＩＭＡＰ識別コードに対するマッピングを示す。 図６は、電子メールをデータ処理デバイスに配信する改良システムの一実施形態を示す。 図７は、本発明の一実施形態によるユーザ・データベースに保持したユーザ・データの集合を示す。 図８は、本発明の一実施形態において用いられる係属メッセージ表を示す。 図９は、本発明の一実施形態によるプロセスを示す。 図１０は、本発明の一実施形態によるシステム・アーキテクチャを示す。 図１１は、本発明の一実施形態による複数のタスク・キューを示す。 図１２は、本発明の一実施形態において用いられるシンクロナイザおよびメール・キャッシュを示す。 図１３は、本発明の一実施形態にしたがって、アカウントを同期させるために実装する方法を示す。 図１４は、１つ以上の電子メール・ストアとワイヤレス・データ処理デバイスとの間において電子メールを同期させるシステムの別の実施形態を示す。 図１５は、１つ以上の電子メール・ストアとワイヤレス・データ処理デバイスとの間にいて電子メールを同期させる方法の一実施形態を示す。

説明全体を通じて、説明の目的のために、本発明の完全な理解が得られるように、多数の具体的な詳細を明記する。しかしながら、本発明は、これら具体的な詳細の一部が無くても実用化できることは、当業者には明らかであろう。一方、周知の構造およびデバイスは、ブロック図形態で示して、本発明の基礎となる原理が曖昧になるのを避けている。

前述の問題に取り組むために、本願の譲受人は、複数の電子メール・アカウント間において調整を行うシステムを開発した。このシステムのある種の態様は、APPARATUS AND METHOD FOR COORDINATING MULTIPLE EMAIL ACCOUNTS（複数の電子メール・アカウントを調整する装置および方法）と題する米国特許第７，１５５，７２５号、およびAPPARATUS AND METHOD FOR DISTRIBUTING ELECTRONIC MESSAGES TO A WIRELESS DATA PROCESSING DEVICE USING A MULTI-TIERED QUEUING ARCHITECTURE（多層待ち行列アーキテクチャを用いて電子メッセージをワイヤレス・データ処理デバイスに配信する装置および方法）と題する米国特許第７，１６２，５１３号（「従来特許」）に記載されている。これらの特許は、本願の譲受人に譲渡されており、ここで引用したことによりその内容が本願にも含まれるものとする。

これより、図１から図９に関して、従来特許について説明し、続いて内部および外部電子メール・アカウントからの電子メールの一掃効率的な調整、同期、および管理に対処する電子メール・システムへの新たな改良について説明する。以下に説明する本発明の実施形態においても、ワイヤレス・クライアント・デバイスを用いた実施態様を中心とするが、本発明の基礎原理は必ずしもワイヤレス実施態様に限定される訳ではない。

先行特許に記載された実施形態
本発明の実施形態は、図１に概略的に示すような、データ処理サービス１００上において実現することができる。一実施形態では、サービス１００は、ワイヤレス・データ処理デバイス１０１と任意の外部サーバとの間におけるプロキシとして機能し、ワイヤレス・デバイス１０１は、例えば、電子メール・サーバ１３０および１３１、ならびにウェブ・サーバ（図示せず）のように、外部サーバと通信する。例えば、標準的なアプリケーション、マルチメディア・コンテンツ、およびデータをサービス１００によって、ワイヤレス・デバイス１０１が適正に解釈することができるフォーマットに変換することができる。サーバ１００の一実施形態が、PORTAL SYSTEM FOR CONVERTING REQUESTED DATA INTO A BYTECODE FORMAT BASED ON PORTAL DEVICE'S GRAPHICAL CAPABILITIES（ポータル・デバイスのグラフィック処理能力に基づいて、要求データをバイトコード・フォーマットに変換するポータル・システム）と題する米国特許第６，７２１，８０４号に記載されている。この特許は、本願の譲受人に譲渡されており、ここで引用したことによりその内容が本願にも含まれるものとする。

図１に示す実施形態によれば、ユーザには、サービス１００（例えば、１つ以上の電子メール・サーバ上に維持される）インターネット電子メール・アカウント１０２を提供する。本明細書において用いる場合、「インターネット」とは、電子メール・アカウントがサービス１００によって維持および制御される事実に言及する。ユーザは、内部電子メール・アカウント１０２にアクセスして、電子メール・メッセージをユーザのワイヤレス・デバイス１０１からワイヤレス・ネットワーク１２０を通じて、および／またはクライアント・コンピュータ１１０（例えば、インターネットと通信するように結合されているパーソナル・コンピュータ）から送出および受信することができる。種々のネットワーク形式を用いることができ、例えば、セルラ・ディジタル・パケット・データ（「ＣＤＰＤ」）および汎用パケット無線サービス（「ＧＰＲＳ」）をサポートするものが含まれる。しかしながら、本発明の基礎原理は、ワイヤレス・ネットワーク１２０のいずれの特定の形式にも限定されないことを注記しておく。

内部電子メール・アカウント１０２に加えて、ユーザは種々の「外部」電子メール・アカウント１３０および１３１を有することができる。つまり、「外部」とは、サービス１００によって直接的に維持も制御もなされないという意味である。前述のように、従来のシステムでは、ユーザは、個々の電子メール・アカウント１０２、１３０、および１３１の各々に別個にログ・インしなければならないのが通例であった。対照的に、本発明の一実施形態では、サービス１００が自動的にユーザの外部アカウント１３０および１３１からメッセージを読み出し、これらのメッセージをユーザの内部電子メール・アカウント１０２に格納する。このため、ユーザは、１つのアカウント１０２から、そして、１つのユーザ・エージェントを用いて、彼／彼女のメッセージの全てにアクセスすることができる。

図１に示す実施形態では、サービス１００上に構成されたインターフェース１０４が周期的に外部電子メール・アカウント１３０および１３１に照会して、新たなメッセージをチェックする。あるいは、または加えて、インターフェース１０４は、ユーザが内部電子メール・アカウント１０２にログ・インするとき毎に、ユーザからコマンドを受信したときにのみ、外部アカウント１３０および１３１からメッセージを取り出すことができる。一実施形態では、ユーザは、新たな電子メール・メッセージを受信すると、それを自動的にインターフェース１０４に送信するように、外部電子メール・アカウント１３０、１３１を構成することができる。

インターフェース１０４が外部電子メール・アカウント１３０、１３１からメッセージを取り出すことができるようになる前に、各アカウント（例えば、mail.pacbell.net)および有効なユーザ認証データ毎に、サーバのネットワーク・アドレスを最初にプログラミングしておかなければならない。例えば、外部電子メール・アカウント１３０、１３１は、通例、電子メール・メッセージをインターフェース１０４に供給する前に、有効なユーザ名およびパスワードを必要とする。したがって、図１に示すように、ユーザは、最初に外部電子メール・アカウント・データ１０７をインターフェースに供給することを要求される場合がある。

一旦外部電子メール・アカウント１３０、１３１からの電子メール・メッセージが内部電子メール・アカウント１０２内に格納されたなら、電子メールが最初から内部アカウント１０２にアドレスされていたかのように、これらに対して種々の電子メール動作（例えば、回答、削除、保存メール・フォルダに移動、．．．等）を実行することができる。加えて、一実施形態では、インターフェース１０４はメール・アカウント更新を外部電子メール・アカウント１３０、１３１に送信することができる。例えば、ユーザが特定のメッセージを削除した場合、メッセージを削除したことの指示が外部アカウント１３０、１３１に送信され、これによってメッセージ一貫性を種々の電子メール・アカウント間で維持する。一実施形態では、内部アカウント１０２に対する動作を外部アカウント１３０、１３１に反映させるべきか否かに関する選択は、ユーザによってアカウント毎に行うことができる。

ＩＭＡＰプロトコル（例えば、ＩＭＡＰ４）を用いる内部電子メール・アカウントとＰＯＰ３プロトコルを用いる外部アカウントとの間において電子メール・メッセージを調整する特定の一実施形態を、図２に示す。この実施形態は、これら２つの特定的なプロトコルを用いて説明するが、本発明の基礎原理は、種々の代わりのメッセージング・プロトコル（例えば、分散メール・システム・プロトコル（「ＤＭＳＰ」）、Ｘ．４００、．．．等）を用いても実現できることを注記しておく。

この実施形態では、ＰＯＰ取込／更新インターフェース２０６をサービス１００上に構成して、１つ以上の外部ＰＯＰサーバ２１４から電子メール・メッセージを取り出す。前述のように、ＰＯＰ取込／更新インターフェース２０６は、外部ＰＯＰアカウント２１４上に新たな電子メール・メッセージ２３０がないか周期的に（例えば、１５分毎）チェックするように、プログラミングすることができる。加えて、ユーザは、ＰＯＰ取込／更新インターフェース２０６に、いずれの所与の時点でも、ワイヤレス・デバイス１０１またはクライアント・コンピュータ１１０から、新たなメッセージをチェックするように命令することができる。

新たなメッセージをチェックするためにどのようにＰＯＰ取込／更新インターフェース２０６を始動させるかには関係なく、一旦始動させたなら、例えば、ユーザの電子メール・アカウント名およびパスワードのような認証データを、最初に外部ＰＯＰアカウント２１４に送信する。一旦外部ＰＯＰアカウント２１４によって認証データが受け入れられたなら、ＰＯＰアカウント２１４はあらゆる新たな電子メール・メッセージをＰＯＰ取込／更新インターフェース２０６に送信する。一実施形態では、ＰＯＰプロトコルを用いて、ＰＯＰアカウント２１４からＰＯＰ取込／更新インターフェース２０６にファイルを送信する。しかしながら、本発明の基礎原理は、いずれのメッセージ送信プロトコルにも限定されるのではない。

ユーザの外部ＰＯＰがどのように構成されているかに応じて、ＰＯＰ取込／更新インターフェース２０６に送信されるメッセージは、これらが送信されると直ちに外部アカウント２１４から自動的に削除することができ、またはユーザが後にメッセージを削除すべきことを指示するまで外部アカウント２１４上に維持することもできる。

一実施形態では、ＰＯＰ取込／更新インターフェース２０６は、新しい電子メール・メッセージを、内部ＩＭＡＰアカウント２１０上で指定されたフォルダに転送する。例えば、ユーザがYahoo電子メール・アカウントおよびWorldnet電子メール・アカウントを有する場合、ユーザは内部ＩＭＡＰアカウント２１０上に２つの独立したフォルダをセット・アップし（例えば、それぞれ、「Yahooメール」および「Worldnetメール」）、双方のアカウントからの新たな電子メール・メッセージを格納することができる（前述のように、ＩＭＡＰは電子メール・メッセージ・フォルダに対するサポートに備えている）。

外部ＰＯＰアカウント２１４が、電子メール・メッセージを読み出した後でもこれらのメッセージを格納するように構成されている場合、読み出し後に各メッセージのコピーが２つずつ存在する。即ち、外部アカウント２１４上に１つのコピー、および内部電子メール・データベース２１１上に１つのコピーが存在する。したがって、２つのアカウント間における調整拡大に備えるために、一実施形態では、電子メール・メッセージ・マッピング・ロジック２１２が、内部アカウント２１０および外部アカウント２１４上に格納されているメッセージ間にリンクを生成する。例えば、図３に示すような表を、電子メール・メッセージ・マッピング・ロジック２１２によって生成し、内部電子メール・メッセージ識別コード３０１を、外部電子メール・メッセージ識別コード３０２と対応付けることができる。動作において、ユーザが特定の内部電子メール・メッセージに関して動作を実行する毎に、電子メール・メッセージ・マッピング・ロジック２１２は、対応する外部電子メール・メッセージが存在するか否か判定する。存在する場合、ＰＯＰ取込／更新インターフェース２０６に通知し、次いでＰＯＰ取込／更新インターフェース２０６は、それに応じて、外部ＰＯＰアカウント２１４を更新する。

例えば、再度図３を参照して、ユーザが内部メッセージＩＤコード"folder=saved mail, uid=3361"を有するメッセージを削除すると、電子メール・メッセージ・マッピング・ロジック２１２は、ＰＯＰ取込／更新インターフェース２０６に、外部メッセージＩＤコード"B881431776693cca7e41ccded 0f56613"を有する外部メッセージ番号４を外部ＰＯＰサーバ２１４から削除すべきことを示す。すると、ＰＯＰ取込／更新インターフェース２０６は、ＰＯＰ３「削除」コマンドを外部ＰＯＰアカウント２１４に送信して、そのメッセージ番号（例えば、"DELE4"）を用いてメッセージを特定する。このように、ユーザは数個の異なるメール・アカウントを１つのアカウントから効果的に管理することができる。

ユーザは、彼／彼女のワイヤレス・デバイス１０１から内部電子メール・アカウント２１０にアクセスすることができ、一実施形態では、ワイヤレス・デバイス１０１は、電子メール・プロキシ２０４を通じてアカウントに接続する。ネットワーク・ポータル・アプリケーションに記載されているように、一実施形態では、電子メール・プロキシ２０４は、電子メール・メッセージおよびその他のコンテンツ（例えば、ウェブ・ページ、グラフィック画像等）を、個々のワイヤレス・デバイス１０１の処理能力に基づいて一意にフォーマットする。また、ユーザは、内部電子メール・アカウント２１０に、クライアント・デスクトップまたはノートブック・コンピュータ１１０を通じて、直接またはウェブ・インターフェース２０２（例えば、Yahoo MailおよびHotmailが提供するウェブ・インターフェースのような）を介してアクセスすることもできる。

図４は、内部電子メール・アカウント４１０および外部電子メール・アカウント４１４双方がＩＭＡＰアカウントである、一実施形態を示す。外部ＩＭＡＰアカウント４１４は電子メール・フォルダのサポートを有するので、種々のレベルの電子メール調整が可能である。例えば、ユーザは、外部電子メール・アカウント４１４上で指定されたフォルダにおいて発見されたメッセージだけを取り出すようにＩＭＡＰ取込／更新インターフェース４０６を構成することができる（例えば、「インボックス」フォルダからのみ）。一旦具体的なフォルダがユーザによって特定されると、内部アカウント４１０は、前述と同様にして、外部アカウント４１４からメッセージを取り出すことができる。例えば、一旦メッセージを外部アカウント４１４から読み出したなら、電子メール・メッセージ・マッピング・ロジック４１２を内部アカウント４１０内において実行して、各外部メッセージＩＤコードを内部メッセージＩＤコードと関連付ける（例えば、図３に概略的に示すように）。次いで、この関連付けを用いて、メッセージ更新をリモート・アカウント４１４に送信することができる。例えば、ユーザがメッセージを削除すると、電子メール・メッセージ・マッピング・ロジック４１２は、対応する外部メッセージが存在するか否か判定する（例えば、内部メッセージＩＤコードを用いて、表参照を実行することによって）。存在する場合、電子メール・メッセージ・マッピング・ロジック４１２は、外部ＩＤコードをＩＭＡＰ取込／更新インターフェース４０６に送信し、続いて、ＩＭＡＰ取込／更新インターフェース４０６は「削除」コマンドを外部ＩＭＡＰアカウント４１４に送信する（即ち、外部ＩＤコードによって、削除すべきメッセージを特定する）。

内部および／または外部ＩＭＡＰアカウントを用いて作業する際の付加的な問題の１つは、電子メール・メッセージＩＤコードは各個々のＩＭＡＰフォルダ内でなければ一意でないことである。例えば、「インボックス」フォルダおよび「保存メール」フォルダ双方が、１から２０までの範囲を取るＩＤコードを有する電子メール・メッセージを収容することもあり得る（即ち、異なる電子メール・メッセージに同じＩＤコードが用いられる）。加えて、電子メール・メッセージをソース・フォルダから宛先フォルダに移動するとき、新たなＩＤコードが与えられる（即ち、フォルダ内に既に格納されているメッセージに用いられたＩＤコードに基づいて）。その結果、内部電子メール・アカウント２１０、４１０および外部電子メール・アカウント２１４、４１４上に格納されているメッセージ間で精度の高いマッピングを維持するためには、何らかのメカニズムを設ける必要がある。

本発明の一実施形態では、ＩＭＡＰフォルダ全体を通じて精度高く追跡するために、ＩＭＡＰアカウント２１０、４１０上にある全てのメッセージに、一意のグローバルＩＤコード（「ＧＩＤ」）を生成する。標準的なＩＭＡＰ識別コードとは異なり、メッセージのＧＩＤは、アカウント２１０、４１０上にある当該メッセージを一意に識別し、メッセージが１つのフォルダから次のフォルダに移動しても変化しない。図５における表は、ＧＩＤの標準的ＩＭＡＰ ＩＤコードへのマッピング例を明示する。一実施形態では、電子メール・メッセージ・マッピング・ロジック２１２、４１２は、各電子メール・メッセージのＧＩＤを、リモート・アカウント上の対応するＩＤコードと関連付ける。その結果、ユーザが内部アカウント２１０、４１０においてファイルをフォルダ間で移動させても、外部アカウント２１４、４１４上の対応するメッセージをなおも特定することができる。

ＧＩＤは、様々な異なる方法で生成し維持することができる。一実施形態では、特定のメッセージに対する更新が行われたときにはいつでも、ＧＩＤマッピングを更新する。例えば、ＧＩＤ＝２０がINBOX:25に対応し、ユーザがINBOX:25をTrash:12に移動させた場合、それに応じてマッピングを更新する。この技法の利点の１つは、ＧＩＤによるメッセージの素早い参照が可能になることである。

別の実施形態では、X-GID:20のようなX-Headerをメール・メッセージの実際のヘッダに挿入する。メッセージを移動させると、ヘッダもそれと共に移動する。この技法の利点の１つは、メッセージをフォルダ毎に次々に追跡するのに要する作業が少なくなることである。

一実施形態では、ユーザが内部アカウント２１０、４１０からの電子メール・メッセージに応答すると、ヘッダ内にある"FROM:"フィールドが、メッセージを送信した先の元のアカウントを示す。例えば、メッセージが本来外部アカウント２１４、４１４に送られた場合、回答が内部アカウントにおいて生成されたという事実にも拘わらず、"FROM:"フィールドは外部アカウント・アドレスを含む。

加えて、メッセージを内部アカウントから送信したことの指示も、メッセージに含めることができる。例えば、メッセージをワイヤレス・デバイスから送信した場合、「ワイヤレス」デバイスからメッセージを送ったことの指示を、発信元の名称に添付することができ（例えば、「スコット・キスター（ワイヤレス）」scott.kister@danger.com）、これによってメッセージの真の発信元を特定しつつ、同時に元の電子メール受信アドレスを維持する。一実施形態では、この指示は、内部アカウント２１０、４１０において、エンド・ユーザによってイネーブルまたはディスエーブルすることができる。

図６は、電子メッセージをワイヤレス・データ処理デバイス１０１に配信する(distribute)電子メール・システムの別の実施形態を示す。この実施形態は、概略的に、ユーザ・データベース６２５、ユーザ・データベース６２５にアクセスするデータベース・プロキシ・サーバ６２０、電子メール・プロキシ・サーバ６１０、ディスパッチャ・サーバ６１５、およびメール・サーバ６０５上で（あるいは、別個のサーバ上で）実行するメール・エージェント６０６によって構成されている。

図７に示すユーザ・データベース６２５の一部の例は、ユーザ識別コード７０１のデータ処理デバイス識別コード７０２に対するマッピングを収容する。ユーザＩＤ／デバイスＩＤのマッピングは、サービス１００が、所与のユーザのために電子メール・メッセージおよびその他のデータを送信すべき特定のワイヤレス・デバイス１０１を特定するために用いられる。加えて、ユーザ・データベース６２５は、ユーザのアカウント名、ユーザのオンライン・ステータス、ワイヤレス・デバイス１０１が通信している特定のディスパッチャ６１５を含む、およびユーザと関連付けられている加入者個人情報モジュール（「ＳＩＭ」）識別コード（ユーザは１つよりも多いＳＩＭを維持している場合もある）を収容する。

ディスパッチャ６１５は、ワイヤレス・デバイス１０１とサービス１００との間で送信するデータのための通信中央地点を形成する。一実施形態では、ディスパッチャ６１５は、ワイヤレス・デバイス１０１とサービス１００上に維持されている種々のプロキシ・サーバとの間にソケット接続（例えば、ＴＣＰソケット）を維持する。例えば、電子メール・セッションでは、ディスパッチャ６１５は、ワイヤレス・デバイス１０１と電子メール・プロキシ・サーバ６１０との間にソケット接続を開設し維持する。同様に、他のワイヤレス・アプリケーション（例えば、インスタント・メッセージング、ウェブ・ブラウジング、．．．等）では、ディスパッチャ６１５は、ワイヤレス・デバイス１０１としかるべきプロキシ・サーバ６２１（例えば、インスタント・メッセージング・プロキシ・サーバ、ウェブ・プロキシ・サーバ、．．．等）との間にソケット接続を確立し維持する。ユーザがサービス１００にログ・インする毎またはサービス１００からログ・アウトする毎に、ディスパッチャ６１５は、ＤＢプロキシ６２０に、ユーザ・データベース６２５におけるユーザのオンライン・ステータスをそれに応じて更新するように通知する。加えて、ワイヤレス・ネットワーク１２０と、サービス１００が動作するローカル・ネットワークとの間に帯域幅の大きな差がある場合、ディスパッチャ６１５は、各個々のソケット接続を通じてワイヤレス・デバイス１０１に送信するデータおよびワイヤレス・デバイス１０１から送信されるデータを、一時的にバッファする。

メール・サーバ６０５（または別個のサーバ）上で実行するメール・エージェント６０６は、連続的にユーザの電子メール・アカウントに対する変化を追跡する。一実施形態では、エージェント６０６はユーザのインボックスを周期的にチェックして、ユーザが何らかの新たな電子メール・メッセージを受信したか否か判定する。ユーザに宛てられた新たな電子メール・メッセージが到達すると、メール・エージェント６０６は「新電子メール・メッセージ」警報を電子メール・プロキシ・サーバ６１０に送信する。電子メール・プロキシ・サーバ６１０は、新電子メール・メッセージ警報をＤＢプロキシ・サーバ６２０に転送する。電子メール・プロキシ・サーバは、新電子メール・メッセージ警報のフォーマットを標準フォーマット（例えば、ＩＭＡＰ）からサービス１００が採用している専用のメッセージング・フォーマットに変換することができる。

ＤＢプロキシ・サーバ６２０は、ユーザ・データベース６２５に照会して、ユーザがオンラインかまたはオフラインか判定し、オンラインである場合、どのディスパッチャを通じてデータ処理デバイス１０１が接続されているかも判定する。ＤＢプロキシ・サーバ６２０は、次に、新電子メール・メッセージ警報を自動的にユーザのワイヤレス・デバイス１０１に、ディスパッチャ６１５を通じて送信する。つまり、ユーザがオンラインの場合、彼／彼女は、何らかの新たな電子メール・メッセージが彼／彼女の電子メール・アカウントに到達したときに、自動指示を受信する。

しかしながら、ユーザがオフラインの場合、ＤＢプロキシ６２０は新電子メール警報を、図８に示すような、係属メッセージ表８００に格納する。係属メッセージ表は、表に格納されているデータ・タイプを示すメッセージ・タイプ指示８０１と、基礎メッセージ・データを収容するメッセージ・オブジェクト８０２とによって構成されている。図８には、３種類のメッセージ・タイプ、新電子メール・メッセージ警報８０１、新電子メール・メッセージ８１１、および新インスタント・メッセージ８１２が示されている。勿論、本発明の基礎原理に従いつつも、事実上無制限の数のメッセージ・タイプを一時的にユーザ・データベース６２５内において待ち行列に入れることができる。

一実施形態では、一旦新電子メール・メッセージ警報が、ある特定のメール・フォルダ（例えば、特定のメール・サーバ上にあるユーザのインボックス）に対して、ユーザの係属メッセージ表８００に格納されると、それ以上の警報や電子メール・メッセージは、そのメール・フォルダに対して、表には格納されず、これによってネットワーク帯域およびユーザ・データベース６２５上の記憶空間を保存する。しかしながら、異なるフォルダに対する新電子メール警報を受信した場合、新電子メール警報を係属メッセージ表８００に格納する。

ユーザがディスパッチャ６１５を介してサービス１００に再接続するときにはいつでも、ディスパッチャ６１５は最初にＤＢプロキシ６２０をチェックして、何らかの電子メール・メッセージ警報、電子メール・メッセージ、または他のタイプのデータが、ワイヤレス・デバイス１０１に対して係属中になっていないか判定する。係属中になっている場合、ディスパッチャ６１５は、これらをＤＢプロキシ６２０を通じて受信し、これらをワイヤレス・デバイス１０１に送信する。

一実施形態では、一旦ワイヤレス・デバイス１０１が新電子メール・メッセージ警報８１０を受信したなら（直ちに、またはユーザ・データベースの中において待ち行列に入れた後）、ワイヤレス・デバイス１０１は、指定されたグローバルＩＤ値よりも高い新たな電子メール・メッセージ全ての要求を送信する。この要求は、デバイス１０１が自動的に生成しても、または手動でユーザ・コマンドに応答して生成してもよい。図５に示すように、サービス１００が新たな電子メール・メッセージを受信するに連れて、新たなグローバルＩＤが順次割り当てられる。したがって、ワイヤレス・デバイス１０１は、そのローカル電子メール・ストレージに照会して、既にダウンロード済みの電子メール・メッセージに対する最大ＧＩＤ値を特定し、次いで、特定したＧＩＤ値よりも大きなＧＩＤ値を有する全ての電子メール・メッセージを要求することができる。このように全ての新電子メール・メッセージに対して一括要求を送信することにより、新たな電子メール・メッセージ毎に個々に要求する技法と比較すると、多大な量のネットワーク帯域幅の節約となる。

ディスパッチャ６１５は、この一括要求を電子メール要求と同一視し（例えば、要求に関連するデータ・オブジェクトのヘッダを読むことにより）、応答して、この要求を電子メール・プロキシ６１０に転送する。前述のように、要求がウェブ・ページ要求またはインスタント・メッセージング・トランザクションであった場合、ディスパッチャはこの要求をウェブ・プロキシ・サーバまたはインスタント・メッセージ・プロキシ・サーバにそれぞれ転送する。

電子メール・プロキシ６１０は、要求をデコードし、応答して要求をＩＭＡＰプロトコル（またはメール・サーバ６０５が採用する他のプロトコル）に変換する。例えば、「全ての新電子メール・メッセージ」に対する１つの要求に応答して、プロキシ・サーバ６１０は、新たな電子メール・メッセージ各々を個々に要求し、次いでこれらを１つの一括電子メール・メッセージ応答に束ねて、データ処理デバイス１０１に転送しても、ネットワーク帯域幅を保存することになる。

一実施形態では、プロキシ・サーバ６１０は、各電子メール・メッセージのコンテンツ全体（即ち、電子メール・ヘッダ＋本体）ではなく、新たな電子メール・メッセージ全てのヘッダのリストを最初に要求する。一旦データ処理デバイス１０１においてメッセージ・ヘッダを受信したなら、ユーザはメッセージ・ヘッダから各メッセージの主題の行を調べて、彼／彼女が読みたい電子メール・メッセージのみをダウンロードすることができる。

ワイヤレス・ネットワーク１２０は、通例、有線ネットワーク程信頼性が高くない。したがって、ワイヤレス・デバイス１０１は、ときとして、サービス１００とのデータ・トランザクションの最中に、ワイヤレス・ネットワーク１２０から切断される場合もある。例えば、電子メール・プロキシ６１０が１つ以上の電子メール・メッセージをユーザの代わりに電子メール・サーバ６０５から受信した後で、しかもディスパッチャ６１５によって、要求された電子メール・メッセージのワイヤレス・デバイス１０１への配信に成功した後に、ワイヤレス・デバイス１０１が移動してワイヤレス・ネットワークとの接触が絶たれる場合もある。これが生じた場合、一実施形態では、ディスパッチャ６１５は、ワイヤレス・デバイス１０１が再度オンラインに戻るまで、電子メール・メッセージ（またはその他のデータ）をメモリにおいて待ち行列に入れる。一旦ワイヤレス・デバイス１０１がディスパッチャ６１５との接続を再確立したなら、ディスパッチャ６１５は、待ち行列に入れたデータをワイヤレス・デバイス１０１に送信する。

一実施形態では、しかしながら、ユーザがある所定の時間期間（例えば、５分間）接触を絶ったままであった場合、ディスパッチャ６１５は待ち行列データをＤＢプロキシ６２０に送信し、次いで、ＤＢプロキシ６２０がデータを係属メッセージ表８００の中に格納する。これは、前述の通りである。あるいは、または加えて、ディスパッチャ６１５は、データをワイヤレス・デバイス１０１に送信しようとする試みを（指定時間量ではなく）指定回数だけ行った後、待ち行列データをＤＢプロキシ６２０に送信してもよい。

ユーザがサービス１００との接続を再確立すると、ディスパッチャ６１５（最初にデータを待ち行列に入れたディスパッチャとは異なるディスパッチャであってもよい）は、ＤＢプロキシ６２０に、何らかの係属データがないか照会する。次いで、ＤＢプロキシ６２０は係属データをディスパッチャ６１５に送信し、ディスパッチャ６１５はデータをワイヤレス・デバイス１０１に転送する。

このように、サービス１００は、複数のレベルの待ち行列を用いて、電子メール・メッセージおよびその他のデータのために信頼性の高い配信システムを提供する。ディスパッチャ６１５は、短期キューとして作用し、指定時間期間の間電子メール・メッセージを格納する。ワイヤレス・デバイス１０１が、指定時間期間の後もオフラインのままである場合、ディスパッチャ６１５は係属中の電子メール・メッセージを、ＤＢプロキシ６２０が維持するユーザ・データベース６２５に転送することによって、メモリおよび処理パワーを解放し、ディスパッチャ６１５はこれらを他のデータ処理デバイスの接続に割り当てし直すことができる。次いで、電子メール・メッセージおよびその他のデータをユーザ・データベース６２５に無期限に（即ち、ワイヤレス・デバイス１０１が再度オンラインになるまで）格納する。

図９は、説明したばかりの電子メール配信プロセスの種々の態様を概略的に示すフローチャートである。９０２において、メール・エージェント６０６は、新たな電子メール・メッセージがメール・サーバ６０５上にあるユーザのインボックスに到達したことを検出する。９０４において、ＤＢプロキシ６２０は、ワイヤレス・デバイス１０１が現在オンラインになっているか否か、ユーザ・データベース６２５に対する照会を通じて判定する。オンラインでない場合、新たな電子メール通知をユーザ・データベース９０６の中で待ち行列に入れ、後にサービス１００に接続する次のときに、ワイヤレス・デバイス１０１に送信する。

ワイヤレス・デバイス１０１がオンラインの場合、９０８において、ディスパッチャは新電子メール通知をワイヤレス・デバイス１０１に送信する。９０９において、電子メール・プロキシ６１０は、ワイヤレス・デバイス１０１から新たな電子メール・メッセージ全ての要求を受信する（例えば、ある指定されたＧＩＤ値よりも上）。９１０において、電子メール・プロキシは、新たな電子メール・メッセージを読み出し、フォーマットし直し、ディスパッチャに送信する（例えば、これらを１つの応答に束ねることによって）。次いで、９１２において、ディスパッチャ６１５は、電子メール・メッセージをワイヤレス・デバイスに送信しようとする。

送信に成功したと９１４において判定した場合、プロセスは終了する。しかしながら、送信が失敗であった場合、ディスパッチャ６１５は、９１８において、再送信閾値条件（例えば、時間閾値または再送信試行閾値を過ぎていない）に達していないと判定される限り、９２０において、電子メール・メッセージをそのローカル・メッセージ・キューから送信しようとし続ける。再送信閾値に達した場合、９２２において、電子メール・メッセージをディスパッチャのキューから、ユーザ・データベース６２５内にある長期係属メッセージ・キュー（例えば、係属メッセージ表８００）に送信する。

電子メール調整および同期システムの新たな実施形態
図１０は、内部および外部電子メール・メール・サーバからの電子メール・メッセージを管理する更に別の技法を採用したアーキテクチャを示す。この実施形態では、電子メール・メッセージの同期、配信、およびスケジューリングは、非同期新メール通知受信部１００５、タスク・キュー１００６、同期部１００７、メール・キャッシュ１００８、およびスケジューラ１００９を含む、様々な新たなコンポーネントによって遂行する。特に明記しない限り、図１０に示すコンポーネントは、先に説明した対応するコンポーネント（例えば、ＤＢプロキシ１０１４、ディスパッチャ１０１２、メール・プロキシ１０１０等）と同じくまたは同様に動作するものとする。

本発明の一実施形態では、タスク・キュー１０１４は、非同期新メール通知受信部１００５、スケジューラ１００９、メール・プロキシ１０１０、および同期部１００７のような、他のシステム・コンポーネントによってタスクが置かれるキュー（または一連のキュー）である。タスク・キュー１０１４は、厳密には線形キューではない。これは、リレーショナル・データベースであり、例えば、項目がキューの中にいる時間長、タスクの優先度が高いか低いか、そしてそれが他のタスクと合体することができるか否かを含む、複雑な発見的方法に応じて、このリレーショナル・データベースから、実行する次のタスクに照会することができる。データベースの実施態様では、別個のタスクをデータベースの各行に格納することもできる。また、タスク・キュー１００６は、乱調状態（例えば、２つのエンティティが同じタスクを同時に完了させようとする場合に発生する可能性がある）を防止するために原子的歯止め動作 (atomic locking operation)を実行する１つ以上の小さなサーバ・アプリケーションを含むこともできる。一旦タスクがタスク・キューに入力されると、これらは続いて、同期部１００７（以下で説明する）のような他のコンポーネントによって処理される。

図１１に示すように、タスク・キュー１００６は、複数の個別キュー１１０１〜１１０３で構成することができ、各キューは、同様の種類および／または優先度のタスク１１１０〜１１１３を収容する。例えば、各タスク・キュー１１０１〜１１０３は、異なる優先度レベルを表すことができる。この実施形態では、他の変数が全て等しいとすると（例えば、各タスクがキュー内にある時間長のような）、相対的に高い方の優先度レベルを有するキューの中にあるタスクは、相対的に優先度レベルが低いタスクに先だってサービスされる。あるいは、または加えて、各タスク・キュー１１０１〜１１０３は、異なる種類のタスクを格納することもできる。例えば、非同期新メール通知受信部１００５が供給する新電子メール通知を１つのキューに入れてもよく、スケジューラ１００９によってスケジュールが組まれた電子メール動作を別のキューに入れてもよく、更に同期部１００７が生成したメッセージ本体要求を第３のキューに入れてもよい。

勿論、異なるタスク「種類」は、実際には、各タスク種類の異なるスケジューリング要件を満たすように、異なる優先度を表すこともできる。例えば、メール・プロキシ１０１０が生成するユーザ行動／要求は、速い折返しを必要とし、したがって「高優先度」キューに追加される。同期タスクは、関係する項目を纏めてバッチ処理できるように、ランダム・アクセスが可能なキューに入れるとよい。スケジューラ１００９が生成するようなその他のタスクは、通常の中間優先度の先入れ先出し（「ＦＩＦＯ」）キューに入れればよい。本発明の基礎原理に従いつつも、タスクを特徴付け、これらのタスクを区別してキューに入れる種々の代替技法および／または追加技法も用いることができる。

また、本発明の一実施形態はメール・キャッシュ１００８も含み、この中には、ユーザの種々のメール・アカウントの最後の既知状態を表すメッセージ・データ、デバイスに送信したデータ、デバイスにこれから送信しなければならないデータ、種々のメール・アカウントにこれから送信しなければならないデータ、および性能向上のためにキャッシュするメッセージ本体の過渡的ローカルコピー(transient local copy)を格納する。メッセージ・データを格納するために、メール・キャッシュ１００８内には１つ以上のリレーショナル・データベースを用いることができる。

図１１は、メール・キャッシュ１００８の一実施形態を示す。メール・キャッシュ１００８は、論理的に、永続構造ストア１２０４と、メッセージ本体キャッシュ１２０５とに細分割されている。

永続構造ストア１２０４は、各ユーザの電子メール・アカウント（例えば、外部アカウント１００２および内部アカウント１００３）の分かっている最後の状態を反映する。一実施形態では、永続構造ストア１２０４に格納されている情報は、メッセージ本体を除くユーザのメール・データの全てを含む（例えば、送り主、主題、メッセージ受信先、メッセージ日付等）。以下に、永続構造ストアの一実施形態の枠組みの概要を示す。
１．各ユーザと関連付けられている電子メール・アカウントのリスト。
２．アカウント毎に、アクセス方法、サーバ・アドレス、認証証明書、最後の同時時刻、同期詳細履歴、および同期を実行したフォルダのリスト。
３．フォルダ毎に、電子メール・メッセージのリスト。
４．メッセージ毎に、限定ではなく、日付、主題、フラグ、送り主、および受信先を含む、当該メッセージの概要リストを作成するために十分な情報。

前述の基本的なメール・データ構造に加えて、永続構造ストア１２０４は、仮想フォルダ、メッセージ・スレッド、および全テキスト検索用単語索引も含むことができる。一実施形態では、永続構造ストア１２０４は、発信元サーバ（例えば、メール・ストア１００２、１００３）上にある各メッセージの最後の分かっている状態と、係属、未同期変化の同定(identity)を含む現在の局所状態との間の差異を維持する。

以下に、メッセージについてのサーバ上において最後に分かっている状態と現在の局所状態との間の差の例を示す。
１．メッセージをローカルに削除したが、この削除を未だ同期していない。
２．メッセージをローカルに「隠した」。これは、同期させることを意図しない削除である。
３．まだ同期されていないフラグ変化（例えば、「見た」に変化した「見ていない」の指示(designation)。
４．メッセージを異なるフォルダに移動し、まだ同期させていない。

一実施形態では、永続構造ストアは、メッセージだけでなく、フォルダに関するメタデータも格納するので、フォルダについてのサーバ上において最後に分かっている状態と現在の局所状態との間の差の例も表すことができる。これらは、フォルダの名称変更および削除も含むことができる。

一実施形態では、キャッシュ管理方針にしたがって、情報を永続構造ストア１２０４に維持する。最も単純な場合、一旦あるユーザ用の永続構造ストアが指定の閾値に達したなら、古い方の情報から除去して行き、新しい情報のための余裕を作る。あるいは、最も長い時間期間アクセスされないままでいる情報を除去して、新たな情報および／またはアクセスされた時期が遅い情報のための余裕を作る。本発明の基礎原理に従いつつも、種々のその他のキャッシュ管理方針を実施することもできる。

永続構造ストア１２０４内に格納されているメタデータは、各メール・サーバの状態を反映し、再発生が容易であるので（即ち、リモート・サーバに照会することによって）、したがってこれは過渡的と見なされる。しかしながら、メール・サーバの新たな状態を、メール・キャッシュに格納されている最後のバージョンと比較し、相違だけをデータ処理デバイスに送ることが可能になるので、メタデータをメール・キャッシュに維持することにより、重要な最適化が得られる。メール・サーバの以前の状態がなければ、データ処理デバイスに送る必要があるデータは遥かに多くなり、デバイスは、それが既に知っていることおよび知らないことを判定する責務を伴うことになる。

これらの概念を念頭に入れて、本発明の一実施形態では、複数のメール・キャッシュをサポートするために、複数のサーバをサービスの中に実装する。メール・システムに接続すると、データ処理デバイスは、当該ユーザのメール・アカウントについてのメタデータが格納されている特定のメール・キャッシュ・サーバ上に「拠点を構える」ことになる。加えて、性能のために、メール・データを共有ストレージ（例えば、ユーザ・データベース）にコピーしない。デバイスのメール・キャッシュを格納しているサーバが故障した場合（ユーザは再度拠点を構えなければならない）、本発明の一実施形態は、メール・ストアとのキャッシュなし同期反復を実行する、動作の瞬断(performance hit)を受け入れる。

本発明の一実施形態では、一部のメタデータはローカル専用である（即ち、メール・キャッシュだけに格納されている）。これは、例えば、「隠されている」というフラグが立っているメッセージを含む。他のメール・データ（メール・ストアから常に取り出すことができる）とは対照的に、このデータは確実に永続的である必要がある。これを遂行するために、永続構造ストア内に２列のデータを実装する。１つは確実に永続的であり（即ち、共有ストレージ内または複数のサーバに跨ってこれを格納することにより）、１つはそうではない。

メッセージ本体キャッシュ１２０５は、完全なメッセージ本体を保持する。これらは、永続構造ストア１２０４におけるメッセージ・メタデータと相互参照される。一実施形態では、メッセージ本体は、第２キャッシュ管理方針にしたがって、一時的にメッセージ本体キャッシュ１２０５内に格納する。第２キャッシュ管理方針は、通例、永続構造ストアのキャッシュ管理方針とは異なる。非常に大きな第三者の電子メールの可能性を想定すると、キャッシュ管理方針は、通例、いつでも一度にユーザの電子メール・データの全てをキャッシュすることはない。代わりに、インテリジェント方針を実施して、メッセージがキャッシュの中にある時間長、メッセージがアクセスされた最後の時刻、ユーザのアカウントにおける全体的な活動レベル、およびキャッシュ内に既に格納されているデータ量というような変数に基づいて、メッセージを除去する。例えば、ユーザが特定のメッセージに頻繁に（指定の閾値よりも上）アクセスする場合、メッセージ本体キャッシュ１２０５は、メッセージが比較的長い時間キャッシュの中にあるという事実にも拘わらず、メッセージのコピーを保持することができる。対照的に、あるメッセージがキャッシュの中に長い時間（例えば、第１指定時間期間）にあり、最近ユーザがアクセスしていない（例えば、第２指定時間期間）場合、メッセージ本体をメッセージ本体キャッシュから削除すればよい。メッセージを保持すべきかまたは削除すべきか判定するためには、種々のその他のキャッシュ管理変数を実装してもよい。

一実施形態では、性能を最適化するために、メッセージ本体取込部(fetcher)は、新たな入手可能な本体を検出したときはいつでも、思惑的にメール・サーバからメッセージ本体を取り出す（即ち、データ処理デバイスからの明示的な指令なくして）。一実施形態では、デバイスによって要求されるまで、思惑的に取り込んだ本体をデバイスには送信しない。

一実施形態では、データ処理デバイス１０１上に、メッセージ・キャッシングの第２レイヤを実装する。具体的には、この実施形態では、新たな電子メール・メッセージを受信すると直ちに、そのメッセージについてのメタデータを、「新メッセージ」通知と共に、データ処理デバイスに送る。一実施形態では、メタデータは、永続構造ストア１２０４に格納されているのと同じデータである。あるいは、メタデータは、永続構造ストア１２０４に格納されているデータの内、限られた部分集合（例えば、メッセージの主題、送り主、および受信先）としてもよい。メッセージ本体は、エンド・ユーザによって要求されたときにのみ、データ処理デバイスに送信される。

一実施形態では、異なるキャッシュ管理方針をデータ処理デバイス上で実施して、メタデータおよび／またはメッセージ本体をキャッシュする（即ち、システム・メール・キャッシュ１００８上で実施するキャッシュ管理方針とは異なる）。例えば、一旦メッセージ本体がデバイスにダウンロードされたなら、メッセージ本体をメッセージ本体キャッシュ内に保持する理由はない。つまり、この実施形態では、ダウンロードしたメッセージ本体を自動的にメッセージ本体キャッシュから削除する。一旦デバイス上に来れば、当該デバイス上における別個のキャッシュ管理方針にしたがって、メッセージ本体をキャッシュする。例えば、一実施形態では、所定の時間期間アクセスされなかったメッセージ本体は、エンド・ユーザによって要求されるまで、キャッシュから除去することができる。

一実施形態では、デバイス側キャッシュを管理するために、２つの判断基準、即ち、メッセージ・サイズおよびメッセージの古さを用いる。一実施形態では、最少数のメッセージをキャッシュから削除することによって殆どのメモリを取り返すように、非常に大きなメッセージ（即ち、閾値を超える）をキャッシュから除去する。これは、非常に新しく（即ち、指定時間期間以内に受信した）非常に大きなメッセージは、可能であれば、キャッシュから除去「すべきでない」という制限を受ける。

一実施形態では、同期部１００７は、デーモン（即ち、連続ループで走るソフトウェア・コンポーネント）であり、連続的にユーザのメール・アカウント１００２、１００３のキャッシュのビューを更新し、ユーザが行った変更を用いてメール・アカウントを更新し、これら２つの間の対立を調停する。また、メール・プロキシ１０１０を通じてデータを非同期的にデバイス１０１に送る。

図１２に示すように、同期部１００７の一実施形態は、メッセージ本体取込コンポーネント１２０２、および同期ロジック１２０１を含む。その名称が示唆するように、メッセージ本体取込部１２０２は、新たなメッセージ本体を読み出し、エンド・ユーザの要求時にキャッシュから除去されたメッセージ本体を取り出すことを責務とする（例えば、永続構造ストア１２０４の中に未だある可能性があるが、メッセージ本体キャッシュからは既に消去されているメッセージの本体）。メッセージ本体取込部は、外部メール・ストア１００２およびローカル・メール・ストア１００３双方と通信して、要求されたメッセージ本体を取り出す。

同期ロジック１２０１は、ユーザのメール・アカウントのメール・キャッシュのビューを更新し、ユーザが行った変更を用いてメール・アカウントを更新し、これら２つの間の対立を調停する。言い換えると、同期ロジック１２０１は、ユーザの電子メール・アカウントのローカル表現が、それらの管轄サーバ上における実際の状態と一致すること、この同じ状態がワイヤレス・デバイス１０１にも忠実に反映されること、そしていずれの末端における変更もしかるべき伝えられることを保証することを責務とするコンポーネントである。また、データをデバイスにメール・プロキシ１０１０を通じて非同期に送る。一実施形態では、帯域幅を保存するために、同期ロジック１２０１は、しかるべきときには、複数のメール動作を組み合わせる。例えば、エンド・ユーザが特定のメッセージを読み出し、修正し、フォルダに移動させ、次いで削除した場合、削除動作だけを同期させればよい。

動作において、同期部は、連続的にタスク・キュー１００６に照会して、同期する必要があるアカウントを調べる。ユーザ・アカウントに対する入力は、以下の状況では、タスク・キューの中に置かれる。
１．非同期新メール通知受信部が、外部メール・ストア１００２から、そのアカウントに対する新メール通知を（ＳＭＴＰ受信部１００４を通じて）受信したとき。
２．ユーザがワイヤレス・デバイス１０１上で、または元のアカウントに対する反映(mirroring)を必要とするウェブベースのインターフェースを通じて、メッセージ・データに対して変更を行ったとき。
３．スケジューラ１００９が、ユーザのアカウントを同期する時刻であると判定したとき。
４．ユーザの行為の結果、キャッシュ・ミスが発生し、メッセージ・データを（再）ダウンロードしなければならなくなったとき。尚、これは、ユーザの行為が概してリアル・タイムで係属中となる特殊な場合であることを注記しておく。つまり、この動作に対して、「高優先度」タスク・キュー（例えば、図１１におけるキュー１１０１）を用いるとよい。この場合、所望のコンテンツは、シンク(sync)要求に対するパラメータであり、待機中のクライアントは適時の完了通知(timely completion notice)を受信しなければならない（即ち、サービスに対する要求は、ユーザが読むのを待っているメッセージのアイデンティティを含む）。

一実施形態では、動作すべきタスク・キュー１００６からのアカウントを特定した後、同期部は、図１３に示すように、以下の行為を実行する。

１３０１．起源サーバへの接続
同期部は、最初に、アカウントの起源サーバ(origin server)（例えば、外部メール・ストア１００２またはローカル・メール・ストア１００３）に接続する。こうするために、同期部は、必要なアカウント・タイプ／位置情報、および認証証明書をＤＢプロキシ１０１４から入手し、次いでこの情報を用いてアカウントの起源サーバとの接続を確立する。

１３０２．最後の同期以来の変更を判定する
次に、同期部１００７は、最後の同期以来、そのアカウントにおいて何が変化したか判定する。こうするために、リモート・フォルダのリストおよび収容しているメッセージについての概要データを、起源サーバから取り込む。一実施形態では、「クイック・スキャン」同期モードを採用し、所与の高水位(high-water mark)よりも新しいメッセージ概要のみを照会する。このモードは、古い方のメッセージにおけるフラグ変化を見過ごすが、新しいメッセージを発見する。一旦起源サーバからデータを収集したなら、これを永続構造ストアにおけるアカウントの表現と比較する。相違が発見された場合、そのいずれもがリモート変化(remote changes)の集合を構成する。

１３０３．対立を解決する
次に、同期部は、起源サーバの変化集合とユーザのローカル変化集合との間に存在し得るあらゆる対立を解決しようとする。ユーザ・アカウントのメール・データに対する係属ローカル変化のリストをリモート変化リストと比較したときに、同じデータ項目が双方の場所で変化している場合、対立が存在しており、解決しなければならない（双方の端末で変化が同一であるのでないならば）。一実施形態では、同期部における対立検出および相関ロジックは、サーバが信頼できるという原則に基づいて、起源サーバのバージョンをローカル・バージョンよりも優先する。あるいは、一実施形態では、対立検出および相関ロジックは、ローカル変化バージョンを選択する。別の実施形態では、同期部はユーザに照会し、ユーザに正しい変化バージョンを選択させる。

１３０４．ローカル変化のアップロード
対立解決によって排除されていないローカル変化を、外部メール・サーバ１００２が要求するプロトコル・シーケンスを通じて（例えば、ＩＭＡＰ ＳＴＯＲＥコマンド、ＰＯＰ ＤＥＬＥコマンド等）、サーバにアップロードする。

１３０５．リモート変化のダウンロード
前述のステップによって未だ入手していないいずれの関連構造データも、発見したあらゆる新メッセージの本体と共にダウンロードする。結果を永続構造ストア１２０４およびメッセージ本体キャッシュ１２０５に入れる。一実施形態では、新たに追加したメッセージ本体は、ある最少時間量だけキャッシュ内に残留して、デバイスがその非同期メール変更通知に応答し、本体を要求することを可能にする。

１３０６．該当する通知の待ち行列
一旦リモート変化をダウンロードしたなら、メール・プロキシ１０１０およびディスパッチャ１０１２を通じたデバイスへの非同期配信のために、該当する通知（例えば、新メール通知、メッセージ削除通知等）を待ち行列に入れる（前述の通り）。一実施形態では、リモート変化に起因して永続構造ストアに新たな情報が入ると、デバイスへの非同期通知の配信が行われ、一方、デバイスは追加データを要求する場合もある。フラグのオンおよびオフの切り換えというような単純な変化の場合、データ自体を通知に収容してもよい。

一実施形態では、スケジューラ１００９はデーモンであり、ユーザ・アカウントに対するタスクをタスク・キュー１００６に入れることによって、同期部に、どのアカウントにおいてそしていつ動作するか指令する。スケジューラ１００９は、アカウント活動およびユーザの好みのような変数に基づいて、アカウント毎に異なるシンク−頻度発見的方法を採用してもよい。例えば、ユーザが活発に彼／彼女のアカウント上で作業している場合（例えば、活発に電子メール・メッセージを送りそして読んでいる）、スケジューラ１００９は一時的に同期の頻度を高めることができる。同様に、ユーザの外部メール・アカウント１００２が非常に活発である場合、スケジューラ１００９は同期の頻度を高めることができる（活動が少ないアカウントに対して）。一実施形態では、スケジューラ１００９はＤＢプロキシ１０１４をチェックして、アカウントの活動を判定する。ＤＢプロキシ１０１４が、ユーザのアカウントが「活発である」と判定した場合（例えば、新たなメッセージが存在するため）、スケジューラ１００９は同期の頻度を高める。対照的に、ＤＢプロキシ１０１４が、ユーザのアカウントが「活発でない」と判定した場合（例えば、ユーザがオフラインである、および／または新たなメッセージが存在しない）、スケジューラ１００９は同期の頻度を低くする。同様に、最後の同期中に一過性のエラー(transient error)が発生した場合（例えば、期限切れまたは誤ったパスワードまたはその他の認証データのために）、スケジューラ１００９は、同期の頻度をさらに大きく低下させてもよく、または、エラーが解決するまで（例えば、正しいユーザ名およびパスワードがシステムに供給されるまで）予定した同期をディスエーブルしてもよい。一般に、スケジューラが採用する発見的方法は、限定ではなく、以下の変数を含む。最後の同期の時刻、同期の時のエラー頻度、このアカウントにおいて見られるメールの分量、外部メール・プロバイダの要件／選択、および同期させ直す係属中の変化の分量。

前述のように、一実施形態では、メール・プロキシ１０１０はワイヤレス・デバイス１０１に対して待ち行列機能を実行し、ディスパッチャ１０１２を通じてデバイスに伝達する。例えば、同期部１００７による同期、および／または非同期新メール通知受信部１００５が受信した新メール通知に応答して、メール・プロキシ１０１０は、新メール通知をワイヤレス・デバイス１０１にプッシュする。一実施形態では、新メッセージ通知は、メッセージ毎にメタデータを含む（例えば、送り主ＩＤ、主題、日時等のような、永続構造ストア１２０４に格納されている情報と同一、またはその部分集合）。メタデータを用いて、ユーザは次にメッセージ本体全てをメッセージ本体キャッシュ１２０５に要求することができる。

一実施形態では、ＳＭＴＰ受信部１００４は、外部ＳＭＴＰサーバ１００１からのインバウンドＳＭＰＴ要求（例えば、新メッセージのような電子メール・アカウント更新）を処理する。また、新たなメッセージをローカル・メール・ストア１００３に入れる前に、スパム・フィルタリングおよび添付ファイル抜き取りを実行することもできる。一旦インバウンド・メッセージをローカル・メール・ストア１００３に入れたなら、非同期新メール通知受信部１００５に、新たなメッセージの到達に対して警報する。

一実施形態では、ローカル・メール・ストア１００３は、内部ユーザ・アカウントに属するメッセージ、および外部ＳＭＴＰサーバ１００１から受信した外部メッセージを格納するところである。これは、外部メール・アカウント１００２と全く同様に、ＩＭＡＰサーバとしてもよく、その場合、ローカル・メール・ストア１００３と外部アカウント１００２との間にある唯一の相違（同期部１００７およびメール・キャッシュ１００８のような他のシステム・コンポーネントの観点から）は、ローカル・メール・ストア１００３がサービス１００によってホストされることだけである。

前述のように、非同期新メール通知受信部１００５は、ユーザの種々の電子メール・アカウント（例えば、外部アカウント１００２およびローカル・メール・アカウント１００３）における新メールの到達に関する非同期の通知を扱う。ある種の外部アカウント１００２は、新メール通知を非同期新メール通知受信部１００４にプッシュすることによって、外部アカウントを連続的にポールして変化を見つける必要性を軽減することもできる。

図１４は、１つ以上の電子メール・ストア１４０１〜１４０３とワイヤレス・データ処理デバイス１０１との間において、同期モジュール１４０７およびメール・キャッシュ１４０８を用いて電子メールを同期するシステムの別の実施形態を示す。注記すべきは、この実施形態は、前述の実施形態のように、スケジューラやタスク・キューを含まないことである。同期は、データ処理デバイス１０１上のメール・データの状態に対する修正のような、デバイス主導イベントに基づいて実行する。

図１４に示すサービスによって実現するメール・ストアと同期させるための方法の一実施形態を図１５に示す。１５０１ａにおいて、データ処理デバイス上でユーザがメール動作を実行する。例えば、ユーザは１つ以上の電子メール・メッセージを削除するとしてもよい。

１５０２において、この動作および電子メール・メッセージ（群）の識別情報を同期モジュール１４０７に報告する（メール・プロキシ１０１０を通じて）。１５０３において、同期部１４０７はメール・ストア１４０１〜１４０３の１つにおいて動作を実行しようとする（即ち、動作が実行された電子メール・メッセージを収容するメール・ストア）。１５０４において、そのメール・ストアは、必要であれば、動作に対して対立解決を実行する。同期部が要求した動作が以前の動作と対立する場合、メール・サーバは同期部による要求を拒絶することもできる。一例として、ユーザがデスクトップ・インターフェース（例えば、ウェブ・ブラウザ）を通じてメール・ストアに接続し、電子メール・メッセージをデータ処理デバイスから削除する前にその電子メール・メッセージを新たなフォルダに移動させた後に、削除の試行は失敗に終わる。メール・ストア上には、種々のその他の既知の対立解決技法を実施することもできる。

１５０５において、同期部１４０７は、動作が要求されたメール・ストアから、更新した状態情報を取り出す。上の例に戻って、電子メール・メッセージを新たなフォルダに移動させたために削除動作が失敗した場合、この情報を同期部１４０７に送る。

１５０６において、同期部１４０７はメール・キャッシュ１４０８の中にある状態情報を更新する。一実施形態では、メール・キャッシュ１４０８は、前述のメール・キャッシュ１００８と同じアーキテクチャを採用する。例えば、メール・キャッシュは、各ユーザのメール・ストアの状態に関するメタデータを格納する永続構造ストア１２０４と、メッセージ本体をキャッシュするメッセージ本体キャッシュ１２０５とを含む。 このようにして、更新した状態情報を永続構造ストア１２０４および／またはメッセージ本体キャッシュ１２０５において反映させる。

１５０７において、メール・キャッシュ１４０８は更新した変更をワイヤレス・データ処理デバイス１０１に送信する。

一実施形態では、前述したような複数の同期部およびメール・キャッシュを、複数の物理的サーバを跨いで実装する。ユーザをサービスに接続するとき、ユーザのメール・キャッシュを特定のサーバに維持する。即ち、サービス内における特定のメール・キャッシュ・サーバおよび／または同期部を、そのユーザの拠点とする。サービスが、ユーザに代わって、特定のメール・ストアに接続したい場合、最初にチェックを行って、特定のメール・サーバ・キャッシュおよび同期部がユーザの拠点になっているか否か判定する。この情報は、ユーザ・データベース内に維持するとよい。そうなっている場合、メール要求をそこに向ける。この場合、リモート・メール・サーバへの生の接続が既に確立されていてもよく、再利用することができる。

ユーザのリモート・メール・サーバ・セッションに関する大量の状態が、ユーザ／アカウントの拠点となっているメール・キャッシュにローカルに維持されている。このデータは、サーバおよびネットワーク挙動(performance)についてはローカルである。そのユーザ／アカウントの拠点を別のノードに移し易くするために（例えば、サーバが故障した場合、または異なるサーバの集合間で負荷のバランスを取り直すことが望まれる場合）、本発明の一実施形態では、ユーザ・データベースのような共有ストレージにローカル状態を移動させる（即ち、ＤＢプロキシを通じて）。

本発明の実施形態は、以上に明記したような種々のステップを含むことができる。これらのステップは、汎用または特殊目的プロセッサにある種のステップを実行させる機械実行可能命令に具体化することができる。あるいは、これらのステップは、当該ステップを実行するハードワイヤ・ロジックを内蔵する特定のハードワイヤ・コンポーネントによって、またはプログラミングしたコンピュータ・コンポーネントおよびカスタム・ハードウェア・コンポーネントの任意の組み合わせによって実行することもできる。

また、本発明の実施形態は、機械実行可能命令を格納する機械読み取り可能媒体として提供することもできる。機械読み取り可能媒体は、限定ではなく、フロッピ・ディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、伝搬媒体、あるいは電子命令を格納するのに適したその他の種類の媒体／機械読み取り可能媒体を含むことができる。例えば、本発明は、通信リンク（例えば、モデムまたはネットワーク接続）を通じて搬送波またはその他の伝搬媒体に具体化したデータ信号によってリモート・コンピュータ（例えば、サーバ）から要求元コンピュータ（例えば、クライアント）に転送することができるコンピュータ・プログラムのようにダウンロードすることもできる。

以上の説明全体を通じて、説明の目的上、本発明の完全な理解を得るために、多数の具体的な詳細を明記した。しかしながら、本発明はこれらの具体的な詳細の一部がなくても実用化可能であることは、当業者には明白であろう。例えば、図１０に示した機能モジュールは、各々、別個の物理的サーバ機として実現することができ、あるいは複数の物理的機械に跨って分散させることもできる。更に、ある種のモジュールを１つの機械の上で共に集合化することもできる。加えて、以上では本発明の実施形態をＩＭＡＰおよびＰＯＰの文脈で説明したが、本発明の基礎原理は、いずれの特定の種類のプロトコルにも限定されない。したがって、本発明の範囲および主旨は、以下に続く特許請求の範囲に関して判断すべきものとする。

Claims (21)

1. コンピュータ実装方法であって、
   ワイヤレス・データ処理デバイスの代わりに、第１電子メール・サーバから第１電子メール・メッセージ集合を取り出すステップと、
   前記第１電子メール・メッセージ集合からメタデータを抽出するステップと、
   前記メタデータを第１キャッシュに格納するステップであって、第１キャッシュ管理方針にしたがって前記第１キャッシュが管理される、ステップと、
   前記電子メール・メッセージの少なくともメッセージ本体を第２キャッシュに格納するステップであって、第２キャッシュ管理方針にしたがって前記第２キャッシュが管理される、ステップと、
   を備えた、コンピュータ実装方法。
2. 請求項１記載の方法であって、更に、
   前記第１キャッシュから前記ワイヤレス・データ処理デバイスに前記メタデータの一部を自動的に送信するステップと、
   前記ワイヤレス・データ処理デバイスから前記メッセージ本体に対する要求を受信したときにのみ、メッセージ本体を前記ワイヤレス・データ処理デバイスに送信するステップと、
   を備えた、方法。
3. 請求項２記載の方法であって、更に、
   第３キャッシュ管理方針にしたがって、前記ワイヤレス・データ処理デバイス上において前記メッセージ本体およびメタデータを管理するステップを備えた、方法。
4. 請求項１記載の方法において、前記第１キャッシュ管理方針は、メタデータを、該メタデータに関連したメッセージ本体を前記第２キャッシュ管理方針が保持するよりも相対的に長い時間保持する、方法。
5. 請求項１記載の方法において、前記メタデータは、少なくとも、メッセージ識別コード、メッセージ送り元、およびメッセージ主題を含む、方法。
6. 請求項１記載の方法であって、更に、
   前記ワイヤレス・デバイスから電子メールに対する要求を受信するステップと、
   前記電子メール・メッセージの本体が前記第２キャッシュに格納されているか否か判定するステップと、
   前記メッセージ本体が前記第２キャッシュに格納されていない場合、前記第１電子メール・サーバから前記電子メール・メッセージ本体を取り出すステップと、
   前記電子メール・メッセージ本体を前記ワイヤレス・デバイスに送信するステップと、
   を備えた、方法。
7. 請求項１記載の方法であって、更に、
   前記ワイヤレス・データ処理デバイスの代わりに、第２電子メール・サーバから第２電子メール・メッセージ集合を取り出すステップと、
   前記第２電子メール・メッセージ集合からメタデータを抽出するステップと、
   前記第１電子メール・メッセージ集合からの前記メタデータと共に、前記第２電子メール・メッセージ集合からの前記メタデータを前記第１キャッシュに格納するステップと、
   前記第２電子メール・メッセージ集合の少なくともメッセージ本体を、前記第1電子メール・メッセージ集合のメッセージ本体と共に前記第２キャッシュに格納するステップと、
   を備えた、方法。
8. プログラム・コードを格納する少なくとも１つのメモリと、
   前記プログラム・コードを処理する少なくとも１つのプロセッサであって、
   ワイヤレス・データ処理デバイスの代わりに、第１電子メール・サーバから第１電子メール・メッセージ集合を取り出す動作と、
   前記第１電子メール・メッセージ集合からメタデータを抽出する動作と、
   前記メタデータを第１キャッシュに格納する動作であって、第１キャッシュ管理方針にしたがって前記第１キャッシュが管理される、動作と、
   前記電子メール・メッセージの少なくともメッセージ本体を第２キャッシュに格納する動作であって、第２キャッシュ管理方針にしたがって前記第２キャッシュが管理される動作と、
   を実行する、少なくとも１つのプロセッサと、
   を有する、電子メール・メッセージ・キャッシュ・システム。
9. 請求項８記載のシステムであって、
   前記第１キャッシュから前記ワイヤレス・データ処理デバイスに前記メタデータの一部を自動的に送信する動作と、
   前記データ処理デバイスから前記メッセージ本体に対する要求を受信したときにのみ、メッセージ本体を前記ワイヤレス・データ処理デバイスに送信する動作と、
   を、前記プロセッサに実行させる追加のプログラム・コードを含む、システム。
10. 請求項９記載の方法であって、
    第３キャッシュ管理方針にしたがって、前記ワイヤレス・データ処理デバイス上において前記メッセージ本体およびメタデータを管理する動作を、前記プロセッサに実行させる追加のプログラム・コードを含む、方法。
11. 請求項８記載の方法において、前記第１キャッシュ管理方針は、メタデータを、該メタデータと関連したメッセージ本体を前記第２キャッシュ管理方針が保持するよりも相対的に長い時間保持する、方法。
12. 請求項８記載の方法において、前記メタデータは、少なくとも、メッセージ識別コード、メッセージ送り元、およびメッセージ主題を含む、方法。
13. 請求項８記載の方法であって、
    前記ワイヤレス・デバイスから電子メールに対する要求を受信する動作と、
    前記電子メール・メッセージの本体が前記第２キャッシュに格納されているか否か判定する動作と、
    前記メッセージ本体が前記第２キャッシュに格納されていない場合、前記第１電子メール・サーバから前記電子メール・メッセージ本体を取り出す動作と、
    前記電子メール・メッセージ本体を前記ワイヤレス・デバイスに送信する動作と、
    を、前記プロセッサに実行させる追加のプログラム・コードを含む、方法。
14. 請求項８記載の方法であって、
    前記ワイヤレス・データ処理デバイスの代わりに、第２電子メール・サーバから第２電子メール・メッセージ集合を取り出す動作と、
    前記第２電子メール・メッセージ集合からメタデータを抽出する動作と、
    前記第１電子メール・メッセージ集合からの前記メタデータと共に、前記第２電子メール・メッセージ集合からの前記メタデータを前記第１キャッシュに格納する動作と、
    前記第２電子メール・メッセージ集合の少なくともメッセージ本体を、前記第1電子メール・メッセージ集合のメッセージ本体と共に前記第２キャッシュに格納する動作と、
    を、前記プロセッサに実行させる追加のプログラム・コードを含む、方法。
15. プログラム・コードが格納された機械読み取り可能媒体であって、前記プログラム・コードが機械によって実行されると、該機械に、
    ワイヤレス・データ処理デバイスの代わりに、第１電子メール・サーバから第１電子メール・メッセージ集合を取り出す動作と、
    前記第１電子メール・メッセージ集合からメタデータを抽出する動作と、
    前記メタデータを第１キャッシュに格納する動作であって、第１キャッシュ管理方針にしたがって前記第１キャッシュが管理される、動作と、
    前記電子メール・メッセージの少なくともメッセージ本体を第２キャッシュに格納する動作であって、第２キャッシュ管理方針にしたがって前記第２キャッシュが管理される、動作と、
    を実行させる、機械読み取り可能媒体。
16. 請求項１５記載のシステムであって、
    前記第１キャッシュから前記ワイヤレス・データ処理デバイスに前記メタデータの一部を自動的に送信する動作と、
    前記データ処理デバイスから前記メッセージ本体に対する要求を受信したときにのみ、メッセージ本体を前記ワイヤレス・データ処理デバイスに送信する動作と、
    を、前記機械に実行させる追加のプログラム・コードを含む、システム。
17. 請求項１６記載の方法であって、
    第３キャッシュ管理方針にしたがって、前記ワイヤレス・データ処理デバイス上において前記メッセージ本体およびメタデータを管理する動作を、前記機械に実行させる追加のプログラム・コードを含む、方法。
18. 請求項１５記載の方法において、前記第１キャッシュ管理方針は、メタデータを、該メタデータと関連したメッセージ本体を前記第２キャッシュ管理方針が保持するよりも相対的に長い時間保持する、方法。
19. 請求項１５記載の方法において、前記メタデータは、少なくとも、メッセージ識別コード、メッセージ送り元、およびメッセージ主題を含む、方法。
20. 請求項１５記載の方法であって、
    前記ワイヤレス・デバイスから電子メールに対する要求を受信する動作と、
    前記電子メールの本体が前記第２キャッシュに格納されているか否か判定する動作と、
    前記メッセージ本体が前記第２キャッシュに格納されていない場合、前記第１電子メール・サーバから前記電子メール・メッセージ本体を取り出す動作と、
    前記電子メール・メッセージ本体を前記ワイヤレス・デバイスに送信する動作と、
    を、前記機械に実行させる追加のプログラム・コードを含む、方法。
21. 請求項１５記載の方法であって、
    前記ワイヤレス・データ処理デバイスの代わりに、第２電子メール・サーバから第２電子メール・メッセージ集合を取り出す動作と、
    前記第２電子メール・メッセージ集合からメタデータを抽出する動作と、
    前記第１電子メール・メッセージ集合からの前記メタデータと共に、前記第２電子メール・メッセージ集合からの前記メタデータを前記第１キャッシュに格納する動作と、
    前記第２電子メール・メッセージ集合の少なくともメッセージ本体を、前記第1電子メール・メッセージ集合のメッセージ本体と共に前記第２キャッシュに格納する動作と、
    を、前記機械に実行させる追加のプログラム・コードを含む、方法。

Images