有条件购买要约管理系统
专利汇可以提供有条件购买要约管理系统专利检索，专利查询，专利分析的服务。并且本 发明 是用于实现双边购买者驱动商务的方法和装置。本发明允许预期的买方(400)大范围地向潜在的卖方传送可约定的购买要约,使卖方(300)可方便地搜索相关的买方的购买要约,并使卖方基于买方的购买要约潜在地约定买方达成合同。在一优选的 实施例 中,本发明的装置包括从预期的买方接收可约定的购买要约的 控制器 (200)。该控制器使购买要约对潜在的卖方可得,并然后确定一个或多个卖方是否愿意接受给定的购买要约。本发明的方法和装置可用于因特网上以及诸如语音电话这种传统的通信系统上。，下面是有条件购买要约管理系统专利的具体信息内容。
1.一种用于完成远程预期的买方和远程潜在的卖方之间有约束力 的合同的计算机装置，该装置包括：
存储器装置；以及
与所述存储器装置通信而配置的处理器，所述处理器被配置为从 远程预期的买方接收(a)包含至少一个条件的购买要约，及(b)用于规 定从其可为满足所述至少一个条件的购买支付资金的通用财务帐户的 支付标识符；所述处理器还配置为向多个远程潜在的卖方传输购买要 约，并至少从远程潜在的卖方之一接收要约的无条件承诺。
2.根据权利要求1的计算机装置，其中所述处理器还配置为启动 支付标识符的使用以实现从买方对购买的支付。
3.根据权利要求1的计算机装置，其中通用财务帐户是一信用 卡帐户。
4.一种用于完成远程预期的买方和远程潜在的卖方之间有约束 力的合同的计算机装置，该装置包括：
存储器装置；以及
与所述存储器装置通信而配置的处理器，所述处理器被配置为从 远程预期的买方接收(a)包含至少一个条件的购买要约，及(b)用于规 定从其可为满足所述至少一个条件的购买支付资金的电子结算系统的 通用财务帐户的支付标识符；所述处理器还配置为向远程潜在的卖方 的电子购物网络传输购买要约，至少从远程潜在的卖方之一接收要约 的无条件承诺，并启动支付标识符的使用通过对所述电子结算系统的 所述通用财务帐户的收费以进行对所述购买的支付。
5.根据权利要求4的计算机装置，其中所述电子结算系统是一 信用卡系统。
6.根据权利要求4的计算机装置，其中所述电子结算系统是与 所述电子购物网络分开的。
7.根据权利要求1或4的计算机装置，其中至少一个条件是从 由价格、数量、投送日期、质量、地理位置、及匿名性组成的一组中 选择的。
8.根据权利要求1或4的计算机装置，其中处理器被配置为通 知第一个接受的卖方，它已经进入与买方法律上约定的合同。
9.根据权利要求1或4的计算机装置，其中处理器还被配置为 向买方传输通知，购买要约由第一个接受的卖方接受。
10.根据权利要求9的计算机装置，其中向买方通知承诺标识了 第一个接受的卖方。
11.根据权利要求1或4的计算机装置，其中购买要约包括过期 日期，并在该日期之前是不可改变的。
12.根据权利要求1或4的计算机装置，其中如果在预定的时间 段内购买要约没有被接受，则购买要约过期。
13.根据权利要求1或4的计算机装置，其中如果购买要约没有 被接受而过期，则处理器还配置为通知买方，购买要约已经失效。
14.根据权利要求1或4的计算机装置，其中购买要约直到预定 的日期之前是无效的。
15.根据权利要求1或4的计算机装置，其中处理器还配置为确 定在任何承诺之前要约是否已经取消。
16.根据权利要求1或4的计算机装置，其中购买要约包含这样 的条件，假如买方向第一个接受的卖方支付了规定罚金，则在第一个 接受的卖方接受要约之后，买方有权撤回其要约。
17.根据权利要求1或4的计算机装置，其中购买要约是由预期 的买方加密签署的。
18.根据权利要求1或4的计算机装置，其中处理器还配置为从 买方收集对购买的支付。
19.根据权利要求1或4的计算机装置，其中处理器还配置为向 第一个接受的卖方传输买方的信用卡信息和授权。
20.根据权利要求1或4的计算机装置，其中处理器还配置为， 把从买方收集的支付置于由第三方保存的帐户。
21.根据权利要求1或4的计算机装置，其中购买的支付是基于 分期付款从买方收集的。
22.根据权利要求1或4的计算机装置，其中处理器还配置为向 第一个接受的卖方汇付对购买的支付。
23.根据权利要求1或4的计算机装置，其中处理器还配置为从 买方向第一个接受的卖方传输支付。
24.根据权利要求23的计算机装置，其中对购买的支付是在购 买要约的承诺时立即向第一个接受的卖方汇付的。
25.根据权利要求1或4的计算机装置，其中处理器还配置为对 潜在的买方和潜在的卖方之间交换的传输的原始性和完整性的至少一 个进行鉴别。
26.根据权利要求1或4的计算机装置，其中处理器还配置为在 不标识预期的买方的情形下使购买要约对潜在的卖方可得。
27.根据权利要求1或4的计算机装置，其中处理器还配置为在 不显示卖方的身份的情形下通知买方，他们的要约被接受。
28.根据权利要求1或4的计算机装置，其中购买要约是对于货 物。
29.一种用于以电子方式完成远程预期的买方和远程潜在的卖方 之间有约束力的合同的方法，该方法包括步骤：
从远程预期的买方以电子方式接收(a)包含至少一个条件的购买 要约，及(b)用于规定从其可为满足所述至少一个条件的购买支付资 金的通用财务帐户的支付标识符；
以电子方式使购买要约对于多个远程潜在的卖方可得；以及
至少从远程潜在的卖方之一以电子方式接收要约的无条件承诺。
30.根据权利要求29的方法，其中至少一个条件是从由价格、 数量、投送日期、质量、地理位置、及匿名性组成的一组中选择的。
31.一种用于以电子方式完成远程预期的买方和远程潜在的卖方 之间有约束力的合同的方法，该方法包括步骤：
从远程预期的买方以电子方式接收包含至少两个条件的购买要 约，一个条件称买方将有权从来自多个潜在的卖方的承诺中选择预期 的买方将被其约定的至少一个承诺；
以电子方式使购买要约对于多个潜在的卖方可得；
至少从多个潜在的卖方以电子方式接收要约的无条件承诺；
以电子的方式向预期的买方传输多个无条件承诺；以及
以电子方式从预期的买方接收买方将被约定履行的无条件承诺的 至少一个选择。
32.根据权利要求31的方法，其中所述两个条件之一是从由价 格、数量、投送日期、质量、地理位置、及匿名性组成的一组中选择 的。
33.一种用于以电子方式完成远程预期的买方和远程潜在的卖方 之间有约束力的合同的方法，该方法包括步骤：
从远程预期的买方以电子方式接收(a)包含至少一个条件的购买 要约，及(b)来自一电子结算系统的通用财务帐户的支付标识符，从 该电子结算系统可为满足所述至少一个条件的购买支付资金；
以电子方式使购买要约对于远程潜在的卖方的电子购物网络可 得；
以电子方式从至少一个远程潜在的卖方接收要约的无有条件购 买；以及
以电子的方式启动支付标识符的使用，通过对所述电子结算系统 的所述通用财务帐户收费对所述购买进行支付。
34.根据权利要求33的方法，其中所述电子结算系统是信用卡 系统。
35.根据权利要求33的方法，其中所述电子结算系统是与所述 电子购物网络分开的。
36.根据权利要求33的方法，其中至少一个条件是从由价格、 数量、投送日期、质量、地理位置、及匿名性组成的一组中选择的。
37.一种用于处理航空公司机票销售的系统，该系统包括：
用于从顾客获得对旅行的购买要约并从航空公司机票的多个卖方 获得一个或多个规则的通信端口，所述购买要约包含顾客定义的至少 一个条件，且所述每一规则包含一个或多个航空公司定义的限制；以 及
用于比较所述购买要约与所述规则的处理装置，以便如果所述顾 客定义的条件满足所述航空公司定义的至少所述规则之一的限制，确 定所述航空公司机票的任何卖方是否愿意接受所述购买要约。
38.一种用于处理货物或服务销售的系统，该系统包括：
用于从顾客获得对所述货物或服务的购买的购买要约、并从多个 卖方获得一个或多个规则的通信端口，所述购买要约包含顾客定义的 至少一个条件，且所述每一规则包含一个或多个卖方定义的限制；以 及
用于比较所述购买要约与所述规则的处理器，以便如果所述顾客 定义的条件满足所述卖方定义的至少所述规则之一的限制，确定任何 所述卖方是否愿意接受所述购买要约。
39.根据权利要求37或38的系统，其中所述购买要约是有约束 力的约定。
40.根据权利要求37或38的系统，其中所述处理器标识满足所 述顾客定义的条件的产品。
41.根据权利要求37或38的系统，其中所述限制包括价格，且 所述价格是不公开的。
42.根据权利要求37或38的系统，其中如果所述顾客定义的条 件满足所述限制，则所述处理器向所述顾客提供所述购买要约的承 诺。
43.根据权利要求37或38的系统，其中如果所述顾客定义的条 件满足所述限制，则所述处理器约定所述顾客。
44.根据权利要求37或38的系统，还包括一个或多个远程服务 器，用于存储所述规则的至少一部分。
45.根据权利要求37或38的系统，还包括至少一个收益管理系 统，且其中至少所述规则的一部分是通过所述至少一个收益管理系统 产生的。
46.根据权利要求37或38的系统，其中如果所述购买要约没有 被接受且所述购买要约在至少一个所述规则的预定的允限内，则所述 处理器产生一还价。
47.根据权利要求37或38的系统，其中所述限制包含一最小价 格且所述处理器防止所述顾客识别所述最小价格。
48.根据权利要求47的系统，其中所述处理器通过限制在预定 的周期内可从给定的顾客获得所述购买要约的数目，防止所述顾客识 别所述最小价格。
49.根据权利要求47的系统，其中如果当航空公司接受了所述 购买要约时机票没有被定座，则所述处理器通过对所述顾客征收罚金 来防止所述顾客识别所述最小价格。
50.根据权利要求47的系统，其中通过评估包含关于所述顾客 将对应于所述购买要约对一机票定座的似然率的信息的所述顾客的信 誉，所述处理器防止所述顾客识别所述最小价格。
51.根据权利要求47的系统，其中如果所述顾客定义的条件满 足所述航空公司定义的限制，则所述处理器通过约定所述顾客购买所 述航空公司机票防止所述顾客识别所述最小价格。
52.一种用于处理航空公司机票销售的系统，所述系统包括：
存量分配系统，用于提供多个座位供向提交用于旅行的购买要约 的顾客销售，包含顾客定义的至少一个条件的所述购买要约包括价 格；
收益管理系统，用于建立航空公司定义的限制，这些限制适用于 包含适当票价的所述提供的座位；以及
用于向一处理器提供所述航空公司定义的限制的发送器，以确定 如果所述顾客定义的条件满足所述航空公司定义的限制，是否接受所 述购买要约。
53.根据权利要求52的系统，用于获得对一个或多个所述提供的 座位的保留的接收器，如果所述顾客定义的条件满足所述航空公司定 义的限制。
54.根据权利要求52的系统，其中所述收益管理系统向提交所 述购买要约的顾客分配包含所述多个供销售的座位的票价等级。
55.根据权利要求52的系统，其中所述收益管理系统还包括一 处理器，如果所述购买要约在所述航空公司定义的至少一个限制的预 定允限之内，该处理器用于建立产生还价的规则。
56.根据权利要求52的系统，其中所述收益管理系统选择所述 航空公司定义的限制，以阻止由一般愿意付全票价的顾客使用。
57.一种处理航空公司机票销售的方法，该方法包括步骤：
获得来自顾客对旅行的购买要约，所述购买要约包含顾客定义的 包含价格的至少一个条件；
从多个航空公司机票卖方识别一个或多个规则，每一所述规则包 含一个或多个航空公司定义的限制；以及
比较所述购买要约与所述规则，以确定如果所述顾客定义的条件 满足所述航空公司定义的至少一个所述规则的限制，航空公司机票的 任何所述卖方是否愿意接受所述购买要约。
58.一种用于处理巡游票销售的系统，包括：
用于从顾客获得对旅行的购买要约并用于从巡游票的多个卖方接 收一个或多个规则的通信端口，所述购买要约包含顾客定义的包含价 格的至少一个条件，且每一所述规则包含一个或多个巡游经营者定义 的限制；以及
用于比较所述购买要约与所述规则的处理器，以便确定顾客定义 的所述条件是否满足巡游经营者定义的至少一个所述规则每一限制。
59.一种用于处理巡游票销售的系统，包括：
用于从顾客获得对所述巡游票的购买要约并用于向所述巡游票多 个潜在的卖方提供所述购买要约的通信端口，所述购买要约包含顾客 定义的至少一个条件，以及用于规定从其可支付资金的通用帐户的支 付标识符；以及
处理器，用于确定一个或多个所述运输公司是否接受所述购买要 约，并如果对于所述购买要约收到承诺，则用于约定所述顾客购买所 述巡游票。
60.根据权利要求58的系统，其中所述巡游经营者定义的限制包 括价格，且所述价格是不公开的。
61.根据权利要求58或59的系统，其中所述顾客定义条件包括 规定的旅程。
62.根据权利要求58或59的系统，其中顾客定义的所述条件包 括服务等级。
63.根据权利要求58或59的系统，其中顾客定义的所述条件包 括最大价格。
64.一种用于处理产品销售的系统，包括：
用于从顾客获得对所述产品的购买要约的通信端口，所述购买要 约包含顾客定义的至少一个条件，及用于规定从其可支付资金的通用 帐户的支付标识符；
处理器，用于确定是否多个潜在的所述产品的卖方接受所述购买 要约，并用于向所述顾客标识所述多个接受的卖方；以及
所述通信端口接收来自所述顾客对所述接受的卖方之一的选择以 提供所述产品。
65.根据权利要求64的系统，其中所述处理器在所述买方和所述 接受的卖方之间提供通信渠道。
66.根据权利要求64的系统，其中所述处理器向所述买方提供 由每一接受的卖方提供的所述产品的电子表示。
67.根据权利要求64的系统，其中所述处理器向所述买方提供 鼓励因素，用于选择所述接受的卖方之一以提供所述产品。
68.一种用于处理产品销售的系统，包括：
用于从顾客获得购买要约的通信端口，所述购买要约包含顾客定 义的至少一个条件及用于规定从其可支付资金的通用帐户的支付标识 符；以及
处理器，用于(i)确定一个或多个所述运输公司是否接受所述购买 要约并标识满足所述顾客定义的条件的产品，以及(ii)如果收到对所 述购买要约的承诺，约定所述顾客购买所述巡游票。
69.一种用于处理产品销售的系统，包括：
用于从顾客获得购买要约的通信端口，所述购买要约包含顾客定 义的至少一个条件及用于规定从其可支付资金的通用帐户的支付标识 符；
用于确定是否多个潜在的卖方接受所述购买要约并用于约定所述 顾客从所述多个接受的卖方之一购买的处理器；以及
存储器装置，用于存储所述附加的承诺的标识符，以供由所述处 理器对照来自后继的顾客的购买要约进行比较。
70.根据权利要求69的系统，其中所述附加的接受的产品的所述 标识符存储在存储器高速缓冲器中，该缓冲器在对来自后继顾客的所 述购买要约的所述提供步骤之前被访问。
71.一种用于处理产品销售的系统，包括：
通信端口，用于：
(a)从顾客获得对所述产品购买的购买要约，所述购买要约包含 顾客定义的至少一个条件，该条件含有来自潜在卖方集合的优选的卖 方的子集；
(b)向在不是优选的卖方的潜在的卖方所述集合中一个或多个被 排除的卖方提供所述购买要约；以及
(c)在所述购买要约被所述优选的卖方之一接受之前，从所述被排 除卖方之一接收对所述购买要约的还价；以及
用于确定所述顾客是否接收所述还价的处理器。
72.根据权利要求71的系统，其中所述通信端口接收来自所述顾 客购买来自所述被排除的还价的卖方的所述产品的承诺。
73.根据权利要求71的系统，其中所述处理器约定所述顾客购 买来自所述被排除的还价的卖方的所述产品。
74.根据权利要求71的系统，其中所述购买要约在所述优选的 卖方之前提供给所述被排除的卖方。
75.根据权利要求71的系统，其中所述购买要约与所述优选的 卖方同时提供给所述被排除的卖方。
76.根据权利要求64、68、69或71的系统，其中所述产品是货 物或服务。
77.根据权利要求76的系统，其中所述货物或服务是航空公司 机票。
78.根据权利要求76的系统，其中所述货物或服务是巡游。
79.根据权利要求71的系统，其中所述货物或服务是一个或多 个长途电话通话。
80.一种处理巡游票销售的方法，包括以下步骤：
从顾客获得对旅行的购买要约，所述购买要约包含顾客定义的至 少一个条件；
标识来自多个巡游票卖方的一个或多个规则，每一所述规则包含 巡游经营者定义的一个或多个限制；以及
如果所述顾客定义的条件满足巡游经营者定义的至少一个所述规 则的每一限制，则约定所述顾客购买所述巡游票。
81.一种处理巡游票销售的方法，包括以下步骤：
从顾客获得对所述巡游票的购买要约，所述购买要约包含顾客定 义的至少一个条件及用于规定从其可支付资金的通用帐户的支付标识 符；
向所述巡游票的多个潜在卖方提供所述购买要约；
从一个或多个所述卖方接收所述购买要约的承诺；以及
如果收到对所述购买要约的承诺，则约定所述顾客购买所述巡游 票。
82.一种用于处理成分条款组合销售的系统，包括：
从顾客接收对所述组合的购买要约的通信端口，所述购买要约包 含每一成分条款的描述及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，它用于把所述组合购买要约分解为多个成分购买要约并 确定每一所述成分购买要约是否由一个或多个潜在的卖方接受，并从 而如果收到对每一所述成分购买要约的承诺，则约定所述顾客购买所 述组合。
83.一种用于处理成分条款组合销售的系统，包括：
用于从顾客获得对所述组合的购买要约并用于从多个所述成分条 款的卖方获得一个或多个规则的通信端口，所述购买要约包含对每一 所述成分条款顾客定义的至少一个条件，且每一所述规则包含一个或 多个卖方定义的限制；以及
处理器，它进行：
分解所述组合购买要约为多个成分购买要约；
比较一个或多个所述成分购买要约与所述规则，以确如果所述顾 客定义的条件满足所述卖方定义的至少一个所述规则的限制，则任何 所述卖方是否愿意接受所述成分购买要约；以及
如果对每一所述成分购买要约获得承诺，则向所述顾客提供成分 条款的所述组合。
84.一种用于处理成分条款组合销售的系统，包括：
从顾客接收对所述组合的购买要约的通信端口，所述购买要约包 含每一成分条款的描述及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，它确定每一所述成分购买要约是否由一个或多个潜在的 卖方接受，并从而如果对每一所述成分购买要约收到承诺，则约定所 述顾客购买所述组合。
85.根据权利要求82或84的系统，其中所述处理器启动所述支 付标识符的使用以便收集所述资金。
86.根据权利要求82、83或84的系统，其中所述成分购买要约 以成分价格提供。
87.根据权利要求86的系统，其中每一成分的所述成分价格基 于成分条款的市场价值对整个组合的市场价值的百分比。
88.根据权利要求82、83或84的系统，其中所述处理器启动与 每一接受成分购买要约的卖方达成初步协议，从而保留与所述被接受 的成分购买要约相关的成分条款达预定的时间周期。
89.根据权利要求82、83或84的系统，其中所述购买要约包括 总价格，且所述总价格的一部分作为保险金保留。
90.根据权利要求86的系统，其中所述处理器增加在预定时间 周期过后仍然未被所述卖方接受的一个或多个所述成分购买要约的成 分价格。
91.根据权利要求82、83或84的系统，其中所述处理器基于与 每一成分购买要约相关的行业及所述卖方的行业过滤提供给所述卖方 的成分购买要约。
92.根据权利要求82、83或84的系统，其中所述承诺还包括满 足所述顾客定义的条件的成分产品的识别。
93.一种用于处理成分条款组合销售的系统，包括：
从顾客接收对所述组合的购买要约的通信端口，所述购买要约包 含每一成分条款的描述及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，把所述组合购买要约分解为多个成分购买要约并确定每 一所述成分购买要约是否由一个或多个潜在的卖方以成分价格接受， 并从而如果收到对每一所述成分购买要约的承诺，则约定所述顾客购 买所述组合，其中所述成分价格对所述顾客不公开。
94.一种处理成分条款组合销售的方法，它包括步骤：
从顾客获得对所述组合的购买要约，所述购买要约包含每一成分 条款的说明及用于规定从其可支付资金的通用帐户的支付标识符；
把所述组合购买要约分解为多个成分购买要约；
确定一个或多个潜在的卖方是否接受所述成分购买要约；以及
如果收到对所述每一成分购买要约的承诺，则约定所述顾客购买 所述组合。
95.一种处理成分条款组合销售的方法，它包括步骤：
从顾客获得对所述组合的购买要约，所述购买要约包含顾客定义 的对每一所述成分条款至少一个条件；
把所述组合购买要约分解为多个成分购买要约；
识别来自所述成分条款的多个卖方的一个或多个规则，每一所述 规则包含一个或多个卖方定义的限制；以及
比较一个或多个所述成分购买要约与所述规则，以确定如果所述 顾客定义的条件满足所述卖方定义的至少一个所述规则的限制，则任 何所述卖方是否愿意接受所述成分购买要约；以及
如果对每一所述成分购买要约获得承诺，则向所述顾客提供成分 条款的所述组合。
96.一种用于处理长途通话的系统，该系统包括：
用于从顾客获得对一个或多个通话的购买要约并用于向多个潜在 的电信公司提供所述购买要约的通信端口，所述购买要约包含顾客定 义的至少一个条件，以及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，用于确定一个或多个所述电信公司是否接受所述购买要 约，并如果收到对于所述购买要约的承诺，则用于约定所述顾客购买 所述电话通话。
97.一种用于处理长途通话的系统，该系统包括：
用于从顾客获得对一个或多个电话通话的购买要约并用于从多个 电信公司接收一个或多个规则的通信端口，所述购买要约包含顾客定 义的包含价格的至少一个条件，且每一所述规则包含一个或多个电信 公司定义的限制；以及
用于比较所述购买要约与所述规则的处理器，以便确定如果顾客 定义的所述条件满足电信公司定义的至少一个所述规则每一限制，则 任何所述电信公司是否愿意接受所述购买要约。
98.根据权利要求96的系统，其中所述处理器启动所述支付标识 符的使用以收集支付。
99.根据权利要求96的系统，其中所述资金可从通用帐户支付。
100.根据权利要求96的系统，其中所述资金可由电话服务提供 者发出的定期电话服务帐单收取。
101.根据权利要求96或97的系统，其中所述购买要约是从配 置为传输所述购买要约的电话机接收的。
102.根据权利要求96或97的系统，其中所述购买要约是对向 一个或多个被呼叫方的通话的组合。
103.根据权利要求96或97的系统，其中所述购买要约是对预 定时间周期电话服务合同。
104.根据权利要求96或97的系统，其中所述购买要约是对预 定金额电话服务合同。
105.根据权利要求96或97的系统，其中所述顾客定义的条件 规定一天中对所述一个或多个电话通话的特定时间。
106.根据权利要求96或97的系统，其中所述顾客定义的条件 规定了对所述一个或多个电话通话最小的持续时间。
107.根据权利要求96或97的系统，其中所述顾客定义的条件 规定了对所述一个或多个电话通话最大的持续时间。
108.根据权利要求96或97的系统，其中所述顾客定义的条件 包含被呼叫方的电话号码。
109.根据权利要求96或97的系统，其中所述通信端口连接到 电话网络。
110.根据权利要求96或97的系统，其中所述通信端口连接到 电子网络。
111.一种处理长途通话的方法，包括以下步骤：
从顾客获得对一个或多个电话通话的购买要约，所述购买要约包 含顾客定义的至少一个条件及用于规定从其可支付资金的通用帐户的 支付标识符；
向所述多个潜在电信公司提供所述购买要约；
从一个或多个所述电信公司接收所述购买要约的承诺；以及
如果收到对所述购买要约的承诺，则约定所述顾客购买所述电话 通话。
112.一种处理长途通话的方法，包括以下步骤：
从顾客获得对一个或多个电话通话的购买要约，所述购买要约包 含顾客定义的包含价格的至少一个条件；
标识来自多个长途电信公司的一个或多个规则，每一所述规则包 含电信公司定义的一个或多个限制；以及
如果所述顾客定义的条件满足电信公司定义的至少一个所述规则 的每一限制，则约定所述顾客购买所述电话通话。
113.一种用于完成远程预期的活动门票买方和远程潜在的活动门 票卖方之间的有约束力的合同的计算机装置，该装置包括：
存储器装置；及
配置与所述存储器装置连接的处理器，配置所述处理器进行：
从所述买方接收对所述活动门票的购买要约，所述要约包含至少 一个条件、来自通用财务帐户的帐户号码、及向所述通用财务帐户对 满足所述至少一个条件的购买收费的授权；
向多个远程潜在的活动门票卖方传输所述购买要约；
从至少一个所述远程潜在的活动门票卖方接收所述要约的无条件 承诺；
确定与所述活动门票相关的替换门票标识符；以及
向所述买方传输所述替换门票的标识符。
114.根据权利要求113的装置，其中所述处理器还配置为，从所 述卖方接收第二通用财务帐户号码，及用于向所述卖方的帐户征收罚 金对所述第二通用帐户号码收费的授权。
115.根据权利要求113的装置，其中所述处理器还配置为，在 收到表示所述活动门票由所述卖方交出的信号时，处理向所述卖方的 支付。
116.根据权利要求113的装置，其中所述处理器还配置为，在 收到与所述活动门票相关的门票号码时处理对所述卖方的支付。
117.根据权利要求113的装置，其中所述处理器还配置为，处 理所述活动门票的删除。
118.根据权利要求113的装置，其中所述处理器还配置为，接 收并存储与所述活动门票相关的所述买方的姓名。
119.根据权利要求113的装置，其中所述处理器还配置为，向 活动地点控制器传输与所述活动门票相关的门票标识符。
120.根据权利要求119的装置，其中所述处理器配置为，通过 进一步配置从所述活动地点控制器接收所述替换门票的标识符确定替 换门票的标识符。
121.根据权利要求113的装置，其中所述替换门票标识符包含 原始门票标识符。
122.一种用于对活动门票管理替换标识符的计算机装置，该装置 包括：
存储器装置；以及
被配置与所述存储器装置连接的处理器，所述处理器配置为从中 央控制器接收对替换门票号码的请求，所述请求包括原始门票号码； 所述处理器还配置为确定所述替换门票号码、向所述中央控制器传输 所述替换门票号码；并在所述存储器装置存储所述原始门票号码和所 述相关的替换门票号码。
123.根据权利要求122的装置，其中所述处理器配置为，接收 表示买方身份的标识数据，并在所述存储器装置与所述原始门票号码 及所述替换门票号码相关存储所述标识数据。
124.一种用于对活动门票鉴别替换标识符的计算机装置，它包 括：
用于存储门票标识符和与所述门票标识符相关的第一替换门票标 识符的存储器装置；
输出装置；以及
配置为与所述存储器及所述输出装置连接的处理器，所述处理器 配置为：
以电子方式接收第二替换门票标识符；
比较所述第二替换门票标识符与所述第一替换门票标识符以确定 结果；以及
通过所述输出装置显示所述结果以指出所述第二替换门票标识符 的真实性。
125.根据权利要求124的装置，其中所述存储器还存储表示与所 述第一替换标门票标识符相关的买方的身份的数据，且所述处理器还 配置为检索所述标识数据，并通过所述输出装置显示所述标识数据以 指出所述买方的身份。
126.一种处理项目销售的方法，包括：
接收包含至少一个条件信号的要约信号，由此要约信号定义具有 来自顾客的至少一个条件的要约；
接收用于规定从其可支付资金的帐户的支付标识符信号；
从第三方接收与要约相关的信息信号；
向至少一个卖方传输要约信号和信息信号；
从至少一个的至少一个卖方接收响应传输的要约信号和传输的信 息信号的承诺信号；以及
选择一个承诺信号。
127.一种用于处理项目销售的装置，包括：
存储装置；及
与存储装置连接的处理器，
存储装置存储用于控制处理器的程序；及
处理器对程序可操作以便：
接收包含至少一个条件信号的要约信号，由此要约信号定义具有 来自顾客的至少一个条件的要约；
接收用于规定从其可支付资金的帐户的支付标识符信号；
从第三方接收与要约相关的信息信号；
向至少一个卖方传输要约信号和信息信号；
从至少一个的至少一个卖方接收响应传输的要约信号和传输的信 息信号的承诺信号；以及
选择一个承诺信号。
128.权利要求127的装置，其中处理器还对程序可操作以便：
识别从其收到所选择的承诺信号的卖方。
129.根据权利要求127的装置，其中处理器还对程序可操作以 便：
启动支付标识符的使用以收集资金。
130.根据权利要求129的装置，其中处理器还对程序可操作以 便向至少一个卖方传输支付标识符信号。
131.根据权利要求127的装置，其中处理器还对程序可操作以 便：
验证收到的要约信号，从而确定收到的要约信号是否满足预定的 验证准则。
132.根据权利要求131的装置，其中处理器还对程序可操作， 以便仅当验证的步骤确定收到的要约信号满足预定的验证准则才传输 要约信号和信息信号。
133.根据权利要求127的装置，其中处理器还对程序可操作以 便选择第一个收到的承诺信号。
134.根据权利要求127的装置，其中处理器还对程序可操作以 便如果收到多个承诺信号则随机选择多个承诺信号之一。
135.根据权利要求127的装置，其中处理器还对程序可操作以 便
如果收到多个承诺信号，
根据预定的分类准则对多个承诺信号进行分类，以及
选择被分类的多个承诺信号的第一个。
136.根据权利要求127的装置，其中处理器还对程序可操作以 便
如果收到多个承诺信号，
传输多个卖方信号，每一信号表示对应于多个承诺信号之一的一 个卖方，
接收表示被选择的卖方信号的的选择信号，并从而指示对应的承 诺信号，以及
选择对应于被选择的卖方信号的承诺信号。
137.一种用于处理借入者终端与至少一个出借者终端之间的贷款 的销售的装置，包括：
存储装置；及
与存储装置、借入者终端和至少一个出借者终端连接的处理器，
存储装置存储
用于控制处理器的程序；及
处理器对程序可操作以便
从借入者终端接收包含至少一个条件信号的要约信号，由此要约 信号定义具有来自借入者的至少一个条件的要约；
从借入者终端接收用于规定从其可支付资金的帐户的支付标识符 信号；
从第三方接收包含信用信息的信息信号；
向至少一个出借者传输要约信号和信息信号；
从至少一个出借者终端接收响应传输的要约信号和传输的信息信 号的承诺信号；
选择一个承诺信号；以及
标识从其收到被选择的承诺信号的出借者终端。
138.根据权利要求137的装置，其中处理器还对程序可操作以 便：
验证收到的要约信号，从而确定收到的要约信号是否满足预定的 验证准则。
139.根据权利要求138的装置，其中处理器还对程序可操作以 便：
进行财务计算确定收到的要约信号是否定义了有意义的要约。
140.根据权利要求137的装置，其中至少一个条件信号指示贷 款数额、定期支付数额、贷款周期和利率中的至少一个。
141.根据权利要求137的装置，其中至少一个条件信号指示对 支付数额和利率之一的最低者的要求。
142.根据权利要求137的装置，其中要约信号包括：
指示贷款数额的第一条件信号，
指示定期支付数额的第二条件信号，及
指示对最低利率的要求的第三条件信号。
143.根据权利要求142的装置，其中处理器还对程序可操作以 便：
如果收到其中每一承诺信号包含利率的多个承诺信号，则选择多 个承诺信号的具有最低利率的承诺信号。
144.根据权利要求137的装置，其中要约信号包括：
指示贷款数额的第一条件信号，
指示对最低定期支付数额要求的第二条件信号，及
指示利率的第三条件信号。
145.根据权利要求144的装置，其中处理器还对程序可操作以 便：
如果收到其中每一承诺信号包含定期支付数额的多个承诺信号， 则选择多个承诺信号的具有最低定期支付数额的承诺信号。
146.根据权利要求144的装置，其中要约信号还包括：
表示贷款周期的第四条件信号。
147.根据权利要求144的装置，其中要约信号还包括：
表示最大贷款周期的第四条件信号。
148.根据权利要求137的装置，其中要约信号还包括：
表示贷款数额的第一条件信号，
表示定期支付数额的第二条件信号，及
表示利率的第三条件信号。
149.根据权利要求148的装置，其中第二条件信号指示按月支 付数额。
150.根据权利要求148的装置，其中要约信号还包括：
表示贷款周期的第四条件信号。
151.根据权利要求137的装置，其中要约信号还包括：
表示贷款数额的第一条件信号，
表示贷款周期的第二条件信号，及
表示利率的第三条件信号。
152.根据权利要求151的装置，其中要约信号还包括：
表示定期支付数额的第四条件信号。
153.根据权利要求152的装置，其中第四条件信号表示按月支 付数额。
154.一种用于处理项目销售的装置，包括：
存储装置；及
与存储装置、借入者终端和至少一个出借者终端连接的处理器，
存储装置存储
用于控制处理器的程序；及
处理器对程序可操作以便
接收包含至少一个条件信号的要约信号，要约信号定义具有来自 顾客的至少一个条件的要约；
接收用于规定从其可支付资金的帐户的支付标识符信号；
从第三方接收与要约相关的信息信号；
存储来自多个卖方的每一个的至少一个规则信号，每一规则信号 包含至少一个卖方定义的限制；
比较要约信号和信息信号与至少一个规则信号；以及
确定至少一个条件和信息信号是否满足任何规则的卖方定义的每 一限制。
155.根据权利要求154的装置，其中处理器还对程序可操作以 便：
如果多个规则被满足，则选择多个被满足的规则之一。
156.根据权利要求155的装置，其中处理器还对程序可操作以 便：
随机则选择多个被满足的规则之一。
157.根据权利要求155的装置，其中处理器还对程序可操作以 便：
传输多个出借者信号，每一信号表示对应于多个被满足的规则之 一的出借者；
接收表示被选择的出借者信号的选择信号，并从而指示对应的规 则；以及
选择对应于所选择的出借者信号的被满足的规则。
本发明涉及使用电子网络对产品的购买提出要约的顾客进行产品 销售的方法和装置。
大多数产品销售系统是卖方驱动的，从而卖方定价、包装并配置 产品，而买方决定是否接受。传统上，卖方必须吸引买方并完成销售。 这样，在买方驱动的系统中，交易的广告成本和这种广告不成功所伴 随的风险将落到卖方头上。
通常，货物和服务是在使用卖方驱动的议定书的零售环境中被销 售的，从而卖方一般设定了买方可能接受或拒绝的不可协商的价格。 其它商业形式提供了更多的灵活性，并允许要约和还价的交换。例如 在拍卖中，买方找不到卖方，而是卖方吸引众多的买方，他们集体决 定最终售价，除非拍品不保留而被售出，否则卖方随后可能拒绝该价 格。其它商业系统，诸如NASDAQ或纽约证券交易所(NYSE)，是交 易驱动的，其中通过提供有效、公平有序的市场使买方和卖方匹配。 这种交易驱动系统既不有利于买方也不有利于卖方，而是简单地实现 使匹配过程发生的交流。在第4,903,201号美国专利中公开了用于期 货贸易的自动化交易驱动商业系统。
另一方面，买方驱动系统是一种买方指定要约条款、卖方决定是 否接受的系统。例如“招工”广告即是买方驱动的询问，因为雇主在 寻找并购买合格的雇员的服务。这种询问向大量的潜在雇员进行广 告，这些潜在的雇员可以通过向预期的雇主提供其简历来响应。一般 来说，买方驱动系统比其它用于处理产品销售的系统更理想。例如， 买方驱动系统在所需产品的购买条款和条件上对买方提供了更多的控 制。此外，当有大量的潜在卖方，但那些卖方不具有大范围作广告的 资源时，买方能够采取主动向卖方传达其需要。
单方买方驱动系统基于履行指定任务来接受要约而寻求买方与卖 方之间完全的契约。例如有奖系统中，“买方”广播或公布向完成特 定任务的任何人进行提供奖赏。这样，单方系统只能由允许通过履行 而承诺的有限的交易类型所采用。另一方面，双边买方驱动系统基于 要执行的相互的承诺寻求买方与卖方之间完全的契约。然而，双边买 方驱动系统要求买方投入大量的时间、资金及其它资源确定数目不定 的潜在卖方，并向每一卖方传达买方的购买需要。然而，包括潜在的 低价格在内的对使用通常的双边买方驱动系统的消费者的任何好处， 一般被努力中所花费的时间和资金量超过。此外，买方驱动系统还对 卖方规定了固有成本。如果每一买方具有不同的一组购买规范，并使 用不统一的语言传达其购买需要，则卖方必须付出相当大的花费查看 并理解每一个别的请求。此外，卖方常常没有义务为各买方定制其产 品。
通常使用的双边买方驱动过程的一例是由诸如公司或政府等希望 以可能的最低价格购买大量货物或服务的大型组织采用的系统。开 始，买方形成详细的书面说明，通常称为“需求建议书”(RFP)，提 出他们想要购买的东西的数量和要求。RFP一旦定稿就向已知的若 干个潜在提供者散发。然后潜在的提供者查看RFP以找出他们能够 满足的条目，然后决定是否投入必要的时间和人力按RFP规定的截 止期向买方提交一整套正式的建议。建议一旦提交，则由买方评估， 并通知对应于被选定的建议的提供者，它已经以其要约“赢得”这项 业务。
大型组织能够利用RFP过程所提供的好处，因为它们的批量购 买对提供者表示着值得为它们的业务而进行竞争的机会，并且大型组 织具有向充分多数目的提供者传达它们购买需求的资源。结果是，大 型组织常能够实现可观的单位成本的节省，特别是在一般商品或商品 服务(如纸夹或长距离服务)及易变项目(如飞机票及旅馆房间)上。然 而，个人消费者不能有效参与这种双边买方驱动系统，因为他们一般 没有大型组织的购买能力和资源。
由于商业上探索利用因特网固有的优点，用于处理产品销售的许 多系统，诸如购物中心、商品目录及拍卖店正在因特网上实现。这些 方法一般是寻求造成更好的卖方或交换驱动系统，从而把货物的销售 和服务做得更有效。虽然已经试图使用因特网实现双边买方驱动交 易，但这些努力大部分是不成功的。例如，买方能够以很小的或没有 成本在“公告牌”型因特网站点张贴“需求”广告。这样，顾客基本 上能够向大量的有意向他们销售他们正寻找的产品的卖方张贴其自己 的RFP。然而实际上，对于潜在的卖方经常去访问一般具有不同的 格式、条件、条款及语言风格的“公告牌”站点或响应其各个RFP 是不现实的。此外，由于有以下的原因使卖方不敢使用这种过程(i)没 有RFP的真实性保证，(ii)同个别顾客协商的价格往往过高，以及(iii) 很难执行在消费者和卖方之间达成的任何协议(包括支付保证)。缺少 足够数量的卖方降低了对买方张贴其RFP的鼓励。
很多产业以及顾客可能从有效的双边买方驱动系统受益。例如， 近来旅游业已经经历了世界范围的蓬勃发展。由于旅游容量持续增 加，据料这种容量将超过计划的旅游者数量，从而降低利用率并对定 价造成压力。为了对付这种定价和存量的挑战，很多与旅游相关的卖 方已经开发了复杂的收益管理系统(RMS)，以便通过对可用的存量的 动态定价优化收益。一般来说，当由卖方第一次增加存量时，卖方的 收益管理系统试图通过建立多个价格分类并然后分配存量及指定给每 一价格类的价格，使存量的收益最大化。然后收益管理系统继续监视 在每一价格类内相对于预测需求的实际需求，动态地再次评价存量的 分配和对给定存量每一价格类定价。
虽然常规收益管理系统采用了复杂的工具预期未来旅游的需要， 但是预测的误差总是导致不能预料的过剩容量。此外，卖方可以利用 其收益管理系统预测预期的过剩容量，诸如给定的航班上与预测为空 位的座位相关的过剩容量。此外，诸如价格战或非常的天气条件等不 能预测的外部活动，还可能影响卖方的过剩容量。这样，在试图降低 这种过剩容量中，卖方周期地对存量分配和定价再评估。然而旅游相 关的卖方在没有进行价格战或协调他们自己的基本价格结构的情形下 (即还没有对全票价旅游者降低其全票价的价格的情形下)，不能简单 地对这种未销售的存量按已经公布的价格打折扣。这样，当前没有有 效的方法使旅游相关的卖方处理这种过剩的容量。
旅游相关的卖方认识到，有大量与希望以优惠价格旅游的闲暇旅 游者相关的潜在的需求源。然而，当前还没有有效的办法使这种卖方 接受由闲暇旅游买方提出的低于公布的价格的特别价格的要约。具体 来说，没有有效的办法使卖方相信，如果卖方接受买方的要约，买方 将按照这种要约进行旅游而不会使用信息查明卖方价格弹性的基本水 平，如果卖方的竞争者和买方知道这种水平，可能剧烈地冲击卖方整 个的收益结构。
类似地，对于供给正变得接近饱和的长途电话市场，长途电信公 司之间为了新的业务竞争已经急剧增加。虽然在美国和其它国家由于 竞争增加的结果，与长途电话相关的价格已经下降并预期会继续急剧 下降，但是长途电话的价格仍然保持相当的高，致使许多人没有象他 们所希望的那样多的定购长途电话。此外，许多打电话的人一般不熟 悉与在一天不同时间对不同地理区域定购电话相关的价位结构。这 样，不能识别并控制长途电话的费用又阻碍了许多人定购较多的长途 电话。
虽然诸如公司等许多大客户常常有足够的力量与长途电信公司协 商长途电话价率，或允许电信公司对他们的帐户投标，但就给定的当 前的电话系统，长途电话提供者还是不能与一般的客户个别地协商长 途电话价率。此外，许多大客户与数个不同的长途电信公司有帐户， 并在他们业主专用交换分机(PBX)或其它顾客经营场所设备中采用 “最低费用路由”技术。这种技术使他们能够使用存储的价率信息基 于每次通话选择最高效费比的电信公司。这种费用降低的解决办法对 一般只有一条长途电话提供者的顾客仍是不能得到的。虽然为了使顾 客能够识别提供最高效费比要约以完成通话已经开发了一些系统，但 这种系统不便于与各电信公司实时协商，或允许一个或更多的电话通 话根据呼叫方规定的限制完成。
此外，以往的商业系统对诸如音乐会、戏剧演出、运动会等活动 的门票转卖者限制广告门票可得性及完成门票交易的能力。当前，门 票的转卖者可用使用因特网上的分类广告、电子公告牌或“闲谈室” 广告门票的可得性。一旦门票被转卖，这种广告难以从公共领域取消。 于是，售票人可能在门票已经售出后被询问。此外，买方要求实际门 票的物理占有，并在演出之前才提交可能是有问题的。此外，门票的 买方和卖方一般具有彼此不信任。除非买方与门票转卖者面对面，否 则买方一般不愿意在没有某种送达保证的情形下付票款。类似地，门 票转卖者一般不愿意在没有事先付费情形下交付门票。然而，以往的 门票转卖系统没有对保证买方和卖方的置信性提供任何机制。
除了已知的商业系统上述缺陷之外，卖方常常需要来自第三方有 关买方的要约的信息，以便确定是否接受要约。例如，艺术品潜在的 买方需要艺术品伴随有可靠的第三方的“证明封印”。这种封印通常 证实艺术品是真品，并还评定其价值。类似地，资金的潜在出借人需 要潜在的借款人的信誉历史或“信用分”。出借人一般不是从潜在的 借款人那里接收这种这重要信息，因为借款人可能试图改变信息以表 现得更可信赖。信用信息必须来自可靠的第三方。
于是，借贷资金的要约，包括利率和借款数额等借款人规定的条 件，其本身还不足以使出借人确定是否接受要约。就信用风险和信用 信誉而言潜在的出借人还不能断定要约是否能够接受。这样，买方将 不能有效地作出要约。当前用于评估借款人与金融产品的销售相关的 信誉风险的系统，诸如第5,611,052号美国专利中所公开的系统，不 允许潜在的借款人规定所需的借贷条件。此外，在第5,611,052号美 国专利中所公开的系统没有防止不拟购买的人以无用的借贷申请干扰 金融产品的卖方。
从以上用于处理产品销售的传统系统的缺陷显然可见，需要一种 双边买方驱动系统，该系统能够被各个消费者使用，以便向潜在的卖 方广泛地传达他们的购买需求，该系统能够克服先有技术的缺陷。还 需要一种能够证实买方要约的条款和条件的双边买方驱动系统。在这 种双边买方驱动系统中还需要一种第三方管理，以便裁决双方之间的 合同争端，增加买方和卖方对系统的信心并建立在买方规定的要约中 使用的标准的协议、格式、条款和语言。还需要允许卖方在实际需求 与预测需求不相符时销售过剩的容量的一种系统。需要另一种买方驱 动系统，它允许买方以买方设定的一般是低于产品发布的价格的价格 获得产品。还需要一种系统，允许卖方能够促销过剩的存量或容量， 而不会危及卖方公布的价格结构。最后，还需要一种系统，它允许卖 方借助于来自第三方有关要约的信息来评估来自买方的要约的可承诺 性。
公开了一种用于在远程预期的买方和远程潜在的卖方之间完善形 成约束性合同的有条件购买要约(CPO)管理系统，该系统包括存储器 装置，并配置与存储器装置通信的处理器，处理器的构成使其从远程 预期的买方接收(a)包括至少一个条件的购买要约，及(b)用于规定从 其可对满足该至少一个条件的购买支付资金的通用财务帐户的支付标 识符，处理器的构成还能够向多个远程潜在的卖方传输购买要约，并 从至少一个远程潜在的卖方接收要约的无条件承诺。在本发明的一个 实施例中，还进而配置处理器使之启动支付标识符的使用以实现对来 自卖方的购买的支付，并且通用财务帐户是信用卡帐户。在本发明的 各个实施例中，从由价格、数量、送达日期、质量。地理位置及匿名 性组成的组中可以选择至少一个条件。
公开了根据本发明的另一实施例的一种包括通信端口和处理器的 系统，该系统允许CPO管理系统代表已向CPO管理系统授权的某 些基于代理的买方接受或拒绝给定的CPO。通信端口获得来自顾客 的购买要约并接收来自多个卖方的一个或多个规则。购买要约包含至 少一个顾客定义的条件，且每一规则包含一个或多个卖方定义的限 制。处理器对购买要约与规则进行比较以确定顾客定义的条件是否满 足卖方定义的至少一个规则的每一限制。
在一个实施例中，如果CPO由一个以上的卖方接受，则CPO 管理系统执行公告销售多约束过程，以便允许每一接受的卖方直接向 顾客营销并公告销售其产品。这样，基于由每一卖方提供的材料或激 励，顾客仍然能够为自己选择使用哪一个卖方接受。顾客受到由CPO 管理系统根据CPO条款的约束，并承诺购买由CPO规定的货物或 服务，但是买方基于由每一接受的卖方直接向顾客提供的材料或激励 可以决定采用哪一个卖方。
由顾客提交的CPO能够规定一个或多个较好的卖方。这样，CPO 管理系统向每一规定的卖方提供了CPO以确定一个或多个卖方是否 愿意接受CPO。在一补充的实施例中，CPO管理系统最好执行排除 的卖方CPO评估过程，以便在特定的卖方接受CPO之前向可能向 顾客还价的排除的卖方提供CPO。能够在较好的卖方之前或同时向 排除的卖方提供CPO。
公开了根据本发明另一实施例的一种适于处理货物或服务组合销 售的系统，该系统包括通信端口和处理器。通信端口接收来自顾客的 对组合销售的购买要约。购买要约包括每一组成条款的描述和用于规 定从其可支付资金的通用帐户的支付标识符。处理器把组合销售的购 买要约分解为多个购买要约成分，并确定每一购买要约成分是否能够 由一个或多个潜在的卖方接受。从而如果收到对每一购买要约的成分 的承诺，则约束顾客购买该组合销售。
公开了根据本发明的另一实施例的一种适于处理对一个或多个电 话通话的购买要约的系统，该系统包括通信端口和处理器。通信端口 获得来自顾客对一个或多个电话通话的购买要约，并向多个潜在的电 信公司提供该购买要约。购买要约包括顾客定义的至少一个条件和用 于规定资金支付方式的支付标识符。处理器确定一个或多个电信公司 是否接受购买要约，并如果收到对购买要约的承诺，则约束顾客购买 这些电话通话。
根据本发明的另一实施例的一种适于转卖活动门票的方法包括： 潜在的买方向中央控制器电子传输保证购买的要约；中央控制器电子 方式形成多个潜在的卖方可得到的要约；第一接受卖方向中央控制器 传输要约的承诺；以及中央控制器向买方与一代码一同传输这一承 诺，该代码用来在活动地点验证其门票的购买。
这样，本发明的一个优选实施例向个人提供了一种从门票转卖者 快速简易购买门票的方式，并使他们避免了门票转卖市场传统的问 题。此外门票转卖者能够基于由潜在的买方提供的有保证的购买要约 销售门票。而且，本发明包括防止在交易之中和之后欺骗行为的机制。
一般来说，根据本发明的允许卖方借助于来自第三方有关要约的 信息评估来自买方的要约的可接受性的又一实施例，中央控制器接收 包括至少一个条件信号的要约信号。要约信号定义了具有来自顾客的 至少一个条件的有条件购买要约。中央控制器还接收用于规定从其支 付资金的帐户的支付标识符信号。从第三方接收关于要约的信息信 号。信息信号一般包括如果来自提交有条件购买要约的借款人则是不 可信的相关信息。
通过参照以下详细的说明及附图将获得对本发明、及本发明进一 步的特点和优点更全面的理解。
图1表示本发明的第一实施例。
图2是表示中央控制器的一实施例的框图。
图3是表示卖方接口的一实施例的框图。
图4是表示买方接口的一实施例的框图。
图5表示说明有条件购买要约如何产生的一实施例。
图6表示说明通过中央控制器有条件购买要约的承诺的一实施 例。
图7表示说明有条件购买要约的激活的一实施例。
图8表示说明维持激活的有条件购买要约的一实施例。
图9表示说明选择有条件购买要约的卖方的一实施例。
图10和11表示说明有条件购买要约的约束的一实施例。
图12表示用于在买方和卖方之间交换货物和支付的示例性过 程。
图13表示一示例性支付方法。
图14到17表示使用密码协议的示例性鉴定过程。
图18和19表示由卖方还价的示例性实施例。
图20表示说明可信的服务器与担保代理的使用的一实施例。
图21是表示根据本发明一实施例的有条件购买要约(CPO)管理 系统的简略框图。
图22是图21的示例性CPO管理中央服务器的简略框图。
图23是图21的示例性安全的航空公司服务器的简略框图。
图24是图21的示例性中央保留系统的简略框图。
图25a是图21的示例性保留管理系统(RMS)的简略框图。
图25b表示传统的定价和分配过程及在图39的CPO规则产生过 程期间，图24a中所示RMS、航空公司保留系统及各种数据库之间 的相互作用。
图25c表示在时间上给定的票价级别内对航线机票的实际需求相 对于预测的需求。
图26表示来自图22的顾客数据库的样本表。
图27表示来自图22的航线数据库的样本表。
图28表示来自图22和24的航班时间表数据库的的样本表。
图29a和29b共同表示来自图23的CPO数据库的样本表。
图30a表示来自图23安全的航空公司规则数据库的样本表。
图30b和30c共同表示对图23的安全的航空公司规则数据库可 选的样本表。
图31表示来自图23的还价规则数据库的样本表。
图32表示来自图23的安全的航空公司决算数据库的样本表。
图33表示来自图24和25a的定价和限制数据库的样本表。
图34表示来自图24和25a的座位分配数据库的样本表。
图35表示来自图25a的预测和需求分析数据库的样本表。
图36a到36c是共同描述由图22的CPO管理中央服务器实现的 示例性CPO管理过程的流程图。
图37a和37b是共同描述由图23的安全的航空公司服务器实现 的示例性评估过程的流程图。
图38是描述由图23的安全的航空公司服务器实现的示例性决算 过程的流程图。
图39是描述由图25a的收益管理系统实现的示例性CPO规则产 生过程的流程图。
图40a和40b共同表示来自图22的CPO数据库对于巡游实现的 样本表。
图41表示来自图23的安全规则数据库对于巡游实现的另一样本 表。
图42是描述可由图22的CPO管理中央服务器实现的示例性公 告销售多约束过程的流程图。
图43表示来自与图44a和44b的流程图伴随的、可由图22的CPO 管理中央服务器实现的、排除的经营者还价数据库的样本表。
图44a和44b是共同描述可由图22的CPO管理中央服务器实现 的示例性排除卖方CPO评估过程的流程图。
图45是表示根据本发明的一个实施例组合有条件购买要约(CPO) 管理系统的简略框图。
图46是图45的示例性中央控制器的简略框图。
图47是图45的示例性安全的服务器的简略框图。
图48是图45的示例性买方或卖方接口的简略框图。
图49表示来自图46的买方数据库的样本表。
图50表示来自图46的卖方数据库的样本表。
图51表示来自图46的组合CPO数据库的样本表。
图52表示来自图46的成分CPO数据库的样本表。
图53表示来自图46的市场价格数据库的样本表。
图54a和54b表示来自图47的安全的卖方规则数据库的样本表。
图55a和55b是共同描述由图46的中央控制器实现的示例性组 合CPO公告销售过程的流程图。
图56a到56c是共同描述由图46的中央控制器实现的示例性组 合CPO监视过程的流程图。
图57是描述由图47的安全的服务器实现的示例性成分CPO规 则评估过程的流程图。
图58A是表示根据本发明的一个实施例的有条件购买要约(CPO) 管理系统的简略框图。
图58B是表示根据本发明的另一个实施例的有条件购买要约 (CPO)管理系统的简略框图。
图59是表示由图58A或58B的呼叫方使用的电话机的透视图。
图60是由图58的CPO管理系统使用的中央服务器的简略框图。
图61表示来自图60的顾客数据库的样本表。
图62表示来自图60的电信公司数据库的样本表。
图63表示来自图60的公布价率数据库的样本表。
图64表示来自图60的CPO数据库的样本表。
图65a和65b是共同描述由图60的中央服务器实现的示例性CPO 管理过程的流程图。
图66a和66b是共同描述由图60的中央服务器实现的示例性 IVRU过程的流程图。
图67是根据本发明的一个实施例的系统的示意图。
图68是用于图67的系统的中央控制器的示意图。
图69是用于图67的系统的远程用户终端的示意图。
图70是用于图67的系统的活动地点控制器的示意图。
图71a是表示用于图67的系统的活动表的内容的表。
图71b是表示用于图67的系统的活动地点表的内容的表。
图71c是表示用于图67的系统的顾客表的内容的表。
图71d是表示用于图67的系统的要约表的内容的表。
图71e是表示用于图67的系统的交易表的内容的表。
图72a是表示用于图67的系统的门票表内容的表。
图72b是表示用于图67的系统的更换门票表内容的表。
图73a到73g是描述根据本发明的一个实施例提交和接受保证要 约以便从因特网购买活动门票的方法的流程图。
图74是根据本发明提供的用于处理产品销售的系统的示意图。
图75a是图74的系统的中央控制器的一个实施例的示意图。
图75b是图74的系统的中央控制器的另一个实施例的示意图。
图76是图75a和75b的中央控制器的借款人数据库的示意图。
图77是图75a和75b的中央控制器的出借人数据库的示意图。
图78是图75a和75b的中央控制器的要约数据库的示意图。
图79是图75a和75b的中央控制器的信誉报告数据库的示意图。
图80是图75a和75b的中央控制器的附属数据库的示意图。
图81a是图75a的中央控制器的响应数据库的示意图。
图81b是图75b的中央控制器的规则数据库的示意图。
图82a和82b是表示用于处理借款者终端和出借者终端之间贷款 销售的方法的流程图。
图82c是表示用于处理借款者终端和出借者终端之间贷款销售的 另一方法的流程图。
现在将参照图1、2、3和4讨论本发明的一个实施例的方法和装 置。在一优选实施例中，本发明包括中央控制器200、卖方接口300、 买方接口400、及相关的数据库。本发明从买方接受有条件购买要约， 使它们可由潜在的卖方看到，并允许卖方约定它们。这样，买方能够 向卖方连同要约传达他的承诺，给卖方以信心，即如果他能够生产该 产品，则买方完全有能力支付。
系统的体系结构
以下参照图1到4解释本发明的方法和装置的第一实施例系统的 体系结构。如图1所示，本发明的装置包括卖方接口300、中央控制 器200、及买方接口400(统称为“结点”)。每一结点通过使用公共 交换电话网的因特网连接被连接，诸如由当地或区域电话运营公司提 供的电话网连接。连接还可以由专用数据线路、蜂窝式电话、个人通 信系统(＂PCS＂)、微波、或卫星网络提供。卖方接口300和买方接口 400是用于与中央控制器200通信的输入和输出网关。
使用以上组件，本发明提供了公告有条件购买要约，使得潜在的 卖方能够获得这些要约，允许卖方约定这些要约以形成法律上有约束 力的合同的方法和装置。
如图2所示，中央控制器200包括中央处理器(CPU)205、密码 处理器210、RAM215、ROM220、支付处理器230、时钟235、操 作系统240、网络接口245、及数据存储器装置250。
有足够的存储和处理能力的普通的个人计算机或计算机工作站可 以作为中央控制器200。在一个实施例中，它作为web服务器，接受 并发送由买方产生的CPO 100。中央控制器200必须能够进行高额 交易处理，在处理通信和数据库搜索时执行大量的数学计算。诸如通 常由Intel公司制造的100Mhz P54C的Pentium微处理器可用作为 CPU 205。这处理器采用32位体系结构。等同的处理器包括Motorola 120Mhz PowerPC604或Sun Microsystem的166MHz UltraSPARC- 1。
通常由Motorola公司制造的MC68HC16微控制器可用作为密码 处理器210。也可使用等同的处理器。这一微控制器采用以16MHz 结构的16位乘法和累加指令，并需要少于一秒执行5123位的RSA 专用密钥操作。密码处理器210支持对来自买方和卖方的通信的验 证，以及允许匿名交易。密码处理器210还能够作为CPU 205的一 部分构成。其它市场有售的专用密码处理器包括VLSI Technology的 33MHz6868或Semaphore Communication的40MHz Roadrunner284。
再来参照图2，支付处理器230包括通常的微处理器(诸如Intel Pentium)，支持附属于该装置的方法的支付的转帐和汇兑、收费、或 借方。支付处理器230还能够作为CPU 205的一部分构成。由支付 处理器230进行的信用卡交易的处理可由市售的软件支持，诸如由 Open Market公司制造Secure Webserver。这一服务器软件把信用卡 号码沿因特网以电子方式传送到Open Market总部，在那里进行信 用卡的验证和处理。它们的Integrated Commerce Service提供了运 行基于Web的业务所必须的机构内服务。服务包括联机帐目报表、 订单提取与信用卡支付核准、信用卡结算、自动化销售税计算、数字 式收据产生、基于帐目的购买跟踪、及低价服务支付总汇。
数据存储器装置250可以包括硬盘磁的或光存储单元，以及CD- ROM驱动器或快闪存储器。数据存储器250包含本发明中交易处理 中使用的数据库，包括买方数据库255、卖方数据库260、CPO数据 库265、还价数据库267、卖方响应数据库270、购买确认数据库275、 合同细节数据库280、支付数据库285、密码键数据库290，及审计 数据库295。在一优选实施例中使用诸如由Oracle公司制造的Oracle7 数据库软件生成并管理这些数据库。数据存储器装置250还存储属于 买方帐户297、卖方帐户298、及第三方暂存(escrow)帐目299的信 息。
买方数据库255以诸如以下的字段保持买方的数据：姓名、地址、 信用卡号码、电话号码、ID号码、社会保险号码、电子邮件地址、 信用历史、过去系统的使用、公共/专用密钥信息等。当买方第一次 用该系统登记，或公告其第一个CPO 100之前时，获得这一信息。 买方数据库255还包含由买方产生的每一个CPO 100的跟踪号码、 及每一个卖方响应110及对买方的CPO的还价的跟踪号码。
卖方数据库260以以下字段保持卖方的数据，诸如姓名、接触信 息、公共/专用密钥信息、支付偏好、业务类型、及出售的货物。接 触信息包括电话号码、web网页URL、公告牌地址、寻呼机号码、 电话号码、电子邮件地址、话音邮件地址、传真号码、或任何其它与 卖方接触的方式。在登记时，可能要求卖方展示按约定的CPO 100 发货的能力的证据。例如，一航空公司可以提交若干个它们服务的城 市对，以便中央控制器200能够迅速确定航空公司是否能够满足给定 的CPO 100。
CPO数据库265以诸如以下的字段跟踪所有的CPO 100：状态、 跟踪号码、日期、时间、目标、价格、到期日、条件、及买方标识号 码。这一数据库在买方和卖方之间就支付发生争执时是有价值的，因 为可以产生合同的细节。CPO数据库265还能够存储有法律约束的 证明172。
还价数据库267跟踪所有的还价140。这一数据库的构结与CPO 数据库265相同，所不同在于，增加了使还价140与特定的CPO相 关联的CPO跟踪号码字段。
卖方响应数据库270以诸如卖方姓名、卖方ID号码、日期、时 间、卖方响应跟踪号码、及相关的CPO跟踪号码字段跟踪所有的卖 方响应110。
购买确认数据库275跟踪向买方和卖方发送的确认完成的交易(法 律约束的合同)的消息。字段包括买方姓名、买方ID号码、卖方姓名、 卖方ID号码、购买确认跟踪号码、及相关的CPO跟踪号码。
合同细节数据库280包括包含在CPO 100中的形式背景条款。 这些形式条款有效填充了由买方规定的条件之间的间隙，规定了大多 数CPO 100共同的一般合同细节。
支付数据库285以诸如买方姓名、买方ID号码、支付量、及相 关的CPO跟踪号码等字段跟踪由买方作出的所有的支付。这一数据 库还可以存储买方的信用卡号码。
密码键数据库290便于进行加密功能，存储对称和非对称密钥。 这些密钥由加密处理器210用于对CPO 100、卖方响应110、购买确 认120、还价140、及买方响应150进行加密和解密。
审计数据库295存储与CPO 100过帐相关的交易信息，使之为 后来的分析被检索。
买方帐目297以诸如买方姓名、银行和信用帐户号码、及借或贷 交易等字段跟踪所有属于买方帐户的信息。这一帐目可以是指向存储 在买方银行的帐户数据的指针。
卖方帐户298以诸如卖方姓名、银行及信用帐户号码、及借或贷 交易等字段跟踪所有属于卖方帐户的信息。对CPO 100的买方支付 可以发送到这一帐户。
暂存帐户299是买方在资金并入卖方帐户298之前暂时保存买方 资金的帐户。
网络接口245是通过各买方接口400和卖方接口300与买方和卖 方通信的网关。普通的内部或外部调制解调器可作为网络接口245。 网络接口245支持从1200之上的波特速率范围的调制解调器，但如 果需要更大的带宽，可以把这种输入组合到T1或T3线路。在一优 选实施例中，网络接口245与因特网和/或诸如America On-line、 CompuServe或Prodigy等任何商业联机服务连接，允许买方和卖方 从联机连接的广泛的范围进行访问。几个商业电子邮件服务器包括以 上的功能。NCD Software制造了“Post.Office”，这是为通过企业网 络和因特网链接人和信息而设计的安全的基于服务器的电子邮件软件 包。该产品是与平台无关的并使用基于因特网协议的开放标准。用户 能够使用诸如文件、图形、视频和音频等包封交换信息。系统还支持 多种语言。另外，网络接口245可被配置为语音邮件接口、web站点、 BBS、或电子邮件地址。
虽然以上的实施例描述单个计算机作为中央控制器200，但业内 专业人员将能理解该功能可以分布在多个计算机上。在一个实施例 中，中央控制器200被配置在分布式体系结构中，其中数据库和处理 器装在分开的单元或位置。某些控制器执行基本处理功能并包含最小 的RAM、ROM、及通用处理器。每一这些处理器附加在作为与其它 控制器和接口装置的基本通信链接的WAN集线器。WAN集线器可 以具有其本身的最小处理能力，基本作为通信路由器。业内专业人员 将能够明白，可以支持几乎无限的控制器。这种结构产生了更为动态 和灵活的系统，较少受到对整个系统的灾难性硬件故障的影响。置信 服务器实施例提供了这种分布式环境的更多的细节，描述了运算服务 器160、置信服务器165及担保机构170。这些服务器的硬件与对中 央控制器200上述服务器类似配置。
图3和4分别描绘了卖方接口300和买方接口400。在一示例性 实施例中，它们都是普通的个人计算机，具有诸如键盘、鼠标或普通 的语音识别软件包的输入装置；诸如视频监视器显示装置；诸如CPU 处理装置；及诸如调制解调器网络接口。这些装置与中央控制器200 接口。另外，卖方接口300和买方接口400还可以是语音硬件系统， 或其它电子或语音通信系统。如以下实施例中进一步所述，传真机或 寻呼机也可以作为接口装置。
现参照图3，其中描绘了卖方接口300，该接口包括中央处理器 (CPU)305，RAM315，ROM320，时钟335，视频驱动器325，视频 监视器330，通信端口340，输入装置345，调制解调器350，及数据 存储器装置360。可增加密码处理器335和生物统计装置355用于稍 后所述较强的验证。诸如上述100Mhz P54C的Pentium微处理器可 用作为CPU 305。时钟335是标准的基于芯片的时钟，该时钟的作用 是为对由卖方接口产生的卖方响应110或还价140打时间印记。
如果所产生的大部分卖方响应110和还价140是基于文本的且不 很长，则调制解调器350可以不需要高速数据传输。如果需要密码处 理器，则使用上述的MC68HC16微控制器。生物统计装置355的结 构将在以下结合密码验证实施例说明。
数据存储器装置360是传统的基于磁性的硬盘存储单元，诸如由 Conner Peripherals制造的。消息数据库370可用于对卖方协响应110 和还价140存档，而审计数据库380可用于记录支付记录并中央控制 器200通信。
现参照图4，其中描绘了买方接口400，该接口包括中央处理器 (CPU)405、RAM415、ROM420、时钟435、视频驱动器425、视频 监视器430、密码处理器410、通信端口440、输入装置445、调制解 调器450、及数据存储器装置460。所有这些组件可以与图3中所述 的组件相同。
有很多商业软件应用程序能够实现卖方接口300或买方接口400 所需的通信，其基本功能是消息的生成和传输。例如由Qualcommg 公司生产的Eudora Pro提供了用于消息的生成的编辑工具以及向适 当的电子地址发送该消息的通信工具。当中央控制器200配置为web 服务器时，可使用诸如来自Netscape公司的Netscape导航者web浏 览器等普通的通信软件。买方和卖方可以使用Netscape Nevigator浏 览器传输CPO 100、卖方响应110或还价140。不需要很专门的软件。
联机实施例
在本发明的一个实施例中，买方和卖方之间的通信是借助中央控 制器200作为web服务器经电子网络进行的。买方向中央控制器200 登录，生成CPO 100，并然后脱离与网络的连接。CPO 100。通过在 中央控制器200的web网页上公告CPO 100而使CPO 100可达到潜 在的买方。周期性的维护由中央控制器200进行以保证有效的CPO 100不至过期，并保证买方有足够的信用能支付选择了约定CPO 100 的卖方。卖方的响应110以电子的方式被传输到中央控制器200，中 央控制器与买方接触指出CPO 100已经被约定。CPO 100一旦被约 定，则中央控制器200把信用卡消息转移到卖方。
参见图5，其中描绘了买方形成CPO 100的过程。在步骤500， 买方使用买方接口的买方调制解调器450登录到中央控制器200，建 立通信链接。应当注意，买方可以是个人、公司、合伙、政府或任何 其它实体。在一个实施例中，中央控制器200具有万维网上的页面， 允许买方通过诸如由Netscape公司生产的Netscape Navigator等普 通web浏览器软件的接口提供信息。在步骤510，买方通过从可能的 目标列表中进行选择选而择他想要购买的货物目标。如框515中所 示，目标可以包括航空公司机票、旅馆房间、租用汽车、保险、抵押、 衣物、等。在选择了目标之后，在，买方接口400的视频监视器430 上显示一表格。这一表格是带有要由买方填写的数个空格的电子合 同，每一空格表示CPO 100的一个条件。
在步骤520，买方输入货物的说明。例如，业务出差者可能希望 从旧金山飞往纽约。货物的说明可能是这一对城市之间两个一等舱往 返机票，五月7日离开，五月12日返回。表格上将有用于填写出发 城市、目的城市、出发日期、返回日期、机票号码、服务等级等的地 方。买方只需在空白处填写。然后在步骤530买方增加其它的条件。 例如买方可能只想要在午夜之前到达目标城市中途不停的机票。这些 条件将类似地登录到CPO 100。如框535中所示，条件可能包括这 样的条款，即飞机必须在午夜之前到达，旅馆必须是无烟的，或租用 汽车必须不是小型的。条件是CPO 100的条款，使买方能够对其特 定的需要编制CPO 100。条件还可以基于其它的条件。例如，一个 条件可能声称，必须满足五个其它特定条件中的四个。另外，可以对 CPO 100的每一条件给出点值，使CPO 100要求必须满足达到一定 总点值的的条件。例如，买方可能指出，窗口座位值两点值，走廊座 位一个点值，而不停飞行四个点值等。CPO 100可能要求为了满足 CPO 100的条件必须满足十个点值。条件还可以指示，对于CPO 100 的第一次约定之后二十四小时之内，其它卖方可以使要约约定，如果 没有收到更好的要约最初作出约定的卖方完成合同。条件甚至可以基 于外部活动。例如，卖方可以生成这样的CPO 100，即提出只购买 在目标城市十一月份下雪的情形下的航班机票。
在步骤540，如果需要，买方将向CPO 100添加过期日。这使公 布其CPO 100的买方不用担心在其需要改变之后他后来被约定。在 步骤550，买方录入价格。例如，在用于租用汽车的CPO 100中， 买方可以录入三天租用五十美元的价格。在步骤560，买方向CPO 100 附加其姓名或唯一的用户ID号码。这一ID号码是在买方在登记要 求服务时从中央控制器200收到的，或是由买方选择的然后通过电话 与中央控制器登记。中央控制器200在买方数据库255保有买方ID 号码的数据库，并只发出(或只允许)唯一的号码。如果需要的安全性 较低，则用户的电话号码可以作为ID号码，因为它的优点是唯一又 便于记忆。如果需要增加的安全性，则可以实施密码实施例中所述的 过程。
一旦以上要素形成，则买方在步骤570把它们传输到中央控制器 200。买方通过按动位于录入CPO 100的条款的屏幕上的按钮进行这 一操作。在步骤580，向CPO 100的成分添加合同的法律用语以形 成完整的CPO 100。法律用语是从存储多个段落的合同数据库280 抽出的。这些段落和以上的合同要素连接在一起而形成完整的CPO 100。唯一不能使CPO 100认为是合法的合同的缺失的唯一要素是卖 方的姓名和签字。
除了基于万维网的接口之外，买方还可以通过电子邮件、语音邮 件、传真机、或邮政邮件传输来发送CPO 100的数据。使用语音邮 件，买方通话中央控制器200并留下音频形式的CPO 100。这些CPO 100在中央控制器200被改编为数字文本，或使其以相同的音频格式 由潜在的卖方得到。在邮政邮件的实施例中，中央控制器200的作用 更象个路由器，把CPO 100引导到潜在的卖方，必要时生成CPO 100 的多个拷贝。CPO 100还可以公布到由中央控制器200操纵的公告 牌或web网页上。中央控制器200支持多种传输方法，允许CPO 100 格式的广泛类型。然而，一些格式可以在由中央控制器200进一步处 理之前被改变。例如，通过邮件以纸的形式传输的CPO 100可以使 用光学字符识别软件被扫入并数字化以便生成数字化文本。这些实施 例在稍后所述的脱机实施例中更为详细地说明。
现参见图6，在使CPO 100可由潜在的卖方得到之前，CPO 100 被接收并检验看是否可得到足够的信贷满足CPO 100规定的价格。 在步骤600，中央控制器200从CPO 100抽取价格和截止期信息。 在步骤610，支付处理器230向信用卡清算银行提交CPO 100的价 格预先验证。这是要“锁定”买方的信用卡上可用的信贷部分，防止 在CPO 100仍然有效时买方用完这一信贷。在步骤620，信用卡清 算银行预先验证，指出是否能够得到足够的信贷。如果不能得到足够 得到资金满足CPO 100的价格，则在步骤630从买方请求另一信用 卡号码。一旦已经发送附加的信用卡号码，则中央控制器200再次在 步骤610提交预先验证。在步骤640，检验CPO 100的截止日期， 看它是否已经过期。如果它已经过期，则在步骤650拒绝CPO 100 并返回给买方。如果CPO 100还没有过期，则在步骤660它被接受。
现参照图7，其中示出一实施例，CPO 100被启动并使之由潜在 的卖方得到。在步骤700，唯一的跟踪号码被添加到CPO 100。在步 骤710中央控制器对CPO 100打上时间印记，并在CPO数据库265 存储CPO 100。CPO数据库265包含对每一CPO 100的记录，并包 括诸如状态、目标、跟踪号码、时间印记、货物的描述、价格、截止 日期、条件、及买方ID号码等字段。状态字段值有“待办”、“有效”、 “过期”、和“完成”。“待办”的状态意味着CPO当前不能由潜在的 卖方得到。或者它仍然在由中央控制器200处理，航班它已由买方暂 时挂起。“有效”的CPO 100是潜在的卖方可得到的，并能够约定。 “过期”的CPO 100不能再被约定。已经由卖方约定的CPO 100具 有状态“完成”。
CPO 100在步骤720被存储之后可用通过一系列的处理步骤。如 果需要，则一个步骤是语言翻译，或生成所有的CPO 100必须以其 写成的标准语言，或翻译成对要向其发送的卖方的最适当的语言。这 一翻译是由中央控制器200的语言专家，或由诸如Systran Software 生产的自动翻译软件Systran Profession提供的。可用得到二十个双 向语言组合，包括英语到/从法语、意大利语、德语、西班牙语、葡 萄牙语、和日语。如果需要，另一步骤是对拼写和语法错误进行编辑。 为了明晰还可用对CPO 100进行复审。任何有不清楚的条款或条件 的CPO 100将被返回买方以便澄清。列出目标城市“Chicago”的买 方可能得把CPO 100返回以便澄清或纠正。
再来参见图7，在步骤730对CPO 100的数据库记录的状态设置 为“有效”。在步骤740，从目标字段提取CPO 100的目标。在步骤 750，在适当的目标区域公告CPO 100。这允许中央控制器200只向 最适当的卖方显示CPO 100。在万维网环境中，中央控制器200有 对每一可能的目标区域的web网页。这样，需要航空公司机票的所 有CPO 100将显示在航空公司机票web网页上。由于卖方能够直接 与他们能够为其提供其货物的目标接触，这使潜在的卖方能够更加容 易找到他们想要约定的适当的CPO 100。在另一实施例中，CPO 100 是以电子方式或者个别地或者成组地邮寄到潜在的卖方的。潜在的卖 方能够进行选择以便接收所有的CPO 100、在他们目标区域中的CPO 100、或者表示特定条件的CPO 100的子集。例如，汽车出租公司可 能要求对于豪华汽车的所有汽车出租CPO 100发送给他们。
在其中CPO 100正在向卖方发送的实施例中，重要的是应注意， 对于卖方接口300有数种硬件的选择。适用的卖方接口300包括传真 机、无线连接的个人数字助手(PDA)。例如，稀有钱币商可以指令中 央控制器200每当CPO 100出现关于Morgan Silver Dollars时传呼 他，通过传呼机网络提供CPO 100的细节，或通知卖方向中央控制 器200登录以获得进一步的细节。
现参见图8，其中示出CPO 100的维护过程。在步骤800，中央 控制器200搜索CPO数据库265。在步骤810，CPO 100的每一数 据库记录的截止日期字段与当前日期进行比较。如果CPO 100的截 止日期早于当前日期，则在步骤820 CPO 100的状态变为“过期”。 在步骤830，支付处理器230与信用卡清算银行联系以验证买方的信 用卡是否仍然有效。如果信用卡无效，则CPO 100的状态在步骤840 变为“过期”。一旦所有的“有效”CPO数据库记录已被检验，则在 步骤850完成维护过程。
图9示出潜在的卖方选择CPO 100的过程。在步骤900，潜在的 卖方使用卖方接口300的调制解调器350登录到中央控制器200。在 步骤910，潜在的卖方选择适当的目标区域。例如，一家刚刚经过历 取消会议订房的芝加哥大旅馆，可能在旅馆目标区域搜索希望找到要 求在那些日期芝加哥的房间的CPO 100。在步骤920，潜在的卖方浏 览可得的CPO 100(即状态为“有效”的那些)的列表。CPO 100可能 以最少的细节列出，另外的信息只能在潜在的卖方有意约定CPO 100 时可得。旅馆CPO 100可能列出为“旅馆-09/16/96-芝加哥-单人住- $85”。希望更多关于CPO 100的信息的潜在的卖方可以在步骤940 请求附加的数据。在一个实施例中，每一CPO 100被超链接到提供 完整细节的分开的web网页。潜在的卖方点击CPO 100，则立刻转 移到支持细节的页面。这一细节可能包括所需的床位类型，适用的设 施，及就餐。在另一实施例中，CPO 100通过电子邮件、传真、电 话、传呼机等电子方式直接传送到卖方的。
图10和11示出CPO 100由卖方约定的过程。在步骤1000，潜 在的卖方选择他想要约定的CPO 100，发出表示他的约定意向的卖 方响应110。在步骤1010，中央控制器200接收来自潜在的卖方的卖 方响应110。中央控制器200这时对卖方的响应打上时间印记并验证 卖方的身份，以及检验其提供货物大概的能力。时间印记允许中央控 制器200确定收到的第一个无条件承诺。如果在彼此几秒钟内收到两 个卖方响应110，则时间印记允许中央控制器200评判定哪个是首先 收到的。另外，时间印记可以在它从卖方接口300被发送时附加在卖 方响应110上。
卖方身份的验证涉及到中央控制器200从卖方响应110抽取卖方 ID并在卖方数据库260中查找卖方的标识。然后卖方数据库260中 的信息提供卖方供货的能力的指示。例如，在卖方能够约定对于航空 公司机票的CPO 100之前，中央控制器200必须验证卖方是一个航 空公司。如果必要，中央控制器200可以验证卖方能够提供所需的特 定的货物。不仅是验证卖方为一个航空公司，中央控制器200可以验 证它服务于买方所要求的城市对。在另一实施例中，买方把买方的响 应110结合到CPO 100中，添加同意定合同的指示而签署CPO 100。 这一指示可以是一数字签字，或可能涉及添加代表买方的一符号或标 记。
然后中央控制器200在步骤1030验证CPO 100的状态，在步骤 1040确定CPO 100的状态是否为“有效”。如果CPO 100当前为“有 效”，则在步骤1060向卖方响应110添加唯一的跟踪号码。然后在步 骤1070中央控制器200把卖方的响应存储到卖方响应数据库270。 如果在步骤1040 CPO 100的状态不是“有效”，则卖方的响应被中 央控制器200拒绝，并在步骤1050被发送回潜在的卖方。
在另一实施例中，在步骤1010卖方直接向买方传送卖方响应 110。然后买方可以把卖方的响应110发送到中央控制器200以检验 和鉴定，或者他可以选择接收卖方响应110而不要检验和鉴定。
在图11中，当对于选择的CPO 100的信用卡号码和准许代码发 送到卖方时，在步骤1100开始支付过程。在步骤1100 CPO 100被约 定，把CPO 100转为买方和卖方之间有法律约束力的合同。约定的 过程要求CPO 100的状态变为“完成”，以防止下一个卖方可能约定 CPO 100。约定过程还要求卖方的ID添加到CPO 100。在步骤1120， 中央控制器200向卖方发送购买确认120，并然后在步骤1130把它 发送给买方。
在另一实施例中，多个买方可能约定CPO 100。这种情形下，CPO 100可以保持其“有效”的状态直到给定数目的买方已经作出响应， 并只有这时CPO 100的状态变为“完成”。例如，稀有钱币商可以公 告要约一百美元购买一种特别的钱币的CPO 100。CPO 100的添加 可以规定，该要约接收前十名卖方的响应，允许十个可约定的合同。 另一选择是接收任何数目的约定，或直到买方资金能达到的任何数目 的约定。
系统的提供者可用许多方法得到收益流。在一个实施例中，对每 一提交的CPO 100定额收费。还可以有一种覆盖给定时间段的任何 数目的CPO 100的定额收费，使买方能够象定购报纸那样多定购服 务。在另一实施例中，中央控制器200计算价格的折扣值，卖方只收 到其中CPO 100的价格的一个百分数。在另一实施例中，登广告者 对把与CPO 100一同列出的消息付费，以补充相同的运行费用。另 外，可以采用本发明的方法和装置而不设支付功能。
图12示出买方和卖方之间的货物交换。在步骤1200，卖方把特 定的货物转移给买方。这一转移可能涉及物理货物以及数字货物的交 付。物理货物可能包括汽车、珠宝、计算机设备等。数字货物可能包 括文挡、票据、访问代码等。例如，一个旅馆可能向买方传送一确认 号码，以便在旅馆检入时出示。在步骤1210，买方检验交付的货物 看它们是否满足CPO 100的所有的条件和条款。例如定旅馆房间的 买方，将检验房间用于正确的日期及正确的城市。在步骤1220，如 果货物不满足CPO 100中所述买方的条件，则买方为解决争执与在 中央控制器200的仲裁者联系。这一过程将在稍后所述的争执解决实 施例中更为详细说明。在步骤1240交易完成。
支付偏好
图13示出中央控制器200以其建立买方帐户297的协议。在步 骤1300，买方选择其希望的支付方法。希望的支付方法可以包括信 用卡、个人支票、电子资金转帐、数字货币等。在步骤1310，买方 向中央控制器200传送对应于其希望的支付方法的支付数据。如框 1315所指出的，这种支付数据可以包括信用卡号码或银行帐户号码。 然而，这些支付方法只是示例性的，由于业内通常已知有许多等同的 也可使用的支付方法。例如，如果买方希望通过信用卡支付，则支付 数据将包括其信用卡号码、截止日期、发放机构名称及信贷限额。对 于电子资金转帐，支付数据包括买方银行的名称及其帐户号码。在步 骤1320，中央控制器200在支付数据库285中存储支付数据和支付 偏好。
在步骤1330，中央控制器200建立买方帐户，这或者是存入由 买方转帐的货币，或者是作为指向系统外买方的一个帐户的指针。例 如对于使用信用卡的买方，买方帐户297包括信用卡号码、截止日期 及发放机构名称。买方可能还向中央控制器200转移要存储到买方帐 户297的货币，这将如同通常支票转帐那样操作。中央控制器200可 向卖方发送一写在买方帐户297上的支票。另外，中央控制器200能 够直接从买方帐户297向卖方帐户298以电子方式转移资金。在步骤 1340，中央控制器200与银行或信用卡发放者联系以确认可得到资 金。这样买方不能使用不能获得信贷的信用卡建立买方帐户297。
以上的协议可类似地用于卖方，允许生成卖方帐户298。基本的 差别在于，卖方帐户298主要用于存款，当买方发现收到不接收的货 物时在存款返回或退款的情形下使货币从卖方流向买方。因而对于卖 方可用资金的验证不是那么重要的。
虽然联机实施例描述了中央控制器200向卖方传输用于处理的信 用卡信息的协议，但当然有很多可以从买方向卖方转帐支付的协议。 在一个实施例中，处理是通过中央控制器200进行的，而不是卖方。 中央控制器200在支付数据库285中查找买方的信用卡号码。这信用 卡号码传输给支付处理器230。支付处处理器230与信用卡清算银行 联系获得授权号码。在买方每月清单中可支付额出现在买方信用卡清 单上。清算银行把该数额通知卖方帐户298。中央控制器200更新支 付数据库285指出支付已经进行。中央控制器200还能够通过向每一 方提供支付信息而安排直接在买方和卖方之间进行支付。例如，买方 可以接收卖方的支票帐户号码。帐户信息还能够嵌入到CPO 100和 卖方协议110中，允许一旦买方和卖方每一方具有CPO 100的拷贝 他们就可完成支付。
支付的另一方法涉及使用数字现金的过程。中央控制器200在支 付数据库285中查找买方电子交付地址。这地址被传送到支付处理器 230，数字现金就从买方被下载。中央控制器200更新支付数据库285 指出支付已经进行。如果数字现金是由电子邮件传送的，则这一地址 就是电子邮件地址，或它可能是能够接收联机数字现金转移的因特网 协议地址。这一电子交付地址被发送到支付处理器230。数字现金被 下载到卖方帐户298或直接到卖方。然后中央控制器200更新支付数 据库285指出支付已经进行。使用这一数字现金协议，买方能够把支 付与CPO 100一同纳入到电子表格。
使用数字现金协议实现支付的实际过程是业内所熟知的，因而在 此无需详述。例如，业内一般专业人员可以参见Daniel C.Lynch和 Leslie Lundquist，Digital Money，Jone Wiley & Sons，1996；或Seth Godin Presenting Digital Cash，Sams Net Publishing，1995。
延迟支付实施例
虽然联机实施例描述了卖方在约定CPO 100时立即接收支付的 协议，但是也可以实现其它的实施例，其中支付被延迟到货物已经由 买方收到，或延迟到某一预定的日期。系统还支持部分支付和分期支 付。
第三方暂存帐户299允许支付延迟到卖方完成货物的交付，同时 保证买方将实际上进行支付。中央控制器200建立第三方暂存帐户299 作为暂时保存的帐户。当在步骤1110卖方约定了CPO 100时，资金 从买方帐户转297移到第三方暂存帐户299。只有在货物已经由买方 收到之后，资金才从第三方暂存帐户转移到卖方帐户298。买方可以 向中央控制器200传输一数字化签字的放行消息，授权向卖方放行第 三方暂存的资金。
在另一实施例中，当CPO 100被约定时，买方进行部分支付， 并在货物收到时完成支付。约定时应支付CPO 100的要约部分是CPO 100的一个条件，并在CPO 100被约定时存储在支付数据库285中。 在步骤1110中央控制器释放这一部分资金，然后在步骤1200货物已 经交付之后释放其余部分。在约定时进行的部分支付可以是不能返还 的。例如这将允许旅馆出售两天前通知取消的旅馆房间预定，在两天 期限内取消结果是罚收押金。
在另一实施例中，CPO 100描述了分期支付的使用。第一次支付 在CPO 100预定时作出，之后是按CPO 100的条件规定的常规的支 付。作出支付的日期存储在支付数据库285中。
还价的实施例
在本发明的一个实施例中，卖方响应CPO 100不是通过预定它， 而是通过以修改的和/或附加的条件作出还价。例如，航空公司可能 查看五百美元的一等机票的CPO 100。该航空公司可能愿意以六百 美元出售。这样就希望形成并发出还价而不是选择约定CPO 100。 这还价类似于CPO 100，所不同的是，买方约定卖方而不是卖方约 定买方。另外还价指向特定的部分(买方)，与可以指向多个卖方的CPO 100不同。
图18示出还价140的形成。在步骤1800，潜在的卖方选择对其 想要作出还价的CPO 100。在步骤1810，卖方以修改的条件准备还 价140。卖方遵循买方产生CPO 100的相同的过程(步骤500到580)， 选择还价140的条件。备择地，向卖方呈现CPO 100的电子拷贝并 允许卖方编辑想要修改的那些条件。例如，汽车出租公司可能取得买 方每天十美元租用豪华车的请求，并以每天十二美元小型汽车还价。 在步骤1820，卖方把CPO 100的跟踪号码附加到还价140上。中央 控制器200在步骤1830接收还价140，设置状态为“有效”。然后在 步骤1840中央控制器200向还价140添加唯一的跟踪号码，并在步 骤1850在还价数据库267存储该号码。中央控制器200抽取附加在 还价140上的CPO 100的跟踪号码，以便在步骤1860找到向其传输 还价的买方。
图19示出买方响应还价140的过程。在步骤1900，买方决定是 否约定还价140。如果他不约定，则在步骤1910还价被传输返回潜 在的卖方。如果买方决定约定，则在步骤1920买方的响应150传输 到中央控制器200。在步骤1930，资金从买方帐户297去除并存放到 卖方的帐户298。在步骤1940，还价140的状态变为“完成”。在步 骤1950购买确认120传送给卖方并在步骤1960传送给买方。如图12 所述完成了交换货物的过程。
脱机的实施例
在本发明的一个实施例中，买方和卖方与脱机的方式与中央控制 器200通信。不是发送电子邮件或使用基于web服务器，买方和卖 方使用电话、传真机、邮政邮件或其它脱机通信工具。
例如买方可以使用电话产生CPO 100。买方通话中央控制器200 并与一代理连接。买方提供CPO 100的条款，诸如目标、货物说明、 条件、截止期、价格等。买方还提供买方ID、口令、或私人密钥， 使得中央控制器200能够验证其身份。代理通过把数据键入到终端把 这些数据转换为数字形式，并然后添加法律用语而形成CPO 100。 然后CPO 100传输到中央控制器200，在这里如同联机实施例中所 述那样使之能够由潜在的卖方获得。
在另一实施例中，买方通话中央控制器200并和通常的交互式语 音响应装置(IVRU)连接，该装置允许买方录入CPO 100的一些或所 有的条款而无需现场代理的帮助。买方首先使用其电话的音频按键从 目标菜单进行选择，然后通话直接指向在该目标区域规定的代理，或 者提示买方输入进一步的CPO 100条款。
潜在的卖方也可以使用电话浏览并约定CPO 100。潜在的卖方通 话中央控制器200并选择目标。然后中央控制器200把CPO 100的 文本转换为音频的形式，向潜在卖方读整个的列表。在读CPO 100 期间的任何时候，潜在的卖方可以按动他的电话上的键的组合以便约 定。卖方录入卖方的ID号码，并在CPI 100约定之前被中央控制器 200验证。潜在的卖方在使CPO 100的读给他们之前还可以录入参 数。例如航空公司可以请求读出多于八百美元的所有航空公司的CPO 100，跳过较低价格的的任何CPO 100。
买方也可以通过传真或邮政邮件与中央控制器200的代理通信。 代理接收消息并对其进行数字化，并形成如上所述的CPO 100。
密码验证实施例
在以上的实施例中，买方和卖方的验证涉及检验附加的ID或姓 名并对它与卖方数据库260和买方数据库255中存储的ID或姓名进 行比较。虽然这一过程在低安全性的环境中工作良好，但是通过使用 密码协议它能够被大大改进。这些协议不仅提高了对消息的发送者进 行验证的能力，而且能够验证消息本身的完整性，证明其在传输期间 没有被改变。例如，在他们的身份没有验证之前，能够防止小的航空 公司约定要求由大的运输公司进行的CPO 100。加密还能够防止窃 听者获得消息的内容。例如能够防止竞争的航空公司读取所截取的由 另一竞争者产生的卖方响应110。这种技术一般称为密码安全方法， 并将包括对称和非对称没有两者的使用及数字签字和散列算法。
使用密码协议保证发送者的真实性以及消息的完整性的实践是业 内所熟知的，故无需在此详述。例如，业内一般的专业人员可以参考 Bruce Scheier，Applied Cryptography，Protocols，Algorithms，And Source Code In C，(2d Ed，John Wiley&Sons，Inc.，1996)。
图14描绘了卖方和中央控制器200共享一个密钥的对称密钥实 施例。这样卖方协议110的加密和解密两者使用同一密钥进行。这一 加密可以使用诸如DES(FIPS PUB 46中规定的美国政府标准)算法实 现，或使用业内已知的诸如IDEA、Blowfish、RC4、RC2、SAFER 等几种算法进行。在步骤1400卖方使用卖方接口300的密码处理器 310以其指定的对称密钥对卖方的响应110加密。密钥可以存储在消 息数据库370中，或否则由卖方存储或记忆。然后在步骤1410加密 的卖方响应110传输到中央控制器200的密码处理器210。密码处理 器210在步骤1420从卖方响应110抽取卖方ID，并在步骤1430查 找密码密钥数据库290中的该卖方的对称密钥，在步骤1440以这一 密钥解密卖方响应110。密钥码密数据库290包含用于加密、解密和/ 或鉴定消息的算法和密钥。在步骤1450，如果结果的消息是明白的， 则它必定已由相同的密钥加密，鉴定出该卖方必定是卖方响应110的 作者。
这一过程使得未授权的卖方要把其本身表示为一合法的卖方是十 分困难的。在没有加密过程情形下，从合法的卖方获得了样品卖方响 应110的未授权的卖方将能够抽取卖方ID，并然后向未授权的卖方 响应110附加这一ID号码。然而，当卖方响应110已经使用对称密 钥被加密时，获得了样品卖方响应110的未授权的卖方只能发现卖方 的ID号码，而不是对称的密钥。没有这一密钥，未授权的卖方就不 能生成不会被中央控制器200发现的卖方响应110，因为他不能以授 权的卖方能够进行的相同的方式对其消息加密。对称密钥协议还保证 了卖方响应110在传输期间没有被窜改，因为消息的改变需要知道对 称密钥。加密的卖方响应110还向卖方提供了匿名性。
现在参见图15，示出非对称密钥协议，其中对卖方响应110使 用私人密钥加密并使用公共密钥解密。对这一过程的这两种算法是 RSA和DSA。在步骤1500，卖方以他私人密钥使用密码处理器310 加密卖方响应110，在步骤1510向中央控制器200传输卖方响应110。 密码处理器210在步骤1520抽取卖方ID，并在步骤1530在密码数 据库290中查找卖方相关的公共密钥，在步骤1540以这一公共密钥 解密卖方的响应110。如前面那样，如果卖方的响应是容易理解的， 则中央控制器200已经在步骤1550鉴定卖方。又在其由中央控制器 200收到之前获得了卖方响应110的未授权卖方是不能不被觉察改变 它的，因为他们不知道卖方的私人密钥。然而未授权的卖方如果他们 设法获得了卖方的公共密钥是能够读取该消息的。如果卖方以其公共 密钥加密了卖方响应110，则获得了消息的保密性，因为袭击者需要 知道卖方的私人密钥阅读卖方的响应110。
图16表示使用数字签字的密码技术以提供鉴定和消息的完整 性。一种这样的算法是DSA(数字签字算法)，在FIPS PUB 186中规 定的美国政府标准。如同在上述的非对称协议那样，每一卖方具有相 关的公共和私人密钥。在步骤1600卖方以其私人密钥使用密码处理 器310签署卖方响应110，并在步骤1610向中央控制器200传输该 响应。在步骤1620，中央控制器的密码处理器210抽取卖方的ID， 并在步骤1630查找卖方的公共密钥，在步骤1640使用卖方的响应110 和卖方的公共密钥检验签署。如果卖方的响应110是可理解的，则在 步骤1650中央控制器200接收卖方响应110为可靠的。
现在参见图17，其中描绘了使用用于验证卖方响应110的可靠 性和完整性的消息验证代码的密码技术。在本发明的散列协议中，卖 方和中央控制器200共享对称密钥，卖方把该密钥在步骤1700包含 在卖方响应110的散列中。在散列协议中，单向函数用于卖方响应110 的数字表示，产生作用很象卖方响应110的指纹的代码。任何MAC 算法，诸如RIPE-MAC，IBC-Hash，CBC-MAC等可用于这一用途。 在步骤1710向中央控制器200传送卖方响应110之后，密码处理器 210在步骤1720从卖方响应110抽取卖方ID。然后在步骤1730密码 处理器210查找卖方对称密钥，并在步骤1740以这一对称密钥散列 卖方响应110，比较所得的散列值和附加在卖方响应110的散列值。 在步骤1750如果这些散列值匹配，则卖方响应110的完整性与卖方 的可靠性一同得到验证。
虽然密码技术能够对卖方响应110的可靠性提供较大的可信性， 但是如果卖方的密钥受到损坏，则它们是没有用的。获得了另一卖方 的对称密钥的的袭击者就中央控制器200的眼睛来说是与该卖方不能 区别的。没有办法能够知道卖方是否是卖方响应110的真正的作者， 或是具有正确的密钥的袭击者。解决这一问题的一个方法(称为未识 破替代)是使用生物检测装置，诸如指纹阅读器、话音识别系统、视 网膜扫描仪等。这些装置把卖方的物理属性结合到卖方响应110中， 然后它们与存储在中央控制器200处的卖方数据库260中的值进行比 较。本发明中，这种装置附加在卖方接口300。
例如，指纹检验可以在卖方响应110生成之前进行，在产生卖方 响应110期间响应来自中央控制器200的提示，在某些预定的或随机 的时间，或连续地通过把扫描透镜安装到卖方接口300，使得在卖方 响应110产生时要求卖方保持其手指始终在扫描透镜上以便连续验 证。
这种识别装置的一个例子是从一台湾公司Startek可得的FC100 FINGERPRINT VERIFIER(指纹验证器)。FC100易于通过接口卡 与任何PC适配。指纹验证器使用光学扫描透镜。卖方把他的手指放 在透镜上，结果图象被扫描、数字化，并被数据压缩和存储在存储器 中。一般来说，256字节的文件是所需的一个文件。每一现场扫描的 指纹与存储在数据存储器装置360中事先登记/存储的模板对比。如 果指纹不匹配，则由密码处理器335执行的密码算法可以防止卖方产 生卖方响应110。
在嗓音验证实施例中，卖方的嗓音用来验证其身份。这一实施例 检验不需要使用任何特别的硬件的优点，因为它可以通过标准的电话 连接实现。在中央计算机200验证卖方的身份。获得嗓音痕迹和然后 使用它验证人的身份的过程是业内熟知的，因而在此无需详述。业内 一般专业人员可以参见嗓音识别/验证技术的SpeakEZ公司。普通的 说话者识别软件对卖方的嗓音采样。这一样本存储在中央控制器处卖 方数据库260中。每当卖方想要向中央控制器200传输卖方响应110 时，他需要通话中央控制器200，并在提示时向电话说话作为嗓音样 本。如果这一样本与存储在卖方数据库260中的匹配，则向卖方提供 一口令，该口令被结合到附加在卖方响应110中的数字签字中。收到 的没有适当的嗓音匹配口令的任何卖方响应110不被接受。嗓音痕迹 还可以存储在卖方接口300的数据存储器装置360内的一数据库中， 以便在允许卖方响应110生成之前在当地验证卖方的身份。
虽然以上的密码和生物学检测协议描述了鉴定和验证卖方响应 110，但它们可以同样用于CPO 100、还价140、买方响应150、购买 确认120，或买方、卖方与中央控制器200之间其它任何消息或通信 的鉴定和验证。
匿名交易实施例
如前所述，本发明提供了对买方和卖方两者的匿名性。这种匿名 性是通过对所有所交易免除对每个人的姓名所有参照而实现的。例 如，买方将其ID纳入CPO 100而不是其姓名，防止接收CPO 100 的卖方发现买方的身份。如果买方是一个不希望竞争对手知道该公司 正在寻找的实验室设备类型的生物技术公司，则这就是需要的。
类似地，卖方可能还希望对其身份保密。航空公司可能不希望公 众知道它们正在一些城市之间对机票大打折扣。
虽然使用ID号码对买方和卖方都能够提供匿名，但是仍然有一 些潜在的缺陷。首先，如果存储在买方数据库255或卖方数据库260 中的ID号码的数据库及各个买方/卖方被泄漏，则匿名性被破坏，因 为消息发送者能够在买方数据库255或卖方数据库260中查到。为了 防止这一点，以中央控制器200的公共密钥加密ID号码，使得即使 它被偷窃，没有私人密钥也没有用。
虽然我们只描述了用于保持匿名的一个可能方法，但还有其它同 等的方法。例如，如果实施例包括电话传信，则能够使用通常的话音 修改技术维护买方和卖方的身份。如果CPO 100或卖方响应110为 书面表格，则可使用光学字符识别扫描该表格并翻译成数字表格，丢 弃在原始文挡中能够找到的任何信息。
置信服务器实施例
在本发明的一个实施例中，这样控制器200分为三个不同的组成 部分：操作服务器160，置信服务器165，和担保代理170。每一服 务器在CPO 100的管理过程中执行不同的任务。这一分开使袭击者 更难于危及系统，因为它们必须破坏三个分开的系统的保密性而不是 一个。如图20中所示，这些服务器与买方接口400和卖方接口300 协同工作。操作服务器160的任务是公告CPO 100，并接收由置信 服务器165先前验证的所有交易。置信服务器165验证买方和卖方的 身份，而担保代理170检验买方的支付能力和卖方的按约定的CPO 100交付的能力。在这一实施例中，每一服务器的类型可以分布在数 个服务器上。
以下的协议描述了三个服务器的交换作用并假设如下：
1.每一人都知道操作服务器160、置信服务器165、及担保代理170 的公共密钥。
2.买方和潜在的卖方具有如下所述的担保证书172。
3.公共密钥能够既可用于加密又可用于签字。
在CPO 100由操作服务器160接受之前，它必须带有置信服务 器165和担保代理170两者的数字签字。因此，CPO 100包含两个 附加的要素--置信服务器ID和担保证书。
置信服务器ID是证明生成CPO 100的卖方的置信服务器165的 ID号码。“担保证书”是公共密钥的证书，证明者规定了担保证书172 的一组有效日期，对所包括的数量的限制，及一组附加的条件。这些 附加的条件可能要求撤销清单的联机检验，可能规定要使用的操作服 务器160和置信服务器165等。担保代理170不知道对应于被证明的 公共密钥的私人密钥--只有用户知道。知道私人密钥被用作为对契约 持有人身份的证明。(在很多情形下这允许买方和卖方的匿名性，当 然除了在非常特别的情形下他们对担保代理170都不是匿名的)。
对买方的担保证明将称为BCB，而对应的公共密钥和私人密钥 将分别称为PKB和SKB。
通过买方、置信服务器165和操作服务器160之间的交互作用公 告CPO 100。协议的这一部分能够以只不过在各方之间传输的加密 的电子邮件来实现。
在CPO 100可以公告之前，买方必须从置信服务器165取得证 明。要求这一点以便买方和操作服务器160都知道他们指定的判定合 同是否已经履行的置信服务器165实际上愿意接受CPO 100。操作 服务器160在没有如下所述的TRUSTED_ACCEPTANCE消息的情 形下将不接受CPO 100。
除非置信服务器165确信买方的CPO 100是新的(不是再放)，且 买方的支付能力由担保代理170保证，否则它将不会发出 TRUSTED_ACCEPTANCE。买方还必须确信向他发出的是新的 TRUSTED_ACCEPTANCE。
协议的工作如下：
1.买方形成
U0＝＂REQUEST FOR TRUSTED APPROVAL＂
X0＝U0，CPO，RO，附加条款
并发送到置信服务器165
M0＝PKEPKA(X0，SignSKB(X0))。
2.置信服务器165以
U1＝＂TRUSTED CPO CHALLENGE＂
R1＝160位随机数
X1＝U1散列(X0)，R1
响应并向买方发送
M1＝PKEPKB(X1，SignSKA(X1))。
3.对此买方以
U2＝＂BUYER CPO RESPONSE＂
X2＝U2，散列(X1)
响应并向置信服务器165发送
M2＝PKEPKA(X2，SignSKB(X2))。
4.置信服务器165以
U3＝＂TRUSTED CPO ACCEPTANCE＂
T3＝Timestamp (时间印记)
X3＝U3，散列(X3)，T3，CPO
响应并向买方发送
M3＝PKEPKB(X3，SignSKA(X3))。
5.买方存储X3作为TRUSTED_ACCEPTANCE。
为了使操作服务器160公告CPO 100，必须确信CPO 100具有 新的TRUSTED_ACCEPTANCE，且它是由担保代理170产生的。 这是如下进行的：
1.买方形成
R0＝随机160位数
U0＝＂CPO SERVER SUBMISSION＂
X0＝U0，R0，TRUSTED_ACCEPTANCE
然后向操作服务器160发送
M0＝PKEPKS(X0，SignSKB(X0))。
2.操作服务器160接收M0并对其检验。如果它是新的(不是回 放)，并且如果操作服务器160愿意公告CPO 100，则它形成
R1＝随机160位数
U1＝＂SERVER CPO CHALLENGE＂
X1＝1，散列(X0)，R1
并然后加密且向买方发送
M1＝PKEPKB(X1，SignSKS(X1))。
3.买方形成
U2＝＂CPO RESPONSE TO SERVER CHALLENGE＂
并向操作服务器160发送
M2＝PKEPKS(X2，SignSKB(X2))。
4.如果这一消息的签字验证正确，则操作服务器160公告CPO。 操作服务器160形成
U3＝＂POSTED CPO RECEIPT＂
CPO＝U3，散列(X2)，CPO。
然后它向买方发送
M3＝PKEPKB(CPO，SignSKS(CPO))。
在这一协议的末尾，买方有收据通知它的CPO 100已经公告， 并且操作服务器160确信担保证书172的持有者刚才已经同意CPO 100，并具有置信服务器165的准许。
潜在的卖方具有其自己的担保证书172(BCP)。在他获准实时浏 览CPO 100(有能力约定它们)之前，他必须通过一个协议。(CPO 100 对未正在浏览的人们是可得的，但是在他们通过这一协议之前任何人 不准许约定CPO 100)。这一协议的目的是要证明卖方由担保代理170 保证有能力交付所需货物，并通过建立秘密的鉴定密钥Kp还降低了 操作服务器160的计算负荷。所有这样作法降低了允许潜在的卖方浏 览CPO 100的计算花费。
1.潜在的卖方形成
R0＝随机160位数
T＝时间范围
U0＝＂REQUEST FOR ACCESS TO BROWSE＂
X0＝U0，R0，T，BCP
并向操作服务器160发送
M0＝PKEPKS(X0，SignSKP(X0))。
2.操作服务器160决定是否认可潜在的卖方。如果认可，则它形 成
R1＝随机160位数
U1＝＂SERVER BROWSE-ACCESS CHALLENGE＂
X1＝U1散列(X0)，R1
并向潜在卖方发送
M1＝PKEPKP(X1，SignSKS(X1))。
3.潜在的卖方通过形成
U1＝＂BROWSE-ACCESS RESPONCE＂
而响应并向操作服务器160发送
M2＝PKEPKS(X2，SignSKP(X2))。
4.操作服务器160检验签字，并然后通过形成
U3＝＂BINDING KEY＂
Kp＝用于约定CPO 100的随机密钥。
T＝时间范围(从第一个协议消息起)
X1＝U3，散列(X2)，T，Kp
并向潜在的卖方发送
M3＝PKEPKP(X3，SignSKS(X3))。
在这协议的末尾，潜在的卖方在最近的消息中所规定的时限内保 有共享的密钥，以该密钥他被准许约定CPO 100。潜在的卖方和操 作服务器160都确信它们已经彼此实时交互作用，并且操作服务器160 知道，潜在的卖方按约定的CPO 100交付的能力是由担保代理170 保证的。
在潜在的卖方浏览各CPO 100时，每一个是通过操作服务器160 在KP的鉴定之下发送给他的，并包含一随机检测以防止重放的袭击。 当潜在的卖方希望约定一个时，他在KP的鉴定之下形成一约定CPO 100的要约。操作服务器160确信这是真实的约定CPO 100的要约， 且这是正在实时发生的。它通过向他发送BOUND CPO响应。
1.操作服务器160形成
U0＝＂CPO OFFER＂
R0＝随机160位数
X0＝U0，R0，T，CPO描述
并向潜在的卖方发送
M0＝PKEPKS(X0，AuthKp(X0))。
(注意这一步骤对每一浏览的CPO 100重复)
2.潜在的卖方形成
U1＝＂CPO OFFER TO BIND＂
R1＝随机160位数
X1＝U1，散列(X0)，R1，要约细节
并加密且向操作服务器160发送
M1＝PKEPKP(X1，AuthKp(X1))。
3.如果要约对操作服务器160是可接受的，则它形成
U2＝＂SERVER BINDING OF CPO＂
T＝时间印记
X1＝U2，散列(X1)，BCP，T，CPO，要约细节
并加密且向潜在的卖方发送
M2＝PKEPKP(X2，SignSKS(X2))。
4.潜在的卖方作为BOUND_CPO存储X2，SignSKS(X2)。
BOUND_CPO的要约细节字段规定CPO 100的条件。在大多数 情形下，这将涉及对支付的交换而交付某些货物，可能在来自置信服 务器165的代理人在场情形下。然而在某些情形下，这可能涉及中介 人，以保持潜在的买方、卖方或两者的匿名性。重要的是潜在的卖方 具有BOUND_CPO，使得他能够以简单的检测响应协议向买方或中 介人证明其身份。
这组协议描述了支持CPO 100的底层结构的一种可能的实现。 重要的是要注意，操作服务器160、置信服务器165及担保代理170 可以是相同的一实体。这种情形下，协议可大为简化。
易货实施例
并不是所有的交易要求货币从买方向卖方转移。在易货交易中买 方和卖方之间的差别消失了，结果是第一方和第二方之间的一种合 同。第一方公告CPO 100，而第二方约定它。第二方从第一方接受 的不是现金，而是货物。例如，一个需要处理掉摩托车的第一方可能 公告CPO 100，其中他的要约是以从纽约到伦敦的一等票交换摩托 车。
仲裁协议
虽然以上的实施例已经说明货物从卖方向买方交付作为过程的终 止，但不可避免地某些交易将会引起争执，要求继续的行动解决这些 争执。本发明能够以两种方式支持争执的解决。
首先，向每一CPO 100植入语言，要求双方服从所有争执的有 法律效力的仲裁，以有助于避免法庭中更为费时和费钱法律战。此外， 可以设置违约赔偿金，它规定了对CPO 100的具体违约的赔偿量。
第二，中央控制器200通过提供对每一争执的仲裁人而能够支持 仲裁过程。当从卖方发运的货物与CPO 100的条件不符时，可以要 求这种仲裁。例如，要求不停顿的飞机票的买方，可以对交付的是带 有一次或多次停顿的机票卖方寻求赔偿。类似地，其CPO 100是要 非吸烟旅馆房间的出差旅行者，可以从以吸烟的房间约定该CPO 100 的旅馆寻求赔偿。买方可以不是要求赔偿，而是要求货物的替换，诸 如不停顿的另一航线的机票。在涉及航空公司机票的仲裁中，买方可 以向中央控制器200与CPO 100的跟踪号码一同提交机票拷贝件， 以使仲裁者能够裁决卖方是否履行了CPO 100的条件。如果卖方发 运了货物而没有从买方收到支付，卖方也可以发起仲裁处理。
在另一实施例中，交易数据能够发送给系统以外的第三方仲裁 者。中央控制器200可以向仲裁者发送CPO 100的拷贝、卖方响应 110、及购买确认。如果有验证或非拒付问题，密钥也可以提供给仲 裁者。
本发明的应用
为了说明本发明的应用，以下的例子展示了最终用户的潜在需 求：
CPO：航空机票
需要四张机票
从芝加哥的O＇Hare或Midway机场到Phoenix。
4月12或13日离开
4月18或19日返回。
六个最大的运输公司的任何一个可接受。
如果停留时间不超过2小时换机可接受。
我愿意约定每张机票$180不含税。
CPO：旅馆设施
住宿五夜
4月12或13日到达，4月18或19日离开
离Phoenix市中心30分钟驱车时间内
双人床位
非吸烟
旅馆、汽车旅馆或住宿与早餐旅馆均可接受
必须是AAA等级或汽车2星旅馆或更好
我愿以每夜$55约定(不含税)。 CPO：新汽车购买
1997年Ford Taurus
必须是零售商现货
GL包带空调
AM/FM/卡盒(货品#1224-099)
可以安装其它可选设备
可以是白色、棕黄色、绿色或栗色。
里程数100英里或更少，未上牌照
不要零售商示范车
向我交付不晚于1996年7月15日
贷款预审：Chase Manhattan#1220-998-887AD-21
我将以$21,350约定 CPO：汽车保险
1997 Ford Taurus
1人驾驶，年龄40，男性
家住Rdgefield，CT
驾车上班30英里
包括撞车
$500绝对免赔率
包括玻璃风档
过去3年没有超速违章
过去3年没有事故
1MM责任保护
驾驶执照#CT 1222-221-2298
保险公司等级必须是A或更好，AM最好
我将以每年$1,200约定 CPO：U.S.银元
1886 Morgan
费城造币厂标记
以ANA封装密封
MS94或更高级别
我将购买最多总共6枚
卖方可满足全部或部分订货
我将以每枚$225约定
要约监理：Coiworld，P.O.Box 1000，M.Y.，N.Y.
Mr.K.Smith 212-222-1000 CPO：工业品
我公司欲购40吨钢材
等级120
纽约市FOB交货
级别4厚板或级别12铸锭
合金RT-12或等同产品
1996年八月1目前交付
最大价格按Citibank所知
将约定低于最大价格的第一投标
Citibank提供即时的价格验证
每天每个供货者1个投标(GMT)
E-mail@metal.biddesk4022Citi.com
信用支付信件，Citibank 100-887-9877 CPO：信用卡申请
VISA金卡
信用限额$5,000
利率12％或更低
我将以每年$10约定
财经史可在http：//www.provider/～shapiro23得到
CPO：失物悬赏
内有重要计算机盘的手提箱遗失
盘标号RT-554 IBM
1996年四月7日遗失在NYC地铁F线
愿以$500约定
提供遗失&找回收据#以索取奖金
要约监理人：NYC Police&Found
Mr.K.Smith 212-555-1000
工业应用
就上述详细的描述来说，除了其它的系统之外显然本发明可以用 来生成以下的一个或多个系统：
-允许满足购买要约条款的卖方约定买方接受卖方对该要约的履 约的系统；
-允许在卖方接受买方在购买要约中提出的条款时能够立即集资 的系统；
-允许置信的第三方监理者的系统，其有关履约、过程任何方面 的适当性或解释的决定将对各方有约束力；
-允许卖方在同意买方的购买要约时接收其部分支付，并在买方 的购买要约中所要求的货物或服务交付时接收随后支付的系统；
-允许买方或卖方直到协议被圆满执行后保持匿名、并对买方甚 至在协议被圆满执行后保仍持匿名的系统，系统通过使用作为中继系 统的置信的第三方负责对买方购买要约要求的货物或服务的交付；
-保证使用本发明的系统的买方不会被来自没有资格的卖方的询 问和或承诺所淹没的系统；
-提供了其中与对买方购买要约的完整性一同对买方身份的验证 的一种系统的系统；
-其中对卖方身份进行验证以确定卖方满足购买要约条件的能力 的系统；
-允许卖方提交可验证的对买方要约的还价的系统；
-其中还价可以允许买方在该还价的可验证条款条件下与卖方对 还价约定的系统；
-其中允许根据买方的购买要约的条款从卖方向买方交付诸如保 险证书等基于数字化的产品及这种交付的加密证实的系统；
-其中允许多于一个的卖方可以就购买要约与买方约定的购买要 约的系统；以及
-其中表示系统的全部或部分能够使用诸如打印的介质或报纸的 广告等非电子方法实现的系统。
就以上对本发明详细的说明来看，本发明显然提供了这样一种方 法和装置，使预期的货物或服务的买方能向潜在的卖方广泛联系可约 定的购买要约，使卖方能方便地搜索相关买方购买要约，并使卖方能 基于买方的购买要约约定卖方而达成合同。此外，本发明通过保证买 方对购买的支付而实现卖方和买方之间协议的履行。因而本发明是一 高度有效的双方买方驱动的商业系统，它改进了买方搜索能够满足买 方购买需要的卖方的能力，并改进了卖方识别意中的买方的能力。
在本发明的一个实施例中，使用电子网络和中央控制器在买方和 卖方之间进行通信。想要进行购买的买方访问位于远程服务器的中央 控制器。然后买方通过规定他想要购买的货物的目标、他想要获得的 货物的描述、及买方要求的其它条件，而生成有条件购买要约 (″CPO＂)。例如，典型的CPO可以是规定买方想要购买从芝加哥 O＇Hare机场到德克萨斯的达拉斯的一组四张航空机票，机票必须出 自六个最大的美国航空公司之一，买方愿意最多预定不超过两个小时 的一次性换机停留，且买方愿意支付每张机票$180，加适当的税款。
然后买方把用户的标识附加在CPO上并把该CPO传输到中央 控制器。在本发明之下，CPO可以通过包括万维网接口、电子邮件、 话音邮件、传真或邮政邮件等的各种方式传输。然后标准的法律条款 和用语与CPO形成一整体以对买方的购买要约“填缝”。另外，CPO 可以在买方与中央控制器联机时产生。
在使CPO与潜在的卖方通信之前，中央控制器对照买方数据库 验证买方的标识号码。中央控制器可以要求买方提供信用卡号码，并 还可以通过与信用卡结算银行联系而保证买方有足够的可用的信贷函 盖CPO中规定的购买价格。然后中央控制器向CPO指定唯一的跟 踪号码，并广泛显示CPO，使之所有有意的潜在卖方能够看得到。CPO 可以按目标分类显示，使得潜在的卖方易于识别相关的CPO。这样， 例如卖方可用登录到web网点上，并看见CPO目标分类列表。然后 卖方能够选择特定的目标，并能够浏览对应于该目标类别的CPO。 在一个实施例中，可以要求卖方提供证明以便查看给定的目标类别的 CPO。
如果在查看特定的CPO之后，潜在的卖方想要接受该CPO，则 卖方把他的意图通知中央控制器。然后中央控制器对来自卖方的消息 打上时间印记，并验证卖方的身份及其对买方寻求的货物的支付能 力。然后系统检验该特定的CPO是否仍然“有效”并能够被接受。 如果该CPO只能由一个卖方接受，在第一个合格的卖方接受它时它 就被“完成”。以后的卖方将不能接受“完成”的CPO。如果卖方接 受了一个有效的CPO，则向该卖方的承诺指定一个跟踪号码。然后 该承诺被存储在数据库中。买方和卖方现在是对合法约定的合同的双 方。
在另一实施例中，中央控制器自动地管理买方和卖方之间的支付 系统。本发明能够采用各种支付方法，包括信用卡、个人支票、电子 资金转帐、借贷卡、及数字化货币。支付系统还可能涉及第三方与买 方相关的暂存帐户的使用，其中由买方提供的函盖所需货物购买的资 金能够由合格的卖方保持为未决的承诺。此外，向卖方支付的定时能 够被改变。能够在卖方接受CPO之后立即向卖方支付，或支付可以 延迟直到卖方履行合同契约之后。
在本发明的另一实施例中，通过发出带有与原来的CPO不同的 条件的可约定的还价，向卖方给出响应CPO的选择。卖方向中央控 制器传输还价，然后中央控制器向买方转发该还价。然后向买方给出 接受还价的选择，从而约定卖方达成合同。
本发明还可以按脱机实施例实现。替代使用电子邮件或基于web 的服务器，买方和卖方可以通过电话、传真、邮政邮件或其它脱机通 信工具与中央控制器联系。例如，买方可以使用电话生成CPO(使用 或不使用现场代理的帮助)，并且潜在的买方可以使用电话浏览并约 定CPO。
在另一个联机实施例中，使用命密码协议验证买方和/或卖方的 身份并检验买方和卖方与中央控制器通信的完整性。使用密码术和生 物学检测，中央控制器能够使未授权者企图以作为合法买方或卖方通 过而窜改系统，或窃取系统的通信更为困难。
匿名性是本发明的另一优点。由于各种私密或竞争的原因，买方 和卖方常常希望在从事商业交易时不要向一般公众显露身份。本发明 通过使用存储在由中央控制器保全的数据库中的识别号码，实现了买 方和卖方的匿名性。
本发明的一个实施例把中央控制器的功能分为三个组成部分，并 以三个分开的服务器实施它们：一个操作服务器、一个置信服务器、 及一个担保代理。置信服务器验证买方和卖方的身份，而担保代理检 验它们支付或交货的能力。操作服务器依赖于来自另外两个服务器检 验消息公告CPO。这一配置允许服务器较高的专用化。
本发明的另一实施例不要求从买方向卖方转移货币。而是使用系 统完成涉及货物、服务或其它非货币考虑的交换的合同。
最后，本发明的一个实施例包含用于解决使用系统完成协议引起 的买方和卖方之间的争执一种机制。可以要求各方在CPO中保证有 法律效力的仲裁为条件，并可以在仲裁过程中由中央控制器协助。中 央控制器可以作为仲裁者服务，或可以把争执提交第三方仲裁者解 决。
本发明实现的是以前的任何系统没有作到的事情，即在字面上来 说是把买方的钱悬挂在晾衣绳上使所有的卖方能够看到。附加在钱上 的是说明卖方为从晾衣绳取下这钱必须同意作的事情的注释。在卖方 方面没有不确定性或时间的浪费。他知道如果它能够满足买方提出的 条件，他能够立即结束销售并为这获得支付。没有没完没了的争论。 用不着商讨。
本发明还允许买方得到大量位于远程的卖方，这些卖方通常不能 找到该买方，但是它们却能够向买方提供买方真正所需的东西。例如， 可以是这样一种情形，即一个能够详精确定义他所希望以特定价格购 买的汽车和一组选件的汽车买方。本发明允许这样的买方发出可约定 的购买要约，该要约广泛通知到在美国授权的销售商。然后任何一个 这样的销售商可以决定是否接受这一要约。当如保险销售的情形那 样，买方所搜寻的产品的卖方没有存量成本，对买方的优点则特别明 显。保险买方可以使用本发明形成广泛的网络达到成千的潜在保险卖 方，并潜在地找到愿满足买方规定的购买条件的卖方。
本发明的一个目的是提供一种坚固的系统，该系统把买方的要求 与能够满足这些要求的卖方匹配起来。本发明的买方和卖方提供了一 种广泛的双边买方驱动的，结合了各种通信、商业及安全方法的用于 生成可约定合同的系统。中央控制器的力量在于对来自买方的可约定 的要约提供场所，以能够由潜在的卖方有效地访问和分析的格式广泛 传播这些要约，实现结果的合同的履行，解决由执行合同引起的争执， 并维护帐目、收集、验证、匿名性，使本发明对传统的系统是一重要 改进。
基于代理的卖方
现在将参照图21到40描述本发明的另一实施例的方法和装置， 它允许CPO管理系统代表一些的基于代理的卖方接受或拒绝给出的 CPO，这样的卖方把这种授权委托给CPO管理系统。
图21示出有条件购买要约(CPO)管理系统2100，用于从以下称 为顾客2110的一个或多个顾客或旅行代理人2110接收有条件购买要 约，并用于评估收到的CPO对比由多个卖方，诸如航空公司2120、 2130或巡游经营者(未示出)，定义的数个CPO规则，以确定任何卖 方是否愿意接受给定的CPO。如以下进一步的讨论，如果卖方接受 给定的CPO，则CPO管理系统2100代表接受的卖方2130约定顾客 2110，以便形成有法律约束力的合同。
如这里所使用的，CPO是包含由顾客按顾客定义的价格为购买 一条款，诸如飞行旅行而提交的一个或多个条件的可约定要约。在所 示的航空公司的实施例中，顾客定义的条件将包括旅程参数，诸如出 发和目标城市；出发和返回可接受的日期和时间；及顾客是否接受中 转飞行或中途停留。此外，CPO的参数还允许顾客规定一个或多个 希望的航空公司，航班，座位的指定，座位等级，飞机型号，退票/ 更改规则，或最大中途停留时间。在游轮实施例中，顾客定义的条件 还将包括旅程参数，诸如出发和目标城市；出发和返回可接受的日期 和时间；以及一个或多个希望的游轮经营者，航船类型，舱位等级， 膳食偏好。
如以下进一步所讨论的，CPO规则是一组由给定的卖方，诸如 航空公司，定义的限制，以便定义卖方愿意接受预定的最小价格下的 这种限制的组合。在一优选实施例中，CPO规则由各航空公司或巡 游经营者的收益管理系统2500产生。在另一实施例中，CPO规则可 能由产量管理系统、利润管理系统，或任何控制并管理存量的系统产 生。
如以下结合图25b及图39更为充分的讨论，收益管理系统2500 将通过评估当前存量、定价及收益信息，以及历史模式和外部活动， 使用CPO规则产生过程3900产生CPO规则。此后，CPO规则由CPO 管理系统2100使用以便作出决定代表特定的航空公司或巡游经营者 或者接受、或拒绝或讨价CPO。根据本发明的特点，CPO规则在性 质上是动态的，并必要时可以由给定的航空公司或其它卖方更新。
例如，对于给定的航空公司的CPO规则能够规定，航空公司将 接受任何为在Newark，New Jersey(EWR)和Orlando，Florida(MCO) 之间在1997年10月期间旅行的CPO，如果(i)顾客是在星期二和星 期四之间旅行，(ii)机票在出发前21天内定票，(iii)每张机票价格至 少为$165，(iv)K-等级存量在顾客旅程的所有飞行区段可得，以及(v)至 少有两(2)个旅客一同旅行。
虽然这里示出的CPO管理系统是作为用于销售航空或巡游票的 系统，但是对于普通专业人员明显的是，CPO能够用于销售任何货 物或服务产品，诸如汽车、保险、计算机设备、或旅馆设施。对于用 于销售这种物品的一般CPO管理系统的更详细的讨论，请参见作为 本发明的原始申请的1996年9月4日提交的No.08/707,660美国专利 申请，该申请在此结合作为参照。要注意的是，在这种另外的实施例 中，以下参照图25a到25c所讨论的收益管理系统2500，能够作为 由卖方使用的存量管理系统或任何其它系统而被实施，以便对各种物 品确定定价和存量信息。
CPO管理系统
如图21所示，CPO管理系统2100最后包括CPO管理中央控制 器2200和一个或多个航空公司安全服务器2300。如以下结合图23 进一步所讨论的，每一航空公司安全服务器2300可以与一个或多个 航空公司或巡游经营者相关，并除了其它的东西之外，每一服务器 2300存储由诸如航空公司2120等任何相关卖方定义的CPO规则。 每一航空公司安全服务器2300可以位于离CPO管理中央控制器2200 远处，如图21所示，或可以与CPO管理中央控制器2200结合在一 起。在一个远程实施例中，与每一航空公司或巡游经营者相关的航空 公司安全服务器2300可以在物理上位于由特定的航空公司或巡游经 营者保护的处理设施处，或在第三方的物理位置。这样，航空公司或 巡游经营者能够独立地评估CPO规则。
对于一般专业人员明显的是，航空公司安全服务器2300的位置 将决定航空公司2120、2130或巡游经营者(未示出)与CPO管理系统 2100之间传输的信息的性质。例如，如果航空公司安全服务器2300 与CPO管理中央控制器2200结合在一起，或者另外位于距离各个 航空公司2120、2130或巡游经营者(未示出)远处，则各个航空公司 2120、2130或巡游经营者，将向用于存储CPO规则和对照每一收到 的CPO的CPO申请的航空公司的相关航空公司安全服务器2300的 位置，传输CPO规则。类似地，如果航空公司安全服务器2300物 理上位于由相关的航空公司或巡游经营者保护的处理设施处，则CPO 管理中央控制器2200将向每一航空公司或巡游经营者传输用于处理 的CPO，并且航空公司或巡游经营者将向CPO管理中央控制器2200 返回对每一CPO的响应。这样，CPO管理系统2100通过向每一卖 方提供CPO并接收承诺或拒绝，能够确定一个或多个卖方接受给定 的CPO，或者通把CPO用于CPO规则而代表特定的卖方作出或者 接受、或者拒绝、或者讨价CPO的决定。
CPO规则包含敏感的信息，这包括价格灵活性和可得的容量， 这如果让卖方的竞争者或顾客知道，将会剧烈冲击卖方整个的收益结 构。因而，根据本发明的一个特点，如果必要，CPO规则最好由每 一航空公司服务器2300安全地存储，以防止诸如航空公司2120这样 的一个卖方访问、获得或改变诸如航空公司2130这样的另一个卖方 的CPO规则。在一个实施例中，航空公司安全服务器2300使用计 算机安全技术，诸如数据库访问控制机制。这样，CPO规则的完整 性和保密性在潜在敌意的计算环境中得到了维护。
此外，根据本发明的另一特点，CPO管理系统2100防止顾客2110 为了识别出卖方对于给定的航班或舱位所定义的最小价格，而提交包 含逐渐增加价格的多个CPO。例如，如果假定由任何航空公司2120 或巡游经营者接受CPO将约定到顾客2110，则将阻止顾客2100“侦 察”CPO管理系统2100以识别卖方基本的价格灵活性。此外，CPO 管理系统2100能够限制在预定的时间段内任何顾客2110能够提交的 CPO的数目。
在另一实施例中，如果当至少一个航空公司接受了CPO时而没 有定座，则能够对顾客或旅游代理2110收费或罚金，或CPO管理系 统2100能够评估包含有关所述顾客2110将对应于所述CPO定座的 可能性的信息的所述顾客2110的等级。对于适当的等级系统更为详 细的描述，请参见标题为AIRLINE PRICE INQUIRY METHOD AND SYSTEM，1997年3月4日提交的No.08/811,349美国专利申请，转让 给本发明受让人并在此作为参照。在一个实施例中，被评估的信誉包 括由顾客2110对购买要约定座的比率。这样，航空公司或巡游经营 者能够确信，如果卖方接受顾客的要约，则顾客将对票定座而不使用 信息查明卖方价格灵活性的基本水平。给定的航空公司安全服务器 2300的特定位置，也可能影响相关的航空公司或巡游经营者可能对 敏感的CPO规则所需的安全措施的水平。例如，如果给定的航空公 司安全服务器2300是单个航空公司专用的，且物理上位于由相关航 空公司保护的处理设施处，则如果需要，各航空公司能够实现其自身 最小的安全措施控制每一CPO对其自身的CPO规则的处理，从而 维护了纳入CPO规则中的价格敏感信息的完整性和保密性。然而如 果给定的航空公司安全服务器2300为多个航空公司或巡游经营者存 储CPO规则，并位于远离这种航空公司或巡游经营者的位置，则一 般专业人员显然知道，实现计算机安全性和数据库访问控制机制的重 要性可能要增加。
如以下将要讨论的，每一顾客2110例如通过电话、传真、联机 访问、电子邮件、亲自接触或通过旅行社代理人与CPO管理系统联 系，并向CPO管理系统2100提供他们的CPO的条款。要注意，每 一顾客2110可以使用通用计算机用于与CPO管理系统2100通信。 每一顾客2110的用计算机最好由处理单元、调制解调器、存储器装 置，以及与CPO管理系统2100通信所需的任何软件组成。
一旦CPO的条款已经由CPO管理系统2100接收，则CPO管 理注意服务器2200将执行以下结合图36a到图36讨论的CPO管理 过程3600，以便把收到的CPO对照每一航空公司或巡游经营者的 CPO规则进行比较。作为比较的结果，该CPO或者被接受、拒绝或 讨价。因而，通知顾客2110航空公司或巡游经营者对CPO的响应。 如果卖方接受CPO，或如果顾客2110接受来自卖方的还价，则由CPO 管理系统2100以满足由顾客2110定义的条件的适当的限制对票进行 定座。
根据本发明的另一特点，CPO的最小要求设计为使通常愿付全 票价的出差旅行者或最后时刻旅行者放弃使用这系统。例如，如果 CPO规则要求星期六夜晚停留，或顾客2110对顾客旅程的出发与返 回时间有显著的灵活性，则将使出差旅行者放弃。这样，将使通常不 愿意在其旅程末尾失去一整天的出差旅行者放弃购买这种折扣票。这 样，本发明允许航空公司以别的方式填充空位，这种方式刺激潜在的 未满足的闲暇旅游需求，而又不触动航空公司2120、2130的基本票 价结构。
类似地，在对任何条款的销售采用CPO管理系统的实施例中， 最好设计CPO的最小要求，使通常愿意支付零售全价的顾客放弃使 用这一系统。例如，当销售时装款式时，可要求CPO顾客购买上一 季的时装。类似地，CPO规则可设计为要求购买多个给定的款式， 从而使寻求一个款式而更愿意支付零售全价的顾客放弃使用。
在一优选实施例中，CPO管理系统2100可以有选择地访问以下 结合图24将讨论的中央保留(预定)系统(CRS)2400，以进行识别 出满足给定旅程的特定航班或舱位的旅程查询，并作出保留。中央保 留系统(CRS)2400例如可以作为现有的传统的保留系统实现，例如 Apollo，Sabre，System One或Worldspan。
此外，CPO管理系统2100可以另外方式访问每一航空公司或巡 游经营者的业主保留系统(ARS)2150，以进行这种旅程查询，并与各 航空公司或巡游经营者作出保留。由每一航空公司2120维护的航空 公司保留系统(ARS)2150，基本上分别是中央CRS 2400的子集。这 样，就CRS 2400与每一航空公司或巡游经营者的业主保留系统2150 的重叠功能和能力来看，CPO管理系统2100能够访问任何这种系统 以获得所需的信息，故这里术语“CRS”与“ARS”可交换使用。
如图21所示，每一航空公司2120、2130或巡游经营者(未示出) 还具有收益管理系统(RMS)2500，这将在以下结合图25a到25c进一 步讨论。RMS 2500可以作为传统的RMS嵌入，在这里被修改以产 生CPO规则，并另外对CPO顾客销售的航空公司或巡游票分配并 定价。
一般，收益管理系统(RMS)2500用来以熟知的方式优化每航班或 舱位的收益。RMS通过对各种收费等级周期调节套入的定座限额进 行座位或舱位存量控制，以便优化旅客混合，并从而使产生的收益最 大化。
CPO管理系统2100、顾客2110、航空公司2120、2130、巡游经 营者(未示出)及中央保留系统2400(总称为“结点”)最好彼此之间传 输数字编码数据及其它信息。结点之间的通信链路最好包括其上可传 播电子信号的电缆、光纤、无线链路。例如，每一结点可以通过使用 公共交换电话网(PSTN)的因特网连接，诸如由本地或区域电话运营 公司通过的这种网络。另外，每一结点可以通过专用线路、蜂窝电话 网、个人通信系统(＂PCS＂)、微波、或卫星网络连接。
图22是表示示例性的CPO管理中央服务器2200的框图。该CPO 管理中央服务器2200最好包括一定的标准硬组件，诸如中央处理器 (CPU)2205、随机存取存储器(RAM)2210、只读存储器(ROM)2220、 时钟2225、数据存储器装置2230、及通信端口2240、2250、2260。 CPU 2205最好连接到每一其它列出的部件，或者通过共享的数据总 线，或者专用的连接，如图22中所示。
CPU 2205可以作为单一的市售处理器嵌入，诸如Intel的Pentium 100Mhz P54C微处理器，Motorola 120MHz PowerPC 604微处理器 或Sun Microsystem的166MHz UltraSPARC-1微处理器。另外，CPU 2205可以作为数个并行操作的这种处理器嵌入。
ROM 2220和/或数据存储器装置2230可操作以存储以下结合图 36所讨论的一个或多个指令，CPU 2205可操作对这些指令进行搜索、 解释并执行。例如，ROM 2220和/或数据存储器装置2230最好存储 一些过程，以便在航空公司2120、2130及顾客2110之间实现要求的 支付、收费、和罚款的转帐。特别地，如以下结合图36c所讨论，如 果票实际发给了顾客2110，CPO管理过程3600最好向信用卡发放者 传输有关给定的顾客2110的信用卡信息用于支付。这种会计交易的 处理最好以通常的方式保证安全，例如使用熟知的密码技术。
CPU 2205最好按熟知的方式包括控制单元、算术逻辑单元 (ALU)、及CPU局部存储器存储器装置，诸如可堆栈高速缓存器或 多个寄存器。控制单元可操作以便从数据存储器装置2230或ROM 2220检索指令。ALU是可操作以便进行执行指令所需的多种操作。 CPU局部存储器存储器装置可操作以便提供高速存储，用于存储暂 时的结果和控制信息。
如以下结合图26到29分别所讨论的，数据存储器装置2230包 括顾客数据库2600、航空公司数据库2700、航班时刻表数据库2800、 及CPO数据库2900。顾客数据库2600最好存储关于CPO管理系统 2100的每一顾客的信息，包括个人情况信息和开单信息，诸如信用 卡号码。航空公司数据库2700最好存储关于对CPO管理系统2100 登记了的向CPO顾客销售航空公司机票的每一航空公司的信息，包 括地址和联系信息。航班时刻表数据库2800最好对每一起点终点对 存储具体航班的信息。最后，CPO数据库2900最好包含正在由CPO 管理系统2100处理的每一CPO的记录，包括CPO条款和相关状态。
此外，数据存储器装置2230包括在以下结合图36进一步讨论的 CPO管理过程3600。一般来说，CPO管理过程3600从顾客2100接 收每一CPO，对照每一航空公司2120、2130的CPO规则比较CPO， 并代表航空公司确定是接受、拒绝还是讨价CPO。
通信端口2240连接CPO管理中央服务器2200与由每一航空公 司2120、2130维护的中央保留系统(CRS)2400及业主保留系统 (ARS)2150。通信端口2250，例如通过使用公共交换电话网(PSTN) 的因特网连接CPO管理中央服务器2200与各个顾客及旅行社代理 人，诸如顾客2110。通信端口2260连接CPO管理中央服务器2200 与任何远程的航空公司安全服务器2300。通信端口2240、2250、2260 每一个最好包含多个通信信道用于同时建立多个连接。要注意，虽然 CPO管理中央服务器2200表示为具有三个分开的通信端口2240、 2250、2260，但CPO管理中央服务器2200能够另外由到以太网的 单个连接实现，该以太网反过来对中央服务器2200提供到各结点的 连接。
图23是表示示例性的航空公司安全服务器2300的框图。如前所 述，CPO管理系统2100可以使用一个或多个航空公司安全服务器 2300，每一个支持一个或多个航空公司2120、2130。每一航空公司 安全服务器2300最好包括一定的标准硬组件，诸如中央处理器 (CPU)2305、随机存取存储器(RAM)2310、只读存储器(ROM)2320、 时钟2325、数据存储器装置2330、及通信端口2340、2345。这些组 件的每一个可以与结合图22所述的组件相同。
如前面所指出，在一个实施例中，CPO规则可以存储在安全数 据库中，以便维护包含在每一CPO规则中高度敏感的信息的完整性 和保密性。这样，航空公司安全服务器2300最好使用安全数据库， 诸如商业上从Oracle，Informix或IBM可得的产品。
如以下分别结合图30到32进一步的讨论，数据存储器装置2330 包括航空公司规则安全数据库3000，还价规则数据库3100、及航空 公司审计安全数据库3200。航空公司规则安全数据库3000最好维护 对一个或多个与航空公司安全服务器2300相关航空公司的CPO规 则。还价规则数据库3100最好由每一航空公司安全服务器2300存储， 以便维护一组允限，如果CPO在预定与一给定CPO规则相关的一 个或多个限制的允限内，可由CPO管理系统2100采用该允限以代 表航空公司产生对CPO的还价。如前所指出的，航空公司规则安全 数据库3000和还价规则数据库3100可以按加密的格式存储，以便维 护包含在每一CPO规则中高度敏感的信息的完整性和保密性。航空 公司审计安全数据库3200最好对由CPO管理系统2100处理的每一 CPO维护审计记录。
此外，数据存储器装置2330包括以下分别结合图37和38进一 步讨论的评估过程3700和审计过程3800。一般来说，评估过程3700 是由CPO管理过程3600执行一个子程序，它接收CPO并把CPO 对照一个航空公司诸如航空公司2120的规则作比较，以便代表航空 公司对给定的CPO产生响应。审计过程3800是由CPO管理过程3600 执行一个子程序，以便保存由CPO管理系统2100处理的每一CPO 的审计记录。
通信端口2340把航空公司安全服务器2300连接到CPO管理中 央服务器2200。通信端口2345把航空公司安全服务器2300连接到 相关的航空公司2120。通信端口2340、2345最好包含多个通信信道， 以便同时建立多个连接。
中央保留系统
图24是表示示例性的中央保留(预定)系统(CRS)服务器2400 的体系结构的框图。CRS 2400最好包括一定的标准硬组件，诸如中 央处理器(CPU)2405、随机存取存储器(RAM)2410、只读存储器 (ROM)2420、时钟2425、数据存储器装置2430、及通信端口2440。 这些组件的每一个可以与结合图22所述的组件相同。
ROM 2420和/或数据存储器装置2430可操作以便存储一个或多 个指令，用于按熟知的方式处理(1)从航空公司收到的航班信息；(2) 有关航班可得情况的旅程查询；(3)机票定座，CPU 2405可操作以便 对这些指令进行检索、解释和执行。
如以下分别结合图33到34进一步的讨论，数据存储器装置2430 包括航班时刻表数据库2800、定价和限制数据库3300、及座位分配 数据库3400。如前所指出，航班时刻表数据库2800主要包含与由CPO 管理中央服务器存储的相同名称的数据库的相同的航班信息，即对每 一起终点对具体的航班信息。定价和限制数据库3300维护定价信息 以及对由航空公司2120、2130提供的给定航班上每一票价等级的相 关限制。座位分配数据库3400维护由航空公司120、2130提供的给 定的航班上每一种票价等级的可用存量信息。
通信端口2440把CRS 2400连接到CPO管理中央服务器2200 并连接到每一航空公司，诸如航空公司2120、2130。CRS 2400最好 包含电子邮件处理器2450，用于处理和存储CRS 2400及各顾客 2110、航空公司2120、2130与CPO管理系统2100之间传输的电子 邮件信息。
收益管理系统
图25a是表示作为由每一航空公司诸如航空公司2120维护的示 例性收益管理系统(RMS)2500的体系结构的框图。如前所指出的， RMS 2500可用普通的RMS嵌入，诸如从Sabre Dcision Tecknologies 可购买的RMS，它这里被修改为能产生CPO规则，并另外对向CPO 顾客销售的航空公司机票进行分配和定价。这样，RMS 2500使得航 空公司2120的存量部分可用于向CPO顾客销售。要注意，许多航 空公司的RMS只执行存量分配功能，而不参与定价功能。这种情形 下，使用分开的系统，诸如人工过程对已经由RMS分配的存量进行 定价。在这里公开所示的实施例中，RMS 2500即执行存量分配又执 行定价功能。
RMS 2500最好包括一定的标准硬组件，诸如中央处理器 (CPU)2505、随机存取存储器(RAM)2510、只读存储器(ROM)2520、 时钟2525、数据存储器装置2530、及通信端口2540。这些组件的每 一个可以与结合图22所述的组件相同。
ROM 2420和/或数据存储器装置2530可操作以便存储一个或多 个指令，用于分析当前的座位存量和收益以及历史模式，以便对可得 的座位存量进行分配和定价，努力使航空公司的收益最大化，CPU 2505可操作对这些进行检索、解释并执行。
如以下分别结合图33到35所讨论的，数据存储器装置2530包 括定价和限制数据库3300、座位分配数据库3400、它们每一个主要 包含由CRS 2400存储的相同名称的数据库的相同的信息，以及预测 和需求分析数据库3500。如前所指出的，定价和限制数据库3300维 护定价信息和由相关航空公司2120提供的给定的航班上每一票价等 级的相关限制，以及座位分配数据库3400维护由相关航空公司2120 提供的给定的航班上每一票价等级的可得的存量信息。预测和需求分 析数据库3500包含对给定的航班每一票价等级的每一销售票价的信 息，以及对由RMS 2500建立的每一销售价格的预测需求。此外，数 据存储器装置2530最好包括以下结合图39所讨论的CPO规则产生 过程3900，以便通过评估当前存量、定价和收益信息以及历史模式， 产生CPO规则预测未来的旅游。
通信端口2540把每一RMS 2500连接到CRS 2400及CPO管理 系统2100。
图25b示出RMS 2500使用数个数据库和其它工具实现通常的定 价和分配过程及CPO规则产生过程3900的方式。如图25b所示的 示例性数据库的特定格式和内容在以下结合图33到35详细讨论。要 注意，当航班第一次添加到航班时刻表中时，最初可由RMS 2500执 行通常的定价和分配过程及CPO规则产生过程3900，并然后响应需 求和外部活动周期地对可用的存量重新分配和定价。
这样，当航班第一次添加到航空公司2120的航班时刻表中时， 航班的记录最好由航班时刻表数据库2800中的航空公司保留系统 2150使用适当的旅程信息生成。此外，RMS 2500将执行与图39中 所示的CPO规则产生过程3900配合的通常的定价和分配过程，以 便如图25b所示，对航班的定价和限制数据库3300、座位分配数据 库3400、及预测和需求分析数据库3500的各个字段作初始填充。
一般来说，在对给定的航班初始定价和分配过程期间，RMS通 过建立多个票价等级并分配指定给每一票价等级的数个座位和票价试 图最大化收益。初始的座位分配和定价信息分别存储在座位分配数据 库3400和定价与限制数据库3300中。对每一票价等级的初始价格和 预测的需求最好存储在预测和需求分析数据库3500中。在一个实施 例中，能够通过向CPO顾客销售票的RMS 2500建立分开的票价等 级。由于卖给CPO顾客的票一般是折扣出售的，因而RMS 2500最 初最好只是向CPO票价等级分配被预测为空位或在航班起飞时不大 可能售出的座位。如所周知，航空公司能够使用普通的RMS 2500基 于可得历史数据预测给定的航班上是否有空位。
如图25b所示，航空公司保留系统(ARS)2150将访问所建立的定 价和限制数据库3300和座位分配数据库3400以进行旅程询问。此外， 在机票由航空公司2120售出时，ARS 2150最好将座位分配数据库 3400中的可得存量减一。这样，座位分配数据库3400维护每一航班 上可得存量的最新表示。
RMS 2500将继续监视每一票价等级内相对于预测的需求2570 的实际需求2560，如图25c所示，动态地重新评估存量分配及对给 定航班每一票价等级的定价，以便把不可预料的过多存量增量2580 降低到最小。RMS 2500通过检索来自座位分配数据库3400的详细 存量数据或来自预测和需求分析数据库3500的汇总信息，监视当前 实际需求信息。此外，RMS 2500将使用存储在预测和需求分析数据 库3500对于以前时期的历史需求信息，这些信息主要提供了对每一 航班上给定的票价等级的每一售价的需求曲线。例如，当对给定的航 班存量进行分配和定价时，RMS 2500可以按熟知的方式对类似的航 班从以前相关时间区间分析需求趋势。还应注意，如图25b所示，通 常的RMS一般对竞争力和其它活动诸如价格战或增加需求的大活动 (如奥运会)有响应。
根据本发明的特点，如果必要，航空公司2120通过向CPO顾客 释放供销售的票可以对预测差错，或对已经产生了不可预料的过多能 力2580的其它竞争力进行纠正。由于CPO规则保密的性质，以及 使全价出差旅行者放弃使用CPO票，航空公司2120、2130能够折 扣销售这种过剩的容量，而不会破坏其现有的票价结构。这样，在一 优选实施例中，RMS 2500将周期地执行以下结合图39讨论的CPO 规则产生过程3900，以产生刺激向CPO顾客销售机票的CPO规则。
数据库
图26示出示例性顾客数据库2600，该数据库最好存储CPO管 理系统2100的每一顾客的信息，包括个人情况信息和开单信息，诸 如信用卡号码。顾客数据库2600维护多个记录，诸如记录2605-2615， 每一记录与不同的顾客相关。对于列在字段2640中的每一顾客姓名， 顾客数据库2600在字段2645包含顾客地址，在字段2655中包含信 用卡号码。此外，根据帐户数据库2600最好在字段2660包含标识 (ID)。存储在字段2660的ID号码例如能够用来索引与顾客相关的以 前票的购买和CPO的历史数据库(未示出)。
图27示出一示例性航空公司数据库2700，该数据库最好存储对 CPO管理系统2100登记以便向CPO顾客销售航空公司机票的每一 航空公司的信息，包括地址和联系的信息。航空公司数据库2700维 护多个记录，诸如记录2705-2715，每一记录与不同的航空公司相关。 对于列在字段2740中的每一航空公司的名称，航空公司数据库2700 分别在字段2745和2750包含地址和联系的信息。例如联系信息可以 包括航空公司2120的每个雇员的姓名及对应的电话号码、web网页 URL、寻呼机号码、公告牌地址、电话号码、电子邮件地址、语音 邮件地址或传真号码。
此外，在给定的航空公司的CPO规则以加密格式存储的实施例 中，相关的航空公司的密钥最好存储在航空公司数据库2700的字段 2755中。最后，航空公司数据库2700最好在字段2760存储已经向 每一航空公司要约并已经实际上由各航空公司接受的CPO的百分数 的指示。这样，CPO管理系统2100能够按根据CPO接受率排列的 顺序向航空公司要约一特定的CPO，如以下结合图36b所讨论。在 另一实施例中，航空公司数据库2700能够根据基于以下纳入一些字 段便于CPO的处理(i)每一航空公司为向CPO顾客销售形成的可用 的存量，(ii)由每一航空公司议定的优先权，诸如对一定航线航空公 司的优先权，或(iii)由航空公司付给CPO管理系统2100的最高代理 费率。
图28示出示例性的航班时刻表数据库2800，该数据库最好存储 每一起终点对的特定的航班信息，以及连接信息。航班时刻表数据库 2800维护多个记录，诸如记录2805和2815，每一记录与不同航班相 关。对于列在字段2840和2845中的每一起终点对，航班时刻表数据 库2800在字段2850包含每一航班的日期，以及在字段2855和2860 包含各航班离开和到达的时间。与每一航班相关的航空公司和航班号 码最好分别在字段2865和2870中指示，且任何所需的连接在字段 2875中指示。
图29a和29b示出示例性的CPO数据库2900，该数据库最好包 含正在由CPO管理系统2100处理的每一CPO的记录，包括CPO 的条款及相关状态。CPO数据库2900维护多个记录，诸如记录2905 和2910，每一记录与正在由系统2100处理的不同的CPO相关。对 于由字段2920中的CPO号码标识的每一CPO，CPO数据库2900 在字段2925中包含CPO收到的日期，并如果有，则在字段2930中 包含与该CPO相关的旅行社代理人的标识(ID)号码。应注意，字段 2930中的旅行社代理人ID号码例如可用来索引与该旅行社代理人相 关的以前的机票购买和CPO的历史数据库(未示出)。
此外，CPO数据库2900通过在字段2935中的姓名，并通过字 段2940中的标识号码标识顾客，并在字段2945中标识任何同行的旅 客。存储在字段2945中的ID号码最好用来交叉参考在顾客数据库 2600中对顾客存储的对应的信息。
顾客的旅程和其它有关限制的参数存储在CPO数据库2900的字 段2950到2995中。特别地，起始和目标城市分别在字段2950和2955 中标识，并由顾客2110规定的任何连接限制存储在字段2960中。顾 客离开和返回的日期分别存储在字段2965和2970中。在另一实施例 中(未示出)，CPO数据库2900还能够允许顾客2110规定对离开和返 回的航班具体一天中的时间(范围)限制。
CPO数据库2900最好在字段2975存储一同旅行的旅客的总数 的指示，并在字段2980提供顾客愿意对每张机票支付的价格。由顾 客规定的任何其它杂项限制将记录在字段2985中，诸如较喜爱的航 空公司、航班、或座位的分配。字段2990记录各CPO当前的状态， 诸如待定、接受、拒绝或过期。最后，如果CPO最后的结果是机票 对顾客定座，则与机票相关的旅客的姓名记录号码(PNR)存储在字段 2995中。一般来说，PNR是由CRS 2400存储的包含对每一购票旅 客的信息的记录，包括：记录号码、旅客姓名、购票地址、票据信息、 诸如信用卡号码、所有区段的公司和航班号码、座位分配、存货等级、 飞机类型、航空公司发出的对折扣票价的授权代码、售出价格、及其 它注释。
如以下进一步所讨论的，一个或多个航空公司可能不是拒绝 CPO，而是发出对CPO的可约定的还价，对此顾客2110可以接受 或拒绝。如果还价向顾客2110发出，则带有任何相关限制的还价的 记录最好在CPO数据库2900中生成。例如，如果航空公司2120向 存储在CPO数据库2900的记录2905中的CPO号码23456发出还 价，则初始的CPO的状态变为“反对”，且对应于还价的进一步的记 录(未示出)可被存储在CPO数据库2900中指示还价的修改的CPO 号码下，诸如CPO号码23456-CO1。
图30示出示例性的航空公司规则安全数据库3000，该数据库最 好维护与特定的航空公司安全服务器2300相关的一个或多个航空公 司的CPO规则。如前面所指出，航空公司规则安全数据库3000可 以加密格式存储以维护包含在CPO规则中的高度敏感的信息的完整 性和保密性。航空公司规则安全数据库3000维护多个记录，诸如记 录3002和3004，每一记录与不同的CPO相关。对于每一由字段3010 中的规则号码标识的CPO规则，航空公司规则安全数据库3000在 字段3012到3044包含由各航空公司定义的相关限制。
根据本发明的特点，由CPO管理系统2300处理的CPO规则可 以有各种复杂性。在示例性的航空公司规则安全数据库3000中所述 的特定规则只是表示本发明的原理。对于一般的专业人员显然的是， 航空公司可以采纳这种限制的一个子集和/或采纳附加的限制。例如， 航空公司2120的CPO规则还可以采纳与旅程相关的最小夜晚数的 限制，或要求顾客2110星期六夜晚停留。
为了示例的目的，图30a中所示的航空公司规则安全数据库 3000，允许航空公司通过在字段3012到3044中规定以下限制的某些 或全部而生成CPO规则：出发和目标城市、连接条件、包含或排除 的航班号码、离开的日期和时间、星期几离开、返回的日期和时间、 星期几返回、旅行的旅客数、航行长度、每座位平均收益、每机票最 小票价、存量限制或座位可得性、及提前购买的要求。
例如，图30a所示的记录3002是与对给定的航空公司的CPO规 则相关的，该规则规定了航空公司将接受对从Newark，New Jersey(EWR)到Orlando，Florida(MCO)在1997年10月间的旅行的 任何CPO，假如(i)顾客是乘在星期二到星期四离开的任何航班旅行， (ii)机票在出发前21天内定座，(iii)每张机票价格至少为$165，(iv)K- 存量在顾客旅程的所有区段可得，以及(v)至少两(2)个旅客一同旅行。
类似地，图30a所示的记录3004与对给定航空公司的CPO规则 相关，该规则规定，航空公司将接受任何这样的CPO，即具有至少 $150的票价，在New York，NY(JFK)和Chicago，IL(ORD)之间在 1997年4月或5月期间两个或更多一同旅行的人，其中Q或K存量 在上午11点到下午2点可得，航班在星期二离开并在星期一到星期 四返回，并在旅行前7到21天之间定座，并能够途经该航空公司的 Cleveland，OH或Pittsburg，PA中心。
在另一或附加的实施例中，能够使用图30b和30c分别所示的一 对存量和定价数据库3050、3075实现航空公司规则安全数据库3000。 在这一实施例中，存储在存量数据库3050中的CPO规则包含航空 公司已经释放向CPO顾客销售的每一航班上的实际存量。存量数据 库3050维护多个记录，诸如记录3052-3056，每一与不同CPO规则 和航班相关。对于由字段3060中的规则号码标识的每一CPO规则， 存量数据库3050在字段3062到3066中包含航空公司、航班号码及 日期的指示。此外，在字段3068中指示可以由CPO管理系统2100 销售的每航班的座位数量。在一优选实施例中，在存量由CPO管理 系统2100销售时，记录在存量数据库3050中的可得存量将减量。
图30C所示的价格数据库3075维护诸如3080-3084的多个记录， 每一个与不同的起终点对相关。对于分别在字段3090和3092中标识 的起终点对，价格数据库3075分别在字段3088、3093和3096中包 含航空公司、日期和最低价格的指示。
这样，在这种替代的或附加的实施例中，在访问存量数据库3050 之前，CPO管理系统2100将最好查询CRS 2400以识别出满足顾客 旅程限制的可能的航班。然后，CPO管理系统2100将访问存量数据 库3050，以确定航空公司是否已经向CPO管理系统2100释放了这 种识别出的航班上的任何存量，供向CPO顾客销售。在一个实施例 中，从CRS 2400识别出的航班的列表能够被排序以优化顾客偏好， 并能够按航班排序的列表搜索存量数据库3050，直到识别出可得的 存量。最后，如果识别出任何满足顾客旅程的可得的存量，则CPO 管理系统2100将访问图30c所示的定价数据库3075，以确定由顾客 所规定的价格是否超出如定价数据库3075的字段3096中所载由航空 公司所确定的最小价格。
图31示出一示例性还价规则数据库3100，该数据库最好存储可 由CPO管理系统2100采用以产生对CPO的还价的一组允限，如果 CPO在与给定的CPO规则相关的一个或多个限制的预定允限之内。 还价规则数据库3100维护诸如3105和3110等多个记录，每一与不 同的CPO规则相关。对由字段3120中的规则号码标识的每一CPO 规则，还价规则数据库3100在字段3125到3140中包含关于离开和 返回日期和时间可接受的允限。此外，还价规则数据库3100在字段 3145到3155分别包含关于旅行的旅客数目、运输的长度和收益的允 限。最后，还价规则数据库3100在字段3160到3165分别记录有关 最小价格和提前购买要求的任何可行的允限。
如图31所示，还价规则数据库3100在记录3015中包含了对应 于来自图30a的CPO规则号码45687的还价规则号码45687。如图 31中所示，如果给定的CPO不满足CPO规则号码45687的一个或 多个限制，但是不被满足的限制是在还价规则数据库3100中所载的 预定允限之内，则CPO管理系统2100被授权代表与CPO规则号码 45687相关的航空公司2120产生一还价。例如，如果给定的CPO包 含顾客定义的价格$140.00，但是所有其它航空公司定义的CPO规 则号码45687的限制被满足，则按还价规则号码45687的授权，应当 产生一还价包含$150.00价格，因为价格变化在与CPO号码45687 相关的最小价格百分之十(10％)内。
图32示出一示例性航空公司审计安全数据库3200，该数据库最 好维护由CPO管理系统2100处理的对每一CPO的审计痕迹。航空 公司审计安全数据库3200维护诸如记录3205-3215等多个记录，每 一记录与已经由CPO管理系统2100处理的不同的CPO相关。对于 由字段3220中的CPO号码标识的每一CPO，航空公司审计数据库 3200在字段3225包含有关航空公司对该CPO的响应，并分别在字 段3230和3235中包含CPO的日期和时间。此外，如果一张票被顾 客2110在任何航空公司定座，则航空公司审计数据库3200最好在字 段3240存储与机票相关的旅客姓名记录(PNR)号码，并在字段3245 存储指示该机票是否在有关航空公司定座。在一优选实施例中，字段 3245的登录指出机票是否被定座(a)在与该数据库相关的有关航空公 司，(b)在另外的航空公司，或(c)如果完全没有机票发出。这样，CPO 管理系统，能够确定机票实际上已对由至少一个航空公司接受的每一 CPO被定座。
图33示出一示例性定价和限制数据库3300，该数据库维护对由 航空公司2120和2130提供的每一航班的定价信息和相关的限制，它 们由RMS 2500建立和更新。定价和限制数据库3300包含诸如记录 3305-3315等多个记录，每一与不同航班相关。对于由字段3335中 的航班号码标识的每一航班，定价和限制数据库3300在字段3330中 包含航班的日期，并在字段3335到2250中包含与每一存量相关的各 个价格和限制。
图34示出示一例性座位分配数据库3400，该数据库维护由航空 公司2120和2130提供的给定的航班上每一票价等级的存量信息，该 信息由RMS 2500分配和更新。此外，在存量由航空公司销售时，ARS 2150最好将记录在座位分配数据库3400中的存量减量。座位分配数 据库3400包含诸如记录3405-3420等多个记录，每一记录与不同的 航班相关。对于由字段3425中由航班号码标识的每一航班，座位分 配数据库3400在字段3430中包含航班离开的日期，并在字段3435 到3440包含每一存量等级中各可得存量。此外，座位分配数据库3400 在字段3445最好包含每一航班上被定座的座位总数的指示，并在字 段3450中包含航班上可得的总容量。
图35示出一示例性预测与需求分析数据库3500，该数据库记录 对给定航班每一票价等级的每一销售价，并记录对由RMS 2500建立 的每一销售价的预测需求。如前所指出，当航班第一次添加到航空公 司2120的航班时刻表时，对每一票价等级的初始价格及预测需求最 好在预测与需求分析数据库3500中生成。此外，最好对由RMS 2500 对每一票价等级建立的每一新的销售价生成新的记录。
预测与需求分析数据库3500包含诸如记录3505-3525等多个记 录，每一记录与对给定航班上给定票价等级的不同销售价相关。对于 字段3530中标识的每一航班号码，预测与需求分析数据库3500分别 在字段3535到3545包含离开日期、及起始和目标城市，并分别在字 段3550和3555分别包含对应的提供的价格和票价等级。最后，预测 与需求分析数据库3500在字段3560最好记录对于每一票价等级按每 一提供的价格由航空公司销售的机票实际量，并在字段3565记录对 应的预测量。售的机票的实际量可以按机票被实际销售或借助于基于 周期的批处理而实时记录在字段3560中。
处理过程
如以上所讨论，CPO管理中央服务器2200最好执行图36a到图 36c所示的CPO管理过程3600，以便接收来自顾客2110的每一CPO， 并把CPO与每一航空公司的规则对比，以便确定代表航空公司或接 受、或拒绝或讨价该CPO。如图36a中所示，当顾客或旅行社代理 访问CPO管理系统2100时，CPO管理过程3600在步骤3604期间 开始实施本发明原理的过程。
然后，在步骤3608期间，CPO管理中央服务器2200将接收来 自顾客2110的顾客信息、旅程、价格和其它限制，如果对于新的顾 客需要，则要求把它们录入顾客数据库2600，及CPO数据库2900。 最好在步骤3612期间以收到的信息在CPO数据库中生成CPO记录， 并设置状态字段为“待定”。
在步骤3616期间最好向顾客2110显示或读出适当的法律用语， 且CPO管理系统2100将等待来自顾客2110的认可以形成可约定的 有条件购买要约(CPO)。在步骤3620期间，从CPO数据库2900的 字段2980抽取价格，并从顾客数据库2600抽取包含信用卡号码的适 当的顾客信息。然后在对于授权前的步骤3624期间，向信用卡发放 者传输与适当的开单描述符一起与CPO管理系统2100相关的商业 ID，总购买量(最好等于由顾客2110规定的价格)及信用卡信息。
然后在步骤3628期间适当地执行测试，以确定授权代码是否已 从信用卡发放者收到。如果在步骤3628期间确定信用卡发放者没有 授权购买量，则在步骤3632期间最好从顾客2110请求另一信用卡， 且程序控制返回到步骤3624继续按以上所述的方式处理。
然而如果在步骤3628期间确定信用卡发放者已经授权购买量， 则在步骤3636期间接受CPO供处理，且程序控制继续到步骤3640(图 36b)。在步骤3640期间，对每一航空公司CPO管理过程3600最好 执行以下结合图37所讨论的评估过程3700。在步骤3612期间所生 成的CPO记录传送给评估过程3700供与诸如航空公司2120的一个 航空公司的CPO规则对比，以便为该航空公司产生对给定的CPO 的响应。如前所指出的，航空公司对CPO的响应可以是接受、拒绝 或讨价该CPO。如以下进一步所讨论，如果CPO被航空公司接受或 讨价，则评估过程3700将返回航空公司对CPO的响应以及航班号 码。
在另一实施例中，评估过程3700能够对每一航空公司按预定的 顺序执行，直到一个航空公司接受该CPO。录入，评估过程能够基 于以下执行(i)由每一航空公司形成的可供向CPO顾客销售的存量，(ii) 在航空公司数据库3700中记录的每一航空公司的CPO承诺率，(iii) 由每一航空公司协商的优先权，诸如航空公司对一定路线的优先权， (iv)由航空公司向CPO管理系统2100支付的最高代理费率。这样， 能够由航空公司积极参与的因素，和/或对CPO管理系统2100优化 收益的因素确定排序。要注意，在优选的实施例中，如果CPO由航 空公司接受，不论航空公司愿意接受的最小价格如何，或CPO管理 系统2100是否使用了排序准则处理CPO，则顾客2110将支付由顾 客定义的价格。
如图36b所示，在步骤3644期间最好进行一测试以确定CPO是 否已经被至少一个航空公司接受。如果在步骤3644期间确定CPO 被至少一个航空公司接受，那么在步骤3648期间进行进一步的测试 以确定CPO是否被多于一个航空公司接受。如果在步骤3648期间 确定CPO没有被多于一个航空公司接受，那么程序控制直接进到步 骤3672(图36c)以便对机票定座。
然而如果在步骤3648期间确定CPO被多于一个航空公司接受， 那么在步骤3652期间最好执行打破僵局算法以确定要使用哪一个航 空公司的承诺。例如，打破僵局算法能够选择这样的一个航空公司， 它提供对顾客2110最大方便的旅程，使对CPO管理系统利润最大， 或通过CPO管理系统2100使可供销售的存量最优化。要注意，在 另一实施例中，其中对每一航空公司以预定的顺序执行评估过程 3700，直到一个航空公司接受该CPO，这将不需要打破僵局算法。 在又一实施例，顾客2110可以为自己选择采用哪一个航空公司的承 诺。然后，程序控制进到步骤3672(图36c)对机票定座。
为了对机票定座，从顾客数据库2600、CPO数据库2900及从评 估过程3700或CRS 2400收到的存量和航班信息抽取生成顾客姓名 记录(PNR)所需的信息。如前面所指出的，PNR一般包括以下参数： 记录号码、顾客姓名、购票地址、诸如信用卡号码等开单信息、所有 区段的航班号码、公司名、飞机座位分配、舱位等级、飞机类型、航 空公司发出的对折扣票价的授权代码、销售价格、及其它注释。
然后在步骤3674期间，PNR传输给对其定票的航空公司的航空 公司保留系统2150或CRS 2400以建立保留。然后在步骤3678期间， CPO管理过程3600将把与CPO管理系统2100相关的商业ID，连 同适当开单描述符、总购买量(最好等于由顾客2110规定的价格)及 信用卡信息传输给信用卡发放者用于支付。
在步骤3682期间以指定的PNR号码更新CPO数据库2900中的 CPO记录，且状态字段变为“已接受”。最后，在步骤3686期间由 CPO管理过程3600对每一航空公司执行以下结合图38讨论的审计 过程3800，以便对由CPO管理系统2100处理的每一CPO保存一审 计痕迹。如前所指出的，审计过程3800将在航空公司审计安全数据 库3200中生成一条目，它能够用来对每一由至少一个航空公司接受 的CPO确定机票实际上被CPO管理系统2100定座。
然而如果在步骤3644(图36b)期间确定，CPO没有被至少一个航 空公司接受，则在步骤3656期间进行进一步的测试以确定是否有至 少一个航空公司对CPO提供了还价。如果在步骤3656期确定间有 至少一个航空公司对CPO提供了还价，则初始的CPO的状态变为 “讨价”，并在步骤3660期间最好在CPO数据库2900中生成该还价 的一个记录，例如使用带着“-CO”扩充的原来的CPO号码。然后， 在步骤3664期间还价被传输给顾客2110。在另一实施例中，如果CPO 在预定的允限内，则顾客2110不是收到一个或多个还价，而是能够 被指令稍后时间重新提交CPO，或CPO管理系统2100能够周期地 重新执行该CPO，直到该CPO被接受，或直到CPO过期。要注意， 就CPO规则的动态性质来看，起初被拒绝的CPO可能后来被一个 或多个航空公司接受。
然后在步骤3668期间最好进行一测试，以确定顾客2110是否接 受了还价之一。如果在步骤3668期间确定了顾客2110接受了一还价， 则程序新控制进到步骤3672(图36c)以便按上述方式对机票定座。然 而如果在步骤3668期间确定了顾客2110没有接受还价，则程序新控 制进到步骤3696(图36c)，其中CPO管理系统3600将把顾客对还价 的拒绝传输到作出该还价的航空公司。然后在步骤3698期间，CPO 管理系统3600将把同CPO数据库2900中的该CPO相关的还价的 状态更新为“拒绝”。程序控制按以上所述的方式进到步骤3686，并 然后在步骤3699期间终止。
然而如果在步骤3656期间(图36b)确定没有航空公司提供对该 CPO的还价，则程序控制进到步骤3690(图36c)，其中CPO管理系 统将把该CPO的拒绝传输到顾客2110。然后，在步骤3694期间CPO 数据库2900中该CPO的状态被更新为“被拒绝”。程序控制按以上 所述的方式进到步骤3686，并然后在步骤3699期间终止。
如上所讨论，CPO管理过程3600在步骤3640期间执行评估过 程3700。一个示例性的评估过程3700示于图37a和37b。在一个实 施例中，评估过程最好对每一航空公司定制，使得每一评估过程3700 从CPO管理过程3600以标准格式接收CPO记录，用于与相关航空 公司诸如航空公司2120的规则对比，并返回航空公司对CPO的标 准响应，诸如接受、拒绝或讨价。此外，如果航空公司的响应是接受 或讨价CPO，则评估过程3700最好还返回选择的航班号码。
如图37a所示，评估过程3700起始在步骤3705期间从CPO记 录抽取起终点对，并然后在步骤3701期间识别属于所抽取的起终点 对的航空公司规则安全数据库3000中的所有CPO规则。在步骤3715 期间，对于前一步骤期间识别的每一CPO规则，把顾客定义的CPO 记录中从字段2960到2995的限制与对应的航空公司定义的航空公司 规则安全数据库3000中的从字段3016到3044限制进行比较。
然后，在步骤3720期间进行测试以确定CPO是否满足至少一个 航空公司的规则。例如，存储在CPO数据库2900的记录2910中的 CPO号码23452(图29a和29b)定义了New York(JFK)到Chicago(ORD) 的起终点对。这样，评估过程3700将访问航空公司规则安全数据库 3000并识别对该起终点对的所有CPO规则。在图30a所示的示例性 航空公司规则安全数据库3000中，CPO规则号码23452被识别为属 于这一起终点对的唯一规则。然后，把顾客定义的CPO号码23452 中的从字段2960到2995的限制的每一个与对应的CPO规则号码 23452中的航空公司定义的从字段3016到3044的限制进行比较。由 于顾客愿意停留一次(字段2960)，故途经Cleveland或Pittsburg路 线的航空公司的要求(字段3016)能够被满足。此外，顾客离开和返回 的日期要求(字段2965和2970)满足航空公司对旅程离开和返回两者 的日期、时间和周天要求(字段3020到3032)。此外，旅行的旅客数 目满足在字段3034中提出的航空公司要求，且顾客的价格(字段2980) 超过航空公司定义的最小价格(字段3040)。这样，CPO号码23452 将被与CPO规则号码45687相关的航空公司接受，假如Q或K存 量可得(字段3042)，且该CPO在起飞前7到21天之间正在被处理(字 段3044)。
在一个实施例中，在CPO管理系统2100定义满足如CPO规则 中提出的航空公司要求的可得存量，及CPO本身中提出的要求的条 件下，CPO管理系统2100允许航空公司2120以接受给定的CPO的 格式规定CPO规则。例如，图30a所示的CPO规则号码23452是 以Q或K存量可得为条件的。
这样，如果在步骤3720确定CPO满足至少一个航空公司的规则， 则最好在步骤3725期间进行进一步的测试以确定任何被满足的规则 是否以可得的存量为条件。
如果在步骤3725期间确定任何被满足的规则都不以可得的存量 为条件，则程序控制直接进到以下讨论的步骤3735。然而如果在步 骤3725期间确定一个或多个被满足的规则以可得的存量为条件，则 在步骤3730期间访问CRS或ARS以识别出具有可得座位并满足被 满足的CPO规则和CPO两者的适当限制的航班，如果有这样的航 班。
然后在步骤3735期间进行测试以确定，是否有多于一个满足该 CPO的航班已经被识别。如果在步骤3735期间确定了只有一个满意 的航班已经被识别，则程序控制直接进到以下讨论的步骤3745(图 37b)。
然而如果在步骤3735期间确定多于一个满足该CPO的航班已经 被识别，则在步骤3740期间选择一个最密切匹配CPO中提出的顾 客偏好或对顾客最方便的航班(图37b)。另外，各个航空公司2120能 够定义其自身的准则使CPO管理系统2100用来选择单一的航班。 然后在步骤3745期间响应将被设置为“接受”，且在步骤3770期间 程序控制将以定义的响应和选择的航班号码返回CPO管理过程 3600。
然而如果在步骤3720期间(图37a)确定CPO不是满足至少一个 航空公司的规则，则程序控制进到步骤3750(图37b)，其中进行进一 步的测试以确定CPO是否在航空公司规定的允限内，以便产生一还 价。如前所指出，如果CPO在与给定的CPO规则相关的一个或多 个限制的预定允限内，则最好由每一航空公司安全服务器2300存储 还价规则数据库3100，以保持能够由CPO管理系统2100使用的一 组允限，以代表航空公司产生对CPO的还价。
这样，如果在步骤3750期间确定CPO在由航空公司规定用于产 生还价的允限之内，则在步骤3760期间产生一带有从还价规则数据 库3100检索的适当修改条款的还价。然后，在步骤3765期间响应将 被设置为“讨价”，且在步骤3770期间程序控制将以定义的响应和选 择的航班号码返回CPO管理过程3600。
然而如果在步骤3750期间确定CPO不在由航空公司规定用于产 生还价的允限之内，则在步骤3755期间响应将被设置为“拒绝”，且 在步骤3770期间程序控制将以定义的响应和选择的等于零的航班号 码返回CPO管理过程3600。
如前所指出的，在步骤3686期间CPO管理过程3600最好对每 一航空公司执行审计过程3800，以便对每一由CPO管理系统处理过 的CPO保存一审计痕迹。一示例性的审计过程3800示于图38。审 计过程3800将最好在航空公司审计安全数据库3200生成一项，它能 够由CPO管理系统2100使用，以确定一机票实际上由CPO管理系 统2100对至少由一个航空公司接受的每一CPO定座。这样，对于 航空公司2120能够确保，使得利用CPO管理系统2100的顾客2110、 另一航空公司2130或第三方获得航空公司2120的底价灵活性的危险 最小。
如图38所示，在步骤3810期间如果必要，审计过程3800将最 初对航空公司规则安全数据库中的存量减量。例如，只是在机票最终 由相关航空公司定座，且，与以现在可得存量为条件的CPO规则不 同，用来接受CPO的CPO规则实际包含由航空公司为对CPO顾客 销售而释放的存量，则存量应当被减量。
然后在步骤3815期间，审计过程3800最好在航空公司审计安全 数据库3200中生成CPO的一个记录，包括CPO号码、如果有机票 则与由CPO管理系统2100对顾客2110发出的机票相关的PNR、及 如果有机票则它是否在对应的航空公司定座的指示。在步骤3820期 间，程序控制将返回到CPO管理过程3600。
当航班第一次添加到航班时刻表中时，最好由RMS 2500执行图 39所示的示例性CPO规则产生过程3900，并然后响应需求和外部 活动对可得的存量周期地重新分配和定价。这样，在步骤3905期间 初始进行测试以确定由RMS 2500进行的当前存量分配是否为对正在 被分配的航班的初始分配。如果在步骤3905期间确定当前的存量分 配是正在被分配的航班的初始分配，则在步骤3910期间进行进一步 的测试，以确定使用通常的方法是否预测到航班可能带有空位离开。
如果在步骤3910期间确定航班不会带空位离开，则程序控制将 在步骤3985期间终止。然而如果在步骤3910期间确定航班可能带空 位离开，则在步骤3915期间CPO规则产生过程3900最好将把空位 分配到用于CPO顾客的特价等级。然后在步骤3920期间确定对这 种机票适当的最小票价和其它限制。
在步骤3925期间以新确定的票价等级、分配的存量和初始价格 对该航班把定价和限制数据库3300、座位分配数据库3400、及预测 和需求分析数据库3500进行更新。然后在步骤3930期间，CPO规 则产生过程3900最好将产生包含被分配的存量、所确定的最小价格 和其它限制的CPO规则，并然后在步骤3935期间把产生的CPO规 则传输到相关的航空公司安全服务器2300。然后程序控制将在步骤 3985期间终止。
然而如果在步骤3905期间确定，当前存量分配不是对正在被分 配的该航班的初始分配，则程序控制进到步骤3950，以便对于给定 航班的一个或多个票价等级重新分配以前的分配，使不能预料的过剩 存量增量2580最小化。这样在步骤3950期间进行测试，以确定，对 任何票价等级预测的需求是否超过实际的需求达预定的允限以上。在 一个实施例中，RMS使用记录在预测和需求分析数据库3500的字段 3560和3565中的汇总信息，能够作出这一决定。此外，RMS 2500 通过分析对以前时段存储在预测和需求分析数据库3500的历史需求 信息，能够产生在步骤3950中使用的预定允限。
如果在步骤3950期间确定，对任何票价等级预测的需求没有超 过实际的需求达预定的允限以上，则没有必要重新分配现有的分配， 且程序控制将在步骤3985期间终止。要注意，如果实际需求超过预 测需求，则RMS 2500能够除去以前分配供对CPO销售的存量。
然而如果在步骤3950期间确定，对任何票价等级预测的需求超 过实际的需求达预定的允限以上，则在步骤3955期间RMS 2500将 最好分配过剩的容量，或其部分，供对CPO顾客销售。然后，将在 步骤3960期间确定对这种机票适当的最小票价和其它限制。
在步骤3965期间对该航班将以重新分配的存量和所确定的价格 更新定价和限制数据库3300、座位分配数据库3400、及预测和需求 分析数据库3500。然后，在步骤3970期间CPO规则产生过程3900 将产生包含分配的存量、所确定的最小价格和其它限制的CPO规则， 并然后在步骤3980期间把产生的CPO规则传输到相关的航空公司 安全服务器2300。然后程序控制将在步骤3985期间终止。
巡游的实现
虽然这里CPO管理系统2100已经主要作为用于销售航空公司机 票的系统说明，但是对一般专业人员明显地是，该CPO管理系统2100 也能够用来销售巡游票。在这种实施例中，与航空公司的情形不同， 每一航空公司安全服务器2300将与一个或多个巡游经营者相关，且 每一安全服务器2300除了其它之外，以与上述在航空公司实现中所 述的安全服务器2300类似方式，存储由任何巡游经营者定义的CPO 规则。
此外，收益管理系统2500和航空公司保留系统2150将分别作为 每一巡游经营者的收益管理系统和保留系统实施。以类似于上述航空 公司实现中所述的收益管理系统方式，巡游收益管理系统确定定价和 存量信息，并产生CPO规则。类似地，以类似于上述航空公司实现 中所述的保留系统方式，巡游保留系统对各巡游经营者进行旅程询问 并作出保留。
这样，CPO管理系统2100从潜在的巡游旅行者接收CPO，并 对比由多个巡游经营者的每一个提供的一组CPO规则评估该CPO。 对于巡游实现的示例性CPO数据库4000示于图40a和40b。CPO 数据库4000最好存储由CPO管理系统2100正在处理的每一CPO 的记录，包括CPO条款和相关状态。CPO数据库4000保存诸如记 录4005和4010多个记录。每一记录与正在由CPO系统2100处理 的不同CPO相关。对于每一由字段4020中的CPO号码标识的CPO， CPO数据库4000在字段4025中包含CPO收到的日期，并如果有则 在字段4030包含与CPO相关的旅行社代理的标识(ID)号码。要注意， 存储在字段4030中的旅行社代理ID号码例如可被用来索引对与该 旅行社代理相关的以前的购票和CPO的数据库(未示出)。
此外，CPO数据库4000在字段4035按姓名并在字段4040按标 识号码标识顾客。任何同行的顾客在字段4045中标识。存储在字段 4040中的ID号码最好用来交叉参照对顾客存储在顾客数据库2600 中的对应的信息。
顾客的旅程和其它有关的限制的参数存储在CPO数据库4000的 字段4050到4085。具体来说，出发和目标港口分别在字段4050和4055 中标识，并且由顾客2110规定的任何港口限制记录在字段4060。离 开和返回日期分别存储在字段4065和4070。
CPO数据库4000最好在字段4075存储一同旅行的顾客总数， 并在字段4080记录顾客愿意支付的每张票的价格。任何由顾客规定 的其它杂项限制，诸如希望的巡游经营者、舱位、船舱分配或就餐时 间等将记录在字段4085中。字段4090记录各CPO当前状态，诸如 待定、接受、拒绝或过期。
对于巡游实现的示例性规则安全数据库4100示于图41，用于维 护与各安全服务器2300相关的一个或多个巡游经营者的CPO规则。 规则安全数据库4100可以按加密格式存储以维护包含在CPO规则 中的高度敏感信息的完整性和保密性。规则安全数据库4100保持多 个记录，诸如记录4102和4104，每一与不同的CPO规则相关。对 于由字段4110中规则号码标识的每一CPO规则，规则安全数据库 4100在字段4112到4144包含由各巡游经营者定义的相关限制。
根据本发明的特点，由CPO管理系统2100处理的CPO规则可 能有各种复杂性。在示例性的规则安全数据库4100所述的特定规则 只是表示本发明的原理。对于一般的专业人员明显的是，巡游经营者、 航空公司或其它卖方可以采纳这种限制的一个子集和/或采纳另外的 限制。
为了示例的目的，图41中所示的规则安全数据库4100允许巡游 经营者通过在字段4112到4144规定以下的限制的部分或全部而生成 CPO规则：始发港口、航班号码(包含或排除)、离开的日期和时间、 离开的周天、返回的日期和时间、返回的周天、旅行的旅客数、航行 长度、每舱位平均收益、每张票最小价格、存量限制或舱位可得性、 及提前购买要求。
例如，图41所示的记录4102是与对给定的巡游经营者的CPO 规则相关的，该规则规定了巡游经营者将接受对从St.Thoms在1997 年10月间的旅行的任何CPO，假如(i)顾客是乘在星期二到星期四离 开和返回的任何游船旅行，(ii)船票在出发前两个(2)月内定座，(iii)每 舱位每英里收益至少为$1.20且每人价格至少为$529，(iv)不是对豪华 级旅游，以及(v)至少两(2)个旅客一同旅行。
对于多个约定的公告销售
如以上所讨论，如果CPO被多于一个以上的航空公司或巡游经 营者接受，则最好在步骤3652期间由CPO管理过程3600执行打破 僵局算法，以便确定使用哪一个航空公司的承诺。例如，打破僵局算 法能够选择卖方它提供这样的旅程，即使得对顾客2110最方便、使 对CPO管理系统2100利润最大化、优化供通过CPO管理系统2100 销售的可得存量，或允许顾客2110为其自己选择采用哪一个航空公 司或巡游经营者的承诺。在另一种实现中，如果CPO由多于一个巡 游经营者接受，则CPO管理系统2100执行图42中所示的公告销售 多约定过程4200，以便允许每一接受的卖方直接向顾客2110出售并 公告销售其产品。这样，顾客2110仍然基于由每一卖方提供的材料 或刺激性为自己选择采用哪一个巡游经营者的承诺。顾客2110仍然 由CPO管理系统2100根据CPO的条款约定。换言之，顾客2110 有责任购买由CPO规定的货物或服务，但是基于由每一接受的巡游 经营者向顾客2110直接提供的材料，买方必须决定采用哪一个巡游 经营者。
例如，顾客2110可能提交一CPO，用于1998年3月份的巡游， 在维尔京群岛任何地方，A等舱带晚餐，出价$800.00。该CPO向多 个巡游经营者提供。三个巡游经营者接受了该CPO。然后CPO管理 系统2100根据CPO的限制约定顾客2110到以该要约识别的信用卡 帐户上。然后CPO管理系统2100提供在顾客2110与接受的卖方之 间通信的渠道，或者向试图以有吸引力的方式销售其产品的每一接受 的巡游经营者提供顾客接触的信息。然后顾客2110选择三个接受的 卖方之一。这样，每一个巡游经营者知道以CPO规定的价格他们有 三分之一销售巡游的机会。预计巡游经营者将会很主动地向这种有保 证的买方销售，特别是就与每一巡游旅行者相关的高边际利润而言。
要注意，顾客2110与每一接受的卖方之间由CPO提供的通信渠 道可以是交互式的web站点或其它电子机制，这使得每一接受的卖 方能够向顾客2110提供有关他们试图销售的巡游的详细信息。例如， 交互式web站点可能包含巡游组合的不同方面的虚拟表示，诸如实 际的巡游船和船舱，以及巡游将访问的各港口和可能的活动。这样， 买方能够使用已知的技术考察虚拟的巡游表示。
图42表示一示例性的公告销售多约定过程4200，该过程可以由 图22的CPO管理中央服务器实现，以允许每一接受的卖方直接向 顾客2110销售，以试图公告销售其产品。在打破僵局算法的情形下， 公告销售多约定过程4200最好在步骤3652期间由CPO管理过程3600 执行，以确定采用哪一个巡游经营者的承诺。如图42中所示，在步 骤4210期间，通过指令接受的巡游经营者或其它卖方为指定的顾客 2110提供公告销售信息，公告销售多约定过程4200开始。然后CPO 管理系统2100最好在步骤4220期间从接受的经营者那里接收公告销 售信息，并在步骤4230期间向顾客2110传输接受的信息，或以另外 的方式使之可得。最后，在步骤4250期间程序控制返回CPO管理 过程3600之前，公告销售多约定过程4200接收顾客2110关于采用 哪一个经营者的决定。
在另一实现中，如果CPO由多于一个巡游经营者接受，则CPO 管理系统2100能够把每一接受的卖方约定到一个CPO。根据打破僵 局算法或这里所公开的公告销售多约定过程4200，能够向最初的买 方分配卖方之一。这样，然后CPO管理系统2100能够向其它买方 按与初始接受的CPO相关的价格或高于该价格再次销售存量。
被排除的卖方CPO评估
如前面所指出，由顾客2110提交的CPO能够规定一个或多个可 用的航空公司、巡游经营者或其它卖方。这样，CPO管理系统2100 将向每一规定的卖方提供CPO，以确定卖方的一个或多个是否愿意 接受该CPO。在一补充的实施例中，CPO管理系统2100最好执行 以下结合图44a和44b讨论的排除的卖方CPO评估过程4400，以便 向被排除的卖方提供CPO，这些卖方在规定的卖方之一接受该CPO 之前可以对顾客2110作出还价。被排除的卖方可以作出比顾客2110 规定的CPO的最初条款更为有利的还价，以图获得该业务。这样， CPO管理系统2100能够向被排除的卖方销售接收CPO信息的权利， 或者对任何由顾客2110接受的还价收取较大百分比的代理费。
例如，在巡游业中，首次的旅游者倾向于开发一种特别的商标忠 诚性。这样，当考虑未来的巡游时，这种顾客2110可能向很有限数 目的巡游经营者提交CPO。CPO管理系统2100将根据CPO的条款 向规定的巡游经营者提交CPO，并还向一个或多个被排除的巡游经 营者提交CPO。在CPO由顾客规定的经营者之一接受之前，CPO 管理系统2100最好使用图43所示的被排除的经营者还价数据库 4300，以保持从被排除的经营者收到任何还价。
对于巡游实现示例性被排除的经营者还价数据库4300示于图 43。被排除的经营者还价数据库4300保持多个记录，诸如记录4305 到4315，每一记录与从被排除的经营者收到的不同的还价相关。对 于由字段4325中的号码标识的每一还价，被排除的经营者还价数据 库4300在字段4330到4350分别包含对应的CPO号码、顾客标识 符、被排除的经营者、还价的条款、及相关的状态。例如，如果顾客 的CPO起初规定，该要约要提交给Holland AmericaLine或Seaborn Cruise Lines，则CPO管理系统2100可能首先把该要约提交给 Carnival.Princess和Royal Caribean Cruise Lines。如图43所示，每 一被排除的经营者分别提交$600、$600和$575的还价。如果由顾客 CPO起初规定的经营者还没有被接受，则向顾客2110提供接受还价 之一的选择。如果顾客2110接受一个还价，则顾客2110被约定到还 价的条款，并删除原来的CPO。
图44a和44b描述了一示例性的排除的卖方CPO评估过程4400。 这一过程4400可以由图22的CPO管理中央服务器实现，以向被起 初的要约条款排除的卖方提供CPO信息。这时在由CPO的条款规 定的卖方之一接受该CPO之前，这些排除的卖方能够试图获得该业 务。如以下所讨论，排除的卖方CPO评估过程4400最好结合CPO 管理过程3600执行。如图44a中所示，在步骤4405期间，在接受来 自顾客2110的CPO并在CPO数据库2900和4000中存储该CPO 时，排除的卖方CPO评估过程4400开始。然后，在步骤4410期间， 对CPO进行评估以检索由顾客2110规定的任何经营者。在步骤4415 期间访问经营者数据库，以识别能够向其提供CPO信息的潜在的经 营者。
然后在步骤4420期间进行一测试，以确定是否有从CPO的条款 被排除的一个或多个经营者。如果在步骤4420期间确定没有经营者 从顾客的CPO被排除，则CPO管理过程3600继续如上所述操作。 然而如果在步骤4420期间确定有一个或多个经营者从顾客的CPO 被排除，则在步骤4430期间最好向每一被规定并被排除的经营者传 输CPO信息。要注意，能够在规定的经营者之前或同时，向被排除 的经营者提供CPO。
然后在步骤4435期间，从被排除的经营者接收任何还价，并在 步骤4440期间存储在排除的经营者还价数据库4300中。然后在步骤 4445期间把每一收到还价提供给顾客2110。然后在步骤4450期间进 行一测试，以确定在起初的CPO由任何规定的经营者接受之前，顾 客2110是否接受任何还价。如果在步骤4450期间确定在起初的CPO 由任何规定的经营者接受之前，顾客2110不接受任何还价，则CPO 管理过程3600继续如上所述操作。
然而如果在步骤4450期间确定，在原来的CPO由任何规定的经 营者接受之前，顾客2110已经接受了一个还价，则原来的CPO终止 或被删除，且在步骤4460期间CPO数据库2900中原来的CPO状 态4000变为“删除”。然后，被接受的还价的状态变为“接受”，并 且如果有被拒绝的还价，则在步骤4465期间在排除的经营者还价数 据库4300中其状态变为“拒绝”。最后，程序控制返回CPO管理过 程3600并按以上所述方式继续进行。
虽然对公告销售多约定过程4200和排除的卖方CPO评估过程 4400在此已经就巡游实施例进行了说明，要注意，对于一般专业人 员显然，公告销售多约定过程4200和排除的卖方CPO评估过程4400 在其它行业中也可使用，包括航空公司和其它与旅行相关的行业，长 途电话业和金融业。
组合CPO管理系统
以下结合图45到57讨论适于处理货物和服务组合销售的本发明 的又一实施例。图45表示对于货物和服务的组合使用买方接口4800 用于从一个或多个买方接收和处理CPO的有条件购买要约(CPO)管 理系统。在一个实施例中，组合CPO管理系统4500把整个组合的CPO 分解或解体为分别向卖方提供的成分CPO。组合CPO管理系统4500 处理与每一组合CPO相关的各成分CPO，以便使用卖方接口4801- 4806确定一个或多个卖方是否愿意接受给定的组合CPO的各成分的 每一个。如以下所讨论，如果给定CPO的各成分CPO的每一个由 一个或多个卖方接受，则组合CPO管理系统4500代表各个接受的 卖方约定买方，购买整个组合。这样，就形成合法的有约束力的合同。
这里如通常那样，组合CPO是包含由买方对于按买方定义的价 格购买成分的货物或服务或两者的组合，诸如航空旅行、旅馆和汽车 租用，而提交的一个或多个条件的捆绑要约。在一示例性旅行实施例 中，对CPO买方定义的条件一般将包括总价格和旅程参数，诸如出 发和目标城市；可接受的旅行日期和时间；以及对每一成分所需要的 服务等级。此外，买方可以对整个的组合CPO的一个或多个各成分 有选择地提供更为详细的规格，诸如对于旅行相关的组合CPO的航 空公司部分买方是否接受转机或中途停留，或者对于一个或多个各成 分货物或服务所希望的提供者。
根据本发明的一个特点，组合CPO管理系统4500最好把整个组 合CPO分解为分别向卖方提供的成分CPO。在另一实施例中，组合 CPO管理系统4500向每一卖方提供整个的CPO，使卖方能够分别 接受组合CPO的各成分。要注意，组合CPO的各成分可以是对相 同产品的。例如，买方能够对六(6)个一般的体育运动活动门票提交 购买要约。组合CPO管理系统4500能够对可能由一个卖方接受的 六张票作为一个整体的CPO向卖方提供购买要约。另外，组合CPO 管理系统4500能够把六张票的整个组合CPO分解为数个分别提供 给卖方的一张或多张票的成分CPO。在一个实施例中，大批量货物 的整体的组合CPO能够被分解为优化成最可能被接受的单位的成分 CPO。在以上票的例子中，组合CPO管理相同4500能够把对六张 票的请求分解为每个为两张票的三个成分CPO，假设大多数卖方倾 向于销售成对的票。
在一优选实施例中，组合CPO管理系统4500在对每一成分CPO 计算要约价格之前，从要约总价格留出一保证金。所保留的保证金量 可以基于整个组合的所有成分将被约定的似然率确定。这样，保证金 缓和了由于未能约定组合CPO的所有成分结果组合CPO管理系统 4500遇到的风险。
如以下结合图56进一步所讨论的，组合CPO管理系统4500能 够使用保留的保证金或其部分增加仍然没有由卖方接受的一个或多个 成分CPO的要约价格。例如，如果买方要以总价不超过一千美元 ($1,000.00)对一假期组合提交一要约，组合CPO管理系统4500可以 保留一百美元的保证金($100)，或百分之十(10％)，以便如果所需的 组合成分不能以从起初的$900分配的要约价格被约定时使用。然而 如果组合CPO管理系统4500在以起初分配的$900约定整个组合时 成功，则组合CPO管理系统4500能够保留$100保证金作为利润， 把该保证金返还买方，或把未使用的保证金放到某基金中以帮助约定 其它组合CPO的成分CPO。
为了对每一成分CPO计算要约价格，组合CPO管理系统4500 起初最好基于组合中的每一货物或服务的市场价格，确定组合的整体 市场价格。然后组合CPO管理系统4500基于由买方对整个组合要 约的总价格，按由保留的保证金调节，如果适用，则乘以各成分CPO 的市场价格对组合的总市场价格的比值，这样对每一成分CPO计算 要约价格。例如，如果买方对由航空旅行、旅馆设施、和汽车租用组 成的旅行组合提交一要约，以该组合总价格不超过一千美元 ($1,000.00)，且每一成分条款的市场价格分别为$420、$400和$250， 该组合的总市场价格为$1070。如果先由组合CPO管理系统4500保 留$100的保证金，则$900被调节的组合CPO价格将基于市场价格 分配给各成分CPO如下：$360(40％)用于航空公司机票，$333(37％) 用于旅馆设施，且$207(23％)用于汽车租用。
然后组合CPO管理系统4500处理各成分CPO，以确定是否一 个或多个卖方愿意接受整个的组合CPO的各成分CPO的每一个。 如果成功，则组合CPO管理系统4500代表每一接受的卖方约定买 方，以便购买整个的组合。如以下进一步的讨论，在每一成分CPO 被卖方接受时，组合CPO管理系统4500最好与卖方订立一“预预 定”协议，从而该成分的货物或服务被保留预定的时间段，以允许组 合CPO管理系统4500完成其余现有成分CPO的处理。接受成分CPO 的卖方可以允许组合CPO管理系统4500例如两周的时间段，在此 期间组合CPO管理系统4500必须完成该组合。要注意，这种限定 的预定“预约定”时间段保护了卖方避免保留后来不能售出的产品。
在另一实施例中，组合CPO管理系统4500能够与选择接受成分 CPO的每一卖方订立约定协议。在这一实现中，如果组合的部分被 约定，而其它部分没有在限期时间内约定，则组合CPO管理系统4500 能够为差额提供资金以市场价格或接近市场价格完成未接受的组合成 分。在又一的实施例中，组合CPO管理系统4500能够基于组合的 每一成分将约定的似然率以特定的串行顺序向卖方提供成分CPO。
此外，最好能够保证卖方，在通过对初始的预约定加密获得的预 预约定之后，不能继续向卖方的竞争者购买已被接受的成分CPO。 例如，预约定了给定的成分CPO的卖方能够在向组合CPO管理系 统100传输他们的承诺之前，对他们的标识字符加密，使得组合CPO 管理系统4500能够识别诸如航空公司等卖方的行业，及接受要约的 授权，但是直到整个的组合完成之前不能识别卖方特定标识。
虽然这里作为用于处理旅行相关的组合CPO解释了组合CPO 管理系统4500，但是对于一般专业人员显然，组合CPO管理系统4500 能够用来处理货物或服务或两者的任何成分的组合，诸如汽车和相关 的保险，计算机和相关的外围设备，或批量货物。
组合CPO管理系统
如图45所示，组合CPO管理系统4500最好包含中央控制器4600 和一个或多个安全服务器4700，用于与一个或多个买方或卖方接口 4800-4806通信。如图45所示，组合CPO管理系统4500可基于与 成分CPO相关的行业或其它预定的审查准则向被选择的卖方提供给 定的成分CPO，使得卖方只能获得他们可能有兴趣或被授权审查的 成分CPO。另外，组合CPO管理系统可以向供审查的所有卖方提供 所有的成分CPO。
根据本发明的一个特点，组合CPO管理系统4500最好提供可选 的代理功能，该功能允许组合CPO管理系统4500能够代表已经把 这种授权委托给组合CPO管理系统4500的某些基于代理的卖方， 接受或拒绝给定的成分CPO。这样，组合CPO管理系统4500最好(i) 代表已经把这种授权委托给组合CPO管理系统4500的某些基于代 理的卖方接受或拒绝给定的成分CPO，及(ii)允许基于广播的卖方能 够独立地评估成分CPO。这样，组合CPO管理系统4500最好能够 向每一基于广播的卖方提供收到的组合CPO的一个或多个成分 CPO，使卖方可独立地确定是否接受给定的成分CPO。要注意，例 如在由每一基于广播的卖方可访问的电子公告牌上，例如借助于广播 传输或借助于成分CPO的邮寄，组合CPO管理系统4500能够向每 一适当的基于广播的卖方提供成分CPO。另外，组合CPO管理系统 4500能够对照由一个或多个基于代理的卖方定义的数个CPO规则， 来评估一个收到的组合CPO的一个或多个成分CPO，以代表基于代 理的卖方决定接受或拒绝给定的成分CPO。这样，通过向每一卖方 提供成分CPO并接收承诺或拒绝，或通过把成分CPO施加于CPO 规则而代表特定的卖方决定或接受或拒绝或讨价成分CPO，组合CPO 管理系统4500能够确定一个或多个卖方是否接受一给定的成分 CPO。
如以下进一步的讨论，CPO规则是一组由给定的基于代理的卖 方诸如卖方4804定义的限制，以定义这种限制的一个组合，卖方愿 意对这种限制接受预定的最小价格。在一个实施例中，CPO规则是 由各基于代理的卖方的收益管理系统、产出管理系统、或利润管理系 统产生的，或是由控制和管理存量的系统产生的。对于CPO规则更 详细的讨论，它们产生的方式和相关的安全问题，可参见美国专利 08/819,319，名称为Conditional Purchase Offer Management System， 1997年7月提交，本发明的原始申请，该文献在此结合作为参照。 一般来说，例如收益管理系统将采用CPO规则产生过程通过评估当 前存量、定价和收益信息以及历史模式和外部活动而产生CPO规则， 以便预测未来的旅游。
例如，对于给定的基于代理的航空公司的CPO规则能够规定航 空公司将接受任何为在Newark，New Jersey(EWR)和Orlando， Florida(MCO)之间在1997年10月期间旅行的CPO，如果(i)顾客是 在星期二和星期四之间旅行，(ii)机票在出发前21天内定座，(iii)每 张机票价格至少为$165，(iv)K-等级存量在顾客旅程的所有飞行区段可 得，以及(v)至少有两(2)个旅客一同旅行。
如以下结合图47进一步所讨论的，每一安全服务器4700可能与 一个或多个基于代理的卖方相关，且每一服务器4700除了其它之外 存储由任何相关的基于代理的卖方定义的CPO规则，诸如规则4804 和4806。每一安全服务器4700如图45中所示可能位于远离中央控 制器4600，或可能与中央控制器4600结合在一起。在一个远程实施 例中，与每一基于代理的卖方相关的安全服务器4700可能在物理上 位于由特定的卖方保证安全的处理设备处，或在第三方的物理位置。
如以下进一步所讨论，每一买方例如借助于电话、传真、联机访 问、电子邮件、人员的接触或通过代理人与组合CPO管理系统4500 接触，并对组合CPO管理系统4500提供他们的组合CPO条款。要 注意，每一买方可以使用以下结合图48所讨论的通用计算机，诸如 买方接口4800，用于与组合CPO管理系统4500通信。每一买方的 通用计算机最好由处理单元、调制解调器及任何与组合CPO管理系 统4500通信所需的软件组成。
一旦组合CPO的条款由组合CPO管理系统4500收到，中央控 制器4600将执行以下结合图55a和55c所讨论的组合CPO公告过程 5500，以便把整个的组合CPO分解为成分CPO，并然后(i)向适当的 基于广播的卖方提供每一成分CPO，并(ii)对比适当的基于代理的卖 方的适当CPO规则评估每一成分CPO。此外，一旦成分CPO已经 公告，则组合CPO管理系统4500最好将周期地执行以下结合图56a 到56c进一步讨论的组合CPO监视过程，以确定整个的组合CPO 的每一成分CPO是否由适当的卖方接受。如果给定的组合CPO的 各成分CPO每一个由一个或多个卖方接受，则组合CPO管理系统 4500代表接受的卖方通知买方，他已经被约定以满足买方定义的条 件的适当限制购买整个组合。
组合CPO管理系统4500和买方与卖方接口4800-4806(统称为“结 点”)最好彼此之间传输数字化编码的数据和其它信息。结点之间的 通信链接最好包括电子信号能够在其上面传播的电缆、光纤或无线链 路。例如，每一结点可通过使用诸如由本地或区域电话经营公司提供 的公共交换电话网(PSTN)通过因特网连接被连接起来。另外，每一 结点可以通过专用数据线路、蜂窝电话、个人通信系统(＂PCS＂)，微 波或卫星网络连接。
图46是表示示例性中央控制器4600的体系结构的框图，中央控 制器4600最好包括一定的标准硬组件，诸如中央处理器(CPU)4605、 随机存取存储器(RAM)4610、只读存储器(ROM)4620、时钟4625、 数据存储器装置4630、操作系统4650、支付处理器4660及网络接口 4680。CPU 4605最好连接到每一其它列出的部件，或者通过共享的 数据总线，或者专用的连接，如图46中所示。
CPU 4605可以作为单一的市售处理器嵌入，诸如Intel的Pentium 100Mhz P54C微处理器，Motorola 120MHz PowerPC 604微处理器 或Sun Microsystem的166MHz UltraSPARC-1微处理器。另外，CPU 4605可以作为数个并行操作的这种处理器实现。
ROM 4620和/或数据存储器装置4630可操作以存储以下结合图 55和56所讨论的一个或多个指令，CPU 4605可操作对这些指令进 行检索、解释并执行。支付处理器4660可操作地实现已知的过程， 以便借助于普通的电子资金转移网络(EFT)实现卖方和买方之间所需 支付的转帐、收费和借贷。具体来说，如以下结合图56所讨论的， 如果组合实际上由买方购买，则组合CPO监视过程5600最好向信 用卡发放者传输与给定买方相关的信用卡信息供支付。这种会计交易 的处理最好以通常的方式保证安全，例如使用熟知的密码技术。
CPU 4605最好按已知的方式包括控制单元、算术逻辑单元 (ALU)、及CPU局部存储器存储器装置，诸如可堆栈高速缓存器或 多个寄存器。控制单元可操作以便从数据存储器装置4630或ROM 4620检索指令。ALU可操作以便进行执行指令所需的多种操作。CPU 局部存储器存储器装置可操作以便提供高速存储，用于存储暂时的结 果和控制信息。
如以分别下结合图49到53进一步所讨论的，数据存储器装置4630 包括买方数据库4900、卖方数据库5000、组合CPO数据库5100、 成分CPO数据库5200及市场价格数据库5300。买方数据库4900最 好存储关于组合CPO管理系统4500的每一买方的信息，包括个人 情况信息和开单信息，诸如信用卡号码。卖方数据库5000最好存储 关于对组合CPO管理系统4500登记了的向组合CPO买方销售成分 货物或服务的每一卖方的信息，包括标识符和姓名信息。组合CPO 数据库5100最好包含由组合CPO管理系统4500处理的每一组合CPO 的记录，包括每一组合CPO内的成分CPO的指示和相关状态。成 分CPO数据库5200最好包含由组合CPO管理系统4500处理的每 一组合CPO的记录，包括每一成分CPO的条款和相关状态。最后， 市场价格数据库5300最好存储由组合CPO管理系统4500处理的每 一成分货物或服务的市场价格信息。
此外，数据存储器装置4630包括在以下分别结合图55和56进 一步讨论的组合CPO公告过程5500和组合CPO监视过程5600。一 般来说，组合CPO公告过程5500把组合CPO分解为成分货物或服 务，并然后(i)向适当的基于广播的卖方公告每一成分CPO及(ii)对比 每一基于代理的卖方的适当CPO规则评估每一成分CPO。组合CPO 监视过程5600确定公告的组合CPO的每一成分CPO是否由适当的 卖方接受，并如果接受，则向每一接受的卖方提供买方信息。这样， 如果给定的组合CPO的各CPO的每一个被接受，则组合CPO管理 系统4500代表每一接受的卖方通知买方，它已经被约定购买整个组 合。
网络接口信息4680例如借助于使用公共电话交换网(PSTN)的因 特网连接把中央控制器4600连接到买方和卖方。网络接口4680最好 包含多个通信渠道以便同时建立多个连接。
图47是表示示例性安全服务器4700体系结构的框图。如前面所 指出，组合CPO管理系统4500可以使用一个或多个安全服务器 4700，每一支持一个或多个基于代理的卖方4804、4806。每一安全 服务器4700最好包含一定的标准硬组件，诸如中央处理器 (CPU)4705、随机存取存储器(RAM)4710、只读存储器(ROM)4720、 时钟4725、数据存储器装置4730、及通信端口4740。这些组件的每 一个可以与以上结合图46所述的组件相同。
如上所指出，在一个实施例中，CPO规则可以存储在安全数据 库中以保持包含在每一CPO规则中的高度敏感信息的完整性和保密 性。这样，安全服务器4700最好使用安全数据库，诸如从 Oracle，Informix或IBM商业可得的产品。
如以下结合图54进一步的讨论，数据存储器装置4730包括卖方 规则安全数据库5400。卖方规则安全数据库5400最好对与安全服务 器4700相关的一个或多个基于代理的卖方维护CPO规则。如前所 指出，卖方规则安全数据库5400可以以加密格式存储以保持CPO 规则中包含的高度敏感信息的完整性和保密性。此外，数据存储器装 置4730包含在以下结合图57进一步讨论的成分CPO规则评估过程 5700。一般来说，成分CPO规则评估过程5700是由组合CPO公告 过程5500执行的子程序，该子程序接收成分CPO并对照一个或多 个基于代理的卖方分规则比较该CPO，以代表卖方产生对给定的成 分CPO的响应。
安全服务器4700可以有选择地对由组合CPO管理系统4500处 理的每一成分CPO维护审计痕迹。对于适当审计系统的讨论，请参 见以上在此作为参照的本发明的原始申请。
通信端口4740把安全服务器4700连接到中央控制器4600。通 信端口4740最好包含用于同时建立多个连接的多个通信渠道。
图48是表示示例性买方和卖方接口4800-4806的体系结构的框 图。接口4800最好包括一定的标准硬组件，诸如中央处理器 (CPU)4805、随机存取存储器(RAM)4810、只读存储器(ROM)4820、 时钟4825、数据存储器装置4830、及通信端口4840。这些组件的每 一个可以与以上结合图46所述的组件相同。此外，接口4800最好包 含视频监视器4850和相关的视频驱动器4860，及输入装置，诸如键 盘和鼠标。
数据存储器装置4830最好包含一消息数据库4880，用于通过各 买方和卖方接口4800-4806存储所需的消息以便与组合CPO管理系 统4500的中央控制器4600通信。对基于广播的和基于代理的卖方， 通信代理4840把接口4800分别连接到中央控制器4600或安全服务 器4700。
图49表示一示例性买方数据库4900，该数据库最好存储关于组 合CPO管理系统4500的每一买方的信息，包括个人情况信息和开 单信息，诸如信用卡号码。买方数据库4900保持多个记录，诸如记 录4905-4915，每一记录与不同的买方相关。对于字段4920中的每 一买方的标识符，买方数据库4900在字段4925和4930分别包含对 应的买方姓名和地址，并在字段4935包含信用卡号码。此外，买方 数据库4900最好包含与字段4940中的买方相关的CPO的指示，它 可能是这里所述的组合CPO或本发明的原始申请中所述的一般的 CPO。存储在字段4029中的标识符例如可用于索引以前购买及与买 方相关的CPO的历史数据库(未示出)。
图50示出示例性卖方数据库5000，该数据库最好存储有关与组 合CPO管理系统4500登记以便向组合CPO买方销售成分货物或服 务的每一卖方的信息，包括标识符和姓名信息。
卖方数据库5000维护多个记录，诸如记录5005-5030，每一与不 同的卖方相关。对于字段5035列出的每一卖方的标识符，卖方数据 库5000在字段5040包含对应的卖方姓名。此外，卖方数据库5000 最好在字段5045对与每一卖方相关的任何CPO记录跟踪号码。要 注意，记录在字段5045的信息能够通过在以下讨论的组合CPO数 据库5100中包含卖方ID字段而类似地被记录。
图51表示一组合CPO数据库5100，该数据库最好包含正在由 组合CPO管理系统4500处理的每一组合CPO的记录，包括每一组 合CPO内的成分CPO的指示和相关状态。组合CPO数据库5100 维护多个记录，诸如记录5105-5110，每一与不同的组合CPO相关。 对于字段5120中列出的每一组合CPO，组合CPO数据库5100在字 段5125和5130中分别包含状态和初始要约的价格。此外，组合CPO 数据库5100最好在字段5135到5150中分别记录保证金因子，剩余 保证金，调整的组合CPO价格及每分配保证金百分比。保证金变量 由组合CPO管理系统4500处理的方式在以下结合图56讨论。组合 CPO的公告和过期日期，以及对每一保证金分配所需的整个持续时 间段和公告时间分别存储在字段5155到5170中。每一组合CPO内 的各成分货物或服务有选择地标识在字段5175中，且与每一成分相 关的条件和成分号码记载在字段5180和5185中。要注意，另外能够 使用记录在字段5185中的成分CPO号码从成分CPO数据库5200 检索字段5175和5180中记录的信息。最后，与每一组合CPO相关 的买方的标识符最好记录在字段5190。
图52表示一示例性成分组合CPO数据库5200，该数据库最好 包含对正在由组合CPO管理系统4500处理的每一成分CPO的记录， 包括成分CPO的条款和相关的状态。成分CPO数据库5200维护多 个记录，诸如记录5205到5230，每一记录与正在由系统4500处理 的不同的成分CPO相关。对于由字段5240中的成分CPO号码标识 的每一成分，成分CPO数据库5200在字段5245包含对每预定约定 的成分CPO状态或过期日期，以及在字段5250到5260分别包含与 成分CPO相关的对应的目标、价格和条件。最后，在字段5265最 好记录与每一成分CPO相关的买方的标识符。
图53示出一示例性市场价格数据库5300，该数据库最好对由组 合CPO管理系统4500处理的每一成分货物和服务存储市场价格信 息。如以下结合图55进一步讨论的，组合CPO公告过程4500最好 使用市场价格信息向每一成分货物或服务分配组合总价格。市场价格 数据库5300维护多个记录，诸如记录5305到5345，每一记录与由 系统4500处理的不同的成分货物或服务相关。对于字段5360中标识 的每一成分货物或服务，市场价格数据库5300在字段5365中标识对 每一货物或服务的可得的质量或服务水平，以及对字段5370中指示 的每一时间段，在字段5375中标识所提出的对应的市场价格。要注 意，最好对每一始发和目标城市对(O&D Pair)记录对于往返航空旅 行的每一服务水平的市场价格。
如前所指出的，安全服务器4700最好维护一个或多个卖方规则 安全数据库5400，以便为与安全服务器4700相关的一个或多个基于 代理的卖方存储CPO规则。卖方规则安全数据库5400的一例用于 基于代理的航空公司示于图54a中，用于基于代理的旅馆示于图54b 中。
图54a表示一示例性航空公司规则安全数据库5400，该数据库 最好对与特定的安全服务器4700相关的一个或多个基于代理的航空 公司维护CPO规则。如前面所指出的，航空公司规则安全数据库5400 可以以加密格式存储，以便维护包含在CPO规则中的高度敏感信息 的完整性和保密性。航空公司规则安全数据库5400维护多个记录， 诸如记录5402和5404，每一与不同的CPO规则相关。对于由字段 5410中规则号码标识的每一CPO规则，航空公司规则安全数据库 5400包含由字段5412到5444中基于代理的各航空公司定义的相关 限制。
图54b表示一示例性旅馆规则安全数据库5450，该数据库最好 对与特定的安全服务器4700相关的一个或多个基于代理的旅馆维护 CPO规则。如前面所指出的，旅馆规则安全数据库5450可以以加密 格式存储，以便维护包含在CPO规则中的高度敏感信息的完整性和 保密性。旅馆规则安全数据库5450维护多个记录，诸如记录5452和 5456，每一与不同的CPO规则相关。对于由字段5460中规则号码 标识的每一CPO规则，旅馆规则安全数据库5450在字段5465中标 识适用的旅馆地点并包含由字段5470到5490中基于代理的各旅馆定 义的相关限制。
如以上所讨论，中央控制器4600最好执行图55a到55c所示的 组合CPO公告过程5500，以便把组合CPO分解为成分货物或服务， 并然后(i)向适当的基于广播的卖方公告每一成分CPO及(ii)对比每一 基于代理的卖方的适当CPO规则评估每一成分CPO。如图55a中所 示，当买方对成分货物或服务的组合提交CPO时，在步骤5505期 间，组合CPO广播过程5500开始实施本发明的原理的过程。
然后，中央控制器4600将从买方接收与组合CPO相关包括每一 成分货物或服务的限制的条件，以及一般用途帐户诸如信用卡或借贷 卡帐户的标识符，在步骤5510资金可从这些帐户支付，并然后在步 骤5515期间从买方接收组合CPO的价格和过期日期。这样，例如 使用信用卡帐户的信用限额，以一般用途帐户保证要约。最好在步骤 5520期间显示适当的法律用语并向买方读出以形成约定的组合 CPO。在步骤5525期间产生组合CPO号码，并然后在步骤5530期 间向组合CPO数据库5100输入包括买方标识符、组合CPO价格及 过期日期的组合CPO信息、以及对于成分货物或服务的条件的信息。
如前所指出的，在对每一成分CPO计算要约价格之前，组合CPO 管理系统4500最好留出组合要约总价格的一保证金。这样，在步骤 5535期间，通过使组合CPO价格乘以记录在组合CPO数据库5100 中的保证金因子，计算出适当的保证金。然后在步骤5540期间(图 55b)，所计算的保证金记录在组合CPO数据库5100的“剩余保证金” 字段5140中。然后通过从最初的组合要约的总价格减去计算的保证 金而计算出调整的CPO价格，然后该价格在步骤5545期间输入到 组合CPO数据库5100。然后在步骤5550期间在组合CPO数据库5100 的字段5125中组合CPO的状态被设置为“有效”。
在步骤5555期间从市场价格数据库5300检索组合CPO中的每 一成分货物或服务的市场价格。在步骤5560期间通过把整个组合中 的每一各成分CPO的市场价格相加，检索出整个的组合CPO市场 价格。然后在步骤5565期间，例如通过根据各成分货物或服务的市 场价格对总的市场价格的比率，而分配如步骤5545期间计算调整的 组合CPO价格，计算出对每一成分CPO的各CPO价格。
然后在步骤5570期间对每一成分CPO产生CPO号码，并在步 骤5575期间(图55c)记录到组合CPO数据库5100的“成分CPO号 码”字段中。在步骤5590期间向每一基于广播的卖方提供每一成分 CPO，并对每一基于代理卖方执行成分CPO规则评估过程5700之 前，在步骤5580期间对每一成分CPO的成分CPO数据库5200中 生成一新的记录。在步骤5595期间程序控制终止。
如以上所讨论，中央控制器4600最好执行图56a到56c所示的 组合CPO监视过程，以确定公告的组合CPO的每一成分CPO是否 已经由适当的卖方接受，并如果接受，则向每一接受的卖方提供买方 信息。这样，若给定的组合CPO的各成分CPO的每一个被接受， 则组合CPO管理系统4500代表每一接受的卖方通知并约定买方， 购买整个的组合。组合CPO监视过程5600可被周期地执行以确定 每一成分CPO的状态，或被连续地执行。
如图56a所示，组合CPO监视过程5600通过一测试以确定是否 给定的组合CPO内所有的成分CPO已经按当前的公告的价格被预 约定，在步骤5605期间开始实施本发明原理的过程。要注意，在示 例性实施例中，向接受给定的成分CPO的第一个卖方判给该成分 CPO。对于用来确定向多个接受的卖方中的哪一个卖方判给一成分 CPO的其它机制的讨论，请参见以上在此参照的本发明的原始申请。 如果在步骤5605期间确定，给定的组合CPO内的所有成分CPO已 经按当前公告的价格被预约定，则在步骤5650期间从买方数据库4900 检索包括买方的姓名、地址和帐户号码的买方的识别信息。然后在步 骤5655期间向接受成分CPO的每一卖方传输买方识别号码。在步 骤5660期间通过通常的信用卡授权网络，组合CPO监视过程5600 向对于支付授权的信用卡发放者，连同买方的信用卡帐户号码、开单 描述符和对组合CPO的购买量，传输组合CPO管理系统4500的商 务标识符。
在步骤5665期间更新组合CPO数据库5100的状态字段5125， 以便在程序控制在步骤5670期间终止之前指出各组合CPO被完成。
然而，如果在步骤5605期间确定，给定的组合CPO内所有的成 分CPO还没有以当前公告的价格预约定，则在步骤5610期间(图56b) 从组合CPO数据库5100的字段5160检索组合CPO的过期日期。 接着在步骤5615期间进行检查以判定组合CPO是否过期。如果在 步骤5615期间确定组合CPO已经过期，而每一成分未都被预约定， 则组合CPO监视过程5600(I)在步骤5635期间向各卖方传送被一个 或多个卖方接受的过期的组合CPO内的成分CPO的任何预约定协 议的终止；(II)在步骤5640期间向各买方传送组合CPO的过期。在 另一实施例中，如果原来的组合CPO未被接受，则能够邀请买方再 次提交修改的组合CPO。此外，组合CPO管理系统4500可能基于 由组合CPO管理系统4500接收的各成分的承诺试图编辑对买方的 还价。然后，在步骤5645程序控制终止。
然而如果在步骤5615期间确定，组合CPO没有过期，则组合CPO 监视过程5600，例如通过访问组合CPO数据库5100识别出组合CPO 中的成分数目，并识别当前预约定成分数目，将在步骤5620期间调 整组合CPO数据库5100的状态字段5125，以便指示当前预约定的 整个组合CPO的百分数。然后在步骤期间5625从组合CPO数据库 5100的字段5165检索“整个的公告持续时间”参数，然后该参数乘 以在字段5170中设置的“每一保证金分配所需的公告时间”。
然后在步骤5630期间进行一测试，以确定对于分配附加的保证 金以增加还没有被预约定的每一成分CPO的价格所需的公告时间， 组合CPO是否已经为有效。如果在步骤5630期间确定组合CPO对 于分配附加保证金所需的公告时间还不是有效的，则程序控制返回步 骤5605(图56a)并继续按以上方式处理。然而如果在步骤5630期间 确定组合CPO对于分配附加保证金所需的公告时间是有效的，则在 步骤5675期间(图56c)计算每一剩余的有效成分CPO相对于所有剩 余的有效成分CPO的总价格的百分组成。
然后在步骤5680期间从组合CPO数据库5100的字段5150检索 “每分配保证金的百分比”。然后在步骤5682通过把检索的“每分配 保证金的百分比”值乘以记录在组合CPO数据库5100的字段5140 中的“剩余保证金”的值，计算出要分配给剩余的有效成分CPO的 保证金量。然后在步骤5684通过使剩余的有效成分CPO(如在步骤 5675期间所确定的)的价格百分比乘以计算出的可分配保证金量，向 每一剩余的有效成分CPO按适当的百分比分配剩余的保证金。
例如，如果三个成分的组合的一个成分最初以原来的公告价格预 预定，并且剩余的两个成分在分配附加的保证金所需的公告时间内没 有被约定，则组合CPO监视过程5600最好在这两个剩余的成分CPO 之间分配保证金的一部分。分配给每一成分CPO的量最好按它们各 自原来公告的价格确定。在以上所讨论的买方对由航空旅行、旅馆设 施和汽车租借组成的旅行组合，以组合的总价格不超过一千美元 ($1,000.00)提交一要约的例子中，假设预约定的第一个成分是$360 的航空公司机票。这样，组合CPO监视过程5600将把剩余的保证 金部分分配给旅馆和汽车租借成分CPO的要约价格。在一优选实施 例中，由于旅馆成分CPO占整个剩余CPO价格达62％ ($333/($333+$207))，故旅馆成分CPO的要约价格增加从保证金($50) 提取的款项的62％或31％。类似地，汽车租借成分CPO要约价格 将增加38％或19％。如果对分配附加的保证金所需的公告时间仍有 一个或多个成分没有被约定，则最好分配更多的保证金。
在步骤5688期间通过减去在前面步骤所分配的保证金而调节字 段5140中记录的“剩余保证金”。然后，在步骤5690期间，带有新 调整的价格的剩余的有效CPO提供给基于广播的卖方，并对每一适 当的基于代理的卖方执行成分CPO规则评估过程5700。最后，程序 控制返回步骤5605(图56a)，并继续以上所述的处理，直到所有的成 分CPO被预约定，或直到最后CPO过期。这样，对分配附加保证 金所需的每一时间周期仍然没有被接受的每一成分CPO，要约价格 增加附加的分配保证金。如以上所讨论，组合CPO公告过程5500 和组合CPO监视过程5600，分别在步骤5590和5690各执行成分CPO 规则评估过程，为基于代理的卖方对照一个或多个基于代理的卖方的 规则比较成分CPO，以代表卖方产生对给定成分CPO的响应。一示 例性成分CPO规则评估过程4700示于图57中。在一个实施例中， 成分CPO规则评估过程4700对每一基于代理的卖方定制，使得每 一评估过程5700从中央控制器4600按标准格式接收成分CPO记录， 用于对照相关卖方的规则比较，并返回卖方对成分CPO的标准响应， 诸如“接受”或“拒绝”。
如图57所示，成分CPO规则评估过程5700起初在步骤5710识 别卖方规则安全数据库5000中与成分CPO有关的所有CPO规则。 然后，在步骤5720期间，对于在前一步骤识别的每一CPO规则， 来自成分CPO数据库5200中的成分CPO记录的买方定义的条件在 步骤5720期间与来自卖方安全数据库5000的对应的卖方定义的限制 比较。
然后在步骤5730期间，进行一测试以确定成分CPO是否满足 CPO规则。如果在步骤5730期间确定成分CPO不满足一个CPO规 则，则程序控制在步骤期间5770终止。然而如果在步骤5730期间确 定成分CPO满足一CPO规则，则在步骤期间5740从成分CPO数 据库5200检索成分CPO号码，并然后输入到卖方数据库5000的“CPO 跟踪号码”字段5045。在程序控制在步骤5770终止之前，在步骤5760 期间成分CPO数据库5200的字段5245中的成分CPO状态更新为 “预约定完成”。此外，如果受到卖方委托，则预约定过期日期能够 添加到字段5245中。
用于电话通话的CPO管理系统
以下将结合图58到66讨论适于处理对一个或多个电话通话购买 要约的本发明进一步的实施例。图58A和58B示出一个有条件购买 要约(CPO)管理系统5800，用于接收和处理对来自一个或多个呼叫方 诸如呼叫方5810的电话通话的CPO。CPO管理系统5800处理CPO 以确定一个或多个长途电信公司，诸如局间电信公司5820-5824，是否 愿意接受给定的CPO并根据由呼叫方5810定义的限制完成电话通 话。例如在美国，局间电信公司5820-5824可能是AT&T、Sprint及 MCI。如以下进一步的讨论，如果局间电信公司5820接受给定的 CPO，则CPO管理系统5800代表接受的局间电信公司5820约定呼 叫方5810，以形成有法律约束力的合同。
如这里使用的，CPO是包含一个或多个条件的约定的要约，它 由呼叫方5810提交用于通常以由呼叫方定义的价格完成一个或多个 电话通话。这样，呼叫方5810最好能够向一个或多个被呼叫方5830 对于个别的电话通话、呼叫的组合提交一CPO，或对于预定的时间 周期提供电话服务的合同提交一CPO。在示例性实施例中，由呼叫 方5810定义的条件可包含被呼叫的电话号码、最大价格、如果有则 一个或多个偏爱的电信公司、以及任何的时间限制，诸如一天内特定 的时间或最小通话持续时间。最大价格可最好由呼叫方5810按固定 时间周期价格规定，诸如对二十(20)分钟电话通话十美元($10)，或者 按每分钟价率，诸如每分钟十四美分($0.14/分钟)。
CPO管理系统
图58A表示用于使CPO管理系统5800与一个或多个呼叫方5810 及一个或多个局间电信公司5820-5824互连的示例性网络环境，局间 电信公司可对通话规定到所需的被呼叫方5830的路线。根据本发明 的一个特点，通常由普通老式电话业务(POTS)电话号码标识的希望 与被呼叫方5830通话的呼叫方5810，可以向CPO管理系统5800提 交一要约，用于根据由呼叫方定义的限制的电话通话。在一优选实施 例中，呼叫方5810使用图59所示的电话机5900，在拨打被呼叫方5830 电话号码之前，拨打分配给CPO管理系统5800的电话号码，诸如 不收费电话号码，或“800号码”，以便向CPO管理系统5800提供 CPO条款。另外，呼叫方5810最初能够借助于传真与CPO管理系 统5800接触。一旦呼叫方5810开始与CPO管理系统5800接触， 则呼叫方5810就向CPO管理系统5800提交CPO条款，诸如通话 的最大价格和被呼叫方5830的电话号码。
在图58B所示的一变形中，呼叫方5810起初能够借助于使用诸 如通用计算机的用户终端5815访问因特网的联机访问或电子邮件， 与CPO管理系统5800接触。这一联机的实施例特别适用于希望向 一个或多个被呼叫方5830提交用于通话组合的CPO的呼叫方5810， 或适用于提供预定时间周期电话服务的合同。
如图59所示，CPO条款可选择地在电话机5900上显示给呼叫 方5810。此外，电话机5900能够特别配置用于向CPO管理系统5800 或直接向局间电信公司5820传输CPO的软件。例如，能够对电话 机5900的速度拨号按钮编程，以便自动向CPO管理系统5800或直 接向局间电信公司5820传输CPO条款。这样，呼叫方5810将使用 电话机5900上的小键盘和功能键对给定的CPO条款进行编程，并 然后使用速度拨号按钮启动CPO的传输。
如图58A所示，当呼叫方5810拨打指定给CPO管理系统5800 的电话号码时，一般首先建立到本地交换操作员5850的连接，例如 这是本地电信公司的电话交换系统。本地交换操作员5850转而把呼 叫方连接到公共交换电话网(PSTN)。按电话技术中熟知的方式，本 地交换操作员5850能够通过通信链路5860建立呼叫方5810与数个 局间电信公司5820-5824之一之间的连接。局间电信公司5820例如 可以是长途载波网络，包括电路和分组交换网络或它们的组合的提供 者，且通信链路5860可以是在其上能够传播电子信号的电缆、光纤 或无线链路。要注意，随着长途电信公司在很多地区提供本地电话服 务或者相反的趋势，本地交换操作员5850和局间电信公司5820-5824 之间的区别可能变得透明。一个或多个局间电信公司5820可能能够 在给定的呼叫方5810和所希望的被呼叫方5830之间确定通话路由。 对于在给定的呼叫方5810和所希望的被呼叫方5830之间通过局间电 信公司5820经长途载波网络建立连接的方式的更详细的讨论，请参 见在此作为参照的4,191,860号美国专利。
根据本发明的一个特点，CPO管理系统5800最好提供可选的代 理功能，这种功能使CPO管理系统5800能够代表某些基于代理的 局间电信公司5820接受或拒绝给定的CPO，这些局间电信公司已经 把这种授权委托给CPO管理系统5800。这样，CPO管理系统5800 最好(i)代表已把对决定接受或拒绝给定的CPO的授权委托给CPO 管理系统5800的某些基于代理的局间电信公司5820评估CPO；以 及(ii)使基于广播的局间电信公司5820能够独立地评估CPO。这样， CPO管理系统5800能够向每一基于广播的局间电信公司5820提供 CPO，以便局间电信公司5820独立地决定是否接受给定的CPO。要 注意，例如借助于广播传输，或借助于例如在每一基于广播的局间电 信公司可访问的电子公告牌上公告CPO，CPO管理系统5800能够 向每一基于广播的局间电信公司5820提供CPO。
此外，CPO管理系统5800能够对照由一个或多个基于代理的局 间电信公司5820所定义的数个CPO规则评估CPO，以代表基于代 理的局间电信公司5820决定接收或拒绝给定的CPO。这样，CPO 管理系统5800能够通过向每一电信公司提供CPO并接收承诺或拒 绝而确定一个或多个电信公司是否接受给定的CPO，或者通过把CPO 施于CPO规则而代表特定的电信公司提出或接收或拒绝或讨价CPO 的决定。
如以下进一步的讨论，CPO规则是一组由给定的基于代理的局 间电信公司5820定义的限制，以便定义这种限制的一组合，就此局 间电信公司5820愿意接受委托完成一个或多个电话通话。在一优选 实施例中，CPO规则由各基于代理的局间电信公司5820的某类收益 管理系统、产出管理系统、或利润管理系统产生，或者由任何控制和 管理网络容量的系统产生。对于CPO规则，它们的产生方式及有关 的安全问题更详细的讨论，请参见第08/889,319号美国专利申请，名 称为Conditional Purchase Offer Management System，1997年7月8 日提交，这是本发明的原始申请，在此作为参照。一般来说，例如收 益管理系统将采用CPO规则产生过程产生CPO规则，通过评估当 前网络容量、定价和收益信息，以及历史模式和外部活动，预测未来 的通话需求。
一旦CPO的条款由CPO管理系统5800接收，则以下结合图60 讨论的中央服务器6000将执行以下结合图65a和65b讨论的CPO 管理过程6500，以便(i)向局间电信公司5820提供每一CPO且(ii)确 定要约的条款是否已由任何局间电信公司5820接受。然后，CPO管 理系统5800或接受的局间电信公司5820通知呼叫方5810局间电信 公司5820的响应，并如果接受，则呼叫方5810被约定完成并对一个 或多个满足由呼叫方5810定义的条件的适当限制的通话付费。
CPO管理系统5800可以有选择地对由CPO管理系统5800处理 的每一CPO保持审计痕迹。对于适用的审计系统的讨论，请参见在 此结合作为对照的本发明的原始申请。
根据本发明的另一特点，CPO管理系统5800防止了呼叫方5810 从一个或多个与给定的CPO相关的电话通话识别电信公司最低价 格。例如，CPO管理系统5800最好不向呼叫方公开电信公司的最低 价格，并可选地限制任何呼叫方5810能够在预定的时间周期内提交 的CPO的数目。此外，本发明约定的性质阻止了呼叫方5810提交CPO 只是为了识别最小价格，因为呼叫方5810将有责任根据CPO条款 完成一个或多个电话通话。在另一实施例中，如果当至少一个电信公 司5820已经接受CPO时通话没有被完成，则能够对呼叫方5810收 费或罚款，或者CPO管理系统5800能够对包含有关呼叫方5810将 完成对应于所述的CPO一个或多个电话通话的似然率的信息的呼叫 方5810的信誉进行评估。对于适当的信誉评估系统更详细的描述， 请参见向本发明受让人转让并在此结合作为对照的美国专利申请 No.08/811,349，1997年3月4日提交，名称为AIRLINE PRICE INQUIRY METHOD AND SYSTEM。在一个实施例中，被评估的信 誉包括由顾客5810完成的通话对购买要约的比率。这样，电信公司 5820能够确信，如果电信公司接受呼叫方的要约，则呼叫方5810将 完成呼叫而不会使用信息查明电信公司的价格灵活性的基本水平。
图60是表示一示例性CPO管理中央服务器6000的体系结构的 框图。CPO管理中央服务器6000最好包含一定的标准硬组件，诸如 中央处理器(CPU)6005、随机存取存储器(RAM)6010、只读存储器 (ROM)6020、时钟6025、数据存储器装置6030、及通信端口6040。 CPU 6005最好连接到每一其它列出的部件，或者通过共享的数据总 线，或者专用的连接，如图60中所示。CPU 6005可以作为单一的市 售处理器实现，诸如Intel的Pentium 100Mhz P54C微处理器， Motorola 120MHz PowerPC 604微处理器或Sun Microsystem的 166MHz UltraSPARC-1微处理器。另外，CPU 6005可以作为数个协 同操作的这种处理器实现。
ROM 6020和/或数据存储器装置6030可操作以存储以下结合图 65和66进一步所讨论的一个或多个指令，CPU 6005可操作对这些 指令进行检索、解释并执行。例如，ROM 6020和/或数据存储器装 置6030最好存储一些过程，以便在呼叫方5810与局间电信公司 5820-5824之间实现要求的支付、收费、和罚款的转帐。
CPU 6005最好按熟知的方式包括控制单元、算术逻辑单元 (ALU)、及CPU局部存储器存储器装置，诸如可堆栈高速缓存器或 多个寄存器。控制单元可操作以便从数据存储器装置6030或ROM 6020检索指令。ALU可操作以便进行执行指令所需的多种操作。CPU 局部存储器存储器装置可操作以便提供高速存储，用于存储暂时的结 果和控制信息。
如以下结合图61到64分别所讨论的，数据存储器装置6030最 好包括顾客数据库6100、电信公司数据库6200、费率数据库6300、 及CPO数据库2900。顾客数据库6100最好存储关于CPO管理系统 6000的每一顾客的信息，包括个人情况信息和对每一顾客服务的本 地电话公司的指示。电信公司数据库6200最好存储关于对CPO管 理系统5800登记了的向呼叫方提供长途电话服务的每一电信公司的 信息，包括地址信息。费率数据库6300最好对在电信公司数据库6200 中标识的每一电信公司存储公布的费率信息。最后，CPO数据库6400 最好包含正在由CPO管理系统5800处理的每一CPO的记录，包括 CPO条款和相关状态。
在一个实施例中，其中CPO管理系统5800提供一种代理功能， 使CPO管理系统5800能够代表把这种授权委托给CPO管理系统5800 的基于代理的一些局间电信公司5820接受或拒绝给定的CPO，CPO 管理中央服务器6000最好包含用于存储CPO规则的CPO规则数据 库(未示出)。CPO规则可以存储在安全数据库中，以保持包含在每一 CPO规则中的敏感信息的完整性和保密性。
此外，数据存储器装置6030包括在以下结合图65a和65b进一 步讨论的CPO管理过程6500，以及以下结合图66a和66b进一步讨 论的IVRU过程6600。一般来说，CPO管理过程6500从呼叫方5810 接收每一CPO，向每一适当的局间电信公司5820提供CPO，并然 后确定要约的条款是否已经由任何局间电信公司5820接受。IVRU 过程6600最好由CPO管理过程6500引用以便从呼叫方5810接收 CPO的参数。
通信端口6040把CPO管理中央服务器6000连接到本地交换机 操作员5850和局间电信公司5820-5824。通信端口6040最好包含多 个通信信道用于同时建立多个连接。
数据库
图61示出一示例性顾客数据库6100，它最好存储关于CPO管 理系统6000的每一顾客(呼叫方)的信息，包括个人情况信息和对每 一顾客服务的本地电话公司的指示。顾客数据库6100包含多个记录， 诸如记录6105-6125，每一记录与不同的顾客相关。对于在字段6140 中列出的每一顾客的姓名，顾客数据库6100在字段6145包含顾客的 地址，在字段6150包含顾客被约定的方式，在字段6155包含对顾客 服务的本地电话公司的指示，并在字段6160包含顾客的电话号码。 存储在字段6160中的电话号码例如可以用作为顾客的标识符，以便 对以前与该顾客相关的交易的历史数据库(未示出)进行索引。
如在字段6150中所示，可以通过文件上预先写好的合同或电子 合同对给定的顾客约定，这种合同例如可以授权接受的局间电信公司 5820对呼叫方的电话单上的给定呼叫向呼叫方5810收费，或者借助 于向信用卡或其它通用的帐户收费。如以下所讨论，根据本发明可以 通过CPO管理系统5800或本地交换机操作员，代表接受的局间电 信公司5820对呼叫方5810就完成的电话通话开单，或者直接由接受 的局间电信公司5820按传统的方式开单。
在一种实现中，其中CPO对呼叫方5810规定达到对预定时间周 期的最小使用，例如其中呼叫方5810同意花费至少二百美元($200) 在十二(12)个月获得较低的费率，达成的协议能够立即对信用卡收 费，或按月收费。此外，除非呼叫方5810没有满足CPO的责任， 否则不能对信用卡收费。例如，在发生收费时可以对通话向呼叫方 5810直接开单，且其余差额可以在协议期末尾向信用卡帐户收费。 此外，如果在CPO由一个局间电信公司5820接受后呼叫方5810不 同意完成通话，则能够向呼叫方5810收取罚金。
图62示出一示例性电信公司数据库6200，它最好关于与CPO 管理系统5800登记同意向呼叫方提供长途电话服务的每一电信公司 的信息，包括地址信息。电信公司数据库6200保持多个记录，诸如 记录6205-6225，每一记录与不同的电信公司相关。对于列在字段6240 的每一电信公司的名称，电信公司数据库6200在字段6245中包含地 址信息。此外，在给定的电信公司的CPO规则以加密的格式存储， 或者另外需要安全传输的一个实施例中，相关的电信公司的密钥最好 存储在电信公司数据库6200的字段6250中。最后，电信公司数据库 6200最好在字段6255存储已经向每一电信公司要约且实际上已经由 每一各电信公司接受的CPO的百分比的指示。这样，CPO管理系统 5800能够把一特定的CPO按根据CPO承诺率排序的顺序向电信公 司要约。在另一实施例中，电信公司数据库6200能够根据基于以下 条件的顺序组织字段便于CPO的处理(i)由每一电信公司协商的优先 权，或者(ii)由电信公司向CPO管理系统5800支付的最高代理费率。
图63示出一示例性费率数据库6300，该数据库最好存储对每一 在电信公司数据库6200中标识的电信公司存储公布的费率信息。费 率数据库6300保持多个记录，诸如记录6305-6325，每一记录与不 同的电信公司相关。对于在字段6340中标识的每一电信公司，费率 数据库6300最好在字段6345和6350分别包含对应的国内费率和国 际费率。
图64表示一示例性CPO数据库6400，该数据库最好包含正由 CPO管理系统5800处理的每一CPO的记录，包括CPO条款和相关 的状态。CPO数据库6400保持多个记录，诸如记录6405-6425，每 一记录与正由系统5800处理的不同的CPO相关。对于由字段6440 中的CPO号码标识的每一CPO，CPO数据库6400在字段6445包 含CPO收到的日期，在字段6450包含与该CPO相关的顾客的标识(ID) 号码，并在字段6455包含被呼叫的电话号码的指示。呼叫方CPO 的参数存储在CPO数据库6400的字段6460中。CPO数据库6400 最好在字段6470存储呼叫方愿意为通话支付的价格。一旦被接受， 则字段6465指示接受的电信公司，且字段6475记录各CPO当前的 状态，诸如待定、接受、拒绝、或过期。
处理过程
如上所讨论，CPO管理中央服务器6000最好执行如图65a和65b 所示的CPO管理过程6500，以便接收来自呼叫方5810的每一CPO， 向每一适当的局间电信公司5820提供该CPO，并然后确定要约的条 款是否已经由任何局间电信公司5820接受。如图8a所示，例如在通 过CPO管理系统5800的专用小交换机(PBX)业务收到来自呼叫方 5810的呼叫时，CPO管理过程6500在步骤6505期间开始实施本发 明原理的过程。
然后在步骤6510期间，CPO管理过程6500将抽取与入局呼叫 相关的自动号码识别(ANI)号码。然后在步骤6515期间使用记录在字 段6160中所抽取的ANI号码作为顾客标识符在顾客数据库6100中 生成一新的记录。然后，最好在步骤6525期间执行以下结合图66a 和66b要讨论的IVRU过程6600，或者另一顾客接口过程，以便从 呼叫方5810接收CPO的参数，包括被呼叫方5830的电话号码，最 大价格，CPO将被约定的方式，以及任何时间期限及其它适用的限 制。然后在步骤6530期间收到的CPO参数存储在CPO数据库6400， 并通过用户标识符(ANI)的索引后在步骤6535期间提供给适当的 电信公司(图65b)。要注意，通过例如把CPO只提供给能够对呼叫 方5810和被呼叫方5830之间的通话规定路由的电信公司，或者只向 由呼叫方5810指定的电信公司提供CPO，CPO管理系统5800能够 对提供给每一电信公司的CPO过滤。进而要注意，CPO管理过程6500 最好在步骤6530期间对照由任何基于代理的电信公司所提供的CPO 规则评估CPO。
在步骤6540最好从每一电信公司接收对CPO的响应。然后在步 骤6545期间进行一测试以便确定CPO的条款是否已经被一电信公 司接受。如果在步骤6545期间确定定CPO的条款还没有被一电信 公司接受，则最好在步骤6550期间通知呼叫方5810 CPO已经被拒 绝。然后在步骤6560期间程序控制终止之前，在步骤6555期间CPO 数据库6400中的CPO状态变为“被拒绝”。
然而如果在步骤6545期间确定CPO的条款已经被一电信公司接 受，则在步骤6570期间来自CPO数据库6400的详尽顾客记录最好 提供给接受的电信公司，以便电信公司根据由CPO规定的条款完成 通话。要注意，可以由CPO管理系统5800或本地交换机操作员5850 代表接受的局间电信公司5820向呼叫方5810对通话开单，或直接由 接受的局间电信公司5820按传统方式开单。本地交换机操作员5850 通常接收完成通话的总费用的一个百分数。最后，在步骤6580期间 程序控制终止之前，在步骤6575期间CPO数据库6400中的CPO 的状态变为“被接受”。
如以上所指出，CPO管理系统6500最好在步骤6525期间执行 图66a和66b中所示的IVRU过程6600，以便接受来自呼叫方5810 的CPO的参数，包括被呼叫方5830的电话号码、最大价格、及任 何时间期限和其它适用的限制。如图66a所示，IVRU过程6600在 步骤6610期间通过提示呼叫方5810提供被呼叫放5830的电话号码 而开始实现本发明原理的过程。然后在步骤6620期间，交互话音响 应单元(IVRU)捕捉呼叫方5810的响应，并向CPU 6005提供被呼叫 的号码。
然后在步骤6630期间IVRU提示呼叫方5810提供呼叫方5810 愿意为通话支付的价格以及CPO约定的方式，如对信用卡帐户收费， 并在步骤6640期间捕捉响应，向CPU 6005提供通话的最大价格。 然后，在步骤6650期间IVRU提示呼叫方5810提供与CPO相关的 任何其它的限制或规定，例如如果有则包括通话的时间限制，如果有 则包括所希望的一个或多个电信公司，以及CPO待定的时间期限。 然后在步骤6660期间，IVRU捕捉呼叫方5810的响应并向CPU 6005 提供附加的限制或规定。最后，在步骤6680期间程序控制终止之前， IVRU过程6600在步骤6670期间指令呼叫方5810挂机并等待响应(图 66b)。
这样，由CPO管理系统5800接收CPO的限制并然后提供给每 一适当的局间电信公司5820。如果被接受，则局间电信公司将根据 CPO条款完成呼叫方5810和所希望的被呼叫方5830之间的通话， 并责成呼叫方5810向接受的局间电信公司5820支付通话的费用。
在图58A所示的实施例中，希望对被呼叫方5830通话的呼叫方 5810拾起电话机5900并拨打与CPO管理系统5800相关的电话号码。 呼叫最好由PBX交换机或相关的呼叫处理器接收。然后从通话信息 抽取呼叫方5810的电话号码，并用来在顾客数据库6100中访问或生 成一记录。然后呼叫方5810或者被连接到IVRU或者一现场操作员， 以便提供呼叫方5810的CPO的条款，诸如被呼叫的号码及最大价 格。然后最好指令呼叫者挂机并等待响应。
一旦CPO被检索并由CPO管理系统5800处理，它就被提供给 多个电信公司。这时每一电信公司5820-5824例如基于根据网络容量 平衡的一个或多个规则确定是接受或是拒绝该CPO。如果CPO被接 受，则CPO管理系统或接受的电信公司5820通知买方，并通过接 受的电信公司的网络接通通话。如果有与通话相关的时间期限或其它 限制，则最好在通话最初建立时通知呼叫方5810。例如可以通过CPO 管理系统5800、接受的电信公司5820，或通过操纵本地交换机5850 的本地电话公司就通话向呼叫方5810开单。这样，可以个别地对通 话向通用帐户收费，诸如信用卡，或可以借助于呼叫方普通电话帐单 支付。
类似地，在图58B所示的实施例中，希望提交需要在预定的时 间段的电话服务的CPO的呼叫方5810可以使用用户终端5815与CPO 管理系统5800接触。例如CPO能够规定用户愿意为电话服务支付 的费率、合同责任期限长度、以及呼叫方愿意对折扣费率的回报所附 加的任何灵活性或限制，诸如在非高峰期通话及最小花费责任。
一旦CPO被CPO管理系统5800接收并处理，则然后CPO被 提供给多个电信公司。然后每一电信公司5820-5824确定是接受或是 拒绝该CPO。如果CPO被接受，则CPO管理系统5800或接受的电 信公司5820以适当的方式通知买方，并把接受的电信公司5820转接 成呼叫方的长途电话提供商。
用于活动门票的CPO管理系统
现在将参照图67到73g讨论本发明的另一实施例。图67到73 所示的实施例允许买方向一定数目的潜在卖方提交对一定的活动，诸 如冰球比赛的门票的担保购买的要约。卖方可以查看要约，并如果条 款是可同意的则接受要约。这样，买方可以迅速地提交一要约，以便 购买保证安全方便地送达的门票。
以下参照图67-72b，解释本发明的装置和方法的一个实施例的 系统的体系结构。如图67中所示，本发明的装置一般包括一地点控 制器7000、中央控制器6800、信用卡处理器6830及远程用户终端 6900。远程用户终端6900通过网络6845连接到中央控制器6800。
使用以上的组件，本发明的本实施例提供了允许中央控制器便于 活动门票的购买和销售的方法和装置。具体来说，中央控制器6800 接收并公告购买特定活动门票的要约。这种要约是有担保的，例如使 用信用卡帐户上的信用限额。中央控制器6800进而把每一要约提供 给多个潜在的卖方，且允许卖方接受要约并从而形成法律上有约束力 的合同。
如图68所示，中央控制器6800包括中央处理器(CPU)6805、随 机存取存储器(RAM)6815、只读存储器(ROM)6820、时钟6835、输 入/输出(＂I/O＂)端口、及数据存储器装置6850。数据存储器装置6850 是包含活动表格7100、活动地点表7120、顾客表7130、要约表7150、 和交易表7180的存储器装置，以下将分别参照图71a到71e更为详 细讨论。
图71a示出一示例性的活动表7100，该表最好存储有关使用图67 的系统可以转卖其门票的活动的信息，包括位置和时间表信息。活动 表7100维护多个记录，诸如记录7114，每一记录与不同活动相关。 对于列在活动ID字段7102中的每一活动标识符，活动表7100包含 存储在字段7104中的活动类型代码和存储在字段7106中的活动描 述。存储在字段7104中的活动类型代码表示活动的格式，例如，国 家冰球联盟比赛标记为“NHL”。存储在字段7106中的活动描述说 明具体的活动。
活动表7100最好还包含存储在字段7106中的活动地点ID。存 储在字段7106的活动地点ID例如可被用来对以下将参照图71b更 充分说明的活动地点表7120作索引。如图71a所示，存储在活动表 7100中的每一记录还包含存储在字段7110中的日期和存储在字段 7112中的时间。字段7110和7112的日期和时间分别表示与记录相 关的活动开始时间。存储在这一表中的信息可从任何源提供给中央控 制器6800，包括推销商、活动地点和潜在的买方和卖方。
图71b示出示例性活动地点表7120。活动地点表7120的每一记 录，诸如记录7128，最好存储与活动地点相关并说明活动地点的数 据。活动地点7120最好由存储唯一活动地点的标识符的字段7122索 引。活动地点表7120还在字段7124存储剧场、礼堂、或运动场的名 称，并在字段7126存储地址。
图71c示出一示例性顾客表7130，该表最好存储有关对电子门 票销售系统登记了的每一顾客的信息。顾客数据库7130维护多个记 录，诸如记录7146和7148，每一记录与不同的顾客相关。登记在顾 客表7130中的顾客可以购买屏幕、销售门票或既购买又销售门票。 顾客表7130在字段7132对每一顾客存储唯一的顾客标识符，并在字 段7134和7136中存储姓名和地址信息。
保存在顾客表7130中的数据最好由顾客在登记过程中提供，这 时顾客被指定唯一的顾客标识符。
顾客表7130还存储顾客信用卡数据。顾客的信用卡号码存储在 字段7138。顾客的信用卡过期日期存储在字段7140，按出现在信用 卡上的卡持有者的姓名存储在字段7142中。
图71d示出一示例性要约表7150，该表最好存储与使用本发明 的门票销售系统公告的要约相关的信息。要约表7150维护多个记录， 诸如记录7170和7172，每一记录与要购买或销售门票的要约相关。 要约表7150的每一记录包含存储在字段7151中的唯一要约标识符， 该标识符由中央控制器6800在要约公告时指定。要约表格7150每一 记录包含用于标识作出要约的顾客、要约的条件、接受要约的顾客、 及与要约相关的行政信息等字段。
推广要约的顾客的顾客标识符存储在字段7152。使用字段7152 的顾客标识符作为对顾客表7130的索引，易于获得与推广要约的顾 客相关的信息。要约表7150中的每一记录还在字段7153中存储活动 标识符。活动标识符指示所提供的门票相关的活动。使用活动标识符 7135作为对活动表7100的索引，可易于获得有关活动的信息。
要约表7150的每一记录还包括分别存储作出要约的日期和要约 可被接受的最后一天的字段7154和7155。指示要约类型和要约状态 的数据也存储在要约表7150的每一记录中字段7156和7157中。字 段7156存储指示要约是否是一个或多个门票购买的要约还是销售要 约的代码。字段7157存储指示要约状态的代码。要约状态的可能性 包括：待定、有效、过期、及履行。
要约表中每一记录的字段7158存储要约适用的座位。指示与要 约相关的座位分配的数据分布在字段7159-7164。在要约要求座位分 配范围的活动中，存储在字段7159-7161的数据用来标识范围中的第 一座位，而存储在字段7162-7164的数据用来标识范围中的最后的座 位。字段7165存储每个座位的价格。
此外，要约表7150的每一记录在字段7166-7169包含行政数据。 存储在字段7166中的数据存储被授权支持要约的信用量。一旦要约 被接受，字段7167存储可被用作为对交易数据库7180索引的交易标 识符，这以下参照图71e更完整讨论。要约表7150的每一记录可选 地存储对一相关的或链接的要约记录的指针。该指针存储在字段7168 并表示要约表7150中下一个相关记录的要约标识符。最后，要约表 7150的每一记录的字段7169存储卖方想要销售的原始门票的一个或 多个序列号。
一旦要约被接受，中央控制器6800就向交易表7180添加一交易。 图71e示出一示例性交易表7180，该交易表格最好存储有关每一接 受的要约的信息。对每一被接受的要约指定一唯一的交易标识符，该 标识符存储在交易表7180的字段7181中和要约表7150的字段7167 中。要约表7150中相关记录的要约标识符存储在字段7182中。这一 要约标识符可用作为对要约表7150的索引以便检索关于与交易记录 相关的要约的信息。
交易表7180的每一记录最好还包括存储相关要约被接受的日期 的字段7183，以及存储交易总值的字段7184。字段7185存储向买方 信用卡收费量；字段7186存储保留的卖方信用限额量的量以支持承 诺；且字段7187存储对于处理交易的收费；交易表7180的每一记录 还在字段7188存储一日期，指由控制器6800的操作者收到门票的日 期。
卖方的顾客标识符存储在字段7189，表示门票的数据存储在字 段7190和7194。字段7190存储原始门票号码，而字段7194存储新 的门票号码。分配新的门票号码以区分卖的门票和原始门票，并有助 于门票持有者之间潜在的冲突的有效解决。
中央控制器6800可选地包含合同细节表(未示出)，它包括在不 同时间中央处理器6800检索和向用户传输的表格合同条款。例如， 合同表可以包括传输给买方并并入担保购买要约的合同条款。合同表 还可能包括在请求认可这一意向以约定买方的要约并生成一有法律约 束力的合同之前，传输给卖方的合同条款。这些表格条款有效地填补 了由买方规定的条件之间的缝隙，规定了这一性质的大多数合同共用 的一般合同细节。
现在参见图69将更为详细说明远程用户终端6900。远程用户终 端6900可以是顾客可通过其访问中央控制器6800的个人计算机、可 视电话、单独的公用电话、或任何其它装置。远程用户终端6900一 般包括控制远程用户终端6900操作的中央处理器(＂CPU＂)6905。CPU 6905以电子的方式连接到随机存取存储器(＂RAM＂)6915、只读存储 器(＂ROM＂)6920、输入/输出端口6925、时钟6935、及通信端口6940 和数据存储器装置6960。CPU 6905以输入/输出端口6925和诸如键 盘这样的输入装置6945接收来自远程用户的输入。CPU 6905通过输 入/输出端口6925和视频监视器6930向远程用户传输输出。此外， 通信端口6940提供到网络6845的通信。最后，数据存储器装置6960 是包含中央控制器接口软件6965的存储器装置。
现在参见图70将更为详细说明活动地点控制器7000。活动地点 控制器7000一般包括控制活动地点控制器7000的操作的中央处理器 (＂CPU＂)7010。CPU 7010以电子的方式连接到随机存取存储器 (＂RAM＂)7020、只读存储器(＂ROM＂)7030、时钟7040、提供到中央 控制器6800通信通路的通信端口7050、及数据存储器装置7060。数 据存储器装置7060是一持续存储器装置，包含门票表7210和替代门 票表7230。活动地点控制器7000还包括用于输入数据的输入装置7080 及用于向操作者呈现和显示信息的输出装置7070。
图72a示出示一例性的门票表7210，该表最好存储关于在一具 体活动地点对各个座位发出的门票的信息。每一门票具有由活动地点 控制器7000在发出之前指定给该门票的具体的门票号码。门票表7210 的每一记录最好包括标识该门票对其有效的活动的字段7211，说明 对各票分配的号码的字段7212，及表示在礼堂中座位的位置(即各区、 排、和座位)的字段7214-7220。门票表7210还可能包括表示活动地 点、活动或座位特有的其它信息的字段。
图72b示出一示例性替代门票表7230，该表最好存储有关原始 门票号码的数据，该号码已经无效并存储被指定替代的门票号码。替 代门票表7230在字段7232存储已经由中央控制器6800转卖的门票 号码，并在字段7242存储替代的门票号码。门票表7230的每一记录 还包括存储数据标识符的字段7231和存储买方标识符的字段7240。
一般的专业人员将能够看出，本发明能够在没有所示分布式体系 结构的情形下构成并操作。如果活动地点和门票分发者希望这样，这 样控制器6800能够装有所有的或部分的地点控制器7000的数据库， 并进行由活动地点控制器7000在本实施例中所进行的所有的或部分 的处理步骤。在这种替代的实施例中，数据处理和数据存储能够被集 中进行，并在适当使用通常的远程终端或工作站时活动地点能够访问 数据。
在本发明的一个实施例中，潜在的买方和卖方之间的通信是通过 诸如因特网这样的电子的或数字网络进行的，以中央控制器6800作 为因特网web站点的主机，用户能够借助于个人计算机访问或“登 录”到该主机。重要的是要注意，用户能够通过其它通信链路诸如连 接到语音响应单元(＂VRU＂)的普通电话线路访问中央控制器。
为了使用门票转卖服务，作为潜在买方的用户通过网络6845登 录到中央控制器6800，生成并提交担保的购买要约，并从网络6845 断开连接。在一个实施例中，担保的购买要约是有法律约束力的要约， 以便购买由预授权信用卡交易支持的门票。在接收要约时，中央控制 器6800与买方的信用卡发放者接触以确认买方具有有效的信用卡帐 户和/或足够的信用对所需的门票支付。然后通过使用与中央控制器 6800链接的web站点公告要约，能够使潜在的卖方获得担保的购买 要约。通过中央控制器6800进行周期的维护，以保证“有效”的要 约不至过期。潜在的卖方能够使用本发明的系统浏览要约并提交所希 望的要约的电子承诺。潜在的卖方的承诺以电子方式传输给中央控制 器6900。中央控制器6800处理该承诺并与卖方的信用卡发放者接触 以确认有足够的信用函盖潜在的未履约罚金。这种卖方信用的保留是 要鼓励各方之间诚信，从而保护交易。在检验了可用的信用之后，通 知双方约定交易，并以电子方式使门票无效而指定一替代门票号码。 然后要求卖方交出无效的门票。这可通过把它们返回活动地点而完 成，或卖方可以把门票邮寄到中央控制器6800的操作者。在接收交 出的门票时，中央控制器6800的操作者把要转帐的支付导向给出售 门票的卖方。
现在将参照图73a说明用户登录并开始使用本系统的过程。如步 骤7300的中所示，操纵远程终端6900的用户通过网络6845建立与 中央控制器6800的连接。用户可以是希望发布对门票担保购买要约 的买方，或者是希望查看门票要约的潜在的卖方。
在步骤7302，中央控制器6800从用户请求顾客的ID。在步骤 7304，中央控制器6800基于用户是否已有顾客ID确定如何继续进 行。如果用户对这一服务登记，并想起他的顾客ID，则在步骤7312 他将其ID传输给中央控制器6800，且过程以步骤7314继续进行。
另一方面，如果用户没有对服务登记，或不记得他的顾客ID， 则他必须在步骤7304提交负的响应，并如步骤7306所示向中央控制 器6800提交相关的顾客信息。在步骤7308中央控制器6800基于收 到的顾客信息生成顾客的记录。包括姓名、地址、信用卡和号码、期 限和出现在信用卡上的姓名的这一信息存储到顾客表7130。在步骤 7310，中央控制器6800把由用户提供的信息与顾客表7130中已经存 储的信息进行比较。如果发现匹配，则中央控制器6800从顾客表7130 的字段7132检索顾客ID，并把顾客ID号码传输给用户。这一服务 提供给先前已给出信息，但是未记得他的顾客ID号码的用户。如果 发现不匹配，则中央控制器6800向用户指定一新的顾客ID号码， 把它存储在顾客表7130的字段7132中，并向顾客传输该号码。
在步骤7314，用户指出他是否愿意提交担保的购买要约，或查 看来自潜在买方的要约。参照图73b-73c更为充分地说明了与提交要 约相关的过程步骤。参照图73d-73g更为充分地说明了与查看要约相 关的过程步骤。在另一实施例中，用户还能够选择对一定的活动向潜 在的买方广告门票的可得性。此外，用户能够选择查看这种广告，以 便在提交要约之前对好的价格可能如何有更好的理解。
图73b-73c示出在步骤7314用户选择之后所执行的过程步骤， 以提交一担保的购买要约。在步骤7316，中央控制器6800向用户终 端6900传输活动地点和活动的一般信息，以便显示给用户。例如， 在一个实施例中，中央控制器6800可以向用户提供数个选项以便确 切定位用户希望出席的具体的活动。用户可直接请求具体的活动，或 通过一组狭窄的选择最后找到所需的活动。例如可以要求用户确定来 自活动表7100的任何字段。取决于所提供的信息量，活动的选择将 被随之限定。例如，如果用户只提供了活动类型(例如“NHL”)，则 中央控制器6800将扫描活动表7100并提供在活动类型字段7104中 找到的所有匹配。这可能是一长的活动列表，然而，中央控制器6800 可能提示用户提供更多的信息以收缩列表。然后用户可以从收缩的列 表中选择以找到他正在寻找的活动。例如，用户可以规定特别的百老 汇作品星期六白天的表演以收缩列表。然后中央控制器6800提供给 用户正确的活动信息，包括来自活动表7100字段7102的活动ID。 用户把这一活动ID作为他们的担保购买要约的一部分纳入，使得它 能够由中央控制器在要约表7150中跟踪。
然后在步骤7318，用户基于活动ID号码选择所需的活动。在步 骤7320，中央控制器6800从用户请求与要约相关的一定的信息，诸 如
(1)所需门票的号码；
(2)每一门票的价格；
(3)所希望每一门票的位置；
(4)可选地，要约有效的日期。
用户基于门票的具体位置，指出他希望要的门票的号码及他愿意 花费的价格。用户可以使用活动地点的图象表示，选择对应于他愿意 支付的价格的座位的确切位置。例如，基于活动地点ID号码(存储在 活动地点表7120的字段7122)，中央控制器6800从存储器检索该具 体的活动地点座位的图象表示，并提供给远程终端6900的用户。在 一个实施例中，中央控制器6800先提供整个活动地点泛泛的一般的 轮廓(例如由区域显示)。然后用户能够能够点击具体的区域收缩其对 确切座位的搜索。随着后继的选择点击，用户终端6900处的显示屏 把显示的座位范围收缩直到用户找到他所需的座位。然后用户能够选 择对应于购买要约的成组的座位。中央控制器6800在要约表7150的 字段7159-7164存储所选择的座位。如果用户更希望选择一个区或多 个区而不是一个具体的座位，则他可以输入选择的范围。然后中央控 制器6800只需使用区字段7159和7162存储这一较宽的选择，并把 其它四个字段留空。
此外，用户可以提供表示要约过期日期的终结日期。如前所讨论， 中央控制器6800周期地查看这一终结日期，并一旦经过这一日期， 就把要约表7150的字段7157中要约的状态变为“过期”。
在步骤7322，中央控制器6800接收由用户传输的要约信息，并 如步骤7324所示，中央控制器6800生成要约表7150的要约记录。 在步骤7328，询问用户他是否想要作出另外的要约。在这点，如果 用户希望对分开的活动作出一要约，他可以通过在步骤7316-7324所 讨论的过程进行。然而如果用户希望作出与先前提供的要约相关的、 或者连带的要约，则他们可以如下这样作。首先，在一个实施例中， 他们提供如步骤7318那样相同的活动ID。然后，在提供了与先前所 讨论的相同的一般信息之后，用户指示这一要约是连带的。然后，中 央控制器指定对起初的要约生成的要约ID号码作为对相关要约的连 带ID号码，并存储在要约表7150的连带ID字段7168中。
用户可以基于所需座位的类型提供连带要约。例如，用户可以选 择具体活动地点中的“高质量”座位的号码，并开出较高的购买价格。 连带要约将包括对具体活动地点的“较低质量”座位，大概按较低购 买价格。这样基于连带ID，潜在的卖方将在他们查看期间一同考虑 两种要约。
而且与同一活动相反，用户可以把两个分开活动的要约连接起 来。例如，用户不是连接基于座位选择和价格的要约，而是可能更愿 意出席本地区域的两个活动之一，但不是两个。这样，他可能把这些 要约链接，使得潜在的卖方能够知道要约是针对“或这/或那”提议 考虑的。
中央控制器6800对要约ID字段7151中的每一要约指定一要约 ID号码，并对连带ID字段7168中的连带要约指定这号码作为连带 ID号码。而且，要约日期字段7145以指示要约公告时的时间印记(例 如日期和时间)公布。然后，中央控制器6800向状态字段7157指定 值“待定”。这一值在收到来自用户信用卡发放者的授权时将变为“有 效”。进而，中央控制器6800计算授权量，并将其存储在授权量字段 7166中。授权量字段表示被保留“支持”要约并实际上等于总交易 量的用户的信用量。通过保留用户的信用部分，能够对门票卖方和门 票服务担保，如果要约被接受他们将收到支付。在要购买连带要约的 情形下，授权量是连带要约的最高交易量。当连带要约被接受时，系 统自动地认为所有相关的要约被收回。最后，中央控制器6800在要 约表7150的各个字段存储由用户提供的所有信息，包括基于活动地 点的图象表示的座位位置。
在步骤7330，中央控制器6800从合同细节表(未示出)抽取法律 合同用语，并传输给用户终端6900的用户。这一用语描述了提供购 买要约的法律含义，并且该过程类似于在签署一书面合同之前查看条 款。如果用户选择不遵守这些条款，他可以取消要约。然而，如果用 户选择遵守这些条款，则用户向中央控制器6800传输正面确认，并 在法律上被约定到担保的购买要约的条款。
然后在图73c中，在步骤7332中央控制器6800与用户的信用卡 发放者接触以接收对要约的授权。首先，中央控制器6800基于来自 要约表7150的顾客ID从顾客表7130收集用户的姓名、地址、信用 卡类型、信用卡号码、及过期日期。这一信息连同来自要约表7150 的字段7166的授权帐户，通过信用卡处理器6830一同传输给信用卡 发放者。
在步骤7334，中央控制器6800通过信用卡处理器6830从信用 卡发放者接收授权或者拒绝。由于任何数目的原因信用卡发放者可能 拒绝请求，包括过期的卡、超过信用限，或者支付失约。在拒绝时， 在步骤7336中央控制器6800把这一拒绝通知在用户终端6900的用 户，并请求另外的信用卡信息。另外，用户可以传输对应于另外的信 用卡的信息，该信息补充或代替在顾客表7130中他现在的信息。如 果提供了另外的信用卡信息，则重复步骤7332以便接收对收费的授 权。当通过信用卡处理器6830从信用卡发放者接收授权时，中央控 制器6800更新要约表7120，包括改变状态字段7157为“有效”以 确认公告的要约。
图73d-73g示出基于用户在步骤7314的选择所执行的处理步骤。 在步骤7340，中央控制器6800用户终端6900传输一般的活动地点 和活动信息以便显示给用户。如先前在步骤7316所讨论的，中央控 制器6800可以向用户提供数个选项以标识用户希望查看的确切的活 动。最后，中央控制器6800向用户提供来自活动表7100字段7102 的活动ID。在步骤7342，用户向中央控制器6800提供活动ID，这 样它可以识别在要约表7150中相关的要约。
在步骤7344，中央控制器6800识别与所选择的活动ID相关并 具有“有效”状态的要约记录。中央控制器6800把这一数据传输给 用户终端6900以向用户显示。用户可以对具体活动一同查看所有的 要约，或每次查看一个。在一个实施例中，用户可以通过活动地点的 图象显示查看各每一要约，以便确切地确定买方需要哪里的座位。在 某些情形下，要约可以是对整个活动场所任何地方的座位。另些情况 下，要约可以只是对于区段、行或座位的特定范围。在一个实施例中， 用户可能能够输入他们的确切的门票信息以确认其是否满足要约的要 求。
如以上所讨论，在向用户呈现时连带要约将被适当地识别。这种 情形下，中央控制器6800允许相关的连带要约同时被查看，使得用 户能够比较从单个买方提交的有条件要约。
然后，在步骤7346，中央控制器6800接收或是一接受特定要约 的请求，或是一查看其它活动要约的请求。在后一种情形下，将重复 步骤7340、7342和7346。应当注意，用户可以在接受要约之前任何 时候退出系统。
在用户传输接受特定的要约请求之后，在步骤7348用户向注意 控制器6800传输原始门票号码和座位位置(即区段、行和座位)。在 接收来自用户的这一信息时，中央控制器6800在步骤7350向活动地 点控制器7000传输原始门票号码和座位位置，以便检验门票的真实 性。
现在参见图73e，在步骤7352活动地点控制器7000从门票表7210 检索与在步骤7350通过中央库存6800传输的门票号码匹配的记录。 在步骤7354和7356活动地点控制器7000检验所传输的门票号码是 否与所传输的座位位置匹配。如果所传输的门票和座位位置不匹配， 则在步骤7358，活动地点控制器7000向中央控制器6800传输一无 效的组合消息。然后在步骤7360中央控制器6800向用户终端6900 传输一消息，指出门票号码与座位位置是无效的组合。在用户终端 6900接收该无效组合消息时，用户能够在步骤7370重新向中央控制 器6800提交门票和座位位置。然后过程转回步骤7350。如果门票号 码和座位位置组合有效，过程继续进行步骤7372。
在图73f的步骤7372，中央控制器6800向用户终端6900传输向 销售其门票的用户显示的合同语言。如前面所指出的，这一合同语言 可存储在合同细节表(未示出)中。这一语言描述了接受担保购买要约 的法律含义，且该过程类似于在签署一书面合同之前的查看条款。如 果出售其门票的用户选择了不遵从这些条款，则用户可以删除其承 诺。然而，如果用户选择了遵从这些条款，则用户向中央控制器6800 传输正面的确认，并在法律上约定到该承诺。
然后中央控制器6800在步骤7376与用户的信用卡发放者接触以 接收对该承诺的授权。基于在步骤7306从用户收集的和存储在顾客 表7130中的要约信息和信用信息，中央控制器6800请求来自信用卡 发放者的授权以保留用户信用的一部分。这一信用的保留是制止欺骗 并可用作为在卖方没能送达门票的情形下的罚金。这种罚金形成了买 方的信心，并对购买门票的用户提供了保证，即销售门票的用户实际 上将会出让该门票。如果出售门票的用户企图违反协议，则罚金可以 付给购买门票的用户。这一罚金可以按数种方式确定，包括对出售门 票的用户征收统一的罚金，或征收等于由购买门票的用户要约总量的 罚金。
在步骤7374，中央控制器6800从销售门票的用户收集信息。基 于从要约表7150检索的顾客ID，该信息可能包括来自顾客表7130 的用户姓名、地址、信用卡号码和过期日期。这一信息与来自要约表 7150字段7166的授权量一同通过信用卡处理器6830传输给信用卡 发放者。
在步骤7376，中央控制器6800通过信用卡处理器6830或者接 收或者拒绝来自信用卡发放者的授权。信用卡发放者可以由于任何原 因拒绝请求，包括过期的卡、超过卡的限量、或制止支付。当拒绝时， 在步骤7328中央控制器6800把拒绝通知给用户终端6900的用户， 并请求替代的信用卡信息。用户可能传输与稍早时提供的相同的信用 信息，因为稍早时用户可能误传输了不正确的信息。另外，用户可能 传输对应于替代的信用卡的信息，该信息将补充或替代顾客表7130 中的信用卡信息。而且，用户可能整个删除交易。如果提供替代的信 用卡信息，则重复步骤7374以便接收对收费的授权。
如果中央控制器6800通过信用卡处理器6830从信用卡发放者接 收授权，则过程以步骤7380继续进行，其中中央控制器6800对销售 产生并指定交易ID。这一交易ID存储在要约表7150的字段7167中。 进而，中央控制器6800在交易表7180中生成由指定的交易ID索引 的一新的记录。该指定的交易ID还存储在交易表7180的字段7181 中。交易表7180的原始门票号码7190字段以来自销售门票用户的正 确的门票号码填充。此外，中央控制器6800使用指示承诺被公布的 时间的日期字段7183对该承诺打上时间印记。
一旦担保的购买要约被接受，中央控制器6800使用来自字段7152 的顾客ID作为进入顾客表7130的索引，以便检索购买该门票的用 户。在步骤7382，中央控制器6800向活动地点控制器7000传输购 买该门票的用户的姓名。
在步骤7384，活动地点控制器7000在替换门票表7230中生成 一新的记录。该新的记录以指示买方的姓名、原始门票号码、门票的 区段、行和座位的信息填充。如步骤7386所示，新记录还以由活动 地点控制器7000指定的替换门票的号码填充。然后替换门票号码传 输给中央控制器6800。
一旦中央控制器6800已经从活动地点控制器7000接收替换门票 号码7242，则中央控制器6800在步骤7388就更新交易表7180的新 门票号码字段7194。在步骤7390，中央控制器6800确定应支付额并 对购买门票的用户的信用卡收费，即门票的价格加上手续费7187。 中央控制器6800还以收取的数额更新交易表7180的字段7185。最 后，中央控制器6800以接受要约的用户的卖方ID更新字段7189， 并在卖方试图使用其已售出的门票的情形下，中央控制器6800以卖 方的授权数额更新字段7186。字段7184是基于对买方收取的不含手 续费7187的数额7185被更新的。虽然本实施例的费用表示为存储在 表中，但这种费用可易于计算而不是从表中检索。
在步骤7392，中央控制器6800向用户终端6900传输一消息通 知销售门票的用户，只要中央控制器6800收到原始门票已经被交出 的证实，则将以门票的销售数额记入其信用卡帐户。
在步骤7394，中央控制器把替换的门票号码7292和消息传输到 购买门票的用户，指出其担保的要约已经被接受。然后在步骤7396 购买门票的用户可以打印替换的门票号码，把该门票带到活动地点并 使用它获得对所需活动的访问。取消原始号码并发出附有购买用户姓 名的替换的门票号码，以防止门票的卖方和/或购买者的欺骗行为。
例如，如果卖方持有一门票到达活动地点，且购买者持有相同座 位的替换的门票也到达相同的活动地点，则活动地点控制器能够被访 问以确定哪个门票是有效的。只要替换门票在活动地点控制器7000 的替换门票表7230中登记，则替换门票总应替代原始门票。如果这 种欺骗行为是由卖方试图进行的并被中央控制器6800检测出，则中 央控制器能够对卖方的信用卡帐户收取在交易表7180字段865中授 权的卖方的数额。
作为另一例子，如果两个人持有相同的替换门票到达活动地点， 则能够访问活动地点控制器，基于替换门票表7230的新的买方姓名 字段7240的内容而确定合法的拥有者。防止欺骗行为的这些措施将 保证在使用中央控制器6800购买和销售门票时不会发生问题。
最后，在步骤7398，中央控制器6800接收已经从卖方那里收到 原始门票的证实，并以交易额7184计入销售门票的用户的信用卡帐 户。中央控制器进而据此更新门票收到日期字段7188。门票的交出 最好通过把门票投送到活动地点的预定销售窗口而完成，然而其它的 交出方式也是可行的，诸如通过邮政服务或联邦快递。一旦门票已经 交出且交易完成，中央控制器6800把要约表7150的状态字段7157 更新为“完成”以便跟踪之用。在收到交出的门票时，中央控制器6800 对出售门票的用户帐户计入款项。
虽然交出原始门票优选的方法是使用邮件或其它投送机制，但许 多代替的实施例也是可行的。使用一种替换的实施例，门票的兑现能 够在购买的要约不可改变地被接受时推断完成。另一实施例采用能够 被物理上替换的活动门票以使它们无效或作废。每一门票包含预先打 印在门票票面上的唯一的门票号码，但是通过诸如模糊的乳胶涂层这 样的可刮除的覆盖使其隐藏起来。在可刮除的覆盖被除去之前，门票 的持有者是不知道门票号码的。
在承诺时，指令处理门票的卖方除去每一被出售的门票上门票号 码的覆盖。把门票号码提供给中央控制器6800以检验门票的卖方实 际上具有有效的门票。然后对交易中涉及的每一门票提供的门票号码 以电子方式作废，并如前所述指定一替换门票号码。
展现门票号码的行动不仅是为了检验门票卖方拥有门票，而且还 消除了需要卖方交出门票，因为可刮除的覆盖的除去使门票作废。虽 然这一替换的实施例需要对活动门票添加结构，但它不需要保留卖方 信用限额的一部分作为对没能返回未使用的门票的罚金。
现在将使用填充各图的各字段的数据说明本发明的一示例性实施 例。要约表7150的记录7172是如类型字段7156所指出的购买的担 保要约，该要约是由顾客ID字段7152所标识的用户4000已经提交 的。由顾客表7130中的记录7148表示的用户4000是居住在101 Pink Ave，Norwalk，CT的Sue Black。提交给中央控制器6800的信用卡 号码是Discover卡号码4444-4444-4444-4444，9/02过期，发给Susan Black。
在要约表7150的记录7172中，Sue Black已经公告了以活动地 点第一区第一行每张门票$200,00购买到如活动ID字段7153所标记 的活动ID E001的担保要约。正如由活动表7100的记录7114所标记 的，活动E001为一NHL比赛，如活动地点ID字段7108所标记的， 具体为NJ Devils对New York Rangers，发生在5/6/97下午7：30在 “MSG”。活动地点表7120的记录7126标识MSG为在New York， NY的Madison Square Garden活动地点。
除了这一担保购买要约之外，Sue Black还公告了由连带ID字段 7168标记的连带要约。这一连带要约具有ID代码0333。要约表7150 的记录7170具有要约ID 0333，并从而是与记录7172连带的要约。 记录7170是由Sue Black购买到HNL比赛NJ Devils对New York Rangers的四张门票的要约，具有与记录7172的要约请求相同的日 期和时间。在记录7170中，Sue Black指出她将为活动地点第一区第 一行四张门票的每一张支付$250。因为要约7170与要约7172连带， Sue Black已经指出她将愿意要两个要约其中的一个。
要约表7150的字段7166指出已经由Discover为帐户4444-4444- 4444-4444对两个由Sue Black提交的记录7170和7172授权$1,000。 如果它们之一被履行，则$1,000是Sue Black的要约能够使她花费的 最高可能的数额。
对于记录7172，交易ID字段7167已经以交易ID填充，指出买 方已接受Sue Black的购买的担保要约。记录7172的状态字段7157 记录了要约已经被履行，并且状态字段7170过期，由于它与记录7172 的连带方式指出，如果一个被满足，则另一个应当放弃。
交易表7180的记录7195说明了交易TR001的细节，这一交易 是由卖方ID字段7189指示的卖方2000对Sue Black购买的担保要 约的承诺。
顾客表7130的记录7170指出，具有由顾客ID字段7132指示的 ID号码2000的顾客是居住在456 Red Drive，Atlanta GA的Jill Janson，并有主卡号码2222-2222-2222-2222，对中央控制器登记的 过期日期为9/99。
记录7195指出，对她购买活动的行1、座位1的座位003和004 在5/2/97向Sue Black收费$420，该活动与要约表7150中她的担保 购买要约的记录相联系。记录7195还指出，Jill Janson已经出售存 储在原始门票号码字段810的她的原始门票号码667913和667914， 区段001，行001，及座位003和004。卖方数额授权字段7185存储 $400，该数额是在Jill Janson不忠实其出售她的门票的协议的情形 下，由主卡从帐户2222-2222-2222-2222对中央控制器6800授权给借 方的。如果使用她的新的门票号码访问活动地点有问题，则这一数额 的全部或部分计入Sue Black。
收到门票日期字段7188对这一记录是空的，指出中央控制器6800 还没有收到Jill Janson已经交出她的门票的验证。一旦中央控制器 6800收到Jill Janson已经交出她的门票的验证，Jill Janson的信用 卡帐户将被计入存储在交易帐户字段7184中的数额$380。
中央控制器6800已经向Sue Black发出两个座位的替换门票号 码。这些替换门票号码存储在字段7194。Sue Black最好打印出这些 替换的门票号码，并携带这些号码到活动地点赢得对活动的访问。
门票表7210的记录7222和7224存储与发给Jill Janson的原始 门票相关的信息。替换门票表7230的记录7244和7246存储由中央 控制器6800发给Sue Black的替换门票号码，这些号码替换给Jill Janson的原始门票号码。这些记录由活动地点控制器7000存储用于 发生如前面所描述的欺骗行为情形。
重要的是要注意，在以上所描述的实施例中，卖方和买方双方的 通知都是通过接触他们各自的远程用户终端进行的。这一通知还能够 使用包括但不限于电话、传真、电子邮件及寻呼机等传统技术进行。
除了本发明的担保要约和承诺系统之外，本实施例还适用于门票 转卖的其它方面。例如，本实施例能够包含对一定活动或门票的登记 过程。这种过程将使预期的门票买方能够建立可通过中央控制器6800 实现的门票守候。中央控制器6800能够周期地轮询要约以确定是否 有可得的特别的门票。可得性可以通过传统的电话线路、电子邮件、 传真或寻呼机传输给用户。通知偏好可以由用户在登记过程期间确 定。
适用于本实施例的门票转卖的另一方面是广告。系统不是简单地 允许用户提出、查看、接受要约，而是能够提供与活动和门票相关的 广告。
CPO和第三方输入管理系统
现在参照图74到82将讨论本发明另一实施例的方法和装置，它 允许卖方根据来自第三方与要约相关的信息评估来自买方的要约的可 承诺性。虽然为了示例的目的，以下结合图74到82的说明采用了与 金融相关的实施例，但是业内专业人员将能够理解，本发明的范围不 限于此。于是以下的说明中，卖方和买方可分别称为出借者和借入者。
参见图74，用于处理产品销售的系统7410包括中央控制器7412， 该中央控制器通过因特网或其它适当的通信网络与借入者终端 7414、第三方7416和7418、及出借者终端7420、7422和7424通信。 所示的借入者终端、第三方和/或出借者终端的数目是示例性的，而 不是限定。业内专业人员应当理解，任何数目的借入者终端、第三方 和/或出借者终端可以与本发明可替换的各实施例中的中央控制器 7412通信。
借入者终端7414一般是用于产生并向中央控制器7412传输信号 的一计算机或其它装置。借入者终端理想地是通常的个人计算机，诸 如基于Intel 80386微处理器与调制解调器或其它远程通信装置连接 的个人计算机。希望购买产品(货物或服务)的顾客操作浏览器终端 7414以便向中央控制器7412传输包含至少一个条件的信号的要约信 号。要约信号定义具有来自顾客的至少一个条件的有条件购买要约。
本实施例中，顾客是希望获得贷款的“借入者”(即他希望“购 买”贷款)。因而，要约信号定义一为获得贷款的要约。如以下详细 的说明，要约可以包括任何各种各样条件，并于是要约信号包括一个 或多个规定借入者所希望的条件的条件信号。例如，借入者可能希望 对贷款特定的按月支付量和/或具体的利率。
浏览器终端7414还向中央控制器7412传输用于规定可从其支付 资金的通用帐户的支付标识符信号。支付标识符信号例如规定信用卡 号码或借入者拥有的帐户的支票帐户号码。
如果借入者没能执行(履行)其购买的要约，则支付标识符信号通 过标识要被支付的资金用来有效地“约定”借入者。从而支付标识符 对潜在的出借者保证要约是真诚的和有约束力的。例如，如果借入者 违约，则可以使用支付标识符收集足够的资金以抵销在处理借入者要 约中出借者的费用。要收集的规定资金量或者能够通过中央控制器 7412设置，或者留给出借者自行处理。
在另一实施例中，即使借入者履行了他的要约，支付标识符能够 另外用来收集其它的费用。例如，支付标识符可用来收集交易费或甚 至按月贷款支付。
如果出借者操作出借者终端接受要约，从而引起处理该要约的费 用，则向出借者保证他(i)可以把贷款出售给借入者，如果借入者能够 满足贷款条件；或者(ii)如果借入者没能遵守要约条款(例如，借入者 没能履行借贷)，则出借者从支付标识符信号规定的帐户收集支付的 罚金支付。在这两种情形下，对出借者保证了要约的承诺将产生资金， 并这样要约的承诺不会如同在其它用于处理产品销售的系统那样有风 险。
如上所述，为了确定是否接受要约，卖方常常需要有关来自第三 方的要约的信息。例如，来自借入者的要约信号不会被出借者评估和 接受，除非出借者知道借入者的信用历史或信用记分。于是，系统7410 包括第三方7416和7418，用于向中央控制器7412提供信息信号。 信息信号最好定义以下的信息(i)该信息不应当由买方查看和/或改 变；和/或(ii)该信息对确定要约的有效性和/或值是必须的。第三方7416 和7418例如可以是向中央控制器7412提供有关借入者信用信息的信 用报告机构，以及评估由借入者提交的借贷担保的价值的评估者。
中央控制器7412接收并存储传输的要约信号、支付标识符信号 和信息信号。如以下详细的描述，这些信号存储在几个数据库中，从 而便于查询和检索数据库中表示的数据。中央控制器7412使用存储 的信号允许任何出借者终端7420、7422及7424接受要约，如果要约 被认为是适当的。
如果出借者终端接受要约，则借入者被约定遵守要约的条款。如 果借入者没有，例如如果借入者没有签署必要的贷款文件，则中央控 制器7412启动支付标识符信号的使用以收集资金。例如，中央控制 器7412可以向出借者终端传输支付标识符，从而允许出借者收集资 金。另外，中央控制器7412本身可以使用支付标识符信号收集资金。
中央控制器7412能够以各种方式管理要约的承诺。在以下所述 的实施例中，接受一要约能够包括(i)向出借者终端传输要约信号，并 转而从出借者终端接收承诺信号，或者(ii)比较要约信号与卖方规则， 并确定要约是否满足任何规则。
图75a示出一中央控制器7530，这是当接受要约包括从出借者 终端接收承诺信号的步骤时所使用的中央控制器7412(图74)的一实 施例。中央控制器7530包括中央处理器7531、诸如一个或多个普通 的微处理器，及存储器装置7532，诸如与中央处理器7531连接的 RAM、软盘、硬盘或它们的组合。中央处理器7531和存储器装置7532 每一个可以是(i)完全位于单个的计算机内部；(ii)通过远程通信链路 与之连接，诸如串行端口电缆，电话线或射频收发器；或者(iii)它们 的组合。例如，中央控制器7430可能包括一个或多个与用于维护数 据库的远程服务器计算机连接的计算机。
存储器装置7532存储(i)用于根据本发明并特别是根据以下详细 说明的过程控制中央处理器7531的程序；(ii)用于维护提交要约的每 一借入者上的信息的借入者数据库7534；(iii)用于维护关于可能接受 要约的每一出借者信息的出借者数据库7536；(iv)用于规定提交给中 央控制器的每一要约的要约数据库7538；(v)用于存储描述信用价值 的信息信号的信用报告数据库7540；(vi)用于存储描述用于与要约连 接的附属担保信息信号的附属担保数据库7542；以及(vii)用于规定由 中央控制器接收的每一承诺的响应数据库7544。
程序7533还包括必要的程序元素，诸如用于与计算机外围装置 接口的“装置驱动程序”。适当的装置驱动程序和其它必要的程序元 素业内的专业人员是熟知的，并在此无需详述。每一数据库7534、 7536、7538、7540、7542及7544将在以下详细说明。
图75b示出中央控制器7560，这是当接受要约包括确定要约是 否满足任何出借者规定的规则的步骤时所使用的中央控制器7412的 一个实施例。中央控制器7560包括中央处理器7561和与中央处理器 7561连接的存储器装置7562。中央处理器7561和存储器装置7562 可以按类似于图75a的中央处理器7531和存储器装置7532的方式实 现。
存储器装置7562类似地存储(i)用于根据本发明控制中央处理器 7561的程序7533；(ii)用于维护提交要约的每一借入者上的信息的借 入者数据库7534；(iii)出借者数据库7536；(iv)要约数据库7538；(v) 信用报告数据库7540；(vi)附属担保数据库7542；以及还存储(vii)用 于存储对于接受要约出借者规定的规则的规则数据库7564。程序7533 和数据库7534、7536、7538、7540、7542的功能如上所述，而规则 数据库7564将在以下详细说明。
参见图76，图75a和75b的借入者数据库7534存储示例性记录 7670和7672，这每一记录对应于提交要约的借入者。每一记录存储 由中央控制器7412(图74)产生并唯一标识由借入者所作的要约的要 约标识符7674。每一记录还存储借入者的姓名7676、地址7678及电 话号码7680。
参见图77，图75a和75b的出借者数据库7536存储示例性记录 7790和7792，其每一记录对应于接受要约的出借者。每一记录存储 一出借者标识符7794，该标识符由中央控制器7412(图74)产生并唯 一标识一出借者、以及出借者的姓名7796、地址7798及电话号码 7800。
参见图78，图75a和75b的要约数据库7538存储示例性记录 7810、7812和7814，这每一记录对应于收到的要约。每一记录存储 要约标识符7816，它(i)唯一标识一要约，并(ii)对应于图76的借入者 数据库7534的要约标识符7674之一。每一记录还存储收到要约的日 期7818和时间7820，及要约的条件，诸如贷款量7822、每月支付 7824、贷款条款7826和贷款利率7828。每一记录还具有过期日期7830 和过期时间7832，在该日期和时间后要约不能被接受。在其中出借 者希望知道例如所需的贷款是否被担保的实施例中，还存储贷款类型 7834。
参见图79，图75a和75b的信用报告数据库7540存储示例性记 录7942、7944和7946，这每一记录对应于收到的要约。每一记录存 储要约标识符7948，它(i)唯一标识一要约，(ii)对应于图76的借入者 数据库7534的要约标识符7674之一，并(iii)对应于图78的要约数据 库7538中的要约标识符7816之一。对每一要约，还存储信用报告标 识符7950，该标识符由中央控制器7412(图74)产生并唯一标识提交 了对应的要约的借入者的信用验证的结果和其它评估。信用计分7952 定义了该评估的结果。
参照图80，图75a和75b的附属担保数据库7542存储示例性记 录8060、8062、8064和8066，每一记录对应于收到的要约。每一记 录存储一标识符8068，该标识符唯一标识一要约并对应于上述与图 76、78和79相关联描述的要约标识符。对于每一要约，还存储附属 担保类型8070，附属担保的说明8072和附属担保值8074。
参见图81a，图75a的响应数据库7544存储示例性记录8180和 8182，每一记录对应于收到的对要约的响应。每一记录存储要约标识 符8184，该标识符唯一标识一要约并对应于上述与图76、78、79和 80相关联描述的要约标识符。每一记录还存储唯一标识每一收到的 响应的响应标识符8186、出借者身份8188、出借者愿意提供的贷款 条件，诸如贷款数额8190，分段支付数额8192，贷款条款8194和贷 款利率8196。响应时间8198和日期8200也存储在响应数据库7544 中。
参见图81b，图75b的规则数据库7564存储示例性记录8212和 8214，每一记录对应于定义出借者何时将接受要约的准则的规则。每 一记录存储唯一标识一规则的规则标识符8216、标识接受满足规则 的要约的出借者身份8218、及规定接受一要约的准则的规则限制 8220。
图82a和82b示出用于处理借入者终端和一个或多个出借者终端 之间的贷款销售的方法8230。所示的方法8230由图75a的实施例的 中央控制器7530执行，其中接受一要约包括从出借者终端接收承诺 信号。中央控制器从借入者终端接收要约信号(步骤8232)。如上所述， 要约信号包括至少一个条件信号，从而要约信号定义具有来自借入者 至少一个条件的要约。
支付标识符信号是从借入者终端接收的(步骤8234)。支付标识符 信号，诸如信用卡号码或支票帐户号码，规定了可从其支付资金的帐 户。
中央控制器验证支付标识符信号(步骤8236)。可通过冻结帐户中 一定数额的资金或另外使该资金对借入者不可得，并从而保证这种资 金对接受的卖方保持为可得而验证支付标识符信号。如果支付标识符 信号无效，则请求借入者终端重新传输要约和支付标识符信号(步骤 8238)。中央控制器还验证收到的要约信号(保证8240)，从而确定收 到的要约信号是否满足预定的验证准则。如果要约信号不满足预定的 验证准则，则请求借入者终端重新传输接口和支付标识符(步骤 8238)。
验证一般包括进行财务计算，以确定收到的要约信号是否定义了 有意义的要约。例如，如果要约信号包含贷款数额、利率、贷款周期 和按月支付数额，则财务计算能够确定规定的要约是否有意义。财务 计算是已知的，并在由Richard A.Brealey和Stewart C.Myers所著 的“Principles of Corporate Finance，Fourth Edition”中描述，该文 献在此结合作为本公开的一部分对照。
中央控制器还从第三方请求并接收包含信用信息的信息信号(步 骤8242)。信息信号可进而包含与要约相关的其它信息，诸如由借入 者提供的附属担保评估值。如上所述，可以有多于一个的第三方向中 央控制器提供所需的信息信号。
然后中央控制器把要约信号和信息信号传送给一个或多个出借者 终端(步骤8244)。中央控制器转而从至少一个出借者终端接收响应被 传输的要约信号和信息信号的一个或多个承诺信号(步骤8246)。选择 承诺信号之一(步骤8248)，并标识对应的出借者终端(步骤8250)。从 而借入者在要约的条款和条件之下被约定到所标识的出借者。如果借 入者后来以不遵从要约条款而违约(步骤8252)，则启动支付标识符信 号的使用以便收集资金(步骤8254)。例如，中央控制器可以收集资金， 或可以向标识的出借者终端传输支付标识符信号，允许出借者直接收 集资金。
选择一个承诺信号的步骤8248可以按数种方式进行。例如，可 以选择首先收到承诺信号或承诺信号随机的一个。在另一实施例中， 承诺信号可以根据预定的分类标准存储，诸如按最低利率或最低月支 付数额存储。这时选择所存储的承诺信号的第一个将分别提供最低的 利率或按月支付。数种“打破僵局”方法可用来从一组同等吸引力的 承诺信号中选择一个承诺信号。
可能还希望允许借入者选择承诺信号，并这样选择出借者。在这 种实施例中，向借入者传输多个出借者信号。每一出借者信号表示一 出借者，该出借者又对应于多个承诺信号之一。然后借入者终端向中 央控制器提供指示被选的借入者信号的选择信号。从而选择信号指示 对应的被选择的承诺信号。
承诺信号的选择还可以通过由要约规定的条件发生。例如，一个 要约可以包括指示贷款数额的条件信号、定期支付数额及最低利率要 求。这样，选择指示在预定时间内收到的最低利率的承诺信号。类似 地，要约可以包括括指示贷款数额的条件信号、利率和最低定期支付 数额的要求。这种要约可进而包括指示最大贷款期的条件信号。因而， 选择指示最低定期支付数额的承诺信号。
图82c示出用于处理借入者终端和一个或多个出借者终端之间的 贷款销售方法8260的另一实施例。所示的方法8260图75b的实施例 的中央控制器7560执行，其中接受一个要约包括比较要约信号与卖 方规则，并确定要约是否满足任何规则。
如以上与图82a和82b相关的说明，中央控制器从借入者终端接 收要约信号(步骤8262)，并还接收支付标识符信号(步骤8264)。中央 控制器验证支付标识符信号(步骤8266)。如果支付标识符信号无效， 则请求借入者终端重新传输要约及支付标识符(步骤8268)。中央控制 器还验证收到要约信号(步骤8270)，从而确定收到的要约信号是否满 足预定的验证准则。如果要约是没有意义的，则请求借入者终端重新 传输要约及支付标识符(步骤8268)。中央控制器还从第三方请求并接 收指示信用信息的信息信号(步骤8272)。
中央控制器至少存储来自多个卖方的每一个的一个规则信号(步 骤8274)。每一规则信号至少包括一个卖方定义的限制。某些限制可 能涉及要约条件，而另一些条件可能涉及信息信号。例如，一规则可 能包括贷款数额必须小于$100,000且信用计分必须大于八十的限制。 业内专业人员应当理解，存储规则信号的步骤8274可以出现在接收 要约信号之前或之后。
要约信号和信息信号与至少一个规则信号比较(步骤8276)。如果 确定要约的条件和信息信号满足每一卖方定义的任何规则的限制(步 骤8278)，对应的出借者被标识(步骤8280)。如果多于一个规则被满 足，则根据以上所述的任何方法选择一个规则。从而在要约的条款和 条件下约定借入者到被标识的出借者。如果后来借入者以不遵守要约 条件而违约(步骤8282)，则如上所述启动支付标识符信号的使用以便 收集资金(步骤8284)。
本领域内熟练的技术人员应当认识到，本发明的方法和装置具有 许多应用，并且本发明不限于这里公开的示例性例子。此外，正如本 领域内熟练的技术人员所知，本发明的范围函盖对这里所述的系统的 组件通常已知的变化和改型。
权利要求书
按照条约第19条的修改
1.一种用于完成远程预期的买方和远程潜在的卖方之间有约束力 的合同的计算机装置，该装置包括：
存储器装置；以及
与所述存储器装置通信而配置的处理器，所述处理器被配置为从 远程预期的买方接收(a)包含至少一个条件的购买要约，及(b)用于规 定从其可为满足所述至少一个条件的购买支付资金的通用财务帐户的 支付标识符；所述处理器还配置为向多个远程潜在的卖方传输购买要 约，并至少从远程潜在的卖方之一接收要约的无条件承诺。
2.根据权利要求1的计算机装置，其中所述处理器还配置为启动 支付标识符的使用以实现从买方对购买的支付。
3.根据权利要求1的计算机装置，其中通用财务帐户是一信用 卡帐户。
4.一种用于完成远程预期的买方和远程潜在的卖方之间有约束 力的合同的计算机装置，该装置包括：
存储器装置；以及
与所述存储器装置通信而配置的处理器，所述处理器被配置为从 远程预期的买方接收(a)包含至少一个条件的购买要约，及(b)用于规 定从其可为满足所述至少一个条件的购买支付资金的电子结算系统的 通用财务帐户的支付标识符；所述处理器还配置为向远程潜在的卖方 的电子购物网络传输购买要约，至少从远程潜在的卖方之一接收要约 的无条件承诺，并启动支付标识符的使用通过对所述电子结算系统的 所述通用财务帐户的收费以进行对所述购买的支付。
5.根据权利要求4的计算机装置，其中所述电子结算系统是一 信用卡系统。
6.根据权利要求4的计算机装置，其中所述电子结算系统是与 所述电子购物网络分开的。
7.根据权利要求1或4的计算机装置，其中至少一个条件是从 由价格、数量、投送日期、质量、地理位置、及匿名性组成的一组中 选择的。
8.根据权利要求1或4的计算机装置，其中处理器被配置为通 知第一个接受的卖方，它已经进入与买方法律上约定的合同。
9.根据权利要求1或4的计算机装置，其中处理器还被配置为 向买方传输通知，购买要约由第一个接受的卖方接受。
10.根据权利要求9的计算机装置，其中向买方通知承诺标识了 第一个接受的卖方。
11.根据权利要求1或4的计算机装置，其中购买要约包括过期 日期，并在该日期之前是不可改变的。
12.根据权利要求1或4的计算机装置，其中如果在预定的时间 段内购买要约没有被接受，则购买要约过期。
13.根据权利要求1或4的计算机装置，其中如果购买要约没有 被接受而过期，则处理器还配置为通知买方，购买要约已经失效。
14.根据权利要求1或4的计算机装置，其中购买要约直到预定 的日期之前是无效的。
15.根据权利要求1或4的计算机装置，其中处理器还配置为确 定在任何承诺之前要约是否已经取消。
16.根据权利要求1或4的计算机装置，其中购买要约包含这样 的条件，假如买方向第一个接受的卖方支付了规定罚金，则在第一个 接受的卖方接受要约之后，买方有权撤回其要约。
17.根据权利要求1或4的计算机装置，其中购买要约是由预期 的买方加密签署的。
18.根据权利要求1或4的计算机装置，其中处理器还配置为从 买方收集对购买的支付。
19.根据权利要求1或4的计算机装置，其中处理器还配置为向 第一个接受的卖方传输买方的信用卡信息和授权。
20.根据权利要求1或4的计算机装置，其中处理器还配置为， 把从买方收集的支付置于由第三方保存的帐户。
21.根据权利要求1或4的计算机装置，其中购买的支付是基于 分期付款从买方收集的。
22.根据权利要求1或4的计算机装置，其中处理器还配置为向 第一个接受的卖方汇付对购买的支付。
23.根据权利要求1或4的计算机装置，其中处理器还配置为从 买方向第一个接受的卖方传输支付。
24.根据权利要求23的计算机装置，其中对购买的支付是在购 买要约的承诺时立即向第一个接受的卖方汇付的。
25.根据权利要求1或4的计算机装置，其中处理器还配置为对 潜在的买方和潜在的卖方之间交换的传输的原始性和完整性的至少一 个进行鉴别。
26.根据权利要求1或4的计算机装置，其中处理器还配置为在 不标识预期的买方的情形下使购买要约对潜在的卖方可得。
27.根据权利要求1或4的计算机装置，其中处理器还配置为在 不显示卖方的身份的情形下通知买方，他们的要约被接受。
28.根据权利要求1或4的计算机装置，其中购买要约是对于货 物。
29.一种用于以电子方式完成远程预期的买方和远程潜在的卖方 之间有约束力的合同的方法，该方法包括步骤：
从远程预期的买方以电子方式接收(a)包含至少一个条件的购买 要约，及(b)用于规定从其可为满足所述至少一个条件的购买支付资 金的通用财务帐户的支付标识符；
以电子方式使购买要约对于多个远程潜在的卖方可得；以及
至少从远程潜在的卖方之一以电子方式接收要约的无条件承诺。
30.根据权利要求29的方法，其中至少一个条件是从由价格、 数量、投送日期、质量、地理位置、及匿名性组成的一组中选择的。
31.一种用于以电子方式完成远程预期的买方和远程潜在的卖方 之间有约束力的合同的方法，该方法包括步骤：
从远程预期的买方以电子方式接收包含至少两个条件的购买要 约，一个条件称买方将有权从来自多个潜在的卖方的承诺中选择预期 的买方将被其约定的至少一个承诺；
以电子方式使购买要约对于多个潜在的卖方可得；
至少从多个潜在的卖方以电子方式接收要约的无条件承诺；
以电子的方式向预期的买方传输多个无条件承诺；以及
以电子方式从预期的买方接收买方将被约定履行的无条件承诺的 至少一个选择。
32.根据权利要求31的方法，其中所述两个条件之一是从由价 格、数量、投送日期、质量、地理位置、及匿名性组成的一组中选择 的。
33.一种用于以电子方式完成远程预期的买方和远程潜在的卖方 之间有约束力的合同的方法，该方法包括步骤：
从远程预期的买方以电子方式接收(a)包含至少一个条件的购买 要约，及(b)来自一电子结算系统的通用财务帐户的支付标识符，从 该电子结算系统可为满足所述至少一个条件的购买支付资金；
以电子方式使购买要约对于远程潜在的卖方的电子购物网络可 得；
以电子方式从至少一个远程潜在的卖方接收要约的无有条件购 买；以及
以电子的方式启动支付标识符的使用，通过对所述电子结算系统 的所述通用财务帐户收费对所述购买进行支付。
34.根据权利要求33的方法，其中所述电子结算系统是信用卡 系统。
35.根据权利要求33的方法，其中所述电子结算系统是与所述 电子购物网络分开的。
36.根据权利要求33的方法，其中至少一个条件是从由价格、 数量、投送日期、质量、地理位置、及匿名性组成的一组中选择的。
37.一种用于处理航空公司机票销售的系统，该系统包括：
用于从顾客获得对旅行的购买要约并从航空公司机票的多个卖方 获得一个或多个规则的通信端口，所述购买要约包含顾客定义的至少 一个条件，且所述每一规则包含一个或多个航空公司定义的限制；以 及
用于比较所述购买要约与所述规则的处理装置，以便如果所述顾 客定义的条件满足所述航空公司定义的至少所述规则之一的限制，确 定所述航空公司机票的任何卖方是否愿意接受所述购买要约。
38.一种用于处理货物或服务销售的系统，该系统包括：
用于从顾客获得对所述货物或服务的购买的购买要约、并从多个 卖方获得一个或多个规则的通信端口，所述购买要约包含顾客定义的 至少一个条件，且所述每一规则包含一个或多个卖方定义的限制；以 及
用于比较所述购买要约与所述规则的处理器，以便如果所述顾客 定义的条件满足所述卖方定义的至少所述规则之一的限制，确定任何 所述卖方是否愿意接受所述购买要约。
39.根据权利要求37或38的系统，其中所述购买要约是有约束 力的约定。
40.根据权利要求37或38的系统，其中所述处理器标识满足所 述顾客定义的条件的产品。
41.根据权利要求37或38的系统，其中所述限制包括价格，且 所述价格是不公开的。
42.根据权利要求37或38的系统，其中如果所述顾客定义的条 件满足所述限制，则所述处理器向所述顾客提供所述购买要约的承 诺。
43.根据权利要求37或38的系统，其中如果所述顾客定义的条 件满足所述限制，则所述处理器约定所述顾客。
44.根据权利要求37或38的系统，还包括一个或多个远程服务 器，用于存储所述规则的至少一部分。
45.根据权利要求37或38的系统，还包括至少一个收益管理系 统，且其中至少所述规则的一部分是通过所述至少一个收益管理系统 产生的。
46.根据权利要求37或38的系统，其中如果所述购买要约没有 被接受且所述购买要约在至少一个所述规则的预定的允限内，则所述 处理器产生一还价。
47.根据权利要求37或38的系统，其中所述限制包含一最小价 格且所述处理器防止所述顾客识别所述最小价格。
48.根据权利要求47的系统，其中所述处理器通过限制在预定 的周期内可从给定的顾客获得所述购买要约的数目，防止所述顾客识 别所述最小价格。
49.根据权利要求47的系统，其中如果当航空公司接受了所述 购买要约时机票没有被定座，则所述处理器通过对所述顾客征收罚金 来防止所述顾客识别所述最小价格。
50.根据权利要求47的系统，其中通过评估包含关于所述顾客 将对应于所述购买要约对一机票定座的似然率的信息的所述顾客的信 誉，所述处理器防止所述顾客识别所述最小价格。
51.根据权利要求47的系统，其中如果所述顾客定义的条件满 足所述航空公司定义的限制，则所述处理器通过约定所述顾客购买所 述航空公司机票防止所述顾客识别所述最小价格。
52.一种用于处理航空公司机票销售的系统，所述系统包括：
存量分配系统，用于提供多个座位供向提交用于旅行的购买要约 的顾客销售，包含顾客定义的至少一个条件的所述购买要约包括价 格；
收益管理系统，用于建立航空公司定义的限制，这些限制适用于 包含适当票价的所述提供的座位；以及
用于向一处理器提供所述航空公司定义的限制的发送器，以确定 如果所述顾客定义的条件满足所述航空公司定义的限制，是否接受所 述购买要约。
53.根据权利要求52的系统，用于获得对一个或多个所述提供的 座位的保留的接收器，如果所述顾客定义的条件满足所述航空公司定 义的限制。
54.根据权利要求52的系统，其中所述收益管理系统向提交所 述购买要约的顾客分配包含所述多个供销售的座位的票价等级。
55.根据权利要求52的系统，其中所述收益管理系统还包括一 处理器，如果所述购买要约在所述航空公司定义的至少一个限制的预 定允限之内，该处理器用于建立产生还价的规则。
56.根据权利要求52的系统，其中所述收益管理系统选择所述 航空公司定义的限制，以阻止由一般愿意付全票价的顾客使用。
57.一种处理航空公司机票销售的方法，该方法包括步骤：
获得来自顾客对旅行的购买要约，所述购买要约包含顾客定义的 包含价格的至少一个条件；
从多个航空公司机票卖方识别一个或多个规则，每一所述规则包 含一个或多个航空公司定义的限制；以及
比较所述购买要约与所述规则，以确定如果所述顾客定义的条件 满足所述航空公司定义的至少一个所述规则的限制，航空公司机票的 任何所述卖方是否愿意接受所述购买要约。
58.一种用于处理巡游票销售的系统，包括：
用于从顾客获得对旅行的购买要约并用于从巡游票的多个卖方接 收一个或多个规则的通信端口，所述购买要约包含顾客定义的包含价 格的至少一个条件，且每一所述规则包含一个或多个巡游经营者定义 的限制；以及
用于比较所述购买要约与所述规则的处理器，以便确定顾客定义 的所述条件是否满足巡游经营者定义的至少一个所述规则每一限制。
59.一种用于处理巡游票销售的系统，包括：
用于从顾客获得对所述巡游票的购买要约并用于向所述巡游票多 个潜在的卖方提供所述购买要约的通信端口，所述购买要约包含顾客 定义的至少一个条件，以及用于规定从其可支付资金的通用帐户的支 付标识符；以及
处理器，用于确定一个或多个所述运输公司是否接受所述购买要 约，并如果对于所述购买要约收到承诺，则用于约定所述顾客购买所 述巡游票。
60.根据权利要求58的系统，其中所述巡游经营者定义的限制包 括价格，且所述价格是不公开的。
61.根据权利要求58或59的系统，其中所述顾客定义条件包括 规定的旅程。
62.根据权利要求58或59的系统，其中顾客定义的所述条件包 括服务等级。
63.根据权利要求58或59的系统，其中顾客定义的所述条件包 括最大价格。
64.一种用于处理产品销售的系统，包括：
用于从顾客获得对所述产品的购买要约的通信端口，所述购买要 约包含顾客定义的至少一个条件，及用于规定从其可支付资金的通用 帐户的支付标识符；
处理器，用于确定是否多个潜在的所述产品的卖方接受所述购买 要约，并用于向所述顾客标识所述多个接受的卖方；以及
所述通信端口接收来自所述顾客对所述接受的卖方之一的选择以 提供所述产品。
65.根据权利要求64的系统，其中所述处理器在所述买方和所述 接受的卖方之间提供通信渠道。
66.根据权利要求64的系统，其中所述处理器向所述买方提供 由每一接受的卖方提供的所述产品的电子表示。
67.根据权利要求64的系统，其中所述处理器向所述买方提供 鼓励因素，用于选择所述接受的卖方之一以提供所述产品。
68.一种用于处理产品销售的系统，包括：
用于从顾客获得购买要约的通信端口，所述购买要约包含顾客定 义的至少一个条件及用于规定从其可支付资金的通用帐户的支付标识 符；以及
处理器，用于(i)确定一个或多个所述运输公司是否接受所述购买 要约并标识满足所述顾客定义的条件的产品，以及(ii)如果收到对所 述购买要约的承诺，约定所述顾客购买所述巡游票。
69.一种用于处理产品销售的系统，包括：
用于从顾客获得购买要约的通信端口，所述购买要约包含顾客定 义的至少一个条件及用于规定从其可支付资金的通用帐户的支付标识 符；
用于确定是否多个潜在的卖方接受所述购买要约并用于约定所述 顾客从所述多个接受的卖方之一购买的处理器；以及
存储器装置，用于存储所述附加的承诺的标识符，以供由所述处 理器对照来自后继的顾客的购买要约进行比较。
70.根据权利要求69的系统，其中所述附加的接受的产品的所述 标识符存储在存储器高速缓冲器中，该缓冲器在对来自后继顾客的所 述购买要约的所述提供步骤之前被访问。
71.一种用于处理产品销售的系统，包括：
通信端口，用于：
(a)从顾客获得对所述产品购买的购买要约，所述购买要约包含 顾客定义的至少一个条件，该条件含有来自潜在卖方集合的优选的卖 方的子集；
(b)向在不是优选的卖方的潜在的卖方所述集合中一个或多个被 排除的卖方提供所述购买要约；以及
(c)在所述购买要约被所述优选的卖方之一接受之前，从所述被排 除卖方之一接收对所述购买要约的还价；以及
用于确定所述顾客是否接收所述还价的处理器。
72.根据权利要求71的系统，其中所述通信端口接收来自所述顾 客购买来自所述被排除的还价的卖方的所述产品的承诺。
73.根据权利要求71的系统，其中所述处理器约定所述顾客购 买来自所述被排除的还价的卖方的所述产品。
74.根据权利要求71的系统，其中所述购买要约在所述优选的 卖方之前提供给所述被排除的卖方。
75.根据权利要求71的系统，其中所述购买要约与所述优选的 卖方同时提供给所述被排除的卖方。
76.根据权利要求64、68、69或71的系统，其中所述产品是货 物或服务。
77.根据权利要求76的系统，其中所述货物或服务是航空公司 机票。
78.根据权利要求76的系统，其中所述货物或服务是巡游。
79.根据权利要求71的系统，其中所述货物或服务是一个或多 个长途电话通话。
80.一种处理巡游票销售的方法，包括以下步骤：
从顾客获得对旅行的购买要约，所述购买要约包含顾客定义的至 少一个条件；
标识来自多个巡游票卖方的一个或多个规则，每一所述规则包含 巡游经营者定义的一个或多个限制；以及
如果所述顾客定义的条件满足巡游经营者定义的至少一个所述规 则的每一限制，则约定所述顾客购买所述巡游票。
81.一种处理巡游票销售的方法，包括以下步骤：
从顾客获得对所述巡游票的购买要约，所述购买要约包含顾客定 义的至少一个条件及用于规定从其可支付资金的通用帐户的支付标识 符；
向所述巡游票的多个潜在卖方提供所述购买要约；
从一个或多个所述卖方接收所述购买要约的承诺；以及
如果收到对所述购买要约的承诺，则约定所述顾客购买所述巡游 票。
82.一种用于处理成分条款组合销售的系统，包括：
从顾客接收对所述组合的购买要约的通信端口，所述购买要约包 含每一成分条款的描述及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，它用于把所述组合购买要约分解为多个成分购买要约并 确定每一所述成分购买要约是否由一个或多个潜在的卖方接受，并从 而如果收到对每一所述成分购买要约的承诺，则约定所述顾客购买所 述组合。
83.一种用于处理成分条款组合销售的系统，包括：
用于从顾客获得对所述组合的购买要约并用于从多个所述成分条 款的卖方获得一个或多个规则的通信端口，所述购买要约包含对每一 所述成分条款顾客定义的至少一个条件，且每一所述规则包含一个或 多个卖方定义的限制；以及
处理器，它进行：
分解所述组合购买要约为多个成分购买要约；
比较一个或多个所述成分购买要约与所述规则，以确如果所述顾 客定义的条件满足所述卖方定义的至少一个所述规则的限制，则任何 所述卖方是否愿意接受所述成分购买要约；以及
如果对每一所述成分购买要约获得承诺，则向所述顾客提供成分 条款的所述组合。
84.一种用于处理成分条款组合销售的系统，包括：
从顾客接收对所述组合的购买要约的通信端口，所述购买要约包 含每一成分条款的描述及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，它确定每一所述成分购买要约是否由一个或多个潜在的 卖方接受，并从而如果对每一所述成分购买要约收到承诺，则约定所 述顾客购买所述组合。
85.根据权利要求82或84的系统，其中所述处理器启动所述支 付标识符的使用以便收集所述资金。
86.根据权利要求82、83或84的系统，其中所述成分购买要约 以成分价格提供。
87.根据权利要求86的系统，其中每一成分的所述成分价格基 于成分条款的市场价值对整个组合的市场价值的百分比。
88.根据权利要求82、83或84的系统，其中所述处理器启动与 每一接受成分购买要约的卖方达成初步协议，从而保留与所述被接受 的成分购买要约相关的成分条款达预定的时间周期。
89.根据权利要求82、83或84的系统，其中所述购买要约包括 总价格，且所述总价格的一部分作为保险金保留。
90.根据权利要求86的系统，其中所述处理器增加在预定时间 周期过后仍然未被所述卖方接受的一个或多个所述成分购买要约的成 分价格。
91.根据权利要求82、83或84的系统，其中所述处理器基于与 每一成分购买要约相关的行业及所述卖方的行业过滤提供给所述卖方 的成分购买要约。
92.根据权利要求82、83或84的系统，其中所述承诺还包括满 足所述顾客定义的条件的成分产品的识别。
93.一种用于处理成分条款组合销售的系统，包括：
从顾客接收对所述组合的购买要约的通信端口，所述购买要约包 含每一成分条款的描述及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，把所述组合购买要约分解为多个成分购买要约并确定每 一所述成分购买要约是否由一个或多个潜在的卖方以成分价格接受， 并从而如果收到对每一所述成分购买要约的承诺，则约定所述顾客购 买所述组合，其中所述成分价格对所述顾客不公开。
94.一种处理成分条款组合销售的方法，它包括步骤：
从顾客获得对所述组合的购买要约，所述购买要约包含每一成分 条款的说明及用于规定从其可支付资金的通用帐户的支付标识符；
把所述组合购买要约分解为多个成分购买要约；
确定一个或多个潜在的卖方是否接受所述成分购买要约；以及
如果收到对所述每一成分购买要约的承诺，则约定所述顾客购买 所述组合。
95.一种处理成分条款组合销售的方法，它包括步骤：
从顾客获得对所述组合的购买要约，所述购买要约包含顾客定义 的对每一所述成分条款至少一个条件；
把所述组合购买要约分解为多个成分购买要约；
识别来自所述成分条款的多个卖方的一个或多个规则，每一所述 规则包含一个或多个卖方定义的限制；以及
比较一个或多个所述成分购买要约与所述规则，以确定如果所述 顾客定义的条件满足所述卖方定义的至少一个所述规则的限制，则任 何所述卖方是否愿意接受所述成分购买要约；以及
如果对每一所述成分购买要约获得承诺，则向所述顾客提供成分 条款的所述组合。
96.一种用于处理长途通话的系统，该系统包括：
用于从顾客获得对一个或多个通话的购买要约并用于向多个潜在 的电信公司提供所述购买要约的通信端口，所述购买要约包含顾客定 义的至少一个条件，以及用于规定从其可支付资金的通用帐户的支付 标识符；以及
处理器，用于确定一个或多个所述电信公司是否接受所述购买要 约，并如果收到对于所述购买要约的承诺，则用于约定所述顾客购买 所述电话通话。
97.一种用于处理长途通话的系统，该系统包括：
用于从顾客获得对一个或多个电话通话的购买要约并用于从多个 电信公司接收一个或多个规则的通信端口，所述购买要约包含顾客定 义的包含价格的至少一个条件，且每一所述规则包含一个或多个电信 公司定义的限制；以及
用于比较所述购买要约与所述规则的处理器，以便确定如果顾客 定义的所述条件满足电信公司定义的至少一个所述规则每一限制，则 任何所述电信公司是否愿意接受所述购买要约。
98.根据权利要求96的系统，其中所述处理器启动所述支付标识 符的使用以收集支付。
99.根据权利要求96的系统，其中所述资金可从通用帐户支付。
100.根据权利要求96的系统，其中所述资金可由电话服务提供 者发出的定期电话服务帐单收取。
101.根据权利要求96或97的系统，其中所述购买要约是从配 置为传输所述购买要约的电话机接收的。
102.根据权利要求96或97的系统，其中所述购买要约是对向 一个或多个被呼叫方的通话的组合。
103.根据权利要求96或97的系统，其中所述购买要约是对预 定时间周期电话服务合同。
104.根据权利要求96或97的系统，其中所述购买要约是对预 定金额电话服务合同。
105.根据权利要求96或97的系统，其中所述顾客定义的条件 规定一天中对所述一个或多个电话通话的特定时间。
106.根据权利要求96或97的系统，其中所述顾客定义的条件 规定了对所述一个或多个电话通话最小的持续时间。
107.根据权利要求96或97的系统，其中所述顾客定义的条件 规定了对所述一个或多个电话通话最大的持续时间。
108.根据权利要求96或97的系统，其中所述顾客定义的条件 包含被呼叫方的电话号码。
109.根据权利要求96或97的系统，其中所述通信端口连接到 电话网络。
110.根据权利要求96或97的系统，其中所述通信端口连接到 电子网络。
111.一种处理长途通话的方法，包括以下步骤：
从顾客获得对一个或多个电话通话的购买要约，所述购买要约包 含顾客定义的至少一个条件及用于规定从其可支付资金的通用帐户的 支付标识符；
向所述多个潜在电信公司提供所述购买要约；
从一个或多个所述电信公司接收所述购买要约的承诺；以及
如果收到对所述购买要约的承诺，则约定所述顾客购买所述电话 通话。
112.一种处理长途通话的方法，包括以下步骤：
从顾客获得对一个或多个电话通话的购买要约，所述购买要约包 含顾客定义的包含价格的至少一个条件；
标识来自多个长途电信公司的一个或多个规则，每一所述规则包 含电信公司定义的一个或多个限制；以及
如果所述顾客定义的条件满足电信公司定义的至少一个所述规则 的每一限制，则约定所述顾客购买所述电话通话。
113.一种用于完成远程预期的活动门票买方和远程潜在的活动门 票卖方之间的有约束力的合同的计算机装置，该装置包括：
存储器装置；及
配置与所述存储器装置连接的处理器，配置所述处理器进行：
从所述买方接收对所述活动门票的购买要约，所述要约包含至少 一个条件、来自通用财务帐户的帐户号码、及向所述通用财务帐户对 满足所述至少一个条件的购买收费的授权；
向多个远程潜在的活动门票卖方传输所述购买要约；
从至少一个所述远程潜在的活动门票卖方接收所述要约的无条件 承诺；
确定与所述活动门票相关的替换门票标识符；以及
向所述买方传输所述替换门票的标识符。
114.根据权利要求113的装置，其中所述处理器还配置为，从所 述卖方接收第二通用财务帐户号码，及用于向所述卖方的帐户征收罚 金对所述第二通用帐户号码收费的授权。
115.根据权利要求113的装置，其中所述处理器还配置为，在 收到表示所述活动门票由所述卖方交出的信号时，处理向所述卖方的 支付。
116.根据权利要求113的装置，其中所述处理器还配置为，在 收到与所述活动门票相关的门票号码时处理对所述卖方的支付。
117.根据权利要求113的装置，其中所述处理器还配置为，处 理所述活动门票的删除。
118.根据权利要求113的装置，其中所述处理器还配置为，接 收并存储与所述活动门票相关的所述买方的姓名。
119.根据权利要求113的装置，其中所述处理器还配置为，向 活动地点控制器传输与所述活动门票相关的门票标识符。
120.根据权利要求119的装置，其中所述处理器配置为，通过 进一步配置从所述活动地点控制器接收所述替换门票的标识符确定替 换门票的标识符。
121.根据权利要求113的装置，其中所述替换门票标识符包含 原始门票标识符。
122.一种用于对活动门票管理替换标识符的计算机装置，该装置 包括：
存储器装置；以及
被配置与所述存储器装置连接的处理器，所述处理器配置为从中 央控制器接收对替换门票号码的请求，所述请求包括原始门票号码； 所述处理器还配置为确定所述替换门票号码、向所述中央控制器传输 所述替换门票号码；并在所述存储器装置存储所述原始门票号码和所 述相关的替换门票号码。
123.根据权利要求122的装置，其中所述处理器配置为，接收 表示买方身份的标识数据，并在所述存储器装置与所述原始门票号码 及所述替换门票号码相关存储所述标识数据。
124.一种用于对活动门票鉴别替换标识符的计算机装置，它包 括：
用于存储门票标识符和与所述门票标识符相关的第一替换门票标 识符的存储器装置；
输出装置；以及
配置为与所述存储器及所述输出装置连接的处理器，所述处理器 配置为：
以电子方式接收第二替换门票标识符；
比较所述第二替换门票标识符与所述第一替换门票标识符以确定 结果；以及
通过所述输出装置显示所述结果以指出所述第二替换门票标识符 的真实性。
125.根据权利要求124的装置，其中所述存储器还存储表示与所 述第一替换标门票标识符相关的买方的身份的数据，且所述处理器还 配置为检索所述标识数据，并通过所述输出装置显示所述标识数据以 指出所述买方的身份。
126.一种处理项目销售的方法，包括：
接收包含至少一个条件信号的要约信号，由此要约信号定义具有 来自顾客的至少一个条件的要约；
接收用于规定从其可支付资金的帐户的支付标识符信号；
从第三方接收与要约相关的信息信号；
向至少一个卖方传输要约信号和信息信号；
从至少一个的至少一个卖方接收响应传输的要约信号和传输的信 息信号的承诺信号；以及
选择一个承诺信号。 127.一种用于处理项目销售的装置，包括：
存储装置；及
与存储装置连接的处理器，
存储装置存储用于控制处理器的程序；及
处理器对程序可操作以便：
接收包含至少一个条件信号的要约信号，由此要约信号定义具有 来自顾客的至少一个条件的要约；
接收用于规定从其可支付资金的帐户的支付标识符信号；
从第三方接收与要约相关的信息信号；
向至少一个卖方传输要约信号和信息信号；
从至少一个的至少一个卖方接收响应传输的要约信号和传输的信 息信号的承诺信号；以及
选择一个承诺信号。
128.权利要求127的装置，其中处理器还对程序可操作以便：
识别从其收到所选择的承诺信号的卖方。
129.根据权利要求127的装置，其中处理器还对程序可操作以 便：
启动支付标识符的使用以收集资金。
130.根据权利要求129的装置，其中处理器还对程序可操作以 便向至少一个卖方传输支付标识符信号。
131.根据权利要求127的装置，其中处理器还对程序可操作以 便：
验证收到的要约信号，从而确定收到的要约信号是否满足预定的 验证准则。
132.根据权利要求131的装置，其中处理器还对程序可操作， 以便仅当验证的步骤确定收到的要约信号满足预定的验证准则才传输 要约信号和信息信号。
133.根据权利要求127的装置，其中处理器还对程序可操作以 便选择第一个收到的承诺信号。
134.根据权利要求127的装置，其中处理器还对程序可操作以 便如果收到多个承诺信号则随机选择多个承诺信号之一。
135.根据权利要求127的装置，其中处理器还对程序可操作以 便
如果收到多个承诺信号，
根据预定的分类准则对多个承诺信号进行分类，以及
选择被分类的多个承诺信号的第一个。
136.根据权利要求127的装置，其中处理器还对程序可操作以 便
如果收到多个承诺信号，
传输多个卖方信号，每一信号表示对应于多个承诺信号之一的一 个卖方，
接收表示被选择的卖方信号的的选择信号，并从而指示对应的承 诺信号，以及
选择对应于被选择的卖方信号的承诺信号。
137.一种用于处理借入者终端与至少一个出借者终端之间的贷款 的销售的装置，包括：
存储装置；及
与存储装置、借入者终端和至少一个出借者终端连接的处理器，
存储装置存储
用于控制处理器的程序；及
处理器对程序可操作以便
从借入者终端接收包含至少一个条件信号的要约信号，由此要约 信号定义具有来自借入者的至少一个条件的要约；
从借入者终端接收用于规定从其可支付资金的帐户的支付标识符 信号；
从第三方接收包含信用信息的信息信号；
向至少一个出借者传输要约信号和信息信号；
从至少一个出借者终端接收响应传输的要约信号和传输的信息信 号的承诺信号；
选择一个承诺信号；以及
标识从其收到被选择的承诺信号的出借者终端。
138.根据权利要求137的装置，其中处理器还对程序可操作以 便：
验证收到的要约信号，从而确定收到的要约信号是否满足预定的 验证准则。
139.根据权利要求138的装置，其中处理器还对程序可操作以 便：
进行财务计算确定收到的要约信号是否定义了有意义的要约。
140.根据权利要求137的装置，其中至少一个条件信号指示贷 款数额、定期支付数额、贷款周期和利率中的至少一个。
141.根据权利要求137的装置，其中至少一个条件信号指示对 支付数额和利率之一的最低者的要求。
142.根据权利要求137的装置，其中要约信号包括：
指示贷款数额的第一条件信号，
指示定期支付数额的第二条件信号，及
指示对最低利率的要求的第三条件信号。
143.根据权利要求142的装置，其中处理器还对程序可操作以 便：
如果收到其中每一承诺信号包含利率的多个承诺信号，则选择多 个承诺信号的具有最低利率的承诺信号。
144.根据权利要求137的装置，其中要约信号包括：
指示贷款数额的第一条件信号，
指示对最低定期支付数额要求的第二条件信号，及
指示利率的第三条件信号。
145.根据权利要求144的装置，其中处理器还对程序可操作以 便：
如果收到其中每一承诺信号包含定期支付数额的多个承诺信号， 则选择多个承诺信号的具有最低定期支付数额的承诺信号。
146.根据权利要求144的装置，其中要约信号还包括：
表示贷款周期的第四条件信号。
147.根据权利要求144的装置，其中要约信号还包括：
表示最大贷款周期的第四条件信号。
148.根据权利要求137的装置，其中要约信号还包括：
表示贷款数额的第一条件信号，
表示定期支付数额的第二条件信号，及
表示利率的第三条件信号。
149.根据权利要求148的装置，其中第二条件信号指示按月支 付数额。
150.根据权利要求148的装置，其中要约信号还包括：
表示贷款周期的第四条件信号。
151.根据权利要求137的装置，其中要约信号还包括：
表示贷款数额的第一条件信号，
表示贷款周期的第二条件信号，及
表示利率的第三条件信号。
152.根据权利要求151的装置，其中要约信号还包括：
表示定期支付数额的第四条件信号。
153.根据权利要求152的装置，其中第四条件信号表示按月支 付数额。
154.一种用于处理项目销售的装置，包括：
存储装置；及
与存储装置、借入者终端和至少一个出借者终端连接的处理器，
存储装置存储
用于控制处理器的程序；及
处理器对程序可操作以便
接收包含至少一个条件信号的要约信号，要约信号定义具有来自 顾客的至少一个条件的要约；
接收用于规定从其可支付资金的帐户的支付标识符信号；
从第三方接收与要约相关的信息信号；
存储来自多个卖方的每一个的至少一个规则信号，每一规则信号 包含至少一个卖方定义的限制；
比较要约信号和信息信号与至少一个规则信号；以及
确定至少一个条件和信息信号是否满足任何规则的卖方定义的每 一限制。
155.根据权利要求154的装置，其中处理器还对程序可操作以 便：
如果多个规则被满足，则选择多个被满足的规则之一。
156.根据权利要求155的装置，其中处理器还对程序可操作以 便：
随机则选择多个被满足的规则之一。
157.根据权利要求155的装置，其中处理器还对程序可操作以 便：
传输多个出借者信号，每一信号表示对应于多个被满足的规则之 一的出借者；
接收表示被选择的出借者信号的选择信号，并从而指示对应的规 则；以及 选择对应于所选择的出借者信号的被满足的规则。
158.一种使用计算机便于在买方和多个卖方的至少一个之间进行 交易的方法，包括：
向计算机输入包含要约价格的有条件购买要约；
向计算机输入规定信用卡帐户的支付标识符，该支付标识符与有 条件购买要约相关；
在收到支付标识符后向多个卖方输出有条件购买要约；
向计算机输入来自卖方的承诺，该承诺是对有条件购买要约的响 应；以及
使用支付标识符向卖方提供支付。
159.根据权利要求158的方法，其中向计算机输入承诺的步骤 包括：
向计算机输入来自卖方集合的每一成员的承诺，卖方集合包含至 少一个卖方，每一承诺是对有条件购买要约的响应；
并还包括；
选择一个收到的承诺，从而确定卖方集合的被选择的卖方；
且其中提供支付的步骤包括：
使用支付标识符向被选择的卖方提供支付。
160.根据权利要求158的方法，还包括：
确定预定数额在信用卡帐户中是否可得。
161.根据权利要求158的方法，还包括：
向买方输出对使用支付标识符的授权的请求，以便如果收到承诺 则提供支付；以及
响应该请求向计算机输入来自买方的授权。
162.根据权利要求158的方法，其中向计算机输入承诺的步骤 包括：
向计算机输入来自卖方集合的每一个的承诺。
163.根据权利要求158的方法，还包括：
确定有条件购买要约有效的有效期；且其中向计算机输入承诺 的步骤在有效期进行。
164.根据权利要求158的方法，还包括：
在接收承诺的步骤之后向计算机输入有条件购买要约的撤销；并 其中提供支付的步骤包括；
向卖方提供预定数额的支付。
165.根据权利要求159的方法，其中选择一个收到的承诺的步 骤包括：
确定第一个收到的承诺，从而确定卖方集合的第一个卖方；
且其中提供支付的步骤包括：
使用支付标识符向第一个卖方提供支付。
166.一种便于在买方和多个卖方的至少一个之间进行交易的装 置，包括：
存储装置；及
与存储装置连接的处理器，
该存储装置存储
用于控制处理器的程序；及
处理器使用该程序可操作以便接收包含要约价格的有条件购买要 约；
接收规定信用卡帐户的支付标识符，该支付标识符与有条件购买 要约相关；
在收到支付标识符之后使有条件购买要约对多个卖方可得；
从一卖方接收承诺，该承诺是对有条件购买要约的响应；以及
使用支付标识符向被选择的卖方提供支付。
167.一种使用计算机便于在买方和多个卖方的至少一个之间进 行交易的方法，包括：
向计算机输入包含要约价格的有条件购买要约；
向计算机输入规定财务帐户的支付标识符，该支付标识符与该有 条件购买要约相关；
向买方输出如果收到承诺使用支付标识符以提供支付的授权请 求；
响应该请求向计算机输入来自买方的授权；
在收到支付标识符后向多个卖方输出有条件购买要约；
向计算机输入来自卖方的承诺，该承诺是对有条件购买要约的响 应；以及
使用支付标识符向卖方提供支付。
168.一种便于在买方和多个卖方的至少一个之间进行交易的装 置，包括：
存储装置；及
与存储装置连接的处理器，
该存储装置存储
用于控制处理器的程序；及
处理器对该程序可操作以便接收包含要约价格的有条件购买要 约；
接收规定财务帐户的支付标识符，该支付标识符与有条件购买要 约相关；
向买方输出如果收到一承诺使用支付标识符以提供支付的授权请 求；
接收响应该请求来自买方的授权；
在收到支付标识符之后向多个买方传输有条件购买要约；
从一卖方接收承诺，该承诺是对所传输的有条件购买要约的响 应；以及
使用支付标识符向卖方提供支付。
169.根据权利要求166的装置，其中处理器还对程序可操作以 便：
接收来自卖方集合的每一成员的承诺，卖方集合包含至少一个卖 方，每一承诺是对有条件购买要约的响应；
选择一个收到的承诺，从而确定卖方集合的被选择的卖方；以及
使用支付标识符向被选择的卖方提供支付。
170.根据权利要求166的装置，其中处理器还对程序可操作以 便：
确定第一个收到的承诺，从而确定卖方集合的第一个卖方；以及
使用支付标识符向第一个卖方提供支付。
171.根据权利要求166的装置，其中处理器还对程序可操作以 便：
确定预定数额在信用卡帐户中是否可得。
172.根据权利要求166的装置，其中处理器还对程序可操作以 便：
从买方向卖方进行支付转帐。
173.根据权利要求166的装置，其中处理器还对程序可操作以 便：
向卖方传输支付标识符。
174.根据权利要求166的装置，其中处理器还对程序可操作以 便：
向买方输出如果收到一承诺使用支付标识符以提供支付的授权请 求；
响应该请求从买方接收该授权。
175.根据权利要求166的装置，其中处理器还对程序可操作以 便：
接收来自卖方集合的每一个的承诺。
176.根据权利要求166的装置，其中有条件购买要约包括一过 期日期，并在过期日期之前该要约是不可撤回的。
177.根据权利要求166的装置，其中处理器还对程序可操作以 便：
确定有条件购买要约有效的有效期；且
在有效期内接收承诺。
178.根据权利要求166的装置，其中处理器还对程序可操作以 便：
在收到承诺之后接收有条件购买要约的撤销；以及
向卖方提供预定数额的支付。
179.根据权利要求167的装置，其中向计算机输入承诺的步骤 包括：
向计算机输入来自卖方集合的每一成员的承诺，卖方集合包含至 少一个卖方，每一承诺是对有条件购买要约的响应；
并还包括；
选择一个收到的承诺，从而确定卖方集合的被选择的卖方；
且其中提供支付的步骤包括：
使用支付标识符向被选择的卖方提供支付。
180.根据权利要求179的方法，其中选择一个收到的承诺的步 骤包括：
确定第一个收到的承诺，从而确定至少一个卖方的第一个卖方；
且其中提供支付的步骤包括：
使用支付标识符向第一个卖方提供支付。
181.根据权利要求167的方法，其中财务帐户是一信用卡帐户。
182.根据权利要求181的方法，还包括：
确定在信用卡帐户中预定数额是否可得。
183.根据权利要求167的方法，还包括：
从买方向买方转帐支付。
184.根据权利要求167的方法，其中提供支付的步骤包括：
向卖方传输支付标识符。
185.根据权利要求167的方法，其中向计算机输入承诺的步骤 包括：
向计算机输入来自卖方集合的每一个卖方的承诺。
186.根据权利要求167的方法，其中有条件购买要约包括过期 日期并在过期日期之前是不可撤回的。
187.根据权利要求167的方法，还包括：
确定有条件购买要约为有效的有效期；
且其中向计算机输入承诺的步骤在有效期进行。
188.根据权利要求167的方法，还包括：
在接收承诺的步骤之后向计算机输入有条件购买要约的撤销；且 其中提供支付的步骤包括；
向卖方提供预定数额的支付。
189.根据权利要求168的装置，其中处理器还对程序可操作以 便：
接收来自卖方集合的每一成员的承诺，卖方集合包含至少一个卖 方，每一承诺是对有条件购买要约的响应；选择一个收到的承诺，从 而确定卖方集合的被选择的卖方；以及
使用支付标识符向被选择的卖方提供支付。
190.根据权利要求188的装置，其中处理器还对程序可操作以 便：
确定第一个收到的承诺，从而确定卖方集合的第一个卖方；以及
使用支付标识符向第一个卖方提供支付。
191.根据权利要求168的装置，其中财务帐户是一信用卡帐户。
192.根据权利要求190的装置，其中处理器还对程序可操作以 便：
确定在信用卡帐户中预定数额是否可得。
193.根据权利要求168的装置，其中处理器还对程序可操作以 便：
从买方向买方转帐支付。
194.根据权利要求168的装置，其中处理器还对程序可操作以 便：
向卖方输出支付标识符。
195.根据权利要求168的装置，其中处理器还对程序可操作以 便：
接收来自卖方集合的每一个的承诺。
196.根据权利要求168的装置，其中有条件购买要约包括过期 日期并在过期日期之前是不可撤回的。
197.根据权利要求168的装置，其中处理器还对程序可操作以 便：
确定有条件购买要约为有效的有效期；以及
在有效期接收承诺。
198.根据权利要求168的装置，其中处理器还对程序可操作以 便：
在接收承诺之后接收有条件购买要约的撤销；并向卖方提供预定 数额的支付。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种防线缆完全撤回的电力施工用放线装置 | 2020-05-13 | 273 |
| 短信息撤回的方法及装置 | 2020-05-11 | 699 |
| 一种移动终端的误操作撤回方法及系统 | 2020-05-13 | 258 |
| 撤回聊天内容的方法及设备 | 2020-05-12 | 469 |
| 基于网络应答的随机系统及撤回随机的方法 | 2020-05-14 | 98 |
| 一种选择性撤回邮件的实现方法 | 2020-05-11 | 171 |
| 可选择性撤回预取的方法 | 2020-05-12 | 759 |
| 用于撤回数据转移操作的方法及装置 | 2020-05-13 | 522 |
| 一种选择性撤回邮件的实现方法 | 2020-05-13 | 606 |
| 用于车辆消息撤回的方法和设备 | 2020-05-12 | 479 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
