CN101084519A - 对进取性定单提供价格改进的大宗交易系统 - Google Patents

Abstract

本发明包含促进电子证券交易的系统和方法。优选系统实施例包含交易促进计算机系统，而交易促进计算机系统包含促进器模块、金融信息交换服务器、事务处理数据库和起计算证券的参考价作用的分析服务器。优选方法实施例包括如下步骤：接收证券的市场数据；计算证券的参考价；接收包含第一价格限定和第一数量限定的第一定单；接收与第一定单相对和包含第二价格限定和第二数量限定的第二定单；和在与参考价的差异最小的价格上执行包含所述第一定单和所述第二定单的交易，其中，该交易服从第一和第二价格和第一和第二数量限定。

Description

对进取性定单提供价格改进的大宗交易系统

交叉参考相关申请

本申请是2003年6月24日提出的美国专利申请第10/603,100号的部分继续，美国专利申请第10/603,100号是2001年5月31日提出的美国专利申请第09/870,845号的部分继续，美国专利申请第09/870,845号是2000年12月29日提出的美国专利申请第09/750,768号的部分继续，美国专利申请第09/750,768号是2000年6月1日提出的美国专利申请第09/585,049号的部分继续。特此全文引用上面列出的每个申请，以供参考。

技术领域

本发明涉及管理信息以使大宗交易兴趣集中在秘密撮合帐簿上以及在像因特网那样的计算机网络上进行大宗交易的方法。

背景技术

在公开证券市场上，市场机制和交易心理形成传播有效信息和发现价格的障碍。市场参与者暴露有关他或她的真正价格限定的信息的决定代表影响价格预期的市场影响成本与延迟或无法进行交易的机会成本之间的折衷。正如这里所使用的那样，术语“市场参与者”指的是有能力交易证券的任何个人或公司；市场参与者的例子包括在电子通信网络(ECN)上交易的私人投资者、经纪交易商、机构、对冲基金和统计套利和其它专门交易运作部门。

通过向例如一个或多个可能卖家显示买家真正价格限定，市场参与者实际上正在出售一份每个卖家可以自由选择执行的期权；只要这个期权是开放的，就可以对应该成为公平交易价格的市场参与者预期设置较低的界线。即使卖家之一原来存在较低的价格预期，但当知道买家的价格限定时，也可以马上改变这个预期，唯一剩下的问题是，公平的价格是否应该再高一些。的确，通过公开表示买家渴望获取股票的高价格，可以反映出还值得卖家注意的信息。

经纪交易商通过在发现公平价格之前代表交易双方谨慎管理当事人的预期，然后提出可以使双方都满意的公平价格来处理这个问题。今天，这样的代理定单越来越多地通过电子手段传送。为了避免上述对价格预期的影响，在公开市场上不显示视为“不确定”的定单。经纪人可以代表买方和卖方接收撮合不确定定单，并亲自在两个定单的限定之间的某处找出必然选择公平价格的位置，以便进行撮合交易。当处理这样的状况时，通常需要自行决定。例如，如果买家在上午10点输入$30.00的大宗买入定单，而市场从那时起降到$29.80的当前最佳发盘，由于与当前市场相比，现在似乎有些贵，所以在这个价格上最没有可能自动撮合$29.99的大宗卖出定单；如果市场价格将上升到这个水平之上，买家的限定被解释为停止买入的定单。但是，有可能接受也与买家高得多的限定撮合的$29.82的大宗卖出定单，而$29.85的大宗卖出定单将提示经纪人给买家打电话。

考虑到佣金支付，和考虑到信息被泄漏给与像对冲基金那样的进取性交易公司关系密切的个体，这种人为仲裁都会造成价格过高。这样就使大型机构燃起了找出他们可以不受传统经纪人随意干预地亲自公布他们的定单的替代市场的欲望。

像NASDAQ或电子通信网络(ECN)那样的电子市场都没有被良好地装备成处理大宗交易的价格发现问题。最简单地说，电子市场简单地向他们的客户显示买家和卖家的交易兴趣，然后使这些客户有能力实现这样的买入和卖出兴趣。为了避免影响市场参与者的价格预期，电子市场的用户通常输入消极价格的相对小额定单。和耐心地等待其它人执行它们，或者，采取稍微有点进取的姿态和执行其它人已经公布在展板的另一方上的定单。

一些工具可用于将较大额的定单“切割”成可以以相同方式工作的大量小片，但它们的活动不可避免地向熟悉统计分析技术的人员揭示出较大额定单的存在。这样的交易者可以开发和优化在大额秘密定单正在工作的时候故意检测它们的交易策略，并通过预测那些定单有可能造成的市场影响来产生利益。最简单的这样策略是将较大额定单的位置提前和依靠它的长时间存在将价格往有利可图的方向推动。通过沿着与大额定单相同的方式交易，这样的寄生策略最终加剧了大额定单在第一位置自然引起的价格移动。最后结果与在纽约证券交易所上公布大额定单产生的结果完全不同：在后一种情况下，场内交易者一起“分享”拍卖定单，或直接来到前面，截取能够吸引他们的流动物。在NYSE交易大厅内，以及在电子市场上，术语“便士跳跃(penny-jumping)”和“往前移(front-running)”已经开始用于描述这种类型的寄生策略。

一些ECN提出了更复杂的定单类型，试图缓解往前移问题。一些定单(例如，自行决定定单)仅仅通过显示一个价格，但保留执行到较高秘密价格限定的优先级，设法屏蔽真正价格限定。这些措施遭到简单计数策略，譬如，在不同价格水平上喷洒小额定单，看看什么时候在未显示价格水平使定单被执行的策略的破坏。其它复杂的定单类型与隐藏自行决定价格结合使用最少量条件，以避免通过小额定单的喷洒来检测。由于不显示价格，所以没有传统意义上的“价格暴露”。然后，兴趣相反的大宗交易者在定单与常驻定单的限额相符之前，仅仅通过重复输入和取消总是处在较差价格水平上的定单，可以发现第一定单的限定，和的确拥有这样做的信用职责。因此，尽管在交易之前价格预期是不变的，但是，即使卖家另一方面愿意接受降到$29.90的任何价格，在ECN上输入大额隐藏定单按$30.00购买的交易者的确也应该期望按$30.00交易。

其结果是，由于大多数参与者迅速得知，潜伏在暗处和采取使其它人愿意每次少量示出或显示的价格可以更有利可图，所以像SuperMontage那样的电子帐簿难以在有吸引力的价格水平上吸引比较大额的定单。这导致市场演变成平均交易数量总是下降到大约500股，而总交易量和平均机构定单数量不断增大。

在这种环境下，迫切需要一种当对方当事人同样进取时，将价格改进所得的利益奖励给愿意秘密表达他们的真正价格进取性的交易者的电子交易系统。在这样的大宗交易解决方案中，进取交易者的最佳策略应该是输入他们带有进取性价格的定单，而消极交易者自然通过输入消极定价定单而得到最好服务。

然后，解决这样的需要不能以牺牲传统市场上的电子交易系统的主要可觉察优点为代价，这个优点就是无人为仲裁或无交易前信息泄漏地即时进行交易的能力。

简而言之，面临的挑战是防止可在进取限定价格上用电子手段执行的定单在对方事实上也愿意进取时，实际上在这样的进取性价格上被执行。

为了在损失电子速度执行的可觉察优点的情况下和在没有第三方当事人介入的情况下，使天平向有利于输入进取性定单的当事人这一方倾斜，必须识别可以加强愿意表达进取性价格的当事人的谈判位置的值项。一种这样的值项是信息。2003年6月24日提供的相关申请第10/603,100号；2001年5月31日提出的相关申请第09/870,845号；2000年12月29日提出的相关申请第09/750,768号；和2000年6月1日提出的相关申请第09/585,049号(特此全文引用以供参考)示出了愿意秘密地向计算机系统公开CertifiedTrading Interest(认证交易兴趣)信息的当事人如何可以获得从有兴趣与他们交易的其它当事人那里接收Certified Trading Interest信息的权利。这样就打开了当交易者在交易系统中输入进取定价定单时，使信息流的箭头反向的可能性：不向第三方当事人示出进取性价格，而是让进取性价格帮助交易者吸引带有更消极发盘的来自第三方当事人的信息。

发明内容

本发明的系统通过使市场参与者将进取定价定单输入电子匹配帐簿中，而无需向对方当事人公开这样的限定价格，或者变成自由检测这样限定价格的策略的牺牲品，并且当发现匹配定单时，接受立即执行，如果两个定单的限定允许，将价格定得与公布参考价，譬如，全国市场(National Market)中间价接近，克服了已知自动交易系统的局限性。优选实施例使市场参与者：(1)将隐藏定单输入系统的电子匹配帐簿中，而不用向公众公开定单的属方和价格；(2)在如果匹配定单允许，与全国市场中间价(或其它参考价)接近的价格上，接受对按价格时间优先级排列的帐簿中的匹配的对方定单的立即执行；(3)使系统发出“ACTIVE SYMBOL”指示符，以引诱其它参与者将定单输入这个证券中；(4)当至少与全国市场中间价(或其它参考价)一样进取地定价定单，和第二市场参与者将消极对方定单输入系统显示的大宗价格范围(Block Price Range)内时，接收“CONTRA PRESENT”通知；和(5)如果至少与全国市场中间价(或其它参考价)一样进取地作了定价，在任何时候，或者，如果比中间价更消极地作了定价，在(比如说，5秒)的延迟之后，提高定单价格，以便不应用旨在通过在不断提高进取性价格上依次取消和取代对方定单检测长期有效定单的真正限定价格的策略。

优选实施例包含以在公开市场上交易的替代物，譬如，金融证券形式进行大宗交易的方法，该方法包含如下步骤：用电子手段计算或接收少量替代物的参考价，譬如，买入和卖出替代物的最佳交易商报价的平均值；用电子手段存储参考价；用电子手段在网络上接收来自第一参与者的信息，该信息包括买入和卖出替代物的大宗定单；和用电子手段将来自第一参与者的信息存储在电子匹配帐簿中。如果该定单与以前输入按价格时间优先级排列的电子匹配帐簿中的其它定单匹配，该方法包含在带有与参考价尽可能接近的价格的匹配定单的价格和数量属性内和在两个定单允许的范围内进行交易，和向用户和向清算和管制实体报告进行的交易。如果定单不匹配，比参考价更消极地定价第一定单，和存在比参考价更进取(但没有进取到足以与第一参与者定单匹配)定价的来自第二市场参与者的常驻对方定单，该方法包含用电子手段将CONTRA PRESENT通知发送给第二市场参与者，通知它们对方存在消极定单；每当第二参与者定单被取消或修改成比参考价更消极的价格时，除去CONTRA PRESENT通知；继续重新计算参考价和重新定价来自被选为使他们的定单“钉住”参考价的第一参与者和第二参与者的定单；并且当参考价的变化使这样的执行在两个定单的范围内成为可能时，对带有固定价格的定单执行钉住定单，和向用户和向清算和管制实体报告进行的交易。

有利的是，正如与参考价相比较确定的那样，可以以允许输入最进取定单的交易者改进价格的方式进行交易。例如，如果第一参与者输入比参考价高3美分买入的定单，和第二参与者输入比参考价低2美分卖出的定单，那么，在参考价本身上进行交易，将大部分价格改进给予具有3-美分进取性的定单。如果买入定单比参考价高3美分，但卖出定单被设置成比参考价高1美分，那么，在参考价加1美分上进行交易；在这种情况下，只有进取性定单接受价格改进。如果买入定单被设置在参考价上和卖出定单被设置在比参考价高1美分，可以不进行交易，但买家接收到CONTRA PRESENT通知。由于在交易之前发布这个信息使第一参与者可以撤回，所以使事实上渴望交易的第二参与者空手而归。这样的交易者最有可能通过输入带有进取性限定的定单实现他或她的交易目标。另一方面，如果这样的第二参与者事实上愿意等待以更好价格交易的机会，那么，通过邀请第一参与者考虑更进取的价格，CONTRA PRESENT通知起建设性作用。在这两种情况下，与进取性交易者在交易之前将信息泄漏给其它人，常常导致负面的市场影响和低下的填充率的电子市场截然不同，进取性交易者是包含在CONTRA PRESENT通知中的信息的受益者。由于这种信息流的反转，CONTRA PRESENT通知激励交易者表达他们真正的交易偏爱，导致更大的流动性和更有效的价格发现。

一个可替代实施例包含如下附加步骤：用电子手段计算大宗价格范围(BPR)；用电子手段将BPR存储在计算机可读媒体上；用电子手段在像因特网那样的通信网络上发送包括BPR和参考价信息的数据；和通过图形用户界面向数个用户显示数据。可替代实施例最好保持在直到一定的时间间隔，譬如，60秒内固定的BPR，除参考价因系统外部的事件突然改变，参考价本身不断地被更新之外。在这个可替代实施例中，除了上述的步骤之外，当第一参与者输入与当前在系统中的任何对方定单不匹配，但至少与BPR一样进取地定价的定单时，即，如果是等于或高于Block Bid(大宗递盘)的买入定单，或等于或低于Block Offer(大宗发盘)的卖出定单，其中，Block Bid和Block Offer分别形成BPR的下限和上限，本发明的系统用电子手段通知用户在合议系统中存在对交易替代物的主动兴趣。在这个可替代实施例中，只有当至少与BPR一样进取地定价对方的定单时，才发送存在对方的通知，和如果随后发现引起对方给出条件的两个定单之一因一个或两个定单可能钉住的参考价的变化，或因BPR本身的变化而比BPR更消极地定价，除去存在对方的通知。

另一个可替代实施例起像在上述两个实施例之一中所述那样的作用，但另外要求已经输入相对于参考价来说消极的定单的第一参与者在允许用更进取的价格取代该定单之前，必须等待通知的最小时间量，譬如，5秒钟。在这个可替代实施例中，可能已经得到在系统内存在消极对方的通知的第二参与者接着可以选择取消或重新定价定单，以便执行第一参与者的还盘。

