JP2007526537A - 持続的にイベントデータを記憶および提供するためのサーバアーキテクチャおよび方法 - Google Patents

Abstract

ウェブサイトシステム（３０）は、ウェブサイトユーザのブラウジングセッション中に発生するイベントを反映するイベントデータを持続的に記憶し、他のアプリケーションおよびサービス（３８）が当該データをリアルタイムに利用できるようにするイベント履歴サーバシステム（３２）を備える。サーバシステム（３２）は、例えば、全ての承認されたユーザの全てのマウスクリックに関する情報を記録するために用いられてもよく、インプレッションおよびマウスオーバーイベント等の別のタイプのイベントを記録するためにも用いることもできる。特定ユーザのイベントデータは、イベントタイプ、イベント発生時刻および別の様々な基準に基づいてサーバシステム（３２）から検索が可能である。一実施形態において、サーバシステム（３２）は、セッションＩＤごとにイベントデータをキャッシュするキャッシュ層（４０）を備え、かつ、前記イベントデータをユーザＩＤごとに持続的に記憶する持続的記憶層（４４）を備える。また、上記記憶されたイベントデータを用いて実現されうる様々なアプリケーションの特徴も開示される。

Description

本発明は、ウェブサイトユーザのブラウズセッション中に発生するイベントを反映するイベントデータの取得、持続的な記憶、および供給を行なうサーバアーキテクチャに関する。また、本発明は、イベント履歴データを利用したパーソナライゼーション技術にも関する。

一般に、ウェブサイトシステムは、ユーザのブラウジングあるいは「クリックストリーム」に関する情報を取得および記憶するための１つまたはそれ以上の機構を備えている。取得されたクリックストリームデータは、承認されたユーザのウェブページをパーソナライズするために一般に用いられる。しかし、典型的には、取得されたクリックストリームデータは、各ユーザのブラウズ履歴に関する非常に限定された情報を提供するものであるか、パーソナライゼーションに限定して用いられるフォーマットで取得されているかの何れかである。

例えば、ウェブサイトの中には、電子カタログのブラウズ中に各ユーザによって行なわれた項目の選択、ブラウズノードの選択、および探索クエリの提出のそれぞれについてのリアルタイム記録を保持しているものもある。このようなブラウズ履歴は、例えば、パーソナライズした項目の提案を生成したり、以前にアクセスしたコンテンツにユーザが戻るための支援を行なうナビゲーション履歴を表示するために有用である。しかし、典型的には、これらのタイプの記録は、新たなタイプのリアルタイム型パーソナライゼーション・アプリケーションを柔軟に構築するために望ましいとされるレベルの詳細および構造を欠いている。

また、一部のシステムは、ウェブサイトが受信した全てのＨＴＴＰ要求の時系列の記録を含むウェブサーバアクセスログ（「ウェブログ」）を、関連したタイムスタンプおよびユーザＩＤ情報と共に保持している。動的に生成されるウェブページの場合、ウェブクエリログは、当該ページ内でユーザに提示される項目のＩＤ（一般に、項目の「インプレッション」と呼ばれる）も記録している場合がある。典型的に、これらのログは、より詳細なブラウズ履歴情報を典型的に含んでいるものの、ユーザのクリックストリーム履歴をリアルタイムで抽出および分析するのに十分には適さないフォーマットで保持されている。ウェブログは、様々なパーソナライゼーション機能に有用な情報を得るためにマイニングが可能であるが、大規模なウェブログのマイニングを行なうタスクには、多くの時間または日数を要する可能性があり、場合によっては、抽出されたデータを、それが利用できる時点では陳腐なものにしてしまう。さらに、ウェブログに含まれる詳細情報の多くは、マイニング処理中に無視され、したがってパーソナライゼーションの目的においては実質的に失われる。

本発明は、ウェブサイトユーザのブラウズセッション中に発生するイベントを記述したイベントデータを持続的に記憶するイベント履歴サーバシステムを提供する。イベントデータは、対応するユーザのＩＤと関連付けて記憶され、イベントデータを用いて特定ユーザ用にウェブページをパーソナライズすることができるウェブサイトアプリケーションがリアルタイムで利用できるようになっている。一実施形態において、イベント履歴サーバは、ウェブサイトの全ユーザの実質的に全ての選択イベント（例えば、マウスクリック）を記述したイベントデータを記録する。イベント履歴サーバは、インプレッション（すなわち、動的に生成されたウェブページ上でユーザに提示された項目）やマウスオーバーイベント等の別のタイプのブラウジングイベントを記述したイベントデータも記録することができる。

各記録イベントに関して記憶されたイベントデータは、イベントオブジェクトとしてデータベース内に記憶されることが好ましい。各イベントオブジェクトは、例えば、一般的なイベントタイプの識別子（例えば、マウスクリック、インプレッション等）および付随する表示要素のタイプ（例えば、カタログ項目、ブラウズノード、探索結果項目等）、イベント値（例えば、選択されたテキスト）、イベントの発生日時を示すタイムスタンプおよび関連したコンテキスト情報を含んでいてもよい。イベント履歴サーバのクエリインタフェイスは、パーソナライゼーションアプリケーション等のアプリケーションが、一般的なイベントタイプ、付随する表示要素のタイプ、発生時刻および場合によってはその他の基準によって特定ユーザのイベントデータを検索することを可能にする。クエリインタフェイスは、「ユーザＸは以前にＵＲＬ Ｙにアクセスしたか？」および「ユーザＸがＵＲＬ Ｙにアクセスしたのはいつか？」というセマンティクスを持つクエリもサポートすることが好ましい。より一般的には、クエリインタフェイスは、「タイプＴおよび値ＶのイベントがユーザＸのイベント履歴内に存在するか？」というセマンティクスを持つクエリをサポートすることができる。

一実施形態において、イベント履歴サーバシステムは、イベントデータを、対応するブラウズセッションｌＤと関連付けてキャッシュするキャッシュ層を備え、上記イベントデータを、対応するユーザＩＤと関連付けて持続的に記憶する持続的記憶層を備える。キャッシュ層は、各キャッシュ層サーバがそれぞれ異なるユーザのセットのイベントデータをキャッシュするように、ブラウズセッションＩＤごとにパーティションに分割された複数の物理キャッシュ層サーバを備えることが好ましい。持続的記憶層は、２つまたはそれ以上の物理記憶層サーバを備え、当該サーバのいずれもがイベントデータに対する所与のクエリ／要求に応答ができるよう、持続的に記憶されたイベントデータの完全なセットを、それぞれが記憶することが好ましい。

好ましい実施形態においては、記録可能なブラウジングイベントが発生すると、イベント報告コンポーネントは、その特定のブラウジングセッションＩＤに関連したキャッシュ層サーバに更新を送信し、同サーバは、そこに指定されたイベントデータにより各自のキャッシュを更新する。更新は、また、イベントデータが持続的に記憶されるように、キャッシュ層サーバから記憶層に渡される。イベント履歴サーバシステムのクライアントからのクエリは、まずキャッシュ層サーバによって処理され、同サーバは、該当するイベントデータがキャッシュされていない場合には、当該クエリを持続的記憶層に渡す。

一実施形態において、イベント履歴サーバシステムは、一般的なインターネット探索機能を提供するウェブ探索アプリケーションのユーザによって行なわれた動作を記述したイベントデータを記憶する。このイベントデータは、ユーザによって提出された探索クエリおよび探索結果ページからユーザによって選択された探索結果項目（ＵＲＬ）を含むことが好ましい。記録されたイベントデータは、ユーザ用に探索結果ページをパーソナライズするために用いられることが好ましい。例えば、一実施形態においては、ユーザが当該ユーザによって以前にアクセスされたＵＲＬ（探索結果項目）を返信する探索を行なうと、探索結果ページにコメントが付され、このＵＲＬが以前にアクセスされたことが示され、かつ当該アクセスの日付が示される。

本発明の一側面によると、イベント履歴サーバは、特定ユーザによってアクセスされたＵＲＬを反映するユーザ特有のブルーム（Ｂｌｏｏｍ）フィルタを生成し、このブルームフィルタを用いて、特定ユーザが以前に特定のＵＲＬにアクセスしたかどうかを効率的に評価する。ブルームフィルタは、項目インプレッション等の別のタイプのイベントが特定ユーザのイベント履歴内に存在するか否かを効率的に評価するために生成および使用されてもよい。

また、ユーザが各自のイベント履歴を閲覧し、編成し、かつこれにコメントを付けることを可能にするアプリケーションの特徴も開示される。

この概要および以下の詳細な説明は、いずれも本発明を定めるものではない。本発明は請求項によって定められる。

以下、イベント履歴サーバシステムを備えるウェブサイトシステムの好適な実施形態について図面を参照しながら説明する。理解できるように、開示されるシステム内で実施される本発明の特徴の多くは、残りの特徴がなくとも実現または使用することができる。以下の記載においては、説明の目的で多数のインプリメンテーションの詳細を記載するが、これは本発明を説明するためのものであって、限定するものではない。

