JP4959655B2

JP4959655B2 - 高性能ルールエンジン

Info

Publication number: JP4959655B2
Application number: JP2008235600A
Authority: JP
Inventors: クリスティアン・ブレラーゲ; トビアス・リーケ; カールステン・ツィーグラー
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2007-10-15
Filing date: 2008-09-12
Publication date: 2012-06-27
Anticipated expiration: 2028-09-12
Also published as: US7937354B2; US20090099994A1; JP2009099133A

Description

本開示は、一般に、プロセスモデリングに関する。

ルールエンジンを使用すると、プロセスの実行ロジックをわかりやすい、宣言的方法でモデル化することができる。例えば、ビジネスルールエンジンは、ビジネスプロセスの実行ロジックを処理する。高い敏しょう性と柔軟性を実現するために、ビジネスルール管理システム(BRMS)では、ビジネス関係アプリケーションロジックを他のタイプのアプリケーションロジックから分離し、ビジネスプロセスモデルへの変更が容易に実装できるように、また、そのような変更が専門的プログラミング能力を必ずしも必要としないようにする。これらのBRMSは、例えば、公共部門、金融機関、保険業務などにおいて使用される。

外部ルールエンジンとデータをやり取りするために、ローカルルールエンジンは、語彙(ビジネス語彙(BV)、ルールエンジン語彙、または中間語彙と呼ばれる)を外部ルールエンジンとやり取りするが、ただし、語彙は、ローカルルールエンジンと外部ルールエンジンとの間でやり取りされるデータのフォーマット、型、記述、または構造を規定する。語彙は、外部ルールエンジンが受け取ったコンテキストが適切に処理され、ローカルルールエンジンが受け入れる適切なフォーマットおよび構造を応答が備えるように、ルールを定義するために外部ルールエンジンにより使用される。

一般的な一実装によれば、外部ビジネスルールエンジンの入力および出力をそれぞれ定義するコンテキスト記述および結果記述を含むBVは、汎用データ構造を使用することに基づき、自動的に生成され、コンテキスト記述は、さらに、外部ビジネスルールエンジンに固有のコンテキストデータ型を含む。外部ビジネスルールエンジンとの接続を含む表現式が定義され、BVは、外部ビジネスルールエンジンで受け取ったときにコンテキスト記述および結果記述に基づきビジネスルールを定義することを可能にする拡張マークアップ言語(XML)スキーマ文書(XSD)においてシリアル化される。スキーマ文書は、リモートプロシージャコールを使用して外部ビジネスルールエンジンに接続を介して伝送され、コンテキスト記述に従って指定されたコンテキストは、表現式に渡される。コンテキストは、ビジネスルールによる評価のため、接続を介して入力として外部ビジネスルールエンジンに伝送され、結果記述に従って指定されたビジネスルール評価結果は、接続を介して外部ビジネスルールエンジンの出力として受け取られ、結果が出力される。

他の一般的な実装によれば、方法は、ルールによる評価のため外部ルールエンジンに伝送されるコンテキスト、および外部ルールエンジンに伝送される自動生成語彙をシリアル化するスキーマ文書に基づき、外部ルールエンジンから受け取ったルール評価結果を出力するステップを含む。スキーマ文書では、語彙に含まれるコンテキスト記述および結果記述に基づいてビジネスルールを定義し、コンテキストおよび結果は、それぞれ、コンテキスト記述および結果記述に従って指定される。

他の一般的な実装によれば、外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙は、自動生成され、ルールエンジン語彙は、外部ルールエンジンにより受け取られたときに、コンテキスト記述および結果記述に基づきルールを定義することを可能にするスキーマ文書においてシリアル化され、スキーマ文書は、外部ルールエンジンに伝送される。コンテキスト記述に従って指定されたコンテキストは、ビジネスルールによる評価のため、入力として外部ビジネスルールエンジンに伝送され、結果記述に従って指定されたルール評価結果は、外部ルールエンジンの出力として受け取られ、結果が出力される。

実装は、以下の特徴のうちの1つまたは複数を含むことができる。例えば、ルールエンジン語彙は、フィールド、構造体、またはテーブルデータ要素などの、汎用データ構造を使用することに基づき生成されうる。外部ルールエンジンへの接続を含む表現式が定義され、コンテキストがその表現式に渡され、これにより、スキーマ文書およびコンテキストが、接続を介して伝送され、結果が、接続を介して受け取られるようにできる。表現式を定義するステップは、さらに、ルールエンジンにクエリを実行し、接続パラメータを決定するステップと決定された接続パラメータに基づき可能な表現式のリストから定義済み表現式を選択するステップを含むことができる。コンテキストは、表現式がトリガされた場合に、リモートプロシージャコールを介して外部ルールエンジンに自動的に伝送されうる。結果は、SUN MICROSYSTEMS(登録商標)JAVA(登録商標)プログラミング言語のリモートプロシージャコールなどのリモートプロシージャコールを介して受け取られる。

他の実施例では、コンテキスト記述は、さらに、外部ルールエンジンに固有のコンテキストデータ型を含むことができる。ルールは、コンテキスト記述および結果記述に基づき外部ルールエンジンにおいて定義されうる。スキーマ文書は、XSDとすることができる。外部ルールエンジンは、BRMSなどのビジネスルールエンジンであってよく、ルールエンジン語彙は、BVであってよく、外部ルールエンジンは、ビジネスルールエンジンであってよい。

他の一般的な実装によれば、コンピュータプログラム製品は、機械可読媒体で有形に具現化される。コンピュータプログラム製品は、機械により読み取られたときに、外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙を自動生成し、外部ルールエンジンにより受け取られたときに、コンテキスト記述および結果記述に基づきルールを定義することを可能にするスキーマ文書においてルールエンジン語彙をシリアル化し、スキーマ文書を外部ルールエンジンに伝送するステップをデータ処理装置に行わせる動作をする命令を備える。コンピュータプログラム製品は、さらに、機械により読み取られたときに、コンテキスト記述に従って指定されたコンテキストをルールによる評価のため入力として外部ルールエンジンに伝送し、結果記述に従って指定されたルール評価結果を外部ルールエンジンの出力として受け取り、結果を出力するステップをデータ処理装置に行わせる動作をする命令も含む。

他の一般的な実装によれば、デバイスは、プロセッサ、インターフェース、および出力モジュールを備える。プロセッサは、外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙を自動生成し、外部ルールエンジンにより受け取られたときに、コンテキスト記述および結果記述に基づきルールを定義することを可能にするスキーマ文書においてルールエンジン語彙をシリアル化する。インターフェースは、スキーマ文書を外部ルールエンジンに伝送し、コンテキスト記述に従って指定されたコンテキストをルールによる評価のため、入力として外部ルールエンジンに伝送し、結果記述に従って指定されたルール評価結果を外部ルールエンジンの出力として受け取る。出力モジュールは、結果を出力する。

1つまたは複数の実施形態の詳細は、付属の図面および以下の説明で述べられる。本開示の他の特徴および利点は、説明および図面、さらに請求項から明白になる。

類似の参照番号は、全体を通して対応する部分を表す。

ビジネスプロセスとは、調整された順序で実行される一連のビジネスタスクまたは事業活動のことである。アプリケーションを使用することで、ローカルビジネスルールエンジンにより処理されるビジネスオブジェクトおよび関数を使用して、複数の機能分野に及ぶビジネスプロセスをモデル化することができる。

タスクとは、例えば、ビジネスプロセスフローを分割または結合することにより、活動を記述する、またはビジネスプロセスの制御フローを変更するビジネスプロセスのアトミックコンポーネントのことである。例示的なビジネスプロセスは、専用として割り当てられている開始タスクを備え、専用として割り当てられている終了タスクの前にそれぞれ実行される第1から第3までのタスクを順次実行することができる。特定のいくつかのタスクの実行に際して、パートナー提供の関数またはロジックを備える外部ビジネスルールエンジンを呼び出すことが必要になることがある。

