JP2008537811A

JP2008537811A - リスティングを管理するためのシステム及び方法

Info

Publication number: JP2008537811A
Application number: JP2008501026A
Authority: JP
Inventors: アダムハイダー; サンディープカンナ; ジョセフティン
Original assignee: ヤフー！インコーポレイテッド
Priority date: 2005-03-11
Filing date: 2006-03-10
Publication date: 2008-09-25
Also published as: CN101203847A; CN101203847B

Abstract

ユーザにより検査するためにインターネットを経て種々のしばしば無関係の部署から得られるデータを捕獲し、管理しそして提示するためのコンピュータシステム及び方法。このシステムは、会社サイト、ウェブサイト、直接フィード及び他のソースのリスティングから情報データセットをスクレープするように動作できる１つ以上のスクレーピングエンジンを有するスクレーピングモジュールを備え、このスクレーピングモジュールは、スクレープされたリスティング情報データセットを受け取ってデータベースに記憶する。又、このシステムは、ソース、システムアドミニストレータ及び処理モジュールの全てのオペレーション及びそれらの間の通信を整合するマネージメントプラットホームも有する。プラットホーム内の処理モジュールは、データベースに記憶された選択されたスクレープされたデータを分析するスクレーピングマネージメントモジュールと、データベースに記憶された各データセットを検査して、所定セットのカテゴリーの１つ以上にカテゴリー分けし、そしてそのカテゴリー分けされたデータセットをデータベースへ返送するカテゴリー分けモジュールと、を備えている。
【選択図】図１Ａ

Description

本発明は、コンピュータソフトウェアに係り、より詳細には、データリスティングを管理するためのソフトウェアシステム及び方法に係る。

データのリスティングを管理し、そして不動産の仲買人、雇用者募集係、旅行代理店のような顧客に提出することが必要な会社に共通した課題は、彼等が有する情報を簡潔且つインテリジェントな仕方で伝達し、このようなデータの利用者が、求めている特定の情報を、最適な、効率的な且つ有効な仕方で、最短のサーチ時間周期内に得るようにすることである。別の課題は、データの流れを追跡し、種々のビジネスユニット間で情報転送を行いそしてリスティングデータを利用するエンティティを管理する必要性である。

１つの説明上の例は、雇用者募集の分野を含む。才能のある従業員を引き付けようとする会社の課題は、手に入るポジションに対して最良組の候補を見出すことである。求職者の課題は、申し分のない仕事を見つけることである。人的資源部門の中での１つの標準的な慣例は、各々の空いたポジションに対する仕事の説明を作成し、次いで、その説明と共にポジションを広告することである。募集係及び求職者は、次いで、これら説明を再検討し分析して、求職者と特定の仕事との間の一致を決定しなければならない。

自分の熟練度セットに基づいて適切な仕事をインターネット上でサーチしている個人にとって多数のサーチツールが利用できる。現在利用できる典型的なサーチツールは、求職者が、希望の勤務地、職種、希望の報酬レベル等の種々の基準をキーワードの形態で選択することを必要とする。同様に、雇用主は、仕事の説明に加えて、特定の仕事に対して考慮する必要のある熟練度レベル、教育、経験年数、等を与える。次いで、サーチツールは、仕事の説明のデータベースにおいて求職者のキーワードをルックアップし、求職者のキーワードを含む仕事の説明を返送するか又は表示する。しかしながら、利用できるサーチツールは、依然、雇用主及び求職者が非常に多数のいわゆるサーチ結果を各々ふるいにかけることをしばしば必要とするか、或いは設けられた基準があまりに特定過ぎるか又は狭過ぎる場合にはサーチ結果を全く返送することができない。

一般に、リスティング形態でコンパイルされたデータ、例えば、特定の地域の新しい家をインターネットでサーチする個人には多数のサーチツールが利用できる。現在利用できる典型的な不動産サーチツールは、希望の場所、家の形式、敷地の大きさ、スクールシステム、ストリート位置の好み、価格範囲、等の種々の基準をキーワードの形態で家の買手又は買手の代理店が選択することを必要とする。リスティング不動産仲買人は、通常、家の説明に加えて、絵及び他のデータ、例えば、敷地、家の平方フィート値、寝室及び風呂の数をマルチリスティングサービスで提供する。サーチツールは、次いで、家のデータベースにおいてユーザのキーワードをルックアップし、そしてユーザのキーワードを含む家を返送するか又は表示する。しかしながら、利用できるサーチツールは、依然、ユーザ、即ち不動産仲買人又は潜在的な買手又は他のユーザが、多数のサイトにおいて非常に多数のいわゆるサーチ結果を各々ふるいにかけることをしばしば必要とする。従って、リスティングデータをより有効に収集し、データを正規化し、そしてリスティングデータのユーザとプロバイダーとの間のインターフェイスを管理するサーチ管理システムを提供することが要望される。

ここに述べるシステムは、仕事の部署、履歴書リスティング、不動産リスティング、製品リスティング、等の任意の種類のリスティングデータに対してサーチツールを管理するための「プラットホーム・フォー・アドバンスト・リスティング・マネージメント(Platform for Advanced Listing Management)」ソフトウェアシステムを組み込んでいる。このシステムは、多数のマシン間に完全に分散させることができ且つ拡張可能である。ソフトウェアシステム内の以下に述べる各モジュールは、拡張可能であり、取り扱い及び処理されるべきデータの量により規定される多数のインスタンスを含むことができる。

ここに述べるシステムの実施形態は、サーチ可能なデータ構造体へコンパイルするために複数のソースからデータネットワークを経て捕獲されるリスティング情報データの捕獲及び処理を管理するコンピュータソフトウェアシステムである。このシステムは、ネットワークインターフェイスを通してシステムアドミニストレーション及びオペレーション制御を与えるアドミニストレーションポータルモジュールと、このアドミニストレーションポータルモジュールを経て与えられるインストラクションに応答して、ソースへのアクセスを制御し、リスティング情報データの検索を制御し、そしてこれらソースから受け取られたリスティング情報データを処理するように動作できる１つ以上のリスティングマネージャーモジュールとを備えている。このリスティングマネージャーモジュールの各々は、タスクマネージャーを制御して、リスティング情報データをカテゴリー分けし、そのカテゴリー分けされたリスティング情報データの部分を、所定のクオリティ基準への適合性について検査し、そしてそのカテゴリー分けされたリスティング情報データを使用のためにサーチバンクに記憶する。

各リスティングマネージャーモジュールは、１つ以上のタスクマネージャーを含み、各タスクマネージャーは、アドミニストレーションポータルモジュールにおいてサイトマネージメントモジュールにより識別されたサイトからスクレープされたデータセットを得、そしてそのスクレープされたデータセットをデータベースに記憶するために、１つ以上のスクレープエンジンのオペレーション及びそれらの間の通信を整合するスクレープマネージメントモジュールを備えている。又、リスティングマネージャーモジュールは、好ましくは、データベースに記憶された各スクレープされたデータセットを所定のクオリティ基準への適合性について分析するためにスクレープマネージメントモジュールに結合されたクオリティマネージメントモジュールと、データベースに記憶された各データセットを検討して、所定セットのカテゴリーの１つ以上へとカテゴリー分けし、そしてそのカテゴリー分けされたデータセットをデータベースへ返送するように動作できるリスティングデータカテゴリー分けモジュールと、データベースからのカテゴリー分けされたデータセットをコンパイルしてサーチバンクへ転送するためにデータベースと通信するサーチバンクシンクロナイザーとを備えている。

例示的システムの実施形態は、リスティング情報にアクセスするのに利用できる手段を使用することにより動作する。このような手段は、直接的フィード、ウェブベースフィード、ＸＭＬフィード、及びスクレープ技術を使用してウェブを探し回りインターネット、特に、ワールドワイドウェブ上の利用可能なサイトからリスティング情報を得ること、を含むが、リスティング情報は、現在知られているか又は今後知られる他のネットワークに配布され得るので、ここに述べるシステム及び機能は、分布情報環境に適用することができ、これにより、情報を手動又は自動化システムにより得ることができる。

一実施形態として、求職者及び仕事（ジョブ）の説明並びに仕事の部署について説明する。しかしながら、管理システムは、単純な職探しより相当に広い用途を有する。これは、データのリスティング又はデータレコードの他のコンパイルを管理すべきいかなる形式のデータ管理システムでも実施することができる。ここに述べるシステムは、モジュラーで、拡張可能であり、且つ単一コンピュータにおいてスタンドアローンシステムとして実施することができるか、或いはそのモジュラー機能は、異種コンピュータ、サーバー、等の間に分散させて、適当なネットワークインターフェイスを経て通信することができる。

仕事に関する情報を求めている求職者は、ここに述べるシステムの実施形態を使用するときに、再検討すべき広い分野のジョブ説明を有する。より詳細には、システムは、スクレープ技術を使用して、ジョブ説明でポピュレートされたデータベースを構築する。データベースは、他のソースからのジョブ説明、例えば、応募者を求めている会社により供給され及び／又はスクレープ以外の方法により与えられるジョブ説明を含むこともできる。このシステムは、ジョブ説明を受け取り、次いで、内部カテゴリー分け及びクオリティマネージメントプロセスを使用して、各個々のジョブ説明に含まれる情報のクオリティを最大にし、ユーザに対する有用性を最大にすると共に、ここに述べるシステムを利用したときにはユーザの全体的なジョブサーチ経験を改善する。

本開示に基づきリスティングデータセットを得、取り扱い、そしてコンパイルする方法は、インターネットを経て利用できる１つ以上のサイトにおいて１つ以上のリスティングからリスティング情報データセットを得るステップと、各スクレープされたリストに対応するデータセットをデータベースに記憶するステップと、データベースに記憶された各データセットを所定のクオリティ基準への適合性について分析するステップと、データベースに記憶された各データセットを１つ以上の所定のカテゴリーへカテゴリー分けして、そのカテゴリー分けされたデータセットをデータベースへ返送するステップと、を備えている。この方法は、更に、ＸＬＭフィード、ＲＳＳフィード、及び種々のソースからの直接的入力を介して１つ以上の顧客サイトからリスティング情報データセットを得るステップも備える。カテゴリー分けオペレーションは、好ましくは、各々の所定のカテゴリーにおける各データセットに対して信頼値を決定し、指定することを含む。この決定は、好ましくは、そしてより詳細には、各得られたデータセットのテキストを、カテゴリー分けデータベースにおける以前にカテゴリー分けされたデータセットのテキストと比較し、そして各々の得られたデータセットに対して各所定のカテゴリーにおける信頼値を決定することを含む。

この開示の方法の好ましい実施形態は、１つ以上の会社の経歴サイト又はジョブボードにおける１つ以上のジョブリスティングからジョブ説明データにアクセスし及び／又はそれをスクレープするオペレーションと、各スクレープしたジョブリスティングに対応するスクレープしたジョブ説明データをデータベースに記憶するオペレーションと、データベースに記憶された各スクレープされたジョブ説明データを所定のクオリティ基準への適合性について分析するオペレーションと、データベースに記憶された各ジョブ説明を１つ以上の所定のジョブカテゴリーにカテゴリー分けするオペレーションと、そのカテゴリー分けされたジョブ説明をデータベースへ返送するオペレーションと、そのカテゴリー分けされたジョブ説明データをデータベースからサーチバンクへ転送するオペレーションと、を備えている。

カテゴリー分けオペレーションは、好ましくは、各スクレープされたジョブ説明のテキストをカテゴリー分けデータベースにおける以前にカテゴリー分けされたジョブ説明テキストと比較するオペレーションと、各スクレープされたジョブ説明に対して各所定のカテゴリーにおける信頼値を決定するオペレーションを含む。更に好ましくは、この方法は、信頼値が手動レビューに対して所定値より低い各カテゴリー分けされスクレープされたジョブ説明にフラグを立て、そして手動レビューインターフェイスを設けて、レビューアがフラグ付けされたカテゴリー分けを検証できるようにすることを含む。

本開示の上述した特徴及び目的は、同じ要素が同じ参照番号で示された添付図面を参照した以下の詳細な説明から明らかとなろう。

本発明の実施形態による「プラットホーム・フォー・アドバンスト・リスティング・マネージメント（ＰＡＬＭ）」システム１００を使用する例示的システム１０の高レベルブロック図が、図１Ａに示されている。このシステム１０は、インターネット１１２又は他のネットワークアクセスを経て複数のサイト１１０からリスティング情報データセットを得、ＰＡＬＭシステム１００においてデータセットを処理し、その処理されたデータセットを１つ以上のデータベース１２に記憶し、次いで、ユーザ１２０によりウェブサーバークラスター１１８を通してアクセスするために１つ以上のサーチバンク１０９をポピュレートするように設計された分散型ソフトウェアシステムである。

図１Ａは、例示的システム１０をマクロビューで示している。図１Ｂは、１つのリスティングマネージャーモジュール１０４の詳細なブロック図である。図１Ｃは、ＰＡＬＭタスクマネージャー１３１の機能を示すブロック図で、各リスティングマネージャーモジュール１０４内の分散された機能を示す。

ＰＡＬＭプラットホーム１００は、コンテンツ取得、分類、クオリティ、性能及び表示のためのビジネスプロセスの自動化及びカスタマイズを容易にするリスティング・ライフサイクル・マネージメント・プラットホームシステムである。図２を参照して以下に詳細に述べる例示的アプリケーション実施形態では、ＰＡＬＭシステム１００は、雇用／ジョブサーチ及び就職コンテクストにおいて使用される。しかしながら、ＰＡＬＭ１００を組み込んだシステム１０は、非常に多数のデータセットが含まれる複雑なリスティング機構を管理するのに使用できることを理解されたい。

図１Ａに戻ると、システム１０は、一般に、リスティング管理システムの全ての潜在的管理機能をシステム１００においてモジュール形態に合体させる。従って、システム１００は、基本的に、ポータルセクション１０２、一連のリスティングマネージャー１０４、及び好ましくは、外部プロセス一体化モジュール１６０を有する。更に、システム１００は、プラットホーム「アプリケーションプログラミングインターフェイス（ＡＰＩ）」１０６、顧客自己サービスポータル１０７、及びアドミニストレーションインターフェイスポータルＡＰＩ１０８を備えている。基本的に、システム１００は、例えば、インターネット１１２を経て、外部入力サイト１１０及び他のソースにインターフェイスする。アドミニストレーション操作要員１１４は、イントラネット１１６を通してアドミニストレーションポータル１０８を経てＰＡＬＭポータル１０２にアクセスする。又、支払を済ませた顧客１１７は、ＰＡＬＭシステム１００へのアドミニストレーションアクセスが与えられた場合に、インターネット１１２を通りセルフサービスポータル１０７を経てＰＡＬＭポータル１０２へインターフェイスすることができる。

外部サイト及びソース１１０から検索されるリスティングデータは、ＰＡＬＭ１００内で処理される。ＰＡＬＭシステム１００は、次いで、１つ以上のサーチバンク１０９をポピュレートする。サーチバンク１０９内の情報は、次いで、ユーザ１２０により問合せされたときにインターネット１１２を経て表示するために、ウェブサーバークラスター１１８によりアクセスされる。

ＰＡＬＭシステム１００は、アドミニストレーションオペレータ１１４が、データリスティングを取得し、処理し、表示に利用するのを加速できるようにする。ＰＡＬＭシステム１００は、１つ以上のＰＡＬＭ処理マシン又はリスティングマネージャーモジュール１０４を合体するのが好ましい。又、このシステムは、外部通信、例えば、アドミニストレーションアクセス、制御、検査及びレポート機能、並びにアカウンティング、ファイナンス、セールス、及び顧客情報機能のために、適切なＰＡＬＭアプリケーションプログラミングインターフェイス（ＡＰＩ）１０８を通して対話する。

ＰＡＬＭポータル１０２は、ＰＡＬＭシステム１００におけるＰＡＬＭリスティングマネージャー１０４により遂行されるプロセスにアクセスし、制御し及び質問するのに使用できる多数の機能的モジュールを含む。

ユーザマネージメント、シングルサインオン(Single Sign-on)モジュール１２２は、全ての許可されたアドミニストレータに対して役割ベースのアクセス制御を与え、ユーザアクセス、許可、及び役割を管理するための「生成、レビュー、更新及び削除（ＣＲＵＤ）」使用ケースをサポートし、スタンドアローン認証、又は通し集中企業認証（シングルサインオンとしても知られている）アクティビティをサポートし、そして承認及びアドミニストレータワークフローを与える。又、このモジュール１２２は、アドミニストレータがシングルサインオンアクティビティを遂行して、ＰＡＬＭポータル１０２内で許可された機能にアクセスするのを許す。

ユーザマネージメントモジュールに対するユーザマネージメントユーザインターフェイスの例示的スクリーンショットが図１７に示されている。図１７には、ユーザアドミニストレーションスクリーン１７００が示され、これは、ＰＡＬＭシステム１００内の機能を遂行し又は編集することが管理上許可されたことを示す例示的許可ユーザ名１７０２及びそれらのアクセス許可１７０４をリストするものである。セルフサービスポータル１０７を通して入るセルフサービス顧客１１７のためのユーザインターフェイススクリーンは、相当に制限される。というのは、このような顧客は、システム１００内に制限された機能的アクセスしかもたないのが好ましいからである。