Ｉ．概要
図１は、本発明の一実施形態に係るイベント履歴サーバシステム３２（「イベント履歴サーバ」）を備えるウェブサイトシステム３０を示す。イベント履歴サーバ３２は、ユーザのブラウジングセッション中に発生するイベントを示すイベントデータを持続的に記録し、かつこれに対するリアルタイムアクセスを提供するためのサービスを提供する。イベントデータは、ユーザのクリックストリームを記述していることが好ましく、マウスオーバーやインプレッションイベント等の別のタイプのイベントを記述していてもよい。以下に説明するように、イベント履歴サーバ３２は、アプリケーションおよびサービスが特定ユーザのイベントデータを柔軟に検索し、またそれに関する情報を要求することを可能にするＡＰＩ（アプリケーションプログラムインタフェイス）も提供している。

図１に示すように、ウェブサイトシステム３０は、ユーザコンピュータ３６および／または別の種類の装置（ＰＤＡ、携帯電話等）から要求を受信および処理する１つ以上のウェブサーバ装置３４を備えている。ウェブサーバ装置３４上で実行される処理は、ウェブサービスとして実現されうる各種ウェブアプリケーション３８と通信を行なう。これらのアプリケーション３８は、ウェブサーバ装置３４上で実行することができるが、より典型的には、別々のサーバ装置（図示せず）上で実行される。典型的に、所与のシステム内に設けられるウェブアプリケーションの種類は、そのシステムの性質および目的によって決まる。例えば、インターネット探索エンジンサイトは、ユーザがウェブページのインデックスのキーワード探索を行なうことを可能にするための１つ以上の探索アプリケーション３８を備えてもよい。電子商取引サイトは、電子カタログの探索、ブラウザツリーによる電子カタログのブラウジング、パーソナライズされた提案の生成、注文の発注、個人アカウントデータの管理といったタスクを実行するためのウェブアプリケーションを備えうる。本説明の目的のために、ウェブアプリケーション３８の少なくとも一部は、イベント履歴サーバ３２に記憶されたユーザ特有のイベントデータに基づいてパーソナライズされたウェブページコンテンツを供給することを前提としてもよい。

図１に示すように、各ウェブサーバ装置３４は、オンラインユーザによって実行される動作に応じてイベント履歴サーバ３２に更新を送るイベント報告コンポーネント３５を実行することが好ましい。（所与のユーザは、個人である必要はなく、例えば、ユーザコンピュータ３６またはユーザアカウントを共有する個人の集合であってもよい）。このような更新は、それぞれ、ユーザのブラウジングセッション中に発生した、マウスクリック、探索クエリの提出、あるいはインプレッション等の特定のイベントを記述したイベントデータを含む、あるいは指定する。イベント報告コンポーネント３５は、イベント履歴サーバ３２に対する呼び出しを行なうためのＡＰＩ（アプリケーションプログラムインタフェイス）のセットを含んでもよく、また、イベント／更新が生成される対象である動作のタイプを指定する設定パラメータを含んでもよい。ＡＰＩは、アプリケーション３８がイベント履歴サーバ３２にクエリを提出することを可能にするためにも設けられている。下記のセクションＶに記載するように、ブラウジングイベントは、ユーザコンピュータ３６上で実行されるブラウザベースのイベント報告コンポーネント（図７）によって、イベント履歴サーバ３２に付加的にまたは二者択一的に報告されてもよい。

特定のイベントに関してイベント履歴サーバ３２により記憶された上記データセットは、「イベントオブジェクト」として記憶されることが好ましい。一実施形態において、例えば、イベント履歴サーバ３２は、ウェブサイトシステム３０の全ての承認されたユーザの実質的に全ての選択動作すなわち「マウスクリック」を記述したイベントオブジェクトを持続的に記憶する。この情報は、例えば、アクセスされたＵＲＬ、アクセス時刻／日、および関連したコンテキスト情報を含んでもよい。イベント履歴サーバは、動的に生成されたウェブページ内でユーザに提示された特定の項目を反映したインプレッションイベントも記録することができる。例えば、データベースから選択されたパーソナライズされた項目リストを含む動的に生成されたウェブページをユーザが閲覧する場合、イベント履歴サーバは、当該項目のそれぞれに関してイベントオブジェクトを記憶してもよいし、あるいは、項目リストを含む１つのイベントオブジェクトを記憶してもよい。記録されうるイベントのタイプ、およびそのようなイベントに関して記録することができるイベントデータのタイプの別の例を以下に示す。イベントオブジェクトは、発生時刻、一般的なイベントタイプ（例えば、マウスクリック対インプレッション）、付随する表示要素のタイプ（例えば、カタログ項目、ブラウズノードやウェブ探索結果ＵＲＬ）、ユーザＩＤやその他のオブジェクト特性に基づいた検索を可能にするために、イベント履歴サーバ３２内において記憶および索引付けされることが好ましい。

イベント履歴サーバ３２によって取得されたイベントデータは、ウェブサイトシステム３０がホストとなっている特定のウェブサイトまたはウェブサイトのセットをユーザがブラウジング中に、ユーザによって実行された動作を反映している。一部の実施形態においては、このような取得データは、外部の独立したウェブサイトをユーザがブラウジング中にユーザによって実行された動作をも反映していてもよい。例えば、全てのＵＲＬアクセス（および場合によっては別のタイプのイベント）をイベント履歴サーバ３２に対して報告するブラウザツールバーなどのブラウザプラグインを各自のコンピュータ３６にダウンロードすることを、ユーザに対して許可または要求してもよい（以下に記載する図７を参照）。

ウェブアプリケーション３８の一部または全てがイベント履歴サーバ３２のクライアントとして機能することが好ましい。図１に示すように、ウェブアプリケーションは、主として、イベントクエリをイベント履歴サーバ３２に送信することによりイベント履歴サーバ３２と対話を行い、特定のイベントの情報を検索または取得する。これらのクエリは、「ユーザＹに関して、最新のものからＮ個、過去のタイプＴのイベントを再び呼び出せ。」または「ユーザＹに関して今後のＮ個のタイプＴのイベントを再び呼び出せ。」等の固定サイズのイベントデータブロックに対する要求を含むことが好ましい。例えば、ウェブアプリケーション３８は、特定ユーザによって提出された過去の５０個の探索クエリに関してイベントオブジェクトを要求してもよく、あるいは、特定ユーザによって閲覧された過去の５０個のブラウズノードに関してイベントオブジェクトを要求してもよい。検索されたイベントオブジェクトは、ウェブアプリケーション３８によって、例えばパーソナライズされた項目提案の生成やナビゲーションを容易にするためのブラウズ履歴データの表示等のあらゆる適切な目的に用いることができる。

イベント履歴サーバ３２は、「タイプＴかつ値ＶのイベントがユーザＹのイベント履歴内に存在するか？」および「タイプＴかつ値ＶのイベントがユーザＹのイベント履歴内で発生したのはいつか？」という意味形式のクエリもサポートすることが好ましい。例えば、ウェブアプリケーションは、イベント履歴サーバ３２に照会を行い、特定ユーザが特定のＵＲＬに以前にアクセスしたかどうか、かつ、もしアクセスした場合にはいつアクセスしたのかを明らかにすることができる。以下に説明するように、このような特徴を持つ１つのアプリケーションは、特定ユーザによってすでにアクセスされた探索結果ＵＲＬを強調表示し、かつ、閲覧されたＵＲＬが最後にいつアクセスされたかを表示するパーソナライズされたウェブ探索結果ページ（図３を参照）を生成することを含む。イベント履歴サーバ３２によってサポートされうるクエリのタイプおよび取得されたイベントデータを利用したアプリケーションの別の例を以下に示す。

図１においてイベントクエリはウェブアプリケーション３８から出ているように示されているが、イベント履歴サーバ３２は、別のタイプのコンポーネントからのイベントクエリ（および場合によっては更新）に応答してもよい。例えば、データマイニングアプリケーションが、ウェブサイトのブラウジングを向上させる目的でユーザのイベントデータの検索および分析を行い、セキュリティーアプリケーションまたはセキュリティー管理者が、クリックストリームデータを検索してセキュリティー侵害の分析を行なってもよい。更新および／またはクエリをイベント履歴サーバ３２に送信するアプリケーションコンポーネントおよびサービスは、本明細書においては「クライアント」と呼ばれ、図１においてはクライアント層３９の一部として示されている。

図１に示すように、イベント履歴サーバ３２は、キャッシュ層４０および持続的記憶層４４の２層で構成される。キャッシュ層４０は、１組の物理キャッシュ層サーバ４２で構成され、これらはそれぞれ、クライアントからの更新およびクエリに対して応答するためのサービスレベルのソフトウェア７０（図２）を実行する。各キャッシュ層サーバ４２は、イベントデータをイベントオブジェクトの形式で一時的に記憶するキャッシュ４３を備える。キャッシュ４３は、不揮発性のディスク記憶装置、ランダムアクセスメモリ、またはこれらの組み合わせを用いて実現することができる。以下に説明するように、キャッシュ４３は、一定のタイプのクエリに対して応答するためのユーザ特有のブルームフィルタをも記憶していてもよい。クライアント層３９、キャッシュ層４０および持続的記憶層との間の通信は、ローカルエリアネットワークを介して行なわれることが好ましい。

