JP2008507065A - プログラム的トランザクションの自動承認 - Google Patents

Abstract

関係者間のトランザクションを自動的に承認する第三者トランザクション承認システムを介するなど、コンピューティングシステムの間のトランザクションを容易にする技法を説明する。いくつかの状況で、トランザクションは、アプリケーションプログラムを実行することによる料金ベースのウェブサービスの使用を伴うプログラム的トランザクションであり、トランザクション承認システムは、関係者によって以前に指定されたプライベート承認指示に従って、ウェブサービス提供者とウェブサービス消費者との間のトランザクションに関する支払いを承認および／または提供する。承認指示には、潜在的なトランザクションをその下で承認できる条件を規定する事前定義の指示ルールセットを含めることができ、指示ルールセットのそれぞれは、関連する参照トークンによって参照される。トランザクション承認システムは、潜在的なトランザクションの各関係者から参照トークンを受け取り、それらの参照トークンに関連する指示ルールセットに互換性があるまたは他の方式で満たされるかどうかに基づいて、そのトランザクションを承認するかどうかを判定することができる。

Description

次の開示は、全般的にはコンピューティングシステムの間の相互作用を容易にすることに関し、具体的には、関係者の実行中のアプリケーションプログラムの間での料金ベースのウェブサービスプログラム的トランザクションを承認するためなど、関係者の事前定義の指示に従って関係者間のプログラム的トランザクションを自動的に承認することに関する。

コンピュータおよび実行中のソフトウェアアプリケーションがプログラム的に相互作用することを可能にする様々な機構が存在する。例えば、あるコンピュータ上のプログラムが別のコンピュータ上のプログラムを実行させることを可能にするリモートプロシージャ呼出し（「ＲＰＣ」）プロトコルが、長年にわたって存在し、ＣＯＲＢＡ（「Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ」）およびＤＣＯＭ（「Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ」）などの様々なオブジェクト指向アーキテクチャが、類似する機能を提供する。さらに、通信を可能にするために別々のアプリケーション（しばしば、別個のタイプであり、関連しないソースからのアプリケーションである）を接続するために、様々なミドルウェアプログラムが実装されてきた。例えば、ネットワークのあるユーザのコンピュータシステムがネットワークの別のユーザのコンピュータシステムにデータを送信することを可能にする標準機構を提供する、様々なＥＤＩ（「Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ」）ネットワークが存在する。

ワールドワイドウェブ（「ウェブ」）の広い人気は、コンピュータが相互に通信する追加の機会を提供してきた。例えば、多くの現在のウェブの使用に、ユーザがウェブサーバにウェブページを対話的に要求すること（例えば、ユーザのウェブブラウザアプリケーションの実行を介して）および要求された情報をそれに答えて受信することが含まれる。要求された情報のそのような対話的ユーザ指定のほかに、ウェブサービスを介するなど、定義されたＡＰＩ（「アプリケーションプログラムインターフェース」）を介して情報を交換するためのリモートアプリケーションのプログラム的相互作用をサポートするためのウェブの使用の増加もある。

ウェブサービスは、異種アプリケーションおよび異種コンピュータが相互作用することを可能にし、様々な基礎になるプロトコルおよび技法を使用して定義し、実装することができる。例えば、一部のウェブサービス実装は、指定された動作および１以上のクエリパラメータを含むＵＲＬ（「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」）などのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ」）として指定されたウェブサービス呼出し要求に応答して、ＨＴＴＰ（「ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ」）を使用するＸＭＬ（「ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」）フォーマットでデータを返す。他の実装では、標準メッセージ交換用のＳＯＡＰ（「Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ」）、サービス呼出し記述用のＷＳＤＬ（「Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ」）、および利用可能サービスのディスカバリ用のＵＤＤＩ（「Universal Description, Discovery, and Integration service」）などの追加の基礎になるプロトコルが、様々な目的に使用される。

したがって、コンピュータシステムおよびプログラムは、様々な形で相互作用することができるが、異なるシステムおよびプログラムの間のトランザクションおよび他の相互作用を確立できる形において様々な制限が存在する。例えば、ウェブサービスまたは他のプログラム的サービスの一部の提供者は、進んで彼らのサービスを無料で誰もが利用可能にするが、ほとんどの有用で信頼できるサービスは、しばしば、無料で利用可能ではない。残念ながら、プログラム的サービスの提供者およびこれらのサービスの潜在的消費者がトランザクションに関する支払いおよび他の条件に合意する機構は、時間がかかり、使いにくいものであると同時に、関係者の少なくとも一部にとって非常に制限的である可能性がある。具体的に言うと、一部のトランザクションは、サービスまたは情報に関する関係者間の手動折衝から生じるが、そのような技法は、時間がかかり、発生し得るトランザクションの量を大幅に制限し、通常、関係者に関するかなりの情報の交換も必要とし、これが、いくつかの状況でそのようなトランザクションに対する追加の障害をもたらす可能性がある。

しかし、そのような手動折衝以外に、無料で利用可能ではないプログラム的サービスの使用に関する合意は、通常、一方の関係者がサービスおよび／または情報の使用に関する条件を定義し、他方の潜在的な関係者がこれらの条件を受け入れるかどうかを単に対話的に手動で判定することに制限される、折衝されないトランザクション（例えば、様々な使用制限の下で提供される通常のインターネットサービス提供者からのインターネットアクセス、またはデジタル著作権管理ソフトウェアによって実施される使用法制限の下で提供されるコンテンツ）に制限される。さらに、一部の技法は、消費者が、彼らの代わりにどのように支払いを行うことができるかに関する少なくとも制限された制御を有することを可能にする場合がある（例えば、指定された価値を有するある形の電子マネーを獲得し、使用することによって。したがって、この電子マネーは、その価値を超えて消費者に出費させるために不徳な第三者が使用することはできない）が、そのような技法は、通常、トランザクションの確立に関連する問題については援助しない。

したがって、プログラム的サービスに関連するトランザクションの確立に関連する上記および他の問題に対処し、および／またはコンピュータシステムおよび実行中のプログラムの相互作用を他の形で容易にする解決策を提供することが有益であるはずである。

いくつかの実施形態において、以前に関係者によって指定されたプライベート承認指示に従って関係者間のトランザクションおよび／またはそのトランザクションの金銭の支払いを自動的に承認する第三者トランザクション承認システムを提供することによるなど、コンピューティングシステムの間の相互作用を容易にするソフトウェアファシリティを説明する。いくつかの実施形態において、トランザクションの一部またはすべてが、ウェブサービス消費者と提携するアプリケーションプログラムによるウェブサービス提供者のウェブサービスの使用を伴うトランザクションなど、実行中のコンピュータプログラムの間で行われるプログラム的トランザクションである。さらに、いくつかの実施形態において、トランザクション承認システムは、さらに、関係者のうちの１以上への承認された支払いを１つまたは他の関係者の代わりに提供する。

このトランザクション承認システムは、関係者の間の様々なタイプの相互作用に関するトランザクションおよび／または支払いを承認するのに使用することができ、図８Ａ〜８Ｃに、そのような相互作用の一部の例が示されている。具体的に言うと、図８Ａには、関係者８０５ａが関係者８１０ａによって提供されるサービスを要求し、このサービスの提供が関連するコストを有する、２関係者トランザクション８３０ａの例が示されている。トランザクション承認システム８２０ａは、トランザクションを承認するかどうかおよび／またはそのトランザクションに関連するコストをカバーするためのサービス要求者からサービス提供者への支払い８５０ａの提供を承認するかどうかを判定するために、関係者８０５ａおよび８１０ａに関する情報（例えば、関係者のうちで、このトランザクション承認システムへの、承認を要求するプログラム的呼出しを行う関係者から受け取られた情報）を使用する。トランザクションおよび／または支払いが承認された後に、このトランザクション承認システムは、承認の表示を提供し（例えば、承認要求呼出しに対する応答として）、さらに、いくつかの実施形態においては、サービス要求者の代わりに承認された支払いを実際に行うことができる。承認プロセス８４０ａをどのように行うことができるかに関する詳細は、下でより詳細に述べる。

図示の承認技法および支払い技法は、様々な状況で使用することができる。例えば、提供されるサービスに、２つの関係者の間のプログラム的トランザクション（例えば、サービス提供者によって提供されるウェブサービスのサービス要求者による呼出し）が含まれる場合があり、あるいは、その代わりに、他のタイプのトランザクション（例えば、ある関係者から他の関係者への物理的製品または物理的サービスの提供など、関係者の間の物理的トランザクション）を含めることができる。このトランザクション承認システムを用いる承認相互作用は、同様に、トランザクション中に（例えば、適当な承認応答が受信されない限りトランザクションが完了されなくなるように）、または、その代わりに、トランザクションと別々の形で（例えば、サービス提供者に支払いを提供するためにトランザクションが完了した後に）など、様々な形で実行することができる。さらに、承認の実行に使用される、関係者に関する情報は、同様に、下でより詳細に述べるように、様々な形を有することができる。

図８Ｂは、関係者８０５ｂが関係者８１０ｂによって提供されるサービスを要求するトランザクション８３０ｂに関するより複雑な支払い８５０ｂの例を提供する。この例では、トランザクション承認者（ａｕｔｈｏｒｉｚｅｒ）８２０ｂが、トランザクション（図示せず）を承認した後に、支払いの一部を、サービス提供者８１０ｂとトランザクション承認者（例えば、トランザクション承認者がトランザクションおよび／または支払いの承認を実行するために料金を請求することに基づいて）の両方に提供することができ、支払いの一部を、サービス要求者と１以上の他の支払い提供者８１５ｂ（例えば、サービス要求者によって実行されるアプリケーションプログラムを提供したアプリケーション開発者）の両方によって提供することができる。他の状況では、様々な関係者の間の支払いを、支払い提供者が支払いのすべてを提供する場合、支払い提供者が支払いのうちでサービス提供者およびトランザクション承認者のうちの一方に与えられる部分を提供し、サービス要求者がサービス提供者およびトランザクション承認者のうちの他方に与えられる部分を提供する場合など、他の形で提供することができる。

図８Ｃは、複数の参加する関係者８６０ａ〜８６０ｎを有するより複雑なトランザクション８３０ｃの例を提供する。この例では、これらの関係者のうちの一部またはすべてならびに１以上の他の支払い提供者８１５ｃが、トランザクション承認者８２０ｃに情報を供給するか、他の形でこれと相互作用して、このトランザクション承認者が、このトランザクションおよび／またはすべての関連する金銭の支払いが承認されるかどうかを判定できるようにすることができる。承認プロセス８４０ｃが、承認を提供した後に、支払い（図示せず）を、参加する関係者および／または支払い提供者のうちの１以上によって、他の参加する関係者および／またはトランザクション承認者に対して行うことができる。

前に注記したように、このトランザクション承認システムは、トランザクションを承認するかどうかを判定するときに、トランザクションの関係者に関する様々な情報を使用することができる。具体的に言うと、そのようなトランザクションの潜在的な関係者であるユーザは、まず、料金ベースのトランザクションおよび／またはそのようなトランザクションの関連する金銭の支払いの承認に使用される支払い命令ルールセットなど、トランザクションの承認に後に使用される、１以上のタイプの使用法命令ルールセットをこのトランザクション承認システムを用いて定義することができる。ある関係者の各そのような支払い命令ルールセットには、下でより詳細に述べるように、支払い命令ルールセットがその関係者の潜在的なトランザクションおよび／またはそれに関連する金銭の支払いを承認できる条件を規定する１以上の指定されたルールを含めることができる。

例えば、潜在的なウェブサービス消費者（例えば、彼らのアプリケーションプログラムが指定された状況の下でウェブサービスを呼び出すことができることを望むアプリケーション開発者）は、支払い命令ルールセットによって承認できるトランザクションのウェブサービス消費者への金銭的露出を制限する支払い命令ルールセットのルールを指定することができる（例えば、その支払い命令ルールセットがトランザクションを承認できる回数、その支払い命令ルールセットが承認できる１トランザクションあたりの最高支払額、その支払い命令ルールセットが承認できる最高総支払額、その支払い命令ルールセットの失効日などを介して）。同様に、潜在的なウェブサービス提供者は、支払い命令ルールセットによって承認できるトランザクションに関するウェブサービス提供者への債務を制限する支払い命令ルールセットのルールを指定することができる（例えば、ウェブサービスへのアクセスを購入できる消費者に関する制限、ウェブサービスへのアクセスを購入するのに使用できる支払いのタイプに関する制限、ウェブサービスの使用に不満を感じている消費者が利用可能な救済策に関する制限など）。さらに、潜在的なウェブサービス呼出し側（例えば、１以上のウェブサービスを呼び出す、アプリケーション開発者によって供給されるアプリケーションプログラムのエンドユーザ）は、支払い命令ルールセットによって承認できるトランザクションに関する呼出し側への債務を制限する支払い命令ルールセットのルールを指定することができる（例えば、呼出し側が開始することを承認されるプログラム的トランザクションのタイプに対する制限、および／または、サービスの提供者への支払いならびに／あるいはトランザクション承認サービスおよび／または支払いサービスなどの他の第三者サービスに支払われる料金など、プログラム的サービスへのアクセスを購入するために行うことができる支払いのタイプに対する制限）。

あるユーザの指定された使用法命令ルールセットを受け取った後に、このトランザクション承認システムは、オプションでまずその指示ルールセットを承認した後に（例えば、その指示ルールセットが必要な情報を含むこと、および／または含む場合にその情報が正しい形であることの検証に基づいて）、そのユーザに関連する形でその指示ルールセットを格納する（例えば、その指示ルールセットをこのトランザクション承認システムに関するそのユーザのアカウントに関連付ける）。このトランザクション承認システムは、その指示ルールセットを参照する参照トークンを生成し、その参照トークンをその指示ルールセットに関連付け（例えば、その参照トークンの表示を格納された指示ルールセットと共に格納することによって）、後にその指示ルールセットを参照するのに使用するためにその参照トークンをユーザに供給することも行う。他所でより詳細に述べるように、これらの参照トークンは、様々な形で生成することができ、様々な形（例えば、一意であることが保証された長い乱数）をとることができ、いくつかの実施形態においては、複数の参照トークンを、単一の指示ルールセットについて生成し、これに関連付けることができる。いくつかの実施形態において、参照トークンは、ユーザに関連するすべての識別情報を欠くことによって、および／または参照トークンに関連する指示ルールセットの条件に関するすべての情報を欠くことによって（例えば、そのような参照トークンを用いる潜在的トランザクションの他の関係者が、ユーザおよび／または関連する指示ルールセットに関するそのような情報を取得するのを防ぐために）など、ユーザによる参照トークンの匿名使用および／またはプライベート使用を可能にする形で生成される。

使用法命令ルールセットが定義され、関連する参照トークンが生成された後に、これらを使用して、指示ルールセットの以前に定義された条件によるプログラム的トランザクションの自動的承認を可能にすることができる。具体的に言うと、いくつかの実施形態において、潜在的なプログラム的トランザクションの複数の関係者（例えば、ウェブサービス提供者、ウェブサービス消費者、およびオプションでエンドユーザ呼出し側関係者）のそれぞれは、その潜在的トランザクションの承認に使用される参照トークンならびにその潜在的トランザクションに関する様々な情報を供給する。これらの参照トークンおよび潜在的トランザクションに関する様々な情報は、そのトランザクションが承認されるかどうかの自動判定（例えば、リアルタイムの形でなどの動的判定）のために、このトランザクション承認システムに供給することができる。下でより詳細に述べるように、いくつかの実施形態において、潜在的トランザクションが承認されるかどうかの、供給された参照トークンに基づくこのトランザクション承認システムによる自動判定には、これらの参照トークンに関連する指示ルールセットを取り出すことと、その後、それらの指示ルールセットに互換性があるかどうかを判定することとが含まれる。

このトランザクション承認システムに供給される、潜在的トランザクションに関する情報は、様々な実施形態および状況で変更することができる。例えば、トランザクションに関する情報を、いくつかの状況では、単に、関係者のうちの１つによって別の関係者に支払われるトランザクション額に制限することができ、他の状況では、トランザクションに関する様々な追加の詳細を供給することができる（例えば、トランザクションのタイプ）。さらに、いくつかの状況で、このトランザクション承認システムへの呼出しは、さらに、潜在的トランザクションの複数の関係者のそれぞれが、別の関係者におよび／またはこのトランザクション承認システムへの料金としてのどちらであれ、（支払う場合に）いくらを支払わなければならないかに関する詳細を指定することができる。

使用法命令ルールセットに互換性があるかどうかの判定は、各指示ルールセット内の各ルールが現在の潜在的トランザクションについて満たされるかどうかを判定することによるなど、様々な実施形態で様々な形で実行することができる。そのようなルールを満たすことは、潜在的トランザクションに関する情報（例えば、トランザクションのタイプおよび／またはトランザクションに関連する支払額）、トランザクションの１以上の他の関係者に関する情報（例えば、関係者が指定された判断基準を満たすかどうか）、潜在的トランザクションについて指定された１以上の他の指示ルールセットに関する情報（例えば、他の指示ルールセットの１以上の対応するルールがルールと一致しまたは他の形で互換性があるかどうか）などに基づくなど、異なるタイプのルールについて様々な形で発生し得る。逆に、いくつかの状況で、指示ルールセットが使用のために現在利用可能でない（例えば、指示ルールセットが失効しているか、許容可能なユーザの総数または総許容可能支払額を超えていることに基づくなど、他の形で現在使用のために利用可能でない）場合および／または指示ルールセットをその潜在的トランザクションについて使用できない場合など、潜在的トランザクションのときの諸条件に基づいて、指示ルールセット（およびそれらに関連する参照トークン）のうちの１以上が現在の潜在的トランザクションについて無効なので、指示ルールセットに互換性がないと判定される場合がある。