エージェント／サイトマネージメントモジュール１２４は、スクレープにより得たジョブ情報の管理を伴う特定の実施形態について以下に詳細に述べるスクレープエンジンのオペレーションを制御する。このモジュール１２４は、サイト及びサイト属性、例えば、エージェントがリモートサイトに自動的にアクセスするのに必要なユーザ名及びパスワードを管理するためのＣＲＵＤ使用ケースをサポートする。又、このモジュールは、エージェント／サイトに対する要求をイネーブルし、ディスエイブルし、承認し、そして拒絶する。これらのサイト属性は、次のものを含む。
シードＵＲＬ（１つ又は複数）
スロットル速度
頻度
スクレープの好ましい日時
表示／非表示スケジュール
「ホスト」の所与のリスト内に留まるためのエージェントインストラクション
ブラックリストサイト（スクレープされるべきでないもの）
所与のＳＬＤ、例えば、<anything>.ibm.com内に留まる
１ホスト離れるまでクロールする（例えば、www.ibm.comは、www.ibm.peopleclick.comへのリンクを有し、従って、peopleclick.comから全リストを得る）

クオリティレビューモジュール１２６は、オペレータがリスティングのクオリティをレビューし、コンテンツの発行及びエラーをレビューし、そしてリスティングを有効とするか又は無効とするのを許す手動ツールを与える。例えば、有効とするオペレーションは、テスト、ジャンク、及び違反コンテンツリスティングに対する無効化を含む。最終的に、クオリティレビューモジュール１２６は、図１３を参照して以下に述べる自動クオリティレビュータスクのための詳細な手動レビューメカニズムを与える。本質的に、クオリティレビューモジュールは、所定のクオリティ基準を満足しないものとしてフラグが立てられたデータセットをオペレータがデータベースから検索するのを許す。

リスティングライフサイクルモジュール１２８は、リスティングデータ入力及び出力のオペレーション制御においてＰＡＬＭシステムのスループットオプション及び性能の微同調及び調整を許す。例えば、このモジュールは、国(Country)、人口統計（ＤＭＡ）、バーチカル(Vertical)、クオリティ、又は他のパラメータによりリスティングを埋め戻すことができる。例えば、支払済リストに載せられた農業の仕事が僅かしかない国の領域では、ユーザ１２０に表示される結果が、このようなエリアからスクレープされたリストで補足され、即ち埋め戻されるか、或いはクオリティレベルの決定に基づいて除外されるリスティングでポピュレートされてもよい。従って、このモジュールを使用して、スクレープされた表示情報と支払済表示情報との間の混合スロットルを調整し、スクレープされたリスト及び支払済リストのパーセンテージを、カントリー、ＤＭＡ又はバーチカルのような種々のパラメータにより変更することができる。これは、支払済リスティング、スクレープされたリスティング及びプレミアムリスティングの統計学的値及び性能を比較する機能を含む。又、これは、リスティングの形式及び属性を管理するためのＣＲＵＤ使用ケースを与え、そしてコンテンツ／リスティング表示及び満了スケジュールを管理する。

レポートモジュール１３０は、他の基準の中でも、産業及び人口統計による多数のレポートタスクをサポートする。例えば、このモジュール１３０は、支払済及びスクレープされたリスティングの経歴的性能の比較を許し、リスティングのクリックの追跡、並びに支払済及びスクレープされたリスティングに対する関心の表現を容易にし、そしてトラフィックの再方向付けを追跡する。又、新たなリスティングの数、支払済及びスクレープされた情報データセットの数も追跡する。最終的に、セールス及びマーケッティングチームは、このツールを使用して、同様のこのようなリスティングの以前の経歴に基づきプレミアムリスティングをアップセールすることができる。産業レポート１６００の例示的スクリーンショットが図１６に示されている。例示的クオリティマネージャーレポート１４００が図１４に示されている。

カテゴリーレビューモジュール１３２は、適当なカテゴリーにおいて自動的に目録化又は分類できないリスティング情報を手動でレビューしそして適切にカテゴリー分けするか又は削除することのできるメカニズムを与える。カテゴリーレビューモジュール１３２は、求職及びリスティング情報管理の分野におけるＰＡＬＭ１００システムの１つの特定の実施形態を参照して以下に詳細に説明する。しかしながら、以下に述べるカテゴリーレビューの原理は、データリスティングが、所定の、動的に決定された基準に基づいて系統的に得られ、レビューされそしてカテゴリー分けされるいかなるシステムにも適用できる。開発されて、本発明の譲受人に譲渡された例示的な自動カテゴリー分け技術が、２００４年８月１７日に出願された“Automatic Product Categorization”と題する米国特許出願第１０／９２０，５８８号に説明されている。

サーチバンクシンクロナイザーモジュール１５４は、浄化されカテゴリー分けされたデータセットをデータベース１２から取り出し、それを適切にフォーマットし、次いで、サーチバンク１０９の適当な１つへコピーをポピュレートする。同様に、支払済サーチバンクシンクロナイザー１５６は、支払リスティング顧客から発信する浄化されカテゴリー分けされたデータセットを取り出し、そのデータセットをサーチのために適切にフォーマットし、そしてサーチに使用できるコピーでサーチバンク１０９をポピュレートする。このような支払済リスティングは、データセットがユーザのサーチ基準を満足し、従って、エンドユーザ１２０へ表示されるときに、ユーザ１２０に対してより高いレベルの視覚性が与えられるのが好ましい。

コンフィギュレーションジェネレータモジュール１５８は、システム１００により取り扱われるデータの量を分析し、利用可能なＰＡＬＭリスティングマネージャーモジュール１０４の各々に対するコンフィギュレーションパラメータを発生し、そして各ＰＡＬＭリスティングマネージャーモジュール１０４に割り当てられるべきＰＡＬＭタスクマネージャー／スケジューラーの数及びサイズを決定する。リスティングマネージャーモジュールの利用性、システム１００に送り込まれるデータの量、以下に更に説明するスクレープオペレーションの結果、及びアドミニストレーション入力に基づいて、アドミニストレーションオペレータは、システム１００におけるデータスループットを最適化し均等化するに必要な情報をコンフィギュレーションマネージャーモジュール１５８に通知する。

ＰＡＬＭシステム１００は、ハードウェアの利用性と、コンフィギュレーションマネージャーモジュール１５８とによって決定された１ないしｎの多数のＰＡＬＭリスティングマネージャーモジュール１０４を備えている。ＰＡＬＭリスティングマネージャーの一例が図１Ｂに示されている。ＰＡＬＭリスティングマネージャーモジュール１０４は、ＰＡＬＭシステム１００の全データベース１２におけるデータにアクセスして使用し、このデータベースは、ＰＡＬＭメタデータ記憶装置１６２、ステージングデータベース１６４、及びコックド(cooked)データベース１６６を、ＰＡＬＭシステム１００への各入力に関連したローカルデータベースと共に備えている。一般に、アドミニストレーション情報は、メタデータ記憶装置１６２へ移管される。ステージングデータベース１６４は、初期データ処理中に使用される一時的データベースである。初期の処理が完了すると、処理されたデータは、コックドデータベース１６６に記憶される。

各リスティングマネージャーモジュール１０４は、サイト１１０及び顧客のセルフサービスブロック１１７のような外部ソースからシステム１００へ送り込まれる各データセットに対して遂行されるべき一連のタスクを管理し且つスケジュールするマスタータスクスケジューラー１３１を含むのが好ましい。このマスタータスクスケジューラー１３１により制御されるタスクは、スクレープマネージャーモジュール１３４、データソースアダプタタスク１３６、データスプリッタタスク１３３、データクレンザータスク１３８、データデ・デューピング(De-duping)タスク１３９、自動カテゴリー分けエンジンタスク１４０、ルールベースのクオリティエンジンタスク１４２、及びビジネスルールタスク１４４を含むが、これらに限定されない。

スクレープマネージャーモジュール１３４は、外部サイト１１０からリスティング情報をスクレープするか又はそれを得るツールの全体的制御及び管理を行う。利用するスクレープツールには、２つの一般的形式がある。即ち、現在のＹａｈｏｏ，Ｉｎｃの子会社であるＫｅｌｋｏｏ，Ｉｎｃにより最初に開発されたＫｅｌｋｏｏのような特定サイト向けスクレープツールと、これもＹａｈｏｏ，Ｉｎｃにより開発されたＣａｆｅ／ＫｅｌｓａスクレープエンジンのようなＵＲＬクローラーエンジンである。クローラーエンジンは、シードＵＲＬでスタートし、それが遭遇する各々のリンクを通して探し回り、従って、オリジナルアドレスから遥かに移動した位置及び情報へと導くことができる。スクレープマネージャーモジュール１３４は、マスタータスクスケジューラー１３１を通して、これらスクレープツールのオペレーションをエージェント／サイトマネージメントモジュール１２４と整合し、スクレープ及びクロールされるサイトがアクティビティで圧倒されずに、そこに頻繁に訪れて、現在リスティング情報を確実に取り扱えるように保証する。

データソースアダプタタスクモジュール１３６は、データセットが種々の入力からシステム１００へ受け取られたときにローカルデータベースに記憶されている異なるデータソースからのデータを取り出し、そして異なる形式のデータセットを、全て１つの正規化された形式の正規化データセットへと変換する。例えば、データセットは、テキストファイル、ＸＭＬ、ＨＴＭＬ又はＲＳＳデータフィードとして、システム１００へ送り込むことができる。これら異なる形式のデータセットは、更なる処理の前に正規化されねばならない。データソースアダプタタスクモジュール１３６は、全てのデータセットが、共通の正規化された形式であるように保証する。

図１Ｃを参照すれば、各ＰＡＬＭマスタータスクスケジューラー１３１は、多数のタスクスレッドを幾つかが管理するところの一連のタスクをスケジュールしそして制御する。マスタータスクスケジューラー１３１は、データクレンザータスクマネージャー１３８、データデ・デューピングタスクマネージャー１３９、カテゴリー分けタスクマネージャー１４０、クオリティエンジンタスクマネージャー１４２、及びビジネスルールタスクマネージャー１４４をスケジューリングし、その各々は、タスクのｎ個のスレッドを管理することができる。

データスプリッタタスク１３３は、データセットのかたまりを、ほぼ同様の特性の異なるグループへと分割し、同様の属性をもつデータセットが同じタスクシーケンススレッドにより処理されるようにする。このタスク１３３は、異なるスレッドへのデータセットの指定を決定する。データスプリットタスクは、先ず、利用可能なＰＡＬＭマスタータスクスケジューラー１３１の数にコンフィギュレーション変化があるかどうか検出する。変化がある場合には、スクレープファーム及び他のソースからのステージデータが、新たなグループへと再ハッシュされる。変化がない場合には、新たに追加されたデータセットだけが評価される。データスプリットタスク１３３は、ジョブリスティングの場合には、仕事の肩書き、会社、及び仕事の状態のような所定フィールドのＡＳＣＩＩのハッシュに基づいてリスティングデータを分割する。このハッシュは、特に、((ascii(jobtitle)＋ascii(jobcompany)＋ascii(jobstate1))%NUM_CK_RUNNERS)であり、ここで、NUM_CK_RUNNERSは、ＰＡＬＭマスタータスクスケジューラー１３１に使用可能なスレッドの数で、コンフィギュレーションマネージャー１５８により決定される。データスプリットタスクの機能は、常に同じデータセットを同じ「バケット」へと分割する均一ハッシュ関数を使用して、同じデータレコードが好ましくは同じスレッドにより処理されるようにすることである。

データクレンザータスクマネージャー１３８は、スレッド１６１における各データセット又はレコードの検査、及びフォーマット化の除去を制御し、各スクレープされたリスティングにおけるリスティング情報が同じフォーマット及びコンテンツ構造を有するようにする。特に、このタスク１３８は、データフィールドからの全ＨＴＭＬタグの剥離、名前の確認を制御し、そしてＵＳ国内のリスティングに対する２文字状態コードのような適当なコードをアドレス及び位置データに入れる。国際リスティングの場合には、適当な国際位置の省略形（州／区域）を入れる。又、このタスクモジュール１３８における各スレッド１６１は、各ＵＲＬのようなデータリスティングにおけるこのようなフィールドのオペレーションチェックを遂行し、それが“http:”又は“https”のいずれかでスタートし、不敬なワードを剥離し、日付フィールドを確認し、各フィールドにおける無効キャラクタ、例えば、都市フィールドにおける全ての数字をチェックするように保証する。最終的に、各スレッド１６１は、例えば、センテンスの最初の文字が大文字であり、且つ各々の新たなセンテンスをスタートするために２つのスペースがあることを保証する正しい基本的句読点オペレーションを与えるのが好ましい。

データデ・デューピングタスクマネージャー１３９は、データクレンザーマネージャーモジュール１３８からデータレコード又はリスティングデータセットを取り上げて、そのデータセットを既存のデータベース１６４及び１６６のレコードと比較するマルチスレッド型タスク１６３を管理し且つスケジューリングして、ＰＡＬＭシステム１００が、既に受け取られ、検査されそして記憶されたデータを複製することがないよう保証する。既存のデータベースコンテンツと比較されたときに複製としてフラグの立てられたデータセットは、データベース１２から除去される。従って、「複製解除(de-duplicating)」又は「デ・デューピング(de-duping)」という語が使用される。

カテゴリー分けタスクマネージャーモジュール１４０は、特定のリスティングデータセットが属するカテゴリーを決定するためのオペレーションを自動的に遂行するスレッド１６５を管理する。例えば、アラバマ州モビールの販売リスティングのための家は、その場所、大きさ、形態、単一家族向けか複数家族向けか、等に基づいてカテゴリー分けされる。ジョブデータセットは、分野、時間、教育、場所、等によりカテゴリー分けすることができる。従って、カテゴリー分けエンジンタスクマネージャー１４０は、当該リスティングデータセットを所定のカテゴリーに基づいて自動的にカテゴリー分けするのに必要なオペレーションを制御し管理する。このタスクマネージャー１４０は、マルチスレッド型であり、カテゴリー決定のｎ個までのインスタンス１６５を同時に整合する。このカテゴリー分けタスクは、決定されたカテゴリーに対して信頼レベルの決定も含むのが好ましい。例示的なカテゴリー分け技術が、２００４年８月１７日に出願された米国特許出願第１０／９２０，５８８号、及びそこに述べられた関連出願に開示されており、これらは、全て、Ｙａｈｏｏ，Ｉｎｃに譲渡されたものである。

ルールベースのクオリティエンジンタスクマネージャー１４２は、データセットがある基準を満足し且つある最小レベルの詳細情報を含むよう確保するために、各リスティングデータセットを子細に検査するところの一連のルールを与える。このような基準は、例えば、家の不動産リスティングのためのストリートアドレス、又はジョブリスティングのための仕事の肩書き、又はこのような実施に対する都市の場所を含むことができる。このモジュール１４２の１つの実施形態は、システム１００の求職実施形態を参照して以下に詳細に説明する。クオリティエンジンタスクマネージャー１４２は、２つの基本的なスレッドシーケンス、即ちＵＲＬリンクチェックスレッド１６７、及びこれに続くデータ確認スレッド１６９をスケジューリングする。これらのチェック１６７及び１６９は、ＵＲＬが実際に現在有効なＵＲＬであることを検証し、そしてデータベースレコードワードと、ＵＲＬからダウンロードされたウェブページとの間のワードマッチングルーチンも遂行して、リスティング説明がマッチするよう保証する。データ確認スレッド１６９は、データセットからワードをランダムに選択し、それらを、ダウンロードされたウェブページに対してマッチさせ、そしてそれらに５個より多くのキャラクタを有するワードを選択するのが好ましい。データセットが、ダウンロードされたウェブページにマッチしない場合には、エラーフラグがセットされる。このタスクのより詳細な例は、図１３を参照し、ＰＡＬＭシステム１００の求職実施形態に関して以下に説明する。

ビジネスルールタスクモジュール１４４は、たとえデータが以前にクロールされていても、リスティングを表示するか又は表示しないための判別ルールを適用し、リスティングをフィルタリングし、産業の場所に基づいて部分的リスティングを示し、又はサイトのデータを表示に対して完全に阻止するための能力をビジネスに与える。例えば、ボストンエリアでの求職用途では、所定時間周期中にヘルス産業に対するスクレープ又はクロールされたデータの１０％の表示しか選択しないことがある。新しいリスティングが到着すると、ビジネスルールエンジンは、全体的なデータセットを通して進み、そして予め定義されたルールに基づいて全てのリスティングを取り除くか又はマークする。

ＰＡＬＭシステム１００の前記説明から、このシステムは、拡張可能で、マルチスレッド型で、且つ分散的であり、複数のモジュール１０４のようなモジュールの機能を、ここに述べる機能を遂行するように適当に作動的に一緒に接続されたコンピューティングマシンの異なる組み合せで実行できることが明らかであろう。

本発明の実施形態に基づいて図１Ａ−１Ｃに示されたＰＡＬＭシステム１００の一実施形態を組み込んだ求職システム２００の全体的アーキテクチャーが図２に示されている。このシステム２００は、３つのセクション、即ち外部入力セクション２０１、データ取り扱いセクション２０３、及び出力取り扱いセクション２０５を有すると考えることができる。基本的に、データ取り扱いセクションは、ジョブデータのための外部入力セクション２０１に到達し、データを処理し、データを編成しそしてその有効性を確認しジョブデータをカテゴリー分けし、そしてデータを出力セクションへ与え、出力セクションは、最終的に求職者２０７によりインターネット１１２を経てアクセスされる。