キャッシュ層サーバ４２は、ブラウズセッションＩＤごとにパーティションに分割されていることが好ましく、これは、このようなサーバ４２はそれぞれ、各自の範囲またはグループのセッションＩＤに関連付けられたイベントデータ（イベントオブジェクト）のみを記憶することを意味する。したがって、例えば、ユーザが新たなブラウジングセッションを開始すると、そのセッションは、当該ブラウジングセッションに対応する全ての更新およびイベントクエリをそれ以降処理する特定のキャッシュ層サーバ４２に割り当てられる。１つのインプリメンテーションにおいては、合計９つのデュアルＣＰＵキャッシュ層サーバ４２がキャッシュ層４０内に設けられ、これらのうちの１つがホットスペアとして用いられる。キャッシュ４３は、ステートレスなライトスルーキャッシュとして用いられることが好ましく、これにより、装置４２の付加、取り外し、バックアップおよび再起動が容易となる。

以下に説明するように、キャッシュ層４０は、クライアント層３９と持続的記憶層４４との間の中継部として実質的に機能し、これによりシステムがより高いスループットレベルで動作することが可能となっている。キャッシュ層４０の使用は好ましいが、イベント履歴サーバ３２は、キャッシュ層なしで実現されてもよい。さらに、キャッシュ層４０が設けられている場合、キャッシュを行うことが有益でない場合にはこれをバイパスしてもよく、その結果、要求の一部は持続的記憶層４４によって直接処理される。

さらに図１を参照すると、持続的記憶層４４は、１組の物理記憶層サーバ４６で構成されている。図示される実施形態においては、２つの記憶層サーバ４６が設けられているが、これより多くあるいは少なく用いてもよい。各記憶層サーバ４６は、システム３２によって持続的に記憶されたイベントデータの完全なコピーの保持を担っている。したがって、記憶層サーバ４６は、２つ以上設けられている場合には、互いのミラーとなっている。記憶層サーバ４６はミラーリングされているため、１つの記憶層サーバ４６がダウンしたり取り外されたりしても、イベント履歴サービスの全体的な機能に影響を及ぼすことはない。

各記憶層サーバ４６は、例えば、数テラバイトのディスクドライブ記憶装置を備えていてもよい。１日につき約１００Ｍのイベントが記録され、かつ各記録イベントについて平均３０バイトのデータが記憶される場合、各記憶層サーバ４６は、１日につき約３ＧＢ（ギガバイト）、すなわち１年につき約１テラバイトのイベントデータを記憶することになる。このような使用量が想定される場合、各記憶層サーバ４６は、数年分のイベントデータを記憶および処理する能力を有する。記憶層サーバ４６の記憶容量一杯になった場合は、記憶層に新たなディスクドライブを追加してその容量を増加させ、かつ／または古いイベントデータを削除あるいはアーカイブしてもよい。

以下に説明し、図２に示すように、各記憶層サーバ４６は、イベントデータを記憶および管理するためのデータベースソフトウェア６２を実行し、かつ、キャッシュ層４０から受信し、更新およびクエリを処理するためのサービスレベルコード６０を実行する。記憶層サーバ４６は、低コストの汎用ハードウェアを用いて実現してもよく、バークレー（Ｂｅｒｋｅｌｅｙ）データベースまたは別の種類の比較的低コストのデータベースを用いてイベントデータを記憶してもよい。

イベント履歴サーバ３２は、更新に対して概ね以下のように応答する。ウェブサーバ装置３４によって更新がキャッシュ層４０に送信されると、対応するセッションＩＤに割り当てられたキャッシュ層サーバ４２は、その更新によって指定されたイベントオブジェクトを含めるよう各自のキャッシュ４３を更新する。このイベントが承認されたユーザに対するものである場合、キャッシュ層サーバ４２は、この更新を各記憶層サーバ４６に対しても（好ましくはパブリッシュ／サブスクライブ（ｐｕｂｌｉｓｈ−ｓｕｂｓｃｒｉｂｅ）プロトコルを用いて）送信し、当該サーバ４６は、それぞれ、関連するイベントオブジェクトを、対応するユーザＩＤと関連付けて自らの持続的記憶装置６４に記憶する。各キャッシュ層サーバ４２は、記憶層サーバ４６に送信するための複数のイベント／更新を集めることが好ましく、その結果、これらのサーバ４６はキャッシュ層からの更新をバッチ単位で受信する。イベントオブジェクトは、対応するセッションＩＤおよび／またはユーザＩＤと関連付けてキャッシュ４３に記憶される。

更新において指定されたイベントデータが未承認のユーザに対するものである場合、キャッシュ層サーバ４２は、このイベントオブジェクトを自らのキャッシュ４３に（対応するセッションＩＤと関連付けて）記憶するが、この更新を持続的記憶層４４に送信しない。ユーザは、例えば、ユーザが（１）ウェブサイトにとって新規である場合、（２）特定のコンピュータ３６からウェブサイトに初めてアクセス中であって、かつログインしていない場合、または（３）クッキーを遮断するように構成されたコンピュータ３６からウェブサイトにアクセス中であって、かつログインしていない場合には未承認であってもよい。このように、セッションを通じて、キャッシュ層は未承認ユーザに関するイベントデータを収集する。

ブラウジングセッション中に、未承認ユーザがログインを行うか、アカウントを作成するか、あるいは承認される場合、関連したキャッシュ層サーバ４２は、当該ユーザに関して収集されたイベントデータを、そのユーザＩＤと関連付ける。また、キャッシュ層サーバ４２は、一連の更新を記憶層サーバ４４に送信し、この収集されたイベントデータをユーザＩＤと関連付けて持続的に記憶する。このようにして、システムはユーザのイベントを、当該イベントの発生時点でユーザが承認されない場合であっても持続的に取得することを可能にする。さらに、ユーザが未承認である期間中、イベント履歴サーバ３２のクライアントは、未承認ユーザのキャッシュされたイベントデータに関する情報をユーザのセッションＩＤに基づいて検索および要求することができる。

イベント履歴サーバ３２は、クライアントからのイベントクエリに関して概ね以下のように応答する。クライアントからイベントクエリを受信すると、キャッシュ層サーバ４６は、まず各自のキャッシュ４３をチェックして該当するイベントデータがその中に存在するか否かを判定し、データが存在する場合にはクエリに応答する。該当するイベントデータがキャッシュ４３に存在しない場合、クエリは記憶層サーバ４６のいずれかに渡される。この目的で記憶層サーバ４６を選択するために、負荷分散アルゴリズムを用いることができる。選択された記憶層サーバ４６は、応答（要求されたイベントオブジェクトを含んでいてもよい）を生成し、この応答をクエリの送信元であるキャッシュ層サーバ４２に返信することにより、クエリに対して応答する。次に、キャッシュ層サーバ４２は、この応答を要求元のクライアントに渡す。

応答が持続的記憶装置から検索されたイベントデータを含む場合、キャッシュ層サーバ４２は、このイベントデータを各自のキャッシュ４３にデフォルトで記憶する。この好ましい実施形態において、イベントクエリは、検索されたイベントデータをキャッシュすべきではないことを示してもよく、このような特徴は、例えば、オフラインでのデータマイニングを行う目的で持続的記憶装置から大量のイベントデータを読み出す際にキャシュを行うことを禁止するために用いることができる。

上記で示されたように、イベント履歴サーバ３２の上記した実施形態は、ブラウジングイベントを記述したデータを、そのイベントが発生する際に取得し、パーソナライゼーション・アプリケーション３８が当該イベントデータをリアルタイムで（すなわち、実質的に直ちに）利用できるようにする。また、イベントデータは、アプリケーション３８が各自のクエリを特定のパーソナライゼーション・タスクの実施に必要な特定のタイプおよび項目のイベントデータに限定することを可能にするような形式で利用可能とされる。さらに、オフラインでのデータマイニング分析結果に依存するシステムとは異なり、アプリケーション３８は、イベントデータの単なる要約とは違って、「生の」イベントデータ自体へのアクセスを有している。一部の実施形態において、イベント履歴サーバのユーザは、各自のブラウズ履歴がイベント履歴サーバによって記録されるべきか否かを制御するオプションを与えられてもよい（例えば、オプトインまたはオプトアウトのオプションを設けてもよい）。開示されたアーキテクチャの別の特徴および利点について以下に記載する。

ＩＩ．イベントオブジェクトのコンテンツおよび検索
上記に示されたように、所与のイベントに関して記憶されたデータセットはイベント履歴サーバ３２によりイベントオブジェクトとして記憶される。一実施形態において、各イベントオブジェクトは、以下のコンポーネントを含む。すなわち、主題（Ｓｕｂｊｅｃｔ）、値（Ｖａｌｕｅ）、タグ（Ｔａｇ）および時間（Ｔｉｍｅ）である。以下、これらのコンポーネンのそれぞれについて説明する。一実施形態において、これらのコンポーネントは、３つの一般的なイベントタイプ、すなわちマウスクリック、インプレッションおよびマウスオーバーイベントに関するデータを取得するために用いられる。

