专利名称：用于集合计算服务器资源的方法和系统的制作方法
技术领域：
本发明总体而言是关于电子交易平台。更具体而言，是关于集合计算服务器资源的基于计算机的方法和系统。
背景技术：
很多不同的市场都提供电子交易。电子交易是一种广为人知的匹配市场上购买和出售货品订单的方式。匹配的订单随后可以通过电子方式得到“执行”，从而实施匹配的订单。电子交易平台需要技术资源以进行这些电子交易。持续不断地优化电子交易平台的硬件和软件资源可以在技术上达到降低那些硬件和软件资源的负载的效果，同时全面提升电子交易的质量。这里所说的质量包括速度(如缩短网络等待时间)、效率(如减少中央处理单元的处理资源，降低电子内存消耗)、准确性(如给定货品的实际报价值准确)等。不同种类的电子交易使用不同的数据记录结构来代表所交易的证券。这种数据记录结构的不同导致的结果就是对应不同类型的电子交易的唯一技术结构和配置。而且，在电子交易中所涉及的服务器之间的网络连接、以及这些电子交易服务器上的硬件和软件流程的配置也会影响不同类型的电子交易的质量。其中一种电子交易的特点是债券结构的数据记录。债券数据记录通常以不同的格式保存在不同的计算环境中，这些计算环境由不同的券商维护。与债券数据记录相关联的电子报价需要定期更新(通常是每天)，并且使所有与特定债券数据记录相关联的债券的券商能够得到。在某些当前配置中，一个例子就是加拿大的债券电子交易。由特定交易公司或券商维护的计算环境仅依赖于关联到该计算环境的电子交易数据，而不与由其他券商所维护的计算环境所关联的电子交易数据进行交互。这样，一个券商的计算环境中的电子报价因其他券商的电子计算环境不同而不同。在另外的配置中，不同券商的计算环境可通过某种方式连接成网络，这样就可以检查所有券商的电子交易数据，以确定电子报价，该电子报价对应于给定债券的全部债券数据记录(保存在参与的券商所关联到的计算环境中)。但是， 检查对应于给定债券的所有债券数据记录会消耗大量的计算资源。而且，大量消耗计算资源也会干扰其他连接在网络中、专门基于按时且有意义的电子报价最终执行电子交易的计算资源。因此，最好能够降低由于检查和处理对应于给定债券的债券数据记录以生成该债券的电子报价而引起的计算资源负担。
发明内容
本发明的一个方面就是提供一个系统，集合包含多个报价服务器的计算服务器资源。每个报价服务器都配置为保存一个券商数据记录，其中包含一个债券的报价。每个券商数据记录都与其他券商数据记录不同。系统还包含一个结算服务器，配置为保存一个结算数据记录，其中包含债券的实际交易值。系统还包含一个报价引擎，连接到报价服务器和结算服务器。报价引擎配置为接收券商数据记录和结算数据记录。报价引擎配置为基于券商数据记录和实际交易值执行多个操作。这些操作配置为连续删除一个或多个所述券商数据记录。报价引擎配置为基于删除后余下的券商数据记录执行最终的价格确定。
图1示出了一个实施例的集合计算服务器资源的系统。图2示出了一个流程图，说明另一个实施例的集合计算服务器资源的方法。图3示出了图1的系统执行图2方法的方块205的示例。图4示出了图1的系统执行图2方法的方块210的示例。图5示出了图1的系统执行图2方法的方块255的示例。图6示出了图1的系统执行图2方法的方块255的另一示例。图7示出了另一实施例集合计算服务器资源的方法。图8示出了一个流程图，说明另一个实施例集合计算服务器资源的方法。图9示出了一个流程图，说明另一个实施例集合计算服务器资源的方法。图10示出了一个流程图，说明确定询价(作为此处讨论的其他方法的可选输出生成的一部分)的方法。
具体实施例现在请参阅图1。一个集合了计算资源的系统，整体标记为50。系统50包含多个报价服务器，54-l、M-2、54-3. . . 此处统称为“服务器M”)。这些服务器都通过任何适当的网络62连接到报价引擎58。系统50还包含一个结算服务器66，它直接连接到报价引擎58和网络62。每个服务器M通常都是一个服务器或大型机，其中包含的装置包括一个或多个中央处理单元、易失性内存(即随机访问内存)、永久内存(即硬盘设备)以及网络接口 (使每个服务器M能够通过网络62通讯)。这些装置通过总线相互连接。例如，每台服务器讨可以是加利福尼亚I^alo Alto的Sun Microsystems Inc.出品的运行UNIX操作系统的Sun Fire V480，拥有四个中央处理单元(每个单元都以约900MHz的速度运行以及有大约16GB的随机访问内存)。但是，需要强调的是，此处提到的这个服务器仅供示例。其他类型的计算环境阵列的报价服务器M也包含在本发明范围内。事实上，已经考虑到每台服务器M都有不同的计算环境。每台服务器可带有一个键盘或鼠标(或其他输入设备)和一台显示器(或其他输出设备)。每台服务器M通常都是与不同券商相关联的计算环境的一部分，因此每台服务器M通常都是不同的，有着不同的处理器、内存、操作系统和软件配置。每台服务器M通常都连接到与券商相关联的其他计算框架结构，包括交易屏幕、打印机、文件服务器等。在下文中将要介绍，每台服务器M都配置为保存代表不同债券的报价的电子数据记录，并将这些电子数据记录转发给报价引擎58。报价引擎58是一台服务器或大型机，其中包含的装置包括一个或多个中央处理单元、易失性内存(即随机访问内存)、永久内存(即硬盘设备)以及网络接口(通过网络 62与每台服务器M通讯)。这些装置通过总线相互连接。例如，报价引擎58可以是加利福尼亚 Palo Alto 的 Sun Microsystems Inc.出品的运行 UNIX 操作系统的 Sun Fire V480, 拥有四个中央处理单元(每个单元都以约900MHz的速度运行并有大约16GB的随机访问内存)。但是，需要强调的是，此处提到的这个服务器仅供示例。其他类型的计算环境阵列的报价引擎58也包含在本发明范围内。在现有实施例中，报价引擎58连接到主要永久存储设备(未示出)，该设备中保存与接收自服务器M和结算服务器66的电子数据记录相关联的永久数据。在下文中将要介绍，报价引擎58配置为生成代表给定债券的最终报价的电子数据记录。网络62可以是有线的，也可以是无线的，或者两者结合。它可以基于任何类型的已知网络体系结构或平台(如因特网或广域网)，或两者的结合。通常网络62为相互连接的引擎58、服务器66和服务器M提供一个框架结构。结算服务器66也是在一台服务器、大型机或其他计算环境上，与更广泛的电子交易往来相关联，配置为保存代表已登记的债券交易的电子数据记录，并将这些数据记录转发给报价引擎58。现在请参阅图2。此处用流程图说明本发明的另一实施例中集合计算资源的方法。 该方法整体标记为200。为了帮助理解此方法，现假定方法200是通过系统50执行的。而且，下文中关于方法200的讨论将进一步帮助理解系统50及其各种组件。但是，请理解系统50和/或方法200可以有各种变化，不需要完全按照这里所述的那样一起工作，而且这些变化也在本发明的范围之内。方块205接收代表交易值的数据记录。在系统50中，方块205由报价引擎58执行，后者接收数据记录“数据记录DR-0”。DR-O中包含电子数据，代表给定债券发行的市值加权价格、收益、交易总额、交易日期以及清算日期。方块205在图3中进行了详解结算服务器66将交易值数据记录“数据记录DR-0”发送到报价引擎58。报价引擎58接收到数据记录“数据记录DR-0”后，将它存储在内存中。作为方块205的一部分，报价引擎58可以配置为对数据记录“数据记录DR-0”中已知不正确的数据进行更正。更正因子是根据数据记录“数据记录DR-0”中的数据确定的。例如，如果确定数据记录“数据记录DR-0”中的价格不正确，则可以根据数据记录“数据记录DR-0”中的其他数据进行计算(如果这些数据正确的话)。更正因子的另一个例子是检查在结算服务器66上登记的交易，其中的价格包括应计但未付的利息(“应计利息”)。(正常的期望值是交易已登记为结清，即最终价格中没有 “应计利息”)。报价引擎58可以配置为也利用数据库中的已知的先前条款和条件。该数据库配置为提供更正因子，以通过来自结算系统的价格日期和清算日期反算“应计利息”，从而重新计算正确的结清价格。如果由于更正因子未知或无法确定而不能进行这样的更正， 那么数据记录“数据记录DR-0”被标识为不正确，方法200被暂停，以执行另一个进程，如方法200a或200b。(方法200a和200b将在后面讨论。)在某些实施例中，报价引擎58会要求结算服务器66发送另外一份数据记录“数据记录DR-0”，例如当确定之前接收到的数据记录“数据记录DR-0”已损坏时。请注意，方法200可以在任何时候执行，但通常是在给定债券发行的交易值存储在结算服务器66上的一个数据记录(如数据记录“数据记录DR-0”)中之后半小时之内。 请注意，半小时的时长并不是固定的，只是一个为限制性的示例。通常而言，当给定债券发行的交易值被存储到结算服务器66上的数据记录中、并随即可供报价引擎58使用时，方法 200几乎是立即执行。不过，方法200也可以在其他时候执行。在某些实施例中，从给定债券发行的交易值被存储到结算服务器66上的数据记录(如“数据记录DR-0”)时，到给定债券发行的交易值到期的时间段内，方法200可以在任何时候执行。通常，给定债券发行的交易值在下一个交易期(一般来说是下一个工作日)开始时到期，这样给定交易期的交易值只在当前交易期中用于方法200的执行。但是，本领域专业人士可以理解，交易值的到期时间可能会根据特定债券市场环境有所不同。另外还需要注意的是，可以为多个债券发行执行方法200，或是作为与报价引擎58并行的进程，或是顺序进行，或者是并行与串行的结
I=I O另外，请注意，在某些实施例中，报价引擎58配置为方块205的一部分，将数据记录“数据记录DR-0”中的某些债券的交易值规格化，从而减少或消除错误数据并忽略未正确登记的交易。此变化将在后面讨论。方块210从交易公司或券商接收报价。在系统50中，方块210由报价引擎58执行，后者从各个报价服务器讨接收数据记录“数据记录DR-1”、“数据记录DR-2”... “数据记录DR-n”，这些数据记录包含代表给定债券发行的报价的电子数据。方块210在图4中进行了详解报价服务器M将报价数据记录“数据记录DR-1”... “数据记录DR-n”发送到报价引擎58。在一个当前实施例中，数据记录“数据记录DR-1”... “数据记录DR-n”直接从报价服务器M发送到报价引擎58。但是，在此实施例的一种常见变化中，数据记录“数据记录DR-1”... “数据记录DR-n”由它们各自的报价服务器M在不同时间发布给报价服务器数据库(未示出)。然后，在执行方块210时，从报价服务器数据库(未示出)中提取数据记录“数据记录DR-I ” ... “数据记录DR-n”。由于报价服务器讨不同源的特点，数据记录“数据记录DR-1”... “数据记录DR-n” 通常格式也不相同。因此，作为方块210的一部分，报价引擎58可以配置为将数据记录“数据记录DR-1”... “数据记录DR-n”统一为一种常用格式。而且，作为方块210的一部分，报价引擎58可以配置为在已知更正因子可用的情况下对数据记录“数据记录DR-1”... “数据记录DR-n”中每个已知不正确的数据进行更正。更正因子是根据每个数据记录“数据记录DR-1”... “数据记录DR-n”中的数据确定的。例如，根据数据记录中的其他数据(如果这些其他数据正确的话)重新计算部分已知不正确的数据。如果由于更正因子未知或无法确定而不能进行这样的更正，那么数据记录“数据记录DR-1”... “数据记录DR-n”中被标识为不正确的数据记录就将被忽略，不执行方法200接下来的处理。如果方块210中的数据记录中的报价超过来自方块205的数据记录中的交易值的第一预定义阈值，方块215会删除这些数据记录。(请注意，此方块和接下来的方块中的 “删除”的意思可能是完全从报价引擎58的内存中删除，或者是从专属于方法200的存储区中删除，或者是在方法200接下来的处理中将它们标记为“忽略”)。在当前实施例中，第一预定义阈值被称为。发明人认定，如果X处于特定范围之内，服务器M和引擎58的计算资源的利用就被视为有效率的。发明人认定，可以通过审阅每个通过特定时间段的历史分析来定价的债券发行的变化来确定X。三个月的时间段被认为是合适的时间段，不过也可以使用其他时间段，并且仍属于本发明的范围之内。或者，如果发行的定价历史少于三个月，也可以审阅整个发行期的每日定价变化，从而确定X。使用此技术，发明人认定X值的第一范围介于约正负4之间。使用此技术，发明人认定X值的第二范围介于约正负25之间。 发明人还认定X的其他范围可以设置在第一范围和第二范围之间，而且正负区间不一定相等。这些范围被认为可以帮助更好地利用服务器M和引擎58的计算资源。方块220比较经方块215删除之后余下的数据记录中的报价。方块225删除方块 220中相互关系超过第二预定义阈值的数据记录。在当前实施例中，第二预定义阈值被称为。发明人认定，如果Y处于特定范围之内，服务器M和引擎58的计算资源的利用就是有效率的。发明人认定，可以通过根据债券发行的类型审阅历史数据来确定Y。审阅两年时间段内给定债券发行类型的定价历史的每日变化可以达到这个目的。不过，请理解也可以使用其他时间段。使用这些技术，发明人认定Y值的第一范围可以介于正负0. 750之间。 使用这些技术，发明人还认定Y值的第二范围可以介于正负1.750之间。发明人还认定还可以为Y设置介于第一范围和第二范围之间的其他范围，但这些范围的正负区间通常是相等的。这些范围被认为可以帮助更好地利用服务器M和引擎58的计算资源。方块230针对经方块225删除之后余下的数据记录中存储的报价执行均值和标准偏差操作。方块235删除来自方块230的、超过方块225的标准偏差操作的第三预定义阈值的公司报价。在当前实施例中，第三预定义阈值被称为Ζ%。发明人认定，如果Z处于约正负1之间的范围之内，服务器M和引擎58的计算资源的利用就是有效率的。选择使用距均值一个标准偏差的原因是，“正常分布”的数据中68. 27%的数据处于均值的一个标准偏差内。距均值一个标准偏差被认为是普遍使用的标准，而且为此目的还提供了一个相对于均值的合理的数据集。方块240确定经方块235删除后是否还仍有余下的公司报价。如果在方块240中得到的结果是“无”，那么在方块250中会在引擎58中调用一个意外处理例程。这样一个意外处理例程58可以执行任何备选流程以确定某个债券发行的最终价格，或错误消息指明某个债券发行的最终价格无法确定。例如，一个最终价格可以设置为经过前面的方块(如方块21 后余下的数据记录的平均价格。另一个例子是，方法200a或200b会被调用，如下文所述。如果在方块240得到的结果是“是”，则在方块M5中使用经方块235删除后余下的数据记录中存储的报价确定最终价格。在当前实施例中，债券发行的最终价格是通过经方块235删除后余下的数据记录中存储的报价的均值计算出来的。生成方块245中确定的最终价格。在当前实施例中，最终价格并入到数据记录Dfoi+Ι中。方块255生成一个或多个输出数据记录以供后续处理。引擎58可配置为在方块 255将数据记录Dfoi+Ι返回到部分或全部报价服务器54。在一个当前实施例中，引擎58配置为仅将数据记录Dfoi+Ι返回到在方块210提交数据记录、且提交的数据记录没有被方块 225删除的报价服务器M。这种配置不鼓励同一报价服务器M在方块210重复提交数据记录(作为方法200的后续操作)，从而可进一步提高报价服务器M和引擎58的使用效率。(请注意，由于服务器M和引擎58可能通过方法200合作用于多个债券发行，所以可以假定给定服务器M可以为某些债券发行正确参与到方法200中，而同时为其他债券发行在方法200中提供不准确的数据记录)。在一个当前实施例中，方块255将数据记录Dfoi+Ι返回到至少一部分的报价服务器M。方块255的典型执行在图5中示出，数据记录Dfoi+Ι中包含在方块MO中确定的债券发行的最终价格，而且被返回到报价服务器M-l、54-2和M-n，但不返回到报价服务器 M-3，因为报价服务器M-3提交了在方块225中被删除的数据记录DR-3。图6示出了方块 255不同于图5的另一种执行方式，其中，除了将数据记录Dfoi+Ι返回到报价服务器M-1、54-2和M-n之外，还向报价服务器M-3发送意外报告ER，向报价服务器指出数据记录DR-3在方块225被删除。报价服务器M-3随后可使用意外报告ER更新报价服务器 54-3中的流程，这样就不会再次发送该债券发行的错误数据记录，从而进一步减少引擎58 上的处理资源浪费。返回到报价服务器M的数据随后可以被发送到自动的交易流程中。这些流程驻留在服务器M本身或其他服务器上，自动导向代表购买或出售特定债券的电子指令。通过释放每台报价服务器M的处理压力，计算资源可以被引导到自动交易流程，从而减少与这些自动交易流程相关联的等待时间。现在请参阅图7。这张流程图根据本发明的另一实施例介绍了一种集合计算资源的方法，这种方法整体标记为300。为了帮助理解这种方法，假定方法300是使用系统50执行的。而且，下文中关于方法300的讨论将帮助进一步理解系统50及其各种组件。但是，请理解系统50和/或方法300可以有各种变化，不需要完全按照这里所述的那样一起工作， 而且这些变化也在本发明的范围之内。方块305确定是否有存储实际交易的新数据记录。在方块305所考虑的数据记录与方法200的方块205所考虑的数据记录类型相同(即存储在或者来自结算服务器66)。 “新”的意思是这些数据记录是在方法200的最近一次执行之后添加的，或者更改过。如果在方法200的最近一次执行之后有存储实际交易的新数据记录，则方块305的结果是“是”。 在这种情况下前进到方块310，此时如以前一样调用方法200。如果没有存储实际交易的新数据记录，则结果是“否”，并前进到方块315。方块315确定是否有占先券商数据记录。如果对于正在执行方法300的特定债券， 存在来自代表实际上最初发行该债券的券商(即“占先券商”)的报价服务器M的包含报价的数据记录，则此方块的结果是“是”。因此，为了使方块315生效，报价引擎58配置为保存有一个数据库，可以区分出对应于报价引擎讨所处理的每个债券发行的占先券商的报价服务器M。此数据库用于执行方块315。如果存在来自代表占先券商的报价服务器M的包含特定债券发行报价的数据记录，则方块315的结果是“是”，并前进到方块320。这时调用方法200a。方法200a在下面进一步讨论。如果方块315的结果是“否”，则前进到方块325。这时调用方法200b。方法 200b在下面进一步讨论。方法200a在图8以流程图的方式说明。方法200a是方法200的一种变式，因此 200a中的方块的说明也类似，只是方法200a中的说明带有后缀” a”。请注意，在方法200a 中，方块205被略去，代之以方块207a。方块207a从代表占先券商的报价服务器接收数据记录(其中包含债券发行的报价)。另外，请注意方块210被略去，代之以方块209a。方块 209a从代表非占先券商的报价服务器即所有除了方块207a的报价服务器M之外的所有报价服务器54)接收数据记录。方块209a的数据记录包含对应于那些报价服务器M 的债券发行的报价。除此之外，方法200a和方法200的执行方式基本相同，虽然根据方块 207a和209a接收到的数据的上下文而有所调整。方法200b在图9以流程图的方式示出。方法200b是方法200的一种变式，因此 200b中的方块的说明也类似，只是方法200b中的说明带有后缀”b”。请注意，在方法200b 中，方块205被略去，代之以方块208b。方块208b确定最近执行的是方法200、200a还是200b,并从方块M5、Mfe或24 接收最终价格(取决于最近执行的是这三个方块中的哪一个)。除此之外，方法200b和方法200的执行方式基本相同，虽然根据方块200b接收到的数据的上下文而有所调整。虽然前文描述了一些实施例和示例，但请理解这些是非限制性的，而且所有变化、 子集以及组合都在本发明的范围之内。例如，如上文中关于系统50的介绍中所述，方块205 由报价引擎58执行，后者接收代表给定债券发行的市值加权价格、收益、总交易量、交易日期和清算日期的数据记录。但是，如前文所注明，报价引擎58配置为方块205的一部分，可以接收给定债券发行的多个交易值(作为数据记录“数据记录DR-0”的一部分)，并在需要时评估以及更正这些交易值，从而减少或消除错误数据并忽略未正确登记的交易。在这种变化中，报价引擎58配置为对数据记录“数据记录DR-0”中存储的数据进行反向工程，以得到规格化的价格。这种规格化的价格反映实际发生的交易的价格，而不是未规格化的价格 (实际上存储在数据记录“数据记录DR-0”中)，而且反映债券的实际价格加上债券的应计值(由结算服务器66提供)。报价引擎58还配置为忽略数据记录“数据记录DR-0”中反映重复购买协议的债券交易值；这些协议被错误地当作客户交易存储在了数据记录“数据记录DR-0”中。数据记录“数据记录DR-0”中余下的以及更正过的实际交易值被集中起来， 提供每个发行的市值加权价格、收益以及交易总量。在某些实施例中，例如要为机构债券交易定价时，少于500，000面值的交易也会被报价引擎58忽略。但是，本领域技术人员可以理解，较小值的交易也可能用在其他实施例中。发明人对于前文内容进行了测试。其中某些针对各种方法测试的结果在下文中进行讨论。第一个测试使用方法200运行了第一个债券(此处称为“债券1”)，如下文中的讨论。表 I-I典型数据记录DR-O方法200的方块20权利要求
1.一种集合计算服务器资源的系统，包含多台报价服务器；每台所述报价服务器配置为保存一个券商数据记录，其中包含一个债券的报价；至少一个所述券商数据记录不同于另一个所述券商数据记录；一台结算服务器，配置为保存结算数据记录，其中包含所述债券的实际交易值；一个报价引擎，连接到所述报价服务器和所述结算服务器；所述报价引擎配置为接收所述券商数据记录和所述结算数据记录；所述报价引擎配置为基于所述券商数据记录执行多个操作；所述多个操作可选地包括所述实际交易值；所述操作配置为连续删除一个或多个所述券商数据记录；所述操作基于对所述实际交易值和所述报价的比较，或占先券商报价与其他所述报价的比较；所述报价引擎配置为基于所述余下的券商数据记录执行最终价格确定。
2.如权利要求1所述的系统，其特征在于，所述多个操作中至少一个配置为删除包含的报价高于预定义上限或低于预定义下限的所述券商数据记录。
3.如权利要求2所述的系统，其特征在于，所述预定义上限和下限是通过所述实际交易值和占先券商报价之一确定的。
4.如权利要求3所述的系统，其特征在于，所述预定义上限为高于所述实际交易值和所述占先券商报价之一的4%到25%。
5.如权利要求3所述的系统，其特征在于，所述预定义下限为低于所述实际交易值和所述占先券商报价之一的4%到25%。
6.如权利要求1所述的系统，其特征在于，所述报价引擎配置为在接收到所述结算数据记录之后立即执行所述多个操作。
7.如权利要求1所述的系统，其特征在于，所述报价引擎配置为在接收到所述结算数据记录约30分钟之后执行所述多个操作。
8.如权利要求1所述的系统，其特征在于，所述报价引擎配置为在所述实际交易值到期之前执行所述多个操作。
9.如权利要求8所述的系统，其特征在于，所述实际交易值的到期是下一个交易期的开始。
10.如权利要求1到9之一所述的系统，其特征在于，报价引擎进一步配置为将所述最终价格确定的结果传输到所述多台报价服务器中的至少一台。
11.如权利要求10所述的系统，其特征在于，所述报价引擎进一步配置为将所述最终价格确定的所述结果传输到所述多台报价服务器中的与所述余下的券商数据记录相关联的报价服务器。
12.如权利要求1所述的系统，其特征在于，所述实际交易值来自前一交易期的所述结算数据记录。
13.一种根据权利要求1到12之一所述的系统的报价引擎。
全文摘要
提供一种用于集合计算资源的方法和系统。在一个实施例中，一个系统包含多个报价服务器，它们连接到一个报价引擎。报价引擎还连接到一个结算服务器。报价引擎从不同的服务器接收代表报价的数据。报价引擎还从结算服务器接收代表实际交易的数据。报价引擎配置为对报价和实际交易进行操作，删除某些报价以减少报价引擎上的计算资源消耗，从而提高处理报价以达到最终报价的效率。系统还通过将处理转移到报价引擎来减轻报价服务器的负担。
文档编号G06Q40/00GK102224518SQ200880132056
公开日2011年10月19日 申请日期2008年11月21日 优先权日2008年11月21日
发明者约翰·乔治·布鲁斯·马克里 申请人:多伦多证券交易所