外部入力セクション２０１は、企業及び会社の経歴サイト及び多数の他のジョブボード２０２のようなソースからデータ取り扱いセクションによりアクセスすることのできる仕事の部署を含む。これらの企業経歴サイト及びジョブボード２０２は、現在、数千の会社の経歴サイトより成る。又、雇用主／募集係２０４は、インターネット１１２を経て雇用主／募集係インターフェイスアプリケーション２０６へジョブリスティング情報を直接与えることができる。このような応募係インターフェイスアプリケーションは、ジョブ情報を入力すると共に個々のリスティングを適切なフォーマットでデータ取り扱いセクション２０３へ提示するためのユーザインターフェイススクリーンを雇用主／募集係に与える。

システムゲートウェイ／フィード２０８は、顧客サイト２１０と通信し、そして顧客サイト２１０がこの目的のために以前に記憶したジョブ情報を予め定義されたフォーマットでプルする。ゲートウェイ／フィード２０８は、顧客サイトが情報を提示するのを許し、そしてシステム２００のデータ取り扱いセクション２０３にシステムフィードを与える。或いは、顧客サイトは、ウェブサービス２１２を通してジョブ情報を利用できるようにする。ここで、システム２００は、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）を経て顧客サイト２１０にアクセスし、ジョブリスティング情報を得る。顧客サイトからジョブ情報を得る別の経路は、ＲＳＳ２１４を通るものである。“Really simple Syndication”の省略形であるＲＳＳは、ニュース、ブログ、製品データ、及び多数の他の形式のウェブコンテンツを共有するように設計された軽量のＸＭＬフォーマットである。ＲＳＳは、ＢＢＣ、Ｙａｈｏｏ、ＣＮＥＴ、ＣＮＮ、Ｄｉｓｎｅｙ、Ｆｏｒｂｅｓ、ＭｏｔｌｅｙＦｏｏｌ、Ｗｉｒｅｄ、ＲｅｄＨｅｒｒｉｎｇ、及び更に多数を含むサイト間でコンテンツを共有する人気のある手段へ進化した。又、ジョブ情報は、顧客サイト２１０から直接的ＸＭＬフィード２１６を通りインターネット１１２を経て得ることもできる。

又、スクレープエンジンファーム２１８も、データ取り扱いセクション２０３に入力を与える。このスクレープエンジンファーム２１８は、設計選択上の事柄として開発されるが、好ましくは、インターネット１１２のようなグローバルな電子ネットワークを経てサーチするためにこの好ましい実施形態に特に向けられる異なるスクレープ技術及び方法を通常使用する多数のスクレープエンジン２２０を有し、各エンジン２２０は、特定形式のスクレープタスク、又は特定形式又はセットの企業サイトに対して最適化される。例えば、現在は、Ｙａｈｏｏ，Ｉｎｃの子会社であるヨーロッパのＫｅｌｋｏｏ，Ｉｎｃにより開発されたＫｅｌｋｏｏスクレープエンジンは、所定の既知の企業サイト又はリスティングサイトを完全に探し回るように最適化される。Ｋｅｌｋｏｏのスクレープエンジンは、サイト内の内部リンクを特定の内部位置までたどり、ジョブ情報データセットを抽出するように最適化される。しかしながら、外部リンクはたどらない。Ｙａｈｏｏ，Ｉｎｃにより開発され、そして２００５年２月２２に出願された“Techniques for Crawling Dynamic Web Content”と題する米国特許出願第１１／０６４，２７８号に開示されたＣａｆｅ／Ｋｅｌｓａスクレープエンジンファームは、シードＵＲＬを系統的に検査し、サイト内の各リンクをたどり、そしてそのＵＲＬに設けられる各内部及び外部リンクと、その「クロール」の際に見出すリンクとをたどるように最適化される。

入力セクション２０１は、これらの種々のソースからデータをフィードし、そしてバス２２４を経て全データベース１２の一部分であるステージングデータベース２２２へフィードする。ステージングデータベース２２２は、次いで、データ取り扱いセクション２０３において、プラットホーム・フォー・アドバンスト・リスティング・マネージメント（ＰＡＬＭ）システム１００によりアクセスされる。又、ＰＡＬＭシステム１００は、このマネージメントシステム１００に入力を与える多数のモジュールを有する。例えば、顧客関係マネージャー（ＣＲＭ）モジュール２２６及び他の外部アプリケーションモジュール２２８は、情報を与えると共に、ＰＡＬＭシステム１００内で独特に利用できるレポート及び他の情報を抽出することができる。又、プロジェクトマネージメント、オペレーション、セールス、及びマーケッティング要員２３０も、以下に詳細に述べるように、イントラネット２３２を経てＰＡＬＭシステム１００へ入力を与え、そしてそれを制御することができる。

データ出力セクション２０５は、ジョブサーチウェブサーバー／クライアントクラスター２４８と、このクラスター２４８に対する多数のデータソースモジュールとを備えている。スクレープサーチバンク２４６は、これらの１つである。広告システムのプレミアムリスティングモジュール２５０、支払済サーチバンク２５２、オーバーチュア(overture)システムコンテンツマッチングモジュール２５４、及びリンクビルダーモジュール２５６は、ジョブサーチウェブサーバー／クライアントクラスター２４８により問合せされる。

広告システムのプレミアムリスティングモジュール２５０は、クラスター２４８を編成し、そしてそれに、システム２００のホストとの支払済プレミアムアカウントをもつ特定の雇用主又は募集係からの広告を与える。これらのプレミアム広告は、求職者に、特殊なボックス、バナー、ハイライト状態で表示されるか、さもなければ、特定のサーチ要求に応答して求職者２０７に提示される他のリスティングからセットオフされて表示される。

支払済サーチバンクモジュール２５２は、システム２００のホストへ料金を支払う際に雇用主メンバー２６０がアクセスするところの特殊なサーチバンクである。この支払済サーチバンクモジュール２５２は、料金を支払う仕事応募係雇用主又は会社からのジョブリスティングを識別し、記憶し、そして追跡して、それらの配属ジョブリスティングが、求職者２０７に提示されるユーザインターフェイスにおいてより高い又は強調された配置を受け入れるよう保証する。従って、支払済の部署は、メンバー会社によりメンバーデスクトップ２６２又はゲートウェイ２６４を経てサーチバンク２５２へ直接的に与えられる。支払済サーチバンク２５２は、ユーザにより与えられる幾つかの望ましいサーチカテゴリーに関連してリスティングをプッシュするために、ここに述べるシステム２００のオペレータにプレミアムを支払ったジョブリスティングエンティティにより与えられる情報を含み、従って、このようなサーチ結果は、プレミアム支払と引き換えにユーザインターフェイス４０６を経てユーザに対して目立つ位置に与えられる。

オーバーチュアシステムのコンテンツマッチングモジュール２５４は、求職者のサーチ基準にマッチする広告がデータベースにあるかどうか問合せする。これらの広告は、システム２００のホスト２００により使用するために支払済データベースに予め記憶されるか又はリンクされる。このような広告は、図４に示すサーチ結果ユーザインターフェイススクリーンショットに示されている。

リンクビルダーモジュール２５６は、求職者２０７により与えられたサーチ用語にマッチするジョブの他のソースへリンクするためのリンケージクッキー及びアドレスを与える。あるインスタンスでは、ジョブ説明を見るために、求職者は、特定のウェブサイトに通されてリスティングを見なければならない。このような環境では、サイトは、ジョブ情報が見られる前に、クッキー等の特定のセキュリティエレメントを必要とする。従って、リンクビルダーモジュール２５６は、サイトが特定のクッキー又は他の識別子を必要とする場合に、必要なインターフェイス特性を与える。リンクビルダーモジュール２５６は、サイトにより要求される必要な情報、例えば、ジョブリスティングにアクセスするためのセッションクッキーを含むＵＲＬを構築するプロセスを管理する。リンクビルダーモジュール２５６の結果は、自分のサーチ要求からの関心のある特定のジョブに加えて、求職者２０７に与えられる。

図４を続けて参照すれば、ウェブサーバークラスター２４８は、ここに述べるシステム２００を使用したい求職者２０７へのゲートウェイインターフェイスとして働く。求職者２０７は、システム２００におけるサーチ要求を開始するために、図３に示すものと同様のユーザインターフェイスが提示されるのが好ましい。クラスター２４８は、次いで、システムサーチバンク２５２、２５４、２４６及び２５０から情報を得るようにサーチし、そしてそれを、図４に例示する結果インターフェイスのように、問合せしている求職者２０７に、使い易く且つ効率的な仕方で、提示する。

図３に示すユーザインターフェイス３００にサーチ要求３０２を入力する求職者２０７は、サーバークラスター２４８とインターフェイスし、これは、次いで、図４に示すように、集計結果を求職者２０７に提示する。従って、ユーザは、以下に述べるように、広告システムのプレミアムリスティングモジュール２５０、ジョブサーチバンク２５２、バンク２５４、２５０、２４６により識別されたリスティング、及びバンク２５６からのクロールされたジョブが与えられることで、プレミアムリスティングを見る。

図４を参照すれば、ユーザ問合せ結果インターフェイス４００の例示的スクリーンショットが示されている。このユーザインターフェイス４００は、求職者に、その問合せにマッチする全てのジョブ情報をレビューする機会を与える。更に、求職者が、異なる又はより洗練された問合せを提出するのを許す。表示部分４０２は、特定のサーチ基準にマッチする全てのジョブ情報、例えば、図４では、イリノイ州のソフトウェア開発者の勤め口、を再検討する機会をユーザに与える。求職者は、ソフトウェア開発者の勤め口に対するサーチ結果として得られる全てのジョブ情報を再検討してもよいし、或いは過去の２４時間、７日又は他の予め選択された時間周期に更新された説明だけを再検討してもよい。又、求職者は、自分のサーチを、経験レベル、場所、或いはジョブ説明内の他の特性又はサブカテゴリーにより構成してもよい。

又、インターフェイス４００は、多数の好ましい結果グループにより分離された結果セグメントも表示する。従って、システム２００は、広告システムプレミアムリスティングモジュール２５０から得られたプレミアムリスティング４０４のセグメントを提示し、これは、ビジネスを追求している雇用主がプレミアムを支払って、それらのジョブリスティングが、求職者２０７に提示されるユーザインターフェイス４００の結果部分においてより目立つ位置を得るための機会を与えることにより、システム２００のホストがシステム２００を収益向上ツールとして使用するのを許す。

又、ユーザインターフェイス４００は、支払済ジョブサーチバンク２５２からのサーチの結果を提示する第２のサブセクション４０６も含むのが好ましい。又、第３のサブセクション４０８は、スクレープされたサーチバンク２４６をサーチする直接的な結果である非プレミアムアルゴリズムサーチ結果を提示する。第４のセクション４１０は、オーバーチュアシステムコンテンツマッチングモジュール２５４から、より一般的な支払済リンクを与える。最終的に、広告システムプレミアムリスティングモジュール２５０のサーチから多数の広告４０９を表示することができる。

スクレーピングは、図１５に示す次のコンポーネントを含む。即ち、Ｋｅｌｋｏｏスニファー２２０、ジョブに対してウェブサイト２０２をスクレープするための一連のエージェント１５０２、好ましくは、スクレープされたジョブ及びエージェントログを記憶するためのステージングデータベース２２２のようなＭｙＳＱＬデータベース、及びエージェント１５０２を起動するためにＰＡＬＭシステム１００のエージェント／サイトマネージメントモジュール１２４により管理されるランナースクリプト１５０４。

どのようにデータが好ましくはシステム２００のスクレーピングファーム２２０を通して流れるかの概要を以下に述べる。スクレーピングサイクルの始めに、全データベース１２の別の部分であるコックドデータベース２３６における“job_current”テーブル６２６が裁断され、そのコンテンツがアーカイブテーブル（図示せず）へコピーされる。スクレープされたジョブのアーカイブは、限定された周期（例えば、７日）中にのみ記憶されるのが好ましい。

スクレーピングエンジン２２０のＫｅｌｋｏｏ「スニファー(Sniffer)」は、アダプタ（ａ．ｋ．ａ．エージェント１５０２）を起動するのに使用されるＪａｖａ（Ｒ）プログラムである。スクレーピングエンジン２２０は、エージェント１５０２を経てジョブボード２０２をスクレープする。各エージェント１５０２は、３つのテキストファイル、即ちａｇｅｎｔ．ｉｎｆｏ、ａｇｅｎｔ．ｐｒｏｐｓ、及びａｇｅｎｔ．ｓｑｌ、より成るのが好ましい。単一のエージェントを使用して、単一のウェブサイトをスクレープする。エージェントファイルは、エージェント特有のディレクトリに記憶される。次いで、エージェント１５０２は、スクレープされたジョブを「ジョブ」テーブル１５０６にダンプし（多数のジョブテーブルがあることに注意されたい）、その２つが図１５に示されている。ランナー(Runner)１５０４は、ジョブレコードを「ジョブ」テーブル１５０６から“job_current”テーブル６２６へコピーする。ランナー１５０４の下流のコンポーネント、例えば、クオリティマネージャーモジュール１４２、及びカテゴリー分けモジュール１３２、１４０は、ジョブレコードのコピーを受け取り、そして好ましくはコックドデータベース２３６の一部分である“job_current”テーブル６２６内のレコードについてクオリティマネージメント及びカテゴリー分けオペレーションを遂行する。その結果は、次いで、図２に示すコックドデータベース２３６へ通される。

Ｋｅｌｋｏｏスニファーサーチエンジン２２０は、エージェント１５０２をバーチャルＳＱＬテーブルとして考える。バーチャルテーブルのスキーマは、エージェントのｓｑｌファイルにおいて定義される。ｉｎｆｏファイルは、スニファーサーチエンジン２２０が実行するバーチャルテーブルに対するＳＥＬＥＣＴステートメントである。プロップファイルは、バーチャルテーブルを埋めるのに使用されるスクレーピングロジックを含む。このスクレーピングロジックは、種々のフィルタにより実行される一連のステップである。フィルタは、アダプタデベロープメントキット（ＡＤＫ）を作り上げるＪａｖａ（Ｒ）クラスである。フィルタは、順次に実行され、そして変数を読み取り共通のコンテクストに書き込むことができる。ｈｔｍｌページにおいてストリング又はパターンを見出してセーブし、コンテクストの変数を操作し、再発生パターンをループにして、ループ内で他のフィルタを実行し、ＵＲＬで識別されたページへ進んでそのコンテンツを検索し、等々を行なうためのフィルタが存在する。

エージェント１５０２の出力は、各々のスクレープされたジョブに対するＳＱＬＩＮＳＥＲＴステートメントを含むテキストファイルである。スニファーサーチエンジン２２０は、このデータファイルを使用して、スクレープされたジョブレコードを、「ジョブ」と称されるＭｙＳＱＬテーブル（実際のテーブル名は、コンフィギュレーションパラメータである）１５０６へロードする。スニファー２２０は、種々のコマンドラインパラメータと、コマンドライン上に通される任意の数のプロパティファイルを経て、構成される。スニファーサーチエンジン２２０の最も重要なコンフィギュレーションパラメータは、ＭｙＳＱＬデータベースの名前、データベースユーザ及びパスワード、スクレープされたレコードをダンプするためのテーブルの名前、エージェント要求ファイルへの経路、及びエージェント１５０２を含むディレクトリである。

スニファーサーチエンジン２２０は、一度に１つのエージェント１５０２をロードして実行する単一スレッド型であるのが好ましい。エージェント１５０２を実行した後、スニファーサーチエンジン２２０は、「レポート」テーブル１５０８へレコードを次の情報と共に挿入する。即ち、実行の時間、エージェント１５０２の名前及び経路、スクレープされたレコード（ジョブ）の数、及び考えられるエラー。

エージェントファイルは、ＣＶＳレポジトリーに記憶される。ＱＡを通したエージェント１５０２のバージョンは、特殊なＣＶＳタグでタグ付けされる。この構成は、エージェント開発者、テスト装置、及び生産システムが同じツリーに対して機能して、生産中の未テストエージェントの実行を回避できるようにする。

エージェントランナー１５０４は、システム２００に対して開発されたパール(Perl)スクリプトである。ランナー１５０４は、ローカルファイルシステムにおいてエージェントファイルを利用できることを要求する。ランナー１５０４がスタートする前に、ローカルＣＶＳツリーは、実行しなければならない全てのエージェントファイルをダウンロードするために生産タグに対して同期される。ランナー１５０４は、次のステップを実行する。
１．そのコンフィギュレーションファイルを読み取る。これは、実行すべきエージェント１５０２のリストを含む。各ランナーは、コンフィギュレーションの一部分として通されるｉｄを有する。
２．スニファー２２０のためのコンフィギュレーションファイルを、それ自身のコンフィギュレーションに基づいて発生する。
３．実行されるべきエージェント１５０２に属する“job_current”テーブル６２６から全てのレコードを削除する（好ましくは、“job_current”テーブル６２６は毎日裁断されるので、これは、ほとんどの場合、不必要である）。
４．エージェント１５０２を実行するスニファーサーチエンジン２２０を起動する。
５．ジョブ説明をｈｔｍｌタグから剥離するようにジョブタグ内の各レコードを処理するのが好ましい。各ランナーは、それ「自身」のジョブテーブル１５０６を有し、ランナーｉｄ（例えば、“job 1”）を使用してその名前が生成される。
６．ジョブテーブル１５０６から“job_current”テーブル６２６へ全てのレコードをダンプする。ジョブレコードは、ランナーのｉｄを含み、これは、下流のコンポーネントが、特定のランナー１５０４から到来するレコードを容易に識別する上で助けとなる。
７．実行エージェントの概要をそのログファイルに書き込む。この情報は、ジョブテーブル１５０６、“job_current”テーブル６２６及びレポートテーブル１５０８への問合せを経て検索される。
８．最終的に、ｓｓｈを経てクオリティマネージャーマネージメントモジュール１２４を呼び出し、個別のマシンにおいて実行することができる。ランナー１５０４のｉｄは、データクレンザータスク１３８、データデ・デューピングタスク１３９、クオリティマネージャータスク１４２、カテゴリー分けタスク１４０の各々に通され、従って、各タスクは、マスタータスクスケジューラー１３１により実行すべくコールされたときに“job_current”テーブル６２６からどのレコードを処理すべきかを知る。

