(57)【要約】  エンドユーザルールロジックの定義および実行のインフラストラクチャを提供するルールベースソフトウェアアーキテクチャ。これによって、単純なＩＦ−ＴＨＥＮルールを使用する統一されたストレージプラットフォームでのデータのエンドユーザ自動化が可能になる。このアーキテクチャは、データに関連するアイテムを追跡する監視コンポーネントと、ルールコンポーネントへのルールコンポーネントインターフェースを含み、追跡されるアイテムに関連するメタデータを使用して、アイテムのサブセットの自動化されたハンドリングを提供する。このシステムは、さらに、内容ベースのロジックを使用することによる、システム内での仮想コレクションおよびアイテムの定義を提供する。このシステムは、さらに、トリガロジックの関数としてアイテムおよびアイテムのコレクションを動的にアクティブにセットする１つまたは複数のトリガコンポーネントが含まれる。追加コンポーネントに、アイテムに制約ロジックを課す制約コンポーネントと、判断ポイントでアプリケーションカスタマイゼーションロジックをイネーブルすることをサポートする判断コンポーネントを含めることができる。
2007537512.tif 000002
【特許請求の範囲】
【請求項１】
データに関連するアイテムを追跡する監視コンポーネントと、
前記アイテムのサブセットの自動化されたハンドリングを提供するために、前記追跡されるアイテムに関連するメタデータを使用するルールコンポーネントと
を含むことを特徴とするデータ管理を容易にするシステム。
【請求項２】
内容ベースロジックを使用することによる前記システム内での仮想コレクションおよびアイテムの定義をさらに提供することを特徴とする請求項１に記載のシステム。
【請求項３】
トリガロジックの関数としてアイテムおよびアイテムのコレクションを動的にアクティブにセットする１つまたは複数のトリガコンポーネントをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項４】
前記アイテム内で制約ロジックを課すことを容易にする制約コンポーネントをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項５】
１つまたは複数の判断ポイントでのアプリケーションカスタマイゼーションロジックのイネーブルを容易にする判断コンポーネントをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項６】
エンドユーザは、追加メタデータを提供することを特徴とする請求項１に記載のシステム。
【請求項７】
前記追加メタデータは、宣言的であることを特徴とする請求項６に記載のシステム。
【請求項８】
前記ルールコンポーネントは、前記データを自動化するルールの出力を容易にすることを特徴とする請求項１に記載のシステム。
【請求項９】
前記ルールコンポーネントは、自動的に派生された条件を含むルールの出力を容易にすることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ルールコンポーネントは、明示的に指定された条件を含むルールの出力を容易にすることを特徴とする請求項１に記載のシステム。
【請求項１１】
前記ルールコンポーネントは、引数であるエンドユーザ入力を含むルールの出力を容易にすることを特徴とする請求項１に記載のシステム。
【請求項１２】
ルールの間の衝突を解決する解決コンポーネントをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項１３】
前記解決コンポーネントは、エンドユーザルール優先順位付けおよび事前定義の解決ポリシの少なくとも１つによって前記ルール衝突を解決することを特徴とする請求項１３に記載のシステム。
【請求項１４】
請求項１に記載のシステムを実行するコンピュータ実行可能命令をストアされることを特徴とするコンピュータ可読媒体。
【請求項１５】
請求項１に記載のシステムを使用することを特徴とするコンピュータ。
【請求項１６】
請求項１に記載のシステムを使用することを特徴とするサーバ。
【請求項１７】
ファイルシステムデータに関連するアイテムを追跡する監視コンポーネントと、
前記データの自動化されたハンドリングを提供するために前記追跡されるアイテムに関連するエンドユーザ生成のルールを処理するルールコンポーネントと
を含むことを特徴とするエンドユーザによるファイルシステム管理を容易にするルールベースのシステム。
【請求項１８】
前記エンドユーザは、前記ルールを使用することによって他のアイテムから仮想コレクションおよびアイテムを定義することを特徴とする請求項１７に記載のシステム。
【請求項１９】
同期式および非同期式である１つまたは複数のトリガコンポーネントをさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記アイテム内で制約ロジックを課すのを容易にする制約コンポーネントと、１つまたは複数の判断ポイントでのアプリケーションカスタマイゼーションロジックのイネーブルを容易にする判断コンポーネントとをさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項２１】
前記ルールは、自動的に派生される条件および明示的に指定される条件を含むことを特徴とする請求項１７に記載のシステム。
【請求項２２】
前記ルールは、引数であるエンドユーザ入力を含むことを特徴とする請求項１７に記載のシステム。
【請求項２３】
エンドユーザルール優先順位付けおよび事前定義の解決ポリシの少なくとも１つを使用することによって、複数の前記ルールの間の衝突を解決する解決コンポーネントをさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項２４】
データに関連するアイテムを追跡することと
前記アイテムのサブセットの自動化されたハンドリングを容易にするために、前記追跡されるアイテムに関連するメタデータを提供することと
を含むファイルシステムデータのエンドユーザ自動化を容易にする方法を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項２５】
内容ベースロジックを使用することによる前記システム内での仮想コレクションおよびアイテムの定義をさらに含むことを特徴とする請求項２４に記載の方法。
【請求項２６】
トリガロジックの関数としてアイテムおよびアイテムのコレクションを動的にアクティブにセットすることをさらに含むことを特徴とする請求項２４に記載の方法。
【請求項２７】
前記アイテム内で制約ロジックを課す動作と、
前記データ内で１つまたは複数の判断ポイントを識別する動作と、
前記１つまたは複数の判断ポイントでアプリケーションカスタマイゼーションロジックをイネーブルする動作と
をさらに含むことを特徴とする請求項２４に記載の方法。
【請求項２８】
前記データの自動化を容易にする１つまたは複数のルールを出力することをさらに含むことを特徴とする請求項２４に記載の方法。
【請求項２９】
自動的に派生される条件および明示的に指定される条件を含むルールを出力することをさらに含むことを特徴とする請求項２４に記載の方法。
【請求項３０】
引数であるエンドユーザ入力を含むルールを出力することをさらに含むことを特徴とする請求項２４に記載の方法。
【請求項３１】
エンドユーザによって作成される１つまたは複数のルールを使用して、ファイルシステムのデータに関連するアイテムを追跡することと、
前記データの自動化されたハンドリングを容易にする、前記追跡されるアイテムに関連する前記ルールを処理することと
を含むことを特徴とする前記ファイルシステムを管理するルールベースの方法。
【請求項３２】
エンドユーザルール優先順位付けおよび事前定義の解決ポリシの少なくとも１つによって前記ルールの間の衝突を解決することをさらに含むことを特徴とする請求項３１に記載の方法。
【請求項３３】
内容ベースロジックを使用することによって前記システム内で仮想コレクションおよびアイテムを定義することをさらに含むことを特徴とする請求項３１に記載の方法。
【請求項３４】
トリガロジックの関数としてアイテムおよびアイテムのコレクションを動的にアクティブにセットすることをさらに含むことを特徴とする請求項３１に記載の方法。
【請求項３５】
前記アイテム内で制約ロジックを課す動作と、
前記データ内で１つまたは複数の判断ポイントを識別する動作と、
前記１つまたは複数の判断ポイントでアプリケーションカスタマイゼーションロジックをイネーブルする動作と
をさらに含むことを特徴とする請求項３１に記載の方法。
【請求項３６】
前記１つまたは複数のルールのロジックコンポーネントを含み、前記データの前記自動化されたハンドリングを容易にするエンドユーザプログラムをコンポーズするのに使用される代数を提供することをさらに含むことを特徴とする請求項３１に記載の方法。
【請求項３７】
前記ロジックコンポーネントは、クエリ、複雑な動詞、およびＩＦ−ＴＨＥＮルール構造を使用する制約の少なくとも１つを定義するのに使用されることを特徴とする請求項３６に記載の方法。
【請求項３８】
前記ロジックコンポーネントは、複数のアプリケーションにまたがるルールロジックの共通の視覚的提示を容易にすることを特徴とする請求項３６に記載の方法。
【請求項３９】
プロパティを生成するためにルールを用いて値を定義する動作と、
エージェントを作成するためにルールをイベントと組み合わせる動作と、
新しいリストを生成するためにリストをフィルタリングする動作と、
前記新しいリストを別のリストと組み合わせる動作と
のうちの少なくとも１つをさらに含むことを特徴とする請求項３１に記載の方法。
【請求項４０】
前記エンドユーザが
既存の型と異なる新しいエンドユーザ型を定義することと、
前記既存の型を動的に変更することと、
クエリを定義し、永続させることと、
特定のアイテムに影響するロジックを定義することと
のうちの少なくとも１つを実行することを可能にするロジックコンポーネントを含むルールベースの代数を提供することをさらに含むことを特徴とする請求項３１に記載の方法。
【請求項４１】
第１アプリケーション内で行われたルールベースの変更を、別のアプリケーションにまたがって永続させることをさらに含むことを特徴とする請求項３１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データのエンドユーザ自動化を容易にするルールベースソフトウェアアーキテクチャに関する。
【背景技術】
【０００２】
コンピュータおよびコンピューティングは、必ず、ユーザの世界を２つの等級すなわち、プログラムを形成し、価値があり豊かな挙動を可能にする複雑な形でコンピュータを使用する方法を知っている、よく知っている「司祭長」と、彼らの言いなりになり、コンピュータがその人の必要のためによく働くようにするための知識または情報または教育への簡単なまたは安価なアクセスを拒否される初心者ユーザに分割してきた。しかし、技術がアクセスへの障壁のいくつかを破壊した時に、コンピューティングの主要なブレークスルーが発生した。
【０００３】
メインフレームの世界では、コンピュータが、大企業以外には持つのに高価にすぎた。ミニコンピュータおよびその後のパーソナルコンピュータ（ＰＣ）の出現が、コスト障壁を破壊し、コンピュータを小企業および個人が入手可能なものにした。
【０００４】
１９８０年代に、プログラマが、グラフィカルユーザインターフェース（ＧＵＩ）アプリケーションを作ろうと努力し、豊富で一貫性のあるＧＵＩがなければ、プログラマは、ＰＣユーザに価値のあるアプリケーションを作ることができなかった。Ｖｉｓｕａｌ  Ｂａｓｉｃ革命ならびにコントロールおよびイベントベースＧＵＩ構成を使用することによって、大勢のアプリケーション開発者が、簡単に豊富なアプリケーションを作れるようになった。これによって、より多くのエンドユーザがこれらのアプリケーションを利用できる、有効なサイクルも確立された。
【０００５】
１９９０年代に、エンドユーザは、情報へのアクセスの欠如を克服しようと努力した。インターネットの成長およびウェブが、この空間を変容させ、ほとんどすべての価値のある情報が、ブラウザを有するすべての人に入手可能になった。しかし、克服すべき多数の障壁がまだある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
コンピューティングは、パーソナルではない。ＰＣに関して、真に「パーソナル」であるものはごくわずかである。ローカルディスクに保管されたデータは、パーソナルである。しかし、機械の挙動（機械がユーザの代わりに実行すること）は、数百万人のユーザの間でほぼ同一である。非常に強力な汎用コンピュータを所有してはいるが、平均的なユーザは、それを、通信エンドポイントして有用な、検索エントリポイントとして有用な、缶詰にされたマスマーケットアプリケーションの実行に有用な静的ツールであるが、それ以外にはこの言葉の真の意味での「パーソナルコンピューティング」を行えないものとして扱う。現在のアプリケーションで使用可能なパーソナライゼーション機能は、可能であり望ましいものの上っ面を撫でるに過ぎない。
【０００７】
コンピューティングは手動である。ほとんどのコンピュータエンドユーザの日常の作業を考慮されたい。ＰＣは、情報を集め、通信に反応し、判断を行い、それらに作用する、すなわち、通信を開始するか応答し、情報を編成し、商品、旅行などを売り買いする。コンピュータは、人の間の改善された通信を有し、情報への改善されたアクセスを有する。しかし、ＰＣは、判断を行い、正しい時に操作するという責任からエンドユーザをほとんど解放していない。ビジネスの世界では、主要な組織の決断に関する意思決定サポートシステムがある。それでも、ソフトウェアは、多くの日常の重要な個人的決断で平均的なＰＣユーザを助けていない。
【０００８】
コンピューティングは、コンテキスト的ではない。コンピュータソフトウェアは、通常、どちらかといえば静的であり、ユーザの実際のコンテキストに無関係なオプション設定を提供する（例えば、「何故会社と自宅でメッセージングバディの同一のセットを有しなければならないのか」）。
【０００９】
したがって、ユーザは、まだ、電子メール、文書、および他のパーソナルデータのシフト、ソート、検索、および反応に毎日時間を費やすという手作業の情報処理の圧力にますます陥れられることによって、ソフトウェアの「前産業時代」にいる。
【００１０】
エンドユーザソフトウェアは、パーソナライズされ、エンドユーザの必要およびプリファレンスを知り、特にこれらの必要およびユーザコンテキストによって案内される形で働かなければならない。さらに、コンピュータシステムおよびソフトウェアは、すべてのエンドユーザに、エンドユーザに重要な情報を収集し、シフトし、その情報に反応して１日２４時間働くパーソナル実行アシスタントを提供しなければならない。
【００１１】
エンドユーザコンピューティングアクティビティの最も価値のあるクラスは、エンドユーザが関連する情報を見ることの保証（例えば、「悪天候に起因して学校が休みになる場合に知らせよ」）、パーソナライズされた挙動による人対人の通信の機能強化（例えば、「妻が電話をかけてきた時に外出中の場合に、いつ戻るかを妻に知らせよ」）、重要な情報が失われないことの保証（例えば、「緊急の電子メールがある場合に、私のモバイル装置に必ず転送せよ」）、および情報の管理の自動化（例えば、新しい写真が来た時に、そのタイムスタンプ、ＧＰＳ位置、および関連カレンダエントリに基づいて、正しいフォルダおよびに置け」）などの、情報のフローおよび検索を扱う。
【００１２】
これを行う形は、エンドユーザが、彼のコンピュータの挙動を「プログラム」できるようにすることによる。しかし、伝統的なプログラミング言語は、エンドユーザが訓練された開発者でない（かつ、なることができない）という点で、回答ではない。
【００１３】
したがって、この手動プロセスの自動化を容易にし、これによって、ユーザが、コンピュータおよびソフトウェアをパーソナライズして、彼の代わりに自動的に働くようにする改善されたプログラミングプラットフォームの、満たされていない必要性が存在する。
【課題を解決するための手段】
【００１４】
次に、本発明のいくつかの態様の基本的な理解を提供するために、本発明の単純化された要約を提示する。この要約は、本発明の詳細な概要ではない。本発明の主要な／クリティカルな要素を識別することおよび本発明の範囲を区切ることは、意図されていない。この要約の唯一の目的は、後で提示する詳細な説明の前置きとして、単純化された形で本発明の一部の概念を提示することである。
【００１５】
本発明の焦点は、ストレージおよび通信の中心の価値であるデータおよび情報と、通常は初心者の非開発者（消費者、知識労働者、およびビジネスユーザ）であるが、それでも自分のＰＣおよびアプリケーションにカスタマイズされ自動化された形で振る舞わせることを求めるエンドユーザである。
【００１６】
本明細書に開示され、請求される発明に、その一態様において、データを自動化するエンドユーザ定義ルールロジックの定義および実行のインフラストラクチャを提供するルールベースソフトウェアアーキテクチャが含まれる。
【００１７】
ルール作成フレームワークは、ルールを作成する時およびルールを使用するアプリケーションを作成する時に使用されるアイテムおよび関係からなる。これらのアイテムおよび関係は、ルールフレームワークのルールエンジンによって使用されて、特定のイベントに応答してコンピュータが行わなければならないことが決定される。エンドユーザルールに基づいてアプリケーション挙動をカスタマイズするために、プログラマは、ソフトウェアの機能を「ルールイネーブル（ｒｕｌｅ  ｅｎａｂｌｅ）」し、エンドユーザは、これらの機能用のルールを作成する。
【００１８】
本発明は、エンドユーザが、少なくとも４つの形すなわち、データ派生、トリガードアクティブ化（ｔｒｉｇｇｅｒｅｄ  ａｃｔｉｖａｔｉｏｎ）、データ制約、および判断ポイント（ｄｅｃｉｓｉｏｎ  ｐｏｉｎｔ）でエンドユーザデータを「自動化」する論理を定義できるようにする。データ派生ルールは、入力アイテムスコープにアタッチされる。トリガードアクティブ化ルールは、コレクション内で変化するアイテムにアタッチされる。データ制約ルールは、コレクション内で変化するアイテムにアタッチされる。データ駆動判断ルールは、アプリケーションによってアイテムに明示的に適用される。統一されたルールストレージプラットフォームが、図式化されたデータのテーマを取り巻く知識労働者アプリケーションのすべてを一緒に共通ストアにまとめる。
【００１９】
ルールは、複雑なロジックに関する単一の宣言的ＩＦ−ＴＨＥＮプログラミング構造である。すべてのエンドユーザロジックコンポーネントが、ルールとして定義される。すべての他の制約が、単純にバイナリ代数演算子である。ルールは、指定されたアイテム型の入力引数に対する宣言的で副作用がない関数を定義する。
【００２０】
ルール作成フレームワークは、アイテム型すなわち、判断ポイントアイテム、ルールアイテム、およびルールセットアタッチメントアイテムを使用して、ルール作成をサポートする。ＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔと表されるルールセットアタッチメントアイテムは、判断ポイント（ＤｅｃｉｓｉｏｎＰｏｉｎｔと表される）アイテムとルール（Ｒｕｌｅと表される）アイテムの間の接続を表す。これらの接続は、物理的なストアされた「リンク」または計算された「共通値アソシエーション」のいずれかとしてモデリングすることができる。どちらの場合でも、機能は同一であり、このアイテムがそれのために作成されたＲｕｌｅからＤｅｃｉｓｉｏｎＰｏｉｎｔへの接続である。アプリケーションの各ルールイネーブルされた特徴は、判断ポイントアイテムによって定義される。エンドユーザは、特定の判断ポイントのルールを作成し、アプリケーションは、判断ポイントオブジェクトを使用してルールエンジンにデータをサブミットする。各条件／結果ステートメントが、ルールアイテムである。ルールは、実行に関するロジックの単位である。ルールは、マルチステートメントとすることができる。ユーザは、ルールを作成する。ルール編成は、ユーザによって制御することができるが、アプリケーションまたはユーザに提示されるビジュアルブラウジングメタファによって制御することもできる。アプリケーションも、ルールを作成することができる。ルールは、ルールセットアタッチメント（ＲＳＡ）アイテムを介して判断ポイントに関連付けられる。このアタッチメントは、どのルールを所与の入力について実行しなければならないかを判定するために、ルールエンジンによって使用される。
【００２１】
ルールプラットフォームは、データベースクエリプロセッサを使用して、エンドユーザルールを評価する。これは、効率的な評価につながると同時に、セマンティックスが、プラットフォームの残りとの一貫性を保つ。
【００２２】
エンドユーザは、通常、訓練された開発者ではないので、伝統的なプログラミング言語でプログラムすることを期待することは無理である。そうではなく、図式化されたロジックビルディングブロックを提供し、その結果、エンドユーザが、単純だが豊富な組合せでそれらを縫い合わせることによってプログラミングできるようにする。既存のアプリケーションからの経験的な証拠が、エンドユーザがＩＦ−ＴＨＥＮルールを使用して判断ロジックを定義することを快適に感じることが示される。したがって、本発明のルールベースプラットフォームは、単純なＩＦ−ＴＨＥＮルールを使用する統一されたストレージプラットフォームでのデータのエンドユーザ自動化を可能にする。これによって、さらに、Ｂｏｏｌｅａｎ条件を用いるクエリビルダを使用するアプリケーションのホストがサポートされる。
【００２３】
前述および関連する目的の達成のために、本発明のある例示的な態様を、次の説明および添付図面に関して本明細書で説明する。しかし、これらの態様は、本発明の原理を実施できる様々な形のうちの少数を示し、本発明は、そのような態様のすべておよびその同等物を含むことが意図されている。本発明の他の利益および新規の特徴は、図面と共に検討される場合に、本発明の次の詳細な説明から明白になる。
【発明を実施するための最良の形態】
【００２４】
本発明を、これらから図面を参照して説明するが、図面では、同一の符号が、図面全体を通じて同一の要素を指すのに使用される。次の説明では、説明のために、本発明の完全な理解を提供するために多数の具体的な詳細を示す。しかし、本発明を、これらの具体的な詳細なしで実践できることは明白である。他の場合には、本発明の説明を容易にするために、周知の構造および装置を、ブロック図形式で示す。
【００２５】
本明細書で使用される用語「コンポーネント」および「システム」は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれであれ、コンピュータ関連の実体を指すことが意図されている。例えば、コンポーネントは、プロセッサで動作するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピュータとすることができるが、これに制限はされない。例えば、サーバで動作するアプリケーションとサーバの両方を、コンポーネントとすることができる。１つまたは複数のコンポーネントが、１つのプロセスおよび／または実行のスレッド内に存在することができ、１つのコンポーネントを、１つのコンピュータにローカライズし、および／または複数のコンピュータの間で分散することができる。
【００２６】
ルールプラットフォーム
ファイルシステムは、エンドユーザデータのリポジトリである。本発明は、エンドユーザが、少なくとも４つの形すなわち、データ派生、トリガードアクティブ化、データ制約、および判断ポイントでエンドユーザデータを「自動化」するロジックを定義することを可能にする。統一されたルールストレージプラットフォームが、図式化されたデータのテーマを取り巻く知識労働者アプリケーションのすべてを一緒に共通ストアにまとめる。これは、データの発見、編成、およびデータに対する反応に関する。豊かな照会および豊かなルールが、同一の硬貨の２つの側面である。豊かな照会およびビューは、エンドユーザに、データを見つける時の高められた制御を与える。豊かなルールは、データ編成の高められた自動化ならびにアクティブ／反応挙動のシステムへの作り込みの能力を提供する。これらは、現在のＰＣユーザが個々のアプリケーションに期待し始めている機能である。１つの特徴が、すべてのデータおよびアプリケーションにまたがってこれらの機能を標準化することである。
【００２７】
本発明のルールベースアーキテクチャは、図式化、データ共有、および情報管理を容易にする。データのユビキタス共通図式化が、エンドユーザ「プログラム」の開発の中心である。データ共有は、エンドユーザプログラムに共通し、自然である。到着する電子メールメッセージに優先順位を付けると決断した時に、その日のカレンダエントリ、人およびその人が参加するグループ、ユーザの現在位置（異なるアプリケーションによって作成された図式化されたデータのすべて）が、判断を行うために自然に一緒にプルされる。開示されるアーキテクチャは、アプリケーションにまたがるデータの共有を可能にする。本発明の重要な態様が、編成（フォルダ／リスト）および関係を介する情報オーバーロードを管理する能力である。ほとんどの情報オーバーロード情況で、問題は、豊かなフォルダおよびカテゴリ化を有することだけではなく、手作業でデータを編成／カテゴリ化する時間をも有することである。システムが、豊かな編成構造の使用を自動化する場合に、そのシステムは、エンドユーザとって真に価値のあるものになる。
【００２８】
ルール作成フレームワークは、ルールを作成する時およびそのルールを使用するアプリケーションを作成する時に使用される、アイテムおよび関係からなる。これらのアイテムおよび関係は、コンピュータが特定のイベントに応答して行うべきことを決定するために、ルールプラットフォームのルールエンジンによって使用される。
【００２９】
エンドユーザルールに基づいてアプリケーション挙動をカスタマイズするために、２つのことが行われる。プログラマが、ソフトウェアの機能を「ルールイネーブル」し、ユーザが、これらの機能用のルールを作成する。例えば、ルールイネーブルするオペレーティングシステム特徴が含まれ、その結果、ユーザが、フォルダおよび文書などのアイテムに対してルールを定義できるようになる。これは、エンドユーザがコンピュータに望む挙動を表す、エンドユーザによって記述されるルール「プログラム」をサポートする。さらに、この挙動は、ユーザが移動する時にユーザと共に移植されなければならない。開示されるルールアーキテクチャは、データとしてルールをモデリングするので、データを同期化し、移植することができる。
【００３０】
ルールは、複雑なロジックのための単一の宣言的プログラミング構造である。すべてのエンドユーザロジックコンポーネントが、ルールとして定義される。他のすべての構造が、単純なバイナリ代数演算子である。ルールは、特定のアイテム型の入力引数に対する、宣言的で副作用がない関数を定義する。ルールは、２つの部分すなわち、シグネチャ（入力アイテム型および出力型を定義する）および定義を有する。一般に、出力型は、単純なスカラ型、アイテム型、またはコレクション型とすることができる（結果のセットの期待を反映する）。
【００３１】
ルールは、単一の入力に作用するものとして論理的に表現されるが、評価中には、しばしば、実際の入力のセットに適用される。動作中の例として、Ｍｅｓｓａｇｅアイテム型に対して定義されたルールを検討されたい。Ｍｅｓｓａｇｅ型は、関係型Ｒｅｃｉｐｉｅｎｔのソースであり、そのターゲットは、Ｃｏｎｔａｃｔアイテム型である。これによって、メールメッセージの「Ｔｏ」フィールドの情報を取り込む。この例を説明するために、英語風の擬似言語を使用して、ルールを記述する。これが、実際のルール言語を表すと誤解してはならない。そうではなく、ルールは、ＡＰＩ構造を使用するコードで、意味のあるユーザフレンドリな記述を有するフレンドリなＵＩ操作を使用してエンドユーザによって表現される。
【００３２】
ルール定義は、０個以上のＩＦ−ＴＨＥＮステートメントの順序付きリストである。ルール内の各ＩＦ−ＴＨＥＮステートメントは、条件式（ＩＦ部分）と結果式リスト（ＴＨＥＮ部分）を有する。条件式は、Ｂｏｏｌｅａｎ式ツリーであり、その葉は、エンドユーザが推理できる基本条件演算子である。結果は、エンドユーザが推理できる定数または単純な式である式のリストである。
【００３３】
複数のＩＦ−ＴＨＥＮステートメントを有するルールのセマンティクスは、特定の入力アイテムの出力に関して定義される。入力アイテムに対して真と評価される条件を有するステートメントがない場合に、結果はＮＵＬＬである。条件が真と評価されるステートメントが正確に１つだけある場合に、出力は、そのステートメントの結果によって定義される。条件が真と評価されるステートメントが複数ある場合には、結果は、これらのすべてのステートメントの結果への衝突解決ポリシの適用に依存する。一般的な衝突解決ポリシは、ルール内のステートメントの順序に基づく、すなわち、最高の優先順位が勝つ。
【００３４】
ルール作成フレームワークは、アイテム型すなわち、判断ポイントアイテム、ルールアイテム、およびルールセットアタッチメントアイテム（ＲｕｌｅＳｅｔＡｔａｃｈｍｅｎｔまたはＲＳＡとも表す）を使用して、ルール作成をサポートする。アプリケーションのルールイネーブルされた特徴のそれぞれが、判断ポイントアイテムによって定義される。各ユーザは、特定の判断ポイントのルールを作成し、アプリケーションは、判断ポイントオブジェクトを使用して、ルールエンジンにデータをサブミットする。各条件／結果ステートメントが、Ｒｕｌｅステートメントアイテムである。ルールは、実行に関するロジックの単位である。アプリケーションも、ルールを作成することができる。アプリケーションは、出発点としてデフォルトルールを提供することができる。このデフォルトルールは、エンドユーザがルールを変更するか代替ルールを提供することを選択するまで、判断ポイントとして使用される。ルールは、ＲＳＡアイテムを介して判断ポイントに関連付けられる。このアタッチメントは、所与の入力に関してどのルールを実行すべきかを判定するために、ルールエンジンによって使用される。
【００３５】
他のデータコレクションと結合され／組み合わされる条件を定義することを可能にすることができる。さらに、他のルールで使用できる仮想コレクションを含むコンポーネント化されたロジックを指定することができる。
【００３６】
非同期挙動ルールに関して、結果は、ファイルシステム型に対するメソッド、任意のＣＬＲ型に対するメソッド、または任意のスタティックメソッドであるアクションを記述する。同期挙動ルールに関して、結果は、アプリケーション固有型の値のセット、例えば、ファイル名、ストリング、評価されるオブジェクト、色の列挙されたリストの１つのセットである。
【００３７】
ルールプラットフォームに、標準的なリッチルールユーザインターフェース（ＵＩ）が含まれる。従われる原理は、ルールとビュー／クエリの両方のための共通ＵＩがあり、オーサリングプロセス全体を単一の画面で行うことができ、テンプレートの均一な抽象化がサポートされ、値選択がリッチ型固有コントロール（例えば、データピッカ）をサポートでき、ＵＩを拡張可能とすることができる（新しいアイテム型が追加される時に、それらに対してルールをオーサリングし、その条件およびアクションを含めることを自動的に可能にすることができる）ことである。オペレーティングシステムルールに関して、ユーザは、ビジュアルブラウジングメタファを有するＵＩアクションを介して、判断ポイントにルールをアタッチする。しかし、他のアプリケーションが、ユーザのためにアタッチメントを作成することができる。というのは、アプリケーションが、ユーザのために判断ポイントを定義するからである。
【００３８】
図１を参照すると、本発明のルールアーキテクチャによるエンドユーザデータ自動化および管理を容易にするシステム１００が示されている。ルールアーキテクチャは、エンドユーザが、次の４つの形で「データを自動化する」ロジックを定義することを可能にする。第１に、データ派生は、内容ベースロジックを使用するシステムで他のアイテムから「仮想」コレクションおよびアイテムを定義するのを容易にする。例えば、Ｂｅｌｌｅｖｕｅに住所を有するＣｏｎｔａｃｔｓの全体的なセットのサブセットであるＰｅｏｐｌｅＷｈｏＬｉｖｅＩｎＢｅｌｌｅｖｕｅという名前の連絡先のグループを定義することである。第２に、副作用を有するロジックのトリガードアクティブ化は、コレクションおよびアイテムをトリガロジックに関連付けることによって、これらのコレクションおよびアイテムをアクティブにするのを容易にする。例えば、Ｓｐｅｃｉｆｉｃａｔｉｏｎｓコレクションに追加されるすべての新しい文書が、その作成者が電子メールによって通知される結果をもたらさなければならないことを宣言することによる。第３に、データ制約は、アイテムに制約ロジックを課すのを容易にする。例えば、Ｉｎｄｉｇｏフォルダのすべての電子メールが、件名に「Ｉｎｄｉｇｏ」を有するか、Ｉｎｄｉｇｏメーリングリストに送信されたものであることを要求することによる。最後に、データ駆動判断は、アプリケーションインターセプタポイントでのリッチアプリケーションカスタマイゼーションロジックのサポートを容易にする。例えば、メッセージの内容および宛先に基づいて、どの署名ファイルを進行中のメールメッセージに添付するかを指定することによる。
【００３９】
これをサポートして、システム１００に、データに関連するアイテムを追跡する監視コンポーネント１０２が含まれる。ルール評価コンポーネント１０４は、追跡されるアイテムに関連するメタデータを使用して、そのアイテムのサブセットの自動化されたハンドリングを提供する。このシステムは、さらに、内容ベースロジックを使用することによるシステムでの仮想コレクションおよびアイテムの定義を容易にする。このシステムに、さらに、トリガロジックの関数としてアイテムおよびアイテムのコレクションを動的にアクティブにセットする１つまたは複数のトリガコンポーネント１０６が含まれる。追加のコンポーネントに、アイテムに制約ロジックを課す制約コンポーネント１０６と、判断ポイントでアプリケーションカスタマイゼーションロジックをイネーブルするのをサポートする判断コンポーネント１０８が含まれる。判断コンポーネント１０８は、アプリケーションによって公開できる１つまたは複数の判断ポイントだけではなく、イベントまたは判断ポイントをサブミットするＡＰＩも表す。
【００４０】
図２を参照すると、本発明のルールアーキテクチャによる図式化の１つの方法論が示されている。説明を単純にするために、例えば流れ図の形で、本明細書で示される１つまたは複数の方法論が、一連の動作として図示され、説明されるが、本発明によれば、一部の動作を、本明細書で説明し、図示するものと異なる順序でおよび／または他の動作と同時に行うことができるので、本発明が、動作の順序によって制限されないことを理解し、了解されたい。例えば、当業者は、この方法論を、その代わりに、状態図でなど、一連の相互に関係する状態またはイベントとして表現できることを理解し、了解するであろう。さらに、示された動作のいずれかが、本発明による方法論の実施に必要ではない可能性がある。
【００４１】
図式化は、複数のアプリケーションがデータおよびロジックを認識し、相互作用することを可能にする周知の定義されたパターンへの、データおよびロジックの構造化と定義される。データのユビキタス共通図式化が、エンドユーザ「プログラム」の開発の中心である。少なくとも３つの「図式化」が、本発明によるエンドユーザデータ自動化を可能にする。２００で、エンドユーザデータ自動化を容易にするために、図式化のためにデータおよびロジックを受け取る。２０２で、データを図式化する。図式化された情報は、エンドユーザアプリケーションの基礎になるデータである（例えば、電子メール、人、グループ、および位置）。これによって、アプリケーションによるデータの一貫した解釈が可能になる。２０４で、ロジックビルディングブロックのためにイベントを図式化する。図式化された情報イベントは、アタッチロジックへのフックを提供するイベントである。これらのイベントは、高水準であり、エンドユーザに意味のある情報フローに結び付けられる。例えば、電子メールメッセージの到着が、そのようなイベントである。イベントは、アプリケーション内の同期インターセプタポイントまたはそれにロジックをバインドできる非同期イベントとすることができる。２０６で、ルールを介してデータ（または情報）およびイベントを処理するために、ロジックビルディングブロックを図式化する。エンドユーザは、通常は、訓練を受けた開発者ではないので、伝統的なプログラミング言語でプログラムすることを期待することは無理である。そうではなく、図式化されたロジックビルディングブロックを提供し、その結果、エンドユーザが、単純だが豊富な組合せでそれらを縫い合わせることによってプログラミングできるようにする。
【００４２】
図３を参照すると、本発明のルールアーキテクチャによるデータ派生の１つの方法論が示されている。３００で、処理のためにデータを受け取る。３０２で、ルールアーキテクチャの１つまたは複数のルールを適用して、内容ベースロジックを使用してシステム内の他のアイテムから「仮想」コレクションおよびアイテムを定義することによって、データを自動化する。例えば、仮想コレクションは、Ｃｉｔｙに住所を有するＣｏｎｔａｃｔｓの全体的なセットのサブセットであるＰｅｏｐｌｅＷｈｏＬｉｖｅＩｎＣｉｔｙと呼ばれる連絡先のグループを定義することによって作成することができる。
【００４３】
図４を参照すると、本発明のルールアーキテクチャによる副作用を有するロジックのトリガードアクティブ化の１つの方法論が示されている。４００で、処理のためにデータを受け取る。４０２で、トリガするイベントに対するアクティビティをトリガロジックに関連付けることによって、コレクションおよびアイテムをアクティブにする。例えば、Ｓｐｅｃｉｆｉｃａｔｉｏｎｓコレクションに追加されるすべての新しい文書が、その作成者が電子メールによって通知される結果をもたらさなければならないことを宣言する。
【００４４】
図５を参照すると、本発明のルールアーキテクチャによるデータ制約の１つの方法論が示されている。５００で、処理のためにデータを受け取る。５０２で、制約ロジックをアイテムに課す。Ｎａｍｅフォルダのすべての電子メールが、件名に「Ｎａｍｅ」を有するか、Ｎａｍｅメーリングリストに送信されたものであることを要求することが、データ制約の１つの例である。
【００４５】
図６を参照すると、本発明のルールアーキテクチャによる判断ポイントでのアプリケーションカスタマイゼーションの提供の１つの方法論が示されている。６００で、判断ポイントでの処理のためにデータを受け取る。リッチカスタマイゼーションロジックが、アプリケーションインターセプタ（または判断）ポイントで提供される。したがって、６０２で、判断ポイントにアタッチされたルールを処理する。メッセージの内容および宛先に基づいて、発信メールメッセージにどの署名ファイルを添付するかを指定することが、データ駆動判断ポイントの１つの例である。６０４で、アプリケーション判断を返す。
【００４６】
図７を参照すると、本発明のルールアーキテクチャのアイテム型およびその関係を示す図が示されている。入力スコープは、任意の型の任意のアイテムである。入力スコープは、ルール評価のスコープを特定のアイテムまたはフォルダに制限するためにオペレーティングシステムによって使用されるが、通常は、個々のアプリケーションによって使用されない。上のグラフィックの行のラベルは、アイテムの間の関係の名前を示す。ＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔアイテムは、ＤｅｃｉｓｉｏｎＰｏｉｎｔアイテムとＲｕｌｅアイテムの間の接続を表す。これらの接続は、物理的なストアされた「リンク」または計算された「共通値アソシエーション」のいずれかとしてモデリングすることができる。どちらの場合でも、機能は同一であり、このアイテムがそれのために作成されたＲｕｌｅからＤｅｃｉｓｉｏｎＰｏｉｎｔへの接続である。判断ポイントアイテムは、アプリケーションがルールプラットフォームを使用することを可能にする。ルールは、制約、条件、および結果を含むルールアイテムを記述する。ルールに、ルールステートメントが含まれる。ルールは、判断ポイントにアタッチされ、アプリケーションは、結果を返すために判断ポイントに入力を供給する。
【００４７】
図８を参照すると、本発明のルールアーキテクチャによる条件および結果処理を示す図が示されている。ルールプラットフォームは、エンドユーザルールロジックを定義し、実行するインフラストラクチャを提供する。ルールスキーマは、アイテム型に関連付けられた、パラメータ化された条件および結果を提供する。例えば、ＥｍａｉｌＭｅｓｓａｇｅアイテム型は、それに関連付けられた条件ＩｓＦｒｏｍ、ＩｓＴｏなどを有する。本発明によるエンドユーザプログラミングを容易にするために使用可能な、ルールプラットフォーム用のアイテム型８００の完全なセットが提供される。アイテム型８００は、アイテム型１：条件１／結果１、アイテム型２：条件２／結果２、．．．、アイテム型Ｎ：条件Ｎ／結果Ｎと表される。入力８０２として、より単純な条件のいくつかが、アイテム型から自動的に派生され、他の条件８０４は、開発者が明示的に指定することができる。ユーザは、アイテム型８００への引数値８０６を入力する。選択されたアイテム型８００のこれらの条件および結果が、エンドユーザロジックの出力「命令セット」８０８になる。ルールの条件および結果は、開発者が定義する条件および結果のインスタンスであり、引数値はエンドユーザによって指定される。各ルールは、アイテムのすべての共有機能、セキュリティ機能、および同期化機能と共に、アイテムとして永続する。
【００４８】
エンドユーザロジック「プログラム」である出力命令セット８０８は、ルールのセットであり、ルールは、ルールステートメントのセットである。ロジックの完全な単位に、１つまたは複数のルールが含まれる。各ルールは、オーサリングの単位である。ルールへの入力が、データアイテムであることに留意されたい。ルールは、特定のアイテム型のアイテムに関する宣言的ステートメントである。基本モデルに対する拡張として、非アイテムデータ（過渡データまたはＸＭＬ）を、ルール入力として提供することができる。ルールが適用されるアイテムは、ルールの展開に依存する。ルールは、展開可能なエンドユーザロジックの単位である。ルールは、それにアイテムスコープ（アイテム入力のソースまたは判断ポイント）をアタッチすることによって展開される。この関連は、ＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔとして取り込まれる。ルールおよびＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔ（ＲＳＡ）は、アイテムとすることができる（これは、前に説明したように、アイテムの間の名前付きの一般的な値関係とすることができる）。
【００４９】
アクティブルールの場合に、アイテムスコープは、アイテムコレクションである。ルールが、アプリケーションのインターセプトおよびカスタマイズに使用される時に、そのアプリケーションは、ルールが適用されるアイテムを供給する。
【００５０】
ルールは、エンドユーザカスタマイゼーション要求を集合として定義する。ルール内の各Ｒｕｌｅステートメントは、エンドユーザ意図の１つのステートメントに対応する。複数のルールを適用できる場合には、衝突レゾルバ（ｃｏｎｆｌｉｃｔ  ｒｅｓｏｌｖｅｒ）を、アクションを介して適用することができる。
【００５１】
図９Ａ〜Ｅを参照すると、本発明のルールアーキテクチャによるルールの代表的なフォーマットが示されている。エンドユーザの展望からは、Ｒｕｌｅ＝＝Ｖｉｅｗ＝＝Ｑｕｅｒｙである。ルールプラットフォームは、少なくとも、ルールが宣言的なＩＦ−ＴＨＥＮ式であり；ルールのデータモデルがデータモデルであり、その結果、アイテム型がルールに参加することができ；ルールが、データモデルに対してデータベースクエリプロセッサ内で評価されるという原理に従う。
【００５２】
ビューは、永続したクエリであるが、表現力においてクエリと変わらない。実際に、ビューおよびルールは、永続性の共通の要件を共有する。
【００５３】
この共通性の説明は、フィルタクエリについて意味をなすが、より豊かなセマンティクス（例えば集約）を使用する全部そろったＳＱＬクエリについては、明らかに真でない。そのようなクエリは、開発者がアプリケーションで使用するのに適切である。これらのクエリは、より豊かなルールシステムとの共通性を有する。
【００５４】
エンドユーザクエリは、通常は単純なフィルタである。興味深いことに、このクラスのフィルタクエリは、ＯＰａｔｈ言語によって提供されるものでもある。
【００５５】
図９Ａに、本発明によるルールの一般的なフォーマットを示す図である。ルールは、単に、ＯＮ（各データアイテム）／ＩＦ（条件が真）／ＴＨＥＮ（結論）という形のステートメントのセットである。ルールは、判断、真実、および一般に、様々な宣言的ステートメントを表すのに使用することができる。クエリは、ルールの結論が、結果内のアイテムを含めることに制限される、ルールの制限された形である（一般に、アイテムの除外も、可能な結論である）。クエリの結果の内容を定義する宣言的ステートメントは、ＯＮ（各データアイテム）ＩＦ（条件が真）ＴＨＥＮ（クエリ結果のアイテムを含める）である。実際に、これは、ＳＱＬ言語が当初にそれに基づいてモデリングされた、リレーショナル計算でクエリがモデリングされる形である。アクティブルールの場合に、ルールの結論は、実行される、副作用を有するアクションと解釈される。
【００５６】
ルールは制限的なので、異なる評価アルゴリズムが可能である。短待ち時間アルゴリズムが、クライアントマシンに適当であるが、高スループットアルゴリズムが、サーバに適当である。ルールは、アイテムとして永続され、セキュリティ、共有、および同期化の領域での標準化された挙動につながる。
【００５７】
ルールの条件は、入力アイテム型によって定義される基本的な述部を組み合わせるＢｏｏｌｅａｎ式である。アイテムプロパティに対する共通の比較条件ならびにスキーマ開発者によって定義される高度な条件メソッドがサポートされる。第１の原理は、エンドユーザルール内の条件およびエンドユーザクエリ内の条件が、表現力、表現のやさしさおよびメタファに関して同一でなければならないことである。第２の原理は、エンドユーザビューが、他のルール／クエリ／ビューとコンポーズ可能でなければならないことである。これによって、コンポーズ可能なビルディングブロックを介して豊かなエンドユーザロジックを作成できるようになる。関係にまたがり、データコレクションにまたがる条件を表すことが可能であることに留意されたい（データベース用語では「結合」であるが、平均的なユーザに意味のある様式化された形で提示される）。
【００５８】
ルールの結果は、単にデータである。ルールが、アプリケーションカスタマイゼーションに使用される時に、そのルールは、消費するアプリケーションによって解釈される必要がある。アクティブ化ルール（イベントによってトリガされた挙動に副作用があるアクションを提供する）の場合に、結果は、実行されるアクションに対応する。ルールプラットフォームは、これらのアクションが実行されるホスティングサービスを提供する。
【００５９】
ルールアイテムは、関係のセットを含む（例えば、ルールアイテムを「含む」）アイテムである。ルールの論理的挙動は、特定の型の単一の入力アイテムに対して定義される。ルールは、入力アイテムに適用される。
【００６０】
データベースにおけるプログラミング構造の主要な種類が、トリガ、ストアドプロシージャ（ｓｐｒｏｃ）、ビュー／クエリ、および制約である。同様に、本発明によるエンドユーザプログラミングは、アクティブルール（トリガ）、カスタマイゼーションルール（ｓｐｒｏｃ）、派生ルール（ビュー）、および制約ルール（制約）を有する。
【００６１】
図９Ｂに、本発明によるアクティブルールの一般的なルールフォーマットを示す。アクティブルールは、例えば、カメラからダウンロードされる写真の自動的な編成；着信電子メール、電話呼、およびＩＭの処理、フィルタリング、および転送；関連アラートに関するユーザへの通知；およびエンドユーザによって定義される単純なアドホック「ワークフロー」を含む、コンピュータがユーザの代わりにアクションを実行する必要があるすべてのシナリオで使用される。
【００６２】
アクティブロジックは、ＯＮ（アイテム）／ＩＦ（条件）／ＴＨＥＮ（アクション）の形のルールによって定義される。ＴＨＥＮ文節の結果は、ストレージシステムと共に使用可能な基本的な動詞のセット（例えば、ＭｏｖｅおよびＡｄｄ）またはストレージスキーマ開発者によって定義された動詞のセットから選択された実行可能アクションに対応する。高度な開発者は、エンドユーザルールの条件およびアクションを定義するために、特殊化されたスキーマまたはスキーマ拡張を定義することができる。
【００６３】
アクティブルールをアイテムスコープにアタッチできる２つの形がある。第１に、アクティブルールを、周期的セマンティクスを用いてアイテムコレクションにアタッチすることができる。ルールは、各アイテムに周期的に適用され、適当なアクション（衝突を解決した後に）が行われる。第２に、アクティブルールを、イベンティングセマンティクスを用いてアイテムコレクションにアタッチすることができる。アイテムコレクション内で変化が発生する時に、必ず、変化したアイテムに対してルールが実行される。
【００６４】
図９Ｃに、本発明によるアプリケーションカスタマイゼーションルールの一般的なルールフォーマットを示す。現在のアプリケーションの挙動は、非常にカスタマイズ可能ではない。通常、すべてのカスタマイゼーションが、単純なオプション設定に基づく。その代わりに、ルールは、現在のアプリケーションコンテキストおよびユーザコンテキストに基づいて、データ駆動ロジックを用いる様々なインターセプタポイントでエンドユーザがアプリケーションをカスタマイズすることを可能にする。カスタマイゼーションルールは、エンドユーザ制御の点を提供することを求めるすべてのアプリケーションによって使用することができる。これを考える１つの形は、アプリケーションのツール→オプションを介して設定可能なすべての値が、定数としてだけではなく、判断ロジックを介して定義可能でなければならないというものである。例えば、どの署名ファイルを発信メールメッセージに添付するかを判定するルール、アラートでユーザに割り込むかどうかを判定するルールなどである。
【００６５】
アプリケーションカスタマイゼーションルールは、ＯＮ（アイテム）／ＩＦ（条件）／ＴＨＥＮ（結果）という形である。アプリケーションは、入力としてアイテムまたはアイテムのセットを提供する。結果は、ルール評価の一部として実際に自動的に実行されるのではなく、アプリケーションが適当に解釈する、ルール実行の結果として単純に返される。
【００６６】
図９Ｄに、本発明によるデータ派生ルールの一般的なルールフォーマットを示す。エンドユーザは、コンテンツベースフィルタを使用することによって、アイテムのセットを定義するルールを定義することができる。これらを、派生アイテムセットと呼ぶ。オペレーティングシステムのビジュアルブラウザメタファは、密接に関連するアイデアを取り込むダイナミックセットという概念を有する。すべてのエンドユーザクエリおよびビューが、このカテゴリに含まれる。
【００６７】
派生ルールは、ＯＮ（アイテム）／ＩＦ（条件）／ＴＨＥＮ（含む／除外する）という形を有する。許容される結果が、「含む」と「除外する」だけであることに留意されたい。ルールは、アイテムスコープにアタッチすることによって展開される。結果の派生されたＩｔｅｍＳｅｔに、ルールによって「含まれる」、ソースセット内のアイテムが含まれる。効果的に、これらの派生ルールは、アイテムスコープに対するリッチフィルタを定義する。
【００６８】
派生ＩｔｅｍＳｅｔの例に、非ヌルの自宅の電話番号を有するＣｏｎｔａｃｔｓおよびビジネス連絡先としてマークされていないＣｏｎｔａｃｔｓとして定義される、ＭｙＦｒｉｅｎｄｓという名前の人のグループ；ＭｙＦｒｉｅｎｄｓに含まれる人からの、ＩｎＢｏｘにある電子メールとして定義される、ＩｎＢｏｘＭａｉｌＦｒｏｍＭｙＦｒｉｅｎｄｓという名前の電子メールのセットが含まれる。
【００６９】
派生アイテムセットの定義が、コンポーズ可能である、すなわち、ＩｎＢｏｘＭａｉｌＦｒｏｍＭｙＦｒｉｅｎｄｓが、ＭｙＦｒｉｅｎｄｓの定義を使用することに留意されたい。このコンポーズ可能性は、エンドユーザがモジュラー定義を作成するためにクリティカルである。派生アイテムセットのモジュラー定義は、他の種類のルールをより表現力のあるものにもする。例えば、ＩｎＢｏｘに対するアクティブルールは、送信者がＭｙＦｒｉｅｎｄｓに含まれる場合にそのメールを「パーソナル」としてマークしなければならないことを示すことができる。
【００７０】
図９Ｅに、本発明によるデータ制約ルールの一般的なルールフォーマットを示す。エンドユーザは、ＯＮ（アイテム）／ＩＦ（条件）／ＴＨＥＮ（許容する／許容しない）という形のルールを使用することによって、アイテムコレクションに対する制約を指定することもできる。制約ルールは、既存のアイテムコレクションにアタッチされ（これが、このルールのアイテムスコープである）、アイテムコレクションに対する変更（挿入／更新／削除）によってアクティブ化される。アクティブ化は、変更と同期する。失敗に対する複数の可能な挙動があり（ルール結果が「許容しない」の場合）：変更（通常はアイテムの追加）自体を失敗にすることができる。その代わりに、コレクションに追加されるアイテムを、制約に従うように変更することができる。
【００７１】
各ルールは、ルール入力の型、許容される条件、および許容されるルール結果を指定するルール制約に関連する。例えば、派生アイテムセットを定義するか、照会に使用されるルールは、その結果が入力アイテムの包含または除外のいずれかになるように制約することができる。エンドユーザは、ルール制約を扱わない。これは、アプリケーションおよび開発者の概念であり、エンドユーザが指定できるロジックを特定の判断のコンテキストで制約することである。ＲｕｌｅＣｏｎｓｔｒａｉｎｔ型は、これらの制約を記述するのに使用される。
【００７２】
制約ルールと派生ルールが非常に似ていることを観察することができる。しかし、相違は、制約ルールが、コレクションへのメンバシップに関する必要な条件を指定するだけであることである。これらは、コレクションにデータを与える形を指定しない（言い換えると、ルールロジックが適用されるアイテムの領域がない）。
【００７３】
エンドユーザプログラミング（ＥＵＰ）モデル
伝統的に、ファイルシステムに関する設計作業の多くは、「手動」対話の分野、例えば、コピーセマンティクス、ライフタイム管理などでのエンドユーザ要件の理解に基づくものであった。これらの要件は、コアファイルシステムのデータモデルおよびＡＰＩに取り込まれ、挿入されてきた。しかし、ファイルシステムデータとのエンドユーザ対話の完全な要件は、エンドユーザによってプログラムされるデータ操作を伴う、より豊かで動的な対話を伴うことによって、「手動」対話より幅広いものである。
【００７４】
ＥＵＰの設計は、要件の主要な駆動体としてのエンドユーザの思考に関連する４つの中心原理に基づく。
【００７５】
コンポジションロジック。複雑なロジックを、より単純な構造を有するより小さいコンポジション単位を使用して構成することができる。すべてのエンドユーザプログラムが、宣言的である。エンドユーザプログラムは、ロジックコンポーネントのコンポジションによって構成される。論理コンポーネントを一緒にすることができる形を定義するＥＵＰ代数がある。各ロジックコンポーネントは、エンドユーザが意味を了解するロジックのフラグメントである。ロジックコンポーネントが、クエリを定義するか複雑な動詞または制約を定義するのに使用されるのいずれであれ、ロジックコンポーネントは、共通のＩＦ−ＴＨＥＮルール構成を使用して定義される。共通の論理モデルのほかに、ロジックコンポーネントは、アプリケーションにまたがるルールロジックの共通のビジュアル表現も可能にする。
【００７６】
データとしてプログラムを管理する。すべてのＥＵＰプログラムおよびすべてのＥＵＰロジックコンポーネントは、ファイルシステムアイテムとして表現される。エンドユーザの観点から、エンドユーザが定義した複雑なアクションまたはフィルタは、エンドユーザが編集した文書と変わらない。共有、同期化、バックアップ、セキュリティなどの観点から、これはデータの１つである。有用な副作用は、ＥＵＰ概念と相互作用するＡＰＩ表面が、すべてのデータアイテムと相互作用する標準ＡＰＩ表面であることである。
【００７７】
エンドユーザ柔軟性。これは、エンドユーザに力および柔軟性を与えることに関するすべてである。例えば、エンドユーザは、新しいエンドユーザ型を定義し、既存の型を動的に変更し、クエリを定義し、永続させ、特定のアイテムに影響する「ビジネスロジック」を定義することなどができる。これらは、宣言的、代数的、およびルールベースである抽象化の適当なレベルで記述される。
【００７８】
アプリケーションにまたがる共通モデル。あるアプリケーションまたはユーザに提示されるビジュアルブラウジングメタファでエンドユーザが行う作業を、他のアプリケーションに持ち込むことができる。例えば、エンドユーザプロパティが、メタファ内でＤｏｃｕｍｅｎｔ型についてセットアップされている場合に、エンドユーザは、そのメタファの別の部分または別のファイルシステムアプリケーションで文書に対するクエリを定義する時に、そのプロパティを使用できることを期待することができる。
【００７９】
データのＥＵＰに対する５つの基本的な態様すなわち、データ型、ロジック、クエリおよびビュー、動詞および自動化、判断、ならびに制約がある。データ型に、型マッピングおよびプロパティマッピングが含まれる。型マッピングに、エンドユーザが見ることができ、それに関してエンドユーザが推理できるデータ型と、型をファイルシステムにマッピングする形が含まれる。プロパティマッピングに、ユーザがエンドユーザデータ型に関連して見るプロパティと、これらを基礎になるストレージ型にマッピングする形が含まれる。
【００８０】
ロジックに、クエリ、自動化、制約、およびアプリケーションカスタマイゼーションが含まれる。プログラミングモデルが、エンドユーザロジックを定義し、オーサリングモデルが、エンドユーザが複雑なロジックをどのように定義できるかを定義する。エンドユーザロジック永続性が提供され、管理は、エンドユーザロジックがどのように共有され、管理されるかと、ネーミング、共有、同期化などの機構を記述する。
【００８１】
クエリおよびビューは、例えばエンドユーザに提示される正しいフィルタリングおよび照会抽象化を記述する式モデルを提供する。挙動は、エンドユーザがアイテムをオートリストにまたはこれからドラッグする時に期待される挙動が何であるかを考慮する（例えば、オートリストがリストのように振る舞う）。プレゼンテーション抽象化に関して、エンドユーザへのオートリストのプレゼンテーションに関連する論理情報のセット（例えば、プロジェクションプロパティ、ソート順序、ページネーション）があり、ある物理的情報（ページ次元など）もある。
【００８２】
動詞および自動化は、エンドユーザ「動詞」が基礎になるデータモデルに関して何であるか、新しい複雑な条件動詞がエンドユーザによってどのように構成されるか、アイテムに対する動詞の適用をアイテムのセットに一緒にどのように適用できるか、より豊かな動詞、および動詞の適用をどのように自動化できるかを記述する。
【００８３】
判断は、アプリケーションカスタマイゼーション判断（エンドユーザカスタマイゼーションルールによって定義される）がどのようにモデリングされるかを記述する。
【００８４】
制約は、アイテム／アイテムセットの内容に対してエンドユーザがどのように制約を定義できるか、および実施可能なセマンティクスを記述する。
【００８５】
エンドユーザプログラミング（ＥＵＰ）代数に関する５つの基本的な項がある。
Ｐｒｏｐｅｒｔｙ（Ｔ）：これは、エンドユーザ型Ｔのプロパティを記述する。ユーザは、プロパティを使用して、フィルタおよびアクションを記述する。
Ｆｉｌｔｅｒ（Ｔ）：これは、型Ｔのアイテムに対してフィルタとして使用することができるＢｏｏｌｅａｎ関数を定義する。これは、戻り型がＢｏｏｌｅａｎであるルールである。
Ｅｖｅｎｔ（Ｔ）：これは、重要なオカレンスを定義する。これは、通常は、型がＴであるデータアイテム（イベントデータ）に関連する。
Ａｃｔｉｏｎ（Ｔ）：これは、アイテム型Ｔの副作用を有するメソッドであり、通常は他のパラメータを必要とする。
Ｓｅｔ（Ｔ）：これは、型Ｔのアイテムのセットである。
【００８６】
これらの項のそれぞれのインスタンスは、システム内で開発者によって定義されたアイテムスキーマから派生される。Ｓｅｔ（Ｔ）の場合に、この項のインスタンスは、ファイルシステム内のコレクションのいずれかである。しかし、これらの項のそれぞれのインスタンスは、エンドユーザが、単純な代数コンストラクタまたはルールを介して構成することもできる。次の基本的な項を、ルールを使用することによって構成することができる。
Ｐｒｏｐｅｒｔｙ（Ｔ）：入力アイテム型がＴであり、出力型がＯであるルールが、型Ｔに対する型Ｏのプロパティを定義する。
Ｆｉｌｔｅｒ（Ｔ）：入力アイテム型がＴであり、出力型がＢｏｏｌｅａｎであるルールが、型Ｔのアイテムに対するフィルタを定義する。
Ａｃｔｉｏｎ（Ｔ）：入力アイテム型がＴであり、出力型がルールが、型Ｔのアイテムに対するアクションを定義する。
【００８７】
各ルール内で、＜プロパティ＞＜比較演算子＞＜式＞、＜既存フィルタ＞、ＡＮＹ／ＥＶＥＲＹ＜関係ターゲット＞ＭＡＴＣＨＥＳ＜フィルタ＞、およびＡＮＹ／ＥＶＥＲＹ＜関係ターゲット＞ＩＮ＜セット＞を含む様々な条件を使用することができる。これらの条件は、Ｒｕｌｅ内で発生し得る異なる種類のコンポジションを示す。これに、セット内のアイテムのカウントである集約も含まれる。次の項は、単純なバイナリ代数演算を使用して構成することができる：Ｅｖｅｎｔ（Ｔ）＝Ｅｖｅｎｔ（Ｔ）＋Ｆｉｌｔｅｒ（Ｔ）、ただし、派生されるイベントは、例えばＮｅｗＩｎｔｅｒｅｓｔｉｎｇＩｔｅｍ（Ｄｏｃ）＝ＮｅｗＩｔｅｍ（Ｄｏｃ）＋ＩｓＩｎｔｅｒｅｓｔｉｎｇ（Ｄｏｃ）など、別のイベントのイベントデータへのフィルタの適用によって定義される；Ｆｉｌｔｅｒ（Ｔ）＝Ｆｉｌｔｅｒ１（Ｔ＿ＳｕｂＴｙｐｅ１）Ｕｎｉｏｎ  Ｆｉｌｔｅｒ２（Ｔ＿ＳｕｂＴｙｐｅ２）；Ｓｅｔ（Ｔ）＝Ｓｅｔ１（Ｔ）＋Ｆｉｌｔｅｒ（Ｔ）、ただし、派生されるセットは、別のセットのアイテムのそれぞれへのフィルタの適用によって定義される；派生されるセットメンバは、フィルタが真と評価されるアイテムである；およびＳｅｔ（Ｔ）＝Ｓｅｔ１（Ｔ）Ｕｎｉｏｎ  Ｓｅｔ２（Ｔ）。
【００８８】
個々のＥＵＰロジックコンポーネントは、アプリケーション内で直接に評価することができる。これは、アプリケーションカスタマイゼーションに使用される手法である（例えば、Ｏｕｔｌｏｏｋなどのアプリケーションが、エンドユーザロジックを介するアプリケーションの挙動のエンドユーザによるカスタマイズを可能にするために）。ＥＵＰの中心要素は、環境ビジュアルブラウジングメタファを介して表面に出され、次の３種類のプログラムを含む。
派生セット：派生セット（代数項として前に説明した）自体は、完全なエンドユーザプログラムである。これがオープンされる時に、セット定義のロジックが実行され、その結果が、通常は表示される。次の代数演算は、派生セットについてもサポートされる、Ｓｅｔ（Ｔ）＝Ｓｅｔ１（Ｔ）Ｕｎｉｏｎ  Ｓｅｔ２（Ｔ）。
バッチ：バッチ＝Ｓｅｔ（Ｔ）＋Ａｃｔｉｏｎ（Ｔ）。バッチは、実行されるセット指向タスクを定義する。バッチのセマンティクスは、セット内の各アイテムに対してアクションを実行することである。バッチを、手作業で実行するか、実行のためにスケジューリングすることができる。
エージェント：エージェント＝Ｅｖｅｎｔ（Ｔ）＋Ａｃｔｉｏｎ（Ｔ）。エージェントは、イベントが発生する時に実行されるアクションを定義する。
【００８９】
３種類のＥＵＰプログラムのすべてが、ファイルシステムアイテムならびにロジックコンポーネントとして定義される。
【００９０】
さらなる代数演算を含めることができる。例えば、派生されるセットを定義するために、様々な集合組合せ演算（交わり、集合の差など）を考慮することが実行可能である。
【００９１】
ＲｕｌｅＬｏｇｉｃアイテムは、エンドユーザロジックの単位を定義する。ＱｕｅｒｙＦｉｌｔｅｒ、複雑な動詞、複雑なイベント、および計算されたプロパティが、ＲｕｌｅＬｏｇｉｃのインスタンスである。論理的に、ＲｕｌｅＬｏｇｉｃアイテムは、入力アイテムに対するユーザ定義関数の定義を取り込む。すべてのＲｕｌｅＬｏｇｉｃアイテムに、ＲｕｌｅＣｏｎｓｔｒａｉｎｔが含まれ、このＲｕｌｅＣｏｎｓｔｒａｉｎｔは、関数の入力アイテム型および出力型を定義する。０個以上のＩＦ−ＴＨＥＮステートメントがある。各ステートメントは、Ｃｏｎｄｉｔｉｏｎ（ステートメントのＩＦ部分に対応する）およびＲｅｓｕｌｔ（ＴＨＥＮ部分に対応する）を有する。Ｃｏｎｄｉｔｉｏｎは、ネストされた要素のＢｏｏｌｅａｎ式ツリーであり、このツリーの葉に、ＬｅａｆＣｏｎｄｉｔｉｏｎ要素がある。Ｒｅｓｕｌｔは、０個以上のＲｅｓｕｌｔＥｌｅｍｅｎｔｓのネストされた要素コレクションであり、ＲｅｓｕｌｔＥｌｅｍｅｎｔｓのそれぞれが、名前とパラメータ値のセットとを有する。ＱｕｅｒｙＦｉｌｔｅｒの場合に、ステートメントのＲｅｓｕｌｔは、名前ＴｒｕｅまたはＦａｌｓｅを有し、パラメータを有しない単一のＲｅｓｕｌｔＥｌｅｍｅｎｔｓである。
【００９２】
ＲｕｌｅＬｏｇｉｃ定義（したがってＱｕｅｒｙＦｉｌｔｅｒも）のセマンティクスを、本明細書で短く説明する。ＱｕｅｒｙＦｉｌｔｅｒがステートメントを有しない場合に、出力はＮＵＬＬである。ＱｕｅｒｙＦｉｌｔｅｒが１つのステートメントを有する場合に、出力は、Ｃｏｎｄｉｔｉｏｎが真と評価され、ＲｅｓｕｌｔがＴｒｕｅである場合に真である。出力は、Ｃｏｎｄｉｔｉｏｎが真と評価され、ＲｅｓｕｌｔがＦａｌｓｅである場合に偽である。それ以外の場合に、出力はＮＵＬＬである。ＱｕｅｒｙＦｉｌｔｅｒが複数のステートメントを有する場合に、出力は、そのＣｏｎｄｉｔｉｏｎが真と評価されるステートメントのＲｅｓｕｌｔに対する総計関数を使用して計算される。最も一般的な総計関数は、ステートメント順序に基づくものである（ネストされたｉｆ−ｔｈｅｎ−ｅｌｓｅまたはｓｗｉｔｃｈステートメントのセマンティクスを提供する。
【００９３】
図１０を参照すると、本発明のルールアーキテクチャによる入力アイテムのコレクションにルールをアタッチすることによるルールの適用の１つの方法論が示されている。用語「コレクション」は、アイテム参照のすべてのセットを指す（シェル用語ではセットと呼ばれ、ルール用語では関係のマルチセットと呼ばれる）。１０００で、入力アイテムスコープを提供するアイテムコレクションを受け取る。１００２で、入力アイテムスコープを提供するアイテムコレクションにルールをアタッチすることができる。１００４で、ルールを呼び出す。１００６で、呼び出された時に、アイテムスコープのアイテムのそれぞれにルールが適用される。
【００９４】
図１１を参照すると、本発明のルールアーキテクチャによる判断ポイントにアタッチすることによるルールの適用のもう１つの方法論が示されている。１１００で、判断ポイントを公開する。１１０２で、判断ポイントにルールをアタッチする。ルールは、ルールによる評価のためにアイテムを供給するのに使用される判断ポイントにアタッチすることができる。
【００９５】
図１２を参照すると、本発明のルールアーキテクチャによるルールを直接に呼び出すことによるルールの適用のもう１つの方法論が示されている。１２００で、処理のために入力アイテムを受け取る。１２０２で、入力を指定するパラメータを用いて、ルールを直接に呼び出す。
【００９６】
図１３を参照すると、本発明のルールアーキテクチャによるルールの適用のもう１つの方法論が示されている。１３００で、処理のために入力アイテムスコープを受け取る。１３０２で、入力アイテムスコープで変化するアイテムにルールを適用する。この最後の事例は、アクティブ挙動（時々、イベンティング機能と呼ばれる）を提供するためのルールの一般的な使用をモデリングしたものである。ルールのこの使用では、入力アイテムが、「イベントによって送出され」、ルール評価の結果が、「アクション」を実行させることができる。新規のルールプラットフォームが、ルールシステムの上のレイヤとして、このアクティブイベンティング機能を提供する。
【００９７】
図１４を参照すると、本発明によるルール衝突解決の１つの方法論が示されている。デフォルトで、エンドユーザロジックの挙動は、個々のルールの累積的挙動である。しかし、多くの場合に、ルールが「衝突する」相互作用を有することができる。１４００で、処理のために複数のルールを含むユーザ定義ロジックを受け取る。少数の異なる衝突解決ポリシがサポートされる。例えば、１４０２で、ルールのエンドユーザルール優先順位付けを容易にする解決コンポーネントによって、ルール衝突を解決することができる。１４０４で、解決コンポーネントの代替メソッドが、開発者定義の解決ポリシ（例えば、カスタム集約）によってルール衝突を解決できることをもたらす。
【００９８】
ルール作成フレームワークは、ルール作成時およびルールを使用するアプリケーションの作成時に使用されるアイテムおよび関係からなる。これらのアイテムおよび関係は、特定のイベントに応答してコンピュータが行わなければならないことを判定するために、ルールプラットフォームのルールエンジンによって使用される。エンドユーザルールに基づいてアプリケーション挙動をカスタマイズするために、２つのことが行われる：プログラマが、ソフトウェアの機能を「ルールイネーブル」し、エンドユーザが、これらの機能用のルールを作成する。ルールイネーブルは、ユーザがルールにコンポーズするためのアプリケーション定義型またはＯＯＴＢ（アウトオブザボックス、すぐに使える）型に関連するＥＵＰコンポーネントを定義することを意味する。イネーブルは、ルールをアタッチできる判断ポイントを作成することも意味する。例えば、ルールイネーブルするオペレーティングシステム特徴が含まれ、その結果、ユーザが、フォルダおよび文書などのアイテムに対する変更に関するルールを定義することができるようになる。
【００９９】
ルールＡＰＩは、ルール入力をルール評価エンジンに導入し、エンドユーザルールを維持し、条件、アクション、バインディングなどを含むルールアーキテクチャの様々な部分を登録し、反映するのに使用される。ルールＡＰＩは、３つの例外（ルール入力、ルール入力コレクション、およびルール例外型）を有するルール型によって定義される部分クラスを完成させるヘルパメソッドとして実装される。これは、ルールに関するＡＰＩが、ルール型に対するＡＰＩであることを意味する。本発明のルールＡＰＩは、次を提供する。
【０１００】
Ｑｕｅｒｙ型から分離されたＡｐｐＣｕｓｔｏｍｉｚａｔｉｏｎ／Ａｃｔｉｖｅ  Ｒｕｌｅｓ型。分離によって、Ｑｕｅｒｙ関連型とＡｐｐＣｕｓｔｏｍｉｚａｔｉｏｎ型で異なるヘルパメソッドを構成できるようになる。これは、開発者の展望からの単純化でもある；アプリケーション内でのアプリケーションカスタマイゼーションにルールエンジンを使用することだけに関心を持つ開発者は、これらのＡＰＩを学習するだけでよい。
【０１０１】
組み合わされたＲｕｌｅ、Ｒｕｌｅｓ概念。Ｒｕｌｅｓは、制約情報（入力型および出力型）と、１つまたは複数のＬｏｇｉｃＳｔａｔｅｍｅｎｔからなる。各ＬｏｇｉｃＳｔａｔｅｍｅｎｔは、Ｃｏｎｄｉｔｉｏｎツリーおよび１つまたは複数の結果からなる。
【０１０２】
ＬｏｇｉｃＲｅｓｕｌｔ型ファミリ（将来の拡張用）。ＬｏｇｉｃＲｅｓｕｌｔは、型継承をもたらす基本型である。サポートされるのは、２つの結果型、すなわち、エンコードされたメソッド呼出し（ＦｕｎｃｔｉｏｎＩｎｆｏ）を含む既存の「Ａｃｔｉｏｎ」、ならびにＢｏｏｌｅａｎ戻り型（主にＱｕｅｒｙＦｉｌｔｅｒｓ／ＡｕｔｏＬｉｓｔｓで使用される）である。もう１つの実施形態では、スカラおよびＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）結果を含むようにこれを拡張することができる。
【０１０３】
ＥＵＰアイテムの間の値ベースの接続。これは、アイテムの間の明示的な関係／リンクを主張するのではない、アイテムを関係付ける追加の形である。ルールＡＰＩは、ルールアタッチメントのエンコードなどにＩｔｅｍＩｄを使用する。関連付けの概念、ある種類の宣言された型ベースの関係は、この機構と共に使用される。
【０１０４】
ルールＡＰＩ（ＥＵＰコンポーネントを指すもう１つの形）は、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｕｌｅｓ名前空間内の型からなる。ルールＡＰＩは、新しいイベントを導入する手段（ＲｕｌｅＩｎｐｕｔ、ＲｕｌｅＩｎｐｕｔＣｏｌｌｅｃｔｉｏｎ）を提供する。少数の例外があるが、これらの型は、以前にエミュレートされたＥＵＰコンポーネントおよびプログラムである。これらの型は、図式化された型であり、これは、これらが、標準的なストア動作ＡＰＩを使用してインスタンス化され、永続され、発見されることを意味する。型は、ユーザルール（ＲｕｌｅＬｏｇｉｃから派生する型）を作成し、維持する手段を提供する。これらのルールは、アクティブルール、アプリケーションカスタマイゼーション用のルール、または構造化クエリルールとすることができる。
【０１０５】
図１５を参照すると、本発明のルールアーキテクチャによるアイテム型および関連する関係が示されている。ルールプラットフォームによって公開されるパブリックＡＰＩのほとんどは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｒｕｌｅｓスキーマで宣言された型からなる。ルールスキーマは、ＥＵＰコンポーネントアイテム型を定義する。これらは、ユーザの代わりにルールロジックをインスタンス化するのに使用され、アプリケーションが、ルールロジックをアタッチできる判断ポイントを宣言し、ルール評価の結果を保持し、通信することを可能にする。
【０１０６】
ＲｕｌｅＬｏｇｉｃ。ユーザルールロジックを保持するすべてのアイテムの基本型。これには、すべてのルールに共通する基本的な「形状」が含まれる。
派生：（ＯＳファイルシステム）．ｉｔｅｍから
この型に追加されたプロパティ：
・  Ｃｏｎｓｔｒａｉｎｔ：このルールのＬｏｇｉｃＣｏｎｓｔｒａｉｎｔ。
・  Ｓｔａｔｅｍｅｎｔｓ：ＬｏｇｉｃＳｔａｔｅｍｅｎｔのマルチセット。各ルールに、１つまたは複数のステートメント（条件／アクション対）が含まれる。条件が評価され、真である場合に、アクションが結果として返される。マルチセット内の順序付けは、ステートメントの間の優先順位付けを暗示し、Ｓｔａｔｅｍｅｎｔｓ［０］が最高の優先順位を有する。順序付きマルチセットを実装することもできる。ステートメントを有しないＲｕｌｅＬｏｇｉｃアイテムは、不正とみなされる。一実施形態で、ビジネスロジックが存在する時に、ランタイム例外を送出することができる。
・  Ｅｎａｂｌｅｄ：このロジックがイネーブルまたはディスエーブルされていることをマークするＢｏｏｌｅａｎ（デフォルト：真）
この型に追加されたメソッド：なし。
【０１０７】
ＱｕｅｒｙＦｉｌｔｅｒ。ＱｕｅｒｙＦｉｌｔｅｒは、ユーザによってオーサリングされたフィルタリングロジックを表す。ＱｕｅｒｙＦｉｌｔｅｒのステートメントは、Ｂｏｏｌｅａｎ出力型を指定するＬｏｇｉｃＣｏｎｓｔｒａｉｎｔを有する。
派生：ＲｕｌｅＬｏｇｉｃから
この型に追加されたプロパティ：なし。
この型に追加されたメソッド：
・  ＱｕｅｒｙＦｉｌｔｅｒ（Ｔｙｐｅ  ｉｎｐｕｔＩｔｅｍＴｙｐｅ）：入力アイテム型をセットできるようにするコンストラクタ。Ｂｏｏｌｅａｎの結果型が、ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔでセットされる。
・  ＱｕｅｒｙＦｉｌｔｅｒ（Ｔｙｐｅ  ｉｎｐｕｔＩｔｅｍＴｙｐｅ，ＬｏｇｉｃＳｔａｔｍｅｎｔ  ｌ）：入力型をセットし（上と同様）、単一のＬｏｇｉｃＳｔａｔｅｍｅｎｔを追加するコンストラクタ。
・  Ｃｏｌｌｅｃｔｉｏｎ  Ｅｖａｌｕａｔｅ（ＣｏｌｌｅｃｔｉｏｎＳｃｏｐｅ  ｃｖ）：入力コレクションを与えられて、クエリフィルタを評価する。ＩｔｅｍＩｄのコレクションとして結果を返す。
・  Ｃｏｌｌｅｃｔｉｏｎ  Ｅｖａｌｕａｔｅ（ＡｕｔｏＬｉｓｔ  ａ）：入力コレクションとしてＡｕｔｏＬｉｓｔを与えられて、クエリフィルタを評価する。
・  Ｂｏｏｌｅａｎ  Ｅｖａｌｕａｔｅ（Ｉｔｅｍ  ｉ）：このＱｕｅｒｙＦｉｌｔｅｒ内で保持されるＬｏｇｉｃＳｔａｔｅｍｅｎｔに対して単一のアイテムを評価し、最終的な結果を返す。
【０１０８】
ＡｕｔｏＬｉｓｔ。ＡｕｔｏＬｉｓｔは、ＡｕｔｏＬｉｓｔのウィンドウズ（登録商標）ブラウジングメタファ概念を表す。これは、ＱｕｅｒｙＦｉｌｔｅｒ＋ＩｎｐｕｔＳｃｏｐｅを参照し、ＩｔｅｍＳｅａｒｃｈｅｒを介して返される結果を用いて評価することができる。
この型に追加されたプロパティ：
・  ＩｎｐｕｔＳｃｏｐｅｓ：ＩｎｐｕｔＳｃｏｐｅのマルチセット。ＡｕｔｏＬｉｓｔは１つまたは複数を有する。
・  評価される時にこのフィルタが適用される入力スコープ。０個の入力スコープを有するＡｕｔｏＬｉｓｔは、不正である。ビジネスロジックが存在する時に、ランタイム例外を送出することができる。
・  ＱｕｅｒｙＦｉｌｔｅｒｓ：ＱｕｅｒｙＦｉｌｔｅｒアイテムのＩｔｅｍＩｄのマルチセット。
・  このＡｕｔｏＬｉｓｔを評価する時に使用されるロジック定義を含む。
この型に追加されたメソッド：
・  ＡｕｔｏＬｉｓｔ（Ｔｙｐｅ  ｉｎｐｕｔＩｔｅｍＴｙｐｅ，ＩｎｐｕｔＳｃｏｐｅ  ｉｎｐｕｔＳｃｏｐｅ）：入力アイテム型ならびに入力スコープをセットできるようにするコンストラクタ。Ｂｏｏｌｅａｎの戻り型が、ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔでセットされる。
・  ＡｕｔｏＬｉｓｔ（Type inputItemType, InputScope inputScope, QueryFilter）：入力アイテム型と１つの入力スコープをセットし、単一のＱｕｅｒｙＦｉｌｔｅｒへの参照を追加するコンストラクタ
・  ＩｔｅｍＳｅａｒｃｈｅｒ  ＧｅｔＩｔｅｍＳｅａｒｃｈｅｒ（）：このＡｕｔｏＬｉｓｔの評価の結果に対するＩｔｅｍＳｅａｒｃｈｅｒを返す。
・  Ｉｎｔｅｒｎａｌ  ｓｔｒｉｎｇ  ＧｅｔＶｉｅｗＮａｍｅ（）：このＡｕｔｏＬｉｓｔをバッキングする生成されたビューの名前を返す。ＩｔｅｍＳｅａｒｃｈｅｒ統合に使用される。
【０１０９】
ＡｐｐＲｕｌｅ。ＡｐｐＲｕｌｅｓは、アプリケーションカスタマイゼーションシナリオで使用される。
派生：ＲｕｌｅＬｏｇｉｃから
この型に追加されたプロパティ：
・  ＤｅｃｉｓｉｏｎＰｏｉｎｔ：このＡｐｐＲｕｌｅがアタッチされる判断ポイントのＩｔｅｍＩｄ。
この型に追加されたメソッド：
・  ＡｐｐＲｕｌｅ（ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔ  ｌｃ）：ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔをセットできるようにするコンストラクタ。
・  ＡｐｐＲｕｌｅ（ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔ  ｌｃ，ＬｏｇｉｃＳｔａｔｅｍｅｎｔ  ｌ）：ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔをセットでき、単一のＬｏｇｉｃＳｔａｔｅｍｅｎｔを追加できるようにするコンストラクタ。
・  ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔｓ  Ｅｖａｌｕａｔｅ（Ｉｔｅｍ  ｉｎｐｕｔＩｔｅｍ）：所与の入力アイテムに関してこのＡｐｐＲｕｌｅを評価し、生成された結果を返す。
・  ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔｓ  Ｅｖａｌｕａｔｅ（ＣｏｌｌｅｃｔｉｏｎＶａｌｕｅ  ｃ）：指定されたコレクション内のアイテムのそれぞれについてこのＡｐｐＲｕｌｅを評価し、生成された結果を返す。
【０１１０】
ＳｃｏｐｅｄＡｐｐＲｕｌｅ。ＳｃｏｐｅｄＡｐｐＲｕｌｅは、主に、ルールロジックを適用しなければならない入力スコープを追加するために、アクティブルールシナリオで使用される。あるアプリケーションカスタマイゼーションシナリオが、ファイルシステム内の位置とのロジックの関連付けを要求することが可能である。これらのシナリオは、それ自体の判断ポイントと共にこれらのアイテムを利用することができる。
派生：ＡｐｐＲｕｌｅから
この型に追加されたプロパティ：
・  ＩｎｐｕｔＳｃｏｐｅｓ：ＩｎｐｕｔＳｃｏｐｅのマルチセット（下を参照されたい）。ＳｃｏｐｅｄＡｐｐＲｕｌｅｓは、そのロジックが適用される１つまたは複数の入力スコープを有する。０個の入力スコープを有するＳｃｏｐｅｄＡｐｐＲｕｌｅｓは、不正である。ビジネスロジックが存在する時に、ランタイム例外を送出することができる。
この型に追加されたメソッド：
・  ＳｃｏｐｅｄＡｐｐＲｕｌｅ（ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔ  ｌｃ，ＩｎｐｕｔＳｃｏｐｅ  ｉｎｐｕｔＳｃｏｐｅ）：ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔおよび単一の入力スコープをセットできるようにするコンストラクタ。
・  ＳｃｏｐｅｄＡｐｐＲｕｌｅ（LogicConstraint lc, InputScope inputScope, LogicStatement l）：ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔおよび単一の入力スコープをセットできるようにし、単一のＬｏｇｉｃＳｔａｔｅｍｅｎｔを追加できるようにするコンストラクタ。
【０１１１】
ＤｅｃｉｓｉｏｎＰｏｉｎｔ。ＤｅｃｉｓｉｏｎＰｏｉｎｔは、アプリケーションがルールエンジンに入力をサブミットする時と場合、およびアプリケーションが受け取ると期待する結果の種類を記述するために、アプリケーションによって作成される。ＤｅｃｉｓｉｏｎＰｏｉｎｔは、アプリケーションカスタマイゼーションシナリオで、アプリケーションがそれを介してルールエンジンに入力をサブミットできる機構である。
派生：（ＯＳファイルシステム）．ｉｔｅｍから
この型のプロパティ：
・  ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ：ＤｅｃｉｓｉｏｎＰｏｉｎｔを作成したアプリケーションまたはスキーマの名前。これは、例えば、所与のアプリケーションのすべてのＤｅｃｉｓｉｏｎＰｏｉｎｔを示すために、ＵＩ（ユーザインターフェース）アプリケーションによって使用することができる。
・  ＳｃｏｐｅＲｅｑｕｉｒｅｄ：真の時に、ここにアタッチされるすべてのＲｕｌｅＬｏｇｉｃが、入力ソースを定義されていなければならない（ＳｃｏｐｅｄＡｐｐＲｕｌｅ）。
・  Ｃｏｎｓｔｒａｉｎｔ：このＤｅｃｉｓｉｏｎＰｏｉｎｔについて作成されたルールに対する制約を記述するＬｏｇｉｃＣｏｎｓｔｒａｉｎｔ（下を参照されたい）。この制約は、アプリケーションがこのＤｅｃｉｓｉｏｎＰｏｉｎｔに達した時にアプリケーションがサブミットする入力の種類（ＯＳファイルシステム型ｉｄ）ならびにアプリケーションが期待する出力の種類を記述する。
この型に追加されたメソッド：
・  ＤｅｃｉｓｉｏｎＰｏｉｎｔ（string ApplicationName, LogicConstraint c, bool scopeRequired）：すべてのプロパティをセットできるようにするコンストラクタ。
・  ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔｓ  Ｓｕｂｍｉｔ（ＲｕｌｅＩｎｐｕｔ  ｒ）：所与のＲｕｌｅＩｎｐｕｔをサブミットし、その処理に関連するＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔを取り出す。
・  ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔｓ  Ｓｕｂｍｉｔ（ＲｕｌｅＩｎｐｕｔＣｏｌｌｅｃｔｉｏｎ  ｒ）：所与のＲｕｌｅＩｎｐｕｔＣｏｌｌｅｃｔｉｏｎをサブミットする。
【０１１２】
ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔｓ。サブミットされたＲｕｌｅＩｎｐｕｔのそれぞれが、単一のＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔｓアイテムの作成を引き起こす。このアイテムには、存在する場合に、サブミットされたデータに基づくルール評価の結果が含まれる。この新たに作成されるアイテムのｉｔｅｍｉｄは、サブミットしたアプリケーションに返される。次に、このアプリケーションが、アイテムデータを読み取って、行うべきアクションを判定することができる。
派生：（ＯＳファイルシステム）．ｉｔｅｍ
この型に追加されたプロパティ：
・  Ｒｅｓｕｌｔｓ：それぞれに単一のルール結果（行うべきアクション）が含まれる、ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔのマルチセット。
この型に追加されたメソッド：なし。
【０１１３】
図１６Ａ〜Ｈに、本発明のルールアーキテクチャに従って使用されるネストされた要素型を示す。
【０１１４】
図１６Ａに、本発明のＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔネステッド型を示す。ＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔは、単一のルール結果を表す（行うべきＡｃｔｉｏｎＲｅｓｕｌｔまたは返すべき他の種類のＲｅｓｕｌｔ）。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅから
この型に追加されたプロパティ：
・  Ｒｅｓｕｌｔ：ルールから返される結果を指定するＬｏｇｉｃＲｅｓｕｌｔ。
・  ＩｎｐｕｔＩｔｅｍＩｄ：このＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔを生成させた入力アイテムのＩｔｅｍＩｄ。
・  ＲｕｌｅＩｔｅｍＩｄ：このＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔを生成させたＲｕｌｅＬｏｇｉｃアイテムのＩｔｅｍＩｄ。
・  Ｓｔａｔｅｍｅｎｔ：このＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔを生成させた、ロジックアイテム内のＳｔａｔｅｍｅｎｔを指定する整数。
この型に追加されたメソッド：
・  ｖｏｉｄ  Ｅｘｅｃｕｔｅ（ＩｔｅｍＣｏｎｔｅｘｔ  ｉｃ）：ヘルパメソッド。ＲｅｓｕｌｔプロパティにＡｃｔｉｏｎＲｅｓｕｌｔが含まれる場合に、その中で指定されるこのメソッドを呼び出す。これがＩｔｅｍＣｏｎｔｅｘｔ．Ｕｐｄａｔｅ（）を呼び出すのではなく、呼出し元がそれを呼び出す。ＲｅｓｕｌｔがＡｃｔｉｏｎＲｅｓｕｌｔでない場合に、このメソッドは、ＲｕｌｅＥｘｃｅｐｔｉｏｎを送出しなければならない。
【０１１５】
パラメータ置換：ＲｅｓｕｌｔにＡｃｔｉｏｎＲｅｓｕｌｔが含まれる場合に、そのＡｃｔｉｏｎＲｅｓｕｌｔのＡｒｇｕｍｅｎｔｓは、ＬｏｇｉｃＳｔａｔｅｍｅｎｔによって指定される後処理されたＡｒｇｕｍｅｎｔｓを表すＣｏｎｓｔａｎｔＶａｌｕｅになる。
【０１１６】
図１６Ｂに、本発明のＩｎｐｕｔＳｃｏｐｅネステッド型およびその派生物を示す。図１５のＡｕｔｏＬｉｓｔまたはＳｃｏｐｅｄＡｐｐＲｕｌｅのいずれかの、ＩｎｐｕｔＳｃｏｐｅを表す。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：
・  ＩｔｅｍＩｄ：入力スコープのＩｔｅｍＩｄ
この型に追加されたメソッド：
・  ＩｎｐｕｔＳｃｏｐｅ（Ｇｕｉｄ  ｉｎｐｕｔＳｃｏｐｅ）
【０１１７】
ＣｏｌｌｅｃｔｉｏｎＳｃｏｐｅは、コレクションであるＩｎｐｕｔＳｃｏｐｅである。
派生：ＩｎｐｕｔＳｃｏｐｅから
この型に追加されたプロパティ：
・  ＲｅｌａｔｉｏｎｓｈｉｐＳｃｈｅｍａ：コレクションを定義する関係を保持するストリングスキーマ名
・  ＲｅｌａｔｉｏｎｓｈｉｐＮａｍｅ：コレクションを定義する上記のスキーマ内の関係型のストリング名
・  ＳｈａｌｌｏｗＳｃｏｐｅ：Ｂｏｏｌｅａｎ：真の場合に、入力スコープが、関係トラバーサルの１レベルに制限されなければならない。偽がデフォルトである。
この型に追加されたメソッド：
・  ＣｏｌｌｅｃｔｉｏｎＳｃｏｐｅ（Guid inputScope, string relationshipSchema, string relationshipName）
【０１１８】
ＡｕｔｏＬｉｓｔＳｃｏｐｅは、ＡｕｔｏＬｉｓｔであるＩｎｐｕｔＳｃｏｐｅである。
派生：ＩｎｐｕｔＳｃｏｐｅから
この型に追加されたプロパティ：なし。
この型に追加されたメソッド：
・  ＡｕｔｏＬｉｓｔＳｃｏｐｅ（Ｇｕｉｄ  ｉｎｐｕｔＳｃｏｐｅ）
【０１１９】
ＣＳＩＤＬＳｃｏｐｅは、ビジュアルブラウジングメタファＣＳＩＤＬであるＩｎｐｕｔＳｃｏｐｅである。ＣＳＩＤＬ値は、アプリケーションによって頻繁に使用されるが、任意の所与のシステムで同一の名前または位置を有しない場合がある特殊なフォルダを識別する、独自のシステム独立の形を提供する。
派生：ＩｎｐｕｔＳｃｏｐｅから
この型に追加されたプロパティ：
・  ＣＳＩＤＬ：現在のユーザについて評価され、入力スコープとして使用されるＣＬＩＤＬの値。
【０１２０】
図１６Ｃに、本発明のＬｏｇｉｃＣｏｎｓｔｒａｉｎｔネステッド型を示す。ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔは、ＲｕｌｅＬｏｇｉｃ（および子）とＤｅｃｉｓｉｏｎＰｏｉｎｔの両方によって使用される。ＤｅｃｉｓｉｏｎＰｏｉｎｔと共に使用される時に、ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔは、評価のためにサブミットされる入力アイテム型ならびに宣言するアプリケーションによって期待される出力型を指定する。ＲｕｌｅＬｏｇｉｃと共に使用される時に、この制約は、それに対してルールを評価できる入力型ならびにルールが生成する出力の種類を宣言する。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：
・  ＩｎｐｕｔＩｔｅｍＴｙｐｅＩｄ：入力アイテム型を指定するＯＳファイルシステムＴｙｐｅＩｄ。
・  Ｏｕｔｐｕｔ：出力型を指定するＯｕｔｐｕｔＴｙｐｅ  ｅｎｕｍ（下を参照されたい）からの値
この型に追加されたメソッド：
・  ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔ（Ｔｙｐｅ  ｉｎｐｕｔＩｔｅｍＴｙｐｅ，ＯｕｔｐｕｔＴｙｐｅ  ｏｔ）：ｔｙｐｅＯｆ（Ｉｔｅｍ）およびＯｕｔｐｕｔＴｙｐｅ（下を参照されたい）をとり、適当なＯＳファイルシステムＴｙｐｅＩｄを見つけてＩｎｐｕｔＩｔｅｍＴｙｐｅＩｄにストアする。
【０１２１】
ＯｕｔｐｕｔＴｙｐｅ（ｅｎｕｍ）は、Ｌｏｇｉｃ／ＤｅｃｉｓｉｏｎＰｏｉｎｔについてどの型を出力するか（または出力型に対する制約）を記述する。ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔで使用される。
値：
・  Ｂｏｏｌｅａｎ
・  ＦｕｎｃｔｉｏｎＩｎｆｏ
【０１２２】
図１６Ｄに、本発明のＬｏｇｉｃＳｔａｔｅｍｅｎｔネステッド型を示す。ＬｏｇｉｃＳｔａｔｅｍｅｎｔｓは、条件ツリーおよび結果のセット（アクションまたはＢｏｏｌｅａｎ）をエンコードする。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：
・  Ｃｏｎｄｉｔｉｏｎ：この論理ステートメントの条件ツリー。
・  ＬｏｇｉｃＲｅｓｕｌｔｓ：ＬｏｇｉｃＲｅｓｕｌｔ要素のマルチセット。条件が真と評価される場合に結果をエンコードする。
この型に追加されたメソッド：
・  ＬｏｇｉｃＳｔａｔｅｍｅｎｔ（Ｃｏｎｄｉｔｉｏｎ  ｃ，ＬｏｇｉｃＲｅｓｕｌｔ  ｌ）：条件ツリーおよび単一の結果をセットするコンストラクタ。
【０１２３】
図１６Ｅに、本発明のＬｏｇｉｃＲｅｓｕｌｔネステッド型およびその派生物を示す。ＬｏｇｉｃＲｅｓｕｌｔは、すべての結果型の基本クラスである。これは、それ自体は絶対に使用されず；その子が、ＲｕｌｅＬｏｇｉｃアイテムからの結果をエンコードするのに使用される。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：なし。
この型に追加されたメソッド：なし。
【０１２４】
ＢｏｏｌｅａｎＲｅｓｕｌｔ。ルールロジックがＢｏｏｌｅａｎ値を返せるようにする。主にＱｕｅｒｙＦｉｌｔｅｒ／ＡｕｔｏＬｉｓｔによって使用される。
派生：ＬｏｇｉｃＲｅｓｕｌｔから
この型に追加されたプロパティ：
・  Ｒｅｓｕｌｔ：結果を含むＢｏｏｌｅａｎ。真がデフォルト。
この型に追加されたメソッド：
・  ＢｏｏｌｅａｎＲｅｓｕｌｔ（ｂｏｏｌ  ｒｅｓｕｌｔ）
【０１２５】
ＡｃｔｉｏｎＲｅｓｕｌｔ。アクションは、アクティブルールまたはアプリケーションカスタマイゼーションルールの結果である。
派生：ＬｏｇｉｃＲｅｓｕｌｔから
この型に追加されたプロパティ：
・  ＦｕｎｃｔｉｏｎＩｎｆｏ：呼び出すべきメソッドをエンコードしたＦｕｎｃｔｉｏｎＩｎｆｏ
・  Ａｒｇｕｍｅｎｔｓ：ＦｕｎｃｔｉｏｎＩｎｆｏの順序付き引数を含むマルチセット。
・  Ｒｅｓｕｌｔ：スカラ結果はストリングであり、ｉｎｔ、ｄａｔｅ、ｓｔｒｉｎｇなどの実際のスカラ値を記述するｅｎｕｍである。
この型に追加されたメソッド：
・  Ａｃｔｉｏｎ（ＬｏｇｉｃＲｅｓｕｌｔ  ｌｒ，ｐａｒａｍｓ  ｏｂｊｅｃｔ［］ａｒｇｕｍｅｎｔｓ）：ロジック結果と、オプションとして必要な引数をセットするコンストラクタ。
・  ＳｃａｌａｒＲｅｓｕｌｔ（Ｓｔｒｉｎｇ  ｒｅｓｕｌｔ，ｅｎｕｍ  ＳｃａｌａｒＴｙｐｅ）
【０１２６】
ＳｃａｌａｒＲｅｓｕｌｔ。
この型に追加されたプロパティ：
・  Ｒｅｓｕｌｔ：ストリングとしてのスカラ結果、ｉｎｔ、ｄａｔｅ、ｓｔｒｉｎｇなどの実際のスカラ値を記述するｅｎｕｍである。
この型に追加されたメソッド：
・  ＳｃａｌａｒＲｅｓｕｌｔ（Ｓｔｒｉｎｇ  ｒｅｓｕｌｔ，ｅｎｕｍ  ＳｃａｌａｒＴｙｐｅ）
【０１２７】
図１６Ｆに、本発明のＣｏｎｄｉｔｉｏｎネステッド型およびその派生物を示す。Ｃｏｎｄｉｔｉｏｎは、ルールの条件をエンコードするのに使用される基本型である。これは、直接にインスタンス化されるのではなく、その子が、所与のルールインスタンスの一部として使用される。Ｃｏｎｄｉｔｉｏｎには、それ自体のプロパティが含まれない。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：なし。
この型に追加されたメソッド：
・  ｐｕｂｌｉｃ  ｓｔａｔｉｃ  Ｃｏｎｄｉｔｉｏｎ  ｏｐｅｒａｔｏｒ  ＆（Ｃｏｎｄｉｔｉｏｎ  ｌｅｆｔ，Ｃｏｎｄｉｔｉｏｎ  ｒｉｇｈｔ）：「＆」をオーバーライドして、ｌｅｆｔパラメータおよびｒｉｇｈｔパラメータを有する新しいＡｎｄＣｏｎｄｉｔｉｏｎを作成する。
・  ｐｕｂｌｉｃ  ｓｔａｔｉｃ  Ｃｏｎｄｉｔｉｏｎ  ｏｐｅｒａｔｏｒ｜（Ｃｏｎｄｉｔｉｏｎ  ｌｅｆｔ，Ｃｏｎｄｉｔｉｏｎ  ｒｉｇｈｔ）：「｜」演算子をオーバーライドする。
・  ｐｕｂｌｉｃ  ｓｔａｔｉｃ  Ｃｏｎｄｉｔｉｏｎ  ｏｐｅｒａｔｏｒ  ！（Ｃｏｎｄｉｔｉｏｎ  ｃ）：Ｃｏｎｄｉｔｉｏｎ  ｃのＮｏｔＣｏｎｄｉｔｉｏｎを返す。
【０１２８】
ＣｏｎｄｉｔｉｏｎＴｒｅｅは、Ｃｏｎｄｉｔｉｏｎから派生し、一連の条件をエンコードする。ＣｏｎｄｉｔｉｏｎＴｒｅｅは、直接には絶対に使用されず、その子であるＡｎｄＣｏｎｄｉｔｉｏｎおよびＯｒＣｏｎｄｉｔｉｏｎが使用される。
派生：Ｃｏｎｄｉｔｉｏｎから
この型に追加されたプロパティ：
・  Ｃｈｉｌｄｒｅｎ：Ｃｏｎｄｉｔｉｏｎのマルチセット。これらは、単一の条件または他のツリーとすることができる。
この型に追加されたメソッド：
・  なし。
【０１２９】
ＡｎｄＣｏｎｄｉｔｉｏｎは、ＣｏｎｄｉｔｉｏｎＴｒｅｅから派生する。ＡｎｄＣｏｎｄｉｔｉｏｎツリーがルールに追加される時に、そのＡｎｄＣｏｎｄｉｔｉｏｎツリーは、ルール評価の成功を判定する時に、コンポーネント条件を評価し、その結果の論理ＡＮＤをとらなければならないことを示す。
派生：ＣｏｎｄｉｔｉｏｎＴｒｅｅから
この型に追加されたプロパティ：なし。
この型に追加されたメソッド：
・  ＡｎｄＣｏｎｄｉｔｉｏｎ（ｐａｒａｍｓ  Ｃｏｎｄｉｔｉｏｎ［］ｏｐｅｒａｎｄｓ）：構築時にコンポーネント条件を指定できるようにするコンストラクタ。
【０１３０】
ＯｒＣｏｎｄｉｔｉｏｎも、ＣｏｎｄｉｔｉｏｎＴｒｅｅから派生する。ＯｒＣｏｎｄｉｔｉｏｎツリーがルールに追加される時に、そのＯｒＣｏｎｄｉｔｉｏｎツリーは、ルール評価の成功を判定する時に、コンポーネント条件を評価し、その結果の論理ＯＲをとらなければならないことを示す。
派生：ＣｏｎｄｉｔｉｏｎＴｒｅｅから
この型に追加されたプロパティ：なし。
この型に追加されたメソッド：
・  ＯｒＣｏｎｄｉｔｉｏｎ（ｐａｒａｍｓ  Ｃｏｎｄｉｔｉｏｎ［］ｏｐｅｒａｎｄｓ）：構築時にコンポーネント条件を指定できるようにするコンストラクタ。
【０１３１】
ＮｏｔＣｏｎｄｉｔｉｏｎは、Ｃｏｎｄｉｔｉｏｎから派生する。ＮｏｔＣｏｎｄｉｔｉｏｎがルールに追加される時に、構成条件が評価され、その結果の否定が使用される。
派生：Ｃｏｎｄｉｔｉｏｎから
この型に追加されたプロパティ：
・  Ｃｏｎｄｉｔｉｏｎ：単一のＣｏｎｄｉｔｉｏｎ（または、ＣｏｎｄｉｔｉｏｎＴｒｅｅなどの派生型）
この型に追加されたメソッド：
・  ＮｏｔＣｏｎｄｉｔｉｏｎ（Ｃｏｎｄｉｔｉｏｎ  ｃｏｎｄｉｔｉｏｎ）：構築時に条件を指定できるようにするコンストラクタ。
【０１３２】
ＬｅａｆＣｏｎｄｉｔｉｏｎは、実際の条件を表すのに使用される。これは、使用される条件関数の名前、ならびに名前を指定された条件関数と共に使用される引数のマルチセットを記述する。
派生：Ｃｏｎｄｉｔｉｏｎから
この型に追加されたプロパティ：
・  Ｎａｍｅ：評価中に使用される条件関数の名前。現在、これは、組み込みセット指向条件またはトリガするアイテム型の任意のメソッドのいずれかである、サポートされるＳＱＬコンパレータのいずれかの名前とすることができる。サポートされるＳＱＬ組み込み（およびテキスト同等物）は、「＝」、「Ｅｑｕａｌｓ」、「＞」、「ＧｒｅａｔｅｒＴｈａｎ」、「＜」、「ＬｅｓｓＴｈａｎ」、「＞＝」、「ＧｒｅａｔｅｒＴｈａｎＥｑｕａｌＴｏ」、「＜＝」、「ＬｅｓｓＴｈａｎＥｑｕａｌＴｏ」、「＜＞」、「ＮｏｔＥｑｕａｌ」、および「Ｌｉｋｅ」である。
サポートされるセット指向条件：
○  ＡＮＹ＿ＩＮ：ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅおよびＣｏｌｌｅｃｔｉｏｎＶａｌｕｅと共に使用される。名前を指定されたコレクションで定義される関係のいずれかが、ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅで指定された型であるかどうかを判定する。
○  ＡＬＬ＿ＩＮ：ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅおよびＣｏｌｌｅｃｔｉｏｎＶａｌｕｅと共に使用される。名前を指定されたコレクションで定義される関係のすべてが、ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅで指定された型であるかどうかを判定する。
・  Ａｒｇｕｍｅｎｔｓ：名前を指定された条件関数への引数のマルチセット。一実施形態で、ＭｕｌｔｉＳｅｔが順序付きでないので、ＬｅａｆＣｏｎｄｉｔｉｏｎ１およびＬｅａｆＣｏｎｄｉｔｉｏｎ２プロパティが使用される。
この型に追加されたメソッド：
・  ＬｅａｆＣｏｎｄｉｔｉｏｎ（ｓｔｒｉｎｇ  ｎａｍｅ，ｐａｒａｍｓ  ｏｂｊｅｃｔ［］ａｒｇｕｍｅｎｔｓ）：構築時に条件関数名および引数をセットできるようにするコンストラクタ。
【０１３３】
ＯＰａｔｈＣｏｎｄｉｔｉｏｎは、ＯＰａｔｈの、複雑な開発者定義のｂｌｏｂを表す。ＯＰａｔｈ式は、使用されるためにＢｏｏｌｅａｎ戻り値に評価されなければならない。例えば：（「Ｃｏｕｎｔ（ＯｕｔＤｏｃｕｍｅｎｔＡｕｔｈｏｒＲｅｌａｔｉｏｎｓｈｉｐｓ）＞１」）である。
派生：ＬｅａｆＣｏｎｄｉｔｉｏｎから
この型に追加されたプロパティ：
・  ＯＰａｔｈ：ＯＰａｔｈ式を含むストリング
・  ＤｉｓｐｌａｙＮａｍｅ：クエリビルダまたは他のＵＩで表示されるＯＰａｔｈのこのｂｌｏｂのストリング名。
・  この型に追加されたメソッド：
・  ＯＰａｔｈＣｏｎｄｉｔｉｏｎ（ｓｔｒｉｎｇ  ｅｘｐ）：ＯＰａｔｈ式をセットするコンストラクタ。
【０１３４】
図１６Ｇに、本発明のＡｒｇｕｍｅｎｔＶａｌｕｅネステッド型およびその派生物を示す。ＡｒｇｕｍｅｎｔＶａｌｕｅは、条件とアクションの両方の引数をエンコードするのに使用される基本型である。これは、直接にはインスタンス化されず、その子（ＣｏｎｓｔａｎｔＶａｌｕｅ、ＰｒｏｐｅｒｔｙＶａｌｕｅ、ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅ、ＣｏｌｌｅｃｔｉｏｎＶａｌｕｅなど）が使用される。
派生：ＯＳファイルシステム．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：なし。
【０１３５】
ＣｏｎｓｔａｎｔＶａｌｕｅは、ＡｒｇｕｍｅｎｔＶａｌｕｅから派生し、ルールの条件およびアクションの引数の定数値を表すのに使用される。
派生：ＡｒｇｕｍｅｎｔＶａｌｕｅから
この型に含まれるプロパティ：
・  Ｖａｌｕｅ：この引数によって表される単一のストリング値を含む。
この型に追加されたメソッド：
・  ＣｏｎｓｔａｎｔＶａｌｕｅ（ｓｔｒｉｎｇ  ｖａｌｕｅ）：構築時に直接に値をセットできるようにするコンストラクタ。
【０１３６】
ＰｒｏｐｅｒｔｙＶａｌｕｅは、ＡｒｇｕｍｅｎｔＶａｌｕｅから派生し、ＯＳファイルシステムタイプのプロパティである条件およびアクションへの引数を表すのに使用される。もう１つの実施形態で、ルールアーキテクチャのトリガするアイテム型との一貫性のために、ストリングスキーマおよび型名ではなく型ＧＵＩＤを使用することができることに留意されたい。
派生：ＡｒｇｕｍｅｎｔＶａｌｕｅから
この型に含まれるプロパティ：
・  ＰｒｏｐｅｒｔｙＮａｍｅ：パラメータとして使用されるインバウンドアイテムのプロパティの名前を含む。
この型に追加されたメソッド：
・  ＰｒｏｐｅｒｔｙＶａｌｕｅ（ｓｔｒｉｎｇ  ｐｒｏｐｅｒｔｙＮａｍｅ）：構築時にプロパティ名を指定できるようにするコンストラクタ。
【０１３７】
ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅは、ＡｒｇｕｍｅｎｔＶａｌｕｅから派生し、セット指向条件のいずれかへのパラメータとして使用される関係の名前を表すのに使用される。
派生：ＡｒｇｕｍｅｎｔＶａｌｕｅから
この型に含まれるプロパティ：
・  ＲｅｌａｔｉｏｎｓｈｉｐＳｃｈｅｍａＮａｍｅ：Ｒｅｌａｔｉｏｎｓｈｉｐ型をその中で見つけることができるスキーマの名前を含む。
・  ＲｅｌａｔｉｏｎｓｈｉｐＮａｍｅ：Ｒｅｌａｔｉｏｎｓｈｉｐ型の名前を含む。
この型に追加されたメソッド：
・  ＲｅｌａｔｉｏｎｓｈｉｐＶａｌｕｅ（string relationshipSchemaName, string relationshipName）：構築時にスキーマ名および型名を指定できるようにするコンストラクタ。
【０１３８】
ＣｏｌｌｅｃｔｉｏｎＶａｌｕｅは、ＡｒｇｕｍｅｎｔＶａｌｕｅから派生し、セット指向条件のいずれかへのパラメータとして使用されるコレクションの名前を表すのに使用される。
派生：ＡｒｇｕｍｅｎｔＶａｌｕｅから
この型に含まれるプロパティ：
・  ＣｏｌｌｅｃｔｉｏｎＩｔｅｍＩｄ：コレクションアイテムのＧｕｉｄアイテムｉｄ
・  ＲｅｌａｔｉｏｎｓｈｉｐＳｃｈｅｍａＮａｍｅ：このコレクションの関係をその中で見つけることができるスキーマの名前
・  ＲｅｌａｔｉｏｎｓｈｉｐＮａｍｅ：このコレクションに含まれるＲｅｌａｔｉｏｎｓｈｉｐ型の名前。
この型に追加されたメソッド：
・  ＣｏｌｌｅｃｔｉｏｎＶａｌｕｅ（Guid itemid, string relationshipSchemaName, string relationshipName）：構築時にすべてのプロパティ値をセットできるようにするコンストラクタ。
【０１３９】
ＲｕｌｅＶａｌｕｅは、ＡｒｇｕｍｅｎｔＶａｌｕｅから派生し、ＬｅａｆＣｏｎｄｉｔｉｏｎのパラメータとして評価され、使用されるＲｕｌｅＬｏｇｉｃを表すのに使用される。ＲｕｌｅＶａｌｕｅが、セット指向条件のいずれかへのパラメータとして使用される時に、ＲｕｌｅＶａｌｕｅは、ＡｕｔｏＬｉｓｔをポイントすると期待される（そうでない場合には、例外が生成されなければならない）。ＲｕｌｅＶａｌｕｅが、組み込みスカラ条件（「＝」、「＜」など）のいずれかへのパラメータとして使用される時に、ＲｕｌｅＶａｌｕｅは、ＲｕｌｅＬｏｇｉｃをポイントすることができる。ＲｕｌｅＶａｌｕｅは、Ｂｏｏｌｅａｎを返すこともできる。
派生：ＡｒｇｕｍｅｎｔＶａｌｕｅから
この型に含まれるプロパティ：
・  ＲｕｌｅＩｄ：ルールアイテムのＧｕｉｄアイテムｉｄ
この型に追加されたメソッド：
・  ＲｕｌｅＶａｌｕｅ（Ｇｕｉｄ  ｒｕｌｅＩｔｅｍＩｄ）：構築時にすべてのプロパティ値をセットできるようにするコンストラクタ。
【０１４０】
ＯＰａｔｈＶａｌｕｅは、ＬｅａｆＣｏｎｄｉｔｉｏｎのＬＨＳまたはＲＨＳとしてのＯＰａｔｈ式の使用を可能にする。
派生：ＡｒｇｕｍｅｎｔＶａｌｕｅから
この型に追加されたプロパティ：
・  ＯＰａｔｈ：ＯＰａｔｈ式
・  ＤｉｓｐｌａｙＮａｍｅ：クエリビルダまたは他のＵＩに表示される名前
この型に追加されたメソッド：
・  ＯＰａｔｈＶａｌｕｅ（ｓｔｒｉｎｇ  ｅｘｐ，ｓｔｒｉｎｇ  ｄｉｓｐｌａｙＮａｍｅ）：構築時にすべてのプロパティ値をセットできるようにするコンストラクタ。
【０１４１】
図１６Ｈに、本発明のＦｕｎｃｔｉｏｎＩｎｆｏネステッド型およびその派生物を示す。ＦｕｎｃｔｉｏｎＩｎｆｏは、Ａｃｔｉｏｎとして呼び出されるメソッドに関する情報を表すのに使用される基本型である。ＦｕｎｃｔｉｏｎＩｎｆｏは、それ自体では絶対に使用されず、その子型のＩｎｓｔａｎｃｅＦｕｎｃｔｉｏｎＩｎｆｏおよびＳｔａｔｉｃＦｕｎｃｔｉｏｎＩｎｆｏが使用される。
派生：（ＯＳファイルシステム）．ＮｅｓｔｅｄＴｙｐｅ
この型に追加されたプロパティ：
・  ＭｅｍｂｅｒＮａｍｅ：呼び出されるメソッドの名前、またはその「ｓｅｔ＿」メソッドが呼び出されなければならないプロパティの名前。
この型に追加されたメソッド：
・  ＦｕｎｃｔｉｏｎＩｎｆｏ（ｓｔｒｉｎｇ  ｍｅｍｂｅｒＮａｍｅ）：構築時にメンバの名前をセットできるようにするコンストラクタ。
・  ｉｎｔｅｒｎａｌ  ｖｉｒｔｕａｌ  ｖｏｉｄ  Ｅｘｅｃｕｔｅ（ItemContext context, List <ArgumentValue> arguments）：このメソッドは、名前を指定されたメソッドの呼出しを実行するために、子クラスでオーバーライドされる。
【０１４２】
ＩｎｓｔａｎｃｅＦｕｎｃｔｉｏｎＩｎｆｏは、ＦｕｎｃｔｉｏｎＩｎｆｏから派生し、特定のアイテムインスタンスに対するメソッド呼出しを表すのに使用される。
派生：ＦｕｎｃｔｉｏｎＩｎｆｏから
この型に追加されたプロパティ：
・  ＴａｒｇｅｔＩｔｅｍＩｄ：それに対してメソッドを呼び出さなければならないアイテムのアイテムｉｄ。ルール作成の一部としてＡｃｔｉｏｎＲｅｓｕｌｔ要素へのメソッド呼出しをエンコードする時に、メソッド呼出しが入力アイテムに対して行われなければならない場合には、ＴａｒｇｅｔＩｔｅｍＩｄを空のままにすることに留意されたい。その呼出しが特定のアイテムに対して行われなければならない場合には、そのアイテムのＩＤをここにセットしなければならない。
この型に追加されたメソッド：
・  ＩｎｓｔａｎｃｅＦｕｎｃｔｉｏｎＩｎｆｏ（ｓｔｒｉｎｇ  ｍｅｍｂｅｒＮａｍｅ）：構築時にメンバの名前をセットできるようにするコンストラクタ。
・  ＩｎｓｔａｎｃｅＦｕｎｃｔｉｏｎＩｎｆｏ（ｓｔｒｉｎｇ  ｍｅｍｂｅｒＮａｍｅ，Ｇｕｉｄ  ｔａｒｇｅｔＩｔｅｍＩｄ）：構築時にメンバの名前およびターゲットにされるアイテムｉｄをセットできるようにするコンストラクタ。
・  ｉｎｔｅｒｎａｌ  ｖｏｉｄ  Ｅｘｅｃｕｔｅ（ItemContext context, List <ArgumentValue> arguments）：ＩｎｓｔａｎｃｅＦｕｎｃｔｉｏｎＩｎｆｏデータによって指定されるメソッドを実行する。最後にｃｏｎｔｅｘｔ．Ｕｐｄａｔｅ（）が呼び出されず、呼出し側がその世話をすることに留意されたい。これは、メソッド呼出しがメモリ内のＯＳファイルシステムデータに対する副作用を有する場合に重要である。
【０１４３】
ＳｔａｔｉｃＦｕｎｃｔｉｏｎＩｎｆｏは、ＦｕｎｃｔｉｏｎＩｎｆｏから派生し、スタティックメソッド呼出しを表すのに使用される。
派生：ＦｕｎｃｔｉｏｎＩｎｆｏから
この型に追加されたプロパティ：
・  ＡｓｓｅｍｂｌｙＮａｍｅ：このメソッドを見つけることができるアセンブリの名前。
・  ＴｙｐｅＮａｍｅ：このメソッドが定義されたアセンブリ内の型の名前。
この型に追加されたメソッド：
・  ＳｔａｔｉｃＦｕｎｃｔｉｏｎＩｎｆｏ（string assemblyName, string typeName, string memberName）：構築時にＡｓｓｅｍｂｌｙＮａｍｅ、ＴｙｐｅＮａｍｅ、およびＭｅｍｂｅｒＮａｍｅを指定できるようにするコンストラクタ。
・  Ｉｎｔｅｒｎａｌ  ｖｏｉｄ  Ｅｘｅｃｕｔｅ（ItemContext context, List <ArgumentValue> arguments）：このＳｔａｔｉｃＦｕｎｃｔｉｏｎＩｎｆｏによって指定されるメソッドを実行する。最後にｃｏｎｔｅｘｔ．Ｕｐｄａｔｅ（）が呼び出されず、呼出し側がその世話をすることに留意されたい。これは、メソッド呼出しがメモリ内のＯＳファイルシステムデータに対する副作用を有する場合に重要である。
複数の非ファイルシステム型が、ＯＳファイルシステムルールＡＰＩの一部である。
【０１４４】
ＲｕｌｅＩｎｐｕｔは、プラットフォームへの入力を定義し、サブミットするのに使用される。サブミットされる入力は、イベントが発生したスコープにアタッチされたＲｕｌｅの評価をトリガする。入力をサブミットするには、ＤｅｃｉｓｉｏｎＰｏｉｎｔ型で見つかるサブミッションメソッドを使用する。
この型のプロパティ：
・  Ｉｎｔ６４  Ｉｄ：このＲｕｌｅＩｎｐｕｔのｉｄ。ＲｕｌｅＩｎｐｕｔが成功裡にサブミットされた後に、プラットフォームによってＩｄが割り当てられる。
・  Ｇｕｉｄ  ＥｖｅｎｔＤａｔａＩｔｅｍＩｄ：イベントが発生したＷｉｎＦＳアイテムのｉｔｅｍｉｄ。
この型のメソッド：なし。
【０１４５】
ＲｕｌｅＩｎｐｕｔＣｏｌｌｅｃｔｉｏｎは、Ｓｙｓｔｅｍ．Ｃｏｌｌｅｃｔｉｏｎｓ．ＣｏｌｌｅｃｔｉｏｎＢａｓｅから派生する。これによって、複数のＲｕｌｅＩｎｐｕｔを同時にサブミットすることが可能になる。生成されるＲｕｌｅＳｅｔＥｖａｌｕａｔｉｏｎアイテムに、バッチでサブミットされたすべてのイベントからの組み合わされた結果が含まれる。空のＲｕｌｅＩｎｐｕｔＣｏｌｌｅｃｔｉｏｎのサブミットは、有効である。返されるＧｕｉｄに、Ｇｕｉｄ．Ｅｍｐｔｙがセットされる。
この型のプロパティ：なし。
この型のメソッド：
・  ＲｕｌｅＩｎｐｕｔ  ｔｈｉｓ［ｉｎｔ  ｉｎｄｅｘ］：アレイインデックスアクセッサを使用する、含まれるＲｕｌｅＩｎｐｕｔへのアクセスを可能にするインデクサ。
・  ｉｎｔ  Ａｄｄ（ＲｕｌｅＩｎｐｕｔ  ｖａｌｕｅ）：指定されたＲｕｌｅＩｎｐｕｔをコレクションに追加する。ＲｕｌｅＩｎｐｕｔが既にコレクションにある場合には、ＩｎｖａｌｉｄＯｐｅｒａｔｉｏｎＥｘｃｅｐｔｉｏｎを送出する。
・  ｂｏｏｌ  Ｃｏｎｔａｉｎｓ（ＲｕｌｅＩｎｐｕｔ  ｖａｌｕｅ）：コレクションに所与のＲｕｌｅＩｎｐｕｔが含まれる場合に真、そうでない場合に偽を返す。
・  ｉｎｔ  ＩｎｄｅｘＯｆ（ＲｕｌｅＩｎｐｕｔ  ｖａｌｕｅ）：コレクション内の所与のＲｕｌｅＩｎｐｕｔのインデックスを返す。
・  ｖｏｉｄ  Ｉｎｓｅｒｔ（ｉｎｔ  ｉｎｄｅｘ，ＲｕｌｅＩｎｐｕｔ  ｖａｌｕｅ）：コレクションの指定されたインデックスにｖａｌｕｅを挿入する。
・  ｖｏｉｄ  Ｒｅｍｏｖｅ（ＲｕｌｅＩｎｐｕｔ  ｖａｌｕｅ）：所与のファイルシステムルールイベントをコレクションから除去する。
【０１４６】
ＲｕｌｅＥｘｃｅｐｔｉｏｎ。これらのＡＰＩの１つがエラーなる時に、例外が送出される。標準的な状況のために記述された「普通の」例外があてはまるか、システム例外が正確に送出が望まれるものである場合に、例えば次などの標準例外が使用される。
ArgumentNullException
ArgumentOutOfRangeException
InvalidOperationException
【０１４７】
ＯＳファイルシステムルールＡＰＩインデクサ（Ｃ＃の「ｔｈｉｓ」プロパティ）は、キーがコレクション内のエントリと一致しない場合に、ＡｒｇｕｍｅｎｔＯｕｔＯｆＲａｎｇｅＥｘｃｅｐｔｉｏｎを送出する。インデクサは、有効なオブジェクトを返すか例外を送出し、Ｓｙｓｔｅｍ．Ｃｏｌｌｅｃｔｉｏｎｓ．Ｈａｓｈｔａｂｌｅのようにヌル値を返さない。ＯＳファイルシステムルールまたはＳＱＬクライアントによって検出される他のエラーは、ＲｕｌｅＥｘｃｅｐｔｉｏｎとして送出される。
【０１４８】
サンプルコード
【０１４９】
【表１−１】
2007537512.tif 000003
【０１５０】
【表１−２】
2007537512.tif 000004
【０１５１】
ＬｅａｆＣｏｎｄｉｔｉｏｎの演算子Ｄｉｓｃｏｖｅｒｙ。どの演算子がサポートされるかを開発者が発見できる形の１つが、すべての有効な演算子のｅｎｕｍを有することである。利益は、開発者が、すべての有効な演算子を素早く発見できることである。スペルを誤った演算子の発行を避けることもできる。もう１つの形は、ＢｅｔｗｅｅｎＯｐｅｒａｔｏｒ（ｖａｌｕｅ１，ｖａｌｕｅ２，ｖａｌｕｅ３）、ＧｒｅａｔｅｒＴｈａｎＯｐｅｒａｔｏｒ（ｖａｌｕｅ１，ｖａｌｕｅ２）など、演算子ごとに独自のクラスを定義することである。
【０１５２】
もう１つの最適化で、ＱｕｅｒｙＦｉｌｔｅｒおよびＡｕｔｏＬｉｓｔが、論理ステートメントのＢｏｏｌｅａｎ結果を有することだけができる。ＡＰＩは、ＡｐｐＲｕｌｅに使用されるステートメントと別の、特殊なＢｏｏｌｅａｎＳｔａｔｅｍｅｎｔ型を作成することによって、ＱｕｅｒｙＦｉｌｔｅｒおよびＡｕｔｏＬｉｓｔでＢｏｏｌｅａｎ結果だけを有することを保証することができる。
【０１５３】
次は、エンドユーザ照会およびエンドユーザフィルタと、それらを実行するＡＰＩ機構の説明である。オブジェクトＱｕｅｒｙＦｉｌｔｅｒおよびＡｕｔｏＬｉｓｔは、ユーザの代わりにクエリを構成する時、またはエンドユーザが後で見、使用し、推理するクエリを構成する時に作成される。
【０１５４】
クエリは、アイテムのスコープおよびこれらのアイテムに適用されるＱｕｅｒｙＦｉｌｔｅｒによって定義される。クエリの結果は、アイテムのセットであり、すべての実用的な理由から、エンドユーザは、クエリと物理的なＬｉｓｔの間にほとんど差を見出さない。したがって、「クエリ」のユーザの概念は、データのアドホックな動的フィルタリングのプロセスを指し、これは、永続する時にＡｕｔｏＬｉｓｔになり、ＡｕｔｏＬｉｓｔは、その内容がオンデマンドで計算されるＬｉｓｔである。用語ＬｉｓｔおよびＡｕｔｏＬｉｓｔは、交換可能に使用される。
【０１５５】
エンドユーザは、２つのビジュアル機構を使用してクエリを構成する。第１に、ＬｉｓｔまたはＡｕｔｏ−Ｌｉｓｔの内容を表示するページを開き、特定の１つまたは複数のプロパティによってリスト（またはオートリスト）内のアイテムをスタックするかソートし、特定のスタックに「ドリルイン」するというナビゲーションタスクのいずれかを実行することによってエンドユーザがクエリを実行できるナビゲーショナルＵＩである。第２に、エンドユーザに提供されるリッチクエリＵＩが、リストビューワページに統合されたクエリビルダＵＩを使用することによって、より豊かなクエリフィルタのコンポーズを容易にすることができる。
【０１５６】
クエリ構成は、１回のプロセスではなく、増分的でコンポジション的なプロセスである。例えば、コンポジション的スタッキングによって、ユーザが、タイトルによって文書をスタックし、１つのタイトルにドリルインすることが可能になる。残りのＤｏｃｕｍｅｎｔは、次に、日付によってスタックされ、ユーザは、ある年にドリルインする。
【０１５７】
フィルタのコンポジション。ユーザは、（［Ｔｏｄａｙ］−３０ｄａｙｓ）と（［Ｔｏｄａｙ］−６０ｄａｙｓ）の間のｍｏｄｉｆｉｅｄＤａｔｅを有する文書として「ＭｏｄｉｆｉｅｄＬａｓｔＭｏｎｔｈ」などのフィルタを定義する。これは、クエリビルダＵＩ内で作成し、実行し、おそらく保存することができる。
【０１５８】
ＡｕｔｏＬｉｓｔのコンポジション。ユーザは、キーワード「Ｉｍｐｏｒｔａｎｔ」を有する「ａｌｌ  ｉｔｅｍｓ」スコープ内のすべての文書として「ＭｙＩｍｐｏｒｔａｎｔＤｏｃｕｍｅｎｔｓ」を定義し、これをオートリストとして保存する。ユーザは、ビューを開くことによってＭｙＩｍｐｏｒｔａｎｔＤｏｃｕｍｅｎｔｓにナビゲートすることによって、新しいオートリストの入力スコープとして「ＭｙＩｍｐｏｒｔａｎｔＤｏｃｕｍｅｎｔｓ」から開始する。ユーザは、クエリビルダＵＩを使用して「ＭｙＩｍｐｏｒｔａｎｔＤｏｃｕｍｅｎｔｓ」に対して「ＭｏｄｉｆｉｅｄＬａｓｔＭｏｎｔｈ」クエリフィルタを使用し、その後、結果のオートリストを「ＩｍｐｏｒｔａｎｔＤｏｃｕｍｅｎｔｓＵｐｄａｔｅｄＬａｓｔＭｏｎｔｈ」として保存する。
【０１５９】
マルチステートメントフィルタ。ユーザは、クエリビルドＵＩを使用して、「ｍｕｓｉｃ  ｔｙｐｅ  ＩＳ  ｊａｚｚ」などのフィルタを作成する。ユーザは、追加フィルタ「ＯＲ」「ｍｕｓｉｃ  ａｒｔｉｓｔ  ＩＳ  Ｊｏｎｉ  Ｍｉｔｃｈｅｌｌ」を追加する。ユーザは、追加フィルタ「ＡＮＤ」「ｍｕｓｉｃ  ａｌｂｕｍ  ｔｉｔｌｅ  ｄｏｅｓ  ＮＯＴ  ＣＯＮＴＡＩＮ「Ｏｒｉｇｉｎａｌ  Ｓｏｕｎｄｔｒａｃｋ」」を追加する。
【０１６０】
経時的に、クエリを、ＡｕｔｏＬｉｓｔとして保存し、取り出し、さらに編集することができる。クエリで使用されるフィルタは、エンドユーザプログラミングの他の態様すなわち、リッチアクションおよびリッチイベントの定義にも使用することができる。最後に、ＡｕｔｏＬｉｓｔおよびフィルタ自体を照会することができる（例えば、ＭｙＤｏｃｕｍｅｎｔｓリストをこれから削除するので、このリストを使用しているＡｕｔｏＬｉｓｔを見つける）。
【０１６１】
クエリ結果は、ユーザによって見られる。プレゼンテーション情報は、２つのカテゴリに含まれる。
【０１６２】
クエリメタデータ。選択されたアイテムの特定のエンドユーザプロパティが提示される。エンドユーザは、クエリ結果の一部としてユーザに示される列のリストに特定のプロパティを追加し、除去することができる。これらのプレゼンテーション詳細を、集合的にビュー定義と呼ぶ。同一のクエリまたはＡｕｔｏＬｉｓｔは、概念上、アプリケーションごとにおよび／またはユーザごとに、異なるビュー定義を有することができる。
【０１６３】
アプリケーションメタデータ。アプリケーションは、アプリケーション固有データをＶｉｅｗＤｅｆｉｎｉｔｉｏｎに関連付けて、そのアプリケーションで使用されるコンテキストメタデータを取り込むことができる（例えば、ＡｕｔｏＬｉｓｔを表示する時の背景カラー）。
【０１６４】
リッチナビゲーショナルＵＩでＡｕｔｏＬｉｓｔを提示するために、柔軟で強力なカーソリングモデルが必要である。クエリまたはＡｕｔｏＬｉｓｔのプレゼンテーション要素は、クエリ定義に影響しない（クエリ定義は、クエリの内容の論理的で宣言的な定義である）。
【０１６５】
次は、エンドユーザシナリオである。第１のシナリオでは、ユーザが気にするアイテムにユーザがフィルだダウンする時に提供される保存および再利用の機能性が、ＡｕｔｏＬｉｓｔとして保存し、そのセットに戻る。ローカルビュー永続性は、ユーザが、保存されたＡｕｔｏＬｉｓｔに戻ることを可能にし、ＡｕｔｏＬｉｓｔが保存された時と同一のビューが提供される。アプリケーションにまたがるクエリ永続性の共通プラットフォームが提供され、これによって、あるアプリケーションの中から定義された「Ｐｅｏｐｌｅ  Ｉ’ｍ  ｍｅｅｔｉｎｇ  ｗｉｔｈ」ＡｕｔｏＬｉｓｔを見ることを選択する第２ユーザが、このクエリをブラウズし、会合に来る人を見ることができる。一般に、ユーザは、多数の異なるアプリケーションによって作成されたＡｕｔｏＬｉｓｔを見、ブラウズすることができる。
【０１６６】
第２のシナリオでは、クエリコンポジションが提供され、その結果、第２ユーザが、会合に来るクライアントに関するすべてのレポートを見ることができる。第２ユーザは、クエリを作成して、「Ｐｅｏｐｌｅ  Ｉ’ｍ  Ｍｅｅｔｉｎｇ」ＡｕｔｏＬｉｓｔに含まれる人によってオーサリングされたすべての文書を見つける。ＡｕｔｏＬｉｓｔを配布するために、第２ユーザは、重要なクライアントレポートを見つける（彼の計算機にあるアイテムデータに基づいて）Ａｕｔｏｌｉｓｔを作成し、彼のチームがそれを使用することを求める。第２ユーザは、これを彼のチームの全員に配布して、ＡｕｔｏＬｉｓｔとして保存し、彼らの個人のマシンにあるデータに対して彼ら自身のマシンで実行する。ビュー定義を配布するために、第３ユーザが第２ユーザからの保存されたＡｕｔｏｌｉｓｔを開く時に、第３ユーザは、第２ユーザが作成したものと同一の、フィルタアイコン、ソート順序、およびグループ化を有する列を得る。
【０１６７】
第３のシナリオでは、ローカルクエリを共有することができる。第３ユーザは、第２ユーザに使用してもらいたいアイテムのセットを有する。第３ユーザは、アイテムの第１セットに関する保存されたＡｕｔｏｌｉｓｔ（第３ユーザ自身のマシンにある）にアクセスする。第２ユーザおよび第３ユーザの両方が、このＡｕｔｏＬｉｓｔを開く時に同一のアイテムのセットを見る（セキュリティ制限を除いて）。第３ユーザが、アプリケーションをポイントするＡｕｔｏｌｉｓｔを第２ユーザから得る場合に、グレースフルフェイリヤ（ｇｒａｃｅｆｕｌ  ｆａｉｌｕｒｅ）を提供することができる。第３ユーザは、そのアプリケーションを有しない。したがって、Ａｕｔｏｌｉｓｔは、その代わりにＡｌｌ  Ｉｔｅｍｓで開かれる。
【０１６８】
複数のＱｕｅｒｙＦｉｌｔｅｒおよびＡｕｔｏＬｉｓｔをコンポーズして、新しいＱｕｅｒｙＦｉｌｔｅｒおよびＡｕｔｏＬｉｓｔを構成することが可能である。ＡｕｔｏＬｉｓｔをクエリのスコープとして使用することも可能である。
【０１６９】
図１７を参照すると、本発明によるルールエンジン１７００が示されている。開示されるルールプラットフォームは、入力を受け取り、適当なルールを評価するルールエンジン１７００からなる。ルールエンジン１７００を呼び出すために、アプリケーションは、ルールＡＰＩ（ルール評価ＡＰＩとも呼ばれる）を使用することによって、判断ポイントオブジェクトを介してデータをサブミットする。このＡＰＩは、データをルール評価エンジンにサブミットし、ＡＰＩを介して結果を返す。実行モデルは、同期式であり、返される結果は、単に構造化されたデータである。ルールエンジン１７００は、クエリプロセッサを使用してルールを評価し、実行すべきルールを判定し、入力に対してルールを評価し、結果を返す。開発者のためのストレージプラットフォームであることのほかに、ＥＵＰモデルおよびファイルシステムの抽象化は、プラットフォーム全体の重要な部分である。
【０１７０】
図１８を参照すると、本発明のルールアーキテクチャでの豊かさの次元を表すブロック図１８００が示されている。提供される機能は、３つの全般的なカテゴリすなわち、挙動、構造、および制御フローに含まれる。挙動に関して、エンドユーザルールは、２つの基本的な種類のカスタマイゼーションすなわち、データを定義する派生ルール（ストアされたクエリ）と、挙動を定義するアクティブルールに使用される。派生ルールは、データに対するリッチクエリを定義し、照会およびルールのために物理ファイルシステムコレクションのように振る舞う仮想データコレクション（「派生アイテムセット」）を定義する。例えば、エンドユーザは、派生アイテムセットとして、ＰｅｏｐｌｅＷｈｏＬｉｖｅＩｎＢｅｌｌｅｖｕｅと呼ばれるＣｏｎｔａｃｔのグループを定義することができる。後に、このユーザは、電子メールを照会して、ＰｅｏｐｌｅＷｈｏＬｉｖｅＩｎＢｅｌｌｅｖｕｅによって送信されたすべてのメールを見つけることができる。
【０１７１】
アクティブルールは、エンドユーザがロジックを用いてアプリケーションフローを増補することをアプリケーションが可能にする明確に定義された判断ポイントでアプリケーションの挙動を定義するためにエンドユーザによって使用される。２種類の判断ポイントがある。同期判断ポイントは、アプリケーションが判断ポイントに達し、エンドユーザルールを呼び出す同期イベントを送出する場所である。ルール評価ＡＰＩが、結果のセットを判定する。アプリケーションは、結果に作用し、おそらくその挙動を変更する。非同期判断ポイントは、アプリケーションが判断ポイントに達し、非同期イベントを送出し、「ファイヤーアンドフォゲット（ｆｉｒｅ−ａｎｄ−ｆｏｒｇｅｔ）」の形で処理を継続する場所である。ルールプラットフォームは、適当なルールを評価し、すべての関連する結果を操作させる。
【０１７２】
図１８の構造ブロックに関して、ルールを、ファイルシステムデータモデルのすべての態様に関して記述して、アイテム型ならびに、単純なネステッド要素であるプロパティ、ネステッド要素のマルチセットであるプロパティ、アイテムからの関係のエンドポイント、およびアイテムに対する拡張というアイテム型の態様を含めることができる。ルールは、関係型ならびに、単純なネステッド要素であるプロパティおよびネステッド要素のマルチセットであるプロパティという関係型の態様についても記述することができる。拡張に関して、これらは、本質的にアイテム型のように振る舞う。
【０１７３】
使用可能な関数ブロックに関して、ルールの条件およびアクションは、関数呼出しに似ている。最も一般的な関数は、「＝」などの組み込み演算子である。Ｔ−ＳＱＬ（Ｔｒａｎｓａｃｔ  −  Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）呼出し可能関数のすべてが、条件でサポートされ、クライアント呼出し可能関数のすべてが、アクションでサポートされる。サポートされる関数は、プリミティブデータ型に対するＳＱＬ演算子、組み込みＳＱＬ関数、定量化ＡＮＹ＿ＩＮおよびＡＬＬ＿ＩＮの集合演算子、条件（ＵＤＦとして登録された場合）に関するストア側アセンブリで定義されたＣＬＲメソッド、およびアクションンに関してクライアントアセンブリで定義されたＣＬＲメソッドである。
【０１７４】
コンポジションブロックに関して、ファイルシステムスキーマで定義された「要素」のほかに、ファイルシステムルール代数は、コンポジションをサポートする。ＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔは、条件で使用できるという点で、または別のアタッチメントのスコープとして使用できるという点で、ファーストクラスオブジェクトである。
【０１７５】
コンポジションのもう１つの形に、関数としての強く型付けされた派生されたルールの使用が含まれる。例えば、Ｄｏｃｕｍｅｎｔアイテムを操作する、「ＩｓＩｎｔｅｒｅｓｔｉｎｇ」と呼ばれる１つまたは複数を定義することを検討されたい。次に、条件関数として「ＩｓＩｎｔｅｒｅｓｔｉｎｇ」を使用したルールを作成することができる。
【０１７６】
制御フローブロックに関して、制御フローは、衝突解決ポリシを使用することによってエンドユーザに提供される。これらは、コードの複雑な部分なので、アプリケーション開発者が、これらを構成する。エンドユーザは、使用可能なポリシから選択するだけである。
【０１７７】
追加の制御フローを、ルールプラットフォームの外で手続的に達成することができる。ファイルシステムルールアーキテクチャを、ルールＡＰＩと共に使用することができるので、開発者は、標準的なＣ＃制御フロー構造を使用することができる。
【０１７８】
ルールの豊かさ
図１９を参照すると、本発明のルールアーキテクチャの入力を表す図１９００が示されている。条件およびアクションが入力として作用するデータを参照する。入力の豊かさは、２つの次元すなわち、入力の位置（例えば、ストア内とそれ以外）および入力のカーディナリティ（例えば、シングルトンまたは入力のセット）に分かれる。標準的なシナリオは、次の表に示されている、次の組合せを使用する。
【０１７９】
【表２】
2007537512.tif 000005
【０１８０】
この例では、入力が、ストア内のメッセージアイテムである。ファイルシステムアイテムのほかに、関係のサブミットならびにルールエンジンへの入力としてのＸＭＬ文書の両方について、サポートが提供される。ルール自体は、スカラ値によってパラメータ化され、ルール評価の前に引数が供給されることを必要とする。これらを、ルールパラメータと呼ぶ。
【０１８１】
条件およびアクションのそれぞれが、オペランドを有する。次の例を参照されたい。
【０１８２】
【表３】
2007537512.tif 000006
【０１８３】
条件関数に応じて、オペランドのそれぞれが、スカラ式またはセットのいずれかである。
【０１８４】
スカラ式は、その値がスカラ型である式である。次のスカラ式がサポートされる：定数（例えば、１、「Ｈｅｌｌｏ」）；マルチセットでないアイテム型または関係型のプロパティ（例えば、［Ｄｏｃｕｍｅｎｔ］．Ｔｉｔｌｅを含む、入力のプロパティ、プロパティがネステッドプロパティである場合に、これらもサポートされる；および、セットに対する総計関数。ルールパラメータ（上で説明した）も使用することができる。
【０１８５】
セットベースの総計関数は、アイテムセット、関係、およびネステッド要素のマルチセット（例えば、Ｃｏｕｎｔ、ＭＩＮ、ＭＡＸ、ＳＵＭ、およびＡＶＧ）に関連する。Ｃｏｕｎｔは、その引数セット内のメンバの数のカウントを提供する総計関数である。
【０１８６】
例
【０１８７】
【表４】
2007537512.tif 000007
【０１８８】
ＯＰａｔｈと同一の総計関数のセットがサポートされ、これは、ファイルシステムプラットフォーム全体にまたがる表現可能性の同一のレベルである。
【０１８９】
開発者が定義する総計関数は、このモデルでサポートされる。拡張性も実装することができる。
【０１９０】
ＡＮＹ＿ＩＮなどの一部の演算子は、オペランドとしてセットを有する。セットは、標準的なコレクションまたは派生アイテムセットとして構成することができる。標準ファイルシステムコレクションに、関係およびその関係のソースアイテム（例えば、ＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐおよびＭｙＦｒｉｅｎｄｓ）が含まれる。重要な特殊事例として、入力アイテムは、関係ソース（例えば、Ｍｅｓｓａｇｅ．Ｒｅｃｉｐｉｅｎｔ）または関係ターゲット（例えば、Ｍｅｓｓａｇｅ．ＡｔｔａｃｈｍｅｎｔＯｆ）である。入力アイテム内のネステッド要素のマルチセットとしておよび入力アイテムに対する式のセットとして。
【０１９１】
派生アイテムセットは、１つまたは複数の派生ルールを入力アイテムスコープに関連付けることによって定義される。この関連付けは、ＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔによって取り込まれる。例えば、派生ルールＦｒｉｅｎｄｌｙＰｅｒｓｏｎを、その入力アイテムスコープとしてＭｙＣｏｎｔａｃｔｓにアタッチして、派生アイテムセットＭｙＦｒｉｅｎｄｓを定義する。派生アイテムセットは、入力ソースに完全にバインドすることができ、あるいは、部分的にバインドすることができる。完全にバインドされた派生アイテムセットの内容は、列挙することができる。部分的にバインドされた派生アイテムセットは、評価のために、一部またはすべての入力が供給されることを必要とする。すべての派生ルールが、直接に、部分的にバインドされた派生アイテムセットでもある。これは、評価に入力アイテムスコープを必要とする。例えば、ＦｒｉｅｎｄｌｙＰｅｒｓｏｎは、部分的にバインドされたアイテムセットである。この派生を、条件の中で、入力アイテムに対して実行されるフィルタリング関数と呼ぶことができる。ルールの入力を部分的にのみ定義するＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔは、部分的にバインドされたアイテムセットも定義する。例えば、Ｐｅｏｐｌｅ＿Ｂｙ＿Ｌｏｃａｔｉｏｎは、Ｃｏｎｔａｃｔ入力アイテムおよび入力としての位置の両方を必要とする。これが、入力スコープとしてＭｙＦｒｉｅｎｄｓにアタッチされる場合に、部分的にバインドされた派生アイテムセットＦｒｉｅｎｄｓ＿Ｉｎになる（バインドは、ＭｙＦｒｉｅｎｄｓ入力スコープとＰｅｏｐｌｅ＿Ｂｙ＿Ｌｏｃａｔｉｏｎ派生アイテムセットの間のＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔによって表される）。現在は部分的にバインドされた派生アイテムセットＦｒｉｅｎｄｓ＿Ｉｎを評価するためには、位置を供給する。
【０１９２】
条件の豊かさは、条件への入力と、条件で使用できる関数によって定義される。条件への入力は、前に定義した。条件で許容される関数は、次の通りである：比較演算子＝、＜＞、＞、＜、＜＝、＞＝、ＢＥＴＷＥＥＮ、およびＩＮならびにＬＩＫＥおよびＣＯＮＴＡＩＮＳをサポートするストリングを含む、スカラ式引数を有する標準的な比較条件；ＳｑｌＢｏｏｌｅａｎを返す場合の、入力型に関連するストア側メンバ関数；ＳｑｌＢｏｏｌｅａｎを返す場合の、パラメータとして入力アイテムをとるストア側スタティック関数；およびセットベースの条件。
【０１９３】
次のセットベース条件が、前に説明したＩｔｅｍＳｅｔの柔軟な定義のためにサポートされる。関連アイテムセットの重要なカテゴリが、入力アイテムをソースとするか入力アイテムでターゲットにされる関係によって定義されるカテゴリである。部分的にバインドされた派生アイテムセットは、別々に検討される。
【０１９４】
【表５】
2007537512.tif 000008
【０１９５】
３つのセットベースの条件は、他の２つのフレイバでもサポートされる。部分的にバインドされたターゲットアイテムセット（ＴａｒｇｅｔＩｔｅｍＳｅｔは完全にはバインドされない。完全な入力バインディングを提供するのは、この条件のアイテムセットの使用である）。このクラスの条件は、入力に関係するアイテムセット内のアイテムのプロパティに対する豊かな条件を表すのに使用することができる。例えば、ＩＳＡＮＹ  Ｒｅｃｉｐｉｅｎｔ  Ａ  ＦｒｉｅｎｄｌｙＰｅｒｓｏｎである。このクラスの条件は、ファイルシステム内の他のアイテムセットに対する豊かな「結合」条件を表すのにも使用することができる。例えば、ＩＳＡＮＹ  Ｒｅｃｉｐｉｅｎｔ  ＩＮ  Ｆｒｉｅｎｄｓ＿Ｉｎ（「Ｂｅｌｌｅｖｕｅ」）およびＥＸＩＳＴＳ（Ｅｍａｉｌ＿Ｂｙ＿Ｓｕｂｊｅｃｔ（Ｍｅｓｓａｇｅ．Ｓｕｂｊｅｃｔ））である。
【０１９６】
第２のフレイバ、仮想ターゲット関係セットに関して、入力が関係である（アイテムではなく）時に、セットベースの条件を、関係に対して働くルールによって定義されたターゲットセットと共に使用することができる。入力としてＭｅｓｓａｇｅ．Ｒｅｃｉｐｉｅｎｔ関係を取り、電子メールアドレスがＣｏｍｐａｎｙドメインからであるかどうか、例えばＩＳＡＮＹ  ＲｅｃｉｐｉｅｎｔＲｅｌ  Ａ  ＣｏｍｐａｎｙＡｃｃｏｕｎｔを判定するＣｏｍｐａｎｙＡｃｃｏｕｎｔを仮定する。
【０１９７】
許容される結果のリストは、ＲｕｌｅＣｏｎｓｔｒａｉｎｔから既知である。これらのそれぞれが、名前と、周知の型付けされた引数リストを有する。エンドユーザは、各ルールの結果のセットを選択する。各結果が、名前および引数バインディングによって指定される。引数は、任意のスカラ式にバインドすることができる。さらに、エンドユーザは、次のようの結果のデータ駆動セットを定義することができる。
【０１９８】
【表６】
2007537512.tif 000009
【０１９９】
ＦＯＲＥＡＣＨ構造の中のＲｅｓｕｌｔは、このルールの許容される種類の結果のどれかである。これらの結果に供給されるスカラ引数に、ＦＯＲＥＡＣＨ文節によって指定されるアイテムのプロパティと、ルール入力のプロパティを含めることができる。
【０２００】
これらのルールは、集合的に、ユーザが望む論理機能を定義する。次は、ルールがどのように評価され、衝突解決が制御フロー構造の代替物をエンドユーザにどのように与えるかの説明である。
【０２０１】
ルール実行は、特定の入力アイテムに関して、次の論理セマンティクスを使用する：すべてのルールの条件を評価し、条件が真であるルールについて、結果にまたがって衝突を解決する。入力のセットがある場合に、評価の結果は、単に、その入力スコープ内の各個々のアイテム／関係に対するルール評価の結果の和集合である。複数のアイテムが１つのルールにサブミットされる時の、特別なセマンティクスはない。論理的に、各アイテムが独立に評価される。異なる入力から生じる結果は、絶対に互いに衝突しない。
【０２０２】
衝突解決ポリシは、ルールの表現力の豊かさをもたらす。異なる衝突ポリシがサポートされる。エンドユーザが定義したポリシは、処理停止オプションを有する、ルールへのエンドユーザ優先順位割り当てを容易にする。エンドユーザは、すべてのルールに一意の優先順位を割り当てる。処理停止フラグもセットされる場合に、これは、このルールの条件が真と評価される場合に、それより低い優先順位を有するすべてのルールを無視しなければならないことを示す。開発者が定義するポリシに、結果間優先順位割り当ての機能が含まれ、この場合に、開発者は、すべての結果型に一意の優先順位を指定することができる。潜在的な結果の間で、最高優先順位の結果だけが保持される。さらに、開発者定義のポリシは、結果内集約ベース衝突解決を容易にし、この場合に、開発者は、同一の結果型の結果のセットを操作し、それらを集約する総計関数を指定することができる。
【０２０３】
衝突解決を使用すると、次のルール挙動がサポートされる：処理停止オプションと共に、各ルールに一意のエンドユーザ優先順位を割り当てることによって、ルールステートメントがネストされたＩＦ−ＴＨＥＮ  ＥＬＳＥ（ＩＦ  ＴＨＥＮ  ＥＬＳＥ（．．．））式のように振る舞うことができる；処理停止オプションなしでルール優先順位を使用することによって、ルールステートメントが、ｃａｓｅステートメントにまたがるフォールスルーを有するＣ＋＋ｓｗｉｔｃｈステートメントのように振る舞うことができる；適当な結果内衝突解決ポリシを使用することによって、ルールステートメントが、重複のない和集合セマンティクスおよび交差セマンティクスを提供する；右結果内衝突解決ポリシを使用することによって、ルールステートメントが、投票ベースセマンティクス（少なくとも３つのルールが結果に合意する）を提供することができる；結果間優先順位割り当てによって、ルールステートメントが豊かなクロス結果セマンティクスを提供することができる。
【０２０４】
制約を、ファイルシステムビジネスロジックを介して、条件およびアクションで供給される値に追加することができる。
【０２０５】
条件を、ＬｅａｆＣｏｎｄｉｔｉｏｎネステッド要素型を使用して表すことができる。関数を、ＳｔａｔｉｃＦｕｎｃｔｉｏｎＩｎｆｏおよびＩｎｓｔａｎｃｅＦｕｎｃｔｉｏｎＩｎｆｏを使用して表すことができる。引数を、ＣｏｎｓｔａｎｔＶａｌｕｅ、ＰｒｏｐｅｒｔｙＶａｌｕｅ、ＣｏｌｌｅｃｔｉｏｎＶａｌｕｅ、およびＲｕｌｅＳｅｔＡｔｔａｃｈｍｅｎｔＶａｌｕｅの１つとすることができる。
【０２０６】
結果を、Ａｃｔｉｏｎネステッド要素型を使用して表すことができる。Ａｃｔｉｏｎ要素内の関数および引数は、上で条件について説明したものと同一である。一実施形態で、マルチセットが、ストア内でサポートされる。もう１つの実施形態で、ＬｅａｆＣｏｎｄｉｔｉｏｎおよびＡｃｔｉｏｎが、最大で５つの引数をサポートする。
【０２０７】
図２０を参照すると、開示されるアーキテクチャを実行するように動作可能なコンピュータのブロック図が示されている。本発明の様々な態様の追加の文脈を提供するために、図２０および次の説明は、本発明の様々な態様を実施できる適切なコンピューティング環境２０００の短い一般的な説明を提供することを意図されたものである。本発明を、上で、１つまたは複数のコンピュータで動作することができるコンピュータ実行可能命令の全般的な文脈で説明したが、他のプログラムモジュールと組み合わせて、および／またはハードウェアおよびソフトウェアの組合せとして、本発明を実施できることを、当業者は理解するであろう。
【０２０８】
一般に、プログラムモジュールに、特定のタスクを実行するか、特定の抽象データ型を実施するルーチン、プログラム、コンポーネント、データ構造などが含まれる。さらに、本発明の方法を、単一プロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティング装置、マイクロプロセッサベースまたはプログラマブルなコンシューマ電子機器、および類似物を含む、他のコンピュータシステム構成と共に実践でき、これらのそれぞれを、機能的に１つまたは複数の関連する装置に結合できることを、当業者は了解するであろう。
【０２０９】
本発明の図示された態様は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、ローカルとリモートの両方のメモリストレージ装置に配置することができる。
【０２１０】
コンピュータに、通常は様々なコンピュータ可読媒体が含まれる。コンピュータ可読媒体は、コンピュータによってアクセスできるすべての使用可能な媒体とすることができ、揮発性および不揮発性の媒体、取外し可能および取り外し不能の媒体の両方が含まれる。制限ではなく例として、コンピュータ可読媒体に、コンピュータストレージ媒体と通信媒体を含めることができる。コンピュータストレージ媒体に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージの任意の方法または技術で実施される、揮発性および不揮発性、取外し可能および取り外し不能の両方の媒体が含まれる。コンピュータストレージ媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージ装置、あるいは、所望の情報をストアするのに使用でき、コンピュータによってアクセスできる他のすべての媒体が含まれるが、これに制限はされない。
【０２１１】
通信媒体は、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実施し、すべての情報配布媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれなければならない。
【０２１２】
図２０をもう一度参照すると、本発明の様々な態様を実施する例示的環境２０００に、コンピュータ２００２が含まれ、コンピュータ２００２に、処理装置２００４、システムメモリ２００６、およびシステムバス２００８が含まれる。システムバス２００８は、システムメモリ２００６を含むがこれに制限されないシステムコンポーネントを処理装置２００４に結合する。処理装置２００４は、様々な市販の使用可能なプロセッサのいずれかとすることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも、処理装置２００４として使用することができる。
【０２１３】
システムバス２００８は、複数のタイプのバス構造のいずれかとすることができ、このバス構造は、さらに、様々な商業的に入手可能なバスアーキテクチャのいずれかを使用する、メモリバス（メモリコントローラ付きまたはなし）、周辺バス、およびローカルバスに相互接続することができる。システムメモリ２００６に、読取専用メモリ（ＲＯＭ）２０１０およびランダムアクセスメモリ（ＲＡＭ）２０１２が含まれる。基本入出力システム（ＢＩＯＳ）が、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ２０１０にストアされ、ＢＩＯＳには、スタートアップ中などにコンピュータ２００２内の要素の間で情報を転送するのを助ける基本ルーチンが含まれる。ＲＡＭ  ２０１２に、データをキャッシングするスタティックＲＡＭなどの高速ＲＡＭも含めることができる。
【０２１４】
コンピュータ２００２に、さらに、適当なシャーシ（図示せず）内での外部使用のために構成することもできる内蔵ハードディスクドライブ（ＨＤＤ）２０１４（例えば、ＥＩＤＥ、ＳＡＴＡ）、磁気フロッピディスクドライブ（ＦＤＤ）２０１６（例えば、取外し可能ディスケット２０１８から読み取るかこれに書き込む）、および光学ディスクドライブ２０２０（例えば、ＣＤ−ＲＯＭディスク２０２２を読み取るか、ＤＶＤなどの他の大容量光学媒体から読み取るかこれに書き込む）が含まれる。ハードディスクドライブ２０１４、磁気ディスクドライブ２０１６、および光学ディスクドライブ２０２０は、それぞれ、ハードディスクドライブインターフェース２０２４、磁気ディスクドライブインターフェース２０２６、および光学ドライブインターフェース２０２８によってシステムバス２００８に接続することができる。外部ドライブ実施形態用のインターフェース２０２４に、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）インターフェーステクノロジおよびＩＥＥＥ  １３９４インターフェーステクノロジの少なくとも１つまたは両方が含まれる。
【０２１５】
ドライブおよびそれに関連するコンピュータ可読媒体は、データ、データ構造、コンピュータ実行可能命令などの不揮発性ストレージを提供する。コンピュータ２００２に関して、ドライブおよび媒体は、適当なデジタルフォーマットでのすべてのデータのストレージに対処する。上のコンピュータ可読媒体の説明で、ＨＤＤ、取外し可能磁気ディスケット、およびＣＤまたはＤＶＤなどの取外し可能光学媒体に言及したが、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジ、および類似物などのコンピュータによって可読の他のタイプの媒体も、例示的なオペレーティング環境で使用することができることと、さらに、そのようなすべての媒体に、本発明の方法を実行するコンピュータ実行可能命令を含めることができることを、当業者は了解するであろう。
【０２１６】
オペレーティングシステム２０３０、１つまたは複数のアプリケーションプログラム２０３２、他のプログラムモジュール２０３４、およびプログラムデータ２０３６を含む複数のプログラムモジュールを、ドライブおよびＲＡＭ  ２０１２にストアすることができる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータのすべてまたは一部を、ＲＡＭ  ２０１２にキャッシングすることもできる。
【０２１７】
本発明を、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実施できることを了解されたい。
【０２１８】
ユーザは、例えばキーボード２０３８、およびマウス２０４０などのポインティング装置などの１つまたは複数の有線／無線入力装置を介してコンピュータ２００２にコマンドおよび情報を入力することができる。他の入力装置（図示せず）に、マイクロホン、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーン、および類似物を含めることができる。上記および他の入力装置は、しばしば、システムバス２００８に結合された入力装置インターフェース２０４２を介して処理装置２００４に接続されるが、パラレルポート、ＩＥＥＥ  １３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどの他のインターフェースによって接続することができる。
【０２１９】
モニタ２０４４または他のタイプのディスプレイ装置も、ビデオアダプタ２０４６などのインターフェースを介してシステムバス２００８に接続される。モニタ２０４４のほかに、コンピュータに、通常はスピーカ、プリンタなど、他の周辺出力装置（図示せず）が含まれる。
【０２２０】
コンピュータ２００２は、リモートコンピュータ２０４８など、１つまたは複数のリモートコンピュータへの有線接続および／または無線接続を介する論理接続を使用してネットワーク化された環境で動作することができる。リモートコンピュータ２０４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースのエンターテイメントアプライアンス、ピア装置、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ２００２に関して説明した要素の多数またはすべてが含まれるが、図を簡単にするために、メモリストレージ装置２０５０だけを図示した。図示の論理接続には、ローカルエリアネットワーク（ＬＡＮ）２０５２および／またはより大きいネットワーク、例えば広域ネットワーク（ＷＡＮ）２０５４などのより大きいネットワークへの有線／無線接続性が含まれる。そのようなＬＡＮおよびＷＡＮのネットワーキング環境は、オフィス、会社などでありふれており、イントラネットなどの会社全体のコンピュータネットワークを容易にし、これらのすべてを、インターネットなどのグローバル通信ネットワークに接続することができる。
【０２２１】
ＬＡＮネットワーキング環境で使用される時に、コンピュータ２００２は、有線および／または無線の通信ネットワークインターフェースまたはアダプタ２０５６を介してローカルエリアネットワーク２０５２に接続される。アダプタ２０５６は、ＬＡＮ  ２０５２への有線接続または無線接続を容易にし、ＬＡＮ  ２０５２には、無線アダプタ２０５６と通信するために配置された無線アクセスポイントも含めることができる。ＷＡＮネットワーキング環境で使用される時に、コンピュータ２００２は、モデム２０５８を含むことができ、あるいはＬＡＮ上の通信サーバに接続され、あるいはインターネットによるなどＷＡＮ  ２０５４を介する通信を確立する他の手段を有する。モデム２０５８は、内蔵または外付けの有線装置または無線装置とすることができるが、シリアルポートインターフェース２０４２を介してシステムバス２００８に接続される。ネットワーク化された環境では、コンピュータ２００２に関して図示されたプログラムモジュールまたはその一部を、リモートメモリ／ストレージ装置２０５０にストアすることができる。図示のネットワーク接続が例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることを了解されたい。
【０２２２】
コンピュータ２００２は、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、携帯情報端末、通信衛星、および無線で検出可能なタグに関連する機器または位置（例えば、キオスク、ニューススタンド、トイレなど）および電話機など、無線通信に機能的に配置された無線装置またはエンティティと通信するように動作する。これには、少なくともＷｉ−Ｆｉ無線テクノロジおよびＢｌｕｅｔｏｏｔｈ（商標）無線テクノロジが含まれる。したがって、通信は、従来のネットワークのように事前定義の構造とするか、単に少なくとも２つの装置の間のアドホック通信とすることができる。
【０２２３】
Ｗｉ−ＦｉまたはＷｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙは、家庭の寝椅子、ホテルのベッド、仕事場の会議室などからワイヤなしでのインターネットへの接続を可能にする。Ｗｉ−Ｆｉは、コンピュータなどの装置が室内および戸外で、基地局からの範囲内の任意の場所でデータを送受信できるようにする、セル電話機に似た無線テクノロジである。Ｗｉ−Ｆｉネットワークは、ＩＥＥＥ  ８０２．１１（ａ、ｂ、ｇなど）と称するラジオテクノロジを使用して、セキュアで信頼性があり高速の無線接続性を提供する。Ｗｉ−Ｆｉネットワークは、他のコンピュータに、インターネットに、および有線ネットワークに（ＩＥＥＥ  ８０２．３またはイーサネット（登録商標）を使用する）コンピュータを接続するのに使用することができる。Ｗｉ−Ｆｉネットワークは、免許不要の２．４ＧＨｚおよび５ＧＨｚラジオ帯域で、１１Ｍｂｐｓ（８０２．１１ａ）または５４Ｍｂｐｓ（８０２．１１ｂ）のデータレートあるいは両方の帯域を含む製品（デュアルバンド）で動作し、したがって、このネットワークは、多数のオフィスで使用される基本的な１０ＢａｓｅＴ有線イーサネット（登録商標）ネットワークに似た実世界の性能を提供することができる。
【０２２４】
図２１を参照すると、本発明による例示的コンピューティング環境２１００を示す概略ブロック図が示されている。システム２１００に、１つまたは複数のクライアント２１０２が含まれる。クライアント２１０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）とすることができる。クライアント２１０２は、例えば、本発明を使用することによって、クッキーおよび／または関連するコンテキスト情報を収容することができる。システム２２００に、１つまたは複数のサーバ２１０４も含まれる。サーバ２１０４も、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）とすることができる。サーバ２１０４は、例えば、本発明を使用することによって、変換を実行するスレッドを収容することができる。クライアント２１０２とサーバ２１０４の間の可能な通信の１つを、複数のコンピュータプロセスの間で伝送されるように適合されたデータパケットの形とすることができる。データパケットには、例えば、クッキーおよび／または関連するコンテキスト情報を含めることができる。システム２１００に、クライアント２１０２とサーバ２１０４の間の通信を容易にするのに使用することができる通信フレームワーク２１０６（例えば、インターネットなどのグローバル通信ネットワーク）が含まれる。
【０２２５】
通信を、有線テクノロジ（光ファイバを含む）および／または無線テクノロジを介して容易にすることができる。クライアント２１０２は、クライアント２１０２にローカルな情報（例えば、クッキーおよび／または関連するコンテキスト情報）をストアするのに使用できる１つまたは複数のクライアントデータストレージ２１０８に機能的に接続される。同様に、サーバ２１０４は、サーバ２１０４にローカルな情報をストアするのに使用することができる１つまたは複数のサーバデータストア２１１０に機能的に接続される。
【０２２６】
上で説明したものに、本発明の例が含まれる。もちろん、本発明を説明するためにコンポーネントおよび方法論の考えられるすべての組合せを記述することは可能ではないが、当業者は、本発明の多数のさらなる組合せおよび置換が可能であることを了解するであろう。したがって、本発明は、請求項の趣旨および範囲に含まれるそのような変更、修正、および変形のすべてを含むことが意図されている。さらに、用語「ｉｎｃｌｕｄｅｓ」が詳細な説明または請求項のいずれかで使用される範囲まで、そのような単語は、請求項で前後を接続する単語として使用される時に用語「ｃｏｍｐｒｉｓｉｎｇ」が解釈されるのと同一の形で包含的であることが意図されている。
【図面の簡単な説明】
【０２２７】
【図１】本発明のルールアーキテクチャによるエンドユーザデータ自動化および管理を容易にするシステムを示す図である。
【図２】本発明のルールアーキテクチャによる図式化の１つの方法論を示す図である。
【図３】本発明のルールアーキテクチャによるデータ派生の１つの方法論を示す図である。
【図４】本発明のルールアーキテクチャによる副作用を有するロジックのトリガードアクティブ化の１つの方法論を示す図である。
【図５】本発明のルールアーキテクチャによるデータ制約の１つの方法論を示す図である。
【図６】本発明のルールアーキテクチャによる判断ポイントでのアプリケーションカスタマイゼーションの提供の１つの方法論を示す図である。
【図７】本発明のルールアーキテクチャのアイテム型およびその関係を示す図である。
【図８】本発明のルールアーキテクチャによる条件および結果処理を示す図である。
【図９Ａ】本発明によるルールの一般的なフォーマットを示す図である。
【図９Ｂ】本発明によるアクティブルールの一般的なルールフォーマットを示す図である。
【図９Ｃ】本発明によるアプリケーションカスタマイゼーションルールの一般的なルールフォーマットを示す図である。
【図９Ｄ】本発明によるデータ派生ルールの一般的なルールフォーマットを示す図である。
【図９Ｅ】本発明によるデータ制約ルールの一般的なルールフォーマットを示す図である。
【図１０】本発明のルールアーキテクチャによる入力アイテムのコレクションにルールをアタッチすることによるルールの適用の１つの方法論を示す図である。
【図１１】本発明のルールアーキテクチャによる判断ポイントにルールをアタッチすることによるルールの適用のもう１つの方法論を示す図である。
【図１２】本発明のルールアーキテクチャによるルールを直接に呼び出すことによるルールの適用のもう１つの方法論を示す図である。
【図１３】本発明のルールアーキテクチャによるルールの適用のもう１つの方法論を示す図である。
【図１４】本発明によるルール衝突解決の１つの方法論を示す図である。
【図１５】本発明のルールアーキテクチャによるアイテム型および関連する関係を示す図である。
【図１６Ａ】本発明のＥｖａｌｕａｔｉｏｎＲｅｓｕｌｔＥｌｅｍｅｎｔネステッド型を示す図である。
【図１６Ｂ】本発明のＩｎｐｕｔＳｃｏｐｅネステッド型およびその派生物を示す図である。
【図１６Ｃ】本発明のＬｏｇｉｃＣｏｎｓｔｒａｉｎｔネステッド型を示す図である。ＬｏｇｉｃＣｏｎｓｔｒａｉｎｔは、ＲｕｌｅＬｏｇｉｃ（および子）とＤｅｃｉｓｉｏｎＰｏｉｎｔの両方によって使用される。
【図１６Ｄ】本発明のＬｏｇｉｃＳｔａｔｅｍｅｎｔネステッド型を示す図である。ＬｏｇｉｃＳｔａｔｅｍｅｎｔｓは、条件ツリーおよび結果のセット（アクションまたはＢｏｏｌｅａｎ）をエンコードする。
【図１６Ｅ】本発明のＬｏｇｉｃＲｅｓｕｌｔネステッド型およびその派生物を示す図である。
【図１６Ｆ】本発明のＣｏｎｄｉｔｉｏｎネステッド型およびその派生物を示す図である。
【図１６Ｇ】本発明のＡｒｇｕｍｅｎｔＶａｌｕｅネステッド型およびその派生物を示す図である。
【図１６Ｈ】本発明のＦｕｎｃｔｉｏｎＩｎｆｏネステッド型およびその派生物を示す図である。
【図１７】本発明によるルールエンジンを示す図である。
【図１８】本発明のルールアーキテクチャでの豊かさの次元を示すブロック図である。
【図１９】本発明のルールアーキテクチャの入力を示す図である。
【図２０】開示されるアーキテクチャを実行するように動作可能なコンピュータを示すブロック図である。
【図２１】本発明による例示的なコンピューティング環境を示す概略ブロック図である。
【図１】
2007537512.tif 000010
【図２】
2007537512.tif 000011
【図３】
2007537512.tif 000012
【図４】
2007537512.tif 000013
【図５】
2007537512.tif 000014
【図６】
2007537512.tif 000015
【図７】
2007537512.tif 000016
【図８】
2007537512.tif 000017
【図９Ａ】
2007537512.tif 000018
【図９Ｂ】
2007537512.tif 000019
【図９Ｃ】
2007537512.tif 000020
【図９Ｄ】
2007537512.tif 000021
【図９Ｅ】
2007537512.tif 000022
【図１０】
2007537512.tif 000023
【図１１】
2007537512.tif 000024
【図１２】
2007537512.tif 000025
【図１３】
2007537512.tif 000026
【図１４】
2007537512.tif 000027
【図１５】
2007537512.tif 000028
【図１６Ａ】
2007537512.tif 000029
【図１６Ｂ】
2007537512.tif 000030
【図１６Ｃ】
2007537512.tif 000031
【図１６Ｄ】
2007537512.tif 000032
【図１６Ｅ】
2007537512.tif 000033
【図１６Ｆ】
2007537512.tif 000034
【図１６Ｇ】
2007537512.tif 000035
【図１６Ｈ】
2007537512.tif 000036
【図１７】
2007537512.tif 000037
【図１８】
2007537512.tif 000038
【図１９】
2007537512.tif 000039
【図２０】
2007537512.tif 000040
【図２１】
2007537512.tif 000041