これらの状況の下で、ローカルビジネスルールエンジン(本明細書では、プライマリーもしくは独自ビジネスルールエンジン、または「関数および導出ツール(Function & Derivation Tool)」(FDT)とも呼ばれる)に、外部またはサードパーティ製ビジネスルールエンジン(またはサードパーティ製BRMS)を組み込むことができる。例えば、エンティティは、特定のプラットフォームまたはアプリケーションに対し提供されるか、または最適化される事前に構成されたサードパーティ製給与計算ルール集合にアクセスしたい場合がある。これらの他のビジネスルールエンジンを「外部」と記述することにより、それらのエンジンがプライマリーまたはローカルビジネスルールエンジンと異なることが単に意図される。そのため、ビジネスルールエンジンは、ローカルビジネスルールエンジンと同じ機械上で実行されているか、またはローカルビジネスルールエンジンと同じオペレータに関連付けられている場合であっても、「外部」と称されうる。

外部ルールエンジンとデータをやり取りするために、ローカルルールエンジンは、まず、語彙を外部ルールエンジンとやり取りするが、ただし、語彙は、ローカルルールエンジンと外部ルールエンジンとの間でやり取りされるデータのフォーマット、型、記述、または構造を規定する。語彙は、外部ルールエンジンが受け取った入力データ(または「コンテキスト」)が適切に処理され、出力データ(または「応答」)がローカルルールエンジンに適切なフォーマットおよび構造を備えるように、外部ルールエンジンにおいてルールの定義を可能にするか、定義を行わせるか、または定義を有効にする。この語彙のやり取りに基づき、ルール評価結果データは、ローカルルールエンジンにより容易にインポートされ、さらに処理されうる。

語彙は、コンテキストおよび結果情報を使用して、設計時フェーズにローカルルールエンジンにおいて自動的に生成される。実行時フェーズでは(つまり、外部ルールエンジンでルールを配備または定義した後)、ローカルルールエンジンは、データ(つまり、コンテキスト)を外部ルールエンジンに受け渡すことにより、外部ルールエンジン側で配備されたルールを呼び出すことができる。予想されるコンテキストフォーマット、型、記述、または構造に基づき定義されたルールを使用することで、外部ルールエンジンは、そのルールを使用してコンテキストを受け取り、処理し、結果として得られるデータ集合を適切なフォーマットでローカルルールエンジンに返す。

そうする際に、企業体は、特に公共部門、保険分野、および金融分野における顧客の要求にうまく応じることができる。さらに、ローカルルールエンジンの機能的ギャップが埋められるが、それは、独自もしくは専用ルールエンジンを利用する主要BRMSがそのままローカルルールエンジンにより使用されうるからである。したがって、ユーザーは、特定のFDTにコミットせず、ビジネスプロセスをモデル化する最善のアプローチを採ることができ、これにより、全体的なカスタマーエクスペリエンスを高めることができる。FDTプロデューサーの観点から、BRMSプロバイダは既存のFDTソリューションを強化するように自社製品を手直しすることができるため、サードパーティ製ルールエンジンのシームレスな統合は、そのマーケットポジションも改善することができる。

図1は、高性能ルールエンジンを実装する例示的なシステム100のブロック図である。簡単に言うと、例示的なシステム100は、FDTシステム101およびBRMS102を備え、これらはネットワーク104により接続されている。

SAP(登録商標)NETWEAVER(登録商標)FDTを実装することができる、FDTシステム101は、ビジネスルールを定義し、処理し、包括的なアプリケーションプログラミングインターフェース(API)を使用してデータを出力するローカルルールエンジン105を備える。ローカルルールエンジン105は、ビジネスルールを管理し、自動化するハードウェアまたはソフトウェアモジュールである。BRMS102は、ビジネスルールを定義し、処理し、外部ルール処理の結果をFDTシステム101に出力する外部ルールエンジン106を備える。

例示的な一構成では、外部ルールエンジン106は、ローカルルールエンジン105側で使用またはアクセスを望んでいる場合のある専用の、カスタマイズされた、独自の、または(特許または企業秘密などにより)保護されたビジネスルールを含む。金融コンテキストでは、外部ルールエンジンは、年間所得または支払い滞納などの、最近の顧客の信用記録に関する入力を受け付け、また消費者のプールと突き合わせて消費者を評価する信用度点数を出力する信用度採点関数を備える。FDTシステム101が、モーゲージプロバイダにより運用される場合、その結果得られる信用度点数を、消費者に融資を許可するかどうかを決定するために使用できる。

この実施例では、BRMS102のオペレータは、個人の信用度を人為的に膨らませるおそれのある弱点を企業体が発見するのを防ぐため、信用度点数を導き出すのに外部ルールエンジン106により使用される信用度採点ロジックを公表したくない場合がある。それと同時に、FDTシステム101のオペレータは、ローカルルールエンジン105のユーザーに、信用度が探索されていることを知られたくない、または信用度データにアクセスしようとした場合にユーザーが余計なステップを踏まなければならないようにしたい場合がある。

したがって、本明細書で説明されている高性能アプローチを使用すると、ローカルルールエンジン105は、それ自体FDTシステム101の内部にあるが、外部ルールエンジン106を呼び出す表現式を含む関数を実行することによりBRMS102とシームレスにインターフェースすることができる。説明されている実施例では、この表現式は、顧客を一意に識別するコンテキスト情報を、外部ビジネスルールの定義を補助するか、定義を可能にするか、定義を行わせるか、または定義を有効にする以前に提供されたBVに基づき外部ルールエンジンが容易に理解できるフォーマット、構造、またはデータ型で供給することにより外部ルールエンジンを呼び出すことができる。

外部ルールエンジン106は、ルールを使用してコンテキストを評価または処理し、結果情報(または単に、「結果」)をローカルルールエンジン105が容易に理解できるフォーマット、構造、またはデータ型でローカルルールエンジン105に返す。外部ルールエンジン106により供給される結果は、呼び出される関数に関連付けられているローカルルールエンジン106の表現式(または解析木)により解析され、関数の出力は、結果に基づきFDTシステム101のユーザーに返される。

したがって、「関数および導出ツール」の「関数」は、外部ルールエンジンとの通信をシームレスに呼び出すプレースホールディング表現を使用して外部ルールエンジン106におけるルールベースロジックの処理をトリガすることを指す。「関数および導出ツール」の「導出」は、コンテキスト入力の解析を規定する解析木(または表現式木)を指す。例えば、導出は、結果がすでに受理されたステートメントの当然の帰結であることを示すステートメント(論理学または数学におけるステートメントなど)の順序としてのものであってよい。

同様にして、表現式は、値、関数、トークン、アトム、およびプロシージャの任意の結合とすることができ、他の値を計算し、次いで返す、特定の表現式の型に対する優先順位および関連付けの特定のルールに応じて解釈されうる。同様に、表現式の型は、定義済みのコンテキストに対する優先順位および関連付けのルールを記述するものである。特定のビジネスプロセスを実行するそれぞれのアプリケーションについて、フィルタは、特定の表現式の型、表現式、または関数の使用を制限し、与えられたシナリオにおいて利用可能オブジェクトの量を減らすことができる。

上で推測されるように、関数または表現式への入力は、「コンテキスト」と呼ばれ、表現式の出力(または戻り値)は、「結果」と呼ばれる。コンテキストと結果は両方とも、フィールド、構造体、またはテーブルなどのデータ要素、またはスカラー値、作業領域、ベクトル値などのデータオブジェクトの集合を含むことができ、スカラーは一度に1つの値を保持する変数を指し、ベクトルは、スカラーの集まりである。

例示的な一実施例では、健康保険ビジネスルールをモデル化する関数は、入力として複数の患者名を一覧にしたテーブルを受け付けるか、または入力として単一の患者名を示す単一要素を受け付ける表現式を含むことができる。この関数は、テーブル内に名前が載っている患者が、ビジネスルールを実行するエンティティにより保険を掛けられているかどうかを示す基本データフィールドを出力することができるか、または最近施された医療の日付および説明が載っているテーブルを出力することができる。したがって、「ルール」は、保険金詐欺検出関数、信用度採点関数、または他の説明関数などの特定の関数に割り当てられた表現式または表現式の階層と理解されうる。入力コンテキストに適用される特定のルールは、入力コンテキストの型、記述、または構造によって異なりうる。

