(57)【要約】  処理エンジン、データベース、およびルールエンジンと通信したアプリケーションによって生成されるルールと関連する事実の集合とを処理するためのシステムと方法と媒体が記載されており、処理エンジン、データベース、およびルールエンジンは、ルールを考慮して事実の集合を処理し、アプリケーションに対する１つ以上のルールに依存したレスポンスを生成し、アプリケーションはそのレスポンスに基づいて１つ以上のワークフローを行う。ルールエンジンは、ルールと事実を処理するために、前向き連鎖、後向き連鎖、または前向き連鎖と後向き連鎖の組み合わせを適用することもある。処理エンジン、データベース、およびルールエンジンと協働して作動する無数の新しいアプリケーションも記載されている【選択図】図１０
2016505953.tif 000002
【特許請求の範囲】
【請求項１】
ルールエンジンで使用されるルールコードのセットを構築するためのシステムであって、
ユーザーにルールコードのセットを書かせたり、入力されたデータをフォーマットしてフォーマットされたデータを作成させたりすることを要求せずに、ユーザーから入力されたデータを受け取るように構成されたコンフィギュレータであって、入力されたデータが、アプリケーションの１つ以上のプロセス状態、１つ以上のプロセス状態の各々で受け取られる１つ以上の入力、１つ以上のプロセス状態の各々の１つ以上の予想される出力、および１つ以上のプロセス状態の各々で行なわれる１つ以上の動作を含む、コンフィギュレータ、および、
フォーマットされたデータを受け取るように、かつアプリケーションと協働して動作するルールエンジンによって実行可能なルールコードのセットを生成するように構成されたルール書き込み装置、
を含む、システム。
【請求項２】
ルール書き込み装置からルールコードのセットを受け取るように、かつルールのセットがルールエンジンによって実行され得ることを実証するためにルールのセットにおいて一連の論理テストを行うように構成され、ならびに、修正を要求するルールのセットにおける任意のエラーのルール書き込み装置に命令するように構成されたテスターをさらに含む、請求項１に記載のシステム。
【請求項３】
ユーザーからフォームを受け取り、かつコンフィギュレータ用の入力データを開発するためにフォームから情報を抽出するように構成されたデータ抽出器にフォームを出力するように構成されたフォームデポジトリをさらに含む、請求項１に記載のシステム。
【請求項４】
フォームから抽出された情報が、１つ以上のグラフィックオブジェクトと、１つ以上のプロセス状態、１つ以上の入力、１つ以上の予想される出力、および１つ以上の動作を識別する１つ以上のグラフィックオブジェクトに関連した他の情報とを含む、請求項３に記載のシステム。
【請求項５】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、アプリケーションの機能を行うための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
ユーザー、１つ以上の他のソース、またはユーザーと１つ以上の他のソースの組み合わせから、機能に関するアプリケーションへの入力を受け取ること；
機能に適用する１つ以上のルールと、入力に基づいて１つ以上のルールに関連した事実の集合とを決定すること；
１つ以上のルールと事実の集合を含むルールエンジンに対するメッセージを送ること；
機能に関連するルールに依存したレスポンスを開発するためにルールエンジン内で１つ以上のルールと事実の集合を処理することであって、こうした処理は、後向き連鎖クエリーを含む前向き連鎖ルール内の状態を作成することによって前向き連鎖ルールを後向き連鎖ルールと組み合わせることを含む、こと；
アプリケーションへルールに依存したレスポンスを送ること；および、
機能の性能に帰するルールに依存したレスポンスに基づいてアプリケーション内で１つ以上のワークフローを行うこと、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項６】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、ルールエンジン内で前向き連鎖ルールを後向き連鎖ルールと組み合わせるための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することであって、この場合、前向き連鎖ルールの実行が中断される、こと、
問題のある事実に関するルール述語の依存性を表に記録すること、および、
前向き連鎖ルールの実行中に、実行するべき新しいルールを選択するために、次の未試行の事実にスキップすること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項７】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、アプリケーションの機能を実行するための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
ユーザー、１つ以上の他のソース、またはユーザーと１つ以上の他のソースの組み合わせから、機能に関するアプリケーションへの入力を受け取ること；
機能に適用する１つ以上のルールと、入力に基づいて１つ以上のルールに関連した事実の集合を決定すること；
１つ以上のルールと事実の集合を含むルールエンジンに対するメッセージを送ること；
機能に関連するルールに依存したレスポンスを開発するためにルールエンジン内で１つ以上のルールと事実の集合を処理することであって、こうした処理は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせることを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、こと；
アプリケーションへルールに依存したレスポンスを送ること；および、
機能の性能に帰するルールに依存したレスポンスに基づいてアプリケーション内で１つ以上のワークフローを行うこと、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項８】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、ユーザーのためにドキュメントを処理する命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
文書処理アプリケーションでユーザーからドキュメントを受け取ること；
ドキュメントの識別プロセスを始めるために、ドキュメントからのデータを含むメッセージをルールエンジンに送ること；
ドキュメントに関してドキュメントの種類とドキュメントの内容を識別する第１のルールに依存したレスポンスを引き起こすために、ルールエンジン内で動作される第１のルールのセットに基づいてドキュメントを分析すること；
第１のルールに依存したレスポンスに基づいて、ドキュメントの種類に応じたドキュメントのハンドラープロセスを始めるために、ルールエンジンにメッセージを送ること；
第２のルールに依存したレスポンスを引き起こすために、ハンドラープロセスに対応するルールの第２のセットに基づいてドキュメントの内容を分析すること；および、
第２のルールに依存したレスポンスに基づいて、ドキュメントを処理するために文書処理アプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項９】
ドキュメントを分析する命令とドキュメントの内容を分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項８に記載の非一時的なコンピューター読み取り可能な記憶媒体。
【請求項１０】
ドキュメントを分析する命令とドキュメントの内容を分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせる命令を含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項８に記載の非一時的なコンピューター読み取り可能な記憶媒体。
【請求項１１】
１つ以上のワークフローはユーザーの生産性を改善する、請求項８に記載の非一時的な読み取り可能な記憶媒体。
【請求項１２】
ドキュメントはローンの申し込みに関し、第２のルールに依存したレスポンスはローンの申し込みを承認し、ローンの申し込みを拒否し、あるいは、ローンの申し込みを評価するためには追加のドキュメントまたは情報が必要となることを示す、請求項８に記載の非一時的な読み取り可能な記憶媒体。
【請求項１３】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、製品を開発し、テストし、および分析するための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
アプリケーションにおいて製品に関するデータを受け取ること；
データを分析するためのプロセスを開始するためにデータを含むメッセージをルールエンジンに送ること；
データに応じてルールに依存したレスポンスを引き起こすために、ルールエンジン内で動作するルールのセットに基づいてデータを分析すること；および、
ルールに依存したレスポンスに基づいて、製品の開発、テスト、または分析に関連付けられるアプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項１４】
データを分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１５】
データを分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせる命令を含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１６】
データは、開発される製品の態様に関連付けられるシミュレーションデータであり、ルールに依存したレスポンスはシミュレーションデータに関する問題を示し、１つ以上のワークフローはその問題に関して１人以上の人に警告を出すことを含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１７】
データは、開発される製品のプロトタイプに関連付けられるテストデータであり、ルールに依存したレスポンスは、テストデータに関する問題を示し、１つ以上のワークフローは問題に関して１人以上の人に警告を出すことを含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１８】
データは開発される製品に関連付けられる分析データであり、ルールに依存したレスポンスは、製品が検定に合格している、検定に失格している、または、水準または規則に従って製品を保証するのに必要な部分が欠けているということを示し、１つ以上のワークフローは、検定に合格した、検定に失格した、または一部を欠いた製品に関して１人以上の人に警告を出すことを含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１９】
１つ以上のワークフローは、基準団体または監督機関に提出するのに適した報告書を作成することを含む、請求項１８に記載の非一時的な読み取り可能な記憶媒体。
【請求項２０】
１つ以上のワークフローは、なぜ製品が検定に失格したのかを示す報告書を作成することを含む、請求項１８に記載の非一時的な読み取り可能な記憶媒体。
【請求項２１】
１つ以上のワークフローは、製品の少なくとも１つの部分が欠けていること、およびその部分が製品内のどこにあり得るかを示す報告書を作成することを含む、請求項１８に記載の非一時的な読み取り可能な記憶媒体。
【請求項２２】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、航空機のフライトを選択する際にユーザーを支援する命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
航空機のフライトに関するユーザーの好みについてユーザーからアプリケーション内でデータを受け取ること；
データを分析するためのプロセスを開始するために、データを含むメッセージをルールエンジンに送ること；
データに応じてルールに依存したレスポンスを引き起こすためにルールエンジン内で動作するルールのセットに基づいてデータを分析すること；および、
ルールに依存したレスポンスに基づいて、ユーザーの好みを満たす１つ以上の航空機のフライトを識別することに関連するアプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項２３】
データを分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項２２に記載の非一時的な読み取り可能な記憶媒体。
【請求項２４】
データを分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせることを含み、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項２２に記載の非一時的な読み取り可能な記憶媒体。
【請求項２５】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、航空会社に関連する乗組員をモニターする命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
各乗組員に関してアプリケーション内でデータを受け取ること；
データを分析するためのプロセスを開始するためにデータを含むメッセージをルールエンジンに送ること；
データに応じてルールに依存したレスポンスを引き起こすためにルールエンジン内で動作するルールのセットに基づいてデータを分析すること；および、
ルールに依存したレスポンスに基づいて、乗組員の勤務時間要件を満たす１つ以上の航空機のフライトを識別することに関連したアプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項２６】
データを分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項２５に記載の非一時的な読み取り可能な記憶媒体。
【請求項２７】
データを分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせることを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項２５に記載の非一時的な読み取り可能な記憶媒体。
【請求項２８】
１つ以上のワークフローは、乗組員の勤務スケジュールを識別する、請求項２５に記載の非一時的な読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願への相互参照）
本出願は、２０１２年１２月１０日に出願された米国仮特許出願６１／７３５，５０１号の利益を主張する。
【０００２】
本開示は、ルールベースのデータ処理システムとこれを使用するための方法に関する。
【背景技術】
【０００３】
世界中の人や企業に添付されるデータ量の急激な増加を可能にしたクラウドベースシステムにおけるデータの収集、記憶、アクセス、および編成が近年発展している。データセットが非常に大きくなって従来のデータベース管理ツールを用いて作業するのが難しくなるとき、データセットは「ビッグデータ」と呼ばれる。ビッグデータは現在マクロであるが増えつつある問題であり、絶えず膨大な業務処理データに晒されている大企業や、車、センサー、カメラ、および大都市の車道の交通の流れを管理するための他の多くのソースからのデータを処理しようと試みる大都市の行政統治機関などの異なるソースからの大量のデータを処理しようとしている他の組織に影響を与えている。ソーシャルネットワーク、クラウドサービス、およびメディアサービスが拡大するにつれ、１人当たりのデータの量は、データが直接結合または疎結合するコンピュータシステムと個人の両方によって、収拾不可能なレベルにまですでに増大しつつある。
【０００４】
個人が身の回りの莫大なデータセットを容易に問い合わせできるように現在多大な努力が払われており、これはパーソナルサーチエンジン（ｐｅｒｓｏｎａｌ  ｓｅａｒｃｈ  ｅｎｇｉｎｅｓ）として知られている。パーソナルサーチエンジンは、個人がより優れた検索を行うことを可能にし、かつ自身の莫大な集合的なデータセットを編成する組織するのに重要になるであろうが、集合的なデータセットの量が個人の能力やクエリープロセスに時間と労力をつぎ込もうとする意欲では手の打ちようがなくなる時点が依然としてあるであろう。
【０００５】
同様に、電子メールやテキストのような既存のコミュニケーションテクノロジーには、マーケティングメッセージ、個人的な通信文書と仕事上の通信文書の組み合わせ、およびそれ以外のクラッタが溢れるようになった。少数の受領者の間での短い１つのメッセージから、高度に文脈化されたフォーマットで多量のコンテンツタイプを共有したいと願う異なる地理的位置にいる数十の参加者の間でのより流動的な通信スタイルへと進化を遂げた現代の個人の通信スタイルの性質を採用しようとしたが失敗に終わっている。受け取る電子メール通信は、例えば、メッセージに対する文脈上の関連性をユーザーに提供する有効な能力に欠けており、つまり、入ってくる通信のすべてのピースは、小さなフィルタリング能力で基本的には同じ方法で扱われる。個人を取り巻く集合的なデータセット量の増加と不適切な通信の結果として、編成用ソフトウェアツールは甚だ非効率なものとなっている。さらに、かつては個人的な理由やビジネス上の理由で通信する明瞭で汚れのないチャンネルだった電子メールは、雑然としたものとなり、効率的ではなくなった。
【０００６】
日本の通産省は何年も前に、「第五世代コンピュータ」を開発するという１０年にわたるプロジェクトを始めた。これは、ビッグデータなどの大量のデータベース上で動作する超並列処理コンピュータを使用することで性能を高めることになっていた。ソフトウェアは、２つの理由で論理プログラミング（つまり、言語のプロログファミリー）に基づいていた：知識表現レベルでは、自動化した推論は論理に基づくことになっており、ハードウェアレベルでは、論理の宣言的性質により、機械内の膨大な数の処理ユニットの中の演算を自動的にスケジュール設定することが可能となる。
【０００７】
第五世代コンピュータープロジェクトは多くの理由で１９９２年に終了した。この理由とは、従来の「既製の」コンピュータが劇的に進歩したため、並列処理マシンの性能をすぐに凌駕し、論理プログラミング言語中のコミッテッドチョイス（ｃｏｍｉｔｔｅｄ−ｃｈｏｉｃｅ）の特徴がその宣言的な意味を破壊したという事実を含む。ハードウェアの観点から言えば、プロジェクトは明らかに時代を先取りしていた。２０１２年４月時点では、８コアプロセッサーが標準的な「既製の」製品であり、携帯電話は４コアプロセッサーを装備していた。１６または３２のプロセッサコアを備えたコンピュータが数年以内に新しい標準になるであろう。ソフトウェアの観点からみれば、宣言的なセマンティクス問題は、宣言型プログラミングが多くのコアで同時に実行される際に誇張されるだけの問題のままである。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
処理エンジン、データベース、およびルールエンジンと通信したアプリケーションによって生成されるルールと関連する事実の集合（ｂａｇ  ｏｆ  ｆａｃｔｓ）とを処理するためのシステムと方法が記載されており、処理エンジン、データベース、およびルールエンジンは、ルールを考慮して事実の集合を処理し、アプリケーションに対する１つ以上のルールに依存したレスポンスを生成し、アプリケーションはそのレスポンスに基づいて１つ以上のワークフローを行う。ルールエンジンは、ルールと事実を処理するために、前向き連鎖、後向き連鎖、または前向き連鎖と後向き連鎖の組み合わせを適用することもある。ルールエンジン内での前向き連鎖ルールと後向き連鎖ルールの組み合わせの実施形態は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存した条件を含まない限り、後向き連鎖ルールの目標として前向き連鎖ルールから推論された事実を利用する工程を含んでもよく、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語（ｒｕｌｅ−ｐｒｅｄｉｃａｔｅ）の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の試されていない事実にスキップする。処理エンジン、データベース、およびルールエンジンと協働して作動する無数の新しいアプリケーションについても記載されている。
【図面の簡単な説明】
【０００９】
【図１】実施形態に従って否定を含む後向き連鎖と前向き連鎖のルールの組み合わせを例証するフローチャートである。
【図２】実施形態に係る高可用性アーキテクチャを示す。
【図３】実施形態に係るシャーディング（ｓｈａｒｄｉｎｇ）によるスケーリングを示す。
【図４】実施形態に係るフラグメンテーションによるスケーリングを示す。
【図５Ａ】実施形態に係る並列前向き連鎖を例証する。
【図５Ｂ】実施形態に係る後向き連鎖におけるＯＲ並列化を例証する。
【図５Ｃ】後向き連鎖におけるＡＮＤ並列化を例証する。
【図６】ルールエンジンの実施形態を組み込むアプリケーション開発プラットフォームの実施形態のブロック図である。
【図７】図６のアプリケーション開発プラットフォーム用データ入力の実施形態のブロック図である。
【図８】図６のルールエンジンと協働して使用されるデータベースおよびプロセスエンジンの実施形態のブロック図である。
【図９】図６のルールエンジンの実施形態のブロック図である。
【図１０】アプリケーションと協働して作動する図６の処理セクションの実施形態のブロック図である。
【図１１】アプリケーションが図１０の処理セクションとどのように作動するのかの高水準な記載を例証するフローチャートである。
【図１２】実施形態に係るドキュメント管理システムを例証するフローチャートである。
【図１３】演算装置を例証するブロック図である。
【発明を実施するための形態】
【００１０】
ルールエンジンの実施形態は、データ中のコンテキストと関連性がデータセットのサイズまたは複雑さにかかわらず達成されるやり方でプロセスとワークフローによってデータの知的な処理を可能にすることができる様々なアプリケーションの実施形態の基礎を含むこともある。従って、本記載はルールエンジンの実施形態の記載から始まり、中心の要素としてルールエンジンを含む様々な可能なアプリケーションの実施形態について記載していく。
【００１１】
本ルールエンジンの実施形態は、プロセッサー上で実行される際にプロセッサーに様々な機能、ステップ、アルゴリズム、プロセスなどを行わせる命令を記憶したコンピュータ可読媒体を含むこともある。さらに、ルールエンジンは、非一時的、非一過性、またはコンピュータ読み取り可能な記憶媒体に記憶されることもある。本明細書で使用されるように、コンピュータ読み取り可能な記憶媒体は、機械可読情報を記録にするために構成される任意のディスクまたはドライブも含むこともあり、フロッピー（登録商標）ディスク、ＣＤ、ＤＶＤ、光学記憶装置、磁気ドライブ、ソリッドステートドライブ、ハードドライブ、または当該技術で知られている任意の他のメモリデバイスを含むこともある。
【００１２】
実施形態は、システム内のそれぞれの各アクターに固有であり、かつコンテキストとの関連性が高い、ワークフローへの知的なデータの処理を大衆にもたらす新しい可能性を与えることもある。１つの実施形態では、プロセスエンジンは、プロセスを制御するルールエンジンのルールと、プロセス状態を表わすプロセスとルール事実（ｒｕｌｅ  ｆａｃｔｓ）を使用することもある。この構造では、プログラミングは、望ましくない副作用も行き詰ったプロセス状態もほとんどまたはまったくない、純粋な論理や数学的な音になることもある。プロセス状態遷移は、静的なフローではなく、システムを高度に複雑なデータセットの取り扱いに非常に優れたものとする条件に基づくこともある。システムプロセスは、フォールトトレランス能力をシステムに加え、スケーラビリティに非常に適している、非同期メッセージパッシングを使用することもある。ルールセマンティクス（ｒｕｌｅ  ｓｅｍａｎｔｉｃｓ）は、マルチコアＣＰＵ上での並列実行を考慮に入れて、実行順序とは無関係に行うことができる。
【００１３】
実施形態に係るルールエンジンの一例は、既存のルールエンジンと比較して、以下のとおりである。本実施形態を既存のルールエンジンと比較することの背後にあるポイントは、本実施形態の宣言的な態様である純粋論理を強調することである。既存のルールエンジンはＤＲＯＯＬＳと呼ばれ、ＪＢＯＳＳ（２００６年以降、ＲＥＤ  ＨＡＴの一部門）の後援の下Ｊａｖａ（登録商標）で書かれた人気のあるオープンソースルールエンジンである。これは純粋には宣言的ではなく、以下の例が例証するように、本ルールエンジンほど簡潔ではない：「ｉｆ  ｔｈｅ  ｐａｒｅｎｔ  ｏｆ  Ｘ  ｉｓ  Ｚ，  ａｎｄ  ｔｈｅ  ｐａｒｅｎｔ  ｏｆ  Ｚ  ｉｓ  Ｙ，  ｔｈｅｎ  ｔｈｅ  ｇｒａｎｄｐａｒｅｎｔ  ｏｆ  Ｘ  ｉｓ  Ｙ（Ｘの親がＺであり、Ｚの親がＹである場合、Ｘの祖父母はＹである）」と言うルールをコード化すること。対応するＤＲＯＯＬコードは以下のように書かれることもある：
【００１４】
【数１】
2016505953.tif 000003
ルールエンジンの本実施形態の対応するコードは、以下のように書かれることもある：
【００１５】
【数２】
2016505953.tif 000004
これらのコード例は両方とも純粋に宣言的であるが、ＤＲＯＯＬＳでは、以下のような異なる非宣言的なルールを使用してコードを書くことが可能となる：
【００１６】
【数３】
2016505953.tif 000005
【００１７】
後者のＤＲＯＯＬＳコードでは、条件をトリガーすると、コードは最初に知識ベースから第１のｐａｒｅｎｔ（親）に関連する事実＄ｐ１を撤回し（したがって、知識ベース内にｇｒａｎｄｐａｒｅｎｔ（祖父母）推論をそのまま残しつつ、同時にその論理サポートを無効にする）、その後、ルールエンジンはコンピュータを切るか、仮想サーバーを停止させる（ルールエンジンがクラウドサーバー環境で動作している場合）か、あるいは、他のフォールトを生じさせる；これらはすべて上記のようなルールエンジンを使用するアプリケーションでは問題となることもある。というのも、こうしたフォールトによりアプリケーションが停止し、要求された動作を完了しないことがあるからである。
【００１８】
宣言的なセマンティクスを破壊することができないことから、本ルールエンジン実施形態の対応するコードでは事情が異なることもある。さらに、コードを単純化することでルールエンジンの速度が改善されることもある。両方のルールエンジンを使用して書かれたルール間の簡単なベンチマークは、こうした性能の増大を例証する。ベンチママークルールは、リンゴ対オレンジの比較を避けるために、２つのセットの事実（「内部結合」として知られている）間の交差である、１つの特定の機能だけを測定する。ＤＲＯＯＬＳコードは以下のように書かれることもある：
【００１９】
【数４】
2016505953.tif 000006
【００２０】
本ルールエンジンの前向き連鎖コードで表現される同じルールは、以下のように書かれることもある：
【００２１】
【数５】
2016505953.tif 000007
【００２２】
ＤＲＯＯＬＳは純粋な前向き連鎖ルールエンジンであるが、本ルールエンジンの実施形態では、このルールも以下のように後向き連鎖機能を使用して書かれることもある：
【００２３】
【数６】
2016505953.tif 000008
【００２４】
ベンチマークテストでは、他のすべての条件を平等にして同じコンピュータで動作させると、前向き連鎖バージョンは、２００，０００の事実で４１％速く、４００，０００で２．８％速かった。後向き連鎖バージョンは２００，０００の事実で６１％速く、４００，０００の事実で１６．９％速かった。本ルールエンジンのコアオペレーションは前向きと後向きの連鎖の両方で同じこともある：事実のマッチング；それは異なる推論の処理にすぎない。
【００２５】
ルールエンジンの基礎をなす構造は、エンジンを駆動する１つ以上のアルゴリズムで構成されることもある。もう一度ＤＲＯＯＬＳの例について言及すると、ＤＲＯＯＬＳは、チャールズ・フォーギーによって開発されたマッチングアルゴリズムであるＲＥＴＥに基づいている。ＲＥＴＥは、ユーザーによって確立されたルールからツリーを構築することにより動作する。事実はルールに対するパラメータとして最上位のノードでツリーを入力し、リーフノード（つまりルール結果）に達するまで、ツリーをくまなく探す。具体的には、ツリーは、それぞれのノード（ルート以外の）がルール左辺（条件パート）で発生するパターンに相当する、ノードのネットワークを含んでいる。ルートノードからリーフノードまでのパスは完全なルール左辺を定義する。それぞれのノードにはそのパターンを満たす事実の記憶がある。新しい事実が主張されるまたは修正されると、ネットワークに沿って伝播し、その事実がそのパターンにマッチした時にノードに注釈が付けられる。事実または事実の組み合わせにより所定のルールに関するパターンがすべて満たされるとき、リーフノードに到達し、対応するルールが起動する。
【００２６】
本ルールエンジンは数多くの特徴を有しており、そのなかにはアルゴリズム的なものもあり、これはその純粋論理プログラミングを利用することができるアプリケーションの開発に非常に適していることもある。こうした特徴（さらに以下に記載）は次のものを含んでいる：
Ａ．  副作用のない純粋な数理論理学；
Ｂ．  否定のロバストな取り扱い；
Ｃ．  前向きと後向き連鎖の組み合わせ；
Ｄ．  簡潔なルールのシンタックス（ｒｕｌｅ  ｓｙｎｔａｘ）；
Ｅ．  ルールエンジンをアプリケーションに埋め込むか、あるいは、ネットワークを介するサービスとして供給することができる；
Ｆ．  プロセスエンジンは現状に対して真である事実の集合としてそれぞれのプロセス状態を表す；
Ｇ．  プロセス状態の遷移は、「フロー」または「スレッド」を含む静的なグラフではなく、条件に基づいている；および、
Ｈ．  プロセスは非同期メッセージパッシングを使用する。
【００２７】
特徴Ａに関して、「副作用」とは、ルールエンジンがハングアップしかねない、読み取りファイル、書き込みファイルなどの非論理要素を指す。ルールエンジンが数学的に純粋であるためには、こうした副作用を取り除く必要である。ルールエンジンに副作用がない場合、ルールエンジンは論理素子を有するだけであり、このことは、本ルールエンジンの実施形態が入力を前提として出力を生成する際、その結果が論理ルールの宣言的なセマンティクス（数学的−論理的な解釈）と一致していることを意味する。
【００２８】
対照的に、例えば、ＰＲＯＬＯＧでは、副作用はルールエンジンそれ自体の内部で取り扱われ、これは一般に並列処理ルールエンジンの場合でも同様である。こうしたルールエンジンでは、プロセス状態の変化はすべてデータベーストランザクションとして終了する。特定の保険会社で使用されているようなルールエンジンもあり、この場合、データはすべてプロセス状態の形態で構築されるため、データベーストランザクションを含まずにすべてのデータをルールエンジンに利用することが可能である。しかしながら、こうしたルールエンジンではデータは分割・分離されないため、同じデータを使用する多くの異なるプロセスは平行で実行されることもあり、これはルールエンジンや対応するアプリケーションの効率に影響を与える。
【００２９】
データベーストランザクションを含むルールエンジンに関して、様々なプロセスが同時にトランザクションを要求しようとする、つまり、同じデータのすべてまたは一部を読む／書くこともあるため、衝突は常に起こり得るものである。データベーストランザクションには次のプロパティがある：任意の時点では、トランザクションに直接関与しない任意のエージェントの観点から、トランザクションに関連した変化はすべて生じているか、または１つも生じていないかのいずれかである。このプロパティは、プロセス状態を記憶するシステムが常に一貫した状態であることを保証する。すべての非自明なデータベースアプリケーションは、トランザクションのこのプロパティに大きく依存する。
【００３０】
このトランザクションのプロパティを保証するために、複数のエージェントがリソース競合：ｐｅｓｓｉｍｉｓｔｉｃ同時制御、または、ｏｐｔｉｍｉｓｔｉｃ同時制御を引き起こす方法で同時にトランザクションを要求した際に、データベースは同時制御のための２つのスキームの１つを使用する。ｐｅｓｓｉｍｉｓｔｉｃ同時制御はトランザクションに関与するすべてのリソース上で排他ロックを得るが、ｏｐｔｉｍｉｓｔｉｃ同時制御はロックがないが、すべての処理が行われた後に、最終的なコミットオペレーション時に最新の衝突のみを検知する。衝突が検知されると、現在のトランザクションはロールバックされ、完了するまで再度試みられる。
【００３１】
ｏｐｔｉｍｉｓｔｉｃ同時制御はスケーラブルなウェブ・アプリケーションの標準的案スキームである。というのも、ｏｐｔｉｍｉｓｔｉｃ同時制御は、低レベルのリソース競合のスケーラブルなアプリケーション向けに一段と効率的である、つまり、最も一般的なケース、リソース競合がないだろうという仮定向けに最適化されるからである。ｏｐｔｉｍｉｓｔｉｃ同時制御を使用するどのアプリケーションも、最新の衝突によって失敗したあらゆるトランザクションを再度試みることができる必要がある。非常に単純なアプリケーションでは、これは容易である−トランザクションを成功裡にコミットする（Ｃｏｍｍｉｔｔｅｄ）ことができるまで繰り返されるループ内のデータベース最新の論理をエンコードするだけである。しかしながら、これにより、最新の論理演算は等冪な演算（つまり、それ自体で乗算しても変化しない演算）であることを要求され、さもなければ、トランザクションのセマンティクスは、衝突が生じたか否か、つまり物理的に偶然の要因に依存するであろう。
【００３２】
ルールエンジン自体に影響を与える衝突を回避するために、ルールエンジンと協働して作動するプロセスエンジンにデータベーストランザクションを移動することができるが、このような場合、ルールエンジンは、衝突をもたらすトランザクションをもはやロールバックすることができず、結果として、上記のように停止することになる。
【００３３】
副作用がないことから、本ルールエンジンの実施形態による演算は定義上等冪であり――副作用はなく、埋め込み用アプリケーションによって明示的に制御されるものを除けば外部入力はない。これは他のプログラミング言語では当てはまらず、任意のプログラミング言語で等冪なプログラムを書くことは可能であるが、どの任意のアプリケーションも等冪であるという保証はない。従って、プロセス状態の遷移を演算するために本ルールエンジンの実施形態として等冪なプログラミング言語を使用することにより、完全に一般的な（つまり、チューリング−完全）遷移関数によってルールされるトランザクション状態遷移を作り出すことが容易になることもある。
【００３４】
ルールのセット（ａ  ｓｅｔ  ｏｆ  ｒｕｌｅｓ）の正確さを証明し、かつそのルールのセットで暗黙のプロパティを証明する／引き出すために、特徴Ａによって代数のツールを使用することも可能になる。例えば、ルールは「クリーンな」研究施設環境では分離してテストされることもある。製造環境で生じ得るどんな状況も分離されたテストにおいて（わずかな労力で）シミュレートされることがある。特徴Ａは、内部で一貫しており、問題を解決するために外部の入力を必要としないというセキュリティ上の利点を備えている。ゆえに、ルールは自己承認型（ｓｅｌｆ−ａｕｔｈｏｒｉｚｉｎｇ）である。この特徴によって、信頼できない外部の関係者に自身のルールを安全に提供させるとともに、結果を生み出すために自らが好むどんなコードでも安全に実行させるようになる。
【００３５】
特徴Ｂは、否定の状態を宣言的な方法で使用することを可能にする。例えば、本ルールエンジンの一実施形態は、後向き連鎖でｉｆ−ｔｈｅｎ−ｅｌｓｅルールを提供するためにこの特徴を使用することもある。それ以外の後向き連鎖の言語（例えばＰＲＯＬＯＧ）では、ｉｆ−ｔｈｅｎ−ｅｌｓｅはあるが、宣言的なセマンティクスを欠く。前向き連鎖の言語（つまり、上に記載した保険会社のルールエンジンなどのルールエンジンのほとんど）は、前向き連鎖アルゴリズムの性質によりｉｆ−ｔｈｅｎ−ｅｌｓｅルールを備えていない。本ルールエンジンは前向き連鎖で明確な否定の状態を使用することができ、これは、以下にさらに記載されるように、本ルールエンジンで前向き連鎖と後向き連鎖を組み合わせる独特な方法に依存している。
【００３６】
前向き連鎖と後向き連鎖の組み合わせである特徴Ｃは、前向き連鎖または後向き連鎖のいずれか一方だけよりも多くの表現力を与える。両方のオプションを有する些細な意味だけでなく、前向き連鎖ルールを有することでそれらを組み合わせることによっても一連の推論が得られ、この推論は、単一の回答を提供するための後向き連鎖フィルタ／検索ルールによって、あるいは、前向き連鎖ルールの状態の一部として後向き連鎖のクエリーを使用することによって減らされる。
【００３７】
特徴Ｄにより、本ルールエンジンはさほど簡潔ではない代替物よりも強力になる。
【００３８】
特徴Ｅは、ネットワークのインプリメンテーションに依存するアプリケーションの性能に有害な影響を与えることなく、ルールエンジンの分布の制御を可能にする有用な実行特徴である。
【００３９】
特徴Ｆにより、従来の有限状態機械を自明な方法で実行すること、複数の同時有限状態機械を同じプロセスで等しく自明ない方法で実行すること、およびプロセス状態遷移ルールによって使用される任意のコンテキストデータをプロセス状態とともに同じ集合に記憶させることが可能となる。特徴Ｆは記憶されたプロセスに特有のデータに対して簡潔さを加える。データは、ルール状態で使用される事実としてすぐに利用可能である。データベース検索を行うための余分なコードは必要ではない。特徴Ｆはプロセス状態の任意の形式的な分析がこの特定の事実の集合だけを考慮する必要があることを保証する。
【００４０】
特徴Ｇは複雑な並行プロセスのモデリングを単純化し、特徴Ｈはスケーラビリティとフォールトトレランスに優れている。
【００４１】
特徴Ｆは、有限状態機械としてではなく「事実の集合」としてプロセス状態を処理することによって、手続の実行が論理的な実行から分離されることもあるという点でとりわけ重要なこともある。論理を分離させることがなければ、論理的なルールで動かされる状態遷移の概念はない。さらに、別の状態遷移なしで、プロセス状態は単なる任意に更新されたデータベース記録の束である（あるいはそれと同様になり得る）。従って、グループまたは
【００４２】
上で記述した特徴は、既存のルールエンジンを上回る多くの利点を本ルールエンジンの実施形態に与えるものである。例えば、分離しているルールをテストする能力により、本ルールエンジンを使用するために書き込まれるアプリケーションは、ルールをテストし、デバッグし、かつ維持しやすくなる。セキュリティ上の利点、否定のロバストな取り扱い、前向き連鎖と後向き連鎖の組み合わせ、および簡潔なルールのシンタックスは、ルールプログラマーに対して、既存のルールエンジンよりも多くの表現力を与える。プロセスエンジンが事実の集合としてのそれぞれのプロセス状態を表し、プロセス状態遷移が条件に基づき、および、プロセスが非同期メッセージのパーシングを用いるという事実により、複雑な並行プロセスをモデル化することがより容易になり、その結果、ルールエンジンを使用するアプリケーションを製造し維持するのにかかる費用が安くなる。ルールのセットの正確さと、プロセス状態の任意の形式的な分析は一連の事実が現在の状態で信であるという事実を説明する必要があるだけであるという事実の正確さを証明する代数のツールを使用する能力によって、アプリケーションは、プロセスを最適化し、かつエラーを回避するために、ルールに関する自動推論と証拠を使用することが可能となる。さらに、他のプログラミング言語は純粋な数理論理学を使用し、簡潔であり、ネットワーク構成で実行され得るが、ルールエンジンではない。
【００４３】
特徴Ｃに関して明記されたように、前向き連鎖と後向き連鎖の組み合わせは、前向き連鎖ルールで否定が処理される方法と同様に、非常に強力なこともある。前向き連鎖は「供給駆動型」である。前向き連鎖は個々の所定の事実で始まり、ルールによってそれらから推論され得ることを解明する。本ルールエンジンの実施形態に基づいたフライト選択アプリケーションは、前向き連鎖を実行する基本的なアルゴリズムを含むこともある。例えば、
【００４４】
【数７】
2016505953.tif 000009
【００４５】
このルールは複数の事実がともに作動することを必要としており、したがって、次の事実を仮定する：
【００４６】
【数８】
2016505953.tif 000010
【００４７】
本明細書で提供されるルールの例では、スペースはルールを読みやすくするために加えられたものであることに留意されたい。こうしたルールを書くための適切なシンタックスの説明はさらに以下で提供される。
【００４８】
先に記述された前向き連鎖ルールはここで新しい事実ｃａｎｄｉｄａｔｅ  （“ＢＡ−０７７７”）を推論することもある。この推論の意図された意味は、ｒｅｑｕｅｓｔ（要求）の条件を満たす限り、フライトナンバーＢＡ−０７７７が要求に対する可能なフライトｃａｎｄｉｄａｔｅ（候補）であるということである。
【００４９】
フライト選択アプリケーションに組み込まれる本ルールエンジンの単純化した実施形態は、以下のようにこの前向き連鎖ルールを処理することもある：所定の事実のセットにおけるそれぞれの事実、つまり、ｒｅｑｕｅｓｔ（“Ｓｔｏｃｋｈｏｌｍ”，“Ｌｏｎｄｏｎ”）について、ルールエンジンは、ルールの条件部分（前項）に複数のバリエーションのｒｅｑｕｅｓｔ（Ｘ，Ｙ）を含むそれぞれのルールを見ることもあり、その後、事実にと対してこれをマッチさせることもあり、変数Ｆｒｏｍ＝“Ｓｔｏｃｋｈｏｌｍ”とＴｏ＝“Ｌｏｎｄｏｎ”の２つを制約することでルールのインスタンス化をもたらすこともある。ルールのインスタンス化は以下のように見えることもある：
【００５０】
【数９】
2016505953.tif 000011
【００５１】
その後、ルールエンジンは、条件の任意の残りの部分、この場合では、事実のセットにマッチさせるために、ｎｏｎｓｔｏｐ（“ＢＡ−０７７７”、“Ｓｔｏｃｋｈｏｌｍ”、“Ｌｏｎｄｏｎ”）を調べることもある。この場合、所定の事実であるｎｏｎｓｔｏｐ（“ＢＡ−０７７７”、“Ｓｔｏｃｋｈｏｌｍ”、“Ｌｏｎｄｏｎ”）がマッチするため、１つのマッチが見つかる。このマッチによりルール状態は真となり、推論された事実ｃａｎｄｉｄａｔｅ（“ＢＡ−０７７７”）が事実のセットに加えられることもある。所定の事実のセットと同じ方法で推論されたすべての事実もルールに対して試みられることもあるため、推論と推論の組み合わせはさらなる推論などが生み出すこともあり、アルゴリズムは供給すべき試されていない事実がなくなるまで継続されることもある。
【００５２】
ルールエンジンを呼び出したフライト選択アプリケーションは、ここで事実の最終セットを検査し、任意の興味深い推論を捜すこともあれば、あるいは、後向き連鎖のクエリーを実行することでルールエンジンに調べさせることもある。後向き連鎖は「要求駆動型」である。後向き連鎖は仮説のステートメントから始まり、このステートメントがルールの結果であるかどうかを解明する。ステートメントは論理変数を含むこともあり、その場合、ステートメントはこうした変数の複数の特定の値についてのみ真であることがある。後向き連鎖アルゴリズムはこうした値を演算することもある。このおかげで、後向き連鎖は知識ベースを問合せするのに適したものとなる。
【００５３】
本ルールエンジンの実施形態に従って、後向き連鎖ルールは前向き連鎖ルールよりも複雑な構造を有することもある。多くの個別の「ｉｆ−ｔｈｅｎ」節の代わりに、後向き連鎖における「ｉｆ−ｔｈｅｎ」節は、「ｅｌｓｅ」の演算子を介して互いに接続されることもある。これにより、後向き連鎖に対して、純粋な宣言的なセマンティクスを含むコミッテッドチョイスの特徴が与えられ、これは、非論理的なコミットと枝刈り演算子を利用する既存の論理プログラミング言語から識別可能である。
【００５４】
上記からのフライト選択例で継続すると、ユーザーを所望の目的地へと運ぶ直行便がなかった場合、乗り継ぎ便によってそこにたどり着くことがまだ可能なこともある。後向き連鎖は以下のように可能な接続について我々にルールエンジンに問合せさせることもある：
【００５５】
【数１０】
2016505953.tif 000012
【００５６】
再度、特定の事実は、以下のように例について仮定されることもある：
【００５７】
【数１１】
2016505953.tif 000013
【００５８】
後向き連鎖エンジンにクエリーｐｏｓｓｉｂｌｅ＿ｆｌｉｇｈｔ（“Ｓｔｏｃｋｈｏｌｍ”、“Ｓａｎ  Ｄｉｅｇｏ”、Ｘ）を与える場合、後向き連鎖エンジンはこのステートメントの論理的な証拠を見つけて、Ｘに対する１つ以上の値を提供しようとすることもある。後向き連鎖アルゴリズムは、ルール中の変数を束縛するために目標パラメータを用いて、適切なルールをインスタンス化することで先行することもあり、これは以下をもたらすこともある：
【００５９】
【数１２】
2016505953.tif 000014
【００６０】
次のステップは、最初の「ｉｆ−ｔｈｅｎ」節の条件を評価することであってもよく、これは、目標、この場合、ｎｏｎｓｔｏｐ（Ｃｏｄｅ、“Ｓｔｏｃｋｈｏｌｍ”、“Ｓａｎ  Ｄｉｅｇｏ”）として条件を用いて、後向き連鎖アルゴリズムを呼び出すことによって行われることもある。ｎｏｎｓｔｏｐは基本的な事実の述語であるため、目標は事実の記憶に対して直接マッチされ得る。ＳｔｏｃｋｈｏｌｍからＳａｎ  Ｄｉｅｇｏまでの直行便がないため、マッチは見つけられず、条件で失敗する。その後、次の代替節が試みられることもある（ｅｌｓｅの後の１つ）。この条件は２つの初歩的な事実の述語の論理積である。第１のｎｏｎｓｔｏｐの（Ｃｏｄｅ１、“Ｓｔｏｃｋｈｏｌｍ”、Ｓｔｏｐ）は、最初の節と同じ方法でマッチし、この場合、以下の対応する変数の束縛を与える２つのマッチが見られる：
【００６１】
【数１３】
2016505953.tif 000015
【００６２】
最初のｎｏｎｓｔｏｐの目標からの着陸地について２つの値があるので、ｎｏｎｓｔｏｐ（Ｃｏｄｅ２、Ｓｔｏｐ、“Ｓａｎ  Ｄｉｅｇｏ”）は非決定論的にマッチする。着陸地の値のそれぞれについて１つのマッチが見られ、論理積について設定された解の集合の合計は以下のとおりである：
【００６３】
【数１４】
2016505953.tif 000016
【００６４】
この時点で、「ｉｆ−ｔｈｅｎ」節は、その条件が真であるため、コミットされる。このことは、目標に関してそれ以上の代替的な「ｉｆ−ｔｈｅｎ」節が考慮されないこともあるということを意味している。この場合、どのみち代替物は残されないが、あった場合は枝刈りされているかもしれない。当初の目標はここで「ｔｈｅｎ」節中の下位目標と取り替えられ、後向き連鎖アルゴリズムが再度スタートすることもある。このプロセスは、解決すべき目標がなくなるか、あるいは、目標の１つに失敗する（全体の証明に失敗して）まで続けられることもある。さらに第３の可能性；複数の起こり得る理由の１つによる中断された証明、最も顕著なものは、束縛されない変数の値に関する条件−もある。
【００６５】
先に提供された後向き連鎖の例では、当初の目標に取って代わる下位目標が単一の目標Ｘ＝［Ｃｏｄｅ１、Ｃｏｄｅ２］からなるので、後向き連鎖はすぐに完了した。「＝」がルールエンジン中の手順によって評価される組み込みの述語であることから、この目標は下位目標にさらに分割されない。後向き連鎖アルゴリズムは、当初のクエリーの２つの解集合で成功裡に終了する：
【００６６】
【数１５】
2016505953.tif 000017
【００６７】
Ｘ値のそれぞれは、ＳｔｏｃｋｈｏｌｍからＳａｎ  Ｄｉｅｇｏまでの異なる許容可能なあり得るルートに相当する。
【００６８】
非決定性、単純な順次的な後向き連鎖（例えばＰＲＯＬＯＧ）を無視することは、従来の手続き型言語を実行するために使用されるよく知られているスタックベースの実行モデルに非常に似ている。
【００６９】
本ルールエンジンの実施形態に従って、上記の前向き連鎖例において、ルールは、以下のような直行便だけでなく接続便も許可するルールと取り替えられることもある：
【００７０】
【数１６】
2016505953.tif 000018
ここで、前向き連鎖ルールは、後向き連鎖クエリーを含む条件を含んでいる。たとえｐｏｓｓｉｂｌｅ＿ｆｌｉｇｈｔ（Ｆｒｏｍ，Ｔｏ，Ｆｌｉｇｈｔ）が初歩的な事実のクエリーよりもむしろ一般的なクエリーであっても、本実施形態ではこの場合の取り扱いは単純になる。実施形態に従って、入力事実ｒｅｑｕｅｓｔ（“Ｓｔｏｃｋｈｏｌｍ”、“Ｓａｎ  Ｄｉｅｇｏ”）により、目標ｐｏｓｓｉｂｌｅ＿ｆｌｉｇｈｔ（“Ｓｔｏｃｋｈｏｌｍ”、“Ｓａｎ  Ｄｉｅｇｏ”、Ｆｌｉｇｈｔ）は、前向き連鎖ルールの条件の評価の一部として後向き連鎖エンジンにおいて試されるであろう。その結果、前向き連鎖アルゴリズムは、事実のセットに対して２つの新しい推論された事実を加えるだろう：
【００７１】
【数１７】
2016505953.tif 000019
【００７２】
後向き連鎖ルール内に前向き連鎖の推論を含めることは、上記とほぼ同じくらい単純である。後向き連鎖の目標は、前向き連鎖から推論された任意の事実を含む任意の初歩的な事実からなることもあるため、後向き連鎖ルールから前向き連鎖ルールの結果を参照することに関して特別なことは何もないように思われるであろうが、この場合はそうではない。前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含んでいる場合に発生する問題がある。これを理解するために、以前の例のルールをとるが、以下のように、フライトはキャンセルされないという追加条件を加える：
【００７３】
【数１８】
2016505953.tif 000020
その後、以下のように、ｃａｎｃｅｌｌｅｄ（Ｆｌｉｇｈｔ）について追加のルールを加える：
【００７４】
【数１９】
2016505953.tif 000021
この考えは、航空当局によってｕｎｓａｆｅ（安全でない）とみなされる任意のフライトが、たとえ実際にはキャンセルされて（ｃａｎｃｅｌｌｅｄ）いなかったとしても、フライト選択のために自動的にキャンセルされるというものである。
【００７５】
実施形態のコンテキスト中の問題は、ｃａｎｄｉｄａｔｅ（Ｆｌｉｇｈｔ）が真または偽であるかどうかを決定することができるように、ｃａｎｃｅｌｌｅｄ（Ｆｌｉｇｈｔ）を評価する方法と時間である。これがどのように問題になり得るのかの一例は以下のとおりである：フライトＢＡ−０７７７が安全ではないわけではないと仮定する。論理上、このことはｃａｎｃｅｌｌｅｄ（“ＢＡ−０７７７”）が偽となることを意味する。なぜなら、それが真であり、ルールエンジンが閉世界仮説で動作するということをいかなるルールも含意していないからである。したがって、ｎｏｔ  ｃａｎｃｅｌｌｅｄ（キャンセルされなかった）（“ＢＡ−０７７７”）は真であり、このことは事実ｃａｎｄｉｄａｔｅ（“ＢＡ−０７７７”）を含意している。この含意された事実に関する問題は、後件としてｃａｎｃｅｌｌｅｄ（Ｆｌｉｇｈｔ）を有する前向き連鎖ルールのあらゆる可能なアプリケーションが使い尽くされるまで、ｃａｎｃｅｌｌｅｄ（“ＢＡ−０７７７”）の真理値を演算することはできないということである。しかしながら、前向き連鎖アルゴリズムが完了するまでは、こうしたすべてのルールアプリケーションがいつ使い尽くされたのかを知ることはできない。
【００７６】
上記の例における問題の原因は否定条件であるｎｏｔ  ｃａｎｃｅｌｌｅｄ（Ｆｌｉｇｈｔ）である。すべての条件が否定のない肯定的な事実にのみ依存する場合、ルールの実行順序は重要ではない。しかしながら、否定により前向き連鎖アルゴリズムは順序に敏感になる。従って、正確な依存順に、問題のあるルールを取り扱うために一見簡単な前向き連鎖アルゴリズムを修正しなければならない。
【００７７】
本ルールエンジンの実施形態は、実行時、否定の推論された事実を使用しようとする試み、実際には、後向き連鎖ルール内部のどこかでそうした事実を用いようとするいかなる試みも検知する。なぜなら、推論された事実に対する言及が否定目標の内部のどこかで動的にネストされれば、否定の問題も現れることがあるからである。この状況が検知されると、最新の前向き連鎖ルールの実行は中断し、問題のある事実に対するルールの述語の依存が表に記録され、前向き連鎖アルゴリズムは次の未試行の事実にスキップして実行すべき新しいルールを選択する。順序依存表（ｏｒｄｅｒ−ｄｅｐｅｎｄｅｎｃｙ  ｔａｂｌｅ）の一例は以下のように現われることもある：
【００７８】
【数２０】
2016505953.tif 000022
【００７９】
１つの述語には２以上の依存があり得るが、この場合、ｃａｎｄｉｄａｔｅ／１は１つの依存ｃａｎｄｉｄａｔｅ／１しか有していない。用語「／１」の使用は１つの引数（ａｒｇｕｍｅｎｔ）の述語を意味する。２つ、３つ、またはそれ以上の引数を有する同じ名前の述語は、別の述語とみなされる。
【００８０】
中断されていないすべての前向き連鎖が完了すると、順序依存表が走査され、依存性として生じるが依存性そのものを有していない述語はすべて閉鎖構造（本文脈では、閉世界仮説がこうした述語に有効であることを意味している）に関してマークされ、否定で安全に使用することができる。その後、以前に中断されたルール実行について前向き連鎖が再開される。その後、２つの状況の１つが発生するまで全体の手順が繰り返されることもある：
１．  前向き連鎖はいかなるルール実行も中断することなく完了した；または、
２．  順序依存表には依存のない依存性はない。この場合、順序依存表の述語はすべて閉じられている。これは、それが有効であるかどうかを知らずに閉世界仮説を作ることに本質的に相当するが、これは機能する。というのも、それが有効ではない場合に、複数の否定条件下で偽であると以前想定された推論が初めてなされたときにそれはすぐに検知され、その後、全体のルールエンジンの呼び出しが停止される。
例えば、キャンセルされた／１は、それ自体の順序依存性がないので閉じられるであろうし、疑わしいルールは、前向き連鎖の次のラウンドで完了するであろう。
【００８１】
より複雑な例は、以下と取り換えられるｃａｎｃｅｌｌｅｄに関するルールを含んでいる。
【００８２】
【数２１】
2016505953.tif 000023
この場合、「承認された」は前向き連鎖推論であると仮定されるため、依存表は、最初の前向き連鎖を実行後、以下のように見えるだろう。
【００８３】
【数２２】
2016505953.tif 000024
【００８４】
この表では、「ａｐｐｒｏｖｅｄ／１」だけが、それ自体の依存性を持つことなく表に現れる。表がグラフ（数学的な有向グラフ）として解釈される場合、ａｐｐｒｏｖｅｄ／１はただ一つのリーフノードである。したがって、中断されたルールの実行が新しい前向き連鎖の実行で再開される前、ａｐｐｒｏｖｅｄ／１は閉じている。ｃａｎｃｅｌｌｅｄ／１は、任意の新しいｃａｎｃｅｌｌｅｄ／１の事実がａｐｐｒｏｖｅｄ／１を含む条件の否定によって推論され得る場合、知られるまで閉じておくことはできない。したがって、第２の実行はｃａｎｄｉｄａｔｅ／１をもう一度中断するが、今回は、ｃａｎｃｅｌｌｅｄ／１は依存性がなく閉じることができる。第３の実行は中断することなく完了し、前向き連鎖アルゴリズムは完了するだろう。
【００８５】
サイクルが依存性グラフで生じない限り、この前向き連鎖アルゴリズムは常に否定の取り扱いに成功する、つまり、それは、上の状況２では終わらない。さらに、周期的な依存性が生じれば、状況２は結果として成功に終わることもあるが、対応する述語がそれよりも前に閉じることができたという推測の仮定と矛盾する推論が依然としてなされることもあるため、失敗に終わることもある（証明の停止）。
【００８６】
図１には、ルールエンジンと協働して動作するプロセスエンジンによって処理されるような、否定を含む前向き連鎖ルール、あるいは否定を含む後向き連鎖と前向き連鎖のルールの組み合わせを例証するフローチャートが示されている。ステップ（１００）では、ルールの実行中に、否定の内部で遭遇するそれぞれの述語を確認して、それが推論されたが依然として閉じられていないものとしてマークされているかどうかを決定する（ルールエンジンの記号表でこうしたものを示すフラグがある）。そうでない場合、ルールは正常なものとして実行され続ける（ステップ１０２）。さもなければ、試みられているその事実（最新のルール実行について引き金を引く事実）について、ルールの実行は中断され、ルールとその依存性の述語が順序依存表に加えられる（ステップ１０４）。ステップ（１０６）では、より多くの試みられていない事実がある場合、次の試みられていない事実はすべてのルールに対してステップ（１００）と協働して試みられる（ステップ１０８）。すべての事実がルールに従って完了するまで処理されるか、あるいは、ステップ（１０４）で中断される場合、順序依存表が走査される（ステップ１１０）。述語が表に列挙されるが依存性がない場合（ステップ１１２）、述語が閉鎖構造についてマークされる（ステップ１１４）。表に追加の述語がある場合（ステップ１１６）、プロセスは（ステップ１１２）に戻る。追加の述語がない場合、ステップ（１１９）では、チェックを行って、任意の（つまり、少なくとも１つの）述語が閉鎖構造についてマークされているか否かを決定し（つまり、ステップ１１４はそのループ中で０回行われた）、閉鎖構造についていかなる述語もマークされなかった場合には、順序依存表にある残りのすべての述語は閉じられる（ステップ１２０）。少なくとも１つの述語がステップ（１１９）で閉鎖構造についてマークされた場合、中断されたルールの実行はステップ（１１８）で再開される。
【００８７】
前向き連鎖と後向き連鎖のルール（否定を含む）の組み合わせは十分に単純化されたように思えることもあるが、この特定の組み合わせはさほど重要ではない。上記のように、保険会社の解は前向き連鎖のみを使用したものであり、第五世代コンピュータープロジェクトは後向き連鎖のみを使用したものである。前向き連鎖は駆動されたデータまたはイベントであり、一方で、目標があって解を必要としているときには、後向き連鎖は演算に優れたものである。前向き連鎖は事実を前処理して推論を作成し、その一方で、後向き連鎖は、事実を考慮して最良の解を見つけ出そうとする。ルールを組み合わせることで、両方のルールの力を利用することが可能となる。例えば、ルールを組み合わせて、後向き連鎖ルールや前向き連鎖ルールそのものを使用することなく、後向き連鎖ルールまたは前向き連鎖ルールに事実を適用することができる。上に議論した否定の問題を取り扱うプロセスエンジンによってこのような手法でルールを組み合わせることは行われておらず、結果は非常に強力なものであり、望ましい上記の特徴の多くを生み出す。
【００８８】
上に記載されたルールエンジンの実施形態を利用するために、そのセマンティックな詳細と、それをどのように使用することができるかについてもっと理解を深めることが必要とされている。ルールと事実の構築において、事実は、０以上の引数と一緒に述語記号として形式的に表される。例としては以下のものが挙げられる。
【００８９】
【数２３】
2016505953.tif 000025
【００９０】
こうした形式化した事実の意味は意図したヒトの解釈に依存する。この解釈は、述語記号へと関係式を抽象化する方法に関する公式または非公式な語彙、地域や世界の条約についての決定を含んでいる。上記の例を使用して：
“ｈｏｌｉｄａｙ（休日）”は、今日が休日であることを意味し得る。
“ａｍｏｕｎｔ（量）（１７０）”は、注文が１７０の通貨単位に相当することを意味し得る。
“ｓｅｒｖｉｃｅ（サービス）（ｔａｋｅｏｕｔ（テイクアウト））”は、顧客が消費される調理済みの食事を買うことを意味し得る。
“ｌｏｃａｔｉｏｎ（位置）（“Ｓｕｎｄｂｙｂｅｒｇ”）”は、Ｓｕｎｄｂｙｂｅｒｇは顧客が配達される注文した商品を受け取りたいと願う位置である。
“ｄｅｐｅｎｄｓ（依存する）（ｍａｒｇｈｅｒｉｔａ（マルゲリータ），ｂａｓｉｌ（バジル）”は、ピザマルゲリータが新鮮なバジルの入手可能性に依存していることを意味し得る。
【００９１】
述語記号は文字列（ｓｔｒｉｎｇ）に制限されない。より記述的な文字列は  単語を分離する下線文字を使用することで、あるいは一重または二重引用符で全体の文字列を囲むことで、使用することができる：
【００９２】
【数２４】
2016505953.tif 000026
【００９３】
これは明瞭さの増加に貢献し得ることもあるが、余計な符号が増え、抽象化の喪失はすべての肯定的な結果を容易に否定しかねない。結局、それはプログラマが最終的に責任を負う個人的判断なのである。
【００９４】
ある述語の引数は、対応する事実が「話題にしている」物体を表す。例えば、事実ａｍｏｕｎｔ（１７０）は数１７０について何かを言う。つまり、それは順序の量である。事実ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，ｂａｓｉｌ）はピザの種類であるｍａｒｇｈｅｒｉｔａとハーブのｂａｓｉｌの類のことを言う。形式論理は記号のｍａｒｇｈｅｒｉｔａまたはｂａｓｉｌが何を意味しようとさほど気にせず、そのもっとも純粋な形態で論理は１７０が何を意味しているのかさえ気にしない。それが通常の数であるという考えは多くの可能な解釈の１つに過ぎない。純粋な形式論理で重要なただ一つのことは、根本的な真理が公理または経験的観察を記述する偶然的真理として当然のものとみなされる場合、真理の様々な表現が真理の他の表現にいかにして関連付けられるのかということである。したがって、すべてのオブジェクトは、記号定数（原子用語）として、または他のオブジェクトの表現の関数として、単なる抽象記号として表される。オブジェクトのこの抽象的な表現は「エルブランの項」として知られており、フランスの数学者ジャック・エルブランが１９２０年代に発明したものである。
【００９５】
エルブランの項のセットは帰納的に定義される：
１．どんな定数記号もエルブランの項である。例：ｆｏｏ、ｘ、４２、−３．１４、「私はセイウチである」
２．エルブランの項のリストに適用される関数記号もエルブランの項である。例：ｆｏｏ（ｂａｒ）、ｆ（ａ，ｂ，ｃ）、ｆ（ｇ（ａ，ｆ（ｂ）），ｃ）
【００９６】
関数記号と定数記号は、述語記号（前段落に記載）と同じシンタックスを有している。英大文字または下線で始まる記号が論理変数として解釈されるため、こうした名前は、引用符で囲まれない限り、定数記号、関数記号、または述語記号に使用することができないことに注意する。
【００９７】
プログラミングの観点から、引数を含む複合したエルブランの項は、包括的なデータ構造のコンストラクター（他のタイプの言語で一般的な同型性の一種）として見られることもある。ゼロ−引数の述語は論理的な観点から見れば単なる原子的命題であることにさらに留意されたい。たとえこうした命題が複数の意味解釈でオブジェクトについて一般に話すとしても、こうした状況は形式概念ではまったく目に見えるものではなく、この概念下では命題はあらゆる意味で不明瞭である。ゼロ引数の述語しか含まず、それ以外には何も含まない述語論理学は、あらゆる点で命題演算と等価である。
【００９８】
いくつかの事実、ルール、および項は、正常な関数表記の代わりに演算子表記で、例えば、ｏｐ（ｘ，ｙ）の代わりにｘ  ｏｐ  ｙ、あるいはｏｐ（ｘ）の代わりにｏｐ  ｘなどと書かれることもある。これは純粋なシンタックスシュガーであり、セマンティクスに関する限り、まったく関連性はない。例えば、エルブランの項ｓｑｒｔ（３＊＊２＋４＊＊２）は、表面的なシンタックスを除けば、あらゆる点で、エルブランの項ｓｑｒｔ（’＋’（’＊＊’（３，２），’＊＊’（４，２）））と完全に等価である。
【００９９】
演算子記号はすべてあらかじめ定義され、その名前と先行関係が以下に見られる。固有の演算子記号により、通常表現される方法で演算式を書くことが容易になる。しかしながら、純粋な述語論理学では、こうした式の自動解釈は存在しない。演算式の評価は、単に「演算意識の高い」固有の述語の特定のセット：ｅｖａｌ，＜などでのみ生じる。さらに、単一化述語「＝」は、単にエルブラン項の構造に関するだけであり、したがって、例えば、２＋２＝４は実際には偽である。なぜなら‘＋’（２，２）と４は、２つの明確に異なるエルブランの項だからである。しかしながら、ｅｖａｌ（２＋２，４）は真である。なぜなら、ｅｖａｌは演算式を数値に変換するからである。
【０１００】
ルールは純粋な述語論理学を使用して表現される。技術的な話をすると、ルールは、エルブラン項の領域上で一次のホーン節と呼ばれる論理文のフォームによって表される。これは、全てのルールには論理的な解釈があり、この解釈は十分に定義され、任意の特定のルールエンジンのインプリメンテーション、または任意の特別なコード化とは無関係であることを意味している。さらに、これは、ルールエンジンの呼び出しがいかなる副作用も持ちえないことと、ルール内のすべての表現が指示的透明性を有することも意味している。
【０１０１】
１階論理とホーン節を使用する理由は、この組み合わせによりルールの導出を数学的かつ演算的に扱いやすくなるということにある。１階のホーン節向けの効率的な論証アルゴリズムがあり、多項式時間に純粋に命題のホーン節を証明することができることが知られている。純粋なホーン節モデルは、ｉｆ−ｅｌｓｅ論理とともに失敗による否定で拡張され、その１階の解釈が無限の公理型としてしか理解され得ない多くの固有の述語もある。しかしながら、これらの拡張のいずれにも任意の方法で純粋論理から逸脱するセマンティクスはない。
【０１０２】
本ルールエンジンの実施形態によって使用される２つの一般的な推論方法：上記のように、前向き連鎖と後向き連鎖がある。前向き連鎖では、ルールエンジンは１セットの基本的な事実から始め、こうした事実とマッチする条件を有するルールを見つけ、このルールから推論する。その後、こうした推論は新しい事実とされ、新しい推論が作られなくなるまで、あるいは複数のルールが論理的矛盾を示す偽を推論するまで、このプロセスは繰り返される。後向き連鎖では、ルールエンジンは、変数を含むこともある述語として表現されたクエリーで始まる。この述語は基本的な事実またはルールからの推論のいずれかであると仮定され、ルールエンジンはどのような条件下でこの述語が真であるのかを見つけ出す。述語が１つ以上の事実とマッチする場合、これらの事実はクエリーに対する解を構成する。述語がルールからの推論と一致する場合、そのルールのそれぞれの条件は後向き連鎖のクエリーとして処理され、ルールを呼び出したクエリーに対する解はすべての条件に共通する解集合となる。本明細書に記載された言語は、特定の実後にどちらの方法を使用するべきかを特定する表記法を用いて、前向き連鎖と後向き連鎖の両方を支持する。それぞれの述語は前向き連鎖ルールまたは後向き連鎖ルールによって指定され、これらは構文的に別のものである。第３のタイプの述語：一連の基本的な事実によって指定される事実の述語もある。
【０１０３】
前向き連鎖ルールでは、以下のように、右側に定義される述語、左側に条件を書く：
【０１０４】
【数２５】
2016505953.tif 000027
あるいは代替的に、含意記号（「＝＞」）は以下のように使用することができる：
【０１０５】
【数２６】
2016505953.tif 000028
【０１０６】
ｆｉｓｈ／１（つまり１つの引数を含むｆｉｓｈという名の述語）の上記の定義が、基本的な事実ａｑｕａｔｉｃ（ｎｅｍｏ）とｈａｓＧｉｌｌｓ（ｎｅｍｏ）が真であるであるコンテキスト中にあれば、前向き連鎖は事実ｆｉｓｈ（ｎｅｍｏ）を推論し、証明された事実のセットにそれを加えるだろう。その後、この新しい事実は、その条件にｆｉｓｈ（Ｘ）を含むすべての前向き連鎖ルール（こうした任意のルールが存在する場合）を誘発して、あたかもそれが基本的な事実であるかのように処理される。
【０１０７】
前向き連鎖は、事実の比較的小さなセットによって記述され得る分類学（分類）のようなもの非常に役立つ。上記の例はわずか２つの推論規則しか示していないが、より複雑なシナリオでは何千もの分類規則があり得る。そのような場合では、前向き連鎖は、その条件がルールの総数ではなくむしろ事実の小さなセットの中にある述語のみを含むルールの数に比例した実行回数を保証する。これは以下に記載される後向き連鎖とは全く異なる。
【０１０８】
後向き連鎖ルールでは、以下のように、左側に定義される述語、右側に条件を書く：
【０１０９】
【数２７】
2016505953.tif 000029
【０１１０】
代替的に、同じ述語定義は以下のように２つの長い矢印（「――＞」）の節を使用して書くことができる：
【０１１１】
【数２８】
2016505953.tif 000030
【０１１２】
述語ｃｏｎｎｅｃｔｅｄ／１は、ｒｏｍａという名のノードに接続されるネットワーク中のすべてのノードについて真である。ノードの間の直接的なリンクは、以下のように基本的な事実として与えられる：
【０１１３】
【数２９】
2016505953.tif 000031
【０１１４】
上記の節を再度参照してクエリーｃｏｎｎｅｃｔｅｄ（ｍｉｌａｎｏ）に答えるために、後向き連鎖は、ｃｏｎｎｅｃｔｅｄ／１の定義に対してクエリーをマッチさせることから始まるであろう。ｒｏｍａとｍｉｌａｎｏが２つの別々の定数記号であるので、最初の節はマッチしない。しかし、第２の節は、２つのクエリーｌｉｎｋ（ｍｉｌａｎｏ，Ｂ）とｃｏｎｎｅｃｔｅｄ（Ｂ）を生成して、Ａ＝ｍｉｌａｎｏとマッチする。これらのクエリーの最初の方は、Ｂの可能な値、この場合ではＢ＝ｇｅｎｏｖａとＢ＝ｔｏｒｉｎｏを決定する。これにより残りのクエリーについて２つの選択肢：ｃｏｎｎｅｃｔｅｄ（ｇｅｎｏｖａ）とｃｏｎｎｅｃｔｅｄ（ｔｏｒｉｎｏ）がもたらされる。これらの代替的な問合わせの両方に後向き連鎖が適用され、最初の方はｃｏｎｎｅｃｔｅｄ（フィレンツェ）を生成し、これがｃｏｎｎｅｃｔｅｄ（ｒｏｍａ）を生成し、これはｃｏｎｎｅｃｔｅｄ／１の定義における最初の節とマッチして、真であるクエリーを生成し、論証の連鎖を終える。
【０１１５】
後向き連鎖は検索と意思決定に非常に役立ち、ルールが比較的わずかなケースしかなく、事実の数が多い際に、とりわけ効率的である。上記の例では、数百万の余分なｌｉｎｋ／２の事実を追加しても、当初のクエリーの論証にこうした余分な事実がまったく必要とされない限り、当初のクエリーの実行時間に少しも影響しない。このことは、すべての事実が必要か否かにかかわらずルールにマッチする前向き連鎖とは全く異なる。
【０１１６】
後向き連鎖ルールについては、定義する節は常に相互排他的である。これは設計によるものである：それぞれの節について、すべての以前の節に関する選択条件はすべて暗黙的に否定される。これは、後向き連鎖に任意のホーン節を使用する言語と比較して、セマンティクスを制限する。この設計の利点は、「決定論的な選択の論理」の記述と比較して以下に説明される。
【０１１７】
後向き連鎖の定義は値を演算するのにも役立つ。例えば、上に列挙されたリンク事実は、以下のようなリンクするノードの間の距離を含むように以下のように拡張された場合：
【０１１８】
【数３０】
2016505953.tif 000032
別のノードからのｒｏｍａまでの距離は、以下の述語によって演算することができる：
【０１１９】
【数３１】
2016505953.tif 000033
【０１２０】
クエリーｄｉｓｔａｎｃｅ（ｍｉｌａｎｏ，Ｘ）に対する解は、後向き連鎖によってｄｉｓｔａｎｃｅ（ｍｉｌａｎｏ，１５０＋２７０＋３００＋０）であると演算されるだろう。上に議論されるように、Ｘ＝Ｙ＋Ｚは演算を行わず、エルブランの項を単一化するだけである。従って、Ｘについて解いた値は、記号定数７２０ではなく複合項１５０＋２７０＋３００＋０である。後者を演算するために、定義はｅｖａｌ／２を用いて合計を評価しなければならない：
【０１２１】
【数３２】
2016505953.tif 000034
【０１２２】
同じ述語について異なるタイプの定義を混合することはできない。例えば、ｆｏｏ／３が後向き連鎖ルールを有する場合、その後件としてｆｏｏ／３を有する前向き連鎖ルールはあり得ない。
【０１２３】
しかしながら、後向き連鎖のクエリーで前向き連鎖の述語を使用することは可能であり、前向き連鎖ルールにおいて条件として後向き連鎖の述語を使用することも可能である。最初のケースはかなり明瞭である：すべての前向き連鎖の推論を行ったとき、前向き連鎖の述語は後向き連鎖のコンテキスト中の基本的な事実のように見えて、基本的な事実が使用されるのと同じ方法で使用されることもある。
【０１２４】
第２のケースは若干より複雑である。後向き連鎖のクエリーは、以下のように、前向き連鎖ルールの条件の中で組み合わされることもある：
【０１２５】
【数３３】
2016505953.tif 000035
【０１２６】
基本的な事実ｄｅｐａｒｔｕｒｅ（ｍｉｌａｎｏ）とｄｉｓｔａｎｃｅ／２の後向き連鎖の定義を仮定すると、このルールは、後向き連鎖によってＹを演算して、例えば、７２０を提供し、その後、前向き連鎖と後向き連鎖の組み合わせに関して上記されたように、前向き連鎖の推論ｔｒａｖｅｌ（７２０）を行う。
【０１２７】
非決定性は、ルールの１回の呼び出しが２以上の可能な解をもたらすことができる際のものである。例えば、以下の基本的な事実を仮定する：
【０１２８】
【数３４】
2016505953.tif 000036
【０１２９】
クエリーｄｅｐｅｎｄｓ（Ｘ，Ｙ）は、ＸとＹに関する値の３つの組み合わせを生成する：
【０１３０】
【数３５】
2016505953.tif 000037
同様に、クエリーｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，Ｘ）はＸについて２つの値を生成する：
【０１３１】
【数３６】
2016505953.tif 000038
他方で、クエリーｄｅｐｅｎｄｓ（ｃａｐｒｉｃｃｉｏｓａ，Ｘ）は１つの独特な解を有する：Ｘ＝ａｒｔｉｃｈｏｋｅｓ。同様に、クエリーｄｅｐｅｎｄｓ（Ｘ，ａｎｃｈｏｖｉｅｓ）はなんの解も有していない。考慮すべき必要のある代替的な結果がないので、こうしたケースは決定論的と呼ばれる。
【０１３２】
非決定論的なクエリーを行う能力は強力であると同時に危険でもある。この能力は２つ以上の事実間のマッチに依存する条件を表現しやすくすることから強力である。以下のルールを例とする：
【０１３３】
【数３７】
2016505953.tif 000039
【０１３４】
このルールは、ルールの条件部分における事実の述語に従って、提供される品物のすべての購買者と製品のすべての有資格販売者をマッチさせる。見つかったすべてのマッチについて、１セットのｔｒａｄｅ／３の事実が推論として生成される。これはすべて一行のコードによって行われる。危険な部分は、予期しない非決定性によって手に負えない量の仕事を解決するように要求する一見単純そうなルールを書くことが非常に簡単である――各々がより多くの解にマッチする多くのサブクエリーが得られ、その結果として組み合わせ爆発を引き起こす――ということである。この非決定性に対する救済策は決定論的な選択の論理であり、これについては以下にさらに説明する。
【０１３５】
否定は偽の文から真の文を作り、真の文から偽の文を作る。否定は、基礎となる導出手順の制限により、限定されたフォーマットにおいて本明細書で支持されるのみである。最も注目すべきは、基本的な事実と推論は否定することができないことである。これらは常に肯定的なければならない。例えば、以下のように書くことは法的なシンタックスではない：
【０１３６】
【数３８】
2016505953.tif 000040
【０１３７】
別の制限は、否定の証拠が、十分な理由のある変数に値を代入することはできないということである。例えば、いくつかの条件が、その部分の１つとして「ｎｏｔ  ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，Ｘ）」を含むと仮定する。これは、Ｘについての無限数の解で真実であると理論上は証明することができる：
【０１３８】
【数３９】
2016505953.tif 000041
【０１３９】
しかし、そうすることは明らかに非実用的であることから、否定ｎｏｔ  ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，Ｘ）を導出することが可能な状況は以下のとおりである：
１．Ｘには条件の他のいくつかの部分の証拠によって値ａｎｃｈｏｖｉｅｓが代入される。ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，ａｎｃｈｏｖｉｅｓ）を記述する事実がないため、否定は真であると証明される。
２．Ｘには条件の他のいくつかの部分の証拠によって値ｂａｓｉｌが代入される。ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，ｂａｓｉｌ）を記述する事実がないため、否定は偽であると証明される。
３．ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，Ｘ）にマッチする事実が全くないため、否定は偽であると証明される。したがって、否定はすべてのＸについては真であると証明されるため、値を代入する必要はない。
４．事実である代わりに、ｄｅｐｅｎｄｓ／２は、すべてのＸについて真である述語として定義され、例えば、ｄｅｐｅｎｄｓ（ｍａｒｇｈｅｒｉｔａ，Ｘ）−−＞真であり；したがって、否定は、すべてのＸについて偽であると証明されるため、値を代入する必要はない。
【０１４０】
他のすべての場合、否定の証明は中断される。否定を含む条件は、偽である条件の他の複数の部分によって依然として偽であると証明されることもあるが、真である条件に依存する任意の証明も同様に中断され、結果として最上位のクエリーについて保留される可能性がある。
【０１４１】
少数の余分な述語とルールを導入することで、否定の事実が「エミュレートされ」得ることに留意されたい。例えば、ルールが事実の述語ａｃｃｅｐｔｅｄ（Ｘ）を使用する場合、別の事実の述語ｎｏｔ＿ａｃｃｅｐｔｅｄ（Ｘ）を導入して否定のケースを表すことができる。これが形式的に肯定的な事実であることから、それは制限なくルールの中で使用することができる。解釈上の不整合性を回避するために、以下のフォームのルールが加えられることもある：
【０１４２】
【数４０】
2016505953.tif 000042
「偽」が推論されるときは常に、証明は中断され、矛盾の検出の信号が埋め込みアプリケーションに出される。
【０１４３】
集団的に排他的である、例えば以下などの任意のセットの事実を取り扱うために、同じ技術を拡張させることができる。
【０１４４】
【数４１】
2016505953.tif 000043
左側の条件が真であれば、矛盾エラーの信号が出される。
【０１４５】
決定論的な選択の論理は、条件のせいぜい１つが同時に真であり得るような方法で、述語がいくつかの節によって定義される際のものである。例えば、何かが、事実ｇｏｏｄ、ｂｅｔｔｅｒ、およびｂｅｓｔの真の値に依存して、カテゴリーｓｔａｎｄａｒｄ、ｇｏｌｄ、またはｐｌａｔｉｎｕｍの１つに分類される場合である。以下のアプローチを試みることもある：
【０１４６】
【数４２】
2016505953.tif 000044
しかしながら、例えば、ｇｏｏｄとｂｅｔｔｅｒが両方とも共に真である場合には、これは期待されるようには機能しない。なぜなら、２つの事実：ｃａｔｅｇｏｒｙ  （ｓｔａｎｄａｒｄ）とｃａｔｅｇｏｒｙ（ｇｏｌｄ）が推論されるからである。これらの２番目だけが望ましいため、以下のように条件はより一層正確でなければならない：
【０１４７】
【数４３】
2016505953.tif 000045
それぞれの節は先行する節の条件を否定する。これは、ｉｆ−ｔｈｅｎ−ｅｌｓｅシンタックスを用いて、後向き連鎖の述語として、より判読可能な方法で表現することができる：
【０１４８】
【数４４】
2016505953.tif 000046
【０１４９】
これは「ｅｌｓｅ」の論理的な意味を示す：以前の条件を暗黙的に否定するのは結合記号である。本明細書で述べられる後向き連鎖の述語の定義はすべて「ｅｌｓｅ」によって決定論的な選択の論理を使用する。このことは同様に「−−＞」シンタックス」によって定義される述語に当てはまる。上記の例は矢印のシンタックスでこのように見える：
【０１５０】
【数４５】
2016505953.tif 000047
それぞれの節とその次の節との間には暗黙の「ｅｌｓｅ」がある。コロン（「：」）と矢印（「−−＞」）との間の条件はガード（ｇｕａｒｄ）と呼ばれる。ガードが真であると証明されるまで、節の残り（矢印の右まで）の残りを導出する試みはなされない。
【０１５１】
述語の引数がパターンマッチング項を含む場合、このパターンマッチングは技術的にはガードの一部でもある。コロンで定められた条件が存在しない場合、ガードは引数パターンのマッチングのみからなる。
【０１５２】
ガードの証拠は、ガードの外側にある変数には値を代入することができない。例えば、次の節と基本的な事実を仮定する：
【０１５３】
【数４６】
2016505953.tif 000048
論理上、ｓｅｃｕｒｉｔｙ（Ｐ，ｌｏｗ）は、ａｌｉｃｅおよびｂｏｂとは異なるＰのすべての値について真であるが、こうした値は、否定に関して上に記載された理由と同じ理由で、任意の実際的な方法では証明によって生み出すことができない。従って、ガードの証明は保留にされ、その結果、クエリーが、証明のいくつかの他の部分によってＰに値を代入する複数のより大きな問合わせの一部ではない限り、クエリーに対する解は保留された証明である。
【０１５４】
場合によっては、ガードが外部変数に値を代入することができないという制限は、最初の節のガード内で自由な余分な変数を導入することによって克服することができる：
【０１５５】
【数４７】
2016505953.tif 000049
ここで、第１と第２の節の間での選択は、クエリー内のＰに任意の値を代入する必要なく行われる。第１の節が選ばれる場合、ＰにはＸ＝Ｚによって１つの値が代入され、あるいは、いくつかの値が非決定論的に（例えば、ａｌｉｃｅとｂｏｂ）が代入されることもある。しかし、セマンティクスは変更される：セキュリティ（Ｐ，ｌｏｗ）は、ｔｒｕｓｔｅｄ（Ｚ）がすべてのＺについて偽である場合にのみ、すなわち、ｔｒｕｓｔｅｄ／１の事実がないとき、真である。上記の場合、ｓｅｃｕｒｉｔｙ（Ｐ，ｌｏｗ）がすべてのＰに真であるため、Ｐにはどんな値も代入されない。
【０１５６】
後向き連鎖において決定論的な選択の論理を常に使用するという利点は、後向き連鎖の間に節を試してみても非決定性は決して導入されないということを保証することにある。非決定性は事実のクエリーで依然として生じることもあるが、このような場合はもっと簡単に予言および認識できる。事実のクエリーを用いることは、非決定性が暗に望ましい後向き連鎖ルールを書く推奨される方法である。前向き連鎖は決定論的な選択の論理を用いない。それは意味をなさないことになる。というのも、前向き連鎖の間はいかなる予測可能な順序でも節の条件は検査されないからである。
【０１５７】
理論上、ｉｆ−ｔｈｅｎ−ｅｌｓｅは決定論的な選択を行う唯一の可能な方法ではない。別の可能性はＮ−ｗａｙ  ｅｘｃｌｕｓｉｖｅ−ｏｒであり、それ以外のものも多くある。しかしながら、ｉｆ−ｔｈｅｎ−ｅｌｓｅはあらゆる人に知られており、証明アルゴリズムを非常に効率的に実行することができるという長所を持つ。
【０１５８】
「閉世界仮説」とは、知られていないかつ証明されていないものが偽であるという仮定である。この仮定は、ルールとデータが目下の目的のために定義によって「完全である」という形式上のコンテキストにおいて適切である。例えば、ある会社は、会社のお金を借りている借主の記録を有していることもある。たとえお金を借りているものの借主として記録されていない人が存在する可能性はあるとしても、会社の借主の記録の中に見られない非借主としてすべての人を形式的に処理することは合理的である。本実施形態では、閉世界仮説は、否定が真実であり、（等しく）ガードが偽であることを証明するために必要である。それ以外には閉世界仮説は違いをもたらさない。
【０１５９】
否定と決定論的な選択の論理はそのようなに強力なツールであることから、閉世界仮説は、反対の仮定が指定されるすべての述語について暗に作られる。反対の仮説は「開世界仮説」と呼ばれ、本実施形態にはそれについて特別な宣言があり、閉世界仮説の対象外の述語にこれを使用することができる。例えば、以下のとおりである：
【０１６０】
【数４８】
2016505953.tif 000050
上記の宣言と事実を考慮して、クエリーａ（ｂａｒ）とｃ（ｆｏｏ，ｂａｚ）は、事実ｂが存在しないためにクエリーｂがそうであるように、証明を保留させるであろうが、ｂが開世界仮説であるという事実ゆえにｂが偽であるという結論に至ることはない。クエリーｅ（ｂａｒ）がそうであるように、クエリーｄは他方で偽であると証明されるであろう。
【０１６１】
事実と前向き連鎖の述語だけが開世界仮説として宣言されることもある。後向き連鎖の述語は常に閉世界である。というのも、こうした述語は、述語の定義が常に完全な決定論的な選択の論理を使用するためである。構文上、例で示されるように、開世界宣言はメタ（ｍｅｔａ）のステートメントによってタグ付けされる。メタのステートメントの完全なリストは以下で見ることができる。
【０１６２】
単純な部分から複雑なシステムを容易に構築するために、本ルールエンジンのルールシンタックスは、名前空間向けの組み込みサポートを備えている。それぞれの記号は実際には２つの部分：名前空間の冠とローカル名からなる。例えば、以下である。
【０１６３】
【数４９】
2016505953.tif 000051
上記の例において、名前空間の冠はｆｏｏであり、ローカル名はｂａｒである。名前空間が与えられない場合、暗黙の名前空間が与えられる。デフォルトの暗黙の名前空間がメインであり、したがって、以下の場合；
【０１６４】
【数５０】
2016505953.tif 000052
記号ｂａｒはメイン：：ｂａｒとして解釈されるだろう。
【０１６５】
この暗黙の名前空間は、コードに名前空間の宣言を加えることにより変更することができる：
【０１６６】
【数５１】
2016505953.tif 000053
【０１６７】
この宣言の後のｂａｒに関するどんな言及もｆｏｏ：：ｂａｒとして解釈されるだろう。また、同じことが、名前空間の宣言の後に言及される他の記号（例えばｂａｚ）にも当てはまる。
【０１６８】
しかし、ただ１つの特定の記号に関する暗黙の名前空間を変更することも可能である。これは「インポート」宣言によりなされる：
【０１６９】
【数５２】
2016505953.tif 000054
この場合、ｂａｒに関するどんな言及もｆｏｏ：：ｂａｒとして解釈されるが、いくつかの他の名前空間が名前空間宣言によって指定されていなければ、他のすべての記号は名前空間ｍａｉｎを得るだろう。新しい名前空間を導入するためには特別な宣言は必要ではない。例えば、ａｓｄｆｇｈｊ：：ｓｏｍｅ＿ｓｙｍｂｏＩが書かれている場合、この記号は、「ａｓｄｆｇｈｊ」が他の場所で言及されているか否かにかかわらず、名前空間ａｓｄｆｇｈｊを有している。しかし、本明細書で異なるように取り扱われる４つの名前空間があり、以下のとおりである：
【０１７０】
【表１】
2016505953.tif 000055
【０１７１】
私的な名前空間に名前を付ける際、これらの４つの名前空間タグは避けなればならない。インポートは、パーサーに対する、特定の記号に再度名前を付けることになるという単なる命令であることに留意されたい。ユーザーが述語の定義に関してｅｖａｌなどの記号を使用したい場合、ｅｖａｌが通常はｃｏｒｅの名前空間からあらかじめインポートされるという事実にもかかわらず、ユーザーは単純に以下のように書くことができ：
【０１７２】
【数５３】
2016505953.tif 000056
その後、望みどおりにｅｖａｌを使用することができる。なぜなら、これはｃｏｒｅ：：ｅｖａｌを使用するいかなるコードも妨害しないからである。
【０１７３】
論理に基づいたソフトウェアにはすべてそれ自体の特異な限界があり、これは設計上の考慮すべき事案やインプリメンテーションに関連するコスト／利益のつり合いによる。しかし、論理そのものに固有なそれ以外の限界もある。こうした限界は、以下を含む数理論理学の定理の当然の結果として生じるため、論理を使用するどんなツールもこうした限界の影響を受けるという意味で、工学的観点から交渉の余地がない：
１．１階述語論理は再帰的に決定不可能であり、すなわち、いかなるアルゴリズムも与えられた式が真であるか偽であるか決定することができない。例外は、すべての述語が、一般的な関係の代わりに１つの引数の特性について話すことを制限されるときである。ゼロ引数の場合（別名、命題論理学）も例外である。
２．命題論理学は決定可能であるが、真理値を解くことはＮＰ完全問題である。
３．ホーン節のみからなる命題論理学は、多項式時間で可解である。しかしながら、ホーン節は、あらゆる起こり得る論理文の部分集合を表わすことができるだけである。
【０１７４】
上記の説明では、最初の限界は、１階述語論理が非常に表出的であるため、解くことが不可能な問題を記述するために使用され得るということを単に意味するだけである。有名な例はアラン・チューリングの停止問題である：コンピュータがプログラムを実行した後に停止する場合は真であり、プログラムが永久にループする場合は偽であるという論理式を書くことは可能である。しかし、その式が真であるか偽であるかどうかを決定することができるアルゴリズムは存在しない。第２の限界は、多くの変数を含まない式を考慮すると、命題が真であるか偽であるかを決定することは原則としては常に可能であるが、我々の知る限り、問題の大きさ（つまり、関与する事実とルールの総量）で指数関数的にコストがかかる。第３の限界は、変数を含まないホーンを実際に適切な効率で解くことができるとしても、完全な１階述語論理ほど表出的ではないということである。
【０１７５】
述語論理学とは、「すべて」または「いくつか」に関して、例えば、「数匹の猫は黒い」または「クレタ人はみんな嘘つきである」などと主張する命題に関するものである。この後者の句は紀元前６００年ごろのクレタ人の哲学者エピメニデスの作とされる。エピメニデスはクレタ人だったので、これは論理的な逆説の最も初期の例の１つであると考えられている。形式的に、ある述語は、ｎが０、１、２、．．．であり得る場合に、ｎ個のオブジェクト（述語の引数）の関係であり、関係が存在すれば述語は真であり、そうでなければ述語は偽である。述語論理学における命題は通常数量化された変数を含んでおり、これは、「すべてのＸ．．．について」または「．．．ようなＸが存在する」と述べ、その後に続く命題中の変数Ｘを使用することによって導かれる変数を意味する。
【０１７６】
１階述語論理（ＦＯＬ）は、数量化された変数を述語の引数としてのみ使用することができ、述語自体としては決して使用することができない、述語論理学である。したがって、１階論理では、「猫はすべて黒い」と表現することができるが、「すべての論理関係は真である」と表現することはできない。述語論理学は非常に表出的であるが、述語論理文は一般に解くのが非常に困難である。すべての述語がたった１つの引数に制限されない限り、つまり、多角的な関係が許可されない場合、ＦＯＬ中のあらゆる真の（同義語の）命題を証明することができるいかなるアルゴリズムも存在し得ないことが証明されている。
【０１７７】
本ルールエンジンの実施形態は、効率的な証明手順を有するＦＯＬの部分集合を使用する。部分集合は「ホーン節」として知られており、証明手順は「ロビンソンの導出」として知られている。解を返す本ルールエンジンについて書かれたすべてのプログラムは、論理的セマンティクスを有することが保証されており、つまり、任意のこうしたプログラムからの任意の解または結論が常に論理上正しいということを第一原理から証明することができる。しかしながら、解が全く返ってこない状況もある。
【０１７８】
本ルールエンジンの実施形態で使用される演算子は、優先順位の高い順に以下の表で列挙される。右結合演算子はΧ・Ｙとして示され、左結合演算子はＹ・Χとして示される。前置演算子は・Χまたは・Ｙのいずれかとして示され、双方とも結合が含まれていないので同じものを意味する。
右結合演算子は以下のようにネストされる：
Χ・Ｙ・Ζ＝Χ・（Ｙ・Ζ）
そして、左結合演算子は以下のようにネストされる：
Ζ・Ｙ・Χ＝（Ζ・Ｙ）・Χ
演算子の表：
【０１７９】
【数５４】
2016505953.tif 000057
【０１８０】
本ルールエンジンの実施形態は少数の組み込み述語を含んでいる。こうした述語は、事実とルールに導出アルゴリズムを適用することにより証明されるよりもむしろルールエンジン自体によって評価される。ほとんどの組み込みは入力データとして１つ以上の引数と、随意に、いくつかの算出された出力データで単一化される別の引数を使用する。入力データが束縛されていない変数である場合、組み込みは有限値を得るまで停止する。どの引数が入力され、どの引数が出力されるのかはほとんどの述語では明白であるため、どれがどれなのかをここでは明示的に記述しない。
【０１８１】
算術的述語（Ａｒｉｔｈｍｅｔｉｃ  ｐｒｅｄｉｃａｔｅｓ）は、アプリケーションに依存して異なるエバリュエーターを使用することができる。デフォルトは「ｊａｖａ（登録商標）．ｍａｔｈ．ＢｉｇＤｅｃｉｍａｌ」に基づくエバリュエーターである。このことは、すべての数値が有限の長さの任意の精度の１０進数として表わされることを意味する。演算の間の精度の丸めと拡張は、別段の定めのない限り、「ｊａｖａ（登録商標）．ｍａｔｈ．ＢｉｇＤｅｃｉｍａｌ」に従って終わる。
これらの述語は演算式を求める：
【０１８２】
【表２】
2016505953.tif 000058
【０１８３】
演算式は特別な解釈を備えた単なるエルブラン項である。数値定数は対応する数値として解釈される。他の項は以下の表に従って解釈される。
記号定数：
【０１８４】
【表３】
2016505953.tif 000059
【０１８５】
１変数関数：
【０１８６】
【表４】
2016505953.tif 000060
【０１８７】
２変数関数：
【０１８８】
【表５】
2016505953.tif 000061
【０１８９】
本ルールエンジンの実施形態は、外部パラメータを含む項を書くためのシンタックスシュガーを有する。変数が＄記号で始まる場合、それは組み込み述語ｓｙｓ：：ｐａｒａｍによってアクセスされる外部パラメータとして解釈される。例えば、以下のとおりである。
【０１９０】
【数５５】
2016505953.tif 000062
上記は以下と等価である：
【０１９１】
【数５６】
2016505953.tif 000063
ここでＸは他では生じない変数である。
【０１９２】
【数５７】
2016505953.tif 000064
ｓｙｓ：：ｐａｒａｍの正確なセマンティクスはアプリケーションに依存して変わる。例えば、プロセスエンジンでは、プロセス状態遷移が始められる時点でｊａｖａ（登録商標）．ｌａｎｇ．Ｓｙｓｔｅｍ．ｇｅｔＣｕｒｒｅｎｔＴｉｍｅＭｉＩＩｉｓ（）の値を有するＴＩＭＥと名づけられたタイマーによって生成される外部パラメータがある。他方で、スタンドアローンのルールエンジンでは、ｓｙｓ：：ｐａｒａｍは、次のように簡潔に定義される：
【０１９３】
【数５８】
2016505953.tif 000065
ここでパラメータ（Ｘ，Ｙ）はユーザールールによって定義される。
【０１９４】
以下のものは、項に関する記号情報をテストまたは抽出し、こうした情報から新しい項を構築する組み込みの一覧表である。
【０１９５】
【表６】
2016505953.tif 000066
【０１９６】
単純な反射的（Ｒｅｆｌｅｃｔｉｖｅ）「呼び出し（ｃａｌｌ）」プリミティブが実務的な理由のため本ルールエンジンの実施形態に加えられた。理論上、これは１階の論理に対する２階拡張であるが、実際には、それはリフレクティブプログラミングのための制限されたツールに過ぎない。それは便宜上のものにすぎない−−それは、通常の１階の論理構成を用いて簡単明瞭ではあるがより手の込んだ方法では入手することができない機能を提供するものではない。主たる目的は否定を表現する簡単な方法を提供することである。別の用途は、ほかで定義されたルールからのランタイム記号表へのコールバックを可能にすることである。
【０１９７】
【表７】
2016505953.tif 000067
【０１９８】
２つの引数の呼び出し（Ｘ，Ｙ）は、１つの引数の呼び出し（Ｘ）の一種の「非カリー化（ｕｎｃｕｒｒｙｉｎｇ）」バージョンである。例えば、呼び出し（ｐ（Ａ，Ｂ，Ｃ），［Ｘ，Ｙ，Ｚ］）は、呼び出し（ｐ（Ａ，Ｂ，Ｃ，Ｘ，Ｙ，Ｚ））と等価である。
【０１９９】
定義から分かるように、述語はガードの内部からリフレクティブな呼び出しを行わない。このことは、例えば、ｎｏｔ（ｈａｓＦｅａｔｈｅｒｓ（Ｘ））がＸ＝ｇａｒｆｉｅｌｄまたはＸ＝ｆｉｄｏのような解を決して生成することができないことを意味している。代わりに、それは、Ｘがテスト可能な値を得るまで、保留される。
【０２００】
上で示したように、否定は閉世界仮説で理解されることになっている。この仮説は、その節のすべてがそれを解決できない場合に、述語は偽であるとみなされることを意味している。述語を解くこともある最新のルールセットの外部には追加の節は存在し得ない。
【０２０１】
ｏｒの組み込みの定義は、ｎｏｔの組み込みの制限されたバージョンを用いた、ド・モルガンの定理の一応用例に過ぎない。これは単純なテストのコンテキストでは役立つが、本格的な非決定性を導入する選言命題には対処しない。一般的なケースを取り扱う選言命題の述語は、以下のように定義することができる：
【０２０２】
【数５９】
2016505953.tif 000068
しかしながら、選言命題を表現する必要のあるすべてのケースでこうした定義を慣例的に使用することは推奨されない。その理由は、非決定性は高価で予測不能であるため、それが使用されているすべての状況で明確にされなければならないからである。
【０２０３】
存在量化のためのシンタックスシュガーは便宜上のものであり、つまり、存在量化が必要な場合は常に、余分な「ヘルパー（ｈｅｌｐｅｒ）」節を導入することにより、これが全くなくとも行うことができる。全称量化（∀）のためのシンタックスがないことに留意する。全称量化はホーン節の最も外側のレベルで暗黙であり、というのも、変数はすべてその内部に含まれるからである。ホーン節の先行部分が否定の式に形式的に含まれているので、この全称量化は先行部分にのみ含まれる変数の存在量化と完全に等価である。
【０２０４】
【数６０】
2016505953.tif 000069
【０２０５】
この節の典型的な使用は、「ｉｆ  ｔｈｅｒｅ  ｉｓ  ａ  ｄａｎｃｅｒ  ｗｈｏ  ｄｏｅｓ  ｎｏｔ  ｈａｖｅ  ａ  ｐａｒｔｎｅｒ，  ｔｈｅｎ．．．」というようなことを表現する必要があるときである。このような類が単純に条件部分について作用することを期待するであろう：
【０２０６】
【数６１】
2016505953.tif 000070
しかしながら、本ルールエンジンは、「ｉｆ  ｔｈｅｒｅ  ｉｓ  ａ  ｄａｎｃｅｒ  Ｘ  ａｎｄ  ａ  ｔｈｉｎｇ  Ｙ  ｓｕｃｈ  ｔｈａｔ  Ｘ  ａｎｄ  Ｙ  ａｒｅ  ｐａｒｔｎｅｒｓ，  ｔｈｅｎ．．．」ということを意味するものとこれを解釈するが、これは完全に異なる。そして、このことが意図された意味だったとしても、ルールエンジンは条件が真であることを証明することができない。なぜなら、その導出アルゴリズムは条件が真であるいくつかの「ｔｈｉｎｇ」Ｙの少なくとも１つの例を生成するように要求されることになるからであり、これは不可能である。
【０２０７】
その問題は存在量化の使用により解決される：
【０２０８】
【数６２】
2016505953.tif 000071
ここで、意味は「ｉｆ  ｔｈｅｒｅ  ｉｓ  ａ  ｄａｎｃｅｒ  Ｘ，  ａｎｄ  ｉｔ  ｉｓ  ｎｏｔ  ｔｈｅ  ｃａｓｅ  ｔｈａｔ  ｔｈｅｒｅ  ｉｓ  ａ  ｔｈｉｎｇ  Ｙ  ｓｕｃｈ  ｔｈａｔ  Ｘ  ａｎｄ  Ｙ  ａｒｅ  ｐａｒｔｎｅｒｓ，  ｔｈｅｎ．．．」に変更される。
【０２０９】
これは、余分な「ヘルパー」述語が導入される以下の解と意味論的に等価である：
【０２１０】
【数６３】
2016505953.tif 000072
この特定の例ではヘルパー述語は直観的なセマンティクスを有するが、必ずしもそうだとは限らない。
【０２１１】
実施形態では、基本的な時間座標は、Ｊａｖａ（登録商標）の「ｔｉｍｅＭｉｌｌｉｓ」であり、これは、１９７０年１月１日の００：００：００のＵＴＣ（協定世界時）以降の近似的にミリ秒の数である。それは２つの理由で近似である：コンピュータの時計はＵＴＣとは完全に同期していないこともあり、ＵＴＣは、時間座標では考慮されない閏秒を使用している。２００９時点で、１９７０年以降、ちょうど２４閏秒が挿入されたため、経過したミリ秒の真の数は名目上の時間座標よりも２４０００大きい。原子時（ＴＡＩ）は、余分な閏秒を用いてＵＴＣ日を相殺し、その後、ＵＴＣとＴＡＩの間の最初のオフセットを考慮するためにさらに１０加えることで、引き出され得る。
【０２１２】
【数６４】
2016505953.tif 000073
【０２１３】
ｓｙｓ：：ｄａｔｅ複合項の引数は、以下のＪａｖａ（登録商標）フィールドと同じ値を有する：
【０２１４】
【数６５】
2016505953.tif 000074
Ｚｏｎｅ＿ｏｆｆｓｅｔとＤＳＴ＿ｏｆｆｓｅｔがミリ秒であり、Ｙｅａｒが４桁年であることに注意する。引数の残りはそのＰＯＳＩＸ等価物に非常によく似ている。Ｔｉｍｅｚｏｎｅの引数は、ｊａｖａ（登録商標）．ｕｔｉｌ．ＴｉｍｅＺｏｎｅｃＩａｓｓ、例えば、“Ｅｕｒｏｐｅ／Ｚｕｒｉｃｈ”の時間帯の１つに正確にマッチしたものでなければならない。
Ｄａｙ＿ｏｆ＿ｗｅｅｋは１−７の範囲であり、１は日曜である。
Ｄａｙ＿ｏｆ＿ｙｅａｒは１月１日の１である。
ＩＳＯ＿８６０１＿ｗｅｅｋ＿ｎｕｍｂｅｒは、１週目が１月４日を含む週である、ＩＳＯ  ８６０１によって定義されるような週数であり、週数は日曜日と月曜日の間で変わる。
【０２１５】
これらは言語内で定義することができたかもしれないが、便宜上に提供する。
【０２１６】
【表８】
2016505953.tif 000075
【０２１７】
メタのステートメントの一般的なシンタックスは以下のとおりである：
【０２１８】
【数６６】
2016505953.tif 000076
ここで、Ｄｉは、後にファイルで出てくるルールと事実の解釈に影響する宣言である。
以下の宣言は例として示されているように利用可能である：
【０２１９】
【表９】
2016505953.tif 000077
【０２２０】
本ルールエンジンを動作させるためのシステムの実施形態のインプリメンテーションは、多くの異なるやり方で遂行することができる。こうしたシステムのインプリメンテーションを実施するための主な機能要素は、ＪＡＶＡ（登録商標）  ＥＥサーバーを含むこともあり、これは、ルールエンジン、ルール定義と設定ファイルを供するファイルリポジトリ、ＳＱＬデータベース、随意のＳＳＬリバースプロキシー、およびロードバランサ（ｌｏａｄ  ｂａｌａｎｃｅｒ）を含む。開発環境では、ロードバランサはまったく使用されず、システムの残りの要素はすべて同じサーバー上で実行されたが、異なる要素を移動させてマシンを分離し、動作に成功した。ファイルリポジトリが必ずしも均質的なサービスではないことが留意されたい。異なるソース、例えば、備え付けのファイルシステム、ＳＱＬデータベース、ウェブサービス（ＷｅｂＤＡＶまたはプレーンＨＴＴＰ）、ＤＲＯＰＢＯＸなどから、異なるタイプのファイルを出すことができた。しかしながら、本開示の目的のために、ファイルサーバーはＳＱＬベースのウェブサーバであると仮定する。
【０２２１】
図２、３、４、５Ａ、５Ｂ、および５Ｃは、これらの機能要素の異なる構成を示す。図２は基礎的な高可用性アーキテクチャ（２００）、その可用性ゾーンＡ（２０２）と可用性ゾーンＢ（２０４）を示している。ゾーンＡ（２０２）は、ＳＱＬマスターデータベース（２０６）、ファイルリポジトリサーバー（２０８）、およびＪＡＶＡ（登録商標）  ＥＥサーバー（２１０）を含んでおり、ゾーンＢ（２０４）はＳＱＬスレーブデータベース（２１２）、ファイルリポジトリ（２１４）、およびＪＡＶＡ（登録商標）  ＥＥサーバー（２１６）を含んでいる。ロードバランサ（２１８）は適宜２つのゾーン間でクライアントとサービスの要求（２２０）を振り分ける。
【０２２２】
図３はシャーディング（ｓｈａｒｄｉｎｇ）によるスケーリングを示しており、論理シャード（ｌｏｇｉｃａｌ  ｓｈａｒｄｓ）（３０２）のそれぞれは、すべてのプロセスのセットの部分集合に対応する。例えば、論理シャードｋは、ＰＩＤ＝ｋ  ｍｏｄｅ  ｎ（ＰＩＤはプロセスＩＤ番号）のすべてのプロセスであり得る。それぞれの論理シャードは同じような方法で物理的なシャード（３０４）にマッピングされるが、物理的なシャード（３０４）のｍが当初の論理的−物理的なマッピングを変更させることなく増大することを確実にするには、異なるアルゴリズムを使用しなければならないこともある。所定のＰＩＤからの物理的なシャードへのルーティングは、ロードバランサ（２１８）のようにある共有資源を介して行われなければならない。
【０２２３】
図４は、いわゆるフラグメンテーションによるスケーリングを示しており、「フラグメンテーション」は、ワールド・ワイド・ウェブによって遂行されてスケーリングのタイプを指すように意図されている。このインプリメンテーション時、唯一の共有資源は、ウェブのように、ルート・ネーム・サーバーＤＮＳインフラストラクチャーである。領域Ａ（４０４）、領域Ｂ（４０６）、領域Ｃ（４０８）などのクライアント（４０２）の要求を満たすそれぞれの領域は、図３で例証されるようなシャードクラスタ（ｓｈａｒｄｅｄ  ｃｌｕｓｔｅｒ）、図２で例証されるような単一の高可用性クラスタ、またはそれ以外のタイプのクラスタ、あるいは、単一のサーバーのいずれかに対応する。それぞれの領域は完全に自律しており、根本的なインターネットルーティングおよびＤＮＳ解決システムで不可避なものを除けば、争点はない。図４のアーキテクチャに対して本ルールエンジンの実施形態を利用するアプリケーションを適応しても、領域とローカルＰＩＤに対するプロセスＩＤ番号を一般化することが要求されるだけですむ。
【０２２４】
図５Ａ、５Ｂ、および５Ｃは、３つの異なる構成の演算スケーリングを例証する。図５Ａは平行な前向き連鎖を例証しており、入力事実（５０２）は事実集約装置（ｆａｃｔ  ａｇｇｒｅｇａｔｏｒ）（５０４）によって組み合わされ、組み合わされた事実（５０６）は並列のＣＰＵコア（５０８）に振り分けられ、これが事実の組み合わせ（５０６）から推論を行い、その推論に基づいて措置を講じる。本ルールエンジンの実施形態では、これらの措置は等冪であり、推論がなされる順序から独立しており、これはルールエンジンのルールの論理的なセマンティクスの結果である。推論の順序が最終的な結果とは無関係であるので、並列実行は可能性もある。アプリケーションに関するいかなる並列なスピードアップ要因も、当然のことながら、そのアプリケーション中のルール論理の構造に依存するであろう。
【０２２５】
後向き連鎖におけるＯＲ−並列が図５Ｂで例証されており、後向き連鎖は、通常１つの変数を含むステートメント（５１０）を受け取り、ステートメント（５１０）を満たす変数設定の観点から１つ以上の解を見つける。ＣＰＵコア（５０８）にステートメントを振り分ける非決定性マネージャー（５１２）は、ＰＲＯＬＯＧと他の逐次プログラミング言語で見られる後戻りの概念を一般化する。本ルールエンジンの実施形態では、こうした解は、ステートメント（５１４）の論理的な証拠と常に一致しており、これはルールエンジンのルールの論理的なセマンティクスの結果である。後向き連鎖が多くの代替的な解を探す場合は常に、これらの代替物の実行順序は重要ではない。なぜなら、「ＯＲ」ステートメントの１つのオペランドを満たす解が別のオペランドの任意の証拠から完全に独立しているからである。これにより、後向き連鎖の代替物の並列計算が可能となる。アプリケーションのための任意の並列なスピードアップ要因は、当然のことながら、そのアプリケーション中のルール論理の構造に依存する。
【０２２６】
図５Ｃは、後向き連鎖におけるＡＮＤ−並列を例証する。後向き連鎖の目標（証明すべきステートメント）が２つの下位目標（５２０）を含む連言からなる場合は常に、それぞれの下位目標の変数設定の観点から部分解が互いに一致している限り、これらの２つの下位目標の証明は同時に実行することができる。下位目標が互いから独立しているとき、真の並列実行が達成可能である。下位目標が独立していない場合、依存性は論理変数の共有によって明示される。これらの共有される論理変数を用いて（例えば、同期マネージャー（５２２）によって）下位目標の証明の同時実行を同期させつつ、可能な限り並列実行に影響を与えることができる。通常通り、アプリケーションのいかなるスピードアップ要因もルール論理の構造に依存する。
【０２２７】
非常に強力ではあるが、本ルールエンジンの実施形態の論理的なプログラミング言語とシンタックス、およびプロセスエンジンの論理的構成は、一般に利用されるエンジンのタイプにかかわらず、複雑であり、多くの人にとって容易に理解するのは困難である。有用で順応性があるアプリケーションプログラムを作成するためにルールエンジンとプロセスエンジンのパワーを効率よく利用するのに必要なコード行を書くべくルールエンジンとプロセスエンジンの使用法を学習することができる人もいるが、それには相当な時間が必要となり、非常に多様な結果を生成することが多い。ルールエンジンの言語やシンタックス、およびプロセスエンジンを利用する最も効果的な方法をほとんどのユーザーに教えようとするよりもむしろ、図６で例証される実施形態は、ルール書き込み装置（ｒｕｌｅ  ｗｒｉｔｅｒ）を利用して、ルールエンジンやプロセスエンジンと協働して動作するアプリケーションプログラムへユーザーの表示された要望を変換する。
【０２２８】
ルール書き込み装置により、特定の最終用途アプリケーションに適切なあらかじめ定義されたプロセス状態、動作、入力タイプ、および出力タイプを含むルール書き込み装置によって生成される標準的なルールテンプレートに影響を与えて、データの有用性と処理を向上させることができることもある。アプリケーションのタイプは、同僚と協力するためのビジネスワークフロー、モバイルのパーソナルアシスト用アプリケーション、および以下に詳細に記載されるようなそれ以外のアプリケーションを含むこともある。
【０２２９】
実施形態の全体的な論理アプリケーションシステムをさらに理解するために、図６について言及する。システム（６００）全体は、少なくとも３つの主要セクション、入力セクション（６０２）、アプリケーションセクション（６０４）、および処理セクション（６０６）を含んでもよく、これらはそれぞれ、以下により詳細に記載される多くの要素を含むこともある。入力セクション（６０２）は、構成セクション（６０８）、ルール書き込み装置（６１０）、およびテスター（６１２）を少なくとも含んでもよい。図７に関してさらに記載されている構成セクション（６０８）は、コンフィギュレータ（６１４）、フォームデポジトリ（ｆｏｒｍ  ｄｅｐｏｓｉｔｏｒｙ）（６１６）、およびデータ抽出器（６１８）を少なくとも含んでもよい。アプリケーションセクション（６０４）は、アプリケーション（６２２）、アプリケーションデータ抽出器（６２４）、ならびに、出力配信およびプレゼンテーションインターフェース（６２６）を少なくとも含んでもよい。処理セクション（６０６）は、プロセスエンジン（６３０）、ルールエンジン（６３２）、およびデータベース（６３４）を少なくとも含んでもよい。
【０２３０】
コンフィギュレータ（６１４）は、図７で例証されるように、様々な異なる方法でユーザーから入力データを受け取ってもよい。その後、コンフィギュレータ（６１４）は入力データを使用して、ユーザーの希望を達成するアプリケーションに対するコードコアを生成するようルール書き込み装置（６１０）に命じる。ルール書き込み装置（６１０）に命令する手法と方法は大きく異なることもある。ルール書き込み装置（６１０）に命令するためにデータと指示をフォーマットすることもある５つの異なるオプションが図７に示されているが、これらのオプションは例に過ぎず、実施形態は示された例に限定されてはならない。
【０２３１】
入力（７０２）、状態（７０４）、出力（７０６）、および動作（７０８）の形態で１つ以上のルールを書くための命令を含むオプション１は、ルールエンジンとプロセスエンジンを用いて書かれたアプリケーションを実行することを望んでいるということを非常によく理解しているユーザーを対象としている。オプション１では、ユーザーは、動作中にアプリケーションが入ることが予想される多くの異なるプロセス状態（７０４）、その状態（７０４）のそれぞれで受け取られることもある１つ以上の入力（７０２）、それぞれの状態（７０２）での１つ以上の予想される出力（７０６）、および、それぞれの状態（７０２）で実行される１つ以上の動作（７０８）を識別することができるようになる必要があることもある。オプション１では、ユーザーは、上記のように、前向き連鎖または後向き連鎖、あるいはその両方の組み合わせなどの動作（７０８）のそれぞれの論理的な態様を識別することができるようになる必要もあることもある。
【０２３２】
例えば、新入社員に関する情報の処理に関連するアプリケーションの場合、最初の状態は、従業員の名前などの入力として受け取られたデータの評価と、姓、名、ミドルネーム、または従業員にはミドルネームがないことを示すゼロ入力（ｎｕｌｌ  ｅｎｔｒｙ）といった名前に関する必要なデータのすべてを受け取ったかどうかを判断する動作を含むこともある。必要なすべてのデータが最初の状態によって受け取られていた場合、次に行なわれる動作は、名前を承認し、１つ以上の他の必要な入力も同様に受け取られる場合などの限り、人的資源システムにおいて従業員のための記録を作成するとった追加の動作等を行う他の１以上の状態にその名前を転送することを含んでもよい。同様に、名前が承認されない場合、取られる動作は、修正のために入力源に名前を戻すことを含むこともある。
【０２３３】
記載したように、１つの状態は、その状態に関連する複数の入力、複数の出力、および複数の動作を有することもある。オプション１内では、ユーザーは、ルール書き込み装置が指定された状態に関する適切なルールを書き上げやすくするような方法で実行される動作の性質を少なくともある程度は定義することができてもよい。例えば、入力が前向き連鎖プロセスで使用することができる事実であることをユーザーが認識できる場合、ユーザーはこうした方法で動作を識別することができる。同様に、入力が後向き連鎖プロセスで使用することができるクエリーであることをユーザーが認識できる場合、ユーザーはこうした方法で動作を識別することができる。動作のなかにはユーザーが認識しないこともある前向き連鎖と後向き連鎖の両方のプロセスに役立つものであるものもあるため、ルール書き込み装置（１１０）は、ユーザーの入力命令を評価し、かつそれらの入力命令に基づいて効率的なルールを適切に開発する能力を含む。
【０２３４】
オプション２は、必要な命令をすべて識別したくないか、あるいは、そうすることができないユーザーのために、および、望むことのほとんどを行う標準化された命令（７１０）を支持して自分たちが好むであろう事柄に関して妥協することを厭わないユーザーのために設計されている。標準命令はデータを追加したフォームに組み入れられることもあり、この場合、それぞれの入力はそのデータに基づいて講じられる標準動作に対応する。上に議論された新入社員の処理の例に戻ると、オプション１に関して、フォームは、ユーザーがその従業員を処理するために使用したい命令のすべてではないが大部分を含むフォームライブラリ（７１２）に既に存在していることもある。ユーザーはフォームから望むことに関して妥協することを全く厭わなければ、まさにそのままの標準的なフォームを受け取ることができる。他方では、必要ないという理由でユーザーが削除したい複数の命令があった場合、あるいは、フォームの特定の位置で入力されたデータの名前またはタイプを変更したい場合、ユーザーは基本的な編集要素（７１４）を使用して、標準的なフォームに上記のような変更等の適度な変更を加えることができる。
【０２３５】
オプション３は、利用されるフォームが、ユーザーによって図６で例証されるフォームデポジトリ（６１６）に（電子的に）ドロップされたユーザー生成型のフォームである（図６と図７の両方で例証されたデータ抽出器（６１８）によって処理される）。ユーザー作成フォームのデータを処理するために、データ抽出器（６１８）は、ラジオボタン、ライン、テキストボックスなどのグラフィックオブジェクトを含むユーザーフォーム（７２０）上でのそれぞれのオブジェクトまたはフィールドの位置と、数、テキスト、色などのようなグラフィックオブジェクトに関連付けられる他の情報を判断し、ルール書き込み装置（６１０）に関する命令を適切に開発するためにシステムが必要とするフォーマットへとマッピングすることもある。ユーザーは、フォーマットされたフォームで、データ、すなわち、フォーム上の異なるグラフィックオブジェクトとテキストが表すことと、こうしたデータに基づいて実行される動作を識別する（７２２）ことを要求されることになる。
【０２３６】
システム（６００）に関して命令を受け取るために生成される第１のフォームのいくつかは、システム（６００）の演算子によって時間をかけて開発されるフォームに制限されることもあるが、ユーザーは、オープンソースタイプの環境（７２４）下において無料で、あるいは、シェアウェア・タイプの環境下でわずかな料金で、自ら再使用する、あるいは、他の関係者と喜んでシェアする特定のフォーム（オプション４）を開発するであろう。設計されたフォームはモバイルデバイスのためのアプリケーションとおなじやり方で購入することができ、開発者は、理想としては適正価格で販売され大量に売れて報われるユニークなカスタムフォーム（７２６）（オプション５）を開発することを奨励される。
【０２３７】
ルール書き込み装置へデータを入力するための他の実施形態が明らかに可能であるため、本明細書に記載されたわずかの実施形態は、ルールを書くスキルのない人々のために書かれたルールを有するすべての可能な実施形態であると意図するものではなく、これを限定するものでもない。例えば、ルールは平易な英語で書くことができ、ルールコードは平易な英語のテキストからルールコードに自動的に翻訳することもできる。一実施形態では、ルールの実行に関して領域固有言語（ＤＳＬ）の翻訳機が利用される。ＤＳＬはコンピュータを制御するために使用される任意のタイプのコード体系を含んでおり、このコード体系は汎用プログラミング言語ではない。（英語のテキストのような別の言語を使用して）ルールオーサリングシステムからのルールエンジンに関するルールコードを生成する目的で、ＤＳＬは次の一般的なフォーマットを有するカスタムＸＭＬファイルによって定義されることもある：
【０２３８】
【数６７】
2016505953.tif 000078
【０２３９】
上記フォーマットは、一連の〈ｓｙｍｂｏｌ〉要素とその後の一連の〈ｍａｃｒｏ〉要素からなる。それぞれのｓｙｍｂｏｌ要素は、ｓｙｍｂｏｌのクラスを指定する属性と共に単語または句からなる。例えば、以下である。
【０２４０】
【数６８】
2016505953.tif 000079
【０２４１】
それぞれのｍａｃｒｏ要素は〈ｔｅｍｐｌａｔｅ〉要素と〈ｒｕｌｅｓ〉要素からなる。これらのｔｅｍｐｌａｔｅとｒｕｌｅの関係は、以下のように１つの例を以って最もうまく説明される：
【０２４２】
【数６９】
2016505953.tif 000080
【０２４３】
上記のマクロの翻訳機が平易な英語で表現された少数のルールをどのように作成するかを例証するためには、以下の文を考慮する：
【０２４４】
【数７０】
2016505953.tif 000081
翻訳結果は次の２つのルールになるだろう：
【０２４５】
【数７１】
2016505953.tif 000082
【０２４６】
英語のテキスト（ｍａｃｒｏのテンプレート）の動詞「ｍｕｓｔ  ｂｅ」が論理上は義務に関する演算子であるため、標準的な１階論理では直接表現することができない。その代わりに、ｍａｃｒｏはこの動詞を「ｆａｉｌ（失敗）」結果を暗に意味するルール前件中の否定条件へと翻訳する。こうして推論された「ｆａｉｌ」の存在は、対応する遵守規則が破られたことを意味する。ルールエンジンコードは２つの論理変数（ＩｎｄｅｘとＸ）を含んでおり、マクロのテンプレート中に直接の対象物を持っていないことにも注意されたい。この場合、Ｉｎｄｅｘは実際には、それぞれの媒体にＩｎｄｅｘを割り当てる隠されたデータモデルの一部である。これはルールエンジンのルールに同時に多くの自動車を操縦させる。ｉｎｄｅｘは「ｆａｉｌ」結果で繰り返されるため、どの自動車が規則を違反しているか正確に識別することができる。Ｘは、車両状態（例えば、「ｍｏｖｉｎｇ」または「ｓｔｉｌｌ」）に関する単なるプレースホールダーであり、この場合、必要に応じて否定が動作するようにそれ自体の変数を必要とする。もしｉｎｄｅｘ変数がなければ、
【０２４７】
【数７２】
2016505953.tif 000083
を
【０２４８】
【数７３】
2016505953.tif 000084
に単純化することは可能だろう。
しかしながら、Ｉｎｄｅｘが否定の外側で束縛されているか、または否定の内部で存在量化されていない限り、ルールが「ｎｏｔ  ｃａｒ（Ｉｎｄｅｘ，Ｍｏｖｉｎｇ）」と書かれると、上記は作動しない。しかしながら、後者は、その意味を、信号が青ならば少なくとも一台の車が移動しているに違いないというものに変更することになる。
【０２４９】
特別なシンタックスにより、同じマクロテンプレート中でｓｙｍｂｏｌクラスの１以上の例が可能となる。例えば、以下のとおりである。
【０２５０】
【数７４】
2016505953.tif 000085
このマクロを以下に適用すると：
【０２５１】
【数７５】
2016505953.tif 000086
このルールが生まれる：
【０２５２】
【数７６】
2016505953.tif 000087
【０２５３】
このルールは少々弱い。というのも、それは、誰にでも適用可能にすることができる変数を含む代わりに、Ｏｐｒａｈについてはハードウェアに組み込まれているが、翻訳の根本概念を伝えるものだからである。論理変数は以下のように生成される：
【０２５４】
【数７７】
2016505953.tif 000088
慣例により、大文字で始まるテンプレートパラメータは、ルール生成の論理変数として処理されるだろう。この例において、「Ｘ１」−「Ｘ６」は変数として処置されるだろう。
【０２５５】
上記のマクロを以下のように英語のテキストに適用すると：
【０２５６】
【数７８】
2016505953.tif 000089
以下のルールが生じるであろう：
【０２５７】
【数７９】
2016505953.tif 000090
この場合、マクロ中の「Ｘ１」と「Ｘ３」の両方は「最初の人」にマッピングされるが、生成されたルールでは、「Ｘ１」と「Ｘ３」は両方とも生成された変数名「Ａ」と取り替えられる。残りの変数は同じように取り扱われる。ルールエンジン中のシンタックスは制限されるため、論理変数については新しい名前が生成される。したがって、「最初の人」を変数名として直接使用することはできない。論理変数の範囲が単一のルール節に制限されているので、各ルール内を除いて、生成された変数の名前を唯一無二のものする必要はない。
【０２５８】
以下のように同じマクロを異なるルールに使用することができる：
【０２５９】
【数８０】
2016505953.tif 000091
マクロは以下を生成する：
【０２６０】
【数８１】
2016505953.tif 000092
リストまたは単純枚挙法は様々なタイプの遵守規則において珍しくないわけではない。例えば、こうしたリストは、ルールエンジンの事実またはルールの表にマッピングすることができる：
【０２６１】
【数８２】
2016505953.tif 000093
【０２６２】
これらの２つの入力にこのマクロを適用すると：
【０２６３】
【数８３】
2016505953.tif 000094
以下のルールエンジンコードが生成される：
【０２６４】
【数８４】
2016505953.tif 000095
テンプレート中の単純枚挙法は最後の要素の前で「ａｎｄ」または「ｏｒ」のいずれかを随意に使用することができることに留意する。これはスタイルの問題に過ぎず、リストはルール生成装置によってまさに同じ方法で取り扱われる。
【０２６５】
インプリメンテーションの観点から、記号とマクロの定義を含んでいるＸＭＬファイルは、少なくとも現在では、人間のプログラマによってハンドコーディングする必要があるものであってもよい。こうしたＸＭＬファイルは、領域に特有の言語を定義する「ビルディングブロック（ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）」として組み合わされてもよい。これは、異なるビルディングブロックが含まれ得るＧＵＩ内で行われることもある。同じＧＵＩは、ルールの作成者に、様々なメニューやテキスト入力フィールドから来るテンプレートと記号を選択することによって領域にルールを構成させることもある。その後、結果として生じたＤＳＬルールがルール発生装置によって入力として処理され、出力として実行可能なルールエンジンのルールが生成される。
【０２６６】
処理は、一度に１つの入力ＤＳＬルールを取り、マッチするまでそれぞれのマクロのテンプレートにそれをマッチさせることによって続く。その後、マッチしたテンプレートパラメータは、上に記載された原則に従ってマクロのルールセクション中で置き換えられる。少なくとも１つの成功したマッチが見つかると、最後のマッチに対応するルールが見つけられ、出力に加えられる。随意に、２以上の成功したマッチが見つかった場合、警告も示される。成功したマッチがまったく見つからない場合、そのＤＳＬルールについてエラーメッセージが示され、翻訳が停止する。マッチングする処理は入力の一パターンとしてテンプレートを検索する従来の後戻りアルゴリズムを使用しつつ、テンプレートパラメータの結果として生じる設定の跡を辿る。
【０２６７】
図８は図６のデータベース（６３４）とプロセスエンジン（６３０）をさらに例証する。コントローラー（８０２）は、データベース（６３４）とルールエンジン（６３２）と同様に、アプリケーション（６２２）と処理セクション（６０６）の間の相互作用を制御する。コントローラーは、メッセージ消費者（８０４）とメッセージ作成装置（ｍｅｓｓａｇｅ  ｐｒｏｄｕｃｅｒ）（８０６）によって処理セクション（６０６）から／に送られるメッセージの処理と、タイマー（８０８）によって処理セクション（６０６）内でのオペレーションのタイミングを操作する。データベース（６３４）は、ルールエンジンによって実行されるルール用のルール記憶装置（８１０）、時間指定されたメッセージ（８１２）、プロセス状態記憶装置（８１４）、およびプロセスレジストリ（８１６）を含む、多くの別々のデータセクションを含んでいる。
【０２６８】
図９はルールエンジン（６３２）の実行された実施形態の詳細を示しており、機能的なセクションは指定の機能のまわりの実線によって示されており、記憶エリア（データベース（６３４）に記憶された）は破線によって示されている。ルールと事実はルールエンジン（６３２）へ入力され、ルールに関してルールパーサー（９０２）に、事実に関して事実ローダー（ｆａｃｔ  ｌｏａｄｅｒ）（９０４）に送られる。その後、構文解析されたルールは、前向き連鎖エグゼキューター（ｅｘｅｃｕｔｏｒ）（７０８）、または後向き連鎖エグゼキューター（７１０）、または組み合わせる際にはその両方によって使用される事実項記憶装置（７０６）に記憶される。構文解析されたルールは、前向き連鎖エグゼキューター（７０８）または後向き連鎖エグゼキューター（７１０）に入力するために構文解析されたルール記憶装置（７１２）に同様に記憶される。記号は記号表（７１４）によって供給される。ルールと事実が後向き連鎖エグゼキューター（７１０）によって実行されると、証拠または中断された証拠が証明木（７１６）と証明木スプリッター（ｐｒｏｏｆ  ｔｒｅｅ  ｓｐｌｉｔｔｅｒ）（７２０）に記憶され、切り離されたルールが証明されると、項は項単一化装置（ｔｅｒｍ  ｕｎｉｆｉｅｒ）（７２２）によって再度結合する。ルールエンジンの論理的分析の結果は後向き連鎖エグゼキューター（７１０）から出力される。
【０２６９】
アプリケーションのいくつかの例が上に参照されているが、アプリケーション環境でルールエンジンを実行することができる方法は理論上制限されない。図１０で例証されるように、入力（１００４）（キーボード、グラフィカルユーザーインターフェイスなどのような任意の既知のデータ入力フォームの１つ以上であり得る）、記憶装置（１００６）（非一時的）、および出力（１００８）（同様に任意のフォーム）を備えた任意のアプリケーション（１００２）は、一実施形態において、図６、および、図６を参照して記載されたように、処理セクション（６０６）と通信するように構成されてもよい。以前に記載されたように、アプリケーション（１００２）、入力（１００４）、記憶装置（１００６）、出力（１００８）、および処理セクション（６０６）の様々な要素は、物理的に同一場所に配置されてもよく、それぞれの任意のあらゆる要素が物理的に異なる場所に配置可能であり、あるいは様々な組み合わせを作ることもできる。例えば、アプリケーション（１００２）はモバイルデバイス上で操作することができ、これは、モバイルデバイスを介して、および、セル方式、ＷＩＦＩや他のネットワーク、赤外線スキャンなどを介して、ユーザーからの入力を受け取り、モバイルデバイス上およびクラウド上に情報を記憶し、論理要素が遠隔設置されたサーバー上で操作される場合にはクラウドを介して処理セクション（６０６）と通信し、および、モバイルデバイスに、またはネットワークを介して他のデバイスにデータを出力する。
【０２７０】
図１１は、アプリケーション（１００２）と処理セクション（６０６）の間の基礎的な通信の実施形態を示す。ステップ（１１０２）では、アプリケーション（１００２）は、ユーザーおよび／または他のソースから入力を受け取り、これはアプリケーション（１００２）によって実行される事実またはルールのフォームであってもよい。ステップ（１１０４）では、アプリケーション（１００２）は、ルール（もしあれば）と、処理セクション（６０６）のルールエンジン（６３２）によって実行されるルールに適用可能な事実の集合とともに、処理セクション（６０６）に対して１つのメッセージまたは２つ以上のメッセージを送信する。ステップ（１００６）では、処理セクション（６０６）は、事実の集合を考慮してルールを適用可能なものと評価し、ルールに依存したレスポンスをアプリケーションに戻してさらに処理する。先に記載されたように、処理セクションによって評価されているルールは、前向き連鎖、後向き連鎖、または、その組み合わせを含むこともある。ステップ（１１０８）では、アプリケーション（１００２）はレスポンスを処理し、レスポンスを考慮して処理セクション（６０６）にメッセージを送信するか、あるいは、ユーザーおよび／または他のソースによって使用される出力にデータを送信する。
【０２７１】
処理セクション（６０６）を用いて使用されるアプリケーションの一例は、勤務時間制御を含んでいる。多くの様々な仕事は、特定のタイプの人々が一度に、何日間にわたって、または毎週、または毎月などに勤務中であり得る時間を規制している。勤務時間制御アプリケーションは、医師、看護師、および他の患者ケア担当者の時間を規制するために病院によって、特定の従業員が軍、航空交通管制など、または、所定の時間にわたって様々な乗務員が費やす飛行時間の量を制御する必要がある航空産業のような他の産業（あるいは他の職業）等において、一度に働く時間量を規制するために政府機関によって、採用されることもある。こうした規制に晒される個人が数人の場合、乗務員のスケジュールを決定することは比較的容易である場合があるが、一日２４時間、異なる飛行機で世界中を飛び回っている多くの異なる時間帯にいる数千もの乗組員がいる場合には、乗務員の勤務時間の予定を立てて適切に制御することは非常に複雑化する可能性があり、この場合にこそ本実施形態に係るルールエンジンの力を完全に実現することができる。
【０２７２】
航空産業向けの勤務時間制御アプリケーションは以下に記載されており、データ入力、スクリーン構成、認可、および他の目的のために本ルールエンジンの実施形態をどのように利用することができるのかを例証している。例えば、グラフィカルユーザーインターフェイス（ＧＵＩ）と協働して使用され、データモデルに依存する単純なデータ入力バリデーションルール（ｖａｌｉｄａｔｉｏｎ  ｒｕｌｅ）は、以下のように書かれることもある：
【０２７３】
【数８５】
2016505953.tif 000096
すべてのデータが入力された後にサインオフフェーズ（ｓｉｇｎ−ｏｆｆ  ｐｈａｓｅ）で始動する別のデータ入力バリデーションルールは、以下のとおりである：
【０２７４】
【数８６】
2016505953.tif 000097
バリデーションエラーは１つの入力フィールドには関連付けられない。なぜなら、乗務員を順番に入力することが可能であり、例えば、指導者を入力する前に副操縦士を入力することを許されるからである。しかし、副操縦士と指導者なしでサインオフするとバリデーションエラーが生成される。
【０２７５】
スクリーン構成例が次に記載されている。この例において、同じＧＵＩデータ入力画面中のコピーボタンは、これらのルールを使用して、往復便のために出発と到着の空港に関するデフォルト値を書き入れる：
【０２７６】
【数８７】
2016505953.tif 000098
【０２７７】
認可ルール例は以下のように書かれてもよい：
【０２７８】
【数８８】
2016505953.tif 000099
これらのルールは、入力としてユーザー役割とページビュー識別子を含むＧＵＩコード（ＪＡＶＡ（登録商標）ウェブ・アプリケーション）によって呼び出されるルールエンジンの一時性のプロセスの一部であり、ルールエンジン出力メッセージはそのページ上のそのユーザーに関する一連の認可されたオペレーションを戻す。この技術を避けてその代わりに単純な性能フラッグ（ｃａｐａｂｉｌｉｔｙ  ｆｌａｇ）を使用することがより望ましいいくつかの状況下ではパフォーマンスに関する懸念があることもあるが、認可に対するこの種の柔軟な制御は必要とされるとき、本ルールエンジンは容易にそれを提供することができる。ルールエンジンの宣言的なセマンティクスにより、ルールエンジンは、信頼されていないユーザーが個人データにアクセスするためにルールをアップロードすることさえ許可する。なぜなら、こうしたルールの実行がシステムの残りのセキュリティを危険にさらすことが決してあり得ないからである。
【０２７９】
本ルールエンジンの実施形態を使用して実行され得るより高度なＧＵＩアプリケーションは、個々のユーザーのクリックに反応し、かつ、ルール、現在のプロセス状態、および他のプロセスからの随意のメッセージに基づいてＧＵＩスクリーンを再構成するプロセスを含んでいる。
【０２８０】
統合／構成ツールのさらなる例が以下に例証される。実例となる例はローン契約申し込み（ａ  ｌｏａｎ  ａｇｒｅｅｍｅｎｔ  ａｐｐｌｉｃａｔｉｏｎ）を記載しており、ここでは、入力メッセージ「ｇｅｎｅｒａｔｅ＿ｄｒａｆｔ」により、ルールエンジンプロセスが、要求されたドキュメントを作成するために草案作成サービス（ｄｒａｆｔ  ｇｅｎｅｒａｔｏｒ  ｓｅｒｖｉｃｅ）（ローン契約申し込みに対するプラグインアプリケーション）を構成する。この構成は、非ルールエンジンプロセス「アプリケーション」にメッセージを送ることによって行われ、これはこの場合プラグインの一部であってもよい。ルールコードは以下のとおりである：
【０２８１】
【数８９】
2016505953.tif 000100
【０２８２】
ルールエンジンの簡潔さに由来する力を実証する別の例は、それが構成または統合に関するよりもむしろシステムのプログラミング例に似ている。この例において、ルールエンジンのルールは、それぞれの乗務員に関して最新の蓄積された勤務時間とフライト時間を周期的に更新するために上記の勤務時間アプリケーションにおいて使用されるタイムスケジューラを実行する：
【０２８３】
【数９０】
2016505953.tif 000101
ルールコードの上記行は、時間指定したバッチジョブに使用されるＵＮＩＸ（登録商標）「ｃｒｏｎ」サービスによって用いられるＦｒａｎｔａ−Ｍａｌｙ離散事象アルゴリズムのあるバージョンを実行する。「ｃｒｏｎ」によって使用されるジョブテーブルは、ここには示されない追加の２５のコード行によって実行される。対照的に、ＵＮＩＸ（登録商標）  ｃｒｏｎはＣコードの約５，０００のコード行によって実行される。従って、ルールエンジンは、１００倍で同じタスクを行うのに必要なコードの量を減らす。
【０２８４】
ルールエンジンを利用するドキュメント分析アプリケーションの実施形態がここから記載される。このアプリケーションはルールエンジンのためのルールコードで実行され、ＤＲＯＰＢＯＸタイプのアカウントをセットアップする能力をユーザーに与え、このとき、ドキュメントをクラウド環境に預けて、その後、ルールコードに基づいてどのようにそれぞれのドキュメントが処理されるべきかを決定するためにドキュメントを分析することができる。ドキュメントは、文書処理ドキュメント、写真、電子メール、テキストメッセージ、経費報告書などの関連する情報を有するが、こうした情報をどのように処理すべきかに関する命令は備えていない、任意のタイプであり得る。
【０２８５】
論理的なルールのワークフローは、あるドキュメントがワークフローに関連付けられる位置に置かれると、そのドキュメントに含まれる情報を処理するために確立されることになる。学習機能が加えられることもあり、その結果、ユーザーの動作が徐々に研究されて、ワークフローが修正されるようになるか、あるいは、ユーザーの動作に適合するようにワークフローを修正するためのオプションがユーザーに与えられる。この種のドキュメント分析アプリケーションは、実行されたモバイルアプリケーション、ビジネスアプリケーションであり得るか、あるいは単に友達との夕食や旅行プランなどの日常の活動を自動化するためのものであり得る。アプリケーションは、電子メールの非能率的な使用を「ｇｅｔ  ｔｈｉｎｇｓ  ｄｏｎｅ（物事を終わらせる）」に取り換える職場および／または自宅でＩｎｂｏｘ／Ｏｕｔｂｏｘの概念を有効に採用する。アプリケーションを実行するように要求されるルールコードを記載するよりもむしろ、アプリケーションのワークフローは、当業者が本明細書に記載されるワークフローの論理的な構成に基づいて上に提供されるシンタックスを使用して、ルールコードを実行することができるという理解の下で記載されている。
【０２８６】
図１２を参照すると、ユーザーがユーザーのデスクトップ上のアプリケーションフォルダーにドキュメントのコピーをドロップするとき（ステップ１２０２）、ドキュメントは、アプリケーションサーバー上のユーザーに割り当てられた対応するフォルダーに自動的にコピーされる（ステップ１２０４）。ドキュメントがサーバーに到着すると、ある動作が自動的に誘発され、ドキュメントとその中身を見てドキュメントを分類するルールコード中のルールのセットに呼びかけるＪＡＶＡ（登録商標）コードが実行される。カテゴリー分類ルールからの出力に基づいて、ＪＡＶＡ（登録商標）コードはその後、ドキュメントを別のフォルダーに移動させ、ユーザーのデスクトップ上のアプリケーションフォルダーからコピーを削除する（ステップ１２０８）。その後、ＪＡＶＡ（登録商標）コードは、プロセスエンジンの「ハンドラー（ｈａｎｄｌｅｒ）」プロセスにメッセージを送信して、ハンドラープロセスを識別する、あるいは、識別されたドキュメントの分類について実行されるフロープロセスを制御する（ステップ１２１０）。理想的には、ドキュメントを処理するのに必要であると識別されたそれぞれの異なるタイプのプロセスには１つのハンドラープロセスがある。ドキュメントがプロセスセクション（６０６）によって少なくとも最初は処理されて終わると、ルールに依存したレスポンスは、複数のワークフローを開始するルールエンジン／処理セクションから出力される。ビジネスアプリケーションでは、例えば、同じ名前のドキュメントがアクティブなワークフロープロセスにすでに関連付けられていなければ、受け取ったドキュメントの新しいワークフロープロセスを始める経費報告書用のハンドラーが存在することもある。いったんハンドラーが呼び出されると、そのドキュメント中の情報の処理における次のステップは、その特定のハンドラー、識別されたワークフロープロセス、および潜在的にはこうしたプロセスの結果に依存する。
【０２８７】
例えば、特定の日時の夕食を提案している友人からの電子メールは、その日時の夕食についてユーザーのカレンダー上にカレンダーイベントを作成するために様々なルールセットとルールセットによって生成されたワークフローに従って処理するための特定のデスクトップ上のフォルダーにユーザーによってドロップされ、一方で、別のワークフローがお気に入りのレストランのウェブサイトを評価して、その日時で二人分の予約の予定を立てようとする。予約が終わると、異なるルールセットによって確認が処理され、ワークフローが生じ得るためコピーが友人に送られ、コピーは適切な識別子をもってユーザーのために作成されたフォルダーに記憶され、したがって、ユーザーは必要に応じて後で確認を探すことができる。ルールのセット次第で、当日の夜の自動車またはセダンのサービスの予約などといった他のワークフローが生じ得ることもあり、花の注文やクリーニング店からのスーツの受取等、その晩にそれ以外の特別なリクエストが必要かどうかについてユーザーにメッセージが送信され得る。確立され得るルールとワークフローの数と種類は無限であるが、ほとんどの人々には多少の実際的な制限がある可能性が高く、ユーザーが同じプロセスが続くことを望まない場合、ユーザーはまずデスクトップのフォルダーに電子メールをドロップせず、あるいは、ルールの異なるセットを自動的に適用する異なるフォルダーにそれをドロップすることになる。
【０２８８】
個人的なまたは仕事上の生産性目的のために図１２に例証された同じ種類のプロセスを、上記のフライトスケジューリングアプリケーション、勤務時間制御アプリケーション（タイムスケジューリングの有無に関わらず）、およびローン処理の例などのそれ以外の多くのコンテキストで使用することができる。後者に関して、住宅購入のためといったローンの処理では一般に、ローン申請者から受け取り、潜在的な貸手によって作成され、および他のソースから得られるドキュメントの制限されたセットがある。ローンの申し込み、申請者の財政状況、住宅に関する情報、郡の記録、信用格付け報告書などを処理のために１つ以上のフォルダーにすべてドロップすることができ、その後、上記に似たプロセスにかける。例えば、ローンの申し込みは、要求された情報がすべて提供されたことを確かめるために分析され、そうでない場合には、任意の不足した情報を得るためにワークフローが生成されることになる。いったんすべての情報が得られると、申込者の情報が、ローンの額、種類、条件、資産の価値、購入価格、頭金などについて指定された範囲内であるかどうかを決定するために分析されることになる。同時に、他のドキュメントは、入力したすべてが確立されている基準を満たすかどうかを確認するために同様のやり方で分析され、こうした基準が満たされているか否かに基づいて、適切なワークフローが生成することになる。最後には、申請者がローンの資格があるか否か、申請者に資格を与えることを許可する対処可能な問題があるか否か、あるいは申込者が拒絶されたまたは資格を満たすことができなかったかどうかを示すレスポンスが生成されることになる。
【０２８９】
次に来るハンドラープロセスの一実施形態の一例が同期制御フローであり、ここで、ＪＡＶＡ（登録商標）プログラムは、プロセスチャネル指示子（ｐｒｏｃｅｓｓ  ｃｈａｎｎｅｌ  ｄｅｓｉｇｎａｔｏｒ）Ｐと１セットの入力データ項（事実）を承認するルールエンジンライブラリについてラッパー（ｗｒａｐｐｅｒ）を呼び出す。Ｐは、いくつかのルールコード（ルールと事実）への言及と、現在のプロセス状態を表す１セットの項とを含むデータベース入力に変えられる。後者の項を最初の入力データの項と合体させ、その後、以下に詳細に示される最上位の制御フローが以下を加えて行われる：ｏｕｔｐｕｔ（Ｃ，Ｘ）が真であるすべてのＣ，Ｘについて、メッセージｉｎｐｕｔ（Ｐ，Ｘ）はＣで指定されたプロセスエンジンのプロセスに送られる。ｏｃｃｌｕｄｅ（Ｙ）が真であるすべてのＹに関して、項Ｙはプロセス状態から削除される。その後、ｐｅｒｓｉｓｔ（Ｚ）が真であるすべてのＺについて、項Ｚはプロセス状態に加えられる。メッセージの送信とデータベースの更新（もしあれば）は、単一のＪＡＶＡ（登録商標）  ＥＥトランザクションとして完了する。
【０２９０】
別の例では、呼び出しを取扱い、メッセージの受取と同じトランザクションで結果として生じるトランザクションを行う非同期ＪＡＶＡ（登録商標）  ＥＥ  ｂｅａｎに対して、チャンネル指示子と入力データ項（事実）がメッセージ中で送られるという点を除けば、非同期制御フローは、同期制御フローに関して上に記載された方法に類似する方法で実行されてもよい。ｏｕｔｐｕｔ（ｄｅｆａｕｌｔ，Ｘ）からのどんな結果もこのケースでは廃棄される。
【０２９１】
最上位の制御フロープロセスは、ルールエンジンライブラリへの呼び出しを行い、引数としてルールコード（ルールと事実）を含むテキスト文字列と１セットの入力データ項（事実）を提供する、ＪＡＶＡ（登録商標）プログラムを含んでいる。その出力は、ｏｕｔｐｕｔ（ｄｅｆａｕｌｔ，Ｘ）が真であるようにＸを含む１セットの項である。例外が生じない場合、このセットは、所定のルールと事実と入力項の事実により含意される最大の上記セットを含むことが保証される。ルールコードのテキスト文字列は、効率を上げるためにキャッシュされる他のルールコードモジュールを含める命令を含むことができる。ルールコードは異なるように処理される３種類のステートメントからなる：
１．  前向き連鎖ルール。
２．  後向き連鎖ルール。
３．  事実。
さらに以下に詳細に記載されるように、最上位の呼び出しは、最初に前向き連鎖ルールを適用し、その後、結果として生じるプログラム状態に後向き連鎖ルールを適用することにより行われる。
【０２９２】
前向き連鎖ルールは、すべての与えられた事実（コードに含まれるものと入力として提供されるものの両方）のリストを作ることにより適用される。その後、それぞれの事実はリストから除去され、その事実にマッチする条件を含むあらゆる前向き連鎖ルールに適用される。その後にこのルールは実行される。ルールが事実のセットにまだ含まれていなかった推論をもたらす場合、その推論は、事実のセットとリストの最後に加えられる。図１に関して上に記載されたように、前向き連鎖ルールは後向き連鎖ルールの実行と組み合わせることもできる。
【０２９３】
後向き連鎖制御フローは、入力として与えられる、論理変数を含む可能性がある目標項を含んでいる。この目標項とマッチする後向き連鎖ルールがある場合、後向き連鎖の決定論的な制御フローが適用される。後向き連鎖の決定論的な制御フローアルゴリズムが、証明木にいかなる選択肢を残すことなく終了する場合、目標項の１つの解が戻ってくる。さもなければ、後向き連鎖の非決定論的な制御フローが行なわれる。
【０２９４】
後向き連鎖の決定論的な制御フローは、最初のステップとして、ルール中にあるそれぞれの論理変数のスロットで環境記録を作成する。ルールの頭部（ｒｕｌｅ  ｈｅａｄ）中のすべての変数を目標内の対応する項と単一化する。単一化が新しく作成された環境記録の外部にある任意の変数の束縛をもたらす場合、この目標の実行は中断され、その代わりに目標スタック（ｇｏａｌ  ｓｔａｃｋ）上で次の目標が試みられる。単一化が中断されることなく成功すると、ルールガード（もしあれば）内のすべての条件は目標スタックに押しつけられ、当初のステップがそれに適用される。
【０２９５】
後向き連鎖ルールの代わりに事実がマッチすると、１つの可能な事実だけがマッチした場合に目標は解かれる。さもなければ、目標は証明木の未解決の非決定論的な選択としてマークされ、目標は当初のステップとして中断される。
【０２９６】
組み込み述語がマッチする場合、対応するＪＡＶＡ（登録商標）コードが呼び出される。
【０２９７】
単一化が失敗すると、最新の環境記録がドロップされ、ｉｆ−ｔｈｅｎ−ｅｌｓｅルールから次の候補（もしあれば）は見つけられ、最初のステップが繰り返される。
【０２９８】
ルールガードが解かれた（空のガードは常に解かれる）とき、ルール本体は以下によってコミットされる：
１．候補から「ｅｌｓｅ」のルール部分を切り離す；
２．最新の環境記録を親環境と合わせる；および、
３．ルール本体の目標を目標スタックに押しつけること。
【０２９９】
中断された目標に属する論理変数が（複数の場所にあるため）再度単一化されるときはいつでも、中断された目標は証明木の「ｗａｋｅ  ｌｉｓｔ」に置かれるため、最初のステップでそれを再試行することができる。
【０３００】
後向き連鎖の非決定論的な制御フローは、証明木（深さ優先）内の第１の未解決の選択を見つけ出し、証明木全体を、その選択の第１の代替物を含むＴと、残りの代替物を表す選択の機会の最初の代案を含んでいるＴ’と、残りの選択肢を表わす継続選択オブジェクトを含むＴに分けることを含んでいる。その後、そのプロセスは、Ｔ、その後Ｔ’の決定論的な制御フローの最初のステップを継続する。
【０３０１】
上記の記載に関して、「マッチング」との用語は、エルブラン項（変数を含む可能性のある）のロビンソン単一化の特定の意味を備えている。そのロビンソン単一化の「ｏｃｃｕｒ  ｃｈｅｃｋ」は性能上の理由で行われない。その代わりに、ネストされたエルブラン項の深さには制限が課されることから、非常に深くネストされた項を統一する試みが例外を生む。ｏｃｃｕｒ  ｃｈｅｃｋによる単一化の失敗を含む任意の状況はその代わりに例外を設ける。
【０３０２】
本明細書に記載されているような処理セクション（つまりプロセスエンジン、データベース、およびルールエンジン）と協働して作動する別のタイプのアプリケーションは、製品のコア無線周波数管理、開発、試験、性能解析、および認可に関連した様々なステージを含むこともある。例えば、特定のタイプの電子製品の開発中に、設計やおそらく製品に関連する特定の特徴すら問わず、辿らねばならない特定の既知のステップがある。既知のルールは、それに関連して確立されたルールのセットと、ルールエンジンのルールに依存する出力に基づいて続くワークフローとを有することもある。こうしたルールのセットやワークフローは、会社の内部の製品開発システムへプログラムされることもあれば、あるいはこうしたシステムは、処理セクションによる処理するためにドキュメントまたはデータを受け取る別のシステムに呼び出しまたは要求を行うようにプログラムされ得る。例えば、製品の設計または概念化の間に、エンジニアは、開発される製品のいくつかの態様に関連したシミュレーションデータをアップロードすることもあり、処理セクションがこのデータを受け取ると、ワークフローが生成されることもあり、これにより、シミュレーションデータに基づいて報告書が作成され、承認を求めるために報告書のコピーがマネージャーに送信される。シミュレーションデータを処理する際に、シミュレーションデータが仕様データまたは測定されたデータとは十分に相関していないと決定された場合、マネージャーに警告し、デザインチームの都合のよいスケジュールを尋ね、時間Ｗに会議室Ｚでミーティングを手配する異なるワークフローが生成されることもある。
【０３０３】
いったんデザイン／概念のフェーズが完了すると、製品は製品開発に移り、異なるルールのセットとワークフローが適用されることもある。例えば、処理セクションに関連するアプリケーションにプログラムされたルールのセットは、潜在的な問題の早期発見に使用されることもある。製品が新しいタイプの携帯電話である場合、ある種のテストのために第三者の実験室に開発中の電話を送る必要があることもある。こうしたテストには数週間かかり、テストが終わるまでに莫大な額のコストがかかることもある。テストの間に生成された測定データはアプリケーションに送信されることもあり、その結果、リアルタイムまたはほぼリアルタイムでルールに従ってデータを分析することができるようになり、結果として特定のワークフローが生成されることもある。約６００のテストからテスト番号１０が奇妙な規格外の測定データを生成した場合、このことは失敗を示すか、または、ワークフローに従って他のテストのその後の失敗に結びつく可能性の高い事象すら示しており、テストは中断されることもあれば、あるいは、テストを要求する顧客にこの問題を警告し、テストを中止するか別の処置を講じる許可を与えるメッセージおよび／または報告書が送られることもある。
【０３０４】
アメリカや多くの諸外国で販売されることになっている電子製品が完成しても、発売される前に、いくつかの標準的な要件や、無線周波数（ＲＦ）送信に関連するＦＣＣ規則などの統制規則に合格しなければならない。こうした統制規則はアプリケーションにプログラムされることもあり、生の測定データを受け取ると、構文解析され、パッケージ化され、処理セクションの前で実行されるウェブサービスに送られ、これが統制規則から開発されたそのルールに対してパッケージ化されたデータを照合し、その後に続く適切なワークフローに反応する。実施形態の一例では、ルールに依存するレスポンスは、「合格する（ｐａｓｓ）」、「失敗する（ｆａｉｌ）」、または「欠けている（ｍｉｓｓｉｎｇ）」であってもよく、「合格する」はすべてのパッケージ化された解析済データがＦＣＣ規則に合格したことを意味する。レスポンスの「失敗する」または「欠けている」はより複雑であり、「失敗する」レスポンスは失敗した１以上の部分を示すものであり、「欠けている」レスポンスとはデータが欠けていることを示すものである。これらのレスポンスの各々は「合格する」レスポンスがＦＣＣに提出するのに適した報告書を生成すること等の関連するワークフローを有することもあれば、「失敗した（ｆａｉｌｅｄ）」または「欠けている」レスポンスは、失敗した部分または欠けている部分、失敗した部分の程度、失敗した部分の図のテキストまたは一部分に色を付けるか、あるいは特定の色で失敗した部分または欠けている部分のまわりに箱を描くことなどによって、失敗した部分がどこにあるのか、または欠けている部分がどこにあるのかを示すコンピュータで作成した情報の一覧を含む別の報告書を作成することもある。
【０３０５】
一実施形態において、ルールエンジンで使用されるルールコードのセットを構築するためのシステムは、ユーザーにルールコードのセットを書かせたり、入力されたデータをフォーマットしてフォーマットされたデータを作成させたりすることを要求せずに、ユーザーから入力されたデータを受け取るように構成されたコンフィギュレータであって、入力されたデータが、アプリケーションの１つ以上のプロセス状態、１つ以上のプロセス状態の各々で受け取られる１つ以上の入力、１つ以上のプロセス状態の各々の１つ以上の予想される出力、および１つ以上のプロセス状態の各々で行なわれる１つ以上の動作を含む、コンフィギュレータ、および、フォーマットされたデータを受け取り、かつアプリケーションと協働して動作するルールエンジンによって実行可能なルールコードのセットを生成するように構成されたルール書き込み装置、を含む。
【０３０６】
一実施形態では、システムは、ルール書き込み装置からルールコードのセットを受け取り、かつルールのセットがルールエンジンによって実行され得ることを実証するためにルールのセットにおいて一連の論理テストを行うように構成され、ならびに、修正を要求するルールのセットにおける任意のエラーのルール書き込み装置に命令するように構成されたテスターをさらに含む。
【０３０７】
一実施形態では、システムは、ユーザーからフォームを受け取り、かつコンフィギュレータ用の入力データを開発するためにフォームから情報を抽出するように構成されたデータ抽出器にフォームを出力するように構成されたフォームデポジトリをさらに含む。
【０３０８】
一実施形態では、フォームから抽出された情報は１つ以上のグラフィックオブジェクトと、１つ以上のプロセス状態、１つ以上の入力、１つ以上の予想される出力、および１つ以上の動作を識別する１つ以上のグラフィックオブジェクトに関連した他の情報とを含んでいる。
【０３０９】
一実施形態では、アプリケーションの機能を行う方法は、ユーザー、１つ以上の他のソース、またはユーザーと１つ以上の他のソースの組み合わせから、機能に関するアプリケーションへの入力を受け取るステップ；機能に適用する１つ以上のルールと、入力に基づいて１つ以上のルールに関連した事実の集合を決定するステップ；１つ以上のルールと事実の集合を含むルールエンジンに対するメッセージを送るステップ；機能に関連するルールに依存したレスポンスを開発するためにルールエンジン内で１つ以上のルールと事実の集合を処理するステップであって、こうした処理ステップは、後向き連鎖クエリーを含む前向き連鎖ルール内の状態を作成することによって前向き連鎖ルールを後向き連鎖ルールと組み合わせるステップを含んでいる、ステップ；アプリケーションにルールに依存したレスポンスを送るステップ；および、機能の性能に帰するルールに依存したレスポンスに基づいてアプリケーション内で１つ以上のワークフローを行うステップ、を含む。
【０３１０】
一実施形態では、ルールエンジン内で前向き連鎖ルールを後向き連鎖ルールと組み合わせる方法は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用するステップを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は、実行するべき新しいルールを選択するために、次の試されていない事実にスキップする。
【０３１１】
一実施形態では、アプリケーションの機能を実行する方法は、ユーザー、１つ以上の他のソース、またはユーザーと１つ以上の他のソースの組み合わせから、機能に関するアプリケーションへの入力を受け取るステップ；機能に適用する１つ以上のルールと、入力に基づいて１つ以上のルールに関連した事実の集合を決定するステップ；１つ以上のルールと事実の集合を含むルールエンジンに対するメッセージを送るステップ；機能に関連するルールに依存したレスポンスを開発するためにルールエンジン内で１つ以上のルールと事実の集合を処理するステップであって、こうした処理するステップは、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせるステップであって、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の試されていない事実にスキップする、ステップ；アプリケーションにルールに依存したレスポンスを送るステップ；および、機能の性能に帰するルールに依存したレスポンスに基づいてアプリケーション内で１つ以上のワークフローを行うステップ、を含む。
【０３１２】
一実施形態では、ユーザーのためのドキュメントを処理する方法は、文書処理アプリケーションでユーザーからドキュメントを受け取るステップ；ドキュメントの識別プロセスを始めるために、ドキュメントからのデータを含むメッセージをルールエンジンに送るステップ；ドキュメントに関してドキュメントの種類とドキュメントの内容を識別する第１のルールに依存したレスポンスを引き起こすために、ルールエンジン内で動作されるルールの第１のセットに基づいてドキュメントを分析するステップ；第１のルールに依存したレスポンスに基づいて、ドキュメントの種類に応じたドキュメントのハンドラープロセスを始めるために、ルールエンジンにメッセージを送るステップ；第２のルールに依存したレスポンスを引き起こすために、ハンドラープロセスに対応するルールの第２のセットに基づいてドキュメント内容を分析するステップ；および、第２のルールに依存したレスポンスに基づいて、ドキュメントを処理するために文書処理アプリケーション内で１つ以上のワークフローを実行するステップ、を含む。
【０３１３】
実施形態では、ドキュメントを分析するステップとドキュメント内容を分析するステップは、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせるステップを含んでいる。
【０３１４】
実施形態では、ドキュメントを分析するステップとドキュメント内容を分析するステップは、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせるステップを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の試されていない事実にスキップする。
【０３１５】
実施形態では、１つ以上のワークフローはユーザーの生産性を改善する。
【０３１６】
実施形態では、ドキュメントはローンの申し込みに関し、第２のルールに依存したレスポンスはローンの申し込みを承認し、ローンの申し込みを拒否し、あるいは、ローンの申し込みを評価するためには追加のドキュメントまたは情報が必要となることを示す。
【０３１７】
一実施形態では、製品を開発し、テストし、および分析するための方法は、アプリケーションにおいて製品に関するデータを受け取るステップ；データを分析するためのプロセスを開始するためにデータを含むメッセージをルールエンジンに送るステップ；データに応じてルールに依存したレスポンスを引き起こすために、ルールエンジン内で動作するルールのセットに基づいてデータを分析するステップ；および、ルールに依存したレスポンスに基づいて、製品の開発、テスト、または分析に関連付けられるアプリケーション内の１つ以上のワークフローを実行するステップを含む。
【０３１８】
実施形態では、データを分析するステップは、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせるステップを含んでいる。
【０３１９】
実施形態では、データを分析するステップは、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせるステップを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の試されていない事実にスキップする。
【０３２０】
実施形態では、データは、開発される製品の態様に関連付けられるシミュレーションデータであり、ルールに依存したレスポンスはシミュレーションデータに関する問題を示し、１つ以上のワークフローはその問題に関して１人以上の人に警告を出すことを含んでいる。
【０３２１】
実施形態では、データは、開発される製品のプロトタイプに関連付けられるテストデータであり、ルールに依存したレスポンスは、テストデータに関する問題を示し、１つ以上のワークフローは問題に関して１人以上の人に警告を出すことを含んでいる。
【０３２２】
実施形態では、データは開発される製品に関連付けられる分析データであり、ルールに依存したレスポンスは、製品が検定に合格している、検定に失格している、または、水準または規則に従って製品を保証するのに必要な部分が欠けているということを示し、１つ以上のワークフローは、検定に合格した、検定に失格した、または一部を欠いた製品に関して１人以上の人に警告を出すことを含んでいる。
【０３２３】
実施形態では、１つ以上のワークフローは、基準団体（ｓｔａｎｄａｒｄ  ｂｏｄｙ）または監督機関に提出するのに適した報告書を作成することを含んでいる。
【０３２４】
実施形態では、１つ以上のワークフローは、なぜ製品が検定に失格したのかを示す報告書を作成することを含んでいる。
【０３２５】
実施形態では、１つ以上のワークフローは、製品の少なくとも１つの部分が欠けていること、およびその部分が製品内のどこにあり得るかを示す報告書を作成することを含んでいる。
【０３２６】
一実施形態では、航空機のフライトを選択する際にユーザーを支援する方法は、航空機のフライトに関するユーザーの好みについてユーザーからアプリケーション内でデータを受け取るステップ；データを分析するためのプロセスを開始するために、データを含むメッセージをルールエンジンに送るステップ；データに応じてルールに依存したレスポンスを引き起こすためにルールエンジン内で動作するルールのセットに基づいてデータを分析するステップ；および、ルールに依存したレスポンスに基づいて、ユーザーの好みを満たす１つ以上の航空機のフライトを識別すること関連するアプリケーション内で１つ以上のワークフローを実行するステップを含む。
【０３２７】
実施形態では、データを分析するステップは、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせるステップを含んでいる。
【０３２８】
実施形態では、データを分析するステップは、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせるステップを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の試されていない事実にスキップする。
【０３２９】
一実施形態では、航空会社に関連する乗組員をモニターする方法は、各乗組員に関してアプリケーション内でデータを受け取るステップ；データを分析するためのプロセスを開始するためにデータを含むメッセージをルールエンジンに送るステップ；データに応じてルールに依存したレスポンスを引き起こすためにルールエンジン内で動作するルールのセットに基づいてデータを分析するステップ；および、ルールに依存したレスポンスに基づいて、乗組員の勤務時間要件を満たす１つ以上の航空機のフライトを識別することに関連したアプリケーション内の１つ以上のワークフローを実行するステップを含む。
【０３３０】
実施形態では、データを分析するステップは、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせるステップを含んでいる。
【０３３１】
実施形態中では、データを分析するステップは、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせるステップを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の試されていない事実にスキップする。
【０３３２】
実施形態では、１つ以上のワークフローは、乗組員のための勤務スケジュールを識別する。
【０３３３】
本開示全体にわたって多くの演算システムが記載されてきた。これらのシステムの記載は、本開示の教示またはか適用性を制限することを意図していない。さらに、例証されたシステムの様々な構成要素の処理は、多くの機械、ネットワーク、および他のコンピューティングリソースに分散されることもある。例えば、ルールエンジン、プロセスエンジン、データベース、および対応するアプリケーションの構成要素は、別の装置として、または別の演算システム上で、あるいは、代替的に１つの装置または１つの演算システムとして、実行されてもよい。加えて、システムの２つ以上の構成要素は、より少ない数の構成要素に組み合わされることもある。さらに、例証されるシステムの様々な構成要素は、専用のコンピューターハードウェアシステムよりもむしろ、１つ以上の仮想マシン中で実行されることもある。同様に、示されたデータベースと他の記憶位置は、例えば、記憶域ネットワークまたは他の分散ストレージシステムを含む物理的および／または論理なデータ記憶装置を表すこともある。さらに、いくつかの実施形態では、示された構成要素間の接続は、ハードウェア間の実際の接続よりもむしろ、データフローの可能なパスを表す。可能な接続のいくつかの例が示されているが、示された構成要素の部分集合のいずれも様々なインプリメンテーションにおいて構成要素の他の部分集合と通信することもある。
【０３３４】
実施形態に依存して、本明細書に記載されたアルゴリズムのいずれかの特定の動作、事象、または機能は、異なるシーケンスで行われることもあれば、追加され、合体され、または一緒に省略されることもある（例えば、記載されたすべての動作または事象がアルゴリズムを実行するのに必要なわけではない）。さらに、特定の実施形態において、動作または事象は、例えば、マルチスレッド処理、割込み処理、あるいは多数のプロセッサーまたはプロセッサコアによって、あるいは他のパラレルアーキテクチャー上で、連続してではなく、同時に行われることもある。
【０３３５】
図１３に関して以下に詳細に議論されるように、様々な例証されるシステムのそれぞれは、本明細書に記載された様々な機能を行うようにプログラムまたは構成された演算システムとして実行されることもある。演算システムは、記載された機能を実行するためにネットワーク上で通信および相互動作（ｉｎｔｅｒｏｐｅｒａｔｅ）する多数の別個のコンピュータまたは演算装置（例えば、物理サーバー、ワークステーション、ストレージアレイなど）を含むこともある。こうした演算装置はそれぞれ、メモリまたは他の非一時的なコンピュータ可読化独記憶媒体に記憶されるプログラム命令またはモジュールを実行するプロセッサー（または多数のプロセッサー）を含むことが一般である。本明細書で開示された様々な機能の一部またはすべてが代替的にコンピュータシステムのアプリケーションに特有の回路で実行されることもあるが、様々な機能はこうしたプログラム命令で具体化されることもある。演算システムが多くの演算装置を含んでいる場合、これらの装置は、必要性はないが、同じ場所に配置されてもよい。開示された方法とタスクの結果は、固体メモリチップおよび／または磁気ディスクなどの物理記憶装置を異なる状態に転換することによって永続的に記憶されることもある。本明細書に記載されたそれぞれのアプリケーションは、関連するサーバーコードで、またはクライアントサーバ構成でプログラムされた１つ以上の物理サーバーなどの１台以上の演算装置によって実行されてもよい。
【０３３６】
図１３は、本開示の態様を実行するのに適した演算装置（１８００）の典型的なインプリメンテーションの実施形態を描く。演算装置（１８００）は、メモリ（１８０８）および／または記憶装置（１８１６）に記憶された命令を実行することにより、本明細書に記載された様々な機能を行うように構成されることもある。演算装置の様々な例としては、パソコン、携帯電話、スマートフォン、表、ワークステーション、サーバーなどが挙げられる。実施形態も、通信ネットワークによって通信可能に接続された多くの演算装置を含む分散演算システム上で実行されてもよい。
【０３３７】
１台以上のプロセッサー（１８０６）は、１つ以上のシステムおよびマイクロコントローラ、マイクロプロセッサー、縮小された命令セット回路（ＲＩＳＣ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理回路（ＰＬＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および本明細書に記載された機能を実行することができる他の回路を含む、任意の適切なプログラム可能な回路を含んでいる。上記例の実施形態は、いかなる方法でも「プロセッサー」の用語の定義および／または意味を制限することを意図していない。
【０３３８】
メモリ（１８０８）と記憶装置（１８１６）は、限定されないが、シグナルそれ自体、ランダムアクセスメモリー（ＲＡＭ）、フラッシュメモリー、ハードディスクドライブ、ソリッドステートドライブ、ディスケット、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、および／または、任意の適切なメモリを除く、非一時的なコンピュータ読み取り可能な記憶媒体を含む。典型的なインプリメンテーションでは、メモリ（１８０８）と記憶装置（１８１６）は、プロセッサー（１８０６）が本明細書に記載された機能を行うことを可能にするプロセッサー（１８０６）によって実行可能な（例えば、プロセッサー（１８０６）は命令によってプログラムされることもある）本開示の態様を具体化するデータおよび／または命令を含んでもよい。さらに、メモリ（１８０８）と記憶装置（１８１６）は、オペレーションシステム（１８０２）、基本的な入出力システム（「ＢＩＯＳ」）（１８０４）、および様々なアプリケーションを含むこともある。
【０３３９】
ディスプレイ（１８１０）は、演算装置のユーザーに情報を提示するために少なくとも１つの出力構成要素を含み、ディスプレイ（１８１０）を介してインタラクティブ機能を提供するためのユーザインターフェース（１８１１）を組み込んでもよい。ディスプレイ（１８１０）は、演算装置のユーザーに情報を伝えることができる任意の構成要素であってもよい。いくつかのインプリメンテーションでは、ディスプレイ（１８１０）は、ビデオアダプターおよび／またはオーディオアダプター等の出力アダプターを含んでいる。出力アダプターは、プロセッサー（１８０６）に動作可能に接続され、表示装置（例えば、液晶ディスプレイ（ＬＣＤ）、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、陰極線管（ＣＲＴ）、「電子インク」ディスプレイなど）、または音声出力装置（例えば、スピーカー、ヘッドホンなど）のような出力装置に動作可能に接続されるように構成される。
【０３４０】
入力装置（１８１２）は、ユーザーからの入力を受け取るための少なくとも１つの入力構成要素を含んでいる。入力構成要素（１８１２）は、例えば、キーボード、ポインティングデバイス、マウス、スタイラス、タッチ感知パネル（例えば、タッチパッド、またはディスプレイ（１８１０）に組み入れられたタッチスクリーン）、ジャイロスコープ、加速度計、位置検知器、音声入力装置などを含んでもよい。タッチスクリーンのような単一の構成要素は、入力装置（１８１２）とディスプレイ（１８１０）の両方として機能することもある。
【０３４１】
ネットワークインターフェイス（１８１４）は、有線ネットワークまたは無線ネットワークで制御信号とデータ信号を送受信するように構成された１つ以上の装置を含んでもよい。様々な実施形態では、ネットワークインターフェイス（１８１４）の１つ以上は、無線周波数スペクトルで送信し、時分割多重アクセス（「ＴＤＭＡ」）通信プロトコル、広帯域の符号分割多重アクセス（「Ｗ−ＣＤＭＡ」）などを使用して動作することもある。様々な実施形態では、ネットワークインターフェイス（１８１４）は、イーサネット（登録商標），８０２．１１、インターネットプロトコル（「ＩＰ」）送信等を用いて、有線または無線のネットワークで受信データと制御信号を送受信することもある。有線または無線のネットワークは、ゲートウエイ、スイッチ、ハブ、ルーター、ファイアウォール、プロキシーなどの様々なネットワーク構成要素を含むこともある。
【０３４２】
とりわけ、「こともある（ｍａｙ）」、「かもしれない（ｍｉｇｈｔ）」、「〜してもよい（ｍａｙ）」、「例えば（ｅ．ｇ．）」などの本明細書で使用される条件付きの言葉は一般に、特段の定めのない限り、あるいは、さもなければ用いられる文脈で理解されて、特定の実施形態が、ほかの実施形態とは異なり、特定の特徴、要素、および／または状態を含むということを伝えることを意図している。したがって、こうした条件付きの言語は、特徴、要素、および／または状態がいかなる方法でも１つ以上の実施形態で必要とされるということ、あるいは、１つ以上の実施形態が、著者の入力や促しがあってもなくても、これらの特徴、要素および／または状態が任意の特別な実施形態で行なわれることになっているかどうかを決定するため論理を必ず含んでいるということを含意することを必ずしも意図したものではない。
【０３４３】
上記の詳細な記載が様々な実施形態に適用され新規な特徴を示し、記載し、および指摘してきたが、例証された装置またはアルゴリズムのフォームまたは詳細の様々な省略、置換、および変更は、本開示の精神から逸脱することなくなされてもよい。認識されているように、いくつかの特徴は他の特徴とは別々に使用されるか実行されることもあるが、本明細書に記載されたプロセスは、本明細書で説明される特徴と利点のすべてを提供するとは限らないフォームで具体化されることもある。保護の範囲は先の記載によってではなく添付の特許請求の範囲によって定義される。請求項の等価物の意味と範囲内にあるすべての変更はその範囲内に受け入れられる。
【図１】
2016505953.tif 000102
【図２】
2016505953.tif 000103
【図３】
2016505953.tif 000104
【図４】
2016505953.tif 000105
【図５Ａ】
2016505953.tif 000106
【図５Ｂ】
2016505953.tif 000107
【図５Ｃ】
2016505953.tif 000108
【図６】
2016505953.tif 000109
【図７】
2016505953.tif 000110
【図８】
2016505953.tif 000111
【図９】
2016505953.tif 000112
【図１０】
2016505953.tif 000113
【図１１】
2016505953.tif 000114
【図１２】
2016505953.tif 000115
【図１３】
2016505953.tif 000116
【手続補正書】
【提出日】平成26年10月10日(2014.10.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ルールエンジンで使用されるルールコードのセットを構築するためのシステムであって、
ユーザーにルールコードのセットを書かせたり、入力されたデータをフォーマットしてフォーマットされたデータを作成させたりすることを要求せずに、ユーザーから入力されたデータを受け取るように構成されたコンフィギュレータであって、入力されたデータが、アプリケーションの１つ以上のプロセス状態、１つ以上のプロセス状態の各々で受け取られる１つ以上の入力、１つ以上のプロセス状態の各々の１つ以上の予想される出力、および１つ以上のプロセス状態の各々で行なわれる１つ以上の動作を含む、コンフィギュレータ、および、
フォーマットされたデータを受け取るように、かつアプリケーションと協働して動作するルールエンジンにまとめて送信可能であるとともに該ルールエンジンによって実行可能なルールコードのセットを生成するように構成されたルール書き込み装置であって、１つ以上のルールを含むルールコードのセットが、１つ以上のプロセス状態のなかの最新のプロセス状態に関する１つ以上のルールについて真であるデータを含む事実の集合に適用され；最新のプロセス状態の間に任意のソースから１つ以上のルールに関する追加のルールまたは追加のデータが要求されない、ルール書き込み装置、
を含むシステム。
【請求項２】
ルール書き込み装置からルールコードのセットを受け取るように、かつルールのセットがルールエンジンによって実行され得ることを実証するためにルールのセットにおいて一連の論理テストを行うように構成され、ならびに、修正を要求するルールのセットにおける任意のエラーのルール書き込み装置に命令するように構成されたテスターをさらに含む、請求項１に記載のシステム。
【請求項３】
ユーザーからフォームを受け取り、かつコンフィギュレータ用の入力データを開発するためにフォームから情報を抽出するように構成されたデータ抽出器にフォームを出力するように構成されたフォームデポジトリをさらに含む、請求項１に記載のシステム。
【請求項４】
フォームから抽出された情報が、１つ以上のグラフィックオブジェクトと、１つ以上のプロセス状態、１つ以上の入力、１つ以上の予想される出力、および１つ以上の動作を識別する１つ以上のグラフィックオブジェクトに関連した他の情報とを含む、請求項３に記載のシステム。
【請求項５】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、アプリケーションの機能を行うための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
ユーザー、１つ以上の他のソース、またはユーザーと１つ以上の他のソースの組み合わせから、機能に関するアプリケーションへの入力を受け取ること；
機能に適用する１つ以上のルールと、入力に基づいて１つ以上のルールに関連した事実の集合とを決定することであって、事実の集合は、事実の集合内のデータが１つ以上のルールに真である最新のプロセス状態を表す、こと；
１つ以上のルールと事実の集合を含むルールエンジンに対するメッセージを一緒に送ること；
機能に関連するルールに依存したレスポンスを開発するために最新のプロセス状態の間に任意のソースから１つ以上のルールに関する追加のルールまたは追加のデータを要求することなく、ルールエンジン内で１つ以上のルールと事実の集合を処理することであって、こうした処理は、後向き連鎖クエリーを含む前向き連鎖ルール内の状態を作成することによって前向き連鎖ルールを後向き連鎖ルールと組み合わせることを含む、こと；
アプリケーションへルールに依存したレスポンスを送ること；および、
機能の性能に帰するルールに依存したレスポンスに基づいてアプリケーション内で１つ以上のワークフローを行うこと、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項６】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、ルールエンジン内で前向き連鎖ルールを後向き連鎖ルールと組み合わせるための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することであって、この場合、前向き連鎖ルールの実行が中断される、こと、
問題のある事実に関するルール述語の依存性を表に記録すること、および、
前向き連鎖ルールの実行中に、実行するべき新しいルールを選択するために、次の未試行の事実にスキップすること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項７】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、アプリケーションの機能を実行するための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
ユーザー、１つ以上の他のソース、またはユーザーと１つ以上の他のソースの組み合わせから、機能に関するアプリケーションへの入力を受け取ること；
機能に適用する１つ以上のルールと、入力に基づいて１つ以上のルールに関連した事実の集合を決定することであって、事実の集合は、事実の集合内のデータが１つ以上のルールに真である最新のプロセス状態を表す、こと；
１つ以上のルールと事実の集合を含むルールエンジンに対するメッセージを一緒に送ること；
機能に関連するルールに依存したレスポンスを開発するために最新のプロセス状態の間に任意のソースから１つ以上のルールに関する追加のルールまたは追加のデータを要求することなく、ルールエンジン内で１つ以上のルールと事実の集合を処理することであって、こうした処理は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせることを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、こと；
アプリケーションへルールに依存したレスポンスを送ること；および、
機能の性能に帰するルールに依存したレスポンスに基づいてアプリケーション内で１つ以上のワークフローを行うこと、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項８】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、ユーザーのためにドキュメントを処理する命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
文書処理アプリケーションでユーザーからドキュメントを受け取ること；
ドキュメントの識別プロセスを始めるために、ドキュメントからのデータと、データに一緒に適用される第１のルールのセットを含むメッセージをルールエンジンに送ることであって、データが最新のプロセス状態に関する第１のルールのセットについて真である、こと；
最新のプロセス状態の間に任意のソースから第１のルールのセットに関する追加のルールまたは追加のデータを要求することなく、ドキュメントに関してドキュメントの種類とドキュメントの内容を識別する第１のルールに依存したレスポンスを引き起こすために、ルールエンジン内で動作される第１のルールのセットに基づいてドキュメントを分析すること；
第１のルールに依存したレスポンスに基づいて、ドキュメントの種類に応じたドキュメントのハンドラープロセスを始めるために、ルールエンジンにメッセージを送ること；
第２のルールに依存したレスポンスを引き起こすために、ハンドラープロセスに対応するルールの第２のセットに基づいてドキュメントの内容を分析すること；および、
第２のルールに依存したレスポンスに基づいて、ドキュメントを処理するために文書処理アプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項９】
ドキュメントを分析する命令とドキュメントの内容を分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項８に記載の非一時的なコンピューター読み取り可能な記憶媒体。
【請求項１０】
ドキュメントを分析する命令とドキュメントの内容を分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせる命令を含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項８に記載の非一時的なコンピューター読み取り可能な記憶媒体。
【請求項１１】
１つ以上のワークフローはユーザーの生産性を改善する、請求項８に記載の非一時的な読み取り可能な記憶媒体。
【請求項１２】
ドキュメントはローンの申し込みに関し、第２のルールに依存したレスポンスはローンの申し込みを承認し、ローンの申し込みを拒否し、あるいは、ローンの申し込みを評価するためには追加のドキュメントまたは情報が必要となることを示す、請求項８に記載の非一時的な読み取り可能な記憶媒体。
【請求項１３】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、製品を開発し、テストし、および分析するための命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
アプリケーションにおいて製品に関するデータを受け取ること；
データを分析するためのプロセスを開始するためにデータを含むメッセージと、データに一緒に適用されるルールのセットをルールエンジンに送ることであって、データが最新のプロセス状態に関するルールのセットについて真である、こと；
最新のプロセス状態の間に任意のソースから第１のルールのセットに関する追加のルールまたは追加のデータを要求することなく、データに応じてルールに依存したレスポンスを引き起こすために、ルールエンジン内で動作するルールのセットに基づいてデータを分析すること；および、
ルールに依存したレスポンスに基づいて、製品の開発、テスト、または分析に関連付けられるアプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項１４】
データを分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１５】
データを分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせる命令を含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１６】
データは、開発される製品の態様に関連付けられるシミュレーションデータであり、ルールに依存したレスポンスはシミュレーションデータに関する問題を示し、１つ以上のワークフローはその問題に関して１人以上の人に警告を出すことを含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１７】
データは、開発される製品のプロトタイプに関連付けられるテストデータであり、ルールに依存したレスポンスは、テストデータに関する問題を示し、１つ以上のワークフローは問題に関して１人以上の人に警告を出すことを含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１８】
データは開発される製品に関連付けられる分析データであり、ルールに依存したレスポンスは、製品が検定に合格している、検定に失格している、または、水準または規則に従って製品を保証するのに必要な部分が欠けているということを示し、１つ以上のワークフローは、検定に合格した、検定に失格した、または一部を欠いた製品に関して１人以上の人に警告を出すことを含む、請求項１３に記載の非一時的な読み取り可能な記憶媒体。
【請求項１９】
１つ以上のワークフローは、基準団体または監督機関に提出するのに適した報告書を作成することを含む、請求項１８に記載の非一時的な読み取り可能な記憶媒体。
【請求項２０】
１つ以上のワークフローは、なぜ製品が検定に失格したのかを示す報告書を作成することを含む、請求項１８に記載の非一時的な読み取り可能な記憶媒体。
【請求項２１】
１つ以上のワークフローは、製品の少なくとも１つの部分が欠けていること、およびその部分が製品内のどこにあり得るかを示す報告書を作成することを含む、請求項１８に記載の非一時的な読み取り可能な記憶媒体。
【請求項２２】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、航空機のフライトを選択する際にユーザーを支援する命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
航空機のフライトに関するユーザーの好みについてユーザーからアプリケーション内でデータを受け取ること；
データを分析するためのプロセスを開始するために、データを含むメッセージと、データに一緒に適用されるルールのセットをルールエンジンに送ることであって、データが最新のプロセス状態に関するルールのセットについて真である、こと；
最新のプロセス状態の間に任意のソースから第１のルールのセットに関する追加のルールまたは追加のデータを要求することなく、データに応じてルールに依存したレスポンスを引き起こすためにルールエンジン内で動作するルールのセットに基づいてデータを分析すること；および、
ルールに依存したレスポンスに基づいて、ユーザーの好みを満たす１つ以上の航空機のフライトを識別することに関連するアプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項２３】
データを分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項２２に記載の非一時的な読み取り可能な記憶媒体。
【請求項２４】
データを分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせることを含み、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項２２に記載の非一時的な読み取り可能な記憶媒体。
【請求項２５】
演算装置上で実行される際に少なくとも以下のことを演算装置にさせる、航空会社に関連する乗組員をモニターする命令を含む、非一時的なコンピューター読み取り可能な記憶媒体：
各乗組員に関してアプリケーション内でデータを受け取ること；
データを分析するためのプロセスを開始するためにデータを含むメッセージと、データに一緒に適用されるルールのセットをルールエンジンに送ることであって、データが最新のプロセス状態に関するルールのセットについて真である、こと；
最新のプロセス状態の間に任意のソースから第１のルールのセットに関する追加のルールまたは追加のデータを要求することなく、データに応じてルールに依存したレスポンスを引き起こすためにルールエンジン内で動作するルールのセットに基づいてデータを分析すること；および、
ルールに依存したレスポンスに基づいて、乗組員の勤務時間要件を満たす１つ以上の航空機のフライトを識別することに関連したアプリケーション内で１つ以上のワークフローを実行すること、
を含む、非一時的なコンピューター読み取り可能な記憶媒体。
【請求項２６】
データを分析する命令は、後向き連鎖クエリーを含む前向き連鎖ルール内で条件を作成することにより、前向き連鎖ルールを後向き連鎖ルールと組み合わせる命令を含む、請求項２５に記載の非一時的な読み取り可能な記憶媒体。
【請求項２７】
データを分析する命令は、前向き連鎖ルールが別の前向き連鎖の推論の否定に依存する条件を含まない限り、前向き連鎖ルールから推論された事実を後向き連鎖ルールの目標として利用することによって、後向き連鎖ルールを前向き連鎖ルールと組み合わせることを含み、この場合、前向き連鎖ルールの実行が中断され、問題のある事実に関するルール述語の依存性が表に記録され、前向き連鎖ルールの実行は実行するべき新しいルールを選択するために次の未試行の事実にスキップする、請求項２５に記載の非一時的な読み取り可能な記憶媒体。
【請求項２８】
１つ以上のワークフローは、乗組員の勤務スケジュールを識別する、請求項２５に記載の非一時的な読み取り可能な記憶媒体。
【国際調査報告】
2016505953.tif 000117
2016505953.tif 000118
2016505953.tif 000119
2016505953.tif 000120