(57)【要約】  第三者トランザクション承認システムを介して自動的に承認される、関係者間のトランザクションを実行することによるなどの、コンピューティングシステム間の対話を容易にするための技術を説明する。いくつかの状況において、トランザクションは、アプリケーションプログラムを実行することによる料金ベースのウェブサービスの使用を伴うプログラム的トランザクションであり、トランザクション承認システムは、関係者によって以前に指定されたプライベート承認指示に従って支払いを承認しおよび／または提供する。この承認指示には、潜在的なトランザクションをその下で承認できる条件を規定する既定の命令ルールセットを含むことができ、命令ルールセットのそれぞれは、関連する参照トークンによって参照される。潜在的なトランザクションへの関係者の１以上が、関係者についての参照トークンを供給した後に、トランザクション承認システムは、それらの参照トークンに関連する命令ルールセットに互換性があるまたは他の形で満たされるかどうかに基づいて、そのトランザクションを承認するかどうかを決定することができる。
2008507064.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサービス提供者および他の関係者の既定の命令に基づいて自動的に承認されるプログラム的トランザクションを実行する、前記ウェブサービス提供者用の方法であって、前記方法は、前記ウェブサービス提供者のコンピューティングシステムの制御の下で実行され、
前記ウェブサービス提供者の少なくとも１つのウェブサービス機能の呼び出し、およびそのウェブサービス機能についての第１の関係者から前記ウェブサービス提供者への関連する金銭的支払いを含む、前記第１の関係者と前記ウェブサービス提供者との間のプログラム的トランザクションのために、前記第１の関係者からの要求を受け取ることと、
前記プログラム的トランザクションについて前記関連する金銭的支払いを承認するかどうかを決定するのに使用される、前記第１の関係者の第１の参照トークンを取得することであって、前記第１の参照トークンは、前記ウェブサービス提供者からアクセス可能でない前記第１の関係者の第１の既定の支払い命令ルールセットに関連付けられることと、
前記第１の関係者から前記ウェブサービス提供者への前記関連する金銭的支払いを承認するかどうかを自動的に決定するために第三者トランザクション承認者に指示を送ることであって、前記送られる指示は、前記第１の関係者の前記取得された第１の参照トークンおよび前記第１の関係者からアクセス可能でない前記ウェブサービス提供者の第２の既定の支払い命令ルールセットに関連付けられた前記ウェブサービス提供者の第２の参照トークンを含み、前記トランザクション承認者は、前記第１および第２の支払い命令ルールセットにアクセスでき、前記トランザクション承認者による前記自動の承認決定は、前記第１および第２の支払い命令ルールセットに互換性があることを決定されるかどうかに少なくとも一部に基づくことと、
前記関連する金銭的支払いが承認されると決定されるときに、前記少なくとも１つのウェブサービス機能を前記第１の関係者に提供することと
を備えたことを特徴とする方法。
【請求項２】
前記関連する金銭的支払いが承認されると決定されるときに、前記第１の関係者の代わりに前記トランザクション承認者から前記関連する金銭的支払いを受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記関連する金銭的支払いが承認されると決定された後に、前記第１の関係者から前記関連する金銭的支払いを受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記要求されたプログラム的トランザクションは、前記第１の関係者、前記ウェブサービス提供者、および前記トランザクションに関連する第三者のうちの１つによるそれぞれであり、前記第１の関係者、前記ウェブサービス提供者、前記第三者、および前記トランザクション承認者のうちの別個の１以上へのそれぞれである、１以上の追加の関連する金銭的支払いをさらに含み、前記追加の関連する金銭的支払いは、１以上の対応する支払い命令ルールセットがその追加支払いを承認するときにそれぞれなされるようになっていることを特徴とする請求項１に記載の方法。
【請求項５】
前記受け取られた要求は、アプリケーションプログラムを実行している別個のエンドユーザに前記第１の関係者によって提供される前記アプリケーションプログラムからであることを特徴とする請求項１に記載の方法。
【請求項６】
前記送られる指示は、前記エンドユーザの第３の既定の支払い命令ルールセットに関連する前記エンドユーザの取得された第３の参照トークンをさらに含み、
前記関連する金銭的支払いを承認するための前記取り出された第１および第２の支払い命令ルールセットに互換性があるかどうかの前記決定は、前記第１および第２の支払い命令ルールセットが前記第３の支払い命令ルールセットと互換性があるかどうかを決定することをさらに含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記受け取られた要求は、アプリケーションプログラムを実行している前記第１の関係者に別の関係者によって提供される前記アプリケーションプログラムからであることを特徴とする請求項１に記載の方法。
【請求項８】
前記要求の前記受け取りの前に、前記第２の支払い命令ルールセットを定義するために前記トランザクション承認者と対話することと、応答して前記トランザクション承認者から前記第２の参照トークンを受け取ることとを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ウェブサービス提供者による前記要求の前記受け取りの前に、前記第１の関係者のコンピューティングシステムの制御の下で、前記第１の支払い命令ルールセットを定義するために前記トランザクション承認者と対話することと、応答して前記トランザクション承認者から前記第１の参照トークンを受け取ることとを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記トークンは、前記ウェブサービス提供者が前記第１のトークンから前記第１の支払い命令ルールセットについての情報を取得できないように、ならびに前記第１の関係者が前記第２のトークンから前記第２の支払い命令ルールセットについての情報を取得できないように、匿名であることを特徴とする請求項１に記載の方法。
【請求項１１】
前記第１のトークンは、前記ウェブサービス提供者が前記第１のトークンから前記第１の関係者についての情報を取得できないように匿名であることを特徴とする請求項１に記載の方法。
【請求項１２】
前記第三者トランザクション承認者への前記指示の前記送ることは、前記トランザクション承認者によって提供される１以上のウェブサービスの呼出しに基づくことを特徴とする請求項１に記載の方法。
【請求項１３】
前記送られる指示は、前記第１および第２の支払い命令ルールセットに少なくとも一部に基づいて前記プログラム的トランザクションを承認するかどうかをさらに決定することを特徴とする請求項１に記載の方法。
【請求項１４】
前記送られる指示は、前記第１および第２の支払い命令ルールセットのそれぞれが現在の条件の下で有効であるかどうかをさらに決定することを特徴とする請求項１に記載の方法。
【請求項１５】
前記関連する金銭的支払いを承認するかどうかの前記決定は、前記第１および／または第２の支払い命令ルールセット内で指定された情報に従って、前記第１の関係者および／または前記ウェブサービス提供者によって前記トランザクション承認者に情報を対話的に提供することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１６】
前記第１および第２の支払い命令ルールセットのそれぞれは、前記支払い命令ルールセットがプログラム的トランザクションを承認するかどうかを決定する判断基準をそれぞれが指定する複数のルールを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記関連する金銭的支払いを承認するための前記第１および第２の支払い命令ルールセットに互換性があることを前記決定することは、前記第１および第２の支払い命令ルールセットのそれぞれの前記ルールのそれぞれが前記プログラム的トランザクションについて満たされることを決定することを含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記支払い命令ルールセットのそれぞれは、前記支払い命令ルールセットが承認できるトランザクションのタイプを規定する１以上のルールと、前記支払い命令ルールセットが承認できるポストトランザクションの変更状況を規定する１以上のルールと、前記支払い命令ルールセットが承認できる、受け取られるまたは提供される支払いのタイプを規定する１以上のルールと、前記支払い命令ルールセットがトランザクションを行うことを承認できる関係者のタイプを規定する１以上のルールとをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１９】
前記第１の関係者および前記ウェブサービス提供者のそれぞれは、潜在的なプログラム的トランザクションの一部としての情報へのアクセスを別の関係者に提供し、および／または受け取るかどうかを規定する複数のルールをそれぞれが含む１以上の使用法命令ルールセットをさらに有することを特徴とする請求項１に記載の方法。
【請求項２０】
前記第１の関係者および前記ウェブサービス提供者のそれぞれは、その支払い命令ルールセットが関連付けられる前記トランザクション承認者のアカウントを有することを特徴とし、前記金銭的支払いの支払い手段として前記第１の関係者の前記アカウントを使用すること、ならびに前記金銭的支払いの支払いリポジトリとして前記ウェブサービス提供者の前記アカウントを使用することとによって、前記第１の関係者の代わりに前記ウェブサービス提供者に前記関連する金銭的支払いを提供することを含むことを特徴とする請求項１に記載の方法。
【請求項２１】
前記第１および第２の支払い命令ルールセットは、前記プログラム的トランザクションと互換性があることを決定されることを特徴とし、前記ウェブサービス提供者のウェブサービス機能の呼出しおよび第２の関係者から前記ウェブサービス提供者への第２の関連する金銭的支払いを含む、前記第２の関係者と前記ウェブサービス提供者との間の第２のプログラム的トランザクションについての別個の第２の関係者からの要求を受け取った後に、前記第２の支払い命令ルールセットが前記第２の関係者の別個の第３のトークンに関連する第３の支払い命令ルールセットと互換性があることを決定されることに基づいて、前記第２のプログラム的トランザクションについての前記第２の金銭的支払いが承認されると決定された後に、そのウェブサービス機能を前記第２の関係者に提供することを含むことを特徴とする請求項１に記載の方法。
【請求項２２】
前記第１および第２の支払い命令ルールセットは、前記プログラム的トランザクションについて互換性があることを決定されることを特徴とし、前記第１の関係者と前記ウェブサービス提供者との間の第２のプログラム的トランザクションについての第２の要求を前記第１の関係者から受け取った後に、かつ前記第１および第２の参照トークンを含む第２の指示を前記トランザクション承認者に送った後に、前記第１および第２の支払い命令ルールセットが前記第２のプログラム的トランザクションについて互換性がないことを決定されることに基づいて、前記第２のプログラム的トランザクションを承認しないことの決定の指示を前記トランザクション承認者から受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項２３】
前記第１および第２の支払い命令ルールセットは、前記プログラム的トランザクションに関して互換性がないことを決定されることを特徴とし、前記プログラム的トランザクションについて前記関連する金銭的支払いを承認するかどうかを決定する際に使用される前記第１の関係者または前記ウェブサービス提供者の第３の参照トークンの指示を受け取った後に、前記第３のトークンに関連する第３の支払い命令ルールセットが前記第１および／または第２の支払い命令ルールセットと互換性があることを決定されることに基づいて、前記プログラム的トランザクションについての前記関連する金銭的支払いを承認することを決定することを含むことを特徴とする請求項１に記載の方法。
【請求項２４】
前記第１および第２の支払い命令ルールセットは、ＸＭＬ文書であることを特徴とする請求項１に記載の方法。
【請求項２５】
前記第１の参照トークンの前記取得することは、前記受け取られた要求と共に前記第１の参照トークンを受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項２６】
トランザクションの一部としての１以上のサービスを提供するための前記第１の関係者から前記第２の関係者への関連する金銭的支払いを含む、別個の第１の関係者と第２の関係者との間の潜在的な前記トランザクションの指示を受け取ることと、
前記トランザクションを承認するかどうかを決定する際に使用される、前記第１の関係者のための第１の参照および前記第２の関係者のための第２の参照の表示を受け取ることと、
前記第１の参照に関連する第１の使用法命令ルールセットが、前記トランザクションを承認する方式で、前記第２の参照に関連する第２の使用法命令ルールセットと互換性があることが自動的に決定されるかどうかの、前記第１および第２の関係者と別個のトランザクション承認システムからの指示を取得することと、
前記第１および第２の使用法命令ルールセットに互換性があると決定されるときに、前記トランザクションの少なくとも一部を実行することと
を備えた方法を実行することによって、コンピュータ可読媒体の内容がコンピュータシステムに関係者間の自動的に承認されるトランザクションを行わせることを特徴とするコンピュータ可読媒体。
【請求項２７】
前記トランザクションは、プログラム的トランザクションであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項２８】
前記プログラム的トランザクションは、前記第１および第２の関係者のうちの一方によって提供されるウェブサービスの前記第１および第２の関係者のうちの他方によって呼出されることを含むことを特徴とする請求項２７に記載のコンピュータ可読媒体。
【請求項２９】
前記プログラム的トランザクションは、前記第１および第２の関係者のうちの一方が前記第１および第２の関係者のうちの他方に情報へのアクセスを提供することを含むことを特徴とする請求項２７に記載のコンピュータ可読媒体。
【請求項３０】
前記方法は、前記第１の関係者によって実行されることを特徴とし、前記プログラム的トランザクションの前記少なくとも一部の前記実行することは、前記第１の関係者から前記第２の関係者への前記関連する金銭的支払いの提供することと、前記１以上のサービスの提供の一部としての前記第２の関係者からの情報および／または機能の受け取ることとを含むことを特徴とする請求項２７から２９の任意に記載のコンピュータ可読媒体。
【請求項３１】
前記方法は、前記第２の関係者によって実行されることを特徴とし、前記プログラム的トランザクションの前記少なくとも一部の前記実行は、前記第１の関係者からの前記関連する金銭的支払いの受け取ることと、前記１以上のサービスの実行の一部としての前記第１の関係者および／または第三者への情報および／または機能を提供することとを含むことを特徴とする請求項２７から２９の任意に記載のコンピュータ可読媒体。
【請求項３２】
前記方法は、第三者によって実行されることを特徴とし、前記プログラム的トランザクションの前記少なくとも一部の前記実行することは、前記１以上のサービスウの提供の一部としての前記第２の関係者からの情報および／または機能の受け取ることを含むことを特徴とする請求項２７から２９の任意に記載のコンピュータ可読媒体。
【請求項３３】
前記トランザクションは、プログラム的トランザクションであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項３４】
前記トランザクションは、前記第１および第２の関係者のうちの少なくとも一方が前記関係者の他方に１以上の物理的サービスを提供する、前記第１と第２の関係者の間の物理的トランザクションであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項３５】
前記１以上のサービスの前記提供することは、前記第１および第２の使用法命令ルールセットに互換性があることを前記決定することの前に完了することを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３６】
前記１以上のサービスの前記提供することは、前記第１および第２の使用法命令ルールセットに互換性があることの前記決定することの少なくとも一部に基づいて実行されることを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３７】
前記第１および第２の使用法命令ルールセットに互換性があることを決定することは、前記第１および第２の使用法命令ルールセットのそれぞれの複数のルールのそれぞれを、前記トランザクションについて前記ルールが満たされることを決定するために評価することを含むことを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項３８】
前記トランザクションは、少なくとも１つの追加関係者をさらに含むことを特徴とし、前記第１および第２の使用法命令ルールセットに互換性があるかどうかの前記決定は、さらに、前記第１および第２の使用法命令ルールセットが前記少なくとも１つの追加関係者のそれぞれについての追加使用法命令ルールセットと互換性があるかどうか決定することを含むことを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項３９】
前記第１および第２の参照のうちの少なくとも１つは、前記トランザクションで使用するために動的に生成される、それに関連する使用法命令ルールセットが前記トランザクションについて指定される指示の少なくとも一部に基づく、参照トークンであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項４０】
各動的に生成される参照トークンは、前記トランザクションでのみ使用が利用可能な使い捨てトークンであることを特徴とする請求項３９に記載のコンピュータ可読媒体。
【請求項４１】
前記コンピュータ可読媒体は、コンピューティングシステムのメモリであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項４２】
前記コンピュータ可読媒体は、前記内容を含む生成されたデータ信号を伝送するデータ伝送媒体であることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項４３】
前記内容は、実行されたときに前記コンピューティングシステムに前記方法を実行させる命令であることを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項４４】
前記内容は、関係者間のトランザクションを自動的に承認するのに使用される１以上のデータ構造を含み、前記データ構造は複数のエントリを含み、各エントリは関係者に関連する前記使用法命令ルールセットであり、一意の関連する参照トークンの指示と使用法命令ルールセットについての複数のルールの指示とを含むことを特徴とする請求項２６に記載のコンピュータ可読媒体。
【請求項４５】
関係者間の自動的に承認されるプログラム的トランザクションを実行するように構成されたコンピューティングデバイスであって、
第１の関係者と第２の関係者との間のプログラム的トランザクションと、前記プログラム的トランザクションを承認するかどうかを決定するのに使用される前記第１の関係者の第１の参照トークンおよび前記第２の関係者の第２の参照トークンとの１以上の指示受け取った後に、前記プログラム的トランザクションを承認するために前記第１および第２の参照トークンに関連する第１および第２の支払い命令ルールセットが満たされるかどうかに関する決定を取得するように構成されたトランザクション要求コンポーネントであって、前記プログラム的トランザクションは、前記第２の関係者から１以上のウェブサービスの機能を前記第１の関係者に提供することを含むトランザクション要求コンポーネントと、
前記第１および第２の支払い命令ルールセットが満たされることが決定された後に、前記プログラム的トランザクションの少なくとも一部を実行するように構成されたトランザクション実行コンポーネントと
を備えたことを特徴とするコンピューティングデバイス。
【請求項４６】
前記トランザクション要求コンポーネントおよび前記トランザクション実行コンポーネントは、前記コンピューティングデバイスのメモリ内で実行されていることを特徴とする請求項４５に記載のコンピューティングデバイス。
【請求項４７】
前記トランザクション要求コンポーネントは、前記プログラム的トランザクションを承認するために前記第１および第２の支払い命令ルールセットが満たされるかどうかに関する決定を取得する手段からなり、前記トランザクション実行コンポーネントは、前記プログラム的トランザクションの少なくとも前記一部を実行する手段からなることを特徴とする請求項４５に記載のコンピューティングデバイス。
【請求項４８】
関係者によって第三者トランザクション承認システムに提供される既定の命令に従って自動的に承認される、ウェブサービス提供者と消費者の間のプログラム的ウェブサービストランザクションを実行するコンピュータに実装される方法であって、前記方法は、前記ウェブサービス提供者および前記消費者のコンピューティングシステム制御の下で、
複数のウェブサービス提供者のそれぞれについて、前記ウェブサービス提供者について１以上の支払い命令ルールセットを定義するため、および応答して前記支払い命令ルールセットのそれぞれについて関連する参照トークンを受け取るために、前記第三者トランザクション承認システムと対話することであって、各支払い命令ルールセットは、それぞれが料金について少なくとも１つのウェブサービスを提供するウェブサービス提供者を有するトランザクションについて、ウェブサービス消費者からの支払いを受け入れるかどうかを規定する複数のルールを含み、前記参照トークンのそれぞれは、潜在的なトランザクションの一部として前記関連する支払い命令ルールセットを参照するのに後に使用するために、前記トランザクション承認システムによって生成されることと、
複数のウェブサービス提供者のそれぞれについて、前記ウェブサービス消費者について１以上の支払い命令ルールセットを定義するため、および応答して前記支払い命令ルールセットのそれぞれについて関連する参照トークンを受け取るため、前記第三者トランザクション承認システムと対話することであって、各支払い命令ルールセットは、それぞれが料金として提供される少なくとも１つのウェブサービスを受け取る前記ウェブサービス消費者を有するトランザクションについて、ウェブサービス提供者への支払いを提供するかどうかを規定する複数のルールを含み、前記参照トークンのそれぞれは、潜在的なトランザクションの一部として前記関連する支払い命令ルールセットを参照するのに後に使用するために、前記トランザクション承認システムによって生成されることと、
複数の前記ウェブサービス提供者のそれぞれについて、前記ウェブサービス提供者のうちの１つによって関連する料金に対してそれぞれが提供される１以上のウェブサービスを特定することと、そのウェブサービスを提供する前記ウェブサービス提供者から前記特定されたウェブサービスのそれぞれをプログラム的に呼び出すこととであって、前記ウェブサービスのそれぞれの前記プログラム的呼び出しのそれぞれは、前記ウェブサービス消費者の前記参照トークンのうちの１つを提供することを含むことと、
複数の前記ウェブサービス提供者のそれぞれについて、前記ウェブサービス提供者によって提供されるウェブサービスについてそれぞれであり、呼出しを行うウェブサービス消費者についての参照トークンをそれぞれが含む１以上の前記呼出しを受け取ることと、
前記ウェブサービス提供者が前記呼び出されたウェブサービスに関連する前記料金として前記呼出しを行う前記ウェブサービス消費者に前記呼び出されたウェブサービスを提供することを含む潜在的なトランザクションを承認する要求を前記トランザクション承認システムに送ることであって、前記送られる要求は、前記受け取られた呼出しと共に含まれる前記ウェブサービス消費者の前記参照トークンと、前記ウェブサービス提供者についての前記参照トークンの１つを含むことと、
前記トランザクション承認システムが、前記送られる要求に含まれる前記参照トークンに関連する前記支払い命令ルールセットに互換性があることに基づいて、前記潜在的なトランザクションが承認されることを決定するときに、
ウェブサービス提供者および消費者が関連する参照トークンによって示される既定の命令に従ってウェブサービスについての支払いを含むトランザクションを行うことができるようにするために、前記呼び出されるウェブサービスについての前記関連する料金を前記トランザクション承認システムを介して前記ウェブサービス提供者から受け取り、前記呼び出されるウェブサービスを前記ウェブサービス消費者に提供することと
によって、ウェブサービスを呼び出すトランザクションについての支払いを可能にするために、前記生成された参照トークンおよび関連する支払い命令ルールセットを使用することと
を備えたことを特徴とする方法。
【請求項４９】
前記トランザクション承認システムの制御の下で、提供されるウェブサービスに関連する料金を含むウェブサービス提供者とウェブサービス消費者の間の潜在的なトランザクション承認についてのそれぞれである複数の受け取られる要求への応答であって、各承認要求は、前記ウェブサービス提供者のための参照トークン、および前記ウェブサービス消費者のための参照トークンを含み、
前記承認要求に含まれる前記参照トークンに関連する支払い命令ルールセットを取り出すことと、
前記ウェブサービス提供者についての前記支払い命令ルールセット内のルールが、前記ウェブサービス消費者についての前記支払い命令ルールセット内で指定される方式で、前記ウェブサービス提供者からの前記関連する料金の受け入れを可能にするように、および前記ウェブサービス消費者についての前記支払い命令ルールセット内のルールが、前記ウェブサービス提供者についての前記支払い命令ルールセット内で指定される方式で、前記ウェブサービス提供者への前記関連する料金の支払いを可能にするように、前記取り出された支払い命令ルールセットに互換性があるかどうかを決定することと、
前記取り出された支払い命令ルールセットに互換性があると決定されるときに、前記潜在的なトランザクションを承認し、前記ウェブサービス消費者についての前記支払い命令ルールセット内で指定された前記方式で、前記関連する料金を前記ウェブサービス提供者に提供し、前記ウェブサービス提供者についての前記支払い命令ルールセット内で指定された前記方式で前記ウェブサービス提供者から支払いを取得することと
によって前記潜在的なトランザクションを承認するかどうかを決定することとを含むこと特徴とする請求項４８に記載の方法。
【請求項５０】
前記ウェブサービス消費者は、ウェブサービス消費者アプリケーション開発者についての参照トークンのうちの１以上を含むアプリケーションプログラムを別個のエンドユーザにそれぞれが提供するアプリケーション開発者であって、前記ウェブサービスの前記プログラム的呼出しはそれぞれ、エンドユーザによって実行されるアプリケーションプログラムからのそれぞれであり、前記アプリケーションプログラムによって提供される前記ウェブサービス消費者アプリケーション開発者についての前記含まれる参照トークンのうちの１つを使用していることを特徴とする請求項４８に記載の方法。
【請求項５１】
エンドユーザによって実行されるアプリケーションプログラムからのウェブサービスの前記プログラム的呼出しのそれぞれは、少なくとも１つのウェブサービスを受け取とることをそれぞれが含むトランザクションについての支払いを提供するかどうかを規定するルールを含む前記エンドユーザの支払い命令ルールセットに関連する前記エンドユーザについての別個の参照トークンを供給することをさらに含むことを特徴とし、ウェブサービス提供者によって前記トランザクション承認システムに送られる前記要求のそれぞれは、潜在的なトランザクションが承認される前記トランザクション承認システムによる前記決定することが、ウェブサービス提供者、ウェブサービス消費者、およびエンドユーザについての前記参照トークンに関連する前記支払い命令ルールセットの互換性にさらに基づくように、ウェブサービス提供者についての受け取られた呼出しと共に含まれるエンドユーザについての参照トークンをさらに含むことを特徴とする請求項５０に記載の方法。
【請求項５２】
潜在的トランザクションについて前記支払い命令ルールセットに互換性があることを前記決定することは、
前記ウェブサービス提供者についての前記参照トークンに関連する前記支払い命令ルールセット内のそれぞれのルールについて、前記ルールが、前記ウェブサービス消費者、前記ウェブサービス消費者の前記参照トークンに関連する前記支払い命令ルールセット、前記潜在的なトランザクションに関する情報、および前記潜在的なトランザクションに関連するアプリケーションプログラムを実行するエンドユーザのうちの１以上によって満たされることを決定することと、
前記ウェブサービス消費者の前記参照トークンに関連する前記支払い命令ルールセット内のそれぞれのルールについて、前記ルールが、前記ウェブサービス提供者、前記ウェブサービス提供者の前記参照トークンに関連する前記支払い命令ルールセット、前記潜在的なトランザクションに関する情報、および前記潜在的なトランザクションに関連するアプリケーションプログラムを実行するエンドユーザのうちの１以上によって満たされることを決定することと
を含むことを特徴とする請求項４８に記載の方法。
【請求項５３】
前記支払い命令ルールセットのそれぞれは、前記支払い命令ルールセットが承認できるトランザクションのタイプを規定する１以上のルールと、前記支払い命令ルールセットが承認できるポストトランザクション変更状況を規定する１以上のルールと、前記支払い命令ルールセットが承認できる、受け取られるまたは提供される支払いのタイプを規定する１以上のルールと、前記支払い命令ルールセットがトランザクションを行うことを承認できる関係者のタイプを規定する１以上のルールとをさらに含むことを特徴とする請求項５２に記載の方法。
【請求項５４】
ウェブサービス提供者とウェブサービス消費者の間の各潜在的なトランザクションが、前記潜在的なトランザクションを承認するかどうかを決定するのに使用されるそれらの支払い命令ルールセットのうちの１つの前記ウェブサービス提供者および消費者のそれぞれによる選択を含むように、前記ウェブサービス提供者および消費者のそれぞれは、別個のルールおよび別個の関連する参照トークンを有する複数の支払い命令ルールセットを有することを特徴とする請求項４８に記載の方法。
【請求項５５】
前記ウェブサービス提供者および前記ウェブサービス消費者のそれぞれは、その支払い命令ルールセットが関連付けられる前記トランザクション承認システムのアカウントを有することを特徴とし、前記ウェブサービス消費者の前記アカウントは、ウェブサービス提供者への支払いの支払い手段として使用できることを特徴とし、前記ウェブサービス提供者の前記アカウントは、ウェブサービス消費者からの支払いの支払いリポジトリとして使用でき、前記潜在的なトランザクションのうちの少なくともいくつかについてのウェブサービス消費者からウェブサービス提供者への関連する料金の前記提供は、これらのトランザクションにかかわる前記ウェブサービス提供者および消費者の前記アカウントの使用を伴うようになっていることを特徴とする請求項４８に記載の方法。
【請求項５６】
前記トランザクション承認システムは、生成された参照トークンを後の使用のためにウェブサービス提供者および消費者に提供することと、潜在的なトランザクションについての前記支払い命令ルールセットに互換性があるかどうかを決定することと、潜在的なトランザクションについてウェブサービス消費者からウェブサービス提供者に関連する料金を提供することとのうちの１以上のそれぞれに料金をさらに請求することを特徴とする請求項４８に記載の方法。
【請求項５７】
前記参照トークンは、潜在的なトランザクションへの関係者が、前記潜在的なトランザクションへの別の関係者の前記参照トークンに関連する前記支払い命令ルールセットに関する情報を取得することができず、前記参照トークンからの前記別の関係者に関する情報を取得することができないように、匿名であることを特徴とする請求項４８に記載の方法。
【請求項５８】
潜在的なトランザクションの一部としてのウェブサービス消費者への呼び出されたウェブサービスのウェブサービス提供者による前記提供することは、前記ウェブサービス提供者による前記ウェブサービスの実行に関連する情報を含む応答メッセージを前記ウェブサービス提供者に提供することと、前記トランザクション承認システムがその後に潜在的なトランザクションが承認されないと決定するときに、前記ウェブサービス提供者から前記ウェブサービス消費者に前記ウェブサービスに関連するエラーメッセージを提供することとを含むことを特徴とする請求項４８に記載の方法。
【請求項５９】
ユーザを伴う自動的に承認される動作を実行するためのコンピュータに実装される方法であって、
第１のユーザおよび別個の第２の実体を伴う潜在的動作の指示を受け取ることと、
前記示された動作を承認するかどうかを自動的に決定するのに使用される、前記第１のユーザの第１の参照の指示および前記第２の実体の第２の参照の指示を受け取ることと、
前記第１の参照に関連する第１の使用法命令ルールセットが、前記指示された動作を承認するような方式で前記第２の参照に関連する第２の使用法命令ルールセットと互換性があることを自動的に決定されるかどうかの指示を前記第１のユーザおよび前記第２の実体と別個のトランザクション承認システムから取得することと、
前記第１および第２の使用法命令ルールセットに互換性があることを決定されるときに、前記指示された動作の実行を容易にすることと
を備えたことを特徴とする方法。
【請求項６０】
前記指示された動作は、前記第１のユーザと前記第２の実体との間の提案されるトランザクションであって、前記トランザクションの一部として１以上のサービスを提供することに関する前記第１の関係者から前記第２の関係者への関連する金銭的支払いを含むことを特徴とし、前記指示された動作の前記実行の前記容易化は、前記トランザクションの少なくとも一部を実行することを含むことを特徴とする請求項５９に記載の方法。
【請求項６１】
前記指示された動作は、前記第１のユーザが前記第２の実体から利用可能な制限された情報へのアクセスを取得することを含むことを特徴とする請求項５９に記載の方法。
【請求項６２】
前記指示された動作は、前記第１のユーザが前記第２の実体から利用可能な制限されたサービスへのアクセスを取得することを含むことを特徴とする請求項５９に記載の方法。
【請求項６３】
前記指示された動作は、前記第１のユーザが前記第２の実体に関する１以上の指示された契約条項に合意することを含むことを特徴とする請求項５９に記載の方法。
【請求項６４】
前記１以上の指示された契約条項は、前記第１のユーザと前記第２の実体との間の１以上のトランザクションと共に使用される論争解決ポリシを含むことを特徴とする請求項６３に記載の方法。
【請求項６５】
前記１以上の示された契約条件は、前記第１のユーザと前記第２の実体との間の支払いに関する払戻しの提供に関する少なくとも１つの条件を含むことを特徴とする請求項６３に記載の方法。
【請求項６６】
前記第２の実体は、前記第１のユーザと別個の第２のユーザであることを特徴とする請求項５９から６５のいずれかに記載の方法。
【請求項６７】
関係者間の自動的に承認されるトランザクションを実行するためにコンピュータに実装する方法であって、
１以上のサービスの提供を含む、別個の第１および第２の関係者との間のトランザクションの指示を受け取ることと、
前記トランザクションを承認するかどうかを決定するのに使用される前記第１の関係者の第１の参照の表示および前記第２の関係者の第２の参照の表示を受け取ることであって、前記第１の参照は、前記第１の関係者に関連するプライベート情報を保護する方式で生成されることと、
前記第１の参照に関連する前記第１の関係者についての第１の既定の承認命令が、前記トランザクションを承認する方式で前記第２の関係者の第２の既定の承認指示と互換性があるように自動的に決定されるかどうかの指示を取得することと、
前記第１および第２の使用法命令ルールセットに互換性があると決定されるときに、前記第１の関係者に関連する前記プライベート情報を保護する方式で前記トランザクションの少なくとも一部を実行することと
を備えたことを特徴とする方法。
【請求項６８】
前記第１の関係者についての前記既定の承認指示は、複数のルールを伴う命令ルールセットを含むことを特徴とする請求項６７に記載の方法。
【請求項６９】
前記第１の関係者に関連する前記プライベート情報の前記保護することは、前記第２の関係者が前記プライベート情報を取得するのを防ぐことを含むことを特徴とする請求項６７から６８のいずれかに記載の方法。
【請求項７０】
前記第１の参照は、前記第１の関係者に関連する前記保護されるプライベート情報が前記第１の関係者のアイデンティティの指示を含むような方式で生成されることを特徴とする請求項６７から６９のいずれかに記載の方法。
【請求項７１】
前記第１の参照は、前記第１の関係者に関連する前記保護されたプライベート情報が前記第１の関係者の前記既定の承認命令を含むような形式で生成されることを特徴とする請求項６７から６９の任意に記載の方法。
【請求項７２】
関係者の間で自動的に承認されるトランザクションを実行するためのコンピュータに実装される方法であって、
１以上のサービスの提供を含む、別個の第１および第２の関係者との間のトランザクションの指示を受け取ることと、
前記トランザクションを承認するかどうかを決定するのに使用される、前記第１の関係者の第１の参照の指示および前記第２の関係者の第２の参照の指示を受け取ることと、
前記第１の参照に関連する第１の使用法命令ルールセットが、前記トランザクションを承認するような方式で、前記第２の参照に関連する第２の使用法命令ルールセットと互換性があるように自動的に決定されるかどうかの指示を取得することと、
前記第１および第２の使用法命令ルールセットに互換性があると決定されるときに、前記トランザクションが承認されることの指示を提供し、前記トランザクションの実行に関連する１以上の機能のタイプの指示を提供することと
を備えたことを特徴とする方法。
【請求項７３】
前記第１および第２の使用法命令ルールセットに互換性があると決定されるときに、前記トランザクションの少なくとも一部を実行することと、前記トランザクションの実行を容易にするために１以上の補足機能のタイプを提供することとをさらに備えたことを特徴とする請求項７２に記載の方法。
【請求項７４】
前記第１および第２の使用法命令ルールセットに互換性があることを決定されるときに、前記第１および第２の関係者のうちの少なくとも１つに前記トランザクションに対応する支払いを提供することをさらに備えたことを特徴とする請求項７２から７３の任意に記載の方法。
【請求項７５】
前記第１および第２の使用法命令ルールセットに互換性があることを決定されるときに、前記第１および第２の関係者のうちの少なくとも１つから前記トランザクションに対応する支払いを取得することをさらに備えたことを特徴とする請求項７２から７４の任意に記載の方法。
【請求項７６】
前記トランザクションの実行に関連する前記１以上の機能のタイプは、前記トランザクションについて提供される支払いを保証する保険引受けサービスを含むことを特徴とする請求項７２から７５のいずれかに記載の方法。
【請求項７７】
前記保険引受けサービスの使用は、前記支払いの意図した受取人が実質的に即時形式で前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項７６に記載の方法。
【請求項７８】
前記保険引受けサービスは、前記支払いの前記意図した受取人が、前記支払いが前記支払いの意図した支払人から取得される前に、前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項７７に記載の方法。
【請求項７９】
前記保険引受けサービスは、前記支払いの前記意図した受取人が、前記支払いが前記支払いの支払人によって争われる可能性がある期間中に、前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項７７から７８の任意に記載の方法。
【請求項８０】
前記トランザクションの実行に関連する前記１以上の機能のタイプは、前記トランザクションについて提供される支払いが提供されることを保証するために前記支払いを保証する保険サービスを含むことを特徴とする請求項７２から７９の任意に記載の方法。
【請求項８１】
前記保険サービスの使用は、前記支払いの意図した受取人が実質的に即時形式で前記支払いへのアクセスを取得することを可能にすることを特徴とする請求項８０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
以下の開示は、概して、コンピューティングシステムの間の対話を容易にすることに関し、さらに詳しくは、関係者の実行中のアプリケーションプログラムの間の料金ベースのウェブサービスプログラム的トランザクションを承認するためなどの、関係者の既定の承認命令に従って自動的に承認される関係者間のトランザクションの実行に関する。
【背景技術】
【０００２】
コンピュータおよび実行中のソフトウェアアプリケーションがプログラム的に対話することを可能にする様々なメカニズムが存在する。例えば、あるコンピュータ上のプログラムが別のコンピュータ上のプログラムを実行させることを可能にするリモートプロシージャコール（「ＲＰＣ」）プロトコルが、長年にわたって存在してきて、ＣＯＲＢＡ（「Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ」）およびＤＣＯＭ（「Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ」）などの様々なオブジェクト指向アーキテクチャが、同様の機能を提供する。さらに、通信を可能にするために別々のアプリケーション（しばしば、別個のタイプであり、関連しないソースからである）を接続するために、様々なミドルウェアプログラムが実装されてきた。例えば、ネットワークの一ユーザのコンピュータシステムが、ネットワークの別のユーザのコンピュータシステムにデータを送信することを可能にする標準メカニズムを提供する、様々なＥＤＩ（「Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ」）ネットワークが存在する。
【０００３】
ワールドワイドウェブ（「ウェブ」）の広い人気は、コンピュータが相互に通信する追加の機会を提供してきた。例えば、多くの現在のウェブの使用に、ユーザがウェブサーバからのウェブページを対話的に要求すること（例えば、ユーザのウェブブラウザアプリケーションの実行を介して）および要求された情報を応答して受信することを伴う。要求された情報のそのような対話的ユーザ指定に加え、ウェブサービスを介するなど、定義されたＡＰＩ（「アプリケーションプログラムインターフェース」）を介して情報を交換するためのリモートアプリケーションのプログラム的対話をサポートするためのウェブの使用の増加もある。
【０００４】
ウェブサービスは、異種のアプリケーションおよびコンピュータが対話することを可能にし、様々な基礎になるプロトコルおよび技術を使用して定義および実装することができる。例えば、一部のウェブサービス実装は、指定された動作および１以上のクエリパラメータを含むＵＲＬ（「Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ」）などのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ」）として指定されたウェブサービス呼出し要求に応答して、ＨＴＴＰ（「ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ」）を使用するＸＭＬ（「ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ」）フォーマットでデータを返す。他の実装において、標準メッセージ交換用のＳＯＡＰ（「Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ」）、サービス呼出しの記述用のＷＳＤＬ（「Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ」）、および利用可能サービスのディスカバリ用のＵＤＤＩ（「Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ  Ｓｅｒｖｉｃｅ」）などの追加の基礎になるプロトコルが、様々な目的に使用される。
【０００５】
ウェブサービスは、様々なアプリケーションおよびコンピュータが対話することを可能にするが、ウェブサービスの現在の実装および使用は、様々な制限を有する。例えば、ウェブサービスの一部の提供者は、進んで彼らのウェブサービスを無料で利用可能にしているが、ほとんどの有用で信頼できるウェブサービスは、しばしば、無料で利用可能ではない。残念ながら、ウェブサービスの提供者およびこれらのウェブサービスの潜在的消費者がトランザクションの支払いおよび他の条項に合意するメカニズムは、時間がかかり、使いにくい。さらに、そのような合意を妨げるセキュリティおよび信頼の問題が、しばしば存在する場合があり、潜在的消費者は、見込みのあるウェブサービス提供者が所望のウェブサービスを信頼性をもって正確に提供することの十分な保証に欠けるかもしれないが、ウェブサービス提供者が、彼らのウェブサービスが承認された消費者だけによって、およびその提供者によって指定された任意の条件に従ってのみ使用される保証を欠くかもしれない。さらに、彼らのウェブサービスに呼び出しを行うアプリケーションプログラムのエンドユーザによるそのようなウェブサービスの使用を制限および制御することができない場合に、アプリケーション開発者は、彼らのアプリケーションプログラムを呼び出す料金ベースウェブサービスをいやがる場合がある。最後に、ウェブサービス提供者が、消費者による彼らのウェブサービスの使用についての指定された支払いを徴収することを可能にする使いやすいメカニズムは、一般に存在しない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、ウェブサービスの使用に関連する上記および他の問題に対処し、および／またはコンピュータシステムおよび実行中のアプリケーションの対話を他の形で容易にする解決法を提供することが有益であるはずである。
【課題を解決するための手段】
【０００７】
いくつかの実施形態において、以前に関係者によって指定されたプライベート承認命令に従って、関係者間のトランザクションおよび／またはそのトランザクションの金銭的支払いを自動的に承認する第三者トランザクション承認システムを提供することによるなど、コンピューティングシステムの間の対話を容易にするソフトウェア機能を説明する。いくつかの実施形態において、トランザクションの一部またはすべてが、ウェブサービス消費者と提携するアプリケーションプログラムによるウェブサービス提供者のウェブサービスの使用を伴うトランザクションなど、実行中のコンピュータプログラムの間で行われるプログラム的トランザクションである。さらに、いくつかの実施形態において、トランザクション承認システムは、さらに、関係者のうちの１以上への承認された支払いを１以上の他の関係者の代わりに提供する。このトランザクション承認システムは、トランザクションへの関係者が、トランザクションが承認されるかどうかを自動的に決定し、そうである場合には、そのトランザクションの実行を進めることを可能にする。
【０００８】
このトランザクション承認システムは、関係者の間の様々なタイプの対話についてのトランザクションおよび／または支払いを承認するのに使用でき、図８Ａ〜８Ｃに、いくつかのそのような対話の例が示されている。具体的には、図８Ａは、関係者８０５ａが関係者８１０ａによって提供されるサービスを要求し、このサービスの提供が関連するコストを有する、２者間のトランザクション８３０ａの例を示す。トランザクション承認システム８２０ａは、トランザクションを承認するかどうかおよび／またはそのトランザクションに関連するコストをカバーするためのサービス要求者からサービス提供者への支払い８５０ａの提供を承認するかどうかを決定するために、関係者８０５ａおよび８１０ａに関する情報（例えば、承認を要求するこのトランザクション承認システムへの、プログラム的呼出しを行う関係者のうちの１者から受け取られた情報）を使用する。トランザクションおよび／または支払いが承認された後に、このトランザクション承認システムは、承認の指示を提供し（例えば、承認要求コールへの応答として）、そしていくつかの実施形態においてさらに、サービス要求者の代わりに承認された支払いを実際に行うことができる。承認プロセス８４０ａをどのように行うことができるかに関しては、以下でより詳細に述べる。
【０００９】
図示の承認および支払い技術は、様々な状況で使用できる。例えば、提供されるサービスに、２者間のプログラム的トランザクション（例えば、サービス提供者関係者によって提供されるウェブサービスのサービス要求者による呼出し）が含まれる場合があり、あるいはその代わりに、他のタイプのトランザクション（例えば、ある関係者から他の関係者への物理的製品または物理的サービスの提供などの、関係者の間の物理的トランザクション）を含めることができる。このトランザクション承認システムを用いる承認対話は、トランザクション中に（例えば、適当な承認応答が受信されない限りトランザクションが完了されなくなるように）、またはその代わりに、トランザクションと別々の方式で（例えば、サービス提供者に支払いを提供するためにトランザクションが完了した後に）など、様々な方法で同様に実行することができる。さらに、承認の実行に使用される関係者に関する情報は、下でより詳細に述べるように、様々な形を同様に有することができる。
【００１０】
図８Ｂは、関係者８０５ｂが関係者８１０ｂによって提供されるサービスを要求するトランザクション８３０ｂについてのより複雑な支払い８５０ｂの例を提供する。この例では、トランザクション承認者８２０ｂが、トランザクションを承認した後に（図示せず）、支払いの一部を、サービス提供者８１０ｂとトランザクション承認者８２０ｂ（例えば、トランザクション承認者がトランザクションおよび／または支払いの承認を実行するために料金を請求することに基づいて）の両方に提供することができ、支払いの一部を、サービス提供者と１以上の他の支払い提供者８１５ｂ（例えば、サービス要求者によって実行されるアプリケーションプログラムを提供したアプリケーション開発者）の両方によって提供することができる。他の状況において、様々な関係者の間の支払いを、支払い提供者が支払いのすべてを提供する場合、ならびに支払い提供者がサービス提供者およびトランザクション承認者のうちの一方に与えられる支払いの一部分を提供し、サービス要求者がサービス提供者およびトランザクション承認者のうちの他方に与えられる部分を提供する場合など、他の方法で提供することができる。
【００１１】
図８Ｃは、複数の参加者８６０ａ〜８６０ｎを有するより複雑なトランザクション８３０ｃの例を提供する。この例では、これらの関係者のうちの一部またはすべて、ならびに１以上の他の支払い提供者８１５ｃが、トランザクション承認者８２０ｃに情報を提供するか、または他の形で対話して、このトランザクション承認者が、このトランザクションおよび／または任意の関連する金銭的支払いが承認されるかどうかを決定できるようにすることができる。承認プロセス８４０ｃが、承認を提供した後に、参加者および／または支払い提供者のうちの１以上によって、他の参加者および／またはトランザクション承認者に、支払い（図示せず）を行うことができる。
【００１２】
前に注記したように、このトランザクション承認システムは、トランザクションを承認するかどうかを決定するときに、トランザクションの関係者に関する様々な情報を使用することができる。具体的には、そのようなトランザクションの潜在的な関係者であるユーザは、まず、料金ベースのトランザクションおよび／またはそのようなトランザクションの関連する金銭的支払いの承認に使用される支払い命令ルールセットなどの、トランザクションの承認に後に使用される、１以上の種類の使用法命令ルールセットをこのトランザクション承認システムを用いて定義することができる。関係者のそのような支払い命令ルールセットのそれぞれは、以下でより詳細に述べるように、支払い命令ルールセットがその関係者の潜在的なトランザクションおよび／またはその関連する金銭的支払いを承認できる条件を規定する１以上の指定されたルールを含むことができる。
【００１３】
例えば、潜在的なウェブサービス消費者（例えば、彼らのアプリケーションプログラムが指定された状況の下でウェブサービスを呼び出すことができることを望むアプリケーション開発者）は、支払い命令ルールセットによって承認できるトランザクションのウェブサービス提供者への金銭的露出を制限する支払い命令ルールセットのルールを指定することができる（例えば、その支払い命令ルールセットがトランザクションを承認できる回数、その支払い命令ルールセットが承認できる１トランザクションあたりの最高支払額、その支払い命令ルールセットが承認できる最高総支払額、その支払い命令ルールセットについて失効日などを介して）。同様に、潜在的なウェブサービス提供者は、支払い命令ルールセットによって承認できるトランザクションについてのウェブサービス提供者への債務を制限する支払い命令ルールセットのルールを指定することができる（例えば、ウェブサービスへのアクセスを購入できる消費者への制限、ウェブサービスへのアクセスを購入するのに使用できる支払いのタイプへの制限、ウェブサービスの使用に不満である消費者が利用可能な救済策への制限など）。さらに、潜在的なウェブサービス呼出し側（例えば、１以上のウェブサービスを呼び出す、アプリケーション開発者によって提供されるアプリケーションプログラムのエンドユーザ）は、支払い命令ルールセットによって承認できるトランザクションについての呼出し側への債務を制限する支払い命令ルールセットのルールを指定することができる（例えば、呼出し側が開始することを承認されるプログラム的トランザクションのタイプへの制限、および／または、サービスの提供者への支払いならびに／あるいはトランザクション承認サービスおよび／または支払いサービスなどの他の第三者サービスに支払われる料金など、プログラム的サービスへのアクセスを購入するために行うことができる支払いのタイプへの制限）。
【００１４】
あるユーザのための指定された使用法命令ルールセットを受け取った後に、このトランザクション承認システムは、オプションでまずその命令ルールセットを承認した後に（例えば、もしあるならば、その命令ルールセットが必要な情報を含むこと、および／または正しい形式であることの検証に基づいて）、そのユーザに関連する形でその命令ルールセットを保管する（例えば、それをトランザクション承認システムに関するユーザのアカウントに関連付ける）。このトランザクション承認システムは、その命令ルールセットを参照する参照トークンを生成し、その参照トークンをその命令ルールセットに関連付け（例えば、その参照トークンの指示を格納された命令ルールセットと共に保管することによって）、後にその命令ルールセットを参照するのに使用するためにその参照トークンをユーザに提供することも行う。他でより詳細に述べるように、これらの参照トークンは、様々な方法で生成することができ、様々な形式（例えば、一意であることが保証された長い乱数）をとることができ、いくつかの実施形態においては、複数の参照トークンを、単一の命令ルールセットについて生成し、これに関連付けることができる。いくつかの実施形態において、参照トークンは、ユーザに関連する任意の識別情報を欠くことによって、および／または参照トークンに関連する命令ルールセットの条件に関する任意の情報を欠くことによって（例えば、そのような参照トークンを呼び出す潜在的トランザクションへの他の関係者が、ユーザおよび／または関連する命令ルールセットに関するそのような情報を取得するのを防ぐために）など、ユーザによる参照トークンの匿名および／またはプライベート使用を可能にする方式で生成される。
【００１５】
使用法命令ルールセットが定義され、関連する参照トークンが生成された後に、これらを使用して、命令ルールセットの以前に定義された条件によってプログラム的トランザクションの自動的承認を可能にすることができる。具体的には、いくつかの実施形態において、潜在的なプログラム的トランザクションへの複数の関係者（例えば、ウェブサービス提供者、ウェブサービス消費者、およびオプションでエンドユーザ呼出し者）のそれぞれは、その潜在的トランザクションの承認に使用される参照トークンならびにその潜在的トランザクションに関する様々な情報を供給する。これらの参照トークンおよび潜在的トランザクションに関する様々な情報は、そのトランザクションが承認されるかどうかの自動決定（例えば、リアルタイムの方式などの動的決定）のために、このトランザクション承認システムに供給することができる。下でより詳細に述べるように、いくつかの実施形態において、供給された参照トークンに基づく、潜在的トランザクションが承認されるかどうかのこのトランザクション承認システムによる自動決定は、これらの参照トークンに関連する命令ルールセットを取り出すことと、その後、それらの命令ルールセットに互換性があるかどうかを決定することとが含まれる。
【００１６】
このトランザクション承認システムに供給される、潜在的トランザクションに関する情報は、様々な実施形態および状況で変えることができる。例えば、トランザクションに関する情報を、いくつかの状況において、単に、関係者のうちの１つによって別の関係者に支払われるトランザクションの量に制限することができ、一方で他の状況において、トランザクションに関する様々な追加の詳細を供給することができる（例えば、トランザクションのタイプ）。さらに、いくつかの状況において、このトランザクション承認システムへの呼出しは、（支払う場合に）この潜在的トランザクションへの複数の関係者のそれぞれが、別の関係者かおよび／またはトランザクション承認システムへ料金として、支払うことになることについての詳細をさらに指定することができる。
【００１７】
使用法命令ルールセットに互換性があるかどうかの決定は、各命令ルールセット内の各ルールが現在の潜在的トランザクションについて満たされるかどうかを決定することによってなどの、様々な実施形態で様々な方法で実行することができる。そのようなルールを満たすことは、潜在的トランザクションに関する情報（例えば、トランザクションのタイプおよび／またはトランザクションに関連する支払額）、トランザクションへの１以上の他の関係者に関する情報（例えば、関係者が指定された判断基準を満たすかどうか）、潜在的トランザクションについて指定された１以上の他の命令ルールセットに関する情報（例えば、他の命令ルールセット内の１以上の対応するルールがルールと一致または他の形で互換性があるかどうか）などに基づくなど、異なるタイプのルールについて様々な方法で発生し得る。逆に、いくつかの状況で、命令ルールセットが使用にあたり現在利用可能でない（例えば、命令ルールセットが失効しているか、さもなけれれば許容可能なユーザの総数または総許容可能支払額を超えていることに基づくなどで現在使用のために利用可能でない）場合および／または命令ルールセットをその潜在的トランザクションについて使用できない場合など、潜在的トランザクション時点の条件に基づいて、命令ルールセット（およびそれらに関連する参照トークン）のうちの１以上が現在の潜在的トランザクションについて無効なので、命令ルールセットに互換性がないと決定される場合がある。
【００１８】
１以上の関連する金銭的支払いを有する潜在的トランザクションが、承認されることが自動的に決定されるときに、トランザクション承認システムは、いくつかの実施形態においてさらに、適当に関係者の間の支払い交換を実行または容易にすることができる。例えば、いくつかの実施形態において、支払いを提供するユーザは、１以上の支払い手段（例えば、クレジットカード、銀行口座など）を事前に指定している場合があり、その場合は、金銭的支払いを、適当な方式でこれらの支払い手段のうちの１以上から得ることができる（例えば、その支払いを提供するユーザについての支払い命令ルールセットによって指定された支払い手段から）。同様に、支払いを受け取るユーザは、事前に１以上の支払いリポジトリ（例えば、銀行口座、デビットカードなど）を指定している場合があり、その場合は、金銭的支払いを、適当な方式でこれらの支払いリポジトリのうちの１以上に提供することができる（例えば、その支払いを受け取るユーザの支払い命令ルールセットによって指定された支払いリポジトリへ）。
【００１９】
このトランザクション承認システムが、潜在的なトランザクションを承認し、オプションでその潜在的トランザクションについての任意の関連する金銭的支払いを実行した後に、トランザクションの関係者は、適当な方式でそのトランザクションを実行することができる。例えば、そのトランザクションが、料金ベースのウェブサービストランザクションである場合に、ウェブサービス消費者は、そのウェブサービスを呼び出すことができ、そのウェブサービスの提供者は、そのウェブサービスに関連する機能をその消費者に提供することができる。
【００２０】
いくつかの実施形態において、潜在的なトランザクションが承認および／または実行された後であっても、このトランザクション承認システムによって追加の制限を課すことができる。例えば、いくつかの状況で、支払いが預けられたトランザクション承認システムのアカウントへのアクセスを制限することによって、および／または受取人の別の支払いリポジトリへの受け取られた支払いの一部またはすべての預金を遅延させることによってなど、支払いの受取人が、これらの支払いをすぐに引き出すかまたは受け取ることを許されないことがある。そのような支払いアクセス制限は、トランザクションが承認および／または実行された後の指定された時間期間の間に、任意の論争が解決され、任意の払戻しが自動的になされる（例えば、払戻しの額についての支払い受取人への入金相殺として）ことを可能にすることを含む、様々な方式で様々な理由について実行することができる。いくつかの実施形態において、追加の関連する機能を、さらに、このトランザクション承認システムによって、あるいは任意のそのような払戻しの資金を保証または提供する料金ベースの保険引受けまたは保険サービスなどの第三者から提供することができ、したがって、支払い受取人が、任意の受け取られた支払いへの即座またはよりすばやいアクセスを有することが可能になる。
【００２１】
いくつかの実施形態において、このトランザクション承認システムのユーザは、支払い命令ルールセットの代わりにまたはそれに加えてのどちらであれ、料金ベーストランザクションの承認以外の状況で使用される他のタイプの使用法命令ルールセットをより一般的に定義することができる。例えば、そのような使用法命令ルールセットはそれぞれ、制限された情報または制限されたサービスへのアクセスを提供するかどうかを決定するためなど、その使用法命令ルールセットが料金を含まない潜在的トランザクションを承認できる条件を規定する１以上の指定されたルールを含めることができる。
【００２２】
さらに、使用法命令ルールセットのルールは、様々な実施形態で様々な方法で指定および使用することができ、さらに、様々な実施形態で様々な形式を有することができる。例えば、いくつかの実施形態において、あるルールが、あるタイプの検査すべき情報と、その情報に関して実行するためのタイプの評価と、評価の結果がルールを満たすかどうかを決定するテストとを指定することができる。より一般的に、他の実施形態において、あるルールが、そのルールが指定された状況で満たされるかどうかを決定するために検査および／または評価することができる任意の条件または情報を反映することができる。例えば、いくつかの実施形態において、ＸＭＬフォーマットを使用してルールを指定することができ、さらにいくつかの実施形態において、ＸＭＬ文書として命令ルールセットを指定および／または保管することができる。
【００２３】
さらに、いくつかの実施形態において、各既定のタイプのルールが、命令ルールセットの使用に関連する条件のタイプを指定し、各ユーザ選択が、作成される命令ルールセットについて使用法条件がどのようにまたはいつ満たされるかに影響するように、既定のルールタイプをカスタマイズするために１以上のパラメータ値を指定することを含むなど、ユーザは、使用法命令ルールセットを作成するときに様々な既定のタイプのルールから選択することができる。さらに、いくつかの実施形態において、ユーザは、ルールが満たされるときを決定するユーザ指定のプロシージャをそれぞれが示すルールなど、様々なユーザ指定のルールを指定することができる（例えば、呼び出されたときに、ルールが満たされるかどうかに関する指示を提供する、ルールに関する実行可能コードを提供することによって、あるいはその代わりに、アクセス可能なユーザ指定のウェブサービスまたは他の関数を、指定されたパラメータ値を使用して呼び出すことによるなど、ルールが満たされるかどうかを示す応答を自動的に取得する方法を示すことによって）。
【００２４】
いくつかの実施形態において、ルールの評価はさらに、自動化された方式および／または１以上のユーザに関して対話的な方式でなど、ルールが満たされるかどうかに関する決定の一部として使用される追加情報を取得することを含めることができる（例えば、評価を確認および／または追加情報を提供するために、命令ルールセットを作成したユーザにクエリすることによって）。さらに、使用法命令ルールセットのセキュリティおよび／またはプライバシに関連する機能が提供されるいくつかの実施形態においては、命令ルールセット内のルールのうちの１以上を使用して、その機能を提供することができ（例えば、その命令ルールセットにアクセスおよび／または変更できる人を制限することによって）、一方で他の実施形態では、そのような機能を、他の方式で提供することができる（例えば、１以上の命令ルールセットを関連付けることができるユーザアカウントへのアクセスを制御することによって）。
【００２５】
さらに、支払い／使用法命令ルールセットおよびそのルールは、このトランザクション承認システムによって提供されるグラフィカルユーザインターフェース（「ＧＵＩ」）を介して対話的におよび／またはその目的のためにこのトランザクション承認システムによって提供される１以上のウェブサービスの呼出しを介してなど、様々な実施形態で様々な方法で作成することができる。そのようなウェブサービスは、ＨＴＴＰ上のＸＭＬに基づくＡＰＩ（例えば、リソースに焦点を合わせた分散対話モデルであるＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒまたは「ＲＥＳＴ」の一部として）、および／またはＳＯＡＰおよび／またはウェブサービスに関連する他のプロトコルの使用に基づくＡＰＩを使用することなど、様々な方法で実装することができる。さらに、命令ルールセットが作成され、参照トークンに関連付けられた後に、いくつかの実施形態において、その命令ルールセットは、変更が許されないかもしれない。代替案では、いくつかの実施形態において、そのような命令ルールセットを変更することができ、変更された命令ルールセットの新しい参照トークンが、その新しい命令ルールセットについて生成される（例えば、前の参照トークンを置き換えるために）。さらに、いくつかの実施形態において、参照トークンおよび／または関連する命令ルールセットを、意図した使用のときに動的に作成することができ（例えば、プログラム的サービスの呼出しを試みることおよび／または第三者承認者に承認要求を送ることの一部としてまたはその直前に）、一例として、いくつかの実施形態において、使い捨てまたは単一使用のトークンおよび／または命令ルールセットを作成し、使用することができる（例えば、特定の潜在的トランザクションのために）。
【００２６】
さらに、料金ベーストランザクションが承認され、金銭的支払いが処理されるいくつかの実施形態において、ユーザの一部またはすべては、さらに、支払い手段および／または支払いリポジトリとしてユーザが使用できるアカウントなど、そのような支払いを容易にするトランザクション承認システムに関するアカウントを有することができる。そのようなアカウントおよび／または他の金銭の手段／リポジトリは、いくつかの実施形態において、非常に小額の微小な支払いをサポートすることができる。さらに、いくつかの実施形態において、このトランザクション承認システムは、さらに、金銭的支払いトランザクションに関連する料金を最小にするためおよび／または最小支払い額に達することを可能にするためなど、提供および／または受け取られる金銭的支払いの集計を提供することができる（例えば、毎月など、周期ベースで）。他のタイプのアカウントと同様に、そのようなユーザアカウントは、いくつかの実施形態において、最大許容貸方残高など、その使用に関連する様々な条件および制限ならびに様々なセキュリティおよびアクセス制御（例えば、パスワードベースの）を有することができる。
【００２７】
さらに、このトランザクション承認システムは、上では様々な実施形態における様々な機能および能力を提供するものとして説明されたが、いくつかの実施形態において、そのような機能および能力の一部を、その代わりに１以上のシステムにまたがって分割することができる。例えば、いくつかの実施形態において、一部のまたはすべてのユーザが、このトランザクション承認システムが提携するか他の形でアクセスできる別のシステムのユーザアカウントを既に有する場合があり、そうである場合に、アカウント関連機能の一部またはすべてを、このトランザクション承認システムと合わさって、別のシステムによって提供することができる（例えば、命令ルールセットの保管、参照トークンの生成、支払いリポジトリ／手段機能の提供など）。
【００２８】
例示のために、様々な特定のタイプの能力および機能がトランザクション承認システムの特定の実施形態によって実行され、ユーザが、様々なタイプの料金ベースのプログラム的トランザクションを承認するための支払い命令ルールセットなどの特定のタイプの命令ルールセットを特定の形で定義および使用するソフトウェア機能のいくつかの実施形態を下で説明する。しかし、当業者は、本発明の技術を、ウェブサービス以外のサービスおよびアイテムと、金銭的支払いの提供以外の目的とを含む様々な他の状況で使用できることと、本発明が提供される例示的詳細に限定されないこととを理解するであろう。
【００２９】
図２は、ウェブサービス（「ＷＳ」）支払い処理システム（「ＰＨＳ」）金銭のトランザクション承認システム２００の例の実施形態のコンポーネントおよび情報フローを示すネットワーク図である。様々なユーザおよびシステムが、図示の例のＰＨＳと対話して、ユーザおよび／またはシステムの間で発生するトランザクションに関してなどの、支払い処理機能を受け取る。図示の実施形態で、ＰＨＳには、下で説明するように、アカウントシステム２２０とウェブサービストランザクションシステム２１０の両方が含まれる。
【００３０】
詳しくは、図示の実施形態では、アプリケーション開発を実行するユーザ（図示せず）は、コンピューティングシステム２５０を使用して、ＰＨＳと対話２５１して、このユーザによって開発されるアプリケーションプログラムの代わりに後の支払い処理機能を可能にする。アプリケーション開発者ユーザのコンピューティングシステム２５０は、まず、アカウントシステムと対話して、アカウントシステムによって提供される対話型ＧＵＩ  ２２４を介して、またはその代わりにアカウントシステムによって提供される１以上のウェブサービスＡＰＩ  ２２２を介してなど、このアプリケーション開発者のためにユーザアカウント２３０を定義する。図示の実施形態では、そのような各ユーザアカウントに、使用法命令ルールセットを支払いのためにいつどのように使用できるかに関する様々なルールをそれぞれが指定する、１以上の使用法命令ルールセット２３５を含めることができる。さらに、各使用法命令ルールセットは、後にその使用法命令ルールセットを参照するための関連する一意の参照トークン２４０を有する。アプリケーション開発者ユーザが、１以上の使用法命令ルールセットと共にアカウントを作成した後に、ユーザは、彼らが作成する１以上のアプリケーションプログラム２５５内に、その使用法命令ルールセットの参照トークン２５７のうちの１以上を含める。
【００３１】
同様に、ウェブサービスを他者に提供する１以上のユーザ（図示せず）は、コンピューティングシステム２６０を使用して、アカウントシステムの対話型ＧＵＩおよび／またはウェブサービスＡＰＩを介してアカウントシステムと対話２６１する。アプリケーション開発者と同様に、各ウェブサービス提供者ユーザは、アカウントシステムに、１以上の使用法命令ルールセットと共にアカウントを作成することができる。ウェブサービス提供者ユーザは、ウェブサービス提供者がウェブサービスを他者に（例えば、料金のために）共に提供する１以上のウェブサービス提供者トランザクションシステム２６５の一部として、彼らの使用法命令ルールセットについて彼らの参照トークン２６７のうちの１以上を関連付けることができる。
【００３２】
アプリケーションプログラム２５５のうちの１つが、後に、エンドユーザコンピューティングシステム２７０上でエンドユーザ（図示せず）によって実行されているときに、そのアプリケーションプログラムは、ウェブサービスＡＰＩ  ２６９を介するなど、ウェブサービス提供者のトランザクションシステムによって提供される１以上のウェブサービスを呼び出す２９０。しかし、図示の実施形態のウェブサービス提供者は、適当な支払いがアプリケーションプログラムについて提供される場合に限って、要求されたウェブサービスを提供する。したがって、図示の実施形態では、アプリケーションプログラムは、ウェブサービス呼出しの一部として、アプリケーション開発者ユーザの参照トークン２５７を供給する。要求されたウェブサービスをアプリケーションプログラムに提供する前に、ウェブサービス提供者トランザクションシステムは、ＰＳＨトランザクションシステム２１０への連絡２９５をして、ＰＨＳトランザクションシステムのウェブサービスＡＰＩ  ２１２の呼出しを介するなど、適当な承認および支払いを取得する。図示の実施形態では、ウェブサービス提供者トランザクションシステムは、ウェブサービス提供者の参照トークン２６７ならびにアプリケーションプログラムからの参照トークン２５７を、ＰＨＳトランザクションシステムとの対話の一部として提供し、さらに、これから発生するトランザクションおよび関連する支払いに関する情報を提供する。ここには図示されていないが、いくつかの実施形態において、ウェブサービス提供者のトランザクションシステム２６５によって提供される１以上のウェブサービスと参照トークン２６７は、ウェブサービス提供者のウェブサイト（図示せず）の一部として提供されるアプリケーションプログラムなど、ウェブサービス提供者の１以上のアプリケーションプログラムの一部であることができる。
【００３３】
ＰＳＨトランザクションシステム２１０は、図示の実施形態では、まずウェブサービスＡＰＩ  ２１２への呼出しで提供された参照トークンに対応する使用法命令ルールセット２３５に関する情報を取り出すためにアカウントシステム２２０と対話すること、ならびに、さらに、その使用法命令ルールセットが属するユーザアカウント２３０から他の情報を取り出すこととによって、支払いトランザクションが承認されるかどうかを決定する。使用法命令ルールセットおよび他の情報を取得した後に、ＰＳＨトランザクションシステム２１０は、ルールセットが互換であり、要求された支払いが行われることを他の形で承認するかどうかを決定し、そうである場合には、ＰＨＳトランザクションシステムは、その支払いを実行し（例えば、アプリケーションプログラムの参照トークン２５７に関連する支払い手段に請求すること、およびその請求金額の少なくとも一部をトランザクションシステム２６５の参照トークン２６７に関連する支払いリポジトリに預けることによって）、トランザクションシステム２６５に確認を提供し、そこでトランザクションシステム２６５は、最初に要求されたウェブサービスをアプリケーションプログラムに続いて提供する。いくつかの実施形態において、ＰＨＳは、さらに、実行されたトランザクションごとの支払いの一部ならびに／あるいはアカウント作成および／または変更に関連する支払いとしてなど、そのＰＨＳが提供するサービスの一部またはすべてについての支払いを取得することができる。
【００３４】
ＰＳＨトランザクションシステム２１０およびアカウントシステム２２０は、この実施形態では、別々であるが協力するシステムとして図示されているが、他の実施形態では、図示の機能を他の形で提供することができる。例えば、いくつかの実施形態においては、単一のシステムが、アカウント作成および維持能力ならびにトランザクション承認および処理能力の両方を提供することができ、他の実施形態では、トランザクションシステム２１０およびアカウントシステム２２０を、その代わりに、関連しないシステム／組織によって提供することができる。
【００３５】
さらに、支払いタイプのトランザクションだけがこの図に示されているが、他の実施形態では、支払いトランザクションの代わりにまたはこれに加えてのいずれであれ、様々な他のタイプのトランザクションを実行することができる。さらに、図示の実施形態では、トランザクションシステム２６５のウェブサービスを使用することに関する使用回数による料金を述べるが、他の実施形態では、１以上のアプリケーションプログラム２５５に関するトランザクションシステム２６５の１以上のウェブサービスの進行中のサブスクリプションなど、様々な他のタイプの購入トランザクションを実行することができる。代替案では、ウェブサービスの指定された回数の使用または指定された時間期間中の無制限の回数の使用を、その代わりに、アプリケーションプログラム２５５をエンドユーザに配布する前にアプリケーション開発者ユーザによってなど、購入し、参照トークン２５７に関連付けることができる。そのような状況では、サブスクリプションまたは他の複数回使用購入に関する情報を、様々な形でアカウントシステムによって保管することができ、その結果、トランザクションシステム２１０は、後に、支払いトランザクションが承認されることを決定できるようになる。使用法命令ルールセットを使用するプログラム的トランザクションの自動承認に関する追加の詳細は、参照によってその全体を本明細書に組み込まれている、本願と同時に出願された特許文献１（弁理士整理番号１２０１３７．４８９）に含まれる。
【００３６】
図９Ａ〜９Ｂおよび１０Ａ〜１０Ｃのそれぞれに、第三者トランザクション承認システム（この例においては「Ｓｕｂｗａｙ」と称する）によって自動的に承認されるプログラム的トランザクションの実行の追加の例を示す。具体的に言うと、図９Ａおよび９Ｂには、ウェブサービスベースのプログラム的トランザクションに関するマシン対マシンマイクロペイメントを行う例が示されている。この例では、「ＭａｐＸ」と称するウェブサービス提供者が、呼出し１回あたり１セントの料金で住所によって地図をサービスするウェブサービスを提供する。「ＣｅｌｌＸ」は、様々なエンドユーザ消費者に提供されるセル電話（または「携帯電話」）サービスの一部としてのこのウェブサービスの潜在的ウェブサービス提供者である。ＣｅｌｌＸが、ＭａｐＸのプログラム的マッピングサービスへの入会に署名した後に、ＣｅｌｌＸは、このＭａｐＸサービスを使用して、地図をそのセル電話サービスカスタマが利用可能にする。
【００３７】
図９Ａおよび９Ｂの例の図示の一連の動作は、ＭａｐＸの代理人（図示せず）が、Ｓｕｂｗａｙトランザクション承認システム９２０を用いて対話的アカウントセットアップ動作９３１を実行すること、具体的には、Ｓｕｂｗａｙシステム９２０によって提供されるウェブサイト９２２を使用してＭａｐＸに関する情報（例えば、ＭａｐＸの信用証明情報および自動決済機関（または「ＡＣＨ」）銀行情報）を指定することから開始される。次に、Ｓｕｂｗａｙウェブサイト９２２は、Ｓｕｂｗａｙウェブサービス９２４と対話して、ＭａｐＸに関する受け取った情報を提供することと、それに答えて新しいアカウントのＩＤを受け取ることとによって、ＭａｐＸのアカウントを作成する。次に、ＭａｐＸの代理人は、Ｓｕｂｗａｙウェブサービス９２４とのプログラム的対話９３３を開始して、ＭａｐＸの信用証明、アカウントＩＤ、および支払い命令ルールセットのルール９３３ａを提供することによってＭａｐＸの支払い命令ルールセットを作成し、ＭａｐＸの代理人によるそのようなプログラム的対話には、後にマッピングウェブサービスを消費者に提供するＭａｐＸウェブサービス提供者アプリケーション９１０を使用すること、またはその代わりに、別のプログラム（図示せず）を使用することを含めることができる。Ｓｕｂｗａｙシステム９２０は、支払い命令ルールセットをストレージ９２６に保管し９２６ａ、関連するトークンをＭａｐＸ代理人に返し、ＭａｐＸ代理人は、そのトークンを、後にトランザクションを承認する際に使用するためにＭａｐＸウェブサービス提供者アプリケーション９１０に含める。支払い命令ルールセットを登録した後に、ＭａｐＸは、ＭａｐＸアプリケーション９１０を使用して、マッピングウェブサービスをウェブサービスの潜在的消費者に提供することができる。
【００３８】
次に、ＣｅｌｌＸの代理人（図示せず）は、ＭａｐＸアプリケーション９１０と対話９３５して、ＭａｐＸマッピングサービスの入会に署名し（例えば、ＭａｐＸアプリケーション９１０の適当なウェブサービスを使用して署名アクティビティを実行することによって）、それに答えてＭａｐＸのトークンを受け取る。ＣｅｌｌＸ代理人は、Ｓｕｂｗａｙウェブサイト９２２と対話してＣｅｌｌＸに関する情報を指定することによってＳｕｂｗａｙシステム９２０でのアカウントセットアップ動作９３７も実行し、それに答えてアカウントＩＤを受け取る。アカウントＩＤを取得するために、Ｓｕｂｗａｙウェブサイト９２２は、Ｓｕｂｗａｙウェブサービス９２４と対話して、ＣｅｌｌＸから受け取った情報を提供することによってＣｅｌｌＸアカウントを作成する。次に、ＣｅｌｌＸ代理人は、Ｓｕｂｗａｙウェブサービス９２４とのプログラム的対話９３９を開始して、ＣｅｌｌＸの信用証明、アカウントＩＤ、および支払い命令ルールセットのルール９３９ａを提供することによって、ＣｅｌｌＸの支払い命令ルールセットを作成する。次に、Ｓｕｂｗａｙシステム９２０は、その支払い命令ルールセットをストレージ９２６に保管し９２６ａ、関連するトークンをＣｅｌｌＸ代理人に返し、ＣｅｌｌＸ代理人は、そのトークンを、ＣｅｌｌＸからセル電話サービスを介してＣｅｌｌＸカスタマが利用可能なＣｅｌｌＸアプリケーション９０５に含める。支払い命令ルールセットを登録した後に、ＣｅｌｌＸは、ＣｅｌｌＸアプリケーション９０５を介して、ＭａｐＸのマッピングウェブサービスをそのカスタマに提供することができる。
【００３９】
次に、ＣｅｌｌＸセル電話サービスのカスタマは、ＣｅｌｌＸアプリケーション９０５のオンラインディレクトリサービスの一部である地図関連リンクを選択することによるなど、ＭａｐＸアプリケーション９１０からのＭａｐＸのマッピング機能を使用するＣｅｌｌＸアプリケーション９０５内の機能を選択する９４１。次に、このユーザ選択は、このカスタマの選択に対応する特定の地図を要求するために、ＣｅｌｌＸアプリケーション９０５に、ＭａｐＸアプリケーション９１０からＭａｐＸウェブサービスをプログラム的に呼び出させ、この呼出しには、前にＣｅｌｌＸアプリケーション９０５に関連付けられたＣｅｌｌＸ参照トークンを提供することが含まれる。次に、ＭａｐＸアプリケーション９１０は、このトランザクションに関する情報、ＭａｐＸの信用証明、ならびにＭａｐＸおよびＣｅｌｌＸの参照トークンを含む支払い承認要求をＳｕｂｗａｙウェブサービス９２４にサブミットする。次に、Ｓｕｂｗａｙシステム９２０は、それらの参照トークンの支払い命令ルールセットを取り出し９２６ｂ、これらを使用して、このトランザクションが承認されるかどうかを決定し、この呼出しに関するＣｅｌｌＸからＭａｐＸへの支払いを実行し、トランザクション承認を示すトランザクションＩＤをＭａｐＸアプリケーション９１０に返す。次に、ＭａｐＸアプリケーション９１０は、要求された地図をＣｅｌｌＸアプリケーション９０５に提供し、ＣｅｌｌＸアプリケーション９０５は、その地図をカスタマに表示する。ＭａｐＸアプリケーション９１０およびＣｅｌｌＸアプリケーション９０５の可能な実装の一例として、ＣｅｌｌＸアプリケーション９０５は、前に図２で説明したアプリケーションプログラム２５５に似た形で動作することができ、ＭａｐＸアプリケーション９１０は、前に図２で説明した、ＷＳ  ＡＰＩ  ２６９を含むＷＳ提供者トランザクションシステム２６５のアプリケーションプログラムに似た形で動作することができる。
【００４０】
図１０Ａ〜１０Ｃに、プログラム的トランザクションを承認するための支払い命令ルールセットの使用のもう１つの例を示すが、このトランザクションには、この例では、ウェブサービスを介して第三者販売者のためのショッピングカート機能を実装するためにアプリケーション９６０を提供するユーザ（「Ｒｏｂ」と命名する）が含まれる。そのような販売者は、Ｒｏｂのショッピングカート機能の入会に署名することができ、Ｒｏｂのショッピングカートアプリケーション９６０とインターフェースするカスタマ選択可能コントロールを販売者のアプリケーションに含めることによって、Ｒｏｂのショッピングカート機能を使用することができ、Ｒｏｂのショッピングカートアプリケーション９６０は、各販売者のカスタマごとにセッション情報を維持する。カスタマが、販売者のアプリケーションを介してチェックアウトするときに、Ｒｏｂのショッピングカートアプリケーション９６０は、Ｓｕｂｗａｙトランザクション承認システム９７０と対話して、カスタマから販売者への支払いを処理する。
【００４１】
図１０Ａ〜１０Ｃの例の図示の一連の動作は、販売者の代理人（図示せず）が、Ｒｏｂのショッピングカートアプリケーション９６０と対話することによってＲｏｂのショッピングカートサービスへの入会に署名するために対話型動作９８１を実行することから開始され、Ｒｏｂのショッピングカートアプリケーション９６０は、まず、この代理人を、Ｓｕｂｗａｙトランザクション承認システム９７０にリダイレクトして、販売者の支払い命令ルールセットを登録する。販売者代理人は、次に、Ｓｕｂｗａｙシステム９７０によって提供されるウェブサイト９７２と対話して、サインインし（この例では、販売者は、既にＳｕｂｗａｙシステム９７０のアカウントを有する）、支払い指示ルール情報９８１ａをＳｕｂｗａｙシステム９７０に提供する。次に、Ｓｕｂｗａｙウェブサイト９７２は、Ｓｕｂｗａｙウェブサービス９７４と対話して、Ｒｏｂのショッピングカートウェブサイトアプリケーション９６０の信用証明、販売者のアカウントＩＤ、および支払い命令ルールセットのルール９８１ａを提供することによって支払い命令ルールセットを作成する。次に、Ｓｕｂｗａｙシステム９７０は、その支払い命令ルールセットをストレージ９７６に保管し９７６ａ、関連するトークンをＲｏｂのショッピングカートウェブサイトアプリケーション９６０を介して販売者に返す。次に、販売者は、販売者のウェブサイトアプリケーション９５５の一部としてショッピングカート機能に関連するカスタマ選択可能コントロールを含め、これらのコントロールは、Ｒｏｂのショッピングカートウェブサイトアプリケーション９６０によって提供される対応するウェブサービスを呼び出している間にパラメータとして販売者参照トークンを使用する適当なＵＲＬに関連する。
【００４２】
次に、販売者のカスタマは、販売者のウェブサイトアプリケーション９５５と対話９８３して、適当なコントロールを選択してカスタマのショッピングカートにアイテムを追加し、これによって、カスタマのセッションＩＤおよび販売者の参照トークンを含む情報が、販売者アプリケーション９５５からＲｏｂのショッピングカートウェブサイトアプリケーション９６０に送られる。カスタマが、その後、販売者ウェブサイトアプリケーション９５５を介してチェックアウトに進むことを示すときに、販売者アプリケーション９５５は、情報をＲｏｂのショッピングカートアプリケーション９６０に送り、Ｒｏｂのショッピングカートアプリケーション９６０は、カスタマのショッピングカート内のアイテムの購入に対応する額に関するそのカスタマの支払い指示ルールの使い捨てセットを動的に指定するためにＳｕｂｗａｙウェブサイト９７２と対話する。カスタマは、必要な場合にアカウントの作成を含めて、Ｓｕｂｗａｙウェブサイト９７２でサインインするようにプロンプトを出される。次に、Ｓｕｂｗａｙウェブサイト９７２は、Ｓｕｂｗａｙウェブサービス９７４との対話に進んで、Ｒｏｂのショッピングカートウェブサイトアプリケーション９６０の信用証明、カスタマのアカウントＩＤ、および支払い命令ルールセットのルール９８３ａを提供することによって支払い命令ルールセットを作成する。次に、Ｓｕｂｗａｙシステム９７０は、その支払い命令ルールセットをストレージ９７６に保管し９７６ａ、カスタマの関連するトークンをＲｏｂのショッピングカートウェブサイトアプリケーション９６０に返す。
【００４３】
販売者のカスタマが、販売者ウェブサイトアプリケーション９５５を介して「Ｃｏｎｆｉｒｍ  Ｏｒｄｅｒ（注文を確認する）」コントロールを選択することによって注文を行うことを示すときに、販売者アプリケーション９５５は、セッションＩＤを含む表示をＲｏｂのショッピングカートウェブサイトアプリケーション９６０に送る。次に、Ｒｏｂのショッピングカートウェブサイトアプリケーション９６０は、前に作成された、そのカスタマの参照トークンを取り出し、このトランザクションに関する情報、ショッピングカートウェブサイト信用証明、ならびに販売者およびカスタマの参照トークンを含む支払い承認要求をＳｕｂｗａｙウェブサービス９７４にサブミットする。次に、Ｓｕｂｗａｙシステム９７０は、その参照トークンの支払い命令ルールセットを取り出し９７６ｂ、これらを使用して、そのトランザクションが承認されることを決定し、そのトランザクションに関するカスタマから販売者への支払いを実行し、トランザクションＩＤをＲｏｂのショッピングカートウェブサイトアプリケーション９６０に返して、トランザクション承認を示す。
【００４４】
図１Ａ〜１Ｂは、トランザクション承認および処理システムによる後の使用のためにアカウントおよび使用法命令ルールセットを作成するためのユーザによる対話の例を提供する。具体的に言うと、図１Ａは、ウェブサービス提供者ユーザＡＢＣが、アカウントシステムによって提供されるウェブページ内のフォームに記入することによるなど、それを介してユーザアカウントを対話的に作成するＧＵＩの例を提供する。この図示の例では、対話作成例画面に、概要情報を含むヘディング領域１１１と、それに続く、アカウント名、アカウントを表示し、変更するためのアクセス制御用のパスワード、すべてのオプションの証明書、およびすべてのオプションの組織提携など、アカウントに関する様々な一般情報をユーザがそこで指定できる領域１１３とが含まれる。この例では、ＡＢＣによって提供されるウェブサービスの潜在的消費者の一部の使用法命令ルールセットが、ＡＢＣへの支払いを承認するために第三者からの証明を要求する場合があるので、ユーザＡＢＣは、第三者会社ＢＣＤ  Ｃｏｒｐｏｒａｔｉｏｎからの証明を指定する。同様に、ＡＢＣのウェブサービスの潜在的消費者の使用法命令ルールセットが、同様に、ユーザＡＢＣへの支払いを承認するために１以上の組織提携を要求する場合があるので、ユーザＡＢＣは、それ自体の会社と様々なウェブサービス提供者の連盟との両方への組織提携を指示する。
【００４５】
この例では、アカウント作成画面に、オプションのセクション１１４も含まれ、このセクション１１４では、ユーザＡＢＣが、料金ベースウェブサービスの消費者への提供に関してなど、そのユーザが受け取ることのできる支払い用の１以上の支払いリポジトリを指定することができる。この例の実施形態では、ユーザＡＢＣは、銀行口座とデビットカードを含む、入ってくる支払いを預けることができる２つの支払いリポジトリを指定する。このユーザは、さらに、預けられるすべての支払いが少なくとも５セントの最小額でなければならないように、デビットカードに関する制限を指定する。この図示の実施形態のセクション１１４には、作成されるユーザアカウント自体がそのユーザの支払いリポジトリとして働くことも示されている。
【００４６】
このアカウント作成画面には、セクション１１５も含まれ、このセクション１１５で、ユーザＡＢＣは、他者に対して行われる支払いに使用される１以上の支払い手段を指定することができる。この例では、ユーザＡＢＣは、利用可能な支払い手段として、この口座からのすべての個々の支払いが５０ドルを超えないという制限付きで同一の銀行口座、ならびに２００ドルの最大の個々の支払いおよび２０００ドルの最大累積差引勘定という制限付きでクレジットカード支払い手段を指定する。セクション１１５は、同様に、作成されるユーザアカウントが、そのユーザによる支払い手段として利用可能であることを示し、このユーザアカウントには、このユーザに関して、この例では１０００ドルの最高差引勘定信用限度が含まれる。様々なタイプの情報を指定した後に、ユーザは、コントロール１１６ｂを選択して、アカウントを作成することができ、あるいは、ユーザは、その代わりにコントロール１１６ａを選択して、アカウント作成をキャンセルすることができる。
【００４７】
図示の実施形態では、まずユーザアカウントを作成した後に、ユーザは、図１Ｂに示された例の画面を介して、１以上の使用法命令ルールセットを作成するオプションを提示される。具体的に言うと、図示の画面には、概要情報を有するヘッダセクション１１７と、作成される使用法命令ルールセットに関する様々な情報をそこで指定できるルール指定セクション１１８とが含まれる。この例では、セクション１１８は、ユーザが、作成される使用法命令ルールセットの名前、ルールセットの使用法タイプ（この例では支払いを受け取るため）、すべてのそのような支払いを受け取る支払いリポジトリ、およびこの例では指定されていない失効日を指定することを可能にする。ユーザＡＢＣは、このルールセットの１以上の特定のルールを指定することもできる。この例には、定義済みの２つのルールと、この例のこの使用法命令ルールセットについて選択でき、カスタマイズできる他のタイプのルール属性を示す第３のルールのドロップダウンメニューとが示されている。
【００４８】
例えば、ユーザＡＢＣは、この使用法命令ルールセットが、最初の「ＡｌｌｏｗｅｄＰａｙｅｒｓ（承認される支払人）」役割属性を満たすユーザからの支払いを受け取るだけであることを指定しており、この役割属性は、この例では、支払人の指定された組織提携、支払人のレーティング、またはそのＩＤが示された特定の支払人に基づいて満たすことができる。示されているように、この例で指定できる他の役割属性には、ユーザＡＢＣが支払いを受け入れない、承認されないまたはブロックされた支払人、この使用法承認ルールセットを使用できる承認されるまたは承認されないトランザクションタイプの指定、受け取られる支払いの支払い手段および通貨の承認されるまたは承認されないタイプ、発生するすべての論争を後に扱うための諸条件などが含まれる。さらに、図示の実施形態は、ユーザが、実行可能コードおよび／またはアクセス可能な実行可能な機能を呼び出すメカニズム（例えば、ウェブサービス）を含めることによるなど、ユーザ定義のルールを指定することを可能にする。作成される使用法命令ルールセットに関する様々な情報を指定した後に、ユーザＡＢＣは、セクション１０９内のコントロールのうちの１つを選択して、現在の使用法命令ルールセットを作成し、このアカウントの別のルールセットの作成を継続するか、現在の使用法命令ルールセットを作成し、アカウント変更を終了するか、現在の使用法命令ルールセットの作成をスキップし、終了することができる。
【００４９】
この例に示されたルール属性のタイプは、例のために単純化された形で提供され、類似する情報を、その代わりに他の状況で他の形で指定することができる。例えば、承認されるおよび承認されない支払人について異なる属性を有するのではなく、あるユーザが承認されるかまたは承認されないかのどちらであるかを決定するのに使用される、タイプの評価判断基準（例えば、ルールを満たすために、支払人が指定された値「ＩＳ（である）」または「ＩＳ−ＮＯＴ（でない）」ことが指定される）と共に、支払人の単一の属性を、その代わりに提供することができる。例の属性に関する追加の詳細は、他所で述べる。
【００５０】
図１Ｃに、ユーザアカウントの使用法命令ルールセットを作成する代替技術を示す。具体的に言うと、この例の実施形態では、ユーザアカウントおよび使用法命令ルールセットは、ＷＳ支払いハンドラシステムによって提供される１以上のウェブサービスを介するなど、ウェブサービス消費者アプリケーション開発者ユーザＣＤＥによってプログラム的に作成される。この例の実施形態では、プログラム的呼出しの一部として提供される情報に、図１Ｃに示された例のＸＭＬ文書１３１が含まれる。この例のＸＭＬ文書は、作成される使用法命令ルールセットが関連付けられるアカウントＩＤ（例えば、ユーザアカウントを作成する、以前のプログラム的呼出しに応答してこのユーザが受け取ったアカウントＩＤ）を指定し、さらに、図１Ｂに関する対話的な形で指定されたものに似た様々な情報を提供する。
【００５１】
具体的に言うと、この使用法命令ルールセットは、料金ベースウェブサービス（例えば、ウェブサービス提供者ユーザＡＢＣによって提供される１以上のウェブサービス）など、ユーザＣＤＥによって作成される１以上のアプリケーションプログラムによって呼び出されるトランザクションンの支払いを提供する際に使用するためにユーザＣＤＥによって作成されつつある。この例では、作成される使用法命令ルールセットは、ユーザＣＤＥのＰＨＳアカウント（この例では名前「ＭｙＰＨＳＡｃｃｏｕｎｔ」によって指定される）を使用し、指定された失効日を有する。この使用法命令ルールセットについて定義された２つのルールのうちの２番目のルールは、さらに、適当な評価タイプおよびルール値と共に既定のルール属性「ＰａｙｍｅｎｔｓＡｌｌｏｗｅｄ（承認される支払い）」を使用することによって、この使用法命令ルールセットが承認できる総支払いを１０００ドルの額以下になるように制限する。この使用法命令ルールセットについて指定された第１のルールは、この使用法命令ルールセットを使用できない特定の支払い受取人を識別し、この特定の支払い受取人は、この例では、「ＤｉｓａｌｌｏｗｅｄＲｅｃｉｐｉｅｎｔ（承認されない受取人）」という、より特定の属性タイプではなく、「Ｒｅｃｉｐｉｅｎｔ（受取人）」という一般属性と、「ＩＳ−ＮＯＴ」という適当な評価タイプとを用いて指定される。他の実施形態では、対応する情報を、その代わりに、他のフォーマットを使用するＸＭＬ文書内および／またはＸＭＬ以外の形を含む、様々な他の形で提供することができる。
【００５２】
図１Ｃには、ＷＳ支払いハンドラシステムへの第２のプログラム的呼出しに付随するためなど、ユーザＣＤＥのアカウントのもう１つの使用法命令ルールセットを作成する第２のＸＭＬ文書１３３も示されている。具体的に言うと、この第２の使用法命令ルールセットは、この例ではアクセス制御情報を指定するためなど、支払い処理以外のタイプのトランザクションに関する使用法命令ルールセットの例を示す。例えば、ユーザＣＤＥは、１以上のプログラム的サービスまたは情報のソースへのアクセスを提供するサブスクリプションまたは他のメンバシップを有する場合があるが、ユーザＣＤＥは、そのようなアクセス権がこのユーザによって提供される１以上のアプリケーションから利用可能にされるときを制限することを望む場合がある。この例では、ＸＭＬ文書１３３で作成される使用法命令ルールセットには、関連する支払い手段が含まれるのではなく、サブスクリプション／メンバシップに従ってアクセスを得るために提供しなければならないユーザ名およびパスワードを含む様々なアクセス情報が含まれ、他の実施形態および状況では、様々な他のタイプのアクセス制御情報を、その代わりに指定し、使用することができる。
【００５３】
この使用法命令ルールセットは、この例では「Ａｌｌｏｗｅｄ−Ｕｓｅ（承認される使用）」というユーザ指定の名前を与えられる（例えば、図示されていない他のすべてのユーザ定義ルールと独立にこのユーザ定義ルールを参照する際に後に使用するために）ユーザ定義ルールの定義の例、ならびに、実行されたときに、図示されているように、ルールが満たされるかどうかを示す応答を提供するＵＲＩベース呼出し指定も示されている。この例では、呼出し指定には、大括弧に囲まれたパラメータ「ａｃｃｅｓｓ−ｐｒｏｖｉｄｅｒ．ｎａｍｅ」を、この使用法命令ルールセットが特定のトランザクションについてマッチングされるアクセス提供者の使用法命令ルールセットのアカウントからの対応する名前に置換することによって、特定の潜在的トランザクションに固有の情報を記入されるパラメータの表示が含まれる。そのようなユーザ定義のルールは、この使用法命令ルールセットを使用するアプリケーションおよび／またはそのアプリケーションプログラムを実行するエンドユーザに関する情報を含む、様々なタイプの情報を使用して、様々な形で特定の状況で、そのルールが満たされるかどうかに関する決定を行うことができる。同様に、ユーザ定義のルールは、ユーザ定義のルールが関連付けられる使用法命令ルールセットの作成の一部として実行可能コード（例えば、スクリプトまたはアプレット）を提供することによるものを含む、様々な他の形で、他の実施形態で、定義し、呼び出すことができる。
【００５４】
図１Ｄおよび１Ｅに、作成されたユーザアカウントおよび使用法命令ルールセットに関する情報を保管する際に使用される複数の例のデータベースを示す。具体的に言うと、図１Ｄは、作成されたユーザアカウントに関する様々な情報を保管する、例のアカウントデータベース１４０を示し、エントリ１４０ａ〜１４０ｂのそれぞれは、別個のユーザアカウントに対応する。この例では、各エントリに、アカウントを作成するユーザによって指定された情報だけではなく、そのアカウントについて自動的に生成され、そのアカウントに関連付けられる情報も含まれる。例えば、エントリ１４０ａは、その作成を前に図１Ａに関して述べたユーザアカウントに対応し、列１４３〜１４６には、図１Ａのセクション１１３でユーザによって指定された情報が含まれる。さらに、このアカウントが作成されたときに、ＰＨＳは、このアカウントの一意のアカウントＩＤを作成したが、このアカウントＩＤが、列１４１に保管される。さらに、この例では、ユーザＡＢＣは、図１ＡのＰＨＳアカウントの作成の前に既にＰＨＳまたは関連するシステムに既知であり、列１４２に、このユーザに以前に関連付けられた（例えば、ウェブ販売者または店に関するなど、ユーザＡＢＣについて以前に作成されたユーザアカウントの一部として）、ユーザＡＢＣのユーザＩＤが含まれる。
【００５５】
さらに、図１Ａに関して前に述べたように、この例の実施形態では、ＰＨＳは、ユーザのうちの少なくとも一部について、彼らのＰＨＳアカウントを支払いリポジトリまたは支払い手段として使用する能力を提供する。したがって、列１４９および１５０に、アカウントの現在の差引勘定およびアカウントについて許容される最高差引勘定（例えば、アカウント作成のときにユーザ固有の形で動的に決定され、オプションでユーザとの後の経験に基づいて調整される最高差引勘定）を含む、ユーザのＰＨＳアカウントのその態様に対応する情報が含まれるが、ユーザＡＢＣは、この例ではＰＨＳアカウントを支払いリポジトリまたは支払い手段として使用しないので、現在の勘定残高は０である。この図には示されていないが、アカウントについて以前に実行されたトランザクションの表示、アカウントに対して行われた変更、他のユーザおよびこれらのユーザがアカウントにアクセスするための関連するアクセス制御の表示など、様々な他のタイプの情報をアカウントに関連付けることができる。エントリ１４０ｂには、図１Ｃに関して前に述べた、ユーザＣＤＥのアカウントに関する類似する対応する情報が含まれる。
【００５６】
アカウントデータベース１４０の列１４７および１４８には、ユーザアカウントと共に使用するために定義されたすべての支払いリポジトリおよび支払い手段に関する情報が含まれる。具体的に言うと、エントリ１４０ａの列１４７の情報は、図１Ａのセクション１１４で指定された支払いリポジトリに対応し、エントリ１４０ａの列１４８の支払い手段情報は、同様に、図１４Ａのセクション１５５で指定された支払い手段に対応する。この例では、各支払いリポジトリおよび支払い手段が、一意のＩＤを与えられ、このＩＤは、列１４７および１４８に保管され、追加の例のデータベースである支払いリポジトリデータベース１８０および支払い手段データベース１９０は、それぞれユーザ指定の支払いリポジトリおよびユーザ指定の支払い手段に関する情報を保管する。この例の実施形態では、支払いリポジトリデータベースおよび支払い手段データベースのそれぞれに、それぞれ、個々の支払いリポジトリおよび支払い手段に対応する複数のエントリ１８０ａ〜１８０ｂおよび１９０ａ〜１９０ｃが含まれる。
【００５７】
さらに、データベース１８０および１９０には、列１８１および１９１の自動的に生成されるＩＤと、列１８２および１９２の支払いリポジトリまたは支払い手段が関連するアカウントの表示と、列１８３および１９３のリポジトリまたは手段のユーザ指定の名前と、支払いの預かりまたは請求金額について支払いリポジトリまたは支払い手段をどのように使用するかに関する列１８４〜１８６および１９４〜１９６の様々な情報とを含む、各リポジトリまたは手段の様々な情報が保管される。他の実施形態では、手段および／またはリポジトリのタイプに固有の形で（例えば、請求を行うためにクレジットカードに関連するユーザのフルネームを使用するが、銀行口座についてはそのような情報を使用しないこと）など、様々な他のタイプの追加情報を提供し、使用することができる。さらに、この図示の例では、ユーザは、前に述べたように、支払いリポジトリまたは支払い手段の使用に関する１以上の制限を定義することができ、そのような制限情報は、この例では列１８７〜１８８および１９７〜１９８に保管される。
【００５８】
ユーザＡＢＣは、支払いリポジトリと支払い手段（それぞれエントリ１８０ａおよび１９０ａに対応する）の両方として単一の銀行口座を使用するが、この例では、銀行口座は、これらの使用のそれぞれについて別個のＩＤを与えられ（これらのエントリの列１８１および１９１に示されているように）、しかし、他の実施形態では、単一のＩＤをその代わりに使用することができる。さらに、この図には示されていないが、他の状況で、単一の支払いソースまたは宛先の異なる使用に伴う異なる制限または他の条件を定義するためなど、単一の支払いソースまたは宛先（例えば、銀行口座）を、複数の定義された支払いリポジトリおよび／または複数の定義された支払い手段と共に使用することができる。さらに、この例では、ユーザＣＤＥは、まだユーザ指定の支払いリポジトリまたはユーザ指定の支払い手段を指定しておらず、その代わりに、支払い手段としてＰＨＳアカウントを使用することを指定している（ユーザＣＤＥは、現在、支払いをまったく受け取らないので、現在は支払いリポジトリを必要としない）。
【００５９】
図１Ｅに、様々な定義された使用法命令ルールセットに関する情報を保管する使用法命令ルールセットデータベース１６０を示す。具体的に言うと、エントリ１６０ａは、図１ＢでユーザＡＢＣによって定義された使用法命令ルールセットに対応し、エントリ１６０ｂは、図１ＣでＸＭＬ文書１３１によって定義された使用法命令ルールセットに対応する。この例では、各使用法命令ルールセットは、一意のＩＤを与えられ（列１６１に示されているように）、さらに、この使用法命令ルールセットを後に参照する際に使用するために自動的に生成された一意の参照トークンを与えられる（列１６３に示されているように）。この例では、参照トークンが長い乱数であるが、他の実施形態では、様々な他のタイプの情報を、参照トークンに使用することができ、一般に、この情報に、支払い命令ルールセットを参照するか他の形で示すことができるすべての情報を含めることができる。いくつかの実施形態において使用できる他のタイプの参照トークンの例に、デジタル証明書または他の信用証明、鍵対の公開鍵または秘密鍵（ＰＨＳが、ユーザのアカウントに関連付けることによってなど、他方の鍵にアクセスできる場合に）、および／またはこれらの鍵のうちの１つを使用して暗号化された情報（例えば、参照トークンに関連する使用法命令ルールセットのコピー、参照トークンが属するユーザに関する情報、参照トークンが使用される潜在的トランザクションに関する情報など）が含まれる。データベース１６０に、さらに、使用法命令ルールセットが関連付けられるアカウントのアカウントＩＤ（列１６２に示されているように）、名前および使用タイプ（列１６４および１６５に示されているように）、オプションの失効日（列１６７に示されているように）、および使用法命令ルールセットと共に使用される１以上のオプションの支払いリポジトリまたは支払い手段の表示（列１６６に示されているように）を含む、使用法命令ルールセットに関する様々な他の指定された情報が含まれる。
【００６０】
データベース１６０には、列１６８の、使用法命令ルールセットのルールの表示も含まれ、この表示は、この例では、これらのルールに対応するルールＩＤを用いて示されている。ルールに関する追加情報は、使用法命令ルールデータベース１７０で提供される。具体的に言うと、この例の各ルールは、関連する一意のルールＩＤ（列１７１に示されているように）およびそのルールが関連付けられる使用法命令ルールセットのＩＤの表示（列１７２に示されているように）を有する。列１７３〜１７７には、特定の状況でルールが満たされるかどうかをどのように決定するかに関する様々な情報が含まれ、様々な他のタイプの情報を、同様に、他の実施形態および状況で、異なるタイプのルールに固有の形で（例えば、ユーザ定義ルールに関する呼出し詳細を保管することによって）など、そのようなルールについて保管することができる。
【００６１】
図３に、トランザクション承認ハンドラシステムファシリティ３４０の実施形態を実行するのに適するサーバコンピューティングシステム３００ならびにウェブサービス消費者用のコンピューティングシステム３５０およびウェブサービス提供者用のコンピューティングシステム３７０を示す。サーバコンピューティングシステムには、ＣＰＵ  ３０５、様々な入出力デバイス３１０、ストレージ３２０、およびメモリ３３０が含まれる。入出力デバイスには、ディスプレイ３１１、ネットワーク接続３１２、コンピュータ可読媒体ドライブ３１３、および他の入出力デバイス３１５が含まれる。
【００６２】
トランザクション承認ハンドラシステムの一実施形態は、メモリ内で実行されつつあり、トランザクション認証コンポーネント３４１、トランザクションハンドラコンポーネント３４３、アカウント管理コンポーネント３４５、オプションの支払い集計コンポーネント３４７、およびオプションのセキュリティ管理コンポーネント３４９を含む。具体的に言うと、トランザクション承認ハンドラシステムは、潜在的なトランザクションの表示を受け取り、そのトランザクションを承認するかどうかを決定する。そのような潜在的なトランザクションには、ウェブサービス消費者システム３５０のメモリ３５７内で実行中のアプリケーションプログラム３５９とウェブサービス提供者システム３７０のメモリ３７７内で実行中のウェブサービスサーバ３７９との間のトランザクション、および／または１以上のそのようなシステム３５０および３７０と１以上の他のコンピューティングシステム３９０との間のトランザクションを含めることができる。
【００６３】
承認される潜在的なトランザクションを実行する前に、ユーザ（例えば、コンピューティングシステム３５０および３７０のユーザ）は、アカウント管理コンポーネントと対話して、ユーザアカウントを作成し、そのユーザアカウントに関する情報３２５が、ストレージ３２０に保管される。各そのようなユーザは、アカウント管理と対話して、１以上の使用法命令ルールセットも作成し、各そのような命令ルールセットに関する情報３２７が、そのユーザのアカウントに関連する形で保管される。アカウント管理は、作成されたそのような使用法命令ルールセットごとに参照トークンも作成し、その参照トークンに関する情報３２８が、使用法命令ルールセットに関連する形で保管される。作成された参照トークンが、コンピューティングシステム３５０および３７０のユーザなどのユーザに提供された後に、これらのユーザは、参照トークン３５６および３７６を、それぞれアプリケーションプログラム３５９およびウェブサービスサーバ３７９による後の使用のために、コンピューティングシステムのストレージ３５１および３７１にそれぞれ保管することができる。アカウント管理コンポーネントは、この図示の実施形態ではトランザクション承認ハンドラシステムの一部であるが、他の実施形態では、アカウント管理コンポーネント機能の一部またはすべてを、その代わりに、トランザクション承認ハンドラシステムが対話する別のシステムによって実行することができる。
【００６４】
トランザクション承認ハンドラシステム３４０が、承認決定に関する潜在的なトランザクションの表示およびそのトランザクションの関係者の複数の参照トークンを受け取るときに、トランザクション認証コンポーネントは、それらの参照トークンに対応する使用法命令ルールセットに関する保管された情報を取り出し、これらの使用法命令ルールセットが、現在の条件の下でその潜在的なトランザクションについて満たされるかどうかを決定する。そうである場合には、トランザクションハンドラコンポーネントは、料金ベースのトランザクションの関係者の間での金銭的支払い実行について手配するなど、その潜在的なトランザクションを実行しまたは他の形で処理するのを援助する。
【００６５】
いくつかの実施形態において、トランザクション承認ハンドラシステムは、さらに、オプションの支払い集計コンポーネント３４７およびオプションのセキュリティ管理コンポーネント３４９のうちの一方または両方を含むことができる。存在する場合に、支払い集計コンポーネントは、関係者のプリファレンスに基づいておよび／または他の情報を使用してなど、適宜、関係者に対して行われるおよび／または関係者から受け取られる支払いを集計することができる。セキュリティ管理コンポーネントは、存在するときに、トランザクションの関係者の識別を確認するため、参照トークンを提供するユーザの識別および／または承認を確認するため、ユーザアカウントおよび使用法命令ルールセットの作成および／または変更を試みるユーザのユーザ承認を実行するためなど、様々なタイプの追加のセキュリティ関連検証を実行することができる。
【００６６】
トランザクション承認ハンドラシステムの機能には、異なる実施形態で様々な形でアクセスすることができる。例えば、一部のユーザは、サーバコンピューティングシステムへの物理的アクセスを有することができ、その場合に、様々な入出力デバイス３１０と対話して、情報を提供し、および／または受け取ることができる。その代わりに、他のユーザは、クライアントコンピュータシステムを使用して、ネットワーク３８０を介してリモートに（例えば、インターネットおよび／またはワールドワイドウェブを介して）など、このシステムに直接にアクセスすることができる。そのようなユーザは、メモリ３６０内で実行されるブラウザ（図示せず）など、そのクライアントコンピュータシステム上で提供されるソフトウェアまたは他の機能を使用して、トランザクション承認ハンドラシステムと対話することができる。他の実施形態では、ユーザは、その代わりに、１以上の他のコンピュータとの対話を介して間接的にトランザクション承認ハンドラシステムから機能および／または情報を受け取ることができ、この１以上の他のコンピュータは、その機能または情報をユーザに提供する前に、トランザクション承認ハンドラシステムからその機能または情報を直接に受け取ることができる。さらに、トランザクション承認ハンドラシステムコンポーネントの一部またはすべてが、様々なフィードバックまたは他の一般的なタイプの情報をユーザに（例えば、ユーザ要求に応答して）提供することができ、この情報を、サーバシステムのディスプレイ３１１上またはクライアントシステム上の入出力デバイス３５４または３７４のうちの１つの上でユーザに提示することができる。
【００６７】
当業者は、コンピューティングシステム３００、３５０、および３７０が、単に例示的であり、本発明の範囲を限定することを意図されていないことを理解するであろう。コンピューティングシステム３００を、インターネットなどの１以上のネットワークを介してまたはワールドワイドウェブ（「ウェブ」）を介してを含めて、図示されていない他のデバイスに接続することができる。より一般的に、「クライアント」デバイスまたは「サーバ」デバイスには、コンピュータ、ネットワークデバイス、インターネットアプライアンス、ＰＤＡ、無線電話機、セル電話機、ポケットベル、電子オーガナイザ、テレビジョンベースのシステム、および相互通信機能を含む様々な他の消費者製品を含む、対話できるハードウェアまたはソフトウェアのすべての組合せを含めることができる。例えば、コンピューティングシステム３５０のうちの１つを、セル電話機、無線ＰＤＡ、または他のポータブルデバイスとすることができ、その電話機／ＰＤＡ／デバイスのユーザは、１以上の提供者コンピューティングシステム３７０とのトランザクションの処理など、トランザクションハンドラシステム３４０の機能を使用することをもたらす１以上の選択を行うことができる。さらに、図示のトランザクション承認ハンドラシステムコンポーネントによって提供される機能は、いくつかの実施形態において、より少数のコンポーネントに組み合わせるか、追加コンポーネントに分散させることができる。同様に、いくつかの実施形態において、図示のコンポーネントの一部の機能を、提供しないものとすることができ、および／または、他の追加の機能を利用可能にすることができる。
【００６８】
当業者は、様々なアイテムが、使用されている間にメモリ内またはストレージ上に保管されるものとして図示されているが、これらのアイテムまたはその一部を、メモリ管理およびデータ保全性のためにメモリと他のストレージデバイスとの間で転送できることも理解するであろう。その代わりに、他の実施形態で、ソフトウェアモジュールおよび／またはコンポーネントの一部またはすべてが、別のデバイスのメモリ内で実行し、コンピュータ間通信を介して図示のコンピューティングデバイスと通信することができる。トランザクション承認ハンドラシステムコンポーネントまたはデータ構造の一部またはすべてを、ハードディスク、メモリ、ネットワーク、または適当なドライブによって読み取られるポータブル物品などのコンピュータ可読媒体に保管することもできる（例えば、命令または構造化データとして）。トランザクション承認ハンドラシステムコンポーネントおよびデータ構造を、無線ベース媒体および有線／ケーブルベース媒体を含む様々なコンピュータ可読伝送媒体上で、生成されたデータ信号として（例えば、搬送波の一部として）伝送することもできる。したがって、本発明を、他のコンピュータシステム構成と共に実践することができる。
【００６９】
図４は、ユーザアカウント管理ルーチン４００の実施形態の流れ図である。このルーチンは、ユーザが、アカウントと共に使用される使用法命令ルールセットを定義することを含めて、トランザクション承認およびハンドラシステムと共に使用されるアカウントを作成し、変更することを可能にする。いくつかの実施形態においては、このルーチンを、ユーザが対話できる対話型ユーザインターフェースの一部として（例えば、ウェブサイトの１以上のウェブページの一部として）実施することができ、他の実施形態では、このルーチンを、その代わりに、ユーザの代わりの１以上のプログラム的呼出しに応答して実行することができる（例えば、ユーザの代わりにアクセスされる１以上のウェブサービスの一部として）。
【００７０】
このルーチンは、ステップ４０５で開始され、ここで、アカウントに関連する指示を受け取る。ステップ４１０で、このルーチンは、その指示がアカウントの作成に関連するかどうかを決定し、そうである場合には、ステップ４１５に継続して、アカウントの定義に関連する様々な情報を受け取る。例えば、いくつかの実施形態において、ユーザは、アカウント名、アカウントパスワードまたは他のセキュリティアクセスメカニズム、そのアカウントと共に使用される１以上の支払い手段の表示、そのアカウントと共に使用される１以上の支払いリポジトリの表示などを提供することができる。次に、このルーチンは、ステップ４２０で継続して、いくつかの実施形態においては一意のアカウントＩＤ、請求金額を含むことのできる支払い手段としてアカウントを使用できる場合にユーザについて許容される最高差引勘定など、アカウントの使用に関連する追加情報を自動的に生成する。ステップ４２５で、このルーチンは、受け取られたおよび生成されたアカウント情報を使用してアカウントを作成し、ステップ４３０で、アカウントの作成者に新しいアカウントの参照を提供する（例えば、アカウントＩＤの表示）。
【００７１】
ステップ４１０で、その代わりに、受け取られた指示がアカウントの作成に関連しないと決定された場合には、このルーチンは、ステップ４３５に継続して、アカウントの変更に関連する情報を受け取り、ステップ４４０で、適当である場合に、示された通りにアカウントを変更する。ステップ４４５で、このルーチンは、アカウント変更に、使用法命令ルールセットの作成または変更が含まれたかどうかを決定する。そうである場合には、このルーチンは、ステップ４５０で継続して、命令ルールセットへの後の参照を可能にするために、使用法命令ルールセットに関連する一意の参照トークンを生成する。ステップ４５５で、このルーチンは、使用法命令ルールセットを参照するのに後に使用される参照トークンの表示をアカウント所有者に提供する。ステップ４３０または４５５の後に、またはその代わりに、ステップ４４５でアカウント指示が使用法命令ルールセットの作成または変更に関連しないと決定された場合に、このルーチンは、ステップ４６０で継続して、現在のアカウントに対する変更を行い続けるかどうかを決定する。そうである場合には、このルーチンはステップ４３５に戻り、そうでない場合には、このルーチンはステップ４９９に継続し、終了する。
【００７２】
この図には示されていないが、他の実施形態で、アカウントに関する情報を提供することによって、ユーザがアカウントを再検討できるようにするなど、ユーザアカウントに関連する追加の機能を提供することができる。さらに、いくつかの実施形態において、追加のセキュリティ制御を使用して、アカウントの作成および／または変更を試みるユーザが、それを行うことを承認されることを保証することができる。さらに、いくつかの実施形態において、ユーザアカウントを、トランザクション承認および処理機能を提供するシステムと別個の会社または他の実体に関連付けることができる。
【００７３】
図５は、トランザクション承認およびハンドラルーチン５００の実施形態の流れ図である。このルーチンは、承認されるか他の形で処理されるトランザクションの表示と、そのトランザクションの複数の関係者からの使用法命令ルールセットに対応する参照トークンの表示とを受け取り、使用法命令ルールセットに互換性があるときにそのトランザクションを承認すると決定する。いくつかの実施形態において、このルーチンは、１以上のウェブサービスを介するなど、プログラム的に呼び出されるが、他の実施形態では、このルーチンを、その代わりに他の形で（例えば、グラフィカルユーザインターフェースを介して対話的に）呼び出すことができる。
【００７４】
このルーチンは、ステップ５０５で開始され、ここで、複数関係者トランザクションの表示および複数の関係者のそれぞれの参照トークン（例えば、トランザクションの複数の関係者ごとに１つ）の表示を受け取る。次に、このルーチンは、ステップ５１０に継続して、トークンに対応する使用法命令ルールセットを取り出し、いくつかの実施形態において、さらに、これらの使用法命令ルールセットの一部またはすべてが属するユーザアカウントからの他の情報を取り出すか、他の形で利用可能にすることができる。
【００７５】
このルーチンは、次に、ステップ５１５に継続して、関係者によって提供される追加のセキュリティ情報に基づくなど、関係者がトークンを使用することを承認されるかどうかを決定するためにセキュリティ検証を実行するかどうかを決定する。そうである場合には、このルーチンは、ステップ５２０に継続して、トークンを使用するための関係者の承認を示すセキュリティ情報を取得し、検証することを試み、ステップ５２５で、そのような承認が検証されたかどうかを決定する。他の実施形態では、その代わりに、トークン自体の命令ルールセットの使用にその使用法命令ルールセットの使用が承認されるときを制御するルールまたは他の制限が含まれるときなど、そのようなトークンを使用するためのそのようなセキュリティ承認または他のアクセス承認を、実行しないものとすることができる。
【００７６】
ステップ５２５で、トークン使用承認が検証されると決定された場合に、または、ステップ５１５で、セキュリティ検証を実行しないと決定された場合に、このルーチンは、サブルーチン５３０の実行に継続して、図６に関してより詳細に述べるように、取り出された使用法命令ルールセットに基づいてトランザクションを妥当性検査する。ステップ５３５で、トランザクションが妥当性検査されると決定される場合には、このルーチンは、サブルーチン５４５の実行に継続して、図７Ａおよび７Ｂに関してより詳細に述べるように、トランザクションのタイプに固有の形でなど、示されたトランザクションの実行を試みる（例えば、料金ベースのトランザクションに関する金銭的支払いを行うために）。他の実施形態では、このルーチンは、その代わりに、トランザクションが承認されるかどうかを単に決定し、トランザクションの実行は他に委ねることができる。
【００７７】
ステップ５４５の後に、ステップ５５０で、示されたトランザクションの実行に成功したと決定される場合には、このルーチンは、ステップ５５５に進んで、ルーチン５００がウェブサービスの一部として呼び出された場合に応答ＸＭＬ文書内でなど、成功の表示を返す。その代わりに、ステップ５２５で、使用承認が検証されないと決定された場合、または、ステップ５３５で、トランザクションが妥当性検査されないと決定された場合、または、ステップ５５０で、トランザクション実行が成功しないと決定された場合には、このルーチンは、その代わりにステップ５４０に継続して、このルーチンがウェブサービスの一部として呼び出された場合に応答として送られるＸＭＬ文書としてなど、エラーメッセージを返す。ステップ５４０または５５５の後に、このルーチンは、ステップ５９９に継続し、終了する。
【００７８】
図６は、トランザクション妥当性検査サブルーチン５３０の実施形態の流れ図である。このサブルーチンは、トランザクションの表示およびそのトランザクションの関係者によって指定された複数の使用法命令ルールセットの表示を受け取り、それらのルールおよび使用法命令ルールセットの他の情報に基づいて、そのトランザクションが妥当性検査されるかどうかを決定する。
【００７９】
このサブルーチンは、ステップ６０５で開始され、ここで、トランザクションの表示および複数の使用法命令ルールセットの表示を受け取る。ステップ６１０で、その使用法命令ルールセットを使用できるトランザクションに関連する判断基準を指定する各ルールおよび／またはその使用法命令ルールセットを使用できるトランザクションの関係者に関する情報を指示する各ルールを選択し、それらのルールが満たされるかどうかを決定するために、そのトランザクションおよび／またはこれらの他の関係者に関する情報を取り出す。例えば、トランザクションの別の関係者に関する情報を取得するために、その、他の関係者に関連するユーザアカウント（例えば、その、他の関係者からのトークンの使用法命令ルールセットが関連付けられたユーザアカウント）からの情報、ならびに他の形で（例えば、ウェブサービス呼出しの一部として使用されたＨＴＴＰヘッダからなど、トランザクション処理ルーチンに関する呼出し要求に基づいて）アクセス可能とすることができる他の関係者に関する情報を、取得することができる。同様に、トランザクションに関する情報を、ルーチン呼出しの一部として（例えば、トランザクションオブジェクトまたはトランザクションについて提供される文書の一部として）受け取られる情報に基づいて、またはその代わりに外部ソースから、取得可能とすることができる。
【００８０】
ステップ６１０の後に、このサブルーチンは、ステップ６１５で継続して、ユーザ定義ルールではない、許容できるトランザクションに関連する他の条件を指定する、他の指定されたルールを識別し、すべてのそのような指定されたルールが、他の指定された使用法命令ルールセットからのルールおよび／またはトランザクション自体と互換性があるかどうかを決定する。次に、このサブルーチンは、ステップ６２０で継続し、すべてのユーザ定義ルールを、そのルールについて指定された形で呼び出し、これらのルールが満たされるかどうかを示す応答を取得する。ステップ６２０の後に、このサブルーチンは、ステップ６３０に継続して、指定された使用法命令ルールセットのルールのすべてが満たされたかどうかを決定する。そうである場合には、このサブルーチンは、ステップ６４０に継続し、トランザクションが妥当性検査されることの表示を返し、そうでない場合には、その代わりにステップ６３５に継続して、トランザクションが妥当性検査されないことの表示を返す。ステップ６３５または６４０の後に、このサブルーチンは、ステップ６９９に継続し、終了する。
【００８１】
他の実施形態では、トランザクション妥当性検査を、その代わりに、様々なタイプのルールを異なる順序で評価することによっておよび／またはいずれかのルールが満たされないとわかった場合にさらなるルール評価を停止することによってなど、他の形で実行することができる。その代わりに、他の実施形態で、トランザクションが妥当性検査されるかどうかの決定を、使用法命令ルールセット自体がこれらのルールセットのルールの間の他のタイプの相互関係を示す場合におよび／または他の既定の判断基準（例えば、パーセンテージの最小閾値または満たされなければならない指定されたルールのサブセット）に基づいてなど、すべての指定されたルールのすべての満たすことを要求すること以外の形で実行することができる。
【００８２】
図７Ａおよび７Ｂは、支払い実行処理トランザクションサブルーチン５４５の実施形態の流れ図である。このサブルーチンは、あるタイプのトランザクションについて実行できる処理の１タイプの例であり、この場合には、トランザクションの少なくとも１つの部分がトランザクションの少なくとも１つの他の関係者に支払いを与えることである、支払い処理トランザクションである。
【００８３】
このサブルーチンは、ステップ７０５で開始され、ここで、支払いトランザクションの表示（例えば、支払額の表示およびおそらくは他の支払い関連条件の表示）ならびに少なくとも１つの支払い提供者および少なくとも１つの支払い受取人のそれぞれの参照トークンの表示を受け取る。ステップ７１０で、このサブルーチンは、支払い提供者ごとに、その支払い提供者によって提供されたトークンに対応する使用法命令ルールセットに関連する支払い手段に基づくなど、使用される支払い手段およびその支払い手段に関するすべての定義された支払い制限を決定する。同様に、ステップ７１５で、このサブルーチンは、支払い受取人ごとに使用される支払いリポジトリおよびすべての定義された支払い制限を決定する。ステップ７２０で、このサブルーチンは、最低現在請求金額、最高現在請求金額、最低累積差引勘定、最高累積差引勘定などに基づくなど、トランザクションによって示される１以上の支払いが、支払い手段および／または支払いリポジトリに関するすべての定義された支払い制限を満たすかどうかを決定する。
【００８４】
ステップ７２０の後に、このサブルーチンは、ステップ７２５に継続して、支払いがすべての定義された支払い制限を満たすかどうかを決定し、そうである場合には、ステップ７３５に継続して、そのような支払いごとに、請求金額について支払い手段に別々に請求書を送るか、あるいはその代わりに、周期的な基礎で（例えば毎月）または最低累積請求金額に達するまでなど、他の支払いと一緒にこの支払いを集計するかどうかを決定する。支払いの請求金額を集計しないと決定された場合には、このサブルーチンは、ステップ７４０に継続して、その支払いに関して対応する支払い手段に即座に請求するが、その代わりに、ステップ７３５で請求金額を集計すると決定された場合には、このサブルーチンは、ステップ７４５に継続して、その支払い手段に関する後の集計された請求のために請求金額の表示を保管する。図示されてはいないが、ステップ７３５〜７４５は、複数の支払いを行わなければならない場合に、トランザクションの支払いごとに複数回繰り返すことができる。
【００８５】
ステップ７４０または７４５の後に、このサブルーチンは、ステップ７５０で継続して、各支払いを対応する支払いリポジトリに直接に預けるか、あるいはその代わりに、集計支払いを預ける前に他の支払いと一緒に支払いを集計するかを決定する。支払いを集計しないと決定される場合には、このサブルーチンは、ステップ７５５に継続して、各そのような支払いを適当な支払いリポジトリに即座に預けるが、その代わりに、ステップ７５０で支払いを集計すると決定される場合には、このサブルーチンは、その代わりにステップ７６０に継続して、適当な支払いリポジトリへの後の集計された預金のために支払いの表示を保管する。この図には示されていないが、ステップ７５０〜７６０を、トランザクションについて行われる支払いごとに実行することができる。
【００８６】
ステップ７５５または７６０の後に、このサブルーチンは、ステップ７６５に継続して、支払いが成功したことの表示を返す。その代わりに、ステップ７２５で、トランザクションによって示される支払いが、１以上の定義された支払い制限を満たさないと決定された場合には、このサブルーチンは、その代わりに、ステップ７３０に継続して、支払いが成功しなかったことの表示を返す。いくつかの実施形態において、支払いおよび／または預金を集計する能力は、複数の支払いまたは預金が最低額制限を満たせるようにするためなど、いずれかの定義された支払い制限が満たされるかどうかを決定するときに考慮されるが、他の実施形態では、各そのような支払いが、個別に考慮される。その代わりに、他の実施形態では、支払い預金集計および／または支払い請求金額集計を実行しないものとすることができる。ステップ７３０または７６５の後に、このサブルーチンは、ステップ７９９に継続し、終了する。
【００８７】
当業者は、いくつかの実施形態において、上で述べたルーチンによって提供される機能を、より多数のルーチンの間で分割する、またはより少数のルーチンに合併するなど、代替の形で提供できることも理解するであろう。同様に、いくつかの実施形態において、示されたルーチンは、他の図示のルーチンがその代わりにそれぞれそのような機能を欠くか含むときまたは提供される機能の量が変更されるときなど、説明したものより多数またはより少数の機能を提供することができる。さらに、様々な動作を、特定の形で（例えば、直列にまたは並列に）および／または特定の順序で実行されるものとして示す場合があるが、当業者は、他の実施形態で、これらの動作を異なる順序でおよび異なる形で実行できることを理解するであろう。当業者は、単一のデータ構造を複数のデータ構造に分割させることによって、または複数のデータ構造を単一のデータ構造に合併させることによってなど、上で述べたデータ構造を異なる形で構成できることも理解するであろう。同様に、いくつかの実施形態において、他の図示のデータ構造がその代わりにそれぞれそのような情報を欠くか含むときまたは保管される情報の量もしくはタイプが変更されるときなど、図示のデータ構造が、説明されたものより多数またはより少数の情報を保管することができる。
【００８８】
次は、使用法命令ルールセットおよび使用法命令ルールセットのルールを定義し、使用する技術の例示的例を提供するが、本発明がこれらの詳細に限定されることは意図されていない。
【００８９】
特定の支払いの送り手または受取人にトランザクションを制限する例は、次の通りである。
【００９０】
承認される受取人トークン
【００９１】
【表１】
2008507064.tif 000003
【００９２】
受取人のトークンが、ｔｏｋｅｎ１と正確に一致する場合に、そのトランザクションは承認される。このルールは、すべての関係者（送り手、受取人、呼出し側）から利用可能である。複数の承認される受取人トークンの指定の例に、次が含まれる。
【００９３】
【表２】
2008507064.tif 000004
【００９４】
ブロックされる送り手トークン
【００９５】
【表３】
2008507064.tif 000005
【００９６】
このトランザクションは、送り手のトークンがｔｏｋｅｎ１と一致する場合には承認されない。このルールは、すべての関係者（送り手、受取人、呼出し側）から利用可能である。複数のブロックされる受取人トークンの指定の例に、次が含まれる。
【００９７】
【表４】
2008507064.tif 000006
【００９８】
秘密作成ハンドシェークの例は、次の通りである。
【００９９】
これは、送り手と受取人がある条件に合意するために秘密ハンドシェークを交換する例である。両方の関係者がこの定義されるルールに似たルールを有しない場合には、トランザクションは承認されない。
【０１００】
送り手の秘密
【０１０１】
【表５】
2008507064.tif 000007
【０１０２】
秘密ハンドシェークルールについて、送り手および受取人が同一の値を定義しない場合に、トランザクションは承認されない。任意のストリングを‘ｒｕｍｐｌｅｓｔｉｌｓｋｉｎ’の代わりに使用することができ、既定の参照でない限り、任意の参照名をＳｈａｒｅｄＳｅｃｒｅｔＳｅｎｄｅｒおよびＳｈａｒｅｄＳｅｃｒｅｔＲｅｃｉｐｉｅｎｔの代わりに使用することができる。
【０１０３】
受取人の秘密
【０１０４】
【表６】
2008507064.tif 000008
【０１０５】
秘密ハンドシェークルールについて、送り手および受取人が同一の値を定義しない場合に、トランザクションは承認されない。任意のストリングを‘ｒｕｍｐｌｅｓｔｉｌｓｋｉｎ’の代わりに使用することができ、既定の参照でない限り、任意の参照名をＳｈａｒｅｄＳｅｃｒｅｔＳｅｎｄｅｒおよびＳｈａｒｅｄＳｅｃｒｅｔＲｅｃｉｐｉｅｎｔの代わりに使用することができる。
【０１０６】
使用制限付き参照トークンを作成する例は、次の通りである。
【０１０７】
支払い命令ルールセットは、支払いを行うのにトークンを使用できる回数、トークンを使用できる総額、またはトークンの失効日を制限することができる。これらのルールは、そのトークンの使用法だけに適用され、したがって、送り手の支払い命令ルールセットは、送り手のトークンの使用法しか制限することができない。同様に、同一のことが、呼出し側および受取人にあてはまる。
【０１０８】
使い捨てトークン
【０１０９】
【表７】
2008507064.tif 000009
【０１１０】
このルールは、トークンが１回使用された後に、そのトークンが働くのをやめさせる。このルールは、それ自体の支払い命令ルールセットだけに適用され、したがって、送り手の命令ルールセットは、その使用法を制限することしかできない。
【０１１１】
使用回数を制限する
【０１１２】
【表８】
2008507064.tif 000010
【０１１３】
このルールは、トークンが５回使用された後に、そのトークンが働くのをやめさせる。
【０１１４】
総額を制限する
【０１１５】
【表９】
2008507064.tif 000011
【０１１６】
失効日
【０１１７】
【表１０】
2008507064.tif 000012
【０１１８】
このルールは、２００５年１月３０日にトークンが働くのをやめさせる。この日の深夜（グリニッジ標準時００：００）から以降に、このトークンを使用するすべてのトランザクションは承認されない。
【０１１９】
受取人としてのみ使用する
【０１２０】
【表１１】
2008507064.tif 000013
【０１２１】
このルールは、このトークンが受取人のトークンとして使用されない限り、このトークンに支払いを承認させなくする。
【０１２２】
呼出し側としてのみ使用する
【０１２３】
【表１２】
2008507064.tif 000014
【０１２４】
このルールは、このトークンが呼出し側のトークンとして使用されない限り、このトークンに支払いを承認させなくする。
【０１２５】
受取人としてのみ使用する
【０１２６】
【表１３】
2008507064.tif 000015
【０１２７】
このルールは、このトークンが送り手のトークンとして使用されない限り、このトークンに支払いを承認させなくする。
【０１２８】
トランザクションの額の制限の例は、次の通りである。
【０１２９】
トランザクション額制限ルールは、すべての関係者から利用可能である。
【０１３０】
最高トランザクション額
【０１３１】
【表１４】
2008507064.tif 000016
【０１３２】
最低トランザクション額
【０１３３】
【表１５】
2008507064.tif 000017
【０１３４】
このルールは、トランザクション額を１米国ドル以上に制限する。トランザクションがこの額未満である場合には、このルールは、そのトランザクションを承認しない。
【０１３５】
トランザクション通貨を制限する
【０１３６】
【表１６】
2008507064.tif 000018
【０１３７】
このルールは、トランザクション通貨を日本円に制限する。トランザクション通貨が日本円でない場合には、そのトランザクションは承認されない。
【０１３８】
支払い提供者／送り手が支払い詳細を指定する例は、次の通りである。
【０１３９】
送り手は、支払いがクレジットカード、ＡＣＨ銀行口座、または既存勘定残高のどれから行われるかなど、支払い方法を指定する。
【０１４０】
残高繰越し
【０１４１】
【表１７】
2008507064.tif 000019
【０１４２】
このルールは、資金が既存勘定残高からとられることを指定する。
【０１４３】
デフォルトＡＣＨ銀行口座
【０１４４】
【表１８】
2008507064.tif 000020
【０１４５】
このルールは、アカウントのデフォルトＡＣＨ銀行口座が使用されることを指定する。デフォルトＡＣＨ口座は、ＣｒａｔｅＡｃｃｏｕｎｔメッセージまたはＳｅｔＤｅｆａｕｌｔＦｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔメッセージを介するなど、様々な形で指定することができる。
【０１４６】
特定のＡＣＨ銀行口座
【０１４７】
【表１９】
2008507064.tif 000021
【０１４８】
このルールは、ｆｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔＲｅｆｅｒｅｎｃｅによって参照される特定のＡＣＨ銀行口座を指定する。金銭の手段参照が、ｉｎｓｔａｌｌＡＣＨＢａｎｋＡｃｃｏｕｎｔメッセージから返される。この例では、金銭の手段参照は、銀行口座番号ではなく、銀行口座番号は、いくつかの実施形態において、プライバシの理由から支払い命令ルールセットに含まれない場合がある。ＰａｙｍｅｎｔＭｅｔｈｏｄは、他の支払い命令ルールセットでそれに反するアサーションを行うことを可能にするように指定されなければならない。
【０１４９】
デフォルトクレジットカード
【０１５０】
【表２０】
2008507064.tif 000022
【０１５１】
このルールは、アカウントのデフォルトクレジットカードが使用されることを指定する。デフォルトクレジットカードは、ＣｒａｔｅＡｃｃｏｕｎｔメッセージまたはＳｅｔＤｅｆａｕｌｔＦｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔメッセージを介するなど、様々な形で指定することができる。
【０１５２】
特定のクレジットカード
【０１５３】
【表２１】
2008507064.tif 000023
【０１５４】
このルールは、ｆｉｎａｎｃｉａｌＩｎｓｔｒｕｍｅｎｔＲｅｆｅｒｅｎｃｅによって参照される特定のクレジットカード銀行口座を指定する。支払い手段参照が、ｉｎｓｔａｌｌＣｒｅｄｉｔＣａｒｄメッセージから返される。この例では、金銭の手段参照は、クレジットカード番号ではなく、クレジットカード番号は、いくつかの実施形態において、プライバシの理由から支払い命令ルールセットに含まれない場合がある。ＰａｙｍｅｎｔＭｅｔｈｏｄは、他の支払い命令ルールセットでそれに反するアサーションを行うことを可能にするように指定されなければならない。
【０１５５】
支払い受取人が論争解決ポリシを指定する例は、次の通りである。
【０１５６】
論争解決は、送り手が特定のトランザクションに関する論争を登録するときに行われる可能性がある。受取人の支払い命令ルールセットによって指定される場合に、論争を解決するために、自動払戻しが受取人から送り手に発行される。論争は、送り手によって開始され、受取人によって指定された論争解決ポリシによって決定される。この例の実施形態では、通常の払戻しは、論争されず、受取人がいつでも要求することができ、これらのルールによって指定される論争解決ポリシと無関係に必ず成功する。
【０１５７】
「送り手が勝つ」期限
【０１５８】
【表２２】
2008507064.tif 000024
【０１５９】
このルールは、送り手がトランザクションから１５日以内に論争を登録した場合に、自動払戻しが発行されることを指定する。
【０１６０】
自動払戻しなし
【０１６１】
【表２３】
2008507064.tif 000025
【０１６２】
このルールは、送り手が論争を登録する場合に発行される自動払戻しがないことを指定する。
【０１６３】
「送り手が勝つ」払戻しの分数またはパーセンテージの限度
【０１６４】
【表２４】
2008507064.tif 000026
【０１６５】
このルールは、トランザクション額の５０％だけが、論争を解決するために払い戻されることを指定する。
【０１６６】
呼出し側／エンドユーザまたは支払い受取人が支払い方法を制限する例は、次の通りである。
【０１６７】
呼出し側および／または受取人は、資金がどこから来るかに関する制限を設けることができる。例えば、呼出し側がトランザクション料金について支払おうとしている場合に、その呼出し側は、クレジットカードトランザクション料金が他の方法より高価なので、支払いのソースが「クレジットカード」ではないことを確かめることを望む場合がある。
【０１６８】
残高繰越のみ
【０１６９】
【表２５】
2008507064.tif 000027
【０１７０】
このルールは、支払い方法が残高繰越でない場合にトランザクションを承認しない。
【０１７１】
残高繰越およびＡＣＨのみ
【０１７２】
【表２６】
2008507064.tif 000028
【０１７３】
このルールは、支払い方法が残高繰越でもＡＣＨでもない場合にトランザクションを承認しない。
【０１７４】
クレジットカード以外
【０１７５】
【表２７】
2008507064.tif 000029
【０１７６】
このルールは、支払い方法がクレジットカードである場合にトランザクションを承認しない。
【０１７７】
支払われる料金の分数の制限の例は、次の通りである。
【０１７８】
料金パーセンテージは、呼出し側によってＰａｙメッセージに渡される。すべての関係者が、これらのルールを使用することができる。
【０１７９】
送り手の総料金の分数を制限する
【０１８０】
【表２８】
2008507064.tif 000030
【０１８１】
このルールは、送り手が、支払われる総料金の５０％を超えて支払おうとしている場合に、トランザクションを承認しない。
【０１８２】
受取人の総料金の分数を制限する
【０１８３】
【表２９】
2008507064.tif 000031
【０１８４】
このルールは、受取人が、支払われる総料金の８０％を超えて支払おうとしている場合に、トランザクションを承認しない。
【０１８５】
呼出し側の総料金の分数を制限する
【０１８６】
【表３０】
2008507064.tif 000032
【０１８７】
このルールは、受取人が、支払われる総料金の１／３を超えて支払おうとしている場合に、トランザクションを承認しない。
【０１８８】
支払い命令ルールセットに利用可能であり、支払い要求メッセージ（例えば、呼出し側からトランザクション承認者への）の一部としてＸＭＬ文書として送ることができるコンテキストデータの例は、次の通りである。
【０１８９】
【表３１】
2008507064.tif 000033
【０１９０】
トークンに利用可能なコンテキストデータの例は、次の通りである。
【０１９１】
【表３２】
2008507064.tif 000034
【０１９２】
トランザクションに関する支払いを承認するのに支払い命令ルールセットを使用する例は、次の通りである。
【０１９３】
この例では、トランザクションに、呼出し側関係者が送り手関係者によって提供されるアプリケーションプログラムを使用する受取人関係者にウェブサービスを要求することが含まれる。呼出し側は、トランザクション承認者によって請求される、要求されるサービスに関連する料金を支払おうとしており、送り手は、トランザクションのコストを支払おうとしており、トランザクション額は、５０．００米国ドルである。第三者トランザクション承認者へのトランザクション承認呼出しの一部として渡されるパラメータの値は、次の通りである。
【０１９４】
・  ＣａｌｌｅｒＦｒａｃｔｉｏｎＯｆＦｅｅｓ：＝１００％
・  ＳｅｎｄｅｒＦｒａｃｔｉｏｎＯｆＦｅｅｓ：＝０％
・  ＲｅｃｉｐｉｅｎｔＦｒａｃｔｉｏｎＯｆＦｅｅｓ：＝０％
・  ＴｒａｎｓａｃｔｉｏｎＡｍｏｕｎｔ：＝ＵＳＤ５０．００
すべてのオプションのパラメータは、トランザクションと共に保存されるが、トランザクションの実行には影響しない。
【０１９５】
データ取出しおよびアカウント検証
トランザクション承認者は、呼出し側、受取人、および送り手のトークンを含むトランザクション承認呼出しを呼出し側から受け取り、これらのトークンに関連するデータを取り出す。取り出されるデータは、次の通りである。
【０１９６】
・  対応するトークンによって識別される、関係者のそれぞれのアカウント情報、すなわち、
・  アカウントＩＤ
・  状況（アクティブ、クローズド、一時停止）
・  差引勘定
・  利用可能な差引勘定
トランザクション承認者は、様々な関係者のアカウントが存在し、すべてがアクティブであることを検証する。アカウントのいずれかが非アクティブである場合には、トランザクションは承認されず、エラーが返される。そうでない場合には、トランザクション承認者は、継続して、支払い命令ルールセットに関連する次のデータを取り出す。
【０１９７】
・  トークンによる、関係者のそれぞれの支払い命令ルールセットおよび統計、すなわち、
・  支払い指示ルール
・  使用量総カウント：これまでにそのトークンによって承認されたトランザクションの個数
・  使用量総額：これまでにそのトークンによって承認されたトランザクション額（絶対値）の合計
・  料金、デフォルト、および承認される値を指定するための、トランザクション承認者自体の支払い指示ルール。
【０１９８】
指示セットを、トークン役割のそれぞれについて下に示し、その後、説明する。
【０１９９】
送り手：
【０２００】
【表３３】
2008507064.tif 000035
【０２０１】
受取人：
【０２０２】
【表３４】
2008507064.tif 000036
【０２０３】
呼出し側：
【０２０４】
【表３５】
2008507064.tif 000037
【０２０５】
トランザクション承認者：
【０２０６】
【表３６】
2008507064.tif 000038
【０２０７】
トランザクション承認者は、取り出されたデータを、承認呼出し内の支払い要求メッセージで受け取られたデータとマージし、様々な関係者の支払い命令ルールセットを評価する。
【０２０８】
支払い命令ルールセットを評価する
次では、評価を述べ、様々な支払い指示ルールの間の対話を示す。ここで提示される支払い命令ルールセットのすべてが、合意に達する。
【０２０９】
送り手：
【０２１０】
【表３７】
2008507064.tif 000039
【０２１１】
送り手は、各トランザクションの額を５０ドルまでに制限しようとしている。これは、トークンの総使用回数を制限しない（次のアイテムを参照されたい）。
【０２１２】
送り手：
【０２１３】
【表３８】
2008507064.tif 000040
【０２１４】
送り手は、トークンの使用量を合計１０回または合計７５ドルのうちの最初に達した方に制限しようとしている。
【０２１５】
送り手：
【０２１６】
【表３９】
2008507064.tif 000041
【０２１７】
受取人：
【０２１８】
【表４０】
2008507064.tif 000042
【０２１９】
送り手のトークンは、２００４年６月１日まで使用することだけができ、受取人のトークンは、２００４年１０月１日まで使用することだけができる。
【０２２０】
送り手：
【０２２１】
【表４１】
2008507064.tif 000043
【０２２２】
受取人：
【０２２３】
【表４２】
2008507064.tif 000044
【０２２４】
送り手は、すべての料金を支払わないことをアサートする。受取人は、呼出し側がすべての料金を支払うというより厳格な要件を有する。
【０２２５】
送り手：
【０２２６】
【表４３】
2008507064.tif 000045
【０２２７】
呼出し側：
【０２２８】
【表４４】
2008507064.tif 000046
【０２２９】
トランザクション承認者：
【０２３０】
【表４５】
2008507064.tif 000047
【０２３１】
送り手は、支払い方法にＡＣＨをセットしようとしているが、これは、資金が、トランザクション承認者の送り手のアカウントに関連するデフォルトＡＣＨ銀行口座から引き出されることを意味する。呼出し側は、料金の１００％を支払おうとしているので、呼出し側は、呼出し側のコストを低く保つために、支払い方法がＡＣＨまたは残高繰越のいずれかでなければならないことのアサーションを行う。トランザクション承認者の支払い命令ルールセットは、ＰａｙｍｅｎｔＭｅｔｈｏｄがセットされていることを確かめ、その値を制限する。
【０２３２】
受取人：
【０２３３】
【表４６】
2008507064.tif 000048
【０２３４】
送り手：
【０２３５】
【表４７】
2008507064.tif 000049
【０２３６】
受取人は、送り手がトランザクション日付の後１０日までの間に１００％の払戻しを受け取ることを可能にする論争解決ポリシを指定する。送り手は、受取人がトランザクション日付の後少なくとも１０日の間に９０％以上の払戻しに合意する論争解決ポリシを指定しない限り、支払いを拒否する。この送り手および受取人は、意見が一致している。
【０２３７】
トランザクションを実行する
支払い命令ルールセットの評価から、次の変数がわかる。
【０２３８】
・  ＰａｙｍｅｎｔＭｅｔｈｏｄ：＝‘ａｃｈ’
・  ＳｅｎｄｅｒＷｉｎｓＴｉｍｅＬｉｍｉｔ：＝１０ｄａｙｓ
・  ＳｅｎｄｅｒＷｉｎｓｔＦｒａｃｔｉｏｎＬｉｍｉｔ：＝１００％
トランザクション承認者は、主トランザクションの資金の提供源として使用される送り手のデフォルトＡＣＨ金銭の手段をルックアップする。料金スケジュールによれば、ＡＣＨトランザクションは、５０ドルのトランザクションについて０．６０ドルのコストがかかる（１．０％＋１トランザクションあたり０．１０ドル）。トランザクション承認者は、呼出し側に返されるトランザクションＩＤも生成する。このすべてに基づいて、トランザクション承認者は、次を実行する。
【０２３９】
・  送り手の銀行口座からＡＣＨを介して５０．００ドルを引き出す
・  トランザクション承認者の送り手のアカウントに５０．００ドルを預ける
・  トランザクション承認者の送り手のアカウントからトランザクション承認者の受取人のアカウントへの５０．００ドルの残高繰越しを実行する
・  トランザクション承認者の呼出し側のアカウントからトランザクション承認者への０．６０ドルの残高繰越しを実行する
参照および説明は、論争解決変数と共に、すべてがトランザクションデータに保管される。勘定残高は、上のトランザクションの実行の間に更新される。
【０２４０】
支払い応答メッセージ
トランザクションが成功であったので、トランザクションＩＤが、支払い応答メッセージの一部として呼出し側に返される。
【０２４１】
【表４８】
2008507064.tif 000050
【０２４２】
いくつかの実施形態において、使用法命令ルールセットは、なんらかのイベントが承認されるか否かを検査するのに使用され、コンテキストデータに対して評価されるルールのセット（「アサーション式」または「アサーション」とも称する）を含み、それらのルール／アサーションがコンテキストデータの所与のセットについて真と評価される場合には、イベントが承認される。使用法命令ルールセットを定義する言語の例は、次の通りである。
【０２４３】
アサーションの例
この例の言語では、アサーションは、真または偽に評価される式（すなわち、ブール式）である。代入を使用して、変数の値をセットすることもできる。命令ルールセット内のアサーションのすべてが真と評価される場合には、トランザクションが承認され、そうである場合には、代入される変数（ある場合に）の値を使用して、そのトランザクションの実行を指示することができる。
【０２４４】
最も単純な支払い命令ルールセットは、次のテキストからなる。というのは、このテキストが必ず真に評価されるからである。
【０２４５】
【表４９】
2008507064.tif 000051
【０２４６】
論理演算子、いくつかの単純な式、およびリテラルを有するより多くのアサーションを追加する。それがどのように見えるかを示す
【０２４７】
【表５０】
2008507064.tif 000052
【０２４８】
上の支払い命令ルールセットは、必ず真に評価される（２００４年１２月５日の前である限り）。
【０２４９】
この例の言語の式は、演算子優先順位に関してＰｅｒｌまたはＣの式に類似する。例示のために、次の式を参照されたい。
【０２５０】
【表５１】
2008507064.tif 000053
【０２５１】
上の式は、真に評価される。というのは、上の式が、次式と同等であるからである。
【０２５２】
【表５２】
2008507064.tif 000054
【０２５３】
より一般的に、演算子評価の優先順位は、次の順序である。
【０２５４】
１）リテラル、ブラックボード間接参照（ｂｌａｃｋｂｏａｒｄ  ｄｅｒｅｆｅｒｅｎｃｅ）、および括弧（）内の式
２）ネゲート−否定！
３）乗算＊除算／、左から右へ
４）マイナス−プラス＋、左から右へ
５）等しい＝＝不等！＝未満＜超＞以下＜＝以上＞＝、ｉｎ、ｎｏｔＩｎ
６）論理積＆＆、左から右へ
７）論理和｜｜、左から右へ
やはりＣまたはＰｅｒｌに似て、ホワイトスペースは、この例の言語では無視され、したがって、タブ、スペース、および改行は、重要でない（ストリング引用符内を除く。ストリング引用符内では、正確なフォーマッティングが保存される）。
【０２５５】
代入の例
ユーザは、変数を作成し、代入ステートメントを作ることによって変数の値をセットすることができる。代入ステートメントは、次のような外見を有する。
【０２５６】
【表５３】
2008507064.tif 000055
【０２５７】
次のステートメントは、ＭｙＦａｖｏｒｉｔｅＡｍｏｕｎｔという名前のｍｏｎｅｙ型の変数を作成し、その値に７．９９米国ドルをセットする。
【０２５８】
【表５４】
2008507064.tif 000056
【０２５９】
変数は、支払い命令ルールセットの評価全体を通じて値を変化させない。１つの変数に関する複数の代入ステートメントを設けることができる（異なる支払い命令ルールセット内であっても）が、すべての値が一致しなければならず、さもなければ、この状態はアサーション失敗として扱われる。変数は、ブラックボードに保管され、これは、ユーザがアサーションで変数を間接参照できることを意味する。支払い命令ルールセット（または同時に評価される別の支払い命令ルールセット）で代入される変数は、どの式においても使用することができる。
【０２６０】
コンテキストブラックボード
リテラルを有する式を処理することは、かなり無益である。というのは、これらが、必ず同一の結果に評価されるからである。実際には、支払い命令ルールセットは、コンテキストデータのあるセットに対して評価され、このセットは、この例の言語では、ブラックボードと呼ばれるメモリ領域に保管される。この例では、ブラックボードは、ストリングキーからスカラ値への単純なマップである。ストリングキーは、通常、大文字から始まる。名前は、大文字小文字の区別がある。ブラックボードは、イベントに固有のデータを提供する。
【０２６１】
式内でブラックボードデータを間接参照するには、参照名を単純に式に含める。
【０２６２】
【表５５】
2008507064.tif 000057
【０２６３】
ブラックボード間接参照は、スカラ値を使用できるすべての式で使用することができる。
【０２６４】
ブラックボードに保管される変数は、グローバル変数またはプライベート変数のいずれかである。プライベート変数は、特定の支払い命令ルールセット（例えば、送り手、受取人、または呼出し側）によってのみ使用することができるが、グローバル変数は、すべての支払い命令ルールセットによって式内で使用することができる。
【０２６５】
この例では、変数は、変化しない単一の値を代入される。異なる変数は、その値に関する異なる提供源を有する。例えば、変数の中には、支払い命令ルールセット内で値を代入されるものと、トランザクション承認システム（「ＴＡＳ」）によって指定されるものと、支払い要求メッセージ内で呼出し側によって渡されるものがある。
【０２６６】
下のチャートに、すべての支払い要求メッセージについて定義される変数を、各変数の値の提供源と共に示す。さらに、支払い命令ルールセットは、代入ステートメントを使用して、それ自体の変数を作成することができる。これらの変数は、グローバルであり、例えば、送り手の支払い命令ルールセット内の代入ステートメントによって作成された変数を、受取人の指示内の式で使用することができる。ユーザ指定の変数の名前は、ＴＡＳ定義の変数名および他のユーザ定義変数との衝突を避けるために、そのユーザに固有の文字の識別シーケンスから始まらなければならない。例えば、ＢｏｂのＳｕｒｆ  Ｓｈａｃｋによって定義される変数名は、すべてが、‘ＢｏｂｓＳｕｒｆＳｈａｃｋ’から始まるものとすることができる。
【０２６７】
少数の例外はあるが、すべてのグローバル変数は、呼出し側によって支払い要求メッセージで渡すことができ、あるいは、支払い命令ルールセットのいずれかで指定することができ、したがって、下のチャートに示された現在の提供源は、規約に過ぎない。これに対する例外には、ＴＡＳによって指定される値を有する変数と、少なくとも１つのトークンが、入ってくる承認メッセージに渡される必要があり、使用されるすべての他のトークンが、到達可能である必要があるという事実とが含まれる。例えば、ＣａｌｌｅｒＴｏｋｅｎが、支払い要求メッセージで提供される唯一のトークンである場合に、対応する支払い命令ルールセットは、ＳｅｎｄｅｒＴｏｋｅｎまたはＲｅｃｉｐｉｅｎｔＴｏｋｅｎあるいはその両方を示すことができる。対応する支払い命令ルールセットがＳｅｎｄｅｒＴｏｋｅｎだけを示す場合には、送り手の支払い命令ルールセットがＲｅｃｉｐｉｅｎｔＴｏｋｅｎを示すことができ、逆も同様である。
【０２６８】
【表５６−１】
2008507064.tif 000058
【０２６９】
【表５６−２】
2008507064.tif 000059
【０２７０】
プライベート変数
下のチャートにリストされたプライベート変数は、各支払い命令ルールセットがこれらの変数のそれぞれのそれ自体のコピーを得るように、支払い命令ルールセットごとに提供される。例えば、これらの参照のデータは、受取人と送り手について異なる。受取人は、送り手の値にアクセスすることができず、逆も同様である。
【０２７１】
【表５７−１】
2008507064.tif 000060
【０２７２】
【表５７−２】
2008507064.tif 000061
【０２７３】
コメント
コメントは、番号記号（＃）から始まり、その行の残りを無視させる。複数行コメントについては、各行の始めに＃を置く。
【０２７４】
【表５８】
2008507064.tif 000062
【０２７５】
言語特性
いくつかの実施形態において、この言語に、ループ構造および／または再帰などの時間的態様が含まれる場合があるが、この例には、そのような時間的態様または分岐ステートメントは含まれない。データ型には、ｂｏｏｌｅａｎ、ｎｕｍｂｅｒ、ｓｔｒｉｎｇ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ、およびｍｏｎｅｙが含まれる。演算子は、次の通りである。
【０２７６】
【表５９】
2008507064.tif 000063
【０２７７】
リテラル
ＢＯＯＬＥＡＮ
【０２７８】
【表６０】
2008507064.tif 000064
【０２７９】
ＮＵＭＢＥＲ
【０２８０】
【表６１】
2008507064.tif 000065
【０２８１】
２３１−１までのすべての整数が許容される。負の値は、「ネゲート」演算を介して達成される。小数は、やはりサポートされ、浮動小数点数としては保管されない。数は、数字から始まり、したがって、先頭の０は、０と１の間の小数に使用される。パーセンテージとして数を表すこともサポートされる。
【０２８２】
ＳＴＲＩＮＧ
【０２８３】
【表６２】
2008507064.tif 000066
【０２８４】
ストリングリテラルは、一重引用符に囲まれる。二重引用符は、現在は使用されない。
【０２８５】
ＤＡＴＥＴＩＭＥ
【０２８６】
【表６３】
2008507064.tif 000067
【０２８７】
‘ｎｏｗ’リテラルは、現在時刻を返す。このパターンに続く引用符で囲まれたテキストを、比較することができる。ｄａｔｅｔｉｍｅキーワードは、ストリング式ではなく、引用符で囲まれたテキストを扱う。
【０２８８】
ＤＵＲＡＴＩＯＮ
【０２８９】
【表６４】
2008507064.tif 000068
【０２９０】
ｄｕｒａｔｉｏｎリテラルは、時間の期間を指定し、新しい日付を形成するために日付に追加することができる。様々な数学演算が利用可能である。
【０２９１】
【表６５】
2008507064.tif 000069
【０２９２】
上の２つのリテラルスタイルの両方がサポートされる。第２のリテラルスタイルは、１年２カ月３日１０時間３０分に変換される。ｄｕｒａｔｉｏｎリテラルの第２の形は、非特許文献１の持続時間の定義に従う。
【０２９３】
持続時間の語彙表現は、非特許文献２の拡張フォーマットＰｎＹｎＭｎＤＴｎＨｎＭｎＳであり、ここで、ｎＹは、年数を表し、ｎＭは、月数を表し、ｎＤは、日数を表し、‘Ｔ’は、日付／時刻セパレータであり、ｎＨは、時数を表し、ｎＭは、分数を表し、ｎＳは、秒数を表す。
【０２９４】
ＭＯＮＥＹ
【０２９５】
【表６６】
2008507064.tif 000070
【０２９６】
ｍｏｎｅｙリテラルは、通貨コードおよびｎｕｍｂｅｒリテラル、または通貨コードおよび数を表す式によって指定することができる。すべての通貨コードをリストしたテーブルを含む、通貨コードに関するさらなる情報については非特許文献３を参照されたい。許容できる通貨コードのセットは、ＩＳＯ  ４２１７によって指定されるものに限定されないが、ＩＳＯ  ４２１７の通貨コードは認識される。
【０２９７】
演算子および組込み関数
次のセクションでは、ｌｈｓは、左側オペランドを表し、ｒｈｓは、右側オペランドを表す。
【０２９８】
ＮＥＧＡＴＥＯＰＥＲＡＴＩＯＮ
【０２９９】
【表６７】
2008507064.tif 000071
【０３００】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｄｕｒａｔｉｏｎ、ｍｏｎｅｙ
ＮＯＴＯＰＥＲＡＴＩＯＮ
【０３０１】
【表６８】
2008507064.tif 000072
【０３０２】
許容される型：ｂｏｏｌｅａｎ
ＯＲＯＰＥＲＡＴＩＯＮ
【０３０３】
【表６９】
2008507064.tif 000073
【０３０４】
許容される型：ｂｏｏｌｅａｎ
ＡＮＤＯＰＥＲＡＴＩＯＮ
【０３０５】
【表７０】
2008507064.tif 000074
【０３０６】
許容される型：ｂｏｏｌｅａｎ
ＩＮＯＰＥＲＡＴＩＯＮ
【０３０７】
【表７１】
2008507064.tif 000075
【０３０８】
許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。ｉｎ演算子は、次の省略形であり、正確に次と同等である。
【０３０９】
【表７２】
2008507064.tif 000076
【０３１０】
ＮＯＴＩＮＯＰＥＲＡＴＩＯＮ
【０３１１】
【表７３】
2008507064.tif 000077
【０３１２】
許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。ｎｏｔＩｎ演算子は、次の省略形であり、正確に次と同等である。
【０３１３】
【表７４】
2008507064.tif 000078
【０３１４】
ＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ
【０３１５】
【表７５】
2008507064.tif 000079
【０３１６】
許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３１７】
ＮＯＴＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ
【０３１８】
【表７６】
2008507064.tif 000080
【０３１９】
許容される型：すべての型
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３２０】
ＬＥＳＳＴＨＡＮＯＰＥＲＡＴＩＯＮ
【０３２１】
【表７７】
2008507064.tif 000081
【０３２２】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３２３】
ＧＲＥＡＴＥＲＴＨＡＮＯＰＥＲＡＴＩＯＮ
【０３２４】
【表７８】
2008507064.tif 000082
【０３２５】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３２６】
ＬＥＳＳＴＨＡＮＯＲＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ
【０３２７】
【表７９】
2008507064.tif 000083
【０３２８】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３２９】
ＧＲＥＡＴＥＲＴＨＡＮＯＲＥＱＵＡＬＳＯＰＥＲＡＴＩＯＮ
【０３３０】
【表８０】
2008507064.tif 000084
【０３３１】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３３２】
ＡＤＤＯＰＥＲＡＴＩＯＮ
【０３３３】
【表８１】
2008507064.tif 000085
【０３３４】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。
【０３３５】
ｍｏｎｅｙに対する操作は、ｌｈｓとｒｈｓの両方がｍｏｎｅｙ型であることを必要とする。
【０３３６】
ｄｕｒａｔｉｏｎをｄｕｒａｔｉｏｎに加算することができ、ｄｕｒａｔｉｏｎがもたらされる。
【０３３７】
ｄａｔｅｔｉｍｅをｄｕｒａｔｉｏｎに加算することができ、あるいは、ｄｕｒａｔｉｏｎをｄａｔｅｔｉｍｅに加算することができ、ｄａｔｅｔｉｍｅがもたらされる。
【０３３８】
ＳＵＢＯＰＥＲＡＴＩＯＮ
【０３３９】
【表８２】
2008507064.tif 000086
【０３４０】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。
【０３４１】
ｍｏｎｅｙに対する操作は、ｌｈｓとｒｈｓの両方がｍｏｎｅｙ型であることを必要とする。
【０３４２】
ｄｕｒａｔｉｏｎをｄｕｒａｔｉｏｎから減算することができ、ｄｕｒａｔｉｏｎがもたらされる。
【０３４３】
ｄｕｒａｔｉｏｎをｄａｔｅｔｉｍｅから減算することができ、ｄａｔｅｔｉｍｅはｌｈｓでなければならず、ｄｕｒａｔｉｏｎはｒｈｓでなければならず、ｄａｔｅｔｉｍｅがもたらされる。
【０３４４】
ＭＵＬＴＯＰＥＲＡＴＩＯＮ
【０３４５】
【表８３】
2008507064.tif 000087
【０３４６】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄｕｒａｔｉｏｎ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。
【０３４７】
ｍｏｎｅｙについて、ｍｏｎｅｙは、ｉｎｔｅｇｅｒまたはｄｏｕｂｌｅによって乗算することができ、ｍｏｎｅｙがもたらされる。
【０３４８】
ｄｕｒａｔｉｏｎについて、ｄｕｒａｔｉｏｎは、ｉｎｔｅｇｅｒによって乗算することができ、ｄｕｒａｔｉｏｎがもたらされる。
【０３４９】
ＤＩＶＯＰＥＲＡＴＩＯＮ
【０３５０】
【表８４】
2008507064.tif 000088
【０３５１】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ
Ｉｎｔｅｇｅｒおよびｄｏｕｂｌｅを操作することができ、これは、両方のオペランドがｉｎｔｅｇｅｒである場合を除いてｄｏｕｂｌｅをもたらす。
【０３５２】
ｍｏｎｅｙについて、ｍｏｎｅｙは、ｉｎｔｅｇｅｒまたはｄｏｕｂｌｅによって除算することができ、ｌｈｓはｍｏｎｅｙ値でなければならず、ｒｈｓはｉｎｔｅｇｅｒまたはｄｏｕｂｌｅでなければならず、ｍｏｎｅｙがもたらされる。
【０３５３】
ＭＩＮＦＵＮＣＴＩＯＮ
【０３５４】
【表８５】
2008507064.tif 000089
【０３５５】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３５６】
ＭＡＸＦＵＮＣＴＩＯＮ
【０３５７】
【表８６】
2008507064.tif 000090
【０３５８】
許容される型：ｉｎｔｅｇｅｒ、ｄｏｕｂｌｅ、ｍｏｎｅｙ、ｄａｔｅｔｉｍｅ、ｄｕｒａｔｉｏｎ
ｉｎｔｅｇｅｒ型とｄｏｕｂｌｅ型を比較できることを除いて、ｌｈｓおよびｒｈｓは、同一の型でなければならない。
【０３５９】
ＭＯＤＦＵＮＣＴＩＯＮ
【０３６０】
【表８７】
2008507064.tif 000091
【０３６１】
許容される型：ｉｎｔｅｇｅｒ
ｌｈｓとｒｈｓの除算の整数剰余をもたらす。
【０３６２】
ＣＡＴＦＵＮＣＴＩＯＮ
【０３６３】
【表８８】
2008507064.tif 000092
【０３６４】
許容される型：ｓｔｒｉｎｇ
ｌｈｓとｒｈｓを組み合わせたストリングをもたらす。
【０３６５】
ＧＥＴＣＵＲＲＥＮＣＹＣＯＤＥ
【０３６６】
【表８９】
2008507064.tif 000093
【０３６７】
許容される型：ｍｏｎｅｙ
ストリングとして通貨コードを返す。
【０３６８】
解析文法
【０３６９】
【表９０−１】
2008507064.tif 000094
【０３７０】
【表９０−２】
2008507064.tif 000095
【０３７１】
【表９０−３】
2008507064.tif 000096
【０３７２】
【表９０−４】
2008507064.tif 000097
【０３７３】
語彙定義
【０３７４】
【表９１】
2008507064.tif 000098
【０３７５】
前述から、例示のために本明細書で特定の実施形態を説明したが、本発明の趣旨および範囲から逸脱せずに、様々な変更を行えることが理解されるであろう。したがって、本発明は、添付の特許請求の範囲およびそこに列挙された要素によるものを除いて限定されない。さらに、本発明のある種の態様を、添付の特許請求の範囲である種の請求項の形で提示するが、本発明人は、すべての利用可能な請求項の形において本発明の様々な態様を企図している。例えば、本発明の一部の態様だけが、コンピュータ可読媒体で実施されるものとして現在は列挙されている可能性があるが、他の態様も、同様にそのように実施することができる。
【図面の簡単な説明】
【０３７６】
【図１Ａ】プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。
【図１Ｂ】プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。
【図１Ｃ】プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。
【図１Ｄ】プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。
【図１Ｅ】プログラム的トランザクションを承認するのに使用される使用法命令ルールセットを定義する例を示す。
【図２】ウェブサービス支払い処理システムの例示的実施形態のコンポーネントおよび情報フローを示すネットワーク図である。
【図３】支払い処理システムの実施形態を実行するのに適したコンピューティングシステムの実施形態を示すブロック図である。
【図４】ユーザアカウント管理ルーチンの実施形態のフロー図である。
【図５】トランザクション承認およびハンドラルーチンの実施形態のフロー図である。
【図６】トランザクション妥当性検査サブルーチンの実施形態のフロー図である。
【図７Ａ】支払い処理トランザクションサブルーチン実行の実施形態のフロー図である。
【図７Ｂ】支払い処理トランザクションサブルーチン実行の実施形態のフロー図である。
【図８Ａ】トランザクションへの関係者間の対話のタイプの例を示す。
【図８Ｂ】トランザクションへの関係者間の対話のタイプの例を示す。
【図８Ｃ】トランザクションへの関係者間の対話のタイプの例を示す。
【図９Ａ】トランザクションへの関係者間の対話のタイプの例を示す。
【図９Ｂ】トランザクションへの関係者間の対話のタイプの例を示す。
【図１０Ａ】トランザクションへの関係者間の対話のタイプの例を示す。
【図１０Ｂ】トランザクションへの関係者間の対話のタイプの例を示す。
【図１０Ｃ】トランザクションへの関係者間の対話のタイプの例を示す。
【図１Ａ】
2008507064.tif 000099
【図１Ｂ】
2008507064.tif 000100
【図１Ｃ】
2008507064.tif 000101
【図１Ｄ】
2008507064.tif 000102
【図１Ｅ】
2008507064.tif 000103
【図２】
2008507064.tif 000104
【図３】
2008507064.tif 000105
【図４】
2008507064.tif 000106
【図５】
2008507064.tif 000107
【図６】
2008507064.tif 000108
【図７Ａ】
2008507064.tif 000109
【図７Ｂ】
2008507064.tif 000110
【図８Ａ】
2008507064.tif 000111
【図８Ｂ】
2008507064.tif 000112
【図８Ｃ】
2008507064.tif 000113
【図９Ａ】
2008507064.tif 000114
【図９Ｂ】
2008507064.tif 000115
【図１０Ａ】
2008507064.tif 000116
【図１０Ｂ】
2008507064.tif 000117
【図１０Ｃ】
2008507064.tif 000118
【国際調査報告】
2008507064.tif 000119