(57)【特許請求の範囲】
【請求項１】
申込価格を含む顧客が定義した条件を含む旅行に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信し、複数の航空券の売主の各々から各売主が承諾可能な最低価格を含む航空会社が定義した制限を含む規程を、前記規程を保存している規程データベースを介して受信する通信ポートと、
前記通信ポートに接続され、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較し、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記航空会社が定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記航空券を購入するように前記顧客を拘束するプロセッサと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とするシステム。
【請求項２】
申込価格を含む顧客が定義した条件を含む商品及び役務の一方に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信し、複数の売主の各々から各売主が承諾可能な最低価格を含む売主が定義した制限を含む規程を、前記規程を保存している規程データベースを介して受信する通信ポートと、
前記通信ポートに接続され、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較し、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記売主が定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記一方を購入するように前記顧客を拘束するプロセッサと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とするシステム。
【請求項３】
申込価格を含む顧客が定義した条件を含む旅行に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信し、複数のクルーズチケットの売主の各々から各売主が承諾可能な最低価格を含むクルーズオペレータが定義した制限を含む規程を、前記規程を保存している規程データベースを介して受信する通信ポートと、
前記通信ポートに接続され、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較し、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記クルーズオペレータが定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記クルーズチケットを購入するように前記顧客を拘束するプロセッサと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とするシステム。
【請求項４】
前記規程データベースを有する遠隔サーバーを更に有することを特徴とする請求項１〜３のうちいずれか一項に記載のシステム。
【請求項５】
前記規程の一部を生成する少なくとも一の歳入管理システムを更に有することを特徴とする請求項１〜４のうちいずれか一項に記載のシステム。
【請求項６】
前記顧客が定義した条件は旅程を含むことを特徴とする請求項１又は３に記載のシステム。
【請求項７】
前記顧客が定義した条件はサービスレベルを含むことを特徴とする請求項１又は３に記載のシステム。
【請求項８】
前記購入申込が前記規程の許容範囲内にあれば、前記プロセッサは前記購入申込の前記顧客が定義した条件を修正した修正条件を有する代案を生成して前記顧客に前記通信ポートを介して送信することを特徴とする請求項１〜７のうちいずれか一項に記載のシステム。
【請求項９】
前記プロセッサは、前記顧客を拘束するときに航空券が予約されていない場合には前記支払識別子を利用して前記金融口座に罰金を科することを特徴とする請求項１に記載のシステム。
【請求項１０】
前記プロセッサは、前記顧客の前記購入申込に対する予約率を算出し、当該予約率に基づいて前記購入申込を拒否することを特徴とする請求項１に記載のシステム。
【請求項１１】
通信ポートと当該通信ポートに接続されたプロセッサとを有するコンピュータにより実行される航空券販売処理方法であって、
前記通信ポートが、申込価格を含む顧客が定義した条件を含む旅行に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信するステップと、
前記通信ポートが、複数の航空券の売主の各々から各売主が承諾可能な最低価格を含む航空会社が定義した制限を含む規程を、前記規程を保存している規程データベースを介して受信するステップと、
前記プロセッサが、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較するステップと、
前記プロセッサが、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記航空会社が定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記航空券を購入するように前記顧客を拘束するステップと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とする航空券の販売処理方法。
【請求項１２】
通信ポートと当該通信ポートに接続されたプロセッサとを有するコンピュータにより実行されるクルーズチケットの販売処理方法であって、
前記通信ポートが、申込価格を含む顧客が定義した条件を含む旅行に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信するステップと、
前記通信ポートが、複数のクルーズチケットの売主の各々から各売主が承諾可能な最低価格を含むクルーズオペレータが定義した制限を含む規程を、前記規程を保存している規程データベースを介して受信するステップと、
前記プロセッサが、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較するステップと、
前記プロセッサは、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記クルーズオペレータが定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記クルーズチケットを購入するように前記顧客を拘束するステップと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とする販売処理方法。
【請求項１３】
申込価格を含む顧客が定義した条件を含む通話に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信し、複数の通信業者の各々から各通信業者が承諾可能な最低価格を含む通信業者が定義した制限を含む規程を、前記規程を保存している規程データベースを介して取得する通信ポートと、
前記通信ポートに接続され、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較し、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記通信業者が定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記通話を購入するように前記顧客を拘束するプロセッサと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とする長距離通話処理システム。
【請求項１４】
前記購入申込は、前記購入申込を送信するように構成されている電話機から受信されることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項１５】
前記購入申込は、一以上の着呼者への通話パッケージに関するものであることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項１６】
前記購入申込は、所定期間の電話サービス契約に関するものであることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項１７】
前記購入申込は、所定金額の電話サービス契約に関するものであることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項１８】
前記顧客が定義した条件は、前記一以上の通話の時刻を特定していることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項１９】
前記顧客が定義した条件は、前記一以上の通話の最小継続時間を特定していることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項２０】
前記顧客が定義した条件は、前記一以上の通話の最大継続時間を特定していることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項２１】
前記顧客が定義した条件は、着呼者の電話番号を含むことを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項２２】
前記通信ポートは電話ネットワークに接続されていることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項２３】
前記通信ポートは電子ネットワークに接続されていることを特徴とする請求項１３に記載の長距離通話処理システム。
【請求項２４】
通信ポートと当該通信ポートに接続されたプロセッサとを有するコンピュータにより実行される長距離通話処理方法であって、
前記通信ポートが、申込価格を含む顧客が定義した条件を含む通話に関する購入申込と金融口座を特定する口座番号を含む支払識別子を前記顧客から受信するステップと、
前記通信ポートが、複数の通信業者の各々から各通信業者が承諾可能な最低価格を含む通信業者が定義した制限を含む規程を、前記規程を保存している規程データベースを介して受信するステップと、
前記プロセッサが、前記通信ポートを介して取得した前記購入申込を、前記通信ポートを介して前記規程データベースを検索することによって取得した前記規程と比較するステップと、
前記プロセッサは、前記購入申込に含まれる前記顧客が定義した条件が前記規程に含まれる前記通信業者が定義した制限を満足している場合に前記通信ポートを介して取得した前記支払識別子を利用して前記金融口座に課金することによって前記通話を購入するように前記顧客を拘束するステップと、
を有し、
前記プロセッサは、所定期間内に同一の顧客が提出した異なる申込価格を含む購入申込の数が所定数を超えた場合には前記所定数を超えた購入申込を拒否することを特徴とする長距離通話処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、製品の購入申込を提出した顧客に電子ネットワークを使用して当該製品の販売を処理する方法と装置に関する。
【背景技術】
【０００２】
ほとんどの製品販売処理システムは売主駆動であり、売主が製品に価格付け、包装、形成をし、買主はそれを承諾するかどうかを決定する。伝統的に、売主は買主を魅了して販売を完了しなければならない。従って、売主駆動システムでは、取引の宣伝広告費用と当該宣伝広告が不成功に終わるというそれに伴う危険は売主にある。
【０００３】
典型的に、商品と役務は売主駆動プロトコルを使用する小売環境で販売され、これにより売主は買主が承諾又は拒否する協定不能な価格を一般に設定する。他の商業形態の中にはより多くの弾力性と申込及び代案の交換を許容するものがある。例えば、競売では、買主は売主を得ず、代わりに売主が最終販売価格を集合的に決定する多数の買主を魅了し、売主は競売品が無条件で販売されていなければ最終販売価格を後で拒否することができる。ナズダック（ＮＡＳＤＡＱ）やニューヨーク株式取引所（ＮＹＳＥ：  Ｎｅｗ  Ｙｏｒｋ  Ｓｔｏｃｋ  Ｅｘｃｈａｎｇｅ）などの他の商業システムは交換駆動であり、買主と売主は効率的、公正的、規律正しい市場を提供することによって折り合う。かかる交換駆動システムは買主と売主のどちらも味方せず単に折り合い処理の発生を可能にする通信を実現するだけである。先物を取引する自動交換駆動商業システムの例は特許文献１に開示されている。
【０００４】
他方、買主駆動システムは、買主が申込条件を指図して売主が承諾するかどうかを決定するものである。例えば、「求人」広告は、雇用者が適任従業員の役務を配置購入することを期待しているので買主駆動の問い合わせである。問い合わせは多数の潜在的従業員に宣伝され、彼らは将来の雇用者に履歴書を送ることによって応答することができる。一般に、買主駆動システムはその他の製品販売処理システムよりも好ましい。例えば、買主駆動システムは、希望製品の購入の条項と条件に対してより多くの制御を買主に与えている。また、多数の潜在的売主が存在してもそれらの売主に広く広告する資力がなければ、買主は売主にその要求を伝える主導権を握ることができる。
【０００５】
一方的買主駆動システムは、指定業務の実行の申込の承諾に基づいて買主と売主の間で契約を完成させるものである。例えば、報酬システムでは、「買主」は、特定の仕事を完成する者への報酬の申込みを放送又は公表する。従って、一方的システムは、履行による承諾を可能にする限定された種類の取引にのみに利用可能である。一方、双方的買主駆動システムは、履行すべき相互の約定に基づき、買主と売主の間で契約を完成させるものである。しかし、双方的買主駆動システムは、無数の潜在的売主を配置して買主の購入要求を各売主に伝えるために、多くの時間とお金その他の資源を買主に投資するように要求する。しかし、潜在的に低価格な従来の双方的買主駆動システムを使用する顧客のいかなる利益も、通常、苦労して費やした時間とお金の量の方が勝っている。また、買主駆動システムは売主に固有の費用を同様に賦課する。もし各買主が異なる購入明細を有して非画一的言語で彼の要求を伝えれば、売主は各人の要求を検討理解するために多額の費用を支払わなければならない。更に、売主はしばしば個別的買主にその製品をカスタマイズすることに柔軟ではない。
【０００６】
定期的に使用される双方的買主駆動処理の例は、最低可能価格で商品や役務を大量に購入したい企業や政府などの大組織によって利用されるシステムである。まず、購入者は、購入希望物の数量と要件を述べている典型的に「申込要求（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｐｒｏｐｏｓａｌ：  ＲＦＰ）」と呼ばれる詳細な明細書を作成する。一旦最終決定されると、ＲＦＰは既知の潜在的供給者のリストに分配される。潜在的供給者は履行可能なものを識別するためにＲＦＰを選別し、その後、ＲＦＰで設定された締切りまでに買主に正式な拘束力のある申込みを提出するのに必要な時間と努力を投資するかどうかを決定する。一旦提出されると申込は買主によって評価され、選択された申込に対応する供給者には、取引価格でビジネスを「勝ち取った」旨が通知される。
【０００７】
大組織の購入量は供給者がビジネスを得ようと競争する価値のある機会を表しており、また、大組織は多数の供給者にその購入要求を伝える資力を有しているため、大組織はＲＦＰ処理が与える恩恵を最大限に利用することができる。その結果、大組織は、しばしば、多額の単位費用削減を、（紙用クリップや長距離電話サービスなど）特に商品又は商品役務に関して、また、（航空券やホテルルームなど）生鮮品について達成することができる。しかし、個人客は、一般に大組織の購買力と資力を持たないため、効果的にかかる双方的買主駆動システムに参加することはできない。
【０００８】
商業がインターネット固有の特長の利用を求めるにつれ、モール、カタログ、競売所などの多くの製品販売処理システムはインターネットで実行されるようになってきた。このアプローチは一般により優れた売主又は交換駆動システムを形成することを目的としているが、これによって商品と役務の販売はより効率的にされている。双方的買主駆動取引を実行するのにインターネットを利用する試みは既に幾つか存在しているものの、それらの試みはほとんど成功していなかった。例えば、買主は「求人」広告を小額又は無料で「電子掲示板」形式のインターネットサイトに掲載することができる。従って、顧客は本質的に、希望するまさにその製品を彼らに販売することを了解する多数の売主に対して、彼ら自身のＲＦＰを掲載することができる。しかし、実際は、潜在的売主が様々な「電子掲示板」サイトに頻繁に訪問し、典型的に多種多様な形式、条件、条項、言語様式を有する個々のＲＦＰに応答することは現実的ではない。また、売主は、以下の理由でこのような処理を使用することを躊躇する。即ち、（ｉ）ＲＦＰの真偽の保証がなく、（ｉｉ）個々の消費者と交渉する費用はしばしば高く、（ｉｉｉ）消費者と売主の間に達しうる（支払保証などの）いかなる合意も実行することが困難である。代わりに、多数の売主のいなければ買主はそのＲＦＰを掲載しようとする気力が減退する。
【０００９】
消費者と同様に、多くの産業は効果的な双方的買主駆動システムからの恩恵を得ている。例えば、最近、旅行業界は爆発的な世界的成長を遂げた。旅行容量の増加が継続するにつれて収容力が所期の旅行者量を超え、利用減少と価格圧力をもたらすことが予想されている。かかる価格付けと在庫の問題に対処するために、多くの旅行関連売主が利用可能な在庫価格を動的設定することによって収入を最適化する高性能な収入管理システム（ＲＭＳ）を開発した。一般に、在庫が最初に売主によって加えられると、売主の収入管理システムは、複数の価格階級を設定してその後その在庫と各価格階級に当てられた価格を割り当てることによって、その在庫に対する収入を最大化しようとするものである。収入管理システムは、その後、各価格階級内の予測需要に対する現実の需要の監視を継続し、在庫割り当てと所与の在庫に対する各価格階級の価格付けを動的に再評価する。
【００１０】
従来の収入管理システムは将来の旅行の需要を予測するのに高性能の手段を利用しているが、予測誤差は常に予期しない超過容量をもたらす。また、買主は、その収入管理システムを、空席と予測された座席に関連する所与のフライトの超過容量など、予想超過容量を予測するのに利用することができる。更には、価格戦争や悪天候状態などの予期しない外部事件が売主の超過容量に影響を与える場合もある。従って、かかる超過容量を減少しようとするために、売主は定期的に在庫割り当てと価格付けを再評価しなければならない。しかし、旅行関連売主は、価格戦争を開始したり独自の基底価格構造を危険にさらすことなしに（即ち、満額旅行者に対して満額費用を減じることなしに）、このような未販売在庫に対する公表価格を単に割り引くことはできない。従って、現在、旅行関連売主にとって、かかる超過容量を処理する効果的な方法は存在しない。
【００１１】
旅行関連売主は、有利な価格なら旅行に行くことを了解するレジャー旅行者に関する潜在的需要源が大きいことを認識している。しかし、売主の公表価格よりも安い買主が設定した特定の価格で買主からのレジャー旅行の申込を売主が承諾する効果的な方法は現在存在しない。特に、売主がその買主の申込を承諾すれば買主がその申込に従って旅行し、売主の競争相手や他の買主に知られれば売主の全収入構造に大打撃を与えるであろう売主の基底価格柔軟性を確認するのにその情報を利用しないということを売主が確信する効果的な方法は存在しない。
【００１２】
また、長距離電話市場は供給がほぼ飽和し、新事業に対する長距離通信業者間の競争は劇的に増加している。増加した競争の結果、長距離通話関連費用は低下し、劇的に低下しつづけることが米国と他の国々では予想されているが、長距離通話費用は多くの人々が好きなだけ長距離通話をすることを控えるのに十分高価なままである。また、ほとんどの発呼者は、一日の様々な時間帯に様々な地理的場所に発呼することに関連した価格構造を典型的に知らない。従って、長距離通話費用の識別制御ができないために、多くの人々が長距離通話をより多くかけてしまうことをためらってしまう。
【００１３】
法人客などの多くの大型客は、長距離通信業者とその長距離電話料金について交渉したり通信業者がその口座に値をつける十分な手段をしばしば有しているので、現在の電話システムでは長距離電話プロバイダーが平均的顧客と個別的に長距離電話料金を交渉することは実際的ではない。また、多くの大型客は幾つかの異なる長距離通信業者に口座を有しており、彼ら所有する構内交換機（ＰＢＸ）スイッチ又はその他の顧客構内装置において「最低費用ルート」技術を採用している。この技術により、彼らは最も費用が安い通信業者を、格納された価格情報を使用して、通話単位で選択することができる。ここでもかかる費用削減策は、典型的に一の長距離プロバイダーのみを有する平均的顧客には利用可能ではない。通話完了に最も費用が安い公表料金を提供する長距離通信業者を顧客が識別することを可能にするシステムが開発されたが、かかるシステムは個々の通信業者と実時間交渉を可能にしないし、一以上の通話が発呼者が特定した制限に従って完了することを可能にしない。
【００１４】
また、従来の商業システムでは、コンサート、劇、スポーツイベントなどのイベントチケットの再販売者がチケットの入手可能性を宣伝してチケット取引を完了することが制限されている。現在、チケット再販売者は、チケットの入手可能性を宣伝するのにインターネットの求人広告、電子掲示板又は「チャットルーム」を利用している。かかる宣伝広告は、一旦チケットが再販売されると公けの範囲から除去するのが困難である。従って、チケットを販売する者は、チケット後販売に問い合わせを得ることができる。また、買主は現実のチケットの物理的取得を要求し、イベント前の迅速な配達が問題となる。更に、チケットの買主と売主は相互に一般的不信を抱いている。買主がチケット再販売者に直面していなければ買主は典型的に配達の何らかな確信がなければチケットの支払いを了解しない。同様に、チケット再販売者は典型的にチケットを支払いがなければ前もって配達することを了解しない。しかし、従来のチケット再販売システムは、買主も売主も真偽性を保証する機構を何ら有していなかった。
【００１５】
上述した既知の商業システムの欠点に加えて、申込を承諾するかどうかを決定するために売主は第三者からの買主の申込に関連する情報をしばしば必要とする。例えば、手工芸品の潜在的買主は、手工芸品が信頼された第三者の「許可印」が付されていることを要求する。かかる印はその手工芸品が本物であることを認証し、その価値の査定も行うであろう。同様に、資金の潜在的貸主は潜在的借主のクレジット履歴又は「クレジットスコア」を要求する。貸主は、潜在的借主からかかる重要な情報を受け付けることは典型的にはしない。なぜなら、買主はよりクレジットの価値があるように見せるためにその情報を変更しようと試みるかもしれないからである。クレジット情報は信頼された第三者から得なければならない。
【００１６】
そこで、利率やローン額などの借主の特定した条件を有する資金借りの申込は、それ自体は、その申込を承諾するかどうかを決定するのに貸主にとって不十分である。潜在的貸主は、クレジット危険とクレジット価値に関してその申込が承諾可能であるかどうかを確信することができないであろう。従って、買主はかかる申込を有益に作成することができないであろう。特許文献２に開示されているシステムのように、金融製品の販売に関連して借主のクレジットリスクを評価する現在のシステムによれば、潜在的買主は希望ローン条件を特定することができない。また、特許文献２に開示されたシステムは、買う気のない人々が、無価値のローン申込書を有する金融製品の売主に殺到することを防止していない。
【特許文献１】米国特許第４，９０３，２０１号明細書
【特許文献２】米国特許第５，６１１，０５２号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１７】
従来の製品販売処理システムの上述した欠点から明らかなように、従来技術の欠点に注目し、個人客がその購入需要を潜在的売主に世界的に伝えるのに利用することができる双方的買主駆動システムの需要が存在する。また、買主の申込の条項及び条件を認証する双方的買主駆動システムの更なる需要が存在する。当事者間の契約紛争を解決し、システム内の買主と売主の信頼性を増加させ、買主が特定した申込に使用されるべき標準プロトコル、形式、用語及び文言を設定するために、かかる双方的買主駆動システムにおける第三者管理の需要も存在する。現実の需要が予期された需要に適合しないときに売主が超過容量を販売することができるシステムに対する更なる需要も存在する。買主が製品を、その製品の公表価格よりも典型的に低い買主によって設定された価格で得ることができる買主駆動システムに対する別の需要も存在する。更に、売主の公表価格構造を危険にせずに、売主が超過在庫又は容量の価格を刺激することができるシステムに対する更に別の需要が存在する。最後に、買主からの申込の承諾可能性を第三者からの申込関連情報に照らして売主が評価することができるシステムに対する更なる需要がある。
【課題を解決するための手段】
【００１８】
遠隔地にいる将来の買主と遠隔地にいる潜在的な売主との間で拘束力のある契約を完成する条件付購入申込管理システムが開示されている。かかるシステムは、メモリ装置とメモリ装置と通信可能に配置された処理装置とを有しており、処理装置は前記遠隔地にいる将来の買主から（ａ）少なくとも一の条件を含む購入の申込と、  （ｂ）当該少なくとも一つの条件に適合する購入用に資金が支払可能な汎用金融口座を特定する支払識別子を受信するように構成され、更に、処理装置は、その購入申込を複数の遠隔地にいる潜在的な売主に送信し、前記遠隔地にいる潜在的な売主の少なくとも一人から前記申込の無条件承諾を受信するように構成されている。本発明の一実施例においては、前記処理装置は、買主から購入の支払いを履行するのに支払識別子の利用を開始し、汎用金融口座がクレジットカード口座であるように更に構成されている。本発明の様々な実施例において、前記少なくとも一の条件が価格、数量、配達日、品質、地理的場所及び匿名性からなるグループから選択されることができる。
【００１９】
通信ポートと処理装置とを有している本発明の他の実施例によるシステムが開示されており、ここではＣＰＯ管理システムは所与のＣＰＯを承諾又は拒否することを、かかる権限をＣＰＯ管理システムに委託したある代理店基盤の売主に代わって、行うことができる。通信ポートは顧客から旅行に対する購入申込を入手して複数の売主から一以上の規程を受信する。購入申込は少なくとも一の顧客が定義した条件を含んでおり、規程の各々は一以上の売主が定義した制限を含んでいる。処理装置は、顧客が定義した条件が規程の少なくとも一つの売主が定義した制限の各々を満足しているかどうかを決定するために購入申込を規程に比較する。
【００２０】
一の実施例においては、ＣＰＯが一以上の売主によって承諾されれば、ＣＰＯ管理システムは、各承諾をしている売主が顧客に彼らの製品を直接販売及び後販売することができるようにするために後販売多重拘束処理を実行する。従って、顧客は依然として自分で各売主によって与えられた資料や刺激に基づいて、いずれの売主の承諾を利用するかを選択することができる。顧客はＣＰＯ管理システムによりＣＰＯの条件に従って拘束され、ＣＰＯが特定した商品又は役務を購入する義務を有するが、買主は、各承諾をしている売主によって直接にその顧客に与えられた資料や刺激に基づいて、いずれの売主を利用するかを決定することができる。
【００２１】
顧客が提出するＣＰＯは一以上の好ましい売主を特定することができる。従って、ＣＰＯ管理システムは一以上の売主がそのＣＰＯの承諾することを了解するかどうかを決定するためにそのＣＰＯを各特定された売主に与える。補助的な実施例においては、ＣＰＯ管理システムは、好ましくは、除外売主ＣＰＯ評価処理を実行して、特定された売主の一人がそのＣＰＯを承諾する前に、ビジネスを得る目的で、その顧客に代案を作成することができる除外された売主にそのＣＰＯを与える。ＣＰＯは、好ましい売主より前に又は同時に、除外された売主に与えられることができる。
【００２２】
通信ポートと処理装置とを有して、商品及び役務のパッケージ販売を処理するのに適している本発明の別の実施例によるシステムが開示されている。通信ポートは顧客からパーケージに対する購入申込を受信する。購入申込は各コンポーネント品の説明と資金が支払可能な汎用口座を特定する支払識別子を含んでいる。処理装置は、パッケージ購入申込を複数のコンポーネント購入申込に分解して、コンポーネント購入申込の各々が一以上の潜在的な売主によって承諾されるかどうかを決定する。コンポーネント購入申込の各々に対して承諾が受信されると顧客はこれによりパッケージを購入するように拘束される。
【００２３】
通信ポートと処理装置とを有して、一以上の通話に対する購入申込を処理するのに適している本発明の別の実施例によるシステムが開示されている。通信ポートは顧客から一以上の通話に対する購入申込を入手して、複数の潜在的通信業者にその購入申込を与える。購入申込は少なくとも一の顧客が定義した条件と資金が支払可能な方法を特定する支払識別子を含んでいる。処理装置は、一以上の通信業者が購入申込を承諾するかどうかを決定し、購入申込に対して承諾が受信されると顧客が通話を購入するように拘束する。
【００２４】
イベントチケットの再販売に適している本発明の他の好ましい実施例による方法は、チケットに対する保証された購入申込を中央制御装置に電子的に送信する潜在的な買主と、複数の潜在的な売主に前記申込を電子的に入手可能にする中央制御装置と、前記中央制御装置に前記申込の承諾を送信する最初に承諾する売主と、開催地で彼のチケット購入を確認するのに使用するコードと共にこの承諾を買主に送信する前記中央制御装置とを有している。
【００２５】
従って、本発明の一の好ましい実施例はチケット再販売者からチケットを購入する素早く簡単な方法を与え、彼らがチケット再販売市場の伝統的問題を回避することを可能にしている。更に、チケット再販売者は、潜在的買主によって与えられた保証された購入申込に基づいてチケットを販売することができる。また、本発明は、取引中及び取引後の両方で詐欺を防止する機構を含んでいる。
【００２６】
一般に、売主は買主からの申込の承諾可能性を第三者からの申込関連情報に照らして評価することができる本発明の更なる実施例によれば、中央制御装置は少なくとも一の条件信号を有する申込信号を受信する。申込信号は、顧客からの少なくとも一の条件を有する条件付購入申込を定義している。中央制御装置は、資金が支払可能な口座を特定する支払識別子信号も受信する。申込関連情報信号は第三者から受信する。情報信号は、条件付購入申込を提出する借主から出れば信頼されない関連情報を典型的に含んでいる。
【００２７】
本発明の更なる特徴と長所と共に、本発明のより完全な理解は以下に詳細な説明と図面を参照して得られるだろう。
【発明の効果】
【００２８】
本発明によれば、遠隔地にいる将来の買主と遠隔地にいる潜在的な売主の間で拘束力のある契約を完成することができる。
【発明を実施するための最良の形態】
【００２９】
以下、本発明の一実施例の方法と装置を図１、２、３及び４を参照して説明する。好ましい実施例では、本発明は、中央制御装置２００と、売主インターフェース３００と、買主インターフェース４００と、関連データベースとを有している。本発明は、条件付購入申込を買主から受け取り、潜在的な売主が見ることができるようにし、売主がそれらを拘束することを可能にしている。従って、買主は申込を通じて彼が従う言質を売主に伝えることができ、売主に対して、商品を製造することができれば買主は準備の整った支払力を有しているという確信を与える。
【００３０】
システム構築
本発明の装置と方法の第１実施例のシステム構築を図１乃至図４を参照して例示する。図１に示すように、本発明の装置は、売主インターフェース３００と、中央制御装置２００と、買主インターフェース４００と（総括的に「ノード」という）を有する。各ノードは、市内又は地方的電話交換会社によって与えられるもののように、公衆電話交換網を利用したインターネット接続を介して接続されている。接続は専用データ線、携帯、パーソナルコミュニケーションシステムズ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍｓ：  ＰＣＳ）、マイクロ波又は衛星ネットワークによって与えられてもよい。売主インターフェース３００と買主インターフェース４００とは中央制御装置２００と通信する入出力口である。
【００３１】
上述したコンポーネントを使用することによって、本発明は条件付購入申込を掲載し、それらを潜在的な売主に入手可能にし、売主が法律的に拘束力のある契約を形成するためにその申込を拘束することを可能にする方法及び装置を提供している。
【００３２】
図２に示すように、中央制御装置２００は、中央演算処理装置（ＣＰＵ）２０５と、暗号処理装置２１０と、ＲＡＭ２１５と、ＲＯＭ２２０と、支払処理装置２３０と、クロック２３５と、オペレーティングシステム２４０と、ネットワークインターフェース２４５と、データ記憶装置２５０とを有している。
【００３３】
十分なメモリと処理能力を有する従来のパーソナルコンピュータ又はコンピュータワークステーションは中央制御装置２００として使用することができる。一の実施例においては、それは、買主が生成したＣＰＯ１００を送受信するウェブサーバーとして動作する。中央制御装置２００は、通信処理及びデータベースサーチにおいて、大量の取引処理と多数の数学的計算を実行することができるものでなければならない。インテル社によって一般に製造されている１００ＭＨｚ  Ｐ５４Ｃなどのペンティアムマイクロプロセッサ(R)はＣＰＵ２０５に使用することができる。この処理装置は３２ビット構築を採用している。同等な処理装置はモトローラの１２０ＭＨｚ  パワーＰＣ６０４やサンマイクロシステムズの１６６ＭＨｚ  ＵｌｔｒａＳＰＡＲＣ−Ｉである。
【００３４】
モトローラ社によって一般に製造されているＭＣ６８ＨＣ１６マイクロコントローラは暗号処理装置２１０に使用することができる。これと同等な処理装置も使用することができる。このマイクロコントローラは、１６ＭＨｚ配列において１６ビット増加累積命令（ｍｕｌｔｉｐｌｙ−ａｎｄ−ａｃｃｕｍｕｌａｔｅ  ｉｎｓｔｒｕｃｔｉｏｎ）を利用しており、５１２ビットＲＳＡプライベートキー操作を実行するのに１秒もかからない。暗号処理装置２１０は、匿名取引を可能にするのと共に、買主及び売主からの通信の認証もサポートしている。暗号処理装置２１０はＣＰＵ２０５の一部として構成されてもよい。他の商業的に利用可能な特別の暗号処理装置はＶＬＳＩテクノロジーの３３ＭＨｚ６８６８又はセマフォール・コミュニケーションズ（Ｓｅｍａｐｈｏｒｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）の４０Ｍｈｚ  ロードランナー（Ｒｏａｄｒｕｎｎｅｒ）２８４である。
【００３５】
図２を再び参照するに、支払処理装置２３０が（インテルペンティアム(R)などの）従来のマイクロプロセッサを有しており、本装置の方法に付随する支払い、課金又はデビッドの転送及び交換をサポートしている。支払処理装置２３０もＣＰＵ２０５の一部として構成されてもよい。支払処理装置２３０によるクレジットカード取引処理は、オープンマーケット社（Ｏｐｅｎ  Ｍａｒｋｅｔ，  Ｉｎｃ．）によって製造されているセキュアウェブサーバー（Ｓｅｃｕｒｅ  Ｗｅｂｓｅｒｖｅｒ）など商業的に入手可能なソフトウェアによってサポートされることができる。このサーバーソフトウェアは、クレジットカード番号を電子的にインターネット上でオープンマーケット本社にあるサーバーに送信し、そこでカードの照合と処理が行われる。それらのインテグレーティド・コマース・サービス（Ｉｎｔｅｇｒａｔｅｄ  Ｃｏｍｍｅｒｃｅ  Ｓｅｒｖｉｃｅ）はウェブベースのビジネスを営むのに必要なバックオフィスサービスを与えている。サービスは、オンライン口座利用明細書、注文取り及びクレジットカード支払許可、クレジットカード紛争解決、自動販売税計算、ディジタルレシート作成、口座ベースの購入トラッキング、及び、低価格サービスの支払総計を含んでいる。
【００３６】
データ記憶装置２５０は、ＣＤ−ＲＯＭドライブやフラッシュメモリと共に、ハードディスク、磁気又は光記憶装置を有することができる。データ記憶装置２５０は本発明の取引処理に使用されるデータベースを含んでおり、買主データベース２５５と、売主データベース２６０と、ＣＰＯデータベース２６５と、代案データベース２６７と、売主応答データベース２７０と、購入確認データベース２７５と、契約詳細データベース２８０と、支払データベース２８５と、暗号キーデータベース２９０と、会計データベース２９５とを含んでいる。好ましい実施例においては、オラクル社（Ｏｒａｃｌｅ  Ｃｏｒｐｏｒａｔｉｏｎ）によって製造されるオラクル７（Ｏｒａｃｌｅ７）などのデータベースソフトウェアがこれらのデータベースを作成管理するのに使用される。データ記憶装置２５０は、買主口座２９７、売主口座２９８及び第三者預託口座２９９に関係する情報も格納している。
【００３７】
買主データベース２５５は、例えば、氏名、住所、クレジットカード番号、電話番号、ＩＤ番号、社会保障番号、電子メールアドレス、クレジット履歴、過去のシステムの利用、パブリック／プライベートキー情報等のフィールドに買主のデータを保存している。この情報は、買主が最初にシステムに登録するとき又は彼の最初のＣＰＯ１００を掲載する直前に得られる。買主データベース２５５も買主が生成した各ＣＰＯ１００のトラッキング番号と各売主応答１１０と買主のＣＰＯ１００に直結する代案１４０のトラッキング番号も含んでいる。
【００３８】
売主データベース２６０は、氏名、契約情報、パブリック／プライベートキー情報、支払いの好み、業種、販売商品などのフィールドに売主に関するデータを保存している。契約情報は、電話番号、ウェブページＵＲＬ、電子掲示板アドレス、ページ番号、電話番号、電子メールアドレス、ボイスメールアドレス、ファクシミリ番号又はその他売主に連絡をとる手段を含んでいる。登録の際、売主は拘束されたＣＰＯ１００に関する配達能力の証拠を示すことを要求されることができる。例えば、航空会社であれば、中央制御装置２００がその航空会社が所与のＣＰＯ１００を満足することができるかどうかを迅速に決定することができるように、彼らが役務を行っている都市の組のリストを提出することができる。
【００３９】
ＣＰＯデータベース２６５は、全てのＣＰＯ１００を、ステイタス、トラッキング番号、日付、時間、対象、価格、満了日、条件及び買主の識別番号などのフィールドでトラッキングする。このデータベースは、契約の詳細が作成可能なので、買主と売主との間に支払いに関する紛争が生じた場合に価値がある。ＣＰＯデータベース２６５も保証書１７２を格納することができる。
【００４０】
代案データベース２６７は全ての代案１４０をトラッキングする。このデータベースの構造は、代案１４０が特定のＣＰＯ１００に関連付けられることを可能にするＣＰＯトラッキング番号のフィールドを追加している以外はＣＰＯデータベース２６５と同一である。
【００４１】
売主応答データベース２７０は、売主の氏名、売主ＩＤ番号、日付、時間、売主応答トラッキング番号及び関連ＣＰＯトラッキング番号などのフィールドで全ての売主応答１１０をトラッキングする。
【００４２】
購入確認データベース２７５は、買主と売主に送信されたメッセージをトラッキングして、完了した取引（拘束された契約）を確認する。フィールドは、買主の氏名、買主のＩＤ番号、売主の氏名、売主のＩＤ番号、購入確認トラッキング番号及び関連ＣＰＯトラッキング番号を含んでいる。
【００４３】
契約詳細データベース２８０は、ＣＰＯ１００に含まれる形式背景条項を含んでいる。これらのフォーム条項は、買主が特定した条件間の溝を効果的に埋め、殆どのＣＰＯ１００に共通の包括契約詳細事項を特定する。
【００４４】
支払データベース２８５は、買主の氏名、買主ＩＤ番号、支払額及び関連ＣＰＯトラッキング番号などのフィールドで買主によってなされた全ての支払いをトラッキングする。このデータベースは主のクレジットカード番号を格納することもできる。
【００４５】
暗号キーデータベース２９０は暗号機能を可能にし、対称及び非対称キーを格納している。これらのキーは、ＣＰＯ１００、売主応答１１０、購入確認１２０、代案１４０及び買主応答１５０を暗号化及び解読するのに暗号処理装置によって使用される。
【００４６】
会計データベース２９５は、後日の分析用に検索されることを可能にするＣＰＯ１００の掲載関連取引情報を格納している。
【００４７】
買主口座２９７は、買主の氏名、銀行及びクレジット口座番号、デビット又はクレジット取引などのフィールドによって買主の口座に関連する全情報をトラッキングする。この口座は、買主の銀行で格納される口座データへのポインタになり得る。
【００４８】
売主口座２９８は、売主の氏名、銀行及びクレジット口座番号、デビット又はクレジット取引などのフィールドによって売主の口座に関連する全情報をトラッキングする。ＣＰＯ１００に対する買主の支払はこの口座に送られることができる。
【００４９】
第三者預託口座２９９は、売主口座２９８におかれる前に一時的に買主の資金を保持する口座である。
【００５０】
ネットワークインターフェース２４５は、買主と売主が各々買主インターフェース４００と売主インターフェース３００を介して通信するための出入口である。従来の内部又は外部モデムはネットワークインターフェース２４５として機能することができる。ネットワークインターフェース２４５は、ボードレート１２００から上の範囲でモデムをサポートするが、より多くの帯域が必要な場合には、かかる入力をＴ１又はＴ３線に結合することができる。好ましい実施例においては、ネットワークインターフェース２４５は、インターネット及び／又はアメリカオンライン、コンピサーブ又はプロディジーなどの商業オンラインサービスに接続され、買主と売主が広範囲のオンライン接続からのアクセスを許容する。幾つかの商業電子メールサービスは上述の機能を含んでいる。ＮＣＤソフトウェアは、エンタープライズネットワークとインターネット上で人々と情報を結合するために設計された機密保持（がなされている）サーバーベースの電子メールソフトウェアパッケージである「ポストオフィス（Ｐｏｓｔ．Ｏｆｆｉｃｅ，）」を製造している。その製品は、プラットフォーム独立でインターネットプロトコルに基づいてオープンスタンダードを利用している。ユーザーはファイル、グラフィックス、ビデオ又はオーディオなどの添付付きメッセージを交換することができる。システムは多数の言語もサポートしている。代替的に、ネットワークインターフェース２４５は、ボイスメールインターフェース、ウェブサイト、ＢＢＳ又は電子メールアドレスとして構成されることができる。
【００５１】
上述した実施例は、中央制御装置２００として動作する単一のコンピュータを説明しているが、当業者は機能が複数のコンピュータに分散可能であることを理解するであろう。一の実施例においては、中央制御装置２００は分散構築に構成され、データベースと処理装置は離れたユニット又は場所に収納される。幾つかの制御装置は主要処理機能を実行し、最低限、ＲＡＭ、ＲＯＭ及び汎用処理装置を含んでいる。これらの制御装置の各々は、他の制御装置とインターフェース装置と共に主要通信リンクとして機能するＷＡＮハブに取り付けられている。ＷＡＮハブはそれ自身最小限の処理能力を有することができ、主として通信ルーターとして機能する。当業者は、ほとんど無数の制御装置がサポート可能であることを理解するだろう。この構成はより動的で柔軟なシステムを生み出し、全システムに影響を与える破壊的なハードウェアの故障を受けにくい。信託サーバーの実施例はより詳細な分散環境を与え、操作サーバー１６０と、信託サーバー１６５と、保証代理人１７０とを説明している。これらのサーバーのハードウェアは、中央制御装置２００に対して説明されたのと同様に構成されるであろう。
【００５２】
図３及び図４は売主インターフェース３００と買主インターフェース４００とをそれぞれ説明している。例示的な実施例においては、それらは、キーボード、マウス又は従来の音声認識ソフトウェアパッケージなどの入力装置、ビデオモニターなどの表示装置、ＣＰＵなどの処理装置、モデムなどのネットワークインターフェースを有する従来のパーソナルコンピュータである。これらの装置は中央制御装置２００とインターフェース接続されている。代替的に、売主インターフェース３００と買主インターフェース４００もボイスメールシステムその他の電子又はボイス通信システムであってもよい。後述する実施例で更に説明するように、ファックス機やページャーなどの装置は適切なインターフェース装置にもなる。
【００５３】
さて、図３を参照するに、中央処理装置（ＣＰＵ）３０５、ＲＡＭ３１５、ＲＯＭ３２０、クロック３３５、ビデオドライバー３２５、ビデオモニタ３３０、通信ポート３４０、入力装置３４５、モデム３５０及びデータ記憶装置３６０を有する売主インターフェース３００が説明されている。暗号処理装置３３５とバイオメトリック装置３５５は以下に述べるようにより強力な認証のために加えられてもよい。上述の１００ＭＨｚ  Ｐ５４Ｃなどのペンティアムマイクロプロセッサ(R)はＣＰＵ３０５に使用されることができる。クロック３３５は、売主インターフェース３００により作成された売主応答１１０又は代案１４０をタイムスタンプする機能を備えた標準チップベースのクロックである。
【００５４】
モデム３５０は、作成される殆どの売主応答及び代案１４０がテキストベースであまり長くなければ高速データ転送を必要としない。暗号処理装置が必要ならば、上述のＭＣ６８ＨＣ１６マイクロコントローラが使用される。バイオメトリックデバイス３３５の構造を暗号認証の実施例に関連して以下に説明する。
【００５５】
データ記憶装置３６０は、コンナーペリフェラルズ（Ｃｏｎｎｅｒ  Ｐｅｒｉｐｈｅｒａｌｓ）によって製造されているものなど従来の磁気ベースのハードディスク記憶装置である。メッセージデータベース３７０は売主応答１１０と代案１４０とを達成するのに使用することができ、会計データベース３８０は支払記録を記録したり中央制御装置２００と通信したりするのに使用することができる。
【００５６】
さて、図４を参照するに、中央制御装置（ＣＰＵ）４０５、ＲＡＭ４１５、ＲＯＭ４２０、クロック４３５、ビデオドライバー４２５、ビデオモニタ４３０、暗号処理装置４３５、通信ポート４４０、入力装置４４５及びデータ記憶装置４６０を有する買主インターフェース４００が説明されている。これらのコンポーネントの全ては図３に説明されたものと同一であってもよい。
【００５７】
売主インターフェース３００又は買主インターフェース４００によって要求される通信を可能にすることができる商業ソフトウェアアプリケーションは多く存在し、その主要な機能はメッセージの作成と送信である。クォルコム社（Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ）によって製造されるユードラプロ（Ｅｕｄｏｒａ  Ｐｒｏ）は、例えば、適当な電子アドレスにメッセージを発送する通信ツールであるのと同様にメッセージの作成の編集ツールを与えている。中央制御装置２００がウェブサーバーとして構成されると、ネットスケープ社（Ｎｅｔｓｃａｐｅ  Ｃｏｒｐｏｒａｔｉｏｎ）からのネットスケープナビゲータウェブブラウザ（Ｎｅｔｗｃａｐｅ  ｎａｖｉｇａｔｏｒ  ｗｅｂ  ｂｒｏｗｓｅｒ）などの従来の通信ソフトウェアも使用することができる。買主と売主はネットスケープナビゲータブラウザをＣＰＯ１００、売主応答１１０又は代案１４０を送信するのに使用することができる。
【００５８】
オンラインの実施例
本発明の一実施例においては、買主と売主の間の通信は電子ネットワークを介してウェブサーバーとして動作する中央制御装置２００により行われる。買主は中央制御装置２００にログオンし、ＣＰＯ１００を作成し、それからネットワークからの接続を断つ。ＣＰＯ１００は、ＣＰＯ１００を中央制御装置２００のウェブページに掲載することによって、潜在的買主に入手可能にされる。アクティブなＣＰＯ１００が満了になっていないこと及び買主がＣＰＯ１００の拘束を選択した売主に支払うのに十分な利用可能なクレジットを持っていること確信するために定期的な点検が中央制御装置２００によって行われる。売主応答１１０は中央制御装置２００に電子的に送信され、それはＣＰＯ１００が拘束されたことを表示するために買主に連絡する。中央制御装置２００はＣＰＯ１００が拘束されるとすぐに売主にクレジットカード情報を転送する。
【００５９】
図５を参照すると、買主がＣＰＯ１００を形成する処理が説明されている。ステップ５００において、買主は買主インターフェース４００の買主モデム４５０を使用して中央制御装置２００にログオンして通信リンクを設定する。買主は個人、法人、パートナーシップ、政府その他いかなる主体であってもよいことに留意しなければならない。一実施例においては、中央制御装置２００はワールドワイドウェブにページを持っていて、買主は従来のネットスケープ社によって製造されるネットスケープナビゲータなどのウェブブラウザーソフトウェアのインターフェースを通じて情報を与えることができる。ステップ５１０において、買主は、可能対象リストから選択することによって購入希望商品の対象を選択する。ボックス５１５に示すように対象は航空券、ホテルルーム、レンタカー、保険、不動産、洋服などを含んでいる。対象が選択されると買主インターフェース４００のビデオモニタ４３０に用紙が表示される。この用紙は買主が記入する幾つかの空欄を有する電子契約であり、各空欄がＣＰＯ１００の条件を表している。
【００６０】
ステップ５２０において買主は商品の説明を入力する。例えば、出張旅行者はサンフランシスコからニューヨークまで飛行機で飛びたいかもしれない。商品の説明は、５月７日に出発して５月１２日に戻るそれらの都市の間の２枚のファーストクラス往復チケットとなるかもしれない。用紙には出発都市、目的都市、出発日、帰りの日、チケット番号、サービスのクラス等のための欄がある。買主は単に空欄を埋めるだけである。買主はその後他の条件をステップ５３０で追加する。例えば、買主は真夜中前に目的都市に到着する直行便チケットのみを希望などとすることができる。これらの条件はＣＰＯ１００に同様に入力されるであろう。ボックス５３５に表示されているように、フライトは真夜中前に到着しなければならず、ホテルルームは禁煙でなければならず、又は、レンタカーは小型以外でなければならないという条項を含んでいる。条件はＣＰＯ１００の条項であり、買主は特別の要求を仕立てることができる。条件はその他の条件に依拠してもよい。例えば、一の条件は５つの他の特定の条件の４つが満足されていなければならないとすることもできる。代替的に、ＣＰＯ１００の各条件はポイント値を与えられることもでき、ＣＰＯ１００が条件がある合計ポイント値までは満足されなければならないと要求することもできる。例えば、買主は窓側の座席が２ポイントで通路側の座席が１ポイントで直行便が４ポイントとするなどを表示することができる。ＣＰＯ１００は、ＣＰＯ１００の条件を満足するためには１０「ポイント」が適合していなければならない旨を要求することができる。条件は、ＣＰＯ１００の最初の所期の拘束後２４時間は、他の売主は拘束を申込み、より有利な申込みが受信されない場合にのみ元の拘束している売主は契約を完了することができる旨を表示することもできる。条件は外部事件に依拠してさえいてもよい。例えば、買主は、目的都市に１１月に雪が降る場合にのみ航空券を買うことを申込むＣＰＯ１００を作成することができる。
【００６１】
ステップ５４０において、買主は必要があればＣＰＯ１００に満了日を追加する。これにより、買主は、彼の要求が変更した後に、後日拘束されることを心配せずにＣＰＯ１００を掲載することができる。ステップ５５０において買主は価格を入力する。レンタカーのＣＰＯ１００においては、例えば、買主は３日間のレンタルに対して５０ドルの価格を入力することができる。ステップ５６０において、買主は名前又は独自のユーザーＩＤ番号をＣＰＯ１００に添付する。このＩＤ番号は買主がサービスを登録すると中央制御装置２００によって受信されるか買主によって選択されてその後中央制御装置２００によって電話登録される。中央制御装置２００は、買主ＩＤ番号のデータベースを買主データベース２５５に保存し、独自の番号のみを発行（又は許可）する。緩やかな機密保持で十分であれば、独自性と暗記の容易性のためにユーザーの電話番号はＩＤ番号として機能することができる。追加的な機密保持が要求されれば、暗号の実施例で説明する手続が実行されてもよい。
【００６２】
上述の要素が一旦発展すると買主はそれらを中央制御装置２００にステップ５７０で送信する。買主はＣＰＯ１００の条件を入力した画面上の「送信」ボタンをクリックすることによってこれを行う。ステップ５８０において、完全なＣＰＯ１００を形成するために、法律定型的文言がＣＰＯ１００のコンポーネントに加えられる。法律文言は、複数段落を格納する契約詳細データベース２８０から引き出される。これらの段落は完全なＣＰＯ１００を形成するために上記の契約要素と互いに結合される。ＣＰＯ１００が法律契約としての認識を防止する欠如している要素は売主の氏名と署名のみである。
【００６３】
ワールドワイドウェブベースのインターフェースの代わりに、買主はＣＰＯ１００データを電子メール、ボイスメール、ファクシミリ又は郵送で送信することもできる。ボイスメールを使用すると、買主は中央制御装置２００に電話してオーディオ形式でＣＰＯ１００を残す。これらのＣＰＯ１００は、中央制御装置でディジタルテキストに置き換えられるか、潜在的な売主に同一のオーディオ形式で入手可能にされる。郵便の実施例においては、中央制御装置２００はルーターとして動作し、ＣＰＯ１００を潜在的売主に発送し、必要があればＣＰＯ１００の複数の写しを形成する。ＣＰＯ１００は中央制御装置２００が操作する電子掲示板又はウェブページに掲載されることもできる。中央制御装置２００は複数の送信方法をサポートしており、広範なＣＰＯ１００の形式を可能にしている。しかし、幾つかのフォーマットは中央制御装置２００によって更に処理される前に変更されてもよい。例えば、紙形式で郵送されたＣＰＯ１００はディジタルテキストを作成するために、光学文字認識ソフトウェアを使用してスキャンされてディジタル化される。これらの実施例は以下に述べるオフラインの実施例においてより詳しく説明する。
【００６４】
さて、図６を参照するに、ＣＰＯ１００が潜在的売主に入手可能にされる前に十分なクレジットがＣＰＯ１００の述べられた価格をカバーするのに利用可能であるかどうかを調べるためにＣＰＯ１００は受信されてチェックされる。ステップ６００において、中央制御装置２００は、価格と満了日情報をＣＰＯ１００から抽出する。ステップ６１０において、支払処理装置２３０は、クレジットカード清算所にＣＰＯ１００価格の事前許可を提出する。これは、買主のクレジットカードについて利用可能なクレジットの一部を「ロックする」機能を果たし、彼がこのクレジットをＣＰＯ１００がアクティブな間は使用することを防止する。ステップ６２０において、クレジットカード精算所は事前許可に応答して十分なクレジットが利用可能であるかどうかを表示する。もし十分な資金がＣＰＯ１００の価格をカバーするのに利用可能でなければ別のクレジットカード番号が買主からステップ６３０で要求される。一旦追加クレジットカード番号が送信されると中央制御装置はその後事前許可をステップ６１０で再提出する。ステップ６４０において、ＣＰＯ１００の満了日がチェックされてそれが既に満了したかどうかが調べられる。もし満了していたら、ＣＰＯ１００はステップ６５０で拒否されて買主に戻される。ＣＰＯ１００が未だ満了していなければステップ６６０で承諾される。
【００６５】
さて、図７を参照するに、ＣＰＯ１００がアクティベートされて潜在的売主に入手可能にされる実施例が示されている。ステップ７００において、独自のトラッキング番号がＣＰＯ１００に追加される。中央制御装置はＣＰＯ１００にステップ７１０でタイムスタンプし、その後ＣＰＯ１００をＣＰＯデータベース２６５に格納する。ＣＰＯデータベース２６５は各ＣＰＯ１００の記録を含んでおり、ステイタス、対象、トラッキング番号、タイムスタンプ、商品の説明、価格、満了日、条件及び買主ＩＤ番号などのフィールドを含んでいる。ステイタスフィールドは、「係属中」、「アクティブ」、「満了」及び「完了」の値を有している。「係属中」のステイタスは、ＣＰＯが現在潜在的売主に入手可能にされていないことを意味する。それは中央制御装置２００によって処理中であるか、買主によって一時停止されている。「アクティブな」ＣＰＯ１００は潜在的売主に入手可能であり拘束可能である。「満了した」ＣＰＯ１００はもはや拘束されることはできない。売主によって拘束されたＣＰＯ１００は「完了」のステイタスを有する。
【００６６】
ステップ７２０で格納された後、ＣＰＯ１００は一連の処理ステップを経ることができる。必要があれば、一のステップは言語翻訳であり、ＣＰＯ１００が書かれなければならない標準言語を作成したり、それが送信される売主に最も適切な言語に翻訳したりする。この翻訳は中央制御装置２００の言語専門家によって、又は、システムソフトウェア（Ｓｙｓｔｅｍ  Ｓｏｆｔｗａｒｅ）によって製造されるシステムプロフェッショナル（Ｓｙｓｔｅｍ  Ｐｒｏｆｅｓｓｉｏｎａｌ）などの自動翻訳ソフトウェアによってなされる。英語へ／からフランス語、イタリア語、ドイツ語、スペイン語、ポルトガル語及び日本語の１２の双方向言語の組み合わせを利用することができる。必要があれば、別のステップがスペル又は文法の誤りを編集する。ＣＰＯ１００は明確化のために見直されることもできる。不明確な条項又は条件を有するいかなるＣＰＯ１００も買主に戻されて明確にするように求められる。「シカゴ」の目的都市をリストに加えている買主は明確化又は訂正のためにＣＰＯ１００を戻すことができる。
【００６７】
再び図７を参照するに、ＣＰＯ１００に対するデータベース記録のステイタスがステップ７３０で「アクティブ」に設定されている。ステップ７４０で、ＣＰＯ１００の対象は対象フィールドから抽出される。ステップ７５０で、ＣＰＯ１００は適当な対象領域に掲載される。これにより中央制御装置２００は最も適切な売主にのみＣＰＯ１００を表示することができる。ワールドワイドウェブ環境において、中央制御装置２００は各可能な対象領域毎にウェブページを有している。従って、航空券を要求している全てのＣＰＯ１００は航空券ウェブページに表示されるであろう。これにより、潜在的売主は、彼らが与えることができる商品の対象に行けば彼らが拘束を希望する適当なＣＰＯ１００をより簡単に見つけることができるようになる。代替的な実施例においては、ＣＰＯ１００は、個別的に又はグループで潜在的売主に電子的に郵送される。潜在的売主は、全てのＣＰＯ１００、彼らの対象領域にあるＣＰＯ１００のみ、又は、特定条件を表しているＣＰＯ１００のサブセットを受信することを選択することができるであろう。例えば、レンタカー企業は高級車に対する全てのレンタカーＣＰＯ１００の送信を要求することができる。
【００６８】
ＣＰＯ１００が売主に送信される実施例においては、売主インターフェース３００に対して幾つかのハードウェアオプションが存在することに留意することが重要である。適当な売主インターフェース３００は、ファックス機と、無線接続を有するパーソナルディジタルアシスタント（ＰＤＡ）と、ビーパー又はページャーを有する。例えば、珍しい硬貨の売買業者はＣＰＯ１００がモルガンシルバードル（Ｍｏｒｇａｎ  Ｓｉｌｖｅｒ  Ｄｏｌｌａｒｓ）に対して現れるたびに彼にビーという信号を送るように中央制御装置２００に命令し、ＣＰＯ１００の詳細をビーパーネットワーク上で与えたり、更なる詳細事項のために中央制御装置２００にログオンするよう売主に通知することができる。
【００６９】
さて、図８を参照するに、ＣＰＯ１００のメインテナンスの手続が示されている。ステップ８００で、中央制御装置２００はＣＰＯデータベース２６５をサーチする。ステップ８１０で、ＣＰＯ１００の各データベース記録の満了データフィールドが現在の日付と比較される。ＣＰＯ１００の満了日が現在の日付前であればＣＰＯ１００のステイタスはステップ８２０で「満了」に変更される。ステップ８３０において、支払処理装置２３０は、買主のクレジットカードが未だ有効であるかどうかを確認するためにクレジットカード精算所に連絡をとる。クレジットカードが有効でなければＣＰＯ１００のステイタスはステップ８４０において「満了」に変更される。メインテナンス処理は、全ての「アクティブな」ＣＰＯデータベース記録が一旦検査されるとステップ８５０で完了する。
【００７０】
図９は潜在的売主がＣＰＯ１００を選択する処理を示している。ステップ９００で、潜在的売主は、売主インターフェース３００のモデム３５０を使用して中央制御装置２００にログオンする。ステップ９１０で、潜在的売主は適当な対象領域を選択する。例えば、コンベンション用の部屋の予約がたった今キャンセルとなったシカゴの大ホテルは、それらの日付においてシカゴに部屋を要求しているＣＰＯ１００を見つけるという目的でホテル対象領域をサーチする。ステップ９２０で、潜在的売主は利用可能なＣＰＯ１００（即ち、「アクティブ」のステイタスを有するもの）のリストをブラウズする。ＣＰＯ１００は最小詳細事項でリストに加えられて更なる情報は潜在的売主がそのＣＰＯ１００の拘束に興味を持った場合にのみ入手可能とすることができる。ホテルＣＰＯ１００は「ホテル９／１６／９６シカゴ一人分８５ドル」としてリスとされることができる。ＣＰＯ１００についてより多くの情報を希望する潜在的売主はステップ９４０で追加データを要求することができる。一の実施例においては、各ＣＰＯ１００は、完全な詳細事項を与える別個のウェブページにハイパーリンクされている。潜在的売主はＣＰＯ１００をクリックすれば即座に補助的詳細事項のページに移行される。この詳細事項はベッドの希望の大きさ、フィットネス施設及びレストランを含むことができる。別の実施例においては、ＣＰＯ１００は、電子メール、ファックス、電話、ビーパー等を介して、売主に直接に電子的に送信される。
【００７１】
図１０及び図１１は、ＣＰＯ１００が売主によって拘束される処理を示している。ステップ１０００で、潜在的売主は拘束したいＣＰＯ１００を選択し、拘束したい意図を表す売主応答１１０を発する。ステップ１０１０において、中央制御装置２００は売主応答１１０を潜在的売主から受信する。中央制御装置２００は、その後、売主応答１１０をタイムスタンプして売主の身元の真偽を、彼の商品配達能力を確認するのと共に認証する。タイムスタンプにより、中央制御装置２００は、受信される最初の無条件承諾を決定することができる。２つの売主応答１１０が互いに数秒以内に受信されれば、タイムスタンプにより中央制御装置２００はどちらが最初に受信されたかを決定することができる。代替的に、タイムスタンプは、売主インターフェース３００から送信されるときに売主インターフェース３００のクロック３３５を使用して売主応答１１０に添付されてもよい。
【００７２】
売主の身元の認証では、中央制御装置２００は売主応答１１０から売主ＩＤを抽出して売主の身元を売主データベース２６０で調べる。売主データベース２６０の情報は、その後、売主の商品配達能力を表示する。例えば、売主が航空券のＣＰＯ１００を拘束することができる前に、中央制御装置２００は売主が航空会社であることの真偽を確かめなければならない。必要があれば、中央制御装置２００は、売主が要求された特定の商品を与えることができるかどうかを確認することができる。売主が航空会社であることを確認するだけでなく中央制御装置２００はそれが買主によって要求された都市の組について役務を提供しているかどうかを確認することもできる。別の実施例においては、売主は売主応答１１０をＣＰＯ１００に組み込み、その契約が合意された旨の表示を加えることによってＣＰＯ１００に署名をする。この表示はディジタル署名であるか売主を表す記号又は表示を付加する。
【００７３】
中央制御装置２００は、その後、ＣＰＯ１００のステイタスをステップ１０３０で確認し、ステップ１０４０でＣＰＯ１００のステイタスが「アクティブ」であるかどうかを決定する。ＣＰＯ１００が現在「アクティブ」であれば、独自のトラッキング番号がステップ１０６０で売主応答１１０に付加される。中央制御装置２００は、その後、ステップ１０７０で売主応答１１０を売主応答データベース２７０に格納する。ＣＰＯ１００のステイタスがステップ１０４０で「アクティブ」でなければ、ステップ１０５０において売主応答１１０は中央制御装置２００によって拒否されて潜在的売主に戻される。
【００７４】
別の実施例においては、売主は売主応答１１０を直接に買主にステップ１０１０で送信する。買主は、その後、売主応答１１０を中央制御装置２００に確認と認証のために送信するか、売主応答１１０を確認と認証なしで受け付けることを選択してもよい。
【００７５】
図１１において、選択されたＣＰＯ１００に対するクレジットカード番号と許可コードが売主に送信されると支払処理がステップ１１００で開始される。ステップ１１１０において、ＣＰＯ１００は拘束され、ＣＰＯ１００は買主と売主との間で法的に拘束力のある契約に変化する。拘束処理はＣＰＯ１００のステイタスが「完了」に変わることを要し、その後の売主がそのＣＰＯ１００を拘束できないようにする。拘束処理は、売主ＩＤがＣＰＯ１００に付加されることも要する。ステップ１１２０で中央制御装置２００は購入確認１２０を売主に送信して、ステップ１１３０で、その後、それを買主に送信する。
【００７６】
別の実施例においては、多数の売主がＣＰＯ１００を拘束することができる。この場合、ＣＰＯ１００は、所与の数の売主が応答するまで、その「アクティブ」のステイタスを保存することができ、その後にのみＣＰＯ１００のステイタスは「完了」に変わる。例えば、珍しい硬貨の売買業者は、特定の種類のコインを１００ドルで申込むＣＰＯ１００を掲載することができる。ＣＰＯ１００の条件は、申込みは最初の１０人の売主が応答するまでオープンであると述べることができ、１０の拘束可能な契約を許容する。別の選択肢は、ＣＰＯ１００がいかなる数の拘束に対しても、あるいは、買主が利用可能な資金までのいかなる数の拘束に対してもオープンな場合である。
【００７７】
システムのプロバイダーが収入ストリームを駆動することができる方法は数多く存在する。一の実施例においては、均一料金が提出されるＣＰＯ１００毎に変更される。所与の期間中はいくつの数のＣＰＯ１００であってもカバーするであろう均一料金も存在してもよく、買主は買主が新聞を購読するとそのサービスに加入することができる。別の実施例では、中央制御装置２００は、売主がＣＰＯ１００の価格の歩合しか受け取らない割引値を計算する。別の実施例においては、宣伝広告者はＣＰＯと共にメッセージをリストに加えてもらうために料金を支払い、システム運営資金を補助する。代替的に本発明の方法と装置は支払機能なしで利用されてもよい。
【００７８】
図１２は買主と売主との間の商品の交換を示している。ステップ１２００で、売主は特定商品を買主に移転する。この移転はディジタル商品と同様に物理的商品の配達を伴う。物理的商品は車、宝石、コンピュータ装置などを含むだろう。ディジタル商品は文書、チケット、アクセスコードなどを含むだろう。例えば、ホテルはホテルのチェックインの際に提示される確認番号を買主に移転することができるだろう。ステップ１２１０で、それらがＣＰＯ１００の全条項及び条件を満たしているかどうかを調べるために買主は配達された商品を検査する。例えば、ホテルルームを購入する買主は、部屋が正しい日付で正しい都市になされているかどうかを確認するであろう。ステップ１２２０において、商品がＣＰＯ１００に述べられているように買主の条件に適合しなければ買主は中央制御装置２００の調停者に紛争解決のために連絡をとる。この処理は後述する紛争解決の実施例においてより詳細に説明する。ステップ１２４０で取引は完了する。
【００７９】
支払いの好み
図１３は、中央制御装置２００が買主口座２９７を設定するプロトコルを示している。ステップ１３００で、買主は好ましい支払方法を選択する。好ましい方法はクレジットカード、パーソナルチェック、電子資金移転、ディジタルマネーなどを含むことができるであろう。ステップ１３１０で、買主は、好ましい支払方法に対応する支払データを中央制御装置２００に転送する。ボックス１３１５に表示されているように、かかる支払データはクレジットカード番号又は銀行口座番号を含むことができるであろう。しかし、これらの支払方法は、多くの均等な、業界で普通に知られた支払方法も使用されることができるので、単なる例示である。例えば、買主がクレジットカードによる支払を希望すれば、支払データは彼のクレジットカード口座番号、満了日、発行機関名及びクレジット限度を含むであろう。電子資金移転の場合には、支払データは買主の銀行名と彼の口座番号を含む。ステップ１３２０で、中央制御装置２００は、支払データと支払いの好みを支払データベース２８５に格納する。
【００８０】
ステップ１３３０において、中央制御装置２００は、買主が移転するお金を格納するか、システム外の買主の口座へのポインターとして機能する買主口座２９７を設定する。例えば、クレジットカードを利用する買主にとって、買主口座２９７はクレジットカード番号、満了日及び発行機関名を含んでいる。買主は、従来の当座預金口座のように機能するであろう買主口座２９７に格納されるために中央制御装置２００にお金を移すこともできる。中央制御装置２００は買主口座２９７に記載された売主に小切手を送るであろう。代替的に、中央制御装置２００は、電子的に資金を買主口座２９７から売主口座２９８に直接に移転することもできる。ステップ１３４０で、中央制御装置２００は、資金が利用可能であることを確認するために銀行又はカード発行者に連絡をとる。従って、買主は、買主口座２９７を設定するために利用可能なクレジットなしにクレジットを使用することはできない。
【００８１】
上述のプロトコルは売主にも同様に適用可能で売主口座２９８の形成を可能にする。主な相違は、売主口座２９８は主として預金に使用され、受け取った商品が承諾可能ではないと買主が発見した場合の預金返還又はリファンドの場合にお金は売主から買主に流れる。利用可能な資金の確認は従って売主にとって重要ではない。
【００８２】
オンラインの実施例は中央制御装置２００がクレジットカード情報を処理のために売主に送信するプロトコルを説明しているが、支払が買主から売主に移転される支払プロトコルがもちろん多く存在する。一の実施例では、クレジットカードの処理は売主ではなく中央制御装置２００が行う。中央制御装置２００は、買主のクレジットカード番号を支払データベース２８５で調べる。このクレジットカード番号は支払処理装置２３０に送信される。支払処理装置２３０は許可番号を得るためにクレジットカード精算所に連絡をとる。請求額が買主の月別明細書のクレジットカード明細書に現れる。精算所はこの額を売主の口座２９８に記録する。中央制御装置２００は支払いがなされたことを表示するために支払データベース２８５を更新する。中央制御装置２００は、支払情報を各当事者に与えることによって、買主と売主との間に直接支払がなされるように調整することもできる。例えば、買主は売主の当座預金口座番号を受け取ることができるだろう。口座情報はＣＰＯ１００と売主応答１１０に埋め込まれて、買主と売主が一旦ＣＰＯ１００の写しを各々得ると支払いの完了を可能にすることができるだろう。
【００８３】
別の支払方法はディジタルキャッシュを使用する手続を含んでいる。中央制御装置２００は、支払データベース２８５で買主の電子配達アドレスを調べる。このアドレスは支払処理装置２３０に送信され、買主からディジタルキャッシュがダウンロードされる。中央制御装置２００は支払がなされたことを表示するために支払データベース２８５を更新する。このアドレスは、ディジタルキャッシュが電子メールで移転されるならば電子メールアドレスか、ディジタルキャッシュのオンライン移転の受け入れを可能にするインターネットプロトコルアドレスであってもよいだろう。この電子配達アドレスは支払処理装置２３０に送られる。ディジタルキャッシュは売主口座２９８に又は直接に売主にダウンロードされる。中央制御装置２００は支払がなされたことを表示するために支払データベース２８５をその後更新する。これらのディジタルキャッシュプロトコルを使用すると、買主は電子用紙にＣＰＯ１００と支払いを含むことできる。
【００８４】
支払を実行するのにディジタルキャッシュプロトコルを利用すること例は当業界で周知であるのでここでは詳細に説明しない。参考のため、当業者はダニエル・Ｃ・リンチ（Ｄａｎｉｅｌ  Ｃ．  Ｌｙｎｃｈ）とレズリー・ランドクイスト（Ｌｅｓｌｉｅ  Ｌｕｎｄｑｕｉｓｔ）のディジタルマネー（Ｄｉｇｉｔａｌ  Ｍｏｎｅｙ）、ジョンウィリー＆サンズ（Ｊｏｈｎ  Ｗｉｌｅｙ  ＆  Ｓｏｎｓ）、１９９６年刊又はセス・ゴディン（Ｓｅｔｈ  Ｇｏｄｉｎ）のプレゼンティング・ディジタルキャッシュ（Ｐｒｅｓｅｎｔｉｎｇ  Ｄｉｇｉｔａｌ  Ｃａｓｈ）、サムズネットパブリシング（Ｓａｍｓ  Ｎｅｔ  Ｐｕｂｌｉｓｈｉｎｇ）、１９９５年刊を参照ことができる。
【００８５】
支払延期の実施例
オンライン実施例は売主がＣＰＯ１００を拘束すると直ちに支払いを受け取るプロトコルを説明しているが、商品が買主に受け取られるまでは又はある所定の日付までは支払いが延期される他の実施例が実行されてもよい。一部払いや分割払いも本システムによってサポートされる。
【００８６】
第三者預託口座２９９は売主が商品の配達を完了するまで支払いを延期することを可能にし、買主が実際に支払いをすることを同時に確保している。中央制御装置２００は、第三者預託口座２９９を一時的に保持する口座として設定する。売主がＣＰＯ１００をステップ１１１０で拘束すると資金は買主口座２９７から第三者預託口座２９９に移転される。商品が買主に受け取られた後にのみ資金は第三者預託口座２９９から売主口座２９８に移転される。買主はディジタル署名された解放メッセージを中央制御装置２００に送信して、第三者預託された資金が売主に解放されることを許可することができる。
【００８７】
別の実施例では、ＣＰＯ１００が拘束されると買主は一部払いをし、商品が受け取られるとその後支払いを完了する。拘束されて支払われるＣＰＯ１００の申込価格の一部は、ＣＰＯ１００の条件でありＣＰＯ１００が拘束されると支払データベース２８５に格納される。中央制御装置はこの資金の一部をステップ１１１０で解放し、商品がステップ１２００で配達されると残りの部分を開放する。拘束されるとなされる一部払いは返却不能である。これにより、例えば、ホテルは、２日前通知でキャンセル可能なホテルルームの予約を販売して、２日以内キャンセルは預金の喪失につながるようにすることができる。
【００８８】
別の実施例では、ＣＰＯ１００は分割払いの利用を説明している。最初の支払はＣＰＯ１００が拘束されるとなされ、ＣＰＯ１００の条件に特定されているように定期的な支払いが続く。支払いがなされるべき日付は支払データベース２８５に格納される。
【００８９】
代案の実施例
本発明の一実施例においては、売主はＣＰＯ１００に、それを拘束せずに修正及び／又は追加条件を有する代案を提示することによって、応答する。例えば、航空会社は、５００ドルのファーストクラスチケットのＣＰＯ１００を見るかもしれない。航空会社は、６００ドルであれば販売を了解することができ、従ってＣＰＯ１００を拘束することを選択するよりは代案を展開して発行することを希望する。この代案は、売主が買主を拘束するのではなく買主が売主を拘束する点を除けばＣＰＯ１００に類似している。また、代案は、複数の売主に向けられるＣＰＯ１００と異なり、特定の当事者（買主）に向けられる。
【００９０】
図１８は代案１４０の発生を示している。ステップ１８００で、潜在的売主は代案作成を希望するＣＰＯ１００を選択する。ステップ１８１０で、売主は修正条件を有する代案を準備する。売主は買主がＣＰＯ１００を生成するのに使用したのと同一の処理（ステップ５００乃至５８０）に従って代案１４０の条件を選択する。代替的に、売主はＣＰＯ１００の電子的な写しを提示されて売主が変更を希望する条件を編集することが許される。例えば、レンタカー会社は、高級車１日１０ドルの買主の要求をとり、小型車１日１２ドルの代案を作成する。ステップ１８２０で、売主はＣＰＯ１００のトラッキング番号を代案１４０に添付する。中央制御装置２００は、代案１４０をステップ１８３０で受信し、「アクティブ」のステイタスを設定する。中央制御装置２００は、その後、独自のトラッキング番号をステップ１８４０で代案１４０に添付し、ステップ１８５０でそれを代案データベース２６７に格納する。中央制御装置２００は、ステップ１８６０で代案１４０が送信される買主を見つけるために、代案１４０に添付されたＣＰＯ１００のトラッキング番号を抽出する。
【００９１】
図１９は、買主が代案１４０に応答する処理を示している。ステップ１９００で、買主は代案１４０を拘束すべきかどうかを決定する。彼が拘束しなければ、代案１４０は潜在的売主にステップ１９１０で戻される。買主が拘束を決定すると、買主応答１５０が中央制御装置２００にステップ１９２０で送信される。ステップ１９３０において、資金が買主口座２９７から除去されて売主口座２９８に置かれる。ステップ１９４０において、代案１４０のステイタスは「完了」に変わる。購入確認１２０がステップ１９５０で売主に送信され、ステップ１９６０で買主に送信される。商品交換手続は図１２に説明されたように完了する。
【００９２】
オフラインの実施例
本発明の一実施例では、買主と売主はオフライン方法で中央制御装置２００と交信する。電子メールを送信したりウェブベースのサーバーを利用したりする代わりに、買主と売主は電話、ファックス機、郵便その他のオフライン通信手段を使用する。
【００９３】
例えば、買主はＣＰＯ１００を生成するのに電話を利用することができる。買主は中央制御装置２００に電話して代理人に接続される。買主は、対象、商品説明、条件、満了日、価格などのＣＰＯ１００の条件を与える。買主は、中央制御装置２００が彼の身元を認証することができるように、彼の買主ＩＤ、暗証又はプライベートキーを与える。代理人はそれを端末に打ち込むことによってこのデータをディジタル形式に置き換え、その後ＣＰＯ１００を形成するために法律文言を付加する。ＣＰＯ１００は、その後中央制御装置２００に送られ、オンラインの実施例で説明されたように潜在的売主に入手可能にされる。
【００９４】
代替的な実施例では、買主は中央制御装置２００を電話をかけ、買主がＣＰＯ１００の幾つか又は全ての条件を生きた代理人の補助なしに入力することを可能にする従来の対話型音声応答ユニット（Ｉｎｔｅｒａｃｔｉｖｅ  Ｖｏｉｃｅ  Ｒｅｓｐｏｎｓｅ  Ｕｎｉｔ：  ＩＶＲＵ）に接続される。買主は、まず、彼の電話のプッシュボタンキーを使用して対象のメニューから選択し、その後、その呼はその対象領域を特定する生きた代理人につながるか、買主は更なるＣＰＯ１００の条件のためにプロンプト応答される。
【００９５】
潜在的売主はＣＰＯ１００をブラウズして拘束するのに電話を利用することもできる。潜在的な売主は中央制御装置２００を発呼して対象を選択する。中央制御装置２００は、その後、各ＣＰＯ１００のテキストをオーディオ形式に返還し、全リストを潜在的売主に読みあげる。ＣＰＯ１００を読みあげている間のいかなる時においても潜在的売主はＣＰＯ１００を拘束用に選択するために彼の電話のキーの組合せを押すことができる。売主は売主ＩＤ番号を入力して中央制御装置２００によってＣＰＯ１００の拘束前に認証される。潜在的売主はＣＰＯ１００のリストが彼らに読み上げられる前にパラメータを入力することもできるであろう。例えば、航空会社は、８００ドル以上の全航空会社ＣＰＯ１００が読み上げられることを要求して低価格のＣＰＯ１００を飛ばすことができる。
【００９６】
買主もファックスや郵便で中央制御装置２００の代理人と通信することができる。代理人はメッセージを受信し、上述したようにそれをディジタル化してＣＰＯ１００を作成するために処理を行う。
【００９７】
暗号認証の実施例
前述の実施例においては、買主と売主の認証は、添付のＩＤ又は氏名をチェックしてそれを売主データベース２６０及び買主データベース２５５に格納されているそれらと比較することを含んでいる。この手続は低機密環境では十分機能するが、暗号プロトコルの利用によりそれは大幅に改善される。これらのプロトコルはメッセージ送信者を認証する能力を強化するのみならずメッセージ自体の完全性を確認する機能を有し、送信中に変更されていないことを証明している。例えば、小さい航空会社は、身元が認証されないので、大手運輸業者による履行を要求するＣＰＯ１００を拘束することができないだろう。暗号は盗み聞きする者がメッセージの内容を知ることを防止することもできる。例えば、競合航空会社は、別の競合相手が生成したいかなる売主応答１００も横取りして読むことができないだろう。このような技術は暗号保証方法と一般に呼ばれており、ディジタル署名とハッシュアルゴリズムと共に対称及び非対称キーの両方の使用を含むであろう。
【００９８】
メッセージの完全性と送信者の真偽性を確信するために暗号プロトコルを使用する実務は当業界で周知であるのでここでは詳しく説明しない。参考のために、当業者は、ブルース・シュナイアー（Ｂｒｕｃｅ  Ｓｃｈｎｅｉｅｒ）のアプライド・クリプトグラフィ・プロトコルズ・アルゴリズムズ・アンド・ソースコード・インＣ（Ａｐｐｌｉｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ，  Ｐｒｏｔｏｃｏｌｓ，  Ａｌｇｏｒｉｔｈｍｓ，  Ａｎｄ  Ｓｏｕｒｃｅ  Ｃｏｄｅ  Ｉｎ  Ｃ．）、第２版、ジョン・ウイリー＆サンズ社、１９９６年刊を参照することができる。
【００９９】
図１４は、売主と中央制御装置２００がキーを共有する対称キーの実施例を説明している。従って、売主応答１１０の暗号化と解読が共に同一のキーで行われる。この暗号化は、（ＦＩＰＳ  ＰＵＢ  ４６で特定されている合衆国政府基準）ＤＥＳなどのアルゴリズムにより又はＩＤＥＡ、ブローフィッシュ、ＲＣ４、ＲＣ２、ＳＡＦＥＲなど当業界で知られている幾つかのアルゴリズムのいかなるものを用いても実行することができる。売主は、ステップ１４００で売主インターフェース３００の暗号処理装置３１０を使用して彼の割り当てられた対称キーで売主応答１１０を暗号化する。キーはメッセージデータベース３７０に格納されてもよいし、売主によってその他の方法で格納又は記憶されてもよい。暗号化された売主応答１１０は、ステップ１４１０で、その後、中央制御装置２００の暗号処理装置２１０に送信される。暗号処理装置２１０は、売主応答１１０から売主ＩＤをステップ１４２０で抽出してステップ１４３０で暗号キーデータベース２９０の売主の対称キーを調べ、売主応答１１０をステップ１４４０においてこのキーで解読する。暗号キーデータベース２９０は、メッセージを暗号化、解読及び／又は認証用のアルゴリズムとキーを含んでいる。ステップ１４５０で、結果的メッセージが理解可能であれば、同一キーによって暗号化されたはずであり、売主が実際に売主応答１１０の著者であったに間違いないことを認証する。
【０１００】
この手続は、無権限の売主が彼自身を正当な売主であると表現することをより困難にしている。暗号手続がなければ、正当な売主からサンプル売主応答１１０を入手した無権限の売主は、売主ＩＤを抽出することができ、その後、このＩＤ番号を無権限の売主応答１１０に添付することができるであろう。しかし、売主応答１１０が対称キーで暗号化されると、サンプル売主応答１１０を入手する無権限の売主は売主ＩＤ番号を発見するのみであり、対称キーは発見しない。このキーがなければ、無権限の売主は、中央制御装置２００によって発見されないであろう売主応答１１０を作成することができない。なぜなら、彼は彼のメッセージを、正当な権限を有する売主ができたのと同一の方法で暗号化することができないからである。対称キープロトコルは、メッセージの変更は対称キーの知識を要するので、売主応答１１０が送信中に不正変更されていないことも確信する。暗号化された売主応答１１０は売主により多くの匿名性も与える。
【０１０１】
さて、図１５を参照するに、売主応答１１０がプライベートキーで暗号化されてパブリックキーで解読される非対称キープロトコルが示されている。この手続のかかる２つのアルゴリズムはＲＳＡとＤＳＡである。売主は、ステップ１５００で売主応答１１０を彼のプライベートキーにより暗号処理装置３１０を使用して暗号化し、ステップ１５１０で売主応答１１０を中央制御装置２００に送信する。暗号処理装置２１０は、売主ＩＤをステップ１５２０で抽出し、ステップ１５３０でその売主の関連パブリックキーを暗号キーデータベース２９０で調べる。上述したように売主応答１１０が理解可能であれば、中央制御装置２００はステップ１５５０で売主を認証した。再び、売主応答１１０を入手した無権限の売主は、売主のプライベートキーを知らないので、それが中央制御装置２００に受信された前に、それを気づかれずに変更することはできない。しかし、無権限の売主は、売主のパブリックキーを何とかして得たならば、メッセージを読むことはできるであろう。売主が売主応答１１０を彼のパブリックキーで暗号化すればメッセージの秘密性は得られ、売主応答１１０を見るには攻撃者が売主のプライベートキーを知ることを要する。
【０１０２】
図１６は、認証とメッセージの完全性を与えるのにディジタル署名を利用する暗号技術を示している。一のかかるアルゴリズムはＤＳＡ（デジタル署名アルゴリズム：Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅ  Ａｌｇｏｒｉｔｈｍ）で、ＦＩＰＳ  ＰＵＢ  １８６で特定された合衆国政府基準である。上述の非対称プロトコルにあるように、各売主は、関連付けられたパブリック及びプライベートキーを有している。売主は、ステップ１６００で暗号処理装置３１０により売主応答１１０をプライベートキーで署名して、ステップ１６１０においてそれを中央制御装置２００に送信する。中央制御装置の暗号処理装置２１０は、売主ＩＤをステップ１６２０で抽出して、売主のパブリックキーをステップ１６３０で調べ、ステップ１６４０で売主応答１１０とその売主のパブリックキーを使用して署名を確認する。売主応答１１０が理解可能であれば、中央制御装置２００はステップ１６５０で本物として売主応答１１０を受け付ける。
【０１０３】
図１７を参照するに、売主応答１１０の真正と完全性を確認するメッセージ認証コードを使った暗号技術が説明されている。本発明のハッシュプロトコルでは、売主と中央制御装置２００は、売主がステップ１７００で売主応答１１０のハッシュに含める対称キーを共有する。ハッシュプロトコルでは、一方向関数が売主応答１１０のディジタル表示に適用され、売主応答１１０の指紋のように動作するコードを生成する。例えば、ＲＩＰＥ−ＭＡＣ、ＩＢＣ−Ｈａｓｈ、ＣＢＣ−ＭＡＣなどのＭＡＣアルゴリズムのいずれもがこのアプリケーションに適用することができる。ステップ１７１０で売主応答１１０を中央制御装置２００に送信した後、ステップ１７２０で暗号処理装置２１０は売主ＩＤを売主応答１１０から抽出する。その後、暗号処理装置２１０は、ステップ１７３０で売主の対称キーを調べ、ステップ１７４０でこの対称キーにより売主応答１１０をハッシュし、結果のハッシュ値を売主応答１１０に添付されたハッシュ値と比較する。ステップ１７５０でそれらの値が一致すれば、売主の真正と売主応答１１０の完全性が確認されたことになる。
【０１０４】
暗号技術は売主応答１１０の真正についてより大きい信頼性を与えるが、売主の暗号キー危険にさらされればそれらは無益である。他の売主の対称キーを入手した攻撃者は、中央制御装置２００にはその売主と見分けがつかない。その売主が、売主応答１１０の本当の著者であったのか、あるいは、正しい暗号キーを持っている攻撃者なのかを知る方法はない。（見逃し交換として知られる）この問題を解決する一つの方法は、例えば、指紋読取装置、音声認識システム、網膜スキャナ等のようなバイオメトリック装置を使うことである。これらの装置はその売主の身体的特徴を売主応答１１０に組み込み、その後、中央制御装置２００の売主データベース２６０に格納されている値と比較される。本発明において、かかる装置は売主インターフェース３００に付随する。
【０１０５】
例えば、指紋照合は、売主応答１１０の形成前に中央制御装置２００からのプロンプトに応答して売主応答１１０の生成中のある所定の又は無作為な時期に、若しくは、売主応答１１０の生成中の継続的照合のために売主が常に走査レンズに指を維持するよう要求されるように走査レンズを売主インターフェース３００に結合することによって継続的に、行うことができる。
【０１０６】
かかる識別装置の例は、台湾の会社のスターテック（Ｓｔａｒｔｅｋ）から入手可能なＦＣ１００指紋照合装置（ＦＩＮＧＥＲＰＲＩＮＴ  ＶＥＲＩＦＩＥＲ）である。ＦＣ１００はインターフェースカードを介していかなるＰＣにもすぐに適合することができる。指紋照合装置は光学走査レンズを利用している。売主が指をレンズにおくと、結果の像が走査、ディジタル化され、そのデータは圧縮されてメモリに格納される。典型的に２５６バイトファイルがあれば十分である。各生きた走査指紋は、データ記憶装置３６０に格納されて以前に登録格納したテンプレートと比較される。紋様が一致しなければ暗号処理装置３３５によって実行される暗号はアルゴリズムは売主が売主応答１１０の生成を妨げる。
【０１０７】
音声照合の実施例では、売主の音声が身元確認に使用される。この実施例は、標準電話接続で実行可能なので、何ら特定のハードウェアの使用を要求しないという長所を有する。売主の身元は中央制御装置２００で確認される。声紋を入手する処理とそれをその後の人物同一性確認で使用することは当業界で周知であるのでここでは詳しく説明しない。当業者は、音声識別／照合技術についてスピークイージー社（ＳｐｅａｋＥＺ，  Ｉｎｃ．）を参照することができる。従来の話者識別ソフトウェアは売主の音声サンプルをとる。このサンプルは中央制御装置２００の売主データベース２６０に格納される。売主が売主応答１１０を中央制御装置２００に送信することを希望するたびに、彼は中央制御装置２００に電話をかけて音声サンプルにプロンプト応答で電話に話しかける。このサンプルが売主データベース２６０に格納されたものと一致すれば、売主は売主応答１１０に添付されたディジタル署名に結合する暗証を与えられる。適当な音声一致暗証なしに受信されたいかなる売主応答１１０も受け付けてもらえない。声紋は、売主応答１１０の形成前にその場で売主の身元を確認するために、売主インターフェース３００のデータ記憶装置３６０のデータベースに格納されてもよい。
【０１０８】
上述の暗号及びバイオメトリックプロトコルは売主応答１１０の認証と確認を説明しているが、ＣＰＯ１００、代案１４０、買主応答１５０、購入確認１２０その他のメッセージ又は買主、売主及び中央制御装置２００の間の通信にも等しく適用することができる。
【０１０９】
匿名取引の実施例
上述したように、本発明は買主と売主の両方に匿名性を与えている。かかる匿名性は全取引に対して個人名をいちいち参照することを排除することによって達成される。例えば、買主は彼の名前よりも彼のＩＤを含めて、ＣＰＯ１００を受信する売主が買主の身元を発見することを防止するだろう。買主がバイオテクノロジーの会社であって競争相手にその会社が探している研究装置の種類を知られたくない場合にはこのことは望ましい。
【０１１０】
同様に、売主は、彼らの身元を秘密にしておくことを希望する場合もある。航空会社はある都市間で大幅に料金割引をしていることを公けに知られたくないかもしれないだろう。
【０１１１】
ＩＤ番号の使用は買主と売主の両方に匿名性を与えることができるが、幾つかの潜在的な弱点が存在する。第１に、買主データベース２５５又は売主データベース２６０に格納されているＩＤ番号のデータベースとそれら各々の買主／売主が危険にさらされれば、匿名性は破壊される。なぜなら、メッセージ送信者は買主データベース２５５又は売主データベース２６０を調査可能だからである。これを防止するため、中央制御装置２００のパブリックキーによりＩＤ番号が暗号化され、その結果、それは盗まれてもプライベートキーがないので無益になる。
【０１１２】
我々は一の可能な匿名性維持方法のみを説明したが、他にも均等物は存在する。例えば、電話によりメッセージを送る実施例であれば、買主と売主の身元は従来の音声修正技術を利用して保存することができる。ＣＰＯ１００又は売主応答１１０が用紙形式であれば、その形式は光学文字認識を利用して走査されてディジタル形式に変換されることができ、原文書で発見され得るいかなる情報も破棄することができる。
【０１１３】
信託サーバーの実施例
本発明の一実施例では、中央制御装置２００は、操作サーバー１６０、信託サーバー１６５及び保証代理人１７０の３つの別個の要素に分離されている。各サーバーはＣＰＯ１００管理処理において別個の仕事を行う。この分離により、攻撃者は１つではなく３つの別個のシステムの機密保持を破らなければならないので、システムを破ることがより困難になる。図２０に示すように、これらのサーバーは買主インターフェース４００と売主インターフェース３００に関連して動作する。操作サーバー１６０は、ＣＰＯ１００を掲載する仕事を有し、信託サーバー１６５によって事前に認証された全取引を受け入れる。信託サーバー１６５は買主と売主の身元を認証し、保証代理人１７０は買主の支払能力と拘束されたＣＰＯ１００に関する売主の配達能力を確認する。本実施例では、各サーバーの種類は幾つかのサーバー上に分散されることができる。
【０１１４】
次のプロトコルは３つのサーバーの対話を述べており、以下のものを負担している。
【０１１５】
１．  皆は操作サーバー１６０、信託サーバー１６５及び保証代理人１７０のパブリックキーを知っている。
【０１１６】
２．  買主と潜在的な売主は後述するように保証書１７２を持っている。
【０１１７】
３．  パブリックキーは暗号と署名の両方に使用することができる。
【０１１８】
ＣＰＯ１００が操作サーバー１６０に承諾される前に、信託サーバー１６５と保証代理人１７０の両方のディジタル署名を生み出さなければならない。このため、ＣＰＯ１００は、２つの追加要素である信託サーバーＩＤと保証書を含んでいる。
【０１１９】
信託サーバーＩＤはＣＰＯ１００を作成した買主を認証した信託サーバー１６５のＩＤ番号である。「保証書」は、保証書１７２に対する一連の有効日、カバー限度額、一連の付加条件を特定する保証子（保証代理人１７０）を有するパブリックキーの証明書である。これらの付加条件は、撤回リストのオンラインチェッキングを要求することができ、使用される操作サーバー１６０と信託サーバー１６５を特定する等を行うことができる。保証されたパブリックキーに対応するプライベートキーは保証代理人１７０に知られておらず、ユーザーにのみ知られている。そのプライベートキーの知識は保証保持者に対する身元の証拠として使用される。（このことは買主と売主の匿名性を多くの場合に許容している。もちろんどちらも保証代理人１７０には非常に特別の場合を除いて匿名ではない。）
買主に対する保証書１７２はＢＣＢと呼ばれ、対応するパブリック及びプライベートキーはＰＫＢ及びＳＫＢとそれぞれ呼ばれる。
【０１２０】
ＣＰＯ１００は、買主と、信託サーバー１６５と、操作サーバー１６０との間の対話によって掲載される。プロトコルのこの部分は当事者間で送信される暗号化されたＥメールと何ら変わりない。
【０１２１】
ＣＰＯ１００が掲載可能になる前に買主は信託サーバー１６５から許可を得なければならない。これは買主と操作サーバー１６０の両方が、契約が履行されたかどうかを決定するために指定した信託サーバー１６５がＣＰＯ１００を現実に承諾することを了解していることを知るのに必要である。操作サーバー１６０は後述する信託承諾（ＴＲＵＳＴＥＤ＿ＡＣＣＥＰＴＡＣＥ）メッセージなしにはＣＰＯ１００を承諾しないだろう。
【０１２２】
買主のＣＰＯ１００が新鮮（再生でない）でなく、買主の支払能力が保証代理人１７０に保証されなければ、信託サーバー１６５もまた信託承諾を発行しないだろう。買主は新鮮な信託承諾を発行されていることも確信しなければならない。
【０１２３】
プロトコルは以下のように作用する。
【０１２４】
１． 買主は以下を形成
Ｕ０＝「信託許可要求」
Ｘ０＝Ｕ０、ＣＰＯ、Ｒ０、追加条件
そして信託サーバー１６５に以下を送信
Ｍ０＝ＰＫＥＰＫＡ  （Ｘ０，  Ｓｉｇｎ  ＳＫＢ  （Ｘ０））
２． 信託サーバー１６５は以下で応答
Ｕ１＝「信託ＣＰＯ呼掛け」
Ｒ１＝１６０−ｂｉｔ乱数
Ｘ１＝Ｕ１ハッシュ（Ｘ０），  Ｒ１
そして買主に以下を送信
Ｍ１＝  ＰＫＥＰＫＡ  （Ｘ１，  Ｓｉｇｎ  ＳＫＡ  （Ｘ０））
３． 買主はこれに以下で応答
Ｕ２＝「買主ＣＰＯ応答」
Ｘ２＝Ｕ２，  ハッシュ（Ｘ１）
そして信託サーバー１６５に以下を送信
Ｍ２＝  ＰＫＥＰＫＡ  （Ｘ２，  Ｓｉｇｎ  ＳＫＢ  （Ｘ２））
４． 信託サーバー１６５は以下で応答
Ｕ３＝「信託ＣＰＯ承諾」
Ｔ３＝タイムスタンプ
Ｘ３＝Ｕ３，  ハッシュ（Ｘ２），  Ｔ３，  ＣＰＯ
そして買主に以下を送信
Ｍ３＝  ＰＫＥＰＫＢ  （Ｘ３，  Ｓｉｇｎ  ＳＫＡ  （Ｘ３））
５． 買主はＸ３を信託承諾として格納
操作サーバー１６０がＣＰＯ１００を掲載するためには、ＣＰＯ１００が新鮮な信託承諾を有し、それが保証代理人１７０によって保証されていることを確信しなければならない。これは以下のように作用する。
【０１２５】
１． 買主は以下を形成
Ｒ０＝「１６０ビット乱数」
Ｕ０＝「ＣＰＯサーバー提出」
Ｘ０＝Ｕ０，  Ｒ０，  信託承諾
そして操作サーバー１６０に以下を送信
Ｍ０＝ＰＫＥＰＫＳ  （Ｘ０，  Ｓｉｇｎ  ＳＫＢ  （Ｘ０））
２． 操作サーバー１６０はＭ０を受信してそれを確認。それが新鮮で（再生でなく）、操作サーバー１６０がＣＰＯ１００掲載を了解する場合には、それは以下を形成
Ｒ１＝「１６０ビット乱数」
Ｕ１＝「サーバーＣＰＯ呼掛け」
Ｘ１＝１，  ハッシュ（Ｘ０），  Ｒ１
そしてその後以下を暗号化して買主に送信
Ｍ１＝  ＰＫＥＰＫＢ  （Ｘ１，  Ｓｉｇｎ  ＳＫＳ  （Ｘ１））
３． 買主は以下を形成
Ｕ２＝「サーバー呼掛けにＣＰＯ応答」
そしてその後操作サーバー１６０に以下を送信
Ｍ２＝  ＰＫＥＰＫＳ  （Ｘ２，  Ｓｉｇｎ  ＳＫＢ  （Ｘ２））
４． このメッセージの署名が正しく照合すれば操作サーバー１６０はＣＰＯを掲載する。操作サーバー１６０は以下を掲載
Ｕ３＝「掲載されたＣＰＯ受領」
ＣＰＯ＝Ｕ３，  ハッシュ（Ｘ２），  ＣＰＯ
それはその後買主に以下を送信
Ｍ３＝  ＰＫＥＰＫＢ  （ＣＰＯ，  Ｓｉｇｎ  ＳＫＳ  （ＣＰＯ））
このプロトコルの終わりに、買主は彼のＣＰＯ１００が掲載されたことを了承する承認書を得、操作サーバー１６０は保証書１７２の保持者がＣＰＯ１００にちょうど同意して信託サーバー１６５の同意を得ていることを確信する。
【０１２６】
潜在的売主は彼自身の保証書１７２（ＢＣＰ）を有する。彼がＣＰＯ１００を（それらを拘束する能力付きで）ブラウズすることを実時間で許可される前に、彼はプロトコルを経験しなければならない。（ＣＰＯ１００はブラウズしない人々には入手可能であるが、彼らがこのプロトコルを経るまではだれもＣＰＯ１００を拘束することができない）。このプロトコルの目的は、売主が要求された商品を配達することができると保証代理人１７０に保証されている旨を証明することと、秘密認証キーＫｐを設定することによって操作サーバー１６０に対する計算負荷を減少することである。これら全てにより、潜在的売主はＣＰＯ１００をブラウズする計算費用を減少させる。
【０１２７】
１． 潜在的売主は以下を形成
Ｒ０＝１６０ビット乱数
Ｔ＝時間範囲
Ｕ０＝「ブラウズへのアクセス要求」
Ｘ０＝Ｕ０，  Ｒ０，  Ｔ，  ＢＣＰ
そして操作サーバー１６０に以下を送信
Ｍ０＝ＰＫＥＰＫＳ  （Ｘ０，  ＳｉｇｎＳＫＰ  （Ｘ０））
２． 操作サーバー１６０は潜在的売主アクセスを認めるかどうかを決定。そうであればそれは以下を形成
Ｒ１＝１６０ビット乱数
Ｕ１＝「サーバーブラウズ−アクセス呼掛け」
Ｘ１＝Ｕ１，  ハッシュ（Ｘ０），  Ｒ１
そして潜在的売主に以下を送信
Ｍ１＝ＰＫＥＰＫＰ  （Ｘ１，  ＳｉｇｎＳＫＳ  （Ｘ１））
３． 潜在的売主は以下を形成することによって応答
Ｕ２＝「ブラウズ−アクセス応答」
そして操作サーバー１６０に以下を送信
Ｍ２＝ＰＫＥＰＫＳ  （Ｘ２，  ＳｉｇｎＳＫＰ  （Ｘ２））
４． 操作サーバー１６０は署名を確認し、その後以下を形成することによって応答
Ｕ３＝「拘束力のあるキー」
Ｋｐ＝ＣＰＯ１００を拘束するのに使用される無作為な秘密キー
Ｔ＝時間範囲（最初のプロトコルメッセージから）
Ｘ３＝Ｕ３，  ハッシュ（Ｘ２），  Ｔ，  Ｋｐ
そして潜在的売主に以下を送信
Ｍ３＝ＰＫＥＰＫＰ  （Ｘ３，  ＳｉｇｎＳＫＳ  （Ｘ３））
このプロトコルの終わりに潜在的売主は、最後のメッセージで特定されている期限内にＣＰＯ１００を拘束することができる秘密共有キーを保持する。潜在的売主と操作サーバー１６０は互いに実時間で対話したことを共に確信し、操作サーバー１６０は潜在的売主の拘束されたＣＰＯ１００に関する配達能力は保証代理人１７０によって保証されていることを認識する。
【０１２８】
潜在的売主がＣＰＯ１００をブラウズすると、各々は操作サーバー１６０によって彼に送信され、Ｋｐで認証され、再生攻撃を防止する無作為な呼掛け（Ｃｈａｌｌｅｎｇｅ）を含んでいる。潜在的売主がその拘束を希望すれば、彼はＣＰＯ１００を拘束する申込を形成して、Ｋｐで認証された、認証されたＣＰＯ１００のハッシュと共にそれを送信する。操作サーバー１６０は、これがＣＰＯ１００を拘束するための有効な申込であり、それが実時間で発生していることを確信する。それは「拘束されたＣＰＯ（ＢＯＵＮＤ＿ＣＰＯ）」を彼に送信することによって応答する。
【０１２９】
１． 操作サーバー１６０は以下を形成
Ｕ０＝「ＣＰＯ申込」
Ｒ０＝１６０ビット乱数
Ｘ０＝Ｕ０，  Ｒ０，  ＣＰＯ説明
そして潜在的売主に以下を送信
Ｍ０＝ＰＫＥＰＫＰ  （Ｘ０，  ＡｕｔｈＫｐ（Ｘ０））
（このステップはブラウズされた各ＣＰＯ１００に対して繰り返されることに注意）
２． 潜在的売主は以下を形成
Ｕ１＝「ＣＰＯ拘束申込」
Ｒ１＝１６０ビット乱数
Ｘ１＝Ｕ１，  ハッシュ（Ｘ０），  Ｒ１，  申込詳細
そして以下を暗号化して操作サーバー１６０に送信
Ｍ１＝ＰＫＥＰＫＳ  （Ｘ１，  ＡｕｔｈＫｐ（Ｘ１））
３． 申込が操作サーバー１６０に承諾可能であれば、それは以下を形成
Ｕ２＝「ＣＰＯのサーバー拘束」
Ｔ＝タイムスタンプ
Ｘ２＝Ｕ２，  ハッシュ（Ｘ１），  ＢＣＰ，  Ｔ，  ＣＰＯ，  申込詳細そして以下を暗号化して潜在的売主に送信
Ｍ２＝ＰＫＥＰＫＰ  （Ｘ２，  ＳｉｇｎＳＫＳ  （Ｘ２））
４． 潜在的売主はＸ２，  ＳｉｇｎＳＫＳ  （Ｘ２）をＢＯＵＮＤ＿ＣＰＯとして格納
拘束されたＣＰＯの「申込詳細」フィールドはＣＰＯ１００の条件を特定する。殆どの場合、これは、おそらく信託サーバー１６５からの代理人の存在下で、支払と交換にある商品の配達を含むであろう。しかし、ある場合には、これは潜在的買主、売主又はその双方のための匿名性を守るために仲介人を介するであろう。単純な呼掛け応答プロトコルにより買主又は仲介者に対してその身元を証明することができるよう潜在的売主がＢＯＵＮＤ＿ＣＰＯを有することが重要である。
【０１３０】
この一連のプロトコルはＣＰＯ１００をサポートするインフラストラクチャーの可能な一実施例を説明している。操作サーバー１６０、信託サーバー１６５及び保証代理人１７０は考えられるところでは同一主体になり得ることに留意することが重要である。この場合には、これらのプロトコルは大幅な単純化が可能となる。
【０１３１】
バーター（物々交換）の実施例
全取引が買主から売主へのお金の移転を要求するわけではない。バーター取引では、買主と売主の違いは消失して、第１の当事者と第２の当事者間の契約となる。現金を得る代わりに、第２の当事者は第１の当事者から商品を得る。例えば、オートバイの処分を希望する第１の当事者は彼がニューヨークからロンドンまでのファーストクラスチケットとオートバイとを交換する申込をするＣＰＯ１００を掲載することができるであろう。
【０１３２】
調停のプロトコル
前述の実施例は処理の終わりに売主から買主への商品の配達を述べているが、幾つかの取引から紛争が生じることは避けられず、これらの紛争解決のフォローアップ活動が必要となる。本発明は、２つの方法で紛争解決をサポートすることができる。
【０１３３】
第１に、より費用と時間がかかる法律裁判所の法律争議の回避を促進するために両当事者が全紛争に対して拘束力のある調停に服従することを要求する文言をあらゆるＣＰＯ１００に作成されることができる。また、ＣＰＯ１００の特定の違反に対する損害額を特定する損害の清算を設定してもよい。
【０１３４】
第２に、中央制御装置２００は、各紛争に対して調停者を設けて調停処理をサポートすることができる。売主から出荷された商品がＣＰＯ１００の条件に対応しない場合にかかる調停を要求することができるだろう。例えば、直行便航空券を希望する買主は一以上の経由を有するチケットを配達した売主に損害額を求めることができる。同様に、ホテルの禁煙室に対するＣＰＯ１００を有する出張旅行者は喫煙室でそのＣＰＯを拘束したホテルから損害額を求めることができるだろう。損害額を求める代わりに、買主は、別の直行便航空券などの商品交換を要求してもよい。航空券が関与する調停では、買主はＣＰＯ１００のトラッキング番号と共に中央制御装置２００にチケットの写しを提出することができ、調停者に対して売主がＣＰＯ１００の条件を履行したかどうかの設定を許可することができる。売主は、商品出荷後に買主から支払いを未だ受け取っていなければ調停手続を開始することもできる。
【０１３５】
代替的実施例においては、取引データは本システム外の第三者調停者に送られてもよい。中央制御装置２００は、ＣＰＯ１００、売主応答１１０及び購入確認１２０の写しを調停者に送ることができる。真正又は否認なしについて問題があれば暗号キーが調停者に与えられてもよい。
【０１３６】
本発明の適用
本発明の適用を明確性のためエンドユーザーの潜在的需要を以下に示す。
【０１３７】
ＣＰＯ：    航空券
４枚のチケットが必要
シカゴ、オヘア又はミッドウェイからフェニックスまで
４月１２日又は１３日に出発
４月１８日又は１９日に帰り
６大運輸業者のいずれも可
乗り換えも２時間以内の待ち合わせであれば可
税別１８０ドルで拘束
ＣＰＯ：    ホテル宿泊
５泊
４月１２日又は１３日に到着４月１８日又は１９日に出発
フェニックスダウンタウン車で３０分以内
ダブルベッド
禁煙
ホテル、モーテル又は朝食付き宿泊も可
トリプルエー（ＡＡＡ）認可又はモービル２＊以上であること
一泊（税別）５５ドルで拘束
ＣＰＯ：  新車購入
１９９７フォードトーラス
ディーラストックであること
エアコン付きＧＬパッケージ
ＡＭ／ＦＭ／カセット（ストック番号１２２４−０９９）
搭載済み別オプション可
白、黄褐色、緑、栗色可
１００マイル以下で登録なし
ディーラのデモ車でないこと
１９９６年７月１５日前に配達可能なこと
ローン事前許可：チェースマンハッタン＃１２２０−９９８−８８７ＡＤ−２１
２１，３５０ドルで拘束
ＣＰＯ：    車の保険
１９９７フォードトーラス
運転手１人４０歳男
コネチカット州リッジフィールド在住
仕事場まで３０マイル運転
衝突含む
５００ドル控除
ガラス保証含む
過去３年スピード違反なし
過去３年無事故
１ＭＭ責任保護
運転免許番号ＣＴ１２２２−２２１−２２９８
ＡＭベストにより仕事はＡ評価以上
年１，２００ドルで拘束
ＣＰＯ：  米国シルバードル
１８８６モルガン
フィラデルフィアミントマーク
ＡＮＡ包装でシール
ＭＳ９４以上の等の級
計６枚まで購入
売主は全部又は一部の履行可
各２２５ドルで拘束
申込管理人：ニューヨーク州ニューヨーク市私書箱１０００コインワールド
Ｋ．スミス氏２１２−２２２−１０００
ＣＰＯ：    工業用品
弊社は４０トンの鋼材購入希望
等級１２０
ニューヨーク州ニューヨーク市までＦＯＢ配達
クラス４スラブ又はクラス１２インゴット
アロイＲＴ−１２又は均等物
１９９６年８月１日までに配達
シティバンクに最高額通知
最高額以下の最初の入札で拘束
シティバンクは即座に価格確認を与える
１日１社１入札（ＧＭＴ）
Ｅメール＠ｍｅｔａｌｓ．ｂｉｄｄｅｓｋ４０２２Ｃｉｔｉ．ｃｏｍ
支払信用状シティバンク１００−８８７−９８７７
ＣＰＯ：    クレジットカード申込み
ビザゴールドカード
クレジット限度額５，０００ドル
利息１２％以下
年１０ドルで拘束
金融履歴入手可能
1227612016031_0
ＣＰＯ：    返還謝礼金
重要なコンピュータディスクの入ったブリーフケースを紛失
ディスクラベルはＲＴ−５５４ＩＢＭ
茶革ケース真鍮スナップ、ＲＬモノグラム
１９９６年４月７日マンハッタン地下鉄Ｆ線に置き忘れ
５００ドルで拘束
報酬請求用紛失物発見受領書番号付与
申込管理人：ニューヨーク警察紛失物発見
Ｋ．スミス氏２１２−５５５−１０００
産業上の利用可能性
上述の詳細な説明に関して、本発明は、他のものに加え、一以上の以下のシステムを形成に使用可能であることは明白である。
【０１３８】
−  売主の申込に対する履行を承諾するように買主を拘束するために売主が購入申込の条件に適合することができるシステム
−  売主が、買主の購入申込に述べられた条件を承諾すると資金を直ちに回収することができるシステム
−  信頼された第三者管理者が処理のいかなる面においても履行、相当性又は解釈に関する決定が当事者を拘束することができるシステム
−  買主の購入申込に合意すると売主が支払いの一部を受け取ることができ、買主の購入申込に要求された商品又は役務の配達があればその後の支払いが受けられるシステム
−  契約完了時まで買主又は売主が匿名を維持することができ、買主はその購入申込によって要求された商品又は役務の配達の中継システムとして信頼された第三者を利用することによって契約後も匿名を維持することができるシステム
−  本発明のシステムを使用する買主には資格のない売主からの問い合わせ又は承諾が殺到することはないことを確保するシステム
−  買主の購入申込の完全性と買主の身元が認証されるシステムを提供するシステム
−  購入申込の条件を満足させる売主の能力を決定するため売主の身元が認証されるシステム
−  売主は買主に認証可能な代案を提出可能なシステム
−  代案により、その代案の認証可能な条件の下、買主が売主をその代案に拘束することができるシステム
−  買主の購入申込の条件とかかる配達の暗号確認に従って、売主から買主への保険証などのディジタルベースの製品の配達を可能にするシステム
−  一以上の売主が購入申込に買主を拘束可能な購入申込を許容するシステム
−  印刷媒体や新聞広告など非電子的手段を利用してシステムの全部又は一部が実行可能な方法を示すシステム
−  本発明の上述の詳細な説明に関し、商品又は役務の将来の買主が拘束力のある購入申込を世界的に潜在的売主に伝えることができ、売主が便宜に関連する買主の購入申込をサーチでき、売主は買主の購入申込に基づいて買主を契約に拘束することができる方法及び装置を本発明が提供していることは直ちに理解できるであろう。また、本発明は買主と売主の合意の履行を、その購入に対する買主の支払いを保証することによって、実現することができる。従って、本発明は、買主の購入要求を満足させることが可能な売主へ買主が到達する能力を向上させ、興味をもった買主を識別する売主の能力を向上させている大変効果的な双方的買主駆動商業システムである。
【０１３９】
本発明の一実施例では買主と売主との間の通信は電子ネットワークと中央制御装置を利用して行われる。購入を希望する買主は遠隔地のサーバーにある中央制御装置にアクセスする。買主は、購入希望商品の対象、希望商品の説明及び買主が要求するその他の条件を特定することによって、条件的購入申込（ＣＰＯ）をその後作成する。例えば、典型的なＣＰＯは、買主が、シカゴのオヘア空港からテキサスのダラスまで、米国６大運輸業者のいずれかで、待合せ時間が２時間以内ならせいぜい１回の乗り継ぎは了解し、各チケットに税別１８０ドル支払うことを了解する４枚の航空券ブロックを購入希望であることを特定する。
【０１４０】
その後、買主はユーザーＩＤをＣＰＯに添付して、そのＣＰＯを中央制御装置に送信する。本発明の下では、ＣＰＯは、ワールドワイドウェブインターフェース、電子メール、ボイスメール、ファクシミリ、郵送など無数の手段を介して送信することができる。法律定型条項と文言は、買主の購入申込の「溝を埋めるために」その後ＣＰＯに統合することができる。代替的に、ＣＰＯは買主が中央制御装置へのオンライン接続中に展開することができる。
【０１４１】
ＣＰＯを潜在的売主に送信する前に中央制御装置は買主のＩＤ番号を買主データベースに対して認証する。中央制御装置は買主にクレジットカード番号を要求することができ、クレジットカード精算所と契約を結ぶことによって買主がＣＰＯで特定されている購入価格をカバーするのに利用可能な十分のクレジットを持っていることを確信することもできる。中央制御装置は、その後、独自のトラッキング番号をＣＰＯに割り当て、興味をもったいかなる潜在的売主が見ることができるようにＣＰＯを世界的に表示することができる。ＣＰＯは、潜在的売主が関連するＣＰＯをより簡単に識別することができるように、対称範囲別に表示されてもよい。従って、売主は、例えば、ウェブサイトにログオンしてＣＰＯ対象範囲のリストを見ることができる。売主はその後特定の対称を選択して対象範囲に対応するＣＰＯをブラウズする能力を持つことができる。一実施例においては、売主には、所与の対象範囲のＣＰＯを見るための資格が要求されてもよい。
【０１４２】
特定のＣＰＯを見た後で、潜在的売主はそのＣＰＯの承諾を希望すれば、売主はその意図を中央制御装置に伝える。中央制御装置は、その後、その売主からのメッセージをタイムスタンプして売主の身元と買主希望商品の配達能力を認証する。次に、システムは特定のＣＰＯが依然として「アクティブ」で承諾可能であることを確認する。ＣＰＯが一の売主によってのみ承諾可能であれば、最初の有資格の売主がそれを承諾すればそれは「完了」する。その後の売主は「完了した」ＣＰＯを承諾することはできない。売主がアクティブなＣＰＯを承諾すれば、独自のトラッキング番号が売主の承諾に割り当てられる。その承諾はその後データベースに格納される。買主と売主はこれで法律的に拘束力のある契約の当事者となる。
【０１４３】
他の実施例では、中央制御装置は買主と売主の間の支払システムを自動的に管理する。クレジットカード、パーソナルチェック、電子資金移転、デビットカード、デジタルキャッシュを含む様々な支払方法が本発明で利用可能である。本支払システムは買主と関連付けられた第三者預託口座の使用することもでき、有資格の売主が承諾するまで希望商品の購入をカバーするために買主が前払いした資金を保存することができる。更に、売主への支払時期は変更可能である。売主はＣＰＯを承諾した後直ちに支払いを受けることができるし、売主が契約責務を果たすまで支払いが延期されてもよい。
【０１４４】
本発明の更に他の実施例においては、売主は、原ＣＰＯとは異なる条件を有する拘束力のある代案を発行することによってＣＰＯに応答する選択肢が与えられる。売主が代案を中央制御装置に送信すると、中央制御装置はその代案を買主に転送する。買主はその後代案を承諾する選択肢が与えられ、これによって売主を契約に拘束する。
【０１４５】
本発明はオフラインの実施例で実行されることもできる。電子メールやウェブベースのサーバを使う代わりに、買主と売主は、電話、ファクシミリ、郵便その他のオフラインの通信手段を介して中央制御装置と通信することができる。例えば、買主は（生きた代理人の援助を得て又はそれなしに）ＣＰＯを形成するのに電話を使用することができ、潜在的売主は、ＣＰＯをブラウズして拘束するのに電話を使用することができる。
【０１４６】
他のオンラインの実施例においては、暗号プロトコルは、買主及び／又は売主の身元を認証して買主と売主の中央制御装置との通信の完全性を確認するのに使用される。暗号とバイオメトリックスにより、中央制御装置は、正当な買主又は売主になりすましたりシステム通信を盗聴することによって無権限者がシステムを不正に変更しようとするのを非常に困難にすることができる。
【０１４７】
匿名性は本発明の別の長所である。無数のプライバシーと競争上の理由により、買主と売主は商業取引に従事する際にしばしば彼らの身元を一般公衆に秘密にすることを希望する。本発明は中央制御装置によって機密保持がなされているデータベースに格納されたＩＤ番号を使用することによって買主と売主の匿名性を確保する。
【０１４８】
本発明の一実施例は、中央制御装置の機能を３つのコンポーネントに分割し、それらを３つの異なるサーバーである操作サーバー、信託サーバー及び保証代理人において具体化している。信託サーバーは買主と売主の身元を認証し、保証代理人は商品の支払い又は配達能力を確認する。操作サーバーは、確認のため他の２つのサーバーからのメッセージに依存しながらＣＰＯを掲載する。この構成はサーバーのより専門化を可能にする。
【０１４９】
本発明の別の実施例は買主から売主にお金を移転することを要しない。代わりに、システムは、商品、役務その他の非金銭的対価の交換を介在させる契約を締結するのに使用される。
【０１５０】
最後に、本発明の実施例は、システムを使用して締結された合意から生じる買主と売主との間の紛争を解決する機構を有している。当事者はＣＰＯで拘束力のある調停を契約条件として要求され、中央制御装置による調停処理に補助されることができる。中央制御装置は、調停者として機能することができるし、紛争解決のため第三者に紛争解決を頼ることもできる。
【０１５１】
従来のシステムが以前に行っていないもので本発明が達成しているものは、買主のお金を全ての売主が見ることができる物干綱に文字通り干すことである。お金に添付されているのは、お金を物干綱からおろすために売主が合意しなければならないものを述べたメモである。売主には不確実性はないし時間の無駄もない。彼は、買主が述べた条件に自分が適合できることを知っていれば、直ちにその販売を終了して支払いを受けることができる。口論はない。交渉もない。
【０１５２】
本発明によれば、買主は、通常は買主を見つける余裕がないが買主に希望通りの取引を提供することができる大多数の遠隔地の売主に到達することができる。これは、例えば、希望する車とオプションパッケージを特定の価格で正確に定義することができる車の買主の場合であろう。本発明によれば、かかる買主は、米国の権限を有する売買業者に広く送信される拘束力のある購入申込を発行することができる。そのような売買業者の誰もがその後その申込を承諾するかどうかを決定することができる。買主の希望製品の売主が在庫運搬費を持たない場合は、保険販売の場合と同様に、買主の長所は特に重要である。保険の買主は本発明を利用して、何千もの潜在的保険売主に到達して買主の特定購入条件を満足することを了解する売主を潜在的に探すための大きな網を投げることができるであろう。
【０１５３】
本発明の目的は、買主の要求をそれらを満足させることができる売主に適合させる強固なシステムを提供することである。本発明は、買主と売主の通信、商業及び機密保持の様々な方法を結合して拘束力のある契約を作成する世界的双方的買主駆動システムを提供している。買主の拘束力のある申込を処理し、それらの申込を潜在的売主による効率的評価分析が可能な形式で世界的に通信し、結果の契約の履行を実現し、それらの契約から生じた紛争を解決し、請求書、回収、認証及び匿名性を維持する中央制御装置の力は従来のシステムに対して本発明を改良あるものにしている。
【０１５４】
代理人ベースの売主
ＣＰＯ管理システムが所与のＣＰＯの承諾又は拒否を、ＣＰＯ管理システムにかかる権限を委託したある代理人ベースの売主の代わって許可する本発明の別の実施例の方法と装置について以下図２１乃至４０を参照して説明する。図２１は、一以上の顧客又は旅行案内業者２１１０、以下顧客２１１０という、からの条件的購入申込を受信して、航空会社２１２０、２１３０など複数の売主又はクルーズオペレータ（図示せず）によって定義された幾つかのＣＰＯ規程に対してその受信したＣＰＯを評価して所与のＣＰＯをいずれかの売主が承諾を了解するかを決定する条件付購入申込（ＣＰＯ）管理システム２１００を示している。後述するように、売主が所与のＣＰＯを承諾すれば、ＣＰＯ管理システム２１００はその顧客２１１０を承諾している売主２１３０の代わりに拘束して法律的に拘束力のある契約を作成する。
【０１５５】
ここで使用するように、ＣＰＯは、顧客が定義した価格における航空旅行などの品物購入に対して顧客２１１０から提出された一以上の条件を含む拘束力のある申込である。例示的な航空券の実施例では、顧客が定義した条件は、出発及び目的都市、出発と帰りの承諾可能な日時、接続便又は経由が顧客に承諾可能かどうかなどの旅程パラメータを含むであろう。加えて、ＣＰＯのパラメータにより、顧客は一以上の好ましい航空会社、フライト、座席指定、シートのクラス、飛行機の種類、払戻し／変更規則、最大待合せ時間を特定することができる。クルーズの実施例では、顧客が定義した条件は、出発及び目的都市、出発と帰りの承諾可能な日時、一以上の好ましいクルーズオペレータ、船舶の種類、客室のクラス、食事の好みなどの旅程パラメータを含むであろう。
【０１５６】
更に以下に説明するように、ＣＰＯ規程は、航空会社など所与の売主が定義した、売主が所定の最低価格の承諾を了解する制限の組合せを定義する一連の制限である。好ましい実施例では、ＣＰＯ規程は、それぞれの航空会社やクルーズオペレータの収入管理システム２５００によって生成される。代替的な実施例では、ＣＰＯ規程は、売上管理システム、利潤管理システムその他在庫を制御管理するいかなるシステムによっても生成可能である。
【０１５７】
図２５ｂ及び図３９に関連して後で十分に説明するように、収入管理システム２５００は、将来の旅行を予測するために、過去のパターンや外部事件と共に、現在の在庫、価格付け及び収入情報を評価して、ＣＰＯ規程を生成するＣＰＯ規程生成処理３９００を利用している。その後、ＣＰＯ規程は、特定の航空会社又はクルーズオペレータに代わって、ＣＰＯを承諾、拒否又は代案発行するかを決定するのにＣＰＯ管理システム２１００によって利用されている。本発明の特徴によれば、ＣＰＯ規程は本来動的で、所与の航空会社その他の売主によって必要があれば更新することができる。
【０１５８】
例えば、所与の航空会社に対するＣＰＯ規程は、（ｉ）顧客が火曜日と木曜日の間で旅行し、（ｉｉ）チケットが出発の２１日以内に予約され、（ｉｉｉ）チケット毎の価格が少なくとも１６５ドルで、（ｉｖ）顧客の旅程の全フライトセグメントにＫクラス在庫が利用可能で、（ｖ）最低２人の旅行同伴乗客がいる場合には、その航空会社は１９９７年１０月中はニュージャージー州ニューワーク（ＥＷＲ）とフロリダ州オーランド（ＭＣＯ）との間の旅行に対するいかなるＣＰＯも承諾すると特定することができる。
【０１５９】
ＣＰＯ管理システム２１００は、航空券又はクルーズチケットを販売するシステムとしてここで例示されているが、ＣＰＯ管理システム２１００は、当業者に明らかになるであろうように、オートバイ、保険、コンピュータ装置又はホテル宿泊などいかなる商品又は役務の製品をも販売するのに利用されることができる。かかる品物を販売する一般的ＣＰＯ管理システムのより詳しい説明のために、本発明に対する親出願でありここに参照して結合される１９９６年９月４日に出願された米国特許出願番号第０８／７０７，６６０を参照のこと。かかる代替的な実施例においては、図２５ａ乃至２５ｃに関連して後述する収入管理システム２５００は、在庫管理システム又はそれぞれの品物に対して価格付け及び在庫情報を設定するのに売主が利用可能なその他のシステムとして具体化されることができることに留意する必要がある。
【０１６０】
ＣＰＯ管理システム
図２１で示すように、ＣＰＯ管理システム２１００は、好ましくは、ＣＰＯ管理中央サーバー２２００と一以上の機密保持（がなされている）航空会社サーバー２３００とを有している。図２３に関連して後述するように、各々の機密保持航空会社サーバー２３００は、一以上の航空会社又はクルーズオペレータに関連付けられることができ、各サーバー２３００は、他のものに加えて、航空会社２１２０などいずれかの関連売主が定義したＣＰＯ規程を格納することができる。各機密保持航空会社サーバー２３００は、図２１に示すように、ＣＰＯ管理中央サーバー２２００から遠隔的に配置又はＣＰＯ管理中央サーバー２２００に一体化が可能である。ある遠隔地の実施例においては、各航空会社又はクルーズオペレータに関連付けられた機密保持航空会社サーバー２３００は特定の航空会社又はクルーズオペレータによって機密保持がなされている処理施設又は第三者の物理的場所に物理的に配置されることができる。このようにして、航空会社又はクルーズオペレータがＣＰＯ規程を独自に評価することができる。
【０１６１】
特定の場所の機密保持航空会社サーバー２３００は、当業者に明らかであるように、航空会社２１３０、２１３０又はクルーズオペレータ（図示せず）とＣＰＯ管理システム２１００との間で送信された情報の性質を指示することができる。例えば、機密保持航空会社サーバー２３００はＣＰＯ管理中央サーバー２２００に統合されるか、各々の航空会社２１２０、２１３０又はクルーズオペレータ（図示せず）から遠隔的に配置されているならば、それぞれの航空会社２１２０、２１３０又はクルーズオペレータはＣＰＯ規程を、ＣＰＯ規程の格納と受信された各ＣＰＯへのＣＰＯ規程の適用のために、その航空会社の機密保持航空会社サーバー２３００の場所に送信するであろう。同様に、機密保持航空会社サーバー２３００が関連航空会社又はクルーズオペレータによって機密保持がなされている処理施設に物理的に存在すれば、ＣＰＯ管理中央サーバー２２００はＣＰＯを各航空会社又はクルーズオペレータに処理のために送信し、航空会社又はクルーズオペレータは各ＣＰＯ毎にＣＰＯ管理中央サーバー２２００に応答を返すであろう。従って、ＣＰＯ管理システム２１００は、ＣＰＯを各売主に与えて承諾又は拒否を受信することによって、若しくは、特定の売主の代わりにＣＰＯを承諾、拒否又は代案発行するかを決定するためにＣＰＯをＣＰＯ規程に適用することによって、一以上の売主が所与のＣＰＯを承諾するかを決定することができる。
【０１６２】
ＣＰＯ規程は、もし売主の競争相手や顧客に知られれば売主の全収入構造に大打撃を与えることになる価格弾力性と利用可能な容量を含む機密情報を含んでいる。従って、本発明の特徴によれば、ＣＰＯ規程は、航空会社２１２０など一の売主が他の売主のＣＰＯ規程をアクセス、入手又は変更することを防止するために、必要があれば、好ましくは、各航空会社サーバー２３００に機密的に格納される。ある実施例では、機密保持航空会社サーバー２３００はデータベースアクセス制御機構などのコンピュータ機密保持技術を利用している。このようにして、ＣＰＯ規程の完全性と秘匿性は潜在的に劣悪な計算環境で維持される。
【０１６３】
また、本発明の更なる機能によれば、ＣＰＯ管理システム２１００は、所与のフライト又は寝台に対する売主が定義した最低価格をつきとめるために、顧客２１１０が徐々に増加する価格を含む多数のＣＰＯを提出することを防止している。例えば、ＣＰＯが、航空会社２１２０又はクルーズオペレータによって承諾されると顧客２１１０を拘束するならば、顧客２１００は売主の基底価格弾力性をつきとめるためにＣＰＯ管理システム２１００を「ピング（ｐｉｎｇ）する」のを思いとどまるだろう。また、ＣＰＯ管理システム２１００はどの顧客２１１０でも所定期間内に提出可能なＣＰＯの数を制限することができる。
【０１６４】
代替的な実施例では、顧客又は旅行案内業者２１１０は少なくとも一の航空会社がＣＰＯを承諾するときにチケットが予約されていなければ料金又は罰則を課されるか、ＣＰＯ管理システム２１００は、かかる顧客２１１０は当該ＣＰＯに対応するチケットを予約したであろう可能性に関する情報を含むかかる顧客２１１０の信頼度を評価することができる。適切な信頼度システムのより詳細な説明は、１９９７年３月４日に出願され、本発明の譲受人に譲渡されここで参照して結合される合衆国特許出願番号第０８／８１１，３４９号、発明の名称「航空会社価格問い合わせ方法及びシステム」を参照のこと。一の実施例では、評価された信頼度は、顧客２１１０の購入申込に対する予約率から構成されている。このようにして、航空会社又はクルーズオペレータは売主が顧客の申込を承諾するならば顧客は売主の基底レベルの価格弾力性を確かめるのに情報を使用しないでそのチケットを予約するだろうということを確信することができる。所与の機密保持航空会社サーバー２３００の特定の場所は、関連航空会社又はクルーズオペレータが機密性の高いＣＰＯ規程用に希望する機密保持対策レベルにも打撃を与える場合がある。例えば、所与の機密保持航空会社サーバー２３００は単一の航空会社に専用で、関連航空会社によって機密保持がなされている処理施設に物理的に存在すれば、必要があれば、それぞれの航空会社はそれ自身のＣＰＯ規程に対して各ＣＰＯの処理を制御するために独自の最小機密保持対策を実行することができ、それによってＣＰＯ規程に組み込まれた価格機密情報の完全性と秘匿性を維持することができる。しかし、所与の機密保持航空会社サーバー２３００がＣＰＯ規程を複数の航空会社又はクルーズオペレータに対して格納し、かかる航空会社又はクルーズオペレータから遠隔的に配置されていれば、当業者には明らかになるであろうように、コンピュータ機密保持とデータベースアクセス制御機構を実行する重要性は増加するであろう。
【０１６５】
以下に更に説明するように、各顧客２１１０はＣＰＯ管理システム２１００に、例えば、電話、ファクシミリ、オンラインアクセス、Ｅメール、参上する連絡により又は旅行案内業者を介して連絡をとり、ＣＰＯ管理システム２１００に彼らのＣＰＯの条件に与える。各顧客２１００は、ＣＰＯ管理システム２１００と通信するのに汎用コンピュータを使用することができることに留意する必要がある。各顧客２１１０の汎用コンピュータは好ましくは処理ユニット、モデム、メモリ手段そしてＣＰＯ管理システム２１００と通信するのに必要なソフトフェアを有している。
【０１６６】
ＣＰＯの条件が一旦ＣＰＯ管理システム２１００によって受信されると、ＣＰＯ管理中央サーバー２２００は、図３６ａ乃至図３６ｃに関連付けられて以下に後述されているように、ＣＰＯ管理処理３６００を実行する。この比較の結果、ＣＰＯは承諾されるか、拒否されるか、代案対象とされる。その後、顧客２１１０は航空会社又はクルーズオペレータのＣＰＯに対する応答を通知される。売主がＣＰＯを承諾れば、又は、顧客２１１０が売主からの代案を承諾れば、チケットはその後ＣＰＯ管理システム２１１０によって顧客２１１０によって定義された条件に適合する適当な制限で予約される。
【０１６７】
本発明の更なる特徴によれば、ＣＰＯの最小要求は満額料金を支払うことを典型的に了解する出張旅行者や出発間際の旅行者によって本システムの利用を思いとどまるように設計されている。例えば、出張旅行者は、ＣＰＯ規程が顧客２１１０による土曜夜の滞在や顧客の旅程の出発と帰りの両方の時間に関して大幅な弾力性を要求していれば、思いとどまるであろう。このようにして、その旅行のどちらか一端の丸一日を無駄にすることを典型的に了解しない出張旅行者は、かかる割引チケットの購入を思いとどまるであろう。従って、本発明により、航空会社は、航空会社２１２０、２１３０の基底料金構造は無傷で、潜在的な満たされていないレジャー旅行を刺激する方法で空席を埋めることができる。
【０１６８】
同様に、ＣＰＯ管理システムがいかなる品物の販売にも利用される実施例においては、ＣＰＯの最低限の要求は、典型的に満額小売価格を支払うことを了解する顧客がこのシステムの利用を思いとどまるように好ましくは設計されている。例えば、流行品販売の場合、ＣＰＯ顧客は先シーズンの流行品を購入するように要求することができる。同様に、ＣＰＯ規程は所与の品物を多量に購入するように要求するように設計されることができ、これによって品物を一つだけを探していて満額小売価格を支払う可能性のある顧客による利用を思いとどまらせることができる。
【０１６９】
好ましい実施例では、ＣＰＯ管理システム２１００は、図２４を参照して後述するように、所与の旅程を満足させる特定のフライト又は寝台を識別する旅程質問を実行して予約をするために、中央予約システム（ＣＲＳ）２４００に選択的にアクセスすることができる。中央予約システム（ＣＲＳ）２４００は、例えば、アポロ、サブレ、システムワン又はワールドスパンなどの現存する従来の予約システムとして具体化されることができる。
【０１７０】
また、ＣＰＯ管理システム２１００は、かかる旅程質問を実行してそれぞれの航空会社又はクルーズオペレータで予約をするために、各航空会社又はクルーズオペレータの専売予約システム（ＡＲＳ）２５００に代替的にアクセスすることもできる。各航空会社２１２０が保持する航空会社予約システム（ＡＲＳ）２１５０は、本質的に各々中央ＣＲＳ２４００のサブセットである。従って、各航空会社又はクルーズオペレータのＣＲＳ２４００と専売予約システム２１５０の重複機能及び能力に関して、ＣＰＯ管理システム２１００は必要情報を得るためにかかるシステムのいずれにもアクセスすることができ、「ＣＲＳ」と「ＡＲＳ」の用語はここで置換可能に使用される。
【０１７１】
図２１に示すように、各航空会社２１２０、２１３０又はクルーズオペレータ（図示せず）は、図２５ａ乃至図２５ｃを参照して後述する収入管理システム（ＲＭＳ）２５００も有している。ＲＭＳ２５００は従来のＲＭＳとして具体化されることができ、ＣＰＯ規程を生成してＣＰＯ顧客に販売用航空券又はクルーズチケットを割り当てて価格付けをするようにここでは変形されている。
【０１７２】
一般に、収入管理システム（ＲＭＳ）２５００は、周知の方法でフライト又は寝台毎に収入を最適化するのに利用される。ＲＭＳは、乗客の混合を最適化することによって生成された収入を最大限にするために、様々な料金クラスに対して定期的にネストされた予約限度（「バケツ」）を調整することによって座席又は客席在庫制御を実行する。
【０１７３】
ＣＰＯ管理システム２１００、顧客２１１０、航空会社２１２０、２１３０、クルーズオペレータ（図示せず）及び中央予約システム２４００は（総括的に、「ノード」という）は、好ましくは、ディジタル的にコード化されたデータその他の情報を相互に送信する。ノード間の通信リンクは、好ましくは、電子信号が伝搬可能なケーブル、ファイバー又は無線リンクを有している。例えば、各ノードは、市内又は地域的電話会社によって供給されているもののように、公衆電話交換網（ＰＳＴＮ）を利用してインターネット接続を介して接続されることができる。代替的に、各ノードは専用データ線、携帯電話、パーソナルコミュニケーションシステム（ＰＣＳ）、マイクロ波又は衛星ネットワークによって接続されてもよい。
【０１７４】
図２２は、例示的ＣＰＯ管理中央サーバー２２００の構築を示すブロック図である。ＣＰＯ管理中央サーバー２２００は、中央演算処理装置（ＣＰＵ）２２０５、ランダムアクセスメモリ（ＲＡＭ）２２１０、リードオンリメモリ（ＲＯＭ）２２２０、クロック２２２５、データ記憶装置２２３０及び通信ポート２２４０、２２５０、２２６０などのある標準ハードウェアコンポーネントを好ましくは含んでいる。ＣＰＵ２２０５は、好ましくは、リストの他の要素の各々に、図２２に示すように、共有データバス又は専用接続手段によって、リンクされている。
【０１７５】
ＣＰＵ２２０５は、インテルペンティアム(R)１００ＭＨｚ  Ｐ５４Ｃマイクロプロセッサ、モトローラの１２０ＭＨｚ  ＰｏｗｅｒＰＣ  ６０４マイクロプロセッサ又はサンマイクロシステムの１６６ＭＨｚ  ＵｌｔｒａＳＰＡＲＣ−１マイクロプロセッサ等の、一の商業的に入手可能な処理装置として具体化されることができる。代替的に、ＣＰＵ２２０５は、パラレル動作する幾つかの処理装置として具体化されてもよい。
【０１７６】
ＲＯＭ２２２０及び／又はデータ記憶装置２２３０は、図３６に関連して後述するように、ＣＰＵ２２０５が検索、解釈及び実行するように動作可能な一以上の命令を格納するように動作することができる。例えば、ＲＯＭ２２２０及び／又はデータ記憶装置２２３０は、航空会社２１２０、２１３０と顧客２１１０との間で要求された支払い、課金及びデビットの移転を実行するための処理を好ましくは格納する。特に、図３６ｃに関連して後述するように、チケットが現実に顧客２１１０に発行されると、ＣＰＵ管理処理３６００は、所与の顧客２１１０に関連するクレジットカード情報を支払用にクレジットカード発行者に好ましくは送信する。かかる会計取引処理は、例えば、周知の暗号技術を利用して、従来の方法で好ましくは機密保持される。
【０１７７】
ＣＰＵ２２０５は、制御ユニットと、算術論理ユニット（ＡＬＵ）と、スタック可能なキャッシュや複数のレジスタなどＣＰＵローカルメモリ記憶装置とを既知の方法で、好ましくは有している。制御ユニットはデータ記憶装置２２３０又はＲＯＭ２２２０から命令を検索するように動作することができる。ＡＬＵは、命令実行に必要な複数の動作を実行するように動作することができる。ＣＰＵローカルメモリ記憶装置は、一時的結果と制御情報を格納するのに使用される高速記憶装置を与えるように動作することができる。
【０１７８】
図２６乃至図２９に関連して各々後述するように、データ記憶装置２２３０は顧客データベース２６００、航空会社データベース２７００、フライトスケジュールデータベース２８００、及び、ＣＰＯデータベース２９００を有している。顧客データベース２６００は、ＣＰＯ管理システム２１００の各顧客に関する履歴情報やクレジットカード番号などの請求書情報を含む情報を好ましくは格納している。航空会社データベース２７００は、ＣＰＯ顧客に航空券を販売するために、ＣＰＯ管理システム２１００に登録されている各航空会社に関する住所及び契約情報を含む情報を好ましくは格納している。フライトスケジュールデータベース２８００は、好ましくは、各Ｏ＆Ｄペアに対して特定のフライト情報を格納する。最後に、ＣＰＯデータベース２９００は、ＣＰＯの条件と関連ステイタスを含むＣＰＯ管理システム２１００によって処理される各ＣＰＯの記録を好ましくは含んでいる。
【０１７９】
また、データ記憶装置２２３０は、図３６に関連して後述するＣＰＯ管理処理３６００を含んでいる。一般に、ＣＰＯ管理処理３６００は、各ＣＰＯを顧客２１１０から受信し、ＣＰＯを各航空会社２１２０、２１３０のＣＰＯ規程と比較し、そのＣＰＯを承諾、拒否又は代案発行するかどうか航空会社の代わりに決定する。
【０１８０】
通信ポート２２４０は、ＣＰＯ管理中央サーバー２２００を中央予約システム（ＣＲＳ）２４００と各航空会社２１２０、２１３０が保持する専売予約システム（ＡＲＳ）２１５０に接続する。通信ポート２２５０は、ＣＰＯ管理中央サーバー２２００を顧客２１１０などの個人客と旅行案内業者に、例えば、公衆電話交換網（ＰＳＴＮ）を利用するインターネット接続によって接続する。通信ポート２２６０は、ＣＰＯ管理中央サーバー２２００を遠隔地のいずれかの機密保持航空会社サーバー２３００に接続する。通信ポート２２４０、２２５０、２２６０は、各々、複数の接続を同時に設定する多重通信チャネルを好ましくは有している。ＣＰＯ管理中央サーバー２２００は３つの別個の通信ポート２２４０、２２５０、２２６０を有するものとして例示されているが、ＣＰＯ管理中央サーバー２２００は、代替的に、中央サーバー２２００に様々なノードへの接続を代わりに提供する中央イーサネット（Ｅｒｔｈｅｒｎｅｔ）ネットワーク（Ｒ）への単独接続によって代替的に実行されることができる。
【０１８１】
図２３は、例示的機密保持航空会社サーバー２３００の構築を示すブロック図である。前述したように、ＣＰＯ管理システム２１１０は、各々が一以上の航空会社２１２０、２１３０をサポートしている一以上の機密保持航空会社サーバー２３００を利用することができる。各々の機密保持航空会社サーバー２３００は、中央演算処理装置（ＣＰＵ）２３０５、ランダムアクセスメモリ（ＲＡＭ）２３１０、リードオンリメモリ（ＲＯＭ）２３２０、クロック２３２５、データ記憶装置２３３０及び通信ポート２３４０、２３４５などのある標準ハードウェアコンポーネントを好ましくは含んでいる。これらのコンポーネントの各々は図２２に関連して上述したものと同一でもよい。
【０１８２】
前述したように、一の実施例において、ＣＰＯ規程は、各ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、機密保持がなされているデータベースに格納されることができる。従って、機密保持航空会社サーバー２３００は、オラクル（Ｏｒａｃｌｅ）、インフォミックス（Ｉｎｆｏｒｍｉｘ）又はＩＢＭから商業的に入手可能な製品などの機密保持がなされているデータベースを好ましくは使用している。
【０１８３】
図３０乃至３２に関連してそれぞれ後述するように、データ記憶装置２３３０は、機密保持航空会社規程データベース３０００、代案規程データベース３１００及び機密保持航空会計データベース３２００を有している。機密保持航空会社規程データベース３０００は、機密保持航空会社サーバー２３００に関連する一以上の航空会社のためにＣＰＯ規程を好ましくは保存している。ＣＰＯが所与のＣＰＯ規程に関連する一以上の制限の所定許容範囲内にあれば、代案ＣＰＯ管理システム２１００が航空会社に代わってＣＰＯに対する代案を生成するのに利用することができる一連の許容度を保存するために、規程データベース３１００は各機密保持航空会社サーバー２３００によって好ましくは格納される。前述したように、機密保持航空会社規程データベース３０００及び代案規程データベース３１００は、ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、暗号形式で格納されることができる。機密保持航空会計データベース３２００は、ＣＰＯ管理システム２１００が処理する会計形跡を各ＣＰＯ毎に好ましくは保存する。
【０１８４】
また、データ記憶装置２３３０は、図３７及び図３８に関連してそれぞれ後述する評価処理３７００と会計処理３８００を含んでいる。一般に、評価処理３７００は、ＣＰＯを受信して当該ＣＰＯを航空会社２１２０等の一の航空会社の規程に比較してその航空会社に代わってその所与のＣＰＯに対する応答を生成するＣＰＯ管理処理３６００が実行するサブルーチンである。会計処理３８００は、ＣＰＯ管理システム２１００が処理する会計形跡を各ＣＰＯに対して保存するためにＣＰＯ管理処理３６００が実行するサブルーチンである。
【０１８５】
通信ポート２３４０は、機密保持航空会社サーバー２３００をＣＰＯ管理中央サーバー２２００に接続する。通信ポート２３４５は機密保持航空会社サーバー２３００を関連航空会社２１２０に接続する。通信ポート２３４０、２３４５は、複数の接続を同時に設定する多重通信チャネルを好ましくは有している。
【０１８６】
中央予約システム
図２４は、例示的中央予約システム（ＣＲＳ）サーバー２４００の構築を示すブロック図である。ＣＲＳ２４００は、中央演算処理装置（ＣＰＵ）２４０５、ランダムアクセスメモリ（ＲＡＭ）２４１０、リードオンリメモリ（ＲＯＭ）２４２０、クロック２４２５、データ記憶装置２４３０及び通信ポート２４４０等の、ある標準ハードウェアコンポーネントを好ましくは含んでいる。これらのコンポーネントの各々は、図２２に関連して上述したものと同一でもよい。
【０１８７】
ＲＯＭ２４２０及び／又はデータ記憶装置２４３０は、  （１）航空会社から受信したフライト情報、（２）フライトの利用可能性に関する旅程質問、及び、（３）チケットの予約を、既知の方法で処理し、ＣＰＵ２４０５が検索、解釈及び実行するように動作可能な一以上の命令を格納するように動作することができる。
【０１８８】
図２８、図３３及び図３４を参照してそれぞれ後述するように、データ記憶装置２４３０は、フライトスケジュールデータベース２８００と、価格付け・制限データベース３３００と、座席割当データベース３４００とを有している。前述したように、フライトスケジュールデータベース２８００は、本質的に、ＣＰＯ管理中央サーバー２２００に格納されている同一名のデータベース、即ち、Ｏ＆Ｄペアに対する特定のフライト情報と同一のフライト情報を含んでいる。価格付け・制限データベース３３００は、航空会社２１２０、２１３０が提供する所与のフライトに関する料金クラスに対する価格付け情報と関連制限を保存している。座席割当データベース３４００は、航空会社２１２０、２１３０が提供する所与のフライトに関する各料金クラスに対して入手可能な在庫情報を保存している。
【０１８９】
通信ポート２４４０は、ＣＲＳ２４００をＣＰＯ管理中央サーバー２２００と航空会社２１２０、２１３０などの各航空会社に接続する。ＣＲＳ２４００は、ＣＲＳ２４００と様々な顧客２１１０、航空会社２１２０、２１３０及びＣＰＯ管理システム２１００との間で送信されるＥメールメッセージを処理格納する電子メール処理装置２４５０を好ましくは含んでいる。
【０１９０】
収入管理システム
図２５ａは、航空会社２１２０などの各航空会社が維持するように、例示的収入管理システム（ＲＭＳ）２５００の構築を示すブロック図である。前述したように、ＲＭＳ２５００は、サブレディシジョンテクノロジーズ（Ｓａｂｒｅ  Ｄｅｃｉｓｉｏｎ  Ｔｅｃｈｎｏｌｏｇｉｅｓ）から商業的に入手可能なＲＭＳなど従来のＲＭＳとして具体化されることができ、ここではＣＰＯ規程を生成して販売用に航空券をＣＰＯ顧客に割り当てて価格付けするように変更されている。このようにして、ＲＭＳ２５００は、航空会社２１２０の在庫の一部をＣＰＯ顧客２１１０への販売に供することができる。多くの航空会社に対してＲＭＳは在庫割当機能だけを実行し、価格付け機能を組み込んでいないことに留意する必要がある。かかる場合、手動処理などの別個の処理を、ＲＭＳが割り当てた在庫を価格付けするのに利用される。ここで開示された例示的実施例では、ＲＭＳ２５００は在庫割り当てと価格付け機能の両方を発揮する。
【０１９１】
ＲＭＳ２５００は、中央演算処理装置（ＣＰＵ）２５０５、ランダムアクセスメモリ（ＲＡＭ）２５１０、リードオンリメモリ（ＲＯＭ）２５２０、クロック２５２５、データ記憶装置２５３０及び通信ポート２５４０等ある標準ハードウェアコンポーネントを好ましくは含んでいる。これらのコンポーネントの各々は、図２２に関連して上述したものと同一であってもよい。
【０１９２】
ＲＯＭ２５２０及び／又はデータ記憶装置２５３０は、航空会社のために収入を最大にするように座席在庫を割り当てて価格付けするために、過去のパターンと共に現在の座席在庫と収入を分析し、ＣＰＵ２４０５が検索、解釈及び実行するように動作可能な一以上の命令を格納するように動作することができる。
【０１９３】
図３３乃至図３５に関連してそれぞれ後述するように、データ記憶装置２５３０は、予測・需要分析データベース３５００と共に、それぞれ本質的にＣＲＳ２４００に格納されている同一名のデータベースと同一情報を有する価格付け・制限データベース３３００と座席割当データベース３４００とを含んでいる。前述したように、価格付け・制限データベース３３００は、関連航空会社２１２０が提供する所与のフライトに関する各料金クラスに対する価格付け情報と関連制限を保存しており、座席割当データベース３４００は、関連航空会社２１２０が提供する所与のフライトに関する各料金クラスに対する入手可能な在庫情報を保存している。予測・需要分析データベース３５００は、所与のフライトに対する各料金クラスに対して各販売価格の情報を含んでおり、ＲＭＳ２５００が設定するように各販売価格における需要を予測する。また、データ記憶装置２５３０は、将来の旅行を予測するために過去のパターンと共に現在の在庫、価格及び収入情報を評価することによって、ＣＰＯ規程を生成すべく、図３９に関連して後述するＣＰＯ規程生成処理３９００を好ましくは含んでいる。
【０１９４】
通信ポート２５４０は、各ＲＭＳ２５００をＣＲＳ２４００とＣＰＯ管理システム２１００に接続する。
【０１９５】
図２５ｂは、ＲＭＳ２５００が従来の価格付け及び割当処理とＣＰＯ規程生成処理３９００を実行する際に利用する幾つかのデータベースその他の手段を示している。図２５ｂに示す例示的データベースの特定の形式と内容は図３３乃至図３５に関して詳細に後述する。従来の価格付け及び割当処理とＣＰＯ規程生成処理３９００は、フライトが最初にフライトスケジュールに加えられると最初にその後定期的にＲＭＳ２５００により、需要と外部事件に応答して入手可能な在庫を再割当及び価格付けをするために、実行可能であることに留意する必要がある。
【０１９６】
従って、フライトが最初に航空会社２１２０のフライトスケジュールに加えられると、フライトの記録が、適当な旅程情報を有するフライトスケジュールデータベース２８００内の航空会社予約システム２１５０によって好ましくは形成される。また、ＲＭＳ２５００は、図２５ｂに示すように、価格付け・制限データベース３３００、座席割当データベース３４００及び予測・需要分析データベース３５００のそれぞれのフィールドをフライト用にまず埋め、図３９に示すＣＰＯ規程生成処理３９００に関連して従来の価格付け及び割当処理を実行する。
【０１９７】
一般に、所与のフライトに対する最初の価格付け及び割当処理の間、ＲＭＳ２５００は複数の料金クラスを設定して座席数と各料金クラスに割り当てられた価格を指定することによって収入の最大化を試みる。最初の座席割当及び価格付け情報は、座席割当データベース３４００と価格付け・制限データベース３３００のそれぞれに格納される。各料金クラスに対する最初の価格と予測需要は、好ましくは、予測・需要分析データベース３５００に格納されている。ある実施例では、ＣＰＯ顧客にチケットを販売するためにＲＭＳ２５００によって別個の料金クラスが設定可能である。ＣＰＯ顧客へのチケットは一般に割引販売されるので、ＲＭＳ２５００は、好ましくは、フライトが現実に出発すると空席になることが予測されるか販売される見込みが少ないＣＰＯ料金クラスに座席をまず割り当てるだけである。周知のように、航空会社は、所与のフライトに関して空席があるかどうかを利用可能な過去のデータに基づいて予測するのに従来のＲＭＳ２５００を利用することができる。
【０１９８】
図２５ｂに示すように、航空会社予約システム（ＡＲＳ）２１５０は、旅程質問を実行するために、設定された価格付け・制限データベース３３００及び座席割当データベース３４００にアクセスするであろう。また、チケットが航空会社２１２０によって販売されると、ＡＲＳ２１５０は座席割当データベース３４００に入手可能な在庫を好ましくは減分するであろう。このようにして、座席割当データベース３４００は、各フライトに関して入手可能な在庫の最新表示を保存している。
【０１９９】
ＲＭＳ２５００は、図２５ｃに示すように、予測需要２５７０に対して各料金クラス内で現実の需要２５６０の監視を継続し、予測されない超過在庫デルタ２５８０を最小にするために所与のフライトに対する各料金クラスの在庫割当及び価格付けを動的再評価する。ＲＭＳ２５００は、座席割当データベース３４００から詳細な在庫データ又は予測・需要分析データベース３５００から要約情報を検索することによって、現在の現実の需要情報を監視する。また、ＲＭＳ２５００は、各フライトに関する所与の料金クラスの各販売価格に対して需要曲線を与える以前の期間の予測・需要分析データベース３５００に格納された過去の需要情報を利用するであろう。例えば、所与のフライトに対して在庫割当及び価格付けする際に、ＲＭＳ２５００は既知の方法で以前の関連期間から類似フライトに対する需要傾向を分析することができる。従来のＲＭＳは、図２５ｂに示すように、価格競争やオリンピックなどの大イベントのための増加需要など競争力その他の外部事件に典型的に応答することにも留意する必要がある。
【０２００】
本発明の特徴によれば、航空会社２１２０は、必要があれば、ＣＰＯ顧客への販売用チケットを開放することによって、予測誤差その他の予期されない超過容量２５８０を作り出した競争力を訂正することができる。ＣＰＯ規程の秘匿性と満額料金出張旅行者によるＣＰＯチケットの思いとどまった使用により、航空会社２１２０、２１３０はその現存する公表料金構造を傷つけることなしに、かかる超過容量を割引販売することができる。従って、好ましい実施例においては、ＲＭＳ２５００は、ＣＰＯ顧客へのチケット販売を奨励するＣＰＯ規程を生成するために、図３９に関連して後述するＣＰＯ規程生成処理３９００を定期的に実行するであろう。
【０２０１】
データベース
図２６は、ＣＰＯ管理システム２１００の各顧客に関する履歴情報及びクレジットカード番号などの請求書情報などの情報を好ましくは格納している例示的顧客データベース２６００を示している。顧客データベース２６００は、異なる顧客に各々関連付けられた記録２６０５−２６１５等の複数の記録を保存している。フィールド２６４０にリストされた各顧客名毎に、顧客データベース２６００は、顧客の住所をフィールド２６４５に、クレジットカード番号をフィールド２６５５に含んでいる。また、顧客口座データベース２６００は、識別（ＩＤ）番号をフィールド２６６０に好ましくは含んでいる。フィールド２６６０に格納されているＩＤ番号は、例えば、以前のチケット購入と顧客に関連付けられたＣＰＯの過去のデータベース（図示せず）にインデックスを付すのに利用することができる。
【０２０２】
図２７は、住所と連絡先情報を含み、航空券をＣＰＯ顧客に販売するためにＣＰＯ管理システム２１００に登録されている各航空会社に関する情報を好ましくは格納している例示的航空会社データベース２７００を示している。航空会社データベース２７００は、異なる航空会社に各々関連付けられている記録２７０５−２７１５等の複数の記録を保存している。フィールド２７４０にリストされた各航空会社名に対して、航空会社データベース２７００は住所と連絡情報をフィールド２７４５及び２７５０のそれぞれに有している。連絡先情報は、例えば、その航空会社２１２０の個別従業員名と対応する電話番号、ウェブページＵＲＬ、電子掲示板アドレス、ページャー番号、電話番号、電子メール番号、ボイスメールアドレス又はファクシミリ番号を含んでいる。
【０２０３】
また、所与の航空会社のＣＰＯ規程が暗号形式で格納される実施例においては、関連航空会社の暗号キーが、好ましくは、航空会社データベース２７００のフィールド２７５５に格納されている。最後に、航空会社データベース２７００は、好ましくは、各航空会社が提供したＣＰＯのそれぞれの航空会社によって現実に承諾された割合の表示をフィールド２７６０に格納している。このようにして、ＣＰＯ管理システム２１００は、図３６ｂに関連して後述するように、ＣＰＯ承諾率に従ってランク付けされた順番で特定ＣＰＯを航空会社に提供することができる。代替的な実施例においては、航空会社データベース２７００は、（ｉ）各航空会社によってＣＰＯ顧客への販売に供されている在庫量、（ｉｉ）あるルートの航空会社の優先順位など各航空会社によって交渉された優先権、又は、（ｉｉｉ）ＣＰＯ管理システム２１００に航空会社が支払う最高委任料に基づく順番に従って、ＣＰＯ処理を容易にするためにフィールドを結合することができる。
【０２０４】
図２８は、接続情報と共に、各Ｏ＆Ｄペアに対して特定のフライト情報を好ましくは格納する例示的フライトスケジュールデータベース２８００を示している。フライトスケジュールデータベース２８００は各々が異なるフライトに関連付けられた記録２８０５−２８１５等の複数の記録を保存している。フィールド２８４０及び２８４５にリストされた各Ｏ＆Ｄペアに対して、フライトスケジュールデータベース２８００は、各フライトの日付をフィールド２８５０に、また、それぞれのフライトの出発と到着時間をフィールド２８５５及び２８６０に有している。各フライトに関連付けられている航空会社及び飛行便番号は、フィールド２８６５及び２８７０にそれぞれ好ましくは表示され、要求されているいかなる接続もフィールド２８７５に表示されている。
【０２０５】
図２９ａ及び２９ｂは、ＣＰＯの条件と関連ステイタスを含む、ＣＰＯ管理システム２１００が処理する各ＣＰＯの記録を好ましくは有する例示的ＣＰＯデータベース２９００を示している。ＣＰＯデータベース２９００は、システム２１００が処理している異なるＣＰＯに各々関連付けられた記録２９０５及び２９１０等の複数の記録を保存している。フィールド２９２０のＣＰＯ番号によって識別される各ＣＰＯ毎に、ＣＰＯデータベース２９００は、そのＣＰＯが受信された日付をフィールド２９２５に、ＣＰＯに関連付けられた旅行案内業者に対する識別（ＩＤ）番号がもしあればフィールド２９３０に含んでいる。フィールド２９３０に格納されている旅行案内業者ＩＤ番号は、例えば、以前のチケット購入とその旅行案内業者に関連付けられたＣＰＯの過去のデータベース（図示せず）をインデックス付けするのに利用してもよいことに留意することが必要である。
【０２０６】
また、ＣＰＯデータベース２９００は、フィールド２９３５の名前によって、そしてフィールド２９４０のＩＤ番号によって顧客を識別しており、フィールド２９４５のいかなる同乗者をも識別している。フィールド２９４５に格納されるＩＤ番号は、顧客データベース２６００に顧客に対して格納されている対応情報を相互参照するのに好ましくは利用される。
【０２０７】
顧客の旅程その他の関連制限のパラメータは、ＣＰＯデータベース２９００のフィールド２９５０乃至２９９５に格納される。特に、出発及び目的都市はフィールド２９５０及び２９５５でそれぞれ識別され、顧客２１１０が特定するいかなる接続制限もフィールド２９６０に記録されている。顧客の出発と帰りの日付はフィールド２９６５と２９７０にそれぞれ格納されている。（図示しない）代替的な実施例においては、ＣＰＯデータベース２９００により、顧客２１１０は出発及び帰りの便の特定の時刻（範囲）制限を特定することができる。
【０２０８】
ＣＰＯデータベース２９００は、好ましくは、同伴旅行乗客数合計表示をフィールド２９７５に格納し、顧客がチケット毎に支払うことを了解する価格をフィールド２９８０に述べる。好ましい航空会社、便又は座席指定等の顧客が特定するその他の雑多な制限はフィールド２９８５に記録される。フィールド２９９０は、「係属中」、「承諾」、「拒否」又は「満了」などの現在のそれぞれのＣＰＯステイタスを記録する。最後に、ＣＰＯが最終的に顧客にチケット予約となれば、そのチケットに関連付けられている乗客名記録番号（ＰＮＲ）はフィールド２９９５に格納される。一般に、ＰＮＲはＣＲＳ２４００が格納する記録で、チケットが発行された各乗客毎に、記録番号、乗客名、チケットの住所、クレジットカード番号などの請求書情報、全てのセグメントに対する運輸業者及び飛行便番号、座席指定、在庫クラス、飛行機の種類、割引料金に対して航空会社が発行する許可コード、販売価格及び追加コメントなどの情報を有している。
【０２０９】
後述するように、ＣＰＯを拒否する代わりに、一以上の航空会社は、その顧客２１１０が承諾又は拒否することができる拘束力のある代案をそのＣＰＯに対して発行することができる。代案が顧客２１１０に発行されれば、関連制限を有する代案の記録がＣＰＯデータベース２９００に好ましくは形成される。例えば、航空会社２１２０がＣＰＯデータベース２９００の記録２９０５に格納されたＣＰＯ番号２３４５６に対して代案発行すると、最初のＣＰＯのステイタスは「代案発行」に変更され、代案に対応する（図示しない）更なる記録は、ＣＰＯ番号２３４５６−ＣＯ１等のその代案を表示する修正ＣＰＯ番号の下でＣＰＯデータベース２９００に格納されることができる。
【０２１０】
図３０ａは、特定の機密保持航空会社サーバー２３００に関連付けられた一以上の航空会社に対してＣＰＯ規程を好ましくは保存する例示的機密保持航空会社規程データベース３０００を示している。上述したように、機密保持航空会社規程データベース３０００は、ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、暗号形式で格納されることができる。機密保持航空会社規程データベース３０００は、各々異なるＣＰＯ規程に関連付けられている記録３００２及び３００４等の複数の記録を保存している。フィールド３０１０の規程番号によって識別される各ＣＰＯ規程に対して、機密保持航空会社規程データベース３０００は、それぞれの航空会社が定義する関連制限をフィールド３０１２乃至３０４４に有している。
【０２１１】
本発明の特徴によれば、ＣＰＯ管理システム２３００が処理するＣＰＯ規程は様々な複雑性を有している。例示的機密保持航空会社規程データベース３０００で述べられている特定の制限は本発明の原理の典型でしかない。航空会社は、当業者には明らかになるであろうように、かかる制限のサブセットを結合し、及び／又は、追加的制限を結合することができる。例えば、航空会社２１２０のＣＰＯ規程は、旅程に最低限宿泊数の制限を結合することができるし、顧客に土曜夜の滞在を要求することができる。
【０２１２】
例示目的として、図３０ａに示す機密保持航空会社規程データベース３０００により、フィールド３０１２乃至３０４４において後述する幾つか又は全ての制限、即ち、出発及び目的都市、接続制限、包含又は除外飛行便番号、出発の日時、出発の曜日、帰りの日時、帰りの曜日、旅行乗客数、旅行距離、座席毎の平均売上、チケット当りの最低価格、在庫制限又は座席入手可能性及び事前購入要求を特定することによって、航空会社はＣＰＯ規程を形成することができる。
【０２１３】
例えば、  （ｉ）顧客が火曜日と木曜日の間で発つ便で旅行し、（ｉｉ）チケットが出発の２１日以内に予約され、（ｉｉｉ）チケット価格が少なくとも１６５ドルで、（ｉｖ）顧客の旅程の全フライトセグメントにＫ在庫が入手可能で、（ｖ）最低２人の同伴旅行乗客がいる場合には、航空会社は１９９７年１０月中はニュージャージー州ニューワーク（ＥＷＲ）とフロリダ州オーランド（ＭＣＯ）との間の旅行に対するいかなるＣＰＯも承諾すると特定する所与の航空会社に対するＣＰＯ規程に、図３０ａに示す記録３００２は関連付けられている。
【０２１４】
同様に、Ｑ又はＫの在庫が午前１１時から午後２時の間のいかなる便にも入手可能で、フライトが火曜日に出発して月曜日乃至木曜日に戻り、旅行前７乃至２１日で予約がなされ、その航空会社のオハイオ州クリーブランド又はペンシルバニア州ピッツバーグのハブを経由するルートを採ることができ、１９９７年４月又は５月中にニューヨーク州ニューヨーク（ＪＦＫ）とイリノイ州シカゴ（ＯＲＤ）間で同伴旅行する２人以上に対して少なくとも１５０ドルの価格を有するいかなるＣＰＯも承諾すると特定している所与の航空会社に対するＣＰＯ規程に、図３０ａに示す記録３００４は関連付けられている。
【０２１５】
代替的又は補助的実施例においては、機密保持航空会社規程データベース３０００は、図３０ｂ及び図３０ｃにそれぞれ示す一組の在庫及び価格付けデータベース３０５０、３０７５を利用して実行されることができる。本実施例において在庫データベース３０５０に格納されるＣＰＯ規程は、ＣＰＯ顧客に対する販売に対して航空会社が開放した各便に関しての現実の在庫を含んでいる。在庫データーベース３０５０は、異なるＣＰＯ規程とフライトに各々関連付けられている記録３０５２−３０５６等の複数の記録を保存している。フィールド３０６０の規程番号によって識別される各ＣＰＯ規程毎に、在庫データベース３０５０は、航空会社、飛行便番号及び日付の表示をフィールド３０６２乃至３０６６にそれぞれ含んでいる。また、ＣＰＯ管理システム２１００が各便に関して販売可能な座席数はフィールド３０６８に表示されている。好ましい実施例では、在庫はＣＰＯ管理システム２１００が販売するので、在庫データベース３０５０に記録されている入手可能な在庫は減らされる。
【０２１６】
図３０ｃに示す価格付けデータベース３０７５は、異なるＯ＆Ｄペアに各々関連付けられている記録３０８０−３０８４等の複数の記録を保存している。フィールド３０９０及び３０９２でそれぞれ識別される各Ｏ＆Ｄペア毎に、価格付けデータベース３０７５は航空会社、日付及び最低価格の表示をフィールド３０８８、３０９３及び３０９６のそれぞれに含んでいる。
【０２１７】
従って、かかる代替的又は補助的実施例においては、在庫データベース３０５０にアクセスする前に、ＣＰＯ管理システム２１００は、好ましくはＣＲＳ２４００に対して顧客の旅程制限を満足可能なフライトを識別するように質問する。その後、ＣＰＯ管理システム２１００は、航空会社が当該識別されたフライトをＣＰＯ管理システム２１００にＣＰＯ顧客販売用に解放したかを決定するために在庫データベース３０５０にアクセスする。ある実施例では、ＣＲＳ２４００からの識別されたフライトリストは、顧客の嗜好を最適化するために順番付けが可能で、在庫データベース３０５０はフライトの順番付けされたリストの順番で入手可能な在庫が識別されるまでサーチされることができる。最後に、顧客の旅程を満足する入手可能な在庫が識別されると、ＣＰＯ管理システム２１００は図３０ｃに示される価格データベース３０７５にアクセスし、価格付けデータベース３０７５のフィールド３０９６に述べられているように、顧客定義価格が航空会社定義最低価格を超えているどうかを決定する。
【０２１８】
図３１は、ＣＰＯが所与のＣＰＯ規程に関連付けられた一以上の制限の所定許容範囲内にあればＣＰＯ管理システム２１００がＣＰＯに対する代案を生成するのに利用することができる一連の許容度を好ましくは格納している例示的代案規程データベース３１００を示している。代案規程データベース３１００は、異なるＣＰＯ規程に各々関連付けられている記録３１０５及び３１１０等の複数の記録を保存している。フィールド３１２０の規程番号によって識別される各ＣＰＯ規程に対して、代案規程データベース３１００は出発及び帰りの日時に関する承諾可能な許容度をフィールド３１２５乃至３１４０に含んでいる。また、代案規程データベース３１００は、旅行乗客数、旅行距離及び売上に関する許容度をフィールド３１４５乃至３１５５にそれぞれ含んでいる。最後に、代案規程データベース３１００は、最低価格と事前購入要求に関するいかなる許容可能な許容度もフィールド３１６０乃至３１６５にそれぞれ記録している。
【０２１９】
図３１に示すように、代案規程データベース３１００は、図３０ａからのＣＰＯ規程番号４５６８７に対応する代案規程番号４５６８７を記録３１０５に有している。図３１に示すように、ＣＰＯ管理システム２１００は、所与のＣＰＯがＣＰＯ規程番号４５６８７の一以上の制限には適合しないが制限は代案規程データベース３１００に述べられている所定許容範囲内であれば、ＣＰＯ規程番号４５６８７に関連付けられた航空会社の代わりに代案を作成する権限を有する。例えば、所与のＣＰＯは顧客が定義した価格１４０ドルを含むがＣＰＯ規程番号４５６８７の他の航空会社が定義した全制限を満足していれば、価格変化がＣＰＯ規程番号４５６８７に関連付けられた最低価格の１０％以内であるので、代案規程番号４５６８７が許可するように、価格１５０ドルを含む代案が生成されなければならない。
【０２２０】
図３２は、ＣＰＯ管理システム２１００が処理する各ＣＰＯ毎に会計形跡を好ましくは保存する例示的機密保持航空会計データベース３２００を示している。機密保持航空会計データベース３２００は、ＣＰＯ管理システム２１００が処理する異なるＣＰＯに各々関連付けられている記録３２０５−３２１５等の複数の記録を保存している。フィールド３２２０のＣＰＯ番号により識別される各ＣＰＯ毎に、機密保持航空会計データベース３２００はそれぞれの航空会社によるＣＰＯへの応答をフィールド３２２５に、ＣＰＯの日付と時間をフィールド３２３０及び３２３５にそれぞれ含んでいる。また、チケットがいかなる航空会社に関しても顧客２１１０に予約されると、機密保持航空会計データベース３２００は、チケットに関連付けられている乗客名記録（ＰＮＲ）番号をフィールド３２４０に、チケットがそれぞれの航空会社に予約されたかどうかの表示をフィールド３２４５に好ましくは格納する。好ましい実施例においては、フィールド３２４５への入力はチケットが（ａ）データベースに関連付けられたそれぞれの航空会社に予約されたか、（ｂ）別の航空会社に予約されたか、又は、（ｃ）チケットが全く発行されなかったかどうかを示している。このようにして、ＣＰＯ管理システム２１００は少なくとも一の航空会社が承諾した各ＣＰＯに対してチケットが現実に予約されたことを設定することができる。
【０２２１】
図３３は、ＲＭＳ２５００が設定更新するように、航空会社２１２０、２１３０が提供する各フライト毎に価格付け情報と関連制限とを保存する例示的価格付け・制限データベース３３００を示している。価格付け・制限データベース３３００は、異なるフライトに各々関連付けられている記録３３０５−３３１５等の複数の記録を含んでいる。フィールド３３２５に飛行便番号により識別される各フライト毎に、価格付け・制限データベース３３００は、フライトの日付をフィールド３３３０に、各在庫クラスに関連付けられているそれぞれの価格及び制限をフィールド３３３５乃至３３５０に有している。
【０２２２】
図３４は、ＲＭＳ２５００が割当更新するように、航空会社２１２０、２１３０が提供する所与のフライトに関する各料金クラス毎に利用可能な在庫情報を保存している例示的座席割当データベース３４００を示している。また、在庫が航空会社によって販売されると、その航空会社のＡＲＳ２１５０は座席割当データベース３４００に記録された入手可能な在庫を好ましくは減分する。座席指定データベース３４００は、異なるフライトに各々関連付けられている記録３４０５−３４２０等の複数の記録を含んでいる。フィールド３４２５の飛行便番号により識別される各フライト毎に、座席指定データベース３４００はフライトの出発日をフィールド３４３０に、各在庫クラスでそれぞれ入手可能な在庫をフィールド３４３５乃至３４４０に含んでいる。また、座席指定データベース３４００は、そのフライトに関して予約された全座席数の表示をフィールド３４４５に、そのフライトに関して利用可能な容量をフィールド３４５０に好ましくは含んでいる。
【０２２３】
図３５は、ＲＭＳ２５００が設定するように、所与のフライトの各料金クラス毎に各販売価格を記録して各販売価格で需要を予測する例示的予測・需要分析データベース３５００を示している。前述したように、フライトが航空会社２１２０のフライトスケジュールにまず追加されると、各料金クラス毎の最初の価格の記録と予測需要が予測・需要分析データベース３５００に好ましくは形成される。また、新しい記録は、各料金クラス毎にＲＭＳ２５００が設定する各新販売価格毎に、動的在庫再割当処理の一部として好ましくは形成される。
【０２２４】
予測・需要分析データベース３５００は、所与のフライトに関する所与の料金クラスに対する異なる販売価格に各々関連付けられている記録３５０５−３５２５等の複数の記録を含んでいる。フィールド３５３０で識別される各飛行便番号毎に、予測・需要分析データベース３５００は、出発日、出発及び目的都市をフィールド３５３５乃至３５４５にそれぞれ、対応する申込価格と料金クラスをフィールド３５５０乃至３５５５にそれぞれ有している。最後に、予測・需要分析データベース３５００は、各料金クラスに対する各提供価格での航空会社による現実のチケット販売量をフィールド３５６０に記録する。現実のチケット販売量は、チケットが現実に販売されると実時間で又は定期的な一括処理によって、フィールド３５６０に実時間で記録されることができる。
【０２２５】
処理
上述したように、ＣＰＯ管理中央サーバー２２００は図３６ａ乃至３６ｃに示すＣＰＯ管理処理３６００を好ましくは実行して、顧客２１１０から各ＣＰＯを受信し、そのＣＰＯを各航空会社の規程と比較し、航空会社に代わってそのＣＰＯを承諾、拒否又は代案発行するかどうかを決定する。図３６ａに示すように、ＣＰＯ管理処理３６００は、顧客又は旅行案内業者がＣＰＯ管理システム２１００にアクセスすると、ステップ３６０４で本発明の原理を具体化する処理を開始する。
【０２２６】
その後、ステップ３６０８で、ＣＰＯ管理中央サーバー２２００は、顧客情報、旅程、価格その他の制限を、必要があれば新しい顧客に対して、顧客データベース２６００及びＣＰＯデータベース２９００を埋めるように要求されている顧客２１１０から受信する。ＣＰＯの記録はＣＰＯデータベース２９００に、ステップ３６１２で受信した情報と「係属中」に設定されたステイタスフィールドと共に、好ましくは形成される。
【０２２７】
適当な法律文言がステップ３６１６で好ましくは表示又は顧客２１１０に読み上げられ、ＣＰＯ管理システム２１００は拘束力のある条件付購入申込（ＣＰＯ）を形成するために顧客２１１０からの承認を待つ。ステップ３６２０で、価格がＣＰＯデータベース２９００のフィールド２９８０から抽出され、クレジットカード番号を含む適当な顧客情報が顧客データベース２６００から抽出される。その後、適当な請求書記述子（好ましくは顧客２１１０が特定する価格に等しい）全購入額及びクレジットカード情報と共に、ＣＰＯ管理システム２１００に関連付けられた商人ＩＤが事前許可のためにステップ３６２４でクレジットカード発行者に送信される。
【０２２８】
許可コードがクレジットカード発行者から受信されたかどうかを決定するテストがその後ステップ３６２８で好ましくは実行される。ステップ３６２８で、クレジットカード発行者が購入額を許可しなかった旨が決定されれば、別のクレジットカードがステップ３６３２で顧客２１１０から好ましくは要求され、上述した方法で処理を継続するためにプログラム制御はステップ３６２４に帰還する。
【０２２９】
しかし、ステップ３６２８でクレジットカード発行者が購入額を許可した旨が決定されると、ＣＰＯはステップ３６３６で処理のために承諾されてプログラム制御はステップ３６４０に続く（図３６ｂ）。ＣＰＯ管理処理３６００は、各航空会社に対して、ステップ３６４０で、図３７に関連して後述する評価処理３７００を好ましくは実行する。ステップ３６１２で形成されたＣＰＯ記録は、航空会社が所与のＣＰＯに対する応答を生成するために、航空会社２１２０等ある航空会社のＣＰＯ規程に比較されるために評価処理３７００に移行される。上述したように、航空会社のＣＰＯに対する応答は、ＣＰＯの承諾又は拒否若しくは代案発行とされうる。以下に更に説明するように、評価処理３７００は、ＣＰＯが航空会社が承諾するか代案発行するならば、飛行便番号と共に、ＣＰＯへの航空会社の応答を返還するだろう。
【０２３０】
代替的な実施例においては、評価処理３７００は、一の航空会社がＣＰＯを承諾するまで所定順番で各航空会社に対して実行することができる。例えば、評価処理３７００は、（ｉ）各航空会社がＣＰＯ顧客への販売に供する在庫量、（ｉｉ）航空会社データベース３７００に記録されているような各航空会社のＣＰＯの承諾率、（ｉｉｉ）あるルートに対する航空会社の優先権等の各航空会社によって交渉される優先権又は（ｉｖ）ＣＰＯ管理システム２１００に航空会社が支払う最高委任費用に基づいて順番に実行することができる。このようにして、順番は、航空会社による参加をインセントする要因、及び／又は、ＣＰＯ管理システム２１００への収入を最適化する要因によって決定されることができる。好ましい実施例においては、顧客２１１０は、航空会社が承諾を了解するであろう最低価格、又は、どのような順番基準をＣＰＯ管理システム２１００がそのＣＰＯ処理に利用するかに拘らず、ＣＰＯが航空会社が承諾すれば顧客が定義した価格を支払うことに留意する必要がある。
【０２３１】
図３６ｂに示すように、ＣＰＯを少なくとも一の航空会社が承諾したかどうかを決定するテストがステップ３６４４で好ましくは実行される。ステップ３６４４でＣＰＯが少なくとも一の航空会社によって承諾されたことが決定されると、ＣＰＯを一以上の航空会社が承諾したかどうかを決定する更なるテストがステップ３６４８で好ましくは実行される。ステップ３６４８でＣＰＯが一以上の航空会社が承諾しなかったことが決定されるとプログラム制御はチケットを予約するためにステップ３６７２（図３６ｃ）に移行する。
【０２３２】
しかし、ＣＰＯを一以上の航空会社が承諾したことがステップ３６４８によって決定されると、利用する航空会社の承諾を決定するタイブレーカーアルゴリズムがステップ３６５２で好ましくは実行される。例えば、タイブレーカーアルゴリズムは、顧客２１１０の利便を最大にする旅程を提供する航空会社、ＣＰＯ管理システム２１００への利益を最大にする航空会社、又は、ＣＰＯ管理システム２１００が販売に供する在庫を最適化する航空会社を選択することができる。代替的な実施例においては、一の航空会社がＣＰＯを承諾するまで評価処理３７００が各航空会社毎に所定順番で実行されるとタイブレーカーアルゴリズムは不要となることに留意する必要がある。更なる代替的な実施例においては、顧客２１１０は利用する航空会社の承諾を自分で選択することができる。その後、プログラム制御はチケットを予約するためにステップ３６７２（図３６ｃ）に進む。
【０２３３】
チケットを予約するために、乗客名記録（ＰＮＲ）を形成するのに必要な情報は、顧客データベース２６００、ＣＰＯデータベース２９００及び評価処理３７００又はＣＲＳ２４００から受信された在庫及びフライト情報から抽出される。上述したように、ＰＮＲは一般に次のパラメータ、即ち、記録番号、乗客名、チケットの住所、クレジットカード番号などの請求書情報、全セグメントに対する飛行便番号、運輸業者、座席指定、在庫クラス、飛行機の種類、割引料金に対する航空会社が発行した許可コードその他の追加コメントを有している。
【０２３４】
その後、ステップ３６７４で、ＰＮＲは予約設定のため、チケットが予約される航空会社の航空会社予約システム２１５０又はＣＲＳ２４００に送信される。ＣＰＯ管理処理３６００は、その後、ステップ３６７８で、適当な請求書記述子、（顧客２１１０が特定した価格に好ましくは等しい）全購入金額及びクレジットカード情報と共に商人ＩＤをクレジットカード発行者に支払いのために送信する。
【０２３５】
ＣＰＯデータベース２９００のＣＰＯの記録は割り当てられたＰＮＲ番号によりステップ３６８２で更新され、ステイタスフィールドは「承諾」に変更される。最後に、図３８に関連して後述する会計処理３８００は、ＣＰＯ管理システム２１００が処理する各ＣＰＯ毎に会計形跡を保存するために、ＣＰＯ管理処理３６００によって各航空会社毎に実行される。上述したように、会計処理３８００は、少なくとも一の航空会社が承諾した各ＣＰＯに対してチケットが現実にＣＰＯ管理システム２１００によって予約されたことを設定するのに利用することができる機密保持航空会社会計データベース３２００に入力形成される。
【０２３６】
しかし、ステップ３６４４（図３６ｂ）でＣＰＯを少なくとも一の航空会社が承諾しなかったことを決定すると、少なくとも一の航空会社がそのＣＰＯに代案提供したかどうかを決定する更なるテストがステップ３６５６で実行される。ステップ３６５６で少なくとも一の航空会社がそのＣＰＯに代案提供したことが決定されると、ステップ３６６０で、最初のＣＰＯのステイタスは「代案発行」に変更されて、その代案の記録が、例えば、「−ＣＯ」の拡張子の付いた原ＣＰＯ番号を利用してＣＰＯデータベース２９００に好ましくは形成される。その後、代案は、ステップ３６６４で顧客２１１０に送信される。代替的な実施例においては、一以上の代案を受信する代わりに、ＣＰＯが所定許容範囲内にあれば顧客２１１０はそのＣＰＯを後日再提出するように命令されることができ、又は、ＣＰＯ管理システム２１００はそのＣＰＯが承諾されるか満了するまで、定期的にそのＣＰＯを再実行することができる。ＣＰＯ規程の動的性質のために、最初に拒否されたＣＰＯは一以上の航空会社により後日承諾されることができる。
【０２３７】
その後、ステップ３６６８で、顧客２１１０が代案の一つを承諾したかどうかを決定する更なるテストが好ましくは実行される。ステップ３６６８で顧客２１１０が代案を承諾したことが決定されると、上述した方法でそのチケットを予約するためにプログラム制御はステップ３６７２（図３６ｃ）に進む。しかし、ステップ３６６８で顧客２１１０が代案を承諾しなかったことが決定されると、プログラム制御はステップ３６９６（図３６ｃ）に進み、ＣＰＯ管理処理３６００はその代案の顧客による拒否を、その代案を作成した航空会社に送信する。その後、ステップ３６９８で、ＣＰＯ管理処理３６００は、ＣＰＯデータベース２９００のＣＰＯに関連付けられた代案のステイタスを「拒否」に更新する。プログラム制御はステップ３６８６に上述した方法で進み、ステップ３６９９で終了する。
【０２３８】
しかし、ステップ３６５６（図３６ｂ）でいずれの航空会社もそのＣＰＯに代案提供しなかったことが決定されると、プログラム制御はステップ３６９０（図３６ｃ）に進み、ＣＰＯ管理処理３６００は、そのＣＰＯの拒否を顧客２１１０に送信する。その後、ＣＰＯデータベース２９００のＣＰＯのステイタスはステップ３６９４で「拒否」に更新される。プログラム制御は上述の方法でステップ３６８６に進み、その後ステップ３６９９で終了する。
【０２３９】
上述したように、ＣＰＯ管理処理３６００は評価処理３７００をステップ３６４０で実行する。例示的評価処理３７００を図３７ａ及び図３７ｂに示す。ある実施例においては、評価処理３７００は各航空会社毎に好ましくはカスタマイズされ、その結果、各評価処理３７００はＣＰＯの記録を航空会社２１２０等の関連航空会社の規程に比較するために標準形式でＣＰＯ管理処理３６００から受信し、そのＣＰＯに対する航空会社の承諾、拒否又は代案作成などの標準応答を返却する。また、航空会社の応答がそのＣＰＯを承諾か代案作成であれば、評価処理３７００は選択された飛行便番号を好ましくは返却する。
【０２４０】
図３７ａに示すように、評価処理３７００はまずＯ＆Ｄペアをステップ３７０５でＣＰＯ記録から抽出し、その後、ステップ３７１０で抽出されたＯ＆Ｄペアに関連する機密保持航空会社規程データベース３０００の全ＣＰＯ規程を識別する。ＣＰＯ記録のフィールド２９６０乃至２９９５からの顧客定義制限は、機密保持航空会社規程データベース３０００のフィールド３０１６乃至３０４４からの対応航空会社定義制限に、ステップ３７１５で、上述したステップで識別される各ＣＰＯ規程毎に、その後比較される。
【０２４１】
その後、ＣＰＯが少なくとも一の航空会社規程を満足しているかどうかを決定するテストがステップ３７２０で行われる。例えば、ＣＰＯデータベース２９００の記録２９１０に格納されているＣＰＯ番号２３４５２（図２９ａ及び図２９ｂ）は、ニューヨーク（ＪＦＫ）からシカゴ（ＯＲＤ）までのＯ＆Ｄペアを定義している。従って、評価処理３７００は、機密保持航空会社規程データベース３０００にアクセスし、このＯ＆Ｄペアに対する全ＣＰＯ規程を識別する。図３０ａに示す例示的機密保持航空会社規程データベース３０００において、ＣＰＯ規程番号２３４５２はこのＯ＆Ｄペアに関連する唯一の規程であると識別されている。その後、ＣＰＯ番号２３４５２のフィールド２９６０乃至２９９５からの顧客が定義した制限の各々はＣＰＯ規程番号２３４５２のフィールド３０１６乃至３０４４からの対応する航空会社が定義した制限に比較される。顧客は、一経由を了解しているので（フィールド２９６０）、クリーブランド又はピッツバーグを経由するルートの航空会社の要件（フィールド３０１６）は満足される。また、顧客の出発と帰りの日付の要件（フィールド２９６５及び２９７０）は旅行の出発及び帰りの両方の行程（フィールド３０２０乃至３０３２）に対するその航空会社の日時と曜日の要件を満足している。また、旅行乗客数は、フィールド３０３４の航空会社の要件を満足しており、顧客の価格（フィールド２９８０）は航空会社が定義した最低価格（フィールド３０４０）を超えている。従って、ＣＰＯ番号２３４５２は、Ｑ又はＫ在庫が入手可能であり（フィールド３０４２）、そのＣＰＯがフライト前７乃至２１日前に処理されれば（フィールド３０４４）、ＣＰＯ規程番号４５６８７に関連付けられた航空会社によって承諾される。
【０２４２】
ある実施例においては、ＣＰＯ管理システム２１００により、航空会社２１２０、２１３０は、ＣＰＯ管理システム２１００が、ＣＰＯ規程が述べているようにその航空会社の要件に適合すると共にＣＰＯそれ自身において述べられているようにその顧客２１１０の要件に適合する入手可能な在庫を発見することを条件に、所与のＣＰＯを承諾する形式でＣＰＯ規程を特定することができる。例えば、図３０ａに示すＣＰＯ規程番号２３４５２は、Ｑ又はＫ在庫が入手可能であるという条件付けがなされている。
【０２４３】
従って、ステップ３７２０でＣＰＯが少なくとも一の航空会社規程を満足していると決定されれば、満足された規程は在庫入手可能であるという条件付けがなされているかどうかを決定する更なるテストがステップ３７２５で好ましくは実行される。
【０２４４】
ステップ３７２５で満足された規程のいずれもが在庫入手可能であるという条件付けがなされていないと決定されれば、プログラム制御は後述するステップ３７３５に直接に移行する。しかし、一以上の満足された規程が在庫入手可能であるという条件付けがなされていることがステップ３７２５で決定されれば、入手可能な座席を有して満足されたＣＰＯ規程とそのＣＰＯの両方の適当な制限を満足するフライトがあればそれを識別するためにＣＲＳ又はＡＲＳはステップ３７３０でアクセスされる。
【０２４５】
その後、ＣＰＯを満足する一以上のフライトが識別されたかどうかを決定するテストがステップ３７３５で実行される。ステップ３７３５で唯一の満足のいくフライトが識別されれば、プログラム制御は後述するステップ３７４５に直接進行する（図３７ｂ）。
【０２４６】
しかし、ステップ３７３５で一以上の満足の行くフライトが識別されたことが決定されると、ＣＰＯで述べられた顧客の嗜好に最も近く適合又は顧客の利便を最大にする一のフライトがステップ３７４０で選択される（図３７ｂ）。代替的に、各航空会社２１２０は、単一のフライトを選択するのに利用されるＣＰＯ管理システム２１００用の独自の基準を定義することができる。その後、応答はステップ３７４５で「承諾」に設定され、ステップ３７７０で、プログラム制御は定義された応答と選択された飛行便番号と共にＣＰＯ管理処理３６００に戻る。
【０２４７】
しかし、ステップ３７２０（図３７ａ）でＣＰＯが少なくとも一の航空会社規程を満足しないと決定されると、プログラム制御はステップ３７５０（図３７ｂ）に進み、そのＣＰＯが代案を生成するために航空会社が特定した許容範囲内にあるかどうかを決定する更なるテストが行われる。上述したように、代案規程データベース３１００は、ＣＰＯ管理システム２１００が、もしＣＰＯが所与のＣＰＯ規程に関連付けられた一以上の制限の所定許容範囲内にあれば、航空会社の代わりにＣＰＯに対する代案を生成するのに利用される一連の許容度を保存するために各機密保持航空会社サーバー２３００によって好ましくは格納されている。
【０２４８】
従って、ステップ３７５０でそのＣＰＯが代案生成用に航空会社が特定した許容範囲内にあると決定されると、代案規程データベース３１００から検索されるように、適当な修正条件を有する代案がステップ３７６０で生成される。その後、応答は、「代案発行」にステップ３７６５で設定され、ステップ３７７０で、プログラム制御は定義された応答と選択された飛行便番号と共に、ＣＰＯ管理処理３６００に帰還する。
【０２４９】
しかし、そのＣＰＯが代案形成用に航空会社が特定した許容範囲内にないとステップ３７５０で決定されれば、応答はステップ３７５５で「拒否」に設定され、ステップ３７７０で、プログラム制御は、無効に等しい選択された飛行便番号と定義された応答と共に、ＣＰＯ管理処理３６００に戻る。
【０２５０】
上述したように、ＣＰＯ管理処理３６００は、ＣＰＯ管理システム２１００が処理する各ＣＰＯ毎に会計形跡を保存するために各航空会社毎に会計処理３８００をステップ３６８６で好ましくは実行する。例示的会計処理３８００を図３８に示す。会計処理３８００は、ＣＰＯ管理システム２１００が、少なくとも一の航空会社が承諾した各ＣＰＯ毎にチケットがＣＰＯ管理システム２１００によって現実に予約されたことを設定するのに利用する入力を機密保持航空会計データベース３２００に好ましくは形成する。このようにして、航空会社２１２０は、ＣＰＯ管理システム２１００を航空会社２１２０の基底価格弾力性を入手するのに利用している顧客２１１０、他の航空会社２１３０又は第三者の危険が最小であることを確信することができる。
【０２５１】
図３８に示すように、会計処理３８００は必要があればステップ３８１０で、機密保持航空会社規程データベースの在庫をまず減分する。例えば、在庫入手可能という条件が付されたＣＰＯ規程と反対に、チケットが関連航空会社によって最終的に予約されてそのＣＰＯを承諾するのに使用されたＣＰＯ規程が現実に航空会社がＣＰＯ顧客へ販売用に解放した在庫を含んでいたときにのみ在庫は減分されなければならない。
【０２５２】
その後、会計処理３８００は、ステップ３８１５で、ＣＰＯ番号と、ＣＰＯ管理システム２１００が顧客２１１０に発行したチケットに関連付けられたＰＮＲと、チケットを対応航空会社が予約したかどうかの表示とを含むＣＰＯの記録を機密保持航空会計データベース３２００に好ましくは形成する。プログラム制御はその後ＣＰＯ管理処理にステップ３８２０で帰還する。
【０２５３】
図３９に示す例示的ＣＰＯ規程生成処理３９００は、フライトが最初にフライトスケジュールに加えられると最初にその後定期的にＲＭＳ２５００によって好ましくは実行され、需要と外部事件に応答して入手可能在庫を再割当及び価格付けする。従って、ＲＭＳ２５００による現在の在庫割当が割当られているフライトに対する最初の割当であるかどうかを決定するテストがステップ３９０５でまず実行される。現在の在庫割当が割当られているフライトに対する最初の割当であるとステップ３９０５で決定されると、従来の方法を利用してフライトが空席を有して出発しそうであるということが予測されているかどうかを決定する更なるテストがステップ３９１０で実行される。
【０２５４】
フライトが空席を有して出発する見込みはなさそうであるということがステップ３９１０で決定されると、プログラム制御はステップ３９８５で終了する。しかし、フライトが空席を有して出発しそうであるということがステップ３９１０で決定されると、ＣＰＯ規程生成処理３９００は、ステップ３９１５でその空席をＣＰＯ顧客用特別料金クラスに好ましくは割り当てる。その後、かかるチケットに対する適当な最低料金その他の制限がステップ３９２０で設定される。
【０２５５】
フライトに対する価格付け・制限データベース３３００、座席割当データベース３４００及び予測・需要分析データベース３５００は、ステップ３９２５で、新しく設定された料金クラス、割り当てられた在庫及び最初の額と共に、更新される。その後、ＣＰＯ規程生成処理３９００は、割り当てられた在庫、設定最低価格その他の制限を含むＣＰＯ規程をステップ３９３０で好ましくは生成し、その生成されたＣＰＯ規程を関連機密保持航空会社サーバー２３００にステップ３９３５で送信する。プログラム制御はその後ステップ３９８５で終了する。
【０２５６】
しかし、現在の在庫割当が割り当てられているフライトに対する最初の割当ではないとステップ３９０５で決定されると、予期しない超過在庫デルタ２５８０を最小にするために所与のフライトの一以上の料金クラスに対する以前の割当を再割当するためにプログラム制御は３９５０に進む。従って、いかなる料金クラス対しても所定許容度以上に予測需要が現実の需要を超えているかどうかを決定するテストがステップ３９５０で実行される。ある実施例においては、ＲＭＳは、予測・需要分析データベース３５００のフィールド３５６０及び３５６５に記録されている要約情報を利用してこの決定をすることができる。また、ＲＭＳ２５００は、以前の期間に対する予測・需要分析データベース３５００に格納されている過去の需要情報を分析することによって、ステップ３９５０で利用される所定許容度を生成することができる。
【０２５７】
予測需要がいかなる料金クラスに対しても所定許容度以上に現実の需要を超えていないことがステップ３９５０で決定されると、現存の割当を再割当する必要はなく、プログラム制御はステップ３９８５で終了する。現実の需要が予測需要を超えていなければＲＭＳ２５００はＣＰＯ顧客へ販売用に以前に割り当てられた在庫を除去することができることに留意する必要がある。
【０２５８】
しかし、予測需要がいかなる料金クラスに対しても所定許容度以上に現実の需要を超えていることがステップ３９５０で決定されると、ＲＭＳ２５００は、ステップ３９５５で、ＣＰＯ顧客販売用に超過容量又はその一部を好ましくは割り当てる。
【０２５９】
そのフライトに対する価格付け・制限データベース３０００、座席割当データベース３４００及び予測・需要分析データベース３５００は、ステップ３９６５で再割当された在庫と設定価格で更新される。その後、ＣＰＯ規程生成処理３９００は、割当られた在庫、設定最低価格その他の制限を含むＣＰＯ規程をステップ３９７０で生成し、その生成されたＣＰＯ規程を関連機密保持航空会社サーバー２３００にステップ３９８０で送信する。プログラム制御はその後ステップ３９８５で終了する。
【０２６０】
クルーズの実施例
ＣＰＯ管理システム２１００は航空券販売システムとして主としてここで例示されてきたが、ＣＰＯ管理システム２１００は、当業者には明らかになるであろうように、クルーズチケットを販売するのに同様に利用されることができる。かかる実施例においては、各機密保持航空会社サーバー２３００は、航空会社と逆に、一以上のクルーズオペレータに関連付けられ、各機密保持サーバー２３００は、航空会社の実施例で上述した機密保持サーバー２３００と同様の方法で、関連クルーズオペレータが定義したＣＰＯ規程を他のものに加えて格納する。
【０２６１】
また、収入管理システム２５００と航空会社予約システム２１５０は、それぞれ、各クルーズオペレータの収入管理システムと予約システムとして具体化されるであろう。クルーズ収入管理システムは、価格付け及び在庫情報を設定してＣＰＯ規程を、航空会社の実施例で上述した収入管理システムと同様な方法で、生成する。同様に、クルーズ予約システムは旅程質問を実行し、航空会社の実施例で上述した予約システムと同様の方法で、それぞれのクルーズオペレータと共に予約を作成する。
【０２６２】
従って、ＣＰＯ管理システム２１００はＣＰＯを潜在的なクルーズ旅行者から受け取り、そのＣＰＯを複数のクルーズオペレータの各々が提供する一連のＣＰＯ規程に対して評価する。クルーズ実施例用の例示的ＣＰＯデータベース４０００を図４０ａ及び図４０ｂに示す。ＣＰＯデータベース４０００は、ＣＰＯの条件と関連ステイタスを含む、ＣＰＯ管理システム２１００が処理する各ＣＰＯの記録を好ましくは格納している。ＣＰＯデータベース４０００は、システム２１００が処理する異なるＣＰＯに各々関連付けられている記録４００５及び４０１０等の複数の記録を保存している。フィールド４０２０のＣＰＯ番号によって識別される各ＣＰＯ毎に、ＣＰＯデータベース４０００はＣＰＯが受信された日付をフィールド４０２５に、ＣＰＯに関連付けられた旅行案内業者用の識別（ＩＤ）番号があればそれをフィールド４０３０に含んでいる。フィールド４０３０に格納されている旅行案内業者ＩＤ番号は、例えば、以前のチケット購入と旅行案内業者に関連付けられたＣＰＯの過去のデータベース（図示せず）にインデックスを付すのに利用されることができることに留意する必要がある。
【０２６３】
また、ＣＰＯデータベース４０００は、フィールド４０３５の名前と、フィールド４０４０の識別番号によって顧客を識別する。同伴乗客はフィールド４０４５で識別される。フィールド４０４０に格納されているＩＤ番号は、顧客データベース２６００の顧客に対して格納された対応情報を相互参照するのに好ましくは利用される。
【０２６４】
顧客旅程その他の関連制限のパラメータはＣＰＯデータベースのフィールド４０５０乃至４０８５に格納される。特に、出発及び目的港はフィールド４０５０及び４０５５でそれぞれ識別され、顧客が特定したいかなる港制限もフィールド４０６０に記録される。出発及び帰りの日付はそれぞれフィールド４０６５及び４０７０に格納されている。
【０２６５】
ＣＰＯデータベース４０００は、同伴旅行乗客数合計表示をフィールド４０７５に好ましくは格納しており、顧客がチケット１枚当たりに支払うことを了解する価格をフィールド４０８０に述べている。好ましいクルーズオペレータ、寝台、客室指定又は食事時間等の顧客が特定したその他の雑多な制限はフィールド４０８５に記録される。フィールド４０９０は、「継続中」、「承諾」、「拒否」又は「満了」等の現在のそれぞれのＣＰＯステイタスを記録している。
【０２６６】
それぞれの機密保持サーバー２３００に関連付けられている一以上のクルーズオペレータに対してＣＰＯ規程を保存するクルーズの実施例に対する例示的機密保持規程データベース４１００を図４１に示す。機密保持規程データベース４１００は、ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、暗号形式で格納されることができる。機密保持規程データベース４１００は、異なるＣＰＯ規程に各々関連付けられている記録４１０２及び４１０４等の複数の記録を保存している。フィールド４１１０の規程番号によって識別される各ＣＰＯ規程毎に、機密保持規程データベース４１００は、それぞれのクルーズオペレータが定義した関連制限をフィールド４１１２乃至４１４４に含んでいる。
【０２６７】
本発明の特徴によれば、ＣＰＯ管理システム２１００が処理するＣＰＯ規程は様々な複雑性を有することができる。例示的機密保持規程データベース４１００に述べられている特定の制限は本発明の原理の典型に過ぎない。クルーズオペレータ、航空会社その他の販売者は、当業者にとって明らかになるであろうように、かかる制限のサブセットを結合し、及び／又は、付加的制限を結合することができる。
【０２６８】
例示目的のため、図４１に示す機密保持規程データベース４１００により、クルーズオペレータは、フィールド４１１２乃至４１４４の次の制限、即ち、出発港、（包含又は除外）クルーズ番号、出発の日時、出発の曜日、帰りの日時、帰りの曜日、旅行乗客数、旅行距離、客室当たりの売上、チケット当たりの最低価格、在庫制限又は客室入手可能性及び事前購入要求の幾つか又は全てを特定することによって、ＣＰＯ規程を形成することができる。
【０２６９】
例えば図４１に示す記録４１０２は、（ｉ）顧客が火曜日乃至木曜日に出発して帰るクルーズで旅行し、（ｉｉ）チケットが出発の２ヶ月以内に予約され、（ｉｉｉ）売上が客室毎１マイル当り少なくとも１．２０ドルで価格は少なくとも一人当り５２９ドルであり、（ｉｖ）高級クラスの旅行でなく、及び、（ｖ）最低２人の同伴旅行乗客がいる場合には、そのクルーズオペレータは１９９７年１０月中のセント・トーマスからの旅行に対するいかなるＣＰＯをも承諾することを特定する所与のクルーズオペレータのＣＰＯ規程に関連付けられている。
【０２７０】
多重拘束用後販売
上述したように、ＣＰＯを一以上の航空会社又はクルーズオペレータが承諾すれば、いずれの航空会社の承諾を利用するかを決定するタイブレーカーアルゴリズムがＣＰＯ管理処理３６００によってステップ３６５２で好ましくは実行される。例えば、タイブレーカーアルゴリズムは、顧客２１１０の利便を最大にする旅程、ＣＰＯ管理システム２１００に対する利益を最大にする旅程、ＣＰＯ管理システム２１００が販売に供する在庫を最適化する旅程を提供する売主を選択することができるし、顧客２１１０に対して自分でどの航空会社又はクルーズオペレータの承諾を利用するかを選択させることもできる。代替的な実施例においては、ＣＰＯを一以上のクルーズオペレータが承諾すれば、ＣＰＯ管理システム２１００は、各々の承諾している売主が顧客にその製品を直接売り込んで事後販売することを可能にする図４２に示す後販売多重拘束処理４２００を実行する。従って、顧客２１１０は、各売主が提供する資料や奨励策に基づいて、どのクルーズオペレータの承諾を利用するかを依然として自分で決定する。顧客２１１０は、ＣＰＯの条件に従って、依然としてＣＰＯ管理システム２１００によって拘束されている。換言すれば、顧客２１１０は、ＣＰＯが特定する商品又は役務を購入する義務を有するが、買主はどのクルーズオペレータを利用するかを、各承諾しているクルーズオペレータが直接に顧客２１１０に提供する資料に基づいて、決定しなければならない。
【０２７１】
例えば、顧客２１１０は、１９９８年３月の月間に、バージン諸島のどこでも、遅い時間の食事付きＡ級客室で、８００ドルでクルーズ用ＣＰＯを提出することができる。そのＣＰＯは複数のクルーズオペレータに与えられる。３つのクルーズオペレータがそのＣＰＯを承諾する。ＣＰＯ管理システム２１００は、その後、そのＣＰＯ制限に従って、その申込によって識別されたクレジットカード口座にその顧客２１１０を拘束する。ＣＰＯ管理システム２１００は、その後、その顧客２１１０と承諾している売主との間に通信チャネルを与えるか、その製品を魅力的な方法で売りこみたいと思っている各承諾をしている売主に顧客連絡情報を与える。顧客２１１０は、その後、承諾している三人の売主の中から一人を選択する。従って、各クルーズオペレータは、そのＣＰＯが特定する価格でクルーズを販売するのに３つに１つのチャンスがあることを知っている。クルーズオペレータは、各クルーズ旅行者に関連づけられた高限界収益に関しては特に、かかる保証された購入者に積極的に売り込むであろうことが予想される。
【０２７２】
ＣＰＯ管理システム２１００が与える顧客２１１０と各承諾している売主との間の通信チャネルは、各承諾している売主が売り込もうとしているクルーズに関する詳細情報を顧客２１１０に提供することができる対話型ウェブサイトその他の電子機構であることができる。例えば、対話型ウェブサイトは、そのクルーズが訪問する様々な港と利用可能な活動と共に、現実のクルーズ船と客室などのクルーズパッケージの異なる面の仮想表現を含むかもしれない。このようにして、買主は既知の技術を使用してクルーズの仮想表現を開拓することができる。
【０２７３】
図４２は、その製品を事後販売する目的で各売主が顧客２１１０に直接売り込むことを可能にするために、図２２のＣＰＯ管理中央サーバーが実施可能な例示的後販売多重拘束処理４２００を示している。後販売多重拘束処理４２００は、ステップ３６５２で、タイブレーカーアルゴリズムに代わって、どのクルーズオペレータの承諾を利用するかを決定するために、ＣＰＯ管理処理３６００によって好ましくは実行される。図４２に示すように、後販売多重拘束処理４２００は、承諾しているクルーズオペレータその他の売主に対して、指定された顧客２１１０に後販売情報の提供を命令することよって、ステップ４２１０で開始する。ＣＰＯ管理システム２１００は、その後ステップ４２２０で、承諾しているオペレータから後販売情報を好ましくは受信し、受信情報を顧客２１１０にステップ４２３０で送信又はその他の方法で入手可能にする。最後に、後販売多重拘束処理４２００は、プログラム制御がＣＰＯ管理処理３６００に帰還する前に、ステップ４２５０で、どのオペレータを利用するかに関する顧客２１１０の決定を受信する。
【０２７４】
代替的な実施例においては、ＣＰＯは一以上のクルーズオペレータが承諾するならば、ＣＰＯ管理システム２１００はそのＣＰＯを承諾している売主の各々を拘束することができる。原買主は、タイブレーカーアルゴリズム又はここで開示された代替的な後販売多重拘束処理４２００に従って、売主の一人に割り当てられることができる。このようにして、ＣＰＯ管理システム２１００は、その後、最初に承諾されたＣＰＯに関連付けられた価格と同額以上で他の買主に超過在庫を再販売することができる。
【０２７５】
除外された売主のＣＰＯ評価
上述したように、顧客２１１０が提出したＣＰＯは一以上の好ましい航空会社、クルーズオペレータ、適用可能であれば、その他の売主を特定することができる。従って、ＣＰＯ管理システム２１００は、一以上の売主がそのＣＰＯの承諾を了解するかどうかを決定するためにＣＰＯを特定された売主の各々に与える。補助的な実施例においては、ＣＰＯ管理システム２１００は、特定された売主の一人がそのＣＰＯを承諾する前に顧客２１１０に代案を作成可能な除外された売主にそのＣＰＯを与える図４４ａ及び図４４ｂに関連して後述する除外売主ＣＰＯ評価処理４４００を好ましくは実行する。除外された売主は、ビジネスを得る目的で顧客２１１０が特定したＣＰＯの原条件よりも好ましい代案を作成することができる。このようにして、ＣＰＯ管理システム２１００は、ＣＰＯ情報を受信する権利を除外された売主に販売したり、顧客２１１０が承諾する代案に対してより大きな割合の委託料を徴収することができる。
【０２７６】
例えば、クルーズ業界では、初めてのクルーザーは特定ブランドロイヤルティを開発しようとする。従って、将来のクルーズを考慮した時、かかる顧客２１１０はＣＰＯを非常に限定された数のクルーズオペレータに提出するかもしれない。ＣＰＯ管理システム２１１０は、ＣＰＯの条件に従って、ＣＰＯを特定のクルーズオペレータに提出し、またＣＰＯを一以上の除外されたクルーズオペレータに提出する。ＣＰＯ管理システム２１００は、そのＣＰＯを顧客が特定したオペレータの一人が承諾する前に除外されたオペレータから受信したいかなる代案をも保持するのに図４３で示す除外オペレータ代案データベース４３００を好ましくは利用する。
【０２７７】
クルーズ実施例用の例示的除外オペレータ代案データベース４３００を図４３に示す。除外オペレータ代案データベース４３００は、除外されたオペレータから受信した異なる代案に関連付けられている記録４３０５乃至４３１５等の複数の記録を保存する。フィールド４３２５の番号によって識別される各代案毎に、除外オペレータ代案データベース４３００は、対応するＣＰＯ番号、顧客識別子、除外されたオペレータ、代案の条件及び関連ステイタスをフィールド４３３０乃至４３５０にそれぞれ有している。例えば、顧客のＣＰＯが、申込はホーランド・アメリカライン（Ｈｏｌｌａｎｄ  ＡｍｅｒｉｃａＬｉｎｅ）又はシーボーン・クルーズ・ラインズ（Ｓｅａｂｏｒｎ  Ｃｒｕｉｓｅ  Ｌｉｎｅｓ）に提出されるべきことを当初特定していたならば、ＣＰＯ管理システム２１００は、最初にその申込をカーニバル・プリンセス・アンド・ロイヤル・カリビアン・クルーズ・ラインズ（Ｃａｒｎｉｖａｌ，  Ｐｒｉｎｃｅｓｓ  ａｎｄ  Ｒｏｙａｌ  Ｃａｒｉｂｂｅａｎ  Ｃｒｕｉｓｅ  Ｌｉｎｅｓ）に提出することができる。図４３に示すように、除外されたオペレータの各々は、６００ドル、６００ドル及び５７５ドルの代案をそれぞれ提出している。顧客のＣＰＯが元々特定したオペレータのいずれもが未だ承諾をしていなければ、顧客２１１０は、代案の一つを承諾するかどうかの選択肢を与えられる。顧客２１１０が代案を承諾すれば、顧客２１１０はその代案の条件に拘束されて原ＣＰＯは取り消される。
【０２７８】
図４４ａ及び図４４ｂは、例示的な除外売主ＣＰＯ評価処理４４００を説明している。この処理４４００は、原申込条件が除外している売主にＣＰＯ情報を与える図２２のＣＰＯ管理中央サーバーによって実行されることができる。それらの除外された売主は、その後、ＣＰＯの条件が特定した売主の一人がそのＣＰＯを承諾する前に、ビジネスを獲得しようとすることができる。後述するように、除外売主ＣＰＯ評価処理４４００はＣＰＯ管理処理３６００に関連して好ましくは実行される。図４４ａに示すように、除外売主ＣＰＯ評価処理４４００は、顧客２１１０からＣＰＯを受信してそのＣＰＯをＣＰＯデータベース２９００又は４０００に格納すると、ステップ４４０５で開始する。その後、そのＣＰＯは、顧客２１１０が特定したオペレータを検索するために、ステップ４４１０で評価される。オペレータデータベースは、ＣＰＯ情報が与えられることができる潜在的なオペレータを識別するために、ステップ４４１５で評価される。
【０２７９】
ＣＰＯの条件から除外されたオペレータが一以上存在するかどうかを決定するテストがステップ４４２０でその後実行される。顧客のＣＰＯからオペレータが除外されていないことがステップ４４２０で決定されれば、ＣＰＯ管理処理３６００は上述したように動作を継続する。しかし、顧客のＣＰＯから一以上のオペレータが除外されていることがステップ４４２０で決定されれば、ＣＰＯ情報は、ステップ４４３０で、特定及び除外されたオペレータの各々に好ましくは送信される。ＣＰＯは、特定されたオペレータの前又は同時に、除外されたオペレータに与えられることができることに留意する必要がある。
【０２８０】
その後、いかなる代案も除外されたオペレータからステップ４４３５で受信されて除外オペレータ代案データベース４３００にステップ４４４０で格納される。受信された代案の各々は、その後、顧客２１１０にステップ４４４５で提出される。特定されたオペレータのいずれかが原ＣＰＯを承諾する前に顧客２１１０が代案のいずれかを承諾するかどうかを決定するテストがその後ステップ４４５０で実行される。特定されたオペレータのいずれかが原ＣＰＯを承諾する前に顧客２１１０がその代案のいずれかを承諾しないことがステップ４４５０で決定されると、ＣＰＯ管理処理３６００は上述したように動作を継続する。
【０２８１】
しかし、特定されたオペレータのいずれかが原ＣＰＯを承諾する前に顧客２１１０が代案を承諾したことがステップ４４５０で決定されると、原ＣＰＯは終了して取り消され、ＣＰＯデータベース２９００、４０００の原ＣＰＯのステイタスは「取消」にステップ４４６０で変更される。その後、承諾された代案のステイタスは「承諾」に変更され、拒否された代案があればそのステイタスは除外オペレータ代案データベース４３００においてステップ４４６５で「拒否」に変更される。最後に、プログラム制御はＣＰＯ管理処理３６００に戻り、上述した方法で継続する。
【０２８２】
後販売多重拘束処理４２００及び除外売主ＣＰＯ評価処理４４００はクルーズの実施例でここに例示されてきたが、後販売多重拘束処理４２００及び除外された売主ＣＰＯ評価処理４４００は、当業者に明らかになるであろうように、航空会社その他の旅行関連業界、長距離電話業界、金融業界など他の業界でも同様に適用することができることに留意する必要がある。
【０２８３】
パッケージＣＰＯ管理システム
商品及び役務のパッケージ販売を処理するのに適している本発明の更なる実施例を図４５乃至図５７に関連して以下に説明する。図４５は、コンポーネント（構成要素）商品又は役務のパッケージを得るために買主インターフェース４８００を利用する一以上の買主からＣＰＯを受信処理する条件付購入申込（ＣＰＯ）管理システムを示している。ある実施例においては、パッケージＣＰＯ管理システム４５００は、全パッケージＣＰＯを個別的に売主に提供されるコンポーネントＣＰＯに分解又は解体する。パッケージＣＰＯ管理システム４５００は、売主インターフェース４８０１−４８０６を利用する一以上の売主が所与のパッケージＣＰＯの個別的コンポーネントの各々の承諾を了解するかどうかを決定するために、各パッケージＣＰＯに関連付けられた個別的コンポーネントＣＰＯを処理する。更に以下に説明するように、所与のパッケージＣＰＯの個別的コンポーネントＣＰＯの各々を一以上の売主が承諾すれば、パッケージＣＰＯ管理システム４５００は、承諾している各売主に代わって、買主をパッケージ全体を購入するように拘束する。このようにして、法律的に拘束力のある契約が形成される。
【０２８４】
ここで使用するように、パッケージＣＰＯは、買主定義価格で航空旅行、ホテル及びレンタカー等のコンポーネント商品又は役務若しくはその両方のパッケージを購入するために買主が提出した一以上の条件を含む拘束力のある申込である。例示的な旅行の実施例においては、パッケージＣＰＯに対して買主が定義した条件は、一般に、総価格と、出発及び目的都市、承諾可能な旅行の日時、及び、各個別的コンポーネント毎の希望サービスクラス等の旅程パラメータを含んでいる。また、選択的に、買主は、旅行関連パッケージＣＰＯの航空部分に対して接続便又は経由が買主に承諾可能であるかどうか等のパッケージＣＰＯ全体の一以上の個別的コンポーネントに対するより詳細説明、又は、一以上の個別的コンポーネント商品又は役務に対する好ましいプロバイダーを与えることができる。
【０２８５】
本発明の一の特徴によれば、パッケージＣＰＯ管理システム４５００は、売主に個別的に申込まれたパッケージＣＰＯ全体をコンポーネントＣＰＯに好ましくは解体する。代替的な実施例においては、パッケージＣＰＯ管理システム４５００は、パッケージＣＰＯ全体を各売主に与え、売主はパッケージＣＰＯの各コンポーネントを別個に承諾することができる。パッケージＣＰＯの個別的コンポーネントは同一製品になる場合があることに留意する必要がある。例えば、買主は、特定スポーツイベントに対する６枚の一般入場券の購入申込を提出することができる。パッケージＣＰＯ管理システム４５００は、一の売主にのみ承諾可能な６枚券に対する統合的ＣＰＯとしての購入申込を売主に与えることができる。代替的に、パッケージＣＰＯ管理システム４５００は、６枚券に対するパッケージＣＰＯ全体を、個別的に売主に提供される一以上の券の幾つかのコンポーネントＣＰＯに分解することができる。一の実施例においては、大型商品に対するパッケージＣＰＯ全体は、承諾される見こみが最も高い単位に最適化されているコンポーネントＣＰＯに分解されることができる。上述のチケットの例では、パッケージＣＰＯ管理システム４５００は、ほとんどの売主が券を組販売することを期待していると仮定して６枚券に対する要求を２枚ずつの３つのコンポーネントＣＰＯに分解する。
【０２８６】
一の好ましい実施例においては、パッケージＣＰＯ管理システム４５００は、各コンポーネントＣＰＯ毎に申込価格を計算する前に、申込価格総額からマージンを保全する。保全マージン額はパッケージ全体の全コンポーネントが拘束される見込みに基づいて決定されてもよい。このようにして、マージンは、パッケージＣＰＯの全コンポーネントの拘束に失敗した結果としてパッケージＣＰＯ管理システム４５００が被る危険を緩和している。
【０２８７】
図５６に関連して更に以下に説明するように、パッケージＣＰＯ管理システム４５００は、保全マージン又はその一部を、売主が承諾していない一以上のコンポーネントＣＰＯの申込価格を増額するのに利用することができる。例えば、買主がバケーションパッケージに対する申込を総価格１，０００．００ドル以下で提出するとすれば、パッケージＣＰＯ管理システム４５００は、希望パッケージが当初９００ドルから割当られた申込価格で拘束することができなければ１００ドルの利用マージン、即ち、１０％を保全することができる。しかし、パッケージＣＰＯ管理システム４５００が当初指定した９００ドルでパッケージ全体を拘束することに成功すれば、パッケージＣＰＯ管理システム４５００は１００ドルマージンを利益として保全するか、そのマージンを買主に戻すか、又は、他のパッケージＣＰＯのコンポーネントＣＰＯの拘束を補助する資金の未使用マージンに置くことができる。
【０２８８】
各コンポーネントＣＰＯ毎に申込価格を計算するために、パッケージＣＰＯ管理システム４５００は、まず、パッケージの各個別的コンポーネント商品又は役務の市場価格に基づいてパッケージの総市場価格を好ましくは決定する。パッケージＣＰＯ管理システム４５００は、その後、各コンポーネントＣＰＯの申込価格を、もし適当であれば、そのパッケージの全市場価格に対するそれぞれのコンポーネントＣＰＯの市場価格の比率によってかけられた買主が申込んだパッケージ全体の総価格に基づいて、保全マージンによって調整されるように、計算する。例えば、買主が航空旅行、ホテル宿泊及びレンタカーからなる旅行パッケージに対する申込をパッケージに対する総価格が１，０００．００ドル以下として提出し、各コンポーネント品が４２０ドル、４００ドル、２５０ドルの市場価格を有するとすると、パッケージは１０７０ドルの総市場価格を有する。最初にパッケージＣＰＯ管理システム４５００が最初に１００ドルのマージンを保全すると、９００ドルの調整されたパッケージＣＰＯ価格が個別的コンポーネントＣＰＯに以下のように市場価格に基づいて割り当てられる。即ち、航空券に対して３６０ドル（４０％）、ホテル宿泊に対して３３３ドル（３７％）及び車のレンタルに対して２０７ドル（２３％）となる。
【０２８９】
パッケージＣＰＯ管理システム４５００は、その後、一以上の売主がパッケージＣＰＯ全体の個別的コンポーネントＣＰＯの各々の承諾を了解するかどうかを決定するために、個別的コンポーネントＣＰＯを処理する。もし成功すれば、パッケージＣＰＯ管理システム４５００は、承諾している売主の各々に代わって、パッケージ全体を購入するように買主を拘束する。以下に更に説明するように、売主が各個別的コンポーネントＣＰＯを承諾すると、パッケージＣＰＯ管理システム４５００は、好ましくは、その売主と「事前拘束」合意をする。これによって、パッケージＣＰＯ管理システム４５００が残りのアクティブなコンポーネントＣＰＯの処理を完了できるように、コンポーネント商品又は役務は所定時間に対して保全される。コンポーネントＣＰＯを承諾する売主は、パッケージＣＰＯ管理システム４５００が、例えば、パッケージＣＰＯ管理システム４５００がパッケージを完了しなければならない２週間を許容することができる。このように限定された「事前拘束」期間は後で販売されることができない製品を保全することから売主を保護することに留意する必要がある。
【０２９０】
代替的な実施例においては、パッケージＣＰＯ管理システム４５００は、コンポーネントＣＰＯを承諾することを選択する各売主と拘束力のある合意を結ぶことができる。この実施例においては、パッケージの一部が拘束されて残りは満了していない場合に、パッケージＣＰＯ管理システム４５００はパッケージの承諾されていないコンポーネントを市場価格で又はそれに近い価格で完了するために差額資金を出すことができる。更なる代替的な実施例においては、パッケージＣＰＯ管理システム４５００は、各パッケージのコンポーネントが拘束される見込みに基づいて、特定の連続順序でコンポーネントＣＰＯを売主に与えることができる。
【０２９１】
また、売主は、最初の事前拘束を暗号化することによって事前拘束が得られた後には、パッケージＣＰＯ管理システム４５００は承諾されたコンポーネントＣＰＯの販売を売主の競争相手に継続することができないと好ましくは確信することができる。例えば、パッケージＣＰＯ管理システム４５００が航空会社等売主の業界と申込承諾許可を識別することはできるが売主の特定の身元はパッケージ全体が終了するまで識別することができないように、所与のコンポーネントＣＰＯを事前拘束する売主はパッケージＣＰＯ管理システム１００に承諾を送信する前にその身元を明らかにする特徴を暗号化することができる。
【０２９２】
パッケージＣＰＯ管理システム４５００は旅行関連パッケージＣＰＯを処理するシステムとしてここで示されているが、パッケージＣＰＯ管理システム４５００は、当業者には明らかになるであろうように、オートバイと関連保険、コンピュータと関連周辺機器又は大型商品などいかなるコンポーネント商品又は役務若しくはその両方のパッケージをも処理するのに利用されることができる。
【０２９３】
パッケージＣＰＯ管理システム
図４５に示すように、パッケージＣＰＯ管理システム４５００は、一以上の買主又は売主インターフェース４８００−４８０６と通信するために、中央制御装置４６００と一以上の機密保持サーバー４７００を好ましくは有している。パッケージＣＰＯ管理システム４５００は、コンポーネントＣＰＯに関連する業界その他の所定選別基準に基づいて、図４５に示すように、選択された売主に所与のコンポーネントＣＰＯを与えることができ、売主は、興味を持った又は選別権限を有するコンポーネントＣＰＯを得るだけである。代替的に、パッケージＣＰＯ管理システムは、選別用に全売主に全コンポーネントＣＰＯを与えることができる。
【０２９４】
本発明の一の特徴によれば、パッケージＣＰＯ管理システム４５００は、パッケージＣＰＯ管理システム４５００に権限を委任したある代理店ベースの売主に代わって、パッケージＣＰＯ管理システム４５００が所与のコンポーネントＣＰＯを承諾又は拒否することを可能にする選択的代理業的性質を好ましくは与える。従って、パッケージＣＰＯ管理システム４５００は、好ましくは、（ｉ）所与のコンポーネントＣＰＯを承諾又は拒否する権限をパッケージＣＰＯ管理システム４５００に権限を委任したある代理店ベースの売主に代わってコンポーネントＣＰＯを評価し、及び、（ｉｉ）放送ベースの売主が独立してコンポーネントＣＰＯを評価することを可能にする。従って、パッケージＣＰＯ管理システム４５００は、受信したパッケージＣＰＯの一以上のコンポーネントＣＰＯを各放送ベースの売主に好ましくは与え、その売主が所与のＣＰＯを承諾するかどうかを独立して決定することができる。パッケージＣＰＯ管理システム４５００は、コンポーネントＣＰＯを各々の適当な放送ベースの売主に、例えば、同報通信によって、又は、コンポーネントＣＰＯを例えば、各放送ベースの売主によってアクセス可能な電子掲示板に掲載することによって、与えることができる。代替的に、パッケージＣＰＯ管理システム４５００は、代理店ベースの売主の代わりに所与のコンポーネントＣＰＯの承諾又は拒否を決定するために、受信したパッケージＣＰＯの一以上のコンポーネントＣＰＯを一以上の代理店ベースの売主が定義した幾つかのＣＰＯ規程に対して評価することができる。従って、パッケージＣＰＯ管理システム４５００は、一以上の売主が所与のコンポーネントＣＰＯを承諾するかどうかを、コンポーネントＣＰＯを各売主に与えて承諾又は拒否を受信することによって、又は、特定の売主に代わってコンポーネントＣＰＯを承諾、拒否、代案発行する決定をするためにコンポーネントＣＰＯをＣＰＯ規程に適用することによって、決定することができる。
【０２９５】
以下に説明するように、ＣＰＯ規程は、売主が所定最低価格の承諾を了解する制限の組合せを定義するために、売主４８０４など所与の代理店ベースの売主が定義した一連の制限である。一の実施例においては、それぞれの代理店ベースの売主のＣＰＯ規程は収入管理システム、売上管理システム又は利益管理システムによって、若しくは、在庫制御管理するシステムによって生成される。ＣＰＯ規程のより詳細な説明のため、それらが生成される方法及び関連する機密保持の問題は、ここに参照して結合される１９９７年７月８日に出願され、本発明の親出願である合衆国特許出願番号０８／８８９，３１９、発明の名称「条件付購入申込管理計画」を参照のこと。一般に、収入管理システムは、例えば、将来の旅行を予測するために、現在の在庫、価格付け及び収入情報を過去のパターンや外部事件と共に評価することによってＣＰＯ規程生成処理をＣＰＯ規程を生成するのに利用する。
【０２９６】
例えば、所与の代理店ベースの航空会社に対するＣＰＯ規程は、（ｉ）顧客が火曜日と木曜日の間で旅行し、（ｉｉ）チケットが出発の２１日以内に予約され、（ｉｉｉ）チケット毎に価格が少なくとも１６５ドルであり、（ｉｖ）顧客の旅程の全フライトセグメントにＫクラスの在庫が入手可能であり、（ｖ）最低２人の同伴旅行乗客がいる場合には、その航空会社は１９９７年１０月の月間はニュージャージー州ニューワーク（ＥＷＲ）とフロリダ州オーランド（ＭＣＯ）との間の旅行に対するいかなるコンポーネントＣＰＯも承諾すると特定することができる。
【０２９７】
図４７に関連して以下に後述するように、各機密保持サーバー４７００は代理店ベースの一以上の売主に関連付けられることができ、各サーバー４７００は、その他の一つに加えて、売主４８０４及び４８０６などの代理店ベースの関連売主が定義したＣＰＯ規程を格納する。各機密保持サーバー４７００は、図４５に示すように、中央制御装置４６００から遠隔地に配置されてもよいし、中央制御装置４６００と一体でもよい。一の遠隔地の実施例においては、各代理店ベースの売主に関連付けられている機密保持サーバー４７００は、特定の売主によって機密保持がなされている処理施設に物理的に配置されることができるし、第三者の物理的な場所に配置されることができる。
【０２９８】
以下に更に説明するように、各買主は、パッケージＣＰＯ管理システム４５００と、例えば、電話、ファクシミリ、オンラインアクセス、Ｅメール、参上する連絡又は代理人を介して連絡をとり、パッケージＣＰＯ管理システム４５００に彼らのパッケージＣＰＯの条件を与える。各買主は、パッケージＣＰＯ管理システム４５００と通信するために図４８に関連して後述する買主インターフェース４８００などの汎用コンピュータを使用することができることに留意する必要がある。各買主の汎用コンピュータは、パッケージＣＰＯ管理システム４５００と通信するために必要な処理ユニット、モデム、メモリ手段及びソフトウェアを好ましくは有している。
【０２９９】
一旦、パッケージＣＰＯの条件がパッケージＣＰＯ管理システム４５００によって受信されると、中央制御装置４６００は、パッケージＣＰＯ全体をコンポーネントＣＰＯに解体するために、図５５ａ乃至図５５ｃに関連して後述するパッケージＣＰＯ掲載処理５５００を実行し、その後、（ｉ）各コンポーネントＣＰＯを適当な放送ベースの売主に与え、（ｉｉ）各コンポーネントＣＰＯを各適当な代理店ベースの売主の適当なＣＰＯ規程に対して評価する。また、一旦コンポーネントＣＰＯが掲載されると、パッケージＣＰＯ管理システム４５００は、適当な売主がパッケージＣＰＯ全体の各コンポーネントＣＰＯを承諾しているかどうかを決定するために、図５６ａ乃至図５６ｃに関連して以下に更に説明するパッケージＣＰＯ監視処理５６００を好ましくは定期的に実行する。一以上の売主が所与のパッケージＣＰＯの個別的コンポーネントＣＰＯの各々を承諾していれば、パッケージＣＰＯ管理システム４５００は、承諾している売主の各々に代わって、買主が定義した条件に適合する適当な制限でパッケージ全体を購入するように買主が拘束された旨を彼に通知する。
【０３００】
パッケージＣＰＯ管理システム４５００と買主及び売主インターフェース４８００−４８０６（総括的に「ノード」という。）は、ディジタル符号されたデータその他の情報を好ましくは相互に通信する。ノード間の通信リンクは、電子信号が伝搬可能なケーブル、ファイバー又は無線リンクを好ましくは有する。例えば、各ノードは、市内又は地方電話会社によって提供されるもののように公衆電話交換網（ＰＳＴＮ）を利用するインターネット接続を介して接続されることができる。代替的に、各ノードは専用データ線、携帯電話、パーソナルコミュニケーションシステム（ＰＣＳ）、マイクロ波又は衛星ネットワークによって接続されることができる。
【０３０１】
図４６は、例示的中央制御装置４６００の構築を示すブロック図である。中央制御装置４６１０は、中央演算処理装置（ＣＰＵ）４６０５、ランダムアクセスメモリ（ＲＡＭ）４６１０、リードオンリメモリ（ＲＯＭ）４６２０、クロック４６２５、データ記憶装置４６３０、オペレーティングシステム４６５０、支払処理装置４６６０及びネットワークインターフェース４６８０等ある標準ハードウェアコンポーネントを好ましくは有している。ＣＰＵ４６０５は、リストの他の要素の各々に、図４６に示すように、共有データバス若しくは専用接続によって、好ましくはリンクされている。
【０３０２】
ＣＰＵ４６０５は、インテルのペンティアム(R)１００ＭＨｚ  Ｐ５４Ｃマイクロプロセッサ、モトローラの１２０ＭＨｚ  ＰｏｗｅｒＰＣ  ６０４マイクロプロセッサ又はサンマイクロシステムの１６６ＭＨｚ  ＵｌｔｒａＳＰＡＲＣ−１マイクロプロセッサ等の単一の商業的に入手可能な処理装置として具体化されることができる。代替的に、ＣＰＵ４６０５は、パラレル動作する幾つかの処理装置として具体化されてもよい。
【０３０３】
ＲＯＭ４６２０及び／又はデータ記憶装置４６３０は、図５５及び図５６に関連して更に以下に説明するように、ＣＰＵ４６０５が検索、解釈及び実行するように動作することができる一以上の命令を格納するように動作することができる。支払処理装置４６６０は、売主と買主との間で、従来の電子資金移転（ＥＦＴ）ネットワークによって、要求された支払い、課金及びデビットの移転を実行するための既知の処理を好ましくは実行する。特に、図５６に関連して後述するように、現実に買主がパッケージを購入されると、パッケージＣＰＯ監視処理５６００は、所与の買主に関連付けられたクレジットカード情報をクレジットカード発行者に好ましくは支払用に送信する。かかる会計取引処理は、例えば、周知の暗号技術を利用して従来の方法で好ましくは機密保持される。
【０３０４】
ＣＰＵ４６０５は、制御ユニットと、算術論理ユニット（ＡＬＵ）と、スタック可能なキャッシュや複数のレジスタなどＣＰＵローカルメモリ記憶装置とを既知の方法で好ましくは有している。制御ユニットはデータ記憶装置４６３０又はＲＯＭ４６２０から命令を検索するように動作することができる。ＡＬＵは、命令実行に必要な複数の動作を実行するように動作することができる。ＣＰＵローカルメモリ記憶装置は、一時的な結果と制御情報を格納するのに使用される高速記憶装置を与えるように動作することができる。
【０３０５】
図４９乃至図５３にそれぞれ関連して更に以下に説明するように、データ記憶装置４６３０は、買主データベース４９００、売主データベース５０００、パッケージＣＰＯデータベース５１００、コンポーネントＣＰＯデータベース５２００及び市場価格データベース５３００を有している。買主データベース４９００は、、パッケージＣＰＯ管理システム４５００の各買主に関する履歴情報やクレジットカード番号などの請求書情報を含む情報を好ましくは格納している。売主データベース５０００は、パッケージＣＰＯ買主にコンポーネント商品又は役務を販売するために、好ましくは、パッケージＣＰＯ管理システム４５００により登録されている各売主に関する識別子や名前情報を含む情報を好ましくは格納している。パッケージＣＰＯデータベース５１００は、パッケージＣＰＯ管理システム４５００が処理している各パッケージＣＰＯの記録、例えば、各パッケージＣＰＯのコンポーネントＣＰＯの表示と関連ステイタス、を好ましくは含んでいる。コンポーネントＣＰＯデータベース５２００は、パッケージＣＰＯ管理システム４５００によって処理されている各コンポーネントＣＰＯの記録、例えば、各コンポーネントＣＰＯの条件と関連ステイタス、を好ましくは含んでいる。最後に、市場価格データベース５３００は、パッケージＣＰＯ管理システム４５００によって処理される各コンポーネント商品又は役務毎に市場価格情報を好ましくは格納している。
【０３０６】
また、データ記憶装置４６３０は、図５５及び図５６にそれぞれ関連して以下に説明するパッケージＣＰＯ掲載処理５５００とパッケージＣＰＯ監視処理５６００とを含んでいる。一般に、パッケージＣＰＯ掲載処理５５００は、パッケージＣＰＯをコンポーネント商品又は役務に分解して、その後、（ｉ）各コンポーネントＣＰＯを適当な放送ベースの売主に対して掲載し、及び、（ｉｉ）各代理店ベースの売主の適当なＣＰＯ規程に対して各コンポーネントＣＰＯを評価する。パッケージＣＰＯ監視処理５６００は、掲載されたパッケージＣＰＯの各コンポーネントＣＰＯが適当な売主によって承諾されているかどうかを決定し、承諾されていれば、買主情報を各承諾している売主に提供する。このようにして、所与のパッケージＣＰＯの個別的コンポーネントＣＰＯの各々が承諾されれば、パッケージＣＰＯ管理システム４５００は、承諾している売主の各々の代わりに、買主に対して彼がパッケージ全体を購入するように拘束されている旨を通知する。
【０３０７】
ネットワークインターフェース４６８０は、中央制御装置４６００を買主及び売主に、例えば、公衆電話交換網（ＰＳＴＮ）を利用するインターネット接続によって接続する。ネットワークインターフェース４６８０は複数接続を同時設定する多重通信チャネルを好ましくは有している。
【０３０８】
図４７は、例示的な機密保持サーバー４７００の構築を示すブロック図である。上述したように、パッケージＣＰＯ管理システム４５００は、各々が一以上の代理店ベースの売主４８０４、４８０６をサポートしている一以上の機密保持サーバー４７００を利用することができる。各機密保持サーバー４７００は、好ましくは、中央演算処理装置（ＣＰＵ）４７０５、ランダムアクセスメモリ（ＲＡＭ）４７１０、リードオンリメモリ（ＲＯＭ）４７２０、クロック４７２５、データ記憶装置４７３０及び通信ポート４７４０等ある標準ハードウェアコンポーネントを含んでいる。これらのコンポーネントの各々は図４６に関連して上述したものと同一であってもよい。
【０３０９】
前述したように、一の実施例において、ＣＰＯ規程は、各ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、機密保持データベースに格納されることができる。従って、機密保持サーバー４７００は、オラクル（Ｏｒａｃｌｅ）、インフォミックス（Ｉｎｆｏｒｍｉｘ）又はＩＢＭから商業的に入手可能な製品等の機密保持データベースを好ましくは使用している。
【０３１０】
図５４に関連して以下に更に説明するように、データ記憶装置４７３０は、機密保持売主規程データベース５４００を有している。機密保持売主規程データベース５４００は、機密保持サーバー４７００に関連付けられた一以上の代理店ベースの売主のためにＣＰＯ規程を好ましくは保存している。前述したように、機密保持売主規程データベース５４００は、ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、暗号形式で格納されることができる。また、データ記憶装置４７３０は、図５７に関連して以下に更に説明するコンポーネントＣＰＯ規程評価処理５７００を有している。一般に、コンポーネントＣＰＯ規程評価処理５７００は、パッケージＣＰＯ掲載処理５５００が実行するサブルーチンであり、それは、所与のＣＰＯに売主に変わって応答を生成するために、コンポーネントＣＰＯを受信してそのＣＰＯを代理店ベースの一以上の売主の規程に対して比較する。
【０３１１】
機密保持サーバー４７００は、パッケージＣＰＯ管理システム４５００が処理する各コンポーネントＣＰＯ毎に会計形跡を選択的に保存することができる。適した会計システムの説明のため、上述したようにここで参照して結合されている本発明の親出願を参照のこと。
【０３１２】
通信ポート４７４０は、機密保持サーバー４７００を中央制御装置４６００に接続する。通信ポート４７４０は複数接続を同時に定する多重通信チャネルを好ましくは有している。
【０３１３】
図４８は、例示的な買主及び売主インターフェース４８００−４８０６の構築を示すブロック図である。インターフェース４８００は、中央演算処理装置（ＣＰＵ）４８０８、ランダムアクセスメモリ（ＲＡＭ）４８１０、リードオンリメモリ（ＲＯＭ）４８２０、クロック４８２５、データ記憶装置４８３０及び通信ポート４８４０等ある標準ハードウェアコンポーネントを好ましくは含んでいる。これらのコンポーネントの各々は図４６に関連して上述したものと同一であってもよい。また、インターフェース４８００は、ビデオモニタ４８５０及び関連ビデオドライバ４８６０、キーボードなどの入力装置４８７０を好ましくは含んでいる。
【０３１４】
データ記憶装置４８３０は、パッケージＣＰＯ管理システム４５００の中央制御装置４６００と通信するために、それぞれの買主又は売主インターフェース４８００−４８０６によって要求されたメッセージを格納するメッセージデータベース４８３０を好ましくは含んでいる。通信ポート４８４０は、インターフェース４８００を、放送及び代理店ベースの売主のそれぞれのために、中央制御装置４６００又は機密保持サーバー４７００に接続する。
【０３１５】
図４９は、パッケージＣＰＯ管理システム４５００の各買主に関する履歴情報及びクレジットカード番号などの請求書情報などの情報を好ましくは格納している例示的な買主データベース４９００を示している。買主データベース４９００は、異なる買主に各々関連付けられた記録４９０５−４９１５等の複数の記録を保存している。フィールド４９２０の各買主識別子毎に、買主データベース４９００は、対応する買主の名前と住所をフィールド４９２５及び４９３０のそれぞれに、クレジットカード番号をフィールド４９３５に含んでいる。また、買主データベース４９００は、ここで説明されているようにパッケージＣＰＯ又は本発明の親出願に説明されているように一般のＣＰＯである、買主に関連付けられたＣＰＯの表示をフィールド４９４０に好ましくは含んでいる。フィールド４９２０に格納されている識別子は、例えば、以前の購入と買主に関連付けられたＣＰＯの過去のデータベース（図示せず）にインデックスを付すのに利用することができる。
【０３１６】
図５０は、識別子と名前情報を含み、コンポーネント商品又は役務をパッケージＣＰＯ買主に販売するためにパッケージＣＰＯ管理システム４５００により登録されている各売主に関する情報を好ましくは格納している例示的な売主データベース５０００を示している。売主データベース５０００は、異なる売主に各々関連付けられている記録５００５−５０３０等の複数の記録を保存している。フィールド５０３５にリストされている各売主識別子毎に、売主データベース５０００は対応する売主名をフィールド５０４０に含んでいる。また、売主データベース５０００は、各売主に関連付けられたＣＰＯに対するトラッキング番号をフィールド５０４５に好ましくは含んでいる。フィールド５０４５に記録された情報は、売主ＩＤフィールドを後述のパッケージＣＰＯデータベース５１００に含むことによって、同様に記録可能であることに留意する必要がある。
【０３１７】
図５１は、各パッケージＣＰＯのコンポーネントＣＰＯと関連ステイタスの表示を含み、パッケージＣＰＯ管理システム４５００が処理している各パッケージＣＰＯの記録を好ましくは含んでいるパッケージＣＰＯデータベース５１００を示している。パッケージＣＰＯデータベース５１００は、異なるパッケージＣＰＯに各々関連付けられている記録５１０５−５１１０等の複数の記録を保存している。フィールド５１２０にリストされている各パッケージＣＰＯ毎に、パッケージＣＰＯデータベース５１００は、ステイタスと原申込価格をフィールド５１２５及び５１３０のそれぞれに含んでいる。また、パッケージＣＰＯデータベース５１００は、マージンファクター、残りマージン、調整されたパッケージＣＰＯ価格及び割当マージンの割合をフィールド５１３５乃至５１５０のそれぞれに好ましくは記録している。マージン変数がパッケージＣＰＯ管理システム４５００によって処理される方法を図５６に関連して以下に説明する。各マージン割当毎に要求されている全掲載存続期間と掲載時間と共に、パッケージＣＰＯの掲載及び満了日は、フィールド５１５５乃至５１７０にそれぞれ格納されている。各パッケージＣＰＯの個別的コンポーネント商品又は役務はフィールド５１７５で選択的に識別され、各コンポーネントに関連付けられた条件とコンポーネント番号はフィールド５１８０及び５１８５に述べられている。フィールド５１７５及び５１８０に記録されている情報は、フィールド５１８５に記録されたコンポーネントＣＰＯ番号を利用してコンポーネントＣＰＯデータベース５２００から代替的に検索可能であることに留意する必要がある。最後に、各パッケージＣＰＯに関連付けられた買主の識別子はフィールド５１９０に好ましくは記録される。
【０３１８】
図５２は、コンポーネントＣＰＯの条件と関連ステイタスを含み、パッケージＣＰＯ管理システム４５００が処理している各コンポーネントＣＰＯ毎に記録を好ましくは含んでいる例示的なコンポーネントＣＰＯデータベース５２００を示している。コンポーネントＣＰＯデータベース５２００は、システム４５００が処理している異なるコンポーネントＣＰＯに各々関連付けられた記録５２０５及び５２３０等の複数の記録を保存している。フィールド５２４０のコンポーネントＣＰＯ番号によって識別された各コンポーネントＣＰＯ毎に、コンポーネントＣＰＯデータベース５２００は、コンポーネントＣＰＯにそれぞれ関連付けられた対応する対象、価格及び条件と共に、事前拘束されたコンポーネントＣＰＯに対するステイタスと満了日をフィールド５２５０乃至５２６０に含んでいる。最後に、各コンポーネントＣＰＯに関連付けられている買主の識別子がフィールド５２６５に好ましくは記録される。
【０３１９】
図５３は、パッケージＣＰＯ管理システム４５００が処理する各コンポーネント商品又は役務に対する市場価格情報を好ましくは格納している例示的な市場価格データベース５３００を示している。図５５に関連して以下に更に説明するように、パッケージＣＰＯ掲載処理４５００は、コンポーネント商品又は役務の各々に全パッケージ価格を割り当てるのに市場価格情報を好ましくは利用する。市場価格データベース５３００は、システム４５００が処理する異なるコンポーネント商品又は役務に各々関連付けられた記録５３０５乃至５３４５等の複数の記録を保存している。フィールド５３６０で識別されているコンポーネント商品又は役務毎に、市場価格データベース５３００は、フィールド５３７０において表示された各期間毎に、フィールド５３７５で述べられた対応市場価格と共に、各商品又は役務毎に利用可能品質又はサービスレベルをフィールド５３６５で識別する。往復航空旅行の各サービスレベルに対する市場価格は、各出発及び目的都市の組（Ｏ＆Ｄペア）毎に好ましくは記録される。
【０３２０】
上述したように、機密保持サーバー４７００は、機密保持サーバー４７００に関連付けられている代理店ベースの一以上の売主のためにＣＰＯ規程を格納するために、一以上の機密保持売主規程データベース５４００を好ましくは保持している。機密保持売主規程データベース５４００は、代理店ベースの航空会社に対して図５４ａに、代理店ベースのホテルに対して図５４ｂに示されている。
【０３２１】
図５４ａは、特定の機密保持サーバー４７００に関連付けられた代理店ベースの一以上の航空会社に対してＣＰＯ規程を好ましくは保存する例示的な機密保持航空会社規程データベース５４００を示している。上述したように、機密保持航空会社規程データベース５４００は、ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、暗号形式で格納されることができる。機密保持航空会社規程データベース５４００は、異なるＣＰＯ規程に各々関連付けられている記録５４０２及び５４０４等の複数の記録を保存している。フィールド５４１０の規程番号によって識別されている各ＣＰＯ規程毎に、機密保持航空会社規程データベース５４００は、それぞれの代理店ベースの航空会社が定義した関連制限をフィールド５４１２乃至５４４４に含んでいる。
【０３２２】
図５４ｂは、特定の機密保持サーバー４７００に関連付けられた代理店ベースの一以上のホテルに対してＣＰＯ規程を好ましくは保存する例示的な機密保持ホテル規程データベース５４５０を示している。上述したように、機密保持ホテル規程データベース５４５０は、ＣＰＯ規程に含まれている非常に機密性の高い情報の完全性と秘匿性を維持するために、暗号形式で格納されることができる。機密保持ホテル規程データベース５４５０は、異なるＣＰＯ規程に各々関連付けられている記録５４５２及び５４５６等の複数の記録を保存している。フィールド５４６０の規程番号によって識別されている各ＣＰＯ規程毎に、機密保持ホテル規程データベース５４５０は、適用可能なホテルサイトをフィールド５４６５に識別し、それぞれの代理店ベースのホテルが定義した関連制限をフィールド５４７０乃至５４９０に含んでいる。
【０３２３】
上述したように、中央制御装置４６００は、パッケージＣＰＯをコンポーネント商品又は役務に分解するために、図５５ａ乃至図５５ｃに示すパッケージＣＰＯ掲載処理５５００を好ましくは実行し、その後、（ｉ）各コンポーネントＣＰＯを適当な放送ベースの売主に対して掲載し、（ｉｉ）各コンポーネントＣＰＯを代理店ベースの各売主の適当なＣＰＯ規程に対して評価する。図５５ａに示すように、パッケージＣＰＯ掲載処理５５００は、買主がコンポーネント商品又は役務のパッケージに対するＣＰＯを提出すると、本発明の原理を具体化する処理をステップ５５０５で開始する。
【０３２４】
その後、中央制御装置４６００は、ステップ５５１０で、各コンポーネント商品又は役務の説明、資金が支払可能なクレジット又はデビットカード口座などの汎用口座識別子等のパッケージＣＰＯに関連付けられた条件を買主から受信し、その後ステップ５５１５で、パッケージＣＰＯの価格と満了日を買主から受信する。このようにして、申込は汎用口座によって、例えば、クレジットカード口座のクレジット限度額を利用して、保証される。適当な法律文句が、拘束力のあるパッケージを形成するために、ステップ５５２０で、好ましくは表示されるか買主に読み上げられる。パッケージＣＰＯ番号はステップ５５２５で生成され、買主識別子、パッケージＣＰＯ価格及び満了日、コンポーネント商品又は役務の条件などのパッケージＣＰＯ情報が、その後ステップ５５３０で、パッケージＣＰＯデータベース５１００に入力される。
【０３２５】
上述したように、パッケージＣＰＯ管理システム４５００は、各コンポーネントＣＰＯ毎に申込価格を計算する前に、パッケージ申込価格総額のマージンを好ましくは保全している。従って、適当なマージンがステップ５５３５で、パッケージＣＰＯ価格にパッケージＣＰＯデータベース５１００に記録されているマージンファクターをかけることによって計算される。その後、計算されたマージンは、パッケージＣＰＯデータベース５１００の「残りマージン」フィールド５１４０にステップ５５４０で記録される（図５５ｂ）。調整されたＣＰＯ価格は、計算されたマージンを原パッケージ申込価格総額から引くことによってその後計算され、それはその後パッケージＣＰＯデータベース５１００にステップ５５４５で入力される。パッケージＣＰＯのステイタスは「アクティブ」に、パッケージＣＰＯデータベース５１００のフィールド５１２５にステップ５５５０で設定される。
【０３２６】
パッケージＣＰＯの各コンポーネント商品又は役務の市場価格は、ステップ５５５５で市場価格データベース５３００から検索される。パッケージＣＰＯ全体の市場価格は、パッケージ全体の各個別的コンポーネントＣＰＯの市場価格を加えることによって、ステップ５５６０で計算される。各コンポーネントＣＰＯに対する個別的ＣＰＯ価格は、その後、ステップ５５６５で、例えば、全市場価格に対するそれぞれのコンポーネント商品又は役務の市場価格の比に従って、ステップ５５４５で計算されるように、調整されたパッケージＣＰＯ価格を割り当てることによって計算される。
【０３２７】
ＣＰＯ番号は、その後ステップ５５７０で各コンポーネントＣＰＯ毎に生成され、パッケージＣＰＯデータベース５１００の「コンポーネントＣＰＯ番号」フィールドにステップ５５７５で記録される（図５５ｃ）。各コンポーネントＣＰＯが放送ベースの売主の各々に与えられてコンポーネントＣＰＯ規程評価処理５７００がステップ５５９０で代理店ベースの売主に対して実行される前に、ステップ５５８０で各コンポーネントＣＰＯ毎に、コンポーネントＣＰＯデータベース５２００に新しい記録が形成される。プログラム制御はステップ５５９５で終了する。
【０３２８】
上述したように、中央制御装置４６００は、適当な売主が掲載パッケージＣＰＯの各コンポーネントＣＰＯを承諾したかどうかを決定するために、図５６ａ乃至５６ｃに示すパッケージＣＰＯ監視処理５６００を好ましくは実行し、そして、承諾すれば、承諾している各売主に買主情報を与える。このようにして、所与のパッケージＣＰＯの個別的コンポーネントＣＰＯの各々が承諾されれば、パッケージＣＰＯ管理システム４５００は、承諾している売主の各々の代わりに、買主に通知してパッケージ全体を購入するように買主を拘束する。パッケージＣＰＯ監視処理５６００は、各コンポーネントＣＰＯのステイタスを決定するために、定期的に又は継続して実行されることができる。
【０３２９】
図５６ａに示すように、パッケージＣＰＯ監視処理５６００は、所与のパッケージＣＰＯの全コンポーネントＣＰＯが現在掲載されている価格で事前拘束されたかどうかを決定するテストを実行することによって、ステップ５６０５で本発明の原理を具体化する処理を開始する。例示的な実施例においては、所与のコンポーネントＣＰＯを承諾する最初の売主にはそのコンポーネントＣＰＯが与えられる。複数の承諾している売主の中でどの売主にコンポーネントＣＰＯが与えられるべきかを決定する他の機構の説明は上述のここで参照して結合される本発明の親出願を参照のこと。所与のパッケージＣＰＯの全コンポーネントＣＰＯが現在掲載されている価格で事前拘束されたとステップ５６０５で決定されると、買主の名前、住所及びクレジットカード口座番号を含む買主識別情報が買主データベース４９００からステップ５６５０で検索される。その後、買主識別番号はコンポーネントＣＰＯを承諾した各売主にステップ５６５５で送信される。パッケージＣＰＯ監視処理５６００は、パッケージＣＰＯ管理システム４５００の商人識別子を、買主のクレジットカード口座番号、請求書記述子及びパッケージＣＰＯ購入額と共に、クレジットカード発行者に支払許可のためにステップ５６６０で従来のクレジットカード許可ネットワークを介して送信する。
【０３３０】
パッケージＣＰＯデータベース５１００のステイタスフィールド５１２５は、プログラム制御がステップ５６７０で終了する前に、それぞれのパッケージＣＰＯが完了したことを表示するために、ステップ５６６５で更新される。
【０３３１】
しかし、所与のパッケージＣＰＯの全コンポーネントＣＰＯが現在掲載されている価格で事前拘束されていないとステップ５６０５で決定されると、パッケージＣＰＯの満了日がパッケージＣＰＯデータベース５１００のフィールド５１６０からステップ５６１０で検索される（図５６ｂ）。その後ステップ５６１５で、パッケージＣＰＯが満了したかどうかを決定するテストが実行される。各コンポーネントが事前拘束されずにパッケージＣＰＯが満了したことがステップ５６１５で決定されると、パッケージＣＰＯ監視処理５６００は、（１）ステップ５６３５で、一以上の売主が承諾した満了パッケージＣＰＯのコンポーネントＣＰＯの事前拘束合意の終了をそれぞれの売主に、そして、（２）ステップ５６４０で、それぞれの買主にパッケージＣＰＯの満了を通信する。代替的な実施例では、原パッケージＣＰＯが承諾されなかった場合は、買主は、訂正パッケージＣＰＯを再提出するように促されることができる。また、パッケージＣＰＯ管理システム４５００は、パッケージＣＰＯ管理システム４５００が受信した個別的コンポーネントの承諾に基づいて、その買主のために代案編集を試みることができる。その後、プログラム制御はステップ５６４５で終了する。
【０３３２】
しかし、パッケージＣＰＯが満了していないということがステップ５６１５で決定されると、パッケージＣＰＯ監視処理５６００は、例えば、パッケージＣＰＯのコンポーネント数を識別するためにパッケージＣＰＯデータベース５１００にアクセスして現在事前拘束されているコンポーネント数を識別することによって現在事前拘束されているパッケージＣＰＯ全体の割合を表示するために、パッケージＣＰＯデータベース５１００のステイタスフィールド５１２５をステップ５６２０で調整する。その後、「全掲載存続期間」パラメータがパッケージＣＰＯデータベース５１００のフィールド５１６５からステップ５６２５で検索され、それはその後フィールド５１７０で述べられた「各マージン割当毎の掲載時間」パラメータをかけられる。
【０３３３】
その後、事前拘束されていない各コンポーネントＣＰＯの価格を増額するために追加マージンを割り当てるのに必要な掲載時間に対してパッケージＣＰＯがアクティブであるかどうかを決定するテストがステップ５６３０で行われる。追加マージンの割り当てに必要な掲載時間に対してパッケージＣＰＯがアクティブでないことがステップ５６３０で決定されると、プログラム制御はステップ５６０５に戻り（図５６ａ）、上述した方法で処理を継続する。しかし、追加マージンの割り当てに必要な掲載時間に対してパッケージＣＰＯがアクティブであるとステップ５６３０で決定されると、各残りのアクティブなコンポーネントＣＰＯの割合成分がステップ５６７５で、全ての残りのアクティブなコンポーネントＣＰＯの総価格に対して、計算される（図５６ｃ）。
【０３３４】
「割当マージンの割合」はその後ステップ５６８０でパッケージＣＰＯデータベース５１００のフィールド５１５０から検索される。残りのアクティブなコンポーネントＣＰＯに割り当てられるべきマージン額は、検索された「割当マージンの割合」の値にパッケージＣＰＯデータベース５１００のフィールド５１４０に記録された「残りマージン」の値をかけることによって、その後ステップ５６８２で計算される。その後、割当可能なマージンは、適当な割合の残りのアクティブなコンポーネントＣＰＯの各々に、（ステップ５６７５で決定されたように）残りのアクティブなコンポーネントＣＰＯの価格割合に計算された割当可能なマージン額をかけることによって、ステップ５６８４で適用される。
【０３３５】
例えば、３つのコンポーネントパッケージの１のコンポーネントが原掲載価格でまず事前拘束され、残りの２つのコンポーネントが追加マージンを割り当てるのに必要な掲載期間中に拘束されなかった場合、パッケージＣＰＯ監視処理５６００は、２つの残りコンポーネントＣＰＯ間でマージンの一部を好ましくは割り当てる。各コンポーネントＣＰＯへの割当額はそれぞれ最初に掲載された価格によって好ましくは決定される。上述の例において、買主が航空旅行、ホテル宿泊及びレンタカーからなる旅行パッケージに対してパッケージに対する総費用が千ドル（１，０００．００ドル）以下という申込を提出して最初の事前拘束コンポーネントは航空券３６０ドルであった場合を仮定してみる。従って、パッケージ監視処理５６００は、ホテルとレンタカーコンポーネントＣＰＯに対する残りマージンの一部を申込価格に割り当てる。好ましい実施例においては、ホテルコンポーネントＣＰＯは残りのＣＰＯ価格全体の６２％（３３３ドル／（３３３ドル＋２０７ドル））であるので、ホテルコンポーネントＣＰＯの申込価格は、マージン（５０ドル）からとられたお金の６２％だけ、即ち、３１ドルだけ、増加している。同様に、車のレンタルコンポーネントＣＰＯ申込価格は、３８％だけ、即ち、１９ドルだけ増加している。一以上のコンポーネントが追加マージンの割当てに必要な掲載時間再び拘束されないと、マージンの多くが好ましくは割り当てられる。
【０３３６】
フィールド５１４０に記録された「残りマージン」は、以前のステップで割り当てられたマージンを差し引くことによってステップ５６８８で調整される。その後ステップ５６９０で、新しく調整された価格を有する残りのアクティブなＣＰＯが放送ベースの売主に与えられ、コンポーネント規程評価処理５７００が適当な代理店ベースの売主の各々に対して実行される。最後に、プログラム制御はステップ５６０５（図５６ａ）に戻り、全コンポーネントＣＰＯが事前拘束されるかパッケージＣＰＯが満了するまで、上述したように処理を継続する。このようにして、申込価格は、追加マージンの割当てに必要な各期間に対して承諾されないままの各コンポーネントＣＰＯ毎に追加的な割り当てられたマージンにより増額される。上述したように、パッケージＣＰＯ掲載処理５５００とパッケージＣＰＯ監視処理５６００の各々は、所与のコンポーネントＣＰＯに対する応答を売主に代わって生成して一以上の代理店ベースの売主の規程に対してコンポーネントＣＰＯを比較するために、代理店ベースの売主のために、ステップ５５９０と５６９０でそれぞれ、コンポーネントＣＰＯ規程評価処理を実行する。例示的なコンポーネントＣＰＯ規程評価処理４７００が図５７に示されている。一の実施例においては、コンポーネントＣＰＯ規程評価処理５７００は代理店ベースの各売主毎にカスタマイズされており、その結果、各評価処理５７００はコンポーネントＣＰＯ記録を中央制御装置４６００から標準形式で、関連売主の規程に対して比較するために受信し、「承諾」又は「拒否」などのコンポーネントＣＰＯへの売主の標準応答を返却する。
【０３３７】
図５７に示すように、コンポーネントＣＰＯ規程評価処理５７００は、ステップ５７１０で、コンポーネントＣＰＯに関連した機密保持売主規程データベース５０００の全ＣＰＯ規程をまず識別する。その後ステップ５７２０で、コンポーネントＣＰＯデータベース５２００のコンポーネントＣＰＯ記録からの買主定義条件は、その後ステップ５７２０で、機密保持売主規程データベース５０００からの対応する売主定義制限に、以前のステップで識別された各ＣＰＯ規程毎に、比較される。
【０３３８】
その後、コンポーネントＣＰＯがＣＰＯ規程を満足するかどうかを決定するテストがステップ５７３０で実行される。コンポーネントＣＰＯがあるＣＰＯ規程を満足しないとステップ５７３０で決定されると、プログラム制御はステップ５７７０で終了する。しかし、コンポーネントＣＰＯがあるＣＰＯ規程を満足するとステップ５７３０で決定されると、そのコンポーネントＣＰＯは、コンポーネントＣＰＯデータベース５２００からステップ５７４０で検索され、売主データベース５０００の「ＣＰＯトラッキング番号」フィールド５０４５に入力される。コンポーネントＣＰＯデータベース５２００のフィールド５２４５のコンポーネントＣＰＯのステイタスは、プログラム制御がステップ５７７０で終了する前に、ステップ５７６０で、「事前拘束完了」に更新される。また、事前拘束満了日は、売主が要求すれば、フィールド５２４５に加えられることができる。
【０３３９】
通話に対するＣＰＯ管理システム
一以上の通話に対する購入申込を処理するのに適している本発明の更なる実施例を図５８乃至図６６に関連して以下に説明する。図５８Ａ及び図５８Ｂは、発呼者５８１０などの一以上の発呼者からの通話のＣＰＯを受信して処理する条件付購入申込（ＣＰＯ）管理システム５８００を示している。ＣＰＯ管理システム５８００は、交換通信業者５８２０−５８２４等の一以上の長距離通信業者が所与のＣＰＯを承諾して発呼者５８１０が定義した制限に従って通話を完了することを了解するかどうかを決定するために、そのＣＰＯを処理する。例えば、合衆国では、交換通信業者５８２０−５８２４は、ＡＴ＆Ｔ、スプリント（Ｓｐｒｉｎｔ）及びＭＣＩである。以下に更に説明するように、交換通信業者５８２０は所与のＣＰＯを承諾するならば、ＣＰＯ管理システム５８００は承諾している交換通信業者５８２０の代わりに発呼者５８１０を拘束して法律的に拘束力のある契約を作成する。
【０３４０】
ここで使用するように、ＣＰＯは、典型的に発呼者が定義した価格での一以上の通話の完了に対して発呼者５８１０が提出した一以上の条件を含む拘束力のある提供である。このようにして、発呼者５８１０は、個別通話、一以上の着呼者５８３０への通話パッケージ又は所定期間の電話サービスを提供する契約に対してＣＰＯを好ましくは提出することができる。例示的な実施例においては、発呼者５８１０が定義した条件は、着呼された電話番号、最高価格、一以上の好ましい通信業者がいればそれを、特定時刻などの時間制限や最短通話期間などと共に、含んでいる。最高価格は、好ましくは発呼者５８１０が、２０分の通話に対する１０ドルなど固定期間に対する価格、１分当り１４セント（０．１４ドル／分）などの分価格で、特定することができる。
【０３４１】
ＣＰＯ管理システム
図５８Ａは、一以上の発呼者５８１０と、所望の着呼者５８３０に呼を発送する一以上の交換通信業者５８２０−５８２４に、ＣＰＯ管理システム５８００を相互連結する例示的なネットワーク環境を示している。本発明の特徴によれば、簡易電話サービス（Ｐｌａｉｎ  Ｏｌｄ  Ｔｅｌｅｐｈｏｎｅ  Ｓｅｒｖｉｃｅ：  ＰＯＴＳ）電話番号によって典型的に識別されている着呼者５８３０に電話をしたい発呼者５８１０は、発呼者が定義した制限に従って通話に対するＣＰＯ管理システム５８００に申込を提出することができる。ある好ましい実施例においては、発呼者５８１０は、着呼者５８３０の電話番号に電話をかける前に、トールフリー電話番号や「８００番番号」などＣＰＯ管理システム５８００が割り当てた電話番号にダイアルしてＣＰＯ管理システム５８００にＣＰＯの条件を与えるのに図５９に示す電話機５９００を利用する。代替的に、発呼者５８１０は、最初にＣＰＯ管理システム５８００にファクシミリにより連絡をとる。一旦発呼者５８１０が最初にＣＰＯ管理システム５８１０に連絡をとると、発呼者５８１０は通話の最高価格と着呼者５８３０の電話番号などのＣＰＯ条件をＣＰＯ管理システム５８００に提出する。
【０３４２】
図５８Ｂに示す更なる変形例においては、発呼者５８１０はインターネット５８７０にアクセスするのに汎用コンピュータなどの加入者端末５８１５を利用してオンラインアクセス又はＥメールにより最初にＣＰＯ管理システム５８００に連絡を取ることができる。このオンラインの実施例は、一以上の着呼者５８３０への通話のパッケージに対して、又は、所定期間の電話役務を提供する契約のために、ＣＰＯの提出を希望する発呼者５８１０に特に適している。
【０３４３】
ＣＰＯの条件は、選択的に、図５９に示すように、発呼者５８１０に電話機５９００上に表示することができる。また、電話機５９００は、ＣＰＯ管理システム５８００又は直接に交換通信業者５８２０にＣＰＯを送信するソフトウェアにより特に構成されることができる。例えば、電話機５９００の短縮ダイアルボタンは自動的にＣＰＯの条件をＣＰＯ管理システム５８００又は直接に交換通信業者５８２０に送信するようにプログラムされることができる。このようにして、発呼者５８１０は、電話機５９００のキーパッドとファンクションキーを利用して所与のＣＰＯの条件をプログラムし、その後、短縮ダイアルボタンを利用してＣＰＯの送信を開始する。
【０３４４】
図５８Ａに示すように、発呼者５８１０が、ＣＰＯ管理システム５８００が割り当てた電話番号にダイアルすると、例えば、市内電話会社の電話交換システムである加入者交換オペレータ５８５０との接続がまず典型的に設定される。加入者交換オペレータ５８５０は、代わりに、発呼者を公衆電話交換網（ＰＳＴＮ）に接続する。加入者交換オペレータ５８５０は発呼者５８１０と幾つかの交換通信業者５８２０−５８２４の一つとの間に電話業界では周知の方法で通信リンク５８６０上に接続を設定することができる。交換通信業者５８２０は、例えば、回路及びパケット交換網又はその組合せを有する長距離通信業者ネットワークのプロバイダーであり、通信リンク５８６０は電子信号が伝搬可能なケーブル、ファイバー又は無線リンクである。長距離電話通信業者が多くのエリアで市内電話サービスを提供する又はその逆の傾向が増加しているため加入者交換オペレータ５８５０と交換通信業者５８２０−５８２４との間の区別は透明になり得ることに留意する必要がある。一以上の交換通信業者５８２０は所与の発呼者５８１０と所望の着呼者５８３０との間で呼を発送することができる。交換通信業者５８２０によって長距離通信業者ネットワーク上で所与の発呼者５８１０と所望の着呼者５８３０との間に接続が形成される方法のより詳細な説明については、ここで参照して結合される米国特許第４，１９１，８６０号を参照のこと。
【０３４５】
本発明の特徴によれば、ＣＰＯ管理システム５８００は、ＣＰＯ管理システム５８００が所与のＣＰＯを承諾又は拒否することを、ＣＰＯ管理システム５８００に当該権限を委任したある代理店ベースの交換通信業者５８２０に代わって、可能にする選択的代理業的特徴を好ましくは与える。従って、ＣＰＯ管理システム５８００は、好ましくは、（ｉ）  ＣＰＯ管理システム５８００に所与のＣＰＯを承諾又は拒否することを決定する権限を委任したある代理店ベースの交換通信業者５８２０に代わってＣＰＯを評価し、（ｉｉ）放送ベースの交換通信業者５８２０がＣＰＯを独立して評価することを可能にする。従って、ＣＰＯ管理システム５８００は、交換通信業者５８２０が独立して所与のＣＰＯを承諾するかどうかを決定することができるように、ＣＰＯを放送ベースの交換通信業者５８２０の各々に与えることができる。ＣＰＯ管理システム５８００は、ＣＰＯを放送ベースの交換通信業者５８２０の各々に、例えば、放送送信によって又はＣＰＯを、例えば、各放送ベースの交換通信業者５８２０がアクセス可能に電子掲示板に掲載することによって、与えることができることに留意する必要がある。
【０３４６】
また、ＣＰＯ管理システム５８００は、所与のＣＰＯの承諾又は拒否を代理店ベースの交換通信業者に代わって決定するために、一以上の代理店ベースの交換通信業者が定義した幾つかのＣＰＯ規程に対してＣＰＯを評価することができる。従って、ＣＰＯ管理システム５８００は、ＣＰＯを各通信業者に与えて承諾又は拒否を受信することによって、又は、特定の通信業者の代わりにＣＰＯを承諾、拒否又は代案発行することを決定するためにＣＰＯ規程に当てはめることによって、一以上の通信業者が所与のＣＰＯを承諾するかどうかを決定することができる。
【０３４７】
以下に更に説明するように、ＣＰＯ規程は所与の代理店ベースの交換通信業者５８２０が定義した一連の制限であって、交換通信業者５８２０が一以上の通話を完了する委託を承諾することを了解する制限の組合せを定義している。好ましい実施例においては、ＣＰＯ規程は、それぞれ代理店ベースの交換通信業者５８２０のある種の収入管理システム、売上管理システム又は利益管理システムによって、又は、ネットワーク容量の制御管理システムによって生成される。ＣＰＯ規程のより詳細な説明のため、その生成方法と関連機密保持問題は、ここに参照して結合される１９９７年７月８日に出願され、本発明の親出願である米国特許出願番号０８／８８９，３１９、発明の名称「条件付購入申込管理計画」を参照のこと。一般に、例えば、収入管理システムは、将来の通話需要を予測するために、過去のパターンと外部事件と共に、現在のネットワーク容量、価格付け及び収入情報を評価することによって、ＣＰＯ規程を生成するのにＣＰＯ規程生成処理を利用している。
【０３４８】
一旦ＣＰＯの条件がＣＰＯ管理システム５８００に受信されると、図６０に関連して後述する中央サーバー６０００は、（ｉ）各ＣＰＯを交換通信業者５８２０に与えるため、及び、（ｉｉ）交換通信業者が申込条件を承諾したかどうかを決定するために、図６５ａ及び図６５ｂに関連して以下に説明するＣＰＯ管理処理６５００を実行する。その後、ＣＰＯ管理システム５８００又は承諾している交換通信業者５８２０は、発呼者５８１０に交換通信業者５８２０の応答を通知し、承諾されれば、発呼者５８１０は、発呼者５８１０が定義した条件に適合する適当な制限を有する一以上の通話を完了して支払いをするように拘束される。
【０３４９】
ＣＰＯ管理システム５８００は、選択的に、ＣＰＯ管理システム５８００が処理する各ＣＰＯに対する会計形跡を保存することができる。適した会計システムのより詳細な説明に対しては、上述のここで参照して結合される本発明の親出願を参照のこと。
【０３５０】
本発明の更なる特徴によれば、ＣＰＯ管理システム５８００は、発呼者５８１０が、所与のＣＰＯに関連する一以上の通話に対する通信業者の最低価格を識別することを防止している。例えば、ＣＰＯ管理システム５８００は、好ましくは通信業者の最低価格を発呼者に開示せず、選択的に、いかなる発呼者５８１０も所定期間内に提出可能なＣＰＯの回数を制限する。また、発呼者５８１０はＣＰＯ条件に従って一以上の通話を完了する義務があるため、本発明の拘束性は最低価格を単につきとめるために発呼者５８１０がＣＰＯを提出するのを思いとどまらせる。代替的な実施例においては、少なくとも一の通信業者５８２０がＣＰＯを承諾したときに通話が完了しなければ、発呼者５８１０は料金又は罰金を課されることができ、又は、ＣＰＯ管理システム５８００は、発呼者５８１０が当該ＣＰＯに対応する一以上の通話を完了する見込みに関する情報を含む発呼者５８１０の信頼度を評価することができる。適切な信頼度システムのより詳細な説明は、１９９７年３月４日に出願され、本発明の譲受人に譲渡されここで参照して結合される米国特許出願番号第０８／８１１，３４９号、発明の名称「航空会社価格問合せ方法及びシステム」を参照のこと。ある実施例においては、評価された信頼度は、顧客５８１０の購入申込に対する完了通話率から構成される。このようにして、通信業者５８２０は、通信業者が発呼者の申込を承諾するならば発呼者５８１０は、通信業者の基底レベルの価格弾力性を確認するためにその情報を利用せず、通話を完了することを確信することができる。
【０３５１】
図６０は、例示的なＣＰＯ管理中央サーバー６０００の構築を示すブロック図である。ＣＰＯ管理中央サーバー６０００は、中央演算処理装置（ＣＰＵ）６００５、ランダムアクセスメモリ（ＲＡＭ）６０１０、リードオンリメモリ（ＲＯＭ）６０２０、クロック６０２５、データ記憶装置６０３０及び通信ポート６０４０等ある標準ハードウェアコンポーネントを好ましくは含んでいる。ＣＰＵ６００５は、図６０に示すように、リストされた他の要素の各々に、共有データバス又は専用接続により、好ましくはリンクされている。ＣＰＵ６００５は、インテルのペンティアム(R)１００ＭＨｚ  Ｐ５４Ｃマイクロプロセッサ、モトローラの１２０ＭＨｚ  ＰｏｗｅｒＰＣ  ６０４マイクロプロセッサ又はサンマイクロシステムの１６６ＭＨｚ  ＵｌｔｒａＳＰＡＲＣ−１マイクロプロセッサ等の単一の商業的に入手可能な処理装置として具体化されることができる。代替的に、ＣＰＵ２２０５は、協同動作する幾つかの処理装置として具体化されてもよい。
【０３５２】
ＲＯＭ６０２０及び／又はデータ記憶装置６０３０は、図６５及び図６６に関連して更に説明するように、ＣＰＵ２２０５が検索、解釈及び実行するように動作することができる一以上の命令を格納するように動作することができる。例えば、ＲＯＭ６０２０及び／又はデータ記憶装置６０３０は、発呼者５８１０と交換通信業者５８２０−５８２４との間で、要求された支払い、課金、デビットの移転を実行するための処理を好ましくは格納している。
【０３５３】
ＣＰＵ６００５は、制御ユニットと、算術論理ユニット（ＡＬＵ）と、スタック可能なキャッシュや複数のレジスタなどＣＰＵローカルメモリ記憶装置とを既知の方法で好ましくは有している。制御ユニットはデータ記憶装置６０３０又はＲＯＭ６０２０から命令を検索するように動作することができる。ＡＬＵは、命令実行に必要な複数の動作を実行するように動作することができる。ＣＰＵローカルメモリ記憶装置は、一時的な結果と制御情報を格納するのに使用される高速記憶装置を与えるように動作することができる。
【０３５４】
図６１乃至図６４に関連して以下に更に説明するように、データ記憶装置６０３０は顧客データベース６１００、通信業者データベース６２００、料金データベース６３００及びＣＰＯデータベース６４００を有している。顧客データベース６１００は、ＣＰＯ管理システム５８００の各顧客に関する履歴情報や各顧客にサービスを提供している市内電話会社の表示を含む情報を好ましくは格納している。通信業者データベース６２００は、発呼者に長距離電話サービスを提供するために、ＣＰＯ管理システム５８００に登録されている各通信業者に関する住所情報を含む情報を好ましくは格納している。料金データベース６３００は、通信業者データベース６２００が識別する各通信業者の公表料金情報を好ましくは格納している。最後に、ＣＰＯデータベース６４００は、好ましくは、ＣＰＯの条件と関連ステイタスを含むＣＰＯ管理システム２１００が処理する各ＣＰＯの記録を含んでいる。
【０３５５】
ＣＰＯ管理システム５８００が所与のＣＰＯを承諾又は拒否することを、ＣＰＯ管理システム５８００にその権限を委託したある代理店ベースの交換通信業者５８２０の代わりに、可能にするＣＰＯ管理システム５８００が代理業的特徴を与える実施例においては、ＣＰＯ管理中央サーバー６０００は、ＣＰＯ規程を格納するＣＰＯ規程データベース（図示せず）を好ましくは含んでいる。ＣＰＯ規程は、各ＣＰＵ規程に含まれている機密性の高い情報の完全性と秘匿性を維持するために、機密保持データベースに格納されることができる。
【０３５６】
また、データ記憶装置６０３０は、図６５ａ及び図６５ｂに関連して以下に説明するＣＰＯ管理処理６５００と、図６６ａ及び図６６ｂに関連して以下に説明するＩＶＲＵ処理６６００を含んでいる。一般に、ＣＰＵ管理処理６５００は、各ＣＰＯを発呼者５８１０から受信し、そのＣＰＵを各適当な交換通信業者５８２０に与え、その後、いずれかの交換通信業者５８２０が申込条件を承諾したどうかを決定する。ＩＶＲＵ処理６６００は、発呼者５８１０からＣＰＵパラメータを受信するために、ＣＰＵ管理処理６５００によって好ましくは開始される。
【０３５７】
通信ポート６０４０は、ＣＰＵ管理中央サーバー６０００を加入者交換オペレータ５８５０と交換通信業者５８２０−５８２４に接続する。通信ポート６０４０は、複数接続を同時設定する多重通信チャネルを好ましくは有している。
【０３５８】
データベース
図６１は、ＣＰＯ管理システム５８００の各顧客（発呼者）に関する履歴情報や各顧客にサービスを提供している市内電話会社の表示を含む情報を好ましくは格納している例示的顧客データベース６１００を示している。顧客データベース６１００は、異なる顧客に各々関連付けられた記録６１０５−６１２５等の複数の記録を保存している。フィールド６１４０にリストされた各顧客の名前毎に、顧客データベース６１００は、顧客の住所をフィールド６１４５に、顧客が拘束される方法をフィールド６１５０に、顧客にサービスを提供している市内電話会社表示をフィールド６１５５に、顧客電話番号をフィールド６１６０に含んでいる。フィールド６１６０に格納されている電話番号は、例えば、顧客に関連する以前の取引履歴データベース（図示せず）にインデックを付す顧客識別子として利用することができる。
【０３５９】
フィールド６１５０に示すように、所与の顧客は、承諾している交換通信業者５８２０が発呼者の電話明細書に所与の通話に対して発呼者５８１０に課金することができるファイルの事前に存在している書面又は電子契約若しくはクレジットカードその他の汎用口座への課金によって、拘束されることができる。以下に説明するように、発呼者５８１０は、承諾している交換通信業者５８２０の代わりにＣＰＯ管理システム５８００又は加入者交換オペレータ５８５０によって又は承諾している交換通信業者５８２０によって直接に、本発明に従って完了した通話に対して従来の方法で請求されることができる。
【０３６０】
例えば、ＣＰＯが発呼者５８１０に所定期間最低限の使用することを義務付ける実施例においては、発呼者５８１０が最低料金を得るために１２ヶ月で少なくとも２００ドル費やすことに合意した場合、その条件に対する合意はクレジットカードに直ちに又は月別で課金されることができる。また、クレジットカードは、発呼者５８１０がＣＰＯ義務違反でなければ、課金されることができない。例えば、発呼者５８１０は課金を受けると、通話に対して直接に請求書を発行されることができ、合意した条件の終わりに残りの残高がクレジットカード口座に課金されることができる。また、発呼者５８１０は、交換通信業者５８２０がＣＰＯを承諾した後に発呼者５８１０が通話完了に合意しない場合には、罰金を課されることができる。
【０３６１】
図６２は、長距離電話サービスを発呼者に与えるために、ＣＰＯ管理システム５８００に登録されている各通信業者に関する住所情報を含む情報を好ましくは格納している例示的な通信業者データベース６２００を示している。通信業者データベース６２００は、異なる通信業者に各々関連付けられた記録６２０５−６２２５等の複数の記録を保存している。フィールド６２４０にリストされた各通信業者名毎に、通信業者データベース６２００は住所情報をフィールド６２４５に含んでいる。また、所与の通信業者のＣＰＯ規程が暗号形式で格納されている実施例においては又は機密保持送信が要求されているその他の場合には、関連通信業者の暗号キーが好ましくは通信業者データベース６２００のフィールド６２５０に格納される。最後に、通信業者データベース６２００は、それぞれの通信業者が現実に承諾した各通信業者に提供されたＣＰＯの割合表示をフィールド６２５５に好ましくは格納している。このようにして、ＣＰＯ管理システム５８００はＣＰＯ承諾率に従ってランク付けされた順番で特定のＣＰＯを通信業者に提供している。代替的な実施例においては、通信業者データベース６２００は、（ｉ）各通信業者によって交渉された優先権又は（ｉｉ）ＣＰＯ管理システム５８００に通信業者から支払われた最高委託料に基づく順番に従ってＣＰＯの処理を容易にするためにフィールドを結合することができる。
【０３６２】
図６３は、通信業者データベース６２００が識別する各通信業者毎の公表料金情報を好ましくは格納している例示的な料金データベース６３００を図示している。料金データベース６３００は、異なる通信業者の各々に関連付けられている記録６３０５−６３２５等の複数の記録を保存している。フィールド６３４０で識別されている各通信業者毎に、料金データベース６３００は、対応国内料金と国際料金をフィールド６３４５及び６３５０のそれぞれに好ましくは含んでいる。
【０３６３】
図６４は、ＣＰＯの条件と関連ステイタスを含む、ＣＰＯ管理システム５８００が処理している各ＣＰＯの記録を好ましくは含んでいる例示的ＣＰＯデータベース６４００を示している。ＣＰＯデータベース６４００は、システム５８００が処理している異なるＣＰＯに各々関連付けられている記録６４０５−６４２５等の複数の記録を保存している。フィールド６４４０のＣＰＯ番号によって識別されている各ＣＰＯ毎に、ＣＰＯデータベース６４００は、ＣＰＯがフィールド６４４５に受信された日付、ＣＰＯに関連付けられた顧客の識別（ＩＤ）番号をフィールド６４５０に、着呼電話番号表示をフィールド６４５５に含んでいる。発呼者のＣＰＯのパラメータはＣＰＯデータベース６４００のフィールド６４６０に格納されている。ＣＰＯデータベース６４００は、発呼者がその通話に対して支払うことを了解している価格をフィールド６４７０に好ましくは格納している。フィールド６４６５は、一旦承諾されると承諾している通信業者を表示し、フィールド６４７５は、継続中、承諾又は満了など現在のそれぞれのＣＰＯステイタスを記録する。
【０３６４】
処理
上述したように、ＣＰＯ管理中央サーバー６０００は図６５ａ及び図６５ｂに示すＣＰＯ管理処理６５００を好ましくは実行し、発呼者５８１０から各ＣＰＯを受信し、そのＣＰＯを適当な交換通信業者５８２０の各々に与え、その後、交換通信業者５８２０が申込条件を承諾したかどうかを決定する。図８ａに示すように、ＣＰＯ管理処理６５００は発呼者からの呼を、例えば、ＣＰＯ管理システム５８００の構内交換機（ＰＢＸ）スイッチを介して受信すると、ステップ６５０５で本発明の原理を具体化する処理を開始する。
【０３６５】
その後、ステップ６５１０で、ＣＰＯ管理処理６５００は、着呼に関連付けられた自動番号識別（ＡＮＩ）番号を抽出する。ステップ６５１５で顧客データベース６１００にその後抽出されたＡＮＩ番号をフィールド６１６０に記録された顧客識別子として利用して新しい記録が形成される。その後、図６６ａ及び図６６ｂに関連して以下に説明するＩＶＲＵ処理６６００又は別の顧客インターフェース処理がステップ６５２５で好ましくは実行され、着呼者５８３０の電話番号、最高価格、ＣＰＯ拘束方法及び時間的制限その他の適用可能な制限を含むＣＰＯパラメータを発呼者５８１０から受信する。受信されたＣＰＯパラメータはステップ６５３０でＣＰＯデータベース６４００に格納され、顧客識別子（ＡＮＩ）によってインデックスが付され、ステップ６５３５で適当な通信業者に与えられる（図６５ｂ）。ＣＰＯ管理システム５８００は、例えば、発呼者５８１０と所望の着呼者５８３０間で呼を発送することができる通信業者にＣＰＯを与えることによってのみ、又は、ＣＰＯを発呼者５８１０が指定した通信業者に与えることによってのみ、各通信業者に与えられたＣＰＯをフィルタすることができることに留意する必要がある。同様に、ステップ６５３０で、ＣＰＯ管理処理６５００は代理店ベースの通信業者が与えるＣＰＯ規程に対してＣＰＯを好ましくは評価することに更に留意する必要がある。
【０３６６】
ステップ６５４０で各通信業者からＣＰＯに対する応答が好ましくは受信される。その後、ステップ６５４５で通信業者がＣＰＯ条件を承諾したかどうか決定するテストが行われる。ＣＰＯ条件を通信業者が承諾していないとステップ６５４５で決定されると、発呼者５８１０はステップ６５５０でＣＰＯが拒否された旨を好ましくは通知される。プログラム制御がステップ６５６０で終了する前に、ＣＰＯデータベース６４００におけるＣＰＯステイタスはその後ステップ６５５５で「拒否」に変更される。
【０３６７】
しかし、通信業者がＣＰＯ条件を承諾したとステップ６５４５で決定されると、ＣＰＯデータベース６４００から全顧客記録が好ましくは承諾している通信業者にステップ６５７０で与えられ、通信業者はそのＣＰＯが特定する条件に従って通話を終了することができる。発呼者５８１０は、承諾している交換通信業者５８２０の代わりにＣＰＯ管理システム５８００又は加入者交換オペレータ５８５０によって若しくは承諾している交換通信業者５８２０によって直接に、その通話に対して従来の方法で請求されることができることに留意する必要がある。加入者交換オペレータ５８５０は典型的に全通話終了費用の歩合を受け取る。最後に、プログラム制御がステップ６５８０で終了する前に、ＣＰＯデータベース６４００のＣＰＯのステイタスは、その後、ステップ６５７５で「承諾」に変更される。
【０３６８】
上述したように、ＣＰＯ管理処理６５００は、ステップ６５２５で、図６６ａ及び６６ｂに示すＩＶＲＵ処理６６００を好ましくは実行して、着呼者５８３０の電話番号、最高価格、時間制限その他の適用可能な制限を含むＣＰＯパラメータを発呼者５８１０から受信する。図６６ａに示すように、ＩＶＲＵ処理６６００は、発呼者５８１０に着呼者５８３０の電話番号を促すことによって本発明の原理を具体化する処理をステップ６６１０で開始する。その後、対話型音声応答ユニット（ＩＶＲＵ）は発呼者５８１０の応答をステップ６６２０で捉え、ＣＰＵ６００５に着呼される番号を与える。
【０３６９】
ＩＶＲＵは、その後ステップ６６３０で、発呼者５８１０に発呼者５８１０がその通話に対する希望支払価格と、クレジットカード口座への課金などのＣＰＯ拘束方法を促し、応答をステップ６６４０で捉えてその通話に対する最高価格をＣＰＵ６００５に与える。その後、ＩＶＲＵは、発呼者５８１０に、例えば、その通話に対する時間制限、一以上の好ましい通信業者があればそれを、ＣＰＯが係属すべき期間制限を含むＣＰＯに関連するその他の制限又は明細をステップ６６５０で促す。ＩＶＲＵは、その後ステップ６６６０で、発呼者５８１０の応答を捉え、追加制限又は明細をＣＰＵ６００５に与える。最後に、ＩＶＲＵ処理６０００は、プログラム制御がステップ６６８０で終了する前に、発呼者５８１０に受話器をおいて応答を待つようステップ６６７０で命令する（図６６ｂ）。
【０３７０】
このようにして、ＣＰＯ管理システム５８００はＣＰＯ制限を受信し、その後、各適当な交換通信業者５８２０に与える。承諾されれば、交換通信業者５８２０はＣＰＯ条件に従って発呼者５８１０と所望の着呼者５８３０との間の通話を終了し、発呼者５８１０は通話費用を承諾している交換通信業者５８２０に支払う義務を負う。
【０３７１】
図５８Ａに示す実施例においては、着呼者５８３０へ発呼することを希望する発呼者５８１０は電話機５９００を取り上げ、ＣＰＯ管理システム５８００に関連付けられた電話番号をダイアルする。ＰＢＸ又は関連通話処理装置がその呼を好ましくは受信する。発呼者５８１０の電話番号は、その後、通話情報から抽出され、顧客データベース６１００にアクセス又は記録作成するのに使用される。発呼者５８１０は、その後、着呼される番号と最大費用などの発呼者のＣＰＯ条件を提出するために、ＩＶＲＵ又は生きたオペレータのどちらかに接続される。発呼者は、その後、受話器を置いて応答を待つように好ましくは命令される。
【０３７２】
ＣＰＯ管理システム５８００はＣＰＯを一旦受信処理すると、それを複数の通信業者に与える。各通信業者５８２０−５８２４は、その後、そのＣＰＯの承諾又は拒否を、例えば、ネットワーク容量バランスに基づく一以上の規程に基づいて決定する。ＣＰＯが承諾されると、ＣＰＯ管理システム５８００又は承諾している通信業者５８２０は買主に通知し、承諾している通信業者のネットワークで発呼する。その呼に関連する時間制限その他の制限が存在すれば、発呼者５８１０はその呼が最初に設定された時に好ましくは通知される。発呼者５８１０はその呼に対して、例えば、ＣＰＯ管理システム５８００、承諾している通信業者５８２０又は加入者交換５８５０を操作している市内電話会社によって、請求されることができる。このようにして、呼は、クレジットカードなどの汎用口座に個別的に課金されたり、発呼者の従来の電話請求によって支払われたりすることができる。
【０３７３】
同様に、図５８Ｂに示す実施例においては、所定期間の電話サービスに対してＣＰＯを提出することを希望する発呼者５８１０は、加入者端末５８１５を利用してＣＰＯ管理システム５８００と連絡をとることができる。例えば、ＣＰＯは、割引料金のお返しに、オフピーク時間や最低消費義務など、発呼者が厳守することを了解する弾力性又は制限と共に、加入者が電話サービスに対して支払うことを了解する料金と契約義務の範囲を特定することができる。
【０３７４】
一旦ＣＰＯがＣＰＯ管理システム５８００によって受信されて処理されると、ＣＰＯは、その後、複数の通信業者に与えられる。各通信業者５８２０−５８２４は、その後、そのＣＰＯを承諾するか拒否するかを決定する。そのＣＰＯが承諾されると、ＣＰＯ管理システム５８００又は承諾している通信業者５８２０は、買主に通知をして、発呼者に対する長距離プロバイダーを承諾している通信業者５８２０に適当な方法で切り換える。
【０３７５】
イベントチケットに対するＣＰＯ管理システム
本発明の別の実施例を以下図６７乃至７３ｇを参照して説明する。図６７乃至図７３に示す実施例よれば、買主は、ホッケーの試合等あるイベントのチケットに対して保証された購入申込を何人かの潜在的売主に提供することができる。売主は、その申込を検討して条件に合意可能であればその申込を承諾する。従って、買主は、安全便利な方法で配達されることが保証されているチケット購入申込をすぐに提出することができる。
【０３７６】
図６７−７２ｂを参照するに、本発明の装置と方法の一実施例のシステム構築が示されている。図６７に示すように、本発明の装置は、一般に、開催地制御装置７０００、中央制御装置６８００、クレジットカード処理装置６８３０及び遠隔ユーザー端末６９００を有している。遠隔ユーザー端末６９００は、ネットワーク６８４５を介して中央制御装置６８００に接続されている。
【０３７７】
上述したコンポーネントを使用して、本発明の実施例は、中央制御装置がイベントチケットの購入販売を容易に行うことができる方法と装置を提供している。特に、中央制御装置６８００は、特定イベントに対するチケット購入申込を受信掲載する。かかる申込は、例えば、クレジットカード口座のクレジット限度額を利用して保証されている。中央制御装置６８００は、更に、複数の潜在的売主に各申込が利用可能なようにして、売主が申込を承諾することを可能にし、これにより、法律的に拘束力のある契約を形成している。
【０３７８】
図６８に示すように、中央制御装置６８００は、中央演算処理装置（ＣＰＵ）６８０５と、欄段アクセスメモリ（ＲＡＭ）６８１５と、リードオンリメモリ（ＲＯＭ）６８２０と、クロック６８３５と、入出力（Ｉ／Ｏ）ポート６８５５と、データー記憶装置６８５０とを有している。データ記憶装置６８５０は、それぞれ図７１ａ乃至７１ｅを参照してより詳細に説明するイベント表７１００と、開催地表７１２０と、顧客表７１３０と、申込表７１５０と、取引表７１８０とを含むメモリ装置である。
【０３７９】
図７１ａは、図６７のシステムを利用してチケットが再販売可能なイベントに関する場所と予定情報とを含む情報を好ましくは格納している例示的なイベント表７１００を示している。イベント表７１００は、異なるイベントに関連付けられている記録７１１４等の複数の記録を保存している。イベントＩＤフィールド７１０２にリストされる各イベント識別子毎に、イベント表７１００は、フィールド７１０４に格納されているイベント種類コードと、フィールド７１０６に格納されているイベント説明を含んでいる。フィールド７１０４に格納されているイベント種類コードはイベント形式を表しており、例えば、ナショナル・ホッケー・リーグの試合は「ＮＨＬ」と示されている。フィールド７１０６に格納されているイベント説明は特定のイベントを説明している。
【０３８０】
また、イベント表７１００は、フィールド７１０６に格納されている開催地ＩＤを好ましくは含んでいる。フィールド７１０６に格納されている開催地ＩＤは、例えば、図７１ｂを参照してより詳しく説明する開催地表７１２０にインデックスを付すのに利用される。図７１ａに示すように、イベント表７１００に格納されている各記録は、フィールド７１１０に格納されている日付とフィールド７１１２に格納されている時間とを含んでいる。フィールド７１１０及び７１１２の日付と時間は、それぞれ、記録に関連付けられたイベントの開始時間を表している。この表に格納されている情報は、プロモータ、開催地、潜在的な買主及び売主を含む多くの情報源から中央制御装置６８００に与えられることができる。
【０３８１】
図７１ｂは、例示的な開催地表７１２０を示している。記録７１２８等の開催地表７１２０の各記録は、開催地に関連してこれを説明するデータを好ましくは格納している。開催地表７１２０は、独自の開催地識別子を格納しているフィールド７１２２によって好ましくはインデックスされている。開催地表７１２０は、映画館、劇場又はスタジアムの名前をフィールド７１２４に、住所をフィールド７１２６に更に格納している。
【０３８２】
図７１ｃは、電子チケット販売システムによって登録されている各顧客に関する情報を好ましくは格納している例示的な顧客表７１３０を示している。顧客データベース７１３０は、異なる顧客に各々関連付けられている記録７１４６及び７１４８等の複数の記録を保存している。顧客表７１３０に登録されている顧客はチケットを購入し、チケットを販売し、又は、チケットを売買する。顧客表７１３０は、各顧客毎に独自の顧客識別子をフィールド７１３２に、名前と住所情報をフィールド７１３４及び７１３６に格納している。好ましくは、顧客表７１３０に保存されているデータは顧客が独自の顧客識別子を割り当てられる登録処理中に顧客によって与えられる。
【０３８３】
顧客表７１３０は顧客クレジットカードデータを更に格納している。顧客クレジットカード番号はフィールド７１３８に格納されている。顧客クレジットカードの満了日はフィールド７１４０に格納され、カード保持者名はそれがクレジットカードに現れるとフィールド７１４２に格納される。
【０３８４】
図７１ｄは、本実施例のチケット販売システムを利用して掲載された申込に関する情報を好ましくは格納している例示的な申込表７１５０を示している。申込表７１５０は、チケット売買申込に各々関連付けられた記録７１７０及び７１７２等の複数の記録を保存している。申込表７１５０の各記録は、申込が掲載されると中央制御装置６８００が割り当てるフィールド７１５１に格納されている独自の申込識別子を含んでいる。申込表７１５０の各記録は、申込を行う顧客、申込条件、申込を承諾する顧客及び申込に関係する管理情報を識別するフィールドを含んでいる。
【０３８５】
申込を行う顧客の顧客識別子はフィールド７１５２に格納されている。申込を行う顧客に関する情報は、フィールド７１５２の顧客識別子を顧客表７１３０へのインデックスとして利用して簡単に入手することができる。申込表７１５０の中の各記録はフィールド７１５３にイベント識別子を更に格納している。イベント識別子は申込チケットに関係するイベントを表している。イベント情報はフィールド７１５３のイベント識別子を利用してイベント表７１００へのインデックスとして簡単に入手することができる。
【０３８６】
申込表７１５０の各記録は、申込がなされた日付と、申込が承諾された最終日をそれぞれ格納しているフィールド７１５４及び７１５５を更に含んでいる。申込の種類と申込のステイタスを示すデータもフィールド７１５６及び７１５７の申込表７１５０の各記録に格納されている。フィールド７１５６は、申込が一以上のチケットを購入する申込か販売する申込かを表示するコードを格納している。フィールド７１５７は、申込のステイタスを示すコードを格納している。申込のステイタスは、係属中、アクティブ、満了及び履行を含むことができる。
【０３８７】
申込表の各記録のフィールド７１５８は申込が適用される座席数を格納している。申込に関連する座席の場所を識別するデータはフィールド７１５９−７１６４を埋める。申込がある範囲の座席の場所を要求している場合には、フィールド７１５９−７１６１に格納されているデータが最初の座席をある範囲で識別するのに使用され、フィールド７１６２−７１６４に格納されているデータが最後の座席をある範囲で識別するのに使用される。フィールド７１６５は座席毎の価格を格納している。
【０３８８】
また、申込表７１５０の各記録はフィールド７１６６−７１６９に管理データを含んでいる。フィールド７１６６に格納されているデータは申込をサポートする許可クレジット額を格納している。一旦申込が承諾されると、フィールド７１６７は、図７１ｅを参照してより完全に説明する取引表７１８０へのインデックスとして使用されることができる取引識別子を格納している。申込表７１５０の各記録は、選択的に、関連又はリンクされた申込記録の申込識別子を表している。ポインターはフィールド７１６８に格納されて、申込表７１５０に次の関連記録の申込識別子を表している。最後に、申込表７１５０の各記録のフィールド７１６９は、売主が販売しようとしている原チケットの一以上の通し番号を格納している。
【０３８９】
一旦申込が承諾されると、中央制御装置６８００は取引記録を取引表７１８０に加える。図７１ｅは、各承諾された申込に関する情報を好ましくは格納している例示的な取引表７１８０を示している。各承諾された申込は、取引表７１８０のフィールド７１８１と申込表７１５０のフィールド７１６７に格納されている独自の取引識別子を割り当てられる。申込表７１５０の関連記録の申込識別子はフィールド７１８２に格納されている。この申込識別子は、取引記録に関連付けられた申込に関する情報を検索するために申込表７１５０へのインデックスとして利用されることができる。
【０３９０】
取引表７１８０の各記録は関連申込が承諾された日付を格納しているフィールド７１８３と、取引合計値を格納しているフィールド７１８４とを好ましくは更に含んでいる。フィールド７１８５は、買主のクレジットカードに課される額を格納している。フィールド７１８６は承諾を支持するために保全された売主のクレジット限度額を格納している。フィールド７１８７は取引処理に対して課金される料金を格納している。取引表７１８０の各記録はフィールド７１８８にチケットが制御装置６８００のオペレータが受信した日付を表す日付も格納している。
【０３９１】
売主の顧客識別子はフィールド７１８９に、チケット識別データはフィールド７１９０及び７１９４に格納されている。フィールド７１９０は原チケット番号を格納しており、フィールド７１９４は新しいチケット番号を格納している。新しいチケット番号は、再販売されたチケットから原チケットを区別するために、そして、チケット保持者間の潜在的衝突の効率的解決を促進するために割り当てられる。
【０３９２】
選択的に、中央制御装置６８００は、中央処理装置６８００が様々な時にユーザーに送受信した形式契約条項を含んでいる契約詳細表（図示せず）を含むことができる。例えば、契約表は、買主に送信されて保証された購入申込に結合された契約条項を含むことができる。契約表は、買主の申込を拘束して法律的に拘束力のある契約を形成する彼の意思の承認を要求する前に、売主に送信された契約条項を含むことができる。これらの形式条項は効果的に買主が特定した条件の溝を埋め、この性質の殆どの契約に共通の包括契約詳細事項を特定している。
【０３９３】
以下、図６９を参照して、遠隔ユーザー端末６９００を詳細に説明する。遠隔ユーザー端末６９００は、顧客が中央制御装置６８００にアクセス可能なパーソナルコンピュータ、スクリーンホン、スタンドアロン売店その他の装置であることができる。遠隔ユーザー端末６９００は、一般に、遠隔ユーザー端末６９００の動作を制御する中央演算処理装置（ＣＰＵ）６９０５を含んでいる。ＣＰＵ６９０５は、ランダムアクセスメモリ（ＲＡＭ）６９１５、リードオンリメモリ（ＲＯＭ）６９２０、入出力ポート６９２５、クロック６９３５、通信ポート６９４０及びデータ記憶装置６９６０に電子的に接続されている。ＣＰＵ６９０５は、入出力ポート６９２５とキーボードなどの入出力装置６９４５で遠隔ユーザーから入力を受信する。ＣＰＵ６９０５は、入出力ポート６９２５とビデオモニタ６９３０を介して出力を遠隔ユーザーに送信する。更に、通信ポート６９４０は、ネットワーク６８４５に通信パスを与えている。最後に、データ記憶装置６９６０は、中央制御装置インターフェースソフトウェア６９６５を含むメモリ装置である。
【０３９４】
以下、図７０を参照して、開催地制御装置７０００を詳細に説明する。開催地制御装置７０００は、一般に、開催地制御装置７０００の動作を制御する中央演算処理装置（ＣＰＵ）７０１０を含んでいる。ＣＰＵ７０１０は、ランダムアクセスメモリ（ＲＡＭ）７０２０、リードオンリメモリ（ＲＯＭ）７０３０、クロック７０４０、中央制御装置６８００に通信パスを与える通信ポート７０５０及びデータ記憶装置７０６０に電子的に接続されている。データ記憶装置７０６０は、チケット表７２１０と交換チケット表７２３０を含むパーシステントメモリ装置である。開催地制御装置７０００は、入力データを受信する入出力装置７０８０とオペレータに情報を提供又は表示する出力装置７０７０を更に含んでいる。
【０３９５】
図７２ａは、特定の開催地の様々な座席に対して発行されたチケットに関する情報を好ましくは格納している例示的なチケット表７２１０を示している。各チケットは、発行前に開催地制御装置７０００がそれに割り当てた特定のチケット番号を有している。チケット表７２１０の各記録はチケットが有効なイベントを識別するフィールド７２１１と、イベントに対して発行された各チケットに割り当てられた番号を識別するフィールド７２１２と、劇場の座席の場所を表す（即ち、セクション、列、席のそれぞれ）フィールド７２１４−７２２０を好ましくは含んでいる。チケット表７２１０は、開催地、イベント又は座席に特定のその他の情報を表すフィールドも含んでいる。
【０３９６】
図７２ｂは、無効となって交換チケット番号が割り当てられた原チケット番号に関連したデータを好ましくは格納している例示的な交換チケット表７２３０を示している。交換チケット表７２３０は、中央制御装置６８００が再販売したチケット番号をフィールド７２３２に格納し、交換チケット番号をフィールド７２４２に格納している。チケット表７２３０の各記録はイベント識別子を格納しているフィールド７２３１と買主識別子を格納しているフィールド７２４０とを更に含んでいる。
【０３９７】
本発明は、例示された分散処理構築なしに構成されて動作されることができることを当業者は理解するであろう。開催地とチケット分配者がそのように望めば、中央制御装置６８００は、開催地制御装置７０００の全て又は一部のデータベースを結合することができ、本実施例の開催地制御装置７０００によって実行された処理ステップの全て又は一部を行うことができるだろう。かかる代替的な実施例においては、データ処理及びデータ格納は中央集権化されることができ、開催地はデータを従来の遠隔端末又はワークステーションを使用して適当にアクセスすることができる。
【０３９８】
本発明の一実施例においては、潜在的な買主と売主との間の通信はインターネットなどの電子又はディジタルネットワークを介して、ユーザーがパーソナルコンピュータによってアクセス又は「ログイン」することができるインターネットウェブサイトをホストしている中央制御装置６８００との間に生じる。ユーザーは音声応答ユニット（ＶＲＵ）にリンクされた従来の電話線他の通信リンクを介して中央制御装置にアクセスすることができることに留意することが重要である。
【０３９９】
チケット再販売サービスを使用するために、潜在的買主であるユーザーはネットワーク６８４５を介して中央制御装置６８００にログオンして保証された購入申込を作成、提出し、そのネットワーク６８４５との接続を切断する。一の実施例においては、保証された購入申込は、事前許可されたクレジットカード取引によって裏書されたチケットを購入するように法律的に拘束力のある申込である。申込を受け取ると中央制御装置６８００は、買主が有効なクレジットカード口座及び／又は要求されたチケットを支払うのに十分なクレジットを有していることを確信するために、買主のクレジットカード発行者に連絡をとる。保証された購入申込は、中央制御装置６８００にリンクされたウェブサイトを使用してその申込を掲載することによって、その後、潜在的売主に入手可能にされる。「アクティブ」な申込が満了していないことを確信するために中央制御装置６８００は定期点検を実行する。潜在的売主は、申込をブラウズして望ましい申込の電子承諾を提出するのに本発明のシステムを利用することができる。潜在的売主による承諾は電子的に中央制御装置６８００に送信される。中央制御装置６８００は承諾を処理して、不履行に対する潜在的罰金をカバーするのに十分なクレジットがあることを確信するために売主のクレジットカード発行者と連絡をとる。売主のクレジットに対するこの保全は当事者間の信頼を促進するためのものであり、これによって取引を保護する。利用可能なクレジットを確認した後、両当事者には拘束力のある取引が通知され、チケットは電子的に無効にされて交換チケット番号が割り当てられる。その後、売主は無効チケットを引き渡すように求められる。これはそれらを開催地に戻すことによって履行されることができ、又は、売主はチケットを中央制御装置６８００のオペレータに郵送することができる。引き渡されたチケットを受け取ると、中央制御装置６８００のオペレータはチケット販売ユーザーへの支払移転を指図する。
【０４００】
図７３ａを参照して、ユーザーがシステムにログオンしてそのシステムの使用を開始するする処理を説明する。ステップ７３００に示すように、遠隔端末６９００を操作するユーザーはネットワーク６８４５を介して中央制御装置６８００との接続を設定する。ユーザーは、チケットの保証された購入申込を出すことを希望する潜在的な買主か、チケット申込の検討を希望する売主のどちらかである。
【０４０１】
ステップ７３０２で、中央制御装置６８００はユーザーから顧客ＩＤを要求する。ステップ７３０４で、中央制御装置６８００は、ユーザーが既に顧客ＩＤを有しているかどうかに基づいて進行方法を決定する。ユーザーがこのサービスに登録されて彼の顧客ＩＤを覚えていれば、彼は彼の顧客ＩＤを中央制御装置６８００にステップ７３１２で送信し、処理はステップ７３１４に続く。
【０４０２】
他方、ユーザーがサービスに登録されていないか彼の顧客ＩＤを覚えていないと、彼は否定的応答をステップ７３０４で提出して関連顧客情報を中央制御装置６８００にステップ７３０６に示すように提供する。ステップ７３０８で、中央制御装置６８００は、受信した顧客情報に基づいて顧客の記録を形成する。名前、住所、クレジットカード番号、満了日及び名前を含むこの情報は、クレジットカードに現れるように、顧客表７１３０に格納される。ステップ７３１０で、中央制御装置６８００は、ユーザーが与えた情報を既に顧客表７１３０に格納されている情報と比較する。一致が発見されれば中央制御装置６８００は、顧客ＩＤを顧客表７１３０のフィールド７１３２から受信して顧客ＩＤ番号をユーザーに送信する。このサービスは、所与の情報を以前に与えたがその顧客ＩＤを思い出せないユーザーに対して与えられる。一致がなければ、中央制御装置６８００は新しい顧客ＩＤをユーザーに割り当てて、顧客表７１３０のフィールド７１３２にそれを格納し、それをユーザーに送信する。
【０４０３】
ステップ７３１４で、ユーザーは保証された購入申込の提出を希望するか、潜在的売主からの申込の検討を希望するかを表示する。申込提出に関連した処理ステップを図７３ｂ−７３ｃを参照してより詳しく説明する。代替的な実施例においては、ユーザーはあるイベントに対するチケットの入手可能性を潜在的買主に広告することを選択することができる。更に、ユーザーは、申込提出前に、正当価格がどのくらいであるかについてのより良い理解を得るために、かかる広告の検討を選択することができる。
【０４０４】
図７３ｂ及び図７３ｃは、保証された購入申込を提出するために、ステップ７３１４のユーザー選択後に行われる処理ステップを示している。ステップ７３１６で、中央制御装置は、一般開催地とイベント情報をユーザーに表示するためにユーザー端末６９００に送信する。例えば、ある実施例においては、中央制御装置６８００は、ユーザーが出席を希望する特定イベントを正確に指摘するために、幾つかの選択肢をユーザーに与えることができる。ユーザーは特定イベントを直接要求することができるし、正しいイベントを最終的に発見するために狭める選択肢のグループを通じて進行する。例えば、ユーザーはイベント表７１００から幾つかのフィールドを識別するように求められることができる。与えられた情報量に依存して、イベントの選択は狭まる。例えば、ユーザーがイベントの種類（例えば、「ＮＨＬ」）だけを与えれば、中央制御装置６８００は、イベント表７１００を走査して、イベント種類フィールド７１０４で発見された全ての一致を与える。しかし、これは長いイベントリストであるので中央制御装置６８００は、リストを狭めるためにもっと情報を与えるようにユーザーに促す。ユーザーは、次いで、彼がさがしているイベントを発見ために狭いリストから選ぶことができる。例えば、ユーザーは、リストを狭めるために、特定ブロードウェイ製作の土曜マチネの劇だけを特定することができる。中央制御装置６８００は、その後、ユーザーに、イベント表７１００のフィールド７１０２からのイベントＩＤを含む正しいイベント情報を与える。ユーザーは、中央制御装置が申込表７１５０でトラッキング可能なように、このイベントＩＤを保証された購入申込の一部として含めることができる。
【０４０５】
次に、ステップ７３１８で、ユーザーは、イベントＩＤ番号に基づいて希望イベントを選択する。ステップ７３２０で、中央制御装置６８００は、
（１）  希望チケット番号
（２）  各チケットの価格
（３）  各チケットの希望の場所
（４）  選択的に、申込が有効とされる日付
などの申込に関連するある情報をユーザーから要求する。
【０４０６】
ユーザーは、チケットの特定の場所に基づいて、彼が好むチケットの番号と彼が費やすことを了解する価格を表示する。ユーザーは開催地のグラフィック表示を使用して彼が支払うことを了解する価格に対応する座席の正確な場所を選択することができる。例えば、（開催地表７１２０のフィールド７１２２に格納された）開催地ＩＤ番号に基づいて、中央制御装置６８００は、特定開催地の座席グラフィック表示をメモリから検索して遠隔ユーザー端末６９００でユーザーに与える。ある実施例では、中央制御装置６８００は、最初に、開催地全体（例えば、セクションによる表示）の広い一般的輪郭を与える。その後、ユーザーは、その正確な座席のサーチを狭めるために特定領域をクリックする。各連続的選択クリックにより、ユーザー端末６９００のディスプレイ画面はユーザーが希望する座席を発見するまで表示された座席の範囲を狭める。ユーザーは、その後、購入申込に対応する座席グループを選択することができる。中央制御装置６８００はフィールド７１５９−７１６４に選択された座席を格納する。ユーザーが特定座席の代わりに一のセクション又は多数のセクションを選択することを好めば、彼はある範囲の選択を入力することができる。中央制御装置６８００は、その後、セクションフィールド７１５９及び７１６２を使用して他の４つのフィールドを空にすることによってのみこの広い選択を格納することができる。
【０４０７】
更に、ユーザーは、申込が満了する日付を示すために終了日を与えることができる。上述したように、中央制御装置６８００は定期的にこの終了日を見直し、一旦その日が過ぎれば申込のステイタスを申込表７１５０のフィールド７１５７で「満了」に変更する。
【０４０８】
ステップ７３２２で、中央制御装置６８００は、ユーザーが送信した申込情報を受信することができ、ステップ７３２４に示すように、中央制御装置６８００は申込記録を申込表７１５０に形成する。ステップ７３２８で、ユーザーは追加申込を希望するかどうか質問される。この点で、ユーザーが別のイベント申込を希望すれば、彼はステップ７３１６−７３２４で説明されたのと同一の処理を行う。しかし、ユーザーが以前に提供された申込に関連又はリンクされた申込をしたいと思えば、以下のようにしてそのようにすることができる。まず、ある実施例では、彼らは同一のイベントＩＤをステップ７３１８で与える。次に、上述した同一の一般情報を提出した後で、ユーザーはこの申込がリンクされたことを表示する。中央制御装置は、その後、最初の申込用に形成されたその申込ＩＤ番号を関連申込のリンクＩＤ番号として割り当て、申込表７１５０のリンクＩＤフィールド７１６８に格納する。
【０４０９】
ユーザーは、希望座席の種類に基づいてリンクされた申込を提供することができるだろう。例えば、ユーザーは特定の開催地において「高品質」の座席番号を選択してより高い購入価格を申し込むことができる。リンクされた申込は、特定開催地に対しておそらくより低い購入価格を有する「低品質」の座席を含んでいる。従って、リンクＩＤに基づいて、潜在的売主はその検討中に両方の申込を検討することができる。
【０４１０】
同様に、ユーザーは、同一物と反対に、２つの別個のイベントに対する申込をリンクすることができる。例えば、座席の選択と価格に基づく申込をリンクする代わりに、ユーザーはその市内エリアの２つのイベントの両方ではなく１つに出席することを希望するかもしれない。従って、彼は、申込が「どちらか」の案に対して条件付けされたことを潜在的売主が気づくようにこれらの申込をリンクすることができる。
【０４１１】
中央制御装置６８００は、申込ＩＤ番号を申込ＩＤフィールド７１５１の各申込に割り当て、この番号をリンクＩＤフィールド７１６８のリンクされた申込に対するリンクＩＤ番号として割り当てる。同様に、申込日付フィールド７１５４は、申込が掲載されたときを示すタイムスタンプ（例えば、日時）で埋められる。次に、中央制御装置６８００は、その「係属中」の値をステイタスフィールド７１５７に割り当てる。この値はユーザーのクレジットカード発行者から許可を受領すると「アクティブ」に変わる。更に、中央制御装置６８００は、許可された額を計算して、それを許可額フィールド７１６６に格納する。許可額フィールドは、申込を「裏書」するために保全されたユーザーのクレジット額を表しており、取引総額に通常等しい。ユーザーのクレジットの一部を保全することによって、申込が承諾されればチケットの売主とチケットサービスは支払いを受け取ることが保証される。リンクされた購入申込の場合、許可額はリンクされた申込の最高取引額である。リンクされた申込が承諾されると、引き出される全関連申込を、システムは自動的に考慮する。最後に、中央制御装置６８００は、開催地のグラフィック表示に基づく座席の場所を含むユーザーが与えた全情報を申込表７１５０のそれぞれのフィールドに格納することができる。
【０４１２】
ステップ７３３０で、中央制御装置６８００は、契約詳細表（図示せず）から法律契約文言を抽出して、ユーザー端末６９００のユーザーに送信する。この文言は、保証された購入申込を提供することの法律関係を述べており、処理は書面契約を署名する前に条件を検討することと同様である。ユーザーがこれらの条件に拘束されないことを選択すれば、彼は申込を取り消すことができる。しかし、ユーザーがこれらの条件に拘束されることを選択すれば、ユーザーは肯定的承認を中央制御装置６８００に送信し、保証された購入申込の条件に法律的に拘束される。
【０４１３】
図７３ｃにおいて、中央制御装置６８００は、その後ステップ７３３２で、その申込に対する許可を受け取るためにユーザーのクレジットカード発行者に連絡をとる。まず、中央制御装置６８００は、顧客表７１３０からユーザーの名前、住所、クレジットカードの種類、クレジットカード番号及び満了日を、申込表７１５０からの顧客ＩＤに基づいて収集する。この情報は、申込表７１５０のフィールド７１６６からの許可額と共に、クレジットカード処理装置６８３０を介してクレジットカード発行者に送信される。
【０４１４】
ステップ７３３４で、中央制御装置６８００は、クレジットカード発行者からの許可又は拒否を、クレジットカード処理装置６８３０を介して受信する。クレジットカード発行者は、満了したカード、クレジット限度額の超過又は支払不履行を含む理由で要求を拒否することができる。拒否されると、ステップ７３３６で、中央制御装置６８００は、ユーザー端末６９００のユーザーにこの拒否を通知して別のクレジットカード情報を要求する。代替的に、ユーザーは、顧客表７１３０の彼の現在の情報を補完又は交換する別のクレジットーカードに対応する情報を送信することができる。代わりのクレジットカード情報が与えられれば、課金許可を受けるためにステップ７３３２が繰り返される。クレジットカード処理装置６８３０を介してクレジットカード発行者から許可を受信すると、中央制御装置６８００は掲載された申込を確認するために、申込表７１２０を、ステイタスフィールド７１５７を「アクティブ」に変更するなどして更新する。
【０４１５】
図７３ｄ乃至図７３ｇは、潜在的買主からの申込を検討するためにユーザー選択に基づいてステップ７３１４で実行される処理ステップを示している。ステップ７３４０で、中央制御装置６８００は、ユーザーに表示するために一般開催地とイベント情報をユーザー端末６９００に送信する。ステップ７３１６で上述したように、中央制御装置６８００は、ユーザーが検討を希望する正確なイベントをつきとめるために幾つかの選択肢をユーザーに与えることができる。最終的に、中央制御装置６８００は、イベント表７１００のフィールド７１０２からイベントＩＤをユーザーに与える。ステップ７３４２で、ユーザーはイベントＩＤを中央制御装置６８００に与え、それが申込表７１５０の関連申込を識別することができるようにする。
【０４１６】
ステップ７３４４で、中央制御装置６８００は、選択されたイベントＩＤに関連付けられて「アクティブ」のステイタスを有する申込記録を識別する。中央制御装置６８００は、このデータをユーザーに表示するためにユーザー端末６９００に送信する。ユーザーは、特定イベントにの全申込を同時に又は一度に一つずつ検討することができる。ある実施例では、ユーザーは開催地のグラフィック表示を介して買主が座席を要求している場所を正確に示すために各個別的申込を検討することができる。ある場合には、申込はアリーナ全体のどの座席に対するものであってもよい。一の実施例では、ユーザーは正確なチケット情報を入力してそれが申込要件を満たしているかどうかを確認することができる。
【０４１７】
上述したように、リンクされた申込は、ユーザーに提供されると適当に識別される。この場合、中央制御装置６８００は、関連リンク申込が同時に検討されることを許容しているので、ユーザーは一の買主が提出した条件付申込を比較することができる。
【０４１８】
次に、ステップ７３４６で、中央制御装置６８００は特定の申込を承諾する要求又は別イベントの申込を検討する要求を受け取る。ユーザーは申込の受信前のいかなる時にもシステムから出ることができることに留意しなければならない。
【０４１９】
ユーザーが特定の申込を承諾する要求を送信した後で、ステップ７３４８でユーザーは原チケット番号と座席の場所（即ち、セクション、列及び座席）を中央制御装置６８００に送信する。この情報をユーザーから受け取ると中央制御装置６８００は、ステップ７３５０で原チケット番号と座席の場所を、そのチケットの有効性の確認のために、開催地制御装置７０００に送信する。
【０４２０】
以下、図７３ｅを参照するに、ステップ７３５２で開催地制御装置７０００はチケット表７２１０から中央制御装置６８００がステップ７３５０で送信したチケット番号と一致する記録を受信する。開催地制御装置７０００は、ステップ７３５４と７３５６で送信されたチケット番号が送信された座席の場所に一致することを確認する。ステップ７３５８で、送信されたチケットと座席の場所が一致しなければ、開催地制御装置７０００は、無効な組合せのメッセージを中央制御装置６８００に送信する。中央制御装置６８００は、その後ステップ７３６０で、チケット番号と座席の場所が無効な組合せである旨のメッセージをユーザー端末６９００に送信する。無効な組合せのメッセージをユーザー端末６９００で受信すると、ユーザーはチケットと座席の場所を中央制御装置６８００にステップ７３７０で再提出する。その後、処理はステップ７３５０に帰還する。チケット番号と座席の場所の組合せが有効であれば処理はステップ７３７２に続く。
【０４２１】
図７３ｆのステップ７３７２で、中央制御装置６８００はユーザー端末６９００に法律契約文言を送信し、それはチケット販売ユーザーに表示される。上述したように、この契約文言は契約詳細表（図示せず）に格納されることができる。この文言は、保証された購入申込を承諾することの契約関係について述べており、処理は書面契約に署名する前に条件を検討するのと同様である。チケット販売ユーザーがこれらの条件に従うことを選択しなければ、ユーザーはその承諾を取り消すことができる。しかし、ユーザーがその条件に従うことを選択すれば、ユーザーは中央制御装置６８００に肯定的承認を送信し、その承諾に法的に拘束される。
【０４２２】
中央制御装置６８００は、その後ステップ７３７６で、承諾許可を得るためにユーザーのクレジットカード発行者に連絡をとる。中央制御装置６８００は、ステップ７３０６でユーザーから収集した顧客表７１３０に格納されている申込情報とクレジット情報に基づいて、ユーザーのクレジットの一部を保全するために許可をクレジットカード発行者から要求する。このクレジット保全は詐欺防止であり、売主がチケットを配達しそこなった場合の罰金として使用されることができる。かかる罰金は買主の信頼を形成し、チケット購入ユーザーに対して、チケット販売ユーザーが実際にチケットを譲渡する旨を確信させる。チケット販売ユーザーが契約の履行を拒もうとした場合には罰金がチケット購入ユーザーに支払われることができる。この罰金は、チケット販売ユーザーに均一の罰金を課したり、チケット購入ユーザーが提供した全額に等しい罰金を課すなど幾つかの方法で決定されることができる。
【０４２３】
ステップ７３７４で、中央制御装置６８００はチケット販売ユーザーから情報収集をする。情報は、申込表７１５０から検索された顧客ＩＤに基づいて、顧客表７１３０からユーザー名、住所、クレジットカード番号及び満了日を含むことができる。申込表７１５０のフィールド７１６６からの許可額と共に、この情報は、クレジットカード処理装置６８３０を介してクレジットカード発行者に送信される。
【０４２４】
ステップ７３７６で、中央制御装置６８００は、クレジットカード発行者からクレジットカード処理装置６８３０を介して許可又は拒否を受信する。クレジットカード発行者は、満了したカード、クレジット限度額の超過、支払不履行を含む理由により要求を拒否することができる。拒否されると、ステップ７３２８で、中央制御装置６８００は、ユーザー端末６９００のユーザーに拒否を通知して代わりのクレジットカード情報を要求する。ユーザーは、ユーザーが間違った情報を前に誤って送信したのであれば、クレジットカード情報を前に与えたように送信しようとすることができる。代替的に、ユーザーは、顧客表７１３０のクレジットカード情報を補完又は交換するであろう代わりのクレジットカードに相当する情報を送信することができる。代わりのクレジットカード情報が与えられると、課金許可を得るためにステップ７３７４が繰り返される。
【０４２５】
中央制御装置６８００はクレジットカード処理装置６８３０を介してクレジットカード発行者から許可を受信し、中央制御装置６８００が取引ＩＤを生成してその販売に割り当てるステップ７３８０に処理は続く。この取引ＩＤは申込表７１５０のフィールド７１６７に格納される。更に、中央制御装置６８００は、割り当てられた取引ＩＤによってインデックスが付されている新しい記録を取引表７１８０に形成する。割り当てられた取引ＩＤは、取引表７１８０のフィールド７１８１にも格納される。取引表７１８０の原チケット番号７１９０のフィールドは、チケット販売ユーザーからの適当なチケット番号によって埋められる。更に、中央制御装置６８００は、データフィールド７１８３を使用してその承諾をタイムスタンプし、その承諾が掲載された時を表示する。
【０４２６】
一旦保証された購入申込が承諾されると、中央制御装置６８００は、フィールド７１５２からの顧客ＩＤをチケット購入ユーザーの名前を検索する顧客表７１３０へのインデックスとして使用する。ステップ７３８２で、中央制御装置６８００は、チケット購入ユーザーの名前を開催地制御装置７０００に送信する。
【０４２７】
ステップ７３８４で、開催地制御装置７０００は新しい記録を交換チケット表７２３０に形成する。新しい記録は買主の名前、原チケット番号、チケットのセクション、列及び座席を示す情報で埋められる。ステップ７３８６に示すように、新しい記録は、開催地制御装置７０００が割り当てられる交換チケット番号で更に埋められる。交換チケット番号は、その後、中央制御装置６８００に送信される。
【０４２８】
一旦中央制御装置６８００が交換チケット番号７２４２を開催地制御装置７０００から受信すると、中央制御装置６８００は、その後ステップ７３８８で、取引表７１８０の新チケット番号フィールド７１９４を更新する。ステップ７３９０で、中央制御装置６８００は、なすべき支払を決定してチケット購入ユーザーのクレジットカードに、チケット代金に処理費用７１８７を加えたものを課金する。中央制御装置６８００は、課金額で取引表７１８０のフィールド７１８５も更新する。最後に、中央制御装置６８００は申込承諾をしているユーザーの売主ＩＤでフィールド７１８９を更新し、また中央制御装置６８００は、売主が販売されたチケットを使用しようとした場合に許可された売主額でフィールド７１８６を更新する。フィールド７１８４は処理費用７１８７を除いた買主課金額７１８５に基づいて更新される。本実施例の料金は表に格納されているものとして例示されているが、かかる料金は表から検索される代わりに簡単に計算することができる。
【０４２９】
ステップ７３９２で、中央制御装置６８００はメッセージをユーザー端末６９００に送信して、チケット販売ユーザーに対して、彼のクレジットカード口座をチケット販売額で、中央制御装置６８００が原チケットが引き渡された旨の確認を受信するとできるだけ早く、クレジットする旨を通知する。
【０４３０】
ステップ７３９４で、中央制御装置は交換チケット番号７２９２と彼の保証された申込は承諾された旨のメッセージをチケット購入ユーザーに送信する。チケット購入ユーザーは、その後ステップ７３９６で、交換チケット番号を印刷し、その場所にそれを開催地に持っていき、希望イベントにアクセスするのにそれを使用することができる。原番号の取消と購入ユーザー名に結び付けられた交換チケット番号の発行はチケットの売主及び／又は購入者のどちらかによる詐欺を防止するために行われる。
【０４３１】
例えば、売主が開催地にチケットを持って現れ、購入者も同一の開催地に同一の座席に対する交換チケットを持って現れた場合、どちらのチケットが有効であるかを決定するために開催地制御装置をアクセスすることができる。開催地制御装置７０００の交換チケット表７２３０に登録されている限り、交換チケットは常に原チケットを無効にする。かかる詐欺は売主によって企図されて中央制御装置６８００によって看破されれば、中央制御装置売主のクレジットカード口座に取引表７１８０のフィールド８５６で許可された売主額を課金することができる。
【０４３２】
別の例として、２人の人が同一の交換チケットを持って開催地に到着した場合、交換チケット表７２３０の新しい買主の名前フィールド７２４０の内容に基づいて正当な所有者を決定するために開催地制御装置をアクセスすることができる。これらの詐欺対策により顧客はチケット売買で中央制御装置６８００を使用することに何の問題もないことを確信する。
【０４３３】
最後に、ステップ７３９８で、中央制御装置６８００は原チケットが売主から受け取られた旨の確認を受信して、チケット販売ユーザーのクレジットカード口座を取引額７１８４でクレジットする。従って、中央制御装置は、チケットが受け取られた日付フィールド７１８８を更に更新する。チケットの引渡しは、好ましくは、開催地の予約販売窓口へのチケットの配達によって行われるが、郵送やフェデラルエクスプレス便によるなど別の引渡手段も可能である。一旦チケットが引き渡されて取引が完了すると、中央制御装置６８００は申込表７１５０のステイタスフィールド７１５７をトラッキング目的で「完了」に更新する。引き渡されたチケットを受け取ると、中央制御装置６８００はチケット販売ユーザーの口座をクレジットする。
【０４３４】
原チケットを引き渡す好ましい方法は郵送その他の配達機構を使用することであるが、多数の代替的な実施例が可能である。ある代替的な実施例を使用すると、チケット回収は購入申込が変更不能に承諾されたときに推定的に行われてもよい。代替的な実施例は、無効又は無益にするために物理的に変更可能なイベントチケットを使用する。各チケットは、チケット表面に事前印刷されているが白色ラテックスコートなどスクラッチオフカバーによって目視不明になる独自のチケット番号を含んでいる。チケット番号はスクラッチオフカバーが取り除かれない限りチケット保持者にはわからない。
【０４３５】
承諾時にチケットを処理する売主は、販売される各チケットのチケット番号上のカバーを除去するように命令される。チケット番号は、そのチケットの売主が実際に有効なチケットを所有していることを確認するために、中央制御装置６８００に与えられる。本取引に関連した各チケット毎に与えられるチケット番号は、その後、電子的に無効にされて交換チケット番号が上述したように割り当てられる。
【０４３６】
チケット番号を暴露する行為は、そのチケットについてのチケットの売主の所有を確認するだけでなく売主がチケットを引き渡す必要性を取り除く機能も有している。なぜなら、スクラッチオフカバーを取り除くとそのチケットは無効になるからである。この代替的な実施例はイベントチケットに追加構造を要求としているが、それは売主のクレジット限度額の一部を未使用チケットを返却できなかったことに対する罰金として保全する必要性を排除している。
【０４３７】
様々な図のフィールドを埋めるデータを使用して本発明の実施例を以下に説明する。申込表７１５０の記録７１７２は、顧客ＩＤフィールド７１５２が識別しているようにユーザー４０００が提出した種類フィールド７１５６に示すように、保証された購入申込である。顧客表７１３０の記録７１４８に示すように、ユーザー４０００は、コネチカット州ノーウォークの１０１ピンクアベニューに住んでいるスー・ブラックである。中央制御装置６８００に提出されたクレジットカード番号は、ディスカバー（Ｄｉｓｃｏｖｅｒ）でカード番号４４４４−４４４４−４４４４−４４４４であり、９／０２に満了し、スー・ブラックに発行されたものである。
【０４３８】
申込表７１５０の記録７１７２において、スー・ブラックは、イベントＩＤフィールド７１５３に示すように、イベントＩＤＥ００１に対する２枚のチケットの保証された購入申込を開催地の最初のセクションの最初の列１枚当たり２００．００ドルで掲載した。イベント表７１００の記録７１１４に示すように、イベントＥ００１はＮＨＬの試合であり、特に、開催地ＩＤフィールド７１０８に示すように、ニュージャージー・デビルス対ニューヨーク・レンジャーズの５／６／９７、７：３０ｐ．ｍ．に、「ＭＳＧ」で開始するものである。開催地表７１２０の記録７１２６はＭＳＧがニューヨーク州ニューヨーク市のマジソン・スクエア・ガーデンと識別している。
【０４３９】
この保証された購入申込に加えて、スー・ブラックは、リンクされたＩＤフィールド７１６８に示すように、リンク申込も掲載している。このリンク申込は０３３３のＩＤコードを有している。申込表７１５０の記録７１７０は申込ＩＤ０３３３を有しており、従って、記録７１７２にリンクされている申込である。記録７１７０は、記録７１７２の申込要求と同一の日時を有するニュージャージー・デビルス対ニューヨーク・レンジャーズというＮＨＬ試合の４枚チケットのスー・ブラックによる購入申込である。記録７１７０で、スー・ブラックは彼女が開催地の第１セクションの第１列の４枚のチケットの各々に対して２５０ドル支払うと述べている。申込７１７０は申込７１７２にリンクされているので、スー・ブラックは彼女が２つの申込の一方あるいは他方を希望することを示している。
【０４４０】
申込表７１５０のフィールド７１６６は、スー・ブラックが提出した両記録７１７０及び７１７２に対して、口座４４４４−４４４４−４４４４−４４４４に対して１，０００ドルがディスカバーによって許可されていることを示している。１，０００ドルはそれらの一つが履行されればスーブラックの申込がかかり得る最高可能額である。
【０４４１】
記録７１７２に対して取引ＩＤフィールド７１６７は取引ＩＤで埋められ、買主がスー・ブラックの保証された購入申込を承諾したことを示している。記録７１７２のステイタスフィールド７１５７は、申込が履行され、ステイタス記録７１７０が満了したことを登録している。なぜなら、それは記録７１７２に一つが履行されると他は無視されなければならないことを示す方法でリンクされたからである。
【０４４２】
取引表７１８０の記録７１９５は、売主ＩＤフィールド７１８９に示すように、売主２０００によるスー・ブラックの保証された購入申込の承諾である取引ＴＲ００１の詳細事項を説明している。
【０４４３】
顧客表７１３０の記録７１７０は、ＩＤ番号２０００を有する顧客が、顧客ＩＤフィールド７１３２に示すように、ジョージア州アトランタレッドドライブ４５６に住んでおり、満了日９／９９を有して中央制御装置６８００に登録されているマスターカード番号２２２２−２２２２−２２２２−２２２２を有するジル・ジャンソン（Ｊｉｌｌ  Ｊａｎｓｏｎ）であることを示している。
【０４４４】
記録７１９５は、スー・ブラックが申込表７１５０の彼女の保証された購入申込に結合されたイベントの列１、座席１の座席００３と００４を購入したことに対して４２０ドル５／２／９７に課金されたことを示している。記録７１９５も、ジル・ジャンソンが、セクション００１、列００１、座席００３及び００４に対して、原チケット番号フィールド８１０に格納された原チケット６６７９１３と６６７９１４を彼女に販売したことを示している。売主許可額フィールド７１８５は、ジル・ジャンソンが彼女のチケットを販売するという彼女の合意を承諾しない場合に、中央制御装置６８００がマスターカードによって口座２２２２−２２２２−２２２２−２２２２からデビッドすることが許可されている額４００ドルを格納している。この額の全て又は一部が、彼女が新しいチケット番号を使用して開催地のイベントにアクセスするのに問題が生じれば、スー・ブラックにクレジットされることができる。
【０４４５】
チケットが受け取られた日付フィールド７１８８はこの記録で空白であり、中央制御装置６８００はジル・ジャンソンが彼女のチケットを引き渡したことを確認することを受信していないという表示をしている。中央制御装置６８００が、ジル・ジャンソンが彼女のチケットを引き渡した旨の確認を一旦受信すると、ジル・ジャンソンのクレジットカード口座は取引口座フィールド７１８４に格納された額の３８０ドルだけクレジットされる。
【０４４６】
中央制御装置６８００は、交換チケット番号をスー・ブラックに両席に対して発行する。これらの交換チケット番号はフィールド７１９４に格納される。好ましくは、スー・ブラックは、これらの交換チケット番号を印刷して、イベントにアクセスするために開催地に持っていくことができる。
【０４４７】
チケット表７２１０の記録７２２２及び７２２４は、ジル・ジャンソンに発行された原チケットに関連する情報を格納している。交換チケット表７２３０の記録７２４４及び７２４６は、中央制御装置６８００がスー・ブラックに発行した交換チケット番号を格納しており、それはジル・ジャンソンに与えられた原チケット番号を置き換えている。これらの記録は、上述したように、詐欺の場合に利用されるために、開催地制御装置７０００に格納される。
【０４４８】
上述した実施例は、買主と売主の両当事者の通知が遠隔ユーザー端末にそれぞれ連絡を取ることを介して行われることに留意することが重要である。この通知は、従来の技術を使用しても実行されることができ、例えば、電話、ファクシミリ、Ｅメール及びページングによって行われるがこれらに限定されるものではない。
【０４４９】
本発明の保証された購入及び承諾システムに加えて、本発明はチケット再販売の他の側面にも十分に適している。例えば、本実施例は、あるイベント又はチケットの登録処理を含むことができる。かかる処理は、将来のチケットの買主が中央制御装置が実行することができるチケット監視を設定することを可能にするであろう。中央制御装置６８００は、特定のチケットが利用可能かどうかを決定するために、定期的に申込を獲得することができる。利用可能性はユーザーに従来の電話線、Ｅメール、ファクシミリ又はページャーを介して送信されることができる。通知の嗜好は登録処理中にユーザーが決定することができる。
【０４５０】
本実施例に十分に適しているチケット再販売の他の側面は宣伝広告である。ユーザーが単に申込を出して、検討して、承諾することを可能にする代わりに、システムはイベントとチケットに関連する製品の宣伝広告を与えることができる。
【０４５１】
ＣＰＯ及び第三者入力管理システム
第三者からの申込関連情報に照らして売主に買主の申込の承諾可能性を評価することを可能にする本発明の別の実施例の方法及び装置を以下図７４乃至８２を参照して説明する。図７４乃至８２に関連する以下の説明は金融関連の実施例を例示目的で採用しているが、当業者は、本発明の範囲がそれらに限定されないことを理解するであろう。従って、以下の説明において、売主と買主は、貸主と借主とそれぞれ呼んでもよい。
【０４５２】
図７４を参照するに、製品販売処理システム７４１０は、借主端末７４１４と通信する中央制御装置７４１２と、第三者７４１６及び７４１８と、貸主端末７４２０、７４２２及び７４２４とをインターネットその他の適した通信網を介して有している。借主端末、第三者及び／又は貸主端末の例示された番号は例示であり何ら限定するものではない。いかなる数の借主端末、第三者及び／又は貸主端末も中央制御装置７４１２と本発明の代替的な実施例で送信することができることを当業者は理解するであろう。
【０４５３】
買主端末７４１４は、典型的に、信号を生成して中央制御装置７４１２にそれを送信するコンピュータその他の装置である。理想的には、借主端末は、モデムその他の遠隔通信装置に接続されているインテル８０３８６マイクロプロセッサに基づくものなどの従来のパーソナルコンピュータである。製品（商品又は役務）の購入を希望する顧客は、少なくとも一の条件信号を含んだ申込信号を中央制御装置７４１２に送信するために買主端末７４１４を操作する。申込信号は、少なくとも一の条件を含んでいる顧客からの条件的購入申込を定義している。
【０４５４】
本実施例においては、顧客はローンを希望する「買主」である（即ち、彼はローンを「購入」したいと思っている）。従って、申込信号はローンを入手する申込を定義する。以下に詳細に説明するように、申込は様々な条件のいずれをも含むことができ、申込信号は、借主の希望条件を特定する一以上の条件信号を含んでいる。例えば、借主は、ローン及び／又は特定の利率に対する特定の月払額を希望することができる。
【０４５５】
借主端末７４１４は、中央制御装置７４１２に、資金が支払可能な汎用口座を特定する支払識別子信号も送信する。例えば、支払識別子信号は、借主が所有する口座のクレジットカード番号又は当座預金口座番号を特定する。
【０４５６】
支払識別子信号は、借主がその購入の申込を実行（開始）することができなかった場合に、支払われるべき資金を識別することによって借主を効果的に「拘束」するのに利用される。これによって支払識別子は、申込が本物で拘束力のある旨を潜在的貸主に確信させる。例えば、借主が約束にそむけば、支払識別子が、借主の申込を処理するのに費やした貸主の費用を償うのに十分な額を徴収するのに使用されることができる。資金の特定の徴収額は中央制御装置７４１２が設定してもよいし、貸主の裁量に任されてもよい。
【０４５７】
別の実施例においては、借主がたとえ彼の申込を完了しなくても、支払識別子は他の費用を徴収するのに追加的に使用されることができる。例えば、支払識別子は、ローン取引料金又は月別ローン払いでさえ徴収するのに使用されてもよい。
【０４５８】
貸主が申込を承諾するために貸主端末を操作して、これによって申込処理費用が発生すると、貸主は、（ｉ）ローン条件を満足することができればローンを貸主に販売することができること、又は、（ｉｉ）借主が申込条件に従うことを怠れば、（例えば、借主がローン完了を怠れば）、貸主は、支払識別子信号が特定する口座から支払われる罰金払いを徴収することができることを確認する。両方の場合において、貸主は、申込の承諾は資金を産み、従って、申込の承諾は他の製品販売処理システムほど危険ではないと確信する。
【０４５９】
上述したように、売主は、申込を承諾するかどうかを決定するために、しばしば、申込関連情報を第三者に要求する。例えば、貸主が借主のクレジット履歴又はクレジットスコアを知らなければ、貸主は借主からの申込信号を評価して承諾することができない。そこで、システム７４１０は、中央制御装置７４１２に情報信号を与える第三者７４１６及び７４１８を含んでいる。情報信号は、（ｉ）買主が見たり及び／又は変更してはならない情報、及び／又は（ｉｉ）申込の有効性及び／又は価値を決定する必要がある情報を好ましくは定義している。第三者７４１６及び７４１８は、例えば、中央制御装置７４１２に借主のクレジット情報を与えるクレジット報告事務所や借主が提出するローン担保の価値を評価する評価人である。
【０４６０】
中央制御装置７４１２は、送信された申込信号、支払識別子信号及び情報信号を受信格納する。以下に詳細に説明するように、信号は幾つかのデータベースに格納され、これによって、データベース内で表わされたデータのサーチ及び検索を容易にする。中央制御装置７４１２は、申込が適当であるとみなされた場合には、貸主端末７４２０、７４２２及び７４２４のいずれかが申込を承諾することができることを許容するために格納された信号を使用する。
【０４６１】
貸主端末が申込を承諾するならば、借主はその申込の条件を守るように拘束される。例えば、借主が必要なローン用紙に署名しなければ中央制御装置７４１２は支払識別子を資金回収に使用することを開始する。例えば、中央制御装置７４１２が支払識別子信号を貸主端末に送信することができ、これによって貸主に資金回収を可能にする。代替的に、中央制御装置７４１２それ自身が支払識別子信号を資金回収に使用することができる。
【０４６２】
中央制御装置７４１２は、様々な方法で申込の承諾を管理することができる。以下の実施例では、申込の承諾は、（ｉ）申込信号を貸主端末に送信し、代わりに承諾信号を貸主端末から受信すること、又は、（ｉｉ）申込信号を売主の規程と比較し、申込が規程のいずれも満足しているかを決定することを含んでいる。
【０４６３】
図７５ａは、申込の承諾が貸主端末から承諾信号を受信するステップを含んでいる場合に使用される中央制御装置７４１２（図７４）の具体化である中央制御装置７５３０を示している。中央制御装置７５３０は、一以上の従来のマイクロプロセッサなどの中央演算処理装置７５３１と、中央演算処理装置７５３１に接続されているＲＡＭ、フロッピーディスク（Ｒ）、ハードディスク又はこれらの組み合わせなどの記憶装置７５３２とを有している。中央演算処理装置７５３１と記憶装置７５３２とは、（ｉ）単一のコンピュータ内に完全に配置されているか、（ｉｉ）シリアルポートケーブル、電話線、無線周波数トランシーバーなどの遠隔通信リンクによって接続されているか、（ｉｉｉ）それらの組合せであってもよい。例えば、中央制御装置７５３０は、データベースを保持する遠隔サーバーコンピュータに接続されている一以上のコンピュータから構成されてもよい。
【０４６４】
記憶装置７５３２は、（ｉ）本発明に従って、特に、ここで詳細に説明する処理に従って、中央演算処理装置７５３１を制御するプログラム７５３３と、（ｉｉ）申込を提出する各借主に関する情報を保存する借主データベース７５３４、（ｉｉｉ）申込を受け取る各貸主に関する情報を保存する貸主データベース７５３６と、（ｉｖ）中央制御装置に提出された各申込を特定する申込データベース７５３８と、（ｖ）クレジット価値を説明する情報信号を格納するクレジット報告データベース７５４０と、（ｖｉ）申込に関連して使用される担保を説明する情報信号を格納する担保データベース７５４２と、（ｖｉｉ）中央制御装置によって承諾された各承諾を特定する応答データベース７５４４とを格納している。
【０４６５】
プログラム７５３３は、コンピュータ周辺装置とインターフェース接続する「デバイスドライバー」などの必要なプログラム要素も含んでいる。適当なデバイスドライバーとその他のプログラム要素は当業者に既知であるのでここでは詳細には説明しない。データベース７５３４、７５３６、７５３８、７５４０、７５４２及び７５４４の各々は以下に詳細に説明する。
【０４６６】
図７５ｂは、申込の承諾が、申込が貸主特定規程のいずれも満足しているかどうかを決定するステップを含んでいる場合に使用される中央制御装置７４１２（図７４）の具体化である中央制御装置７５６０を示している。中央制御装置７５６０は、中央演算処理装置７５６１と中央演算処理装置７５６１に接続されている記憶装置７５６２とを含んでいる。中央演算処理装置７５６１と記憶装置７５６２とは、図７５ａの中央演算処理装置７５３１とデータ記憶装置７５３２に類似する方法で実行されてもよい。
【０４６７】
記憶装置７５６２は、（ｉ）本発明に従って中央演算処理装置７５６１を制御するプログラム７５３３と、（ｉｉ）申込を提出する各借主に関する情報を保存する借主データベース７５３４と、（ｉｉｉ）貸主データベースと、（ｉｖ）申込データベース７５３８と、（ｖ）クレジット報告データベース７５４０と、（ｖｉ）担保データベース７５４２と、更に、（ｖｉｉ）申込を承諾するための借主が特定した規程を格納する規程データベース７５６４とを有している。プログラム７５３３とデータベース７５３４、７５３６、７５３８、７５４０及び７５４２は上述したように機能し、規程データベース７５６４は以下に詳細に説明する。
【０４６８】
図７６を参照するに、図７５ａと図７５ｂの借主データベース７５３４は、申込を提出する借主に各々対応している例示的に記録７６７０と７６７２とを格納している。各記録は、中央制御装置７４１２（図７４）によって生成されて借主が作成した申込を独自に識別する申込識別子７６７４を格納している。各記録は、借主の名前７６７６、住所７６７８及び電話番号７６８０も格納している。
【０４６９】
図７７を参照するに、図７５ａ及び図７５ｂの借主データベース７５３６は、申込を承諾可能な貸主に各々対応する例示的記録７７９０及び７７９２を格納している。各記録は、中央制御装置７４１２（図７４）によって生成されて貸主の名前７７９６、住所７７９８及び電話番号７８００と共に貸主を独自に識別する貸主識別子７７９４を格納している。
【０４７０】
図７８を参照するに、図７５ａ及び図７５ｂの申込データベース７５３８は、受信された申込に各々対応している例示的記録７８１０、７８１２及び７８１４を格納している。各記録は申込識別子７８１６を格納しており、申込識別子は、（ｉ）申込を独自に識別し、（ｉｉ）図７６の借主データベース７５３４の申込識別子７６７４の一つに対応している。各記録は、更に、データ７８１８と申込が受信された時間７８２０、ローン額７８２２、月払い７８２４、ローン期間７８２６及びローンの利率７８２８などの申込条件を格納している。各記録は、満了日７８３０と満了時７８３２とを有することができ、その後は申込を承諾されることができない。ローンの種類７８３４は、例えば、貸主が、希望ローンが機密保持されているかどうかを知ることができることが望ましい実施例にも格納されている。
【０４７１】
図７９を参照するに、図７５ａ及び図７５ｂのクレジット報告データベース７５４０は、受信された申込に各々対応している例示的記録７９４２、７９４４及び７９４６を格納している。各記録は申込識別子７９４８を格納しており、申込識別子は、（ｉ）申込を独自に識別し、（ｉｉ）図７６の借主データベース７５３４の申込識別子７６７４の一つに対応し、（ｉｉｉ）図７８の申込データベース７５３８の中の申込識別子７８１６の一つに対応している。中央制御装置７４１２（図７４）によって生成され、対応する申込を提出した借主のクレジットチェックその他の評価の結果を独自に識別するクレジット報告識別子７９５０も各申込毎に格納されている。クレジットスコア７９５２は評価結果を定義している。
【０４７２】
図８０を参照するに、図７５ａ及び図７５ｂの担保データベース７５４２は、受信された申込に各々対応している例示的記録８０６０、８０６２、８０６４及び８０６６を格納している。各記録は、申込を独自に識別し、図７６、７８及び７９に関連して上述された申込識別子に対応している申込識別子８０６８を格納している。各申込に対して、担保の種類８０７０、担保の説明８０７２及び担保の価値８０７４が格納されている。
【０４７３】
図８１ａを参照するに、図７５ａの応答データベース７５４４は、申込に対して受信された応答に各々対応している例示的記録８１８０及び８１８２を格納している。各記録は、申込を独自に識別し、図７６、７８、７９及び８０に関連して上述された申込識別子に対応している申込識別子８１８４を格納している。各記録は、各受信応答を独自に識別する応答識別子８１８６、貸主識別子８１８８、及び、ローン額８１９０、定期的支払額８１９２、ローン期間８１９４及びローン利率８１９６など貸主が与えることを了解しているローンの条件も格納している。応答時間８１９６と日付８２００も応答データベース７５４４に格納されている。
【０４７４】
図８１ｂを参照するに、図７５ｂの規程データベース７５６４は、貸主が申込を承諾するときの規程定義基準に各々対応している例示的記録８１８０及び８１８２を格納している。各記録は、規程、規程を満足している申込を承諾している貸主を識別する貸主の身元８２１８、申込を承諾する基準を特定する規程制限８２２０を独自に識別する規程識別子８２１６を格納している。
【０４７５】
図８２ａ及び図８２ｂは、借主端末と一以上の貸主端末との間のローン販売処理方法８２３０を示している。例示された方法８２３０は、申込の承諾が貸主端末からの承諾信号の受信を含んでいる図７５ａの実施例の中央制御装置７５３０によって実行される。中央制御装置は申込信号を借主端末から受信する（ステップ８２３２）。上述したように、申込信号は少なくとも一の条件信号を含んでおり、申込信号はこれによって借主からの少なくとも一の条件を有する申込を定義する。
【０４７６】
支払識別子信号は借主端末から受信される（ステップ８２３４）。クレジットカード番号や当座預金番号などの支払識別子信号は資金が支払可能な口座を特定する。
【０４７７】
中央制御装置は支払識別子信号を有効にする（ステップ８２３６）。支払識別子信号は、口座資金の額を凍結又はその他の方法で借主に資金を利用不可能にすることによって有効にされることができ、これによってかかる資金が承諾している売主に利用可能なままにされる。支払識別子信号が有効でなければ、借主端末は申込と支払識別子信号を再送信するように要求される（ステップ８２３８）。また、中央制御装置は、受信された申込信号を有効にしており（ステップ８２４０）、これによって受信申込信号が所定有効基準を満足しているかどうかを決定する。申込信号が所定の有効基準を満たしていない場合には、借主端末は申込と支払識別子を再送信するように要求される（ステップ８２３８）。
【０４７８】
有効化は、受信された申込信号が意味のある申込を定義しているかどうかを決定するために金融計算を実行することを典型的に含んでいる。例えば、申込信号がローン額、利率、ローン期間及び月払額を含んでいれば、金融計算は特定化された申込が意味があるかどうかを決定することができる。金融計算は既知であり、本開示の一部としてここで参照して結合されるリチャード・Ａ・ブリーリ（Ｒｉｃｈａｒｄ  Ａ．  Ｂｒｅａｌｙ）及びスチュワート・Ｃ・マイヤー（Ｓｔｅｗａｒｔ  Ｃ．  Ｍｙｅｒｓ）による「コーポレート・ファイナンス（Ｃｏｒｐｏｒａｔｅ  Ｆｉｎａｎｃｅ）第４版」の第３章に説明されている。中央制御装置は、第三者からクレジット情報を含む情報信号を要求し受信もする（ステップ８２４２）。情報信号は、更に、買主が提供した担保の評価値など、申込に関連する他の情報を含んでいる。上述したように、一以上の第三者が所望の情報信号を制御装置に供給することができる。
【０４７９】
中央制御装置は、その後、申込信号と情報信号を一以上の貸主端末に送信する（ステップ８２４４）。中央制御装置は、代わりに、貸主端末の少なくとも一つから、送信された申込信号と情報信号に応答する一以上の承諾信号を受信する（ステップ８２４６）。承諾信号の一つが選択され（ステップ８２４８）、対応する貸主端末が識別される（ステップ８２５０）。借主は、これにより、申込の条項又は条件の下、識別された貸主に拘束される。借主がその後借りての条項によって従わないことによって約束をやぶれば（ステップ８２５２）、資金回収のために支払識別子信号を利用することが開始される（ステップ８２５４）。例えば、中央制御装置は資金回収をすることができるし、支払識別子信号を識別された貸主端末に送信して貸主が資金を直接回収することを可能にする。
【０４８０】
一の承諾信号を選択するステップ８２４８は幾つかの方法で実行されることができる。例えば、最初に受信された承諾信号又は承諾信号の無作為な一つが選択される。更に別の実施例においては、承諾信号は、最低利率又は最低月払額によって選別されるなどの所定の選別基準に従って選別されることができる。選別された承諾信号の最初を選択することは、その後、最低利率又は月払いをそれぞれ与える。幾つかの「タイブレーク」方法を、一群の等しく魅力的な承諾信号から一の承諾信号を選択するのに使用することができる。
【０４８１】
借主が承諾信号を選択して貸主を選択することが望ましい場合もある。かかる実施例においては、複数の貸主信号が借主に送信される。各借主信号は、複数の承諾信号の一つに代わりに対応する貸主を表示している。借主端末は、その後、選択された貸主信号を表す選択信号を中央制御装置に与える。選択信号はこれによって、選択された対応する承諾信号を表示する。
【０４８２】
承諾信号の選択は、申込が特定した条件を通じて発生することができる。例えば、申込は、ローン額、定期的支払額及び最低利率の要求を表す条件信号を含むことができる。従って、所定時間内に受信された最低利率を表す承諾信号が選択される。同様に、申込は、ローン額、利率及び最低の定期的支払額の要求を表す条件信号を含むことができる。かかる申込は最大ローン期間を表す条件信号を更に含むことができる。従って、最低定期的支払額を表す承諾信号が選択される。
【０４８３】
図８２ｃは、借主端末と一以上の貸主端末との間のローン販売処理方法８２６０の別の実施例を示している。例示された方法８２６０は図７５ｂの実施例の中央制御装置７５６０によって実行され、申込の承諾は申込信号を売主の規程と比較し、その申込がその規程を満足しているかどうかを決定することを含んでいる。
【０４８４】
図８２ａ及び図８２ｂに関連して上述したように、中央制御装置は、借主端末から申込信号（ステップ８２６２）を受信し、支払識別子信号（ステップ８２６４）も受信する。中央制御装置は支払識別子信号を有効にする（ステップ８２６６）。支払識別子が有効ではなければ、借主端末は申込及び支払識別子を再送信することを要求される（ステップ８２６８）。中央制御装置は、受信された申込信号も有効にし（ステップ８２７０）、これによって受信された申込信号が所定の有効化基準を満たしているかどうかを決定する。申込が意味のあるものでなければ、借主端末は申込及び支払識別子を再送信するように要求される（ステップ８２６８）。中央制御装置は、第三者からのクレジット情報を含む情報信号を要求し受信する（ステップ８２７２）。
【０４８５】
中央制御装置は、複数の売主の各々からの少なくとも一の規程信号を格納している（ステップ８２７４）。各規程信号は、少なくとも一の売主定義制限を含んでいる。ある制限は、申込条件を含むことができ、残りの制限は情報信号を含むことができる。例えば、ローン額が１００，０００ドル未満でなければならず、クレジットスコアは８０よりも大きくなければならない旨の制限を規程は含むことができる。当業者は、規程信号を格納するステップ８２７４が、申込信号が受信される前後で発生可能であることが理解できるであろう。
【０４８６】
申込信号及び情報信号は少なくとも一の規程信号（ステップ８２７６）に比較される。申込と情報信号の条件がいずれの規程の売主が定義した各制限を満足していれば（ステップ８２７８）、対応貸主は識別される（ステップ８２８０）。一の規程以上が満足されれば、一の規程が上述した方法のいずれかに従って選択される。借主はこれによって識別された貸主に申込の条項と条件の下で拘束される。借主が、その後、申込の条項を守らないことによって約束をやぶれば（ステップ８２８２）、支払識別子信の利用が上述したように資金回収のために開始される（ステップ８２８４）。
【０４８７】
本発明の方法及び装置は多くのアプリケーションを有すること、及び、本発明はここで開示された典型例には限定されないことを当業者は理解するであろう。更に、本発明の範囲は、ここで説明されているシステムコンポーネントに対する従来から知られている様々な変形及び変更を、当業者によって知られるであろうように、カバーするものである。
【０４８８】
本出願は、更に以下の事項を開示する。
【０４８９】
（付記１）  遠隔地にいる将来の買主と遠隔地にいる潜在的な売主の間で拘束力のある契約を完成するコンピュータ装置であって、
メモリ装置と、
当該メモリ装置と通信可能に配置された処理装置とを有し、前記処理装置は、（ａ）少なくとも一の条件を含む購入申込と、（ｂ）前記少なくとも一の条件に適合する購入用資金が支払可能な汎用金融口座を特定する支払識別子とを前記遠隔地にいる将来の買主から受信するように構成され、前記処理装置は、前記購入申込を複数の遠隔地にいる潜在的な売主に送信し、前記遠隔地にいる潜在的な売主の少なくとも一人から前記申込の無条件承諾を受信するように更に構成されているコンピュータ装置。
【０４９０】
（付記２）  前記処理装置は、前記買主からの前記購入の支払いに実効を持たせるのに前記支払識別子の利用を開始するように更に構成されている付記１記載のコンピュータ装置。
【０４９１】
（付記３）  前記汎用金融口座はクレジットカード口座である付記１記載のコンピュータ装置。
【０４９２】
（付記４）  遠隔地にいる将来の買主と遠隔地にいる潜在的な売主の間で拘束力のある契約を完成するコンピュータ装置であって、
メモリ装置と、
当該メモリ装置と通信できるように配置された処理装置とを有し、前記処理装置は、（ａ）少なくとも一の条件を含む購入申込と、（ｂ）前記少なくとも一の条件に適合する購入用資金が支払可能な電子清算システムの汎用金融口座を特定する支払識別子とを前記遠隔地にいる将来の買主から受け取るように構成され、前記処理装置は、前記購入申込を遠隔地にいる潜在的な売主の電子購入ネットワークに送り、前記遠隔地にいる潜在的な売主の少なくとも一人から前記申込の無条件承諾を受け取り、前記電子清算システムの前記汎用金融口座に課金することによって前記支払識別子を前記購入の支払いに利用することを開始するように更に構成されているコンピュータ装置。
【０４９３】
（付記５）  前記電子清算システムはクレジットカードシステムである付記４記載のコンピュータ装置。
【０４９４】
（付記６）  前記電子清算システムは前記電子購入ネットワークから独立している付記４記載のコンピュータ装置。
【０４９５】
（付記７）  前記少なくとも一の条件は、価格、数量、配達日、品質、地理的場所及び匿名性からなるグループから選択される付記１又は４記載のコンピュータ装置。
【０４９６】
（付記８）  前記処理装置は、最初に承諾した売主に対して、それが前記買主と法律的に拘束力のある契約を締結したことを通知するように構成されている付記１又は４記載のコンピュータ装置。
【０４９７】
（付記９）  前記処理装置は、最初に承諾した売主が前記購入申込を承諾した旨の通知を前記買主に送るように更に構成されている付記１又は４記載のコンピュータ装置。
【０４９８】
（付記１０）  前記買主への承諾の通知は、最初に承諾した売主を識別している付記９記載のコンピュータ装置。
【０４９９】
（付記１１）  前記購入申込は満了日を有し、その日前は撤回不能である付記１又は４記載のコンピュータ装置。
【０５００】
（付記１２）  前記購入申込は所定期間内に承諾されなければ満了する付記１又は４記載のコンピュータ装置。
【０５０１】
（付記１３）  前記処理装置は、前記購入申込が承諾されずに満了すれば前記購入申込が消滅したことを前記買主に通知するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５０２】
（付記１４）  前記購入申込は所定日までは有効ではない付記１又は４記載のコンピュータ装置。
【０５０３】
（付記１５）  前記処理装置は、前記申込がいずれかの承諾前に撤回されたかどうかを決定するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５０４】
（付記１６）  前記購入申込は、前記買主が前記最初に承諾した売主に特定の罰金を支払うならば前記最初に承諾した売主が前記申込を承諾した後に前記買主がその申込を撤回する権利を有する旨の前記条件を含んでいる付記１又は４記載のコンピュータ装置。
【０５０５】
（付記１７）  前記購入申込が前記将来の買主によって暗号署名されている付記１又は４記載のコンピュータ装置。
【０５０６】
（付記１８）  前記処理装置は、前記買主から前記購入の支払いを回収するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５０７】
（付記１９）  前記処理装置は、買主クレジットカード情報と許可を前記最初に承諾した売主に送るように更に構成されている付記１又は４記載のコンピュータ装置。
【０５０８】
（付記２０）  前記処理装置は、前記買主から徴収した支払いを第三者預託口座におくように更に構成されている付記１又は４記載のコンピュータ装置。
【０５０９】
（付記２１）  前記処理装置は、前記購入に対する前記支払いは分割で前記買主から徴収される付記１又は４記載のコンピュータ装置。
【０５１０】
（付記２２）  前記処理装置は、前記最初に承諾した売主に前記購入に対する支払いを送金するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５１１】
（付記２３）  前記処理装置は、前記買主から前記最初に承諾した売主に支払いを移転するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５１２】
（付記２４）  前記購入の前記支払いは、前記購入申込の承諾がなされると直ちに前記最初に承諾した売主に送金される付記２３記載のコンピュータ装置。
【０５１３】
（付記２５）  前記処理装置は、前記潜在的な買主と潜在的な売主との間で交換される送信の出所と完全性の少なくとも一つを認証するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５１４】
（付記２６）  前記処理装置は、前記潜在的な買主の身元を示さずに前記購入申込が潜在的な売主に入手可能なようにするように更に構成されている付記１又は４記載のコンピュータ装置。
【０５１５】
（付記２７）  前記処理装置は、前記売主の身元を示さずにその申込が承諾された旨を前記買主に通知するように更に構成されている付記１又は４記載のコンピュータ装置。
【０５１６】
（付記２８）  前記購入申込は商品に対するものである付記１又は４記載のコンピュータ装置。
【０５１７】
（付記２９）  遠隔地にいる将来の買主と遠隔地にいる潜在的な売主の間で拘束力のある契約を電子的に完成する方法であって、
前記遠隔地にいる将来の買主から（ａ）少なくとも一の条件を含む購入申込と、（ｂ）前記少なくとも一の条件に適合する購入用資金が支払可能な汎用金融口座を特定する支払識別子とを電子的に受信するステップと、
前記購入申込を複数の遠隔地にいる潜在的な売主に電子的に入手可能するステップと、
前記遠隔地にいる潜在的な売主の少なくとも一人から前記申込の無条件承諾を電子的に受信するステップとを有する方法。
【０５１８】
（付記３０）  前記少なくとも一の条件は、価格、数量、配達日、品質、地理的場所及び匿名性からなるグループから選択される付記２９記載の方法。
【０５１９】
（付記３１）  遠隔地にいる将来の買主と遠隔地にいる潜在的な売主の間で拘束力のある契約を電子的に完成する方法であって、
前記将来の買主から少なくとも二つの条件を含む購入申込を電子的に受信するステップであって、一の条件は、前記買主が、潜在的な売主からの複数の承諾の中から前記将来の買主が拘束される少なくとも一の承諾を選択する権利を有する旨を述べているステップと、
前記購入申込を複数の潜在的な売主に電子的に入手可能するステップと、
複数の前記潜在的な売主から前記申込の無条件承諾を電子的に受信するステップと、
前記複数の無条件承諾を前記将来の買主に電子的に送信するステップと、
前記買主が履行するように拘束される無条件承諾の少なくとも一の選択を前記将来の買主から電子的に受信するステップとを有する方法。
【０５２０】
（付記３２）  前記二つの条件の一つは、価格、数量、配達日、品質、地理的場所及び匿名性からなるグループから選択される付記３１記載の方法。
【０５２１】
（付記３３）  遠隔地にいる将来の買主と遠隔地にいる潜在的な売主の間で拘束力のある契約を電子的に完成する方法であって、
前記遠隔地にいる将来の買主から（ａ）少なくとも一の条件を含む購入申込と、（ｂ）前記少なくとも一の条件に適合する購入用資金が支払可能な電子清算システムの汎用金融口座からの支払識別子とを電子的に受信するステップと、
前記購入申込を遠隔地にいる潜在的な売主の電子購入ネットワークに電子的に入手可能するステップと、
前記遠隔地にいる潜在的な売主の少なくとも一人から前記申込の無条件承諾を電子的に受信するステップと、
前記電子清算システムの前記汎用金融口座に課金することによって前記購入の支払いを行うのに前記支払識別子の利用を電子的に開始するステップとを有する方法。
【０５２２】
（付記３４）  前記電子清算システムはクレジットカードシステムである付記３３記載の方法。
【０５２３】
（付記３５）  前記電子清算システムは前記電子購入ネットワークとは独立である付記３３記載の方法。
【０５２４】
（付記３６）  前記少なくとも一の条件は、価格、数量、配達日、品質、地理的場所及び匿名性からなるグループから選択される付記３３記載の方法。
【０５２５】
（付記３７）  顧客から旅行に対する購入申込と複数の航空券の売主から一以上の規程を入手する通信ポートであって、前記購入申込は少なくとも一の顧客が定義した条件を含んでおり、前記規程の各々は一以上の航空会社が定義した制限を含んでいる通信ポートと、
前記顧客が定義した条件が前記規程の少なくとも一の前記航空会社が定義した制限を満足すれば、航空券の前記売主のいずれかが前記購入申込を承諾することを了解するかどうかを決定するために、前記購入申込を前記規程に比較する処理手段とを有する航空券販売処理システム。
【０５２６】
（付記３８）  商品又は役務の販売処理システムであって、
顧客から前記商品又は役務に対する購入申込と複数の売主から一以上の規程を入手する通信ポートであって、前記購入申込は少なくとも一の顧客が定義した条件を含んでおり、前記規程の各々は一以上の売主が定義した制限を含んでいる通信ポートと、
前記顧客が定義した条件が前記規程の少なくとも一の前記売主が定義した制限を満足すれば、前記売主のいずれかが前記購入申込を承諾することを了解するかどうかを決定するために、前記購入申込を前記規程に比較する処理装置とを有する前記商品又は役務の販売処理システム。
【０５２７】
（付記３９）  前記購入申込は拘束力がある付記３７又は３８記載のシステム。
【０５２８】
（付記４０）  前記処理装置は、前記顧客が定義した条件を満足する製品を識別する付記３７又は３８記載のシステム。
【０５２９】
（付記４１）  前記制限は価格を有し、当該価格は開示されない付記３７又は３８記載のシステム。
【０５３０】
（付記４２）  前記処理装置は、前記顧客が定義した条件が前記制限を満足すれば、前記購入申込の承諾を前記顧客に与える付記３７又は３８記載のシステム。
【０５３１】
（付記４３）  前記処理装置は、前記顧客が定義した条件が前記制限を満足すれば前記顧客を拘束する付記３７又は３８記載のシステム。
【０５３２】
（付記４４）  少なくとも前記規程の一部を格納する一以上の遠隔サーバーを更に有する付記３７又は３８記載のシステム。
【０５３３】
（付記４５）  少なくとも一の歳入管理システムを更に有し、前記規程の一部は前記少なくとも一の歳入管理システムから生成される付記３７又は３８記載のシステム。
【０５３４】
（付記４６）  前記購入申込が承諾されず、かつ、前記購入申込が前記規程の少なくとも一つの所定許容範囲内にあれば、前記処理装置は代案を生成する付記３７又は３８記載のシステム。
【０５３５】
（付記４７）  前記制限は最低価格を含み、前記処理装置は、前記顧客が前記最低価格をつきとめることを防止する付記３７又は３８記載のシステム。
【０５３６】
（付記４８）  前記処理装置は、所定期間に所与の顧客から入手可能な前記購入申込の数を制限することによって、前記顧客が前記最低価格をつきとめることを防止する付記４７記載のシステム。
【０５３７】
（付記４９）  前記処理装置は、航空会社が前記購入申込を承諾するときにチケットが予約されていない場合に前記顧客に対して罰金を課することによって、前記顧客が前記最低価格をつきとめることを防止する付記４７記載のシステム。
【０５３８】
（付記５０）  前記処理装置は、前記顧客が前記購入申込に対応するチケットを予約する見込みに関する情報を含む前記顧客の信頼度を評価することによって、前記顧客が前記最低価格をつきとめることを防止する付記４７記載のシステム。
【０５３９】
（付記５１）  前記処理装置は、前記顧客が定義した条件が前記航空会社が定義した制限を満足すれば前記航空券を購入するように前記顧客を拘束することによって、前記顧客が前記最低価格をつきとめることを防止する付記４７記載のシステム。
【０５４０】
（付記５２）  旅行に対する購入申込を提出する顧客に複数の販売用座席を与える在庫割当システムであって、前記購入申込は、価格を含む少なくとも一の顧客が定義した条件を有する在庫割当システムと、
適当な料金を含む前記与えられた座席に適用可能な航空会社が定義した制限を設定する歳入管理システムと、
前記顧客が定義した条件が前記航空会社が定義した制限を満足すれば前記購入申込を承諾するかどうかを決定するために、処理装置に前記航空会社が定義した制限を与える送信機とを有する航空券販売処理システム。
【０５４１】
（付記５３）  前記顧客が定義した条件が前記航空会社が定義した制限を満足すれば一以上の前記与えられた座席に対して予約を入手する受信機、付記５２記載のシステム。
【０５４２】
（付記５４）  前記歳入管理システムは、前記購入申込を提出する前記顧客に複数の販売用座席を含む料金クラスを割り当てる付記５２記載のシステム。
【０５４３】
（付記５５）  前記歳入管理システムは、前記購入申込が、前記航空会社が定義した制限の少なくとも一つの所定許容範囲内にあれば代案を生成するための規程を設定する処理装置を更に有する付記５２記載のシステム。
【０５４４】
（付記５６）  満額払いを典型的に了解する顧客が利用を思いとどまるように前記歳入管理システムは前記航空会社が定義した制限を選択する付記５２記載のシステム。
【０５４５】
（付記５７）  顧客から旅行に対する購入申込を入手するステップであって、前記購入申込は少なくとも一の顧客が定義した条件を含んでいるステップと、
複数の航空券の売主から一以上の規程を識別するステップであって、前記規程の各々は一以上の航空会社が定義した制限を含んでいるステップと、
前記顧客が定義した条件が前記規程の少なくとも一の前記航空会社が定義した制限を満足すれば、航空券の前記売主のいずれかが前記購入申込を承諾することを了解するかどうかを決定するために、前記購入申込を前記規程に比較するステップとを有する航空券販売処理方法。
【０５４６】
（付記５８）  顧客から旅行に対する購入申込と複数のクルーズチケットの売主から一以上の規程を入手する通信ポートであって、前記購入申込は価格を含む少なくとも一の顧客が定義した条件を含んでおり、前記規程の各々は一以上のクルーズオペレータが定義した制限を含んでいる通信ポートと、
前記顧客が定義した条件が、前記規程の少なくとも一つの前記クルーズオペレータが定義した制限の各々を満足しているかどうかを決定するために、前記購入申込を前記規程に比較する処理装置とを有するクルーズチケット販売処理システム。
【０５４７】
（付記５９）  クルーズチケットの販売処理システムであって、
顧客から前記クルーズチケットに対する購入申込を入手して複数のクルーズチケットの潜在的な売主に前記購入申込を与える通信ポートであって、前記購入申込は少なくとも一の顧客が定義した条件と、資金が支払可能な汎用口座を特定する支払識別子とを含んでいる通信ポートと、
一以上の前記運輸業者が前記購入申込を承諾するかどうかを決定し、前記購入申込に対する承諾が受信されれば前記クルーズチケットを購入するように前記顧客を拘束する処理装置とを有するシステム。
【０５４８】
（付記６０）  前記クルーズオペレータが定義する制限は価格を含んでおり、当該価格は開示されない付記５８記載のシステム。
【０５４９】
（付記６１）  前記顧客が定義した条件は特定の旅程を含んでいる付記５８又は５９記載のシステム。
【０５５０】
（付記６２）  前記顧客が定義した条件はサービスレベルを含んでいる付記５８又は５９記載のシステム。
【０５５１】
（付記６３）  前記顧客が定義した条件は最高価格を含んでいる付記５８又は５９記載のシステム。
【０５５２】
（付記６４）  製品の販売処理システムであって、
顧客から前記製品に対する購入申込を入手する通信ポートであって、前記購入申込は少なくとも一の顧客が定義した条件と、資金が支払可能な汎用口座を特定する支払識別子とを含んでいる通信ポートと、
前記製品の複数の潜在的な売主が前記購入申込を承諾するかどうかを決定し、前記顧客に前記複数の承諾した売主を識別する処理装置とを有し、
前記通信ポートは前記顧客から、前記製品を与える前記承諾した売主の一人の選択を受信するシステム。
【０５５３】
（付記６５）  前記処理装置は、前記買主と前記承諾した売主との間に通信チャネルを提供する付記６４記載のシステム。
【０５５４】
（付記６６）  前記処理装置は、前記承諾した売主の各々が提供する前記製品の前記買主に電子表現物を与える付記６４記載のシステム。
【０５５５】
（付記６７）  前記処理装置は、前記製品を与える前記承諾した売主の一人を選択する前記買主に奨励策を与える付記６４記載のシステム。
【０５５６】
（付記６８）  顧客から購入申込を入手する通信ポートであって、前記購入申込は少なくとも一の顧客が定義した条件と、資金が支払可能な汎用口座を特定する支払識別子を含んでいる通信ポートと、
（ｉ）一以上の前記運輸業者が前記購入申込を承諾して前記顧客が定義した条件を満足する製品を識別するかどうかを決定し、（ｉｉ）前記購入申込に対して承諾が受信されれば前記クルーズチケットを購入するように前記顧客を拘束する処理装置とを有する製品販売処理システム。
【０５５７】
（付記６９）  顧客から購入申込を入手する通信ポートであって、前記購入申込は少なくとも一の顧客が定義した条件と、資金が支払可能な汎用口座を特定する支払識別子を含んでいる通信ポートと、
複数の潜在的な売主が前記購入申込を承諾するかどうかを決定して、前記顧客を前記複数の承諾した売主の一人から購入するように拘束する処理装置と、
その後の顧客からの購入申込に対して前記処理装置による比較のために前記追加承諾の識別子を格納するメモリ装置とを有する製品販売処理システム。
【０５５８】
（付記７０）  前記追加承諾された製品の前記識別子は、その後の顧客からの前記購入申込に対する供給ステップの前にアクセスされるメモリキャッシュに格納される付記６９記載のシステム。
【０５５９】
（付記７１）  製品販売の処理システムであって、
（ａ）顧客から前記製品の購入に対する購入申込を入手する通信ポートであって、前記購入申込は、一連の潜在的な売主からの好ましい売主のサブセットを含む少なくとも一の顧客が定義した条件を含んでいる通信ポートであって、
（ｂ）前記一連の潜在的な売主の一以上の除外された好ましい売主ではない売主に前記購入申込を与える通信ポートであって、
（ｃ）前記購入申込が前記好ましい売主の一人によって承諾される前に前記購入申込に対する代案を前記除外された売主の一人から受信する通信ポートと、
前記顧客が前記代案を承諾するかどうかを決定する処理装置とを有するシステム。
【０５６０】
（付記７２）  前記通信ポートは、前記除外されて代案発行した売主から前記製品を購入する承諾を前記顧客から受信する付記７１記載のシステム。
【０５６１】
（付記７３）  前記処理装置は、前記除外されて代案発行した売主から前記顧客が前記製品を購入するように拘束する付記７１記載のシステム。
【０５６２】
（付記７４）  前記購入申込は、前記好ましい売主の前に前記除外された売主に与えられる付記７１記載のシステム。
【０５６３】
（付記７５）  前記購入申込は、前記好ましい売主と同時に前記除外された売主に与えられる付記７１記載のシステム。
【０５６４】
（付記７６）  前記製品は商品又は役務である付記６４、６８、６９又は７１記載のシステム。
【０５６５】
（付記７７）  前記商品又は役務は航空券である付記７６記載のシステム。
【０５６６】
（付記７８）  前記商品又は役務はクルーズである付記７６記載のシステム。
【０５６７】
（付記７９）  前記商品又は役務は一以上の長距離通話である付記７６記載のシステム。
【０５６８】
（付記８０）  クルーズチケットの販売処理方法であって、
顧客から旅行に対する購入申込を入手するステップであって、前記購入申込は少なくとも一の顧客が定義した条件を含んでいるステップと、
複数のクルーズチケットの売主から一以上の規程を識別するステップであって、前記規程の各々は一以上のクルーズオペレータが定義した制限を含んでいるステップと、
前記顧客が定義した条件が前記規程の少なくとも一の前記クルーズオペレータが定義した制限の各々を満足していれば前記クルーズチケットを購入するように前記顧客を拘束するステップとを有する方法。
【０５６９】
（付記８１）  クルーズチケットの販売処理方法であって、
顧客から前記クルーズチケットに対する購入申込を入手するステップであって、前記購入申込は少なくとも一の顧客が定義した条件と、資金が支払い可能な汎用口座を特定する支払識別子を含んでいるステップと、
前記クルーズチケットの複数の潜在的な売主に前記購入申込を与えるステップと、
一以上の前記売主から前記購入申込の承諾を受信するステップと、
前記承諾が前記購入申込に対して受信されれば前記クルーズチケットを購入するように前記顧客を拘束するステップとを有する方法。
【０５７０】
（付記８２）  コンポーネント品のパッケージの販売処理システムであって、
顧客から前記パッケージに対する購入申込を受け取る通信ポートであって、前記購入申込は各コンポーネント品の説明と、資金が支払い可能な汎用口座を特定する支払識別子とを含んでいる通信ポートと、
前記パッケージ購入申込を複数のコンポーネント購入申込に分解し、各コンポーネント購入申込が一以上の潜在的な売主によって承諾されるかどうかを決定し、これにより承諾が前記コンポーネント購入申込の各々に対して受け取られれば前記パッケージを購入するように前記顧客を拘束する処理装置とを有するシステム。
【０５７１】
（付記８３）  コンポーネント品のパッケージの販売処理システムであって、
顧客から前記パッケージに対する購入申込を入手し、前記コンポーネント品の複数の売主から一以上の規程を入手する通信ポートであって、前記購入申込は前記コンポーネント品の各々に対する少なくとも一の顧客が定義した条件を含んでおり、前記規程の各々は一以上の売主が定義した制限を含んでいる通信ポートと、
前記パッケージ購入申込を複数のコンポーネント購入申込に分解する処理装置であって、
前記顧客が定義した条件が前記規程の少なくとも一の前記売主が定義した制限を満足していれば前記売主のいずれかが前記コンポーネント購入申込を承諾することを了解するかどうかを決定するために、一以上の前記コンポーネント購入申込を前記規程と比較する処理装置であって、
前記コンポーネント購入申込の各々に対して承諾が得られれば前記コンポーネント品の前記パッケージを前記顧客に与える処理装置とを有するシステム。
【０５７２】
（付記８４）  コンポーネント品のパッケージの販売処理システムであって、
顧客から前記パッケージに対する購入申込を受け取る通信ポートであって、前記購入申込は各コンポーネント品の説明と、資金が支払い可能な汎用口座を特定する支払識別子とを含んでいる通信ポートと、
一以上の潜在的な売主によって前記コンポーネント購入申込の各々が承諾されるかどうかを決定し、前記コンポーネント購入申込の各々に対して承諾が受信されればこれによって前記パッケージを購入するように前記顧客を拘束する処理装置とを有するシステム。
【０５７３】
（付記８５）  前記処理装置は、前記資金を徴収するのに前記支払識別子の利用を開始する付記８２又は８４記載のシステム。
【０５７４】
（付記８６）  前記コンポーネント購入申込はコンポーネント価格で提供される付記８２、８３又は８４記載のシステム。
【０５７５】
（付記８７）  各コンポーネントの前記コンポーネント価格は、前記パッケージ全体の市場価格に対する前記コンポーネント品の市場価格の割合に基づく付記８６記載のシステム。
【０５７６】
（付記８８）  前記処理装置は、コンポーネント購入申込を承諾する各売主と予備契約の締結を開始し、前記承諾されたコンポーネント購入申込に関連付けられたコンポーネント品は所定期間保全される付記８２、８３又は８４記載のシステム。
【０５７７】
（付記８９）  前記購入申込は合計価格を含んでおり、前記合計価格の一部はマージンとして保全される付記８２、８３又は８４記載のシステム。
【０５７８】
（付記９０）  前記処理装置は、所定期間後に前記売主によって承諾されずにいる一以上の前記コンポーネント購入申込のコンポーネント価格を増加する付記８６記載のシステム。
【０５７９】
（付記９１）  前記処理装置は、各コンポーネント購入申込に関連付けられた産業と前記売主の産業に基づいて前記売主に与えられた前記コンポーネント購入申込を選別する付記８２、８３又は８４記載のシステム。
【０５８０】
（付記９２）  前記承諾は、前記顧客が定義した条件を満足するコンポーネント製品の身元確認を更に有する付記８２、８３又は８４記載のシステム。
【０５８１】
（付記９３）  コンポーネント品のパッケージの販売処理システムであって、
顧客から前記パッケージに対する購入申込を受け取る通信ポートであって、前記購入申込は各コンポーネント品の説明と、資金が支払い可能な汎用口座を特定する支払識別子とを含んでいる通信ポートと、
前記パッケージ購入申込を複数のコンポーネント購入申込に分解し、一以上の潜在的な売主によって前記コンポーネント購入申込の各々が承諾されるかどうかを決定し、前記コンポーネント購入申込の各々に対して承諾が受信されればこれによって前記パッケージを購入するように前記顧客を拘束し、前記コンポーネントの価格は前記顧客には開示されない処理装置とを有するシステム。
【０５８２】
（付記９４）  コンポーネント品のパッケージの販売処理方法であって、
顧客から前記パッケージに対する購入申込を入手するステップであって、前記購入申込は各コンポーネント品の説明と、資金が支払い可能な汎用口座を特定する支払識別子とを含んでいるステップと、
前記パッケージ購入申込を複数のコンポーネント購入申込に分解するステップと、
一以上の潜在的な売主が前記コンポーネント申込を承諾するかどうかを決定するステップと、
前記コンポーネント購入申込の各々に対して承諾が得られれば前記パッケージを購入するように前記顧客を拘束するステップとを有する方法。
【０５８３】
（付記９５）  コンポーネント品のパッケージの販売処理方法であって、
顧客から前記パッケージに対する購入申込を入手するステップであって、前記購入申込は、前記コンポーネント品の各々に対して少なくとも一の顧客が定義した条件を含んでいるステップと、
前記パッケージ購入申込を複数のコンポーネント購入申込に分解するステップと、
前記コンポーネント品の複数の売主からの一以上の規程を識別するステップであって、前記規程の各々は一以上の売主が定義した制限を含んでいるステップと、
前記顧客が定義した条件が前記規程の少なくとも一つの前記売主が定義した制限を満足していれば前記売主のいずれかが前記コンポーネント購入申込を承諾することを了解するかどうかを決定するために一以上の前記コンポーネント購入申込を前記規程と比較するステップと、
前記コンポーネント購入申込の各々に対して承諾が入手されればコンポーネント品の前記パッケージを前記顧客に与えるステップとを有する方法。
【０５８４】
（付記９６）  顧客から一以上の通話に対する購入申込を入手し、前記購入申込を複数の潜在的な通信業者に与える通信ポートであって、前記顧客申込は、少なくとも一の顧客が定義した条件と、資金が支払い可能方法を特定する支払識別子とを含んでいる通信ポートと、
一以上の前記通信業者が前記購入申込を承諾するかどうかを決定して、前記購入申込に対して承諾が受信されれば前記顧客を前記通話の購入に拘束する処理装置とを有する長距離通話処理システム。
【０５８５】
（付記９７）  顧客から一以上の通話に対する購入申込を入手し、複数の通信業者から一以上の規程を受信する通信ポートであって、前記購入申込は価格を含む少なくとも一の顧客が定義した条件を含んでおり、前記規程の各々は一以上の通信業者が定義した制限を含んでいる通信ポートと、
前記顧客が定義した条件が前記規程の少なくとも一の前記通信業者が定義した制限の各々を満足するならば前記通信業者のいずれかが前記購入申込を承諾することを了解するかどうかを決定するために前記購入申込を前記規程に比較する処理装置とを有する長距離通話処理システム。
【０５８６】
（付記９８）  前記処理装置は、支払いを回収するのに前記支払識別子の利用を開始する付記９６記載のシステム。
【０５８７】
（付記９９）  前記資金は汎用口座から支払可能である付記９６記載のシステム。
【０５８８】
（付記１００）  前記資金は、電話サービスプロバイダーによって発行される定期的な電話サービス請求書に課金される付記９６記載のシステム。
【０５８９】
（付記１０１）  前記購入申込は、前記購入申込を送信するように構成されている電話機から受信される付記９６又は９７記載のシステム。
【０５９０】
（付記１０２）  前記購入申込は、一以上の着呼者への通話パッケージに対するものである付記９６又は９７記載のシステム。
【０５９１】
（付記１０３）  前記購入申込は、所定期間の電話サービス契約に対するものである付記９６又は９７記載のシステム。
【０５９２】
（付記１０４）  前記購入申込は、所定金額の電話サービス契約に対するものである付記９６又は９７記載のシステム。
【０５９３】
（付記１０５）  前記顧客が定義した条件は、前記一以上の通話の時刻を特定している付記９６又は９７記載のシステム。
【０５９４】
（付記１０６）  前記顧客が定義した条件は、前記一以上の通話の最小継続時間を特定している付記９６又は９７記載のシステム。
【０５９５】
（付記１０７）  前記顧客が定義した条件は、前記一以上の通話の最大継続時間を特定している付記９６又は９７記載のシステム。
【０５９６】
（付記１０８）  前記顧客が定義した条件は、着呼者の電話番号を含む付記９６又は９７記載のシステム。
【０５９７】
（付記１０９）  前記通信ポートは電話ネットワークに接続されている付記９６又は９７記載のシステム。
【０５９８】
（付記１１０）  前記通信ポートは電子ネットワークに接続されている付記９６又は９７記載のシステム。
【０５９９】
（付記１１１）  顧客から一以上の通話に対する購入申込を入手するステップであって、前記購入申込は、少なくとも一の顧客が定義した条件と、資金が支払可能な方法を特定する支払識別子とを含んでいるステップと、
前記購入申込を複数の潜在的な通信業者に与えるステップと、
前記購入申込の承諾を一以上の前記通信業者から受信するステップと、
前記購入申込に対して承諾が受信されれば前記通話を購入するように前記顧客を拘束するステップとを有する長距離通話処理方法。
【０６００】
（付記１１２）  顧客から一以上の通話に対する購入申込を入手するステップであって、前記購入申込は価格を含む少なくとも一の顧客が定義した条件を含んでいるステップと、
複数の長距離通信業者からの一以上の規程を識別するステップであって、前記規則の各々は一以上の通信業者が定義した制限を含んでいるステップと、
前記顧客が定義した条件が前記規程の少なくとも一つの前記通信業者が定義した制限を満足すれば前記通話を購入するように前記顧客を拘束するステップとを有する長距離通話処理方法。
【０６０１】
（付記１１３）  遠隔地にいる将来のイベントチケット買主と遠隔地にいる潜在的なイベントチケット売主との間に拘束力のある契約を完成するコンピュータ装置であって、
メモリ装置と、
前記メモリ装置と接続可能に配置されている処理装置とを有し、
前記処理装置は、イベントチケットに対する購入申込を前記買主から受信するように構成され、前記申込は少なくとも一の条件と、汎用金融口座からの口座番号と、前記汎用金融口座へ前記少なくとも一の条件に適合している購入に対して課金する許可を含んでおり、
前記処理装置は、前記購入申込を複数の遠隔地にいる潜在的なイベントチケット売主に送信するように構成され、
前記処理装置は、前記申込の無条件承諾を前記遠隔地にいる潜在的なイベントチケット売主の少なくとも一人から受信するように構成され、
前記処理装置は、前記イベントチケットに関連付けられている交換チケット識別子を決定するように構成され、
前記処理装置は、前記交換チケット識別子を前記買主に送信するように構成されているコンピュータ装置。
【０６０２】
（付記１１４）  前記処理装置は、前記売主から第２の汎用金融口座番号と当該第２の汎用金融口座番号に前記売主の口座に適用される罰金に対して課金する許可を受信するように更に構成されている付記１１３記載の装置。
【０６０３】
（付記１１５）  前記処理装置は、前記売主による前記イベントチケットの引渡しを表す信号を受信すると前記売主に対する支払いを処理するように更に構成されている付記１１３記載の装置。
【０６０４】
（付記１１６）  前記処理装置は、前記イベントチケットに関連付けられたチケット番号を受信すると前記売主に対する支払いを処理するように更に構成されている付記１１３記載の装置。
【０６０５】
（付記１１７）  前記処理装置は、前記イベントチケットの取り消しを処理するように更に構成されている付記１１３記載の装置。
【０６０６】
（付記１１８）  前記処理装置は、前記イベントチケットに関連付けられた前記買主の名前を受信して格納するように構成されている付記１１３記載の装置。
【０６０７】
（付記１１９）  前記処理装置は、前記イベントチケットに関連付けられたチケット識別子を開催地制御装置に送信するように更に構成されている付記１１３記載の装置。
【０６０８】
（付記１２０）  前記処理装置は、前記開催地制御装置から前記交換チケット識別子を受信するように更に構成されていることによって前記交換チケット識別子を決定するように構成されている付記１１９記載の装置。
【０６０９】
（付記１２１）  前記交換チケット識別子は原チケット識別子を含んでいる付記１１３記載の装置。
【０６１０】
（付記１２２）  イベントチケットに対する交換識別子を管理するコンピュータ装置であって、
メモリ装置と、
前記メモリ装置と接続可能に配置されている処理装置とを有し、前記処理装置は、交換チケット番号に対する要求を中央制御装置から受信するように構成され、前記要求は原チケット番号を含んでおり、前記処理装置は前記交換チケット番号を決定し、前記交換チケット番号を前記中央制御装置に送信し、前記原チケット番号と前記関連交換チケット番号を前記メモリ装置に格納するように更に構成されているコンピュータ装置。
【０６１１】
（付記１２３）  前記処理装置は、買主の身元を表す身元データを受信し、前記原チケット番号と前記交換チケット番号との関連付けるために前記身元データを前記メモリ装置に格納するように更に構成されている付記１２２記載の装置。
【０６１２】
（付記１２４）  イベントチケットに対する交換識別子を認証するコンピュータ装置であって、
チケット識別子と、当該チケット識別子に関連付けられた第１の交換チケット識別子とを格納するメモリ装置と、
出力装置と、
前記メモリ装置と前記出力装置に接続可能に配置される処理装置とを有し、当該処理装置は、
第２の交換チケット識別子を電子的に受信し、
結果を決定するために前記第２の交換チケット識別子を前記第１の交換チケット識別子と比較し、
前記第２の交換チケット識別子の有効性を示すために前記出力装置を介して前記結果を表示するように構成されているコンピュータ装置。
【０６１３】
（付記１２５）  前記メモリは、前記第１の交換チケット識別子に関連付けられた買主の身元を表すデータを更に格納し、前記処理装置は、前記身元データを検索し、前記買主の前記身元を表示するために前記表示装置を介して前記身元データを表示するように更に構成されている付記１２４記載の装置。
【０６１４】
（付記１２６）  少なくとも一の条件信号を有する申込信号を受信するステップであって、前記申込信号はこれによって顧客から少なくとも一の条件を有する申込を定義するステップと、
資金が支払可能な口座を特定する支払識別子信号を受信するステップと、
第三者から前記申込に関連した情報信号を受信するステップと、
前記申込信号と前記情報信号とを少なくとも一の売主に送信するステップと、
前記少なくとも一の売主の少なくとも一人から、前記送信された申込信号と前記送信された情報信号に応答する承諾信号を受信するステップと、
一の承諾信号を選択するステップとを有する品物販売処理方法。
【０６１５】
（付記１２７）  記憶装置と、
当該記憶装置に接続された処理装置とを有し、
前記記憶装置は処理装置を制御するプログラムを格納し、
前記処理装置は前記プログラムにより、
少なくとも一の条件信号を含む申込信号を受信し、当該申込信号はこれによって顧客からの少なくとも一の条件を有する申込を定義し、
資金が支払可能な口座を特定する支払識別子信号を受信し、
第三者から申込に関連した情報信号を受信し、
前記申込信号と前記情報信号を少なくとも一の売主に送信し、
前記少なくとも一の売主の少なくとも一人から前記送信された申込信号と前記送信された情報信号に応答する承諾信号を受信し、
一の承諾信号を選択するように動作する品物販売処理装置。
【０６１６】
（付記１２８）  前記処理装置は、選択された承諾信号が受信された売主を特定するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６１７】
（付記１２９）  前記処理装置は、前記資金を回収するのに前記支払識別子信号の利用を開始するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６１８】
（付記１３０）  前記処理装置は、前記支払識別子信号を前記少なくとも一の売主に送信するように前記プログラムにより更に動作する付記１２９記載の装置。
【０６１９】
（付記１３１）  前記処理装置は、前記受信された申込信号を有効にし、これによって前記受信された申込信号が所定の有効化基準に適合するかどうかを決定するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６２０】
（付記１３２）  前記処理装置は、前記有効化ステップが前記受信された申込信号が前記所定の有効化基準に適合していることを決定する場合にのみ、前記申込信号と前記情報信号を送信するように前記プログラムにより更に動作する付記１３１記載の装置。
【０６２１】
（付記１３３）  前記処理装置は、前記最初の受信された承諾信号を選択するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６２２】
（付記１３４）  前記処理装置は、複数の承諾信号が受信されれば前記複数の承諾信号の無作為な一つを選択するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６２３】
（付記１３５）  前記処理装置は、複数の承諾信号が受信される場合に、所定の選別基準に従って前記複数の承諾信号を選別し、前記選別された複数の承諾信号の最初のものを選択するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６２４】
（付記１３６）  前記処理装置は、複数の承諾信号が受信されている場合に、
前記複数の承諾信号の一つに相当する売主を各々表している複数の売主信号を送信し、
選択された売主信号を表す選択信号を受信し、これによって対応する承諾信号を表示し、
前記選択された売主信号に相当する前記承諾信号を選択するように前記プログラムにより更に動作する付記１２７記載の装置。
【０６２５】
（付記１３７）  借主端末と少なくとも一の貸主端末との間のローン販売処理装置であって、
記憶装置と、
当該記憶装置、前記借主端末及び前記少なくとも一の貸主端末に接続された処理装置とを有し、
前記記憶装置は前記処理装置を制御するプログラムを格納し、
前記処理装置は前記プログラムにより
少なくとも一の条件信号を含む申込信号を借主端末から受信し、前記申込信号はこれによって借主から少なくとも一の条件を有する申込を定義し、
支払可能な口座を特定する支払識別子信号を借主端末から受信し、
第三者からクレジットカード情報を含む情報信号を受信し、
前記申込信号と前記情報信号を前記少なくとも一の貸主端末に送信し、
少なくとも一の貸主から前記送信された申込信号と前記送信された情報信号に応答する承諾信号を受信し、
一の承諾信号を選択し、
前記選択された承諾信号が受信された前記貸主端末を識別するように動作するローン販売処理装置。
【０６２６】
（付記１３８）  前記処理装置は、前記受信された申込信号を有効にして、これによって前記受信された申込信号が所定の有効化基準に適合するかどうかを決定するように前記プログラムにより更に動作する付記１３７記載の装置。
【０６２７】
（付記１３９）  前記処理装置は、前記受信された申込信号が意味のある申込を定義しているかどうかを決定するために金融計算を実行するように前記プログラムにより更に動作する付記１３８記載の装置。
【０６２８】
（付記１４０）  前記少なくとも一の条件信号はローン額、定期的支払額、ローン期間及び利率の少なくとも一つを表示する付記１３７記載の装置。
【０６２９】
（付記１４１）  前記少なくとも一の条件信号は定期的支払額と利率の一つの最低のものに対する要求を表示している付記１３７記載の装置。
【０６３０】
（付記１４２）  前記申込信号は、ローン額を示す第１の条件信号と、定期的支払額を示す第２の条件信号と、最低利率の要求を示す第３の条件信号とを含んでいる付記１３７記載の装置。
【０６３１】
（付記１４３）  前記処理装置は、各承諾信号が利率を含んでいる複数の承諾信号が受信されれば、前記複数の承諾信号の中で最低利率を有する承諾信号を選択するように前記プログラムにより更に動作する付記１４２記載の装置。
【０６３２】
（付記１４４）  前記申込信号は、ローン額を示す第１の条件信号と、最低の定期的支払額を示す第２の条件信号と、利率を示す第３の条件信号とを含んでいる付記１３７記載の装置。
【０６３３】
（付記１４５）  前記処理装置は、各承諾信号が定期的支払額を含んでいる複数の承諾信号が受信されれば、前記複数の承諾信号の中で最低の定期的支払額を有する承諾信号を選択するように前記プログラムにより更に動作する付記１４４記載の装置。
【０６３４】
（付記１４６）  前記申込信号は、ローン期間を示す第４の条件信号を更に有している付記１４４記載の装置。
【０６３５】
（付記１４７）  前記申込信号は、最大ローン期間を示す第４の条件信号を更に有している付記１４４記載の装置。
【０６３６】
（付記１４８）  前記申込信号は、ローン額を示す第１の条件信号と、定期的支払額を示す第２の条件信号と、利率を示す第３の条件信号とを含んでいる付記１３７記載の装置。
【０６３７】
（付記１４９）  前記第２の条件信号は月払額を示している付記１４８記載の装置。
【０６３８】
（付記１５０）  前記申込信号は、ローン期間を示す第４の条件信号を更に含んでいる付記１４８記載の装置。
【０６３９】
（付記１５１）  前記申込信号は、ローン額を示す第１の条件信号と、ローン期間を示す第２の条件信号と、利率を示す第３の条件信号とを含んでいる付記１３７記載の装置。
【０６４０】
（付記１５２）  前記申込信号は、定期的支払額を示す第４の信号を更に含んでいる付記１５１記載の装置。
【０６４１】
（付記１５３）  前記第４の条件信号は月払額を示している付記１５２記載の装置。
【０６４２】
（付記１５４）  記憶装置と、
当該記憶装置、前記借主端末及び前記少なくとも一の貸主端末に接続された処理装置とを有し、
前記記憶装置は前記処理装置を制御するプログラムを格納し、
前記処理装置は前記プログラムにより
少なくとも位置の条件信号を含む申込信号を受信し、前記申込信号は顧客からの少なくとも一の条件を有する申込を定義し、
資金が支払可能な口座を特定する支払識別子信号を受信し、
第三者から前記申込に関連した情報信号を受信し、
複数の売主の各々から少なくとも一の規程信号を格納し、各規程信号は少なくとも一の売主が定義した制限を含み、
前記申込信号と前記情報信号とを少なくとも一の規程信号と比較し、
前記少なくとも一の条件と前記条件信号がいずれかの規程の各売主が定義した制限を満足するかどうかを決定するように動作する品物販売処理装置。
【０６４３】
（付記１５５）  前記処理装置は、複数の規程が満足される場合に、前記複数の満足された規程の一つを選択するように前記プログラムにより更に動作する付記１５４記載の装置。
【０６４４】
（付記１５６）  前記複数の満足された規程の無作為な一つを選択するように前記プログラムにより更に動作する付記１５５記載の装置。
【０６４５】
（付記１５７）  前記処理装置は、
前記複数の満足された規程の一つに対応する貸主を各々表す複数の貸主信号を送信し、
選択された貸主信号を表す選択信号を受信し、これによって対応する規程を表示し、
前記選択された貸主信号に対応する前記満足された規程を選択するように前記プログラムにより更に動作する付記１５５記載の装置。
【０６４６】
（付記１５８）  買主と複数の売主の少なくとも一人との間の取引をコンピュータを利用して容易にする方法であって、
申込価格を含む条件付購入申込を前記コンピュータに入力するステップと、
クレジットカード口座を特定する支払識別子を前記コンピュータに入力するステップであって、前記支払識別子は前記条件付購入申込に関連付けられているステップと、
前記支払識別子を受信した後に前記複数の売主に前記条件付購入申込を出力するステップと、
売主からの承諾を前記コンピュータに入力するステップであって、前記承諾は前記条件付購入申込に応答しているステップと、
前記支払識別子を利用することによって前記売主に支払いをするステップとを有する方法。
【０６４７】
（付記１５９）  承諾を前記コンピュータに入力する前記ステップは、一連の売主の各構成員からの承諾を前記コンピュータに入力するステップであって、前記一連の売主は少なくとも一の売主を有し、各承諾は前記条件付購入申込に応答しているステップを有し、
一の受信された承諾を選択して、これによって前記一連の売主の中で選択された売主を決定するステップを更に有し、
支払いをする前記ステップは、前記支払識別子を利用することによって前記選択された売主に支払いをする付記１５８記載の方法。
【０６４８】
（付記１６０）  所定額がクレジットカード口座で利用可能かどうかを決定するステップを更に有する付記１５８記載の方法。
【０６４９】
（付記１６１）  承諾が受信されれば前記支払識別子を支払いに利用するために許可要求を前記買主に出力するステップと、
前記要求に応答した前記買主からの前記許可を前記コンピュータに入力するステップを更に有する付記１５８記載の方法。
【０６５０】
（付記１６２）  承諾を前記コンピュータに入力する前記ステップは、一連の売主の各々からの承諾を前記コンピュータに入力するステップを有する付記１５８記載の方法。
【０６５１】
（付記１６３）  前記条件付購入申込がアクティブであるアクティブ期間を決定するステップを更に有し、承諾を前記コンピュータに入力する前記ステップは前記アクティブ期間に行われる付記１５８記載の方法。
【０６５２】
（付記１６４）  前記条件付購入申込の撤回を、前記承諾を受信する前記ステップ後に前記コンピュータに入力するステップを更に有し、支払いをする前記ステップは前記売主に所定額の支払いをするステップを有する付記１５８記載の方法。
【０６５３】
（付記１６５）  一の受信された承諾を選択する前記ステップは、最初に受信された承諾を決定して、これによって一連の売主の中で最初の売主を決定するステップを有し、
支払いをする前記ステップは前記支払識別子を利用することによって前記最初の売主に支払いをするステップを有する付記１５９記載の方法。
【０６５４】
（付記１６６）  買主と複数の売主の少なくとも一人との間の取引を容易にする装置であって、
記憶装置と、
当該記憶装置に接続された処理装置とを有し、
前記記憶装置は前記処理装置を制御するプログラムを有し、
前記処理装置は前記プログラムにより、
申込価格を有する条件付購入申込を受信し、
前記支払識別子の受信後に前記条件付購入申込が前記複数の売主に入手可能になるようにし、
前記条件付購入申込に応答する承諾を売主から受信し、
前記支払識別子を利用することによって前記選択された売主に支払いをするように動作する装置。
【０６５５】
（付記１６７）  買主と複数の売主の少なくとも一人との間の取引をコンピュータを利用して容易にする方法であって、
申込価格を含む条件付購入申込を前記コンピュータに入力するステップと、
金融口座を特定する支払識別子を前記コンピュータに入力するステップであって、前記支払識別子は前記条件付購入申込に関連付けられているステップと、
承諾が受信された後に前記支払識別子を支払いに利用するために許可要求を前記買主に出力するステップと、
前記要求に応答して前記買主からの許可を前記コンピュータに入力するステップと、
支払識別子を受信した後に前記条件付購入申込を前記複数の売主に出力するステップと、
売主からの承諾を前記コンピュータに入力するステップであって、前記承諾は前記条件付購入申込に応答しているステップと、
前記支払識別子を利用することによって前記売主に支払いをするステップとを有する方法。
【０６５６】
（付記１６８）  買主と複数の売主の少なくとも一人との間の取引を容易にする装置であって、
記憶装置と、
当該記憶装置に接続された処理装置とを有し、
前記記憶装置は前記処理装置を制御するプログラムを有し、
前記処理装置は、前記プログラムにより、
申込価格を有する条件付購入申込を受信し、
前記条件付購入申込に関連付けられて金融口座を特定する支払識別子を受信し、
承諾が受信されれば前記支払識別子を支払いに利用するために許可要求を前記買主に出力し、
前記要求に応答した前記買主からの前記許可を受信し、
前記支払識別子を受信した後に前記条件付購入申込を前記複数の売主に送信し、
前記送信された条件付購入申込に応答した承諾を売主から受信し、
前記支払識別子を利用して前記売主に前記支払いをするように動作する装置。
【０６５７】
（付記１６９）  前記処理装置は、前記プログラムにより
一連の売り手の各構成員から承諾を受信し、前記一連の売主は少なくとも一の売主を有し、各承諾は前記条件付購入申込に応答し、
一の受信された承諾を選択し、これによって前記一連の売主の中で選択された売主を決定し、
前記支払識別子を利用して前記選択され売主に支払いをするように更に動作する付記１６６記載の装置。
【０６５８】
（付記１７０）  前記処理装置は、前記プログラムにより
受信された最初の承諾を決定し、これによって前記一連の売主の中で最初の売主を決定し、
前記支払識別子を利用して前記最初の売主に支払いをするように更に動作する付記１６９記載の装置。
【０６５９】
（付記１７１）  前記処理装置は、所定額が前記クレジットカード口座で利用可能かどうかを決定するように前記プログラムにより更に動作する付記１６６記載の装置。
【０６６０】
（付記１７２）  前記処理装置は、前記買主から前記売主に支払いを移転するように前記プログラムにより更に動作する付記１６６記載の装置。
【０６６１】
（付記１７３）  前記処理装置は、前記売主に前記支払識別子を送信するように前記プログラムにより更に動作する付記１６６記載の装置。
【０６６２】
（付記１７４）  前記処理装置は、前記プログラムにより
承諾が受信されれば前記支払識別子を支払いに利用するために前記買主に許可要求を出力し、
前記要求に応答した前記買主からの前記許可を受信するように更に動作する付記１６６記載の装置。
【０６６３】
（付記１７５）  前記処理装置は、一連の売主の各々から承諾を受信するように前記プログラムにより更に動作する付記１６６記載の装置。
【０６６４】
（付記１７６）  前記条件付購入申込は満了日を有し、当該満了日前には撤回不能である付記１６６記載の装置。
【０６６５】
（付記１７７）  前記処理装置は、前記プログラムにより
前記条件付購入申込がアクティブであるアクティブ期間を決定し、
当該アクティブ期間中は承諾を受信するように更に動作する付記１６６記載の装置。
【０６６６】
（付記１７８）  前記処理装置は、前記プログラムにより
承諾の受信後に前記条件付購入申込の撤回を受信し、
前記売主に所定額の支払いをするように更に動作する付記１６６記載の装置。
【０６６７】
（付記１７９）  承諾を前記コンピュータに入力する前記ステップは、一連の売主の各構成員からの承諾を前記コンピュータに入力するステップであって、前記一連の売主は少なくとも一の売主を有し、各承諾は前記条件付購入申込に応答しているステップを有し、
一の受信された承諾を選択して、これによって前記一連の売主の中で選択された売主を決定するステップを更に有し、
支払いをする前記ステップは、前記支払識別子を利用することによって前記選択された売主に支払いをする付記１６７記載の方法。
【０６６８】
（付記１８０）  受信された承諾を選択する前記ステップは、最初に受信された承諾を決定して、これによって前記少なくとも一の売主の中で最初の売主を決定するステップを有し、
支払いをする前記ステップは、前記支払識別子を利用することによって前記最初の売主に支払いをするステップを有する付記１７９記載の方法。
【０６６９】
（付記１８１）  前記金融口座はクレジットカード口座である付記１６７記載の方法。
【０６７０】
（付記１８２）  所定額が前記クレジットカード口座で利用可能かどうかを決定するステップを更に有する付記１８１記載の方法。
【０６７１】
（付記１８３）  前記買主から前記売主に支払いを移転するステップを更に有する付記１６７記載の方法。
【０６７２】
（付記１８４）  支払いを移転する前記ステップは、前記支払識別子を前記売主に送信するステップを有する付記１６７記載の方法。
【０６７３】
（付記１８５）  承諾を前記コンピュータに入力する前記ステップは、一連の売り手の各々から承諾を前記コンピュータに入力するステップを有する付記１６７記載の方法。
【０６７４】
（付記１８６）  前記条件付購入申込は満了日を有し、当該満了日前には撤回不能である付記１６７記載の方法。
【０６７５】
（付記１８７）  前記条件付購入申込がアクティブであるアクティブ期間を決定するステップとを更に有し、承諾を前記コンピュータに入力する前記ステップは前記アクティブ期間に行われる付記１６７記載の方法。
【０６７６】
（付記１８８）  承諾を受信する前記ステップの後に前記条件付購入申込の撤回を受信するステップを更に有し、支払をする前記ステップは前記売主に所定額の支払いをすることを有している付記１６７記載の装置。
【０６７７】
（付記１８９）  前記処理装置は、前記プログラムにより
一連の売り手の各構成員から承諾を受信し、前記一連の売主は少なくとも一の売主を有し、各承諾は前記条件付購入申込に応答し、
一の受信された承諾を選択し、これによって前記一連の売主の中で選択された売主を決定し、
前記支払識別子を利用して前記選択され売主に支払いをするように更に動作する付記１６８記載の装置。
【０６７８】
（付記１９０）  前記処理装置は、前記プログラムにより
受信された最初の承諾を決定し、これによって前記一連の売主の中で最初の売主を決定し、
前記支払識別子を利用して前記最初の売主に支払いをするように更に動作する付記１８８記載の装置。
【０６７９】
（付記１９１）  前記金融口座はクレジットカード口座である付記１６８記載の装置。
【０６８０】
（付記１９２）  前記処理装置は、所定額が前記クレジットカード口座で利用可能かどうかを決定するように前記プログラムにより更に動作する付記１９０記載の装置。
【０６８１】
（付記１９３）  前記処理装置は、前記買主から前記売主に支払いを転送するように前記プログラムにより更に動作する付記１６８記載の装置。
【０６８２】
（付記１９４）  前記処理装置は、前記支払識別子を前記売主に送信するように前記プログラムにより更に動作する付記１６８記載の装置。
【０６８３】
（付記１９５）  前記処理装置は、一連の売主の各々から承諾を受信するように前記プログラムにより更に動作する付記１６８記載の装置。
【０６８４】
（付記１９６）  前記条件付購入申込は満了日を有し、当該満了日前には撤回不能である付記１６８記載の装置。
【０６８５】
（付記１９７）  前記処理装置は、前記条件付購入申込がアクティブであるアクティブ期間を決定し、前記アクティブ期間中に承諾を受信するように前記プログラムにより更に動作する付記１６８記載の装置。
【０６８６】
（付記１９８）  前記処理装置は、承諾の受信後に前記条件付購入申込の撤回を受信し、前記売主に所定額の支払をするように前記プログラムにより更に動作する付記１６８記載の装置。
【図面の簡単な説明】
【０６８７】
【図１】本発明の第１実施例を示している。
【図２】中央制御装置の一実施例を示すブロック図である。
【図３】売主インターフェースの一実施例を示すブロック図である。
【図４】買主インターフェースの一実施例を示すブロック図である。
【図５】条件付購入申込がどのように生成されるかを示す実施例を示している。
【図６】中央制御装置による条件付購入申込の承諾を示す実施例を示している。
【図７】条件付購入申込のアクティベーションを示す実施例を示している。
【図８】アクティブな条件付購入申込の点検の一実施例を示している。
【図９】条件付購入申込を選択する売主を示す実施例を示している。
【図１０】条件付購入申込の拘束力を示す実施例を示している。
【図１１】条件付購入申込の拘束力を示す実施例を示している。
【図１２】買主と売主との間の商品と支払いの交換の例示的手続を示している。
【図１３】例示的支払方法を示している。
【図１４】暗号プロトコルを使用する例示的認証手続を示している。
【図１５】暗号プロトコルを使用する例示的認証手続を示している。
【図１６】暗号プロトコルを使用する例示的認証手続を示している。
【図１７】暗号プロトコルを使用する例示的認証手続を示している。
【図１８】売主による代案の例示的実施例を示している。
【図１９】売主による代案の例示的実施例を示している。
【図２０】信託サーバーと保証代理人の使用を示す実施例を示している。
【図２１】本発明の一実施例による条件付購入申込（ＣＰＯ）管理システムを示す概略ブロック図である。
【図２２】図２１の例示的ＣＰＯ管理中央サーバーの概略ブロック図である。
【図２３】図２１の例示的な機密保持（がなされている）航空会社サーバーの概略ブロック図である。
【図２４】図２１の例示的な中央予約システムの概略ブロック図である。
【図２５ａ】図２１の例示的な予約管理システム（ＲＭＳ）の概略ブロック図である。
【図２５ｂ】従来の価格付け・割当処理と図３９のＣＰＵ規程生成処理中における、ＲＭＳと、航空会社予約システムと、図２５ａに示された様々なデータベース間の対話を示している。
【図２５ｃ】予測需要に対する所与の料金クラスの航空券の時間に対する現実の需要を示している。
【図２６】図２２の顧客データベースからのサンプル表を示している。
【図２７】図２２の航空会社データベースからのサンプル表を示している。
【図２８】図２２及び図２４のフライトスケジュールデータベースからのサンプル表を示している。
【図２９ａ】総括的に、図２２のＣＰＯデータベースからのサンプル表を示している。
【図２９ｂ】総括的に、図２２のＣＰＯデータベースからのサンプル表を示している。
【図３０ａ】図２３の機密保持がなされている航空会社規程データベースからのサンプル表を示している。
【図３０ｂ】総括的に、図２３の機密保持航空会社規程データベースの代替的なサンプル表を示している。
【図３０ｃ】総括的に、図２３の機密保持航空会社規程データベースの代替的なサンプル表を示している。
【図３１】図２３の代案規程データベースからのサンプル表を示している。
【図３２】図２３の機密保持がなされている航空会社会計データベースからのサンプル表を示している。
【図３３】図２４及び図２５ａの価格付け・制限データベースからのサンプル表を示している。
【図３４】図２４及び図２５ａの座席割当データベースからのサンプル表を示している。
【図３５】図２５ａの予測・需要分析データベースからのサンプル表を示している。
【図３６ａ】総括的に、図２２のＣＰＯ管理中央サーバーによって実行される例示的ＣＰＯ管理処理を説明するフローチャートである。
【図３６ｂ】総括的に、図２２のＣＰＯ管理中央サーバーによって実行される例示的ＣＰＯ管理処理を説明するフローチャートである。
【図３６ｃ】総括的に、図２２のＣＰＯ管理中央サーバーによって実行される例示的ＣＰＯ管理処理を説明するフローチャートである。
【図３７ａ】総括的に、図２３の機密保持航空会社サーバーによって実行される例示的な評価処理を説明するフローチャートである。
【図３７ｂ】総括的に、図２３の機密保持航空会社サーバーによって実行される例示的な評価処理を説明するフローチャートである。
【図３８】図２３の機密保持航空会社サーバーによって実行される例示的会計処理を説明するフローチャートである。
【図３９】図２５の収入管理システムによって実行される例示的ＣＰＯ規程生成処理を説明するフローチャートである。
【図４０ａ】総括的に、クルーズの実施例に対する図２２のＣＰＯデータベースからの代替的なサンプル表を示している。
【図４０ｂ】総括的に、クルーズの実施例に対する図２２のＣＰＯデータベースからの代替的なサンプル表を示している。
【図４１】クルーズの実施例に対する図２３の機密保持規程データベースからの代替的なサンプル表を示している。
【図４２】図２２のＣＰＯ管理中央サーバーによって実行されることができる例示的な後販売多重拘束処理を説明するフローチャートである。
【図４３】図４４ａ及び図４４ｂのフローチャートに関連して図２２のＣＰＯ管理中央サーバーによって実行可能な除外オペレータ代案データベースからのサンプル表を示している。
【図４４ａ】総括的に、図２２のＣＰＯ管理中央サーバーによって実行可能な例示的な除外売主ＣＰＯ評価処理を説明するフローチャートである。
【図４４ｂ】総括的に、図２２のＣＰＯ管理中央サーバーによって実行可能な例示的な除外売主ＣＰＯ評価処理を説明するフローチャートである。
【図４５】本発明の一実施例によるパッケージ条件付購入申込（ＣＰＯ）管理システムを示す概略ブロック図である。
【図４６】図４５の例示的な中央制御装置の概略ブロック図である。
【図４７】図４５の例示的な機密保持サーバーの概略ブロック図である。
【図４８】図４５の例示的な買主又は売主インターフェースの概略ブロック図である。
【図４９】図４６の買主データベースからのサンプル表を示している。
【図５０】図４６の売主データベースからのサンプル表を示している。
【図５１】図４６のパッケージＣＰＯデータベースからのサンプル表を示している。
【図５２】図４６のコンポーネントＣＰＯデータベースからのサンプル表を示している。
【図５３】図４６の市場価格データベースからのサンプル表を示している。
【図５４ａ】図４７の機密保持売主規程データベースからのサンプル表を示している。
【図５４ｂ】図４７の機密保持売主規程データベースからのサンプル表を示している。
【図５５ａ】総括的に、図４６の中央制御装置によって実行される例示的なパッケージＣＰＯ掲載処理を説明するフローチャートである。
【図５５ｂ】総括的に、図４６の中央制御装置によって実行される例示的なパッケージＣＰＯ掲載処理を説明するフローチャートである。
【図５５ｃ】総括的に、図４６の中央制御装置によって実行される例示的なパッケージＣＰＯ掲載処理を説明するフローチャートである。
【図５６ａ】総括的に、図４６の中央制御装置によって実行される例示的なパッケージＣＰＯ監視処理を説明するフローチャートである。
【図５６ｂ】総括的に、図４６の中央制御装置によって実行される例示的なパッケージＣＰＯ監視処理を説明するフローチャートである。
【図５６ｃ】総括的に、図４６の中央制御装置によって実行される例示的なパッケージＣＰＯ監視処理を説明するフローチャートである。
【図５７】図４７の機密保持サーバーによって実行される例示的なコンポーネントＣＰＯ規程評価処理を説明するフローチャートである。
【図５８ａ】本発明の一実施例による条件付購入申込（ＣＰＯ）管理システムを示す概略ブロック図である。
【図５８ｂ】本発明の代替的な実施例による条件付購入申込（ＣＰＯ）管理システムを示す概略ブロック図である。
【図５９】図５８Ａ及び図５８Ｂの発呼者によって利用される例示的な電話機の斜視図である。
【図６０】図５８のＣＰＯ管理システムによって使用される中央サーバーの概略ブロック図である。
【図６１】図６０の顧客データベースからのサンプル表を示している。
【図６２】図６０の通信業者データベースからのサンプル表を示している。
【図６３】図６０の公表価格データベースからのサンプル表を示している。
【図６４】図６０のＣＰＯデータベースからのサンプル表を示している。
【図６５ａ】総括的に、図６０の中央サーバーによって実行される例示的なＣＰＯ管理処理を説明するフローチャートである。
【図６５ｂ】総括的に、図６０の中央サーバーによって実行される例示的なＣＰＯ管理処理を説明するフローチャートである。
【図６６ａ】図６０の中央サーバーによって実行される例示的なＩＶＲＵ処理を説明するフローチャートである。
【図６６ｂ】図６０の中央サーバーによって実行される例示的なＩＶＲＵ処理を説明するフローチャートである。
【図６７】本発明の一実施例によるシステムの概略図である。
【図６８】図６７のシステムで使用される中央制御装置の概略図である。
【図６９】図６７のシステムで使用される遠隔ユーザー端末の概略図である。
【図７０】図６７のシステムで使用される開催地制御装置の概略図である。
【図７１ａ】図６７のシステムで使用されるイベント表の内容を示す表である。
【図７１ｂ】図６７のシステムで使用される開催地表の内容を示す表である。
【図７１ｃ】図６７のシステムで使用される顧客表の内容を示す表である。
【図７１ｄ】図６７のシステムで使用される申込表の内容を示す表である。
【図７１ｅ】図６７のシステムで使用される取引表の内容を示す表である。
【図７２ａ】図６７のシステムで使用されるチケット表の内容を示す表である。
【図７２ｂ】図６７のシステムで使用される交換チケット表の内容を示す表である。
【図７３ａ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７３ｂ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７３ｃ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７３ｄ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７３ｅ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７３ｆ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７３ｇ】本発明の一実施例によるインターネットでイベントチケットを購入する保証された申込を提出して承諾する方法を示すフロー図である。
【図７４】本発明に従って与えられる製品販売処理システムの概略図である。
【図７５ａ】図７４のシステムの中央制御装置の実施例の概略図である。
【図７５ｂ】図７４のシステムの中央制御装置の他の実施例の概略図である。
【図７６】図７５ａ及び図７５ｂの中央制御装置の借主データベースの概略図である。
【図７７】図７５ａ及び図７５ｂの中央制御装置の貸主データベースの概略図である。
【図７８】図７５ａ及び図７５ｂの中央制御装置の申込データベースの概略図である。
【図７９】図７５ａ及び図７５ｂの中央制御装置のクレジット報告データベースの概略図である。
【図８０】図７５ａ及び図７５ｂの中央制御装置の担保データベースの概略図である。
【図８１ａ】図７５ａの中央制御装置の応答データベースの概略図である。
【図８１ｂ】図７５ｂの中央制御装置の規程データベースの概略図である。
【図８２ａ】借主端末と貸主端末間のローン販売処理方法を示すフローチャートである。
【図８２ｂ】借主端末と貸主端末間のローン販売処理方法を示すフローチャートである。
【図８２ｃ】借主端末と貸主端末間の別のローン販売処理方法を示すフローチャートである。
【符号の説明】
【０６８８】
２００      中央制御装置
２０５      中央演算処理装置（ＣＰＵ）
２３０      支払処理装置
２５０      データ記憶装置
【図１】
0004921447.tif 000002
【図２】
0004921447.tif 000003
【図３】
0004921447.tif 000004
【図４】
0004921447.tif 000005
【図５】
0004921447.tif 000006
【図６】
0004921447.tif 000007
【図７】
0004921447.tif 000008
【図８】
0004921447.tif 000009
【図９】
0004921447.tif 000010
【図１０】
0004921447.tif 000011
【図１１】
0004921447.tif 000012
【図１２】
0004921447.tif 000013
【図１３】
0004921447.tif 000014
【図１４】
0004921447.tif 000015
【図１５】
0004921447.tif 000016
【図１６】
0004921447.tif 000017
【図１７】
0004921447.tif 000018
【図１８】
0004921447.tif 000019
【図１９】
0004921447.tif 000020
【図２０】
0004921447.tif 000021
【図２１】
0004921447.tif 000022
【図２２】
0004921447.tif 000023
【図２３】
0004921447.tif 000024
【図２４】
0004921447.tif 000025
【図２５ａ】
0004921447.tif 000026
【図２５ｂ】
0004921447.tif 000027
【図２５ｃ】
0004921447.tif 000028
【図２６】
0004921447.tif 000029
【図２７】
0004921447.tif 000030
【図２８】
0004921447.tif 000031
【図２９ａ】
0004921447.tif 000032
【図２９ｂ】
0004921447.tif 000033
【図３０ａ】
0004921447.tif 000034
【図３０ｂ】
0004921447.tif 000035
【図３０ｃ】
0004921447.tif 000036
【図３１】
0004921447.tif 000037
【図３２】
0004921447.tif 000038
【図３３】
0004921447.tif 000039
【図３４】
0004921447.tif 000040
【図３５】
0004921447.tif 000041
【図３６ａ】
0004921447.tif 000042
【図３６ｂ】
0004921447.tif 000043
【図３６ｃ】
0004921447.tif 000044
【図３７ａ】
0004921447.tif 000045
【図３７ｂ】
0004921447.tif 000046
【図３８】
0004921447.tif 000047
【図３９】
0004921447.tif 000048
【図４０ａ】
0004921447.tif 000049
【図４０ｂ】
0004921447.tif 000050
【図４１】
0004921447.tif 000051
【図４２】
0004921447.tif 000052
【図４３】
0004921447.tif 000053
【図４４ａ】
0004921447.tif 000054
【図４４ｂ】
0004921447.tif 000055
【図４５】
0004921447.tif 000056
【図４６】
0004921447.tif 000057
【図４７】
0004921447.tif 000058
【図４８】
0004921447.tif 000059
【図４９】
0004921447.tif 000060
【図５０】
0004921447.tif 000061
【図５１】
0004921447.tif 000062
【図５２】
0004921447.tif 000063
【図５３】
0004921447.tif 000064
【図５４ａ】
0004921447.tif 000065
【図５４ｂ】
0004921447.tif 000066
【図５５ａ】
0004921447.tif 000067
【図５５ｂ】
0004921447.tif 000068
【図５５ｃ】
0004921447.tif 000069
【図５６ａ】
0004921447.tif 000070
【図５６ｂ】
0004921447.tif 000071
【図５６ｃ】
0004921447.tif 000072
【図５７】
0004921447.tif 000073
【図５８ａ】
0004921447.tif 000074
【図５８ｂ】
0004921447.tif 000075
【図５９】
0004921447.tif 000076
【図６０】
0004921447.tif 000077
【図６１】
0004921447.tif 000078
【図６２】
0004921447.tif 000079
【図６３】
0004921447.tif 000080
【図６４】
0004921447.tif 000081
【図６５ａ】
0004921447.tif 000082
【図６５ｂ】
0004921447.tif 000083
【図６６ａ】
0004921447.tif 000084
【図６６ｂ】
0004921447.tif 000085
【図６７】
0004921447.tif 000086
【図６８】
0004921447.tif 000087
【図６９】
0004921447.tif 000088
【図７０】
0004921447.tif 000089
【図７１ａ】
0004921447.tif 000090
【図７１ｂ】
0004921447.tif 000091
【図７１ｃ】
0004921447.tif 000092
【図７１ｄ】
0004921447.tif 000093
【図７１ｅ】
0004921447.tif 000094
【図７２ａ】
0004921447.tif 000095
【図７２ｂ】
0004921447.tif 000096
【図７３ａ】
0004921447.tif 000097
【図７３ｂ】
0004921447.tif 000098
【図７３ｃ】
0004921447.tif 000099
【図７３ｄ】
0004921447.tif 000100
【図７３ｅ】
0004921447.tif 000101
【図７３ｆ】
0004921447.tif 000102
【図７３ｇ】
0004921447.tif 000103
【図７４】
0004921447.tif 000104
【図７５ａ】
0004921447.tif 000105
【図７５ｂ】
0004921447.tif 000106
【図７６】
0004921447.tif 000107
【図７７】
0004921447.tif 000108
【図７８】
0004921447.tif 000109
【図７９】
0004921447.tif 000110
【図８０】
0004921447.tif 000111
【図８１ａ】
0004921447.tif 000112
【図８１ｂ】
0004921447.tif 000113
【図８２ａ】
0004921447.tif 000114
【図８２ｂ】
0004921447.tif 000115
【図８２ｃ】
0004921447.tif 000116