イベントオブジェクトの主題は、マウスクリック、マウスオーバーおよびインプレッションイベントに関して、付随する表示要素のタイプ（例えば、項目、ブラウズノード、外部ＵＲＬまたは探索クエリを提出するためのリンク等）を示すコードである。ユーザからの探索クエリの提出を記述するために、１つ以上の主題コードが定義されてもよい。イベントの主題は、イベントのタグ（後述）とともに、イベントのタイプ（例えば、ブラウズノードのマウスクリックやカタログ項目のインプレッション等）を完全に指定するものである。

下記の表１は、サポートされうるイベント主題のいくつかの例を記載し、そのイベント主題のそれぞれに関して値フィールドに記憶されたデータを示している。これらの例は、ウェブサイトシステム３０が、項目（商品、ニュース記事等）を見つけるためにユーザによってブラウズおよび探索されうる電子カタログのホストとなっており、かつウェブサイトシステム３０が外部のウェブサイトおよびウェブページを見つけるための探索エンジンを実現しているということを前提にしている。理解できるように、特定のウェブサイトシステム３０内に記録されたイベントのタイプは、主にそのシステムの性質および目的によって決まり、表１に列記されるものと大きく異なる場合がある。

さらに、イベントタイプは、アプリケーションの付加的な特徴をサポートするために、変更または拡張されてもよい。例えば、表１に示されていない一実施形態においては、ユーザによって入力されたコメントを記憶する目的で、「コメント」イベントタイプが定義されている。コメントイベントのためのアプリケーションの一つは、ユーザが各自の探索結果にコメントを付け、後に当該コメントの再呼び出しおよび見直しを行なうことを可能にすることを含む。自らのコメントを他のユーザに対し公開する機能をユーザに与えてもよい。マウスクリック、インプレッションおよびマウスオーバーイベントとは異なり、コメントイベントは、イベントデータを後に検索するために記憶するというユーザからの明示的な要求を表している。

タグは、以下の一部または全てを示すフラグセットとして実現してもよい。（１）一般的なイベントのタイプ（例えば、マウスクリック、インプレッションまたはマウスオーバー）、（２）イベントの値部分が（例えば、特定のテキストストリングが長すぎるために）短縮されたか否か、（３）イベントが「表示不可能」、つまりユーザによって閲覧が不可能であるか否か、および（４）イベントが持続的か一時的か。

タグの「表示不可能」フラグは、例えば、ユーザが自らの閲覧可能なイベント履歴からイベントを効果的に除去することを可能にするために用いることができる。例えば、ウェブサイトシステム３０は、アプリケーション３８と、それを介して各自のイベント履歴を閲覧および探索することが可能になる関連ユーザインタフェイスとを設け、選択されたイベントを係る履歴から「削除」してもよい。ユーザが特定のイベント（例えば、特定の探索クエリ提出またはブラウズノードアクセス）を削除すると、関連したイベントをユーザが閲覧することを防ぐために、対応するイベントオブジェクトには、イベント履歴サーバ３２によって「表示不可能」とマークがつけられるが、イベント履歴サーバ３２のクライアントは依然としてこれにアクセスすることができる。

「持続的／一時的」フラグは、ある一定の時点で持続的記憶装置から永久的に削除することができるイベントにマークを付けるために用いてもよい。この特徴は、一定の期間後にはほとんどあるいは全く価値がなくなるイベントオブジェクトを放棄するために用いることができ、その結果、関連した持続的記憶装置は、他のデータの記憶用に利用可能となる。

時間コンポーネントは、イベントの発生時刻を示す数値であり、例えば、１９７０年からの秒単位で表すことができる。持続的／一時的フラグが「一時的」にセットされている場合は、イベントオブジェクトの有効期限を指定する付加的な値を含んでいてもよい。期限切れのイベントオブジェクトは、バックグラウンドタスクにより、または別の何らかの適切な方法を用いて周期的に持続的記憶装置から削除されてもよい。

イベント履歴サーバ３２によって実現されたクエリセットは、クライアントがイベントの主題、値、タグおよび時刻に基づいて所与のユーザまたはセッションに対するイベントオブジェクトを検索することを可能にすることが好ましい。例えば、クライアントは、特定のタイプの表示要素の全てのインプレッション（または全てのマウスクリックイベント）に対するイベントオブジェクト、または特定の表示要素の種類および値の全てのインプレッション（または全てのマウスクリックイベント）を要求することができる。また、クエリセットは、クライアントがイベントの時間範囲（例えば、「最後の１０日間」または「２００３年２月１０日以降」）を指定することを可能にすることが好ましい。

上述のように、クエリセットは、以下の形式のクエリもサポートする。「タイプＴかつ値ＶのイベントがユーザＸの履歴内に存在するか？」。イベントのタイプは、一般的なイベントタイプ（例えば、マウスクリックやインプレッション）、付随する表示要素のタイプまたはその両方としてクエリにおいて指定することができる。例えば、「タイプ＝ウェブ探索クエリ、かつ、値＝ハレー彗星のイベントがユーザＸの履歴に存在するか？」という形式のクエリは、ユーザＸが、クエリ「ハレー彗星」を用いて一般的なウェブ探索を行なったか否かを明らかにする。さらに、クエリセットは、「ユーザＸの履歴においてタイプＴかつ値Ｖのイベントが発生したのはいつか？」というタイプのクエリをサポートする。

ＩＩＩ．ソフトウェアアーキテクチャ
図２は、一実施形態におけるキャッシュ層サーバおよび記憶層サーバ４２、４６上で実行される主要ソフトウェアコンポーネントを示している。図示されたように、各記憶層サーバ４６は、キャッシュ層４０からのクエリおよび更新を処理するためのサービスコード６０を実行する。このサービスコードは、バークレーデータベースを実現するために用いられるソフトウェア等のデータベースソフトウェア６２と通信を行なう。データベースソフトウェア６２は、ディスクドライブ記憶装置６４において、イベントデータの１つまたはそれ以上のデータベースを管理している。一実施形態において、各記憶層サーバ４６は、複数のパブリッシュ／サブスクライブ式のサービス処理を実行し、これらは、それぞれ、各自のユーザＩＤのセットまたは範囲に対応し、かつ、各自のバークレーデータベースにのみアクセスを行なう。このアーキテクチャにより、データベースの管理が大いに簡素化される。各記憶層サーバ４６は、その他に、記憶層サーバを同期状態に保つ役割を担う同期サービスコード６８をも実行する。同期サービスは、例えば、１つの記憶層サーバが一時的に切断された後に持続的データベースを同期化するために用いられる。

各キャッシュ層サーバ４２は、自己のイベントデータのキャッシュ４３にアクセスするキャッシュ層サービスコード７０を実行する。イベントデータは、ユーザＩＤ（ユーザが承認されている場合）ごとおよびセッションＩＤごとにキャッシュ４３に記憶されていることが好ましい。図２に示すように、キャッシュ層サービスコード７０は、クライアントから受信した更新およびクエリを処理するためのコンポーネント７２、７４を含む。

図２にさらに示すように、両方の種類のサーバ４２、４６は、ブルームフィルタの生成および処理を行なうためのソフトウェアコンポーネントも含むことが好ましい。以下に説明するように、各ブルームフィルタは、ユーザのイベントデータの一部を圧縮して表現したものであり、関連したイベントオブジェクトを検索することなくユーザが特定の動作を実行したか否かを評価するために用いることができる。例えば、一実施形態において、ブルームフィルタは、所与のユーザが所与のＵＲＬにアクセスしたか否かを判定するために必要な処理およびデータ検索を軽減するために用いられる。

ＩＶ．探索パーソナライゼーション・アプリケーション例
上記に示されたように、イベント履歴サーバ３２の１つのアプリケーションは、特定ユーザによって以前にアクセスされた任意の探索結果項目を識別するパーソナライズされた探索結果ページを生成することを含む。探索結果ページは、このような項目がそれぞれアクセスされた時刻をさらに示してもよい。この特徴は、内部カタログ探索（この場合、探索結果ページは、例えば、ユーザが項目詳細ページを閲覧したカタログ項目を示してもよい）およびウェブ探索（この場合、探索結果ページは、どの外部ウェブページが閲覧されたかを示してもよい）の両方に適用することができる。

図３は、この特徴の一実施形態に係るウェブ探索結果ページの例を示している。この例において、ウェブ探索クエリ「ロード・オブ・ザ・リング」により、各探索結果項目（３つが図示されている）が対応するＵＲＬを有する外部ウェブページまたはサイトである探索結果リストが作成されている。一実施形態においては、探索結果リストに含まれるリンクは、ユーザのブラウザを当該外部ページに直ちにリダイレクトするために用いられる内部リンク（すなわち、これらは元のウェブサーバシステム３０を示している）であり、これにより、イベント履歴サーバ３２は、ユーザによって閲覧の選択がなされた探索結果（外部ＵＲＬ）を記述したイベントオブジェクトを記録することが可能となる。別の実施形態においては、ユーザの外部ＵＲＬの選択は、ユーザの選択を検出および報告するジャバスクリプトコンポーネントを実行することによってログ記録される。