在图1中给出了本发明的优选计算机系统实施例的示意图。

该系统最好包含交易促进系统100。所述交易促进系统100通过像因特网那样的通信网络80和像FIX网络90那样的金融信息交换网络与参与者连接。系统100通过销售商网络70接收来自销售商60的市场数据。将定单发送到执行引擎50。当所述执行引擎接收到时，自动交易匹配定单。优选实施例包含负责与每个客户GUI的连接的网络服务器子系统110；将连接提供给后台系统和客户定单管理系统的金融信息交换(FIX)服务器120；和负责实现像这里所述那样的系统的定单管理逻辑的定单管理器子系统130。促进器模块140创立旨在将兴趣集中在交易上和将用户引向交易的信息事件。交易促进系统100跟踪事务处理数据库150中它的定单的状态。该系统确定定单与通过分析服务器160计算的像全国最佳递盘和发盘中间价那样的参考价相比的价格进取性。在可替代实施例中，该系统也估量相对于接着也由分析服务器160计算的大宗价格范围的价格进取性：定单的价格可以(a)比BPR更消极，或(b)是进取的，这意味着在BPR内或比BPR更进取。执行引擎50通过通信网络80接收定单，和用电子手段将它们存储在交易容错数据库(帐簿51)中；它在这同一个网络上将执行结果往回报告给交易促进系统100。在可替代实施例中，执行引擎50可以作为系统100内的附加部件寄宿在本地。

参与者使用图形用户界面20将定单输入系统中。当执行所述定单时，利用FIX协议将结果报告给它们的保荐经纪人95或它们自己公司的定单管理系统(OMS)10，以便加以处理。

最好要求所有定单都是“大宗定单”，这意味着它们的数额是大宗数量的倍数。例如，如果大宗数量是100,000，GUI只允许是100,000股的倍数的定单。定单可以具有限定价格或更好价格，或使它们钉住像全国市场上最佳递盘和发盘之间的中间价那样的市场指导价。将所有有效大宗定单都直接发送到将它们存储在帐簿50中的执行引擎50。在可替代实施例中，接受任何数额的定单。

优选实施例根据先到先服务原则处理定单。在可替代实施例中，为了另外激励交易者输入进取定价定单，该系统通告不对匹配加以考虑地接收和排队定单的累积时段，再加上按价格时间优先级将定单输入执行引擎50中的交易时段，其中，首先输入买入定单，随后输入卖出定单，并且当按定单输入检测到匹配时，像上述那样执行它们。例如，该系统可以通告15分钟的累积时段，以及执行时段占据每个15分钟间隔的最后一秒钟。在这个实施例中，该系统整天就在累积时段和交易时段之间交替变化，例如，累积时段为8:30:00-8:44:59；8:45-8:59:59；9:00-9:14:59等。

GUI 20使有兴趣大宗交易给定证券的交易者可以点击像显示在主屏上方的方框中那样的证券代码，引出定单输入对话框和按照他或她预先配置的偏爱自动填充定单输入对话框的字段。交易者可以按需要编辑这些字段和按下标为“Submit(提交)”的按钮输入定单。

如果新输入的定单与一个或多个前帐簿定单匹配(新定单属于同一证券，处在相对方，和具有等于或高于长期有效帐簿定单的价格)，执行引擎50按价格时间优先级自动排列对方定单和以两个定单的限定内与系统当前参考价最接近的价格，在输入定单和长期有效定单之间进行交易，直到前者或后者之一被完全执行，和用电子手段向用于统一行情显示系统的自动确认和交易(ACT)服务40和向保荐经纪人的清算公司30报告交易结果。还将执行的通知发送到图形用户界面20，以便将交易结果通知交易者。如果另一方面，在帐簿中不存在匹配定单，新定单仍然存储在帐簿中，作为长期有效定单。在优选实施例中，客户可以选择让它们的定单由第三方经纪人保荐，在这种情况下，还通过FIX将交易结果报告给保荐经纪人的后台系统95。在优选实施例中，只有在最小延迟(比方说，5秒)之后，才允许输入消极定单(与当前参考价相比)的参与者提高那个定单的价格进取性。在可替代实施例中，用户可以马上取代定单，但取代定单只有在指定最小延迟之后才有资格匹配。在又一个可替代实施例中，所有定单在系统公布的累积时段内都没有资格匹配，并在累积时段过去之后，按属方、价格进取性和时间的顺序装入执行引擎50中。在又一个可替代实施例中，交易者可以随时输入定单和修改价格，和系统操作人员监视特定用户是否正从事于“探明”常驻定单限定的活动(如果是，取消它们的帐户)。

为了提高交易的可能性，将系统的定单管理器130与当新输入的定单未发现匹配，而是存储在帐簿51中作为长期有效定单时自动起作用的促进器模块140连接。一旦输入买入(卖出)定单，促进器就通过CONTRA PRESENT通知，通知定价成等于或低于(等于或高于)参考价的长期有效卖出(买入)定单已经输入了对方定单。在可替代实施例中，输入定单的对方的所有长期有效定单都有资格接收这样的通知。

在可替代实施例中，只有合理定价的定单才成为促进主体；大宗交易的合理价格范围(大宗价格范围)由分析服务器160计算和公布在每60秒钟更新一次的交易者的图形用户界面20上。在这个可替代实施例中，促进器140不泄漏定单的价格或属方地生成鼓励其它人输入相同证券的定单的信息事件。

在这个实施例中，取决于系统数据库150内已知的定单的状态，当使促进器140起作用时，存在两种可能作用流。

在第一种情况下，当新输入的定单未发现匹配时，系统的状态使得在系统内不存在合理定价的对方定单。将消息传送给预订这种证券的所有当事人，表示在新输入定单的代码主体中存在活动(如果代码已经处在“活动”状态，省略这个步骤)。如图2所示，图形用户界面20将在定单输入对话框205上面的橙色方框215中显示活动代码。该系统最好使看见活动代码和有兴趣大宗交易这种证券的第二参与者通过点击该代码引出定单输入对话框。该系统最好按照第二参与者的预先配置偏爱填充定单输入对话框205的所有字段。第二参与者借助于代码是“活动”的知识行动。因此，他将了解到以前输入了使ACTIVE SYMBOL通知发出的第一定单，和这个第一定单被定价在BPR内。如果第一定单是对方的和仍然打开，利用这个信息，第二参与者可以选择提交大宗发盘(大宗递盘)的限定买入(卖出)定单，以保证交易进行。在优选实施例中，一旦代码变成活动的，它就这样保持至少60秒(或其它预定时段)；与BPR更新结合在一起复审打开活动代码通知，和只有当所述通知在超过60秒内未解决和在BPR更新的时候系统内当前打开的这个代码中没有更合理定价的定单时才除去打开活动代码通知。在可替代实施例中，实时地更新ACTIVE SYMBOL通知，以反映此时系统内是否存在合理定价定单。在另一个可替代实施例中，除了颜色外，GUI还显示系统内当前打开的合理定价定单的数量。

在第二种情况下，存在常驻在帐簿51中的合理定价对方定单，但这个对方定单不具备相当的进取性，足以满足新输入定单提出的限定价格。在这种情况下，促进器模块140将CONTRA PRESENT通知发送给有资格至少与当前参考价一样进取地定价的常驻对方定单。如果对方定单当前未满足这个准则，但由于参考价的变化在稍后时间满足这个准则，那么，在条件满足的稍后时间发送CONTRA PRESENT通知。一旦被发送，只要定单保持合理定价，CONTRAPRESENT通知就一起保持有效。在可替代实施例中，不存在与参考价有关的条件，和满足合理价格条件的任何长期有效对方定单都有资格接收CONTRAPRESENT通知。如图2所示，图形用户界面20通过加亮定单输入对话框205上面的黄色方框225中的代码显示CONTRA PRESENT通知。因此，使代码成为活动的第一参与者将看到现有存在对方。该系统最好使所述第一参与者能够以进取性的价格重新定价定单，和取代定单，以便执行第二参与者的定单。在优选实施例中，该系统自动提议BPR的进取性一端，作为默认价格，以鼓励导致交易的策略；然后，交易者可以点击接受提议的价格限定，或如有需要修改定单对数。在可替代实施例中，该系统使用户能够将进取性定单类型配置成限于BPR中的较好者或与当前全国市场中间价相差可配置的数美分(或它的几分之一)，然后，这个进取性定单类型是在存在CONTRA PRESENT通知的情况下被提议为默认类型的那一种类型。在优选实施例中，使用户可以通过点击带有代码的黄色方框，然后按下为这个目的标记的单个按钮，输入使系统尝试执行对方定单的定单。在可替代实施例中，图形用户界面20让交易者选择新的价格和按下标为“Replace(取代)”的按钮。如果没有一个带有长期有效定单的交易者提高他们的价格进取性，并在30秒之后仍然存在长期有效对方定单，如果接着发现第二参与者的定单至少与参考价一样进取地定价，那么，轮到第二参与者有资格获知系统内存在长期有效对方定单。正如前面针对第一参与者所述的那样，该系统最好通过黄色方框显示这个信息；和所述第二参与者可以选择提高他或她的价格进取性，以便达成交易。在另一个实施例中，只要求第二参与者的定单是“合理定价的”，以便有资格在30秒(或预定时段)之后接收CONTRA PRESENT通知。在这两种情况下，30秒延迟阻止第二参与者尝试探查系统，发现是否只存在对方，以便稍后撤回；常驻定单有30秒钟来决定接下还盘还是撤回。在另一个可替代实施例中，没有30秒延迟，和所有交易者同时接收CONTRA PRESENT通知，但存在可以不取消定单的5-秒最小有效时间。在另一个可替代实施例中，所有用户马上接收CONTRA PRESENT通知，而不存在最小有效时间条件。在可替代实施例中，交易者可以将GUI 20配置成当接收到CONTRA PRESENT通知时，用进取性价格自动取代他们的定单。在这个最后实施例中，如果在带有自动重新定价定单和竞争执行相同对方定单的系统内存在多个定单，该系统按价格时间优先级执行响应定单：为了执行输入对方定单，长期有效定单首先按价格竞争，然后，如果两个定单具有相同的进取性价格限定，随着转到第一定单的优先级被输入，按输入的时间竞争。

计算大宗价格范围(BPR)的优选算法力图根据股票的波动性确定在下一个60秒内交易大宗定单的合理价格。在优选实施例中，这个范围基于自更新BPR的最后时间以来将交易结果报告给统一行情显示系统的价格，采用全国最佳递盘和发盘的当前中间价上下的对称价格范围。这个范围相对于中间价上下延伸与自最近BPR更新以来观察的价格波动有直接关系的数量。

缩写

缩写	全称	说明
			ACT	自动确认和交易服务	允许实时比较交易和将清算信息转发

		到保管信托和清算公司(DTCC)的Nasdaq设施
			API	应用程序编程接口	使第三方开发者能够创建与系统连接和使远程用户可以访问它的前端应用软件
BlockLink		使用户能够通过将交易邀请发送给可能对方当事人促进大宗交易的相关应用程序的系统主体
			BPR	大宗价格范围	认为有理由影响大宗交易的价格范围
Enum	枚举	用于表示电子信息存储设施中的数据类型的术语，其中，所取的可能值都在枚举表内
			PCM	忠实资本市场	本发明的系统主体的可能保荐经纪人的例子
FIX	金融信息交换协议	用于在金融市场中传达定单和交易信息的协议
			GUI	图形用户界面	旨在使访问本发明的系统主体得以实现的前端应用程序
INT	整数	通常指电子信息存储设施中的数据类型
			IOC	马上或取消	表示如果不能马上填充定单，则应该取消它的定单属性
IOI	兴趣指示	用在金融市场中指示有兴趣购买或卖出证券的消息
			LBQ	大宗数量	用在本发明的系统主体中提高定单匹配的机会的每个代码的标准化定单数额
LQT	流动性跟踪器	本文引用的相关应用程序的Nasdaq设施主体
			MID	中间价	距离全国市场上的最佳递盘和最佳发盘相同的价格

MPID	市场参与者ID	用于标识Nasdaq市场上的经纪交易商的4字母缩写
			NotHeld		让经纪人不受定单显示约束地自行决定管理定单和管理与确定定单有关的规则的定单属性
OATS	定单审查追踪系统	全国证券交易商为了市场监管运行的系统
			OMS	定单管理系统	允许公司跟踪定单的状态、执行或正在工作的部分等的计算机系统，
Peg		指示参照全国市场，在有匹配机会的时刻计算限定价格的定单属性
			PegOffset		将数美分附加在钉住价格上的定单属性
Q/A	质量保证	软件开发过程的组成部分
			Ticket		从定单管理系统发送到经纪人或交易系统的消息，指示通过这个经纪人或交易系统交易一定股数的意图
TIF	有效时间	指示定单有效的时间间隔的定单属性

附图说明

图1是本发明的优选计算机系统实施例的示意图；

图2描绘了打开定单输入对话框的优选GUI；

图3(a)和3(b)描绘了包括系统与参与者和相关公司的电子系统的交互的优选系统和方法的操作；

图4示出了优选实施例中从清算的角度来看交易的生命周期；

图5描绘了最好在处理New Ticket(新票证)的同时执行的优选步骤；

图6描绘了处理Cancel Ticket(取消票证)消息的优选步骤；

图7描绘了处理有效定单的优选步骤；

图8描绘了优选监视表配置对话框；

图9描绘了计算BPR的优选方法的步骤；和

图10描绘了标识监视证券的优选GUI。

具体实施方式

下文是本发明的优选和可替代实施例的详细描述。

关键特征。下面是本发明的特征的优选列表：

1.秘密大宗撮合。将定单发送到撮合具有价格时间优先级的定单和报告锁定交易以便进行清算的匹配引擎。匹配引擎可以远程寄宿。

2.大宗数量。所有定单最好都以按每种证券配置的大宗数量的倍数输入。通过鼓励用户使用相同的定单数量，大宗证券的数额阻止了博弈，并减轻了完成填充之后的“买家懊悔”问题或出错方的担心。

