テキストを生成する方法及びシステム
【課題】本発明は、全体としてテキストを生成する方法及びシステムに関し、特に、レポート用の構文法的に正しいテキストを生成する方法及びシステムに関する（ただし、これに限定されない）。
【解決手段】データを解釈するエキスパートシステムの能力は、人間の専門家を制限するのと同じ要因、すなわちデータ複雑性によって制限される。したがって、従来のエキスパートシステムは、ますます大量化する複雑なデータを解釈し、そのようなデータを知識に変換する際に制限を受ける。本発明は、複雑なデータを解釈し、そのようなデータをテキストレポート内で表現される知識に変換する手段を提供する。
【解決手段】データを解釈するエキスパートシステムの能力は、人間の専門家を制限するのと同じ要因、すなわちデータ複雑性によって制限される。したがって、従来のエキスパートシステムは、ますます大量化する複雑なデータを解釈し、そのようなデータを知識に変換する際に制限を受ける。本発明は、複雑なデータを解釈し、そのようなデータをテキストレポート内で表現される知識に変換する手段を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全体として、テキストを生成する方法及びシステムに関し、特に、構文法的に正しいテキストをレポート用に生成する方法及びシステム（ただし、これに限定されるわけではない）に関する。
【背景技術】
【０００２】
２０世紀半ば以来の、処理速度及びメモリ容量を含むコンピュータ能力の指数関数的な増大が、社会のあらゆる部門における、まさにわれわれの日常生活におけるコンピュータ利用の有用性を劇的に高めた。コンピュータの主要な用途の一つは、ますます量を増大させるデータの生成及び保存である。しかし、生のデータは、それ自体では、限られた価値しか持たない。ほとんどの場合、その真の価値は、生データが誰かによって解釈され、必要な理解と洞察がもたらされたときに、初めて獲得することができる。この解釈プロセスは、「データ」を「知識」に変換し、それをしばしば「判断」に変換する付加価値プロセスである。この知識又は判断は、テキストのレポートでしばしば表現される。
【０００３】
コンピュータ処理されるプロセスは、数値データ及びテキストデータの双方を抽出し、対照し、保存するのに役立つが、このデータを人間又はコンピュータによって効果的に解釈する能力は、大きなデータ量とそれに伴う複雑性によって制限されることがある。
【０００４】
人間の場合、データの本体をタイムリーに正確に解釈するように判断を下す能力には、有意な特徴（ｓｉｇｎｉｆｉｃａｎｔ ｆｅａｔｕｒｅｓ）が明白となるようにデータが前処理され十分に縮小されていることが必要となる。
【０００５】
ルールベースのエキスパートシステムの場合、大きく複雑なデータセットの全ての特殊性を考慮するのに必要とされるルールの増殖を回避するために、各ルールはできるだけ汎用的にするという更なる関連要件が存在する。より汎用的なルールは、データセットからの、より上位の抽象概念（ａｂｓｔｒａｃｔｉｏｎｓ）を使用して構築されるので、基礎をなすデータの詳細のばらつきは、それらのルールを必ずしも無効にしない。これらのより上位の抽象概念は、まさに、ルールベースのエキスパートシステムを構築する人間の専門家が使用する有意な特徴である。
【０００６】
すなわち、人間の専門家とちょうど同じように、エキスパートシステムは、大きな一組の原データ値ではなく、より小さな一組の有意な特徴に基づいて推論を行うことができる形式に複雑なデータが縮小されることを必要とする。
【０００７】
したがって、後続の解釈のために人間又はコンピュータに提示できる、より小さなあまり複雑でない一組の有意な値にデータを前処理することによって、解釈すべきデータのデータ複雑性を低減する方法を見つけることが課題である。
【０００８】
データ複雑性に寄与する主要な要因は二つ存在する。
【０００９】
第１の要因は、解釈する必要があるかもしれないデータ項目値の数そのものであり、すなわち、与えられたシステム内に、分析する必要がある多数の要素が存在する場合である。
【００１０】
例えば、委託医師向けの患者検査レポートを作成するために、研究所の病理学者は、患者の血液サンプルを分析した診断機器で使用された数百ものタンパク質バイオマーカーの結果を解釈しなければならないことがある。
【００１１】
複雑性に拍車をかける第２の要因は、個々のデータ値それ自体のサイズと、おそらくは構造化されていない（「自由形式の」）フォーマットである。単一の数値又は列挙値（すなわちテキストコード）は、それ自体では、例えば３．４ｍｍｏｌ／Ｌのトロポニン値など、この「原子的な」値と、対応するデータ項目とに明らかな関連性が存在するので、解釈が比較的簡単かもしれない。
【００１２】
しかし、大きな自由形式のテキストは、曖昧表現、誤字、略語、二つ以上のデータ値、又は同じデータ値の多くの異なる可能な解釈のうちの一つを含むことがあり、これが解釈をはるかに困難にする。
【００１３】
例えば、委託医師向けの患者検査レポートを作成するために、研究所の病理学者は、委託医師によって提供された患者の長大なテキストの病歴に照らして、機械が生成した検査結果を解釈しなければならないことがある。病歴は、大きな構造化されていないデータ項目なので複雑であり、テキスト内の比較的小さなばらつきが、得られる解釈を完全に変えてしまうことがある。例えば、省略形の語句「ＤＭ」（既知の真性糖尿病（ｄｉａｂｅｔｅｓ ｍｅｌｌｉｔｕｓ））、「ＦＨ ＤＭ」（真性糖尿病の家族歴）、「？ ＤＭ」（糖尿病の疑い）、「ｎｏｔ ＤＭ」（糖尿病ではない）はどれも、与えられた一組のグルコース検査結果についての病理学者の解釈を変化させる。臨床メモ内の同義語（「ＤＭ」、「Ｄｉａｂｅｔｉｃ」（糖尿病の）、「Ｄｉａｂ」（糖尿）、「Ｄｉａｂｅｔｅｓ ｎｏｔｅｄ」（糖尿病注意））、誤記（「Ｄｉａｂｅｔｅｓ Ｍｅｌｌｉｔｉｓ」）、語順の変化（「？ ＤＭ」、「ＤＭ ？」）はどれも、解釈を行うときに、病理学者によって理解される必要があることにも留意されたい。
【００１４】
病歴は、語句「ｏｎ Ｚｏｃｏｒ」（Ｚｏｃｏｒ投与中）又は「ｏｎ ｌｉｐｉｄ ｌｏｗｅｒ ｔｒｅａｔｍｅｎｔ」（脂質低下薬投与中）も含むことがあり、どちらの語句（フレーズ）も、患者が何らかの心臓薬を服用しているかどうかを病理学者に伝える第２の概念を表す。この種の語句も同様に、検査結果についての病理学者の解釈と、委託医師向けに作られるレポートに影響する。
【００１５】
具体例「ＤＭ，ｏｎ Ｚｏｃｏｒ」を見ると、「病歴」データ項目と原子的な値の間に明らかな関連性は存在しない。むしろ、複雑なデータ項目としての病歴は、二つのより単純で原子的なデータ項目、例えば「糖尿病（はい）」と「治療薬投与（はい）」を暗示的に含む。
【００１６】
データ項目値のサイズと構造の欠如とに起因するこの第２のタイプの複雑性の別の例は、第１の所究所が、患者検査の幾つかを「内部的に」実行する一方で、幾つかのより専門的な検査のために血液サンプルを第２の研究所に送付する場合である。第２の研究所は、テキストレポートで検査結果を返送する。第１の研究所の病理学者の観点からは、第２の研究所から受け取ったレポートは、複雑なデータ項目である。病理学者は、委託医師向けの最終レポートを作成するために、このレポートに加えて、第１の研究所で行われた結果も解釈しなければならない。
【００１７】
複雑なデータを伴う臨床分野の別の例は、アレルギー分野である。この分野では、関連する一つ以上のアレルゲンを特定するために、可能性のあるアレルゲンを血液サンプルにおいて検査し、その後、長大かもしれない自由形式の患者病歴における症状と照合する必要がある。他の例としては、伝染病（病原菌の特定）や多臓器疾患（例えば、神経学的、内分泌学的、腫瘍学的な遠因の特定）が挙げられる。
【００１８】
複雑なデータの解釈における同様の困難は、（例えば、航空券、運転免許証、及びパスポートの再発行、クレジットカードでの購入、並びに電子商取引における）不正検出、物流における監査、在庫管理、（例えば、偽造の検出における、若しくは製品リコール目的のための）シリアルナンバー管理、又はＩＴサポートサービスなどの非医療分野でも生じる。
【００１９】
航空会社不正検出の例では、チケットの販売及び乗客のフライトに関する構造化されていない又は半構造化されたデータを含む多数のイベントが記録され、その後、指定された航空券に対して正しい価格が適用されたかどうかを識別するために、価格決定運賃表及び航空券再発行のための他の基準と照合される必要がある。これは面倒な業務である。というのも、運賃表及び航空券に含まれる情報は、構造化されていないか、又は半構造化されているにすぎず、また、各集合は、運賃表に表された条件に実際に従っているかどうかを判断するために、人間の専門家によって個別に解釈されるからである。
【００２０】
人間の専門家による効率的で正確な解釈を可能にするために、（この例では）運賃表の複雑なデータは、特定のチケットに適用可能な一組の条件に縮小される必要がある。そのチケットの関連する特性（出発都市及び行先都市、搭乗日、搭乗クラス、価格）も、抽出される必要がある。運賃表及びチケットのデータが前処理されて、これらの有意な特徴になれば、不正な又は間違った発券イベントが存在するかどうかに関して、人間の専門家が判断を下すことができる。
【００２１】
不動産査定の仕事は、複雑なデータの解釈が必要とされる別の領域である。この分野では、必要とされる解釈は、金額とその根拠となる説明から構成される査定である。解釈がなされるデータは、家屋及び土地の広さ、家屋の向き、付近の郵便番号及び最近の査定、又は他の比較し得る不動産を含む、様々な複雑で異種のデータから成る。不動産の様々な特性（例えば、隣接する高層アパートによって遮られる眺望）を記述した自由形式のテキストメモは、査定に影響する重要な要因を含むことがあり、そのため、解釈を必要とする。
【００２２】
複雑なデータの解釈を必要とする非医療分野の別の例は、ＩＴサポートサービスの分野である。企業が、ニュースフィード又は他のレポートなど、定期的な付加価値出力を契約顧客に提供するオンライントランザクション処理システムを考えてもらいたい。
【００２３】
企業のオンライントランザクション処理システムの信頼性は、このサービスの性能に不可欠である。非常に高い水準の信頼性を達成するには、システムの信頼性に影響し得る全ての要因について、システムを継続的に監視し続けなければならない。
【００２４】
これらの要因は、トランザクションレート、ユーザアクティビティ、メモリ、ディスク、及びＣＰＵなどのリソース利用に加えて、オペレーティングシステムが発生させる警報及び警告、並びにトランザクション処理アプリケーション自体が発生させる警報及び警告を含む。これらの要因を記録する標準的な方法は、ログファイルなどの中央設備に、こうした情報の全てを継続的にログに取ることであり、中央設備では、そのような情報を企業のＩＴサポートスタッフによって定期的に分析することができる。目標は、オンライントランザクションシステムが障害を起こす前に、ログファイルに記録されたあらゆる深刻な警報又は気がかりな傾向にＩＴサポートスタッフが対応することである。
【００２５】
ログエントリは、しばしば異なる製造元製品に属する様々なオペレーティングシステム又はアプリケーションシステムのコンポーネントによって生成されるので、ユニバーサルコーディングシステムによってフォーマットされておらず、基本的に自由テキストである。大規模なオンライントランザクション処理システムの場合、ログファイルは、例えば１日当たり数十メガバイトなど、非常に大きくなることがあり、ＩＴサポートスタッフが人的に検査できる範囲を超えている。更に、あるクラスの警報は、即座の行動を必要とすることがあり、その場合、警報及び対応する修復行動の決定が迅速に確認される必要があるかもしれない。
【００２６】
先の例のように、人間の専門家による効率的で正確な解釈を可能にするには、ログファイル内の複雑なデータは、何らかの修復行動を取る必要があるかどうかに関して人間の専門家が判断を下す際の基礎となる一組の有意な特徴（例えば、警報や傾向の状態条件）へと前処理される必要がある。
【００２７】
コンピュータベースのエキスパートシステムは、人間の解釈プロセスを模倣しようと試みている。例えば、リップルダウン（ＲｉｐｐｌｅＤｏｗｎ）は、米国特許第６５５３３６１号で説明されているように、高度に特有な解釈をどのようにケースバイケースに行うかを分野の専門家によって教え込まれたコンピュータベースのエキスパートシステム（決定エンジン）である。
【００２８】
人間の専門家と同様に、ルールベースのエキスパートシステムは、関連する有意な特徴からシステムが推論を行えるように、それらの特徴に関してデータがシステムに提示されるようにする必要がある。複雑な生データ（例えば、運賃表及びチケット自体におけるデータ）から推論を行うとすれば、必要とされる具体的なルールの数が扱いきれないほどになるばかりでなく、ひとたびルールを構築してしまうと、運賃表やチケットにおいて新たに遭遇するどのようなバリエーションも解釈に失敗することになる。
【００２９】
高トランザクション環境では、エキスパートシステムは、人間の専門技術を高めて生データの迅速な解釈をもたらすうえで重要な役割を果たすことができる。例えば、病理学研究所は、その研究所で雇用できる僅かな人数の病理学者の人的能力をはるかに超えた、１日当たり数万人の患者についての解釈レポートを提供する必要がある可能性がある。
【００３０】
しかし、データを解釈するエキスパートシステムの能力は、人間の専門家を制限するのと同じ要因、すなわち、データ複雑性によって制限される。複雑なデータは、人間の専門家が使用するよりも上位の概念を使用してルールを構築できるような形式に前処理して、そうでなければ生じるであろうルール及びレポート定義の増殖を回避する必要がある。
【００３１】
以下では、データ複雑性問題のより詳細で具体的な二つの例を提示する。
【００３２】
第１のより具体的な例は、内科病理学の分野におけるものである。この分野では、病理医などの専門家によって通常は実行される複雑な調査が、しばしば多数の検査を必要とする。検査結果の解釈は、しばしば困難であり、専門家又はエキスパートシステムの技量を必要とする。専門家又はエキスパートシステムは、検査結果の有益な分析及び解釈を時には高度に要約された形式で含むレポート内に含まれるテキストを生成し、そのレポートは、生の検査結果自体を解釈するための専門知識をもたない可能性のある委託医師（例えば家庭医）に送られる。これまでは、検査が比較的相互に独立している分野において、エキスパートシステムの知識ベース（ナレッジベース）が構築されてきた。例えば、甲状腺レポート用の知識ベースは、甲状腺機能検査の結果（すなわち、ＴＳＨ、ＦＴ３、及びＦＴ４）を主として考察する。身体検査又は口述された病歴から臨床メモに記録された所見と同様に、年齢及び性別などの他の患者人口統計データも、一般に考慮される必要がある。これらの知識ベースを使用して生成されたレポートは、これらの個々の検査及びそれらの値に言及するのに加えて、診断も提供し、しばしば治療及び追跡検査の推奨も与える。一般に、これらの分野では、検討すべき２０未満の検査に加えて、年齢及び性別などの患者人口統計データと、開業医によって提供される臨床メモ内の所見が存在する。検査結果は相互作用することがあるため、ある程度、関連をもつことがあるが（例えば、一つの検査が異常である場合、別の検査も異常である可能性が高い）、考慮すべき検査及び検査相互作用の数が少なければ、知識ベース内のルールは、個々の検査結果そのものに言及でき、依然としてその一般性を維持できる。すなわち、検査結果が、解釈の前に何らかの前処理工程によって、より小さな一組の有意な特徴に縮小される必要はない。
【００３３】
ある条件下で与えられたテキストコメントから構成される具体的なルールは、各個別検査結果を考慮することによって、又は検査結果の比較的少数の有意な組合せを考慮することによって、書くことができる。例えば、一群の甲状腺検査の場合、ＴＳＨ検査結果が上昇したのであれば、「原発性甲状腺機能低下症と一致する」というコメントが生成されることがある。
【００３４】
上記の甲状腺の例など従来の臨床分野は、少数の属性（Ａｔｔｒｉｂｕｔｅｓ）しか有さない。しかし、数百又は数千にすらなる可能性のある調査が見込まれる、より新しい臨床分野の場合、各種類の調査へ具体的なルールを適用することは不可能になる。例えば、開業医は、ピーナッツ、大豆、ミルク、小麦、卵など、多くの食品アレルギー検査を要求することがある。大豆及びミルクが非常に高い陽性値（例えば、それぞれ２４．３及び３０．１）を返し、他の検査が陰性である場合、病理学者は、医師に返送するレポートに、 「非常に高い結果がミルク（３０．１）及び大豆（２４．３）に対して検出された」
のようなコメントを含めることを望む。
【００３５】
検査データの解釈がこのコメントを与えることを可能にするルールは、
１０≦ミルク≦５０、非常に高い結果を指示する
１０≦大豆≦５０、別の非常に高い結果を指示する
ミルク＞大豆、レポート内でミルク値が大豆よりも前となるべきことを指示する
ピーナッツ＝０
小麦＝０、卵＝０
に基づいている。
【００３６】
たかだか五つのアレルゲンが検査されるこの単純な例では、上記のコメントの組合せの数は２５＝３２（重要度の順序は無視）である。検査結果の各組合せに対応して、異なるルールが存在する必要がある。
【００３７】
この単純なコメントであっても、このコメントと対応するルールとの３２個の可能な組合せの各々を個別に定義することは明らかに現実的ではない。そして、現実世界の例は、これよりもはるかに複雑である。
【００３８】
アレルギー知識ベースの場合、調査において実行できる文字通り数百の可能な検査が存在し、各々は、同じ化学物質（ＩｇＥ）を測定し、各検査の値は、特定のアレルゲンに対する患者の反応を示す。調査において数百の検査が存在する場合、専門家が、検査結果間に生じうる相互作用を定義して、正確なレポートが必要とする多数のコメントバリエーションを提供することは不可能である。解釈的知識ベースが定義できるようになる前に、この分野のデータ複雑性を大幅に低減しなければならない。
【００３９】
しかし、高度に複雑なデータを考慮したレポートを生成するという計算上の課題は、従来のエキスパートシステムの能力を超えている。例えば、４００の検査が存在すれば、各検査が、「陽性」又は「陰性」など、わずか２種類の出力しかもたない場合でも、検査結果の可能な組合せは２４００も存在し、各組合せは、あらかじめ生成されてコンピュータシステム上に保存される固有のレポート用テキスト結論を必要とする。ここでは、検査データ間に生じうる相互作用や、状況を大きく複雑化する臨床メモなどの他の関連する入力を考慮すらしていない。複雑なデータを解釈しようと試みる従来の手法は、数百又はそれ以上の所見が存在する場合は、実現可能ではない。
【００４０】
臨床環境では、様々な症例及び対応するレポートは、検査の数があまり多くなくても膨大になることがあり、患者の病歴情報及び臨床メモも考慮される場合は、なおさらそうである。
【００４１】
第２のより具体的な例は、航空会社によって直接的に、又は旅行代理店、航空券安売業者、若しくはオンライントラベルウェブサイトを介して間接的に航空券が発行される可能性のある航空券発行アプリケーションである。（例えば、旅行プラン変更のため、又は紛失チケット若しくは破損チケットの交換のため）チケットを再発行する必要がある場合、運賃表（航空券に影響する期間及び条件についての文書）に照らして、並びに元の取引明細（例えば、支払われた金額、購入チケットの枚数、取引通貨、乗客の名前、購入日付及び場所）に照らして、元の取引の詳細を確認する必要がある。とりわけ困難なのは、航空運賃表が複雑なテキストデータ項目であることである。航空運賃表は、何らかの明確なフォーマットに従っていないが、それにも関わらず、特定の重要な情報を含んでいる。この情報は、「キャンセル」、「旅行前」、「紛失チケット」などといった多数のキーターム（Ｋｅｙ Ｔｅｒｍ、キーとなる用語）として、更に、金銭値及び日付として、しばしば表現される。一つの運賃表内で、また複数の運賃表間で、各キータームは、様々な形で出現することがある。例えば、「ｆｒｅｅ ｏｆ ｃｈａｒｇｅ」（無料）、「ｆｏｃ」、及び「ｎｏ ｐｅｎａｌｔｙ」（違約金なし）は全て、同じことを意味する。
【００４２】
運賃表の各々は、キータームを含むばかりでなく、搭乗前キャンセルのための違約金、紛失チケットのための違約金などといった特定の情報も指定する。これらのキーコンセプト（Ｋｅｙ Ｃｏｎｃｅｐｔ、キーとなる概念）の各々は、キータームを使用して、様々な異なる方法で表現される。
【００４３】
したがって、上記の例では、様々な方法で表現された関連する情報を含む自由テキストのブロックを解析し、その後、自由テキストからの情報を他のデータとともに解析して、結論に達することが必要である。類似の問題は、医療診断（臨床メモが自由テキストで表現された重要な情報を含むことがあり、病理学検査及び人口統計データと併せて解釈されなければならない）の場面でも生じる。
【００４４】
自由テキストのブロックを解釈する際の困難には、以下が含まれる。
（ａ）一つ以上の有意な特徴を使用してルールを構築できるように、自由テキストのブロックからこれらの有意な特徴を抽出する際の困難。
（ｂ）知識ベースが、自由テキストブロックの少数の変形例を扱う困難。自由テキストブロック内のテキストデータが、ルールが構築されたテキストと全く同じではない場合、それらのルールは、新しい自由テキストブロックにも依然として適用されるほど十分には汎用的でないことがある。
（ｃ）知識ベースが、一つの自由テキストブロック内で、又は複数の自由テキストブロック間で、有意な特徴自体の異なる表現を扱う困難。
（ｄ）複数のキータームを含み、場合によっては幾つかのより上位のキーコンセプトを包含した自由テキストブロックに基づいてルールを構築する必要性。「キーコンセプト」は、解釈を行うときに専門家又はエキスパートシステムによって使用される、自由テキスト内に埋め込まれた有意な特徴である。キーコンセプトは、一連のキーターム（一つのキータームシーケンス）を表す、より上位の固有コードである。キータームシーケンスの幾つかの変形例が、単一のキーコンセプトにマッピングされる可能性がある。
【００４５】
要約すると、データを解釈する際に人間の解釈プロセスを模倣するために使用される従来のコンピュータ応用エキスパートシステムは、複雑なデータを解釈するために使用される場合には、以下を含む多くの制約を受ける。
（ａ）結論に達するため又は判断（例えば最終的な診断）を表現するために非常に多数のデータ値を考慮する必要がある場合、解釈プロセスを操るルールが過度に複雑で扱いにくくなるので、非常に大量のデータ値を解釈するのは困難である。
（ｂ）大きな構造化されていないデータ項目値を扱うのは困難であり、その結果、そのような複雑なデータの解釈ができない。複雑なデータ項目を、より単純で原子的なデータ項目及び値を抽出でき、それらをルール及び結論において使用できるようにする正規の形式に縮小することは、扱いにくいプロセスであり、知識ベースを維持するうえで長期にわたる苦労をもたらす。
【００４６】
したがって、従来のエキスパートシステムは、ますます大量化する複雑なデータを解釈し、そのようなデータを知識又は判断（テキストのレポートで表現される知識又は判断）に変換する際に制約を受ける。異なるソースから取得される数値データ及びテキストデータを含み、自由形式テキスト又はその代わりに「概況（ｓｙｎｏｐｔｉｃ）」レポートでのような構造化されたテキストを含む様々な形式で提示される大量の複雑なデータを解釈することが可能な、テキスト（テキストレポートなど）を生成するコンピュータ応用方法及びシステムが要望されている。
【発明の概要】
【発明が解決しようとする課題】
【００４７】
本発明の目的は、複雑なデータを解釈して、そのようなデータをテキストレポートで表現される知識又は判断に変換する際における従来のエキスパートシステムの上述した制約を解消する方法及びシステムを提供することである。
【課題を解決するための手段】
【００４８】
本発明の第１の態様によれば、複数のデータ項目から情報を生成する方法が提供される。この方法は、
（ａ）複数のデータ項目の少なくとも一つを用いて集約データ項目（ａｇｇｒｅｇａｔｅ ｄａｔａ ｉｔｅｍ）をポピュレート（ｐｏｐｕｌａｔｅ）する工程と、
（ｂ）集約データ項目を使用して情報を生成する工程と
を含み、
集約データ項目は、派生属性（ｄｅｒｉｖｅｄ ａｔｔｒｉｂｕｔｅ）の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
情報を生成する当該方法が、決定支援システムによって実行され、
生成された情報が、以下のグループ
ｉ．テキスト情報、
ｉｉ．機械命令
のうちの一つ以上に属する。
【００４９】
本発明の第２の態様によれば、複数のデータ項目から情報を生成するシステムが提供される。このシステムは、
（ａ）プリプロセッサであって、
ｉ．複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．複数のデータ項目から一つ以上の他の派生属性を構築する
プリプロセッサと、
（ｂ）前記集約データ項目を使用する派生属性及び他の派生属性を使用して情報を生成する情報生成器と
を備え、
情報生成器が、決定支援システムの少なくとも一部を成し、
前記集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
生成された情報が、以下のグループ
ｉ．テキスト情報
ｉｉ．機械命令
のうちの一つ以上に属する。
【００５０】
一実施形態では、この方法は、所定の構造の複数の要素の各々を、前記データ値のうちの対応する一つでポピュレートする前工程を含む。この構造は、前記複数の要素の各々を集約データ項目に関連付ける。この方法は、この構造に従って、前記複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートしてもよい。
【００５１】
一実施形態では、この方法は、前記構造を処理して、集約データ項目の一つ以上の特性を決定する工程を含む。
【００５２】
一実施形態では、前記構造は、複数の集約データ項目を相互に関連させ、この方法は、前記構造を処理して、前記複数の集約データ項目の各々の一つ以上の特性を決定する工程を含む。
【００５３】
一実施形態では、前記情報はテキスト情報を含む。前記情報は、臨床決定支援情報であってもよい。この他に、前記情報は機械命令を含む。
【００５４】
一実施形態では、情報を生成する工程は、知識ベース又は決定支援システムを使用して情報を生成する工程を含む。
【００５５】
一実施形態では、集約データ項目をポピュレートする工程は、複数のデータ項目を受け取る工程を含む。一実施形態では、テキスト情報は、構文法的及び／又は文法的に正しいものであってもよい。テキスト情報は、人間が読むことのできるものであってもよい。一実施形態では、テキスト情報は、レポートの少なくとも一部を成していてもよい。レポートは、一つ以上の検査結果に関連付けられていてもよい。一実施形態では、各データ項目は、検査結果の一つに対応することができる。検査は、アレルギー検査、白血病検査、病理学検査、血液検査、及び任意の他の種類の医療検査のいずれを含んでいてもよい。データ項目は、任意の他の情報、例えば、性別、年齢、人口統計情報、臨床症状に対応していてもよい。
【００５６】
一実施形態では、集約データ項目は、互いに関連する複数のデータ項目を含む。一実施形態では、集約データ項目をポピュレートする工程は、これら複数のデータ項目の少なくとも一つ又は別の集約データ項目に一のルールを適用することによって、集約データ項目をポピュレートする工程を含む。このルールは、分野に特有のルールであってもよい。この他に、このルールは、ケースに特有のルールであってもよい。このルールは、前記複数のデータ項目の一つ以上を用いて集約データ項目をポピュレートするためのものであってもよい。ルールは、閾値を上回る一つ以上の前記データ項目を用いて集約データ項目をポピュレートするためのものであってもよい。ルールは、閾値を下回る一つ以上の前記データ項目を用いて集約データ項目をポピュレートするためのものであってもよい。
【００５７】
一実施形態では、この方法は、（ａ）複数のデータ項目のうちの少なくとも一つを用いて一つ以上の集約データ項目をポピュレートする工程と、（ｂ）前記一つ以上の集約データ項目に一つ以上のルールを適用することによって、前記一つ以上の集約データ項目からのデータ項目を用いて一つ以上の更なる集約データ項目をポピュレートする工程と、（ｃ）一つ以上の更なる集約データ項目を使用して情報を生成する工程とを含む。
【００５８】
一実施形態では、複数のデータ項目の各々は、識別子及び値に関連付けられる。複数のデータ項目の各々は、その識別子及び値を含んでいてもよい。この識別子は、データ項目の名称又はラベルに関連付けられてもよい。一実施形態では、情報を生成する工程は、集約データ項目をポピュレートするデータ項目の名称又はラベルを情報に含める工程を含む。情報を生成する工程は、集約データ項目をポピュレートするデータ項目に関連付けられた値を情報に含める工程を含んでいてもよい。情報を生成する工程は、情報内における名称又はラベルの順序を決定する工程を含んでいてもよい。
【００５９】
一実施形態では、情報を生成する工程は、集約データ項目の一つ以上の特性を決定する工程を含む。特性を決定する該工程は、集約データ項目を構成するデータ項目の数を決定する工程、集約データ項目が空であるかどうかを決定する工程、集約データ項目が特定のデータ項目を含むかどうかを決定する工程、集約データ項目が特定のデータ項目を含まないかどうかを決定する工程、及び複数の集約データ項目がデータ項目を共有するかどうかを決定する工程のうちの一つ以上を含んでいてもよい。特性の一つは、値であってもよい。
【００６０】
一実施形態では、情報を生成する工程は、集約データ項目の決定された特性を情報に含める工程を含む。
【００６１】
一実施形態では、集約データ項目をポピュレートする工程は、一つ以上の他の集約データ項目を用いて集約データ項目をポピュレートする工程を含んでいてもよい。この集約データ項目と一つ以上の集約データ項目の各々とは、一つの集約識別子に関連付けられていてもよい。集約識別子は各々、集約名に関連付けられていてもよい。情報を生成する工程は、集約名を含める工程を含んでいてもよい。集約名を情報に含める工程は、情報内における集約名の順序を決定する工程を含んでいてもよい。
【００６２】
一実施形態では、集約データ項目をポピュレートする工程は、二つの他の集約データ項目に演算を施す工程を含む。演算を施す工程は、二つの他の集約データ項目の差、和、及び積のうちの一つ以上を含んでいてもよい。一実施形態では、集約データ項目をポピュレートする工程は、別の集約データ項目を構成するどのデータ項目が、特定の範囲内の値又は特定の離散集合に属する値を有するかを決定する工程を含む。
【００６３】
一実施形態では、情報を生成する工程は、集約データ項目に一つ以上のルールを適用する工程を含む。これら一つ以上のルールは、リップルダウンルール知識システムの少なくとも一部を成していてもよい。
【００６４】
一実施形態では、情報を生成する工程は、派生属性を構成する（一つ以上の）データ項目の（一つ以上の）識別子を情報に含める工程を含む。
【００６５】
一実施形態では、情報を生成する工程は、データ項目を構成するデータ項目の値を情報に含める工程を含む。
【００６６】
一実施形態では、情報を生成する工程は、情報内におけるデータ項目識別子の順序を決定する工程を含む。
【００６７】
一実施形態では、この方法は、情報の概念表現を構築する工程を更に含み、
概念表現は、
（ａ）複数のデータ項目、
（ｂ）一つ以上の派生属性、
（ｃ）一つ以上のルールの以前の反復において評価された一つ以上の結論
のうちの一つ以上の解析に基づいて決定支援システムのルールを評価することにより与えられる結論であり、結論の構築は、これらのルールの連続する再評価において行われる。
【００６８】
一実施形態では、この方法は、結論を構築する工程を更に含み、結論の構築は、ルール評価の反復において行われ、連続する各ルール評価は、以前のルール評価において構築された結論を利用する。
【００６９】
一実施形態では、複数のデータ項目から情報を生成するシステムであって、そのシステムは、複数のデータ項目のうちの少なくとも一つを用いて集約データ項目をポピュレートする集約データ項目ポピュレータと、集約データ項目を使用して情報を生成する情報生成器とを備える。
【００７０】
一実施形態では、情報生成器は、テキスト情報を生成するテキスト情報生成器である。あるいは、情報生成器は、機械命令を生成する機械命令生成器である。
【００７１】
一実施形態では、このシステムは、知識ベース又は決定支援システムを備える。一実施形態では、システムは、複数のデータ項目を受け取るデータ項目受信機を備える。情報生成器は、構文法的及び／又は文法的に正しいテキスト情報を生成するように構成されていてもよい。情報生成器は、人間が読めるテキスト情報を生成するように構成されていてもよい。情報生成器は、符号化テキスト情報を生成するように構成されていてもよい。符号化テキスト情報は、機械命令であってもよい。
【００７２】
一実施形態では、複数のデータ項目から情報を生成するシステムであって、そのシステムは、
（ａ）プリプロセッサであって、
ｉ．複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．複数のデータ項目から一つ以上の他の派生属性を構築する
プリプロセッサと、
（ｂ）集約データ項目を使用する派生属性及び他の派生属性を使用して情報を生成する情報生成器と
を備え、
情報生成器が、決定支援システムの少なくとも一部を成し、
集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
生成された情報が、以下のグループ
ｉ．テキスト情報
ｉｉ．機械命令
のうちの一つ以上に属する。
【００７３】
一実施形態では、情報生成器は、レポートの少なくとも一部を成すテキスト情報を生成するように構成されていてもよい。一実施形態では、集約データポピュレータは、複数のデータ項目のうちの少なくとも一つにルールを適用することによって集約データ項目をポピュレートするように構成されていてもよい。
【００７４】
一実施形態では、情報生成器は、集約データ項目をポピュレートするデータ項目に関連付けられた名称又はラベルを情報に含めるように構成される。情報生成器は、集約データ項目をポピュレートするデータ項目に関連付けられた値を情報に含めるように構成されていてもよい。情報生成器は、テキスト内における名称又はラベルの順序を決定するように構成されていてもよい。
【００７５】
一実施形態では、システムは、解釈部分を含む情報の概念表現を構築するビルダー（ｂｕｉｌｄｅｒ）を更に備えており、解釈部分は、複数のデータ項目を含む集約データ項目に対する演算を表す。
【００７６】
一実施形態では、情報生成器は、集約データ項目の特性を決定するように構成される。情報生成器は、集約データ項目を構成するデータ項目の数を決定すること、集約データ項目が空かどうかを決定すること、及び集約データ項目が特定のデータ項目を含むかどうかを決定することのうちの一つ以上を含むように構成されていてもよい。
【００７７】
一実施形態では、情報生成器は、集約データ項目の決定された特性を情報に含めるように構成される。
【００７８】
一実施形態では、集約データポピュレータは、一つ以上の他の集約データ項目を用いて集約データ項目をポピュレートするように構成される。集約データポピュレータは、集約データ項目に関連付けられた集約データ項目名をテキストに含めるように構成されていてもよい。集約データポピュレータは、テキスト内における集約データ項目名の順序を決定するように構成されていてもよい。
【００７９】
一実施形態では、集約データ項目ポピュレータは、二つの他の集約データ項目に演算を施すように構成される。
【００８０】
一実施形態では、集約データ項目ポピュレータは、別の集約データ項目を構成するどのデータ項目が特定の範囲内の値を有するかを決定するように構成される。一実施形態では、情報生成器は、集約データ項目に一つ以上のルールを適用するように構成される。
【００８１】
一実施形態では、情報生成器は、検査が実行された局所特性を考慮するように構成される。
【００８２】
一実施形態では、複数のデータ項目から情報を生成する方法が提供され、その方法は、各々がデータ項目の一つ以上を含む一つ以上の集約データ項目を使用して、一つ以上のルールの結果を評価する工程と、その結果に従って情報を生成する工程とを含む。
【００８３】
一実施形態では、情報はテキスト情報を含む。あるいは、情報は機械命令を含む。
【００８４】
一実施形態では、情報を生成する工程は、知識ベース又は決定支援システムを使用して情報を生成する工程を含む。
【００８５】
一実施形態では、一つ以上のルールの結果を評価する工程は、これらのルールのうちの一つ以上のための基礎として、集約データ項目の特性を使用する工程を含む。
【００８６】
一実施形態では、複数のデータ項目から情報を生成するシステムが提供される。そのシステムは、各々が複数のデータ項目の一つ以上を含む一つ以上の集約データ項目を使用して一つ以上のルールの結果を評価する評価器と、該結果に従って情報を生成する情報生成器とを備える。
【００８７】
一実施形態では、情報生成器は、テキスト情報を生成するテキスト情報生成器である。あるいは、情報生成器は、機械命令を生成する機械命令生成器である。
【００８８】
一実施形態では、システムは、知識ベース又は決定支援システムを備える。
【００８９】
一実施形態では、情報を生成する方法が提供され、その方法は、解釈部分を含む情報の概念表現を受け取る工程であって、解釈部分が、複数のデータ項目を含む集約データ項目に対する演算を表す工程と、解釈部分から情報を生成する工程とを含む。
【００９０】
一実施形態では、情報はテキスト情報である。あるいは、情報は機械命令である。
【００９１】
一実施形態では、情報を生成する工程は、データ項目の各々に関連付けられた一つ以上の名称又はラベルを情報に含める工程を含む。情報を生成する工程は、複数のデータ項目の集団名を情報に含める工程を含んでいてもよい。一つ以上の名称又はラベルを含める工程は、情報をテキストの概念表現のリテラル部分と統合する工程を含んでいてもよい。
【００９２】
一実施形態では、概念表現は疑似テキストである。
【００９３】
一実施形態では、情報を生成する工程は、構文法的及び／又は文法的に正しいテキスト情報を生成する工程を含んでいてもよい。
【００９４】
一実施形態では、情報を生成するシステムが提供され、そのシステムは、解釈部分を含む情報の概念表現を受け取る受信機であって、解釈部分が、複数のデータ項目を含む集約データ項目に対する演算を表す、受信機と、解釈部分から情報を生成する情報生成器とを備える。
【００９５】
一実施形態では、情報はテキスト情報であり、その場合、情報生成器はテキスト情報生成器である。あるいは、情報は機械命令であり、その場合、情報生成器は機械命令生成器である。
【００９６】
一実施形態では、生成器は、データ項目の各々に関連付けられた一つ以上の名称又はラベルを情報に含めるように構成される。生成器は、複数のデータ項目の集団名を情報に含めるように構成されていてもよい。生成器は、情報をテキストの概念表現のリテラル部分と統合するように構成されていてもよい。
【００９７】
一実施形態では、生成器は、構文法的及び／又は文法的に正しいテキスト情報を生成するように構成されていてもよい。
【００９８】
一実施形態では、本発明は、本発明の第１の態様に係る方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラムを提供する。
【００９９】
一実施形態では、本発明は、本発明の第７の態様に係るコンピュータプログラムを提供するコンピュータ可読媒体を提供する。
【０１００】
一実施形態では、本発明は、本発明の第３の態様に係る方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラムを提供する。
【０１０１】
一実施形態では、本発明は、本発明の第９の態様に係るコンピュータプログラムを提供するコンピュータ可読媒体を提供する。
【０１０２】
一実施形態では、本発明は、本発明の第５の態様に係る方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラムを提供する。
【０１０３】
一実施形態では、本発明は、本発明の第１１の態様に係るコンピュータプログラムを提供するコンピュータ可読媒体を提供する。本明細書における用語「サーバ」は、クライアント−サーバアーキテクチャの一部において、接続されたクライアントに対するサービスを実行する、ハードウェアとソフトウェアの任意の組合せを包含することが意図されている。
【０１０４】
クライアントとサーバは、単一のハードウェア又は複数の接続されたハードウェア上で動作する別個のソフトウェアとすることができる。
【０１０５】
したがって、好ましい一実施形態では、本発明は、異なるソースから取得される数値データ及びテキストデータを含む大量の複雑なデータを解釈することが可能な手段を提供することによって、従来のエキスパートシステムの制限の少なくとも幾つかを克服する、テキスト（テキストレポートなど）を生成するコンピュータ応用方法及びシステムを提供する。一実施形態では、本発明は、自由形式テキストを含む様々な形式で提示されるデータを解釈する手段を更に提供する。
【０１０６】
本発明の本質のより良い理解を達成するため、以下では、テキスト情報を生成する方法及びシステムの実施形態を、添付の図面及び実施例を参照しながら、あくまで例示として説明する。
【０１０７】
ここで、例１は、白血病レポート知識ベースの形態をとる好ましい一実施形態に係るテキストを生成する方法及びシステムの一例である。
【０１０８】
例２は、アレルギーレポート知識ベースの形態をとる好ましい一実施形態に係るテキストを生成する方法及びシステムの別の例である。
【０１０９】
例３は、航空券発券監査システムの形態をとる他の実施形態に係るテキストを生成する方法及びシステムの一例である。
【０１１０】
例４は、ログファイル監視システムの形態をとる他の実施形態に係るテキストを生成する方法及びシステムの一例である。
【図面の簡単な説明】
【０１１１】
【図１】テキストのブロックとテキスト正規化属性「ＮｏｒｍＣａｔ」を使用したその「正規形」の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図２】「ＮｏｒｍＣａｔ」におけるキータームのリストと各キータームを定義する正規表現の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図３】正規化テキストから通貨及び値を抽出した変数を有するコメントの二つの例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図４】テキストレポートなどのテキスト又はテキスト情報を生成するシステムの一実施形態のブロック図である。
【図５】テキストレポートなどのテキスト又はテキスト情報を生成する方法の一実施形態のフロー図である。
【図６】テキストレポートなどのテキスト又はテキスト情報を生成するシステムの別の実施形態のブロック図である。
【図７】テキストレポートなどのテキスト又はテキスト情報を生成する方法の別の実施形態のフロー図である。
【図８】テキストレポートなどのテキスト又はテキスト情報を生成する方法のまた別の実施形態のフロー図である。
【図９】テキストレポートなどのテキスト又はテキスト情報を生成する方法の第３の実施形態のフロー図である。
【図１０】ある実施形態の、キータームを定義するテキスト要約器属性（ＴＣＡ：ｔｅｘｔ ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ）の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１１】キータームとともにキーコンセプトも定義される図１０の実施形態に係るテキスト要約器属性（ＴＣＡ）の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１２】自ら（「ＴＣＡ」）についての値とキーコンセプト「ＣｘＢｔ」、「ＣｘＡｔ」、「ＲｉＯｂ１」及び「ＲｉＲｔｃ」についての値をサンプルケースに与える図１０のテキスト要約器属性（ＴＣＡ）のユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１３】キーコンセプトの評価を定める照合用形式（Ｍａｔｃｈｉｎｇ Ｆｏｒｍ）の一例を示す図１０のＴＣＡのユーザインタフェースのウィンドウである。ユーザは、各照合用形式のための生テキストの一例を提供するように促される。示される例は、航空券発券に関係する。
【図１４】派生マッチ（Ｄｅｒｉｖｅｄ Ｍａｔｃｈ）のための照合用形式の一例を示す図１０のＴＣＡのユーザインタフェースのウィンドウである。キーワードが追加されたため、照合用形式は、もはやそれらの例と一致しない。示される例は、航空券発券に関係する。
【図１５】新しいキーワードが追加された場合、照合用形式がそれらの例の正規化バージョンと一致するように、照合用形式をどのように変更する必要があるかを示す図１０のＴＣＡのユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１６】コメント内の変数においてキーコンセプトをどのように直接使用できるかを示す図１０のＴＣＡのユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１７】「ＢＴ」から「ＢｅｆｏｒｅＴｒａｖｅｌ」へのキーワードの名称変更が照合用形式をどのように自動的に更新するかを示す図１０のＴＣＡのユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１８】日付及びブール値を抽出するＴＣＡの一実施形態のユーザインタフェースのウィンドウである。
【図１９】キーコンセプトのための例示的なブール値及び日付値を示す図１８の実施形態のユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図２０】派生属性及びそれが表す生テキストの一部がツールのヒント（ｔｏｏｌｔｉｐ）としてユーザに提供される、本発明に係るＴＣＡの一実施形態のユーザインタフェースの例示的なウィンドウである。
【図２１】データ項目と集約データ項目の階層関係の一実施形態の概略図である。
【発明を実施するための形態】
【０１１２】
表１は、本発明に従って定義された用語の辞書である。表１で定義された用語は、本文書の全体にわたって大文字を使用して表記される。用語に大文字が使用されていない場合は、別途指摘がない限り、その通常の意味で解釈されたい。
【０１１３】
【表１】
【０１１４】
好ましい一実施形態では、本発明は、異なるソースから得られる数値データ及びテキストデータを含む大量の複雑なデータを解釈することが可能な手段を提供することによって、従来のエキスパートシステムの制約の少なくとも一部を解消する、情報（テキストのレポート（Ｔｅｘｔｕａｌ Ｒｅｐｏｒｔ）など）を生成するコンピュータ応用方法及びシステムを提供する。一実施形態では、本発明は、自由形式テキストで提示されるデータの解釈を可能にする自由テキスト解析手段を含む、様々な形式で提示されるデータを解釈する手段を更に提供する。
【０１１５】
図４は、複数のデータ項目からテキストを生成するシステムの一実施形態のブロック図であり、番号１によって全体的に示される。システム１は、情報を処理できる任意のシステムを構成していてもよく、この実施形態では、コンピュータ可読媒体２上に存在し、システムの中央プロセッサ４を制御するための命令を含むコンピュータプログラムを有するコンピュータシステム１として説明することができる。これらの命令は、人間が読めるテキストのレポート内の情報などのテキスト情報を複数のデータ項目から生成する方法５００を実施するためのものである。方法５００のフロー図が、図５に示されている。
【０１１６】
あるいは、生成される情報は、レポートとして提示されるテキスト情報ではなく、一つ以上の機械命令であり、システム１の構成要素は、これに応じて変更される。「テキスト情報（ｔｅｘｔｕａｌ ｉｎｆｏｒｍａｔｉｏｎ）」という用語は、これ以降、適切な場合は、この代替実施形態を包含するように、より広い意味に解釈されるべきであることを理解されたい。
【０１１７】
図４を参照すると、コンピュータ可読媒体２は、ＳＣＳＩなどの適切なバス６によってプロセッサ４に接続されるハードドライブディスク２の形態を取る不揮発性メモリ２を含む。幾つかの実施形態では、不揮発性メモリ２は、例えば、フラッシュメモリ、ＣＤ、ＤＶＤ、又はＵＳＢフラッシュメモリユニットを含む。
【０１１８】
２．一つ以上のデータ項目８は、それらのデータ項目の出所である他のシステム又はユーザとの通信インタフェースの一部であるデータ受信機１０を介して受け取られる。受信機は、
（ａ）データ項目
（ｂ）派生属性
（ｃ）結論
のうちの一つ以上を受け取ることができる。
【０１１９】
各データ項目８は、処理すべき入力データ、例えば、ある調査の一つ以上の検査の結果や、処理を必要とする他の任意の単純な又は複雑なデータを表す。
【０１２０】
このような処理は、解釈部分を含む情報の概念表現を構成するビルダー（ｂｕｉｌｄｅｒ）によって実行することが可能であり、ここで、解釈部分は、複数のデータ項目を含む集約データ項目に対する演算を表現する。幾つかの実施形態では、これらのデータ項目のソースは、１の外部にある情報システム３７である。
【０１２１】
生成されたテキスト情報２６は、テキスト情報を必要とする他のシステム又は受取人（１人以上のユーザなど）との通信インタフェースの一部であるデータ送信機１１（送信機と呼ばれる）を介して送られる。幾つかの実施形態では、テキスト情報の送り先は、１の外部にある情報システム３７である。送信機は、生成された情報を、
（ａ）機械
（ｂ）受取人
のうちの一つ以上に送る。
【０１２２】
図６に示されるような幾つかの実施形態では、システム３は、組み込みシステムである。図４のシステム１の構成要素と同様の図６の構成要素は、同様に番号がふられる。この実施形態の組み込みシステム３は、医学的検査などの検査を実施する機器の一部を成す。図示されたアーキテクチャばかりでなく、端末／メインフレーム、クライアント／サーバ、クラウドコンピューティングなどの任意の適切なアーキテクチャを使用できることを理解されたい。
【０１２３】
図４及び図６に示される実施形態では、コンピュータ可読媒体（例えばハードドライブ）２は、集約データ項目、他の派生属性（Ｄｅｒｉｖｅｄ Ａｔｔｒｉｂｕｔｅｓ）、及びテキスト情報を生成するためのルール、を定めるためのコンピュータ命令を保有する。
【０１２４】
概略的に言えば、「派生属性」は、解釈のために知識ベースに提示された原データ内には存在しないが、何らかの式を使用してこのデータから構築されるデータ項目である。この式は、以下の考慮事項
（ａ）データ項目又は他の派生属性の識別子
（ｂ）データ項目又は派生属性の値
（ｃ）以下の中で提示されるデータ項目又は派生属性の複数のインスタンス
ｉ．時間ベースのシーケンス
ｉｉ．他の任意のベクトルフォーマット
のいずれかに基づいている。
【０１２５】
集約データ項目は、派生属性の一例である。原（又は「プライマリ」）データは、データ項目から値ペアへのマッピングとして提示される。病歴データが検討される場合、原データは、データ項目からそのデータ項目に関する値の時間ベースシーケンスへのマップとして提示される。原データ内のデータ項目は、「プライマリ属性」と呼ばれる。
【０１２６】
派生属性は、ルール及びレポート内でプライマリ属性よりも自然で汎用的に使用できる、より上位の概念である。例えば、プライマリ属性は、委託医師の名前であってもよい。より有用な派生属性は、委託医師の名前が専門医師リスト上の名前と一致した場合に値「真」を有する派生属性「専門医」であってもよい。別の例は、プライマリ属性が患者の身長及び患者の体重の場合である。有用な派生属性は、身長の２乗に対する体重の比として評価される数値から構成される属性「ＢＭＩ」であってもよい。
【０１２７】
図４及び図６を参照すると、システム１は、図５及び図７に示されるテキストを生成する方法を実行することによってデータ項目８を処理するように構成される。この他に、データ項目８は、不動産査定など、任意の専門分野に関係していてもよい。不動産「検査」又は評価についてのデータ項目８は、例えば、家屋及び土地の広さ、家屋の向き、付近の郵便番号及び最近の査定、又は他の比較し得る不動産を含む。専門分野の他の例には、不正検出、骨ミネラル濃度レポート、メディカル警報、ゲノムレポート、分子レポート、及びアレルギーレポートのうちの一つ以上が含まれる。本明細書で説明されるシステム１、３及び方法５００は、そのようなデータ項目８を前処理するように構成されていてもよい。
【０１２８】
図４の例示的な実施形態では、システム１は、データ項目８を受け取るデータ受信機１０を有し、データ項目８は、その後、ハードドライブ（又は他のコンピュータ可読媒体）２上に保存されてもよく、又は保存されなくてもよい。検査がシステム１から離れた場所で、例えば、リモートサイト１２で行われる実施形態では、システム１は、リモートサイト１２も接続されるネットワーク１４に接続されるように構成されていてもよい。ネットワーク１４は、インターネット又はクラウドなどのワイドエリアネットワークであってもよいが、リモートサイト１２は、例えば、システム１の隣の部屋など、きわめて近くにあってもよく、その場合、ネットワーク１４は、ローカルエリアネットワーク又はＷｉＦｉやＷＬＡＮなどのワイヤレスネットワークとすることができる。この他に、システム３が検査機器５の一部である図６に示される例では、データ受信機１０は、プロセッサ４とデータソース２２との間のインタフェースとして動作してもよい。データソース２２の例は、システム３のサンプル検査装置であり、この装置は、サンプルに対する物理的、化学的、生物学的検査又は他の分析を実行する。
【０１２９】
プロセッサ４（図４及び図６）は、ハードドライブ２（又は他のコンピュータ可読媒体）上に保存された複数のデータ項目８のうちの少なくとも一つを用いて集約データ項目２４をポピュレート（データ投入）する集約データ項目ポピュレータとしてプログラムされる。一実施形態では、集約データ項目２４は、プロセッサ４による処理のためのメモリ２０のある種のデータ構造（例えば、ファイル、リスト、配列、ツリー、レコード、データベースで使用されるテーブル、フラットファイル、又は索引システムなど、任意の形式の適切なデータ構造）である。データ項目８は、メモリ２０内にも保存することができる。この実施形態におけるメモリ２０は、ＣＰＵレジスタ、オンダイ８ＲＡＭキャッシュ、外部キャッシュ、ＤＲＡＭ、及び／又はページングシステム、ハードドライブ（若しくは他のコンピュータ可読媒体）２上の仮想メモリ若しくはスワップ空間、或いは他の任意のタイプのメモリを含む。しかし、実施形態は、適切な場合は、より多くの又はより少ないメモリタイプを有していてもよい。
【０１３０】
プロセッサ４は、集約データ項目２４を使用して情報２６を（例えば、テキストレポートとして、又は一つ以上の機械命令として）生成する情報生成器になるようにプログラムされる。情報生成器４は、そのように生成された情報２６をメモリ２０内に保存するように構成される。この実施形態では、テキスト情報２６は、構文法的及び／又は文法的に正しい、人間が読めるテキストを表す。
【０１３１】
システム１、３の出力はテキストの情報であり、好ましくは人間が読める形式のもの、例えば、モニタ又は画面２８に印字されるテキスト（例えばテキストレポート）、プリンタ３０によって紙のレポート３３に印刷されるテキスト、データ送信機１１によってネットワーク１４を介してユーザのワークステーション３２（例えば内科医や外科医のコンピュータ）又は別の情報システム３７に送信される電子メール又は他のタイプの電子メッセージ３４のうちの一つ以上である。プロセッサ４によって生成されるテキスト情報は、データ項目８から導出される他の何らかの決定支援結果などのテキスト情報であってもよい。一実施形態では、ＳＭＳゲートウェイ（又は他のＳＭＳ中継機構）３４は、人間が読める形式のテキスト情報２６（すなわち構文法的及び／又は文法的に正しいテキスト）を含むＳＭＳ又は電子メールなどの電子メッセージを、電子デバイスなどの受信機３６に送信するように、システム１によって命令される。デバイス３６は、モバイル電話、スマートフォン、ＰＤＡ、又は他のハンドヘルド電子デバイス、処理能力を有する他の任意のコンピューティングデバイスとすることができる。一実施形態では、システム１は、ＳＭＳをハンドヘルドモバイルデバイス３６に送信する命令を送るように構成される。これは、検査結果が異常であり、即座のフォローアップを必要とする場合、又は検査の結果が迅速に求められる場合（例えば、航空券を検査する場合）に有利である。
【０１３２】
図５を参照すると、複数のデータ項目からテキストレポート内の情報などのテキストを生成する方法５００の一実施形態が示されている。集約データポピュレータとして動作するプロセッサ４（図４及び図６）は、集約データ項目２４にデータを投入するようにプログラムされる。図７を参照すると、テキストを生成する方法の別の実施形態が示されている。この方法は、複数の集約データ項目のうちの少なくとも一つに一つ以上のルールを適用することによって、（図４及び図６でラベル２４を付された）集約データ項目をポピュレートする副工程を含む。
【０１３３】
ルールは、ルールベースの知識／エキスパートシステム又は決定エンジンの少なくとも一部を形成してもよい。適切なルール知識システムの一例は、参照により本明細書に組み込まれる、出願人の米国特許第６５５３３６１号の明細書で開示されるリップルダウン（ＲｉｐｐｌｅＤｏｗｎ）として知られる独自仕様システムである。その米国明細書で説明されるように、ルールの集まりが、専門家によって構築される知識ベースである。ルールは、分野に特有であってもよい。例えば、ルールは、アレルギー検査の分野に、又は白血病検査の分野に特有であってもよい。しかし、幾つかの他の例では、ルールは、ケースに特有のルールであり、すなわち、一組の関連する検査結果／データ項目８に特有のルールである。この場合、システム１は、知識ベース又は決定支援システムである。
【０１３４】
図４及び図６を参照すると、一つのケースでは、データ項目８は、関連する名称又はラベルの部分と、値の部分とを有し、例えば、
ミルク，２５
大豆，３０
ピーナッツ，０
のようになる。
【０１３５】
データ項目８の各々は、識別子（ここでは、ミルク、大豆、又はピーナッツ）と、値（ここでは、２５、３０、又は０）に関連付けられる。これらの実施形態では、データ項目８の各々は、識別子と値を含む。識別子は、この例では、テキストの情報２６を生成（例えば、図５の工程５０４を参照）するために使用できるデータ項目の名称又はラベル（例えば「ミルク」）である。システムは、この識別子を、指定された
（ａ）言語（生成される情報が人間に可読な場合）、又は
（ｂ）命令フォーマット（生成される情報が機械命令である場合）
に翻訳及び／又は表現することが可能なルールを含む。これは、生成される情報が、状況に適した言語／フォーマットで、又はルールによって他に決定されるように、生成されることを可能にする。
【０１３６】
名称又はラベル「非常に高い食品アレルゲン」を有する集約データ項目２４には、例えば、以下のようなルール
ミルク＞２５なら、ミルクを「非常に高い食品アレルゲン」に含める ＡＮＤ
大豆＞２５なら、大豆を「非常に高い食品アレルゲン」に含める ＡＮＤ
ピーナッツ＞２５なら、ピーナッツを「非常に高い食品アレルゲン」に含める
によって、上記のデータ項目８からポピュレート（例えば、図５の工程５０２を参照）することができる。
【０１３７】
この他に、名称又はラベル「非常に高い食品アレルゲン」を有する集約データ項目２４（図４及び図６）には、例えば以下のようなデータ前処理操作（例えば、図７の工程７０２を参照）
「非常に高い食品アレルゲン」は、範囲（２５，１００）内の食品アレルゲンである
を適用することによって、上記のデータ項目８からポピュレートすることができる。
【０１３８】
複数のデータ項目からの情報の生成は、
（ｄ）プリプロセッサ（前処理装置）であって、
ｉ．複数のデータ項目のうちの少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．これら複数のデータ項目から一つ以上の他の派生属性を構成する
プリプロセッサと、
（ｅ）この集約データ項目を使用する派生属性及び他の派生属性を使用して、情報を生成する情報生成器と
を含むことが可能であり、
情報生成器が、決定支援システムの少なくとも一部を成し、
集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念を抽出して、それにより、前記情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構成されるデータ項目であり、
そのように生成された情報が、以下のグループ
ｉｉｉ．テキストの情報
ｉｖ．機械命令
のうちの一つ以上に属する。
【０１３９】
プロセッサ４（図４及び図６）は、一つ以上の集約データ項目（例えば２４）を使用して、上で例示されたように、一つ以上のルールの結果を評価する評価器としてもプログラムされる。テキスト情報生成器４は、上記の例では、例えば、ルールの結論に従って、レポート３３用のテキスト情報を生成する。
【０１４０】
このように、プロセッサ４（図４及び図６）は、
（ａ）一つ以上の集約データ項目２４を個々のデータ項目８を用いてポピュレートする集約データ項目ポピュレータ、
（ｂ）集約データ項目２４に適用された一つ以上のルールの結論を評価する評価器、及び
（ｃ）集約データ項目２４を使用して、（例えば、テキストレポートとして、又は一つ以上の機械命令として）テキスト情報２６を生成するテキスト情報生成器
の一つ以上として機能することが可能である。
【０１４１】
プロセッサ４（図４及び図６）は、各データ項目８を検査してから集約データ項目２４に含めてもよいことが分かる。（図４及び図６に示されるような）テキストを生成するシステムの典型的な実施形態は、概説された機能を並列的又は直列的に実行する二つ以上のプロセッサ４を含んでいてもよいことも分かるだろう。
【０１４２】
上で概説された例示では、名称「非常に高い食品アレルゲン」を有する（図４及び図６でラベル２４を付された）集約データ項目の一つの概念表現は、
ミルク，２５
大豆，３０
となる。
【０１４３】
テキスト情報生成器４（図４及び図６）は、集約データ項目２６をポピュレートするデータ項目８に関連付けられた名称又はラベルをテキスト情報２６に含めるように構成してもよい。例えば、プロセッサ４に、
「非常に高い食品アレルゲン」に対して非常に高い結果が見出された
というテキスト情報を形成するように求めてもよい（例えば、図５に示される方法の工程５０４において）。
【０１４４】
同じ例を続けると、テキスト情報生成器４として機能するプロセッサ４は、
大豆及びミルクに対して非常に高い結果が見出された
というテキストを表すテキスト情報を生成することができる。
【０１４５】
テキスト情報生成器（プロセッサ）４は、大豆がミルクよりも高い値を有しており、したがって、このテキストを提示する最良の方法は、大豆が上位となるようにテキスト内において名称又はラベルを順序付けることであると決定する。また、生成器４は、この集約データ項目２４内には二つの項目しか存在しないので、「大豆」と「ミルク」の間に「及び」を配置すべきであると決定する。値が２６の蜂蜜など、集約データ項目２４内に第３の項目が存在する場合、生成すべき文法的に正しいテキストの一つが、
大豆、蜂蜜及びミルクに対して非常に高い結果が見出された
であると生成器４が決定できるようにする機械命令を生成器４は含んでいる。
【０１４６】
テキスト情報生成器４は、必要な場合は、集約データ項目２４をポピュレートするデータ項目８に関連付けられた値をテキスト情報２６内に含めるように構成される。例えば、上記のテキストは、代わりに、
大豆（３０）、蜂蜜（２６）及びミルク（２５）に対して非常に高い結果が見出された
であってもよい。
【０１４７】
上記のものは、一つの一般的に要求される順序付けの例であるが、異なる状況では他の順序付けがあってもよい。
【０１４８】
別のそのような例は、委託医師向けの患者検査レポートを生成するために、研究所の病理学者が、患者の血液サンプルを分析した診断機器で使用された、例えば数百ものタンパク質バイオマーカーの結果を解釈しなければならないことがある場合である。そのような解釈を可能にするために、テキストを生成するシステムは、バイオマーカー結果を複数のサブグループに整理するが、その各々は、何らかの診断上の意味を有する、より上位のマーカーと考えることができる。例えば、バイオマーカーの一つのグループは、白血病の特定のＢＣＣ型の有無を検査してもよいし、別のグループは、白血病の特定のＡＭＬ型の有無を検査してもよい。
【０１４９】
これにより、テキストを生成するシステムは、各サブグループにおけるバイオマーカー結果の全てから単一の結果を導出することによって、例えば、ＢＣＣグループのマーカーを組み合わせた結果を表す単一の値と、ＡＭＬグループのマーカーを組み合わせた結果を表す単一の値を導出することによって、データ複雑性を低減する。こうなれば、患者の血液サンプルの結果は、研究所の病理学者による解釈に適することになり、病理学者は、遙かに少数だが上位のマーカーを検討しさえすればよい。
【０１５０】
解釈プロセスの簡略化に加えて、テキスト生成システムによって生成されて病理学者により委託医師に提供されるレポートは、個々のマーカー値ではなくマーカーのグループに対応する結果値を使用することによって簡略化される。マーカーのグループの観点から書かれたレポートは、より簡潔であり、個々のマーカー値自体の値変化に起因する変動をあまり受けない。
【０１５１】
マーカーをグループ化する利点は、全てのルールが個々のマーカー値を参照する必要がある場合とは異なり、エキスパートシステムが人間の専門家の解釈プロセス及びグループ値の推論に従うことができるようになるので、はるかに少数のルールしか必要とせずにエキスパートシステムを構築できることである。同様に、多様なレポートを、特定のマーカー値ではなく、マーカーのグループ及びそれらのグループ値の観点から書くことができるので、それらのレポートを、人間の専門家による定義を必要とする遙かに少数のレポート種類を用いて、依然としてエキスパートシステムによって生成することができる。
【０１５２】
一つのデータ項目を履歴的に（時間ベースで）眺める必要性から多数のデータ項目値が生じることもある。
【０１５３】
例えば、心筋酵素の結果値、例えばトロポニンを監視する病理学者は、緊急対応チームに警報を出すかどうかを評価するために、過去数週間にわたる以前の全ての結果に照らして現在の結果を解釈することが必要になる可能性がある。データ量及び複雑性は、この時系列の変化率を表し、そのため、現在値に対する時系列全体の重要な特徴を要約した、新しい上位（高レベル）の結果を提供することによって低減される。その場合、病理学者は、この上位の傾向の結果に照らして、現在の結果の意義を解釈することができる。
【０１５４】
幾つかの実施形態では、生成されるテキスト情報は、人間が読める形式のテキスト情報（すなわち、構文法的及び／又は文法的に正しいテキスト）を生成せず、代わりに、一つ以上の機械命令の形式を取るテキストを生成する。この場合、システムは、機械命令生成器を含む。機械命令は、ワークフローを制御することができる。例えば、アレルゲンが検出されなかったことを検査結果が示す場合、人間の評価者によるレポートのチェックを行わずに、機械命令は、システムに自動的にレポートを送らせることができる。この他に、機械命令は、レポートが生成される前に、保有サンプルに対する追加検査を実施させてもよいし、或いはその追加検査が実施されるように命令してもよい。
【０１５５】
別の実施形態では、システム１、３（図４及び図６）は、テキストレポート又は他の出力を受け取る受信機３６を含むことができる。図８を参照すると、テキストを生成する方法の他の実施形態は、ユーザ３８が、ＣＰＵに接続されたキーボード又は他の入力デバイスによって、テキストの概念表現を入力することを可能にする工程（工程８０２）を含む。概念表現は、システムによって不揮発性メモリ２内に保存される。「概念表現（ｃｏｎｃｅｐｔｕａｌ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）」は、原データ項目、又は集約データ項目を含む派生属性（派生データ項目）の観点からのルール条件の表現である。上記の例を使用すると、オペレータによって入力される概念表現は、
「非常に高い食品アレルゲン」に対して非常に高い結果が見出された
という「疑似テキスト」の形式を取る。
【０１５６】
この例の疑似テキストは、照合される個々の検査結果の分析に基づいた、結論／決定のコンパクトで形式張らない記述である。疑似テキストは、オペレータによって望まれる、テキストの高レベル記述を表すが、重要なこととして、システム１、３が計算するように意図された詳細を省略する。疑似テキストは、コンピュータ処理の詳細についての自然言語記述である。疑似テキストは、プログラミング言語又はスクリプト言語を使用して達成できる所望のテキストについてのより技術的な記述よりも、作成すること及び読むことが人間にとって容易である。
【０１５７】
概念表現は、解釈部分を含む。このケースでは、解釈部分は
「非常に高い食品アレルゲン」
である。
【０１５８】
解釈部分は、名称「非常に高い食品アレルゲン」を有する集約データ項目に対する操作を表す。図８（工程８０２）を参照すると、テキストを生成する方法８００の一実施形態では、システム１、３において、ユーザ３８は、解釈部分を含む疑似テキストとして、テキストの概念表現を入力する。データ項目８を受け取ると、テキスト情報生成器４は、本文書の他の箇所で説明されるように、その解釈部分からテキスト情報２６を生成する（図８の工程８０４を参照）。テキスト情報生成器４は、データ項目の各々に関連付けられた一つ以上の名称又はラベルをテキスト情報２６に含めるように構成される。テキスト情報生成器４は、複数のデータ項目のための集団名（識別子）をテキスト情報２６に含めるように更に構成されてもよい。テキスト情報生成器４は、テキスト情報２６をテキストの概念表現のリテラル部分（逐語的部分）と統合するように更に構成されてもよい。この例示では、
大豆、蜂蜜及びミルクに対して非常に高い結果が見出された
となる。
【０１５９】
図４及び図６に示される実施形態では、テキスト情報生成器４は、集約データ項目２４の特性を決定するように構成される。例えば、テキスト情報生成器４は、
（ａ）集約データ項目を構成するデータ項目の数を決定すること
（ｂ）集約データ項目が空であるかどうかを決定すること
（ｃ）集約データ項目が特定のデータ項目を含むかどうかを決定すること
のうちの一つ以上を含むように構成してもよい。
【０１６０】
これらは、テキストを生成する方法及びシステムの実施形態において集約データ項目に施す操作の例である。例えば、テキスト情報２６は、
（非常に高い食品アレルゲンの数）個の食品アレルゲンに対して非常に高い結果が見出された
などの疑似テキストから生成されて（図８の工程８０４）、
３個の食品アレルゲンに対して非常に高い結果が見出された
となる。
【０１６１】
このように、テキスト情報生成器４は、集約データ項目の決定された特性についての情報をテキスト情報２６に含めるように構成される。「Ｎｕｍｂｅｒ ｏｆ」（「の数」）は、集約データ項目「非常に高い食品アレルゲン」に対して行われる操作の一種である。
【０１６２】
集約データポピュレータ４（図４及び図６）は、集約データ項目２４を一つ以上の他の集約データ項目を用いてポピュレートするように構成してもよい。前者の集約データ項目は、関連のある複数のデータ項目、例えば患者が高いアレルギーを示すことが見出された全ての食品を含んでいてもよい。したがって、集約データ項目「食品」は、それもまた集約データ項目（例えば、ピーナッツ、ツリーナッツ。ツリーナッツもまた、アーモンド、ブラジルナッツ、クルミ、ヘーゼルナッツ、マカダミア、ピスタチオ、ピーカン、及びカシューナッツ等のデータ項目を包含していてもよい）であるデータ項目（例えば、ナッツ）を用いてポピュレートされてもよい。
【０１６３】
集約データポピュレータ４は、集約データ項目に関連付けられた集約データ項目名（識別子）をテキストに含めるように構成されてもよい。集約データポピュレータ４は、テキスト内における集約データ項目２４の名称の順序を決定するように構成されてもよい。一実施形態では、集約データ項目ポピュレータ４は、二つ以上の他の集約データ項目２４に演算を施すように構成される。例えば、一つの集約データ項目２４は、非常に高い結果の食品アレルゲンであってもよく、他の集約データ項目２４は、関心のある食品アレルゲンであってもよい。その場合、ポピュレータ４は、二つの集約データ項目の積集合を取ることによって、新しい集約データ項目２４、例えば、非常に高い結果の関心のある食品アレルゲンを生成してもよい。他の可能な演算子には、差（ｄｉｆｆｅｒｅｎｃｅ）、和（ｕｎｉｏｎ）、及び積（ｉｎｔｅｒｓｅｃｔｉｏｎ）が含まれる。別の実施形態では、集約データ項目ポピュレータ４は、別の集約データ項目を構成するどのデータ項目が特定の範囲内の値を有するかを決定するように構成される。
【０１６４】
一実施形態では、テキスト情報２６を生成する工程は、集約データ項目２４の決定された特性についての情報をテキスト情報２６に含める工程を含む。例えば、決定された特性が、集約データ項目を構成する項目の最大値である場合、テキスト情報は、「最も高い花粉アレルゲンは、結果＜最も高い花粉アレルゲンの値＞ｍｍｏｌ／Ｌを有する＜最も高い花粉アレルゲン＞であった」との文を含んでもよく、ここで、＜最も高い花粉アレルゲン＞は、最も高い値を有する花粉アレルゲンと定義された花粉アレルゲン集約データ項目の特性であり、＜最も高い花粉アレルゲンの値＞は、値それ自体である。
【０１６５】
幾つかの実施形態では、テキスト情報生成器４は、プログラムフローを制御するために、集約データ項目２４に一つ以上のルールを適用するように構成される（例えば、図７の工程７０２参照）。そのようなルールに関連付けられる論理検査の一例は、
Ｉｆ 適度な食品の数＞１ ＡＮＤ ｉｆ 症状の数＞１ ＡＮＤ 非常に高い食品の数＋食品の数＝０
である。
【０１６６】
このようなルールに関連付けられるワークフロー動作は、病理学者へのレポートを自動的に委託医師に開示するのではなく、検査結果及びレポートを検討のための待ち行列に入れることであってもよい。
【０１６７】
集約データ項目は、ルールを構成するブール条件の評価において使用される場合、テキスト情報２６を生成するためのデータ項目として扱えることが分かる。集約データ項目２４へのポピュレートには、一つ以上の他の集約データ項目を用いて集約データ項目２４をポピュレートすることが含まれていてもよく、他の集約データ項目の各々は、名称又はラベルの形式を取る関連集約識別子を有していてもよい。集約データ項目へのポピュレート（例えば、図５の工程５０２）は、二つ以上の別の集約データ項目を組み合わせることによって（例えば、和又は積演算）、又は別の集約データ項目を構成するどのデータ項目が特定の範囲内の値を有するか（例えば、範囲［２０〜５０］内の花粉項目）を決定するなど、より汎用的な条件を適用することによって達成することができる。
【０１６８】
その場合、集約識別子（名称又はラベル）は、データ項目名をテキスト情報２６内で使用する場合とちょうど同じようにテキスト情報２６内で使用することができる。ここでも、テキスト情報２６内における集約名の順序をテキスト情報生成器４が決定してもよい。
【０１６９】
システム及び方法の幾つかの実施形態は、知識ベース（ナレッジベース）による解釈に先立ってデータ複雑性を低減する、新しい又は改良されたデータ前処理方法を含み、この方法は、
（ａ）個々のデータ項目をデータの一つ以上のサブセット（部分集合）にグループ化する工程（各サブセットグループは、集約データ項目と呼ばれる）、
（ｂ）統計値（例えば、最大値、最小値、グループサイズ、中間値、平均値、最頻値、又は他の任意の統計値）、又は各集約データ項目についての他の数値、ブール値、若しくはテキスト値（以下、「集約」値）を計算する工程、
（ｃ）集約データ項目の集まりに施される指定された演算（例えば、和や積）を更に実行して、他の集約データ項目を生成する工程（例えば、各々が特定の癌マーカーの集まりを表す集約データ項目「ＢＣＬＬ診断」、「ＡＭＬ診断」、「ＢＣＬＬ支持」、「ＡＭＬ支持」の和集合が、全ての白血病癌マーカーから成る別の集約データ項目「白血病」を表してもよい）、
（ｄ）自由形式テキストからなる値を有するデータ項目から一つ以上のデータ項目及び値を生成する工程、及び／又は、
（ｅ）一連の値に関連付けられたデータ項目から一つ以上のデータ項目及び値を生成する工程
を含む。
【０１７０】
これにより、データ前処理方法の一つの態様は、個々のデータ項目及びそれらの値の集まりを検討し、そして、グループ化、フィルタリング、マッピング、相関付け、又は他の処理により、各々が値を有する派生属性（Ｄｅｒｉｖｅｄ Ａｔｔｒｉｂｕｔｅｓ）（集約データ項目を含む）を生成することによって、このデータの複雑性を低減する。
【０１７１】
データ前処理方法の別の態様は、データ項目の複雑な自由形式テキスト値を検討し、ストリングパターンマッチング及びフィルタリングの処理により、各々が値を有する、他のより単純なデータ項目を生成することによって、複雑性を低減する。
【０１７２】
データ前処理方法の別の態様は、一連の値に関連付けられたデータ項目を検討し、フィルタリング、傾向分析（ｔｒｅｎｄ ａｎａｌｙｓｉｓ）、又は他の分析により、各々が値を有する、他のより単純なデータ項目を生成することによって、複雑性を低減する。この方法は、一組の原データ項目における各個別データ値又は自由形式テキスト若しくはシーケンスである複雑なデータ項目値を検討することを必要とする代わりに、単一の派生データ項目及びその値の検討も可能にする。ここで、「派生」データ項目及びその値は、前処理によって構成されたデータ項目及び値を指し、「集約」データ項目を含む。これは、解釈する必要があるデータ値の量及び複雑性を著しく低減させ、したがって、（生成されるテキストレポートにおいて後で表現される）判断又は結論に達するために必要とされるルール及び決定点の数も著しく低減する。集約データ項目及びそれらの値は、知識ベースの出力として使用することもでき、得られるレポートテキストの複雑性を大きく低減する。
【０１７３】
他の実施形態では、テキストを生成するシステム及び方法は、様々な形式で提示されるデータを解釈する手段を更に含む。自由テキストデータ項目の解釈を可能にする自由テキスト解析手段も、このデータ解釈手段に含まれる。自由テキスト解析手段は、自由テキストデータ項目を前処理する方法を実行し、その方法は、テキストデータ内の「正規表現」を、以下のグループ
（ａ）長大な自由テキストデータ項目を解釈することを必要とする代わりに、データ項目の著しく単純な「標準的（ｃａｎｏｎｉｃａｌ）」表現を検討することを可能にする一連のキーワード
のうちの一つ以上にマッピングする工程と、
（ｂ）複雑なテキストデータ項目を多数のより単純な「原子的」データ項目に割り当てる工程であって、各原子的データ項目の値が、
ｉ．ブール値（例えば、真又は偽、はい又はいいえ）、
ｉｉ．有限の列挙（「ａ」、「ｂ」、「ｃ」）、又は
ｉｉｉ．数値
のうちの一つである、工程と
を含む。
【０１７４】
本明細書で説明されるような複雑なデータ項目の前処理のための新しい又は改良された方法を提供することによって、好ましい実施形態は、従来のエキスパートシステムの制約の少なくとも幾つかを克服し、大量の複雑なデータ（異なるソースから取得され、自由形式テキストを含む様々な形式で提示される数値データ及びテキストデータを含む）の解釈を可能にする。好ましい実施形態は、複雑なデータを知識又は判断（解釈されたデータに基づいた結論、結果、又は他の発見を含む）に変換する。知識又は判断は、テキストレポート内でテキスト情報（機械命令を含む）として表現される。
【０１７５】
データ前処理方法は、フィルタリング、グループ化、マッピング、及び他の操作によって、データ複雑性を扱いやすい程度まで低減する。例えば、解釈すべき数百のタンパク質バイオマーカー検査値が存在する場合、フィルタリング操作は、特定の患者に関連しないある種の結果を除外してもよい。この方法は、一つ以上のデータ項目を取り、ある式を適用して、それらの（一つ以上の）データ項目を処理し、派生属性にする工程も含む。派生属性は、より扱いやすい。というのも、派生属性は、原データ項目からより上位（高レベル）でより重要な情報を抽出し、したがって、解釈すべきデータを減少させて、扱いやすくするからである。データ前処理方法は、関連する複数のデータ項目を一つ以上のデータサブセットにグループ化するグループ化操作を含む。ここで、各サブセットグループは、集約データ項目と呼ばれる。現在の例を続けると、グループ化操作は、関連バイオマーカーの特定のサブセットの値を収集し、各サブセットについて、例えば最大値などの統計値を計算することができる。そのため、テキストを生成する方法及びシステムは、個々のバイオマーカーを解釈しなければならない代わりに、各グループについて単一のデータ値を検討しさえすればよく、検討すべきデータ値の数を著しく低減する。
【０１７６】
ある患者のテキスト病歴又は他のテキストデータなど、特定のデータ項目が複雑な場合、マッピング操作が、テキスト内のパターン（「正規表現」）を探し、これらのパターンを一連のキーワードにマッピングすることができる。そのため、テキストを生成する方法及びシステムは、長大な自由テキストデータ項目を解釈しなければならない代わりに、このテキスト項目の著しく単純な「標準的」表現を考えさえすればよい。病歴の多数のバリエーションが、同じ単純な標準的表現をもたらすことがあり、やはり、著しく少数のルール及び決定点を使用して解釈を行うことを可能にする、より容易な解釈を可能にする。
【０１７７】
マッピングの別の例は、テキストのパターンをキーワードに割り当てる代わりに、複雑なテキストデータ項目を、多数のより単純な「原子的」データ項目、すなわち、各原子的データ項目の値がブール値（「真」（ｔｒｕｅ）若しくは「偽」（ｆａｌｓｅ）、はい若しくはいいえ）、有限な列挙（「ａ」、「ｂ」、「ｃ」）、又は数値であるデータ項目に割り当てる。複雑な病歴から割り当てられる原子的データ項目の一例は、「真」又は「偽」の値を有する「糖尿病ステータス」と呼ばれるデータ項目であってもよい。別の例は、列挙値「ビグアニド」、「メグリチニド」、又は「スルホニル尿素」を有する「糖尿病薬」と呼ばれるデータ項目であってもよい。このようにして、病歴内に含まれる選択された重要な概念が抽出され、別の標準的な方式で表現される。
【０１７８】
これらの全ての例では、複雑なデータが、解釈を容易にするために、より単純なデータ項目へと前処理される。
【０１７９】
本発明の一実施形態では、集約データポピュレータ装置又はツール（例えば、データベース構造）が、複数のデータ項目を受け取る。ここで、各データ項目は、例えば、複数の検査のうちの一つの結果に対応する。この例示では、複数の検査の結果は、
（ａ）患者の状態の調査（例えば、患者が特定の形態の疾病又はアレルギーを有するか）
（ｂ）大量のデータの監査（例えば、航空券を再発行すべきかどうかを判断する場合に必要とされるもの）、又は
（ｃ）情報を抽出し、或いは決定に到達するために、大量の複雑なデータ項目（テキストレポート内の列挙データ及び数値データを含む）を解析する必要がある基本的に任意の解析
において使用される。
【０１８０】
図５及びタンパク質バイオマーカー検査の例を参照すると、複数のタンパク質バイオマーカー検査の検査値は、複数のサブセットデータグループ（集約データ項目）にグループ化される。言い換えると、各集約データ項目は、個々のタンパク質バイオマーカー検査値の集まりからポピュレートされる（工程５０２）。
【０１８１】
テキスト生成用システムのこの実施形態では、装置（集約データ項目ポピュレータ）は、様々な種類のデータ項目を（一つ以上の）適切な集約データ項目に関連付ける所定のデータ構造の形式での情報を含む。このデータ構造は、装置が、受け取ったデータを処理する様々なルールを適用することによって、受け取ったデータ項目の一つ以上を用いて所定の集約データ項目をポピュレートすることを可能にする。言い換えると、集約データ項目ポピュレータは、個々のデータ項目を関連する集約データ項目にマッピングすることによって、関連する集約データ項目をポピュレートする。「集約データ項目ポピュレータ」は、個々のデータ項目をどのようにマッピングすべきかを決定する一組のルールを含む。個々のデータ項目（プライマリ属性及び派生属性を含む）は、名称、種類、値によって、又は別の集合のメンバーシップによって、一つの集約データ項目にマッピングされる。言い換えると、集約データ項目は、集合メンバーシップに従って、個々のデータ項目を用いてポピュレートされる。現在の例では、集約データ項目のうちの一つにおける各データ項目は、例えば、特定の疾病又はアレルギーについての関連するバイオマーカーである。航空運賃表の例を使用すると、集約データ項目のうちの一つにおける各データ項目は、例えば、チケット再発行のための関連する条件とすることができる。
【０１８２】
他の実施形態（図９の工程９０２参照）では、データを前処理する工程は、自由形式テキストで表現されたデータを抽出する方法（本書において後でより詳細に説明する。工程９０２）を含む。この部分の議論のため、テキストを生成するシステム及び方法の一実施形態は、自由形式テキストを含む様々な手法で表現されたデータをテキスト要約器属性（ｔｅｘｔ ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ）を使用して抽出する手段を含む。そのようにして抽出されたデータ項目は、その後、他のデータ項目（例えば、システムによって受け取られた、個々の検査結果に関係する数値データ項目や、レポート／記録データの個々の項目、例えばクレジットカード有効期限や航空券発券日）と同様の方法で処理される。
【０１８３】
図７の工程７０２を参照すると、その後、追加の集約データ項目に、その集約データ項目に作用する他のルールによってデータを供給してもよい。追加の集約データ項目は、例えば、有意な値を有するデータ項目を含んでいてもよい。その場合、追加のルールが、追加の集約データ項目に適用される。ルールの一例は、追加の集約データ項目内の重要なデータ項目の数が閾値を超えたかどうかを判断することを含んでいてもよい。ルールの結果は、肯定的な検査結果を示してもよく、その場合、肯定的な又は他の検査結果を報告する適切なテキストが生成される。テキストは、集約データ項目を使用することにより、ケースごとにルールを必要とすることなく、柔軟にケースバイケースで生成してよい。
【０１８４】
図９を参照すると、自由形式テキストで表現されたデータ（例えば、臨床メモ、航空運賃表、不動産広告）を含むデータを異なるソースから抽出する工程（工程９０２）を含む、テキストを生成する方法の他の実施形態９００が示されている。この方法は、様々な手法で表現された関連する情報を含む自由テキストのブロックの解析を可能にする。自由テキストから抽出された情報（例えば、数値データ又は他の情報）が他のデータとともに解析され、結論又は判断に至る（工程９０４）。例えば、臨床メモは、自由テキストで表現された重要な情報を含んでいてもよく、また、病理学検査及び人口統計データと併せて解釈されなければならない。
【０１８５】
航空券発券環境では、自由テキストを解釈する必要性から生じる問題を解決しようとする発明者らの最初の試みは、「テキスト正規化属性」（Ｔｅｘｔ Ｎｏｒｍａｌｉｓａｔｉｏｎ Ａｔｔｒｉｂｕｔｅ：ＴＮＡ）と呼ばれる派生属性を生成することを含んでいた。ＴＮＡは、自由テキストを一連のキータームに変換する。「キーターム（Ｋｅｙ Ｔｅｒｍ）」は、自由テキストの断片を表す固有コードである。キータームは、可変の要素、例えば通貨値を含んでいてもよい。自由テキスト断片の幾つかの別形が単一のキータームにマッピングされてもよい。自由テキストから一連のキータームへのマッピングは、その自由テキストの標準的表現を提供する。
【０１８６】
ＴＮＡは、各キータームを、その多数の形態に従って、すなわち、そのキータームの別フレーズによって定義することを可能にした。派生属性の出力は、自由テキストから抽出されたキータームから成る、「凝縮された」又は「正規化された」テキストの文字列であった。図１は、典型的なテキストブロックと、ＴＮＡによって定義されたその「正規形」を表示するユーザインタフェースを示している。ＴＮＡは、図２に示されるように、本質的には、正規表現のキーワードへのマップである。
【０１８７】
関連するキータームは表として列挙され、キーワードごとに、マッチする正規表現のリストが存在した。次に、生テキストが、現在の検索位置から（位置的に）最も近いマッチを検索することによって、トークンのリストに変換された。ここでは、同じ位置から開始する複数のマッチは、マッチ長さによって選択される。ビルトインマッチャ（ｂｕｉｌｔ−ｉｎ ｍａｔｃｈｅｒ）は、「ＡＵＤ ７５」などの通貨値を、可変要素を有するキータームと考えることのできる特別な金銭値トークンに変換する。
【０１８８】
正規化されたテキストが、（一つ以上の）所望の値、例えば、取引の金銭値（７５）及び通貨の「値」（ＡＵＤ）を抽出するために解析された。発明者らによって行われた実験において所望の値を抽出するのに使用された構文法（シンタックス）は、テキスト正規表現パターンマッチングアルゴリズムを使用する独自仕様のリップルダウン条件言語における構文法であった。図３は、正規化テキストから通貨及び値を抽出するために使用された埋め込み変数を有するコメントの二つの例を表示するユーザインタフェース画面を示している。
【０１８９】
ＴＮＡは、知識ベースを構築することによって試されたが、その知識ベースでは、コメントは、所定の理由で航空券を再発行する費用を与える可変表現であった。ほとんど全ての場合において、
金額＝ＮｏｒｍＣａｔにおいて｛「ＣＸ ＢＴ ＦＯＲ ＭＶ＄」にマッチするコードにおける金額｝通貨＝｛ＮｏｒｍＣａｔにおいて「ＣＸ ＢＴ ＦＯＲ ＭＶ＄」にマッチするコードにおける通貨｝
のようなコメントを追加するための条件は、
ＮｏｒｍＣａｔがコードシーケンス「ＣＸ ＢＴ ＦＯＲ ＭＶ＄」を含む
であった。
【０１９０】
本質的には、同じマッチングシーケンスが３回、すなわち、可変コメントにおいて２回、それを追加するための条件において１回、書かれなければならなかった。
【０１９１】
このテキスト正規化プロセスを使用して、発明者らは、例えばオーストラリアなど一つの国で調査した運賃表のほとんどをうまく解析する知識ベースを構築することができたが、最も複雑な運賃表からデータを抽出するには、いくらかの機能強化が必要であった。しかし、別の国の運賃表のために新しいキーワード又はキータームを追加する必要があった場合は特に、知識ベースを維持することが困難であることを意味する問題が存在した。類似の問題は、他の状況でも、例えば、ある患者の検査結果の解釈に２人以上の臨床医からの臨床メモを含める必要がある場合にも生じた。
【０１９２】
ＴＮＡに伴う問題は、以下のように説明することができる。
【０１９３】
Ａ．抽出情報の変更に対する感度
ＴＮＡに新しいキーワードを追加した結果、コメント内の変数及びルール内の条件が、もはや意図したようには評価されない可能性があった。例えば、運賃表が、テキスト
．．．ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ ＢＵＴ ＷＩＴＨＩＮ ２４ ＨＯＵＲＳ ＯＦ ＳＣＨＥＤＵＬＥＤ ＦＬＩＧＨＴ ＴＩＭＥ ＣＨＡＲＧＥ ＡＵＤ ７５ ＦＯＲ ＣＡＮＣＥＬＬＡＴＩＯＮ．．．（出発前であって予定出発時刻の２４時間以内の場合、キャンセルには７５オーストラリアドルを請求します）
を含んでいたと仮定する。
【０１９４】
このテキストは、キーワード「ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ」、「ＣＡＮＣＥＬＬＡＴＩＯＮ」、及び「ＦＯＲ」を含む。これらのキーワードは、図２に列挙されたキータームの同義語（別形又は正規代替表現）である。ＴＮＡは、正規表現を、関連するキーワードにマッピングする。
【０１９５】
ＴＮＡが、「ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ」を「ＢＴ」で、「ＦＯＲ」を「ＦＯＲ」で、「ＣＡＮＣＥＬＬＡＴＩＯＮ」を「ＣＸ」で置き換え、加えて金銭値（ｍｏｎｅｔａｒｙ ｖａｌｕｅｓ）のビルトインマッチも置き換えた場合、正規化テキスト（すなわち、凝縮されたテキストの文字列である、派生属性の出力）は、
ＢＴ ＭＶ＜ＡＵＤ，７５＞ ＦＯＲ ＣＸ
となる。
【０１９６】
この正規化テキストは、条件
コードシーケンス「ＢＴ ＭＶ＄ ＦＯＲ ＣＸ」を含む
を満たす。
【０１９７】
ここで、語句「ＷＩＴＨＩＮ ２４ ＨＯＵＲＳ ＯＦ ＳＣＨＥＤＵＬＥＤ ＦＬＩＧＨＴ ＴＩＭＥ」（予定出発時刻の２４時間以内）が重要であり、捕捉する必要があると我々が決めた場合、我々はこれのための新しいキーワード、例えば「Ｗ２４ＨＦＴ」を追加しなければならない。我々の正規化テキストは、今度は、
ＢＴ Ｗ２４ＨＦＴ ＭＶ＜ＡＵＤ，７５＞ ＦＯＲ ＣＸ
となる。
【０１９８】
しかし、新しい正規化テキストは、コードシーケンス内に「Ｗ２４ＨＦＴ」が存在するので、もはや元の条件を満たさない。すなわち、新しいキータームの追加は、意図していたものとは異なる評価をＴＮＡに容易に行わせうる。
【０１９９】
キータームがテキスト正規化処理から除去される場合にも、全く同じ問題が生じる。
【０２００】
Ｂ．コメント及び条件の冗長性
上記の例で概説したように、正規化テキストから値及び通貨を抽出するために、同じマッチングシーケンスを３回使用しなければならなかった。これは、処理時間、並びにコメント及び条件を作成するのにユーザが必要とする時間の面で非効率的であり、最終的には、知識ベースの保守を必要以上に困難にした。
【０２０１】
Ｃ．キーワード名変更に対する感度
例えば、「ＢＴ」から「Ｂｅｆｏｒｅ Ｔｒａｖｅｌ」（出発前）にキーワードを変更すると決定した場合、やはり、このキーワードを使用していた変数及び条件は、もはや当てはまらなくなる。これは問題Ａに類似しているが、キーワード名変更は表面的な変更であるので、より容易に回避される。一方、新しいキーワードの追加又は既存のキーワードの削除は、テキスト正規化プロセスにとってより根本的な変更である。
【０２０２】
このように、自由形式テキスト内のデータを前処理する問題を解決しようとするこれまでの試みは、変更されたキーワードに対処できない欠点と、コメント及び条件を定義する際の非効率性に悩まされていた。この制約は、上で概説された航空券発券の例及びログファイルの例の状況において問題に対処しようと試みる際に見つかった。
【０２０３】
今からＩＴサポートサービスの例を取り上げて、以下のログファイル断片について検討する。
【０２０４】
【数１】
【０２０５】
ＴＮＡを使用するテキスト正規化処理は、これらのログエントリをフィルタリングして、
ＰＭ ＤＣ
に縮小する。ここで、第１のログエントリは「ＰＭ」と、第３のものは「ＤＣ」（ＷＡＲＮＩＮＧ Ｃｏｕｌｄ ｎｏｔ ｄｉｓｃｏｎｎｅｃｔ ｃｌｉｅｎｔ（警告はクライアントを切断しない））と符号化され、第２及び第４の（情報提供用の）エントリは無視される。
【０２０６】
偽陽性の（すなわち有意ではない）ＤＣ警報を示すルールは、条件
コードシーケンス「ＰＭ ＤＣ」を含む
を使用してもよい。
【０２０７】
しかし、ここで、ＴＮＡが、バックアップ（ＢＣＫ）イベントなど、新しい項目を含むように変更された場合、得られる正規化テキストは、
ＰＭ ＢＣＫ ＤＣ
となる。
【０２０８】
すると、ＤＣ警報が偽陽性であったことを示す条件は、もはや正しく評価されない。
【０２０９】
したがって、先の航空券発券の例で説明したものと同じＴＮＡの制約が、ここでも当てはまる。
【０２１０】
図９の実施形態は、キーターム（Ｋｅｙ Ｔｅｒｍｓ）とキーコンセプト（Ｋｅｙ Ｃｏｎｃｅｐｔｓ）の双方を組み込んだ新しいツール（「テキスト要約器属性（Ｔｅｘｔ Ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ）」又はＴＣＡとして知られる）を提供する。キータームとキーコンセプトの双方を単一のツールにまとめることによって、キーワードの追加又は削除によって引き起こされる問題は克服される。また、キーワードは、タームとコンセプトの両方で共有されるオブジェクトなので、集約データ項目に適用（例えば、図７の工程７０２）されるルールに影響を及ぼすことなく、名称を変更することができる。更に、ツールは、派生属性自体としてのキーコンセプトの抽出を含んでいるので、条件及び変数を反復する必要はあまりない。
【０２１１】
図１０は、あるＴＣＡの例示のユーザインタフェースを示している。「属性（Ａｔｔｒｉｂｕｔｅ）」又は「プライマリ属性（Ｐｒｉｍａｒｙ Ａｔｔｒｉｂｕｔｅ）」は、ルール条件又は他の表現の基本要素の一つである。各属性は、名称と、関連付けられた一つの値、又は場合によっては一連の値（時系列の複数の値がその属性に関連付けられる場合など）を有する。属性は、ルール条件のデータ値要素、例えば、単一のアレルゲンマーカーなどの下位（低レベル）のデータ項目や、花粉項目などのより上位（高レベル）の集約データ項目を表す。ルール条件の他の要素は、算術演算子やテキスト演算子や論理演算子、あるいはブール式を形成するために属性とその値を関連付けるその他の表現である。例えば、ルール条件「幾つかの花粉が高い」は属性「花粉」（集約データ項目）と、論理表現「幾つかのＸが高い」を含み、ここでは、変数「Ｘ」が花粉という値で置き換えられている。
【０２１２】
「ケース」は、解釈のためにエキスパートシステムに提示される、属性とその値の集まりである。プリプロセッサは、複雑なケース、すなわち、多数の属性、大量の自由形式テキストデータを伴う属性、又はデータ項目の長いシーケンスを伴う属性を有するケースを取り、集約データ項目（より上位の属性、又は「派生」属性）をケースに追加することによって、そのケースの複雑性を低減させ、ケースをルール条件及び解釈レポート内で、より容易に、かつより汎用的に使用できるようにする。
【０２１３】
テキスト要約器属性（ＴＣＡ）は、このような派生属性である。テキスト要約器属性は、一組のキーワード（又は「キーターム」）を、一組のキーコンセプト又は「派生マッチ（Ｄｅｒｉｖｅｄ Ｍａｔｃｈｅｓ）」とともに定義する（図１１参照）。各キーコンセプト又は派生マッチは、
（ａ）ターゲット（実際には、知識ベース又はエキスパートシステムにおける別の派生属性である）
（ｂ）抽出式（マッチした形式について派生属性の値を定める）
（ｃ）「照合用形式（Ｍａｔｃｈｉｎｇ Ｆｏｒｍｓ）」のリスト（照合用形式は、一連のキーターム（キータームのシーケンス）である）
から成る。
【０２１４】
本実施形態は、以下のようにして、テキストのブロック上でＴＣＡの評価を実行する。すなわち、
（ａ）テキストが一連のキーワード（キーワードのシーケンス）に正規化される。
（ｂ）正規化テキストが派生マッチの各々によって解析されて、キーコンセプトに値を提供する。各派生マッチについて、マッチする複数の照合用形式（もしあれば）のうち最長のものが取り上げられる。これは、文献において、「貪欲（ｇｒｅｅｄｙ）」パターンマッチとして知られている。
（ｃ）一つの照合用形式がマッチを見出した各派生マッチについて、その関連する派生マッチのための所定の式が適用され、これが、そのキーコンセプトに対応する派生属性のための属性値になる。
【０２１５】
関連する式の全てが「＄（１）」である航空運賃表を解析する例について検討する。これは、システム１、３（図４及び図６参照）によって、「照合したテキスト内で見出された最初の金銭値トークンを返す」として解釈される。後で別の抽出式を見る。
【０２１６】
上記のプロセスは、ケース内で参照された属性（例えば、上記のチケット再発行の例における「カテゴリ」）のためのサンプルシーケンス内のサンプルの全てにわたって適用することができる。「サンプルシーケンス」は、任意の属性用の複数の値からなる、順序付けられ、刻時されたリストである。サンプルシーケンス内の各値は、日付及び時間に関連付けられる。このようにして、ＴＣＡは、ＴＣＡのための、また付随する派生属性の各々のためのサンプルシーケンスを生成する。少なくとも一つの非空白値を含むサンプルシーケンスが、ケースに導入される。図１２は、属性「カテゴリ」（Ｃａｔｅｇｏｒｙ）のための値を有する例示的なケースを示しており、その場合、ＴＣＡのための値は、「ＴＣＡ」と呼ばれ、派生属性のための値は、「ＣｘＢｔ」、「ＣｘＡｔ」、「ＲｉＯｂ１」、及び「ＲｉＲｔｃ」と呼ばれる。
【０２１７】
ＴＣＡの使用は、先に説明したＴＮＡの使用に伴う問題を
（ａ）キーワードを安全に追加及び削除することを可能にし、
（ｂ）コメント及び条件内における冗長性を低減させ、
（ｃ）キーワードの名称変更（リネーム）を可能にする
ことによって解消する。
【０２１８】
Ａ．キーワードを安全に追加及び削除できる
派生マッチ（すなわちキーコンセプト）における照合用形式を定義する際、ユーザは、幾らかの例示の生テキストが各照合用形式に付随するように、照合されるべき生テキストの例を提供するように促される（図１３参照）。ユーザが提供する例は、照合用形式へのマッチを与えるものでなければならない。ユーザが、正規化された例がもはや照合用形式にマッチしないように（例えば、キーワードを追加することによって）キーワードに変更を加えた場合、ユーザは、（例えば、異なる色で示された派生マッチによって、又はユーザに警告を与える他の何らかの手段によって）これについて警告を受ける。
【０２１９】
例えば、照合（マッチング）用のフレーズ「−」を有するキーワード「−」がキーワードの組に追加された場合、図１５に示されるように、派生マッチは、不具合にみまわれる。派生マッチを回復させるには、新しいキーワードを削除する必要があり、又は照合用形式の幾つかを、それらの例の正規化バージョンにマッチするように、変更する必要がある。
【０２２０】
このように、派生マッチにおける例は、そのキーコンセプトの定義のための背景（コンテキスト）を提供する点で、リップルダウン知識ベースにおけるコーナーストーンケース（ｃｏｒｎｅｒｓｔｏｎｅ ｃａｓｅ）に似ている。
【０２２１】
Ｂ．コメント及び条件の、より小さな冗長性
ＴＣＡの派生属性は、コメント及び条件内の変数において直接使用することができる。これらの条件は、ケース内における派生属性の存在をまさに主張し、例えば、
ＣｘＢｔが利用可能
は、図１６に示されるコメントを追加するために使用することができた。
【０２２２】
Ｃ．キーワードの名称変更が可能
キーワードの名称はキーワードと派生マッチ内の照合用形式とによって共有されるオブジェクト参照にすぎないので、キーワードと一緒に派生マッチをＴＣＡに含めることにより、システムは、キーワードの名称変更に対して耐性を持つことになる。そのため、例えば、キーワード「ＢＴ」を「ＢｅｆｏｒｅＴｒａｖｅｌ」に名称変更した場合、我々の照合用形式は、図１７に示されるように、自動的に更新される。
【０２２３】
ＴＣＡの他の利点
異なる抽出式
派生マッチの図示の例は、運賃表の正規化テキストからの金銭値の抽出を示している。運賃表などの自由形式テキストから抽出する必要がある他の追加的な種類の情報が存在してもよい。（航空券発券シナリオにおける）例は、
（ａ）キーフレーズ（キーとなる語句）が発生したかどうか、及び／又は
（ｂ）日付
を含む。
【０２２４】
航空券発券の例を続けると、照合用形式が一つ以上の日付（これらは、金銭値と同様に、キーワードとして自動的に現れる）を含む場合、式「＠（ｉ）」を使用して第ｉの日付を抽出することができる。キーフレーズを扱うため、我々は、式「？」を使用して、マッチが存在する場合に派生属性が値「真」（Ｔｒｕｅ）を取るべきであることを示す。これらの式の双方を使用する（すなわち、日付とブール値を抽出する）ＴＣＡの例が、図１８に示されている。図１９は、派生属性のためのこれらのブール値及び日付値がこの例示的なケースにおいてどのように現れるかを示している。
【０２２５】
ツールのヒント（Ｔｏｏｌｔｉｐｓ）
ユーザは、ケース内に派生属性及びその値を見た場合、それがなぜそこにあるのかよく分からないことがある。すなわち、それが生テキストのどの部分を表すのかよく分からないことがある。この点を補助するため、ある実施形態では、派生属性及びその照合値を生じさせた生テキストを、（図２０に例示されるように）ツールのヒントとして提供する。
【０２２６】
幾つかのレポートセクション（各々が任意選択的な見出しを有する）から成る長大なレポートでは、これらのレポートセクションが提示される順序は、エンドユーザ（例えば、医師、発行チケットを検査する航空会社、不動産専門家又は買い手／売り手）にとって重要な要素である。すなわち、エンドユーザは、最も重要なレポートセクションをレポートの先頭近くで見ることを望む。しかし、一つのレポートセクションを別のセクションよりも重要にするものは、解釈される特定のケースに依存する。したがって、各ケース内のデータに作用するルールを使用して、指定されたレポートセクションを順序付けることは有益である。他の幾つかのレポートセクション、例えば、常にレポートの先頭にある要約レポートセクションは、その配置が固定されなければならない。したがって、ユーザは、固定及び可変のレポートセクション順序付けの双方を混合して定義できるようになっていてもよい。
【０２２７】
アレルギーの報告は、可変レポートセクション順序付けが必要とされる可能性のある分野である。花粉（ｐｏｌｌｅｎ）、食品（ｆｏｏｄ）、ダニ（ｍｉｔｅ）、カビ（ｍｏｕｌｄ）、及び動物（ａｎｉｍａｌ）アレルゲン検査結果についてのコメントに対応して、少なくとも５つの別個のレポートセクションが存在する。与えられた患者について食品アレルギー検査結果が最も重要である場合、食品レポートセクションが他の４つの前にくるべきである、などというようになる。最も重要ではない検査結果に対応するレポートセクションは、他のものの後に配置されるべきである。更に、固定のレポートセクション、すなわち、レポートの先頭に位置する要約レポートセクション、及び通常はレポートの末尾に位置する勧告レポートセクションもある。
【０２２８】
結果として、システムは、所望のレポートセクション順序付けに対応する値を割り当てるルール構文法（シンタックス）を使用して、各可変レポートセクションのための「派生属性」を定義する手段をオペレータ３８に提供する。上記のアレルギーの例では、例えば、「ｐｏｌｌｅｎ＿ｏｒｄｅｒ」、「ｆｏｏｄ＿ｏｒｄｅｒ」、「ｍｉｔｅ＿ｏｒｄｅｒ」、「ｍｏｕｌｄ＿ｏｒｄｅｒ」、及び「ａｎｉｍａｌ＿ｏｒｄｅｒ」の５つの派生属性が存在する。ｐｏｌｌｅｎ＿ｏｒｄｅｒは、全ての花粉データ項目のうちで最も高い値と定義され、他のものについても同様である。派生属性「ｐｏｌｌｅｎ＿ｏｒｄｅｒ」は、花粉レポートセクションに関連付けられる。各ケースについて、５つの派生属性の値が計算され、対応するレポートセクションが、これらの値に従って順序付けられる。例えば、ケースが、下記のデータ項目及び値
芝＝５０，カバノキ＝２０，（花粉）
小麦＝５，大豆＝１５，（食品）
カビ＝２
ダニ＝１
猫＝６２，犬＝４９（動物）
というデータ項目及び値を有する場合、レポートセクションは以下の順序
動物、花粉、食品、カビ、ダニ
となる。
【０２２９】
幾つかの実施形態では、システムは、以下のうちの少なくとも一つを提供してもよい。すなわち、
・必要とされる非常に大きな知識ベースを管理する基礎技術としてのリップルダウン（ＲｉｐｐｌｅＤｏｗｎ）ルールシステム
・知識ベースからの符号化出力を使用して、自動検証（ａｕｔｏｖａｌｉｄａｔｉｏｎ）及び反射型試験（ｒｅｆｌｅｘｉｖｅ ｔｅｓｔｉｎｇ）等の研究所ワークフローを例えば制御するワークフローエンジンを制御するなどの機械語命令である符号化情報を生成する機構
・ルール条件を構築するための自然言語構文法（シンタックス）
・解釈される特定のケースによって評価されるコメントへの変数の挿入。変数は、集約データ項目を使用して定義されてもよい。
【０２３０】
推論
人間の専門家と同様に、エキスパートシステムは、ルールが適用できる可能性もできない可能性もある大きなデータ集合ではなくルールが適用できる特徴を有するデータにルールを適用することができる形式へと、複雑なデータを縮小する必要がある。したがって、ルールベースのシステムは、関連ルールを選択するプログラムを必要とする。例えば、提示された（一つ以上の）ケースの属性に一致する条件をどのルールが有するかを決定するプログラムを必要とする。
【０２３１】
推論エンジン（ｉｎｆｅｒｅｎｃｅ ｅｎｇｉｎｅ）は、そのようなプログラムであり、適切なルールをケースに適用し、したがって、ルールを使用して「判断」などの結果を推論するタスクを実行する。
【０２３２】
この推論はしばしば、幾つかの環境において適切なルールに基づいている。しかし、他の環境では、ルールは変更される必要がある。したがって、知識ベースのルールの継続的な反復が存在する。解釈のために提示されたケースへの一つ以上のルールの適用可能性は、結果の解釈の正確性を決定する。
【０２３３】
知識ベースによって生成された解釈の検査及び可能な訂正が、一組の「拒否された」ケースを決定する。これらは、元の解釈を容認する、知識ベースを保守する専門家に提示され、又はさもなければ、訂正された解釈が知識ベースによって以降のケースに与えられるように、新しいルールを生成する。
【０２３４】
人間の専門家と同様に、ルールベースのエキスパートシステムは、関連する重要な特徴から推論が可能になるように、これらの特徴に関してエキスパートシステムに提示されるデータを有する必要がある。複雑な生データから推論した場合、必要とされる特定のルールの数が管理できない程度となるばかりでなく、ルールが構築された後でも、提示された複雑なデータ内で新たに遭遇するどのようなバリエーションも解釈することができない。データ内のより一般化された特徴からの推論は、解釈プロセス自体をより一般に適用可能なものとし、そのため、より頑強（ロバスト）にする。
【０２３５】
高トランザクション環境では、エキスパートシステムは、人間の専門知識を利用して生データの迅速な解釈を提供する際に、極めて重要な役割を果たすことが可能である。例えば、病理学研究所は、その研究所で雇用できる僅かな人数の病理学者の人的能力をはるかに超えた、１日当たり数万人の患者についての解釈レポートを提供する必要に迫られる場合がある。
【０２３６】
マルチレベル推論
マルチレベル推論は、解釈プロセスにおいて、より上位の抽象概念（上位概念と呼ばれる）を連続的に生成するプロセスである。
【０２３７】
より上位の抽象概念
推論プロセスにおいて後で他のルールによって使用される、より上位の抽象概念を提供するために、中間結論が使用される。中間結論自体は、最終的な解釈に出現しないが、最終的な解釈を決定するために使用されるルールに影響を及ぼす。
【０２３８】
好ましい実施形態では、
１．属性レベル、及び
２．ルールレベル
においてマルチレベル推論の二つの段階が存在する。
【０２３９】
属性レベルでのマルチレベル推論
属性は、ある式又は表現（例えば、算術式、ブール式、集合メンバーシップ演算）に従って、他の属性の点から定義されてもよい。
【０２４０】
これらは、オンライン情報システムから受け取った属性である「プライマリ」属性とは対照的に、「派生」属性と呼ばれる。
【０２４１】
例えば、知識ベースの仕事は、全ての疑わしいトランザクションに人間の専門家向けのフラグを付けて更なる検討ができるようにし、疑わしくないトランザクションにはフラグを付けないことである。疑わしくないトランザクションにフラグを付けたのでは、人間の専門家の時間を浪費するからである。
【０２４２】
知識ベースによって解析されるトランザクションの例には、以下の三つのトランザクション（取引）が含まれる。
【０２４３】
【表２】
【０２４４】
あるケースにおけるこれらの金融取引でのプライマリ属性は、「会社」、「国」、「金額」、及び「以前のフラグ」から構成されていてもよい。
【０２４５】
派生属性は、得られるルールをより汎用的かつより保守可能なものにする抽象概念として定義される。例えば、以下の派生属性が定義される。
１．「石油産業」。これは、取引が石油産業の会社を含む場合に真となる。Ｂａｘｘｏｎは、石油会社の組に属する一つである。
２．「非条約国」。これは、取引が、特定の国際条約の加盟国ではない特定の一組の国々に関連する場合に真となる。Ｕｇｉｎｔａ及びＴｉｇｅｒｉａは、この組に含まれる。
３．「ボーダライン金額」。これは、取引が、それが自動的に監視下に入るように最小値に近い場合に真となる。この例の場合、９５００ドルと９９９９ドルの間の金額は、ボーダラインと考えられる。
４．「以前のボーダライン数」。これは、過去１週間以内にボーダライン内にあった取引の数の総計である。
【０２４６】
これらの派生属性がマルチレベル推論プロセスによって評価されると、このケースは、以下のようになる。
【０２４７】
【表３】
【０２４８】
この例におけるこのマルチレベル推論は、全ての属性を定めるために、二つの推論解析を必要とする。
１．第１の解析は、属性「石油産業」、「非条約国」及び「ボーダライン金額」を決定できるようにする。これに続いて、
２．第２の解析は、属性「以前のボーダライン数」を計算できるようにする。
【０２４９】
マルチレベル推論の他の例は、（参照により本明細書に組み込まれる）オーストラリア特許出願第２０１０９０４５４５号において、本発明の出願人及び発明者らによって提供されている。
【０２５０】
属性レベルでのマルチレベル推論の適用を使用する派生属性は、単一の式又は表現に関して指定され、そのため、決定できるのは、プライマリ属性のみから導出できる派生属性に限られる。
【０２５１】
ルールレベルでのマルチレベル推論
より上位の抽象化は、
１．（上で示されたような）プライマリ属性から抽出される派生属性、及び
２．ルールベースによって抽出される知識ベースの結論
によって可能になる。
【０２５２】
ルールベース推論の第１のレベルでは、結論は、属性（プライマリ若しくは派生属性又はその両方）の点から定義された一つ以上のルールによって与えられる。
【０２５３】
第２のレベルでは、第１レベルの結論をルール条件内に組み込んだルールを使用して結論を与えてもよい。
【０２５４】
このルールレベルでのマルチレベル推論は、その後、必要に応じて、第３及びそれ以降のレベルに適用してもよい。
【０２５５】
上記の金融例では、ユーザは、ルール条件
・「ボーダライン金額」が真かどうか
・「非条約国」が真かどうか
・「以前のボーダライン数」が２以上であるかどうか
を使用して、第１レベルの結論を「疑わしい取引」と定めてもよい。このケースでは、これらの条件は全て真である。
【０２５６】
「疑わしい取引」が、単なる別の派生属性ではなく結論として定められる理由は、この「疑わしい取引」が、単一の式又は表現を用いて定められるものよりも複雑な概念であるからである。
【０２５７】
例えば、「疑わしい取引」を示す全く異なるシナリオが多数存在する可能性がある。各シナリオは、異なる一組のルール条件によって指定され、そのいずれもが、結論「疑わしい取引」を与える。
【０２５８】
逆に、「疑わしい取引」シナリオに非常に類似して見えるが、それを疑わしくないとする僅かな相違があるケースが存在する可能性もある。
【０２５９】
ユーザは、ここで、ルール条件
・「疑わしい取引」、及び
・「以前のフラグなし」
を使用して、第２レベルの結論「要検査」を定めてもよい。
【０２６０】
ここでも、これらの条件は、このケースについてはともに真である。結論「以前のフラグなし」は、すでにフラグが付けられた取引についてのフラグ付けを回避し、それによって取引の重複した検査を回避するために含まれており、その目的は、ここでも、人間の専門家の時間を浪費しないためである。
【０２６１】
ユーザは、「説明」と呼ばれる第３のレベルの結論も定義することができる。この結論は、「＜金額＞のこの取引は疑わしい。会社＜会社＞からの過去ボーダライン取引が先週＜以前のボーダライン数＞回あり、現在の取引は非条約国＜国＞からのものであるため。」という値を有する。この結論を与えるルール条件は、単に「要検査」である。
【０２６２】
この結論の目的は、なぜこのケースが知識ベースによって検査のためにフラグを付けられたのかについて、テキストの説明を人間の検査者に提供することである。コメント内の変数（＜＞記号によって示される）は、このケースにおける特定の属性値から評価される。
【０２６３】
ユーザは、ルール条件
「要検査」、及び
「石油会社」
を使用して、値「石油取引」を有する「待ち行列」と呼ばれる第３のレベルの結論も定めることができる。この結論の目的は、特定の種類の取引（このケースでは、石油会社による取引）に経験を有する専門家によって検査を受ける特定の待ち行列にこのケースを送ることである。
【０２６４】
これらの結論がマルチレベル推論プロセスによって評価されると、このケース及びそのルールベースの解釈は、以下のようになる。
【０２６５】
【表４】
【０２６６】
全ての属性が定められた後は、これらの全ての結論を定めるために、三つの推論パスが必要とされる。
【０２６７】
第１のパスでは、結論「疑わしい取引」が与えられる。第２のパスでは、「要検査」が与えられる。第３のパスでは、「待ち行列」及び「説明」が与えられる。
【０２６８】
リップルダウンルール（ＲｉｐｐｌｅＤｏｗｎ Ｒｕｌｅｓ）方法論を利用する知識ベースにルールレベルでのマルチレベル推論を適用することで、「疑わしい取引」のような概念を、疑わしい取引を示す全てのシナリオを考慮し、しかも疑わしい取引を示さない全てのシナリオを除外した上で、結論として定めることが可能になる。これは、マルチレベル推論だけを使用して一つ以上の派生属性によって提供されるものよりも広い視野を与える。
【０２６９】
マルチレベル推論は、その専門家分野にとって適切な抽象化レベルにある概念を用いて知識ベースを定義することを可能にする。
【０２７０】
属性レベルでは、マルチレベル推論は、オンライン情報システムから受け取った多かれ少なかれ恣意的な一組のプライマリ属性を、その分野に特有で適切な概念を表す派生属性へと前処理することを可能にする。
【０２７１】
属性レベルにおける前処理は、例えば、自由テキストの大きなブロックから概念を抽出することによって、又は多数の関連する属性をより上位の属性にフィルタリング及びグループ化することによって、データ複雑性を低減することもできる。
【０２７２】
結論レベルでは、マルチレベル推論は、人間の専門家がこの分野を理解して特定のシナリオの解釈を正当化するときに通常使用するであろう概念を表すように上位の抽象概念を定めることを可能にする。
【０２７３】
結論を定めるためにリップルダウン（ＲｉｐｐｌｅＤｏｗｎ）方法論を使用することは、これら上位の抽象概念が時間とともに精緻化されて、きわめて複雑な可能性のある概念の自然表現ばかりでなく、非常に正確で明快な表現をも提供できることを意味する。
【０２７４】
リップルダウンの組み込みコーナストーンケース検証手順（別途説明する）と結び付く、ケースの分野特有の適切な抽象概念の集合を用いることで、これらの抽象概念によって大規模で洗練された有用な知識ベースを構築及び保守するという専門家の仕事が実現可能になる。
【０２７５】
例１
第１の適用例は、数百のタンパク質発現マーカー又は遺伝子発現マーカーのマイクロアレイによってその値が決定される数百の検査を用いて診断が実行される白血病レポート知識ベースである。専門家は、関連するマーカーからなる複数のサブセット（部分集合）、このパターンに対応する診断、及び委託医師向けのテキストレポートに記載するそれら有意なサブセットについてのコメントを特定する診断レポート知識ベースを構築してもよい。
【０２７６】
アレイ検査結果は、知識ベースへの入力として、複数のデータ項目及び値ペアとして提供される。この例では、これらのデータ項目には、識別のためにＣＤ１〜ＣＤ１００のラベルが付される。これらのラベルは、アレイに対する１００個の要素を表している。現実世界の例は、数百のマーカーを含むことがある。
【０２７７】
この例では、データ値のうちの一つの値が５０未満であることは、その患者のサンプルについては、そのマーカーに対応する抗体の発現がないことを意味する。５０よりも大きな値は、（他のマーカーの値によっては）有意である可能性がある。１００よりも高いマーカーの値は、有意な発現を示す。
【０２７８】
特定の様々な白血病の診断は、１００個のデータ値の指定されたサブセットの値から推定することができる。
【０２７９】
例えば、Ｂ細胞慢性リンパ性白血病（Ｂ−ＣＬＬ）の診断は、ＣＤ１、ＣＤ２、ＣＤ３、ＣＤ４及びＣＤ５のうちの少なくとも二つが有意な発現を示すことから推定することができる。この診断は、ＣＤ６、ＣＤ７、ＣＤ８、ＣＤ９及びＣＤ１０のうちのいずれかが有意な発現を示すことによって支持されるが、これらは、それ自体でＢＣＬＬを診断するものではない。
【０２８０】
この他に、急性骨髄性白血病（ＡＭＬ）の診断は、ＣＤ１１、ＣＤ１２、ＣＤ１３、ＣＤ１４及びＣＤ１５のうちの少なくとも二つが有意な発現を示すことから推定することができる。この診断は、ＣＤ１６、ＣＤ１７、ＣＤ１８、ＣＤ１９及びＣＤ２０のうちのいずれかが有意な発現を示すことによって支持されるが、これらは、それ自体でＡＭＬを診断するものではない。
【０２８１】
５つの集約データ項目には、受け取ったデータ項目を用いて、下記の構造例によって指定されるようにデータが供給される。
１．「ＢＣＬＬ診断」は、データ項目ＣＤ１、ＣＤ２、ＣＤ３、ＣＤ４、ＣＤ５によってポピュレートされる。
２．「ＢＣＬＬ支持」は、データ項目ＣＤ６、ＣＤ７、ＣＤ８、ＣＤ９、ＣＤ１０によってポピュレートされる。
３．「ＡＭＬ診断」は、データ項目ＣＤ１１、ＣＤ１２、ＣＤ１３、ＣＤ１４、ＣＤ１５によってポピュレートされる。
４．「ＡＭＬ支持」は、データ項目ＣＤ１６、ＣＤ１７、ＣＤ１８、ＣＤ１９、ＣＤ２０によってポピュレートされる。
５．「白血病」は、集約データ項目「ＢＣＬＬ診断」、「ＡＭＬ診断」、「ＢＣＬＬ支持」、「ＡＭＬ支持」によってポピュレートされる。
【０２８２】
これらのデータ項目と１５個の集約データ項目の階層関係を与える構造の一態様の概略が、図２１に示されている。幾つかの実施形態では、構造の下位の階層がポピュレートされると、上位の階層における値又は特性が計算される。構造は、デバイス１のメモリ２０やハードドライブ２（又は他のデータ記憶ユニット）等に保存されて、ＣＰＵ４によって解釈されてもよい。
【０２８３】
以下の範囲
（ａ）定数５０と定義される「無検出」、及び
（ｂ）定数１００と定義される「高」
も定義してもよい。
【０２８４】
各セット内の有意なデータ項目を表すために、以下のルール
１．「有意なＢＣＬＬ診断」。これは、ルール「範囲［＞高］におけるＢＣＬＬ診断」によってポピュレートされる。
２．「有意なＢＣＬＬ支持」。これは、ルール「範囲［＞無検出］におけるＢＣＬＬ診断」によってポピュレートされる。
３．「有意なＡＭＬ診断」。これは、ルール「範囲［＞高］におけるＡＭＬ診断」によってポピュレートされる。
４．「有意なＡＭＬ支持」。これは、ルール「範囲［＞無検出］におけるＡＭＬ診断」によってポピュレートされる。
を適用することによって、さらなる集約データ項目がポピュレートされる。
【０２８５】
ＢＣＬＬ診断コメントは、以下の疑似テキスト
「＜有意なＢＣＬＬ診断＞にてＰａｎ−Ｂ細胞抗原発現、＜有意なＢＣＬＬ支持＞にて共発現、Ｂ細胞慢性リンパ性白血病（Ｂ−ＣＬＬ）に典型的。」
によって与えられる。
【０２８６】
変数「＜有意なＢＣＬＬ診断＞」は、有意なＢＣＬＬのデータ項目の名称と値を列挙するための指示であり、変数＜有意なＢＣＬＬ支持＞についても同様である。この実施形態では、列挙される名称と値は、最も有意な属性が最初に列挙されるように、データ項目値の降順で順序付けられる。
【０２８７】
ＢＣＬＬ診断ルールは、ＢＣＬＬ診断コメントの生成を
「有意なＢＣＬＬ診断の数≧２」、且つ
「有意なＢＣＬＬ支持の数≧１」
のようにトリガする。
【０２８８】
すなわち、コメントは、集合「有意なＢＣＬＬ診断」内に二つ以上のデータ項目が存在し、且つ、集合「有意なＢＣＬＬ支持」内に一つ以上のデータ項目が存在する場合に生成される。
【０２８９】
第２のコメント例として、ＡＭＬ診断コメントは、以下の疑似テキスト
「陽性の＜有意なＡＭＬ診断、名称として＞に基づいてＡＭＬ抗原発現と合致、＜有意なＡＭＬ支持、名称として＞にて共発現。Ｍ２分類の可能性が疑われる。」
によって与えられる。
【０２９０】
データ項目「＜有意なＡＭＬ診断、名称として＞」は、有意なＡＭＬのデータ項目の名称のみを列挙するための知識ベースに対する指示であり、変数＜有意なＡＭＬ支持、名称として＞についても同様である。
【０２９１】
この実施形態では、列挙される名称と値は、値がコメントに示されないとしても、最も有意なデータ項目が最初に列挙されるように、データ項目値の降順で順序付けられる。
【０２９２】
ＡＭＬコメントの生成をトリガするＡＭＬ診断ルールは、
「有意なＡＭＬ診断の数≧２」、且つ
「有意なＡＭＬ支持の数≧１」
であってもよい。
【０２９３】
コメントは、集合「有意なＡＭＬ診断」内に二つ以上のデータ項目が存在する場合に生成される。これは要するに、集合「ＡＭＬ診断」内に１００より大きい値を有するデータ項目が二つ以上存在し、集合「ＡＭＬ支持」内に５０より大きい値を有するデータ項目が少なくとも一つ存在することを意味する。以下のような患者「Ａ」からのサンプルの検査結果について検討する。
【０２９４】
【表５】
これらの結果は、知識ベースの一実施形態に送られる。この知識ベースは、集約データ項目を
・有意なＢＣＬＬ診断は、「ＣＤ５、ＣＤ３及びＣＤ４」と評価
・有意なＢＣＬＬ支持は、「ＣＤ７及びＣＤ８」と評価
・有意なＡＭＬ診断及び有意なＡＭＬ支持は、双方ともヌル（空）と評価
のように評価し、発現を評価する。
【０２９５】
その後、知識ベースは、上述のように定められたルールに従って解釈を行う。「有意なＢＣＬＬ診断」集合内には三つの要素が存在し、「有意なＢＣＬＬ支持」集合内には二つの要素が存在するので、このケースではＢＣＬＬルールが適用可能である。
【０２９６】
知識ベースは、ＢＣＬＬコメント「＜有意なＢＣＬＬ診断＞」及び「＜有意なＢＣＬＬ支持＞」内の変数を評価し、次いで、評価済みのコメント
「ＣＤ５（２６０）、ＣＤ３（１９０）及びＣＤ４（１５０）にてＰａｎ−Ｂ細胞抗原発現、ＣＤ７（９０）及びＣＤ８（６０）にて共発現、Ｂ細胞慢性リンパ性白血病（Ｂ−ＣＬＬ）に典型的。」
を与える。
【０２９７】
第２の例のために、以下のような患者「Ｂ」の検査結果について検討する。
【０２９８】
【表６】
【０２９９】
これらの結果は、知識ベースに送られる。知識ベースは、最初、集約データ項目を
・有意なＢＣＬＬ診断及び有意なＢＣＬＬ支持は、双方ともヌル（空）と評価
・有意なＡＭＬ診断は、「ＣＤ１２及びＣＤ１１」と評価
・有意なＡＭＬ支持は、「ＣＤ１９、ＣＤ２０及びＣＤ１８」と評価
のように評価する。
【０３００】
その後、知識ベースは、上記のルールに従って解釈を行う。「有意なＡＭＬ診断」集合内には二つの要素が存在し、「有意なＡＭＬ支持」集合内には三つの要素が存在するので、このケースではＡＭＬルールが適用可能である。
【０３０１】
その後、知識ベースは、コメント
「陽性のＣＤ１２及びＣＤ１１に基づいてＡＭＬ抗原発現と合致、ＣＤ１９、ＣＤ２０及びＣＤ１８にて共発現。Ｍ２分類の可能性が疑われる。」
を与える。
【０３０２】
例２
別の適用例は、実行可能なＩｇＥ検査が５００以上となる可能性があるアレルギーレポート知識ベースである。アレルギー専門家の仕事は、実行した検査のどのサブセット（部分集合）が患者について有意な結果値を有するか、どの検査値が有意でない可能性があるか、どの検査を追跡調査する必要があるか（可能性のある５００の検査のうちのどれを併せて追跡調査として実行すべきかを含む）について、委託医師に助言を与えることである。
【０３０３】
一つの解決例は、以下の通りである。
【０３０４】
・可能性のあるデータ項目名の全ての集まりから、それらのデータ項目名を、分野に特有のルール（有意花粉属性など）及びケースに特有のルールに基づいて、複数の集約データ項目にグループ化する。
【０３０５】
・集約データ項目の特性のいずれかを、更なるルール及び／又はコメントの基礎として使用する。例えば、ある集約データ項目の要素の数が一定の数を上回った場合、又はその集合が特定の要素を含む場合、特定のコメントを与える。
【０３０６】
・一つ以上の集約データ項目をコメント内の変数として使用する。例えば、「犬、猫及びピーナッツアレルギーが有意である」。このコメントにおいて、フレーズ「犬、猫及びピーナッツ」は、このケースにとって有意なアレルゲンから成る集約データ項目の評価である。このコメントの汎用的な形式は、「｛有意なアレルゲン｝アレルギーが有意である」とすることができ、ここで、集合｛有意なアレルゲン｝自体は、ルールによって定められる。
【０３０７】
・任意で、データ項目の値をコメントに含める。例えば、「犬（１０２．３）、猫（５６．４）及びピーナッツ（４３．５）アレルギーが有意である」。
【０３０８】
・コメント内に出現する集約データ項目内のデータ項目を適切に順序付ける。例えば、コメント内で最も重要な属性が最初に出現するように、その事例における属性値の降順で順序付ける。
【０３０９】
・データ項目を、レポートの残りの部分と整合した自然に構成された文に自動的にフォーマットする。例えば、三つの属性が有意である場合には、その集合のフォーマットを「犬、猫及びピーナッツアレルギー」とし、二つの属性だけが有意である場合には、その集合のフォーマットを「犬及び猫アレルギー」としてもよい。
【０３１０】
・データ項目の以前のグループ化に基づいて、データ項目のグループ化を定義することができるようにする。例えば、新しい集約データ項目は、一つの集合と別の集合の差、和、積、又は任意の集合演算とすることができる。これにより、複数の集合からなる階層構造を定義することが可能になる。例えば、集合「適切な検査」と集合「指示された検査」との差は、まだ指示されていない適切な検査の集合を特定することができる。
【０３１１】
・個々のデータ項目か、それらの属性を含む集約データ項目のいずれかを適宜に使用するコメントを定義できるようにする。例えば、個々のデータ項目のリストがその特定の事例のコメントにとって長すぎる場合、「ピーナッツ、大豆、ミルク、卵及び桃アレルギー」の代わりに、用語「食品アレルギー」を使用する。
【０３１２】
・同様に、サブセット（部分集合）名の代わりにスーパー集約データ項目名を使用するコメントを適宜に定義できるようにする。例えば、個々の集約データ項目のリストがその特定のケースのコメントにとって長すぎる場合、「花粉、動物、カビ、…アレルギー」の代わりに、用語「吸入アレルギー」を使用する。
【０３１３】
疑似テキスト
以下の表は、上述した疑似テキストの特徴の幾つかを定義しており、ここで、ｓ、ｔ、ｘ、ｙ、ｚは、それがプライマリ項目であるか派生データ項目であるかに関わらず、データ項目を指す。
【０３１４】
文字Ｘ、Ｙ、Ｚは、特に、集約データ項目（派生データ項目の一種）を指す。文字ａ、ｂは、数字又は名称付き定数を指す。文字ｐは、ブール式を指す。
【０３１５】
【表７】
【０３１６】
例３
第３の適用例は、航空券運賃表を解釈し、
（ａ）出発都市及び行先都市
（ｂ）どれだけの違約金が適用できるか
など、チケットを再発行できる条件を決定するために使用される知識ベースである。
【０３１７】
第２の知識ベースは、再発行チケットを解釈して、実際に支払われた料金並びに出発都市及び行先都市を決定するために使用される。
【０３１８】
第３の知識ベースは、他の二つの知識ベースの出力を解釈し、再発行チケットが運賃表の条件に従っているかどうかを判断する。
【０３１９】
とりあえず第１の知識ベースについて検討すると、運賃表内の自由形式テキストの断片は、以下のようなものとすることができる。
【０３２０】
【表８】
【０３２１】
この運賃表の断片を前処理するために、テキスト要約器属性（Ｔｅｘｔ Ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ：ＴＣＡ）が使用される。ＴＣＡにおける幾つかのキーワードは、
（ａ）「ＣＡＮＣＥＬＬＡＴＩＯＮ ＦＥＥ」（キャンセル料）及び他の類似の語句を表す「ＣＸ」
（ｂ）「ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ」（出発前）及び他の類似の語句を表す「ＢＴ」
（ｃ）「ＡＵＤ１１０」や「ＡＵＤ７５」のように可変の金額を有する金銭値を表す「＜ＡＵＤ ｎ＞」
である。
【０３２２】
ＴＣＡ内のキーコンセプトは、派生属性「ＣａｎｃｅｌｌａｔｉｏｎＦｅｅＢｅｆｏｒｅＴｒａｖｅｌ」であり、これは、この一連のキーワード「ＣＸ ＢＴ ＜ＡＵＤ Ｎ＞」から導出される可変の金銭値Ｎを有するものと定義される。この例では、属性「ＣａｎｃｅｌｌａｔｉｏｎＦｅｅＢｅｆｏｒｅＴｒａｖｅｌ」は、数値１１０を有する。
【０３２３】
知識ベースは、これ及び他の運賃表条件を、例えば「ＣａｎｃｅｌｌａｔｉｏｎＦｅｅＢｅｆｏｒｅＴｒａｖｅｌ＝１１０」などの標準化形式で、結論として出力するためのルールを有する。これらの標準化形式は、第３の知識ベースに入力され、第３の知識ベースは、再発行チケットについての実際の航行及び支払われた料金を要約する第２の知識ベースの出力と運賃表条件を比較する。その後、第３の知識ベースは、運賃表条件と、再発行チケットの要約された詳細を解釈して、運賃表条件に従って再発行チケットが再発行されたかどうかを判断する。
【０３２４】
例４
第４の適用例は、一連のログファイルエントリを監視し、ＩＴサポートスタッフに警報を送信すべきかどうか、またいつ送信すべきかを決定するために使用される知識ベースである。
【０３２５】
エキスパートシステムは、ログファイルの監視及び解釈を行うＩＴサポートスタッフを支援するときに、基本的な役割を演じることができる。エキスパートシステムは、ＩＴサポートスタッフが重要であると見なす、またＩＴサポートスタッフによる何らかの予防措置又は是正措置が許可されることを示す特定の警報、警告、又は傾向を、この非常に大きな自由形式テキストデータから抽出するのを補助することができる。
【０３２６】
ログファイルを解釈するときのより具体的な困難は、「偽陽性」、すなわち、実際には重要でない警報又は他の警報ほど重要でない警報の問題である。
【０３２７】
例えば、最初の「メモリ不足」警報は有意であるかもしれないが、続いて繰り返される同じ警報は、すでに警告された問題を指しているだけのこともあり（偽陽性）、さもなければ、実際に全く新しい問題であることもある（真陽性）。これら二つの警報の間に長い時間差が存在する場合、第２の警報は、真陽性である可能性がより高い。
【０３２８】
別の例は、高い率のページフォールトに起因する「ディスクスラッシング」警報の場合である。これは重要であるが、場合によっては、より重要な問題の症状にすぎず、その問題とは、メモリ不足状態であるかもしれない。この場合、「ディスクスラッシング」警報より前の「メモリ不足」警報の存在は、第２の警報が、先行する「メモリ不足」警報が存在しない場合ほどには重要でないことを意味する。
【０３２９】
別の例は、「クライアント切断失敗」警報の場合である。１日のほとんどの時間においては、これは、ＩＴサポートスタッフによる即刻の調査を許可する有意な警報である。しかし、警報がログに取られたのが、１日の特定の時間、例えば、毎日の予防保守（ｐｒｅｖｅｎｔａｔｉｖｅ ｍａｉｎｔｅｎａｎｃｅ：ＰＭ）のためにシステムがオフライン状態にあることが知られている午前２時である場合、その警報は有意ではないかもしれない。
【０３３０】
警報の有意性と適切な応答を判断するルールは、警報の種類だけでなく、それらの順序、頻度、互いに対するタイミング、更には絶対的タイムスタンプさえも考慮しなければならない。
【０３３１】
警報の有意性が判断されると、取るべき適切な行動に関する決定を、エキスパートシステムによって行うことができる。したがって、エキスパートシステムがログファイルを解釈するためには、個々のログエントリ又はログエントリのシーケンスを、キーターム又はキーコンセプトのシーケンスに分類するように前処理を行う必要がある。したがって、複雑で本質的には自由形式のテキストログファイルは、正規化された形式に縮小され、その正規化形式から、より単純でより上位の原子的データ項目を抽出し、ルール条件内で使用することができる。
【０３３２】
ユーザ（クライアント）を切断できないことをログエントリが示している場合における潜在的な警報状況の例を示す。しかし、システムが予防保守を開始した後にこの警告が発生した場合は、潜在的な警報は偽陽性と見なされ、ＩＴサポートスタッフに警報は送られない。
【０３３３】
一連のログファイルエントリの以下の例について検討する。
【０３３４】
【数２】
【０３３５】
知識ベースによる解釈の前にこれらのログファイルエントリを前処理するため、我々はＴＣＡを構築する。ＴＣＡ中のキーワードは、
（ａ）「Ｐｒｅｖｅｎｔａｔｉｖｅ Ｍａｉｎｔｅｎａｎｃｅ」（予防保守）及び他の類似の語句を表す「ＰＭ」
（ｂ）「ＷＡＲＮＩＮＧ」（警告）及び他の類似の語句を表す「ＷＡＲＮ」
（ｃ）「Ｃｏｕｌｄ ｎｏｔ ｄｉｓｃｏｎｎｅｃｔ ｃｌｉｅｎｔ」（クライアントを切断できなかった）及び他の類似の語句を表す「ＤＣ」
である。
【０３３６】
これらのログファイルエントリについてのＴＣＡの値は、正規化テキスト形式「ＰＭ ＷＡＲＮ ＤＣ」である。このＴＣＡのキーコンセプトの一つは、派生属性「Ａｌｅｒｔ」（警報）である。これは、正規化テキスト形式が「ＷＡＲＮ」を含む場合（本例でも含む）にブール値「真」を有するように定義される。
【０３３７】
知識ベースは、属性Ａｌｅｒｔの値が「真」である場合にワークフロー動作「Ｓｅｎｄ ａｌｅｒｔ ｅｍａｉｌ」（警報電子メールを送る）を追加するためのルールを有する。このワークフロー動作は、通知先のＩＴサポートスタッフの電子メールアドレスを含み、電子メールヘッダは、警報の要約を提供し、電子メール本文は、警報の詳細を記述する。
【０３３８】
ＴＣＡの別のキーコンセプトは、派生属性「ＦａｌｓｅＰｏｓｉｔｉｖｅ」（擬陽性）である。これは、正規化テキスト形式が「ＰＭ ＷＡＲＮ ＤＣ」を含む（本例でも含む）場合にブール値「真」を有するように定義される。
【０３３９】
知識ベースは、属性ＦａｌｓｅＰｏｓｉｔｉｖｅの値が「真」である場合に、ワークフロー動作「Ｓｅｎｄ ａｌｅｒｔ ｅｍａｉｌ」を削除するための別の後続するルールを有する。
【０３４０】
前処理段階では、これら二つの派生属性Ａｌｅｒｔ及びＦａｌｓｅＰｏｓｉｔｉｖｅがケースに追加され、双方とも値「真」を有する。
【０３４１】
知識ベース推論の段階中、条件「Ａｌｅｒｔ ｉｓ ｔｒｕｅ」（警報が真）を有するルールによって、警報ワークフロー動作が解釈に追加される。しかし、警報ワークフロー動作は、条件「ＦａｌｓｅＰｏｓｉｔｉｖｅ ｉｓ ｔｒｕｅ」（擬陽性が真）を有する後続のルールによって削除され、最終的な結果としては、警報ワークフロー動作は解釈中に存在せず、したがって、ＩＴサポートスタッフに警報電子メールは送信されない。
【０３４２】
ここまで実施形態を説明してきたので、幾つかの実施形態が、以下の利点の幾つかを有しうることが分かるだろう。
【０３４３】
・単一のテキストレポートを生成する目的で、多数のデータ項目（幾つかの実施形態では、自由形式テキストとして提示されるテキスト結果を含む）を処理することが可能である。
【０３４４】
・そのレポートは、各ケースにとって重要なデータ項目を、適切な順序で、言語学的に自然な構文法で提示する。
【０３４５】
・具体的なレポートバリエーションの数は、データ項目の可能なサブセットの数及び各サブセット内で可能な順序付けの数に起因して、本質的に無限である。
【０３４６】
・特定のレポートを決定する具体的なルール条件の数も、ケース中の属性及びそれらの値のパターンの数に起因して、本質的に無限である。
【０３４７】
・それにも関わらず、ルールは前処理段階の結果である派生属性に基づいているので、専門家は、管理可能な数のルールを用いて、知識ベースを構築及び保守することができる。
【０３４８】
・多数の属性及びそれに対応する多数のレポートバリエーションを管理できるエキスパートシステムが提供される。
【０３４９】
具体的な実施形態に示される本発明には、広範に説明されたような本発明の主旨及び範囲から逸脱することなく、多くの変形及び／又は変更をなし得ることが理解されるだろう。したがって、本発明の実施形態は、全ての点において、限定的ではなく、例示的なものと見なされるべきである。
【符号の説明】
【０３５０】
１ システム
２ コンピュータ可読媒体
３ システム
４ 中央プロセッサ
８ データ項目
１０ データ受信機
１１ データ送信機
１２ リモートサイト
１４ ネットワーク
２０ メモリ
２２ データソース
２４ 集約データ項目
２６ テキスト情報
２８ 画面
３０ プリンタ
３２ ワークステーション
３６ 受信機
３７ 情報システム
３８ ユーザ
【技術分野】
【０００１】
本発明は、全体として、テキストを生成する方法及びシステムに関し、特に、構文法的に正しいテキストをレポート用に生成する方法及びシステム（ただし、これに限定されるわけではない）に関する。
【背景技術】
【０００２】
２０世紀半ば以来の、処理速度及びメモリ容量を含むコンピュータ能力の指数関数的な増大が、社会のあらゆる部門における、まさにわれわれの日常生活におけるコンピュータ利用の有用性を劇的に高めた。コンピュータの主要な用途の一つは、ますます量を増大させるデータの生成及び保存である。しかし、生のデータは、それ自体では、限られた価値しか持たない。ほとんどの場合、その真の価値は、生データが誰かによって解釈され、必要な理解と洞察がもたらされたときに、初めて獲得することができる。この解釈プロセスは、「データ」を「知識」に変換し、それをしばしば「判断」に変換する付加価値プロセスである。この知識又は判断は、テキストのレポートでしばしば表現される。
【０００３】
コンピュータ処理されるプロセスは、数値データ及びテキストデータの双方を抽出し、対照し、保存するのに役立つが、このデータを人間又はコンピュータによって効果的に解釈する能力は、大きなデータ量とそれに伴う複雑性によって制限されることがある。
【０００４】
人間の場合、データの本体をタイムリーに正確に解釈するように判断を下す能力には、有意な特徴（ｓｉｇｎｉｆｉｃａｎｔ ｆｅａｔｕｒｅｓ）が明白となるようにデータが前処理され十分に縮小されていることが必要となる。
【０００５】
ルールベースのエキスパートシステムの場合、大きく複雑なデータセットの全ての特殊性を考慮するのに必要とされるルールの増殖を回避するために、各ルールはできるだけ汎用的にするという更なる関連要件が存在する。より汎用的なルールは、データセットからの、より上位の抽象概念（ａｂｓｔｒａｃｔｉｏｎｓ）を使用して構築されるので、基礎をなすデータの詳細のばらつきは、それらのルールを必ずしも無効にしない。これらのより上位の抽象概念は、まさに、ルールベースのエキスパートシステムを構築する人間の専門家が使用する有意な特徴である。
【０００６】
すなわち、人間の専門家とちょうど同じように、エキスパートシステムは、大きな一組の原データ値ではなく、より小さな一組の有意な特徴に基づいて推論を行うことができる形式に複雑なデータが縮小されることを必要とする。
【０００７】
したがって、後続の解釈のために人間又はコンピュータに提示できる、より小さなあまり複雑でない一組の有意な値にデータを前処理することによって、解釈すべきデータのデータ複雑性を低減する方法を見つけることが課題である。
【０００８】
データ複雑性に寄与する主要な要因は二つ存在する。
【０００９】
第１の要因は、解釈する必要があるかもしれないデータ項目値の数そのものであり、すなわち、与えられたシステム内に、分析する必要がある多数の要素が存在する場合である。
【００１０】
例えば、委託医師向けの患者検査レポートを作成するために、研究所の病理学者は、患者の血液サンプルを分析した診断機器で使用された数百ものタンパク質バイオマーカーの結果を解釈しなければならないことがある。
【００１１】
複雑性に拍車をかける第２の要因は、個々のデータ値それ自体のサイズと、おそらくは構造化されていない（「自由形式の」）フォーマットである。単一の数値又は列挙値（すなわちテキストコード）は、それ自体では、例えば３．４ｍｍｏｌ／Ｌのトロポニン値など、この「原子的な」値と、対応するデータ項目とに明らかな関連性が存在するので、解釈が比較的簡単かもしれない。
【００１２】
しかし、大きな自由形式のテキストは、曖昧表現、誤字、略語、二つ以上のデータ値、又は同じデータ値の多くの異なる可能な解釈のうちの一つを含むことがあり、これが解釈をはるかに困難にする。
【００１３】
例えば、委託医師向けの患者検査レポートを作成するために、研究所の病理学者は、委託医師によって提供された患者の長大なテキストの病歴に照らして、機械が生成した検査結果を解釈しなければならないことがある。病歴は、大きな構造化されていないデータ項目なので複雑であり、テキスト内の比較的小さなばらつきが、得られる解釈を完全に変えてしまうことがある。例えば、省略形の語句「ＤＭ」（既知の真性糖尿病（ｄｉａｂｅｔｅｓ ｍｅｌｌｉｔｕｓ））、「ＦＨ ＤＭ」（真性糖尿病の家族歴）、「？ ＤＭ」（糖尿病の疑い）、「ｎｏｔ ＤＭ」（糖尿病ではない）はどれも、与えられた一組のグルコース検査結果についての病理学者の解釈を変化させる。臨床メモ内の同義語（「ＤＭ」、「Ｄｉａｂｅｔｉｃ」（糖尿病の）、「Ｄｉａｂ」（糖尿）、「Ｄｉａｂｅｔｅｓ ｎｏｔｅｄ」（糖尿病注意））、誤記（「Ｄｉａｂｅｔｅｓ Ｍｅｌｌｉｔｉｓ」）、語順の変化（「？ ＤＭ」、「ＤＭ ？」）はどれも、解釈を行うときに、病理学者によって理解される必要があることにも留意されたい。
【００１４】
病歴は、語句「ｏｎ Ｚｏｃｏｒ」（Ｚｏｃｏｒ投与中）又は「ｏｎ ｌｉｐｉｄ ｌｏｗｅｒ ｔｒｅａｔｍｅｎｔ」（脂質低下薬投与中）も含むことがあり、どちらの語句（フレーズ）も、患者が何らかの心臓薬を服用しているかどうかを病理学者に伝える第２の概念を表す。この種の語句も同様に、検査結果についての病理学者の解釈と、委託医師向けに作られるレポートに影響する。
【００１５】
具体例「ＤＭ，ｏｎ Ｚｏｃｏｒ」を見ると、「病歴」データ項目と原子的な値の間に明らかな関連性は存在しない。むしろ、複雑なデータ項目としての病歴は、二つのより単純で原子的なデータ項目、例えば「糖尿病（はい）」と「治療薬投与（はい）」を暗示的に含む。
【００１６】
データ項目値のサイズと構造の欠如とに起因するこの第２のタイプの複雑性の別の例は、第１の所究所が、患者検査の幾つかを「内部的に」実行する一方で、幾つかのより専門的な検査のために血液サンプルを第２の研究所に送付する場合である。第２の研究所は、テキストレポートで検査結果を返送する。第１の研究所の病理学者の観点からは、第２の研究所から受け取ったレポートは、複雑なデータ項目である。病理学者は、委託医師向けの最終レポートを作成するために、このレポートに加えて、第１の研究所で行われた結果も解釈しなければならない。
【００１７】
複雑なデータを伴う臨床分野の別の例は、アレルギー分野である。この分野では、関連する一つ以上のアレルゲンを特定するために、可能性のあるアレルゲンを血液サンプルにおいて検査し、その後、長大かもしれない自由形式の患者病歴における症状と照合する必要がある。他の例としては、伝染病（病原菌の特定）や多臓器疾患（例えば、神経学的、内分泌学的、腫瘍学的な遠因の特定）が挙げられる。
【００１８】
複雑なデータの解釈における同様の困難は、（例えば、航空券、運転免許証、及びパスポートの再発行、クレジットカードでの購入、並びに電子商取引における）不正検出、物流における監査、在庫管理、（例えば、偽造の検出における、若しくは製品リコール目的のための）シリアルナンバー管理、又はＩＴサポートサービスなどの非医療分野でも生じる。
【００１９】
航空会社不正検出の例では、チケットの販売及び乗客のフライトに関する構造化されていない又は半構造化されたデータを含む多数のイベントが記録され、その後、指定された航空券に対して正しい価格が適用されたかどうかを識別するために、価格決定運賃表及び航空券再発行のための他の基準と照合される必要がある。これは面倒な業務である。というのも、運賃表及び航空券に含まれる情報は、構造化されていないか、又は半構造化されているにすぎず、また、各集合は、運賃表に表された条件に実際に従っているかどうかを判断するために、人間の専門家によって個別に解釈されるからである。
【００２０】
人間の専門家による効率的で正確な解釈を可能にするために、（この例では）運賃表の複雑なデータは、特定のチケットに適用可能な一組の条件に縮小される必要がある。そのチケットの関連する特性（出発都市及び行先都市、搭乗日、搭乗クラス、価格）も、抽出される必要がある。運賃表及びチケットのデータが前処理されて、これらの有意な特徴になれば、不正な又は間違った発券イベントが存在するかどうかに関して、人間の専門家が判断を下すことができる。
【００２１】
不動産査定の仕事は、複雑なデータの解釈が必要とされる別の領域である。この分野では、必要とされる解釈は、金額とその根拠となる説明から構成される査定である。解釈がなされるデータは、家屋及び土地の広さ、家屋の向き、付近の郵便番号及び最近の査定、又は他の比較し得る不動産を含む、様々な複雑で異種のデータから成る。不動産の様々な特性（例えば、隣接する高層アパートによって遮られる眺望）を記述した自由形式のテキストメモは、査定に影響する重要な要因を含むことがあり、そのため、解釈を必要とする。
【００２２】
複雑なデータの解釈を必要とする非医療分野の別の例は、ＩＴサポートサービスの分野である。企業が、ニュースフィード又は他のレポートなど、定期的な付加価値出力を契約顧客に提供するオンライントランザクション処理システムを考えてもらいたい。
【００２３】
企業のオンライントランザクション処理システムの信頼性は、このサービスの性能に不可欠である。非常に高い水準の信頼性を達成するには、システムの信頼性に影響し得る全ての要因について、システムを継続的に監視し続けなければならない。
【００２４】
これらの要因は、トランザクションレート、ユーザアクティビティ、メモリ、ディスク、及びＣＰＵなどのリソース利用に加えて、オペレーティングシステムが発生させる警報及び警告、並びにトランザクション処理アプリケーション自体が発生させる警報及び警告を含む。これらの要因を記録する標準的な方法は、ログファイルなどの中央設備に、こうした情報の全てを継続的にログに取ることであり、中央設備では、そのような情報を企業のＩＴサポートスタッフによって定期的に分析することができる。目標は、オンライントランザクションシステムが障害を起こす前に、ログファイルに記録されたあらゆる深刻な警報又は気がかりな傾向にＩＴサポートスタッフが対応することである。
【００２５】
ログエントリは、しばしば異なる製造元製品に属する様々なオペレーティングシステム又はアプリケーションシステムのコンポーネントによって生成されるので、ユニバーサルコーディングシステムによってフォーマットされておらず、基本的に自由テキストである。大規模なオンライントランザクション処理システムの場合、ログファイルは、例えば１日当たり数十メガバイトなど、非常に大きくなることがあり、ＩＴサポートスタッフが人的に検査できる範囲を超えている。更に、あるクラスの警報は、即座の行動を必要とすることがあり、その場合、警報及び対応する修復行動の決定が迅速に確認される必要があるかもしれない。
【００２６】
先の例のように、人間の専門家による効率的で正確な解釈を可能にするには、ログファイル内の複雑なデータは、何らかの修復行動を取る必要があるかどうかに関して人間の専門家が判断を下す際の基礎となる一組の有意な特徴（例えば、警報や傾向の状態条件）へと前処理される必要がある。
【００２７】
コンピュータベースのエキスパートシステムは、人間の解釈プロセスを模倣しようと試みている。例えば、リップルダウン（ＲｉｐｐｌｅＤｏｗｎ）は、米国特許第６５５３３６１号で説明されているように、高度に特有な解釈をどのようにケースバイケースに行うかを分野の専門家によって教え込まれたコンピュータベースのエキスパートシステム（決定エンジン）である。
【００２８】
人間の専門家と同様に、ルールベースのエキスパートシステムは、関連する有意な特徴からシステムが推論を行えるように、それらの特徴に関してデータがシステムに提示されるようにする必要がある。複雑な生データ（例えば、運賃表及びチケット自体におけるデータ）から推論を行うとすれば、必要とされる具体的なルールの数が扱いきれないほどになるばかりでなく、ひとたびルールを構築してしまうと、運賃表やチケットにおいて新たに遭遇するどのようなバリエーションも解釈に失敗することになる。
【００２９】
高トランザクション環境では、エキスパートシステムは、人間の専門技術を高めて生データの迅速な解釈をもたらすうえで重要な役割を果たすことができる。例えば、病理学研究所は、その研究所で雇用できる僅かな人数の病理学者の人的能力をはるかに超えた、１日当たり数万人の患者についての解釈レポートを提供する必要がある可能性がある。
【００３０】
しかし、データを解釈するエキスパートシステムの能力は、人間の専門家を制限するのと同じ要因、すなわち、データ複雑性によって制限される。複雑なデータは、人間の専門家が使用するよりも上位の概念を使用してルールを構築できるような形式に前処理して、そうでなければ生じるであろうルール及びレポート定義の増殖を回避する必要がある。
【００３１】
以下では、データ複雑性問題のより詳細で具体的な二つの例を提示する。
【００３２】
第１のより具体的な例は、内科病理学の分野におけるものである。この分野では、病理医などの専門家によって通常は実行される複雑な調査が、しばしば多数の検査を必要とする。検査結果の解釈は、しばしば困難であり、専門家又はエキスパートシステムの技量を必要とする。専門家又はエキスパートシステムは、検査結果の有益な分析及び解釈を時には高度に要約された形式で含むレポート内に含まれるテキストを生成し、そのレポートは、生の検査結果自体を解釈するための専門知識をもたない可能性のある委託医師（例えば家庭医）に送られる。これまでは、検査が比較的相互に独立している分野において、エキスパートシステムの知識ベース（ナレッジベース）が構築されてきた。例えば、甲状腺レポート用の知識ベースは、甲状腺機能検査の結果（すなわち、ＴＳＨ、ＦＴ３、及びＦＴ４）を主として考察する。身体検査又は口述された病歴から臨床メモに記録された所見と同様に、年齢及び性別などの他の患者人口統計データも、一般に考慮される必要がある。これらの知識ベースを使用して生成されたレポートは、これらの個々の検査及びそれらの値に言及するのに加えて、診断も提供し、しばしば治療及び追跡検査の推奨も与える。一般に、これらの分野では、検討すべき２０未満の検査に加えて、年齢及び性別などの患者人口統計データと、開業医によって提供される臨床メモ内の所見が存在する。検査結果は相互作用することがあるため、ある程度、関連をもつことがあるが（例えば、一つの検査が異常である場合、別の検査も異常である可能性が高い）、考慮すべき検査及び検査相互作用の数が少なければ、知識ベース内のルールは、個々の検査結果そのものに言及でき、依然としてその一般性を維持できる。すなわち、検査結果が、解釈の前に何らかの前処理工程によって、より小さな一組の有意な特徴に縮小される必要はない。
【００３３】
ある条件下で与えられたテキストコメントから構成される具体的なルールは、各個別検査結果を考慮することによって、又は検査結果の比較的少数の有意な組合せを考慮することによって、書くことができる。例えば、一群の甲状腺検査の場合、ＴＳＨ検査結果が上昇したのであれば、「原発性甲状腺機能低下症と一致する」というコメントが生成されることがある。
【００３４】
上記の甲状腺の例など従来の臨床分野は、少数の属性（Ａｔｔｒｉｂｕｔｅｓ）しか有さない。しかし、数百又は数千にすらなる可能性のある調査が見込まれる、より新しい臨床分野の場合、各種類の調査へ具体的なルールを適用することは不可能になる。例えば、開業医は、ピーナッツ、大豆、ミルク、小麦、卵など、多くの食品アレルギー検査を要求することがある。大豆及びミルクが非常に高い陽性値（例えば、それぞれ２４．３及び３０．１）を返し、他の検査が陰性である場合、病理学者は、医師に返送するレポートに、 「非常に高い結果がミルク（３０．１）及び大豆（２４．３）に対して検出された」
のようなコメントを含めることを望む。
【００３５】
検査データの解釈がこのコメントを与えることを可能にするルールは、
１０≦ミルク≦５０、非常に高い結果を指示する
１０≦大豆≦５０、別の非常に高い結果を指示する
ミルク＞大豆、レポート内でミルク値が大豆よりも前となるべきことを指示する
ピーナッツ＝０
小麦＝０、卵＝０
に基づいている。
【００３６】
たかだか五つのアレルゲンが検査されるこの単純な例では、上記のコメントの組合せの数は２５＝３２（重要度の順序は無視）である。検査結果の各組合せに対応して、異なるルールが存在する必要がある。
【００３７】
この単純なコメントであっても、このコメントと対応するルールとの３２個の可能な組合せの各々を個別に定義することは明らかに現実的ではない。そして、現実世界の例は、これよりもはるかに複雑である。
【００３８】
アレルギー知識ベースの場合、調査において実行できる文字通り数百の可能な検査が存在し、各々は、同じ化学物質（ＩｇＥ）を測定し、各検査の値は、特定のアレルゲンに対する患者の反応を示す。調査において数百の検査が存在する場合、専門家が、検査結果間に生じうる相互作用を定義して、正確なレポートが必要とする多数のコメントバリエーションを提供することは不可能である。解釈的知識ベースが定義できるようになる前に、この分野のデータ複雑性を大幅に低減しなければならない。
【００３９】
しかし、高度に複雑なデータを考慮したレポートを生成するという計算上の課題は、従来のエキスパートシステムの能力を超えている。例えば、４００の検査が存在すれば、各検査が、「陽性」又は「陰性」など、わずか２種類の出力しかもたない場合でも、検査結果の可能な組合せは２４００も存在し、各組合せは、あらかじめ生成されてコンピュータシステム上に保存される固有のレポート用テキスト結論を必要とする。ここでは、検査データ間に生じうる相互作用や、状況を大きく複雑化する臨床メモなどの他の関連する入力を考慮すらしていない。複雑なデータを解釈しようと試みる従来の手法は、数百又はそれ以上の所見が存在する場合は、実現可能ではない。
【００４０】
臨床環境では、様々な症例及び対応するレポートは、検査の数があまり多くなくても膨大になることがあり、患者の病歴情報及び臨床メモも考慮される場合は、なおさらそうである。
【００４１】
第２のより具体的な例は、航空会社によって直接的に、又は旅行代理店、航空券安売業者、若しくはオンライントラベルウェブサイトを介して間接的に航空券が発行される可能性のある航空券発行アプリケーションである。（例えば、旅行プラン変更のため、又は紛失チケット若しくは破損チケットの交換のため）チケットを再発行する必要がある場合、運賃表（航空券に影響する期間及び条件についての文書）に照らして、並びに元の取引明細（例えば、支払われた金額、購入チケットの枚数、取引通貨、乗客の名前、購入日付及び場所）に照らして、元の取引の詳細を確認する必要がある。とりわけ困難なのは、航空運賃表が複雑なテキストデータ項目であることである。航空運賃表は、何らかの明確なフォーマットに従っていないが、それにも関わらず、特定の重要な情報を含んでいる。この情報は、「キャンセル」、「旅行前」、「紛失チケット」などといった多数のキーターム（Ｋｅｙ Ｔｅｒｍ、キーとなる用語）として、更に、金銭値及び日付として、しばしば表現される。一つの運賃表内で、また複数の運賃表間で、各キータームは、様々な形で出現することがある。例えば、「ｆｒｅｅ ｏｆ ｃｈａｒｇｅ」（無料）、「ｆｏｃ」、及び「ｎｏ ｐｅｎａｌｔｙ」（違約金なし）は全て、同じことを意味する。
【００４２】
運賃表の各々は、キータームを含むばかりでなく、搭乗前キャンセルのための違約金、紛失チケットのための違約金などといった特定の情報も指定する。これらのキーコンセプト（Ｋｅｙ Ｃｏｎｃｅｐｔ、キーとなる概念）の各々は、キータームを使用して、様々な異なる方法で表現される。
【００４３】
したがって、上記の例では、様々な方法で表現された関連する情報を含む自由テキストのブロックを解析し、その後、自由テキストからの情報を他のデータとともに解析して、結論に達することが必要である。類似の問題は、医療診断（臨床メモが自由テキストで表現された重要な情報を含むことがあり、病理学検査及び人口統計データと併せて解釈されなければならない）の場面でも生じる。
【００４４】
自由テキストのブロックを解釈する際の困難には、以下が含まれる。
（ａ）一つ以上の有意な特徴を使用してルールを構築できるように、自由テキストのブロックからこれらの有意な特徴を抽出する際の困難。
（ｂ）知識ベースが、自由テキストブロックの少数の変形例を扱う困難。自由テキストブロック内のテキストデータが、ルールが構築されたテキストと全く同じではない場合、それらのルールは、新しい自由テキストブロックにも依然として適用されるほど十分には汎用的でないことがある。
（ｃ）知識ベースが、一つの自由テキストブロック内で、又は複数の自由テキストブロック間で、有意な特徴自体の異なる表現を扱う困難。
（ｄ）複数のキータームを含み、場合によっては幾つかのより上位のキーコンセプトを包含した自由テキストブロックに基づいてルールを構築する必要性。「キーコンセプト」は、解釈を行うときに専門家又はエキスパートシステムによって使用される、自由テキスト内に埋め込まれた有意な特徴である。キーコンセプトは、一連のキーターム（一つのキータームシーケンス）を表す、より上位の固有コードである。キータームシーケンスの幾つかの変形例が、単一のキーコンセプトにマッピングされる可能性がある。
【００４５】
要約すると、データを解釈する際に人間の解釈プロセスを模倣するために使用される従来のコンピュータ応用エキスパートシステムは、複雑なデータを解釈するために使用される場合には、以下を含む多くの制約を受ける。
（ａ）結論に達するため又は判断（例えば最終的な診断）を表現するために非常に多数のデータ値を考慮する必要がある場合、解釈プロセスを操るルールが過度に複雑で扱いにくくなるので、非常に大量のデータ値を解釈するのは困難である。
（ｂ）大きな構造化されていないデータ項目値を扱うのは困難であり、その結果、そのような複雑なデータの解釈ができない。複雑なデータ項目を、より単純で原子的なデータ項目及び値を抽出でき、それらをルール及び結論において使用できるようにする正規の形式に縮小することは、扱いにくいプロセスであり、知識ベースを維持するうえで長期にわたる苦労をもたらす。
【００４６】
したがって、従来のエキスパートシステムは、ますます大量化する複雑なデータを解釈し、そのようなデータを知識又は判断（テキストのレポートで表現される知識又は判断）に変換する際に制約を受ける。異なるソースから取得される数値データ及びテキストデータを含み、自由形式テキスト又はその代わりに「概況（ｓｙｎｏｐｔｉｃ）」レポートでのような構造化されたテキストを含む様々な形式で提示される大量の複雑なデータを解釈することが可能な、テキスト（テキストレポートなど）を生成するコンピュータ応用方法及びシステムが要望されている。
【発明の概要】
【発明が解決しようとする課題】
【００４７】
本発明の目的は、複雑なデータを解釈して、そのようなデータをテキストレポートで表現される知識又は判断に変換する際における従来のエキスパートシステムの上述した制約を解消する方法及びシステムを提供することである。
【課題を解決するための手段】
【００４８】
本発明の第１の態様によれば、複数のデータ項目から情報を生成する方法が提供される。この方法は、
（ａ）複数のデータ項目の少なくとも一つを用いて集約データ項目（ａｇｇｒｅｇａｔｅ ｄａｔａ ｉｔｅｍ）をポピュレート（ｐｏｐｕｌａｔｅ）する工程と、
（ｂ）集約データ項目を使用して情報を生成する工程と
を含み、
集約データ項目は、派生属性（ｄｅｒｉｖｅｄ ａｔｔｒｉｂｕｔｅ）の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
情報を生成する当該方法が、決定支援システムによって実行され、
生成された情報が、以下のグループ
ｉ．テキスト情報、
ｉｉ．機械命令
のうちの一つ以上に属する。
【００４９】
本発明の第２の態様によれば、複数のデータ項目から情報を生成するシステムが提供される。このシステムは、
（ａ）プリプロセッサであって、
ｉ．複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．複数のデータ項目から一つ以上の他の派生属性を構築する
プリプロセッサと、
（ｂ）前記集約データ項目を使用する派生属性及び他の派生属性を使用して情報を生成する情報生成器と
を備え、
情報生成器が、決定支援システムの少なくとも一部を成し、
前記集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
生成された情報が、以下のグループ
ｉ．テキスト情報
ｉｉ．機械命令
のうちの一つ以上に属する。
【００５０】
一実施形態では、この方法は、所定の構造の複数の要素の各々を、前記データ値のうちの対応する一つでポピュレートする前工程を含む。この構造は、前記複数の要素の各々を集約データ項目に関連付ける。この方法は、この構造に従って、前記複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートしてもよい。
【００５１】
一実施形態では、この方法は、前記構造を処理して、集約データ項目の一つ以上の特性を決定する工程を含む。
【００５２】
一実施形態では、前記構造は、複数の集約データ項目を相互に関連させ、この方法は、前記構造を処理して、前記複数の集約データ項目の各々の一つ以上の特性を決定する工程を含む。
【００５３】
一実施形態では、前記情報はテキスト情報を含む。前記情報は、臨床決定支援情報であってもよい。この他に、前記情報は機械命令を含む。
【００５４】
一実施形態では、情報を生成する工程は、知識ベース又は決定支援システムを使用して情報を生成する工程を含む。
【００５５】
一実施形態では、集約データ項目をポピュレートする工程は、複数のデータ項目を受け取る工程を含む。一実施形態では、テキスト情報は、構文法的及び／又は文法的に正しいものであってもよい。テキスト情報は、人間が読むことのできるものであってもよい。一実施形態では、テキスト情報は、レポートの少なくとも一部を成していてもよい。レポートは、一つ以上の検査結果に関連付けられていてもよい。一実施形態では、各データ項目は、検査結果の一つに対応することができる。検査は、アレルギー検査、白血病検査、病理学検査、血液検査、及び任意の他の種類の医療検査のいずれを含んでいてもよい。データ項目は、任意の他の情報、例えば、性別、年齢、人口統計情報、臨床症状に対応していてもよい。
【００５６】
一実施形態では、集約データ項目は、互いに関連する複数のデータ項目を含む。一実施形態では、集約データ項目をポピュレートする工程は、これら複数のデータ項目の少なくとも一つ又は別の集約データ項目に一のルールを適用することによって、集約データ項目をポピュレートする工程を含む。このルールは、分野に特有のルールであってもよい。この他に、このルールは、ケースに特有のルールであってもよい。このルールは、前記複数のデータ項目の一つ以上を用いて集約データ項目をポピュレートするためのものであってもよい。ルールは、閾値を上回る一つ以上の前記データ項目を用いて集約データ項目をポピュレートするためのものであってもよい。ルールは、閾値を下回る一つ以上の前記データ項目を用いて集約データ項目をポピュレートするためのものであってもよい。
【００５７】
一実施形態では、この方法は、（ａ）複数のデータ項目のうちの少なくとも一つを用いて一つ以上の集約データ項目をポピュレートする工程と、（ｂ）前記一つ以上の集約データ項目に一つ以上のルールを適用することによって、前記一つ以上の集約データ項目からのデータ項目を用いて一つ以上の更なる集約データ項目をポピュレートする工程と、（ｃ）一つ以上の更なる集約データ項目を使用して情報を生成する工程とを含む。
【００５８】
一実施形態では、複数のデータ項目の各々は、識別子及び値に関連付けられる。複数のデータ項目の各々は、その識別子及び値を含んでいてもよい。この識別子は、データ項目の名称又はラベルに関連付けられてもよい。一実施形態では、情報を生成する工程は、集約データ項目をポピュレートするデータ項目の名称又はラベルを情報に含める工程を含む。情報を生成する工程は、集約データ項目をポピュレートするデータ項目に関連付けられた値を情報に含める工程を含んでいてもよい。情報を生成する工程は、情報内における名称又はラベルの順序を決定する工程を含んでいてもよい。
【００５９】
一実施形態では、情報を生成する工程は、集約データ項目の一つ以上の特性を決定する工程を含む。特性を決定する該工程は、集約データ項目を構成するデータ項目の数を決定する工程、集約データ項目が空であるかどうかを決定する工程、集約データ項目が特定のデータ項目を含むかどうかを決定する工程、集約データ項目が特定のデータ項目を含まないかどうかを決定する工程、及び複数の集約データ項目がデータ項目を共有するかどうかを決定する工程のうちの一つ以上を含んでいてもよい。特性の一つは、値であってもよい。
【００６０】
一実施形態では、情報を生成する工程は、集約データ項目の決定された特性を情報に含める工程を含む。
【００６１】
一実施形態では、集約データ項目をポピュレートする工程は、一つ以上の他の集約データ項目を用いて集約データ項目をポピュレートする工程を含んでいてもよい。この集約データ項目と一つ以上の集約データ項目の各々とは、一つの集約識別子に関連付けられていてもよい。集約識別子は各々、集約名に関連付けられていてもよい。情報を生成する工程は、集約名を含める工程を含んでいてもよい。集約名を情報に含める工程は、情報内における集約名の順序を決定する工程を含んでいてもよい。
【００６２】
一実施形態では、集約データ項目をポピュレートする工程は、二つの他の集約データ項目に演算を施す工程を含む。演算を施す工程は、二つの他の集約データ項目の差、和、及び積のうちの一つ以上を含んでいてもよい。一実施形態では、集約データ項目をポピュレートする工程は、別の集約データ項目を構成するどのデータ項目が、特定の範囲内の値又は特定の離散集合に属する値を有するかを決定する工程を含む。
【００６３】
一実施形態では、情報を生成する工程は、集約データ項目に一つ以上のルールを適用する工程を含む。これら一つ以上のルールは、リップルダウンルール知識システムの少なくとも一部を成していてもよい。
【００６４】
一実施形態では、情報を生成する工程は、派生属性を構成する（一つ以上の）データ項目の（一つ以上の）識別子を情報に含める工程を含む。
【００６５】
一実施形態では、情報を生成する工程は、データ項目を構成するデータ項目の値を情報に含める工程を含む。
【００６６】
一実施形態では、情報を生成する工程は、情報内におけるデータ項目識別子の順序を決定する工程を含む。
【００６７】
一実施形態では、この方法は、情報の概念表現を構築する工程を更に含み、
概念表現は、
（ａ）複数のデータ項目、
（ｂ）一つ以上の派生属性、
（ｃ）一つ以上のルールの以前の反復において評価された一つ以上の結論
のうちの一つ以上の解析に基づいて決定支援システムのルールを評価することにより与えられる結論であり、結論の構築は、これらのルールの連続する再評価において行われる。
【００６８】
一実施形態では、この方法は、結論を構築する工程を更に含み、結論の構築は、ルール評価の反復において行われ、連続する各ルール評価は、以前のルール評価において構築された結論を利用する。
【００６９】
一実施形態では、複数のデータ項目から情報を生成するシステムであって、そのシステムは、複数のデータ項目のうちの少なくとも一つを用いて集約データ項目をポピュレートする集約データ項目ポピュレータと、集約データ項目を使用して情報を生成する情報生成器とを備える。
【００７０】
一実施形態では、情報生成器は、テキスト情報を生成するテキスト情報生成器である。あるいは、情報生成器は、機械命令を生成する機械命令生成器である。
【００７１】
一実施形態では、このシステムは、知識ベース又は決定支援システムを備える。一実施形態では、システムは、複数のデータ項目を受け取るデータ項目受信機を備える。情報生成器は、構文法的及び／又は文法的に正しいテキスト情報を生成するように構成されていてもよい。情報生成器は、人間が読めるテキスト情報を生成するように構成されていてもよい。情報生成器は、符号化テキスト情報を生成するように構成されていてもよい。符号化テキスト情報は、機械命令であってもよい。
【００７２】
一実施形態では、複数のデータ項目から情報を生成するシステムであって、そのシステムは、
（ａ）プリプロセッサであって、
ｉ．複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．複数のデータ項目から一つ以上の他の派生属性を構築する
プリプロセッサと、
（ｂ）集約データ項目を使用する派生属性及び他の派生属性を使用して情報を生成する情報生成器と
を備え、
情報生成器が、決定支援システムの少なくとも一部を成し、
集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
生成された情報が、以下のグループ
ｉ．テキスト情報
ｉｉ．機械命令
のうちの一つ以上に属する。
【００７３】
一実施形態では、情報生成器は、レポートの少なくとも一部を成すテキスト情報を生成するように構成されていてもよい。一実施形態では、集約データポピュレータは、複数のデータ項目のうちの少なくとも一つにルールを適用することによって集約データ項目をポピュレートするように構成されていてもよい。
【００７４】
一実施形態では、情報生成器は、集約データ項目をポピュレートするデータ項目に関連付けられた名称又はラベルを情報に含めるように構成される。情報生成器は、集約データ項目をポピュレートするデータ項目に関連付けられた値を情報に含めるように構成されていてもよい。情報生成器は、テキスト内における名称又はラベルの順序を決定するように構成されていてもよい。
【００７５】
一実施形態では、システムは、解釈部分を含む情報の概念表現を構築するビルダー（ｂｕｉｌｄｅｒ）を更に備えており、解釈部分は、複数のデータ項目を含む集約データ項目に対する演算を表す。
【００７６】
一実施形態では、情報生成器は、集約データ項目の特性を決定するように構成される。情報生成器は、集約データ項目を構成するデータ項目の数を決定すること、集約データ項目が空かどうかを決定すること、及び集約データ項目が特定のデータ項目を含むかどうかを決定することのうちの一つ以上を含むように構成されていてもよい。
【００７７】
一実施形態では、情報生成器は、集約データ項目の決定された特性を情報に含めるように構成される。
【００７８】
一実施形態では、集約データポピュレータは、一つ以上の他の集約データ項目を用いて集約データ項目をポピュレートするように構成される。集約データポピュレータは、集約データ項目に関連付けられた集約データ項目名をテキストに含めるように構成されていてもよい。集約データポピュレータは、テキスト内における集約データ項目名の順序を決定するように構成されていてもよい。
【００７９】
一実施形態では、集約データ項目ポピュレータは、二つの他の集約データ項目に演算を施すように構成される。
【００８０】
一実施形態では、集約データ項目ポピュレータは、別の集約データ項目を構成するどのデータ項目が特定の範囲内の値を有するかを決定するように構成される。一実施形態では、情報生成器は、集約データ項目に一つ以上のルールを適用するように構成される。
【００８１】
一実施形態では、情報生成器は、検査が実行された局所特性を考慮するように構成される。
【００８２】
一実施形態では、複数のデータ項目から情報を生成する方法が提供され、その方法は、各々がデータ項目の一つ以上を含む一つ以上の集約データ項目を使用して、一つ以上のルールの結果を評価する工程と、その結果に従って情報を生成する工程とを含む。
【００８３】
一実施形態では、情報はテキスト情報を含む。あるいは、情報は機械命令を含む。
【００８４】
一実施形態では、情報を生成する工程は、知識ベース又は決定支援システムを使用して情報を生成する工程を含む。
【００８５】
一実施形態では、一つ以上のルールの結果を評価する工程は、これらのルールのうちの一つ以上のための基礎として、集約データ項目の特性を使用する工程を含む。
【００８６】
一実施形態では、複数のデータ項目から情報を生成するシステムが提供される。そのシステムは、各々が複数のデータ項目の一つ以上を含む一つ以上の集約データ項目を使用して一つ以上のルールの結果を評価する評価器と、該結果に従って情報を生成する情報生成器とを備える。
【００８７】
一実施形態では、情報生成器は、テキスト情報を生成するテキスト情報生成器である。あるいは、情報生成器は、機械命令を生成する機械命令生成器である。
【００８８】
一実施形態では、システムは、知識ベース又は決定支援システムを備える。
【００８９】
一実施形態では、情報を生成する方法が提供され、その方法は、解釈部分を含む情報の概念表現を受け取る工程であって、解釈部分が、複数のデータ項目を含む集約データ項目に対する演算を表す工程と、解釈部分から情報を生成する工程とを含む。
【００９０】
一実施形態では、情報はテキスト情報である。あるいは、情報は機械命令である。
【００９１】
一実施形態では、情報を生成する工程は、データ項目の各々に関連付けられた一つ以上の名称又はラベルを情報に含める工程を含む。情報を生成する工程は、複数のデータ項目の集団名を情報に含める工程を含んでいてもよい。一つ以上の名称又はラベルを含める工程は、情報をテキストの概念表現のリテラル部分と統合する工程を含んでいてもよい。
【００９２】
一実施形態では、概念表現は疑似テキストである。
【００９３】
一実施形態では、情報を生成する工程は、構文法的及び／又は文法的に正しいテキスト情報を生成する工程を含んでいてもよい。
【００９４】
一実施形態では、情報を生成するシステムが提供され、そのシステムは、解釈部分を含む情報の概念表現を受け取る受信機であって、解釈部分が、複数のデータ項目を含む集約データ項目に対する演算を表す、受信機と、解釈部分から情報を生成する情報生成器とを備える。
【００９５】
一実施形態では、情報はテキスト情報であり、その場合、情報生成器はテキスト情報生成器である。あるいは、情報は機械命令であり、その場合、情報生成器は機械命令生成器である。
【００９６】
一実施形態では、生成器は、データ項目の各々に関連付けられた一つ以上の名称又はラベルを情報に含めるように構成される。生成器は、複数のデータ項目の集団名を情報に含めるように構成されていてもよい。生成器は、情報をテキストの概念表現のリテラル部分と統合するように構成されていてもよい。
【００９７】
一実施形態では、生成器は、構文法的及び／又は文法的に正しいテキスト情報を生成するように構成されていてもよい。
【００９８】
一実施形態では、本発明は、本発明の第１の態様に係る方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラムを提供する。
【００９９】
一実施形態では、本発明は、本発明の第７の態様に係るコンピュータプログラムを提供するコンピュータ可読媒体を提供する。
【０１００】
一実施形態では、本発明は、本発明の第３の態様に係る方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラムを提供する。
【０１０１】
一実施形態では、本発明は、本発明の第９の態様に係るコンピュータプログラムを提供するコンピュータ可読媒体を提供する。
【０１０２】
一実施形態では、本発明は、本発明の第５の態様に係る方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラムを提供する。
【０１０３】
一実施形態では、本発明は、本発明の第１１の態様に係るコンピュータプログラムを提供するコンピュータ可読媒体を提供する。本明細書における用語「サーバ」は、クライアント−サーバアーキテクチャの一部において、接続されたクライアントに対するサービスを実行する、ハードウェアとソフトウェアの任意の組合せを包含することが意図されている。
【０１０４】
クライアントとサーバは、単一のハードウェア又は複数の接続されたハードウェア上で動作する別個のソフトウェアとすることができる。
【０１０５】
したがって、好ましい一実施形態では、本発明は、異なるソースから取得される数値データ及びテキストデータを含む大量の複雑なデータを解釈することが可能な手段を提供することによって、従来のエキスパートシステムの制限の少なくとも幾つかを克服する、テキスト（テキストレポートなど）を生成するコンピュータ応用方法及びシステムを提供する。一実施形態では、本発明は、自由形式テキストを含む様々な形式で提示されるデータを解釈する手段を更に提供する。
【０１０６】
本発明の本質のより良い理解を達成するため、以下では、テキスト情報を生成する方法及びシステムの実施形態を、添付の図面及び実施例を参照しながら、あくまで例示として説明する。
【０１０７】
ここで、例１は、白血病レポート知識ベースの形態をとる好ましい一実施形態に係るテキストを生成する方法及びシステムの一例である。
【０１０８】
例２は、アレルギーレポート知識ベースの形態をとる好ましい一実施形態に係るテキストを生成する方法及びシステムの別の例である。
【０１０９】
例３は、航空券発券監査システムの形態をとる他の実施形態に係るテキストを生成する方法及びシステムの一例である。
【０１１０】
例４は、ログファイル監視システムの形態をとる他の実施形態に係るテキストを生成する方法及びシステムの一例である。
【図面の簡単な説明】
【０１１１】
【図１】テキストのブロックとテキスト正規化属性「ＮｏｒｍＣａｔ」を使用したその「正規形」の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図２】「ＮｏｒｍＣａｔ」におけるキータームのリストと各キータームを定義する正規表現の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図３】正規化テキストから通貨及び値を抽出した変数を有するコメントの二つの例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図４】テキストレポートなどのテキスト又はテキスト情報を生成するシステムの一実施形態のブロック図である。
【図５】テキストレポートなどのテキスト又はテキスト情報を生成する方法の一実施形態のフロー図である。
【図６】テキストレポートなどのテキスト又はテキスト情報を生成するシステムの別の実施形態のブロック図である。
【図７】テキストレポートなどのテキスト又はテキスト情報を生成する方法の別の実施形態のフロー図である。
【図８】テキストレポートなどのテキスト又はテキスト情報を生成する方法のまた別の実施形態のフロー図である。
【図９】テキストレポートなどのテキスト又はテキスト情報を生成する方法の第３の実施形態のフロー図である。
【図１０】ある実施形態の、キータームを定義するテキスト要約器属性（ＴＣＡ：ｔｅｘｔ ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ）の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１１】キータームとともにキーコンセプトも定義される図１０の実施形態に係るテキスト要約器属性（ＴＣＡ）の一例を示すユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１２】自ら（「ＴＣＡ」）についての値とキーコンセプト「ＣｘＢｔ」、「ＣｘＡｔ」、「ＲｉＯｂ１」及び「ＲｉＲｔｃ」についての値をサンプルケースに与える図１０のテキスト要約器属性（ＴＣＡ）のユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１３】キーコンセプトの評価を定める照合用形式（Ｍａｔｃｈｉｎｇ Ｆｏｒｍ）の一例を示す図１０のＴＣＡのユーザインタフェースのウィンドウである。ユーザは、各照合用形式のための生テキストの一例を提供するように促される。示される例は、航空券発券に関係する。
【図１４】派生マッチ（Ｄｅｒｉｖｅｄ Ｍａｔｃｈ）のための照合用形式の一例を示す図１０のＴＣＡのユーザインタフェースのウィンドウである。キーワードが追加されたため、照合用形式は、もはやそれらの例と一致しない。示される例は、航空券発券に関係する。
【図１５】新しいキーワードが追加された場合、照合用形式がそれらの例の正規化バージョンと一致するように、照合用形式をどのように変更する必要があるかを示す図１０のＴＣＡのユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１６】コメント内の変数においてキーコンセプトをどのように直接使用できるかを示す図１０のＴＣＡのユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１７】「ＢＴ」から「ＢｅｆｏｒｅＴｒａｖｅｌ」へのキーワードの名称変更が照合用形式をどのように自動的に更新するかを示す図１０のＴＣＡのユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図１８】日付及びブール値を抽出するＴＣＡの一実施形態のユーザインタフェースのウィンドウである。
【図１９】キーコンセプトのための例示的なブール値及び日付値を示す図１８の実施形態のユーザインタフェースのウィンドウである。示される例は、航空券発券に関係する。
【図２０】派生属性及びそれが表す生テキストの一部がツールのヒント（ｔｏｏｌｔｉｐ）としてユーザに提供される、本発明に係るＴＣＡの一実施形態のユーザインタフェースの例示的なウィンドウである。
【図２１】データ項目と集約データ項目の階層関係の一実施形態の概略図である。
【発明を実施するための形態】
【０１１２】
表１は、本発明に従って定義された用語の辞書である。表１で定義された用語は、本文書の全体にわたって大文字を使用して表記される。用語に大文字が使用されていない場合は、別途指摘がない限り、その通常の意味で解釈されたい。
【０１１３】
【表１】
【０１１４】
好ましい一実施形態では、本発明は、異なるソースから得られる数値データ及びテキストデータを含む大量の複雑なデータを解釈することが可能な手段を提供することによって、従来のエキスパートシステムの制約の少なくとも一部を解消する、情報（テキストのレポート（Ｔｅｘｔｕａｌ Ｒｅｐｏｒｔ）など）を生成するコンピュータ応用方法及びシステムを提供する。一実施形態では、本発明は、自由形式テキストで提示されるデータの解釈を可能にする自由テキスト解析手段を含む、様々な形式で提示されるデータを解釈する手段を更に提供する。
【０１１５】
図４は、複数のデータ項目からテキストを生成するシステムの一実施形態のブロック図であり、番号１によって全体的に示される。システム１は、情報を処理できる任意のシステムを構成していてもよく、この実施形態では、コンピュータ可読媒体２上に存在し、システムの中央プロセッサ４を制御するための命令を含むコンピュータプログラムを有するコンピュータシステム１として説明することができる。これらの命令は、人間が読めるテキストのレポート内の情報などのテキスト情報を複数のデータ項目から生成する方法５００を実施するためのものである。方法５００のフロー図が、図５に示されている。
【０１１６】
あるいは、生成される情報は、レポートとして提示されるテキスト情報ではなく、一つ以上の機械命令であり、システム１の構成要素は、これに応じて変更される。「テキスト情報（ｔｅｘｔｕａｌ ｉｎｆｏｒｍａｔｉｏｎ）」という用語は、これ以降、適切な場合は、この代替実施形態を包含するように、より広い意味に解釈されるべきであることを理解されたい。
【０１１７】
図４を参照すると、コンピュータ可読媒体２は、ＳＣＳＩなどの適切なバス６によってプロセッサ４に接続されるハードドライブディスク２の形態を取る不揮発性メモリ２を含む。幾つかの実施形態では、不揮発性メモリ２は、例えば、フラッシュメモリ、ＣＤ、ＤＶＤ、又はＵＳＢフラッシュメモリユニットを含む。
【０１１８】
２．一つ以上のデータ項目８は、それらのデータ項目の出所である他のシステム又はユーザとの通信インタフェースの一部であるデータ受信機１０を介して受け取られる。受信機は、
（ａ）データ項目
（ｂ）派生属性
（ｃ）結論
のうちの一つ以上を受け取ることができる。
【０１１９】
各データ項目８は、処理すべき入力データ、例えば、ある調査の一つ以上の検査の結果や、処理を必要とする他の任意の単純な又は複雑なデータを表す。
【０１２０】
このような処理は、解釈部分を含む情報の概念表現を構成するビルダー（ｂｕｉｌｄｅｒ）によって実行することが可能であり、ここで、解釈部分は、複数のデータ項目を含む集約データ項目に対する演算を表現する。幾つかの実施形態では、これらのデータ項目のソースは、１の外部にある情報システム３７である。
【０１２１】
生成されたテキスト情報２６は、テキスト情報を必要とする他のシステム又は受取人（１人以上のユーザなど）との通信インタフェースの一部であるデータ送信機１１（送信機と呼ばれる）を介して送られる。幾つかの実施形態では、テキスト情報の送り先は、１の外部にある情報システム３７である。送信機は、生成された情報を、
（ａ）機械
（ｂ）受取人
のうちの一つ以上に送る。
【０１２２】
図６に示されるような幾つかの実施形態では、システム３は、組み込みシステムである。図４のシステム１の構成要素と同様の図６の構成要素は、同様に番号がふられる。この実施形態の組み込みシステム３は、医学的検査などの検査を実施する機器の一部を成す。図示されたアーキテクチャばかりでなく、端末／メインフレーム、クライアント／サーバ、クラウドコンピューティングなどの任意の適切なアーキテクチャを使用できることを理解されたい。
【０１２３】
図４及び図６に示される実施形態では、コンピュータ可読媒体（例えばハードドライブ）２は、集約データ項目、他の派生属性（Ｄｅｒｉｖｅｄ Ａｔｔｒｉｂｕｔｅｓ）、及びテキスト情報を生成するためのルール、を定めるためのコンピュータ命令を保有する。
【０１２４】
概略的に言えば、「派生属性」は、解釈のために知識ベースに提示された原データ内には存在しないが、何らかの式を使用してこのデータから構築されるデータ項目である。この式は、以下の考慮事項
（ａ）データ項目又は他の派生属性の識別子
（ｂ）データ項目又は派生属性の値
（ｃ）以下の中で提示されるデータ項目又は派生属性の複数のインスタンス
ｉ．時間ベースのシーケンス
ｉｉ．他の任意のベクトルフォーマット
のいずれかに基づいている。
【０１２５】
集約データ項目は、派生属性の一例である。原（又は「プライマリ」）データは、データ項目から値ペアへのマッピングとして提示される。病歴データが検討される場合、原データは、データ項目からそのデータ項目に関する値の時間ベースシーケンスへのマップとして提示される。原データ内のデータ項目は、「プライマリ属性」と呼ばれる。
【０１２６】
派生属性は、ルール及びレポート内でプライマリ属性よりも自然で汎用的に使用できる、より上位の概念である。例えば、プライマリ属性は、委託医師の名前であってもよい。より有用な派生属性は、委託医師の名前が専門医師リスト上の名前と一致した場合に値「真」を有する派生属性「専門医」であってもよい。別の例は、プライマリ属性が患者の身長及び患者の体重の場合である。有用な派生属性は、身長の２乗に対する体重の比として評価される数値から構成される属性「ＢＭＩ」であってもよい。
【０１２７】
図４及び図６を参照すると、システム１は、図５及び図７に示されるテキストを生成する方法を実行することによってデータ項目８を処理するように構成される。この他に、データ項目８は、不動産査定など、任意の専門分野に関係していてもよい。不動産「検査」又は評価についてのデータ項目８は、例えば、家屋及び土地の広さ、家屋の向き、付近の郵便番号及び最近の査定、又は他の比較し得る不動産を含む。専門分野の他の例には、不正検出、骨ミネラル濃度レポート、メディカル警報、ゲノムレポート、分子レポート、及びアレルギーレポートのうちの一つ以上が含まれる。本明細書で説明されるシステム１、３及び方法５００は、そのようなデータ項目８を前処理するように構成されていてもよい。
【０１２８】
図４の例示的な実施形態では、システム１は、データ項目８を受け取るデータ受信機１０を有し、データ項目８は、その後、ハードドライブ（又は他のコンピュータ可読媒体）２上に保存されてもよく、又は保存されなくてもよい。検査がシステム１から離れた場所で、例えば、リモートサイト１２で行われる実施形態では、システム１は、リモートサイト１２も接続されるネットワーク１４に接続されるように構成されていてもよい。ネットワーク１４は、インターネット又はクラウドなどのワイドエリアネットワークであってもよいが、リモートサイト１２は、例えば、システム１の隣の部屋など、きわめて近くにあってもよく、その場合、ネットワーク１４は、ローカルエリアネットワーク又はＷｉＦｉやＷＬＡＮなどのワイヤレスネットワークとすることができる。この他に、システム３が検査機器５の一部である図６に示される例では、データ受信機１０は、プロセッサ４とデータソース２２との間のインタフェースとして動作してもよい。データソース２２の例は、システム３のサンプル検査装置であり、この装置は、サンプルに対する物理的、化学的、生物学的検査又は他の分析を実行する。
【０１２９】
プロセッサ４（図４及び図６）は、ハードドライブ２（又は他のコンピュータ可読媒体）上に保存された複数のデータ項目８のうちの少なくとも一つを用いて集約データ項目２４をポピュレート（データ投入）する集約データ項目ポピュレータとしてプログラムされる。一実施形態では、集約データ項目２４は、プロセッサ４による処理のためのメモリ２０のある種のデータ構造（例えば、ファイル、リスト、配列、ツリー、レコード、データベースで使用されるテーブル、フラットファイル、又は索引システムなど、任意の形式の適切なデータ構造）である。データ項目８は、メモリ２０内にも保存することができる。この実施形態におけるメモリ２０は、ＣＰＵレジスタ、オンダイ８ＲＡＭキャッシュ、外部キャッシュ、ＤＲＡＭ、及び／又はページングシステム、ハードドライブ（若しくは他のコンピュータ可読媒体）２上の仮想メモリ若しくはスワップ空間、或いは他の任意のタイプのメモリを含む。しかし、実施形態は、適切な場合は、より多くの又はより少ないメモリタイプを有していてもよい。
【０１３０】
プロセッサ４は、集約データ項目２４を使用して情報２６を（例えば、テキストレポートとして、又は一つ以上の機械命令として）生成する情報生成器になるようにプログラムされる。情報生成器４は、そのように生成された情報２６をメモリ２０内に保存するように構成される。この実施形態では、テキスト情報２６は、構文法的及び／又は文法的に正しい、人間が読めるテキストを表す。
【０１３１】
システム１、３の出力はテキストの情報であり、好ましくは人間が読める形式のもの、例えば、モニタ又は画面２８に印字されるテキスト（例えばテキストレポート）、プリンタ３０によって紙のレポート３３に印刷されるテキスト、データ送信機１１によってネットワーク１４を介してユーザのワークステーション３２（例えば内科医や外科医のコンピュータ）又は別の情報システム３７に送信される電子メール又は他のタイプの電子メッセージ３４のうちの一つ以上である。プロセッサ４によって生成されるテキスト情報は、データ項目８から導出される他の何らかの決定支援結果などのテキスト情報であってもよい。一実施形態では、ＳＭＳゲートウェイ（又は他のＳＭＳ中継機構）３４は、人間が読める形式のテキスト情報２６（すなわち構文法的及び／又は文法的に正しいテキスト）を含むＳＭＳ又は電子メールなどの電子メッセージを、電子デバイスなどの受信機３６に送信するように、システム１によって命令される。デバイス３６は、モバイル電話、スマートフォン、ＰＤＡ、又は他のハンドヘルド電子デバイス、処理能力を有する他の任意のコンピューティングデバイスとすることができる。一実施形態では、システム１は、ＳＭＳをハンドヘルドモバイルデバイス３６に送信する命令を送るように構成される。これは、検査結果が異常であり、即座のフォローアップを必要とする場合、又は検査の結果が迅速に求められる場合（例えば、航空券を検査する場合）に有利である。
【０１３２】
図５を参照すると、複数のデータ項目からテキストレポート内の情報などのテキストを生成する方法５００の一実施形態が示されている。集約データポピュレータとして動作するプロセッサ４（図４及び図６）は、集約データ項目２４にデータを投入するようにプログラムされる。図７を参照すると、テキストを生成する方法の別の実施形態が示されている。この方法は、複数の集約データ項目のうちの少なくとも一つに一つ以上のルールを適用することによって、（図４及び図６でラベル２４を付された）集約データ項目をポピュレートする副工程を含む。
【０１３３】
ルールは、ルールベースの知識／エキスパートシステム又は決定エンジンの少なくとも一部を形成してもよい。適切なルール知識システムの一例は、参照により本明細書に組み込まれる、出願人の米国特許第６５５３３６１号の明細書で開示されるリップルダウン（ＲｉｐｐｌｅＤｏｗｎ）として知られる独自仕様システムである。その米国明細書で説明されるように、ルールの集まりが、専門家によって構築される知識ベースである。ルールは、分野に特有であってもよい。例えば、ルールは、アレルギー検査の分野に、又は白血病検査の分野に特有であってもよい。しかし、幾つかの他の例では、ルールは、ケースに特有のルールであり、すなわち、一組の関連する検査結果／データ項目８に特有のルールである。この場合、システム１は、知識ベース又は決定支援システムである。
【０１３４】
図４及び図６を参照すると、一つのケースでは、データ項目８は、関連する名称又はラベルの部分と、値の部分とを有し、例えば、
ミルク，２５
大豆，３０
ピーナッツ，０
のようになる。
【０１３５】
データ項目８の各々は、識別子（ここでは、ミルク、大豆、又はピーナッツ）と、値（ここでは、２５、３０、又は０）に関連付けられる。これらの実施形態では、データ項目８の各々は、識別子と値を含む。識別子は、この例では、テキストの情報２６を生成（例えば、図５の工程５０４を参照）するために使用できるデータ項目の名称又はラベル（例えば「ミルク」）である。システムは、この識別子を、指定された
（ａ）言語（生成される情報が人間に可読な場合）、又は
（ｂ）命令フォーマット（生成される情報が機械命令である場合）
に翻訳及び／又は表現することが可能なルールを含む。これは、生成される情報が、状況に適した言語／フォーマットで、又はルールによって他に決定されるように、生成されることを可能にする。
【０１３６】
名称又はラベル「非常に高い食品アレルゲン」を有する集約データ項目２４には、例えば、以下のようなルール
ミルク＞２５なら、ミルクを「非常に高い食品アレルゲン」に含める ＡＮＤ
大豆＞２５なら、大豆を「非常に高い食品アレルゲン」に含める ＡＮＤ
ピーナッツ＞２５なら、ピーナッツを「非常に高い食品アレルゲン」に含める
によって、上記のデータ項目８からポピュレート（例えば、図５の工程５０２を参照）することができる。
【０１３７】
この他に、名称又はラベル「非常に高い食品アレルゲン」を有する集約データ項目２４（図４及び図６）には、例えば以下のようなデータ前処理操作（例えば、図７の工程７０２を参照）
「非常に高い食品アレルゲン」は、範囲（２５，１００）内の食品アレルゲンである
を適用することによって、上記のデータ項目８からポピュレートすることができる。
【０１３８】
複数のデータ項目からの情報の生成は、
（ｄ）プリプロセッサ（前処理装置）であって、
ｉ．複数のデータ項目のうちの少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．これら複数のデータ項目から一つ以上の他の派生属性を構成する
プリプロセッサと、
（ｅ）この集約データ項目を使用する派生属性及び他の派生属性を使用して、情報を生成する情報生成器と
を含むことが可能であり、
情報生成器が、決定支援システムの少なくとも一部を成し、
集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念を抽出して、それにより、前記情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構成されるデータ項目であり、
そのように生成された情報が、以下のグループ
ｉｉｉ．テキストの情報
ｉｖ．機械命令
のうちの一つ以上に属する。
【０１３９】
プロセッサ４（図４及び図６）は、一つ以上の集約データ項目（例えば２４）を使用して、上で例示されたように、一つ以上のルールの結果を評価する評価器としてもプログラムされる。テキスト情報生成器４は、上記の例では、例えば、ルールの結論に従って、レポート３３用のテキスト情報を生成する。
【０１４０】
このように、プロセッサ４（図４及び図６）は、
（ａ）一つ以上の集約データ項目２４を個々のデータ項目８を用いてポピュレートする集約データ項目ポピュレータ、
（ｂ）集約データ項目２４に適用された一つ以上のルールの結論を評価する評価器、及び
（ｃ）集約データ項目２４を使用して、（例えば、テキストレポートとして、又は一つ以上の機械命令として）テキスト情報２６を生成するテキスト情報生成器
の一つ以上として機能することが可能である。
【０１４１】
プロセッサ４（図４及び図６）は、各データ項目８を検査してから集約データ項目２４に含めてもよいことが分かる。（図４及び図６に示されるような）テキストを生成するシステムの典型的な実施形態は、概説された機能を並列的又は直列的に実行する二つ以上のプロセッサ４を含んでいてもよいことも分かるだろう。
【０１４２】
上で概説された例示では、名称「非常に高い食品アレルゲン」を有する（図４及び図６でラベル２４を付された）集約データ項目の一つの概念表現は、
ミルク，２５
大豆，３０
となる。
【０１４３】
テキスト情報生成器４（図４及び図６）は、集約データ項目２６をポピュレートするデータ項目８に関連付けられた名称又はラベルをテキスト情報２６に含めるように構成してもよい。例えば、プロセッサ４に、
「非常に高い食品アレルゲン」に対して非常に高い結果が見出された
というテキスト情報を形成するように求めてもよい（例えば、図５に示される方法の工程５０４において）。
【０１４４】
同じ例を続けると、テキスト情報生成器４として機能するプロセッサ４は、
大豆及びミルクに対して非常に高い結果が見出された
というテキストを表すテキスト情報を生成することができる。
【０１４５】
テキスト情報生成器（プロセッサ）４は、大豆がミルクよりも高い値を有しており、したがって、このテキストを提示する最良の方法は、大豆が上位となるようにテキスト内において名称又はラベルを順序付けることであると決定する。また、生成器４は、この集約データ項目２４内には二つの項目しか存在しないので、「大豆」と「ミルク」の間に「及び」を配置すべきであると決定する。値が２６の蜂蜜など、集約データ項目２４内に第３の項目が存在する場合、生成すべき文法的に正しいテキストの一つが、
大豆、蜂蜜及びミルクに対して非常に高い結果が見出された
であると生成器４が決定できるようにする機械命令を生成器４は含んでいる。
【０１４６】
テキスト情報生成器４は、必要な場合は、集約データ項目２４をポピュレートするデータ項目８に関連付けられた値をテキスト情報２６内に含めるように構成される。例えば、上記のテキストは、代わりに、
大豆（３０）、蜂蜜（２６）及びミルク（２５）に対して非常に高い結果が見出された
であってもよい。
【０１４７】
上記のものは、一つの一般的に要求される順序付けの例であるが、異なる状況では他の順序付けがあってもよい。
【０１４８】
別のそのような例は、委託医師向けの患者検査レポートを生成するために、研究所の病理学者が、患者の血液サンプルを分析した診断機器で使用された、例えば数百ものタンパク質バイオマーカーの結果を解釈しなければならないことがある場合である。そのような解釈を可能にするために、テキストを生成するシステムは、バイオマーカー結果を複数のサブグループに整理するが、その各々は、何らかの診断上の意味を有する、より上位のマーカーと考えることができる。例えば、バイオマーカーの一つのグループは、白血病の特定のＢＣＣ型の有無を検査してもよいし、別のグループは、白血病の特定のＡＭＬ型の有無を検査してもよい。
【０１４９】
これにより、テキストを生成するシステムは、各サブグループにおけるバイオマーカー結果の全てから単一の結果を導出することによって、例えば、ＢＣＣグループのマーカーを組み合わせた結果を表す単一の値と、ＡＭＬグループのマーカーを組み合わせた結果を表す単一の値を導出することによって、データ複雑性を低減する。こうなれば、患者の血液サンプルの結果は、研究所の病理学者による解釈に適することになり、病理学者は、遙かに少数だが上位のマーカーを検討しさえすればよい。
【０１５０】
解釈プロセスの簡略化に加えて、テキスト生成システムによって生成されて病理学者により委託医師に提供されるレポートは、個々のマーカー値ではなくマーカーのグループに対応する結果値を使用することによって簡略化される。マーカーのグループの観点から書かれたレポートは、より簡潔であり、個々のマーカー値自体の値変化に起因する変動をあまり受けない。
【０１５１】
マーカーをグループ化する利点は、全てのルールが個々のマーカー値を参照する必要がある場合とは異なり、エキスパートシステムが人間の専門家の解釈プロセス及びグループ値の推論に従うことができるようになるので、はるかに少数のルールしか必要とせずにエキスパートシステムを構築できることである。同様に、多様なレポートを、特定のマーカー値ではなく、マーカーのグループ及びそれらのグループ値の観点から書くことができるので、それらのレポートを、人間の専門家による定義を必要とする遙かに少数のレポート種類を用いて、依然としてエキスパートシステムによって生成することができる。
【０１５２】
一つのデータ項目を履歴的に（時間ベースで）眺める必要性から多数のデータ項目値が生じることもある。
【０１５３】
例えば、心筋酵素の結果値、例えばトロポニンを監視する病理学者は、緊急対応チームに警報を出すかどうかを評価するために、過去数週間にわたる以前の全ての結果に照らして現在の結果を解釈することが必要になる可能性がある。データ量及び複雑性は、この時系列の変化率を表し、そのため、現在値に対する時系列全体の重要な特徴を要約した、新しい上位（高レベル）の結果を提供することによって低減される。その場合、病理学者は、この上位の傾向の結果に照らして、現在の結果の意義を解釈することができる。
【０１５４】
幾つかの実施形態では、生成されるテキスト情報は、人間が読める形式のテキスト情報（すなわち、構文法的及び／又は文法的に正しいテキスト）を生成せず、代わりに、一つ以上の機械命令の形式を取るテキストを生成する。この場合、システムは、機械命令生成器を含む。機械命令は、ワークフローを制御することができる。例えば、アレルゲンが検出されなかったことを検査結果が示す場合、人間の評価者によるレポートのチェックを行わずに、機械命令は、システムに自動的にレポートを送らせることができる。この他に、機械命令は、レポートが生成される前に、保有サンプルに対する追加検査を実施させてもよいし、或いはその追加検査が実施されるように命令してもよい。
【０１５５】
別の実施形態では、システム１、３（図４及び図６）は、テキストレポート又は他の出力を受け取る受信機３６を含むことができる。図８を参照すると、テキストを生成する方法の他の実施形態は、ユーザ３８が、ＣＰＵに接続されたキーボード又は他の入力デバイスによって、テキストの概念表現を入力することを可能にする工程（工程８０２）を含む。概念表現は、システムによって不揮発性メモリ２内に保存される。「概念表現（ｃｏｎｃｅｐｔｕａｌ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）」は、原データ項目、又は集約データ項目を含む派生属性（派生データ項目）の観点からのルール条件の表現である。上記の例を使用すると、オペレータによって入力される概念表現は、
「非常に高い食品アレルゲン」に対して非常に高い結果が見出された
という「疑似テキスト」の形式を取る。
【０１５６】
この例の疑似テキストは、照合される個々の検査結果の分析に基づいた、結論／決定のコンパクトで形式張らない記述である。疑似テキストは、オペレータによって望まれる、テキストの高レベル記述を表すが、重要なこととして、システム１、３が計算するように意図された詳細を省略する。疑似テキストは、コンピュータ処理の詳細についての自然言語記述である。疑似テキストは、プログラミング言語又はスクリプト言語を使用して達成できる所望のテキストについてのより技術的な記述よりも、作成すること及び読むことが人間にとって容易である。
【０１５７】
概念表現は、解釈部分を含む。このケースでは、解釈部分は
「非常に高い食品アレルゲン」
である。
【０１５８】
解釈部分は、名称「非常に高い食品アレルゲン」を有する集約データ項目に対する操作を表す。図８（工程８０２）を参照すると、テキストを生成する方法８００の一実施形態では、システム１、３において、ユーザ３８は、解釈部分を含む疑似テキストとして、テキストの概念表現を入力する。データ項目８を受け取ると、テキスト情報生成器４は、本文書の他の箇所で説明されるように、その解釈部分からテキスト情報２６を生成する（図８の工程８０４を参照）。テキスト情報生成器４は、データ項目の各々に関連付けられた一つ以上の名称又はラベルをテキスト情報２６に含めるように構成される。テキスト情報生成器４は、複数のデータ項目のための集団名（識別子）をテキスト情報２６に含めるように更に構成されてもよい。テキスト情報生成器４は、テキスト情報２６をテキストの概念表現のリテラル部分（逐語的部分）と統合するように更に構成されてもよい。この例示では、
大豆、蜂蜜及びミルクに対して非常に高い結果が見出された
となる。
【０１５９】
図４及び図６に示される実施形態では、テキスト情報生成器４は、集約データ項目２４の特性を決定するように構成される。例えば、テキスト情報生成器４は、
（ａ）集約データ項目を構成するデータ項目の数を決定すること
（ｂ）集約データ項目が空であるかどうかを決定すること
（ｃ）集約データ項目が特定のデータ項目を含むかどうかを決定すること
のうちの一つ以上を含むように構成してもよい。
【０１６０】
これらは、テキストを生成する方法及びシステムの実施形態において集約データ項目に施す操作の例である。例えば、テキスト情報２６は、
（非常に高い食品アレルゲンの数）個の食品アレルゲンに対して非常に高い結果が見出された
などの疑似テキストから生成されて（図８の工程８０４）、
３個の食品アレルゲンに対して非常に高い結果が見出された
となる。
【０１６１】
このように、テキスト情報生成器４は、集約データ項目の決定された特性についての情報をテキスト情報２６に含めるように構成される。「Ｎｕｍｂｅｒ ｏｆ」（「の数」）は、集約データ項目「非常に高い食品アレルゲン」に対して行われる操作の一種である。
【０１６２】
集約データポピュレータ４（図４及び図６）は、集約データ項目２４を一つ以上の他の集約データ項目を用いてポピュレートするように構成してもよい。前者の集約データ項目は、関連のある複数のデータ項目、例えば患者が高いアレルギーを示すことが見出された全ての食品を含んでいてもよい。したがって、集約データ項目「食品」は、それもまた集約データ項目（例えば、ピーナッツ、ツリーナッツ。ツリーナッツもまた、アーモンド、ブラジルナッツ、クルミ、ヘーゼルナッツ、マカダミア、ピスタチオ、ピーカン、及びカシューナッツ等のデータ項目を包含していてもよい）であるデータ項目（例えば、ナッツ）を用いてポピュレートされてもよい。
【０１６３】
集約データポピュレータ４は、集約データ項目に関連付けられた集約データ項目名（識別子）をテキストに含めるように構成されてもよい。集約データポピュレータ４は、テキスト内における集約データ項目２４の名称の順序を決定するように構成されてもよい。一実施形態では、集約データ項目ポピュレータ４は、二つ以上の他の集約データ項目２４に演算を施すように構成される。例えば、一つの集約データ項目２４は、非常に高い結果の食品アレルゲンであってもよく、他の集約データ項目２４は、関心のある食品アレルゲンであってもよい。その場合、ポピュレータ４は、二つの集約データ項目の積集合を取ることによって、新しい集約データ項目２４、例えば、非常に高い結果の関心のある食品アレルゲンを生成してもよい。他の可能な演算子には、差（ｄｉｆｆｅｒｅｎｃｅ）、和（ｕｎｉｏｎ）、及び積（ｉｎｔｅｒｓｅｃｔｉｏｎ）が含まれる。別の実施形態では、集約データ項目ポピュレータ４は、別の集約データ項目を構成するどのデータ項目が特定の範囲内の値を有するかを決定するように構成される。
【０１６４】
一実施形態では、テキスト情報２６を生成する工程は、集約データ項目２４の決定された特性についての情報をテキスト情報２６に含める工程を含む。例えば、決定された特性が、集約データ項目を構成する項目の最大値である場合、テキスト情報は、「最も高い花粉アレルゲンは、結果＜最も高い花粉アレルゲンの値＞ｍｍｏｌ／Ｌを有する＜最も高い花粉アレルゲン＞であった」との文を含んでもよく、ここで、＜最も高い花粉アレルゲン＞は、最も高い値を有する花粉アレルゲンと定義された花粉アレルゲン集約データ項目の特性であり、＜最も高い花粉アレルゲンの値＞は、値それ自体である。
【０１６５】
幾つかの実施形態では、テキスト情報生成器４は、プログラムフローを制御するために、集約データ項目２４に一つ以上のルールを適用するように構成される（例えば、図７の工程７０２参照）。そのようなルールに関連付けられる論理検査の一例は、
Ｉｆ 適度な食品の数＞１ ＡＮＤ ｉｆ 症状の数＞１ ＡＮＤ 非常に高い食品の数＋食品の数＝０
である。
【０１６６】
このようなルールに関連付けられるワークフロー動作は、病理学者へのレポートを自動的に委託医師に開示するのではなく、検査結果及びレポートを検討のための待ち行列に入れることであってもよい。
【０１６７】
集約データ項目は、ルールを構成するブール条件の評価において使用される場合、テキスト情報２６を生成するためのデータ項目として扱えることが分かる。集約データ項目２４へのポピュレートには、一つ以上の他の集約データ項目を用いて集約データ項目２４をポピュレートすることが含まれていてもよく、他の集約データ項目の各々は、名称又はラベルの形式を取る関連集約識別子を有していてもよい。集約データ項目へのポピュレート（例えば、図５の工程５０２）は、二つ以上の別の集約データ項目を組み合わせることによって（例えば、和又は積演算）、又は別の集約データ項目を構成するどのデータ項目が特定の範囲内の値を有するか（例えば、範囲［２０〜５０］内の花粉項目）を決定するなど、より汎用的な条件を適用することによって達成することができる。
【０１６８】
その場合、集約識別子（名称又はラベル）は、データ項目名をテキスト情報２６内で使用する場合とちょうど同じようにテキスト情報２６内で使用することができる。ここでも、テキスト情報２６内における集約名の順序をテキスト情報生成器４が決定してもよい。
【０１６９】
システム及び方法の幾つかの実施形態は、知識ベース（ナレッジベース）による解釈に先立ってデータ複雑性を低減する、新しい又は改良されたデータ前処理方法を含み、この方法は、
（ａ）個々のデータ項目をデータの一つ以上のサブセット（部分集合）にグループ化する工程（各サブセットグループは、集約データ項目と呼ばれる）、
（ｂ）統計値（例えば、最大値、最小値、グループサイズ、中間値、平均値、最頻値、又は他の任意の統計値）、又は各集約データ項目についての他の数値、ブール値、若しくはテキスト値（以下、「集約」値）を計算する工程、
（ｃ）集約データ項目の集まりに施される指定された演算（例えば、和や積）を更に実行して、他の集約データ項目を生成する工程（例えば、各々が特定の癌マーカーの集まりを表す集約データ項目「ＢＣＬＬ診断」、「ＡＭＬ診断」、「ＢＣＬＬ支持」、「ＡＭＬ支持」の和集合が、全ての白血病癌マーカーから成る別の集約データ項目「白血病」を表してもよい）、
（ｄ）自由形式テキストからなる値を有するデータ項目から一つ以上のデータ項目及び値を生成する工程、及び／又は、
（ｅ）一連の値に関連付けられたデータ項目から一つ以上のデータ項目及び値を生成する工程
を含む。
【０１７０】
これにより、データ前処理方法の一つの態様は、個々のデータ項目及びそれらの値の集まりを検討し、そして、グループ化、フィルタリング、マッピング、相関付け、又は他の処理により、各々が値を有する派生属性（Ｄｅｒｉｖｅｄ Ａｔｔｒｉｂｕｔｅｓ）（集約データ項目を含む）を生成することによって、このデータの複雑性を低減する。
【０１７１】
データ前処理方法の別の態様は、データ項目の複雑な自由形式テキスト値を検討し、ストリングパターンマッチング及びフィルタリングの処理により、各々が値を有する、他のより単純なデータ項目を生成することによって、複雑性を低減する。
【０１７２】
データ前処理方法の別の態様は、一連の値に関連付けられたデータ項目を検討し、フィルタリング、傾向分析（ｔｒｅｎｄ ａｎａｌｙｓｉｓ）、又は他の分析により、各々が値を有する、他のより単純なデータ項目を生成することによって、複雑性を低減する。この方法は、一組の原データ項目における各個別データ値又は自由形式テキスト若しくはシーケンスである複雑なデータ項目値を検討することを必要とする代わりに、単一の派生データ項目及びその値の検討も可能にする。ここで、「派生」データ項目及びその値は、前処理によって構成されたデータ項目及び値を指し、「集約」データ項目を含む。これは、解釈する必要があるデータ値の量及び複雑性を著しく低減させ、したがって、（生成されるテキストレポートにおいて後で表現される）判断又は結論に達するために必要とされるルール及び決定点の数も著しく低減する。集約データ項目及びそれらの値は、知識ベースの出力として使用することもでき、得られるレポートテキストの複雑性を大きく低減する。
【０１７３】
他の実施形態では、テキストを生成するシステム及び方法は、様々な形式で提示されるデータを解釈する手段を更に含む。自由テキストデータ項目の解釈を可能にする自由テキスト解析手段も、このデータ解釈手段に含まれる。自由テキスト解析手段は、自由テキストデータ項目を前処理する方法を実行し、その方法は、テキストデータ内の「正規表現」を、以下のグループ
（ａ）長大な自由テキストデータ項目を解釈することを必要とする代わりに、データ項目の著しく単純な「標準的（ｃａｎｏｎｉｃａｌ）」表現を検討することを可能にする一連のキーワード
のうちの一つ以上にマッピングする工程と、
（ｂ）複雑なテキストデータ項目を多数のより単純な「原子的」データ項目に割り当てる工程であって、各原子的データ項目の値が、
ｉ．ブール値（例えば、真又は偽、はい又はいいえ）、
ｉｉ．有限の列挙（「ａ」、「ｂ」、「ｃ」）、又は
ｉｉｉ．数値
のうちの一つである、工程と
を含む。
【０１７４】
本明細書で説明されるような複雑なデータ項目の前処理のための新しい又は改良された方法を提供することによって、好ましい実施形態は、従来のエキスパートシステムの制約の少なくとも幾つかを克服し、大量の複雑なデータ（異なるソースから取得され、自由形式テキストを含む様々な形式で提示される数値データ及びテキストデータを含む）の解釈を可能にする。好ましい実施形態は、複雑なデータを知識又は判断（解釈されたデータに基づいた結論、結果、又は他の発見を含む）に変換する。知識又は判断は、テキストレポート内でテキスト情報（機械命令を含む）として表現される。
【０１７５】
データ前処理方法は、フィルタリング、グループ化、マッピング、及び他の操作によって、データ複雑性を扱いやすい程度まで低減する。例えば、解釈すべき数百のタンパク質バイオマーカー検査値が存在する場合、フィルタリング操作は、特定の患者に関連しないある種の結果を除外してもよい。この方法は、一つ以上のデータ項目を取り、ある式を適用して、それらの（一つ以上の）データ項目を処理し、派生属性にする工程も含む。派生属性は、より扱いやすい。というのも、派生属性は、原データ項目からより上位（高レベル）でより重要な情報を抽出し、したがって、解釈すべきデータを減少させて、扱いやすくするからである。データ前処理方法は、関連する複数のデータ項目を一つ以上のデータサブセットにグループ化するグループ化操作を含む。ここで、各サブセットグループは、集約データ項目と呼ばれる。現在の例を続けると、グループ化操作は、関連バイオマーカーの特定のサブセットの値を収集し、各サブセットについて、例えば最大値などの統計値を計算することができる。そのため、テキストを生成する方法及びシステムは、個々のバイオマーカーを解釈しなければならない代わりに、各グループについて単一のデータ値を検討しさえすればよく、検討すべきデータ値の数を著しく低減する。
【０１７６】
ある患者のテキスト病歴又は他のテキストデータなど、特定のデータ項目が複雑な場合、マッピング操作が、テキスト内のパターン（「正規表現」）を探し、これらのパターンを一連のキーワードにマッピングすることができる。そのため、テキストを生成する方法及びシステムは、長大な自由テキストデータ項目を解釈しなければならない代わりに、このテキスト項目の著しく単純な「標準的」表現を考えさえすればよい。病歴の多数のバリエーションが、同じ単純な標準的表現をもたらすことがあり、やはり、著しく少数のルール及び決定点を使用して解釈を行うことを可能にする、より容易な解釈を可能にする。
【０１７７】
マッピングの別の例は、テキストのパターンをキーワードに割り当てる代わりに、複雑なテキストデータ項目を、多数のより単純な「原子的」データ項目、すなわち、各原子的データ項目の値がブール値（「真」（ｔｒｕｅ）若しくは「偽」（ｆａｌｓｅ）、はい若しくはいいえ）、有限な列挙（「ａ」、「ｂ」、「ｃ」）、又は数値であるデータ項目に割り当てる。複雑な病歴から割り当てられる原子的データ項目の一例は、「真」又は「偽」の値を有する「糖尿病ステータス」と呼ばれるデータ項目であってもよい。別の例は、列挙値「ビグアニド」、「メグリチニド」、又は「スルホニル尿素」を有する「糖尿病薬」と呼ばれるデータ項目であってもよい。このようにして、病歴内に含まれる選択された重要な概念が抽出され、別の標準的な方式で表現される。
【０１７８】
これらの全ての例では、複雑なデータが、解釈を容易にするために、より単純なデータ項目へと前処理される。
【０１７９】
本発明の一実施形態では、集約データポピュレータ装置又はツール（例えば、データベース構造）が、複数のデータ項目を受け取る。ここで、各データ項目は、例えば、複数の検査のうちの一つの結果に対応する。この例示では、複数の検査の結果は、
（ａ）患者の状態の調査（例えば、患者が特定の形態の疾病又はアレルギーを有するか）
（ｂ）大量のデータの監査（例えば、航空券を再発行すべきかどうかを判断する場合に必要とされるもの）、又は
（ｃ）情報を抽出し、或いは決定に到達するために、大量の複雑なデータ項目（テキストレポート内の列挙データ及び数値データを含む）を解析する必要がある基本的に任意の解析
において使用される。
【０１８０】
図５及びタンパク質バイオマーカー検査の例を参照すると、複数のタンパク質バイオマーカー検査の検査値は、複数のサブセットデータグループ（集約データ項目）にグループ化される。言い換えると、各集約データ項目は、個々のタンパク質バイオマーカー検査値の集まりからポピュレートされる（工程５０２）。
【０１８１】
テキスト生成用システムのこの実施形態では、装置（集約データ項目ポピュレータ）は、様々な種類のデータ項目を（一つ以上の）適切な集約データ項目に関連付ける所定のデータ構造の形式での情報を含む。このデータ構造は、装置が、受け取ったデータを処理する様々なルールを適用することによって、受け取ったデータ項目の一つ以上を用いて所定の集約データ項目をポピュレートすることを可能にする。言い換えると、集約データ項目ポピュレータは、個々のデータ項目を関連する集約データ項目にマッピングすることによって、関連する集約データ項目をポピュレートする。「集約データ項目ポピュレータ」は、個々のデータ項目をどのようにマッピングすべきかを決定する一組のルールを含む。個々のデータ項目（プライマリ属性及び派生属性を含む）は、名称、種類、値によって、又は別の集合のメンバーシップによって、一つの集約データ項目にマッピングされる。言い換えると、集約データ項目は、集合メンバーシップに従って、個々のデータ項目を用いてポピュレートされる。現在の例では、集約データ項目のうちの一つにおける各データ項目は、例えば、特定の疾病又はアレルギーについての関連するバイオマーカーである。航空運賃表の例を使用すると、集約データ項目のうちの一つにおける各データ項目は、例えば、チケット再発行のための関連する条件とすることができる。
【０１８２】
他の実施形態（図９の工程９０２参照）では、データを前処理する工程は、自由形式テキストで表現されたデータを抽出する方法（本書において後でより詳細に説明する。工程９０２）を含む。この部分の議論のため、テキストを生成するシステム及び方法の一実施形態は、自由形式テキストを含む様々な手法で表現されたデータをテキスト要約器属性（ｔｅｘｔ ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ）を使用して抽出する手段を含む。そのようにして抽出されたデータ項目は、その後、他のデータ項目（例えば、システムによって受け取られた、個々の検査結果に関係する数値データ項目や、レポート／記録データの個々の項目、例えばクレジットカード有効期限や航空券発券日）と同様の方法で処理される。
【０１８３】
図７の工程７０２を参照すると、その後、追加の集約データ項目に、その集約データ項目に作用する他のルールによってデータを供給してもよい。追加の集約データ項目は、例えば、有意な値を有するデータ項目を含んでいてもよい。その場合、追加のルールが、追加の集約データ項目に適用される。ルールの一例は、追加の集約データ項目内の重要なデータ項目の数が閾値を超えたかどうかを判断することを含んでいてもよい。ルールの結果は、肯定的な検査結果を示してもよく、その場合、肯定的な又は他の検査結果を報告する適切なテキストが生成される。テキストは、集約データ項目を使用することにより、ケースごとにルールを必要とすることなく、柔軟にケースバイケースで生成してよい。
【０１８４】
図９を参照すると、自由形式テキストで表現されたデータ（例えば、臨床メモ、航空運賃表、不動産広告）を含むデータを異なるソースから抽出する工程（工程９０２）を含む、テキストを生成する方法の他の実施形態９００が示されている。この方法は、様々な手法で表現された関連する情報を含む自由テキストのブロックの解析を可能にする。自由テキストから抽出された情報（例えば、数値データ又は他の情報）が他のデータとともに解析され、結論又は判断に至る（工程９０４）。例えば、臨床メモは、自由テキストで表現された重要な情報を含んでいてもよく、また、病理学検査及び人口統計データと併せて解釈されなければならない。
【０１８５】
航空券発券環境では、自由テキストを解釈する必要性から生じる問題を解決しようとする発明者らの最初の試みは、「テキスト正規化属性」（Ｔｅｘｔ Ｎｏｒｍａｌｉｓａｔｉｏｎ Ａｔｔｒｉｂｕｔｅ：ＴＮＡ）と呼ばれる派生属性を生成することを含んでいた。ＴＮＡは、自由テキストを一連のキータームに変換する。「キーターム（Ｋｅｙ Ｔｅｒｍ）」は、自由テキストの断片を表す固有コードである。キータームは、可変の要素、例えば通貨値を含んでいてもよい。自由テキスト断片の幾つかの別形が単一のキータームにマッピングされてもよい。自由テキストから一連のキータームへのマッピングは、その自由テキストの標準的表現を提供する。
【０１８６】
ＴＮＡは、各キータームを、その多数の形態に従って、すなわち、そのキータームの別フレーズによって定義することを可能にした。派生属性の出力は、自由テキストから抽出されたキータームから成る、「凝縮された」又は「正規化された」テキストの文字列であった。図１は、典型的なテキストブロックと、ＴＮＡによって定義されたその「正規形」を表示するユーザインタフェースを示している。ＴＮＡは、図２に示されるように、本質的には、正規表現のキーワードへのマップである。
【０１８７】
関連するキータームは表として列挙され、キーワードごとに、マッチする正規表現のリストが存在した。次に、生テキストが、現在の検索位置から（位置的に）最も近いマッチを検索することによって、トークンのリストに変換された。ここでは、同じ位置から開始する複数のマッチは、マッチ長さによって選択される。ビルトインマッチャ（ｂｕｉｌｔ−ｉｎ ｍａｔｃｈｅｒ）は、「ＡＵＤ ７５」などの通貨値を、可変要素を有するキータームと考えることのできる特別な金銭値トークンに変換する。
【０１８８】
正規化されたテキストが、（一つ以上の）所望の値、例えば、取引の金銭値（７５）及び通貨の「値」（ＡＵＤ）を抽出するために解析された。発明者らによって行われた実験において所望の値を抽出するのに使用された構文法（シンタックス）は、テキスト正規表現パターンマッチングアルゴリズムを使用する独自仕様のリップルダウン条件言語における構文法であった。図３は、正規化テキストから通貨及び値を抽出するために使用された埋め込み変数を有するコメントの二つの例を表示するユーザインタフェース画面を示している。
【０１８９】
ＴＮＡは、知識ベースを構築することによって試されたが、その知識ベースでは、コメントは、所定の理由で航空券を再発行する費用を与える可変表現であった。ほとんど全ての場合において、
金額＝ＮｏｒｍＣａｔにおいて｛「ＣＸ ＢＴ ＦＯＲ ＭＶ＄」にマッチするコードにおける金額｝通貨＝｛ＮｏｒｍＣａｔにおいて「ＣＸ ＢＴ ＦＯＲ ＭＶ＄」にマッチするコードにおける通貨｝
のようなコメントを追加するための条件は、
ＮｏｒｍＣａｔがコードシーケンス「ＣＸ ＢＴ ＦＯＲ ＭＶ＄」を含む
であった。
【０１９０】
本質的には、同じマッチングシーケンスが３回、すなわち、可変コメントにおいて２回、それを追加するための条件において１回、書かれなければならなかった。
【０１９１】
このテキスト正規化プロセスを使用して、発明者らは、例えばオーストラリアなど一つの国で調査した運賃表のほとんどをうまく解析する知識ベースを構築することができたが、最も複雑な運賃表からデータを抽出するには、いくらかの機能強化が必要であった。しかし、別の国の運賃表のために新しいキーワード又はキータームを追加する必要があった場合は特に、知識ベースを維持することが困難であることを意味する問題が存在した。類似の問題は、他の状況でも、例えば、ある患者の検査結果の解釈に２人以上の臨床医からの臨床メモを含める必要がある場合にも生じた。
【０１９２】
ＴＮＡに伴う問題は、以下のように説明することができる。
【０１９３】
Ａ．抽出情報の変更に対する感度
ＴＮＡに新しいキーワードを追加した結果、コメント内の変数及びルール内の条件が、もはや意図したようには評価されない可能性があった。例えば、運賃表が、テキスト
．．．ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ ＢＵＴ ＷＩＴＨＩＮ ２４ ＨＯＵＲＳ ＯＦ ＳＣＨＥＤＵＬＥＤ ＦＬＩＧＨＴ ＴＩＭＥ ＣＨＡＲＧＥ ＡＵＤ ７５ ＦＯＲ ＣＡＮＣＥＬＬＡＴＩＯＮ．．．（出発前であって予定出発時刻の２４時間以内の場合、キャンセルには７５オーストラリアドルを請求します）
を含んでいたと仮定する。
【０１９４】
このテキストは、キーワード「ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ」、「ＣＡＮＣＥＬＬＡＴＩＯＮ」、及び「ＦＯＲ」を含む。これらのキーワードは、図２に列挙されたキータームの同義語（別形又は正規代替表現）である。ＴＮＡは、正規表現を、関連するキーワードにマッピングする。
【０１９５】
ＴＮＡが、「ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ」を「ＢＴ」で、「ＦＯＲ」を「ＦＯＲ」で、「ＣＡＮＣＥＬＬＡＴＩＯＮ」を「ＣＸ」で置き換え、加えて金銭値（ｍｏｎｅｔａｒｙ ｖａｌｕｅｓ）のビルトインマッチも置き換えた場合、正規化テキスト（すなわち、凝縮されたテキストの文字列である、派生属性の出力）は、
ＢＴ ＭＶ＜ＡＵＤ，７５＞ ＦＯＲ ＣＸ
となる。
【０１９６】
この正規化テキストは、条件
コードシーケンス「ＢＴ ＭＶ＄ ＦＯＲ ＣＸ」を含む
を満たす。
【０１９７】
ここで、語句「ＷＩＴＨＩＮ ２４ ＨＯＵＲＳ ＯＦ ＳＣＨＥＤＵＬＥＤ ＦＬＩＧＨＴ ＴＩＭＥ」（予定出発時刻の２４時間以内）が重要であり、捕捉する必要があると我々が決めた場合、我々はこれのための新しいキーワード、例えば「Ｗ２４ＨＦＴ」を追加しなければならない。我々の正規化テキストは、今度は、
ＢＴ Ｗ２４ＨＦＴ ＭＶ＜ＡＵＤ，７５＞ ＦＯＲ ＣＸ
となる。
【０１９８】
しかし、新しい正規化テキストは、コードシーケンス内に「Ｗ２４ＨＦＴ」が存在するので、もはや元の条件を満たさない。すなわち、新しいキータームの追加は、意図していたものとは異なる評価をＴＮＡに容易に行わせうる。
【０１９９】
キータームがテキスト正規化処理から除去される場合にも、全く同じ問題が生じる。
【０２００】
Ｂ．コメント及び条件の冗長性
上記の例で概説したように、正規化テキストから値及び通貨を抽出するために、同じマッチングシーケンスを３回使用しなければならなかった。これは、処理時間、並びにコメント及び条件を作成するのにユーザが必要とする時間の面で非効率的であり、最終的には、知識ベースの保守を必要以上に困難にした。
【０２０１】
Ｃ．キーワード名変更に対する感度
例えば、「ＢＴ」から「Ｂｅｆｏｒｅ Ｔｒａｖｅｌ」（出発前）にキーワードを変更すると決定した場合、やはり、このキーワードを使用していた変数及び条件は、もはや当てはまらなくなる。これは問題Ａに類似しているが、キーワード名変更は表面的な変更であるので、より容易に回避される。一方、新しいキーワードの追加又は既存のキーワードの削除は、テキスト正規化プロセスにとってより根本的な変更である。
【０２０２】
このように、自由形式テキスト内のデータを前処理する問題を解決しようとするこれまでの試みは、変更されたキーワードに対処できない欠点と、コメント及び条件を定義する際の非効率性に悩まされていた。この制約は、上で概説された航空券発券の例及びログファイルの例の状況において問題に対処しようと試みる際に見つかった。
【０２０３】
今からＩＴサポートサービスの例を取り上げて、以下のログファイル断片について検討する。
【０２０４】
【数１】
【０２０５】
ＴＮＡを使用するテキスト正規化処理は、これらのログエントリをフィルタリングして、
ＰＭ ＤＣ
に縮小する。ここで、第１のログエントリは「ＰＭ」と、第３のものは「ＤＣ」（ＷＡＲＮＩＮＧ Ｃｏｕｌｄ ｎｏｔ ｄｉｓｃｏｎｎｅｃｔ ｃｌｉｅｎｔ（警告はクライアントを切断しない））と符号化され、第２及び第４の（情報提供用の）エントリは無視される。
【０２０６】
偽陽性の（すなわち有意ではない）ＤＣ警報を示すルールは、条件
コードシーケンス「ＰＭ ＤＣ」を含む
を使用してもよい。
【０２０７】
しかし、ここで、ＴＮＡが、バックアップ（ＢＣＫ）イベントなど、新しい項目を含むように変更された場合、得られる正規化テキストは、
ＰＭ ＢＣＫ ＤＣ
となる。
【０２０８】
すると、ＤＣ警報が偽陽性であったことを示す条件は、もはや正しく評価されない。
【０２０９】
したがって、先の航空券発券の例で説明したものと同じＴＮＡの制約が、ここでも当てはまる。
【０２１０】
図９の実施形態は、キーターム（Ｋｅｙ Ｔｅｒｍｓ）とキーコンセプト（Ｋｅｙ Ｃｏｎｃｅｐｔｓ）の双方を組み込んだ新しいツール（「テキスト要約器属性（Ｔｅｘｔ Ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ）」又はＴＣＡとして知られる）を提供する。キータームとキーコンセプトの双方を単一のツールにまとめることによって、キーワードの追加又は削除によって引き起こされる問題は克服される。また、キーワードは、タームとコンセプトの両方で共有されるオブジェクトなので、集約データ項目に適用（例えば、図７の工程７０２）されるルールに影響を及ぼすことなく、名称を変更することができる。更に、ツールは、派生属性自体としてのキーコンセプトの抽出を含んでいるので、条件及び変数を反復する必要はあまりない。
【０２１１】
図１０は、あるＴＣＡの例示のユーザインタフェースを示している。「属性（Ａｔｔｒｉｂｕｔｅ）」又は「プライマリ属性（Ｐｒｉｍａｒｙ Ａｔｔｒｉｂｕｔｅ）」は、ルール条件又は他の表現の基本要素の一つである。各属性は、名称と、関連付けられた一つの値、又は場合によっては一連の値（時系列の複数の値がその属性に関連付けられる場合など）を有する。属性は、ルール条件のデータ値要素、例えば、単一のアレルゲンマーカーなどの下位（低レベル）のデータ項目や、花粉項目などのより上位（高レベル）の集約データ項目を表す。ルール条件の他の要素は、算術演算子やテキスト演算子や論理演算子、あるいはブール式を形成するために属性とその値を関連付けるその他の表現である。例えば、ルール条件「幾つかの花粉が高い」は属性「花粉」（集約データ項目）と、論理表現「幾つかのＸが高い」を含み、ここでは、変数「Ｘ」が花粉という値で置き換えられている。
【０２１２】
「ケース」は、解釈のためにエキスパートシステムに提示される、属性とその値の集まりである。プリプロセッサは、複雑なケース、すなわち、多数の属性、大量の自由形式テキストデータを伴う属性、又はデータ項目の長いシーケンスを伴う属性を有するケースを取り、集約データ項目（より上位の属性、又は「派生」属性）をケースに追加することによって、そのケースの複雑性を低減させ、ケースをルール条件及び解釈レポート内で、より容易に、かつより汎用的に使用できるようにする。
【０２１３】
テキスト要約器属性（ＴＣＡ）は、このような派生属性である。テキスト要約器属性は、一組のキーワード（又は「キーターム」）を、一組のキーコンセプト又は「派生マッチ（Ｄｅｒｉｖｅｄ Ｍａｔｃｈｅｓ）」とともに定義する（図１１参照）。各キーコンセプト又は派生マッチは、
（ａ）ターゲット（実際には、知識ベース又はエキスパートシステムにおける別の派生属性である）
（ｂ）抽出式（マッチした形式について派生属性の値を定める）
（ｃ）「照合用形式（Ｍａｔｃｈｉｎｇ Ｆｏｒｍｓ）」のリスト（照合用形式は、一連のキーターム（キータームのシーケンス）である）
から成る。
【０２１４】
本実施形態は、以下のようにして、テキストのブロック上でＴＣＡの評価を実行する。すなわち、
（ａ）テキストが一連のキーワード（キーワードのシーケンス）に正規化される。
（ｂ）正規化テキストが派生マッチの各々によって解析されて、キーコンセプトに値を提供する。各派生マッチについて、マッチする複数の照合用形式（もしあれば）のうち最長のものが取り上げられる。これは、文献において、「貪欲（ｇｒｅｅｄｙ）」パターンマッチとして知られている。
（ｃ）一つの照合用形式がマッチを見出した各派生マッチについて、その関連する派生マッチのための所定の式が適用され、これが、そのキーコンセプトに対応する派生属性のための属性値になる。
【０２１５】
関連する式の全てが「＄（１）」である航空運賃表を解析する例について検討する。これは、システム１、３（図４及び図６参照）によって、「照合したテキスト内で見出された最初の金銭値トークンを返す」として解釈される。後で別の抽出式を見る。
【０２１６】
上記のプロセスは、ケース内で参照された属性（例えば、上記のチケット再発行の例における「カテゴリ」）のためのサンプルシーケンス内のサンプルの全てにわたって適用することができる。「サンプルシーケンス」は、任意の属性用の複数の値からなる、順序付けられ、刻時されたリストである。サンプルシーケンス内の各値は、日付及び時間に関連付けられる。このようにして、ＴＣＡは、ＴＣＡのための、また付随する派生属性の各々のためのサンプルシーケンスを生成する。少なくとも一つの非空白値を含むサンプルシーケンスが、ケースに導入される。図１２は、属性「カテゴリ」（Ｃａｔｅｇｏｒｙ）のための値を有する例示的なケースを示しており、その場合、ＴＣＡのための値は、「ＴＣＡ」と呼ばれ、派生属性のための値は、「ＣｘＢｔ」、「ＣｘＡｔ」、「ＲｉＯｂ１」、及び「ＲｉＲｔｃ」と呼ばれる。
【０２１７】
ＴＣＡの使用は、先に説明したＴＮＡの使用に伴う問題を
（ａ）キーワードを安全に追加及び削除することを可能にし、
（ｂ）コメント及び条件内における冗長性を低減させ、
（ｃ）キーワードの名称変更（リネーム）を可能にする
ことによって解消する。
【０２１８】
Ａ．キーワードを安全に追加及び削除できる
派生マッチ（すなわちキーコンセプト）における照合用形式を定義する際、ユーザは、幾らかの例示の生テキストが各照合用形式に付随するように、照合されるべき生テキストの例を提供するように促される（図１３参照）。ユーザが提供する例は、照合用形式へのマッチを与えるものでなければならない。ユーザが、正規化された例がもはや照合用形式にマッチしないように（例えば、キーワードを追加することによって）キーワードに変更を加えた場合、ユーザは、（例えば、異なる色で示された派生マッチによって、又はユーザに警告を与える他の何らかの手段によって）これについて警告を受ける。
【０２１９】
例えば、照合（マッチング）用のフレーズ「−」を有するキーワード「−」がキーワードの組に追加された場合、図１５に示されるように、派生マッチは、不具合にみまわれる。派生マッチを回復させるには、新しいキーワードを削除する必要があり、又は照合用形式の幾つかを、それらの例の正規化バージョンにマッチするように、変更する必要がある。
【０２２０】
このように、派生マッチにおける例は、そのキーコンセプトの定義のための背景（コンテキスト）を提供する点で、リップルダウン知識ベースにおけるコーナーストーンケース（ｃｏｒｎｅｒｓｔｏｎｅ ｃａｓｅ）に似ている。
【０２２１】
Ｂ．コメント及び条件の、より小さな冗長性
ＴＣＡの派生属性は、コメント及び条件内の変数において直接使用することができる。これらの条件は、ケース内における派生属性の存在をまさに主張し、例えば、
ＣｘＢｔが利用可能
は、図１６に示されるコメントを追加するために使用することができた。
【０２２２】
Ｃ．キーワードの名称変更が可能
キーワードの名称はキーワードと派生マッチ内の照合用形式とによって共有されるオブジェクト参照にすぎないので、キーワードと一緒に派生マッチをＴＣＡに含めることにより、システムは、キーワードの名称変更に対して耐性を持つことになる。そのため、例えば、キーワード「ＢＴ」を「ＢｅｆｏｒｅＴｒａｖｅｌ」に名称変更した場合、我々の照合用形式は、図１７に示されるように、自動的に更新される。
【０２２３】
ＴＣＡの他の利点
異なる抽出式
派生マッチの図示の例は、運賃表の正規化テキストからの金銭値の抽出を示している。運賃表などの自由形式テキストから抽出する必要がある他の追加的な種類の情報が存在してもよい。（航空券発券シナリオにおける）例は、
（ａ）キーフレーズ（キーとなる語句）が発生したかどうか、及び／又は
（ｂ）日付
を含む。
【０２２４】
航空券発券の例を続けると、照合用形式が一つ以上の日付（これらは、金銭値と同様に、キーワードとして自動的に現れる）を含む場合、式「＠（ｉ）」を使用して第ｉの日付を抽出することができる。キーフレーズを扱うため、我々は、式「？」を使用して、マッチが存在する場合に派生属性が値「真」（Ｔｒｕｅ）を取るべきであることを示す。これらの式の双方を使用する（すなわち、日付とブール値を抽出する）ＴＣＡの例が、図１８に示されている。図１９は、派生属性のためのこれらのブール値及び日付値がこの例示的なケースにおいてどのように現れるかを示している。
【０２２５】
ツールのヒント（Ｔｏｏｌｔｉｐｓ）
ユーザは、ケース内に派生属性及びその値を見た場合、それがなぜそこにあるのかよく分からないことがある。すなわち、それが生テキストのどの部分を表すのかよく分からないことがある。この点を補助するため、ある実施形態では、派生属性及びその照合値を生じさせた生テキストを、（図２０に例示されるように）ツールのヒントとして提供する。
【０２２６】
幾つかのレポートセクション（各々が任意選択的な見出しを有する）から成る長大なレポートでは、これらのレポートセクションが提示される順序は、エンドユーザ（例えば、医師、発行チケットを検査する航空会社、不動産専門家又は買い手／売り手）にとって重要な要素である。すなわち、エンドユーザは、最も重要なレポートセクションをレポートの先頭近くで見ることを望む。しかし、一つのレポートセクションを別のセクションよりも重要にするものは、解釈される特定のケースに依存する。したがって、各ケース内のデータに作用するルールを使用して、指定されたレポートセクションを順序付けることは有益である。他の幾つかのレポートセクション、例えば、常にレポートの先頭にある要約レポートセクションは、その配置が固定されなければならない。したがって、ユーザは、固定及び可変のレポートセクション順序付けの双方を混合して定義できるようになっていてもよい。
【０２２７】
アレルギーの報告は、可変レポートセクション順序付けが必要とされる可能性のある分野である。花粉（ｐｏｌｌｅｎ）、食品（ｆｏｏｄ）、ダニ（ｍｉｔｅ）、カビ（ｍｏｕｌｄ）、及び動物（ａｎｉｍａｌ）アレルゲン検査結果についてのコメントに対応して、少なくとも５つの別個のレポートセクションが存在する。与えられた患者について食品アレルギー検査結果が最も重要である場合、食品レポートセクションが他の４つの前にくるべきである、などというようになる。最も重要ではない検査結果に対応するレポートセクションは、他のものの後に配置されるべきである。更に、固定のレポートセクション、すなわち、レポートの先頭に位置する要約レポートセクション、及び通常はレポートの末尾に位置する勧告レポートセクションもある。
【０２２８】
結果として、システムは、所望のレポートセクション順序付けに対応する値を割り当てるルール構文法（シンタックス）を使用して、各可変レポートセクションのための「派生属性」を定義する手段をオペレータ３８に提供する。上記のアレルギーの例では、例えば、「ｐｏｌｌｅｎ＿ｏｒｄｅｒ」、「ｆｏｏｄ＿ｏｒｄｅｒ」、「ｍｉｔｅ＿ｏｒｄｅｒ」、「ｍｏｕｌｄ＿ｏｒｄｅｒ」、及び「ａｎｉｍａｌ＿ｏｒｄｅｒ」の５つの派生属性が存在する。ｐｏｌｌｅｎ＿ｏｒｄｅｒは、全ての花粉データ項目のうちで最も高い値と定義され、他のものについても同様である。派生属性「ｐｏｌｌｅｎ＿ｏｒｄｅｒ」は、花粉レポートセクションに関連付けられる。各ケースについて、５つの派生属性の値が計算され、対応するレポートセクションが、これらの値に従って順序付けられる。例えば、ケースが、下記のデータ項目及び値
芝＝５０，カバノキ＝２０，（花粉）
小麦＝５，大豆＝１５，（食品）
カビ＝２
ダニ＝１
猫＝６２，犬＝４９（動物）
というデータ項目及び値を有する場合、レポートセクションは以下の順序
動物、花粉、食品、カビ、ダニ
となる。
【０２２９】
幾つかの実施形態では、システムは、以下のうちの少なくとも一つを提供してもよい。すなわち、
・必要とされる非常に大きな知識ベースを管理する基礎技術としてのリップルダウン（ＲｉｐｐｌｅＤｏｗｎ）ルールシステム
・知識ベースからの符号化出力を使用して、自動検証（ａｕｔｏｖａｌｉｄａｔｉｏｎ）及び反射型試験（ｒｅｆｌｅｘｉｖｅ ｔｅｓｔｉｎｇ）等の研究所ワークフローを例えば制御するワークフローエンジンを制御するなどの機械語命令である符号化情報を生成する機構
・ルール条件を構築するための自然言語構文法（シンタックス）
・解釈される特定のケースによって評価されるコメントへの変数の挿入。変数は、集約データ項目を使用して定義されてもよい。
【０２３０】
推論
人間の専門家と同様に、エキスパートシステムは、ルールが適用できる可能性もできない可能性もある大きなデータ集合ではなくルールが適用できる特徴を有するデータにルールを適用することができる形式へと、複雑なデータを縮小する必要がある。したがって、ルールベースのシステムは、関連ルールを選択するプログラムを必要とする。例えば、提示された（一つ以上の）ケースの属性に一致する条件をどのルールが有するかを決定するプログラムを必要とする。
【０２３１】
推論エンジン（ｉｎｆｅｒｅｎｃｅ ｅｎｇｉｎｅ）は、そのようなプログラムであり、適切なルールをケースに適用し、したがって、ルールを使用して「判断」などの結果を推論するタスクを実行する。
【０２３２】
この推論はしばしば、幾つかの環境において適切なルールに基づいている。しかし、他の環境では、ルールは変更される必要がある。したがって、知識ベースのルールの継続的な反復が存在する。解釈のために提示されたケースへの一つ以上のルールの適用可能性は、結果の解釈の正確性を決定する。
【０２３３】
知識ベースによって生成された解釈の検査及び可能な訂正が、一組の「拒否された」ケースを決定する。これらは、元の解釈を容認する、知識ベースを保守する専門家に提示され、又はさもなければ、訂正された解釈が知識ベースによって以降のケースに与えられるように、新しいルールを生成する。
【０２３４】
人間の専門家と同様に、ルールベースのエキスパートシステムは、関連する重要な特徴から推論が可能になるように、これらの特徴に関してエキスパートシステムに提示されるデータを有する必要がある。複雑な生データから推論した場合、必要とされる特定のルールの数が管理できない程度となるばかりでなく、ルールが構築された後でも、提示された複雑なデータ内で新たに遭遇するどのようなバリエーションも解釈することができない。データ内のより一般化された特徴からの推論は、解釈プロセス自体をより一般に適用可能なものとし、そのため、より頑強（ロバスト）にする。
【０２３５】
高トランザクション環境では、エキスパートシステムは、人間の専門知識を利用して生データの迅速な解釈を提供する際に、極めて重要な役割を果たすことが可能である。例えば、病理学研究所は、その研究所で雇用できる僅かな人数の病理学者の人的能力をはるかに超えた、１日当たり数万人の患者についての解釈レポートを提供する必要に迫られる場合がある。
【０２３６】
マルチレベル推論
マルチレベル推論は、解釈プロセスにおいて、より上位の抽象概念（上位概念と呼ばれる）を連続的に生成するプロセスである。
【０２３７】
より上位の抽象概念
推論プロセスにおいて後で他のルールによって使用される、より上位の抽象概念を提供するために、中間結論が使用される。中間結論自体は、最終的な解釈に出現しないが、最終的な解釈を決定するために使用されるルールに影響を及ぼす。
【０２３８】
好ましい実施形態では、
１．属性レベル、及び
２．ルールレベル
においてマルチレベル推論の二つの段階が存在する。
【０２３９】
属性レベルでのマルチレベル推論
属性は、ある式又は表現（例えば、算術式、ブール式、集合メンバーシップ演算）に従って、他の属性の点から定義されてもよい。
【０２４０】
これらは、オンライン情報システムから受け取った属性である「プライマリ」属性とは対照的に、「派生」属性と呼ばれる。
【０２４１】
例えば、知識ベースの仕事は、全ての疑わしいトランザクションに人間の専門家向けのフラグを付けて更なる検討ができるようにし、疑わしくないトランザクションにはフラグを付けないことである。疑わしくないトランザクションにフラグを付けたのでは、人間の専門家の時間を浪費するからである。
【０２４２】
知識ベースによって解析されるトランザクションの例には、以下の三つのトランザクション（取引）が含まれる。
【０２４３】
【表２】
【０２４４】
あるケースにおけるこれらの金融取引でのプライマリ属性は、「会社」、「国」、「金額」、及び「以前のフラグ」から構成されていてもよい。
【０２４５】
派生属性は、得られるルールをより汎用的かつより保守可能なものにする抽象概念として定義される。例えば、以下の派生属性が定義される。
１．「石油産業」。これは、取引が石油産業の会社を含む場合に真となる。Ｂａｘｘｏｎは、石油会社の組に属する一つである。
２．「非条約国」。これは、取引が、特定の国際条約の加盟国ではない特定の一組の国々に関連する場合に真となる。Ｕｇｉｎｔａ及びＴｉｇｅｒｉａは、この組に含まれる。
３．「ボーダライン金額」。これは、取引が、それが自動的に監視下に入るように最小値に近い場合に真となる。この例の場合、９５００ドルと９９９９ドルの間の金額は、ボーダラインと考えられる。
４．「以前のボーダライン数」。これは、過去１週間以内にボーダライン内にあった取引の数の総計である。
【０２４６】
これらの派生属性がマルチレベル推論プロセスによって評価されると、このケースは、以下のようになる。
【０２４７】
【表３】
【０２４８】
この例におけるこのマルチレベル推論は、全ての属性を定めるために、二つの推論解析を必要とする。
１．第１の解析は、属性「石油産業」、「非条約国」及び「ボーダライン金額」を決定できるようにする。これに続いて、
２．第２の解析は、属性「以前のボーダライン数」を計算できるようにする。
【０２４９】
マルチレベル推論の他の例は、（参照により本明細書に組み込まれる）オーストラリア特許出願第２０１０９０４５４５号において、本発明の出願人及び発明者らによって提供されている。
【０２５０】
属性レベルでのマルチレベル推論の適用を使用する派生属性は、単一の式又は表現に関して指定され、そのため、決定できるのは、プライマリ属性のみから導出できる派生属性に限られる。
【０２５１】
ルールレベルでのマルチレベル推論
より上位の抽象化は、
１．（上で示されたような）プライマリ属性から抽出される派生属性、及び
２．ルールベースによって抽出される知識ベースの結論
によって可能になる。
【０２５２】
ルールベース推論の第１のレベルでは、結論は、属性（プライマリ若しくは派生属性又はその両方）の点から定義された一つ以上のルールによって与えられる。
【０２５３】
第２のレベルでは、第１レベルの結論をルール条件内に組み込んだルールを使用して結論を与えてもよい。
【０２５４】
このルールレベルでのマルチレベル推論は、その後、必要に応じて、第３及びそれ以降のレベルに適用してもよい。
【０２５５】
上記の金融例では、ユーザは、ルール条件
・「ボーダライン金額」が真かどうか
・「非条約国」が真かどうか
・「以前のボーダライン数」が２以上であるかどうか
を使用して、第１レベルの結論を「疑わしい取引」と定めてもよい。このケースでは、これらの条件は全て真である。
【０２５６】
「疑わしい取引」が、単なる別の派生属性ではなく結論として定められる理由は、この「疑わしい取引」が、単一の式又は表現を用いて定められるものよりも複雑な概念であるからである。
【０２５７】
例えば、「疑わしい取引」を示す全く異なるシナリオが多数存在する可能性がある。各シナリオは、異なる一組のルール条件によって指定され、そのいずれもが、結論「疑わしい取引」を与える。
【０２５８】
逆に、「疑わしい取引」シナリオに非常に類似して見えるが、それを疑わしくないとする僅かな相違があるケースが存在する可能性もある。
【０２５９】
ユーザは、ここで、ルール条件
・「疑わしい取引」、及び
・「以前のフラグなし」
を使用して、第２レベルの結論「要検査」を定めてもよい。
【０２６０】
ここでも、これらの条件は、このケースについてはともに真である。結論「以前のフラグなし」は、すでにフラグが付けられた取引についてのフラグ付けを回避し、それによって取引の重複した検査を回避するために含まれており、その目的は、ここでも、人間の専門家の時間を浪費しないためである。
【０２６１】
ユーザは、「説明」と呼ばれる第３のレベルの結論も定義することができる。この結論は、「＜金額＞のこの取引は疑わしい。会社＜会社＞からの過去ボーダライン取引が先週＜以前のボーダライン数＞回あり、現在の取引は非条約国＜国＞からのものであるため。」という値を有する。この結論を与えるルール条件は、単に「要検査」である。
【０２６２】
この結論の目的は、なぜこのケースが知識ベースによって検査のためにフラグを付けられたのかについて、テキストの説明を人間の検査者に提供することである。コメント内の変数（＜＞記号によって示される）は、このケースにおける特定の属性値から評価される。
【０２６３】
ユーザは、ルール条件
「要検査」、及び
「石油会社」
を使用して、値「石油取引」を有する「待ち行列」と呼ばれる第３のレベルの結論も定めることができる。この結論の目的は、特定の種類の取引（このケースでは、石油会社による取引）に経験を有する専門家によって検査を受ける特定の待ち行列にこのケースを送ることである。
【０２６４】
これらの結論がマルチレベル推論プロセスによって評価されると、このケース及びそのルールベースの解釈は、以下のようになる。
【０２６５】
【表４】
【０２６６】
全ての属性が定められた後は、これらの全ての結論を定めるために、三つの推論パスが必要とされる。
【０２６７】
第１のパスでは、結論「疑わしい取引」が与えられる。第２のパスでは、「要検査」が与えられる。第３のパスでは、「待ち行列」及び「説明」が与えられる。
【０２６８】
リップルダウンルール（ＲｉｐｐｌｅＤｏｗｎ Ｒｕｌｅｓ）方法論を利用する知識ベースにルールレベルでのマルチレベル推論を適用することで、「疑わしい取引」のような概念を、疑わしい取引を示す全てのシナリオを考慮し、しかも疑わしい取引を示さない全てのシナリオを除外した上で、結論として定めることが可能になる。これは、マルチレベル推論だけを使用して一つ以上の派生属性によって提供されるものよりも広い視野を与える。
【０２６９】
マルチレベル推論は、その専門家分野にとって適切な抽象化レベルにある概念を用いて知識ベースを定義することを可能にする。
【０２７０】
属性レベルでは、マルチレベル推論は、オンライン情報システムから受け取った多かれ少なかれ恣意的な一組のプライマリ属性を、その分野に特有で適切な概念を表す派生属性へと前処理することを可能にする。
【０２７１】
属性レベルにおける前処理は、例えば、自由テキストの大きなブロックから概念を抽出することによって、又は多数の関連する属性をより上位の属性にフィルタリング及びグループ化することによって、データ複雑性を低減することもできる。
【０２７２】
結論レベルでは、マルチレベル推論は、人間の専門家がこの分野を理解して特定のシナリオの解釈を正当化するときに通常使用するであろう概念を表すように上位の抽象概念を定めることを可能にする。
【０２７３】
結論を定めるためにリップルダウン（ＲｉｐｐｌｅＤｏｗｎ）方法論を使用することは、これら上位の抽象概念が時間とともに精緻化されて、きわめて複雑な可能性のある概念の自然表現ばかりでなく、非常に正確で明快な表現をも提供できることを意味する。
【０２７４】
リップルダウンの組み込みコーナストーンケース検証手順（別途説明する）と結び付く、ケースの分野特有の適切な抽象概念の集合を用いることで、これらの抽象概念によって大規模で洗練された有用な知識ベースを構築及び保守するという専門家の仕事が実現可能になる。
【０２７５】
例１
第１の適用例は、数百のタンパク質発現マーカー又は遺伝子発現マーカーのマイクロアレイによってその値が決定される数百の検査を用いて診断が実行される白血病レポート知識ベースである。専門家は、関連するマーカーからなる複数のサブセット（部分集合）、このパターンに対応する診断、及び委託医師向けのテキストレポートに記載するそれら有意なサブセットについてのコメントを特定する診断レポート知識ベースを構築してもよい。
【０２７６】
アレイ検査結果は、知識ベースへの入力として、複数のデータ項目及び値ペアとして提供される。この例では、これらのデータ項目には、識別のためにＣＤ１〜ＣＤ１００のラベルが付される。これらのラベルは、アレイに対する１００個の要素を表している。現実世界の例は、数百のマーカーを含むことがある。
【０２７７】
この例では、データ値のうちの一つの値が５０未満であることは、その患者のサンプルについては、そのマーカーに対応する抗体の発現がないことを意味する。５０よりも大きな値は、（他のマーカーの値によっては）有意である可能性がある。１００よりも高いマーカーの値は、有意な発現を示す。
【０２７８】
特定の様々な白血病の診断は、１００個のデータ値の指定されたサブセットの値から推定することができる。
【０２７９】
例えば、Ｂ細胞慢性リンパ性白血病（Ｂ−ＣＬＬ）の診断は、ＣＤ１、ＣＤ２、ＣＤ３、ＣＤ４及びＣＤ５のうちの少なくとも二つが有意な発現を示すことから推定することができる。この診断は、ＣＤ６、ＣＤ７、ＣＤ８、ＣＤ９及びＣＤ１０のうちのいずれかが有意な発現を示すことによって支持されるが、これらは、それ自体でＢＣＬＬを診断するものではない。
【０２８０】
この他に、急性骨髄性白血病（ＡＭＬ）の診断は、ＣＤ１１、ＣＤ１２、ＣＤ１３、ＣＤ１４及びＣＤ１５のうちの少なくとも二つが有意な発現を示すことから推定することができる。この診断は、ＣＤ１６、ＣＤ１７、ＣＤ１８、ＣＤ１９及びＣＤ２０のうちのいずれかが有意な発現を示すことによって支持されるが、これらは、それ自体でＡＭＬを診断するものではない。
【０２８１】
５つの集約データ項目には、受け取ったデータ項目を用いて、下記の構造例によって指定されるようにデータが供給される。
１．「ＢＣＬＬ診断」は、データ項目ＣＤ１、ＣＤ２、ＣＤ３、ＣＤ４、ＣＤ５によってポピュレートされる。
２．「ＢＣＬＬ支持」は、データ項目ＣＤ６、ＣＤ７、ＣＤ８、ＣＤ９、ＣＤ１０によってポピュレートされる。
３．「ＡＭＬ診断」は、データ項目ＣＤ１１、ＣＤ１２、ＣＤ１３、ＣＤ１４、ＣＤ１５によってポピュレートされる。
４．「ＡＭＬ支持」は、データ項目ＣＤ１６、ＣＤ１７、ＣＤ１８、ＣＤ１９、ＣＤ２０によってポピュレートされる。
５．「白血病」は、集約データ項目「ＢＣＬＬ診断」、「ＡＭＬ診断」、「ＢＣＬＬ支持」、「ＡＭＬ支持」によってポピュレートされる。
【０２８２】
これらのデータ項目と１５個の集約データ項目の階層関係を与える構造の一態様の概略が、図２１に示されている。幾つかの実施形態では、構造の下位の階層がポピュレートされると、上位の階層における値又は特性が計算される。構造は、デバイス１のメモリ２０やハードドライブ２（又は他のデータ記憶ユニット）等に保存されて、ＣＰＵ４によって解釈されてもよい。
【０２８３】
以下の範囲
（ａ）定数５０と定義される「無検出」、及び
（ｂ）定数１００と定義される「高」
も定義してもよい。
【０２８４】
各セット内の有意なデータ項目を表すために、以下のルール
１．「有意なＢＣＬＬ診断」。これは、ルール「範囲［＞高］におけるＢＣＬＬ診断」によってポピュレートされる。
２．「有意なＢＣＬＬ支持」。これは、ルール「範囲［＞無検出］におけるＢＣＬＬ診断」によってポピュレートされる。
３．「有意なＡＭＬ診断」。これは、ルール「範囲［＞高］におけるＡＭＬ診断」によってポピュレートされる。
４．「有意なＡＭＬ支持」。これは、ルール「範囲［＞無検出］におけるＡＭＬ診断」によってポピュレートされる。
を適用することによって、さらなる集約データ項目がポピュレートされる。
【０２８５】
ＢＣＬＬ診断コメントは、以下の疑似テキスト
「＜有意なＢＣＬＬ診断＞にてＰａｎ−Ｂ細胞抗原発現、＜有意なＢＣＬＬ支持＞にて共発現、Ｂ細胞慢性リンパ性白血病（Ｂ−ＣＬＬ）に典型的。」
によって与えられる。
【０２８６】
変数「＜有意なＢＣＬＬ診断＞」は、有意なＢＣＬＬのデータ項目の名称と値を列挙するための指示であり、変数＜有意なＢＣＬＬ支持＞についても同様である。この実施形態では、列挙される名称と値は、最も有意な属性が最初に列挙されるように、データ項目値の降順で順序付けられる。
【０２８７】
ＢＣＬＬ診断ルールは、ＢＣＬＬ診断コメントの生成を
「有意なＢＣＬＬ診断の数≧２」、且つ
「有意なＢＣＬＬ支持の数≧１」
のようにトリガする。
【０２８８】
すなわち、コメントは、集合「有意なＢＣＬＬ診断」内に二つ以上のデータ項目が存在し、且つ、集合「有意なＢＣＬＬ支持」内に一つ以上のデータ項目が存在する場合に生成される。
【０２８９】
第２のコメント例として、ＡＭＬ診断コメントは、以下の疑似テキスト
「陽性の＜有意なＡＭＬ診断、名称として＞に基づいてＡＭＬ抗原発現と合致、＜有意なＡＭＬ支持、名称として＞にて共発現。Ｍ２分類の可能性が疑われる。」
によって与えられる。
【０２９０】
データ項目「＜有意なＡＭＬ診断、名称として＞」は、有意なＡＭＬのデータ項目の名称のみを列挙するための知識ベースに対する指示であり、変数＜有意なＡＭＬ支持、名称として＞についても同様である。
【０２９１】
この実施形態では、列挙される名称と値は、値がコメントに示されないとしても、最も有意なデータ項目が最初に列挙されるように、データ項目値の降順で順序付けられる。
【０２９２】
ＡＭＬコメントの生成をトリガするＡＭＬ診断ルールは、
「有意なＡＭＬ診断の数≧２」、且つ
「有意なＡＭＬ支持の数≧１」
であってもよい。
【０２９３】
コメントは、集合「有意なＡＭＬ診断」内に二つ以上のデータ項目が存在する場合に生成される。これは要するに、集合「ＡＭＬ診断」内に１００より大きい値を有するデータ項目が二つ以上存在し、集合「ＡＭＬ支持」内に５０より大きい値を有するデータ項目が少なくとも一つ存在することを意味する。以下のような患者「Ａ」からのサンプルの検査結果について検討する。
【０２９４】
【表５】
これらの結果は、知識ベースの一実施形態に送られる。この知識ベースは、集約データ項目を
・有意なＢＣＬＬ診断は、「ＣＤ５、ＣＤ３及びＣＤ４」と評価
・有意なＢＣＬＬ支持は、「ＣＤ７及びＣＤ８」と評価
・有意なＡＭＬ診断及び有意なＡＭＬ支持は、双方ともヌル（空）と評価
のように評価し、発現を評価する。
【０２９５】
その後、知識ベースは、上述のように定められたルールに従って解釈を行う。「有意なＢＣＬＬ診断」集合内には三つの要素が存在し、「有意なＢＣＬＬ支持」集合内には二つの要素が存在するので、このケースではＢＣＬＬルールが適用可能である。
【０２９６】
知識ベースは、ＢＣＬＬコメント「＜有意なＢＣＬＬ診断＞」及び「＜有意なＢＣＬＬ支持＞」内の変数を評価し、次いで、評価済みのコメント
「ＣＤ５（２６０）、ＣＤ３（１９０）及びＣＤ４（１５０）にてＰａｎ−Ｂ細胞抗原発現、ＣＤ７（９０）及びＣＤ８（６０）にて共発現、Ｂ細胞慢性リンパ性白血病（Ｂ−ＣＬＬ）に典型的。」
を与える。
【０２９７】
第２の例のために、以下のような患者「Ｂ」の検査結果について検討する。
【０２９８】
【表６】
【０２９９】
これらの結果は、知識ベースに送られる。知識ベースは、最初、集約データ項目を
・有意なＢＣＬＬ診断及び有意なＢＣＬＬ支持は、双方ともヌル（空）と評価
・有意なＡＭＬ診断は、「ＣＤ１２及びＣＤ１１」と評価
・有意なＡＭＬ支持は、「ＣＤ１９、ＣＤ２０及びＣＤ１８」と評価
のように評価する。
【０３００】
その後、知識ベースは、上記のルールに従って解釈を行う。「有意なＡＭＬ診断」集合内には二つの要素が存在し、「有意なＡＭＬ支持」集合内には三つの要素が存在するので、このケースではＡＭＬルールが適用可能である。
【０３０１】
その後、知識ベースは、コメント
「陽性のＣＤ１２及びＣＤ１１に基づいてＡＭＬ抗原発現と合致、ＣＤ１９、ＣＤ２０及びＣＤ１８にて共発現。Ｍ２分類の可能性が疑われる。」
を与える。
【０３０２】
例２
別の適用例は、実行可能なＩｇＥ検査が５００以上となる可能性があるアレルギーレポート知識ベースである。アレルギー専門家の仕事は、実行した検査のどのサブセット（部分集合）が患者について有意な結果値を有するか、どの検査値が有意でない可能性があるか、どの検査を追跡調査する必要があるか（可能性のある５００の検査のうちのどれを併せて追跡調査として実行すべきかを含む）について、委託医師に助言を与えることである。
【０３０３】
一つの解決例は、以下の通りである。
【０３０４】
・可能性のあるデータ項目名の全ての集まりから、それらのデータ項目名を、分野に特有のルール（有意花粉属性など）及びケースに特有のルールに基づいて、複数の集約データ項目にグループ化する。
【０３０５】
・集約データ項目の特性のいずれかを、更なるルール及び／又はコメントの基礎として使用する。例えば、ある集約データ項目の要素の数が一定の数を上回った場合、又はその集合が特定の要素を含む場合、特定のコメントを与える。
【０３０６】
・一つ以上の集約データ項目をコメント内の変数として使用する。例えば、「犬、猫及びピーナッツアレルギーが有意である」。このコメントにおいて、フレーズ「犬、猫及びピーナッツ」は、このケースにとって有意なアレルゲンから成る集約データ項目の評価である。このコメントの汎用的な形式は、「｛有意なアレルゲン｝アレルギーが有意である」とすることができ、ここで、集合｛有意なアレルゲン｝自体は、ルールによって定められる。
【０３０７】
・任意で、データ項目の値をコメントに含める。例えば、「犬（１０２．３）、猫（５６．４）及びピーナッツ（４３．５）アレルギーが有意である」。
【０３０８】
・コメント内に出現する集約データ項目内のデータ項目を適切に順序付ける。例えば、コメント内で最も重要な属性が最初に出現するように、その事例における属性値の降順で順序付ける。
【０３０９】
・データ項目を、レポートの残りの部分と整合した自然に構成された文に自動的にフォーマットする。例えば、三つの属性が有意である場合には、その集合のフォーマットを「犬、猫及びピーナッツアレルギー」とし、二つの属性だけが有意である場合には、その集合のフォーマットを「犬及び猫アレルギー」としてもよい。
【０３１０】
・データ項目の以前のグループ化に基づいて、データ項目のグループ化を定義することができるようにする。例えば、新しい集約データ項目は、一つの集合と別の集合の差、和、積、又は任意の集合演算とすることができる。これにより、複数の集合からなる階層構造を定義することが可能になる。例えば、集合「適切な検査」と集合「指示された検査」との差は、まだ指示されていない適切な検査の集合を特定することができる。
【０３１１】
・個々のデータ項目か、それらの属性を含む集約データ項目のいずれかを適宜に使用するコメントを定義できるようにする。例えば、個々のデータ項目のリストがその特定の事例のコメントにとって長すぎる場合、「ピーナッツ、大豆、ミルク、卵及び桃アレルギー」の代わりに、用語「食品アレルギー」を使用する。
【０３１２】
・同様に、サブセット（部分集合）名の代わりにスーパー集約データ項目名を使用するコメントを適宜に定義できるようにする。例えば、個々の集約データ項目のリストがその特定のケースのコメントにとって長すぎる場合、「花粉、動物、カビ、…アレルギー」の代わりに、用語「吸入アレルギー」を使用する。
【０３１３】
疑似テキスト
以下の表は、上述した疑似テキストの特徴の幾つかを定義しており、ここで、ｓ、ｔ、ｘ、ｙ、ｚは、それがプライマリ項目であるか派生データ項目であるかに関わらず、データ項目を指す。
【０３１４】
文字Ｘ、Ｙ、Ｚは、特に、集約データ項目（派生データ項目の一種）を指す。文字ａ、ｂは、数字又は名称付き定数を指す。文字ｐは、ブール式を指す。
【０３１５】
【表７】
【０３１６】
例３
第３の適用例は、航空券運賃表を解釈し、
（ａ）出発都市及び行先都市
（ｂ）どれだけの違約金が適用できるか
など、チケットを再発行できる条件を決定するために使用される知識ベースである。
【０３１７】
第２の知識ベースは、再発行チケットを解釈して、実際に支払われた料金並びに出発都市及び行先都市を決定するために使用される。
【０３１８】
第３の知識ベースは、他の二つの知識ベースの出力を解釈し、再発行チケットが運賃表の条件に従っているかどうかを判断する。
【０３１９】
とりあえず第１の知識ベースについて検討すると、運賃表内の自由形式テキストの断片は、以下のようなものとすることができる。
【０３２０】
【表８】
【０３２１】
この運賃表の断片を前処理するために、テキスト要約器属性（Ｔｅｘｔ Ｃｏｎｄｅｎｓｅｒ Ａｔｔｒｉｂｕｔｅ：ＴＣＡ）が使用される。ＴＣＡにおける幾つかのキーワードは、
（ａ）「ＣＡＮＣＥＬＬＡＴＩＯＮ ＦＥＥ」（キャンセル料）及び他の類似の語句を表す「ＣＸ」
（ｂ）「ＢＥＦＯＲＥ ＤＥＰＡＲＴＵＲＥ」（出発前）及び他の類似の語句を表す「ＢＴ」
（ｃ）「ＡＵＤ１１０」や「ＡＵＤ７５」のように可変の金額を有する金銭値を表す「＜ＡＵＤ ｎ＞」
である。
【０３２２】
ＴＣＡ内のキーコンセプトは、派生属性「ＣａｎｃｅｌｌａｔｉｏｎＦｅｅＢｅｆｏｒｅＴｒａｖｅｌ」であり、これは、この一連のキーワード「ＣＸ ＢＴ ＜ＡＵＤ Ｎ＞」から導出される可変の金銭値Ｎを有するものと定義される。この例では、属性「ＣａｎｃｅｌｌａｔｉｏｎＦｅｅＢｅｆｏｒｅＴｒａｖｅｌ」は、数値１１０を有する。
【０３２３】
知識ベースは、これ及び他の運賃表条件を、例えば「ＣａｎｃｅｌｌａｔｉｏｎＦｅｅＢｅｆｏｒｅＴｒａｖｅｌ＝１１０」などの標準化形式で、結論として出力するためのルールを有する。これらの標準化形式は、第３の知識ベースに入力され、第３の知識ベースは、再発行チケットについての実際の航行及び支払われた料金を要約する第２の知識ベースの出力と運賃表条件を比較する。その後、第３の知識ベースは、運賃表条件と、再発行チケットの要約された詳細を解釈して、運賃表条件に従って再発行チケットが再発行されたかどうかを判断する。
【０３２４】
例４
第４の適用例は、一連のログファイルエントリを監視し、ＩＴサポートスタッフに警報を送信すべきかどうか、またいつ送信すべきかを決定するために使用される知識ベースである。
【０３２５】
エキスパートシステムは、ログファイルの監視及び解釈を行うＩＴサポートスタッフを支援するときに、基本的な役割を演じることができる。エキスパートシステムは、ＩＴサポートスタッフが重要であると見なす、またＩＴサポートスタッフによる何らかの予防措置又は是正措置が許可されることを示す特定の警報、警告、又は傾向を、この非常に大きな自由形式テキストデータから抽出するのを補助することができる。
【０３２６】
ログファイルを解釈するときのより具体的な困難は、「偽陽性」、すなわち、実際には重要でない警報又は他の警報ほど重要でない警報の問題である。
【０３２７】
例えば、最初の「メモリ不足」警報は有意であるかもしれないが、続いて繰り返される同じ警報は、すでに警告された問題を指しているだけのこともあり（偽陽性）、さもなければ、実際に全く新しい問題であることもある（真陽性）。これら二つの警報の間に長い時間差が存在する場合、第２の警報は、真陽性である可能性がより高い。
【０３２８】
別の例は、高い率のページフォールトに起因する「ディスクスラッシング」警報の場合である。これは重要であるが、場合によっては、より重要な問題の症状にすぎず、その問題とは、メモリ不足状態であるかもしれない。この場合、「ディスクスラッシング」警報より前の「メモリ不足」警報の存在は、第２の警報が、先行する「メモリ不足」警報が存在しない場合ほどには重要でないことを意味する。
【０３２９】
別の例は、「クライアント切断失敗」警報の場合である。１日のほとんどの時間においては、これは、ＩＴサポートスタッフによる即刻の調査を許可する有意な警報である。しかし、警報がログに取られたのが、１日の特定の時間、例えば、毎日の予防保守（ｐｒｅｖｅｎｔａｔｉｖｅ ｍａｉｎｔｅｎａｎｃｅ：ＰＭ）のためにシステムがオフライン状態にあることが知られている午前２時である場合、その警報は有意ではないかもしれない。
【０３３０】
警報の有意性と適切な応答を判断するルールは、警報の種類だけでなく、それらの順序、頻度、互いに対するタイミング、更には絶対的タイムスタンプさえも考慮しなければならない。
【０３３１】
警報の有意性が判断されると、取るべき適切な行動に関する決定を、エキスパートシステムによって行うことができる。したがって、エキスパートシステムがログファイルを解釈するためには、個々のログエントリ又はログエントリのシーケンスを、キーターム又はキーコンセプトのシーケンスに分類するように前処理を行う必要がある。したがって、複雑で本質的には自由形式のテキストログファイルは、正規化された形式に縮小され、その正規化形式から、より単純でより上位の原子的データ項目を抽出し、ルール条件内で使用することができる。
【０３３２】
ユーザ（クライアント）を切断できないことをログエントリが示している場合における潜在的な警報状況の例を示す。しかし、システムが予防保守を開始した後にこの警告が発生した場合は、潜在的な警報は偽陽性と見なされ、ＩＴサポートスタッフに警報は送られない。
【０３３３】
一連のログファイルエントリの以下の例について検討する。
【０３３４】
【数２】
【０３３５】
知識ベースによる解釈の前にこれらのログファイルエントリを前処理するため、我々はＴＣＡを構築する。ＴＣＡ中のキーワードは、
（ａ）「Ｐｒｅｖｅｎｔａｔｉｖｅ Ｍａｉｎｔｅｎａｎｃｅ」（予防保守）及び他の類似の語句を表す「ＰＭ」
（ｂ）「ＷＡＲＮＩＮＧ」（警告）及び他の類似の語句を表す「ＷＡＲＮ」
（ｃ）「Ｃｏｕｌｄ ｎｏｔ ｄｉｓｃｏｎｎｅｃｔ ｃｌｉｅｎｔ」（クライアントを切断できなかった）及び他の類似の語句を表す「ＤＣ」
である。
【０３３６】
これらのログファイルエントリについてのＴＣＡの値は、正規化テキスト形式「ＰＭ ＷＡＲＮ ＤＣ」である。このＴＣＡのキーコンセプトの一つは、派生属性「Ａｌｅｒｔ」（警報）である。これは、正規化テキスト形式が「ＷＡＲＮ」を含む場合（本例でも含む）にブール値「真」を有するように定義される。
【０３３７】
知識ベースは、属性Ａｌｅｒｔの値が「真」である場合にワークフロー動作「Ｓｅｎｄ ａｌｅｒｔ ｅｍａｉｌ」（警報電子メールを送る）を追加するためのルールを有する。このワークフロー動作は、通知先のＩＴサポートスタッフの電子メールアドレスを含み、電子メールヘッダは、警報の要約を提供し、電子メール本文は、警報の詳細を記述する。
【０３３８】
ＴＣＡの別のキーコンセプトは、派生属性「ＦａｌｓｅＰｏｓｉｔｉｖｅ」（擬陽性）である。これは、正規化テキスト形式が「ＰＭ ＷＡＲＮ ＤＣ」を含む（本例でも含む）場合にブール値「真」を有するように定義される。
【０３３９】
知識ベースは、属性ＦａｌｓｅＰｏｓｉｔｉｖｅの値が「真」である場合に、ワークフロー動作「Ｓｅｎｄ ａｌｅｒｔ ｅｍａｉｌ」を削除するための別の後続するルールを有する。
【０３４０】
前処理段階では、これら二つの派生属性Ａｌｅｒｔ及びＦａｌｓｅＰｏｓｉｔｉｖｅがケースに追加され、双方とも値「真」を有する。
【０３４１】
知識ベース推論の段階中、条件「Ａｌｅｒｔ ｉｓ ｔｒｕｅ」（警報が真）を有するルールによって、警報ワークフロー動作が解釈に追加される。しかし、警報ワークフロー動作は、条件「ＦａｌｓｅＰｏｓｉｔｉｖｅ ｉｓ ｔｒｕｅ」（擬陽性が真）を有する後続のルールによって削除され、最終的な結果としては、警報ワークフロー動作は解釈中に存在せず、したがって、ＩＴサポートスタッフに警報電子メールは送信されない。
【０３４２】
ここまで実施形態を説明してきたので、幾つかの実施形態が、以下の利点の幾つかを有しうることが分かるだろう。
【０３４３】
・単一のテキストレポートを生成する目的で、多数のデータ項目（幾つかの実施形態では、自由形式テキストとして提示されるテキスト結果を含む）を処理することが可能である。
【０３４４】
・そのレポートは、各ケースにとって重要なデータ項目を、適切な順序で、言語学的に自然な構文法で提示する。
【０３４５】
・具体的なレポートバリエーションの数は、データ項目の可能なサブセットの数及び各サブセット内で可能な順序付けの数に起因して、本質的に無限である。
【０３４６】
・特定のレポートを決定する具体的なルール条件の数も、ケース中の属性及びそれらの値のパターンの数に起因して、本質的に無限である。
【０３４７】
・それにも関わらず、ルールは前処理段階の結果である派生属性に基づいているので、専門家は、管理可能な数のルールを用いて、知識ベースを構築及び保守することができる。
【０３４８】
・多数の属性及びそれに対応する多数のレポートバリエーションを管理できるエキスパートシステムが提供される。
【０３４９】
具体的な実施形態に示される本発明には、広範に説明されたような本発明の主旨及び範囲から逸脱することなく、多くの変形及び／又は変更をなし得ることが理解されるだろう。したがって、本発明の実施形態は、全ての点において、限定的ではなく、例示的なものと見なされるべきである。
【符号の説明】
【０３５０】
１ システム
２ コンピュータ可読媒体
３ システム
４ 中央プロセッサ
８ データ項目
１０ データ受信機
１１ データ送信機
１２ リモートサイト
１４ ネットワーク
２０ メモリ
２２ データソース
２４ 集約データ項目
２６ テキスト情報
２８ 画面
３０ プリンタ
３２ ワークステーション
３６ 受信機
３７ 情報システム
３８ ユーザ
【特許請求の範囲】
【請求項１】
複数のデータ項目から情報を生成する方法であって、
（ａ）前記複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートする工程と、
（ｂ）前記集約データ項目を使用して前記情報を生成する工程と
を含み、
前記集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、前記情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
情報を生成する当該方法が、決定支援システムによって実行され、
生成された前記情報が、以下のグループ
ｉ．テキストの情報、
ｉｉ．機械命令
のうちの一つ以上に属する、方法。
【請求項２】
前記複数のデータ項目を前処理して、前記複数のデータ項目から一つ以上の派生属性を抽出し、それによりデータ複雑性を低減する前工程を含む、請求項１に記載の方法。
【請求項３】
データの前記前処理が反復して行われ、一つ以上の派生属性が、以前の反復において構成された派生属性から抽出される、請求項１又は２に記載の方法。
【請求項４】
前記式が、以下の考慮事項のうちの一つ以上に基づく、請求項１〜３のいずれか一項に記載の方法。
（ａ）前記複数のデータ項目の識別子、
（ｂ）一つ以上の派生属性の識別子、
（ｃ）前記複数のデータ項目の値、
（ｄ）前記一つ以上の派生属性の値、
（ｅ）一つのデータ項目の複数のインスタンスの値、ここで、前記複数のデータ項目の複数のインスタンスは、
ｉ．時間ベースのシーケンス、
ｉｉ．他の任意のベクトルフォーマット
で与えられる、
（ｆ）前記派生属性の複数のインスタンスの値、ここで、前記派生属性の複数のインスタンスは、
ｉ．時間ベースのシーケンス、
ｉｉ．他の任意のベクトルフォーマット
で与えられる。
【請求項５】
前記派生属性が、
（ａ）集約データ項目、
（ｂ）テキスト要約器属性、
（ｃ）複数のデータ項目から一つ以上の上位概念データ項目を抽出し、それによりデータ複雑性を低減するデータ前処理の任意の他の結果
のうちの一つ以上である、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
（ｃ）における前記複数のデータ項目が、複数の派生属性である、請求項５に記載の方法。
【請求項７】
前記テキスト要約器属性は、キータームの一つ以上のシーケンスを一つのキーコンセプトにマッピングし、
キータームは、自由形式テキストから情報を抽出できるように、自由形式テキストの断片を表す正規表現である、請求項５又は６に記載の方法。
【請求項８】
各キーコンセプトが、
（ａ）前記決定支援システムにおける派生属性であるターゲット、
（ｂ）照合用形式によって選択された自由形式テキストの断片に関して、前記ターゲットの一つ以上の値を定める抽出式、及び
（ｃ）照合用形式のリストであって、各照合用形式がキータームのシーケンスである、照合用形式のリスト
を含む、請求項７に記載の方法。
【請求項９】
データ項目の一つ以上の集合を識別する前工程を備える請求項１〜８のいずれか一項に記載の方法であって、前記集合のメンバーシップ（集合メンバーシップ）が、
（ａ）データ項目識別子、
（ｂ）データ項目値、
（ｃ）データ項目種類、
（ｄ）データ項目の他の特性
のうちの一つ以上によって決定され、
集合メンバーシップが、個々のデータ項目から集約データ項目へのマッピングを可能にする、請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
前記データ項目の前記集合が、派生属性の集合を含む、請求項９に記載の方法。
【請求項１１】
集合メンバーシップに従って、前記複数のデータ項目の少なくとも一つを用いて、前記集約データ項目をポピュレートする工程を含む、請求項９又は１０に記載の方法。
【請求項１２】
前記集約データ項目をポピュレートする前記工程が、
（ａ）前記複数のデータ項目の少なくとも一つ、
（ｂ）別の集約データ項目を含む一つ以上の派生属性
のうちの一つ以上にルールを適用することによって、前記集約データ項目をポピュレートする工程を含む、請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
前記情報を生成する前記工程が、
ａ）前記データ項目の識別子、
ｂ）前記派生属性の識別子、
ｃ）前記データ項目の値、
ｄ）前記派生属性の値
のうちの一つ以上を前記情報に含める工程を含む、請求項９〜１２のいずれか一項に記載の方法。
【請求項１４】
情報を生成する前記工程が、前記情報内における前記識別子及び前記値の順序を決定する工程を含む、請求項１２又は１３に記載の方法。
【請求項１５】
情報の概念表現を構築する工程を更に含み、
前記概念表現が、
（ａ）前記複数のデータ項目、
（ｂ）一つ以上の派生属性、
（ｃ）一つ以上のルールの以前の反復において評価された一つ以上の結論
のうちの一つ以上の解析に基づいて前記決定支援システムのルールを評価することにより与えられる結論であり、結論の構築が前記ルールの連続する再評価において行われる、請求項１〜１４のいずれか一項に記載の方法。
【請求項１６】
前記方法が、結論を構築する工程を更に含み、
結論の構築が、ルール評価の反復において行われ、
連続する各ルール評価が、以前のルール評価において構築された結論を利用する、請求項１〜１５のいずれか一項に記載の方法。
【請求項１７】
前記概念表現が、解釈部分を含み、
前記解釈部分が、一つ以上の集約データ項目に対する演算を表し、前記一つ以上の集約データ項目に対する前記演算が、
（ａ）前記一つ以上の集約データ項目を構成するデータ項目の数、
（ｂ）前記一つ以上の集約データ項目が空かどうか、
（ｃ）前記一つ以上の集約データ項目が特定のデータ項目を含むかどうか、
（ｄ）他の任意の集合演算
のうちの一つ以上を決定することを含む、請求項１５又は１６に記載の方法。
【請求項１８】
前記情報を生成する前記工程が、前記解釈部分から情報を生成する、請求項１７に記載の方法。
【請求項１９】
前記情報を生成する前記工程が、
ａ）一つ以上の派生属性、
ｂ）一つ以上の結論
のうちの一つ以上に一つ以上のルールを適用する反復処理を含む、請求項１〜１８のいずれか一項に記載の方法。
【請求項２０】
前記一つ以上のルールが、リップルダウンルール知識システムの少なくとも一部を成すことができる、請求項１２〜１９のいずれか一項に記載の方法。
【請求項２１】
（ａ）派生属性の階層構造を反復的に評価する工程と、
（ｂ）リップルダウンルールを使用して繰り返し推論を行って、一つ以上の最終結論に到達する工程と、
（ｃ）前記情報を生成する際に、一つ以上の最終結論を使用する工程と
を含む、請求項１〜２０のいずれか一項又は複数項に記載の方法。
【請求項２２】
前記テキスト情報が、任意の人間が読める情報である、請求項１〜２１のいずれか一項に記載の方法。
【請求項２３】
前記テキスト情報が、構文法的及び／又は文法的に正しい、請求項１〜２２のいずれか一項に記載の方法。
【請求項２４】
前記テキスト情報が、一つ以上のルールによって決定される言語で表現される、請求項２２又は２３に記載の方法。
【請求項２５】
ａ）一つ以上のデータ項目識別子、
ｂ）一つ以上のデータ項目値、
ｃ）一つ以上の派生属性識別子、
ｄ）一つ以上の派生属性値、
ｅ）一つ以上の結論
のうちの一つ以上を、前記一つ以上のルールによって決定される前記言語に翻訳する副工程を含む、請求項２４に記載の方法。
【請求項２６】
前記テキスト情報が、レポートの少なくとも一部を成す、請求項１〜２５のいずれか一項に記載の方法。
【請求項２７】
前記機械命令が、一つ以上のルールによって決定される命令フォーマットで表現される、請求項１〜２６のいずれか一項に記載の方法。
【請求項２８】
複数のデータ項目から情報を生成するシステムであって、
（ａ）プリプロセッサであって、
ｉ．前記複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．前記複数のデータ項目から一つ以上の他の派生属性を構築する
プリプロセッサと、
（ｂ）前記派生属性を使用して前記情報を生成する情報生成器と
を備え、
前記情報生成器が、決定支援システムの少なくとも一部を成し、
前記集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、前記情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
生成された前記情報が、以下のグループ
ｉ．テキスト情報
ｉｉ．機械命令
のうちの一つ以上に属する、システム。
【請求項２９】
前記プリプロセッサが、派生属性を反復的に構築することができる、請求項２８に記載のシステムであって、該派生属性は、反復処理において以前に定められた派生属性を使用する派生属性である、請求項２８に記載のシステム。
【請求項３０】
前記情報生成器が、結論を反復的に構築することができる、請求項２８又は２９に記載のシステムであって、該結論の構築が、反復処理において以前に定められた結論を使用するルールを使用して行われる、請求項２８又は２９に記載のシステム。
【請求項３１】
前記派生属性が、
（ａ）集約データ項目、
（ｂ）テキスト要約器属性、
（ｃ）複数のデータ項目から一つ以上の上位概念データ項目を抽出し、それによりデータ複雑性を低減するデータ前処理の任意の他の結果
のうちの一つ以上である、請求項２８〜３０のいずれか一項に記載のシステム。
【請求項３２】
複数のデータ項目を受け取る受信機を更に備える請求項２９〜３１のいずれか一項に記載のシステム。
【請求項３３】
（ａ）集約データ項目、
（ｂ）一つ以上のルール、
（ｃ）他の派生属性、
（ｄ）一つ以上の結論、
（ｅ）複数のデータ項目から一つ以上の上位概念データ項目を抽出し、それによりデータ複雑性を低減するデータ前処理の任意の他の結果、
（ｆ）解釈部分を定める際に使用される任意の他の概念表現
のうちの一つ以上を定義するビルダーを更に備える請求項２９〜３２のいずれか一項に記載のシステム。
【請求項３４】
前記システムが、送信機を更に備え、前記送信機が、前記生成された情報を
ａ）機械、
ｂ）受取人
のうちの一つ以上に送る、請求項２９〜３３のいずれか一項に記載のシステム。
【請求項３５】
請求項１〜３４のいずれか一項に記載の方法に従う方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラム。
【請求項３６】
請求項３５の前記コンピュータプログラムに従うコンピュータプログラムを提供するコンピュータ可読媒体。
【請求項３７】
実質的に添付の図面を参照して本明細書で説明された方法。
【請求項３８】
実質的に添付の図面を参照して本明細書で説明されたシステム。
【請求項１】
複数のデータ項目から情報を生成する方法であって、
（ａ）前記複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートする工程と、
（ｂ）前記集約データ項目を使用して前記情報を生成する工程と
を含み、
前記集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、前記情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
情報を生成する当該方法が、決定支援システムによって実行され、
生成された前記情報が、以下のグループ
ｉ．テキストの情報、
ｉｉ．機械命令
のうちの一つ以上に属する、方法。
【請求項２】
前記複数のデータ項目を前処理して、前記複数のデータ項目から一つ以上の派生属性を抽出し、それによりデータ複雑性を低減する前工程を含む、請求項１に記載の方法。
【請求項３】
データの前記前処理が反復して行われ、一つ以上の派生属性が、以前の反復において構成された派生属性から抽出される、請求項１又は２に記載の方法。
【請求項４】
前記式が、以下の考慮事項のうちの一つ以上に基づく、請求項１〜３のいずれか一項に記載の方法。
（ａ）前記複数のデータ項目の識別子、
（ｂ）一つ以上の派生属性の識別子、
（ｃ）前記複数のデータ項目の値、
（ｄ）前記一つ以上の派生属性の値、
（ｅ）一つのデータ項目の複数のインスタンスの値、ここで、前記複数のデータ項目の複数のインスタンスは、
ｉ．時間ベースのシーケンス、
ｉｉ．他の任意のベクトルフォーマット
で与えられる、
（ｆ）前記派生属性の複数のインスタンスの値、ここで、前記派生属性の複数のインスタンスは、
ｉ．時間ベースのシーケンス、
ｉｉ．他の任意のベクトルフォーマット
で与えられる。
【請求項５】
前記派生属性が、
（ａ）集約データ項目、
（ｂ）テキスト要約器属性、
（ｃ）複数のデータ項目から一つ以上の上位概念データ項目を抽出し、それによりデータ複雑性を低減するデータ前処理の任意の他の結果
のうちの一つ以上である、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
（ｃ）における前記複数のデータ項目が、複数の派生属性である、請求項５に記載の方法。
【請求項７】
前記テキスト要約器属性は、キータームの一つ以上のシーケンスを一つのキーコンセプトにマッピングし、
キータームは、自由形式テキストから情報を抽出できるように、自由形式テキストの断片を表す正規表現である、請求項５又は６に記載の方法。
【請求項８】
各キーコンセプトが、
（ａ）前記決定支援システムにおける派生属性であるターゲット、
（ｂ）照合用形式によって選択された自由形式テキストの断片に関して、前記ターゲットの一つ以上の値を定める抽出式、及び
（ｃ）照合用形式のリストであって、各照合用形式がキータームのシーケンスである、照合用形式のリスト
を含む、請求項７に記載の方法。
【請求項９】
データ項目の一つ以上の集合を識別する前工程を備える請求項１〜８のいずれか一項に記載の方法であって、前記集合のメンバーシップ（集合メンバーシップ）が、
（ａ）データ項目識別子、
（ｂ）データ項目値、
（ｃ）データ項目種類、
（ｄ）データ項目の他の特性
のうちの一つ以上によって決定され、
集合メンバーシップが、個々のデータ項目から集約データ項目へのマッピングを可能にする、請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
前記データ項目の前記集合が、派生属性の集合を含む、請求項９に記載の方法。
【請求項１１】
集合メンバーシップに従って、前記複数のデータ項目の少なくとも一つを用いて、前記集約データ項目をポピュレートする工程を含む、請求項９又は１０に記載の方法。
【請求項１２】
前記集約データ項目をポピュレートする前記工程が、
（ａ）前記複数のデータ項目の少なくとも一つ、
（ｂ）別の集約データ項目を含む一つ以上の派生属性
のうちの一つ以上にルールを適用することによって、前記集約データ項目をポピュレートする工程を含む、請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
前記情報を生成する前記工程が、
ａ）前記データ項目の識別子、
ｂ）前記派生属性の識別子、
ｃ）前記データ項目の値、
ｄ）前記派生属性の値
のうちの一つ以上を前記情報に含める工程を含む、請求項９〜１２のいずれか一項に記載の方法。
【請求項１４】
情報を生成する前記工程が、前記情報内における前記識別子及び前記値の順序を決定する工程を含む、請求項１２又は１３に記載の方法。
【請求項１５】
情報の概念表現を構築する工程を更に含み、
前記概念表現が、
（ａ）前記複数のデータ項目、
（ｂ）一つ以上の派生属性、
（ｃ）一つ以上のルールの以前の反復において評価された一つ以上の結論
のうちの一つ以上の解析に基づいて前記決定支援システムのルールを評価することにより与えられる結論であり、結論の構築が前記ルールの連続する再評価において行われる、請求項１〜１４のいずれか一項に記載の方法。
【請求項１６】
前記方法が、結論を構築する工程を更に含み、
結論の構築が、ルール評価の反復において行われ、
連続する各ルール評価が、以前のルール評価において構築された結論を利用する、請求項１〜１５のいずれか一項に記載の方法。
【請求項１７】
前記概念表現が、解釈部分を含み、
前記解釈部分が、一つ以上の集約データ項目に対する演算を表し、前記一つ以上の集約データ項目に対する前記演算が、
（ａ）前記一つ以上の集約データ項目を構成するデータ項目の数、
（ｂ）前記一つ以上の集約データ項目が空かどうか、
（ｃ）前記一つ以上の集約データ項目が特定のデータ項目を含むかどうか、
（ｄ）他の任意の集合演算
のうちの一つ以上を決定することを含む、請求項１５又は１６に記載の方法。
【請求項１８】
前記情報を生成する前記工程が、前記解釈部分から情報を生成する、請求項１７に記載の方法。
【請求項１９】
前記情報を生成する前記工程が、
ａ）一つ以上の派生属性、
ｂ）一つ以上の結論
のうちの一つ以上に一つ以上のルールを適用する反復処理を含む、請求項１〜１８のいずれか一項に記載の方法。
【請求項２０】
前記一つ以上のルールが、リップルダウンルール知識システムの少なくとも一部を成すことができる、請求項１２〜１９のいずれか一項に記載の方法。
【請求項２１】
（ａ）派生属性の階層構造を反復的に評価する工程と、
（ｂ）リップルダウンルールを使用して繰り返し推論を行って、一つ以上の最終結論に到達する工程と、
（ｃ）前記情報を生成する際に、一つ以上の最終結論を使用する工程と
を含む、請求項１〜２０のいずれか一項又は複数項に記載の方法。
【請求項２２】
前記テキスト情報が、任意の人間が読める情報である、請求項１〜２１のいずれか一項に記載の方法。
【請求項２３】
前記テキスト情報が、構文法的及び／又は文法的に正しい、請求項１〜２２のいずれか一項に記載の方法。
【請求項２４】
前記テキスト情報が、一つ以上のルールによって決定される言語で表現される、請求項２２又は２３に記載の方法。
【請求項２５】
ａ）一つ以上のデータ項目識別子、
ｂ）一つ以上のデータ項目値、
ｃ）一つ以上の派生属性識別子、
ｄ）一つ以上の派生属性値、
ｅ）一つ以上の結論
のうちの一つ以上を、前記一つ以上のルールによって決定される前記言語に翻訳する副工程を含む、請求項２４に記載の方法。
【請求項２６】
前記テキスト情報が、レポートの少なくとも一部を成す、請求項１〜２５のいずれか一項に記載の方法。
【請求項２７】
前記機械命令が、一つ以上のルールによって決定される命令フォーマットで表現される、請求項１〜２６のいずれか一項に記載の方法。
【請求項２８】
複数のデータ項目から情報を生成するシステムであって、
（ａ）プリプロセッサであって、
ｉ．前記複数のデータ項目の少なくとも一つを用いて集約データ項目をポピュレートし、かつ
ｉｉ．前記複数のデータ項目から一つ以上の他の派生属性を構築する
プリプロセッサと、
（ｂ）前記派生属性を使用して前記情報を生成する情報生成器と
を備え、
前記情報生成器が、決定支援システムの少なくとも一部を成し、
前記集約データ項目が、派生属性の一形式であり、
一つの派生属性は、前記複数のデータ項目から一つ以上の上位概念が抽出され、それにより、前記情報を生成する際に、凝縮された量のより関連するデータを検討できるように、式を使用して前記複数のデータ項目から構築されるデータ項目であり、
生成された前記情報が、以下のグループ
ｉ．テキスト情報
ｉｉ．機械命令
のうちの一つ以上に属する、システム。
【請求項２９】
前記プリプロセッサが、派生属性を反復的に構築することができる、請求項２８に記載のシステムであって、該派生属性は、反復処理において以前に定められた派生属性を使用する派生属性である、請求項２８に記載のシステム。
【請求項３０】
前記情報生成器が、結論を反復的に構築することができる、請求項２８又は２９に記載のシステムであって、該結論の構築が、反復処理において以前に定められた結論を使用するルールを使用して行われる、請求項２８又は２９に記載のシステム。
【請求項３１】
前記派生属性が、
（ａ）集約データ項目、
（ｂ）テキスト要約器属性、
（ｃ）複数のデータ項目から一つ以上の上位概念データ項目を抽出し、それによりデータ複雑性を低減するデータ前処理の任意の他の結果
のうちの一つ以上である、請求項２８〜３０のいずれか一項に記載のシステム。
【請求項３２】
複数のデータ項目を受け取る受信機を更に備える請求項２９〜３１のいずれか一項に記載のシステム。
【請求項３３】
（ａ）集約データ項目、
（ｂ）一つ以上のルール、
（ｃ）他の派生属性、
（ｄ）一つ以上の結論、
（ｅ）複数のデータ項目から一つ以上の上位概念データ項目を抽出し、それによりデータ複雑性を低減するデータ前処理の任意の他の結果、
（ｆ）解釈部分を定める際に使用される任意の他の概念表現
のうちの一つ以上を定義するビルダーを更に備える請求項２９〜３２のいずれか一項に記載のシステム。
【請求項３４】
前記システムが、送信機を更に備え、前記送信機が、前記生成された情報を
ａ）機械、
ｂ）受取人
のうちの一つ以上に送る、請求項２９〜３３のいずれか一項に記載のシステム。
【請求項３５】
請求項１〜３４のいずれか一項に記載の方法に従う方法を実施するようにコンピュータを制御する命令を含むコンピュータプログラム。
【請求項３６】
請求項３５の前記コンピュータプログラムに従うコンピュータプログラムを提供するコンピュータ可読媒体。
【請求項３７】
実質的に添付の図面を参照して本明細書で説明された方法。
【請求項３８】
実質的に添付の図面を参照して本明細書で説明されたシステム。
【図５】
【図６】
【図７】
【図８】
【図９】
【図２１】
【図１】
【図２】
【図３】
【図４】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図６】
【図７】
【図８】
【図９】
【図２１】
【図１】
【図２】
【図３】
【図４】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１２−８４１０９（Ｐ２０１２−８４１０９Ａ）
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２８８３６５（Ｐ２０１０−２８８３６５）
【出願日】平成２２年１２月２４日（２０１０．１２．２４）
【出願人】（５１０３４１６２８）パシフィック ノレッジ システムズ ピーティーワイ リミテッド (1)
【Ｆターム（参考）】
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願番号】特願２０１０−２８８３６５（Ｐ２０１０−２８８３６５）
【出願日】平成２２年１２月２４日（２０１０．１２．２４）
【出願人】（５１０３４１６２８）パシフィック ノレッジ システムズ ピーティーワイ リミテッド (1)
【Ｆターム（参考）】
[ Back to top ]