JP2001142907A - インターネット・プロファイリングシステム - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、多数のドメインに亘るユーザの関
心を追跡し、追跡したユーザの時間的に変化する関心を
記述する時間ベースモデルを生成するシステム、方法、
並びに、種々のソフトウェア製品の提供を目的とする。 【解決手段】 本発明は、ウェブビジターの識別と、ウ
ェブビジターの時間的に変化する関心を把握する。変化
するユーザの関心は、多数の定義済みユーザグループ内
で各ユーザのメンバーシップを判定するため使用され
る。各ユーザの関心の時間ベースモデル及びグループメ
ンバーシップは、インターネット行動の詳細なプロフィ
ールを形成する。詳細なプロフィールは、ユーザへのマ
ーケット情報及び製品情報の提示、ウェブコンテンツの
動的なカスタマイズ、並びに、その他の販売目的に使用
可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オンラインネット
ワークのユーザの挙動及び関心の分析に係り、特に、イ
ンターネット及びワールド・ワイド・ウェブのユーザに
関するユーザの関心の分析及びモデリングに関する。

【０００２】

【従来の技術】どのような市場でも顧客の行動は重要で
ある。このことは、従来からの小売業にも当てはまる
が、小売業では、顧客の関心を判定するための十分に発
展したメカニズムが存在する。既存の店舗ビジネスで
は、ビジネスの顧客は店内を歩く様子を観察される。顧
客の行動は（たとえば、クレジットカードの購入品を通
じて）買物を追跡することによっても観察される。顧客
の観察は、実際上、多数の小売業で使用される重要な技
術である。顧客の観察は非常に重要であり、顧客行動に
関する大規模データベースが存在し、継続して使用され
る。たとえば、殆どのスーパーマーケット・チェーン
は、顧客行動の大規模データベースを保有する。このデ
ータベース内のデータを分析結果は、多数の目的（たと
えば、在庫管理、商品配置、新商品分析など）のため使
用される。

【０００３】顧客行動の理解は、電子商取引の場合にも
必要であるが、電子商取引における顧客を観察する技術
は必然的に異なる。顧客が電子商取引ウェブサイトと相
互作用する方法は、本人が店に入り買物を行う経験とは
根本的に異なるが、変わらないままのものも多数ある。
ウェブを訪れる人、すなわち、ウェブビジターがウェブ
サイトを見て回るとき、購入するときもあれば、購入し
ないときもある。店側は、ビジターが購入した理由、及
び、購入しなかった理由を把握することに関心がある。
そこで、電子商取引者は、自分の潜在的な顧客層及び顧
客を理解しようとする。電子商取引者は、ウェブビジタ
ーを観察する必要がある。この観察は、顧客の関心を時
間的にモデリングする必要性、モデリングに必然的に付
随する多量データの管理の必要性、ならびに、ユーザ関
心の有意なモデルを提供するたウェブ内容のカテゴリー
の必要性を生じる。

【０００４】従来、オンラインシステムのユーザの観察
は、典型的にユーザ関心に関するユーザが提供した情
報、たとえば、顧客に重要な情報のカテゴリーを識別さ
せることができる質問又はフォームのような情報を使用
する。このようなアプローチの例には、YahooやExciteの
ような検索ポータルによって提供される種々のカスタマ
イズ可能なホームページが含まれる。これらのポータル
では、ユーザは、多数の予め決められたカテゴリーの中
から興味のあるカテゴリーを選択し、関連したニュース
及び関連データがユーザに提供される。しかし、ユーザ
の関心が時間に応じて変化する場合、カテゴリーの変更
は自動的には行われないので、ユーザは指定した興味の
あるカテゴリーを手動で変更しなければならない。これ
らのサイトは、ユーザが自分の興味を簡単なキーワード
を使って指定できるようにするが、興味のある対象が変
化した場合、ユーザはキーワードを自分でマニュアル変
更しなければならない。

【０００５】クリックスルー(clickthrough)及びページ
閲覧に関してユーザの行動をより系統的に追跡し、これ
らの行動に関する情報を集める別のウェブサイトが存在
する。ユーザの行動は特定のウェブサイト上で変化する
ので、集められた情報は更新される。このアプローチ
は、ユーザの行動の変化のある局面を捉えることができ
るが、単一のウェブサイトに関する興味の識別に制限さ
れる。他のウェブサイトでのユーザの行動は、たとえ、
この別の行動がユーザの関心を最も正確に表現している
としても、特定サイトで集められた情報に影響を与えな
い。より詳細には、ユーザ行動の分析は、典型的に、使
用状況を追跡するサーバーの特定のインターネット・ド
メインに制限される。別のドメインでのユーザ行動は追
跡されない。

【０００６】さらに、このようなサーバー上で集められ
た情報は、現在のユーザの関心を表現するだけであり、
潜在的な将来の関心や過去の関心を表さない。すなわ
ち、この情報は、ユーザ関心の時間的変化をモデル化で
きない。しかし、ウェブ上の商取引者や、コンテンツを
ウェブビジターに配信しようとする側にとって価値のあ
る情報は、時間的に変化するユーザの関心である。

【０００７】

【発明が解決しようとする課題】本発明は、上記の従来
技術による制限を解決するため、多数のドメインに亘る
ユーザの関心を追跡し、追跡したユーザの時間的に変化
する関心を記述する時間ベースモデルを生成するシステ
ム、方法、並びに、種々のソフトウェア製品の提供を目
的とする。

【０００８】

【課題を解決するための手段】上記目的を達成するた
め、本発明によれば、変化するユーザの関心は、多数の
定義済みユーザグループ内で各ユーザのメンバーシップ
を判定するため使用される。各ユーザの関心の時間ベー
スモデル及びグループメンバーシップは、インターネッ
ト行動の詳細なプロフィールを形成し、この詳細なプロ
フィールは、ユーザへのマーケット情報及び製品情報の
提示や、ウェブコンテンツの動的なカスタマイズを行う
ため、あるいは、その他の販売目的に使用可能である。

【０００９】そのため、本発明は、ウェブビジターの識
別と、ウェブビジターの時間的に変化する関心を把握す
るという重要な要求を満たす。本発明は、ワールド・ワ
イド・ウェブ上のウェブビジターを追跡し分析するソフ
トウェアシステムであり、以下の説明中、"ProReach"又
は"ProReaach system"のように呼ばれる。

【００１０】本発明の特徴及び局面は以下の通りであ
る。第一に、本発明は、ウェブビジターがウェブサイト
を訪問するとき、ウェブビジターを識別し監視すること
ができる。勿論、インターネット上には多数のウェブサ
イトがあり、多数のウェブビジターが存在する。関連す
るウェブサイトの数が二つであるか、あるいは、数千で
あるか、ならびに、ウェブビジターの数が数百万人であ
るかどうかとは無関係に、本発明は、多数のウェブサイ
トに亘って多数のビジターを識別することができるシス
テムを提供する。この局面に関して、本発明は、ウェブ
サイトへの各ビジターを固有識別情報で識別する。この
固有識別情報によって、ビジターは、多数のビジターが
同一ウェブサイトを訪問している間でも、このビジター
が他のウェブサイトを訪問しているときでも一貫して識
別される。

【００１１】ProReachは、ウェブビジターのより完全な
像を得るため、多数のウェブ行動からのデータを結合す
る。ProReachのビジター識別プロセスはウェブ全域で動
くので、ProReachはこれらの異なるウェブサイトからの
データを結合することができる。このことは、換言する
と、ウェブビジターがワールド・ワイド・ウェブ上であ
ちらこちらを見て回るときに、ProReachがこのウェブビ
ジターを繰り返し、一貫して識別し得ることを意味す
る。さらに詳細には、他のウェブ追跡用製品に対し、Pr
oReachシステムは、ウェブサーバーとウェブクライアン
トの両方に関するデータを収集する。ProReachは、ウェ
ブクライアントがシステム上にインストールできるダウ
ンロード可能なソフトウェアを配布することによって、
ウェブクライアントに関する情報を獲得する。このソフ
トウェアは、インストールされた後、ウェブユーザのマ
シーンからのウェブユーザの行動を追跡する。ウェブビ
ジターがウェブサイトを訪問するとき、ウェブビジター
の行動が記録される。周期的に、このデータのコンパク
ト版がProReachにアップロードされ、このユーザに関す
るプロフィール及びユーザグループ情報を保持する他の
ウェブサイトに配布される。

【００１２】したがって、各ウェブサイトでのユーザ行
動は、ユーザが相互作用を行ったウェブコンテンツの項
目、たとえば、ページビュー、購入などを識別するため
監視される。監視はウェブサーバー自体で行っても、ク
ライアント側のソフトウェアで行ってもよい。監視の中
には、ユーザがコンテンツを閲覧していた時間の長さに
関する情報と共に、たとえば、URL若しくはURIを用いて
ウェブコンテンツの各項目を識別することが含まれる。
これは、ウェブページを読むような時間のかかるウェブ
行動が非常に高いユーザ関心を反映しているので効果を
奏する。ユーザのコンテンツの項目との特別な相互作用
のデータはウェブイベントレコードに蓄積される。たと
えば、簡単な高速クリックスルーのようなウェブ行動は
ユーザ関心を有効に反映していないのでウェブイベント
レコードで追跡されない。ウェブビジターを識別し、ウ
ェブビジターが相互作用するウェブ内容を監視するこの
プロセスは、自動的かつ継続的に行われる。時間経過と
共に、多数のウェブイベントレコードが、多数のウェブ
ユーザによる多数のウェブサイトでの行動から作成され
る。

【００１３】ウェブサイトを閲覧するウェブビジターの
データが収集された時点で、このデータは未だビジネス
上の決定を行うために特に有用な形式ではない。たとえ
ば、一部のウェブビジターがたくさんのウェブサイトの
何百ものページを閲覧していることを知ることは、特に
有用ではない。しかし、ウェブビジターがどういう種類
の内容を閲覧しているか、たとえば、車、化粧品、ニュ
ース、技術情報、音楽CD,書籍などを閲覧しているかど
うかを知ることは非常に有用である。

【００１４】理想的には、ワールド・ワイド・ウェブ上
のあらゆる文書は、その文書がどういう内容に関するも
のであるかを簡単に記述した説明文が添付されている。
すなわち、この説明文は、たとえば、書籍が図書館で分
類されるのと同じように文書を分類する。しかし、この
ような理想的な状況が直ちに現実化するとは考えられな
い。そこで、ウェブビジターが閲覧する文書を自動的に
分類する方法が必要になる。この分類技術は、頑強性と
正確性と保守性とを備えるべきである。

【００１５】ProReachシステムは、まさにこの能力を具
備している。ProReachシステムは、そのためコンテンツ
認識エンジンを有する。コンテンツ認識エンジンは、文
書及びカテゴリーの組を選択し、文書がこれらのカテゴ
リーとよく一致する程度を計算するソフトウェアコンポ
ーネントである。コンテンツ認識エンジンを使用するこ
とにより、ProReachシステムは多種類のウェブ文書を分
類し、文書に与えられた階層的カテゴリーを含むカテゴ
リーのランク付けリストを生成する。基本的な考え方
は、コンテンツ認識エンジンが、所与の文書と一致する
カテゴリー若しくは一致しない一部のカテゴリーを評価
することである。コンテンツ認識エンジンは、文書をテ
ストし、各カテゴリーとどの程度一致しているかを示す
スコアを返却する。このプロセス中、文書は多数のカテ
ゴリーに対してテストされ、その結果として得られる分
類は、分類スコアのベクトルである。このベクトルの各
分類スコアは、当該文書がスポーツ、ニュース、あるい
は、コンピュータのような所与のカテゴリーにどの程度
一致しているかを示す。

【００１６】したがって、各ウェブイベントレコード
は、多数の定義済みのカテゴリーとの関連性を判定する
ため処理される。このカテゴリーは、広範なカテゴリー
及びトピックスを含む分類ツリーの形で維持される。好
ましくは、ウェブコンテンツは、カテゴリー毎にそのコ
ンテンツがカテゴリーに関して表現している程度を示す
ため得点化される。この分類は、ウェブマスタ若しくは
システム管理者による行動を要求することなく自動的に
行われる。

【００１７】分類プロセスの一部として使用されるカテ
ゴリー自体は、コンテンツ認識エンジンに与えられるデ
ータの一部である。ProReachは、好ましくは、ProReach
がインストールされ、特定のウェブサイトで動き始める
と直ぐに、システムがウェブコンテンツ分類できるよう
に、ターンキーカテゴリーを与える。一実施例におい
て、ターンキーカテゴリーは、特定のローカルProReach
システム装置と通信する集中ホストシステムから与えら
れる。ホストProReachシステムは、企業の情報システム
の体系を構築するビジネス（e-business）の実際的な情
報ニーズをターゲットするカテゴリーの包括的な組と、
それらのカテゴリーのサンプルデータとを与える。

【００１８】オプション機能として、ProReachシステム
のユーザは、カテゴリーを変更し、あるいは、専用カテ
ゴリーを作成することができる。このようにして、ProR
eachシステムを使用するウェブサイトは、潜在的顧客及
び顧客の閲覧習性をカスタム形式で分類することができ
る。ProReachシステムのユーザは新しい種類のカテゴリ
ーを作成するこができる。このカスタム化はオプション
であり、ユーザはカスタム化をしなくてもよい。ProRea
chは、カスタム化可能なターンキーシステムであるが、
カスタム化をしなくても利用できるシステムである。ま
た、ProReachは、カテゴリー作成やカテゴリー保守のプ
ロセスを支援するその他のツールも提供する。

【００１９】ウェブビジターの行動に関するデータはそ
れ自体でも価値があるが、ProReachは、このデータから
より意味のある情報を抽出する。電子商取引意思決定者
は、ユーザの心理学的、人口統計学的なプロフィールに
関心がある。電子商取引意思決定者は、ユーザ行動のあ
らゆる単独の細部を求めるのではなく、ユーザ行動の細
部から抽象化されたユーザの関心のサマリーを必要とす
る。そのため、ユーザ行動の全ての細部データが非常に
有意義なサマリーに圧縮されることが非常に望まれるよ
うになる。したがって、本発明は、各ユーザ及び異なる
グループの詳細なインターネットプロフィールと、情報
のカテゴリーを生ずるためにこの情報を更に処理する。

【００２０】本発明のProReachシステムは、ウェブ行動
収集のプロセスを用いてウェブビジターの行動のサマリ
ーを作成する。このプロセスを通じて、ProReachシステ
ムは、ビジターの行動の履歴を自動的に取得し、この履
歴を新たな訪問によって収集されたデータと一体的に統
合する。新たな訪問を取得し、これらを前の訪問と統合
するプロセスは、必要に応じて行われる。このようにし
て、ウェブビジターのプロフィールは、常に最新状態に
更新され、ウェブビジターの関心を反映する。

【００２１】より詳細には、ProReachは、ウェブビジタ
ーのウェブ行動データを３次元的に、すなわち、誰が
（身元）、いつ（時刻）、何を行ったか（コンテンツ分
類）に関して収集する。このプロセスは、次元の合成と
呼ばれる。これらの３次元の他に、ProReachは複雑な統
計ベースの集計を行う。

【００２２】ProReachシステムの別の長所は、ビジター
の行動を収集するアプローチがフレキシブルな点であ
る。異種の電子商取引は、ビジターの行動を異なる方法
で要約することを求める。その理由は、異なる企業が顧
客の特性を把握する異なるニーズをもつからである。

【００２３】ProReachシステムは、ProReachシステム管
理者によって調整され得る優れた集計能力を提供する。
集計プロセスを制御するパラメータを設定することが可
能である。パワーとフレキシビリティは合成される。こ
れらのパラメータは、保持される情報と、その情報を保
持するために許容される記憶容量とを制御する。

【００２４】本発明のこの局面において、所定のウェブ
サーバーに蓄積されたウェブイベントレコードは、最初
に、そのウェブサーバーの各ウェブユーザ毎に、好まし
くは、毎日のように一定間隔で周期的に収集された結果
の組に集計される。ユーザは、一日に何回も特定のウェ
ブサイトを訪問する場合があるので、個人ウェブイベン
トレコードがその都度生成される。同じことが多数の別
個のユーザについても当てはまる。したがって、ユーザ
毎に、そのユーザの全ての分類情報を集めるため、ウェ
ブイベントレコードが合成される。さらに、各ウェブイ
ベントレコード内のカテゴリースコア情報は、ウェブ行
動の間隔を反映させるため処理される。この処理によっ
て、カテゴリー重みの組が生成される。

【００２５】１日のような期間に収集された合成された
カテゴリーのカテゴリー重み付け情報は、多数のカテゴ
リーに亘るユーザの関心の程度を詳細に記述する。しか
し、ユーザ関心のより良く要約されたモデルを獲得する
ため、更なる処理が有益である。重み付きカテゴリー情
報から、種々の統計的測定量、たとえば、時間的な平均
カテゴリー重み、最大重み、最小重み、標準偏差などが
得られる。さらに、ユーザのカテゴリーに対する関心が
上昇中、下降中、又は、一定であることを表すトレンド
パターンが獲得される。時間区間的にカテゴリー重みに
関して要約された表現は蓄積され、その時間区間的に多
数のカテゴリーの全域でユーザ関心の変化がもっとも巧
く捕捉される。その結果として、基礎となるウェブイベ
ントレコードの未加工データは削除され、効率的な記憶
が実現される。

【００２６】第一に、周期的情報は、より長い時間に亘
って各カテゴリーに関するユーザ毎に集計される。たと
えば、ユーザに関して毎日集計された情報は、週毎の時
間的区間、１月毎、３ヶ月毎、１年毎などのより長い時
間で更に集計される。これにより、いわゆる「ユーザ・
カテゴリーコンプレックス」が形成され、多数の異なる
日からの単一のカテゴリーに関する統計的情報は集計関
数によって合成される。一例として、集計関数は平均化
である、特定のカテゴリーに関する時間的なカテゴリー
重みの平均がトレンドパターン及びその他の統計的測定
量と共に獲得される。

【００２７】第二に、次元結合は、カテゴリーコンプレ
ックスを形成するため使用される。カテゴリーコンプレ
ックスは、選択された時間的区間の間に特定のカテゴリ
ーにおける多数のユーザ関心を要約する。カテゴリーコ
ンプレックスは、特定のカテゴリーのおけるユーザの集
団の時間的な関心のレベルを記述する。

【００２８】別のタイプの次元結合は、ユーザ・カテゴ
リーコンプレックスを使用する。第一に、個別のユーザ
に対する多数のユーザ・カテゴリーコンプレックスは、
選択された時間的区間の間に結合され、ユーザの全体的
な関心の集計された見解を形成する。すなわち、多数の
異なるカテゴリーからのカテゴリー情報が集計され、ユ
ーザの全体的な関心を記述する。

【００２９】さらに、ユーザ・カテゴリーコンプレック
スは、ユーザグループ・カテゴリーコンプレックスを形
成するため、個別のカテゴリーと、ユーザグループを形
成する選択されたユーザとに関して結合してもよい。ユ
ーザグループメンバーは、ユーザのカテゴリー関心とオ
プションとして人口統計学とに基づくある種のメンバー
シップテストに合致することによって選択される。これ
により、そのカテゴリーについての時間的なユーザグル
ープの関心のサマリーが得られる。

【００３０】ユーザコンプレックスは、全てのカテゴリ
ーにおける全体的なグループ関心を記述するため、ユー
ザグループコンプレックスに結合されうる。最終的に、
グループコンプレックスは、選択された時間的区間の間
に全カテゴリー域での総集団の関心を記述する全体的な
総コンプレックスを形成するため集計される。

【００３１】集計される多数のコンプレックスの他に、
ユーザの個別のプロフィールは、ユーザグループ情報が
更に追加される。特定のメンバーシップ基準を有する多
数のユーザグループが定義される。商取引者は、関心を
共有するユーザのグループ、購買傾向、又は、人口統計
学を定義することができる。メンバーシップ基準は、好
ましくは、一つ以上のカテゴリーに対し、特定のレベル
若しくは範囲のカテゴリー重みを持つ（又は持たない）
ユーザに基づく。ユーザは複数のユーザグループのメン
バーでもよい。グループメンバーシップは、ユーザが規
定時間以上、ウェブコンテンツと相互作用したとき、並
びに、ユーザの関心がカテゴリー重みのレベル変化によ
って表されるように変化するときに、自動的に更新され
る。ProReachシステムは、ユーザのプロフィールに基づ
いて、ユーザを正しいユーザグループに自動的に分類す
る。ユーザグループの定義が変化したとき、ProReachシ
ステムは、ユーザを正しいユーザグループに自動的に再
分類する。同様に、ユーザの関心が変化すると共に、ユ
ーザは新しい関心に基づいて正しいビジターセグメント
に自動的に収容される。このように、商取引者は、オン
デマンドでマーケットセグメントに直接アクセスし、電
子セールスキャンペーンを迅速に実施することができ
る。

【００３２】ProReachシステムが生成するビジタープロ
フィール情報は、その情報を作成したウェブサイトの単
独の用途及び利益のため確保される。ProReachシステム
は、ユーザプロフィール情報を共有してもよい。この共
有化を容易に実現するため、ProReachは、ProReachシス
テムが相互に情報の転送の方針を決めるのを補助する集
中サービスを提供する。相互により深い関係を必要とす
るProReachの顧客に対し、本発明はアライアンス（同盟
機構）を提供する。アライアンスは、ユーザプロフィー
ルをプロフィールデータベースに供与することが決めら
れたProReachシステムのグループである。アライアンス
の全メンバーはプロフィールを供与し、アライアンスの
全メンバーはアライアンスプロフィールへのアクセス権
を取得することにより恩恵を授かる。特に、アライアン
スは、企業がワールド・ワイド・ウェブ上で一体的に仕
事をしようとする垂直的に統合されたマーケットで有用
である。このような企業のグループは、情報を結合する
ことにより利益が得られるが、共有化を促進し、調整
し、確実なものとするため、基盤構造を必要とする。Pr
oReachは、共有化を可能にさせる基盤構造を提供する。
アライアンスにおいて、各メンバーは、ビジターに対し
て作成されたビジタープロフィールをメンバーのウェブ
サイトに供与する。これらの供与されたプロフィール
は、アライアンスにより維持されるプロフィールのデー
タベースに一体的に収集される。このアライアンスへの
全メンバーは、これらのプロフィールへの条件付きアク
セス権を取得する。共有ルールのシステムは、全体的な
共有プロセスを制御するので、企業は選択された情報だ
けを共有する。ProReachは、多数のアライアンスの情報
を支援する。ProReachを使用可能なシステムは、二つ以
上のアライアンスに所属することが可能である。

【００３３】非常に多量のビジター行動データは、ProR
eachシステムを使用するウェブサイトによって生成され
る。このデータの存在は、プライバシー事項を増加させ
る。また、このデータは、ProReachシステム自体がシス
テム間でデータを共有する方法に関する問題を生じさせ
る。ProReachは、プライバシー事項を扱うアーキテクチ
ャーを具備する。ProReachは、いわゆる身元情報ファイ
アウォールを用いてウェブビジターのプライバシーを保
障する。身元情報ファイアウォールの目的は境界を確定
することである。身元情報ファイアウォールの境界の内
側で、ウェブビジターの身元は、許可を得た人又はプロ
セスにアクセス権がある。電子メールアドレス、ホーム
ページアドレス及び年齢のような他の個人情報も利用可
能である。

【００３４】身元情報ファイアウォールの境界の外側で
は、ウェブビジターを識別するため使用できる情報は与
えられない。実際上、身元情報ファイアウォールの外側
で情報を要求する人若しくはプロセスは、不透明なビジ
ター識別子しか得られない。不透明なビジター識別子を
発行するProReachシステムは、ウェブビジターを個別に
識別するためそのビジター識別子を使用することができ
る。したがって、不透明なビジター識別子は、ProReach
ビジターへの外部参照可能な名前である。

【００３５】不透明なビジター識別子を備えた人若しく
はプロセスは、不透明なビジター識別子をPrpReachシス
テムに提示することができる。ProReachシステムは、不
透明なビジター識別子を実際のビジターに割り当てる。
この方法を用いることにより、ウェブ商取引者は、たと
えば、ウェブビジターの関心に関する多量の情報を得る
ことができるが、商取引者はビジターの身元情報や連絡
先情報はわからない。ウェブ商取引者は不透明なビジタ
ー識別子（若しくは、ビジター識別子の組）しか与えら
れない。商取引者は自分が必要とする情報を取得する
が、ビジターのデータのプライバシーは保護される。し
たがって、身元情報ファイアウォールの外側で、ProRea
chによって追跡されるウェブビジターは匿名である。

【００３６】ウェブ商取引者は、IProのビジター交信サ
ービス（Visitor Contact Service）を用いて自分の代
わりにProReachシステムをウェブビジターと交信させ
る。不透明なビジター識別子及びメッセージが与えられ
た場合、ビジター交信サービスは電子メールアドレス
（又は、その他の必要な情報）を参照する。次に、ビジ
ター連絡サービスは、メッセージをウェブビジターに送
信する。ウェブ商取引者は、自分のメッセージをウェブ
ビジターへ配信させるが、ウェブ商取引者はウェブビジ
ターの身元情報を知らない。

【００３７】身元情報ファイアウォールはフレキシブル
に構成することができる。身元情報ファイアウォール
は、単一のProReachシステムを取り囲むように構成する
ことが可能である。身元情報ファイアウォールは、ProR
eachシステムのグループを取り囲むように構成してもよ
い。ProReachシステムのグループを取り囲む構成は、
（たとえば、多数のサーバーを備えたポータルの場合
に）グループとして働く多数のProReachサーバーが存在
し、データがサーバー間で共有されるべき場合に意味を
もつ。

【００３８】

【発明の実施の形態】本発明の好ましい実施例を以下の
順序で説明する。 Ｉ．ウェブイベント及び集計 Ａ．ウェブイベントレコード ＩＩ．ＰｒｏＲｅａｃｈシステムアーキテクチャーの概
要 Ａ．グローバルサービス ＩＩＩ．基本システム処理 Ａ．ＰｒｏＲｅａｃｈ機能的概要 Ｂ．カテゴリー発見及び保守 １．カテゴリー発見 ２．カテゴリー保守 ＩＶ．アライアンスを含むＰｒｏＲｅａｃｈシステム Ｖ．集計 Ａ．毎日のウェブイベント集計 １．カテゴリースコアの重みへの変換 ２．ユーザによるカテゴリー重みの順序付けのためのウ
ェブイベントレコードの再構成 ３．カテゴリー関心時間モデル情報の作成 Ｂ．次元結合 Ｃ．ユーザグループシステム Ｄ．毎日の集計 Ｅ．アフィニティグループマネージャ Ｆ．更新オブジェクト Ｇ．スケジューラ Ｈ．イベントディスパッチャ Ｉ．プロフィールシステム Ｊ．ＡＱＬシステム １．ＡＱＬ言語 ２．ＡＱＬインタープリタ ＶＩ．カテゴリー及び分類 Ａ．分類の概要 Ｂ．カテゴリー及び階層組織データ １．カテゴリー階層の構築及び維持 Ｃ．カテゴリー名及びＩＤ １．デフォルト変更不可ユーザ・カテゴリー構造 ２．カテゴリーとグループの類似性及び相違性 Ｄ．分類におけるソース及びロケーションの使用 Ｅ．コンテンツカテゴリーライフサイクル：形成、調整
及び変更 １．標準カテゴリーツリーと、ＰｒｏＲｅａｃｈシステ
ム管理者による追加 ａ）ＰｒｏＲｅａｃｈシステムでのカテゴリーの追加 ｂ）標準カテゴリーツリーの更新 ｃ）標準カテゴリーツリーの構築 ｄ）カテゴリーの発見、改良及び編集 Ｆ．コンテンツ認識エンジンの分類モデル １．カテゴリー作成 ２．文書分類 ３．多重辞書分類 ４．カテゴリーキャッシュ ＶＩＩ．グローバルサービス Ａ．グローバル識別子（ＧＩＤ）サービス １．ＧＩＤ要求 ２．ＰＩＤを用いた個人識別 Ｂ．グローバルアップロードサービス Ｃ．グローバルクライアント管理サービス Ｄ．イエローページ Ｅ．グローバル交換手段 ＶＩＩＩ．ＰｒｏＲｅａｃｈクライアント側のウェブ使
用データ収集 Ａ．ウェブ行動監視 Ｂ．ＰｒｏＲｅａｃｈクライアントウェブ使用データの
フィルタ及び集計 １．時間ベース統合 ａ）ウェブイベントレコードタイムスタンプの調整 ｂ）短時間行動の無視 ｃ）ウェブ行動の集計 ２．他のデータのフィルタ ３．プライバシー制御 Ｃ．プライバシー設定値（ユーザ変更可能）に基づくフ
ィルタ １．ＵＲＬパターンベースフィルタ ２．キーワードベースフィルタ Ｄ．デフォルトプライバシー関連フィルタ Ｅ．ＰｒｏＲｅａｃｈクライアントデータアップロード １．ＰｒｏＲｅａｃｈクライアントアップロードキュー ２．ＰｒｏＲｅａｃｈアップロードストリーム及びアッ
プロードレコード ３．データアップロード ａ）ウェブイベントレコードアップロード ｂ）ホームページＵＲＬアップロード ４．時間のアップロード及びアップロードステージ ａ）プレアップロードステージ ｂ）アップロードステージ ｃ）ポストアップロードステージ ５．ＰｒｏＲｅａｃｈアップロードサービス及びアップ
ロード ＩＸ．コンテンツターゲッティング Ａ．ＣＧＩによるプロフィールへのアクセス １．ＣＧＩによるページメタデータへのアクセス ａ）実行時におけるマルチパートページの動的コンテン
ツ分類の取り扱い以下、本発明の実施例を詳細に説明す
る。

【００３９】Ｉ．ウェブイベント及び集計 図１を参照するに、ウェブコンテンツ内でウェブビジタ
ーの関心を測る基本モデリングユニットとして使用され
るウェブイベントの概念説明図が示されている。ウェブ
イベント１０１は、３種類の情報の結合体である。第一
に、ウェブイベント１０１は、特定のウェブビジター１
０３、すなわち、一般的に、「ユーザ」を個別に識別す
る情報を含む。このユーザは、個人でも、ユーザが所属
していると考えられる個人のグループでもよい。第二
に、ウェブイベント１０１は、ウェブビジターがウェブ
コンテンツを閲覧し、あるいは、ウェブコンテンツと相
互作用する際に消費した時間の長さを記述する情報１０
７若しくは測定量を含む。

【００４０】第三に、ウェブイベント１０１は、一つ以
上のカテゴリー１０５を識別する情報を含む。カテゴリ
ーにはウェブビジターが訪れたウェブコンテンツが属
し、カテゴリー毎にユーザの関心の測定量が含まれる。
ウェブコンテンツを記述するため使用されるカテゴリー
は、好ましくは、カテゴリーの階層を形成し、親カテゴ
リー（たとえば、「スポーツ」）は、多数の子カテゴリ
ー（たとえば、「サッカー」及び「ゴルフ」）をもつ。

【００４１】これらの３種類のデータは、ウェブコンテ
ンツの項目を閲覧し、あるいは、項目と相互作用するユ
ーザは、そのウェブコンテンツに関するカテゴリーに
「関心（興味）」を抱いていることを表現しているとい
う基本的なアイデアをモデル化するため使用される。ビ
ジターがウェブコンテンツを閲覧、相互作用する時間が
長くなるほど、ビジターの関心が高くなると考えられる
（勿論、関心のレベルを測るためには、単にページを眺
めるだけ、あるいは、商品を購入するなどの相互作用タ
イプのようなその他の要因も使用される）。

【００４２】特定の時刻若しくは間隔におけるあるカテ
ゴリーへのユーザの関心の測定量は、以下の説明では、
「重み」と呼ぶ。重みは、ウェブコンテンツの項目と相
互作用するビジターが費やした時間の長さと、カテゴリ
ーがそのコンテンツを記述していると思われる程度との
関数である。多数のカテゴリーが利用できる好ましい一
実施例において、ウェブイベントはカテゴリー毎に重み
を含む。これは、ウェブコンテンツの所与の項目が多数
のカテゴリーに異なる度合いで関係する事実を反映して
いる。

【００４３】これらの重みの解釈の重要な尺度、すなわ
ち、カテゴリーへの関心のレベルを与えるため、重み
は、相互作用ユニットと呼ばれる標準ユニットに応じて
決められる。相互作用ユニットは、ユーザがコンテンツ
の項目に１分間の注意を払ったことを意味する。相互作
用ユニットを用いてウェブイベントを測ることにより、
多種多様なユーザの関心及びウェブコンテンツのカテゴ
リーを有意に比較することができる。

【００４４】上記３通りの情報は、特定のウェブサイト
でウェブビジターが訪れたウェブコンテンツの項目ごと
に収集され、多数のウェブサイトに亘る多数の異なるビ
ジターによって拡張される。たとえば、ビジターが所与
のウェブサイト上であるウェブページから別のウェブペ
ージに移動するとき、ビジターを識別する情報と、ペー
ジのカテゴリー説明と、ページ上でビジターが費やした
時間の長さとをカプセル化したウェブイベントが生成さ
れる。同じビジターが異なるウェブサイトを訪れると
き、ビジターは識別され、コンテンツのカテゴリーと、
このコンテンツの閲覧に費やされた時間とを獲得したウ
ェブイベントが生成される。

【００４５】ウェブイベント自体は、単に個別のデータ
項目であり、個々のユーザ若しくはユーザグループの関
心の全体的なパターン、又は、カテゴリー若しくは時刻
に関するパターンを直接的に記述するものではない。こ
の抽象化のレベルは、本発明の第２の局面である集計に
よって与えられる。一般的に説明すると、集計は、関心
のパターンを確定するためウェブイベントの異なるグル
ープの重みを要約するプロセスである。一般的に、ウェ
ブイベントは、時間的区間、個別のユーザ、ユーザのグ
ループ、カテゴリーのグループ、あるいは、これらの組
み合わせに関して結合され得る。全体をまとめて考慮す
ると、ウェブイベントを結合するには以下の６通りの方
法がある。