3.ACTIVE SYMBOL通知。在可替代实施例中，当确定证券交易的双方都对大宗交易感兴趣时，系统也通知用户。这样就及时把注意力集中在定单输入上，从而提高了填充速度。

4.CONTRA PRESENT通知。当输入几乎匹配的对方定单时，通知系统中带有进取定价定单(与参考价有关)的交易者。30秒钟之后，如果那时所述第二定单满足价格进取性条件，还可以警告带有所述第二定单的参与者存在相近匹配。CONTRA PRESENT通知将有关消极还盘(counter offer)的信息奖励给输入进取定价定单的交易者，从而鼓励交易者表达他们真正的价格进取性。

5.与后台的FIX连接。优选实施例支持直接或通过FIX服务局将FIX执行结果传送到买方定单管理系统的机制。这种情况支持买方客户与保荐经纪人的收盘匿名。

6.FIX票证处理应用。客户可以将股票从他们的定单管理系统放入系统中(代码、数量和属方)，然后利用GUI 20逐渐达到输入的数量。可以更新OMS，以便跟踪各个工作定单，或者，取决于客户机的配置，只根据填充情况。

7.API/GUI访问。系统提供为已经接收到CONTRA PRESENT通知的感兴趣证券的监视表突出显示代码的设计成带有来自机构交易者的输入的可选交易前端。在带有ACTIVE SYMBOL通知的可替代实施例中，也显示这个ACTIVESYMBOL通知。系统还展示应用程序编程接口(API)，使许可的第三方当事人能够代表他们的顾客接收这样的通知，并通过他们自己的前端应用程序提供可视性。在可替代实施例中，还可以通过为市场数据服务的FIX协议获取这样的通知和大宗价格范围。

本发明包含将系统与参与者和相关公司，譬如，保荐经纪人或他们的清算公司的电子系统整合在一起的优选结构。在图3(a)和3(b)中表示了这种整合的概况。这些图形例示了导致如下所述的参与者C和E之间的交易的流程。对于已经在系统中的长期有效定单，新的参与者可以输入对方定单。该系统发出CONTRA PRESENT通知；将常驻定单修改成较高价格进取性水平，产生一个被执行的交易。

该系统最好通过如下步骤促进上述例子中的交易：

1.在步骤1中，用户将定单输入该系统中，最好利用图形用户界面20。

2.该系统最好在步骤2中指定记录经纪人，并根据记录经纪人和顾客ID，对照任何信用额度验证定单。将定单信息存储在数据库150中。

3.在步骤3中，定单管理器130将定单发送到执行引擎50，并期待指示定单按输入填充、存储成有效限定定单、还是如果定单无效则被取消的，从执行引擎返回的定单更新消息。

4.一旦发现在执行引擎中未执行或取消定单，OM 130就将定单项事件通知促进器模块140。

5.促进器模块140发现存在带有进取性价格的存在于系统之中的对方；它马上将CONTRA PRESENT通知发送给常驻对方，而如果接着发现新定单是进取性的，则在例如30秒延迟之后，安排向发出新定单的第二参与者发布这同一个消息的事件。

6.在步骤6中，将对方存在消息传送给常驻定单。

7.步骤7最好比发送第一对方存在消息晚30秒发生：如果对方存在状况持续下去，并且接着与参考价相比，进取性地定价新的定单，则将CONTRAPRESENT通知传送给新定单。

8.在步骤8中，常驻定单(即，将服务局用于他们与系统的FIX连接的有保荐顾客)在他们的GUI 200上接收CONTRA PRESENT通知，并修改定单以提高价格进取性。

9.在步骤9中，OM 130发送修改定单请求并更新OM数据库150中定单的状态。

10.在步骤10中，OM 130将修改定单请求传送给执行引擎50。

11.在步骤11中，执行引擎50确定新的价格进取性足以锁定交易，并且最好将这个交易结果与清算对方信息一起报告给ACT。在可替代实施例中，只为行情显示系统报告交易结果，而将清算信息一直保留到收盘，以便延迟将交易结果通知保荐经纪人的时间。

12.执行引擎50最好向定单管理器130报告执行结果，OM 130更新它的数据库150中的定单的状态并更新消耗的信用。

13.在步骤13中，定单管理器130向网络服务器110和FIX服务器120报告交易结果。

14.网络服务器110和FIX服务器120将执行消息转发给它们各自的客户。

15.第二客户通过服务局接收FIX执行结果。

16.在交易过程的最后步骤中，将执行结果的引出副本(drop copy)发送给保荐经纪人。在优选实施例中，这是在收盘时完成的。在可替代实施例，这是马上完成的，并将保荐经纪人保荐的所有交易活动直接通知保荐经纪人。

设施

该系统最好包含如下设施或子系统：

1.网络服务器110。网络服务器子系统使客户能够通过图形用户界面200访问该系统。这个界面最好是可以用于将定单输入该系统中的最合适界面。所有用户必须下载交易应用程序(GUI)，或开发出为活动代码和对方存在标志提供满意可视性的GUI。网络服务器110最好通过公布的API支持与交易前端的连接。

2.FIX服务器120。FIX服务器使用户(客户)能够打开连接和根据FIX协议交换金融信息消息。FIX服务器的源代码可从开放源代码库中获得。FIX服务器最好配置成接收Ticket(New，Cancel，Cancel/Replace)和定单状态请求消息。它将推出包括定单更新和填充的执行。它最好支持与客户定单管理系统的直接连接，以及通过服务局的连接。FIX服务器还可以用于将执行消息(带有“完成”状态)传送给保荐经纪人，以便在交易处理之后设置。通常，这些消息在收盘时发出，但客户最好也可以在需要的时候请求系统当天将执行结果通知他们的经纪人。

3.定单管理器130。定单管理器处理定单和随后的交易消息，将它们传递给执行引擎加以存储和执行。它最好接收来自分析服务器160的BPR更新消息，并通过跟踪至少与BPR一样好地定价定单，或消极定价定单的时间，维持它的定单上的价格进取性标志。

4.促进器模块140。如本文所述，定单管理器130最好包含负责通过谨慎发布有关定单的信息，促进匹配定单输入系统中的部件。

5.定单管理数据库150。定单管理器130最好跟踪交易和可完全恢复结构化查询语言(SQL)数据库中定单的状态。它还包含负责向清算公司报告交易结果，以及负责每日生成送给相应自我监管组织(SRO)的强制性报告的报告模块。

6.分析服务器160。分析服务器160接收将每个代码的市场活动状态(开始、停止、交易暂停)、所有Nasdaq和NYSE列出股票的内部最佳递盘和发盘(价格、总数额和时间标志)和来自全国市场系统统一行情显示系统的最后售出交易数据通知所述服务器的数据反馈。服务器将这个信息存储在像硬盘驱动器那样的计算机可读媒体上，并进行如上所述的分析计算，以确定参考价和大宗价格范围。它负责按代码向预订方公布参考价、BPR更新消息和交易暂停方面的变化。

7.求助桌面。该系统最好包含求助桌面子系统，该求助桌面子系统包含像万维网GUI那样的用户界面。求助桌面操作人员可以访问这个界面，以加入/删除/修改与各个交易者相联系的客户公司、保荐经纪人或GUI帐户。求助桌面使交易操作人员能够根据定单ID或通过公司和代码查询系统，跟踪将客户定单输入系统中之后的事件的序列，和给予想要调用求助桌面的交易者对系统中他们定单的历史的详细响应。

8.系统操作管理。该系统最好还包含使系统操作人员能够管理所有设施的功能实现的系统操作控制台子系统。除了普通系统操作职责之外，该系统最好还使操作人员能够实现包括如下的其它职责：保密；审查；管理收盘和开盘事件的批处理；容量计划；和管理内部帐户(操作人员和求助桌面)的权利。

9.匹配引擎50。匹配引擎50将参与者的定单存储在电子匹配帐簿51中，并且当在重叠价格上输入买入定单和卖出定单时进行交易，如果两个定单的价格限定允许，将执行价格选择成与参考价接近。

下面更广泛地描述上述特征的优选实现。

FIX服务器。优选实施例最好在需要时将FIX协议用于与客户定单管理系统10和保荐经纪人的后台整合。图4示出了从清算的角度来看交易的生命周期。为了使用系统，客户最好能够在两个模型之间作出选择。第一模型是使用票证，以便于在多个市场目的地之间管理债务。票证是来自每个市场目的地(市场目的地是像当前系统那样，可以执行定单的地方)中帮助交易者监视他们正在交易多少股的客户定单管理系统的代用品。票证的用途是保证在所有目的地输入的累计股数决不会超过如客户定单管理系统10所知的客户所有定单的总股数。当交易者使用票证时，从OMS输入的票证出现在GUI 20上，而且只能对照这些票证输入定单。

如果定单属于同一证券、处在同一方且具有不大于以前输入的票证的数额，则选择使用票证的客户最好只能够将所述定单输入系统中。当交易者选择使用票证时，该系统最好通过执行如下步骤更新后台和第三方系统。

1.在步骤410中，将票证输入系统100中，作为没有价格的FIX定单。票证携带系统将其映射到特定GUI的终端ID。交易者看到显示在他/她的GUI上的票证。

2.在步骤420中，交易者对照这个票证输入本文称为“子”定单的定单。这个子定单与票证属于同一证券和同一方，和选择的数量是交易者配置的默认定单数量或票证数量的较少者。该系统最好验证该定单和将它传递给执行引擎50。在优选实施例中，通过带有Order Status＝New的FIX执行消息向OMS报告定单项事件。在可替代实施例中，当交易完成时(请看下面)，客户OMS只接收执行消息。

3.当针对这个定单发生交易时，执行引擎50最好向ACT报告关于行情显示系统和清算(步骤430)。然后，将交易结果通知定单管理器130。在优选实施例中，该系统接着将交易细节通知像GUI那样的API客户机和像顾客定单管理系统那样的FIX客户机。

4.在步骤450中，该系统最好将包括客户ID的FIX执行消息发送到执行经纪人。

5.该系统最好使用户能够在交易日或结束之前启动分配处理(在用户的选择下执行步骤440)。

6.优选系统在收盘时执行如下步骤(步骤460)。

a.将交易总结文件发送到保荐经纪人的清算公司。这个文件包含与清算有关的信息，包括代码、卖出或买入的股数和对方当事人的MPID。

b.OATS报告代表保荐经纪人给出定单追踪和执行的总结。该系统自动将OATS报告发送给保荐经纪人，以便转发给NASD。在可替代实施例中，将报告直接发送给NASD。这些文件传输是电子形式的，并使用文件传输协议(FTP)。

在优选实施例中，使用户能够选择不要求使用票证，而是使交易者开始定单输入步骤420的处理的可替代配置。其余步骤与如上所述相同。

在可替代实施例中，系统100由使用系统的所有客户的保荐经纪人寄宿，和包含本领域的普通技术人员可以容易地实现的或可通过专门销售商从市场上购买到的交易后处理子系统。在这个可替代实施例中，不需要收盘匿名，和可以马上发出经纪人执行报告。

FIX服务器120最好支持提供与客户定单管理系统10的连接的各种各样联网解决方案。例如，客机OMS可以直接与所述FIX服务器连接，或者，可以通过调停FIX服务器120和数个客户机之间的连接的FIX服务局与FIX服务器120通信。

当票证无效时或当客户机被配置成不使用票证时，FIX服务器120拒绝票证；票证拒绝消息最好在文本字段中携带可理解的拒绝理由。如果由于定单数量少于这种证券的大宗数量(LBQ)而发送拒绝消息，最好为拒绝消息中的消息文本中的信息给出正确的LBQ。在优选实施例中，FIX服务器120最好支持如下到达消息：FIX New Order、Cancel Order、Cancel/Replace和OrderStatus Request。如果客户使用票证，则发出消息最好包括与给定票证的子定单有关的Order Update(FIX执行消息携带底层票证的Order-ID)。不使用票证的客户最好只接收执行消息(FIX执行消息)。在可替代实施例中，不利用票证的客户接收与通过GUI输入的定单有关的每个事件的Order Update消息，包括New Order确认消息，以便OMS可以逐个事件地跟踪正在运行的总模型，以及已经执行的数额。

FIX服务器120最好支持使操作人员无需改变系统软件就能够设置和定制新的客户机连接的万维网配置屏幕。如上所述，FIX买方客户机最好可以配置成只用于(a)FIX执行，或(b)支持票证处理和执行报告。FIX保荐经纪人客户机最好配置成只接收执行结果。在可替代实施例中，可以将保荐经纪人的FIX连接配置成接收发送到有保荐客户的OMS的每个消息的引出副本。除了每次执行发送的执行消息之外，配置选项最好包括当定单完成时，发送最后FIX执行消息，以及设置成“完成”的Order Status字段，以指示对这个定单的工作已完成的选项。

定单管理器。定单管理器130起消息处理器的作用。在如下的段落中，将描述各种各样消息的处理。

该系统最好使用户能够输入New Ticket消息。New Ticket消息是带有Order Type＝Market和没有限定价格的FIX New Order消息。带有限定价格的FIX Order将被拒绝。在可替代实施例中，可以在系统的应用程序编程接口(API)上提交这个消息。

如下的步骤最好在步骤510中接收到票证之后，在处理New Ticket(参见图5)的时候执行。

●验证。在步骤520中，该系统最好通过首先验证FIX New Order消息中的字段处理新定单。票证必须含有有效的Client-ID、Trader-ID(映射到专门GUI)、证券和属方(买入或卖出)，和至少与这个证券的大宗数量一样大。Cloud9最好接受标识为“Market(市场)”定单和“Not Held(不持有)”的FIX Order(票证)，并拒绝含有限定价格的票证。在可替代实施例中，对价格和Not Held状态的限制不是强制的。最好只允许客户在每一方每种证券拥有一种票证。如果以前的票证仍然许可，则同一证券的第二买入票证或第二卖出票证将被拒绝。如果以前的票证已被执行或取消，那么，你可以输入第二票证；它将取代GUI前端上的第一票证。可替代实施例应用了能够为每种证券显示多个票证的前端，和允许客户输入任何个数的票证。其它商业FIX定单属性将不被忽略。最好用合理的代码将拒绝票证显示在GUI上。