図３のリストの第１の項目１００は、ユーザが以前にこの特定のＵＲＬにアクセスしたことを示す、コメント「閲覧済み」を含む。これにより、ユーザは、すでに閲覧済みのウェブページを容易に識別することができる。ユーザのイベント履歴は、（単にユーザのコンピュータ３６上だけではなく）サーバ側で記憶されているため、ユーザが単に別のコンピュータ３６から上記特定のウェブペーを閲覧した場合であっても、「閲覧済み」のステイタスは適切に示される。この項目１００上でマウスのカーソルを動かすことにより、ユーザは、「以前２月１４日に閲覧済み」というマウスオーバーテキストによって示されるように、彼／彼女が最後にこのＵＲＬにアクセスした日付を見ることもできる。あるいは、このアクセス日付のテキストは、探索結果テキスト１００と共にインライン表示されてもよい。ユーザが特定のＵＲＬにアクセスした回数やそのＵＲＬを発見した過去の探索クエリのテキスト（現在の探索クエリと異なる場合）等の別の様々なタイプの情報をユーザのイベント履歴に基づいてコメントに組み込むことが可能である。

図４は、探索アプリケーション３８がイベント履歴サーバ３２と対話を行なって図３に示されるタイプの探索結果ページを生成する一般的な処理を示している。この例においては、ユーザはウェブサイトシステム３０によって承認されていることを前提としている。ブロック１１０で示されるように、探索アプリケーションは、まず探索クエリを受信し、探索を実行して探索結果セットを生成する。探索が一般的なウェブ探索である場合、各探索結果項目は、探索に応答するウェブページのＵＲＬの形式となり、（図３に示されるような）このようなウェブページから抽出されたテキストの抜粋とともに表示することができる。当該技術分野において知られているように、このような探索の実行は、探索クエリをウェブクローラープログラム（ｗｅｂ ｃｒａｗｌｅｒ ｐｒｏｇｒａｍ）によって生成されたインデックスと比較することを典型的に含む。探索がウェブサイトシステム３０がホストとなっている電子カタログに向けられている場合、各探索結果項目は、対応する項目詳細ページにアクセスするためにクリックすることが可能な項目説明の形式であってもよい。一部の実施形態において、所与の探索において返信された探索結果は、外部ウェブページおよび内部でホストされる電子カタログから選択された項目の両方を含みうる。

ブロック１１２で示されるように、探索アプリケーションは、次に各探索結果項目（あるいは少なくとも現在の探索結果ページ上で表示されるべき探索項目）に対する別個のクエリをイベント履歴サーバ３２に送信し、ユーザがその項目に以前にアクセスしたか否かを判定する。一般的なウェブ探索の場合、このようなクエリはそれぞれ、「ユーザＸは、ＵＲＬ＝＜ＵＲＬ値＞を以前に選択したか？」という形式であってもよい。カタログ探索の場合、各クエリは、「ユーザＸは、カタログ項目＝＜項目ＩＤ＞を以前に選択したか？」という形式であってもよい。以下に説明されるように、イベント履歴サーバ３２はこれらのタイプのクエリを効率的に処理するためにブルームフィルタを用いることが好ましいが、ブルームフィルタの使用は省略してもよい。

ブロック１１４で示されるように、以前にユーザによってアクセスされたと判明した各探索結果項目（存在する場合）に関して、追加のクエリをイベント履歴サーバ３２に送信し、当該項目へのユーザの最後のアクセス日（時刻）を要求することが好ましい。最終的に、ブロック１１６に示されるように、図３に示されたタイプの閲覧済み項目の埋め込みコメントを含む探索結果ページが生成される。探索アプリケーションは、表示のために探索結果項目を順位付け／順序付けを行なう際、各探索結果項目の閲覧済み／未閲覧のステイタスを考慮してもよい。

明らかなように、探索クエリに応じてイベント履歴サーバ３２が実際にはアクセスされないように、図４で示す処理を変更することが可能である。例えば、イベント履歴サーバ３２の負荷を軽減するために、特定ユーザによって選択された特定の探索結果ＵＲＬを示すイベントデータを、イベント履歴サーバ３２から周期的に検索して別個の「探索パーソナライゼーション」サーバに記憶することが可能である。そして、この別個のサーバを、「ユーザＸは外部ＵＲＬ Ｙにアクセスしたか？」とういうタイプの要求に応じるタスクに割り当てることができる。同じことが、以下に説明する図５の処理に対しても当てはまる。

探索アプリケーションのユーザインタフェイスは、以前に閲覧した項目、以前に閲覧していない項目または特定の期間内に閲覧された項目（例えば、過去７日間）に探索範囲を限定するオプションをユーザに与えることができる。この特徴は、イベント履歴サーバ３２から返信されたクエリ結果が、表示されるべき探索結果項目の判定に用いられること以外は、図４に示されるものと同様の処理フローを用いて実現することができる。

明らかなように、上記の探索結果パーソナライゼーションの特徴および図５を参照して説明した特徴は、他のタイプの項目の探索にも適用することができる。例えば、オンラインオークションサイトとの関連では、発見されたオークションのうちユーザによって閲覧されたのはどれか、各オークションが閲覧されたのはいつか、および場合によっては、ユーザがこのようなオークションのそれぞれに入札を行なったか否かを示すコメントをオークションの探索結果に付してもよい。同様に、ユーザによって特定の書き込みが閲覧されたか否か／いつ閲覧されたかを示すコメントを、掲示板の書き込みまたはブログ（ウェブログ）の書き込みの探索結果に付してもよい。

図３に戻って、第２の探索結果項目１２０は、イベント履歴サーバ３２を用いて実現することができる別の特徴を示している。この特徴は、ユーザが以前に同様の探索クエリを提出したかどうか、および、提出した場合には新規探索結果項目（すなわち、過去の探索結果セットに存在しない項目）が見つかったか否かを判定することを含む。この特定例において、探索結果ページは、ユーザが以前２月１４日に同様の探索を行なったこと、およびＵＲＬ「ｌｏｒｄｏｔｒｉｎｇｓ．ｃｏｍ」に対応する項目が過去の探索において現れなかった新規項目であることを明らかにしている。

図５は、探索アプリケーション３８がイベント履歴サーバ３２と対話を行なってこの「新規項目コメント」の特徴を実施する一般的な処理を示している。図３に示す種類のコメント付き探索結果ページを生成するために、この処理を図４の処理と組み合わせてもよい。図５に示されたように、探索アプリケーションは、まず探索クエリ（ブロック１３０）を受信および実行し、イベント履歴サーバ３２に照会を行なってユーザが以前に同様のクエリを提出したか否かを判定する（ブロック１３２）。ユーザがこのクエリを提出していない場合、「新規項目」コメントを加えることなく探索結果ページが生成される（ブロック１４０）。

同様の探索クエリが以前に提出されていた場合、イベント履歴サーバ３２は、最終提出時刻について再度照会を受ける（ブロック１３４）。また、ブロック１３６に示されるように、イベント履歴サーバ３２は、（存在する場合には）現在の探索結果項目のうちユーザに表示されていない（すなわち、インプレッションイベントの対象となったことがない）のはどれかを判定するための照会を受ける。この照会の範囲を、過去の探索の時点またはその直後に発生したインプレッションに、必要に応じて限定してもよい。ブロック１３８で示されるように、現在の探索結果セットに何らかの新規探索結果項目が存在する場合、これらに対しては、図３に示すようにコメントが付される（項目１２０）。新規項目の重要性の順位を上昇させ、新規項目が表示される可能性を高めてもよい。

図５に示された方法の１つの変形は、ユーザが（リピート）探索を同様の探索クエリの過去の実行において現れなかった項目に明示的に限定することを可能にすることである。このようなオプションは、例えば、ウェブサイトの探索ページ上のチェックボックスとして設けることができる。

ＩＶ．ユーザが以前に所与の要素を閲覧またはアクセスしたか否かを判定するためのブルームフィルタの使用
上記のように、「ユーザＸの履歴内にタイプＴかつ値Ｖのイベントが存在するか？」という形式のクエリに応答する際の持続的なデータ検索の必要性を軽減するために、イベント履歴サーバ３２によってブルームフィルタが使用されてもよい。ブルームフィルタは、例えば、特定ユーザが特定ＵＲＬを閲覧または選択したか否かを判定するために用いることができる。

背景として、ブルームフィルタとは、ハッシュ関数のセットによって生成されたビットシーケンスまたはアレイである。ブルームフィルタは、特定の項目が、大きいセットの要素であるか否かを速やかに調べるために用いられる。ブルームフィルタの一般的な応用例の１つは、所与のオブジェクト（オブジェクトのＵＲＬとして識別されるような）がウェブページのキャッシュに現在記憶されているか否かをテストすることである。具体的には、オブジェクトがキャッシュに追加されると、オブジェクトのＵＲＬにハッシュ関数が適用され、ブルームフィルタのどのビットをＯＮにすべきかが判定される。オブジェクトが要求されると、要求されたオブジェクトのＵＲＬにこれらのハッシュ関数が再度適用され、次にブルームフィルタの対応するビットの全てがＯＮになったか否かを判定するテストが行われる。１つ以上のビットがＯＮでなかった場合、オブジェクトはキャッシュに記憶されない。一方、全てのビットがＯＮである場合、要求されたオブジェクトがキャッシュに存在する可能性が非常に高い。したがって「フォールスポジティブ（ｆａｌｓｅ ｐｏｓｉｔｉｖｅ）」すなわち「偽のヒット」はありうるが、「フォールスネガティブ（ｆａｌｓｅ ｎｅｇａｔｉｖｅ）」すなわち「偽のミス」は通常ありえない。