１以上の関連する金銭の支払いを有する潜在的トランザクションが、承認されると自動的に判定されるときに、このトランザクション承認システムは、いくつかの実施形態において、さらに、適当に関係者の間の支払い交換を実行するか容易にすることができる。例えば、いくつかの実施形態において、支払いを提供するユーザは、事前に１以上の支払い手段（例えば、クレジットカード、銀行口座など）を指定している場合があり、そうである場合に、金銭の支払いを、適当な形でこれらの支払い手段のうちの１以上から取得することができる（例えば、その支払いを提供するユーザの支払い命令ルールセットによって指定された支払い手段から）。同様に、支払いを受け取るユーザは、事前に１以上の支払いリポジトリ（例えば、銀行口座、デビットカードなど）を指定している場合があり、その場合に、金銭の支払いを、適当な形でこれらの支払いリポジトリのうちの１以上に供給することができる（例えば、その支払いを受け取るユーザの支払い命令ルールセットによって指定された支払いリポジトリへ）。

このトランザクション承認システムが、潜在的なトランザクションを承認し、オプションでその潜在的トランザクションのすべての関連する金銭の支払いを実行した後に、そのトランザクションの関係者は、適当な形でそのトランザクションを実行することができる。例えば、そのトランザクションが、料金ベースのウェブサービストランザクションである場合に、ウェブサービス消費者は、そのウェブサービスを呼び出すことができ、そのウェブサービスの提供者は、そのウェブサービスに関連する機能性をその消費者に供給することができる。

いくつかの実施形態において、潜在的なトランザクションが承認されおよび／または実行された後であっても、このトランザクション承認システムによって追加の制限を課すことができる。例えば、いくつかの状況で、支払いが預けられたトランザクション承認システムのアカウントへのアクセスを制限することによって、および／または受取人の別の支払いリポジトリへの受け取られた支払いの一部またはすべての預金を遅延させることによってなど、支払いの受取人が、これらの支払いを即座に引き出すか受け取ることを承認されないものとすることができる。そのような支払いアクセス制限は、トランザクションが承認されおよび／または実行された後の指定された時間期間の間に、すべての論争が解決され、すべての払戻しが自動的に行われる（例えば、払戻しの額に関する支払い受取人への入金相殺として）ことを可能にすることを含む、様々な形で、様々な理由について実行することができる。いくつかの実施形態において、追加の関連する機能性を、さらに、このトランザクション承認システムによって、または、すべてのそのような払戻しの資金を保証するか提供する料金ベースの保険引受けまたは保険サービスなどの第三者から供給することができ、したがって、支払い受取人が、すべての受け取られた支払いへの即座のまたはよりすばやいアクセスを有することが可能になる。

いくつかの実施形態において、このトランザクション承認システムのユーザは、支払い命令ルールセットの代わりにまたはそれに加えてのどちらであれ、料金ベーストランザクションの承認以外の状況で使用される他のタイプの使用法命令ルールセットをより一般的に定義することができる。例えば、そのような使用法命令ルールセットには、それぞれ、制限された情報または制限されたサービスへのアクセスを提供するかどうかを判定するためなど、その使用法命令ルールセットが料金を含まない潜在的トランザクションを承認できる条件を規定する１以上の指定されたルールを含めることができる。

さらに、使用法命令ルールセットのルールは、様々な実施形態で様々な形で指定し、使用することができ、さらに、様々な実施形態で様々な形を有することができる。例えば、いくつかの実施形態において、あるルールが、あるタイプの検査すべき情報と、その情報に関して実行すべき、あるタイプの評価と、評価の結果がルールを満たすかどうかを判定するテストとを指定することができる。より一般的に、他の実施形態では、あるルールが、そのルールが指定された状況で満たされるかどうかを判定するために検査し、および／または評価することができるすべての条件または情報を反映することができる。例えば、いくつかの実施形態において、あるルールを、ＸＭＬフォーマットを使用して指定することができ、指示ルールセットを、さらに、いくつかの実施形態において、ＸＭＬ文書として指定し、および／または格納することができる。

さらに、いくつかの実施形態において、各事前定義のタイプのルールが、指示ルールセットの使用に関連する条件のタイプを指定し、各ユーザ選択が、作成される指示ルールセットについて使用法条件がどのようにまたはいつ満たされるかに影響するために事前定義のルールタイプをカスタマイズするために１以上のパラメータ値を指定することを含むなど、ユーザは、使用法命令ルールセットを定義するときに様々な事前定義のタイプのルールから選択することができる。さらに、いくつかの実施形態において、ユーザは、ルールが満たされるときを判定するユーザ指定のプロシージャをそれぞれが示すルールなど、様々なユーザ指定のルールを指定することができる（例えば、呼び出されたときに、ルールが満たされるかどうかに関する表示を提供する、ルールに関する実行可能コードを提供することによって、あるいは、その代わりに、アクセス可能なユーザ指定のウェブサービスまたは他の関数を、指定されたパラメータ値を使用して呼び出すことによるなど、ルールが満たされるかどうかを示す応答を自動的に取得する形を示すことによって）。

いくつかの実施形態において、ルールの評価に、さらに、自動化された形でおよび／または１以上のユーザに関して対話的な形でなど、ルールが満たされるかどうかに関する判定の一部として使用される追加情報を取得することを含めることができる（例えば、評価を確認し、および／または追加情報を供給するために、指示ルールセットを作成したユーザにクエリすることによって）。さらに、使用法命令ルールセットのセキュリティおよび／またはプライバシに関連する機能性が提供されるいくつかの実施形態においては、指示ルールセット内のルールのうちの１以上を使用して、その機能性を提供することができ（例えば、その指示ルールセットにアクセスでき、および／またはこれを変更できる人を制限することによって）、他の実施形態では、そのような機能性を、他の形で提供することができる（例えば、１以上の指示ルールセットを関連付けることができるユーザアカウントへのアクセスを制御することによって）。

さらに、使用法命令ルールセットおよびそのルールは、このトランザクション承認システムによって提供されるグラフィカルユーザインターフェース（「ＧＵＩ」）を介して対話的におよび／またはその目的のためにこのトランザクション承認システムによって提供される１以上のウェブサービスの呼出しを介してなど、様々な実施形態で様々な形で作成することができる。そのようなウェブサービスは、ＨＴＴＰ上のＸＭＬに基づくＡＰＩ（例えば、リソースに焦点を合わせた分散相互作用モデルであるＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒまたは「ＲＥＳＴ」の一部として）および／またはＳＯＡＰおよび／またはウェブサービスに関連する他のプロトコルの使用に基づくＡＰＩを使用することなど、様々な方法で実装することができる。さらに、指示ルールセットが作成され、参照トークンに関連付けられた後に、いくつかの実施形態において、その指示ルールセットは、変更を承認されないかもしれない。代替案では、いくつかの実施形態において、そのような指示ルールセットを変更することができ、変更された指示ルールセットの新しい参照トークンが、その新しい指示ルールセットについて生成される（例えば、前の参照トークンを置き換かえるために）。さらに、いくつかの実施形態において、参照トークンおよび／または関連する指示ルールセットを、意図した使用のときに動的に作成することができ（例えば、プログラム的サービスの呼出しを試みることおよび／または第三者の承認者に承認要求を送ることの一部としてまたはその直前に）、一例として、いくつかの実施形態において、使い捨てのトークンおよび／または指示ルールセットを作成し、使用することができる（例えば、特定の潜在的トランザクションのために）。

さらに、料金ベーストランザクションが承認され、金銭の支払いが処理されるいくつかの実施形態において、ユーザの一部またはすべては、さらに、支払い手段および／または支払いリポジトリとしてユーザが使用できるアカウントなど、そのような支払いを容易にするこのトランザクション承認システムに関するアカウントを有することができる。そのようなアカウントおよび／または他の金銭的手段／リポジトリは、いくつかの実施形態において、非常に小額の微小な支払いをサポートすることができる。さらに、いくつかの実施形態において、このトランザクション承認システムは、さらに、金銭の支払いトランザクションに関連する料金を最小にするため、および／または最小支払い額に達することを可能にするためなど、提供および／または受け取られる金銭の支払いの集計を提供することができる（例えば、毎月など、周期ベースで）。他のタイプのアカウントと同様に、そのようなユーザアカウントは、いくつかの実施形態において、最大許容貸方残高など、その使用に関連する様々な条件および制限ならびに様々なセキュリティおよびアクセス制御（例えば、パスワードベースの）を有することができる。

さらに、このトランザクション承認システムは、上では様々な実施形態で様々な機能性および能力を提供するものとして説明されたが、いくつかの実施形態において、そのような機能性および能力の一部を、その代わりに１以上のシステムにまたがって分割することができる。例えば、いくつかの実施形態において、一部のまたはすべてのユーザが、このトランザクション承認システムが提携するか他の形でアクセスできる別のシステムのユーザアカウントを既に有する場合があり、そうである場合に、アカウント関連機能性の一部またはすべてを、このトランザクション承認システムとあいまって、その別のシステムによって提供することができる（例えば、指示ルールセットの格納、参照トークンの生成、支払いリポジトリ／手段機能性の提供など）。

例示のために、様々な特定のタイプの能力および機能性がトランザクション承認システムの特定の実施形態によって実行され、ユーザが、様々なタイプの料金ベースのプログラム的トランザクションを承認するための支払い命令ルールセットなどの特定のタイプの使用法命令ルールセットを特定の形で定義し、使用する、ソフトウェアファシリティのいくつかの実施形態を下で説明する。しかし、当業者は、本発明の技法を、ウェブサービス以外のサービスおよびアイテムと、金銭の支払いの提供以外の目的とを含む様々な他の状況で使用できることと、本発明が、提供される例示的詳細に限定されないこととを理解するであろう。

図２は、この例ではプログラム的ウェブサービスに関する支払いを承認し、提供する、支払いハンドリングシステム（「ＰＨＳ」）金銭のトランザクション承認システム２００の例の実施形態のコンポーネントおよび情報フローを示すネットワーク図である。様々なユーザおよびシステムが、図示の例のウェブサービス（「ＷＳ」）ＰＨＳと相互作用して、ユーザおよび／またはシステムの間で行われるトランザクションに関するものなど、支払いハンドリング機能性を受け取る。図示の実施形態で、ＰＨＳには、下で説明するように、アカウントシステム２２０とウェブサービストランザクションシステム２１０の両方が含まれる。

具体的に言うと、図示の実施形態では、アプリケーション開発を実行するユーザ（図示せず）は、コンピューティングシステム２５０を使用して、ＰＨＳと相互作用２５１して、このユーザによって開発されるアプリケーションプログラムの代わりに後の支払いハンドリング機能を利用可能にする。アプリケーション開発者ユーザのコンピューティングシステム２５０は、まず、アカウントシステムと相互作用して、アカウントシステムによって提供される対話型ＧＵＩ ２２４を介してまたはその代わりにアカウントシステムによって提供される１以上のウェブサービスＡＰＩ ２２２を介してなど、このアプリケーション開発者のユーザアカウント２３０を定義する。図示の実施形態では、各そのようなユーザアカウントに、使用法命令ルールセットを支払いのためにいつどのように使用できるかに関する様々なルールをそれぞれが指定する１以上の使用法命令ルールセット２３５を含めることができる。さらに、各使用法命令ルールセットは、後にその使用法命令ルールセットを参照するための関連する一意の参照トークン２４０を有する。アプリケーション開発者ユーザが、１以上の使用法命令ルールセットと共にアカウントを作成した後に、そのユーザは、その使用法命令ルールセットの参照トークン２５７のうちの１以上を、彼らが作成する１以上のアプリケーションプログラム２５５内に含める。

同様に、ウェブサービスを他者に提供する１以上のユーザ（図示せず）は、コンピューティングシステム２６０を使用して、アカウントシステムの対話型ＧＵＩおよび／またはウェブサービスＡＰＩを介してアカウントシステムと相互作用２６１する。アプリケーション開発者と同様に、各ウェブサービス提供者ユーザは、アカウントシステムに、１以上の使用法命令ルールセットと共にアカウントを作成することができる。ウェブサービス提供者ユーザは、ウェブサービス提供者がウェブサービスを他者に（例えば、料金と引き換えに）提供するのに用いる１以上のウェブサービス提供者トランザクションシステム２６５の一部として、彼らの使用法命令ルールセットの彼らの参照トークン２６７のうちの１以上を関連付けることができる。

アプリケーションプログラム２５５のうちの１つが、後に、エンドユーザコンピューティングシステム２７０でエンドユーザ（図示せず）によって実行されているときに、そのアプリケーションプログラムは、ウェブサービスＡＰＩ ２６９を介するなど、ウェブサービス提供者のトランザクションシステムによって提供される１以上のウェブサービスを呼び出す２９０。しかし、図示の実施形態のウェブサービス提供者は、適当な支払いがアプリケーションプログラムについて提供される場合に限って、要求されたウェブサービスを提供する。したがって、図示の実施形態では、アプリケーションプログラムは、ウェブサービス呼出しの一部として、アプリケーション開発者ユーザの参照トークン２５７を供給する。要求されたウェブサービスをアプリケーションプログラムに供給する前に、ウェブサービス提供者トランザクションシステムは、ＰＳＨトランザクションシステム２１０に連絡２９５して、ＰＨＳトランザクションシステムのウェブサービスＡＰＩ ２１２の呼出しを介するなど、適当な承認および支払いを取得する。図示の実施形態では、ウェブサービス提供者トランザクションシステムは、ウェブサービス提供者の参照トークン２６７ならびにアプリケーションプログラムからの参照トークン２５７を、ＰＨＳトランザクションシステムとの相互作用の一部として供給し、さらに、これから行われるトランザクションおよび関連する支払いに関する情報を供給する。

ＰＳＨトランザクションシステム２１０は、図示の実施形態では、まずウェブサービスＡＰＩ ２１２への呼出しで供給された参照トークンに対応する使用法命令ルールセット２３５に関する情報を取り出すためにアカウントシステム２２０と相互作用すること、ならびに、さらに、その使用法命令ルールセットが属するユーザアカウント２３０から他の情報を取り出すこととによって、支払いトランザクションが承認されるかどうかを判定する。使用法命令ルールセットおよび他の情報を取得した後に、ＰＳＨトランザクションシステム２１０は、ルールセットが互換であり、要求された支払いが行われることを他の形で承認するかどうかを判定し、そうである場合には、ＰＨＳトランザクションシステムは、その支払いを実行し（例えば、アプリケーションプログラムの参照トークン２５７に関連する支払い手段に請求することと、その請求金額の少なくとも一部をトランザクションシステム２６５の参照トークン２６７に関連する支払いリポジトリに預けることとによって）、トランザクションシステム２６５に確認を供給し、トランザクションシステム２６５は、その後、最初に要求されたウェブサービスをアプリケーションプログラムに供給する。いくつかの実施形態において、ＰＨＳは、さらに、実行されたトランザクションごとの支払いの一部ならびに／あるいはアカウント作成および／または変更に関連する支払いとしてなど、そのＰＨＳが提供するサービスの一部またはすべてに関する支払いを取得することができる。

ＰＳＨトランザクションシステム２１０およびアカウントシステム２２０は、この実施形態では、別々であるが協力するシステムとして図示されているが、他の実施形態では、図示の機能性を他の形で提供することができる。例えば、いくつかの実施形態においては、単一のシステムが、アカウント作成および維持能力ならびにトランザクション承認およびハンドリング能力の両方を提供することができ、他の実施形態では、トランザクションシステム２１０およびアカウントシステム２２０を、その代わりに、関連しないシステム／組織によって提供することができる。

さらに、支払いタイプのトランザクションだけがこの図に示されているが、他の実施形態では、支払いトランザクションの代わりにまたはこれに加えてのいずれであれ、様々な他のタイプのトランザクションを実行することができる。さらに、図示の実施形態では、トランザクションシステム２６５のウェブサービスを使用することに関する使用回数による料金を述べるが、他の実施形態では、１以上のアプリケーションプログラム２５５に関するトランザクションシステム２６５の１以上のウェブサービスの進行中のサブスクリプションなど、様々な他のタイプの購入トランザクションを実行することができる。代替案では、ウェブサービスの指定された回数の使用または指定された時間期間中の無制限の回数の使用を、その代わりに、アプリケーションプログラム２５５をエンドユーザに配布する前にアプリケーション開発者ユーザによってなど、購入し、参照トークン２５７に関連付けることができる。そのような状況では、サブスクリプションまたは他の複数回使用購入に関する情報を、様々な形でアカウントシステムによって格納することができ、その結果、トランザクションシステム２１０は、後に、支払いトランザクションが承認されることを判定できるようになる。プログラム的トランザクションを承認するための使用法命令ルールセットの使用に関する追加の詳細は、参照によってその全体が本明細書に組み込まれている特許文献１（弁理士整理番号１２０１３７．４９５）に含まれる。