他の例示的な一実施例では、「ビジネスオブジェクト」は、それぞれのビジネスプロセスに入力され、ビジネスオブジェクトは、構造モデル、内部プロセスモデル、またはサービスインターフェースにより記述される一意的に識別可能なビジネスコンポーネント、エンティティ、またはデータを表す。例示的なビジネスオブジェクト型は、コアまたはホスティングビジネスオブジェクト(例えば、発注書、顧客請求書要求、または発注書)、複製されたビジネスオブジェクト(例えば、発注書などのコアビジネスオブジェクトに関するプランニング図)、ビジネスオブジェクトテンプレート(例えば、すべての属性を備える製品の最大テンプレート)、従属ビジネスオブジェクト(例えば、アドレスなどの他のビジネスオブジェクトの再利用部分)、ビジネス基礎オブジェクト(例えば、ビジネスパートナーなどの基礎レイヤに置かれるオブジェクト)を含む。

「概念オブジェクト」とは対照的に、「ビジネスオブジェクト」は、エンティティ型を記述し、必ずしもエンティティ自体のインスタンスを記述しない。同様に、従属ビジネスオブジェクトは、他のビジネスオブジェクト内で、または他のビジネスオブジェクトにより(再利用部分として)使用され、ビジネスの観点から、自立し得ない概念を表すビジネスオブジェクトである。従属ビジネスオブジェクトのインスタンスは、ビジネスオブジェクトのコンテキスト中に出現しうるけれども、従属オブジェクトは、ある範囲の埋め込みオブジェクトの構造および関数に関して等価である。

図2は、高性能ビジネスルールエンジンを実装する例示的なプロセス200を示すフローチャートである。簡単に言うと、プロセス200は、
外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙を自動生成するステップと、
外部ルールエンジンにより受け取られたときに、コンテキスト記述および結果記述に基づきルールを定義することを可能にするスキーマ文書においてルールエンジン語彙をシリアル化するステップと、
スキーマ文書を外部ルールエンジンに伝送するステップと
を含む。コンテキスト記述に従って指定されたコンテキストは、ビジネスルールによる評価のため、入力として外部ルールエンジンに伝送され、結果記述に従って指定されたルール評価結果は、外部ルールエンジンの出力として受け取られ、結果が出力される。例示的なプロセス200は、技術およびビジネスルールの処理、実装、および構成のための実行時および保守環境を提供するある種のビジネスルールフレームワーク(BRF)として取り扱うことができる。

さらに詳しく言うと、プロセス200が開始すると(S201)、外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙(またはBV)が、自動的に生成される(S202)。FDTシステム(またはローカルルールエンジンなどのFDTシステムのコンポーネント)がBRMSにアクセスできるようにするため、プレースホールディング表現式(place-holding expression)を使用して外部ルールエンジンでルールベースのロジックの処理をトリガする関数が、ローカルルールエンジン内にモデル化される。そのため、この関数は、外部ルールエンジンにより理解されうるデータ記述でモデル化または指定されなければならない。したがって、適切なデータを関数の呼び出しに基づき外部ルールエンジンに伝送できる。

ローカルルールエンジンは、多数の異なるデータオブジェクト記述をサポートしている。例えば、表1は、例示的なローカルルールエンジンによりサポートされている異なる型の「データ要素」データオブジェクトの一覧であり、表2は、例示的なローカルルールエンジンによりサポートされている異なる型の「構造体」データオブジェクトの一覧である。なお、構造体とは、一般に、類似の型のデータ要素のリストのことである。データ要素および構造体に加えて、例示的なローカルルールエンジンは、さらに、テーブルデータオブジェクトもサポートすることができ、これは(構造体のように)、類似の型のデータ要素のリストを含むが、(構造体とは異なり)定義済みのヘッダを含む。

したがって、語彙は、予想されるコンテキストおよび結果のそれぞれについて、予想されるコンテキストおよび結果のデータ型を含む記述を含まなければならない。例えば、語彙は、予想されるコンテキスト(または入力)が、型ELEMENT_TEXTの患者名、または型ELEMENT_NUMBERの患者識別番号、または型ELEMENT_CURRENCYの予想される治療費でありうると記述することができる。予想される結果(または出力)も、同様に記述されうる。関数の予想される入力および出力は、FDTシステムに知られているので、FDTシステムは、特定の関数の予想される入力および出力を参照することにより外部ルールエンジンへのエクスポートのため専用のBVを自動的に生成することができる。特に、語彙は、設計時フェーズに用意されるコンテキストに基づくので、ルールエンジンが過去の通信に基づきテンプレートまたはスキーマを導出する必要はない。

コンテキスト記述は、外部ルールエンジンに固有のデータ型とすることができる。例えば、語彙は、フィールド、構造体、またはテーブルデータオブジェクトなどの、汎用データオブジェクトを使用して自動的に生成されうる。そうする際に、語彙は、ローカルルールエンジンと外部ルールエンジンとの間の論議領域を定義する基本言語構成要素を指定するために使用されうる。この点に関して、語彙は、ローカルルールエンジンと外部ルールエンジンとの間でやり取りされるコンテキストおよび結果の意図されたフォーマット、型、または構造の公開された記述として取り扱うことができる。

簡単に先を参照すると、図3は、例示的なローカルルールエンジンデータ型同士の関係を示す。CL_FDT_ELEMENTクラス301、CL_FDT_STRUCTUREクラス302、およびCL_TABLEクラス304は、それぞれ、汎用の方法および属性を定義し、実装する、要約CL_FDT_OBJECTクラス305からの特性および関数を継承する。CL_FDT_OBJECTクラス305は、管理データ307およびトランザクション処理を取り扱う、CL_FDT_MAINTENANCEクラスからの特性および関数を継承する。最上位のIF_FDT_ADMIN_DATAインターフェース307は、管理方法および属性への構造化されたアクセスを行うため、さまざまな属性を1つのインターフェースに集中させる。

図2を参照すると、外部ルールエンジンとの接続を含む表現式は、ローカルルールエンジンを外部エンジンに論理的に接続するようにモデル化されるか、指定されるか、または他の何らかの方法で定義され(S204)、これにより、コンテキストおよび結果のデータ呼び出しの通信が可能になる。接続は、ローカルルールエンジン内部ルール処理アプローチを使用して、ローカルルールエンジンを外部ルールエンジンとシームレスに統合できるようにするプレースホルダEXTERNAL BRMS表現式として定義される。ローカルルールエンジンのユーザーは、外部呼び出しをアラートされないため、複雑さと統合費用が低減される。

ローカルルールエンジンは、インスタンス定数表現式サブクラス、決定テーブル表現式サブクラス、決定木表現式サブクラス、表現式サブクラス、および関数呼び出し表現式サブクラスなどの汎用表現式サブクラスとともに、ローカルルールエンジンと外部ルールエンジンとの間の通信を可能にする上述のEXTERNAL BRMS表現式サブクラスを備えることができる。EXTERNAL BRMS表現式サブクラスは、例えば、外部ルールエンジンとの通信のため一般的に使用されるパラメータおよび関数呼び出しをカプセル化する要約GENERIC BRMS CONNECTORクラスへの関連付けを含むことができる。したがって、EXTERNAL BRMS表現式インスタンスは、外部ルールエンジンでルールがいったん定義された後、ローカルルールエンジンを外部ルールエンジンに接続するために、ローカルルールエンジンにおいて表現式木内で選択されるか、作成されるか、指定されるか、または他の何らかの方法で定義される(以下参照、S207)。

表現式を定義するステップは、さらに、ルールエンジンにクエリを実行し、接続パラメータを決定するステップと決定された接続パラメータに基づき可能な表現式のリストから定義済み表現式を選択するステップを含むことができる。EXTERNAL BRMS表現式サブクラスは、EXECUTE()、CLOSE()、およびGETPARAMETERS()関数を含むことができ、これらの関数により、リフレクティブプログラミングを使用して、接続パラメータを決定し、さまざまな外部ルールエンジンアプリケーションプラットフォームサブクラス同士を区別することができる。例えば、GETPARAMETERS()関数を使用することで、ローカルルールエンジンは、外部ルールエンジンがJAVA(登録商標)アダプタを使用すると決定し、外部ルールエンジンのJAVA(登録商標) Adapterと通信するために使用されるパラメータおよび関数呼び出しをカプセル化するJAVA(登録商標) BRMSコネクタを実装するEXTERNAL BRMS表現式を指定することができる。