本発明の１つの側面によると、所与のユーザに対し、そのユーザのイベント履歴の何らかの側面またはセグメントを記述するために、１つまたはそれ以上のブルームフィルタが生成される。ブルームフィルタは、持続的記憶層４４（図１）によって生成および記憶され、クエリへの応答のためにキャッシュ層４０に渡されることが好ましい。異なるタイプのクエリに応答するために、所与のユーザ用に異なるブルームフィルタを生成してもよい。例えば、異なるタイプの活動（例えば、ＵＲＬアクセス、ＵＲＬインプレッション、ＵＲＬアクセスおよびインプレッション、カタログ項目アクセス、マウスオーバーイベント等）用に異なるタイプのブルームフィルタを生成することができる。また、異なる期間用に異なるブルームフィルタを生成してもよい。

図６は、承認されたユーザであるユーザＸによるＵＲＬアクセスをテストするために、ブルームフィルタが用いられる一般的な処理を示している。同図はＵＲＬアクセスに限定されているが、図示される処理フローは、他のタイプのイベント活動にも該当する。図６のステップ１において、記憶層サーバ４６は、ユーザＸ用に、１つ以上のブルームフィルタを生成する。このステップは、例えば、ユーザＸに対する関連したクエリまたは更新の受信に応じて行なってもよい。特にＵＲＬアクセスに対するブルームフィルタを生成するために、記憶層サービスコード（図２）は、まずユーザＸに対するＵＲＬアクセスイベントを検索し、アクセスされた各ＵＲＬにハッシュ関数のセットを適用し、関連したブルームフィルタのビットをセットする。以下に述べるように、ブルームフィルタの大きさは、所望の数のイベントの記憶を可能にしつつフォールスポジティブの確率を所望の閾値未満に維持するように選択することができる。１つの記憶層サーバ４６によって生成されたブルームフィルタは、同期サービスにより（１つまたは複数の）別の記憶層サーバに渡されてもよい。ブルームフィルタは、キャッシュ層サーバ４２により付加的に、または二者択一的に生成されてもよい。

図６のステップ２において、キャッシュ層サーバは、「ユーザＸはＵＲＬ Ｙにアクセスしたか？」という形式のクエリを受信する。上述の探索結果コメントの特徴との関連では、１つの探索結果ページを生成する目的で、所与のユーザに関してこのようなクエリを多数受信することができる。ステップ３において、キャッシュ層サーバ４２は、ブルームフィルタがキャッシュ４３にまだ記憶されていない場合、記憶層サーバ４６のうちの１つから該当するブルームフィルタを検索する。

ステップ４において、キャッシュ層サーバ４２は、該当するブルームフィルタをテストして、ＵＲＬに関して、対応するビットがＯＮであるか否かを確かめる。ビットのうち１つ以上がＯＦＦである場合（すなわち、ユーザＸの該当イベント履歴においてＵＲＬ Ｙへのアクセスが存在しない）場合、キャッシュ層サーバ４２は、持続的記憶層にクエリを渡すことなく、ＮＯの回答を返信する（ステップ５）。一方、全てのビットがＯＮである（すなわち、ユーザＸのイベント履歴にＵＲＬアクセスが存在している可能性が高い）場合、記憶層サーバ４６のうちの１つにクエリが渡され（ステップ６）、ＵＲＬアクセスに対するユーザＸの実際のイベントデータがチェックされる。ステップ７において、記憶層サーバ４６は、キャッシュ層サーバ４２を介してクエリに対する応答を返信する。記憶層サーバに対して照会を行なう代わりに（ステップ６）、キャッシュ層サーバを、ブルームフィルタのテストがポジティブである場合に単にＹＥＳの回答を返信するよう構成してもよいが、この手法によると、まれにユーザに対して不正確な結果が提示される場合がある。

ＵＲＬアクセスを反映した更新がそれ以降ユーザＸについて受信されるので、キャッシュ層サーバ４２は、関連したブルームフィルタの自身のコピーを更新し、これらの更新を反映させる（しかし、記憶層サーバ４６は更新を行なわないことが好ましい）。例えば、ユーザＸが図３に示すタイプのウェブ探索結果ページから探索結果項目（ＵＲＬ）を選択する場合、関連したブルームフィルタがキャッシュ４３内で更新され、選択されたＵＲＬに関連付けられたビットがセットされる。したがって、クエリに応答するためにキャッシュ層によって用いられるブルームフィルタは、該当するユーザの最新のブラウジング活動を反映している。ある時点において、ブルームフィルタを、非アクティブであることを理由にキャッシュ４３から放棄してもよく、この時点で、更新されたブルームフィルタがその後の使用のために持続的記憶層に（元のバージョンの代わりに）書き込まれる。

ある時点において、所与のブルームフィルタの容量が満たされる、すなわち、所望の平均フォールスポジティブ確率を超えずにさらなるイベントを記憶することができなくなるかも知れない。この時点で、より大きいイベント容量を提供するために、ブルームフィルタをより大きい（例えば、４キロバイトの代わりに８キロバイトの）ブルームフィルタと交換することができる。

上記した説明においては、承認されたユーザに対するブルームフィルタの生成および使用に焦点をおいたが、ブルームフィルタは、キャッシュ層サーバ４２によって、未承認のユーザに関しても生成することができる。例えば、ブラウジングセッションの始めに、割り当てられたキャッシュ層サーバ４２は、ユーザに関してフィルタを生成してもよく、また、それ以降、そのユーザに関して、新たなイベントを用いてブルームフィルタを更新してもよい。このような「セッション特有」のブルームフィルタを、上記と同様にクエリに対して応答するために用いることができる。

Ｖ．ブラウザベースのイベントデータの報告
図７は、イベント履歴サーバ３２が、ブラウザベースのイベント報告コンポーネント１６０によって報告されたイベントデータを記録する実施形態を示している。イベント報告コンポーネント１６０は、イベント履歴サーバ３２のユーザのコンピュータ３６の一部または全てにおいて、ウェブブラウザ１６２のコンポーネントとして実行される。図示されたように、イベント報告コンポーネント１６０は、ブラウザツールバーコンポーネント１６４の一部として実現されることが好ましい。ツールバーコンポーネント１６４は、例えば、ユーザによってダウンロードおよびインストール可能な任意選択のブラウザプラグインとして設けることができる。あるいは、イベント報告コンポーネント１６０は、独立型ブラウザプラグインとして、ツールバー以外のプラグインの一部として、またはウェブブラウザ１６２の固有コードの一部として実現することができる。

ブラウズベースのイベント報告コンポーネント１６０は、ユーザによってアクセスされた全てのウェブサイトおよびページについてイベントデータを報告することが好ましい。例えば、イベント報告コンポーネント１６０は、ユーザによってアクセスされた全てのウェブページ上での全てのマウスクリックまたはその他の選択イベントを報告することができる。イベント報告コンポーネント１６０は、マウスオーバーイベント、インプレッション、ウェブブラウザ１６２上の「戻る」ボタンの選択等の別のタイプのブラウジングイベントをも報告することができる。

ブラウザベースのイベント報告コンポーネント１６０は、図１のサーバベースのイベント報告コンポーネント３５に代えて用いることができる。あるいは、所与のシステム内で両タイプのイベント報告コンポーネント３５、１６０を用いてもよい。例えば、インストールされたツールバー１６４を有しないユーザに関しては、イベント履歴サーバ３２は、サーバベースのイベント報告コンポーネント３５によって報告されたデータのみを取得してもよく、その場合、イベントデータは、１つ以上の特定のウェブサイトのブラウジング中に発生するイベントのみを反映する。自分のコンピュータ３６にインストールされたツールバー１６４を有するユーザに関しては、取得されたイベントデータは、別のウェブサイトにも及んでいてもよい。

ブラウザベースのイベント報告コンポーネント１６０から収集されたイベントデータは、ユーザに対して様々な異なるパーソナライゼーション・サービスを提供するために用いられることができる。例えば、ユーザが、自分がアクセスした、何らかのユーザ指定の基準を満たす全てのウェブサイトのリストを閲覧することを可能にするサービスを提供することができる。このサービスを用いて、ユーザは、例えば、ウェブ上でそれぞれが行った全ての支払いトランザクションのリストを閲覧したり、アクセスした全ての旅行関連ウェブサイトの履歴を閲覧することができる。このようなサービスを実現するために、イベントオブジェクト内に含まれるデータフィールドを必要に応じて補足することができる。

図７に示されたように、パーソナライズされたツールバーコンテンツは、サーバ側のツールバー・パーソナライゼーション・アプリケーション１７０によって生成されてもよい。このアプリケーション１７０は、ユーザに対して表示するためのコンテキスト依存のツールバーメッセージを生成するために、イベント履歴サーバ３２から検索されたイベントデータを用いることができる。例えば、ユーザが特定のウェブサイトにアクセスする場合、ツールバー・パーソナライゼーション・アプリケーション１７０は、そのウェブサイト上でユーザによって実行されたトランザクションの履歴を検索および表示することができる。さらに、ツールバーは、現在のブラウジングセッション中に訪問された全てのウェブサイトまたはページに関するリアルタイムな情報によってパーソナライズされてもよい。