【００４６】方法１）二つの日付の間で全ウェブイベン
トを結合する。この結合方法は、ユーザの集合の総合的
な関心、すなわち、グローバル関心のモデルを得るた
め、所定の時間的区間に亘る全カテゴリー及び全ユーザ
に関するウェブイベントを結合する。

【００４７】方法２）二つの日付の間であるカテゴリー
に対する全ウェブイベントを結合する。この結合方法
は、特定のカテゴリーに関するユーザの関心のレベル及
びパターンのモデルを得るため、所定の時間的区間に亘
る全ユーザに関する特定のカテゴリー（又は、カテゴリ
ーのグループ）に対するウェブイベントを結合する。

【００４８】方法３）二つの日付の間であるユーザ及び
あるカテゴリーに関するウェブイベントを結合する。こ
の方法は、特定のカテゴリーに関するユーザの関心のレ
ベル及びパターンのモデルを得るため、所定の時間的区
間に亘って特定のユーザ及び特定のカテゴリーのウェブ
イベントを結合する。

【００４９】方法４）二つの日付の間であるユーザグル
ープ及びあるカテゴリーに関するウェブイベントを結合
する。この方法は、特定のカテゴリーに関するユーザグ
ループの関心のモデルを与える。

【００５０】方法５）全カテゴリーを通じて二つの日付
の間で特定のユーザに関するウェブイベントを結合す
る。この方法は、全カテゴリーに対するユーザの関心の
全体的な分布の様子と、ウェブサイトに保持されている
一つ乃至少数の狭いカテゴリーに関心があるか、あるい
は、ウェブサイトの多数のカテゴリーに広範な関心があ
るかどうかを説明する。

【００５１】方法６）全カテゴリーを通じて二つの日付
の間でユーザグループに関するウェブサイトを結合す
る。

【００５２】一実施例において、上記の種々のタイプの
結合を行うとき、所定の時間的区間中に選択されたイベ
ントは、その時間的区間内に始まったイベントであり、
選択された時間的区間後に終了するイベントも含まれ
る。

【００５３】このような種々の方法でウェブイベントを
結合するプロセスは、ウェブイベントを結合するために
使用される次元がデータ内に６次元存在するので、以下
の説明では「次元結合」と呼ぶ。これらの実施可能な結
合方法は、時間的な期間中にあるカテゴリーに関するユ
ーザ若しくはグループの関心を分析する。図２を参照す
るに、ウェブイベントを結合する種々の方法が示されて
いる。

【００５４】図２に示された多数の離散的なウェブイベ
ント１０１は、ある時間的区間、たとえば、長い日数に
発生する。１日毎のウェブイベント１０１は全てユーザ
固有の毎日集計される結果２０１に集められる。これら
の毎日集計される結果２０１は、同図ではレベル０のよ
うに表される。ウェブビジターの関心を理解するため、
ある日数（たとえば、１週、１ヶ月、３ヶ月、１年な
ど）に亘るウェブイベントは、上述の通り種々の方法で
結合される。

【００５５】最初に、レベル１において、毎日の集計
は、上述の方法３）にしたがって、ＵＣ（ユーザ・カテ
ゴリー）コンプレックス２０３に結合され、あるいは、
方法２）にしたがって、Ｃ（カテゴリー）コンプレック
ス２０５に結合される。１日毎に集計された結果１０１
は、コンプレックス２０３とコンプレックス２０５の両
方に寄与することに注意する必要がある。すなわち、特
定のウェブビジターのウェブ行動は、そのビジター行動
による影響を受ける全てのカテゴリーに対するカテゴリ
ーコンプレックス２０５と、種々のカテゴリーに対する
ユーザの関心のレベルを記述するユーザ固有のユーザ・
カテゴリーコンプレックス２０３とに寄与する。

【００５６】次に、レベル２では、個々のＵＣコンプレ
ックスが結合される。第１に、上述の方法４）にしたが
って、ユーザグループを形成するあるユーザについての
特定のＵＣコンプレックスがＧＣ（グループ・カテゴリ
ー）コンプレックス２０６に結合される。このコンプレ
ックス２０６は、そのデータに関する特定のカテゴリー
へのグループの関心を記述する。第２に、上述の方法
５）にしたがって、特定のユーザに対するユーザ・カテ
ゴリーコンプレックスの全てが単一のＵ（ユーザ）コン
プレックス２０７を形成するため結合される。このユー
ザコンプレックス２０７は、カテゴリーの全域における
ユーザ関心を要約する。ユーザコンプレックス２０７
は、特に、ユーザ関心の広さ若しくは狭さを測るため有
用である。たとえば、ウェブサイトがコンテンツのカテ
ゴリーを制限される場合を考える。このウェブサイトの
一人のユーザについて、ユーザコンプレックス２０７は
１乃至２個のカテゴリーだけに高レベルの関心を示し、
他のユーザのユーザコンプレックス２０７は大多数のカ
テゴリーに高レベルの関心を示す。この２番目のタイプ
のユーザは、商取引の目的のため、若しくは、その他の
価値駆動型行動のためのウェブサイトにとって大切であ
る可能性が高い。

【００５７】次に、レベル３では、個別のユーザのため
のコンプレックス２０７が上述の方法６）にしたがっ
て、全てのカテゴリーを通じてＧ（グループ）コンプレ
ックス２０９に結合される。

【００５８】最後に、レベル４において、多数のグルー
プからのコンプレックス２０９が上述の方法１）にした
がって、全ユーザの全カテゴリー域への関心を記述する
Ｔ（総合）コンプレックス２１１に結合される。

【００５９】このウェブイベントモデリング及び集計の
枠組みは多数の有利な特徴を与える。第一に、システム
管理者（若しくは、ProReachシステムのメンバー）は、
ユーザ関心の時間的パターンのより広い分析又はより狭
い分析を獲得するために集計が行われる時間的区間を自
由に選択することができる。これは、非常に短期間の関
心の傾向、又は、より長期間のユーザ関心の傾向を識別
するため有用である。第二に、集計の各レベルは下位レ
ベルの情報を完全に獲得するので、下位レベルのウェブ
イベントデータは記憶効率を高めるため選択的に消去し
ても構わない。たとえば、（小さい重みによって確認さ
れる）非常に低いレベルの関心しかないカテゴリーに関
するウェブイベントは、そのデータがＵＣデータ若しく
はＣデータ中に要約された後、消去してもよい。より大
きい重みをもつウェブイベントは、より多くの分析若し
くは販売のため使用できるように、より長期間記憶され
る。

【００６０】Ａ．ウェブイベントレコード ウェブビジターが、ユニフォーム・リソース・ロケータ
（ＵＲＬ）のコンテンツを閲覧したり、あるいは、ウェ
ブ取引を開始するサブミットボタンをクリックするよう
なウェブ行動を実行するとき、このウェブ行動は、クラ
イアント側又はサーバー側のトラッカーによって記録さ
れ、ウェブイベントが記録される。各ウェブイベントの
データはウェブイベントレコードに蓄積される。ウェブ
イベントレコードは、次に、毎日集計される結果１０１
に集計され、その結果から多数のコンプレックスが得ら
れる。ウェブイベントレコードの基本的な特徴は以下の
通りである。

【００６１】

【表１】 たとえば、ユーザのウェブ行動として以下の行動を考え
る。

【００６２】

【表２】 ウェブイベントレコードは、ウェブクライアント１０８
若しくはウェブサーバー１０２によって生成される。ウ
ェブクライアント１０８上で生成された場合、対応した
ウェブイベントレコードは以下の通りである（ユーザＩ
Ｄ及びカテゴリ−スコア情報は示されていない）。

【００６３】

【表３】 注１：URLが取得されたとき、現在時刻がウェブイベン
トレコード内の標準時刻タイムスタンプフィールドに記
憶される。現在時刻と、前のレコードのタイムスタンプ
内の時刻との差が計算され、前のレコードの間隔フィー
ルドに記憶される。

【００６４】注２：間隔は、終了時刻−開始時刻に一致
する場合と一致しない場合とがある。その理由は、この
URLへの最先のダウンロードと最新のダウンロードの間
に他のイベントが存在し得るからである。たとえば、<U
RL B>と<URL C>のビジットの間に２分のギャップがあ
る。行動テーブル内の間隔フィールドは、ユーザが特定
のURLをブラウズ（読む）際に費やした実際の時間を示
し、一方、ウェブイベントレコード内の間隔フィールド
は、その時間の近似である。ウェブイベントレコードが
ウェブクライアント１０８によって作成された場合、ク
ライアントソフトウェアは、現在URLの終了時刻として
次のURLの開始時刻を選ぶことにより現実の間隔を近似
するだけである。ソフトウェアは、ユーザの介入なくし
て、URLビジットの間のアイドルギャップを知る方法が
ない。ウェブイベントレコードがユーザを追跡するウェ
ブサーバー１０２によって生成されるとき、その間隔を
推定することができる。

【００６５】注３：ここで、<URL E>に対する間隔は、
ウェブクライアント１０８によって、13分50秒(10:30-1
0:16:10=00:13:50)として計算される。ウェブクライア
ント１０８は、<URL E>へのアクセス後のアイドル時間
がわからない。しかし、ウェブクライアント１０８（若
しくは、ウェブサーバー１０２）は、単一のURLアクセ
スの間隔に対し予め設定された最大時間、たとえば、5
分間を保持する。これは、唯一のURLアクセスが異常に
大きい間隔をとることがないように、間隔因子を正規化
するためにある。ユーザは、２回のURLアクセス間にし
ばらくの期間、他の行動に拘わり、その結果として、異
常に長い間隔の数値を生じる場合がある。このような異
常に長い間隔の数値は、ユーザのウェブ使用状況パター
ン及びプロフィールを不正確にする影響がある。しか
し、累算的間隔は、最大間隔数値には制限されないこと
に注意する必要がある。たとえば、<URL A>の間隔は、
二つの別々のURLアクセスの集計であるので、5分間の限
界によって制限されない。

【００６６】注４：行動５、７及び８は、時間的区間が
非常に短いため取り除かれるので、いずれのウェブイベ
ントの合計間隔にも含まれない。このような短時間の閲
覧はユーザの実際の関心を示す可能性が少ないので、短
時間の行動を間隔から除くことはデータ収集要求量を減
少させるため役立つ。

【００６７】次節では、ウェブイベントを記録し、上述
のデータを集計する多数の能力を与えるシステムのアー
キテクチャー及び機能性を説明する。

【００６８】ＩＩ．ＰｒｏＲｅａｃｈシステムアーキテ
クチャーの概要 本発明は、ProReachと呼ばれるシステムに組み込まれ
る。最初に、ProReachアーキテクチャーの非常に上位レ
ベルの概要を説明し、次に、このアーキテクチャーに含
まれる上位レベルの構成要素について説明し、これらの
構成要素間の上位レベルの関係を示す。また、ProReach
のいくつかの典型的なコンフィギュレーションを説明
し、ProReachがファイアウォールの向こう側にある一つ
以上のウェブサーバーをファイアウォールを通してサポ
ートする方法を説明する。アライアンスの基本要素の説
明もなされる。

【００６９】図３を参照するに、インターネット経由で
動作する多数のProReachシステム１００が示されてい
る。各ProReachシステム１００は、１台以上のウェブサ
ーバー１０２を扱う。これらのウェブサーバー１０２
は、全て同じドメインに属してもよく、あるいは、別の
ドメインに属してもよい。図３には、二つのProReachシ
ステム１００が示されている。一方のProReachシステム
１００は、１台のウェブサーバー１０２をサポートし、
もう一方のProReachシステム１００は２台のウェブサー
バー１０２をサポートする。同図には、全部で３台のPr
oReach使用可能ウェブサーバー１０２がある。

【００７０】ProReachシステム１００の各ProReach使用
可能ウェブサーバー１０２は、ウェブサーバー１０２が
サービスを提供するウェブサイトで個別のウェブビジタ
ーのウェブビジットを追跡する。ウェブサーバー１０２
は、ウェブビジターを追跡、識別し、閲覧されたコンテ
ンツに対するカテゴリー情報を獲得し、ビジットの時刻
及び間隔を含むログを記録する。このデータが収集され
た後、ProReachシステム１００は、ウェブビジターを評
価するためデータを分析し、ウェブビジターのプロフィ
ールを作成若しくは更新する。これにより得られたユー
ザのプロフィール（又は、ユーザのビジットによる影響
を受けたその他のプロフィール）が販売目的、ページ編
集、若しくは、バーナー広告の推進のため使用され得
る。

【００７１】多数のProReachシステムは、ProReachグロ
ーバルサービス１１０を利用する。グローバルサービス
１１０は、情報の効率及び真正の観点から高度に集中さ
れた多数のタスクを実行する。以下に更に説明されるグ
ローバルサービス１１０には、ウェブビジターの識別、
標準化カテゴリーの保持及び多数のシステムへの配信、
並びに、システム１００間で情報を交換するメカニズム
が含まれる。

【００７２】図３には、２台のウェブクライアント１０
６及び１０８が示される。ウェブクライアントは、Nets
cape Communicatior^(R)又はMicrosoft Internet Explor
er^{(R )}のようなウェブブラウザを含む通常のコンピュー
タである。ProReachは、既存のウェブブラウザと統合さ
れ、本発明の特徴若しくは効果を得るために特別のブラ
ウザは必要とされない。しかし、選択的な改良として、
一部のウェブクライアント１０８はProReach使用可能で
ある。すなわち、クライアント１０８はクライアント側
の追跡ソフトウェアを実行する。周期的に、ProReach使
用可能クライアント１０８は、ウェブ行動のデータをア
ップロードするため、特に、ProReachシステム１００を
持たないウェブサイト上のウェブクライアントのユーザ
のウェブイベントを追跡するため、ProReachグローバル
サービス１１０を自動的に使用する。この特徴によっ
て、ProReachシステム１００及びサーバー１０２におけ
るユーザの行動だけでなく、ユーザの全てのウェブ行動
に関する情報を統合できるので、ユーザ関心の非常に完
全な観察が行える。ProReachグローバルサービス１１０
は、このクライアントデータを多数のProReachシステム
１００に送信する役割を担う。

【００７３】図４を参照するに、多数のウェブサーバー
１０２をサポートするため、各ProReachシステム１００
は、ハブ２０４と１台以上のスポーク２０２とを含むハ
ブ及びスポークトポロジーで構成される。各ハブ及びス
ポークは、実行可能なソフトウェアモジュールの集まり
である。全体として、ProReachシステム１００は、４台
のPentium^（R）II Xeon^TMプロセッサと８GBのメモリと
を具備した大規模ウェブホスト用サーバーであるFujits
u teamserver M800i シリーズサーバーのような企業サ
ーバークラスハードウェア上で動く。ソフトウェア環境
は、好ましくは、オペレーティングシステムとしてMicr
osoft Windows NT 4.0を含み、ウェブサイト管理用のMi
crosoft^（R） Internet Information Server^(R) 4.0 (I
IS)と、ファイアウォール管理用のMicrosoft Proxy Ser
ver 2.0と、コンテンツ管理並びにユーザ及びグループ
プロフィールに基づく配信用のMicrosoft Site Server
3.0とを含む。

【００７４】より詳細には、各スポーク２０２は、ウェ
ブサーバー１０２からのビジターデータを収集し、分類
するために設けられる。データがウェブサーバー１０２
から収集された後、データはスポーク２０２上で部分的
に処理される。部分的に処理されたデータは、スポーク
２０２からハブ２０４に移される。ハブ２０４で、デー
タが集計され、最新のビジタープロフィールを生成する
ため分析される。同じウェブビジターからのデータは、
異なるスポーク２０２から送られてくるが、ハブ２０４
はこのデータを適当なユーザプロフィールに集計するこ
とに注意する必要がある。

【００７５】ProReachは、殆どのProReachサービスが企
業ファイアウォール内に含まれるように構成される。ウ
ェブサーバー１０２自体は、ファイアウォールの外側に
ある。単一のウェブs-バー用のProReachシステム１００
を含む典型的なProReach構造は、図５に示されている。
ProReach使用可能ウェブサーバー１０２はファイアウォ
ール２０６の外側にある。ProReachスポーク２０２は、
ウェブサーバー１０２に接続され、Javaサーブレットの
ようなサーバー側プラグインを用いて通信を行う。ProR
eachスポーク２０２自体は、上述のようにProReachハブ
２０４に接続される。図５には、一つのスポーク２０２
しか示されていないが、既に説明した通り、それぞれが
専用のウェブサーバー１０２をサポートする多数のスポ
ーク２０２を使用してもよい。ProReach使用可能クライ
アント１０８は、ProReachを含まない非ProReachウェブ
サーバー１１３におけるユーザビジットを追跡し、蓄積
した使用状況データをProReachグローバルサービス１１
２に送信する。次に、ProReachグローバルサービス１１
２は、使用状況データを適当なProReachシステム１００
に回送する。図５には、ProReachシステム１００が他の
ProReachシステム１００と協働する方式が示されてい
る。一方のProReachシステムのハブ２０４が別のProRea
chシステム１００と通信する方式に注意する必要があ
る。このような通信はシステム１００の間でのデータの
共用を扱うことができる。

【００７６】ProReachは、ウェブファイアウォール２０
６を越えて働く。たとえば、企業が２台のウェブサーバ
ー１０２を有し、それぞれのウェブサーバーが固有ドメ
イン名及びファイアウォール２０６をもつ場合を考え
る。それらのウェブサイトにおいて、全ウェブビジター
を追跡することが望ましい。この場合、異なるProReach
の構造、すなわち、一つのスポーク２０２がローカルハ
ブ２０４に取り付けられ、他のスポーク２０２は遠隔地
にあり、別のファイアウォール２０６の向こう側にある
構造が使用される。ProReachがファイアウォールを越え
て作用することができる能力は、特に、異なる組織若し
くは企業に属するウェブサイトが論理ユニットとして一
体としてグループ化され、それらのウェブビジターのデ
ータが共用されるべき場合に望まれる。

【００７７】Ａ．グローバルサービス 一実施例において、ProReachは、多数のグローバルサー
ビス１１２を提供する。これらのサービスは、マスター
・ホスト・システム及びサーバーによって提供され、た
とえば、ProReachシステム１００の総合的なプロバイダ
によって与えられる。このグローバルサービスは図６に
示されている。

【００７８】グローバル識別子サービス６０２は、グロ
ーバル識別子[GID]を割り当て、ビジター識別情報に関
連した他の機能性を実現する。GIDは、ウェブビジター
を大域的に識別するため使用され、これにより、ビジタ
ーのウェブイベント及びその他の使用状況データは、多
数の異なるProReachシステム１００又はProReach使用可
能ウェブクライアント１０８から受信されたとき、適切
に順番に揃えられる。

【００７９】グローバルカテゴリーツリーサービス６０
４は、標準的なカテゴリーの収集物を保持し、配信す
る。これにより、異なるProReachシステム１００は、ウ
ェブコンテンツを説明し、分類するため共通のカテゴリ
ー集合を使用する。このように、多数のウェブサイトか
らの関心情報は、カテゴリーの共通フレームワークに対
して測定され、評価される。

【００８０】グローバルアップロードサービス６０６
は、多数のProReach使用可能ウェブクライアント１０８
からアップロードされたウェブ行動データを受信するた
め、クライアント追跡ソフトウェアと共に動作する。こ
のグローバルサービスは、ウェブ行動データを適切なPr
oReachシステム１００に配信する。

【００８１】グローバルクライアント管理サービス６０
８は、全てのRroReach使用可能ウェブクライアント１０
８のリストを保持し、このリストを保守することにより
（たとえば、新しいProReach使用可能ウェブクライアン
ト１０８を追加し、動作しなくなったウェブクライアン
トを削除することにより）、ProReach使用可能ウェブク
ライアントの管理を助ける。

【００８２】グローバルイエローページ６１０のサービ
スは、ProReachシステム１００のLDAPディレクトリを保
持する。

【００８３】グローバル交換手段サービス６１２は、個
々のProReachシステム１００が、他のProReach使用可能
システム１００とウェブビジター情報を交換するための
ビジネス規則を記述する。

【００８４】ＩＩＩ．基本システム処理 ProReachの役割は、ユーザデータを取得し、ユーザデー
タを分析し、個別のビジター若しくはビジターの集合的
なグループに対するビジタープロフィールサマリーを生
成することである。ビジタープロフィールサマリーは、
所与のウェブビジター若しくはグループの関心を記述す
る。このウェブプロフィールサマリーの生成には多数の
異なるプロセスが関連する。これらのプロセスは一般的
に以下の通りである。 ・ウェブサーバー上でウェブビジター行動を追跡 ・ウェブクライアントからウェブビジター行動を追跡 ・ウェブビジターが閲覧した文書を分離し、重みを決定 ・時刻、ユーザ及びカテゴリーによってウェブイベント
を集計 ・異なるウェブサイトを訪れた同じウェブビジターを識
別 ・異なるウェブサイトで、同一ウェブビジターに関する
データを集計し、ウェブビジターのグローバルプロフィ
ールを生成 ・カテゴリーの発見と保守 次の２節の前半部では、一部のProReachのキーアプリケ
ーションプロセスの全体を概括する。次の節で、カテゴ
リーの発見と保守について説明する。

【００８５】Ａ．ＰｒｏＲｅａｃｈ機能的概要 本節では、基本ProReachシステム１００を流れるデータ
フローを示すため、基本処理ステップを説明する。ま
た、ProReachシステム１００の構造的特徴について詳細
に調べる。

【００８６】基本処理ステップを集中的に説明するた
め、ある程度の簡単化を行い、特定のシナリオだけを明
らかにする。以下では、ProReach使用可能ウェブサーバ
ー１０２だけがウェブクライアント１０６に常駐するク
ッキーに基づいてウェブビジットを追跡する場合を考え
る。ProReachは、ログイン名とその他の情報にも基づい
てウェブビジターを追跡するが、この追跡については説
明しない。さらに、殆どのウェブクライアントで成り立
つように、ウェブクライアント１０６がクッキーを許容
する場合を想定する。

【００８７】一般的に、ウェブ行動を追跡するプロセス
の全体は以下のとおりである。

【００８８】・ウェブクライアント１０６がProReach使
用可能サイト１００を訪れる。

【００８９】・ProReach使用可能ウェブサーバー１０２
は、ウェブクライアント１０６をグローバルサービスウ
ェブサーバー１１２へ切り換える。このウェブサーバー
１１２は、ウェブビジターを識別するグローバル識別子
（GID）を割り当てる。ウェブビジターは、できる限り
明確に識別される。識別情報は実際の人を正確に示す場
合もあれば、使用されるウェブクライアント１０６を識
別するだけの場合もある。

【００９０】・グローバルサービスウェブサーバー１１
２は、ウェブクライアント１０６を元のProReach使用可
能ウェブサイト１００に切り換え、ウェブビジターを識
別する付加データを与える。

【００９１】・ProReach使用可能ウェブサーバー１０２
は、この識別子を受け取り、ログ上にウェブヒットを記
録する。ログ上のエントリーはこの識別子を含む。

【００９２】・ウェブサーバー１０２は、このウェブヒ
ットのログからデータを読み出し、ProReachスポーク２
０２に送信する。このログ上の各エントリーの処理は、
スポーク２０２上で始まる。ビジターによって閲覧され
たウェブページのカテゴリーが計算される。この時点
で、ProReachシステム１００は、ウェブページにアクセ
スした人と、そのウェブページのコンテンツの分野を判
定する。

【００９３】・規定時間を超えて、ビジターがウェブサ
イト１００を繰り返しビジットする場合、そのウェブビ
ジターに関連したウェブイベントの履歴が作られる。Pr
oReachは、このデータを集計プロセスで処理することに
よってこのデータを管理する。このプロセスは、データ
をできるだけコンパクトに保つが、有用な分析特性は保
存する。特に、集計プロセスは、ウェブイベントをより
一般化された説明、たとえば、ユーザ及び／又はカテゴ
リーの全体のサマリーを含む説明に要約する。

【００９４】・集計ステップの終了後、プロファイリン
グステップが行われる。プロファイリングステップは、
ウェブビジターの関心を識別する。これにより、ウェブ
ビジターの関心のプロフィールサマリーが得られる。

【００９５】上記のステップは、ウェブビジターデータ
を追跡、分類、集計する基本処理ステップを実証する。
これらのステップの結果物は、ウェブ商取引者が調査す
ることのでき、他の目的（バーナー広告の選択、コンテ
ンツ若しくはサービスの個人化）のためにも使用される
ウェブビジタープロフィールのデータベースである。あ
るいは、ウェブ商取引者は、問い合わせツールを使用す
ることにより、自分のウェブビジターの集団を調査して
もよい。

【００９６】これらのステップは、この節の後半部で詳
細に解明される。

【００９７】図７乃至９を参照するに、ProReachシステ
ム１００のウェブサーバー１０２の部分が示される。ウ
ェブサーバー１０２は、プロフィールサーブレット７３
０と、カテゴリーサーブレット７３１と、ロガー７０２
と、ビジターログ７０４とを含む。

【００９８】ウェブクライアント１０６からのビジット
によって処理が始まる。ウェブクライアント１０６は、
ウェブサーバー１０２によりホストされたウェブページ
にアクセスする（７０１）。ロガー７０２は、ウェブク
ライアントのGIDを要求する。このGIDを取得するため、
ロガー７０２は、グローバルProReachサービス１１２の
グローバル識別子サービス６０２に要求を行う。この要
求は、HTTPプロトコルを用いて、ウェブクライアント
を、ProReachグローバルサービス６１２の一部であるPr
oReachウェブサーバーに切り換えることによって開始さ
れる。図９において、このウェブサーバーはウェブクラ
イアント１０６からの要求がProReachクッキーを含むか
どうかを検査する。ProReachクッキーが要求中に現れる
とき、GIDがクッキーから取り出される。これは、この
ウェブクライアント１０６を識別するGIDである。

【００９９】要求がProReachクッキーを含まない場合、
すなわち、ウェブクライアントがGIDを含まない場合、
新しいGIDがグローバル識別子６１２によって生成され
る。このGIDは大域的にユニークであることが保証され
る。グローバルサービスが計算したGIDは、ウェブ・リダ
イレクションによって、ProReach使用可能ウェブサーバ
ー１０２に返信される（７０７）。実際のGIDはURLにエ
ンコードされるので、ProReach使用可能ウェブクライア
ント１０６は、このURLを受信し、URLからGIDを取り出
し、GIDをクッキーに格納することができる。他の情報
もURLにエンコードされるので、ウェブクライアント１
０６は最初に要求したページに返信される。

【０１００】ウェブビジターのブラウザがクッキーを受
け付けないように構成されている場合、グローバル識別
子サービス６０２はその旨を検出し、通常の方法でGID
としてリダイレクトによって返信されたこのウェブビジ
ターにGIDを割り当てる。しかし、このGIDの値は、ProR
each使用可能ウェブサーバー１０２がセッションクッキ
ーを試行、発行しないこと、並びに、このウェブビジタ
ーのイベントを未知若しくは匿名ユーザとして記録する
ことを表す。

【０１０１】図１０では、GIDがウェブサーバー１０２
に返信されたとき、ロガー７０２はウェブクライアント
をユニークに識別し、ロガーはウェブイベントレコード
をProReachビジターログ７０４に記録する。このエント
リーは、ウェブアクセスが発生した時刻、GID、アクセ
スされたウェブページのURLに関する情報を収容すると
共に、その他の情報も含む。この動作のシーケンスは、
ウェブページ毎に繰り返され、あるいは、ビジターが発
生したその他のウェブ行動毎に繰り返される。

【０１０２】図１０に示されるように、ログ７０４の内
容は、ウェブサーバー１０２から、ファイアウォールの
内側にあるProReachスポーク２０２に定期的に転送され
る。スポーク２０２は、ログプレプロセッサ７０６、ハ
ブビジターログ７０８、イベントキュー７１０、イベン
トプロセッサ７１２、カテゴライザ７１４、ページメタ
データキャッシュ７１６、及び、コンテンツ認識エンジ
ン７１８等の多数のその他の処理モジュールを含む。

【０１０３】データがスポーク２０２に到達した後、デ
ータは、ビジターログ７０８に収容するため前処理され
る（７０６）。この前処理は、データのフォーマットが
特有であるかどうかとは無関係に、データを標準形式の
ウェブイベント（たとえば、データのオブジェクト表
現）に変換する。

【０１０４】イベントキュー７１０は、このログ７０８
を監視し、新しいウェブイベントデータが利用可能であ
るとき、イベントキュー７１０はそのデータを獲得し、
ウェブイベントをGIDによってソートする。イベントキ
ュー７１０は、ログ７０８内の各ウェブイベントを処理
するためイベントプロセッサ７１２を要求する。イベン
トプロセッサ７１２は、カテゴライザ７１４への要求を
行うことによりウェブイベントが分類されることを保証
する。ウェブページを予め分類し、この分類情報をペー
ジメタデータ７１６にエントリーとして与えてもよい。
先行の分類は、ProReachがランタイムに分類を行うこと
が回避されるようできるだけ早期にウェブページを分類
するためウェブサイトを検出してから始まる。しかし、
一部のウェブサイトはウェブコンテンツを動的に生成す
るので、ProReachは全てのウェブページを予め分類でき
るとは限らず、ジャストインタイムで分類されたウェブ
ページを準備する必要がある。

【０１０５】ウェブビジターにより訪れられたURLが既
に分類されている場合、このデータはページメタデータ
キャッシュ７１６から取り出され得る。このデータを取
り出せない場合、カテゴライザ７１４は、コンテンツ認
識エンジン７１８を呼び出す。コンテンツ認識エンジン
７１８は、カテゴリーのデータベースを管理する。各カ
テゴリーは、「スポーツ」や「ニュース」のようなある
種のトピックスを表現する。ウェブページは任意の数の
カテゴリーと照合される。一致したカテゴリーは、ウェ
ブページが関連する分野を表し、ビジターの関心を識別
するための手段を提供する。

【０１０６】コンテンツ認識エンジン７１８は、多数の
カテゴリーのスコアを与える。各スコアは、ページがカ
テゴリーと関連する度合いを測る量である。好ましく
は、スコアは、カテゴリーデータベースのカテゴリー毎
にコンテンツ認識エンジン７１８によって与えられる。
あるいは、スコアは、選択された個数の最高スコアカテ
ゴリー（たとえば、最高から１０番目までのスコアカテ
ゴリー）だけに対し与えられる。

【０１０７】コンテンツ認識エンジン７１８は、所定の
ウェブイベントの分類プロセスを完了したとき、スコア
付きカテゴリーとそれぞれのスコアのリストを収容する
ようにウェブイベントに対するページメタデータキャッ
シュ９１６を更新する。キャッシュが更新されたとき、
ウェブイベントのカテゴリー及びそれぞれのスコアはイ
ベントプロセッサ７１２に返信される。イベントプロセ
ッサ７１２は、そのウェブイベントに対する分類の結果
を収容するためウェブイベントレコードを変更する。あ
るいは、分類情報は、ウェブイベントとは別々に記憶さ
れてもよく、URLのような他の手段を用いてウェブイベ
ントからアクセスされる。ウェブイベントレコードが分
類された後、ウェブイベントは、次の処理ステージに発
送する準備ができている。次の処理ステージは、ProRea
chハブ２０４上にある。より一般的には、分類されたウ
ェブイベントは、ProReachスポーク２０２からハブ２０
４に流れる。

【０１０８】図１２を参照するに、ProReachハブ２０４
が示されている。ProReachハブ２０４は、集計キュー７
２２と、集計システム７２４と、プロフィール７２６
と、データベースエージェント７２８と、プロフィール
データベース７２０とを有する。

【０１０９】ハブ２０４は、ウェブプロフィールのデー
タベース７２０を保持する。このデータベース７２０の
各プロフィールは、GIDによってユニークに識別され
る。各ウェブプロフィール内で、ウェブビジターのウェ
ブイベントはカテゴリーによって保持される。例示的な
ウェブプロフィールは、カテゴリーデータベースに収容
されたカテゴリーの数毎に個人（又はグループ）の関心
を記述する、ProReachハブ２０４は、新たに分類された
ウェブイベントを獲得し、このデータを既存のウェブプ
ロフィールのデータと統合し、ウェブ行動から生成され
るようなウェブイベントで獲得されたような関心に関す
る最新情報を用いてビジターのプロフィールを更新す
る。ウェブプロフィールがそのウェブビジターに対して
存在しない場合、一つのプロファイルが作成される。

【０１１０】この集計処理の第１ステップは、ウェブプ
ロフィールを選択するためウェブビジターのGIDを用い
て、必要とされるウェブプロフィールをデータベース７
２０から獲得することである。ウェブイベントレコード
又はイベントレコードの集合が集計されたとき、それら
は各ウェブイベントが同一GIDを有するグループ単位で
処理される。

【０１１１】あるGIDに対するウェブプロフィールが獲
得された後、集計システム７２４は、ウェブビジターが
アクセスした文書の全カテゴリーに対し集計動作を実行
する。好ましい一実施例において、カテゴリー重みを更
新する閾値が確定され、閾値よりも高いスコアが付けら
れた文書に対するカテゴリーだけが更新される。

【０１１２】一般的に、集計器７２６は、図２を参照し
て説明したように、多数のユーザ、グループ、及び、カ
テゴリーサマリーを更新する。各サマリーは、専用のウ
ェブイベントレコードに保持され、ユーザ若しくはユー
ザグループ、又は、適用されるカテゴリーと、適当な他
の集計された重み値を識別する。このアプローチの場
合、ProReachは、多量で高品質のビジターデータを低コ
ストで保存することができる。その理由は、ProReachが
ウェブ商取引者によって必要とされる動作の類、すなわ
ち、ユーザ関心及び傾向の分析をサポートするよう設計
されているからである。

【０１１３】集計プロセスが終了したとき、次のステッ
プは、ビジターのプロフィールを更新することである。
プロファイリング７２６は、ウェブビジターの関心を識
別する作業である。この作業の働きを理解するため、最
初に、簡単な例を説明する。ウェブサイトのビジットを
利用して、「スポーツファン」を識別しようとするウェ
ブ商取引者がいる場合を想定する。このウェブ商取引者
は、まず、「スポーツファン」が何を意味しているかを
定義する。この用語を定義するためには多数の方法が考
えられる。

【０１１４】・絶対的関心度定義：スポーツファンと
は、１年に少なくとも２０回にわたりスポーツ関連ウェ
ブページを閲覧する人である。