●处理。该系统最好将有效票证存储在数据库150中。然后，在步骤540中，通过网络服务器110将票证显示在客户GUI上，而在步骤530中，通过FIX服务器120确认票证返回到客户OMS。下表给出了优选实施例中Ticket消息中的所需字段。

字段	说明
		ClientID	输入票证的公司
ClientTicket ID	专用于这个公司
		Trader ID	将看见票证的GUI
Quantity	股数
		Side	只买入或卖出
Price	必须空着

Symbol	在系统内受到支持
		Type	必须是市场
NotHeldFlag	必须设置

该系统最好使用户能够输入Cancel/Replace Ticket消息。Cancel/Replace Ticket最好作为带有前打开票证的ClientTicketID和新票证的ClientTicketID的FIX Cancel/Replace Order提交。在可替代实施例中，可以在API上提交这个消息。在优选实施例中，一旦接收到Cancel/ReplaceTicket消息，该系统就执行如下步骤。

●验证。如果新数量减去已经执行的数量(新“许可数”)小于该代码的系统大宗数量，或如果小于放在执行引擎上作为打开定单(open order)的总股数(许可数小于工作数)，本发明的系统主体最好拒绝Cancel/ReplaceTicket消息。

●处理。如果接受请求，则Cloud9最好将票证数额修改成可应用于任何随后定单项事件并通过网络服务器110将变化推给客户GUI。最好还通过FIX确认返回到客户OMS的变化。

该系统最好使用户能够输入Cancel Ticket请求。Cancel Ticket消息是带有前打开票证的ClientTicketID的FIX Cancel Order消息。在可替代实施例中，可以在API上提交这个消息。本发明的系统主体按如下处理CancelTicket消息(参见图6)。

●验证。该系统最好通过保证指向打开票证，在步骤610中验证CancelRequest消息的字段。

●处理。如果存在打开定单，则在步骤620中，该系统将首先尝试取消与票证相联系的所有打开定单，然后，动态地用消息报告取消之前完成的任何执行结果630(当所有相关定单都得到执行或被取消，和Cloud9定单管理器的数据库在任何填充的状态方面都与执行引擎的数据库一致时，结束这个“消除”处理)。当任何打开定单都被消除时，在步骤640中，如果有的话，该系统将确认带有指示被取消的数额的结果的Cancel Ticket。在步骤650中，通过网络服务器将成功的Cancel Ticket请求通知客户GUI。

该系统最好使用户能够输入New Order消息。New Order消息最好通过GUI或API提交，并包含以限定价格或更好价格买入或卖出给定证券的给定大宗手数的请求。在优选实施例中，用户也可以选择钉住价格限定，在这种情况下，将定单限制在绝对限定价格与钉住限定价格之间的较不进取价格上。在可替代实施例中，用户通过利用FIX ExecInstr字段，将票证(带有ExecInstr＝“suspended”的FIX定单)与新定单(未挂起)区分开，来选择以挂起通过FIX输入New Order，或者根本不选择使用票证而将他们所有的FIX定单解释成New Order消息。New Order消息最好像如下那样管理。

验证。该系统最好验证定单是针对受支持证券的大宗数量的倍数。在可替代实施例中，定单可以针对任意数量。优选定单验证处理中的另一个步骤是核实定单包含价格字段。在可替代实施例中，如果用户选择钉住价格，在这种情况下，钉住定单可以不受限制地浮动，那么，放弃这种要求。优选实施例中支持的钉住类型是钉住NBBO中间价，或根本不钉住。正如本领域的普通技术人员所知的那样，可替代实施例支持另外的钉住属性。该系统最好还验证定单的属方是买入还是卖出。可替代实施例还支持短期卖出定单。参数PegOffest确定相对于应该使定单得到定价的钉住值(NBBO中间价)的美分数(或它的几分之一)。如果定单不是钉住的，最好忽略PegOffest属性。该系统最好向GUI客户机报告拒绝的定单，以及可理解的错误码。如果客户使用了票证处理，验证步骤最好还检验定单的数额不超过相关票证的数额，并且与票证属于同一方。如果输入定单的客户与保荐经纪人之间存在信用额度，作为验证处理的一部分，该系统最好核实定单不会破坏所述信用额度；信用核实处理将在下面作更详细描述。在优选实施例中，如果系统在最后5秒(或其它预定时段)内曾经接收到定单，该定单与当前定单属于同一证券和同一方，以及价格比当前定单更消极，并比那时的参考价更消极，那么，拒绝该定单。在可替代实施例中，接受这样的进取性提高定单，但在5-秒延迟过去之前，将其标记成不可执行的。在另一个可替代实施例中，在累积时段过去之前，所有定单都是不可执行的，但接着按属方、价格和输入的时间的顺序将它们提交给执行引擎50。在又一个可替代实施例中，没有这样的条件，可以在任何时候以任何价格输入定单并可马上执行，但是，当发现特定用户具有检验各种价格水平，以试图探明常驻定单的价格限定的模式时，通知求助桌面操作人员，而求助桌面操作人员给顾客打电话，通知他们这样的行为是不允许的。给予本实施例中的求助桌面操作人员特定准则，使得如果该行为不被纠正，则他们可以中止顾客在系统上进行交易的权利。

在优选实施例中，作为无效来拒绝IOC定单。在可替代实施例中，接受IOC定单，但有资格看到CONTRA PRESENT通知的长期有效(standing)对方定单的拥有者可以看到对方放入无法执行的IOC定单(在优选GUI中，代码暂时从橙色变成黄色，然后又变加橙色)。在又一个可替代实施例中，接受IOC定单，但不发送CONTRA PRESENT通知。

定单属性。优选实施例的系统期待找出如下表给出的New Order消息中的所需字段。

字段	注释
		ClientID	输入定单的公司
Trader ID	输入定单的GUI
		ClientOrderID	专用于这个公司
Quantity	股数
		Price	如果钉住，可选。如果钉住值超越限额，则带有限额的钉住定单起限定定单的作用。
Side	只买入或卖出
		Symbol	在一级市场上
Time-in-Force(TIF)	FIF是绝对时间或一天。所有定单都在交易日结束时失效。
		Peg	MID、NONE。在钉住值或更好值上执行。
PegOffset	要加入钉住价格中的带符号美元数。

处理。该系统最好通过如下步骤处理有效定单(参见图7)。

●在验证(步骤710)之后，在步骤720中马上将有效定单传递给执行引擎。响应将指示定单被拒绝，还是被接受，并放入帐簿中作为打开定单，或者处在执行未决状态。通过网络服务器将来自执行引擎的状态报告给GUI。

●如果客户使用FIX Ticket，该系统最好报告像接受或拒绝那样通过FIX返回的定单状态(步骤730)；执行未决状态在FIX中将作为开放状态报告(随后锁定的执行消息将接在后面)。FIX定单状态更新消息携带相关票证的ID。

●如果执行引擎指出定单是打开的，则该系统将通过帮助提高交易可能性的促进器启动处理740。

○优选实施例确定系统中是否存在进取性对方定单。如果处在对方和至少与代码的当前参考价一样进取地定价，则说定单就是进取性对方定单。带有进取性对方定单的用户马上接收CONTRA PRESENT通知。带有当前没有资格成为进取性的对方定单的用户只要它们以后因参考价的改变而成为进取性的，就有资格接收这样的通知。如果接着发现成为进取性的，最好在定单输入时刻加上30秒(或其它预定时段)的时间安排一个事件，以便将CONTRAPRESENT通知发送给新输入的定单。这种情况最好与常驻对方定单是否有资格接收通知无关地发生。因此，将消极定单输入系统中的用户可以让愿意在30秒或更长的间隔内输入进取性定单的那一个发现存在这样的定单。在可替代实施例中，如果发现常驻对方有资格首先接收这样的通知，则只发送延迟CONTRA PRESENT通知。

○在可替代实施例中，该系统还按定单输入确定新定单的价格是否至少与大宗价格范围(BPR)的最近公布价格一样进取，如果是，则将该定单标记成“合理定价的”。如果该定单被标识成“合理定价的”和代码还未处在“活动”状态，该系统向所有用户发出ACTIVE SYMBOL通知，邀请他们在这种证券上放入定单。在可替代实施例中，还计算大宗价格范围，只有当新定单的价格得到合理定价时，才发送CONTRA PRESENT通知，而如果以后确定因定单价格和BPR的改变，每个定单不再是合理地定价，则除去CONTRA PRESENT通知。

●在步骤750中，该系统等待其它定单到达。像上面从验证步骤710开始那样处理对方定单。带有相等或更好价格的对方定单最好与那时流行参考价尽可能接近地执行。

该系统最好使用户能够输入Cancel Order消息。Cancel Order是带有与前New/Replaced Order相对应的ClientOrderID的GUI/API消息。在可替代实施例中，还可以通过FIX接收取消定单请求。

验证。如果order ID无效或指向成为打开的在Cloud9内未知的定单，则拒绝取消定单请求。

处理。系统100最好通过如下步骤处理Cancel Order请求。

●Cloud9 OM 130将有效取消定单请求传递给执行引擎50。

●执行引擎50用取消的股票作为响应。取消响应可以在执行之后进行。对于已填充(fill)或到期定单，拒绝取消请求。

●一旦从执行引擎50接收到成功的取消响应，

○将定单状态更新消息推给GUI客户机20和分析服务器160。

○如果客户使用FIX Ticket，还通过FIX报告状态更新。

○释放分配给这个定单的信用。

○如果已经发出与这个定单相关的“CONTRA PRESENT”通知，则在不再存在对方的情况下，除去通知。

○注意：在带有ACTIVE SYMBOL通知的可替代实施例中，取消定单最好不除去这个通知。用户可以响应该通知继续在双方输入定单，产生交易机会。在另一个可替代实施例中，直接将ACTIVE SYMBOL状态与系统中合理定价定单的存在相联系。

该系统还使用户能够输入取消/取代定单请求，以修改以前输入的定单。在优选实施例中，Cancel/Replace Order是指向(ClientOrderID)前有效New/Replaced Order的GUI/API消息。在可替代实施例中，也可以通过FIX输入这个消息，对于New Order消息，具有与前面所述相同的配置选项。

验证。ClientOrderID应该指向有效定单。如果指向已知被取消、到期或执行的定单，或者，如果在最小延迟(比方说，5秒)过去之前，对以前消极定单提高了价格进取性，该系统最好拒绝取消/取代请求；上面针对NewOrder消息描述了这种功能的可替代实施例。该系统最好支持交易前信用检验。因此，如果定单的数额因取消/取代请求增大了，该系统首先对用户的帐户核实新数额未超过信用额度。拒绝信用验证失败的取代定单请求，使其成为无效的，以及用理由码说明信用理由。

Cancel/Replace Order处理。Cloud9 OM 130最好通过将其传递给执行引擎，处理取消/取代定单消息。执行引擎50以包括已执行股票、其余打开股票和平均价格的定单状态作出响应。

●交易消息。通过网络服务器110将状态更新消息推给GUI客户机。

●如果客户使用FIX Ticket，还通过FIX报告状态更新。

●如果取消/取代修改了定单的数额，则取消和取代分配给这个定单的信用量，以反映新的定单。

交易消息。执行引擎50通过交易消息将交易结果报告给定单管理器130。来自执行引擎的每个交易消息报告恰好涉及到两个定单的锁定交易。

执行引擎50将对照对方定单的帐簿匹配各个定单(一对多匹配)。在匹配检验之后可以存在多个各自交易，每个交易都将独立处理。

由于交易是单次事务处理，交易的两只腿应该作为一个单元来报告。

该系统的优选实施例期待找出交易消息的如下字段。

	说明	类型
			TradeID	有关这个交易的ID	字符串
NewOrder ID	一对多匹配中的“一”	字符串
			ResidentOrder ID	对方定单	字符串
Quantity	股数	INT
			NewAvgPrice	定单的所有执行的平均股票价格	FLOAT
NewFilled	执行的股票的数量	INT
			ResidenAvgPrice	定单的所有执行的平均股票价格	FLOAT
ResidenFilled	执行的股票的数量	INT
			Price	报告给ACT	FLOAT
ACTTrade ID	报告给ACT	字符串
			TimeStamp	报告给ACT	HHMMSSCC
BidTimeStamp	递盘方接收的最近报价(是否引起价格变化)	HHMMSSCC
			OfferTimeStamp	发盘方接收的最近报价(是否引起价格变化)	HHMMS SCC

处理交易消息。系统100最好通过如下步骤处理来自执行引擎50的交易消息。

●对于使用Ticket或请求FIX执行的客户，通过FIX向相关GUI客户机报告两次执行。

●更新信用，以反映根据交易价格消耗的实际信用量。

●如果交易者使用票证和票证上的剩余量小于这种代码的大宗数量，使票证上的剩余量作废。

●将大宗行情显示系统消息发送到网络服务器，以便传送给监视这种证券的GUI。大宗行情显示系统消息最好包含如下字段。

	说明	类型
			TimeStamp	由执行引擎报告	HHMMS SCC
Quantity	股数	INT
			Price		FLOAT
TotalQuantity	自开盘以来这种证券交易的总数	INT

该系统最好使交易者能够在紧急情况下，用单个请求取消以前输入系统中的所有定单。CancelAllClientOrder s是请求取消通过给定GUI输入的所有定单的来自网络服务器的消息。在可替代实施例中，也可以通过FIX传送这个消息。由于执行引擎50不知道顾客ID，Cloud9 OM将通过分别取消处在打开状态的与这个客户相联系的每个定单，像各个Cancel Order请求那样处理它们来处理cancel-all消息。