ルールエンジン語彙は、スキーマ文書内にシリアル化またはパッケージされ(S205)、このスキーマ文書はXSDであってよい。スキーマ文書に含まれるのは、外部ルールエンジンに供給されるように、自動的に生成された(上記参照、S202)コンテキストおよび結果定義もしくは記述である。コンテキストまたは結果は、要素、構造体、テーブル、または他の型のデータであってよいので、スキーマ文書では、コンテキストまたは結果がどの型のデータであると予想されるかを識別し、その識別されたデータ型に関連付けられている実行時XML要素を与える。

スキーマ文書は、そのスキーマに従って「有効」であると取り扱われるように文書が準拠しなければならないルールの集合を表す。この点に関して、RELAX NG、文書型定義(DTD)、またはスキマトロンなどの他のスキーマ文書言語もしくはアプローチは、XSDに対する補助機能として置き換えられるか、または使用されうる。スキーマ文書においてシリアル化された語彙を使用することで、語彙内に符号化された条件および関係に基づきルールを定義することができる。

図4は、例示的なスキーマ文書401に関連付けられている複数のレイヤを示す。ローカルルールエンジン402は、独自のデータオブジェクト、汎用もしくは標準化されたデータオブジェクト、またはABAPもしくは他のデータオブジェクトなどのさまざまな形のデータを外部ルールエンジン404に渡すことができるため、スキーマ文書401は、それ自体、関連付けられているデータの正確な特徴付けをサポートするためにそれらの関連付けられているデータオブジェクトのそれぞれを認識しなければならない。そうするためには、スキーマ文書401は、ローカルルールエンジンが伝達することができるデータオブジェクトの型を指定するデータ型コンポーネント405(FDT_BVSCHEMA.XSD)を(<INCLUDE>要素を介して)含まなければならない。

スキーマ文書401は、さらに、標準コンポーネント406(W3C XMLスキーマなど)だけでなく、ビジネスコンテキスト名を指定し、追加のデータ構成要素を定義するために標準コンポーネント406を拡張するスキーマ拡張コンポーネント407(FDT_TYPES.xsD)も組み込まなければならない。スキーマ拡張コンポーネント407は、スキーマ文書402により第2の名前空間として(<IMPORT>要素を介して)インポートされうる。上に示されているように、スキーマ文書401は、設計時フェーズ409においてローカルルールエンジン402から外部ルールエンジン404に伝送される。以下でさらに詳しく説明されるように(以下参照、S209からS211)、スキーマ文書401は、外部ルールエンジン404でルールを定義するための基盤として使用され、ルールは、語彙に従ってローカルルールエンジン402により生成されるコンテキスト411を処理し、結果412を出力するために実行時フェーズ410において使用される。

以下の表3は、スキーマ文書例の一部を示している。表3では、参照しやすいように、行番号が追加されている。

表3に示されている例示的なスキーマ文書において、行01は、使用されているXMLのバージョン(バージョン1.0)を指定するXML宣言であり、行02で、XS:SCHEMA要素を開き、行03から05で、目的の名前空間を定義する。行07で、ビジネスコンテキスト名を指定し、追加のデータ構成要素を定義するよう標準コンポーネントを拡張するスキーマ拡張コンポーネントをインポートする。行07は、ローカルルールエンジンが伝達することができるデータオブジェクトの型を指定するデータ型コンポーネントを含む。行10から15は、型ELEMENT_TEXTの「Patient_Name」コンテキスト要素を定義する。この要素定義から、外部ルールエンジンは、テキストコンテキストデータを予想し、ルールによりさらに評価し処理するために、おそらく患者の名前を入力することになる。

スキーマ文書は、外部ルールエンジンに伝送される(S206)。ルールは、受け取ったスキーマ文書に含まれるコンテキスト記述および結果記述に基づき外部ルールエンジンにおいて定義され、テストされる(S207)。外部ルールエンジンに届いたら、スキーマ文書において、コンテキスト記述および結果記述に基づきルールを定義することができる。したがって、スキーマ文書は、外部ルールエンジンによるルールの定義の基盤を与える。

BVは、FDTコンテキストから導出され、スキーマ文書内に汎用フォーマットで与えられる。設計フェーズにおいて定義され、供給されるBVから、ルールは、設計時フェーズにおいてBRMSにより定義され、実行時フェーズに対し配備される。BVを使用することで、外部ルールエンジンは、インポート関数を使用し、XSDエンティティおよび属性を関連付けることにより、あるいはXSDエンティティに対応するテンプレート、またはXSD属性に対応し、ネストされたエンティティ(高々1つが出現しうる)を参照するようなテンプレートの属性を作成もしくは更新することにより、XMAおよびJAVA(登録商標)テンプレートをリンクする。さらに、外部ルールエンジンは、木構造と異なるXSD関係を表すテンプレート、そのようなテンプレートおよび属性により実装される概念、インポートされたスキーマ文書に対応するテンプレートとその属性との間に存在するような概念の間の関係、またはそのような関係に対する動詞句を作成または更新することができる。

概念、関係、および動詞句は、XMLテンプレートが割り当てられている場合にのみ更新されうる(作成されない)。したがって、既定のXSD-Importウィザードを使用して、概念、関係、および動詞句の初期提供が、行われる場合も行われない場合もある。

コンテキスト記述に従って指定されたコンテキストは、ルールによる評価のため外部ルールエンジンに入力として伝送される(S209)。コンテキストは、表現式がトリガされた場合に、リモートプロシージャコールを介して外部ルールエンジンに自動的に伝送またはエクスポートされうる。コンテキストは、表現式に渡され、これにより、接続を介してスキーマ文書およびコンテキストを伝送させ、接続を介して結果を受け取らせることができる。

実行時フェーズでは、コンテキストは、ローカルルールエンジンで定義されている関数に(データオブジェクトとして)渡され、次いで、コンテキストを表現式木に適用する。関数内に定義されているEXTERNAL BRMS表現式型を使用することで、この関数は、コンテキスト(またはコンテキストの関連する一部)を外部ルールエンジンに供給し、外部ルールエンジンは、コンテキストを処理して、結果を返す。関数は(ローカルルールエンジンにおいて)結果を受け取り、処理して、処理された結果に基づきデータを出力する。コンテキストは、外部ルールエンジンにおいてルールを使用して評価される(S210)。

結果記述に従って指定されたルール評価結果は、外部ルールエンジンの出力として受け取られる(S211)。結果は、SUN MICROSYSTEMS(登録商標)JAVA(登録商標)プログラミング言語のリモートプロシージャコールなどのリモートプロシージャコールを介して受け取られる。

結果が出力され(S212)、それにより、プロセス200を終了する(S214)。結果は、出力に先立って、ローカルでさらに処理されるか、または評価され、人間のオペレータに対し視覚的または聴覚的出力を行うことができるか、またはさらに評価するため他の関数またはプロセスに出力されうる。外部ルールエンジンは、BRMSなどのビジネスルールエンジンであってよく、ルールエンジン語彙は、BVであってよく、外部ルールエンジンは、ビジネスルールエンジンであってよい。上記の信用度採点の実施例では、結果を出力することで、信用度をローカルルールエンジンのオペレータに、もしくはユーザーに出力することができるか、または結果がモデル化されたビジネスプロセスに関して信用度が満足なものであるか、または不満足なものであるかを示す指標を出力することができる。

図5は、高性能ルールエンジンを実装する例示的なシステム500のブロック図である。システム500は、JAVA(登録商標)コネクタであってよい交換インフラストラクチャ504を介して、外部ルールエンジン502aから502n(nは任意の整数を表す)に接続されているローカルルールエンジン501を含む。外部ルールエンジン502aから502nに関連付けられているアプリケーションプラットフォームサブクラスは、JAVA(登録商標) J2SE、JAVA(登録商標) J2EE、C++、Delphi、ABAP、NET、WebService、plain XML、または他のサブクラスを含むことができる。