【０１１５】・相対的関心頻度定義：スポーツファンと
は、スポーツ関連ウェブページを他のウェブページより
も頻繁に閲覧する人である。たとえば、スポーツファン
は、ウェブページを１００回閲覧する場合に、スポーツ
関連ウェブページを１０回閲覧する人である。

【０１１６】・比較的関心頻度定義：スポーツファンと
は、他のウェブビジターよりも頻繁にスポーツ関連文書
を閲覧する人である。

【０１１７】用語「スポーツファン」に対するこれらの
３通りの定義の候補は、ユーザのウェブ行動から判定さ
れるようなスポーツカテゴリーの重みの関数として関心
を記述する。

【０１１８】いずれのタイプの定義法（あるいは、他の
定義法）もカテゴリーの集合に関して関心を定義するた
め使用される。論理的に、関心は、ウェブビジターが関
心を抱いているかどうかを判定するため、プロフィール
データベース７２０に対するSQLで使用するような問い
合わせとして理解される。問い合わせは、任意のカテゴ
リーの組み合わせの重みを評価するため定義される。Pr
oReachを用いる場合、ウェブ商取引者は、例示による問
い合わせツールのような簡単な問い合わせツールを用い
てこのような関心を命名し、定義することができる。こ
のツールは、データベースエージェント７２８を介して
データベース７２０上で動作する。

【０１１９】関心が定義された後、新しい関心は、所与
のProReachシステム１００に追加され、利用できるよう
にされる。関心が利用できるようにアクティブにされる
と、各関心を選択し、所与のウェブビジターがその関心
を持つかどうかをテストするのは、プロファイラ７２６
の役割である。プロファイリングが行われるとき、活性
化された関心は、ビジターが関心を持つかどうかを判定
するため、ウェブビジターのデータに適用される。その
結果は、ビジターに相応しい関心を識別するプロフィー
ルである。

【０１２０】たとえば、データベース７２０中に５種類
のアクティブ関心、たとえば、スポーツファン、保守的
な人（保守派）、趣味に熱中する人（趣味熱中派）、離
婚直後の人、退職を計画中の人のような関心があり、そ
れぞれの関心は、多数のカテゴリーに関する上述したよ
うな規準の集合によって予め定義されている場合を想定
する。保守的な人の関心は、保守的な考え又は信念と関
連していると考えられるカテゴリーに分類されたページ
にアクセスする相対的頻度によって定義され、離婚直後
の人の関心は、離婚代理人に関連したウェブコンテンツ
を閲覧する（最新の挙動を識別する）相対的頻度によっ
て定義される。

【０１２１】このような関心の集合は、データベース７
２０に格納され、プロファイラ７２６によってウェブビ
ジターのデータに適用される。各関心に関連した問い合
わせは、（述語として）適用され、この述語評価の結果
はブール代数値である。このよりから、たとえば、以下
の結果集合が得られる。

【０１２２】

【表４】 結果はビジターが関心を持っているかどうかを示すブー
ル代数値であることに注意する必要がある。他の実施例
では、ファジィ集合メンバーシップが使用され、各関心
の結果は、ユーザが関心を持っている程度の測度（たと
えば、０．１から１．０までに定められた値）として表
現される。

【０１２３】たとえば、このような結果に基づいて、こ
のウェブビジターのウェブプロフィールが更新される
（７２３）。好ましくは、データベース７２０内のウェ
ブプロフィールサマリーレコードは、ウェブビジターの
関心を列挙する。一実施例において、ウェブプロフィー
ルサマリーレコードは、プロファイラ７２６によって決
められるようなウェブビジターの関心を記載する関心フ
ィールドを含む。プロファイリングの終了後、この関心
フィールドは更新される。各関心は関心識別子と関連付
けられる。関心識別子は、{101,321,19}のような関心フ
ィールドに割り当てられた整数のシーケンスである。た
とえば、スポーツファン関心のIDが101であり、保守派
関心のIDが321であり、退職計画中関心のIDが19である
とき、{101,321,19}は、｛スポーツファン、保守派、退
職計画中｝と同じことを表す。

【０１２４】各関心IDは、ウェブビジターの関心を簡潔
に識別する。

【０１２５】関心はウェブビジターを分類するために役
立つので有用である。しかし、関心は、ある意味でカテ
ゴリーとは区別される。第一に、関心はユーザ若しくは
ユーザのグループを表すが、カテゴリーはウェブコンテ
ンツを表す。第二に、関心は、訪れたウェブコンテンツ
のカテゴリースコア、人口統計学など含む多数の要因の
組み合わせから形成されるので、関心は、コンテンツ認
識エンジン７１８のカテゴリーによって典型的に表され
るような階層的な親子関係に簡単には限定されない。

【０１２６】ProReachがウェブビジターをプロファイル
するとき、ProReachは各ウェブビジターの関心を計算
し、必要に応じて再計算する。この計算が行われると
き、更新されたプロフィールサマリーは、データベース
エージェント７２８を介してデータベース７２０に記憶
される（７２２）。これにより、更新されたウェブプロ
フィールが得られ、カテゴリーに関係した全データ、お
よび、そのウェブビジターの全ての関心も同様に更新さ
れる。

【０１２７】問い合わせツールのような他のProReachツ
ールは、ProReachウェブビジターのグループを素早く正
確に指定するためこのデータを使用できる。たとえば、
スポーツファンであり、かつ、保守派である全ウェブビ
ジターを識別するため問い合わせが行われる。あるい
は、スポーツファンではあるが、保守派ではない全ての
ウェブビジターを識別する問い合わせを行うことも可能
である。

【０１２８】次に、関心を定義する方法と、ウェブビジ
ターの現在の関心の集合を反映させるためプロフィール
を更新する方法を説明する。図９は、ウェブサーバー７
０２がウェブビジターのウェブプロフィールにアクセス
する方法を示す。ウェブサーバー１０２上のプロフィー
ルサーブレット７３０は、GIDに基づいて既知ウェブビ
ジターのウェブプロフィールを獲得する（７３１）。GI
Dは、ウェブクライアント１０６に常駐するクッキー又
はグローバル識別子サービスから得られる。この機能に
よって、ウェブビジターのGIDを識別することが望ましく
なる。ウェブサーバー１０２がビジターのGIDにアクセ
スした後、ウェブサーバーは、ウェブビジターの対応し
たプロフィールからデータを選択的に取得するためGID
を使用することができる。プロフィール内に関心が与え
られているとき、ウェブサーバー１０２は、たとえば、
ビジターが関心をもつカテゴリーに最もよく一致するコ
ンテンツを選択することによって、ウェブビジターに最
も関心のあるコンテンツが最大限に生かされるようウェ
ブページを動的に作成することができる。

【０１２９】ProReachは、ウェブクライアントからウェ
ブ行動を追跡する機能、ProReachシステム間でウェブプ
ロフィールデータを交換する機能のような多数の能力を
有する。ProReachは、ウェブ商取引者が候補者（顧客に
なりそうな人）を識別し、連絡をとるために役立つ便宜
を図る。ProReachは、垂直的マーケット内でのビジネス
がそのビジネスに適してカテゴリーを作成できるように
先進的な分類技術を提供する。また、ProReachは、カテ
ゴリーを開発及び保守するプロセスを自動化する分類技
術を提供する。

【０１３０】Ｂ．カテゴリー発見及び保守 この節では、カテゴリー発見及びカテゴリー保守のプロ
セスを例を用いて説明する。

【０１３１】１．カテゴリー発見 ProReachシステム１００がコンピュータ周辺機器に関し
てコンテン認識エンジン７１８によって管理されるよう
な以下のカテゴリーを有する場合を考える。

【０１３２】

【表５】 記憶装置カテゴリーは、他のカテゴリーの親カテゴリー
である。第一に、サブカテゴリー内の文書の総数は４３
０であり、一方、記憶装置には５００文書が分類されて
いることに注意する必要がある。これは、文書中に記憶
装置に関連しておるが、既存のサブカテゴリーでは区別
できないた他のカテゴリーが存在することを示す。

【０１３３】カテゴリー発見プロセスは、既存のカテゴ
リー内に潜むカテゴリーを見つけるため統計的分析を使
用する。以下に詳述するように、カテゴリー発見は、頻
度と、文書の集合に出現する語の間の関係とに基づい
て、カテゴリーを識別する。上述の例において、このカ
テゴリー発見プロセスが、ＤＶＤに関する多数の記憶装
置の文書の存在を発見した場合を考える。カテゴリー発
見プロセスは、潜在的な新しいカテゴリーとしてＤＶＤ
を識別する。逆に、カテゴリー発見プロセスによって指
摘されたカテゴリー変化は、オペレータによって検査、
確認される。このオペレータとの相互作用は、多数の理
由から望ましい。第一に、カテゴリー発見プロセスは、
多数の価値のある示唆を与えるが、常に正しいとは限ら
ない。人によるある程度のガイダンスは、意味のあるカ
テゴリーだけが追加されることを保証するため有効であ
る。

【０１３４】上述のケースで、オペレータが新しいＤＶ
Ｄカテゴリーを追加すべきであることを確認した場合を
考える。この確認が与えられた後、残りのプロセスは自
動的に行われ、カテゴリーは、文書を分類するためコン
テンツ認識エンジン７１８によって直ちに使用される。
既存の文書は、カテゴリースコアを決定するため再評価
される。

【０１３５】カテゴリー発見プロセスを適用するときを
決める際の問題は、新しいカテゴリーの探索を何時行う
べきかということである。一実施例において、新カテゴ
リーの探索は、以下のいずれかの条件が成立したときに
行われる。 ・所定のカテゴリー内に多数の文書が分類されている
（たとえば、分類された全文書の中で所定数、若しく
は、所定の割合を超えるとき） ・分類の見落としの兆候がある（たとえば、親カテゴリ
ーがサブカテゴリーに対して所定数、若しくは、所定の
割合を超える文書を含むとき） ・所定のカテゴリーに分類された文書をアクセスする多
数のウェブビジターが存在する（たとえば、選択された
時間的区間のビジター数が所定数、若しくは、所定の割
合を超えるとき） カテゴリーツリーの一部の分枝は、時間的に非常に不安
定であるかもしれない（たとえば、高度技術）。そこ
で、カテゴリーツリーのその区分の時間的不安定性も要
因となり得る。

【０１３６】２．カテゴリー保守 カテゴリー発見は新カテゴリーの発見に関係する。カテ
ゴリー保守は、既存のカテゴリーの維持及び改良に関す
る。カテゴリー発見の場合と同様に、カテゴリー保守の
プロセスは、好ましくは、カテゴリーの変更を示唆する
忠告型プロセスである。カテゴリー保守プロセスは、確
認が与えられるまで、変更を行わない。あるいは、自動
的に変更が行われるようにしてもよい。

【０１３７】特に、カテゴリー保守は、以下の場合に示
唆を与える。 ・カテゴリーの消去 ・カテゴリーに関連した訓練用文書の変更 カテゴリー発見と同様に、カテゴリー保守は統計的分析
を含む。たとえば、カテゴリーを消去する示唆は、その
トピックに関連したウェブページの数が非常に少なく、
かつ、その文書を閲覧する人の数が非常に少ない場合に
行われる。文書が少なく、その文書の閲覧者が少ないと
いうことは、そのカテゴリーが消去するカテゴリーの候
補である。

【０１３８】たとえば、訓練用文書はスコアに基づいて
選択され、カテゴリースコアが閾値よりも低い場合、訓
練用文書は再選択される。カテゴリーに関連したキーワ
ードに十分に高いスコアが付けられていないとき、カテ
ゴリーは移される。

【０１３９】カテゴリーを作成するため、カテゴリーを
選択し、訓練用文書を選択し、キーワードを生成するた
め訓練用文書にスコアを付け、キーワードがカテゴリー
を反映しているかどうかを人が判断する。

【０１４０】ＩＶ．アライアンスを含むＰｒｏＲｅａｃ
ｈシステム 図１乃至６は、ProReachスポーク２０２がウェブ行動デ
ータをProReachシステム１００の集中ハブ２０４に供給
する様子を示している。ハブとスポークのトポロジー
は、フレキシブルかつスケール変更可能な形式で１台以
上のウェブサーバー１０２を取り扱う。しかし、ProRea
chは、このウェブイベントの局所的な蓄積よりも優れて
いる。ハブ２０４に保持されたビジターのプロフィール
は価値があるが、情報の価値は、多数のハブ及びProRea
chシステム１００の全域における集計によって増加す
る。この集計は、情報のソースが別々の企業に属してい
ても、多数のソースからのプロフィールを併合すること
によって達成される。

【０１４１】既存システムの場合に、ビジタープロフィ
ール情報の共有による恩恵を享受する企業は、いくつか
の理由から情報の共有を拒む。ビジタープロフィール情
報の共有を促進する基盤技術はないので、情報の共有化
のためには、ソフトウェアサポートの大規模な初期投資
が必要である。また、プロフィール情報自体に関して
も、どの企業がプロフィール情報を所有するのか、決定
権は誰にあるのかという所有権及び使用権の問題があ
る。

【０１４２】本発明では、アライアンス（同盟）は、企
業間でプロフィール情報の共有化を促進し、共有化のた
めの障害を解決する手段である。アライアンスを用いる
ことによって、ProReachは、ビジネス当事者の双方に有
益なデータのビジネス間での供給かを実現する。多くの
場合に、アライアンスは、ある垂直的統合マーケットの
周りでクラスタ化されたビジネスをサービスするため形
成される。たとえば、薬剤のアライアンスが存在し、あ
るいは、石油関連ビジネスのアライアンスが存在する。
図１３を参照するに、各ProReachシステム１００は、ア
ライアンス８００のメンバーではないか、あるいは、一
つ以上のアライアンス８００のメンバーである。アライ
アンスにおけるメンバーシップは変化する。アライアン
ス８００のメンバーは、自分のプロフィールデータのコ
ピーをアライアンス８００に送信する。このデータは、
アライアンスプロフィールに集計される。アライアンス
プロフィールは、アライアンスメンバーから収集された
プロフィールの集合体である。

【０１４３】勿論、同じウェブビジターは、同一アライ
アンス８００のメンバーである多数のProReachシステム
１００を訪れる。異なるローカルハブが同一ウェブビジ
ターのプロフィールを送信するとき、アライアンス８０
０は、別々のローカルプロフィールを取得し、そのウェ
ブビジターに関する単一のアライアンスプロフィールに
組み合わせる。GIDを使用することにより、アライアンス
は、同じウェブビジターに属するプロフィールを簡単に
計算し、重複を回避するためこれらのプロフィール中の
情報を正しく併合することができる。

【０１４４】ローカルプロフィール情報をアライアンス
に供給する代わりに、アライアンス８００のメンバー
は、アライアンスプロフィールにある程度のアクセス権
をもつ。ProReachシステム１００は、アライアンス８０
０の完全アクセス、制限アクセス、若しくは、最小アク
セスメンバーである。各メンバーシップレベルの責任及
び利益は変化する。 ・完全アクセスメンバーは、垂直統合型プロフィールに
対し最大許容アクセス権をもつ。完全アクセスメンバー
は、ローカルプロフィールからの最大量の情報を与え
る。 ・制限アクセスメンバーは、適度なアクセス権を有し、
ローカルプロファイルから適当な量の情報を与えること
が必要である。 ・最小アクセスメンバーは、垂直統合型プロフィールに
対し最小アクセス権をもつ。最小アクセスメンバーは、
ローカルプロフィールからの最小量のプロフィール情報
を与えることが必要である。

【０１４５】垂直統合型アライアンスへの参加により、
各メンバーは共同で生成したアライアンスプロフィール
への条件付きアクセスが許可される。利益及び責任は、
少数のメンバーシップレベルの間で合理的に取り扱われ
る。メンバーシップは、与えようとする情報のカテゴリ
ーと、その量と、対象とするウェブビジターとを指定す
る必要がある。したがって、このスキームは、個別のPr
oReachシステム１００が多数のアライアンスに参加する
確実な動機を与える。

【０１４６】ProReachシステム１００は、アライアンス
のメンバーであることから、ウェブビジターのアライア
ンスプロフィールへのアクセス権を保有する恩恵を享受
する。アライアンスプロフィールは多数のウェブサイト
及びProReachシステム１００に亘って集計されるので、
ウェブビジターの関心についての非常に正確で包括的な
評価を与える。これにより、所定のProReachシステム１
００は、ビジターがアライアンスメンバーであるProRea
chシステム１００をビジットしたときに、ウェブコンテ
ンツをウェブビジターに向けることができる。

【０１４７】Ｖ．集計 この節では、ウェブイベントが集計システム７２４と集
計キュー７２２とによって集計されるプロセスの一実施
例を詳細に説明する。集計キュー７２２は、変換されて
いないウェブイベントレコードの組を蓄積する。これら
のレコードは、スポーク２０２上のイベントプロセッサ
７１２によって、到達順に、すなわち、一つ以上のスポ
ークから到来した順にキュー７２２に与えられる。概略
的に、キューは、ある時間的区間に亘って多数の異なる
ユーザによって生成されたウェブイベントを蓄積する。

【０１４８】図１４を参照するに、集計キュー７２２の
論理構造が示されている。集計キュー７２２は、ウェブ
イベント９００の集合体を蓄積する。各ウェブイベント
はウェブコンテンツの項目と相互作用するビジターのイ
ンスタンスを表現する。各ウェブイベント９００は、ユ
ーザ識別子９０２（好ましくは、GID）と、ウェブ行動
が始まったときを表す開始時刻９０４と、行動の間隔
（秒単位）（間隔が得られないとき、デフォルトとして
１分）９０６と、タイプ（取引、クリックスルー又はペ
ージ閲覧のいずれかを表現）９１４と、URL（ウェブサ
イトのドメイン名）９１２と、カテゴリーベクトル９１
６とを収容する。カテゴリーベクトル９０８は、カテゴ
リー識別子のリスト９１０と、それぞれのカテゴリース
コアとを収容する。各カテゴリースコアは、ウェブコン
テンツがコンテンツ認識エンジン７１８によってカテゴ
リーに関して評価された程度を示す。好ましくは、カテ
ゴリー毎にカテゴリースコアがコンテンツ認識エンジン
７１８によって保存される。したがって、たとえば、コ
ンテンツ認識エンジン７１８によって使用されるカテゴ
リーが1000カテゴリーである場合に、ベクトル９０８
は、1000個の<カテゴリーID、スコア＞タプルを収容す
る。一実施例において、カテゴリースコアは0から1,000,
000の範囲に収まるが、任意の有効なレンジが適切なス
ケーリング係数と共に使用される。

【０１４９】図１５を参照するに、集計システム７２４
のコンポーネントが示されている。集計システム７２４
は、一般的に、多種類のサービスを果たす。第一に、毎
日集計システム９１９は、ウェブサーバー１０２で生じ
たウェブイベントから毎日の集計を集める。第二に、次
元集計システム９４１は、図２に示されるような多数の
ユーザコンプレックス及びカテゴリーコンプレックスに
次元結合することにより、毎日の集計を組み合わせる。
第三に、ユーザグループシステム９５０は、ユーザグル
ープの定義及び定義の維持を行う。プロフィールサーバ
ー９５５は、個々のユーザプロフィールを保持し、ユー
ザプロフィールの局面に関する問い合わせに応答する。
全てのサービスは、集計システム７２４の範囲に含まれ
る。

【０１５０】毎日集計システムは、ハンドラーオブジェ
クト９２０と、計算オブジェクト９２２と、パーサーオ
ブジェクト９２４と、集計器オブジェクト９２６とを含
む。集計キュー７２２は、毎日集計システム７２４への
エントリーポイントとして理解され、図７乃至１０では
便宜的に個別に示されている。

【０１５１】イベントディスパッチャ９３０は、集計シ
ステムの全サービスの範囲内の全ての行動を監視し、イ
ベントを聞くことに関心のある人にイベントを送る。イ
ベントディスパッチャは、集計システム内のサービスの
一部ではない。イベントディスパッチャは、カメラのよ
うに、集計システム内部で行われる全ての行動を監視
し、見渡し、注視するだけである。

【０１５２】毎日問合わせオブジェクト９３２は毎日集
計システムの一部であり、毎日の集計に関する全ての問
合わせを担う。毎日問合わせオブジェクトは、上述のよ
うにユーザの関心に関する全種類の問合わせ、たとえ
ば、関心の定義、及び、（１日単位で）特定の関心をも
つユーザの識別の問合わせを取り扱う。問合わせは、問
合わせ言語９４６を使用する問合わせ言語インタープリ
ター９４４によって処理される。ハンドラ９２０は毎日
集計システムのインタフェースをエクスポートし、ウェ
ブイベントのパケットの毎日集計プロセス中に毎日集計
サービスの残りのコンポーネントを管理する。

【０１５３】結合器９３８は、次元集計システムの一部
であり、ProReachのメンバーによって計画されたように
次元集計を行う。より詳細には、合成器９３８は、一部
のメンバーによって行われた計画されタスクに図２のレ
ベル１乃至レベル４に示されるように、毎日集計された
ウェブイベント（又は、コンプレックス）を上位レベル
サマリー（たとえば、時刻、ユーザ、グループ、及び、
カテゴリーなどに関して）次元結合する役割を担う。

【０１５４】更新オブジェクト９４０は、毎日集計シス
テムがウェブイベントのパケットを処理するとき、毎日
集計を更新する。

【０１５５】データベース７２０は、ウェブイベントか
らの集計された情報を多数の異なるテーブルに格納す
る。多数のテーブルには以下のテーブルが含まれる。

【０１５６】ユーザテーブル：ユーザテーブルは、各ユ
ーザを識別し、記述する情報を格納する。このテーブル
のフィールドには、ユーザID、ラストネーム、ファース
トネームが含まれ、このテーブルはユーザIDで索引付け
られる。

【０１５７】ユーザID連絡テーブル：このテーブルは連
絡アドレスに関する以下の欄、ユーザID、アドレス１、
アドレス２、市、州、郵便番号、国、電子メールを含
む。

【０１５８】人口統計学テーブル：人口統計学テーブル
は、ユーザに関する人口統計学情報を収容する。人口統
計学テーブルは、ユーザID、性別、年齢、学歴、職業な
どの欄を含む。

【０１５９】メンバーテーブル：メンバーテーブルは、
ProReachシステムのメンバー、すなわち、ProReachシス
テムにアカウントをもつ人（若しくは、企業）に関する
情報を収容する。このテーブルは、ID番号、ラストネー
ム、ファーストネーム、電子メール、ログイン、パスワ
ード、URL、アカウント種別などの欄を含む。URLはメン
バーによって所有されるウェブサイトのドメイン名を表
現する。メンバーがウェブサイトを所有しないとき、UR
L欄は空白である。アカウント種別は、メンバーが保持
するアカウントの種別を表現する。この種別にしたがっ
て、メンバーはある種のサービスにアクセスし、他のサ
ービスは拒否される。

【０１６０】カテゴリーテーブル：カテゴリーテーブル
は、コンテンツ領域エンジン７１８によって使用される
全てのカテゴリーを格納する。このテーブルに含まれる
フィールドは、カテゴリーID、カテゴリー名、及び、親
カテゴリーIDである。テーブルは、カテゴリーIDと、名
前及び親に関する２次的索引によって索引付けられる。
親カテゴリーIDは、カテゴリーの階層を構築するため使
用され、低レベルカテゴリー情報を上位カテゴリーに集
めるため使用される。

【０１６１】毎日集計テーブル：毎日集計テーブルの各
行は、所定の日に出現した特定のユーザ・カテゴリーの
組み合わせに関して毎日集計するオブジェクトを格納す
る。この情報は、図２に示された集計ツリーのレベル０
のデータに対応する。このフィールドには、ユーザID、
カテゴリーID、重み、偏差、日付、及び、傾向が含まれ
る。

【０１６２】偏差フィールドは、（カテゴリーID）によ
って指定されたカテゴリーに関する所定の時間的区間に
亘るカテゴリー重みの標準偏差を格納する。

【０１６３】日付フィールドは曜日若しくは日数を格納
する。

【０１６４】傾向フィールドは、時間的区間のユーザの
関心の曲線の形状若しくは勾配を記述する文字列又は符
号化値を格納する。たとえば、以下に詳細に説明するよ
うに、傾向フィールドは、この曲線を「増加のち減少」
あるいは「一定のち増加」のように記述する。

【０１６５】ユーザグループテーブル：このテーブル
は、各ユーザグループを識別し、そのサイズと、そのユ
ーザグループに関する説明、あるいは、メンバーシップ
を決める規則が共に格納される。このテーブルのフィー
ルドには、ユーザーグループID、グループ名、説明及び
サイズが含まれる。サイズはグループメンバーの数を表
す。

【０１６６】規準テーブル：規準テーブルは、ユーザグ
ループに対する種々のメンバーシップテストを定義する
ため使用されるルールを格納する。ユーザグループ規準
と共に使用されるこのテーブルは、以下のフィールドを
含む。

【０１６７】規準IDフィールドは、ルール番号を指定す
る。

【０１６８】カテゴリーIDフィールドは、規準が適用さ
れるカテゴリーを指定する。

【０１６９】最小フィールドは、ルールを満たすためユ
ーザが取り得る最小重みを定義する。

【０１７０】最大フィールドは、ルールを満たす最大重
みを定義する。

【０１７１】否定フィールドは、ルールを満たすことが
グループ包括若しくはグループ除外のどちらであるかを
指定する。

【０１７２】一例として、ルールの最小フィールド＝２
０、最大フィールド＝８０、否定フィールド="NO"であ
る場合を考える。このメンバーシップルールは、「メン
バーシップテストを満たすユーザに対し、カテゴリーの
重みは、２０乃至８０でなければならない」を意味す
る。

【０１７３】否定フィールド="YES"である場合には、こ
のルールは、ルールのメンバー足り得るためには、重み
が２０乃至８０意外でなければならないことを意味す
る。

【０１７４】ユーザグループ規準テーブル：ユーザグル
ープ規準テーブルは、各ユーザグループを規準テーブル
に定義された一つ以上のメンバーシップルールと関連付
ける。フィールドには、ユーザグループIDフィールド
と、規準IDフィールドとが含まれる。

【０１７５】保持カテゴリーテーブル：保持カテゴリテ
ーブルは、情報（たとえば、重み、ユーザグループ、プ
ロフィールなど）が保持されるカテゴリーの集合を含
む。このテーブルのフィールドには、カテゴリーID、現
在値(CurrentValue)、パーマネント(Permanent)、低程
度関心(LowInteresterd)、中程度関心(MidiumIntereste
d)、高程度関心(HighInterested)、及び、極高程度関心
(VeryHighInterested)が含まれる。

【０１７６】このテーブルは、システム管理者又は商取
引者が、保持されるべきカテゴリーと、無視されるカテ
ゴリーとを選択できるようにする。この選択は絶対的選
択でも動的選択でもよい。絶対的選択の場合、商取引者
は、全体から一つのカテゴリーの集合を選択し、これら
のカテゴリーに関する情報だけを保持する。動的選択の
場合、商取引者は、同時に全てのカテゴリーを考慮し、
各カテゴリーの現在値フィールドにあるランクを与え
る。現在値ランクは、そのカテゴリーに関心のあるユー
ザ数に応じて動的に変えられる。たとえば、現在値があ
るレベルよりも下がったとき、カテゴリーは無視され、
テーブルから削除される。新カテゴリーがある程度の重
要度を獲得したときにはテーブルに追加される。これが
動的選択である。

【０１７７】商取引者は動的選択と絶対的選択の両方を
組み合わせてもよい。たとえば、商取引者は、所定数の
カテゴリーをパーマネント（ブール代数フラグ）として
選択し、他のカテゴリーをパーマネントではない動的な
カテゴリーとして選択してもよい。パーマネントカテゴ
リーは常にテーブルに置かれ、関連した情報（ユーザグ
ループ全体、プロフィールなど）が常に保持される。動
的カテゴリーは、現在値があるレベルよりも低下したと
きにテーブルから削除されるカテゴリーである。この閾
値は、好ましくは、集計システム７２４用のコンフィギ
ュレーションファイル、若しくは、システム管理者によ
って定められる。

【０１７８】保持カテゴリーテーブルのLowIntereste
d、MediumInterested、HigInterested、VeryHighIntere
stedのような他の欄は、それぞれ、重みによって判定さ
れるように、そのカテゴリーへの関心が低いユーザ、普
通のユーザ、高いユーザ、非常に高いユーザの数が収容
される。一実施例において、これらの関心グループは、
重みの四分位数と関連付けられる。すなわち、重みが１
から２４までのとき、関心が低いので、ユーザはLowInt
erestedにカウントされ、重みが２５から４９の範囲に
あるとき、関心は中間程度なので、ユーザはMediumInte
restedにカウントされ、重みが５０から７４までのと
き、関心が高いのでユーザはHighInterestedにカウント
され、重みが７５から１００までのとき、関心が非常に
高いのでユーザはVeryHighInterestedにカウントされ
る。

【０１７９】保持ユーザテーブル：保持ユーザテーブル
は、プロフィールが保持された全てのユーザを掲載す
る。このテーブルのフィールドには、ユーザID、ラン
ク、及び、ホットカテゴリーIDが含まれる。

【０１８０】ランクフィールドは、ユーザの重要度に応
じて変更される値のフィールドである。値があるレベル
よりも低いとき（すなわち、１００番目若しくは１００
０番目のランクよりも低いとき）、ユーザはテーブルか
ら削除され、このユーザに関するプロフィールは保持さ
れない。しかし、新ユーザが非常に重要になったとき、
このユーザはテーブルに追加され、そのユーザのプロフ
ィールが保持される。

【０１８１】ホットカテゴリーIDは、そのユーザに関し
て最高カテゴリー重みを有するカテゴリーを識別する。

【０１８２】プロフィールテーブル：プロフィールテー
ブルは、ユーザがメンバーになっているユーザグループ
に関して、各ユーザのプロフィールを記述する。このテ
ーブルのフィールドには、ユーザID、ユーザグループI
D、メンバー開始時、メンバーシップ終了時、現在メン
バー、及び、最終更新が含まれる。

【０１８３】メンバー開始時フィールドは、ユーザがグ
ループのメンバーになった日付を識別する。

【０１８４】ユーザは、多数のユーザグループのメンバ
ーになることができ、メンバーシップは動的であり、時
間的に変化する。プロフィールテーブルは、ユーザグル
ープメンバーシップの履歴レコードを保持する。全ての
ユーザグループに対し、プロフィールテーブルは、ユー
ザが始めてメンバーになったとき（メンバー開始時）
と、ユーザが現在メンバーであるかどうか（現在メンバ
ー）と、メンバーシップが終了するとき（メンバーシッ
プ終了時）とを指定する。この異なるユーザグループ間
の変更の履歴レコードから、将来のユーザの反応を予測
するため使用され得るある種の挙動及びパターンを抽出
し、販売目的にこの情報を利用することができる。

【０１８５】ユーザ・カテゴリーコンプレックステーブ
ル：このテーブルは、図２に示されたＵＣ（ユーザ・カ
テゴリー）コンプレックス２０３のデータを格納する。
このテーブルのフィールドには、ユーザID、カテゴリー
ID、重みWeight、偏差Deviation、カテゴリーに対する
重みWeightAgainstCategory、集団に対する重みWeightA
gainstPopulation、傾向Trend、区間FromAndToなどが含
まれる。

【０１８６】ユーザID及びカテゴリーIDは、ユーザとカ
テゴリーの組合せを指定する。

【０１８７】重みは、カテゴリーIDによって指定された
カテゴリーへのユーザ関心の平均重みを表す。

【０１８８】偏差は、このユーザ関心の平均重みの標準
偏差である。

【０１８９】カテゴリーに対する重みは、ユーザ毎に指
定されたカテゴリーの他のカテゴリーに対する重要度の
測定量を格納する。一実施例において、カテゴリーに対
する重みの値は、指定されたカテゴリーに関して総計さ
れたカテゴリー重さのパーセンテージである。すなわ
ち、カテゴリーｊについてのカテゴリーに対する重み
は、カテゴリーｊの重みを全てのカテゴリー重みの合計
で割り算し、パーセンテージ表記するためその結果を１
００倍した値に一致する（パーセンテージに変換する前
の値をそのまま使用する場合もある）。

【０１９０】集団に対する重みWeightAgainstPopulatio
nは、ユーザ毎に指定されたカテゴリーの重要度を他の
全ユーザと相対的に表した測定量を格納する。一実施例
において、集団に対する重みは、指定されたカテゴリー
に関して総計されたカテゴリー重さの他の全ユーザに対
する相対的なパーセンテージである。すなわち、カテゴ
リーｊとユーザｋに関する集団に対する重みは、ユーザ
ｋに関するカテゴリーｊの重みを全ユーザに関するカテ
ゴリーｊのカテゴリー重みの合計で割り算した結果をパ
ーセンテージ表記するため１００倍した値に一致する
（１００倍する前の値をそのまま使用してもよい）。

【０１９１】傾向Trendは、区間FromAndToによって定義
された時間的区間に亘るカテゴリーへのユーザ関心の形
状又は勾配を記述する。

【０１９２】区間FromAndToは、このコンプレックスを
生成するため使用されたウェブ行動の最先開始時刻と最
新開始時刻を定義する。

【０１９３】ユーザコンプレックステーブル：ユーザコ
ンプレックステーブルは、U（ユーザ）コンプレックス
２０５の内容を記憶する。このテーブルのフィールドに
は、ユーザID、重み、偏差、傾向、区間FromAndTo、カ
テゴリーカウントが含まれる。ユーザコンプレックス
は、多数のカテゴリーに関するユーザの関心を要約する
ので、カテゴリーカウントは、ユーザに関心のあるカテ
ゴリーの数を追跡する。このカテゴリー数は、集計ツリ
ーにおけるユーザコンプレックスオブジェクトの子供の
数でもある。

