コプロセッサを使った構造化データおよび非構造化データの高性能の統合、処理および探索の方法およびシステム
ユーザおよび企業体アプリケーションに、企業体の構造化データおよび非構造化データへの効率的で、インテリジェントなアクセスを提供するためにそれらのデータを統合する方法およびシステムが本明細書で開示される。ＳＱＬコマンドなどの標準化データベース問い合わせ形式を使って、企業体の構造化と非構造化データの両方に問い合わせを向けることができる。問い合わせを処理する必要に応じて、コプロセッサを使い、非構造化データに対する（全文検索などの）データ処理タスクをハードウェアアクセラレートすることができる。さらに、ハードウェアアクセラレートされたデータ処理のために企業体の非構造化データのどの部分がコプロセッサに送られるべきか判定するために、従来の関係データベース技術を使って、関係データベースによって格納されている構造化データにアクセスすることもできる。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照および優先権主張）
本出願は、参照によりその開示全体が本明細書に組み込まれる、２００６年１１月１３日に出願された、米国仮特許出願第６０／８６５６２９号の優先権を主張するものである。
【０００２】
本出願は、参照によりその開示全体が本明細書に組み込まれる、（Ｔｈｏｍｐｓｏｎ Ｃｏｂｕｒｎ代理人整理番号４４８２６−６５５９２により識別される）「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｄａｔａ Ｍｅｔａｔａｇｇｉｎｇ ａｎｄ Ｄａｔａ Ｉｎｄｅｘｉｎｇ Ｕｓｉｎｇ Ｃｏｐｒｏｃｅｓｓｏｒｓ」という名称の、本出願と同日に出願された、米国特許出願第＿＿＿＿＿号に関連するものである。
【０００３】
本発明は、一般に、データベースアクセラレーションの分野を対象とし、詳細には、企業体データ探索、ドキュメントウェアハウス、テキストマイニング、テキスト解析、情報アクセス、アクショナブルインテリジェンス（ａｃｔｉｏｎａｂｌｅ ｉｎｔｅｌｌｉｇｅｎｃｅ、活用可能な形の情報）の実現といった領域を含む企業データウェアハウスアクセラレーションを対象とする。
【背景技術】
【０００４】
（用語）
以下の各項に、本明細書で使用する様々な用語のいくつかの定義を示す。また以下の項には、これらの用語に関連する背景情報も示す。
【０００５】
ＧＰＰ：本明細書で使用する場合、「汎用プロセッサ」（またはＧＰＰ）という用語は、固定された形態を有し、その機能が可変であり、この可変機能が、命令を取り出し、その命令を実行することによって定義されるハードウェア装置（例えば、ＩｎｔｅｌのＸｅｏｎプロセッサやＡＭＤのＯｐｔｅｒｏｎプロセッサなど）をいい、従来の中央処理装置（ＣＰＵ）がその一般的な例である。
【０００６】
再構成可能論理：本明細書で使用する場合、「再構成可能論理」という用語は、その形態および機能を、製造後に現場で大幅に変更（すなわち再構成）することのできる任意の論理技術をいう。これはＧＰＰと対比されるものであり、ＧＰＰの機能は製造後に変化し得るが、その形態は製造時に固定されている。
【０００７】
ソフトウェア：本明細書で使用する場合、「ソフトウェア」という用語は、ＧＰＰまたは他の処理装置上で展開されるデータ処理機能をいい、ソフトウェアは、ソフトウェアがロードされる装置の形態を変更し、または定義するのに使用することはできない。
【０００８】
ファームウェア：本明細書で使用する場合、「ファームウェア」という用語は、再構成可能論理または他の処理装置上で展開されるデータ処理機能をいい、ファームウェアは、ファームウェアがロードされる装置の形態を変更し、または定義するのに使用され得る。
【０００９】
コプロセッサ：本明細書で使用する場合、「コプロセッサ」という用語は、主プロセッサを有する計算処理システムにおいて、他の構成要素と連携して動作するように設計された計算エンジンをいう（マルチコアプロセッサアーキテクチャの場合のように、主プロセッサ自体が複数のプロセッサを備えてもよい）。典型的には、コプロセッサは、特定のタスク集合を実行するように最適化され、システム性能を最適化するために（典型的にはＧＰＰである）主プロセッサのタスクを軽減するのに使用される。コプロセッサによって実行されるタスクの範囲は、コプロセッサのアーキテクチャに応じて、固定とすることも、可変とすることもできる。固定式コプロセッサアーキテクチャの例には、広範囲のタスクを実行するグラフィックスプロセッサユニットや、比較的狭い範囲のタスク集合を実行する浮動小数点数値コプロセッサが含まれる。再構成可能コプロセッサアーキテクチャの例には、幅広い種類の固定型の、またはプログラム可能な計算エンジンを実施するように再構成され得る、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能論理回路が含まれる。コプロセッサの機能は、ソフトウェアおよび／またはファームウェアによって定義されてもよい。
【００１０】
ハードウェアアクセラレーション：本明細書で使用する場合、「ハードウェアアクセラレーション」という用語は、主プロセッサから１つまたは複数の処理タスクを軽減して主プロセッサに関連したこれらのタスクの処理待ち時間を低減するために、コプロセッサ上に実施されたソフトウェアおよび／またはファームウェアを使用することをいう。
【００１１】
企業体：本明細書で使用する場合、「企業体」という用語は、その進行中の業務の一部として（「企業体データ」と呼ばれる）データを格納し、かつ／または処理する任意の事業組織または行政主体をいう。
【００１２】
データベース：本明細書で使用する場合、「データベース」という用語は、問い合わせ処理を迅速化するための索引付け機能を有する永続的データストアをいう。様々なデータベース管理システム（ＤＢＭＳ）実装形態が、関係型（ＲＤＢＭＳ）、オブジェクト指向型（ＯＯＤＢＭＳ）、階層型などとして類別され得る。しかし、今日業界において優勢なアーキテクチャは関係型の、行／列からなる、構造化照会言語（ＳＱＬ）対応データベースである。ＡＮＳＩ標準のＳＱＬデータベースエンジンは、普通は効率的な方法で、問い合わせに応答して構造化データを検索することのできる、成熟したソフトウェアアーキテクチャである。
【００１３】
構造化データ：本明細書で使用する場合、「構造化データ」という用語は、関係データベースに合わせて正規化され、永続化されているデータをいう。正規化とは、データを表の行／列形式にし、重複データを別々の表に抽出するデータ設計プロセスである。関係列内の構造化データには、Ｂツリー索引を用いて索引付けして、これらの列内のデータへのアクセスを大幅に迅速化することができる。ＳＱＬでは、構造化列にはサイズ限界がある。これらの列には、一貫性のあるデータ品質を保証するための制約条件および参照整合性が適用され得る。一般的な構造化ＳＱＬデータ型の例は、ＩＮＴ（ｅｇｅｒ）、ＮＵＭＢＥＲ、ＣＨＡＲ（ａｃｔｅｒ）、ＶＡＲＣＨＡＲ、ＤＡＴＥ、ＴＩＭＥＳＴＡＭＰなどである。構造化データの処理は、周知の関係データベース技術が適するものである。非常に重要なことに、本発明は、これらの機能を活用して、関係データベースが最も得意とすること、すなわち、索引付きルックアップを使った構造化データへの迅速なアクセスを行う。
【００１４】
非構造化データ：本明細書で使用する場合、「非構造化データ」という用語は、前記の構造化データの定義の範囲に入らないデータをいう。したがって、非構造化データという用語は、自由な形のテキストまたは埋込み値が含まれているファイル、ドキュメントまたはオブジェクトを含む。このデータは、データを生成したアプリケーションによって使用された、しばしばバイナリ形式のデータを含む、完全なバイト集合を含む。非構造化データの例には、ワードプロセッシングドキュメント（Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄの固有の形式のドキュメントなど）、Ａｄｏｂｅ Ａｃｒｏｂａｔドキュメント、電子メール、画像ファイル、映像ファイル、オーディオファイル、およびファイルを作成したソフトウェアアプリケーションに関連する固有の形式の他のファイルなどが含まれる。ＳＱＬでは、非構造化列は、無制限ではないにせよ、非常に大きいサイズを有する。非構造化ＳＱＬデータ型の一般的な例は、ＢＬＯＢ、ＴＥＸＴ、ＸＭＬ、ＲＡＷ、ＩＭＡＧＥなどである。また、非構造化オブジェクトは、データベースの外部に、例えばオペレーティングシステムファイルなどに格納されてもよい。データベースエンジン内からこれらの外部オブジェクトへのアクセスには、データベース表のメタデータ内の格納場所へのリンクを使用する。
【００１５】
本明細書で使用する際に、ＸＭＬという用語を通常は「構造化」として類別しない理由には以下のものがある：
・ＸＭＬは、大きな値、またはサイズが無制限の値を持ち得る。
・ＸＭＬは、しばしば、強制されたデータ型を持たないことがある。
・ＸＭＬは柔軟なスキーマを有する。
・要素および属性のＸＭＬ値は、しばしば、従来の「構造化」データベース列ほど厳格に適合されず、不要なものが完全に除去されていないことがある。
【００１６】
柔軟なスキーマを有する「半構造化」データの概念が、特にＸＭＬについては台頭しつつあるが、本発明では、関係データベースに合わせて正規化され、永続化されていないあらゆるものは、非構造化データとみなす。したがって、ＸＭＬデータ型のものである列は、この「非構造化データ」の定義に該当することになる。ＸＭＬデータは、本発明で概説するハードウェアアクセラレートされた探索および統合の最有力候補である。
【００１７】
メタデータ：本明細書で使用する場合、データオブジェクトおよびドキュメントの文脈における「メタデータ」という用語は、データオブジェクトまたはドキュメントを記述し、または特徴付けるデータをいう。オブジェクトおよびドキュメントのメタデータの例には、それだけに限らないが、ファイル型、バイトサイズ、作成日、最終変更日、著者、表題、ドキュメント／オブジェクトのデータソースに関する情報（任意選択で、ドキュメントを作成するのに使用されたプログラムの名称およびバージョン番号を含む）、データが他のデータとマッチするかどうかに関する情報、主題対象、分類情報（ドキュメント／オブジェクトの概念に関する情報、ドキュメント／データオブジェクト内に含まれる人名／地名／企業名、語数カウントなど）、ドキュメント／オブジェクト内のデータに関連する位置情報、ドキュメント／オブジェクトに関する他の内容から派生する情報が含まれる。
【００１８】
バス：本明細書で使用する場合、「バス」という用語は、装置および場所がそのアドレスによりアクセスされる任意の物理的相互接続を含む論理バスをいう。本発明の実施に際して使用され得るバスの例には、それだけに限らないが、ＰＣＩバスファミリ（ＰＣＩ−ＸやＰＣＩ−Ｅｘｐｒｅｓｓなど）およびＨｙｐｅｒＴｒａｎｓｐｏｒｔバスが含まれる。
【００１９】
パイプライン化：本明細書で使用する場合、「パイプライン」、「パイプライン化シーケンス」、または「連鎖」という用語は、あるアプリケーションモジュールの出力が、シーケンス内の次のアプリケーションモジュールの入力に接続されているアプリケーションモジュールの配列をいう。このパイプライン化配列は、各アプリケーションモジュールが、所与のクロックサイクルの間に受け取る任意のデータを独立に操作し、次いで、別のクロックサイクルの間にその出力をシーケンス内の次の下流側アプリケーションモジュールに渡すことを可能にする。
【００２０】
全文検索：本明細書で使用する場合、「全文検索」という用語は、ドキュメントまたはオブジェクトの全体を通してスキャンし、あらゆる単語またはバイトを考慮することをいう。この処理は、近似、柔軟なスキーマでのタグ付けに基づくトークン化、ワイルドカード処理、または複雑なマッチングを可能にし得る。
【００２１】
ＳＱＬ対応クライアントアプリケーション：本明細書で使用する場合、クライアントアプリケーションの文脈における「ＳＱＬ対応の」という用語は、関係型のＳＱＬベースのデータベースサーバにアクセスすることのできるクライアントアプリケーションをいう。ＡＮＳＩ標準のＳＱＬ言語は、いずれも関係型のＳＱＬベースのデータベースサーバにアクセスすることのできる、多数の高度なソフトウェアクライアントアプリケーションの進化を可能にしている。これらのＳＱＬ対応クライアントアプリケーションの例には、ビジネスインテリジェンス（ＢＩ）報告ツール、抽出転送ロード（ＥＴＬ）ツール、企業体用ソフトウェアアプリケーション（ＥＲＰ、ＣＲＭ、ＳＡＰ）、ミドルウェア、および様々なプログラミング言語で書かれた多数の任意の特注アプリケーションなどが含まれる。
【００２２】
ビジネスインテリジェンス報告ツール：本明細書で使用する場合、「ビジネスインテリジェンス報告ツール」（または「ＢＩ報告ツール」）という用語は、関係データベースへの探索問い合わせを作成し、報告書を生成、提示するための、ユーザが使いやすいグラフィカルインターフェース（ＧＵＩ）を提供するソフトウェアアプリケーションをいう。ＢＩ報告ツールは、ユーザ指定の図形的に作成された問い合わせを、ＳＱＬコマンドなどの標準化データベース問い合わせに変換する。次いで、そのように作成されたＳＱＬコマンドが、所望のデータの検索を実行するためにＲＤＢＭＳに送られる。
【００２３】
テキスト解析およびテキストマイニング：本明細書で使用する場合、「テキスト解析」および「テキストマイニング」という用語は、意味論のような複雑な言語概念を使ってドキュメントオブジェクトを操作するアルゴリズムをいう。テキスト解析／テキストマイニング処理の例には、名前付きエンティティ認識、内容抽出、ドキュメント分類、ドキュメント要約、自然言語処理、統計パターン学習、および関連性ランク付けが含まれる。
【００２４】
企業体はそのデータを多種多様な方法で格納、管理し続ける。企業体がそのデータを格納するための１つの方法が、関係データベース管理システム（ＲＤＢＭＳ）を使ったデータベース内に格納するものである。このようなＲＤＢＭＳに格納された、表形式の正規化されたデータを一般に構造化データという。例えば企業体は、その売上記録および顧客情報を、書式設定し、不要な情報を除去し、適合させ、構造化データとしてＲＤＢＭＳ内に格納する。当分野では、典型的には構造化照会言語（ＳＱＬ）などの標準化データ言語に基づいてこのような構造化データにインテリジェントにアクセスするための様々な公知のツールが開発されている。
【００２５】
しかし一般にこのような表形式の構造化データは、企業体の格納データ全体のごくわずかな部分を表すにすぎないものであると推定される。格納データの残りの部分は典型的には、その記憶が企業体内の多種多様なファイルシステムおよび記憶手段の間に拡散しているのが普通である非構造化データで構成されている。非構造化オブジェクトおよびドキュメントの爆発的増加により、多くの企業体が深刻な「情報過負荷」状態に陥っている。このすべての構造化データおよび非構造化データにインテリジェントに、統合的にアクセスすることは、難しい課題を提起する。この課題を難しくする一因は、多くの企業体では、企業体の非構造化データの記憶が各データベースから、しばしば異なる組織部門によって別々に管理されていることである。多くの組織が直面している大きな課題が、その関係データベース内の構造化データを、ＢＬＯＢを含む、この比較的整理されていない大量の他の非構造化データと効率よく、効果的に統合することである。構造化データは、テキスト解析を使って、「なにが？」、「どこで？」、「いつ？」、「だれが？」のような比較的単純明快な質問への回答を提供することができ、非構造化データは「なぜ？」のようなより複雑な質問に回答することができる。
【００２６】
図１にこの問題を示す。多くの企業体では、すべてのドキュメントが、企業体全体に広がっているいくつかの別々のサーバの間のどこに位置しているかに関しての整理がほとんど行われていない。例えば、企業体がそのデータを格納するための記憶空間１０２は、ドキュメント管理システムＡ１０４、ネットワークファイルサーバＢ１０６、アプリケーションサーバＣ１０８といった別々の構成要素の間に拡散している。この記憶空間内の所望のドキュメントにアクセスし、所望のドキュメントを探し出すために、ユーザ１００は、異なる各構成要素にアクセスするのに異なるツールを使用せざるを得なくなる可能性が高い（例えば、システム１０４にアクセスするのにカスタムアプリケーションを使用し、サーバ１０６にアクセスするのにＷｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒなどのソフトウェア製品を使用し、サーバＣにアクセスするのにカスタムアプリケーションプログラミングインターフェース（ＡＰＩ）を使用するなど）。インターネット１１０上でデータの探索を行うには、さらに別のツール（Ｇｏｏｇｌｅなどのウェブサーチツール）が使用される可能性が高いはずである。このようにドキュメントの場所およびアクセス手段が乱雑な寄せ集めになっていると、ユーザは、記憶空間１０２内のどこに目的のドキュメントが位置しているか熟知していなければならないだけでなく、異種の構成要素１０４、１０６および１０８にアクセスするためのいくつかの異なるツールの使い方にも習熟していなければならない。しかも、図１に示すような企業体探索機能によってユーザは、関係データベース内に格納されている他の企業体データに直接アクセスし、これらと自分の探索を相関させることができない。
【００２７】
ユーザの探索が何らかの形の全文検索を含むとき、このような全文照会をサポートするソフトウェアはしばしば、特に問い合わせが多くの長いドキュメントの本文全体をスキャンすることを必要とするときには、完了するのに比較的長い時間を要する。これが遅いのは、一部には、従来のソフトウェアを実行するときの汎用プロセッサ（ＧＰＰ）の性能に関する固有の制約条件のためである。現在の索引付け法には、「発見能力（ｆｉｎｄ−ａｂｉｌｉｔｙ）」の実現に大きな限界がある。索引付けは関連するドキュメントを探し出すのに幾分役立つこともあるが、つづり間違い、交替するつづりの変形、正規表現を探索するタスク、または多数の用語を探索するタスクは、現在の索引付け法では容易にも、迅速にも解決されない問題であり、効果的な索引を作成するための時間に対応できなくなることが多い。言い換えると、何かの発見に役立つ効果的な索引を構築するためには、何を発見しようとしているのかがあらかじめ分かっていなければならない。従来のシステムにおける欠点の一例は、つづり間違いを探索するための容易な、または標準的な方法がないことである。この問題は、データが動的であり、または絶えず変化する状況においてはさらに悪化する。
【００２８】
構造化データに関しては、ＳＱＬは、多くの関係データベースに対して標準化された一貫性を有するプログラミングインターフェースを提供することができるため、産業において広範囲に配備されている。しかし、本発明者らは、構造化データのためのＳＱＬと、非構造化データに対する全文検索機能（またはテキスト解析やテキストマイニングといった他の処理機能）との統合を標準化しようとする現行の試みには改善が必要であると認識している。これらの試みの実現形態は、しばしば、性能上の障害を明確に示している。標準ＳＱＬを、構造化された表形式のデータと様々な形の非構造化データとを統合するように拡張しようとするいくつかの取り組みが行われている。例えば、半構造化ＸＭＬデータへの関係型アクセスのためのＳＱＬ／ＸＭＬ、非構造化マルチメディアデータのためのＳＱＬ／ＭＭ、非構造化外部データのためのＳＱＬ／ＭＥＤ、正規表現、ワイルドカード、語幹抽出、シソーラスおよびブール演算を使ってＸＭＬデータを探索するＸＱｕｅｒｙ１．０およびＸＰａｔｈ２．０Ｆｕｌｌ−Ｔｅｘｔ１．０などである。本発明者らは、非構造化データを処理するこれらのＳＱＬ拡張機能の大部分が、一貫性を欠く、種々雑多な言語の寄せ集めを表すものであり、それがこれらの拡張機能のＩＴ業界における普及を妨げていると考えている。本発明者らの考えでは、重大な性能上の問題がしばしばこれらの標準化の取り組みを遅らせている可能性が高い。
【００２９】
また、ＳＱＬの普及の結果として、いくつかのビジネスインテリジェンス（ＢＩ）報告ツールも開発されている。本発明者らは、非構造化テキスト解析をサポートする報告ツールの機能は比較的限られており、当分野では、この領域における改善が求められていると考えている。これらのソフトウェアツールの大部分は、非構造化データに対する全文検索、および他の高度なテキストマイニングおよび解析を実行するための、比較的限られた能力しか備えていない。重ねていうが本発明者らは、各ツールの性能は特に有効なものになっていないと考えている。
【先行技術文献】
【特許文献】
【００３０】
【特許文献１】米国特許第６７１１５５８号明細書
【特許文献２】米国特許第７１３９７４３号明細書
【特許文献３】米国特許出願公開２００６／０２９４０５９号明細書
【特許文献４】米国特許出願公開２００７／００６７１０８号明細書
【特許文献５】米国特許出願公開２００７／０１３０１４０号明細書
【特許文献６】米国特許出願公開２００７／０１７４８４１号明細書
【特許文献７】米国特許出願公開２００７／０２３７３２７号明細書
【発明の概要】
【発明が解決しようとする課題】
【００３１】
したがって本発明者らは、当分野には、非構造化データへのより高速で、統合的なアクセスを可能とするシステムが大いに求められていると考えている。さらに本発明者らは、当分野には、構造化データと非構造化データを相互に連係させ、統合して、非構造化データのインテリジェントなアクセスをサポートするためのより良い方法も求められていると考えている。
【課題を解決するための手段】
【００３２】
これらの目的のために、本発明者らは、従来の標準に基づく構造化データの問い合わせ処理と緊密に統合された方法で、問い合わせ処理時に、より複雑な非構造化データ解析のハードウェアアクセラレーションを活用するように構成された新規の方法およびシステムを開示する。その際に本発明は、好ましくは、以下の特許明細書および特許出願明細書に開示されている基礎をなすハードウェアアクセラレーション技術を利用する。「Ａｓｓｏｃｉａｔｅｄ Ｄａｔａｂａｓｅ Ｓｃａｎｎｉｎｇ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ」という名称の米国特許第６７１１５５８号明細書、「Ａｓｓｏｃｉａｔｉｖｅ Ｄａｔａｂａｓｅ Ｓｃａｎｎｉｎｇ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許第７１３９７４３号明細書、「Ｉｎｔｅｌｌｉｇｅｎｔ Ｄａｔａ Ｓｔｏｒａｇｅ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許出願公開第２００６／０２９４０５９号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｅｒｆｏｒｍｉｎｇ Ｂｉｏｓｅｑｕｅｎｃｅ Ｓｉｍｉｌａｒｉｔｙ Ｓｅａｒｃｈｉｎｇ」という名称の米国特許出願公開第２００７／００６７１０８号明細書、（２００７年８月１０日に出願された米国出願第１１／８３６９４７号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｔｅｉｎ Ｓｅｑｕｅｎｃｅ Ａｌｉｇｎｍｅｎｔ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許出願公開第＿＿＿＿＿号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｒｅｇｕｌａｒ Ｅｘｐｒｅｓｓｉｏｎ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」という名称の米国特許出願公開第２００７／０１３０１４０号明細書、（２００６年５月２日に出願された米国出願第１１／３８１２１４号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｐｐｒｏｘｉｍａｔｅ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」という名称の米国特許出願公開第＿＿＿＿＿号明細書、「Ｆｉｒｍｗａｒｅ Ｓｏｃｋｅｔ Ｍｏｄｕｌｅ ｆｏｒ ＦＰＧＡ−Ｂａｓｅｄ Ｐｉｐｅｌｉｎｅ Ｐｒｏｃｅｓｓｉｎｇ」という名称の米国特許出願公開第２００７／０１７４８４１号明細書、および「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ Ｂｌｏｃｋｗｉｓｅ Ｉｎｄｅｐｅｎｄｅｎｔ Ｅｎｃｒｙｐｔｉｏｎ／Ｄｅｃｒｙｐｔｉｏｎ」という名称の米国特許出願公開第２００７／０２３７３２７号明細書。各特許明細書および特許出願明細書の開示全体を参照により本明細書に組み込むものとする。
【００３３】
このハードウェアアクセラレーションは、ハードウェアアクセラレーションに適した問い合わせ処理の部分（非構造化データに対して実行される全文検索操作など）に対して適用される。どの非構造化データがハードウェアアクセラレートされたデータ処理操作に適用されるべきかインテリジェントに限定するために（および、それによって全体の応答時間を早めるために）、本発明を実施するシステムは、データベースに格納された構造化データの索引付き問い合わせも用いることができる。好ましくはこれらの問い合わせは、ＲＤＢＭＳを対象とするＳＱＬコマンドといった、標準化された索引付きデータベース問い合わせとして作成される。このように、ユーザは構造化データと非構造化データの両方を対象とする問い合わせを、よく知る方法で作成することができる。本発明の好ましい実施形態によるＡＰＩを用いれば、問い合わせ処理を、構造化データ部分とハードウェアアクセラレートされた非構造化データ部分とに効果的に分岐させることができる。
【００３４】
ハードウェアアクセラレートされたデータ処理操作は、好ましくは、前記の特許明細書および特許出願明細書に記載されているように、ＧＰＰとは別のコンピュータリソース（好ましくは、ファームウェアが展開されている再構成可能論理回路といったコプロセッサ）によって実行される。このためにコプロセッサを利用することにより、ＧＰＰによって実行される従来のソフトウェアを使って非構造化データの全文検索を実行する従来の解決法と比べて、問い合わせ処理の著しいアクセラレーションが達成され、それによってシステムの（１つまたは複数の）ＧＰＰを他のシステムタスクを実行するために解放することができる。
【００３５】
問い合わせ処理プロセスに役立つ構造化され、索引付けされたデータは、少なくとも一部は、オブジェクト（ドキュメントなど）のメタデータを含むことが好ましい。このメタデータには、好ましくはＲＤＢＭＳ内の構造化関係表に格納されており、非構造化データのどの部分がコプロセッサに流されるべきか特定するために、ＳＱＬコマンドなどの標準化された問い合わせを使って問い合わせることができる。実際、一態様によれば、本発明は本質的にはコプロセッサのデータ処理機能をＳＱＬ対応にする。
【００３６】
好ましくは、メタデータで索引付けされた非構造化データは、非構造化データのためのデータ処理機能が展開されているコプロセッサを用いた機器内の高性能ディスク空間内に格納されている。このように、ネットワーク帯域幅の制約条件なしで、非構造化データをコプロセッサに流すことができる。また非構造化データは、高速ネットワークを介して機器２００からアクセス可能などこかに格納することもできる。
【００３７】
本発明者らはさらに、非構造化オブジェクトからのメタデータの生成も、コプロセッサを使って（好ましくは、適切なファームウェアが展開されている再構成可能論理回路の形のコプロセッサを使って）ハードウェアアクセラレートすることができることを開示する。メタデータを生成すべき非構造化オブジェクトを適切に構成されたコプロセッサに流し、それによってその非構造化データに索引付けするのに使用されるメタデータの生成を迅速化することができる。このメタデータ生成に続いて、これらの非構造化オブジェクトの本体全部が、好ましくは、機器のディスク空間に取り込まれる。
【００３８】
またメタデータは、好ましくは、機器の内部のＲＤＢＭＳに格納されるが、本発明の好ましい実施形態の問い合わせ処理機能の一部として、機器の外部にある別の関係データベースに格納された構造化データにもアクセスすることができることに留意すべきである。
【００３９】
本発明者らは、後述する一般的なデータ探索に加えて、本発明を無数の用途に適用することができるものと予想している。例えば、保健医療の症例管理においては、臨床研究データベース、患者記録データベース、保険および法的ファイルのデータベース、法規則データベースといった多種多様なデータソースを、本明細書で説明する機器によって統合し、それによって、診断の向上、誤診の低減、適切な治療の保証、サービス品質の向上、利用可能なリソースの利用率増大、不正行為の低減、費用の管理その他の目標に関して、保健医療組織の機能を強化することができる。
【００４０】
科学分野では、科学的臨床的文献、治療記録および報告書、化合物データベース、医薬データベース、医学的症状データベースなどといった異種のデータソースを、本明細書で説明する機器を使って統合することができる。このように、望ましい目標には、生物医学的および化学的成分、遺伝標識、例えばタンパク質や遺伝子、塩基配列などと、諸症状、すなわち、「ＡはＢを阻害する」、「ＡはＢを活性化する」、「ＡはＢと関連付けられる」といったパターンの間の関係を抽出することなどが含まれる。成分抽出とは、この文脈では、ドメイン辞書に基づく生物医学テキストおよび化学テキストから遺伝子、化学物質、症状および症候群の名称および徴候を認識することをいう。
【００４１】
諜報およびテロ対策の分野では、報道および調査報告書、通信傍受、ドキュメント、ならびに事件ファイル（すべて様々な言語で書かれている）といった異種のデータソースを、本明細書で説明する機器によって統合することができる。このデータへの統合的でインテリジェントなアクセスによって検出することのできる目標およびパターンには、組織的結社およびネットワーク、行動／攻撃パターン、脅威評価、戦略策定、戦術評価、および事件予測が含まれる。
【００４２】
法執行分野では、本明細書で説明する機器を使って、諜報／テロ対策分野と同様のデータソースを、犯罪および裁判報告書、法律文書、ならびに地理的、人口統計学的データと共に統合することができる。このような統合の目標には、犯罪パターン（時間的、地理空間的、対人的、および／または組織的）の検出、ならびに犯罪捜査および訴追の支援が含まれるはずである。
【００４３】
有価証券詐欺行為探知の分野では、金融報告書および報道、企業ファイルおよびドキュメント、売買その他の取引記録といった異種のデータソースすべてを、本明細書で説明する機器を使って統合し、それによって、インサイダー取引、報告違反、マネーロンダリング、不法取引、価格異常といった行為を探知する能力を高めることができる。
【００４４】
顧客関係管理（ＣＲＭ）の分野では、顧客電子メールおよび書簡、コールセンターメモおよび転写記録、ならびに既存のＣＲＭシステムに維持されている他の顧客データといった異種のデータソースを、本明細書で説明する機器を使って統合することができる。このような統合により、おそらくは、製品およびサービス品質の問題を特定し、製品設計および管理に役立てることができる。
【００４５】
評判管理の分野では、異種のデータソースには報道、ウェブページおよび市場分析が含まれ、これらのデータソースを本明細書で説明する機器を使って統合して、企業体と社会との関係の状態を明らかにするテキストマイニングおよびパターン検出操作を実行することができる。
【００４６】
同様に、本明細書で説明する機器は、個人と組織とのつながりを判断するために電子メールその他の通信、企業ドキュメント、および報道を分析する社会的ネットワーク分析ツールとして使用することもできる。
【００４７】
本明細書で説明する機器を展開するための機が熟していると考えられる他の領域には、業務管理、競争インテリジェンス（ｃｏｍｐｅｔｉｔｉｖｅ ｉｎｔｅｌｌｉｇｅｎｃｅ）、法的開示（例えば、訴訟の原告が、「ジョンスミス」に関連する、維持されており、または被告の管理下にあるすべてのデータを要求する場合など）、コンテンツ権利管理、法規順守その他が含まれる。
【００４８】
さらに、本明細書で説明する発明は、内容から導出されるメタデータの自動生成を含めて、データに対して実行されるメタデータ生成操作を著しく速めるのに使用することができる。
【００４９】
本発明の前記その他の特徴および利点は、以下の説明および図面を考察すれば当業者には明らかになるであろう。
【図面の簡単な説明】
【００５０】
【図１】企業体がユーザに企業体のデータへのアクセスを可能にするための従来の方法を示す図である。
【図２】本発明の例示的実施形態を示す図である。
【図３】本発明の一実施形態によるドキュメント取込み前処理操作の概要を例示する図である。
【図４】本発明の一実施形態による探索機器を例示する図である。
【図５】本発明の一実施形態によるドキュメント取込み前処理操作を例示する論理図である。
【図６】本発明の一実施形態によるドキュメント取込み前処理操作のための図４の探索機器内のデータフローを例示する図である。
【図７ａ】図４の探索機器において使用するためのプリント回路基板を例示する図である。
【図７ｂ】図４の探索機器において使用するためのプリント回路基板を例示する図である。
【図８】どのようにしてファームウェアパイプラインが複数の再構成可能論理回路にわたって展開され得るかを例示する図である。
【図９】本発明の一実施形態による問い合わせ処理操作の概要を例示する図である。
【図１０ａ】どのようにして関係データベースとの対話が実行されるかに関してプロセッサとコプロセッサとの間の関係を例示する図である。
【図１０ｂ】図１０ａに対応する本発明の一実施形態による問い合わせ処理操作を例示する流れ図である。
【図１０ｃ】図１０ａに対応する本発明の一実施形態による問い合わせ処理操作を例示する論理図である。
【図１１ａ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｂ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｃ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｄ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｅ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｆ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｇ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１２】問い合わせの少なくとも一部が探索機器の外部に位置するドキュメントに対して実行される、本発明の一実施形態による問い合わせ処理操作の概要を例示する図である。
【図１３】問い合わせによって指定された構造化データを検索するために探索機器の外部にあるＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作の概要を例示する図である。
【図１４】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作を例示する論理図である。
【図１５ａ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｂ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｃ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｄ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｅ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｆ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｇ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｈ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１６】問い合わせを処理するために探索機器によって実行されるＡＰＩの処理フローを例示する図である。
【図１７ａ】ドキュメント取込み前処理操作および問い合わせ指定のデータ処理操作を実行するためにどのようにしてＦＡＭパイプラインを再構成可能論理回路上に展開することができるかを例示する図である。
【図１７ｂ】ドキュメント取込み前処理操作および問い合わせ指定のデータ処理操作を実行するためにどのようにしてＦＡＭパイプラインを再構成可能論理回路上に展開することができるかを例示する図である。
【図１８ａ】構造化データおよび非構造化データが共通データストアに格納されている例示的実施形態を示す図である。
【図１８ｂ】構造化データおよび非構造化データが共通データストアに格納されている例示的実施形態を示す図である。
【発明を実施するための形態】
【００５１】
図２に、企業体機器２００が、ユーザコンピュータ１００のユーザに、（関係データベース２１０によって格納されているような）構造化データと、（構成要素１０４、１０６および１０８を介して、またはインターネット１１０を介して格納され、アクセスすることのできるような）非構造化データへのインテリジェントで、統合的なアクセスを可能にするように構成されている本発明の好ましい実施形態の概要を示す。機器２００の実施形態を探索機器と呼ぶこともできるが、本明細書で説明するように、機器２００により、探索以外に、または探索に加えて他のデータ解析機能をサポートすることもできることに留意すべきである。
【００５２】
好ましくは、探索機器２００は、ハードウェアアクセラレートされたデータ処理機能はもとより、少なくとも一部は構造化データを対象とする問い合わせを処理する問い合わせ処理ＡＰＩも用いる。図４に、機器２００の好ましい実施形態を示す。機器２００内には、コプロセッサ４５０が、ディスクコントローラ４１４および４１６、ならびに（直接、またはＲＡＭ４０８などのシステムメモリ経由で間接的に）データストア３０４および３０６によって定義されるディスクサブシステムと、（ネットワークインターフェース４１０を介した）ネットワーク４２０の一方または両方から流されるデータを受け取るように配置されている。データストア３０４は、構造化関係データが格納されているＲＤＢＭＳを備え、データストア３０６は、非構造化データが格納されているファイルシステムを備える。しかし、非構造化データは、以下で図１８ａおよび図１８ｂに関連して説明するように、任意選択でＲＤＢＭＳ３０４内の非構造化データ列に格納されてもよいことに留意すべきである。ネットワーク４２０は、好ましくは、多種多様なドキュメントストア３０８（構成要素１０４、１０６および／または１０８）が位置する企業体ネットワーク（ＬＡＮであれＷＡＮであれ）を備える。データストア３０４は構造化データのためのデータストアとして特徴付けられているが、データストア３０４は、任意選択で、やはり取込みおよび問い合わせ処理の対象とし得る非構造化データＢＬＯＢを含んでもよいことに留意すべきである。
【００５３】
好ましい実施形態では、コプロセッサ４５０は、再構成可能論理回路４０２を備える。好ましくは、データはシステムバス４０６を介して再構成可能論理回路４０２に流れ込むが、他の設計アーキテクチャも可能である（図７ｂ参照）。好ましくは、再構成可能論理回路４０２はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）であるが、そうでなくてもよい。また、システムバス４０６は、再構成可能論理回路４０２と、機器のプロセッサ４１２および機器のＲＡＭ４０８とを相互接続することもできる。好ましい実施形態では、システムバス４０６はＰＣＩ−ＸバスまたはＰＣＩ−Ｅｘｐｒｅｓｓバスとすることができるが、そうでなくてもよい。
【００５４】
データストア３０６は任意のデータ記憶装置／システムとすることができるが、好ましくは、何らかの形の大容量記憶媒体である。例えば、データストア３０６は、ディスクアレイなどの磁気記憶装置とすることができる。しかし、本発明の実施に際しては他の種類の記憶媒体も使用に適することに留意すべきである。
【００５５】
プロセッサ４１２およびＲＡＭ４０８によって定義されるコンピュータシステムは、当分野の技術者が理解するような任意の市販のコンピュータシステムとすることができる。例えばコンピュータシステムは、ＩｎｔｅｌのＸｅｏｎシステムや、ＡＭＤのＯｐｔｅｒｏｎシステムなどとすることができる。したがって、機器２００の中央または主プロセッサとして使用されるプロセッサ４１２は、好ましくは、ＧＰＰを備える。
【００５６】
再構成可能論理回路４０２には、その機能を定義するファームウェアモジュールが展開されている。ファームウェアソケットモジュール４０４は、再構成可能論理回路との間のデータ移動要件（コマンドデータとターゲットデータの両方）を処理し、それによって、やはり再構成可能論理回路上に展開されているファームウェアアプリケーションモジュール（ＦＡＭ）連鎖３５０に一貫性のあるアプリケーションインターフェースを提供する。ＦＡＭ連鎖３５０の各ＦＡＭ３５０ｉは、ファームウェアソケットモジュール４０４から連鎖３５０に流れる任意のデータに対して指定されたデータ処理操作を実行するように構成されている。以下で、本発明の好ましい実施形態による再構成可能論理上に展開され得る好ましいＦＡＭの例を説明する。
【００５７】
ＦＡＭによって実行される特定のデータ処理操作は、ＦＡＭがファームウェアソケットモジュール４０４から受け取るコマンドデータによって制御／パラメータ化される。このコマンドデータはＦＡＭ特有のものとすることができ、コマンドを受け取るとＦＡＭは、受け取ったコマンドによって制御されるデータ処理操作を実行するように編成される。例えば、完全マッチ操作を実行するように構成されたＦＡＭ内では、ＦＡＭの完全マッチ操作は、完全マッチ操作を実行するための（１つまたは複数の）キーを定義するようにパラメータ化され得る。このようにして、完全マッチ操作を実行するように構成されたＦＡＭに１つまたは複数の異なるキーの新しいパラメータをロードするだけで、そのＦＡＭを、別の完全マッチ操作を実行するように容易に編成し直すことができる。
【００５８】
ＦＡＭは、受け取ったコマンドによって指定されるデータ処理操作を実行するように編成された後で、ファームウェアソケットモジュールから受け取るデータストリームに対して、コマンドで指定されたデータ処理操作を実行することができるようになる。よってＦＡＭは、指定されたデータストリームを指定された方法で処理するための適切なコマンドによって、編成されることができる。ＦＡＭがそのデータ処理操作を完了すると、そのＦＡＭには、ＦＡＭによって実行されるデータ処理操作の性質を変更するようＦＡＭを再編成させる別のコマンドを送ることができる。ＦＡＭは、ハードウェア速度で動作（し、ＦＡＭを介して高スループットの目標データを提供）するのみならず、そのデータ処理操作のパラメータを変更するよう柔軟にプログラムし直すこともできる。
【００５９】
ＦＡＭ連鎖３５０は、好ましくは、パイプライン化シーケンスとして配列された複数のファームウェアアプリケーションモジュール（ＦＡＭ）３５０ａ、３５０ｂ、．．．を備える。しかし、ファームウェアパイプライン内には、ＦＡＭ３５０ｉの１つまたは複数の並列経路を用いることもできることに留意すべきである。例えばファームウェア連鎖は、相互に並列な、第１のパイプライン化経路として配列された３つのＦＡＭ（ＦＡＭ３５０ａ、３５０ｂ、３５０ｃなど）と、第２のパイプライン化経路として配列された４つのＦＡＭ（ＦＡＭ３５０ｄ、３５０ｅ、３５０ｆおよび３５０ｇなど）とを含んでもよい。さらに、ファームウェアパイプラインは、既存のパイプライン経路から分岐する１つまたは複数の経路を備えることもできる。本発明の実施者は、所与の用途の処理要件に基づき、ＦＡＭ連鎖３５０の適切なＦＡＭ配列を設計することができる。
【００６０】
通信路４３０は、ファームウェアソケットモジュール４０４を、パイプライン化ＦＡＭの第１のＦＡＭ３５０ａの入力と接続する。第１のＦＡＭ３５０ａの入力は、ＦＡＭ連鎖３５０への入口点として使用される。通信路４３２はパイプライン化ＦＡＭ３５０ｍの最後のＦＡＭの出力を、ファームウェアソケットモジュール４０４と接続する。最後のＦＡＭ３５０ｍの出力は、ＦＡＭ連鎖３５０からの出口点として使用される。通信路４３０も通信路４３２も、好ましくは、マルチビット経路である。
【００６１】
特に、ファームウェアソケットモジュールとの間のデータフローに関連して、機器２００によって使用されるソフトウェアおよびハードウェア／ソフトウェアインターフェースがどういったものであるかは、前記の組み込まれた米国特許出願公開第２００７／０１７４８４１号明細書に詳細に記載されている。
【００６２】
図７ａに、機器２００においてコプロセッサ４５０として使用するために市販のコンピュータシステムのバス４０６に接続することのできるプリント回路基板またはカード７００を示す。図７ａの例では、プリント回路基板は、メモリ素子７０２およびＰＣＩ−Ｘバスコネクタ７０４と通信状態にあるＦＰＧＡ４０２（Ｘｉｌｌｉｎｘ Ｖｉｒｔｅｘ ＩＩ ＦＰＧＡなど）を含む。好ましいメモリ素子７０２は、ＳＲＡＭおよびＤＲＡＭメモリを含む。好ましいバスコネクタ７０４は標準カード端コネクタである。
【００６３】
図７ｂに、プリント回路基板／カード７００の代替の構成を示す。図７ｂの例では、プリント回路基板７００には、バス７０６（ＰＣＩ−Ｘバスなど）、１つまたは複数のディスクコントローラ７０８、およびディスクコネクタ７１０もインストールされている。当分野で理解されているように、任意の市販のディスクインターフェース技術がサポートされ得る。この構成では、ファームウェアソケット４０４は、プロセッサ４１２に、専用ＰＣＩ−ＸまたはＰＣＩ−ｅバス７０６を介して接続された（１つまたは複数の）ディスクへの通常のアクセスを可能にするためのＰＣＩ−Ｘ／ＰＣＩ−Ｘ（またはＰＣＩ−ｅ／ＰＣＩ−ｅ）ブリッジとしても使用される。図３ｂに示すディスクコントローラおよびディスクコネクタに加えて、またはこれらの代わりにネットワークインターフェースを使用することができることに留意すべきである。
【００６４】
図７ａまたは図７ｂの構成において、ファームウェアソケット４０４は、メモリ７０２をＰＣＩ−Ｘバスからアクセス可能にすることができ、それによって、ＯＳカーネルがメモリ７０２を、ディスクコントローラおよび／またはネットワークインターフェースコントローラからＦＡＭへ転送するためのバッファとして利用することが可能になることは注目に値する。また、図７ａおよび図７ｂのプリント回路基板上にはただ１つのＦＰＧＡ４０２しか示されていないが、プリント回路基板７００上に複数のＦＰＧＡを含めることにより、または機器２００に複数のプリント回路基板７００をインストールすることにより複数のＦＰＧＡをサポートすることができることが理解されるはずであることも注目に値する。図８に、１つのパイプライン内の多数のＦＡＭが複数のＦＰＧＡにまたがって展開されている例を示す。
【００６５】
本明細書で論じる例示的実施形態において、「ドキュメント」という用語は、本発明のシステムによって処理される非構造化データを記述するのに使用される。しかし、「ドキュメント」という用語の用法は例示のためのものにすぎず、本発明のシステムおよび方法を使って他の形の非構造化データを処理することもできることに留意すべきである。
【００６６】
機器２００の性能を向上させ得る任意選択の一構成が、大量の（おそらくはすべての）企業体のドキュメントを機器の搭載データストア３０６に取り込むことができる機能である。さらにその際に機器２００が、取り込む各ドキュメントに関するメタデータを構築することが好ましい。このドキュメントメタデータは、次いで、搭載するＲＤＢＭＳ３０４などの関係データベースシステムに格納することのできる構造化データを含む。
【００６７】
図３に、好ましい実施形態の一態様によるドキュメント取込み前処理の概要を示す。好ましくは、ユーザコンピュータ１００上に表示された何らかの形のドキュメント取込みＧＵＩ３００を介して、ユーザは、どの（１つまたは複数の）ドキュメントがデータストア３０６に取り込まれるべきか指定することができる。任意選択でユーザは、取り込まれるべき（１つまたは複数の）ドキュメントに関する様々な形のメタデータを打ち込むこともできる。しかし、コプロセッサ４５０（好ましくは、ファームウェア３５０が展開されている再構成可能論理回路４０２）は、所望のメタデータ生成操作を自動的に実行するように編成され得るため、これは必要になるとは限らない。ＧＵＩ３００を介した適切なユーザコマンドに応答して、企業体ネットワーク４２０を介してアクセス可能であるが、機器２００の外部にあるデータストア３０８に格納された１つまたは複数のドキュメント３１２が機器２００に送られる。機器２００が、ＮＴＦＳ、ＦＡＴ、ＣＩＦＳ、様々な特色を有するＵＮＩＸ（登録商標）ファイルシステムといった共通ファイルシステム上に格納されたドキュメントへのアクセス、ならびにＨＴＴＰを介したウェブアクセスを可能にするために用いるドキュメント検索機能３５２においては、様々なアダプタを用いることができる。
【００６８】
ファームウェアパイプライン３５０にある各ＦＡＭは、好ましくは、ＦＡＭが受け取るドキュメントに対してドキュメントメタデータ生成操作を実行するように編成されている。ファームウェア３５０において用いられ得るドキュメントメタデータ生成法の例には、それだけに限らないが、品詞タグ付け、情報およびエンティティ抽出、ドキュメント分類、ドキュメントクラスタ化、およびテキスト要約が含まれる。これらの操作は機能的には、１つまたは複数のドキュメントのデータストリームに対する一連の「変換」とみなすことができる。ドキュメントに対して実行され得るドキュメント分類操作の一例は言語分類を含む。言語分類では、ドキュメントを、ドキュメント内のテキストが最も密接にマッチする言語を特定するように構成されている統計的Ｎグラムアルゴリズムに適用することができる。別のドキュメント分類操作では、ドキュメントのある種の分類を知るために隠れマルコフモデル（ＨＭＭ）を用いることができる。さらに、ファームウェア３５０が正規表現パターンマッチングを用いてドキュメントに関する分類情報をさらに作成することもできる。例えば、使用され得るドキュメント分類器は、問題のドキュメントがクレジットカード番号を含むかどうか識別するフラグとすることができる。そのような場合、ファームウェア３５０は正規表現パターンマッチング操作を実施するＦＡＭを含むことができ、この正規表現パターンマッチング操作は、ＦＡＭに流されるドキュメントがクレジットカード番号のように見えるデータパターンを含むかどうか判定することを中心としてキー指定される。この操作の結果に基づき、クレジットカード標識メタデータを正または負に設定することができる。
【００６９】
従来のメタデータ生成操作の手法はこれらの操作をプロセッサ４１２などの主プロセッサによって実行されるソフトウェアに組み込んでおり、これは、前記のように、性能不足を示していると考えられる。本発明者らは、これらのメタデータ生成操作をコプロセッサ４５０に肩代わりさせることにより、著しいアクセラレーションを達成することができると考えている。メタデータ生成操作を実行するためのコプロセッサの使用に関するさらなる詳細は、前記の組み込まれた（Ｔｈｏｍｐｓｏｎ Ｃｏｂｕｒｎ代理人整理番号４４８２６／６５５９２として識別される）「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｄａｔａ Ｍｅｔａｔａｇｇｉｎｇ ａｎｄ Ｄａｔａ Ｉｎｄｅｘｉｎｇ Ｕｓｉｎｇ Ｃｏｐｒｏｃｅｓｓｏｒｓ」という名称の、本出願と同日に出願された、米国特許出願第＿＿＿＿＿号明細書に記載されている。
【００７０】
ファームウェア３５０の操作によって生成されたドキュメントメタデータ３１４は、次いでＲＤＢＭＳ３０４に格納することができ、そこでＲＤＢＭＳエンジンは、後で、データストア３０６内のどのドキュメントが、問い合わせ処理時にコプロセッサ４５０によってハードウェア速度で処理されるべきか特定するために、標準化されたデータベース問い合わせを使って問い合わせすることのできるこのドキュメントメタデータの索引を生成し、維持するように動作する。受け取られたドキュメント３１２がファームウェア３５０によって処理された後で、ドキュメント３１２を非構造化データのデータストア３０６に格納することにより、ドキュメント３１２を機器に取り込むことができる。メタデータ生成およびドキュメント取込みの動作は、好ましくは、ほぼリアルタイムで事実上同時に行われる。ドキュメントメタデータ３１４は、任意選択で、機器２００外部の構造化データベースに格納することもできることに留意すべきである。
【００７１】
図５に、このドキュメント取込み前処理を論理フローとして示す。ステップ１でユーザは、ＧＵＩ３００と対話して、機器２００に取り込むための新しいドキュメント３１２を特定する。ＧＵＩ３００は、任意選択で、ドキュメント３１２からどんなメタデータを生成すべきかユーザが指定することができるように構成されてもよい。次にステップ２で、ドキュメント３１２がその元の場所（企業体ドキュメントストア３０８、インターネットまたは企業体ネットワーク４２０からアクセス可能な他の何らかのネットワーク）から取り出される。次いでファームウェア３５０が、ドキュメント３１２に対してそのドキュメントメタデータ生成操作５００を実行してドキュメントメタデータ３１４を生成する。次いでステップ３で、ドキュメント３１２がデータストア３０６のファイルシステムに格納され、ドキュメントメタデータが（そのデータストア３０６のファイルシステムにおける場所を含めて）ＲＤＢＭＳ３０４の関係表に保存される。図６に、このデータフローを機器２００上に重ね合わせたものを示す。
【００７２】
このように、機器２００はこれ以後、ＲＤＢＭＳ３０４によって索引付けされたドキュメントメタデータ３１４を使って、どのドキュメントにコプロセッサ４５０による問い合わせ指定のデータ処理操作（全文検索操作など）を行うべきか判断するのに役立てることができる。さらに、機器２００内では標準化ＲＤＢＭＳ技術が活用されているため、所与の問い合わせ９０４を処理するときに、どのドキュメントにコプロセッサベースのデータ処理操作を行うべきか判断するのに、多くのユーザに周知の標準化データベース問い合わせを使用することができる。
【００７３】
一般には、関係データベース３０４は、ドキュメントメタデータ３１４の問い合わせを最適化するためにＢツリー索引などの索引付け法を使用することが好ましい。また、ハードウェアアクセラレートされたメタデータ生成によって生成され得る索引が豊富な情報を有するために、索引の効力を活用することによって、近接検索（すなわち、単語Ｘが単語ＹからＺ単語位置未満分だけ隔てられているインスタンスを検出する）を含む、洗練された全文検索操作を効率よく達成することができる。
【００７４】
さらに、企業体がその企業体データ処理操作に役立てるために機器２００を使用するときには、ドキュメント取込み前処理を、将来を見越して新規に作成されたドキュメントに対して適用するだけでなく、企業体の既存のドキュメントの全部または相当な部分に対して遡及的に適用することもできる。したがって、機器２００をインストールするときに、企業体は、効果的で、効率のよいドキュメント探索を可能にするために、図３、図５および図６に関連して詳述したように、機器を介して企業体のドキュメントの全部または相当な部分を取り込もうとしてもよい。しかし、図３、図５および図６に関連して説明した取込み前処理の対象とされるドキュメントは、機器２００の外部のドキュメントだけに限定される必要はないことに留意すべきである。前処理は、以前にメタデータ生成操作の対象とされたことのないデータストア３０６内のドキュメントにも、新規のメタデータ生成操作を必要とするドキュメントにも適用することができる。
【００７５】
また、ドキュメントがそこから前処理のために機器２００に取り込まれる記憶３０８は、企業体ネットワークを介してアクセス可能な任意のデータストア（企業体ネットワーク４２０内の企業体データストアや、企業体ネットワークの外部にあっても、企業体ネットワークからアクセス可能なデータストアなど）とすることができることにも留意すべきである。例えば、機器２００に取り込まれるドキュメントは、ウェブページなどのインターネットコンテンツとすることができる。
【００７６】
相当数のドキュメント３１２のためのドキュメントデータ３１４がＲＤＢＭＳ３０４に格納されると、機器２００はそれ以後ユーザ指定の問い合わせを処理することができるようになる。機器２００内のＡＰＩは、好ましくは、機器が、ＲＤＢＭＳ３０４内のドキュメントメタデータ３１４と対照して標準化データベース問い合わせを処理し、次いで、問い合わせの結果集合を使って、どのドキュメントが問い合わせ指定のデータ処理操作のためにコプロセッサ４５０に送られるべきか判定することを可能にするように構成されている。
【００７７】
図９に、どのようにしてこのような問い合わせを処理することができるかの概要を例示する。ユーザが自分のデスクトップ上で従来のＢＩ報告ツール９００にアクセスすることができ、このツール９００を介してユーザは、報告ツール９００を使用する際の訓練の一部としてすでに熟知している何らかの構文を使った所望の問い合わせ９０４を入力することができる。次いで報告ツール９００は、ユーザ指定の問い合わせ９０４から標準化データベース問い合わせ（ＳＱＬコマンド９０６など）を生成するように動作する。探索機器２００は、この標準化データベース問い合わせ９０６を受け取るように配置されている。機器２００は、（ＢＩ報告ツール９００がバス４０６に接続されている場合には）このような問い合わせをＢＩ報告ツール９００から直接受け取ることもでき、ネットワークインターフェース４１０を介してＢＩ報告ツール９００から間接的に受け取ることもできる。次いで探索機器２００によって実行されるＡＰＩ９０２が、ＳＱＬコマンド９０６をＲＤＢＭＳ３０４およびデータストア３０６に対して適宜適用するように動作する。好ましくは、ＡＰＩ９０２の操作は、機器のプロセッサ４１２によって実行される。しかし、ＡＰＩ機能の少なくとも一部は、任意選択で、コプロセッサ４５０によって展開されてもよいことに留意すべきである。好ましくは、このＡＰＩ９０２は、可能な場合には、既存のＡＮＳＩのＳＱＬ標準および拡張機能（ＳＱＬ／ＸＭＬ、ＳＱＬ／ＭＥＤ、ＳＱＬ／ＭＭ、ＸＭＬ／Ｆｕｌｌ−Ｔｅｘｔなど）に適合している。ＳＱＬ標準および拡張機能が所望の機能をサポートしていない場合、ＡＰＩのために（データベース用語で「外部処理手順」として類別され得る）外部機能を考案することができる。図１０ａにＡＰＩ９０２の好ましい実施形態を示す。以下で論じる図１６には、ＡＰＩ９０２の代替の実施形態が記載されている。
【００７８】
したがって、本発明の好ましい実施形態は、ＳＱＬ対応クライアントアプリケーションが、ＳＱＬコマンドを介してコプロセッサ４５０のハードウェアアクセラレートされた機能にアクセスすることができるようにするよう動作する。したがって、機器２００は、ＢＩ報告ツール９００などのＳＱＬ対応クライアントアプリケーションと統合することができるだけでなく、さらに、または代替として、他のＳＱＬ対応アプリケーションと統合することもできる。例えば機器２００は、様々な企業体ソフトウェアアプリケーション（ＥＲＰ、ＣＲＭ、ＳＡＰなど）、ミドルウェアプログラム、クライアントプログラム、多数のプログラミング言語のいずれかで書かれた（ＯＤＢＣやＪＤＢＣ接続などを使った）特注のプログラム、データベース３０４にリンクされている別のＳＱＬデータベースといったＳＱＬ対応アプリケーションのいずれかまたはすべてと統合することができる。
【００７９】
機器２００自体におけるＳＱＬ対応機能は、好ましくは、従来のＳＱＬリレーショナルエンジンソフトウェア９５０との、高性能の緊密な統合を含む。この一例が図１０ａに示されている。リレーショナルエンジンソフトウェア９５０は、関係データベースにアクセスするための従来の既製品のソフトウェアとすることができる。リレーショナルエンジン９５０による問い合わせ処理をコプロセッサ４５０と統合するために、リレーショナルエンジンソフトウェア９５０にいくつかのカスタマイズを加えることができる。所望の統合を達成するためのこの種のカスタマイズをもたらし得る方法の例としては、Ｃ言語による外部処理手順（ＳＱＬエンジンに動的にリンクされるカスタムライブラリ）、ユーザ定義の型および関数、ストアドプロシージャ、カスタムデータプロバイダなどがある。
【００８０】
例えば、ＳＱＬコマンドでいくつかの命令文に遭遇したときに所望の外部処理手順を呼び出すコードをリレーショナルエンジン９５０に加えることができる。この一例が図１０ｃに示されており、リレーショナルエンジン９５０は、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」という命令文を、（図１０ａにコプロセッサインターフェースソフトウェア９５２として示されている）外部プログラムを呼び出すものとして理解するように構成されている。リレーショナルエンジン９５０は、このような命令文に遭遇すると、以下で図１０ｂに関連して説明するように、コプロセッサインターフェースソフトウェア９５２を呼び出し、ＡＰＩソフトウェア９５２に適切なデータを渡してコプロセッサを望みどおりに機能させる。リレーショナルエンジン９５０のために、ＳＱＬコマンドにおいて遭遇する命令文によって異なる外部プログラムを呼び出し、それによって、コプロセッサ４５０を用いて異なる処理結果を達成するようないくつかの外部処理手順を考案することができることが容易に理解されるはずである。前記のように「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文は、コプロセッサを完全または近似マッチング操作のために構成する外部処理手順に結び付けることができ、「ｒｅｌｅｖａｎｃｅ ｒａｎｋｉｎｇ」文は、コプロセッサを、関連性の大きさに従ってデータオブジェクトを採点するように構成する外部処理手順に結び付けることができる。
【００８１】
機器２００がＭｙＳＱＬなどのオープンソースデータベースを用いて実施されている場合には、統合を、リレーショナルエンジンのソースコード自体の内部で直接達成することができる。オープンソースを用いた方法が提供する高い柔軟性があれば、ＡＰＩ９０２として使用することができ、クライアントアプリケーションとデータベース３０４との間のすべてのＳＱＬ要求を仲介するＳＱＬパーサ／インタプリタを開発することができる。ＡＰＩ９０２のためのＳＱＬパーサ／インタプリタ戦略の実装例は図１６に示されている。
【００８２】
図１０ａの実施形態に戻って、図１０ｂに、ストアドプロシージャ、外部処理手順、ユーザ定義の関数といったこのような標準ＳＱＬ拡張機能に基づくものである問い合わせ処理の解決法を実施するのに使用することのできる一連のステップを示す。図１０ｂは、同じ一連のステップ（１１０１から１１７０）を使用する図１０ｃと密接に結びついている。ステップ１１０１で、ＡＮＳＩ標準ＳＱＬコマンド９０６が構成され、ＳＱＬ対応クライアントアプリケーションを介して呼び出される。次にステップ１１１０で、リレーショナルエンジン９５０がプロセッサ４１２上で実行され、ＳＱＬコマンド９０６を構文解析して、ＲＤＢＭＳ３０４にどのようにして問い合わせすべきか決定する。オプティマイザヒントおよび様々なコード化法により、ＳＱＬ開発者は、処理の順序が保証され得るコマンドを構築することができる。すなわち、オプティマイザヒントは、ＳＱＬコマンド９０６内の様々な命令文の間の適切な処理順序を定義することができる。図１０ｃを参照すると、リレーショナルエンジンは、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文を処理する前に「ｄａｔｅ＿ｌｏａｄｅｄ」文を満足させることを必要とするはずである。手近にあるタスクは、ＲＤＢＭＳ３０４によって格納されている索引付き表を使って、コプロセッサ４５０による全文スキャンを必要とするオブジェクトを限定しようとするものである。本質的にリレーショナルエンジン９５０は、構造化データを対象とする問い合わせの部分をＲＤＢＭＳ３０４に適用する（この問い合わせ部分は、図９および図１１ｂの例においてＳＱＬコマンド９０８として識別されている）。ステップ１１２０でＲＤＢＭＳ３０４は、ＳＱＬコマンド９０６の「ｄａｔｅ＿ｌｏａｄｅｄ」制約条件部分で表されている基準を、そのドキュメントメタデータ索引の内容と対照してマッチさせた後で、ドキュメントのリスト９１０を返す。ドキュメントリスト９１０で識別されるドキュメントは、好ましくは、データストア３０６内の各ドキュメントの場所によって識別することができる。ステップ１１２５で、リレーショナルエンジン９５０は次に、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文に遭遇し、この命令文は外部処理手順を呼び出すものとして理解される。次いでリレーショナルエンジン９５０は、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文と結び付けられているコプロセッサインターフェースソフトウェア９５２を呼び出す。リレーショナルエンジン９５０は「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文の後に問い合わせ文字列が続いたものをコプロセッサインターフェースソフトウェア９５２に渡し、さらにコプロセッサインターフェースソフトウェア９５２に、ステップ１１２０で生成されたファイルリスト９１０を知らせる。コプロセッサインターフェースソフトウェア９５２はさらには、好ましくは、コプロセッサ４５０に問い合わせ文字列を、問い合わせ指定のデータ処理操作を実行するのに適した構成となるようコプロセッサに命ずるコマンドと共に渡すことによって、コプロセッサの操作を指図する。次いでステップ１１３０で、リスト９１０によって識別された非構造化ドキュメントの本文全体がコプロセッサ４５０に読み込まれる。好ましくは、コプロセッサインターフェースソフトウェア９５２は、ディスクコントローラ４１６に、データストア３０６からリスト９１０に記載された非構造化ドキュメントを流すよう求める命令を出す。次いでデータストア３０６は、コプロセッサ４５０によって処理されるデータストリーム９１４として要求されたドキュメントをコプロセッサ４５０に提供する。次いでコプロセッサ４５０は、ハードウェア速度でデータストリーム９１４に対する指定されたデータ処理操作を実行し（ステップ１１４０）、従来の手法と比べて問い合わせ処理操作の大幅なアクセラレーションが実現される。次いで、コプロセッサ４５０によって検出された「ヒット」があれば、コプロセッサはそれをＲＡＭ４０８内の一時データベース表に結果集合９１６として返すことができる（ステップ１１５０）。コプロセッサインターフェースソフトウェア９５２は、さらには、リレーショナルエンジン９５０にこの結果集合９１６を知らせることができる。任意選択でステップ１１６０において、リレーショナルエンジン９５０は、結果９１６に対する任意の所望の集約、相互相関、または後続の解析を実行するようこれらの結果９１６を後処理することもできる。
【００８３】
次にステップ１１７０で、リレーショナルエンジン９５０は、好ましくは、報告ツール９００が求める書式に探索結果９１６を書式設定し、報告ツール９００はその既存の技術を使ってそれらの探索結果９１６をユーザに提示する。
【００８４】
産業界では多種多様なＢＩ報告ツール９００が使用されているため、ＡＰＩ９０２は、好ましくは、少なくとも主要なＢＩ報告ツールの大部分とインターフェースし得るように構成されている。例えば、探索機器２００によって維持される構成ファイルを、企業体内での探索機器２００の初期設定時に、探索機器２００が相互のデータ交換を可能にするために対話する相手となる特定のＢＩ報告ツール９００を識別するようにセットアップすることができる。
【００８５】
また、従来のＢＩ報告ツール９００を、探索機器２００とユーザの間のインターフェースとして使用しなくてもよいことにも留意すべきである。例えば、探索機器２００を、ＢＩ報告ツールと同じ基本機能を提供するように構成されている、ユーザに表示するための独自のＧＵＩを提供するように構成することもできる。このような場合には、ＡＰＩ９０２を、任意選択でユーザ指定の問い合わせ９０４をデータベース問い合わせ９０８に直接変換するように構成することもできる。
【００８６】
さらに、標準化された問い合わせ９０６は、ＢＩ報告ツール９００またはユーザから発せられなくてもよいことにも留意すべきである。ＢＩ報告ツール９００またはユーザから発せられるのではなく、問い合わせは、探索機器２００によって格納され、または知られているデータを呼び出す他の何らかの企業体アプリケーションから発せられてもよい。
【００８７】
また、本明細書で探索機器２００の一部として説明しているＡＰＩ９０２は、任意選択で、その全部または一部が、ＢＩ報告ツール９００または他の上位レベルアプリケーション内に位置してもよいことにも留意すべきである。
【００８８】
図１０ｃには、本発明の好ましい実施形態による簡単な問い合わせ処理操作の論理図が示されている。この例では、ユーザは、２００７年７月７日にロードされた、テキスト制約条件：「ｂｌａｓｔｎ」という単語の近くにある「ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ」という句、を含むデータストア３０６内のドキュメントを探索しようとしている。ユーザがＢＩ報告ツール９００にこの目標に向けた問い合わせを入力した後で、ＢＩ報告ツールは、図１０ｃに示すようなＳＱＬコマンド９０６を生成するように動作する。このＳＱＬコマンドは、問い合わせがそれと対照して処理されるべきＲＤＢＭＳ３０４内の表を指定する「ｓｅｌｅｃｔ」文を含む。次の命令文は、探索の条件を指定する「ｗｈｅｒｅ」文である。条件の１つは、ドキュメントがデータストア３０６にロードされた日付であり、この条件は２００７年７月７日に設定されている。次の条件は前記のテキスト条件である。リレーショナルエンジンは、図１０ｃに示すようにこのＳＱＬコマンド９０６を受け取り、解釈する（ステップ１１０１参照、図１１ａも参照）。
【００８９】
リレーショナルエンジン９５０は、前記のように、「ｄａｔｅ＿ｌｏａｄｅｄ」制約条件をドキュメントメタデータ項目として識別し、さらに、テキスト制約条件をコプロセッサ４５０によって解決されるべき問題として識別する。図１０ａおよび図１０ｂの実施形態に関して、リレーショナルエンジン９５０は、ＳＱＬコマンド９０６の「ｄａｔｅ＿ｌｏａｄｅｄ」部分に対応するＳＱＬコマンド９０８を使ってＲＤＢＭＳ３０４に問い合わせする（ステップ１１１０参照、図１１ｂも参照）。
【００９０】
次いでＲＤＢＭＳは、メタデータ索引３１４によって、「ｄａｔｅ＿ｌｏａｄｅｄ」制約条件にマッチするものとして識別されたすべてのドキュメントのリスト９１０を返し（すなわち、ＲＤＢＭＳ３０４はその場合、このＳＱＬコマンド９０８をそのドキュメントメタデータ索引に対して適用して、２００７年７月７日にデータストア３０６にロードされたすべてのドキュメントのリストを返すはずである）、このリスト９１０はＲＡＭ４０８に格納することができる（ステップ１１２０参照、図１１ｃも参照）。このリスト９１０は、好ましくは、２００７年７月７日にロードされた各ドキュメントが位置するデータストア３０４のファイルシステム内の場所を識別するものである。
【００９１】
また、ＡＰＩ９０２は（図１０ａおよび図１０ｂの実施形態ではＡＰＩ９５２を介して、ステップ１１２５参照）、データストア３０６にリスト９１０上のすべてのドキュメントの検索を求める要求９１２も出す（図１１ｄ参照）。また、ＡＰＩ９０２は（図１０ａおよび図１０ｂの実施形態ではＡＰＩ９５２を介して、ステップ１１２５参照）、コプロセッサのＦＡＭパイプライン３５０に送るために、「「ｂｌａｓｔｎ」の近くにある「ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ」」という条件を中心として構築された全文検索を実行するようにＦＡＭパイプラインを編成する制御信号１１００を生成するようにも動作する。次いでこの制御信号１１００は、好ましくは、ドキュメントがコプロセッサ４５０に到達する前にコプロセッサ４５０に送られる（好ましくは、コプロセッサ４５０上にあるファームウェアソケットモジュール４０４に送られる）（図１１ｅ参照）。
【００９２】
要求９１２に応答してデータストア３０６は、図１１ｅに示すように、コプロセッサ４５０に（好ましくは再構成可能論理回路４０２上のファームウェアに）送るためのデータストリーム９１４を出力する（ステップ１１３０も参照）。次いでコプロセッサ４５０は（好ましくは、再構成可能論理回路４０２上のＦＡＭパイプライン３５０を介して）、問い合わせ内のテキスト制約条件に従い、ストリーム９１４内のドキュメントのハードウェアアクセラレートされた全文検索を実行する（ステップ１１４０参照、図１１ｆ参照）。次いでこの高速データ処理操作の結果は、ファームウェアソケットモジュール４０４を経由してＡＰＩ９０２に返される（ステップ１１５０参照）。次いでＡＰＩ９０２（好ましくはリレーショナルエンジン９５０）は、図１１ｇに示すように、それらの探索結果９１６を、ユーザにユーザの問い合わせを満足させる探索結果を提示することのできる報告ツール９００に返すために、報告ツール９００が求める方法で書式設定するように動作する（ステップ１１７０参照）。
【００９３】
そのためのドキュメントメタデータ３１４が生成されているドキュメント３１２は、必ずしも機器内でデータストア３０６に格納されている必要はないことにも留意すべきである。それらのドキュメントは、望ましい場合には、機器２００の外部のドキュメントの元の場所に保持することもできる。そのような場合、それらのドキュメントをコプロセッサ４５０によって全文処理すべきときには、それらのドキュメントを、ネットワークインターフェース４１０を介して機器２００およびコプロセッサ４５０に流すことができる。図１２は、ＲＤＢＭＳ３０６によって返されたリスト９１０上のドキュメントが、データストア３０６内部のドキュメントと、企業体ネットワークを介してアクセス可能な他の何らかのデータストア３０８に位置する機器２００の外部のドキュメントの両方を含む場合のこの態様のドキュメント探索を示す、図９の対応図である。そのような場合には、ＡＰＩ９０２により、データストア３０６に送るためと機器２００の外部に送るための２つの要求９１２ａおよび９１２ｂが作成される。この構成は、探索が実行される際の待ち時間をネットワーク帯域幅が制約し得るためにあまり望ましくないが、それでもやはり本発明者らは、ドキュメントがデータストア３０６内に保持されていない場合でさえも、ある程度のアクセラレーションがなおも実現されることを認めるものである。この状況では、ドキュメント３１２をデータストア３０６に取り込む処置は、移動操作ではなくコピー操作とすることができることも注目に値する。企業体の中には、ドキュメント３１２の原本を機器２００の外部にある元の場所に残そうとするものもある。そうした状況では、ドキュメント３１２のコピーだけがデータストア３０６によって格納される。
【００９４】
好ましい実施形態の別の強力な態様は、機器２００が、データ処理操作を実行するときに探索機器２００の外部にある任意の企業体ＲＤＢＭＳ１３００にアクセスすることができるものである。この態様の好ましい実施形態の概要が図１３に示されている。この態様の好ましい実施形態の一部として、ＡＰＩ９０２により外部ＲＤＢＭＳ１３００に対してＳＱＬコマンド１３０２が発行され、それらのコマンドに対する応答１３０４がＡＰＩ９０２によって受け取られる。したがって、機器２００は、対象とするドキュメントの探索を実行するときに、企業体によって維持されている既存の構造化データを効率よく活用することができる。
【００９５】
図１４に、この態様のＳＱＬコマンド処理の論理図を示す。図１４の例では、ユーザには、なぜ最近企業体のいくつかの顧客の売上が鈍化しているのか調べるという任務が割り当てられている。この任務の一部として、ユーザは、ネットワークによって格納されている、このような売上不振に対する有益な洞察を提供し得るドキュメントを調査しようとする。これを達成するためにユーザは、２００７年７月７日にロードされた、「ｗｉｄｇｅｔ」または「ｎｅｗ ｐｒｏｄｕｃｔ」の近くにある「ｔｒｏｕｂｌｅ」というテキストを含む、その月間売上高が１０，０００製品（ｗｉｄｇｅｔ）を下回る顧客のすべてのドキュメントを検索することを目的とする問い合わせを指定する。ＢＩ報告ツール９００は、これらの問い合わせ制約条件を、図１４に示すようなＳＱＬコマンド９０６に変換するように動作する。
【００９６】
企業体はその顧客売上データを探索機器２００の外部にあるＲＤＢＭＳ１３００に格納するため、ＳＱＬコマンド９０６は、外部ＲＤＢＭＳ１３００内のデータ表をＲＤＢＭＳ３０４内のドキュメントメタデータ表と結合するように動作する。この処置は、当分野で公知のＳＱＬ操作である、（ドキュメントメタデータ表の）「Ｄ．Ｃｕｓｔｏｍｅｒ＿ＩＤ」と（外部関係表の）「Ｃ．Ｃｕｓｔｏｍｅｒ＿ＩＤ」とのマージキーに基づき、外部ＲＤＢＭＳ１３００内の「Ｃｕｓｔｏｍｅｒｓ＠ｅｘｔｅｒｎａｌ＿ＤＢ Ｃ」関係表の顧客データをＲＤＢＭＳ３０４内のドキュメントメタデータ関係表と結合する「ｉｎｎｅｒ ｊｏｉｎ」文に反映されている。このマージに基づき、リレーショナルエンジン９５０は、外部関係表から、どの顧客が１０，０００を下回る売上高を有するか特定し、それらの顧客をドキュメントメタデータ表内のフィールドに結び付けることができる。次いで、ドキュメントメタデータ内の「ｄａｔｅ＿ｌｏａｄｅｄ」メタデータフィールドに基づいて、それらの顧客のドキュメントをさらに限定することができる。最終的には、売上高とロードされた日付を満たす顧客のドキュメントを、コプロセッサ４５０内で「「ｗｉｄｇｅｔ」または「ｎｅｗ ｐｒｏｄｕｃｔ」の近くにある「ｔｒｏｕｂｌｅ」」という制約条件に基づく高速テキストマイニングのために処理することができる。その後は、図１０ｂに関連して説明したように処理を続行することができる。
【００９７】
図１５ａに、図１１ａを反映した、ＡＰＩ９０２によるＳＱＬコマンド９０６の受け取りを示す。リレーショナルエンジン９５０は、ＳＱＬコマンド９０６内のどの（１つまたは複数の）制約条件が外部ＲＤＢＭＳ１３００を対象とするものであるか特定し、ＳＱＬコマンド９０６の外部関係データ制約条件部分を対象とする新しいＳＱＬコマンド１３０２を生成する（図１４のＳＱＬコマンド９０６の例では、この外部制約条件部分は売上高制約条件である）。リレーショナルエンジン９５０は、新しいＳＱＬコマンド１３０２を処理するために外部ＲＤＢＭＳ１３００に対して適用する（図１５ｂ参照）。その後リレーショナルエンジン９５０は、外部ＲＤＢＭＳによるＳＱＬコマンド１３０２の処理から結果集合１３０４を受け取る（図１５ｃ参照）。
【００９８】
次いでリレーショナルエンジン９５０は、引き続きそのＳＱＬコマンド９０６を処理し、コマンド９０６にＲＤＢＭＳ３０４を対象とする別の制約条件が残っているかどうか判定する。制約条件が残っていない場合、結果集合１３０４内の顧客に基づいてＲＤＢＭＳ３０４のＳＱＬコマンド９０８が構築される。制約条件が残っている場合、結果集合１３０４と、残りの内部ＲＤＢＭＳを対象とする制約条件（図１４の例では「ｄａｔｅ ｌｏａｄｅｄ」制約条件など）とに基づいて、ＲＤＢＭＳ３０４のＳＱＬコマンド９０８が構築される。したがって、図１４のＳＱＬコマンド９０６の例では、リレーショナルエンジンは、その顧客フィールドが結果集合１３０４内の顧客によって限定され、そのロードされた日付フィールドが２００７年７月７日によって限定されるドキュメントメタデータを有するすべのドキュメントを探し出すＳＱＬコマンドを適用するはずである。この新しいコマンドを処理するためにＲＤＢＭＳ３０４に送ることができる（図１５ｃ参照）。
【００９９】
コマンド９０８に応答してドキュメントリスト９１０を受け取ると、問い合わせ処理の残りの部分が、図１５ｄから図１５ｈに示すように、図１１ｃから図１１ｇに関連して説明したのと同様に続行される。この例では、ＦＡＭパイプライン３５０の制御信号１１００は、どのドキュメントが「ｗｉｄｇｅｔ」または「ｎｅｗ ｐｒｏｄｕｃｔ」の近くにある「ｔｒｏｕｂｌｅ」というテキストを含むか特定するためにデータストリーム９１４内のドキュメントの全文検索を実行するようＦＡＭパイプライン３５０を編成するように構成されている。
【０１００】
前記のように、図１６には、ＡＰＩ９０２の代替の実施形態が開示されている。図１１ａから図１１ｇの作業例に関連して、ステップ１６００、１６０２、１６０４、１６０６、１６１６、および１６２０は、図１１ａに示すフローに対応するものである。ステップ１６２４およびステップ１６２８は図１１ｂに示すフローに対応するものである。ステップ１６３２は図１１ｃに示すフローに対応するものである。ステップ１６４０は図１１ｄに示すフローに対応するものである。ステップ１６１０およびステップ１６３６は図１１ｅに示すフローに対応するものである。ステップ１６４８は図１１ｆに示すフローに対応し、ステップ１６５０は図１１ｇに示すフローに対応するものである。
【０１０１】
また、ＡＰＩ９０２は、構造化データの少なくとも一部分が機器２００の外部にあるＲＤＢＭＳに格納されているときに使用するための一連の処理ステップも開示するものである。図１５ａから図１５ｈの作業例に関連して、ステップ１６００、１６０２、１６０４、１６０６、１６１６、１６２０、および１６２６は、図１５ａに示すフローに対応するものである。この例の問い合わせの一部は外部ＲＤＢＭＳ１３００に格納された関係データを対象としているため、プロセスフローはステップ１６２０からステップ１６２６に分岐することに留意すべきである。その後、ステップ１６３０は、図１５ｂに示すフローに対応するものである。ステップ１６３４、１６３８、１６４２、１６４４、および１６４６は図１５ｃに示すフローに対応するものである。その時点で図１６のプロセスフローはステップ１６３２に分岐し、図１５ｄから図１５ｈが図１１ｃから図１１ｇに関連して説明したように動作するように残りの操作が続行される。
【０１０２】
また、機器２００を、ＢＩ報告ツール９００などの上位レベルアプリケーションからの、データストア３０４内のドキュメントも、ＲＤＢＭＳ３０４がそれに関するメタデータを維持しているドキュメントも、ＲＤＢＭＳ３０４内のデータも対象としない問い合わせも処理するように構成することができることも注目に値する。このような例では、ＡＰＩ９０２は本質的に、それらの問い合わせが適切な外部構成要素に向けられる際の通路として（少なくともリレーショナルエンジン９５０までの通路として）機能する（ステップ１６０４、１６０８、１６１４および１６１８参照）。
【０１０３】
また、ＡＰＩ９０２は、図１６のステップ１６０６、１６１２、１６１４および１６１８で示すように、もっぱらＲＤＢＭＳ３０４内のメタデータだけを対象とする問い合わせ（メタデータに対する、ドキュメントテキスト探索制約条件を含まない問い合わせなど）を処理するように構成することもできることも分かる。
【０１０４】
図１７ａおよび図１７ｂに、好ましい実施形態のハードウェアアクセラレートされたデータ処理タスクを実行するために、再構成可能論理回路４０２のＦＡＭパイプライン３５０をどのようにしてセットアップすることができるかを例示する。図１７ａの例では、単一のＦＡＭパイプライン３５０が用いられており、パイプライン内の第１のＦＡＭ集合１７００はドキュメントメタデータ生成操作を実行するように構成されており、パイプライン内の第２のＦＡＭ集合１７０２は問い合わせ指定のデータ処理操作を実行するように構成されている（またはその逆でもよい）。この編成では、ＦＡＭパイプライン３５０がドキュメント取込み前処理に使用されているとき、問い合わせ指定のデータ処理を対象とするＦＡＭを、それらが事実上オフとされる「通過」モードに設定することができる。ＦＡＭパイプライン３５０がそうではなく問い合わせ指定のデータ処理操作に使用されるときには、ドキュメントメタデータ生成操作を対象とするＦＡＭを、それらが事実上オフとされる「通過」モードに設定することができる。
【０１０５】
この動作モードの代替として、図１７ｂに示すように、ＦＡＭ集合１７００とＦＡＭ集合１７０２を両方とも、独自の別個のパイプラインとして設定することもできる。この例では、ファームウェアソケットモジュール４０４に組み込まれたインテリジェンスが、どんな種類の処理が必要とされているかに応じて、データ（制御データおよびターゲットデータ）を適切なＦＡＭ集合に向けることができる。
【０１０６】
コプロセッサ４５０によって（好ましくは、再構成可能論理回路４０２上に展開されたファームウェア３５０を介して）実行される問い合わせ指定のデータ処理操作には、様々なアルゴリズムのいずれかを使用することができる。前記のように、コプロセッサによって全文検索を実行することもできる。コプロセッサによって実行され得る様々な全文検索操作の例には、完全マッチ操作、近似マッチ操作、正規表現マッチング操作、パターンマッチング操作他が含まれる。全文検索では、（問い合わせによって定義されるように）非構造化データにおいて検出されることが求められるデータに対応する１つまたは複数のキーをコプロセッサ４５０にロードすることができ、流れる非構造化データのいずれかが問い合わせを満足させるかどうか判定するための様々な技法を使って、流れる非構造化データを１つまたは複数のキーと比較することができる。このような全文検索操作の例示的実施形態は、前記の組み込まれた米国特許第６７１１５５８号明細書および米国特許第７１３９７４３号明細書、米国特許出願公開第２００６／０２９４０５９号明細書、米国特許出願公開第２００７／０１３０１４０号明細書、ならびに（２００６年５月２日に出願された米国出願第１１／３８１２１４号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｐｐｒｏｘｉｍａｔｅ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」という名称の米国特許出願公開第＿＿＿＿＿号明細書に開示されている。
【０１０７】
コプロセッサ４５０によって実行され得るデータ処理操作の別の例にはバイオシーケンス類似性探索が含まれ、その実施形態は、前記の組み込まれた米国特許出願公開第２００７／００６７１０８号明細書、および（２００７年８月１０日に出願された、米国出願第１１／８３６９４７号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｔｅｉｎ Ｓｅｑｕｅｎｃｅ Ａｌｉｇｎｍｅｎｔ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許出願公開第＿＿＿＿＿号明細書に開示されている。
【０１０８】
さらに、コプロセッサ４５０内のパイプラインは、非構造化データに対して複数の異なるデータ処理操作を実行するように編成されることもできる。例えば、非構造化データがデータストア３０６に暗号化形式で格納されている場合には、コプロセッサを、全文検索操作を実行する前に、暗号化された非構造化データに対する復号操作を実行するパイプラインで構成することもできる。同様に、非構造化データがデータストア３０６に圧縮形式で格納されている場合には、コプロセッサを、全文検索操作を実行する前に、圧縮された非構造化データに対して伸張操作を実行するパイプラインで構成することもできる。さらに、非構造化データがデータストア３０６に暗号化され、圧縮された形式で格納されている場合には、コプロセッサを、全文検索操作を実行する前に復号および伸張を実行するパイプラインで構成することもできる。
【０１０９】
また、本発明を実施する者は、機器２００内に、様々なユーザが利用し得る内容を制限するセキュリティ機構を用いようとしてもよいことにも留意すべきである。好ましくは、このようなセキュリティ機構は、ＬＤＡＰ、アクティブディレクトリ（Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ）、シングルサインオン（Ｓｉｎｇｌｅ Ｓｉｇｎ−Ｏｎ）といった様々な企業体セキュリティアーキテクチャと統合されている。また、望ましい場合には、コプロセッサ４５０によってセキュリティ機能をハードウェアアクセラレートすることもできることにも留意すべきである。例えば、セキュリティ制御の粒度を、コプロセッサ４５０の使用により、ドキュメントレベルではなくデータレベルにおいて効率よく実施することができる。例えば、コプロセッサが再構成可能論理回路４０２を備える好ましい実施形態では、再構成可能論理回路上でファームウェア３５０を、指定のデータ処理操作のために編成されているファームウェアパイプライン内の下流側ＦＡＭへの制限データの通過を効率よくマスクする資格フィルタリング（ｅｎｔｉｔｌｅｍｅｎｔ ｆｉｌｔｅｒｉｎｇ）を用いるように編成することもできる。例えば、正規表現パターンマッチングＦＡＭを用いて、データがファームウェア３５０を流れる際にデータからデータの特定の部分（名前、電話番号、クレジットカード番号など）を除外することもできる。同様に、医療記録分野への本発明の適用例では、医療記録を探索しようとする、医療記録の特定部分の閲覧を許可されていないユーザが、制限されたデータにアクセスするのを防ぐために、適切に構成されたファームウェアを使って、医者／看護師だけが見るべきである医療記録内の特定のデータをフィルタリングすることもできる。このようにして、ファームウェア３５０によって用いられるデータ処理は、問い合わせ指定のデータ処理を用いるだけでなく、資格フィルタリング他のセキュリティ管理、暗号化／復号（例えば、前記の組み込まれた米国特許出願公開第２００７／０２３７３２７号明細書に記載されている暗号化／復号技術を参照されたい）、問い合わせ指定のデータ処理操作を補助するその他のデータ処理操作といった追加の付随的なデータ処理操作を用いることもできる。
【０１１０】
また、コプロセッサを使って解析されるべき非構造化データの一部を特定するのに構造化データを使用する問い合わせ処理の技法は、構造化データと非構造化データが同じデータストアに位置している状況においても適用することができることにも留意すべきである。この例示的実施形態は、図１８ａおよび図１８ｂに示されている。これは、関係データベース表が非構造化データの列を含む場合とすることができる。この一例は、コールセンター記録を格納する関係データベースにおいて生じ得る。コールセンターデータの各構造化フィールドは、電話が受け取られた日付、発信者の名前および電話番号、ならびに電話に出たコールセンター職員の名前を特定し得る。また、これらの記録は、発信者の通話に関するコールセンター職員の自由形式のテキストメモを含む非構造化データフィールドも含み得る。本明細書で説明した技法を使用すれば、通話メモが「ｒｅｆｕｎｄ」という単語を含む、２００８年１月１日から２００８年１月３１日までのすべての通話記録を検索するよう求める問い合わせを機器２００に向けることができる（図１８ｂ参照）。ＡＰＩ９０２は構造化データ列にアクセスして、通話日付が２００８年１月中であった通話記録の一部を特定することができる。その後、特定された部分におけるすべての通話記録（または少なくとも特定された部分の通話記録内のすべての非構造化列）をコプロセッサ４５０に流して、「ｒｅｆｕｎｄ」という単語を含む２００８年１月の通話記録を特定することができる。
【０１１１】
本明細書で開示した好ましい実施形態においてコプロセッサ４５０はＦＰＧＡなどの再構成可能論理回路４０２を備えているが、コプロセッサ４５０は他の処理装置を使って実現することもできる。例えば、コプロセッサ４５０は、グラフィックス処理装置（ＧＰＵ）、汎用グラフィックスプロセッサ、チップマルチプロセッサ（ＣＭＰ）、専用メモリ素子、複合プログラマブル論理回路、特定用途向け集積回路（ＡＳＩＣ）、および他の入出力処理構成要素を含んでもよい。さらに、機器２００は、直列と並列のどちらかまたは両方のマルチコプロセッサアーキテクチャとして複数のコプロセッサ４５０を用いてもよいことにも留意すべきである。
【０１１２】
以上、本発明をその好ましい実施形態に関連して説明したが、本発明には、やはり本発明の範囲内に含まれる様々な変更が加えられ得る。このような本発明への変更は、本明細書の教示を考察すれば理解されるであろう。したがって、本発明の完全な範囲は、もっぱら添付の特許請求の範囲およびその法的な均等物によって定義されるべきものである。
【技術分野】
【０００１】
（関連出願の相互参照および優先権主張）
本出願は、参照によりその開示全体が本明細書に組み込まれる、２００６年１１月１３日に出願された、米国仮特許出願第６０／８６５６２９号の優先権を主張するものである。
【０００２】
本出願は、参照によりその開示全体が本明細書に組み込まれる、（Ｔｈｏｍｐｓｏｎ Ｃｏｂｕｒｎ代理人整理番号４４８２６−６５５９２により識別される）「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｄａｔａ Ｍｅｔａｔａｇｇｉｎｇ ａｎｄ Ｄａｔａ Ｉｎｄｅｘｉｎｇ Ｕｓｉｎｇ Ｃｏｐｒｏｃｅｓｓｏｒｓ」という名称の、本出願と同日に出願された、米国特許出願第＿＿＿＿＿号に関連するものである。
【０００３】
本発明は、一般に、データベースアクセラレーションの分野を対象とし、詳細には、企業体データ探索、ドキュメントウェアハウス、テキストマイニング、テキスト解析、情報アクセス、アクショナブルインテリジェンス（ａｃｔｉｏｎａｂｌｅ ｉｎｔｅｌｌｉｇｅｎｃｅ、活用可能な形の情報）の実現といった領域を含む企業データウェアハウスアクセラレーションを対象とする。
【背景技術】
【０００４】
（用語）
以下の各項に、本明細書で使用する様々な用語のいくつかの定義を示す。また以下の項には、これらの用語に関連する背景情報も示す。
【０００５】
ＧＰＰ：本明細書で使用する場合、「汎用プロセッサ」（またはＧＰＰ）という用語は、固定された形態を有し、その機能が可変であり、この可変機能が、命令を取り出し、その命令を実行することによって定義されるハードウェア装置（例えば、ＩｎｔｅｌのＸｅｏｎプロセッサやＡＭＤのＯｐｔｅｒｏｎプロセッサなど）をいい、従来の中央処理装置（ＣＰＵ）がその一般的な例である。
【０００６】
再構成可能論理：本明細書で使用する場合、「再構成可能論理」という用語は、その形態および機能を、製造後に現場で大幅に変更（すなわち再構成）することのできる任意の論理技術をいう。これはＧＰＰと対比されるものであり、ＧＰＰの機能は製造後に変化し得るが、その形態は製造時に固定されている。
【０００７】
ソフトウェア：本明細書で使用する場合、「ソフトウェア」という用語は、ＧＰＰまたは他の処理装置上で展開されるデータ処理機能をいい、ソフトウェアは、ソフトウェアがロードされる装置の形態を変更し、または定義するのに使用することはできない。
【０００８】
ファームウェア：本明細書で使用する場合、「ファームウェア」という用語は、再構成可能論理または他の処理装置上で展開されるデータ処理機能をいい、ファームウェアは、ファームウェアがロードされる装置の形態を変更し、または定義するのに使用され得る。
【０００９】
コプロセッサ：本明細書で使用する場合、「コプロセッサ」という用語は、主プロセッサを有する計算処理システムにおいて、他の構成要素と連携して動作するように設計された計算エンジンをいう（マルチコアプロセッサアーキテクチャの場合のように、主プロセッサ自体が複数のプロセッサを備えてもよい）。典型的には、コプロセッサは、特定のタスク集合を実行するように最適化され、システム性能を最適化するために（典型的にはＧＰＰである）主プロセッサのタスクを軽減するのに使用される。コプロセッサによって実行されるタスクの範囲は、コプロセッサのアーキテクチャに応じて、固定とすることも、可変とすることもできる。固定式コプロセッサアーキテクチャの例には、広範囲のタスクを実行するグラフィックスプロセッサユニットや、比較的狭い範囲のタスク集合を実行する浮動小数点数値コプロセッサが含まれる。再構成可能コプロセッサアーキテクチャの例には、幅広い種類の固定型の、またはプログラム可能な計算エンジンを実施するように再構成され得る、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能論理回路が含まれる。コプロセッサの機能は、ソフトウェアおよび／またはファームウェアによって定義されてもよい。
【００１０】
ハードウェアアクセラレーション：本明細書で使用する場合、「ハードウェアアクセラレーション」という用語は、主プロセッサから１つまたは複数の処理タスクを軽減して主プロセッサに関連したこれらのタスクの処理待ち時間を低減するために、コプロセッサ上に実施されたソフトウェアおよび／またはファームウェアを使用することをいう。
【００１１】
企業体：本明細書で使用する場合、「企業体」という用語は、その進行中の業務の一部として（「企業体データ」と呼ばれる）データを格納し、かつ／または処理する任意の事業組織または行政主体をいう。
【００１２】
データベース：本明細書で使用する場合、「データベース」という用語は、問い合わせ処理を迅速化するための索引付け機能を有する永続的データストアをいう。様々なデータベース管理システム（ＤＢＭＳ）実装形態が、関係型（ＲＤＢＭＳ）、オブジェクト指向型（ＯＯＤＢＭＳ）、階層型などとして類別され得る。しかし、今日業界において優勢なアーキテクチャは関係型の、行／列からなる、構造化照会言語（ＳＱＬ）対応データベースである。ＡＮＳＩ標準のＳＱＬデータベースエンジンは、普通は効率的な方法で、問い合わせに応答して構造化データを検索することのできる、成熟したソフトウェアアーキテクチャである。
【００１３】
構造化データ：本明細書で使用する場合、「構造化データ」という用語は、関係データベースに合わせて正規化され、永続化されているデータをいう。正規化とは、データを表の行／列形式にし、重複データを別々の表に抽出するデータ設計プロセスである。関係列内の構造化データには、Ｂツリー索引を用いて索引付けして、これらの列内のデータへのアクセスを大幅に迅速化することができる。ＳＱＬでは、構造化列にはサイズ限界がある。これらの列には、一貫性のあるデータ品質を保証するための制約条件および参照整合性が適用され得る。一般的な構造化ＳＱＬデータ型の例は、ＩＮＴ（ｅｇｅｒ）、ＮＵＭＢＥＲ、ＣＨＡＲ（ａｃｔｅｒ）、ＶＡＲＣＨＡＲ、ＤＡＴＥ、ＴＩＭＥＳＴＡＭＰなどである。構造化データの処理は、周知の関係データベース技術が適するものである。非常に重要なことに、本発明は、これらの機能を活用して、関係データベースが最も得意とすること、すなわち、索引付きルックアップを使った構造化データへの迅速なアクセスを行う。
【００１４】
非構造化データ：本明細書で使用する場合、「非構造化データ」という用語は、前記の構造化データの定義の範囲に入らないデータをいう。したがって、非構造化データという用語は、自由な形のテキストまたは埋込み値が含まれているファイル、ドキュメントまたはオブジェクトを含む。このデータは、データを生成したアプリケーションによって使用された、しばしばバイナリ形式のデータを含む、完全なバイト集合を含む。非構造化データの例には、ワードプロセッシングドキュメント（Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄの固有の形式のドキュメントなど）、Ａｄｏｂｅ Ａｃｒｏｂａｔドキュメント、電子メール、画像ファイル、映像ファイル、オーディオファイル、およびファイルを作成したソフトウェアアプリケーションに関連する固有の形式の他のファイルなどが含まれる。ＳＱＬでは、非構造化列は、無制限ではないにせよ、非常に大きいサイズを有する。非構造化ＳＱＬデータ型の一般的な例は、ＢＬＯＢ、ＴＥＸＴ、ＸＭＬ、ＲＡＷ、ＩＭＡＧＥなどである。また、非構造化オブジェクトは、データベースの外部に、例えばオペレーティングシステムファイルなどに格納されてもよい。データベースエンジン内からこれらの外部オブジェクトへのアクセスには、データベース表のメタデータ内の格納場所へのリンクを使用する。
【００１５】
本明細書で使用する際に、ＸＭＬという用語を通常は「構造化」として類別しない理由には以下のものがある：
・ＸＭＬは、大きな値、またはサイズが無制限の値を持ち得る。
・ＸＭＬは、しばしば、強制されたデータ型を持たないことがある。
・ＸＭＬは柔軟なスキーマを有する。
・要素および属性のＸＭＬ値は、しばしば、従来の「構造化」データベース列ほど厳格に適合されず、不要なものが完全に除去されていないことがある。
【００１６】
柔軟なスキーマを有する「半構造化」データの概念が、特にＸＭＬについては台頭しつつあるが、本発明では、関係データベースに合わせて正規化され、永続化されていないあらゆるものは、非構造化データとみなす。したがって、ＸＭＬデータ型のものである列は、この「非構造化データ」の定義に該当することになる。ＸＭＬデータは、本発明で概説するハードウェアアクセラレートされた探索および統合の最有力候補である。
【００１７】
メタデータ：本明細書で使用する場合、データオブジェクトおよびドキュメントの文脈における「メタデータ」という用語は、データオブジェクトまたはドキュメントを記述し、または特徴付けるデータをいう。オブジェクトおよびドキュメントのメタデータの例には、それだけに限らないが、ファイル型、バイトサイズ、作成日、最終変更日、著者、表題、ドキュメント／オブジェクトのデータソースに関する情報（任意選択で、ドキュメントを作成するのに使用されたプログラムの名称およびバージョン番号を含む）、データが他のデータとマッチするかどうかに関する情報、主題対象、分類情報（ドキュメント／オブジェクトの概念に関する情報、ドキュメント／データオブジェクト内に含まれる人名／地名／企業名、語数カウントなど）、ドキュメント／オブジェクト内のデータに関連する位置情報、ドキュメント／オブジェクトに関する他の内容から派生する情報が含まれる。
【００１８】
バス：本明細書で使用する場合、「バス」という用語は、装置および場所がそのアドレスによりアクセスされる任意の物理的相互接続を含む論理バスをいう。本発明の実施に際して使用され得るバスの例には、それだけに限らないが、ＰＣＩバスファミリ（ＰＣＩ−ＸやＰＣＩ−Ｅｘｐｒｅｓｓなど）およびＨｙｐｅｒＴｒａｎｓｐｏｒｔバスが含まれる。
【００１９】
パイプライン化：本明細書で使用する場合、「パイプライン」、「パイプライン化シーケンス」、または「連鎖」という用語は、あるアプリケーションモジュールの出力が、シーケンス内の次のアプリケーションモジュールの入力に接続されているアプリケーションモジュールの配列をいう。このパイプライン化配列は、各アプリケーションモジュールが、所与のクロックサイクルの間に受け取る任意のデータを独立に操作し、次いで、別のクロックサイクルの間にその出力をシーケンス内の次の下流側アプリケーションモジュールに渡すことを可能にする。
【００２０】
全文検索：本明細書で使用する場合、「全文検索」という用語は、ドキュメントまたはオブジェクトの全体を通してスキャンし、あらゆる単語またはバイトを考慮することをいう。この処理は、近似、柔軟なスキーマでのタグ付けに基づくトークン化、ワイルドカード処理、または複雑なマッチングを可能にし得る。
【００２１】
ＳＱＬ対応クライアントアプリケーション：本明細書で使用する場合、クライアントアプリケーションの文脈における「ＳＱＬ対応の」という用語は、関係型のＳＱＬベースのデータベースサーバにアクセスすることのできるクライアントアプリケーションをいう。ＡＮＳＩ標準のＳＱＬ言語は、いずれも関係型のＳＱＬベースのデータベースサーバにアクセスすることのできる、多数の高度なソフトウェアクライアントアプリケーションの進化を可能にしている。これらのＳＱＬ対応クライアントアプリケーションの例には、ビジネスインテリジェンス（ＢＩ）報告ツール、抽出転送ロード（ＥＴＬ）ツール、企業体用ソフトウェアアプリケーション（ＥＲＰ、ＣＲＭ、ＳＡＰ）、ミドルウェア、および様々なプログラミング言語で書かれた多数の任意の特注アプリケーションなどが含まれる。
【００２２】
ビジネスインテリジェンス報告ツール：本明細書で使用する場合、「ビジネスインテリジェンス報告ツール」（または「ＢＩ報告ツール」）という用語は、関係データベースへの探索問い合わせを作成し、報告書を生成、提示するための、ユーザが使いやすいグラフィカルインターフェース（ＧＵＩ）を提供するソフトウェアアプリケーションをいう。ＢＩ報告ツールは、ユーザ指定の図形的に作成された問い合わせを、ＳＱＬコマンドなどの標準化データベース問い合わせに変換する。次いで、そのように作成されたＳＱＬコマンドが、所望のデータの検索を実行するためにＲＤＢＭＳに送られる。
【００２３】
テキスト解析およびテキストマイニング：本明細書で使用する場合、「テキスト解析」および「テキストマイニング」という用語は、意味論のような複雑な言語概念を使ってドキュメントオブジェクトを操作するアルゴリズムをいう。テキスト解析／テキストマイニング処理の例には、名前付きエンティティ認識、内容抽出、ドキュメント分類、ドキュメント要約、自然言語処理、統計パターン学習、および関連性ランク付けが含まれる。
【００２４】
企業体はそのデータを多種多様な方法で格納、管理し続ける。企業体がそのデータを格納するための１つの方法が、関係データベース管理システム（ＲＤＢＭＳ）を使ったデータベース内に格納するものである。このようなＲＤＢＭＳに格納された、表形式の正規化されたデータを一般に構造化データという。例えば企業体は、その売上記録および顧客情報を、書式設定し、不要な情報を除去し、適合させ、構造化データとしてＲＤＢＭＳ内に格納する。当分野では、典型的には構造化照会言語（ＳＱＬ）などの標準化データ言語に基づいてこのような構造化データにインテリジェントにアクセスするための様々な公知のツールが開発されている。
【００２５】
しかし一般にこのような表形式の構造化データは、企業体の格納データ全体のごくわずかな部分を表すにすぎないものであると推定される。格納データの残りの部分は典型的には、その記憶が企業体内の多種多様なファイルシステムおよび記憶手段の間に拡散しているのが普通である非構造化データで構成されている。非構造化オブジェクトおよびドキュメントの爆発的増加により、多くの企業体が深刻な「情報過負荷」状態に陥っている。このすべての構造化データおよび非構造化データにインテリジェントに、統合的にアクセスすることは、難しい課題を提起する。この課題を難しくする一因は、多くの企業体では、企業体の非構造化データの記憶が各データベースから、しばしば異なる組織部門によって別々に管理されていることである。多くの組織が直面している大きな課題が、その関係データベース内の構造化データを、ＢＬＯＢを含む、この比較的整理されていない大量の他の非構造化データと効率よく、効果的に統合することである。構造化データは、テキスト解析を使って、「なにが？」、「どこで？」、「いつ？」、「だれが？」のような比較的単純明快な質問への回答を提供することができ、非構造化データは「なぜ？」のようなより複雑な質問に回答することができる。
【００２６】
図１にこの問題を示す。多くの企業体では、すべてのドキュメントが、企業体全体に広がっているいくつかの別々のサーバの間のどこに位置しているかに関しての整理がほとんど行われていない。例えば、企業体がそのデータを格納するための記憶空間１０２は、ドキュメント管理システムＡ１０４、ネットワークファイルサーバＢ１０６、アプリケーションサーバＣ１０８といった別々の構成要素の間に拡散している。この記憶空間内の所望のドキュメントにアクセスし、所望のドキュメントを探し出すために、ユーザ１００は、異なる各構成要素にアクセスするのに異なるツールを使用せざるを得なくなる可能性が高い（例えば、システム１０４にアクセスするのにカスタムアプリケーションを使用し、サーバ１０６にアクセスするのにＷｉｎｄｏｗｓ（登録商標） Ｅｘｐｌｏｒｅｒなどのソフトウェア製品を使用し、サーバＣにアクセスするのにカスタムアプリケーションプログラミングインターフェース（ＡＰＩ）を使用するなど）。インターネット１１０上でデータの探索を行うには、さらに別のツール（Ｇｏｏｇｌｅなどのウェブサーチツール）が使用される可能性が高いはずである。このようにドキュメントの場所およびアクセス手段が乱雑な寄せ集めになっていると、ユーザは、記憶空間１０２内のどこに目的のドキュメントが位置しているか熟知していなければならないだけでなく、異種の構成要素１０４、１０６および１０８にアクセスするためのいくつかの異なるツールの使い方にも習熟していなければならない。しかも、図１に示すような企業体探索機能によってユーザは、関係データベース内に格納されている他の企業体データに直接アクセスし、これらと自分の探索を相関させることができない。
【００２７】
ユーザの探索が何らかの形の全文検索を含むとき、このような全文照会をサポートするソフトウェアはしばしば、特に問い合わせが多くの長いドキュメントの本文全体をスキャンすることを必要とするときには、完了するのに比較的長い時間を要する。これが遅いのは、一部には、従来のソフトウェアを実行するときの汎用プロセッサ（ＧＰＰ）の性能に関する固有の制約条件のためである。現在の索引付け法には、「発見能力（ｆｉｎｄ−ａｂｉｌｉｔｙ）」の実現に大きな限界がある。索引付けは関連するドキュメントを探し出すのに幾分役立つこともあるが、つづり間違い、交替するつづりの変形、正規表現を探索するタスク、または多数の用語を探索するタスクは、現在の索引付け法では容易にも、迅速にも解決されない問題であり、効果的な索引を作成するための時間に対応できなくなることが多い。言い換えると、何かの発見に役立つ効果的な索引を構築するためには、何を発見しようとしているのかがあらかじめ分かっていなければならない。従来のシステムにおける欠点の一例は、つづり間違いを探索するための容易な、または標準的な方法がないことである。この問題は、データが動的であり、または絶えず変化する状況においてはさらに悪化する。
【００２８】
構造化データに関しては、ＳＱＬは、多くの関係データベースに対して標準化された一貫性を有するプログラミングインターフェースを提供することができるため、産業において広範囲に配備されている。しかし、本発明者らは、構造化データのためのＳＱＬと、非構造化データに対する全文検索機能（またはテキスト解析やテキストマイニングといった他の処理機能）との統合を標準化しようとする現行の試みには改善が必要であると認識している。これらの試みの実現形態は、しばしば、性能上の障害を明確に示している。標準ＳＱＬを、構造化された表形式のデータと様々な形の非構造化データとを統合するように拡張しようとするいくつかの取り組みが行われている。例えば、半構造化ＸＭＬデータへの関係型アクセスのためのＳＱＬ／ＸＭＬ、非構造化マルチメディアデータのためのＳＱＬ／ＭＭ、非構造化外部データのためのＳＱＬ／ＭＥＤ、正規表現、ワイルドカード、語幹抽出、シソーラスおよびブール演算を使ってＸＭＬデータを探索するＸＱｕｅｒｙ１．０およびＸＰａｔｈ２．０Ｆｕｌｌ−Ｔｅｘｔ１．０などである。本発明者らは、非構造化データを処理するこれらのＳＱＬ拡張機能の大部分が、一貫性を欠く、種々雑多な言語の寄せ集めを表すものであり、それがこれらの拡張機能のＩＴ業界における普及を妨げていると考えている。本発明者らの考えでは、重大な性能上の問題がしばしばこれらの標準化の取り組みを遅らせている可能性が高い。
【００２９】
また、ＳＱＬの普及の結果として、いくつかのビジネスインテリジェンス（ＢＩ）報告ツールも開発されている。本発明者らは、非構造化テキスト解析をサポートする報告ツールの機能は比較的限られており、当分野では、この領域における改善が求められていると考えている。これらのソフトウェアツールの大部分は、非構造化データに対する全文検索、および他の高度なテキストマイニングおよび解析を実行するための、比較的限られた能力しか備えていない。重ねていうが本発明者らは、各ツールの性能は特に有効なものになっていないと考えている。
【先行技術文献】
【特許文献】
【００３０】
【特許文献１】米国特許第６７１１５５８号明細書
【特許文献２】米国特許第７１３９７４３号明細書
【特許文献３】米国特許出願公開２００６／０２９４０５９号明細書
【特許文献４】米国特許出願公開２００７／００６７１０８号明細書
【特許文献５】米国特許出願公開２００７／０１３０１４０号明細書
【特許文献６】米国特許出願公開２００７／０１７４８４１号明細書
【特許文献７】米国特許出願公開２００７／０２３７３２７号明細書
【発明の概要】
【発明が解決しようとする課題】
【００３１】
したがって本発明者らは、当分野には、非構造化データへのより高速で、統合的なアクセスを可能とするシステムが大いに求められていると考えている。さらに本発明者らは、当分野には、構造化データと非構造化データを相互に連係させ、統合して、非構造化データのインテリジェントなアクセスをサポートするためのより良い方法も求められていると考えている。
【課題を解決するための手段】
【００３２】
これらの目的のために、本発明者らは、従来の標準に基づく構造化データの問い合わせ処理と緊密に統合された方法で、問い合わせ処理時に、より複雑な非構造化データ解析のハードウェアアクセラレーションを活用するように構成された新規の方法およびシステムを開示する。その際に本発明は、好ましくは、以下の特許明細書および特許出願明細書に開示されている基礎をなすハードウェアアクセラレーション技術を利用する。「Ａｓｓｏｃｉａｔｅｄ Ｄａｔａｂａｓｅ Ｓｃａｎｎｉｎｇ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ」という名称の米国特許第６７１１５５８号明細書、「Ａｓｓｏｃｉａｔｉｖｅ Ｄａｔａｂａｓｅ Ｓｃａｎｎｉｎｇ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許第７１３９７４３号明細書、「Ｉｎｔｅｌｌｉｇｅｎｔ Ｄａｔａ Ｓｔｏｒａｇｅ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許出願公開第２００６／０２９４０５９号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｅｒｆｏｒｍｉｎｇ Ｂｉｏｓｅｑｕｅｎｃｅ Ｓｉｍｉｌａｒｉｔｙ Ｓｅａｒｃｈｉｎｇ」という名称の米国特許出願公開第２００７／００６７１０８号明細書、（２００７年８月１０日に出願された米国出願第１１／８３６９４７号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｔｅｉｎ Ｓｅｑｕｅｎｃｅ Ａｌｉｇｎｍｅｎｔ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許出願公開第＿＿＿＿＿号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｒｅｇｕｌａｒ Ｅｘｐｒｅｓｓｉｏｎ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」という名称の米国特許出願公開第２００７／０１３０１４０号明細書、（２００６年５月２日に出願された米国出願第１１／３８１２１４号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｐｐｒｏｘｉｍａｔｅ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」という名称の米国特許出願公開第＿＿＿＿＿号明細書、「Ｆｉｒｍｗａｒｅ Ｓｏｃｋｅｔ Ｍｏｄｕｌｅ ｆｏｒ ＦＰＧＡ−Ｂａｓｅｄ Ｐｉｐｅｌｉｎｅ Ｐｒｏｃｅｓｓｉｎｇ」という名称の米国特許出願公開第２００７／０１７４８４１号明細書、および「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ Ｂｌｏｃｋｗｉｓｅ Ｉｎｄｅｐｅｎｄｅｎｔ Ｅｎｃｒｙｐｔｉｏｎ／Ｄｅｃｒｙｐｔｉｏｎ」という名称の米国特許出願公開第２００７／０２３７３２７号明細書。各特許明細書および特許出願明細書の開示全体を参照により本明細書に組み込むものとする。
【００３３】
このハードウェアアクセラレーションは、ハードウェアアクセラレーションに適した問い合わせ処理の部分（非構造化データに対して実行される全文検索操作など）に対して適用される。どの非構造化データがハードウェアアクセラレートされたデータ処理操作に適用されるべきかインテリジェントに限定するために（および、それによって全体の応答時間を早めるために）、本発明を実施するシステムは、データベースに格納された構造化データの索引付き問い合わせも用いることができる。好ましくはこれらの問い合わせは、ＲＤＢＭＳを対象とするＳＱＬコマンドといった、標準化された索引付きデータベース問い合わせとして作成される。このように、ユーザは構造化データと非構造化データの両方を対象とする問い合わせを、よく知る方法で作成することができる。本発明の好ましい実施形態によるＡＰＩを用いれば、問い合わせ処理を、構造化データ部分とハードウェアアクセラレートされた非構造化データ部分とに効果的に分岐させることができる。
【００３４】
ハードウェアアクセラレートされたデータ処理操作は、好ましくは、前記の特許明細書および特許出願明細書に記載されているように、ＧＰＰとは別のコンピュータリソース（好ましくは、ファームウェアが展開されている再構成可能論理回路といったコプロセッサ）によって実行される。このためにコプロセッサを利用することにより、ＧＰＰによって実行される従来のソフトウェアを使って非構造化データの全文検索を実行する従来の解決法と比べて、問い合わせ処理の著しいアクセラレーションが達成され、それによってシステムの（１つまたは複数の）ＧＰＰを他のシステムタスクを実行するために解放することができる。
【００３５】
問い合わせ処理プロセスに役立つ構造化され、索引付けされたデータは、少なくとも一部は、オブジェクト（ドキュメントなど）のメタデータを含むことが好ましい。このメタデータには、好ましくはＲＤＢＭＳ内の構造化関係表に格納されており、非構造化データのどの部分がコプロセッサに流されるべきか特定するために、ＳＱＬコマンドなどの標準化された問い合わせを使って問い合わせることができる。実際、一態様によれば、本発明は本質的にはコプロセッサのデータ処理機能をＳＱＬ対応にする。
【００３６】
好ましくは、メタデータで索引付けされた非構造化データは、非構造化データのためのデータ処理機能が展開されているコプロセッサを用いた機器内の高性能ディスク空間内に格納されている。このように、ネットワーク帯域幅の制約条件なしで、非構造化データをコプロセッサに流すことができる。また非構造化データは、高速ネットワークを介して機器２００からアクセス可能などこかに格納することもできる。
【００３７】
本発明者らはさらに、非構造化オブジェクトからのメタデータの生成も、コプロセッサを使って（好ましくは、適切なファームウェアが展開されている再構成可能論理回路の形のコプロセッサを使って）ハードウェアアクセラレートすることができることを開示する。メタデータを生成すべき非構造化オブジェクトを適切に構成されたコプロセッサに流し、それによってその非構造化データに索引付けするのに使用されるメタデータの生成を迅速化することができる。このメタデータ生成に続いて、これらの非構造化オブジェクトの本体全部が、好ましくは、機器のディスク空間に取り込まれる。
【００３８】
またメタデータは、好ましくは、機器の内部のＲＤＢＭＳに格納されるが、本発明の好ましい実施形態の問い合わせ処理機能の一部として、機器の外部にある別の関係データベースに格納された構造化データにもアクセスすることができることに留意すべきである。
【００３９】
本発明者らは、後述する一般的なデータ探索に加えて、本発明を無数の用途に適用することができるものと予想している。例えば、保健医療の症例管理においては、臨床研究データベース、患者記録データベース、保険および法的ファイルのデータベース、法規則データベースといった多種多様なデータソースを、本明細書で説明する機器によって統合し、それによって、診断の向上、誤診の低減、適切な治療の保証、サービス品質の向上、利用可能なリソースの利用率増大、不正行為の低減、費用の管理その他の目標に関して、保健医療組織の機能を強化することができる。
【００４０】
科学分野では、科学的臨床的文献、治療記録および報告書、化合物データベース、医薬データベース、医学的症状データベースなどといった異種のデータソースを、本明細書で説明する機器を使って統合することができる。このように、望ましい目標には、生物医学的および化学的成分、遺伝標識、例えばタンパク質や遺伝子、塩基配列などと、諸症状、すなわち、「ＡはＢを阻害する」、「ＡはＢを活性化する」、「ＡはＢと関連付けられる」といったパターンの間の関係を抽出することなどが含まれる。成分抽出とは、この文脈では、ドメイン辞書に基づく生物医学テキストおよび化学テキストから遺伝子、化学物質、症状および症候群の名称および徴候を認識することをいう。
【００４１】
諜報およびテロ対策の分野では、報道および調査報告書、通信傍受、ドキュメント、ならびに事件ファイル（すべて様々な言語で書かれている）といった異種のデータソースを、本明細書で説明する機器によって統合することができる。このデータへの統合的でインテリジェントなアクセスによって検出することのできる目標およびパターンには、組織的結社およびネットワーク、行動／攻撃パターン、脅威評価、戦略策定、戦術評価、および事件予測が含まれる。
【００４２】
法執行分野では、本明細書で説明する機器を使って、諜報／テロ対策分野と同様のデータソースを、犯罪および裁判報告書、法律文書、ならびに地理的、人口統計学的データと共に統合することができる。このような統合の目標には、犯罪パターン（時間的、地理空間的、対人的、および／または組織的）の検出、ならびに犯罪捜査および訴追の支援が含まれるはずである。
【００４３】
有価証券詐欺行為探知の分野では、金融報告書および報道、企業ファイルおよびドキュメント、売買その他の取引記録といった異種のデータソースすべてを、本明細書で説明する機器を使って統合し、それによって、インサイダー取引、報告違反、マネーロンダリング、不法取引、価格異常といった行為を探知する能力を高めることができる。
【００４４】
顧客関係管理（ＣＲＭ）の分野では、顧客電子メールおよび書簡、コールセンターメモおよび転写記録、ならびに既存のＣＲＭシステムに維持されている他の顧客データといった異種のデータソースを、本明細書で説明する機器を使って統合することができる。このような統合により、おそらくは、製品およびサービス品質の問題を特定し、製品設計および管理に役立てることができる。
【００４５】
評判管理の分野では、異種のデータソースには報道、ウェブページおよび市場分析が含まれ、これらのデータソースを本明細書で説明する機器を使って統合して、企業体と社会との関係の状態を明らかにするテキストマイニングおよびパターン検出操作を実行することができる。
【００４６】
同様に、本明細書で説明する機器は、個人と組織とのつながりを判断するために電子メールその他の通信、企業ドキュメント、および報道を分析する社会的ネットワーク分析ツールとして使用することもできる。
【００４７】
本明細書で説明する機器を展開するための機が熟していると考えられる他の領域には、業務管理、競争インテリジェンス（ｃｏｍｐｅｔｉｔｉｖｅ ｉｎｔｅｌｌｉｇｅｎｃｅ）、法的開示（例えば、訴訟の原告が、「ジョンスミス」に関連する、維持されており、または被告の管理下にあるすべてのデータを要求する場合など）、コンテンツ権利管理、法規順守その他が含まれる。
【００４８】
さらに、本明細書で説明する発明は、内容から導出されるメタデータの自動生成を含めて、データに対して実行されるメタデータ生成操作を著しく速めるのに使用することができる。
【００４９】
本発明の前記その他の特徴および利点は、以下の説明および図面を考察すれば当業者には明らかになるであろう。
【図面の簡単な説明】
【００５０】
【図１】企業体がユーザに企業体のデータへのアクセスを可能にするための従来の方法を示す図である。
【図２】本発明の例示的実施形態を示す図である。
【図３】本発明の一実施形態によるドキュメント取込み前処理操作の概要を例示する図である。
【図４】本発明の一実施形態による探索機器を例示する図である。
【図５】本発明の一実施形態によるドキュメント取込み前処理操作を例示する論理図である。
【図６】本発明の一実施形態によるドキュメント取込み前処理操作のための図４の探索機器内のデータフローを例示する図である。
【図７ａ】図４の探索機器において使用するためのプリント回路基板を例示する図である。
【図７ｂ】図４の探索機器において使用するためのプリント回路基板を例示する図である。
【図８】どのようにしてファームウェアパイプラインが複数の再構成可能論理回路にわたって展開され得るかを例示する図である。
【図９】本発明の一実施形態による問い合わせ処理操作の概要を例示する図である。
【図１０ａ】どのようにして関係データベースとの対話が実行されるかに関してプロセッサとコプロセッサとの間の関係を例示する図である。
【図１０ｂ】図１０ａに対応する本発明の一実施形態による問い合わせ処理操作を例示する流れ図である。
【図１０ｃ】図１０ａに対応する本発明の一実施形態による問い合わせ処理操作を例示する論理図である。
【図１１ａ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｂ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｃ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｄ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｅ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｆ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１１ｇ】本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１２】問い合わせの少なくとも一部が探索機器の外部に位置するドキュメントに対して実行される、本発明の一実施形態による問い合わせ処理操作の概要を例示する図である。
【図１３】問い合わせによって指定された構造化データを検索するために探索機器の外部にあるＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作の概要を例示する図である。
【図１４】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作を例示する論理図である。
【図１５ａ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｂ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｃ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｄ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｅ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｆ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｇ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１５ｈ】問い合わせによって指定された構造化データを検索するために外部ＲＤＢＭＳがアクセスされる、本発明の一実施形態による問い合わせ処理操作のための、図４の探索機器内でのデータフローを例示する図である。
【図１６】問い合わせを処理するために探索機器によって実行されるＡＰＩの処理フローを例示する図である。
【図１７ａ】ドキュメント取込み前処理操作および問い合わせ指定のデータ処理操作を実行するためにどのようにしてＦＡＭパイプラインを再構成可能論理回路上に展開することができるかを例示する図である。
【図１７ｂ】ドキュメント取込み前処理操作および問い合わせ指定のデータ処理操作を実行するためにどのようにしてＦＡＭパイプラインを再構成可能論理回路上に展開することができるかを例示する図である。
【図１８ａ】構造化データおよび非構造化データが共通データストアに格納されている例示的実施形態を示す図である。
【図１８ｂ】構造化データおよび非構造化データが共通データストアに格納されている例示的実施形態を示す図である。
【発明を実施するための形態】
【００５１】
図２に、企業体機器２００が、ユーザコンピュータ１００のユーザに、（関係データベース２１０によって格納されているような）構造化データと、（構成要素１０４、１０６および１０８を介して、またはインターネット１１０を介して格納され、アクセスすることのできるような）非構造化データへのインテリジェントで、統合的なアクセスを可能にするように構成されている本発明の好ましい実施形態の概要を示す。機器２００の実施形態を探索機器と呼ぶこともできるが、本明細書で説明するように、機器２００により、探索以外に、または探索に加えて他のデータ解析機能をサポートすることもできることに留意すべきである。
【００５２】
好ましくは、探索機器２００は、ハードウェアアクセラレートされたデータ処理機能はもとより、少なくとも一部は構造化データを対象とする問い合わせを処理する問い合わせ処理ＡＰＩも用いる。図４に、機器２００の好ましい実施形態を示す。機器２００内には、コプロセッサ４５０が、ディスクコントローラ４１４および４１６、ならびに（直接、またはＲＡＭ４０８などのシステムメモリ経由で間接的に）データストア３０４および３０６によって定義されるディスクサブシステムと、（ネットワークインターフェース４１０を介した）ネットワーク４２０の一方または両方から流されるデータを受け取るように配置されている。データストア３０４は、構造化関係データが格納されているＲＤＢＭＳを備え、データストア３０６は、非構造化データが格納されているファイルシステムを備える。しかし、非構造化データは、以下で図１８ａおよび図１８ｂに関連して説明するように、任意選択でＲＤＢＭＳ３０４内の非構造化データ列に格納されてもよいことに留意すべきである。ネットワーク４２０は、好ましくは、多種多様なドキュメントストア３０８（構成要素１０４、１０６および／または１０８）が位置する企業体ネットワーク（ＬＡＮであれＷＡＮであれ）を備える。データストア３０４は構造化データのためのデータストアとして特徴付けられているが、データストア３０４は、任意選択で、やはり取込みおよび問い合わせ処理の対象とし得る非構造化データＢＬＯＢを含んでもよいことに留意すべきである。
【００５３】
好ましい実施形態では、コプロセッサ４５０は、再構成可能論理回路４０２を備える。好ましくは、データはシステムバス４０６を介して再構成可能論理回路４０２に流れ込むが、他の設計アーキテクチャも可能である（図７ｂ参照）。好ましくは、再構成可能論理回路４０２はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）であるが、そうでなくてもよい。また、システムバス４０６は、再構成可能論理回路４０２と、機器のプロセッサ４１２および機器のＲＡＭ４０８とを相互接続することもできる。好ましい実施形態では、システムバス４０６はＰＣＩ−ＸバスまたはＰＣＩ−Ｅｘｐｒｅｓｓバスとすることができるが、そうでなくてもよい。
【００５４】
データストア３０６は任意のデータ記憶装置／システムとすることができるが、好ましくは、何らかの形の大容量記憶媒体である。例えば、データストア３０６は、ディスクアレイなどの磁気記憶装置とすることができる。しかし、本発明の実施に際しては他の種類の記憶媒体も使用に適することに留意すべきである。
【００５５】
プロセッサ４１２およびＲＡＭ４０８によって定義されるコンピュータシステムは、当分野の技術者が理解するような任意の市販のコンピュータシステムとすることができる。例えばコンピュータシステムは、ＩｎｔｅｌのＸｅｏｎシステムや、ＡＭＤのＯｐｔｅｒｏｎシステムなどとすることができる。したがって、機器２００の中央または主プロセッサとして使用されるプロセッサ４１２は、好ましくは、ＧＰＰを備える。
【００５６】
再構成可能論理回路４０２には、その機能を定義するファームウェアモジュールが展開されている。ファームウェアソケットモジュール４０４は、再構成可能論理回路との間のデータ移動要件（コマンドデータとターゲットデータの両方）を処理し、それによって、やはり再構成可能論理回路上に展開されているファームウェアアプリケーションモジュール（ＦＡＭ）連鎖３５０に一貫性のあるアプリケーションインターフェースを提供する。ＦＡＭ連鎖３５０の各ＦＡＭ３５０ｉは、ファームウェアソケットモジュール４０４から連鎖３５０に流れる任意のデータに対して指定されたデータ処理操作を実行するように構成されている。以下で、本発明の好ましい実施形態による再構成可能論理上に展開され得る好ましいＦＡＭの例を説明する。
【００５７】
ＦＡＭによって実行される特定のデータ処理操作は、ＦＡＭがファームウェアソケットモジュール４０４から受け取るコマンドデータによって制御／パラメータ化される。このコマンドデータはＦＡＭ特有のものとすることができ、コマンドを受け取るとＦＡＭは、受け取ったコマンドによって制御されるデータ処理操作を実行するように編成される。例えば、完全マッチ操作を実行するように構成されたＦＡＭ内では、ＦＡＭの完全マッチ操作は、完全マッチ操作を実行するための（１つまたは複数の）キーを定義するようにパラメータ化され得る。このようにして、完全マッチ操作を実行するように構成されたＦＡＭに１つまたは複数の異なるキーの新しいパラメータをロードするだけで、そのＦＡＭを、別の完全マッチ操作を実行するように容易に編成し直すことができる。
【００５８】
ＦＡＭは、受け取ったコマンドによって指定されるデータ処理操作を実行するように編成された後で、ファームウェアソケットモジュールから受け取るデータストリームに対して、コマンドで指定されたデータ処理操作を実行することができるようになる。よってＦＡＭは、指定されたデータストリームを指定された方法で処理するための適切なコマンドによって、編成されることができる。ＦＡＭがそのデータ処理操作を完了すると、そのＦＡＭには、ＦＡＭによって実行されるデータ処理操作の性質を変更するようＦＡＭを再編成させる別のコマンドを送ることができる。ＦＡＭは、ハードウェア速度で動作（し、ＦＡＭを介して高スループットの目標データを提供）するのみならず、そのデータ処理操作のパラメータを変更するよう柔軟にプログラムし直すこともできる。
【００５９】
ＦＡＭ連鎖３５０は、好ましくは、パイプライン化シーケンスとして配列された複数のファームウェアアプリケーションモジュール（ＦＡＭ）３５０ａ、３５０ｂ、．．．を備える。しかし、ファームウェアパイプライン内には、ＦＡＭ３５０ｉの１つまたは複数の並列経路を用いることもできることに留意すべきである。例えばファームウェア連鎖は、相互に並列な、第１のパイプライン化経路として配列された３つのＦＡＭ（ＦＡＭ３５０ａ、３５０ｂ、３５０ｃなど）と、第２のパイプライン化経路として配列された４つのＦＡＭ（ＦＡＭ３５０ｄ、３５０ｅ、３５０ｆおよび３５０ｇなど）とを含んでもよい。さらに、ファームウェアパイプラインは、既存のパイプライン経路から分岐する１つまたは複数の経路を備えることもできる。本発明の実施者は、所与の用途の処理要件に基づき、ＦＡＭ連鎖３５０の適切なＦＡＭ配列を設計することができる。
【００６０】
通信路４３０は、ファームウェアソケットモジュール４０４を、パイプライン化ＦＡＭの第１のＦＡＭ３５０ａの入力と接続する。第１のＦＡＭ３５０ａの入力は、ＦＡＭ連鎖３５０への入口点として使用される。通信路４３２はパイプライン化ＦＡＭ３５０ｍの最後のＦＡＭの出力を、ファームウェアソケットモジュール４０４と接続する。最後のＦＡＭ３５０ｍの出力は、ＦＡＭ連鎖３５０からの出口点として使用される。通信路４３０も通信路４３２も、好ましくは、マルチビット経路である。
【００６１】
特に、ファームウェアソケットモジュールとの間のデータフローに関連して、機器２００によって使用されるソフトウェアおよびハードウェア／ソフトウェアインターフェースがどういったものであるかは、前記の組み込まれた米国特許出願公開第２００７／０１７４８４１号明細書に詳細に記載されている。
【００６２】
図７ａに、機器２００においてコプロセッサ４５０として使用するために市販のコンピュータシステムのバス４０６に接続することのできるプリント回路基板またはカード７００を示す。図７ａの例では、プリント回路基板は、メモリ素子７０２およびＰＣＩ−Ｘバスコネクタ７０４と通信状態にあるＦＰＧＡ４０２（Ｘｉｌｌｉｎｘ Ｖｉｒｔｅｘ ＩＩ ＦＰＧＡなど）を含む。好ましいメモリ素子７０２は、ＳＲＡＭおよびＤＲＡＭメモリを含む。好ましいバスコネクタ７０４は標準カード端コネクタである。
【００６３】
図７ｂに、プリント回路基板／カード７００の代替の構成を示す。図７ｂの例では、プリント回路基板７００には、バス７０６（ＰＣＩ−Ｘバスなど）、１つまたは複数のディスクコントローラ７０８、およびディスクコネクタ７１０もインストールされている。当分野で理解されているように、任意の市販のディスクインターフェース技術がサポートされ得る。この構成では、ファームウェアソケット４０４は、プロセッサ４１２に、専用ＰＣＩ−ＸまたはＰＣＩ−ｅバス７０６を介して接続された（１つまたは複数の）ディスクへの通常のアクセスを可能にするためのＰＣＩ−Ｘ／ＰＣＩ−Ｘ（またはＰＣＩ−ｅ／ＰＣＩ−ｅ）ブリッジとしても使用される。図３ｂに示すディスクコントローラおよびディスクコネクタに加えて、またはこれらの代わりにネットワークインターフェースを使用することができることに留意すべきである。
【００６４】
図７ａまたは図７ｂの構成において、ファームウェアソケット４０４は、メモリ７０２をＰＣＩ−Ｘバスからアクセス可能にすることができ、それによって、ＯＳカーネルがメモリ７０２を、ディスクコントローラおよび／またはネットワークインターフェースコントローラからＦＡＭへ転送するためのバッファとして利用することが可能になることは注目に値する。また、図７ａおよび図７ｂのプリント回路基板上にはただ１つのＦＰＧＡ４０２しか示されていないが、プリント回路基板７００上に複数のＦＰＧＡを含めることにより、または機器２００に複数のプリント回路基板７００をインストールすることにより複数のＦＰＧＡをサポートすることができることが理解されるはずであることも注目に値する。図８に、１つのパイプライン内の多数のＦＡＭが複数のＦＰＧＡにまたがって展開されている例を示す。
【００６５】
本明細書で論じる例示的実施形態において、「ドキュメント」という用語は、本発明のシステムによって処理される非構造化データを記述するのに使用される。しかし、「ドキュメント」という用語の用法は例示のためのものにすぎず、本発明のシステムおよび方法を使って他の形の非構造化データを処理することもできることに留意すべきである。
【００６６】
機器２００の性能を向上させ得る任意選択の一構成が、大量の（おそらくはすべての）企業体のドキュメントを機器の搭載データストア３０６に取り込むことができる機能である。さらにその際に機器２００が、取り込む各ドキュメントに関するメタデータを構築することが好ましい。このドキュメントメタデータは、次いで、搭載するＲＤＢＭＳ３０４などの関係データベースシステムに格納することのできる構造化データを含む。
【００６７】
図３に、好ましい実施形態の一態様によるドキュメント取込み前処理の概要を示す。好ましくは、ユーザコンピュータ１００上に表示された何らかの形のドキュメント取込みＧＵＩ３００を介して、ユーザは、どの（１つまたは複数の）ドキュメントがデータストア３０６に取り込まれるべきか指定することができる。任意選択でユーザは、取り込まれるべき（１つまたは複数の）ドキュメントに関する様々な形のメタデータを打ち込むこともできる。しかし、コプロセッサ４５０（好ましくは、ファームウェア３５０が展開されている再構成可能論理回路４０２）は、所望のメタデータ生成操作を自動的に実行するように編成され得るため、これは必要になるとは限らない。ＧＵＩ３００を介した適切なユーザコマンドに応答して、企業体ネットワーク４２０を介してアクセス可能であるが、機器２００の外部にあるデータストア３０８に格納された１つまたは複数のドキュメント３１２が機器２００に送られる。機器２００が、ＮＴＦＳ、ＦＡＴ、ＣＩＦＳ、様々な特色を有するＵＮＩＸ（登録商標）ファイルシステムといった共通ファイルシステム上に格納されたドキュメントへのアクセス、ならびにＨＴＴＰを介したウェブアクセスを可能にするために用いるドキュメント検索機能３５２においては、様々なアダプタを用いることができる。
【００６８】
ファームウェアパイプライン３５０にある各ＦＡＭは、好ましくは、ＦＡＭが受け取るドキュメントに対してドキュメントメタデータ生成操作を実行するように編成されている。ファームウェア３５０において用いられ得るドキュメントメタデータ生成法の例には、それだけに限らないが、品詞タグ付け、情報およびエンティティ抽出、ドキュメント分類、ドキュメントクラスタ化、およびテキスト要約が含まれる。これらの操作は機能的には、１つまたは複数のドキュメントのデータストリームに対する一連の「変換」とみなすことができる。ドキュメントに対して実行され得るドキュメント分類操作の一例は言語分類を含む。言語分類では、ドキュメントを、ドキュメント内のテキストが最も密接にマッチする言語を特定するように構成されている統計的Ｎグラムアルゴリズムに適用することができる。別のドキュメント分類操作では、ドキュメントのある種の分類を知るために隠れマルコフモデル（ＨＭＭ）を用いることができる。さらに、ファームウェア３５０が正規表現パターンマッチングを用いてドキュメントに関する分類情報をさらに作成することもできる。例えば、使用され得るドキュメント分類器は、問題のドキュメントがクレジットカード番号を含むかどうか識別するフラグとすることができる。そのような場合、ファームウェア３５０は正規表現パターンマッチング操作を実施するＦＡＭを含むことができ、この正規表現パターンマッチング操作は、ＦＡＭに流されるドキュメントがクレジットカード番号のように見えるデータパターンを含むかどうか判定することを中心としてキー指定される。この操作の結果に基づき、クレジットカード標識メタデータを正または負に設定することができる。
【００６９】
従来のメタデータ生成操作の手法はこれらの操作をプロセッサ４１２などの主プロセッサによって実行されるソフトウェアに組み込んでおり、これは、前記のように、性能不足を示していると考えられる。本発明者らは、これらのメタデータ生成操作をコプロセッサ４５０に肩代わりさせることにより、著しいアクセラレーションを達成することができると考えている。メタデータ生成操作を実行するためのコプロセッサの使用に関するさらなる詳細は、前記の組み込まれた（Ｔｈｏｍｐｓｏｎ Ｃｏｂｕｒｎ代理人整理番号４４８２６／６５５９２として識別される）「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｄａｔａ Ｍｅｔａｔａｇｇｉｎｇ ａｎｄ Ｄａｔａ Ｉｎｄｅｘｉｎｇ Ｕｓｉｎｇ Ｃｏｐｒｏｃｅｓｓｏｒｓ」という名称の、本出願と同日に出願された、米国特許出願第＿＿＿＿＿号明細書に記載されている。
【００７０】
ファームウェア３５０の操作によって生成されたドキュメントメタデータ３１４は、次いでＲＤＢＭＳ３０４に格納することができ、そこでＲＤＢＭＳエンジンは、後で、データストア３０６内のどのドキュメントが、問い合わせ処理時にコプロセッサ４５０によってハードウェア速度で処理されるべきか特定するために、標準化されたデータベース問い合わせを使って問い合わせすることのできるこのドキュメントメタデータの索引を生成し、維持するように動作する。受け取られたドキュメント３１２がファームウェア３５０によって処理された後で、ドキュメント３１２を非構造化データのデータストア３０６に格納することにより、ドキュメント３１２を機器に取り込むことができる。メタデータ生成およびドキュメント取込みの動作は、好ましくは、ほぼリアルタイムで事実上同時に行われる。ドキュメントメタデータ３１４は、任意選択で、機器２００外部の構造化データベースに格納することもできることに留意すべきである。
【００７１】
図５に、このドキュメント取込み前処理を論理フローとして示す。ステップ１でユーザは、ＧＵＩ３００と対話して、機器２００に取り込むための新しいドキュメント３１２を特定する。ＧＵＩ３００は、任意選択で、ドキュメント３１２からどんなメタデータを生成すべきかユーザが指定することができるように構成されてもよい。次にステップ２で、ドキュメント３１２がその元の場所（企業体ドキュメントストア３０８、インターネットまたは企業体ネットワーク４２０からアクセス可能な他の何らかのネットワーク）から取り出される。次いでファームウェア３５０が、ドキュメント３１２に対してそのドキュメントメタデータ生成操作５００を実行してドキュメントメタデータ３１４を生成する。次いでステップ３で、ドキュメント３１２がデータストア３０６のファイルシステムに格納され、ドキュメントメタデータが（そのデータストア３０６のファイルシステムにおける場所を含めて）ＲＤＢＭＳ３０４の関係表に保存される。図６に、このデータフローを機器２００上に重ね合わせたものを示す。
【００７２】
このように、機器２００はこれ以後、ＲＤＢＭＳ３０４によって索引付けされたドキュメントメタデータ３１４を使って、どのドキュメントにコプロセッサ４５０による問い合わせ指定のデータ処理操作（全文検索操作など）を行うべきか判断するのに役立てることができる。さらに、機器２００内では標準化ＲＤＢＭＳ技術が活用されているため、所与の問い合わせ９０４を処理するときに、どのドキュメントにコプロセッサベースのデータ処理操作を行うべきか判断するのに、多くのユーザに周知の標準化データベース問い合わせを使用することができる。
【００７３】
一般には、関係データベース３０４は、ドキュメントメタデータ３１４の問い合わせを最適化するためにＢツリー索引などの索引付け法を使用することが好ましい。また、ハードウェアアクセラレートされたメタデータ生成によって生成され得る索引が豊富な情報を有するために、索引の効力を活用することによって、近接検索（すなわち、単語Ｘが単語ＹからＺ単語位置未満分だけ隔てられているインスタンスを検出する）を含む、洗練された全文検索操作を効率よく達成することができる。
【００７４】
さらに、企業体がその企業体データ処理操作に役立てるために機器２００を使用するときには、ドキュメント取込み前処理を、将来を見越して新規に作成されたドキュメントに対して適用するだけでなく、企業体の既存のドキュメントの全部または相当な部分に対して遡及的に適用することもできる。したがって、機器２００をインストールするときに、企業体は、効果的で、効率のよいドキュメント探索を可能にするために、図３、図５および図６に関連して詳述したように、機器を介して企業体のドキュメントの全部または相当な部分を取り込もうとしてもよい。しかし、図３、図５および図６に関連して説明した取込み前処理の対象とされるドキュメントは、機器２００の外部のドキュメントだけに限定される必要はないことに留意すべきである。前処理は、以前にメタデータ生成操作の対象とされたことのないデータストア３０６内のドキュメントにも、新規のメタデータ生成操作を必要とするドキュメントにも適用することができる。
【００７５】
また、ドキュメントがそこから前処理のために機器２００に取り込まれる記憶３０８は、企業体ネットワークを介してアクセス可能な任意のデータストア（企業体ネットワーク４２０内の企業体データストアや、企業体ネットワークの外部にあっても、企業体ネットワークからアクセス可能なデータストアなど）とすることができることにも留意すべきである。例えば、機器２００に取り込まれるドキュメントは、ウェブページなどのインターネットコンテンツとすることができる。
【００７６】
相当数のドキュメント３１２のためのドキュメントデータ３１４がＲＤＢＭＳ３０４に格納されると、機器２００はそれ以後ユーザ指定の問い合わせを処理することができるようになる。機器２００内のＡＰＩは、好ましくは、機器が、ＲＤＢＭＳ３０４内のドキュメントメタデータ３１４と対照して標準化データベース問い合わせを処理し、次いで、問い合わせの結果集合を使って、どのドキュメントが問い合わせ指定のデータ処理操作のためにコプロセッサ４５０に送られるべきか判定することを可能にするように構成されている。
【００７７】
図９に、どのようにしてこのような問い合わせを処理することができるかの概要を例示する。ユーザが自分のデスクトップ上で従来のＢＩ報告ツール９００にアクセスすることができ、このツール９００を介してユーザは、報告ツール９００を使用する際の訓練の一部としてすでに熟知している何らかの構文を使った所望の問い合わせ９０４を入力することができる。次いで報告ツール９００は、ユーザ指定の問い合わせ９０４から標準化データベース問い合わせ（ＳＱＬコマンド９０６など）を生成するように動作する。探索機器２００は、この標準化データベース問い合わせ９０６を受け取るように配置されている。機器２００は、（ＢＩ報告ツール９００がバス４０６に接続されている場合には）このような問い合わせをＢＩ報告ツール９００から直接受け取ることもでき、ネットワークインターフェース４１０を介してＢＩ報告ツール９００から間接的に受け取ることもできる。次いで探索機器２００によって実行されるＡＰＩ９０２が、ＳＱＬコマンド９０６をＲＤＢＭＳ３０４およびデータストア３０６に対して適宜適用するように動作する。好ましくは、ＡＰＩ９０２の操作は、機器のプロセッサ４１２によって実行される。しかし、ＡＰＩ機能の少なくとも一部は、任意選択で、コプロセッサ４５０によって展開されてもよいことに留意すべきである。好ましくは、このＡＰＩ９０２は、可能な場合には、既存のＡＮＳＩのＳＱＬ標準および拡張機能（ＳＱＬ／ＸＭＬ、ＳＱＬ／ＭＥＤ、ＳＱＬ／ＭＭ、ＸＭＬ／Ｆｕｌｌ−Ｔｅｘｔなど）に適合している。ＳＱＬ標準および拡張機能が所望の機能をサポートしていない場合、ＡＰＩのために（データベース用語で「外部処理手順」として類別され得る）外部機能を考案することができる。図１０ａにＡＰＩ９０２の好ましい実施形態を示す。以下で論じる図１６には、ＡＰＩ９０２の代替の実施形態が記載されている。
【００７８】
したがって、本発明の好ましい実施形態は、ＳＱＬ対応クライアントアプリケーションが、ＳＱＬコマンドを介してコプロセッサ４５０のハードウェアアクセラレートされた機能にアクセスすることができるようにするよう動作する。したがって、機器２００は、ＢＩ報告ツール９００などのＳＱＬ対応クライアントアプリケーションと統合することができるだけでなく、さらに、または代替として、他のＳＱＬ対応アプリケーションと統合することもできる。例えば機器２００は、様々な企業体ソフトウェアアプリケーション（ＥＲＰ、ＣＲＭ、ＳＡＰなど）、ミドルウェアプログラム、クライアントプログラム、多数のプログラミング言語のいずれかで書かれた（ＯＤＢＣやＪＤＢＣ接続などを使った）特注のプログラム、データベース３０４にリンクされている別のＳＱＬデータベースといったＳＱＬ対応アプリケーションのいずれかまたはすべてと統合することができる。
【００７９】
機器２００自体におけるＳＱＬ対応機能は、好ましくは、従来のＳＱＬリレーショナルエンジンソフトウェア９５０との、高性能の緊密な統合を含む。この一例が図１０ａに示されている。リレーショナルエンジンソフトウェア９５０は、関係データベースにアクセスするための従来の既製品のソフトウェアとすることができる。リレーショナルエンジン９５０による問い合わせ処理をコプロセッサ４５０と統合するために、リレーショナルエンジンソフトウェア９５０にいくつかのカスタマイズを加えることができる。所望の統合を達成するためのこの種のカスタマイズをもたらし得る方法の例としては、Ｃ言語による外部処理手順（ＳＱＬエンジンに動的にリンクされるカスタムライブラリ）、ユーザ定義の型および関数、ストアドプロシージャ、カスタムデータプロバイダなどがある。
【００８０】
例えば、ＳＱＬコマンドでいくつかの命令文に遭遇したときに所望の外部処理手順を呼び出すコードをリレーショナルエンジン９５０に加えることができる。この一例が図１０ｃに示されており、リレーショナルエンジン９５０は、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」という命令文を、（図１０ａにコプロセッサインターフェースソフトウェア９５２として示されている）外部プログラムを呼び出すものとして理解するように構成されている。リレーショナルエンジン９５０は、このような命令文に遭遇すると、以下で図１０ｂに関連して説明するように、コプロセッサインターフェースソフトウェア９５２を呼び出し、ＡＰＩソフトウェア９５２に適切なデータを渡してコプロセッサを望みどおりに機能させる。リレーショナルエンジン９５０のために、ＳＱＬコマンドにおいて遭遇する命令文によって異なる外部プログラムを呼び出し、それによって、コプロセッサ４５０を用いて異なる処理結果を達成するようないくつかの外部処理手順を考案することができることが容易に理解されるはずである。前記のように「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文は、コプロセッサを完全または近似マッチング操作のために構成する外部処理手順に結び付けることができ、「ｒｅｌｅｖａｎｃｅ ｒａｎｋｉｎｇ」文は、コプロセッサを、関連性の大きさに従ってデータオブジェクトを採点するように構成する外部処理手順に結び付けることができる。
【００８１】
機器２００がＭｙＳＱＬなどのオープンソースデータベースを用いて実施されている場合には、統合を、リレーショナルエンジンのソースコード自体の内部で直接達成することができる。オープンソースを用いた方法が提供する高い柔軟性があれば、ＡＰＩ９０２として使用することができ、クライアントアプリケーションとデータベース３０４との間のすべてのＳＱＬ要求を仲介するＳＱＬパーサ／インタプリタを開発することができる。ＡＰＩ９０２のためのＳＱＬパーサ／インタプリタ戦略の実装例は図１６に示されている。
【００８２】
図１０ａの実施形態に戻って、図１０ｂに、ストアドプロシージャ、外部処理手順、ユーザ定義の関数といったこのような標準ＳＱＬ拡張機能に基づくものである問い合わせ処理の解決法を実施するのに使用することのできる一連のステップを示す。図１０ｂは、同じ一連のステップ（１１０１から１１７０）を使用する図１０ｃと密接に結びついている。ステップ１１０１で、ＡＮＳＩ標準ＳＱＬコマンド９０６が構成され、ＳＱＬ対応クライアントアプリケーションを介して呼び出される。次にステップ１１１０で、リレーショナルエンジン９５０がプロセッサ４１２上で実行され、ＳＱＬコマンド９０６を構文解析して、ＲＤＢＭＳ３０４にどのようにして問い合わせすべきか決定する。オプティマイザヒントおよび様々なコード化法により、ＳＱＬ開発者は、処理の順序が保証され得るコマンドを構築することができる。すなわち、オプティマイザヒントは、ＳＱＬコマンド９０６内の様々な命令文の間の適切な処理順序を定義することができる。図１０ｃを参照すると、リレーショナルエンジンは、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文を処理する前に「ｄａｔｅ＿ｌｏａｄｅｄ」文を満足させることを必要とするはずである。手近にあるタスクは、ＲＤＢＭＳ３０４によって格納されている索引付き表を使って、コプロセッサ４５０による全文スキャンを必要とするオブジェクトを限定しようとするものである。本質的にリレーショナルエンジン９５０は、構造化データを対象とする問い合わせの部分をＲＤＢＭＳ３０４に適用する（この問い合わせ部分は、図９および図１１ｂの例においてＳＱＬコマンド９０８として識別されている）。ステップ１１２０でＲＤＢＭＳ３０４は、ＳＱＬコマンド９０６の「ｄａｔｅ＿ｌｏａｄｅｄ」制約条件部分で表されている基準を、そのドキュメントメタデータ索引の内容と対照してマッチさせた後で、ドキュメントのリスト９１０を返す。ドキュメントリスト９１０で識別されるドキュメントは、好ましくは、データストア３０６内の各ドキュメントの場所によって識別することができる。ステップ１１２５で、リレーショナルエンジン９５０は次に、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文に遭遇し、この命令文は外部処理手順を呼び出すものとして理解される。次いでリレーショナルエンジン９５０は、「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文と結び付けられているコプロセッサインターフェースソフトウェア９５２を呼び出す。リレーショナルエンジン９５０は「ｔｅｘｔ＿ｃｏｎｔａｉｎｓ」文の後に問い合わせ文字列が続いたものをコプロセッサインターフェースソフトウェア９５２に渡し、さらにコプロセッサインターフェースソフトウェア９５２に、ステップ１１２０で生成されたファイルリスト９１０を知らせる。コプロセッサインターフェースソフトウェア９５２はさらには、好ましくは、コプロセッサ４５０に問い合わせ文字列を、問い合わせ指定のデータ処理操作を実行するのに適した構成となるようコプロセッサに命ずるコマンドと共に渡すことによって、コプロセッサの操作を指図する。次いでステップ１１３０で、リスト９１０によって識別された非構造化ドキュメントの本文全体がコプロセッサ４５０に読み込まれる。好ましくは、コプロセッサインターフェースソフトウェア９５２は、ディスクコントローラ４１６に、データストア３０６からリスト９１０に記載された非構造化ドキュメントを流すよう求める命令を出す。次いでデータストア３０６は、コプロセッサ４５０によって処理されるデータストリーム９１４として要求されたドキュメントをコプロセッサ４５０に提供する。次いでコプロセッサ４５０は、ハードウェア速度でデータストリーム９１４に対する指定されたデータ処理操作を実行し（ステップ１１４０）、従来の手法と比べて問い合わせ処理操作の大幅なアクセラレーションが実現される。次いで、コプロセッサ４５０によって検出された「ヒット」があれば、コプロセッサはそれをＲＡＭ４０８内の一時データベース表に結果集合９１６として返すことができる（ステップ１１５０）。コプロセッサインターフェースソフトウェア９５２は、さらには、リレーショナルエンジン９５０にこの結果集合９１６を知らせることができる。任意選択でステップ１１６０において、リレーショナルエンジン９５０は、結果９１６に対する任意の所望の集約、相互相関、または後続の解析を実行するようこれらの結果９１６を後処理することもできる。
【００８３】
次にステップ１１７０で、リレーショナルエンジン９５０は、好ましくは、報告ツール９００が求める書式に探索結果９１６を書式設定し、報告ツール９００はその既存の技術を使ってそれらの探索結果９１６をユーザに提示する。
【００８４】
産業界では多種多様なＢＩ報告ツール９００が使用されているため、ＡＰＩ９０２は、好ましくは、少なくとも主要なＢＩ報告ツールの大部分とインターフェースし得るように構成されている。例えば、探索機器２００によって維持される構成ファイルを、企業体内での探索機器２００の初期設定時に、探索機器２００が相互のデータ交換を可能にするために対話する相手となる特定のＢＩ報告ツール９００を識別するようにセットアップすることができる。
【００８５】
また、従来のＢＩ報告ツール９００を、探索機器２００とユーザの間のインターフェースとして使用しなくてもよいことにも留意すべきである。例えば、探索機器２００を、ＢＩ報告ツールと同じ基本機能を提供するように構成されている、ユーザに表示するための独自のＧＵＩを提供するように構成することもできる。このような場合には、ＡＰＩ９０２を、任意選択でユーザ指定の問い合わせ９０４をデータベース問い合わせ９０８に直接変換するように構成することもできる。
【００８６】
さらに、標準化された問い合わせ９０６は、ＢＩ報告ツール９００またはユーザから発せられなくてもよいことにも留意すべきである。ＢＩ報告ツール９００またはユーザから発せられるのではなく、問い合わせは、探索機器２００によって格納され、または知られているデータを呼び出す他の何らかの企業体アプリケーションから発せられてもよい。
【００８７】
また、本明細書で探索機器２００の一部として説明しているＡＰＩ９０２は、任意選択で、その全部または一部が、ＢＩ報告ツール９００または他の上位レベルアプリケーション内に位置してもよいことにも留意すべきである。
【００８８】
図１０ｃには、本発明の好ましい実施形態による簡単な問い合わせ処理操作の論理図が示されている。この例では、ユーザは、２００７年７月７日にロードされた、テキスト制約条件：「ｂｌａｓｔｎ」という単語の近くにある「ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ」という句、を含むデータストア３０６内のドキュメントを探索しようとしている。ユーザがＢＩ報告ツール９００にこの目標に向けた問い合わせを入力した後で、ＢＩ報告ツールは、図１０ｃに示すようなＳＱＬコマンド９０６を生成するように動作する。このＳＱＬコマンドは、問い合わせがそれと対照して処理されるべきＲＤＢＭＳ３０４内の表を指定する「ｓｅｌｅｃｔ」文を含む。次の命令文は、探索の条件を指定する「ｗｈｅｒｅ」文である。条件の１つは、ドキュメントがデータストア３０６にロードされた日付であり、この条件は２００７年７月７日に設定されている。次の条件は前記のテキスト条件である。リレーショナルエンジンは、図１０ｃに示すようにこのＳＱＬコマンド９０６を受け取り、解釈する（ステップ１１０１参照、図１１ａも参照）。
【００８９】
リレーショナルエンジン９５０は、前記のように、「ｄａｔｅ＿ｌｏａｄｅｄ」制約条件をドキュメントメタデータ項目として識別し、さらに、テキスト制約条件をコプロセッサ４５０によって解決されるべき問題として識別する。図１０ａおよび図１０ｂの実施形態に関して、リレーショナルエンジン９５０は、ＳＱＬコマンド９０６の「ｄａｔｅ＿ｌｏａｄｅｄ」部分に対応するＳＱＬコマンド９０８を使ってＲＤＢＭＳ３０４に問い合わせする（ステップ１１１０参照、図１１ｂも参照）。
【００９０】
次いでＲＤＢＭＳは、メタデータ索引３１４によって、「ｄａｔｅ＿ｌｏａｄｅｄ」制約条件にマッチするものとして識別されたすべてのドキュメントのリスト９１０を返し（すなわち、ＲＤＢＭＳ３０４はその場合、このＳＱＬコマンド９０８をそのドキュメントメタデータ索引に対して適用して、２００７年７月７日にデータストア３０６にロードされたすべてのドキュメントのリストを返すはずである）、このリスト９１０はＲＡＭ４０８に格納することができる（ステップ１１２０参照、図１１ｃも参照）。このリスト９１０は、好ましくは、２００７年７月７日にロードされた各ドキュメントが位置するデータストア３０４のファイルシステム内の場所を識別するものである。
【００９１】
また、ＡＰＩ９０２は（図１０ａおよび図１０ｂの実施形態ではＡＰＩ９５２を介して、ステップ１１２５参照）、データストア３０６にリスト９１０上のすべてのドキュメントの検索を求める要求９１２も出す（図１１ｄ参照）。また、ＡＰＩ９０２は（図１０ａおよび図１０ｂの実施形態ではＡＰＩ９５２を介して、ステップ１１２５参照）、コプロセッサのＦＡＭパイプライン３５０に送るために、「「ｂｌａｓｔｎ」の近くにある「ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ」」という条件を中心として構築された全文検索を実行するようにＦＡＭパイプラインを編成する制御信号１１００を生成するようにも動作する。次いでこの制御信号１１００は、好ましくは、ドキュメントがコプロセッサ４５０に到達する前にコプロセッサ４５０に送られる（好ましくは、コプロセッサ４５０上にあるファームウェアソケットモジュール４０４に送られる）（図１１ｅ参照）。
【００９２】
要求９１２に応答してデータストア３０６は、図１１ｅに示すように、コプロセッサ４５０に（好ましくは再構成可能論理回路４０２上のファームウェアに）送るためのデータストリーム９１４を出力する（ステップ１１３０も参照）。次いでコプロセッサ４５０は（好ましくは、再構成可能論理回路４０２上のＦＡＭパイプライン３５０を介して）、問い合わせ内のテキスト制約条件に従い、ストリーム９１４内のドキュメントのハードウェアアクセラレートされた全文検索を実行する（ステップ１１４０参照、図１１ｆ参照）。次いでこの高速データ処理操作の結果は、ファームウェアソケットモジュール４０４を経由してＡＰＩ９０２に返される（ステップ１１５０参照）。次いでＡＰＩ９０２（好ましくはリレーショナルエンジン９５０）は、図１１ｇに示すように、それらの探索結果９１６を、ユーザにユーザの問い合わせを満足させる探索結果を提示することのできる報告ツール９００に返すために、報告ツール９００が求める方法で書式設定するように動作する（ステップ１１７０参照）。
【００９３】
そのためのドキュメントメタデータ３１４が生成されているドキュメント３１２は、必ずしも機器内でデータストア３０６に格納されている必要はないことにも留意すべきである。それらのドキュメントは、望ましい場合には、機器２００の外部のドキュメントの元の場所に保持することもできる。そのような場合、それらのドキュメントをコプロセッサ４５０によって全文処理すべきときには、それらのドキュメントを、ネットワークインターフェース４１０を介して機器２００およびコプロセッサ４５０に流すことができる。図１２は、ＲＤＢＭＳ３０６によって返されたリスト９１０上のドキュメントが、データストア３０６内部のドキュメントと、企業体ネットワークを介してアクセス可能な他の何らかのデータストア３０８に位置する機器２００の外部のドキュメントの両方を含む場合のこの態様のドキュメント探索を示す、図９の対応図である。そのような場合には、ＡＰＩ９０２により、データストア３０６に送るためと機器２００の外部に送るための２つの要求９１２ａおよび９１２ｂが作成される。この構成は、探索が実行される際の待ち時間をネットワーク帯域幅が制約し得るためにあまり望ましくないが、それでもやはり本発明者らは、ドキュメントがデータストア３０６内に保持されていない場合でさえも、ある程度のアクセラレーションがなおも実現されることを認めるものである。この状況では、ドキュメント３１２をデータストア３０６に取り込む処置は、移動操作ではなくコピー操作とすることができることも注目に値する。企業体の中には、ドキュメント３１２の原本を機器２００の外部にある元の場所に残そうとするものもある。そうした状況では、ドキュメント３１２のコピーだけがデータストア３０６によって格納される。
【００９４】
好ましい実施形態の別の強力な態様は、機器２００が、データ処理操作を実行するときに探索機器２００の外部にある任意の企業体ＲＤＢＭＳ１３００にアクセスすることができるものである。この態様の好ましい実施形態の概要が図１３に示されている。この態様の好ましい実施形態の一部として、ＡＰＩ９０２により外部ＲＤＢＭＳ１３００に対してＳＱＬコマンド１３０２が発行され、それらのコマンドに対する応答１３０４がＡＰＩ９０２によって受け取られる。したがって、機器２００は、対象とするドキュメントの探索を実行するときに、企業体によって維持されている既存の構造化データを効率よく活用することができる。
【００９５】
図１４に、この態様のＳＱＬコマンド処理の論理図を示す。図１４の例では、ユーザには、なぜ最近企業体のいくつかの顧客の売上が鈍化しているのか調べるという任務が割り当てられている。この任務の一部として、ユーザは、ネットワークによって格納されている、このような売上不振に対する有益な洞察を提供し得るドキュメントを調査しようとする。これを達成するためにユーザは、２００７年７月７日にロードされた、「ｗｉｄｇｅｔ」または「ｎｅｗ ｐｒｏｄｕｃｔ」の近くにある「ｔｒｏｕｂｌｅ」というテキストを含む、その月間売上高が１０，０００製品（ｗｉｄｇｅｔ）を下回る顧客のすべてのドキュメントを検索することを目的とする問い合わせを指定する。ＢＩ報告ツール９００は、これらの問い合わせ制約条件を、図１４に示すようなＳＱＬコマンド９０６に変換するように動作する。
【００９６】
企業体はその顧客売上データを探索機器２００の外部にあるＲＤＢＭＳ１３００に格納するため、ＳＱＬコマンド９０６は、外部ＲＤＢＭＳ１３００内のデータ表をＲＤＢＭＳ３０４内のドキュメントメタデータ表と結合するように動作する。この処置は、当分野で公知のＳＱＬ操作である、（ドキュメントメタデータ表の）「Ｄ．Ｃｕｓｔｏｍｅｒ＿ＩＤ」と（外部関係表の）「Ｃ．Ｃｕｓｔｏｍｅｒ＿ＩＤ」とのマージキーに基づき、外部ＲＤＢＭＳ１３００内の「Ｃｕｓｔｏｍｅｒｓ＠ｅｘｔｅｒｎａｌ＿ＤＢ Ｃ」関係表の顧客データをＲＤＢＭＳ３０４内のドキュメントメタデータ関係表と結合する「ｉｎｎｅｒ ｊｏｉｎ」文に反映されている。このマージに基づき、リレーショナルエンジン９５０は、外部関係表から、どの顧客が１０，０００を下回る売上高を有するか特定し、それらの顧客をドキュメントメタデータ表内のフィールドに結び付けることができる。次いで、ドキュメントメタデータ内の「ｄａｔｅ＿ｌｏａｄｅｄ」メタデータフィールドに基づいて、それらの顧客のドキュメントをさらに限定することができる。最終的には、売上高とロードされた日付を満たす顧客のドキュメントを、コプロセッサ４５０内で「「ｗｉｄｇｅｔ」または「ｎｅｗ ｐｒｏｄｕｃｔ」の近くにある「ｔｒｏｕｂｌｅ」」という制約条件に基づく高速テキストマイニングのために処理することができる。その後は、図１０ｂに関連して説明したように処理を続行することができる。
【００９７】
図１５ａに、図１１ａを反映した、ＡＰＩ９０２によるＳＱＬコマンド９０６の受け取りを示す。リレーショナルエンジン９５０は、ＳＱＬコマンド９０６内のどの（１つまたは複数の）制約条件が外部ＲＤＢＭＳ１３００を対象とするものであるか特定し、ＳＱＬコマンド９０６の外部関係データ制約条件部分を対象とする新しいＳＱＬコマンド１３０２を生成する（図１４のＳＱＬコマンド９０６の例では、この外部制約条件部分は売上高制約条件である）。リレーショナルエンジン９５０は、新しいＳＱＬコマンド１３０２を処理するために外部ＲＤＢＭＳ１３００に対して適用する（図１５ｂ参照）。その後リレーショナルエンジン９５０は、外部ＲＤＢＭＳによるＳＱＬコマンド１３０２の処理から結果集合１３０４を受け取る（図１５ｃ参照）。
【００９８】
次いでリレーショナルエンジン９５０は、引き続きそのＳＱＬコマンド９０６を処理し、コマンド９０６にＲＤＢＭＳ３０４を対象とする別の制約条件が残っているかどうか判定する。制約条件が残っていない場合、結果集合１３０４内の顧客に基づいてＲＤＢＭＳ３０４のＳＱＬコマンド９０８が構築される。制約条件が残っている場合、結果集合１３０４と、残りの内部ＲＤＢＭＳを対象とする制約条件（図１４の例では「ｄａｔｅ ｌｏａｄｅｄ」制約条件など）とに基づいて、ＲＤＢＭＳ３０４のＳＱＬコマンド９０８が構築される。したがって、図１４のＳＱＬコマンド９０６の例では、リレーショナルエンジンは、その顧客フィールドが結果集合１３０４内の顧客によって限定され、そのロードされた日付フィールドが２００７年７月７日によって限定されるドキュメントメタデータを有するすべのドキュメントを探し出すＳＱＬコマンドを適用するはずである。この新しいコマンドを処理するためにＲＤＢＭＳ３０４に送ることができる（図１５ｃ参照）。
【００９９】
コマンド９０８に応答してドキュメントリスト９１０を受け取ると、問い合わせ処理の残りの部分が、図１５ｄから図１５ｈに示すように、図１１ｃから図１１ｇに関連して説明したのと同様に続行される。この例では、ＦＡＭパイプライン３５０の制御信号１１００は、どのドキュメントが「ｗｉｄｇｅｔ」または「ｎｅｗ ｐｒｏｄｕｃｔ」の近くにある「ｔｒｏｕｂｌｅ」というテキストを含むか特定するためにデータストリーム９１４内のドキュメントの全文検索を実行するようＦＡＭパイプライン３５０を編成するように構成されている。
【０１００】
前記のように、図１６には、ＡＰＩ９０２の代替の実施形態が開示されている。図１１ａから図１１ｇの作業例に関連して、ステップ１６００、１６０２、１６０４、１６０６、１６１６、および１６２０は、図１１ａに示すフローに対応するものである。ステップ１６２４およびステップ１６２８は図１１ｂに示すフローに対応するものである。ステップ１６３２は図１１ｃに示すフローに対応するものである。ステップ１６４０は図１１ｄに示すフローに対応するものである。ステップ１６１０およびステップ１６３６は図１１ｅに示すフローに対応するものである。ステップ１６４８は図１１ｆに示すフローに対応し、ステップ１６５０は図１１ｇに示すフローに対応するものである。
【０１０１】
また、ＡＰＩ９０２は、構造化データの少なくとも一部分が機器２００の外部にあるＲＤＢＭＳに格納されているときに使用するための一連の処理ステップも開示するものである。図１５ａから図１５ｈの作業例に関連して、ステップ１６００、１６０２、１６０４、１６０６、１６１６、１６２０、および１６２６は、図１５ａに示すフローに対応するものである。この例の問い合わせの一部は外部ＲＤＢＭＳ１３００に格納された関係データを対象としているため、プロセスフローはステップ１６２０からステップ１６２６に分岐することに留意すべきである。その後、ステップ１６３０は、図１５ｂに示すフローに対応するものである。ステップ１６３４、１６３８、１６４２、１６４４、および１６４６は図１５ｃに示すフローに対応するものである。その時点で図１６のプロセスフローはステップ１６３２に分岐し、図１５ｄから図１５ｈが図１１ｃから図１１ｇに関連して説明したように動作するように残りの操作が続行される。
【０１０２】
また、機器２００を、ＢＩ報告ツール９００などの上位レベルアプリケーションからの、データストア３０４内のドキュメントも、ＲＤＢＭＳ３０４がそれに関するメタデータを維持しているドキュメントも、ＲＤＢＭＳ３０４内のデータも対象としない問い合わせも処理するように構成することができることも注目に値する。このような例では、ＡＰＩ９０２は本質的に、それらの問い合わせが適切な外部構成要素に向けられる際の通路として（少なくともリレーショナルエンジン９５０までの通路として）機能する（ステップ１６０４、１６０８、１６１４および１６１８参照）。
【０１０３】
また、ＡＰＩ９０２は、図１６のステップ１６０６、１６１２、１６１４および１６１８で示すように、もっぱらＲＤＢＭＳ３０４内のメタデータだけを対象とする問い合わせ（メタデータに対する、ドキュメントテキスト探索制約条件を含まない問い合わせなど）を処理するように構成することもできることも分かる。
【０１０４】
図１７ａおよび図１７ｂに、好ましい実施形態のハードウェアアクセラレートされたデータ処理タスクを実行するために、再構成可能論理回路４０２のＦＡＭパイプライン３５０をどのようにしてセットアップすることができるかを例示する。図１７ａの例では、単一のＦＡＭパイプライン３５０が用いられており、パイプライン内の第１のＦＡＭ集合１７００はドキュメントメタデータ生成操作を実行するように構成されており、パイプライン内の第２のＦＡＭ集合１７０２は問い合わせ指定のデータ処理操作を実行するように構成されている（またはその逆でもよい）。この編成では、ＦＡＭパイプライン３５０がドキュメント取込み前処理に使用されているとき、問い合わせ指定のデータ処理を対象とするＦＡＭを、それらが事実上オフとされる「通過」モードに設定することができる。ＦＡＭパイプライン３５０がそうではなく問い合わせ指定のデータ処理操作に使用されるときには、ドキュメントメタデータ生成操作を対象とするＦＡＭを、それらが事実上オフとされる「通過」モードに設定することができる。
【０１０５】
この動作モードの代替として、図１７ｂに示すように、ＦＡＭ集合１７００とＦＡＭ集合１７０２を両方とも、独自の別個のパイプラインとして設定することもできる。この例では、ファームウェアソケットモジュール４０４に組み込まれたインテリジェンスが、どんな種類の処理が必要とされているかに応じて、データ（制御データおよびターゲットデータ）を適切なＦＡＭ集合に向けることができる。
【０１０６】
コプロセッサ４５０によって（好ましくは、再構成可能論理回路４０２上に展開されたファームウェア３５０を介して）実行される問い合わせ指定のデータ処理操作には、様々なアルゴリズムのいずれかを使用することができる。前記のように、コプロセッサによって全文検索を実行することもできる。コプロセッサによって実行され得る様々な全文検索操作の例には、完全マッチ操作、近似マッチ操作、正規表現マッチング操作、パターンマッチング操作他が含まれる。全文検索では、（問い合わせによって定義されるように）非構造化データにおいて検出されることが求められるデータに対応する１つまたは複数のキーをコプロセッサ４５０にロードすることができ、流れる非構造化データのいずれかが問い合わせを満足させるかどうか判定するための様々な技法を使って、流れる非構造化データを１つまたは複数のキーと比較することができる。このような全文検索操作の例示的実施形態は、前記の組み込まれた米国特許第６７１１５５８号明細書および米国特許第７１３９７４３号明細書、米国特許出願公開第２００６／０２９４０５９号明細書、米国特許出願公開第２００７／０１３０１４０号明細書、ならびに（２００６年５月２日に出願された米国出願第１１／３８１２１４号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｐｐｒｏｘｉｍａｔｅ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」という名称の米国特許出願公開第＿＿＿＿＿号明細書に開示されている。
【０１０７】
コプロセッサ４５０によって実行され得るデータ処理操作の別の例にはバイオシーケンス類似性探索が含まれ、その実施形態は、前記の組み込まれた米国特許出願公開第２００７／００６７１０８号明細書、および（２００７年８月１０日に出願された、米国出願第１１／８３６９４７号から公開された）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｔｅｉｎ Ｓｅｑｕｅｎｃｅ Ａｌｉｇｎｍｅｎｔ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」という名称の米国特許出願公開第＿＿＿＿＿号明細書に開示されている。
【０１０８】
さらに、コプロセッサ４５０内のパイプラインは、非構造化データに対して複数の異なるデータ処理操作を実行するように編成されることもできる。例えば、非構造化データがデータストア３０６に暗号化形式で格納されている場合には、コプロセッサを、全文検索操作を実行する前に、暗号化された非構造化データに対する復号操作を実行するパイプラインで構成することもできる。同様に、非構造化データがデータストア３０６に圧縮形式で格納されている場合には、コプロセッサを、全文検索操作を実行する前に、圧縮された非構造化データに対して伸張操作を実行するパイプラインで構成することもできる。さらに、非構造化データがデータストア３０６に暗号化され、圧縮された形式で格納されている場合には、コプロセッサを、全文検索操作を実行する前に復号および伸張を実行するパイプラインで構成することもできる。
【０１０９】
また、本発明を実施する者は、機器２００内に、様々なユーザが利用し得る内容を制限するセキュリティ機構を用いようとしてもよいことにも留意すべきである。好ましくは、このようなセキュリティ機構は、ＬＤＡＰ、アクティブディレクトリ（Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ）、シングルサインオン（Ｓｉｎｇｌｅ Ｓｉｇｎ−Ｏｎ）といった様々な企業体セキュリティアーキテクチャと統合されている。また、望ましい場合には、コプロセッサ４５０によってセキュリティ機能をハードウェアアクセラレートすることもできることにも留意すべきである。例えば、セキュリティ制御の粒度を、コプロセッサ４５０の使用により、ドキュメントレベルではなくデータレベルにおいて効率よく実施することができる。例えば、コプロセッサが再構成可能論理回路４０２を備える好ましい実施形態では、再構成可能論理回路上でファームウェア３５０を、指定のデータ処理操作のために編成されているファームウェアパイプライン内の下流側ＦＡＭへの制限データの通過を効率よくマスクする資格フィルタリング（ｅｎｔｉｔｌｅｍｅｎｔ ｆｉｌｔｅｒｉｎｇ）を用いるように編成することもできる。例えば、正規表現パターンマッチングＦＡＭを用いて、データがファームウェア３５０を流れる際にデータからデータの特定の部分（名前、電話番号、クレジットカード番号など）を除外することもできる。同様に、医療記録分野への本発明の適用例では、医療記録を探索しようとする、医療記録の特定部分の閲覧を許可されていないユーザが、制限されたデータにアクセスするのを防ぐために、適切に構成されたファームウェアを使って、医者／看護師だけが見るべきである医療記録内の特定のデータをフィルタリングすることもできる。このようにして、ファームウェア３５０によって用いられるデータ処理は、問い合わせ指定のデータ処理を用いるだけでなく、資格フィルタリング他のセキュリティ管理、暗号化／復号（例えば、前記の組み込まれた米国特許出願公開第２００７／０２３７３２７号明細書に記載されている暗号化／復号技術を参照されたい）、問い合わせ指定のデータ処理操作を補助するその他のデータ処理操作といった追加の付随的なデータ処理操作を用いることもできる。
【０１１０】
また、コプロセッサを使って解析されるべき非構造化データの一部を特定するのに構造化データを使用する問い合わせ処理の技法は、構造化データと非構造化データが同じデータストアに位置している状況においても適用することができることにも留意すべきである。この例示的実施形態は、図１８ａおよび図１８ｂに示されている。これは、関係データベース表が非構造化データの列を含む場合とすることができる。この一例は、コールセンター記録を格納する関係データベースにおいて生じ得る。コールセンターデータの各構造化フィールドは、電話が受け取られた日付、発信者の名前および電話番号、ならびに電話に出たコールセンター職員の名前を特定し得る。また、これらの記録は、発信者の通話に関するコールセンター職員の自由形式のテキストメモを含む非構造化データフィールドも含み得る。本明細書で説明した技法を使用すれば、通話メモが「ｒｅｆｕｎｄ」という単語を含む、２００８年１月１日から２００８年１月３１日までのすべての通話記録を検索するよう求める問い合わせを機器２００に向けることができる（図１８ｂ参照）。ＡＰＩ９０２は構造化データ列にアクセスして、通話日付が２００８年１月中であった通話記録の一部を特定することができる。その後、特定された部分におけるすべての通話記録（または少なくとも特定された部分の通話記録内のすべての非構造化列）をコプロセッサ４５０に流して、「ｒｅｆｕｎｄ」という単語を含む２００８年１月の通話記録を特定することができる。
【０１１１】
本明細書で開示した好ましい実施形態においてコプロセッサ４５０はＦＰＧＡなどの再構成可能論理回路４０２を備えているが、コプロセッサ４５０は他の処理装置を使って実現することもできる。例えば、コプロセッサ４５０は、グラフィックス処理装置（ＧＰＵ）、汎用グラフィックスプロセッサ、チップマルチプロセッサ（ＣＭＰ）、専用メモリ素子、複合プログラマブル論理回路、特定用途向け集積回路（ＡＳＩＣ）、および他の入出力処理構成要素を含んでもよい。さらに、機器２００は、直列と並列のどちらかまたは両方のマルチコプロセッサアーキテクチャとして複数のコプロセッサ４５０を用いてもよいことにも留意すべきである。
【０１１２】
以上、本発明をその好ましい実施形態に関連して説明したが、本発明には、やはり本発明の範囲内に含まれる様々な変更が加えられ得る。このような本発明への変更は、本明細書の教示を考察すれば理解されるであろう。したがって、本発明の完全な範囲は、もっぱら添付の特許請求の範囲およびその法的な均等物によって定義されるべきものである。
【特許請求の範囲】
【請求項１】
構造化データと非構造化データの両方への統合的アクセスを可能にする方法であって、
構造化データと非構造化データの組み合わさったものを対象とする問い合わせを受け取るステップと、
受け取った問い合わせに従って構造化データのデータベースから構造化データを取り出すステップと、
取り出した構造化データに基づいて非構造化データのデータストアから非構造化データを取り出すステップと、
取り出した非構造化データを、コンピュータシステム内のシステムの主プロセッサとは別の処理装置に流すステップと、
処理装置を使い、流れる非構造化データに対して問い合わせ指定のデータ処理操作を実行するステップと
を含む、方法。
【請求項２】
処理装置がコプロセッサを備える、請求項１に記載の方法。
【請求項３】
コプロセッサが再構成可能論理回路を備える、請求項２に記載の方法。
【請求項４】
再構成可能論理回路に、問い合わせ指定のデータ処理操作を実行するように構成されたファームウェアが展開されている、請求項３に記載の方法。
【請求項５】
問い合わせが標準化データベース問い合わせを含む、請求項１に記載の方法。
【請求項６】
標準化データベース問い合わせがＳＱＬコマンドを含む、請求項５に記載の方法。
【請求項７】
問い合わせ指定のデータ処理操作が、問い合わせで見られる少なくとも１つのキーに基づくテキスト探索操作を含む、請求項６に記載の方法。
【請求項８】
構造化データが、非構造化データのデータストア内の非構造化データに関するメタデータを含む、請求項１に記載の方法。
【請求項９】
処理装置に新しい非構造化データを流すステップと、
新しい非構造化データに関するメタデータを生成するために、処理装置を使って流れる非構造化データに対するメタデータ生成操作を実行するステップと、
新しい非構造化データを非構造化データのデータストアに格納するステップと、
新しい非構造化データに関するメタデータを構造化データのデータベースに格納するステップと
をさらに含む、請求項８に記載の方法。
【請求項１０】
処理装置がコプロセッサを備える、請求項９に記載の方法。
【請求項１１】
コプロセッサが再構成可能論理回路を備える、請求項１０に記載の方法。
【請求項１２】
再構成可能論理回路に、メタデータ生成操作を実行するように構成されたファームウェアが展開されている、請求項１１に記載の方法。
【請求項１３】
構造化データのデータベースがＲＤＢＭＳを備える、請求項８に記載の方法。
【請求項１４】
構造化データを取り出すステップが、受け取った問い合わせに従って外部の構造化データのデータベースから構造化データを取り出すステップを含む、請求項１に記載の方法。
【請求項１５】
構造化データを取り出すステップが、受け取った問い合わせに従って内部の構造化データのデータベースから構造化データを取り出すステップもさらに含む、請求項１４に記載の方法。
【請求項１６】
構造化データを取り出すステップが、受け取った問い合わせに従って内部の構造化データのデータベースから構造化データを取り出すステップを含む、請求項１に記載の方法。
【請求項１７】
主プロセッサと、
主プロセッサとは別の処理装置と、
主プロセッサおよび処理装置と通信状態にある非構造化データのデータストアと、
主プロセッサおよび処理装置と通信状態にある構造化データのデータストアと
を備え、
主プロセッサが、（１）問い合わせを受け取り、（２）問い合わせの少なくとも一部分を満足させる非構造化データのデータストア内の非構造化データの一部を特定するために、問い合わせの少なくとも一部分を構造化データのデータストア内の構造化データと対照して処理し、（３）非構造化データの一部が処理装置に送られるよう要求するように構成されており、
処理装置が、非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行するように構成されている、
データを処理するシステム。
【請求項１８】
処理装置がコプロセッサを備える、請求項１７に記載のシステム。
【請求項１９】
コプロセッサが再構成可能論理回路を備える、請求項１６に記載のシステム。
【請求項２０】
再構成可能論理回路に、問い合わせ指定のデータ処理操作を実行するように構成されたファームウェアが展開されている、請求項１９に記載のシステム。
【請求項２１】
構造化データのデータベースがＲＤＢＭＳを備え、問い合わせが標準化データベース問い合わせを含む、請求項１７に記載のシステム。
【請求項２２】
ＲＤＢＭＳ内の構造化データが、非構造化データのデータストア内の非構造化データに関するメタデータを含む、請求項２１に記載のシステム。
【請求項２３】
標準化データベース問い合わせがＳＱＬコマンドを含む、請求項２２に記載のシステム。
【請求項２４】
問い合わせ指定のデータ処理操作が、問い合わせで定義されている少なくとも１つのキーのための問い合わせ指定のテキストサーチ操作を含む、請求項２３に記載のシステム。
【請求項２５】
主プロセッサが、問い合わせを受け取り、処理するためのＳＱＬ対応ＡＰＩを用いて構成されている、請求項２４に記載のシステム。
【請求項２６】
主プロセッサ、処理装置、非構造化データのデータストア、およびＲＤＢＭＳを相互接続するバスをさらに備える、請求項２５に記載のシステム。
【請求項２７】
別の非構造化データのデータストアが位置するコンピュータネットワークと通信状態にある、バスに接続されたネットワークインターフェースをさらに備え、ＳＱＬ対応ＡＰＩが、問い合わせに応答して別のデータストア内の非構造化データが処理装置に流されるように、別のデータストアに格納された非構造化データを対象とする問い合わせも処理するように構成されている、請求項２６に記載のシステム。
【請求項２８】
ＳＱＬ対応クライアントアプリケーションがあるコンピュータネットワークと通信状態にある、バスに接続されたネットワークインターフェースをさらに備え、ＳＱＬ対応クライアントアプリケーションが、ユーザ入力に応答して問い合わせを作成し、ネットワークインターフェースを介してＳＱＬ対応ＡＰＩに問い合わせを送るように構成されている、請求項２６に記載のシステム。
【請求項２９】
ＳＱＬ対応クライアントアプリケーションがＢＩ報告ツールを含む、請求項２８に記載のシステム。
【請求項３０】
主プロセッサ、処理装置、およびＲＤＢＭＳを相互接続するバスと、
バスを経由して非構造化データのデータストアと処理装置とを相互接続するネットワークインターフェースと
をさらに備える、請求項２５に記載のシステム。
【請求項３１】
主プロセッサがさらに、非構造化データのストリームを処理装置に向けるように構成されており、処理装置がさらに、処理装置に流された非構造化データに関するメタデータを生成するように構成されており、主プロセッサがさらに、後で問い合わせ処理操作時に使用するために生成されたメタデータをＲＤＢＭＳに格納するように構成されている、請求項２５に記載のシステム。
【請求項３２】
構造化データと非構造化データの両方への統合的アクセスを可能にする方法であって、
構造化データと非構造化データの組み合わさったものを対象とする問い合わせを受け取るステップと、
受け取った問い合わせに従って構造化データのデータベースから構造化データを取り出すステップと、
取り出した構造化データに基づいて非構造化データのデータストアから非構造化データを取り出すステップと、
ファームウェアに流される非構造化データに対して問い合わせ指定のデータ処理操作を実行するように構成されている、再構成可能論理回路上に展開されたファームウェアに取り出した非構造化データを流すステップと
を含む、方法。
【請求項３３】
ファームウェアが展開されている再構成可能論理回路と、
再構成可能論理回路と通信状態にある非構造化データのデータストアと、
再構成可能論理回路と通信状態にある構造化データのデータストアと、
（１）問い合わせを受け取り、（２）問い合わせの少なくとも一部分を満足させる非構造化データのデータストア内の非構造化データの一部を特定するために、問い合わせの少なくとも一部分を構造化データのデータストア内の構造化データと対照して処理し、（３）非構造化データの一部が、再構成可能論理回路上のファームウェアに送られるよう要求するように構成されたインターフェースと
を備え、該ファームウェアが、非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行するように構成されている、データを処理するシステム。
【請求項３４】
データ解析操作を実行するために非構造化データにインテリジェントにアクセスする方法であって、
構造化データのデータストア内の非構造化データに対応するメタデータを維持するステップと、
構造化データのデータストアに、少なくとも一部がメタデータを対象とする問い合わせを適用することにより、非構造化データの一部を特定するステップと、
非構造化データのデータストアから特定した非構造化データの一部を取り出すステップと、
問い合わせへの応答のデータを生成するために、コプロセッサを使って取り出した非構造化データに対するデータ解析操作を実行するステップと
を含む、方法。
【請求項３５】
コプロセッサが再構成可能論理回路を備える、請求項３１に記載の方法。
【請求項３６】
再構成可能論理回路上にファームウェアが展開されており、ファームウェアがデータ解析操作を実行するように構成されている、請求項３５に記載の方法。
【請求項３７】
データ解析操作を実行するステップが、コプロセッサを使って取り出した非構造化データを全文検索するステップを含む、請求項３４に記載の方法。
【請求項３８】
全文検索を行うステップが近接検索を行うステップを含む、請求項３７に記載の方法。
【請求項３９】
問い合わせがＳＱＬコマンドを含む、請求項３４に記載の方法。
【請求項４０】
流れるデータに対してメタデータ生成操作を実行するように構成されているコプロセッサに非構造化データを流してメタデータを生成するステップをさらに含む、請求項３４に記載の方法。
【請求項４１】
コプロセッサとソフトウェアアプリケーションとをインターフェースするプロセッサ可読媒体であって、
（１）ソフトウェアアプリケーションから問い合わせを受け取り、（２）構造化データのデータストアによって格納されている構造化データに対して向けられるべき問い合わせの部分を判定し、（３）非構造化データのデータストアによって格納されている非構造化データに向けられるべき問い合わせの部分を判定し、（４）判定した構造化データのための問い合わせ部分を構造化データのデータストアに対して適用し、（５）判定した構造化データのための問い合わせ部分の適用に応答して、構造化データのデータストアから、格納された非構造化データの一部の識別を受け取り、（６）コプロセッサにコマンドを送って、コプロセッサを、判定した非構造化データのための問い合わせ部分によって指定されるデータ解析操作を実行するように構成し、（７）非構造化データの一部に対してデータ解析操作を実行するために非構造化データのデータストアからコプロセッサに非構造化データの一部を送るよう指図するための、プロセッサ可読媒体上にあるプロセッサ実行可能コード
を備えるプロセッサ可読媒体。
【請求項４２】
問い合わせがＳＱＬコマンドを含む、請求項４１に記載のプロセッサ可読媒体。
【請求項４３】
（１）データ解析操作に応答してコプロセッサからデータを受け取り、（２）ソフトウェアアプリケーションに送るために受け取ったデータを書式設定するための、プロセッサ可読媒体上にあるプロセッサ実行可能コードをさらに備える、請求項４１に記載のプロセッサ可読媒体。
【請求項４４】
構造化データおよび非構造化データを対象とする問い合わせを処理する方法であって、
構造化データを対象とする問い合わせの部分について構造化データ検索操作を実行するステップと、
非構造化データを対象とする問い合わせの部分について問い合わせ指定のデータ処理操作をハードウェアアクセラレートするステップと
を含む、方法。
【請求項４５】
非構造化データに対する問い合わせを実行する方法であって、
問い合わせを受け取るステップと、
問い合わせに応答し、問い合わせと対照して解析されるべき非構造化データの一部を特定するために構造化データにアクセスするステップと、
問い合わせへの応答のデータを生成するために、特定した非構造化データの一部に対して問い合わせ指定のデータ解析操作を実行するステップと
を含み、
アクセスするステップがプロセッサによって行われ、
実行するステップがコプロセッサによって行われる、方法。
【請求項４６】
コプロセッサが再構成可能論理回路を備える、請求項４５に記載の方法。
【請求項４７】
再構成可能論理回路に、非構造化データの一部に対して問い合わせ指定のデータ解析操作を実行するように構成されているファームウェアが展開されている、請求項４６に記載の方法。
【請求項４８】
データ解析操作が全文検索操作を含む、請求項４７に記載の方法。
【請求項４９】
構造化データが関係データベースに格納されている、請求項４５に記載の方法。
【請求項５０】
実行するステップの前に、特定した非構造化データの一部を取り出すステップをさらに含み、取り出すステップが、関係データベースから特定した非構造化データの一部を取り出すステップを含む、請求項４９に記載の方法。
【請求項５１】
構造化データが、非構造化データに対応するメタデータ索引を含む、請求項４５に記載の方法。
【請求項５２】
コンピュータと、
プロセッサ、コプロセッサおよびデータストアを備え、ネットワークを介してコンピュータと通信状態にある機器と
を備え、
コンピュータが、機器に問い合わせを送るソフトウェアアプリケーションを実行するように構成されており、
機器が問い合わせを受け取るように構成されており、
プロセッサが、データストアによって格納されている構造化データに受け取った問い合わせの一部分を選択的に適用し、適用した問い合わせに応答して非構造化データの一部を特定するように構成されており、
プロセッサがさらに、受け取った問い合わせの別の部分に基づいてコプロセッサのためのデータ処理操作を定義するように構成されており、
機器がさらに、特定した非構造化データの一部をコプロセッサに流すように構成されており、
コプロセッサが、受け取った問い合わせに対応する結果集合を生成するために、コプロセッサに流された特定された非構造化データの一部に対して定義されたデータ処理操作を実行するように構成されており、
プロセッサがさらに、（１）生成した結果集合に基づいて問い合わせへの応答を作成し、（２）問い合わせの応答をコンピュータに送るように構成されている、
企業体コンピュータシステム。
【請求項５３】
データストアが、構造化データの少なくとも一部分が格納されている関係データベースを備え、機器が、非構造化データの少なくとも一部分が格納されている第２のデータストアをさらに備える、請求項５２に記載のシステム。
【請求項５４】
構造化データが、少なくとも一部が、非構造化データに対応するメタデータ索引を含む、請求項５３に記載のシステム。
【請求項５５】
ソフトウェアアプリケーションがＳＱＬ対応ソフトウェアアプリケーションを含み、問い合わせがＳＱＬコマンドを含む、請求項５４に記載のシステム。
【請求項５６】
構造化データが格納されている第２の関係データベースをさらに備え、機器がネットワークを介して第２の関係データベースと通信状態にあり、プロセッサがさらに、（１）第２の関係データベースに受信した問い合わせのさらに別の部分を選択的に適用し、（２）２つの関係データベースに適用された問い合わせの部分に基づいて非構造化データの一部を特定するように構成されている、請求項５４に記載のシステム。
【請求項５７】
非構造化データが格納されている第３のデータストアをさらに備え、機器がネットワークを介して第２のデータストアと通信状態にあり、特定される非構造化データの一部が、第２のデータストアと第３のデータストアの両方によって格納されている非構造化データを含む、請求項５４に記載のシステム。
【請求項５８】
コプロセッサが再構成可能論理回路を備える、請求項５４に記載のシステム。
【請求項５９】
再構成可能論理回路上に、定義されたデータ処理操作を実行するように構成されたファームウェアが展開されている、請求項５８に記載のシステム。
【請求項６０】
定義されたデータ処理操作が全文検索操作を含む、請求項５９に記載のシステム。
【請求項６１】
定義されたデータ処理操作がテキストマイニング操作を含む、請求項５９に記載のシステム。
【請求項６２】
定義されたデータ処理操作が正規表現マッチング操作を含む、請求項５９に記載のシステム。
【請求項６３】
ファームウェアが、定義されたデータ処理操作の前に復号操作を実行するように構成されているファームウェアパイプラインを備える、請求項５９に記載のシステム。
【請求項６４】
ファームウェアが、定義されたデータ処理操作の前に伸張操作を実行するように構成されているファームウェアパイプラインを備える、請求項５９に記載のシステム。
【請求項６５】
プロセッサが、受け取った問い合わせを処理するためにＡＰＩソフトウェアを実行するように構成されている、請求項５４に記載のシステム。
【請求項６６】
ＡＰＩソフトウェアがリレーショナルエンジンソフトウェアおよびコプロセッサインターフェースソフトウェアを含み、リレーショナルエンジンソフトウェアが、受信した別の問い合わせ部分に遭遇すると、コプロセッサインターフェースソフトウェアを呼び出すように構成されており、コプロセッサインターフェースソフトウェアが、受信した別の問い合わせ部分を処理するためにコプロセッサを呼び出すように構成されている、請求項６５に記載のシステム。
【請求項６７】
構造化データおよび非構造化データを対象とする問い合わせを処理する装置であって、
（１）リレーショナルエンジンソフトウェアを実行し、（２）コプロセッサインターフェースソフトウェアを実行するように構成されたプロセッサ
を備え、リレーショナルエンジンソフトウェアが、（１）非構造化データの一部を特定するために構造化データを対象とする問い合わせの部分を関係データベースに適用し、（２）非構造化データを対象とする問い合わせの部分に遭遇すると、コプロセッサインターフェースソフトウェアを呼び出すように構成されており、コプロセッサインターフェースソフトウェアが、特定された非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行するためにコプロセッサを呼び出すように構成されている、装置。
【請求項６８】
コプロセッサインターフェースソフトウェアがさらに、コプロセッサが特定された非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行することを可能にするためにコプロセッサにデータを渡すように構成されている、請求項６７に記載の装置。
【請求項６９】
リレーショナルエンジンソフトウェアがＳＱＬリレーショナルエンジンソフトウェアを含む、請求項６８に記載の装置。
【請求項１】
構造化データと非構造化データの両方への統合的アクセスを可能にする方法であって、
構造化データと非構造化データの組み合わさったものを対象とする問い合わせを受け取るステップと、
受け取った問い合わせに従って構造化データのデータベースから構造化データを取り出すステップと、
取り出した構造化データに基づいて非構造化データのデータストアから非構造化データを取り出すステップと、
取り出した非構造化データを、コンピュータシステム内のシステムの主プロセッサとは別の処理装置に流すステップと、
処理装置を使い、流れる非構造化データに対して問い合わせ指定のデータ処理操作を実行するステップと
を含む、方法。
【請求項２】
処理装置がコプロセッサを備える、請求項１に記載の方法。
【請求項３】
コプロセッサが再構成可能論理回路を備える、請求項２に記載の方法。
【請求項４】
再構成可能論理回路に、問い合わせ指定のデータ処理操作を実行するように構成されたファームウェアが展開されている、請求項３に記載の方法。
【請求項５】
問い合わせが標準化データベース問い合わせを含む、請求項１に記載の方法。
【請求項６】
標準化データベース問い合わせがＳＱＬコマンドを含む、請求項５に記載の方法。
【請求項７】
問い合わせ指定のデータ処理操作が、問い合わせで見られる少なくとも１つのキーに基づくテキスト探索操作を含む、請求項６に記載の方法。
【請求項８】
構造化データが、非構造化データのデータストア内の非構造化データに関するメタデータを含む、請求項１に記載の方法。
【請求項９】
処理装置に新しい非構造化データを流すステップと、
新しい非構造化データに関するメタデータを生成するために、処理装置を使って流れる非構造化データに対するメタデータ生成操作を実行するステップと、
新しい非構造化データを非構造化データのデータストアに格納するステップと、
新しい非構造化データに関するメタデータを構造化データのデータベースに格納するステップと
をさらに含む、請求項８に記載の方法。
【請求項１０】
処理装置がコプロセッサを備える、請求項９に記載の方法。
【請求項１１】
コプロセッサが再構成可能論理回路を備える、請求項１０に記載の方法。
【請求項１２】
再構成可能論理回路に、メタデータ生成操作を実行するように構成されたファームウェアが展開されている、請求項１１に記載の方法。
【請求項１３】
構造化データのデータベースがＲＤＢＭＳを備える、請求項８に記載の方法。
【請求項１４】
構造化データを取り出すステップが、受け取った問い合わせに従って外部の構造化データのデータベースから構造化データを取り出すステップを含む、請求項１に記載の方法。
【請求項１５】
構造化データを取り出すステップが、受け取った問い合わせに従って内部の構造化データのデータベースから構造化データを取り出すステップもさらに含む、請求項１４に記載の方法。
【請求項１６】
構造化データを取り出すステップが、受け取った問い合わせに従って内部の構造化データのデータベースから構造化データを取り出すステップを含む、請求項１に記載の方法。
【請求項１７】
主プロセッサと、
主プロセッサとは別の処理装置と、
主プロセッサおよび処理装置と通信状態にある非構造化データのデータストアと、
主プロセッサおよび処理装置と通信状態にある構造化データのデータストアと
を備え、
主プロセッサが、（１）問い合わせを受け取り、（２）問い合わせの少なくとも一部分を満足させる非構造化データのデータストア内の非構造化データの一部を特定するために、問い合わせの少なくとも一部分を構造化データのデータストア内の構造化データと対照して処理し、（３）非構造化データの一部が処理装置に送られるよう要求するように構成されており、
処理装置が、非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行するように構成されている、
データを処理するシステム。
【請求項１８】
処理装置がコプロセッサを備える、請求項１７に記載のシステム。
【請求項１９】
コプロセッサが再構成可能論理回路を備える、請求項１６に記載のシステム。
【請求項２０】
再構成可能論理回路に、問い合わせ指定のデータ処理操作を実行するように構成されたファームウェアが展開されている、請求項１９に記載のシステム。
【請求項２１】
構造化データのデータベースがＲＤＢＭＳを備え、問い合わせが標準化データベース問い合わせを含む、請求項１７に記載のシステム。
【請求項２２】
ＲＤＢＭＳ内の構造化データが、非構造化データのデータストア内の非構造化データに関するメタデータを含む、請求項２１に記載のシステム。
【請求項２３】
標準化データベース問い合わせがＳＱＬコマンドを含む、請求項２２に記載のシステム。
【請求項２４】
問い合わせ指定のデータ処理操作が、問い合わせで定義されている少なくとも１つのキーのための問い合わせ指定のテキストサーチ操作を含む、請求項２３に記載のシステム。
【請求項２５】
主プロセッサが、問い合わせを受け取り、処理するためのＳＱＬ対応ＡＰＩを用いて構成されている、請求項２４に記載のシステム。
【請求項２６】
主プロセッサ、処理装置、非構造化データのデータストア、およびＲＤＢＭＳを相互接続するバスをさらに備える、請求項２５に記載のシステム。
【請求項２７】
別の非構造化データのデータストアが位置するコンピュータネットワークと通信状態にある、バスに接続されたネットワークインターフェースをさらに備え、ＳＱＬ対応ＡＰＩが、問い合わせに応答して別のデータストア内の非構造化データが処理装置に流されるように、別のデータストアに格納された非構造化データを対象とする問い合わせも処理するように構成されている、請求項２６に記載のシステム。
【請求項２８】
ＳＱＬ対応クライアントアプリケーションがあるコンピュータネットワークと通信状態にある、バスに接続されたネットワークインターフェースをさらに備え、ＳＱＬ対応クライアントアプリケーションが、ユーザ入力に応答して問い合わせを作成し、ネットワークインターフェースを介してＳＱＬ対応ＡＰＩに問い合わせを送るように構成されている、請求項２６に記載のシステム。
【請求項２９】
ＳＱＬ対応クライアントアプリケーションがＢＩ報告ツールを含む、請求項２８に記載のシステム。
【請求項３０】
主プロセッサ、処理装置、およびＲＤＢＭＳを相互接続するバスと、
バスを経由して非構造化データのデータストアと処理装置とを相互接続するネットワークインターフェースと
をさらに備える、請求項２５に記載のシステム。
【請求項３１】
主プロセッサがさらに、非構造化データのストリームを処理装置に向けるように構成されており、処理装置がさらに、処理装置に流された非構造化データに関するメタデータを生成するように構成されており、主プロセッサがさらに、後で問い合わせ処理操作時に使用するために生成されたメタデータをＲＤＢＭＳに格納するように構成されている、請求項２５に記載のシステム。
【請求項３２】
構造化データと非構造化データの両方への統合的アクセスを可能にする方法であって、
構造化データと非構造化データの組み合わさったものを対象とする問い合わせを受け取るステップと、
受け取った問い合わせに従って構造化データのデータベースから構造化データを取り出すステップと、
取り出した構造化データに基づいて非構造化データのデータストアから非構造化データを取り出すステップと、
ファームウェアに流される非構造化データに対して問い合わせ指定のデータ処理操作を実行するように構成されている、再構成可能論理回路上に展開されたファームウェアに取り出した非構造化データを流すステップと
を含む、方法。
【請求項３３】
ファームウェアが展開されている再構成可能論理回路と、
再構成可能論理回路と通信状態にある非構造化データのデータストアと、
再構成可能論理回路と通信状態にある構造化データのデータストアと、
（１）問い合わせを受け取り、（２）問い合わせの少なくとも一部分を満足させる非構造化データのデータストア内の非構造化データの一部を特定するために、問い合わせの少なくとも一部分を構造化データのデータストア内の構造化データと対照して処理し、（３）非構造化データの一部が、再構成可能論理回路上のファームウェアに送られるよう要求するように構成されたインターフェースと
を備え、該ファームウェアが、非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行するように構成されている、データを処理するシステム。
【請求項３４】
データ解析操作を実行するために非構造化データにインテリジェントにアクセスする方法であって、
構造化データのデータストア内の非構造化データに対応するメタデータを維持するステップと、
構造化データのデータストアに、少なくとも一部がメタデータを対象とする問い合わせを適用することにより、非構造化データの一部を特定するステップと、
非構造化データのデータストアから特定した非構造化データの一部を取り出すステップと、
問い合わせへの応答のデータを生成するために、コプロセッサを使って取り出した非構造化データに対するデータ解析操作を実行するステップと
を含む、方法。
【請求項３５】
コプロセッサが再構成可能論理回路を備える、請求項３１に記載の方法。
【請求項３６】
再構成可能論理回路上にファームウェアが展開されており、ファームウェアがデータ解析操作を実行するように構成されている、請求項３５に記載の方法。
【請求項３７】
データ解析操作を実行するステップが、コプロセッサを使って取り出した非構造化データを全文検索するステップを含む、請求項３４に記載の方法。
【請求項３８】
全文検索を行うステップが近接検索を行うステップを含む、請求項３７に記載の方法。
【請求項３９】
問い合わせがＳＱＬコマンドを含む、請求項３４に記載の方法。
【請求項４０】
流れるデータに対してメタデータ生成操作を実行するように構成されているコプロセッサに非構造化データを流してメタデータを生成するステップをさらに含む、請求項３４に記載の方法。
【請求項４１】
コプロセッサとソフトウェアアプリケーションとをインターフェースするプロセッサ可読媒体であって、
（１）ソフトウェアアプリケーションから問い合わせを受け取り、（２）構造化データのデータストアによって格納されている構造化データに対して向けられるべき問い合わせの部分を判定し、（３）非構造化データのデータストアによって格納されている非構造化データに向けられるべき問い合わせの部分を判定し、（４）判定した構造化データのための問い合わせ部分を構造化データのデータストアに対して適用し、（５）判定した構造化データのための問い合わせ部分の適用に応答して、構造化データのデータストアから、格納された非構造化データの一部の識別を受け取り、（６）コプロセッサにコマンドを送って、コプロセッサを、判定した非構造化データのための問い合わせ部分によって指定されるデータ解析操作を実行するように構成し、（７）非構造化データの一部に対してデータ解析操作を実行するために非構造化データのデータストアからコプロセッサに非構造化データの一部を送るよう指図するための、プロセッサ可読媒体上にあるプロセッサ実行可能コード
を備えるプロセッサ可読媒体。
【請求項４２】
問い合わせがＳＱＬコマンドを含む、請求項４１に記載のプロセッサ可読媒体。
【請求項４３】
（１）データ解析操作に応答してコプロセッサからデータを受け取り、（２）ソフトウェアアプリケーションに送るために受け取ったデータを書式設定するための、プロセッサ可読媒体上にあるプロセッサ実行可能コードをさらに備える、請求項４１に記載のプロセッサ可読媒体。
【請求項４４】
構造化データおよび非構造化データを対象とする問い合わせを処理する方法であって、
構造化データを対象とする問い合わせの部分について構造化データ検索操作を実行するステップと、
非構造化データを対象とする問い合わせの部分について問い合わせ指定のデータ処理操作をハードウェアアクセラレートするステップと
を含む、方法。
【請求項４５】
非構造化データに対する問い合わせを実行する方法であって、
問い合わせを受け取るステップと、
問い合わせに応答し、問い合わせと対照して解析されるべき非構造化データの一部を特定するために構造化データにアクセスするステップと、
問い合わせへの応答のデータを生成するために、特定した非構造化データの一部に対して問い合わせ指定のデータ解析操作を実行するステップと
を含み、
アクセスするステップがプロセッサによって行われ、
実行するステップがコプロセッサによって行われる、方法。
【請求項４６】
コプロセッサが再構成可能論理回路を備える、請求項４５に記載の方法。
【請求項４７】
再構成可能論理回路に、非構造化データの一部に対して問い合わせ指定のデータ解析操作を実行するように構成されているファームウェアが展開されている、請求項４６に記載の方法。
【請求項４８】
データ解析操作が全文検索操作を含む、請求項４７に記載の方法。
【請求項４９】
構造化データが関係データベースに格納されている、請求項４５に記載の方法。
【請求項５０】
実行するステップの前に、特定した非構造化データの一部を取り出すステップをさらに含み、取り出すステップが、関係データベースから特定した非構造化データの一部を取り出すステップを含む、請求項４９に記載の方法。
【請求項５１】
構造化データが、非構造化データに対応するメタデータ索引を含む、請求項４５に記載の方法。
【請求項５２】
コンピュータと、
プロセッサ、コプロセッサおよびデータストアを備え、ネットワークを介してコンピュータと通信状態にある機器と
を備え、
コンピュータが、機器に問い合わせを送るソフトウェアアプリケーションを実行するように構成されており、
機器が問い合わせを受け取るように構成されており、
プロセッサが、データストアによって格納されている構造化データに受け取った問い合わせの一部分を選択的に適用し、適用した問い合わせに応答して非構造化データの一部を特定するように構成されており、
プロセッサがさらに、受け取った問い合わせの別の部分に基づいてコプロセッサのためのデータ処理操作を定義するように構成されており、
機器がさらに、特定した非構造化データの一部をコプロセッサに流すように構成されており、
コプロセッサが、受け取った問い合わせに対応する結果集合を生成するために、コプロセッサに流された特定された非構造化データの一部に対して定義されたデータ処理操作を実行するように構成されており、
プロセッサがさらに、（１）生成した結果集合に基づいて問い合わせへの応答を作成し、（２）問い合わせの応答をコンピュータに送るように構成されている、
企業体コンピュータシステム。
【請求項５３】
データストアが、構造化データの少なくとも一部分が格納されている関係データベースを備え、機器が、非構造化データの少なくとも一部分が格納されている第２のデータストアをさらに備える、請求項５２に記載のシステム。
【請求項５４】
構造化データが、少なくとも一部が、非構造化データに対応するメタデータ索引を含む、請求項５３に記載のシステム。
【請求項５５】
ソフトウェアアプリケーションがＳＱＬ対応ソフトウェアアプリケーションを含み、問い合わせがＳＱＬコマンドを含む、請求項５４に記載のシステム。
【請求項５６】
構造化データが格納されている第２の関係データベースをさらに備え、機器がネットワークを介して第２の関係データベースと通信状態にあり、プロセッサがさらに、（１）第２の関係データベースに受信した問い合わせのさらに別の部分を選択的に適用し、（２）２つの関係データベースに適用された問い合わせの部分に基づいて非構造化データの一部を特定するように構成されている、請求項５４に記載のシステム。
【請求項５７】
非構造化データが格納されている第３のデータストアをさらに備え、機器がネットワークを介して第２のデータストアと通信状態にあり、特定される非構造化データの一部が、第２のデータストアと第３のデータストアの両方によって格納されている非構造化データを含む、請求項５４に記載のシステム。
【請求項５８】
コプロセッサが再構成可能論理回路を備える、請求項５４に記載のシステム。
【請求項５９】
再構成可能論理回路上に、定義されたデータ処理操作を実行するように構成されたファームウェアが展開されている、請求項５８に記載のシステム。
【請求項６０】
定義されたデータ処理操作が全文検索操作を含む、請求項５９に記載のシステム。
【請求項６１】
定義されたデータ処理操作がテキストマイニング操作を含む、請求項５９に記載のシステム。
【請求項６２】
定義されたデータ処理操作が正規表現マッチング操作を含む、請求項５９に記載のシステム。
【請求項６３】
ファームウェアが、定義されたデータ処理操作の前に復号操作を実行するように構成されているファームウェアパイプラインを備える、請求項５９に記載のシステム。
【請求項６４】
ファームウェアが、定義されたデータ処理操作の前に伸張操作を実行するように構成されているファームウェアパイプラインを備える、請求項５９に記載のシステム。
【請求項６５】
プロセッサが、受け取った問い合わせを処理するためにＡＰＩソフトウェアを実行するように構成されている、請求項５４に記載のシステム。
【請求項６６】
ＡＰＩソフトウェアがリレーショナルエンジンソフトウェアおよびコプロセッサインターフェースソフトウェアを含み、リレーショナルエンジンソフトウェアが、受信した別の問い合わせ部分に遭遇すると、コプロセッサインターフェースソフトウェアを呼び出すように構成されており、コプロセッサインターフェースソフトウェアが、受信した別の問い合わせ部分を処理するためにコプロセッサを呼び出すように構成されている、請求項６５に記載のシステム。
【請求項６７】
構造化データおよび非構造化データを対象とする問い合わせを処理する装置であって、
（１）リレーショナルエンジンソフトウェアを実行し、（２）コプロセッサインターフェースソフトウェアを実行するように構成されたプロセッサ
を備え、リレーショナルエンジンソフトウェアが、（１）非構造化データの一部を特定するために構造化データを対象とする問い合わせの部分を関係データベースに適用し、（２）非構造化データを対象とする問い合わせの部分に遭遇すると、コプロセッサインターフェースソフトウェアを呼び出すように構成されており、コプロセッサインターフェースソフトウェアが、特定された非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行するためにコプロセッサを呼び出すように構成されている、装置。
【請求項６８】
コプロセッサインターフェースソフトウェアがさらに、コプロセッサが特定された非構造化データの一部に対して問い合わせ指定のデータ処理操作を実行することを可能にするためにコプロセッサにデータを渡すように構成されている、請求項６７に記載の装置。
【請求項６９】
リレーショナルエンジンソフトウェアがＳＱＬリレーショナルエンジンソフトウェアを含む、請求項６８に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７ａ】
【図７ｂ】
【図８】
【図９】
【図１０ａ】
【図１０ｂ】
【図１０ｃ】
【図１１ａ】
【図１１ｂ】
【図１１ｃ】
【図１１ｄ】
【図１１ｅ】
【図１１ｆ】
【図１１ｇ】
【図１２】
【図１３】
【図１４】
【図１５ａ】
【図１５ｂ】
【図１５ｃ】
【図１５ｄ】
【図１５ｅ】
【図１５ｆ】
【図１５ｇ】
【図１５ｈ】
【図１６】
【図１７ａ】
【図１７ｂ】
【図１８ａ】
【図１８ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７ａ】
【図７ｂ】
【図８】
【図９】
【図１０ａ】
【図１０ｂ】
【図１０ｃ】
【図１１ａ】
【図１１ｂ】
【図１１ｃ】
【図１１ｄ】
【図１１ｅ】
【図１１ｆ】
【図１１ｇ】
【図１２】
【図１３】
【図１４】
【図１５ａ】
【図１５ｂ】
【図１５ｃ】
【図１５ｄ】
【図１５ｅ】
【図１５ｆ】
【図１５ｇ】
【図１５ｈ】
【図１６】
【図１７ａ】
【図１７ｂ】
【図１８ａ】
【図１８ｂ】
【公表番号】特表２０１０−５１１９２５（Ｐ２０１０−５１１９２５Ａ）
【公表日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願番号】特願２００９−５３６５３６（Ｐ２００９−５３６５３６）
【出願日】平成１９年１１月１２日（２００７．１１．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８４４６６
【国際公開番号】ＷＯ２００８／０６３９７４
【国際公開日】平成２０年５月２９日（２００８．５．２９）
【出願人】（５０８１３７９４７）エクセジー・インコーポレイテツド (5)
【Ｆターム（参考）】
【公表日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願日】平成１９年１１月１２日（２００７．１１．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８４４６６
【国際公開番号】ＷＯ２００８／０６３９７４
【国際公開日】平成２０年５月２９日（２００８．５．２９）
【出願人】（５０８１３７９４７）エクセジー・インコーポレイテツド (5)
【Ｆターム（参考）】
[ Back to top ]