これらのアプリケーションプラットフォームサブクラスのそれぞれについて、外部ルールエンジンから利用できる接続プロトコルおよび機能を指定するカウンターパート(カウンターパート505aから505n)が、外部ルールエンジン内に実装される。したがって、ローカルルールエンジン501は、このカウンターパート情報を使用してターゲットアプリケーションプラットフォーム用にEXTERNAL BRMS表現式506を自動的にカスタマイズすることができ、これにより、外部ルールエンジン502の開発者によるカスタマイズが行われなくても、さまざまなアプリケーションプラットフォームを使用することができる。

この点に関して、ローカルルールエンジン501は、表現式507を含む、関数にコンテキスト情報を受け渡すことにより外部ルールエンジン502と通信する。表現式507は、要約GENERIC BRMS CONNECTOR 509との関連付けを含む、EXTERNAL BRMS表現式506を含む。GENERIC BRMS CONNECTOR 509は、それぞれ、C++ BRMSコネクタ510a、JAVA(登録商標)コネクタ510b、およびWS-BRMSコネクタ510nを使用して、外部ルールエンジン502aから502nまでのC++アダプタのカウンターパート505a、JAVA(登録商標)アダプタのカウンターパート505b、およびWSアダプタのカウンターパート505nと通信する。

図6は、ローカルルールエンジンにより実装される例示的なクラス構造600を示す図である。標準コンポーネントは、IF_FDT_EXTERNAL_BRMSコンポーネント601、CL_FDT_EXTERNAL_BRMSコンポーネント602、IF_FDT_BRMS_CONNECTIONインターフェースコンポーネント604、CL_FDT_BRMS_CONNECTIONコンポーネント605、IF_FDT_J2SE_BRMS_CONNECTIONインターフェースコンポーネント606、CL_FDT_J2SE_BRMS_CONNECTION永続的コンポーネント607、およびJAVA(登録商標)_Connectorコンポーネント609を含む。拡張コンポーネントは、IF_FDT_TRANSACTIONインターフェースコンポーネント610、IF_FDT_ADMIN_DATAインターフェースコンポーネント611、IF_FDT_EXPRESSIONインターフェースコンポーネント612、およびCL_FDT_EXPRESSIONコンポーネント614を含む。

図7は、外部ルールエンジンにより実装される例示的なJAVA(登録商標)クラス構造700を示す。クラス構造700は、JAVA(登録商標)Connector_IFインターフェースコンポーネント701、BRMS_Connector_IFインターフェースコンポーネント702、JAVA(登録商標)Connectorコンポーネント704、3rdPartyConnectorコンポーネント705、および3rdPartyKnowledgeBaseコンポーネント706を含む。

高性能ルールエンジンの使用例は、健康保険詐欺検出の状況で、図8および9に関して以下で説明される。この実施例では、外部ルールエンジンは、患者または治療データなどのトランザクションデータを評価し、提出された請求書が詐欺的なものかどうかを示す指標を出力する。ローカルルールエンジンは、医師の請求書作成課金システム上で実行され、トランザクションデータを格納するデータベースにアクセスすることができる。

医師は、典型的には、健康保険プロバイダに医療費払戻を請求するために定められた治療を列挙する。治療を受ける患者は、正確を期して健康保険料請求書を見直す訓練を受けてない場合があるため、悪質な医師が、実際に施された以上の治療を請求書に記載することにより偽りの治療の費用を健康保険プロバイダに請求する可能性がある。

健康保険プロバイダは、毎日支払処理のため膨大な量の請求書を受け取るので、請求書の手作業によるチェックは経済的にみて不可能である。そのため、健康保険プロバイダは、自動化されたメカニズムを使用して、論理(「if...then...」)テストを使用し、このタイプの潜在的詐欺をほのめかす不一致について受け取った請求書をチェックする。

健康保険プロバイダに提示される各請求書について、ルールエンジンは、患者の説明される治療個人データに関して、または与えられた時間枠に関して、または単一の請求書に関して各請求書行項目をチェックする。例えば、ルールは、患者が第1の治療を受けた場合に、患者が同じ請求書で第2の治療を受けることになっていないことを指示することができる。他のルールは、患者が第1の治療を受けた場合に、患者が次の15分間で第2および/または第3の治療を受けることになっていないことを指示することができる。さらに他のルールは、患者がリハビリテーション治療を受ける場合に、リハビリテーション治療は手術してから高々14日後に開始しなければならないか、または患者が無料予防健康診断を受ける場合に、患者は男性で、少なくとも30才でなければならないことを指示することができる。

また、ビジネスルールエンジンが備える連鎖機能によりカバーされる、一貫性チェックのための任意の治療構成を作成することができると有益である。外部ルールエンジンは、患者の関連する時間枠(つまり、一貫性チェックが必要な期間)にわたる治療歴全体へのアクセス権を与えられなければならない。さもないと、一貫性チェックを正確に実施することができない場合がある。そのようなものとして、ローカルルールエンジンは、患者の治療歴全体を転送するか(緩く結合されたインテグレーションシナリオにおいて)、または外部ルールエンジンに検索機能を単に備えるだけ(緊密なインテグレーションシナリオにおいて)としてよい。

図8は、外部ルールエンジンに供給される例示的なコンテキストを示すブロック図である。コンテキストは、患者情報801、病歴情報802、治療情報804、および請求書情報805を含むことができる。1人の患者に対する患者情報801は、年齢、保険識別番号、および子供の人数を含むことができる。病歴情報802は、病気発症および/または病気治癒の時間を記述することができる。請求書情報804では、ふつうの治療の場合の請求書日付および請求書番号などの支払いに関する一般的情報を指定する。治療情報804は、1つの請求書および少なくとも1つの疾病に割り当てられる。

ローカルルールエンジンが、患者情報801、病歴情報802、治療情報804、または請求書情報805を外部保険詐欺検出ルールエンジンに提供することができる前に、伝達されうるデータの記述に基づき語彙が生成される。表4から7は、患者情報801、病歴情報802、治療情報804、および請求書情報805に関連付けられているそれぞれの例示的コンテキストに対するデータ記述(データ属性および関連付けられているデータ型を含む)をそれぞれリストしたもので、これにより、ローカルルールエンジンと外部ルールエンジンとの間の論議領域を定義し、記述している。

ローカルルールエンジン内では、データ要素、構造体、およびテーブルの3つのデータオブジェクト型が可能である。データ要素のデータオブジェクト型には、論理型、テキスト型、数値型、金額型、数量型、および時点型がある。構造体データオブジェクトは、データ要素の集合を含み、テーブルは、ヘッダ定義を備える構造体を含む。

図9は、例示的なコンテキストにデータオブジェクトを論理的に適合させるために使用される例示的な論理モデル900を示す。論理モデル900は、コンテキストに関して4つのデータオブジェクト、つまり、請求書および患者を定義するすべての要素を含む請求書見出し901、治療歴内の治療への請求書項目参照904のテーブルを含む請求書項目リスト902、病歴のエントリへの参照キーを持つ、すべての属性を含む治療906のテーブルを含む治療歴905、および疾病909の病歴テーブル907に適合される。

コンテキストは、XSDとして外部ルールエンジンに伝送される。それぞれのXSD要素は、要素の概念名を指定する“appinfo”要素で注釈される。この概念は、ルール定義に使用されうる。表12は、その結果得られるXSD文書の一覧であり、表8から11は、それぞれ、実行時に外部ルールエンジンに渡される請求書見出し、請求書項目リスト、治療歴、および病歴の一覧である。

図10は、他の一般的実装により、高性能ルールエンジンを実装する例示的なシステム1000の外観を示す。簡単に言うと、システム1000は、ローカルルールエンジンを実装するデバイス1001、および外部ルールエンジンを実装するサーバ1002を備える。以下でさらに詳しく説明されているように、デバイス1001は、プロセッサ、インターフェース、および出力モジュールを備える。プロセッサは、外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙を自動生成し、外部ルールエンジンにより受け取られたときに、コンテキスト記述および結果記述に基づきルールを定義することを可能にするスキーマ文書においてルールエンジン語彙をシリアル化する。インターフェースは、スキーマ文書を外部ルールエンジンに伝送し、コンテキスト記述に従って指定されたコンテキストをルールによる評価のため、入力として外部ルールエンジンに伝送し、結果記述に従って指定されたルール評価結果を外部ルールエンジンの出力として受け取る。出力モジュールは、結果を出力する。