【０１９４】カテゴリーカウント値は、重みを増加的に
更新する際に使用される。新しいユーザ・カテゴリーコ
ンプレックス２０７が重みｗで形成されるとき（すなわ
ち、ユーザコンプレックスの新しい子供が形成されると
き）、ユーザコンプレックスの新しい重みは、以下の式
にしたがって増加される。 New weight(Ucomplex) = ([categoriesCount * old weight(Ucomplex)] + w)/ (categoriesCount + 1) カテゴリーコンプレックステーブル：カテゴリーコンプ
レックステーブルは、図２に示されたC（カテゴリー）
コンプレックス２０５を格納する。このテーブルのフィ
ールドには、カテゴリーID、重み、偏差、傾向、区間Fr
omAndToが含まれる。このコンプレックスは多数のユー
ザに関する要約を行うので、重み及び偏差は、区間From
AndToによって定義された時間的区間に亘る全ユーザに
関するものである。

【０１９５】グループカテゴリーコンプレックステーブ
ル：グループコンプレックスカテゴリーテーブルは、GC
（グループ・カテゴリー）２０７の内容を格納する。こ
のテーブルのフィールドには、ユーザグループID、カテ
ゴリーID、重み、偏差、傾向、区間FromAndTo、及び、
ユーザカウントが含まれる。ユーザカウントは、選択さ
れたカテゴリーについて、このグループ内のユーザ数を
追跡する。

【０１９６】ユーザカウントは、以下の式にしたがって
増加的な集計中にグループの重みを更新するため使用さ
れる。 new weight(GComplex)=((usersCount * old weight(GComplex)) + w)/ (usersCount + 1) 式中、ｗはユーザグループに新たに追加されたメンバー
の重みである。

【０１９７】総コンプレックステーブル：最後に、総コ
ンプレックステーブルは、全体的な総コンプレックス２
１１を格納する。各行は所定の時間的区間の総コンプレ
ックス２１１に対応する。このテーブルのフィールドに
は、開始日付、日数、週数、月数、年数、重み、偏差、
傾向、及び、ユーザグループカウントが含まれる。種々
の長さフィールドは、特定のコンプレックスに対し集計
が行われた期間を定義する。ユーザグループカウント
は、総計の集計に使用されるユーザグループの総数を格
納する。他のカウントと同様に、ユーザグループカウン
トは、増加的な集計の間に使用される。 new weight(TComplex) = ((usergroupCount * old weight(TComplex)) + w)/ (usergroupCount + 1) 式中、ｗは総コンプレックスに追加された新しいユーザ
グループコンプレックス２０９の重みである。

【０１９８】次に、ウェブイベントを集計するプロセス
を説明する。

【０１９９】Ａ．毎日のウェブイベント集計 スケジューラ９３４は、多数の時間的区間に亘ってウェ
ブイベントを集計情報に集計する多数のプロセスを始動
する。したがって、少なくとも毎日、スケジューラ９３
４は、図２にレベル０に示されるように、集計キュー７
２２からのウェブイベントを毎日集計される毎日集計イ
ベントに集めるためハンドラー９２０を呼び出す。ハン
ドラー９２０は、所定の日に関して集計キュー７２２か
らウェブイベントを要求し、受信する。キュー７２２
は、取得されたイベントを追跡し、所望の日に対応した
イベントを集めるハンドラーの要求に応じて、処理され
ていないイベントを供給する。

【０２００】集計システムは二つのサブシステムを組み
合わせて使用する。第一のサブシステムは、ウェブイベ
ント（このウェブイベントは集計システムの用語ではユ
ーザヒットと呼ばれる）から毎日の集計を生成する。第
二のシステムは、より上位レベルの集計（週単位の集
計、月単位の集計、３ヶ月単位の集計、年単位の集計、
カテゴリー全域の集計、ユーザ全域の集計、ユーザグル
ープ全域の集計）を生成し、このプロセスは次元結合と
呼ばれる。

【０２０１】毎日集計サービスは以下のように動作す
る。 １．ハンドラーオブジェクトは、集計キューからウェブ
イベントのパケットを取り出す。 ２．ハンドラーは、ウェブイベントの重みを計算し、そ
の重みを０から１００までの値に定めるため、パケット
を計算オブジェクトに送る。

【０２０２】非常に簡単な例について説明する。パケッ
トが二つのウェブイベントＡ及びＢしか含まない場合を
考える。ウェブイベントＡは、スコアが２００で間隔が
４分間のひとつのカテゴリーＣ１だけを収容し、ウェブ
イベントＢは、スコアが３００で間隔が２分間のひとつ
のカテゴリーＣ２だけを収容する場合を考える。最初
に、計算オブジェクトは、ウェブイベントＡ内でカテゴ
リーＣ１の重みを計算する。 weight(C1) = score(C1) * duration = 200*4 = 800 ウェブイベントＡには他のカテゴリーが存在しないの
で、ウェブイベントＢに移り、第２のウェブイベントで
カテゴリーＣ２重みを計算する。 weight(C2) = score(C2) * duration = 300*2 = 600 ウェブイベントＢには他のカテゴリーが存在しないの
で、重みの計算が終了する。次に、計算した数字、すな
わち、８００と６００を率に応じて定める必要がある。
スケーリングは８００と６００を以下の式にように置換
することにより行われる。８００に対し、 [800/(800+600)]*100=57.14% ６００に対し、 [600/(800+600)]*100=42.8% 次に、ウェブイベントＡのユーザIDとウェブイベントＢ
のユーザIDが同一であり、カテゴリーC1とカテゴリーC2
が同一である場合、集計器オブジェクトは二つの重みを
平均化し、 (57.14%+42.8%)/2 この平均を保持する。二つのウェブイベントＡ及びＢが
異なるユーザID若しくは異なるカテゴリーを有する場
合、平均化は行われず、二つの重み57.14%と42.8%が保
持される。

【０２０３】いずれの場合も、毎日集計オブジェクト内
で、各ペア（ユーザID、カテゴリー）は、０と１００の
間の１個の数字（パーセント数）を有し、この数字はペ
ア（ユーザID、カテゴリー）の重みと称される。ウェブ
イベントの１個のパケット内で１個の（ユーザID、カテ
ゴリー）ペアが多数のパーセント数（すなわち、多数の
重み）をもつとき、それらは平均化される（平均化は、
後述のようにパーサーがハッシュマップを集計器オブジ
ェクトに与えたときに、集計器オブジェクトで行われ
る）。

【０２０４】１．計算オブジェクトは、（スコアがスケ
ーリングされた重みである）ウェブイベントのパケット
をハンドラーオブジェクトに返し、ハンドラーはそのパ
ケットをパーサーオブジェクトに渡す。パーサーオブジ
ェクトは、パケットのデータ構造をベクトルからハッシ
ュマップに変換し、ハッシュマップを集計器オブジェク
トに与える。

【０２０５】２．集計器オブジェクトは、平均、分散、
傾向及び時間間隔(from,to)のような量を計算する。集
計器オブジェクトは、これらの量を計算するため、計算
オブジェクトのサービスを使用する。これらの量を計算
した後、集計器オブジェクトは更新(update)オブジェク
トの更新メソッドを呼ぶ。更新オブジェクトは（update
という語で始まる）多数のメソッドを有する。各メソッ
ドには特殊用途がある。たとえば、メソッドupdateDail
yAggregate()は、集計器によって生成された新しいハッ
シュマップからの増加的集計を使用してDailyAggregate
オブジェクト内の値を更新する。メソッドupdateUCComp
lex()は、集計ツリーのレベル０で変化した増加的集計
を利用して全てのUCComplexオブジェクトの値を更新
し、その他のメソッドも同様である。すなわち、次元集
計は、集計器がウェブイベントの１個のパケットの処理
を終了した直後に自動的に（増加的に）行われる。

【０２０６】したがって、更新オブジェクトは、毎日集
計システムと次元集計システムの二つのシステムの間で
データアクセスを実現する。毎日集計システムがウェブ
イベントのパケットの処理を終了すると、更新オブジェ
クトは、ウェブイベントの新しいパケットの処理に起因
して集計ツリーのレベル０で変更されたデータに基づい
て次元集計を増加的に始動させる。

【０２０７】次元集計の別の局面はスケジューリングで
ある。上述のように、次元集計は、毎日集計システムが
ウェブイベントの１個のパケットの処理を終了するたび
に、自動的に増加的に始まる。以下、スケジューリング
された次元集計を使用する理由を説明する。

【０２０８】ProReachシステムが動いているとき、メン
バーが存在する。メンバーとは、集中ProReachシステム
にアカウントを持っている人、若しくは、企業である。
ユーザＡはメンバーであるとする。ユーザＡは、ログイ
ン名及びパスワードと、（新規加入したときに）ProRea
chシステムによってユーザＡに与えられたID番号とをも
つ。ユーザＡがProReachシステムによって提供されるシ
ステムを使用したいとき、ユーザＡは、最初に集中ProR
eachシステムのウェブページを訪れ、自分のログイン名
及びパスワードを用いてログインする。ログインした
後、ユーザＡはサービスを使用することができる。ユー
ザＡが使用できるサービスの短いリストは以下のとおり
である。

【０２０９】ａ．（ウェブページで）問合わせを発行
し、問合わせへの回答がウェブページに示される。

【０２１０】問合わせは、プロフィール、ユーザグルー
プ、ある種のカテゴリーに関する関心などである。

【０２１１】ｂ．ユーザグループを作成し、ユーザＡが
作成したユーザグループにユーザが追加されるため満た
されるべきメンバーシップルールを設定する。ユーザＡ
は、各ユーザグループのメンバーを更新するとき、新メ
ンバーを追加するとき、各ユーザグループをデータベー
スに保持する期間をスケジュールすることができる。

【０２１２】ｃ．ユーザＡがウェブサイトを保有する場
合、ユーザＡは集中ProReachシステムに送信されるウェ
ブサイトのウェブトラヒックをもつことができ、それに
より、ProReachシステムは自分のサイトのウェブイベン
トを集計し、いつでもユーザＡからの問合わせに応じる
ことができるように分析の結果をProReachのデータベー
スに保持することができる。

【０２１３】これらのサービスは、ProReachシステムが
ウェブを通じて提供することができるサービスの例に過
ぎない。各サービスには料金がかかる。数種類のアカウ
ントが存在する。一部のアカウントは、ユーザに一組の
サービスを提供し、別のアカウントはより膨大なサービ
スの組をユーザに提供する。たとえば、ウェブサイトを
保有し、上記リストのサービスｃを使用するメンバー
（人又は企業）を想定する。このメンバーは、自分のウ
ェブサイトのウェブイベントに関する次元集計を行うと
きと、時間間隔とを選択する権利を有する。このような
メンバーは、自分のアカウントからこれらのタスクをス
ケジュールすることができる。この次元集計は、毎日集
計システムがウェブイベントの単一のパケットを処理し
終えたときに自動的に行われる次元集計とは異なる。

【０２１４】１．カテゴリースコアの重みへの変換 ハンドラー９２０は、最初に、計算パッケージ９２２に
対し、（ウェブイベントの単一のパケット内で）各ウェ
ブイベント９００のカテゴリースコアを間隔が調整され
たスコアに変換することを要求する。このステップはス
コアを正規化し、カテゴリースコアとイベントの間隔の
両方を別々に記憶する必要性を除く。正規化は、異なる
ウェブイベントが、任意のカテゴリー若しくはユーザに
関して、全体的な重要度を比較できるようにする。

【０２１５】計算オブジェクト９２２は、この機能を支
援するため以下のように動作する。ここで注意すべきこ
とは、各ウェブイベント９００がカテゴリー及びスコア
のベクトルを含むことである。計算オブジェクト９２２
は、ウェブイベントのパケット内で、各ウェブイベント
９００を順番に処理する。単一のウェブイベント９００
のカテゴリーベクトル内の各カテゴリーに対し、計算パ
ッケージ９２２は、ウェブイベントの間隔に応じて、か
つ、そのウェブイベントに対する他の全てのカテゴリー
スコアに基づいて、各カテゴリースコアの尺度を定め
る。一実施例において、スケーリングプロセスは以下の
通りである。

【０２１６】第一に、計算オブジェクト９２２は、ウェ
ブイベントの間隔とウェブイベントのタイプを用いて各
スコアを調整する。

【０２１７】NewScore＝Score*Duration*type 式中、NewScoreは調整済みのカテゴリースコア（０から
１００の範囲にスケーリングされた後には、重みと称さ
れる）を表し、Scoreは元のカテゴリースコアであり、D
urationは開始時刻と終了時刻の間の時間であり（ある
いは、直ちに得られる場合には間隔値であり、得られな
い場合に、間隔のデフォルト値は１分である）、type
は、ウェブイベントのタイプに依存した数である。たと
えば、ウェブイベントが取引である場合、タイプは、単
なるクリックスルーやページ閲覧よりも高い数である。
ページ閲覧のタイプは、クリックスルーのタイプよりも
高い。

【０２１８】次に、計算オブジェクト９２２は、調整済
みのスコアの合計に基づいて調整済みのスコアをスケー
リングする。

【０２１９】

【数２】 式中、ｎはカテゴリー数である（ウェブイベントのパケ
ット内の全カテゴリーである。ウェブイベントのパケッ
トは１０個のウェブイベントを収容する。各ウェブイベ
ントは２０個のカテゴリーを収容する。したがって、カ
テゴリーの総数は２００である）。ｉは各カテゴリーに
対し繰り返される。

【０２２０】このプロセスの結果は、各ウェブイベント
が元のカテゴリースコアの代わりに重みのリストを格納
することである。重みは、特定のウェブイベントの全て
のカテゴリーに関してカテゴリの重要度を簡潔に記述
し、特に、重みは、各カテゴリーのスコアを、時間的に
調整済みのスコアの全体に対するパーセンテージとして
記述する。

【０２２１】２．ユーザによるカテゴリー重みの順序付
けのためのウェブイベントレコードの再構成 ハンドラー９２０は、次にパーサー９２４を呼び出し、
ウェブイベント９００の更新されたパケットを渡す。パ
ーサー９２４は、集計オブジェクト９２６に入力するた
めパケットを再構築する。より詳細には、パーサー９２
４は、多数のウェブイベントレコード９００のカテゴリ
ー重みを、最初にユーザ順に、次に、カテゴリー順に揃
える。

【０２２２】図１６を参照するに、パーサー９２４の処
理機能の一例が示されている。パーサーは、入力とし
て、パケット９００を受け、パケット内の各ウェブイベ
ントは、一方でカテゴリーベクトル９０８を収容する。
上述の通り、ウェブイベントは、ユーザID９０２と、開
始時刻と、間隔と、タイプ（すなわち、取引、クリック
スルー、又は、ページ閲覧など）と、URL（訪れたウェ
ブサイトのドメイン名）と、Ｎ組の＜カテゴリー、重み
＞ペアとを含む。Ｎはカテゴリー数である。クリックス
ルー、取引、ページ閲覧などはウェブイベントを生成す
るので、種々のウェブイベントが異なるユーザに対応
し、同じユーザに多数のウェブイベントが対応する可能
性がある。

【０２２３】次に、非常に簡単な例を用いてパーサーオ
ブジェクトのタスクを説明する。ウェブイベントのパケ
ットが５個のウェブイベントwe1、we2、we3、we4及びwe
5しか含まない場合を考える。そして、最初の３個のウ
ェブイベントwe1、we2及びwe3は同じユーザID（たとえ
ば、Jack）をもつとする。さらに、カテゴリーCが３個
のウェブイベントwe1、we3、we5の中に存在するとす
る。また、ペア＜Jack，C＞に対し、３個の重みw1、w3
及びｗ５が与えられているとする。第１の重みw1は、第
１のウェブイベントwe1内のカテゴリーCの重みである。
したがって、ウェブイベントwe1内で、w1=weight（Jac
k，C）と表される。

【０２２４】第２の重みw3は、同じユーザJackと同じカ
テゴリーCに対する重みであるが、第３のウェブイベン
トwe3内の重みである。したがって、この重みは、ウェ
ブイベントwe3内で、w3=weight（Jack，C）と表され
る。

【０２２５】第３の重みw5は、同じユーザJackと同じカ
テゴリーCに対する重みであるが、第５のウェブイベン
トwe5内の重みである。したがって、この重みは、ウェ
ブイベントwe5内で、w5=weight（Jack，C）と表され
る。

【０２２６】パーサーオブジェクトは、シーケンス（w
1，w3，w5）をペア（Jack，C）に関連付ける。シーケン
ス（w1，w3，w5）は、異なる時点における重みのシーケ
ンスであり、曲線を描く（カテゴリーCに対するユーザJ
ackの関心を測定する時刻の関数である）。この関数
は、シーケンス（w1，w3，w5）だけを用いて与えられる
ので離散関数である。連続関数はグラフの形状をより明
瞭に示すので，理想的には連続関数が好ましい。このグ
ラフの形状は曲線であることがわかっている場合、カテ
ゴリーCに関するユーザJackの関心が時刻と共にどのよ
うに変化しているかがわかる。シーケンス（w1，w3，w
5）は、連続関数ではなく離散関数を表すので、変化に
関する情報を得るため，この離散関数に確率論のルール
を適用する。

【０２２７】この離散関数に対して最初に行われること
は、確率論においてランダム値の期待値と呼ばれる値を
計算することである。本例の場合、期待値は、単にシー
ケンス（w1，w3，w5）の重みの平均である。この平均は
統計学的な平均meanであり、集計オブジェクトによって
（計算オブジェクトを用いて）計算される。次に、集計
器が行うことは、確率論ではランダム値の分散variance
と呼ばれる誤差を計算することである。集計オブジェク
トが３番目に行うことは、値（w1，w3，w5）によって表
現された離散関数のグラフの形状を粗く判定することで
ある。すなわｔ、増加曲線であるか、減少曲線である
か、あるいは、増加曲線と減少曲線の組み合わせである
かなどが判定される。この曲線の形状は傾向trendと呼
ばれる。傾向が判定された後、集計器オブジェクトは、
ある種のデータ構造（たとえば、ハッシュマップ、ハッ
シュテーブルなど）の形として、これらのデータ（平均
mean、分散variance、傾向trend）をペア（Jack，C）に
関連付ける。集計器は、この処理を全てのペア（ユー
ザ、カテゴリー）に対し行う。

【０２２８】集計器が上記の一連の処理を終了したと
き、その結果（ハッシュマップ，ハッシュテーブルな
ど）は、本明細書で毎日集計DailyAggregateと称するオ
ブジェクトを形成する。したがって、毎日集計DailyAgg
regateは、ペア（ユーザ、カテゴリー）を収容するオブ
ジェクトであり、各ペア（ユーザ、カテゴリー）毎にソ
ートデータ（平均、分散、傾向）が関連付けられる。さ
らに、ウェブイベントのパケットによってカバーされた
時間的間隔であるタイムスタンプが設けられる。

【０２２９】以上の通り、毎日集計DailyAggregationシ
ステムは、ウェブイベントの一つのパケットを処理し、
毎日集計DailyAggregateオブジェクトを生成する。

【０２３０】毎日集計システムが（毎日集計DailyAggre
gateオブジェクトを生成することによって）ウェブイベ
ントのパケットの処理を終了したとき、毎日集計システ
ムは、集計キューAggregationQueueから別のウェブイベ
ントのパケットを獲得する。毎日集計システムは、集計
キューからのウェブイベントをパケット単位で処理し続
ける。

【０２３１】以下では、毎日集計DailyAggregationサー
ビスを最初に開始する場合を考える。毎日集計システム
は、集計キューからウェブイベントの第１のパケットpa
cket1を取得する。第１のパケットの処理後に、毎日集
計システムは、毎日集計DailyAggregateオブジェクトを
生成する。この毎日集計オブジェクトをagg1とする。次
に、毎日集計システムは、再び集計キューからウェブイ
ベントの第２のパケットpacket2を取得し、第２のパケ
ットを処理する。第２のパケットpacket2の処理後、毎
日集計システムは第２の毎日集計オブジェクトagg2を生
成する。第２の毎日集計オブジェクトagg2は、第１の毎
日集計オブジェクトagg1と併合され、一つの集計オブジ
ェクトagg12を形成する。融合された後、毎日集計オブ
ジェクトagg1及びagg2は存在しなくなり、集計オブジェ
クトagg12だけがデータベースに存在する。オブジェク
トagg1とagg2の融合は、メソッドupdateDailyAggregate
()を用いて更新オブジェクトよって実行される増加的集
計である。新しい集計オブジェクトagg12は、最初の２
個のパケットpacket1及びpacket2の組み合わせであるウ
ェブイベントの単一のパケットの処理結果を表す。

【０２３２】毎日集計オブジェクト（すなわち、集計オ
ブジェクト）は、図２に示された集計ツリーのレベル０
のデータである。一日毎に１個の毎日集計DailyAggrega
teオブジェクトによって表現される。

【０２３３】その結果として，典型的にウェブサイトの
ビジット中に出現し、２０乃至１００個、あるいは、そ
れ以上のウェブイベントを生成する多数のウェブイベン
トレコードと関連付けられた所定のユーザについて、多
数の異なるレコードからのカテゴリー重みが収集され、
単一のハッシュカテゴリーテーブル１１００に順序正し
く並べられ、カテゴリー毎に、全ての重み及び開始時刻
がまとめて詰め込まれる。これにより、一日のユーザの
ウェブ行動に関してウェブイベントレコードが収集した
全ての関連情報は、単一のデータソースから入手できる
ようになる。

【０２３４】３．カテゴリー関心時間モデル情報の作成
上記ステップの結果として、処理当日にウェブサーバー
１０２に現れたユーザ毎に一つのユーザ・カテゴリー・
テーブル１１００が得られる。これらのユーザ・カテゴ
リー・ハッシュテーブル１１００毎に、ハンドラー９２
０は集計エンジン９２６を呼び出す。集計エンジン９２
６は、これらのテーブルを処理し、ユーザ毎にカテゴリ
ー関心時間モデル情報を得る。要約された情報は、収集
されたうウェブイベントレコードの当日における多数の
カテゴリーに関する特定のユーザの関心を記述する。集
計エンジン９２６は、受け取ったユーザ・カテゴリー・
ハッシュテーブル毎に以下のように動作する。

【０２３５】第一に、カテゴリーテーブル１１００に対
し、集計エンジン９２６は、開始時刻を用いてカテゴリ
ーの重みリスト１１０２をソートする。集計エンジン９
２６は、好ましくは，計算パッケージ９２２内のソーテ
ィングルーチンを呼び出すことによってソートを行う。
この結果として、本質的に曲線であるデータ点の集合が
得られる。この曲線は、最初の開始時刻から最後の開始
時刻までの時間的区間におけるそのカテゴリーに関する
ユーザの関心のレベルを示す。図１７には、たとえば、
カテゴリー："Art Deco"に対するカテゴリー関心曲線１
２００が示されている。このグラフには、当該カテゴリ
ーに関連した１４個のウェブイベントのデータが、開始
時刻順にソートされて示されている。このグラフから、
ユーザの関心が最初は非常に高く、次に降下し、その後
再び上昇したことがわかる。

【０２３６】次のステージの目標は、各カテゴリー関心
曲線１２００を数学的に取得し、その基礎となる重みリ
ストの重みデータ及び時刻データを記憶する必要性を無
くすことである。より詳細には、カテゴリー毎に、集計
エンジン９２６は、時間的区間（たとえば、１日）のカ
テゴリー関心曲線１２００の期待値を決定する。一実施
例において，集計エンジン９２６は、時間的区間中のカ
テゴリーに関する平均重み及び重みの標準偏差を判定す
る。この平均重みは、当該カテゴリーに関する重みリス
ト１１０２内の全ての重みの合計を、重みの個数、すな
わち、この時間的区間中にこのユーザに対するウェブイ
ベントの数で割り算した値である。標準偏差は通常とお
りに計算される。また、これらの計算は、好ましくは、
集計エンジン９２６の要求に応じて計算パッケージ９２
２を用いて行われる。

【０２３７】集計エンジン９２６は、次に、カテゴリー
関心曲線に対する傾向trend説明情報を作成する。傾向
説明情報は、曲線によって表現された時間的区間におけ
るカテゴリーに関するユーザの関心レベルの変化を記述
する。好ましくは、この傾向説明情報は文字列の説明文
（あるいは、符号化された等価物）である。

【０２３８】一実施例において、この傾向を獲得するた
め、集計エンジン９２６は、最初に、最先開始時刻の重
みと平均重みの差をとる。この差は、曲線が最先開示時
刻に対して、増加的、減少的、若しくは、一定であるこ
とを示す。次に、集計エンジン９２６は、平均重みと最
新開始時刻の重みの差を取り、同様に、この曲線が減少
的、増加的、若しくは、一定のいずれであるかを判定す
る。このようにして、以下の９通りの傾向が得られる。 １．増加、減少 ２．増加、一定 ３．増加、増加 ４．一定、減少 ５．一定，一定 ６．一定、増加 ７．減少，減少 ８．減少，一定 ９．減少、増加 集計エンジン９２６は、適切な時間的傾向を判定し、カ
テゴリーについての時間的傾向の情報を記憶する。記憶
される情報は、文字列自体（「増加」、「減少」及び
「一定」）でもよく、あるいは、これらの文字列に対応
した符号値（たとえば、「増加」に対応した値１など）
でもよい。勿論、更に複雑な時間傾向説明情報を得るた
めに、３箇所以上の時点と、三つ以上のセグメントを選
択してもよい。

【０２３９】集計エンジン９２６は、カテゴリー関心曲
線の時間的傾向を判定するため他の方式を採用してもよ
い。他の実施例において、集計エンジン９２６は、最先
開始時刻の時点若しくはその付近、最新開始時刻の時点
若しくはその付近、及び、これら二つの時点の間にある
多数の時点を含む多数のサンプル時点を選択する。最初
に選択された時点からはじめて，集計エンジン９２６
は、曲線が次の選択時点に対し増加的であるか、減少的
であるか、あるいは，一定であるかを判定し、文字列若
しくは符号等価物を曲線のその部分に割り当てる。たと
えば、一実施例において、最先開始時刻と、中間開始時
刻と、最新開始時刻の３箇所の時点が選択される。これ
らの三つの時点によって二つの曲線セグメントが形成さ
れ、集計エンジン９２６は、曲線が増加的、減少的、若
しくは、一定のいずれであるかをセグメント毎に判定す
る。

【０２４０】更に別の実施例では、集計エンジン９２６
は、カテゴリー関心曲線の勾配が正から負に変化する時
点を識別し、開始時刻と、時間的区間に関する適切な説
明情報とを共に記憶することにより、時間的傾向を判定
する。

【０２４１】時間的傾向情報を使用することにより、集
計エンジン９２６は、所定の日に対するユーザのカテゴ
リー関心の完全な記述を有する。より詳細には、集計エ
ンジン９２６は、後で使用するため、以下のようなカテ
ゴリー時間パターンモデルを格納する。 ｛ユーザID(User ID)、カテゴリーID(Category ID)、平
均カテゴリー重み(MeanCategory Weight)、カテゴリー
重み標準偏差(Category Weight Standard Deviation)、
始まり(From)、終わり(To)、傾向(Trend)｝ここで、Fro
mは、重みリスト１１０２に格納された最先開始時刻で
あり、Toは最新開始時刻であり、Trendは曲線変化の説
明情報（文字列若しくは符号化情報）である。

【０２４２】未加工のウェブイベントからの基本的なカ
テゴリー重み情報は、ここで削除してもよく，カテゴリ
ー時間パターンモデルはユーザ・カテゴリーテーブルの
データベース７２０に記憶される。このプロセスは、ユ
ーザ・カテゴリー・ハッシュテーブル１１００内のカテ
ゴリー重みリスト毎に繰り返される。

【０２４３】Ｂ．次元結合 結合器９３８は、種々のコンプレックスの毎日集計され
た情報が要約されたコンプレックス情報を結合するため
のコンポーネントである。結合器オブジェクトによって
行われる次元集計タスクは、一部のメンバーによって行
われるスケジューリングタスクに対応する。いつでも行
われる自動（増加的）次元集計は、更新オブジェクトに
よって実行される。

【０２４４】再度図２を参照するに、ProReachによって
提供され、特に、結合器９３８によって計算された多数
の集計情報のレベルが示されている。結合器９３８は、
与えられたカテゴリー関心時間パターン情報の組を、ユ
ーザ、カテゴリー、又は、時間的区間の任意の組み合わ
せに関して結合するよう設計される。図２には、集計情
報の種々のレベルに関する結合器９３８の動作が示され
ている。

【０２４５】一般的に、図２に示された各集計コンプレ
ックスは、データベース７２０の各テーブルに関して説
明されたように重み値を格納する。重み値は、評価中の
コンプレックスに寄与する全てのコンプレックスの重み
値に関して動作する集計関数によって計算される。たと
えば、特定のユーザグループが１００人のメンバーを有
する場合、ユーザグループコンプレックスに対する重み
は、全てのグループメンバーのユーザコンプレックスの
重みの関数である。同様に、ユーザコンプレックスの重
み（全カテゴリーに関して相対的なユーザの全体的関
心）は、ユーザに対する全てのユーザ・カテゴリーコン
プレックスの重み（特定の各ユーザ・カテゴリー関心）
の関数である。

【０２４６】一実施例において，集計関数は平均重み値
である。他の実施例では、異なる集計関数が使用され，
好ましくは、集計関数は要求に応じて選択される。この
ため、説明の便宜上、一般的に集計関数について説明
し、平均重み集計関数を使用する具体例を提示する。

【０２４７】レベル１には、ユーザ・カテゴリー(User-
Category)コンプレックス２０３と、カテゴリー(Catego
ry)コンプレックス２０５の２タイプの集計データがあ
る。カテゴリーコンプレックス２０５は、１週、１月、
３ヶ月などの選択された時間的区間における全ユーザ及
び特定カテゴリーに関するカテゴリー重みの集計関数に
よって計算される。望ましいカテゴリーのカテゴリーI
D、開始日付及び終了日付は、結合器９３８に渡され
る。結合器９３８は、カテゴリーID及び時間的区間を与
え、ユーザ・カテゴリーテーブルから照合レコードを取
得することによって、データベース７２０から適切なカ
テゴリー関心時間モデルを獲得する。獲得されたレコー
ドに対するカテゴリー重み平均は、コンプレックスに対
する最終値を生成するため集計関数によって処理され
る。集計関数が平均化関数であるとき、平均値は，平均
化される日数に亘って取得された重みの合計をこの日数
で除算した結果である。得られた集計重み値は、カテゴ
リーID、分散、傾向、開始日付及び終了日付と共に、カ
テゴリーコンプレックステーブルに格納される。このコ
ンプレックスに対し、傾向は、集計された重み値が、前
の値よりも増加的、減少的、若しくは、一定のいずれで
あるかによって判定される。

【０２４８】ユーザ・カテゴリーコンプレックス２０３
の場合、プロセスは類似しているが、所定の時間的区間
の特定ユーザに限定される。得られた結果はユーザ・カ
テゴリーコンプレックステーブルに記憶される。

【０２４９】レベル２には、グループ・カテゴリー(Gro
up-Category)コンプレックス２０５とユーザコンプレッ
クス２０７とがある。グループ・カテゴリーコンプレッ
クス２０５を獲得するため、結合器９３８は、ユーザ・
カテゴリーコンプレックステーブルから、指定されたユ
ーザグループに対する全てのユーザ・カテゴリーコンプ
レックス２０５を取得する。ユーザグループメンバーシ
ップ情報は、データベースにプロフィールテーブルの形
で記憶され、プロフィールテーブルはユーザID毎に、ユ
ーザがメンバーとして属するグループを識別する。グル
ープIDが与えられたとき、結合器９３８は、このグルー
プのユーザを識別することができ、それらのユーザ毎に
ユーザ・カテゴリーコンプレックス２０５を獲得するこ
とができる。獲得されたコンプレックスの重みは、適切
な集計関数を用いて集計され、得られた結果がグループ
・カテゴリー(Group-Category)コンプレックステーブル
に格納される。

【０２５０】特定ユーザに対するユーザコンプレックス
２０７を作成するため、合成器９３８は、ユーザのユー
ザIDと、所望の開始時刻及び終了時刻とが与られた場合
に、ユーザ・カテゴリーコンプレックステーブルからユ
ーザ・カテゴリーコンプレックスを獲得し、重みを集計
する。得られた結果はユーザコンプレックステーブルに
格納される。

【０２５１】レベル３にはグループ(Group)コンプレッ
クス２０９が存在する。グループコンプレックスを作成
するため、結合器９３８は、ユーザ・コンプレックステ
ーブルから、所望のユーザグループに対するユーザグル
ープIDと、所望の開始から終了までの間隔とを使用し
て、全てのユーザコンプレックス２０７を取得する。得
られた結果はグループコンプレックステーブルに格納さ
れる。好ましくは、所定のグループに対するユーザコン
プレックス２０７を獲得するとき、結合器９３８は、ユ
ーザグループ規準テーブルについて問合わせを行い、各
ユーザが現在所望のユーザグループのメンバーであるこ
とを確認し、集計が行われるときにメンバーであるユー
ザだけを対象に含める。

【０２５２】最後に、総(Total)コンプレックス２１１
が図２のレベル４に示される。総コンプレックスを作成
するため、結合器９３８は、グループコンプレックステ
ーブルから指定された時間的区間における利用可能な全
グループコンプレックス２０９を取得し、それらの重み
を集計する。得られた結果は総コンプレックステーブル
に格納される。

【０２５３】上述の通り、一実施例において、重みの集
計関数は平均化関数であり、任意の望ましいコンプレッ
クスに対し、重み値は、所望のコンプレックスに寄与す
るコンプレックスの重み値の平均である。

【０２５４】より詳細には，集計サービスは、コンプレ
ックスのタイプ毎に、使用されるべき集計関数を定義す
るコンフィギュレーションファイルを格納する。さら
に、コンフィギュレーションファイルは、コンプレック
ス毎に、コンプレックスが消去されるまでデータベース
に記憶されるべき期間を定義する寿命値を格納する。

【０２５５】Ｃ．ユーザグループシステム ユーザグループマネージャ９３６は、ユーザグループを
定義、保持し、特定のグループ内のユーザのメンバーシ
ップに関する問合わせに応答する役割を担う。上述の通
り、各ユーザグループは、規準テーブルに格納された一
つ以上のメンバーシップルールを有する。ユーザグルー
プマネージャ９３６は以下の関数を含む。

【０２５６】ユーザグループのリスト取得 Get List o
f User Group：ユーザグループテーブルからユーザグル
ープのリストを返す。

