(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5864113
(24)【登録日】2016年1月8日
(45)【発行日】2016年2月17日
(54)【発明の名称】自動化されたルールベースの権利解決
(51)【国際特許分類】
G06Q 50/10 20120101AFI20160204BHJP
【FI】
G06Q50/10 140
【請求項の数】28
【外国語出願】
【全頁数】20
(21)【出願番号】特願2011-54292(P2011-54292)
(22)【出願日】2011年3月11日
(65)【公開番号】特開2011-192280(P2011-192280A)
(43)【公開日】2011年9月29日
【審査請求日】2014年1月27日
(31)【優先権主張番号】12/724,859
(32)【優先日】2010年3月16日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】511053089
【氏名又は名称】コピーライト クリアランス センター インコーポレイテッド
(74)【代理人】
【識別番号】110001243
【氏名又は名称】特許業務法人 谷・阿部特許事務所
(72)【発明者】
【氏名】キース マイアー
【審査官】
宮地 匡人
(56)【参考文献】
【文献】
特開2002−203071(JP,A)
【文献】
特開2001−160003(JP,A)
【文献】
特表2009−512064(JP,A)
【文献】
特開平08−263441(JP,A)
【文献】
米国特許出願公開第2004/0010708(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00−50/34
(57)【特許請求の範囲】
【請求項1】
プロセッサ、メモリ、ディスプレイ、およびユーザー入力デバイスを有するコンピュータを、コンテンツの利用権利に対する要求に応答して制御するための方法であって、
(a)前記メモリ内に複数の権利レコードを格納するステップであって、それぞれの権利レコードがコンテンツ利用の所定のタイプに対する権利を表す、ステップと、
(b)前記メモリ内に複数の表示ルールレコードを格納するステップであって、それぞれの表示ルールレコードは、コンテンツ利用のタイプにリンクされ、少なくとも1つの所定のパラメータの入力を求めるように前記ディスプレイを制御するため、および前記パラメータに対する値を表す入力を前記入力デバイスから受け取るためのプログラムコードを有する、ステップと、
(c)前記メモリ内に複数の権利ルールレコードを格納するステップであって、それぞれの権利ルールレコードは、権利レコードにリンクされ、前記リンクされた権利が利用可能であるかどうかを決定すること、前記権利に対する価格を決定すること、および前記権利に対する印税を決定することのうちの1つを実行する、ステップと、
(d)ルールエンジンプログラムを備える前記プロセッサを、要求されたコンテンツ利用について表示ルールレコードを選択し、その中にあるプログラムコードを実行してパラメータ値を取得するように制御するステップと、
(e)前記ルールエンジンプログラムを備える前記プロセッサを、前記取得したパラメータ値に基づいて、前記メモリから少なくとも1つの権利レコードを取り出すように制御するステップであって、それぞれの権利レコードは、優先度を有する、ステップと、
(f)前記ルールエンジンプログラムを備える前記プロセッサを、ステップ(e)で取り出した各権利レコードにリンクされている各権利ルールレコード内のプログラムコードを実行し、前記取得されたパラメータ値に基づいて、前記各権利レコードにより定義される権利が利用可能であるか、前記権利に対する前記価格、および前記権利に対する前記印税を決定するように制御するステップと、
(g)前記ルールエンジンプログラムを備える前記プロセッサを、各権利レコードが有する前記優先度に基づいて、ステップ(f)で判定された複数の利用可能な権利のうちから単一の権利を選択するように制御するステップと
を含むことを特徴とする方法。
【請求項2】
前記ルールエンジンプログラムの制御の下で、前記プロセッサにより、要求されたコンテンツユーザーのタイプおよびコンテンツ著作物を含む要求オブジェクト、前記コンテンツ利用のタイプに適用されると決定された権利、前記要求の状態、前記入力デバイスから受け取ったパラメータ値、および実行された権利ルールによって生成された結果を生成し、前記メモリ内に保持するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記要求オブジェクトは、前記権利ルールレコードのそれぞれの中のプログラムコードへの入力として与えられることを特徴とする請求項2に記載の方法。
【請求項4】
前記メモリ内に複数のパラメータレコードを格納するステップであって、それぞれのパラメータレコードが所定のパラメータの特性を定義する、ステップと、パラメータレコードを表示ルールレコードにリンクするステップとをさらに含み、ステップ(d)は、表示ルールレコード内のプログラムコードを、当該実行プログラムコードによって必要とされる、前記リンクされたパラメータレコードによって事前定義されるパラメータの特性を用いて実行するステップを含むことを特徴とする請求項1に記載の方法。
【請求項5】
前記メモリ内に複数の妥当性確認ルールレコードを格納するステップであって、それぞれの妥当性確認ルールレコードは、前記ユーザー入力デバイスから受け取った情報の妥当性確認を行うためのプログラムコードを含む、ステップと、それぞれの妥当性確認ルールレコードを前記パラメータレコードのうちの1つにリンクするステップをさらに含み、ステップ(d)は、リンクされた妥当性確認ルールレコードを用いて、取得したパラメータ値の妥当性を確認するステップを含むことを特徴とする請求項4に記載の方法。
【請求項6】
ステップ(c)は、前記メモリ内に複数の前処理ルールレコードを格納することであって、それぞれの前処理ルールレコードがルールレコードにリンクされ、前記ユーザー入力デバイスから受け取った情報を処理する前に、前記権利が利用可能であるかどうかを決定するために必要な情報を取得するための、ステップ(f)で実行されるプログラムコードを含む、ことを含むことを特徴とする請求項1に記載の方法。
【請求項7】
前記メモリ内に複数の解決ルールレコードを格納するステップであって、それぞれの解決ルールレコードが前記要求されたコンテンツ利用に利用可能であると判定された権利を表す複数の権利レコードから1つの権利レコードを選択するための、ステップ(g)で実行されるプログラムコードを含む、ステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項8】
ステップ(g)は、前記ルールエンジンプログラムを備える前記プロセッサを、権利が利用可能であるかどうかを決定した後、および当該権利に対する価格を計算する前に、少なくとも1つの解決ルールレコード内のプログラムコードを実行するように制御すること含むことを特徴とする請求項7に記載の方法。
【請求項9】
それぞれのルールレコード内の編集されたプログラムコードは、コンパイルされ格納されることを特徴とする請求項1に記載の方法。
【請求項10】
ステップ(d)の前に、それぞれのルールレコード内のプログラムコードは、前記メモリから取り出され、インスタンス化され、その結果得られる実行コードは、前記メモリ内にキャッシュされ、そうして、ステップ(d)において、前記ルールエンジンプログラムを備える前記プロセッサが前記実行コードを実行することを特徴とする請求項1に記載の方法。
【請求項11】
それぞれの権利レコード、それぞれの権利ルールレコード、およびそれぞれの表示ルールレコードは、バージョン情報を含み、取得されたパラメータ値は、前記メモリ内に格納され、これにより、ステップ(d)から(g)を実行して第1の利用可能な権利を選択し、後日ステップ(d)から(g)を繰り返して、前記第1の利用可能な権利と同じである第2の利用可能な権利を選択することができることを特徴とする請求項1に記載の方法。
【請求項12】
取得されたパラメータ値は、前記メモリ内の要求オブジェクト内に格納され、前記要求オブジェクトは、ステップ(d)において、前記選択された権利にリンクされている権利ルールレコードに供給され、これにより、すべての取得されたパラメータ値が前記選択された権利にリンクされている前記権利ルールレコードに利用可能になることを特徴とする請求項1に記載の方法。
【請求項13】
ステップ(d)において、選択された表示ルールレコードにおいて実行されるプログラムコードは、前記選択された表示ルール内に格納されている表示行値および前記選択された表示ルールにリンクされているパラメータテーブル内に格納されている表示パラメータ属性を介して前記ディスプレイを制御することを特徴とする請求項1に記載の方法。
【請求項14】
それぞれの表示ルールおよびそれぞれの権利ルールは、それぞれのルールに関連付けられているプログラムコード内で使用することができる複数の関数を含む基底ルールクラスのサブクラスであることを特徴とする請求項1に記載の方法。
【請求項15】
コンテンツの利用権利に対する要求に応答するための装置であって、プロセッサ、メモリ、ディスプレイ、およびユーザー入力デバイスを有するコンピュータを備え、
前記メモリ内に複数の権利レコードを格納し、それぞれの権利レコードがコンテンツ利用の所定のタイプに対する権利を表し、
前記メモリ内に複数の表示ルールレコードを格納し、それぞれの表示ルールレコードはコンテンツ利用のタイプにリンクされ、少なくとも1つの所定のパラメータの入力を求めるように前記ディスプレイを制御し、前記パラメータに対する値を表す入力を前記入力デバイスから受け取るためのプログラムコードを有し、
前記メモリ内に複数の権利ルールレコードを格納し、それぞれの権利ルールレコードは権利レコードにリンクされ、前記リンクされた権利が利用可能であるかどうかを決定すること、前記権利に対する価格を決定すること、および前記権利に対する印税を決定することのうちの1つを実行し、
ルールエンジンプログラムを実行して、要求されたコンテンツ利用について表示ルールレコードを選択し、その中にあるプログラムコードを実行してパラメータ値を取得し、
前記ルールエンジンプログラムを実行して、前記取得したパラメータ値に基づいて、前記メモリから少なくとも1つの権利レコードを取り出し、それぞれの権利レコードは、優先度を有し、
前記ルールエンジンプログラムを実行して、取り出した各権利レコードにリンクされている各権利ルールレコード内のプログラムコードを実行し、前記取得されたパラメータ値に基づいて、前記各権利レコードにより定義される権利が利用可能であるかどうか、前記権利に対する前記価格、および前記権利に対する前記印税を決定し、
前記ルールエンジンプログラムを実行して、各権利レコードが有する前記優先度に基づいて、判定された複数の利用可能な権利のうちから単一の権利を選択するように前記プロセッサを制御する前記メモリ内に格納されているプログラムコードをさらに備えることを特徴とする装置。
【請求項16】
前記ルールエンジンプログラムは、前記メモリ内で、要求されたコンテンツ利用のタイプおよびコンテンツ著作物を含む要求オブジェクト、前記コンテンツ利用のタイプに適用されると決定された権利、前記要求の状態、前記入力デバイスから受け取ったパラメータ値、および実行された権利ルールによって生成される結果を生成し、保持するように前記プロセッサを制御することを特徴とする請求項15に記載の装置。
【請求項17】
前記要求オブジェクトは、前記権利ルールレコードのそれぞれの中のプログラムコードへの入力として与えられることを特徴とする請求項16に記載の装置。
【請求項18】
前記メモリ内に複数のパラメータレコードを格納し、それぞれのパラメータレコードが所定のパラメータの特性を定義し、およびパラメータレコードを表示ルールレコードにリンクするように前記プロセッサを制御するプログラムコード、および表示ルールレコード内のプログラムコードを、当該実行プログラムコードによって必要とされる、前記リンクされたパラメータレコードによって事前定義されるパラメータの特性を用いて実行するように前記プロセッサを制御するプログラムコードをさらに備えることを特徴とする請求項15に記載の装置。
【請求項19】
前記メモリ内に複数の妥当性確認ルールレコードを格納し、それぞれの妥当性確認ルールレコードが前記ユーザー入力デバイスから受け取った情報の妥当性確認を行うためのプログラムコードを含み、およびそれぞれの妥当性確認ルールレコードを前記パラメータレコードのうちの1つにリンクするように前記プロセッサを制御するプログラムコード、並びにリンクされた妥当性確認ルールレコードを用いて、取得したパラメータ値の妥当性を確認するように前記プロセッサを制御するプログラムレコードをさらに備えることを特徴とする請求項18に記載の装置。
【請求項20】
前記メモリ内に複数の権利ルールレコードを格納するように前記プロセッサを制御する前記プログラムコードは、前記メモリ内に複数の前処理ルールレコードを格納するように前記プロセッサを制御する前記プログラムコードを含み、それぞれの前処理ルールレコードがルールレコードにリンクされ、前記ユーザー入力デバイスから受け取った情報を処理する前に、前記権利が利用可能であるかどうかを決定するために必要な情報を取得するための、前記ルールエンジンプログラムによって実行されるプログラムコードを含むことを特徴とする請求項15に記載の装置。
【請求項21】
前記メモリ内に複数の解決ルールレコードを格納するように前記プロセッサを制御する前記メモリ内に可能されているプログラムコードをさらに備え、それぞれの解決ルールレコードが、前記要求されたコンテンツ利用に利用可能であると判定された権利を表す複数の権利レコードから1つの権利レコードを選択するための、前記ルールエンジンプログラムによって実行されるプログラムコードを含むことを特徴とする請求項15に記載の装置。
【請求項22】
前記ルールエンジンプログラムは、権利が利用可能であるかどうかを決定した後、および選択された権利に対する価格を計算する前に、少なくとも1つの解決ルールレコード内のプログラムコードを実行して、判定された複数の利用可能な権利のうちから単一の権利を選択するように前記プロセッサを制御することを特徴とする請求項21に記載の装置。
【請求項23】
それぞれのルールレコード内の編集されたプログラムコードは、コンパイルされ格納されることを特徴とする請求項15に記載の装置。
【請求項24】
前記ルールエンジンプログラムの制御の下での前記プロセッサによる実行の前に、それぞれのルールレコード内のプログラムコードは、前記メモリから取り出され、インスタンス化され、その結果得られる実行コードは、前記メモリ内にキャッシュされ、そうして、前記ルールエンジンプログラムの制御の下で前記プロセッサが前記実行コードを実行することを特徴とする請求項15に記載の装置。
【請求項25】
それぞれの権利レコード、それぞれの権利ルールレコード、およびそれぞれの表示ルールレコードは、バージョン情報を含み、取得されたパラメータ値は、前記メモリ内に格納され、これにより、前記プロセッサは前記ルールエンジンプログラムを実行して第1の利用可能な権利を選択し、次いで前記ルールエンジンプログラムを後日再実行して、前記第1の利用可能な権利と同じである第2の利用可能な権利を選択することができることを特徴とする請求項15に記載の装置。
【請求項26】
取得されたパラメータ値は、前記メモリ内の要求オブジェクト内に格納され、前記要求オブジェクトは、前記ルールエンジンプログラムによって、前記選択された権利にリンクされている権利ルールレコードに供給され、これにより、すべての取得されたパラメータ値が前記選択された権利にリンクされている前記権利ルールレコードに利用可能になることを特徴とする請求項15に記載の装置。
【請求項27】
前記ルールエンジンプログラムは前記プロセッサを、前記選択された表示ルール内に格納されている表示行値および前記選択された表示ルールにリンクされているパラメータテーブル内に格納されている表示パラメータ属性を介して前記ディスプレイを制御する選択された表示ルールレコード内のプログラムコードを実行するように制御することを特徴とする請求項15に記載の装置。
【請求項28】
それぞれの表示ルールおよびそれぞれの権利ルールは、それぞれのルールに関連付けられているプログラムコード内で使用することができる複数の関数を含む基底ルールクラスのサブクラスであることを特徴とする請求項15に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のライセンスおよびサブスクリプションが適用されるコンテンツに対する再利用権を決定するための方法および装置に関するものである。
【背景技術】
【0002】
著者によって作成された著作物、つまり「コンテンツ」は、一般的には、再利用に関して法的規制を受ける。例えば、ほとんどのコンテンツは、著作権によって保護されている。著作権は、実際には、コンテンツを種々のフォーマットで提示するための権利、コンテンツを種々のフォーマットで再現するための権利、二次的著作物を作り出すための権利などを含む、権利の「束」である。著作権で保護されている単一の著作物は、潜在的に、まだ考案されていない利用を含む、等しい数の関連付けられている権利を伴う多数の利用に分割されうる。例えば、著作物をウェブサイトに投稿するなどのデジタル形式での利用およびインターネット経由の利用は、相互接続されたコンピュータおよび他のデバイスの技術、ネットワークインフラストラクチャ、および広範な使用が存在するようになる前には、思い描くことも、許諾されることも、拒否されることもなかったと考えられる。
【0003】
それぞれの権利は、著者によって留保されるか、または他のエンティティに割り当てられうる。権利の所有者は、著者であろうと他のエンティティであろうと、権利者と称される。権利消費者は、権利者から権利を購入する個人またはエンティティである。著作権で保護されている任意の種類のマテリアルの出版社、著者、エージェント、所有者などの権利者は、所有している権利を権利消費者に付与することを許諾または拒否するほかに、それぞれの権利に関係する条件、価格設定、および他の規定を与えることができる
【0004】
このような状況において、有効な権利は、指定された方法でコンテンツを使用するための権利者によって付与される許可を表す。1つの権利は、1つまたは複数の著作物、著作物のコレクション、または著作物の出版社に付随するものとしてよく、また、データソース、ファイル名、またはURLなどの現実世界におけるオブジェクトを指すフレキシブルな識別子に付随するものとすることができる。権利の利用可能性は、1つまたは複数の境界パラメータによって制限されうる。一般に、権利は、見込みライセンシーに対し有効であると考えられ、したがって、指定された再利用の許可は、そのライセンシーに対する境界パラメータが所定の値を有する場合にのみそのライセンシーに付与される。これらの境界パラメータの例として、ライセンシー識別子、ライセンシータイプ、またはライセンシーロケーションが挙げられる。
【0005】
権利者または権利をその代理で割り当てることを権利者によって許可されたエージェントが著作物の特定の利用についての要求を受け取るときに、その要求を権利が要求者に付与される際の契約条件を定めるライセンス契約と比較対照しなければならない。それに加えて、どれだけの印税を誰に支払わなければならないかに関する決定を行わなければならない。いくつかの場合において、印税は複数の権利者にわたる。したがって、その要求を処理するのに、かなりの時間を要することがあり、特に、その要求が通常のものでなかったり、広範囲にわたる利用であったり、または初めての要求である場合、またはその権利に対して、要求されている利用のタイプの解釈を必要とする場合に時間が長くかかる可能性がある。いくつかの場合では、要求された特定の権利に適用されうる多数の、多くの場合には相反するライセンス契約があることもある。そのような場合、人間のオペレータが、その要求をいくつかのライセンスと突き合わせて検討し、その要求に許諾を与えることができるかどうか、またどのライセンス契約に基づいてそうすることができるか決定する必要がある。これらは、時間のかかる、また費用のかかる作業である。
【発明の概要】
【0006】
本発明の原理によれば、以前には人間のオペレータによってなされていた権利決定を行う、つまり、権利に対する要求を許諾することができるかどうか、要求者によってどのような価格が支払われるべきか、印税が権利者にどれだけ支払われるべきかを決定する1つまたは複数の記憶域に格納されている「ルール」によってルールエンジンが駆動される。権利毎に特定の符号化を行うことを回避するために、求められている決定を行うのに必要なルールおよびパラメータを構成し、異なる権利を処理するために異なる方法でリンクすることができる再利用可能なモジュールの標準的集合を形成する。
【0007】
一実施形態において、著作物および利用のタイプを指定することによってユーザーが権利を要求できるようにするグラフィカルユーザーインターフェイスは、利用のタイプにリンクされた追加の表示ルールによって制御され、これにより、要求を許諾できるかどうかを決定するために、またその要求が許諾された場合に決定された価格をユーザーに表示するために必要な情報の入力をユーザーに求める。
【0008】
他の実施形態では、追加の処理ルールは、ユーザーによってグラフィカルユーザーインターフェイスに入力された情報の妥当性を確認し、必要ならば追加の情報を取得し、選択された著作物および利用のタイプについて異なる権利者から利用可能であると思われる複数の権利のうちから1つの権利を選択する。
【図面の簡単な説明】
【0009】
【
図1】格納されているルールによって駆動され、表示を制御するルールエンジンの全体的な構造を示すブロック略図である。
【
図2A】
図1に示されている、複数のテーブルおよびルールデータベースを形成するテーブル間の相互関係を、図式的に示す図である。
【
図2B】
図1に示されている、複数のテーブルおよびルールデータベースを形成するテーブル間の相互関係を、図式的に示す図である。
【
図2C】
図1に示されている、複数のテーブルおよびルールデータベースを形成するテーブル間の相互関係を、図式的に示す図である。
【
図3】
図2A〜2Cに示されているデータベースを構成するための例示的なプロセスにおけるステップを示す流れ図である。
【
図4A】一緒に配置されたときに、権利要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する図である。
【
図4B】一緒に配置されたときに、権利要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する図である。
【
図4C】一緒に配置されたときに、権利要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する図である。
【
図4D】一緒に配置されたときに、権利要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する図である。
【
図4E】一緒に配置されたときに、権利要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する図である。
【発明を実施するための形態】
【0010】
図1においてブロック図式的に示されているように、ルールデータベース100に格納されている複数のルールは、権利の要求を許諾できるかどうか、要求者によってどのような価格が支払われるべきか、および権利者に印税をどれだけ支払うべきかを決定することに関してルールエンジン106を制御する。表示ルールの制御の下で、ルールエンジン106は、要求された決定を行うために必要なパラメータ値の入力を要求者に求めるグラフィカルユーザーインターフェイスをディスプレイ110上に構成する。他のルールは、入力デバイス108を介して要求者からパラメータ値を受け取り、受け取った値の妥当性を確認する。他のルールは、必要な計算を実行し、ディスプレイ110上のグラフィカルユーザーインターフェイスを介して結果を要求者に表示する。入力デバイス108およびディスプレイ110は、
図1に、ルールエンジン106に直接接続されているように示されているけれども、デバイス108およびディスプレイ110は、ブラウザプログラムおよびインターネット(図示せず)を介して、サーバーにおいて動作しているルールエンジン106と通信するリモートコンピュータの一部とすることも可能である。この場合、グラフィカルユーザーインターフェイスは、ブラウザによって表示され、入力デバイスは、マウスおよびキーボードとすることが可能である。このような配置構成は、当業者によく知られている。
【0011】
ルールデータベース100内の情報の配置構成は、
図2A〜2Cに示されており、13個の関係するテーブル200〜224からなる。それぞれのテーブルは、プライマリーキー、つまりユニークキーを含み、外部キーまたは他の情報を含むことができる。例えば、type−of−use(TOU)テーブル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内には多数のエントリがありうる。
【0012】
図3は、ルールデータベースを構成するプロセスを示している。このプロセスはステップ300から始まり、ステップ302に進み、そこで、利用のタイプのレコードを定義し、格納する。一般に、利用のタイプは、定義済みのアクションである。組織のメンバーによる出版物に対する例示的な一組の定義済みの利用のタイプとして、(1)出版物のコピーを組織のメンバーに電子メールで送ること、(2)出版物のコピーを組織のメンバーでない人に電子メールで送ること、(3)出版物のコピーをローカルのハードドライブ上に格納すること、(4)出版物のコピーを共有ネットワークドライブ上に格納すること、(5)出版物のコピーをスキャンし、組織のメンバーに電子メールで送ること、(6)出版物のコピーをスキャンし、組織のメンバーでない人に電子メールで送ること、(7)コピー機で出版物をコピーし、それを組織のメンバーと共有すること、(8)コピー機で出版物をコピーし、それを組織のメンバーでない人と共有すること、(9)出版物の印刷したコピーを組織のメンバーと共有すること、(10)出版物の印刷したコピーを組織のメンバーでない人と共有すること、(11)Lotus Notes(商標)を使用して出版物のコピーを共有すること、(12)出版物のコピーをインターネットサイトにアップロードすること、(13)広告目的で出版物のコピーを投稿すること、および(14)出版物のコピーを電子ペーパー(ソフトビルボード)にアップロードすることが挙げられる。
【0013】
それぞれの利用のタイプは、touテーブル200内に個別のレコードとして格納される。利用のタイプは、子の利用のタイプを含むこともでき、子の利用のタイプは、複数の親の利用のタイプの下で存在しうる。親の利用のタイプに関連付けられている権利は、子に自動的に適用される。可能ならば、権利を親の利用のタイプに割り当てると最も都合がよく、これにより、それぞれの個別の子レベルで割り当てを行う必要がなくなる。いくつかの場合において、権利者は、低いまたはより粒度の細かいレベルでのみ許可を付与している可能性があり、したがって、子の利用のタイプを個別に構成する必要がある。例えば、コピー機によるコピーの親権利は、コピー機による内部コピー、コピー機による外部コピー、コピー機による図書館保存用のコピー、またはポスター表示のためのコピー機によるコピーの子権利を含みうる。すべての権利が適用される場合、それらをコピー機によるコピーの親レベルで構成すると都合がよい。コピー機による内部コピーなどの部分集合のみが適用される場合、子レベルでルールを構成する必要がある。親−子関係は、tou_tou_relationテーブル204内に格納され、これにより、多対多関係を格納することができる。
【0014】
図3に戻り、ステップ304において、パラメータを定義し、格納する。パラメータは、ルールまたは権利要求のいずれかに関連付けられたデータである。例えば、ルールに関連付けられているパラメータは、ページ毎の料金とすることも可能である一方、要求に関連付けられているパラメータは、要求されたページの数とすることが可能である。パラメータ定義は、名前値(ルールまたは権利要求でパラメータを参照することを可能にする)、ラベル値(グラフィカルユーザーインターフェイスにおいてパラメータを識別する)、利用コード(そのパラメータが権利または権利要求定義の範囲内で使用されるか、またはルールの定義の一部である参照パラメータであるかどうかを示す。あるいは、参照パラメータをルールコードの本文部の中に置くことも可能であるが、その場合、それらは他のルールで読み取ることは可能でない)、フィールド長(入力情報の最大文字数を示す)、表示幅(グラフィカルユーザーインターフェイスにパラメータを表示するコントロールの幅に対するデフォルトのピクセル値を示す)、エンティティタイプ(パラメータが接続されるエンティティを示す。「ルール」のエンティティタイプは、最も頻繁にあるものであるが、パラメータは「著作物」または「権利者」にも接続することが可能である)を含む、パラメータを定義する複数の値を含む。追加のパラメータ定義値は、データ型(文字列型、整数型、数値型、日付型、論理型、CLOB型(キャラクターラージオブジェクト)、またはテーブルなどの複合データ型)、およびデフォルト値(これにより、そのパラメータに対するコントロールを表示する際に初期値を表示することができる)、およびパラメータが表示されるデフォルトのシーケンスを示す表示シーケンスを含む。これらの値は、
図2Bに示されているパラメータテーブル216内の対応するフィールドに格納される。それに加えて、パラメータは標準値というオプションの概念を有し、これにより、パラメータが表示されるときにドロップダウンリストコントロール内に所定の値を提示することができる。標準値は、
図2Cに示されている標準値テーブル224に格納され、パラメータIDをパラメータ値テーブル内のparm_idフィールドに入れることによってパラメータに関係付けられる。
【0015】
ステップ306では、ルールを定義し、格納する。ルールは、所定のタスクを実行するための統制されたフレームワークの一部として実行されるソフトウェアコードの一ブロックである。ルールは、権利にリンクし、これにより、権利の利用可能性、オファーの性質(価格)、そのオファーの結果として支払うべき印税(コスト)の条件を決める。権利の利用可能性は、要求者のタイプまたはロケーションおよび制限ルール(例えば、制限ルールで、使用量を5ページ以下に制限することが可能である)などの境界パラメータの組合せによって決定される。価格設定ルールは、要求から取り出したパラメータから要求された権利について提供される価格を計算するために、許諾決定を下したときに実行される。印税ルールは、権利者に支払うべき印税を計算するために、計算された価格が支払われているときに実行され、特別注文ルールは、特別注文を処理するために実行される。いくつかの場合において、複数の権利者が、単一の権利に関連付けられている。このような場合、価格設定ルールを、単一の全体的価格設定ルールとして、または権利者毎(価格が足し合わされる)に割り当てることができ、または印税ルールを権利者毎に割り当てることができる。それに加えて、制限ルールは、全体的に、または権利者毎に割り当てることができる。
【0016】
それぞれのルールタイプは、計算を実行し、ルールの結果を表す1つまたは複数のルール解決を返す。例えば、制限ルールは、制限到達フラグと制限メッセージを含むLimitRuleResolutionを返す。複数の制限ルールを1つの権利にリンクすることができ、制限に達した場合に、その権利は利用不可能になる。同様に、価格設定ルールは、価格タイプ、価格、メッセージタイプ、およびユーザーに表示するメッセージを含むPricingRuleResolutionのリストを返す。価格設定計算では複数の価格が返される可能性がある(例えば、価格、サービス料金、外貨による価格など)。印税ルールは、価格タイプ、価格、メッセージタイプ、およびメッセージを含むRoyaltyRuleResolutionのリストを返す。特別注文ルールでは、特別注文を処理する仕方を記述し、特別注文の有効なフラグ、メッセージタイプ、およびメッセージを含む特別注文解決を返す。
【0017】
それに加えて、本発明のシステムでは、処理ルールは、要求プロシージャおよび権利の解決を制御する。この後者のルールは、必要な情報を収集するためにグラフィカルユーザーインターフェイスの表示をフォーマットし制御する表示ルール、ユーザー入力をチェックし、その妥当性を確認する妥当性確認ルール、必要ならばユーザーによって入力された情報に加えて情報を集める前処理ルール、および要求が複数の権利と一致したときに単一の権利を選択する解決ルールを含む。
【0018】
表示ルールは、利用のタイプにリンクされる。それぞれの利用のタイプは、典型的には、1つの表示ルールにリンクされるが、単一の表示ルールを複数の利用のタイプにリンクすることもできる。表示ルールは、典型的には、ユーザーに提示する表示パラメータおよび提示の順序を定義する。提示の前および提示中に、表示ルールは、表示目的に合わせて表示パラメータの属性を調節することができる。例えば、表示ルールは、テキストラベルを変更するか、またはいくつかの状況において表示を更新させるか、またはパラメータの他の表示属性を修正することができる。あるいは、表示ルールは、ルールに基づいて「条件付き」パラメータの表示または非表示を決めることができる。例えば、著者フラグパラメータが「真」に設定されている場合、表示ルールは、オーサリングされたページの数の入力を求めるプロンプトを表示することができる。表示ルールは、ユーザーのデータ入力に基づいてステータスフラグも立てる。例えば、動作中に、表示ルールは、価格設定ルールを実行すべきであること、または要求が完了し、買い物かごへの商品の追加およびその後のユーザーからの決済の受け入れをシステムが行える状態にあることを示すフラグを立てることができる。さらに、「更新」フラグと称されるすべてのDisplayParmパラメータのフラグを使用して、表示されているパラメータの値が変更された場合にグラフィカルユーザーインターフェイスを再実行することができる。これにより、パラメータの提示が他のパラメータ値の選択に依存するインタラクティブな動作が可能になる。
【0019】
妥当性確認ルールは、パラメータの入力された値をチェックし、その値が所定の基準を満たしていることを確認する。それぞれの妥当性確認ルールは、1つのパラメータにリンクされる。そのパラメータがグラフィカルユーザーインターフェイスに提示された場合、リンクされている妥当性確認ルールが自動的に実行される。例えば、妥当性確認ルールは、入力されたパラメータ値をチェックして、その入力された値が正整数であることを確認することができる。他の妥当性確認ルールは、入力された日付値をチェックして、その値が妥当な日付範囲内にあるかどうか判定することができる。妥当性確認ルールは、<e>rror、<i>nformationのメッセージタイプコードを含む妥当性確認メッセージおよびグラフィカルユーザーインターフェイスに表示するためのメッセージ本文部を返す。妥当性確認エラーがあった場合、エラーメッセージが表示され、ルールエンジンは、新規値が入力されるか、または処理がキャンセルされるまで一時停止する。
【0020】
前処理ルールは、適宜、他のルールにリンクされ、追加の入力を、もしこれらの追加の入力が必要であれば収集することができる。前処理ルールは、表示する前に、または解決する前に実行されるように設定することができる。前処理ルールの役割は、典型的には、データベース、ウェブサービス、またはhttp要求などの外部ソースに接続し、ルールを解決するために必要な追加の情報を集めることである。前処理ルールは、典型的には、集められた情報をルールに関連付けられている<reference>パラメータ内に格納する。これは、メッセージタイプコードおよびメッセージ本文部を前処理メッセージオブジェクトに初期値として入力することも行う。
【0021】
前処理ルールは、適宜、ルール実行の後にオペレーションを実行するために他のルールにリンクすることができる。これは、便利な機能であり、これにより、多くのルールを拡張する標準的なオペレーションが可能になる。例えば、価格は米国ドルで計算されうるが、多くの場合、その価格を多数の通貨単位で提示することが望ましい。この場合、単一の前処理ルールを定義して、計算された価格を適用可能な通貨に変換するために、複数の通貨でオファーを行うべきすべての価格設定ルールの後に実行することができる。
【0022】
解決ルールは、複数の権利が適用される場合にどの権利をユーザーに表示するかを選択し、これらのルールは、典型的には、利用のタイプにリンクされる。一般に、解決ルールは、制限に達することによって排除されなかった最も実施可能な許可ステータスを伴う最高優先度の権利を選択する。
【0023】
ルールは、
図2Bに示されているルールテーブル212内にレコードとして格納される。それぞれのルールレコードは、名前値、記述値、タイプ値、クラス、および許可コードを含む複数の値を含む。タイプコードは、ルールタイプを示し、これは、価格設定、印税、制限、特別注文、表示、妥当性確認、解決、前処理、および後処理の値を含む。クラス値は、ルールを実行するために作成されるオブジェクトクラスの名前である。許可コード値は、ルールが使用される際に基づく許可ステータスを示す。値は、許諾、事前認可された購入、リンク(権利決定ウェブサイトへの)、パブリックドメイン、および連絡先権利者を含む。これらの値は、ルールテーブル212内の該当するフィールドに格納される。
【0024】
それぞれのルールは、所定のパラメータの値を組み合わせて所定のタスクを実行するソフトウェアコードを備える。ルールは、ソースコードテキストのブロックを保持するためのCLOBフィールド(source_code)を持つルールテーブル212内にレコードとして格納される。定義時に従来のコンパイラを使用してJava(登録商標)ベースのルールをコンパイルし、ソースコードとバイトコード(実行ファイル)の両方を格納する。ルールが必要になったときに、実行コードが取り出されてインスタンス化され、メモリ104のグローバルアプリケーションエリア内のマップオブジェクトになる。次いで、マップオブジェクトから名前でルールインスタンスを取り出し、実行する。このフレームワークでは、非Java(登録商標)(インタプリタ実行)ルールは同じパターンに従うが、ただし、ソースコードはバイトコードにコンパイル済みのクラスの代わりにグローバルアプリケーションエリア内にインスタンス化される点が異なる。
【0025】
Java(登録商標)で書いた、価格設定ルールに対するソフトウェアソースコードの例を以下に示す。
【0027】
上に示されているようなコードは、RuleBaseと称される基底クラスを持つクラス階層を使用して書かれている。この基底クラスのサブクラスは、<RuleType>Base(例えば、PricingRuleBase、RoyaltyRuleBase、DisplayRuleBase)を含み、基底クラスにおいて定義された関数を継承する。このクラスライブラリの結果として、すべてのルールに対するソフトウェアコードは、それに利用可能な一連の関数を有している。価格設定ルールの場合、これらの関数の多くは、「add」、「multiply」、および「round」のような数学的演算を行う関数である。これらの関数により、上の例(例えば、句:multiply(“PER_PAGE_FEE”,“NUMBER_OF_PAGES”))に示されているように、ルールソフトウェアは関係するパラメータに名前でアクセスすることができる。ルールソフトウェアの開発を簡素化し、利便性を高めることに加えて、これらの関数は、追跡性のために実行されるオペレーションをログに自動的に記録し、インタプリタで実行されるスクリプティングメカニズムをサポートするオペレーションを標準化するサービスを提供する。
【0028】
このフレームワークは、RightsRequest、Right、RightRule、およびRuleオブジェクトがコールシグネチャの一部である場合の上に示されているルールシグネチャによって示されているようにルール内にコンテキストを入れる。したがって、ルールソフトウェアは、その実行のコンテキストを構成するすべての変数にアクセスすることができる。したがって、ルールエンジンで実行されるルール実行フローにおいて、権利を定義するルールパラメータおよびユーザーによって入力された要求パラメータだけでなく、選択された利用のタイプ、著作物、権利者、現在の権利、見つかった他の権利、および他の計算の結果に関する情報をも参照する可能性がある(例えば、印税ルールは対応する価格設定ルールによって計算される価格を必要とすることが多い)。
【0029】
ルールデータベースを構成するプロセスにおける次のステップ308では、パラメータをルールにリンクする。パラメータは、複数のルールにリンクすることができ、そのルールのコンテキストに対するデフォルト値を受け入れることができる。価格設定ルール、印税ルール、および特別注文ルールの場合、1つまたは複数のエントリをrule_parmリンクテーブル214内に挿入し、制限ルールの場合、1つまたは複数のエントリをright_rule_lim_parmvalリンクテーブルに挿入することによって、パラメータはルールにリンクされる。これらのエントリは、従来のルールメンテナンス用グラフィカルユーザーインターフェイスの表示によって生成されうる。それぞれのエントリは、リンクされたペアに対するルールおよびパラメータ識別子を含む。それに加えて、妥当性確認ルールを、ルールのコンテキストに対するパラメータにリンクすることができる。これは、rule_parmリンクの識別子および適切な妥当性確認ルールを含むrule_parm_validationリンクテーブル208にエントリを入れることによって行われる。妥当性確認ルールは、入力された情報の妥当性をチェックするために、パラメータ値がユーザーによって入力された後に実行される。
【0030】
次に、ステップ310で、権利を定義し、権利テーブル202にレコードとして格納する。それぞれの権利は、利用のタイプIDをその権利を格納するレコードに入れることによって利用のタイプに関係付けられる。
図2Aに示されているように、複数の権利をそれぞれの利用のタイプに関係付けることができる。権利は、1つまたは複数の著作物、著作物のコレクション、境界パラメータ(例えば、権利は与えられたライセンシータイプについてのみ有効であるものとしてよい)、ロケーション(例えば、権利はユーザーが英国にいる場合にのみ有効であるものとしてよい)、またはフレキシブルな識別子(例えば、データソース、ファイル名、またはURL)に接続することができる。これらの接続は、権利テーブル202内の権利を表すレコード内の適切なフィールドに値を追加することによって確立される。権利は、権利テーブルのレコード内に顧客IDを入れることによって特定の顧客に関連付けることもできる。
【0031】
権利は、一から作成するか、または権利テンプレートから作成することができる。権利テンプレートは単なる事前構成された権利であり、コピーし、その後編集することができる。これらの権利テンプレートは、事前構成され「リンク先」とすることができる、標準権利、権利者が事前構成されるが他のすべての値は修正されうる権利である、標準権利者権利、権利者およびリンクされたルールが事前構成されるが他のパラメータは修正されうる権利である、標準権利者ルール権利、およびルールおよびパラメータが事前構成されるが権利者は修正されうる権利である、標準ルールパラメータ権利を含む。
【0032】
すべてのタイプの権利に、ゼロ、1つまたは複数の契約条件を関連付けることができる。標準権利と同様に、契約条件を自由形式で作成することができ、また、標準契約条件をリンク先とすることができる。契約条件は、参考(非制限的)または制限的と考えることもでき、これは、複数の有効な権利がある場合にどの権利を選択すべきかを決定する際の一決定因子としてよい。
【0033】
すべての権利は、そのソースに基づいて優先度を割り当てられ、この優先度はright_priority_cdフィールドおよびright_priority_valueフィールドに格納される。権利が利用のタイプについて許可を付与するものであろうとなかろうと、優先度値により、一方の権利を他方の権利に優先するものとして選択することができる。所望の著作物を対象とする複数の権利が見つかった場合、一般的に、見つかった最高の優先度と一致する優先度を有する権利のみが考えられる。例えば、第1の権利が第2の権利より高い優先度を有し、両方の権利が結果としてある利用のタイプに対する許諾をもたらす場合、第1の権利が後述のように制限に達したため排除される場合であっても、第2の権利は、見つかった最高のレベルと同じレベルにないため考慮されない。
【0034】
契約は権利に関連付けられているオプションの概念であり、権利は、契約の内に、または契約の外に存在しうる。多くの場合において、契約は、単なる権利者と権利に対する便利なグループ化メカニズムにすぎない。契約の範囲内で権利を構成する場合、権利者、テンプレート、標準権利、およびその契約に付随する権利割り当てグループのみを見ることに対するデータ入力の効率のよさがある。データ編成以外に、契約の概念は、例外リストなどの高度な権利優先順位付けコンストラクトを実装する必要がときどき生じた場合にその要求に応える。
【0035】
契約の中の権利は権利優先度を有する。契約が権利に関連付けられる場合、契約優先度のコードおよび値はそれぞれagreement_priority_cdフィールドおよびagreement_priority_valueフィールドに格納される。権利優先度の例示的な値は、No override、Normal(Less granular)、Same Level、More Granular、Allである。粒度は、権利の接続先となる1つまたは複数の著作物の結果生じるものである。著作物に直接接続されている権利は、最も粒度が細かいと考えられ、コレクションに接続されている権利は、粒度が粗いと考えられる。ほとんどの場合において、Normalの権利優先度が適用されるが、これは、契約の範囲内において、より粒度の細かい権利はより粒度の粗い権利に比べて優先度が高いことを示す。例えば、著作物が契約の範囲内のコレクションに存在し、コレクションは第1の権利に接続され、その著作物が契約内の第2の権利に直接接続されている場合、第2の権利は、より粒度が細かいため第1の権利に比べて優先度が高い。別の場合では、一方のコレクションに含まれることは、他方のコレクションに含まれることに比べて優先度が高いとする、例外コレクションを指定することが可能である。
【0036】
ルールデータベースを構成するプロセスにおける次のステップ312では、ルールを権利にリンクする。権利関係ルールタイプ(価格設定、印税、および特別注文)は、ルールのタイプ毎のエントリを、権利の識別子およびさまざまなルールタイプとともにright_ruleリンクテーブル210内に挿入することによって権利にリンクされる。制限ルールは、エントリをright_rule_limリンクテーブル220内に挿入することによって権利にリンクされる。取引に関する権利については、典型的には、単一の価格設定ルール、単一の印税ルール、およびゼロ、1つ、または複数の制限ルールがある。ルールを権利にリンクした後、構成プロセスは、ステップ314で終了する。
【0037】
図4A〜4Eは、一緒に配置されたときに、権利付与の要求に応答してルールエンジンによって実行される例示的なプロセスにおけるステップを示す流れ図を形成する。権利要求セッションでは、要求に関連付けられている情報を保持するためにRightsRequestオブジェクトが作成される。この情報は、ユーザーによって入力された利用のタイプおよび著作物ID、ユーザー要求コンテキストに適用すると決定された権利、動的に決定される要求パラメータ、表示指定(DisplayRowパラメータの値)、ユーザーによって入力されたパラメータ値、妥当性確認ルールの結果、制限ルールの結果、価格設定/印税ルール計算の結果、ならびに権利解決処理に必要なさまざまなフラグおよびポインタを含む。すべての権利関係ルールは、それぞれのルールが完全な要求コンテキストにアクセスできるよう、入力引数としてRightsRequestオブジェクトを受け取る。例えば、NUMBER_OF_PAGESに対するパラメータ値の妥当性を確認する妥当性確認ルールは、ルール処理中にRightsRequestオブジェクトを使用してARTICLE_START_PAGEおよびARTICLE_END_PAGEに対するパラメータ値にアクセスすることができる。
【0038】
要求プロセスは、ステップ400から始まり、ステップ402に進み、そこで、ルールエンジンプログラムの制御下で、従来のテキストボックスおよびコンボボックスコントロールを備えるグラフィカルユーザーインターフェイス表示を生成し、著作物ID、発効日、およびユーザーIDのタイプを含む基本コンテキスト情報を入力するようユーザーに求める。ロケーション情報は、適宜、ユーザーから要求されうる。ユーザーのインタラクティブな操作の観点からは、要求に対して複数の状態がある。それぞれの状態は、「レディ」フラグに関連付けられており、このフラグは、「真」に設定された場合に、状態が完了しており、システムは次の状態に対して「準備が整っている」ことを示す。これらの状態は、すべての「レディ」フラグが偽に設定されている開始状態を含む。境界パラメータのレディフラグは、境界パラメータのレディ状態に関連付けられており、これは、「真」のときに、適用可能な権利を取り出すことが可能なようにすべての境界パラメータが入力され妥当性確認が済んでいることを示す。解決パラメータのレディ状態では、解決パラメータのレディフラグに対する「真」値は、権利関係ルール(制限ルール、価格設定ルール、および印税ルール)を処理することが可能なようにすべての解決関係パラメータが入力され妥当性確認が済んでいることを示す。ユーザーの支払い金額を徴収するために買い物かごのメタファーが使用される場合、買い物かごパラメータのレディ状態において、関連付けられているフラグの「真」値は、商品を買い物かごに追加してユーザーが要求権利に対する対価を支払うことが可能なようにすべてのパラメータが入力され妥当性確認が済んでいることを示す。
【0039】
ステップ406において、利用のタイプIDを使用して、ルールデータベース内のtou_ruleテーブル206にアクセスし、関連付けられている表示ルールを特定する。利用のタイプに表示ルールが関連付けられていない場合、表示順序に従ってパラメータを単に提示し、それぞれの列に対するデフォルト設定を使用するデフォルトの表示ルールが使用される。一般に、表示ルールは実行されると、それぞれの行(displayRow)および行パラメータ(displayParm)の属性を定義することによってエンドユーザーからどのような入力が要求されるかに関するグラフィカルユーザーインターフェイスの命令を出す。
【0040】
表示ルールが特定された場合、rule_parmテーブル214はルールIDでアクセスされ、境界パラメータがparmテーブル216から取り出される。すでに述べたように、境界パラメータは、権利要求コンテキストに適用可能な権利が存在しているかどうかを判定するために必要である。ステップ408において、そのような境界パラメータが存在しているかどうかの判定が行われる。ステップ408において、境界パラメータが存在していないと判定された場合、プロセスは、オフページコネクタ418および424を介して、以下で説明するステップ430に進む。
【0041】
あるいは、ステップ408において、境界パラメータが存在していると判定された場合、プロセスはステップ410に進み、そこで、すでに特定されている表示ルールを実行する。表示ルールは、DisplayRowおよびDisplayParmパラメータを使用して、適切なコントロールをグラフィカルユーザーインターフェイス上の指定されたロケーションに表示し、境界パラメータを入力するようユーザーに求める。ステップ412で、ルールエンジンが境界パラメータを受け取る。次いで、プロセスは、オフページコネクタ416および422を介して、ステップ426に進み、そこで、それぞれのパラメータに関連付けられている妥当性確認ルールを実行する。ステップ428において、入力されたパラメータ値が有効かどうかの判定が行われる。入力されたパラメータ値が有効でないと判定された場合、プロセスは、オフページコネクタ420および414を介して、ステップ410に戻り、そこで、表示ルールを再実行し、パラメータ値を再入力するようユーザーに求める。
【0042】
ステップ430において、境界パラメータが存在しない場合、または境界パラメータ値が収集され、妥当性確認が行われた後、ルールエンジンは、権利テーブル202にアクセスし、ユーザーコンテキストおよびユーザーによって入力された境界パラメータに適用される権利を取り出す。取り出された権利は、それぞれの権利およびその関係するパラメータを含む権利配列内に置かれる。次いで、ステップ432において、ルールエンジンは、権利ルールテーブルにアクセスし、それぞれの取り出された権利に適用されるさまざまな権利関係ルールを決定する。いくつかの場合において、1つの権利に複数の権利者(および権利ルール)が関連付けられている。これらの場合には、ルールエンジンは、2つのオプションをサポートする。第1のオプションでは、一組の価格設定(または特別注文)、印税、および制限ルールは、それぞれの権利者に関連付けられ、総価格は、すべての計算された価格の合計となり、印税が総価格に基づいて解析されてそれぞれの権利者に送られる。任意の権利者に関連付けられている制限に到達した場合、権利全体が無効である。第2のオプションでは、単一の価格設定ルールがすべての権利者に対して使用され、総価格ルールが最初に計算され、次いで、それぞれの権利者について印税が計算される。任意のレベルの制限に到達した場合、権利全体が無効である。
【0043】
ステップ434において、プロセスは、権利およびコンテキストに適用される関係するルールの組合せに基づいてどの表示ルールを実行するかを決定する。デフォルトの表示ルールは、それぞれの利用のタイプについて、または評価すべきルールの組合せについて指定することができる。例えば、「Number of Pages」パラメータ値のみの入力を求める必要がある価格設定ルールP1および印税ルールR1は、表示ルールD1に関連付けることが可能である。しかし、他の価格設定ルールP2を含めるために「Are you a commercial user?」パラメータ値の入力をさらに求める必要がある場合、この後者のルールグループは、追加のパラメータ値に対し要求される追加の入力を求める操作を扱う異なる表示ルールD2に関連付けることが可能である。全体として、表示ルールの選択に対して、以下の順序が適用される。最初に、処理されるルールが、すべて、利用のタイプに対する表示ルールグループに関連付けられている一組のルールに含まれる場合、その表示ルールが使用される。あるいは、処理されるルールが、すべて、親の利用のタイプに対する表示ルールグループに関連付けられている一組のルールに含まれる場合、その表示ルールが使用される。前記のどれもが適用可能でない場合、その利用のタイプに対するデフォルトのルールが使用される。そのようなデフォルトのルールが適用可能でない場合、親の利用のタイプに対するデフォルトのルールが使用される。ほかに特定されるルールがない場合、システムのデフォルトの表示ルールが使用される。
【0044】
次いで、プロセスは、オフページコネクタ436および438を介して、ステップ440に進み、そこで、決定されたパラメータに対する表示ルールを実行し、必要な値を入力するようユーザーに求める。表示ルールは、ここでもまた、ルールに関連付けられているDisplayRowおよびDisplayParmパラメータ値を使用して、権利解決に必要な要求パラメータをユーザーに提示する。ステップ442において、要求パラメータが受け取られ、ステップ444において、妥当性確認ルールが、受け取ったパラメータについて実行される。ステップ446で、パラメータが有効でないと妥当性確認ルールによって判定された場合、プロセスはステップ440に戻り、そこで、表示ルールを再実行し、必要なパラメータ値を再入力するようユーザーに求める。
【0045】
あるいは、ステップ446において、受け取ったパラメータが有効であると判定された場合、プロセスは、オフページコネクタ448および452を介して、ステップ456に進み、そこで、要求パラメータの入力が完了したかどうかの判定を行う。入力が完了していない場合、プロセスは、オフページコネクタ454および450を介して、ステップ440に戻り、そこで、適切な表示ルールを再実行し、さらにパラメータを入力するようユーザーに求める。権利関係ルールは、関連付けられている表示ルールが解決パラメータのレディフラグを「真」に設定してすべての権利関係ルールパラメータが収集されたことを示す場合にのみ実行できる。
【0046】
あるいは、ステップ456において、すべての必要な要求パラメータを受け取り、妥当性確認を行ったと判定された場合、プロセスはステップ460に進み、そこで、すべての取り出された権利に対する制限ルールを実行する。次いで、ステップ462において、制限ルールが実行された後に有効な権利が残っているかどうかの判定を行う。有効な権利が残っていない場合、プロセスは、利用可能な有効な権利がないことを知らせるメッセージをユーザーに表示し、プロセスは、オフページコネクタ472および476を介して進行し、ステップ488で終了する。
【0047】
あるいは、ステップ462において、有効な権利が存在していると判定された場合、これらの権利は、有効な権利リストに入れられ、次いで、プロセスはステップ466に進み、そこで、まだ有効であるすべての権利に対する価格設定ルールを実行し、その後、ステップ468に進み、そこで、すべての有効な権利に対する印税ルールを実行する。次いで、プロセスは、オフページコネクタ470および474を介して、ステップ478に進み、そこで、複数の有効な権利が存在しているかどうかの判定を行う。ただ1つの有効な権利が存在していると判定された場合、ResolvedRightsReadyフラグを立てて、価格設定が完了していることを示し、プロセスは以下で説明するステップ482に進む。
【0048】
あるいは、ステップ478において、複数の有効な権利が存在していると判定された場合、ステップ480で、権利解決ルールを実行して、有効な権利のうちの1つを選択する。権利解決ルールは、選択されたルールをソートして権利のリストの上に来るようにする。決定を下す際に、権利解決ルールでは、権利の優先度、許可の利用可能性、制限的契約条件が存在しているかどうか、価格(最高額または最低額)、印税、権利者、および他の決定因子などの決定因子を考慮することができる。解決ルールによって権利が選択された後、ResolvedRightsReadyフラグが立てられ、価格設定が完了したことを示す。
【0049】
価格設定が完了したときに、プロセスはステップ482において解決された権利および価格をユーザーに表示する。ステップ484におけるこの時点で、価格設定ルールに関連付けられている表示ルールは、DisplayRowおよびDisplayParmパラメータ値を使用し、ユーザーが権利を購入できるようにグラフィカルユーザーインターフェイスを表示する従来の「買い物かご」ソフトウェアを実行する前に必要になると思われる追加のパラメータに対する値の入力をユーザーに求める。商品は、後者の表示ルールが買い物かごパラメータのレディフラグを「真」に設定してすべての必要なパラメータが収集されたことを示す場合にのみ「買い物かご」に追加することができる。
【0050】
ステップ486において、ルールエンジンは、選択された権利、価格設定、印税、および関係するデータ要素を、ステップ488で示されているような課金、徴収、および最終的には印税支払いを実行する役割を持つ従来の買い物かご、精算、および他の管理用のソフトウェアに送る。ルールエンジンのすべての態様は日付/バージョン変更に対応しており、ユーザーが後日注文を修正したくなった場合に、システムは、原注文の時点において有効であった同じ権利、ルール、およびパラメータを見つけて、修正されたパラメータ値で同じ計算を再処理することができる。
【0051】
本発明は、その多数の実施形態を参照しつつ図示され、説明されているが、当業者であれば付属の請求項による定義に従って本発明の精神および範囲から逸脱することなく本明細書において形態および細部にさまざまな変更が加えられうることを理解するであろう。