(57)【要約】  １つ又はそれ以上のフォーマット（１０４）で事象ベースのフィード又は時間ベースのフィードとして受信することができるコンテンツに基づいてアラートメッセージを供給するアーキテクチャ。このアーキテクチャは、コンテンツを予め定義されたデータ構造に正規化し、選択された特性に従って大量のコンテンツを処理するためにコンテンツを索引付けするためのデータ収集処理モジュール（１０３）を含む。マッチングエンジン（１１０）はユーザクエリーを利用して、事象ベースのコンテンツを選択されたコンテンツに関連するアラートメッセージを受信することに関心を示した１人又はそれ以上のユーザに関連付ける。またマッチングエンジンは、対応するアラートメッセージを発信する。ポーラー（１２０）は、予め定義された時間期間にユーザに代わってコンテンツをフェッチし、対応するアラートメッセージを発信する。配信インターフェース（１３０）は、どのアラートメッセージを即時に送るべきか、どのアラートメッセージを後で配信するようスケジュールするかを判断する。アーキテクチャは、スケーラビリティ及びバックアップのためにミラーリングされる（１５８）。【選択図】図１
2007516511.tif 000002
【特許請求の範囲】
【請求項１】
アラートメッセージをアクセス可能にする方法であって、
複数のフォーマットでアクセス可能なコンテンツを正規化する段階と、
前記コンテンツの少なくとも１つの特性に従って前記コンテンツを索引付けする段階と、
少なくとも１人のユーザの少なくとも１つの予め決められた関心に関連付けられた前記コンテンツの少なくとも一部分を前記少なくとも１人のユーザに関連付ける段階と、
前記コンテンツの少なくとも一部分に関係するアラートメッセージを、前記アラートメッセージを受信するよう選択した前記少なくとも１人のユーザに発信する段階と、
前記少なくとも１人のユーザによって予め定義された少なくとも１つの配信機構により前記少なくとも１人のユーザが前記アラートメッセージにアクセスできるようにする段階と、
を含む方法。
【請求項２】
事象ベースのフィードとして前記コンテンツを受信する段階と、
時間ベースのフィードとして前記コンテンツを要求する段階と、
のうちの少なくとも１つを更に含む請求項１に記載の方法。
【請求項３】
前記コンテンツを正規化する段階が、前記コンテンツを前記複数のフォーマットのいずれか１つから正規化されたフォーマットに変換する段階を含む請求項１に記載の方法。
【請求項４】
前記コンテンツの少なくとも１つの特性は、
前記コンテンツが受信された時間と、
前記送信側の識別子と、
前記コンテンツのタイプと、
前記コンテンツが送信された国と、
前記コンテンツがポーリング要求に関連付けられていることを示す表示と、
前記コンテンツが以前受信しコンテンツに関連付けられていることを示す表示と、
のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記コンテンツの少なくとも一部分を関連付ける段階が、
前記少なくとも１人のユーザの少なくとも１つの関心を表すクエリー式に対して前記コンテンツの少なくとも一部分を評価する段階と、
前記コンテンツの少なくとも一部分が前記クエリー式にマッチする場合、前記コンテンツの少なくとも一部分と前記少なくとも１人のユーザとの間の関連付けを設定する段階と、
を含む請求項１に記載の方法。
【請求項６】
前記クエリー式が、前記少なくとも１人のユーザのユーザプロファイルによりアクセスされることを特徴とする請求項５に記載の方法。
【請求項７】
前記コンテンツの少なくとも一部分を関連付ける段階がサービスレベルの質に従って実行されること、
前記アラートメッセージを発信する段階がサービスレベルの質に従って実行されること、
及び、前記少なくとも１人のユーザが前記アラートメッセージにアクセスすることを許可する段階がサービスレベルの質に従って実行されること、
のうちの少なくとも１つであることを特徴とする請求項１に記載の方法。
【請求項８】
前記少なくとも１人のユーザが前記メッセージにアクセスできるようにする段階が、
前記アラートメッセージを前記少なくとも１人のユーザに即時に配信する段階と、
前記アラートメッセージを前記少なくとも１人のユーザに予め定義された時間に配信する段階と、
のうち１つを含む請求項３に記載の方法。
【請求項９】
前記少なくとも１人のユーザが前記アラートメッセージにアクセスできるようにする段階が、
Ｅメールメッセージと、
インスタント・メッセージと、
ショート・メッセージ・サービス・メッセージと、
ボイス・メッセージと、
のうちの少なくとも１つとして前記アラートメッセージを配信する段階を含む請求項１に記載の方法。
【請求項１０】
必要なデータが前記コンテンツに含まれることを確認する段階と、
前記コンテンツの特性を表すために論理オペレーションに従って前記コンテンツを変換する段階と、
前記コンテンツの受信パラメータをロギングする段階と、
前記コンテンツを記憶する段階と、
他のコンテンツに対して前記コンテンツに優先順位を付ける段階と、
前記コンテンツの重複を廃棄する段階と、
のうちの少なくとも１つを更に含む請求項１に記載の方法。
【請求項１１】
正規化、関連付け、発信、及び許可の前記オペレーションをミラーリングする段階を更に含む請求項１に記載の方法。
【請求項１２】
アラートメッセージをアクセス可能にするためのシステムであって、
コンテンツにアクセスしアラートメッセージを伝達するための通信インターフェースと、
前記通信インターフェースと通信するプロセッサと、
前記プロセッサと通信し、前記プロセッサに、
複数のフォーマットでアクセス可能なコンテンツを正規化する段階と、
前記コンテンツの少なくとも１つの特性に従って前記コンテンツを索引付けする段階と、
少なくとも１人のユーザの少なくとも１つの予め決められた関心に関連付けられた前記コンテンツの少なくとも一部分を前記少なくとも１人のユーザに関連付ける段階と、
前記コンテンツの少なくとも一部分に関係するアラートメッセージを、前記アラートメッセージを受信するよう選択した少なくとも１人のユーザに発信する段階と、
前記少なくとも１人のユーザによって予め定義された少なくとも１つの配信機構で前記少なくとも１人のユーザが前記アラートメッセージにアクセスできるようにする段階と、
を含む複数の機能を実行させるデータ及び命令を記憶するメモリと、
を含むシステム。
【請求項１３】
前記命令は、
事象ベースのフィードとして前記コンテンツを受信する段階と、
時間ベースのフィードとして前記コンテンツを要求する段階と、
のうちの少なくとも１つのオペレーションを前記プロセッサに更に実行させることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記命令は、
前記コンテンツを前記複数のフォーマットのいずれか１つから正規化されたフォーマットに変換する段階と、
必要なデータが前記コンテンツに含まれていることを確認する段階と、
前記コンテンツの特性を表すために論理オペレーションに従って前記コンテンツを変換する段階と、
前記コンテンツの受信パラメータをロギングする段階と、
前記コンテンツを記憶する段階と、
他のコンテンツに対して前記コンテンツに優先順位を付ける段階と、
前記コンテンツの重複を廃棄する段階と、
のうちの少なくとも１つのオペレーションを前記プロセッサに更に実行させることを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記コンテンツの少なくとも１つの特性は、
前記コンテンツが受信された時間と、
前記送信側の識別子と、
前記コンテンツのタイプと、
前記コンテンツが送信された国と、
前記コンテンツがポーリング要求に関連付けられていることを示す表示と、
前記コンテンツが前に受信されたコンテンツに関連付けられていることを示す表示と、
のうちの少なくとも１つを含むことを特徴とする請求項１２に記載のシステム。
【請求項１６】
前記命令は、
前記少なくとも１人のユーザの少なくとも１つの関心を表すクエリー式に対して前記コンテンツの少なくとも一部分を評価する段階と、
前記コンテンツの少なくとも一部分が前記クエリー式にマッチする場合、前記コンテンツの少なくとも一部分と前記少なくとも１人のユーザとの間の関連付けを設定する段階と、
からなる各オペレーションを前記プロセッサに更に実行させることを特徴とする請求項１２に記載のシステム。
【請求項１７】
前記命令は、
前記コンテンツの少なくとも一部分を関連付ける段階がサービスレベルの質に従って実行されること、
前記アラートメッセージを発信する段階がサービスレベルの質に従って実行されること、
前記少なくとも１人のユーザが前記アラートメッセージにアクセスすることを許可する段階がサービスレベルの質に従って実行されること、
の各オペレーションを前記プロセッサに更に実行させることを特徴とする請求項１２に記載のシステム。
【請求項１８】
前記命令は、
前記アラートメッセージを前記少なくとも１人のユーザに即時に配信する段階と、
前記アラートメッセージを前記少なくとも１人のユーザに予め定義された時間に配信する段階と、
の各オペレーションを前記プロセッサに更に実行させることを特徴とする請求項１２に記載のシステム。
【請求項１９】
前記アラートメッセージを受信するための移動クライアント装置を更に含むことを特徴とする請求項１２に記載のシステム。
【請求項２０】
前記通信インターフェースと通信し、前記コンテンツにアクセスしてミラーアラートメッセージを伝達するように更に構成されたミラー通信インターフェースと、
前記ミラー通信インターフェースと通信するミラープロセッサと、
前記ミラープロセッサと通信し、前記ミラープロセッサに、
複数のフォーマットでアクセス可能な前記コンテンツを正規化する段階と、
前記コンテンツの少なくとも１つの特性に従って前記コンテンツを索引付けする段階と、
前記少なくとも１人のユーザの少なくとも１つの予め決められた関心に関連付けられた前記コンテンツの少なくとも一部分を前記少なくとも１人のユーザに関連付ける段階と、
前記コンテンツの少なくとも一部分に関係し前記アラートメッセージとほぼ同じ前記ミラーアラートメッセージを前記少なくとも１人のユーザに発信する段階と、
前記少なくとも１人のユーザによって予め定義された前記少なくとも１つの配信機構で前記少なくとも１人のユーザが前記ミラーアラートメッセージにアクセスできるようにする段階と、
を含む複数の機能を実行させるデータ及び命令を記憶するミラーメモリと、
を更に含む請求項１２に記載のシステム。
【請求項２１】
アラートメッセージをアクセス可能にするための変調されたデータ信号であって、
前記変調されたデータ信号が、
複数のフォーマットでアクセス可能なコンテンツを正規化する段階と、
前記コンテンツの少なくとも１つの特性に従って前記コンテンツを索引付けする段階と、
少なくとも１人のユーザの少なくとも１つの予め決められた関心に関連付けられた前記コンテンツの少なくとも一部分を前記少なくとも１人のユーザに関連付ける段階と、
前記コンテンツの少なくとも一部分に関係するアラートメッセージを、前記アラートメッセージの受信を選択した前記少なくとも１人のユーザに発信する段階と、
前記少なくとも１人のユーザによって予め定義された少なくとも１つの配信機構で前記少なくとも１人のユーザが前記アラートメッセージにアクセスできるようにする段階と、
からなる各動作をコンピュータデバイスが実行できるようにする命令を含むことを特徴とする変調されたデータ信号。
【請求項２２】
アラートメッセージの正規化されたコンテンツのためのデータ構造であって、
前記コンテンツのステータスを示すコンタクトと、
前記コンテンツの日付と、
前記コンテンツの有効期限と、
前記コンテンツに関連付けられたユニフォームリソースロケータと、
前記コンテンツのソースに対応するフィードプロバイダ名と、
コンテンツのタイプと、
前記コンテンツのタイトルと、
前記コンテンツを含むデータ本体と、
を含むデータ構造。
【請求項２３】
メッセージを供給するためのシステムであって、
少なくとも１つのコンテンツソースとインターフェースし、複数のフォーマットでコンテンツにアクセスし、前記コンテンツの少なくとも一部分を正規化されたフォーマットに正規化し、前記コンテンツの少なくとも１つの特性に従って前記コンテンツを索引付けする収集処理モジュールと、
前記収集処理モジュールと通信し、前記少なくとも１人のユーザの少なくとも１つの関心に基づいて少なくとも１人のユーザに関連付けられた前記コンテンツの少なくとも一部分が事象ベースのフィードに対応する場合、前記コンテンツの少なくとも一部分を備えたアラートメッセージを発信するマッチングエンジンと、
前記収集処理モジュールと通信し、少なくとも１人のユーザの少なくとも１つの関心に基づいて前記少なくとも１人のユーザに関連付けられた前記コンテンツの少なくとも一部分が、時間ベースのフィードに対応する場合、前記コンテンツの少なくとも一部分を備えたアラートメッセージを発信するポーラーと、
前記マッチングエンジン及び前記ポーラーと通信し、前記少なくとも１人のユーザによって予め定義されたデータ構造に従って前記少なくとも１人のユーザに前記アラートメッセージを配信する配信インターフェースと、
を含むシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２００３年６月１３日に出願された米国暫定出願第６０／４７８，４０１号による優先権を主張し、先願日の恩恵は、３５Ｕ．Ｓ．Ｃ．１１９（ｅ）下で本明細書によって請求される。
本発明は、一般にはメッセージングに関し、より具体的にはネットワーク全体にわたりアラートの配信を可能にすることに関する。
【背景技術】
【０００２】
幾つかのサービスでは、株価情報のような特殊なコンテンツのアラートをユーザに提供してきた。これらのアラートサービスは、一般に、特定のサービスを登録しているユーザに単一のトピックのコンテンツを提供している。複数のトピックに関するアラートを取得するためには、ユーザは一般に複数のサービスを登録している。
【０００３】
（発明の詳細な説明）
次に、本発明の一部を形成し、例証によって本発明を実施することができる特定の例示的な実施形態を示す添付図面を参照しながら本発明を以下により詳細に説明する。しかしながら、本発明は、多くの種々の形式で具現化することができるが、本明細書で示される実施形態に限定されるものとして解釈すべきではなく、むしろこれらの実施形態は、本開示が完全で完璧なものになり、当業者には本発明の範囲を十分に伝えるために提供される。とりわけ、本発明は、方法又は装置として具現化することができる。従って、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はソフトウェアとハードウェアの態様を組み合わせた実施形態の形式を取ることができる。従って以下の詳細な説明は、限定の意味にとるべきではない。
【０００４】
本明細書全体を通して、「ｃｏｎｎｅｃｔｅｄ」という用語は、接続される要素間のどのような中間装置又は構成要素もない直接の接続を意味する。「ｃｏｕｐｌｅｄ」という用語は、接続される要素間の直接接続、或いは１つ又はそれ以上の受動又は能動的ないずれかの中間装置又は構成要素を介した間接接続を意味する。単数形の意味は複数の言及を含む。「において」の意味は、「において」と「上で」を含む。
【０００５】
簡潔に述べると、本発明は、ユーザが関心を登録することができ、続いて登録された関心に関して新しい情報が使用可能になったときにユーザに対して通知（アラート）を行うようにするシステム及び方法に関する。ユーザの関心対象となり得る幾つかの種類のコンテンツがあり、これらには、限定ではないが、株価フィード、ニュース記事、個人広告、ショッピングリスト価格、画像、サーチ結果などが含まれる。またアラートは、限定ではないが、インスタント・メッセージング（ＩＭ）、Ｅメール、ショート・メッセージ・サービス（ＳＭＳ）、マルチメディア・メッセージ・サービス（ＭＭＳ）、ボイス・メッセージなどを含む、種々の配信方法のいずれか又は全てによりユーザに提供することができる。
【０００６】
場合によっては、ユーザは、幾つかの登録された関心についてのアラートが全ての使用可能な方法によって提供されるように選択し、他の登録された関心についての他のアラートが１つの方法だけによって提供されるように選択することができる。更に、幾つかのアラートは、比較的即時の通知を提供するプッシュ法によって提供できる。この場合、本発明は、記憶されたコンタクト情報を用いて、全ての選択された配信方法でユーザにアラートを配信することができる。対照的に、他のアラートは、他の登録された関心に関するユーザからの要求に応答してアラートで返信するプル法によって提供できる。この要求はまた、定期的なアラートを提供するように予め定義された時間をスケジュールすることができる。
【０００７】
ネットワーク上のあるネットワークアドレストランスレーション（ＮＡＴ）装置の向こう側から本発明によって通信するユーザに対しては、プル法では、ユーザのプル要求によって確立された接続を利用してユーザにアラートを送信する。プルアラートが提供される回数は、ユーザが本発明のプル要求を行う頻度によって決まる。しかしながら、ＮＡＴを通して本発明により通信していない他のユーザに対しては、選択された時間間隔でプッシュ法を用いて、それほど緊急ではないアラートを提供することができる。
【０００８】
アラートの履歴は、ユーザ用のウェブページ上で提供することができる。また、ほぼ同じ登録関心のアラートを処理するクエリーを組み合わせて、本発明のスケーリングを比較的多数のユーザに対して可能にすることができる。更にスケーラビリティを可能にするためには、拡張マークアップ言語（ＸＭＬ）フィードなどによる新しいコンテンツ情報が利用可能になると、クエリーのブール事前処理及び事前索引付けを登録関心についての新しいコンテンツ情報に対して適用することができる。また、限定ではないが、登録関心のブールクエリー、配信方法、タイムスケジュール及び同様のものが含まれる種々の情報を含むユーザプロファイルを提供することができる。
【０００９】
図１は、本発明による例示的なアラート・アーキテクチャを示す。アラート・アーキテクチャは、１つ又はそれ以上のソフトウェアモジュール及び／又はサーバー、クライアント装置、及び同様のものなどの１つ又はそれ以上のコンピュータデバイスにより実施することができる。コンピュータデバイスは、一般に、プロセッサ、メモリ、通信インターフェース、及び入出力インターフェース、記憶装置、及び／又は他の従来のコンピュータ構成要素を含む。アラート処理システム１００ａは、ソースコンテンツ１０１、パートナーアラート１０２、プルコンテンツ１２２、及び／又はクライアント装置へのアラートとして配信する他のコンテンツ情報にアクセスする。ソースコンテンツ１０１は、個人広告、ショッピングプライス、ニュース記事、及び同様のものなどの種々のコンテンツを含むことができる。パートナーアラート１０２は、トピックサービスからのアラートとして既に提供できるようになっている株価情報、オークション入札、及び同様のものなどのコンテンツを更に含む。１つ又はそれ以上のフィード収集サーバー１０３は、コンテンツを受信し、図２及び３に関して更に詳細に説明されるように入力処理を実行する。即時に処理されないコンテンツについては、収集サーバー１０３がそのコンテンツをストレージサーバー１０４に送る。
【００１０】
１つ又はそれ以上のマッチングサーバー１１０は、選択されたコンテンツについてのアラートを受信することに関心を示したユーザにコンテンツを関連付ける。一般的にはマッチングサーバー１１０は、コンテンツソースがユーザ要求に未だ関連付けられていないコンテンツに割り込むときに用いられる。１つ又はそれ以上のタイプのアラートを受信することに対する関心は、ユーザデータベース１１５に記憶されているユーザプロファイルに示される。ユーザプロファイルは、ユーザ識別子、所望のアラートタイプ、所望の配信方法、及び他の情報を含む。ポーラー１２０は、ユーザに代わってコンテンツに対する要求を管理する。一般的に、ポーラー１２０は、コンテンツソースからのコンテンツにアクセスを開始する。ポーラー１２０は、収集サーバー１０３にコンテンツをプッシュしないコンテンツソースからのある独立したプルコンテンツ１２２にアクセスすることができる。
【００１１】
１つ又はそれ以上の配信サーバー１３０は、マッチングサーバー１１０及びポーラー１２０と通信している。配信サーバー１３０は、ポーラー１２０からのプルコンテンツ１２２、マッチングサーバー１１０からのプッシュコンテンツ、及びユーザデータベース１１５からのユーザ情報にアクセスする。配信サーバー１３０は、即時及び事前にスケジュールされた配信のためにアラートの分配に優先順位を付けて管理する。事前スケジュールされたアラートは、１つ又はそれ以上のストレージサーバーセット１３２ａ−１３２ｎ上に記憶される。各セットは、アラートのタイプ、配信方法、及び／又は他の特性に相当する。アラートが作成され配信されると、ユーザモニター１４０は、パターン及び／又は他のインサイトについてアラートの流れを監視する。またモニター１４０は、ウェブサイトへのナビゲート、オンライン購入、及び同様のものなどいった、ユーザの行動についての情報を追跡し、及び／又は該情報にアクセスすることができる。追跡された行動はまた、ユーザデータベース１１５のユーザプロファイル内に記憶されるユーザの関心を示している。ロガー１４２は、個々のユーザ、アラートタイプ、及び他のパラメータに関連付けられたデータを追跡する。デバッガー１４４は、アラートの処理に関する問題を解決するために使用される。アラートが配信される予定の場合、アラートは、ユーザが好む方法による配信のための１つ又はそれ以上の適切なサーバーに転送される。例えば、Ｅメールアラートは、バルクサーバー１５２を介して配信することができる。無線携帯機器へのアラートは、無線サーバー１５４を介して配信することができる。インスタント・メッセージアラートは、インスタント・メッセージサーバー１５６を介して配信することができる。各アラートは、一般に、ユーザプロファイルで識別されたクライアント装置にネットワーク１６０をわたり伝達される。ユーザは、アラートが、パーソナルコンピュータ（ＰＣ）１６２、携帯端末１６４、ハンドヘルドコンピュータ１６６、及び／又は同様のものの１つ又はそれ以上に配信されるように指示することができる。
【００１２】
また、ミラーインターフェース１５８を用いて、１つ又はそれ以上のミラーアラート処理システム１００ｂと通信することができる。上記で導入されたデータ及び処理オペレーションの全部又は一部は、同じ場所及び／又は異なる場所で並行処理を行うために複製することができる。ミラーインターフェース１５８は、各サーバータイプがミラードサーバータイプと通信できるように、中央通信インターフェースを含むことができ、及び／又は上記で考察されたサーバーの各々に分散させることができる。各ミラードアラート処理システムでは、各サーバータイプのオペレーションは、ローカルに固有な要素に対してカスタマイズすることができる。
【００１３】
図２は、図１に関して説明されたアーキテクチャに対応する機能要素間の関係及びデータの流れを示す機能ブロック図である。プッシュ又はプルされたソースコンテンツ１７０は、ハイパーテキストマークアップ言語（ＨＴＭＬ）文書、ＸＭＬ文書、テキストファイル、Ｅメールメッセージ、インスタント・メッセージ、及び同様のものなどとして含む１つ又はそれ以上の形式で受信される。必要な場合、収集処理モジュール１７２は、受信されるコンテンツの種々の形式を正規化するために、受信されたコンテンツに１つ又はそれ以上の事前処理オペレーションを実行する。正規化されたコンテンツ文書は一般に、ソース、タイムスタンプ、コンテンツのタイプ、及び／又はフィード記憶領域１０４ａ内での容易な記憶及び検索の他の特性によって索引付けされ、該フィード記憶領域にはまた、記憶ディレクトリパスに基づいてユニバーサルリソースロケータ（ＵＲＬ）が割り当てられる。ＵＲＬは、後で検索するために収集処理モジュール１７２で使用可能にされる。収集処理については、図３に関して更に詳細に説明する。
【００１４】
管理インターフェース１７４は、レビュー、及び／又はステータス、サーチ、手動入力コンテンツ、及び同様のものを取得するなどの管理機能用に受信されたデータにアクセスすることが可能である。また、管理用インターフェース１７４を用いて、システムが適切に動作していることを確実にするよう追跡される検査コンテンツのハートビートフィードをセットアップすることができる。
【００１５】
コンテンツが株価ソースのような事象ベースのフィードからプッシュインされた場合には、コンテンツはマッチングエンジン１１０ａにリレーされる。このリレー及び／又は時間ベースのフィードのような他の通信は、１つのサーバーから別のサーバーにデータをコピーすることができる複製フィードを介して実行することができる。或いは、リレー及び／又は他の通信は、意図された受信者全てが受信するまでデータを同時配信することができるデータバスフィードを介して実行することができる。マッチングエンジンは、受信されたコンテンツについてのアラートを送るべきユーザを決定する。マッチングエンジンは、ユーザデータベースからのユーザプロファイルデータ１１５ａにアクセスし、コンテンツに関するアラートを受け取るよう希望したユーザ、或いは選択したユーザにコンテンツを関連付ける。特に、ユーザプロファイルは、ユーザが交通事故、株価情報、及び同様のものなどのアラートを要求する１つ又はそれ以上のコンテンツタイプを示す。またユーザのプロファイルは、ＡＮＤ、ＯＲ、ＮＯＴ、及び同様のものなどの１つ又はそれ以上の論理演算子を含む１つ又はそれ以上のブールクエリーを示す。ユーザプロファイルのブールクエリーの例を以下に示す。
ＳＴＯＣＫ  ＡＮＤ  （ＣＯＭＰＡＮＹ  ＡＮＤ  ＰＲＩＣＥ＞＄１００）
入力コンテンツタイプが株価情報を含む場合、マッチングエンジン１１０ａはブールクエリーを適用して、株価情報コンテンツが、選択された会社及び＄１００より高い価格に関する情報を含むかどうかを判定する。株価情報がマッチングコンテンツを含む場合には、マッチングエンジン１１０ａは、マッチングコンテンツについてのアラートを要求するユーザのリストにそのユーザを加える。
【００１６】
多くの他のユーザは、同様のクエリーを有することができ、及び／又は入ってくるコンテンツを種々のクエリーとマッチさせることができる。スケーラビリティについての性能を改良するためには、マッチングエンジン１１０ａは、クエリーの索引付けを維持し、各クエリーを同じか又は極めて類似するクエリー結果を要求するユーザに関連付ける。クエリーの索引付けにより、クエリー演算の重複が低減される。今後入ってくるコンテンツでは、これらの事前索引付けされたクエリーに対して解決することができる。マッチングするどのようなクエリーについても、対応するユーザ識別子がリストに加えられる。Ｅメール、インスタント・メッセージ、携帯電話、及び同様のものなどといった、ユーザが希望する配信方法がユーザのプロファイルから取られて、リスト内に含められる。同様に、配信を希望する時間は、ユーザプロファイルにおいて指定することができる。また、ユーザに送られるアラート及び又は他のメッセージの数を制限するメッセージ制限についても、ユーザプロファイルにおいて設けることができる。クエリーは、コンテンツのタイプ、コンピュータデバイスの電流負荷、及び／又は他の特性に基づいてコンピュータデバイス間に分散することができる。全てのクエリーの実行がコンテンツに対して完了すると、マッチングエンジン１１０ａは、配信インターフェース１３０ａにコンテンツ及びリストをリレーするよう準備する。
【００１７】
リレーの前に、マッチングエンジン１１０ａはまた、ユーザプロファイルデータ、コンテンツのタイプ、送信されることになるアラートのタイプ、及び同様のものに基づいて優先順位を決定することができる。優先順位は、サービス品質（ＱＯＳ）レベルと呼ばれる場合もある。例えば、株価コンテンツは通常は時間の影響を極めて受けやすく、従って、マッチングエンジンは、株価コンテンツをユーザにマッチングさせることに関して高い優先順位（例えば高ＱＯＳレベル）を付与することができる。別の実施例として、マッチングエンジンは、ユーザプロファイルデータ１１５ａを使用して、有料のサービスプラン及び／又は他の特性に従ってユーザへの出力アラートに優先順位を付けることができる。
【００１８】
スケジュールされた時間ベースのフィードを使用してプルされるコンテンツでは、ポーラー１２０ａは、指示されたコンテンツタイプに関するアラートを望む１人又はそれ以上のユーザ向けにコンテンツを要求する。ポーラー１２０ａは、収集処理モジュール１７２から、或いは収集処理モジュール１７２にコンテンツを送るように事前に構成することができない外部ソースから直接コンテンツをプルすることができる。外部コンテンツは正規化され、或いは、要求されたコンテンツがポーラー１２０ａに送られる前にコンテンツソースによって事前処理されない場合には上述の方法で事前処理される。ポーラープロセスに関する詳細は更に、図４及び図５に関して以下で説明する。
【００１９】
いずれの場合においても、コンテンツがエンドユーザに配信されることになる場合、図２に示された配信インターフェース１３０ａは、ユーザによって要求される１つ又はそれ以上の方法でアラートを発信する。例えば、あるユーザは、携帯電話番号にショート・メッセージ・サービス（ＳＭＳ）のメッセージとして配信されるアラートを要求することができる。配信インターフェース１３０ａは一般に、配信方法に対応するテンプレートを使用する。テンプレートは、最終アラートを発信するために、コンテンツ文書又はコンテンツ文書へのＵＲＬに利用される。また配信インターフェース１３０ａは、各ユーザに対するアラート配信のタイミング及び／又は他のＱＯＳ態様を管理する。例えば、幾つかのアラートは即時に配信され、他のアラートは、後で配信するようにスケジュールすることができる。他の実施例には、地理的な場所、ビジネスパートナー、コンテンツソース、及び／又は他のパラメータに基づいて転送する構成が含まれる。また配信インターフェース１３０ａは、配信できないアラート、及び／又は他のメンテナンス問題を管理する。配信に関する詳細は、図６に関して以下に更に説明する。
【００２０】
コンテンツデータ収集処理
コンテンツ収集処理に関して更に詳細は説明しない。図３は、収集されたコンテンツを処理するための例示的な論理を示すフロー図である。コンテンツが受信されると、オペレーション１８０でそのソースが認証される。認証及び／又は他のセキュリティ対策は、デジタル証明、デジタル署名、暗号化、仮想私設ネットワークトンネル及び同様のものを含む１つ又はそれ以上の方法で実施することができる。コンテンツのソースもまた、Ｙａｈｏｏ！，Ｉｎｃなどによって提供されるドメイン鍵アプリケーションを含むがこれに限定されないドメインセキュリティ機構で認証することができる。
【００２１】
オペレーション１８２で、受信されたコンテンツは、ＸＭＬフォーマットなどの標準コンテンツフォーマットに変換される。テーブル１は、受信されたコンテンツが更なる処理及びアラートとしての結果として生じる配信用に正規化されるＸＭＬデータ構造の例を示す。
【００２２】
テーブル１：ＸＭＬデータ構造の例
2007516511.tif 000003
以下のコードは、アラートを発信するのに使用することができる交通事故に関する正規化ＸＭＬコンテンツ文書の例を示す。
【００２３】
＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝”１．０”ｅｎｃｏｄｉｎｇ＝”ＵＴＦ−８”？＞
＜ＡｌｅｒｔｓＤｏｃｕｍｅｎｔ＞
＜Ｃｏｎｔａｃｔ＞ｓｈｉ＠ｙａｈｏｏ−ｉｎｃ．ｃｏｍ＜／Ｃｏｎｔａｃｔ＞
＜Ｃｏｕｎｔｒｙ＞ＵＳ＜／Ｃｏｕｎｔｒｙ＞
＜Ｄａｔｅ＞１０４８４９５６２００００＜／Ｄａｔｅ＞
＜ＥｘｐｉｒａｔｉｏｎＤａｔｅ＞１０４８４９７４２００００＜／ＥｘｐｉｒａｔｉｏｎＤａｔｅ＞
＜Ｕｒｌ＞ｈｔｔｐ：／／ａｌｅｒｔｓ．ｙａｈｏｏ．ｃｏｍ／＜／Ｕｒｌ＞
＜Ｆｅｅｄ＞ｕｓ＿ｔｒａｆｆｉｃ＜／Ｆｅｅｄ＞
＜Ｔｙｐｅ＞ｔｒａｆｆｉｃ＜／Ｔｙｐｅ＞
＜Ｔｉｔｌｅ  ｍａｔｃｈｉｎｇ＝１＞
Ｄｉｓａｂｌｅｄ  ｖｅｈｉｃｌｅ
＜／Ｔｉｔｌｅ＞
＜Ａｂｓｔｒａｃｔ  ｍａｔｃｈｉｎｇ＝１＞
故障車
＜／Ａｂｓｔｒａｃｔ＞
＜Ｂｏｄｙ＞
（事故についての他の記述）
＜／Ｂｏｄｙ＞
＜Ａｌｅｒｔ＿Ｄａｔａ＞
＜ＤＥＳＣ＞故障車＜／ＤＥＳＣ＞
＜ＬＡＴＩＴＵＤＥ＞３８．５５４２８９＜／ＬＡＴＩＴＵＤＥ＞
＜ＬＯＮＧＩＴＵＤＥ＞−１２１．４０６１８１＜／ＬＯＮＧＩＴＵＤＥ＞
＜ＳＥＶＥＲＩＴＹ＞２＜／ＳＥＶＥＲＩＴＹ＞
＜ＳＴＡＴＥ＞ＣＡ＜／ＳＴＡＴＥ＞
＜ＭＡＲＫＥＴＣＯＤＥ＞ＳＡＣ＜／ＭＡＲＫＥＴＣＯＤＥ＞
＜ＥＮＤＴＩＭＥ＞Ｍｏｎ  Ｍａｒ２４  ０９：１７：００  ２００３＜／ＥＮＤＴＩＭＥ＞
＜ＩＴＩＳＣＯＤＥ＞２１１＜／ＩＴＩＳＣＯＤＥ＞
＜ＩＴＩＳＭＥＳＳＡＧＥ＞事故についての他の記述＜／ＩＴＩＳＭＥＳＳＡＧＥ＞
…
＜／ＡｌｅｒｔＤａｔａ＞
＜／ＡｌｅｒｔｓＤｏｃｕｍｅｎｔ＞
【００２４】
オペレーション１８４で、収集処理モジュールはコンテンツを確認し、必要なデータがソースにより含まれていたことを検証する。また確認には、以前受信された重複コンテンツを更新する段階及び／又は排除する段階、及び／又は他のデータ・インテグリティ態様を保証する段階を含むことができる。更に、確認には、認証されたソースから正しく受信されたコンテンツを検証する段階を含むことができる。この検証は、暗号化／解読、デジタル署名、デジタル証明、パスワード、対称鍵ペア、非対称鍵ペア、及び同様のもの確認を含むことができる。
【００２５】
典型的には、標準ＸＭＬコンテンツ文書は、修正を加えることなく処理することができる。しかしながら、フィード変換オペレーション１８５の間に幾分修正を加えることもできる。多くの場合、コンテンツフィード変換は、確認問題に対処するために、マイナーフォーマッティング変換又は簡単なストリング置換を含むことになる。それでも尚、より複雑な論理オペレーションを実行することができる。例えば、予め定義されたパーセンテージの株価変動が生じたかどうかを判定するために、入ってくる株価情報を以前の株価情報と比較することができる。ある日の市場の開始からのある株価が一定のパーセンテージだけ変化したときにアラートを要求する多くのユーザが存在するはずである。収集処理モジュールは、株価情報データをユーザに関連付ける前に、現在のパーセンテージ変動を事前に計算することができ、その結果、多数のユーザにアラートを送るべきか否かを判断する際に処理資源を使用又は重複させる必要がなくなる。
【００２６】
オペレーション１８６で、収集処理モジュールはまた、幾つかのメトリクスに基づいてコンテンツを記憶、サーチ、検索、追跡、及び／又は編成するためにコンテンツを索引付けする。メトリクスの一部は、正規化されたコンテンツ文書の標準データ構造に固有のものであるが、メトリクスは、ステータス情報及びレポート用の索引付け文書にも記憶することができる。メトリクスの実施例は、コンテンツが受信された時間、送信側の識別子、コンテンツが送られた国、コンテンツのタイプ、コンテンツがポーリング要求に関連付けられているかどうか、コンテンツが以前に受信されたコンテンツに関連付けられているか否か、及び同様のものを含むことができる。大量の入力コンテンツへのアクセスを容易にすることに加えて、収集処理モジュールは、オペレーション１８８でメトリクスを使用して、重複コンテンツの削除、軽微な修正を識別するためのコンテンツのフィルタリングなどのハウスキーピング及び最適化を実行することができる。例えば、ニュース記事のスペルエラーを修正して、コンテンツソースから再送信することができる。ユーザが、スペルが修正されただけの同じニュース記事の２つのアラートを望む可能性は低い。最初のニュース記事が既に送信されている場合、次のバージョンは、差の閾値を越えない限り削除することができる。或いは、ニュース記事がアラートとして未だ送信されていなかった場合には、ニュース記事の最初のバージョンは、修正バージョンと置き換えることができ、１つのアラートだけがスケジュール時間にユーザに送られるように待ち行列に並べることができる。メトリクスの索引付け文書及び／又はコンテンツ文書は、一般に、フィード記憶装置に記憶される。各記憶された索引付け文書は、索引付け情報へのアクセスを容易にするための索引付けユニバーサルリソースロケータ（ＵＲＬ）によって識別される。
【００２７】
上記のオペレーション全体を通して、収集処理モジュールは、マッチングエンジンを支援するためにタグ及び／又は他のコードを挿入することができる。例えば、上述のＸＭＬ文書の例に関して、収集処理モジュールは、＜ＡｌｅｒｔｓＤｏｃｕｍｅｎｔ＞タグの各直前のＣＤＡＴＡ子にオプションの「マッチング」属性を付加することができる。マッチングエンジンは、文書にマッチするユーザ識別子を決定するために、「マッチング」タグについて文書をスキャンし、テキスト要素にクエリー式を適用することができる。
【００２８】
ポーラーサブシステム
図４は、スケジュールされたアラートを作成するためのポーリングコンテンツを管理するポーラーアーキテクチャを示す。１８０ａから１８０ｎまでのＮ個のポーラーサーバー、及び一般的にバックアップとして機能する一次ＰＭＳ１８２と二次ＰＭＳ１８４を含む少なくとも２つのポーラー管理サーバー（ＰＭＳ）がある。各ポーラーサーバーは、個人広告、天気予報、及び同様のものなどのアラートタイプに基づいて１つ又はそれ以上の要求されるコンテンツソース１２２ａからの幾つかのポールを扱うために非ブロッキングＩ／Ｏを使用する幾つかのプロセスを実行する。要求されるコンテンツは、収集処理モジュールからポーラー１２０に伝送され、及び／又はＨＴＴＰインターフェースなどを介して別々にアクセスすることができる。各ポーラーサーバーは、９６ＢｅｒｋｅｌｅｙＤＢファイルなどのデータベースファイルに１つのユーザ識別子当たりに同一のアラート情報を記憶する。各ファイルは、１５分−２４ｘ４のようなタイムスロットに相当する。アラート要求がユーザデータベース１１５のユーザのプロファイルに挿入されると、ＱＯＳ値が、プロバイダーコード、アラートタイプ、プレミアムフラグ、及び／又は同様のものに基づいて計算される。スケジュールされたアラートは、対応する時間期間での分配のために配信サーバー１３０に伝達される。
【００２９】
図５は、時間ベースのアラートを作成するための論理を示すフロー図である。オペレーション２００では、ポーラーサーバーは、予め定義された時間期間の経過後にウェイクアップし、一次ＰＭＳにウェイクアップ信号を送る。一次ＰＭＳがダウンした場合には、ウェイクアップ信号は二次ＰＭＳに転送される。ウェイクアップ信号は、ポーラーサーバーが１つ又はそれ以上の予め定義されたアラートタイプに対応するコンテンツに対してポーリングすることができることを示す。ウェイクアップ信号は、ＰＭＳがウェイクアップ信号によって突然オーバーランしないように抑制することができる。ＰＭＳがウェイクアップ信号を受信すると、ＰＭＳは、オペレーション２０２でＰＭＳのメモリ内のポーラーサーバーリストに現在使用可能なポーラーサーバーを加える。オペレーション２０４で、ＰＭＳは、ＰＭＳリスト上の第１ポーラーサーバーに個人広告、交通情報、及び同様のもののような１つ又はそれ以上のコンテンツ項目へアクセスさせるように、ｆｅｔｃｈ＿ａｌｅｒｔｓ＿ｌｉｓｔ要求を送る。オペレーション２０６で、ポーラーサーバーは、フェッチ要求を受け取り、要求されたコンテンツ項目にアクセスして、ＰＭＳにコンテンツ項目を返信する。コンテンツ項目にアクセスするために、ポーラーサーバーは、記憶されたユーザの好みによって定義されたクエリー、及び／又は多数のユーザによって要求される統合クエリーを実行する。クエリーにより結果が見出されなかった場合には、ポーラーサーバーは、任意選択的にクエリーを広げて再度試みることができる。コンテンツ項目は、１５分スロットなどの現在の事前定義された時間に対応する。ポーラーサーバーは、コンテンツ項目をＰＭＳに戻す前にＱＯＳレベルに従ってコンテンツ項目に優先順位を付けることができる。
【００３０】
オペレーション２０８で、ＰＭＳは、多数のポーラーサーバーからテーブルに戻されたコンテンツ項目をフィルター処理する。テーブルは、アラートタイプのＱＯＳレベル、ユーザサービスプラン、及び同様のものに基づく。例えば、コンテンツ項目は、優先順位のレベルに対応するＱＯＳテーブル３、ＱＯＳテーブル２、ＱＯＳテーブル１、及びＱＯＳテーブル０に記憶することができる。各コンテンツ項目はまた、コンテンツ項目がテーブルの１つに加えられるときに割り当てられるタイムスタンプを有することができる。タイムスタンプによって、ＰＭＳは、コンテンツ項目がアラートに処理されずにテーブルに存在した時間の長さを追跡することができる。一般に、閾値の時間の長さを越えてテーブル内に存在するコンテンツ項目は、ロードするのに十分なポーラーサーバーが存在しないことを示している。
【００３１】
予め定義された間隔でコンテンツ項目をポーリングすることに加えて、ポーリングサーバーは、配信されるべき対応するアラートを作成するオペレーションを実行する。従って、オペレーション２１０で、ポーラーサーバーは、作業を求める要求をＰＭＳに送る。ＰＭＳは一般に、ＱＯＳレベルの順序に基づいてコンテンツ項目をテーブルからポーラーサーバーに送る。ポーラーサーバーは、古いクエリー結果を現在のコンテンツ項目と比較するなどの論理オペレーションを実行することができる。例えば、現在のコンテンツ項目が古いクエリー結果とは異なる場合には、ポーラーサーバーは、古いクエリー結果を現在のコンテンツ項目に置き換えることができる。スケジュールされたアラートは長期間配信することができないので、コンテンツは、対応するアラートが最終的に配信される前に何度か更新してもよい。ポーラーサーバーがその作業を終えると、ポーラーサーバーは、コンテンツ項目が処理されアラートが作成されたことを示す通知をＰＭＳに送る。またポーラーサーバーはまた、コンテンツ項目に関するアラートを配信するよう配信サーバーに要求を送り、ポーラーサーバーは、次の作業を要求する。通知を受信すると、ＰＭＳは、オペレーション２１２で、その対応するテーブルからコンテンツ項目を削除し、これは対応するアラートタスクが完了したことを示す。
【００３２】
決定オペレーション２１４で、ＰＭＳは、各ＱＯＣレベルのための全タスクが完了したことを示す、各テーブルから全てのコンテンツ項目が削除されたかどうかを判定する。各テーブルが空である場合には、処理は、オペレーション２００に直接戻り、別のウェイクアップ信号を待ち受ける。各テーブルが空でない場合、ＰＭＳはそのタスクの全てを完了できなかったことになり、ＰＭＳはエラーをログ記録することができる。オペレーション２１６で、残りの未処理コンテンツ項目のいずれもが、次の期間に取得されるあらゆる新しいコンテンツ項目とマージされる。
【００３３】
配信サブシステム
図６は、１人又はそれ以上のユーザにアラートを配信するための例示的な論理を示すフロー図である。上記に簡潔に考察されたように、配信サーバー及びストレージサーバーは、一般に、種々の方法でアラートを配信するために送信サーバーとインターフェースする配信サブシステムを含む。配信サブシステムの全ての構成要素は、ハードウェア構成及び／又はソフトウェア構成のどのような組合せも含むことができる。この自由度により、ハードウェア資源が限られた海外のサイトなどの変化する環境でアラートを配備することができるようになる。
【００３４】
配信サーバーの新規インストール時、或いは、ある時間及び／又は一定の予め定義された時間期間にオフラインにされた後のサービスへの復帰時の初期化オペレーション２２０では、配信サーバーは、別の動作中の配信サーバー及び／又は管理インターフェースのような別のソースから更新されたテンプレートを受け取る。全ての配信サーバーは、配信サーバーセット全体に自動的に配布される同じテンプレートのセットを有する必要がある。
【００３５】
オペレーション２２１で、配信サーバーは、マッチングエンジン及び／又はポーラーから１つ又はそれ以上の要求を受け取り、１人又はそれ以上のユーザに１つ又はそれ以上のメッセージを配信する。一般的には要求は、鍵と各鍵に関連した値とのセットを含む。この鍵は、Ｅメール、インスタント・メッセンジャー、ＳＭＳ、ウェブサーバー、ファイル転送プロトコル（ＦＴＰ）配信、及び同様のものなどの配信方法に対応する配信テンプレートのプレースホルダーに対応する。例えば、要求における＜フルネーム，ジョン  スミス＞の鍵−値のペアを用いて、選択された配信テンプレートの「フルネーム」プレースホルダーを置き換えることになる。配信テンプレートは、パーソナルホームページハイパーテキストプロセッサ（ＰＨＰ）、ＪＡＶＡ（商標）サーバーページ（ＪＳＰ）、ＨＴＭＬ  Ｆｏｒｃｅ２０００（ＨＦ２Ｋ）、及び／又はプロプラエタリテンプレート言語などの公知のテンプレート言語で記述することができる。株価情報、ニュース、案内広告、及び同様のものなどのコンテンツタイプを配信サーバーが使用して、どの配信テンプレートのセットを使用するからを決定することができる。各コンテンツタイプについて、配信テンプレートのセットは、ＨＴＭＬページサーバー、テキストファイル転送、インスタント・メッセンジャー、ＳＭＳ、及び同様のものなどの種々の使用可能な配信機構用に生成することができる。しかしながら、配信サーバーは一般に、処理されるべき特定のアラート文書のどのような知識も持たない。その代わりに、配信サーバーは、コンテンツとユーザＩＤリストを含む文書を調べるだけである。コンテンツ文書とユーザＩＤリストとのこの組合せは、ＰｒｏｃｅｓｓＭａｔｃｈＬｉｓｔと呼ばれる場合がある。上述のように、ユーザＩＤリストは、特定のコンテンツフィードにマッチしたユーザＩＤを含む。コンテンツ文書は、送信されることになるアラートの実際のコンテンツを表す鍵−値ペアのセットを含む。限定ではないが、Ｅメール配信の１つのペア、無線配信の１つのペア、ＩＭの１つのペア、及びウェブ履歴の１つのペアを含む各配信方法の鍵−値ペアのセットが存在することができ、以下でこれを説明する。ＰｒｏｃｅｓｓＭａｔｃｈＬｉｓｔはまた、上記のテーブル１で識別された鍵−値ペアに加えて、一般に的には、配信目的のためのユーザのプロファイルからの以下の情報を含む。
−ユーザデータベースからのユーザＩＤコード
−配信のための国コード
−アラートコンテンツ及び／又は配信方法に関連するパートナーＩＤ
−ユーザカテゴリー
−ＱＯＳレベル
−スケジュールされた配信フラグ対即時の配信フラグ
−プレミアムサービスパッケージ情報
−移動配信などに必要とされる通過課金情報
上記の情報はまた、ロギング／統計目的に使用され、配信経路通過移動サービスプロバイダ、Ｅメールプロバイダ、及び同様のものなどの最終工程での全ての課金行為に対するアラートコンテンツをフォーマットするのに使用される実際のテンプレートを決定する。
【００３６】
ＰｒｏｃｅｓｓＭａｔｃｈＬｉｓｔを受信すると、配信サーバーは、ＰｒｏｃｅｓｓＭａｔｃｈＬｉｓｔで識別された各ユーザ及び／又は配信方法に関連付けられたＱＯＳレベルをオペレーション２２２で決定する。配信サーバーは、インバウンド及びアウトバンドの待ち行列の両方でのＱＯＳレベルに従って要求を処理することになる。マッチサーバーからのメッセージは、一般に、待ち行列が含むユーザの優先順位レベルに従って適切なインバウンド待ち行列で終わる。配信サーバーから発生したアラートは、一般に、Ｅメール、無線ＳＭＳ、ＩＭ、及び／又は同様のものを介してアラートが送られるかどうかにより、適切なアウトバウンド待ち行列で終わる。更に、或いは代替として、配信サーバーは、プレミアムユーザが、例えばユーザデータベースがダウンした場合の特別な配信オプションを有するよう保証することができる。ストレージサーバーは、各ユーザについて既知である、最新の既知のＥメールアドレス、無線装置番号、及び／又は同様のものを記憶する。配信サーバーは、ユーザデータベースから情報を得ることができない場合にはストレージサーバーからその情報を検索する。また配信サーバーは、１つのアラート、１つの無線装置、１人のユーザ、及び／又は同様のものにつきメッセージの制限を実施することができる。配信サーバーは、メッセージ制限情報を記憶／検索するために、ストレージサーバーとインターフェースすることになる。
【００３７】
オペレーション２２４で、配信サーバーは、いずれかの種類のブロック又は再転送が幾人かのユーザに対するアラートの配信状態及び／又は幾つかの配信方法に置かれているかどうかを判定する。例えば、ユーザは、夜間の時間帯など、ユーザがどのようなアラートも受信したくない静かな時間を指示することができる。同様に、ユーザは休暇を取ることができ、ユーザが戻るまでアラートが配信されないように要求する。また配信サーバーは、アラートがユーザが主として好む方法以外の幾つかの配信方法によって転送されるべきかどうかを判断することができる。
【００３８】
決定オペレーション２２６で、配信サーバーは、どのアラートを即時に送るべきか、どれをスケジュールされた時間で送るべきかを判断する。後で配信するようにスケジュールされたアラートは、配信ストレージサーバー上に記憶されることになる。オプションＡ及びオプションＢとして本明細書で言及される、配信ストレージサーバーを実施するには少なくとも２つの方法がある。
【００３９】
オプションＡ：
オペレーション２２８では、スケジュールされたアラートに対して資源管理サーバー（ＲＭＳ）は、どのユーザのアラートがどのストレージサーバー上に記憶されるかを判断する。ユーザへのアラートを記憶する必要があるどのような配信サーバーも、アラートが記憶されることになるＳｔｏｒａｇｅＩｄを位置付けるために、ユーザデータベースのユーザの対応するアラート設定を参照する。このようなＳｔｏｒａｇｅＩｄが存在しない場合には、配信サーバーはＲＭＳに接触してＳｔｏｒａｇｅＩｄを得る。ＲＭＳは、登録されたストレージサーバーの各々の電流負荷／使用量に応じて、ユーザのアラートが記憶されるストレージサーバーが何れであるかを決定することになる。配信サーバーにはサーバーＩＤが戻され、次いで、ユーザデータベースのアラート設定にＳｔｏｒａｇｅＩｄが記憶されることになる。フェイルオーバーの目的で、或いはＲＭＳがダウン又は応答しない場合には、ＲＭＳ  ＡＰＩは、復旧して立ち上がるまでは、最後に発行されたＳｔｏｒａｇｅＩｄをＲＭＳへのあらゆる後続のクエリーに対する結果として確実に通すようにする。
【００４０】
適切なストレージサーバーが識別されると、オペレーション２３０で、配信サーバーはユーザのアラート及び（オプションとして）その配信オプションをそのストレージサーバーに記憶する。記憶されたアラートは、後で配信するために単に待機することだけに加え、最新のコンテンツを確保するために新しいアラートと比較することができる。例えば、スケジュールされた配信時間までの時間期間にわたって複数のマッチが更新から生じる可能性があるが、ユーザは、１日に複数回更新された新しいストーリーについて単一のアラートを受信しなければならない。
【００４１】
配信サーバーと同様に、ストレージサーバーは一般に、どのようなアラートの特定情報の知識も持たないことになる。ストレージサーバーは、高速検索のための共有メモリ（例えば、ｓｈｍ）内に情報を記憶して、可能な限り少ないディスク記憶容量を使用するようにあらゆることを試みることになる。効率化のため、コンテンツフィード情報などの多数のユーザに共通のすべての情報を一度記憶し、ユーザに索引付けすることができる。１つの実施形態では、各サーバーに少なくとも４つの記憶エリアがあり、これは共有メモリとディスク書き込みバックの組合せを介して実施される。
−フィード記憶：鍵−値ペアの各収集は、コンテンツフィードのタイプにマッチしたユーザのセット全体に対して一度記憶することになる。
−ユーザ記憶：スケジュールされたアラートの受信に関心のある各ユーザの入力。このエリアは、アラートの削除／編集を決定した場合にユーザの記録に迅速にアクセスするのに必要とされる。
−時間記憶：スケジュールされたアラートを受信することに関心のある各ユーザは、適切なタイムスロット及び適切なサービス待ち行列の下で記憶された記録を有することになる。
−ウェブ記憶：全ての配信されたアラートは、ウェブフロントエンド上での使用のために、それが作成されたフィードへのポインタを備えた永久記録を有することになる。
【００４２】
フェイルオーバー及びスケジュールされたアラートの高速検索のために、サーバーのいずれもミラーリングすることができる。各サーバーは、モジュールアルゴリズムなどを介してアラートのサブセットに対して作用することができる。スケジュールされたアラートを配信するなどの各動作では、サーバーは、１つ又はそれ以上の同位ミラーにその動作を複製する。ハートビート機構は一般に、スケジュールされた配信を行うプロセス間に設定され、サーバーがダウンし、又は何らかの理由でプロセスが障害を起こした場合に、ミラーサーバーの残りのプロセスが作業を続行できるようにする。これは、フェイルオーバーのためだけでなく、使用可能な処理能力を倍増させる（例えば、二倍、三倍など）ためにもミラーサーバーが利用される。
【００４３】
オプションＢ：
配信ストレージサーバーの他の実施形態では、関係データベースが、アラートマッチング結果に対するフィードコンテンツを記憶する。概念上、フィードコンテンツ、ユーザアラートマッチ、及び配信スケジュール時間を関連付けるために、３つのタイプのテーブルが使用される。従って、テーブルの３つのタイプは、フィードテーブル、アラートマッチテーブル、及びタイムスロットテーブルと呼ばれる。フィードテーブルは、ストレージサーバーによって受信された各コンテンツフィードを含む。各コンテンツフィードは、ＦｅｅｄＩＤによって一意的に識別される。フィードテーブルデータ構造の例をテーブル２に示す。
【００４４】
テーブル２：フィードテーブルデータ構造の例
2007516511.tif 000004
【００４５】
アラートマッチテーブルは、アラート毎のユーザマッチを記憶する。ユーザのアラートは、固有のＡｌｅｒｔＩＤによって参照される。各ＡｌｅｒｔＩＤには、０又はそれ以上のコンテンツフィードが存在できる。１つのＡｌｅｒｔＩＤについての幾つかのマッチは、各々が異なるＦｅｅｄＩＤを有するアラートマッチテーブルの複数の行で表されることになる。各タプル＜ＡｌｅｒｔＩＤ、ＦｅｅｄＩＤ＞は、ＡｌｅｒｔＭａｔｃｈｅテーブルにおいて固有であり、ユーザのアラートをその対応するコンテンツフィードに結び付ける。ＡｌｅｒｔＭａｔｃｈｅテーブルデータ構造の例を図３に示す。
【００４６】
テーブル３：アラートマッチテーブルデータ構造の例
2007516511.tif 000005
【００４７】
タイムスロットテーブルは、配信タイムスロットに関連付けられた全ユーザのＡｌｅｒｔＩＤを記憶する。その日の間の各１５分配信タイムスロットは、１つのＴｉｍｅＳｌｏｔテーブルに対応する。例えば、テーブルＴｉｍｅＳｌｏｔ＿９＿４５は、午前９：４５にセットされた配信選択を有する全てのＡｌｅｒｔＩＤを含む。各配信スロットの始めに、幾つかのプロセスがＴｉｍｅＳｌｏｔテーブルのＡｌｅｒｔＩＤの処理を開始する。これらのプロセスを統合するために、ＴｉｍｅＳｌｏｔテーブルの「ＣｌａｉｍｅＢｙ」フィールドにより、各プロセスでは別のプロセスが特定のＡｌｅｒｔＩＤ上で既に動作しているかどうかをチェックできる。ＣｌａｉｍｅＢｙフィールドが空の場合、このＡｌｅｒｔＩＤは、次の使用可能なプロセスが処理するのに使用可能である。ＴｉｍｅＳｌｏｔテーブルデータ構造の例をテーブル４に示す。
【００４８】
テーブル４：タイムスロットテーブルデータ構造の例
2007516511.tif 000006
【００４９】
オペレーション２３２で、アラートが記憶領域にある間、配信ストレージサーバーはまた、ユーザデータベースから更新データを得ることができる。この１つの理由は、ユーザがアラートを削除するとき、或いはユーザがスケジュールされたアラートの配信時間を変更するよう決定したときは常にユーザ入力を消去するためである。ストレージサーバーは、１時間毎などの予め定義された配信時間において、その時間期間に配信されることになる記憶されたアラートにアクセスし、即時配信用の記憶されたアラートにマークを付ける。次にストレージサーバーは、オペレーション２３４で配信サーバーにマーク付けされたアラートを送る。オペレーション２３６で、配信サーバーはテンプレートを用い、該テンプレートが事前に用いられなかった場合には事前に選択された配信方法に従って出力アラートをフォーマットする。次に配信サーバーは、即時の配信アラートを、Ｅメール、インスタント・メッセージ、ＳＭＳを介した配信のための送信サーバー、及び／又はいずれか配信方法が各アラートに関連付けられるものに伝達する。
【００５０】
アラートが配信サーバーによって送られると、「ａｄｄ  Ｔｏ  Ｈｉｓｔｏｒｙ」要求がオペレーション２３８でストレージサーバーに送られ、アラートが送られたことに関するユーザ履歴を更新する。また「ａｄｄ  Ｔｏ  Ｈｉｓｔｏｒｙ」要求は鍵−値ペアのセットを含み、種々のアラートタイプが情報の種々のタイプを記憶できるようにする。この場合もやはり配信サーバーは、一般に、「ａｄｄ  Ｔｏ  Ｈｉｓｔｏｒｙ」要求を送っている特定のアラートの知識を持たない。記憶する必要のある鍵−値ペアのセットは、マッチング側によって定義される。配信サーバーへの全ての要求は、特定のアラートのために記憶する必要のある鍵名称の何らかのセットを伴う必要がある。
【００５１】
また履歴情報は、ストレージサーバーから他のサービスに同時配信することができる。例えば、履歴結果は、ストレージサーバーのミラーセットから直接、又は履歴結果を取り扱うストレージサーバーの別のセットから、フロントエンドウェブページ及び／又は他のウェブポータルページに提供することができる。共有メモリは、可能な限り多くのユーザの履歴結果（「ａｄｄ  Ｔｏ  Ｈｉｓｔｏｒｙ」要求が配信サーバーから入って来たときにライブで更新される）を保持することができ、同時に履歴結果は永久記憶のためのディスクに書き込むことができる。ユーザの上位Ｎ番目までの履歴結果が共有メモリに存在しない場合には、履歴結果は、ユーザの永久記憶ファイルからアクセスされる。上述のように、結果は、鍵−値ペアで戻され、受信側にとって適切な方法で結果をフォーマットするように受信側にアップされる。例えば、実際のニュースアラートでは、ＵＲＬとユーザが受信した最新の３つのニュースアラートの要約と共にユーザに送ることができるが、履歴ページではＵＲＬを表すことだけを必要とすることができる。独立したフォーマッティングにより、新しいアラートタイプを履歴ファイルに記憶されたものを変更することなく加えることができ、これによって履歴報告の新しい要件を新しいアラートタイプに適応させることができる。一般に、鍵−値法は、将来のニーズに適合することになる。
【００５２】
突発故障、破損問題、又はサーバーをアップグレードすることが必要な場合でも情報が失われることがないように幾つかの手段が用いられる。上記に示されたように、各ストレージサーバーは、少なくとも片方のサーバーによってミラーリングされ、その結果、ミラーがトラフィックを扱うときにサーバーを取り外せるようになる。共有メモリ及び複製ファイルのバックアップを用いることができる。例えば、毎日少なくとも二度の共有メモリのバックアップが用いられると共に、少なくとも２４時間分の入力複製ボリュームファイルにより、可能な限り迅速な共有メモリの復元でサーバーをオンラインに戻すことができる。
【００５３】
他の回復機能により、配信要求の処理の完了が保証される。例えば、配信サーバーは、対応するコンテンツ文書に関連した全てのユーザＩＤが処理された場合のみ、「完了」としてアラートにマーク付けする。モニター及び／又は他のユーティリティは、送信されなかったアラートの状態をモニターし、必要であればアラート処理を繰り返すことができる。この回復機能はまた、送信サーバーにも適用できる。
【００５４】
ミラーセットは、回復を保証することに加えてスケーラビリティにも使用できる。マッチサーバーからのトラフィック増加を処理するために、どのような数の追加配信サーバーをいつでも付加することができる。逆に、どのような配信サーバーも、どのようなメンテナンス理由のためにいつでもオフラインにすることができる。残りの動作中のサーバーは、マッチサーバーからの入力トラフィックを処理することができる。
【００５５】
ユーザ登録の増加に対処するために、どのような数のストレージサーバーも水平に付加することができ、この場合、より多くの総数のミラーセットが付加される。スケジュールされたアラートアクティビティの増大に対処するために、ストレージサーバーを垂直に付加することもでき、この場合、１つのセットにつきより多くのミラーサーバーが付加される。
【００５６】
サーバー環境の実施例
図７は、本発明の１つの実施形態による例示的なサーバー３００の機能ブロック図を示す。サーバー３００は、マッチングサーバー、フィードストレージサーバー、ポーラー、配信サーバー、ストレージサーバー、送信サーバーなどの上述のサーバーのいずれか１つ又はそれ以上を含むことができる。各クライアント装置は、同様に構成することができる。サーバー３００は、構成要素を図示のものよりも多く含むことができる。しかしながら図示された構成要素は、本発明を実施するための例示的な実施形態を開示するには十分である。
【００５７】
サーバー３００は、処理ユニット３１２、ビデオディスプレイアダプタ３１４、及び大容量メモリを含み、これら全てはバス３２２を介して互いに通信する。大容量メモリは一般に、ＲＡＭ３１６、ＲＯＭ３３２、及び光ドライブ３２６、ハードディスクドライブ３２８、テープドライブ、及び／又はフロッピーディスクドライブなどの１つ又はそれ以上の永久大容量記憶装置を含む。大容量メモリは、サーバー３００のオペレーションを制御するためのオペレーティングシステム３２０を記憶する。どのような汎用オペレーティングシステムを用いてもよい。サーバー３００の低レベルのオペレーションを制御するために、基本入出力システム（「ＢＩＯＳ」）３１８が備えられる。図６に示されるように、サーバー３００は、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を含む種々の通信プロトコルに使用するよう構成されたネットワークインターフェースユニット３１０を介して、インターネット、又は図１のネットワーク１６０などの他の通信ネットワークと通信することができる。ネットワークインターフェースユニット３１０は、送受信器、送受信装置、ネットワークインターフェースカード（ＮＩＣ）、及び同様のものとして既知であることもある。またサーバー３００は、マウス、キーボード、スキャナー、又は図１に示されていない他の入力装置などの外部装置と通信するための入出力インターフェース３２４を含む。
【００５８】
上述のような大容量メモリは、別のタイプのコンピュータ可読媒体、すなわちコンピュータ記憶媒体を示している。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータなどの情報を記憶するためのどのような方法又は技術でも実施される、揮発性、不揮発性、取外し可能、及び取り外し不能の媒体を含むことができる。コンピュータ記憶媒体の実施例には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又は他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、又は他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、又は他の磁気記憶装置、或いは要求された情報を記憶するのに使用可能であり、コンピュータデバイスによってアクセス可能な何らかの他の媒体が含まれる。
【００５９】
大容量メモリはまた、プログラムコード及びデータを記憶する。１つ又はそれ以上のアプリケーション３５０が、大容量メモリにロードされ、オペレーションシステム３２０を走らせる。アプリケーションプログラムの実施例には、データベースプログラム、スケジューラ、トランスコーダ、Ｅメールプログラム、カレンダー、ウェブサービス、ワードプロセッシングプログラム、表計算プログラムなどが含まれる。大容量記憶装置は更に、収集処理モジュール１７２、管理インターフェース１７４、マッチングエンジン１１０ａ、ポーラー１２０ａ、配信インターフェース１３０ａ、及び同様のものなどのアプリケーションを含むことができる。
【００６０】
上記の明細書、実施例、及びデータは、本発明の構成の製造及び使用を完全に説明する。本発明の多くの実施形態は本発明の精神及び範囲から逸脱することなく実施できるので、本発明は添付の請求項に属する。
【図面の簡単な説明】
【００６１】
【図１】本発明による例示的なアラート・アーキテクチャを示す。
【図２】図１に関して説明されたアーキテクチャに対応する機能要素間の関係及びデータフローを示す機能ブロック図である。
【図３】収集されたコンテンツを処理するための例示的な論理を示すフロー図である。
【図４】スケジュールされたアラートを生成するためにポーリングされたコンテンツを管理するポーラーアーキテクチャを示す。
【図５】時間ベースのアラートを作成するための論理を示すフロー図である。
【図６】１人又はそれ以上のユーザにアラートを配信するための例示的な論理を示すフロー図である。
【図７】本発明の１つの実施形態に従う例示的なサーバーの機能ブロック図を示す。
【符号の説明】
【００６２】
１０３  フィード収集サーバー
１０４  ストレージサーバー
１１０  マッチングサーバー
１２０  ポーラー
１３０  配信サーバー
１５８  ミラーインターフェース
【図１】
2007516511.tif 000007
【図２】
2007516511.tif 000008
【図３】
2007516511.tif 000009
【図４】
2007516511.tif 000010
【図５】
2007516511.tif 000011
【図６】
2007516511.tif 000012
【図７】
2007516511.tif 000013
【国際調査報告】
2007516511.tif 000014