【０２５７】グループサイズの取得 Get Group Size(U
ser Group)：指定されたユーザグループのサイズを返
す。

【０２５８】ユーザ所属グループの取得 Get Which Gr
oup User Belongs To(User)：指定されたユーザがメン
バーとして属するグループのリストを返す。

【０２５９】グループ説明情報の取得 Get Group Desc
ription(User Group)：ユーザグループテーブルから指
定されたユーザグループの説明情報を返す。

【０２６０】グループのユーザ取得 Get Users of Gro
up(User Group)：プロフィールテーブルを再検証するこ
とによって現在メンバーであるユーザのリストを返す。

【０２６１】グループへのユーザ追加 Add User to Gr
oup(User, User Group)：指定されたユーザが指定され
たグループのメンバーシップルールを満たすかどうかを
試験し、満たす場合にそのユーザをプロフィールテーブ
ル内でグループに追加する。

【０２６２】この関数は、新しいユーザがユーザテーブ
ルに追加されるときにも実行され、ユーザグループマネ
ージャ９３８は、ユーザグループ規準テーブル内の既存
の各グループに対して新しいユーザを試験し、そのユー
ザがメンバーシップルールを満たす各ユーザグループの
プロフィールテーブルを更新する。

【０２６３】グループからユーザ削除 Remove User fr
om Group(User, User Group)：プロフィールテーブル内
で指定されたユーザグループから指定されたユーザを削
除。

【０２６４】メンバーシップルールの定義 Define Mem
bership Rule(Category, Minimum,Maximum, Negatio
n)：新しいメンバーシップルールを規準テーブルに追加
する。たとえば、カテゴリー"Auto Racing Enthusiast
s"を定義するため、規準が以下の通り定義される。

【０２６５】AUTO_RACING_GROUP=user.category(auto_r
acing)>80これは、特定ユーザに対する"Auto racing"カ
テゴリーの重みが８０よりも大きいということを意味す
る。

【０２６６】したがって、"Auto racing"カテゴリーにM
inimum=0及びNegation=Noが渡される。

【０２６７】ルールの削除 Delete Rule(Criterion)：
規準Criterionテーブルから指定されたメンバーシップ
ルールを削除する。

【０２６８】グループのルール定義 Define Rule for
Group(User Group, Criterion)：ユーザグループ規準テ
ーブルの指定されたユーザグループに指定された規準を
追加する。

【０２６９】グループからのルール削除 Delete Rule
from Group(User Group, Criterion)：ユーザグループ
規準テーブルの指定されたグループから指定された規準
を削除する。

【０２７０】上記の全ての関数は、ユーザ及びユーザグ
ループテーブルを自動的に更新するため、周期的に実行
されるようにスケジューラ９３４を用いてスケジューリ
ングされる。

【０２７１】Ｄ．毎日の集計(Daily Aggregation) 毎日問合わせDailyQueryオブジェクト９３２（毎日集計
システムの一部）は、毎日の集計に対し多数のカテゴリ
ー重みで表現されるようなユーザ関心レベルに関する問
合わせに応答する役割を担う。１日は、単一の毎日集計
オブジェクトによって表現される。毎日問合わせオブジ
ェクトは、毎日問合わせオブジェクトに関する全種類の
情報、たとえば、対応した日付、ユーザは誰か、最も活
動的なユーザは誰か、どのようなカテゴリーがあるか、
最も重要なカテゴリー（ユーザに対し最大の重みを有す
るカテゴリー）は何かのような情報を獲得できるように
する。

【０２７２】Ｅ．アフィニティ(Affinity)グループマネ
ージャ アフィニティグループマネージャ９３６は、相互に関連
したユーザグループを識別する役割を担う。アフィニテ
ィグループは、関心に関連した規準と、ブール代数論理
を用いて結合された（たとえば、特別会員データベース
からの）他のカスタマプロフィール情報とによって定義
される。たとえば、年齢(age)、収入(income)、及び、
学歴(education)の人口統計学を用いて、以下のメンバ
ーシップ条件によってアフィニティグループ"yuppie sp
ortsters"を定義することがでいる。

【０２７３】 age <= 35 AND (income > 60,000 OR education >= undergraduate) AND interest(sports) > 1.5 この例では、特別会員データは、相対的な関心ProReach
データと結合される。アフィニティグループ"yuppie sp
ortsters"は、通常のユーザグループについての問合わ
せと同じ方法で問い合わせることができる。本例の場
合、グループメンバーシップの計算は、高価な演算であ
るため、アフィニティグループは、メンバーシップ再計
算コマンドrecalculateMembership()を有し、最後の再
計算を記憶する。

【０２７４】アフィニティグループが作成された後、個
別のユーザのイベントレコードはアフィニティグループ
に集められるが、アフィニティグループ自体は他のグル
ープ若しくはコンプレックスに集められない。かくし
て、数回の集計サイクル中に拒否され続けた後、アフィ
ニティグループはより有用になるが、管理者は自由にア
フィニティグループを除去することができる。

【０２７５】アフィニティグループマネージャ９３６は
以下の機能を提供する。

【０２７６】１．アフィニティグループ並びに市場取引
者カスタムメードアフィニティグループの自動作成２．
アフィニティグループに対するユーザの自動追加／自動
削除３．アフィニティグループについて質問し、アフィ
ニティグループを操作するメソッド上記３．に含まれる
メソッドを以下に列挙する。

【０２７７】getListOfAffinityGroups：アフィニティ
グループのリストを返す howManyUsersIn(AffinityGroup group)：指定されたア
フィニティグループ内のユーザ数を返す toWhichAffinityGroupsBelong(String user)：指定され
たユーザが所属する全てのアフィニティグループのリス
トを返す getUsersIn(AffinityGroup group)：指定されたアフィ
ニティグループ内の全ユーザのリストを返す add(AffinityGroup, user)：これは指定されたユーザを
指定されたアフィニティグループに追加する remove(AffinityGroup, user)：これは指定されたユー
ザを指定されたアフィニティグループから削除する。

【０２７８】Ｆ．更新オブジェクト 更新オブジェクト９４０は、図２を参照して説明したよ
うに、毎日の集計を増加的に更新し、集計ツリーのコン
プレックスを更新する役割を担う。増加的な更新は、毎
日集計システムがウェブイベントの単一のパケットを処
理し終えたときに行われる。増加的な更新は、レベル１
のコンプレックスから順番に集計ツリーを昇りながら各
コンプレックスに適用される。増加的な更新のための式
は、多数のコンプレックステーブルに関して既に説明し
た。この増加的な更新は、自動的に、（毎日集計システ
ムがパケットの処理を終了したとき）常時行われる。こ
の増加的な更新は、結合器オブジェクトによって行われ
るタスクとは異なる。結合器オブジェクトは、（特定の
オブジェクトに対する）メンバーの要求時に次元集計を
行う。更新オブジェクトは次元集計システムの一部であ
る。更新オブジェクトは、毎日集計システムと次元集計
システムの間の出入口である。

【０２７９】Ｇ．スケジューラ スケジューラ９３４は、データベース７２０の保守に関
係した多数のタスクの実行をスケジューリングする。ス
ケジューラ９３４は、ユーザが定義した周期に基づいて
以下のタスクを実行することができる。

【０２８０】１．所与のカテゴリーに対し、ユーザ及び
時間的区間に関する集計（カテゴリーは集計の間、固定
される）。この集計の結果はカテゴリーコンプレックス
である。

【０２８１】２．所与のユーザ及びカテゴリーに対し、
時間的区間に関する集計（ユーザ及びカテゴリーは、集
計の期間中、固定される）。この集計の結果は、ユーザ
・カテゴリーコンプレックスである。

【０２８２】３．所与のカテゴリー及びユーザグループ
に対し、所与のユーザグループ内のユーザ及び時間的区
間に関する集計（カテゴリー及びユーザグループは、集
計の期間中、固定される）。この集計の結果は、グルー
プ・カテゴリーコンプレックスである。

【０２８３】４．所与のユーザに対し、全カテゴリー及
び時間的区間に関する集計（ユーザは、集計の期間中、
固定される）。この集計の結果は、ユーザ・カテゴリー
コンプレックスである。

【０２８４】５．所与のユーザグループに対し、所与の
ユーザグループ内のユーザ、全カテゴリー、及び、時間
的区間に関する集計（ユーザグループは集計の期間中、
固定される）。

【０２８５】６．全ユーザグループ、全カテゴリー、及
び、時間的区間に関する集計。この集計の結果は総コン
プレックス２１１であり、全ウェブ行動の総集計を表
す。

【０２８６】７．一日の結果の削除 ８．カテゴリーコンプレックスオブジェクトの削除 ９．ユーザ・カテゴリーコンプレックスオブジェクトの
削除 １０．グループ・カテゴリーコンプレックスオブジェク
トの削除 １１．ユーザコンプレックスオブジェクトの削除 １２．グループコンプレックスオブジェクトの削除 １３．総コンプレックスオブジェクトの削除 １４．集計キューからのウェブイベントレコードの獲得
の頻度。頻度はスケジューリング可能であり、ハンドラ
ーは、たとえば、１５分毎、１時間毎、１分毎にイベン
トレコードを獲得する。

【０２８７】上記の各タスクは、スケジューラ９３４内
で対応したタスク番号によって識別される。タスクをス
ケジュールするため、このスケジュールは以下の関数を
提供する。

【０２８８】Schedule(task, startTime, maxDuration,
frequency, timeInterval)：taskは、上記のタスクの
中から一つのタスクを番号で識別する。startTimeは、
タスクが実行される時刻を識別する。maxDurationは、
タスクが終了するために要する最大時間を指定する。こ
の最大時間を経過してもタスクが終了しない場合、その
タスクのプロセスは停止される。timeIntervalは、タス
クが実行されるべき時間的区間、たとえば、毎日、毎
週、毎月などを指定する。frequencyは、タスクが定義
された時間的区間内に実行されるべき回数である。

【０２８９】Ｈ．イベントディスパッチャ イベントディスパッチャ９３０は、集計サービスのイベ
ント駆動型管理を行い、特に、データベース内の多数の
コンプレックステーブル、ユーザテーブル、及び、カテ
ゴリーテーブルの管理を行う。イベントディスパッチャ
９３０は以下のイベントを発送することができる。

【０２９０】１．CComplexBeginEvent：このイベント
は、ユーザ及び多数の日数に関する集計の開始の際に、
（CComplexオブジェクトを生成するため）イベントディ
スパッチャ９３０によって処理される。

【０２９１】２．CComplexEndEvent：このイベントは、
ユーザに関する集計の終了の際に（すなわち、CComplex
オブジェクトが作成された後）、イベントディスパッチ
ャ９３０によって処理される。

【０２９２】３．UCComplexBeginEvent：このイベント
は、毎日の結果に関する集計の開始の際に、（UCComple
xオブジェクトを生成するため）イベントディスパッチ
ャ９３０によって処理される。

【０２９３】４．UCComplexEndEvent：このイベント
は、ユーザに関する集計の終了の際に（すなわち、UCCo
mplexオブジェクトが作成された後）、イベントディス
パッチャ９３０によって処理される。

【０２９４】５．GCComplexBeginEvent：このイベント
は、UCComplexオブジェクトに関する集計の開始の際
に、（GCComplexオブジェクトを生成するため）イベン
トディスパッチャ９３０によって処理される。

【０２９５】６．GCComplexEndEvent：このイベント
は、UCComplexオブジェクトに関する集計の終了の際に
（すなわち、GCComplexオブジェクトが作成された
後）、イベントディスパッチャ９３０によって処理され
る。

【０２９６】７．UComplexBeginEvent：このイベント
は、UCComplexオブジェクトに関する集計の開始の際
に、（UComplexオブジェクトを生成するため）イベント
ディスパッチャ９３０によって処理される。

【０２９７】８．UComplexEndEvent：このイベントは、
UCComplexオブジェクトに関する集計の終了の際に（す
なわち、UComplexオブジェクトが作成された後）、イベ
ントディスパッチャ９３０によって処理される。

【０２９８】９．GComplexBeginEvent：このイベント
は、UComplexオブジェクトに関する集計の開始の際に、
（GComplexオブジェクトを生成するため）イベントディ
スパッチャ９３０によって処理される。

【０２９９】１０．GComplexEndEvent：このイベント
は、UComplexオブジェクトに関する集計の終了の際に
（すなわち、GComplexオブジェクトが作成された後）、
イベントディスパッチャ９３０によって処理される。

【０３００】１１．TComplexBeginEvent：このイベント
は、GComplexオブジェクトに関する集計の開始の際に、
（TComplexオブジェクトを生成するため）イベントディ
スパッチャ９３０によって処理される。

【０３０１】１２．TComplexEndEvent：このイベント
は、GComplexオブジェクトに関する集計の終了の際に
（すなわち、TComplexオブジェクトが作成された後）、
イベントディスパッチャ９３０によって処理される。

【０３０２】１３．UserGroupAddEvent：このイベント
は、ユーザがユーザグループのメンバーになるとき（す
なわち、ユーザがユーザグループに追加されるとき）、
イベントディスパッチャ９３０によって処理される。

【０３０３】１４．UserGroupRemoveEvent：このイベン
トは，ユーザグループのメンバーがユーザグループから
削除されるとき、イベントディスパッチャ９３０によっ
て処理される。

【０３０４】１５．UserGroupCreatedEvent：このイベ
ントは、新しいユーザグループが作成されるとき、イベ
ントディスパッチャ９３０によって処理される。

【０３０５】１６．UserGroupDeletedEvent：このイベ
ントは、ユーザグループが削除されるとき、イベントデ
ィスパッチャ９３０によって処理される。

【０３０６】１７．UserGroupTestBeginEvent：このイ
ベントは、ユーザグループマネージャが、ユーザグルー
プのメンバーがユーザグループメンバーシップテストを
満たしているか否かをテストするとき、イベントディス
パッチャ９３０によって処理される。

【０３０７】１８．UserGroupTestEndEvent：このイベ
ントは、ユーザグループマネージャUserGroupManagerク
ラスがユーザグループメンバーシップテストを終了した
とき、イベントディスパッチャ９３０によって処理され
る。

【０３０８】１９．CComplexDeletedEvent：このイベン
トは、CComplexオブジェクトが削除されたとき、イベン
トディスパッチャ９３０によって処理される。

【０３０９】２０．UCComplexDeletedEvent：このイベ
ントは、UCComplexオブジェクトが削除されたとき、イ
ベントディスパッチャ９３０によって処理される。

【０３１０】２１．GCComplexDeletedEvent：このイベ
ントは、GCComplexオブジェクトが削除されたとき、イ
ベントディスパッチャ９３０によって処理される。

【０３１１】２２．UComplexDeletedEvent：このイベン
トは、UComplexオブジェクトが削除されたとき、イベン
トディスパッチャ９３０によって処理される。

【０３１２】２３．GComplexDeletedEvent：このイベン
トは、GComplexオブジェクトが削除されたとき、イベン
トディスパッチャ９３０によって処理される。

【０３１３】２４．TComplexDeletedEvent：このイベン
トは、TComplexオブジェクトが削除されたとき、イベン
トディスパッチャ９３０によって処理される。

【０３１４】２５．DailyResultCreatedEvent：このイ
ベントは、毎日の結果が作成されたとき、イベントディ
スパッチャ９３０によって処理される。

【０３１５】２６．DailyResultsDeletedEvent：このイ
ベントオブジェクトは、毎日の結果が削除されたとき、
イベントディスパッチャ９３０によって始動される。

【０３１６】イベントディスパッチャ９３０は、これら
のイベントを集計サービスのほかのコンポーネントに送
ることによって、このようなコンポーネントをイベント
に適切に応答させることができる。たとえば、更新マネ
ージャは、適切なコンプレックスの増加的な更新を行う
ため、DailyResultsAddedEventに応答する。

【０３１７】Ｉ．プロフィールシステム プロフィールシステム９５５は、プロフィールに関する
全ての問合わせに応答するプロフィール問合わせProfil
eQueryという名称のオブジェクトを提供する。このサー
ビスには、プロフィールの管理を担うプロフィールマネ
ージャオブジェクトが含まれる。このような管理は、た
とえば、以下のプロフィール共有化が含まれる。メンバ
ーＡは、集中ProReachシステムのデータベース内に自分
のウェブサイトのプロフィールを保持する。別のメンバ
ーＢが、そのプロフィールの一部（たとえば、エレクト
ロニクスに高い関心を示すプロフール）を保有したい場
合を考える。メンバーＢは、自分専用のプロフィールを
所有しないにもかかわらず、上記プロフィールの一部を
受け取りたい。このような要求を処理し、どのプロフィ
ールが共有されているかの記録を保持することは、全て
プロフィールマネージャオブジェクトによって行われ
る。

【０３１８】より具体的には、プロフィール問合わせオ
ブジェクトは、ユーザプロフィールに関する問合わせを
処理する役割を担う。プロフィール問合わせオブジェク
トは、ユーザIDを指定する問合わせを受け、プロフィー
ルテーブルからそのユーザのグループのメンバーシップ
情報を取得し、ユーザ・カテゴリーテーブルから問題の
カテゴリーに関するそのユーザの関心情報（たとえば、
重み、分散、若しくは、傾向情報）を獲得する。問合わ
せオブジェクトは、取得した情報からユーザプロフィー
ルを作成する。ユーザプロフィールには、ユーザが現在
メンバーとして属するユーザグループの現在ユーザグル
ープリストと、ユーザがある時間的区間に亘り新しいメ
ンバーとして属するグループ、及び、ユーザがメンバー
から外れたグループを識別するグループ変更履歴リスト
と、カテゴリー重みに基づいて関心の程度が上位Ｎ番
目、たとえば、上位１０番目までのカテゴリーのリスト
の中の少なくとも一つの項目が含まれる。カテゴリーリ
ストは、販売目的用にユーザの将来の関心を予測するた
め、増加傾向を示すカテゴリーだけを収容するように改
良してもよい。

【０３１９】好ましい一実施例において、ローカルとグ
ローバルの２種類のユーザプロフィールが保持される。
ローカルユーザプロフィールは、ウェブサイトを訪れた
ユーザから収集したウェブイベント情報を用いて、ProR
each使用可能ウェブサイト１００毎に保持される。グロ
ーバルユーザプロフィールは、ホストシステム１０３若
しくはグローバルサーバー１１２によって保持され、ユ
ーザ毎のローカルユーザプロフィールから作成される。

【０３２０】Ｊ．ＡＱＬシステム ユーザグループマネージャ(UserGroup Manager)オブジ
ェクト９３６、毎日問合わせ(DailyQuery)オブジェクト
９３２、及び、プロファイラ(Profiler)オブジェクト７
２６は、システム管理者(及び、ProReachシステムの多
数のメンバー)がユーザの関心、カテゴリー、グループ
などに関する問合わせを形成することができる機構を必
要とする。一実施例において，この機構は、集計問合わ
せ言語（AQL）と称されるフレキシブル問合わせ言語に
よって与えられる。このAQLは、多数のマネージャが実
行する問合わせオブジェクトを形成するため、AQLシス
テム９４４によって処理される。

【０３２１】１．ＡＱＬ言語 AQLは述語問合わせ言語であり、主として述語だけに基
づく言語である。データタイプの宣言は無い。全ての述
語は、いくつかの引数（その項数arity）と、引数がも
つべきデータタイプとを有する。述語が問合わせに使用
されるとき、述語の引数のデータタイプが使用されるこ
とが暗黙的に想定され、変数のデータタイプを宣言する
必要がない。AQLには以下の特徴がある。

【０３２２】１．原始データタイプ及び原始述語が豊富
である。

【０３２３】２．元の述語又は原始述語から新しい述語
を構築でき、それを行うための構文が非常に簡単であ
る。

【０３２４】３．述語を用いて問合わせを構築する構文
が非常に簡単である。

【０３２５】４．商取引者と述語の間のインタフェース
が簡単であるため、商取引者は問い合わせ言語を学習す
る必要がない。

【０３２６】Aggregation Query Language(AQL)には、
２種類のステートメント（文）が存在する。 １．問合わせステートメント（ある情報を問い合わせる
ステートメント） ２．述語定義ステートメント（新しい述語を構築するス
テートメント） 問合わせステートメントの形式は以下の通りである。

【０３２７】

【外１】 この文は、文P(x, y,…, z)が真となるような全てのタ
プル（x, y, …, z）に関心があることを意味する。た
とえば、P(x)が、「ユーザｘは釣りにとても関心があ
る」を意味するならば、問合わせ：

【０３２８】

【外２】 は、「釣り」にとても関心のある全てのユーザを返答す
る。

【０３２９】より形式的に説明すると、問合わせステー
トメントの文は、常に、キーワード

【０３３０】

【外３】 で始まり、次に、識別子（コンマで区切られた多数の識
別子でも構わない）と述語が続く。

【０３３１】述語は、合成述語でも組込み述語でもよ
い。組込み述語は、集計サービスによって予め与えられ
た述語である。合成述語は、組込み述語を論理結合子
（論理積、論理和、否定など）と組み合わせることによ
って構築される述語である。勿論、他の合成述語を組み
合わせることによって別の合成述語を構築することがで
きる。すなわち、合成述語は商取引者によって構築され
る述語であり、組込み述語は既存の（予め集計サービス
によって設けられた）使用可能な述語である。以下の説
明で、述語という用語は、組込み述語と合成述語の両方
の意味で使用される。述語を記述する構文は以下の通り
である。

【０３３２】合成述語は、論理積、論理和、若しくは、
否定のいずれでもよい。

【０３３３】述語がコンマで区切られるとき、論理積を
表す。たとえば、次の文：[P,Q,R]は３個の述語P、Q及
びRの論理積を表す。

【０３３４】述語がコロンで区切られているとき、論理
和を表す。たとえば、次の文：[P:Q:R]は、３個の述語
P、Q及びRの論理和である。

【０３３５】述語が中括弧{}で囲まれているとき、否定
を表す。たとえば、次の文：{P}は、述語Pの否定を表
す。

【０３３６】新しい述語は、２個以上の述語を上記の論
理積、論理和又は否定用の論理結合子を用いて結合する
ことにより、既存の述語から構築することができる。新
しい述語を定義するため、以下の述語定義ステートメン
トを使用する。

【０３３７】

【外４】 一例として、述語P(x)が「カテゴリーｘには人口の半分
以上が関心をもっている」を表し、述語Q(y)が「ユーザ
ｙは医学に関心がある」を表し、第３の述語R(y, z)が
「ユーザｙはカテゴリーｚだけに強い関心がある」を表
す場合を考える。ここから新しい述語K(y, x)を以下の
通り構築することができる。

【０３３８】

【外５】 この新しい述語は、以下のような問合わせを作成するた
め使用することができる。

【０３３９】

【外６】 この問合わせは、ユーザｙが医学に関心があり、かつ、
カテゴリーｘだけに強い関心があり、このカテゴリーｘ
には人口の半分以上が関心をもっているような全てのユ
ーザｙとカテゴリーｘを返す。

【０３４０】AQLでは、限量子付きのステートメント
（すなわち、論理限量子を含むステートメント）を表現
することができる。述語P(x, y)が「ユーザｘはカテゴ
リーｙに程々の関心がある」を意味するとする。ここ
で、「ユーザｘが程々の関心をもつカテゴリーが存在す
る」というような文を表現したい場合を考える。述語計
算では、この表現は、存在限量子を用いて行われる。

【０３４１】∃y P(x, y) AQLの場合、 P(x, Y) のように表現することができる。大文字は、その変数が
限量子付き変数であることを意味する。次の問合わせ：

【０３４２】

【外７】 は、あるカテゴリーに程々の関心のある全てのユーザｚ
を返す。

【０３４３】AQLは、全称限量子を表現することもでき
る。１階論理の規則によると、全称限量子は，否定と存
在限量子の組み合わせによって表現できる。たとえば、
次の文：「全てのカテゴリーに対し、ユーザｚの関心は
７０％よりも高い」を表現したい場合を考える。

【０３４４】新しい述語P(z)は、ユーザｚが全てのカテ
ゴリーにカテゴリーとは無関係に常に７０％よりも高い
関心をもつことを表す。

【０３４５】「ユーザｘのカテゴリーｙに対する関心は
７０％よりも高い」という意味の述語Q(x, y)が既に存
在すると仮定すると、新しい述語Pは、既存の述語Qを用
いて、

【０３４６】

【外８】

【０３４７】

【外９】 のように表現される。

【０３４８】２．ＡＱＬインタープリタ AQLシステム９４４は、AQL言語を実行可能オブジェクト
（たとえば、Javaオブジェクト）に翻訳し、その結果を
返すために働くインタープリターを含む。インタープリ
ターのコンポーネントには、ステートメントアナライ
ザ、述語定義プロセッサ、レコーダー、ツリービルダ
ー、ファクトリー、述語ツリービルダー、述語ビルダー
及び評価器が含まれる。

【０３４９】あるAQL言語が与えられた場合に、ステー
トメントを取得する最初のコンポーネントは、ステート
メントアナライザコンポーネントである。このコンポー
ネントは、そのステートメントが問合わせステートメン
ト又は述語定義ステートメントのどちらの種類のステー
トメントであるかを判定するだけである。このステート
メントが問合わせステートメントであることが判明した
場合、ステートメントアナライザは、ステートメントの
述語部をツリービルダーコンポーネントに送る。ツリー
ビルダーコンポーネントは、ステートメントの述語部か
らツリーを構築する。たとえば、元のステートメント
が、

【０３５０】

【外１０】 という形式の問合わせステートメントである場合を考え
る。

【０３５１】上記ステートメントの述語部は、最初の括
弧"["で始まり、最後の括弧"]"で終わる文字列である。
ツリービルダーが上記問合わせステートメントから構築
するツリーは以下の通りである。

【０３５２】 ツリービルダーコンポーネントによってこのツリーが構
築された後、ファクトリーコンポーネントは、ツリーの
各リーフに対し（すなわち，R(x, y), P(x),Q(y)に対
し）述語オブジェクトを構築する。次に、述語ツリービ
ルダーは、ツリーの各リーフを，ファクトリーコンポー
ネントによって構築された対応した述語オブジェクトで
置換する。述語ビルダーコンポーネントは、ツリー全体
に対し述語オブジェクトを構築する。評価器コンポーネ
ントは、述語ビルダーコンポーネントによって構築され
た述語オブジェクトを取得し、その述語オブジェクトに
引数を与え、述語オブジェクトを評価し、問合わせステ
ートメントの結果を要求側のエンティティに与える。た
とえば、評価器は、問合わせのタイプと、問合わせを取
り扱うべきオブジェクトとに依存して、その結果をユー
ザグループマネージャオブジェクト、プロファイラオブ
ジェクト、毎日キューオブジェクト、AggQueryオブジェ
クトに返す。

【０３５３】上述の通り、ステートメントアナライザコ
ンポーネントは、最初に、ステートメントのタイプが何
であるか（問合わせステートメント、又は、述語ステー
トメント）を判定する。次に、ステートメントが問合わ
せステートメントではなく、述語ステートメントである
ことが判明した場合、ステートメントアナライザは、述
語定義プロセッサコンポーネントへのステートメントを
処理する。このコンポーネントは、ステートメントの述
語部を取得し、この述語部をツリービルダーコンポーネ
ントと、ファクトリーコンポーネントと、述語ビルダー
とに与える。次に、述語定義プロセッサは、述語ビルダ
ーコンポーネントによって作成された述語オブジェクト
を取得する。述語定義プロセッサコンポーネントは、述
語オブジェクトを、述語定義ステートメントの識別子部
と共に、レコーダーコンポーネントに与える。レコーダ
ーコンポーネントは、ペア（識別子、述語オブジェク
ト）をインタープリターのハッシュテーブルに収容し、
後続の問合わせの際に利用するため記憶される。

【０３５４】ＶＩ．カテゴリー及び分類 Ａ．分類の概要 ウェブビジターがウェブページを閲覧するような行動を
しているとき、ProReachシステムは、発生したこと、す
なわち、誰が，何時、何を行ったかを判定することによ
って行動を分析する。以下では、ProReachが分類化によ
って「誰が」と「何を」を識別する方法を説明する。他
の実施例では、分類化のための付加的な次元が適用さ
れ、行動が行われた場所が判定され、たとえば、どの企
業のウェブサイト若しくは部門で行動が行われたかが示
される。

【０３５５】文書及びその他のウェブコンテンツを分類
するため、ProReachのコンテンツ認識エンジン７１８
は、サンプル文書からカテゴリーパターンを構築し、文
書が最も良く一致するカテゴリーパターンに基づいて文
書を分類する。一実施例において、コンテンツ認識エン
ジン７１８は、Autonomy, Inc., San Mateo, Californi
aから入手可能なエンジンに基づいている。コンテンツ
認識エンジンは、キーワードを識別するため、文書に対
して言語解析を行う。

【０３５６】コンテンツ認識エンジンは、電子商取引に
関係したカテゴリーのライブラリーを含む。カテゴリー
は、ユーザがウェブ関連コンテンツを判断する方法によ
り良く接近するため、階層的に構成される。ProReach
は、半自動的に、並びに、人の管理の下で、カテゴリー
を追加、正確化、及び、編集するアーキテクチャーをコ
ンテンツ認識エンジンに与える。

【０３５７】ProReachは、システム管理者が自分の専門
領域若しくはトラヒックの重い領域に拡張することがで
きる標準的なカテゴリーツリーを有する。文書が分類さ
れ、その用途が記録されると共に、ProReachは、カテゴ
リー間の確率的関係を記述する二つのベイズのネットワ
ークを構築する。第一に、インヘリタンスツリーは、階
層的カテゴリー構造の改良と、分類化性能の効率化とに
役立つ。第二に、関係ネットワークは、カテゴリーがど
のように同時に生起したかを調べる自動的データ及び人
手で操作されたデータの両方によって構築される。これ
らの関係を理解することは、商取引者にとって重要な利
点がある。選択された付加情報を標準的なカテゴリーツ
リーに統合することによって，システム管理者が自分の
ウェブサイトで使用するコンテンツの徐々に正確な測定
がこのツリーで行われることが予想される。

【０３５８】上述の通り、全ウェブイベントレコード
は、ユーザコンプレックス、ユーザグループコンプレッ
クス及びカテゴリーコンプレックスのようなウェブイベ
ントのコンプレックスとして集計されるときに重み付け
られる。この重み付けは、ProReachシステム所有者に関
連した全ての計算を最適化する。コンテンツカテゴリー
及びユーザグループの結合毎に、集計コンプレックスは
この結合のためのウェブトラヒックをモデル化する。

【０３５９】一実施例において、各ProReachシステム１
００は、"systemEveryone"(システム全員)と称されるユ
ーザグループを有し、このユーザグループは、特定のコ
ンテンツカテゴリーと組み合わされて、特定のカテゴリ
ーに関する所定のProReachシステム１００への全ビジタ
ーの行動を記述する。これは、グループ・カテゴリーコ
ンプレックスとして実現され、グループは、"systemEve
ryone"である。同様に、コンテンツカテゴリー"everyth
ing"（全部）は、全てのカテゴリーを要約し、特定のユ
ーザグループの全コンテンツカテゴリーに関する関心を
記述するため、ユーザ・カテゴリーコンプレックス２０
３の各ユーザと共に使用される。かくして、分類化は更
なる分析のためデータをグループ化する方法として機能
する。より一般的に説明すると、集中ProReach管理は、
どこかでわかっている全カテゴリー及び全ユーザに対
し、グループ"everyone"及びコンテンツカテゴリー"eve
rything"を使用する。"global"カテゴリーを使用する集
計コンプレックスは、必要に応じてシステムによってダ
ウンロードしてもよい。

【０３６０】Ｂ．カテゴリー及び階層組織データ 好ましい実施例において、全てのコンテンツカテゴリー
は厳密な階層に収容される。各階層はルートを有し、全
ユーザは"everyone"ユーザグループに含まれ、全コンテ
ンツは"everything"カテゴリーに含まれる。カテゴリー
は子カテゴリーを包含する場合があり、子カテゴリーは
１個の親カテゴリーの子である。親カテゴリーのイベン
ト（又は、ユーザ）を１個の子カテゴリーに分類するこ
とにより付加的なデータが得られる。これらのデータ
は、有用性の点で重要な情報を提供すると評価できる。
これらのデータは、人にとって重要である。

【０３６１】子カテゴリーは、概念的、並びに、ウェブ
トラヒックパターンの点で、相互に異なり、かつ、親カ
テゴリーとも異なる。特に、子カテゴリーは、計算上、
容易に識別できなければならない。子カテゴリーは、カ
テゴリー内の文書をビジターが閲覧した量から得られた
重みに基づいて互いに識別される。独立して存在するに
は非常に「軽い」カテゴリー、すなわち、トラヒックが
不十分であるカテゴリーは、親カテゴリーに組み込ま
れ、その子カテゴリーの重み情報は親カテゴリーの重み
情報と集計される。カテゴリーの重みは、一方で、シス
テム管理者が個別のウェブページ及び他の文書に重みを
つけるため選択した方法に依存する。

【０３６２】ProReachによってカテゴリーに関して記憶
される細部のレベルは、グローバルオプションを設定す
ることによって調節される。これらのオプションが記憶
容量を低下させるように調節されたとき、データは、時
間的パターンに関して記憶される細部の量を減少させ、
かつ、小さいカテゴリーを親カテゴリーに組み込むこと
によって圧縮される。

【０３６３】１．カテゴリー階層の構築及び維持 データパターンが変化すると共に、既存のカテゴリーは
調整され、新しいカテゴリーが作成されなければならな
い。カテゴリーの有用性は、好ましくは、他のカテゴリ
ーとの識別性によって測定される。本発明は、カテゴリ
ーに対するイベントレコードを文書化することによっ
て、カテゴリー発見及びカテゴリー保守を行う。細分さ
れていないカテゴリーが重くなりすぎたとき、以下の４
ステップが行われる。 ・成長中のカテゴリーからのサンプル文書が統計的サン
プルによって収集される。 ・キーフレーズがサンプル文書から明らかにされる。 ・アルゴリズムが１個以上の新しいサブカテゴリーを割
り出すため、（キーフレーズのような）特徴を探索す
る。 ・集中ProReach管理者は、新しいサブカテゴリーの取り
込みを承認若しくは否認するよう促される。