ＰＡＬＭシステム１００は、入力セクション２０１から出力セクション２０５へのスループットを制御し、管理する。好ましくは、１日に一度、又は他の所定のインターバルに一度、１つ以上のＰＡＬＭリスティングマネージャー１０４は、ステージングデータベース２２２のデータにアクセスし、そのデータを処理し、そして出力セクション２０５のサーチバンク２４６及び２５２を更新するように命令される。膨大な量のデータを処理しなければならないので、ＰＡＬＭシステム１００は、通常、ステージングデータベース２２２からのデータで相対的に独立して各々動作する多数のＰＡＬＭリスティングマネージャー１０４を含む。

システム１００は、多数のＰＡＬＭリスティングマネージャーモジュール１０４を組み込むことができ、それらは、全て、本質的に独立して並列に動作し、その各々は、最初にデータ分割タスクにおいてその特定マネージャーのランナー番号に指定されるデータに対して作用する。ＰＡＬＭリスティングマネージャー１０４は、コンフィギュレーションジェネレータ１５８からコンフィギュレーション情報を受け取る。コンフィギュレーションジェネレータ１５８は、システム２００の利用可能なＰＡＬＭリスティングマネージャー１０４にランナー番号を指定する。

各ＰＡＬＭリスティングマネージャー１０４は、好ましくは全分散型データベース１２の一部分であるＰＡＬＭメタデータデータベース２３８からメタデータを受け取りそしてそこにメタデータを記憶する。このデータベース１２は、図１８に示すように共有されるのが好ましい。例えば、マシン１のＰＡＬＭリスティングマネージャー１０４は、例えば、ステージングデータベース２２２から入力１８０２を取り出し、タスクＡを実行し、そしてタスク出力１８０４を発生する。このタスクＡの出力１８０４は、例えば、タスクＢに入力される（１８０４）。同時に、タスクＡの出力１８０４は、ステージングデータベース２２２に一時的に記憶される。タスクＢの出力１８０８も、ステージングデータベース２２２又はメタデータデータベース２３８に適宜一時的に記憶され、他のＰＡＬＭリスティングマネージャー１０４の１つ、この例では、マシン２により使用される。マシン２は、その必要な入力１８０８を、それがステージングデータベース２２２において得られない場合は、メタデータデータベース２３８から必要に応じてプルし、タスクＣを遂行する。タスクＣの出力１８１２も、同様に、別のリスティングマネージャーのタスクに使用するために、データベース２２２又は２３８に記憶して戻すことができる。一時的な映像データに対してこの機構を使用することにより、多数の動作中のＰＡＬＭリスティングマネージャー１０４は、それらのタスクを完了するために、他のリスティングマネージャー１０４に対して必ずしもインラインで待機する必要はない。このように、全体的な処理スループットが向上される。

システム２００におけるＰＡＬＭシステム１００の各ＰＡＬＭリスティングマネージャー１０４は、インターネット１１２を通してアクセスされる種々のサイトからスクレープされるデータ、並びに顧客サイト２１０及び他のソースからＲＳＳフィード２１４、ＸＭＬフィード２１６、ウェブサービスＳＯＡＰ２１２、及び／又は雇用主／募集係アプリケーション２０６を経て得られるジョブ情報データセットに対して動作するようにタスクのスタックを制御するマスタータスクスケジューラー１３１を有する。雇用リスティング及びジョブサーチアプリケーションに関して図２に示す実施形態では、これらリスティングデータセットの各々は、どこから得られようと、最初にステージングデータベース２２２に記憶される。ＰＡＬＭシステム１００は、ステージングデータベース２２２のデータに対して動作し、それを、中間ＰＡＬＭメタデータ記憶装置２３８を使用して、コック(cooked)、浄化(cleansed)及びカテゴリー分けデータベース２３６へ通過させる。ジョブリスティングデータセットがコックされると、データセットは、出力セクション２０５へ通され、特に、サーチバンク２４６及び２５２をポピュレートする。

ＰＡＬＭマスタータスクスケジューラー１３１により各々制御されるｎ個のＰＡＬＭリスティングマネージャー１０４の各々における基本的プロセスフローオペレーションが図５に示されている。オペレーションフローは、初期化オペレーション５０２で始まり、ここで、ＰＡＬＭシステム１００は、所定のスケジュールに基づいてその処理サイクルを開始する。第１に、ＰＡＬＭシステム１００は、どのリスティングマネージャー１０４がどんなタスクを取り扱うか決定する。

特定のＰＡＬＭリスティングマネージャー１０４が、データセットのかたまり又はバッチを取り扱うようにコンフィギュレーションマネージャー１５８により指定されると、ＰＡＬＭマスタータスクスケジューラー１３１は、オペレーション５０４ないし５１０を制御する。次いで、各個々のタスクマネージャー１３８、１３９、１４０、１４２及び１４４は、オペレーション５１２−５２８を参照して以下に述べるように、ステージングデータベース２２２において並列スレッドでデータセットを処理する。

制御がオペレーション５０４へ移行し、ステージングデータベース２２２内のデータセットを、利用可能なＰＡＬＭタスクスレッドへ割り当てることを開始する。これは、データスプリッタータスクモジュール１３３において管理され遂行されるデータスプリットタスクである。このデータスプリットタスク１３３の出力データは、オペレーション５０８において、指定の対応ＰＡＬＭタスクスレッドのランナー番号と共に、ステージングデータベースへ返送される。

データスプリットタスク１３３は、先ず、コンフィギュレーションジェネレータ１５８により決定される利用可能なＰＡＬＭタスクスレッド１−ｎの数にコンフィギュレーション変化があるかどうか検出する。変化がある場合には、スクレーピングファーム及び他のソースからのステージデータが新たなグループへと再ハッシュされる。変化がない場合には、新たに追加されるデータセットのみが評価される。データスプリットタスクは、リスティングデータセットを、仕事の肩書き、会社、及び仕事の状態フィールドのＡＳＣＩＩのハッシュに基づいて、リスティングデータセットを分割する。このハッシュは、特に、((ascii(jobtitle)＋ascii(jobcompany)＋ascii(jobstate1))%NUM_CK_RUNNERS)であり、ここで、NUM_CK_RUNNERSは、コンフィギュレーションマネージャー１５８により決定される使用可能なＰＡＬＭスレッドの数である。データスプリットタスクの機能は、常に同じジョブを同じ「バケット」へと分割する均一ハッシュ関数を使用して、例えば、ジョブリスティングのような同じデータレコードが同じスレッドにより処理されるようにすることである。

次いで、制御は、問合せオペレーション５１０へ移行する。この問合せオペレーション５１０では、ＰＡＬＭタスクスレッドが指定されていない別のエントリーがステージングデータベース２２２にあるかどうかの問合せがなされる。その答えがイエスの場合には、制御がオペレーション５０４へ戻り、次のリスティングデータセットがステージングデータベースから検索されて、検査される。その答えがノーの場合には、分割されるべきデータセットがそれ以上なく、制御は、オペレーション５１２へ移行する。

オペレーション５１２ないし５２８は、特定のＰＡＬＭリスティングマネージャー１０４において指定されたスレッドに対応するランナーＩＤを有する各データセットに対し、各ＰＡＬＭタスクマネージャーにより、好ましくは並列に、遂行されるのが好ましい。

オペレーション５１２において、マスタータスクスケジューラー１３１は、第１のステージングデータベースエントリーをそのランナーＩＤ番号でプルし、そしてデータクレンザータスクマネージャー１３８により管理されるデータ浄化タスクを遂行する。データクレンザータスクマネージャー１３８のスレッドは、ステージングデータベース２２２から完全なデータレコードをプルし、そして全てのフォーマットを除去して、各ジョブリスティングデータセットが同じフォーマット及びコンテンツ構造であるようにする。より詳細には、タスクは、データフィールドから全てのＨＴＭＬタグを剥離し、米国の州名を確認し、そして２文字の州コードを入れる。国際リスティングの場合、適当な国際的場所の省略形（州／区域）を入れる。浄化タスクスレッドは、ＵＲＬをチェックし、それが“http:”又は“https”のいずれかでスタートすることを保証する。次いで、このタスクは、全ての不敬なワードを剥離し、日付フィールドを確認し、各フィールドにおける無効キャラクタ、例えば、都市フィールドにおける全ての数字をチェックする。又、このタスクは、フィールドにおける最大ワード数もチェックする。例えば、都市名は、１５ワードをもつことができない。又、国名を３文字の国コードフォーマットで入れ、仕事の肩書き、説明等のフィールドにおけるスペルを修正する。最終的に、例えば、センテンスの最初の文字が大文字であり、各々の新たなセンテンスをスタートするために２つのスペースがあるといった正しい基本的な句読法を与える。

データクレンザータスクスレッドが、あるスレッドにおけるジョブリスティングデータセットに対して遂行されると、オペレーション５１４において、ステージングデータベース２２２へリスティングが返送される。次いで、制御は、問合せオペレーション５１６へ移行する。問合せオペレーション５１６では、ＰＡＬＭマスタータスクスケジューラー１３１のランナーＩＤに伴う別のデータセットがあるかどうかの質問がなされる。もしそうであれば、制御は、オペレーション５１２へ戻り、次のデータセットが検索されて浄化される。もしそうでなければ、制御はオペレーション５１８へ移行する。

オペレーション５１８において、データセットがステージングデータベース２２２から検索され、そしてデ・デューピングモジュール１３９におけるリスティングレベルのデ・デューピングタスク１２００へ送信される。リスティングレベルのデ・デューピングタスクが図１２に示されている。次のステージングテーブル、コックドデータテーブル、及びデ・デュープドテーブルに、テーブルエントリーのセットを例示する。

ステージングテーブル１

コックドテーブル２

コックドテーブル３

第１に、デ・デューピングタスク１２００は、コックドデータテーブル２においてステージングテーブル１の行１を探す。これは、そこにある。それ故、行１は、無視される。ステージングテーブルの行２は、次いで、コックドデータベースと比較され、そこにあるかどうか調べる。これはない。それ故、コックドデータテーブル２の行２がデ・デュープドコックドデータテーブル３に追加される。次いで、ステージングデータベースにおける各エントリーに対して同じプロセスが繰り返される。無視するか又は追加するこのプロセスが完了すると、ランナー番号２に関連したコックドデータテーブル２の行がステージングテーブル１と比較され、コックドデータベーステーブル２にないランナー２の行がステージングデータベースにあるかどうか決定する。この例では、コックドテーブル２の第３エントリーがステージングテーブル１にない。それ故、このエントリー、即ちジェネラルマネージャーの行は、削除される。その結果、デ・デュープドコックドデータベースが再生され、１日に一度検証されるか、又はシステムアドミニストレータによって定義された周期に一度検証される。

デ・デューピングタスクプロセスのより一般的な図が、図１２に示されている。プロセス１２００は、ステージングデータベースに記憶されたスレッドランナーＩＤを有するデータセットに対してデータスプリットタスク及び浄化タスクが完了したときにコールされる。制御はオペレーション１２０２において開始され、ここでは、デ・デューピングモジュール１３９の初期化が完了する。次いで、制御は、オペレーション１２０４へ移行し、ここでは、ステージングデータベース２２２の第１行が検索され、そしてコックドデータベース２３６の行エントリーに対して検査される。制御は、問合せオペレーション１２０６へ移行する。

問合せオペレーション１２０６において、コックドデータベースに同じ行があるかどうかについて問合せがなされる。もしあれば、制御は、オペレーション１２０８へ移行し、検査されているステージング行が削除される。次いで、制御は、オペレーション１２０４へ戻り、そこで、ステージングデータベースの次の行が検索され、検査される。しかしながら、問合せオペレーション１２０６の答えがノーである場合には、コックドデータベース２３６に同じ行は存在せず、次いで、この行がオペレーション１２１０においてコックドデータベースに追加される。次いで、制御は、問合せオペレーション１２１２へ移行し、そこで、ステージングデータベースの更なる行があるかどうかの問合せがなされる。もしイエスであれば、制御は、オペレーション１２０４へ戻り、そこで、ステージングデータベースの次の行が検索され、プロセスが繰り返される。もしノーであれば、ステージングデータベースの最後の行が検査され、制御は、問合せオペレーション１２１４へ移行する。

問合せオペレーション１２１４において、同じランナーＩＤをもつコックドデータベース２３６の行が、ステージングデータベースのエントリーと比較される。ステージングデータベースにない同じランナーＩＤの行がコックドデータベースにある場合には、これらの行がコックドデータベースから削除される。その理由は、ステージングデータベースがジョブリスティングをもたない場合には、リスティングが雇用主によりプルされるか又は埋められ、従って、ブルテンボード又は経歴リスティングから除去されねばならず、ひいては、求職者にとって有効な仕事の機会はもはやなく、従って、この雇用機会システムにおいて使用されないからである。他方、コックドデータベース２３６における全ての同じランナーＩＤ行がステージングデータベース２２２にある場合には、全てが現在のものであり、制御は、復帰オペレーション１２１８へ移行する。

ここで、ＰＡＬＭマスタータスクスケジューラー１３１は、スプリットタスク、浄化タスク、及びデ・デューピングタスクを通してデータセットを見ており、そしてコックドデータベース２３６は、ここで、特定のデータセットに対してデ・デューピングされ、コックドデータベース２３６のコンテンツへの各新たなエントリーは、カテゴリー分けタスク５２２及びクオリティマネージャータスク５２４へ提示される。図６及び７を参照して、カテゴリー分けタスクを以下に説明する。又、図１３を参照して、クオリティマネージャータスクを説明する。

スクレーピングエンジン２１８を経て得られたスクレープされたジョブは、会計、銀行、工学、医療、歯科、等のカテゴリー指定を有していない。求職者に最も馴染みのある「カテゴリーによるブラウズ」特徴をサポートするために、人間カテゴライザーの多くは、ジョブがスクレープされるときにジョブを手動で分類するのに多大な時間を費やす必要がある。しかしながら、これは、実質的な欠点がある。これは、非常に時間を費やすプロセスである。ジョブは、手動で分類されるときまでに、既に古いものになってしまうことがある。このようなプロセスは、多大な人的資源を必要とする。更に異なるカテゴライザーは、同じ一貫した仕方でカテゴリー分けをしないことがある。このため、ＰＡＬＭシステム２００は、図６に示す自動ジョブカテゴリー分けシステム６００を備えている。このシステム６００は、１秒以内にジョブをカテゴリー分けすることができる。これは、人間のカテゴライザーより実質的に高速であり、且つ一貫したものである。

このジョブカテゴリー分けシステム６００は、多数のモジュールを含む。即ち、実際のカテゴリー分けルーチンを実行するジョブカテゴリー分け（ＪｏｂＣａｔ）サービスモジュール６０２を含む。図１に示されたジョブカテゴリー分けエンジンモジュール１４０は、コックドデータベース２３６のJob_currentテーブル６２６と、手動カテゴリーデータベース６２８と、ジョブカテゴリー（Ｃａｔ）サービスモジュール６０２との間の通信を管理する。カテゴリーレビューモジュール１３２により遂行されるカテゴリー分けトレーニングプロセス６０６は、ＪｏｂＣａｔサービス６０２の精度レベルを向上させ及び／又は維持するために使用される。このカテゴリー分けトレーニングプロセス６０６は、ジョブカテゴリー分け手動レビューインターフェイスモジュール１３２と、図１Ａに示すイントラネット１１６を経てアクセスできるカテゴリー分け専門家との使用を含む。

上述したように、スクレープされたジョブは、浄化されそしてデ・デュープされると、コックドデータベース２３６のＭｙＳＱＬJob_currentテーブル６２６に追加される。ジョブカテゴリー分けプロセス６００は、Job_currentテーブル６２６から各ジョブを取り出し、ジョブカテゴリー分け制御プロセスモジュール６２２を通してＪｏｂＣａｔサービスモジュール６０２へ送信し、カテゴリー及び信頼指定を得る。次いで、スクレープされたジョブは、カテゴリー分け制御プロセスモジュール６２２へ送り返され、そしてJob_currentテーブル６２６へ返送される。しかしながら、ジョブが所定の信頼スレッシュホールドより下がった場合には、フラグが立てられ、即ちフラグがセットされ、そしてそれがカテゴリー分け制御プロセスモジュール６２２を通過するときには、手動レビューインターフェイスモジュール１３２を経て手動レビューするためにman_catデータベース６２８にもコピーが送信される。レビューモジュール１３２で遂行される手動レビュープロセスの結果は、次いで、カテゴリー分けトレーニングプロセス６０６により使用されて、新たなＪｏｂＣａｔサービス値を、古い値に取って代わるように同調させる。分類の結果は、Job_currentテーブル６２６に書き戻され、時には、man_catテーブル６２８に書き戻される。手動レビューモジュール１３２は、Job_currentテーブル及びman_catテーブルの両方のジョブをレビューするためのＵＩを与える。

