(57)【特許請求の範囲】
【請求項１】
建設プロジェクト契約の変動を処理する、コンピュータで実現される方法であって、前記建設プロジェクト契約は、第２の当事者についての請負業者によって建設プロジェクト上で行われるべき仕事について前記請負業者と前記第２の当事者との間のものであり、前記方法は、
前記建設プロジェクト契約の変動提案を受信することに応答して要求オブジェクトデータ構造をコンピュータベースシステムによって生成することを含み、前記変動提案は前記請負業者によって開始され、前記要求オブジェクトデータ構造は少なくとも１つの新しい契約構成要素項目を含み、前記要求オブジェクトデータ構造の前記少なくとも１つの新しい契約構成要素項目は第１の新しい契約構成要素項目を含み、前記第１の新しい契約構成要素項目は、前記第１の新しい契約単位項目の項目ＩＤを識別する項目ＩＤフィールドと、契約予算データ構造における新しい契約単位項目についてのメモリ位置を識別するターゲットフィールドと、前記新しい契約単位項目についての提案値を識別する提案値フィールドとを含み、前記方法はさらに、
前記コンピュータベースシステムの一時的でないコンピュータ読取可能メモリ上に前記要求オブジェクトデータ構造を格納することと、
前記第２の当事者に関連付けられる外部システムに前記要求オブジェクトデータ構造のコピーを送信することと、
前記建設プロジェクト契約の承認された変動を示す応答オブジェクトデータ構造を前記第２の当事者に関連付けられる前記外部システムから前記コンピュータベースシステムによって受信することとを含み、前記応答オブジェクトデータ構造は少なくとも１つの新しい契約構成要素項目を含み、前記応答オブジェクトデータ構造の前記少なくとも１つの新しい契約構成要素項目は第１の新しい契約構成要素項目を含み、前記第１の新しい契約構成要素項目は、ターゲットフィールドと、前記新しい契約単位項目についての承認値を識別する承認値フィールドとを含み、前記方法はさらに、
前記コンピュータベースシステムによってマッチ命令を受信することを含み、前記マッチ命令は、前記要求オブジェクトデータ構造および前記応答オブジェクトデータ構造を、両者が前記請負業者によって開始された前記変動提案に対応すると識別し、前記方法はさらに、
前記マッチ命令を受信することに応答して、対応する前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記項目ＩＤを含むように、応答オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記ターゲットフィールドを自動的に更新することと、
前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記ターゲットフィールドによって識別される前記メモリ位置において前記新しい契約単位項目を含むように前記契約予算データ構造を更新することを含み、前記新しい契約単位項目は、前記応答オブジェクトデータ構造からの前記第１の新しい契約構成要素項目の承認値に基づき規定されるコスト値を含む、方法。
【請求項２】
前記要求オブジェクトデータ構造を生成することは、ステータスフィールドを含む要求オブジェクトデータ構造を生成することを含み、前記ステータスフィールドは、前記要求オブジェクトデータ構造のステータス状態を示し、かつ、前記要求オブジェクトデータ構造が生成されると前記要求オブジェクトデータ構造に第１のステータス状態を割り当て、前記方法はさらに、
前記請負業者からの前記要求オブジェクトデータ構造について提出命令を受信することと、
前記提出命令を受信することに応答して、前記要求オブジェクトデータ構造に第２のステータス状態を割り当てるよう前記ステータスフィールドを更新することと、
前記要求オブジェクトデータ構造の前記ステータス状態が前記第２のステータス状態であることを前記要求オブジェクトデータ構造の前記ステータスフィールドが示す場合にのみ、前記契約予算データ構造における前記新しい契約単位項目についての前記メモリ位置を識別するよう、前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目についての前記ターゲットフィールドを更新することとを含む、請求項１に記載の方法。
【請求項３】
前記要求オブジェクトデータ構造の前記ステータス状態が前記第１のステータス状態であることを前記要求オブジェクトデータ構造の前記ステータスフィールドが示す場合、前記請負業者が前記要求オブジェクトデータ構造の詳細を編集することを可能にすることと、
前記要求オブジェクトデータ構造の前記ステータス状態が前記第１のステータス状態でないことを前記要求オブジェクトデータ構造の前記ステータスフィールドが示す場合、前記請負業者が前記要求オブジェクトデータ構造の前記詳細を編集することを防止することとをさらに含む、請求項２に記載の方法。
【請求項４】
前記請負業者への支払いの要求を前記コンピュータベースシステムによって開始することをさらに含み、前記支払いの要求は、前記応答オブジェクトデータ構造を受信する前に受信され、前記支払いの要求は、前記項目ＩＤによって前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目を識別する、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記応答オブジェクトデータ構造を受信した後にのみ、かつ、前記支払いの要求の要求支払い額が前記応答オブジェクトデータ構造によって規定される前記新しい契約単位項目についての前記承認値よりも大きくない場合にのみ、前記支払いの要求の承認を処理することをさらに含む、請求項４に記載の方法。
【請求項６】
前記建設プロジェクト契約の承認されていない変動を示す第２の応答オブジェクトデータ構造を前記第２の当事者に関連付けられる前記外部システムから前記コンピュータベースシステムによって受信することをさらに含み、前記第２の応答オブジェクトデータ構造は、前記承認された変動を示す前記応答オブジェクトデータ構造の前に受信され始め、前記方法はさらに、
前記コンピュータベースシステムによって第２のマッチ命令を受信することを含み、前記第２のマッチ命令は、前記要求オブジェクトデータ構造および前記第２の応答オブジェクトデータ構造を、両者が前記請負業者によって開始された前記変動提案に対応すると識別する、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記変動提案に対応する前記請負業者への支払いの要求を前記コンピュータベースシステムによって開始することと、
前記第２のマッチ命令を受信した後、かつ、前記承認された変動を示す前記応答オブジェクトデータ構造を受信する前に、前記支払いの要求の承認を処理することとをさらに含む、請求項６に記載の方法。
【請求項８】
前記応答オブジェクトデータ構造を受信することは、対応する前記要求オブジェクトデータ構造より多い少なくとも１つの新しい契約構成要素項目を含む応答オブジェクトデータ構造を受信することを含み、前記応答オブジェクトデータ構造の前記より多い少なくとも１つの新しい契約構成要素項目は第２の新しい契約構成要素項目を含み、前記第２の新しい契約構成要素項目は、ターゲットフィールドと、第２の新しい契約単位項目についての承認値とを含み、前記方法はさらに、
前記契約予算データ構造における前記第２の新しい契約単位項目についてのメモリ位置を識別するよう、前記応答オブジェクトデータ構造の前記第２の新しい契約構成要素項目の前記ターゲットフィールドを自動的に更新することと、
前記要求オブジェクトデータ構造の前記第２の新しい契約構成要素項目の前記ターゲットフィールドによって識別される前記メモリ位置において前記第２の新しい契約単位項目を含むように前記契約予算データ構造を更新することを含み、前記第２の新しい契約単位項目は、前記応答オブジェクトデータ構造の前記第２の新しい契約構成要素項目の承認値に基づき規定されるコスト値を含む、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記ターゲットフィールドが前記要求オブジェクトデータ構造に関連付けられる項目ＩＤを識別する場合に第１のステータス状態を示し、前記ターゲットフィールドが前記契約予算データ構造における新しい契約単位項目についてのメモリ位置を識別する場合に第２のステータス状態を示すよう、前記応答オブジェクトデータ構造の前記少なくとも１つの新しい契約構成要素項目の各新しい契約構成要素項目のステータスフィールドを更新することをさらに含む、請求項８に記載の方法。
【請求項１０】
前記第２の当事者は前記建設プロジェクトについての総合請負業者を含み、前記請負業者は下請け業者を含み、前記方法はさらに、
複数の総合請負業者予算単位項目と各総合請負業者予算単位項目についてのコスト値とを含む前記建設プロジェクトのための総合請負業者予算を前記コンピュータベースシステムの前記一時的でないコンピュータ読取可能メモリ上に格納することと、
前記契約予算データ構造を前記コンピュータベースシステムの前記一時的でないコンピュータ読取可能メモリ上に格納することとを含み、前記契約予算データ構造は、前記複数の総合請負業者予算単位項目の第１の総合請負業者予算単位項目にリンクされ、かつ、複数の契約単位項目および各契約単位項目についてのコスト値を含み、前記方法はさらに、
前記新しい契約単位項目を含むように前記契約予算データ構造を更新することに応答して、前記第１の総合請負業者予算単位項目の前記コスト値を更新することを含む、請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
すべての保留中の変動提案のリストを前記第２の当事者に対してユーザインターフェイス上に表示することをさらに含み、マッチ命令を受信することは、前記すべての保留中の変動提案のリストからの前記要求オブジェクトデータ構造に対応する保留中の変動提案の選択を受信することを含む、請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記応答オブジェクトデータ構造を受信することは、前記要求オブジェクトデータ構造を識別するフィールドを含む応答オブジェクトデータ構造を受信することを含み、前記マッチ命令を受信することは、前記要求オブジェクトデータ構造を識別する前記応答オブジェクトデータ構造の前記フィールドに基づいて、前記要求オブジェクトデータ構造および前記応答オブジェクトデータ構造をペアリングすることを含む、請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
前記マッチ命令を受信することは、前記要求オブジェクトデータ構造および前記応答オブジェクトデータ構造の両方に含まれる同様のデータを識別することによって、前記要求オブジェクトデータ構造が前記応答オブジェクトデータ構造に対応することを自動的に判断することを含む、請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記建設プロジェクト契約の第２の承認された変動を示す第２の応答オブジェクトデータ構造を前記第２の当事者に関連付けられる前記外部システムから前記コンピュータベースシステムによって受信することをさらに含み、前記第２の応答オブジェクトデータ構造は少なくとも１つの新しい契約構成要素項目を含み、前記第２の応答オブジェクトデータ構造の前記少なくとも１つの新しい契約構成要素項目は、ターゲットフィールドと、第３の新しい契約単位項目についての承認値を識別する承認値フィールドとを含む第３の新しい契約構成要素項目を含み、前記方法はさらに、
前記第２の応答オブジェクトデータ構造がいずれの要求オブジェクトデータ構造にもマッチングされないことを確認する命令を受信することと、
前記命令を受信することに応答して、契約予算データ構造における前記第３の新しい契約単位項目についてのメモリ位置を識別するよう、前記第２の応答オブジェクトデータ構造の前記第３の新しい契約構成要素項目の前記ターゲットフィールドを自動的に更新することと、
前記第２の応答オブジェクトデータ構造の前記第３の新しい契約単位項目の前記ターゲットフィールドによって識別される前記メモリ位置において前記第３の新しい契約単位項目を含むよう前記契約予算データ構造を更新することとを含み、前記第３の新しい契約単位項目は、前記第２の応答オブジェクトデータ構造からの前記第３の新しい契約構成要素項目の承認値に基づき規定されるコスト値を含む、請求項１〜１３のいずれか１項に記載の方法。
【請求項１５】
前記第２の応答オブジェクトデータ構造が如何なる要求オブジェクトにもマッチングされないことを確認する前記命令を受信することは、前記第２の当事者からユーザインターフェイスを通じてユーザ入力を受信することを含む、請求項１４に記載の方法。
【請求項１６】
前記第２の応答オブジェクトデータ構造が如何なる要求オブジェクトにもマッチングされないことを確認する前記命令を受信することは、前記第２の応答オブジェクトデータ構造が如何なる要求オブジェクトにも対応しないことを示す、前記第２の応答オブジェクトデータ構造におけるインジケータを自動的に識別することを含む、請求項１４に記載の方法。
【請求項１７】
前記応答オブジェクトデータ構造を受信することは、前記応答オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記承認値フィールドによって識別される前記新しい契約単位項目についての前記承認値が前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記提案値フィールドによって識別される前記新しい契約単位項目についての前記提案値と異なる応答オブジェクトデータ構造を受信することを含む、請求項１〜１６のいずれか１項に記載の方法。
【請求項１８】
コンピュータベース予算管理システム上で予算変動を処理する、コンピュータによって実現される方法であって、
一時的でないコンピュータ読取可能メモリ上に契約予算データ構造を格納することを含み、前記契約予算データ構造は、合計契約予算額と、複数の契約予算単位項目オブジェクトと、前記複数の契約予算単位項目オブジェクトの各契約予算単位項目オブジェクトについての単位項目値とを含み、前記方法はさらに、
プロジェクト上で第１のユーザによって行なわれる仕事についての第１の支払いの要求を前記第１のユーザから前記コンピュータベース予算管理システムによって受信することを含み、前記第１の支払いの要求は少なくとも１つの契約予算単位項目オブジェクトを参照しており、前記方法はさらに、
前記契約予算データ構造の前記合計契約予算額への新しい変動の要求を前記第１のユーザから前記コンピュータベース予算管理システムによって受信すること、
前記新しい変動の要求を受信することに応答して、予算変動提案データ構造を生成することとを含み、前記予算変動提案データ構造は契約構成要素項目を含み、前記契約構成要素項目は、項目ＩＤと、前記契約予算データ構造に加えられるべき提案された新しい契約予算単位項目オブジェクトの値とを含み、前記方法はさらに、
前記プロジェクト上で前記第１のユーザによって行なわれる仕事についての第２の支払いの要求を前記第１のユーザから前記コンピュータベース予算管理システムによって受信することを含み、前記第２の支払いの要求は、前記予算変動提案データ構造の前記提案された新しい契約予算単位項目オブジェクトを参照する、方法。
【請求項１９】
プロジェクト予算データ構造を前記一時的でないコンピュータ読取可能メモリ上に格納することをさらに含み、前記プロジェクト予算データ構造は、複数の単位項目オブジェクトと、前記複数の単位項目オブジェクトの各単位項目オブジェクトについての単位項目値とを含み、
前記プロジェクト予算データ構造の前記複数の単位項目オブジェクトの第１の単位項目オブジェクトは、前記第１の単位項目オブジェクトの前記単位項目値が前記契約予算データ構造の合計契約予算額と等しくなるように前記契約予算データ構造に関連付けられ、前記方法はさらに、
前記契約予算データ構造の前記合計契約予算額への前記新しい変動の要求の承認を第２のユーザから受信することと、
前記予算変動提案データ構造の前記新しい提案された契約予算単位項目オブジェクトを含むように前記契約予算データ構造を更新することと、
前記提案された新しい契約予算単位項目オブジェクトの値に基づいて前記契約予算データ構造の合計契約予算額を増加させることと、
前記契約予算データ構造の増加された前記合計契約予算額に等しくなるように前記プロジェクト予算データ構造の前記第１の単位項目オブジェクトの前記単位項目値を更新することとを含む、請求項１８に記載の方法。
【請求項２０】
前記第２の支払いの要求を受信することは、前記契約予算データ構造の前記合計契約予算額への前記新しい変動の要求の前記承認を第２のユーザから受信する前に前記第２の支払いの要求を受信することを含む、請求項１９に記載の方法。
【請求項２１】
建設プロジェクト契約の変動を処理するように構成される建設プロジェクト契約および予算システムであって、前記建設プロジェクト契約は、第２の当事者についての請負業者によって建設プロジェクト上で行われるべき仕事について前記請負業者と前記第２の当事者との間のものであり、前記予算システムは、
プロセッサと、
命令を格納する一時的でないコンピュータ読取可能メモリとを含み、前記命令は、前記プロセッサによって実行されると、前記予算システムに
前記建設プロジェクト契約の変動提案を受信することに応答して要求オブジェクトデータ構造を生成することを行わせ、前記変動提案は前記請負業者によって開始され、前記要求オブジェクトデータ構造は少なくとも１つの新しい契約構成要素項目を含み、前記要求オブジェクトデータ構造の前記少なくとも１つの新しい契約構成要素項目は第１の新しい契約構成要素項目を含み、前記第１の新しい契約構成要素項目は、前記第１の新しい契約単位項目の項目ＩＤを識別する項目ＩＤフィールドと、契約予算データ構造における新しい契約単位項目についてのメモリ位置を識別するターゲットフィールドと、前記新しい契約単位項目についての提案値を識別する提案値フィールドとを含み、前記命令はさらに、前記プロセッサによって実行されると、前記予算システムに
前記一時的でないコンピュータ読取可能メモリ上に前記要求オブジェクトデータ構造を格納することと、
前記第２の当事者に関連付けられる外部システムに前記要求オブジェクトデータ構造のコピーを送信することと、
前記建設プロジェクト契約の承認された変動を示す応答オブジェクトデータ構造を前記第２の当事者に関連付けられる前記外部システムから受信することとを行わせ、前記応答オブジェクトデータ構造は少なくとも１つの新しい契約構成要素項目を含み、前記応答オブジェクトデータ構造の前記少なくとも１つの新しい契約構成要素項目は第１の新しい契約構成要素項目を含み、前記第１の新しい契約構成要素項目は、ターゲットフィールドと、前記新しい契約単位項目についての承認値を識別する承認値フィールドとを含み、前記命令はさらに、前記プロセッサによって実行されると、前記予算システムに
前記要求オブジェクトデータ構造および前記応答オブジェクトデータ構造を、両者が前記請負業者によって開始された前記変動提案に対応すると識別するマッチ命令を受信することと、
前記マッチ命令を受信することに応答して、対応する前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記項目ＩＤを含むように、応答オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記ターゲットフィールドを自動的に更新することと、
前記要求オブジェクトデータ構造の前記第１の新しい契約構成要素項目の前記ターゲットフィールドによって識別される前記メモリ位置において前記新しい契約単位項目を含むように前記契約予算データ構造を更新することを行わせ、前記新しい契約単位項目は、前記応答オブジェクトデータ構造からの前記第１の新しい契約構成要素項目の承認値に基づき規定されるコスト値を含む、予算システム。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
本開示は、予算を追跡および管理するためのシステムおよび方法に関する。特に、本願明細書において記載されるシステムは、建設プロジェクトについての確定した予算に対する変動（variation）を処理および追跡し、これにより代金請求および支払処理をコントロールする。
【発明の概要】
【課題を解決するための手段】
【０００２】
概要
電子処理の改善を具現化するシステムおよび方法が提供され、当該システムおよび方法によって、請負業者は、プロジェクト契約に対する変動が別の当事者によって承認される前でも、プロジェクト契約に対する変動提案を開始し、当該変動提案に対する支払いを要求することができる。いくつかの実現例では、電子処理の改善によって、請負業者によって生成された変動提案と、別の当事者によって生成された変動評価との間での電子マッチング処理の実現により、変動が承認される前に、請負業者が支払いを受けることが可能になる。変動提案を表すデータ構造が生成され、当該データ構造は、変動提案が、検討され、承認され、プロジェクトについて（たとえば新しい契約構成要素として）実際の予算の一部になるように引き上げられると、維持される。同じデータ構造が処理の全体にわたって、かつ、変動提案が承認された後に維持されるので、変動提案が承認される前にデータ構造に対して行われた支払いの要求、支払いおよび任意の他のアクションが承認後の実際の予算に自動的にリンクされ、これにより、当該契約への変動があたかも上記別の当事者によって作成されたかのように外部会計システムによって認識および処理される。
【０００３】
一実施形態では、第２の当事者についての請負業者によって建設プロジェクト上で行われるべき仕事について請負業者と第２の当事者との間の建設プロジェクト契約の変動を処理するための方法が提供される。いくつかの実施形態では、第２の当事者は建設プロジェクトについての総合請負業者であり、請負業者は総合請負業者によって雇われた下請け業者である。請負業者によって開始される建設プロジェクト契約の変動提案を受信することに応答して、要求オブジェクトデータ構造がコンピュータベースシステムによって生成される。要求オブジェクトは、第１の新しい契約構成要素項目を含み、いくつかの実施形態では、複数の新しい契約構成要素項目を含む。要求オブジェクトの第１の新しい契約構成要素項目は、第１の新しい契約構成要素項目の項目ＩＤを識別する項目ＩＤフィールドと、契約予算データ構造における新しい契約構成要素についてのメモリ位置を識別するターゲットフィールドと、新しい契約構成要素についての提案値を識別する提案値フィールドとを含む。要求オブジェクトは、コンピュータベースシステムの一時的でないコンピュータ読取可能メモリ上に格納され、コピーが第２の当事者（たとえば総合請負業者）に関連付けられる外部システムに送信される。その後、システムは、建設プロジェクト契約の変動評価を示す応答オブジェクトを外部システムから受信する。要求オブジェクトのように、応答オブジェクトは、第１の新しい契約構成要素項目と、おそらく複数の新しい契約構成要素項目とを含む。応答オブジェクトの第１の新しい契約構成要素項目は、ターゲットフィールドと、新しい契約単位項目についての承認値を識別する承認値フィールドとを含む。マッチ命令は、要求オブジェクトおよび応答オブジェクトを、両者が請負業者によって開始された同じ変動提案に対応すると識別し、応答オブジェクトの第１の新しい契約構成要素項目のターゲットフィールドは、対応する要求オブジェクトの第１の新しい契約構成要素項目の項目ＩＤを含むように自動的に更新される。次いで、要求オブジェクトデータ構造の第１の新しい契約構成要素項目のターゲットフィールドによって識別されるメモリ位置において新しい契約単位項目を含むように契約予算データ構造が更新される。新しい契約単位項目に関連付けられるコスト値は、応答オブジェクトからの承認値に基づいて規定される。
【０００４】
いくつかのそのような実施形態では、変動評価は、承認された変動または承認されていない変動のいずれかを含み得る。承認された変動は承認された契約予算の一部分になり、第２の当事者は請負業者によって提案された値での変動を承認し得、変動提案値または構造を編集し得、または、予算値にゼロにセットすることにより変動提案を拒絶し得る。承認されていない変動は変動提案にマッチングされ得るが、承認された契約予算の一部にならない。代わりに、承認されていない変動は、変動提案が外部システムによって認識されていることの確認として機能する。いくつかの実施形態では、システムは、変動提案が外部システムからの承認されていない変動にマッチングされているかぎり、第２の当事者が変動提案に対して要求されている支払いを承認することを可能にする。
【０００５】
別の実施形態では、コンピュータベース予算管理システム上で予算変動を処理するための方法が提供される。契約予算データ構造が一時的でないコンピュータ読取可能メモリ上に格納される。契約予算データ構造は、合計契約予算額と、複数の契約予算単位項目オブジェクトと、各契約予算単位項目オブジェクトについての単位項目値とを含む。１つ以上の予算単位項目オブジェクトに対応する、プロジェクト上で第１のユーザによって行なわれる仕事についての支払いの要求は、第１のユーザから受信され、適切な契約予算単位項目への参照を含む。契約予算データ構造の合計契約予算額への新しい変動の要求も第１のユーザから受信され得、これに応答して、システムは予算変動提案データ構造を生成する。予算変動提案データ構造は少なくとも１つの契約構成要素項目を含んでいる。予算変動提案データ構造における各契約構成要素項目は、項目ＩＤと、契約予算データ構造に加えられるべき提案された新しい契約予算単位項目オブジェクトの値とを含む。予算変動提案データ構造が作成された後、第１のユーザは、契約予算データ構造から予算単位項目オブジェクトを参照する代わりに、新しい予算変動提案データ構造を参照する、第１のユーザによって行なわれる仕事についての支払いの要求を開始し得る。
【０００６】
いくつかの実施形態では、契約への変動提案が別の当事者によって検討および承認される前でも、新しい予算変動提案データ構造を参照する支払いの要求が、受信され得る。しかしながら、他の実施形態では、新しい予算変動提案データ構造は、支払いの要求が承認され得る前に、第１のユーザに支払いをすることを担う第２のユーザによって作成される対応する予算変動評価データ構造にマッチングされなければならない。
【０００７】
本発明の他の局面は、詳細な説明および添付の図面を考慮することによって明白になるであろう。
【図面の簡単な説明】
【０００８】
【図１Ａ】一実施形態に従った変動管理機能を有する建築支払管理システムのブロック図である。
【図１Ｂ】図１の建築支払管理システムによって実現されるさまざまなモジュールのブロック図である。
【図１Ｃ】図１Ａの建築支払管理システムのメモリ上に格納された階層構造をなした契約／予算構造のブロック図である。
【図２】図１のシステム上で実現される、確定された契約／予算に従って支払いを処理するための方法のフローチャートである。
【図３】図１のシステムを使用して下請け業者によって提案される下請契約変動を処理するための１つの方法のフローチャートである。
【図４Ａ】図１のシステムを使用して下請け業者によって提案される下請契約変動を処理するための別の方法のフローチャートである。
【図４Ｂ】図１のシステムを使用して、変動提案を検討、承認、および処理するための方法のフローチャートである。
【図４Ｃ】図１のシステムを使用して、変動提案に基づいて支払いを要求および処理するための方法のフローチャートである。
【図５】図１のシステムを使用して下請け業者に対して表示されるプロジェクトホームページのスクリーンショットの図である。
【図６】図１のシステムにおける変動提案を受信するために下請け業者に表示されるグラフィックユーザインターフェイスのスクリーンショットの図である。
【図７】図１のシステムを使用して下請け業者に対して予算変動提案および承認された予算変動のリストを表示するグラフィックユーザインターフェイスのスクリーンショットの図である。
【図８】図１のシステムを使用して、総合請負業者に対して表示されるプロジェクトホームページのスクリーンショットの図である。
【図９】図１のシステムにおいて、変動評価を変動提案にマッチングするために総合請負業者に表示されるグラフィックユーザインターフェイスのスクリーンショットの図である。
【図１０】図１のシステムを使用して総合請負業者に対して予算変動提案および承認された予算変動のリストを表示するグラフィックユーザインターフェイスのスクリーンショットの図である。
【図１１】図１のシステムを使用して、下請け業者に対して表示されるとともに、支払いの要求を入力するために使用されるグラフィックユーザインターフェイスのスクリーンショットの図である。
【図１２】図１のシステムを使用して、総合請負業者に対して表示されるとともに、下請け業者から受信される支払いの要求を承認するために使用されるグラフィックユーザインターフェイスのスクリーンショットの図である。
【図１３】図１のシステムを使用して、総合請負業者に対して表示されるとともに支払いに先立って下請け業者から受信される支払いの要求を修正するために使用されるグラフィックユーザインターフェイスのスクリーンショットの図である。
【図１４】図２および図３の方法を使用して、承認されていない変動提案に対する予算変動および支払い請求を受信および処理するためのデータ格納および処理フローのブロック図である。
【図１５】図４Ａ、図４Ｂおよび図４Ｃの方法を使用して、承認されていない変動提案に対する予算変動および支払い請求を受信および処理するためのデータ格納および処理フローのブロック図である。
【図１６Ａ】図１Ａのシステムにおける、変動提案に対応する要求オブジェクトと、変動評価に対応する応答オブジェクトとについてのデータライフサイクルのフローチャートである。
【図１６Ｂ】外部ＥＲＰシステムから受信された応答オブジェクトデータ構造をＣＰＭＳによって生成された要求オブジェクトデータ構造にマージするための方法のフローチャートである。
【図１７】第１の例において下請け業者から変動提案を受信することに応答して、図１Ａのシステムによって生成される要求オブジェクトデータ構造の図である。
【図１８】第１の例において変動提案が下請け業者によって提出された後の図１７の要求オブジェクトデータ構造の図である。
【図１９】第１の例における図１ＡのシステムにおいてＥＲＰシステムによって生成されるとともにＣＰＭＳによって受信される応答オブジェクトデータ構造の図である。
【図２０】第１の例において応答オブジェクトデータ構造が図１８の要求オブジェクトデータ構造とマッチングおよびマージされた後の図１９の応答オブジェクトデータ構造の図である。
【図２１】第１の例において、図１Ａのシステムにおける初期の格納された総合請負業者予算データ構造の図である。
【図２２】第１の例において、図２１の総合請負契約予算データ構造からの単位項目に対応する初期の格納された下請契約予算データ構造の図である。
【図２３】第１の例において、図１８の要求オブジェクトデータ構造がプロモートされた後の図２２の格納された下請契約予算データ構造の図である。
【図２４】第１の例において、図２０の応答オブジェクトデータ構造が図１Ａのシステムによって処理された後の図２１の格納された総合請負契約予算データ構造の図である。
【図２５】第１の例において、図２０の応答オブジェクトデータ構造が図１Ａのシステムによって受信および処理された後の図２３の格納された下請契約予算データ構造の図である。
【図２６】第１の例において、変動提案を承認する図２０の応答オブジェクトデータ構造が図１Ａのシステムによって受信および処理される前に変動提案に対して支払いの請求が下請け業者によって提出される場合の図２５の格納された下請契約予算データ構造の代替的な図である。
【図２７】第２の例において、下請け業者から変動提案を受信することに応答して図１Ａのシステムによって生成される要求オブジェクトデータ構造の図である。
【図２８】第２の例において変動提案が下請け業者によって提出された後の図２７の要求オブジェクトデータ構造の図である。
【図２９】第２の例において、図１ＡのシステムにおいてＥＲＰシステムによって生成されるとともにＣＰＭＳによって受信される応答オブジェクトデータ構造の図である。
【図３０】第２の例において、応答オブジェクトデータ構造が図２８の要求オブジェクトデータ構造にマッチングおよびマージされた後の図２９の応答オブジェクトデータ構造の図である。
【図３１】第２の例において、変動提案を承認する図３０の応答オブジェクトデータ構造が図１Ａのシステムによって受信および処理された後の格納された下請契約予算データ構造の図である。
【図３２】第３の例において、下請け業者から変動提案を受信することに応答して、図１Ａのシステムによって生成される要求オブジェクトデータ構造の図である。
【図３３】第３の例において変動提案が下請け業者によって提出された後の図３２の要求オブジェクトデータ構造の図である。
【図３４】第３の例において、図１ＡのシステムにおいてＥＲＰシステムによって生成されるとともにＣＰＭＳによって受信される応答オブジェクトデータ構造の図である。
【図３５】第３の例において、応答オブジェクトデータ構造が図３３の要求オブジェクトデータ構造にマッチングおよびマージされた後の図３４の応答オブジェクトデータ構造の図である。
【図３６】第３の例において、変動提案を承認する図３５の応答オブジェクトデータ構造が図１Ａのシステムによって受信および処理された後の格納された下請契約予算データ構造の図である。
【発明を実施するための形態】
【０００９】
詳細な説明
本発明のいずれの実施形態も詳細に説明される前に、本発明は、その適用において、構成の詳細と、以下の記載において述べられるまたは添付の図面において示される構成要素の配置とに限定されていないということが理解されるべきである。本発明は、他の実施形態において実現可能であり、さまざまな態様で実施または実行可能である。さらに、本願明細書において使用される語法および用語は、説明目的のためであり、限定的であるとみなされるべきでないと理解されるべきである。「含む」、「備える」または「有する」およびそれらのバリエーションの本願明細書における使用は、その後に述べられる項目と、その同等物と、付加的な項目とを包含するよう意図される。他の態様で特定または限定されなければ、「搭載される」、「接続される」、「支持される」、および「結合される」という用語、ならびに、それらのバリエーションは、広く使用されており、直接的および間接的な搭載、接続、支持および結合の両方を包含する。
【００１０】
さらに、本発明の実施形態は、議論の目的のために、大多数のコンポーネントがハードウェア単体で実現されているかのように例示および記載され得るハードウェア、ソフトウェア、および、電子コンポーネントまたはモジュールを含み得るということが理解されるべきである。しかしながら、当業者であれば、この詳細な説明を読んだことに基づいて、少なくとも１つの実施形態において、本発明の電子ベースの局面は、マイクロプロセッサおよび／または特定用途向けＩＣ（「ＡＳＩＣ： application specific integrated circuit」）のような１つ以上の処理ユニットによって実行可能である（たとえば一時的でないコンピュータ読取可能媒体上に格納された）ソフトウェアにおいて実現され得るということを認識するであろう。したがって、複数のハードウェアおよびソフトウェアベースのデバイス、ならびに、複数の異なる構造的構成要素が本発明を実現するために利用されてもよい。たとえば、明細書において記載される「サーバ」および「コンピューティングデバイス」は、１つ以上の処理ユニットと、１つ以上のコンピュータ読取可能媒体モジュールと、１つ以上の入出力インターフェイスと、コンポーネント同士を接続するさまざまな接続部（たとえばシステムバス）とを含み得る。
【００１１】
さらに、建設プロジェクトインタラクションおよびドキュメンテーションのための特定の用語は、異なる司法、特定の文脈、および参加者の好みの間で変動し得るということが理解されるべきである。たとえば、プロジェクト参加者は、「インボイス」、「進捗請求」、「支払い申請」、「請求書作成」、または、「振り出しパッケージ（draw package）」を含む支払いの要求を提出し得る。いくつかの国およびいくつかのプロジェクトでは、支払いは、「振り出し」と呼ばれる処理において、規定された支払期間の終わりに一括で行なわれる。しかしながら、「振り出し」の文脈で以下に議論される例は、他のタイプの構造化された支払い期間または構造化されていない断続的な支払いに容易に適合され得る。同様に、文脈および取決められた実務に依存して、たとえば、「変動」という用語は、「変更依頼」、「変動依頼」あるいは「購入依頼」に相互に交換され得る。同様に、本願明細書において記載される例は、「総合請負業者」および「下請け業者」を参照する。これらのプロジェクト参加者は、いくつかの文脈および現場においては他の名称を有することが理解される。たとえば、「総合請負業者」は、「元請負業者」あるいは「主請負業者」と交換可能に称され得る。同様に、いくつかの文脈では、「契約単位項目」および「契約構成要素」のような用語は交換可能に使用され得る。最後に、予算という用語は、プロジェクトのための財務予測、計画および制約条件を確立するために使用されるさまざまな構成要素およびインタラクションを広く指すことが意図される。したがって、別段の定めがない限り、「予算」という用語は、「予定値（schedule of values）」、「作業分解（work breakdown）」、「作業分解構造（work breakdown structure）」、および／または「単位項目詳細（line item detail）」を含むと広く解釈されるべきであり、または、いくつかの文脈では、そのような用語と交換可能に使用され得る。地域の言い方および習慣に特有であり得るか、または、交換可能に事業のプレファレンスに従うこれらの用語および他の用語は、本願明細書において使用される程度まで、建築業、銀行業および不動産業において適切であろうように、同様の対応するインタラクションおよびドキュメンテーションについての任意の対応する用語を含むよう十分に広く解釈されるべきである。
【００１２】
図１Ａは、複数の参加者を伴う複数の建設プロジェクトのための建設プロジェクト支払い処理を同時に管理するためのネットワークベースのコンピュータシステム１００を示す。建築支払管理システム（「ＣＰＭＳ： construction payment management system」）サーバ１０１は、プロセッサ１０３およびメモリ１０５を含んでおり、メモリ１０５は、以下に記載されるシステム機能を提供するためにプロセッサ１０３によって実行される命令を格納する。メモリ１０５は、たとえばハードディスク、フラッシュメモリ、または、他のタイプのＲＡＭおよびＲＯＭメモリユニットのような１つ以上の一時的でないコンピュータ読取可能メモリを含んでいる。プロセッサ１０３は、マイクロプロセッサ、マイクロコントローラ、ＰＣコンピュータプロセッサ、マルチコアパイプラインプロセッサ、または、並列処理システムコントローラのうちの１つ以上を含むさまざまな商業的に入手可能な処理ユニットを含み得る。
【００１３】
ＣＰＭＳサーバ１０１は、入出力（「Ｉ／Ｏ」）モジュール１０７を通じて、さまざまな他のネットワーク化されたシステムと通信する。たとえば、ユーザは、クライアント端末１０９を通じてＣＰＭＳサーバ１０１にアクセスし得る。クライアント端末１０９は、ＣＰＭＳサーバ１０１に直接的に接続されるか、または、ローカルエリアネットワークを通じてＣＰＭＳサーバ１０１に接続される。代替的または付加的には、クライアント端末１１１，１１３は、インターネット１１５を通じてＣＰＭＳサーバ１０１にアクセスし得る。クライアント端末１０９，１１１，１１３は、たとえば、特にＣＰＭＳサーバ１０１にインターフェイス接続するように設計された専用端末と、ウェブページインターフェイスを通じて、または、デスクトップコンピュータ上で実行されるソフトウェアプログラムを通じて、ＣＰＭＳサーバ１０１にアクセスするデスクトップコンピュータとを含むさまざまな態様で実現され得る。
【００１４】
ＣＰＭＳサーバ１０１はさらに、さまざまな外部プロジェクトおよび予算管理システムとインターフェイス接続するように構成される。たとえば、ＣＰＭＳサーバ１０１は、総合請負業者の外部エンタープライズリソースプランニング（「ＥＲＰ： Enterprise Resource Planning」）システム１１７に（直接的にまたはインターネット接続を介して）通信可能に結合され得る。総合請負業者は、この外部ＥＲＰシステム１１７を使用して、プロジェクト予算を計画および追跡し、リソースおよび設備を割り当て、支払いを処理し、プロジェクトステータスを追跡し得る。ＥＲＰシステム１１７の機能のうちのいくつかは、ＣＰＭＳサーバ１０１によって提供される機能とインタラクションする。
【００１５】
ＣＰＭＳサーバ１０１はさらに、１つ以上の外部のバンキング／支払システム１１９とインターフェイス接続するように構成される。これにより、ＣＰＭＳサーバ１０１は、ＣＰＭＳサーバ１０１を通じて生成、処理および承認される支払いの要求（たとえばインボイス、進捗請求など）に応答してバンキングシステム１１９に支払指示を送り得る。
【００１６】
図１Ａにおいて示されるようなＣＰＭＳシステムの例は、米国特許番号第７，９２５，５８４号にさらに詳細に記載されており、その全内容が本願明細書において参照により援用される。図１Ａの例は、単一のプロセッサ１０３およびメモリ１０５を有する単一のユニットとしてＣＰＭＳサーバ１０１を示すが、いくつかの実現例では、ＣＰＭＳサーバ１０１は、複数の並列処理コアを有するコンピュータサーバ、複数の内部メモリユニットを有するコンピュータサーバ、複数の外部メモリユニット（もしくはクラウドベースのストレージ）とインタラクションするコンピュータサーバ、または、複数のネットワーク化されたコンピュータサーバの連なりを含み得る。したがって、別段の定めがない限り、本願明細書において使用される句および用語は、単一の物理コンポーネントまたは複数の物理コンポーネントを含むと解釈されるべきである。たとえば、本願明細書において使用されるような「メモリ」という句は、単一のメモリユニットまたは複数の別個のメモリユニットを含み得、本願明細書において使用されるような「プロセッサ」という用語は、単一のプロセッサまたは複数の別個のプロセッサを含み得、本願明細書において使用されるような「ＣＰＭＳサーバ」という用語は、単一のサーバ実現例または複数のネットワーク化されたサーバを含み得、本願明細書において使用されるような「ＣＰＭＳ」という用語は、単一のコンピュータ（たとえばＣＰＭＳサーバ１０１）または複数のネットワーク化されたコンピュータシステム（たとえばＣＰＭＳサーバ１０１、クライアント端末１０９，１１１，１１３）を含み得る。
【００１７】
ＣＰＭＳ１０１は、本願明細書における例において記載される機能を提供するモジュールの連なりを実現するように構成される。たとえば、図１Ｂに示されるように、ＣＰＭＳ１０１は、通知／操作指示モジュール１２５、支払要求モジュール１２７、保持モジュール１２９、予算調整モジュール１３１、変動追跡モジュール１３３、および、予算更新モジュール１３５を実現する。以下にさらに詳細に記載されるように、通知／操作指示モジュール１２５によって、ＣＰＭＳ１０１は、ＣＰＭＳ１０１上でのあるイベントまたはアクションの発生を検出し、１人以上のユーザに対して表示されるべき通知を生成する。たとえば、当該通知は、メモリ上に格納され特定のユーザに関連付けられる特定のＥメールアドレスへ送られるＥメールとして、および／または、ユーザのプロジェクトホームページスクリーンに表示されるべきテキスト形式の通知として生成される。通知を受けたユーザによってさらに別のアクションが必要とされる場合、通知／操作指示モジュールは、当該通知にテキストまたは選択可能なリンクを含めて、通知を受けたユーザが１つ以上の必要なアクションを行なうように指示する。
【００１８】
支払要求モジュール１２７を通じて、ＣＰＭＳ１０１は、システムユーザからの支払い要求情報を要求および収集し、検討および／または承認のために別のユーザに当該支払い要求を伝える。保持モジュール１２９は、処理／承認の準備がまだできていない要求およびドキュメントを一時的に保持および格納する。
【００１９】
予算調整モジュール１３１を通じて、ＣＰＭＳ１０１は、プロジェクトに関連付けられるユーザについてさまざまな予算データを格納および維持する。以下にさらに詳細に議論されるように、変動追跡モジュール１３３は、変動提案および変動評価のステータスを追跡する。たとえば、予算更新モジュール１３５は、ユーザからの承認された変動および修正された予定値に基づいて、格納されている予算データ構造を更新する。
【００２０】
図１Ｂに示されるモジュールは例であり、ＣＰＭＳサーバ１０１のさまざまな実際の実現例は、付加的なモジュール、より少数のモジュール、または、代替的なモジュールを実現するように構成されてもよい。この例では、各モジュールは、所定の態様でＣＰＭＳ１０１を機能させるようプロセッサによって実行されるソフトウェア命令の連なりとして実現される。各モジュールは、単一のコンピュータ上の単一のプロセッサによって実行されるか、または、１つ以上のコンピュータサーバ上の複数のプロセッサによって実行される格納されたコンピュータ命令の別個のセクションとして実現され得る。さらに、いくつかの実現例では、少なくともいくつかのモジュールは、単一のモジュールに関連付けられる命令のみを実行する単一の専用プロセッサとして実現され得る。
【００２１】
ＣＰＭＳサーバ１０１は、システムによって管理される各建設プロジェクトについて階層的契約／予算情報を格納および維持する。ＣＰＭＳサーバ１０１はさらに、格納および維持された契約および予算に従って支払いを促進する。図１Ｃは、ＣＰＭＳサーバ１０１上に格納されるとともにＣＰＭＳサーバ１０１によって維持される１つのそのような階層的に構造化されたプロジェクト予算の例を示す。各プロジェクトは、プロジェクトについての全コストの合計を示すプロジェクト契約１５１によって最も高いレベルで規定される。総合プロジェクト契約１５１は、総合請負契約単位項目１５３，１５５の連なりによってさらに規定される。総合請負業者は、各契約単位項目１５３について予定値（ＳＯＶ： schedule of values）１５７を規定し得る。予定値は、１つ以上のＳＯＶ単位項目（たとえばＧＣ  ＳＯＶ単位１、ＧＣ  ＳＯＶ単位２およびＧＣ  ＳＯＶ単位３）を含んでいる。
【００２２】
たとえば、総合請負業者は、プロジェクトに関連付けられる仕事を仕事タイプに分割し得、電気、配管工事、材料などについて別個の総合請負契約単位項目を規定し、各カテゴリーに値（すなわち全プロジェクト値の一部分）を規定する。「電気」の契約単位項目１５３に対応するＧＣ予定値１５７はさらに、図１Ｃに示されるように複数のＳＯＶ単位項目を含んでいる。代替的には、ＧＣは、プロジェクトについてのすべての電気工事を提供するよう電気の下請け業者と契約を結び得る。そのような場合、契約単位項目１５３についてのＧＣ予定値１５７は、単一のＧＣ  ＳＯＶ単位項目のみを含み得る。さらに、いくつかの実現例では、総合プロジェクト契約は、単一の合計の値のみを含んでおり、複数の契約単位項目を規定する代わりに、総合請負業者は、合計のプロジェクト契約値に基づいて直接的に複数のＳＯＶ単位項目を規定し、これにより、図１Ｃに示されるように「契約単位項目」層（すなわち契約単位項目１５３，１５５）を省略する。
【００２３】
ＧＣ  ＳＯＶ１５７における各ＳＯＶ単位項目は、総合請負業者が負う直接的なコスト（すなわちＧＣが直接的に提供する材料および労働）を識別するか、または、総合請負業者と１つ以上の下請け業者もしくは材料サプライヤーとの間の下請契約（たとえば下請契約１５９、下請契約１６１、および下請契約１６３）に対応する。特定の下請契約に関連付けられる仕事および材料は、１つ以上の下請契約単位項目１６５，１６７によってさらに規定される。下請け業者は１つ以上の特定の下請契約を通じてプロジェクトにリンクされ、当該下請け業者は次いで、各下請契約単位項目について予定値を作成することができる。たとえば、ＳＯＶ１６９は、下請契約単位項目１６５について当該下請け業者によって作成される。下請け業者ＳＯＶ１６９は、下請契約単位項目１６５について下請け業者によって行なわれる特定のタスクまたは提供される材料に対応する１つ以上のＳＯＶ単位項目を含んでいる。さらに、各ＳＣ  ＳＯＶ単位項目はさらに、下請け業者とさらに下層の請負業者との間の別の下請契約に対応し得、これにより、多層階層構造のプロジェクトおよび予算システムを実現する。代替的には、１つ以上の個々の下請契約単位項目は、ＧＣ  ＳＯＶ単位項目に直接的にリンクされ得る。そのような実現例において、下請契約（すなわち下請契約１５９，１６１，１６３）は、予算階層における中間層として機能しない。代わりに、当該下請契約は各々、１つ以上の下請契約単位項目を規定し、次いで、当該１つ以上の下請契約単位項目はＧＣ  ＳＯＶ単位項目に直接的にリンクされる。
【００２４】
プロジェクトの最中に、下請け業者が、特定の下請契約１５９において合意した値をコストが超過することになることを発見した場合、あるいは、付加的な仕事または材料が必要になる場合、下請け業者は、下請契約の条件の変動を要求し得る。本願明細書において記載される例では、総合請負業者によって発行された承認された変動により、規定された値を有する新しい下請契約単位項目１７１が下請契約１５７に加えられる。次いで、下請け業者は、新しい下請契約単位項目１７１に対応する新しいＳＯＶ１７３を規定することができる。ほとんどの場合、この新しい下請契約単位項目１７１の追加によって、下請契約１５９の合計の値が変更されるので、総合請負業者は、プロジェクト契約１５１への対応する変動を要求することを決定し得る。
【００２５】
本願明細書において議論された例およびシステムは新しい下請契約単位項目の追加につながる変動に注目しているが、他のシステムは、承認された変動要求に応答して完全に新しい下請契約を作成するように構成されてもよい。さらに、多層の建設プロジェクトの全体にわたって、他の層において変動が同様に処理されてもよい。たとえば、孫請層における新しい契約単位項目の追加によって、下請け業者は、対応する調節を要求し得、最終的に総合請負業者も同様の調節を要求し得る。
【００２６】
図１Ｃの例は、１つの特定のタイプの階層的契約予算配置を示す。しかしながら、本願明細書において記載されるシステムおよび方法は、他の階層的契約および／または予算配置に適合され得る。本願明細書において記載されるシステムおよび方法は、任意のさらに別の階層なしで２つの当事者間の単一の契約を管理および修正するように適合され得る。以下で論じられる例では、図１Ｃの特定の配置に参照を行う場合があり、また、契約予算データ構造により一般的に参照を行う場合もある。別段の定めがない限り、契約予算データ構造という用語は、契約上の合意への変更を反映するために修正される、２つの当事者間の契約上の合意に関係する予算情報を規定する任意のデータ構造を含むと解釈されるべきである。
【００２７】
図２は、図１のシステムを使用して支払いを処理するための方法の一例を示す。ＣＰＭＳサーバ１０１は、総合請負業者のＥＲＰシステム１１７からプロジェクト契約および予算情報を受信し（ステップ２０１）、個々のＳＯＶ単位項目が１つ以上の下請契約によって特定の下請け業者に関連付け（あるいは割り当て）られる（ステップ２０３）。なお、以下に記載される例は特に総合請負業者と下請け業者との間のインタラクションを指し得るが、これらの例において記載される機能およびメカニズムは、１の参加者が仕事を行なうかまたは材料を提供するように契約されており、別の参加者が当該第１の参加者を監督し支払いを行うことを担うといったような、建設プロジェクトにおける参加者の任意の組合せに提供され得る。たとえば、以下の例において記載される下請け業者−総合請負業者の力学は、参加者のさまざまな他の組合せに等しく適用され得る。当該参加者のさまざまな他の組合せは、総合請負業者対プロジェクトオーナー、材料サプライヤー対下請け業者、孫請け業者対下請け業者、材料サプライヤー対総合請負業者などを含むがこれらに限定されない。
【００２８】
総合請負業者からの個々のＳＯＶ単位項目が下請契約（すなわち下請契約単位項目）によって下請け業者に割り当てられた（ステップ２０３）後、下請け業者はさらに、各下請契約単位項目についてＳＯＶを作成することによって、下請け業者予算を規定する（ステップ２０５）。ＣＰＭＳサーバ１０１は、たとえば、ＳＣ  ＳＯＶ単位項目の合計の値が下請契約単位項目の対応する値と等しいことを保証することによって、下請け業者予算が調整される（ステップ２０７）ことを保証する。たとえば、下請け業者が規定した予算情報は、ＣＰＭＳサーバ１０１によって、または、ＣＰＭＳサーバ１０１とインタラクションする下請け業者のＥＲＰシステムによって、生成され得る。
【００２９】
下請け業者予算が適切に調整されれば（ステップ２０７）、ＣＰＭＳサーバ１０１は、承認された下請契約単位項目に対応する支払いの要求を下請け業者が生成することを可能にする（ステップ２０９）。下請け業者予算が調整されていなければ、ＣＰＭＳサーバ１０１は不適合ワークフロー（non-compliance workflow）（ステップ２１１）を実施する。不適合ワークフローはたとえば、下請け業者が支払いの要求を作成するのを防止する。不適合ワークフローのさらなる詳細および他の例は、上で参照によって援用された米国特許番号第７，９２５，５８４号と、その全内容が参照によって本願明細書に援用される米国特許公開番号第２００８／０２８１７３５号とに記載されている。
【００３０】
下請け業者予算が適切に調整されており（ステップ２０７）、かつ、下請け業者が承認された下請契約単位項目に関連付けられる支払いの要求を生成すれば、ＣＰＭＳサーバ１０１は、検討のために総合請負業者へ支払いの要求を転送する（ステップ２１３）。総合請負業者が支払いの要求を承認すれば（ステップ２１５）、ＣＰＭＳサーバ１０１は、下請け業者への支払いを促進するようにワークフローを開始する（ステップ２１７）。上で参照により援用された米国特許番号第７，９２５，５８４号にさらに詳細に記載されるように、ＣＰＭＳサーバ１０１は、外部バンキングシステムに支払い指示を電子的に送り、小切手を印刷することによって、または、他のメカニズムによって、支払いを促進し得る。
【００３１】
しかしながら、総合請負業者が支払い要求を承認しなければ、ＣＰＭＳサーバ１０１は不払いワークフローを実施する（ステップ２１９）。不払いワークフローでは、下請け業者は、承認されていない（あるいは編集された）インボイスの通知を受け得る。いくつかの実施形態では、ＣＰＭＳサーバ１０１は、なぜ支払いの要求が拒絶されたか説明する、総合請負業者からの注釈またはコメントを受信する。これらのコメントは下請け業者に対して表示され、将来のアクセスおよび記録の保持のためにメモリに格納される。いくつかの実施形態では、不払いワークフローは、総合請負業者と下請け業者とが、相互に合意可能な支払い戦略が合意されるまで、交互にインボイスに編集をすることができる拡大編集処理を含み得る。全内容が参照により本願明細書において援用される米国特許番号第８，３０６，８８３号は、そのようなシステムの一例を記載している。
【００３２】
上で論じたように、図１Ｃを参照して、いくつかの状況において、合意した契約／予算の条件が変更されることが必要になる。たとえば、材料のコストが当初に見積もられたよりも高くなり得る。または、ロジスティックスの問題により、下請け業者の建築アクティビティが延長または遅延することになり得る。図３は、ＣＰＭＳサーバ１０１を使用することによって、下請け業者がどのように建設プロジェクトについて承認された予算に対する修正（または「変動」）を要求することができるのかについての一例を示す。下請け業者は変動要求を開始し（ステップ３０１）、ＣＰＭＳサーバ１０１は総合請負業者へ要求を転送する（ステップ３０３）。総合請負業者は、ＣＰＭＳサーバ１０１を通じてか、または、総合請負業者の外部ＥＲＰシステムを通じて変動要求を検討し、変動要求を承認するべきかまたは拒絶するべきかどうか判断する（ステップ３０５）。
【００３３】
変動要求が承認される場合、ＣＰＭＳサーバ１０１は（たとえば新しい下請契約単位項目を加えることによって）適切な下請契約を更新する（ステップ３０７）。次いで、下請け業者は、新しい予算額についてＣＰＭＳサーバ１０１を通じて支払いを要求することができる（ステップ３０９）。しかしながら、変更依頼要求が拒絶されれば、契約／予算には更新が行われない（ステップ３１１）か、または、いくつかの実現例では、予算は変動提案を反映するために更新されるが、以下にさらに詳細に記載されるように、下請け業者によって要求された額の代わりに０ドルの値が割り当てられる。いずれの場合においても、ＣＰＭＳサーバ１０１を使用して支払いを要求する下請け業者の能力は、以前に確定された予算額によって制限され（ステップ３１３）、下請け業者の予算が適用可能な下請契約の条件と適切に調整されない場合、下請け業者は如何なる支払いを要求することも防止され得る。
【００３４】
図４Ａは、ＣＰＭＳサーバ１０１が予算変動要求を処理し得るとともに、下請け業者が新しいＳＣ  ＳＯＶを作成し、かつ、新しい提案された予算額についての支払いを、予算変動が総合請負業者によって承認される前に要求することを可能にする代替的なメカニズムを示す。いくつかの実現例では、ＣＰＭＳサーバ１０１は、図３のみまたは図４Ａのみの機能を提供するように構成される。代替的には、ＣＰＭＳサーバ１０１は、たとえば総合請負業者のプレファレンスセッティング、プロジェクトロケーション、またはプロジェクトタイプといったファクタに基づいて、図３または図４Ａのいずれかの機能を提供するように構成され得る。以下に記載される例では、図３の処理機能は「標準変動処理」と称され、図４Ａの機能は「高度変動処理」と称される。
【００３５】
図４Ａに示されるような高度変動処理において、下請け業者は「変動提案」を作成し、当該変動提案は、承認されれば、新しい下請契約単位項目として加えられる（ステップ４０１）。図５は、ＣＰＭＳサーバにアクセスする端末デバイス上において下請け業者に対して表示されるウェブベースのユーザインターフェイスの例を示す。下請け業者は、ドロップダウンメニューから「変動を提案」または「変動登録」を選択することができる。図６は、「変動を提案」が選択されると下請け業者に対して表示されるユーザインターフェイスを示す。下請け業者は、新しい変動提案に番号、名称、説明、および額を割り当てるようフォームを使用する。提出の時間および文脈に基づいて、日付のような他の手続きデータ（procedural data）が割り当てられる。新しい変動提案は、このスクリーン上でリスト化されたままとなり、下請け業者によって正式に提出されるまで下請け業者によって編集可能である（図４Ａ，ステップ４０３）。図６の例では、下請け業者は、インターフェイスリストの左側の対応するチェックボックスを選択して「選択したものを提出」ボタンをクリックすることにより、変動提案を提出する。代替的には、下請け業者は、変動提案を提出する前に、「下書きを保存」を選択し得、変動提案へのさらなる編集をする能力を保持し得る。
【００３６】
変動提案は、下請け業者によってひとたび提出されれば（図４Ａ，ステップ４０３）、ロックされ、下請け業者はもはや変動提案の詳細を編集することができなくなる。下請け業者は、図５のホームスクリーン上で「変動登録」オプションを選択することによって、それでも提出された変動提案を閲覧し得るとともに、変動提案のステータスを監視し得る。図７は、下請け業者に対して表示される「変動登録」スクリーンの例を示す。変動登録スクリーンは、番号、名称、説明、提出日、提出額によって、すべての提出された変動提案をリスト化する。
【００３７】
以下にさらに詳細に議論されるように、実施形態は、各変動提案が、実際の下請契約予算の一部分として含まれ得る前に総合請負業者によって評価されることになる電子処理の改善を提供する。「評価」とラベル付けされたインターフェイスの右側の３つのカラムは、総合請負業者の各変動提案の評価のステータスおよび結果に関する情報を提供する。たとえば、変動提案が承認されている場合、評価の「ステータス」カラムは、当該変動を「承認済」として示し、「承認額」を含む。変動提案が拒絶されている場合（たとえば図７の変動４）、変動登録は、当該変動について、０．００ドルの承認額を反映する。変動提案がまだ承認されていないまたは拒絶されていない場合、評価の「ステータス」カラムは、変動登録において「提出済」として変動提案を示す。評価の「変動＃」カラムは、総合請負業者のＥＲＰシステムによって変動に割り当てられた識別番号を識別する。（以下にさらに議論されるように）総合請負業者が変動提案をまだ認識していない場合、評価変動番号は変動提案（たとえば変動７）に割り当てられない。しかしながら、評価処理が始まったと総合請負業者のＥＲＰシステムが認識しているが、変動提案がまだ承認または拒絶されていない場合、割り当てられた評価変動番号が表示され、評価ステータスが「提出済」（たとえば変動５）として示される。
【００３８】
以下にさらに詳細に記載されるように、電子システムは、下請け業者が、変動提案が総合請負業者によって実際に承認される前または後に、変動提案に対応する支払い要求を提出することを可能にする。任意の対応する額が現在までに下請け業者によって請求されている場合、その請求額も変動登録スクリーン上で下請け業者に対して表示される。図７の例では、変動登録は単に、単一の特定の下請契約に対応する変動をリスト化する。下請け業者は、表示のために同じプロジェクトから異なる下請契約を選択するよう、インターフェイスの左上コーナーにおけるドロップボックスを使用し得る。
【００３９】
変動提案がひとたび下請け業者によって提出されると、予算変動が要求されたことを示す通知がＣＰＭＳサーバ１０１によって総合請負業者に自動的に送られる（図４Ａ，ステップ４０７）。たとえば、通知は、変動提案、変動額提案および対応する契約／プロジェクトを提出した参加者を識別するＥメールの形態で送られ得る。ＣＰＭＳサーバ１０１はさらに、図１Ｂの通知／操作指示モジュール１２５のような通知／操作指示メカニズムを実現することにより総合請負業者のプロジェクトホームページ上にメッセージを生成および表示することによって総合請負業者に通知し得る。図８は、新しい５つの変動提案が総合請負業者によるさらなるアクションを待っていることを示す「５つの新しい変動提案」を表す通知を含む１つのそのようなプロジェクトホームページの例を示す。
【００４０】
この点において、総合請負業者は、評価処理を開始し得る（図４Ａ，ステップ４０９）か、または、下請け業者は、承認されていない変動提案に対して請求（または支払いの要求）を提出し始め得る（ステップ４１１）。評価処理（ステップ４０９）は図４Ｂにおいてさらに記載されており、下請け業者の請求処理が図４Ｃに記載されている。
【００４１】
図４Ｂに示されるように、総合請負業者は、自身の外部ＥＲＰシステムに変動提案をエクスポートすることによって評価処理を開始する（ステップ４１３）。総合請負業者は、変動提案を編集するべきかどうか決定する（ステップ４１５）。下請け業者によって提案された契約予算値に対して総合請負業者が如何なる変更も加えない場合、当該値と変動提案によって規定された契約単位項目とに基づき「変動評価」が作成される（ステップ４１７）。しかしながら、変更が行なわれる場合、総合請負業者によって提供されるような新しい値、契約単位項目および名称に基づき、「変動評価」が作成される（ステップ４１９）。総合請負業者は、新しい下請契約単位項目の提案値を変更することによって、または、（以下にさらに詳細に記載されるように）下請け業者によって提案されたよりも多い／少ない下請契約単位項目を加えることによって、変動提案を編集し得る。その後、総合請負業者は、変動が承認されたかどうか示す（ステップ４２０）。承認されれば、ＣＰＭＳサーバ１０１は、承認された下請契約予算の一部分として変動評価を組込むように構成される。承認されなければ、変動評価は、さらに以下で議論されるように、「未承認」状態のままとなる。さらに、この例において、変動提案は、０．００ドルの値を有する変動評価を承認することにより拒絶され得る。
【００４２】
その後、ＥＲＰシステムによって生成された変動評価（承認済または未承認）は、ＣＰＭＳへインポートされ（ステップ４２１）、対応する変動提案にマッチングされるように利用可能となる（ステップ４２３）。このマッチング処理は、図９に示されるようにＣＰＭＳインターフェイスを通じて行なわれ得る。図９は、ユーザ端末上で総合請負業者に対して表示されるウェブベースのユーザインターフェイスの例を示す。ユーザインターフェイスは、スクリーンの上部の近傍のテーブルにおいてＥＲＰシステムからインポートされた（すなわちＶａｒ＃  ＳＶ０３）ものであり、かつ、変動評価が承認された（「ステータス」カラムの下）ことを示すマッチングされていない変動評価の詳細を示す。インターフェイスはさらに、下部テーブルにおいてすべての保留中のマッチングされていない変動提案の詳細をリスト化している。このインターフェイスを使用して、総合請負業者は、適切なマッチングされていない変動提案を下部テーブルから選択し、スクリーン上で「マッチ」ボタンを押す。
【００４３】
ひとたびマッチングが完了すると、変動評価が「承認」されていれば、適切な下請契約に新しい下請契約単位項目を加えることによって契約予算が更新される（ステップ４２７）。変動評価が承認されずにマッチングが行なわれる場合、総合請負業者のＥＲＰシステムからの如何なる詳細あるいは識別情報も、マッチングされた変動提案に関連付けられたままであるが、「評価値」はインポートされず下請け業者に対して表示されない。システムは、変動提案の受信を認識することと、総合請負業者のＥＲＰシステムを更新することと、総合請負業者が、総合請負契約への対応する調節をプロジェクトオーナーに交渉している間、下請け業者が働き続けることを可能にすることとを行うために、変動提案を承認することなく総合請負業者がマッチングを行なうことを可能にするように構成され得る。
【００４４】
図９の例では、各リスト化された変動提案の左側のボックスの１つ以上をチェックすることによって、単一の変動評価は、１つ以上の変動提案とマッチングされ得る。システムのいくつかの実現例では、下請け業者が提出した複数の変動提案に対応する契約変動を承認する単一の変更依頼が、総合請負業者のＥＲＰシステムによって発行され得る。反対に、以下に詳細に記載されるように、総合請負業者は、下請け業者によって提案されるような単一の変動の代わりに、下請契約に対して複数の変更を加えることを望み得る。したがって、他の実現例は、改善された電子処理によって単一の変動提案が複数の変動評価にマッチングされるメカニズムをサポートし得る。同様に、いくつかの実現例は、いくつかの変動評価に対していくつかの変動提案の一括マッチングを可能にし得る。
【００４５】
本願明細書において記載される例の多くにおいて、システムは、総合請負業者の承認した変動の値が下請け業者の変動提案の値と異なっていても、総合請負業者から受信された承認された変動に基づいて下請契約予算を自動的に更新するように構成される。いくつかの実現例では、ＣＰＭＳによって実現される（図１Ｂの通知／操作指示モジュール１２５のような）通知／操作指示メカニズムは、承認された変動が変動提案とは異なる値または構造を有する場合、下請け業者への通知を生成および送信／表示する。次いで、ＣＰＭＳによって実現された通知／操作指示メカニズムは、下請け業者が変動修正を受け入れるかまたは新しい変動提案を提出することを促す。これにより、下請け業者は、下請契約が総合請負業者によってどのように修正されるかに関して何らかの入力を保持する。同様に、いくつかの実現例では、補正された下請契約が、承認された変動がプロジェクト予算を事実上変更する前に、下請け業者および総合請負業者の両方によって実行（すなわち電子的にまたは手書きで署名）されなければならない。ＣＰＭＳシステムは、下請け業者が総合請負業者の承認された変動を検討することができ、かつ、承認された変動を受け入れるべきかどうか（すなわち補正された下請契約を実施することにより）判断することができるメカニズムとして、署名要求を利用し得る。複数の変動提案が同じ下請け業者によって提出される場合、ＣＰＭＳシステムは、変動提案に対応するすべての承認された変動を、下請け業者および総合請負業者によって実施されるべき単一の補正された下請契約または追加下請契約にグループ化するように構成され得る。
【００４６】
総合請負業者はさらに、ＣＰＭＳインターフェイスを通じた変動登録スクリーンへのアクセスを有する。図１０は、１つのそのような変動登録の例を示す。図７の下請け業者の変動登録スクリーンのように、ＧＣの変動登録は、下請け業者によって提出された各変動提案と、下請け業者が提案した如何なる変動にも対応しない総合請負業者によって生成された任意の他の変動とを表示する。下請け業者によって最初に提案された変動について、図１０の変動登録は、（「提出額」カラムにおいて）下請け業者によって提案された変動額と、適用可能な場合、（「承認額」カラムにおいて）総合請負業者からの対応する承認された変動からの額とを示している。「ステータス」カラムは、変動提案が承認されたか、拒絶されたか、または、まだ総合請負業者からの承認決定を待っているかどうか示す。総合請負業者によって拒絶された変動提案は「承認額」カラムにおいて０ドルの値を有する。下請業者によって提案されたのとは異なる額について承認された変動提案は「ステータス」カラムにおいて「承認済」として指定されるが、「承認額」カラムにおいて実際の承認された変動額が反映される。図７を参照して上で論じたように、総合請負業者のＥＲＰシステムからの「変動評価」にマッチングされた変動提案は、「提出済」のステータスを示し、かつ、総合請負業者の割り当てられた「変動＃」（たとえば変動５）を示す。しかしながら、「変動評価」にまだマッチングされていない変動提案は、評価変動番号および「承認額」なしで、「提出済」ステータスを示す（たとえば変動７）。総合請負業者はさらに、下請け業者に表示されないがさまざまな他の情報を記録するために総合請負業者によって使用され得る「プライベートコメント」を含み得る。当該さまざまな他の情報はたとえば、変動提案が拒絶もしくは編集された理由、または、変動提案がまだ承認されない理由を含む。
【００４７】
なお、図４Ｂに関して記載されたシステムおよび方法は単に、１つの特定の例を提供する。たとえば、ＣＰＭＳの他の実現例では、総合請負業者は、ＣＰＭＳインターフェイスを通じて変動を直接的に検討、編集、および承認することができ得る。そのようなシステムでは、変動提案は、任意のＥＲＰシステムに必ずしもエクスポートされず、変動評価もＣＰＭＳに必ずしもインポートされない。さらに、いくつかの実現例では、ＣＰＭＳは、共通識別子を使用することによって、または、受信された変動評価と任意の残っているマッチングされていない変動提案との詳細に基づき最も有望なマッチを予測することによって、変動評価に変動提案を自動的にマッチングするように構成される。いくつかのそのようなシステムでは、ＣＰＭＳは、自動的に識別されたマッチを確認するように総合請負業者に要求するように構成され得る。
【００４８】
変動提案および変動評価をマッチングすることを自動的に識別するように構成されるシステムはさらに、ＥＲＰシステムから受信された承認された変動がＣＰＭＳ上で下請け業者によって開始された対応する変動提案を有していない場合を自動的に判断するように構成され得る。そのような状況では、システムは、入力される承認された変動が総合請負業者によって開始された予算変動であると扱うように構成され、下請け業者予算と、したがって下請契約値とを更新する（たとえば図１０における「ＧＣ変動２」）。
【００４９】
図４Ｃは、高度変動処理機能を使用する下請け業者のための請求提出処理を示す。下請け業者はＣＰＭＳへ支払いの要求を入力する（ステップ４４５）。図１１は、支払い要求の詳細を入力するために使用され得るウェブベースのユーザインターフェイスの一例を示す。図１１のユーザインターフェイスは、すべての承認された予算単位項目と、下請け業者が提出した（が総合請負業者による承認については保留中の）承認されていない変動提案とをリスト化する。下請け業者は、請求を提出する予算単位項目を識別するようこのインターフェイスを使用し、（たとえば「この期間」カラムにおけるフィールドを編集することによって）この支払期間中に要求されるべき新しい支払い額を入力する。
【００５０】
図１１のインターフェイスは、承認された下請契約単位項目または変動提案のいずれかを具体的に参照する支払いを下請け業者が要求することを可能にする。下請け業者の予算が適切に調整されている場合のみ、支払い要求インターフェイスの機能はアクセス可能である。しかしながら、図２の例とは異なり、下請け業者は、承認されていない変動提案に対応するＳＯＶを作成し得、変動提案に対して支払いを要求し得る（いくつかの実現例では、下請け業者ＳＯＶは、変動提案について単一の単位項目として作成され、変動が承認された後までは、複数の単位項目に拡張することができない）。さらに、要求された支払いが確定された下請契約予算の単位項目に対応する場合（ステップ４４７）、図１１のインターフェイスは、当該下請契約単位項目についての残存する承認された予算以下の額について、下請け業者が支払を要求することを可能にする（ステップ４４９）。その後、支払いの要求は総合請負業者へ転送される（ステップ４５１）。総合請負業者が支払いの要求を承認すれば（ステップ４５３）、ＣＰＭＳサーバは、支払いを促進するようワークフローを開始する（ステップ４５５）。反対に、要求が拒絶されれば、不払いワークフローが開始される（ステップ４５７）。
【００５１】
図１１のインターフェイスを使用して、下請け業者はさらに、承認されていない変動提案に対する支払いを要求し得る。変動提案が総合請負業者によって「変動評価」にマッチングされており（ステップ４５９）、これにより変動提案が総合請負業者のＥＲＰシステムによって認識されていることを確認している場合、ＣＰＭＳは、承認されていない変動提案に対して総合請負業者が支払いをすることも可能にし得る。しかしながら、下請契約はまだ修正されていないので、ＣＰＭＳはまず、要求された支払い額が承認された下請契約単位項目の残高未満かどうかを判断する（ステップ４４９）。そうならば、支払いの要求は、検討および承認（ステップ４５３）のために、総合請負業者へ転送される（ステップ４５１）。そうでなければ、支払いの要求は記録され、ＣＰＭＳによって実現される保持メカニズム（たとえば図１Ｂの保持モジュール１２９）がその後の処理および承認のために（すなわち変動提案が承認され、かつ、存在する下請契約がしたがって修正された後まで）当該支払いの要求を保持し得る（ステップ４６３）。支払いの要求が提出されるとともに「振り出し」スケジュールで支払われることを要求する他の実現例において、要求された支払い額が承認された下請契約単位項目の残高を上回る場合、当該支払いの要求は拒絶され、下請け業者は、次の振り出し期間の間に、支払いの要求を再提出することを要求される。
【００５２】
この「内金払い（pay on account）」メカニズムは、要求された支払い額が承認された下請契約の残りの値（または下請け業者に割り当てられたプロジェクトについてのすべての下請契約の残り値の合計）を上回らない限り、支払いが承認されることを可能にする。たとえば、下請け業者が下請契約においてさらに１０００ドルの予算変動を提案し、当該変動提案の１０００ドル全部について支払いを要求する場合、下請契約の未払いの残高が１０００ドルに等しいまたは１０００ドルを上回っていれば、システムは、総合請負業者が支払いを承認することを可能にする。これにより、支払いが行なわれて変動提案が最終的に拒絶されれば、当該支払われた額に対応するよう下請契約について自身のＳＯＶを調節するのは下請け業者の責任になる。
【００５３】
ＣＰＭＳはさらに、変動評価にまだマッチングされていない変動提案に対して、下請け業者が支払いを要求することを可能にする（ステップ４６１）。しかしながら、変動提案が総合請負業者のＥＲＰシステムによって（すなわちインポートされた変動評価へのマッチングを行なうことによって）認識されていることを総合請負業者が確認していないので、ＣＰＭＳは、少なくとも変動提案がマッチングされるまで、すべてのそのような支払い要求を保持する（ステップ４６３）。いくつかの実現例では、ＣＰＭＳによって実現される通知／操作指示メカニズム（たとえば図１Ｂの通知／操作指示モジュール１２５）は、マッチングされていない変動提案に対して支払いが要求された場合、変動提案を評価しマッチングを行なうよう総合請負業者に指示する。
【００５４】
図１２は、すべての保留中の支払い請求を検討する（すなわち図４Ｃのステップ４５３）ように総合請負業者によって使用されるウェブベースのインターフェイスの例を示す。このインターフェイスは、情報のうち特に、各下請け業者組織についての合計の契約値と、要求された支払い額と、残存する承認された契約残高と、（「未承認請求」カラムにおける）承認されていない変動に対してなされた任意の支払い要求の合計額とを表示する。総合請負業者は、「未承認請求」カラム内のフィールドをクリックすることによって、請負業者について任意の承認されていない変動を閲覧し得る。「ステータス」カラムは、現在の振り出し期間の間、支払い要求が各下請け業者組織について受信されたかどうか示す。
【００５５】
支払い要求を承認および拒絶することに加えて、総合請負業者は、図１３のウェブベースのインターフェイスを使用する支払いに先立って、下請け業者によって提出された支払いの要求を修正することが可能にされ得る。総合請負業者に表示される「修正」ページは、内容および機能において、下請け業者に表示される下請け業者請求ページに類似している（図１１）。しかしながら、現在の支払期間に支払われるべき額を変更することに加えて、総合請負業者はさらに、なぜ支払い額が編集されたかを下請け業者に説明するコメントを提供し得る。
【００５６】
上記のシステムおよび例において、下請け業者は、任意のときに（またはセットされたスケジュールに従って）、予算変動を提案することができ得る。しかしながら、たとえば全内容が本願明細書において参照により援用される米国特許番号第７，８９９，７３９に記載されるように、支払い要求は、支払いについて、より厳密に規定された支払いスケジュールに従って要求、承認、処理され得る。
【００５７】
（図２〜図３の）標準変動処理と高度変動管理（図４Ａ〜図４Ｃ）との間の機能的な違いは、システムユーザの観点から上で議論されている。しかしながら、これらの違いは、ＣＰＭＳサーバがどのようにハードウェア／データ構造レベルで予算を実現および追跡するかということにおける違いに完全に関係する。図１４は、標準変更依頼処理の最中におけるデータ構造と、ＣＰＭＳサーバ１０１とＥＲＰシステム１１７との間の処理フローインタラクションとを示す。ＣＰＭＳ１４０１は、任意の以前に承認された変動１４０７を含む基本契約１４０５の構成要素を格納する。承認されていない変動提案１４０９は、ＣＰＭＳ１４０１によって別々に格納および追跡される。下請け業者がシステムへ変動提案を入力すると、変動要求１４１１が生成され、外部ＥＲＰシステム１４０３に送信される。要求１４１１が承認される場合、総合請負業者は（自身のＥＲＰシステムを通じて）、プロジェクト予算／契約の一部分としてＣＰＭＳ１４０１に格納されている承認された変動１４０７のリストに新しい承認された変動１４１３を加える契約値を更新しなければならない。
【００５８】
図１４の例では、下請け業者は、ＣＰＭＳ１４０１を通じて変動提案１４０９を入力することによって変動要求１４１１を生成することができるが、実際の変動１４１３は総合請負業者から直接的に入力されなければならない。したがって、ユーザによって生成される変更依頼要求１４１１および総合請負業者から受信される承認された変動１４１３の両方に、要求された支払いをリンクするようシステムが使用し得る実データは維持されない。承認されていない変動提案１４０９に対して下請け業者が支払いを要求するために、下請け業者は、インボイス１４１５をＣＰＭＳ１４０１の外側で生成しなければならない場合があり、手動での検討および承認のために総合請負業者にそれを転送しなければならない場合がある。ＣＰＭＳ１４０１が、承認されていない変動提案１４０９に対して下請け業者が支払いの要求を生成することを可能にするように構成されたとしても、総合請負業者によって手動で請求１４１５は検討されなければならず、データはＥＲＰ１４０３へ手動で入力されなければならない。
【００５９】
対照的に、図１５は、高度変動管理の最中におけるＣＰＭＳ１５０１とＥＲＰ１５０３との間のデータフローおよびインタラクション処理を示す。ＣＰＭＳ１５０１は、任意の承認された変動１５０７を含む基本契約構成要素１５０５を格納する。ＣＰＭＳ１５０１はさらに、承認されると、承認された契約予算に変動提案データが直接的にリンクされるように、要求された変動または承認されていない変動１５０９を基本契約構成要素１５０５に関連させる。変動提案が下請け業者によって作成および提出されると（図４Ａ，ステップ４０１，４０３）、システムは、ＣＰＭＳ上に格納される要求オブジェクト１５１１を生成する。変動提案がＥＲＰシステムにエクスポートされると（図４Ｂ，ステップ４１３）、要求オブジェクト１５１１のコピーがＥＲＰシステム１５０３に送信される。総合請負業者が変動提案の検討を完了した後、（以下に詳細に記載されるように）あるフォーマットおよび内容基準を満たす応答オブジェクト１５１３がＥＲＰ１５０３からＣＰＭＳ１５０１にインポートされる（図４Ｂ，ステップ４２１）。変動評価が変動提案とマッチングされた後（図４Ｂ，ステップ４２３）、応答オブジェクト１５１３は対応する要求オブジェクト１５１１をターゲットとするように更新される。応答オブジェクト１５１３の値および単位項目構造が（以下に詳細に議論されるように）要求オブジェクト１５１１の値および単位項目構造に取って代わるが、応答オブジェクト１５１３が変動を承認する場合、要求オブジェクト１５１１は承認されていない変動１５０９をパスして、承認された変動１５０７として、承認された予算に直接的に関連される。応答オブジェクト１５１３が承認された変動を含んでいない場合、要求オブジェクト１５１１は、承認された変動を含んでいるその後の応答オブジェクト１５１３がＥＲＰ１５０３から受信されるまで、承認されていない変動１５０９に関連付けられたままとなる。
【００６０】
これにより、ＣＰＭＳ１５０１は、たとえば、支払い１５１５について請求を提出するといったように、承認されていない要求オブジェクトデータ構造をターゲットとするアクションをユーザが行うことを可能にし得る。要求オブジェクト１５１１が応答オブジェクト１５１５とマッチングされて承認された変動１５０７の部分になると、支払い要求１５１５と要求オブジェクト１５１１との間の関連性は、承認された変動１５０７との関連性になる。支払い請求は手動で検討する必要はなく、または、データはＥＲＰシステムへ手動で入力される必要はない。その代わりに、ＣＰＭＳ１５０１は、ＣＰＭＳと外部ＥＲＰシステムとの間のインタラクションを提供しつつ、予算変動を提案および承認する処理の全体にわたってデータ構造オブジェクトを維持するように構成される。さらに、応答オブジェクトがマッチングされた要求オブジェクトとひとたびリンクされると、ＣＰＭＳにおいて下請け業者によって行われる、要求オブジェクトをターゲットとする任意のアクションは同様に、総合請負業者のＥＲＰシステムによってインデキシングされ、ＥＲＰシステムによって生成されＥＲＰシステムから送られる応答オブジェクトに対応するものとして総合請負業者のＥＲＰシステムによって認識される。したがって、データおよび機能は、承認された変動がＥＲＰシステム上に作成される前にアクションがＣＰＭＳシステム上で下請け業者によって行われても、ＣＰＭＳシステムと外部ＥＲＰシステムとの間でシームレスに統合される。
【００６１】
以下において議論される例では、このデータマッチングおよび統合処理は、図１６Ａに示されるようなユニークなデータ構造ライフサイクルによって、指示および制御される。新しいデータ構造オブジェクト（要求オブジェクトまたは応答オブジェクトのいずれか）が、システムに入力されると、初期ステータスが割り当てられる。すなわち、ＣＰＭＳ上に作成され初期状態要求オブジェクトは最初は「未提出」ステータス１６０１を有し、ＣＰＭＳへインポートされた応答オブジェクトは最初は「未マッチング」ステータス１６０２を有する。データ構造オブジェクトはＣＰＭＳによって影響を与えられる準備ができている（すなわち要求オブジェクトに対応する変動提案が提出された後であって、応答オブジェクトに対応する変動評価が「マッチングされた」後）場合、オブジェクトには「実行段階（staged）」ステータス１６０３が割り当てられる。ＣＰＭＳがひとたびデータ構造オブジェクトに影響を与えると、その最終終了状態に到達し、そのステータスは、「プロモート」１６０５あるいは「マージ」１６０７のいずれかの「終了状態」ステータスに変更される。
【００６２】
たとえば、新しい変動提案が下請け業者によって作成される（図４Ａ，ステップ４０１）と、要求オブジェクトデータ構造が作成され、「未提出」１６０１の初期状態が割り当てられる。要求オブジェクトが「未提出」ステータス１６０１を有する間は、下請け業者は変動提案のデータを編集することができ、ＣＰＭＳは要求オブジェクトを処理し始めない。ユーザが総合請負業者による考慮のために変動提案を提出すると、要求オブジェクトには、ＣＰＭＳが要求オブジェクトを処理し始め得ることを示す「実行段階」１６０３のステータスが割り当てられる。ひとたびＣＰＭＳが、（以下にさらに詳細に記載されるように）下請契約予算データ構造における潜在的な新しい下請契約単位項目の将来の位置を参照するようターゲットフィールドを更新する要求オブジェクトを処理し、かつ、要求オブジェクトがＥＲＰシステムにエクスポートされると、ＣＰＭＳ上に格納された要求オブジェクトは、「プロモート」１６０５のステータスを割り当てられる。
【００６３】
同様に、変動提案に変動評価を手動でマッチングすることを総合請負業者に要求する実現例では、ＣＰＭＳによってＥＲＰから受信される（図４Ｂ，ステップ４２１）応答オブジェクトは最初は、「未マッチング」１６０２のステータスを割り当てられる。総合請負業者が応答オブジェクトに対応する変動評価を変動提案にマッチングした後、要求オブジェクトのステータスは、ＣＰＭＳが応答オブジェクトを処理し始め得ることを示す「実行段階」１６０３へと更新される。しかしながら、要求オブジェクトと異なり、応答オブジェクトは、「プロモート」１６０５および「マージ」１６０７という２つの潜在的な終了状態を有する。応答オブジェクトが「実行段階」ステータス１６０３に到達した後、ＣＰＭＳは、マッチングされた変動提案に対応する要求オブジェクトに応答オブジェクトをリンクするよう、図１６Ｂに示されるようにマージングルーチンを行なう。（以下に詳細に記載されるように）要求オブジェクトの対応する項目をターゲットとするよう、要求オブジェクトの項目に対応する応答オブジェクトからの個々の項目が更新され、「マージ」ステータス１６０７が割り当てられる。反対に、要求オブジェクトにおいて対応する項目を有していない応答オブジェクトにおける任意の項目は、下請契約予算データ構造における新しい下請契約構成要素の位置を直接的にターゲットとするよう更新され、「プロモート」ステータス１６０５が割り当てられる。
【００６４】
「マージ」１６０７および「プロモート」１６０５は両方とも、データ構造オブジェクト内におけるデータ構造オブジェクトおよび個々の項目についての潜在的な終了状態であるが、「マージ」１６０７および「プロモート」１６０５は各々、異なるターゲティング処理を示す。「プロモート」されたデータオブジェクトおよび項目は、下請契約予算データ構造における新しい下請契約構成要素についての位置を直接的にターゲットとする。「マージ」されたデータオブジェクトおよび項目は、別のデータ構造オブジェクトをターゲットとすることにより間接的に下請契約予算データ構造をターゲットとする（すなわち応答オブジェクトは要求オブジェクトをターゲットとし、要求オブジェクトは下請契約予算データ構造をターゲットとする）。
【００６５】
図１６Ｂは、マージルーチンをさらに詳細に示す。総合請負業者が変動提案に変動評価をマッチングさせた（これにより応答オブジェクトに対応する要求オブジェクトを識別した）（ステップ１６１１（すなわち図４Ｂ，ステップ４２３））後、ＣＰＭＳは、変動評価が如何なる編集もなしで返されたかどうか判断する（ステップ１６１３）。そうならば、応答オブジェクトは、マッチングされた要求オブジェクトと同じ数の項目および同じ値を含むことになる。その後、ＣＰＭＳは、マッチングされたデータ構造をターゲットとするように応答オブジェクトを更新し、オブジェクトと当該オブジェクト内の項目のすべてとのステータスを「マージ」に更新する（ステップ１６１５）。応答オブジェクトが変動が承認されたことを示す場合（ステップ１６１６）、下請契約予算データ構造は、承認された変動に対応する新しい下請契約構成要素を含むように更新される（ステップ１６１７）。応答オブジェクトが変動が承認されたという指示を含んでいない場合、変動提案は、承認されていない変動のままで残り、要求オブジェクトおよび応答オブジェクトは、承認された下請契約予算の部分になるようにはまだ引き上げられていない（ステップ１６１８）。
【００６６】
変動提案が編集されている（ステップ１６１９）場合、応答オブジェクトは、マッチングされた要求オブジェクト内に存在しない付加的な項目、および／または、マッチングされた要求オブジェクトに存在する項目についての異なる値を含み得る。要求オブジェクトにおいて対応する項目を有する如何なる応答項目も、応答オブジェクトにおける値が要求オブジェクトにおける対応する値とは異なっても、対応する項目をターゲットとするよう更新され、それらのステータスは「マージ」に変更される（ステップ１６２１）。新しい項目が応答オブジェクトに加えられると（ステップ１６２３）、それらの新しい項目は、下請契約予算データ構造において新しい下請契約単位項目の位置を直接的にターゲットとするように更新され、「プロモート」ステータスが割り当てられる（ステップ１６２５）。
【００６７】
拒絶された変動（ステップ１６２７）の特殊な場合において、応答オブジェクトは、マッチングされた要求オブジェクトと同じ項目を有するが、応答オブジェクトは、変動の値を０ドル（＄０）として規定する。応答オブジェクトは、要求オブジェクトをターゲットとするように更新され、応答オブジェクトのステータスは「マージ」に変更される（ステップ１６２９）。新しい下請契約単位項目は、０ドルの値を有する下請契約予算データ構造に加えられる（ステップ１６１７）。
【００６８】
図１７は、新しい変動提案が下請け業者によって作成される場合（すなわち図４Ａ，ステップ４０１）に、ＣＰＭＳによって生成される要求オブジェクトデータ構造の一例のコンテンツおよびフォーマットを示す。要求オブジェクトは、複数の項目を有するパーセル（parcel）の形態にある。パーセルデータ構造は、パーセルＩＤ、パーセルタイプおよびステータスを含む。パーセルデータ構造はさらに、変更依頼項目および契約構成要素項目といった２つの項目を含む。両方の項目は、項目ＩＤ、タイプ、ステータス、ターゲットおよび額を有する。図１７において、パーセルおよび両方の項目のステータスは「未提出」である。なぜならば、変動提案要求が下請け業者によってまだ「提出」されていない（すなわち図４Ａのステップ４０３がまだ行われていない）からである。
【００６９】
下請け業者が変更依頼要求（図４Ａ，ステップ４０３）をひとたび提出すると、パーセルおよびすべての項目のステータスが「実行段階」に変更される。その後、ＣＰＭＳは、別のデータ構造またはオブジェクトの物理メモリ位置を参照するよう各項目の「ターゲット」フィールドを更新することによって、要求オブジェクトを処理し始める。その後、各項目およびパーセル自身のステータスは、「プロモート」に更新され、要求オブジェクトがその終了状態に到達したことを示す。図１８は、「プロモート」された要求オブジェクトデータ構造の例を示す。パーセルおよび各項目のステータスは、「プロモート」としてリスト化され、各項目はターゲットを含む。「契約構成要素（ContractComp）」項目は、下請契約予算データ構造において新しい下請契約単位項目に使用されることになる位置をターゲットとする。変更依頼ターゲットは、マッチングに起因する要求と項目との間の関係を促進するように使用される一意のメモリアドレスまたはドキュメント識別番号を参照する。
【００７０】
下請け業者が新しい変動提案ドラフトを作成すると、図１７のデータ構造が生成される（図４Ａ，ステップ４０１）。図１８に示されるように、潜在的な変動が提出された（図４Ａ，ステップ４０５）後、データ構造のステータスが変更される。総合請負業者が変動提案を評価し、ＥＲＰシステムから変動評価をインポートした後（図４Ｂ，ステップ４１３）、新しい応答オブジェクトデータ構造はＣＭＰＳメモリに格納される。図１９は、そのような応答データ構造の一例を示す。さらに、当該応答データ構造は、１つ以上の関連する「項目」を有するパーセルである。パーセルおよび項目はＩＤにより識別されており、ステータスおよびターゲットが割り当てられる。図１９に示されていないが、ＥＲＰシステムから受信された応答オブジェクトはさらに、変動が承認または未承認かどうか示すフラグまたはフィールドを含む。
【００７１】
図１９の例において示されるようなＥＲＰシステムから受信された応答オブジェクトは最初はターゲットを有しておらず、パーセルおよびすべての項目のステータスは「未マッチング」としてリスト化される。ひとたび変動評価が変動提案にマッチングされる（図４Ｂ，ステップ４１４）と、パーセルは図１６Ｂの方法に従って「マージ」され、応答オブジェクトデータ構造は適切なターゲットで更新される。図２０は、「マージ」された応答データ構造の一例を示す。パーセルの「ターゲット」は、ターゲット要求パーセルのパーセルＩＤを反映するように更新される。ターゲット要求パーセルは、この例ではパーセル５（すなわち図１８の要求オブジェクト）である。
【００７２】
しかしながら、この例では、応答データ構造は、マッチングされた要求データ構造より多くの「項目」を含んでいる。下請け業者によって提出された変動提案を単に承認する代わりに、総合請負業者は、２つの新しい下請契約単位項目を作成することと、承認された付加的な予算額１０００ドルをこれら２つの新しい下請契約単位項目間で分割することとを選んでいる。したがって、応答パーセルは、９００ドルの額を有する一方の項目と、１００ドルの額を有する他方の項目といった２つの「契約構成要素」項目を含んでいる。応答パーセルが要求パーセルとマージされると、第１の契約構成要素項目は要求パーセルの契約構成要素項目とマージされる。すなわち、応答パーセルにおける第１の契約構成要素項目のターゲットは、要求パーセルにおける契約構成要素項目（この例では項目１１）の項目ＩＤを反映するように更新され、第１の契約構成要素項目のステータスは「マージ」に変更される。図１８の対応する要求パーセルにおいて対応する第２の契約構成要素項目が存在しないので、応答パーセルの第２の契約構成要素項目は、下請契約予算データ構造の新しい付加的な下請契約単位項目をターゲットとするように更新され、第２の契約構成要素項目のステータスが「プロモート」に変更される（これにより、要求オブジェクトを通じて下請契約予算データ構造を間接的にターゲットとする代わりに、第２の契約構成要素項目は下請契約予算データ構造を直接的にターゲットとすることを示す）。
【００７３】
図２１〜図２６は、ＣＰＭＳが図１７〜図２０に示されるように要求オブジェクトおよび応答オブジェクトを処理すると、ＣＰＭＳのメモリ上に格納された下請契約予算データ構造および総合請負契約予算データ構造がどのように更新されるのかを示す。図２１は、３つの契約単位項目を含むプロジェクトのための元々の変更されていない総合請負契約予算を示す。全体的なプロジェクト契約についての合計請負額は４，０００，０００．００ドルであり、当該合計請負額は、各関連付けられる単位項目額によって示されるように、３つの契約単位項目の間で分割されている。図２１の例は、１つの下請契約のみが現在各総合請負契約予算単位項目に対応していることを示している。図２２は、下請け業者のための下請契約予算データ構造を示す。当該下請契約予算データ構造は、総合請負契約予算データ構造からの「電気」の予算単位項目に対応する下請契約を有する。下請契約について総予算額は５００，０００ドルである。
【００７４】
下請け業者が変動提案（すなわち図１８の要求オブジェクト）を作成および提出すると、下請契約予算データ構造は、承認された下請契約予算（図２２）および潜在的な下請契約予算（図２３）という２つの態様（または文脈）で格納および表示され得る。しかしながら、変動提案が総合請負業者によって検討および承認されるまで、総合請負業者の下請契約予算データ構造についての考え方は変わっておらず、図２１に示された状態のままである。変動提案は、ひとたび総合請負業者によって承認されると、下請契約予算の一部になり、全体的なプロジェクト予算の一部として反映される。図２４に示されるように、更新された総合請負業者予算は、応答オブジェクト（すなわち総合請負業者からの承認された変動）によって指示されるような、電気の単位項目についての増加された額と、増加された合計請負額とを含む。
【００７５】
ひとたび変動提案が総合請負業者によって承認されると、下請契約予算データ構造も、応答オブジェクトによって指示されるように、変動提案の額または用語における任意の変更を反映するように更新される。図２５は、図２０の応答オブジェクトがＣＰＭＳによって処理された後の更新された下請契約予算データ構造を示す。この例では、図１９〜図２０を参照して上で議論されたように、総合請負業者は、１０００ドルの額での単一の新しい下請契約単位項目を承認するのではなく、２つの別個の新しい下請契約単位項目を承認している。すなわち、「ＧＣ  ＣＣ１」については９００．００ドルであり、「ＧＣ  ＣＣ２」については１００．００ドルである。
【００７６】
さらに、上で議論されたように、いくつかの実現例では、下請け業者は、変動提案に対して支払いの要求を、その変動が承認された下請契約予算に加えられる前に作成および提出することができる。図２０の応答オブジェクトに従うと、総合請負業者は、１０００ドルの単一の単位項目の代わりに、９００ドルおよび１００ドルの２つの新しい下請契約単位項目を承認している。しかしながら、図２６に示されるように、要求された１０００ドルの下請契約単位項目に対して下請け業者によって提出された以前の支払いの要求に対応するために、下請契約予算データ構造は、変動提案額全体である１０００ドルが、下請け業者（すなわち要求オブジェクト）によって提案されるように単一の新しい下請契約単位項目に割り付けられるように、更新される。総合請負業者の応答オブジェクトによって規定される構造に準拠するよう、第２の新しい下請契約単位項目が加えられるが、最初は０ドルの値を示す。総合請負業者の応答オブジェクトによって指示されるようにこの割り付けが承認された変動と直接的に一致しないので、この下請け業者は、この不一致に対応するために、下請け業者に代わってさらなる支払い要求が生成され得る前に各新しい下請契約単位項目について下請契約ＳＯＶを更新および調整することが必要であり得る。
【００７７】
図２７〜図３１は、総合請負業者と下請け業者との間のインタラクションの別の例を提供する。図１７〜図２６を参照して上で記載された例とは対照的に、この例では、下請け業者によって提案されたその通りに、総合請負業者は単純に変動を承認している。図２７は、１０００ドルの値を有する新しい下請契約単位項目を要求する「未提出」要求オブジェクトを示す。図２８において、要求オブジェクトは、変動提案が下請け業者によって提出された後、「プロモート」されている。図２９は、ＥＲＰシステムから受信された「未マッチング」応答オブジェクトを示す。図１９の例と異なり、図２９の応答オブジェクトは、図２８のマッチングされた要求オブジェクトと同じ数の項目および同じ契約構成要素値を含んでいる。図３０では、応答オブジェクトは要求オブジェクトとマージされており、ターゲットは対応するパーセルおよび項目ＩＤを参照するように更新され、応答オブジェクトにおけるパーセルおよびすべての項目のステータスが「マージ」に変更される。図２８の要求オブジェクトが図３０の応答オブジェクトにおいて各項目について対応する項目を含んでいるので、応答オブジェクトにおける項目は、下請契約予算データ構造を直接的にターゲットとし、自身のステータスを「プロモート」に変更させるようには作成されない。図３１に示されるように、変動が要求されたそのままで承認されると、実際の下請契約予算データ構造は、当該提案された下請契約予算データ構造（すなわち図２３）と正確にマッチするように、最終的に更新される。
【００７８】
図３２〜図３６はさらに別の例を示す。このシナリオにおいて、総合請負業者は、下請け業者によって要求された変動を拒絶している。図３２および図３３の「未提出」および「プロモート」要求オブジェクトはそれぞれ先の例におけるものと同じである。しかしながら、それぞれ図３４および図３５の「未マッチング」および「プロモート」応答オブジェクトにおいて、新しい契約構成要素の値は１０００ドルの代わりに０ドルにセットされる。結果として、マッチングおよびマージが完了した後、下請契約予算データ構造は、下請け業者によって提案されるように新しい下請契約単位項目を含むように更新されるが、応答オブジェクトによって指示されるようにその新しい単位項目の値は０ドルにセットされる。
【００７９】
上で議論された特定の例およびシナリオは、例示的であるように意図されており、排他的ではない。たとえば、上で記載されたメカニズムは、米国におけるインボイスの作成、オーストラリアにおける進捗請求、他の司法に関連する他の支払い要求メカニズムを統制するために使用されてもよい。したがって、上で使用される予算および支払い用語は、他の司法において使用される他のさまざまな用語に等しく適用するように意図される。
【００８０】
上で議論された例示的なデータ構造は、たとえばテキスト「ステータス」インジケータのようなテキスト構成要素を含んでいるが、これらのステータス識別子は、数字により実現されてもよいことが理解されるであろう。たとえば、「未提出」または「未マッチング」の初期状態ステータスには「１」の第１のステータス識別子値が割り当てられ得、「実行段階」ステータスは「２」の第２のステータス識別子値によって表わされ、「マージ」および「プロモート」の終了状態はそれぞれ、３および４の第３および第４のステータス識別子値によって表わされる。さらに、上で論じたように、本願明細書における例は主として、総合請負業者と下請け業者との間のインタラクションについて議論している。しかしながら、当該システムおよび方法は等しく他の参加者に適用され得る。他の参加者はたとえば、建築家、銀行、土地所有者、総合請負業者、元請負業者、下請け業者、材料サプライヤーなどを含む。
【００８１】
したがって、本発明はたとえば、そのような予算変動提案に従って、リンク付けされたデータ構造を使用することによって、予算変動を処理し、支払いを追跡および促進するためのシステムを提供する。本発明のさまざまな特徴および利点は添付の請求の範囲に記載される。
【図１Ａ】
0006426852.tif 000002
【図１Ｂ】
0006426852.tif 000003
【図１Ｃ】
0006426852.tif 000004
【図２】
0006426852.tif 000005
【図３】
0006426852.tif 000006
【図４Ａ】
0006426852.tif 000007
【図４Ｂ】
0006426852.tif 000008
【図４Ｃ】
0006426852.tif 000009
【図５】
0006426852.tif 000010
【図６】
0006426852.tif 000011
【図７】
0006426852.tif 000012
【図８】
0006426852.tif 000013
【図９】
0006426852.tif 000014
【図１０】
0006426852.tif 000015
【図１１】
0006426852.tif 000016
【図１２】
0006426852.tif 000017
【図１３】
0006426852.tif 000018
【図１４】
0006426852.tif 000019
【図１５】
0006426852.tif 000020
【図１６Ａ】
0006426852.tif 000021
【図１６Ｂ】
0006426852.tif 000022
【図１７】
0006426852.tif 000023
【図１８】
0006426852.tif 000024
【図１９】
0006426852.tif 000025
【図２０】
0006426852.tif 000026
【図２１】
0006426852.tif 000027
【図２２】
0006426852.tif 000028
【図２３】
0006426852.tif 000029
【図２４】
0006426852.tif 000030
【図２５】
0006426852.tif 000031
【図２６】
0006426852.tif 000032
【図２７】
0006426852.tif 000033
【図２８】
0006426852.tif 000034
【図２９】
0006426852.tif 000035
【図３０】
0006426852.tif 000036
【図３１】
0006426852.tif 000037
【図３２】
0006426852.tif 000038
【図３３】
0006426852.tif 000039
【図３４】
0006426852.tif 000040
【図３５】
0006426852.tif 000041
【図３６】
0006426852.tif 000042