【０３６４】２番目及び３番目のステップは、文書の適
切なグルーピングを判定し、実現性のある名称を提案す
るコンテンツ認識エンジン７１８によって自動的に行わ
れる。管理者は、提案を受け入れるてもよいが、自動提
案の改良に基づいてカテゴリーを調節してもよい。たと
えば、管理者は、カテゴリーの別の代表的な文書を選択
し、新しいカテゴリーの記述的な名称を選択してもよ
い。新しいカテゴリーは、標準ProReach配布物の一部に
なり、ProReachシステムによるダウンロードに利用する
ことができる。ProReachシステムは、次に、新しいカテ
ゴリーがこの分野で十分なトラヒックをもつ場合には、
新しいカテゴリーをカバーするイベントレコードを構築
する。

【０３６５】ProReachシステムによって使用されるカテ
ゴリーは、厳密な階層と擬似階層の組み合わせから形成
される。厳密な階層は、単一のインヘリタンスをもつ有
向ツリー状の構造として定義される。各ノード（但し、
ルートを除く）は、必ず１個の親ノードをもつので、親
ノードの子はいずれも１００％の確率でその親ノードの
子ノードである。ツリー構造は、子ノードが自分自身の
先祖になり得ないこと、及び、子ノードから先祖へのパ
スは１本しかないことを意味する。この構造は、簡明で
あり、かつ、カテゴリーの階層として使用するのに都合
が良い。しかし、厳密な階層は、文書若しくはユーザが
関連したカテゴリー間の実際の非常に複雑なコンプレッ
クスを取得できない場合がある。また、厳密な階層は不
確実性、すなわち、特定の文書若しくはユーザが属する
カテゴリー若しくはグループの不確定性を考慮できな
い。

【０３６６】擬似階層はこれらの欠点を解決する。擬似
階層は親子関係を維持するが、文書若しくはユーザが多
数のカテゴリーに部分的に属することを許容する。たと
えば、"dogs"に関する文書は、"pet"カテゴリーに６０
％所属し、"mammal"カテゴリーに３０％所属する。本発
明の一実施例において、これらの擬似階層は、文書をコ
ンテンツカテゴリー、又は、ユーザグループ内のユーザ
に分類する確率をモデル化するため、ベイズのネットワ
ークとして取り扱われる。本例の場合、１カテゴリー毎
に１ノードが存在する。"sports"カテゴリーと、その子
カテゴリー"football"の間の関係は、(30%,85%)であ
る。この関係は、所与の文書が"sports"として分類され
ていることがわかっている場合に、その文書が"fottbal
l"として分類される可能性が３０％であり、逆に、文書
が"football"として分類されている場合に、その文書
が"sports"としても分類される可能性は８５％であるこ
とを意味する。特に、スポーツは別の親カテゴリーを有
する。

【０３６７】ProReachは、実際のコンテンツ分類エンジ
ンの性能が擬似階層型である場合でも、最初にコンテン
ツカテゴリーを厳密な階層でモデル化することによっ
て、階層構造と擬似階層構造の二つのアプローチを合成
する。この原則によれば、子カテゴリー内で発生したウ
ェブトラヒックは、親カテゴリー内でも発生していると
みなされる。

【０３６８】このような外面的な視点の他に、ProReach
は、親カテゴリーと子カテゴリーが相互に関係している
程度についての統計量、たとえば、一方のカテゴリーが
他方のカテゴリーに分類される確率などの統計量を収集
する。

【０３６９】Ｃ．カテゴリー名及びＩＤ ProReachシステム１００で使用されるカテゴリーは、独
立した無関係の企業及び機関によって作成される。独立
したエンティティ（たとえば、企業、機関など）によっ
て命名されたカテゴリーは同じ名称をもたないことが必
要である。より具体的には、ProReachシステム１００
は、内部の二つのカテゴリーに同じ名称を付けてはなら
ない。このような名称の衝突は、著しい困難を引き起こ
し、処理エラーを招く。

【０３７０】主として人の認識に適するように英数字名
が用いられ、実際のカテゴリー識別は（ユーザと文書の
両方に対して）カテゴリーIDに基づいて行われるので、
二つの識別子は異なるアプローチを使用する。たとえ
ば、偶然的に重複する可能性の低い情報を識別子中にエ
ンコーディングすることによって、カテゴリー識別子の
固有性が容易に実現される。他方で、テキスト形式の名
称は、その意味を伝達するため、できる限り簡易である
ことが必要である。場所に特有のカテゴリー名を付ける
ことは意味がある。

【０３７１】IDに対するあいまいさの無いネーミングを
強制し、テキスト形式の名称にもこのネーミングを促進
するため、各ProReachシステム１００は、システム実装
時に決定された固有識別子及び固有テキスト文字列を保
持する。カテゴリーの発生場所が不確かである場合、こ
のカテゴリーは、ローカルカテゴリーID又はローカルカ
テゴリー名に依存させられるべきである。かくして、"S
portsWorld"に固有識別子"4Q5f4"をもつProReachシステ
ムが"Football"と呼ばれるカテゴリー"Xj542"を定義す
る場合、このカテゴリーは、 ID: 4Q5f4.Xj542 name: SportsWorld.Football として取り扱われる。

【０３７２】前後の内容から明らかである場合、接頭
辞"SportsWorld"はデフォルトであるとみなされ、ユー
ザが見るときには隠されるか、若しくは、カラーでエン
コードされる。ProReachが既に"H730"のようなカテゴリ
ー"FootBall"を定義しているような場合、カテゴリー"S
portsWorld"のProReach管理者は、標準カテゴリーと同
じ名称のローカルカテゴリーを作成しようとしたときに
警告メッセージを受け取る。集中システムの集中ProRea
chシステムが固有の識別子、たとえば、ID B345を保有
する場合、集中システムの対応したカテゴリーは、 ID: B345.H730 name:Central.Football のように表される。注：本例において、システムの識別
子（たとえば、B345又はSportsWorld）は接頭辞と呼ば
れる。

【０３７３】更新プロセス中、ProReachシステム１００
は情報を集中システムとの間で交換する。手段に依存し
て、ProReachシステムは、多少のイベントレコード情報
を集中システムに供給し、次に、集中システムは、全Pr
oReachシステム１００及び集中システムの管理者から組
み合わされた更新情報を与える。新しいカテゴリーは、
階層の適当な場所に追加され、ProReachシステム１００
のカテゴリー改良が集中システムのカテゴリー改良に実
質的に重なる場合に、新しいカテゴリーがリストに掲載
される。ProReachシステム１００は、専用化されたカテ
ゴリーを、集中システムが標準カテゴリーツリー（次節
を参照のこと）に追加したカテゴリーに組み入れる機会
が与えられる。

【０３７４】１．デフォルト変更不可ユーザ・カテゴリ
ー構造 異なるProReachシステム１００の間の通信を容易に行う
ため、ユーザグループの初期の粗い集合が与えられる。
全ProReachシステム１００は、これらのユーザグループ
を、階層の最上部付近で共有し、付加的な新しいグルー
プ及びサブグループの組込みが行えるようにする。後述
のコンテンツカテゴリーと共に、このユーザ・カテゴリ
ー構造は、図１８に示されるように標準構造である。

【０３７５】第一に、ユーザグループ"global.everyon
e"は、集中システムで収集されたデータによって構築さ
れた唯一のカテゴリーであることに注意する必要があ
る。他の全てのカテゴリーは、各システム１００に専用
であり、同図では、"system1.everyone"などのように表
された第２レベルのユーザグループに対応する。かくし
て、たとえば、SportWorldの組では、"system1"の代わ
りに"SportWorld"が用いられる。これらの名称は記述的
な名称であり、実際のカテゴリー識別子はシステムによ
って割り当てられた番号であることに注意する必要があ
る。

【０３７６】集中システムが情報を追跡するのは、カテ
ゴリー"everyone"と"gloval.everyone"だけである。各P
roReachシステム１００には、system.everyoneをルート
とする別の副階層が存在する。集計に関して後述するよ
うに、システムの更新中に、システム１００は、システ
ム１００のsystem.everyoneに関する情報を集中システ
ムに送る。集中システムは、集中システムのsystem.eve
ryoneに関する情報を返信することによって応答する。
このように、多数の異なるProReachシステム１００から
のカテゴリーは更新され続ける。

【０３７７】カテゴリー"anonymous"、"cookie"及び"re
gistered"は、それぞれ、識別されない匿名の顧客のカ
テゴリー、ProReachが保存することを許可した人に知ら
れた顧客のカテゴリー、及び、完全な登録を終えた顧客
のカテゴリーであり、一般的に、このような人口統計が
名称及びアドレスとして含まれる。

【０３７８】２．カテゴリーとグループの類似性及び相
違性 管理者は、ユーザやコンテンツのいずれかの種類のサブ
カテゴリーを追加しようとするとき、縦型の特殊化を行
う。サブカテゴリーは、常に、既存カテゴリーの一つに
付加される。システム管理者は、自分の専用システムの
命名法、すなわち、固有の名前空間に基づくカテゴリー
を追加する。二つのタイプのカテゴリーの間には重大な
相違点がある。これらの相違点は、コンテンツカテゴリ
ーについて後で説明することによってより明瞭になる。

【０３７９】

【表６】 Ｄ．分類におけるソース及びロケーションの使用 ソースは、ユーザグループによって取得される次元に類
似した別の次元である。たとえば、集団SportWorldは、
クライアントが競合するウェブサイトSportsOnline.com
を訪れる頻度に非常に関心がある。SportWorldとSports
Online.comが共にProReachシステム１００であるとき、
競合相手が自分のサイトの顧客行動をスパイするためPr
oReachを使用できるならば、両者は互いに非常に不満を
示し、また、集中システムの管理者にも不満を示すであ
ろう。これに対し、顧客行動（たとえば、football上の
行動）が自分のウェブサイトにおける行動であるか、あ
るいは、他のウェブサイト上での行動であるかは、Spor
tWorldにとって重大な関心事である。

【０３８０】これらの関心事のバランスをとるため、Pr
oReachシステムは、ユーザグループ及びコンテンツカテ
ゴリーを取り扱う方法と同様の方法でイベントのソース
を記憶するが、ProReachシステムの所与の集団の内部と
外部だけを区別する。すなわち、任意のユーザ及びカテ
ゴリーに対し、（SportWorldのような）システムは、二
つの拡張型イベントレコードを有する。一方は、集団内
の行動用のイベントレコードであり、他方は、その他の
全ての行動用のイベントレコードである。拡張型イベン
トレコードは、最初、次の章で説明されるイベントレコ
ードと殆ど同様に振る舞うが、拡張型イベントレコード
を索引付けするため使用されるソースの付加パラメータ
が設けられている点が異なる。集中システムは、二つ以
上のソースを記憶し、異なるシステム間の区別、並び
に、システムの内側ソースと外側ソースの区別を行う。

【０３８１】Ｅ．コンテンツカテゴリーライフサイク
ル：形成、調整及び変更 １．標準カテゴリーツリーと、ＰｒｏＲｅａｃｈシステ
ム管理者による追加図１９を参照するに、集中システム
１０３は、各ProReachシステム１００の一体的な部分と
して、標準コンテンツカテゴリーツリー１４００を提供
する。このツリーのルートは、カテゴリー"STANDARD.ev
erything"であり、このカテゴリーは、各ProReachシス
テム１００の個別に付加されたコンテンツカテゴリーの
先祖でもある。標準カテゴリーツリー内の全カテゴリー
は、特に、好ましくは、これらのカテゴリーだけが、接
頭辞"STANDARD"を含む。

【０３８２】個々のProReachシステム１００は、標準カ
テゴリーツリー内のカテゴリーを変更することが認めら
れない。より一般的には、ProReachシステム１００は、
専用システムの下のカテゴリー１３０２、すなわち、そ
のシステムに割り当てられた接頭辞を含むカテゴリーだ
けを変更することができる。ProReachシステムが"Stand
ard"カテゴリーを削除しようとした場合、仮想的な削除
に過ぎない。換言すると、削除されたカテゴリーはその
ProReachシステムからは見えなくなり、目に見える分類
は、不可視にされたカテゴリーには伝えられない。

【０３８３】ａ）ＰｒｏＲｅａｃｈシステムでのカテゴ
リーの追加 ProReachシステム１００の管理者は、サンプル文書を作
成し、ProReachに対し新しいカテゴリーを作成するた
め、そのサンプル文書を使用するよう命令することによ
って、既存のカテゴリーの新しいサブカテゴリーをロー
カルカテゴリーツリーに手動で追加する。これらのカテ
ゴリーは、好ましくは、ある文書が非常に頻繁に使用さ
れていることを示す行動１４０４、すなわち、コンテン
ツを文書が分類されているカテゴリー内で更なるサブカ
テゴリーに分類する必要があることを示す行動に応じて
追加される。ProReachは、最初、新しいカテゴリーの親
を決めるため、旧いツリーの下で文書を分類する。親カ
テゴリーが予定していたものでは無い場合、旧い親カテ
ゴリーが十分に機能していないか、あるいは、サンプル
文書が管理者の意図した状況に適合していないというこ
とがわかる。特に、サンプル文書が単一のカテゴリーに
含まれないことがあり、この場合には、おそらく、文書
の部分集合、若しくは、全く別の文書が新しいカテゴリ
ーを訓練するため使用されるべきである。

【０３８４】ProReachは、組み入れられるカテゴリーに
関するカテゴリー編集行動を監視する。これらのデータ
は局所的に記憶され、更新時に送信されるので、いくつ
かのシステムの管理者が同様の追加を行おうとする場
合、再検査するカテゴリーが指定される。

【０３８５】カテゴリーを順番に追加することにより、
特定のProReachシステム１００は、専門分野に関する専
用階層１４０２を蓄積する。新しいカテゴリーは、既存
のカテゴリーのサブカテゴリーとして追加されるので、
新しいカテゴリーは、標準カテゴリーツリーに先祖をも
つ。したがって、標準カテゴリーツリーが特定の分野に
拡張されなくても、これらのカテゴリーのイベントカテ
ゴリーは、他の全てのProReachシステム１００に有用な
先祖カテゴリーの全体に寄与する。

【０３８６】カテゴリーツリーの特殊化された拡張は、
専門技術を獲得し、集団に特有の経験を高めるので、特
に、集中システム１０３にとって興味深い。標準カテゴ
リーツリーが最も重いトラヒックをもつ新しい第三者サ
ブカテゴリーを取り入れるように拡張されると共に、標
準カテゴリーツリーはコンテンツを徐々に正確に反映す
ることができる。

【０３８７】各ProReachシステム１００は、固有のビジ
ネスに関連した細部のレベルだけを保持するので、標準
カテゴリーツリーが大きくなりすぎると企業は標準カテ
ゴリーツリーを使用できなくなる。非常に軽いカテゴリ
ーツリーは、親カテゴリーに組み入れられる。

【０３８８】ｂ）標準カテゴリーツリーの更新 集中システム１０３は、到来するデータと実際上の経験
とに基づいて標準カテゴリーツリーを改良する。これら
の改良によって、標準カテゴリーツリーは継続的に更新
される。変更毎にタイムスタンプが押されるので、ProR
each使用可能サイトは、未だ組み入れていない更新内容
だけをダウンロードする。

【０３８９】更新情報の一部として、ProReachシステム
１００は、専用システム上のトラヒックに関するサマリ
ー情報を提供する。このような形でビジネスから収集さ
れる情報の量は変化する。しかし、データは、好ましく
は、控えめにされ、個別の顧客や、企業の精確な財政状
況に関する情報を開示しないように設計される。その代
わりとして、サマリーイベントレコード及びカテゴリー
性能統計量だけが共有される。これにより、集中システ
ム１０３と他のProReachシステム１００の間の共生的関
係が得られ、各ProReachシステムは固有のデータの非常
に精確なモデルを構築できるようになる。

【０３９０】ｃ）標準カテゴリーツリーの構築 ProReach標準カテゴリーツリー１４００は、好ましく
は、約８００種類のカテゴリーを含む。これらのカテゴ
リーには、化粧品、スポーツ、ボードゲーム、切手、
車、トラック、本、健康、不動産、旅行などが含まれ
る。標準カテゴリー１４００は階層構造である。カテゴ
リーは、カテゴリーのデータベーステーブルに組み込ま
れ、データベーステーブルのエントリーは親カテゴリー
を識別するフィールドをもつ。

【０３９１】ProReachは、AltaVistaのような主要なウ
ェブポータルサイトのツリーに基づいて初期標準カテゴ
リーツリー１４００を構築する。これらのサイトは、既
に、連続的なトラヒックによって確認されたカテゴリー
を構築している。ProReachは、これらのサイトからペー
ジを収集し、カテゴリーからのリンクしたページによっ
て訓練される分類化エンジンを構築するスパイダリング
システムを使用する。主要なポータルサイトからは、数
万件のカテゴリーを入手することができる。スパイダリ
ングは、トップダウン式に始まり、時間の経過と共にカ
テゴリーの知識を増加する。

【０３９２】カテゴリーは、コンテンツが変化するので
周期的に改定される。多数のカテゴリーは、毎日のニュ
ースのように現在関心のあるトピックスに限定されるこ
とに注意する必要がある。非常に動的なカテゴリーは、
動向に遅れないように非常に頻繁に再計算される。

【０３９３】ｄ）カテゴリーの発見、改良及び編集 ProReachシステム１００で追加されたカテゴリーは、常
に標準カテゴリーへの子孫として追加されるので、標準
カテゴリーを妨害しない。しかし、ProReachシステム管
理者は、固有の子カテゴリーを追加することによって標
準カテゴリーを自由に改良することができる。時間の経
過と共に、集中システム１０３及びProReachシステム１
００の所有者は、カテゴリーをツリー１４００に追加す
ることを選ぶ。カテゴリーは、常に、既存カテゴリーの
子として追加され、親カテゴリーの専門化された部分集
合を定義する。カテゴリーは手動で追加されるだけでは
なく、トラヒックの重いカテゴリーは、より小型の、よ
り専門的な部分に分割される。そのため、カテゴリー
は、抜粋された文書の統計的サンプルを記憶し、管理者
によって別々のサブカテゴリーに分類される。

【０３９４】カテゴリーの性能は常に測定可能であり、
適宜、特殊化を駆動（若しくは阻止）するための基本手
段として使用される。カテゴリーが十分に機能しないと
き、その情報が警告信号として記憶され、警告信号によ
って、カテゴリーの監視と、場合によってはカテゴリー
の再訓練が始動される。改良は、標準カテゴリーツリー
内でトラヒックによって厳密に制御される。高レベルの
トラヒック１４０４が与えられたとき、文書の統計的サ
ンプルが収集され、特殊化サブカテゴリーの候補が生成
される。テスト後、サブカテゴリーは標準カテゴリーツ
リー１４００に追加される。

【０３９５】カテゴリーは徐々にトラヒックを失う場合
がある。トラヒックの損失がProReachシステム１００で
発生する場合、ProReachシステムは、カテゴリーを使用
できない状態におき、関連したトラヒックを親カテゴリ
ーに切り換える。集中システムで検出されたグローバル
カテゴリー性能がカテゴリーを維持する価値が無い程度
に低い場合、カテゴリーの履歴が後で復元できるように
保管され、カテゴリーは、標準カテゴリーツリー１４０
０の親カテゴリーに組み入れられる。

【０３９６】カテゴリーが変更されたとき、元の目標文
書を完璧に分類できない場合がある。その結果として、
新しいカテゴリーIDが生成され（できれば、同じ名前を
用いて）、旧いパターンに対するイベントレコードは、
新しいカテゴリーのイベントレコードに変換される。こ
れを巧く行うために、旧いカテゴリーは、そのイベント
レコードを切り換えるため新しいカテゴリーに割り当て
られる。このとき同時に、旧いコンテンツの中のどれく
らいの部分が新しいカテゴリーに分類されるかを示す数
が割り当てられる。デフォルトとして、１からその部分
を除いた残りの部分が旧いカテゴリーの親に分類され
る。親カテゴリーが変更されたとき、子カテゴリーは新
しいカテゴリーを親とするように切り換えられる。

【０３９７】Ｆ．コンテンツ認識エンジンの分類モデル コンテンツ認識エンジン７１８は、訓練用文書に基づい
てカテゴリーを訓練することができるので、他の文書は
カテゴリーに対しスコアが与えられる。すなわち、文書
と訓練されたカテゴリーとに対し、コンテンツ認識エン
ジン７１８は、 score(document, category) を出力する。このスコアは、0から1,000,1000、あるい
は、その他の適当な最大値まで変化し、スコアが高くな
ると共に、文書がカテゴリーにより良く適合することが
示される。ここで、1,000,000は、浮動小数点値の代わ
りに整数で高精度の結果を記憶するため、1.0の代わり
に最大値として使用される。

【０３９８】図２０には、コンテンツ認識エンジンの動
作の上位レベルの概要図である。適当なコンテンツ認識
エンジンは、Autonomy, Inc., San Mateo, California
から入手できる。所定の文書１５０１はコンテンツ認識
エンジン７１８に供給され、コンテンツ認識エンジン
は、その文書を記憶されたパターンと照合する。パター
ンは、カテゴリーツリー１４００、１４０２のコンテン
ツカテゴリー毎に一つずつ設けられる。カテゴリー毎
に、コンテンツ認識エンジン７１８はカテゴリースコア
を出力する。

【０３９９】多数のウェブページには、ProReachシステ
ムユーザが頻繁に訪れる。ユーザによって閲覧される都
度に各文書を分類するのでは不十分である。したがっ
て、一つの最適な戦略は、カテゴリー重みを再計算する
のではなく、できるだけ記憶することである。カテゴリ
ー重みの記憶は、二つの手段を用いて実現される。ロー
カルProReachシステム１００上のページに対し、カテゴ
リー識別情報がメタデータとしてページの内部に格納さ
れる。あるいは、頻繁にビジットされるページの分類情
報がページメタデータキャッシュ７１６に蓄えられる。
ProReachがURLへのビジットの記録を調べるとき、最初
に、キャッシュ７１６を検査し、次に、メタデータを探
索する。キャッシュとメタデータのいずれからも分類情
報が得られない場合に限り、他の手続きが行われる。

【０４００】１．カテゴリー作成 カテゴリー作成の第１ステップは、代表的な文書の集合
を割り出すことである。カテゴリーの文書は、システム
管理者、又は、このカテゴリーの主題の専門家によって
選択され、コンテンツ認識エンジン７１８を用いて分類
され、実世界の文書に基づいて管理者若しくは他のコン
テンツ専門家によって品質がテストされ、分類化の結果
が確認される。生成された分類が専門家の観点で優れて
いる場合、良好である代表的な文書の集合が使用され
る。分類結果がよくない場合、代表的な文書の集合は変
更されるべきであり、テストプロセスが繰り返される。
テストによって良好な頻度で良好な結果が得られると
き、分類は完了する。

【０４０１】カテゴリーを訓練するため使用されたこの
文書の集合は、カテゴリーのプロトタイプである。統計
的な手法を用いることにより、コンテンツ認識エンジン
７１８は、代表的な文書の集合を分析し、カテゴリーパ
ターンを生成する。このパターンは、重み付きキーフレ
ーズにより構成され、カテゴリー定義用データベーステ
ーブルに格納される。各キーフレーズは、サンプル文書
から抽出され標準的な語形式に制御された語のグループ
である。たとえば、フットボールに関する文書は、"foo
tball players"と"football player"の両方の用語を含
む可能性がある。この例の場合、両方の用語は等価的で
あるとみなされ、単数形の方がカテゴリーパターンにキ
ーフレーズとして記憶される。

【０４０２】２．文書分類 このようなパターンが存在する場合、コンテンツ認識エ
ンジン７１８は、文書をそのパターンと比較し、その文
書がパターンに適合する度合いを計算することができ
る。文書が分類されたとき、文書は、最初に文書のテキ
ストをフレーズに分割することによって処理される。言
語解析及び情報理論処理によって、文書中で重要である
可能性が最も高いフレーズが割り出される。たとえ
ば、"I"若しくは"or"のような単語は、頻繁に出現する
ため、文書の意味を区別するために有効ではないので、
考慮の対象から除かれる。残りのフレーズの一部は、キ
ーフレーズとして識別され、文書の意味を定義している
と考えられる程度に応じて重み付けされる。

【０４０３】文書から抽出されたキーフレーズは、次
に、カテゴリー定義用データベーステーブルでルックア
ップされ、記憶されたカテゴリーパターンと照合され
る。文書のキーフレーズを含むパターンだけが文書のカ
テゴリーの候補として考慮される。４個のカテゴリーパ
ターンがいずれかのキーフレーズに一致した場合を考え
る。この場合、各カテゴリーの文書のスコアが図２０に
示されるように計算される。

【０４０４】ある文書は、たとえば、パターンと９０％
一致し、あるいは、５０％しか一致しない場合もある。
この一致の程度はスコアと称され、0から1,000,000の範
囲に較正される。最高可能スコアの1,000,000は、文書
がパターン用に記憶されたキーフレーズの所定の個数、
又は、所定のパーセンテージと完全に一致した場合に与
えられる。スコア0は、全く一致しなかった場合に与え
られ、上記のステップの前に除去されたパターンに対し
生じる。一般的に、スコアは、パターンのキーフレーズ
と文書のキーフレーズの一致度の合計によって計算され
る。上述の通り、カテゴリースコアの組は、一致が肯定
されるカテゴリーのパターン毎に得られるパターンマッ
チング結果のカテゴリーベクトル９０８である。パター
ンマッチが無いカテゴリーの場合、そのカテゴリーに対
するカテゴリーベクトルとして0が記憶される。

【０４０５】好ましい一実施例において、特定のカテゴ
リーに与えられたスコアは、カテゴリーのサブカテゴリ
ーに与えられたカテゴリースコアの関数として表され
る。これにより、親カテゴリーに対する合成スコア(com
posite score)が得られる。たとえば、"ECOMMERCE"が"B
USINESS"のサブカテゴリーであり、文書のスコアが"ECO
MMERCE"に対しては高く、"BUSINESS"に対しては低い場
合、コンテンツ認識エンジン７１８は"BUSINESS"カテゴ
リーに対するスコアを増加させる。このアプローチは、
カテゴリーの階層関係を保存し、文書のスコアがサブカ
テゴリーで高く、親カテゴリーで低いという直観に反し
た事例を解決する。

【０４０６】このアプローチは、以下の通り実現され
る。親カテゴリーがサブカテゴリーを有する場合、親カ
テゴリーのスコアは、そのスコア自体、又は、親カテゴ
リーのスコアとサブカテゴリーの中の最高スコアの平均
スコアの高い方が選ばれる。カテゴリーB、C、Dがカテ
ゴリーAのサブカテゴリーであり、文書の未加工のカテ
ゴリースコアが、A=300000、B=700000、C=10000、D=200
000である場合を想定する。この例では、Aに対する合成
スコアは、300000と700000（サブカテゴリーBに対する
最大サブカテゴリースコア）の平均である。当業者は、
このアプローチを変形することによって親カテゴリーの
スコアを増大させる種々の方法が得られることを認める
であろう。かくして、一般的に、合成スコアは、親カテ
ゴリーに対する合成スコアを与える関数ｆ（親カテゴリ
ースコア、サブカテゴリーのスコア）で表される。

【０４０７】３．多重辞書分類 ProReachシステムは、カテゴリーを多数のカテゴリーテ
ーブルに分割することによって、特定の環境に調整する
ことができる。一実施例において、これは、異なるカテ
ゴリーの組をカバーするカテゴリー辞書を多種類使用す
ることによって行われる。辞書は、データベース７２０
内に別々のカテゴリーテーブルとして実現してもよい。
一つのカテゴリーは、一つ以上の辞書に存在する。

【０４０８】ProReachは、最初に、第１の辞書を用いて
文書を分類する。殆どの場合、これによって、文書の最
終的なカテゴリーが決まる。例示のため、選択されたカ
テゴリーが標準ツリー１４００の分枝全体を通じて共通
しない親カテゴリー、たとえば、第２の別の辞書に格納
されたカテゴリーである場合を考える。この例の場合、
更なる分類が行われ、再び、更なる分類では未だ十分で
はないという極めて異常な状況が発生し、精密な起こり
得る細部を獲得するために第３の辞書が必要とされる。
本例の場合、第３の辞書のルートカテゴリーがその子孫
よりも文書に最も良く適合することがわかる。したがっ
て、第３の辞書を使用する３番目のステップだけが先に
行われた分類を承認する。時間的制約に依存して、２番
目及び３番目のステップを省いてもよい。その場合、１
番目のステップが有用な部分的情報を提供する。多数の
分類が３ステップ先まで降下した場合、周期的な最適化
によって、辞書の間で、この降下の尤度を小さくさせる
ように再配分が行われる傾向がある。

【０４０９】各辞書の動作は、データベーステーブル問
合わせと、その後に続く僅かな処理である。この動作
は、第１の辞書の内部で行われた分類の約３倍の時間を
必要とする。このように構造が複雑化した理由は、大規
模データベース探索に関連した性能限界と、カテゴリー
の集まりが過剰に膨大化することとを避けるためであ
る。特に、この動作は、多数のカテゴリーの高精度化と
予測処理時間の短縮を組み合わせるため、複雑化する。

【０４１０】トラヒックの少ないProReachシステム１０
０の場合、データが制約されているため最も精細なレベ
ルの細部を記憶するには及ばないので、辞書は一つで十
分であると考えられる。しかし、大規模システムでは、
性能の低いカテゴリーが存在する場合に、それらのカテ
ゴリーは、主として２次的なより具体的な辞書に委ねら
れる。これらの２次的な辞書は、あまり頻繁に使用され
ない領域の細部も記憶する。

【０４１１】この最適化は、第１の辞書内に完全に分類
されたイベントレコード重みを最大化しようとする。こ
れは、システム１００毎に、現在のイベントレコード履
歴に基づいて自動的に最適化される。このため、最も重
いカテゴリーが第１の辞書に格納される。本例の場合、
一つの２次的な辞書が、第１のパスによって返されたカ
テゴリーのサブカテゴリーを格納し、これらのサブカテ
ゴリーは更なる細部を判定するため使用される。

【０４１２】一実施例において、このアプローチは、以
下の通り実現される。

【０４１３】カテゴリー間に親子関係のあるカテゴリー
のツリーを、たとえば、標準カテゴリーツリー１４００
に与える。カテゴリーツリーを形成するように、各カテ
ゴリーの親の数は０若しくは１である。親のないカテゴ
リーはルートとして知られている。0から1,000,000まで
を含む整数で表される閾値Tを考える（この範囲はスコ
アのレンジと同一である）。

【０４１４】次に、カテゴリーのキューQを定義する。
カテゴリーツリーのルートを順序付きキューQに追加す
る。

【０４１５】分類されるべき文書を選択する。Rは、カ
テゴリーベクトル９０８のようなカテゴリー／スコアの
ペアのベクトルを表す。すなわち、ベクトルの各要素は
カテゴリー及びスコアを含むレコードである。

【０４１６】キューQが空ではない間、以下の１．〜
５．を実行する。 １．キューからカテゴリーCを取り出す。 ２．カテゴリーCのサブカテゴリーの集合Sを獲得する。 ３．文書Dを集合S内のカテゴリーの集合を用いて分類す
ることにより得られるカテゴリ／スコアペアPのベクト
ルをVで表す。 ４．ベクトルVの要素をベクトルRに加える。 ５．Vのカテゴリー／スコアペアP毎に、 P.score>=T の場合に限り、P.categoryをQに加える。

【０４１７】このアプローチは、親カテゴリーに対する
文書のスコアがどの程度優れているかによって制御され
るカテゴリーのツリーの中の子孫を与える。親カテゴリ
ーに対するスコアが非常に低い場合（すなわち、閾値よ
りも低い場合）、親カテゴリーのサブカテゴリーの分類
化は行われない。

【０４１８】４．カテゴリーキャッシュ ProReachは、好ましくは、ProReachシステム１００に常
駐する文書をその分類情報と関連付けるキャッシュサブ
システムを使用する。これにより、文書が変更されない
限り、文書の再分類は回避される。

【０４１９】より詳細には、ProReachは２種類のキャッ
シュを保持する。一方のキャッシュは、常時存在するペ
ージメタデータキャッシュ７１６であり、データベース
７２０に記憶される。もう一方のキャッシュは、メイン
メモリに常駐する。必要に応じて、データベースキャッ
シュからのデータは、メインメモリキャッシュに渡され
る。リソース制限（たとえば、メインメモリ、CPU利
用）のため、項目はメインメモリキャッシュから取り出
され得る。データベースキャッシュは、文書、タイムス
タンプ、及び、それらの分類情報の関係として保存され
る。ページメタデータキャッシュ７１６は以下のように
使用される。

【０４２０】文書が指定されたとき、メモリキャッシュ
内でその文書が探索される。文書がメモリキャッシュに
存在しない場合、文書がメタデータキャッシュ７１６に
存在するかどうかが検査される。文書がメタデータキャ
ッシュに存在する場合、情報を表現する項目がデータベ
ースからメモリキャッシュに入れられる。キャッシュさ
れた項目がメタデータキャッシュにも無い場合、この文
書は分類されていない。したがって、この文書は分類さ
れ、最終的に分類情報がデータベースに送り込まれる。
メモリキャッシュからデータベースへのフラッシュ更新
はバックグラウンドプロセスとして行われる。

【０４２１】文書に関してキャッシュされた項目が検出
されたとき、文書上のタイムスタンプがキャッシュされ
たデータ上のタイムスタンプよりも新しい場合、このキ
ャッシュされたデータは無視される。タイムスタンプに
基づいて文書が更新されたと考えられる場合、文書は再
分類される。

【０４２２】ある種の最適化が時間経過と共にこのキャ
ッシュに対し行われる。特に、非常に動的なデータは、
不必要に関連した再分類化の試みのために、キャッシュ
を激しく動かす可能性がある。このような無駄な作業
は、キャッシュ項目毎にカウンタを保持し、キャッシュ
項目が変更される都度カウンタを更新することによって
回避される。所定の時間的区間内に所定回数を超える変
更がなされたとき、文書は内容に関して動的であると推
定することがおそらく合理的であり、キャッシュすべき
ではないと考えられる。