図１Ａ〜１Ｂは、トランザクション承認およびハンドリングシステムによる後の使用のためにアカウントおよび使用法命令ルールセットを作成するためのユーザによる対話の例を提供する。具体的に言うと、図１Ａは、ウェブサービス提供者ユーザＡＢＣが、アカウントシステムによって提供されるウェブページ内のフォームに記入することによるなど、それを介してユーザアカウントを対話的に作成するＧＵＩの例を提供する。この図示の例では、例の対話的作成画面に、概要情報を含むヘディング領域１１１と、それに続く、アカウント名、アカウントを表示し、変更するためのアクセス制御用のパスワード、すべてのオプションの証明書、およびすべてのオプションの組織提携など、アカウントに関する様々な一般情報をユーザがそこで指定できる領域１１３とが含まれる。この例では、ＡＢＣによって提供されるウェブサービスの潜在的消費者の一部の使用法命令ルールセットが、ＡＢＣへの支払いを承認するために第三者からの証明を要求する場合があるので、ユーザＡＢＣは、第三者会社ＢＣＤ Ｃｏｒｐｏｒａｔｉｏｎからの証明を指定する。同様に、ＡＢＣのウェブサービスの潜在的消費者の使用法命令ルールセットが、同様に、ユーザＡＢＣへの支払いを承認するために１以上の組織提携を要求する場合があるので、ユーザＡＢＣは、それ自体の会社と様々なウェブサービス提供者の連盟との両方への組織提携を指示する。

この例では、アカウント作成画面に、オプションのセクション１１４も含まれ、このセクション１１４では、ユーザＡＢＣが、料金ベースウェブサービスの消費者への提供に関してなど、そのユーザが受け取ることのできる支払い用の１以上の支払いリポジトリを指定することができる。この例の実施形態では、ユーザＡＢＣは、銀行口座とデビットカードを含む、入ってくる支払いを預けることができる２つの支払いリポジトリを指定する。このユーザは、さらに、預けられるすべての支払いが少なくとも５セントの最小額でなければならないように、デビットカードに関する制限を指定する。この図示の実施形態のセクション１１４には、作成されるユーザアカウント自体がそのユーザの支払いリポジトリとして働くことも示されている。

このアカウント作成画面には、セクション１１５も含まれ、このセクション１１５で、ユーザＡＢＣは、他者に対して行われる支払いに使用される１以上の支払い手段を指定することができる。この例では、ユーザＡＢＣは、利用可能な支払い手段として、この口座からのすべての個々の支払いが５０ドルを超えないという制限付きで同一の銀行口座、ならびに２００ドルの最大の個々の支払いおよび２０００ドルの最大累積差引勘定という制限付きでクレジットカード支払い手段を指定する。セクション１１５は、同様に、作成されるユーザアカウントが、そのユーザによる支払い手段として利用可能であることを示し、このユーザアカウントには、このユーザに関して、この例では１０００ドルの最高差引勘定信用限度が含まれる。様々なタイプの情報を指定した後に、ユーザは、コントロール１１６ｂを選択して、アカウントを作成することができ、あるいは、ユーザは、その代わりにコントロール１１６ａを選択して、アカウント作成をキャンセルすることができる。

図示の実施形態では、まずユーザアカウントを作成した後に、ユーザは、図１Ｂに示された例の画面を介して、１以上の使用法命令ルールセットを作成するオプションを提示される。具体的に言うと、図示の画面には、概要情報を有するヘッダセクション１１７と、作成される使用法命令ルールセットに関する様々な情報をそこで指定できるルール指定セクション１１８とが含まれる。この例では、セクション１１８は、ユーザが、作成される使用法命令ルールセットの名前、ルールセットの使用法タイプ（この例では支払いを受け取るため）、すべてのそのような支払いを受け取る支払いリポジトリ、およびこの例では指定されていない失効日を指定することを可能にする。ユーザＡＢＣは、このルールセットの１以上の特定のルールを指定することもできる。この例には、定義済みの２つのルールと、この例のこの使用法命令ルールセットについて選択でき、カスタマイズできる他のタイプのルール属性を示す第３ルールのドロップダウンメニューとが示されている。

例えば、ユーザＡＢＣは、この使用法命令ルールセットが、最初の「ＡｌｌｏｗｅｄＰａｙｅｒｓ（承認される支払人）」役割属性を満たすユーザからの支払いを受け取るだけであることを指定しており、この役割属性は、この例では、支払人の指定された組織提携、支払人のレーティング、またはそのＩＤが示された特定の支払人に基づいて満たすことができる。示されているように、この例で指定できる他の役割属性には、ユーザＡＢＣが支払いを受け入れない、承認されないまたはブロックされた支払人、この使用法承認ルールセットを使用できる承認されるまたは承認されないトランザクションタイプの指定、受け取られる支払いの支払い手段および通貨の承認されるまたは承認されないタイプ、発生するすべての論争を後に扱うための諸条件などが含まれる。さらに、図示の実施形態は、ユーザが、実行可能コードおよび／またはアクセス可能な実行可能な機能を呼び出す機構（例えば、ウェブサービス）を含めることによるなど、ユーザ定義のルールを指定することを可能にする。作成される使用法命令ルールセットに関する様々な情報を指定した後に、ユーザＡＢＣは、セクション１０９内のコントロールのうちの１つを選択して、現在の使用法命令ルールセットを作成し、このアカウントの別のルールセットの作成を継続するか、現在の使用法命令ルールセットを作成し、アカウント変更を終了するか、現在の使用法命令ルールセットの作成をスキップし、終了することができる。

この例に示されたルール属性のタイプは、例のために単純化された形で提供され、類似する情報を、その代わりに他の状況で他の形で指定することができる。例えば、承認されるおよび承認されない支払人について異なる属性を有するのではなく、あるユーザが承認されるまたは承認されないかのどちらであるかを判定するのに使用される、タイプの評価判断基準（例えば、ルールを満たすために、支払人が指定された値「ＩＳ（である）」または「ＩＳ−ＮＯＴ（でない）」ことが指定される）と共に、支払人の単一の属性を、その代わりに提供することができる。例の属性に関する追加の詳細は、他所で述べる。

図１Ｃに、ユーザアカウントの使用法命令ルールセットを作成する代替技法を示す。具体的に言うと、この例の実施形態では、ユーザアカウントおよび使用法命令ルールセットは、ＷＳ支払いハンドラシステムによって提供される１以上のウェブサービスを介するなど、ウェブサービス消費者アプリケーション開発者ユーザＣＤＥによってプログラム的に作成される。この例の実施形態では、プログラム的呼出しの一部として供給される情報に、図１Ｃに示された例のＸＭＬ文書１３１が含まれる。この例のＸＭＬ文書は、作成される使用法命令ルールセットが関連付けられるアカウントＩＤ（例えば、ユーザアカウントを作成する、以前のプログラム的呼出しに応答してこのユーザが受け取ったアカウントＩＤ）を指定し、さらに、図１Ｂに関する対話的な形で指定されたものに似た様々な情報を供給する。

具体的に言うと、この使用法命令ルールセットは、料金ベースウェブサービス（例えば、ウェブサービス提供者ユーザＡＢＣによって提供される１以上のウェブサービス）など、ユーザＣＤＥによって作成される１以上のアプリケーションプログラムによって呼び出されるトランザクションンの支払いを供給するのに使用するためにユーザＣＤＥによって作成されている。この例では、作成される使用法命令ルールセットは、ユーザＣＤＥのＰＨＳアカウント（この例では名前「ＭｙＰＨＳＡｃｃｏｕｎｔ」によって指定される）を使用し、指定された失効日を有する。この使用法命令ルールセットについて定義された２つのルールのうちの２番目のルールは、さらに、適当な評価タイプおよびルール値と共に事前定義のルール属性「ＰａｙｍｅｎｔｓＡｌｌｏｗｅｄ（承認される支払い）」を使用することによって、この使用法命令ルールセットが承認できる総支払いを１０００ドルの額以下になるように制限する。この使用法命令ルールセットについて指定された第１のルールは、この使用法命令ルールセットを使用できない特定の支払い受取人を識別し、この特定の支払い受取人は、この例では、「ＤｉｓａｌｌｏｗｅｄＲｅｃｉｐｉｅｎｔ（承認されない受取人）」という、より特定の属性タイプではなく、「Ｒｅｃｉｐｉｅｎｔ（受取人）」という一般属性と、「ＩＳ−ＮＯＴ」という適当な評価タイプとを用いて指定される。他の実施形態では、対応する情報を、その代わりに、他のフォーマットを使用するＸＭＬ文書内および／またはＸＭＬ以外の形を含む、様々な他の形で提供することができる。

図１Ｃには、ＷＳ支払いハンドラシステムへの第２のプログラム的呼出しに付随するためなど、ユーザＣＤＥのアカウントのもう１つの使用法命令ルールセットを作成する第２のＸＭＬ文書１３３も示されている。具体的に言うと、この第２の使用法命令ルールセットは、この例ではアクセス制御情報を指定するためなど、支払いハンドリング以外のタイプのトランザクションに関する使用法命令ルールセットの例を示す。例えば、ユーザＣＤＥは、１以上のプログラム的サービスまたは情報のソースへのアクセスを提供するサブスクリプションまたは他のメンバシップを有する場合があるが、ユーザＣＤＥは、そのようなアクセス権がこのユーザによって提供される１以上のアプリケーションから利用可能にされるときを制限することを望む場合がある。この例では、ＸＭＬ文書１３３で作成される使用法命令ルールセットには、関連する支払い手段が含まれるのではなく、サブスクリプション／メンバシップに従ってアクセスを取得するために供給しなければならないユーザ名およびパスワードを含む様々なアクセス情報が含まれ、他の実施形態および状況では、様々な他のタイプのアクセス制御情報を、その代わりに指定し、使用することができる。

この使用法命令ルールセットは、この例では「Ａｌｌｏｗｅｄ−Ｕｓｅ（承認される使用）」というユーザ指定の名前を与えられる（例えば、図示されていない他のすべてのユーザ定義ルールと独立にこのユーザ定義ルールを参照するのに後に使用するために）ユーザ定義ルールの定義の例、ならびに、実行されたときに、図示されているように、ルールが満たされるかどうかを示す応答を提供するＵＲＩベース呼出し指定も示されている。この例では、呼出し指定には、大括弧に囲まれたパラメータ「ａｃｃｅｓｓ−ｐｒｏｖｉｄｅｒ．ｎａｍｅ」を、この使用法命令ルールセットが特定のトランザクションについてマッチングされるアクセス提供者の使用法命令ルールセットのアカウントからの対応する名前に置換することによって、特定の潜在的トランザクションに固有の情報を記入されるパラメータの表示が含まれる。そのようなユーザ定義のルールは、この使用法命令ルールセットを使用するアプリケーションおよび／またはそのアプリケーションプログラムを実行するエンドユーザに関する情報を含む、様々なタイプの情報を使用して、様々な形で特定の状況で、そのルールが満たされるかどうかに関する判定を行うことができる。同様に、ユーザ定義のルールは、ユーザ定義のルールが関連付けられる使用法命令ルールセットの作成の一部として実行可能コード（例えば、スクリプトまたはアプレット）を供給することによるものを含む、様々な他の形で、他の実施形態で、定義し、呼び出すことができる。

図１Ｄおよび１Ｅに、作成されたユーザアカウントおよび使用法命令ルールセットに関する情報を格納するのに使用される複数の例のデータベースを示す。具体的に言うと、図１Ｄは、作成されたユーザアカウントに関する様々な情報を格納する、例のアカウントデータベース１４０を示し、エントリ１４０ａ〜１４０ｂのそれぞれは、別個のユーザアカウントに対応する。この例では、各エントリに、アカウントを作成するユーザによって指定された情報だけではなく、そのアカウントについて自動的に生成され、そのアカウントに関連付けられる情報も含まれる。例えば、エントリ１４０ａは、その作成を前に図１Ａに関して述べたユーザアカウントに対応し、列１４３〜１４６には、図１Ａのセクション１１３でユーザによって指定された情報が含まれる。さらに、このアカウントが作成されたときに、ＰＨＳは、このアカウントの一意のアカウントＩＤを作成したが、このアカウントＩＤが、列１４１に格納される。さらに、この例では、ユーザＡＢＣは、図１ＡのＰＨＳアカウントの作成の前に既にＰＨＳまたは関連するシステムに既知であり、列１４２に、このユーザに以前に関連付けられた（例えば、ウェブ販売者または店に関するなど、ユーザＡＢＣについて以前に作成されたユーザアカウントの一部として）、ユーザＡＢＣのユーザＩＤが含まれる。

さらに、図１Ａに関して前に述べたように、この例の実施形態では、ＰＨＳは、ユーザのうちの少なくとも一部について、彼らのＰＨＳアカウントを支払いリポジトリまたは支払い手段として使用する能力を提供する。したがって、列１４９および１５０に、アカウントの現在の差引勘定およびアカウントについて許容される最高差引勘定（例えば、アカウント作成のときにユーザ固有の形で動的に決定され、オプションでユーザとの後の経験に基づいて調整される最高差引勘定）を含む、ユーザのＰＨＳアカウントのその態様に対応する情報が含まれるが、ユーザＡＢＣは、この例ではＰＨＳアカウントを支払いリポジトリまたは支払い手段として使用しないので、現在の勘定残高は０である。この図には示されていないが、アカウントについて以前に実行されたトランザクションの表示、アカウントに対して行われた変更、他のユーザおよびこれらのユーザがアカウントにアクセスするための関連するアクセス制御の表示など、様々な他のタイプの情報をアカウントに関連付けることができる。エントリ１４０ｂには、図１Ｃに関して前に述べた、ユーザＣＤＥのアカウントに関する類似する対応する情報が含まれる。

アカウントデータベース１４０の列１４７および１４８には、ユーザアカウントと共に使用するために定義されたすべての支払いリポジトリおよび支払い手段に関する情報が含まれる。具体的に言うと、エントリ１４０ａの列１４７の情報は、図１Ａのセクション１１４で指定された支払いリポジトリに対応し、エントリ１４０ａの列１４８の支払い手段情報は、同様に、図１４Ａのセクション１５５で指定された支払い手段に対応する。この例では、各支払いリポジトリおよび支払い手段が、一意のＩＤを与えられ、このＩＤは、列１４７および１４８に格納され、追加の例のデータベースである支払いリポジトリデータベース１８０および支払い手段データベース１９０は、それぞれユーザ指定の支払いリポジトリおよびユーザ指定の支払い手段に関する情報を格納する。この例の実施形態では、支払いリポジトリデータベースおよび支払い手段データベースのそれぞれに、それぞれ、個々の支払いリポジトリおよび支払い手段に対応する複数のエントリ１８０ａ〜１８０ｂおよび１９０ａ〜１９０ｃが含まれる。

さらに、データベース１８０および１９０には、列１８１および１９１の自動的に生成されるＩＤと、列１８２および１９２の支払いリポジトリまたは支払い手段が関連するアカウントの表示と、列１８３および１９３のリポジトリまたは手段のユーザ指定の名前と、支払いの預かりまたは請求金額について支払いリポジトリまたは支払い手段をどのように使用するかに関する列１８４〜１８６および１９４〜１９６の様々な情報とを含む、各リポジトリまたは手段の様々な情報が格納される。他の実施形態では、手段および／またはリポジトリのタイプに固有の形で（例えば、請求を行うためにクレジットカードに関連するユーザのフルネームを使用するが、銀行口座についてはそのような情報を使用しないこと）など、様々な他のタイプの追加情報を供給し、使用することができる。さらに、この図示の例では、ユーザは、前に述べたように、支払いリポジトリまたは支払い手段の使用に関する１以上の制限を定義することができ、そのような制限情報は、この例では列１８７〜１８８および１９７〜１９８に格納される。

ユーザＡＢＣは、支払いリポジトリと支払い手段（それぞれエントリ１８０ａおよび１９０ａに対応する）の両方として単一の銀行口座を使用するが、この例では、銀行口座は、これらの使用のそれぞれについて別個のＩＤを与えられ（これらのエントリの列１８１および１９１に示されているように）、しかし、他の実施形態では、単一のＩＤをその代わりに使用することができる。さらに、この図には示されていないが、他の状況で、単一の支払いソースまたは宛先の異なる使用に伴う異なる制限または他の条件を定義するためなど、単一の支払いソースまたは宛先（例えば、銀行口座）を、複数の定義された支払いリポジトリおよび／または複数の定義された支払い手段と共に使用することができる。さらに、この例では、ユーザＣＤＥは、まだユーザ指定の支払いリポジトリまたはユーザ指定の支払い手段を指定しておらず、その代わりに、支払い手段としてＰＨＳアカウントを使用することを指定している（ユーザＣＤＥは、現在、支払いをまったく受け取らないので、現在は支払いリポジトリを必要としない）。