図７は、ジョブカテゴリー分けプロセス６００を実施する動作フロー図である。このプロセスは、オペレーション７０２において、一連のジョブスクレーピングが遂行されたときに始まる。制御は、オペレーション７０４へ移行する。オペレーション７０４において、次のジョブに対するジョブ属性がJob_currentテーブル６２６から検索され、そしてジョブ説明が適切にフォーマットされる。次いで、ジョブ属性がＪｏｂＣａｔサービス６０２へ転送され、適切なカテゴリーが見出される。次いで、制御はオペレーション７０６へ移行し、そこで、ジョブカテゴリー及びそのカテゴリーに対する信頼レベルがジョブと対にされる。次いで、制御は問合せオペレーション７０８へ移行する。

問合せオペレーション７０８は、最新の特定ジョブ説明に対して、マッチするＵＲＬがman_catテーブルに存在するかどうか尋ねる。もしあれば、制御はオペレーション７１０へ移行する。もしなければ、ジョブは新たなジョブであり、制御は、オペレーション７１６へ移行する。

オペレーション７１０では、同じＵＲＬで最後のジョブに対してストリング比較ルーチンが遂行される。次いで、制御は、問合せオペレーション７１２へ移行する。この問合せオペレーション７１２は、man_catテーブル６２８のリスティングが、検査されている現在ジョブと同じであるかどうか尋ねる。ジョブストリング比較が等しい場合には、答えがイエスであり、制御はオペレーション７１４へ移行する。というのは、ジョブが同じジョブであると思われるからである。他方、答えがノーである場合には、ジョブが新しいものであり、制御は、再び、オペレーション７１６へ移行する。

問合せオペレーション７１４は、dcp_catが、同じＵＲＬでの最新のジョブのman_catにマッチするかどうか尋ねる。その答えがイエスである場合には、man_cat及びdcp_catが等しくセットされ、そしてdcp_catの信頼値が１に等しくセットされる。ジョブパラメータは、Job_currentテーブル６２６へ戻され、そして制御は問合せオペレーション７１８へ移行する。問合せオペレーション７１８は、カテゴリー分けされるべきスクレープされたジョブがJob_currentテーブルに更にあるかどうか尋ねる。もしなければ、制御は復帰オペレーション７２０へ移行する。カテゴリー分けされるべきスクレープされたジョブがもっとある場合には、制御はオペレーション７０４へ戻され、次のジョブに対するジョブパラメータが検索されてフォーマットされる。

問合せオペレーション７０８に戻ると、ＵＲＬがman_catテーブルに存在しない場合には、制御がオペレーション７１６へ移行する。オペレーション７１６では、Dcp_cat及びdcp_confidenceがセットされ、信頼値が所定のスレッシュホールドに対してチェックされ、そしてスレッシュホールドが信頼値より大きい場合には、review_flagが１にセットされる。次いで、ジョブパラメータがJob_currentテーブル６２６へ通され、この場合も、制御は問合せオペレーション７１８へ進む。

問合せオペレーション７１４へ戻ると、現在ジョブがman_catテーブル６２８にＵＲＬを有する場合には、ジョブは、同じＵＲＬでの最後のジョブと同じであるが、最新のジョブのdcp_cat及びan_catはマッチせず、何かが間違っているか欠落しており、そしてジョブパラメータがオペレーション７２４及び７２６の両方へ通される。オペレーション７２４は、dcp_cat、dcp_confidence値をセットし、expert_reviewフラグ＝１にセットし、そしてこのデータをJob_currentテーブル６２６へフィードする。オペレーション７２６は、expert_reviewフラグ＝１にセットし、このジョブパラメータのコピーをman_catテーブル６２８へ送信し、手動レビューが遂行されるようにする。並列に、制御は、ここでも、上述したように、問合せオペレーション７１８へ進む。

従って、各ジョブに対して、ジョブカテゴリー分け制御プロセスは、Job_currentテーブルからジョブ属性を取り上げ、それらをフォーマットし、それらをＪｏｂＣａｔサービス（Ａｐａｃｈｅ、メソッド＝ＰＯＳＴと称される良く知られたパブリックドメインルーチンにより管理される）へと送信し、カテゴリー及び信頼スコアを取り戻し、判断質問のチェーンを通して進み、そして結果をテーブルに書き戻す。

又、ＪｏｂＣａｔサービス６０２は、アドミニストレータ及びシステムオペレータがジョブ（少なくともジョブ説明）をタイプ入力し、そしてシステム１００の通常のオペレーションとは別にカテゴリー分けのためにＪｏｂＣａｔサービスへジョブを提示するのを許すウェブＵＩも与える。このような例示的ユーザインターフェイス８００が図８に示されている。

ＪｏｂＣａｔサービスモジュール６０２は、図６に示すトレーニングプロセス６０６をホストするための良く知られたウェブサーバーであるＡｐａｃｈｅに依存する。このＪｏｂＣａｔサービス６０２は、ＰＨＰ拡張の共有ライブラリーであり且つカテゴリー分けライブラリーも含むバイナリーパケットを包含する。ＪｏｂＣａｔサービス６０２を構築するには、先ず、ジョブカテゴリーの１組の基本的な定義、即ち分類学６０８、及びそれに関連した独特のＩＤ番号を必要とする。例示的な１組を以下のテーブル１に示す。

テーブル１

トレーニングジョブ説明、即ちトレーニングデータ６１０の例示的テーブルが、テーブル１の各カテゴリーに関連付けされる。この１組の説明と、man_catテーブル６２８のコンテンツとを使用して、予め分類された与えられたジョブ説明パラメータからの分類を確認するサービスを教示する。このテーブルの一例を、以下のテーブル２に示す。

テーブル２

新たなトレーニングセッションについては、このテーブルからのジョブと、man_catテーブルのジョブの両方を使用するのが好ましい。手動でレビューされるジョブが益々利用できるようになるにつれて、リードオンリデータベースからオリジナルトレーニングセットを最終的にドロップさせるのが好ましい。

好ましい実施形態では、このテーブル２及びman_catテーブルの列が相違し、この相違が保持されると共に、トレーニングファイルを生成するスクリプトが全ての必要なマッピングを行う。トレーニングプロセス６０６は、多数のＰＥＡＲＬスクリプトより成る。“create-training-file.pl”スクリプトは、man_catテーブル６２８及びトレーニングデータテーブル６１０の両方からジョブを取り出し、そして全てのジョブを含むファイルをＤＣＰ受け容れフォーマットで書き出して、合併トレーニングデータ６１２を発生する。“train-hj-dcp.pl”スクリプトを使用して、分類のために最も有用なパラメータの幾つかを同調させる。ここに特定する各コンフィギュレーションは、ＪｏｂＣａｔサービスデータパッケージ及びログファイルを構築するのに必要な全パラメータを含む出力ディレクトリを残す。“parse-training-log.pl”スクリプトは、“train-hj-dcp.pl”スクリプトにより生成されたログファイルの各々を読み取り、そして各コンフィギュレーションの精度に関するレポートを生成する。“archive-training-results.pl”スクリプトは、展開のためのコンフィギュレーションが使用された後にそのコンフィギュレーションに対するトレーニング結果を保存するのに使用される。

トレーニングプロセス６１４は、基本的に、トレーニングデータ６１４、分類学６０８並びにルール及びスキーマのセット６１６から引き出す手動プロセスである。又、種々のディクショナリー及びチューニングパラメータ６１８が使用されてもよい。その結果は、新たなクラシファイアパラメータ６２０の最適化を含み、図６に示すように、ジョブカテゴリー分けサービス６０２へ結果が与えられる。トレーニングプロセス６１４は、ほとんど手動であるので、若干のパラメータについてトレーニングし、結果、例えば、分類の詳細なページ、用語の重み、等を手動でチェックし、ルール及びディクショナリーの幾つかを手で変更し、そして異なるコンフィギュレーションでプロセスを繰り返し、展開のための最適なセッティングを見出すのが好ましい。このような最適なコンフィギュレーションが達成されると、新たなクラシファイアパラメータ６２０がジョブカテゴリー分けサービス６０２へ通される。ジョブカテゴリー分けサービス６０２が構築されて実行されると、上述したように、スクレープされたジョブを処理することができる。

以下、例示的ジョブカテゴリー分けプロセスを使用して本発明のリスティングカテゴリー分けプロセスを詳細に説明する。

例示的な字句分析において、３つのテキストフィールドが処理される。（１）肩書き、（２）ジョブ説明、及び（３）会社のカテゴリー。Lexer(lexical-analysis module)が次のプロセスステップに適用される。
１．共通のＨＴＭＬキャラクタ−エンティティリファレンスが、それに対応するＡＳＣＩＩキャラクタに置き換えられる。
２．次いで、非アルファニューメリックキャラクタをデリミッタとして処理することによりテキストフィールドがストリングに分割される（単一の引用符がアルファニューメリックキャラクタとして処理される）。
３．ジョブ肩書きテストが全てのストリングに適用される。ジョブの肩書きは、regex [0-9]*[A-Z]+[A-Z0-9]*を満足するストリングとして定義される。全てのストリングは、小文字に変換される。
４．全てのストリングは、Porterステマーを使用してステムされる。(M. F. Porter. “An algorithm for suffix stripping”; Program, 14(3): 130-137, 1980. Reprinted in Sparck Jones, Karen, and Peter Willet, 1997, Readings in Information Retrieval, San Francisco: Morgan Kaufmann, ISBN 1-55860-454-4、ここでは、“Porter”と称される)
５．ストップワードの予め定義されたリストを使用して、非常に共通した特徴をテキストフィールドからフィルタリングする。純粋なデジットより成るストリングも取り除かれる。

ストップワードの例は、次の通りである。

job description be able right candidate qualified applicants
job id your resume qualified candidate interested candidate
job title seeking equal opportunity interested candidates
job summary be considered eoe interested applicants
such as can enjoy qualified candidates duties
currently seeking ideal candidate contact information focused on
are seeking ideal candidates remain emphasis on
click here successful candidate find out depending on
selected candidate further information come join are met
highly desired should forward please note follow through
strongly desired without regard please sent work closely
strongly preferred subject line please indicate board range
strong online below please submit wide range
preferred listed below please visit wide variety
are encouraged when applying primary responsibility conjunction with
button below when submitting word attachment
make sure be contacted
contact us
幾つかのバイグラム(bigrams)（２ワードフレーズ）は、単一トークンとして検出される。上位のｎグラムも、カテゴリー分けに使用してもよい。

その例を以下に示す。
human resources at least self starter tuition reimbursement
equal opportunity power point accounts payable customer service
pay rate click here seque appli positively impacting
problem solving ajilonfinance com funct subfu human resource
d v boehringer ingelheim registered trademark san francisco
more than immediate los angeles award winning
united states consideration full time decision making
cover letter new york spirited metropolitan area
ideal candidate track record entrepreneurial credit union
long term stock purchase bames noble benefits package
job description loss prevention ad hoc wide range
job title ag 2002 wild kingdom multi task
job summary ajilon finance voice messaging sarbanes oxley
duties fortune 500 affirmative action p sou
air force fastest growing iras cancer valid driver
kaiser permanente general ledger tuition assistance
deutsche telekom real estate
test plans
journal entries

これらのステップから生じる各独特のストリングは、独特のトークンを構成する。幾つかのトークンは、付加的な重みが追加され、weight.dictファイルにおいて追跡される。ファイルのジョブ特有サンプルは、次の通りである。
general ledger 2 per week 3 technical sales 3 development
inpatient 2 nurse 3 planning analyst 2 lifecycles 2
outpatient 2 registered nurse 3 budget planning 3 operating systems 2
claims adjusting 3 human resource 3 financial planning 3 programming
estimate damage 3 college degree 3 financial statements 3 languages 3
ASIC design 3 hs degree 3 financial reports 3 business skills 2
logic design 3 systems administrator corporate tax 3 communication
residential purchase 3 worker compensation disorders 2
3 accounts receivable 3 3 speech language 2
refinance products 3 accounts payable 3 business speech therapy 2
mortgage products 3 fixed assets 3 development 3 speech pathology 2
mortgage loan 4 medical terminology 3 market development speech therapist 2
mortgage brokers 3 legal terminology 3 3 speech pathologist 2
mortgage lender 3 public relations 3 trade shows 4 switchboard 2
call center 3 product marketing 3 forklift operator 2 telephone skills 2
customer service 3 clinical research 3 forklift certified 2 blood drives 2
answers telephone 3 clinical trials 3 food service 3 blood centers 2
inventory control 3 clinical data 3 real estate 3 plasmapheresis
quality assurance 3 direct sales 3 social services 4 process 2
object oriented 4 internet publishing 2 phlebotomist 2

各テキストトークンに対応する「特徴」は、単に、ドキュメントにおけるトークンの、ドキュメント当たりの発生回数でよい。各トークンインスタンスには、それが抽出されたフィールドに依存すると共にそのフィールド内の特徴の位置に依存し得る重みが指定されてもよい。特に、肩書き及び会社のカテゴリーからのトークンカウントに２を乗算した後にそれを全カウントに加算してもよい。説明用語のカウントは、不変と考えてもよい。実施し得る位置依存ルールは、名詞句（例えば、肩書き）内で先頭の名詞を見出す試みにおいて肩書きの最後のワードに、より重たく重み付けすることであり、これは、精度を僅かに高めることになる。

又、多数のトークン（単一クラスターのメンバー）が全て同じトークンとして処理されるトークン特徴クラスタリング（例えば、分散型クラスタリング）を使用することもできる。

上述したように、ジョブレコードは、フリーテキストではないフィールドを含んでもよい。それらは、（１）会社ｉｄ、（２）サラリー、等を含む。これらの特徴が使用される実施形態は、「カテゴリー洗練化」と題する章で説明する。

特徴の選択は、カテゴリー変数を伴う相互情報Ｉ（Ｃ、Ｘ）で個々の特徴ｘをランク付けすることにより遂行できる。

ここで、ｘの和は、ｘ＝０及びｘ＝１に対するものであり、ｃの和は、全てのカテゴリー（クラス）に対するものである。ｐ（ｃ、ｘ）に対する確率推定値は、単純なカウントにより得られ、そしてバイナリー変数ｘは、関連する用語の存在（ｘ＝１）又は不存在（ｘ＝０）を指示する。術語に関して、これは、厳密に言えば、実際のカテゴリー分けのためにクラシファイア（例えば、ナイーブ・ベイズ(Naive Bayes)）に使用される関連用語カウントとは異なる特徴である。これは、数値的な理由で有益である。それに代わるものは、０から無限大まで全ての考えられる用語カウントを加算することであるが、関連する確率推定の潜在的な希薄さのために問題が生じ得る。

ランク付けされたリストは、相互情報の減少する順に処理される。特徴の各数ｍに対して、リストからの最初のｍを使用してクラシファイアがトレーニングされ、そしてクロス確認を使用してその精度が測定される。このように測定される精度が下がり始めるまで、特徴が追加される。

又、特徴の数は、頻度スレッシュホールド限界を設定することにより制御されてもよい。頻度がスレッシュホールド限界未満である特徴は、排除されてもよい。クロス確認により報告されたように最良の精度指数を生じる、スレッシュホールドと特徴の数との組み合せは、２つ又は３つある。

本発明の１つの態様によれば、多数のパスでオファーするジョブをカテゴリー分けする方法が提供される。第１ステップは、第１のカテゴリー分けを遂行して、ジョブを第１のカテゴリーに関連付けることである。第１のジョブカテゴリーが共洗練化可能なジョブカテゴリーのセット内にある場合には、その共洗練化可能なジョブカテゴリーのセット内で第２のカテゴリー分けを遂行して、ジョブのオファーを第２のジョブカテゴリーに関連付ける。更に、第２のジョブは、共洗練化可能なジョブカテゴリーのセット内にあり、第１のジョブは、ジョブの第１セット内にあり、そして共洗練化可能なジョブカテゴリーのセットは、ジョブの第１セットの適切なサブセットである。共洗練化可能なジョブカテゴリーのセットとは、（あるものを別のものと）混同するおそれが比較的高いか、又はセット内のあるジョブカテゴリーがセット内の別のジョブカテゴリーに代わって選択されたと何らかの方法で決定されたジョブカテゴリーのセットとして定義される。

第２のパスに使用するように選択されたカテゴリー、即ち共洗練化可能なジョブカテゴリーは、探しているカテゴリーに基づいて選択される。例えば、共洗練化可能なジョブカテゴリーは、特定のカテゴリーに対して他のカテゴリーと混同するおそれに基づいて決定することができる。２つのカテゴリーがしばしば混同されるかどうか決定する１つの方法は、ジョブのセットの手動カテゴリー分けを遂行することである。手動カテゴリー分けは、正しいものとして、即ちゴールドスダンダートとして処理される。次いで、同じセットのジョブの自動カテゴリー分けを遂行する。一方の軸がゴールドスタンダード（この場合は手動）カテゴライザーにより選択されたカテゴリーを表わし、他方の軸が自動カテゴライザーにより選択されたカテゴリーを表わすマトリクスにおいて結果をグラフ表示する。手動及び自動カテゴリー分けで同じカテゴリーを選択する（おそらく実施形態によっては対角線に沿って）マトリクスにおいて全てのセルを除外すると、最も高い確率をもつセルは、最も混同し易いカテゴリーを表わす。従って、共洗練化可能な製品カテゴリーのセットは、最も混同し易いセルに基づき、そして実際には、共洗練化可能な製品カテゴリーの多数の個別のセットを含み、これらのセットは、各々、他のものとは異なる数のカテゴリーを含むことがある。