在包含大宗价格范围的实施例中，定单管理器130向分析服务器160预订存在打开定单的证券的BPR更新消息，和一旦接收到BPR更新消息，就更新合理定价条件。如果定单的合理价格状态发生变化，定单管理器130对这种证券的所有定单重新评估是否存在对方存在状况，和像上述那样更新对方存在通知。如果这导致定单上的对方存在状态发生变化，该系统最好将CONTRAPRESENT通知更新发送到受影响的UGI客户机。在带有ACTIVE SYMBOL通知的实施例中，该系统还根据BPR更新消息更新这些通知。如果代码处在活动状态，处在这种状态长达至少60秒(或其它预定时段)，并在BPR内不再存在任何定单，将代码设置成“not firm(没有公司)”状态，和网络服务器发送带有SymbolStatus＝Not Active的ACTIVE SYMBOL通知更新消息。在可替代实施例中，在任何BPR更新消息上更新活动代码状态，和即使在不到60秒内代码已经变稳定，也可以将活动代码状态设置成不活动状态。在又一个可替代实施例中，每次改变成全国市场最佳递盘和发盘价格和每次定单输入或取消都更新活动状态，以保证活动状态总是反映此时系统中存在活的、合理定价的可执行定单。

执行引擎。优选实施例中的执行引擎50与Cloud9系统100寄宿在同一设施中，并且两个系统在内联网上通信。在可替代实施例中，执行引擎50是Cloud9系统100内的一个部件。在这两个实施例中，执行引擎50的功能像下述那样。执行引擎50接收“匿名”定单，这意味着定单被剥去买方顾客ID，取而代之，用内部定单ID和保荐经纪人ID标识。正如我们在下面更详细描述的那样，执行引擎50通过检验，看看是否存在与输入定单匹配的常驻描述，并且利用价格时间优先级排列的常驻定单进行交易，处理新输入的定单。

优选实施例中的执行引擎50是在出故障的情况下恢复有关任何Cloud9交易的真正状态的记录簿。

执行引擎50的优选实施例支持限定定单和钉住NBBO中间价的定单。

在可替代实施例中，也支持本领域的普通技术人员所知的其它定单类型。例如，可替代执行引擎可以支持当将其它定单放入系统中时，按价格时间优先级排列自动增加其价格进取性，以保持在顶部位置的价格自行决定定单。然后，只要不破坏自行决定价格的绝对限定价格，最好将这样的定单重新定价成比同一代码和属方的最佳其它定单好一个跳动点(tick)。在可替代实施例的另一个例子中，该系统使交易者能够根据远期时间间隔内的成交量加权平均格式(VWAP)，譬如，从交易时间到收盘的VWAP，或在特定时间间隔，譬如，半小时间隔上的VWAP，输入在稍后时间定价的定单。例如，这样的定单可以被定价成一直购买到比11:00-12:00未来时间间隔内的VWAP高两美分。在这个实施例中。未来定价定单的ACTIVE SYMBOL通知显示定价定单的时间间隔，和务必与同一未来平均价格相关地定价对这样的通知作出响应的所有定单。因此，VWAP时间间隔有效地形成正被交易的替代物的定义的一部分。类似地，可替代实施例使用户能够按一对证券，或包含多种证券的一揽子输入定单。ACTIVE SYMBOL通知描述交易单元的组成，并期待交易者以相同交易单元的买入或卖出定单作出响应。在这些可替代实施例中，必须将参考价和大宗价格范围推广到VWAP定单或一揽子。对于VWAP定单，参考价是VWAP本身，而对于一对和一揽子，参考价是通过基于其参考价的每个项目的美元值加权、一对和一揽子中投资工具的价格的平均。

所有定单要么是限定指定，要么是与参考价相关定价的定单(钉住定单)。如果钉住定单也具有限定价格，那么，最好认为在限定值或钉住值更消极时定价定单。在带有像VWAP定单那样的未来定价定单的实施例中，最好不允许绝对限定价格。一旦交易被锁定，未来价格将变成什么就一目了然了。在带有未来定价VWAP定单的可替代实施例中，用户可以在VWAP定单上宣布停止价。如果这个价格水平在定价时段过去之前被打破，那么，该时段就过早结束了，只有在直到这个点的VWAP上，对相应部分的股票锁定交易。例如，如果市场价格在下一个小时过去了45分钟之后打破$21.15，那么，停止价为$21.15(例如，当前价可能是$21.01)的在下一个小时以未来VWAP买入100,000股的定单将关闭。由于已经过去了3/4时间，所以对于45分钟间隔上的VWAP的75,000股将锁定交易。这样的停止价保护买家避免在定价间隔内价格快速波动带来的风险，和让卖家享受到更高的市场价格，输入其余的股数。

执行引擎50最好允许钉住定单和限定定单相互影响。在出现匹配检验事件的时候，定价钉住定单，然后，在限定价格或钉住价格更消极时，与限定定单一样对待钉住定单。在优选实施例中，钉住值是作为参考价的NBBO中间价，加上可以是正或负的PegOffset量。

使优选实施例中的用户能够将钉住用于保护限定定单，以保证如果市场迅速变化，他们的定单不会在与NBBO相比突然表面得非常进取的价格上交易。GUI 20通过将特征表示成“价格保护”和提供“如果相对于NBBO中间价超过<n>美分，不交易”的选项，建议这种使用钉位的方式。

由于在系统中存在钉住定单和限定定单两者，匹配不仅可以按定单输入触发，而且可以作为使钉住定单的价格与对方定单的限定价格相符的NBBO价格的变化结果触发。

因此，在本发明的优选实施例中，匹配可以按新定单的输入触发，或按使钉住定单与其它定单相符的NBBO价格的变化触发。该系统最好实现如下处理，以便标识这样的匹配。

执行引擎50最好包含利用现有技术中已知的信息高速缓冲技术，从数据提供器60接收所有报价更新消息和跟踪当前最佳递盘和最佳发盘的部件。还最好使执行引擎50的部件能够为给定证券预订价格更新消息，此后，每当给定证券的最佳递盘或最佳发盘发生变化时，就接收消息。

执行引擎50最好保存在一方存在一个或多个限定定单和在另一方存在一个或多个钉住定单的代码的列表，预订这个列表中的所有证券的NBBO价格变化消息。为了这个部分的目的，当被执行引擎50接收时，如果其价格被取作钉住值，认为带有限定价格的钉住定单是钉住定单，和如果按输入将它们定价成限定定单(即，钉住值比限定价格更消极)，将带有限定价格的钉住定单当作限定定单。对于这个列表内的每个代码，执行引擎50最好设置定义成钉住定单的值等于最佳限定对方定单的参考价的值的买家阈值和/或与钉住买入定单类似地定义以便与限定买入定单相交的卖家阈值。一旦每个NBBO价格发生变化，该系统最好计算新的参考价和确定这个价格是否打破了买家阈值或卖家阈值。如果打破了买家阈值，该系统着手进行钉住买入定单和按价格时间优先级排列的限定对方定单之间的交易，就像刚刚将买入定单输入系统中那样，反之，当打破买家阈值时，对卖出定单作类似的处理。

如果多个钉住定单都有资格与卖出定单匹配，最好根据那时的有效价格，按价格时间优先级排列它们，因此，如果两个绝对限定价格不同的定单钉住NBBO中间价，由于这两个定单具有相同的有效值，所以与限定价格不相干，并且，按输入的时间确定它们的排列，最旧的定单处在最高优先级上。

执行引擎50最好按如下观察一级市场上的交易暂停。在证券暂停的时候，所有现有的和新的定单都将被拒绝。执行引擎60从数据销售商60那里推测证券交易状态。如果数据销售商60不能提供服务或相应通信网络70出故障，执行引擎不处理任何交易，而是简单地等待到至关重要的服务被重新建立起来。

在优选实施例中反馈的市场数据包含市场暂停信息，以及1级和最后销售数据，供分析服务器160使用。

如果新定单触发了匹配，执行引擎最好马上向Cloud9 OM 130报告执行未决状态，以及预期总匹配量。如下所述，这个报告是只供促进器140使用的信息，和不保证交易将理所当然。

交易最好利用现有技术中已知的软件编程方法，作为单次事务处理来处理，以避免在计算机出故障的情况下系统报告交易的一方而没有报告交易的另一方带来的风险。处理交易最好涉及如下步骤。

1.如有需要，向管制组织报告交易结果，并更新数据库中的定单状态。在优选实施例中，向Nasdaq ACT系统报告交易结果。为了数据发布(行情显示系统报告)和为了清算的目的，匹配引擎要马上向ACT报告。

2.当为了清算而成功锁定交易时(ACT确认交易报告和指定ACT报告ID)，执行引擎50最好将公司交易报告消息发送到定单管理器130。涉及到钉住定单的交易最好用用于计算NBBO中间价的最近递盘的时间标记和最近发盘的时间标记，以及处理执行结果的时间标记来报告。

执行引擎50按如下处理输入的消息：

New Order处理。New Order是来自OM 130的消息。最好按如下处理它。

●如果有的话，识别匹配定单，并向定单管理器130确认带有状态的定单输入。

●如果定单未被填充，但导致在一方存在限定定单而在另一方存在钉住定单的状况，则在证券中为NBB价格更新登记。

●处理如上所述的任何交易。

Cancel Order。Cancel Order是取消打开定单的来自Cloud9 OM的请求。最好按如下处理它。

●核实Cancel Order请求是否携带指向帐簿51中的一个定单的有效定单ID。

●如果定单已经交易过，拒绝取消定单请求消息。

●如果定单未曾交易过：

○在执行引擎数据库(帐簿51)中将定单状态标记成“取消的”。

○向定单管理器130报告成功取消状态。

在优选实施例中，可以在任何时候修改或取消定单，除非像上述那样提高消极定单的价格进取性。在可替代实施例中，要求定单具有10秒的最小有效时间，以便给予其它参与者合理的时间对促进器140触发的事件，譬如，活动代码或对方存在通知作出反应。

该系统最好还使定单管理器130能够取消与给定保荐经纪人相联系的所有定单，或一起的所有定单。执行引擎50通过首先识别所有受影响的定单，然后按定单的输入时间处理取消定单请求，处理这样聚集的取消定单请求。

执行引擎50最好利用30秒心跳验证与定单管理器130的连接。在连接失败的情况下，该系统最好取消所有定单。

网络服务器。该系统最好包含使客户GUI 20能够通过像因特网那样的通信网络与网络服务器110连接的应用程序编程接口。网络服务器110允许顾客前端应用程序访问像BPR更新的观看或将定单输入系统中那样的Cloud9交易服务。

如果检测到与客户机的连接失败了，则Cloud9最好尝试用执行引擎50取消所有客户定单。在可替代实施例中，该系统允许客户机选择连接的失败不会引起打开定单被取消的配置；选择这个可替代实施例的客户机接着必须调用求助桌面，以便在紧急情况下取消定单。

网络服务器110将交易活动消息(定单、取消/取代、取消)传递给定单管理器，并将响应和主动提供消息往回传递给客户机。它还存在客户GUI配置，譬如，屏幕上窗口的位置和大小和交易者想监视的证券的列表。这些例子不构成穷举列表，而只是为了例示的目的。正如本领域的普通技术人员容易理解的那样，可以存储其它配置参数，以支持GUI显示选项。

在优选实施例中，GUI使交易者能够观看当可用信用的数量下降到低于通常进行大宗交易所需美元数时由系统生成的信用警告。在可替代实施例中，不显示信用警告，一旦定单输入请求出问题，用户就可以简单地发现信用不足。

在本发明的可替代实施例中，GUI 20使交易者能够访问便于管理证券的监视表的对话框。监视表的用途是限制来自系统的信息流到交易者感兴趣的代码。在这个实施例中，该系统最好还使交易者能够看到是否还有什么人当前正在用打开的GUI监视给定代码(由于这样会提高交易的可能性，所以令人感兴趣)。在可替代实施例中，GUI 20使用户能够看到监视证券的交易者的人数。GUI 20将只在监视的证券中为BPR更新消息和为活动代码和对方存在消息的接收登记。在优选实施例中，API允许GUI在任何证券中为BPR/Active/Contras Present消息登记，并在证券的分开列表中分开地为报价更新消息登记。优选GUI 20每次只为一种证券，即，如图2所示，打开定单输入对话框的那一种显示NBBO价格。在可替代实施例中，GUI预订所有监视证券中的NBBO更新，并在引出列表中在代码旁边显示这些价格。

为了管理监视表，用户最好能够加入各个代码，或加入按已知的一组证券，譬如，工业组或门类分类的所有代码。该系统最好还使用户能够以Excel文件的形式提交他们自己的数组证券，并将这些组装入系统中，在这一点上，可以简单地将它们加入交易者可以从中选择的数组证券的列表中，以便填充他或她的监视表。

在图8中描绘了优选监视表配置对话框。用户能够加入代码或数组代码。在用户保存变化之前，变化处在未决状态。用户也可以还原成以前保存的监视表，或装入来自可以例如从它们的OMS或记事簿中导出的Excel电子表格的一组证券。

监视表最好由客户机来管理和一直在服务器上。

在带有监视代码通知的实施例中，网络服务器110最好跟踪哪些代码正受到两个或更多个GUI“监视”。如果将代码加入交易者监视表中，使监视客户器的数量达到两个，那么，网络服务器110将向预订活动代码消息的所有GUI广播消息，以指示代码受到监视。如果监视GUI的数量下降到一个，网络服务器将向预订活动代码更新的GUI广播消息，以指示这个代码不再受到监视。在可替代实施例中，每当用户加入或除去对代码的监视和给出代码、时间标记和监视代码的当事人的更新数量时，就发送消息。

GUI 20最好通过在包含ACTIVE SYMBOL通知的实施例中将橙色用于活动代码，将黄色用于CONTRA PRESENT通知，用彩色编码长方块在GUI的顶端加亮它们，示出处在交易者监视表中和活动的或存在对方的所有代码。在可替代实施例中，与即时信使应用程序类似，通过临时弹出屏幕显示指示监视代码变成活动的或存在对方的消息。在另一个可替代实施例中，在通过点击生成定单输入对话框和响应消息输入定单，或者，通过点击“close(关闭)”或“minimize(最小化)”按钮关闭弹出屏幕或将它缩小成屏幕底下的一根棒，采取行动之前，这些弹出消息一直是可见的。