図１Ｅに、様々な定義された使用法命令ルールセットに関する情報を格納する使用法命令ルールセットデータベース１６０を示す。具体的に言うと、エントリ１６０ａは、図１ＢでユーザＡＢＣによって定義された使用法命令ルールセットに対応し、エントリ１６０ｂは、図１ＣでＸＭＬ文書１３１によって定義された使用法命令ルールセットに対応する。この例では、各使用法命令ルールセットは、一意のＩＤを与えられ（列１６１に示されているように）、さらに、この使用法命令ルールセットを後に参照するのに使用するために自動的に生成された一意の参照トークンを与えられる（列１６３に示されているように）。この例では、参照トークンが長い乱数であるが、他の実施形態では、様々な他のタイプの情報を、参照トークンに使用することができ、一般に、この情報に、支払い命令ルールセットを参照するか他の形で示すことができるすべての情報を含めることができる。いくつかの実施形態において使用できる他のタイプの参照トークンの例に、デジタル証明書または他の信任証、鍵対の公開鍵または秘密鍵（ＰＨＳが、ユーザのアカウントに関連付けることによってなど、他方の鍵にアクセスできる場合に）、および／またはこれらの鍵のうちの１つを使用して暗号化された情報（例えば、参照トークンに関連する使用法命令ルールセットのコピー、参照トークンが属するユーザに関する情報、参照トークンが使用される潜在的トランザクションに関する情報など）が含まれる。データベース１６０に、さらに、使用法命令ルールセットが関連付けられるアカウントのアカウントＩＤ（列１６２に示されているように）、名前および使用タイプ（列１６４および１６５に示されているように）、オプションの失効日（列１６７に示されているように）、および使用法命令ルールセットと共に使用される１以上のオプションの支払いリポジトリまたは支払い手段の表示（列１６６に示されているように）を含む、使用法命令ルールセットに関する様々な他の指定された情報が含まれる。

データベース１６０には、列１６８の、使用法命令ルールセットのルールの表示も含まれ、この表示は、この例では、これらのルールに対応するルールＩＤを用いて示されている。ルールに関する追加情報は、使用法指示ルールデータベース１７０で提供される。具体的に言うと、この例の各ルールは、関連する一意のルールＩＤ（列１７１に示されているように）およびそのルールが関連付けられる使用法命令ルールセットのＩＤの表示（列１７２に示されているように）を有する。列１７３〜１７７には、特定の状況でルールが満たされるかどうかをどのように判定するかに関する様々な情報が含まれ、様々な他のタイプの情報を、同様に、他の実施形態および状況で、異なるタイプのルールに固有の形で（例えば、ユーザ定義ルールに関する呼出し詳細を格納することによって）など、そのようなルールについて格納することができる。

図３に、トランザクション承認ハンドラシステムファシリティ３４０の実施形態を実行するのに適するサーバコンピューティングシステム３００ならびにウェブサービス消費者用のコンピューティングシステム３５０およびウェブサービス提供者用のコンピューティングシステム３７０を示す。サーバコンピューティングシステムには、ＣＰＵ ３０５、様々な入出力デバイス３１０、ストレージ３２０、およびメモリ３３０が含まれる。入出力デバイスには、ディスプレイ３１１、ネットワーク接続３１２、コンピュータ可読媒体ドライブ３１３、および他の入出力デバイス３１５が含まれる。

トランザクション承認ハンドラシステムの一実施形態は、メモリ内で実行されており、トランザクション検証コンポーネント３４１、トランザクショ処理コンポーネント３４３、アカウント管理コンポーネント３４５、オプションの支払い集計コンポーネント３４７、およびオプションのセキュリティ管理コンポーネント３４９を含む。具体的に言うと、トランザクション承認ハンドラシステムは、潜在的なトランザクションの表示を受け取り、そのトランザクションを承認するかどうかを判定する。そのような潜在的なトランザクションには、ウェブサービス消費者システム３５０のメモリ３５７内で実行中のアプリケーションプログラム３５９とウェブサービス提供者システム３７０のメモリ３７７内で実行中のウェブサービスサーバ３７９との間のトランザクション、および／または１以上のそのようなシステム３５０および３７０と１以上の他のコンピューティングシステム３９０との間のトランザクションを含めることができる。

承認される潜在的なトランザクションを実行する前に、ユーザ（例えば、コンピューティングシステム３５０および３７０のユーザ）は、アカウント管理コンポーネントと相互作用して、ユーザアカウントを作成し、そのユーザアカウントに関する情報３２５が、ストレージ３２０に格納される。各そのようなユーザは、アカウント管理と相互作用して、１以上の使用法命令ルールセットも作成し、各そのような指示ルールセットに関する情報３２７が、そのユーザのアカウントに関連する形で格納される。アカウント管理は、作成されたそのような使用法命令ルールセットごとに参照トークンも作成し、その参照トークンに関する情報３２８が、使用法命令ルールセットに関連する形で格納される。作成された参照トークンが、コンピューティングシステム３５０および３７０のユーザなどのユーザに供給された後に、これらのユーザは、参照トークン３５６および３７６を、それぞれアプリケーションプログラム３５９およびウェブサービスサーバ３７９による後の使用のために、コンピューティングシステムのストレージ３５１および３７１にそれぞれ格納することができる。アカウント管理コンポーネントは、この図示の実施形態ではトランザクション承認ハンドラシステムの一部であるが、他の実施形態では、アカウント管理コンポーネント機能性の一部またはすべてを、その代わりに、トランザクション承認ハンドラシステムが相互作用する別のシステムによって実行することができる。

トランザクション承認ハンドラシステム３４０が、承認判定に関する潜在的なトランザクションの表示およびそのトランザクションの関係者の複数の参照トークンを受け取るときに、トランザクション検証コンポーネントは、それらの参照トークンに対応する使用法命令ルールセットに関する格納された情報を取り出し、これらの使用法命令ルールセットが、現在の条件の下でその潜在的なトランザクションについて満たされるかどうかを判定する。そうである場合には、トランザクショ処理コンポーネントは、料金ベースのトランザクションの関係者の間での金銭の支払い実行について手配するなど、その潜在的なトランザクションを実行しまたは他の形で処理するのを援助する。

いくつかの実施形態において、トランザクション承認ハンドラシステムは、さらに、オプションの支払い集計コンポーネント３４７およびオプションのセキュリティ管理コンポーネント３４９のうちの一方または両方を含むことができる。存在する場合に、支払い集計コンポーネントは、関係者のプリファレンスに基づいておよび／または他の情報を使用してなど、適宜、関係者に対して行われるおよび／または関係者から受け取られる支払いを集計することができる。セキュリティ管理コンポーネントは、存在するときに、トランザクションの関係者の識別を確認するため、参照トークンを供給するユーザの識別および／または承認を確認するため、ユーザアカウントおよび使用法命令ルールセットの作成および／または変更を試みるユーザのユーザ承認を実行するためなど、様々なタイプの追加のセキュリティ関連検証を実行することができる。

トランザクション承認ハンドラシステムの機能性には、異なる実施形態で様々な形でアクセスすることができる。例えば、一部のユーザは、サーバコンピューティングシステムへの物理的アクセスを有することができ、その場合に、様々な入出力デバイス３１０と相互作用して、情報を供給し、および／または受け取ることができる。その代わりに、他のユーザは、クライアントコンピュータシステムを使用して、ネットワーク３８０を介してリモートに（例えば、インターネットおよび／またはワールドワイドウェブを介して）など、このシステムに直接にアクセスすることができる。そのようなユーザは、メモリ３６０内で実行されるブラウザ（図示せず）など、そのクライアントコンピュータシステム上で提供されるソフトウェアまたは他の機能性を使用して、トランザクション承認ハンドラシステムと相互作用することができる。他の実施形態では、ユーザは、その代わりに、１以上の他のコンピュータとの相互作用を介して間接的にトランザクション承認ハンドラシステムから機能性および／または情報を受け取ることができ、この１以上の他のコンピュータは、その機能性または情報をユーザに提供する前に、トランザクション承認ハンドラシステムからその機能性または情報を直接に受け取ることができる。さらに、トランザクション承認ハンドラシステムコンポーネントの一部またはすべてが、様々なフィードバックまたは他の一般的なタイプの情報をユーザに（例えば、ユーザ要求に応答して）供給することができ、この情報を、サーバシステムのディスプレイ３１１上またはクライアントシステム上の入出力デバイス３５４または３７４のうちの１つの上でユーザに提示することができる。

当業者は、コンピューティングシステム３００、３５０、および３７０が、単に例示的であり、本発明の範囲を限定することを意図されていないことを理解するであろう。コンピューティングシステム３００を、インターネットなどの１以上のネットワークを介してまたはワールドワイドウェブ（「ウェブ」）を介してを含めて、図示されていない他のデバイスに接続することができる。より一般的に、「クライアント」デバイスまたは「サーバ」デバイスには、コンピュータ、ネットワークデバイス、インターネットアプライアンス、ＰＤＡ、無線電話機、セル電話機、ポケットベル、電子オーガナイザ、テレビジョンベースのシステム、および相互通信機能を含む様々な他の消費者製品を含む、相互作用できるハードウェアまたはソフトウェアのすべての組合せを含めることができる。例えば、コンピューティングシステム３５０のうちの１つを、セル電話機、無線ＰＤＡ、または他のポータブルデバイスとすることができ、その電話機／ＰＤＡ／デバイスのユーザは、１以上の提供者コンピューティングシステム３７０とのトランザクションのハンドリングなど、トランザクショ処理システム３４０の機能を使用することをもたらす１以上の選択を行うことができる。さらに、図示のトランザクション承認ハンドラシステムコンポーネントによって提供される機能性は、いくつかの実施形態において、より少数のコンポーネントに組み合わせるか、追加コンポーネントに分散させることができる。同様に、いくつかの実施形態において、図示のコンポーネントの一部の機能性を、提供しないものとすることができ、および／または、他の追加の機能性を利用可能にすることができる。

当業者は、様々なアイテムが、使用されている間にメモリ内またはストレージ上に格納されるものとして図示されているが、これらのアイテムまたはその一部を、メモリ管理およびデータ保全性のためにメモリと他のストレージデバイスとの間で転送できることも理解するであろう。その代わりに、他の実施形態で、ソフトウェアモジュールおよび／またはコンポーネントの一部またはすべてが、別のデバイスのメモリ内で実行し、コンピュータ間通信を介して図示のコンピューティングデバイスと通信することができる。トランザクション承認ハンドラシステムコンポーネントまたはデータ構造の一部またはすべてを、ハードディスク、メモリ、ネットワーク、または適当なドライブによって読み取られるポータブル物品などのコンピュータ可読媒体に格納することもできる（例えば、命令または構造化データとして）。トランザクション承認ハンドラシステムコンポーネントおよびデータ構造を、無線ベース媒体および有線／ケーブルベース媒体を含む様々なコンピュータ可読伝送媒体上で、生成されたデータ信号として（例えば、搬送波の一部として）伝送することもできる。したがって、本発明を、他のコンピュータシステム構成と共に実践することができる。

図４は、ユーザアカウント管理ルーチン４００の実施形態の流れ図である。このルーチンは、ユーザが、アカウントと共に使用される使用法命令ルールセットを定義することを含めて、トランザクション承認およびハンドラシステムと共に使用されるアカウントを作成し、変更することを可能にする。いくつかの実施形態においては、このルーチンを、ユーザが対話できる対話型ユーザインターフェースの一部として（例えば、ウェブサイトの１以上のウェブページの一部として）実施することができ、他の実施形態では、このルーチンを、その代わりに、ユーザの代わりの１以上のプログラム的呼出しに応答して実行することができる（例えば、ユーザの代わりにアクセスされる１以上のウェブサービスの一部として）。

このルーチンは、ステップ４０５で開始され、ここで、アカウントに関連する指示を受け取る。ステップ４１０で、このルーチンは、その指示がアカウントの作成に関連するかどうかを判定し、そうである場合には、ステップ４１５に継続して、アカウントの定義に関連する様々な情報を受け取る。例えば、いくつかの実施形態において、ユーザは、アカウント名、アカウントパスワードまたは他のセキュリティアクセス機構、そのアカウントと共に使用される１以上の支払い手段の表示、そのアカウントと共に使用される１以上の支払いリポジトリの表示などを供給することができる。次に、このルーチンは、ステップ４２０で継続して、いくつかの実施形態においては一意のアカウントＩＤ、請求金額を含むことのできる支払い手段としてアカウントを使用できる場合にユーザについて許容される最高差引勘定など、アカウントの使用に関連する追加情報を自動的に生成する。ステップ４２５で、このルーチンは、受け取られたおよび生成されたアカウント情報を使用してアカウントを作成し、ステップ４３０で、アカウントの作成者に新しいアカウントの参照を供給する（例えば、アカウントＩＤの表示）。

ステップ４１０で、その代わりに、受け取られた指示がアカウントの作成に関連しないと判定された場合には、このルーチンは、ステップ４３５に継続して、アカウントの変更に関連する情報を受け取り、ステップ４４０で、適当である場合に、示された通りにアカウントを変更する。ステップ４４５で、このルーチンは、アカウント変更に、使用法命令ルールセットの作成または変更が含まれたかどうかを判定する。そうである場合には、このルーチンは、ステップ４５０で継続して、指示ルールセットへの後の参照を可能にするために、使用法命令ルールセットに関連する一意の参照トークンを生成する。ステップ４５５で、このルーチンは、使用法命令ルールセットを参照するのに後に使用される参照トークンの表示をアカウント所有者に供給する。ステップ４３０または４５５の後に、またはその代わりに、ステップ４４５でアカウント指示が使用法命令ルールセットの作成または変更に関連しないと判定された場合に、このルーチンは、ステップ４６０で継続して、現在のアカウントに対する変更を行い続けるかどうかを判定する。そうである場合には、このルーチンはステップ４３５に戻り、そうでない場合には、このルーチンはステップ４９９に継続し、終了する。

この図には示されていないが、他の実施形態で、アカウントに関する情報を供給することによって、ユーザがアカウントを再検討できるようにするなど、ユーザアカウントに関連する追加の機能性を提供することができる。さらに、いくつかの実施形態において、追加のセキュリティ制御を使用して、アカウントの作成および／または変更を試みるユーザが、それを行うことを承認されることを保証することができる。さらに、いくつかの実施形態において、ユーザアカウントを、トランザクション承認およびハンドリング機能を提供するシステムと別個の会社または他の実体に関連付けることができる。

図５は、トランザクション承認およびハンドラルーチン５００の実施形態の流れ図である。このルーチンは、承認されるか他の形で処理されるトランザクションの表示と、そのトランザクションの複数の関係者からの使用法命令ルールセットに対応する参照トークンの表示とを受け取り、使用法命令ルールセットに互換性があるときにそのトランザクションを承認すると判定する。いくつかの実施形態において、このルーチンは、１以上のウェブサービスを介するなど、プログラム的に呼び出されるが、他の実施形態では、このルーチンを、その代わりに他の形で（例えば、グラフィカルユーザインターフェースを介して対話的に）呼び出すことができる。

このルーチンは、ステップ５０５で開始され、ここで、複数関係者トランザクションの表示および複数の関係者のそれぞれの参照トークン（例えば、トランザクションの複数の関係者ごとに１つ）の表示を受け取る。次に、このルーチンは、ステップ５１０に継続して、トークンに対応する使用法命令ルールセットを取り出し、いくつかの実施形態において、さらに、これらの使用法命令ルールセットの一部またはすべてが属するユーザアカウントからの他の情報を取り出すか、他の形で利用可能にすることができる。

このルーチンは、次に、ステップ５１５に継続して、関係者によって供給される追加のセキュリティ情報に基づくなど、関係者がトークンを使用することを承認されるかどうかを判定するためにセキュリティ検証を実行するかどうかを判定する。そうである場合には、このルーチンは、ステップ５２０に継続して、トークンを使用するための関係者の承認を示すセキュリティ情報を取得し、検証することを試み、ステップ５２５で、そのような承認が検証されたかどうかを判定する。他の実施形態では、その代わりに、トークン自体の指示ルールセットの使用にその使用法命令ルールセットの使用が承認されるときを制御するルールまたは他の制限が含まれるときなど、そのようなトークンを使用するためのそのようなセキュリティ承認または他のアクセス承認を、実行しないものとすることができる。

ステップ５２５で、トークン使用承認が検証されると判定された場合に、または、ステップ５１５で、セキュリティ検証を実行しないと判定された場合に、このルーチンは、サブルーチン５３０の実行に継続して、図６に関してより詳細に述べるように、取り出された使用法命令ルールセットに基づいてトランザクションを妥当性検査する。ステップ５３５で、トランザクションが妥当性検査されると判定される場合には、このルーチンは、サブルーチン５４５の実行に継続して、図７Ａおよび７Ｂに関してより詳細に述べるように、トランザクションのタイプに固有の形でなど、示されたトランザクションの実行を試みる（例えば、料金ベースのトランザクションに関する金銭の支払いを行うために）。他の実施形態では、このルーチンは、その代わりに、トランザクションが承認されるかどうかを単に判定し、トランザクションの実行は他に委ねることができる。

ステップ５４５の後に、ステップ５５０で、示されたトランザクションの実行に成功したと判定される場合には、このルーチンは、ステップ５５５に進んで、ルーチン５００がウェブサービスの一部として呼び出された場合に応答ＸＭＬ文書内でなど、成功の表示を返す。その代わりに、ステップ５２５で、使用承認が検証されないと判定された場合、または、ステップ５３５で、トランザクションが妥当性検査されないと判定された場合、または、ステップ５５０で、トランザクション実行が成功しないと判定された場合には、このルーチンは、その代わりにステップ５４０に継続して、このルーチンがウェブサービスの一部として呼び出された場合に応答として送られるＸＭＬ文書としてなど、エラーメッセージを返す。ステップ５４０または５５５の後に、このルーチンは、ステップ５９９に継続し、終了する。