ＶＩ．別のパーソナライゼーション・アプリケーション
理解できるように、別の数多くのタイプのパーソナライゼーション・アプリケーションおよび特徴がイベント履歴サーバ３２によって可能となる。上述のように、そのようなアプリケーションの１つは、ユーザが自分のイベント履歴を閲覧、編成すること、および場合によってはこれらにコメントを付けることを可能にすることを含む。これは、部分的には、ウェブページのセット等の、ユーザがイベント履歴フォルダを作成し、イベントを選択してこのようなフォルダに追加することができるユーザインタフェイスを提供することにより実現できる。イベントタイプ、イベント値、イベント発生時刻およびその他の様々な基準ごとに、ユーザが自分のイベント履歴を探索することができるイベント探索エンジンを設けてもよい。上述のように、ユーザが特定のイベントを自分のイベント履歴から「削除」することを許可してもよい。

本発明を特定の好適な実施形態に関して説明したが、本明細書に記載した全ての特徴および利点が提供されていない実施形態を含む、当業者に明らかな別の実施形態および応用例もまた本発明の範囲に含まれる。したがって、本発明の範囲は、添付の特許請求の範囲を参照することによってのみ定められる。

図１は、本発明の一実施形態に係るイベント履歴サーバシステムを備えるウェブサイトシステムを示す。 図２は、図１のキャッシュ層サーバおよび記憶層サーバによって実行されうるソフトウェアコンポーネントのセットを示す。 図３は、探索結果に、当該項目に関するユーザの過去のブラウズ履歴を示すコメントが付けられているウェブ探索結果ページの例を示す。 図４は、ユーザによって以前にアクセスされた探索結果項目を識別するための処理を示す。 図５は、ユーザが以前に同様の探索クエリを提出したか否かを判定し、かつ、提出した場合には、現在の探索に新規の探索結果項目が見つかったか否かを判定するための処理を示す。 図６は、ユーザが特定のオブジェクトにアクセスしたか否かを効率的に判定するためのブルームフィルタの使用を示す。 図７は、ブラウザツールバー等のブラウザコンポネントによって報告されたイベントデータを収集するためにイベント履歴サーバがどのように使用されうるかを示す。

Claims (45)

1. オンラインユーザからの要求に対し、ウェブページを生成および返信することによって応答するウェブサーバシステムであって、承認されたユーザに対するパーソナライズされたコンテンツを該ユーザのブラウズ履歴に基づいて生成する１つ以上のアプリケーションを備えるウェブサーバシステムと、
   前記ウェブサーバシステムの複数のユーザのそれぞれのブラウジングセッション中に発生するイベントを記述したイベントデータを持続的に記憶し、前記１つ以上のアプリケーションが前記イベントデータをリアルタイムに利用できるようにして前記ユーザのウェブページのパーソナライゼーションを促進するイベント履歴サーバとを備え、
   前記イベント履歴サーバが、前記１つ以上のアプリケーションがイベントタイプごとおよびイベント発生時刻ごとに所与のユーザのイベントデータを検索することができるクエリインタフェイスを、実現しているウェブサイトシステム。
2. 前記イベント履歴サーバが、所与のイベントに関して、前記イベントデータを少なくともイベントタイプ識別子、イベント値、ユーザＩＤおよびタイムスタンプを含むイベントオブジェクトとして記憶する請求項１に記載のウェブサイトシステム。
3. 前記イベント履歴サーバが、ユーザＩＤごとに前記イベントデータを持続的に記憶する少なくとも１つの記憶層サーバを備え、オンラインユーザのイベントデータをキャッシュする少なくとも１つのキャッシュ層サーバをさらに備える請求項１に記載のウェブサイトシステム。
4. 前記キャッシュ層サーバが、未承認のユーザのイベントデータをブラウジングセッション中に収集し、前記ブラウジングセッション中に前記未承認のユーザが承認された場合に、その収集されたイベントデータを持続的に記憶するために前記少なくとも１つの記憶層サーバに渡すように構成されている請求項２に記載のウェブサイトシステム。
5. 前記イベント履歴サーバが複数のキャッシュ層サーバを備え、そのそれぞれが、所与のユーザがブラウジングセッションを通じて特定のキャッシュ層サーバに割り当てられた状態に保たれるように、それぞれ異なるブラウズセッションＩＤのセットに割り当てられている請求項１に記載のウェブサイトシステム。
6. 前記イベント履歴サーバが、ユーザＩＤごとに同様なイベントデータを持続的に記憶する複数のミラーリングされた記憶層サーバを備える請求項１に記載のウェブサイトシステム。
7. 前記イベント履歴サーバの前記クエリインタフェイスが、「ユーザＸはＵＲＬ Ｙにアクセスしたか？」という形式のクエリをサポートしている請求項１に記載のウェブサイトシステム。
8. 前記イベント履歴サーバの前記クエリインタフェイスが、「ユーザＸがＵＲＬ Ｙにアクセスしたのはいつか？」という形式のクエリをサポートしている請求項１に記載のウェブサイトシステム。
9. 前記イベント履歴サーバが、対応するウェブサイトの全ての承認されたユーザの実質的に全てのマウスクリック動作に関してイベントデータを記録する請求項１に記載のウェブサイトシステム。
10. 前記イベント履歴サーバが、動的に生成されたウェブページ上でユーザに対して提示された特定の項目を示すインプレッションイベントデータを記録する請求項１に記載のウェブサイトシステム。
11. 前記１つ以上のアプリケーションが、ウェブページのインデックスを探索するための機能を提供するウェブ探索アプリケーションを備え、前記イベント履歴サーバを用いて、現在の探索を行なっているユーザによって以前にアクセスされたウェブ探索結果項目を識別および強調表示する請求項１に記載のウェブサイトシステム。
12. 前記１つ以上のアプリケーションが、ユーザに、前記イベント履歴サーバによって記録されたような自分のブラウズ履歴データを対話式に閲覧および編成するための機能を提供するアプリケーションを備える請求項１に記載のウェブサイトシステム。
13. 前記イベント履歴サーバが、特定ユーザのイベント履歴を反映したユーザ特有のブルームフィルタを生成し、前記ユーザ特有のブルームフィルタを用いて、前記１つ以上のアプリケーションからのクエリに対して応答する請求項１に記載のウェブサイトシステム。
14. ユーザのウェブブラウズセッション中に発生するブラウジングイベントを記述したイベントデータを持続的に記憶し、かつこれらのブラウジングイベントに対するリアルタイムのアクセスを提供する複数の記憶層サーバであって、前記イベントデータを対応するユーザＩＤと関連付けてインデックス形式で記憶し、持続的に記憶されたイベントデータに対するクライアント要求が前記記憶層サーバのいずれかによって処理可能となるように、互いのミラーとして実現されている記憶層サーバと、
    前記記憶層サーバと前記イベント履歴サーバのクライアントとの間の中継部として機能する複数のキャッシュ層サーバであって、それぞれが各キャッシュ内にキャッシュされたイベントデータを記憶しかつ前記キャッシュされたイベントデータを用いて前記クライアントからのクエリに応答する複数のキャッシュ層サーバとを備えるイベント履歴サーバ。
15. 各キャッシュ層サーバが、それぞれ異なるユーザのセットに関してイベントデータをキャッシュするように、ブラウジングセッションが特定のキャッシュ層サーバに一意に割り当てられている請求項１４に記載のイベント履歴サーバ。
16. 前記キャッシュ層サーバが、イベント報告コンポーネントから受信した更新に対して、該更新によって指定されたイベントデータを用いて自分自身のキャッシュを更新すること、および該更新を、そこに指定された前記イベントデータを持続的に記憶するために前記記憶層サーバに転送することにより、応答する請求項１４に記載のイベント履歴サーバ。
17. 前記記憶層サーバが、所与のイベントに関して、前記イベントデータを、少なくともイベントタイプ識別子、イベント値およびタイムスタンプを含むイベントオブジェクトとして記憶する請求項１４に記載のイベント履歴サーバ。
18. 前記記憶層サーバおよび前記キャッシュ層サーバが、前記イベント履歴サーバのクライアントが少なくともユーザＩＤ、イベント時刻、イベント日付という基準に基づいてイベントオブジェクトを検索することが可能なクエリインタフェイスを実現している請求項１７に記載のイベント履歴サーバ。
19. 各キャッシュ層サーバが、未承認のユーザのイベントデータをブラウジングセッション中に収集し、前記ブラウジングセッション中に前記未承認のユーザが承認された場合に、その収集されたイベントデータを持続的に記憶するために記憶層サーバに渡すように構成されている請求項１４に記載のイベント履歴サーバ。
20. 前記キャッシュ層サーバが、「ユーザＸはＵＲＬ Ｙにアクセスしたか？」という形式のクエリをサポートしている請求項１４に記載のイベント履歴サーバ。
21. 前記キャッシュ層サーバが、「ユーザＸがＵＲＬ Ｙにアクセスしたのはいつか？」という形式のクエリをサポートしている請求項１４に記載のイベント履歴サーバ。
22. 前記記憶層サーバが、対応するウェブサイトの全ての承認されたユーザの実質的に全てのマウスクリック動作に関して、イベントデータを記憶する請求項１４に記載のイベント履歴サーバ。
23. 前記記憶層サーバが、動的に生成されたウェブページ上でユーザに対して提示された特定の項目を示すインプレッションイベントデータを記録する請求項１４に記載のイベント履歴サーバ。
24. ユーザからの探索クエリを処理する方法であって、前記ユーザからリモートであるサーバシステム上において、
    前記探索クエリを実行し、前記探索クエリに応答するウェブページのＵＲＬを含むクエリ結果を生成するステップと、
    前記ＵＲＬのうち少なくとも１つに関して、サーバに照会を行い、前記ユーザに関して記憶されたイベントデータが、前記ユーザが以前に前記ＵＲＬにアクセスしたことを示しているか否かを判定するステップと、
    前記ユーザが以前に前記ＵＲＬにアクセスしたことを前記イベントデータが示している場合に、前記ＵＲＬが以前にアクセスされたことを前記ユーザに示すコメントを探索結果ページ内に含めるステップとを含む方法。