优选实施例中的交易者GUI 20拥有在其监视表上示出或不示出处在“监视”状态的代码(即，至少一个其它交易者正在监视这个代码)的选项。如果他们选择观看这些代码，那么，当它们不是“活动的”或不存在对方时，由于不是马上要求交易者注意，用没有其它两种颜色醒目的第三种颜色表示它们。在优选实施例中，GUI 20在活动和存在对方长方块旁边用灰色长方块表示监视代码。

网络服务器110最好向远程客户器展示API，以便访问系统服务。API最好使用户能够在使用任何交易服务之前，通过基本验证(用户名、口令)打开会话。在可替代实施例中，客户机用证书来验证自己。用户信任状的交换最好通过SSL会话完成，SSL会话利用网络服务器公开密钥交换加密密钥。一旦用户得到验证，就将会话映射成用户身份。

网络服务器API最好展示如下功能。

●Get Sector List：每个公司可以有选择地让证券按门类或其它证券分组排列。证券分组可以按每个客户公司配置。API返回与客户公司和组名相联系的证券列表。

●Get Security List：该系统拥有配置证券的列表。这个功能返回那个列表。列表中的每个单元是代码、公司名和门类。

●Set&Get trader Defaults：该系统使客户机能够存储默认参数。如下列表不是穷举的，而是包含一些特定感兴趣的交易者默认参数；其它参数对于本领域的普通技术人员来说是显而易见的。

○Default Placed amount。定单输入对话框将用这个代码的最小数量(大宗数量)，或如果这个交易者使用了票证，用交易者总票证数额默认地填充数量字段。

○Default Price。定单输入对话框将用通过如下规则之一选择的限定价格填充价格字段：NBBO的进取性一端、NBBO的消极一端、NBBO的中间价；和对于包含BPR的实施例，BPR的进取性一端、BPR的消极一端或BPR的中间价。

○Default TIF。定单输入对话框将用这个秒数填充有效时间字段。

○Default Watch List Management(Security，Sector)。所有监视表由前端来管理和一直在服务器上。

○Default Peg and offset。定单输入对话框将默认地选择或不选择钉住选项，如果选择，对于买入定单，加入这个作为钉住偏移量的美分数，或者，对于卖出定单，从钉住中间价中减去这个美分数。

○Ticketed Orders Only。这个选项确定交易者是否想对照通过票证预约的数额检验定单。如果不选择这个选项，即使没有相应票证，交易者也能够输入定单。

○Set&Get Sector Watch List：保存和检索包含一个门类或其它组的证券的列表。

○Set&Get Symbol Watch List：保存和检索处在给定监视表中的证券的列表。

●Set&Get GUI Defaults：

○Ticket Management Grid：打开或隐藏启动带有显示票证列表的窗口的应用程序的选项。

○Ticket Management Grid definition：font、fieldorder、colsize、col type、headers和field＝col mappings。

○Color Changes(Yes，No)：当已经将定单提交给系统和从那里起已经编辑了这个字段，GUI最好允许用户选择这个选项，加亮定单输入对话框中定单的任何字段。当已经编辑了字段时，用户可以按下“replace(取代)”键，通过Cancel/Replace定单消息将新值发送给系统。加亮已经编辑过的字段有助于用户管理定单。

●Get Heartbeat Interval。确定GUI 20和网络服务器110之间的连接是否能起作用的周期性心跳的秒数。该系统最好对这个参数施加一个下限，以避免负连接管理职责的网络服务器110过载。在可替代实施例中，参数只能设置在服务器上，不通过API展示。

●Get Tickets：获取用户票证。在交易日内，用户每个代码/每方只能拥有一条票证。如果票证被取消，数额下降到未执行的数额。同一代码和同一方的新票证取代列表中的项目。

●Get Orders：获取所有定单的列表。

●Get Order Status。返回ClientOrderID的定单细节。

●Submit New Order：将新定单排队到系统中。后面接着OnOrderUpdate或OnOrderReject事件的异步调用。

●Replace Order：这个功能排队取代定单请求。一旦返回，调用者假设定单状态处在“Pending Replace”下。后面接着OnOrderUpdate或OnOrderReject事件的异步调用。取代定单细节与新定单细节+OrigClientID字段相同。数量是包括已执行数额的总数量。

●Cancel Order：这个功能排队取消定单请求。一旦返回，调用者假设定单状态是“Pending Cancel”。后面接着OnOrderUpdate或OnOrderCancelled事件的异步调用。

●Execute Trade。这个功能请求向保荐经纪人报告这个交易，以便设置分配处理。这可以在交易日结束时自动完成。

●Get Trades for(ClientOrderID，Symbol or ALL)Request/reponse toretrieve trade details。这个请求最好有三种形式。为定单，为证券的所有定单，或为这个GUI客户机的所有交易获取交易结果。

如下是API事件，即，由系统产生和通过API推给GUI 20的消息。

●OnTicketUpdate：对于新的、取代的和取消的票证事件，提升这个事件。

●OnOrderUpdate：对于定单状态变化，提升该事件。这包括对其它通道上或通过其它通道的请求的定单管理响应。

●OnOrderReject：响应在这个会话内输入的新/取代定单请求，提升该事件。

●OnCancelReject：在拒绝取消请求时提升事件。

●当在通过这个API或另一个通道输入的交易者定单之一内存在交易时，提升OnTrade事件。

网络服务器110的优选实施例还提供预订每种证券的市场数据的接口，并将数据存储在像硬盘那样的计算机可读媒体上。字段包括：(NBBO bid，askand TapeTimeStamp)、(BPR Low and High)、Block Tape(Last and totalvolume)、Active Symbol、Contras Present、Security State(open，closed，halted，etc)和timestamp。在这个接口的优选实施例中展示的功能是：

●Subscribe Request/Response：这个功能最好将在请求消息中提供的证券列表加入客户的预订列表中。请求为所请求字段返回那个项目当前数据的瞬像。监视字段的随后变化将提升带有变化的更新事件(OnUpdate)。

●Unsubscribe Request/Response：除去预订请求。

●OnUpdate Event：通知字段的预订者在预订项目内改变。

●Start Active Symbol Feed Request/Response：返回设置了活动代码标志的所有代码的列表。在调用之后，活动代码标志变化中的所有状态变化将导致OnActiveSymChange(Symbol，On/Off)。

●Stop Active Symbol Feed Request/Response：终止上述的事件通知。

●OnActiveSymChange事件将活动代码标志变化通知预订者。

研究数据存储。该系统最好将有关系统活动的信息存储到像硬盘或磁带那样的计算机可读媒体上。这个存储数据使操作人员和研究人员能够监视系统活动的各种计量，尤其，当用户输入定单时，评估一种代码的交易活动的不同度量如何与填充速度相关。这个信息在将系统的使用引向通过买卖媒体和对交易者工作站的访问，导致更大成功的工作流方面起重要的作用。例如，如果在输入未受监视的证券的定单之后的填充速度极低或为零，可以劝告交易者将他们的交易重点集中在受到其它交易者监视的证券的系统上。该系统最好还可以被重新配置成修改什么时候发出标志的规则，以提高系统的填充速度。例如，如果确定当三个或更多个交易者监视多于两种的证券时，填充速度基本上较高，那么，可以将系统重新配置成只有当GUI用户的总数是三个或更多个，而不是二个或更多时才发出监视代码消息。上面的例子只是为了例示，而不是提供穷举的列表。基于上面给出的参数的修改的其它优化对于本领域的普通技术人员来说是显而易见的。

交易活动度量可用在求助桌面上，并在每日结束时输出到永久数据储存库，供以发现可能系统配置设置与较高填充速度之间的关联为目的的离线分析用。

感兴趣的度量是：

●定单活动(输入、BPR进取性变化；取消/到期)

●执行

●票证

●可以看到代码活动标志(在监视表上，作为代码，或作为门类的一部分)的交易者的人数

●可以看到BPR更新的交易者的人数(预订者)

●可以看到报价更新的交易者的人数(预订者)

如下的数据表(A-D)以标准逗号分隔(CSV)形式存储。

表A.票证表

	说明	类型
			Timestamp	到百分之一秒	HHMMSSCC
Symbol		char[5]
			Quantity	大宗数量的倍数	INT
Side	买入，卖出	Enum

表B.定单表

	说明	类型
			Timestamp	到百分之一秒	HHMMSSCC
Symbol		char[5]
			Quantity	大宗数量的倍数	INT
Side	买入，卖出	Enum
			BPR	是/否	Boolean
Status	打开、拒绝、取消、到期、执行	Enum

过期、已填充

表C.交易表

	说明	类型
			Timestamp	到百分之一秒	HHMMSSCC
Symbol		char[5]
			Quantity	大宗数量的倍数	INT
Side	买入，卖出	Enum

表D.监视表

	说明	类型
			Timestamp	到百分之一秒	HHMMSSCC
Symbol		char[5]
			SymbolActiveWatchers	能够看到代码活动标志(标志在他们的监视表上)的客户的个数	INT
BPRWatchers	监视代码BPR更新的客户的个数	INT
			QuoteWatchers	监视代码的报价更新的客户的个数	INT

分析服务器

优选实施例中的分析服务器160通过听取销售商报价反馈60，并且当成为最佳价格的报价被取消或通过带有更好价格的新报价得到提高时，更新所述NBBO价格，跟踪全国最佳递盘和发盘价格。当前NBBO价格最好存储在像硬盘或磁带那样的计算机可读媒体上。除了NBBO价格之外，分析服务器160还根据最后报价和交易数据计算大宗递盘和大宗发盘。

分析服务器的主要功能是产生如下消息：

●NBBO价格变化，和

●对于包含大宗价格范围的实施例，BPR更新消息。

分析服务器160存储所有受支持证券的最后销售数据和一整天内内部递盘或发盘价格的所有变化。在表E和F中描述了需要为分析存储的数据。

表E.内部市场价格更新

	说明	类型
			Timestamp	到百分之一秒	HHMMSSCC
Symbol	证券的一级市场代码	char[5]
			ChangeType	新递盘、新发盘、两者	Enum
BidPrice	以1美分为单位跳动	FLOAT.2
			OfferPrice	以1美分为单位跳动	FLOAT.2
SecurityState	证券的交易状态(打开、关闭、暂停等)	Enum

表F.最后销售

	说明	类型
			Timestamp	到百分之一秒	HHMMSSCC
Symbol	证券的一级市场代码	char[5]
			Quantity	交易数额	INT
Price	到十分之几美分	FLOAT.2

每当内部市场最佳递盘价格或最佳发盘价格发生变化时，分析服务器160将报价更新消息传送给所有相连客户机。更新消息携带新递盘价格或新发盘价格和与改变这个递盘或发盘的报价的出现或除去相联系的时间标记。

分析服务器160最好还每60秒更新一次BPR，并在带有BPR的实施例中，将BPR更新消息发送到定单管理器130，以便确定其定单的价格进取性，和发送到网络服务器110，以便向GUI客户机20广播。

包含大宗价格范围计算的实施例包含负责计算BPR的可取代模块。BPR可以利用本领域的普通技术人员已知的方法，譬如，通过将大宗递盘取成等于全国最佳递盘价格减去5美分，并将大宗发盘取成等于全国最佳发盘价格加上5美分来计算。在另一个实施例中，与股票的历史波动性成比例地设置要加入(从)NBBO价格中(减去)的美分数，以便对于像技术股那样非常不稳定的代码，变化可以大于5美分，而对于像蓝筹股那样的较稳定股票，变化可以更小一点。

计算BPR的更精确算法的例子分别考虑了在过去6 0秒内交易的最高和最低价H和L，以及当前NBBO中间价M，并通过如下步骤计算大宗递盘和大宗发盘(图9)：

●步骤910。对于给定证券，像上面定义的那样确定价格H、L和M。

●步骤920。考察返回到最后BPR更新的时间标记中的最后销售数据，找出离当前NNBO中间价最远定价的交易。让X表示这个交易价与当前NBBO中间价之间的绝对价格差。因此，X是H-M和M-L的较大者。