図６は、トランザクション妥当性検査サブルーチン５３０の実施形態の流れ図である。このサブルーチンは、トランザクションの表示およびそのトランザクションの関係者によって指定された複数の使用法命令ルールセットの表示を受け取り、それらのルールおよび使用法命令ルールセットの他の情報に基づいて、そのトランザクションが妥当性検査されるかどうかを判定する。

このサブルーチンは、ステップ６０５で開始され、ここで、トランザクションの表示および複数の使用法命令ルールセットの表示を受け取る。ステップ６１０で、その使用法命令ルールセットを使用できるトランザクションに関連する判断基準を指定する各ルールおよび／またはその使用法命令ルールセットを使用できるトランザクションの関係者に関する情報を指示する各ルールを選択し、それらのルールが満たされるかどうかを判定するために、そのトランザクションおよび／またはこれらの他の関係者に関する情報を取り出す。例えば、トランザクションの別の関係者に関する情報を取得するために、その、他の関係者に関連するユーザアカウント（例えば、その、他の関係者からのトークンの使用法命令ルールセットが関連付けられたユーザアカウント）からの情報、ならびに他の形で（例えば、ウェブサービス呼出しの一部として使用されたＨＴＴＰヘッダからなど、トランザクションハンドリングルーチンに関する呼出し要求に基づいて）アクセス可能とすることができる他の関係者に関する情報を、取得することができる。同様に、トランザクションに関する情報を、ルーチン呼出しの一部として（例えば、トランザクションオブジェクトまたはトランザクションについて供給される文書の一部として）受け取られる情報に基づいて、またはその代わりに外部ソースから、取得可能とすることができる。

ステップ６１０の後に、このサブルーチンは、ステップ６１５で継続して、ユーザ定義ルールではない、許容できるトランザクションに関連する他の条件を指定する、他の指定されたルールを識別し、すべてのそのような指定されたルールが、他の指定された使用法命令ルールセットからのルールおよび／またはトランザクション自体と互換性があるかどうかを判定する。次に、このサブルーチンは、ステップ６２０で継続し、すべてのユーザ定義ルールを、そのルールについて指定された形で呼び出し、これらのルールが満たされるかどうかを示す応答を取得する。ステップ６２０の後に、このサブルーチンは、ステップ６３０に継続して、指定された使用法命令ルールセットのルールのすべてが満たされたかどうかを判定する。そうである場合には、このサブルーチンは、ステップ６４０に継続し、トランザクションが妥当性検査されることの表示を返し、そうでない場合には、その代わりにステップ６３５に継続して、トランザクションが妥当性検査されないことの表示を返す。ステップ６３５または６４０の後に、このサブルーチンは、ステップ６９９に継続し、終了する。

他の実施形態では、トランザクション妥当性検査を、その代わりに、様々なタイプのルールを異なる順序で評価することによっておよび／またはいずれかのルールが満たされないとわかった場合にさらなるルール評価を停止することによってなど、他の形で実行することができる。その代わりに、他の実施形態で、トランザクションが妥当性検査されるかどうかの判定を、使用法命令ルールセット自体がこれらのルールセットのルールの間の他のタイプの相互関係を示す場合におよび／または他の事前定義の判断基準（例えば、パーセンテージの最小閾値または満たされなければならない指定されたルールのサブセット）に基づいてなど、すべての指定されたルールのすべてを満たすことを要求すること以外の形で実行することができる。

図７Ａおよび７Ｂは、支払い実行ハンドリングトランザクションサブルーチン５４５の実施形態の流れ図である。このサブルーチンは、あるタイプのトランザクションについて実行できるハンドリングの１タイプの例であり、この場合には、トランザクションの少なくとも１つの部分がトランザクションの少なくとも１つの他の関係者に支払いを与えることである、支払いハンドリングトランザクションである。

このサブルーチンは、ステップ７０５で開始され、ここで、支払いトランザクションの表示（例えば、支払額の表示およびおそらくは他の支払い関連条件の表示）ならびに少なくとも１つの支払い提供者および少なくとも１つの支払い受取人のそれぞれの参照トークンの表示を受け取る。ステップ７１０で、このサブルーチンは、支払い提供者ごとに、その支払い提供者によって供給されたトークンに対応する使用法命令ルールセットに関連する支払い手段に基づくなど、使用される支払い手段およびその支払い手段に関するすべての定義された支払い制限を判定する。同様に、ステップ７１５で、このサブルーチンは、支払い受取人ごとに使用される支払いリポジトリおよびすべての定義された支払い制限を判定する。ステップ７２０で、このサブルーチンは、最低現在請求金額、最高現在請求金額、最低累積差引勘定、最高累積差引勘定などに基づくなど、トランザクションによって示される１以上の支払いが、支払い手段および／または支払いリポジトリに関するすべての定義された支払い制限を満たすかどうかを判定する。

ステップ７２０の後に、このサブルーチンは、ステップ７２５に継続して、支払いがすべての定義された支払い制限を満たすかどうかを判定し、そうである場合には、ステップ７３５に継続して、そのような支払いごとに、請求金額について支払い手段に別々に請求書を送るか、あるいはその代わりに、周期的な基礎で（例えば毎月）または最低累積請求金額に達するまでなど、他の支払いと一緒にこの支払いを集計するかどうかを判定する。支払いの請求金額を集計しないと判定された場合には、このサブルーチンは、ステップ７４０に継続して、その支払いに関して対応する支払い手段に即座に請求するが、その代わりに、ステップ７３５で請求金額を集計すると判定された場合には、このサブルーチンは、ステップ７４５に継続して、その支払い手段に関する後の集計された請求のために請求金額の表示を格納する。図示されてはいないが、ステップ７３５〜７４５は、複数の支払いを行わなければならない場合に、トランザクションの支払いごとに複数回繰り返すことができる。

ステップ７４０または７４５の後に、このサブルーチンは、ステップ７５０で継続して、各支払いを対応する支払いリポジトリに直接に預けるか、あるいはその代わりに、集計支払いを預ける前に他の支払いと一緒に支払いを集計するかを判定する。支払いを集計しないと判定される場合には、このサブルーチンは、ステップ７５５に継続して、各そのような支払いを適当な支払いリポジトリに即座に預けるが、その代わりに、ステップ７５０で支払いを集計すると判定される場合には、このサブルーチンは、その代わりにステップ７６０に継続して、適当な支払いリポジトリへの後の集計された預金のために支払いの表示を格納する。この図には示されていないが、ステップ７５０〜７６０を、トランザクションについて行われる支払いごとに実行することができる。

ステップ７５５または７６０の後に、このサブルーチンは、ステップ７６５に継続して、支払いが成功したことの表示を返す。その代わりに、ステップ７２５で、トランザクションによって示される支払いが、１以上の定義された支払い制限を満たさないと判定された場合には、このサブルーチンは、その代わりに、ステップ７３０に継続して、支払いが成功しなかったことの表示を返す。いくつかの実施形態において、支払いおよび／または預金を集計する能力は、複数の支払いまたは預金が最低額制限を満たせるようにするためなど、いずれかの定義された支払い制限が満たされるかどうかを判定するときに考慮されるが、他の実施形態では、各そのような支払いが、個別に考慮される。その代わりに、他の実施形態では、支払い預金集計および／または支払い請求金額集計を実行しないものとすることができる。ステップ７３０または７６５の後に、このサブルーチンは、ステップ７９９に継続し、終了する。

当業者は、いくつかの実施形態において、上で述べたルーチンによって提供される機能性を、より多数のルーチンの間で分割する、またはより少数のルーチンに合併するなど、代替の形で提供できることも理解するであろう。同様に、いくつかの実施形態において、示されたルーチンは、他の図示のルーチンがその代わりにそれぞれそのような機能性を欠くか含むときまたは提供される機能性の量が変更されるときなど、説明したものより多数またはより少数の機能性を提供することができる。さらに、様々な動作を、特定の形で（例えば、直列にまたは並列に）および／または特定の順序で実行されるものとして示す場合があるが、当業者は、他の実施形態で、これらの動作を異なる順序でおよび異なる形で実行できることを理解するであろう。当業者は、単一のデータ構造を複数のデータ構造に分割させることによって、または複数のデータ構造を単一のデータ構造に合併させることによってなど、上で述べたデータ構造を異なる形で構成できることも理解するであろう。同様に、いくつかの実施形態において、他の図示のデータ構造がその代わりにそれぞれそのような情報を欠くか含むときまたは格納される情報の量もしくはタイプが変更されるときなど、図示のデータ構造が、説明されたものより多数またはより少数の情報を格納することができる。

次は、使用法命令ルールセットおよび使用法命令ルールセットのルールを定義し、使用する技法の例示的例を提供するが、本発明がこれらの詳細に限定されることは意図されていない。

特定の支払いの送り手または受取人にトランザクションを制限する例は、次の通りである。

承認される受取人トークン

受取人のトークンが、ｔｏｋｅｎ１と正確に一致する場合に、そのトランザクションは承認される。このルールは、すべての関係者（送り手、受取人、呼出し側）から利用可能である。複数の承認される受取人トークンの指定の例に、次が含まれる。

ブロックされる送り手トークン

このトランザクションは、送り手のトークンがｔｏｋｅｎ１と一致する場合には承認されない。このルールは、すべての関係者（送り手、受取人、呼出し側）から利用可能である。複数のブロックされる受取人トークンの指定の例に、次が含まれる。

秘密作成ハンドシェークの例は、次の通りである。

これは、送り手と受取人がある条件に合意するために秘密ハンドシェークを交換する例である。両方の関係者がこの定義されるルールに似たルールを有しない場合には、トランザクションは承認されない。

送り手の秘密

秘密ハンドシェークルールについて、送り手および受取人が同一の値を定義しない場合に、トランザクションは承認されない。任意のストリングを‘ｒｕｍｐｌｅｓｔｉｌｓｋｉｎ’の代わりに使用することができ、事前定義の参照でない限り、任意の参照名をＳｈａｒｅｄＳｅｃｒｅｔＳｅｎｄｅｒおよびＳｈａｒｅｄＳｅｃｒｅｔＲｅｃｉｐｉｅｎｔの代わりに使用することができる。

受取人の秘密

秘密ハンドシェークルールについて、送り手および受取人が同一の値を定義しない場合に、トランザクションは承認されない。任意のストリングを‘ｒｕｍｐｌｅｓｔｉｌｓｋｉｎ’の代わりに使用することができ、事前定義の参照でない限り、任意の参照名をＳｈａｒｅｄＳｅｃｒｅｔＳｅｎｄｅｒおよびＳｈａｒｅｄＳｅｃｒｅｔＲｅｃｉｐｉｅｎｔの代わりに使用することができる。

使用制限付き参照トークンを作成する例は、次の通りである。

支払い命令ルールセットは、支払いを行うのにトークンを使用できる回数、トークンを使用できる総額、またはトークンの失効日を制限することができる。これらのルールは、そのトークンの使用法だけに適用され、したがって、送り手の支払い命令ルールセットは、送り手のトークンの使用法しか制限することができない。同様に、同一のことが、呼出し側および受取人にあてはまる。

使い捨てトークン

このルールは、トークンが１回使用された後に、そのトークンが働くのをやめさせる。このルールは、それ自体の支払い命令ルールセットだけに適用され、したがって、送り手の指示ルールセットは、その使用法を制限することしかできない。

使用回数を制限する

このルールは、トークンが５回使用された後に、そのトークンが働くのをやめさせる。

総額を制限する

失効日

このルールは、２００５年１月３０日にトークンが働くのをやめさせる。この日の深夜（グリニッジ標準時００：００）から以降に、このトークンを使用するすべてのトランザクションは承認されない。

受取人としてのみ使用する

このルールは、このトークンが受取人のトークンとして使用されない限り、このトークンに支払いを承認させなくする。

呼出し側としてのみ使用する

このルールは、このトークンが呼出し側のトークンとして使用されない限り、このトークンに支払いを承認させなくする。

受取人としてのみ使用する

このルールは、このトークンが送り手のトークンとして使用されない限り、このトークンに支払いを承認させなくする。

トランザクションの額の制限の例は、次の通りである。

トランザクション額制限ルールは、すべての関係者から利用可能である。

最高トランザクション額

最低トランザクション額

このルールは、トランザクション額を１米国ドル以上に制限する。トランザクションがこの額未満である場合には、このルールは、そのトランザクションを承認しない。

トランザクション通貨を制限する

このルールは、トランザクション通貨を日本円に制限する。トランザクション通貨が日本円でない場合には、そのトランザクションは承認されない。

支払い提供者／送り手が支払い詳細を指定する例は、次の通りである。

送り手は、支払いがクレジットカード、自動支払処理装置（または「ＡＣＨ」）銀行口座、または既存勘定残高のどれから行われるかなど、支払い方法を指定する。

残高繰越し

このルールは、資金が既存勘定残高からとられることを指定する。

デフォルトＡＣＨ銀行口座

このルールは、アカウントのデフォルトＡＣＨ銀行口座が使用されることを指定する。デフォルトＡＣＨ口座は、ＣｒａｔｅＡｃｃｏｕｎｔメッセージまたはＳｅｔＤｅｆａｕｌｔＦｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔメッセージを介するなど、様々な形で指定することができる。

特定のＡＣＨ銀行口座

このルールは、ｆｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔＲｅｆｅｒｅｎｃｅによって参照される特定のＡＣＨ銀行口座を指定する。金銭的手段参照が、ｉｎｓｔａｌｌＡＣＨＢａｎｋＡｃｃｏｕｎｔメッセージから返される。この例では、金銭的手段参照は、銀行口座番号ではなく、銀行口座番号は、いくつかの実施形態において、プライバシの理由から支払い命令ルールセットに含まれない場合がある。ＰａｙｍｅｎｔＭｅｔｈｏｄは、他の支払い命令ルールセットでそれに反するアサーションを行うことを可能にするように指定されなければならない。

デフォルトクレジットカード

このルールは、アカウントのデフォルトクレジットカードが使用されることを指定する。デフォルトクレジットカードは、ＣｒａｔｅＡｃｃｏｕｎｔメッセージまたはＳｅｔＤｅｆａｕｌｔＦｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔメッセージを介するなど、様々な形で指定することができる。

特定のクレジットカード

このルールは、ｆｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔＲｅｆｅｒｅｎｃｅによって参照される特定のクレジットカード銀行口座を指定する。支払い手段参照が、ｉｎｓｔａｌｌＣｒｅｄｉｔＣａｒｄメッセージから返される。この例では、金銭的手段参照は、クレジットカード番号ではなく、クレジットカード番号は、いくつかの実施形態において、プライバシの理由から支払い命令ルールセットに含まれない場合がある。ＰａｙｍｅｎｔＭｅｔｈｏｄは、他の支払い命令ルールセットでそれに反するアサーションを行うことを可能にするように指定されなければならない。

支払い受取人が論争解決ポリシを指定する例は、次の通りである。

論争解決は、送り手が特定のトランザクションに関する論争を登録するときに行われる可能性がある。受取人の支払い命令ルールセットによって指定される場合に、論争を解決するために、自動払戻しが受取人から送り手に発行される。論争は、送り手によって開始され、受取人によって指定された論争解決ポリシによって決定される。この例の実施形態では、通常の払戻しは、論争されず、受取人がいつでも要求することができ、これらのルールによって指定される論争解決ポリシと無関係に必ず成功する。

「送り手が勝つ」期限

このルールは、送り手がトランザクションから１５日以内に論争を登録した場合に、自動払戻しが発行されることを指定する。

自動払戻しなし

このルールは、送り手が論争を登録する場合に発行される自動払戻しがないことを指定する。

「送り手が勝つ」払戻しの分数またはパーセンテージの限度

このルールは、トランザクション額の５０％だけが、論争を解決するために払い戻されることを指定する。

呼出し側／エンドユーザまたは支払い受取人が支払い方法を制限する例は、次の通りである。

呼出し側および／または受取人は、資金がどこから来るかに関する制限を設けることができる。例えば、呼出し側がトランザクション料金について支払おうとしている場合に、その呼出し側は、クレジットカードトランザクション料金が他の方法より高価なので、支払いのソースが「クレジットカード」ではないことを確かめることを望む場合がある。

残高繰越のみ

このルールは、支払い方法が残高繰越でない場合にトランザクションを承認しない。

残高繰越およびＡＣＨのみ

このルールは、支払い方法が残高繰越でもＡＣＨでもない場合にトランザクションを承認しない。

クレジットカード以外

このルールは、支払い方法がクレジットカードである場合にトランザクションを承認しない。

支払われる料金の分数の制限の例は、次の通りである。

料金パーセンテージは、呼出し側によってＰａｙメッセージに渡される。すべての関係者が、これらのルールを使用することができる。

送り手の総料金の分数を制限する

このルールは、送り手が、支払われる総料金の５０％を超えて支払おうとしている場合に、トランザクションを承認しない。

受取人の総料金の分数を制限する

このルールは、受取人が、支払われる総料金の８０％を超えて支払おうとしている場合に、トランザクションを承認しない。

呼出し側の総料金の分数を制限する

このルールは、受取人が、支払われる総料金の１／３を超えて支払おうとしている場合に、トランザクションを承認しない。

支払い命令ルールセットに利用可能であり、支払い要求メッセージ（例えば、呼出し側からトランザクション承認者への）の一部としてＸＭＬ文書として送ることができるコンテキストデータの例は、次の通りである。