ここで、カテゴリー洗練化の一例を説明する。ここに述べる技術は、このような実施形態に限定されない。ナイーブ・ベイズ(Naive Bayes)カテゴライザーに基づいて構築された自動クラシファイアについて考える。ナイーブ・ベイズカテゴライザーの例が、David D. Lewis、“Naive (Bayes) at forty: The independence assumption in information retrieval”; in Claire N'edellec and C'eline Rouveirol, editors, Proceedings of ECML-98, 10^th European Conference on Machine Learning, number 1398, pages 4-15, Chemnitz, DE, １９９８年、に掲載されており、これは、ここでは、“Lewis”と称される。カテゴライザーは、２つ以上のカテゴリー分けレベルを有する。トップ（根）レベル６１０では、「ナイーブ・ベイズ」と題する章で述べるように、各カテゴリーが単一多項式分布で記述されるようなフラットカテゴリー分けを遂行することができる。多項式の混合を使用して、あるカテゴリーに対して用語確率分布をモデリングすることができる。厳密に述べると、これは、ナイーブ・ベイズの条件付き独立性の仮定に違反するが、あるカテゴリーを、この仮定に従うがそれらが何であるか先験的に分らない他のカテゴリーへ更に分解できることを単に仮定してもよい。

次いで、共洗練化可能なカテゴリーのセット内にある幾つかのカテゴリーに対して第２のカテゴリー分けが遂行される。これらカテゴリーは、３つの「混同」グループに分割された以下のリストにあるものでよい。各グループにおけるトップレベルノードは、混同グループ内のカテゴリーのみに対して第２のカテゴリー分けを遂行するクラシファイアを有する。

会社ｉｄの場合には、考えられる最もシンプルなモデルであるマルチ・ベルノウリ(multi-Bernoulli)を使用することができる。即ち、各（カテゴリー、会社）対に対して異なる確率推定値をもつことができる。即ち、会社ｉｄをｍとすれば、値｛ｐ（ｃ｜ｍ）｝のセットに対して推定値をもつことができる。これらの値は、｛Ψｃ、ｍ｝によって表わされる。

対数正規分布でサラリー統計値を説明すると、サラリーは、対数正規分布に従ってほぼ分布され、これは、対数価格が単純な正規／ガウス分布に基づいて分布されることを単に意味する。ｚ＝ｌｏｇ（価格）であるとする。次の式が得られる。但し、μ_c及びσ_cは、正規分布の平均及び標準偏差である。

テキストのためのナイーブ・ベイズクラシファイア
マシン学習及びパターン分類においては、カテゴリー分け（又は「分類」）されるべきオブジェクトは、ドキュメントが属する見込みが最も高いカテゴリーを決定するのに使用される情報を含む「特徴ベクトル」ｘと称されるものにより表わされる。ドキュメントに対するいわゆる「ナイーブ・ベイズ(Naive Bayes)」クラシファイアは、「バッグ・オブ・ワード(bag-of-words)」モデルと称されるものを仮定する（Ｌｅｗｉｓを参照）。これは、ワードの特定シーケンスが無視され、それらのカウントしか使用されないことを意味する。この制限は、フレーズがトークンとして検出されそして個々の用語であったかのように処理されるときには、若干回避される。（ナイーブ・ベイズ）のケースでは、特徴ベクトルは、次の式となる。
ｘ＝（ｋ₁、ｋ₂、・・・ｋ_m）
但し、ｋ_iは、ｉ番目の用語の発生回数（カテゴリー分けされるべきドキュメントにおける）であり、そしてｍは、辞書における全用語数であり、このケースでは、ストップワードの除去、等の後にカテゴリー分けを行なうのに使用される用語のセットを指す。

ベイズのクラシファイアは、確率モデルを次のように使用する。特徴ベクトルｘが与えられると、ドキュメントの特徴ベクトルｘが与えられた場合にドキュメントがカテゴリーｃに属する条件付き確率を計算する。カテゴリー分けを遂行するために、ｐ（ｃ｜ｘ）を最大にするｃに対する値ｃ’（即ち、カテゴリーへのドキュメントの指定）を選択する。数学的に、これは、次のように表わされる。
ｃ’＝ａｒｇｍａｘ_c ｐ（ｃ｜ｘ）

この条件付き確率ｐ（ｃ｜ｘ）は、次のように分解できる。
ｐ（ｃ｜ｘ）＝（ｐ（ｘ｜ｃ）ｐ（ｃ））／ｐ（ｘ）

関心があるのは、ｃ’の値だけであって、ｐ（ｃ’｜ｘ）の特定値ではないので、ｘだけに依存しｃには依存しない周辺確率ｐ（ｘ）を無視することができる。
ｃ’＝ａｒｇｍａｘ_c ［ｐ（ｘ｜ｃ）ｐ（ｃ）］ (5)

この式における確率は、共同確率（ｘ、ｃ）である。
ｐ（ｘ、ｃ）＝ｐ（ｘ｜ｃ）ｐ（ｃ）

実際のカテゴリー分けプロセスを実行するためには、ｐ（ｃ）及びｐ（ｘ｜ｃ）のための特定の式が必要である。ナイーブ・ベイズ／バッグ・オブ・ワードモデルは、これに対する多項式分布を使用することができる。即ち、

この式は、「多項式係数」と称されるものに対して次のような省略表示を含む。

但し、ｎ！は、「ｎ階乗」を表わし、次の積を示す。
ｎ！≡ｎ（ｎ−１）（ｎ−２）（ｎ−３）・・・３ｘ２

この多項式係数は、ドキュメントのみの関数であって、クラスの関数ではないので、これもカテゴリー分けプロセスにおいて無視することができる。パラメータ｛θ_i｝は、しばしば、「ベルノウリ(Bernoulli)」パラメータと称され、トレーニングデータから推定することができる。この（“｛・・・｝”）は、省略セット表示である。例えば、｛θ_i｝は、実際には、｛θ_i｜ｉ＝１、２、・・・ｍ｝、即ちこれらパラメータ値の完全なセットを表わす。

カテゴリーごとに、ｐ（ｘ｜ｃ）及びｐ（ｃ）の値を有し、これらの各々は、それ自身の推定パラメータ値を有する。カテゴリーｃ内の用語ｉに対するベルノウリパラメータが表わされ、次の式により推定することができる。

