(57)【特許請求の範囲】
【請求項１】
コンピュータの処理により、電子商取引における支払い制約ルールを定義し実施する方法であって、前記方法は、
第１支払い制約ルールに対応する第１関係オブジェクトを前記コンピュータのメモリ中に生成するステップと、
注文商品がショッピング・カートに入れられており、前記注文商品は１つ以上の支払い制約ルールに関連付けられており、さらに、前記１つ以上の支払い制約ルールに対応する１つ以上の事前条件が満たされているという判断に応答して、前記１つ以上の支払い制約ルールを実行するステップであって、前記支払い制約ルールには優先度が付与されており、前記支払い制約ルールが複数存在し、異なる優先度を有する場合には、当該優先度が高い支払い制約ルールを選択し、支払い制約ルールを自動的に生成する、実行するステップと、
前記１つ以上の支払い制約ルールに対応する１つ以上の事後条件が満たされているという判断に応答して、前記注文商品を含んでいる前記ショッピング・カートから購入注文を送信するステップであって、前記注文商品は、前記１つ以上の支払い制約ルールによって制約される、前記送信するステップと、
を含む、方法。
【請求項２】
前記第１関係オブジェクトは、前記１つ以上の支払い制約ルールを前記注文商品に関連付ける、請求項１に記載の方法。
【請求項３】
前記ショッピング・カートは、一時記憶場所をさらに含む、請求項１に記載の方法。
【請求項４】
第２支払い制約ルールに対応するカタログ・カテゴリを探し出すステップと、
前記第２支払い制約ルールは有効期限に関連付けられているという判断に応答して、前記有効期限を前記第２支払い制約ルールに追加するステップと、
前記第２支払い制約ルールを支払いデータベースに挿入するステップと、
をさらに含む、請求項１に記載の方法。
【請求項５】
前記第１支払い制約ルールと前記第２支払い制約ルールとは、同一の制約ルールである、請求項４に記載の方法。
【請求項６】
支払いデータベースにて支払い制約ルールを検索するステップと、
複数の支払い制約ルールのうちの１つを前記支払いデータベースからの削除に向けて選択するステップと、
前記選択された支払い制約ルールを、前記支払いデータベースから削除するステップと、
をさらに含む、請求項１に記載の方法。
【請求項７】
支払いデータベースにて支払い制約ルールを検索するステップと、
複数の支払い制約ルールのうちの１つ以上を前記支払いデータベースにおける変更に向けて選択するステップと、
１つ以上の新しい支払い方法を前記支払いデータベースに挿入することによって、前記選択された支払い制約ルールを前記支払いデータベースにて更新するステップと、
をさらに含む、請求項１に記載の方法。
【請求項８】
プロセッサと、
前記プロセッサに接続されているデータ・バスと、
前記データ・バスに接続されているメモリと、
コンピュータ・プログラム・コードを具現化しているコンピュータ使用可能媒体と、
を含む、コンピュータ・システムであって、
請求項１〜７の何れか１項に記載の方法の各ステップをハードウェア手段として構成した、コンピュータ・システム。
【請求項９】
請求項１〜７の何れか１項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。
【請求項１０】
請求項９記載の前記コンピュータ・プログラムをコンピュータ読み取り可能な記録媒体に記録した、記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にデータ処理システムに関し、特に、電子商取引（ｅコマース：ｅ−ｃｏｍｍｅｒｃｅ：ｅｌｅｃｔｒｏｎｉｃ  ｃｏｍｍｅｒｃｅ）システムに関する。
【背景技術】
【０００２】
現在、電子商取引ではデータ処理システムを使用して購買が行われている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
複雑な支払いポリシを実施するための制約の使用を電子商取引に提供すること。
【課題を解決するための手段】
【０００４】
電子商取引（ｅコマース）において、複雑な支払いポリシを実施するように支払い制約を用いる方法、システムおよびコンピュータ・プログラム製品が開示される。注文取り込みコンポーネントが、第１支払い制約ルールに対応する第１関係オブジェクトを少なくとも生成する。注文商品がショッピング・カートに入れられており、その注文商品が１つ以上の支払い制約ルールに関連付けられており、さらに、１つ以上の支払いルールに対応する１つ以上の事前条件が満たされていれば、注文取り込みコンポーネントは、１つ以上の支払い制約ルールを実行する。１つ以上の支払い制約ルールに対応する１つ以上の事後条件が満たされていれば、注文取り込みコンポーネントは、当該注文商品を含んでいるショッピング・カートから注文を送信する。
【図面の簡単な説明】
【０００５】
【図１】本発明の一実施形態による例示的なコンピュータの高レベル・ブロック図である。
【図２】本発明の一実施形態による例示的な支払いデータベースと付随的な制約ヘルパおよび支払いヘルパとを示す図である。
【図３】注文の支払いを処理する場合に使用されるとよい例示的な制約ルールを示す図である。
【図４】新しい制約ルールを生成する例示的な方法の高レベル論理フローチャートである。
【図５】複雑な支払いポリシを実施するように支払い制約を用いる例示的な方法の高レベル論理フローチャートである。
【図６】支払いデータベースに支払い制約ルールを追加する例示的な方法の高レベル論理フローチャートである。
【図７】支払いデータベースから支払い制約ルールを削除する例示的な方法の高レベル論理フローチャートである。
【図８】支払いデータベースにおいて支払い制約ルールを更新する例示的な方法の高レベル論理フローチャートである。
【発明を実施するための形態】
【０００６】
当業者であればすぐに分かるように、本発明は、方法、システムまたはコンピュータ・プログラム製品として具現化することができる。従って、本発明は、完全なハードウェアの実施形態、完全なソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、あるいはソフトウェアの側面とハードウェアの側面とを組み合わせた実施形態の形態をとり得るものであり、これら全てが本明細書において一般に「回路」、「モジュール」または「システム」と称されることもある。さらに本発明は、媒体に具現化されたコンピュータ使用可能プログラム・コードを備えた、コンピュータ使用可能記憶媒体上のコンピュータ・プログラム製品の形態をとってもよい。
【０００７】
任意の適切なコンピュータ使用可能またはコンピュータ可読媒体を、利用することができる。コンピュータ使用可能またはコンピュータ可読媒体は、例えば、電子、磁気、光学、電磁気、赤外線、または半導体のシステム、装置、デバイスまたは伝搬媒体であるとよいが、これらに限定されない。コンピュータ可読媒体のさらに具体的な例（非網羅的なリスト）としては、以下が挙げられるだろう：１つ以上のワイヤを有する電気的接続、携帯型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ：ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ、またはフラッシュ・メモリ）、光ファイバ、携帯型コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：ｃｏｍｐａｃｔ  ｄｉｓｃ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、光学式記憶デバイス、インターネットもしくはイントラネットをサポートしている媒体などの伝送媒体、または磁気記憶デバイス。プログラムは、例えば紙またはその他の媒体の光学式走査などを介して電子的に取り込み、その後必要に応じてコンパイル、解釈、あるいは他の方法で適切に処理してからコンピュータ・メモリに保存することができるため、コンピュータ使用可能またはコンピュータ可読媒体は、プログラムが書き込まれた紙またはその他の適切な媒体である可能性すらあることに留意されたい。本文書の文脈において、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置またはデバイスによってあるいはこれらに関連して使用されるように、上記のプログラムを収容、保存、通信、伝搬あるいは搬送することのできる任意の媒体であればよい。コンピュータ使用可能媒体には、具現化されたコンピュータ使用可能プログラム・コードを備えてベースバンドであるいは搬送波の一部として伝搬されるデータ信号を、含めることもできる。コンピュータ使用可能プログラム・コードは、例えばインターネット、ワイヤライン、光ファイバ・ケーブル、ＲＦなどを含むがこれらに限定されない任意の適切な媒体を用いて、伝送されるとよい。
【０００８】
本発明の動作を実行するコンピュータ・プログラム・コードは、Ｊａｖａ（ＪａｖａはＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の米国およびその他の国における商標または登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などの、オブジェクト指向プログラミング言語で書かれているとよい。一方、本発明の動作を実行するコンピュータ・プログラム・コードは同様に、「Ｃ」プログラミング言語または類似したプログラミング言語など、従来の手続き型プログラミング言語で書かれていてもよい。プログラム・コードは、全面的にユーザのコンピュータ上で実行されてもよいし、自立型ソフトウェア・パッケージとして部分的にユーザのコンピュータ上で実行されてもよいし、部分的にユーザのコンピュータ上で実行されさらに部分的にリモート・コンピュータ上で実行されてもよいし、あるいは全面的にリモート・コンピュータまたはサーバ上で実行されてもよい。後の方のシナリオでは、リモート・コンピュータが、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）またはワイド・エリア・ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）を介してユーザのコンピュータに接続されていてもよいし、あるいはこの接続が、外部コンピュータに対して（例えば、インターネット・サービス・プロバイダを使いインターネットを介して）設けられてもよい。
【０００９】
以下、本発明の実施形態による方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート説明図またはブロック図あるいはその両方を参照して、本発明を説明する。当然のことながら、フローチャート説明図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート説明図またはブロック図あるいはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令によって実現することができる。こうしたコンピュータ・プログラム命令は、マシンを形成するように、汎用コンピュータ、特殊用途コンピュータ、またはその他のプログラム可能なデータ処理装置のプロセッサへ提供されてもよく、それにより、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサによって実行される命令が、フローチャートまたはブロック図あるいはその両方の単数または複数のブロックに明示されている機能／作用を実現する手段をもたらすようになる。
上記のコンピュータ・プログラム命令はさらに、コンピュータまたは他のプログラム可能なデータ処理装置を特定の形で機能するように仕向けることが可能なコンピュータ可読メモリに保存されてもよく、それにより、コンピュータ可読メモリに保存された命令が、フローチャートまたはブロック図あるいはその両方の単数または複数のブロックに明示されている機能／作用を実現する命令手段を備えた製品を形成するようになる。
コンピュータ・プログラム命令はさらに、コンピュータ実装されたプロセスを形成するように、コンピュータまたは他のプログラム可能なデータ処理装置上にロードされて、コンピュータまたは他のプログラム可能な装置上における一連の動作ステップの実行をもたらしてもよく、それにより、コンピュータまたは他のプログラム可能な装置上で実行される命令が、フローチャートまたはブロック図あるいはその両方の単数または複数のブロックに明示されている機能／作用を実現するステップ群を提供するようになる。
【００１０】
ここで図１を参照すると、本発明とともに利用するとよい例示的なコンピュータ１００のブロック図が示されている。コンピュータ１００は、システム・バス１０６に接続されているプロセッサ・ユニット１０４を含む。ディスプレイ１１０を駆動／サポートする映像アダプタ１０８も、同様にシステム・バス１０６に接続されている。システム・バス１０６は、バス・ブリッジ１１２を介して、入力／出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）バス１１４に接続されている。Ｉ／Ｏインターフェース１１６が、Ｉ／Ｏバス１１４に接続されている。Ｉ／Ｏインターフェース１１６は、キーボード１１８、マウス１２０、コンパクト・ディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ）ドライブ１２２、およびフラッシュ・メモリ・ドライブ１２６などの多様なＩ／Ｏデバイスに対する通信を提供する。Ｉ／Ｏインターフェース１１６に接続されているポートの形式は、コンピュータ・アーキテクチャ技術の当業者に周知の任意のものとすればよく、ユニバーサル・シリアル・バス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）ポートなどが挙げられるが、これに限定されない。
【００１１】
コンピュータ１００は、システム・バス１０６に接続されているネットワーク・インターフェース１３０を用いネットワーク１２８を介して、サーバ１５０と通信することができる。ネットワーク１２８は、インターネットなどの外部ネットワークとしてもよいし、あるいは、ローカル・エリア・ネットワーク（ＬＡＮ）、Ｅｔｈｅｒｎｅｔ（Ｒ）または仮想プライベート・ネットワーク（ＶＰＮ：Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）などの内部ネットワークとしてもよい。一実施形態では、サーバ１５０は、コンピュータ１００と同様に構成されている。
【００１２】
ハード・ドライブ・インターフェース１３２がさらに、システム・バス１０６に接続されている。ハード・ドライブ・インターフェース１３２は、ハード・ドライブ１３４のインターフェースとなる。一実施形態では、ハード・ドライブ１３４は、同様にシステム・バス１０６に接続されているシステム・メモリ１３６にポピュレートする。システム・メモリ１３６は、コンピュータ１００において揮発性メモリの最下位レベルとして定義される。この揮発性メモリには、例えばキャッシュ・メモリ、レジスタおよびバッファなどを含むがこれらに限定されない、揮発性メモリの追加的な上位レベル（図示せず）を含めてもよい。システム・メモリ１３６にポピュレートするデータとしては、オペレーティング・システム（ＯＳ：Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）１３８、アプリケーション・プログラム１４４およびデータベース１３７がある。データベース１３７は、１つ以上の電子商取引（ｅコマース）注文に対応する情報を含んでいる。一実施形態では、データベース１３７が、電子的なショッピング・カートを含むとよい。一実施形態では、データベース１３７がサーバ１５０に保存されていてもよく、あるいはフラッシュ・メモリ・ドライブ１２６などの外部記憶デバイス上に保存されていてもよい。
【００１３】
ＯＳ１３８は、アプリケーション・プログラム１４４などの資源に対する透過的なアクセスを提供するシェル１４０を含む。一般に、シェル１４０は、ユーザとオペレーティング・システムとの間にインタープリタおよびインターフェースを提供するプログラムである。シェル１４０は、システム・プロンプトを提供し、キーボード１１８、マウス１２０または他のユーザ入力媒体により入力されたコマンドを解釈し、さらに、解釈されたコマンド（単数または複数）を処理に向けて、オペレーティング・システムの適切な下位レベル（例えば、カーネル１４２）へと送信する。図に示すように、ＯＳ１３８はさらに、グラフィカル・ユーザ・インターフェース（ＧＵＩ：ｇｒａｐｈｉｃａｌ  ｕｓｅｒ  ｉｎｔｅｒｆａｃｅ）１４３と、ＯＳ１３８の下位レベルの機能を備えたカーネル１４２とを含む。カーネル１４２は、ＯＳ１３８の他の部分およびアプリケーション・プログラム１４４によって要求される基本的なサービスを提供する。カーネル１４２によって提供されるサービスとしては、メモリ管理、プロセスおよびタスク管理、ディスク管理、ならびにＩ／Ｏデバイス管理が挙げられる。
【００１４】
アプリケーション・プログラム１４４は、ブラウザ１４６、製品マネージャ１４７、制約付き支払いヘルパ１４８、および制約ヘルパ１４９を含む。ブラウザ１４６は、ワールド・ワイド・ウェブ（ＷＷＷ：Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）クライアント（すなわち、コンピュータ１００）がインターネットに対してネットワーク・メッセージを送受信できるようにするプログラム・モジュールおよび命令を含む。コンピュータ１００は、サーバ１５０との通信が可能になるように、ハイパーテキスト転送プロトコル（ＨＴＴＰ：ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）メッセージングを利用するとよい。製品マネージャ１４７、制約付き支払いヘルパ１４８、および制約ヘルパ１４９は、下記で図２乃至８に示される機能、プロセスおよび方法の実行に利用される。
【００１５】
一実施形態では、コンピュータ１００が、製品マネージャ１４７、制約付き支払いヘルパ１４８、および制約ヘルパ１４９を、好ましくは「オン・デマンド」ベースで、（例えば、サーバ１５０を利用している）サービス・プロバイダからダウンロードすることができる。その上、サービス・プロバイダ・サーバ１５０は製品マネージャ１４７、制約付き支払いヘルパ１４８、および制約ヘルパ１４９にあるコードを実行することができるので、ひいてはコンピュータ１００の処理資源が節約される。
【００１６】
コンピュータ１００に図示するハードウェア要素は、網羅的であることを意図したものではなく、むしろ、本発明に必要な基本的なコンポーネントを強調するための代表例である。例えば、コンピュータ１００には、磁気カセット、デジタル多用途ディスク（ＤＶＤ：Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、ベルヌーイ・カートリッジなどといった、別のメモリ記憶デバイスを含めてもよい。これらおよびその他の変形例は、本発明の精神および範囲のうちにあるものとされる。サービス・プロバイダ・サーバ１５０のハードウェア・アーキテクチャは、コンピュータ１００に関して示すものと実質的に同様であってもよいことに留意されたい。
【００１７】
図２を参照すると、例示的なデータベース１３７（図１にも示す）が示されている。一実施形態では、データベース１３７は、注文される商品２２０に関する１つ以上の注文ならびに関連する支払い命令２２５を含んだ注文ファイル２００を含む。注文ファイル２００に関連付けられているのは、契約２０５、カタログ項目２１０、および制約支払いルール２１５に関係する各ファイルである。契約２０５は、注文される商品２２０の買い手と売り手の間における何らかの契約上の取り決めを記述しており、注文に対する支払い、配達の行われ方など、注文がどのように応じられるのかについての取り決めに関する法律上のサポートを含んでいるとよい。カタログ項目２１０は、注文ファイル２００にて見つかる可能性のあるカタログ内の商品を、商品番号、明細、入手可能性などを含めて記述している。
【００１８】
支払い制約ルール２１５は、支払い方法（例えば、支払い方法２３０）と注文商品（例えば、注文される商品２２０）との、ｅコマース・システムにおける依存関係を定義する関係オブジェクトである。一実施形態では、関係オブジェクトは、ｅコマース・システムによって注文製品または支払い方法あるいはその両方を選択するのに用いられる１つ以上の対応する属性の指定またはフィルタリングあるいはその両方を行う、ルールベースの要素である。例えば、ｅコマース・システムのユーザが、値引き（例えば、特売または割引券など）に対応する第１支払い制約ルールに関連付けられた第１商品を選択する場合、この商品が購入に向けて選択される（すなわち、ショッピング・カートに追加される）と、第１商品の購入価格が自動的に調整されるとよい。同様に、ユーザが、資金調達の選択肢に対応する第２支払い制約ルールに関連付けられた第２商品を選択する場合、ユーザ定義アカウントから支払われる既定の金額、またはある期間にわたって賃借契約の形態で支払われる既定の金額、あるいはその両方が含まれるように、第２商品の購入価格が自動的に調整されるとよい。
【００１９】
制約支払いルール２１５に由来する例示的な制約ルールのさらなる詳細について、制約ルール２１６として図３に示す。制約ルール２１６は、制約ルールの任意のタイプの識別子であるルール識別子２４５を含む。図に示す例では、制約ルール２１６は、ルール番号５０００であり、ルール親番号１，３７２（要素２５０）の子である。言い換えれば、ルール親番号１，３７２は、注文の購入はどのように行われるべきかという全般的な制約ルールを定義し、（ルール識別子２４５によって、ルール番号５０００として識別される）制約ルール２１６は、注文に対する支払いはどのように行われるのかという詳細について、さらなる絞込みまたは追加修正あるいはその両方を行う。フィールド２５５によって示されるように、制約ルール２１６は通貨（「＄」）のルールであり、優先度は低い（フィールド２６０）。例示的な優先度レベルとしては、低、中、および高がある。フィールド２６５によって示されるように、制約ルール２１６は、ビジネス・アカウント用金銭的割引を提供するというルール操作を引き起こし、それによりフィールド２７０の通り、買い手が特定の顧客アカウント（「ＸＹＺ」）を使用していれば、注文に対して１０パーセントの割引が与えられる。故に、買い手がこの割引の資格を得るためには、（制約ルール２１６が実施される事前条件としてフィールド２７５に述べられているように）アカウント「ＸＹＺ」を使用している必要がある。さらに、注文がいかに多額であろうとも、合計割引額は＄５００を超過しないという、事後条件（フィールド２８０を参照のこと）の要件がある。フィールド２８５および２９０に示されるように、制約ルール２１６（従って、割引の提供）は、２００７年１２月２５日までに限り、＃１２の店舗においてのみ、実施されている。
【００２０】
ここで図２に戻ると、注文２００の特定の注文に対する支払いがどのように行われるのかということが、その特定注文に関する特定の支払い方法２３０を含んだ支払い命令２２５で定義される。支払い方法２３０を定義し利用するために、制約付き支払いヘルパ１４８および制約ヘルパ１４９が呼び出される。
【００２１】
制約付き支払いヘルパ１４８は、支払い方法機能２３５とともに、総合的に制約ルールを設定する。言い換えれば、制約付き支払いヘルパ１４８は、支払い方法機能２３５のなかから、特定の注文、売り主または顧客あるいはその全てに向けた支払い方法機能テンプレートを選択する。制約付き支払いヘルパ１４８は、任意の事前条件（例えば、買い手が特定の買い手アカウントを使用する必要があること）、事後条件（例えば、いかなる注文に対しても最大割引額は＄５００であること）、有効期限、特定の制約ルールの呼び出しに使うために制約ヘルパ１４９に必要とされるインターフェースなどを設けることによって、制約機能を設定する。
【００２２】
制約ヘルパ１４９は、制約機能２４０を含んだソフトウェア・オブジェクトである。制約機能２４０は、（例えば、制約支払いルール２１５に由来する）特定の制約ルールの呼び出し、評価などがどのように行われるのかを記述する。例として、図３に示した制約ルール２１６について考察する。制約機能２４０は、支払いルール２１６を呼び出す場合を判断する論理を含むとよい。この論理は、発注している顧客の個人情報、地理的または時間的区切り、注文される商品の即時入手可能性などに依存しているとよい。制約機能２４０はさらに、呼び出された制約ルールを適切に処理するために、どのようなタイプの制約ルール（例えば、割引、送料無料、払い戻し、将来使用する割引券など）が呼び出されているのかについても判断する。
【００２３】
どの制約ルールが呼び出されるかを制約機能２４０が判断したら、次いで制約機能２４０は、その制約ルールを使用するのに必要な追加条件が満たされているかどうかを判断する。図３に示した例示的な制約ルール２１６を引き続き用いると、制約機能２４０は、買い手が実際にアカウント＃ＸＹＺを使用しているかどうか、有効期限が来ていないかどうかなどを判断するとよい。全ての事前条件および事後条件が満たされていると制約機能２４０が判断すると、次に制約機能２４０は、その特定の制約ルールを利用するのに必要なソフトウェアが他にあればこれを呼び出す。そのようなソフトウェアの例として、テーブル、サブルーチン（またはその他の処理ソフトウェア・オブジェクト）、データベース、レジスタ、または、選択された制約ルールを実行するのに必要なその他任意のソフトウェアもしくはデータあるいはその両方、あるいはこれら全てに対する呼び出しが挙げられる。
【００２４】
ここで図４を参照すると、制約ルールを生成するために取られる例示的なステップ群の高レベル・フローチャートが提示されている。開始ブロック３００の後、コンピュータ上にユーザ・プロンプトが表示される（ブロック３０５）。このユーザ・プロンプトは、売り手に対し、新しいカタログまたは契約あるいはその両方にバインドされた制約を生成するように促す（照会ブロック３１０）。ブロック３１５に記載されているように、売り手（あるいは、サード・パーティ・サービス）は、ｅコマース環境において売り出される製品を示す新しいカタログを、あるいは既存のカタログ内に新しい商品を、作成することができる。売り手はさらに、上記の新しく追加された商品またはカタログあるいはその両方に対して支払い制約ルール（例えば、上記で図２に記載した制約支払いルール２１５）を関連付け、これらの新しく作成／定義された支払い制約ルールをデータベースに保存することもできる。図２に関連して上述したようなやり方で、上記のようなルールが作成されたら（照会ブロック３２０）、次に支払い制約ルール・データベースが更新されて（ブロック３２５）、プロセスは終了する（終結ブロック３３０）。
【００２５】
ここで図５を参照すると、支払い制約ルールを利用するために取られる例示的なステップ群の高レベル・フローチャートが提示されている。コンピュータ１００（図１）のユーザが、ブラウザ１４６を用いて開始ブロック４００を引き起こし、１つ以上の既定の支払い制約ルールに関連付けられた（言い換えれば、ルールをトリガする）１つ以上の商品を含むｅコマース・システムにアクセスするとよい。ユーザは、カタログ・ユーティリティ１４８（図１）を用いて入手可能な商品を検索し、データベース１３７（同様に、図１に示す）などの仮想ショッピング・カートに商品を入れればよく、それにより当該仮想ショッピング・カートが更新される（ブロック４０５）。買い物客が精算できる状態になっていたら（照会ブロック４１０）、ブロック４１５に示すように、製品マネージャ１４７（図１）などの注文取り込みコンポーネントが、データベース１３７内に関係オブジェクトまたは支払い制約ルールあるいはその両方を生成する。言い換えれば、製品マネージャ１４７は、ユーザが精算できる状態になると（あるいは別の選択肢として、既定の支払い制約ルールに対応する商品をユーザがショッピング・カートに入れるたびに）、データベース１３７内の商品（すなわち、ショッピング・カートに入れられた商品）に対応する関係オブジェクトおよび支払い制約ルールを自動的に生成する。ショッピング・バスケット内の各商品に関連付けられた支払い制約ルールの事前条件が全て満たされていたら（照会ブロック４２０）、次いで適切な支払い制約ルールが優先順位に従って適用される（ブロック４２５）。すなわち、図３の例示的な制約ルール２１６のフィールド２６０に関連して上述したように、異なる支払い制約ルールには異なる優先度レベルがある（例えば、低、中、高）。複数の支払い制約ルールが、同じ製品に対し同じ買い手に関して同時に適用される場合には、より高い／最も高い優先度を有する支払い制約ルールが実行されることになる。該当する支払い制約ルールが全て同じ優先度である場合、無作為に、またはどの制約ルールが買い手に最大の節約を提供するかに従って、あるいはどの制約ルールが売り手に最も高い利益をもたらすかなどに従って、特定の支払い制約ルールが選択される。
【００２６】
注文商品（単数または複数）に対し適切な支払い制約ルールが適用されたら、ブロック４３５に提示されるように、その注文が送信され処理されて（例えば、請求される、発送されるなど）、プロセスは終了する（終結ブロック４４０）。
【００２７】
照会ブロック４１５、４２０および４３０に戻ると、これらの照会のうちいずれかの結果が「いいえ」である（すなわち、制約に関連付けられている注文がない（４１５）、制約付き発注ための事前条件が満たされていない（４２０）、または、制約付き発注のための事後条件の全てが満たされていない（４３０）、あるいはこれら全てである）場合には、その注文は、上述の制約を何も用いずに処理される。
【００２８】
ここで図６を参照すると、本発明の一実施形態による、データベース１３７（図１を参照のこと）に支払い制約ルールを追加する例示的な方法の高レベル論理フローチャートが示されている。コンピュータ１００（図１）のユーザが、カタログにバインドされたまたは契約にバインドされたあるいはその両方である支払い制約ルールを定義するという選択肢を選択したことに応答して、ブロック５００にてプロセスが始まる。ブロック５０５に示すように、製品マネージャ１４７（図１）が、新しい支払い制約ルールの用途に対応するカタログ・カテゴリまたは契約あるいはその両方をデータベース１３７内で検索する。ブロック５１０に示すように、製品マネージャ１４７は、制約ヘルパ１４９（図２）にある情報を使用して、新しい支払い制約ルールに対応する用途または主題あるいはその両方の領域を持つカタログ・カテゴリまたは契約あるいはその両方を探し出すとよい。
【００２９】
ブロック５１５にて、製品マネージャ１４７（図１）は、ユーザが新しい支払い制約ルールに関し有効期限を設けているか否かを判断する。当該支払い制約ルールに有効期限がない場合、プロセスは、ブロック５２５へ進む。ユーザが有効期限を設けている場合（例えば、特売が３０日間有効である場合）、ブロック５２０に示すように、製品マネージャ１４７（図１）は、支払い制約ルールに有効期限を追加する。ブロック５２５に示すように、製品マネージャ１４７が、新しい支払い制約ルールをデータベース１３７に挿入し（すなわち、セーブし）、ブロック５３０にてプロセスは終了する。
【００３０】
ここで図７を参照すると、本発明の一実施形態による、データベース１３７（図１および２）から支払い制約ルールを削除する例示的な方法の高レベル論理フローチャートが示されている。コンピュータ１００（図１）のユーザが、カタログにバインドされたまたは契約にバインドされたあるいはその両方である支払い制約ルールを削除するという選択肢を選択したことに応答して、ブロック６００にてプロセスが始まる。ブロック６０５に示すように、製品マネージャ１４７（図１）が、支払い方法または支払いタイプあるいはその両方に基づいて１つ以上の支払い制約ルールを探し出すべく、データベース１３７に照会する。ブロック６１０に示すように、製品マネージャ１４７は、ＧＵＩ１４３（図１）を用いて、データベース１３７から削除されることになる支払い制約ルールを選択するようにユーザを促す。ブロック６１５に示すように、製品マネージャ１４７が、選択された支払い制約ルールをデータベース１３７から削除し、ブロック６２０にてプロセスは終了する。
【００３１】
ここで図８を見ると、本発明の一実施形態による、データベース１３７（図１）において支払い制約ルールを更新する例示的な方法の高レベル論理フローチャートが示されている。コンピュータ１００（図１）のユーザが、カタログにバインドされたまたは契約にバインドされたあるいはその両方である支払い制約ルールを更新するという選択肢を選択したことに応答して、ブロック７００にてプロセスが始まる。ブロック７０５に示すように、製品マネージャ１４７（図１）が、支払い方法または支払いタイプあるいはその両方に基づいて１つ以上の支払い制約ルールを探し出すべく、データベース１３７に照会する。ブロック７１０に示すように、製品マネージャ１４７は、ＧＵＩ１４３（図１）を用いて、データベース１３７内で更新されることになる支払い制約ルールを選択するようにユーザを促す。ブロック７１５に示すように、製品マネージャ１４７は、選択された支払い制約ルールに対応する１つ以上の支払い方法をデータベース１３７内で探し出す。ブロック７２０に示すように、製品マネージャ１４７が、１つ以上の新しいまたは更新されたあるいはその両方の支払い方法をデータベース１３７に挿入することによって選択された支払い制約ルールを更新し、ブロック７２５にてプロセスは終了する。
【００３２】
本発明の一実施形態は、従って、複雑な支払いポリシを実施するように制約付き支払いを用いる方法を提供する。製品マネージャ１４７（図１）などの支払い取り込みコンポーネントが、第１支払い制約ルールに対応する第１関係オブジェクトを少なくとも生成する。注文商品がデータベース１３７（図１）などのショッピング・カートに入れられており、その注文商品が１つ以上の支払い制約ルールに関連付けられており、さらに、１つ以上の支払い制約ルールに対応する１つ以上の事前条件が満たされていれば、注文取り込みコンポーネントは、上記１つ以上の支払い制約ルールを実行する。１つ以上の支払い制約ルールに対応する１つ以上の事後条件が満たされていれば、注文取り込みコンポーネントは、当該注文商品を含んでいるショッピング・カートから購入注文を送信する。
【００３３】
図面のフローチャートおよびブロック図は、本発明の多様な実施形態によるシステム、方法およびコンピュータ・プログラム製品の、あり得る実装のアーキテクチャ、機能、および動作を示すものであることに留意されたい。この点に関連し、フローチャートまたはブロック図の各ブロックが、明示された論理機能（単数または複数）を実現する１つ以上の実行可能命令を含んだモジュール、セグメント、またはコードの一部となってもよい。さらに、一部の代替的な実装では、ブロックに示された機能が、図面に示された順序から外れて生じ得ることにも留意する必要がある。例えば、関与する機能性次第で、連続して示された２つのブロックが実際にはほぼ同時に実行されることもあり、時にはそれらのブロックが逆の順序で実行されることもある。さらに、ブロック図またはフローチャート説明図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート説明図あるいはその両方の複数ブロックの組み合わせは、明示された機能または作用を実行する特殊用途向けハードウェアベースのシステムによって、あるいは特定用途向けハードウェアとコンピュータ命令との組み合わせによって実現することが可能であることも分かる。
【００３４】
本明細書にて使用される専門用語は、特定の実施形態を説明することを目的としているものに過ぎず、本発明を限定しようとするものではない。本明細書で使用される「１つの」および「その」という単数形は、異なることが文脈によって明確に指示されない限り、複数形をも同様に含めようとするものである。さらに当然のことながら、用語「含む」または「含んでいる」あるいはその両方は、本明細書での使用に当たり、提示される特徴、整数値、ステップ、動作、要素またはコンポーネントあるいはその全ての存在を明示するものであるが、１つ以上のその他の特徴、整数値、ステップ、動作、要素、コンポーネントまたはこれらのグループあるいはその全ての存在を排除するものではない。
【００３５】
以下の請求項における全てのミーンズまたはステップ・プラス・ファンクション要素の対応する構造、材料、作用および同等物は、請求されているその他の要素と組み合わされて特に請求されているように当該機能を果たすあらゆる構造、材料または行為を包含しようとするものである。説明および記述を目的として本発明に関する記載を提示してきたが、網羅的であること、または開示された形態に本発明を限定することは意図されていない。多数の変更および変形が、本発明の範囲および精神から逸脱することなく、当業者に明らかとなるであろう。実施形態は、本発明の原理および実際的応用を最もよく説明するために、加えて他の当業者が、検討される個々の用途に適するように多様な変更を伴った多様な実施形態に向けて本発明を理解できるようにするために、選択され記載されたものである。
【図１】
0005417636.tif 000002
【図２】
0005417636.tif 000003
【図３】
0005417636.tif 000004
【図４】
0005417636.tif 000005
【図５】
0005417636.tif 000006
【図６】
0005417636.tif 000007
【図７】
0005417636.tif 000008
【図８】
0005417636.tif 000009