トークンに利用可能なコンテキストデータの例は、次の通りである。

トランザクションに関する支払いを承認するのに支払い命令ルールセットを使用する例は、次の通りである。

この例では、トランザクションに、呼出し側関係者が送り手関係者によって提供されるアプリケーションプログラムを使用する受取人関係者にウェブサービスを要求することが含まれる。呼出し側は、トランザクション承認者によって請求される、要求されるサービスに関連する料金を支払おうとしており、送り手は、トランザクションのコストを支払おうとしており、トランザクション額は、５０．００米国ドルである。第三者トランザクション承認者へのトランザクション承認呼出しの一部として渡されるパラメータの値は、次の通りである。

・ ＣａｌｌｅｒＦｒａｃｔｉｏｎＯｆＦｅｅｓ：＝１００％
・ ＳｅｎｄｅｒＦｒａｃｔｉｏｎＯｆＦｅｅｓ：＝０％
・ ＲｅｃｉｐｉｅｎｔＦｒａｃｔｉｏｎＯｆＦｅｅｓ：＝０％
・ ＴｒａｎｓａｃｔｉｏｎＡｍｏｕｎｔ：＝ＵＳＤ５０．００
すべてのオプションのパラメータは、トランザクションと共に保存されるが、トランザクションの実行には影響しない。

データ取出しおよびアカウント検証
トランザクション承認者は、呼出し側、受取人、および送り手のトークンを含むトランザクション承認呼出しを呼出し側から受け取り、これらのトークンに関連するデータを取り出す。取り出されるデータは、次の通りである。

・ 対応するトークンによって識別される、関係者のそれぞれのアカウント情報、すなわち、
・ アカウントＩＤ
・ 状況（アクティブ、クローズド、一時停止）
・ 差引勘定
・ 利用可能な差引勘定
トランザクション承認者は、様々な関係者のアカウントが存在し、すべてがアクティブであることを検証する。アカウントのいずれかが非アクティブである場合には、トランザクションは承認されず、エラーが返される。そうでない場合には、トランザクション承認者は、継続して、支払い命令ルールセットに関連する次のデータを取り出す。

・ トークンによる、関係者のそれぞれの支払い命令ルールセットおよび統計、すなわち、
・ 支払い命令ルール
・ 使用量総カウント：これまでにそのトークンによって承認されたトランザクションの個数
・ 使用量総額：これまでにそのトークンによって承認されたトランザクション額（絶対値）の合計
・ 料金、デフォルト、および承認される値を指定するための、トランザクション承認者自体の支払い命令ルール。

指示セットを、トークン役割のそれぞれについて下に示し、その後、説明する。

送り手：

受取人：

呼出し側：

トランザクション承認者：

トランザクション承認者は、取り出されたデータを、承認呼出し内の支払い要求メッセージで受け取られたデータとマージし、様々な関係者の支払い命令ルールセットを評価する。

支払い命令ルールセットを評価する
次では、評価を述べ、様々な支払い命令ルールの間の相互作用を示す。ここで提示される支払い命令ルールセットのすべてが、合意に達する。

送り手：

送り手は、各トランザクションの額を５０ドルまでに制限しようとしている。これは、トークンの総使用回数を制限しない（次のアイテムを参照されたい）。

送り手：

送り手は、トークンの使用量を合計１０回または合計７５ドルのうちの最初に達した方に制限しようとしている。

送り手：

受取人：

送り手のトークンは、２００４年６月１日まで使用することだけができ、受取人のトークンは、２００４年１０月１日まで使用することだけができる。

送り手：

受取人：

送り手は、すべての料金を支払わないことをアサートする。受取人は、呼出し側がすべての料金を支払うというより厳格な要件を有する。

送り手：

呼出し側：

トランザクション承認者：

送り手は、支払い方法にＡＣＨをセットしようとしているが、これは、資金が、トランザクション承認者の送り手のアカウントに関連するデフォルトＡＣＨ銀行口座から引き出されることを意味する。呼出し側は、料金の１００％を支払おうとしているので、呼出し側は、呼出し側のコストを低く保つために、支払い方法がＡＣＨまたは残高繰越のいずれかでなければならないことのアサーションを行う。トランザクション承認者の支払い命令ルールセットは、ＰａｙｍｅｎｔＭｅｔｈｏｄがセットされていることを確かめ、その値を制限する。

受取人：

送り手：

受取人は、送り手がトランザクション日付の後１０日までの間に１００％の払戻しを受け取ることを可能にする論争解決ポリシを指定する。送り手は、受取人がトランザクション日付の後少なくとも１０日の間に９０％以上の払戻しに合意する論争解決ポリシを指定しない限り、支払いを拒否する。この送り手および受取人は、意見が一致している。

トランザクションを実行する
支払い命令ルールセットの評価から、次の変数がわかる。

・ ＰａｙｍｅｎｔＭｅｔｈｏｄ：＝‘ａｃｈ’
・ ＳｅｎｄｅｒＷｉｎｓＴｉｍｅＬｉｍｉｔ：＝１０ｄａｙｓ
・ ＳｅｎｄｅｒＷｉｎｓｔＦｒａｃｔｉｏｎＬｉｍｉｔ：＝１００％

トランザクション承認者は、主トランザクションの資金の供給源として使用される送り手のデフォルトＡＣＨ金銭的手段をルックアップする。料金スケジュールによれば、ＡＣＨトランザクションは、５０ドルのトランザクションについて０．６０ドルのコストがかかる（１．０％＋１トランザクションあたり０．１０ドル）。トランザクション承認者は、呼出し側に返されるトランザクションＩＤも生成する。このすべてに基づいて、トランザクション承認者は、次を実行する。

・ 送り手の銀行口座からＡＣＨを介して５０．００ドルを引き出す
・ トランザクション承認者の送り手のアカウントに５０．００ドルを預ける
・ トランザクション承認者の送り手のアカウントからトランザクション承認者の受取人のアカウントへの５０．００ドルの残高繰越しを実行する
・ トランザクション承認者の呼出し側のアカウントからトランザクション承認者への０．６０ドルの残高繰越しを実行する

参照および説明は、論争解決変数と共に、すべてがトランザクションデータに格納される。勘定残高は、上のトランザクションの実行の間に更新される。

支払い応答メッセージ
トランザクションが成功であったので、トランザクションＩＤが、支払い応答メッセージの一部として呼出し側に返される。

いくつかの実施形態において、使用法命令ルールセットは、なんらかのイベントが承認されるか否かを検査するのに使用され、コンテキストデータに対して評価されるルールのセット（「アサーション式」または「アサーション」とも称する）を含み、それらのルール／アサーションがコンテキストデータの所与のセットについて真と評価される場合には、イベントが承認される。使用法命令ルールセットを定義する言語の例は、次の通りである。

アサーションの例
この例の言語では、アサーションは、真または偽に評価される式（すなわち、ブール式）である。代入を使用して、変数の値をセットすることもできる。指示ルールセット内のアサーションのすべてが真と評価される場合には、トランザクションが承認され、そうである場合には、代入される変数（ある場合に）の値を使用して、そのトランザクションの実行を指示することができる。

最も単純な支払い命令ルールセットは、次のテキストからなる。というのは、このテキストが必ず真に評価されるからである。

論理演算子、いくつかの単純な式、およびリテラルを有するより多くのアサーションを追加する。それがどのように見えるかを示す

上の支払い命令ルールセットは、必ず真に評価される（２００４年１２月５日の前である限り）。

この例の言語の式は、演算子優先順位に関してＰｅｒｌまたはＣの式に類似する。例示のために、次の式を参照されたい。

上の式は、真に評価される。というのは、上の式が、次式と同等であるからである。

より一般的に、演算子評価の優先順位は、次の順序である。

１）リテラル、ブラックボード間接参照（ｂｌａｃｋｂｏａｒｄ ｄｅｒｅｆｅｒｅｎｃｅ）、および括弧（）内の式
２）ネゲート−否定！
３）乗算＊除算／、左から右へ
４）マイナス−プラス＋、左から右へ
５）等しい＝＝不等！＝未満＜超＞以下＜＝以上＞＝、ｉｎ、ｎｏｔＩｎ
６）論理積＆＆、左から右へ
７）論理和｜｜、左から右へ

やはりＣまたはＰｅｒｌに似て、ホワイトスペースは、この例の言語では無視され、したがって、タブ、スペース、および改行は、重要でない（ストリング引用符内を除く。ストリング引用符内では、正確なフォーマッティングが保存される）。

代入の例
ユーザは、変数を作成し、代入ステートメントを作ることによって変数の値をセットすることができる。代入ステートメントは、次のような外見を有する。

次のステートメントは、ＭｙＦａｖｏｒｉｔｅＡｍｏｕｎｔという名前のｍｏｎｅｙ型の変数を作成し、その値に７．９９米国ドルをセットする。

変数は、支払い命令ルールセットの評価全体を通じて値を変化させない。１つの変数に関する複数の代入ステートメントを設けることができる（異なる支払い命令ルールセット内であっても）が、すべての値が一致しなければならず、さもなければ、この状態はアサーション失敗として扱われる。変数は、ブラックボードに格納され、これは、ユーザがアサーションで変数を間接参照できることを意味する。支払い命令ルールセット（または同時に評価される別の支払い命令ルールセット）で代入される変数は、どの式においても使用することができる。

コンテキストブラックボード
リテラルを有する式を処理することは、かなり無益である。というのは、これらが、必ず同一の結果に評価されるからである。実際には、支払い命令ルールセットは、コンテキストデータのあるセットに対して評価され、このセットは、この例の言語では、ブラックボードと呼ばれるメモリ領域に格納される。この例では、ブラックボードは、ストリングキーからスカラ値への単純なマップである。ストリングキーは、通常、大文字から始まる。名前は、大文字小文字の区別がある。ブラックボードは、イベントに固有のデータを提供する。

式内でブラックボードデータを間接参照するには、参照名を単純に式に含める。

ブラックボード間接参照は、スカラ値を使用できるすべての式で使用することができる。

ブラックボードに格納される変数は、グローバル変数またはプライベート変数のいずれかである。プライベート変数は、特定の支払い命令ルールセット（例えば、送り手、受取人、または呼出し側）によってのみ使用することができるが、グローバル変数は、すべての支払い命令ルールセットによって式内で使用することができる。

この例では、変数は、変化しない単一の値を代入される。異なる変数は、その値に関する異なる供給源を有する。例えば、変数の中には、支払い命令ルールセット内で値を代入されるものと、トランザクション承認システム（「ＴＡＳ」）によって指定されるものと、支払い要求メッセージ内で呼出し側によって渡されるものがある。

下のチャートに、すべての支払い要求メッセージについて定義される変数を、各変数の値の供給源と共に示す。さらに、支払い命令ルールセットは、代入ステートメントを使用して、それ自体の変数を作成することができる。これらの変数は、グローバルであり、例えば、送り手の支払い命令ルールセット内の代入ステートメントによって作成された変数を、受取人の指示内の式で使用することができる。ユーザ指定の変数の名前は、ＴＡＳ定義の変数名および他のユーザ定義変数との衝突を避けるために、そのユーザに固有の文字の識別シーケンスから始まらなければならない。例えば、ＢｏｂのＳｕｒｆ Ｓｈａｃｋによって定義される変数名は、すべてが、‘ＢｏｂｓＳｕｒｆＳｈａｃｋ’から始まるものとすることができる。

少数の例外はあるが、すべてのグローバル変数は、呼出し側によって支払い要求メッセージで渡すことができ、あるいは、支払い命令ルールセットのいずれかで指定することができ、したがって、下のチャートに示された現在の供給源は、規約に過ぎない。これに対する例外には、ＴＡＳによって指定される値を有する変数と、少なくとも１つのトークンが、入ってくる承認メッセージに渡される必要があり、使用されるすべての他のトークンが、到達可能である必要があるという事実とが含まれる。例えば、ＣａｌｌｅｒＴｏｋｅｎが、支払い要求メッセージで供給される唯一のトークンである場合に、対応する支払い命令ルールセットは、ＳｅｎｄｅｒＴｏｋｅｎまたはＲｅｃｉｐｉｅｎｔＴｏｋｅｎあるいはその両方を示すことができる。対応する支払い命令ルールセットがＳｅｎｄｅｒＴｏｋｅｎだけを示す場合には、送り手の支払い命令ルールセットがＲｅｃｉｐｉｅｎｔＴｏｋｅｎを示すことができ、逆も同様である。

プライベート変数
下のチャートにリストされたプライベート変数は、各支払い命令ルールセットがこれらの変数のそれぞれのそれ自体のコピーを取得するように、支払い命令ルールセットごとに供給される。例えば、これらの参照のデータは、受取人と送り手について異なる。受取人は、送り手の値にアクセスすることができず、逆も同様である。

コメント
コメントは、番号記号（＃）から始まり、その行の残りを無視させる。複数行コメントについては、各行の始めに＃を置く。

言語特性
いくつかの実施形態において、この言語に、ループ構造および／または再帰などの時間的態様が含まれる場合があるが、この例には、そのような時間的態様または分岐ステートメントは含まれない。データ型には、ｂｏｏｌｅａｎ、ｎｕｍｂｅｒ、ｓｔｒｉｎｇ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ、およびｍｏｎｅｙが含まれる。演算子は、次の通りである。

リテラル
ＢＯＯＬＥＡＮ

ＮＵＭＢＥＲ

２３１−１までのすべての整数が許容される。負の値は、「ネゲート」演算を介して達成される。小数は、やはりサポートされ、浮動小数点数としては格納されない。数は、数字から始まり、したがって、先頭の０は、０と１の間の小数に使用される。パーセンテージとして数を表すこともサポートされる。

ＳＴＲＩＮＧ

ストリングリテラルは、一重引用符に囲まれる。二重引用符は、現在は使用されない。

ＤＡＴＥＴＩＭＥ

‘ｎｏｗ’リテラルは、現在時刻を返す。このパターンに続く引用符で囲まれたテキストを、比較することができる。ｄａｔｅｔｉｍｅキーワードは、ストリング式ではなく、引用符で囲まれたテキストを扱う。

ＤＵＲＡＴＩＯＮ

ｄｕｒａｔｉｏｎリテラルは、時間の期間を指定し、新しい日付を形成するために日付に追加することができる。様々な数学演算が利用可能である。

上の２つのリテラルスタイルの両方がサポートされる。第２のリテラルスタイルは、１年２カ月３日１０時間３０分に変換される。ｄｕｒａｔｉｏｎリテラルの第２の形は、非特許文献１の持続時間の定義に従う。

持続時間の語彙表現は、非特許文献２の拡張フォーマットＰｎＹｎＭｎＤＴｎＨｎＭｎＳであり、ここで、ｎＹは、年数を表し、ｎＭは、月数を表し、ｎＤは、日数を表し、‘Ｔ’は、日付／時刻セパレータであり、ｎＨは、時数を表し、ｎＭは、分数を表し、ｎＳは、秒数を表す。

ＭＯＮＥＹ

ｍｏｎｅｙリテラルは、通貨コードおよびｎｕｍｂｅｒリテラル、または通貨コードおよび数を表す式によって指定することができる。すべての通貨コードをリストしたテーブルを含む、通貨コードに関するさらなる情報については非特許文献３を参照されたい。許容できる通貨コードのセットは、ＩＳＯ ４２１７によって指定されるものに限定されないが、ＩＳＯ ４２１７の通貨コードは認識される。

演算子および組込み関数
次のセクションでは、ｌｈｓは、左側オペランドを表し、ｒｈｓは、右側オペランドを表す。

ＮＥＧＡＴＥＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｄｕｒａｔｉｏｎ、ｍｏｎｅｙ
ＮＯＴＯＰＥＲＡＴＩＯＮ

許容される型：ｂｏｏｌｅａｎ
ＯＲＯＰＥＲＡＴＩＯＮ

許容される型：ｂｏｏｌｅａｎ
ＡＮＤＯＰＥＲＡＴＩＯＮ

許容される型：ｂｏｏｌｅａｎ
ＩＮＯＰＥＲＡＴＩＯＮ

許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。ｉｎ演算子は、次の省略形であり、正確に次と同等である。

ＮＯＴＩＮＯＰＥＲＡＴＩＯＮ

許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。ｎｏｔＩｎ演算子は、次の省略形であり、正確に次と同等である。

ＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ

許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＮＯＴＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ

許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＬＥＳＳＴＨＡＮＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＧＲＥＡＴＥＲＴＨＡＮＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＬＥＳＳＴＨＡＮＯＲＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＧＲＥＡＴＥＲＴＨＡＮＯＲＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＡＤＤＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。

ｍｏｎｅｙに対する操作は、ｌｈｓとｒｈｓの両方がｍｏｎｅｙ型であることを必要とする。

ｄｕｒａｔｉｏｎをｄｕｒａｔｉｏｎに加算することができ、ｄｕｒａｔｉｏｎがもたらされる。

ｄａｔｅｔｉｍｅをｄｕｒａｔｉｏｎに加算することができ、あるいは、ｄｕｒａｔｉｏｎをｄａｔｅｔｉｍｅに加算することができ、ｄａｔｅｔｉｍｅがもたらされる。

ＳＵＢＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。

ｍｏｎｅｙに対する操作は、ｌｈｓとｒｈｓの両方がｍｏｎｅｙ型であることを必要とする。

