(57)【要約】コーポレートの購入ニーヅの効率的管理を見越す、動的支払いカードと関連動的支払いカード管理システム及び付随する方法が開示される。該動的支払いカードは、動的に管理されるカード制御設定を有する従来型支払いカードとすることが出来る。加えて、動的カード管理システムはこれらのカード制御設定を動的に修正するためにカードプロセサーシステムと自動的にインターフエースすることが出来て、そして購入管理システム又は他の要求及び承認ワークフローエンジン（ｏｔｈｅｒ ｒｅｑｕｅｓｔ ａｎｄ ａｐｐｒｏｖａｌ ｗｏｒｋｆｌｏｗ ｅｎｇｉｎｅ）が会社と該動的カード管理システムとの間のインターフエースを提供出来る。より一般的には、購入機構に付随する取引オーソライゼーション決定の制御を助けるために動的に又は能動的に管理された承認パラメーターを利用する購入管理用の有利な解決策が開示される。これらの動的承認パラメーターは構成可能な会社購入ポリシー及び規則の適用を通して発生及び／又は管理され得て、そしてこれらの動的承認パラメーターは、例えば、該購入機構を使用して取引が始動される時オーソライゼーション決定を行う処理システムにより記憶されることが出来る。
2004519773.tif 000002
【特許請求の範囲】
【請求項１】
支払いカードの制御設定を動的に管理する方法に於いて、
エンテイテイ内のリクエスターから購入要求を受ける過程と、
該購入要求を該エンテイテイ用購入ポリシーに関して処理する過程と、
もし該購入ポリシーが満足されれば該購入要求を承認する過程と、
該承認された購入要求に付随する支払いカード用の制御設定をレビューする過程と、そして
該支払いカードが該承認された購入要求に付随する購入を行うため使用されるように該支払いカード用の該制御設定を調整する過程とを具備することを特徴とする該方法。
【請求項２】
該購入ポリシーが、１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能であることを特徴とする請求項１の該方法。
【請求項３】
該誂え可能な購入管理規則が組織構造と承認チェーンを構成する能力を有することを特徴とする請求項２の該方法。
【請求項４】
更に、承認者に、もし承認されるべき該購入要求用に該承認者からの何等かのアクションが必要であるならば、購入要求を知らせる過程と、そして該承認者がネットワークでアクセス可能な承認機構を通して該必要なアクションを取ることを可能にする過程とを具備することを特徴とする請求項２の該方法。
【請求項５】
該ネットワークがインターネットを含むことを特徴とする請求項２の該方法。
【請求項６】
更に、支払いカードに該エンテイテイ内の要素を付随させる過程を具備しており、該要素が該リクエスター、別の人、車両又は建物であることを特徴とする請求項１の該方法。
【請求項７】
受領された購入要求が該支払いカードのアイデンテイフイケーションを含むことを特徴とする請求項１の該方法。
【請求項８】
カードプロセサーが該支払いカード制御設定を記憶することを特徴とする請求項１の該方法。
【請求項９】
更に、該承認された購入要求用の１セットの承認パラメーターを発生する過程と、該購入が該支払いカードで行われるようにどんな調整を行うべきか決定するために該承認パラメーターを該制御設定と比較する過程と、を具備することを特徴とする請求項８の該方法。
【請求項１０】
該制御設定が該承認パラメーターと対応することを特徴とする請求項９の該方法。
【請求項１１】
更に、企てられた購入取引のパラメーターを該制御設定と比較する過程と、もし該パラメーターが該制御設定により許可されれば該購入取引をオーソライズする過程とを具備しており、該比較、オーソライズする過程が該カードプロセサーにより行われることを特徴とする請求項８の方法。
【請求項１２】
ベンダーがオーソライゼーション用に該企てられた購入取引の該パラメーターを該カードプロセサーに通信することを特徴とする請求項１１の該方法。
【請求項１３】
該レビューする過程は購入管理システムが該カードプロセサーに該支払いカード用の該制御設定を表す情報の要求を送る過程と、該カードプロセサーが該購入管理システムに該要求されたカード制御設定情報を送り返す過程と、を備えており、そして該調整する過程は該購入管理システムが該カードプロセサーに該カード制御設定への望まれる調整を送る過程と、該カードプロセサーが該望まれる調整に基づき該記憶されたカード設定を修正する過程と、を備えることを特徴とする請求項８の該方法。
【請求項１４】
少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の通信を処理することを特徴とする請求項１３の該方法。
【請求項１５】
該少なくとも１つの中間システムは、該購入管理システムと該カードプロセサーとの間の過程分離を提供し、該購入管理システムと該カードプロセサーの間の通信用の１つ以上の安全機構を提供し、そしてこれらの通信をそれらが認識されるフオーマットで受けられるように処理するよう構成された安全代行システムを備えることを特徴とする請求項１４の該方法。
【請求項１６】
該少なくとも１つの中間システムが更に、該カードプロセサー用の通信インターフエースを提供するインターフエースシステムを備えており、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信することを特徴とする請求項１５の該方法。
【請求項１７】
支払い機構の動的管理を提供するためにサーバーベースのシステムを動作させる方法に於いて、
１つ以上のサーバーシステムで支払い機構に関する或る購入能力を利用可能にする要求をエンテイテイ内から受ける過程と、
該支払い機構に付随する承認パラメーターを表す情報を得るために該１つ以上のサーバーシステムから処理システムへ通信する過程とを具備しており、該処理システムは該支払い機構に付随した承認パラメーターに基づき該支払機構を使用して始動された取引を処理するシステムであり、該承認パラメーターは該処理システムにより記憶されており、そして該方法は又、
該購入能力が利用可能になるように該支払い機構用の該承認パラメーターを調整する調整インストラクションを該１つ以上のサーバーシステムから該処理システムへ送る過程を具備することを特徴とする該方法。
【請求項１８】
該要求は１つ以上の望まれる取引に関する承認された購入要求を含んでおり、該承認された購入要求は該エンテイテイ内のリクエスターから購入要求を受け、該エンテイテイ用の購入ポリシーに関し該購入要求を処理し、そしてもし該購入ポリシーが満足されるなら該購入要求を承認し、そして該購入要求に基づき該要求を発生させることにより発生されることを特徴とする請求項１７の該方法。
【請求項１９】
更に、該支払い機構を使用して一旦完了された取引に付随する取引データを該１つ以上のサーバーシステムで受ける過程と該取引データを該購入要求と一致確認をする過程とを具備することを特徴とする請求項１８の該方法。
【請求項２０】
該要求が該支払い機構用の予め承認された購入用オーソリテイを提供する要求を有しており、そして該承認パラメーターがこの予め承認された購入用オーソリテイを提供するよう調整されることを特徴とする請求項１７の該方法。
【請求項２１】
更に、該１つ以上のサーバーシステムで、該支払い機構を使用して一旦完了した取引に付随する取引データを受ける過程と該取引データに基づき購入要求を合成する過程とを具備することを特徴とする請求項２０の該方法。
【請求項２２】
更に、該エンテイテイ用の購入ポリシーに関して該合成された購入要求を処理する過程ともし該購入ポリシーが満足されるなら該合成された購入要求を承認する過程とを具備することを特徴とする請求項２１の該方法。
【請求項２３】
更に、該取引の完了後の１つ以上の選択されたイベントの発生に基づいて該予め承認された購入オーソリテイを回復するために該承認パラメーターを調整する過程を具備することを特徴とする請求項２０の該方法。
【請求項２４】
複数の要求が複数の支払い機構に関し受けられ、そして複数の要求が各支払い機構に付随することを特徴とする請求項１７の該方法。
【請求項２５】
該支払い機構が支払いカードを有しており、該処理システムが支払いカード処理システムを有しており、該承認パラメーターが該支払いカード用制御設定を有しており、そして該１つ以上のサーバーシステムが購入管理システムを有することを特徴とする請求項１７の該方法。
【請求項２６】
少なくとも１つの中間システムが該購入管理システムと該支払いカードプロセサーの間の通信を処理することを特徴とする請求項２５の該方法。
【請求項２７】
該少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の過程分離を提供し、該購入管理システムと該カードプロセサーの間の通信用の１つ以上の安全機構を提供し、そしてこれらの通信をそれらが認識されたフオーマットで受けられるように処理するよう構成された安全代行システムを有することを特徴とする請求項２６の該方法。
【請求項２８】
該少なくとも１つの中間システムが更に該カードプロセサー用通信インターフエースを提供するインターフエースシステムを有しており、該安全代行システムが該インターフエースシステムを通して該カードプロセサーと通信することを特徴とする請求項２７の該方法。
【請求項２９】
該購入ポリシーは、１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能であることを特徴とする請求項１８の該方法。
【請求項３０】
該ネットワークがインターネットを含むことを特徴とする請求項２９の該方法。
【請求項３１】
更に、複数の支払いカードをエンテイテイ内の複数の要素に付随させる過程を具備しており、該要素は人、車両又は建物を含むことを特徴とする請求項２５の該方法。
【請求項３２】
更に、企てられた購入取引のパラメーターを該制御設定と比較する過程と、もし該パラメーターが該制御設定により許可されるなら該購入取引をオーソライズする過程とを具備しており、該比較する及びオーソライズする過程は該カードプロセサーにより行われることを特徴とする請求項２５の該方法。
【請求項３３】
ベンダーが該企てられた購入取引の該パラメーターをオーソライゼーション用に該カードプロセサーへ通信することを特徴とする請求項３２の該方法。
【請求項３４】
該制御設定がベンダーアイデンテイテイコードと最大単一取引リミットとを含むことを特徴とする請求項３２の該方法。
【請求項３５】
該支払い機構が動的支払い識別子を含むことを特徴とする請求項１７の該方法。
【請求項３６】
該支払い機構が更に支払いカードに付随した該動的支払い識別子を有する該支払いカードを備えることを特徴とする請求項３５の該方法。
【請求項３７】
該要求がエンテイテイの購入ポリシーに基づき承認された購入要求を含んでおり、該承認パラメーターが該承認された購入要求に付随する１セットの動的承認パラメーターを含んでおり、そして該処理システムが該承認された購入要求用の該動的承認パラメーターのセットを記憶することを特徴とする請求項３６の該方法。
【請求項３８】
更に、特定の動的支払い識別子に付随された複数の購入要求を受ける過程を具備しており、そして更に、各購入要求用に１セットの動的承認パラメーターを該１つ以上のサーバーシステムから該処理システムへ通信する過程を含んでおり、動的承認パラメーターの各セットは該処理システムにより記憶されることを特徴とする請求項３７の該方法。
【請求項３９】
更に、該動的支払い識別子を使用して行われた企てられた購入取引のパラメーターをその動的支払い識別子用に記憶された該動的承認パラメーターのセットと比較する過程と、もし該パラメーターが動的承認パラメーターの少なくとも１セットと整合するなら該購入取引をオーソライズする過程とを具備しており、該比較する過程とオーソライズする過程は該カード処理システムにより行われることを特徴とする請求項３８の該方法。
【請求項４０】
支払いカード制御設定を動的に管理するシステムに於いて、エンテイテイ内のリクエスターから購入要求を受け、該エンテイテイ用の購入ポリシーに関し該購入要求を処理し、もし該購入ポリシーが満足されるなら該購入要求を承認し、該承認された購入要求に付随する支払いカード用の制御設定をレビューし、そして該支払いカードが該承認された購入要求に付随する購入を行うため使用されるように該支払いカード用の該制御設定を調整するよう構成された１つ以上のシステムを具備することを特徴とする該システム。
【請求項４１】
該１つ以上のサーバーシステムが更に、購入ポリシーが該１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を操作することにより構成されるネットワークインターフエースを備えることを特徴とする請求項４０の該システム。
【請求項４２】
該誂え可能な購入管理規則が組織構造及び承認チェーンを構成する能力を有することを特徴とする請求項４１の該システム。
【請求項４３】
該１つ以上のサーバーシステムは更に、承認者に購入要求を知らせるが、それは承認されるべき該購入要求用に該承認者からの何等かのアクションが必要ならば、該承認者に該購入要求を知らせるよう構成されており、そして更に該承認者が該必要なアクションを取ることが出来るネットワークアクセス可能な承認機構を備えることを特徴とする請求項４１の該システム。
【請求項４４】
該ネットワークがインタネットを含むことを特徴とする請求項４３の該システム。
【請求項４５】
該支払いカードが該エンテイテイ内の要素に付随させられており、該要素は該リクエスター、別の人間、車両又は建物であることを特徴とする請求項４０の該システム。
【請求項４６】
該受けられる購入要求が該支払いカードの識別を含むことを特徴とする請求項４０の該システム。
【請求項４７】
更に、該支払いカード制御設定を記憶するカードプロセサーを具備することを特徴とする請求項４０の該システム。
【請求項４８】
該１つ以上のサーバーシステムが更に、該承認される購入要求用に１セットの承認パラメーターを発生し、そして該購入が該支払いカードで行われるためにどんな調整を行うべきか決定するために該承認パラメーターを該制御設定と比較するよう構成されていることを特徴とする請求項４７の該システム。
【請求項４９】
該制御設定が該承認パラメーターと対応することを特徴とする請求項４８の該システム。
【請求項５０】
該カードプロセサーは企てられた購入取引のパラメーターを該制御設定と比較し、そしてもし該パラメーターが該制御設定により許可されるなら該購入取引をオーソライズするよう構成されることを特徴とする請求項４７の該システム。
【請求項５１】
該カードプロセサーが更に、ベンダーから該企てられた購入取引の該パラメーターを受けそしてもし該企てられた購入取引が承認されれば該オーソライゼーションを該ベンダーに戻す通信を行うよう構成されることを特徴とする請求項５０の該システム。
【請求項５２】
該購入管理システムと該カードプロセサーとが更に、該購入管理システムが該支払いカード用の制御設定を表す情報を求める要求を該カードプロセサーに送りそして該カードプロセサーが該要求されたカード設定情報を該購入管理システムへ送り返し、そして次いで該購入管理システムが該カード設定への望まれる調整を該カードプロセサーへ送りそして該カードプロセサーが該望まれた調整に基づき該記憶されたカード設定を修正するように、構成されることを特徴とする請求項４７の該システム。
【請求項５３】
少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の通信を処理することを特徴とする請求項５２の該システム。
【請求項５４】
該少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の過程分離を提供し、該購入管理システムと該カードプロセサーの間の通信用の１つ以上の安全機構を提供し、そしてこれらの通信を、それらが認識されたフオーマットで受けられるように処理する、よう構成された安全代行システムを有することを特徴とする請求項５３の該システム。
【請求項５５】
該少なくとも１つの中間システムが更に、該カードプロセサー用の通信インターフエースを提供するインターフエースシステムを有し、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信することを特徴とする請求項５４の該システム。
【請求項５６】
支払い機構の動的管理を提供するサーバーベースのシステムに於いて、支払い機構に関して或る購入能力を利用可能にする要求をエンテイテイ内から受けるよう、該支払い機構に付随する承認パラメーターを表す情報を得るために処理システムと通信するが、該承認パラメーターは該支払い機構に付随する該承認パラメーターに基づいて該支払い機構を使用して始動される取引を処理すために該処理システムにより記憶され使用されている場合に、該処理システムと該通信するよう、そして該購入能力が利用可能になるよう該支払い機構用承認パラメーターを調整するために調整インストラクションを該処理システムに送るよう、構成される１つ以上のサーバーシステムを具備することを特徴とする該サーバーベースのシステム。
【請求項５７】
該要求が１つ以上の特定の望まれた取引に関する承認された購入要求を含んでおり、該１つ以上のサーバーシステムが更に、該エンテイテイ内のリクエスターから購入要求を受け、該購入要求を該エンテイテイ用の購入ポリシーに関して処理し、もし該購入ポリシーが満足されれば該購入要求を承認し、そして該購入要求に基づく該要求を発生させるよう構成されていることを特徴とする請求項５６の該サーバーベースのシステム。
【請求項５８】
更に、該支払い機構を使用して一旦完了した取引に付随する取引データを受けようそして該取引データを該購入要求と一致確認するよう構成された該１つ以上のサーバーシステムを更に具備することを特徴とする請求項５７の該サーバーベースのシステム。
【請求項５９】
該要求が該支払い機構用の予め承認された購入用オーソリテイを提供する要求を含んでおり、そして該承認パラメーターがこの予め承認された購入用オーソリテイを提供するよう調整されることを特徴とする請求項５６の該サーバーベースのシステム。
【請求項６０】
該１つ以上のサーバーシステムが更に、該支払い機構を使用して一旦完了した取引に付随する取引データを受けそして該取引データに基づき購入要求を合成するよう構成されることを特徴とする請求項５９の該サーバーベースのシステム。
【請求項６１】
該１つ以上のサーバーシステムが更に、該合成された購入要求を該エンテイテイ用の購入ポリシーに関して処理しそしてもし該購入ポリシーが満足されれば該合成された購入要求を承認するよう構成されることを特徴とする請求項６０の該サーバーベースのシステム。
【請求項６２】
該１つ以上のサーバーシステムが更に、該取引の完了後１つ以上の選択されたイベントの発生に基づき該予め承認された購入用オーソリテイを回復するために該承認パラメーターを調整する調整インストラクションを送るよう構成されることを特徴とする請求項５９の該サーバーベースのシステム。
【請求項６３】
複数の要求が複数の支払い機構に関し受けられ、複数の要求が各支払い機構に付随させられることを特徴とする請求項５６の該サーバーベースのシステム。
【請求項６４】
該支払い機構が支払いカードは含み、該処理システムは支払いカード処理システムを含み、該承認パラメーターは該支払いカード用制御設定を含み、そして該１つ以上のサーバーシステムは購入管理システムを含むことを特徴とする請求項５６の該サーバーベースのシステム。
【請求項６５】
少なくとも１つの中間システムが該購入管理システムと該支払いカードプロセサーとの間の通信を処理することを特徴とする請求項６４の該サーバーベースのシステム。
【請求項６６】
該少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の過程分離を提供し、該購入管理システムと該カードプロセサーの間の通信用の１つ以上の安全機構を提供し、そしてこれらの通信をそれらが認識されたフオーマットで受けられるように処理するよう構成された安全代行システムを含むことを特徴とする請求項６５の該サーバーベースのシステム。
【請求項６７】
該少なくとも１つの中間システムが更に、該カードプロセサー用の通信インターフエースを提供するインターフエースシステムを含み、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信することを特徴とする請求項６６の該サーバーベースのシステム。
【請求項６８】
該購入ポリシーが１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能であることを特徴とする請求項５７の該サーバーベースのシステム。
【請求項６９】
該ネットワークがインターネットを含むことを特徴とする請求項６８の該サーバーベースのシステム。
【請求項７０】
更に、エンテイテイ内の該複数の要素に複数の支払いカードを付随させる過程を具備することを特徴とする請求項６４の該サーバーベースのシステム。
【請求項７１】
該支払いカード処理システムが更に、企てられた購入取引のパラメーターを該制御設定と比較し、そしてもし該パラメーターが該制御設定により許可されれば該購入取引をオーソライズするよう構成されることを特徴とする請求項６４の該サーバーベースのシステム。
【請求項７２】
ベンダーがオーソライゼーション用に該企てられた購入取引のパラメーターを該カード処理システムへ通信することを特徴とする請求項７１の該サーバーベースのシステム。
【請求項７３】
該制御設定がベンダーアイデンテイテイコードと最大単一取引リミットとを含むことを特徴とする請求項７１の該サーバーベースのシステム。
【請求項７４】
該支払い機構が動的支払い識別子を含むことを特徴とする請求項５６の該サーバーベースのシステム。
【請求項７５】
該支払い機構が更に、支払いカードに付随する動的支払い識別子を有する様な該支払いカードを備えることを特徴とする請求項７４の該サーバーベースのシステム。
【請求項７６】
該要求がエンテイテイ購入ポリシーに基づき承認された購入要求を含み、該承認パラメーターは該承認された購入要求に付随する１セットの動的承認パラメーターを含み、そして該処理システムは該承認された購入要求用の該動的承認パラメーターのセットを記憶するよう構成されることを特徴とする請求項７５の該サーバーベースのシステム。
【請求項７７】
該１つ以上のサーバーシステムが更に、特定の動的支払い識別子に付随する複数の購入要求を受け、各購入要求用の１セットの動的承認パラメーターを該１つ以上のサーバーシステムから該処理システムへ通信するよう構成されており、動的承認パラメーターの各セットは該処理システムにより記憶されることを特徴とする請求項７６の該サーバーベースのシステム。
【請求項７８】
該カード処理システムが更に、該動的支払い識別子を使用して行われた企てられた購入取引のパラメーターをその動的支払い識別子用に記憶された該動的承認パラメーターのセットと比較し、もし該パラメーターが動的承認パラメーターの少なくとも１セットと整合すれば該購入取引をオーソライズするよう構成されていることを特徴とする請求項７７の該サーバーベースのシステム。
【発明の詳細な説明】
【０００１】
［発明の技術分野］
製品及びサービス調達（ｐｒｏｃｕｒｅｍｅｎｔ）用の購入管理システム（ｐｕｒｃｈａｓｉｎｇ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｒｅｍ）に関し、クレデイットカード、商業カード（ｃｏｍｍｅｒｃｉａｌ ｃａｒｄ）、コーポレートカード（ｃｏｒｐｏｒａｔｅ ｃａｒｄｓ）、フリートカード（ｆｌｌｅｔ ｃａｒｄｓ）、スマートカード（ｓｍａｒｔ ｃａｒｄｓ）、ストアドバリューカード（ｓｔｏｒｅｄ ｖａｌｕｅ ｃａｒｄｓ）、調達カード（ｐｒｏｃｕｒｅｍｅｎｔ ｃａｒｄｓ）そして購入（ｐｕｒｃｈａｓｉｎｇ）｛又は”ピー（Ｐ）”｝カードの様な支払いカード（ｐａｙｍｅｎｔ ｃａｒｄ）を含む、購入機構（ｐｕｒｃｈａｓｉｎｇ ｍｅｃｈａｎｉｓｍｓ）と、これらの購入機構用関連処理インフラストラクチャー（ｒｅｌａｔｅｄ ｐｒｏｃｅｓｓｉｎｇ ｉｎｆｒａｓｔｒｕｃｔｕｒｅｓ ｆｏｒ ｔｈｅｓｅ ｐｕｒｃｈａｓｉｎｇ ｍｅｃｈａｎｉｓｍｓ）と、に関する。
【０００２】
［背景］
大抵の会社は広範な種類の購入のニーヅを有する。しかしながら、コーポレートの購入は効率的に管理し制御するのが難しい場合が多い。例えば、オフイス製品、オフイス供給品（ｏｆｆｉｃｅ ｓｕｐｐｌｉｅｓ）、サービス、そしてマーケッテング材料（ｍａｒｋｅｔｉｎｇ ｍａｔｅｒｉａｌｓ）の購入の様な会社又は組織的支出として行われる購入は購入要求と、付随する支払い手順とを伴う承認過程と、を通して扱われる場合が多い。しかしながら、これらの手順は典型的に非効率的である。購入要求と承認過程とに加えて、コーポレート経費用に払い戻し手順（ｒｅｉｍｂｕｒｓｅｅｍｎｅｔ ｐｒｏｃｅｄｕｒｅｓ）も又使用される。例えば個人の出張及び接待の経費は、従業員が最初該経費用に支払いそして次いで払い戻しを請求する、払い戻し手順を通して扱われることが多い。しかしながら、払い戻し手順は典型的に非効率的で、彼等自身のフアンド（）で該支出を行い、次いでそれらが払い戻されるように承認されたガイドライン内で彼等が行いつつあることを希望せねばならない従業員にとって望ましくないことが多い。
【０００３】
典型的に利用される非効率的手順のために、購入管理は大抵の会社では可成りなコストを発生することが多い。この購入管理は大抵の会社が製品及びサービスを購入する広範な種類の販売チャンネル又はマーケットのためになお一層難しく複雑にされている。例えば、これらの販売チャンネルはカタロブ販売、店内販売、電話販売、オンライン販売｛小売ウエブサイト（ｒｅｔａｉｌ ｗｅｂｓｉｔｅｓ）、公共マーケットプレース／交換所（ｐｕｂｌｉｃ ｍａｒｋｅｔｐｌａｃｅｓ／ｅｘｃｈａｎｇｅｓ）、私的マーケットプレース／交換所（ｐｒｉｖａｔｅ ｍａｒｋｅｔｐｌａｃｅｓ／ｅｘｃｈａｎｇｅｓ）、他｝そして種々の他の利用可能な販売チャンネルを含む。購入される製品又はサービス、或いは製品及びサービスが購入される販売チャンネル又はマーケットに関係なく、会社は１つの共通の購入及び承認過程（ｏｎｅ ｃｏｍｍｏｎ ｐｕｒｃｈａｓｉｎｇ ａｎｄ ａｐｐｒｏｖａｌ ｐｒｏｃｅｓｓ）を通してそれらの製品及びサービスの購入を管理（ｍａｎａｇｅ）する能力を有することが望ましい。
【０００４】
典型的購入管理解決策は製品調達を自動化するビジネスツービジネス電子的コマース適用（ｂｕｓｉｎｅｓｓ−ｔｏ−ｂｕｓｉｎｅｓｓ ｅｌｅｃｔｒｏｎｉｃ ｃｏｍｍｅｒｃｅ ａｐｐｌｉｃａｔｉｏｎｓ）であった。しかしながら、これらのシステムは、バイヤーに多数サプライヤーに亘るその調達過程を管理する能力を提供しない簡単なウエブベースの解決策（例えば、オフイスサプライ小売商により保持されるウエブサイト）であるか、又は、代わって、各クライアント（例えば、コンピユータワークステーション）で特別のプログラムの展開を要する大きな、企業ベースの解決策である。該後者の応用例は屡々インターネット経由でウエブベースのインタフエースを提供するが、それらは、クライアント側ソフトウエアが展開、保持そして屡々更新されねばならないことが多いので望ましくない。又これらの誂えられたシステムは極めて高価で、該応用例の各展開用に該応用ソフトウエアの”インスタンス（ｉｎｓｔａｎｃｅ）”の創生と管理を要する。結果として、これらの企業型の応用システムは広く展開されたベースでは実施されずそして大抵の会社の購入管理用には実用的でない。かくして、これら及び他の問題と従来技術の欠点を克服する購入過程管理用の新しい技術を提供するニーヅが残っている。
【０００５】
会社が如何に購入を行うかに関し、銀行及び金融機関は、クレデイットカード、ストアドバリューカード、商業カード、コーポレートカード、フリートカード、調達カード、購入又は”ピー”カード、そしてスマートカードの様な、支払いカードを含め、種々の支払い機構を提供している。しかしながら、これらの従来の提供品は全てが購入管理用のツールとしては限られた有用性である。クレデイット及びデビットカードは該会社又はその勘定が購入に責任を有する会社カードとして、又は従業員又は従業員の勘定が購入に責任を有する個人カードとして、セットアップされ得る。会社は、それにより予めの承認無しに、従業員に会社デビットを創る又は会社フアンドを支出する能力を与える、会社クレデイット又はデビットカード発行することには非常に気が進まぬのが典型的である。もし従業員勘定が使用されれば、その取引は払い戻す取引として扱われる。
【０００６】
ストアドバリューカードは本質的に、予め決められた支出又はクレデイットリミット（ｐｒｅ−ｄｅｔｅｒｍｉｎｅｄ ｓｐｅｎｄｉｎｇ ｏｒ ｃｒｅｄｉｔ ｌｉｍｉｔｓ）を有するプリペイドクレデイットカードである。これらのストアドバリューカードは消費者マーケットに市販されたが、例えば、それは、親に、クレデイットカードでの購入の容易さを提供しながら彼等の子供の支出を制御可能にする機構としてである。スマートカードは集積回路を含むカードである。スマートカードの増加したメモリーと処理能力は、ことによると銀行及び金融機関がユーザーに増加した利用、機能そして便利さを提供することを可能にするとして宣伝された。しかしながら、スマードカードの不利な面はスマートカードは何等かの新しく展開された特徴が利用される前に新しいインフラストラクチャーがマーチャントにより取り入れられ行われることを要しそうなことである。
【０００７】
購入カードプログラムは銀行及び金融機関により提供される支払い機構であり、それは会社支払いニーヅを助けることに一層特別に向けられている。購入カード又は”ピー”カードは本質的には、予め承認されたベンダー、予め承認された取引量リミット（ｔｒａｎｓａｃｔｉｏｎ ａｍｏｕｎｔ ｌｉｍｉｔｓ）、そして予め承認された全体的クレデイットリミット（ｐｒｅ−ａｐｐｒｏｖｅｄ ｏｖｅｒａｌｌ ｃｒｅｄｉｔ ｌｉｍｉｔｓ）の様な２，３の静的制限（ａ ｆｅｗ ｓｔａｔｉｃ ｌｉｍｉｔａｔｉｏｎｓ）を使用して会社にカードを予め承認可能にする２，３の追加的な制御の特徴を持った会社クレデイットカードである。一旦セットアップされると、これらの購入カードは本質的に予め決められた静的制限を有するクレデイットカードとして作用する。かくして、購入カードは典型的クレデイットカードが行うより多い制御を可能にするが、その会社はなお従業員により始動される特定の購入の制御は出来ず、何故ならば該カードの制限は静的で、支出要求は与えられたカード用に全て予め承認されるからである。要するに、購入は常に会社購入ポリシー（ｃｏｍｐａｎｙ ｐｕｒｃｈａｓｉｎｇ ｐｏｌｉｃｉｅｓ）に照らしてレビューされるか又は承認されること無く完了されてもよいからである。従って購入カードは望ましい購入管理解決策を提供するに至らない。
【０００８】
購入カードプログラムは有効に配布されたクレデイットカードプログラムである。コーポレートカードの個人的請求（ｉｎｄｉｖｉｄｕａｌ ｂｉｌｌｉｎｇ）と相対して、購入カードは一般に会社請求（ｃｏｍｐａｎｙ ｂｉｌｌｉｎｇ）と、マスター勘定と個人カードレベルの両者での特定的会社束縛（ｓｐｅｃｉｆｉｃ ｃｏｍｐａｎｙ ｃｏｎｓｔｒａｉｎｔｓ）との特徴を有する。従来のカード処理能力に基づき、購入カードの銀行により静的に構成され得る束縛と承認パラメーターの種類は表１で示す下記例の制御特徴を有する。
【０００９】
【表１】
2004519773.tif 000003
【００１０】
これらのパラメーターの変更は従来、どんな変更が行われる必要があるかを決定し、銀行にコンタクトし、そして該変更が行われることを要求するオーソライズされた会社代表又は従業員を要した。どんな与えられたカードでも制御特徴に変更が望まれる時は何時も、銀行従業員又は他の個人によるこの手動介入と続くアクションが達成されねばならない。驚くことではないが、大抵の会社は例外が起こる毎回に該束縛を変えることより異なるフオームの支払いを使用する方が容易であると分かっている。結果として、支出の制御を増やすことはカードを用いて行われる会社支出の量を減らしそして該カードプログラムにより約束された付随処理効率を減じている。又この矛盾は、例外が起こる度の失われる交換収入と、関係する会社のカード使用の制限、カードプログラムを実施しない見込み顧客か、又は該プログラムを終了する確立済みカードプログラムを有する会社か何れかのための喪失顧客と、を含めて多数のフロントでの銀行の成長機会を制限する。要するに、これらの静的束縛は該購入カードの一般的利用を減じ、それにより該発行する銀行により取り込まれる付随ライセンス化と交換収入とを減じる。
【００１１】
［発明の概要］
本発明はコーポレート購入ニーヅの効率的管理を許容する動的支払いカード（ｄｙｎａｍｉｃ ｐａｙｍｅｎｔ ｃａｒｄｓ）及び関連する動的支払いカード管理システム（ｄｙｎａｍｉｃ ｐａｙｍｅｎｔ ｃａｒｄ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍｓ）と付随する方法とを提供する。本発明に依れば、該動的支払いカードは従来の支払いカードとすることが出来るが、動的に管理される（ｄｙｎａｍｉｃａｌｌｙ ｍａｎａｇｅｄ）カード制御設定（ｃａｒｄ ｃｏｎｔｒｏｌ ｓｅｔｔｉｎｇｓ）を有する。加えて、動的カード管理システムはこれらのカード制御設定を動的に修正するためにカードプロセサーシステム（ｃａｒｄ ｐｒｏｃｅｓｓｏｒ ｓｙｓｔｅｍ）と自動的にインターフエース出来て、購入管理システム又は他の要求及び承認ワークフローエンジン（ｒｅｑｕｅｓｔ ａｎｄ ａｐｐｒｏｖａｌ ｗｏｒｋｆｌｏｗ ｅｎｇｉｎｅ）が会社と該動的カード管理システムとの間のインターフエースを提供出来る。更に一般的に、購入機構に付随する取引オーソライゼーション決定（ｔｒａｎｓａｃｔｉｏｎ ａｕｔｈｒｉｚａｔｉｏｎ ｄｅｔｅｒｍｉｎａｔｉｏｎｓ）の制御を助けるために動的に又は能動的に管理される承認パラメーター（ａｐｐｒｏｖａｌ ｐａｒａｍｅｔｅｒｓ）を利用することにより購入管理用の有利な解決策を達成する。これらの動的承認パラメーターは構成可能な会社購入ポリシーと規則の適用を通して発生及び／又は管理され得て、そしてこれらの動的承認パラメーター、例えば、該購入機構を使用して取引が始動される時オーソライゼーション決定を行う処理システムにより、記憶され得る。
【００１２】
１実施例では、本発明は支払いカード制御設定を動的に管理するための方法であるが、それはエンテイテイ（ｅｎｔｉｔｙ）内のリクエスター（ｒｅｑｕｅｓｔｏｒ）から購入要求を受ける過程、該エンテイテイの購入ポリシーに関して該購入要求を処理する過程、もし該購入ポリシーが満足されれば該購入要求を承認する過程、該承認された購入要求に付随する支払いカード用の制御設定をレビューする過程、そして該支払いカードが該承認された購入要求に付随する購入を行うため使用されるように該支払いカード用制御設定を調整する過程を含む。加えて、購入ポリシーは、１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能に出来ており、該誂え可能な購入管理規則は組織構造（ｏｒｇａｎｉｚａｔｉｏｎ ｓｔｒｕｃｔｕｒｅｓ）と承認チエーン（ａｐｐｒｏｖａｌ ｃｈａｉｎｓ）を構成する能力を有することが出来る。更に、該方法は、もし承認されるべき該購入要求用に該承認者からの何かのアクションが必要なら、承認者に購入要求を知らせる過程と、そしてネットワークでアクセス可能な承認機構を通して該承認者が必要なアクションを取ることを可能にする過程と、を含む。このネットワークはインターネットを含んでもよい。なお更に、該方法は支払いカードに該エンテイテイ内の要素を付随させる過程を含んでもよく、該要素は例えば、該リクエスター、別の人、車両又はビルデイングとすることも出来る。加えて、該受けられた購入要求は該支払いカードの識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を含んでもよい。
【００１３】
より詳細な点では、該方法は該支払いカード制御設定を記憶するカードプロセサーを含んでもよい。該方法は更に該承認された購入要求用に１セットの承認パラメーターを発生し、該購入が該支払いカードで行われるようにどんな調整を行うべきか決定するために該承認パラメーターを該制御設定と比較する過程を含んでもよい。加えて、該制御設定は該承認パラメーターと対応してもよい。又該方法は、企てられた購入取引のパラメーターを該制御設定と比較し、そしてもし該パラメーターが該制御設定により許可されるならば該購入取引をオーソライズするために該カードプロセサーが作用することを含み、そしてベンダーはオーソライゼーションのために該企てられた購入取引の該パラメーターを該カードプロセサーに通信してもよい。なお更に、該方法のレビューする過程は該支払いカード用制御設定を表す情報の要求を該カードプロセサーに購入運営システムが送ることと、該要求されたカード制御設定情報を該購入管理システムへ該カードプロセサーが送り返すことを含んでもよい。そして該調整過程は該カード制御設定への望まれる調整を該購入管理システムが該カードプロセサーへ送ること、そして該カードプロセサーが該望まれる調整に基づいて該記憶されたカード設定を修正することを含んでもよい。
【００１４】
更に詳細な点では、該方法は、該購入管理システムと該カードプロセサーの間の通信を処理する少なくとも１つの中間システム（ｉｎｔｅｒｍｅｄｉａｔｅ ｓｙｓｔｅｍ）を有してもよい。この中間システム又は該複数システムは該購入管理システムからの送信を受けそれらを該カードプロセサーにより認識されるフオーマットで該カードプロセサーへ送り、該カードプロセサーから送信を受けそれらを該購入管理システムにより認識されるフオーマットで該購入管理システムへ送り、そして該購入管理システム及び該カードプロセサーと通信するための少なくとも１つの安全機構（ｓｅｃｕｒｉｔｙ ｍｅｃｈａｎｉｓｍ）を提供する安全代行システム（ｓｅｃｕｒｅ ｐｒｏｘｙ ｓｙｓｔｅｍ）を有してもよい。該中間システム（含む複数）は又該カードプロセサー用通信インターフエースを提供するインターフエースシステムを含んでもよく、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信する。
【００１５】
更に進んだ実施例では、本発明は支払い機構に関し或る購入能力（ｐｕｒｃｈａｓｉｎｇ ｃａｐａｂｉｌｉｔｉｅｓ）を利用可能（ｍａｋｅ ａｖａｉｌａｂｌｅ）にするためにエンテイテイ内からの要求を１つ以上のサーバーシステムで受け、該支払い機構に付随する承認パラメーターを表す情報を得るために該１つ以上のサーバーシステム（ｓｅｒｖｅｒ ｓｙｓｔｅｍｓ）から処理システム（ｐｒｏｃｅｓｓｉｎｇ ｓｙｓｔｅｍ）へ通信し、そして該購入能力が利用可能になるように該支払い機構用承認パラメーターを調整する調整指示（ａｄｊｕｓｔｍｅｎｔ ｉｎｓｔｒｕｃｔｉｏｎ）を該１つ以上のサーバーシステムから該処理システムへ送ることを含む支払い機構の動的管理を提供するためにサーバーベースのシステムを操作するための方法であり、そこでは該処理システムは該支払い機構に付随しそして該処理システムにより記憶される承認パラメーターに基づき、該支払い機構を使って始動される取引を行うシステムである。加えて、該要求は、該エンテイテイ内のリクエスターから購入要求を受け、該エンテイテイの購入ポリシーに関して該購入要求を処理し、そして該購入ポリシーが満足されるなら該購入要求を承認し、そして該購入要求に基づき要求を発生する、ことにより発生される１つ以上の望まれる取引に関する承認された購入要求を含むことが出来る。更に進んで、該１つ以上のサーバーシステムは該支払い機構を使用して一旦完了された取引に付随する取引データを受け、そして該取引データを該購入要求と一致確認（ｒｅｃｏｎｃｉｌｉｎｇ）をしてもよい。
【００１６】
より詳細な点では、該方法は該支払い機構用の予め承認された購入用オーソリテイ（ｐｒｅ−ａｐｐｒｏｖｅｄ ｐｕｒｃｈａｓｉｎｇ ａｕｔｈｏｒｉｔｙ）を提供する要求を有する要求を備えてもよく、それはこの予め承認された購入用オーソリテイを提供するために該承認パラメーターが調整されることに帰着する。該１つ以上のサーバーシステムは又該支払い機構を使用して一旦完了した取引に付随した取引データを受けることも出来て、該取引データに基づき購入要求を合成することが出来る。該合成された購入要求は更に該エンテイテイの購入ポリシーに関して処理されることが出来てそしてもし該購入ポリシーが満足されれば承認されることが出来る。なお更に、該承認パラメーターは該取引の完了後１つ以上の選択されたイベントの発生に基づき該予め承認された購入用オーソリテイを回復するため調整されることが出来る。他の詳細な点では、複数の要求が複数の支払い機構に関して受けられ、そして複数の要求が各支払い機構に付随することが出来る。該支払い機構は支払いカードを含むことが出来て、該処理システムは支払いカード処理システムを含むことが出来て、該承認パラメーターは該支払いカード用の制御設定を含むことが出来てそして該１つ以上のサーバーシステムは購入管理システムを含むことが出来る。
【００１７】
なお更に詳細な点では、該方法は該購入管理システムと該支払いカードプロセサーの間の通信を処理する少なくとも１つの中間システムを含むことが出来る。この中間システム又は該複数システム（ｉｎｔｅｒｍｅｄｉａｔｅ ｓｙｓｔｅｍ ｏｒ ｓｙｓｔｅｍｓ）は該購入管理システムからの送信を受けそしてそれらを該カード処理システムへ該カード処理システムにより認識されるフオーマットで送り、該カードプロセサーからの送信を受けそれらを該購入管理システムへ該購入管理システムにより認識されるフオーマットで送り、そして該購入管理システム及び該カードプロセサーとの通信用に少なくとも１つの安全機構を提供する安全代行システム（ｓｅｃｕｒｅ ｐｒｏｘｙ ｓｙｓｔｅｍ）を含んでもよい。加えて、該少なくとも１つの中間システムは更に該カードプロセサー用の通信インターフエースを提供するインターフエースシステムを含むことが出来て、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信する。なお更に、複数の支払いカードが、例えば人、車両又は建物とすることが出来るエンテイテイ内の複数の要素に付随することが出来る。又該制御設定はベンダーアイデンテイテイコード（ｖｅｎｄｏｒ ｉｄｅｎｔｉｔｙ ｃｏｄｅ）及び最大単一取引リミット（ｍａｘｉｍｕｍ ｓｉｎｇｌｅ ｔｒａｎｓａｃｔｉｏｎ ｌｉｍｉｔ）を含むことが出来る。該方法は、企てられた購入取引のパラメーターを該制御設定と比較し、もし該パラメーターが該制御設定により許可されれば該購入取引をオーソライズするカードプロセサーを含むことが出来る。そしてベンダーはオーソライゼーション（ａｕｔｈｏｒｉｚａｔｉｏｎ）用に該企てられた購入取引のパラメーターを該カードプロセサーに通信してもよい。
【００１８】
なお他の詳細な点では、該支払い機構はクレデイットカード番号の様な、動的支払い識別子（ｄｙｎａｍｉｃ ｐａｙｍｅｎｔ ｉｄｅｎｔｉｆｉｅｒ）を含むことが出来て、より特定的には、該支払い機構はそれに付随した動的支払い識別子を有する支払いカードとすることが出来る。該要求はエンテイテイ購入ポリシーに基づき承認された購入要求を含むことが出来て、該承認パラメーターは該承認された購入要求に付随する１セットの動的承認パラメーターを含むことが出来て、そして該処理システムは該承認された購入要求用の動的承認パラメーターの該セットを記憶する。加えて、該方法は特定の動的支払い識別子に付随する複数の購入要求を受ける過程を含み、そして更に各購入要求用の１セットの動的承認パラメーターを該１つ以上のサーバーシステムから該処理システムへ通信する過程を含むが、動的承認パラメーターの各セットは該処理システムにより記憶される。なお更に、該方法は該動的支払い識別子を使用して行われた企てられた購入取引のパラメーターをその動的支払い識別子用に記憶された動的承認パラメーターの該セットと比較し、そしてもし該パラメーターが動的承認パラメーターの少なくとも１セットと整合すれば該購入取引をオーソライズする該カード処理システムを含んでもよい。
【００１９】
もう１つの実施例では、本発明は、エンテイテイ内のリクエスターから購入要求を受け、該購入要求を該エンテイテイの購入ポリシーに関して処理し、もし該購入ポリシーが満足されれば該購入要求を承認し、該承認された購入要求に付随する支払いカード用の制御設定をレビューし、そして該支払いカードが該承認された購入要求に付随する購入を行うため使用されてもよいように該支払いカード用制御設定を調整するよう構成された１つ以上のシステムを含む支払いカード制御設定を動的に管理するシステムである。該１つ以上のサーバーシステムは更に、該１つ以上のサーバーシステム上に定在する（ｒｅｓｉｄｅ ｏｎ ｔｈｅ ｏｎｅ ｏｒ ｍｏｒｅ ｓｅｖｅｒ ｓｙｓｔｅｍｓ）複数の誂え可能な購入管理規則（ｃｕｓｔｏｍｉｚａｂｌｅ ｐｕｒｃｈａｓｉｎｇ ｍａｎａｇｅｍｅｎｔ ｒｕｌｅｓ）を操作することにより購入ポリシーが構成されるネットワークインターフエースを含むことが出来て、そして該誂え可能な購入管理規則は組織構造と承認チェーン（ｏｒｇａｎｉｚａｔｉｏｎ ｓｔｒｕｃｔｕｒｅｓ ａｎｄ ａｐｐｒｏｖａｌ ｃｈａｉｎｓ）を構成する能力を含むことが出来る。加えて、該サーバーシステムは、もし承認されるべき該購入要求用に承認者からの何等かのアクションが必要ならば、承認者に購入要求を知らせるよう構成されることが出来て、更に該承認者が該必要なアクションを取ることが出来るネットワークアクセス可能な承認機構（ａｐｐｒｏｖａｌ ｍｅｃｈａｎｉｓｍ）を含んでいる。そしてこのネットワークはインターネットを含むことが出来る。なお更に、該支払いカードは、例えば、該リクエスター、別の人間、車両又は建物とすることが出来る該エンテイテイ内要素に付随することが出来る。そして該受けられた購入要求は該支払いカードの識別を含むことが出来る。
【００２０】
更に詳細な点では、該システムは該支払いカード制御設定を記憶するカードプロセサーを含むことが出来る。そして該１つ以上のサーバーシステムは更に、該承認された購入要求用に１セットの承認パラメーターを発生し、該購入が該支払いカードを用いて行われてもよいようにどんな調整を行うべきかを決定するために該承認パラメーターを該制御設定と比較するよう構成されることが出来る。加えて、該制御設定は該承認パラメーターと対応することが出来る。又該カードプロセサーは企てられた購入取引のパラメーターを該制御設定と比較し、もし該パラメーターが該制御設定により許可されれば該購入取引をオーソライズするよう構成されることが出来る。加えて、該カードプロセサーはベンダーから該企てられた購入取引のパラメーターを受け、もし該企てられた購入取引が承認されれば該オーソライゼーションを該ベンダーに戻して通信するよう構成されることが出来る。なお更に、該購入管理システムと該カードプロセサーは、該購入管理システムが該支払いカード用の制御設定を表す情報の要求を該カードプロセサーに送り、該カードプロセサーが該要求されたカード設定情報を該購入管理システムに送り返し、そして次いで該購入管理システムが該カードプロセサーに該カード設定への望まれる調整を送り、該カードプロセサーが該望まれた調整に基づいて該記憶されたカード設定を修正するように構成されることが出来る。
【００２１】
追加的な詳細点では、該システムは該購入管理システムと該カードプロセサーの間の通信を処理する少なくとも１つの中間システムを含むことが出来る。該中間システム又は該複数システム（ｉｎｔｅｒｍｅｄｉａｔｅ ｓｙｓｔｅｍ ｏｒ ｓｙｓｔｅｍｓ）は、該購入管理システムからの送信を受け、それらを該カードプロセサーへ該カードプロセサーにより認識されうフオーマットで送り、該カードプロセサーからの送信を受けそれらを該購入管理システムへ該購入管理システムにより認識されるフオーマットで送り、そして該購入管理システム及びカードプロセサーとの通信用の少なくとも１つの安全機構を提供するよう構成された安全代行システムを含んでもよい。加えて、中間システム又は該複数システムは更に、該カードプロセサー用に通信インターフエースを提供するインターフエースシステムを含むことが出来て、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信する。
【００２２】
更に進んだ実施例では、本発明は、支払い機構に関する或る購入能力を利用可能にする要求をエンテイテイ内から受けるよう、そして該支払い機構に付随する承認パラメーターを表す情報を得るために処理システムと通信するが、該承認パラメーターは該支払い機構に付随する該承認パラメーターに基づき該支払い機構を使用して始動される取引を処理するために該処理システムにより記憶されそして使用される場合に、該処理システムと該通信するよう、そして該購入能力が利用可能となるように該支払い機構用に該承認パラメーターを調整するために調整指示を該処理システムへ送るよう、構成された１つ以上のサーバーシステムを含む支払い機構の動的管理を提供するサーバーベースのシステムである。特に、該要求は１つ以上の特定の望まれた取引に関する承認された購入要求を含むことが出来て、該１つ以上のサーバーシステムは更に、該エンテイテイ内のリクエスターから購入要求を受け、該購入要求を該エンテイテイの購入ポリシーに関して処理し、もし該購入ポリシーが満足されれば該購入要求を承認し、そして該購入要求に基づき該要求を発生するよう構成されることが出来る。該１つ以上のサーバーシステムは更に該支払い機構を使用して一旦完了した取引に付随する取引データを受け、該取引データを該購入要求と一致確認するよう構成されることが出来る。
【００２３】
より詳細な点では、該サーバーベースのシステムは該支払い機構用に予め承認された購入用オーソリテイを提供する要求を有する要求を備えることが出来て、該承認パラメーターはこの予め承認された購入用オーソリテイを提供するよう調整されることが出来る。又、該１つ以上のサーバーシステムは更に、該支払い機構を使用して一旦完了した取引に付随した取引データを受け、該取引データに基づき購入要求を合成するよう構成されることが出来る。又該サーバーシステムは該合成された購入要求を該エンテイテイの購入ポリシーに関して処理し、もし該購入ポリシーが満足されれば該合成された購入要求を承認するよう構成されることが出来る。なお更に、該サーバーシステムは該取引の完了後１つ以上の選択されたイベントの発生に基づき該予め承認された購入用オーソリテイを回復するために該承認パラメーターを調整する調整指示を送るよう構成されることが出来る。なお更に、複数の要求が複数の支払い機構に関して受けられることが出来て、そして複数の要求が各支払い機構に付随させられることが出来る。加えて、複数の支払いカードがエンテイテイ内の該複数の要素に付随させられることが出来る。又該購入ポリシーは１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能とすることも出来て、このネットワークはインターネット含むことが出来る。
【００２４】
更に詳細な点では、該サーバーベースのシステムは支払いカードを有する支払い機構、支払いカード処理システムを有する処理システム、該支払いカード用制御設定を有する承認パラメーター、そして購入管理システムを有する１つ以上のサーバーシステムを備えることが出来る。加えて、該サーバーベースのシステムは該購入管理システムと該支払いカードプロセサーの間の通信を処理する少なくとも１つの中間システムを含んでもよい。該中間システム又は該複数システムは該購入管理システムからの送信を受けそしてそれらを該カード処理システムへ該カード処理システムにより認識されるフオーマットで送り、該カードプロセサーから送信を受けそしてそれらを該購入管理システムへ該購入管理システムにより認識されるフオーマットで送り、そして該購入管理システム及び該カードプロセサーとの通信用に少なくとも１つの安全機構を提供する、よう構成された安全代行システムを含むことが出来る。加えて、該中間システム又は該複数システムは該カードプロセサー用の通信インターフエースを提供するインターフエースシステムを含むことが出来て、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信する。なお更に、該カード処理システムは企てられた購入取引のパラメーターを該制御設定と比較し、もし該パラメーターが該制御設定により許可されれば該購入取引をオーソライズするよう更に構成される。加えて、ベンダーは該企てられた購入取引の該パラメーターをオーソラオゼーション用に該カード処理システムへ通信出来る。なお更に、該制御設定はベンダーアイデンテイテイコードと最大単一取引リミットを含むことが出来る。
【００２５】
なおより詳細な点では、該サーバーベースのシステムは動的支払い識別子を有する支払い機構を備えることが出来て、該支払い機構はそれらに付随した動的支払い識別子を有する支払いカードであってもよい。加えて、該サーバーシステム又は該複数システムにより受けられた該要求はエンテイテイ購入ポリシーに基づいて承認された購入要求を含むことが出来て、そこでは承認パラメーターは該承認された購入要求に付随する１セットの動的承認パラメーターを含み、そしてそこでは該処理システムは該承認された購入要求用の動的承認パラメーターの該セットを記憶するよう構成されている。又、該サーバーシステムは更に特定の動的支払い識別子に付随する複数の購入要求を受け、各購入要求用の１セットの動的承認パラメーターを該１つ以上のサーバーシステムから該処理システムへ通信するよう構成されており、動的承認パラメーターの各セットは該処理システムにより記憶される。なお更に、該カード処理システムは該動的支払い識別子を使用して行われた企てられた購入取引のパラメーターをその動的支払い識別子用に記憶された動的承認パラメーターの該セットと比較し、もし該パラメーターが動的承認パラメーターの少なくとも１セットと整合するなら該購入取引をオーソライズするよう構成出来る。
【００２６】
［本発明の詳細な記述］
本発明は動的支払いカード及び付随する動的支払いカード管理システムと付随する方法とを提供する。部分的には、本発明は、制御設定が購入ニーヅに基づき動的に調整され、修正されてもよいカードプロセサーへのインターフエースを提供することにより、従来の支払いカード用にカード制御設定の動的管理を見越している。本発明の購入管理システムを使用して、会社は購入ポリシーと承認規則をセットアップし、次いでそれらのポリシーと規則とをその従業員へ提供された動的支払いカードと調和されさせてもよい。該購入管理システムが、これらの従業員の購入要求又は他の活動がそれぞれのカードの制御特徴への調整を要すると決定すると、該購入管理システムは該カード制御設定への変更を行うために適当なカードプロセサーとインターフエースすることが出来て、それにより購入ニーヅに基づきカード制御設定の動的管理を提供する。取引が始動されると、該カードプロセサーは承認情報を該マーチャントへ提供するためにこれらの動的制御特徴に頼ることが出来る。次いで取引データは整合、一致確認そして会計の目的で該カードプロセサーから購入管理システムへ戻して提供される。本発明の動的支払いカード処理のこれら及び他の特徴は更に下記で説明される。
【００２７】
より一般的には、本発明は購入機構に付随する取引オーソライゼーション決定の制御を助けるために、購入ニーヅに基づき動的又は能動的に管理される承認パラメーターの様な動的承認パラメーターを利用することにより購入管理用の有利な解決策を達成する。これらの動的承認パラメーターは構成可能な会社購入ポリシー及び規則の適用を通して発生及び／又は管理されることが出来て、そしてこれらの動的承認パラメーターは、例えば、該購入機構を使って取引が始動されるとオーソライゼーション決定を行う処理システムにより記憶される。広い種類の購入機構が使用され得るが、銀行又は他のカード発行者により発行される支払いカード（例えば、クレデイットカード、商業カード、コーポレートカード、フリートカード、スマートカード、ストアドバリューカード、調達カードそして購入又は”ピー”カード）は会社により初期に採用されるべき購入機構となりそうである。従来の支払いカードは典型的に、トータルシステムサービス社（Ｔｏｔａｌ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅｓ， Ｉｎｃ．）｛テーエスワイエス（ＴＳＹＳ）｝そして第１データ社（Ｆｉｒｓｔ Ｄａｔａ Ｃｏｒｐｏｒａｔｉｏｎ）のデビジョンである第１データ源（Ｆｉｒｓｔ Ｄａｔａ Ｒｅｓｏｕｃｅｓ）｛エフデーアール（ＦＤＲ）｝の様な、カードプロセサーを含む現在の支払いカード処理インフラストラクチャーに依存する。これらのテーエスワイエス及びエフデーアールの様なカードプロセサーは典型的に支払いカード制御設定を記憶し、これらのカード制御設定による支払いカードを使用して行われる取引を処理する。上記表１はこの様な制御設定の例を示す。本発明は従来のカードプロセサーにより記憶され利用されるこれらの支払いカード制御設定の動的管理を通して動的承認パラメーターを提供し管理出来る。この様な現在の支払いカードインフラストラクチャーに適用される様に、本発明は多数の重要な利点を提供するが、それらには支払いカード制御設定の動的管理、該カードプロセサーへのインターフエースを含む購入管理システム、そして該システムに入れられた購入要求又は他の購入ニーヅに基づき該制御設定を自動的に調整出来る購入管理システムが含まれる。
【００２８】
カードプロセサーにより従来式に記憶されたカード制御設定の動的管理に加えて、本発明により提供される該動的購入管理システムは更にこれらの従来の制御設定よりもローバストな承認パラメーターを考慮している。例えば、取引固有の承認パラメーターがカードプロセサーにより記憶され、そしてこれらの設定は又該購入管理システムにより動的に管理されることも出来る。これらのより詳細な動的支払い承認パラメーターは、例えば、承認パラメーターのセットが個人の購入要求と付随処理とにリンクされるように採用され、利用され得る。何等かの特定の購入要求用の動的承認パラメーターは、例えば、購入管理システム内のそれらの購入要求に会社購入ポリシーを適用した後作られることが出来る。次いで該購入管理システムは、該カード設定が該承認された購入要求に付随する取引のオーソライゼーションを可能にするために調整される必要があるかどうかを決定するために、これらの承認パラメーターを該支払いカード用にカードプロセサーにより記憶された制御設定と比較出来る。
【００２９】
現在の購入カードプログラムで利用可能な一般的、管理されないそして静的承認制限とは反対に、動的に管理された支払いカード制御設定又は購入要求にリンクされた他の動的承認パラメーターを利用することにより、本発明のシステムと方法は、購入要求が標準的会社購入ポリシー下でレビューされる安全を犠牲にすることなく、該購入が何処で行われるかに関係なく、会社購入の効率的管理と制御とを見越している。この有利な購入処理は、会社内のユーザー又は要素（例えば、人々、器具、車両、建物、又は何等かの他の望まれる人、場所又は物）からの購入要求に付随する動的承認パラメーターがこれらのユーザーにより企てられた特定の購入にリンクされるように、ユーザーを識別する機構を提供するために、動的支払いカードの様な動的支払い識別子（ｄｙｎａｎｍｉｃ ｐａｙｍｅｎｔ ｉｄｅｎｔｉｆｉｅｒｓ）を利用する。
【００３０】
上記で示した様に、従来の購入カードプログラムは、購入ニーヅに基づき動的に管理されないそしてそれに対し全ての取引が評価はされない１セットの静的規則を実施する。これらの静的規則を使用して、購入カードを利用する取引は、会社の静的な予め設定されたリスト内にあるサプライヤー又はその特定のカード用に予め設定された静的な財務パラメーターについて評価されチェックされるのが典型的である。購入カードは、購入が起こる前に要求がレビューされ、承認される従来の望ましい購入過程をサポートしない重要な欠点を有する。購入カードは、カード保持者が何等かの望まれる購入用に取引するのがその時自由な支出及びカードクレデイットリミットのカテゴリーを予め承認するためにカードプログラムアドミニストレーター（ｃａｒｄ ｐｒｏｇｒａｍ ａｄｍｉｎｉｓｔｒａｔｏｒｓ）を要する。会社は該個人的カード保持者よりも支払いに責任があるのが典型的なので、会社は購入カードの適切な使用を保証することを助ける力（ｌｅｖｅｒａｇｅ）を有しない。
【００３１】
何等かの与えられた時間に設定量のクレデイットを保持する従来のストアドバリューカードは、その量のクレデイットについてか又は該カードプログラムが始動された時規定された１つ以上に静的マーチャントでの使用についてか、何れかで等価の現金として使用される。一般にストアドバリューカードは、ストアドバリューカード上で利用可能なクレデイットがそれが空になるまで多数の取引に使用されてもよいことを意味するバルクのクレデイット手段（ｂｕｌｋ ｃｒｅｄｉｔ ｉｎｓｔｒｕｍｅｎｔｓ）として使用される。或るストアドバリューカードは、静的購入カード構成と同様に、多数のマーチャントがプログラム発端で構成されることを可能にする。しかしながら、ストアドバリューカードは、従来の購入カードに於ける様に、適当な安全防護と効率的購入管理用の制御を提供することに失敗している。
【００３２】
従来のカードプログラムと対照的に、本発明の該動的支払いカードは購入ニーヅに基づいて動的に管理される購入機構を反映する。動的支払いカードのプラットフオームを提供することにより、本発明は従来のクレデイットカード又は他の購入カードで利用可能でない能動的制御を有利に提供する。換言すれば、本発明の動的支払いカード購入は会社が、それらの購入の能動的制御をなお保持しながら、支払いカードをビジネス業務（ｂｕｓｉｎｅｓｓ ｏｐｅｒａｔｉｏｎ）の支出と調達を管理するための主要な機構として利用することを可能にする。従来の購入カードの静的承認モード（ｓｔａｔｉｃ ａｐｐｒｏｖａｌ ｍｏｄｅ）は大抵のビジネスの標準的購入承認過程を単純にはサポートせず、そこでは管理者（ｍａｎａｇｅｒｓ）は要求をレビューし、次いでこれらの特定の要求を購入用に承認する。多くの会社は現実の購入実行への制御の欠如のために彼等の支出（ｅｘｐｅｎｄｉｔｕｒｅ）の主要部用にこの様な従来の購入カードを使用したがらない。従って、この様な会社は共に購入カードの使用を制限するか又はそれらを避ける。かくして、会社支出の可成りの量は払い戻し又はチェックの要求手順（ｒｅｉｍｂｕｒｓｅｍｅｎｔ ｏｒ ｃｈｅｃｋ ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅｓ）の様な、他の機構を通して処理される。
【００３３】
ここで説明した様に、本発明の動的支払いカードプラットフオームは、従来の購入カードプログラムで利用可能なそれらを超える相当な管理及び承認能力を提供することによりこの状況を解決する。有利なことに、本発明では、購入要求のレビューは購入実行の前に起こり、該動的支払いカードが標準的会社購入過程を能動的にサポートすることを可能にする。次いで承認処理はローバストな例外取扱手順を見越し、望ましい承認経過（ａｐｐｒｏｖａｌ ｒｏｕｔｉｎｇ）用規則をトリガー（ｔｒｉｇｇｅｒ）する購入要求の使用を可能にする。そして、一旦承認されると、特定の購入要求用の承認の必要性は、承認と該ビジネスによるポリシー制御とをなお見越しながら、カード取引がクレデイットカード処理ネットワーク内で処理されるように、特定の動的支払いカードと結び付けられるか又はそれに付随させられてもよい。加えて、該動的支払いカード用の処理機構は現在のクレデイットカードネットワーク、例えば、ビザネットクレデイットカード処理ネットワーク（ＶｉｓａＮｅｔ ｃｒｅｄｉｔ ｃａｒｄ ｐｒｏｃｅｓｓｉｎｇ ｎｅｔｗｏｒｋ）及びトータルシステムサービス社（Ｔｏｔａｌ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅｓ， Ｉｎｃ．）｛テーエスワイエス（ＴＳＹＳ）｝カード処理インフラストラクチャーを利用してもよい。
【００３４】
ここでは、例示的実施例を提供する図面に関連して本発明が更に詳細に説明される。図１は動的支払いカード管理システム環境用のブロック線図例を提供する。図２及び４は動的支払いカード及び動的承認パラメーターを利用する取引の流れ線図例を提供する。図３は購入管理システムにより処理されるべき購入要求用の例示的源のブロック線図を提供する。図８Ａ−Ｄは購入管理用のブロック線図例を提供する。
【００３５】
図５Ａは現在のインフラストラクチャーに付随する支払いカード制御設定の動的管理に特に向けられた動的支払いカード管理システム環境用のブロック線図例を提供する。図５Ｂはこの様な環境で動的支払いカードを利用する取引用の流れ線図例を提供する。図６Ａ−Ｂ及び７Ａ−Ｂは取引例の追加的流れ線図を提供する。図９Ａ−Ｄは本発明により従来の支払いカードを動的に管理することに付随する処理例を更に説明するスイムレーン線図を提供する。図１０Ａ−Ｂは該支払いカードインフラストラクチャー内の種々のエイテイテイ間でのカードパラメーターの動的管理のために安全な通信を実現する安全代行環境用のブロック線図を提供する。
【００３６】
現在の支払いカード制御設定を動的承認パラメーターとして動的管理することは初期に実施された本発明の実施例となりそうであり、それは支払いカードが本発明に関して会社により初期に採用されるべき購入機構でありそうだからであることを述べておく。かくして、図１を論じた後、図１０Ａ−Ｂ、図９Ａ−Ｄそして図８Ａ−Ｄと一緒に図５Ａ−５Ｂを論じる。これらの図は現在の支払いカード制御設定の動的管理用への本発明の実施に特に向けられている。図２及び図４は次ぎに論じられる。これらの図は購入要求に基づいて適用される承認パラメーターにより一般的に向けられている。次いで図３が論じられる。最後に、一連の会社取引例が図６Ａ−Ｂ及び図７Ａ−Ｂの論議と共に提供される。
【００３７】
今図１を参照すると、本発明の購入管理を実現するために動的支払いカード処理システム１３０を利用する購入管理環境１５０用のブロック線図が描かれている。描かれる様に、該購入管理環境１５０は購入管理システム１００、動的支払いカード処理システム１３０，ベンダーシステム１４０，そしてクライアント１０４Ａ、１０４Ｂ．．．１０４Ｃを含む。該クライアント１０４Ａ、１０４Ｂ．．．１０４Ｃと該購入管理システム１００は、例えば、インターネットでもよいネットワーク１０２を通して相互に通信してもよい。クライアント１０４Ａ、１０４Ｂ．．．１０４Ｃと該購入管理システム１００はそれぞれ接続１１２Ａ、１１２Ｂ．．．１１２Ｃそして１１４を通してネットワーク１０２と接続される。これらの接続は、当業者により理解される様に、無線接続、ネットワークハブ（ｎｅｔｗｏｒｋ ｈｕｂｓ）、ルーター（ｒｏｕｔｅｒｓ）、インターネットサービスプロバイダー｛アイエスピーエス（ＩＳＰｓ）｝、ポータルコンピユータ（ｐｏｒｔａｌ ｃｏｍｐｕｔｏｒｓ）、又は接続性を提供する何等かのデバイス又はシステムを含むコンピユータシステムをネットワークに接続するための種々の機構の何れであってもよい。該ネットワーク１０２は、該ネットワーク１０２がクライアントと該購入管理システムの間の通信を究極的に許容するどんなデットワーク手段でもよいことを示すために雲形で表される。
【００３８】
クライアント１０４Ａ、１０４Ｂ．．．１０４Ｃは該購入管理システム１００を利用する会社又はエンテイテイを表す。これらの会社又はエンテイテイ内には、利用されてもよい種々のデバイスとシステム、例えば、パーソナルコンピユータ、サーバー、ハンドヘルドコンピユータ、ポータブルコンピユータ、パーソナルデジタルアシスタント又は利用されるべく望まれる何等かの他のデバイス又はシステムの何れがあってもよい。図１はサーバーベースのネットワークアクセス可能なシステムである購入管理システム１００を描いているが、本発明の動的承認パラメーター及び支払いカードはクライアントベースのシステム、サーバーベースのシステム、或いは両者の組合せと共に利用されてもよいことを述べておく。更に、該購入管理システム１００は望まれる購入管理機能を提供するために一緒に働くデバイスとシステムのどんな望まれるグループ化をも表すことを述べておく。
【００３９】
図１に示す様に、各クライアントは複数のユーザーを含む。例えば、クライアント１０４Ａはユーザー１０６Ａ、１０６Ｂ．．．１０６Ｃを含む。クライアント１０４Ｂははユーザー１０８Ａ、１０８Ｂ．．．１０８Ｃを含み、そしてクライアント１０４Ｃはユーザー１１０Ａ、１１０Ｂ．．．１１０Ｃを含む。これらのユーザーは該購入管理システム１００を利用する種々の従業員を表す。これらのユーザーは或る意味で、購入を要求するリクエスター、要求を承認する承認者そして該購入ポリシーと規則を管理するアドミニストレーター（ａｄｍｉｎｉｓｔｒａｔｏｒｓ）と考えられることが出来る。加えて、論理的組織が要素のグループを通して達成されることが出来て、そこではグループは部門、プロジェクト、建物、又は何等かの他の望まれる基準により組織され、要素は人、器具、車両、建物、又は何等かの他の望まれる人、場所又は物と考えられる。
【００４０】
各ユーザーは１つ以上の個人の動的支払いカードを有してもよい。加えて、動的支払いカードは１人以上のユーザーを有してもよく、組織内の或るグループによる使用のために指定されるか又は或る建物、器具、車両、他に付随させられてもよい。好ましくは、該動的支払いカードは、それらに付随するユニークな番号を有する従来の磁気的ストリップ（ｍａｇｎｅｔｉｃ−ｓｔｒｉｐ）クレデイットカード及び購入カードと同様である。これらのユニークな番号は該カードで始動される取引が識別されることを可能にする機構を提供する。しかしながら、ユニークな番号識別子を有し、磁気ストリップカードより他の、他の動的支払い識別子が利用されてもよいことを述べておく。例えば、社会保障番号（ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ）の様なユニークな番号が利用されてもよい。これらのユニークな番号は次いで簡単に該取引情報と一緒に送信される。更に、指紋の様な、生物学的又は生物測定的識別子（ｂｉｏｌｏｇｉｃａｌ ｏｒ ｂｉｏｍｅｔｒｉｃ ｉｄｅｎｔｉｆｉｅｒｓ）が利用されることも出来る。要するに、磁気ストリップクレデイットカード型機構を処理する現在のインフラストラクチャーがあるので、これらの種類の機構が現在好ましい。しかしながら、本発明に依れば、購入要求と付随する承認パラメーターとが始動された取引と相関されることを可能にするどんな動的支払い識別子が利用されてもよい。
【００４１】
購入管理システム１００は購入要求ブロック１１６、承認処理ブロック１１８，動的購入処理ブロック１２０，そして処理一致確認及び報告（ｔｒａｎｓａｃｔｉｏｎ ｒｅｃｏｃｉｌｉａｔｉｏｎ ａｎｄ ｒｅｐｏｒｔｉｎｇ）ブロック１２２を含む。購入要求ブロック１１６はクライアント１０４Ａ、１０４Ｂ．．．１０４Ｃ内のユーザー１０６Ａ、１０６Ｂ．．．１０６Ｃ、１０８Ａ、１０８Ｂ．．．１０８Ｃ、そしてユーザー１１０Ａ、１１０Ｂ．．．１１０Ｃによる購入要求の発生を見越す、該購入管理システム１００内のサブシステムを表す。承認処理ブロック１１８は該クライアント１０４Ａ、１０４Ｂ．．．１０４Ｃにより構成され、選択されるか又は他の仕方で置かれるポリシー及び規則を利用して購入要求の処理を見越すサブシステムを表す。該動的購入処理ブロック１２０は動的支払いカードを利用して購入要求を扱うサブシステムを表す。このブロックは動的支払いカード処理システム１３０と通信し、該取引一致確認及び報告ブロック１２２へ購入注文情報を提供する。このブロック１２２は承認された購入要求を該動的支払いカード処理システム１３０から受けた処理された取引情報と一致を確認し、次いで取引をクライアント１０４Ａ、１０４Ｂ．．．１０４Ｃへ報告するサブシステムである。この報告は種々のフオームのどれを取ってもよく、それらのクライアントが取引が如何に報告されることを望むかに基づいて種々のクライアント用に種々に構成されてもよい。
【００４２】
本発明の該購入管理システム１００は会社が相当な内部資源を支出しクライアントベースのシステム管理に割り当てる必要性を除去するネットワークアクセス可能な、サーバーベースのシステムであることが好ましい。サーバーベースの購入又は調達運営システムの例は、引用によりその全体でここに組み入れられる、”オンラインビジネス購入用の方法とシステム（Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｏｎｌｉｎｅ Ｂｕｓｉｎｅｓｓ Ｐｕｒｃｈａｓｉｎｇ）”の名称の同時係属中の米国特許出願直列番号第０９／４０９、３１６号で説明されている。購入を管理するために、この同時係属中の出願は、ユーザー及び／又は購入管理者に購入管理用に広い種類のネットワークアクセス可能で構成可能な制御を許容するように種々の誂え可能（ｃｕｓｔｏｍｉｚａｂｌｅ）な購入要求、ポリシーそして規則を開示している。これらの誂え可能な管理の特徴は自動購入承認、承認のキューを通しての手動購入承認、購入承認後の自動注文措置、そして購入後管理の特徴（ｐｏｓｔ−ｐｕｒｃｈａｓｅ ｍａｎａｇｅｍｅｎｔ ｆｅａｔｕｒｅｓ）を含む。
【００４３】
購入管理システム１００内の承認処理構成用のこれらのポリシーと規則は該会社の予期した及び／又は突然の又は予期せぬ購入承認ニーヅをカバーするために望まれる様に実施されることが出来る。例えば、経路（ｒｏｕｔｉｎｇ）及び／又は承認必要性（ａｐｐｒｏｖａｌ ｒｅｑｕｉｒｅｍｅｎｔｓ）に影響するよう規定され、構成される支出規則及びポリシー（ｓｐｅｎｄｉｎｇ ｒｕｌｅｓ ａｎｄ ｐｏｌｉｃｉｅｓ）は累積支出／予算ベースの規則（ｃｕｍｕｌａｔｉｖｅ ｓｐｅｎｄｉｎｇ／ｂｕｄｇｅｔ ｂａｓｅｄ ｒｕｌｅｓ）、ドル値規則（ｄｏｌｌａｒ ｖａｌｕｅ ｒｕｌｅｓ）、支出カテゴリー／費用種類規則（ｓｐｅｎｄ ｃａｔｅｇｏｒｙ／ｅｘｐｅｎｓｅ ｔｙｐｅ ｒｕｌｅ）、支払い種類／方法規則（ｐａｙｍｅｎｔ ｔｙｐｅ／ｍｅｔｈｏｄ ｒｕｌｅｓ）、サプライヤー又はサプライヤー種類規則、住所又は住所変更規則、出荷方法規則、そして配送要求のタイミング（ｔｉｍｉｎｇ ｏｆ ｄｅｌｉｖｅｒｙ ｒｅｑｕｉｒｅｍｅｎｔｓ）の様な特徴を含んでもよい。該累積支出／予算ベース規則は、要素（含む複数）及び／又はグループ（含む複数）が或る量のフアンド（ｆｕｎｄｓ）を割り当てられ、それらのフアンドの或るドル量又はパーセントが支出から予約されるか、既に支出されたか、又は支出されるべく残っている時に論理がトリガー（ｔｒｉｇｇｅｒｅｄ）される様な、１つ以上の規則を規定し構成することをユーザーに可能にするよう作られることが出来る。該ドル値規則はユーザーがドル値リミット（ｄｏｌｌａｒ ｖａｌｕｅ ｌｉｍｉｔｓ）、例えば、購入されるユニット当たり、ライン品目当たり、購入要求当たり、又は他の基準、のドル値リミット、を規定し構成することを可能にすることが出来る。該支出カテゴリー／費用種類規則は、例えば、ユーザーが、それに限定しないが、商品種類（ｃｏｍｍｏｄｉｔｙ ｔｙｐｅｓ）、サービス又はサービスの種類、資本財／プロジェクト（ｃａｐｉｔａｌ ｇｏｏｄｓ／ｐｒｏｊｅｃｔｓ）、プロジェクト、チェック要求（ｃｈｅｃｋ ｒｅｑｕｅｓｔ）、現金／キャッシュアドバンス（ｃａｓｈ／ｃａｓｈ ａｄｖａｂｃｅｓ）、出張及び接待（ｔｒａｖｅｌ ａｎｄ ｅｎｔｅｒｔａｉｎｍｅｎｔ）、他を含む広い種類のカテゴリー又は費用種類をカバーする規則を規定し構成することを可能にすることが出来る。該支払い種類／方法規則はユーザーが、該購入が如何に行われるか、例えば、期間、エイシーエイチ（ＡＣＨ）｛自動手形交換所（ａｕｔｏｍａｔｅｄ ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）｝、自動支払い、クレデイットカード、動的支払いカード、チェック、現金、他、に関する規則を規定し構成することを可能にすることが出来る。サプライヤー又はサプライヤーの種類規則はサプライヤーカテゴリーに基づくことが出来る。住所又は住所変更規則は出荷先、出荷元、請求、そして他の住所関連情報の様な項目を含むことが出来る。出荷方法及び配送タイミング規則は同様に、如何にそして何時製品が出荷され受領されるかに関する情報を含むことが出来る。加えて、購入管理システム上で動作するこの様な支出規則は、手動承認、自動承認、通知付き自動承認｛例えば、そこでは、要求は該支出規則論理を使用して自動的に承認されるが、１つ以上の要素及び／又はグループには承認の通知が受けられる理由（含む複数）を含む承認の通知が送られる｝、又は合理的ユーザーが望む何等かの他の種類のトリガー条件をトリガーするよう構成されてもよい。更に、該利用される支出規則は、グループ及び／又は要素固有の基礎に基づきそしてユーザーにより望まれる何等かの組み合わせでグループ（部門、プロジェクト、他）及び／又は要素（個人、車両、他）に適用されることが出来る。かくして、支出規則は、何等かの要素（含む複数）及び／又はグループ（含む複数）又は要素（含む複数）及び／又はグループ（含む複数）の何等かの組み合わせへ、個別にか又は何等かの組合せでか、何れかで適用されてもよい。
【００４４】
該動的支払いカード処理システム１３０は承認パラメーターデータベースブロック１３２と取引処理ブロック１３４を含む。該承認パラメーターデータベースブロック１３２は該動的購入処理ブロック１２０から送られる承認パラメーターを記憶するサブシステムを表す。これらの承認パラメーターは、例えば、各特定購入要求に関連して記憶されそして／又は管理され、従って、始動された取引に関して動的（ｄｙｎａｍｉｃ ｗｉｔｈ ｒｅｓｐｅｃｔ ｔｏ ｉｎｉｔｉａｔｅｄ ｔｒａｎｓａｃｔｉｏｎｓ）である。かくして、ユーザーが取引を始動すると、ベンダーシステム１４０は該取引処理ブロック１３４と通信する。もし該取引が該承認パラメーター外に外れるなら、該取引処理ブロック１３４は該取引を拒絶し、この拒絶について該ベンダーシステム１４０に通知する。もし該取引が該承認パラメーター内に入るなら、該取引処理ブロック１３４は該取引を承認し、この承認について該ベンダーシステム１４０に通知する。該取引ブロック１３４は次いで取引詳細を該取引一致確認及び報告ブロック（ｔｒａｎｓａｃｔｉｏｎ ｒｅｃｏｎｃｉｌｉａｔｉｏｎ ａｎｄ ｒｅｐｏｒｔｉｎｇ ｂｌｏｃｋ）１２２へ送る。該動的支払いカード処理システムは、承認された購入要求当たり１セットの承認パラメーターを動的に記憶又は管理する追加的能力を有するが、ビザネットクレデイットカード処理ネットワーク（ＶｉｓａＮｅｔ ｃｒｅｄｉｔ ｃａｒｄ ｐｒｏｃｅｓｓｉｎｇ ｎｅｔｗｏｒｋ）の様な現在のクレデイットカード取引システムと同様であってよいことを述べておく。上記に示す様に、従来の購入カード処理は何等かの与えられた購入カード用に１つの、静的なセットの制限を記憶するのみである。
【００４５】
各要求された取引用に詳細な承認パラメーターを記憶することにより、本発明は各取引用に動的で、取引ベースの事前承認システム（ａ ｄｙｎａｍｉｃ， ｔｒａｎｓａｃｔｉｏｎ−ｂａｓｅｄ ｐｒｅ−ａｐｐｒｏｖａｌ ｓｙｓｔｅｍ）を提供出来る。この仕方で、該動的な支払いカードを使用した各取引は、マーチャント（ｍｅｒｃｈａｎｔ）、取引量、時間枠又は何等かの他の望まれるパラメーターの様な、１セットの承認パラメーターにより動的に事前有効化（ｐｒｅ−ｖａｌｉｄａｔｅｄ）されてもよい。ここで開示した様に、本発明の該動的支払いカード及び承認パラメーターは購入される製品又はサービスに無関係に購入の制御と管理を見越している。かくして、本発明の購入管理システムは何等かの与えられた購入ニーヅの購入管理を見越している。購入要求が承認されると、該購入管理システムを操作するサーバーシステムはクレデイットカードネットワークのエイジャント（ａｇｅｎｔ）を通して取引を始動することが出来る。その取引は特定の動的支払いカード用の承認された費用をオーソライズ（ａｕｔｈｏｒｉｚｅ）出来る。一旦該クレデイットカードネットワークがその動的支払いカードに対する顧客取引を知ると、該購入管理システムは該取引が起こった該クレデイットカードネットワークのエイジャントにより通知される。次いで該購入管理システムは該顧客又はユーザーの会計システムとの次の一致確認用に該取引の詳細を記録する。もし、何等かの理由で、該動的支払いカードの保持者又はユーザーが該顧客により指定されたパラメーター設定（例えば、時間、購入価格、他）内で該購入取引を実行しないなら、該購入管理システムは、その特定の動的支払いカードに対する取引オーソライゼーションを取り消すために該同じクレデイットカードネットワークエイジャントを使用してもよい。
【００４６】
ブロック１２４、１２６そして１２８は本発明の動的支払いカードの使用に関する追加的過程流れ経路（ａｄｄｉｔｉｏｎａｌ ｐｒｏｃｅｓｓ ｆｌｏｗ ｐａｔｈ）を提供する。ブロック１２４は予め設定された動的支払いカードアロワンス（ａｌｌｏｗａｎｃｅ）を表し、該アロワンスは何れの与えられた動的支払いカード用にもセットアップされるよう望まれる。これらの予め設定されたアロワンスに付随するパラメーターは該購入管理システム１００内で管理され、次いで該購入管理システム１００により該カード処理システム１３０へ提供され該承認パラメーターデータベース１３２内に記憶される。これらのパラメーターはカード保持者が、該購入管理システム１００を通して承認された購入要求を最初に発生する必要無しに事前承認された支出オーソリテイ（ｓｐｅｎｄｉｎｇ ａｕｔｈｏｒｉｔｙ）を持つことを可能にする。該取引処理ブロック１３４がこの様な予め承認された支出オーソリテイを使用して行われた購入に関する取引データを該取引一致確認及び報告ブロック１２２へ提供すると、もし望ましいなら、該取引に付随する購入要求は該取引データから合成されてもよい。この要求合成はブロック１２８により表される。加えて、ブロック１２６に関しては、該カードユーザーはユーザー弁明又は他の情報を提供する機会を与えられてもよく、そしてもし望ましいなら、該弁明された又は弁明されない合成された購入要求が承認処理に提出されてもよい。図５Ａ−Ｂ、６Ａ−Ｂそして７Ａ−Ｂに関連してより完全に論じられる様に、ブロック１２６と１２４を有する図１の実施例でスタートする経路は承認処理順方向流れ（ｆｏｒｗａｒｄ ｆｌｏｗ ａｐｐｒｏｖａｌ ｐｒｏｃｅｓｓｉｎｇ）と承認処理の逆方向流れ（ｒｅｖｅｒｓｅ ｆｌｏｗ ａｐｐｒｏｖａｌ ｐｒｏｃｅｓｓｉｎｇ）とを見越す処理経路例を提供する。
【００４７】
上記で、そして下記でより詳細に論じる様に、本発明は該動的承認パラメーターを提供するためにカードプロセサーにより記憶される支払いカード制御設定を動的に管理するよう適用されることが出来る。制御設定のこの動的管理は会社がカード処理スペシャリストを雇う必要無く会社購入ポリシーに基づくことが出来る。換言すれば、本発明の動的支払いカードシステムは、会社承認ポリシーが自動的にそして動的に管理され得るように、該カード処理インフラストラクチャーとの適当なインターフエースを提供する。この実施例では、従って、該動的支払いカード処理システム１３０はテーエスワイエス（ＴＳＹＳ）の様な標準支払いカードプロセサーであってもよく、そして該カード処理システム１３０のデータベース１３２内に記憶された動的承認パラメーターは、本発明の購入管理｛ピーエム（ＰＭ）｝システム１００を通して動的に管理される標準的支払いカード制御設定とすることが出来る。
【００４８】
今図５Ａを詳細に見ると、現在のカード処理インフラストラクチャーを利用出来る、本発明の動的支払いカード管理環境５００用のブロック線図が提供される。該動的支払いカードの使用を始動するために、会社１０４は典型的に、例えば、下記過程を通して進行してもよく、すなわち：（１）クレデイットを確立し、（２）例えば、銀行又は他のカード発行者を通して、カードプロセサーを用いて初期のカードセットアップを達成し、（３）カード保持者と付随ユーザー職務を決定し、そして（４）何等かの望ましいレベルの予め承認された支出用オーソリテイを有するカード設定を選択する。図５Ａに示す実施例では、会社１０４はカード発行者又は銀行５０２と相互作用５０４を通したクレデイット関係を確立する。次いで相互作用５１４を通して、該カード発行者は該カード処理システム１３０で各ユーザー１０６Ａ、１０６Ｂ．．．１０６Ｃ用に初期カード設定をセットアップしてもよい。もし望ましいならば、このカードセットアップは又該購入管理システム１００により達成されてもよい。例えば、該カード発行者又は銀行５０２は該会社１０４用の利用可能なレベルのクレデイットを提供してもよく、次いで該会社１０４はカードの数と該会社が望むカード用の設定とを決めてもよい。
【００４９】
相互作用５１０を通して、該会社１０４は該購入管理｛ピーエム（ＰＭ）｝システム１００とインターフエースする。上記で論じた様に、これらの相互作用５１０は該会社１０４が該ピーエムシステム１００内で購入ポリシーと付随する承認処理規則を規定することを可能にする。加えて、該相互作用５１０は該ユーザー職務とカード設定が選択され管理されることを可能にする。又、ユーザー１０６Ａ、１０６Ｂ．．．１０６Ｃが購入要求を行うことが出来て、これらの要求が処理されることが出来て、そして承認応答が提供されることが出来るのはこれらの相互作用５１０を通してである。これらの規則、職務そして承認処理に基づき、該ピーエムシステム１００は、相互作用５１２を通して該会社支払いカード用設定を動的に管理するために該カード処理システム１３０とインターフエースする。これらの動的な支払いカードは次いで改良された購入管理を見越している。ベンダー１４０は何等かの与えられ始動された取引用のオーソライゼーションコードを得るために該カード処理システム１３０に頼る。このオードライゼーション相互作用は、ビザネット（ＶｉｓａＮｅｔ）インターフエースネットワークの様な、中間的取引ネットワーク５１５を通して起こる相互作用５１６と５１８を含んでもよい。
【００５０】
図５Ｂは本発明の購入カード管理環境用の処理流れ例５５０用のブロック線図を提供する。それは２つの異なる経路を示すがそれらを通して動的支払いカードが管理され、利用されることが出来る。示された例では、処理流れ５５０は承認処理経路順方向流れ５５４と承認処理経路逆方向流れ５５６とを含み、両経路は如何にユーザー５５２が該動的支払いカードを使うかに依り利用される。これらの２つの経路は例として描かれており、本発明の動的支払いカードを使用して実施出来る処理経路の全てであると取られるべきでないことを述べておく。
【００５１】
もし該動的支払いカードがそれに付随した予め承認された支出用オーソリテイを有するならば、該ユーザーは該承認処理経路逆方向流れ５５６を始めるためにライン５６４を下るよう進んでもよい。ブロック５６６は該ユーザー５５２により使用されつつある該動的支払いカード用にセットアップされた予め設定された支出アロワンスを表す。次いでユーザー５５２はブロック５６８で購入を行うために該カードを使用し、該ブロック５６８ではカード処理が起こり、もし該カード用承認パラメーターが満足されれば、該取引をオーソライズする。該購入についての該カードプロセサー１３０から入手可能な情報に基づいて、該ピーエムシステム１００はブロック５７０で該購入に付随する購入要求を取引後（ｐｏｓｔ−ｔｒａｎｓａｃｔｉｏｎ）に合成（ｓｙｎｔｈｅｓｉｚｅ）出来る。ブロック５７２で、該ピーエムシステム１００は該ユーザー５５２が、ブロック５６８で行われた購入用の、取引詳細、会計的又は総勘定元帳（ｇｅｎｅｒａｌ ｌｅｄｇｅｒ）｛ジーエル（ＧＬ）｝コーデイング、弁明又は何等かの他の望まれる又は要求される情報の様な、追加的取引情報を提供可能にし、そして、もし望まれるならば、例えば、該会社の承認処理規則を通して、該購入の取引後処理（ｐｏｓｔ−ｔｒａｎｓａｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ）を提供する。かくして、この要求合成（ｒｅｑｕｅｓｔ ｓｙｎｔｈｅｓｉｓ）は、該会社の購入承認ガイドライン及び購入一致確認に基づいて取引後承認用に該ピーエムシステム１００内へ戻り入力されるように、予め承認された支出オーソリテイを使って行われる購入を可能にする利点がある。もし該ユーザー５５２が予め承認された支出オーソリテイを有するカードを持たずに該逆方向流れ経路５５６を下方へ進むなら、該取引はブロック５６８で該カードプロセサーによりオーソライズされないであろう。
【００５２】
この購入要求合成は有利なことに、もし望むならば、一般的な予め許可されたカード束縛下で行われた購入が該購入管理システムによる取引後処理及び報告と取引後承認経路に供されることを可能にする。下記例に関し議論される様に、動的支払いカードは、該ユーザーに最初に購入要求承認過程を通過することを要求することなく、或るレベルの承認済み支出オーソリテイを有してセットアップされてもよい。もしユーザーがこの様な予め許可された支出用オーソリテイを使用して取引を行うなら、その購入は典型的に、購入要求、又はそれに付随する購入注文を有しない。該カード処理システム１３０から提供されたデータを使って、該購入管理システム１００は購入要求及び／又はその取引用購入注文を合成出来る。この合成された購入要求／注文は、望まれるならば、該取引が購入要求／注文に対し一致確認され得るように会社の会計システムにより使用されることが出来る。この仕方で、広範な種類の有利な合成情報（ｓｙｎｔｈｅｓｉｚｅｄ ｉｎｆｏｒｍａｔｉｏｎ）がそれらの追跡、会計処理、又は他の目的で会社へ提供される。例えば、該合成購入要求は該取引についてのユーザー弁明を要求する際に、及びもし望むなら、取引後処理で使用出来る。そして会社はユーザーに予め設定されたカードアロワンスを使用して行われた取引が承認されずそれにより該ユーザーによる該会社への払い戻しを要するか否かを知らせることが出来る。
【００５３】
又該ユーザー５５２は承認処理経路順方向流れ５５４を始めるためにライン５５８を下って進めてもよい。ブロック５５９で、ユーザー５５２は該ピーエムシステム１００内の購入要求を始動し、該要求は上記で論じた事前取引承認処理へ供せられる。承認が与えられると仮定して、その時該ピーエムシステム１００はブロック５６０で該カード設定を自動的にかつ動的に管理するが、これらの設定は該購入がユーザー５５２により始動された時該取引がオーソライズされることを可能にするような設定になっている。このタスクを達成するために、図５Ａの実施例に関して説明した様に、該ピーエムシステム１００は該カード処理システム１３０とインターフエースし、設定が該承認された購入要求の対象である該取引を許可するように、該カードの承認パラメーター用の現在の設定を決定しそしてそれらの設定を創るか又は修正する。ブロック５６２で、ユーザー５２２は購入を行い、該購入はもしそれが該カード設定と承認パラメーターにより許可されればオーソライズされる。図９ＡーＤに関連して詳細に論じる様に、会社のカードの概要取引情報が一致確認活動で該ピーエムシステム１００により使用されるために該カードプロセサーから周期的に受信されてもよい。
【００５４】
戻って今度は図５Ａを見ると、該カード処理システム１３０は、例えば、トータルシステムサービス社（Ｔｏｔａｌ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅｓ， Ｉｎｃ．）｛テーエスワイエス（ＴＳＹＳ）｝により提供されるカード処理システムの様な第３者のカードプロセサーにより実施されてもよい。該テーエスワイエスプラットフオームは、例えば、上記表１にリスト化された特徴を含み、購入カード用に設定される種々の特徴を提供する。該テーエスワイエスプラットフオームインターフエースは、該テーエスワエスカード処理システム内に記憶されたカード記録への挿入、削除、修正そして他のコマンドをもたらす或る通信を探し求める。
【００５５】
該購入管理システム１００からテーエスワイエス処理システムの様な該カード処理システム１３０への情報の転送をもたらすために、安全な伝言転送プロトコルが利用されてもよい。例えば、アイビーエム（ＩＢＭ）は、取引環境で伝言の保証された配送を提供することにより安全なイーコマース（ｅ−ｃｏｍｍｅｒｃｅ）と電子的伝言を実現する製品のエムキューシリーズフアミリー（ＭＱＳｅｒｉｅｓ Ｆａｍｉｌｙ ｏｆ ｐｒｏｄｕｃｔｓ）を提供する。この様な伝言インターフエースを使って、カード管理とカード設定情報は該購入管理システム１００から該カード処理システム１３０への間で送られ得る。例えば、テーエスワイエスは、ベロシテイ（ｖｅｌｏｃｉｔｙ）、エムシーシー（ＭＣＣ）グループそしてクレデイットリミットの様な、特定カード設定への修正を見越すインターフエースコマンドを提供する。これらのコマンドに含まれる指示（ｉｎｓｔｒｕｃｔｉｏｎｓ）は次いで該テーエスワイエス取引システム内に供給され、該購入管理システム１００へ戻る、該要求された設定が実施されたと言う、確認応答に帰着する。
【００５６】
図１０Ａは本発明の動的支払いカード管理システム内の安全な通信と過程分離（ｐｒｏｃｅｓｓ ｉｓｏｌａｔｉｏｎ）を実現するための通信システム１０００用ブロック線図を提供する。描かれた実施例では、動的支払いカード｛デーピーシー（ＤＰＣ）｝安全代行者１００４は該通信システム１０００内の種々のエンテイテイ間の過程分離を提供し、購入管理応用品（ｐｕｒｃｈａｓｉｎｇ ｍａｎａｇｅｍｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）１００、銀行又はカード発行者５０２そしてこの実施例でテーエスワイエスとして表現されるカードプロセサー１３０の間の通信用の安全な通信インターフエースを提供する。又該安全代行者１００４は、例えば、該購入管理システム１００が悪意のある又は犯罪的エンテイテイにより危うくされたかどうか決定することを助けることが出来る詐欺検出機構の様な、他の安全機構を提供出来る。該テーエスワイエスネットワーク１３０には、エイスバッチプロセサー（ＡＣＥ ｂａｔｃｈ ｐｒｏｃｅｓｓｏｒ）１０１０，デーイーエフ発生器（ＤＥＦ ｇｅｎｅｒａｔｏｒ）１０１４そして、例えば、該テーエスワイエスの補助的なドットコネクト（ＤｏｔｓＣｏｎｎｅｃｔ）により主催され得るエムキューサーバー（ＭＱ Ｓｅｒｖｅｒ）インターフエース１０１２が付随する。該安全代行者１００４には、暗号化されたメールボックス１００６及び１０１６、ロギング及び安全データベース１０１８そしてクレデイットカード（シーシー）番号地下金庫室｛ｃｒｅｄｉｔ ｃａｒｄ（ＣＣ）ｎｕｍｂｅｒ ｖａｕｌｔ｝１０２０が付随する。該シーシー地下金庫室１０２０はは実際のクレデイットカード番号を貯蔵し、それらの番号用の安全を提供する。もし改善された安全用に望むなら、該クレデイットカード番号自体を使うことよりむしろ、該ピーエムシステム１００は該実際のクレデイットカード番号と相関する別の番号又は識別子を使うことが出来る。かくして、実際のクレデイットカード番号の通信のみが該安全代行者１００４，該銀行５０４及び／又は該テーエスワイエスネットワーク１３０間で起こる。
【００５７】
該ピーエムシステム１００と該安全代行者１００４間の通信は、例えば、仮想の私的ネットワーク｛ブイピーエヌ（ＶＰＮ）｝又はローカルネットワーク接続であってもよい経路１０２２に沿って起こり得る。ここで論じる様に、この経路１０２２を通して通信され得る情報例は動的支払いカード又は能動的クレデイットカード｛エイシーシー（ＡＣＣ）｝取引、カードクレデイットリミット、支出リミット（ｓｐｅｎｄｉｎｇ ｌｉｍｉｔｓ）そしてベロシテイ設定、エムシーシーカテゴリーロックアウト情報、活動報告、カード発行情報、カード取り消し情報そして何等かの他の望まれる情報を含む。該安全代行者１００４から銀行５０２への通信は経路１０２６と１０２８に沿って起こり得る。該経路１０２６と１０２８は、例えば、付加価値ネットワーク｛ブイエイエヌ（ＶＡＮ）｝を通してそして暗号化されたメールボックス１００６を通して通信されるエースフアイル（ＡＣＥ ｆｉｌｅ）を表してもよい。該安全代行者１００４と該エムキューサーバー１０１２間の通信は例えば、ブイピーエヌ上で通信されるエムキューパケットを表す経路１０２４に沿って起こることも出来る。銀行５０２とテーエスワイエスネットワーク１３０の間の通信は例えば、エースバッチプロセサー１０１０への現在のエフテーリンク（ＦＴ ｌｉｎｋ）を表す経路１０３０に沿って起こることが出来る。該テーエスワイエスネットワーク１３０と安全代行者１００４の間の通信は経路１０３２と１０３４に沿って起こることが出来る。該経路１０３２と１０３４は例えば、デーイーエフ発生器１０１４からブイエイエヌを通りそして暗号化メールボックス１０１６を通り通信されるデーイーエフ情報を表してもよい。経路１０２６，１０２８，１０３０，１０３２そして１０３４の様なこれらの経路の幾つかは１方向での通信流れを示す矢印を有するが、もし望むなら、逆方向でも同様に通信が起こり得ることを述べておく。かくして、図１０Ａに描かれた通信システムでは、該安全代行者１００４は安全機構を提供出来て、該システム内の種々のエンテイテイ間の過程分離を提供出来て、そして該システム内の種々のエンテイテイ間の通信の安全な送信を実現出来る中間システムを提供する。加えて、この安全代行者１００４は該システム内の種々のエンテイテイにより認識されるフオーマットで情報を受送信出来て、それにより該種々のエンテイテイにより利用される本質的に異なる（ｄｉｓｐａｒａｔｅ）通信プロトコル又はフオーマット間の翻訳又は変換を提供する。
【００５８】
これらのインターフエースは、購入管理応用品１００，テーエスワイエスイネーブルド（ＴＳＹＳ−ｅｎａｂｌｅｄ）銀行５０２そしてテーエスワイエスが該カードプロセサーであるテーエスワイエスカード処理ネットワーク１３０の間の安全通信チャンネル例を提供する。該購入管理応用品１００と銀行５０２の間の該接続は、例えば、カード発行過程用に使用されてもよい。該購入管理応用品１００と該エムキューサーバー１０１２そして該テーエスワイエスカード処理ネットワーク１３０の間の接続は、例えば、実時間での、動的なカード保守とカード制御設定の管理とのために使用されてもよい。加えて、該テーエスワイエスネットワーク１３０と該購入管理応用品１００との間の該接続は、例えば、カード取引情報の送信用に使用されてもよい。
【００５９】
上記で論じた様に、該ピーエム応用品１００は１セットの保守伝言を使用して、例えば、該テーエスワイエスネットワーク１３０によりサポートされる実時間のカード制御プロトコルを使用して、支払いカード制御設定を管理出来る。上記で示した様に、このテーエスワイエスカード制御プロトコルは送信者にカードの種々のプロパテイを変更することを可能にする１セットのエムキューシリーズ伝言（ＭＱＳｅｒｉｅｓ ｍｅｓｓａｇｅｓ）を利用する。安全を改善し該カードプロセサーネットワーク１３０の保護を助けるために、該購入管理応用品１００は該カードプロセサーネットワーク１３０への直接アクセスを持つことから制限され得る。代わりに、図１０Ａに示す様に、該ピーエム応用品１００は正しくフオーマットされたエムキューシリーズ伝言を、別のエンテイテイにより、例えば、テーエスワイエスがカードプロセサーである該テーエスワイエスの補助的なドットコネクト（ＤｏｔｓＣｏｎｎｅｃｔ）により、ホストとされる信頼されたエムキューサーバー１０１２へ送ることが出来る。この間接的接続は該テーエスワイエスカード処理ネットワーク１３０を安全問題へ曝すのを制限することを助ける。又図１０Ａに示す様に、該ピーエム応用品１００用の追加的安全を提供するために、全支払いカードアクセス及び制御サービスが安全代行品１００４内に作られ得て、それによりこれらの制御設定操作機構を該ピーエム応用品１００自身から分離する。この分離はカードアクセスソフトウエアコードと関連過程の安全と監査（ａｕｄｉｔｉｎｇ）を保証することを助けそして銀行固有の又はプロセサー固有のソフトウエアコードが該ピーエム応用品１００内で絡み合うことを防止する。該主なピーエム応用品１００は次いでネットワーク準備済みプロトコルにより該安全代行品１００４から分離されるが、該プロトコルは該カードプロセサー１３０及び／又は該銀行又はカード発行者５０２から独立したカード制御サービスへの厳密で、よく文書化されたアクセスを保持することを助ける。該ピーエム応用品１００と該カードアクセス安全代行者１００４のこの分離は又、もし望むなら、該安全代行者１００４を物理的にそして地理的に分離したサーバーシステムとして確立する能力を提供する。
【００６０】
代わりに、該ピーエム応用品１００と該安全代行者１００４は１つのサーバーシステムと付随ソフトウエアコードとして実施されることも出来ることを述べておく。加えて、もし該ピーエム応用品、銀行５０２そしてカードプロセサー１３０の間の直接通信が望まれるなら、該安全代行者１００４は除去されることが出来る。しかしながら、悪意のエンテイテイが通信又はシステム動作を妨害又は悪く影響しないことを保証するために何等かの安全手順が望ましそうである。加えて、該安全代行者１００４により提供される機能は、この機能の１部をピーエムシステム１００内にそしてその１部を銀行５０２内にそして１部を該カードプロセサー１３０内又は該追加的中間インターフエース１０１２内に置く様に、該システム内の種々のエンテイテイ間に分割され得る。更に、該安全代行者１００４用の他の実施品が、望ましい様に、利用されることも出来ることを述べておく。
【００６１】
又カードセットアップと発行は該安全代行者１００４を通して行われることも出来る。一旦銀行５０２が新しいカードプログラム用にマスター勘定記録をセットアップすると、該カードプロセサー１３０は、現在の手順下で典型的にその場合である様に、該プログラム用のカードを発行する詳細を取り扱うことが出来る。カード又は複数カードを発行するために、該銀行は該カードプロセサー１３０へ自動化された要求を行う。次いで該カードプロセサー１３０は勘定番号を割り当て、物理的な支払いカードの創生をトリガーする。例えば、該カードプロセサー１３０としてのテーエスワイエスに関して、該銀行５０２及び何等かの他のテーエスワイエスメンバー銀行は、新カードの発行を始動するためにエイス（ＡＣＥ）と呼ばれるバッチモードシステム（ｂａｔｃｈ−ｍｏｄｅ ｓｙｓｔｅｍ）を使うのが典型的である。該エイスシステムでは、銀行５０２は、通信を有効化するためにフアイル転送プログラムを使用するフアイル転送｛エフテー（ＦＴ）｝リンク１０３０の様な、直接的リンクを通して特別にフオーマットされたフラットフアイル（ｆｌａｔ ｆｉｌｅ）を該テーエスワイエスカードプロセサー１３０へ送信する。該通信されたエイスフアイルはカード保持者を該カードプログラムに追加するためにテーエスワイエスにより使用される情報を含んでいる。図１０Ａに示す様に、カード保持者を該プログラムに追加するためにエイスフアイルを創り、送るこのタスクは、もし望むなら、該ピーエム応用品１００及び／又は該安全代行者１００４の動作内に含めることが出来る。この仕方で、該ピーエム応用品１００を使用する会社が該ピーエム応用品１００内で新カードの発行の希望を示すと、エイスフオーマットのフアイルが該ピーエム応用品１００又は該安全代行者１００４により自動的に発生され得る。このエイスフオーマットのフアイルは経路１０２６及び１０２８で表されるブイエイエヌを通しそして暗号化されたメールボックス１００６を通して該銀行５０２へ送信出来る。この様であるから、該エイスバッチプロセサー１０１０により利用される該エイスプロトコルをサポートする現在のエフテーリンク１０３０が利用されることが出来る。もし望むなら、そして適当な通信経路が作られるなら、該ピーエム応用品１００及び／又は該安全代行者１００４はこのエイスフオーマットフアイルを該エイスバッチプロセサー１０１０へ直接通信出来る。一旦新カードが該カードプロセサー１３０により該カードプログラムに追加されると、カード賦活が、該カード保持者が、該カードを賦活するために該カードの裏に置かれた電話番号をコールする様な、従来の手順を通して行われるか、又は該ピーエム応用品１００が自動賦活手順を提供出来る。もし後者が利用されるなら、該カードプロセサー１３０も又、例えば、該安全代行者１００４との通信を通して、この様な自動化された賦活を受け入れるよう修正される。望まれる様に、カードセットアップ及び初期化用の種々の手順が使用出来ることそして上記の議論が該カードプロセサーとしてのテーエスワイエスに関連した唯の１例であることを述べておく。
【００６２】
上記で論じたカード取引の後端の一致確認（ｂａｃｋ−ｅｎｄ ｒｅｃｏｎｃｉｌｉａｔｉｏｎ）をサポートするために、該ピーエム応用品１００は、最終更新以来に起こったカード取引に関する情報を含む周期的更新録（ｐｅｒｉｏｄｉｃ ｕｐｄａｔｅｓ）（例えば、毎月、毎夜、毎時、他）を利用出来る。又これらの取引更新録は、該取引の完了又はオーソライゼーションと同時に送信そして受信された実時間の又は瞬時の更新録であり得ることを述べておく。加えて、これらの更新録は該カードプロセサーによりそして／又は該ピーエム応用品１００の要求で自動的に送られ得る。テーエスワイエスにより使用されるそれらの様な、現在のカード処理手順下では、銀行５０２は２種類の取引データフアイルを受けるのが典型的である。第１は該テーエスワイエスネットワーク１３０が銀行５０２へ毎晩送るデータ交換フアイル（Ｄａｔａ Ｅｘｃｈａｎｇｅ Ｆｉｌｅ）｛デーイーエフ（ＤＥＦ）｝と呼ばれる。前記デーイーエフフアイルは勘定変化とカード取引データとを含む、データを報告する広い配列である。該第２取引データフアイルは毎月テーエスワイエスにより送られ、請求ステートメントを準備するための決算情報（ｓｅｔｔｌｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）を含む。図１０Ａで示す様に、これらの２つのフアイルは、例えば、該デーイーエフ発生器１０１４及び該安全代行者１００４を通して、該ピーエム応用品１００へ送られ得る。該毎晩のデーイーエフフアイルは、上記で論じた様に、一致確認活動用及びカード制御設定の動的管理用、に使用出来る。該毎月の決算データは、例えば、マーチャントによりリフアンド（ｒｅｆｕｎｄｅｄ）されたクレデイットの様な、潜在的活動（ｌａｔｅｎｔ ａｃｔｉｖｉｔｉｅｓ）用に、支払いカード勘定情報の一致確認を完了するために使用出来る。
【００６３】
該現在のテーエスワイエス過程では、テーエスワイエスイネーブルドの銀行５０２は該テーエスワイエスネットワークから毎晩該デーイーエフフアイルを受信する。次いで、該銀行５０２は該フアイルを処理し、データを、今度は該銀行の顧客に面するインタネット応用品（ｃｕｓｔｏｍｅｒ−ｆａｃｉｎｇ Ｉｎｔｅｒｎｅｔ ａｐｐｌｉｃａｔｉｏｎｓ）により使用される１セットのリレーショナルデータベース表（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ ｔａｂｌｅｓ）内へ抽出する。この銀行処理とのピーエム応用品１００のインターフエースを持つことよりむしろ、該銀行５０２は、該テーエスワイエスネットワーク１３０から分離されたデーイーエフが、図１０Ａで示す様に、例えば、経路１０３２及び１０３４により表されるブイエイエヌを通してそして暗号化されたメールボックス１０１６を通して、該ピーエム応用品１００へ直接配送されることを要求出来る。加えて、この分離されたデーイーエフフアイルは、各々が会社又は会社の集合に固有な、多数のデーイーエフフイルとして送られ得る。銀行へ送られる従来のデーイーエフフアイルは、それがビジネスをする全ての会社と個人用の該銀行のカードプログラムと勘定の全てに関する情報を含むのが典型的である。追加的安全用に、該カードプロセサー固有のデータフアイルは、次いで該カード取引データの或る修正された又は抄録された版を該ピーエム応用品１００へ送る、該安全代行者１００４によってのみ操作され得る。次いでこの過程は、詳細勘定情報の様な、機密的情報が該主ピーエム応用品１００内へ洩れることを防止するために安全境界を提供する。再び、上記で述べた様に、安全代行者１００４を提供する別システムを有する図１０Ａのこの実施例は、もし望まれれば、該ピーエム応用品１００，カード発行者５０２及び／又は該カードプロセサー１３０、それら自身の動作の中に該安全機構を組み入れるように変型出来る。
【００６４】
図１０Ｂは図１０Ａに関して描かれたものより一般的な通信システム１０５０用のブロック線図を提供する。この通信システム１０５０は安全な通信と、１つ以上の購入管理システム１００Ａ、１００Ｂ．．．１００Ｃ、１つ以上のカード発行者５０２Ａ、５０２Ｂ．．．５０２Ｃ、１つ以上のカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃ、そして１つ以上の安全代行者システム１００４Ａ、１００４Ｂ．．．１００４Ｃの間の過程分離と、を実現するための安全代行者環境を提供する。図１０Ａからの要素番号は図１０Ａの要素の図１０Ｂのそれらとの一般的相関を表すために図１０Ｂで繰り返されたことを述べておく。
【００６５】
図１０Ａに於ける様に、該１つ以上の安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは、それらに付随する種々の共有型又は分離型データベース、例えば、取引ログ情報を貯蔵するデータベース１０１８及びクレデイットカード（シーシー）地下金庫室を提供するデータベース１０２０を有する。上記で述べた様に、該クレデイットカード地下金庫室は、もし利用されるならば、クレデイットカード番号を該アーキテクチャー内の他のエンテイテイから分離することにより安全機構を提供出来る。これらのデータベースの組織と追加的又は種々のデータベースの使用は該安全代行者環境を実施するために選ばれたアーキテクチャーに依存しそうであろうことを述べておく。
【００６６】
該１つ以上の購入管理応用品１００Ａ、１００Ｂ．．．１００Ｃは通信経路１０２２を通して該１つ以上のカード制御安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃと通信出来る。例えば、通信経路１０２２は、クレデイットカードリミット、支出リミット、ベロシテイ設定、エムシーシーカテゴリー制御及びロックアウト（ＭＣＣ ｃａｔｅｇｏｒｙ ｃｏｎｔｒｏｌｓ ａｎｄ ｌｏｃｋｏｕｔｓ）、クレデイットカード活動報告（ｃｒｅｄｉｔ ｃａｒｄ ａｃｔｉｖｉｔｙ ｒｅｐｏｒｔｓ）、カード発行要求及び情報、カード取り消し要求及び情報、又は他の望まれる情報の様な情報の転送を提供出来る。１つ以上のカード制御安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは通信経路１０２６／１０２８を通して該１つ以上のカード発行者５０２Ａ、５０２Ｂ．．．５０２Ｃと通信出来る。例えば、通信経路１０２６／１０２８はカード発行要求及び関連情報の様な情報の転送を提供出来る。１つ以上のカード制御安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは通信経路１０２４と１０３２／１０３４を通して該１つ以上のカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃと通信出来る。例えば、通信経路１０２４はクレデイットカードパラメーター制御情報の様な情報の転送を提供出来る。そして通信経路１０３２／１０３４は勘定活動報告（ａｃｃｏｕｎｔ ａｃｔｉｖｉｔｙ ｒｅｐｏｒｔｓ）の様な情報の転送を提供出来る。該１つ以上のカード発行者５０２Ａ、５０２Ｂ．．．５０２Ｃは通信経路１０３０を通して該１つ以上のカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃと通信出来る。例えば、該通信経路１０３０は勘定セットアップ情報の様な情報の転送を提供出来る。該１つ以上のカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃは通信経路１０５２を通してマーチャント又はベンダーと通信出来る。例えば、通信経路１０５２は、１つ以上のカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃが記憶されたカードパラメーターに基づき企てられた取引をオーソライズ又は拒絶するため使用出来るクレデイットカード取引情報の転送を提供出来る。かくして、図１０Ａに描かれた該安全代行者１００４と同様に、図１０Ｂの該安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは、安全機構を提供出来て、該システム内の種々のエンテイテイ間の過程分離を提供出来て、そして該システム内の種々のエンテイテイ間の通信の安全な送信を実現出来る中間システムを提供する。加えて、これらの安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは、該システム内の該種々のエンテイテイにより認識されるフオーマットでの情報を受送信出来て、それにより該種々のエンテイテイにより利用される本質的に異なる通信プロトコル又はフオーマット間の翻訳又は変換を提供する。
【００６７】
該カード制御安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは、、それらにより受信されそしてそれらへ送信される通信に関する安全機構を含む、１つ以上の安全機構を提供する。これらの安全機構は、例えば、安全なメールボックス、安全な通信プロトコル、公開／秘密鍵暗号方式（ｐｕｂｌｉｃ／ｐｒｉｖａｔｅ ｋｅｙ ｅｎｃｒｙｐｔｉｏｎ）又は他のデジタル署名手順（ｄｅｇｉｔａｌ ｓｉｇｎａｔｕｒｅ ｐｒｏｃｅｄｕｒｅ）、又は通信安全又は過程安全（ｐｒｏｃｅｓｓ ｓｅｃｕｒｉｔｙ）に向けられた何等かの他の望ましい安全機構を含んでもよい。加えて、転送される情報及び通信経路自身は、もし望ましいなら、該安全代行者環境を実施するために選ばれるアーキテクチャーに依り変型されることも出来ることを述べておく。更に該通信経路は電子的情報がシステム間を流れることを可能にする種々の機構の何れかを通して実施され得ることを述べておく。
【００６８】
更に安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃの様な該安全代行者は、通信用又は他の過程又は目的用の安全機構を提供することに加えて何等かの望ましいレベルの処理機能を組み込むことが出来る。例えば、該購入管理システム１００Ａ、１００Ｂ．．．１００Ｃは該安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃに、１つ以上の支払いカードに関し追加されるべく又は入手可能にされるべく望まれた購入能力又はオーソライゼーションを表す情報を提供出来て、そして該安全代行者１００Ａ、１００Ｂ．．．１００Ｃは、これらの望まれた購入能力又はオーソライゼーションが該１つ以上の支払いカードに関し入手可能になることを確認するために、現在のカード設定を決定しそして正しくフオーマットされた指示（ｉｎｓｔｒｕｃｔｉｏｎ）を発生し該カードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃに送るために、カードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃとインターフエース出来る。この機能を該安全代行者内に組み込むことにより、該購入管理システム１００Ａ、１００Ｂ．．．１００Ｃ自身は、現在のカード設定を決定し、該カード設定への何等かの必要な調整をもたらすために該正しくフオーマットされた指示を発生し送る機能を実行する必要はない。もし該安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃ内ではより少ない機能しか実行されないことが望ましいならば、例えば、該安全代行者１００４Ａ、１００４Ｂ．．．１００４Ｃは、相当な追加的機能を何等提供することなく該通信システム１０５０内の種々のエンテイテイ間の通信の受信及び送信のみ行う中間安全機構を提供するのみとすることが出来る。要するに、本発明の該安全代行者の実施例用には種々の異なる実施法が利用されてもよい。
【００６９】
描かれている様に、該通信システム１０５０は安全代行者環境用に広範囲の起こり得るアーキテクチャーを提供する。例えば、どの購入管理応用品１００Ａ、１００Ｂ．．．１００Ｃがその通信を送信又は受信しているかに関係なく、カードプロセサー１３０Ａとの通信は安全代行者１００４Ａと通って流れ、カードプロセサー１３０Ｂとの通信は安全代行者１００４Ｂを通って流れる、等々の様に、安全代行者は各カードプロセサーに専用化されることが出来る。又安全代行者は、どの購入管理応用品１００Ａ、１００Ｂ．．．１００Ｃ又はどのカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃがその通信を送信又は受信しているかに関係なく、カード発行者５０２Ａを通って発行されたカードに付随する通信は安全代行者１００４Ａを通って流れ、カード発行者５０２Ｂを通って発行されたカードに付随する通信は安全代行者１００４Ｂを通って流れる、等々の様に、各カード発行者用に専用化されることが出来る。加えて、各カード発行者は、どの購入管理応用品１００Ａ、１００Ｂ．．．１００Ｃがその通信を送信又は受信しているかに関係なく、カード発行者５０２Ａにより発行されたカードに付随しそしてカードプロセサー１３０Ａに付随する通信が安全代行者１００４Ａを通って流れ、カード発行者５０２Ｂにより発行されたカードに付随しそしてカードプロセサー１３０Ｂに付随する通信が安全代行者１００４Ｂを通って流れる、等々の様に、１つが各カードプロセサーに付随する多数の安全代行者を有してもよい。なお更に、各購入管理応用品は、どのカード発行者５０２Ａ、５０２Ｂ．．．５０２Ｃ又はどのカードプロセサー１３０Ａ、１３０Ｂ．．．１３０Ｃがその通信を送信又は受信しているかに関係なく、購入管理応用品１００Ａに付随する通信が安全代行者１００４Ａを通って流れるように、専用の安全代行者を有することが出来る。これらの例の組合せも又実施されることが出来る。かくして、上記で述べた様に、安全代行者環境を実現するために広範囲の起こり得るアーキテクチャーが使用され得る。かくして、これらのアーキテクチャー例は該安全代行者環境を実現するための起こり得る構成とアーキテクチャーのほんの幾つかであり、そしてもし望まれるならば他の組合せ、構成そしてアーキテクチャーが使用され得ることを述べておく。
【００７０】
該動的支払いカードが如何に本発明の動的支払いカード管理システムにより使用され管理され得るかの例を更に説明するために、該システム内で、銀行の役割を含めて、人及びエンテイテイが演ずる役割を論じることが有用である。コーポレートの購入用に、該動的支払いカード管理システム１００の中に少なくとも２つの基本的役割が存在する。これらは、そのコーポレーション用に購入を行うためにオーソライズされる前に承認を得なければならないのが典型的なユーザーを表すリクエスター役割（Ｒｅｑｕｅｓｔｏｒ ｒｏｌｅ）と、或るレベルの予め承認された支出オーソリテイを有するのが典型的なユーザーを表すバイヤー役割（Ｂｕｙｅｒ ｒｏｌｅ）と、である。
【００７１】
該リクエスター役割は直接的又は間接的支出均衡で最も普通のそして最も弱い両面の役割と見られ得る。リクエスターは一般に、会社から事前の承認（ｐｒｉｏｒ ａｐｐｒｏｖａｌ）を有さねば何の支出オーソリテイも持たない。該リクエスター用の事前の承認は種々の環境から発生してもよいが、２つの源の１つから発生することが多い。事前承認の第１の源は該会社の購入過程を経由して承認された購入要求、恐らくは、承認された”チェック要求（ｃｈｅｃｋ ｒｅｑｕｅｓｔ）”又は購入注文（ｐｕｒｃｈａｓｅ ｏｒｄｅｒ）｛ピーオー（ＰＯ）｝からである。第２の源又は事前承認（ｐｒｅ−ａｐｐｒｏｖａｌ）は該会社が特定の種類の購入用にリクエスターに与えた予算（ｂｕｄｇｅｔ）である。その予算は支出のカテゴリー、マーチャントの様な要因により、又は取引当たり最大量により、更に限定される。購入要求の性質に依り、実際の購入は該リクエスターにより又は該リクエスターに代わって作用するバイヤー（下記で説明される）により実行されてもよい。普通の種類のリクエスターは出張及び接待（ｔｒａｖｅｌ ａｎｄ ｅｎｔｅｒｔａｉｎｍｅｎｔ）｛テーアンドイー（Ｔ＆Ｅ）｝購入用にカードを使う人である。該テーアンドイーユーザーは一般に航空機代（ａｉｒｆａｒｅ）、カーレンタル（ｃａｒ ｒｅｎｔａｌ）そしてビジネス食事（ｂｕｓｉｎｅｓｓ ｍｅａｌ）の様な物用の払い戻し可能な支出（ｒｅｉｍｂｕｒｓａｂｌｅ ｅｘｐｅｎｓｅｓ）をこうむる（ｉｎｃｕｒｓ）従業員である。該テーアンドイーユーザーは一般にこれらの支出を該事実の後会社に提出し、もしそれらの支出が会社のポリシー内で払い戻し可能であると決定されれば該会社から支出チェック（ｅｘｐｅｎｓｅ ｃｈｅｃｋ）を受け取る。これらの２つの典型的事前承認環境に加えて、会社は種々の理由の何れかで支出オーソリテイを事前承認しようとしてもよいことを述べておく。
【００７２】
該バイヤー役割は、技術、オフイスサプライ、産業製品／設備、又はマーケッテイングの様な特異分野に亘る会社支出の１つ以上のカテゴリーをカバーする該会社内の購入役割と見ることが出来る。例えば、多くの会社はそれらの情報技術（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）｛アイテー（ＩＴ）｝部門内に技術バイヤーを有する。通常該アイテーバイヤーは技術サプライヤーの関係に、そして会社用の全技術製品の組織横断的調達（ｃｒｏｓｓ−ｏｒｇａｎｉｚａｔｉｏｎａｌ ｐｒｏｃｕｒｅｍｅｎｔ）に、責任がある。オフイスマネージャーはもう１人の共通の種類のバイヤーであり、承認し、集合し、そしてオフイス製品サプライヤーに注文を行うことにより会社オフイスサプライ購入を一般に管理する。バイヤーはリクエスター購入要求が承認された時彼等の分野でサプライヤーに対する門番として作用することが多い。
【００７３】
一般に会社はそれらのバイヤーと強い信頼関係を有する。一般にこの信頼関係は、そのバイヤーの範囲での或るレベルの購入に関してはバイヤーの自由裁量（Ｂｕｙｅｒ ｄｉｓｃｒｅｔｉｏｎ）となり、より重要な購入用にはコーポレートが制御を保持している。対応して、バイヤーが行う各購入は該購入が行われる前か又は後か何れかに行われる或るレベルの弁明（ｊｕｓｔｉｆｉｃａｔｉｏｎ）と一致確認（ｒｅｃｏｎｃｉｌｉａｔｉｏｎ）を要する。アイテーバイヤーの事後弁明（ａｆｔｅｒ−ｔｈｅ−ｆａｃｔ ｊｕｓｔｉｆｉｃａｔｉｏｎ）の例は新しくハイヤーされたセールスパーソン用のノートブックコンピユータを購入することでもよい。この様な場合、会社は該バイヤーが正しいことをすると信頼し、該購入が事実行われた後該バイヤーの支出の弁明を監査する。技術バイヤーの例を作ると、繰り返す年間の保守費用を伴う新しい、高価なソフトウエアパッケージの購入は事前承認を要しそうである。大抵の会社はこのハイブリッドの手段を有し、或る購入に関してはバイヤーの自由裁量及び購入後一致確認を許し、他に関しては事前承認を要求する。会計的見方からは、各バイヤー購入は、指定されたカテゴリーの支出についての集中した会社予算に対し、又は部門又は従業員予算に対し、一致確認されてもよい。
【００７４】
個別従業員が種々のシナリオで多数の役割を演じてもよいことを述べておく。例えば、アイテーバイヤーは又オフイス家具要求の状況ではリクエスターでもあることは可能である。同様に、営業役員（ｓａｌｅｓ ｅｘｅｃｕｔｉｖｅ）は主としてはテーアンドイーユーザーであるが、マーケッテイングの担保の大きなプリントラン（ｌａｒｇｅ ｐｒｉｎｔ ｒｕｎ ｏｆ ｍａｒｋｅｔｉｎｇ ｃｏｌｌａｔｅｒａｌ）用の様な、より一般的なリクエスター要求を行ってもよく、そして或る品目の購入に関し事前承認された支出オーソリテイを割り当てられてもよい。
【００７５】
本発明の動的支払いカードシステムの文脈では、銀行の主要な役割は標準的購入カードプログラムに於けると同じの儘である。銀行（又はそのプロセサー）は顧客とのクレデイット関係を確立し、マスタークレデイットリミットの様な、初期購入カード勘定パラメーターをセットアップし、そして丁度それが従来行った様に該カードを発行する。同様に、銀行の進行中の役割は取引処理、顧客への請求そして受取勘定及び交換の両手数料を集めることを含み続けてもよい。該購入管理システム１００が会社及び銀行用に有利に行うことが出来る１つの機能は会社命令された支出（ｃｏｍｐａｎｙ ｄｉｃｔａｔｅｄ ｓｐｅｎｄｉｎｇ）の動的な操作と管理である。該購入管理システム１００はこの動的操作と管理を、少なくとも部分的には該支払いカードの束縛的特徴を制御することにより行う。特に有用なのは、これらの特徴の少なくとも２つ、すなわち、各カードでのマーチャント設定とベロシテイ設定の、動的制御である。従来はこの種の操作は、変更を要求する顧客のオーソライズされた代表による接触の結果として、銀行又は別のオーソライズされたエージャントにより手動で行われた。対照的に、動的支払いカード管理に動力を与える該購入管理システム１００の動的性質は、該銀行の顧客会社に、その購入を該購入管理システムを通して管理することを可能にし、そして該購入管理システムに、該カード設定を修正し、管理するために該カードプロセサーとインターフエースすることを可能にする。この仕方で、該会社は結果としてそれ自身のカード設定を該銀行で確立された該会社のマスタークレデイットリミット内に管理することを可能にされる。この配分されたカード管理は銀行資源を他の活動用に自由にすることを助ける。
【００７６】
上述の様に、本発明の動的支払いカードはそれに付随する種々の設定の何れかを有することも出来る。例えば、各承認された取引用の承認パラメーターが該カードプロセサーにより記憶されてもよい。これらの承認パラメーター用の詳細度のレベル（ｌｅｖｅｌ ｏｆ ｄｅｔａｉｌ）は該カードプロセサー１３０の能力とユーザーの望みに依る。例えば、上記議論の様に、現在の購入カードは、次ぎの様な、すなわちクレデイットリミット、ベロシテイ（ｖｅｌｏｃｉｔｙ）、スロット（ｓｌｏｔｓ）、ポスアイデー（Ｐｏｓ ＩＤ）、最大取引量、そして流用勘定（ｄｉｖｅｒｓｉｏｎ ａｃｃｏｕｎｔｓ）の様な、制御特徴（ｃｏｎｔｒｏｌ ｆｅａｔｕｒｅｓ）を有する。これらの制御特徴は該カードが購入を行うために如何に使用されてもよいかを束縛するため使用される。望ましい承認設定と、カードプロセサーにより利用される該制御特徴と、に依り、本発明の動的支払いカード管理システムは、カード使用に、一般的から非常に特定的までの、支出束縛を提供出来て、そして承認された費用、従業員バイヤー／リクエスター役割、承認された購入要求、又は何等かの他の望まれた活動に依り、それらの束縛を動的にそして自動的に管理することが出来る。
【００７７】
該カード制御設定の動的管理は、管理される支払いカード用に記憶されそして操作されるパラメーターに恐らく依存して、この動的管理の特定の実施を伴う種々の仕方で起こり得る。例えば、上記で識別された該ベロシテイ及びスロット制御特徴を考えると、これらの特徴が支払いカードの動的管理用に使われ得る種々の異なる方法がある。下記で論じる会社例と付随する取引例は如何にスロット及びベロシテイ設定が利用され得るかの例を提供する。特に、これらの取引例については、スロットは特定の種類の支出オーソリテイ用に、そしてベロシテイ設定はスロット当たりベースで設定、管理される。下記表２は取引例用の初期支払いカード制御設定例を説明する。代わりに、該スロットが或る種の支出カテゴリーが支払いカード用に許されるかどうかを、そしてベロシテイ設定がカード当たりベースで設定され管理され得るかを識別するために使用出来る。例えば、該スロットは、スロット１がテーアンドイー費用を表し、スロット２が現金引き出しを表し、スロット３が一般的購入を表し、スロット４が車両的購入を表し（例えば、ガス、オイル他）、そしてスロット５が通常外の購入ニーヅを表す、様に組織され得る。この代わりの例用には、各スロットがこの種類の購入オーソリテイを許可するようにイネーブルとされるか又はこの種類の購入オーソリテイを却下するようにデイスエーブルとされるかの管理は、初期カードセットアップで行われ、その後で何等かの与えられた支払いカード用に許可された種類の支出オーソリテイを調整する必要がある。該ベロシテイ設定の管理はカードレベルで起こり得て、事前承認された支出オーソリテイ又は能力を使って承認された購入要求及び／又は活動に基づいて遙かに高い頻度で調整されるよう期待される。この代替え例用の設定は表２で表明されたそれらと同様であるが、しかしながら、該ベロシテイ制御設定はカード全体について管理され、各スロットについて個別的にではないことを述べておく。更に、カード制御用設定を動的に管理するためのこれらの例は単に例であり、もし望むなら管理されるべき該支払いカードの特定の性質とそれらの関連する制御設定に基づいて多くの他の実施例と管理技術が実施され得ることを述べておく。
【００７８】
図９Ａ−Ｄは本発明の動的購入カード管理システム実施例内の相互作用を更に説明するスイムレーン線図（ｓｗｉｍｌａｎｅ ｄｉａｇｒａｍｓ）を提供する。特に、図９Ａは支払いカード勘定セットアップとカード発行についての相互作用例用のスイムレーン線図を提供する。図９Ｂは、例えば、図５Ｂの承認処理経路順方向流れ５５４に関する様な、承認が最初に必要な取引用の相互作用例についてのスイムレーン線図を提供する。図９Ｃは、例えば、図５Ｂの承認処理経路逆方向流れ５５６に関する様な、自由裁量支出オーソリテイを含む取引用の相互作用例についてのスイムレーン線図を提供する。そして図９Ｄは完了した取引の購入要求との論理的整合を実現するために注文識別子を追加するための相互作用例についてのスイムレーン線図を提供する。これらのスイムレーン線図の各々について、該線図の頂部に亘りリスト化されたエンテイテイがそれらのそれぞれの箱から下方へ伸びるラインに付随されていることを述べておく。これらのラインの１つからスタートし、もう１つで停止する矢印はこれら２つのスタート及び停止ラインに付随するエンテイテイ間の相互作用を表す。
【００７９】
最初に図９Ａを見ると、勘定セットアップとカード発行処理について相互作用例９００が描かれている。該スイムレーン線図の頂部にリスト化された該エンテイテイはピーエムシステム１００，該カードアドミニストレーター又は顧客１０４，カード保持者１０６，カードプロセサー１３０そしてカード発行者５０２である。図９Ａで、該処理９００は３つの活動、すなわち会社勘定の確立９１０、カード発行９１１そしてカードプロフアイルセットアップ９１２に分けられる。
【００８０】
該会社勘定確立活動９１０内では、相互作用９１３は商業的カード勘定クレデイットを求めるための該カードアドミニストレーター１０４と該カード発行者５０２の間の相互作用を表す。相互作用９１４は顧客マスター勘定を確立するための該カード発行者５０２と該カードプロセサー１３０の間の相互作用を表す。そして相互作用９１５は顧客マスター勘定情報を通信するための該カードプロセサー１３０と該ピーエムシステム１００の間の相互作用を表す。
【００８１】
該カード発行活動９１１内では、相互作用９１６はカード発行を要求するためのカードアドミニストレーター１０４と該ピーエムシステム１００の間の相互作用を表す。相互作用９１７はカード発行を始動するための該ピーエムシステム１００と該カードプロセサー１３０の間の相互作用を表す。相互作用９１８はカード勘定情報を通信するための該カードプロセサー１３０と該ピーエムシステム１００の間の相互作用を表す。そして相互作用９１９はカードを該顧客に郵送（ｍａｉｌ）又は他の仕方で供給するためのカードプロセサー１３０と該カードアドミニストレーター１０４の間の相互作用を表す。代わりに、相互作用９１７は、該銀行がその時カード発行要求と関連情報に関して該カードプロセサー１３０と相互作用する、該ピーエムシステム１００と該カード発行者５０２の間にもあり得る。
【００８２】
該カードプロフアイルセットアップ活動９１２内では、相互作用９２０はカード設定を規定するためのカードアドミニストレーター１０４と該ピーエムシステム１００の間の相互作用を表す。相互作用９２１はカード設定を該カードプロセサーデータベース上に設置するためのピーエムシステム１００とカードプロセサー１３０の間の相互作用を表す。相互作用９２２はカード設定の検証が該ピーエムシステム１００により受信されるカードプロセサー１３０と該ピーエムシステム１００の間の相互作用を表す。そして相互作用９２３は該カードを該カード保持者に発送するための該カードアドミニストレーター１０４と該カード保持者１０６の間の相互作用を表す。
【００８３】
図９Ｂは承認を要する取引過程９３０について相互作用例を提供する。該スウイムレーン線図の頂部にリスト化された該エンテイテイは該ピーエムシステム１００，該カードアドミニストレーター又は顧客１０４，カード保持者１０６，承認者（含む複数）９０２，会計士（ａｃｃｏｕｎｔａｎｔ）９０４マーチャント１４０そしてカードプロセサー１３０である。図９Ｂでは、過程９３０は４つの活動、すなわち要求／承認過程９２９，カード設定更新９３１，購入過程９３２そして取引データ処理９３３、に分けられる。
【００８４】
該要求／承認過程活動９２９内では、相互作用９３４は購入要求を創るための該カード保持者１０６と該ピーエムシステム１００の間の相互作用を表す。相互作用９３５はもし承認が必要であれば承認アクションが必要とされる通知を提供するための該ピーエムシステム１００と承認者（含む複数）９０２の間の相互作用を表す。そして相互作用９３６は該要求の承認を示すための承認者（含む複数）９０２と該ピーエムシステム１００の間の相互作用を表す。
【００８５】
該カード設定更新活動９３１内では、相互作用９３７は現在のカードの設定を要求し、受信しそしてレビューするための該ピーエムシステム１００と該カードプロセサー１３０の間の相互作用を表す。相互作用９３８はカード設定と利用可能な支出オーソリテイを更新するための該ピーエムシステム１００と該カードプロセサー１３０の間の相互作用を表す。そして相互作用９３９は要求承認の通知を提供するための該ピーエムシステム１００と該カード保持者１０６の間の相互作用を表す。
【００８６】
購入過程活動９３２内では、相互作用９４０はもしこの様な検証が望まれる場合に、支出能力の検証を提供するための該カード保持者１０６と該ピーエムシステム１００の間の相互作用を表す。相互作用９４１は注文設置のための該カード保持者１０６とマーチャント又はベンダー１４０の間の相互作用を表す。相互作用９４２は該支払いカード取引用のオーソライゼーションを要求するための該マーチャント１４０と該カードプロセサー１３０の間の相互作用を表す。相互作用９４３は該オーソライゼーション応答を提供するための該カードプロセサー１３０と該マーチャント１４０の間の相互作用を表す。そして相互作用９４４は該取引が完了したことを示すための該マーチャント１４０と該カード保持者１０６の間の相互作用を表す。
【００８７】
該取引データ処理活動９３３内では、相互作用９４５は該取引データの通信を提供するための該カードプロセサー１３０と該ピーエムシステム１００の間の相互作用を表す。相互作用９４６は該取引通知トリガー（含む複数）が充たされた｛ｔｒｉｇｇｅｒ（ｏｒ ｔｒｉｇｇｅｒｓ）ｈａｓ ｂｅｅｎ ｍｅｔ｝ことを示すための該ピーエムシステム１００と該カードアドミニストレーター１０４の間の相互作用を表す。同様に、相互作用９４７は取引通知トリガー（含む複数）が充たされたことを示すための該ピーエムシステム１００と該承認者（含む複数）９０２の間の相互作用を表す。トリガーは、例えば、或る予め決められたイベント又は基準の発生に基づいて賦活するように設定されることが出来る。相互作用９４８は、もし該カード保持者１０６によるアクションが必要であるそして／又は該ピーエムシステム１００により要求されるならば、通知を提供するための該ピーエムシステム１００と該カード保持者１０６の間の相互作用を表す。相互作用９４９は該取引整合及び一致確認用に情報を提供するための該カード保持者１０６と該ピーエムシステム１００の間の相互作用を表す。相互作用９５０は該取引の一致確認の検証と完了をもたらすための会計士９０４と該ピーエムシステム１００の間の相互作用を表す。そして相互作用９５１は該取引の一致確認後の該カード設定と利用可能な支出とを更新するための該ピーエムシステム１００と該カードプロセサー１３０の間の相互作用を表す。カードの制御設定と利用可能支出との更新は該過程内の他の望まれる点、例えば、カード取引と特定の購入要求との整合後、にも行われ得ることを述べておく。
【００８８】
図９Ｃは自由裁量の取引過程９６０用の相互作用例を提供する。該スイムレーン線図の頂部にリスト化された該エンテイテイは図９Ｂに於けると同じである。加えて、図９Ｃでは、過程９６０は図９Ｂに於けると同じ４つの活動に分けられている。該要求／承認過程活動９２９内では、相互作用９６１は、例えば、初期カード設定で自由裁量の又は予め承認された支出又は購入オーソリテイを割り当てるための該カードアドミニストレーター１０４と該ピーエムシステム１００の間の相互作用を表す。これらの予め承認された購入能力は、購入要求承認処理の必要無しの自由裁量支出活動と、続いての支払いカードに関する利用可能支出能力の割り当てと、を見越している。他の活動９３１，９３２そして９３３内では、相互作用９３９が除去されたことを除けば、該相互作用は図９Ｂに於けると同じである。又該相互作用９４９の１部として、該ピーエムシステム１００は整合及び／又は一致確認での使用のために取引詳細に基づき合成購入要求を発生出来ることを述べておく。
【００８９】
上記図９Ｂと９Ｃ内で整合及び一致確認相互作用９４９はカード保持者及び／又は何等かの他の関係者の手動アクションを通して又は該ピーエムシステム１００により行われる自動的論理的整合を通して又は手動及び自動活動の組合せを通しての、取引データと承認された又は合成された購入要求との整合を含むことが出来る。例えば、支払いカードは、承認済み購入要求１｛エイピーアール１（ＡＰＲ１）｝、承認済み購入要求２｛エイピーアール２（ＡＰＲ２）｝、５００ドル用取引１｛テー１（Ｔ１）｝、そして３００ドル用取引２｛テー２（Ｔ２）｝に帰着する、図９Ｂに示す購入要求承認手順を通した２つの購入を行うために使用される。又支払いカードは取引３｛テー３（Ｔ３）｝及び取引４｛テー４（Ｔ４）｝に帰着する、図９Ｃ内に示す予め承認された購入オーソリテイ手順に基づく２つの購入を行うために使用される。取引データが該カードプロセサー１３０からピーエムシステム１００により受信されると、該支払いカード用取引のリストはテー１、テー２、テー３そしてテー４を含む。該ピーエムシステム１００により記憶されたこの支払いカードに付随する承認された購入要求のリストは、しかしながら、エイピーアール１とエイピーアール２とを含むのみである。該支払いカード用取引データが、例えば、カード保持者１０６によりレビューされると、４つの取引と２つの購入要求がある。該整合過程のゴールは各取引を１つ以上の購入要求に割り当てそして／又は各購入要求を１つ以上の取引に整合させることである。このゴールを達成するために、購入要求はテー３及びテー４用に合成され得る。
【００９０】
もし整合手順が自動化されるなら、該ピーエムシステム１００はテー１、テー２，テー３そしてテー４用取引データ及び該承認済み購入要求エイピーアール１そしてエイピーアール２用データを解析出来る。該ピーエムシステム１００は該取引及び購入要求を論理的に整合させようと試みることが出来る。承認済み購入要求に整合させられ得なかった取引については、該ピーエムシステム１００は合成された購入要求３（ｓｙｎｔｈｅｓｉｚｅｄ ｐｕｒｃｈａｓｅ ｒｅｑｕｅｓｔ ３）｛エスピーアール３（ＳＰＲ３）｝及び合成された購入要求４｛エスピーアール４（ＳＰＲ４）｝に帰着する、テー３及びテー４用の合成された購入要求を発生する。該ピーエムシステム１００は次いでテー３及びテー４をそれらのそれぞれの合成された購入要求エスピーアール３及びエスピーアール４と整合させる。
【００９１】
手動整合（ｍａｎｕａｌ ｍａｔｃｈｉｎｇ）も又含まれ得る。例えば、カード保持者１０６又は他の関係者は該支払いカード用取引及び購入要求リストをレビューすることが出来る。この活動もやはりテー１，テー２，テー３そしてテー４用取引データ及び該承認済み購入要求エイピーアール１及びエイピーアール２用データを明らかにする。次いで該レビュー者（ｒｅｖｉｅｗｅｒ）はどの購入要求又は複数購入要求がどの取引又は複数取引に付随するかを手動で識別する。この例では、該レビュー者はエイピーアール１をテー１にそしてエイピーアール２をテー２に割り当てるであろう。要求合成をもたらすために、テー３及びテー４が調査されると、該取引が一般的な予め承認された購入用オーソリテイを使用して完了されるとして示すチェックボックス又はボタン（ｃｈｅｃｋ ｂｏｘ ｏｒ ｂｕｔｔｏｎ）も提供されることが出来る。一旦該レビュー者がこの選択を行うと、該ピーエムシステム１００はエスピーアール３及びエスピーアール４に帰着する、購入要求を合成出来る。代わりに、もし自動的要求合成が望まれないなら、レビュー者はエスピーアール３及びエスピーアール４に帰着する購入要求を手動で創ることが出来る。一旦発生されると、レビュー者はテー３及びテー４をそれらのそれぞれの合成された購入要求エスピーアール３及びエスピーアール４と整合させることが出来る。
【００９２】
自動整合によって又は手動整合によって又は両者の組合せによって行われても、整合手順の望まれる結果は少なくとも１つの予め承認された又は合成された購入要求を各取引と相関させることである。各購入要求が多数の取引をカバー出来ること及び／又は各取引が多数の購入要求で要求された購入をカバー出来ることを述べておく。加えて、取引は購入要求の１部分を充たすのみで、該購入要求を追加的取引用に開いた儘にすることが出来る。更に承認された購入要求に関して、該取引が該承認された購入要求で示されたより多い又は少ないドル用であってもよいことを述べておく。
【００９３】
図９Ｂ及び９Ｃでの相互作用９５１は支払いカードの制御用設定の更新、例えば、購入を行うため前に使用された予め承認された支出用オーソリテイをリフレッシュすること、又は承認された購入要求に付随したが、該要求用には実際に行われた購入では承認された全量は必要なかった、支出用オーソリテイを除去すること、をもたらす。この更新は該過程のどんな望まれる点でも起こり得ることを述べておく。例えば、この更新は、カードプロセサーからの取引データの受領後、該整合過程の完了後、又は該会計部門が該取引を正式に一致確認しその注文を閉じた後、の様な１つ以上の選択されたイベントの発生に基づいて起こり得る。加えてこの様なイベントの発生に関連して、この更新は該イベントの発生後直ちにか、該イベント後の或る望ましい期間内にか、該イベントを含む請求サイクルの終わりでか、或いは何等かの他の望ましい時に、起こり得る。該カード制御設定に関して、この更新は該取引に基づくどんな望ましいレベルの調整も提供出来る。例えば、上記テー１が割り当てられた５００ドルの代わりに４５０ドルしか使わなかったと仮定する。該更新は該追加の５０ドルを除去出来る。そして、例えば、テー３に関して、該３００ドルの取引はエスピーアール３と整合される時、該ピーエムシステム１００はその支払いカード用の予め承認された支出用オーソリテイに３００ドルを戻し追加するため該支払いカードを更新出来て、それにより該予め承認された支出用オーソリテイを回復する。従って、この仕方で、該支払いカード用の予め承認された支出用オーソリテイは、取引活動と購入管理システム１００により行われた処理とに依り元の又は中間の値に回復され得ることを述べておく。
【００９４】
図９Ｄは論理的整合を実現するために注文識別子の追加を含む過程９８０用の相互作用例を提供する。該スウイムレーン線図の頂部にリスト化されたエンテイテイは、該カードアドミニストレーター１０４が除去され、該ピーエムシステム１００が要求／注文インターフエース９０６と一致確認インターフエース９０８を有することを除けば、図９Ｂに於けると同じである。図９Ｄでは該過程９８０は図９Ｂに於けると同じ４つの活動に分けられる。図９Ｄと図９Ｂの間の主要な差は相互作用９８１，９８２，９８３そして９８４により表される注文識別（ｏｒｄｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）｛注文アイデー（Ｏｒｄｅｒ ＩＤ）｝情報の追加である。該注文アイデーは該取引を識別し、それにより該取引データの購入要求又は合成された購入要求との後刻の整合及び／一致確認（ｍａｔｃｈｉｎｇ ａｎｄ／ｏｒ ｒｅｃｏｎｃｉｌｉａｔｉｏｎ）を容易化することを助けることを述べておく。該取引情報に付随する該注文アイデーはこのゴールを達成するために種々のフオームのどれを取ってもよく、例えば、該注文アイデーはマーチャント識別子又はコード、取引種類識別子又はコード、購入取引の種類を識別する１ビットのフラグ（例えば、承認を要する又は予め承認された支出用オーソリテイ）、又は何等かの他の望ましい識別情報であってもよい。
【００９５】
該要求／承認過程活動９２９内では、相互作用９３４は購入要求を創るための該カード保持者１０６と該ピーエムシステム１００の該要求／注文インターフエース９０６との間の相互作用を表す。相互作用９３６は該要求の承認を示すための該承認者（含む複数）９０２と該ピーエムシステム１００の該要求／注文インターフエース９０６との間の相互作用を表す。そして相互作用９８１は注文アイデーを提供するための、該承認者（含む複数）９０２と該ピーエムシステム１００の該要求／注文インターフエース９０６との間の、相互作用９３６の１部であってもよい、追加的相互作用を表す。該注文アイデーが幾つかの他の仕方で又はもう１つのエンテイテイ又は関係者により提供されること、例えば、該注文アイデーがカード保持者、リクエスター、承認者、アドミニストレーター、サプライヤー、会計士又はバイヤーにより提供され得ること、そしてそれが該システムにより自動的に提供され得ることを述べておく。
【００９６】
該更新カード設定活動９３１内では、相互作用９３７／９３８は現在のカード設定をレビューしそしてカード設定と利用可能支出オーソリテイを更新するための該ピーエムシステム１００の該要求／注文インターフエース９０６と該カードプロセサー１３０の間の相互作用を表す。そして相互作用９３９は要求承認の通知を提供するための該ピーエムシステム１００の該要求／注文インターフエース９０６と該カード保持者１０６の間の相互作用を表す。
【００９７】
該購入過程活動９３２内では、相互作用９４０は支出能力の検証を提供するための該カード保持者１０６と該ピーエムシステム１００の該要求／注文インターフエース９０６との間の相互作用を表す。相互作用９４１は注文設置のためのカード保持者１０６とマーチャント又はベンダー１４０の間の相互作用を表す。相互関係９８２は該注文アイデーを提供するための該カード保持者１０６とマーチャント１４０の間の、相互作用９４１の１部であってもよい、追加的相互作用を表す。相互作用９４２は支払いカード取引用オーソライゼーションを要求するための該マーチャント１４０と該カードプロセサー１３０との間の相互作用を表す。相互作用９４３は該オーソライゼーション応答を提供するための該カードプロセサー１３０と該マーチャント１４０との間の相互作用を表す。そして相互作用９４４は該取引が完了したことを示すための該マーチャント１４０と該カード保持者１０６との間の相互作用を表す。
【００９８】
取引データ処理活動９３３内では、相互作用９４５は取引データの通信を提供するための該カードプロセサー１３０と該ピーエムシステム１００の該要求／注文インターフエース９０６との間の相互作用を表す。相互作用９８３は注文アイデーを提供するためのカードプロセサー１３０と該ピーエムシステム１００の該要求／注文インターフエース９０６との間の、該相互作用９４５の１部であってもよい、追加的相互作用を表す。相互作用９８４は該取引の該注文記録又は注文アイデーとの自動整合を提供するための該ピーエムシステム１００の該要求／注文インターフエース９０６と該ピーエムシステム１００の該一致確認インターフエース９０８との間の相互作用を表す。相互作用９５０は取引一致確認の検証と完了を提供するための会計士９０４と該ピーエムシステム１００の該一致確認インターフエース（ｒｅｃｏｎｃｉｌｉａｔｉｏｎ ｉｎｔｅｆａｃｅ）９０８との間の相互作用を表す。そして相互作用９５１は該取引の一致確認後の該カード設定と利用可能支出とを更新するための該ピーエムシステム１００の該要求／注文インターフエース９０６と該カードプロセサー１３０の間の相互作用を表す。カード制御用設定と利用可能支出の該更新は又該過程の他の望ましい点、例えば、カード取引の特定購入要求との整合後に、行われ得ることを述べておく。
【００９９】
図８Ａ−Ｄは更に該ピーエムシステム１００用の購入管理過程流れの例に関する詳細を提供する。最初に図８Ａを見ると、購入流れ８００用の高レベルブロック線図が提供され、それは支出制御部８０２，要求管理部８０４、注文管理部８０６そして財務管理部８０８を含む。描かれた実施例では、この購入流れ８００は下記順序、すなわち（１）支出制御部８０２、（２）要求管理部、（３）注文管理部８０６、そして（４）財務管理部、を有し、次いで支出制御部８０２での開始へ戻るよう巡っている、管理活動のループと見なされ得る。この購入流れは１例であり、種々の他の購入流れ実施例又はこの購入流れ８００に対する変型が、望まれて、取り入れ得ることを述べておく。
【０１００】
該支出制御活動８０２はコーポレート支出を制御するための種々の機構の何れをも含んでいる。例えば、アドミニストレーターに種々のセットの支出規則を設定可能にする構成可能な支出カテゴリー及び支出規則が供給されることも可能である。これらの支出規則は組織規則、財務規則、サプライヤー規則又は支出規則の何等かの他のセットを含むことが出来る。組織規則及びポリシーは、グループの階級組織（ｈｉｅｒａｒｃｈｉｅｓ）を創ること、ユーザーをこれらのグループに割り当てること、グループ又はこれらのグループ内の人を通しての承認通過経路を確立すること、関連した支出リミットと予算束縛を有するグループ間の関係を創ること、又は何等かの他の望まれる組織関連規則を創ること、様な活動を含むことが出来る。財務規則は、承認者、リクエスターそしてアドミニストレーター職務とオーソリテイを該組織内の人に割り当てること、コーポレート範囲又はグループレベルの支出ポリシー規則を実施すること、他の支出ポリシー規則を実施すること、総勘定元帳（ｇｅｎｅｒａｌ ｌｅｄｇｅｒ）｛ジーエル（ＧＬ）｝会計と予算をセットアップすること、又は何等かの他の望ましい財務関連規則を創ること、の様な活動を含むことが出来る。サプライヤー規則は、サプライヤープロフアイル（ｓｕｐｐｌｉｅｒ ｐｒｏｆｉｌｅｓ）をセットアップすること、該ピーエムシステム１００を通してのオンライン購入用の品目カタログをポピュレート（ｐｏｐｕｌａｔｅ）すること、サプライヤー及び製品選択を構成すること、又は何等かの他の望ましいサプライヤー関連規則を創ること、の様な活動を含むことが出来る。支出制御活動８０２と関連構成の１部として、例えば、会社は承認と支出過程でのオーソリテイレベルを構成し、コーポレート支出用ポリシーをセットアップし、そして組織、プロジェクト又は支出カテゴリーによりグループ構造を構成することが出来る。要するに、支出制御活動８０２を通して、該ピーエムシステム１００は、会社購入管理用に該ピーエムシステム１００を誂えそして初期化するよう構成をもたらすためにアドミニストレーター又は会社用のインターフエースを提供する。加えて、該購入流れ８００がそのループに沿って続くと、該支出制御活動８０２は、これらのコーポレート購入流れ構成に変型、変化そして更新が行われ得るインターフエースを提供する。
【０１０１】
該支出制御活動８０２と付随構成ユーテイリテイは、例えば、種々の購入要求の承認用に何が必要かを自動的に決定する種々の購入規則及びポリシーを会社が識別し確立することを可能にする構成可能な購入ポリシーを含んでもよい。例えば、この様な購入ポリシーはどの購入が自動的に承認されてよいかを決定する能力のみならずどの購入が購入される前に手動承認を要するかの指示（ｉｎｄｉｃａｔｉｏｎ）も含んでもよい。加えて、手動承認の度合は支出されるべき量の簡単な承認から、該購入のベンダー又は他の詳細に関する常に増加する詳細事項まで、望ましい様に、選択されてもよい。
【０１０２】
加えて、本発明の１実施例では、管理者は該購入管理システム１００に付随するウエブサイトをナビゲートするために従来のインターネットブラウザーを使用してもよい。一旦勘定がセットアップされると、該管理者は、グループ（例えば、部門、プロジェクト、他）と該グループ内に設置すべき要素（例えば、個人ユーザー、車両、他）を創ることそして予算支出リミットを規定すること、を含む、種々の管理機能を行える。グループは要素及び／又は他のグループを含んでもよい。支出リミットはグループ、要素、又は両者の組合せ用に、個別に又は合算して確立されてもよい。要素はリクエスター、承認者、又は何等かの他の望ましい指定で規定され得る。該管理者は次いで何時与えられた購入が手動承認を要するかを決定する規則を含めて購入承認用の詳細なオプションを規定してもよい。有利なことは、このネットワークアクセス可能な管理システムは特殊なクライアント側ソフトウエアを要することなく、従来のネットワークブラウザーで実施されてもよい。
【０１０３】
購入管理システム用の例示的承認管理の特徴は、上記で示した様に、その全体で引用により本明細書にここで組み入れられる、”オンラインビジネス購入用の方法とシステム（Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｏｎｌｉｎｅ Ｂｕｓｉｎｅｓｓ Ｐｕｒｃｈａｓｉｎｇ）”の名称の、米国特許出願直列番号第０９／４０９，３１６号で詳細に説明されている。
【０１０４】
図８Ｂは該要求管理活動８０４の１部となり得る例示的過程を説明することを助ける流れ線図を提供する。この実施例では、リクエスター｛ビリーヒューストン（Ｂｉｌｌｙ Ｈｏｕｓｔｏｎ）｝、承認者｛ジョンスミス（Ｊｏｈｎ Ｓｍｉｔｈ）｝そして追加的承認者（含む複数）の候補者（ｐｏｔｅｎｔｉａｌ）が居る。図８Ｂの底部で注目される様に、もし望ましいなら、外部のリクエスター又は承認者が含まれることも可能だが、要求管理活動８０４は主として内部のコーポレートの活動である。
【０１０５】
ブロック８１２では、該リクエスターにより購入要求が創られる。これらの要求はブロック８１０内でセーブされ得て、これらの購入要求用のステイタスは追跡要求ステイタスライン（Ｔｒａｃｋ Ｒｅｑｕｅｓｔ Ｓｔａｔｕｓ ｌｉｎｅ）８２０により指示された様に追跡され得る。一旦要求が提出されると、もし該支出制御活動８０２を通してセットアップされた規則とポリシーにより承認が要求されるならば、該購入要求の、イーメール通知を通してか、又はもう１つの望ましい通知機構を通しての様な、通知が承認者（Ａｐｐｒｏｖｅｒ）へ送られ得ることがブロック８２２で示される。ブロック８２４で、購入要求がレビューされる。もし拒絶されるなら、流れはブロック８１４へ進むが、そこでは該要求が拒絶された通知が該リクエスターへ送り返される。ブロック８１６で、該リクエスターは該要求と該拒絶をレビュー出来る。もし望むなら、該要求は校訂され再提出されることも出来る。この修正された要求は又ブロック８１０でセーブされることも出来る。代わりに、該要求は取り消され、次ぎにブロック８１８で削除され得る。もし該購入要求がブロック８２４で承認されるなら、流れはブロック８２６へ進みそこで追加的承認が必要かどうかが決定される。もし回答が”イエス”なら、流れは図８Ｂで示す追加的承認サイクルへ進むことが出来る。もし該回答が”ノー”であるなら、流れは要素８２８により表される注文管理活動８０６へ続くことが出来る。
【０１０６】
購入要求処理は又承認のキュー（ｑｕｅｕｅｓ）を利用する。一旦品目が該承認のキューへ送られると、例えば、購入選択を承認する、購入選択を拒絶する、又は該選択を”オンホールド（ｏｎ ｈｏｌｄ）”ステイタスに置く等の、与えられたアクションを取らねばならない与えられた人へ通知が送られる。承認者が該承認キューをレビューすることを選ぶと、レビューされるべき品目の詳細な見方が該承認者へ提供される。もし１セットの品目が該承認のキュー内にリスト化されるなら、該承認者はライン品目拒否（ｌｉｎｅ ｉｔｅｍ ｖｅｔｏ）又は特定品目についての承認を行ってもよい。存在する規則に依り、１人以上の承認者が承認前に該要求をレビューするよう通知されてもよいことを述べておく。更に、もし手動承認が必要ならば、承認まで他のものが遅延させられる間、自動的に承認される要求は直ちに処理されるように、与えられた購入要求がポリシー規則により多数の要求に分けられてもよいことを述べておく。加えて、ベンダー又は該要求の何等かの他の望ましい特徴に依り、各要求内の品目は該サーバー内で論理的に分割、管理されてもよい。
【０１０７】
図８Ｃは該注文管理活動８０６の１部分とすることが出来る処理例を説明する助けとなる流れ線図を提供する。この実施例には、リクエスター｛フアイナンスアドミストレーテイブアシスタント（Ｆｉｎａｎｃｅ Ａｄｍｉｎｉｓｔｒａｔｉｖｅ Ａｓｓｉｓｔａｎｔ）｝、購入注文番号（ＰＯ＃）割当者ａｓｓｉｇｎｅｒ｛ウイジェットパーチャサー（Ｗｉｄｇｅｔ Ｐｕｒｃｈａｓｅｒ）｝、購入者（ウイジェットパーチャサー）、受領者（フアイナンスアドミニストレーテイブアシスタント）、そしてサプライヤー｛エイシーエムイーサプライ社（Ａｃｍｅ Ｓｕｐｐｌｙ Ｃｏ．）｝が居る。図８Ｃの底部で注目される様に、該注文管理活動は内部的及び外部的両活動を含み、そしてもし望ましいなら追加の内部的及び外部的活動が提供されることが出来ることを述べておく。
【０１０８】
ブロック８４２で、該ＰＯ＃割当者は、該要求管理活動８０４からのエントリーを表すノード（ｎｏｄｅ）８４０を通して承認された要求を受ける。この承認された要求は該過程のこの点ではそれに付随する購入注文を有しないと仮定される。ブロック８４４で、該ＰＯ＃割当者は該購入要求にＰＯ＃を付加する。又該ＰＯ＃は他の仕方で提供されることも出来て、例えば、該ＰＯ＃は、購入注文番号（複数ＰＯ＃）がＰＯ番号付け（ＰＯ ｎｕｍｂｅｒｉｎｇ）用の予め決められた会社規則に基づいて自動的に割当られる、該ピーエムシステム１００により自動的に提供され得る、ことを述べておく。ブロック８４６で、該購入者は今は付随ＰＯ＃を有する承認済み要求を受ける。ブロック８４８で、該購入者は該購入注文｛ピーオー（ＰＯ）｝詳細をレビュー出来て該注文をサプライヤーに出すことが出来る。ブロック８５６で、該サプライヤーはフアックス、イーメール、ペーパーコピー、又は直接本人のコンタクト、の様な適当な手段を通して該ＰＯを受ける。ブロック８５８で、該サプライヤーは該注文を充たす（ｆｕｌｆｉｌｌｓ）。ブロック８５０で受領者は積み荷（ｓｈｉｐｍｅｎｔ）を受け取り、該注文充足の量及び／又は他の詳細を検証する。ブロック８５２で、該受領者は該購入された品目を該リクエスターへ配布し、ブロック８５４で該リクエスターは該購入された品物を得る。これらの過程を通して、該購入要求のステイタスは追跡要求ステイタスライン８２０により指示された様に再び追跡される。ノード８６０は財務管理活動８０８へ進む流れを表す。ドル量しきい値より下の取引用、の様なＰＯ＃が望ましくない及び／又は必要とされない取引用、には過程の流れはノード８４０からブロック８４８へ直接進むことが出来る。
【０１０９】
図８Ｄは該財務管理活動８０８の１部であり得る過程の例を説明する助けとなる流れ線図を提供する。この実施例には、リクエスター（ビルヒューストン）、会計士｛クリスチンマーゴリス（Ｋｒｉｓｔｉｎ Ｍａｒｇｏｌｉｓ）｝、ビジネスアナリスト（Ｂｕｓｉｎｅｓｓ Ａｎａｌｙｓｔ）｛メリーウエスト（Ｍａｒｙ Ｗｅｓｔ）｝、そしてサプライヤー｛メデイヤイベントコンセプト（Ｍｅｄｉａ Ｅｖｅｎｔ Ｃｏｎｃｅｐｔｓ）｝が居る。図８Ｄの底部で注目される様に、該財務管理活動８０８は内部的及び外部的の両活動を含み、もし望ましいならば追加の内部的及び外部的活動が提供されることも可能であることを述べておく。流れは該注文管理活動８０６から、購入された品物が受領されたかどうかを決定するため行われるチェックがあるノード８７０まで続く。又注文管理活動８０６からの流れはノード８９０からそして、サプライヤーが該購入された品物用のインボイス（ｉｎｖｏｉｃｅ）を創るブロック８８８まで続く。ブロック８７２で、このインボイスは会計士により受領されそして流れはブロック８７４へ進むことが出来る。加えて、このインボイスデータはブロック８７６で該会計システム内へ手動で入れられることが出来るか、又はそれはブロック８７２からブロック８７６へのラインで表される様に該サプライヤーから該会計システム内へ電子的に受けられることも出来る。ブロック８７８で、該インボイスはレビューされ、そして望ましいならば総勘定元帳（ジーエル）コードが付加されることが出来る。流れは次いでブロック８７４そして８８０へ進む。
【０１１０】
ブロック８７４で、該購入された品物が受領されたかどうかの決定が行われる。もし回答が”ノー”なら、問い合わせがノード８７０を通して該リクエスターへ戻るよう行われる。もし回答が”イエス”なら、流れは会計士が該会計システム内で該購入注文（ピーオー）を閉じるブロック８８０へ進む。ブロック８８２で、インボイスはアイテム（ｉｔｅｍ）８８４で表される会社システム（含む複数）の様な、コーポレート会計システムへ移送され得る。加えて、該ビジネスアナリストに、表された報告／分析ライン８８６の様な会社費用に関して分析、報告させる様な、他の財務管理活動が行われ得る。ここから、もし該コーポレート支出制御構成に対しレビュー、更新又は修正が望まれるなら、該購入流れ処理は該支出制御活動８０２で再び始まることが出来る。
【０１１１】
加えて、該購入流れ８００が、該コーポレーションがその購入活動を続けると同時にそして平行して、起こり得る進行中の活動を表していることを述べておく。該購入流れの例８００は限定的例であると意図されておらず、単に該ピーエムシステム１００を通して実施出来る活動の例を提供するものである。
【０１１２】
上記で論じた様に、購入管理システム１００は好ましくは購入管理に関する会社の財務的制御、洞察（ｉｎｓｉｇｈｔ）そして素早さ（ａｇｉｌｉｔｙ）を実現するインタネット供給される応用品（ｉｎｔｅｒｎｅｔ−ｄｅｌｉｖｅｒｅｄ ａｐｐｌｉｃａｔｉｏｎ）であるのがよい。該購入管理システム１００は、購入要求が購入の前に承認され、支出の前以ての適合性保証を行うように会社の会計的ポリシーを強化することを助ける。購入管理システム１００の購入データ報告ダウンロードの特徴は会計員に、会計コードを含むこれらの承認済み購入要求に関する情報を、会計ソフトウエア内に自動的に、ダウンロードすることを可能にするよう提供され、エントリー時間と誤りを減じる。それにより該購入管理システム１００は承認サイクルを流線型化し、購入及び財務管理者の参加は減じられ、或るドル量を超える要求の様なポリシー例外を扱うことへ向けられる。
【０１１３】
又本発明の購入用のそして動的支払いカード管理システムは一般的な予め承認されたカードの束縛下で行われる購入用に購入要求合成（ｐｕｒｃｈａｓｅ ｒｅｑｕｅｓｔ ｓｙｎｔｈｅｓｉｓ）を提供する。下記会社例に関連して論じる様に、動的支払いカードはユーザーが購入要求承認過程を通ることを要求せずに或るレベルの承認された支出を有してセットアップされてもよい。もしユーザーがこの様な取引を行うなら、その購入は典型的にそれに付随する購入要求又は購入注文を有しない。カード処理システム１３０から提供されるデータを使って、該購入管理システム１００はこの取引用の購入要求及び／又は購入注文を合成する。この合成された購入要求／注文は、望まれる様に、その取引が購入要求／注文に対し一致確認され得るように、会社の会計システムにより次いで使用されることが出来る。この仕方で、広範な種類の有利な合成情報がそれらの追跡、会計又は他の目的で会社に提供され得る。該購入管理システム１００は又、例えば、従業員、部門、製品カテゴリー、コストセンター又は他の望まれる基準による等、種々の望ましい組織的パラメータにより、会社全体用の更新された購入情報の連結された展望への１クリックアクセス（ｏｎｅ−ｃｌｉｃｋ ａｃｃｅｓｓ）を財務管理者（ｆｉｎａｎｃｉａｌ ｍａｎａｇｅｒｓ）に与える購入ダッシュボードを含むことが出来る。
【０１１４】
本発明の該動的支払いカード及び購入管理システム１００は、有利なことは、従来の静的購入カード束縛を動的購入規則で置き換えることが出来る革命的購入カードビヒクル（ｒｅｖｏｌｕｔｉｏｎａｒｙ ｐｕｒｃｈａｓｉｎｇ ｃａｒｄ ｖｅｈｉｃｌｅ）を提供する。どの会社の承認済み取引の実行も許容するよう該動的支払いカードを動的に管理する能力を提供する該購入管理システム１００は該カードプロセサー又はカード処理システム１３０に記憶された動的支払いカード束縛及び承認パラメーターを制御する。又本発明の該動的支払いカードはカード毎ベースでの標準的クレデイットリミットを含む現在の購入カード機能を維持する。そしてそれはゼロの利用可能クレデイットを有するカードが従業員の大きい集合に配布される高い制御シナリオを可能にする。一旦従業員が要求を提出し承認を受けると、該購入管理システム１００はカード処理システム１３０を通して該動的支払いカードを動的に管理する。購入が始動されると、それが承認されたパラメーターに属するなら該カードプロセサーは該購入を承認する。有利なことは、本発明のこの動的支払いカードプラットフオームは、望ましい効率を犠牲にすることなく高度の制御を選ぶことを会社に可能にすることにより制御の矛盾を解決する。この動的制御は、本発明の該動的支払いカードを全ての会社購入（高いドルの購入を含む）用の主要な支払い手段用の有利な解決策にする効果を有する。
【０１１５】
又本発明を通して利用可能な動的制御は支払いカードが、該会社へ請求されるが、なお従来の会社クレデイットカードの逓減負債残高特性（ｄｅｃｌｉｎｉｎｇ ｂａｌａｎｃｅ ｃｈａｒａｃｔｅｒｉｓｔｉｃ）を有することを可能にする。例えば、ユーザーはその動的支払いカード上にセットされた予め承認された支出用オーソリテイに基づき購入するため該支払いカードを使用出来る。これらの購入が行われると、それらはこのカード用にセットアップされた利用可能な予め承認されたクレデイット又はベロシテイに対しカウントする。費用の承認時又は該購入管理過程の或る他の点で、該購入は該カードからクリヤ出来て、それにより該ユーザーの動的支払いカード用の利用可能クレデイット及び購入用オーソリテイを増加又は回復する。その結果は、各従業員用に動的に管理されたクレデイットとベロシテイレベルを保持しながら、従業員に個人的払い戻しの悩み無しに会社費用をこうむる限定された能力しかもたらさない逓減承認負債残高型の特徴と付随購入制御となる。かくして本発明は、或るレベルの事前承認支出オーソリテイをなお提供しながら、カードの束縛の動的制御を通して費用を制御するビヒクルを提供する。例えば、出張及び接待（テーアンドイー）費用に関して、一旦それらが該購入管理システム内で承認、整合又は他の仕方で処理されると取引量の戻し付加と結合されたこの予め承認された支出オーソリテイは、従業員に該システムにより究極的に処理され得るテーアンドイー費用とすることを可能にし、一方該従業員をテーアンドイー費用について払い戻しさせられることを煩わねばならぬことからなお開放する。
【０１１６】
この逓減承認負債残高の特徴を有するので、従ってユーザーは有限量の金について会社に負うよう会社により”信頼（ｔｒｕｓｔｅｄ）”され得る。その有限量の選択はそのユーザーの動的支払いカード用に購入管理システムの設定により制御され得て、エムシーシーグループ又は該動的支払いカード上で利用可能な何等かの他の制御要因により変化してもよい。例えば、ユーザーがテーアンドイーエムシーシー又はエスアイシーコード用に５，０００ドルであるが、全ての他のエムシーシー又はエスアイシーグループ用に０ドルの利用可能ベロシテイを有してもよい。その点で、該ユーザーは予め承認された要求無しにテーアンドイー品目で５，０００ドルまで支出出来て、そしてそのユーザーの利用可能ベロシテイ及び／又はクレデイットリミットはそれだけ逓減するであろう。対応して、その同じユーザーは、適当なエムシーシーグループ内で利用可能なベロシテイを追加するであろう予め承認された要求無しには、オフイスサプライに何等の支出も出来ない。カード設定と取引の更に進んだ例が表２で表明され下記取引例で論じられる。
【０１１７】
加えて、上記で述べた様に、予め承認された支出用オーソリテイを使用して予めの承認無しに行われたテーアンドイー又は他の費用の様な費用のためには、取引後要求（ｐｏｓｔ−ｔｒａｎｓａｃｔｉｏｎ ｒｅｑｕｅｓｔ）も合成されてもよい。例えば、ユーザーの”信頼された（ｔｒｕｓｔｅｄ）”ベロシテイが該購入管理システム１００により保持されるテーアンドイーエムシーシーゲループに関して、テーエスワイエスカード処理システムの様な、カード処理システム１３０により報告された各テーアンドイー取引は、合成された要求に帰着し、該テーエスワイエスカード処理システム取引ログにより供給されるデータの全部の又は幾つかの望まれる表現を提示する。加えて、取引詳細、会計又はジーエルコーデイング、弁明又は何等かの他の情報の様な、追加的取引情報が、該合成された要求の該購入に関してユーザーから要求されるか又は必要となるが、それは次いで該購入管理システムを通しての承認用又は他の処理用に送られてもよい。各弁明された支出が承認されるか又は該過程の別の望まれた点にある時、該購入管理システム１００は該カード処理システム１３０への適当な伝言及びコマンドを通してそのエムシーシーグループ上でその量のベロシテイを復位（ｒｅｉｎｓｔａｔｅ）することが出来る。該予め承認された支出オーソリテイ用の利用可能ベロシテイへのこの逓減負債残高アプローチ（ｄｅｃｌｉｎｉｎｇ ｂａｌａｎｃｅ ａｐｐｒｏａｃｈ）と事後承認取引の進行中制御及び復位（ｏｎｇｏｉｎｇ ｃｏｎｔｒｏｌ ａｎｄ ｒｅ−ｉｎｓｔａｔｅｍｅｎｔ ｏｆ ｐｏｓｔ−ｆａｃｔｏ ａｐｐｒｏｖｅｄ ｔｒａｎｓａｃｔｉｏｎｓ）は該購入管理システム１００に有利で柔軟な制御の特徴を提供する。
【０１１８】
図２は本発明の、動的支払い識別子と承認パラメーターをより一般的に利用する購入要求処理２００用流れ線図である。最初に、ブロック２０２で、ユーザー又は他の要素、（人々、器具、車両、建物、又は何等かの他の望まれた人、場所又はもの）が１つ以上の動的支払い識別子を提供されるか又は割当られる。上記で示した様に、ユニークな番号を有する磁気ストリップカードが動的支払い識別子を提供するため利用出来る。有利なことに、本発明の動的支払いカードは現在のクレデイットカード処理インフラストラクチャー内で使用されてもよい。ブロック２０４へ移ると、次いでユーザーは動的支払い識別子を使用して購入要求を発生することによりその過程を始めてもよい。この購入要求は、ベンダー、購入されるべき製品又はサービス、量、価格付け、弁明、又は何等かの他の望まれる情報の様な、購入情報を識別出来る。ブロック２０４で動的支払い識別子を利用する代わりに、該動的支払い識別子は、望まれる該過程の或る他の点、例えば、購入要求が既に承認されてしまったブロック２０８で、購入要求に付随してもよい。ブロック２０６では、この購入要求は存在する会社ポリシー及び規則に依りレビューされ、そして該購入要求は究極的に拒絶又は承認される。もし該要求が拒絶されるなら、流れはブロック２３０へ進む。ブロック２３０が示す様に、望まれる取引を完了する承認を得ることで続けるためには新しい又は修正された購入要求がユーザー用に必要である。
【０１１９】
もし該購入要求が全体でか又は部分的にか何れかで承認されるならば、流れはブロック２０８へ進み、そこでは購入注文が発生される。この購入注文は要求される取引の詳細を表す。購入要求処理の結果として、そしてブロック２０８で表される様に、承認パラメーターも又発生され、該購入要求及び購入注文に付随する。これらの承認パラメーターは、該取引が完了されねばならない時間、承認されたベンダー、承認された取引量、又は何等かの他の望まれる取引制限又は要求を含む種々の詳細事項の何れかを備えてもよい。かくして、一旦承認されると、各購入要求はそれに付随して、１セットの動的承認パラメーター、購入注文、そして動的支払い識別子を有する。この情報は更に進んだ処理及び一致確認用にブロック２２０に提供される。
【０１２０】
ブロック２１０で、該動的承認パラメーターは、付随した動的支払い識別子及び何等かの他の望まれる情報と一緒に、該取引を処理する動的支払い処理システムへ提供される。与えられた購入注文用の承認必要性を表すこれらの承認パラメーターは次いで、ブロック２０４で購入要求用に使用される動的支払い識別子に対して的に記憶される。これらの動的承認パラメーターの記憶は、例えば、該動的支払い識別子に付随しそして該処理システムにより現在記憶されている該承認パラメーターの該購入管理システムによるレビューを通して、そして次いで記憶された承認パラメーターが該承認された取引を進めさせる状態に移すために該購入管理システムにより該処理システムへ送られた、付加（ａｄｄ）、削除（ｄｅｌｅｔｅ）又は修正コマンド（ｍｏｄｉｆｙ ｃｏｍｍａｎｄｓ）の様な、適当なパラメーター管理コマンドを通して、実施されることが出来る。ブロック２１２では、ユーザーは、例えば、動的支払いカードであってもよい動的支払い識別子を利用して取引を始動する。ブロック２１４で、該取引詳細事項はその動的支払い識別子用に記憶された動的承認パラメーターと相関させられる。各動的支払い識別子が１セットが各承認された取引に付随しそして購入注文に関係付けられた複数の種々のセットの承認パラメーターを有してもよいことを述べておく。かくして、ブロック２１４で起こる相関はどのセットの承認パラメーターが該始動された取引用に使用されるべきかを識別すべきであろう。例えば、ベンダー情報は該始動された取引を減少した数のセットの承認必要性に限定するため最初に利用されてもよい。そこから、どのセットの承認必要性を利用するかを更に決定するために取引量又は製品／サービスの種類が利用されてもよい。代わりに、別の識別番号又は他の識別子が、始動された取引を承認された購入注文と直接関係付けるため記憶され利用されることが出来る。
【０１２１】
ブロック２１６で、該取引は、該取引が承認パラメータ内に入るかどうかを決定するために該動的支払い処理システムによりレビューされるか、又は処理される。もし該取引がこれらのパラメーター外に外れるなら、流れはブロック２２４へ進みそこで該取引は拒絶される。そこから、決定ブロック２２６は追加取引企画が許されるべきかどうかを決定する機構を提供する。例えば、もし取引量パラメーターが超えられていれば、”イエス”が決定され、そして流れは次いでブロック２１２へ戻るよう進み、そこで該ユーザーは適当な取引を始動するようトライすることが出来る。更に進んだ例として、もしタイムリミットパラメーターが超えられたならば、”ノー”が決定され、そして流れは次いでブロック２３０へ戻るよう進むことが出来て、そこで新しい購入要求が必要となろう。
【０１２２】
ブロック２１６へ戻って見ると、もし該取引が承認パラメーター内に入るなら、流れはブロック２１８へ進み、そこで該取引は完了する。該取引詳細は戻って該購入管理システムへ提供され、そしてブロック２２０で、該取引は該購入注文及びブロック２０８から前に提供された他の情報と一致確認される。一旦取引が一致確認されると、ブロック２２２で示される様に、会計詳細がクライアントへ報告される。ブロック２２２の報告が、例えば、該動的支払い識別子を利用した全クライアント取引の毎月のステートメント（ｍｏｎｔｈｌｙ ｓｔａｔｅｍｅｎｔ）を含むことが出来るように、多数のユーザーからの多数の購入要求が該購入要求処理流れ２００を通して同時に処理されてもよいことを述べておく。
【０１２３】
図４は、本発明の、代わりの取引経路を含む購入要求過程流れ４００用のブロック線図である。該過程流れ４００はブロック４０２で始まるが、そこで購入要求が製品及びサービス用に受領される。ブロック４０４へ移り進むと、購入要求は処理され、肯定的又は否定的承認応答が完了する。ここで論じる様に、ブロック４０２での該購入要求は、特定ベンダーからの特定価格での製品又はサービス用の特定要求から或る指定されたニーヅを充たすため使用されるべき或る金額に対する一般的要求まで、広い種類のフオームを取ってもよい。翻って、ブロック４０４での該承認処理はこれらの広く変化する要求を考慮し、又特殊性で広く変化してもよい応答を提供する。例えば、該承認は特定の価格に対する特定ベンダーからの特定製品又はサービス用の承認から、承認されたニーヅを充たす製品又はサービスの購入用の或る金額の割当についての承認まで、及んでもよい。ブロック４０６で、従来のバイヤーと同様な仕方で作動するバイヤー又はエイジャントは選択し該購入動作を行うバイヤーの典型的役割を行ってもよい。この過程は、何等かの種類の事前選択又は自動製品選択を通るようバイパスされてもよく、或いはそれはもし購入されるべき特定の品物又はサービスを指定することが必要でないなら省略されてもよい。
【０１２４】
決定ブロック４０８はその取引が完了まで如何に処理されるかを決定するため使用される。ブロック４０８で、動的支払いカードが使われる予定であるかどうか決定が行われる。もし該動的支払いカードが利用される予定でなければ、流れはブロック４１８へ進みそこでは注文がベンダーに、例えば、プリントした文書、フアクシミリ送信、電話コール、オンラインアクセス、本人、を通してか、又は何等かの他の望ましい手段により、出される。ブロック４２０で、その製品又はサービスが供給される。ブロック４２２で、インボイスが該ベンダーにより直接送られ、そして幾らか平行して、ブロック４２８で、ユーザーは、該品物又はサービスの受領を検証するよう動作する該製品及びサービスの受領者の職務を行使する。ブロック４２４で、該ユーザーは該購入の種々の側面、例えば、該受領した製品及びサービス、該購入要求、該承認条件、該購入注文、そして該ベンダーからのインボイス、を整合し相関を取る会計的職務を行使する。この点から、ブロック４２６で、何等かの必要な支払いが該ベンダーに対し終了させられるか又は行われてもよい。再びこれらの過程の流れブロックは代表的で、絶対的過程の流れを指定するよう意図されてないことを述べておく。望まれれば、変型が実施されてもよい。
【０１２５】
今戻ってブロック４０８を参照すると、もし動的支払いカードが利用される予定であれば、流れはブロック４１０へ進む。本発明の該動的支払いカードを利用することにより、会社は購入管理が望まれる広範囲の取引を管理してもよい。上記で論じた様に、該動的支払いカードは、各承認された購入要求用の１セットの動的承認パラメーターを含む動的承認パラメーターに付随し得るユニークな支払い識別子を表現する。これらの承認パラメーターは、例えば、承認されたベンダー、ドル量、製品種類、品物の数、購入が行われねばならない日又は時間、又は何等かの他の望まれる承認基準であってもよい。かくして、動的支払いカードを所有する個人により取引が始動されると、該取引の承認は、該カードに付随する承認情報と、該取引が始動されつつある特定の購入要求と、に基づいて制御されてもよい。この仕方で、該購入要求でどんな製品又はサービスが要求されるかに関係なく、そして製品又はサービスが購入される予定の販売チャンネルに関係なく、例えば、ネットワークアクセス可能な規則と過程とを通して、会社又はエンテイテイは購入を管理してもよい。
【０１２６】
ブロック４１０で、該承認パラメーターはカード処理システム内に導入されそして適当な動的支払いカードに付随する。ブロック４１２で、該動的支払いカードのユーザーは、例えば、プリントした文書、フアクシミリ送信、電話コール、オンラインアクセス、直接本人、を通して、又は何等かの他の望ましい手段を通して、供給ベンダーに注文を出す。該動的支払いカードはこの購入で支払いビヒクル（ｐａｙｍｅｎｔ ｖｅｈｉｃｌｅ）として利用される。ブロック４１４で、該製品又はサービスが供給されるが、尤もこの供給は該過程の流れ内のどんな場所で起こってもよく、購入の時に行われる必要はないことを述べておく。ブロック４１６で、該ベンダーは該動的支払いカードに課金（ｃｈａｒｇｅｓ）する。該取引の詳細がその動的支払いカード用の動的承認パラメーターの適当なセットとの相関を取ること（ｃｏｒｒｅｌａｔｉｏｎ）とレビューとの後、該課金が承認されれば、流れはブロック４３２及び４３０への２本の幾分平行な経路に沿って進む。もし該取引が、その購入用の該動的支払いカードに付随する該承認情報に基づき承認されないならば、該過程は非承認の指示に基づきブロック４１７で終了する。
【０１２７】
もし該過程が続くならば、ブロック４２８で、ユーザーは該製品とサービスの受領者の職務を行使し、該製品又はサービスの受領（ｒｅｃｅｉｐｔ）を検証するよう動作する。幾分平行して、ブロック４３２で、カード報告処理は、種々の取引詳細に関する情報、例えば、ベンダー名、ベンダー種類、課金額又は他の取引詳細、を提供する。ブロック４３４でクレデイットバランス（ｃｒｅｄｉｔ ｂａｌａｎｃｅ）はデクレメント（ｄｅｃｒｅｍｅｎｔｅｄ）されてもよい。ブロック４３６で、月毎の明細書（ｓｔａｔｅｍｅｎｔ）又はインボイスが顧客に提供される。これは、例えば、総勘定元帳｛ジーエル（ＧＬ）｝配布を提供する報告又はビジネス文書交換（ｂｕｓｉｎｅｓｓ ｄｏｃｕｍｅｎｔ ｅｘｃｈａｎｇｅ）｛ビーデーエックス（ＢＤＸ）｝を通して行うことが出来る。この月毎明細書は会社又はエンテイテイが連結明細書上にその指定された購入の全てを有するよう、該購入管理システム１００により発生されてもよいことを述べておく。ブロック４３０で、該ユーザーは該購入の種々の側面、例えば、該受領された製品及びサービス、該購入要求、該承認条件、該購入注文、そして該ベンダーからのインボイス、を整合し一致確認する会計的職務を行使してもよい。この点から、又如何なる必要な支払いも該ベンダーに対し最終化されるか又は行われる。再び、これらの過程の流れブロックは表現的なものであり絶対的過程流れを指定するよう意図されてないことを述べておく。望ましい様に変型が実施されてよい。
【０１２８】
図３は、本発明により該購入管理環境１００内へ購入要求として導入される購入要求フオーム３２０用の種々の起こり得る源を表すブロック線図である。製品又はサービスが究極的に購入される該購入要求フオームの源又はマーケットは本発明に対し重要ではないことを述べておく。本発明は望まれる購入用の購入要求が、それが会社購入ポリシー及び規則に従って処理されるように何等かの仕方で該購入管理システム１００内に導入される限り全ての購入の効率的管理と制御を見越している。
【０１２９】
今図３を参照すると、要求フオーム発生又は起源環境３００は購入要求フオーム３２０が発生される又は起こる広い種類の源を含む。一旦購入要求フオームがブロック３２０で発生されるか又は起こると、この購入要求は処理用に該購入管理システム１００内へ導入されてもよい。広い購入用カバレッジ（ｂｒｏａｄ ｐｕｒｃｈａｓｉｎｇ ｃｏｖｅｒａｇｅ）を提供するために、該環境３００はインターネットで可能化されたマーケット及び他のマーケットを含むどんな源からでも起こる購入要求を考慮する。重要なことに、本発明では、一旦購入要求が発生されると、該購入は該購入要求の源に関係なく、管理される。
【０１３０】
描かれた実施例では、インターネットで可能化された又はネットワークアクセス可能なマーケット３１５はマーチャントエイピーアイエス（ｍｅｒｃｈａｎｔ ＡＰＩｓ）｛アップリケーションプログラムインターフエースコマンド（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ ｃｏｍｍａｎｄｓ）｝３１８の様なソフトウエアリンクを通した該購入管理システム１００用購入要求フオームを発生してもよい。この様なネットワーク可能化されたマーケット３１５の例は、ユーザーによる購入用に識別されリスト化されたネットワークアクセス可能な製品及びサービスを提供するカタログ化された売り込み市場（ｃａｔａｌｏｇｕｅｄ ｍａｒｋｅｔｐｌａｃｅｓ）の様な、電子的売り込み市場を含む。これらのカタログ化された売り込み市場は製品及びサービスの１つ以上の個別リスト又はグループ化を有する一般的売り込み市場を含んでもよく、極小ベンダーブランド（ｐａｒｔｉｃｌｅ ｖｅｎｄｏｒ ｂｒａｎｄ）下で提供される製品及びサービスの１つ以上のベンダー固有のリスト又はグループ化を有するブランド型売り込み市場を含んでもよい。カタログ化された売り込み市場は、例えば、”オンラインビジネス購入用の方法とシステム（Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｏｎｌｉｎｅ Ｂｕｓｉｎｅｓｓ Ｐｕｒｃｈａｓｉｎｇ）”の名称の同時係属中の米国特許出願直列番号第０９／４０９，３１６号で論じられている。
【０１３１】
加えて、インターネットマーチャント３１２はマーチャントエイピーアイエス３１８を通して本発明の該購入管理システム１００にリンクされてもよいネットワークアクセス可能な又はインターネットイネーブルドマーケット（Ｉｎｔｅｒｎｅｔ ｅｎａｂｌｅｄ ｍａｒｋｅｔｓ）を提供する。なお更に、従来のインターネットイネーブルドでないマーチャント３１４が追加的ソフトウエア及びエイピーアイエスを通してリンクされてもよい。この様なインターネットイネーブルドでないマーチャントも又インターネットユーザーに利用可能にされてもよいホストされたカタログ（ｈｏｓｔｅｄ ｃａｔａｌｏｇｓ）３１６の使用を通してこれ又リンクされてもよい。要するに、インターネットを通してのアクセスを見越すインターネット可能化されたマーケットはマーチャントエイピーアイエス３１８又は何等かの他の望ましい接続機構を通して該購入管理システム１００へリンクされてもよい。
【０１３２】
これらのインターネット可能化されたマーケット３１５を通しての購入要求の発生に加えて、購入要求はウエブインターフエース３０８を含む、他の源又はマーケット３０５から発生されてもよい。他のマーケット３０５の例は、例えば、ユーザー発生された購入要求及び自由フオームテキストエントリー（ｆｒｅｅ ｆｏｒｍ ｔｅｘｔ ｅｎｔｒｙ）を通して創られた要求を含むことが出来るオープンな要求３０２である。これらの要求は予め規定されたフオームを取る必要はなく、該ウエブインターフエース３０８を通してユーザーにより発生されてもよい。加えて、ユーザー用の誂えられたカタログ（ｕｓｅｒ−ｃｕｓｔｏｍｉｚｅｄ ｃａｔａｌｏｇｓ）３０４が該ウエブインターフエース３０８を通して購入要求を発生するため利用されてもよい。又ベンダー又はサプライヤーは、ユーザーがブロック３２０用に購入要求を発生するためにサプライヤーインターフエースを簡単に使用してもよいように、購入要求フオームがその顧客用に提供されるサプライヤーインターフエース３０６を提供してもよい。該開いた要求ブロック（ｏｐｅｎ ｒｅｑｕｅｓｔ ｂｌｏｃｋ）３０２，誂えカタログブロック３０４そしてサプライヤーインターフエースブロック３０６は購入要求用の他の源の例を表すに過ぎず、排他的なグループであると取られるべきでないことを述べておく。更に、購入要求は、本発明に依る、購入管理システム１００内への究極の導入用に、電話コールそしてフアクシミリ送信の様な、ウエブインターフエース３０８の他の手段を通して発生されてもよいことを述べておく。
【０１３３】
要するに、購入管理システム１００に導入するために購入要求が発生される仕方は、購入要求が該購入管理システム１００により処理される何等かのフオームで発生される限り、重要ではない。一旦該購入管理システム１００内では、その源に無関係に、該購入要求は本発明により効率的に管理される。
【０１３４】
［会社例−エイシーエムイーロケット製品（ＡＣＭＥ Ｒｏｃｋｅｔ Ｐｒｏｄｕｃｔｓ）］
更に進んで本発明を説明するために、架空会社（ｆｉｃｔｉｔｉｏｕｓ ｃｏｍｐａｎｙ）用に下記の会社例（ＣＯＭＰＡＮＹ ＥＸＡＭＰＬＥ）が提供される。この会社用の架空従業員は表２で識別される。これらの従業員は該会社内で種々の職務を行い、それらの職務に付随する付随支出ニーヅを有する。最後に、本発明の該動的支払いカード管理システム用の例を更に提供するために図６Ａ、図６Ｂ、図７Ａそして図７Ｂと一緒に、多数の取引例が提供される。下記のこの会社例用に、エイシーエムイーロケット製品（ＡＣＭＥ Ｒｏｃｋｅｔ Ｐｒｏｄｕｃｔｓ）｛エイシーエムイー（ＡＣＭＥ）｝と呼ばれる架空会社とパートナー銀行（Ｐａｒｔｎｅｒ Ｂａｎｋ）と呼ばれる架空金融機関とが利用される。
【０１３５】
エイシーエムイーは３００人の会社（３００−ｐｅｒｓｏｎ ｃｏｍｐａｎｙ）であり、それに限定されないが、技術製品、オフイス製品、産業製品、そして出張及び接待（ｔｒａｖｅｌ ａｎｄ ｅｎｔｅｒｔａｉｎｍｅｎｔ）｛テーアンドイー（Ｔ＆Ｅ）｝を含む種々の間接的及び直接的ニーヅを有する。直接的支出は、品物の生産用に必要な原材料又は部品のための費用の様な、直接的会社費用に差し向けるため使用されることが多い。間接的支出は、出張及び接待費用、産業用サプライ、コンピユータシステム、オフイスサプライそして他の間接的費用の様な、非直接的会社費用に差し向けるために使用されることが多い。パートナー銀行は恐らく商業的カードプログラムを発行する能力を有している。又パートナー銀行は該動的支払いカード管理システムのプロバイダーによりその支払いカード顧客へプラットフオームのサービスを売る又は提供することを許されている。パートナー銀行とのそれらの関係を通して、エイシーエムイーは該購入管理システム１００と連携して該動的支払いカードを使用することを選んだ。エイシーエムイーはパートナー銀行との相互作用を通して動的支払いカードを用いた購入管理システム１００を取り入れ、そしてパートナー銀行はエイシーエムイー用に、会社請求書作成（ｃｏｍｐａｎｙ ｂｉｌｌｉｎｇ）と共に、動的支払いカードプログラムを確立した。下記例では、該動的支払いカード｛デーピーシー（ＤＰＣ）｝の制御用に利用された主要な特徴は、それに限定されないが、ベロシテイ設定、取引サイズ設定、エスアイシーエス（ＳＩＣｓ）｛標準作業コード（Ｓｔａｎｄａｒｄ Ｉｎｄｕｓｔｒｉａｌ Ｃｏｄｅｓ）｝又はエムシーシーエス（ＭＣＣｓ）｛マーチャントカテゴリーコード（Ｍｅｒｃｈａｎｔ Ｃａｔｅｇｏｒｙ Ｃｏｄｅｓ）｝、そしてクレデイットリミットを含む。上記で示される様に、ベロシテイは支出を抑制するための利用性制御（ａｖａｉｌａｂｉｌｉｔｙ ｃｏｎｔｒｏｌ）を表し、そしてベロシテイは典型的にドルと取引数（ｄｏｌｌａｒｓ ａｎｄ ｎｕｍｂｅｒｓ ｏｆ ｔｒａｎｓａｃｔｉｏｎｓ）で記述され、期間により指定されるか又は該カードの寿命に亘り合計されることが出来る。
【０１３６】
エイシーエムイーロケット製品のプロフアイル−エイシーエムイーのリスクのプロフアイルの評価では、パートナー銀行はエイシーエムイーの動的支払いカードプログラム用のマスタークレデイットリミット（ｍａｓｔｅｒ ｃｒｅｄｉｔ ｌｉｍｉｔ）を２００、０００ドルであると設定した。エイシーエムイーのシーエフオー（ＣＦＯ）のフランフアイナンス（Ｆｒａｎ Ｆｉｎａｎｃｅ）は該会社用の一般的購入ポリシーと或るキー職務（ｋｅｙ ｒｏｌｅｓ）用の個別的ポリシーを設定した。これらのポリシーの幾つかを図解するために、下記表２の”ポリシー制御（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ）”部分の下に例が示される。表２は、フランフアイナンスのポリシーに従って下記ユーザーの各々に適用されたポリシーと初期動的支払いカードパラメーターを示す。表２及び下記で識別される該エスアイシーコードは又エムエムシーコード又は利用されるよう望まれる何等かの他のマーチャント識別子（ｍｅｒｃｈａｎｔ ｉｄｅｎｔｉｆｉｅｒｓ）とすることも出来ることを述べておく。上記で述べた様に、表２はスロット毎ベースで、ベロシテイの様な、幾つかの制御設定の管理を提供するが、これらの制御設定は又カード毎レベルで管理されることも出来る。
【０１３７】
ユーザーメリーマーケッテング（Ｍａｒｙ Ｍａｒｋｅｔｉｎｇ）のプロフアイル−メリーはマーケテング部門のメンバーである。メリーは予測出来る支出ニーヅを有しない。メリーの購入の全てはエイシーエムイーのマーケッテング部門副社長（ＡＣＭＥ’ｓ ＶＰ ｏｆ Ｍａｒｋｅｔｉｎｇ）による事前の承認を有さねばならない。
【０１３８】
ユーザーアンアドミン（Ａｎｎ Ａｄｍｉｎ）のプロフアイル−アンはアドミニストレーテイブアシスタント（ａｄｍｉｎｉｓｔｒａｔｉｖｅ ａｓｓｉｓｔａｎｔ）であり、ケイターリングされた（ｃａｔｅｒｅｄ）ランチミーテング用に規則的に配備し、それらの支出用に月当たり３００ドルの予算を割り当てられている。
【０１３９】
ユーザートムテクノロジー（Ｔｏｍ Ｔｅｃｈｎｏｌｏｇｙ）のプロフアイル−トムはエイシーエムイー用のアイテーバイヤー（ＩＴ Ｂｕｙｅｒ）である。彼はエイシーエムイー組織内の全てのアイテー購入（ＩＴ ｐｕｒｃｈａｓｅｓ）に責任がある。トムは５、０００ドル以下のインクレメント（ｉｎｃｒｅｍｅｎｔ）で技術製品について月当たり自由裁量で２０、０００ドル支出（ｓｐｅｎｄ ａ ｄｉｓｃｒｅｔｉｏｎａｒｙ ＄２０，０００ ｐｅｒ ｍｏｎｔｈ）することをエイシーエムイーのシーエフオーによりオーソライズされている。これらの購入は毎月末にトムにより弁明され一致確認されねばならない。５、０００ドルを超えるどんな個別購入も、又は２０、０００ドルを超える月当たり合計支出も、該シーエフオーによる事前承認（ｐｒｉｏｒ ａｐｐｒｏｖａｌ）を要する。非技術的購入はトムのスーパーバイザー（ｓｕｐｅｒｖｉｓｏｒ）による事前承認を要する。
【０１４０】
ユーザーサムショップフロアー（Ｓａｍ Ｓｈｏｐｆｌｏｏｒ）のプロフアイル−サムはショップフロアー用設備技術者である。サムは一般に購入に参画しないが、製造機器の危機的停止時の場合（ｉｎ ｔｈｅ ｃａｓｅ ｏｆ ｃｒｉｔｉｃａｌ ｄｏｗｎｔｉｍｅ ｏｆ ｍａｎｕｆａｃｔｕｒｉｎｇ ｅｑｕｉｐｍｅｎｔ）緊急購入を行うためシーエフオーの承認権（ａｐｐｒｏｖａｌ）を有する。該シーエフオーは該プラントを持続し運転して保つために１０、０００ドルまでの緊急費用（ｅｍｅｒｇｅｎｃｙ ｅｘｐｅｎｄｉｔｕｒｅｓ）を使うことをサムにオーソライズしている。これらの緊急費用は２４時間以内に弁明されねばならない。全ての他の費用はそれらが使われ得る前に予め承認されねばならない。
【０１４１】
ユーザーサリーセール（Ｓａｌｌｙ Ｓａｌｅｓ）のプロフアイル−サリーはレギュラーベースで出張及び接待の費用をこうむる（ｉｎｃｕｒｓ）セールス役員（ｓａｌｅｓ ｅｘｅｃｕｔｉｖｅ）である。サリーは承認を要するテーアンドイー（Ｔ＆Ｅ）カテゴリーの外部購入要求（ｐｕｒｃｈａｓｅ ｒｅｑｕｅｓｔｓ ｏｕｔｓｉｄｅ）を定期的に行う。
【０１４２】
【表２】
2004519773.tif 000004
【０１４３】
【表３】
2004519773.tif 000005
【０１４４】
【表４】
2004519773.tif 000006
【０１４５】
カードプロセサーでのこれらの初期設定を構成するために、該購入管理システム１００により該カード処理システム１３０への適当な関数コール（ｆｕｎｃｔｉｏｎ ｃａｌｌ）が行われることが出来る。例えば、上記で論じた該テーワイテーエス処理プラットフオームインターフエースを用いて、管理及び制御コマンドが利用されてもよい。
【０１４６】
表２で表明されたエイシーエムイーロケット用ユーザー例を用いて、これらのユーザーの各々用に１セットのサンプル取引シナリオが動的支払いカード管理動作と一緒に下記で論じられる。カード発行の様な技術的インターフエース及び該購入カードプロセサーから来る報告はテーエスワイエスの様なカードプロセサーが今日銀行に提供するカード処理機能と同様であってもよい。これらの技術的インターフエースはそれぞれのカードプロセサーを利用する人により公知であり、ここでは繰り返されない。
【０１４７】
取引シナリオ例１Ａ−アンアドミン
アンアドミンはランチミーテングをサポートするために地域のデリー（ｌｏｃａｌ ｄｅｌｉ）からのサンドウイッチのトレーを注文する必要がある。アンは該デリーをコールし、３４．５９ドルの合計となる注文を行い、該デリーに彼女の動的支払いカード番号を与える。該デリーはアンの動的支払いカードに課金し、それに対し該カードプロセサーはスロット１で充分なクレデイットと利用可能なベロシテイとを見出し、そして該デリーは該カードに課金（ｃｈａｒｇｅｓ）し、該サンドウイッチを配送する。
【０１４８】
該カードプロセサーがその処理を行う時、該購入管理システム１００はこの取引を通知される。対応する購入要求がないので、該購入管理システム１００はアン用の購入要求を合成し、エイシーエムイーの会計システム内での後刻の一致確認用に該取引情報を該合成された購入要求に取付る。
【０１４９】
該購入管理システム１００は、例えば、イーメール（ｅ−ｍａｉｌ）により、該取引が完了したことをアンに通知し、そして該取引用の弁明（もし該会社により要求されるなら）、追加的取引詳細、会計又はジーエルコーデング、又は何等かの他の望まれる又は要求される情報を追加するために該購入管理システム１００内へのエイチテーエムエルハイパーリンク（ＨＴＭＬ ｈｙｐｅｒ−ｌｉｎｋ）を彼女に提供出来る。又この通知はアンにその請求作業周期中の彼女の残っている食料サービス予算（ｆｏｏｄ ｓｅｒｖｉｃｅ ｂｕｄｇｅｔ）を知らせる。次ぎに、この支払い品目は該購入管理システム１００を経由してエイシーエムイーの会計システム内に流れ、エイシーエムイーがそれらのステートメントをパートナー銀行から受けるとこの課金が現れ、一致確認される。
【０１５０】
図６Ａはこの取引例用の取引処理を更に説明するグラフ描画を提供する。特に、図６Ａは動的支払いカード処理用の流れ線図６００であり、そこではユーザーは承認された製品カテゴリーに属すると期待される購入を始動する。ブロック６０２で、顧客（又はユーザー）はマーチャント（又はベンダー）へ注文を通信する。ブロック６０５で、該顧客は該注文用の支払いとして動的支払いカード｛デーピーシー（ＤＰＣ）｝を提示する。この取引注文と支払い提示は、本人接触注文及び支払い（ｉｎ−ｐｅｒｓｏｎ ｏｒｄｅｒ ａｎｄ ｐａｙｍｅｎｔ）、遠隔注文と本人接触支払い（ｒｅｍｏｔｅ ｏｒｄｅｒ ａｎｄ ｉｎ−ｐｅｒｓｏｎ ｐａｙｍｅｎｔ）、又は何等かの他の望まれる仕方を含む種々の仕方のどれで行われてもよいことを述べておく。又この取引を図５Ｂに関係付けて、該承認過程流れは逆方向流れ経路５５６に付随させられるであろうがそれは該ユーザー又は顧客が購入要求を最初に発生させることなく進んだからであることを述べておく。承認処理は取引後、例えば、購入要求合成を通して、起こることが期待されるであろう。
【０１５１】
マーチャントはブロック６０４で該注文を受領し、ブロック６０６でカードプロセサーと通信する。決定ブロック６０８で、該カードプロセサーは、承認に関する決定を行うために該カード設定を見る。示された該例では、該カードプロセサーは該始動された購入に付随するエスアイシー用にクレデイット及びベロシテイ設定を見る。もし該取引がこれらの設定内に属しないならば、該始動された取引はブロック６１０で辞退される（ｄｅｃｌｉｎｅｄ）。もし該取引が該設定内に属するなら、該取引は該カードプロセサーによりオーソライズされる。
【０１５２】
次ぎに、ブロック６１２で、該マーチャントは支払いを受入れ、該製品を配送するか又は該製品の配送に立ち会う。次いで該カードプロセサーは該取引がブロック６１４で完了した指示を受ける。ブロック６１６で、該カードプロセサーは該購入管理（ピーエム）システム１００に該取引を通知する。ブロック６２４で、該顧客は該ピーエムシステム１００を通して該取引が行われたことを通知される。
【０１５３】
又該ピーエムシステム１００はブロック６１８で該取引用の購入要求と購入注文を合成出来る。該始動された取引は、該カードが予め承認された支出能力を有したように、アンを或るサービス用のバイヤー役割としてセットアップするカード設定を利用するので、該取引の前に承認された購入要求はない。会計及び承認目的では、購入注文と要求がこの取引用に発生されるのが有利である。この様であるから、該ピーエムシステム１００は該カードプロセサー１３０から受けた取引データから購入要求と注文を合成する。かくして、もし望まれるなら、購入ポリシー規則は取引後に適用され得る（ｂｅ ａｐｐｌｉｅｄ， ｉｆ ｄｅｓｉｒｅｄ， ｐｏｓｔ−ｔｒａｎｓａｃｔｉｏｎ）。最後に、図６Ａのブロック６２０で、該ピーエムシステム１００は該注文を追跡し、取引詳細を報告し、そしてどんな他の望まれるステイタス又は取引情報も提供出来る。次いで、該ピーエムシステム１００は、ブロック６２２で、該顧客の会計システム内への支払い品目流れ（ｐａｙａｂｌｅ ｉｔｅｍｓ ｆｌｏｗ ｉｎｔｏ ｔｈｅ ｃｕｓｔｏｍｅｒ’ｓ ａｃｃｏｕｎｔｉｎｇ ｓｙｓｔｅｍ）を有し得る。該顧客は次いで該カード発行者へ支払いを行ってもよい。
【０１５４】
取引シナリオ例１Ｂ−アンアドミン
アンアドミンは該エイシーエムイーの取締役会議（ｂｏａｒｄ ｍｅｅｔｉｎｇ）用に別のランチを注文する必要がある。この例でアンはこの購入をカバーするために充分な、彼女の月当たり食料予算の残り、を有しない。アンは次の弁明、すなわち”フランさん、これらの顧客の全部の訪問で忙しい月だったので私のケイターリング予算を殆ど使い果たしています。その取締役会議用ランチに関し追加の１００ドルを支出するためあなたの承認を必要とします。深謝、アン”、で承認を要求する購入要求を該購入管理システム１００内で創る。
【０１５５】
フランはこの要求を承認しそして、承認後、該購入管理システム１００はアンの動的支払いカードのスロット１の利用可能ベロシテイをチェックし、彼女が食料サービス用の３７．８９ドルの利用可能ベロシテイを有することを見出す。該購入管理システム１００はアンの動的支払いカードの利用可能ベロシテイを１００ドルだけ増加する（その月用に合計４００ドルまで）。
【０１５６】
この設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得て、それらの設定を更新するために管理及び制御パケット（ｍａｎａｇｅｍｅｎｔ ａｎｄ ｃｏｎｔｒｏｌ ｐａｃｋｅｔｓ）が使用され得る。
【０１５７】
アンは彼女の要求が承認され、彼女の動的支払いカードが特別の１００ドル用について利用可能にされたことを知る。アンは該ケイターリング者に注文する。ランチは配送され、該ケーターリング者は８７．５０ドルをアンの動的支払いカードに課金する。該カードプロセサーはこの取引をカバーするためにアンの動的支払いカードのスロット１に利用可能なベロシテイがあることを判定するので、該取引は成功する。アンの動的支払いカードは８７．５０ドルを課金され、５０．３９ドルの彼女の残りのベロシテイは該周期の残り用に残される。
【０１５８】
該カードプロセサーがその処理を行う時、該購入管理システム１００はこの取引を通知され、そしてエイシーエムイーの会計システム内の後刻の一致確認用にアンの購入要求に該取引情報を取り付けそして／又は該取引情報は将来の整合と一致確認活動用にアンの支払いカードと相関が取られ得る。該購入管理システム１００は、該取引が完了したことをアンに通知し、そして該会社の購入ポリシーにより推進されたものとしてのこの購入へのフオローアップ活動用に該購入管理システム１００内へのエイチテーエムエルハイパーリンクを彼女に提供するであろう。
【０１５９】
次ぎに、この支払い品目は該購入管理システム１００を経由してエイシーエムイー内の会計システム内に流れ、エイシーエムイーがパートナー銀行からそれらのステートメントを受ける時、この課金は現れ、一致確認される。該請求作業周期の終わりで、該購入管理システム１００はアンの動的支払いカード上のスロット１のベロシテイを３００ドルにリセットする。支払いカード制御設定のこのリセットは望まれる様に該過程の他の点で行われてもよいことを再び述べておく。
【０１６０】
再び、これらの設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得てそれらの設定を変更するために管理及び制御パケットが使用され得る。加えて、該ベロシテイ設定への調整及び再調整が必要でなくなるように自動調整がベロシテイ発生を低減可能にする様な関数が該カードプロセサーにより提供されることが可能である。この関数コールは、例えば、現在のベロシテイ設定下であき高（ｈｅａｄｒｏｏｍ）を有効に創り該ベロシテイが該周期の終わりで３００ドルまで下げて再調整される必要を無くする。
【０１６１】
図６はこの取引例のシナリオに関係する取引処理を更に説明するグラフイック描画を提供する。特に、図６Ｂは、ユーザーが該購入管理システムにより処理された購入要求に基づく又は承認された製品カテゴリーに属すると期待される購入要求に基づく、購入を始動する動的支払いカード処理の流れ線図６５０である。図６Ｂは、要求／注文合成用ブロック６１８が簡単化のため処理流れ６５０の外に残されているが、多くの点で図６Ａと似ている。追加的処理として、該ピーエムシステム１００を通しての購入要求がカード承認を得るための機構であることを可能にするブロックがある。従って、この取引を図５Ｂに関係付けて、該承認過程流れは、ユーザーがカードを如何に使用したかに依り順方向流れ経路５５４又は逆方向流れ経路５５６の何れかに付随する。もし事前取引購入要求（ｐｒｅ−ｔｒａｎｓａｃｔｉｏｎ ｐｕｒｃｈａｓｅ ｒｅｑｕｅｓｔ）が利用されるならば、承認は該取引の前に起こると期待される。もし、図６Ａに於ける様に、予め承認された支出用オーソリテイが利用されるならば、承認処理は、例えば、購入要求合成を通して取引後に起こると期待される。
【０１６２】
特に、ブロック６５２で、顧客は、上記で説明された様に、該ピーエムシステム１００内の要求フオームを書き込む（ｆｉｌｌｓ ｏｕｔ）。この購入要求は会社によりセットアップされた適当な購入ポリシーに依り該ピーエムシステム１００によりブロック６５４で処理される。ブロック６５８では、該要求を承認するか又は承認しないか決定が行われる。もし該要求が承認されないならば、該ピーエムシステム１００は該要求が承認過程により辞退されたことをブロック６５５で顧客へ返事する通信を行う。もし該要求が承認されるなら、該ピーエムシステム１００は、該取引が実際処理される時、該カード設定へのどの様な更新が該取引をカードプロセサー１３０により承認されさせるかを自動的に判定する。図６Ｂで、この設定はブロック６６０の”ベロシテイ”設定として描かれるのは、それがアンにより要求された購入が起こることを可能にするものだからである。このカード設定ブロック６６２のカードプロセサーで提供され、該カードプロセサーは次いでブロック６６４で適当な動的支払いカード｛デーピーシー（ＤＰＣ）｝への該ベロシテイ設定を追加又は更新する。
【０１６３】
取引シナリオ例２−メリーマーケッテング
メリーマーケッテングは来るべきトレードショー用の会社コーラテラルの印刷作業を行う必要がある（ｎｅｅｄｓ ｔｏ ｇｅｔ ａ ｐｒｉｎｔ ｒｕｎ ｏｆ ｃｏｍｐａｎｙ ｃｏｌｌａｔｅｒａｌ）。メリーは会社がロケットエクスポトレードショー（Ｒｏｃｋｅｔ Ｅｘｐｏ ｔｒａｄｅｓｈｏｗ）に参加することを知らされており、該ショーの会社ブース用のコーラテラル材料（ｃｏｌｌａｔｅｒａｌ ｍａｔｅｒｉａｌｓ）を得るよう課されている。メリーは彼女が要する印刷作業の規模と運送を含むコストが１、５００ドルであろうと判定した。メリーは購入管理システム１００内で購入要求を創りそれを承認用に提出する。この要求は該会社の購入ポリシーに対し検証（ｖａｌｉｄａｔｅｄ）され、彼女がマーケッテング担当副社長から承認を必要とすること決定された。マーケッテング担当副社長は、例えば、イーメール又は電話コールを通して、彼が承認すべき購入要求を有することを直ちに知らされそしてこの購入を承認する。
【０１６４】
この購入要求の承認後、該購入管理システム１００はメリーの動的支払いカードの合計カードレベルベロシテイを１取引及び１、５００ドルだけ増加させる。
【０１６５】
再び、これらの設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得てそれらの設定を更新するために管理及び制御パケットが使用され得る。
【０１６６】
メリーは彼女の要求が承認されたことそして彼女の動的支払いカードが１、５００ドル購入について可能にされたことを知らされる。メリーはサプライヤーに注文し支払い用に彼女の動的支払いカードを使用する。該コーラテラルは印刷され運送され、メリーの動的支払いカードは１５００ドルを課金される。
【０１６７】
該カードプロセサーがその処理を行うと、該購入管理システム１００は、この取引を通知され、そしてエイシーエムイーの会計システム内の後刻の一致確認用にメリーの購入要求へ該取引情報を付帯させそして／又は将来の整合と一致確認活動用に該取引情報のメリーの支払いカードとの相関を取る。該購入管理システム１００は、メリーに該取引が完了したことを通知し、そして該会社の購入ポリシーにより推進されたものとしてのこの購入へのフオローアップ活動用に該購入管理システム１００内へのエイチテーエムエルハイパーリンクを彼女に提供するであろう。例えば、該会社は該リクエスターが１０００ドルを超える全ての購入品の受領を確認することを要求してもよい。
【０１６８】
次ぎにこの支払われる品目は該購入管理システム１００を経由してエイシーエムイーの会計システム内へ流れ、エイシーエムイーがパートナー銀行からそれらのステートメントを受けるとこの課金は現れ一致確認される。
【０１６９】
図６Ｂは又メリーマーケッテング用のこの例で論じられた取引の種類で起こる動的支払いカード処理例を提供する。
【０１７０】
取引シナリオ例３Ａ−トムテクノロジー
トムテクノロジーは新しく雇ったエンジニア用の新コンピユータシステムを購入する必要がある。トムは、前の購入から彼の動的支払いカード番号で既にセットアップされている彼のデルプレミアページ（Ｄｅｌｌ Ｐｒｅｍｉｅｒ Ｐａｇｅ）へ行き、合計２、１５９ドルとなる注文を行いそしてチェックアウト（ｃｈｅｃｋｓ ｏｕｔ）する。デルはトムの動的支払いカード上でオーソライゼーションを行い該カードプロセサーはトムの動的支払いカード上のスロット１のデルのエスアイシーコード用に利用可能な充分なクレデイットを、そしてこの取引がスロット１上で許される最大ドル量内にあることを見出す。そこでデルのオーソライゼーションはトムの動的支払いカードのスロット１に対し成功する。デルは該ピーシー（ＰＣ）を作りトムへ輸送しそしてトムの動的支払いカードからフアンドを取り込む。
【０１７１】
該カードプロセサーがその処理を行うと、該購入管理システム１００はこの取引を知らされる。対応する購入要求が無いので、該購入管理システム１００はトム用の購入要求を合成し、エイシーエムイーの会計システム内の後刻の一致確認用に該取引情報を該合成された購入要求に付加する。該購入管理システム１００は、トムに該取引が完了したことを知らせるであろう、そしてその取引に弁明（会社により要求されるなら）と受領の確認とを付加するために該購入管理システム１００内へのエイチテーエムエルハイパーリンクを彼に提供するであろう。又このイーメールはトムにその請求作業周期の間の彼の残っている技術予算を知らせてもよい。
【０１７２】
次ぎに、この支払い品目は該購入管理システム１００を経由してエイシーエムイーの会計システム内に流れそしてエイシーエムイーがパートナー銀行からそれらのステートメントを受けた時、この課金が現れ、一致確認される。
【０１７３】
図６Ａは又トムテクノロジー用のこの例で論じられた取引の種類で起こる動的支払いカード処理例を提供する。
【０１７４】
取引シナリオ例３Ｂ−トムテクノロジー
トムテクノロジーは破裂した水道管がそのセンター内の非常に高価なサーバーを破壊したのを見出した。トムは前の購入から彼の動的支払いカード番号で既にセットアップされた彼のデルプレミアページへ行き、そして合計２８、２８８ドルになる注文を構成する。トムは事前承認無しの彼の最大購入は５、０００ドルであることを知っている。そこで、トムは該購入管理システム１００内で購入要求を創り、それに緊急（Ｕｒｇｅｎｔ）のマーク付けしそして次の弁明を含める、すなわち”フランさん、我々のデルのサーバーが、我々のデータセンターの直上に配置された水道ライン破裂により破壊された。私は該デルのウエブサイトでの交換を構成し、彼等は２４時間内にそれをここに備えることが出来る。２８、２８８ドルを支出するためのあなたの承認を必要とする。トム。”
トムの要求は緊急とマーク付けされているので、該購入管理システム１００はテキストページを送ることが出来てそして／又はフランにコールし緊急の要求が該購入管理システム１００内で彼女を待っていることを彼女に知らせることが出来る。フランは新サーバーが唯一の回答かどうかを知るために技術担当副社長、ドナデベロップメント（Ｄｏｎｎａ Ｄｅｖｅｌｏｐｍｅｎｔ）へコールする。ドナは新サーバー無しでは該ガイダンスシステム（ｇｕｉｄａｎｃｅ ｓｙｓｔｅｍｓ）が該新ロケット上で働いているかどうかを検証することは不可能であることをフランに説明する。フランは次ぎにこの要求を承認しそして承認後該購入管理システム１００はトムの動的支払いカード上の該スロット１のベロシテイと最大取引量を該２８、２８８ドルの購入をカバーするよう増加する。
【０１７５】
再び、これらの設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得てそれらの設定を更新するために管理及び制御パケットが使用され得る。
【０１７６】
トムは彼の要求が承認されそして彼の動的支払いカードが２８、２８８ドルの購入用に可能にされたことを知らされる。トムはデルのサイトに戻り、該チェックアウト過程（ｃｈｅｃｋｏｕｔ ｐｒｏｃｅｓｓ）を完了する。デルは該サーバーを作り、それをトムへ輸送する。デルはスロット１に充分なベロシテイと利用可能なクレデイットとを有するトムの動的支払いカードへ課金する。該カードプロセサーがその処理を行うと、該購入管理システム１００はこの取引を知らされ、そしてエイシーエムイー内会計システム内の後刻の一致確認用にトムの購入要求に取引情報を付加しそして／又は将来の整合及び一致確認活動用に該取引情報とメリーの支払いカードとの相関を取る。この取引が完了したことを知らされると該購入管理システムはトムの動的支払いカードのスロット１の最大取引量を５、０００ドルにリセットする。
【０１７７】
該購入管理システム１００は、トムに該取引が成功したことを通知するであろう、そして該サーバーの受領を確認応答するために該購入管理システム１００内へのエイチテーエムエルハイパーリンクを彼に提供するであろう。又この通知はトムにその請求作業周期期間の彼の残りの技術予算を知らせる。次ぎにこの支払い品目は該購入管理システム１００経由でエイシーエムイーの会計システム内に流れ、エイシーエムイーがパートナー銀行からこれらのステートメントを受けるとこの課金が現れ、一致確認される。該請求作業周期の終わりで、該購入管理システム１００はトムの動的支払いカードのスロット１の月当たりベロシテイを２０、０００ドルにリセットする。支払いカード制御設定のこのリセット作業は望まれる該過程の他の点で行われてもよいことを述べておく。
【０１７８】
加えて、該購入管理システム１００がトムの動的支払いカード上の現在のクレデイットリミットを行われつつある購入の規模と比較出来るようにして、従って該クレデイットリミットを増加することを、可能にするために該カードプロセサーにより関数が提供され得る。クレデイットリミット修正に付随するリスクのために、クレデイットリミットが該カード発行者により提供されたアロワンス（ａｌｌｏｗａｎｃｅｓ）を超えて増加されないことを保証するために安全対策が設置されるよう設定され得る。このクレデイットリミット修正はより効率的管理能力を見越している。
【０１７９】
図６Ｂは又、トムテクノロジー用のこの例で論じられた取引の種類で起こる動的支払いカード処理の例を提供する。
【０１８０】
取引シナリオ例４Ａ−サムショップフロアー
積載ドック用頭上ドア（ｏｖｅｒｈｅａｄ ｄｏｏｒ ｆｏｒ ｔｈｅ ｌｏａｄｉｎｇ ｄｅｃｋ）の上に機械的故障があり、ロケットに生産ライン上でバックアップ（ｂａｃｋ ｕｐ）させている。サムショップフロアーはコールされ、その問題を一見し、修理には該ドア上のベルト駆動用の新モーターを要することを判断した。サムは彼が緊急支出能力を有することを知っているので、彼は彼のローカルなグレインジャー産業サプライ支店（Ｇｒａｉｎｇｅｒ Ｉｎｄｕｓｔｒｉａｌ Ｓｕｐｐｌｙ ｂｒａｎｃｈ）をコールし、留め置きデスク（ｗｉｌｌ−ｃａｌｌ ｄｅｓｋ）にモーターを彼用に彼等に用意させる。サムはグレインジャー支店までドライブし、７８３．８９ドル掛かる該モーターの支払いのために彼の”緊急”動的支払いカード（サム用に発行された特別なカード）を提示する。グレインジャーはサムの動的支払いカードに課金する。グレインジャーのエスアイシーコードはサムの”緊急”カードのスロット１の下にカバーされており、そして該ベロシテイ機構経由で利用可能な取引は１件あるので、該取引は承認される。サムは該モーターを該プラントへ持って帰りそれを設置し、該ドアを固定しそしてその同じ午後該ロケットが出ることを可能にした。
【０１８１】
該カードプロセサーがその処理を行うと、該購入管理システム１００はこの取引を知らされる。対応する購入要求が無いので、該購入管理システム１００はサム用の購入要求を合成し、エイシーエムイー内会計システム内の後刻の一致確認用に該取引情報を該合成された購入要求に付加しそして／又は将来の整合と一致確認活動用に該取引情報をメリーの支払いカードと相関を取る。この購入の緊急性のため、該購入管理システム１００は、サムのカードが取引用の”緊急”モードで使用されたことをサムとフランの両者に知らせそしてその取引に弁明と受領の確認とを付加するために該購入管理システム１００内へのエイチテーエムエルハイパーリンクをサムに提供するだろう。又この通知はサムにその請求作業周期の間の彼の残っている緊急予算を知らせるであろう。次ぎに、この支払い品目は該購入管理システム１００経由でエイシーエムイーの会計システム内へ流れ、そしてエイシーエムイーがパートナー銀行からそれらのステートメントを受領する時この課金が現れ、一致確認される。
【０１８２】
図６Ａは又サムショップフロアー用のこの例で論じた取引の種類で起こるであろう動的支払いカード処理例を提供する。
【０１８３】
取引シナリオ例４Ｂ−サムショップフロアー
サムショップフロアーはそのショップフロアーで使用される空圧式ツール用ホースの幾つかが使い古して割れていることに気付いている。サムはそれらが恐らく交換される必要ありと決めた。サムはオンラインでグレインジャーコム（Ｇｒａｉｎｇｅｒ．ｃｏｍ）へ行き、交換ホースが各々１５０．８０ドルであることを判断した。サムはこれらのホースの３つを彼のカート内に載せ、チェックアウトページ（ｃｈｅｃｋｏｕｔ ｐａｇｅ）に進みそこで該グレインジャーコムサイトは税金と運送費を含む合計価格が４９８．７６ドルであることを彼に知らせる。サムは該購入管理システム１００内で購入要求を創り、それを承認を求め提出する。
【０１８４】
フランはもし適当なコストセンター内に残っている部門予算があれば５００ドルより低い購入を自動承認する承認ポリシーを設定して来た。該購入管理システム１００はその設備予算に充分なあき高があり、それは５００ドルより低くそしてこの購入を自動承認することを決定する。この購入要求を承認すると、該購入管理システムはサムの第１動的支払いカードのスロット１で合計ベロシテイを１取引と４９８．７６ドルだけ増加する。
【０１８５】
再び、これらの設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得てそれらの設定を更新するために管理及び制御パケットが使用され得る。
【０１８６】
サムは彼の要求が承認されたことそして彼の動的支払いカードが４９８．７６ドルの購入を可能にされたことを知る。サムはグレインジャーコムに戻り彼の動的支払いカードでチェックアウトを終わる。グレインジャーからの課金はサムの動的支払いカードに対し処理され、該カードプロセサーはサムの第１勘定のスロット１のこの購入に利用可能なベロシテイがあることを判定する。それでこの取引はこの勘定に対し成功する。グレインジャーはこの注文を充たし、それをサムへ出荷する。
【０１８７】
該カードプロセサーがその処理を行う翌夕に、該購入管理システム１００はこの取引を知らされ、そしてエイシーエムイーの会計システム内の後刻の一致確認用に該取引情報をサムの購入要求に付加しそして／又は将来の整合と一致確認活動用に該取引情報をメリーの支払いカードと相関を取る。該購入管理システム１００は、彼のカードがこの取引用に使用されたことをサムに知らせ、そして該会社の購入ポリシーにより推進されたものとしてのこの購入へのフオローアップ活動用に該購入管理システム１００内へのエイチテーエムエルハイパーリンクを彼に提供するだろう。次ぎに、この支払い品目は該購入管理システム１００経由でエイシーエムイーの会計システム内へ流れ、そしてエイシーエムイーがパートナー銀行からそれらのステートメントを受領する時この課金が現れ、一致確認される。
【０１８８】
図６Ｂは又サムショップフロアー用のこの例で論じられた取引の種類で起こるであろう動的支払いカード処理の例を提供する。
【０１８９】
取引シナリオ例５Ａ−サリーセールス
サリーセールスは彼等の宇宙プログラムでエイシーエムイーのロケットを使用することを考えつつあるカナダ政府へのセールスコール（ｓａｌｅｓ ｃａｌｌ）を行う。サリーは航空運賃、レンタルカー、ホテル、そしてビジネスランチを含め彼女のテーアンドイー支出用に彼女の動的支払いカードを使用する。各々の取引で、該カードプロセサーはサリーのカードのスロット１を検査し、これらのテーアンドイーマーチャントがスロット１のエスアイシーコード範囲によりカバーされることそしてこれらの取引用に充分な利用可能ベロシテイがあることを見出す。
【０１９０】
該カードプロセサーがその処理を行うと、該購入管理システム１００はこの取引を知らされこれらの取引をサリーの動的支払いカードに対しログ（ｌｏｇ）する。各々の取引で、サリーの動的支払いカードのスロット１の利用可能なベロシテイは減じられる。会社ポリシーにより、サリーは彼女の動的支払いカード上で付随したあき高（ｈｅａｄｒｏｏｍ）が復位（ｒｅｉｎｓｔａｔｅｄ）されるようにこれらの取引を弁明し一致確認せねばならない。サリーは彼女のカナダ訪問用の課金の全てを識別し、それらを適切に弁明しそして該購入管理システム１００を経由して承認用に提出する。承認されると、該購入管理システム１００はサリーの動的支払いカードのスロット１の利用可能な合計ベロシテイを該適切な量だけ復位させる。
【０１９１】
再び、これらの設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得てそれらの設定を更新するために管理及び制御パケットが使用され得る。加えて、会社請求されるカード（ｃｏｍｐａｎｙ−ｂｉｌｌｅｄ ｃａｒｄ）に付随しておりそしてそれにも拘わらず個人的に請求される流用勘定（ｄｉｖｅｒｓｉｏｎ ａｃｃｏｕｎｔ）の創生を可能にする関数が該カードプロセサーにより提供される。この会社カード上の個人的流用勘定の特徴は、従業員がそのテーアンドイー課金に責任があるようにテーアンドイー支出が該個人的に請求される流用勘定へ逸らされることを可能にする。この個人的責任は会社によって望まれてもよく、会社カード上に該個人的流用勘定を含めることはユーザーが彼等の会社購入とテーアンドイー購入とのニーヅを充たす単一ピースのプラスチック（ａ ｓｉｎｇｌｅ ｐｉｅｃｅ ｏｆ ｐｌａｓｔｉｃ）を担うことを可能にする。
【０１９２】
図７Ａと７Ｂはこの取引処理を更に説明するグラフイカルな描写を提供する。図７Ａと７Ｂは流用勘定が利用される動的支払いカード処理用の流れ線図７００と７５０とである。図７Ａと７Ｂは、要求／注文合成用ブロック６１８が処理流れ７００外に置かれるけれども、多くの点で図６Ａと似ている。追加的処理として、該ピーエムシステム１００を通しての購入要求が流用勘定扱い機構となることを可能にするブロックが存在する。
【０１９３】
特に、図６Ａに似た図７Ａを見ると、購入されつつある製品が流用勘定範囲内にあるかどうかを決定するために決定ブロック７０２が追加される。もしブロック７０２の答えが”ノー”ならば、処理はブロック７０４に進み、そこでは該カードプロセサーは該始動された取引がクレデイット及びベロシテイ設定の様なカードパラメーター内に入るかどうかを決定する。もし答えがブロック７０４で”ノー”ならば、該承認はブロック７０６で辞退される。もしブロック７０４の該答えが”イエス”なら、処理流れはブロック７０８に続きそして図７Ｂへ進む。
【０１９４】
戻って決定ブロック７０２を見て、もし該答えが”イエス”なら、処理はブロック６０８へ進み、該流用勘定が利用される。この経路内の他の追加的ブロックは、該取引が該流用勘定に割り当てられることを識別するブロック７１２と、そして該ピーエムシステム１００が該注文データを後刻の使用のためにデータウエアハウス（ｄａｔａ ｗａｒｅｈｏｕｓｅ）へログするブロック７１４と、である。加えて、ブロック７１０は図７Ｂからのエントリー点を提供する。
【０１９５】
図６Ｂと似ている図７Ｂは、購入されつつある該製品が流用勘定範囲内にあるかどうかを決定するため決定７５２を挿入した。もしブロック７５２の答えが”ノー”ならば、処理はブロック６０８へ進みそこで該カードプロセサーは始動された取引が、クレデイット及びベロシテイ設定の様なカードパラメーター内に入るかどうかを決定する。もしブロック６０８の該答えが”ノー”なら、ブロック６１０で承認は辞退される。もしブロック６０８の該答えが”イエス”ならば、処理はブロック６１２へ続く。ブロック７６０が図７Ａからのブロック７０８用のエントリー点を提供することを述べておく。図７Ａから図７Ｂへのこの経路が要求過程を最初に通らないデーピーシーのユーザー用であるので、図６Ａに関して論じた様に合成ブロックが該処理に追加され得る。
【０１９６】
戻って決定ブロック７５２を見て、もし該答えが”イエス”ならば、処理は決定ブロック７５４へ続き、そして流用勘定が利用される。決定ブロック７５４では、該始動された取引が、クレデイット及びベロシテイの様なデーピーシー設定に対し検査される。もし該取引がそれらの設定に従って許された取引外に外れるならば、該取引はブロック７５６で辞退される。もし該取引が許された取引内に入るなら、処理は図７Ａへ、ブロック７５８を通って図７Ａのブロック７１０へ流れる。
【０１９７】
取引シナリオ例５Ｂ−サリーセールス
サリーセールスは地区セールス会議（ｒｅｇｉｏｎａｌ ｓａｌｅｓ ｍｅｅｔｉｎｇ）を計画しつつあり、該地区セールスチーム用に仕立てられた２０のロゴシャツ（ｌｏｇｏ ｓｈｉｒｔｓ ｍａｄｅ ｕｐ ｆｏｒ ｔｈｅ ｒｅｇｉｏｎａｌ ｓａｌｅｓ ｔｅａｍ）を得ようとしている。サリーは縫製会社と接触し、該セールスキックオフ会議（ｓａｌｅｓ ｋｉｃｋ−ｏｆｆ ｍｅｅｔｉｎｇ）用に該セールスチームに彼女が得ようとする該２０のシャツが３７５ドル掛かることを判断した。サリーは該購入管理システム１００内で購入要求を創りそれを承認用に提出する。この要求は該会社の購入ポリシーに対し検証され彼女がセールス担当副社長からの承認を必要とすることが決定される。該セールス担当副社長は直ちに彼女が承認すべき購入要求を有することを知らされ、この要求を承認する。この購入要求が承認されると、該購入管理システム１００はサリーの動的支払いカードのスロット２の合計ベロシテイをを１取引及び３７５ドルだけ増加する。
【０１９８】
再び、これらの設定変更を達成するために、該カード処理システム１３０への適当な関数コールが該購入管理システム１００により行われ得る。例えば、上記で論じた該テーエスワイエス処理プラットフオームインターフエースを用いて、現在のベロシテイ設定を得てそれらの設定を更新するために管理及び制御パケットが使用され得る。
【０１９９】
サリーは彼女の要求が承認され、彼女の動的支払いカードが３７５ドルの購入を可能にされたことを知らされる。サリーは該縫製会社に推進（ｔｈｅ ｇｏ−ａｈｅａｄ）を指示する。該シャツはエイシーエムイーのロゴを付けて縫製され、サリーへ配送される。該縫製会社はサリーの動的支払いカードに課金しそして該縫製会社の非テーアンドイーのエスアイシーコードのために該課金はサリーの流用勘定をバイパス（ｂｙｐａｓｓｅｓ）し彼女の動的支払いカードのスロット２上で継承を終わる。
【０２００】
カードプロセサーがその処理を行うと、該購入管理システム１００はこの取引を知らされ、後刻のエイシーエムイー会計システム内の一致確認用にサリーの購入要求に該取引情報を取り付けそして／又は将来の整合と一致確認活動用に該取引情報をメリーの支払いカードと相関を取る。該購入管理システム１００は、サリーに彼女のカードがこの取引用に使用されたことを知らせ、そして会社の購入ポリシーにより推進されたものとしてのこの購入へのフオローアップ活動用に該購入管理システム１００内へのエイチテーエムエルハイパーリンクを彼女に提供するであろう。次ぎに、この支払い品目は該購入管理システム１００を経由してエイシーエムイーの会計システム内に流れ、エイシーエムイーがパートナー銀行からそれらのステートメントを受ける時この課金が現れ一致確認される。
【０２０１】
図６Ｂは又サリーセールス用のこの例で論じられた取引の種類で起こるであろう動的支払いカード処理例を提供する。
【０２０２】
本発明の更に進んだ変型と代替え実施例とがこの説明を見た当業者には明らかになるであろう。従って、本発明はこれらの例示配置により限定されないことが認識されるであろう。ついては、この説明は、図解としてのみ解釈されるべきであり、本発明を実施する仕方を当業者に開示する目的のためである。ここに示され説明された本発明のフオームは現在の好ましい実施例と取られるべきであることは理解されるべきである。形状、寸法そして部品配置で種々の変更が行われてもよい。本発明のこの説明に恵まれた後当業者には全て明らかな様に、例えば、等価な要素がここに図解され説明されたものと取り替えられてもよく、そして本発明の或る特徴は他の特徴の使用とは独立に利用されてもよい。
【０２０３】
付属する図面は本発明の例示的実施例を図解するのみであり、従って、その範囲を限定すると考えられるべきでなく、何故ならば本発明は他の等しく有効な実施例を容認しているからであることを述べておく。
【図面の簡単な説明】
【図１】
本発明による、動的支払いカードを利用する購入管理環境のブロック線図である。
【図２】
本発明による、動的支払い識別子と承認パラメーターとを利用する購入要求処理の流れ線図である。
【図３】
本発明による、購入管理環境内の購入要求の種々の起こり得る源を表すブロック線図である。
【図４】
本発明による、代わりの取引経路を含む購入要求処理のブロック線図である。
【図５Ａ】
本発明による、動的購入カード管理環境のブロック線図である。
【図５Ｂ】
本発明による、購入カード管理環境用の、承認処理順方向流れと承認処理逆方向流れの例のブロック線図である。
【図６Ａ】
予め承認された製品カテゴリーに属すると期待される購入をユーザーが始動した動的支払いカード処理の流れ線図である。
【図６Ｂ】
購入管理システムにより処理される購入要求に基づき購入をユーザーが始動した動的支払いカード処理の流れ線図である。
【図７Ａ及び７Ｂ】
流用勘定が利用される動的支払いカード処理用の流れ線図である。
【図８Ａ、８Ｂ、８Ｃそして８Ｄ】
支出制御、要求管理、注文管理そして財務管理を含む購入流れ管理のブロック線図である。
【図９Ａ、９Ｂ、９Ｃそして９Ｄ】
勘定セットアップ及びカード発行、要承認取引、自由裁量取引、そして論理的整合用のスウイムレーン線図である。
【図１０Ａ】
購入管理システムとカードプロセサーインフラストラクチャーの間の安全な通信を実現する安全代行環境のブロック線図である。
【図１０Ｂ】
１つ以上の購入管理システム、１つ以上のカード発行者、１つ以上のカードプロセサー、そして１つ以上の安全代行システムの間の安全な通信を実現する安全代行環境のブロック線図である。
【図１】
2004519773.tif 000007
【図２】
2004519773.tif 000008
【図３】
2004519773.tif 000009
【図４】
2004519773.tif 000010
【図５Ａ】
2004519773.tif 000011
【図５Ｂ】
2004519773.tif 000012
【図６Ａ】
2004519773.tif 000013
【図６Ｂ】
2004519773.tif 000014
【図７Ａ】
2004519773.tif 000015
【図７Ｂ】
2004519773.tif 000016
【図８Ａ】
2004519773.tif 000017
【図８Ｂ】
2004519773.tif 000018
【図８Ｃ】
2004519773.tif 000019
【図８Ｄ】
2004519773.tif 000020
【図９Ａ】
2004519773.tif 000021
【図９Ｂ】
2004519773.tif 000022
【図９Ｃ】
2004519773.tif 000023
【図９Ｄ】
2004519773.tif 000024
【図１０Ａ】
2004519773.tif 000025
【図１０Ｂ】
2004519773.tif 000026
【国際公開パンフレット】
2004519773.tif 000027
2004519773.tif 000028
2004519773.tif 000029
2004519773.tif 000030
2004519773.tif 000031
2004519773.tif 000032
2004519773.tif 000033
2004519773.tif 000034
2004519773.tif 000035
2004519773.tif 000036
2004519773.tif 000037
2004519773.tif 000038
2004519773.tif 000039
2004519773.tif 000040
2004519773.tif 000041
2004519773.tif 000042
2004519773.tif 000043
2004519773.tif 000044
2004519773.tif 000045
2004519773.tif 000046
2004519773.tif 000047
2004519773.tif 000048
2004519773.tif 000049
2004519773.tif 000050
2004519773.tif 000051
2004519773.tif 000052
2004519773.tif 000053
2004519773.tif 000054
2004519773.tif 000055
2004519773.tif 000056
2004519773.tif 000057
2004519773.tif 000058
2004519773.tif 000059
2004519773.tif 000060
2004519773.tif 000061
2004519773.tif 000062
2004519773.tif 000063
2004519773.tif 000064
2004519773.tif 000065
2004519773.tif 000066
2004519773.tif 000067
2004519773.tif 000068
2004519773.tif 000069
2004519773.tif 000070
2004519773.tif 000071
2004519773.tif 000072
2004519773.tif 000073
2004519773.tif 000074
2004519773.tif 000075
2004519773.tif 000076
2004519773.tif 000077
2004519773.tif 000078
2004519773.tif 000079
2004519773.tif 000080
2004519773.tif 000081
2004519773.tif 000082
2004519773.tif 000083
2004519773.tif 000084
2004519773.tif 000085
2004519773.tif 000086
2004519773.tif 000087
2004519773.tif 000088
2004519773.tif 000089
2004519773.tif 000090
2004519773.tif 000091
2004519773.tif 000092
2004519773.tif 000093
2004519773.tif 000094
2004519773.tif 000095
2004519773.tif 000096
2004519773.tif 000097
2004519773.tif 000098
2004519773.tif 000099
2004519773.tif 000100
2004519773.tif 000101
2004519773.tif 000102
2004519773.tif 000103
2004519773.tif 000104
2004519773.tif 000105
2004519773.tif 000106
2004519773.tif 000107
2004519773.tif 000108
2004519773.tif 000109
2004519773.tif 000110
2004519773.tif 000111
2004519773.tif 000112
2004519773.tif 000113
2004519773.tif 000114
2004519773.tif 000115
2004519773.tif 000116
2004519773.tif 000117
2004519773.tif 000118
2004519773.tif 000119
2004519773.tif 000120
2004519773.tif 000121
2004519773.tif 000122
2004519773.tif 000123
2004519773.tif 000124
2004519773.tif 000125
2004519773.tif 000126
2004519773.tif 000127
2004519773.tif 000128
【国際公開パンフレット（コレクトバージョン）】
2004519773.tif 000129
2004519773.tif 000130
【手続補正書】
【提出日】平成15年1月10日(2003.1.10)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コーポレートの購入ニーヅの効率的管理を見越して支払い機構の動的管理を提供するためにサーバーベースのシステムを動作させる方法に於いて、
１つ以上のサーバーシステムで支払い機構に関する或る購入能力を利用可能にする電子的要求をエンテイテイ内ユーザーから受ける過程と、
該支払い機構に付随する承認パラメーターを表す電子的情報を得るために該１つ以上のサーバーシステムから処理システムへ通信する過程とを具備しており、該処理システムは該支払い機構に付随した承認パラメーターに基づき該支払機構を使用して始動された取引を処理するシステムであり、該承認パラメーターは該処理システムにより記憶されており、そして該方法は又、
ベンダーシステムで電子的取引のオーソライゼーションを制御するために該購入能力が利用可能になるように該支払い機構用に記憶された該承認パラメーターを調整する電子的な調整インストラクションを該１つ以上のサーバーシステムから該処理システムへ送る過程を具備することを特徴とする該方法。
【請求項２】
該要求は１つ以上の望まれる取引に関する承認された購入要求を含んでおり、該承認された購入要求は該エンテイテイ内のリクエスターから購入要求を受け、該エンテイテイ用の購入ポリシーに関し該購入要求を処理し、そしてもし該購入ポリシーが満足されるなら該購入要求を承認し、そして該購入要求に基づき該要求を発生させることにより発生されることを特徴とする請求項１の該方法。
【請求項３】
更に、該支払い機構を使用して一旦完了された取引に付随する取引データを該１つ以上のサーバーシステムで受ける過程と該取引データを該購入要求と一致確認する過程とを具備することを特徴とする請求項１又は２の該方法。
【請求項４】
該要求が該支払い機構用の予め承認された購入用オーソリテイを提供する要求を有しており、そして該承認パラメーターがこの予め承認された購入用オーソリテイを提供するよう調整されることを特徴とする請求項１の該方法。
【請求項５】
更に、該１つ以上のサーバーシステムで、該支払い機構を使用して一旦完了した取引に付随する取引データを受ける過程と該取引データに基づき購入要求を合成する過程とを具備することを特徴とする請求項１の該方法。
【請求項６】
更に、該エンテイテイ用の購入ポリシーに関して該合成された購入要求を処理する過程ともし該購入ポリシーが満足されるなら該合成された購入要求を承認する過程とを具備することを特徴とする請求項４又は５の該方法。
【請求項７】
更に、該取引の完了後の１つ以上の選択されたイベントの発生に基づいて該予め承認された購入オーソリテイを回復するために該承認パラメーターを調整する過程を具備することを特徴とする請求項４から６の１つの該方法。
【請求項８】
複数の要求が複数の支払い機構に関し受けられ、そして複数の要求が各支払い機構に付随することを特徴とする前記請求項の１つの該方法。
【請求項９】
該支払い機構が支払いカードを有しており、該処理システムが支払いカード処理システムを有しており、該承認パラメーターが該支払いカード用制御設定を有しており、そして該１つ以上のサーバーシステムが購入管理システムを有することを特徴とする前記請求項の１つの該方法。
【請求項１０】
少なくとも１つの中間システムが該購入管理システムと該支払いカードプロセサーの間の通信を処理することを特徴とする請求項９の該方法。
【請求項１１】
該少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の過程分離を提供し、該購入管理システムと該カードプロセサーの間の通信用の１つ以上の安全機構を提供し、そしてこれらの通信をそれらが認識されたフオーマットで受けられるように処理するよう構成された安全代行システムを有することを特徴とする請求項９又は１０の該方法。
【請求項１２】
該少なくとも１つの中間システムが更に該カードプロセサー用通信インターフエースを提供するインターフエースシステムを有しており、該安全代行システムが該インターフエースシステムを通して該カードプロセサーと通信することを特徴とする請求項１１の該方法。
【請求項１３】
該購入ポリシーは、１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能であることを特徴とする請求項２又は３の該方法。
【請求項１４】
該ネットワークがインターネットを含むことを特徴とする請求項１３の該方法。
【請求項１５】
更に、複数の支払いカードをエンテイテイ内の複数の要素に付随させる過程を具備しており、該要素は人、車両又は建物を含むことを特徴とする請求項９から１４の１つの該方法。
【請求項１６】
更に、企てられた購入取引のパラメーターを該制御設定と比較する過程と、もし該パラメーターが該制御設定により許可されるなら該購入取引をオーソライズする過程とを具備しており、該比較する及びオーソライズする過程は該カードプロセサーにより行われることを特徴とする請求項９から１５の１つの該方法。
【請求項１７】
ベンダーが該企てられた購入取引の該パラメーターをオーソライゼーション用に該カードプロセサーへ通信することを特徴とする請求項１６の該方法。
【請求項１８】
該制御設定がベンダーアイデンテイテイコードと最大単一取引リミットとを含むことを特徴とする請求項１６又は１７の該方法。
【請求項１９】
該支払い機構が動的支払い識別子を含むことを特徴とする前記請求項の１つの該方法。
【請求項２０】
該支払い機構が更に支払いカードに付随した該動的支払い識別子を有する該支払いカードを備えることを特徴とする請求項１９の該方法。
【請求項２１】
該要求がエンテイテイの購入ポリシーに基づき承認された購入要求を含んでおり、該承認パラメーターが該承認された購入要求に付随する１セットの動的承認パラメーターを含んでおり、そして該処理システムが該承認された購入要求用の該動的承認パラメーターのセットを記憶することを特徴とする請求項２０の該方法。
【請求項２２】
更に、特定の動的支払い識別子に付随された複数の購入要求を受ける過程を具備しており、そして更に、各購入要求用に１セットの動的承認パラメーターを該１つ以上のサーバーシステムから該処理システムへ通信する過程を含んでおり、動的承認パラメーターの各セットは該処理システムにより記憶されることを特徴とする請求項２１の該方法。
【請求項２３】
更に、該動的支払い識別子を使用して行われた企てられた購入取引のパラメーターをその動的支払い識別子用に記憶された該動的承認パラメーターのセットと比較する過程と、もし該パラメーターが動的承認パラメーターの少なくとも１セットと整合するなら該購入取引をオーソライズする過程とを具備しており、該比較する過程とオーソライズする過程は該カード処理システムにより行われることを特徴とする請求項２２の該方法。
【請求項２４】
コーポレートの購入ニーヅの効率的管理を見越して支払い機構の動的管理を提供するサーバーベースのシステムに於いて、支払い機構に関して或る購入能力を利用可能にする電子的要求をエンテイテイ内のユーザーから受けとり、該支払い機構に付随する承認パラメーターを表す電子的情報を得るために処理システムと通信し、該承認パラメーターは該支払い機構に付随する該承認パラメーターに基づいて該支払い機構を使用して始動される取引を処理すために該処理システムにより記憶され使用され、該処理システムと該通信し、そしてベンダーシステムで電子的取引のオーソライゼーションを制御するために該購入能力が利用可能になるよう該支払い機構用承認パラメーターを調整するために電子的な調整インストラクションを該処理システムに送るよう、構成される１つ以上のサーバーシステムを具備することを特徴とする該サーバーベースのシステム。
【請求項２５】
該要求が１つ以上の特定の望まれた取引に関する承認された購入要求を含んでおり、該１つ以上のサーバーシステムが更に、該エンテイテイ内のリクエスターから購入要求を受け、該購入要求を該エンテイテイ用の購入ポリシーに関して処理し、もし該購入ポリシーが満足されれば該購入要求を承認し、そして該購入要求に基づく該要求を発生させるよう構成されていることを特徴とする請求項２４の該サーバーベースのシステム。
【請求項２６】
更に、該支払い機構を使用して一旦完了した取引に付随する取引データを受けるようそして該取引データを該購入要求と一致確認するよう構成された該１つ以上のサーバーシステムを更に具備することを特徴とする請求項２５の該サーバーベースのシステム。
【請求項２７】
該要求が該支払い機構用の予め承認された購入用オーソリテイを提供する要求を含んでおり、そして該承認パラメーターがこの予め承認された購入用オーソリテイを提供するよう調整されることを特徴とする請求項２４から２６の１つの該サーバーベースのシステム。
【請求項２８】
該１つ以上のサーバーシステムが更に、該支払い機構を使用して一旦完了した取引に付随する取引データを受けそして該取引データに基づき購入要求を合成するよう構成されることを特徴とする請求項２７の該サーバーベースのシステム。
【請求項２９】
該１つ以上のサーバーシステムが更に、該合成された購入要求を該エンテイテイ用の購入ポリシーに関して処理しそしてもし該購入ポリシーが満足されれば該合成された購入要求を承認するよう構成されることを特徴とする請求項２８の該サーバーベースのシステム。
【請求項３０】
該１つ以上のサーバーシステムが更に、該取引の完了後１つ以上の選択されたイベントの発生に基づき該予め承認された購入用オーソリテイを回復するために該承認パラメーターを調整する調整インストラクションを送るよう構成されることを特徴とする請求項２７から２９の１つの該サーバーベースのシステム。
【請求項３１】
複数の要求が複数の支払い機構に関し受けられ、複数の要求が各支払い機構に付随させられることを特徴とする請求項２４から２９の１つの該サーバーベースのシステム。
【請求項３２】
該支払い機構が支払いカードは含み、該処理システムは支払いカード処理システムを含み、該承認パラメーターは該支払いカード用制御設定を含み、そして該１つ以上のサーバーシステムは購入管理システムを含むことを特徴とする請求項２４から３１の１つの該サーバーベースのシステム。
【請求項３３】
少なくとも１つの中間システムが該購入管理システムと該支払いカードプロセサーとの間の通信を処理することを特徴とする請求項３２の該サーバーベースのシステム。
【請求項３４】
該少なくとも１つの中間システムが該購入管理システムと該カードプロセサーの間の過程分離を提供し、該購入管理システムと該カードプロセサーの間の通信用の１つ以上の安全機構を提供し、そしてこれらの通信をそれらが認識されたフオーマットで受けられるように処理するよう構成された安全代行システムを含むことを特徴とする請求項３３の該サーバーベースのシステム。
【請求項３５】
該少なくとも１つの中間システムが更に、該カードプロセサー用の通信インターフエースを提供するインターフエースシステムを含み、該安全代行システムは該インターフエースシステムを通して該カードプロセサーと通信することを特徴とする請求項３４の該サーバーベースのシステム。
【請求項３６】
該購入ポリシーが１つ以上のサーバーシステム上に定在する複数の誂え可能な購入管理規則を提供するネットワークインターフエースを通して構成可能であることを特徴とする請求項２５から３４の１つの該サーバーベースのシステム。
【請求項３７】
該ネットワークがインターネットを含むことを特徴とする請求項３６の該サーバーベースのシステム。
【請求項３８】
更に、エンテイテイ内の該複数の要素に複数の支払いカードを付随させる過程を具備することを特徴とする請求項３２から３７の１つの該サーバーベースのシステム。
【請求項３９】
該支払いカード処理システムが更に、企てられた購入取引のパラメーターを該制御設定と比較し、そしてもし該パラメーターが該制御設定により許可されれば該購入取引をオーソライズするよう構成されることを特徴とする請求項３２から３８の１つの該サーバーベースのシステム。
【請求項４０】
ベンダーがオーソライゼーション用に該企てられた購入取引のパラメーターを該カード処理システムへ通信することを特徴とする請求項３９の該サーバーベースのシステム。
【請求項４１】
該制御設定がベンダーアイデンテイテイコードと最大単一取引リミットとを含むことを特徴とする請求項３９又は４０の該サーバーベースのシステム。
【請求項４２】
該支払い機構が動的支払い識別子を含むことを特徴とする請求項２４から４１の１つの該サーバーベースのシステム。
【請求項４３】
該支払い機構が更に、支払いカードに付随する動的支払い識別子を有する様な該支払いカードを備えることを特徴とする請求項４２の該サーバーベースのシステム。
【請求項４４】
該要求がエンテイテイ購入ポリシーに基づき承認された購入要求を含み、該承認パラメーターは該承認された購入要求に付随する１セットの動的承認パラメーターを含み、そして該処理システムは該承認された購入要求用の該動的承認パラメーターのセットを記憶するよう構成されることを特徴とする請求項４３の該サーバーベースのシステム。
【請求項４５】
該１つ以上のサーバーシステムが更に、特定の動的支払い識別子に付随する複数の購入要求を受け、各購入要求用の１セットの動的承認パラメーターを該１つ以上のサーバーシステムから該処理システムへ通信するよう構成されており、動的承認パラメーターの各セットは該処理システムにより記憶されることを特徴とする請求項４４の該サーバーベースのシステム。
【請求項４６】
該カード処理システムが更に、該動的支払い識別子を使用して行われた企てられた購入取引のパラメーターをその動的支払い識別子用に記憶された該動的承認パラメーターのセットと比較し、もし該パラメーターが動的承認パラメーターの少なくとも１セットと整合すれば該購入取引をオーソライズするよう構成されていることを特徴とする請求項４５の該サーバーベースのシステム。
【国際調査報告】
2004519773.tif 000131
2004519773.tif 000132
2004519773.tif 000133