さらに詳しく述べると、デバイス1001のハードウェア環境は、テキストおよび画像をユーザーに対し表示する表示モニタ1004、テキストデータおよびユーザーコマンドをデバイス1001に入力するためのキーボード1005、表示モニタ1004上に表示されているオブジェクトを指し示し、選択し、調節するためのマウス1006、固定ディスクドライブ1007、取り外し可能ディスクドライブ1009、テープドライブ1010、ハードコピー出力デバイス1011、およびコンピュータネットワーク接続1012を備える。

表示モニタ1004は、デバイス1001により使用されるソフトウェアアプリケーション、さらにはデバイス1001を操作するのに必要なオペレーティングシステムプログラムのための表示を含むグラフィックス、画像、テキストを表示する。ユーザーは、キーボード1005を使用して、コマンドおよびデータを入力し、コンピュータのオペレーティングシステムプログラム、Webブラウザ、および/またはルールエンジンを操作し、制御する。ユーザーは、デバイス1001上で実行されているデバイス1001およびアプリケーションの対話操作および制御の一環として、マウス1006を使用して、表示モニタ1004上に表示されるグラフィックスおよびテキストオブジェクトを選択し、調節する。マウス1006は、ポインティングデバイスの一種であり、ジョイスティック、トラックボール、タッチパッド、または他のポインティングデバイスであってもよい。

他の実装では、固定ディスクドライブ1007自体が、RAID(「Redundant Array of Independent Disk」)などの、多数の物理的ドライブユニットを備えることができるか、またはディスクドライブファームつまり別のコンピューティングユニット内に物理的に配置されるディスクアレイであってもよい。このようなコンピュータ可読記憶媒体を使用することで、デバイス1001は、取り外し可能および取り外し不可能な記憶媒体に格納されているコンピュータ実行可能プロセスステップ、アプリケーションプログラムなどにアクセスすることができる。

無線または有線コンピュータネットワーク接続1012は、モデム接続、Ethernet(登録商標)を含むローカルエリアネットワーク(「LAN」)接続、またはデジタル加入者回線(「DSL」)、ケーブル高速インターネット接続、ダイヤルアップ接続、T-1回線、T-3回線、光ファイバ接続、または衛星接続などのブロードバンドワイドエリアネットワーク(「WAN」)接続であってよい。ネットワーク1014は、LANネットワーク、企業または政府WANネットワーク、インターネット、または他のネットワークのうちの1つまたは複数であってよい。

コンピュータネットワーク接続1012は、有線または無線コネクタを使用する。例示的な無線コネクタは、例えば、INFRARED DATA ASSOCIATION(登録商標)(「IrDA(登録商標)」)無線コネクタ、光無線コネクタ、INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS(登録商標)(「IEEE(登録商標)」)標準802.11無線コネクタ、BLUETOOTH(登録商標)無線コネクタ、近接場通信(「NFC」)コネクタ、直交周波数分割多重(「OFDM」)超広帯域(「UWB」)無線コネクタ、時間変調超広帯域(「TM-UWB」)無線コネクタ、または他の無線コネクタを含む。例示的な有線コネクタは、例えば、IEEE(登録商標)1394 FIREWIRE(登録商標)コネクタ、ユニバーサルシリアルバス(「USB」)コネクタ、シリアルポートコネクタ、パラレルポートコネクタ、または他の有線コネクタを含む。

取り外し可能ディスクドライブ1009は、デバイス1001からデータをオフロードするか、またはデバイス1001上にデータをアップロードするために使用される取り外し可能記憶デバイスである。取り外し可能ディスクドライブ1009は、フロッピー(登録商標)ディスクドライブ、IOMEGA(登録商標)ZIP(登録商標)ドライブ、コンパクトディスク読み出し専用メモリ(「CD-ROM」)ドライブ、CD-Recordableドライブ(「CD-R」)、CD-Rewritableドライブ(「CD-RW」)、フラッシュメモリ、USBフラッシュドライブ、外付けハードディスクドライブ、サムドライブ、ペンドライブ、キードライブ、高密度デジタル多目的ディスク(「HD-DVD」)光ディスクドライブ、ブルーレイ光ディスクドライブ、ホログラフィックデジタルデータストレージ(「HDDS」)光ディスクドライブ、またはDVD-Recordable(「DVD-R」または「DVD+R」)、DVD-Rewritable(「DVD-RW」または「DVD+RW」)、またはDVD-RAMなどのさまざまな記録可能もしくは書き換え可能なデジタル多目的ディスク(「DVD」)ドライブのうちの1つであってよい。オペレーティングシステムプログラム、アプリケーション、およびさまざまなデータファイルは、ディスク上に格納され、これらは固定ディスクドライブ1007、または取り外し可能ディスクドライブ1009用の取り外し可能媒体上に格納される。

テープドライブ1010は、デバイス1001からデータをオフロードするか、またはデバイス1001上にデータをアップロードするために使用されるテープ記憶装置デバイスである。テープドライブ1010は、1/4インチカートリッジ(「QIC」)、4mmデジタルオーディオテープ(「DAT」)、8mmデジタルリニアテープ(「DLT」)ドライブ、または他のタイプのテープであってよい。

ハードコピー出力デバイス1011は、オペレーティングシステムプログラムおよびアプリケーション用の出力機能を備える。ハードコピー出力デバイス1011は、プリンタ、またはテキストもしくは画像データまたはテキストもしくは画像データのグラフィック表現を含む、有形の出力オブジェクトを出力する出力デバイスであってよい。ハードコピー出力デバイス1011は、デバイス1001に直接接続されているものとして示されているが、そうである必要はない。例えば、ハードコピー出力デバイス1011は、有線または無線ネットワークなどの、ネットワークインターフェースを介してデバイス1001に接続されうる。

さらに、デバイス1001は、図10にデスクトップPCとして例示されているが、他の実装では、デバイス1001は、ラップトップ、ワークステーション、ミッドレンジコンピュータ、メインフレーム、埋め込み型システム、電話機、ハンドヘルドもしくはタブレット型コンピュータ、PDA、またはデータ処理装置を備える他のタイプのデバイスであってよい。

図11は、図10に示されている1つのコンピュータの内部アーキテクチャを例示するブロック図である。コンピューティング環境は、
オペレーティングシステムまたはアプリケーションを含むコンピュータ命令が処理されるコンピュータ中央演算処理装置(「CPU」)1101と、
表示モニタ1004上にグラフィックス、画像、およびテキストをレンダリングするための通信インターフェースおよび処理機能を備える表示インターフェース1102と、
キーボード1005との通信インターフェースを備えるキーボードインターフェース1104と、
マウス1006または同等のポインティングデバイスとの通信インターフェースを備えるポインティングデバイスインターフェース1105と、
ハードコピー出力デバイス1011との通信インターフェースを備えるハードコピー出力デバイスインターフェース1106と、
コンピュータCPU 1101による処理のためコンピュータ命令およびデータが揮発性メモリデバイスに格納される、ランダムアクセスメモリ(「RAM」)1107と、
基本入出力(「I/O」)、起動、またはキーボード1005からのキーストロークを受け取ることなどの基本システム機能の不変な低レベルシステムコードまたはデータが不揮発性メモリデバイス内に格納される、読み取り専用メモリ(「ROM」)1109と、
オペレーティングシステム1111、アプリケーションプログラム1112(必要に応じて、Webブラウザアプリケーション1114、ルールエンジンアプリケーション1115、および他のアプリケーション1116を含む)、およびデータファイル1117を含むファイルが格納される、記憶媒体1110または他の好適なタイプのメモリ(例えば、ランダムアクセスメモリ(「RAM」)、読み取り専用メモリ(「ROM」)、プログラム可能読み取り専用メモリ(「PROM」)、消去可能プログラム可能読み取り専用メモリ(「EPROM」)、電気的消去可能プログラム可能読み取り専用メモリ(「EEPROM」)、磁気ディスク、光ディスク、フロッピー(登録商標)ディスク、ハードディスク、取り外し可能カートリッジ、フラッシュドライブなど)と、
コンピュータネットワーク接続1012上でネットワーク1014との通信インターフェースを備えるコンピュータネットワークインターフェース1119と
を備える。構成要素であるデバイスとコンピュータCPU1101は、コンピュータバス1120上で互いに通信する。

