(57)【要約】【課題】リアルタイムに近くまたはリアルタイムに、スパムフィルタを増分式にアップデートすることを支援するユニークなシステムおよび方法を提供する。【解決手段】  増分アップデートは、部分的に差分学習によって生成できる。差分学習は、新しいデータに基づいて新しいスパムフィルタをトレーニングし、新しいスパムフィルタと既存のスパムフィルタの間の差分を探す。差分は、少なくとも部分的に、パラメータ変更（２つのフィルタ間のフィーチャの重み付け変更）の絶対値の比較によって決定できる。パラメータの頻度など他のファクタも同様に使用できる。特定のフィーチャまたはメッセージに関する使用可能なアップデートを、ルックアップテーブルまたはデータベースを使用して調べることができる。増分アップデートおよび／またはフィーチャ特有のアップデートが利用可能なとき、アップデートは、クライアントなどによってダウンロードできる。自動的に、あるいはクライアントまたはサーバの選択による要求によって提供できる。【選択図】        図１ 
2006012165.tif 000002
【特許請求の範囲】
【請求項１】
アンチスパムアップデートシステムであって、
スパムメッセージと良いメッセージとを区別するようにトレーニングされたスパムフィルタと、
アップデートされた情報で、前記スパムフィルタの少なくとも一部分を増分式に強化しまたは置き換えて、スパム防止を助けるアップデートコンポーネントとであって、前記アップデートコンポーネントは、機械学習コンポーネントを使用することによって少なくとも部分的に構築されることと、
を備えたことを特徴とするシステム。
【請求項２】
前記アップデートコンポーネントは、前記スパムフィルタの少なくともデータ部分をアップデートすることを特徴とする請求項１に記載のシステム。
【請求項３】
クライアントまたはサーバのうちの少なくとも一方の上において実行されることを特徴とする請求項１に記載のシステム。
【請求項４】
前記アップデートコンポーネントは、マッチベースまたはハッシュベースのデータを使用してトレーニングされることを特徴とする請求項１に記載のシステム。
【請求項５】
１つまたは複数のアップデートが前記スパムフィルタに提供される前に、クライアントまたはサーバがアップデートを受信するために支払いをしているかどうかを判定する支払い検証コンポーネントをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項６】
前記アップデートコンポーネントは、複数のＩＰアドレスを介して前記スパムフィルタに前記アップデートされた情報を提供して、サービス拒否攻撃を緩和することを特徴とする請求項１に記載のシステム。
【請求項７】
前記アップデートコンポーネントは、しきい値を満たす量だけ変更された前記スパムフィルタの少なくとも一部分を、強化しまたは置き換えることを特徴とする請求項１に記載のシステム。
【請求項８】
前記アップデートされた情報は、１つまたは複数のパラメータ変更に対応する１つまたは複数の増分アップデートファイルを含むことを特徴とする請求項１に記載のシステム。
【請求項９】
前記スパムフィルタの前記少なくとも一部分は、少なくとも１つのフィーチャに特有のデータを含むことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記少なくとも１つのフィーチャは、ＩＰアドレスおよびＵＲＬのうちの少なくとも一方を含むことを特徴とする請求項９に記載のシステム。
【請求項１１】
増分アップデートサイズを最小にするのを助けるため、既存のスパムフィルタと新しいフィルタとの間のパラメータ変更の数が最小となる機械学習スパムフィルタを構築するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１２】
前記アップデートコンポーネントは、複数の異なるアップデートを前記スパムフィルタに順次適用することを特徴とする請求項１に記載のシステム。
【請求項１３】
前記アップデートコンポーネントは、前記アップデートされた情報のダウンロード効率を改善するために、複数のアップデートの少なくとも一部分を１つにまとめることを特徴とする請求項１に記載のシステム。
【請求項１４】
前記アップデートコンポーネントは、少なくとも１つのフィーチャが、少なくとも１つの他のフィーチャと独立にアップデートされるように、独立した方法によってフィーチャ特有のアップデートを選択的に提供することを特徴とする請求項１に記載のシステム。
【請求項１５】
前記スパムフィルタは、互いに独立にトレーニングまたはアップデートが行われ、その結果、分解可能となる複数のサブフィルタを含むことを特徴とする請求項１に記載のシステム。
【請求項１６】
前記スパムフィルタが、前記アップデートコンポーネントから前記アップデートされた情報を受信するまで、メッセージの少なくとも一部分の分類を遅延させる隔離コンポーネントをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項１７】
アンチスパムクエリシステムであって、
スパムメッセージと良いメッセージとを区別するようにトレーニングされた機械学習スパムフィルタと、
前記スパムフィルタをアップデートするのを助けるため、メッセージが到着するときに、フィーチャに関連した情報についてのクエリを受信するルックアップコンポーネントと、
を備えたことを特徴とするシステム。
【請求項１８】
前記フィーチャに関連した情報は、複数のフィーチャまたはメッセージについての肯定的なデータおよび否定的なデータを含むことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記フィーチャに関連した情報は、ＩＰアドレス、ＵＲＬ、ホスト名、文字ストリング、および単語のうちの少なくとも１つを含む複数のフィーチャについてのフィーチャスコアおよび評価スコアを含むことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記スパムフィルタは、識別力があるようにトレーニングされることを特徴とする請求項１７に記載のシステム。
【請求項２１】
前記スパムフィルタは、少なくとも部分的に増分式にアップデートされることを特徴とする請求項１７に記載のシステム。
【請求項２２】
前記スパムフィルタは、少なくとも部分的に前記ルックアップコンポーネントによってアップデートされることを特徴とする請求項１７に記載のシステム。
【請求項２３】
前記ルックアップコンポーネントは、増分ルックアップクエリをファイルに書き込み、またはこれらをディスクに記憶し、これらをメモリ中において結合することを特徴とする請求項１７に記載のシステム。
【請求項２４】
前記ルックアップコンポーネントは、
１組のフィーチャおよび関連付けられた重み付け、並びに、トレーニング中に生成される１つもしくは複数のモデルまたはフィルタを含むバックエンドデータベースと、
前記データベースとスパムフィルタの間で通信を受け渡すミドルウェアレイヤと、
あらかじめ定義された頻度または自動的な頻度で前記ミドルウェアレイヤを呼び出して、いちばん最近のアップデートされたモデルを取得し、オンラインモデルをローカルに記憶されたモデルファイルとマージする前記スパムフィルタと、
を含むことを特徴とする請求項１７に記載のシステム。
【請求項２５】
前記クエリは、クライアントまたはサーバの少なくとも一方からの、スパムフィルタについての情報の増分アップデートに対する要求を含むことを特徴とする請求項１７に記載のシステム。
【請求項２６】
サービスプロバイダからエンドユーザに対して少なくとも２段階で伝搬されるアップデートされたスパムフィルタであって、前記段階のうちの少なくとも一方は、前記２段階の間に人間の介入についてのオプションが存在するように自動的であること、をさらに備えたことを特徴とする請求項１７に記載のシステム。
【請求項２７】
前記サービスプロバイダから前記エンドユーザに対してフィルタコードを自動的に伝搬させるコンポーネントをさらに備えたことを特徴とする請求項１７に記載のシステム。
【請求項２８】
エンドユーザまたはアドミニストレータの選択に従って、指定される間隔で前記ルックアップコンポーネントにクエリが送信されることを特徴とする請求項１７に記載のシステム。
【請求項２９】
前記スパムフィルタに対するアップデートは、メッセージングプログラムを再起動せずに有効になることを特徴とする請求項１７に記載のシステム。
【請求項３０】
既存のトレーニング済みのスパムフィルタを提供するステップと、
機械学習を使用して新しいスパムフィルタをトレーニングするステップと、
前記既存のスパムフィルタと前記新しいスパムフィルタとの差分を決定するステップと、
前記差分の少なくとも一部分を用いて前記既存のスパムフィルタを増分式にアップデートするステップと、
を備えたことを特徴とするアンチスパムアップデートサービス。
【請求項３１】
前記既存のスパムフィルタは、機械学習を使用してトレーニングされることを特徴とする請求項３０に記載のアップデートサービス。
【請求項３２】
前記既存のスパムフィルタは、メッセージングプログラムによって現在使用されてメッセージをスパムまたは良いものであるとして分類していることを特徴とする請求項３０に記載のアップデートサービス。
【請求項３３】
前記新しいスパムフィルタは、より最近のまたは新しいデータ上でトレーニングされることを特徴とする請求項３０に記載のアップデートサービス。
【請求項３４】
前記差分は、前記既存のスパムフィルタと前記新しいスパムフィルタとの間の１つまたは複数のパラメータ変更を含むことを特徴とする請求項３０に記載のアップデートサービス。
【請求項３５】
前記差分を決定する前記ステップは、パラメータ変更の絶対値をしきい値または経験則と比較して、前記変更が、前記既存のスパムフィルタの増分アップデートを保証するために十分であるかどうかを確認するステップを含むことを特徴とする請求項３０に記載のアップデートサービス。
【請求項３６】
ウェブベースサービスであることを特徴とする請求項３０に記載のアップデートサービス。
【請求項３７】
以下のオペレーション、すなわち、
新しいデータを使用して第１の新しいスパムフィルタを識別力があるようにトレーニングするステップと、
前記第１の新しいフィルタと前記既存のスパムフィルタとの間の、しきい値または経験則を満たす第１の１組の差分を決定するステップと、
前記しきい値または経験則を満たさなかった、前記第１の新しいフィルタと前記既存のフィルタの間のパラメータ変更は、これらが前記既存のフィルタにおいて有する値と同じ値を有するという制約条件に従って、前記新しいデータを使用して第２の新しいスパムフィルタをトレーニングするステップと、
前記第２の新しいスパムフィルタと前記既存のスパムフィルタとの間の第２の１組の差分を決定するステップと、
前記第２の１組の差分の少なくとも一部を用いて前記既存のスパムフィルタをアップデートするステップと、
を使用して、差分の数を最小にするフィルタを構築するステップをさらに備えたことを特徴とする請求項３０に記載のアップデートサービス。
【請求項３８】
ルックアップテーブルおよびデータベースのうちの少なくとも一方を少なくとも部分的に検索することにより、前記既存のスパムフィルタに対するフィーチャ特有のアップデートを要求するステップをさらに備えたことを特徴とする請求項３０に記載のアップデートサービス。
【請求項３９】
前記既存のスパムフィルタを増分式にアップデートする前記ステップは、クライアント、サーバ、またはユーザのうちのいずれかが受信するメッセージの配信に少なくとも部分的に基づいていることを特徴とする請求項３０に記載のアップデートサービス。
【請求項４０】
前記既存のスパムフィルタに対する１つまたは複数の増分アップデートは、少なくとも１つのフィーチャが、別のフィーチャから独立にアップデートされるようにしてフィーチャ特有であることを特徴とする請求項３０に記載のアップデートサービス。
【請求項４１】
前記ルックアップテーブルおよびデータベースは、複数のフィーチャに対応する複数の増分アップデートを含むことを特徴とする請求項３８に記載のアップデートサービス。
【請求項４２】
既存のトレーニング済みのスパムフィルタを提供する手段と、
機械学習を使用して新しいスパムフィルタをトレーニングする手段と、
前記既存のスパムフィルタと前記新しいスパムフィルタとの間の差分を決定する手段と、
前記差分の少なくとも一部分を用いて前記既存のスパムフィルタを増分式にアップデートする手段と、
を備えたことを特徴とするアンチスパムアップデートシステム。
【請求項４３】
ルックアップテーブルおよびデータベースのうちの少なくとも一方を少なくとも部分的に検索することにより、前記既存のスパムフィルタに対するフィーチャ特有のアップデートを要求する手段をさらに備えたことを特徴とする請求項４２に記載のアップデートシステム。
【請求項４４】
スパムフィルタに対する増分アップデートを実施する２つ以上のコンピュータプロセス間で伝送されるようになっているデータパケットであって、
既存のスパムフィルタを新しくトレーニングされたスパムフィルタと比較することと、
前記フィルタ間の複数の差分を識別することと、
前記差分の少なくとも一部分を伝搬させて、前記既存のスパムフィルタをアップデートすることとに関連する情報
を備えることを特徴とするデータパケット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、合法的な情報（例えば、良いメール）も、望ましくない情報（例えば、ジャンクメール）も共に識別するシステムおよび方法に関し、より詳細には、メッセージ処理中に既存のトレーニングされたスパムフィルタに対してリアルタイムに近い、またはリアルタイムのアップデートを提供することに関する。
【背景技術】
【０００２】
インターネットなどのグローバル通信ネットワークの出現により、膨大な数の潜在的な顧客と連絡を取る商用的機会が提起されてきている。電子メッセージング、特に電子メール（「Ｅメール（ｅ−ｍａｉｌ）」は、（「スパム」としても示される）望ましくない広告および宣伝をネットワークユーザに配布する手段としてますます広がりつつある。
【０００３】
コンサルティングとマーケットリサーチの会社であるＲａｄｉｃａｔｉ  Ｇｒｏｕｐ，Ｉｎｃ．は、２００２年８月時点において、２０億通のジャンク電子メールメッセージが毎日送信されていると見積もっている（この数字は、２年ごとに３倍になると予想される）。個人および団体（例えば、企業、政府機関）は、ジャンクメッセージにより、ますます迷惑しており、多くの場合、腹を立てている。したがって、ジャンク電子メールは、今や、信頼できるコンピューティングに対する大きな脅威となっており、あるいはすぐにも大きな脅威となるはずである。
【０００４】
ジャンク電子メールまたはスパムを阻止するために利用される主要な技法は、フィルタリングシステムおよび／またはフィルタリング方法を使用することである。しかし、スパム発信者（ｓｐａｍｍｅｒ）は、絶えず彼らの技法を変更して、フィルタを回避している。したがってスパム発信者の技法が変化するにつれてフィルタを速やかに自動的にアップデートし、メッセージングクライアントおよび／またはメッセージングサーバによって動作させられるエンドアプリケーションに対して、これらのフィルタを広めさせるのが望ましい。
【０００５】
【特許文献１】米国特許出願第１０／８０９１６３号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
例えば、クライアントが使用するメッセージングプログラムの約１億個のコピーが存在し得る。さらに、新しいスパムフィルタは、毎日作成され得る。これらのスパムフィルタは、かなり大規模である可能性があり、フィルタのコピーを動作させる各クライアントにこれらのスパムフィルタを毎日配信することが必要とされる場合もある。このようなことを実行するのは、たとえ禁止はされないにしても、これらクライアント側においてもフィルタプロバイダ側においても、共に問題になる可能性がある。特に、クライアントは、絶えず大規模なファイルをダウンロードする必要があることもあり、かなりの容量のプロセッサメモリを消費し、処理速度を低下させてしまうことになる。このフィルタプロバイダは、毎日すべてのユーザおよび／またはクライアントのために、このフィルタのすべてのコピーをアップデートしなければならなくなることもあるので、膨大な非実用的な量の帯域幅およびサーバが必要になることもある。一日に一度よりも頻繁に新しいフィルタを提供することは、このような条件下においては、たとえ完全にではないにしても、ほぼ不可能となり得る。
【課題を解決するための手段】
【０００７】
以下においては、本発明の簡略化された概要を提示して、本発明のいくつかの態様の基本的な理解を提供している。この概要は、本発明の広範囲にわたる概説ではない。本発明の主要で／重大な要素を特定し、または本発明の範囲を示すことは意図していない。この唯一の目的は、以下に提示されるより詳細な説明に対する前置きとして本発明の一部の概念を簡略化された形式で提示することにある。
【０００８】
本発明は、リアルタイムまたはリアルタイムに近い方法で、部分的アップデートまたは増分（ｉｎｃｒｅｍｅｎｔａｌ）アップデートの形態によって新しい情報またはデータをスパムフィルタに提供することを実施するシステムおよび／または方法に関する。フィルタを最新の情報を用いてアップデートすることができるリアルタイムに近いメカニズムを提供することは、着信スパム攻撃に対する最も有効な保護を与える１つの戦略となる可能性がある。
【０００９】
特に、本発明は、既存のフィルタに対して情報の増分部分を伝えて、新しい良いメッセージおよび／または新しいスパムに関してこのフィルタを最新に保持することを実行するものである。これは、差分学習によって部分的に実施することができ、この差分学習においては、既存のフィルタの１つまたは複数のパラメータを新しいフィルタのこれらのパラメータと比較することができる。ある変更量を示すこれらのパラメータは、これに応じてアップデートすることができる。このフィルタ全体のあらゆるコピーを置き換える必要性が緩和される。したがって、既存のフィルタと新しいフィルタの間の「差分」を送信して、既存のフィルタをアップデートすることができる。その結果、各アップデートをサイズ的に比較的小さくすることができ、アップデートの頻度によっては、さらに小さくすることさえできる。これは、アップデートされた情報が主として新しい良いメッセージまたは新しいスパムに基づいており、１時間当たりに受信されるスパムまたは良いメッセージが限られていることに一部は起因している。したがって、所与の任意のタイムフレームにおける同じ数だけのアップデートとして実施することは、スパムとの戦いにおいて非常に効率的で有効となり得る。
【００１０】
本発明の一態様によれば、増分アップデートは、サーバがある程度決定をすることができる。これらのサーバは、これらのフィルタのうちのどの部分をアップデートし、これらのアップデートを取得し、次いで、これらを受信するために許可し（ｏｐｔ  ｉｎ）または支払いを行っているユーザまたはクライアントに対してこれらのアップデートを提供すべきかを決定することができる。
【００１１】
本発明の他の態様によれば、増分アップデートは、ウェブベースのサービスを介してユーザまたはクライアントがある程度決定することができる。特に、クライアントは、その現行のフィルタによっては、スパムまたは良好であるとして分類する際における困難があるというメッセージを受信することができる。ウェブベースのサービスは、最近において、良いメッセージもしくはスパムを示すと判定されているメッセージまたはメッセージの特徴に関する、データまたは他の情報を含むルックアップテーブルまたはデータベースを提供することができる。このメッセージからある情報を抽出することにより、クライアントは、ウェブベースのサービスに問い合わせて、任意のアップデートされた情報がそのクライアントのフィルタについて存在するかどうかを判定することができる。
【００１２】
例えば、クライアントはメッセージを受信し、このクライアントのフィルタは、そのメッセージをスパムまたは良いメッセージとして分類するのが難しい場合がある。クライアントは、送信者のＩＰアドレス、このメッセージ中の１つ（または複数）のＵＲＬ、このメッセージのハッシュなどのメッセージのある一部分を抽出して、ウェブベースのルックアップサービスからのアップデートされた情報を要求することができる。ある場合には、クエリをウェブベースのサービスに対して送信することができる。代わりにまたは追加して、クライアントは、このルックアップサービスによって現行の情報を用いて構築され保持される１つまたは複数のルックアップテーブルまたはデータベースを参照することができる。少なくとも１つのアップデートが見出されるときに、クライアントのフィルタをそれに従ってアップデートすることができる。クライアントは一連のアップデートを必要としているとこのサービスが判定する場合に、このサービスは、単に最新のアップデートのみを提供し、ダウンロードする必要があるアップデートの総回数を少なくすることができる。
【００１３】
所与の任意のスパムフィルタ上においては、アップデートすることができる数千もの異なるパラメータが存在し得る。これらのフィルタの性質に起因して、１つのパラメータ値に対する１つのわずかな変更が、これらのパラメータのほとんどすべての値に対して何らかの変更を引き起こす可能性がある。したがって、フィルタのうちのどの部分をアップデートすべきかを決定して、最も効果的なスパム保護を提供するための様々な方法が存在する可能性がある。本発明の一態様においては、パラメータに対する変更の絶対値を検査することができる。値において最大の変更を示すパラメータを選択して、アップデートすることができる。代わりに、（例えば、絶対値に基づく）しきい値変更量を設定することができる。このしきい値を超える任意のパラメータは、アップデートするためにマーク付けすることができる。着信メッセージにおけるパラメータまたはフィーチャの頻度など、他のファクタについても同様に考慮することができる。
【００１４】
本発明の他の態様においては、増分アップデートは、フィーチャに固有のものとすることができ、サーバまたはクライアントの選択によって必要に応じたレートで行うことができる。さらに、フィルタは、古いフィルタと新しいフィルタの間のパラメータ変更の数を最小にするように構築することができる。その結果、任意の１つのフィルタアップデート（例えば、データファイル）の全体サイズおよびアップデートすべきパラメータ数は、そうでない場合に比べてかなり少なくすることができる。
【００１５】
前述の目的および関連した目的を達成するため、本発明のある種の例示的な態様について、以下の説明および添付図面に関連して本明細書中で説明している。しかし、これらの態様は、本発明の原理を使用することができる様々な方法のうちの一部しか示しておらず、本発明では、このようなすべての態様およびその等価物を含むことを意図している。本発明の他の利点および新規な特徴については、これらの図面を併せ考慮するときに、本発明の以下の詳細な説明から明らかとなろう。
【発明を実施するための最良の形態】
【００１６】
次に本発明について、図面を参照して説明している。図面中において、同様な参照番号を使用して、全体を通して同様な要素を示している。以下の説明においては、説明を目的として、本発明の十分な理解を提供するために非常に多くの特定の細部について記述している。しかし、本発明は、これらの特定の細部なしに実行することができることが明らかであろう。他の例においては、周知の構造およびデバイスが、本発明の説明をうまく実施するためにブロック図形式で示されている。
【００１７】
この出願において使用されるように、用語「コンポーネント」および「システム」では、コンピュータに関連したエンティティ、すなわちハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアを意味することが意図されている。例えば、コンポーネントは、それだけには限定されないが、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、およびコンピュータとすることができる。例証としては、サーバ上で実行されるアプリケーションもサーバも共にコンポーネントとすることができる。１つまたは複数のコンポーネントは、プロセスおよび／または実行スレッドの内部に存在することができ、コンポーネントは、１台のコンピュータ上にローカルに存在し、または２台以上のコンピュータ間に分散され、あるいはその両方とすることができる。
【００１８】
本発明においては、機械学習スパムフィルタまたは非機械学習スパムフィルタに対する少なくとも部分的なアップデート、または増分アップデートを提供することに関連した様々な推論スキームおよび／または推論技法を組み込むことができる。本明細書で使用されるように、用語「推論（ｉｎｆｅｒｅｎｃｅ）」とは、一般にイベントおよび／またはデータを介して捕捉される１組の観察値からシステム、環境、および／またはユーザの状態についての推理または推論のプロセスのことを意味する。推論を使用して、特定のコンテキストまたはアクションを識別することができ、また例えば状態に対する確率分布を生成することができる。この推論は、確率的とすることができ、すなわちデータおよびイベントの考察に基づいた対象となる状態についての確率分布の計算とすることができる。推論はまた、１組のイベントおよび／またはデータからより高レベルのイベントを構成するために使用される技法を意味することもできる。このような推論の結果、これらのイベントが一時的に近接した近接度に相関しようがしまいが、またこれらのイベントおよびデータが、１つまたは複数のイベントおよびデータソースに由来するかどうかによらず、１組の観察されたイベントおよび／または記憶済みのイベントデータからの新しいイベントまたはアクションの構築がもたらされる。
【００１９】
本発明の様々な態様は、機械学習フィルタおよび非機械学習フィルタに対して適用することができる。１つの一般的な実施態様においては、機械学習スパムフィルタは、機械学習アルゴリズムを使用して、メッセージから抽出される個々の特徴の重み付けを計算することによって、何が良いメッセージとスパムとを特徴づけるかについての定義を学習する。メッセージがホストアプリケーションによって受信されるときに、このメッセージストリームは、スパムメッセージインジケータまたは良いメッセージインジケータとして重み付けされたフィーチャまたは特性について解析し検査することができる。次いで、これらの重み付けされたフィーチャが組み合わされて、このメッセージがスパムであり、またスパムでないという全体的な確率が生成される。メッセージが、確率の特定の「しきい値」を満たす場合には、このメッセージは、このホストアプリケーションの設定に基づいて、割り当てられたアクションのコースを取ることができる。例えば、良いメッセージは、この受信者の受信トレイを対象とすることが可能になるが、一方、スパムメッセージは、特定のフォルダに経路指定され、あるいは削除されることが可能になる。
【００２０】
スパム発信者は、絶えず彼らの方法を適応させている。以前のフィードバックループおよび機械学習技法を用いても、新しいフィルタを自動的にまた簡単に生成することができる。しかし、リアルタイムやリアルタイムに近くなど、速やかにそれらのユーザに対してこれらの新しいフィルタを効率的に広め伝播させることも同様に重要であり得る。これらの新しいフィルタの伝搬については、２つの部分に分解することができる。この第１の部分は、サイズの問題に関与している。この伝搬させられるフィルタは、大規模であり、全体として簡単に配信することが難しいことがある。幸い、これについては、ルックアップシステムを介してこの古いフィルタとこの新しいフィルタの間の「差分」を送信することによって少なくとも部分的に克服することができる。以下に説明するように、この差については、多くのファクタおよび／または選択（クライアントまたはサーバ）に対して決定し、かつ／または基づいたものとすることができる。
【００２１】
第２の問題は、フィルタアップデートの管理に関係している。一方では、多くの人々は、新しいコードおよび新しいデータを含めて、このスパムフィルタに対するすべての変更が自動的に伝搬されることを望むこともある。他方では、多くの管理者は、彼らの全体の組織に対して自動的に伝搬させる前に、新しいファイルおよび／またはデータをテストマシン上にインストールしたいと望むこともある。以下の図面中で説明するように、大規模のフィルタを伝搬させる必要性は、オンラインルックアップサービスを介してこの差分フィーチャ（重み付け）だけをメモリに配信することによって緩和することができる。
【００２２】
次に図１を参照すると、本発明の一態様による、古いまたは既存のスパムフィルタに対して差分情報の提供を実施するアンチスパムアップデートシステム１００の一般的なブロック図を示している。システム１００は、少なくとも１つのスパムフィルタ１２０を使用して、着信テストメッセージをスパムまたは良いメッセージとして分類するテストメッセージ受信コンポーネント１１０を備える。テストメッセージ受信コンポーネント１１０は、サードパーティクライアントまたはサーバ（例えば、ホームコンピュータ）中に配置することができる。スパムフィルタ１２０は、ＳＶＭ（Ｓｕｐｐｏｒｔ  Ｖｅｃｔｏｒ  Ｍａｃｈｉｎｅサポートベクトルマシン）、最大エントロピーモデル（ロジスティック回帰）、パーセプトロン（ｐｅｒｃｅｐｔｒｏｎ）、判定ツリー、および／またはニューラルネットワークのうちのいずれか１つを使用して識別力があるようにトレーニングすることができる。
【００２３】
システム１００は、様々なトレーニングメッセージを受信することができるトレーニングメッセージ受信コンポーネント１３０も備える。実施例は、フィードバックループデータ（例えば、着信メッセージの少なくとも選択された部分を（スパムまたは良いメッセージに）分類する際に参加するユーザからのデータ）、ユーザの苦情、ハニーポットデータなどを含んでいる。トレーニングメッセージ受信コンポーネント１３０は、このフィルタプロバイダ側において見出すことができる。
【００２４】
着信トレーニングメッセージの少なくとも一部分は、フィーチャ解析サブシステム１４０へと経路指定することができ、それによってこのようなメッセージは、そのスパムおよび／または非スパムのような特徴について解析し検査することができる。特に、ＩＰアドレス、ＵＲＬ、および／または特定のテキストなどの複数のフィーチャを各メッセージから抽出し、次いで解析することができる。機械学習コンポーネント１５０を使用して、アップデートコンポーネント１６０は、識別力のある方法をおそらく使用してトレーニングすることができる。代わりに、アップデートコンポーネント１６０は、マッチベースまたはハッシュベースのデータを使用してトレーニングすることができる。このフィーチャ解析サブシステム１４０へと経路指定されるメッセージは、フィルタされなかったメッセージ、フィルタされたメッセージ、またはこれら両者の組合せとすることができる。フィルタされたメッセージのスパムまたは良いメッセージとしての分類では、アップデートコンポーネント１６０のトレーニングまたはスパムフィルタ１２０についてのアップデートの生成に影響を及ぼす必要はない。
【００２５】
アップデートコンポーネント１６０は、着信メッセージから抽出することができる、単語など複数のメッセージおよび／またはフィーチャについて計算された重み付け値、ＩＰアドレスのリスト、ホスト名、ＵＲＬなどのデータを含んでいる。このようなデータは、アップデートコンポーネント１６０によって制御される１つまたは複数のデータファイルまたはデータベースの形に構成することができる。
【００２６】
メッセージ受信／配信システム（例えば、１つまたは複数のサーバ）１１０によって促されるときに、アップデートコンポーネント１６０は、追加情報を用いてスパムフィルタ１２０の少なくとも一部分を少なくとも増分式に強化させることができる。例えば、アップデートコンポーネント１６０は、所与のフィーチャについて、新しいフィーチャ−重み付けデータを追加し、または古い重み付けデータを新しい重み付けデータで置き換え、あるいはその両方を行うことによって、このスパムフィルタのデータ部分をアップデートすることができる。アップデートコンポーネント１６０はまた、可能なら、時刻指定ベースまたはスケジュールベースで増分アップデートを行って任意の１つのアップデートの相対サイズを最小にするようにカスタマイズすることもできる。これらのアップデート自体は、同様に時刻指定ベースで、または受信する着信メッセージ数に基づいて生成することができる。例えば、アップデートは、毎時および／または３０番目のメッセージ受信後ごとに作成することができる。
【００２７】
次に図２を参照すると、スパム防止を助けるアンチスパムアップデートシステム２００の概略ブロック図が示されている。一般的に、アップデートシステム２００は、新しいパラメータデータを既存のスパムフィルタ２１０が利用する古いパラメータデータと比較する。システム２００は、着信メッセージから抽出されるフィーチャを調べて、（例えば、スパムメッセージまたは良いメッセージを示す）関連するフィーチャを識別し、それらの重み付け、スコア、および他の関連データを確認することができるフィーチャ抽出−解析コンポーネント２２０を備える。このデータは、パラメータアップデートデータベース２３０に記憶し保持することができる。このデータベース中の新しいパラメータデータは、パラメータ解析コンポーネント２４０によって既存のフィルタ２１０中の古いパラメータデータに関して解析を行い、このパラメータデータのうちのいずれかが変更されているかどうかを判定することができる。
【００２８】
例えば、パラメータの重み付けを、増大または減少させて、より大きな、またはより小さなスパムの特徴を表示ことができる。さらに、既存のフィルタ２１０に対してパラメータを追加し、またはそこからパラメータを削除することもできる。後者の場合には、その重み付けがゼロになるときに、パラメータまたはフィーチャをフィルタ２１０から取り除くことができる。
【００２９】
アップデートが、特定の任意の１組またはサブセットのパラメータについて存在していると判定される場合、このようなパラメータは、アップデートコントローラ２５０に対して伝えることができる。アップデートコントローラ２５０は、データベース２３０からの関連したパラメータデータにアクセスすることができ、次いでこのようなデータを既存のフィルタ２１０に伝えることができる。基本的に、システム２００は、アップデートサービスをスパムフィルタに対して提供し、これらのスパムフィルタを最新に、また新しい形態のスパムに対して有効に保つ。
【００３０】
このアップデートシステム２００は、クライアント上またはサーバ上で自動的に実行することができる。さらに、このサービスは、加入契約による動作が可能であり、それによって支払い検証コンポーネント２６０は、任意のアップデートが提供される前に、クライアントまたはサーバが、このアップデートまたはアップデートサービスについて支払いが済んでいるかどうかを判定することができる。代わりに、フィルタ２１０は、ルックアップまたはアップデートを行うことができるようになる前に、この加入契約が現在通用していることを検証することもできる。
【００３１】
（例えば図１および２における）アップデートルックアップシステムは、ＤＯＳ（Ｄｅｎｉａｌ−ｏｆ−ｓｅｒｖｉｃｅサービス拒否）攻撃または分散ＤＯＳ攻撃に関して当然のターゲットになってしまう可能性がある。したがって、このシステムは、異なるＩＰアドレスに対応する複数のＩＰアドレスまたは複数のホスト名にまたがって分散させることなどにより、このような攻撃に対して堅固なものとすることができる。実際には、例えば、異なるＩＰアドレスを異なるユーザ（あるいはクライアントまたはサーバ）に対して分散して、攻撃者が攻撃すべきＩＰアドレスの全体のリストを見出すことを難しくすることができる。
【００３２】
機械学習技法においては、これらのパラメータのほぼすべてが、少なくともある小さな量だけ変更されることがあり得るので、アップデートできる数千もの異なる数値パラメータが存在する可能性がある。その結果、どのようなアップデートをすべきかについての判定は、いくつかの異なるアプローチを使用して行うことができる。例えば、１つのアプローチは、最も変化しているパラメータの絶対値を調べるものである。しかし、最大の絶対値変更が、どのパラメータをアップデートすべきかを最もよく指し示してはいないこともある。これは、このパラメータがまれにしか観察されないフィーチャに関連している場合に、特に当てはまる可能性がある。したがって、どのパラメータをアップデートすべきかを決定する際に考慮すべき他のファクタが、発生、頻度、または最新のデータに基づいたパラメータの共通点を含むこともできる。例えば、パラメータは相当に変更されているが、その対応するフィーチャは、非常にわずかなメッセージ（例えば、平均して１００，０００メッセージのうちの３つのメッセージ）中にしか発生しない場合には、このフィーチャについてのアップデートの送信は、このアップデートサービスの効率的な使用ではないこともある。
【００３３】
他のアプローチは、それらを重要にするある量だけ（例えば、ある最小値またはしきい値だけ）、あるいはより一般的なフィーチャにおいては、あまり一般的でないフィーチャの場合と異なるある最小値だけ、変更しているパラメータの絶対値を調べるものである。特定のしきい値が満たされる場合、パラメータをアップデートすることができる。そうでない場合には、パラメータは同じままとすることができる。
【００３４】
さらに他のアプローチは、パラメータ変更の数を制限しようとするようにフィルタまたはフィルタに対するアップデートを構築するものである。釣りあわせるフィーチャ（ｃｏｕｎｔｅｒｂａｌａｎｃｉｎｇ  ｆｅａｔｕｒｅ）と呼ばれる一部のフィーチャは、互いに相互作用し、最終的にはこのフィルタの振舞いに影響を及ぼす可能性がある。釣りあわせるフィーチャが、トレーニング中にこのフィルタ内で適切に考慮されないときには、このフィルタの動作は変更され得る。したがって、パラメータ変更の数を制限するフィルタを構築することにより、釣りあわせるフィーチャが適切に考慮されているかどうかを追跡する必要性を緩和することもできる。
【００３５】
例えば、現在使用しているフィルタＡが、例えば単語「ｗｅｔ（ぬれた）」については０の重み付けを有し、単語「ｗｅａｔｈｅｒ（気候）」については、少し否定的な重み付けを有するものと仮定する。次に、単語「ｗｅｔ」を含む（ただしｗｅａｔｈｅｒは含まない）大量のスパムが到着すると仮定する。単語「ｗｅｔ」および「ｗｅａｔｈｅｒ」を一緒に含む中程度の量の良いメールも存在すると仮定する。新しいフィルタＢは、「ｗｅｔ」をかなりスパムの可能性があるものとして重み付けし、「ｗｅａｔｈｅｒ」については釣りあわせる（ｃｏｕｎｔｅｒｂａｌａｎｃｉｎｇ）否定的な（良い）重みで重み付けをする。これらの単語が一緒に発生するときには、これらの重み付けがキャンセルし、このメールがスパムとして分類されないようにするように学習させることができる。今や、フィルタＡに比べてフィルタＢ中の単語「ｗｅｔ」は、（大量のメール中で発生した）この重み付けをアップデートするために十分に重要であるが、単語「ｗｅａｔｈｅｒ」はそうでない（この単語は、すでにわずかな否定的な重み付けを有しているので、少量のメール中で発生し、少量だけ変更している）と、判定することができる。したがって、「ｗｅｔ」についてのアップデートは伝搬させることができるが、「ｗｅａｔｈｅｒ」についてのカウンタバランスアップデートは、伝搬させることができず、多数の誤りが生じてしまう。このような望ましくないアップデートの作成を緩和するために、図３に示すようにパラメータ変更の数を最小にするフィルタを構築することができる。
【００３６】
この図３に従って、古いデータのフィーチャおよび重み付けを含む古いフィルタＸ３１０から開始される。次に、機械学習を使用して、新しいフィルタＹ１  ３２０をトレーニングする。ある１つ（または複数）の経験則（Ｈｅｕｒｉｓｔｉｃｃ）３３０に従って重要となるＸ３１０とＹ１  ３２０の間の差分を見出す。例えば、この差分の絶対値、この差分からの情報ゲイン、この差分の絶対値×このパラメータの使用頻度などを評価することができる。線型モデル（例えば、ＳＶＭモデル、ナイーブ−ベイズモデル（Ｎａｉｖｅ−Ｂａｙｅｓ  ｍｏｄｅｌ）、パーセプトロンモデル、最大エントロピー（ｍａｘｅｎｔ）モデルまたはロジスティック回帰モデル）の場合には、モデルは、フィーチャ（例えば、このメッセージ中の単語）についての重み付けからなる。線型モデルに関しては、これは、これらの対策のうちの１つに従って最も変化しているこれらのフィーチャ重み付けを見出すことからなる（３４０）。
【００３７】
次に、小さかった（または十分に重要でなかった３６０）フィルタの間の差分はすべて、Ｘ３１０において有したのと同じ値を、Ｙ２  ３５０においても有する必要があるという制約条件に従って、新しいフィルタＹ２  ３５０を学習させることができる。例えば、線型モデルにおいては、これは、あまり変化しなかったフィーチャについての重みづけは、Ｙ２  ３５０中とＸ３１０中において同じであることを意味する。しかし、（例えば、あるしきい値または経験則を満たす）多く変化しているフィーチャについては、これらの重み付けは、Ｙ２  ３５０において異なっている。以前の「ｗｅｔ」と「ｗｅａｔｈｅｒ」の実施例について言及すれば、「ｗｅｔ」が悪いものであると学習されるときに、その釣りあわせる（ｃｏｕｎｔｅｒｂａｌａｎｃｉｎｇ）重み付け（「ｗｅａｔｈｅｒ」）が固定されることになるので、「ｗｅｔ」は、あまりにも悪すぎる用語として学習される可能性はない。したがって、釣りあわせるフィーチャが考慮されているかどうかをそれ以外に追跡する必要性はもはや存在しない。
【００３８】
オプションとして、この手順は、その重み付けが一貫して異なるこれらのフィーチャだけを見出しながら、反復することができる。例えば、この「ｗｅａｔｈｅｒ」パラメータ値は、変化させ得ないので、この「ｗｅｔ」パラメータ値も変化させないように決定することができる。
【００３９】
さらに、この１つ（または複数）のフィルタは、Ｙ１  ３２０を使用してアップデートする代わりにＹ２  ３５０に対するアップデートを使用してアップデートすることができる。このモデルの多くの部分が、同じように制約されていたので、Ｙ２  ３５０とＸ３１０の間の差分は、Ｙ１  ３２０とＸ３１０の間の差分よりも小さくなる。
【００４０】
代替的な技法は、より速やかに変更しまたはこのモデルに対してより大きな影響を有する部分など、このデータの一部分だけをアップデートするものである。例えば、ＩＰアドレスおよびＵＲＬデータは、テキストデータに比べて速やかに（またはゆっくり）変化することもある。さらに、これらのフィーチャを他のフィーチャとは独立にトレーニングするのが簡単なこともある（例えば、「Training Filters for IP Address and URL Learning」という名称で２００４年３月２５日出願の特許文献１参照）。したがって、他のフィーチャを変更できるようにしながら、ある１組のフィーチャを一定に保持することができるモデルを構築することができる。
【００４１】
さらに、サブセットのフィーチャ（例えば、他のどれかから独立な少なくとも１つのフィーチャ）を選択的にアップデートすることにより、このモデルに対する将来のアップデートをさらに簡単に達成することが可能である。この種のモデルの一実施例が、判定ツリーモデルであり、このモデルでは、各リーフ（ｌｅａｆ）は、他のリーフにおいてこれらのモデルから切り離してアップデートすることができる独立なモデルを含む。研究により、これらのモデルは、現在構築されているが全体としてより良い性能を有する典型的なモデルと同じフィーチャ数を有することができることが見出されてきている。
【００４２】
これらのフィーチャを関連したグループにクラスタ化することにより、または何らかの他のメカニズムによりこのフィーチャスペースを任意に分割することを含めて、このモデル構築中にこれらの間の重み付けをバランスさせない、またはバランスさせることができないフィーチャサブセットを先験的に有するようにモデルを設計することができる他の方法が存在する。代わりに、判定ツリーにおけるように、これらのメッセージは、例えばこれらを関連したグループにクラスタ化することによって分割することもできる（この場合には、判定ツリーの場合におけるように、異なる重み付けをもつ異なるクラスタ中に二重のフィーチャが存在することが可能であるが、これらは、独立にアップデートすることができる）。
【００４３】
増分アップデートは、（特定の顧客（サーバまたはクライアント）が最も受信するメッセージに対して適用されるこれらに対して、まずこのアップデートされるフィーチャを集中させて）このクライアント、サーバ、またはユーザが受信するメッセージの配信によって少なくとも部分的に決定することもできる。したがって、複数のクライアントは、例えば、彼らが受信するメッセージのタイプに従って、彼らのフィルタに対する異なるアップデートを受信することができる。
【００４４】
アップデートのタイプが決定された後に、スパムフィルタのアップデートを管理することは、困難な場合がある。メッセージシステム管理者は、しばしば、または時に、彼らのユーザがデータファイルを含めてどのようなソフトウェアを使用しているかを知ることに関心がある。ある場合には、管理者は、彼らのユーザがすべて同じデータを実行することを望むことさえあり、あるいは代わりに、管理者は、好みの環境または望ましい環境中でそれらをテストする機会を有する前には、新しいデータファイルを配信したくないと思うこともある。したがって、管理者は、ユーザがアップデートサービスと直接に情報をやりとりすることを望まないこともある。
【００４５】
例えば、１つのシナリオにおいては、管理者は、ファイルをこれらのユーザに送信する前に、まず特定のファイルをダウンロードし、操作性、他のシステムファイルとの競合などについてこれらのファイルをテストすることを望む可能性がある。したがって、データまたはコードに対するアップデートが、まずこの管理者に送信され、次いでこれらのユーザに伝搬されるという２段階の伝搬を実施することが望ましい。ある場合においては、管理者は、すでにこのフィルタプロバイダを信頼することが可能であり、検証のない完全に自動的なルックアッププロセスを好むこともある。
【００４６】
このルックアップサービスまたはアップデートサービスは、電子メールクライアント上またはサーバ上でのオペレーションについてのコードを必要とする可能性があることを理解されたい。さらに、ルックアップまたはアップデートは、エンドユーザまたは管理者が指定することができるスケジュールされた間隔で実施することができる。代わりに、ルックアップまたはアップデートは、メッセージングプログラムが開始され、またはオープンされるときなど、ある種のイベントが行われるときに実施することができる。アップデートが使用可能なときに、エンドユーザまたは管理者は、（例えば、アップデートが任意選択可能であると）通知を受けることができ、あるいはこのアップデートを自動的にすることができる。エンドユーザまたは管理者は、これらのオプションの間で選択権を与えられることができる。最終的に、このスパムフィルタに対するアップデートを行うことができ、このメッセージングプログラムを再起動することさえなしに、すぐに効果を得ることができる。
【００４７】
説明したように、スパムフィルタに対するアップデートは、少なくとも増分的なものとすることができ、それによってこのスパムフィルタの最も有用な、または望ましい部分がアップデートされ、その残りの部分は、このアップデート、およびそれに関連する関連データファイルのサイズを最小にするために一定に保たれる。ほとんどの場合において、サーバは、どのアップデートを行うべきか、このようなアップデートをいつ行うべきか、および／またはこのようなアップデートを行う方法を決定する役割を担っている。あいにく、サーバは、このような決定を行う際に遅い可能性があり、あるいはこのようなアップデートのタイミングまたは内容が、クライアントまたはユーザのフィルタリングの必要性と少しずれている可能性がある。特に既存のスパムフィルタが、特定の１つ（または複数）のメッセージの分類について不確実であり、このクライアントが、サーバが促すアップデートを待つことによるさらなる遅延に耐えることができないときには、いずれの場合も、クライアントにとって問題となり得る。
【００４８】
図４には、クライアントによるその使用中に、スパムフィルタのアップデートを可能にするルックアップサービスシステム４００の概略ブロック図が示されている。ルックアップサービスシステム４００は、特にこのスパムフィルタに対するリアルタイムに近く、またはリアルタイムで伝搬させるためのあるタイプのアップデートデータを生成することに関し、上述の図１におけるアップデートシステム１００と同様なものとすることができる。しかしさらに、ルックアップサービスシステム４００は、サーバ命令だけによるのでなくて、クライアントまたはエンドユーザによる要求によって、このスパムフィルタに対してアップデートを提供することができる。
【００４９】
この図４に従って、少なくとも１つのスパムフィルタ４２０を使用してメッセージをスパムまたは非スパムとして分類を実施するテストメッセージ受信コンポーネント４１０に対し、着信テストメッセージを配信することができる。テストメッセージは、その最新の１組のパラメータを仮定すると、スパムフィルタ４２０の正確さを決定する助けを行うことができる。テストメッセージ受信コンポーネント４１０は、サードパーティのサーバまたはクライアント上に配置することができる。スパムフィルタ４２０は、機械学習でトレーニングされたもの、または非機械学習でトレーニングされたものとすることができる。
【００５０】
アップデート学習は、以下のように実施することが可能であり、すなわち着信トレーニングメッセージの少なくとも一部分は、（フィルタプロバイダ上に配置された）トレーニングメッセージ受信コンポーネント４３５を介して、フィーチャ解析システム４３０に対して経路指定をすることができる。フィーチャ解析システム４３０は、フィーチャ、およびこれらのトレーニングメッセージの少なくとも一部分から抽出されるそれらの各重み付けに基づいて最近のデータを生成し、それらをルックアップデータベース４４０に記憶することができる。
【００５１】
スパム発信者は、彼らのスパムを適応させ、または修正し、あるいはその両方を行い続けるので、既存のスパムフィルタ４２０によってスパムまたは良いメッセージとして分類することができない、一部のメッセージが存在する可能性がある。クライアントは、このようなメッセージにマーク付けし、次いでこのメッセージ、このメッセージのハッシュ、および／またはこのメッセージの１つまたは複数のフィーチャに基づいて、ルックアップコンポーネント４５０に対してクエリまたは要求を送信することができる。
【００５２】
このルックアップデータベースからの任意のデータがこの要求を満たす場合には、このような対応する情報を送信またはダウンロードして、スパムフィルタ４２０をアップデートすることができる。その後、アップデートされたスパムフィルタをこれらの不確実なメッセージ、並びに、新しい任意のメッセージに適用して、この分類プロセスを実施することができる。
【００５３】
次に図５を参照すると、クライアント５１０が使用するウェブベースのアップデートサービスを実施するオンラインルックアップシステム５００の概略図が示されている。「古い」データ上でトレーニングされている既存のスパムフィルタを使用して、着信メッセージ５１５を分類していることを仮定する。あいにく、このクライアントの既存のフィルタは、一部のメッセージがスパムであるかそれとも良いメッセージであるかを判定するに際し、ある困難を経験している。メッセージ５１５を隔離し、またはサーバが促すアップデートが到着するのを待つのでなく、クライアント５１０は、メッセージ５１５、またはＩＰアドレス５２０、ＵＲＬ５２５、ホスト名５３０、他の１つ（もしくは複数）の任意のフィーチャ５３５など、そこから抽出されるあるフィーチャを取得し、オンラインルックアップシステム５００に問い合わせることができる。オンラインルックアップシステム５００は、１つまたは複数のルックアップテーブル５４０および／または１つまたは複数のデータベース５４５を含むことができる。ルックアップテーブル５４０は、（ＩＰアドレス５５５ごとなど）フィーチャ５５０ごとのアップデートされたデータを含むことができる。クライアントが、このメッセージのＩＰアドレスに対するクエリを実施する場合には、適切なルックアップテーブルまたはアップデートテーブル中において、このＩＰアドレスを調べることができる。
【００５４】
同様に、データベース５４５は、ＩＰアドレス５２０に属する任意のアップデートについて参照し、検索することができる。データベース５４５は、（ＩＰアドレス５６５ごとなど）アップデートされたフィーチャ５６０ごとに整理することができる。テーブルサイズまたはデータベースサイズを調整するために、アップデートされた情報をもつフィーチャだけしか、それぞれこのルックアップテーブルおよびデータベースに提供しないようにすることができる。しかし、それらの重み付けまたは値が変化しているかどうかにかかわらず、ほぼすべてのフィーチャもしくはパラメータを有するルックアップテーブルおよび／またはデータベースを同様に使用可能にすることもできる。テーブルまたはデータベースの構成にかかわらず、アップデートが見出された場合、このアップデートは、直接に送信し、またはこのクライアントがダウンロードして、このスパムフィルタをアップデートすることができる。したがって、このスパムフィルタに対するアップデートは、クライアントの選択に基づいたものにすることができ、また必要に応じて行うことができる。
【００５５】
このサーバまたはクライアント上のメッセージングシステムが、以前のすべてのアップデートを受信していない場合には、複数の一連のフィーチャまたはアップデートを調べることが必要なこともある。この最後に記録されたルックアップから、このシステムはルックアップを実施することが可能であり、それらを順番に適用することができる。オプションとして、このアップデートサーバは、複数のルックアップファイルを一緒に1つにまとめて、このダウンロード効率を改善することも可能である。最後に、このアップデートは、ＨＴＴＰＳなどのセキュリティ保護されたチャネル上において行うこともできる。
【００５６】
より新しいデータについての増分ルックアップは、ファイルに書き込み、またはディスクに記憶し、次いでメモリ中において結合することができる。さらに、この増分アップデートは、このモデルのある種の一部分、１つ（もしくは複数）のフィーチャ、または１つ（もしくは複数）のパラメータが、もはや必要とされない（例えば、重みがゼロ）ことを指定することができる。したがって、これらを削除することが可能になり、メモリスペースまたはディスクスペースを節約している。
【００５７】
次に図６を参照すると、本発明の一態様によるアンチスパムルックアップウェブベースサービスの例示的な１つのアーキテクチャ６００が示されている。アーキテクチャ６００は、例えば、サブセットのフィーチャおよび関連する重み付けとトレーニング中に生成されるモデルを格納するデータティアレイヤ（ｄａｔａ−ｔｉｅｒ  ｌａｙｅｒ）（またはバックエンドデータベース）、このデータベースとスパムフィルタ間で通信の受渡しを行うミドルウェアレイヤ、あらかじめ定義された頻度、または自動的な頻度でミドルウェアレイヤを呼び出して、最新のアップデートされたモデルを獲得し、このオンラインモデルをこのローカルに記憶されたモデルファイルとまとめるスパムフィルタなどの複数のレイヤを含んでいる。
【００５８】
より詳細には、このデータティアレイヤは、２つの記憶域、すなわち（標準のトレーニングのために使用される）トレインストア（ＴｒａｉｎＳｔｏｒｅ）６１０およびアップデートストア（ＵｐｄａｔｅＳｔｏｒｅ）６２０のコピーを格納する。これらの記憶域は、単層ファイルまたはデータベースとすることが可能である。この専用のトレインストア６１０は、オプションとして、このフィーチャ、および頻繁にアップデートすることにより恩恵を受ける一部のフィーチャについての重み付けしか格納しないこともある。アップデートストア６２０は、新しいデータベースまたは１組の単層ファイルであり、これらは、専用のトレインストア６１０からのサブセットの情報からもたらされるバイナリ形式で出力されるモデル、並びに、展開される製品関連付けについての少ない新しい変数を含んでいる。このサブセットの情報は、以下を含むことができる。
【００５９】
・  さらに頻繁にアップデートすることから非常に恩恵を受けるフィーチャを含む新しいモデル、
・  ＵＲＬフィーチャ、ＩＰフィーチャ、および新しい特有のフィーチャを含んでいるこれらの実施例、
・  展開されるモデルファイルの以前のバージョンにそれぞれ対する新しい確率的モデルの関係、および／または
・  新しいモデル転送のサイズを最小にする新しいモデルの増分アップデート。
【００６０】
ミドルウェアレイヤ６３０は、アップデートストア６２０とこのスパムフィルタ．ｄｌｌフィルタ６４０の間のインターフェースとしての役割を果たすことができる。このミドルウェアレイヤは、このスパムフィルタとこのオンラインルックアップサービスの間で往復して情報を受け渡すウェブサービスインターフェースおよび機能を公開する。このミドルウェアレイヤは、ＳＯＡＰサービス、ＨＴＴＰサービス、ＨＴＴＰＳサービス、または他のインターネットサービスとすることができる。
【００６１】
このアンチスパムルックアップサービスは、ある種の他のスパムに関連したシステムおよび方法と組み合わされるときに特に強力である。特に、このアンチスパムルックアップサービスは、メッセージ隔離と組み合わされるときに特に強力となり得る。メッセージ隔離においては、一部のメッセージはジャンクフォルダまたは隔離フォルダ中に入れられ、あるいはそうでなければ一時的に別に保持される。次いでこれらのメッセージは、スパムフィルタアップデートの後に、再度スコア付けされる。ユーザが中央のリポジトリに対してジャンクメッセージの報告を行う「レポートジャンクボタン（ｒｅｐｏｒｔ  ｊｕｎｋ  ｂｕｔｔｏｎ）」などの技法はまた、スパムフィルタアップデートについての重要なデータをもたらすことができる。さらに、メッセージを決して受信していないはずのある種のアカウント（例えば、新しく作成された未使用アカウント）にデータが送信されるハニーポットなどの技法は、スパムフィルタアップデートについての有用なソースである。さらに、フィードバックループ中で、ユーザは、ある種のメッセージが良好であるのか、それともスパムであるのかについて調査（ｐｏｌｌｉｎｇ）をされる。これは、スパムフィルタをアップデートするために価値あるデータを提供する。このデータは、比較的公平なので、レポートジャンクまたはハニーポットデータよりも有用である場合がある。
【００６２】
本発明による様々な方法について、次に一連の動作を介して説明することにするが、一部の動作が、本発明に従って、本明細書中に図示され説明される順序とは異なる順序で、または他の動作と並行して、あるいはその両方で行うことができる。したがって、本発明は、動作の順序によって限定されないことを理解し認識されたい。例えば、この方法は、一連の相互に関連した状態またはイベントとして、状態図の形などにより代替的に表すことができることが、当業者には理解され認識されよう。さらに、本発明による方法を実施するためには、必ずしもすべての例示された動作が必要ではないこともある。
【００６３】
次に図７を参照すると、使用中にスパムフィルタに対して少なくともリアルタイムに近いアップデートを実施する例示のスパムフィルタアップデートプロセス７００の流れ図が示されている。プロセス７００は、７１０において、機械学習技法などにより、新しいデータ、またはより最近のデータ（メッセージ）を用いて新しいフィルタをトレーニングすることを含んでいる。この新しいフィルタは、複数のメッセージフィーチャおよびその関連する重み付け上で識別力のあるようにトレーニングすることができる。フィーチャの少数の実施例には、任意のＩＰアドレス、ＵＲＬ、ホスト名、もしくはメッセージから抽出することができる任意の単語またはテキストが含まれる。
【００６４】
７２０において、プロセス７００は、この新しいフィルタと（古いデータ上でトレーニングされた）この古いフィルタの間の差分を探すことができる。７３０において、見出され、または検出されたどのような差分も、１つまたは複数の別々のデータファイルとして記憶することができる。
【００６５】
オプションとして、これらのデータファイルをデータベースに記憶することができ、またはその中に含まれる内容を１つまたは複数のルックアップテーブル中に整理することができ、または、その両方を行うことができる。これらのデータファイルは、ウェブベースのルックアップサービスを介してクライアントに対して使用可能とすることができる。この図７には示していないが、クライアントは、（その既存のスパムフィルタを使用して分類することができないメッセージからのどのようなメッセージまたはフィーチャについても）このルックアップサービスに問い合わせて、特定のアップデートが利用可能かどうかを判定することができる。アップデートが利用可能な場合、このクライアントは、このクライアントが望むアップデートを選択してダウンロードを行い、この既存のスパムフィルタを部分的にまたは増分式にアップデートすることができる。
【００６６】
図７をもう一度参照すると、７４０においてこの古いスパムフィルタは、１つまたは複数のデータファイルを用いてアップデートすることができる。したがって、この古いフィルタを全体に新しいフィルタで置き換えるのとは対照的に、この古いフィルタは、十分な量の変更を示しているデータを用いて、増分式にアップデートされる。
【００６７】
実際には、例えばこの古いフィルタと新しいフィルタの間で、パラメータの絶対値を比較することができる。変更のしきい値を設定することができる。任意のパラメータのこの絶対値の変更がこのしきい値を満たすときには、次いでこのような変更をアップデートコンポーネントまたはデータファイルに保存することができる。メッセージ中のこれらのパラメータの頻度など、他のファクタが、特定の「変更」がアップデート中に含まれるかどうかに影響を及ぼす可能性がある。アップデートは、データファイルとして記憶することができ、ルックアップテーブル中に整理することができ、かつ／または検索可能データベースに保存することができる。
【００６８】
さらに、アップデート要求は、サーバおよび／または個々のクライアントにより行うことができる。例えば、サーバ管理者は、着信メッセージおよびそのフィルタリングを検査することができ、ある種のメッセージについてのユーザの苦情の増大数、および／または隔離中のメッセージ数またはメッセージの類似点の増大を観察することなど様々なファクタに基づいて、特定のアップデートを必要とするかを決定することができる。これらの領域の問題に対処するために、サーバは、増分フィルタアップデートを少なくとも部分的に要求することができる。したがって、これらのアップデートは、このサーバ側で適用され、次いで個々のクライアントに対して適用されるはずである。
【００６９】
逆に、クライアントは、増分アップデートデータを直接に要求し、それにアクセスさえすることができる。手持ちの疑わしいメッセージからの特定の疑わしいメッセージまたはフィーチャを用いて、クライアントは、オンラインルックアップテーブルまたはデータベースを介して、これらのメッセージからのこの特定のメッセージまたはフィーチャが、それに対応する任意のアップデートを有するかどうかについて問い合わせることができる。もしあれば、次いで、この関連アップデートをこのクライアントに対してダウンロードし、クライアントのフィルタに適用することができる。サーバまたはそのスパムフィルタは、これらのアップデートによって影響を受けることはない。したがって、クライアントは、クライアントが受信しているメッセージの特定のタイプに少なくとも部分的に基づいて、彼らのスパムフィルタに対するアップデートの内容をカスタマイズまたは個人専用のものにすることができる。さらに、より最近のデータがあるかについてこのアップデートまたはルックアップシステムに問い合わせることの方が、隔離プロセスを介して待つよりも高速にすることができる。さらに、この古いフィルタは、ルックアップサービス／システムによって部分的に増分式に、かつ／または部分的にアップデートすることができる。
【００７０】
スパムフィルタは、数千のパラメータ（各パラメータはそれに関連付けられた値を有する）をトレーニングすることができる。１つのパラメータに対する小さな変更は、少なくとも他のパラメータのすべてに少なくとも小さな変更を引き起こす可能性がある。したがって、ある程度まで、パラメータの間に多数の「差」または変更を有することが可能である。変更の数およびフィルタアップデートの全体サイズを最小にするために、図８に示す例示的なプロセス８００を使用することができる。プロセス８００の結果として、フィルタに対するアップデートは、古いデータと新しいデータの間のより重要な、また、意味のある変更に対して焦点を当てることができる。
【００７１】
この図８に示すように、８１０において、第１の新しいフィルタ（例えば、フィルタＫ）は、新しくまたは最近受信したメッセージから抽出されるデータを使用してトレーニングすることができる。このようなトレーニングについては、機械学習技法を使用することができる。８２０において、この新しいフィルタＫと、（現在使用中の）古いまたは既存のフィルタの間の差分は、例えば１つまたは複数の経験則に少なくとも部分的に基づいて、分離することができる。例えば、フィーチャ重み付けを比較し、８３０においてこの差分の絶対値を決定することができる。メッセージにおけるこの変更したフィーチャまたはパラメータの頻度も、考慮することができる。他の多数の経験則を同様に使用することもできる。さらに、１つまたは複数のしきい値を構成し、次いでこれらの差分の絶対値と比較することができる。これらのしきい値は、１つ（または複数）のフィーチャごとに決定して、良いメッセージおよび／またはスパムメッセージ中の様々なフィーチャの頻度または発生レートを明らかにすることもできる。例えば、良いメッセージまたはスパムメッセージにおいてまれにしか発生しないフィーチャについては、より低いしきい値を設定することができる。
【００７２】
８４０において、第２の新しいフィルタ（例えば、フィルタＱ）は、小さな（またはこれらのしきい値または経験則を満たすのには十分大きくない）、フィルタＪとＫの間の差分のすべてが、フィルタＪ中で有していた同じ値を有することができるという制約条件に従ってトレーニングすることができる。したがって、これらの特定のフィーチャについての重み付けは、この第２の新しいフィルタにおいて一定に保持することができる。８５０において、この古いフィルタＪとこの第２の新しいフィルタＱの間の差分を見出すことができる。１つまたは複数のしきい値または経験則を満たすこれらの差分を、アップデートデータファイルに記憶することができる。この第２の新しいフィルタＱ中のこれらフィーチャの多くは、この古いフィルタＪ中と同じ値を有すべきという制約があるので、これらの２つのフィルタ間においては変更の数がより少なくなることが、明らかなはずである。したがって、このフィルタアップデートは、より小さくなる。次いで、８６０において、この古いフィルタＪをアップデートすることができる。
【００７３】
代わりに、この古いフィルタデータの一部分をアップデートすることもできる。例えば、（どのようなテキストに関連したフィーチャとも独立に）ＩＰアドレスまたはＵＲＬデータだけを検査しアップデートすることができる。一般的に、サーバまたはクライアントが、しばらくの間インターネットに接続しておらず、今度は複数のアップデートを必要とする状況においては特に、アップデートを一連の順序で適用することが可能である。各アップデートをダウンロードし、次いで順番に適用することができる。逆に、これらの必要なアップデートを解析し、次いで1つにまとめてこのアップデートの全体サイズを小さくすることができる。例えば、重み付けは、このサーバの最後のアップデート以来、数回変更していることもある。この重み付けに対する各変更を用いてこのフィルタをアップデートする代わりに、この最後のいちばん最近の重み付け値を適用することができ、他の「中間」値は、無視することもできる。したがって、より小さなアップデート、または、より少ないアップデートがもたらされる。
【００７４】
増分アップデートのストレージは、特定のサーバまたはクライアントに応じて柔軟なものとすることができる。例えば、アップデートは、別のファイルに記憶し、次いで最初の（フィルタ）ファイルと1つにまとめることができる。しかし、アップデートファイルは、これらを利用した後すぐに、捨てることができる。したがって、ベースフィルタファイル（ｂａｓｅ  ｆｉｌｔｅｒ  ｆｉｌｅ）を維持することができ、次いでいちばん最近の差を、実行中に確認することができる。時には、一部のフィーチャは、最終的には０の重みにすることが可能である。これらのフィーチャをこのフィルタから削除して、スペースを節約することができる。
【００７５】
本発明の様々な態様についての追加的な環境を提供するために、図９および以下の説明においては、本発明の様々な態様を実装することができる適切な動作環境９１０の簡潔な、一般的な説明を提供することが意図されている。本発明は、１台もしくは複数台のコンピュータまたは他のデバイスが実行する、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈において説明しているが、本発明は、他のプログラムモジュールと組み合わせて、またはハードウェアとソフトウェアの組合せとして、あるいはその両方によって実装することもできることは当業者には理解されよう。
【００７６】
しかし、一般的にプログラムモジュールは、特定のタスクを実施し、特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでいる。動作環境９１０は、適切な動作環境の一実施例にすぎず、本発明の用途または機能の範囲についてどのような限定を示唆することも意図していない。本発明と共に使用するのに適したものとすることができる他のよく知られているコンピュータシステム、コンピュータ環境、および／またはコンピュータコンフィギュレーションには、それだけには限定されないが、パーソナルコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブルな大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、これらの以上のシステムまたはデバイスを含む分散コンピューティング環境などが含まれる。
【００７７】
図９を参照すると、本発明の様々な態様を実装する例示的な環境９１０は、コンピュータ９１２を含んでいる。コンピュータ９１２は、処理装置９１４、システムメモリ９１６、およびシステムバス９１８を含んでいる。このシステムバス９１８は、それだけには限定されないがシステムメモリ９１６を含めて、システムコンポーネントを処理装置９１４に結合する。この処理装置９１４は、様々な使用可能なプロセッサのうちのいずれにすることも可能である。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャもまた、処理装置９１４として使用することができる。
【００７８】
システムバス９１８は、メモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはそれだけには限定されないが、１１−ビットバス、ＩＳＡ、ＭＣＡ、ＥＩＳＡ、ＶＬＢ、ＰＣＩ、ＵＳＢ、ＡＧＰ（Ａｄｖａｎｃｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）、ＰＣＭＣＩＡバス、およびＳＣＳＩを含めて様々な使用可能な任意のバスアーキテクチャを使用したローカルバスを含む、いくつかのタイプの１つ（または複数）のバス構造のうちのいずれにもすることが可能である。
【００７９】
システムメモリ９１６は、揮発性メモリ９２０および不揮発性メモリ９２２を含んでいる。起動中などコンピュータ９１２内の要素間において情報を転送する基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ基本入出力システム）は、不揮発性メモリ９２２に記憶される。例証として限定するものではないが、不揮発性メモリ９２２は、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ（またはフラッシュメモリを含むことが可能である。揮発性メモリ９２０は、ＲＡＭを含んでおり、このＲＡＭは外部キャッシュメモリとしての役割を果たす。例証として限定するものではないが、ＲＡＭは、ＳＲＡＭ、ＤＲＡＭ、ＳＤＲＡＭ、ＤＤＲ  ＳＤＲＡＭ、ＥＳＤＲＡＭ（ｅｎｈａｎｃｅｄ  ＳＤＲＡＭエンハンストＳＤＲＡＭ）、ＳＬＤＲＡＭ（Ｓｙｎｃｈｌｉｎｋ  ＤＲＡＭシンクリンクＤＲＡＭ）、ＤＲＲＡＭなど多くの形態で使用可能である。
【００８０】
コンピュータ９１２はまた、着脱可能／着脱不能な、揮発性／不揮発性のコンピュータストレージ媒体も含んでいる。図９は、例えばディスクストレージ９２４を示している。ディスクストレージ９２４は、それだけには限定されないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックのようなデバイスを含んでいる。さらにディスクストレージ９２４は、それだけには限定されないが、ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ  ｄｉｓｋ  ＲＯＭコンパクトディスクＲＯＭ）デバイス、ＣＤ−Ｒ（ＣＤ  ｒｅｃｏｒｄａｂｌｅ書込み可能ＣＤ）ドライブ、ＣＤ−ＲＷ（ＣＤ  ｒｅｗｒｉｔａｂｌｅ再書込み可能ＣＤ）ドライブ、またはＤＶＤ−ＲＯＭ（デジタル多用途ディスクＲＯＭ）ドライブなどの光ディスクドライブを含めて、他のストレージ媒体と別々の、または組み合わせたストレージ媒体を含むことができる。ディスクストレージデバイス９２４のシステムバス９１８に対する接続をスムーズに実施するために、インターフェース９２６など着脱可能または着脱不能なインターフェースが、一般的に使用される。
【００８１】
図９は、好適な動作環境９１０中に記述されたユーザと基本的なコンピュータリソースとの間の仲介手段としての役割を果たすソフトウェアを説明していることを理解されたい。このようなソフトウェアは、オペレーティングシステム９２８を含んでいる。ディスクストレージ９２４上に記憶することができるオペレーティングシステム９２８は、コンピュータシステム９１２のリソースを制御し割り付ける機能を果たす。システムアプリケーション９３０は、システムメモリ９１６またはディスクストレージ９２４のいずれかに記憶されるプログラムモジュール９３２およびプログラムデータ９３４を介してオペレーティングシステム９２８によるリソースの管理を利用している。本発明は、様々なオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実装することができることを理解されたい。
【００８２】
ユーザは、１つ（または複数）の入力デバイス９３６を介してコンピュータ９１２にコマンドまたは情報を入力する。入力デバイス９３６は、それだけには限定されないが、マウス、トラックボール、スタイラス、タッチパッドなどのポインティングデバイス、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどを含んでいる。これらおよび他の入力デバイスは、システムバス９１８を介して１つ（または複数）のインターフェースポート９３８を経由して処理装置９１４に接続される。１つ（または複数）のインターフェースポート９３８は、例えばシリアルポート、パラレルポート、ゲームポート、およびＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓユニバーサルシリアルバス）を含んでいる。１つ（または複数）の出力デバイス９４０は、１つ（または複数）の入力デバイス９３６と同じタイプのポートのうちの一部のポートを使用している。したがって、例えば、ＵＳＢポートを使用して、コンピュータ９１２に対する入力を提供し、コンピュータ９１２から出力デバイス９４０へと情報を出力することができる。出力アダプタ９４２は、専用のアダプタを必要とする他の出力デバイス９４０のうちに、モニタ、スピーカ、およびプリンタのような一部の出力デバイス９４０が存在することを示すように提供される。出力アダプタ９４２は、例証として限定するものではないが、出力デバイス９４０とシステムバス９１８の間の接続の手段を提供するビデオカードおよびサウンドカードを含んでいる。１台（または複数台）のリモートコンピュータ９４４など、他のデバイスおよび／またはデバイスのシステムは、入力機能も出力機能も共に提供することに留意されたい。
【００８３】
コンピュータ９１２は、１台（または複数台）のリモートコンピュータ９４４など、１台または複数台のリモートコンピュータに対する論理接続を使用して、ネットワーク環境中で動作することができる。この１台（または複数台）のリモートコンピュータ９４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの家庭電気製品、ピアデバイス、または他の共通ネットワークノードなどとすることが可能であり、一般的にコンピュータ９１２に対して説明したエレメントのうちの多くまたはすべてを含んでいる。簡潔に示すために、メモリストレージデバイス９４６だけしか、１台（または複数台）のリモートコンピュータ９４４と共に示していない。１台（または複数台）のリモートコンピュータ９４４は、ネットワークインターフェース９４８を介してコンピュータ９１２に論理的に接続され、次いで通信接続９５０を経由して物理的に接続される。ネットワークインターフェース９４８は、ＬＡＮやＷＡＮなどの通信ネットワークを包含している。ＬＡＮ技術は、ＦＤＤＩ、ＣＤＤＩ（Ｃｏｐｐｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ銅配線分散データインターフェース）、イーサネット（登録商標）／ＩＥＥＥ１１０２．３、トークンリング／ＩＥＥＥ１１０２．５などを含んでいる。ＷＡＮ技術は、それだけには限定されないが、ポイントツーポイントリンク、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ統合デジタルサービス通信網）およびその変形のような回路交換網、パケット交換網、およびＤＳＬを含んでいる。
【００８４】
１つ（または複数）の通信接続９５０は、ネットワークインターフェース９４８をバス９１８に接続するために使用されるハードウェア／ソフトウェアを意味する。通信接続９５０は、分かりやすく図示するためにコンピュータ９１２の内部に示しているが、コンピュータ９１２の外部に存在することも可能である。このネットワークインターフェース９４８に接続するために必要なハードウェア／ソフトウェアは、例示の目的にすぎないが、通常の電話品質のモデム、ケーブルモデムおよびＤＳＬモデムを含めたモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）カードなど内蔵または外付けの技術を含んでいる。
【００８５】
以上で説明してきた内容は、本発明の実施例を含んでいる。本発明を説明する目的でコンポーネントまたは方法のあらゆる考え得る組合せについて説明することは、もちろん可能ではないが、本発明のさらに多くの組合せおよび置換が可能になることが当業者には理解されよう。したがって、本発明では、添付の特許請求の範囲の趣旨および範囲内に含まれるこのようなすべての変更形態、修正形態、および変形形態を包含することが意図されている。さらに、用語「含む（ｉｎｃｌｕｄｅｓ）」が、この詳細なる説明または特許請求の範囲において使用される限りでは、「含む（ｃｏｍｐｒｉｓｉｎｇ）」が使用される際には特許請求項中における移行語として解釈されるので、このような用語は、この用語「含む（ｃｏｍｐｒｉｓｉｎｇ）」と同様にして包含することを意図している。
【図面の簡単な説明】
【００８６】
【図１】本発明の一態様による、スパムフィルタに対する機械学習アップデートの提供を実施するアンチスパムアップデートシステムのブロック図である。
【図２】本発明の一態様による増分アップデートシステムの概略ブロック図である。
【図３】本発明の一態様による、限られたパラメータ変更数を有する、スパムフィルタを生成しスパムフィルタに対するアップデートを行うシステムまたはメカニズムを示す概略図である。
【図４】本発明の一態様による、クライアント要求に少なくとも部分的に基づいたアンチスパムアップデートシステムのブロック図である。
【図５】本発明の一態様による、クライアント要求に少なくとも部分的に基づいたアンチスパムアップデートシステムのブロック図である。
【図６】本発明の一態様による、例示的なアンチスパムルックアップウェブサービスの概略図である。
【図７】本発明の一態様による、少なくとも増分式に（ｉｎｃｒｅｍｅｎｔａｌｌｙ）スパムフィルタのアップデートを実施する例示的な方法を示すフローチャートである。
【図８】本発明の一態様による、以前のフィルタからのアップデートまたは変更が最少の量を示すフィルタの生成を実施する例示的な方法を示すフローチャートである。
【図９】本発明の様々な態様を実装するための例示的な環境を示す図である。
【図１】
2006012165.tif 000003
【図２】
2006012165.tif 000004
【図３】
2006012165.tif 000005
【図４】
2006012165.tif 000006
【図５】
2006012165.tif 000007
【図６】
2006012165.tif 000008
【図７】
2006012165.tif 000009
【図８】
2006012165.tif 000010
【図９】
2006012165.tif 000011
【外国語明細書】
2006012165000001.pdf