●步骤930。设Z＝Y+(MaxBlockSpread/2-Y)*(1+1/(1+exp(-BETA*X))，其中，Y是设置大宗递盘和大宗发盘之间的价差的下限的为每种证券设置的参数，MaxBlockSpread是所述价差的上限，和BETA是可以设置成例如10.0的参数。

●步骤940。计算等于M+Z的大宗递盘，和等于M-Z的大宗发盘。

●步骤950。向定单管理器130和网络服务器110发出BPR Update消息。

这些例子只是为了例示：本领域的普通技术人员可以容易地相像出计算大宗价格范围的其它手段。

信用管理。该系统最好使保荐经纪人能够对他们顾客的帐户设置信用额度。在优选实施例中，信用检验基于总美元限额，计及买入股票加卖出股票的总价值。根据BPR的顶端和定单的限定价格的较大者，验证定单的信用，并且当定单被完全执行、到期或被取消(或部分执行)时，根据消耗的实际信用量调整信用。

●给予经纪人一个万维网帐户来管理信用；他们可以观看客户当前消耗的信用水平，但只限制在如下区间内：小于25％；25-50％；50-75％；大于75％。

●经纪人必须能够提高马上有效的当天信用；或者，他们可以提高或降低在每个交易日开始时得到刷新的信用量。经纪人还可以暂停信用；这会影响当天和以后几天。如果当天信用被暂停，系统将取消所有打开定单。

●经纪人可以稍后为客户撤消信用暂停。暂停具有永久性效果和一直持续到下一天。在收盘时刷新信用。

●经纪人能够将信用警告阈值设置成总数的百分比(默认值＝75％)；另外，每当可用信用降到太低无法使用大宗系统的系统配置美元值MinCreditAmount(例如，2百万美元)以下时，该系统将生成警告。将信用警告传送给求助桌面操作人员和推给客户GUI。

求助桌面。该系统最好提供管理来自顾客的呼叫的操作人员使用的求助桌面界面。这个用户界面可以是万维网浏览器界面，通过公开密钥加密和基于证书的验证，以及用户名和口令对来保证访问。该界面最好使用户能够观看有关定单寿命的详细信息。用户可以弹出带有给定代码和客户ID的定单的列表，以定位顾客正在询问的定单。求助桌面界面使它的用户能够点击感兴趣的定单，按时间顺序观看如下消息。

●票证，如果可应用的话。

●定单输入请求。

●定单输入响应：拒绝(带有理由码)；执行未决；到期；打开。

●填充。

●对照定单发送的CONTRA PRESENT通知。

●修改定单请求和响应(接受，拒绝)。

●取消定单请求和响应(接受，拒绝)。

●到期。

另外，关于定单的寿命内每个重要事件(输入、取消、执行)，求助桌面操作人员能够看NBBO内价格、分别在递盘方和发盘方看到的最近报价的时间标记、BPR价格和时间标记。这可用于回答问题：譬如，当输入定单时，为什么代码变到或未变到活动状态等。

在可替代实施例中，求助桌面操作人员不能观看代码或任何定单的属方，从而降低了与意识到机构顾客的交易兴趣的交易者有关的保密风险。在这个实施例中，求助桌面操作人员通过弹出与交易者有关的定单的列表，利用输入的时间和每个定单的数额，以及也可在交易者GUI 20上看到的ClientOrderID，识别调用者的定单。求助桌面操作人员以交易者为工作对象，识别他或她正在查询哪个定单，然后，通过点击定单观看相应活动痕迹，像上述那样继续下去。

在优选实施例中，求助桌面还使它的操作人员能够从引出列表中选择客户机，和观看它们与交易逻辑有关的配置。下面的列表给出了较重要的用户配置和求助桌面操作人员的用户统计；该列表不是穷举的，本领域的普通技术人员可以容易地理解其它列表。

●信用额度和消耗的信用。

●交易者的活动：定单个数、交易股数、交易美元数。

●交易者列表；选择一个来观看和编辑交易选项。

●监视表管理(加入/除去代码、加入/除去工业组)。

●示出/不示出活动代码条。

●示出/不示出票证的引出列表。

●默认票证属性。

优选实施例还使经纪人能够利用与用于求助桌面操作人员相同的验证和保密模型访问主页。经纪人将这个网页用于信用管理。为了维护客户的私密性，该界面最好限制信息以不暴露客户交易的细节的方式向经纪人显示。在这个实施例中，经纪人只能以总信用额度的百分比形式观看客户消耗的信用量；例如，这可以限制在四个区间内：小于25％；25-50％；50-75％；和大于75％。另外还使保荐经纪人能够通过如下功能修改客户的信用。

○加上当天信用。

○加上当天信用和还增加以后几天的刷新量。

○降低以后几天的刷新量。

○暂停信用。

○撤消信用暂停。

在可替代实施例中，马上向保荐经纪人报告交易结果，和保荐经纪人能够观看执行的交易，以及消耗的准确信用量。在另一个可替代实施例中，保荐经纪人还可以观看交易前活动。

系统配置界面。该系统最好使操作人员能够修改配置，并在业余系统维护期间，加入/除去客户或保荐经纪人。

系统配置界面使系统操作人员能够加入客户和设置所需配置属性，以便使用户能够进行交易。新客户公司必须可用经纪人列表中选择保荐经纪人。保荐经纪人最好对于同一公司内的所有交易者是唯一的。在可替代实施例中，同一公司可以使用数个保荐经纪人，和GUI 20让交易者按定单输入选择保荐经纪人。新公司可以有选择地建立直接与FIX服务器120、通过FIX服务局或通过保荐经纪人95的FIX连接。在后一种情况中，保荐经纪人代表它自己将来自客户机的FIX消息转发给FIX服务器120。取决于它们的工作流要求，公司可以选择两种模式的FIX连接：可以将FIX通道设置成只接收执行结果，或者接收执行结果和定单更新消息。可以将它们设置成输入票证和对照通过票证分配的数额检验GUI输入定单，或不使用票证地工作。当将客户公司加入系统中时，求助桌面操作人员将给经纪人打电话，为顾客的帐户设置某信用额度，和同意client-ID用于收盘报告。最好要求新用户将GUI/API访问配置成能够在系统上进行交易。在可替代实施例中，还通过FIX界面支持用户输入，和不要求用户使用GUI 20或API访问。

系统配置界面最好还使系统操作人员能够将保荐经纪人加入受支持经纪人的列表中。在可替代实施例中，该系统由单个保荐经纪人操作，不能通过第三方经纪人关系访问。在配置保荐经纪人的过程中，操作人员将为保荐经纪人创立用户帐户，以便像上述那样管理它们客户帐户的信用。必须将像电话号码、传真和电子邮件那样的经纪人联系信息输入和存储在系统数据库150中。救助桌面操作人员将利用这个数据就信用问题与经纪人联系。为了完成设置新保荐经纪人的处理，最好执行如下步骤。

●经纪人必须建立FIX连接，以便接收所有执行结果的引出副本。如果经纪人还用作客户OMS的服务局，和代表客户发送票证，那么，这同一种连接也用作与客户机的FIX连接。

●建立包含每笔交易的细节的从系统传送的收盘文件，包括每笔交易的买方顾客的身份。

●可选地，建立带有买方交易细节的在收盘时传送给经纪人清算公司的收盘文件。

进一步使操作人员能够将证券加入为了交易而受到支持的证券列表中或从中除去证券。最好将证券与本发明特有的参数值，譬如，大宗数量和在包含大宗价格范围计算的实施例中，分析服务器160用于计算大宗价格范围的参数相联系。在下表中给出了将一组所需字段用于证券的例子。

	说明	类型
			Security	证券名(可选的斑点(blob))	字符串
Symbol	在一级市场上	char[2，3，4，5]
			Primary market	NYSE，Nasdaq	INT
LargeBlockQuantity	定单必须是这个数量的倍数	INT

MinBlockSpread	大宗递盘和大宗发盘之间的最小美分数	INT
			MaxBlockSpread	大宗递盘和大宗发盘之间的最大美分数	INT
Beta	重新标准化大宗价差的挤压参数	FLOAT

系统操作。优选实施例中的系统最好包含用于提供服务器、网络硬件和交易的集中管理的操作控制台。支持所需功能的操作软件可以至少提供如下特征的形式从市场上购买到。

●所有服务器统计的实时显示

●问题总结

●问题解决反馈

●远程管理/监视

●智能通知系统(警告)

●警告显示、确认和评注

●可听见警报

●日志记录

●在线帮助

操作人员控制台允许系统操作人员执行如下远程动作：

●系统启动

●系统重新启动

●系统关闭

●系统部件重新启动

●系统部件关闭

●系统部件启动

●系统备份

●数据库备份

●一天内启动/关闭

●收盘复位

●执行收盘批处理

该系统另外还使操作人员能够在收盘时生成日常使用报告和从这些报告中提取记帐、研究、清算和OATS报告的必要信息。

操作人员最好还使用系统操作工具创建清算总结，清算总结包含带有交易双方的经纪人ID的交易列表。交易总结与保荐经纪人有关和它的清算公司包含至少给定经纪人保荐一方的所有交易。

该系统最好还生成包含涉及保荐经纪人的所有执行的列表的记帐报告，以便发送给经纪人。执行应该与当天执行报告一一匹配。收盘报告另外还包含在当前报告中屏蔽起来的客户ID。如果交易的两只腿由同一经纪人保荐，在总结文件中将有两个执行报告。

优选实施例将下述数据的两个副本保存到可换式媒体中，供存档和分析中。如有可能，事件的日志记录包括精确到毫秒的日期-时间标记。

●系统和应用程序日志：标记和保存每个机器上的应用程序和系统。在开盘之前最好重置日志。

●配置审查：记录公司的开盘和收盘审查的细节(NT登记、应用程序配置等)。

●ACT消息：存在包含所有ACT消息的细节的分立日志。在开盘之前最好重置这个日志。

●定单和交易：在收盘时将定单和交易表复制到可换式存储器。保存有关定单状态变迁的细节的分立日志。在开盘之前最好重置日志和表格。

操作活动：用日志记录影响系统行为的操作活动。对日志记录加上时间标记，和日志记录包括操作人员的身份。在开盘之前最好重置这个日志。

最好在每个交易日结束之前将所有系统活动日志和日常报告移到永久性存储器中。系统活动日志包含足以重构交易逻辑和每个定单和交易事件的定价的信息，包括解决定价争端所需的时间标记。

该系统最好被配置成在出现意外故障的情况下，利用基于如下考虑的处理自动恢复服务。

●GUI的丧失。GUI 20是Cloud9服务所需的通道。如果网络服务器110检测到与客户机的连接丧失了，在优选实施例中，自动取消所有定单，和该系统生成带有被取消定单、带有任何交易者的电话号码、向求助桌面操作人员发出的警告。GUI 20最好将定单状态显示成“取消未决”。一旦重新连接，定单状态就被更新成“取消”。交易者可以弹出作为连接故障的结果取消的定单的列表和重新激活这些定单；系统将它们当作新定单来对待，和据此处理它们。在可替代实施例中，使用户能够选择在与GUI的连接丧失的情况下不取消他们的定单的配置；在这个实施例中，当不能恢复连接时，用户将调用求助桌面来取消定单。

●FIX的丧失。FIX连接丧失最好不引起定单取消，因为FIX不是管理可执行定单的通道。一旦FIX连接丧失，必须警告操作人员。一旦重新连接，FIX客户机将按照FIX协议要求重新与服务器同步。在可替代实施例中，FIX可以用于将可执行定单输入系统中，和所述系统支持使用户能够请求一旦FIX连接丧失，自动取消他们的定单的配置。

●分析服务器。如果分析服务器160无法服务，优选实施例中的系统将继续起作用，但得不到通常由促进器实现的功能的好处，譬如，新的ACTIVESYMBOL消息(对于带有ACTIVE SYMBOL通知的实施例)或CONTRA PRESENT消息。GUI 20也将无法接收到报价更新和BPR更新消息。如果分析服务器160不能迅速地恢复原样，系统操作人员发出定单，将系统置于拒绝任何进一步的定单输入，但不取消现有定单的离线状态下。这些解决方案被描述成像本发明中那样的交易系统如何解决可靠性问题的例子，但本领域的普通技术人员可以容易地理解其它解决方案。例如，一种可替代手段是，将分析服务器160当作至关重要服务，和一旦服务丧失，自动关闭系统和取消所有定单。

●网络服务器、定单管理器和促进器。这些服务与交易系统的至关重要功能密切相关。因此，在优选实施例中，这些服务的故障被认为是致命的；当检测到连接丧失时，操作人员将力图取消执行引擎中的所有定单，或自动取消这些定单。一旦检测到这些服务的任何一个发生故障，系统就自动进入离线状态。

在独立系统上连续运行的系统管理控制台不断地监视系统的完整性。如果在交易日的任何时间上，系统的完整性变得不确定，系统将自动切换到离线模式。在这个时刻，所有定单都被取消。在系统返回到完全正常操作状态之前，拒绝所有进一步的定单。

带有系统生成呼叫的可替代实施例

大宗撮合系统的众所周知问题是大宗买家和大宗卖家同时输入定单的概率很低。本发明的许多方面旨在解决这个第一交易者输入了定单之后的问题；但它本身不提供什么时候应该最大限度地鼓励这个第一参与者输入定单的引导。

对于通过本文所述的机制，获得最大可能价格改进的愿望来说，及时集中兴趣的能力尤其重要。

在可替代实施例中，系统像上述那样工作，但另外还生成当存在对证券既有买入兴趣又有卖出兴趣的提示时，时常集中交易者的兴趣的系统生成“呼叫”事件。在另一个可替代实施例中，不发送有效标志，呼叫是唯一时间关注事件。呼叫最好通过确定什么时候执行的可能性最高的算法来安排。最好不利用失衡交易信息(譬如，揭示存在买入兴趣，但不存在卖出兴趣)，以避免给人以泄漏信息，从而使交易者感到他们输入系统中的定单正在引起在他们的直接控制范围之外的不想要信息事件的感觉。

呼叫的目的是当执行可能性最大时，吸引交易者输入定单。例如，如果输入给定证券的定单的第一交易者的平均填充率是5％，该证券在打开呼叫时的填充率可能是10％或15％；相反，没有呼叫时的填充率将低于5％；以及与任何呼叫无关地随机输入定单的交易者的总平均填充率为5％。

至少，当双方交易者都输入了定单，但因他们的定单在不同时间输入而相互失匹时，这样的可替代实施例生成把注意力焦距在证券的定单输入上的呼叫。下面将描述系统可以生成呼叫的情况的其它例子。为了避免有关输入系统中的定单的信息泄漏，在带有BPR的实施例中，在预先安排的时间，譬如，60-秒BPR更新，而不是在出现定单项事件的时候报告这些呼叫。

	说明	类型
			Symbol	证券的一级市场名称	char[5]
TimeStamp	当计算BPR时	HHMMSSCC
			QuoteTime	在计算BPR之前最后报告更新的时间	HHMMSSCC
LastSaleTime	在计算BPR之前最近行情显示系统打印的时间	HHMMSSCC
			NationalBid	以美分为单位	FLOAT.2
NationalOffer	以美分为单位	FLOAT.2
			BlockBid	以美分为单位	FLOAT.2
BlockOffer	以美分为单位	FLOAT.2

Call

打开/关闭

Boolean

生成呼叫的算法最好基于如下原理。

●不按定单输入触发。在预先安排的时间上评估发出呼叫的机会。这样就消除了如果交易者想观察他或她自己的定单是否可以引起呼叫发出，将出现信息泄漏的担心。它还阻止了这样的交易者发现有关帐簿的信息。例如，假设系统规则是，当买方和卖方都接收到定单时，发出呼叫。如果买家想按定单输入触发呼叫，他将发现系统中最近已经有了卖家。通过在预先安排的时间发出呼叫，呼叫不再直接与交易者的定单有关，和它的解释未必泄漏有关帐簿中的其它定单的属方的任何信息。

●1分钟最短寿命。一旦启动了呼叫，它就持续足以让交易者对呼叫作出反应和响应的时间。

●两方。只有当存在双方都对大宗感兴趣的证据时才发出呼叫。这样就减少了潜在的博弈。

●未必存在定单。当在系统中不存在有效定单时，可能生成呼叫；因此，交易者不可以通过监视什么时候发出呼叫，推测系统中存在定单。

●不公开规则。使系统发出呼叫的规则最好定期修改和不向参与者公开，以降低寄生交易者试图从呼叫定时中推测有关系统帐簿的信息的风险。定期更新还给予系统操作人员以调整规则的灵活性，以便保持合理的呼叫频率。

如下的数据最好可用于当应该生成呼叫时作出决定的目的。

●带有剩余量的票证。

●打开定单。

●到期定单。

●交易。

●行情显示系统上的大宗打印。

●交易量不寻常地高的行情显示系统上的重复打印。

发出呼叫的基于规则方法

第一可替代实施例利用了当应该生成呼叫作出决定的基于规则手段。对于每个代码，与BPR更新处理一起执行活动评估处理。

如果还没有呼叫，最好应用下面给出的规则，以决定是否应该视系统中的活动(定单、交易等)而定和视市场而定，呼叫代码。如果任何布尔(Boolean)规则都是“真”，呼叫代码。

如果已经呼叫了代码，至少在<60>秒(可配置全局参数)内呼叫了代码，并在证券中不存在对方存在标志，系统最好除去呼叫。

在如下的弹点下列出了导致呼叫的规则。

○定单已输入和到期。之后，对方输入另一个定单。在下一个规则安排的时间上，检验在最后30分钟内在这个代码下是否发布了呼叫(可配置ActiveMaxDelay1)，如果还没有，在这个代码下发布呼叫。

○定单已输入和到期。之后，在行情显示系统上检测大过打印(大于10000股或$250,000，并且，这些都是可配置参数)，并在这个代码下在最后90分钟内还没有发布呼叫(可配置ActiveMaxDelay2)。

○自行决定：求助桌面操作人员打印代码和点击按钮。

○输入定单并在对方存在票证。

○在最后<30>分钟内交易的代码下输入定单。

○消极地定价常驻定单和在带有进取性价格的对方新定单已达到。

○常驻卖出定单是进取性的和在行情显示系统上检测重复打印，指示在大宗数额的发盘上的集体买入；或者，对于系统中的买入定单，反过来也一样，和市场上大宗卖出的证据。

上面的列表只是为了例示，不是穷举的。本领域的普通技术人员可以容易地理解用于识别什么时候存在较大交易可能性的其它规则。

发出呼叫的计分功能方法

像接着所述的那样，带有呼叫的另一个可替代实施例利用计分功能来确定什么时候生成呼叫。

对于每个代码，与BPR更新处理一起执行呼叫评估处理。如果在这个代码下当前还没有呼叫，系统像下述那样计算代码的活动分数和阈值。如果分数分数超过阈值，系统最好为这个代码生成呼叫。

如果已经呼叫了代码，至少在<60>秒(可配置全局参数)内呼叫了代码，并在证券中不存在对方存在标志，系统最好除去呼叫。

系统最好通过两个步骤计算分数。

步骤1：通过加入与如下条件相联系的权重，计算证券的买方兴趣和卖方兴趣。

●OpenOrderConditon。当前打开和进取性定价的买入(卖出)定单。

●PassiveOrderConditon。当前打开但消极定价的买入(卖出)定单。

●ExpiredOrderConditon。当前过期的买入(卖出)定单。

●TicketConditon。带有剩余数量的的买入(卖出)票证。

●BlockTapeConditon。Cloud9上的最近大宗执行。

●MarketPrintCondition。自从最后安排的呼叫评估时间以来发生、在中间价之上(之下)打印、至少<BlockQty＝1000>股或<BlockValue＝$250,000>的行情显示系统上的大宗打印。

●RandomRefreshCondition。在超过<LiqudityRation＝2乘以证券的平均交易量的速度上、总数量在<BlockQty＝1000>股或<BlockValue＝$250,000>之上、自从最后呼叫评估时间以来在中间价之上(之下)的重复打印。

●WatchListCount。在他们的监视表上含有这个代码的交易者的人数。

下表给出权重的合理配置的例子。

	说明
			OpenOrderCondition	BPR内的定单	20
PassiveOrderCondition	消极定单	10
			ExpiredOrderCondition	到期定单	5
TicketCondition	票证	4
			BlockTapeCondition	Cloud9行情显示系统	3
MarketPrintCondition	行情显示系统上的大宗打印	2
			RandomRefreshCondition	市场上的买入(卖出)压力	1
WatchListCount	监视表上含有这个代码的交易者的人数	INT

步骤2：作为买入兴趣乘以卖方兴趣的积，计算代码活动分数。

该系统最好按如下计算阈值。如果该代码从未呼叫过，阈值等于零。如果该代码以前曾经呼叫过，这个代码的阈值等于自从这个代码到期的最后呼叫以来的时间的指数函数：

Threshold＝MaxThreshold*EXP(-Beta*TimeDelay)

参数MaxThreshold和Beta最好可按每个证券配置。

在带有系统呼叫的实施例中，系统可以像上述实施例那样连续地匹配定单，或者，在安排的呼叫时段过去之前，不发生任何匹配地累积定单，和像上述那样，按照属方、价格和时间的顺序向执行引擎释放那时的它们。后一种方法产生可以与发生在本系统中的常规交易连在一起运行的呼叫拍卖环境，其中，当发现调整这样步骤的活动时，系统自动生成呼叫，然后，在呼叫时段内保持所有定单，累积足够多的定单，以便为进取性参与者获得价格改进的最佳机会。在这个实施例中，例如，连续匹配可能对低的最小数量要求(譬如，100股)有效，并且当发现双方都对大宗感兴趣的提示时，自动触发大宗拍卖(例如，100,000股的呼叫。当执行延迟呼叫时，系统最好按如下将自己限制在每次呼叫拍卖单个清算价格上：像上述那样排列定单和一个一个地将它们输入执行引擎50中，当进行了第一次交易时，按需要重新定价所有随后的定单，以保证在出现这个呼叫的时候，它们的限定不会比第一交易价格更进取。在输入了所有定单和进行了所有可能匹配之后，最好使未匹配定单失效。

带有触发ACTIVE SYMBLOL消息的可替代实施例

在可替代实施例中，对于带有ACTIVE SYMBLOL通知的可替代实施例，系统像上述那样运行，除了将活动代码消息只发送给已经提供了指示有可能对大宗买入或卖出这种证券感兴趣的核定交易兴趣信息的交易者之外。例如，这样的核定交易兴趣信息可以是经纪人在每次交易之后发出的执行报告的引出副本，和选择准则可以是公司在最后30分钟内净买出(或净卖出)了至少10,000股股票。在如下的同时待审美国专利申请中广泛描述了其它例子：2000年6月1日提出的第09/585,049号；2000年12月29日提出的第09/750,768号；和2001年3月31日提出的第09/870,845号，特此全文引用以供参考。

带有CONTRA PRESENT通知的可替代实施例

在可替代实施例中，CONTRA PRESENT通知还显示还盘的价格，因此，接收所述通知的当事人可以直接决定是否接受所述还盘，而不是必须提出价格。

本系统的可替代实施例将不同的规则用于确定谁有资格接收CONTRAPRESENT通知，尤其对报价规则和定单显示规则感兴趣。报价规则要求正在报价市场参与者用他们的报价代表他们的最佳定价定单；而定单显示规则要求，如果向不止一个的其它当事人示出价格，务必示出价格和使它适用于整个市场。如果某个人决定像报价那样观看CONTRA PRESENT通知，这两条规则形成了部署本发明的系统主体的潜在障碍。一个可替代实施例通过只向一个当事人示出CONTRA PRESENT通知，解决了这种状况；为了这个目的，选择匹配优先级最高的定单。相反的手段是与他们在系统中是否拥有定单无关地向所有用户示出CONTRA PRESENT通知。当然，只有在系统中拥有定单的用户才能够推测对方兴趣的属方；例如，在系统中拥有买入定单的用户将知道在系统内至少存在一个卖家，以及可能存在多个其它买家。在系统中没有定单的用户将知道存在至少一个买家和至少一个卖家，但不知道哪一方比另一方更进取。由于这样的双方信息不损害参与者的交易兴趣，向整个市场释放这个信息是可接受的信息泄漏。

虽然本文所示和所述的实施例完全能够实现本发明的目的，但显然，根据前面的描述，各种各样的替代、修改和变化对于本领域的普通技术人员来说是显而易见的。这些替代、修改和变化都在本发明的范围之内，和应该明白，示出本文所述的实施例只是为了例示的目的，而不是为了限制的目的。

Claims (23)

1.一种在计算机系统上促进证券交易的方法，包含如下步骤：

用电子手段接收包括证券价格的市场数据；

至少部分根据所述市场数据计算所述证券的参考价；

用电子手段将所述参考价存储在计算机可读媒体中；

用电子手段从第一用户接收与所述证券有关的第一定单，其中，所述第一定单包含第一价格限定和第一数量限定；

用电子手段将所述第一定单存储在计算机可读媒体中；

用电子手段从第二用户接收与所述证券有关的第二定单，其中，所述第二定单是所述第一定单的对方并包含第二价格限定和第二数量限定；

用电子手段将所述第二定单存储在计算机可读媒体中；和

在与所述参考价的差异最小的价格上执行包含所述第一定单和所述第二定单的交易，其中，所述交易服从所述第一和第二价格和所述第一和第二数量限定。

2.根据权利要求1所述的方法，进一步包含：如果(a)所述第二定单在价格上不足以进取到与所述第一定单撮合，和(b)所述第一定单至少与所述参考价一样进取地定价，则将电子通知发送给所述第一用户，其中，所述通知通知所述第一用户已经在所述系统中输入了对方定单。

3.根据权利要求1所述的方法，其中，只有在预定时段过去之后，才允许所述第二用户提高价格进取性。

4.根据权利要求1所述的方法，其中，所述参考价基于最近市场价格。

5.根据权利要求1所述的方法，进一步包含通过图形用户界面向远程用户显示所述参考价。

6.根据权利要求2所述的方法，进一步包含计算大宗价格范围，和其中，只有当所述第二定单至少与所述大宗价格范围的消极一端一样进取时才发出所述通知。

7.根据权利要求6所述的方法，其中，计算大宗价格范围的所述步骤基于所述证券价格的最近波动性。

8.根据权利要求6所述的方法，其中，计算大宗价格范围的所述步骤包含预测在第一预定时段内有可能出现的价格范围。

9.根据权利要求8所述的方法，其中，每隔近似等于所述第一预定时段的时间间隔重新计算所述大宗价格范围。

10.根据权利要求6所述的方法，其中，计算大宗价格范围的所述步骤基于最近或当前市场价格。

11.根据权利要求6所述的方法，进一步包含步骤：如果所述第一定单至少与所述大宗价格范围的消极一端一样进取地定价，则在接收到所述第一定单之后发出活动代码通知。

12.根据权利要求2所述的方法，进一步包含：在接收到所述第二定单之后，向所述第二用户发送电子对方定单通知，所述对方定单通知指示几乎匹配的对方定单在系统内是有效的。

13.根据权利要求12所述的方法，其中，所述第二用户只有在预定时段已过去之后才接收所述对方定单通知。

14.一种在计算机系统上促进证券交易的方法，包含如下步骤：

用电子手段将系统累积时段通知一个或多个用户，以便接收证券的定单；

用电子手段接收包括所述证券的价格的市场数据，并至少部分地根据所述市场数据计算参考价；

用电子手段将所述参考价存储在计算机可读媒体中；

用电子手段从第一用户接收与所述证券有关的第一定单，其中，所述第一定单包含第一价格限定和第一数量限定；

用电子手段将所述第一定单存储在计算机可读媒体中；

用电子手段从第二用户接收与所述证券有关的第二定单，其中，所述第二定单包含第二价格限定和第二数量限定；

用电子手段将所述第二定单存储在计算机可读媒体中；

用电子手段通知所述第一用户对方定单已经被放入系统中；和

在所述累积时间已过去时，在与所述参考价的差异最小的价格上执行包含所述第一定单和所述第二定单的交易，其中，所述交易服从所述第一和第二价格和所述第一和第二数量限定。

15.根据权利要求14所述的方法，进一步包含用电子手段对就给定证券输入的定单发出一次或多次呼叫。

16.根据权利要求15所述的方法，其中，所述呼叫每隔一定时间发出。

17.根据权利要求15所述的方法，其中，就活动指示对大宗买入和卖出证券感兴趣的证券，每隔一定时间发出所述呼叫。

18.根据权利要求17所述的方法，其中，所述活动包含接收买入证券的定单和卖出证券的定单。

19.根据权利要求17所述的方法，其中，所述活动包含接收买入证券的定单和就大宗卖出兴趣的市场数据的证据。

20.一种促进证券交易的电子系统，包含：

交易促进计算机系统，包含促进器模块、金融信息交换服务器、事务处理数据库和起计算证券的参考价作用的分析服务器，

其中，所述交易促进计算机系统与金融信息交换网络和通信网络通信，

其中，所述金融信息交换网络与所述通信网络通信，

其中，所述通信网络与一个或多个用户终端通信；和

与所述交易促进计算机系统通信的执行引擎，

其中，所述执行引擎起使证券的执行交易价格与所述证券的参考价之差最小的作用。

21.根据权利要求20所述的系统，其中，所述分析服务器通过比较定单与证券参考价的价格进取性，评估所述证券的定单。

22.根据权利要求21所述的系统，其中，所述交易促进计算机系统的作用是：如果第一定单至少与参考价一样进取，则向已经就所述证券发出的第一定单的第一用户发送所述交易促进计算机系统已经接收到针对所述第一定单的对方定单的通知。

23.根据权利要求21所述的系统，其中，要求定单是比经纪交易商接收的平均定单数额大的大宗数额的倍数。

Images