ｄｕｒａｔｉｏｎをｄｕｒａｔｉｏｎから減算することができ、ｄｕｒａｔｉｏｎがもたらされる。

ｄｕｒａｔｉｏｎをｄａｔｅｔｉｍｅから減算することができ、ｄａｔｅｔｉｍｅはｌｈｓでなければならず、ｄｕｒａｔｉｏｎはｒｈｓでなければならず、ｄａｔｅｔｉｍｅがもたらされる。

ＭＵＬＴＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄｕｒａｔｉｏｎ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。

ｍｏｎｅｙについて、ｍｏｎｅｙは、ｉｎｔｅｇｅｒまたはｄｏｕｂｌｅによって乗算することができ、ｍｏｎｅｙがもたらされる。

ｄｕｒａｔｉｏｎについて、ｄｕｒａｔｉｏｎは、ｉｎｔｅｇｅｒによって乗算することができ、ｄｕｒａｔｉｏｎがもたらされる。

ＤＩＶＯＰＥＲＡＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。

ｍｏｎｅｙについて、ｍｏｎｅｙは、ｉｎｔｅｇｅｒまたはｄｏｕｂｌｅによって除算することができ、ｌｈｓはｍｏｎｅｙ値でなければならず、ｒｈｓはｉｎｔｅｇｅｒまたはｄｏｕｂｌｅでなければならず、ｍｏｎｅｙがもたらされる。

ＭＩＮＦＵＮＣＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＭＡＸＦＵＮＣＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。

ＭＯＤＦＵＮＣＴＩＯＮ

許容される型：ｉｎｔｅｇｅｒ
ｌｈｓとｒｈｓの除算の整数剰余をもたらす。

ＣＡＴＦＵＮＣＴＩＯＮ

許容される型：ｓｔｒｉｎｇ
ｌｈｓとｒｈｓを組み合わせたストリングをもたらす。

ＧＥＴＣＵＲＲＥＮＣＹＣＯＤＥ

許容される型：ｍｏｎｅｙ
ストリングとして通貨コードを返す。

解析文法

語彙定義

前述から、例示のために本明細書で特定の実施形態を説明したが、本発明の趣旨および範囲から逸脱せずに、様々な変更を行えることが理解されるであろう。したがって、本発明は、添付の特許請求の範囲およびそこに列挙された要素によるものを除いて限定されない。さらに、本発明のある種の態様を、添付の特許請求の範囲である種の請求項の形で提示するが、本発明人は、すべての利用可能な請求項の形において本発明の様々な態様を企図している。例えば、本発明の一部の態様だけが、コンピュータ可読媒体で実施されるものとして現在は列挙されている可能性があるが、他の態様も、同様にそのように実施することができる。

プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。 プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。 プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。 プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。 プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。 ウェブサービス支払い処理システムの例示的実施形態のコンポーネントおよび情報フローを示すネットワーク図である。 支払い処理システムの実施形態を実行するのに適したコンピューティングシステムの実施形態を示すブロック図である。 ユーザアカウント管理ルーチンの実施形態のフロー図である。 トランザクション承認およびハンドラルーチンの実施形態のフロー図である。 トランザクション妥当性検査サブルーチンの実施形態のフロー図である。 支払い処理トランザクションサブルーチン実行の実施形態のフロー図である。 支払い処理トランザクションサブルーチン実行の実施形態のフロー図である。 トランザクションへの関係者間の対話のタイプの例を示す。 トランザクションへの関係者間の対話のタイプの例を示す。 トランザクションへの関係者間の対話のタイプの例を示す。

Claims (81)

1. 少なくとも第１および第２の関係者の間のプログラム的トランザクションの表示を受け取ることであって、前記プログラム的トランザクションは、前記第２の関係者が要求されたサービスを前記第１の関係者に提供することと、前記第１の関係者から前記第２の関係者への前記サービスについての関連する金銭の支払いとを含み、前記第１および第２の関係者は、第三者トランザクション承認者と別個であることと、
   前記プログラム的トランザクションについての前記関連する金銭の支払いを承認するかどうかを判定するのに使用される、前記第１の関係者の第１の参照トークンの表示および前記第２の関係者の第２の参照トークンの表示を受け取ることと、
   前記第１トークンに関連する前記第１の関係者についての第１事前定義の支払い命令ルールセットおよび前記第２トークンに関連する前記第２の関係者についての第２事前定義の支払い命令ルールセットを取り出すことと、
   前記第１の関係者から前記第２の関係者への前記関連する金銭の支払いを承認するために、前記取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかを判定することと、
   前記第１および第２の支払い命令ルールセットに互換性があると判定されるときに、前記第２の関係者が前記第１の関係者に前記サービスを提供するようにするために、前記第１の関係者の代わりに前記第２の関係者に前記関連する金銭の支払いを提供することと
   を備えたことを特徴とする前記第三者トランザクション承認者が関係者間のプログラム的トランザクションを自動的に承認するコンピュータ実装方法。
2. 前記トランザクションは、前記第１の関係者によって別個のエンドユーザに提供され、前記エンドユーザによって実行されているアプリケーションプログラムによる、前記第２の関係者の少なくとも１つのウェブサービスの呼出しを含み、前記少なくとも１つのウェブサービスは、料金と引き換えに前記第２の関係者によって提供されることを特徴とする請求項１に記載の方法。
3. 前記関連する金銭の支払いを承認するための前記取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかの前記判定は、さらに、前記第１および第２の支払い命令ルールセットが前記エンドユーザの第３参照トークンに基づいて取り出される前記エンドユーザについての第３支払い命令ルールセットと互換性があるかどうかを判定することを含むことを特徴とする請求項２に記載の方法。
4. 前記トランザクションは、別の関係者によって前記第１の関係者に提供され、前記第１の関係者によって実行されているアプリケーションプログラムによる、前記第２の関係者の少なくとも１つのウェブサービスの呼出しを含み、前記少なくとも１つのウェブサービスは、料金と引き換えに前記第２の関係者によって提供されることを特徴とする請求項１に記載の方法。
5. 前記トランザクションの前記表示の前記受取の前に、前記第１の関係者から受け取られる１以上の指示に応答して前記第１支払い命令ルールセットを定義することと、前記第２の関係者から受け取られる１以上の指示に応答して前記第２支払い命令ルールセットを定義することとを含むことを特徴とする請求項１に記載の方法。
6. 前記第１支払い命令ルールセットの前記定義は、前記第１トークンを生成することと、前記第１トークンを前記第１支払い命令ルールセットに関連付けることとを含み、前記第２支払い命令ルールセットの前記定義は、前記第２トークンを生成することと、前記第２トークンを前記第２支払い命令ルールセットに関連付けることとを含むことを特徴とする請求項５に記載の方法。
7. 前記トークンは、前記第２の関係者が前記第１トークンから前記第１支払い命令ルールセットに関する情報を取得できないように、および前記第１の関係者が前記第２トークンから前記第２支払い命令ルールセットに関する情報を取得できないように、匿名となるように生成されることを特徴とする請求項６に記載の方法。
8. 前記トークンは、前記第２の関係者が前記第１トークンから前記第１の関係者に関する情報を取得できないように、および前記第１の関係者が前記第２トークンから前記第２の関係者に関する情報を取得できないように、匿名となるように生成されることを特徴とする請求項６に記載の方法。
9. 前記第１および第２の支払い命令ルールセットのそれぞれについて、前記支払い命令ルールセットの前記受け取られる指示は、使用条件の複数の事前定義のタイプ表示と、前記使用条件を満たすことに影響する前記使用条件のそれぞれに関する１以上の対応するユーザ指定の値の表示とを備えたことを特徴とし、前記第１および第２の支払い命令ルールセットそれぞれの前記定義は、前記示された事前定義の使用条件タイプおよび対応するユーザ指定の値のそれぞれについて、前記支払い命令ルールセットのルールを作成することを含むことを特徴とする請求項５に記載の方法。
10. 前記第１および第２の指示ルールセットのそれぞれについて、前記支払い命令ルールセットの前記受け取られた指示は、前記ルールが満たされるかどうかを判定するユーザ指定のプロシージャをそれぞれが有する１以上のルールの表示を含むことを特徴とし、前記第１および第２の支払い命令ルールセットのそれぞれの前記定義は、前記表示されたルールのそれぞれを作成することを含むことを特徴とする請求項５に記載の方法。
11. 前記第１および第２の指示ルールセットのそれぞれについて、前記支払い命令ルールセットについての前記指示は、前記トランザクション承認者によって提供される１以上のウェブサービスの呼出しに基づいて受け取られることを特徴とする請求項５に記載の方法。
12. 前記トランザクションの前記表示および前記第１および第２の参照トークンの前記表示の前記受取りは、前記トランザクション承認者によって提供される１以上のウェブサービスの呼出しに基づくことを特徴とする請求項１に記載の方法。
13. 取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかの前記判定は、さらに、前記第１および第２の支払い命令ルールセットが前記トランザクションを承認するかどうかを判定することになることを特徴とする請求項１に記載の方法。
14. 前記取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかの前記判定は、さらに、前記第１および第２の支払い命令ルールセットが前記第１および第２の関係者との間のトランザクションを承認するかどうかを判定することになることを特徴とする請求項１に記載の方法。
15. 前記取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかの前記判定は、さらに、前記第１および第２の支払い命令ルールセットが現在の条件の下で有効であるかどうかを判定することになることを特徴とする請求項１に記載の方法。
16. 前記取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかの前記判定は、さらに、前記第１および／または第２の支払い命令ルールセットで指定された情報に従って、前記第１および／または第２の関係者から対話的に情報を取得することを含むことを特徴とする請求項１に記載の方法。
17. 前記第１および第２の支払い命令ルールセットは、それぞれ、前記支払い命令ルールセットがトランザクションを承認するかどうかを判定するための判断基準をそれぞれが指定する複数のルールを含むことを特徴とする請求項１に記載の方法。
18. 前記関連する金銭の支払いを承認するための検索された前記第１および第２の支払い命令ルールセットに互換性があることの前記判定は、前記第１および第２の支払い命令ルールセットのそれぞれの前記ルールのそれぞれが、前記トランザクションについて満たされることを判定することを含むことを特徴とする請求項１７に記載の方法。
19. 前記第１および第２の支払い命令ルールセットのうちの一方のルールが満たされることの前記判定は、前記ルールが、他方の支払い命令ルールセットと、他方の支払い命令ルールセットを提供した関係者と、前記トランザクションに関する情報のうちの１以上によって満たされることを判定することを含むことを特徴とする請求項１８に記載の方法。
20. 前記支払い命令ルールセットのそれぞれは、さらに、前記支払い命令ルールセットが承認できるトランザクションのタイプを規定する１以上のルールと、前記支払い命令ルールセットが承認できる次のトランザクション変更条件を規定する１以上のルールと、前記支払い命令ルールセットが承認できる、受け取られるまたは提供される支払いのタイプを規定する１以上のルールと、前記支払い命令ルールセットがトランザクションを行うことを承認できる関係者のタイプを規定する１以上のルールとを含むことを特徴とする請求項１７に記載の方法。
21. 前記第１および第２の関係者は、それぞれ、さらに、潜在的なトランザクションの一部として別の関係者に情報へのアクセスを提供および／または受け取るかどうかを規定する複数のルールをそれぞれが含む１以上の使用法命令ルールセットを有することを特徴とする請求項１に記載の方法。
22. 前記第１および第２の関係者は、それぞれ、その支払い命令ルールセットが関連付けられる前記トランザクション承認者のアカウントを有することを特徴とし、前記第１の関係者の代わりに第２の関係者に前記関連する金銭の支払いを提供することは、前記金銭の支払いの支払い手段として前記第１の関係者の前記アカウントを使用することと、前記金銭の支払いの支払いリポジトリとして前記第２の関係者の前記アカウントを使用することとを含むことを特徴とする請求項１に記載の方法。
23. 前記第１の関係者の代わりの前記第２の関係者への前記関連する金銭の支払いの前記提供は、前記関連する金銭の支払いの少なくとも一部の前記第１の関係者への払戻しを提供するために、指定された時間期間の間に前記関連する金銭の支払いの少なくとも一部への前記第２の関係者のアクセスを制限することを含むことを特徴とする請求項１に記載の方法。
24. 前記第２の関係者への前記関連する金銭の支払いの前記提供が、前記関連する金銭の支払いへの即座のアクセスを前記第２の関係者に与え、前記保証機能の提供者が、前記関連する金銭の支払いの少なくとも一部の前記第１の関係者へのすべての払戻しが利用可能であることを保証するような、前記関連する金銭の支払いに関連する保証機能性を提供することを含むことを特徴とする請求項１に記載の方法。
25. 前記表示されたトランザクションは、さらに、第３の関係者、ならびにそれぞれが前記第１と第２と第３の関係者によってであり、それぞれが前記第１と第２と第３の関係者および前記トランザクション承認者のうちの別個の１以上への、１以上の追加の関連する金銭の支払いを含み、１以上の対応する支払い命令ルールセットがその追加支払いを承認するとき、前記追加の関連する金銭の支払いのそれぞれを提供することを含むことを特徴とする請求項１に記載の方法。
26. 前記第３の関係者は、前記トランザクションの一部として前記第２の関係者のプログラム的サービスを呼び出すアプリケーションプログラムを実行するエンドユーザであることを特徴とし、前記追加の関連する金銭の支払いのうちの少なくとも１つは、前記第３関係者から前記第３関係者および／または前記トランザクション承認者にであることを特徴とする請求項２５に記載の方法。
27. 前記第１および第２の支払い命令ルールセットは互換性があると判定され、前記トランザクションについての論争解決ポリシを指定し、前記第１の関係者の代わりの前記第２の関係者への前記関連する金銭の支払いの前記提供の後に、前記第１および第２の関係者のうちの少なくとも１つからの表示に応答して前記指定された論争解決ポリシを実施することを備えたことを特徴とする請求項１に記載の方法。
28. 前記第１の関係者の代わりの前記第２の関係者への前記関連する金銭の支払いの前記提供は、前記第１の関係者から前記金銭の支払いを取得することを含むことを特徴とする請求項１に記載の方法。
29. 前記第１および第２の支払い命令ルールセットは、ＸＭＬ文書であることを特徴とする請求項１に記載の方法。
30. 前記第２の関係者による前記第１の関係者への前記サービスの前記提供は、前記トランザクションの前記表示の前記受取の前に完了することを特徴とする請求項１に記載の方法。
31. コンピュータ可読媒体であって、
    １以上のサービスの提供を含む別個の第１と第２の関係者の間のトランザクションの表示を受け取ることと、
    前記トランザクションを承認するかどうかを判定するのに使用される、前記第１の関係者の第１の参照の表示および前記第２の関係者の第２の参照の表示を受け取ることと、
    参照に関連する第１事前定義の使用法命令ルールセットが、前記トランザクションを承認する方式で、前記第２の参照に関連する第２事前定義の使用法命令ルールセットと互換性があるかどうかを判定することと、
    前記第１および第２の使用法命令ルールセットに互換性があると判定されるときに、前記トランザクションが承認されることの表示を提供することと
    を備えた方法を実行することによって、コンピュータ可読媒体の内容が、関係者間のトランザクションをトランザクション承認コンピューティングシステムに自動的に承認させるコンピュータ可読媒体。
