(57)【特許請求の範囲】
【請求項１】
複数のサーバの間でメッセージを転送するための、内部接続の前記複数のサーバを有するコンピュータネットワークにおいて、前記複数のサーバのいくつかのサーバは、当該サーバに対してフィルタリング情報を通信するようには構成されていない通信プロトコルを使用し、前記コンピュータネットワークは複数のクライアントコンピューティングデバイスをも有する、クライアント側の追跡メカニズムを使用する方法であって、前記追跡メカニズムはクライアントコンピューティングデバイスに、クライアントコンピューティングデバイスでフィルタリングするために、どのメッセージを前記いくつかのサーバからダウンロードする必要があるかを決定させ、その結果、前記メッセージをメッセージストアにダウンロードする前に前記フィルタリングの処理が行われる方法において、
前記クライアントコンピューティングデバイスで、前記コンピュータにより、新しいメッセージのためのフィルタリング基準を設定するステップと、
前記クライアントコンピューティングデバイスで、該クライアントコンピューティングデバイス内のコンピュータにより、前記サーバに対して前記フィルタリング情報を通信するようには構成されていない通信プロトコルを使用する少なくとも１つのサーバに保持されている全てのメッセージを示すリストを受け取るステップと、
前記クライアントコンピューティングデバイスで、以前のフィルタリング基準に合致し、前記メッセージストアに置かれているメッセージを示すレコードを含むメッセージストアテーブルを前記コンピュータにより取り出し、当該各レコードを前記コンピュータによりフラグでマーキングするステップと、
前記クライアントコンピューティングデバイスで、前記フィルタ基準によりチェックされ、該フィルタ基準に合致しないと判定されたメッセージを示すレコードを有するチェック済みテーブルを前記コンピュータにより取り出し、当該各レコードを前記コンピュータによりフラグでマーキングするステップと、
前記少なくとも１つのサーバで保持されている全てのメッセージについてのリストの示すメッセージと、前記メッセージストアテーブル内に含まれるレコードとを前記コンピュータにより比較するステップと、
前記少なくとも１つのサーバで保持されている全てのメッセージについてのリストの示すメッセージと、前記チェック済みテーブル内に含まれるレコードとを前記コンピュータにより比較し、各メッセージについて、該メッセージが前記チェック済みテーブルにあるか否かを前記コンピュータにより判定するステップであって、該チェック済みテーブルは前記フィルタ基準によりすでにチェックし前記フィルタ基準に合致しなかったメッセージを示すレコードを有する、判定するステップと、
前記メッセージストアテーブルあるいは前記チェック済みテーブルのどちらのテーブル内のレコードにも対応しない、前記リストの全てのメッセージを前記クライアントコンピューティングデバイスの受信箱に、前記コンピュータによりダウンロードするステップであって、その結果ダウンロード時間がメッセージストアテーブルおよびチェック済みテーブルから定まる新しいメッセージだけに限定される、ダウンロードするステップと、
前記メッセージストアテーブルまたは前記チェック済みテーブルが示し、前記リストにより示されるメッセージに対応する、前記メッセージストアテーブルまたは前記チェック済みテーブル内に含まれるレコードのフラグを解除するステップと、
前記コンピュ−タにより、ダウンロードした全ての新しいメッセージについて前記フィルタ基準に合致しているかをチェックし、前記フィルタ基準に合致する場合には新しいマーキングしていないレコードを前記メッセージストアテーブルに加え、前記フィルタ基準に合致しない場合には新しいマーキングしていないレコードを前記チェック済みテーブルに加えるステップと、
前記メッセージストアテーブルおよび前記チェック済みテーブル内のフラグでマーキングされたレコードを前記コンピュータにより削除するステップと
を実行することを特徴とする方法。
【請求項２】
前記クライアントコンピューティングデバイスは、該クライアントコンピューティングデバイス上で実行される複数のアプリケーションプログラムを有し、当該複数のアプリケーションプログラムのうちの１つまたは複数のアプリケーションプログラムは個々のアプリケーションプログラムにより処理されるメッセージ情報のためのフィルタ基準をユーザにより確立することが可能なように構成されていることを特徴とする請求項１に記載の方法。
【請求項３】
前記クライアントコンピューティングデバイスは、各アプリケーションプログラムが、該アプリケーションプログラムのためのメッセージをストアし、ストアされたメッセージを取り出すことを可能にするメッセージストア管理用コンポーネントを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記クライアントコンピューティングデバイスは異なる種類のメッセージを通信することが可能な通信デバイスを有することを特徴とする請求項３に記載の方法。
【請求項５】
前記メッセージはＩＭＡＰ４、ＳＭＳ、ＰＯＰ３、アクチブシンク、ＩＭおよびＭＭＳのすべてあるいはいずれかの種類であることを特徴とする請求項３に記載の方法。
【請求項６】
前記メッセージを示すリストを受け取るステップはＰＯＰ３サーバへのＵＩＤＬコマンドを発行するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記フィルタ基準は時間枠を含むことを特徴とする請求項１に記載の方法。
【請求項８】
複数のサーバの間でメッセージを転送するための、内部接続の前記複数のサーバを有するコンピュータネットワークにおいて使用されるプログラムであって、前記複数のサーバのいくつかのサーバは、当該サーバに対してフィルタリング情報を通信するようには構成されていない通信プロトコルを使用し、前記コンピュータネットワークはクライアント側の複数のコンピューティングデバイスをも有し、前記プログラムはコンピュータ実行可能命令を有し、該コンピュータ実行可能命令は、クライアント側の追跡メカニズムを使用する方法を実行させ、前記追跡メカニズムはクライアント側のコンピューティングデバイスに、クライアント側のコンピューティングデバイスでフィルタリングするために、どのメッセージを前記いくつかのサーバからダウンロードする必要があるかを決定させ、その結果、前記メッセージをメッセージストアにダウンロードする前に前記フィルタリングの処理が行われるプログラムにおいて、該プログラムのコンピュータ実行可能命令は請求項１に記載の方法をコンピュータに実行させることを特徴とするプログラム。
【請求項９】
請求項１に記載の前記メッセージを示すリストを受け取るステップはＰＯＰ３サーバへのＵＩＤＬコマンドを発行するステップを含むことを特徴とする請求項８に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、データを受け取るコンピューティング装置に関し、詳細には、コンピュータと携帯電話とを含むモバイルコンピューティング装置に関する。
【背景技術】
【０００２】
携帯情報端末（ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｔ）、最新型携帯電話、ハンドヘルドコンピュータ、ポケットサイズコンピュータ、タブレットパーソナルコンピュータなどのモバイルコンピューティング装置は、ユーザツールとしてますます重要になり、普及しつつある。この種の装置は、一般に、小型化してきわめて便利になり、しかも、バッテリ電力消費も少なくなっていると同時に、より高機能なアプリケーションを実行することができるようになっている。
【０００３】
遠隔接続を介して、電子メールメッセージなどの様々なメッセージを送受信することができる。送受信可能な他の種類のメッセージとしては、ショートメッセージサービス（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ：ＳＭＳ）メッセージがあり、これは短い英数字メッセージ（最高１６０文字）を移動体通信ネットワーク内の携帯電話間で送受信するための標準である。このような装置は、受信データおよびその他のユーザデータを、ローカルおよび／またはインターネットを含むネットワークへの接続で記憶することができる。一般に、この種のコンピュータおよびコンピュータベースの携帯電話（Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）Ｍｏｂｉｌｅ  ｓｏｆｔｗａｒｅ  ｆｏｒ  Ｓｍａｒｔｐｈｏｎｅｓなどを実行するものなど）では、ユーザは従来の携帯電話通話、インターネットへのアクセス、添付ファイルを含むメッセージの送受信、連絡先の記憶、アポイントメントの保持、および現在のデスクトップコンピュータが実行可能なその他の多くの事を行うことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、記憶容量や帯域幅を含めて、モバイル装置の資源は限られている。その結果、ある種のサーバデータはその全体をダウンロードし、保持することができない。例えば、電子メールメッセージと共に使用されるＰＯＰ３プロトコルを考えてみる。ユーザが、最近３日以内に受け取ったメッセージのみなど、メッセージのフルセットではなくサブセットのみをロードしたい場合、装置はそれらのメッセージを評価し、不要なメッセージを廃棄する必要がある。これは、電子メールクライアントが着信メールサーバに電子メールメッセージのダウンロードを制限するように指示することができるようにするコマンドが、ＰＯＰ３プロトコルには備わっていないためである。しかし、処理容量が限られているため、ユーザにそのようなメッセージが多量にある場合、メッセージデータをフィルタリングのために定期的にダウンロードするのは苛立つことである。例えば、ＰＯＰ３メッセージの日付を判定するには、そのメッセージのために２キロバイト程度のデータがダウンロードされる。多くのユーザがそうであるように、数千通のメッセージがあって各メッセージをそのようなフィルタリングのために処理する必要がある場合、数百万バイト程度のデータをダウンロードする必要があり、それにはかなりの時間を要する。実際、この種のフィルタリングでは、部分ダウンロードにもフルダウンロードと同程度の時間がかかる場合がある。例えば、通信プロトコルがフィルタリング情報をサーバに送るように構成されていない場合など、フィルタリングをクライアント側で行う必要がある場合に、装置がフィルタリングのためにサーバからデータのサブセットを効率的にダウンロードする方法が必要である。
【課題を解決するための手段】
【０００５】
要約すると、本発明は、クライアント側の追跡メカニズムによって、コンピューティング装置が、フィルタリングのためにサーバからどのメッセージをダウンロードする必要があるかを効率的に判定し、それらのメッセージのみを要求することができるようにするシステムおよび方法を対象とする。
【０００６】
一態様では、本発明は、メッセージデータがダウンロードされる前に、実質的にフィルタリング動作のほとんどを行う。例えば、本発明を使用して、ＰＯＰ３電子メールメッセージのダウンロードを最近ｎ日間に受け取った電子メールメッセージのみに制限することができ、その際、現行のフィルタリング動作よりも数桁速い効率的な方法で行うことができる。
【０００７】
この目的のために、ユーザ指定フィルタリング基準を満足しないメッセージ、例えば所望の時間（日付）枠外のメッセージがダウンロードされる場合、そのメッセージデータは廃棄され、そのメッセージが基準を満たしていないという状態が、その固有識別子（ＩＤ）に基づいて「既チェック済み」（または単に「チェック済み」）テーブルに保存される。その後のデータ要求時（例えば、ＰＯＰ３サーバに対する受信箱アプリケーションプログラムの送信／受信要求時）、固有メッセージＩＤのリストが入手される。サーバに対してメッセージデータのダウンロードを要求する前に、主メッセージストアとチェック済みテーブルを調べ、固有ＩＤがいずれのストアにもない場合のみ、当該メッセージデータがダウンロードされる。
【０００８】
サーバとの同期を維持するため、また、チェック済みテーブルが際限なく膨張し続けないようにするため、サーバで削除された各項目は、そのレコードがチェック済みテーブルから削除される。そのために、チェック済みテーブル内の各メッセージレコードにはフラグが関連付けられ、固有メッセージＩＤのリストと照合するのに先立って設定される。リスト内の各メッセージＩＤを調べて、当該メッセージＩＤがリストされており、チェック済みテーブルにもある場合、当該メッセージのフラグが解除される。リストの処理の完了時、チェック済みテーブル内のレコードに設定されたままになっているメッセージフラグは、サーバによってリストされていなかったメッセージに対応し、したがってサーバ側ですでに削除されている。そのような各メッセージのレコードは、チェック済みテーブルから削除される。
【０００９】
その他の利点は、図面と共に以下の詳細な説明を読めば明らかになろう。
【発明を実施するための最良の形態】
【００１０】
動作環境の例
図１に、プロセッサ１２２、メモリ１２４、表示装置１２６、およびキーボード１２８（物理キーボードまたは仮想キーボード、あるいはその両方とすることができる）を含む、１つのハンドヘルドコンピューティング装置１２０の機能構成要素を示す。音声入力を受け取るためにマイクロフォン１２９も備えることができる。メモリ１２４は、一般に、揮発性メモリ（例えばＲＡＭ）と不揮発性メモリ（例えばＲＯＭ、ＰＣＭＣＩＡカードなど）の両方を含む。メモリ１２４には、マイクロソフトコーポレーションのＷｉｎｄｏｗｓ（登録商標）またはその他のオペレーティングシステムなどのオペレーティングシステム１３０が常駐し、プロセッサ１２２上で実行される。
【００１１】
１または複数のアプリケーションプログラム１３２がメモリ１２４にロードされ、オペレーティングシステム１３０上で実行される。アプリケーションの例としては、電子メールプログラム、スケジューリングプログラム、ＰＩＭ（個人情報管理）プログラム、ワードプロセッシングプログラム、表計算プログラム、インターネットブラウザプログラムなどがある。ハンドヘルドパーソナルコンピュータ１２０は、メモリ１２４にロードされた通知マネージャ１３４も備えることができ、プロセッサ１２２上で実行される。通知マネージャ１３４は、例えばアプリケーションプログラム１３２からの通知要求を処理する。また、後述するように、ハンドヘルドパーソナルコンピュータ１２０は、ハンドヘルドパーソナルコンピュータ１２０をネットワークに接続するのに適したネットワーキングソフトウェア１３６（例えばハードウェアドライバなど）およびネットワーク構成要素１３８（例えば無線装置とアンテナ）も備え、電話呼出し機能も備えることができる。
【００１２】
ハンドヘルドパーソナルコンピュータ１２０は、１または複数のバッテリとして実装される電源１４０を有する。電源１４０は、内蔵バッテリより優先して使用され、または内蔵バッテリに充電する、ＡＣアダプタまたは電源ドッキングクレードルなどの外部電源も含むことができる。
【００１３】
図１に示す例示のハンドヘルドパーソナルコンピュータ１２０は、２種類の外部通知メカニズム、すなわち、１または複数の発光ダイオード（ＬＥＤ）１４２と音声発生装置１４４とを備えて図示されている。これらの装置は、電源１４０に直接接続することができ、それによって、起動された場合、ハンドヘルドパーソナルコンピュータプロセッサ１２２およびその他の構成要素がバッテリ電力節約のために停止しても、通知メカニズムによって指示された期間だけオン状態を維持（保持）する。ＬＥＤ１４２は、ユーザが操作を行うまで無期限にオン状態を保持することが好ましい。最新版の音声発生装置１４４は、現在のハンドヘルドパーソナルコンピュータ用バッテリの電力を消費し過ぎるため、システムの他の部分がオフになる場合、または起動後にある程度の有限期間が経過したらオフになるように構成されていることに留意されたい。
【００１４】
基本的なハンドヘルドパーソナルコンピュータを示したが、携帯電話など、プログラムによる使用のために何らかの方法でデータ通信を受け取り、データを処理することが可能な装置であれば、事実上どのような装置でも、本発明を実施する上で同等であることに留意されたい。
【００１５】
フィルタリングのためのメッセージデータのサブセットの入手
本発明は、一般には、電子メールメッセージなどのメッセージおよび同様のデータ通信の処理を対象とし、特に、携帯電話を含む小型モバイルコンピューティング装置での処理を対象とする。しかし、当然ながら、本発明はいかなる種類のコンピューティング装置にも限定されず、例えば、比較的大型の据置き型コンピューティング装置と共に使用することもできる。さらに、本発明について一般に、電子メールアプリケーションおよびメッセージに関して説明するが、本発明はいかなる特定のアプリケーションやデータの種類にも限定されず、データをダウンロードすることができる他のアプリケーションも本発明によって益を得ることができることがわかるであろう。さらに、本発明について主として、時間枠（例えば１日、２日などの１日刻み）に基づくフィルタリングに関して説明するが、事実上、所与のデータセットに適するいかなる基準も同等である。本明細書では、「基準（ｃｒｉｔｅｒｉａ）」という用語は、単一の基準だけでなく複数の基準の任意の組合せも包含することを意図したものであることに留意されたい。
【００１６】
図２を参照すると、全体が２００で示された、メール関連メッセージなどを処理するアーキテクチャが図示されている。１つのこのようなアーキテクチャ２００は、現在、Ｗｉｎｄｏｗｓ（登録商標）ｆｏｒ  Ｍｏｂｉｌｅ  Ｄｅｖｉｃｅｓを実行する装置で実装されている。この例示のアーキテクチャでは、無線装置２０１が通信を受信し、無線インターフェース層２０２が受信データへのアクセスを可能にする。複数のトランスポート２０３が設けられ、各トランスポート２０４１〜２０４ｉは、例えば、インターネットメッセージアクセスプロトコルバージョン４（Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｅ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ４：ＩＭＡＰ４）、ＳＭＳ、ポストオフィスプロトコルバージョン３（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ３：ＰＯＰ３）、アクティブシンク（Ａｃｔｉｖｅ  Ｓｙｎｃ）（Ｗｉｎｄｏｗｓ（登録商標）ベースのデスクトップコンピュータまたは交換サーバとＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ＣＥ．ＮＥＴベースの携帯用装置との間のデータの同期をサポートする）、およびその他のメッセージなどの、異なる種類のメッセージを受信（および送信）するように構成されている。そのような他のメッセージとしては、インスタントメッセージ（Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ：ＩＭ）、マルチメディアメッセージングサービス（Ｍｕｌｔｉｍｅｄｉａ  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ：ＭＭＳ）などがある。
【００１７】
一般に、アプリケーションプログラム２０６は、モバイル装置上で実行され、通信を送受信するアプリケーションが含まれる。そのようなアプリケーションプログラムとしては、受信箱アプリケーション２０８１、カレンダーアプリケーション２０８２、および連絡先関連アプリケーションプログラムなどのその他のアプリケーション２０８ｊがある。本発明の一態様によると、図３および図４を参照しながら説明するように、１または複数のそのようなアプリケーション２０８１〜２０８ｊを、ユーザがフィルタリング基準を入力することができるように構成し、それによって基準を満たすメッセージのみが携帯用データストア２１４１〜２１４ｋで保持されるようにすることができる。これらのデータストアは必ずしもアプリケーションプログラムに対応していないことに留意されたい。例えば、受信箱アプリケーション２０８１は、ＩＭＡＰ４メッセージ用に１つのストア、ＰＯＰ３メッセージ用に１つのストアなどのように、当該アプリケーションのために保持されている複数のデータストアを有することができる。
【００１８】
ＡＰＩで実施されるようなメッセージストア管理部２１２（例えばＣＥＭＡＰＩ）によって、受信箱アプリケーション２０８１などのアプリケーションは、メッセージを記憶し、記憶されたメッセージを必要に応じて取り出すことができる。一般に、メッセージストア管理部２１２は、受信箱アプリケーション２０８１などのアプリケーションからその記憶を抽出し、それによって、実質的に当該アプリケーションはメッセージデータがどこかに存在することしか知らず、当該データにはメッセージストア管理部２１２を介してアクセスすることができるようになっている。データストアからデータを受け取ることができる他のプログラムはオペレーティングシステム部であり、したがって、本発明においては、そのようなコンピュータプログラムコードは同等であるとみなすべきであることに留意されたい。
【００１９】
また、上記の記憶を備えるのではなく、より複雑ではあるが、受信箱プログラムが記憶を直接扱う、代替実施態様を用いることも本質的に同等であることに留意されたい。したがって、本明細書では、「メッセージ処理メカニズム」という用語は、受信箱アプリケーションまたはその種のものおよび／またはメッセージ記憶部を指し、適切な場合には、トランスポートの概念をも含むことができる。
【００２０】
一実施態様では、メッセージストア２１４１〜２１４ｊは、各受信箱アプリケーションサービスに関連付けられたコンポーネントオブジェクトモデル（Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ：ＣＯＭ）オブジェクトであり、メッセージストア管理部２１２は、ＩＭｓｇＳｔｏｒｅインターフェースを介してこれらのメッセージストアへのアクセスを可能にする。この実施態様では、メッセージストアライブラリが、ＩＭｓｇＳｔｏｒｅインターフェースを提供し、このインターフェースが、固有のトランスポート固有記憶域へのアクセスを可能にする。例えば、受信箱は１つのメッセージストアにＳＭＳメッセージを記憶し、他のメッセージストアにＩＭＡＰ４メッセージを記憶するという具合に記憶することができる。各メッセージストアのＩＭｓｇＳｔｏｒｅインターフェースを介してアクセスされるＩＭｓｇＳｔｏｒｅ：：ＧｅｔＰｒｏｐｓおよびＩＭｓｇＳｔｏｒｅ：：ＳｅｔＰｒｏｐｓメソッドを使用して、当該ストアのカスタムプロパティがアクセスされる。
【００２１】
本発明の一態様により、以前にダウンロードされたメッセージの現在のフィルタリング基準に関する状態がわかり、それによって未知の状態にあるメッセージのみのデータがダウンロードされるように、レコードのテーブルを使用して受信箱アプリケーションプログラムのメッセージの状態を追跡する方法を図３に示す。一般に、受信箱アプリケーションプログラムの送信／受信要求に対応する時点などの適切な時点に、サーバで保持されているすべてのメッセージＩＤのリストを入手する。例えば、ＰＯＰ３環境では、このリストを入手するために、ＵＩＤＬ（固有識別子リスト）コマンドが発行され、この要求が、複数のコンピューティング装置の組合せとすることができるＰＯＰ３サーバ、例えば着信メールサーバ３２４で受け取られる。メールサーバ３２４は、これに応答してリスト３２５を返す。後述するように、ＰＯＰ３トランスポート２０３３が、メッセージストアテーブル３２６およびチェック済みテーブル３２８を参照してこのリストの内容を処理する。複数のメッセージストアが存在する場合があるため、アカウント情報３３０を使用して、当該ＰＯＰ３アカウントのテーブル名と適切なデータストアを探し出す。リストが要求側装置に初めて返されるときには、テーブルは空であり、したがって各リストメッセージのデータをフィルタリング基準に照らして評価するためにダウンロードする必要があり、基準を満たすメッセージがメッセージストア２１４ａに入れられる。メッセージストアテーブル３２６には保存された各メッセージのレコードが作成される。
【００２２】
本発明によると、フィルタリング基準を満足しないメッセージデータは廃棄されるが、当該メッセージの既知の状態（フィルタリング基準を満たさないという状態）が、チェック済みテーブル３２８内の対応するレコードに格納される。一実施態様では、より効率的な参照のために、このレコードには固有メッセージＩＤ（または図３のＵＩＤ）のハッシュで索引付けされることに留意されたい。この固有ＩＤは、当該メッセージのレコードで保持することができ、ハッシュ値が固有であることが保証されない場合に必要になる。
【００２３】
当然のことながら、次に受信箱アプリケーションプログラム２０８１を介して送信／受信同期要求が行われ、その結果、ＵＩＤＬコマンドが発行された時は、サーバが新しいリスト３２５を返す場合に、メッセージストアテーブル３２６またはチェック済みテーブル３２８にないリストメッセージのみが、現行フィルタリング基準について未知状態にある。これは、最後の要求以来、フィルタリング基準の変化（後述のように他の方法で処理される）がなかったものと仮定していることに留意されたい。
【００２４】
したがって、装置が接続、ログオンしてＵＩＤＬコマンドの結果を受け取った後、すなわちリスト３２５を受け取った後、論理（図４を参照しながら後で詳述する）は、リストされたＵＩＤをメッセージストアテーブル３２６またはチェック済みテーブル３２８内のＵＩＤと照合し、「新しい」メッセージであり、したがってテーブル３２６または３２８の１つにリストされていないメッセージのみがダウンロードされる。一実施態様では、この論理は、ＰＯＰ３トランスポート２０３３で実施されるが、容易にわかるように、この論理は受信箱アプリケーションおよび／またはメッセージストア管理部２１２など、他の部分で実施することもできる。実際に、一実施態様では、受信箱アプリケーション２０８１は、ＰＯＰ３トランスポート部を含む。
【００２５】
このような新規メッセージのメッセージデータが受信されると、論理はメッセージデータをフィルタリング基準に照らして評価し、基準を満たされている場合には、当該メッセージをメッセージストア２１４ａに入れ、メッセージストアテーブル３２６に当該メッセージのためのレコードを作成する。フィルタリング基準が満たされていない場合には、論理は、固有ＩＤ（これはハッシュ値であってもよく、または前述のようにハッシュ値に加えてもよい）を、チェック済みテーブル３２８に入れる。このように、各新規メッセージの状態が、次に送信／受信要求を受け取ったときに行われる次の評価のために保存される。
【００２６】
さらに、サーバで削除されたメッセージについては、所定のメカニズムにより、それに対応するレコードがチェック済みテーブルまたはメッセージストアから削除される（対応するメッセージデータも削除される）。サーバで削除されたメッセージストア内のメッセージは、削除項目フォルダなどに移動することもでき、その場合、レコードは保持されるが変更されることに留意されたい。しかし、これは本質的に「削除」とみなすことができ、一般に本発明には関係がない。この削除は、クライアント装置上のテーブルがサーバの状態との同期を維持するように行われ、また、テーブルに無関係のレコードが含まれないように行われる。
【００２７】
サーバでの削除に対処するために、メッセージレコードをＵＩＤリスト３２５内のＵＩＤと照合（比較）する前に各メッセージレコードがマークされ、照合完了後もマークされたままになっているメッセージレコードは削除される。具体的には、一実施形態では、各メッセージレコードにフラグが関連付けられ、固有メッセージＩＤのリストがテーブルと照合されるのに先立ってフラグが設定される。リスト内の各メッセージＩＤを調べて、当該メッセージＩＤがリストされており、テーブルにも含まれている場合、例えば当該メッセージのフラグを解除することによって当該メッセージのマークを解除する。リストの処理の完了時、テーブル内のレコードにまだ設定されているメッセージフラグは、サーバによってリストされなかったメッセージ、したがってサーバで削除済みのメッセージに対応する。そのような各メッセージのレコードは、該当するテーブルから削除される。この削除処理は各ＵＩＤが検査された後に行う必要があり、したがって、メッセージのダウンロードに先立って削除が行われない限り、メッセージのダウンロード後にテーブル内に新たに作成されるレコードはマーク解除された状態にされていなければならないことに留意されたい。
【００２８】
例えば、０から３日以内の日付のものであるメッセージのみを受信し、保持したいユーザを考えてみる。これが、送信／受信コマンドに先立つ時点でのフィルタリング基準であったと仮定すると、テーブルには該当する状態のデータが含まれることになる。ＵＩＤＬコマンドに続いてＵＩＤリストを受け取ると、各ＵＩＤについてテーブルが調べられる。送信／受信コマンドを介して頻繁に同期するユーザの場合は特に、メッセージの大部分（または場合によっては全部）がテーブルの１つに含まれていることが多く、したがってダウンロードの必要が比較的少ない。テーブルの照合はダウンロード時間に比べてきわめて高速であるため、大部分のダウンロードを回避することはきわめて効率的である。ダウンロードの場合、リストに存在し、メッセージストアテーブル３２６またはチェック済みテーブル３２８には存在しないＵＩＤは、サーバ上にある新しいメッセージであり、したがってクライアント装置には未知である。したがって、当該メッセージ（例えば少なくとも２キロバイトの関連データ）はダウンロードされ、その日付が、本実施例では３日間というフィルタリング基準に照らして評価される。３日間の時間枠内にある場合、当該メッセージはメッセージストアテーブル３２６に入れられ、それ以外の場合は、データは廃棄される。しかし、いずれの場合も、前述のようにレコードが適切なテーブルに入れられる。
【００２９】
容易にわかるように、他の基準も使用することができる。例えば、本発明は、雇用主など特定の送信元から送られたメッセージではない（他の）メッセージをフィルタにかけて除外することができる。このような実施例では、ユーザは、仕事中だけ使用するハンドヘルド装置上では仕事関係のメッセージのみを入手することができる。メッセージはサーバではなく当該装置でフィルタリングされ、したがって、ユーザは仕事に無関係のメッセージは他のコンピュータを介して（またはフィルタリング基準を変更することによって）入手することができることに留意されたい。基本的に、判定可能なデータであればいかなるデータもフィルタリング基準として使用することができるが、説明を簡単にするために、ここでは説明は日付に基づく実施例に戻る。
【００３０】
他の態様では、ユーザは、古すぎるメッセージを自分の受信箱に自動的に削除させることができる。これは、サーバでの削除とすることはできず、メモリ空間を節約するためなど、クライアント装置上のみでの削除であることに留意されたい。さらに、この削除はフィルタリング時間枠に対応していてもいなくてもよく、例えば、ユーザは３日以内のメッセージのみを受け取ることもでき、５日経過した場合にメッセージを自動的に削除することもできる。いずれにしても、日付に基づくフィルタリングを扱う場合は、クライアント装置からのメッセージの削除であってサーバからの実際の削除ではない場合、当該メッセージのメッセージデータを再びダウンロードする必要がないように、自動削除処理によってメッセージストアテーブルからレコードが削除されるときにチェック済みテーブルにレコードが追加されるようにする必要がある。しかし、ユーザが自動削除時間を日付フィルタリング時間よりも短く設定した場合（システムでこれが可能な場合）、チェック済みテーブル３２８にレコードがあることによって、通常なら日付時間枠内に入る自動削除されたメッセージがダウンロードされなくなることに留意されたい。例えば、日付時間枠が３日の場合にユーザがメッセージを２日後に自動的に削除されるように設定した場合、ユーザは、フィルタリングを防ぐための何らかの処置をとらなければ、自動削除されたメッセージを取り戻すことができなくなる。したがって、このメカニズムは、まだフィルタリング時間枠内にある自動削除メッセージを再びダウンロードするかどうかをユーザ設定可能にすることもできる。その場合、そのようなメッセージのレコードはチェック済みテーブル３２８から削除されなければならない（または追加されないようにしなければならない）。
【００３１】
前述のように、ユーザが基準を変更した場合、チェック済みテーブル３２８には無効なデータが含まれることがある。例えば、ユーザが、フィルタリング基準を３日ではなく５日の時間枠にすべきであると判定した場合、チェック済みテーブル内にある４日経過したメッセージと５日経過したメッセージがユーザによって要求されることになるが、チェック済みテーブルによってそれらのメッセージのダウンロードが阻止されるため、問題がある。ユーザが、基準を他方の方向に変更した場合は、これは問題にならないことに留意されたい。例えば、基準を６日から２日に変更した場合、チェック済みテーブルには６日より古いメッセージのデータが保持され、したがってキャッシュデータは、不完全ではあるが依然として有効である。次の送信／受信時、フィルタリングの際に、フィルタリングで除外される、例えば３日、４日、および５日経過したメッセージのレコードがチェック済みテーブルに追加される。
【００３２】
一実施態様では、キャッシュテーブルに無効なデータが含まれる場合（例えば新しい日付時間枠が古い時間枠よりも広い場合）、すべてのレコードを削除するなどして、キャッシュ全体が無効化される。これによってすべてのレコードについてダウンロードが行われるが、その後、キャッシュは有効になり、次にユーザが日付枠を拡大するまで使用することができる。
【００３３】
代替として、各レコードに日付フィールドを追加することもできる。日付フィールドを使用することで、拡大された日付フィルタリング時間枠に変更が加えられた場合に各レコードを処理によって調べ、新しい日付時間枠内に収まらないレコードを廃棄することができ、それによって、次の送信／受信後にそれらのレコードのメッセージデータがダウンロードされることになる。各レコードの追加の日付フィールドに必要なメモリ空間とダウンロード時間との間でトレードオフがあることに留意されたい。日付フィルタリング時間枠をめったに変更しないユーザはそのような機能を必要としないであろうが、日付フィルタリング時間枠を頻繁に変更するユーザは、時間枠が拡大されるたびにチェック済みテーブルを完全に無効化しない方を好むであろう。したがって、このような日付フィールドは、ユーザがオンに切り換えたり（これによって、チェック済みテーブルを、当該追加フィールドのためのスペースがある異なるテーブルに再コピーすることができる）、オフに切り換えたりすることができるような方法で設けてもよい。または、そのようなスイッチは、ユーザが日付フィルタリング時間枠を何回変更したかを示す統計的な履歴に基づいて自動化してもよい。
【００３４】
本明細書では、本発明について主としてメールデータに関して説明しているが、他のアプリケーションも本発明によって益を受けることができる。例えば、カレンダー関連のアプリケーションや連絡先関連のアプリケーションなどは、ダウンロードとフィルタリングが可能なデータを有する。したがって、一般に、フィルタリング可能なダウンロードデータを有するアプリケーションであればどのようなアプリケーションでも本発明の恩恵を受けることができる。
【００３５】
図４の流れ図を具体的に参照しながら、本発明の動作の説明に移ると、図４のステップ４００は、サーバによってリストされず、したがってサーバで削除されたレコードを特定して削除することができるように、メッセージストアテーブル３２６およびチェック済みテーブル３２８内のレコードを初期化するステップ（例えばフラグの設定）を示している。後述するように、ステップ４０８および４１２で、そのようなレコードがリストされている場合はレコードのマークが解除されることに留意されたい。
【００３６】
ステップ４０２で、ＰＯＰ３サーバに送られるＵＩＤＬコマンドなどによって、ＵＩＤを取り出す。ステップ４０２では、本質的に接続／ログオン動作も行われる。前述のように、エラーがないと仮定した場合、サーバからの応答でＵＩＤがリストされ、ステップ４０４でそのリスト３２５からＵＩＤが１つ選択される。
【００３７】
ステップ４０６で、メッセージストアテーブル３２６によって、当該ＵＩＤがメッセージストア内にあるかどうかを調べる。当該ＵＩＤがメッセージストア内にある場合、当該メッセージは存在し、ダウンロードする必要がない。したがって、ステップ４０６はステップ４０８に分岐し、該当するレコード内のフラグが解除され、次に、後述のように次のリストメッセージがあればそのメッセージのためにステップ４２２に進む。ＵＩＤがメッセージストア内にない場合、当該メッセージは新規メッセージまたはすでにチェック済みテーブルで追跡済みのメッセージであるため、ステップ４０６はステップ４１０に分岐し、さらにメッセージ状態データを探す。
【００３８】
ステップ４１０で、チェック済みテーブル３２８を参照し、当該メッセージが以前にダウンロードされているが、フィルタリング基準を満たさなかった（したがって今でも満たすことができない）とわかっているかどうかを判定する。そのようにわかっている場合、ステップ４１０はステップ４１２に分岐し、当該メッセージはサーバによってリストされており、サーバでは削除されておらず、したがってチェック済みテーブル内のレコードはまだ妥当であるため、そのフラグを解除する。次に、ステップ４１２から、後述のように、次のリストメッセージがあればそのメッセージのためにステップ４２２に進む。
【００３９】
ステップ４１０で、当該メッセージがチェック済みテーブル４１０にない場合（およびステップ４０６でメッセージストアになかった場合）、当該メッセージはフィルタリング基準に関して未知状態のメッセージである。したがって、メッセージデータ（例えば該当する２キロバイト）がステップ４１４でダウンロードされ、ステップ４１６でその該当する部分がフィルタ基準（例えば日付時間枠）に照らして評価される。メッセージが基準を満たす場合、ステップ４１８でそのデータがメッセージストアに入れられ、メッセージストアテーブル３２６に適切な項目がフラグ解除された状態で作成され、それによってマークされたままになっているメッセージが削除される場合に当該項目がテーブルから削除されないようにする。
【００４０】
一方、ステップ４１６でメッセージが基準を満たしていない場合、ステップ４２０でチェック済みテーブル３２８に適切な項目が、この場合もフラグ解除された状態で作成され、それによってサーバで単独で削除されるまで削除されないようにする。レコードが作成される時は常に、ＵＩＤ（および／または対応するハッシュ値）が当該レコードに含められ、それによって、後続のリスト上のＵＩＤと照合して探索することができるようにされることに留意されたい。
【００４１】
ステップ４２２および４２４で、リスト内にＵＩＤが残らなくなるまで各ＵＩＤについてこのプロセスが繰り返される。ＵＩＤが残っていない場合、ステップ４２６が実行され、リストされておらず、したがってサーバで削除された、テーブル内のレコード（メッセージストアにメッセージデータがある場合はそのデータも）が削除される。マークされているフラグは、一度もリストされなかったためにサーバで削除され、したがってステップ４０８またはステップ４１２でマーク解除されなかったレコードを示す。
【００４２】
以上の詳細な説明からわかるように、クライアント側でのデータのフィルタリングのために、サーバで保持されているデータのサブセットのみをダウンロードする方法およびシステムが提供される。この方法およびシステムは、プロトコルがサーバ側でのフィルタリングを実施しないＰＯＰ３メッセージデータを処理するのに特に有用であり、効率的である。したがって、本発明は、現在のコンピューティングで必要な多くの長所および利点を備える。
【００４３】
本発明は、様々な変更および代替構成が可能であるが、本発明の特定の例示の実施形態を図面に示し、詳述した。しかし、本発明を開示した特定の態様に限定する意図はなく、本発明は、本発明の主旨および範囲に含まれるすべての変更、代替構成、および同等物を含むことを意図したものであることを理解されたい。
【図面の簡単な説明】
【００４４】
【図１】本発明を組み込むことができるコンピュータシステムの概要を示すブロック図である。
【図２】本発明を組み込むことができる通信処理アーキテクチャを示すブロック図である。
【図３】本発明の一態様による、フィルタリングのためにダウンロードする必要があるメッセージを判定（決定）するために使用される様々な構成要素および追跡テーブルを示すブロック図である。
【図４】本発明の一態様による、メッセージ識別子、テーブルデータ、およびメッセージデータを処理する論理を示す流れ図である。
【符号の説明】
【００４５】
１２２  プロセッサ
１２４  メモリ
１２６  タッチスクリーン付き表示装置
１２８  キーボード
１２９  マイクロフォン
１３２  アプリケーション
１３４  通知マネージャ
１３６  ネットワーク交換機
１３８  ネットワーク構成要素
１４０  電源
１４４  音声発生装置
【図１】
0004828138.tif 000002
【図２】
0004828138.tif 000003
【図３】
0004828138.tif 000004
【図４】
0004828138.tif 000005