"プロセッサ、メモリ、ディスプレイ、およびユーザー入力デバイスを有するコンピュータを、コンテンツの利用権利に対する要求に応答して制御するための方法であって、a前記メモリ内に複数の権利レコードを格納するステップであって、それぞれの権利レコードがコンテンツ利用の所定のタイプに対する権利を表す、ステップと、b前記メモリ内に複数の表示ルールレコードを格納するステップであって、それぞれの表示ルールレコードは、コンテンツ利用のタイプにリンクされ、少なくとも1つの所定のパラメータの入力を求めるように前記ディスプレイを制御するため、および前記パラメータに対する値を表す入力を前記入力デバイスから受け取るためのプログラムコードを有する、ステップと、c前記メモリ内に複数の権利ルールレコードを格納するステップであって、それぞれの権利ルールレコードは、権利レコードにリンクされ、前記リンクされた権利を付与するかどうかを決定すること、前記権利に対する価格を決定すること、および前記権利に対する印税を決定することのうちの1つを実行する、ステップと、dルールエンジンプログラムを備える前記プロセッサを、要求されたコンテンツ利用について表示ルールレコードを選択し、その中にあるプログラムコードを実行してパラメータ値を取得し、選択された権利にリンクされている権利ルールレコード内のプログラムコードを実行し、前記取得されたパラメータ値に基づいて、前記権利を付与すべきかどうか、前記権利に対する前記価格、および前記権利に対する前記印税を決定し、その後、該当する場合に、複数の有効な権利のうちから単一の権利を選択するように制御するステップとを含むことを特徴とする方法。ステップdは、前記ルールエンジンプログラムの制御の下で、前記プロセッサにより、要求されたコンテンツユーザーのタイプおよびコンテンツ著作物を含む要求オブジェクト、前記コンテンツ利用のタイプに適用されると決定された権利、前記要求の状態、前記入力デバイスから受け取ったパラメータ値、および権利ルールの結果を生成することをさらに含むことを特徴とする請求項1に記載の方法。前記要求オブジェクトは、前記権利ルールレコードのそれぞれの中のプログラムコードへの入力として与えられることを特徴とする請求項2に記載の方法。前記メモリ内に複数のパラメータレコードを格納するステップであって、それぞれのパラメータレコードが所定のパラメータ値を定義する、ステップと、パラメータレコードを権利ルールレコードにリンクするステップであって、権利ルールレコード内のプログラムコードが実行されたときに前記実行プログラムコードによって必要とされるパラメータ値が前記リンクされたパラメータレコードによって事前定義される、ステップをさらに含むことを特徴とする請求項1に記載の方法。前記メモリ内に複数の妥当性確認ルールレコードを格納するステップであって、それぞれの妥当性確認ルールレコードは、前記ユーザー入力デバイスから受け取った情報の妥当性確認を行うためのプログラムコードを含む、ステップと、それぞれの妥当性確認ルールレコードを前記パラメータレコードのうちの1つにリンクするステップをさらに含むことを特徴とする請求項4に記載の方法。ステップcは、前記メモリ内に複数の前処理ルールレコードを格納することであって、それぞれの前処理ルールレコードがルールレコードにリンクされ、前記ユーザー入力デバイスから情報を受け取る前に、前記権利を付与すべきかどうかを決定するために必要な情報を取得するためのプログラムコードを含む、ことを含むことを特徴とする請求項1に記載の方法。ステップcは、前記メモリ内に複数の後処理ルールレコードを格納することであって、それぞれの後処理ルールレコードがルールレコードにリンクされ、所定の方法で前記ルールレコード内のプログラムコードによって生成された出力を修正するためのプログラムコードを含む、ことを含むことを特徴とする請求項1に記載の方法。前記メモリ内に複数の解決ルールレコードを格納するステップであって、それぞれの解決ルールレコードが前記要求されたコンテンツ利用に適用可能であると判定された権利を表す複数の権利レコードから1つの権利レコードを選択するためのプログラムコードを含む、ステップをさらに含むことを特徴とする請求項1に記載の方法。ステップdは、前記ルールエンジンプログラムで前記プロセッサを、権利を付与すべきかどうかを決定した後、および選択された権利に対する価格を計算する前に、少なくとも1つの解決ルールレコード内のプログラムコードを実行するように制御すること含むことを特徴とする請求項8に記載の方法。それぞれのルールレコード内のプログラムコードは、編集が行われるときに、コンパイルされ格納されることを特徴とする請求項1に記載の方法。ステップdの前に、それぞれのルールレコード内のプログラムコードは、前記メモリから取り出され、インスタンス化され、その結果得られる実行コードは、前記メモリ内にキャッシュされ、そうして、ステップdにおいて、前記ルールエンジンが前記実行コードを実行することを特徴とする請求項1に記載の方法。それぞれの権利レコード、それぞれの権利ルールレコード、およびそれぞれの表示ルールレコードは、バージョン情報を含み、取得されたパラメータ値は、前記メモリ内に格納され、これにより、ステップdを実行し、同じ決定で後日繰り返すことができることを特徴とする請求項1に記載の方法。取得されたパラメータ値は、前記メモリ内の要求オブジェクト内に格納され、前記要求オブジェクトは、ステップdにおいて、前記選択された権利にリンクされている権利ルールレコードに供給され、これにより、すべての取得されたパラメータ値が前記選択された権利にリンクされている前記権利ルールレコードに利用可能になることを特徴とする請求項1に記載の方法。ステップdにおいて、選択された表示ルールレコードにおいて実行されるプログラムコードは、前記選択された表示ルール内に格納されている表示行値および前記選択された表示ルールにリンクされているパラメータテーブル内に格納されている表示パラメータ属性を介して前記ディスプレイを制御することを特徴とする請求項1に記載の方法。それぞれの表示ルールおよびそれぞれの権利ルールは、それぞれのルールに関連付けられているプログラムコード内で使用することができる複数の関数を含む基底ルールクラスのサブクラスであることを特徴とする請求項1に記載の方法。コンテンツの利用権利に対する要求に応答するための装置であって、プロセッサ、メモリ、ディスプレイ、およびユーザー入力デバイスを有するコンピュータを備え、前記メモリ内に複数の権利レコードを格納し、それぞれの権利レコードがコンテンツ利用の所定のタイプに対する権利を表し、前記メモリ内に複数の表示ルールレコードを格納し、それぞれの表示ルールレコードはコンテンツ利用のタイプにリンクされ、少なくとも1つの所定のパラメータの入力を求めるように前記ディスプレイを制御し、前記パラメータに対する値を表す入力を前記入力デバイスから受け取るためのプログラムコードを有し、前記メモリ内に複数の権利ルールレコードを格納し、それぞれの権利ルールレコードは権利レコードにリンクされ、前記リンクされた権利を付与するかどうかを決定すること、前記権利に対する価格を決定すること、および前記権利に対する印税を決定することのうちの1つを実行し、ルールエンジンプログラムを実行して、要求されたコンテンツ利用について表示ルールレコードを選択し、その中にあるプログラムコードを実行してパラメータ値を取得し、前記選択された権利にリンクされている権利ルールレコード内のプログラムコードを実行し、前記取得されたパラメータ値に基づいて、前記権利を付与すべきかどうか、前記権利に対する前記価格、および前記権利に対する前記印税を決定し、その後、該当する場合に、複数の有効な権利のうちから単一の権利を選択するように前記プロセッサを制御する前記メモリ内に格納されているプログラムコードをさらに備えることを特徴とする装置。前記ルールエンジンプログラムは、前記メモリ内で、要求されたコンテンツ利用のタイプおよびコンテンツ著作物を含む要求オブジェクト、前記コンテンツ利用のタイプに適用されると決定された権利、前記要求の状態、前記入力デバイスから受け取ったパラメータ値、および権利ルールの結果を生成するように前記プロセッサを制御することを特徴とする請求項16に記載の装置。前記要求オブジェクトは、前記権利ルールレコードのそれぞれの中のプログラムコードへの入力として与えられることを特徴とする請求項17に記載の装置。前記メモリ内に複数のパラメータレコードを格納し、それぞれのパラメータレコードが所定のパラメータ値を定義するように、また権利ルールレコード内のプログラムコードが実行されたときに前記実行プログラムコードによって必要とされるパラメータ値が前記リンクされたパラメータレコードによって事前定義されるようにパラメータレコードを権利ルールレコードにリンクするように前記プロセッサを制御するプログラムコードをさらに備えることを特徴とする請求項16に記載の装置。前記メモリ内に複数の妥当性確認ルールレコードを格納し、それぞれの妥当性確認ルールレコードが前記ユーザー入力デバイスから受け取った情報の妥当性確認を行うためのプログラムコードを含むように、またそれぞれの妥当性確認ルールレコードを前記パラメータレコードのうちの1つにリンクするように前記プロセッサを制御するプログラムコードをさらに備えることを特徴とする請求項19に記載の装置。前記メモリ内に複数の権利ルールレコードを格納するように前記プロセッサを制御する前記プログラムコードは、前記メモリ内に複数の前処理ルールレコードを格納し、それぞれの前処理ルールレコードがルールレコードにリンクされ、前記ユーザー入力デバイスから情報を受け取る前に、前記権利を付与すべきかどうかを決定するために必要な情報を取得するためのプログラムコードを含むように前記プロセッサを制御するプログラムコードを含むことを特徴とする請求項16に記載の装置。前記メモリ内に複数の権利ルールレコードを格納するように前記プロセッサを制御する前記プログラムコードは、前記メモリ内に複数の後処理ルールレコードを格納し、それぞれの後処理ルールレコードがルールレコードにリンクされ、所定の方法で前記ルールレコード内のプログラムコードによって生成された出力を修正するためのプログラムコードを含むように前記プロセッサを制御するプログラムコードを含むことを特徴とする請求項16に記載の装置。前記メモリ内に複数の解決ルールレコードを格納し、それぞれの解決ルールレコードが前記要求されたコンテンツ利用に適用可能であると判定された権利を表す複数の権利レコードから1つの権利レコードを選択するためのプログラムコードを含むように前記プロセッサを制御する前記メモリ内に格納されているプログラムコードをさらに備えることを特徴とする請求項16に記載の装置。前記ルールエンジンプログラムは、前記プロセッサを、権利を付与すべきかどうかを決定した後、および選択された権利に対する価格を計算する前に、少なくとも1つの解決ルールレコード内のプログラムコードを実行するように制御することを特徴とする請求項23に記載の装置。それぞれのルールレコード内のプログラムコードは、編集が行われるときに、コンパイルされ格納されることを特徴とする請求項16に記載の装置。前記ルールエンジンコードの制御の下での前記プロセッサによる実行の前に、それぞれのルールレコード内のプログラムコードは、前記メモリから取り出され、インスタンス化され、その結果得られる実行コードは、前記メモリ内にキャッシュされ、そうして、前記ルールエンジンコードが前記実行コードを実行することを特徴とする請求項16に記載の装置。それぞれの権利レコード、それぞれの権利ルールレコード、およびそれぞれの表示ルールレコードは、バージョン情報を含み、取得されたパラメータ値は、前記メモリ内に格納され、これにより、前記プロセッサは前記ルールエンジンコードを実行して前記権利を付与すべきかどうか、前記権利に対する前記価格、および前記権利に対する前記印税を決定することができ、次いで前記ルールエンジンコードを後日再実行してその結果同じ決定を行うことができることを特徴とする請求項16に記載の装置。取得されたパラメータ値は、前記メモリ内の要求オブジェクト内に格納され、前記要求オブジェクトは、前記ルールエンジンコードによって、前記選択された権利にリンクされている権利ルールレコードに供給され、これにより、すべての取得されたパラメータ値が前記選択された権利にリンクされている前記権利ルールレコードに利用可能になることを特徴とする請求項16に記載の装置。前記ルールエンジンコードは前記プロセッサを、前記選択された表示ルール内に格納されている表示行値および前記選択された表示ルールにリンクされているパラメータテーブル内に格納されている表示パラメータ属性を介して前記ディスプレイを制御する選択された表示ルールレコード内のプログラムコードを実行するように制御することを特徴とする請求項16に記載の装置。それぞれの表示ルールおよびそれぞれの権利ルールは、それぞれのルールに関連付けられているプログラムコード内で使用することができる複数の関数を含む基底ルールクラスのサブクラスであることを特徴とする請求項16に記載の装置。図1においてブロック図式的に示されているように、ルールデータベース100に格納されている複数のルールは、権利の要求を許諾できるかどうか、要求者によってどのような価格が支払われるべきか、および権利者に印税をどれだけ支払うべきかを決定することに関してルールエンジン106を制御する。表示ルールの制御の下で、ルールエンジン106は、要求された決定を行うために必要なパラメータ値の入力を要求者に求めるグラフィカルユーザーインターフェイスをディスプレイ110上に構成する。他のルールは、入力デバイス108を介して要求者からパラメータ値を受け取り、受け取った値の妥当性を確認する。他のルールは、必要な計算を実行し、ディスプレイ110上のグラフィカルユーザーインターフェイスを介して結果を要求者に表示する。入力デバイス108およびディスプレイ110は、図1に、ルールエンジン106に直接接続されているように示されているけれども、デバイス108およびディスプレイ110は、ブラウザプログラムおよびインターネット図示せずを介して、サーバーにおいて動作しているルールエンジン106と通信するリモートコンピュータの一部とすることも可能である。この場合、グラフィカルユーザーインターフェイスは、ブラウザによって表示され、入力デバイスは、マウスおよびキーボードとすることが可能である。このような配置構成は、当業者によく知られている。ルールデータベース100内の情報の配置構成は、図2A~2Cに示されており、13個の関係するテーブル200~224からなる。それぞれのテーブルは、プライマリーキー、つまりユニークキーを含み、外部キーまたは他の情報を含むことができる。例えば、type-of-useTOUテーブル200は、プライマリーキーフィールドtou_id、外部キーフィールドcust_id、ならびにname、description、およびdisplay_sequenceなどの他の情報フィールドを含む。当業者によく知られているように、第1のテーブルは第1のテーブルのプライマリーキーを外部キーとして第2のテーブルに入れることによって第2のテーブルに関係付けることができる。これらの関係は、図2A~2Cに、テーブル同士を接続する直線によって示されている。この直線のフォーク型端部は、多関係、つまり、フォーク型端部が付いているテーブル内に多数の外部キーフィールドのエントリがあることを示している。したがって、単一の端部とフォーク型の端部を持つ直線は、1対多の関係を示す。テーブル206などのいくつかのテーブルは、2つのテーブルからの外部キーを含むリンクテーブルである。例えば、リンクテーブル206は、touテーブル200およびルールテーブル212からの外部キーを含む。リンクテーブル206は、ルールテーブル212との1対1の関係を有するが、touテーブル200とは1対多の関係を有する。したがって、異なるtou_idエントリを有し、同じrule_idエントリを有するリンクテーブル206内には多数のエントリがありうる。図3は、ルールデータベースを構成するプロセスを示している。このプロセスはステップ300から始まり、ステップ302に進み、そこで、利用のタイプのレコードを定義し、格納する。一般に、利用のタイプは、定義済みのアクションである。組織のメンバーによる出版物に対する例示的な一組の定義済みの利用のタイプとして、1出版物のコピーを組織のメンバーに電子メールで送ること、2出版物のコピーを組織のメンバーでない人に電子メールで送ること、3出版物のコピーをローカルのハードドライブ上に格納すること、4出版物のコピーを共有ネットワークドライブ上に格納すること、5出版物のコピーをスキャンし、組織のメンバーに電子メールで送ること、6出版物のコピーをスキャンし、組織のメンバーでない人に電子メールで送ること、7コピー機で出版物をコピーし、それを組織のメンバーと共有すること、8コピー機で出版物をコピーし、それを組織のメンバーでない人と共有すること、9出版物の印刷したコピーを組織のメンバーと共有すること、10出版物の印刷したコピーを組織のメンバーでない人と共有すること、11LotusNotes商標を使用して出版物のコピーを共有すること、12出版物のコピーをインターネットサイトにアップロードすること、13広告目的で出版物のコピーを投稿すること、および14出版物のコピーを電子ペーパーソフトビルボードにアップロードすることが挙げられる。それぞれの利用のタイプは、touテーブル200内に個別のレコードとして格納される。利用のタイプは、子の利用のタイプを含むこともでき、子の利用のタイプは、複数の親の利用のタイプの下で存在しうる。親の利用のタイプに関連付けられている権利は、子に自動的に適用される。可能ならば、権利を親の利用のタイプに割り当てると最も都合がよく、これにより、それぞれの個別の子レベルで割り当てを行う必要がなくなる。いくつかの場合において、権利者は、低いまたはより粒度の細かいレベルでのみ許可を付与している可能性があり、したがって、子の利用のタイプを個別に構成する必要がある。例えば、コピー機によるコピーの親権利は、コピー機による内部コピー、コピー機による外部コピー、コピー機による図書館保存用のコピー、またはポスター表示のためのコピー機によるコピーの子権利を含みうる。すべての権利が適用される場合、それらをコピー機によるコピーの親レベルで構成すると都合がよい。コピー機による内部コピーなどの部分集合のみが適用される場合、子レベルでルールを構成する必要がある。親-子関係は、tou_tou_relationテーブル204内に格納され、これにより、多対多関係を格納することができる。図3に戻り、ステップ304において、パラメータを定義し、格納する。パラメータは、ルールまたは権利要求のいずれかに関連付けられたデータである。例えば、ルールに関連付けられているパラメータは、ページ毎の料金とすることも可能である一方、要求に関連付けられているパラメータは、要求されたページの数とすることが可能である。パラメータ定義は、名前値ルールまたは権利要求でパラメータを参照することを可能にする、ラベル値グラフィカルユーザーインターフェイスにおいてパラメータを識別する、利用コードそのパラメータが権利または権利要求定義の範囲内で使用されるか、またはルールの定義の一部である参照パラメータであるかどうかを示す。あるいは、参照パラメータをルールコードの本文部の中に置くことも可能であるが、その場合、それらは他のルールで読み取ることは可能でない、フィールド長入力情報の最大文字数を示す、表示幅グラフィカルユーザーインターフェイスにパラメータを表示するコントロールの幅に対するデフォルトのピクセル値を示す、エンティティタイプパラメータが接続されるエンティティを示す。ルールのエンティティタイプは、最も頻繁にあるものであるが、パラメータは著作物または権利者にも接続することが可能であるを含む、パラメータを定義する複数の値を含む。追加のパラメータ定義値は、データ型文字列型、整数型、数値型、日付型、論理型、CLOB型キャラクターラージオブジェクト、またはテーブルなどの複合データ型、およびデフォルト値これにより、そのパラメータに対するコントロールを表示する際に初期値を表示することができる、およびパラメータが表示されるデフォルトのシーケンスを示す表示シーケンスを含む。これらの値は、図2Bに示されているパラメータテーブル216内の対応するフィールドに格納される。それに加えて、パラメータは標準値というオプションの概念を有し、これにより、パラメータが表示されるときにドロップダウンリストコントロール内に所定の値を提示することができる。標準値は、図2Cに示されている標準値テーブル224に格納され、パラメータIDをパラメータ値テーブル内のparm_idフィールドに入れることによってパラメータに関係付けられる。ステップ306では、ルールを定義し、格納する。ルールは、所定のタスクを実行するための統制されたフレームワークの一部として実行されるソフトウェアコードの一ブロックである。ルールは、権利にリンクし、これにより、権利の利用可能性、オファーの性質価格、そのオファーの結果として支払うべき印税コストの条件を決める。権利の利用可能性は、要求者のタイプまたはロケーションおよび制限ルール例えば、制限ルールで、使用量を5ページ以下に制限することが可能であるなどの境界パラメータの組合せによって決定される。価格設定ルールは、要求から取り出したパラメータから要求された権利について提供される価格を計算するために、許諾決定を下したときに実行される。印税ルールは、権利者に支払うべき印税を計算するために、計算された価格が支払われているときに実行され、特別注文ルールは、特別注文を処理するために実行される。いくつかの場合において、複数の権利者が、単一の権利に関連付けられている。このような場合、価格設定ルールを、単一の全体的価格設定ルールとして、または権利者毎価格が足し合わされるに割り当てることができ、または印税ルールを権利者毎に割り当てることができる。それに加えて、制限ルールは、全体的に、または権利者毎に割り当てることができる。それぞれのルールタイプは、計算を実行し、ルールの結果を表す1つまたは複数のルール解決を返す。例えば、制限ルールは、制限到達フラグと制限メッセージを含むLimitRuleResolutionを返す。複数の制限ルールを1つの権利にリンクすることができ、制限に達した場合に、その権利は利用不可能になる。同様に、価格設定ルールは、価格タイプ、価格、メッセージタイプ、およびユーザーに表示するメッセージを含むPricingRuleResolutionのリストを返す。価格設定計算では複数の価格が返される可能性がある例えば、価格、サービス料金、外貨による価格など。印税ルールは、価格タイプ、価格、メッセージタイプ、およびメッセージを含むRoyaltyRuleResolutionのリストを返す。特別注文ルールでは、特別注文を処理する仕方を記述し、特別注文の有効なフラグ、メッセージタイプ、およびメッセージを含む特別注文解決を返す。それに加えて、本発明のシステムでは、処理ルールは、要求プロシージャおよび権利の解決を制御する。この後者のルールは、必要な情報を収集するためにグラフィカルユーザーインターフェイスの表示をフォーマットし制御する表示ルール、ユーザー入力をチェックし、その妥当性を確認する妥当性確認ルール、必要ならばユーザーによって入力された情報に加えて情報を集める前処理ルール、および要求が複数の権利と一致したときに単一の権利を選択する解決ルールを含む。表示ルールは、利用のタイプにリンクされる。それぞれの利用のタイプは、典型的には、1つの表示ルールにリンクされるが、単一の表示ルールを複数の利用のタイプにリンクすることもできる。表示ルールは、典型的には、ユーザーに提示する表示パラメータおよび提示の順序を定義する。提示の前および提示中に、表示ルールは、表示目的に合わせて表示パラメータの属性を調節することができる。例えば、表示ルールは、テキストラベルを変更するか、またはいくつかの状況において表示を更新させるか、またはパラメータの他の表示属性を修正することができる。あるいは、表示ルールは、ルールに基づいて条件付きパラメータの表示または非表示を決めることができる。例えば、著者フラグパラメータが真に設定されている場合、表示ルールは、オーサリングされたページの数の入力を求めるプロンプトを表示することができる。表示ルールは、ユーザーのデータ入力に基づいてステータスフラグも立てる。例えば、動作中に、表示ルールは、価格設定ルールを実行すべきであること、または要求が完了し、買い物かごへの商品の追加およびその後のユーザーからの決済の受け入れをシステムが行える状態にあることを示すフラグを立てることができる。さらに、更新フラグと称されるすべてのDisplayParmパラメータのフラグを使用して、表示されているパラメータの値が変更された場合にグラフィカルユーザーインターフェイスを再実行することができる。これにより、パラメータの提示が他のパラメータ値の選択に依存するインタラクティブな動作が可能になる。妥当性確認ルールは、パラメータの入力された値をチェックし、その値が所定の基準を満たしていることを確認する。それぞれの妥当性確認ルールは、1つのパラメータにリンクされる。そのパラメータがグラフィカルユーザーインターフェイスに提示された場合、リンクされている妥当性確認ルールが自動的に実行される。例えば、妥当性確認ルールは、入力されたパラメータ値をチェックして、その入力された値が正整数であることを確認することができる。他の妥当性確認ルールは、入力された日付値をチェックして、その値が妥当な日付範囲内にあるかどうか判定することができる。妥当性確認ルールは、<e>rror、<i>nformationのメッセージタイプコードを含む妥当性確認メッセージおよびグラフィカルユーザーインターフェイスに表示するためのメッセージ本文部を返す。妥当性確認エラーがあった場合、エラーメッセージが表示され、ルールエンジンは、新規値が入力されるか、または処理がキャンセルされるまで一時停止する。前処理ルールは、適宜、他のルールにリンクされ、追加の入力を、もしこれらの追加の入力が必要であれば収集することができる。前処理ルールは、表示する前に、または解決する前に実行されるように設定することができる。前処理ルールの役割は、典型的には、データベース、ウェブサービス、またはhttp要求などの外部ソースに接続し、ルールを解決するために必要な追加の情報を集めることである。前処理ルールは、典型的には、集められた情報をルールに関連付けられている<reference>パラメータ内に格納する。これは、メッセージタイプコードおよびメッセージ本文部を前処理メッセージオブジェクトに初期値として入力することも行う。前処理ルールは、適宜、ルール実行の後にオペレーションを実行するために他のルールにリンクすることができる。これは、便利な機能であり、これにより、多くのルールを拡張する標準的なオペレーションが可能になる。例えば、価格は米国ドルで計算されうるが、多くの場合、その価格を多数の通貨単位で提示することが望ましい。この場合、単一の前処理ルールを定義して、計算された価格を適用可能な通貨に変換するために、複数の通貨でオファーを行うべきすべての価格設定ルールの後に実行することができる。解決ルールは、複数の権利が適用される場合にどの権利をユーザーに表示するかを選択し、これらのルールは、典型的には、利用のタイプにリンクされる。一般に、解決ルールは、制限に達することによって排除されなかった最も実施可能な許可ステータスを伴う最高優先度の権利を選択する。ルールは、図2Bに示されているルールテーブル212内にレコードとして格納される。それぞれのルールレコードは、名前値、記述値、タイプ値、クラス、および許可コードを含む複数の値を含む。タイプコードは、ルールタイプを示し、これは、価格設定、印税、制限、特別注文、表示、妥当性確認、解決、前処理、および後処理の値を含む。クラス値は、ルールを実行するために作成されるオブジェクトクラスの名前である。許可コード値は、ルールが使用される際に基づく許可ステータスを示す。値は、許諾、事前認可された購入、リンク権利決定ウェブサイトへの、パブリックドメイン、および連絡先権利者を含む。これらの値は、ルールテーブル212内の該当するフィールドに格納される。それぞれのルールは、所定のパラメータの値を組み合わせて所定のタスクを実行するソフトウェアコードを備える。ルールは、ソースコードテキストのブロックを保持するためのCLOBフィールドsource_codeを持つルールテーブル212内にレコードとして格納される。定義時に従来のコンパイラを使用してJava登録商標ベースのルールをコンパイルし、ソースコードとバイトコード実行ファイルの両方を格納する。ルールが必要になったときに、実行コードが取り出されてインスタンス化され、メモリ104のグローバルアプリケーションエリア内のマップオブジェクトになる。次いで、マップオブジェクトから名前でルールインスタンスを取り出し、実行する。このフレームワークでは、非Java登録商標インタプリタ実行ルールは同じパターンに従うが、ただし、ソースコードはバイトコードにコンパイル済みのクラスの代わりにグローバルアプリケーションエリア内にインスタンス化される点が異なる。Java登録商標で書いた、価格設定ルールに対するソフトウェアソースコードの例を以下に示す。上に示されているようなコードは、RuleBaseと称される基底クラスを持つクラス階層を使用して書かれている。この基底クラスのサブクラスは、<RuleType>Base例えば、PricingRuleBase、RoyaltyRuleBase、DisplayRuleBaseを含み、基底クラスにおいて定義された関数を継承する。このクラスライブラリの結果として、すべてのルールに対するソフトウェアコードは、それに利用可能な一連の関数を有している。価格設定ルールの場合、これらの関数の多くは、add、multiply、およびroundのような数学的演算を行う関数である。これらの関数により、上の例例えば、句:multiplyPER_PAGE_FEE,NUMBER_OF_PAGESに示されているように、ルールソフトウェアは関係するパラメータに名前でアクセスすることができる。ルールソフトウェアの開発を簡素化し、利便性を高めることに加えて、これらの関数は、追跡性のために実行されるオペレーションをログに自動的に記録し、インタプリタで実行されるスクリプティングメカニズムをサポートするオペレーションを標準化するサービスを提供する。このフレームワークは、RightsRequest、Right、RightRule、およびRuleオブジェクトがコールシグネチャの一部である場合の上に示されているルールシグネチャによって示されているようにルール内にコンテキストを入れる。したがって、ルールソフトウェアは、その実行のコンテキストを構成するすべての変数にアクセスすることができる。したがって、ルールエンジンで実行されるルール実行フローにおいて、権利を定義するルールパラメータおよびユーザーによって入力された要求パラメータだけでなく、選択された利用のタイプ、著作物、権利者、現在の権利、見つかった他の権利、および他の計算の結果に関する情報をも参照する可能性がある例えば、印税ルールは対応する価格設定ルールによって計算される価格を必要とすることが多い。ルールデータベースを構成するプロセスにおける次のステップ308では、パラメータをルールにリンクする。パラメータは、複数のルールにリンクすることができ、そのルールのコンテキストに対するデフォルト値を受け入れることができる。価格設定ルール、印税ルール、および特別注文ルールの場合、1つまたは複数のエントリをrule_parmリンクテーブル214内に挿入し、制限ルールの場合、1つまたは複数のエントリをright_rule_lim_parmvalリンクテーブルに挿入することによって、パラメータはルールにリンクされる。これらのエントリは、従来のルールメンテナンス用グラフィカルユーザーインターフェイスの表示によって生成されうる。それぞれのエントリは、リンクされたペアに対するルールおよびパラメータ識別子を含む。それに加えて、妥当性確認ルールを、ルールのコンテキストに対するパラメータにリンクすることができる。これは、rule_parmリンクの識別子および適切な妥当性確認ルールを含むrule_parm_validationリンクテーブル208にエントリを入れることによって行われる。妥当性確認ルールは、入力された情報の妥当性をチェックするために、パラメータ値がユーザーによって入力された後に実行される。次に、ステップ310で、権利を定義し、権利テーブル202にレコードとして格納する。それぞれの権利は、利用のタイプIDをその権利を格納するレコードに入れることによって利用のタイプに関係付けられる。図2Aに示されているように、複数の権利をそれぞれの利用のタイプに関係付けることができる。権利は、1つまたは複数の著作物、著作物のコレクション、境界パラメータ例えば、権利は与えられたライセンシータイプについてのみ有効であるものとしてよい、ロケーション例えば、権利はユーザーが英国にいる場合にのみ有効であるものとしてよい、またはフレキシブルな識別子例えば、データソース、ファイル名、またはURLに接続することができる。これらの接続は、権利テーブル202内の権利を表すレコード内の適切なフィールドに値を追加することによって確立される。権利は、権利テーブルのレコード内に顧客IDを入れることによって特定の顧客に関連付けることもできる。権利は、一から作成するか、または権利テンプレートから作成することができる。権利テンプレートは単なる事前構成された権利であり、コピーし、その後編集することができる。これらの権利テンプレートは、事前構成されリンク先とすることができる、標準権利、権利者が事前構成されるが他のすべての値は修正されうる権利である、標準権利者権利、権利者およびリンクされたルールが事前構成されるが他のパラメータは修正されうる権利である、標準権利者ルール権利、およびルールおよびパラメータが事前構成されるが権利者は修正されうる権利である、標準ルールパラメータ権利を含む。すべてのタイプの権利に、ゼロ、1つまたは複数の契約条件を関連付けることができる。標準権利と同様に、契約条件を自由形式で作成することができ、また、標準契約条件をリンク先とすることができる。契約条件は、参考非制限的または制限的と考えることもでき、これは、複数の有効な権利がある場合にどの権利を選択すべきかを決定する際の一決定因子としてよい。すべての権利は、そのソースに基づいて優先度を割り当てられ、この優先度はright_priority_cdフィールドおよびright_priority_valueフィールドに格納される。権利が利用のタイプについて許可を付与するものであろうとなかろうと、優先度値により、一方の権利を他方の権利に優先するものとして選択することができる。所望の著作物を対象とする複数の権利が見つかった場合、一般的に、見つかった最高の優先度と一致する優先度を有する権利のみが考えられる。例えば、第1の権利が第2の権利より高い優先度を有し、両方の権利が結果としてある利用のタイプに対する許諾をもたらす場合、第1の権利が後述のように制限に達したため排除される場合であっても、第2の権利は、見つかった最高のレベルと同じレベルにないため考慮されない。契約は権利に関連付けられているオプションの概念であり、権利は、契約の内に、または契約の外に存在しうる。多くの場合において、契約は、単なる権利者と権利に対する便利なグループ化メカニズムにすぎない。契約の範囲内で権利を構成する場合、権利者、テンプレート、標準権利、およびその契約に付随する権利割り当てグループのみを見ることに対するデータ入力の効率のよさがある。データ編成以外に、契約の概念は、例外リストなどの高度な権利優先順位付けコンストラクトを実装する必要がときどき生じた場合にその要求に応える。契約の中の権利は権利優先度を有する。契約が権利に関連付けられる場合、契約優先度のコードおよび値はそれぞれagreement_priority_cdフィールドおよびagreement_priority_valueフィールドに格納される。権利優先度の例示的な値は、Nooverride、NormalLessgranular、SameLevel、MoreGranular、Allである。粒度は、権利の接続先となる1つまたは複数の著作物の結果生じるものである。著作物に直接接続されている権利は、最も粒度が細かいと考えられ、コレクションに接続されている権利は、粒度が粗いと考えられる。ほとんどの場合において、Normalの権利優先度が適用されるが、これは、契約の範囲内において、より粒度の細かい権利はより粒度の粗い権利に比べて優先度が高いことを示す。例えば、著作物が契約の範囲内のコレクションに存在し、コレクションは第1の権利に接続され、その著作物が契約内の第2の権利に直接接続されている場合、第2の権利は、より粒度が細かいため第1の権利に比べて優先度が高い。別の場合では、一方のコレクションに含まれることは、他方のコレクションに含まれることに比べて優先度が高いとする、例外コレクションを指定することが可能である。ルールデータベースを構成するプロセスにおける次のステップ312では、ルールを権利にリンクする。権利関係ルールタイプ価格設定、印税、および特別注文は、ルールのタイプ毎のエントリを、権利の識別子およびさまざまなルールタイプとともにright_ruleリンクテーブル210内に挿入することによって権利にリンクされる。制限ルールは、エントリをright_rule_limリンクテーブル220内に挿入することによって権利にリンクされる。取引に関する権利については、典型的には、単一の価格設定ルール、単一の印税ルール、およびゼロ、1つ、または複数の制限ルールがある。ルールを権利にリンクした後、構成プロセスは、ステップ314で終了する。図4A~4Eは、一緒に配置されたときに、権利付与の要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する。権利要求セッションでは、要求に関連付けられている情報を保持するためにRightsRequestオブジェクトが作成される。この情報は、ユーザーによって入力された利用のタイプおよび著作物ID、ユーザー要求コンテキストに適用すると決定された権利、動的に決定される要求パラメータ、表示指定DisplayRowパラメータの値、ユーザーによって入力されたパラメータ値、妥当性確認ルールの結果、制限ルールの結果、価格設定/印税ルール計算の結果、ならびに権利解決処理に必要なさまざまなフラグおよびポインタを含む。すべての権利関係ルールは、それぞれのルールが完全な要求コンテキストにアクセスできるよう、入力引数としてRightsRequestオブジェクトを受け取る。例えば、NUMBER_OF_PAGESに対するパラメータ値の妥当性を確認する妥当性確認ルールは、ルール処理中にRightsRequestオブジェクトを使用してARTICLE_START_PAGEおよびARTICLE_END_PAGEに対するパラメータ値にアクセスすることができる。要求プロセスは、ステップ400から始まり、ステップ402に進み、そこで、ルールエンジンプログラムの制御下で、従来のテキストボックスおよびコンボボックスコントロールを備えるグラフィカルユーザーインターフェイス表示を生成し、著作物ID、発効日、およびユーザーIDのタイプを含む基本コンテキスト情報を入力するようユーザーに求める。ロケーション情報は、適宜、ユーザーから要求されうる。ユーザーのインタラクティブな操作の観点からは、要求に対して複数の状態がある。それぞれの状態は、レディフラグに関連付けられており、このフラグは、真に設定された場合に、状態が完了しており、システムは次の状態に対して準備が整っていることを示す。これらの状態は、すべてのレディフラグが偽に設定されている開始状態を含む。境界パラメータのレディフラグは、境界パラメータのレディ状態に関連付けられており、これは、真のときに、適用可能な権利を取り出すことが可能なようにすべての境界パラメータが入力され妥当性確認が済んでいることを示す。解決パラメータのレディ状態では、解決パラメータのレディフラグに対する真値は、権利関係ルール制限ルール、価格設定ルール、および印税ルールを処理することが可能なようにすべての解決関係パラメータが入力され妥当性確認が済んでいることを示す。ユーザーの支払い金額を徴収するために買い物かごのメタファーが使用される場合、買い物かごパラメータのレディ状態において、関連付けられているフラグの真値は、商品を買い物かごに追加してユーザーが要求権利に対する対価を支払うことが可能なようにすべてのパラメータが入力され妥当性確認が済んでいることを示す。ステップ406において、利用のタイプIDを使用して、ルールデータベース内のtou_ruleテーブル206にアクセスし、関連付けられている表示ルールを特定する。利用のタイプに表示ルールが関連付けられていない場合、表示順序に従ってパラメータを単に提示し、それぞれの列に対するデフォルト設定を使用するデフォルトの表示ルールが使用される。一般に、表示ルールは実行されると、それぞれの行displayRowおよび行パラメータdisplayParmの属性を定義することによってエンドユーザーからどのような入力が要求されるかに関するグラフィカルユーザーインターフェイスの命令を出す。表示ルールが特定された場合、rule_parmテーブル214はルールIDでアクセスされ、境界パラメータがparmテーブル216から取り出される。すでに述べたように、境界パラメータは、権利要求コンテキストに適用可能な権利が存在しているかどうかを判定するために必要である。ステップ408において、そのような境界パラメータが存在しているかどうかの判定が行われる。ステップ408において、境界パラメータが存在していないと判定された場合、プロセスは、オフページコネクタ418および424を介して、以下で説明するステップ430に進む。あるいは、ステップ408において、境界パラメータが存在していると判定された場合、プロセスはステップ410に進み、そこで、すでに特定されている表示ルールを実行する。表示ルールは、DisplayRowおよびDisplayParmパラメータを使用して、適切なコントロールをグラフィカルユーザーインターフェイス上の指定されたロケーションに表示し、境界パラメータを入力するようユーザーに求める。ステップ412で、ルールエンジンが境界パラメータを受け取る。次いで、プロセスは、オフページコネクタ416および422を介して、ステップ426に進み、そこで、それぞれのパラメータに関連付けられている妥当性確認ルールを実行する。ステップ428において、入力されたパラメータ値が有効かどうかの判定が行われる。入力されたパラメータ値が有効でないと判定された場合、プロセスは、オフページコネクタ420および414を介して、ステップ410に戻り、そこで、表示ルールを再実行し、パラメータ値を再入力するようユーザーに求める。ステップ430において、境界パラメータが存在しない場合、または境界パラメータ値が収集され、妥当性確認が行われた後、ルールエンジンは、権利テーブル202にアクセスし、ユーザーコンテキストおよびユーザーによって入力された境界パラメータに適用される権利を取り出す。取り出された権利は、それぞれの権利およびその関係するパラメータを含む権利配列内に置かれる。次いで、ステップ432において、ルールエンジンは、権利ルールテーブルにアクセスし、それぞれの取り出された権利に適用されるさまざまな権利関係ルールを決定する。いくつかの場合において、1つの権利に複数の権利者および権利ルールが関連付けられている。これらの場合には、ルールエンジンは、2つのオプションをサポートする。第1のオプションでは、一組の価格設定または特別注文、印税、および制限ルールは、それぞれの権利者に関連付けられ、総価格は、すべての計算された価格の合計となり、印税が総価格に基づいて解析されてそれぞれの権利者に送られる。任意の権利者に関連付けられている制限に到達した場合、権利全体が無効である。第2のオプションでは、単一の価格設定ルールがすべての権利者に対して使用され、総価格ルールが最初に計算され、次いで、それぞれの権利者について印税が計算される。任意のレベルの制限に到達した場合、権利全体が無効である。ステップ434において、プロセスは、権利およびコンテキストに適用される関係するルールの組合せに基づいてどの表示ルールを実行するかを決定する。デフォルトの表示ルールは、それぞれの利用のタイプについて、または評価すべきルールの組合せについて指定することができる。例えば、NumberofPagesパラメータ値のみの入力を求める必要がある価格設定ルールP1および印税ルールR1は、表示ルールD1に関連付けることが可能である。しかし、他の価格設定ルールP2を含めるためにAreyouacommercialuserパラメータ値の入力をさらに求める必要がある場合、この後者のルールグループは、追加のパラメータ値に対し要求される追加の入力を求める操作を扱う異なる表示ルールD2に関連付けることが可能である。全体として、表示ルールの選択に対して、以下の順序が適用される。最初に、処理されるルールが、すべて、利用のタイプに対する表示ルールグループに関連付けられている一組のルールに含まれる場合、その表示ルールが使用される。あるいは、処理されるルールが、すべて、親の利用のタイプに対する表示ルールグループに関連付けられている一組のルールに含まれる場合、その表示ルールが使用される。前記のどれもが適用可能でない場合、その利用のタイプに対するデフォルトのルールが使用される。そのようなデフォルトのルールが適用可能でない場合、親の利用のタイプに対するデフォルトのルールが使用される。ほかに特定されるルールがない場合、システムのデフォルトの表示ルールが使用される。次いで、プロセスは、オフページコネクタ436および438を介して、ステップ440に進み、そこで、決定されたパラメータに対する表示ルールを実行し、必要な値を入力するようユーザーに求める。表示ルールは、ここでもまた、ルールに関連付けられているDisplayRowおよびDisplayParmパラメータ値を使用して、権利解決に必要な要求パラメータをユーザーに提示する。ステップ442において、要求パラメータが受け取られ、ステップ444において、妥当性確認ルールが、受け取ったパラメータについて実行される。ステップ446で、パラメータが有効でないと妥当性確認ルールによって判定された場合、プロセスはステップ440に戻り、そこで、表示ルールを再実行し、必要なパラメータ値を再入力するようユーザーに求める。あるいは、ステップ446において、受け取ったパラメータが有効であると判定された場合、プロセスは、オフページコネクタ448および452を介して、ステップ456に進み、そこで、要求パラメータの入力が完了したかどうかの判定を行う。入力が完了していない場合、プロセスは、オフページコネクタ454および450を介して、ステップ440に戻り、そこで、適切な表示ルールを再実行し、さらにパラメータを入力するようユーザーに求める。権利関係ルールは、関連付けられている表示ルールが解決パラメータのレディフラグを真に設定してすべての権利関係ルールパラメータが収集されたことを示す場合にのみ実行できる。あるいは、ステップ456において、すべての必要な要求パラメータを受け取り、妥当性確認を行ったと判定された場合、プロセスはステップ460に進み、そこで、すべての取り出された権利に対する制限ルールを実行する。次いで、ステップ462において、制限ルールが実行された後に有効な権利が残っているかどうかの判定を行う。有効な権利が残っていない場合、プロセスは、利用可能な有効な権利がないことを知らせるメッセージをユーザーに表示し、プロセスは、オフページコネクタ472および476を介して進行し、ステップ488で終了する。あるいは、ステップ462において、有効な権利が存在していると判定された場合、これらの権利は、有効な権利リストに入れられ、次いで、プロセスはステップ466に進み、そこで、まだ有効であるすべての権利に対する価格設定ルールを実行し、その後、ステップ468に進み、そこで、すべての有効な権利に対する印税ルールを実行する。次いで、プロセスは、オフページコネクタ470および474を介して、ステップ478に進み、そこで、複数の有効な権利が存在しているかどうかの判定を行う。ただ1つの有効な権利が存在していると判定された場合、ResolvedRightsReadyフラグを立てて、価格設定が完了していることを示し、プロセスは以下で説明するステップ482に進む。あるいは、ステップ478において、複数の有効な権利が存在していると判定された場合、ステップ480で、権利解決ルールを実行して、有効な権利のうちの1つを選択する。権利解決ルールは、選択されたルールをソートして権利のリストの上に来るようにする。決定を下す際に、権利解決ルールでは、権利の優先度、許可の利用可能性、制限的契約条件が存在しているかどうか、価格最高額または最低額、印税、権利者、および他の決定因子などの決定因子を考慮することができる。解決ルールによって権利が選択された後、ResolvedRightsReadyフラグが立てられ、価格設定が完了したことを示す。価格設定が完了したときに、プロセスはステップ482において解決された権利および価格をユーザーに表示する。ステップ484におけるこの時点で、価格設定ルールに関連付けられている表示ルールは、DisplayRowおよびDisplayParmパラメータ値を使用し、ユーザーが権利を購入できるようにグラフィカルユーザーインターフェイスを表示する従来の買い物かごソフトウェアを実行する前に必要になると思われる追加のパラメータに対する値の入力をユーザーに求める。商品は、後者の表示ルールが買い物かごパラメータのレディフラグを真に設定してすべての必要なパラメータが収集されたことを示す場合にのみ買い物かごに追加することができる。ステップ486において、ルールエンジンは、選択された権利、価格設定、印税、および関係するデータ要素を、ステップ488で示されているような課金、徴収、および最終的には印税支払いを実行する役割を持つ従来の買い物かご、精算、および他の管理用のソフトウェアに送る。ルールエンジンのすべての態様は日付/バージョン変更に対応しており、ユーザーが後日注文を修正したくなった場合に、システムは、原注文の時点において有効であった同じ権利、ルール、およびパラメータを見つけて、修正されたパラメータ値で同じ計算を再処理することができる。本発明は、その多数の実施形態を参照しつつ図示され、説明されているが、当業者であれば付属の請求項による定義に従って本発明の精神および範囲から逸脱することなく本明細書において形態および細部にさまざまな変更が加えられうることを理解するであろう。"