【０４２３】このため、キャッシュされた項目は、"UNC
HACHEABLE"フィールドを持つことが可能である。キャッ
シュされた項目のこのフィールドがセットされると、キ
ャッシュマネージャは、データベース上のこの項目の見
つけ出しを直ちに停止し、この項目をメモリキャッシュ
に保持しようとしない。

【０４２４】近年、ウェブサイトがウェブページコンテ
ンツをユーザ向けにカスタマイズしようとするとき、ユ
ーザは、特定のパラメータを、URLで渡されたパラメー
タ（したがって、CGIスクリプトに渡されるパラメー
タ）ではなく、クッキーに格納する傾向が見られる。し
たがって、ProReachは、URLをUNCACHEABLE（キャッシュ
不可）としてラベル付ける動作を識別しようとする。

【０４２５】キャッシュサブシステムのクライアント
は、キャッシュを集中的に占有しようとするかもしれな
い。典型的に、これは、文書の一部の集合を自動検出
（スパイダリング）し、それらの文書に対応したユニフ
ォーム・リソース・ロケータをコンテンツ認識エンジン
に通すことによって行われる。このようなスパイダリン
グは、１回だけ実行されることも、定期的に実行される
こともある。殆どのシステムでは、略全部の文書がキャ
ッシュサブシステムにエントリーを持つことが完全に可
能である。これによって、計算コストが減少し、実行時
の分類の遅延が減少する。

【０４２６】ＶＩＩ．グローバルサービス ProReachサービスは、グローバルサービスサーバー１１
２を介してグローバルサービスの組を提供する。グロー
バルサービスは、全ProReachシステム１００及びProRea
ch使用可能ウェブクライアント１０８が利用可能なサー
ビスの集中された組として、インターネットを経由して
動かされるという意味でグローバル（大域的）である。
このようなグローバルサービスの一つの機能は、ウェブ
ビジターを識別するため使用されるグローバル識別子の
割り振りであるが、具ルーバルサービスはその他にも多
数の機能を提供する。

【０４２７】たとえば、以下の６種類のグローバルサー
ビスがある。 ・グローバル識別子サービス ・グローバルアップロードサービス ・グローバルクライアントマネージメントサービス ・イエローページサービス ・グローバル交換手段（エクスチェンジポリシー）サー
ビス ・グローバル集計サービス Ａ．グローバル識別子（ＧＩＤ）サービス ProReachにおいて、ウェブクライアントをできる限り正
確に認識することは常に目標である。このため、多数の
最新技術がウェブクライアントを識別するためグローバ
ル識別子サービス６０２によって使用される。第一に、
各ウェブビジター（又はウェブクライアント）は、１２
８ビット値のような固有の識別子によって表現される。

【０４２８】殆どの場合に、ウェブビジターは個人とし
て識別されない。その代わりに、ウェブビジターがウェ
ブブラウザを使用している機器を識別するだけである。
場合によっては、ウェブブラウザによって保持されるク
ッキーの検査によってウェブブラウザを識別することし
かできないので、機器をおおよそ識別するに過ぎない。
１台のコンピュータが一つのウェブブラウザだけを使用
する場合、コンピュータとウェブブラウザの間の１対１
の対応関係によって、より正確な識別情報を得ることが
できる。しかし、１台の機器のユーザは、多数（Ｎ種
類）のウェブブラウザを備える場合があるので、その場
合、Ｎ人の別々のウェブビジターとして取り扱われる。
また、多数の人が同じウェブブラウザを使用する場合も
ある。この場合、同じウェブブラウザを使用中の異なる
個人を検出することができず、同じブラウザを使用中の
個人の集合が一人のウェブビジターとして扱われる。

【０４２９】それ以外の場合、ウェブビジターは個別に
識別され得る。これらの違いに注意して、２種類の１２
８ビット識別子が使用される。

【０４３０】GID：グローバルIDは、クッキー内でこのG
IDをもつクッキーを使用するコンピュータを識別する。

【０４３１】PID：個人IDは、ログイン名及び他の人口
統計学的データに基づいて個々のウェブビジターを識別
する。

【０４３２】上記のGID及びPIDは、共に１２８ビットで
ある。これら２種類の識別子を区別するため、GIDの第
１ビットは常にゼロに設定され、PIDの第１ビットは常
に１に設定される。したがって、GIDとPIDは相互に容易
に区別される。

【０４３３】グローバル識別子サービス６０２は、GID
及びPIDの割り振り、若しくは、計算の際に重要な役割
を果たす。グローバルサービスサーバー１１２のこの局
面での「クライアント」は、他のウェブサーバー、特
に、ProReach使用可能ウェブサーバー１０２である。こ
れらのProReach使用可能ウェブサーバー１０２は、ウェ
ブビジターを識別するため、すなわち、コンピュータの
場合にはGIDを、人の場合にはPIDを識別するため、グロ
ーバル識別子サーバー６０２の補助を必要とする。識別
情報を要求するProReach使用可能ウェブサーバー１０２
は、識別子要求元と呼ばれる。これらの識別子要求元
は、グローバル識別子サービス６１２に識別情報要求を
行う。各識別情報要求は、２種類の要求のいずれか一方
である。２種類の要求とは、匿名識別情報要求と、個人
識別情報要求である。それぞれの要求は以下のように取
り扱われる。

【０４３４】１．ＧＩＤ要求 ウェブクライアント１０６を識別するためGIDを要求す
るProReach使用可能ウェブサーバー１０２は、グローバ
ル識別子サーバー６１２に要求を出す。使用されるプロ
トコルは、ウェブサーバーとして動作するグローバル識
別子サーバー６１２がProReachクッキーへのアクセス権
を獲得できるようにHTTPベースである。この要求のプロ
セスフローは図７乃至９を参照して既に説明した。

【０４３５】HTTPプロトコルはウェブサーバーがそのウ
ェブサーバー専用のクッキーを調べることだけを許可す
るので、ProReach使用可能ウェブサーバー１０２は、こ
のProReachクッキーを直接には検査できない。ProReach
使用可能ウェブサーバー１０２はProReachドメインに属
するのではなく、固有のドメインに属するので、ウェブ
サーバー１０２はProReachクッキーにアクセスできな
い。そのため、ProReach使用可能ウェブサーバーは、
（もしあれば）ProReachクッキーに格納されたGIDへの
アクセス権を取得するため、ProReachドメインで動くグ
ローバルサーバーに依存する。

【０４３６】ウェブクライアント１０６がProReach使用
可能ウェブサーバーと交信するとき、ProReach使用可能
ウェブサーバーは、ウェブクライアント１０６をグロー
バルサービスサーバー１１２に切り換えるため、HTTPプ
ロトコルを使用する。しかし、グローバルサービスサー
バー１１２は、ウェブクライアント１０６を元のウェブ
サーバー１０２に切り換えることができなければならな
い。これは、コールバック情報を含むURLを用いてウェ
ブクライアントをグローバルサービスサーバー１１２に
切り換えるウェブサーバー１０２によって行われる。特
に、URLはウェブサーバー１０２のドメインと、その他
のデータとを含む。

【０４３７】URL符号化要求の厳密なフォーマットは、
おおよそ以下のようなフォーマットである。

【０４３８】http://www.ProReach.com/servlet/getGid
?webserver=www.webserver.com/index.html ここで、www.webserver.comは、要求側ウェブサーバー
１０２のドメインを識別する。

【０４３９】ウェブクライアント１０６は、転送（切り
換え）要求の一部としてURLを受信する。ウェブクライ
アントは、自動的にこのURLに進み、ProReachクッキー
を伝達する。グローバル識別子サーバー６０２は、この
要求を受け、ウェブサーバーの要求識別子及びの名称を
抽出する。グローバル識別子サーバー６０２はProReach
クッキーを調べる。ウェブサーバーが存在する場合、グ
ローバル識別子サーバー６０２はそのGIDを取得する。
ウェブサーバーが存在しない場合、グローバル識別子サ
ーバー６０２はGIDを生成し、そのGIDが埋め込まれたPr
oReachクッキーを作成する。このGIDはシステム全体を
通じて唯一（ユニーク）であることが保証される。GID
を含むクッキーは、ウェブクライアントに保存され、次
の機会までウェブクライアントに置かれる。また、クラ
イアントは、このクッキーを承認しているとは想定でき
ないので、クッキーは承認された場合に限り視覚化され
る。このことは、そのクッキーが承認されたかどうかを
判定するための検査を十分に保証するために重要であ
る。

【０４４０】次に、ProReachウェブサーバーは、元の
「クライアント」ウェブサーバーへのウェブ切り換えを
行う。したがって、このスキームを巧く動作させるため
に２回のウェブ切り換えが行われる。２番目のウェブ切
り換えは、第１のウェブ切り換えと逆向きに行われ、こ
のとき、ウェブクライアントが転送されるURLには、獲
得されたGIDが収容される。

【０４４１】１２８ビットのGIDが８進数表記で、12345
6787012345677と表される場合に、ProReach使用可能サ
ーバー１０２に対し得られるメッセージは次のような形
で表される。

【０４４２】http://www.webserver.com/index.html?gi
d=123456787012345677 情報をエンコーディングするため使用されたこのフォー
マットは一例に過ぎない。元のウェブサーバー１０２
は、このメタデータを受け取り、入力した要求をGIDと
関連付け、次に、このGIDを使用する何らかのHTTPセッ
ションに関連付ける。

【０４４３】グローバル識別子サーバー６１２は、GIDH
IDテーブルと呼ばれる別のテーブルを保持する。このテ
ーブルには、HID列とGID列の２列が含まれる。HIDは、P
roReachシステム１００を一つずつ識別する識別子であ
り、特に、ハブIDが用いられる。その例は以下の通りで
ある。

【０４４４】

【表７】 ProReachがGIDをProReachシステム１００に返すとき、
このテーブルの行には、要求側ProReachシステムのHID
と返却されたGIDが確実に収容される。この行が既に存
在する場合には、変更する必要はない。行が存在しない
場合（たとえば、新しく作成されたGIDの場合、或い
は、サーバー１０２への新しいウェブクライアントのGI
Dの場合）、行が挿入される。これは、多対多の関係で
あることに注意する必要がある。各HIDは、多数のGIDと
関連付けられ得る。各GIDは多数のHIDと関連付けられ得
る。たとえば、GID 023231787012345677は、二つのハ
ブ３９１と４２１に関連付けられる。すなわち、このウ
ェブクライアント１０６は両方のハブを訪れたときに使
用されたことを意味する。

【０４４５】このGIDHIDテーブルを使用することによ
り、ウェブビジターが訪れたハブはどのハブであるかを
計算することができるSQLのような問合わせが簡単に作
成される。また、一つののハブを訪れたウェブビジター
を計算することも容易である。さらに、二つの異なるハ
ブを訪れたウェブビジターが簡単に計算される。

【０４４６】２．ＰＩＤを用いた個人識別 個人を一人ずつ個別に識別することは困難な場合が多
い。たとえば、二人の別々の人が、同一名と同じ誕生日
をもつことがある。逆に、職業に携わるときには旧姓を
名乗り、それ以外の場合には結婚後の苗字を使用する人
は、同じ人であるにもかかわらず二つの名前を持つ。し
たがって、二人のウェブビジターが実際に同一人物であ
るかどうかを判定するため、二人のウェブビジターの人
口統計学的データを比較し、比較ルールの組を用いるこ
とによって、この人口統計学的データが同一人物を表す
かどうかを判定する。この結論は、人口統計学的データ
と比較ルールの質及び量の両方に依存した判断である。

【０４４７】個人の人口統計学的データを（特定人物
の）一件書類と呼ぶ。一件書類中の実際のデータは変化
し得るが、典型的に、名前、生年月日、性別、現住国、
出身国などの標準的な人口統計学的データのような属性
を含む。一件書類は、主要な電子メールアドレス、公開
された全電子メールアドレス、職場電話番号、自宅電話
番号、携帯電話番号、友人関係、出身校、配偶者名、教
育レベル、宗教、職業、趣味、好きなスポーツ、好きな
音楽、好きな本、好みのウェブサイト、好みのウェブペ
ージ等を含む。一件書類に格納されるべきあらゆる属性
を予測することは困難であるため、一件書類は、単にハ
ッシュテーブルとして実現されるので、属性名はキーと
して使用され、属性値はキーに基づいてハッシュテーブ
ルに記憶される。

【０４４８】PIDを用いて個人を識別する要求は、個人
識別要求を呼ばれる。個人識別要求は、PIDと関連付け
られた一件書類から選択された人口統計学的情報の一部
の集合（たとえば、名前、生年月日、性別及び職業）を
含む。かくして、PID毎に、ProReachシステムは一件書
類テーブルに一件書類を保持する。一件書類テーブルの
一例は以下の通りである。

【０４４９】

【表８】 上記表の列の項目は例示に過ぎない。たとえば、以下の
テーブル定義は、同一人物が多数の電子メールアドレス
又は物理的アドレスをもつ可能性を考慮していないが、
これは、各PIDに多数の電子メールアドレス用フィール
ドを設けることによって容易に実現される。同様に、そ
の他の人口統計学的属性のための付加フィールドを簡単
に設けることができる。

【０４５０】一件書類テーブルを使用することにより、
グローバル識別子サービス６１２は、このようなウェブ
ビジター一件書類のデータベースを保持する。テーブル
の各行は、特定のウェブビジターの一件書類を表す。

【０４５１】ビジターがウェブサーバー１０３をビジッ
トしたとき、サーバーは、ユーザが以前に訪れたことが
あるかどうかを判定する。典型的に、これは、ウェブビ
ジターからの名前及びパスワードを要求することによっ
て行われる。名前及びパスワードを使用することによ
り、同じ名前と同じパスワードをもつユーザが登録され
ているかどうかが検査される。このようなユーザが登録
されている場合、このユーザのPIDは既に取得済みであ
る。このPIDは以下の方法によって取得される。

【０４５２】登録プロセス中に、登録中のユーザから人
口統計学的データが収集される。典型的に、データの収
集は、ユーザにウェブベースのフォーム上でこの情報を
含むフォームを書き込ませることによって行われる。登
録ユーザに関する人口統計学的データは一件書類を作成
するため使用される。

【０４５３】ウェブサイトに登録されるユーザの一件書
類は、グローバル識別子サービスに発送され、そこで、
この一件書類は、一件書類テーブル内の他の全ての一件
書類と照合される。一件書類が既存の一件書類と一致し
ているかどうかを判定するため使用される実際の照合ル
ールは、システム管理者によって指定され、たとえば、
二つの一件書類が同一人物を表すかどうかを判定するル
ールを含むエキスパートシステムに実現される。一致す
る一件書類が見つけられたとき、一件書類と関連したPI
Dは、この新しく登録されたユーザのPIDであり、PIDが
ウェブサーバー１０２に返される。

【０４５４】一致している一件書類が見つからなかった
場合、ビジター一件書類がこのウェブクライアントのた
め作成される。このビジター一件書類は、PIDと、名前
と、電子メールアドレスと、その他の利用可能なメタデ
ータとを含む。一件書類は、次に、ビジター一件書類の
一件書類テーブルに付け加えられる。新しいPIDは、識
別要求の結果として、ProReach使用可能ウェブサーバー
１０２に返される。

【０４５５】一件書類が一致したとき、（識別要求中
の）新しい一件書類は、既存の一件書類には存在しない
情報を含む、このとき、新しい情報は、既存の一件書類
に追加され、将来一致する可能性が高くなる。

【０４５６】他の実施例は、PIDをウェブサーバーに返
却しない。その代わりに、RIDと称される固有のユニー
ク識別子がウェブサーバーに返される。RIDは整数又は
その他の文字列でもよい。一体的に、ウェブサーバーの
HID（ハブ識別子）とRIDは、グローバルサービスサーバ
ー上でPIDを個別に識別する複合キーを形成する。これ
らのキーは、グローバルサービスサーバーに保持された
HIDRIDテーブルに格納される。HID及びPIDは、RIDをユ
ニークに識別することに注意する必要がある。

【０４５７】PID要求が満たされるとき、ユニークなPID
及びRIDは、ProReach使用可能サーバーに返される。こ
れは以下の通り行われる。計算されたPIDと、要求側ハ
ブのHIDは、HIDRIDテーブルからRIDを選択するため使用
される。テーブル内にこのようなPIDとHIDの組合せが存
在しない場合、ユニークなRID値がその組合せに対して
生成され、テーブルに格納される。RIDは、HIDの列とRI
Dの列が複合キーを形成するという意味でユニークに決
めなければならない。最後に、選択された（若しくは、
動的に生成された）RIDがPID要求の結果として返され
る。以下の例示的なHIDRIDテーブルはこの関係を表して
いる。

【０４５８】

【表９】 このアプローチの利点は、RIDとPIDの間に間接的なレベ
ルが存在することである。この間接的なレベルが存在す
ることにより、一件書類照合の間違いを訂正することが
できる。たとえば、PID 0232310000345677と765231789
345644が実際に同一人物を表現することが判明した場合
を考える。このエラーは、関連したHID-PIDが同じPIDを
もつように、一方のPIDを他方のPIDで置換すべくHIDRID
テーブルを調整することにより修正される。たとえば、
第２行のPIDの欄は、以下のように値0232310000345677
をとるように更新される。

【０４５９】

【表１０】 この変更は、RIDが343242であるハブ184のウェブビジタ
ーが、RID444343をとるハブ100のウェブビジターと比較
されるとき、両者が同一人物と知て識別されることを保
証する。

【０４６０】グローバル識別子サービスは、このような
HID/RIDの２個のペアを受け取り、それらがHIDRIDテー
ブル内の同じPIDと関連している場合に「真」を返すサ
ービスを提供する。それ以外の場合、このサービスは
「偽」を返す。

【０４６１】この間接的なレベルは、二人の実際には別
人のウェブビジターが一件書類照合によって、間違って
同一人物であると判定された場合に、一件書類の照合誤
りを修正するためにも使用される。上記の例と同様に、
この間違いは、HID/RIDテーブル内で修正される。同一P
IDをもつ２行以上の行は、それらのPID欄が別個になる
ように変更される。さらに、新しいPIDに対する新しい
一件書類が一件書類テーブルに作成される。

【０４６２】Ｂ．グローバルアップロードサービス グローバルアップロードサービス６０６は、ProReach使
用可能ウェブサイト１０８にそのウェブ行動をアップロ
ードさせる。受信データに応じて、このサービスは、ア
ップロードが成功したときに、承認情報をProReachクラ
イアント１０８に送信する。

【０４６３】さらに、グローバルアップロードサービス
６０６は、このデータを適当なProReachシステム１００
に配信する責任がある。グローバルアップロードサービ
スは、ProReachシステム１００がウェブビジターデータ
に加入することを許可する。グローバルアップロードサ
ービスは、ProReachシステムがウェブビジターデータへ
の加入を停止することも許可する。各システム１００
は、特定のウェブビジターのアップロードされたデータ
に加入することが可能である。そのため、サーバー６０
６は、GIDのリストをシステム１００に送り、システム
は加入したいビジターのGIDを返す。

【０４６４】ウェブクライアントがグローバルアップロ
ードサービスを使用して自分のウェブ行動をアップロー
ドするとき、グローバルアップロードサービスは、この
ビジターデータに加入しているシステム１００を見つけ
る。サービスは、加入者ProReachシステム１００に、そ
のシステムが待望しているデータが到着した旨を通知す
る。この通知は、各加入者ProReachシステム１００の受
信クライアントデータサービスに送信される。ProReach
システムに待機中データの到着が通知されると、通知さ
れた各ProReachシステム１００は、適当な時間的区間内
（たとえば、２４乃至７２時間）にそのデータを取得す
る。そのデータが獲得されなかった場合には、削除され
る。

【０４６５】アップロードされたデータの配信を管理す
るため、グローバルアップロードサービス６０６は、ア
ップロードされたデータを含むパッケージと、受取人リ
ストを作成する。このリストは、加入者であるProReach
システム１００をHIDによって識別し、タイムスタンプ
を含む。データは現在時刻がタイムスタンプよりも進ん
でいるときに削除される。同時に、アップロードされた
データの期限が満了し、削除される。

【０４６６】さらに、加入者が現れて、アップロードさ
れたデータを取得したとき、その加入者は受取人リスト
から削除される。全ての加入者がリストから削除された
とき、データは全受取人に配付されているので、データ
は破棄される。勿論、受取人がデータを獲得できなかっ
たとしても、データの期限が過ぎると、データは破棄さ
れる。

【０４６７】Ｃ．グローバルクライアント管理サービス ProReachは、ウェブユーザの行動を監視するクライアン
ト側ソフトウェアを備えているウェブクライアントを追
跡する。定期的に、収集されたデータが上述のようにPr
oReachにアップロードされる。

【０４６８】この機能を実現するため、ユーザは自分の
コンピュータにインストールするためProReachクライア
ントソフトウェアをダウンロードすることができる。グ
ローバルマネージャサービス６０８は、クライアントソ
フトウェアをダウンロードした（GIDによって識別され
た）このようなクライアントコンピュータのリストを保
持する。ソフトウェアがインストールされたとき、クラ
イアント１０８は、クライアントのGIDと共に確認情報
をサービス６０８に送信する。確認情報が与えられたと
き、確認情報と共に与えられたGIDがGIDリストに保持さ
れる。インストレーション先から受信されたGIDと、一
件書類中の電子メールアドレスとを使用して、クライア
ント側追跡ソフトウェアをインストールしたウェブクラ
イアントと交信することが可能になる。

【０４６９】クライアント側追跡ソフトウェアがアンイ
ンストールされた場合、アンインストール先はアンイン
ストールメッセージを関連したGIDと共にサービスに送
信する。このGIDは、クライアント側追跡が許可されたG
IDリストから削除される。

【０４７０】Ｄ．イエローページ このサービス６１０は、ProReachシステム１００のデー
タベースを保持する。各ProReachシステム１００はイエ
ローページサービス６１０を用いて登録され、このデー
タベースに掲載される。データベースには、ProReachシ
ステム１００ごとに以下の項目が格納される。 ・ProReachシステムの名称 ・ハブのIPアドレス及びポートと、サポートされるドメ
インのリスト ・システム管理者の電子メールアドレスを含むProReach
システムの連絡先情報は、ProReachシステムの責任者に
電子メールを送信するため収容される。 ・ProReachシステムを個々に識別するユニークProReach
システムID（たとえば、HID） ・リストが私設、保護、若しくは、公開のいずれである
かを示す情報。リストは、（ProReachグローバルサービ
ス以外の）他人が参照できない場合、私設リストであ
る。リストは、共通ProReachアライアンス８００を共有
するProReachシステムだけによって参照される場合、保
護リストである。リストが公開リストであるとは、全て
のProReachシステム１００による参照が許可されること
である。デフォルトは、私設リストである。 ・ProReachシステムがメンバーとして所属するアライア
ンス８００のリスト ProReachシステム１００は、自分自身のエントリーを追
加、削除、若しくは、更新することができる。ProReach
システム１００は、公開リストのエントリーと、私設リ
ストであって同じアライアンス内に含まれるリストのエ
ントリーとを参照することができる。

【０４７１】サービス６１０は、エントリーを追加、削
除、更新する機能と、エントリーを公開エントリー、私
設エントリー、若しくは、保護エントリーに変更する機
能とを有する。このサービスは、さらに、システム１０
０がアライアンスに加入、若しくは、退会することを許
可する。サービスは、さらに、企業名、ドメイン、若し
くは、アライアンスによる参照機能を提供する。最後
に、サービス６１０は、アライアンスを作成し、全アラ
イアンスのリストを作成し、アライアンスのメンバーの
リストを作成する機能がある。

【０４７２】Ｅ．グローバル交換手段（エクスチェンジ
ポリシー） 各ProReachシステム１００は、交換手段を決定すること
ができる。交換手段は、二つの関連した別々の目的に利
用される。第一に、交換ポリシーは、人口統計学的ステ
ートメントを記述する。人口統計学的ステートメント
は、どのような種類のビジターがProReachシステムを訪
問したか、すなわち、ビジターの数、関心の種類、ビジ
ットの頻度、ウェブビジターの種類などを説明する。こ
の人口統計学的ステートメント中の情報は、ステートメ
ントを作成する個々のProReachシステムの責務である。
人口統計学的ステートメントは、このProReachシステム
を評価するための手段として他のシステムによって使用
される。このような評価は、一つのProReachシステムが
他のProReachシステムとの共有関係を検討する場合に行
われる。第二に、交換手段は、匿名ユーザグループと、
カテゴリーコンプレックスと、ユーザプロフィールの取
引を可能にする。この手段は、取引で利用できるよう
に、一つ以上の特定ユーザと、ユーザグループと、コン
プレックスを識別することができる。プロフィール及び
コンプレックスは、受取人が個別ユーザを私的に識別す
るため使用できる情報を含まないので、この情報は匿名
である。このような情報の集まりは情報リソースに記述
され、情報リソースは他のシステムがリソースを識別す
る探索を用意に行えるようにキーワードと関連付けられ
る。情報リソースは、取引されない情報（たとえば、プ
ロフィール、カテゴリー、グループ、又は、コンプレッ
クス）を記述する一つ以上の例外を含むことができる。

【０４７３】たとえば、ProReach使用可能なwww.acme.c
omは、SportsCustomerリソースをもち、別のProReachシ
ステム使用可能なwww.womensclothig.comは、WomensClo
thingリソースをもつ。これらの二つのProReachシステ
ムは、双方のグループのプロフィールデータが、１回だ
け、若しくは、定期的に互いに送信されるような交換に
同意する場合がある。このような交換手段のデータは、
これらのProReachシステムが互いに相手を見つけて、何
らかの取引を行うプロセスを簡単化する。このデータの
伝送は、好ましくは、顧客連絡先情報を含まないので、
ウェブビジターの匿名性は、システム全体を通じて確保
される。しかし、たとえ、この制約がある場合でも、各
ProReachシステムのプロフィール情報のデータベースは
増加するので、情報は依然として有用である。

【０４７４】たとえば、この交換を通じて、www.acme.c
omがGID9834232122に関連したウェブビジターのプロフ
ィール情報を獲得した場合を考える。また、www.acme.c
omには、GID9834232122に関連したウェブビジターが訪
れたことがないとする。そして、GID9834232122に関連
したウェブビジターがこのサイトをビジットしたとす
る。このウェブビジターGID9834232122は、www.acme.co
mをはじめて訪れたとしても、ProReach使用可能ウェブ
サイトは、このウェブビジターに関する情報を既に保有
している。このウェブサイトは、この情報をwww.womens
clothing.comから取得している。

【０４７５】交換手段は、ジャストインタイム方式の共
有手段を指定することができる。ジャストインタイム方
式の共有手段は、特定GIDに対するプロフィール情報が
要求され得ることを意味する。このような明示的な要求
は有用である。なぜならば、新しいビジターがProReach
使用可能ウェブサイトを訪問したとき、ウェブサイトは
ウェブビジターを歓迎し、バックグラウンドで、このGI
Dに関連したプロフィール情報を要求し、交換相手から
の情報を調べることができるからである。

【０４７６】したがって、グローバル交換手段サービス
６１２は、ProReachシステムが、交換手段を作成、削
除、及び、変更できるようにする。作成の中には、シス
テム１００が取引を望む情報リソースの定義が含まれ
る。このサービスは、さらに、交換手段のための情報リ
ソースを作成、削除、及び、変更するメソッドを与え
る。サーバー６１２は、リストに掲載された交換手段の
データベースを保持し、キーワード、カテゴリー、ユー
ザグループ、若しくは、ユーザGIDによるデータベース
の検索を可能にする。

【０４７７】グローバルプロフィールは、個別のProRea
chシステムで保持されるのと全く同様に保持される。し
かし、ローカルなシステム専用プロフィールとは異な
り、グローバルプロフィールは、標準カテゴリーツリー
１４００内のカテゴリーに関心のあるユーザだけを追跡
する。このデータベースは、非常に膨大であると予想さ
れるので、高性能かつ規模を変更することができるデー
タベースが望ましい。好ましい一実施例において、この
ようなデータベースを実現するためOracle8Iデータベー
スが使用されるので、Java処理は、実際のデータベース
サーバー内で実行され得る。

【０４７８】ＶＩＩＩ．ＰｒｏＲｅａｃｈクライアント
側のウェブ使用データ収集 Ａ．ウェブ行動監視 上述の通り、ある種のウェブクライアントは、ウェブ行
動を追跡するクライアント側ソフトウェアを搭載するこ
とによってProReach使用可能になる。このウェブ行動
は、ProReach使用可能ではなく、ウェブ行動を直接追跡
する能力のないウェブサーバー１１０上で生じたウェブ
行動に対してのみ記録されるべきである。

【０４７９】ウェブ行動は、ウェブイベントレコードに
記録され、グローバルアップロードサービスにアップロ
ードされる。一実施例において、この行動は、動作中に
ブラウザを監視することによって捕捉される。一つの方
法は、ブラウザが外部アプリケーションのためのAPIサ
ポートを有する場合に、ブラウザイベントを監視し、ブ
ラウザと通信するため、ブラウザAPIを使用することで
ある。別の考え得る方法は、ブラウザのウィンドウイベ
ントを監視するため、Windowsのフックのような低レベ
ルWindows API／サービスを使用することである。

【０４８０】Microsoft Internet Explorerブラウザを
監視するため、COMベースオブジェクトモデルを有するI
nternet Explorerに付属するブラウザ・ヘルパー・オブ
ジェクト(BHO)を使用するのが好適である。BHOは、ある
種の登録キーの下で登録されたCOMインプロセスサーバ
ーである。起動時に、Explorerは、そのキーを捜し、CL
SIDが格納されている全てのオブジェクトをロードす
る。BHOは、ブラウザのメインウィンドウに拘束され
る。ブラウザウィンドウの新しいインスタンスは、それ
ぞれ、専用のBHOが関連付けられる。BHOは、ブラウザウ
ィンドウが壊されたとき、アンロードされる。BHOは、E
xplorer OLE-COMイベントに関する通知を受信すること
ができる。ブラウザが始動させることができるイベント
の種類は全部で１８種類である。DownloadComplete、Na
vigateComplete2、OnStatusBarなどのイベントを監視す
ることにより、BHOはブラウザウィンドウにロードされ
た文書を知ることができる。

【０４８１】Netscapeブラウザは、NCAPI（ネットスケ
ープクライアントAPI）と呼ばれるAPIを提供する。NCAP
Iは、二つの主要部をもつ。一方の主要部はOLEを使用
し、もう一方の主要部はDDEML（ダイナミック・データ
・エクスチェンジ・マネージメント・ライブラリ）を使
用する。ProReachクライアント側追跡への利点の一つは
DDEMLである。ExplorerにおけるBHOと同様に、アプリケ
ーションは、Netscapeブラウザと通信し、ある種のブラ
ウザ行動が発生したときに通知を受けるため、NCAPIのD
DEMLを使用することができる。BHOと異なる点は、NCAPI
のDDEMLプログラムが外部アプリケーションであり、ブ
ラウザウィンドウではなく、Netscapeプロセスに固定さ
れることである。NCAPI DDEMLプログラムの一例は、Ne
tscapeブラウザプロセスに関連した全ブラウザウィドウ
内の全ウェブ行動を監視することができる。

【０４８２】Ｂ．ＰｒｏＲｅａｃｈクライアントウェブ
使用データのフィルタ及び集計 １．時間ベース統合 第一に、ウェブコンテンツ間のユーザの閲覧及び移動が
素早い場合、殆どのウェブイベントは記録しても意味が
ないと考えられる。第二に、多数のウェブクライアント
１０８は時間的に同期していないので、レコードに記録
された時刻はクライアント間で一致しない。この問題を
取り扱うため多様なメカニズムが設けられる。

【０４８３】ａ）ウェブイベントレコードタイムスタン
プの調整 各クライアント機器は異なるクロック設定値をもつ。そ
のため、ユーザのウェブ行動の時刻をクライアント機器
のクロックに基づいて記録しても意味がない。ProReach
クライアントソフトウェアは、グローバル基準時刻を用
いて各ユーザウェブ行動のタイムスタンプを調整する必
要がある。この調整は、ウェブイベントレコードがアッ
プロードされる前に行われる。

【０４８４】１）ProReachクライアントソフトウェア
は、最初に、ProReachグローバルアップロードソフトウ
ェアにサーバーのGMT基準時刻を問い合わせる。

【０４８５】２）ProReachクライアントソフトウェア
は、クライアント機器とProReachサーバーのGMT時刻の
差を計算する。この差はTDで表される。

【０４８６】３）ProReachクライアントソフトウェア
は、この差TDをタイムスタンプに加えることによりウェ
ブイベントレコードの各エントリーのタイムスタンプを
調整する。

【０４８７】ｂ）短時間行動の無視 ウェブ行動が非常に短時間、たとえば、１０秒未満しか
続かない場合、ProReachは、そのウェブ行動をウェブイ
ベントレコードに記録しない。この状況は、ユーザが以
前ビジットしたURLを探索するためブラウザの戻る(bac
k)／進む(forward)ボタンを使用している間、あるい
は、ユーザがリンクの中を通過するときに生じる。

【０４８８】ｃ）ウェブ行動の集計 既に説明したように、多数回出現する同じウェブ行動は
集計される。この集計は、URLがProReachクライアント
ソフトウェアによって捕捉される途中で行われる。計算
のスピードを上げるため、ProReachクライアントソフト
ウェアは、WURを格納するためハッシュテーブルを使用
する。

【０４８９】２．他のデータのフィルタ 収集されるデータをさらに制限するため、クライアント
１０８は、ユーザのホームページへのアクセスについて
のレコードを除去し、記憶しない。しかし、ユーザのホ
ームページは、ユーザに関する付加的な人口統計学的情
報又は関心情報を与えるため、ユーザのプロフィールに
記憶される。

【０４９０】上述の通り、クライアント１０８がProRea
ch使用可能ウェブサーバー１０２をビジットするとき、
クライアント１０８はウェブイベントを捕捉しなくても
よい。したがって、クライアント１０８がウェブサーバ
ー１０２、又は、このようなサーバーによるサービスを
享受するドメインのURLを観察するとき、クライアント
はウェブ行動データを記憶しない。