32. 前記トランザクションが承認されることの前記表示の前記提供は、前記第１の関係者の代わりに前記第２の関係者に前記トランザクションに関連する金銭の支払いを提供することを含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
33. 前記トランザクションが承認されることの前記表示の前記提供は、前記第１の関係者から前記トランザクションに関連する金銭の支払いを取得することを備えたことを特徴とする請求項３１に記載のコンピュータ可読媒体。
34. 前記トランザクションは、前記第１および第２の関係者のうちの一方による、前記第１および第２の関係者のうちの他方によって提供されるウェブサービスの呼出しを含むプログラム的トランザクションであることを特徴とする請求項３１に記載のコンピュータ可読媒体。
35. 前記トランザクションは、前記第１および第２の関係者のうちの一方が、前記第１および第２の関係者のうちの他方に、情報へのアクセスを提供することを含むプログラム的トランザクションであることを特徴とする請求項３１に記載のコンピュータ可読媒体。
36. 前記トランザクションは、前記第１および第２の関係者のうちの少なくとも一方が、前記関係者のうちの他方に、１以上の物理的サービスを提供する、前記第１と前記第２の関係者の間の物理的トランザクションであることを特徴とする請求項３１に記載のコンピュータ可読媒体。
37. 前記１以上のサービスの前記提供は、前記トランザクションの前記表示の前記受取の前に完了することを特徴とする請求項３１に記載のコンピュータ可読媒体。
38. 前記１以上のサービスの前記提供は、前記トランザクションが承認されることの前記表示の前記提供に少なくとも一部に基づいて実行されることを特徴とする請求項３１に記載のコンピュータ可読媒体。
39. 前記トランザクション承認コンピューティングシステムは、前記第１および第２の使用法命令ルールセットを格納することを特徴とし、前記第１および第２の使用法命令ルールセットに互換性があるかどうかの前記判定は、前記格納された第１および第２の使用法命令ルールセットを取り出し、比較することを含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
40. 前記第１および第２の使用法指示ルールセットが互換であるかどうかの前記判定は、前記第１および第２の使用法指示ルールセットのそれぞれの複数のルールのそれぞれが前記トランザクションについて満たれるかどうかを判定するために前記ルールを評価することを含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
41. 前記第１および第２の参照は、前記トランザクション承認コンピューティングシステムによって生成される参照トークンであることを特徴とする請求項３１に記載のコンピュータ可読媒体。
42. 前記トランザクションは、さらに、少なくとも１つの追加関係者を含むことを特徴とし、前記第１および第２の使用法命令ルールセットに互換性があるかどうかの前記判定は、さらに、前記第１および第２の使用法命令ルールセットが前記少なくとも１つの追加関係者のそれぞれについての追加使用法命令ルールセットと互換性があるかどうかの判定を含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
43. 前記コンピュータ可読媒体は、コンピューティングシステムのメモリであることを特徴とする請求項３１に記載のコンピュータ可読媒体。
44. 前記コンピュータ可読媒体は、前記内容を含む生成されたデータ信号を伝送するデータ伝送媒体であることを特徴とする請求項３１に記載のコンピュータ可読媒体。
45. 前記内容は、実行されたときに前記コンピューティングシステムに前記方法を実行させる命令であることを特徴とする請求項３１に記載のコンピュータ可読媒体。
46. 前記内容は、関係者間のトランザクションを自動的に承認するのに使用される１以上のデータ構造を含み、前記データ構造は、複数のエントリを含み、各エントリは、関係者に関連する前記使用法命令ルールセットであり、一意の関連する参照トークンの表示と使用法命令ルールセットの複数のルールの表示とを含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
47. コンピューティングデバイスであって、
    第１と第２の関係者との間のプログラム的トランザクション、ならびに前記プログラム的トランザクションを承認するかどうかを判定するのに使用される前記第１の関係者の第１の参照トークンおよび前記第２の関係者の第２の参照トークンの１以上の表示を受け取った後に、前記プログラム的トランザクションを承認するために前記第１および第２の参照トークンに関連する第１および第２の支払い命令ルールセットが満たされるかどうかを判定するように構成されたトランザクション検証コンポーネントと、
    前記第１および第２の支払い命令ルールセットが満たされると判定された後に、前記プログラム的トランザクションについての関連する金銭の支払いを、前記第１の関係者の代わりに前記第２の関係者に提供するように構成されたトランザクショ処理コンポーネントと
    を備えたことを特徴とする、関係者間のプログラム的トランザクションを自動的に承認するように構成されるコンピューティングデバイス。
48. 前記トランザクション要求者コンポーネントおよび前記トランザクショ処理コンポーネントは、前記コンピューティングデバイスのメモリ内で実行されていることを特徴とする請求項４７に記載のコンピューティングデバイス。
49. 前記トランザクション検証コンポーネントは、前記プログラム的トランザクションを承認するために、前記第１および前記第２の支払い命令ルールセットが満たされるかどうかを判定する手段からなることを特徴とし、前記トランザクショ処理コンポーネントは、前記第１の関係者の代わりに前記第２の関係者に、前記プログラム的トランザクションに関する前記関連する金銭の支払いを提供する手段からなることを特徴とする請求項４７に記載のコンピューティングデバイス。
50. プログラム的サービスの提供者および消費者によって事前に定義された指示に従って前記提供者と前記消費者の間のプログラム的トランザクションを自動的に承認および支払いの管理をするコンピュータに実装される方法であって、前記方法は、第三者トランザクション承認者のコンピューティングシステムの制御の下で実行され、
    １以上のプログラム的サービスの複数の提供者のそれぞれについて、それぞれが、前記提供者が料金と引き換えに少なくとも１つのプログラム的サービスを提供することを有する、トランザクションについての消費者からの支払いを受け入れるかどうかを規定する複数のルールをそれぞれが含む、前記提供者からの１以上の支払い命令ルールセットの表示を受け取ることと、
    プログラム的サービスの複数の消費者のそれぞれについて、それぞれが、前記消費者が料金と引き換えに少なくとも１つのプログラム的サービスを受け取ることを有する、トランザクションについて提供者への支払いを提供するかどうかを規定する複数のルールをそれぞれが含む、前記消費者からの１以上の支払い命令ルールセットの表示を受け取ることと、
    前記提供者および消費者の前記示された支払い命令ルールセットのそれぞれについて、前記支払い命令ルールセットに関連する参照トークンを生成し、前記支払い命令ルールセットおよび前記関連する参照トークンを格納し、前記表示された支払い命令ルールセットがそれから受け取られた前記提供者または消費者に前記生成された参照トークンを提供することであって、前記生成された参照トークンは、潜在的なトランザクションの一部として、前記支払い命令ルールセットを参照するのに後に使用するためのものであることと、
    料金と引き換えに消費者への少なくとも１つのプログラム的サービスの提供者による提供を含む、前記提供者と前記消費者との間の潜在的なトランザクションをそれぞれが承認する、複数の要求のそれぞれに応答して、各承認要求は、前記提供者についての参照トークンおよび前記消費者についての参照トークンを含み、さらに、トランザクション支払い額を含む前記潜在的なトランザクションに関する情報を含み、
    前記承認要求に含まれる前記参照トークンに関連する前記格納された支払い命令ルールセットを取り出すことと、
    前記提供者についての前記支払い命令ルールセット内のルールが、前記消費者についての前記支払い命令ルールセット内で指定された方式で、前記消費者からのトランザクション支払額の受け入れを可能にするように、および前記消費者についての前記支払い命令ルールセット内のルールが、前記提供者についての前記支払い命令ルールセット内で指定された方式で、前記提供者へのトランザクション支払額の支払いを可能にするように、前記取り出された支払い命令ルールセットに互換性があるかどうかを判定することと、
    前記取り出された支払い命令ルールセットに互換性があると判定されるときに、プログラム的サービスの潜在的トランザクションが提供者および消費者によって事前に定義された指示に従って自動的に承認および支払われるときに、これらのプログラム的サービスがその提供者によってその消費者に提供されるようにするために、前記潜在的なトランザクションを承認し、前記提供者についての前記支払い命令ルールセット内で指定された方式で、前記提供者に前記トランザクション支払額を提供し、前記消費者についての前記支払い命令ルールセット内で指定された方式で前記消費者から支払いを取得することと
    によって、前記潜在的なトランザクションを承認するかどうかを判定することと
    を備えたことを特徴とするコンピュータ実装方法。
51. 前記消費者は、消費者アプリケーション開発者の１以上の参照トークンを含むアプリケーションプログラムを別個のエンドユーザにそれぞれが提供す、前記アプリケーション開発者であることを特徴とし、前記潜在的なトランザクションの前記承認要求は、それぞれ、エンドユーザによって実行されるアプリケーションプログラムからであり、前記アプリケーションプログラムを提供した前記消費者アプリケーション開発者についての前記含まれる参照トークンのうちの１つを使用していることを特徴とする請求項５０に記載の方法。
52. アプリケーションプログラムからの前記潜在的なトランザクションのそれぞれは、前記アプリケーションプログラムが、ウェブサービス提供者によって料金と引き換えに提供されるウェブサービスを呼び出すことを備えたことを特徴とする請求項５１に記載の方法。
53. 前記承認要求のそれぞれは、さらに、前記要求を行う前記アプリケーションプログラムを実行する前記エンドユーザについての別個の参照トークンを含み、前記別個の参照トークンは、少なくとも１つのサービスを受け取ることをそれぞれが含むトランザクションについての支払いを提供するかどうかを規定するルールを含む前記エンドユーザの支払い命令ルールセットに関連することを特徴とし、前記取り出された支払い命令ルールセットが承認要求に関して互換性があるかどうかの前記判定は、さらに、前記承認要求に含まれる前記別個の参照トークンに関連する前記エンドユーザの前記支払い命令ルールセットのこれらの支払い命令ルールセットの互換性に基づくことを特徴とする請求項５１に記載の方法。
54. 前記潜在的なトランザクションに関する前記承認要求は、エンドユーザによって実行されるアプリケーションプログラムによって、それぞれ開始されることを特徴とし、提供者と消費者との間の前記潜在的なトランザクションのそれぞれについての、前記潜在的なトランザクションに関する前記取り出された支払い命令ルールセットに互換性があることの前記判定は、
    前記提供者の前記参照トークンに関連する前記取り出された支払い命令ルールセット内のそれぞれのルールごとに、前記ルールが、前記消費者、前記消費者についての前記参照トークンに関連する前記取り出された支払い命令ルールセット、前記潜在的なトランザクションに関する前記含まれる情報、および前記潜在的なトランザクションを開始した前記アプリケーションプログラムを実行する前記エンドユーザのうちの１以上によって満たされることを判定することと、
    前記消費者についての前記参照トークンに関連する前記取り出された支払い命令ルールセット内のそれぞれのルールごとに、前記ルールが、前記提供者、前記提供者についての前記参照トークンに関連する前記取り出された支払い命令ルールセット、前記潜在的なトランザクションに関する前記含まれる情報、および前記潜在的なトランザクションを開始した前記アプリケーションプログラムを実行する前記エンドユーザのうちの１以上によって満たされることを判定することと
    を含むことを特徴とする請求項５０に記載の方法。
55. 前記支払い命令ルールセットのそれぞれは、さらに、前記支払い命令ルールセットが承認できるトランザクションのタイプを規定する１以上のルールと、前記支払い命令ルールセットが承認できる次のトランザクション変更条件を規定する１以上のルールと、前記支払い命令ルールセットが承認できる、受け取られか提供されることになる支払いのタイプを規定する１以上のルールと、前記支払い命令ルールセットがそれとのトランザクションを行うことを承認できる関係者のタイプを規定する１以上のルールとを備えたことを特徴とする請求項５４に記載の方法。
56. その支払い命令ルールセットが関連する前記提供者および消費者のそれぞれに前記トランザクション承認者のアカウントを提供することをさらに含み、消費者の前記アカウントは、提供者への支払い用の支払い手段として使用することができ、提供者の前記アカウントは、消費者からの支払い用の支払いリポジトリとして使用することができることを特徴とし、前記潜在的なトランザクションの少なくとも一部に関する支払いの前記提供および取得は、これらのトランザクションにかかわる前記提供者および消費者の前記口座の使用を伴うことを特徴とする請求項５０に記載の方法。
57. 提供者と消費者との間の前記潜在的なトランザクションの少なくとも一部のそれぞれについて、前記潜在的なトランザクションの前記取り出された支払い命令ルールセットに互換性があると判定されるときに、前記提供者および消費者のうちの少なくとも１つの代わりに前記潜在的なトランザクションを実行することを備えたことを特徴とする請求項５０に記載の方法。
58. 前記トランザクション承認者は、さらに、後の使用のために生成された参照トークンを提供者および消費者に提供することと、潜在的なトランザクションについての前記取り出された支払い命令ルールセットに互換性があるかどうかを判定することと、潜在的なトランザクションについての支払いを前記提供および取得することとのうちの１以上のそれぞれについて料金を請求することを特徴とする請求項５０に記載の方法。
59. ユーザを伴う動作を自動的に承認するコンピュータに実装する方法であって
    第１のユーザおよび別個の記第２の実体を伴う動作の表示を受け取ることと、
    前記示された動作を承認するかどうかを自動的に判定するのに使用される前記第１のユーザについての第１の参照の表示および前記第２の実体についての第２の参照の表示を受け取ることと、
    前記第１の参照に関連する第１の事前定義の使用法命令ルールセットが、前記表示された動作を承認する方式で、前記第２の参照に関連する第２の事前定義の使用法命令ルールセットと互換性があるかどうかを判定することと、
    前記第１および第２の使用法命令ルールセットに互換性があると判定されるとき、前記表示された動作が承認されることの表示を提供することと
    を備えたことを特徴とする方法。
60. 前記表示された動作は、前記第１のユーザと前記第２の実体との間の提案されるトランザクションであることを特徴とする請求項５９に記載の方法。
61. 前記表示された動作は、前記第１のユーザが前記第２の実体から利用可能な制限された情報へのアクセスを取得することを備えたことを特徴とする請求項５９に記載の方法。
62. 前記表示された動作は、前記第１のユーザが前記第２の実体から利用可能な制限されたサービスへのアクセスを取得することを備えたことを特徴とする請求項５９に記載の方法。
63. 前記表示された動作は、前記第１のユーザが前記第２の実体との、１以上の表示された契約条件に合意することを含むことを特徴とする請求項５９に記載の方法。
64. 前記１以上の示された契約条件は、前記第１のユーザと前記第２の実体との間の１以上のトランザクションと共に使用される論争解決ポリシを含むことを特徴とする請求項６３に記載の方法。
65. 前記１以上の表示された契約条件は、前記第１のユーザと前記第２の実体との間の支払いについての払戻しの提供に関する少なくとも１つの条件を含むことを特徴とする請求項６３に記載の方法。
66. 前記第２の実体は、前記第１のユーザと別個の第２のユーザであることを特徴とする請求項５９から６５の任意に記載の方法。
67. 関係者間のトランザクションを自動的に承認するコンピュータに実装される方法であって、
    １以上のサービスの提供を含む、別個の第１および第２の関係者との間のトランザクションの表示を受け取ることと、
    前記トランザクションを承認するかどうかを判定するのに使用される前記第１の関係者の第１の参照の表示および前記第２の関係者の第２の参照の表示を受け取ることであって、前記第１の参照は、前記第１の関係者の事前定義の承認指示に関連し、前記第１の関係者に関連するプライベート情報を保護する方式で生成されることと、
    前記第１の関係者の前記事前定義の承認指示が、前記第２の参照に関連する前記第２の関係者の別個の事前定義の承認指示に関して、前記トランザクションを承認する方式で互換性があるかどうかを判定することと、
    前記第１の関係者の前記事前定義の承認指示および前記第２の関係者の前記事前定義の承認指示に互換性があると判定されるときに、前記トランザクションが承認されることの表示を提供することと
    を備えたことを特徴とする方法。
68. 前記第１の関係者についての前記事前定義の承認指示は、複数のルールを伴う指示ルールセットを含むことを特徴とする請求項６７に記載の方法。
69. 前記第１の関係者に関連する前記プライベート情報の前記保護は、前記第２の関係者が前記プライベート情報を取得するのを防ぐことを含むことを特徴とする請求項６７から６８の任意に記載の方法。
70. 前記第１の参照は、前記第１の関係者に関連する前記保護されるプライベート情報が、前記第１の関係者のアイデンティティの表示を含む方式で生成されることを特徴とする請求項６７から６９の任意に記載の方法。
71. 前記第１の参照は、前記第１の関係者に関連する前記保護されるプライベート情報が前記第１の関係者の前記事前定義の承認指示を含む方式で生成されることを特徴とする請求項６７から６９の任意に記載の方法。
72. 関係者間のトランザクションを自動的に承認するコンピュータに実装される方法であって、
    １以上のサービスの提供を含む、別個の第１と第２の関係者との間のトランザクションの表示を受け取ることと、
    前記トランザクションを承認するかどうかを判定するのに使用される、前記第１の関係者の第１の参照の表示および前記第２の関係者の第２の参照の表示を受け取ることと、
    前記第１の参照に関連する第１事前定義の使用法命令ルールセットが、前記トランザクションを承認する方式で、前記第２の参照に関連する第２事前定義の使用法命令ルールセットと互換性があると判定されるかどうかを判定することと、
    前記第１および第２の使用法命令ルールセットに互換性があると判定されるときに、前記トランザクションが承認されることの表示を提供し、前記トランザクションの実行に関連する1以上の機能性のタイプの表示を提供することと
    を備えたことを特徴とする方法。
73. 前記第１および第２の使用法命令ルールセットに互換性があると判定されるときに、前記トランザクションの実行を支援することをさらに備えたことを特徴とする請求項７２に記載の方法。
74. 前記第１および第２の使用法命令ルールセットに互換性があると判定されるときに、前記第１および第２の関係者のうちの少なくとも１つに前記トランザクションに対応する支払いを提供することをさらに備えたことを特徴とする請求項７２から７３の任意に記載の方法。
75. 前記第１および第２の使用法命令ルールセットに互換性があると判定されるときに、前記第１および第２の関係者のうちの少なくとも１つから、前記トランザクションに対応する支払いを取得することをさらに備えたことを特徴とする請求項７２から７４の任意に記載の方法。
76. 前記トランザクションの実行に関連する前記１以上の機能性のタイプは、前記トランザクションについて提供される支払いを保証する保険引受けサービスを含むことを特徴とする請求項７２から７５の任意に記載の方法。
77. 前記保険引受けサービスの使用は、前記支払いの意図した受取人が実質的に即時の方式で、前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項７６に記載の方法。
78. 前記保険引受けサービスは、前記支払いの前記意図した受取人が、前記支払いが前記支払いの意図した支払人から取得される前に、前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項７７に記載の方法。
79. 前記保険引受けサービスは、前記支払いの前記意図した受取人が、前記支払いが前記支払いの支払人によって争われる可能性がある期間の間に、前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項７７から７８の任意に記載の方法。
80. 前記トランザクションの実行に関連する前記１以上の機能性のタイプは、前記支払いが提供されることを保証するために、前記トランザクションについて提供される支払いを保証する保険サービスを含むことを特徴とする請求項７２から７９の任意に記載の方法。
81. 前記保険サービスの使用は、前記支払いの意図した受取人が続いて即時の方式で、前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項８０に記載の方法。

Images