但し、ｎ_i,cは、カテゴリーｃのトレーニングドキュメントの全集合における用語ｉの全インスタンス数であり、ｎ_cは、カテゴリーｃのトレーニングドキュメントの全集合における全用語（カテゴリー分け辞書における用語であって、ストップワード等ではない）の全インスタンス数であり、そしてｍは、辞書における全用語数である。式（８）は、「ラプラスのルール」又は「ラプラスの連続ルール(Laplace's Rule of Succession)」として知られている。

式（５）で示されたカテゴリー分けを遂行するために、周辺クラス確率｛ｐ（ｃ）｝の推定値を必要とする。これらの推定値をφ^' _cで表わすことができ、それらに対してもある形式のラプラスのルールを使用することができる。

但し、ｖ_cは、トレーニングセットにおけるカテゴリーｃの全ドキュメント数であり、Ｎは、トレーニングセットにおける全ドキュメント数（全カテゴリー）であり、｜Ｃ｜は、全カテゴリー数である。これらの数（｛ｖ_c｝及びＮ）が、カテゴリー分けされるべきドキュメントの最終的なポピュレーションを表わさない場合には、｛φ^' _c｝に対して正しい推定値（何らなの手段により得られた）が使用される。

「判別関数」ｄ（ｘ、ｃ）は、次のように定義される。

式（５）により示されたカテゴリー分けの実施は、これに関して、次のように表わすことができる。
ｃ’＝ａｒｇｍａｘ_c ｄ（ｃ、ｘ） (11)

式（１０）の対数を、数値及び計算の両方の理由で判別関数として使用するのが有益である。従って、次のようになる。

例示的ユーザインターフェイス８００のスクリーンショットが、ウェブブラウザを使用して、イントラネット１１６を経てアドミニストレータ、オペレータ又はカテゴリー分け専門家に提示される。このインターフェイス８００は、図示されたプルダウンメニューを経て３つの異なるモード８０２を与える。「全カテゴリー」モードは、全カテゴリー及びそれに対応する信頼値を、信頼値が小さくなる順に分類して、リストする。「詳細な統計値」モードは、なぜ特定のカテゴリーが選択されたかの詳細を示す。このモードは、システム２００をチューニングするオペレータにとって有用である。「最良カテゴリー」モードは、ジョブ及びその信頼値に対してトップカテゴリーだけを示す。これは、「全カテゴリー」モードに示された第１の結果に等しいが、ここでは、ストリングではなく、カテゴリーＩＤ番号を示す。このモードは、データベースにおけるジョブの自動分類に意図され、カテゴリーＩＤ番号は、カテゴリー名よりも好ましい。

ジョブカテゴリー分け手動レビューモジュール１３２において行なわれるジョブカテゴリー分け手動レビュープロセス９００のオペレーションフローチャートが図９に示されている。このオペレーションフローは、アドミニストレーションオペレータ又はカテゴリー分け専門家がオペレーション９０２においてＰＡＬＭアドミニストレーションポータル１０２を経てログインするときに始まる。アドミニストレータは、ログインすると、オペレーション９０４において、図１０に示すユーザインターフェイス１０００が提示される。このユーザインターフェイス１０００は、アドミニストレータ又は専門のレビューアが、カテゴリー１００２、会社１００４を選択し、そしてレビューの形式１００６の選択を行なうのを許す。次いで、制御はオペレーション９０６へ移行する。オペレーション９０６では、オペレーション９０４におけるアドミニストレータの以前の選択に基づいて、第１の／その次のジョブ説明が、コックドデータベース２３６におけるman_catデータベース６２８又はjob_currentテーブル６２６から検索される。アドミニストレータは、図１１に示す例示的インターフェイス１１００のようなユーザインターフェイスが提示される。

このユーザインターフェイス１１００は、第１の／その次のジョブ説明１１０２を、各カテゴリーについて決定されたカテゴリー信頼レベルと共に表示する。この例では、ジョブは、ＩＢＭ社のｐｏｓｔ−ｄｏｃポジションである。信頼レベルは、Engineering_Architecture及びPharmaceutical_Biotechを除く全てに対してゼロであり、どのレベルも１００％マッチしない。このポジションは、Engineering_Architectureとしてカテゴリー分けされるが、信頼レベルは、０．６５７しかなく、従って、手動のレビューについてフラグが立てられる。

図９へ戻ると、オペレーション９０６においてジョブ説明が検索されたとき、制御は、オペレーション９０８へ移行し、そこで、アドミニストレータは、全ジョブ説明に基づいてカテゴリー分けを分析する。次いで、アドミニストレータは、アクションについて３つの選択肢を有する。第１に、問合せオペレーション９１０においてジョブを無効化することができる。第２に、問合せオペレーション９１２において、ジョブＵＲＬ１１１０をクリックしてレビューを向上させることにより、更なるジョブ詳細を得ることができる。第３に、問合せオペレーション９１４において、カテゴリー定義を更新するか、又は新たなカテゴリーを挿入することができる。問合せオペレーション９１０においてジョブを無効化すべきと判断する場合には、制御がオペレーション９１６へ移行し、そこで、ジョブがデータベース１２６及びman_catデータベース６２８から除去される。次いで、制御は、問合せオペレーション９１８へ移行する。この問合せオペレーション９１８は、man_catデータベース６２８又はjob_currentテーブル６２６の待ち行列に、expert_reviewフラグ＝１にセットされた別のジョブ説明があるかどうか尋ねる。もしそうであれば、制御は、オペレーション９０６へ移行し、そこで、次のジョブがレビューのために検索される。

しかしながら、オペレーション９１０の判断が、ジョブを無効化するのではない場合には、expert_reviewフラグ＝０にリセットし、ジョブをjob_currentテーブル６２６へ戻し、そして制御は、問合せオペレーション９１８へ移行する。オペレーション９０８における選択が、更なるジョブ詳細を得ることである場合には、制御がオペレーション９２０へ移行し、そこで、詳細が検索され、そして制御は、再び、オペレーション９０８へ移行する。次いで、アドミニストレータが、更なる詳細を得ないことを選択する場合には、expert_reviewフラグ＝０にリセットした後にジョブ説明レコードが再びjob_currentテーブル６２６へ戻され、そして制御は、再び、問合せオペレーション９１８へ進む。オペレーション９０８の選択が、問合せオペレーション９１４においてカテゴリーを更新することである場合には、制御は、オペレーション９２２へ進む。

オペレーション９２２において、ジョブ説明のカテゴリーが変更されるか又は新たなものが追加され、そしてセーブされる。expert_reviewフラグ＝０にセットされ、次いで、ジョブ説明がjob_currentテーブル６２６へ転送され、そして制御が問合せオペレーション９１８へ移行する。expert_reviewフラグ＝１にセットされた状態でそれ以上のジョブ説明がない場合には、制御は、復帰オペレーション９２４へ移行し、レビューセッションが完了となる。

更に、ジョブカテゴリー分け制御プロセスモジュール６２２は、コックドデータベース２３６の情報を周期的にレビューし、各ジョブリスティングを正確にカテゴリー分けするのが好ましい。ジョブリスティングは、適切なジョブカテゴリー、例えば、情報技術、ヘルスケア、会計、等に入れられることが重要である。ジョブカテゴリー分け制御プロセスモジュール６２２は、自動化されるのが好ましく、或いは手動レビューインターフェイスモジュール１３４を通して、好ましくは人間であるカテゴリー分け専門家からの入力により増強されてもよい。しかしながら、専門家の機能は、先に述べたリスティングレビューアエンティティの場合のように、将来は、自動化ルーチンとなってもよい。というのは、このようなシステムは、益々精巧になるからである。ジョブカテゴリー分け制御プロセスモジュール６２２は、自動化されるのが好ましいが、手動レビュープロセスモジュール１３４は、クオリティについてのチェックを与え、従って、ジョブカテゴリー分けにおいて高い精度を与える。このカテゴリー分けプロセスの結果は、手動カテゴリー分けデータベースに対する短縮名であるman_catデータベース６２８に記憶される。

図１３に示すクオリティマネージャータスクでは、コックドデータベースにおける各エントリー行が検索されて、２つのレベル、即ちＵＲＬ有効化及びコンテンツ有効化において評価される。ＵＲＬ有効化では、タスクは、先ず、ｈｔｔｐ及びｈｔｔｐｓリソースへのリンクが有効であることをチェックし、検証する。本質的に、このシステムは、ＵＲＬにアクセスし、リンクの接続を検証する。第２のオペレーションは、警報応答メッセージがあるかどうかチェックすることを含む。もしそうであれば、リスティングは、手動レビューに対してフラグが立てられる。又、ＵＲＬ有効化オペレーションは、いずれかのリンクが再指令されたか、さもなければ、変更されたかを検出し、そしてセッションクッキーに対するサポートを決定する。クオリティマネージャータスクのコンテンツ有効化部分では、データの非一貫性についてチェックがなされる。例えば、特定のルールを遂行し、ジョブ説明を検証し、説明に対してマッチングアルゴリズムを実行し、都市、州、及び国間のマッチングを検証する、等の種々のチェックが行われる。最終的に、クオリティマネージャープロセスは、同時に動作するｎ個の別々のスレッドで達成することができる。各クオリティマネージャータスクスレッドのオペレーションフローが図１３に示されている。

ルールベースのクオリティエンジンタスクモジュール１４２は、図５に示すシーケンス５００を通して処理される各データセットに対して一連のオペレーションを遂行する。コンフィギュレーションマネージャー１５８は、どれほど多くのリスティングマネージャーモジュール１０４が利用できるか決定する。更に、各リスティングマネージャーモジュール１０４内で、クオリティマネージャータスク１４４は、“Ｎ”個のクオリティマネージャータスクスレッド１６７及び１６９を管理することができる。より詳細には、オペレーション５２４において、オペレーションシーケンス１３００がクオリティエンジンモジュールタスクマネージャー１４２によりコールされる。各クオリティエンジンタスクマネージャー１４２は、“ｎ”個のスレッド１３００の制御を行なう。各シーケンス１３００は、オペレーション１３０２において始まり、必要なレジスタが初期化される。次いで、制御は、オペレーション１３０４へ移行する。このオペレーション１３０４では、コンフィギュレーションジェネレータ１５８により決定されることであるが、クオリティエンジンマネージャー１４２のどれほど多くのスレッドが利用できるか、そしてどれほど多くのスレッド１３００が指定されるかに基づいて、クオリティに対して検査されるべきコックドデータベース２３６のデータセットが検索される。次いで、制御は、オペレーション１３０６へ移行する。ここでは、データセットは、ｎ個の仕切りに分割される。従って、１つの仕切りにおけるデータセットの数は、その仕切り内で利用できるスレッド１３００の数に対応する。次いで、制御は、オペレーション１３０８へ移行する。それに続くオペレーションは、各仕切り内の各データセットに対して並列に遂行される。

オペレーション１３０８において、各データセットがドキュメントルールのセットに対して比較される。例えば、これらのルールは、ジョブ説明のテキストフィールドが少なくとも５つ以上のワードを有するかどうか、ジョブの肩書きフィールドが埋められ即ちナルでないかどうか、ジョブの会社名フィールドが埋められ即ちナルでないかどうか、そしてジョブの場所フィールドが埋められ即ちナルでないかどうか決定することを含む。これらフィールドのいずれかがナルであり、即ちルールに反する場合には、データセットがドキュメントルールに不合格となり、インデックスされないことになる。次いで、制御は、問合せオペレーション１３１０へ進む。問合せオペレーション１３１０では、データセットがルールテストに合格したかどうか尋ねられる。その答えがイエスである場合には、制御は、オペレーション１３１６へ移行する。その答えがノーである場合には、制御は、オペレーション１３１２へ移行し、そこで、エラーフラグがセットされ、次いで、オペレーション１３１４へ移行し、そこで、欠落データのレコードがレポートモジュール１３０へ送信される。次いで、制御は、オペレーション１３１６へ移行する。

オペレーション１３１６において、データセットの場所フィールドをチェックし、都市の場所が、州フィールドにリストされた州に対応し、且つ国がそれに応じて対応することを検証する。次いで、制御は、オペレーション１３１８へ移行する。問合せオペレーション１３１８は、データセットが場所検証テストの各々に合格したかどうか尋ねる。その答えがイエスの場合には、制御は、オペレーション１３２４へ直接移行する。その答えがノーの場合には、オペレーション１３２０において、再びエラーフラグがセットされ、そしてオペレーション１３２２において、場所エラーレポートがレポートモジュール１３０へ送信される。次いで、制御は、オペレーション１３２４へ移行する。

オペレーション１３２４では、検査されているデータセット内の各フィールドのコンテンツを、不敬な又は容認できないワードのセットと比較し、不敬な、さもなければ、受け容れられないワードがデータセットにあるかどうか決定する。次いで、制御は問合せオペレーション１３２６へ移行し、ここでは、不敬な又は受け容れられない言語が見つかったかどうか尋ねられる。受け容れられないワードが見つかった場合には、制御はオペレーション１３２８へ移行し、ここで、エラーフラグがセットされ、そしてオペレーション１３３０へ移行し、ここで、受け容れられない言語のエラーレポートがレポートモジュール１３０へ送信される。他方、不敬なものが見つからない場合には、制御は、オペレーション１３３２へ直接移行する。

オペレーション１３３２において、予備的ＵＲＬアドレスにアクセスし、これをチェックして、アクセス時にエラーメッセージが発生されたかどうか決定する。更に、必要とされるセッションクッキーがある場合には、それらがこのオペレーションで記録される。例えば、ユーザが希望のＵＲＬを得る前にアクセス情報を要求する幾つかのサイトでは、予めのＵＲＬアドレス及びクッキー情報が存在するか又は要求される。このオペレーションは、データセットにおける予備的ＵＲＬ情報が現在あって正しいことを検証する。エラーメッセージがある場合には、それらに注目される。次いで、制御は、問合せオペレーション１３３４へ移行する。問合せオペレーション１３３４は、予めのＵＲＬアドレスがコールされたときにエラーメッセージが受け取られたかどうか尋ねる。その答えがノーである場合には、制御は、オペレーション１３４０へ直接移行する。その答えがイエスである場合には、エラーがあって、オペレーション１３３６においてエラーフラグがセットされ、そしてオペレーション１３３８においてレポートモジュール１３０へエラーレポートが送信される。次いで、制御は、オペレーション１３４０へ移行する。

オペレーション１３４０において、最終的ＵＲＬアドレスがコールされ、要求されたセッションクッキーが記録される。このとき、エラーメッセージが注目される。このオペレーションは、データセットがデータベースにおいて依然現在のものであり続けることを検証するために重要である。特に、ジョブ部署データセットの場合には、ジョブが１日前に埋められることがある。このようなケースでは、部署がクリアされるが、まだデータベースは、ジョブが現在のものであると考える。このオペレーション１３４０は、このような最近の変化状態をキャッチし、このようなアクティビティを受け容れるよう試みる。多くのインスタンスにおいて、このオペレーションは、成功となり、データベースが現在のものとして維持されるよう確保する上で助けとなる。次いで、制御は、問合せオペレーション１３４２へ移行し、ここで、エラーメッセージがあるかどうかの質問がなされ、これは、例えば、ジョブがプルされたことを指示する。エラーメッセージが受け取られない場合には、制御がオペレーション１３４８へ移行する。しかしながら、エラーメッセージが受け取られた場合には、制御がオペレーション１３４４へ移行し、そこで、エラーフラグがセットされ、次いで、オペレーション１３４６へ移行し、そこで、エラーレポートがレポートモジュール１３０へ送信される。次いで、制御は、復帰オペレーション１３６０へ進む。というのは、エラーが受け取られた場合はＵＲＬが無効であり、データセットがインデックスされずに、コックドデータベース２３６へ返送されるからである。

オペレーション１３４８において、ＵＲＬにおけるウェブページが検査のためにダウンロードされる。次いで、制御は、オペレーション１３５０へ移行し、そこで、ウェブページは、データ浄化モジュール１３９で以前に行われたように、ＨＴＭＬデータが浄化される。次いで、制御は、オペレーション１３５２へ移行する。オペレーション１３５２において、データセットのコンテンツは、ウェブページのコンテンツとワードごとにマッチングされる。このオペレーションは、データセットがウェブページを正しく反映することを検証し、これは、リスティングが現在のものであるという別の検証メカニズムである。次いで、制御は、問合せオペレーション１３５４へ移行する。問合せオペレーション１３５４は、マッチングオペレーション１３５２にエラーがあったかどうか尋ねる。エラーがあった場合には、データセットが壊れているか、又はジョブ部署がなぜか異なるものであり、それ故、それがコックドデータベースへ返送され、サーチバンク２４６へ転送されるようにインデックスされない。従って、その答えはイエスであり、制御は、オペレーション１３５６へ移行し、そこで、エラーフラグがセットされ、次いで、オペレーション１３５８へ移行し、そこで、エラーレポートがレポートモジュール１３０へ送信され、次いで、制御は、復帰オペレーション１３６０へ進む。

エラーフラグがセットされる各々のケース、即ちオペレーション１３１２、１３２０、１３２８、１３３６、１３４４、１３５６において、セットされたフラグは、データセットがインデックスされてコックドデータベースへ返送されサーチバンクへ転送されるのを防止する。しかしながら、アドミニストレータがクオリティレビューモジュール１２６において検査するために、データセットのコピーがコックドデータベースに得られるようにされる。

復帰オペレーション１３６０は、制御をオペレーション５２４においてタスク５００へ復帰させ、これは、次いで、制御をオペレーション５２６へ移行し、ここでは、別の一連のルールベースタスクが遂行される。次いで、全体的な制御は、オペレーション５２８に復帰する。

ここに述べた機能的コンポーネント、モジュール、ソフトウェアエレメント、ハードウェアエレメント、並びに特徴及び機能は、ソフトウェア又はハードウェア等に固定されるものとして示され、又は説明されたが、当業者であれば、ここに述べる特徴及び機能は、種々のソフトウェア、ハードウェア及び／又はファームウェアの組み合せで実施されてもよく、且つここに述べる機能は、ここに述べるように１つの特定のコンポーネントに固定されずに、ネットワーク上の種々のコンポーネント又はサブコンポーネントに分散されてもよいことが明らかであろう。従って、ここに述べるデータベースは、ここに述べる特徴及び機能の実施者の好みに最も良く合うように、分離され、統合され、連合され、又はその他、構成されてもよい。又、手動で遂行されるのが好ましいとしてここに述べた機能は、手動で遂行されてもよいし、或いはサブタスクに分割されて、人間オペレータの対話に良く似たインテリジェントサブシステム、例えば、人間に操作によりトレーニングされて最終的に自律的に機能する人工インテリジェントシステムにより、自動化され、最終的に遂行されてもよい。更に別の特徴、機能、及び技術的仕様が、添付図面及び詳細な説明から明らかとなろう。

本発明の装置及び方法を、最も実際的で且つ好ましい実施形態と現在考えられるものについて説明したが、本発明は、これに限定されないことを理解されたい。本発明は、特許請求の範囲及びその精神の中に含まれる種々の変更及び同様の構成を包含するものであると広く解釈されたい。以上に取り上げた特許、特許出願、及び出版物は、全て、その全体が参考としてここに援用される。

本発明の一実施形態によるリスティングマネージメントプラットホームシステムの全ブロック図である。図１Ａのマネージメントプラットホームシステム内の例示的リスティングマネージメントモジュールの全機能的ブロック図である。図１に示すリスティングマネージメントモジュール内の各タスクマネージャーの全機能的ブロック図である。図１Ａ−１Ｃに示したマネージメントプラットホームシステムの一実施形態を使用するジョブサーチシステムの全ブロック図である。図２に示す例示的システムの実施形態に使用するユーザ（求職者）サーチ入力問合せインターフェイスを例示する図である。図２に示す例示的システムの実施形態に使用するユーザ（求職者）サーチ結果インターフェイスを例示する図である。図２に示すシステムを通る簡単なデータプロセスフローを示す図である。図１に示すシステムの実施形態におけるジョブカテゴリー分け制御モジュールを示す図である。図１Ｂに示すシステムの一実施形態によるジョブカテゴリー分けプロセスの動作フローチャートである。ジョブカテゴリー分けプロセスのための例示的ドキュメントカテゴリー分けプラットホームサービスユーザインターフェイスのスクリーンショットである。ジョブカテゴリー分け手動レビューインターフェイスモジュールに対するプロセスフローチャートである。ジョブカテゴリー分け手動レビューインターフェイスモジュールに対する例示的ユーザインターフェイスのスクリーンショットである。手動でレビューされているジョブ説明の例示的ユーザインターフェイスのスクリーンショットである。図１に示すシステムのデ・デューピングモジュールにおけるデ・デューピングプロセスのフローチャートである。図１Ｂ及び１Ｃに示されたクオリティエンジンプロセスのフローチャートである。クオリティマネージャーレポートを示すユーザインターフェイスの例示的スクリーンショットである。本発明の実施形態によるスクレープの機能図である。図１に示すシステムのレポートモジュールにおいて発生された産業レポートのスクリーンショットである。図１Ａのユーザアドミニストレーションモジュールに使用されるユーザインターフェイスのスクリーンショットである。図２に示すシステムにおいて２つのタスクマネージャー間でデータを共有するタスクマネージャーを示す図である。

Claims

サーチ可能なデータ構造体へコンパイルするために複数のソースからデータネットワークを経て捕獲されるリスティング情報データの捕獲及び処理を管理するコンピュータシステムにおいて、
ネットワークインターフェイスを通してシステム管理及びオペレーション制御を与えるアドミニストレーションポータルモジュールと、
前記アドミニストレーションポータルモジュールを経て与えられるインストラクションに応答して、前記ソースへのアクセスを制御し、リスティング情報データの検索を制御し、そしてこれらソースから受け取られたリスティング情報データを処理し、更に、リスティング情報データをカテゴリー分けし、そのカテゴリー分けされたリスティング情報データの部分を、所定のクオリティ基準への適合性について検査し、そしてそのカテゴリー分けされたリスティング情報データを使用のためにサーチバンクに記憶するように動作できる１つ以上のリスティングマネージャーモジュールと、
を備えたコンピュータシステム。
前記データネットワークは、インターネットである、請求項１に記載のシステム。
各々のリスティングマネージャーモジュールは、１つ以上のタスクマネージャーを含み、その各々は、
前記アドミニストレーションポータルモジュールにおいてサイトマネージメントモジュールにより識別されたサイトからスクレープされたデータセットを得、そしてそのスクレープされたデータセットをデータベースに記憶するために、１つ以上のスクレープエンジンのオペレーション及びそれらの間の通信を整合するスクレープマネージメントモジュールと、
前記スクレープマネージメントモジュールに結合され、前記データベースに記憶された各スクレープされたデータセットを、所定のクオリティ基準への適合性について分析するためのクオリティマネージメントモジュールと、
を含む請求項１に記載のシステム。
各タスクマネージャーモジュールは、更に、
前記データベースに記憶された各データセットを検査して、所定セットのカテゴリーの１つ以上へとカテゴリー分けし、そのカテゴリー分けされたデータセットを前記データベースへ返送するように動作できるリスティングデータカテゴリー分けモジュールと、
前記データベースからのカテゴリー分けされたデータセットをコンパイルしてサーチバンクへ転送するために前記データベースと通信するサーチバンクシンクロナイザーと、
を含む請求項３に記載のシステム。
前記カテゴリー分けモジュールは、
カテゴリー分けデータベースと、
各スクレープされたデータセットのテキストを、前記カテゴリー分けデータベースにおける以前にカテゴリー分けされたリスティングデータテキストと比較することにより、各スクレープされたリスティング情報データセットに対して各所定のカテゴリーの信頼値を決定するドキュメントカテゴリー分けプラットホームサービスと、
を含む請求項１に記載のシステム。
前記アドミニストレーションポータルは、レビューアが前記ドキュメントカテゴリー分けプラットホームサービスにより決定されたカテゴリーを検証するのを許すカテゴリー分けレビューモジュールを含む、請求項４に記載のシステム。
前記データベースへ返送される各データセットは、前記カテゴリー分けモジュールにより決定される指定のカテゴリーと、そのカテゴリーに対する指定の信頼値とを含む、請求項４に記載のシステム。
前記データベースへ返送される各データセットは、更に、各所定のカテゴリーに対する信頼値を含む、請求項７に記載のシステム。
前記データベースへ返送される各データセットは、前記指定の信頼値が所定のスレッシュホールド値より低い場合にセットされる手動レビューフラグを含む、請求項５に記載のシステム。
前記クオリティマネージメントモジュールは、所定の基準を満足しない各データセットに関連したクオリティフラグをセットする、請求項１に記載のシステム。
前記アドミニストレーションポータルは、更に、前記クオリティマネージメントモジュールと通信して、レビューアが、クオリティフラグがセットされたデータセットを手動で検査するのを許すクオリティレビューモジュールを含む、請求項１０に記載のシステム。
リスティングデータセットを得、取り扱い、そしてコンパイルする方法において、
インターネットを経て利用できる１つ以上のサイトにおいて１つ以上のリスティングからリスティング情報データセットを得るステップと、
各リスティングに対応するデータセットをデータベースに記憶するステップと、
前記データベースに記憶された各データセットを所定のクオリティ基準への適合性について分析するステップと、
前記データベースに記憶された各データセットを１つ以上の所定のカテゴリーへカテゴリー分けし、そのカテゴリー分けされたデータセットを前記データベースへ返送するステップと、
を備えた方法。
ＸＬＭフィードを通して１つ以上の顧客サイトからリスティング情報データセットを得るステップを更に備えた、請求項１２に記載の方法。
前記カテゴリー分け動作は、各々の所定のカテゴリーに対して各データセットの信頼値を指定することを更に含む、請求項１２に記載の方法。
前記カテゴリー分け動作は、
各得られたデータセットのテキストを、カテゴリー分けデータベースにおける以前にカテゴリー分けされたデータセットのテキストと比較する段階と、
各得られたデータセットに対して各所定のカテゴリーの信頼値を決定する段階と、
を含む請求項１２に記載の方法。
信頼値が手動レビューに対する所定値より低い各カテゴリー分けされたデータセットにフラグを立てるステップと、
レビューアがアドミニストレーションポータルを通してフラグの立ったカテゴリー分けを検証できるようにする手動レビューモジュールを用意するステップと、
を更に備えた請求項１５に記載の方法。
前記データベースへ返送される各データセットに指定されるカテゴリーに対して信頼値を指定するステップを更に備えた、請求項１２に記載の方法。
前記データベースへ返送されるデータセットであって、指定の信頼レベルが所定スレッシュホールドより低いデータセットにフラグを立てるステップを更に備えた、請求項１７に記載の方法。
ユーザによる問合せに応答して前記サーチバンクからウェブクライアントサーバークラスターを経てユーザへ選択されたカテゴリー分けされたデータセットを転送するステップを更に備えた、請求項１２に記載の方法。
前記得る動作は、更に、
インターネットを通して１つ以上のサイトにアクセスする段階と、
前記１つ以上のサイトからリスティングデータセットをスクレープする段階と、
所定のクオリティ基準を満足しないスクレープされたデータセットにフラグを立てる段階と、
前記データベースへ返送されるフラグの立てられたデータセットの手動レビューを許す段階と、
を含み、そして前記カテゴリー分け動作は、
各スクレープされたデータセットのデータを、カテゴリー分けデータベース内の以前にカテゴリー分けされたデータセットのデータと比較する段階と、
各スクレープされたデータセットに対して各所定のカテゴリーの信頼値を決定する段階と、
を含む請求項１２に記載の方法。
信頼値が手動レビューに対する所定値より低い各カテゴリー分けされスクレープされたデータセットにフラグを立てる段階と、
レビューアがフラグの立ったカテゴリー分けを検証できるようにする手動レビューモジュールをアドミニストレーションポータルに用意するステップと、
を更に備えた請求項２０に記載の方法。
ユーザによる問合せに応答して、前記サーチバンクからウェブサーバーを経てユーザへ選択されたカテゴリー分けされたデータセットを転送する段階を更に備えた、請求項２０に記載の方法。
リスティングデータを得て処理するためのコンピュータプロセスを実行するインストラクションのコンピュータプログラムをエンコードするコンピュータ読み取り可能なメディアにおいて、前記コンピュータプロセスは、
インターネットを通して利用できるサイトにおいて１つ以上のリスティングからリスティング情報データをスクレープし、
各スクレープされたリスティング情報に対応するスクレープされたデータセットをデータベースに記憶し、
前記データベースに記憶された各スクレープされたデータセットを、所定のクオリティ基準への適合性について分析し、そして
前記データベースに記憶された各データセットを１つ以上の所定のカテゴリーへとカテゴリー分けし、そのカテゴリー分けされたデータセットを前記データベースへ返送する、
ことを含むものである、コンピュータ読み取り可能なメディア。
前記プロセスは、更に、
所定のクオリティ基準を満足しないスクレープされたデータセットにフラグを立て、
前記データベースへ返送されるフラグの立てられたデータセットの手動レビューを許す、ことを含み、そして前記カテゴリー分け動作は、更に、
各スクレープされたデータセットのデータを、カテゴリー分けデータベース内の以前にカテゴリー分けされたデータセットのデータと比較し、
各スクレープされたデータセットに対して各所定のカテゴリーの信頼値を決定する、
ことを含む請求項２３に記載のコンピュータ読み取り可能なメディア。
サーチ可能なデータ構造体へコンパイルするために複数のジョブ関連ソースからデータネットワークを経て捕獲されるジョブリスティング情報データの捕獲及び処理を管理するコンピュータシステムにおいて、
ネットワークインターフェイスを通してシステムアドミニストレーション及びオペレーション制御を与えるアドミニストレーションポータルモジュールと、
前記アドミニストレーションポータルモジュールを経て与えられるインストラクションに応答して、前記ジョブ関連ソースへのアクセスを制御し、ジョブリスティング情報データの検索を制御し、そしてこれらソースから受け取られたジョブ情報データセットを処理し、更に、ジョブリスティング情報データセットをカテゴリー分けし、そのカテゴリー分けされたジョブ情報データセットの部分を、所定のクオリティ基準への適合性について検査し、そしてそのカテゴリー分けされたジョブ情報データセットを使用のためにジョブサーチバンクに記憶するように動作できる１つ以上のタスクマネージャーモジュールと、
を備えたコンピュータシステム。
前記データネットワークは、インターネットを含む、請求項２５に記載のシステム。
各タスクマネージャーモジュールは、
会社の経歴サイトからのスクレープされたジョブ情報データセットと、前記アドミニストレーションポータルモジュールにおいてサイトマネージメントモジュールにより識別されるジョブボードとを得て、前記スクレープされたデータセットをデータベースに記憶するために、１つ以上のジョブスクレープエンジンのオペレーション及びそれらの間の通信を整合するスクレープマネージメントモジュールと、
前記スクレープマネージメントモジュールに結合され、前記データベースに記憶された各スクレープされたジョブデータセットを、所定のクオリティ基準への適合性について分析するためのクオリティマネージメントモジュールと、
を含む請求項２５に記載のシステム。
前記タスクマネージャーモジュールは、更に、
前記データベースに記憶された各ジョブデータセットを検査して、所定セットのジョブカテゴリーの１つ以上へとカテゴリー分けし、そのカテゴリー分けされたジョブデータセットを前記データベースへ返送するように動作できるジョブリスティングデータカテゴリー分けモジュールと、
前記データベースからのカテゴリー分けされたジョブデータセットをコンパイルして、ジョブサーチバンクへ転送するために前記データベースと通信するサーチバンクシンクロナイザーと、
を含む請求項２７に記載のシステム。
前記カテゴリー分けモジュールは、
ジョブカテゴリー分けデータベースと、
各スクレープされたジョブデータセットのテキストを、前記ジョブカテゴリー分けデータベースにおける以前にカテゴリー分けされたジョブデータのテキストと比較することにより、各スクレープされたジョブリスティング情報データセットに対して各所定のジョブカテゴリーの信頼値を決定するカテゴリー分けモジュールと、
を含む請求項２５に記載のシステム。
前記アドミニストレーションポータルは、レビューアがドキュメントカテゴリー分けプラットホームサービスにより決定されたカテゴリーを検証するのを許すカテゴリー分けレビューモジュールを含む、請求項２８に記載のシステム。
前記データベースへ返送される各ジョブデータセットは、前記カテゴリー分けモジュールにより決定される指定のジョブカテゴリーと、そのカテゴリーに対する指定の信頼値とを含む、請求項２８に記載のシステム。
前記データベースへ返送される各データセットは、更に、各所定のジョブカテゴリーに対する信頼値を含む、請求項３１に記載のシステム。
前記データベースへ返送される各ジョブデータセットは、前記指定の信頼値が所定のスレッシュホールド値より低い場合にセットされる手動レビューフラグを含む、請求項２９に記載のシステム。
前記クオリティマネージメントモジュールは、所定の基準を満足しない各スクレープされたデータセットに関連したクオリティフラグをセットする、請求項２５に記載のシステム。
前記アドミニストレーションポータルは、更に、前記クオリティマネージメントモジュールと通信して、レビューアが、クオリティフラグがセットされたジョブデータセットを手動で検査するのを許すクオリティレビューモジュールを含む、請求項３４に記載のシステム。
ジョブ情報データセットを得、取り扱い、そしてコンパイルする方法において、
インターネットを通して利用できる１つ以上の会社経歴サイト又はジョブボードにおいて１つ以上のジョブリスティングからジョブ情報データセットをスクレープするステップと、
見つかった各スクレープされたジョブリスティングに対応するジョブデータセットをデータベースに記憶するステップと、
前記データベースに記憶された各スクレープされたデータセットを所定のクオリティ基準への適合性について分析するステップと、
前記データベースに記憶された各データセットを１つ以上の所定のジョブカテゴリーへカテゴリー分けし、そのカテゴリー分けされたジョブ情報データセットを前記データベースへ返送するステップと、
を備えた方法。
ＸＬＭフィードを通して１つ以上の顧客サイトからジョブ情報データセットを得るステップを更に備えた、請求項３６に記載の方法。
前記カテゴリー分け動作は、各々の所定のジョブカテゴリーに対して各ジョブ情報データセットの信頼値を指定することを更に含む、請求項３６に記載の方法。
前記カテゴリー分け動作は、
各スクレープされたジョブ情報データセットのテキストを、ジョブカテゴリー分けデータベースにおける以前にカテゴリー分けされたジョブ情報データセットのテキストと比較する段階と、
各スクレープされたデータセットに対して各所定のカテゴリーの信頼値を決定する段階と、
を含む請求項３６に記載の方法。
信頼値が手動レビューに対する所定値より低い各カテゴリー分けされたスクレープされたデータセットにフラグを立てるステップと、
レビューアがアドミニストレーションポータルを通してフラグの立ったカテゴリー分けを検証できるようにする手動レビューモジュールを用意するステップと、
を更に備えた請求項３９に記載の方法。
前記データベースへ返送される各データセットに指定されるジョブカテゴリーに対して信頼値を指定するステップを更に備えた、請求項３６に記載の方法。
前記データベースへ返送されるデータセットであって、指定の信頼レベルが所定スレッシュホールドより低いデータセットにフラグを立てるステップを更に備えた、請求項４１に記載の方法。
求職者による問合せに応答して前記ジョブサーチバンクからウェブクライアントサーバークラスターを経て求職者へ選択されたカテゴリー分けされたジョブ情報データセットを転送するステップを更に備えた、請求項３６に記載の方法。
前記スクレーピング動作は、更に、
インターネットを通してジョブボード又は会社の経歴サイトの１つにアクセスする段階と、
所定のクオリティ基準を満足しないスクレープされたジョブ情報データセットにフラグを立てる段階と、
前記データベースへ返送されるフラグの立てられたジョブ情報データセットの手動レビューを許す段階と、
を含み、そして前記カテゴリー分け動作は、
各スクレープされたジョブ情報データセットのデータを、カテゴリー分けデータベース内の以前にカテゴリー分けされたジョブデータセットのデータと比較する段階と、
各スクレープされたジョブ情報データセットに対して各所定のジョブカテゴリーの信頼値を決定する段階と、
を含む請求項３６に記載の方法。
信頼値が手動レビューに対する所定値より低い各カテゴリー分けされスクレープされたデータセットにフラグを立てる段階と、
レビューアがフラグの立ったカテゴリー分けを検証できるようにする手動レビューモジュールをアドミニストレーションポータルに用意するステップと、
を更に備えた請求項４４に記載の方法。
ユーザによる問合せに応答して、前記サーチバンクからウェブサーバーを経てユーザへ選択されたカテゴリー分けされたデータセットを転送する段階を更に備えた、請求項４４に記載の方法。
会社の経歴サイト及びジョブボードからジョブ説明データをスクレープするためのコンピュータプロセスを実行するインストラクションのコンピュータプログラムをエンコードするコンピュータ読み取り可能なメディアにおいて、前記コンピュータプロセスは、
インターネットを通して利用できるサイトにおいて１つ以上のリスティングからリスティング情報データをスクレープし、
各スクレープされたリスティング情報に対応するスクレープされたデータセットをデータベースに記憶し、
前記データベースに記憶された各スクレープされたデータセットを、所定のクオリティ基準への適合性について分析し、そして
前記データベースに記憶された各データセットを１つ以上の所定のカテゴリーへとカテゴリー分けし、そのカテゴリー分けされたデータセットを前記データベースへ返送する、
ことを含むものである、コンピュータ読み取り可能なメディア。
前記プロセスは、更に、
所定のクオリティ基準を満足しないスクレープされたデータセットにフラグを立て、
前記データベースへ返送されるフラグの立てられたデータセットの手動レビューを許す、ことを含み、そして前記カテゴリー分け動作は、更に、
各スクレープされたデータセットのテキストを、カテゴリー分けデータベース内の以前にカテゴリー分けされたデータセットのテキストと比較し、
各スクレープされたデータセットに対して各所定のカテゴリーの信頼値を決定する、
ことを含む請求項４７に記載のコンピュータ読み取り可能なメディア。
サーチ可能なデータ構造体へコンパイルするために複数のジョブ関連ソースからデータネットワークを経て捕獲されるジョブリスティング情報データの捕獲及び処理を管理するコンピュータシステムにおいて、
ネットワークインターフェイスを通してシステムアドミニストレーション及びオペレーション制御を与えるアドミニストレーションポータルモジュールと、
前記アドミニストレーションポータルモジュール内でサイトマネージメントモジュールにより識別された会社の経歴サイト及びジョブボードからスクレープされたジョブ情報データセットを得、そしてそのスクレープされたデータセットをデータベースに記憶するために、１つ以上のジョブスクレーピングエンジンのオペレーション及びそれらの間の通信を整合するスクレーピングマネージメントモジュールと、
前記データベースに記憶された各ジョブデータセットを検査して、所定セットのジョブカテゴリーの１つ以上へとカテゴリー分けし、そしてそのカテゴリー分けされたジョブデータセットを前記データベースに返送するように動作できるジョブリスティングデータカテゴリー分けモジュールと、
前記スクレーピングマネージメントモジュールに結合され、前記データベースに記憶された各スクレープされたジョブデータセットを、所定のクオリティルールへの適合性について分析するクオリティマネージメントモジュールと、
を備えたコンピュータシステム。
前記データネットワークは、インターネットを含む、請求項４９に記載のシステム。
前記データベースと通信し、前記データベースからのカテゴリー分けされたジョブデータセットをコンパイルしてジョブサーチバンクへ転送するためのサーチバンクシンクロナイザーを更に備えた、請求項４９に記載のシステム。
前記カテゴリー分けモジュールは、
ジョブカテゴリー分けデータベースと、
各スクレープされたジョブデータセットのテキストを、前記ジョブカテゴリー分けデータベースにおける以前にカテゴリー分けされたジョブデータのテキストと比較することにより、各スクレープされたジョブリスティング情報データセットに対して各所定のジョブカテゴリーの信頼値を決定するカテゴリー分けモジュールと、
を含む請求項５１に記載のシステム。
前記アドミニストレーションポータルは、レビューアが前記カテゴリー分けモジュールにおいてドキュメントカテゴリー分けプラットホームサービスにより決定されたカテゴリーを検証するのを許すカテゴリー分けレビューモジュールを含む、請求項５２に記載のシステム。
前記データベースへ返送される各ジョブデータセットは、前記カテゴリー分けモジュールにより決定される指定のジョブカテゴリーと、そのカテゴリーに対する指定の信頼値とを含む、請求項５２に記載のシステム。
前記データベースへ返送される各データセットは、更に、各所定のジョブカテゴリーに対する信頼値を含む、請求項５４に記載のシステム。
前記データベースへ返送される各ジョブデータセットは、前記指定の信頼値が所定のスレッシュホールド値より低い場合にセットされる手動レビューフラグを含む、請求項５２に記載のシステム。
前記アドミニストレーションポータルは、レビューアが前記カテゴリー分けモジュールにより決定されたカテゴリー分けを検証するのを許すカテゴリー分けレビューモジュールを含む、請求項５６に記載のシステム。
前記クオリティマネージメントモジュールは、所定の基準を満足しない各スクレープされたジョブデータセットに関連したクオリティフラグをセットする、請求項４９に記載のシステム。
前記アドミニストレーションポータルは、更に、前記クオリティマネージメントモジュールと通信して、レビューアが、クオリティフラグがセットされたジョブデータセットを手動で検査するのを許すクオリティレビューモジュールを含む、請求項５８に記載のシステム。
ジョブ情報データセットを得、取り扱い、そしてコンパイルする方法において、
インターネットを通して利用できる１つ以上の会社経歴サイト又はジョブボードにおいて１つ以上のジョブリスティングからジョブ情報データセットをスクレープするステップと、
見つかった各スクレープされたジョブリスティングに対応するジョブデータセットをデータベースに記憶するステップと、
前記データベースに記憶された各スクレープされたデータセットを所定のクオリティ基準への適合性について分析するステップと、
前記データベースに記憶された各データセットを１つ以上の所定のジョブカテゴリーへカテゴリー分けし、そのカテゴリー分けされたジョブ情報データセットを前記データベースへ返送するステップと、
を備えた方法。
ＸＬＭフィードを通して１つ以上の顧客サイトからジョブ情報データセットを得るステップを更に備えた、請求項６０に記載の方法。
前記カテゴリー分け動作は、更に、所定のジョブカテゴリー各々に対して各ジョブ情報データセットの信頼値を指定することを含む、請求項６０に記載の方法。
前記カテゴリー分け動作は、
各スクレープされたジョブ情報データセットのテキストを、ジョブカテゴリー分けデータベースにおける以前にカテゴリー分けされたジョブ情報データセットのテキストと比較する段階と、
各スクレープされたデータセットに対して各所定のカテゴリーの信頼値を決定する段階と、
を含む請求項６０に記載の方法。
信頼値が手動レビューに対する所定値より低い各カテゴリー分けされたスクレープされたデータセットにフラグを立てるステップと、
レビューアがアドミニストレーションポータルを通してフラグの立ったカテゴリー分けを検証できるようにする手動レビューモジュールを用意するステップと、
を更に備えた請求項６３に記載の方法。
前記データベースへ返送される各データセットに指定されるジョブカテゴリーに対して信頼値を指定するステップを更に備えた、請求項６０に記載の方法。
前記データベースへ返送されるデータセットであって、指定の信頼レベルが所定スレッシュホールドより低いデータセットにフラグを立てるステップを更に備えた、請求項６５に記載の方法。
求職者による問合せに応答して前記ジョブサーチバンクからウェブクライアントサーバークラスターを経て求職者へ選択されたカテゴリー分けされたジョブ情報データセットを転送するステップを更に備えた、請求項６０に記載の方法。
前記スクレーピング動作は、更に、
インターネットを通してジョブボード又は会社の経歴サイトの１つにアクセスする段階と、
所定のクオリティ基準を満足しないスクレープされたジョブ情報データセットにフラグを立てる段階と、
前記データベースへ返送されるフラグの立てられたジョブ情報データセットの手動レビューを許す段階と、
を含み、そして前記カテゴリー分け動作は、
各スクレープされたジョブ情報データセットのデータを、カテゴリー分けデータベース内の以前にカテゴリー分けされたジョブデータセットのデータと比較する段階と、
各スクレープされたジョブ情報データセットに対して各所定のジョブカテゴリーの信頼値を決定する段階と、
を含む請求項６０に記載の方法。
信頼値が手動レビューに対する所定値より低い各カテゴリー分けされスクレープされたデータセットにフラグを立てる段階と、
レビューアがフラグの立ったカテゴリー分けを検証できるようにする手動レビューモジュールをアドミニストレーションポータルに用意するステップと、
を更に備えた請求項６８に記載の方法。
ユーザによる問合せに応答して、前記サーチバンクからウェブサーバーを経てユーザへ選択されたカテゴリー分けされたデータセットを転送する段階を更に備えた、請求項６８に記載の方法。
会社の経歴サイト及びジョブボードからジョブ説明データをスクレープするためのコンピュータプロセスを実行するインストラクションのコンピュータプログラムをエンコードするコンピュータ読み取り可能なメディアにおいて、前記コンピュータプロセスは、
インターネットを通して利用できるサイトにおいて１つ以上のリスティングからリスティング情報データをスクレープし、
各スクレープされたリスティング情報に対応するスクレープされたデータセットをデータベースに記憶し、
前記データベースに記憶された各スクレープされたデータセットを、所定のクオリティ基準への適合性について分析し、そして
前記データベースに記憶された各データセットを１つ以上の所定のカテゴリーへとカテゴリー分けし、そのカテゴリー分けされたデータセットを前記データベースへ返送する、
ことを含むものである、コンピュータ読み取り可能なメディア。
前記プロセスは、更に、
所定のクオリティ基準を満足しないスクレープされたデータセットにフラグを立て、
前記データベースへ返送されるフラグの立てられたデータセットの手動レビューを許す、ことを含み、そして前記カテゴリー分け動作は、更に、
各スクレープされたデータセットのテキストを、カテゴリー分けデータベース内の以前にカテゴリー分けされたデータセットのテキストと比較し、
各スクレープされたデータセットに対して各所定のカテゴリーの信頼値を決定する、
ことを含む請求項７１に記載のコンピュータ読み取り可能なメディア。