【０４９１】３．プライバシー制御 ProReachクライアント１０８のユーザは、インフォーム
ド・コンセントに基づいてProReachクライアントソフト
ウェアの使用に同意する。ProReachシステムは、潜在的
なユーザがProReachクライアントソフトウェアのユーザ
になる前に、明示的なプライバシーステートメントを潜
在的なユーザに与えるので、ユーザは自分の行動が追
跡、記録されることがわかる。ProReachクライアントソ
フトウェアは、ユーザ変更可能制御メカニズムとデフォ
ルト制御メカニズムを含む。デフォルト制御メカニズム
は、全ユーザに適用され得る共通のプライバシー関連問
題の制御を扱う。これらのメカニズムは、ユーザが自分
の好みに応じて、記録されるウェブ行動データを選別で
きるようにする。

【０４９２】Ｃ．プライバシー設定値（ユーザ変更可
能）に基づくフィルタ ProReachクライアントソフトウェアは、構成可能なユー
ザプライバシー優先度と、ユーザプライバシー設定値に
基づく少なくとも２種類のフィルタ法、すなわち、URL
パターンベースフィルタ法及びキーワードベースフィル
タ法をサポートする。

【０４９３】１．ＵＲＬパターンベースフィルタ ProReachクライアントソフトウェアは、ユーザが、記録
されることを望まず、かつ、ProReachシステム１００と
共有されたくないURLのパターンを設定することを可能
にする。URLパターンは、完全なURL、URLのドメイン
部、あるいは、ワイルドカード文字を含むURLの一部の
いずれでもよい。URLパターンの例は、 １）完全URL：http://www.xyz.com/xyz/abc.html ２）部分URL：http://www.xyz.com ３）URLのドメイン部：http://www.xyz.com ４）ワイルドカードパターン：*xyz* である。

【０４９４】２．キーワードベースフィルタ ユーザは、プライバシー優先度設定値の一部としてキー
ワードのリストを指定することができる。ProReachクラ
イアントソフトウェアは、捕捉されたURLの内容をキー
ワードと照合し、一致するキーワードが存在する場合、
URLはウェブイベントレコードに記録されない。キーワ
ード照合には、一つの単語、多数の単語、及び、句（フ
レーズ）が含まれる。一実施例において、このプロセス
がユーザのコンピュータに与えるオーバーヘッドを少な
くするため、デフォルトとして、クライアント１０８
は、文書タイトルと、HTML”keyword”の<メタ>タグだ
けに対しキーワード照合を行う。あるいは、全文書内容
のキーワード照合は、ユーザ選択可能なオプションとし
て提供される。

【０４９５】一実施例において、ProReachクライアント
ソフトウェアは、そのユーザに標準キーワードテンプレ
ートを与える。各テンプレートは、ProReach標準カテゴ
リーツリーからの特定カテゴリーに基づく。ユーザは、
特定のテンプレートにより多数のキーワードを付加する
選択肢がある。また、テンプレートからのキーワードが
ウェブコンテンツのページと一致する場合、URLは記録
されない。

【０４９６】Ｄ．デフォルトプライバシー関連フィルタ ProReachクライアントソフトウェアは、ユーザのウェブ
行動データへのプライバシー関連アクセス権に関するデ
フォルト手段をサポートする。あるプライバシー関連行
動は、ユーザログインプロセスである。多数のウェブサ
イトは、簡単なHTMLフォームベースログインを使用し、
ユーザログイン情報はHTTPの”GET”要求によってCGIプ
ログラムに送られる。このような場合に、ユーザのログ
インデータは、URLに全て収容され、ProReachクライア
ントソフトウェアはこれらのデータを全て獲得すること
ができる。最も簡単なフォームの場合、ログインデータ
は、ユーザのウェブブラウザから送信される前に暗号化
さえなされていない。ProReachクライアントソフトウェ
アがこの種のURLを平等に取り扱い、全部をProReachシ
ステムに送信した場合、プライベート情報が不用意に漏
れてしまう。ProReachシステムの制御権を有する人は、
多数の人の非常にプライベートな情報、たとえば、銀行
口座、社会保険番号などにアクセスできることになる。
したがって、ProReachクライアントシステムは、URLに
含まれるログインデータを選別し、除去することをデフ
ォルト方針とする。たとえば、ユーザJoeがブラウザを
用いてXYZ銀行のオンラインサービスにログインしよう
としているとき、URLは、 http://www.XYZbank.com/login.cgi?login=joe&pwd=joe
xyz&set_cookie=xyz1234567abcdefg のように見える。

【０４９７】この場合、ProReachクライアントソフトウ
ェアは、URL内の“？”以降の部分文字列を除去し、あ
るいは、URL全体を完全に無視する。

【０４９８】Ｅ．ＰｒｏＲｅａｃｈクライアントデータ
アップロード １．ＰｒｏＲｅａｃｈクライアントアップロードキュー ProReachクライアントソフトウェアはアップロードキュ
ーを保持する。クライアントコンピュータのオペレーテ
ィングシステムのファイルシステムがProReachクライア
ントアップロードキューを作成するため使用される。ア
ップロードキューの各項目はファイルである。ファイル
名は、固定部と可変部とを有する。ファイル名の可変部
は番号である。ProReachクライアントソフトウェアは、
このキュー番号のカウンタを保持する。たえとば、ファ
イル名は、ProReach1.WER、ProReach2.WER、ProReach3.
HOMなどである。"WER"は、アップロード項目がウェブイ
ベントレコードのリストであることを意味し、"HOM"
は、アップロード項目がユーザのブラウザのスターアッ
プページURLであることを意味する。キューが空である
とき、カウンタは０にリセットされる。アップロードキ
ューにはプリセットサイズがあり、キューはFIFO（先入
れ先出し）である。アップロードキューがフル（満杯状
態）になり、かつ、新しいデータをキューに入れる必要
がある場合、キューの最初の項目を破棄する必要があ
る。アップロードキューサイズは、十分なサイズ、たと
えば、５００Kのサイズがあるので、データのアップロ
ードが行われる前に、データが破棄されることはない。
データは、アップロードが成功した後、あるいは、数回
の反復的なアップロードの試みの後に破棄される。

【０４９９】２．ＰｒｏＲｅａｃｈアップロードストリ
ーム及びアップロードレコード ProReachアップロードストリームは、アップロードセッ
ションにアップロードされたデータを表現する。１回の
アップロードでアップロードされたデータは、数個のア
ップロードレコードを有する。アップロードストリーム
はヘッダ部及びデータ部を有する。ヘッダは、アップロ
ードストリームの始まりを示し、ユーザのProReachグロ
ーバルIDと、そのアップロードストリームに収容された
アップロードレコード数を収容する。データ部は、１個
以上のアップロードレコードを収容する。アップロード
ストリーム中の各アップロードレコードは、アップロー
ドキュー内のアップロード項目に対応する。アップロー
ドレコードには、ウェブイベントレコードと、HOMレコ
ードの２種類のレコードが存在する。各アップロードレ
コードは、ヘッダ部とデータ部とを有する。ヘッダは、
アップロードレコードの始まりを示し、データは実際の
アップロードデータである。アップロードレコードのヘ
ッダは、ヘッダデバイダと、このレコードのアップロー
ドキュー項目の名称と、アップロードレコード番号と、
データ長（ヘッダ及びレコードデバイダを除く）と、デ
ータ部のレコード数とを収容する。アップロードストリ
ームとアップロードレコードの両方のヘッダは、固定長
である。ウェブイベントレコード、及び、HOMレコード
は、可変長である。ProReachクライアントソフトウェア
は、レコードデバイダとして、非印刷文字を使用する。

【０５００】３．データアップロード ａ）ウェブイベントレコードアップロード ProReachクライアントソフトウェアは、予め構成された
時間的区間で捕捉されたウェブイベントをアップロード
しなければならない。この時間的区間は、予め決めら
れ、好ましくは、ProReachクライアントユーザによって
リセットできないようにされる。好ましい時間的区間
は、１５乃至３０分間隔である。

【０５０１】ｂ）ホームページＵＲＬアップロード このアップロードは、頻繁にはスケジューリングされな
いタスクである。ユーザがスタートアップページを毎日
若しくは毎週変更する可能性は低い。ProReachクライア
ントソフトウェアは、始動されたときに、ユーザのブラ
ウザスタートアップページが変更されたかどうかを検査
する。スタートアップページが変更された場合、ProRea
chクライアントソフトウェアは"HOM"アップロードレコ
ードをアップロードキューに挿入する。ProReachクライ
アントソフトウェアは、スタートアップページが"http"
プロトコルを用いて指定されたウェブページである場合
に限り、この動作を実行するので、スタートアップペー
ジがローカルファイルである場合には、この動作は行わ
れない。

【０５０２】４．時間のアップロード及びアップロード
ステージ 次に、プレアップロード、アップロード及びポストアッ
プロードの３種類ｎステージにおけるデータアップロー
ドに関連したProReachクライアントソフトウェア動作に
ついて説明する。アップロードは、メモリ内のウェブイ
ベントレコードが空ではないとき，又は、アップロード
キューが空ではないときに限り必要とされる。アップロ
ードを行うため、以下の二つの条件がある。 １）ユーザがインターネットに接続され、メモリ内のウ
ェブイベントが空ではないか、若しくは、アップロード
キューが空ではないときに、予め設定されたプリセット
間隔で行われる。 ２）新しいブラウザプロセスが始動され、アップロード
キューが空ではないときに行われる。

【０５０３】ａ）プレアップロードステージ ウェブイベントレコードをアップロードする前に、次の
動作を行う。 １）タイムスタンプの調整 ２）メモリ内の現在ウェブイベントレコードをProReach
アップロードキューに追加。プリセットアップロード時
刻の他に、ProReachクライアントソフトウェアは、もし
存在するならばメモリ内のウェブイベントレコードをア
ップロードキューに追加する必要がある。

【０５０４】ｂ）アップロードステージ ProReachクライアントソフトウェアは、常に、アップロ
ードキューからデータをアップロードする。ProReachク
ライアントソフトウェアは「アップロード閾値」を有す
る。これは、各アップロード中にアップロード可能なデ
ータの量を表す。ProReachクライアントソフトウェア初
期化時に、この閾値はクライアントコンピュータのモデ
ム速度に基づいて計算される。各アップロードタスク
は、５秒以上継続しないように制限されるのが望まし
い。たとえば、クライアントが１４．４Ｋのモデムを使
用する場合、アップロード閾値は、（１４．４Ｋ／８）
＊５＝９Ｋバイトのように計算される。各アップロード
時に、ProReachクライアントソフトウェアは、アップロ
ードキュー内の項目及び閾値までのアップロードデータ
のサイズを検査する。一例として、アップロードキュー
には、１Ｋの項目１と、６Ｋの項目２と、５Ｋの項目３
の併せて３項目が存在する。項目１及び項目２だけが現
在アップロードでアップロードされ、項目３は次のアッ
プロードに残される。アップロード項目がアップロード
閾値よりも大きい場合、ProReachクライアントソフトウ
ェアが実際のアップロードを実行する前に、より小さい
項目に分割される。ユーザが高速ネットワークコネクシ
ョンを使用する場合、閾値は大きくすることができる。
ユーザのネットワークコネクション速度は、初期化時
に、ProReachクライアントソフトウェアによって検出さ
れる。

【０５０５】ｃ）ポストアップロードステージ アップロード後、ProReachクライアントソフトウェア
は、アップロードされたデータを破棄する前に、アップ
ロードされたデータに関するProReachグローバルアップ
ロードサービスからの承認を待つ必要がある。承認が無
い場合、アップロードキュー内の同じ項目は、承認が受
信されるまで繰り返しアップロードされる。アップロー
ドキューのサイズには制限があるので、承認無しに先に
アップロードされた項目は最終的に破棄される。しか
し、このような状況が発生する場合、通常、ネットワー
ク若しくはProReachグローバルアップロードサービスに
重大な問題が生じていることを意味する。

【０５０６】５．ＰｒｏＲｅａｃｈアップロードサービ
ス及びアップロード 前節で説明したように、ProReachクライアントソフトウ
ェアは、アップロードキュー内のアップロード項目を破
棄する前に、アップロードサービスからの承認を待機す
る必要がある。アップロードストリームのヘッダ内のPr
oReachグローバルIDは、アップロードストリームの発信
元と、アップロードされたデータに関係しているユーザ
が誰であるかについて、アップロードサービスに通知す
る。アップロードサービスは、全てのデータが正しく受
信されたことを保証するため、アップロードサービスヘ
ッダ及びアップロードレコードヘッダに収容された情報
を検査する。アップロードサービスは、アップロードス
トリームを正しく受信したことを知らせるため、承認レ
コードをProReachクライアントに送信する。承認レコー
ドは、ヘッダ及びデータを収容する。ヘッダは、承認情
報のデータ部に収容された名前の個数を表現する数を含
む。データ部は、受信されたアップロード項目の名前を
含む文字列であり、名前は","で区切られる。ProReach
クライアントソフトウェアは、承認レコードを受信した
後、承認レコードに含まれる名前と一致する名前を有す
るアップロードキュー項目を削除する。

【０５０７】このクライアントデータアップロードはHT
TPを用いて実現され得る。この場合、グローバルアップ
ロードサービスは、ウェブサーバー１１２に常駐する
か、あるいは、HTTPプロトコルを処理できる必要があ
り、ProReachクライアントソフトウェアはHTTPクライア
ント（エージェント）として実現される。ProReachアッ
プロードストリームは、HTTP POST要求として送信され
る。HTTP POST要求に対するアップロードサービスHTTP
サーバーの応答を待機するProReachクライアントのため
にタイムアウトが設定される。ProReachクライアントが
タイムアウト内に応答が得られないとき、アップロード
データストリームは後で再送される。

【０５０８】ＩＸ．コンテンツターゲッティング（コン
テンツの絞込み） ProReachの特徴の一つは、ウェブビジターに、絞り込ま
れたターゲットコンテンツを配信できることである。ウ
ェブサーバー上で動作し、このターゲットコンテンツを
配信するサービスは、現在のウェブビジターのプロフィ
ールにアクセスするメカニズム、又は、ウェブビジター
が選択した所定のページに関するカテゴリー情報にアク
セスするメカニズムを持つ必要がある。ProReachは、ビ
ジタープロフィール上のPreReachデータ及びページ分類
情報にアクセスするため、Java、"C"、又は、Perl用のA
PIを明らかにすることによって、このメカニズムを実現
する。

【０５０９】動的なウェブサーバープロセスが、CGI若
しくはフィルタ／モジュールから実行時にProReachデー
タにアクセスしなければならない二つの状況がある。

【０５１０】Ａ．ＣＧＩによるプロフィールへのアクセ
ス 各ProReachサーバー１０２は、このProReachハブのネッ
トワーク内のサイトを訪れたことがあるビジター毎にビ
ジタープロフィールのデータベースを保持する。このデ
ータベースは、データベース７２０のプロフィールテー
ブルである。このデータベース７２０をJavaで実現した
一例では、ビジタープロフィールオブジェクトは、この
ウェブビジターの行動の分類情報を表す関心のベクトル
により構成される。このビジタープロフィールのJavaベ
ースのインスタンスは、このビジターに提示されるウェ
ブを定める際に利用されるウェブビジターの実際の名前
及び住所のような文字列型データにアクセスする数種類
のメソッドを含む。たとえば、ウェブビジターに対し、
そのウェブビジターが生活している領域には存在しない
自動車販売店の広告を提示しても意味が無い。

【０５１１】HTTPプロトコル転送機能及びクッキーを使
用してGIDでウェブビジターを個別に識別するプロセス
については既に説明した。ProReach使用可能システム１
００がターゲットコンテンツ配信を行う場合、ウェブビ
ジターのプロフィールを取得するため同様の方法を使用
することができる。図２１には、典型的なProReach使用
可能ウェブサイトの構成が示されている。同図におい
て、プロファイラ７２６はProReachスポーク２０２にあ
る。ウェブサイトが、ウェブサイトのページを要求する
ユーザ毎にユーザプロファイルレコードを取得しようと
するとき、サイト側のフィルタは、ユーザプロファイル
レコードの情報を取得するため、その要求を再度スポー
ク上のウェブサーバー１０２に転送するよう構成され
る。図２１には、ProReachバックオフィスウェブサーバ
ーに転送される要求のフローが示され、プロフィールレ
コードはGET変数としてURLに付加される。これは、実行
時にプロフィールデータを取得する簡単かつ最適に動作
する実現例である。

【０５１２】一部のウェブサイトは、Javaサーブレット
又はアプリケーションからのプロフィールデータにアク
セスしようとする。この場合、APIが設けられる。Java
APIへのアクセスの例は、 VisitorProfile joeUser = new VisitorProfile(ProReachGID); // constru ctor for visitor profile, takes GID as input For (int i = 0; i < joeUser.interestvec.length(); i++) /* Each profile contains a vector of interest names and integer valu es, called interestvec here. This loop will print out all of the intere st names and values for this web visitor */ system.out.println("interst" + joeUser.interestvec[i].get_name( ) + "score is" + joeUser.interestvec[i].get_value()); Int interest_value = joeUser.interstvec.get_value(int interest_indec ); // get the interest value given the index String inerest_name = joeUser.interestvec.get_name(int interest_inde x); // get interest name given index Identity joesData = new Identity(ProReachGID); // constructor for th e demographic portion of profile Identity joeUser.Identity; // getting identity out of the profile String firstname = joesDate.firstname; // getting first name from de mographic portion of profile String lastname = joesData.lastname; // getting last name from demog raphic portion of profile String email = joesData.email; // getting emai from demographic port ion of profile String address1 = joesData.address1; // getting address from demogra phic portion of profile String day_phome = joesData.day_phone; // getting phone from demogra phic portion of profile である。

【０５１３】１．ＣＧＩによるページメタデータへのア
クセス ProReachサーバーは、サイトのページ毎に分類情報のデ
ータベースを保持する。これは、ページメタデータ７１
６と呼ばれる。ProReachスポーク上のプロフィールにア
クセスするためhttpプロトコルを使用する上述の方法
は、ページメタデータに効率的にアクセスるため使用さ
れ得る。実行時にページに関するメタデータを取得する
この解決法は、サイトのあらゆるURLと、その分類情報
との間に対応関係が存在する場合に限り、正しく機能す
る。この対応関係、すなわち、マッピングは、ページコ
ンテンツスパイダーによって作成される。これは、サー
ビスを始める前に、サイト上の全ウェブページを予め分
類するためウェブマスターによって使用されるツールで
ある。ページメタデータサービスは、ProReach使用可能
ウェブサーバーからのページ分類情報の要求に応じるた
めこのデータを使用することができる。

【０５１４】一部のウェブサイトは、ウェブサーバーに
入る全てのページ要求に対し一つのエントリーポイント
を有する。これは、IISフィルタ、若しくは、アパッチ
(Apache)モジュールと同様であり、サーブレットでも構
わない。このようなアーキテクチャーがProReach顧客の
ウェブサイトに予め存在する場合、或いは、ProReach使
用可能ウェブサイト上に実現可能である場合、ProReach
使用可能ウェブサイトのページメタデータへのアクセス
を最適化するために有利である。ウェブ開発計者は、最
初にマッピング全体をメインメモリに読み込み、実行時
に最速な方法でページのメタデータにアクセスするた
め、メインメモリからこの構造への索引付けを行うフィ
ルタ、モジュール、若しくは、サーブレットを設計す
る。

【０５１５】Java言語の場合、ページインデックスオブ
ジェクトがハッシュオブジェクトから抽出される。ペー
ジインデックスオブジェクトは、索引付けを行うため使
用される有効なURLオブジェクト毎にカテゴリースコア
のベクトルオブジェクトを返す。これは、 PageIndex pageIndex = New LoadPageIndex(String SiteIdentifier); // c onstructor for page metadata object Vector Cat = pagIndex.get_value(Url); // retrieve the categorization for the page given the url Vector Cat = GetCatFromPageIndex(Integer Index); // retrieve the cat egorization of a page given its index のように表される。

【０５１６】次に、Javaと同じタスクを実行する統計的
手法を示す。この手法では、CGIは、単一のページに対
するカテゴリーベクトルを必要とするだけである。

【０５１７】 Vector Cat = GetCatFromUrl(URL url); // this is a static method call to get one categorization for one URL 統計的手法ではこのように表される。

【０５１８】ａ）実行時におけるマルチパートページの
動的コンテンツ分類の取り扱い 上記のサーバー側コンテンツターゲッティング及びペー
ジ分類の解決法は、サーバーから要求された各URLが予
め分類されていることを必要とする。別の実施例によれ
ば、多数のコンポーネント文書からページを構築し、合
成文書を形成するため使用できるあらゆる並べ替えを分
類できないか、或いは、分類しようとしないウェブサイ
ト開発者のための解決法が得られる。

【０５１９】この特徴を実現するため、getCategoryFro
mComponents(A, B, C, …)のような関数を定義する。こ
こで、A、B、Cは、ページのサブコンポーネントである
文書を表し、予め分類され、ページメタデータに格納さ
れている。PrReachサイトのシステム管理者は、各コン
ポーネントを分類する上記のProReach APIコールを行
うため、コンポーネントからページを編成するサイトCG
Iを設ける。これにより、実行時に上記の三つのコンポ
ーネントの分類情報から獲得された合成分類情報を決定
する能力が得られる。

【０５２０】

【発明の効果】本発明は、多数のウェブサイト、サーバ
ー及びドメインに亘ってウェブユーザの一貫した識別情
報を与え、ユーザのウェブ行動を記述するデータを監
視、捕捉し、ウェブ行動データを分類し、データをユー
ザ及びグループの時間的な関心を記述する時間依存型モ
デルに集計する、システム、方法並びに種々のソフトウ
ェア製品である。分類は、ウェブサイト毎に標準化又は
カスタム化されたカテゴリーツリーに関して行われる。
ユーザグループは、カテゴリー関心情報及び人口学的統
計のメンバーシップルールに基づいて定義される。個別
のユーザプロフィールは、ユーザグループメンバーシッ
プルールの充足度に基づいて自動的にユーザ毎に作成さ
れる。新しいデータが時間的にユーザに関して収集され
るとき、ユーザのウェブ行動から抽出されたカテゴリー
関心情報は、種々のカテゴリーに関するユーザの関心の
現在モデルを形成するため更新される。この情報は,グ
ループメンバーシップ及びユーザプロフィール情報を自
動的に更新するためにも使用される。多数のサイトに亘
るユーザの識別情報は、各ユーザを認識し、要求側ウェ
ブサーバーに大域的にユニークな識別子を与えるグロー
バルサービスによって生成され、要求側ウェブサーバー
はそのユーザの行動データを蓄積するためその識別子を
使用することができる。クライアント側のユーザ識別情
報は、グローバルサービスと通信を行わず、カテゴリー
に関する情報を処理しないウェブサーバー上のユーザ行
動データを追跡するため与えられる。ユーザプロフィー
ルは、アライアンスを形成するウェブサイトの間で共有
してもよい。ユーザ行動データは、所望の時間スケール
で関心の頑強なモデルを提供するため、ユーザ／ユーザ
グループ、分類情報、及び、時刻を含む種々の次元に沿
って集計される。

【０５２１】したがって、本発明によれば、マーケット
情報及び製品情報をユーザに有効に提示し、ウェブコン
テンツの動的なカスタマイズを行い、あるいは、ウェブ
コンテンツを販売目的に使用できるようになる。

【図面の簡単な説明】

【図１】ウェブイベントの特徴を示す図である。

【図２】ウェブイベントを集計し、ユーザプロフィール
を作成するプロセスにおけるデータフローである。

【図３】多数のProReachシステムの上位レベルシステム
アーキテクチャーの説明図である。

【図４】ProReachシステムのハブ及びスポークアーキテ
クチャーの説明図である。

【図５】ファイアウォールを用いて動作するProReachシ
ステムの一実施例の説明図である。

【図６】グローバルサービスサーバーの説明図である。

【図７】ProReachシステムの全体的な処理フローの説明
図である。

【図８】ProReachシステムの全体的な処理フローの説明
図である。

【図９】ProReachシステムの全体的な処理フローの説明
図である。

【図１０】ProReachシステムの全体的な処理フローの説
明図である。

【図１１】ProReachシステムの全体的な処理フローの説
明図である。

【図１２】ProReachシステムの全体的な処理フローの説
明図である。

【図１３】ProReachシステムのアライアンスの説明図で
ある。

【図１４】ウェブイベントレコードを蓄積するため使用
される集計キューの説明図である。

【図１５】集計サービスの特徴の説明図である。

【図１６】パーサーの処理機能の説明図である。

【図１７】カテゴリー関心曲線の概念説明図である。

【図１８】集中カテゴリーツリーの根元部分の説明図で
ある。

【図１９】標準カテゴリーツリーの更新プロセスの説明
図である。

【図２０】コンテンツ認識エンジンの動作説明図であ
る。

【図２１】ユーザプロフィールに基づくコンテンツのカ
スタマイズプロセスの説明図である。

【符号の説明】

１０２ ウェブサーバー １０６ ウェブクライアント ７０１ ウェブページアクセス ７０２ ロガー ７０４ ProReachビジターログ ７３０ プロフィールサーブレット ７３１ ページカテゴリー取得サーブレット

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ５０４ Ｇ０６Ｆ 17/60 ５０４ (72)発明者 ステファン エフ ガウアー アメリカ合衆国，カリフォルニア 94536, フリモント，キャリッジ・サークル・コモ ン 37690番 (72)発明者 ハーミッド ベン−マレック アメリカ合衆国，カリフォルニア 94086, サニーヴェール，タマラック・レーン 888番，アパートメント71

Claims (20)

【特許請求の範囲】
1. 【請求項１】 オンライン情報システムのユーザをプロ
   ファイリングするシステムであって、 ウェブコンテンツ項目に関するユーザの要求を受信し、
   選択されたウェブコンテンツ項目に対し、上記ウェブコ
   ンテンツ項目を識別するコンテンツ識別情報と、ユーザ
   が上記ウェブコンテンツ項目と相互作用した時間の長さ
   を表す時間情報と、上記ウェブコンテンツ項目に関する
   複数のカテゴリーに対するカテゴリー関連性情報とを含
   むウェブイベントを記録するウェブサーバーと、 上記ウェブイベントを受信し、上記ウェブイベントを選
   択された時間的区間、選択されたユーザ、選択されたユ
   ーザグループ及び選択されたカテゴリーに関して集計さ
   れた情報に集計する集計サービスと、 少なくとも一つのカテゴリーにおけるユーザの関心に関
   して評価され得る定義可能なメンバーシップルールを個
   々に有する複数のユーザグループを定義するユーザグル
   ープサービスと、 各ユーザに対し、ユーザがメンバーとして属するユーザ
   グループを含むユーザプロフィールを決定するプロフィ
   ールサービスとを有するシステム。
2. 【請求項２】 上記ウェブサーバーから遠隔した場所に
   設置され、上記ウェブサーバーから転送されたユーザの
   要求を受信し、上記転送された要求に応じてユーザを固
   有に識別するグローバル識別値を与えるグローバル識別
   サービスを更に有する請求項１記載のシステム。
3. 【請求項３】 ユーザによって使用されるコンピュータ
   に搭載され、ウェブサーバーからのウェブコンテンツ要
   求の選択された項目に対し、上記ウェブサーバー自体で
   は記録されないウェブイベントを記憶するクライアント
   アプリケーションと、 上記ウェブサーバーから遠隔したアップロードサービス
   とを更に有し、 上記クライアントアプリケーションによって記録される
   各ウェブイベントは、ウェブコンテンツ項目を識別する
   情報及びユーザが上記ウェブコンテンツと相互作用した
   時間の長さを表す時間情報を含み、 上記クライアントアプリケーションは上記記録されたウ
   ェブイベントを上記グローバルアップロードサービスに
   定期的にアップロードし、 上記グローバルアップロードサービスは、ユーザ毎に、
   そのユーザに関するウェブイベントを受信するために加
   入する一つ以上のウェブサーバーを示す情報を保持し、
   ユーザの上記クライアントアプリケーションから上記ウ
   ェブイベントを受信し、ユーザの上記ウェブイベントに
   加入する上記ウェブサーバーに上記ウェブイベントを提
   供する、請求項１記載のシステム。
4. 【請求項４】 上記ウェブコンテンツ項目を表すコンテ
   ンツ識別情報を上記ウェブサーバーから受信し、上記カ
   テゴリー関連性情報に応じて上記ウェブコンテンツ項目
   に関する複数のカテゴリーを与えるため接続されたコン
   テンツ認識エンジンを更に有する請求項１記載のシステ
   ム。
5. 【請求項５】 上記コンテンツ認識エンジンは各カテゴ
   リーに対しカテゴリースコアを与える、請求項４記載の
   システム。
6. 【請求項６】 上記集計サービスは、ウェブコンテンツ
   項目の上記カテゴリー関連性情報をユーザが上記ウェブ
   コンテンツと相互作用した上記時間の長さの関数として
   スケーリングするスケーリングプロセスを更に有する、
   請求項１記載のシステム。
7. 【請求項７】 上記スケーリングプロセスは、各カテゴ
   リーの上記カテゴリー関連性情報を、カテゴリースコア
   と、ユーザが上記ウェブコンテンツ項目と相互作用した
   時間の長さと、スケーリングファクタと、全てのカテゴ
   リーに対し総時間でスケーリングされたカテゴリースコ
   アとの関数である重みに変換する、請求項６記載のシス
   テム。
8. 【請求項８】 ｉが各カテゴリーを表す添え字、間隔ｉ
   はユーザがウェブコンテンツ項目と相互作用した時間の
   長さ、定数はスケーリングファクタであるとき、 各カテゴリーｉは、次式： 新スコアｉ＝（カテゴリースコアｉ）×（間隔ｉ）×定
   数 でスケーリングされたカテゴリースコアを受信し、各カ
   テゴリーは、以下の式で表される重み： 【数１】 を受信する請求項７記載のシステム。
9. 【請求項９】 上記集計サービスは、ユーザ毎に、選択
   された時間的区間に発生したウェブイベントを単一の集
   計されたデータレコードに集計する定期的集計プロセス
   を更に有する、請求項１記載のシステム。
10. 【請求項１０】 上記集計サービスは、個々のユーザ毎
    に、かつ、時間的区間に発生するユーザの複数のウェブ
    イベントの中のウェブイベント毎に、複数のウェブイベ
    ントからカテゴリー関連性情報を収集し、上記時間的区
    間に各イベントに対しカテゴリー関連性情報の統計モデ
    ルを形成し、集計された時間的区間ユーザ結果を形成す
    るプロセスを更に有する、請求項１記載のシステム。
11. 【請求項１１】 カテゴリー毎に、カテゴリー関連性情
    報の統計モデルは、上記時間的区間の平均カテゴリー重
    みと、上記時間的区間のカテゴリー重さの標準偏差とを
    含む、請求項１０記載のシステム。
12. 【請求項１２】 各カテゴリーの上記カテゴリー関連性
    情報は、カテゴリースコアと、ユーザがウェブコンテン
    ツ項目と相互作用した時間の長さと、スケーリングファ
    クタと、全カテゴリーに対し総時間でスケーリングされ
    たカテゴリースコアとの関数であるカテゴリー重さであ
    る、請求項１１記載のシステム。
13. 【請求項１３】 上記統計モデルは、時間的区間の上記
    カテゴリー関連性情報の変化を記述する傾向情報を含
    む、請求項１０記載のシステム。
14. 【請求項１４】 上記傾向情報は、上記カテゴリー関連
    性情報の変化を、増加傾向、減少傾向、一定傾向、又
    は、上記傾向の中の少なくとも二つの傾向の組み合わせ
    として記述する、請求項１３記載のシステム。
15. 【請求項１５】 上記集計サービスは、 選択された時間的区間と、選択されたカテゴリー、選択
    されたユーザ、又は、選択されたユーザグループの中の
    少なくとも一つとを受信し、上記選択された時間的区間
    に生じた集計された時間的区間のユーザ結果から、少な
    くとも選択されたカテゴリー、選択されたユーザ、又
    は、選択されたユーザグループに対する上記選択された
    統計モデルを集計する集計プロセスを更に有する、請求
    項１０記載のシステム。
16. 【請求項１６】 上記集計サービスは、 選択された時間的区間と、選択されたカテゴリーと、選
    択されたユーザとを受信し、上記選択された時間的区間
    におけるユーザの関心のユーザ・カテゴリー統計モデル
    を形成するため、上記選択された時間的区間に生じた集
    計された時間的区間のユーザ結果から、選択されたカテ
    ゴリー及び選択されたユーザに対する統計モデルを集計
    する集計プロセスを更に有する、請求項１０記載のシス
    テム。
17. 【請求項１７】 上記集計プロセスは、選択された時間
    的区間及び選択されたユーザを更に受信し、上記選択さ
    れた時間的区間に全カテゴリーに関するユーザの関心の
    ユーザ統計モデルを形成するため、上記選択された時間
    的区間における上記選択されたユーザのユーザ・カテゴ
    リー統計モデルを集計する、請求項１６記載のシステ
    ム。
18. 【請求項１８】 上記集計プロセスは、選択された時間
    的区間及び選択されたユーザグループを更に受信し、上
    記選択された時間的区間に全カテゴリーに関するユーザ
    グループの関心のユーザグループ統計モデルを形成する
    ため、上記選択された時間的区間における上記ユーザグ
    ループのメンバーである全ユーザのユーザ統計モデルを
    集計する、請求項１７記載のシステム。
19. 【請求項１９】 上記集計プロセスは、選択された時間
    的区間及び選択されたユーザグループを更に受信し、上
    記選択された時間的区間に上記選択されたカテゴリーに
    関するユーザグループの関心のユーザグループ統計モデ
    ルを形成するため、上記選択された時間的区間における
    上記ユーザグループのメンバーである全ユーザのユーザ
    ・カテゴリー統計モデルを集計する、請求項１６記載の
    システム。
20. 【請求項２０】 上記集計サービスは、 選択された時間的区間と、選択されたカテゴリーとを受
    信し、上記選択された時間的区間における上記カテゴリ
    ーに関する全ユーザの関心のカテゴリー統計モデルを形
    成するため、上記選択された時間的区間に生じた全ユー
    ザの集計された時間的区間のユーザ結果から、選択され
    たカテゴリー及び全ユーザに対する統計モデルを集計す
    る集計プロセスを更に有する、請求項１０記載のシステ
    ム。