ルールエンジンアプリケーション1115は、SAP(登録商標)ルールエンジン、Workflow Magicルールエンジン、OpenLexiconルールエンジン、OpenRulesルールエンジン、NxBREルールエンジン、Roolsルールエンジン、JBoss Rulesルールエンジン、またはビジネスルールの管理および自動化を補助する他のソフトウェアシステムであってよい。

簡単に言うと、コンピュータプログラム製品は、機械可読記憶媒体1110で有形に具現化される。コンピュータプログラム製品は、機械により読み取られたときに、
外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述を含むルールエンジン語彙を自動生成し、
外部ルールエンジンにより受け取られたときに、コンテキスト記述および結果記述に基づきルールを定義することを可能にするスキーマ文書においてルールエンジン語彙をシリアル化し、
スキーマ文書を外部ルールエンジンに伝送するステップをデータ処理装置(CPU1101など)に行わせる
動作をする命令を備える。コンピュータプログラム製品は、さらに、機械により読み取られたときに、
コンテキスト記述に従って指定されたコンテキストをルールによる評価のため入力として外部ルールエンジンに伝送し、
結果記述に従って指定されたルール評価結果を外部ルールエンジンの出力として受け取り、
結果を出力する
ステップをデータ処理装置に行わせる動作をする命令も含む。

RAM1107は、オペレーティングシステムのアプリケーションプログラムおよびデバイスドライバなどのソフトウェアプログラムの実行時にコンピュータのCPU1101によるRAMへの格納を高速化するようにコンピュータバス1120とインターフェースする。より具体的には、コンピュータCPU1101は、ソフトウェアプログラムを実行するために、コンピュータ実行可能プロセスステップを固定ディスクドライブ1007または他の媒体からRAM1107のフィールド内にロードする。データは、RAM1107に格納され、そこで、実行時にコンピュータCPU1101によりデータがアクセスされる。

さらに図11に示されているように、デバイス1001は、オペレーティングシステム1111のコンピュータ実行可能コード、および文書処理、表計算、プレゼンテーション、ゲーム、Web閲覧、JAVA(登録商標)Scriptエンジン、または他のアプリケーションなどのアプリケーションプログラム1112を格納する。上述の実装を使用して高性能ルールエンジンを実現することも可能であるけれども、本開示による機能をダイナミックリンクライブラリ(「DLL」)として、またはAPPLE SAFARI(登録商標)WebブラウザまたはMICROSOFT(登録商標)INTERNET EXPLORER(登録商標)WebブラウザといったインターネットWebブラウザなどの他のアプリケーションプログラムのプラグインとして実装することも可能である。

コンピュータCPU 1101は、INTELまたはAMD(登録商標)プロセッサ、POWERPC(登録商標)プロセッサ、MIPS(登録商標)縮小命令セットコンピュータ(「RISC」)プロセッサ、SPARC(登録商標)プロセッサ、ACORN(登録商標)RISC Machine(「ARM(登録商標)」)アーキテクチャプロセッサ、HP ALPHASERVER(登録商標)プロセッサ、またはメインフレーム用の専用コンピュータプロセッサを含む、多数の高性能コンピュータプロセッサのうちの1つである。追加の配置において、コンピュータCPU 1101は、高性能ワークステーションおよびサーバに見られる多重CPU構成を含む、複数の演算処理装置、またはメインフレームに見られる多重スケーラブル演算処理装置である。

オペレーティングシステム1111は、INTEL(登録商標)およびPOWERPC(登録商標)ベースのワークステーションおよびサーバ用のAPPLE(登録商標)MAC OS X(登録商標)、MICROSOFT(登録商標)WINDOWS(登録商標) NT/WINDOWS(登録商標)2000/WINDOWS(登録商標)XP Workstation、MICROSOFT(登録商標)WINDOWS(登録商標) VISTA/WINDOWS(登録商標) NT/WINDOWS(登録商標)2000/WINDOWS(登録商標)XP Server、さまざまなUNIX(登録商標)風のオペレーティングシステムIBM(登録商標)ワークステーションおよびサーバ用のAIX(登録商標)、SUN(登録商標)ワークステーションおよびサーバ用のSUNOS(登録商標)、INTEL(登録商標)CPUベースのワークステーションおよびサーバ用のLINUX(登録商標)、HP(登録商標)ワークステーションおよびサーバ用のHP UX WORKLOAD MANAGER(登録商標)、SGI(登録商標)ワークステーションおよびサーバ用のIRIX(登録商標)、Digital Equipment Corporationコンピュータ用のVAX/VMS、HP ALPHASERVER(登録商標)ベースのコンピュータ用のOPENVMS(登録商標)、モバイルデバイス用のSYMBIAN OS(登録商標)、NEWTON(登録商標)、IPOD(登録商標)、WINDOWS(登録商標)MOBILEまたはWINDOWS(登録商標) CE、PALM(登録商標)、NOKIA(登録商標)OS(「NOS」)、OSE(登録商標)、またはEPOC(登録商標)、またはコンピュータもしくは埋め込み型システム用の専用オペレーティングシステムとすることができる。オペレーティングシステム1111用のアプリケーション開発プラットフォームまたはフレームワークは、BINARY RUNTIME ENVIRONMENT FOR WIRELESS(登録商標)(「BREW(登録商標)」)、JAVA(登録商標) Platform、Micro Edition(「JAVA(登録商標) ME」)、またはJAVA(登録商標) 2 Platform、Micro Edition(「J2ME(登録商標)」)、PYTHON(商標)、FLASH LITE(登録商標)、またはMICROSOFT(登録商標).NET Compactであってよい。

図10および11は、高性能ルールエンジンを動作させるように構成されている、プログラムコード、またはプログラムもしくはプロセスステップを実行するコンピューティングシステムの可能な1つの実装を例示しているが、他のタイプのコンピュータも同様に使用することができる。

方式事項に関して、「ユーザー」という用語は、これまで、一貫して、これらのプロセスと相互作用するエンティティを記述するために使用されてきたが、このような一般化は、複数の関係する、もしくは無関係の、生きている、もしくは自動化されたエンティティ、またはさまざまに異なる、重なり合う、または重なり合わない状態でこれらのプロセスと相互作用する生物を記述することも意図されている。

同様の文脈で、「選択」という用語は、全体を通して、人手による選択、非人間による自動選択、またはその何らかの組み合わせを表すことが意図されている。最後に、簡潔にするため、「JAVA(登録商標)」および「JAVA(登録商標)Script」という用語は、SUN MICROSYSTEMS(登録商標)JAVA(登録商標)SCRIPTプログラミング言語を指すことが意図されており、「XML」という用語は、全体を通して「拡張マークアップ言語」を指すことが意図されている。

これで多数の実装が説明された。しかしながら、本開示の範囲から逸脱することなくさまざまな修正を加えることができることは理解されるであろう。したがって、他の実装は、特許請求の範囲内に収まる。

高性能ルールエンジンを実装する例示的なシステムのブロック図である。高性能ルールエンジンを実装する例示的なプロセスを示すフローチャートである。例示的なFDTデータ型同士の関係を示す図である。例示的なスキーマ文書に関連付けられている複数のレイヤを示す図である。高性能ルールエンジンを実装する例示的なシステムのブロック図である。ローカルルールエンジンにより実装される例示的なクラス構造を示す図である。外部ルールエンジンにより実装される例示的なJAVA(登録商標)クラス構造を示す図である。外部ルールエンジンに供給される例示的なコンテキストを示すブロック図である。例示的なコンテキストにデータオブジェクトを適合させるために使用される例示的な論理モデルを示す図である。例示的なシステムの外観を示す図である。図10に示されているデバイスの内部アーキテクチャを例示するブロック図である。

符号の説明

