(57)【要約】コンピュータシステムによって実行可能な小売方法は、リクエストに応答して見込みのある購入者にページを送るステップを含み、上記ページは特定の製品に関連しており、上記方法はさらに、上記製品を固定価格で直接購入するために、上記見込みのある購入者から購入申込を受取るステップを含み、上記購入申込は上記見込みのある購入者に指名された人の識別情報と上記見込みのある購入者によって少なくとも部分的に選択された購入条件情報とを含み、上記指名された人は上記固定価格で上記製品の購入を分担するよう指名される。
2004527059.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムによって実行可能な小売方法であって、
リクエストに応答して見込みのある購入者にページを送るステップを含み、前記ページは特定の製品に関連し、前記小売方法はさらに、
前記製品を固定価格で直接購入するために、前記見込みのある購入者から購入申込を受取るステップを含み、前記購入申込は前記見込みのある購入者に指名された人の識別情報と前記見込みのある購入者によって少なくとも部分的に選択された購入条件情報とを含み、前記指名された人は前記固定価格で前記製品の購入を分担するよう指名される、方法。
【請求項２】
前記指名された人からそれぞれ支払情報を受取るステップと、
前記固定価格で前記製品の支払を行なうために前記支払情報を処理するステップと、
前記購入条件情報に従って前記製品のある場所への配達を手配するステップとをさらに含む、請求項１に記載の方法。
【請求項３】
前記支払情報を受取るステップは、前記指名された人からそれぞれの支払の分担の事前承認を受取るステップを含む、請求項２に記載の方法。
【請求項４】
前記ページを送ることに応答して前記見込みのある購入者からの価格リクエストを受取るステップをさらに含み、前記価格リクエストは前記製品の配達がなされる場所についての場所情報と配達モード情報とを含み、前記方法は
少なくとも部分的に前記場所情報および前記配達モード情報に基づき前記製品の前記固定価格を提示するステップをさらに含む、請求項１または２に記載の方法。
【請求項５】
前記製品は、製造された、処理された、またはその他の物理的に存在する商品を含む、請求項１に記載の方法。
【請求項６】
前記製品はサービスを含む、請求項１に記載の方法。
【請求項７】
前記購入条件情報は複数の分担機構から前記見込みのある購入者が選択した指定分担機構を含む、請求項１に記載の方法。
【請求項８】
前記購入条件は分担機構を含み、前記分担機構は：
ａ）  前記指名された人が均等額を分担する機構、
ｂ）  前記指名された人が前記見込みのある購入者によって選択された不均等な額を分担する機構、または、
ｃ）  前記指名された人が前記指名された人により選ばれた金額を分担する機構のいずれかを含む、請求項１に記載の方法。
【請求項９】
前記見込みのある購入者から前記選択された分担機構に関する分担情報を受取るステップと、
前記分担情報の前記選択された分担機構に対する一貫性を確認するステップと、
前記識別情報にしたがって申込情報を前記指名された人に送るステップとをさらに含み、前記申込情報は前記購入申込へのリンクを含む、請求項８に記載の方法。
【請求項１０】
前記見込みのある購入者は前記指名された人の１人である、請求項１から９のいずれかに記載の方法。
【請求項１１】
コンピュータシステムによって実行可能な小売方法であって、
固定価格で特定の製品を直接購入するために、見込みのある購入者から購入申込を受取るステップを含み、前記購入申込は前記見込みのある購入者が指名した人の識別情報と前記見込みのある購入者によって少なくとも部分的に選択された購入条件情報とを含み、前記指名された人は前記固定価格で前記製品の購入を分担するよう指名される、小売方法。
【請求項１２】
プログラム命令が記憶されているコンピュータ読取可能な記憶装置であって、前記命令はコンピュータによって実行されると、前記コンピュータに請求項１から１１のいずれかの方法を実行させる、記憶装置。
【請求項１３】
小売方法を実行するためのコンピュータシステムであって、
リクエストに応答して見込みのある購入者にページを送るための手段を含み、前記ページは特定の製品に関連し、前記コンピュータシステムはさらに、
前記製品を固定価格で直接購入するために前記見込みのある購入者から購入申込を受取るための手段を含み、前記購入申込は前記見込みのある購入者に指名された人の識別情報と前記見込みのある購入者によって少なくとも部分的に選択される購入条件情報とを含み、前記指名された人は前記固定価格で前記製品の購入を分担するよう指名される、コンピュータシステム。
【請求項１４】
コンピュータシステムによって実行可能な小売購入方法であって、
ページのリクエストに応答して前記コンピュータシステムでページを受取るステップを含み、前記ページは特定の製品に関連し、前記小売購入方法はさらに、
前記コンピュータシステムを用いて前記製品を固定価格で直接購入するための購入申込を作成するステップを含み、前記購入申込は見込みのある購入者に指名された人の識別情報と前記見込みのある購入者によって少なくとも部分的に選択される購入条件情報とを含み、前記指名された人は前記固定価格で前記製品の購入を分担するよう指名され、前記小売購入方法さらに、
前記購入申込を小売業システムに提出するステップを含む、小売購入方法。
【発明の詳細な説明】
【技術分野】
【０００１】
Ａ．発明の分野
本発明は自動化された共同購入の分野にある。特に、インターネットのような電子通信ネットワークを用いて（ギフト券とは対照的に）特定の贈り物に対して贈与金を集めるための、コンピュータによって実現されるシステムおよび方法である。これは共同利用される電子購入またはＰＥＰと呼ばれる。
【背景技術】
【０００２】
Ｂ．発明の背景
人々は贈り物を購入する場合、個別にではなく、共同で行なうことが多々ある。このような購入は誕生日、結婚や婚約、母の日や父の日、定年退職、送別、バルミツヴァおよびバドミツヴァなどの場合に行なわれる。
【０００３】
このような形の購入を行なう理由はさまざまである。たとえば、個々の贈与金を集めることにより、参加者は個別でするよりも高価な贈り物を贈ることができる。時には、各個人は共同の贈り物に参加する行為自体が適切であるまたは望ましいと考える場合もある。たとえば、家族の子供全員が両親に共同で結婚記念日の贈り物をしたいかもしれないし、スポーツチームのメンバー全員が、離れてしまうメンバーにチーム全体からの贈り物をしたいかもしれない。この場合行なわれる協力は、贈り手側の結びつきおよび受け取り側との関係を表わすことができる。人々が共同で贈り物をする場合の他の理由としてはその便利さにある。多くの場合、６人のグループが個別に６個の贈り物を贈るよりも、１つの贈り物をまとめる方が都合がよい。多くの場合、共同で贈り物をする人々は、１つ以上の動機でそのような行為を行なう。
【０００４】
従来の共同購入
従来、団体で求める贈り物はそのグループのメンバーが、実際に店に足を運んである品物を選び、支払い、受取る。
【０００５】
しかし、このような態様で共同の贈り物を購入する場合、人々は多くの問題に直面する。これらの問題は特定の状況に依存するが、以下を含む：
・購入をまとめるために人々が集まるのは、困難または不可能かもしれない（生活の場もしくは職場が互いに離れている、または忙しくて時間が取れない）；
・品物またはサービスを選ぶのに全員に発言の機会がない；
・贈り物を選び受取る負担はグループの小数の人にかかる；
・業者に支払った人はその金額をみんなから回収するのに困難が伴うこともあり得る、たとえば支払が遅れたり（この場合利子などがかかり得る）、または全く回収できないこともある；
・最終的に払いすぎまたは金額不足の人も出てくる；
・業者に支払った人はその支払に伴う報奨プログラム得点を得るが、他の人は何の特典もない。
【０００６】
従来の方法を用いて贈り物を団体で求める場合、業者側はその事業に伴う重要な情報を取り損なうこともある。多くの場合、小売業者はその購入は贈り物であることや、受取人およびその贈り物の購入にかかわった人々を特定することはできない。小売業者にはこの不在の人々を顧客に変える術はない。
【０００７】
１．電子商取引における先行技術
関連する先行技術は３つのグループに分けることができる、すなわち要求統合システム、対個人（Ｐ２Ｐ）支払システム、および供与額累積システムに分けられる。
【０００８】
ａ）  要求統合システム
要求統合システムの一例は特許公報ＷＯ  ００／４５３１８の「オンライン購入リクエストの統合」に記載されている。このシステムは特定の製品の要求を統合し、複数の「小額」購入者が高額のディスカウントを利用できるようにする。これは「購入サイクル」に従って運営され、以下によって構成される：
・サーバがウェブページを載せ、ここには製品を説明している申込およびその製品のさまざまな数量に対する価格表を含む；
・複数の購入者から複数の購入注文を受理および統合する；
・予め定められた基準に従って申込を締切り、一般に売上数量を伸ばし、かつ単価を下げることを目的とする。
【０００９】
このシステムは買手側の単価を下げ、売手側がより多くの注文を受けることを意図している。これは要求統合システムすべてにおける共通の特徴である。しかし、このようなシステムは共同で贈り物を購入したい個人にはほとんどまたは全く関係ない。第１に、これらのシステムは１つの品物の購入またはグループでの少量の品物の購入を促進させるものではない。なぜなら、これは単一の個別の購入注文をなす複数の購入者からの金額の累積よりも、複数の購入注文の統合に関係しているからである。第２に、単価を下げることは団体で贈り物を購入する場合の主要な動機になることはめったにないからである。本発明は特許公報ＷＯ  ００／４５３１８に定められるような「購入サイクル」、または他の要求統合システムに従って働かないのは理解されるであろう。
【００１０】
ｂ）  Ｐ２Ｐ支払システム
先行技術において個人対個人またはＰ２Ｐ支払システムとして知られ、個人間の支払を可能にするために、インターネットを用いたシステムがいくつか開示されている。このようなシステムの１つはwww.paypal.comにある。このシステムを用いて支払を行なうために、個人（提供者）はペイパル口座を開設することによってメンバーとなる。この口座は民間の銀行またはクレジットカードの口座にリンクされている。提供者は友達（受取人）にｅメールを送って、金額はペイパルサイトから集金できることを知らせる。受取人はこのウェブサイトに入り、（まだメンバーになっていない場合は）メンバーとなり、振替金額を受取ることができる。ペイパルシステムはリンクされている提供者および受取人の銀行またはクレジットカード口座間の資金の振替を管理する。類似したシステムはwww.c2it.comおよびpaydirect.comにもある。
【００１１】
このようなシステムを用いて団体で求める贈り物をまとめることができる。グループのあるメンバーがある商品を購入し、他のメンバーにそれぞれの分担額を１つまたは複数のＰ２Ｐ支払システムを用いて支払ってもらうことができる。支払を行なうために、贈り物をする人々は集まる必要がないことを意味する。また、ワールドワイブウェブやｅメールといったインターネットのサービスを用いることにより、各送り主は贈り物の選択に発言権を有し、その贈り物はグループのなかの１人に、または受取り側に直接配達できる。さらに、複数の共同購入者がクレジットカードまたは他の電子支払システムの使用に伴う報奨得点を得ることができる。
【００１２】
しかし、団体で求めた贈り物の支払を調整するために用いられた場合、これらのサービスは共同購入者にとっていくつかの不便なことがある。たとえば：
・従来の方法のように、業者側に支払う人は他の人からの金額の回収に迷惑を被るかもしれない；
・一部の人が間違った金額を支払う可能性もまだある；
・共同購入者は支払うまたは支払を受取る前に、種々のＰ２Ｐ支払システムのメンバーになることが求められる（これは費用や不便性を伴い得る）；
・このシステムは少なくとも２つの別個の段階での完了を必要とする：すなわちベンダーから贈り物を購入すること、および共同購入者間での支払；
・システムでは一般に共同購入者の１人がグループメンバー間の支払を把握していることを必要とする。
【００１３】
顧客がＰ２Ｐ支払システムを使用しても、小売業者側にとって不便な点は解消されない。小売業者側にはその購入が贈り物であることを知る系統だった方法はなく、贈り物の購入にかかわった人を特定することもできない。ここでも、小売業者には不在の人々を顧客に変える術はない。
【００１４】
ｃ）  供与額累積システム
先行技術の最後のグループのシステムは、供与額累積システムとも呼ばれる。これらのシステムはコンピュータを使って共同購入者の申込を登録および累積し、購入を行なう。要求統合システムと違って、供与額累積システムは大量購入環境とは対照に少量で機能する。
【００１５】
このようなシステムのうちの１つは、「入札プーリングでオンラインオークションを行なう方法」と題される米国特許第５，７９４，２１９号に記載されている。この特許は、オンラインオークションでの入札セッションの際にオークション組合の複数のメンバーから付け値を累積する方法を開示している。中央コンピュータは入札グループの登録を調整し、組合の個人からの付け値を組合せる。従来、オークションの入札者は個人的に落札をカバーするのに十分な資金を確保できる場合にしか勝てない。この米国特許第５，７９４，２１９号に記載されている方法は、より小額の累積を可能にすることによってこの不利点を解消している。
【００１６】
残念ながら、このシステムは共同で贈り物をする人には限定された用途でしかない。なぜなら、適する贈り物はオークションで販売に供せられることはあまりないからである。贈り物はオークションの場よりもむしろ一般に小売で購入されるものである。小売販売の場合、価格は一般に売手側によって設定され、通常交渉の余地はないが、オークションの場合、価格は最も高い付け値を示した人によって定められる。米国特許第５，７９４，２１９号に記載されるシステムには、価格が設定されている場合にどのように個々の供与額を累積するのか記載されていない。このような状況下では、共同購入者の合計の供与額は必ず商品の価格を超えず、かつ共同購入者は個々の供与額のそれぞれの割合に満足するようなシステムにすること望まれる。
【００１７】
この分類での第二のシステムは、「共同の贈り物をするために個別の贈り物を累積するためのシステムおよび方法」と題された、Giftcertificates.com社による国際公開ＷＯ  ０１／２９７８７に記載されており、これは本発明に最も近い先行技術であると考えられている。この文献は受取人に贈る、団体で求める贈り物を累積する作業を自動化するシステムを記載し、購入される品目はギフト券、電子小切手、または銀行小切手といった流通証券である。このシステムは、プロモータと呼ばれる人がネットワークを介してソフトウェアアプリケーションにアクセスして「贈り物キャンペーン」を開始することによって作動する。贈り物キャンペーンは、受取り人のためのグループギフトに対する贈与額または供与額を集める目的のために、グループの参加者に連絡を取る作業として定義されている。
【００１８】
プロモータはｅメールアドレスによって可能性のある参加者を特定し、たとえば贈り物キャンペーンの理由（たとえば誕生日）、個別の分担額、および合計ギフト目標を含めたいくつかのファクタを任意に特定する。
【００１９】
最後に、プロモータはこのギフトキャンペーンを終了させるために用いられるトリガイベントを特定しなければならない。このトリガイベントはギフトキャンペーンが終了する特定の日時もしくは日付、または累積額に達するといった別のイベントであると説明されている。ソフトウェアアプリケーションは識別された参加者の各々にｅメールで連絡する。
【００２０】
参加者はユニバーサルリソースロケータ（ＵＲＬ）をクリックすることによって応答し、それによりソフトウェアアプリケーションは参加者が贈与ページを利用できるよう促される。この贈与ページは参加者が個別の贈与額を入力することができるフィールドを含むと説明されている。このフィールドはいくつかの別個の贈与額を有するドロップダウンメニューの形を取ると説明されている。贈与ページはさらに参加者からクレジットカードの情報を受取るよう設計されたフィールドを含む。
【００２１】
トリガイベントが贈り物キャンペーンを終了させ、サービスプロバイダは受取人に提供するためのギフト券を作成する。記載される実施例の１つは、デジタル券の発行にかかわると説明されており、受取人はこれを記載されているシステムを用いるプロバイダと仕事上関係するどのオンラインベンダーでも使うことができる。
【００２２】
このGiftcertificates.comのシステムは、従来の形式の共同購入に伴う特定の問題に対処している。購入をまとめるのに参加者は互いに集まる必要はなく、グループの１人がグループ全体の支払を行なう負担を緩和し、それにより回収上の問題を防ぐ。
【００２３】
残念ながら、このシステムは贈り物をするために共同購入を行なうのに興味を持つ者にとってまだいくつかの不便な点を有する。これらのうちの主な点は、（ギフト券とは対照的に）特定の贈り物の共同購入を管理する方法が提供されていないことである。ギフト券は受取人が自分の欲しい贈り物を選択できるという利点を与えるが、一部の人にとってはあまり私的で熟考の末の贈り物であるとは考えられないという不利点がある。「贈り物販売における隠れた価値」（キャリーＡ．ジョンソン，２００１年５月）と題されたフォレスターリサーチ（Forrester Research）が行なった調査によると、オンラインでギフト券を購入した人は顧客のたった５％しかいない。消費者の２７％は、一般にギフト券を贈らないので、オンラインでギフト券を購入していない。
【００２４】
消費者はギフト券に対する資金を出しあって、集められたお金で特定の贈り物を選ぶことができる。しかし、これは２段階のプロセスとなり、幾分不便である。
【００２５】
ギフト券の購入は、価格が売手側によって設定されていないという点で、オークションでの購入に似ている。価格は個々の供与額を加算することにより定められる。上記のように、価格が設定された場合、贈り物の共同購入者は余分なお金が業者側に支払われないようにすることに関心を持っている。したがって、コンピュータシステムは選択された商品の価格に到達するよう、供与額を調整することが望ましい。ギフト券が選択された場合、そのギフトの合計金額はそのセールには重要ではない。累積額に対応するギフト券は指定された期限となればいつでも発行できる。さらに、トリガイベントが合計金額として設定されている場合、供与額の合計がこの金額を超えたかどうかは重要ではない。なぜなら、超えた分は受取人に送られるのであり、受取人はそれをギフトのために使うことができる。ギフト券を決済するのにギフトの受取人が後で特定のギフトを選ぶような場合、購入した商品の価格を超えてなされた供与額は何らかの方法で処理されなければならない。逆に、特定の贈り物を共同で購入する場合、商品の価格に到達しなかったときの参加者による供与額を処理する何らか方法がなければならない。たとえば、ある贈り物は１００ドルするが、共同購入者間でたった８０ドルしか集められなかったのでギフトキャンペーンが不首尾に終わった場合、８０ドルを該当する人々に戻す方法、またはこのような状況で振替が行われないようにする方法がなければならない。残念ながら、特許公報ＷＯ  ０１／２９７８７に記載されているシステムは、このような問題に対処していない。
【００２６】
多くの場合、購入者は購入を完了させるだけでなく、個々の供与額のそれぞれの割合に満足することに関心がある。共同購入者によっては均一な額を支払いたいかもしれない。代わりに、一部の人は、贈り物の受取人とのより近い関係などによって、または資金的余裕があって、他の人よりも多くの金額を支払いたいかもしれない。Giftcertificates.comシステムはこのような態様で購入者を支援する機構を提供していない。
【００２７】
本明細書において言及している先行技術は、その先行技術がオーストラリアで共通の一般的知識の一部をなすことを認めるまたは示唆しているものだと取られるべきではない。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
Ｃ．発明の概要
合計額がベンダーによって設定される特定の贈り物についての少量の共同購入を調整するためのシステムが必要であり、このシステムでは：
・購入をまとめるのに、共同購入者は集まる必要がない；
・各共同購入者が贈り物の選択に対して発言権を有することを支援する；
・グループの１人が全員のために業者に支払う必要がなく、誰も他の人の回収に難儀することがないようにする；
・各自が正確なまたは同意した額を支払うようにする；
・各共同購入者は自分の供与額に関連した報奨プログラム得点を得ることを確実にする；
・使用する前にシステムの会員資格を求めない；
・共同購入が１段階で行なわれることを可能にする；
・グループメンバーによるまたはグループメンバー間の支払を自動的に把握する；
・合計の供与額が贈り物の価格を超えないようにする；
・購入が首尾よくいったと判断されるまで、金額の振替が購入者からベンダーに行なわれないようにする；
・全体の購入に対して共同購入者が適切な割合を支払うことを支援する；
・申し込みの購入は贈り物であることをベンダーに特定させ、その購入に参加する人を特定することを支援する。
【００２９】
本発明の実施例は上記の特徴を１つ以上提供することを目的とする。
【００３０】
好都合に、ベンダーが購入するものが贈り物であることを知ることができれば、パッケージにお祝いの項目を含めることができるし、贈り物が発送される際に挨拶状およびその事業または製品についての情報を含めることができる。したがって、ベンダーの市場での潜在的顧客を特定する困難かつ費用のかかる作業、および販売促進のための品目や情報を発送する作業は、顧客側の時間および費用で行なわれる。さらに、ベンダーは贈り物を呼びかけたコーディネータに対して将来の購入に対して割引を与える、または他のインセンティブを与えることによって報いることができる。これはさらに他の購入（贈り物または非贈り物）を奨励するのに役立つ。最後に、本発明の一実施例において、参加者はベンダーのウェブサイトに入って自分のクレジットカードの詳細を提示することにより、参加する同意を表明する。これにより、ベンダーには将来さらに他の購入を奨励させることになる情報（たとえば、特売品、販売促進材料など）をこれらの潜在的顧客に与える機会がもたらされる。
【課題を解決するための手段】
【００３１】
本発明はコンピュータシステムによって実行可能な小売方法を提供する。この方法は、
リクエストに応答して見込みのある購入者にページを送るステップを含む。上記ページは特定の製品に関連している。上記小売方法はさらに、
上記製品を固定価格で直接購入するために、上記見込みのある購入者から購入申込を受取るステップを含む。この購入申込は見込みのある購入者に指名された人の識別情報と、見込みのある購入者によって少なくとも部分的に選択された購入条件情報とを含み、上記指名された人は上記固定価格で上記製品の購入に寄与するよう指名されている。
【００３２】
本発明は小売方法を実行するためのコンピュータシステムを提供する。このコンピュータシステムは、
リクエストに応答して見込みのある購入者にページを送るための手段を含む。上記ページは特定の製品に関連している。
【００３３】
上記コンピュータシステムはさらに、固定価格で上記製品を直接購入するために、上記見込みのある購入者から購入申込を受取るための手段を含む。この購入申込は見込みのある購入者が指名した人の識別情報と、見込みのある購入者によって少なくとも一部選択された購入条件情報とを含む。上記指名された人は上記固定価格で上記製品の購入を分担するよう指名されている。
【００３４】
本発明はさらにコンピュータシステムによって実行可能な小売購入方法を提供する。この方法は、
リクエストに応答してページを上記コンピュータシステムで受取るステップを含む。上記ページは特定の製品に関連している。
【００３５】
この方法はさらに、
上記コンピュータシステムを用いて固定価格で上記製品を直接購入するための購入申込を作成するステップを含む。この購入申込は見込みのある購入者が指名した人の識別情報と、見込みのある購入者によって少なくとも一部選択された購入条件情報とを含む。
【００３６】
この方法はさらに、
上記購入申込を小売業者システムに提出するステップを含む。
【００３７】
本発明はさらにコンピュータシステムによって実行可能な小売方法を提供する。この方法は、
固定価格で特定製品を直接購入するために、見込みのある購入者から購入申込を受取るステップを含む。購入申込は見込みのある購入者が指名した人の識別情報と、見込みのある購入者によって少なくとも一部選択された購入条件情報とを含む。
【００３８】
本発明はさらにプログラム命令が記憶されているコンピュータ読取可能な記憶装置を提供する。プログラム命令はコンピュータによって実行されると、コンピュータに上記方法のステップを実行させる。本発明はさらに上記方法のステップを行なうためのコンピュータソフトウェアを提供する。
【００３９】
本発明は一般にユーザシステムおよび１つ以上のクライアントシステムを用いて共同利用される電子購入のためのシステムおよび方法に関する。本発明は従来の方法を用いた場合に、ならびに既知の要求統合システムおよび寄与額蓄積システムにおいて直面する、共同で特定の贈り物を購入するのに関連する問題を以下によって対処または改善する：
・特定の品目を一つまたは複数選択し、その価格は顧客（コーディネータと呼ぶ）が指定した配達情報を用いてベンダーによって設定される；
・単一の申込注文の一部として、特定の期間および条件（購入条件）に基づいて１つ以上の選択された品目を購入するために、（論理的に一致する）継続申込（ＰＥＰ申込として知られる）をサーバシステムにインタラクティブに作成する；
・サーバシステムによって固有の識別子をそのＰＥＰ申込に割当てる；
・ＰＥＰ申込を１つ以上のクライアントシステムを用いる複数の潜在的参加者（参加指名者）に通信する；
・サーバシステムによって参加指名者の応答を自動的に評価および管理し、それにより応答がＰＥＰ申込の条件と一致するようになる；
・ＰＥＰ申込の条件が満たされた場合に、購入を完了させ、条件が満たされなかった場合に申込を終了させる。
【００４０】
本発明の好ましい実施例において、顧客はサーバシステムと対話形式で、購入条件を定めることができ、それにより正しい金額が集められ（すなわち金額の過不足なく）、参加者は種々の供与方法を用いることにより全体額に対して適当な金額を分担する。
【００４１】
本発明の実施例では、購入条件が満たされるのを妨げる論理的エラーをチェックするさまざまな評価機構を用いる。論理的に一致しない購入条件は続行することが許されず、システムは論理的な不備を取除くよう顧客を支援する。
【００４２】
本発明は各参加指名者が購入を行なう前に提案されている購入項目を見て承認する機会を与え、その承諾内容が購入条件と一致するようにする。
【００４３】
好ましい実施例では参加者は自分のクライアントシステムを用いることにより、個々の支払を分担することを可能にし、購入条件に従って十分の人数が品目を購入することを委ねるまで、顧客からベンダーへの金額の振替を遅らせる。
【００４４】
ある実施例では、一連のアルゴリズムを用いることによりＰＥＰ申込の進行が評価され、アルゴリズムは購入条件が、完全に満たされた、不首尾に終わった、または成功しないかどうか特定できる。最後に、注文の管理を調整し、購入されると品目の配達を支援する。
【００４５】
本発明の実施は一般にソフトウェアで実現され、自社の製品またはサービスを販売するために作成された電子商取引ポータルを既に有する小売業者のサーバシステムにインストールされる。したがって、この局面における本発明の実施は小売業者のサーバシステムで行なわれる。本発明の別の局面において、ソフトウェアは小売業者のものではないサーバシステムにインストールされて実行されてもよい。他の局面において、本発明のパフォーマンスは購入者によって実行される購入ステップにあり、（ここではコーディネータ、見込みのある購入者、または申込み元とも呼ばれる）購入者は、小売業者のサーバとインターフェイスして共同利用される購入を行なう。購入者に購入申込を作成させ得るソフトウェアはサーバシステムに存在するが、サーバとの購入者のコンピュータシステムの包括的相互作用はそのソフトウェアによって実行され、可能化される。
【発明を実施するための最良の形態】
【００４６】
Ｄ．発明の詳細な説明
１．ネットワーク環境
図１は本発明に特に適するあるネットワーク環境の機能ブロック図である。図面にはベンダーのシステム１０１が示され、広く世界的に共同利用される電子購入サービスが提供される。ベンダーシステムは本発明に必要な情報を管理および処理するのを担うサーバアーキテクチャ１０６からなる。さらに、ウェブサイト１０２を含み、これはベンダーの一般のｅコマースページ１０５および本発明に関連するページ１０９を含む。サーバシステムにはさらにつぎの３つのデータベースがある：
（ｉ）  在庫データベース１０３であって、このデータベースは、在庫の量や注文要件についての情報を含み、特定の品目を特定の顧客注文に割当てることができる；
（ii）  ＰＥＰ申込データベース１０７であって、このデータベースは、各ＰＥＰ申込に関する非金融情報を含み、これは参加指名者の詳細、購入条件、管理的詳細、および参加指名者の応答記録を含む；
（iii）  支払データベースであって、このデータベースは、クレジットカードや他の詳細（以下参照）１１０を含み得る。
【００４７】
情報を維持するためにベンダーシステム１０１で使用できるデータベースシステムの一例として、マイクロソフト社のAccess7.0/2002またはオラクル社のOracle(R)9iを含む。このようなデータベースに含まれる情報は、マイクロソフト社のＡＳＰ、Alliare社のColdfusion（Ｒ）といったサーバー側のスクリプト言語を用いて作成されたソフトウェアアプリケーションによって操作される。ベンダーシステム１０１は図示されているものよりも複雑であり得る（たとえば、データベースは多くのサーバ間で分配されてもよい）。代替的に、図示されているものよりも簡単であってもよい（たとえば、３つの別個のデータベースを１つのシステムに組合わせることができる）。
【００４８】
図１において、２人の顧客、すなわちコーディネータ（ＰＥＰを開始した人）および参加指名者はそれぞれのクライアントシステム（１０４および１０８）を用いて通信ネットワークを介してベンダーのウェブサイト１０２にアクセスする。ここには２人の顧客しか図示されていないが、共同利用される電子購入に参加できる顧客の数には制限がない。
【００４９】
本発明は多くの異なる種類の通信ネットワークを使用することができる。たとえば、専用のワイドエリアネットワーク（ＷＡＮ）またはインターネットのような公共のＷＡＮを用いてもよい。これらのネットワークは典型的にハイパーテキストトランスファープロトコル（ＨＴＴＰ）、拡張可能マークアップ言語（ＸＭＬ）、ボイスオーバーインターネットプロトコル（ＶｏｌＰ）およびインターネットプロトコル／トランスファーコントロールプロトコル（ＴＣＰ／ＩＰ）のようなさまざまなプロトコルを用いて、遠隔のコンピュータシステム間で情報を転送することができ、多くの場合これはワールドワイドウェブおよびｅメールといったサービスの使用を介する。
【００５０】
本発明はさらにモバイル用グローバルシステム（ＧＳＭ）、コード分割多重アクセス（ＣＤＭＡ）または時分割多重アクセス技術を含めた無線ネットワークおよび無線アプリケーションプロトコル（ＷＡＰ）を使用することができる。本システムおよび方法はこのような通信ネットワークのいずれか、または組合せを使用することができる。したがって、クライアントシステム（１０４および１０８）はパーソナルコンピュータシステムとして示されるが、携帯情報端末（パームパイロット、ハンドスプリングバイザーズなど）や携帯電話などを含めて、通信ネットワークでインターフェイスすることができる電子装置ならどのようなものでも用いることができる。
【００５１】
クライアントシステムがパーソナルコンピュータの場合、このシステムはサーバシステムによって送られるハイパーテキストマークアップ言語（ＨＴＭＬ）文書を表示するために用いることができる、ネットスケープ(Netscape)（Ｒ）によるナビゲータ６．０（Ｒ）またはマイクロソフト社のインターネットエクスプローラのようなウェブブラウザを含んでもよい。このようなブラウザはジャバスクリプト（Java(R)script）やＶＢスクリプトといったクライアント側のスクリプト言語を用いて、クライアントマシン上のユーザエラーを捕らえ、サーバに送り返す前にクライアントの文書を操作することができる。これはサーバ側のスクリプトのみに依拠する場合よりも効率が良い。ベンダーシステムはＵＲＬによって識別されるウェブサイトのウェブページをアクセスするためのＨＴＴＰリクエストを受取り、それに応答してクライアントシステムにウェブページを提供する。情報の分配はマイクロソフト社のＡＳＰやAllaire社のColdfusion（Ｒ）といったサーバ側のスクリプト言語を使用することによって制御される。コーディネータ、参加指名者、および（後で）参加者は、（以下で説明される）個人応答ページおよび状態ページといった、ベンダーのウェブサイトのＰＥＰ関連ページ１０９を介して、在庫データベース１０３およびＰＥＰ申込データベース１０７に含まれる情報の特定の部分にアクセスできる。この情報はパスワードによって保護されてもよい。
【００５２】
本発明はＰＥＰ申込が完了し、商品やサービスが共同で購入される場合に、顧客からベンダーへの金額の振替を管理する。本発明を用いて行なわれる金額の振替は、クレジットカード、デビットカード、チャージカード、スマートカード、デジタルまたは電子マネー、小切手を含めた多様な電子支払システムを用いて行なうことができる。しかし、便宜上、本発明は事例としてクレジットおよびチャージカード支払システムを用いて説明される。したがって、図１はコーディネータ１０４および参加指名者１０８からベンダー１０１への金額の振替を管理するのに使用することができるいくつかのシステムを示す。これらのシステムはコーディネータの銀行システム１１１、参加指名者の銀行システム１１４、ベンダーの獲得銀行システム１１３、およびゲートウェイシステム１１２を含む。これらの構成要素の各々の機能は後の項目６の「支払管理」と題される箇所でより詳細に説明される。
【００５３】
代替の実施例において、本発明はベンダーのシステムとは別のサーバを介して行なうことができる。この場合、上記のサーバ１０６のＰＥＰ機能性は、ＰＥＰ関連ページ１０９を提供する別のＰＥＰサーバ（図示されていない）によって取扱われる。さらに、支払データベース１１０およびＰＥＰ申込データベース１０７はＰＥＰサーバと直接インターフェイスし、これはベンダーシステム１０１とインターフェイスする。この実施例では、ＰＥＰサーバは参加者からの支払を実行するためにゲートウェイシステム１１２とインターフェイスする。ＰＥＰサーバは（必要なら）発送情報をベンダーシステム１０１に送り、手数料または均一料金を差し引いた購入価格をベンダーに支払う。この実施例のその他の態様については、図１に示されかつ図１に関連して説明される実施例と同様に働く。
【００５４】
２．概要
図２はプロセスの全体を示す簡略フロー図である。このプロセスは、コーディネータがベンダーのウェブサイトを訪れ、共同で購入するべき特定の項目を選択し、ＰＥＰ申込２０１を作成するという意思表示を行うと始まる。ＰＥＰ申込は共同で特定の項目を購入する継続申込である。このような品目は何らかの商品またはサービスであり、その価格は参加者ではなくベンダーによって設定される。
【００５５】
図３はプロセス２０１のこの部分において、ベンダーのサーバシステムによってコーディネータのクライアントシステムに送られるウェブページの一例を示す。項目の簡単な説明３０１、項目の詳細な説明３０５、および従来の「ショッピングカート」購入３０２を始めるオプションがある。顧客は専用のボタン３０３をクリックすることにより「共同利用される電子購入」を開始させる。コーディネータが本発明の説明を得ることができるボタン３０４が設けられてもよい。当業者ならウェブページでのこのようなボタンの使用については慣れており、種々の部分は省略または再配置またはさまざまな態様で適合できることは理解されるであろう。
【００５６】
該当するオプション３０３をクリックすることによって本発明にアクセスするコーディネータはショッピングカート型ウェブページに案内され、コーディネータは選択を確認する機会が与えられる、またはショッピングを続行する機会が与えられる。このようなウェブページは従来のショッピングカート技術を用いるので、ここには記載されない。
【００５７】
コーディネータは自分が選択した項目に満足すれば、ＰＥＰ申込で続行する意図を示す。サーバシステム１０６（または代替的に別のＰＥＰサーバ）はこの潜在的ＰＥＰ申込に一時的なコードを割当て、コーディネータはステップ２０２でいくつかの質問がなされて購入条件を作成する。この実施例では、購入条件は各参加指名者に対して分担をお願いする額などを含めた詳細や受取人の名前、出荷情報などといった管理的詳細を含む。図４は本発明の一実施例に従いコーディネータが購入条件を確立するのを支援するプロセスを示すフロー図である。図５Ａ、図５Ｂおよび図５Ｃはステップ２０２でコーディネータのクライアントシステム１０４によってダウンロードできるウェブページを示す簡単なブロック図である。
【００５８】
サーバシステムは一連のアルゴリズムを用いて購入条件が論理的に一致しているかどうかをステップ２０３でチェックする。条件が満たされた場合に購入が得られるのなら、購入条件は論理的に一致している。逆に、条件が満たされても購入が得られない場合、購入条件は論理的に一致していない。ベンダーシステムは実際に進行する前に購入条件が論理的に一致しているようにすることが望ましい。これにより、参加指名者およびベンダーのシステムは、贈り物の購入をもたらすことができないようなＰＥＰ申込に応答する時間およびリソースを無駄にしないようにする。購入条件が論理的に一致していない場合（２０３＝ノー）、サーバシステムはステップ２０２においてコーディネータに再入力することを求め、このプロセスを支援し得る。購入条件が論理的に一致している場合（２０３＝イエス）、ＰＥＰ申込に固有の識別子が割当てられ、該当するデータベース１０７に記憶され（図示されていない）、プロセスはステップ２０５に進む。図６Ａ、図６Ｂおよび図６Ｃに示される、購入条件の論理的一致をチェックするのに用いられるアルゴリズムはセクション３（ｄ）でより詳細に説明される。
【００５９】
ＰＥＰ申込がステップ２０４においてコーディネータが指名した参加指名者に公開されるとプロセスは進行する。購入の状況に応じて、ＰＥＰ申込は参加指名者に直接または間接的に公開される。購入が知らない者同士の場合（たとえば救済媒体により慈善目的のための装置の購入のような場合）、ＰＥＰ申込は印刷物やインターネット上の広告のような間接的販売取引方法で公開され得る。購入が友人間で行なわれる場合、ＰＥＰ申込は参加指名者に直接、たとえばｅメールまたはＳＭＳ（ショートメッセージサービス）テキストによってＧＳＭ、ＣＤＭＡまたはＴＤＭＡといった技術を用いてセル式電話にて公開される。
【００６０】
参加指名者はＰＥＰ申込に応答し、サーバシステムは詳細継続評価をステップ２０８で記憶する。ＰＥＰ申込がステップ２０５でｅメールによって参加指名者に連絡されている場合、参加指名者はｅメールに挿入されている、サーバシステム上の固有の個人応答ページへのハイパーリンクをクリックすることによって応答することができる。この個人応答ページは各参加指名者に示された購入条件を説明し、これらの条件に同意することをお願いする。図８Ａ、図８Ｂおよび図８Ｃは本発明の一実施例における考えられる個人応答ページの例を示し、これらの図は以下のセクション４でより詳細に説明される。
【００６１】
大まかに言えば、参加を希望する指名者（参加者となる）は同意を表明し、自分のクレジットカードや他の電子支払システム詳細を呈示する。これらの詳細はステップ２０８において、ベンダーによって、または第三者およびベンダーによって記憶される。参加者によって呈示された承諾内容が購入条件に一致する、またはその範囲内にあることをサーバシステムが確実にする必要がある。図９はプロセスのこの部分で目標額を達成するのに用いられる支払承諾ページの一例を示し、後で説明される。
【００６２】
サーバシステムは一連の監視アルゴリズムを用いて参加指名者の応答および未応答を評価する。本発明の好ましい実施例において、これは続けて行われる処理ではなく、たとえば新たな参加指名者からの応答、または日付変更といった定期的な事象で行なわれる。図１０Ａ、図１０Ｂおよび図１０Ｃにおいて詳細に示されるアルゴリズムは、コーディネータが選択する分担方法に応じて変わる。その主な目的はＰＥＰ申込の条件が満たされたかどうかを判断するものであるが、そのＰＥＰ申込が参加者に対して最適化され、適切な時期に終了するよう設計されている。これらの概念は後のセクション５でより詳細に説明される。
【００６３】
ＰＥＰ申込の条件が満たされていない場合（２０７＝ノー）、かつ満たされる可能性がない場合（２０６＝ノー）、ＰＥＰ申込はステップ２０６において締切日にまたは締切日前に終了する（コーディネータが申込を延長するまたは同じ方向で別の申込をやり直すオプションもあり得る）。参加者は状態ページをサーバシステムからダウンロードすることにより、プロセスのどの段階でも進行をチェックすることができる。
【００６４】
ＰＥＰ申込の条件が満たされた場合（２０７＝イエス）、かつ参加者に対して条件が最適化された（２１２＝イエス）場合、ステップ２１１で確認ｅメールが参加者に送られ、ステップ２１０でベンダーへの金額振替が行われる。本発明において、ベンダーが顧客によって提供される支払詳細を記憶および処理する方法ならびに取られる注文の進行方法にはいくつかある。ベンダーは、クレジットカード向けの標準の「リアルタイム」承認プロシージャが用いられる場合に潜在的に起こり得るいくつかの問題に対処する必要がある。参加指名者が自分の詳細を呈示すると直ちに参加指名者のクレジットカードに勘定がつけられる場合、購入条件がステップ２０５において締切日までに満たされないときにはこの金額は払い戻されなければならない。参加指名者のクレジットカードがステップ２１１において購入条件が満たされるまで勘定につけられないのなら、たとえば参加指名者のクレジットの上限額がその時点で超えてしまった、またはクレジットカードの有効期限が切れたことなどの理由により、承認が参加指名者の銀行によって保留にされる可能性がある。本発明の好ましい実施例では、金額の振替は直接のデビット事前承認支払の機構を用いて行なわれる。これにより、ＰＥＰ申込の完了（成功するまたはその他）までの間、ベンダ−は各参加者のクレジットの上限に対して特定の額を「仮押え」することを可能にする。ＰＥＰ申込が首尾よく完了すれば、ステップ２０１において金額の振替が行なわれる。ＰＥＰ申込がステップ２０５において首尾よく完了しなければ、クレジットカードにはチャージされず、仮押えは解除される。これは上述の潜在的な問題を回避する。
【００６５】
一旦金額の振替が行なわれると、選択された品目はステップ２０９において自動的に配達される。このステップは後のセクション７においてより詳細に説明される。
【００６６】
３．項目条件の確立
図４は論理的な購入条件を対話形式で作成するのを支援するプロセスを示すフロー図である。この技術に慣れているものは、図４に示されるプロセスはサーバシステムの１つ以上のステップによって行なわれることは理解できるであろう。さらに、１つの例外を除き、この段階でサーバシステムが得た情報は図示されているものと異なる順序で得ることができる。
【００６７】
以下に説明する実施例では、サーバシステムはコーディネータのクライアントシステムに４つの異なるウェブページを送ることにより、コーディネータが購入条件を確立する支援をする。これらのページの内容はプロセスの際コーディネータが行なう種々の選択に依存する。
【００６８】
ａ）  管理的詳細
プロセスのこの段階でコーディネータに送られる第１のページはステップ４０１での管理的詳細を顕在化させている。購入の合計費用はこのステップを完了するまでに確定していなければならない。合計費用は選択した項目の価格だけではなく、関連する税金および関税、配達料、挨拶状および包装経費をも含む。合計費用を確定することにより、参加者間での購入を正しく分割することができる。したがって、以下の内容を確定する必要がある：
ｉ）  配達する住所；
ii）  前回の配達日、または配達方法（翌日配達、通常配達、または出向いて受取るなど）：
iii）  贈り物にカードをつけて送るかどうか、さらに（任意に）カードの選択；
iv）  包装が必要である場合、その包装の選択および経費。
【００６９】
サーバシステムは種々の配達経費、税金、および特定の地域、郡、州または国への発送に関連する関税についての情報を有するデータベースを備えていることは望ましい。追加費用は自動的に合計額に加算できる。しかし、この情報は容易に入手できないかもしれないし、最新の情報を保つのは困難かもしれない。ベンダーシステムが（望ましくは）即刻この情報をアクセスすることができないのなら、２つの選択肢がある。第１のものは、追加料金としての未定の料金を支払うために、コーディネータから個人的保証を取ることに関わる。第２の選択肢はこのような情報が入手できるまで待つことである。
【００７０】
上記の情報に加えて、サーバシステムはコーディネータから任意に次の情報を求めることができる：
ｖ）  行事の詳細（すなわち、誕生日、クリスマス、結婚など）；
vi）  参加指名者の応答に対する締切日；
vii）  状態ページがパスワードで保護されるべきか、そしてもしそうならそのパスワード；
viii）  最終的受取人の名前。
【００７１】
この情報はすべて従来のウェブに基づくノウハウを用いることによって入手できるので、このページはここに記載または示されない。
【００７２】
ｂ）  分担方法
価格の総額が確定すれば、サーバシステムはステップ４０２で第２のページをコーディネータに送ることにより、どの分担方法が好ましいかを定める。分担方法とは、参加者間で正確な購入金額を分ける方法である。本発明の好ましい実施例では、３つの異なる分担方法がある。これらの方法は次の支払を可能にする：
ｉ）  均等分担（ステップ４０３）。この場合、参加者が２人なら半分ずつ支払い、３人なら３分の１ずつ支払い、４人なら４分の１ずつ支払う、など：
ii）  コーディネータが指定する不均等な額（ステップ４０４）。個々の分担額はどのような額であってもよいが、合計して総金額にならなければならない。たとえば、８０ドルの品目に対して参加者Ａ、ＢおよびＣはそれぞれ４０ドル、２０ドルおよび２０ドルの支払、または４０ドル、２５ドルおよび１５ドルの支払が求められるかもしれない：
iii）  参加指名者が選択した不均等な額（ステップ４０５）：各参加指名者は分担したい額を自由に定めることができる。本発明の一実施例において、ＰＥＰ申込は必要な額が集められると首尾よく終了する。
【００７３】
ベンダーシステムはコーディネータが個々の分担額を設定するのを支援するために、これらの分担方法を用いることができ、同時に分担額が合計購入金額になるようにする。
【００７４】
（ｉ）  均等分担額
コーディネータがステップ４０３において参加指名者に均等額を分担することを求めるよう指定すれば、コーディネータはステップ４０６において購入に何人が参加するかと聞かれる。この情報は各参加者が最終的に負担するべき額（またはある範囲の金額）を定めることとなる。コーディネータは参加者数として、ある人数、最大人数、最少人数、または最大および最少人数を指定することができる。参加者の人数を設定した場合、サーバシステムは前もって参加者の分担額の正確な金額を計算することができる。コーディネータが参加者の最少人数、最大人数、または最少および最大人数を指定した場合、サーバシステムは参加者が支払うことになるある範囲の金額を計算する。
【００７５】
次に、コーディネータはステップ４０６で参加指名者の連絡先の詳細を入力することが求められる。詳細は氏名、ｅメールアドレス、または携帯電話番号を含み得る。携帯電話番号は携帯電話を介してＳＭＳテキストを用いて参加指名者に連絡するために、サーバシステムによって用いられ得る。最初、この情報は参加指名者がコーディネータの呼びかけを受取るのに必要である。
【００７６】
好ましい実施例において、サーバシステムはステップ４１２でこれらの参加指名者の代わりの人（すなわち入替え）を指名してもよいか、または後日さらに他の人を購入に参加するよう加えてもよいかどうか聞いてくる。
【００７７】
サーバシステムは必ず購入条件が内部的に一致しているようにしなければならない。たとえば、ステップ４０６において最少人数５人の参加指名者が均等額を分担することが求められた場合、コーディネータはステップ４１２において少なくとも５人の参加者を指名していなければならない、またはステップ４１２において後で参加指名者の追加を認めていなければならない。サーバシステムはステップ４１２において該当する論理評価アルゴリズムを用いて購入条件を評価する。このアルゴリズムは図６Ａで詳細に示され、後で説明する。
【００７８】
購入条件が論理的に一致しているのなら、コーディネータはステップ４２２でこれらを承認する。
【００７９】
図５Ａは一実施例においてコーディネータに送ることができるウェブページを示す。サーバシステムがコーディネータの個人的詳細および連絡先の詳細を確定させるエレメント（フィールド５０１、５０２、５０３および５０４）を含む。サービスシステムは次にコーディネータ自身が参加者となるかどうか聞いてくる（５０５および５０６）。適する無線ボタン５０６を選択することにより、コーディネータは次の段階５０７で自分の名前を入力する必要はない。コーディネータは各参加指名者の名前５１３、名字５１４、およびｅメールアドレス５１５を入力する。図示される実施例では、サーバシステムはコーディネータが５１６で「追加」ボタンをクリックすると、顧客側のスクリプト（たとえばジャバ（Ｒ）スクリプトまたはＶＢスクリプト）を用いて入力情報を下の入力ボックス５１７に移すことができる。コーディネータは「編集」ボタン５１８を選択することにより、情報の誤りを修正することができる。コーディネータの気が変われば、５１９にて参加指名者を削除することができる。コーディネータはアドレスブックを見るオプション５２０も与えられる。このオプションは後のセクションiii（ｃ）で詳細に説明される。さらに、代わりの人（５２１および５２２）や参加指名者を追加する（５２３および５２４）というオプションもある。起こり得る質問に対する答えを求めるオプション５２６および最初のページに戻るオプション５２５、または次に進むオプション５２７などがある。当業者なら無線ボタンおよびクライアント側のスクリプトの使用についてはよく知っているであろう。
【００８０】
（ii）  コーディネータが指定する不均等な額
ステップ４０４でコーディネータが指定した金額を参加指名者が分担するような場合、参加者はステップ４０７で参加指名者連絡先情報を入力することが求められる。これを入力するいくつかの方法は後のセクション３（ｃ）で説明される。
【００８１】
コーディネータはステップ４０７で各参加指名者が支払うべき額を入力する。
【００８２】
コーディネータは４１３にて指名参加者が後で代わりの人を立てることができるかどうか聞かれる。この分担方法では、新たな参加指名者を追加することができるが、この場合個々の分担額は価格の総額にならなければならない。これは追加の参加指名者間で元の分担額を（たとえば）分けることによって達成できる。しかし、ここでは便宜上，図４に示される唯一のオプションは参加指名者の代わりを立てるオプションであり、この新しい参加指名者はステップ４１３で代わりをなす指名者に対して指定された額を支払う。これははるかに簡単なオプションである。
【００８３】
各参加指名者が支払う金額の総額は価格の総額と合わなければならず、これはステップ４１７において評価アルゴリズムによって確認される。このアルゴリズムは図６Ｂで詳細に示される。購入条件がこのアルゴリズムによって評価および承認されると、コーディネータはステップ４２２において購入条件を承認する。
【００８４】
図５Ｂは本発明の一実施例において、コーディネータに送られ得るウェブページを示す。図５Ａと同様に、このページは、サーバシステムがコーディネータの個人および連絡先詳細を確定できるようにするエレメント（フィールド５２８、５２９、５３０および５３１）を含む。コーディネータは自分が参加者となるかどうか尋ねられる（５３２および５３３）。適切な無線ボタン５３３を選択することにより、コーディネータは次の段階５３４で自分の名前を入力する必要はない。コーディネータは次に各参加指名者の名前５３５、名字５３６およびｅメールアドレス５３７を入力する。図５Ａとは対照に、コーディネータはさらに各指名参加者５３８に対する個人分担額を入力することが求められる。サーバシステムはコーディネータが「追加」ボタン５３９をクリックすると、入力情報を下の入力ボックス５４０に移す。加えた情報に誤りがある場合、コーディネータは「編集」ボタン５４２を選択することにより訂正することができる。ＰＥＰ申込を作成している間にコーディネータの気が変わった場合、５４３にて参加指名者を削除することができる。このオプションは下で詳細に説明される。コーディネータはさらに自分のアドレスブックを見るオプション５４４も与えられる。入力された個人分担額５３８が加算されてウェブページ５４１に表示してもよく、できたら価格の総額との比較が示されてもよい。呈示した金額の合計が価格の総額と合うかどうかコーディネータが確定できないのなら、コーディネータはサーバシステムに代わりの分担額５４５を呈示してもらうことを選ぶこともできる。代わりの参加指名者のオプション（５４６および５４７）、起こり得る質問に対する答えを求めるオプション５４９、および最初のページに戻るオプション５４８またはつぎに進むオプション５５０もある。
【００８５】
（iii）  参加指名者が選ぶ不定額
参加者は自分で選んで分担額を決めることを求められる場合４０５、コーディネータは参加指名者の連絡先情報４０８を入力することが求められ、さらにこの人の代わりの人、または人数を追加できるかどうか４１１、入力することが求められる。
【００８６】
コーディネータは最低分担額４１４があるかどうか尋ねられ、もしあるのならその額４１５を示すことが求められる。コーディネータはさらに最高分担額４１８があるかどうか尋ねられ、もしあるのならその額４１９を示すことが求められる。
【００８７】
コーディネータは総購入金額を集めるのに、１人の最高分担額を明記するが、参加人数が不足する場合があるかもしれない。このような場合ＰＥＰ申込の完了が不可能となる（すなわち論理的に一致していない）。したがって、購入条件は論理評価アルゴリズム４２１によって評価されなければならない。このアルゴリズムは図５Ｃに示され、後で詳細に説明される。
【００８８】
上記のプロセスはコーディネータが購入条件を承認することにより終わる。
【００８９】
図５Ｃは本発明の一実施例においてコーディネータに送ることができるウェブページを示す。図５Ａおよび図５Ｂと同様に、このページは、システムサーバがコーディネータの個人および連絡先詳細を確定できるようにするエレメント（５５１、５５２、５５３および５５４）を含む。サーバシステムはコーディネータに参加者となるかどうかを聞いてくる（５５５および５５６）。適切な無線ボタン５５６を選択することにより、コーディネータは次の段階５５７で自分の名前を入力する必要はない。コーディネータは次に、名前５５８、名字５５６、およびｅメールアドレス５６０を入力する。サーバシステムは入力した情報を下の入力ボックス５６２に移す。加えた情報に誤りがある場合、コーディネータは「編集」ボタン５６３を選択することにより編集することができる。コーディネータの気が変われば、５６４にて参加指名者を削除することができる。コーディネータは自分のアドレスブックを見るオプション５６５も与えられる。このオプションは後で詳細に説明される。さらに代わりの人を立てることができるか（５６６および５６７）、および参加指名者の追加を認めるか（５６８および５６９）のオプションがある。起こり得る質問に対する答えを求めるオプション５７１、および最初のページに戻るオプション５７０または次に進むオプション５７２もある。
【００９０】
ｃ）  参加指名者詳細入力
上記で概要を示した各シナリオでは、コーディネータは各参加指名者の連絡先情報をサーバシステムに提供することが求められる（４０７、４０８および４０９）。この連絡先情報の正確な種類は、サーバシステムが用いる技術およびコーディネータが選択する通信方法に応じて変わる。ｅメールを参加指名者に送り、参加指名者はデスクトップクライアントシステムまたはＷＡＰイネーブル携帯装置を用いてそのメッセージをダウンロードすることができる。このような場合、連絡先情報は参加指名者のｅメールアドレスを含むことになる。ＰＥＰ申込を参加指名者に伝える別な方法はＳＭＳテキストを用いてセル式電話に送ることである。このような場合、参加指名者の連絡先情報は該当する電話番号を含むことになる。サーバシステムはこのような方法の１つまたは組合せを提供できる。
【００９１】
上述のように、コーディネータは各参加指名者の名前およびアドレスを手作業で入力できる（５１３−５１６、５３５−５３９、５５８−５６１）。これは処理が比較的遅くなるという欠点がある。さらに、コーディネータは間違って不正確な情報を入力する可能性もある。サーバシステムはコーディネータの個人のｅメールアドレスブックを、コーディネータのリクエストに応じて専用のｅメールプログラムから直接アップロードすることにより支援できる（５２０、５４４、５６５）。具体的には、コーディネータのｅメールプログラムに関連するアドレスブックファイルを探す自己実行プログラムをダウンロードし、ファイルをサーバシステムにアップロードすることにより行われる。こうしてアドレスを新しいウェブページに表示することができる。コーディネータは該当する連絡先情報に印を付けることにより、誰に参加を呼びかけるかを示すことができる。代替的に、コーディネータは特に本システムおよび方法に関連して用いるために友人や親戚の連絡先情報のリストを記憶してもよい。この情報は自分のクライアントシステムまたは遠隔のサーバシステム（ベンダのシステムまたはほかのシステム）に記憶しておくことができ、必要なときにアクセスできる。これらの代替の方法はそれぞれ手作業で入力するよりも早くかつ正確であるという利点を有する。
【００９２】
ｄ）  論理評価アルゴリズム
前に触れたように、コーディネータが作成した購入条件を論理的に一致させることはサーバシステムにとって重要である。これにより、参加指名者およびベンダーシステムは贈り物の購入をもたらすことができないようなＰＥＰ申込に応答する時間およびリソースを無駄に消費することがなくなる。
【００９３】
評価アルゴリズムはできる限りクライアントベースのスクリプトに関連して、サーバベースのスクリプト言語を用いてサーバシステムによって実現できる。当業者なら、評価アルゴリズムのエレメントが示されているものと異なる順序で用いられ得ることは理解できるであろう。
【００９４】
（ｉ）  均等額で購入するための評価アルゴリズム４１６
ステップ４０３において参加指名者は均等額を分担するよう求められることをコーディネータが指定した場合、コーディネータはステップ４０６で必要な参加人数を指定しなければならない。コーディネータが指名した指名参加者の人数がステップ４０６で指定した参加者数または最小参加数よりも大きければ、ＰＥＰ申込は首尾よく完了する（すなわち論理的に一致している）可能性があるのは明らかである。そうでない場合、ＰＥＰ申込が不首尾に終わる可能性がある（すなわち、購入条件は論理的に一致しないかもしれない）。
【００９５】
図６Ａに示される論理評価アルゴリズムは、このような状況６０１で購入条件の論理的一致性（またはその他）を評価するよう設計されている。
【００９６】
サーバシステムは、ステップ６０２で、参加指名者の合計人数（ＩT）が、設定された最小必要参加者数（Partmin）（４０６で指定）以上であるかどうか判断する。その人数が最小必要参加者数以上である（すなわち、６０２＝イエス）なら、購入条件は論理的に一致しており、コーディネータは購入条件を承認することによりステップ６０３に進むことが求められる。指定人数以上でなければ（すなわち６０２＝ノー）、購入条件は論理的に一致していないかもしれない。サーバシステムはステップ６０５において参加指名者を追加できるかどうか（４１２でコーディネータによって指定）判断する。人数を追加することができるのなら（すなわち６０５＝イエス）、締切日前に新たな人に呼びかける限り購入条件は満たされる。すなわち、コーディネータは購入に４人の最少人数が参加しなければならないと指定しているのにもかかわらず、３人の参加指名者しか指名していないかもしれない。締切日前に追加する人に呼びかけて、４人の参加指名者が参加に同意するのなら、ＰＥＰ申込に対して決定的な不備とはならない。サーバシステムはステップ６０６においてコーディネータに選択した購入条件の意味を説明する。そのコーディネータは、ステップ６０４において参加指名者を追加するオプション、ステップ６０８において最小参加指名者数を減らすオプション、またはステップ６０７において変更を加えずに進むオプションが与えられる。
【００９７】
これらのオプションの１つを選択した後、コーディネータはステップ６０３に進むことが求められ、そこで購入条件が承認される。
【００９８】
参加指名者人数が最小必要参加数より少ない場合（６０２＝ノー）かつ参加指名者の追加を認める条件がない場合（６０５＝ノー）、購入条件は論理的に一致せず、これはステップ６０９でコーディネータに説明しなければならない。コーディネータはステップ６１０で直ちに参加指名者を追加することにより、ステップ６１１で後日参加者の追加を認めることにより、またはステップ６１２で必要最低参加者数を減らすことにより、購入条件の誤りを修正する機会が与えられる。コーディネータがこれらのオプションを１つ以上選択すれば、新しい購入条件がステップ６０２で論理評価アルゴリズムによって再度評価される。反対に、コーディネータは再びスタート６１３することを選ぶこともでき、この場合ステップ６０２で分担方法の選択が求められる。
【００９９】
（ii）  コーディネータが指定した不均等な額での購入に対する評価アルゴリズム４１７
ステップ４０４において購入がコーディネータによって指定された不均等な額で行なわれる場合、購入条件が論理的に一致しているか否かは異なる判断材料で行なわれる。図６Ｂに示される論理評価アルゴリズムは６１４にてこのような状況下で購入条件の論理的一致（またはその他）を評価するよう意図されている。
【０１００】
ここで、サーバシステムはステップ６１５で価格の総額（ＰT）が指定された個々の分担額の合計（Σ［Ｃ（ｌ1）…Ｃ（ｌZ）］）（ここでＣ（ｌ1）＝最初の参加指名者の指定分担額、およびＣ（ｌZ）＝最後の参加指名者の指定分担額）に等しいかどうか確認しなければならない。等しい場合（すなわち６１５＝イエス）、購入条件は論理的に一致しており、コーディネータは確認することによりステップ６１６に進むことが求められる。
【０１０１】
価格の総額（ＰT）が指定された個別の分担額の合計（Σ［Ｃ（ｌ1）…Ｃ（ｌZ）］）に等しくない場合（６１５＝ノー）、購入条件は論理的に一致していないので、このことはステップ６１７でコーディネータに説明されなければならない。コーディネータはステップ６１８で個々の分担額を再度入力する、またはステップ６１９でサーバシステムに新たな金額を提示させる機会が与えられる。
【０１０２】
ステップ６１９においてサーバシステムに新しい個別の分担額を提示することが求められた場合、６２１にて元の分担額が示唆する割合に基づいて、加算すれば価格の総額になる新しい金額を提示する簡単な式を用いることができる。たとえば、最初の参加指名者（Ｃ（ｌ1）Original）の元の分担額が指定された個別の分担額の合計（Σ［Ｃ（ｌ1）…Ｃ（ｌZ）］）の１０％である場合、サーバシステムは価格の総額（ＰT）を１０％で乗算することにより、この参加指名者の新たな分担額を計算することができる。
【０１０３】
コーディネータは次にステップ６２２でオプションが与えられ、ステップ６２０で提示された金額を承認するか、またはステップ６２３において手作業で個別の分担額を再度入力するかを決める。コーディネータが手作業で個別分担額を再度入力するというオプションを取った場合（６２３または６１８）、サーバシステムはステップ６１５で再び新しい購入条件を評価する。
【０１０４】
（iii）  参加指名者が選択する不均等な額で購入する場合の評価アルゴリズム４２１
図６Ｃは、ステップ６２５で参加指名者が選択した額で購入がなされる購入条件を評価するのに用いることができる論理評価アルゴリズムを示す。サーバシステムは、まずステップ６２６でコーディネータが最高分担額（Ｃmax）を明記したかどうか（すなわちＣmax＞０かどうか）確定する。
【０１０５】
最高分担額がなければ（すなわち、６２６＝ノー）、購入条件は論理的に一致しており、コーディネータはステップ６２８でこれを承認することにより進む。最高分担額があるのなら（すなわち６２６＝イエス）、サーバは６２７にて合計参加指名数（ＩT）によって乗算されたこの値（Ｃmax）が、価格の総額（ＰT）より小さいかどうか定める。指名された参加指名者（Ｃmax×ＩT）で集めることができる最高金額が価格の総額以上である場合、購入条件は論理的に一致しており、コーディネータはステップ６２８でこれらを承認することにより続行することが求められる。
【０１０６】
他方で参加指名者で集めることができる最高金額が価格の総額より低い場合（すなわち６２７＝ノー）、サーバシステムは６３０にて参加指名者を追加できるかどうか（４１１においてコーディネータによって指定）判断する。人数を追加することができるのなら（６３０＝イエス）、購入条件は実際に追加者に呼びかけ、その人が締切日前に贈り物を分担する限り、購入条件は満たされる。言い換えると、コーディネータは１００ドルの贈り物を購入するのに、２０ドルの最高分担額を指定し、４人の参加指名者を指定しているかもしれない。５人目の参加指名者が加わってその最高金額を分担すれば、ＰＥＰ申込は成功するが、実際に人数が追加されなければ成功しない。サーバシステムはステップ６３１において、コーディネータに選択した購入条件の意味を説明し、コーディネータはオプションとして、ステップ６２９で即刻参加指名者を追加するオプション、ステップ６３３で最小参加指名者人数を減らすオプション、または変更せずにステップ６３２に進むオプションが与えられる。
【０１０７】
これらのオプションを１つ選択した後、コーディネータはステップ６２８で購入条件を承認することにより進むことが求められる。
【０１０８】
他方で、参加指名者で集めることができる最高額が価格の総額より低い場合（すなわち、６２７＝ノー）、かつ参加指名者の追加ができない場合（６３９＝ノー）、購入条件は論理的に一致せず、６３４にてこれをコーディネータに説明しなければならない。コーディネータはステップ６３５で参加者を追加することにより、ステップ６３６で後日人数の追加を認めることにより、またはステップ６３７で最高分担額を増額することにより、購入条件を修正する機会が与えられる。コーディネータがこれらのオプションを１つ以上選択すれば、新しい購入条件がステップ６２６で再評価される。他方で、コーディネータはステップ６３８で再度開始することを決めるかもしれないが、この場合コーディネータはステップ４０２で分担方法を選択することが求められる。
【０１０９】
ｅ）  承認ページ
上記のプロセスはすべてコーディネータに購入条件の承認を求めるリクエストで終了する（４２２）。コーディネータが続行する前にこれらの条件をはっきりと理解していることは必要である。なぜなら条件は厳密に選択した組合せに依存して著しく変わるからである。承認はクライアントシステムが購入条件に関する該当する詳細をまとめたウェブページをダウンロードし、コーディネータが続行する意思を表明した場合に達成される。これらは電子コマースの従来的な部分であり、ここで説明されない。
【０１１０】
ｆ）  結論
上記のセクション３で概要が示される購入条件を作成するためのオプションは、本発明の実施例の一例に過ぎない。当業者なら本発明はつぎの事項が可能であることは理解されるであろう。
【０１１１】
（ａ）  もっと簡単にできる、（たとえば）以下により：
（ｉ）  サーバシステムによって提供される利用可能な分担方法の数を制限する（たとえば、均等の分担額または指定金額のみを認める）；
（ii）  最初は基本的選択事項のみを提示し、コーディネータが求めた場合のみもっと進んだオプションを提示する；
（iii）  上記の分担方法に伴う柔軟性を減らす（たとえば、サーバシステムは参加指名者の追加もしくは代わりを認めない、または分担額が均等分担である場合、参加する参加者の人数のみの設定しか認めない）；または
（ｂ）  もっと複雑にする、（たとえば）以下により：
（ｉ）  分担する額について人々が合意に達するのを支援する；
（ii）  「混成」分担方法を認める（たとえば、一部の参加者は均等の額で購入価格の一部を負担し、残りの金額は参加者の選択する分担額によって負担する）。
【０１１２】
本発明の細かい構成はベンダーおよび顧客が求めるレベルの高さに応じて代わり得る。
【０１１３】
さらに、必要な情報は図４、図５Ａ、図５Ｂおよび図５Ｃで示される順序と異なる順序でも得ることができる。
【０１１４】
４．参加指名者応答の管理
ＰＥＰ申込を作成および公開すれば、サーバシステムは参加指名者からの応答および非応答を管理しなければならない。このプロセスは図７に示されている。図７に示されているように、各参加指名者（コーディネータが参加者のうちの１人である場合、コーディネータを含む）はステップ７０１でこの呼びかけを受取る。
【０１１５】
ａ）  全般
参加指名者はステップ７０２において呼びかけに対して何の応答もしない場合、ステップ７０３で締切日前にその人に注意を促す督促が送られる。その時点で、参加指名者はステップ７０４において何もしないかもしれないし、ステップ７０６でサーバシステムに連絡を取ることにより応答するかもしれない。参加指名者が呼びかけをｅメールの形で受取っている場合、これはベンダーのウェブサイトの個人応答ページへのハイパーリンクをクリックすることによってなされる。呼びかけがＳＭＳフォームの形で送られた場合、参加指名者はこのようなページへの直接アクセスを備えた呼出しセンターに連絡することによって応答してもよい。ステップ７０４で参加指名者は何もしないことを選択するのなら、購入条件が満たされないことが明らかになった場合、または締切日になった場合、直ちにステップ７０５において参加指名者の関与はなくなる。
【０１１６】
反対に、参加指名者がステップ７０６において個人応答ページへのハイパーリンクで応答すれば、参加指名者はステップ７０７でその呼びかけを断る、または同意してステップ７１１で求められる会計上の詳細を提示できる。前に述べたように、このような詳細の種類は使用される電子支払システムの種類に応じて変わる。たとえば、クレジットカード番号および有効期限、またはスマートカードもしくは電子マネーを介して伝えられる情報の形であり得る。参加指名者がステップ７０７で呼びかけを断った場合、サーバシステムはステップ７０８において代わりのまたは追加の参加指名者を提示する機会を与えてもよい。これはコーディネータが前にこのオプション（４１１、４１２、４１３）を認めている場合しか与えられない。この時点で参加指名者の関与はステップ７０９でなくなる。
【０１１７】
参加指名者はステップ７１１で参加することにより続行することを選択した場合、参加指名者はコーディネータがオプション（４１１、４１２、４１３）を利用可能にした場合のみステップ７１２で追加の参加指名者を任命する機会が与えられる。つぎにサーバシステムはステップ７１３で購入条件が満たされたかどうかを評価する（これは次のセクション５で詳細に説明されるプロセスである）。参加者はステップ７１４でＰＥＰ申込の進行の概要についての状態ページを見ることになるかもしれない（次のセクション４（ｄ）参照）。参加指名者が参加することに同意したのにもかかわらず、購入条件が締切日までに満たされなければ、ステップ７１０で確認の旨が送られ、その時点で参加指名者の関与はステップ７０９でなくなる。購入条件が満たされたのなら、確認通知が送付され、ステップ７１５で金額の振替が行なわれる。
【０１１８】
ｂ）  個人応答ページ
前に述べたように、参加指名者は個人応答ページにハイパーリンクすることにより呼びかけに応答してもよい。参加指名者が共同購入の参加に同意したなら、その人はベンダーとだけではなく、他の参加者とも契約を結ぶことになる。したがって、各参加指名者は自分に関与する限りにおいて十分に購入条件を理解することは重要である、したがって、各応答ページが個々に参加指名者に対応するよう作られていることが望ましく、購入条件はできるだけ簡単にかつ直接的に記載されていることが望ましい。
【０１１９】
個人応答ページは図４に示される分担方法に対応可能である。代替の方法が図８Ａ、図８Ｂおよび図８Ｃに示されており、これは本発明の一実施例において異なる購入条件の組合せに用いることができる個人応答ページを例示している。
【０１２０】
図８Ａが示している個人応答ページでは、各参加指名者のそれぞれの分担額がＰＥＰ申込作成フェーズの最後で知ることができる。これは分担額が均等でなされ、参加人数が（ある任意の範囲ではなく）特定の人数としてステップ４０６で設定されている場合に起こる。さらに、ステップ４０４の場合のように、コーディネータが指定した分担額を参加者が負担する場合にも起こり得る。図８Ａに示されているように、これらの組合せは同様の態様で説明できる。
【０１２１】
図８Ｂが例示している個人応答ページでは、参加者は均等額を分担するが、最終的な参加人数はプロセスの最後でもわからない場合である。これは、コーディネータがステップ４０６である参加人数を定める代わりに、最小参加人数、最大参加人数、または最小および最大参加人数を指定した場合に起こり得る。この場合、各参加者が支払う金額の範囲を計算することは可能であるが、最終的な金額は合計参加人数が決まるまでわからない。
【０１２２】
図８Ｃが例示している個人応答ページでは、参加指名者はステップ４０５で自分の分担額を選ぶ。
【０１２３】
図８Ａ、図８Ｂおよび図８Ｃは本発明の実施例の各々の変形において、どのように個人応答ページを適用して購入条件を簡単にかつ直接的な態様で説明できるかを示す。個人応答ページはつぎのいくつかの共通エレメントを含む：
（ｉ）  歓迎の表示および特定の人に対して品目の共同購入への参加を求める簡単な呼びかけ、ならびに購入理由の説明（すなわち、行事の詳細）：８０１、８１０、８１９；
（ii）  それぞれの参加指名者についての詳細、および呼びかけの現状（さらに、適するのなら、求められたまたは実際の分担額）：８０２−８０５、８１１−８１３、８２０−８２４。図８Ａ、図８Ｂおよび図８Ｃは呼びかけの現在の状況を示す３つの項目である「同意」、「断る」および「応答待ち」を示す。当該技術分野に馴染みのあるものは、「受取ったが開いていない」または「受取って開いた」を含めて、サーバシステムは他のインジケータを表示できることはわかるであろう；
（iii）  参加指名者に参加の成り行きを説明する文章：８０６、８１５、８２５。参加指名者が参加に同意した場合に行なわれるステップを示し、これは購入条件が満たされた場合および満たされていない場合を含む；
（iv）  参加指名者が呼びかけに対して同意または断るオプション：８０７および８０１、８１６および８１７、８２６および８２７；
（ｖ）  システムおよび方法のより詳細な説明を参加指名者に与える機会：８０９、８１１、８２８。
【０１２４】
当該技術分野において馴染みのあるものは、上記のエレメントの一部は省略、またはさまざまな方法で再配置もしくは適合できることはわかるであろう。さらに、必要なら追加情報を含めることもできる。たとえば、ページは参加指名者の数、呼びかけに同意したまたは断った人数、および各参加者の平均分担額といった統計値を含めたサマリーテーブルを含めることができる。この情報は文字もしくは図形、または文字および図形の組合せを用いて伝えることができる。
【０１２５】
図８Ａに示されるレイアウトは個人応答ページの３例のうち最も簡単なものである。参加指名者に対して特定の指定された額（＄Ｚ．００）を分担する呼びかけが表示され８０１、さらに他の参加指名者に求められている指定額（＄Ｘ．００および＄Ｙ．００）８０４を示す。
【０１２６】
それとは対照的に、図８Ｂに示される個人応答ページは、参加指名者に求められる特定の金額を示さない。前に述べたように、これは最終の参加者数が定められるまでわからない。したがって、図８Ｂは参加指名者が負担するかもしれない金額の範囲を示し、これは８１４にて最小または最大人数の参加指名者が参加する数に基づいて計算される。図８Ｂはまた、分担範囲額についての動的情報を与えるのに用いられ得る任意の文章を含み、８１４にて分担額の範囲は参加者の人数が変わるにつれ更新される。
【０１２７】
図８Ｃは参加指名者が自分で分担額を選択する場合８２０を網羅する（おそらくは特定の範囲内の金額）。このシナリオでは、各参加者間で必要な額が集められると直ちにプロセスは終了する。このシナリオで示すことができる重要な情報としては、目標金額、現在の集められた額、および残りの未達成額８２１である。
【０１２８】
ｃ）  同意の選択
参加指名者はＰＥＰ申込に参加する意思表示を、個人応答ページの該当する箇所（８０７、８１６、８２６）をクリックすることにより示すことができる。本発明の一実施例において、これを行なうと参加指名者は支払承諾ページ（図９）に進み、参加指名者は該当する電子支払システムでの資金の転送に必要な詳細を入力するよう求められる。たとえば、クレジットカードまたはチャージカードを用いる参加者は、名前の入力（９０１、９０２および９０３）およびドロップダウンメニューで示される、リストからのクレジットカードまたはチャージカードの種類を選択することが求められる（９０４および９０５）。次に、参加者は該当するカード番号（９０６および９０７）およびカード有効期限（９０８、９０９および９１０）を入力することが求められる。
【０１２９】
支払承諾ページはさらに参加者が払う分担額またはある範囲の分担額を示す部分を含む（９１１、９１２および９１３）。混乱するまたは機能しない申込を避けるためには、支払承諾ページは購入条件に一致する支払金額のみを受付けるよう構成されていなければならない。したがって、この部分の厳密な操作はコーディネータが作成する購入条件の種類に依存する。たとえば、コーディネータが購入条件を設定すると直ちに各分担額がわかる特定の状況もある。これは既に図８Ａに関連して説明されている。ここでは、支払承諾ページは（参加指名者によって変更または修正されないために）編集できないフィールドとして、必要な分担額の正確な金額が表示される９１２。参加指名者が（既に図８Ｂに関連して説明したように）ある範囲の金額に同意する場合、分担額の最低金額および最高金額が表示される（９１２および９１３）。この情報は単に購入条件を参照するだけでなく、参加する意思表示を示した実際の参加指名者数を参照することによって計算される分担額の範囲を表示する意味において動的であり得る（たとえば、必要最小参加数は３人かもしれないが、既に４人が参加することに同意しており、各参加者が支払うことになるかもしれない最高金額が下がる）。参加指名者が（既に図８Ｃに関連して説明したように）自分の分担額を選ぶ場合、支払承諾ページでは特定の指定額は拒否されるようにしなければならない。たとえば、コーディネータが指定した範囲よりも低いまたは高い金額があるかもしれない。さらに、参加指名者は残額を超える額を指定することもできない。好ましくは、参加指名者が行なった入力はクライアント側のスクリプト言語を用いてクライアントシステムで、同様にベンダーサーバシステムで、確認されるべきである。クライアント側のスクリプトにより論理的誤りを識別する処理をはかどらせる。なぜなら、該当する入力はサーバシステムにアップロードする必要なくチェックすることができるからである。このような限定を参加指名者に知らせる簡単な説明９１４もこのウェブページに現われる。
【０１３０】
次に参加指名者は続行するオプション９１５または戻るオプション９１６が与えられる。戻ると、参加指名者は個人応答ページに入り、参加指名者は呼びかけを断ることができる。必要な情報を入力した後に参加指名者が「続ける」をクリックすると、参加者は（下のセクション（ｄ）で説明される）状態ページに入る。参加指名者は任意にベンダーのウェブサイト１０２の一般のｅコマースページ１０５のどれかに入ることもできる。
【０１３１】
ｄ）  状態ページ
参加指名者がクレジットカードの詳細を入力した後、サーバシステムはウェブページを各自に送って特定のＰＥＰ申込の現在の情況を表示することができる（状態ページ）。各参加者は通常の合間で状態ページに戻って、特定のＰＥＰ申込の進行をチェックすることができる（おそらく、パスワードの入力が求められる）。コーディネータが選択した該購入条件の組合せに対してできるだけ合うような態様で、状態ページを参加者に提示するのが望ましい。
【０１３２】
状態ページに含めることができる一部の情報を以下に示す：
・指定された購入品目の説明；
・購入条件の簡単な説明；
・他の参加指名者の身元；
・該ＰＥＰ申込下でなされたさまざまな呼びかけの状態；
・参加するのに同意した参加指名者の数；
・現在の最高および最低分担額（参加者が均等額を分担する場合）；および
・現時点で集まった額、および目標額を達成するのに集められなければならない金額。
【０１３３】
状態ページはｅコマースの従来のアスペクトを用いるだけであり、ここでは詳細に説明しない。
【０１３４】
５．監視アルゴリズム
各ＰＥＰ申込の進行を適時および正確に評価することは、本発明を効果的に行なうのに重要である。各参加者はＰＥＰ申込がいつ不首尾に終わったか、または満たすことができないかをできるだけ早く確認したいものである。これにより、参加者は代わりの共同購入を手配するのになるべく多くの時間が与えられる。ベンダー側はできるだけ早い機会に不首尾に終わるＰＥＰ申込を特定したいものである。なぜなら、これにより在庫管理に役立つからである。さらに、購入者は一般に個々の分担額が大きくなるよりも小さくなることに関心を持つ。購入を均等額で行なう場合、かつコーディネータは最小および最大の参加者が認められることを指定した場合、個別の分担額は参加者数が増加するにつれ小さくなる。このような状況では、より多くの参加者が加わって個々の分担額を下げる見込みがあるのなら、ＰＥＰ申込をオープンの状態に保つのが望ましい。これは、ＰＥＰ申込の「最適化」と呼ぶ。
【０１３５】
本発明の好ましい実施例において、サーバシステムは種々の監視アルゴリズムを用いてこれらの検討材料に鑑みて各ＰＥＰ申込を評価する。この評価はベンダーまたは参加者の関与なしで、自動的になされる。サーバシステムは「評価マイルストーン」と記される周期で各ＰＥＰ申込を評価する。次に説明するさまざまな監視アルゴリズムの作動をトリガする２つの評価マイルストーンとは、新たな指名参加者からの応答の受理、および日付の変更である。このアルゴリズムは、（Visual Basic、Ｃ、Ｃ＋＋、PascalおよびJava（Ｒ）を含む）任意の言語で実現でき、動作システム特定スケジュールサービス（たとえばウインドウズ（Ｒ）９５および９８のサーバエージェント、ウインドウズ（Ｒ）２０００のタスクスケジューラ、またはユニックス（Ｒ）のcronなど）で実行される。これらのソフトウェアシステムを用いて次のアルゴリズムを実現するさまざまな方法は、当業者にとって自明である。
【０１３６】
（ａ）  均等額での購入
図１０Ａは参加者が均等額を負担する場合１００６のＰＥＰ申込を評価するプロセスを示す。このようなＰＥＰ申込は現在の参加者数（PartC）が必要な最小参加者数（Partmin）以上であり（すなわち１００７＝イエス）、かつ以下の場合に、首尾よくいったと判断される：
・最大参加者数（Partmax）も達成している（すなわちPartC＝Partmax）（１０１０＝イエス）；または
・最大参加者数はまだ達成していない（すなわちPartC≠Partmin）（１０１０＝ノー）が、すべての参加指名者は応答しており（１０１１＝イエス）かつ人数の追加は認められていない（１０１２＝ノー）；または
・最大参加者数は達成していない（すなわち、PartC≠Partmin）（１０１０＝ノー）が、すべての参加指名者は応答しており（１０１１＝イエス）かつ人数の追加は認められる（１０１２＝イエス）が、現在の日付（TimeC）は締切日（TimeT）に等しい（言い換えると、締切日になっている）（TimeC≧TimeT）（１００９＝イエス）；または
・最大参加者数は到達していない（すなわち、PartC≠Partmin）（１０１０＝ノー）、かつすべての参加指名者は応答していない（１０１１＝ノー）が、締切日となった（TimeC≧TimeT）（１００９＝イエス）。
【０１３７】
図１０Ａは、最大参加者数に達していなくて（PartC≠Partmin）（１００７＝ノー）かつ以下の場合に、ＰＥＰ申込が不首尾に終わったと判断する場合を示している：
・締切日に達している（TimeC≧TimeT）（１００１＝イエス）；または
・締切日にはまだなっていない（TimeC＜TimeT）（１００１＝ノー）が、すべての参加指名者は応答しており（ＩT＝ＩRESP）（１００２＝イエス）、かつ人数の追加はできない（１００４＝ノー）；または
・締切日にはまだなっていない（TimeC＜TimeT）（１００１＝ノー）、合計参加指名者数（ＩT）は応答した参加指名者の数（ＩRESP）よりも大きく（すなわち、すべての参加指名者は応答していない）（ＩT＞ＩRESP）（１００２＝ノー）、これから応答する参加指名者数（ＩT−ＩRESP）はＰＥＰ申込が成功するために参加の同意を示さなければならない参加者数より小さい（Partmin−PartC）（１００３＝ノー）、かつ人数の追加はできない（１００４＝ノー）。
【０１３８】
図１０Ａは次の場合ＰＥＰ申込が再評価されなければならないことを示し、その場合とは：
・最小参加者数に達しており（PartC≧Partmin）（１００７＝イエス）、最大参加者数には達していない（PartC≠Partmin）（１００１＝ノー）が、参加指名者全員が応答しており（１０１１＝イエス）、人数の追加が認められ（１０１２＝イエス）、締切日にはなっていない（TimeC＜TimeT）（１００９＝ノー）；または
・最小参加者数に達しており（PartC≧Partmin）（１００７＝イエス）、最大参加者数には達していない（PartC≠Partmin）（１０１０＝ノー）、参加指名者全員が応答していない（１０１１＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１００９＝ノー）；または
・最小参加者数に達していない（PartC＜Partmin）（１００７＝ノー）、締切日にはまだなっていない（TimeC＜TimeT）（１００１＝ノー）、参加指名者すべてが応答していない（ＩT＞ＩRESP）（１００２＝ノー）、かつこれから応答する参加指名者数はＰＥＰ申込が成功するために参加の同意を示さなければならない参加者数以上である（ＩT−ＩRESP＞Partmin−PartC）（１００３＝イエス）；または
・最小参加者数に達していない（PartC＜Partmin）（１００７＝ノー）、締切日にはまだなっていない（TimeC＜TimeT）（１００１＝ノー）、参加指名者全員が応答していない（ＩT＞ＩRESP）（１００２＝ノー）、かつこれから応答する参加指名者数はＰＥＰ申込が成功するために参加の同意を示さなければならない参加者数より小さい（ＩT−ＩRESP＜Partmin−PartC）（１００３＝ノー）が、人数の追加は認められている（１００４＝イエス）。
【０１３９】
どの場合でも、サーバシステムは再評価が必要であると判断したら、次の評価マイルストーンに達するまで遅延される。
【０１４０】
（ｂ）  コーディネータが指定した額による購入
図１０Ｂはコーディネータが指定した額で購入するＰＥＰ申込を評価できるプロセスが示される。
【０１４１】
このようなＰＥＰ申込は、現在の集められた金額（ＡＲC）が価格の総額（ＰT）に等しい場合（すなわち、価格の総額が集められた）（１０１６＝イエス）、首尾よくいったと判断される。
【０１４２】
さらに、このようなＰＥＰ申込は次のような場合不首尾に終わったことが示される：
・価格の総額が集められない（ＡＲC≠ＰT）（１０１６＝ノー）かつ締切日になっている（TimeC≧TimeT）（１０１７＝イエス）；または
・価格の総額が集められていない（ＡＲC≠ＰT）（１０１６＝ノー）かつ締切日になっていない（TimeC＜TimeT）（１０１７＝ノー）、少なくとも参加指名者一名は呼びかけを断り（１０２１＝イエス）かつ代わりの参加指名者は認められない（１０２０＝ノー）。
【０１４３】
図１０Ｂは次のような場合ＰＥＰ申込が再評価されなければならないことを示す：
・価格の総額が集められていない（ＡＲC≠ＰT）（１０１６＝ノー）、締切日にはまだなっていない（TimeC＜TimeT）（１０１７＝ノー）、かつ呼びかけを断った参加指名者はいない（１０２１＝ノー）；または
・価格の総額は集められていない（ＡＲC≠ＰT）（１０１６＝ノー）、かつ締切日にはまだなっていない（TimeC＜TimeT）（１０１７＝ノー）、少なくとも参加指名者一名は呼びかけを断った（１０２１＝イエス）が、参加指名者を代えることができる（１０２０＝イエス）。
【０１４４】
（ｃ）  参加者が決めた金額による購入
図１０Ｃは、参加者が選んだ金額を分担する購入にかかわるＰＥＰ申込１０２３を評価できるプロセスを示す。
【０１４５】
このようなＰＥＰ申込は価格の総額が集められた場合（ＡＲC＝ＰT）（１０２４＝イエス）、首尾よくいったと判断される。
【０１４６】
図１０Ｃはさらに、ＰＥＰ申込は次のような場合不首尾に終わることを示している：
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）かつ締切日となっている（TimeC≧TimeT）（１０２５＝イエス）；または
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１０２５＝ノー）、参加指名者全員が応答しており（ＩT＝ＩRESP）（１０３１＝イエス）かつ追加の人数は認められていない（１０３０＝ノー）；または
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１０２５＝ノー）、参加指名者全員は応答していない（ＩT＞ＩRESP）（１０３１＝ノー）、最高分担額（Ｃmax＞０）（１０２７＝イエス）があり、最高分担金額×応答した参加指名者数（ＩT−ＩRESP）は、価格の総額−現在集められた額（ＰT−ＡＲC）より小さく（１０２８＝ノー）、かつ人数の追加は認められていない（１０３０＝ノー）。
【０１４７】
図１０ＣはＰＥＰ申込が次のような場合再評価されなければならないことを示す：
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１０２５＝ノー）、参加指名者全員が応答しており（ＩT＝ＩRESP）（１０３１＝イエス）、かつ追加の人数は認められている（１０３０＝イエス）；または
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１０２５＝ノー）、参加指名者全員は応答していない（ＩT≠ＩRESP）（１０３１＝ノー）、かつ最高分担額はない（１０２７＝ノー）；または
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１０２５＝ノー）、参加指名者全員は応答していない（ＩT≠ＩRESP）（１０３１＝ノー）、最高分担額があり（Ｃmax＞０）（１０２７＝イエス）、かつ最高分担額×応答した参加指名者数（Ｃmax×（ＩT−ＩRESP））は、価格の総額−現在集められた額（ＰT−ＡＲC）より大きい（１０２８＝イエス）；または
・価格の総額が集められていない（ＡＲC≠ＰT）（１０２４＝ノー）、締切日にはなっていない（TimeC＜TimeT）（１０２５＝ノー）、参加指名者全員は応答していない（ＩT≠ＩRESP）（１０３１＝ノー）、最高分担額があり（Ｃmax＜０）（１０２７＝イエス）、かつ最高分担額×応答した参加指名者数（Ｃmax×（ＩT−ＩRESP））は価格の総額−現在集められた額（ＰT−ＡＲC）より小さく（１０２８＝ノー）、かつ人数の追加が認められている（１０３０＝イエス）。
【０１４８】
６．支払管理
前に述べたように、本発明は参加指名者が参加者となることに同意した時とＰＥＰ申込が成功した時との間に時間的遅延がある。したがって、本システムおよび方法が支払処理を安全にかつ効率よく管理することが重要である。
【０１４９】
ｅコマース取引において支払を調整する標準な方法は、該当する詳細が受取られるとすぐにリアルタイムでクレジットカードに請求することである。これはカードの詳細が提示されたとき前後に、参加者からベンダーに金額が振替えられることを意味する。本発明に関連してこの方法を用いる場合にはいくつかの問題が伴う。購入条件が満たされなければ、該当する金額を各参加者の口座に払戻す必要がある（「チャージバック」と知られているプロセス）。これは遅延を伴い、さらに銀行手数料を伴うかもしれない。さらに、参加者は購入条件が満たされる前にクレジットカードの勘定につけられることを望まないかもしれない。さらに、起こり得る組合せの一部では、本システムおよび方法を用いて確立できる購入条件の組合せによっては、各参加者が支払い得る正確な金額はすべての参加指名者が応答するまで、または締切日になるまでわからないこともある。この時点より前では、正確な最終的金額をこれらのクレジットカードに課金するのは不可能である。
【０１５０】
これらの支払に対処する好ましい方法は直接デビット事前承認支払である。これは参加指名者のクレジットの限度額の一部を「差押え」することにより、参加指名者銀行１１４およびコーディネータの銀行１１６または事前承認デビット額の記録を記憶している参加指名者銀行１１４に関与させる。これら種々の銀行（１１４、１１３および１１４）と相手（１０１、１０４および１０８）との間のやりとりはゲートウェイシステム１１２によって調整される。参加者が自分のクレジットカードにある範囲の支払が課せられることに同意した場合、この押えられる金額はカードに請求され得る最高金額に対してなされる。購入条件が満たされると、ベンダーは直接のデビット元としての資格において支払リクエストを開始させる。この方法を用いることは、参加指名者のクレジットカードが購入条件が満たされた場合のみ請求されることを意味し、ベンダーは参加指名者の応答を待つ間商業的に機密性のある情報を自分のシステムに記憶しておく必要はない。さらに実際の応答と決済リクエストとの間の期間で起こる顧客のクレジット状態の変化により支払が拒否される可能性が回避される。
【０１５１】
この問題に対処する別の方法では、ＰＥＰ申込が首尾よく完了するのを待つ間、参加者はエスクローとして保管されている証書を有する第三者に対して支払を行なうことであり。これはクレジットカードによるチャージバックよりも便利なオプションである。なぜならエスクローの支払の管理を専門とする会社は、銀行よりも早く資金の返却を行なうことができるからである。しかし、この方法はさらに他の手数料や遅れが伴うかもしれない。
【０１５２】
この問題に対処する３番目のより簡単な方法は、ベンダーに標準の事前承認支払を使用してもらうことである。これは「リアルタイム」支払の許可を用いることを伴うが、購入条件が満たされるまでその許可のリクエストを遅らせることになる。本発明の一実施例において、この方法によってベンダーは該当するクレジットカードの詳細を自分のシステムの支払データベース１１０内に記憶する必要がでてくる。各参加者の会計上の詳細はベンダーウェブサイト１０２のＰＥＰ関連ページ１０９を介して安全なネットワークでこのデータベースに入力されるが、この情報はＰＥＰ申込データベース１０７または在庫データベース１０３に含まれる情報をアクセスするのと同じ方法で、ウェブサイトを介してアクセスできるものであってはならない。さらに、支払データベース１１０に記憶されているが、データはそれを入手した非承認の人にとっては何の役にもたたないよう暗号化されるべきである。購入条件が満たされた場合、ベンダーは獲得銀行１１３に顧客が提示した支払を受ける許可を求め、さらにこのリクエストとともにクレジットカードデータを送る。この代替方法により、ベンダーシステムはクレジットカードまたはチャージカードの有効期限が締切日より後であることを確認していなければならない。なぜなら、締切日の後にクレジットカードの有効期限がきているのなら、参加者の銀行はベンダーからの決済のリクエストをそれがなされた時点で断り得るからである。
【０１５３】
本実施例の変形として、ベンダーはデータの記憶および処理をゲートウェイシステム１１２に外注することもできる。ゲートウェイシステムによって記憶される財務データに識別子が割当てられ、この識別子は該ＰＥＰ申込についてベンダーが用いているものと同じ、またはその識別子への相互参照となる。特定のＰＥＰ申込の購入条件が満たされると、サーバシステムはＰＥＰ申込を特定してゲートウェイシステムにメッセージを送り、該当する支払をまとめることを求める。
【０１５４】
「リアルタイム」支払承認のリクエストを遅延させるこの方法を用いることは、単純な「リアルタイム」承認方法と比べていくつかの利点を有する。購入条件が満たされるまで、支払リクエストの開始をベンダーが遅延すれば、各参加者が支払う正確な額は購入条件の起こり得る組合せすべてにおいて既知となることを意味する。さらに、この方法を用いることにより、参加者のクレジットカードは購入条件が満たされないと課金されないこととなる。
【０１５５】
しかし、この方法には２つの大きな不利な点がある。クレジットカードおよび他の詳細を記憶する必要により、ベンダーのシステムまたはゲートウェイシステムはある期間の間データに対するセキュリティを確保する手段をとらなければならない。これは非常に費用がかかり、ものによっては侵害されるというリスクもある。第２の欠点は、ベンダーが支払のリクエストを起こした場合に銀行によって断られる可能性があることである。これはベンダーが応答期日に参加者のクレジットカードの詳細を受取る最初の承認を得たとしても起こり得る。原因として、参加者のクレジットカードの限度額が応答日と実際の支払請求日の間に超えてしまったり、クレジットカードをなくしたり盗まれたりすることが考えられる。したがって、事前承認の直接デビットが好ましい。
【０１５６】
７．注文の管理
ベンダーがサービスではなく物理的な品物を販売する場合、サーバシステムは品揃えまたは在庫のデータベース１０６を管理する。このデータベースは販売に供されるベンダーの製品のリスト、およびこれらの製品の在庫数量の記録を一般に含む。商品が在庫にない場合、在庫データベースはそれが在庫に入るまでの時間的見積りをも含み得る。
【０１５７】
購入条件が首尾よく完了するのを待つ間、サーバシステムは在庫データベース１０６において選択した品目を予約済として記すことができる。これはベンダーの在庫管理において重要である。なぜなら、必要時に少なくともそれぞれの品目の１つは発送できるよう在庫になければならないからである。代替的に、選択された品目は最初コーディネータが選択した時点では在庫にないが、購入条件が満たされた場合に品目が在庫にあるのを確実にする必要がある。しかし、ベンダーはコストを抑えるために、手元の在庫数を減らすことに関心を持っている。ＰＥＰ申込は指定された品目の購入をもたらさない可能性もあるので、本発明を用いて購入すると指定されたすべての品目をリザーブまたは注文しておくことは不経済かもしれない。
【０１５８】
ベンダーは本システムおよび方法による今までの経験に基づいた見積りを用いて在庫レベルを管理することができる。経過データはＰＥＰ申込データベース１０９から得られた情報を用いてコンパイルできる。この情報は、首尾よく完了したＰＥＰ申込の割合といった情報、または総額のうちの特定の割合が集められたもしくは参加指名者のうち特定の割合の人が参加の同意を示した場合にもたらされる首尾よく終わったＰＥＰ申込の割合といったもう少し複雑なデータを含む。このようなデータは１年を通してある時点での季節的出来事（たとえばクリスマス）を考慮に入れて統計的に分析できる。このような情報はすべてＰＥＰプロセスにおける在庫を管理するのに用いることができる。
【図面の簡単な説明】
【０１５９】
【図１】本発明に特に適する一ネットワーク環境の機能的ブロック図である。
【図２】本発明の一実施例の概要を示す簡略フロー図である。
【図３】販売品目を表示する典型的なウェブページにあり得るエレメントを示す簡略ブロック図である。
【図４】新しいＰＥＰ申込の購入条件をコーディネータが作成するのを支援するプロセスを示すフロー図である。
【図５Ａ】異なる分担方法が選択された場合に、コーディネータが論理的に一致する購入条件を作成するのを支援する、典型的なウェブページにあり得るエレメントを示す簡略ブロック図である。
【図５Ｂ】異なる分担方法が選択された場合に、コーディネータが論理的に一致する購入条件を作成するのを支援する、典型的なウェブページにあり得るエレメントを示す簡略ブロック図である。
【図５Ｃ】異なる分担方法が選択された場合に、コーディネータが論理的に一致する購入条件を作成するのを支援する、典型的なウェブページにあり得るエレメントを示す簡略ブロック図である。
【図６Ａ】コーディネータが作成した購入条件が異なる分担方法に対して論理的に一致しているかどうかをチェックするのに用いることができるアルゴリズムを示すフロー図である。
【図６Ｂ】コーディネータが作成した購入条件が異なる分担方法に対して論理的に一致しているかどうかをチェックするのに用いることができるアルゴリズムを示すフロー図である。
【図６Ｃ】コーディネータが作成した購入条件が異なる分担方法に対して論理的に一致しているかどうかをチェックするのに用いることができるアルゴリズムを示すフロー図である。
【図７】実施例において、ベンダーのサーバシステムがどのように参加指名者からの応答および非応答を処理するかについての概要を示すフロー図である。
【図８Ａ】異なる購入条件のシナリオ下で起こり得る個人応答ページのエレメントを示す簡略ブロック図である。
【図８Ｂ】異なる購入条件のシナリオ下で起こり得る個人応答ページのエレメントを示す簡略ブロック図である。
【図８Ｃ】異なる購入条件のシナリオ下で起こり得る個人応答ページのエレメントを示す簡略ブロック図である。
【図９】実施例において代替の購入条件の組合せに用いることができる可能な支払承諾ページを示すブロック図である。
【図１０Ａ】ＰＥＰ申込が首尾よくいく、不首尾に終わる、または成功の見込みがなくなってしまったかどうかを定めるために設計された監視アルゴリズムを示すフロー図である。
【図１０Ｂ】ＰＥＰ申込が首尾よくいく、不首尾に終わる、または成功の見込みがなくなってしまったかどうかを定めるために設計された監視アルゴリズムを示すフロー図である。
【図１０Ｃ】ＰＥＰ申込が首尾よくいく、不首尾に終わる、または成功の見込みがなくなってしまったかどうかを定めるために設計された監視アルゴリズムを示すフロー図である。
【図１】
2004527059.tif 000003
【図２】
2004527059.tif 000004
【図３】
2004527059.tif 000005
【図４】
2004527059.tif 000006
【図５Ａ】
2004527059.tif 000007
【図５Ｂ】
2004527059.tif 000008
【図５Ｃ】
2004527059.tif 000009
【図６Ａ】
2004527059.tif 000010
【図６Ｂ】
2004527059.tif 000011
【図６Ｃ】
2004527059.tif 000012
【図７】
2004527059.tif 000013
【図８Ａ】
2004527059.tif 000014
【図８Ｂ】
2004527059.tif 000015
【図８Ｃ】
2004527059.tif 000016
【図９】
2004527059.tif 000017
【図１０Ａ】
2004527059.tif 000018
【図１０Ｂ】
2004527059.tif 000019
【図１０Ｃ】
2004527059.tif 000020
【国際公開パンフレット】
2004527059.tif 000021
2004527059.tif 000022
2004527059.tif 000023
2004527059.tif 000024
2004527059.tif 000025
2004527059.tif 000026
2004527059.tif 000027
2004527059.tif 000028
2004527059.tif 000029
2004527059.tif 000030
2004527059.tif 000031
2004527059.tif 000032
2004527059.tif 000033
2004527059.tif 000034
2004527059.tif 000035
2004527059.tif 000036
2004527059.tif 000037
2004527059.tif 000038
2004527059.tif 000039
2004527059.tif 000040
2004527059.tif 000041
2004527059.tif 000042
2004527059.tif 000043
2004527059.tif 000044
2004527059.tif 000045
2004527059.tif 000046
2004527059.tif 000047
2004527059.tif 000048
2004527059.tif 000049
2004527059.tif 000050
2004527059.tif 000051
2004527059.tif 000052
2004527059.tif 000053
2004527059.tif 000054
2004527059.tif 000055
2004527059.tif 000056
2004527059.tif 000057
2004527059.tif 000058
2004527059.tif 000059
2004527059.tif 000060
2004527059.tif 000061
2004527059.tif 000062
2004527059.tif 000063
2004527059.tif 000064
2004527059.tif 000065
2004527059.tif 000066
2004527059.tif 000067
2004527059.tif 000068
2004527059.tif 000069
2004527059.tif 000070
2004527059.tif 000071
2004527059.tif 000072
2004527059.tif 000073
2004527059.tif 000074
2004527059.tif 000075
2004527059.tif 000076
2004527059.tif 000077
2004527059.tif 000078
2004527059.tif 000079
【国際調査報告】
2004527059.tif 000080
2004527059.tif 000081
2004527059.tif 000082