25. 前記コメントが、前記ユーザに関して記憶された前記イベントデータによって示されるように、前記ユーザが前記ＵＲＬにアクセスした日付を、さらに示す請求項２４に記載の方法。
26. 前記サーバが、少なくとも部分的に、前記ユーザに関して記憶されたブルームフィルタを用いて、前記ユーザが以前に前記ＵＲＬにアクセスしたか否かを評価することにより、前記照会に対して応答する請求項２４に記載の方法。
27. 前記方法が、前記サーバに対して照会を行い、前記ユーザが前記ＵＲＬにアクセスした日付を識別し、前記探索結果ページ内に前記日付を含めるステップをさらに含む請求項２４に記載の方法。
28. 前記方法が、ユーザに関して記憶された前記イベントデータによって示されるように、複数の前記ＵＲＬのそれぞれに関して、前記サーバに対して個別に照会を行い、前記ＵＲＬのそれぞれが、前記ユーザによって以前にアクセスされたか否かを判定するステップを含む請求項２４に記載の方法。
29. 請求項２４に記載の方法を実施する実行可能なクエリ処理コードを備える探索エンジンシステム。
30. インターネット探索を行うための機能を提供するシステムであって、
    ユーザからの探索クエリに対し、該探索クエリに対して応答する外部ウェブページの探索結果ＵＲＬを列記した探索結果ページを生成および返信することによって応答する探索アプリケーションと、
    前記探索結果ページのブラウジング中にユーザによって選択された前記探索結果ＵＲＬを示すユーザ特有のデータを記録するサーバとを備え、
    前記探索アプリケーションが、前記サーバにアクセスし、特定の探索結果ＵＲＬが探索を行っているユーザによって以前にアクセスされたか否かを判定し、どの探索結果ＵＲＬが以前にアクセスされたかを示す表示を前記探索結果ページに組み込み、
    これによりユーザが、自分自身が以前にアクセスした探索結果ＵＲＬについて通知をうけるシステム。
31. 前記サーバが、特定の探索結果ＵＲＬが特定ユーザによってアクセスされた日付を示す情報を付加的に記録し、
    前記探索アプリケーションが、前記情報を用いて、特定の探索結果ＵＲＬがアクセスされた前記日付を前記探索結果ページ内でさらに示す請求項３０に記載のシステム。
32. 前記サーバが、ユーザによって選択された探索結果ＵＲＬを反映するユーザ特有のブルームフィルタを生成し、かつ、該ユーザ特有のブルームフィルタを用いて、特定ユーザが以前に特定のＵＲＬにアクセスしたか否かを評価するように構成されている請求項３０に記載のシステム。
33. 前記システムが、探索結果ＵＲＬの選択に応じてユーザを該ＵＲＬにリダイレクトすることにより、前記ユーザによる前記探索結果ＵＲＬの選択の追跡を容易にしている請求項３０に記載のシステム。
34. 前記サーバが、特定ユーザによって提出された特定の探索クエリを示すユーザ特有のデータをさらに記録し、
    前記探索アプリケーションが、前記サーバによって記憶された前記データを用いて、現在の探索を行なっているユーザが以前に同様の探索を行なった際に現れなかった探索結果ＵＲＬを識別し且つ強調表示する請求項３０に記載のシステム。
35. 前記サーバが、複数のイベントタイプのそれぞれに関して持続的にイベントデータを記憶し、ユーザ特有のイベントデータのイベントタイプごとのリアルタイム検索を提供するクエリセットを実現している請求項３０に記載のシステム。
36. ブラウズ履歴ベースの探索結果のパーソナライゼーションを提供する方法であって、
    探索結果ページのブラウジング中にユーザによって選択された探索結果ＵＲＬを示すイベント履歴データを保持するステップと、
    前記イベント履歴データ内において示されるような前記ユーザによって選択された複数の前記探索結果ＵＲＬを反映するユーザ特有のブルームフィルタを生成するステップと、
    前記ユーザによって提出された探索クエリの結果内での所与のＵＲＬの発生に応じて、少なくとも部分的に、前記ユーザ特有のブルームフィルタを分析することにより、前記ユーザが以前に前記所与のＵＲＬにアクセスしたか否かを判定するステップと、
    前記ユーザが前記所与のＵＲＬに以前にアクセスしたと判定された場合に、前記ユーザが以前に前記所与のＵＲＬにアクセスしたことを表示することにより、前記ユーザに対する探索結果ページをパーソナライズするステップとを含む方法。
37. 前記探索結果ＵＲＬのそれぞれが前記ユーザによっていつ選択されたかという記録を保持し、かつ、前記ユーザが前記所与のＵＲＬにいつアクセスしたかを表示することにより前記探索結果ページをパーソナライズするステップをさらに含む請求項３６に記載の方法。
38. 前記ユーザ特有のブルームフィルタが、複数の独立したウェブサイトのＵＲＬに対する前記ユーザのアクセスを反映する請求項３６に記載の方法。
39. 前記ユーザ特有のブルームフィルタが、複数のブラウズセッションにわたって前記ユーザによって行なわれた動作を反映する請求項３６に記載の方法。
40. 前記ユーザが以前に前記所与のＵＲＬにアクセスしたか否かを判定する前記ステップが、
    前記ブルームフィルタが、前記ユーザの前記所与のＵＲＬへのアクセスの可能性を示しているか否かを最初に判定するステップと、
    前記ブルームフィルタが前記アクセスの可能性を示している場合に、前記イベント履歴データにアクセスし、前記所与のＵＲＬへのアクセスが実際にそこで反映されているか否かを判定するステップとを含む請求項３６に記載の方法。
41. 前記ユーザが以前に前記所与のＵＲＬにアクセスしたか否かを判定する前記ステップが、
    前記ブルームフィルタが、前記ユーザの前記所与のＵＲＬへのアクセスの可能性を示しているか否かを最初に判定するステップと、
    前記ブルームフィルタが前記アクセスの可能性を示している場合に、前記所与のＵＲＬを前記ユーザによって以前にアクセスされたものとして取り扱うステップとを含み、その結果、前記ユーザのイベント履歴データに直接アクセスする必要がなくなる請求項３６に記載の方法。
42. ブラウズ履歴ベースのコンテンツ・パーソナライゼーションを提供する方法であって、
    ウェブサイトとのユーザの対話を記述したブラウズ履歴を保持するステップと、
    前記ユーザのブラウズ履歴内に含まれる複数のイベントを表すユーザ特有のブルームフィルタを生成するステップと、
    少なくとも部分的に、前記ブルームフィルタを分析することにより、前記ユーザの前記ブラウズ履歴内に特定のイベントが存在するか否かを判定するステップと、
    前記特定のイベントが前記ユーザの前記ブラウズ履歴内に存在するか否かを前記ウェブページが反映するように、前記ユーザ用に前記ウェブページをパーソナライズするステップとを含む方法。
43. 前記ブルームフィルタが、前記ユーザの探索結果ＵＲＬへのアクセスを反映し、
    特定のイベントが前記ブラウズ履歴内に存在するか否かを判定する前記ステップが、前記ブルームフィルタを用いて、前記ユーザが以前に特定の探索結果ＵＲＬにアクセスしたか否かを評価するステップを含む請求項４２に記載の方法。
44. 前記ブルームフィルタが、電子カタログから前記ユーザによって選択された複数の項目を反映し、
    特定のイベントが前記ユーザの前記ブラウズ履歴内に存在するか否かを判定する前記ステップが、前記ブルームフィルタを用いて、前記ユーザが以前に前記電子カタログから特定の項目を選択したか否かを評価するステップを含む請求項４２に記載の方法。
45. 前記ブルームフィルタが、項目が前記ユーザに単に表示されただけで選択されなかったイベントを反映し、
    前記ユーザ記のブラウズ履歴内に特定のイベントが存在するか否かを判定する前記ステップが、前記ブルームフィルタを用いて、以前に前記ユーザに対して特定の項目が表示されたか否かを評価するステップ含む請求項４２に記載の方法。

Images