100 システム
101 FDTシステム
102 BRMS
104 ネットワーク
105 ローカルルールエンジン
106 外部ルールエンジン
200 プロセス
301 CL_FDT_ELEMENTクラス
302 CL_FDT_STRUCTUREクラス
304 CL_TABLEクラス
305 要約CL_FDT_OBJECTクラス
307 管理データ
401 スキーマ文書
402 ローカルルールエンジン
404 外部ルールエンジン
405 データ型コンポーネント
406 標準コンポーネント
407 スキーマ拡張コンポーネント
409 設計時フェーズ
410 実行時フェーズ
411 コンテキスト
412 結果
500 システム
501 ローカルルールエンジン
502aから502n 外部ルールエンジン
504 交換インフラストラクチャ
505aから505n カウンターパート
506 EXTERNAL BRMS表現式
507 表現式
509 要約GENERIC BRMS CONNECTOR
510a ++ BRMSコネクタ
510b JAVA(登録商標)コネクタ
510n WS-BRMSコネクタ
600 クラス構造
601 IF_FDT_EXTERNAL_BRMSコンポーネント
602 CL_FDT_EXTERNAL_BRMSコンポーネント
604 IF_FDT_BRMS_CONNECTIONインターフェースコンポーネント
605 CL_FDT_BRMS_CONNECTIONコンポーネント
606 IF_FDT_J2SE_BRMS_CONNECTIONインターフェースコンポーネント
607 CL_FDT_J2SE_BRMS_CONNECTION永続的コンポーネント
609 JAVA(登録商標)_Connectorコンポーネント
610 IF_FDT_TRANSACTIONインターフェースコンポーネント
611 IF_FDT_ADMIN_DATAインターフェースコンポーネント
612 IF_FDT_EXPRESSIONインターフェースコンポーネント
614 CL_FDT_EXPRESSIONコンポーネント
700 JAVA(登録商標)クラス構造
701 JAVA(登録商標)Connector_IFインターフェースコンポーネント
702 BRMS_Connector_IFインターフェースコンポーネント
704 JAVA(登録商標)Connectorコンポーネント
705 3rdPartyConnectorコンポーネント
706 3rdPartyKnowledgeBaseコンポーネント
801 患者情報
802 病歴情報
804 治療情報
805 請求書情報
900 論理モデル
901 請求書見出し
902 請求書項目リスト
904 請求書項目参照
905 治療歴
906 治療
907 病歴テーブル
909 疾病
1000 システム
1001 デバイス
1002 サーバ
1004 表示モニタ
1005 キーボード
1006 マウス
1007 固定ディスクドライブ
1009 取り外し可能ディスクドライブ
1010 テープドライブ
1011 ハードコピー出力デバイス
1012 コンピュータネットワーク接続
1014 ネットワーク
1101 コンピュータ中央演算処理装置(「CPU」)
1102 表示インターフェース
1104 キーボードインターフェース
1105 ポインティングデバイスインターフェース
1106 ハードコピー出力デバイスインターフェース
1107 ランダムアクセスメモリ(「RAM」)
1109 読み取り専用メモリ(「ROM」)
1110 記憶媒体
1111 オペレーティングシステム
1112 アプリケーションプログラム
1114 Webブラウザアプリケーション
1115 ルールエンジンアプリケーション
1116 アプリケーション
1117 データファイル
1119 コンピュータネットワークインターフェース
1120 コンピュータバス

Claims

コンピュータ実装方法であって、
ローカルルールエンジンが実装されたデバイスと、前記デバイスとネットワークにより接続された、外部ルールエンジンが実装されたサーバとを備えたシステムにおいて、
前記ローカルルールエンジンによって、
前記デバイスの記憶装置に記憶された外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述のうち、前記外部ルールエンジンに伝送されるコンテキストに対応するコンテキスト記述および結果記述をルールエンジン語彙として指定するステップと、
スキーマ文書において前記ルールエンジン語彙をシリアル化するステップと、
前記スキーマ文書を前記外部ルールエンジンに伝送するステップと、
前記デバイスの記憶装置に記憶された前記コンテキスト記述に従って指定されたコンテキストを、前記外部ルールエンジンに入力として伝送するステップと、
前記結果記述に従って指定された結果を、前記外部ルールエンジンの出力として受信するステップと、
前記結果を出力するステップと
を含み、
前記結果は、前記サーバの記憶装置に記憶されたビジネスルールに従って、前記外部ルールエンジンが前記コンテキストを処理した結果である、コンピュータ実装方法。
前記ルールエンジン語彙は、汎用データ構造体を使用して表される請求項1に記載の方法。
前記汎用データ構造体は、さらに、フィールド、構造体、またはテーブルデータ要素を含む請求項2に記載の方法。
前記ローカルルールエンジンによって、
前記外部ルールエンジンに伝送されるコンテキストに対応する前記外部ルールエンジンへの接続を含む表現式を定義するステップと、
前記コンテキストを前記表現式に受け渡し、これにより、前記接続を介して前記スキーマ文書および前記コンテキストを伝送させ、前記接続を介して前記結果を受け取らせるステップと
をさらに含む請求項1に記載の方法。
前記表現式を定義するステップは、
前記ルールエンジンにクエリを実行して、接続パラメータを決定するステップと、
前記決定された接続パラメータに基づき可能性のある表現式のリストから前記定義された表現式を選択するステップと
をさらに含む請求項4に記載の方法。
前記コンテキストは、前記表現式がトリガされた場合に、リモートプロシージャコールを介して前記外部ルールエンジンに自動的に伝送される請求項4に記載の方法。
前記結果は、前記リモートプロシージャコールを介して受信される請求項6に記載の方法。
前記リモートプロシージャコールは、SUN MICROSYSTEMS(登録商標)JAVA(登録商標)プログラミング言語のリモートプロシージャコールである請求項6に記載の方法。
前記コンテキスト記述は、さらに、コンテキストデータ型を含む請求項1に記載の方法。
前記コンテキストデータ型は、外部ルールエンジンに固有である請求項9に記載の方法。
前記コンテキスト記述および前記結果記述に基づき前記外部ルールエンジンにおいて前記ルールを定義するステップをさらに含む請求項1に記載の方法。
前記スキーマ文書は、拡張マークアップ言語(XML)スキーマ文書(XSD)である請求項1に記載の方法。
前記外部ルールエンジンは、ビジネスルール管理システム(BRMS)に含まれる請求項1に記載の方法。
前記ルールエンジン語彙は、ビジネス語彙である請求項1に記載の方法。
前記外部ルールエンジンは、ビジネスルールエンジンである請求項1に記載の方法。
前記ルールは、ビジネスルールである請求項1に記載の方法。
機械可読媒体に有形に具現化された、コンピュータプログラムであって、
機械によって読み取られたときに、データ処理装置に、
前記データ処理装置の記憶装置に記憶された外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述のうち、前記外部ルールエンジンに伝送されるコンテキストに対応するコンテキスト記述および結果記述をルールエンジン語彙として指定し、
スキーマ文書において前記ルールエンジン語彙をシリアル化させ、
前記スキーマ文書を前記外部ルールエンジンに伝送させ、
前記データ処理装置の記憶装置に記憶された前記コンテキスト記述に従って指定されたコンテキストを、前記外部ルールエンジンに入力として伝送させ、
前記結果記述に従って指定された結果を、前記外部ルールエンジンの出力として受信させ、
前記結果を出力させる
命令を含み、
前記結果は、前記外部ルールエンジンが実装されたサーバの記憶装置に記憶されたビジネスルールに従って、前記外部ルールエンジンが前記コンテキストを処理した結果である、コンピュータプログラム。
デバイスであって、
前記デバイスの記憶装置に記憶された外部ルールエンジンへの入力および外部ルールエンジンの出力をそれぞれ定義するコンテキスト記述および結果記述のうち、前記外部ルールエンジンに伝送されるコンテキストに対応するコンテキスト記述および結果記述をルールエンジン語彙として指定し、
スキーマ文書において前記ルールエンジン語彙をシリアル化する
ように構成されたプロセッサと、
前記スキーマ文書を前記外部ルールエンジンに伝送し、
前記デバイスの記憶装置に記憶された前記コンテキスト記述に従って指定されたコンテキストを、前記外部ルールエンジンに入力として伝送し、
前記結果記述に従って指定された結果を、前記外部ルールエンジンの出力として受信する
ように構成されたインターフェースと、
前記結果を出力するように構成された出力モジュールと
を備え、
前記結果は、前記外部ルールエンジンが実装されたサーバの記憶装置に記憶されたビジネスルールに従って、前記外部ルールエンジンが前記コンテキストを処理した結果である、デバイス。