用于区块链集成的基于加密难度的金融工具的电子交易和结算系统

摘要

提供了一种金融工具交易系统，该系统允许使用基础加密货币的实物交割来建立和交易基于加密难度的金融工具。基于加密难度的金融工具基于预期值，包括每区块加密货币的预定奖励、预定哈希率、预定金融工具长度、基础加密货币的预定随机数值，以及由基础加密货币采用的当前难度级别，并且可能会随着难度级别的变化而变化。清算所结算系统计算金融工具的估值的每日变动保证金，并提供基础加密货币的实物交割以满足变动保证金。

说明书

相关申请的交叉引用

本申请要求于2019年12月9日提交的标题为“Electronic Trading andSettlement System for Blockchain-Integrated Cryptographic Difficulty-BasedFinancial Instruments”的美国临时申请No.62/945,505的权益，该申请通过引用整体并入本文。

背景技术

本发明一般而言涉及一种加密货币交易系统。更具体地，本发明涉及一种包括加密货币的实物交割(physical delivery)的加密货币交易系统。

加密货币是一种数字资产，其可以用作价值的存储体或交换的媒介，并且通常使用去中心化网络来记录事务(transaction)。加密货币在其上操作的去中心化网络通常是基于区块链的技术。区块链是在用户的网络之间共享的一系列不可变的事务、区块的链，并且有时也称为分布式账本。分布式账本可以是公共的或私有的。私有的分布式账本的所有事务均由通常彼此了解并信任的指定的网络参与者进行验证，并且对网络的访问可以由一个或多个中心化的受信任方控制。公共的分布式账本是一种对谁可以加入网络以及验证事务没有任何限制并且通常没有个人或实体主管的账本。公共账本上的事务验证者通常被称为矿工，并且它们相互竞争来验证事务以换取某种形式的补偿。

为了在网络参与者当中验证和确认事务，网络必须在将一组事务(或者说“区块”)添加到链中之前达成共识。参与者达成共识的机制的目标是制定一组清晰的规则，所有各方都可以按照这些规则就账本的状态以及哪些事务是合法的达成一致。当今存在几种共识机制，然而，一种常见的共识机制是工作量证明(PoW)。

网络上运行给定区块链软件的计算机也称为节点。在PoW模型中，这些节点通过找到数学问题的解并在它们找到该解时获得奖励作为其工作的回报，来竞争将事务的区块添加到区块链中。该奖励是新创建的加密货币，并且这个过程也被称为挖矿。这些工作确保区块链在所有网络参与者之间是安全的和同步的。

挖矿的过程已经演进到需要专用计算硬件，这些专用计算硬件能够高速地大量地计算对问题的解的猜测。这些机器试图解决的数学问题涉及将加密哈希(hash)算法应用于事务的区块。当今，存在跨区块链使用的各种哈希算法，诸如比特币(Bitcoin)中的SHA-256、莱特币(Litecoin)中的scrypt以及以太坊(Ethereum)中的Equihash。平均而言，确认区块被嵌入到区块链软件中所需的时间量被设计为维持网络的速度和稳定性。

挖矿节点(也称为矿工)独立地选择事务并对事务进行分组以形成区块。区块头部(block header)被添加，其总结了区块的内容，该内容通常包括数据组成部分，诸如：

版本：软件/协议版本号

前一个区块哈希：对链上的前一个区块的引用

Merkle根：候选区块中所有事务的哈希

时间戳：区块创建时间

难度目标：区块哈希必须低于的可变阈值

随机数(nonce)：变量，其被改变以实现可接受的哈希值

将这些区块之一添加到区块链的挑战是对工作量证明算法进行求解，这涉及找到区块头部数据的如下哈希值，即，该哈希值具有低于难度目标级别的数值。除该随机数(nonce)外，所有头部数据组成部分都是常量。矿工递增地改变该随机数的值，并使区块头部数据通过哈希函数，直到它达到低于难度目标的哈希值，此时矿工可以证明“工作”。基于工作量证明，其它节点可以接受该区块，并将它添加到链中。例如，比特币中的随机数是32位的字段，并且由此可以包括0到4,294,967,295之间的任何整数。

矿工在盈利地运行其节点方面面临着多重不确定性。第一，挖矿的成功是概率性的，而不是确定性的，即实际的挖矿奖励可能高于或低于预期的奖励。奖励本身是确定性的，但赢得奖励就像彩票一样，由几率决定——随着时间的推移，这些几率应该收敛于标准分布附近。第二，随着价格波动，加密货币奖励的法币转换价格可能高于或低于当前值或预期值。第三，网络哈希率(hashrate)或者说在线处理能力的度量可能会依赖于进入或离开该网络的节点数量而有很大差异。

上述所有变量都是相互关联的，并创建了一种反馈机制，该反馈机制影响挖出区块的几率、奖励的价值以及区块确认时间，从而影响未来的难度目标。

矿工在确定其盈利能力时考虑各种因素。它们的成本可以被很好地理解，因为它们包括资本支出(诸如挖矿硬件和容纳它们的空间)以及必须以法币支付的运营支出(诸如人员配备、电力等)。如上所述，对于矿工的预期未来法币收入，矿工面临各种不确定性。然而，两个重要的不确定性包括：1)他们最终生产的加密货币的数量，以及2)一旦获得产出，他们可以将该产出售出的价格。

发明内容

本发明的一个或多个实施例提供了一种金融工具(financial instruments)交易系统，该系统允许使用基础加密货币(underlying cryptocurrency)的实物交割来建立和交易基于加密难度的金融工具。基于加密难度的金融工具是基于预期值的(该预期值包括每个加密货币区块的预定奖励、给定的哈希率的量、预定的金融工具长度、给定的随机值范围、以及基础加密货币采用的当前难度级别)并且可能会随着难度级别的变化而变化。交易系统计算该金融工具的估值的每日变动保证金(variation margin)，并提供基础加密货币的实物交割以满足该变动保证金。

附图说明

图1图示了根据本发明的实施例的合约挂牌(contract listing)系统100。

图2图示了单独合约挂牌数据结构的示例，该合约挂牌数据结构包括包含示例合约数据的挂牌。

图3图示了本交易系统的账户注资(funding)过程。

图4图示了本交易系统的加密货币存入(deposit)过程。

图5图示了根据本发明的实施例的交易和清算系统(trading and clearingsystem)。

图6图示了根据本发明的实施例的盯市(mark-to-market)系统。

图7图示了根据本发明的实施例的最终结算系统(final settlement system)。

具体实施方式

如上所述，矿工面临着他们的预期未来法币收入的各种不确定性，包括：1)他们最终生产的加密货币的数量，以及2)一旦获得产出，他们可以将该产出售出的价格。然而，挖矿可以被视为将加密货币作为商品生产。因此，与当今的传统商品生产商类似，矿工可能高度重视将风险管理系统纳入其运营来帮助解决这些风险。

本发明的一个实施例提供了一种计算机实现的方法，该方法基于为给定的PoW区块链发布的估计的与实现的观察到的难度级别来促进加密货币的交换和交割。

虽然本发明的实施例是在交易所交易、中央清算系统内描述的，但诸如交易所和交易平台之类的术语广泛地指代商品、衍生品、证券和其它金融工具在其中进行交易的市场，并且包括但不一定限于豁免交易市场(exempt boards of trade)、指定合约市场、指定清算组织、证券交易所、掉期执行设施、电子通信网络等。

本发明可以被用于所有PoW加密货币，包括但不限于比特币、以太坊、比特币现金和莱特币。它也可以适用于具有如下概念的任何和所有加密货币，即，通过挖矿或类似的达成共识的过程来生成附加加密货币。

难度级别在指定数量的区块之后被确定性地重置。例如，比特币的难度重置是每2,016个区块。随着难度目标的变化(并且因此每单位哈希算力(hash power)赢得区块奖励的对应预期几率降低)，本发明允许买方和卖方交换基础奖励资产的差额，其基于初始估计的奖励和预计奖励(其基于更新后的几率)。在其它条件相同的情况下，随着难度的增加，以给定单位的哈希算力赢得区块奖励的预期几率会降低，因此买方将从卖方接收以币为单位的奖励值的差额，并且，如果难度降低，则反之。

图1图示了根据本发明的实施例的合约挂牌系统100。一般而言，在合约挂牌系统100中，各个合约挂牌数据结构(其包括合约挂牌)根据规范被创建、用合约数据进行填充，并且被添加到参考数据库以用于随后的交易，如下面所描述的。此外，下面的图2图示了单个合约挂牌数据结构的示例，其包括包含示例合约数据的挂牌。

在一个实施例中，用于每个合约挂牌的数据在其被创建时被定义和固定在合约挂牌数据结构中。此外，参考数据库被设计为包含与合约规范对应的一组字段。如下面进一步描述的，在第一实施例中，包括合约挂牌的这些数据结构可以被创建并添加到交易所(exchange)参考数据系统127处的参考数据库，而在第二实施例中，包括合约挂牌的这些数据结构可以被创建并添加到清算所(clearinghouse)参考数据系统150的参考数据库中。

更具体而言，一个或多个管理员105可以通过用户界面输入合约数据。用户界面可以由移动应用111、web浏览器112或管理应用113中的任何一个提供，它们中的每一个可以被它们自己的应用编程接口(API)115-117支持。虽然图1中示出了各个API，但每个API都可以是一个或多个API。合约数据110然后可以通过互联网或私有网络120并通过API 122(其能够与交易所参考系统127以及清算所参考系统150对接)传递。

在一个实施例中，合约数据125被传递到交易所参考系统127的参考数据系统130。在参考数据系统130处，管理员105指示参考数据系统130创建合约挂牌数据结构，然后手动填充合约挂牌数据结构的每个数据字段(如下面图2中的示例中所示)，例如通过经过用户界面输入数据(该数据被传输到参考数据系统130)进行填充。一旦用合约数据填充了合约挂牌数据结构，合约挂牌数据结构就作为合约数据134被传输到参考数据数据库136并且被存储。

交易所参考系统127还包括合约自动生成系统132。在合约自动生成系统132处，合约挂牌数据结构可以根据被编程到合约自动生成系统132中的预定规范和/或调度而自动地被创建。例如，对于下面图2中所示的合约挂牌数据结构的数据字段，合约自动生成系统132可以使用固定预定值来自动地生成合约挂牌数据结构，对于加密货币数据字段210诸如是比特币(BTC)、对于合约尺寸数据字段220诸如是100(TH/s)、对于报价格式数据字段230诸如是GH、对于最小价格增量数据字段240诸如是10GH、对于到期日期字段260诸如是12重置、对于结算方法数据字段260诸如是实物结算，以及对于结算过程数据字段270诸如是基于难度级别的每日变动保证金交换和最终结算，如下面图2中所示。在调度方面，在一个示例中，在BTC区块链中，合约自动生成系统132可以每12次重置或者说每24,192个区块创建并填充合约挂牌数据结构。此外，合约自动生成系统132可以为特定的加密货币创建和填充不同尺寸和频率的合约挂牌数据结构。而且，合约自动生成系统132可以为每个单独的加密货币生成具有不同合约数据的不同合约挂牌数据结构。一旦合约自动生成系统生成合约挂牌数据结构，合约挂牌数据结构就作为合约数据134被传输到参考数据数据库136并且被存储。

在附加的实施例中，合约自动生成系统132可以自动生成合约挂牌数据结构并且用合约数据填充它。然后该合约挂牌数据结构可以被传递到参考数据系统130。在参考数据系统130处，合约挂牌数据结构和/或合约数据可以被传输到管理员105以供审查、修改和/或批准。一旦合约挂牌数据结构被管理员批准，该合约挂牌数据结构就作为合约数据134被传输到参考数据数据库136并且被存储。

接下来，在交易所合约挂牌调度器系统138处，存储在参考数据数据库136中的合约数据结构被调度以在交易系统142上挂牌，以便使得可用于交易。在交易所合约挂牌调度器系统138处，软件指示参考数据系统基于合约状态通过网络向交易系统142发布合约信息140。合约挂牌调度器系统138包括调度数据库，该调度数据库包含如下数据，该数据定义了合约生命周期中合约状态发生改变的各事件。在一个实施例中，合约生命周期如下地进展：挂牌、第一次交易、最后一次交易、到期和摘牌。在一个实施例中，所述每个状态或事件可以是指定的日期和时间，例如，2019年11月11日中部时间(CT)下午4:00。在另一个实施例中，每个状态或事件可以是指定的区块链区块高度，例如区块600,768。

在交易所合约挂牌调度器系统138的一个实施例中，管理员105可以使用管理用户界面(UI)来创建调度简档数据并将其添加到调度数据库。在另一个实施例中，交易所合约挂牌调度器系统138可以基于预定义的一组规范而自动地创建调度简档数据并将其添加到调度数据库。例如，交易所合约挂牌调度器系统138可以从参考数据数据库中检索合约挂牌规范，并基于这些合约挂牌规范来对事件进行调度。例如，交易所合约挂牌调度器系统138可以从合约数据结构中检索到期日期数据字段260并使用该到期数据来对挂牌、第一次交易、最后一次交易和摘牌日期进行调度。

在一个实施例中，合约挂牌数据结构具有它们被挂牌以用于交易以及过期的定义时段的数据，这些数据在创建时被记录在参考数据数据库中。在一个实施例中，这些数据包括按照时间段(例如，每周、每月、每季度等)而指定的间隔。在另一个实施例中，这些数据包括按照由区块链区块高度而确定的难度重置时段(例如，第一次重置、第二次重置、第三次重置等)而指定的间隔。此外，重置时段和间隔可能因区块链而异。

在另一个实施例中，合约数据125不是被传递到交易所参考系统127的参考数据系统130，而是，合约数据125被传递到清算所150的清算所参考数据系统152。在操作中，清算所参考数据系统152与交易所参考数据系统132类似地操作。此外，清算所合约自动生成系统154类似于交易所合约自动生成系统132而动作。最后，在存储从参考数据系统152接收到的合约数据156方面，清算所参考数据库158类似于交易所参考数据数据库136那样操作。

在操作中，存储在清算所参考数据数据库158中的合约挂牌数据结构可以由交易所127处的合约挂牌调度器138从清算所150检索。从清算所参考数据数据库158传递到交易所127处的合约挂牌调度器138的合约挂牌数据结构经过清算所API 160并作为合约数据162被传输到交易所API 164。合约挂牌调度器138然后可以对从清算所参考数据数据库158接收到的合约挂牌数据结构进行操作，如上文关于从交易所参考数据数据库136接收到的合约挂牌数据结构所描述的那样。

在交易所交易系统142处，根据合约挂牌调度器138所确定的调度时序，从交易所参考数据数据库136和清算所参考数据数据库158中的一者或两者接收合约挂牌数据结构。交易所交易系统142通过网络将具有更新后的合约状态的合约数据144发布到匹配引擎146。例如，更新后的合约状态可以包括挂牌数据结构元素，诸如挂牌数据和结算日期等。如上面所讨论的，在一个实施例中，每个合约状态或事件可以是指定的日期和时间，例如，2019年11月11日中部时间(CT)下午4:00。在另一个实施例中，每个状态或事件可以是指定的区块链区块高度，例如区块600,768。

在匹配引擎146处，匹配引擎146匹配引擎更新其内部存储器数据库、针对由合约挂牌数据结构表示的(一个或多个)合约而启用匹配、订单提交、订单修改和订单取消。

合约挂牌调度器系统138持续地监视在交易系统142处发布的合约挂牌数据结构的状态和时序的任何更新。例如，当合约被设置为到期并停止交易时，在最后一个交易事件发生时，合约挂牌调度器系统138通过网络向交易系统142发布更新后的合约状态以禁用交易。交易系统142然后将更新后的合约状态记录在交易数据库中。如前所讨论的，最后一个交易事件可以是指定的日期和时间或区块链高度。

交易所交易系统142通过网络向匹配引擎146发布更新后的合约状态。匹配引擎146更新其内部存储器、对于由合约挂牌数据结构表示的(一个或多个)到期合约禁用匹配、订单提交、订单修改和订单取消。此外，匹配引擎取消交易系统中的针对由该合约挂牌数据结构表示的(一个或多个)到期合约的所有未结(open)订单。例如，如上面所讨论的，匹配引擎146可以通过更新其内部存储器数据库以删除仍保留在其数据库中的任何未结订单来取消未结订单。

图2图示了单独合约挂牌数据结构200的示例，该合约挂牌数据结构包括包含示例合约数据的挂牌。现在转向合约挂牌数据结构中的数据字段，加密货币数据字段210包括合约挂牌数据结构200底层的特定加密货币的标识。如图2中所示，加密货币是比特币(BTC)，可以采用所有其它加密货币，诸如以太坊和莱特币。接下来，在合约尺寸数据字段220中，合约的尺寸根据标准化的哈希率和时间来指定，例如每秒100太哈希(Terahashes)(TH/s)。

接下来，在报价格式数据字段230中，合约挂牌数据结构200的报价格式被指定。例如，报价格式可以是难度的千兆哈希(Gigahashes)(GH)或太哈希(TH)。

接下来，在最低价格增量数据字段240中，示出了合约挂牌数据结构220的值在交易期间可以递增或递减的最低价格。最低价格增量以难度单位表达，诸如10GH。

接下来，在合约市值数据字段250中，合约市值根据以下公式计算并存储，该公式示出了确定预期挖矿奖励的公式化方法。在比特币(BTC)的情况下，对于给定的时间段和哈希率，可以根据给定的难度级别来计算以币的数量进行衡量的预期挖矿奖励：

其中R是计算出的预期奖励，其可以用作对该合约的市值的输入；

B是每区块的奖励，其由针对该合约所挂牌的区块间隔的区块链协议定义；

H是指定的哈希率或者说每秒哈希数。在图2的示例中，H可以固定为100TH/s，如在合约尺寸数据字段220中指定的；

S是计算周期内的秒数。在一个实施例中，计算周期中的该秒数可以固定为1,209,600秒或者说14天；

D是区块链所定义的难度级别。该值是由加密货币在其上操作的特定区块链设置的；

N是用于给定区块链的随机数值的范围。该值也由加密货币在其上操作的特定区块链设置。在一个示例中，该随机数值的范围可以是N＝4,294,967,296。

因此，如等式中所示，虽然对于特定合约所采用的B、H、S和N的值可以是固定的，但难度级别D可能变化，并且R的当前值会随着开采加密货币的区块链所规定的当前难度级别而变化。如上式中所示，随着难度级别的增加，R的值减小。这反映了随着难度级别的增加，合约市值中指定的固定量的TH/s不太可能导致矿工赚取到加密货币，这是因为需要执行总体更多的计算才能赚取到加密货币。相反，随着难度级别的降低，R的值增加。同样，这反映了随着难度级别的降低，合约市值中指定的固定量的TH/s更有可能导致矿工赚取到加密货币，这是因为需要执行总体更少的计算来赚取加密货币。在合约的寿命内，难度级别D可能增加或降低。

接下来，在到期日期字段260中，可以设置合约挂牌数据结构200的到期数据。如本文所述，到期日期可以由比特币区块高度确定。例如，比特币难度目标每2,016个区块被重置一次。在一个实施例中，到期数据可以允许合约挂牌数据结构200被挂牌达12次连续重置，或者说总共24,192个区块被添加到区块链。

接下来，在结算方法数据字段270中，可以设置合约挂牌数据结构200的结算方法。在一个实施例中，可以通过将其相应区块链上的加密货币实体结算到客户所控制的账户来进行结算。在另一个实施例中，可以通过在清算所的账册和记录内实体地结算加密货币来进行结算。在另一个实施例中，可以通过在清算所账册和记录内以法币结算加密货币的价值来进行结算。

最后，在结算程序数据字段270中，用于合约挂牌数据结构200的结算程序被指定。在一个实施例中，交易系统可能要求按照由每日合约结算价格确定的基础加密货币(例如，BTC)来每日地交换变动保证金。此外，最终结算可能基于比特币区块链在指定区块高度重置难度之后所发布的难度目标级别。在这个实施例中，结算是基于结算时新设置的难度目标的，其中，该新目标可以是低于、等于或高于在创建合约数据结构时所确定的先前设置的难度目标中的任何一者，并且，确定买方或卖方所欠的东西或在结算时所欠的东西的合约结果可以基于结算时的更新后的难度，如在合约数据结构规范中指定的那样。

图3图示了本交易系统的账户注资过程300。账户注资过程包括客户计算机系统310、客户的银行312、托管银行314和清算所316。转向账户注资过程，首先，在步骤320处，客户310向客户的银行312发送用于将法币从客户的银行312转账到托管银行314的指令。在步骤325处，客户的银行312接收到来自客户310的请求。在步骤330处，客户的银行312将所请求的金额从客户的账户中借记(debit)，并将借记的法币金额转账到托管银行314。

接下来，在步骤335处，托管银行314接收到该法币并通知清算所316。在步骤340处，将客户的法币存款记入(credit)托管银行314处的由清算所316拥有的账户。

然后，在步骤345处，清算所通过确认清算所在托管银行的银行账户中的对应余额增加来验证客户的存入，该确认例如是通过清算所系统通过网络向托管银行的系统发送余额查询来进行的。托管银行的系统从账户数据库中检索余额并通过网络对该查询进行响应。在接收到响应后，清算所系统用新的客户账户余额来更新其自己的内部账户数据库。在步骤350处，清算所316核实其在托管银行314的账户中的余额，并更新内部账本数据库以反映新的内部账本余额。在步骤355处，清算所316在清算所316处记入客户账户以反映客户的存入。最后，在步骤360处，客户310核实客户的该账户的更新后的余额，例如，通过从清算所316检索客户的更新后的账户数据并确认它反映了客户对客户的银行312的指令。

因此，在一个实施例中，为了使用交易系统进行交易，客户在交易所和清算所创建账户并为其注资。例如，客户可以从系统端点提交开户请求。例如，客户可以使用诸如移动应用、PC、服务器等之类的系统端点来提交该请求。系统端点通过网络将请求信息传输到交易所和清算所系统。此外，客户请求消息可以包含诸如姓名、个人识别号码、地址、电话、银行信息、加密货币钱包地址等数据。

在交易所和/或清算所账户系统处，这些系统接收客户的新账户请求、核实客户的身份信息、在账户数据库中创建用户账户，并将身份数据记录在账户数据库中。接下来，客户可以使用系统端点对交易所和/或清算所处的开户进行核实。例如，交易所和/或清算所账户系统可以通过网络向端点系统传输完成消息，并且系统端点可以显示完成消息。

在另一个实施例中，客户从系统端点提交将法币从他/她的银行账户转账到清算所银行账户的请求。例如，用户可以使用诸如移动应用、PC、服务器等之类的系统端点提交该请求。然后系统端点通过网络将转账请求传输到用户的银行。该请求消息可以包含诸如银行账号、金额、币种、收款银行账号等数据。

客户银行系统然后接收该请求、对它进行验证，并处理转账指令。例如，客户银行系统可以通过查询存储在账户数据库中的客户账户余额来验证客户具有足够的资金进行转账。如果客户没有足够的资金来实现转账，那么客户银行系统可以向客户发送错误消息。

客户银行系统然后更新内部事务数据库以反映转账记录。客户银行系统还通过将客户账户余额账户数据库记录减去转账金额来更新存储在账户数据库中的客户账户记录以反映账户余额更新。然后客户银行系统可以发出转账请求。该转账请求可以通过网络被传输到清算所银行系统。

在清算所银行系统处，该请求被接收并验证，并且清算所银行系统处理事务的指令和数据元素。在一个实施例中，清算所银行系统更新存储在账户数据库中的客户账户余额以反映账户余额更新。例如，清算所银行系统可以将入站转账记录在事务数据库中，并将余额数据库记录中的清算所账户余额增加该转账金额。然后清算所银行系统通过网络将事务记录发送到清算所结算系统。该事务记录/消息可以包含诸如银行账号、金额、币种、受益人账号等数据。

清算所结算系统然后从银行系统接收该事务记录。清算所结算系统将客户/受益人账号与客户的清算所账号匹配，并更新存储在余额数据库中的客户账户余额以反映账户余额更新。例如，清算所结算系统可以将余额数据库记录中的客户账户余额增加该转账金额。

最后，客户使用端点系统核实从客户的银行账户转账的法币的更新余额。在一个实施例中，该端点系统通过网络向客户的银行系统传输账户余额查询，然后客户银行系统从账户数据库中提取客户的账户余额并对该查询进行响应。客户端点系统然后接收账户余额查询响应并将余额数据呈现给客户。

图4图示了用于本交易系统的加密货币存入过程400。加密货币存入过程400包括客户计算机系统410、加密货币钱包提供者412、加密货币托管方414、清算所416、区块链网络418和区块链网络418上的公共地址420。现在转向加密货币存入过程400，首先，在步骤425处，客户410请求他们的钱包提供者412将一定数量的加密货币从客户钱包的公共地址转账到加密货币托管方414的公共地址。接下来，在步骤430处，钱包提供者412处的客户的加密货币钱包对客户的请求进行处理。

接下来，在步骤432处，在区块链网络418处，处理加密货币从客户的公共地址到加密货币托管方的公共地址的转账。在步骤434处，区块链节点系统和共识机制确认该转账。在步骤436处，客户的公共地址余额被减少，并且在步骤438处，加密货币托管方的公共地址余额增加。然后，在步骤440处，在清算所416处，区块链节点系统确认该转账。在一个实施例中，区块链节点系统可以自动向加密托管方发送指示余额更新的消息。在另一个实施例中，加密托管方414向区块链节点系统提交余额请求，并且区块链节点系统利用更新后的余额来进行响应。

在步骤442处，加密货币托管方414核实在加密货币托管方414公共地址处从客户接收到加密货币，并通知清算所414。在步骤444处，加密货币托管方414向清算所416发送指令以记入客户的账户。

在步骤446处，清算所通过确认清算所在加密货币托管方处的加密货币托管方账户中的对应余额增加来验证客户的存入，该确认例如是通过清算所系统经由网络向加密货币托管方的系统发送余额查询来进行的。加密货币托管方的系统从账户数据库中检索余额并通过网络对该查询进行响应。在接收到响应后，清算所系统利用新的客户账户余额来更新其自己的内部账户数据库。然后，在步骤448处，清算所416记入客户的加密货币账户余额以反映加密货币的存入。最后，在步骤450处，客户核实预期的更新后的余额出现在清算所416处的客户账户中。

在一个实施例中，客户从系统端点提交将加密货币从他/她的钱包转账到清算所钱包的请求。用户可以使用诸如移动应用、PC、服务器等之类的系统端点来提交该请求。系统端点通过网络将转账请求传输到用户的钱包提供者。该请求消息包含诸如钱包地址、金额、加密货币、接收钱包地址等数据。在区块链节点系统处，转账指令消息被接收，并且钱包通过网络将加密货币转账指令传输到区块链节点系统。

区块链节点系统接收加密货币转账消息，并根据区块链计算方法进行处理。加密货币转账消息可以包括：要转账的加密货币的数量、要从其转账的公共地址以及要将加密货币发送到的公共地址。此外，区块链节点系统可以确认发送方地址具有足够的加密货币来支付所请求的转账和任何相关联的费用。当发送方地址没有足够的加密货币时，区块链共识机制不会确认该事务。作为结果，区块链节点系统不会向清算所区块链节点系统传输余额更新消息，并且可以向客户的钱包传输错误消息。此外，区块链节点系统根据挖矿/共识方法将(一个或多个)加密货币转账事务记录到区块链数据库。

清算所数字托管方通过网络向区块链节点系统查询事务活动。然后，区块链节点检查区块链数据库中区块链上的公共地址事务活动。区块链节点通过网络传输事务记录。事务记录/消息可以包含事务细节，其包括金额、加密货币、始发公共地址等。清算所数字托管方接收该事务记录，并通过网络将它传送到清算所结算系统。清算所结算系统然后更新存储在账户数据库中的账户余额以反映账户余额更新。例如，清算所结算系统可以将账户数据库记录中的清算所账户余额增加转账金额。

清算所结算系统从数字托管方接收事务记录，并将始发公共地址与客户的清算所账户匹配。例如，客户的非清算所钱包地址可以在开户时从客户那里获得并存储在账户数据库中。清算所结算系统然后更新存储在余额数据库中的客户账户余额以反映账户余额更新，诸如转账金额。

客户使用客户计算机系统端点系统来核实区块链上经转账的加密货币的更新后的余额。在一个实施例中，端点系统通过网络向区块链节点传输账户余额查询。区块链节点然后在区块链数据库中检查客户在区块链上的公共地址账户余额。然后，区块链节点通过网络将账户余额查询响应传输到客户端点系统。最后，客户端点系统接收账户余额查询响应，并将余额数据呈现给客户。

图5图示了根据本发明的实施例的交易和清算系统500。交易和清算系统500包括客户505、移动应用511、web浏览器512和交易应用513以及它们各自的API 515-517、互联网或私有网络520、电子交易交易所530、电子清算所550、银行托管系统566、数字托管系统570、区块链节点系统580和区块链590。虽然图5中示出了各个API，但每个API都可以是一个或多个API。如图5中所示，电子交易交易所530包括交易所账户系统532和随附的交易所账户数据库534、参考数据系统536和随附的参考数据数据库538、调度器系统540和随附的调度数据库542、交易系统544以及随附的交易数据库，以及匹配引擎。

电子清算所550包括清算所账户系统552和随附的清算所账户数据库554，以及包括结算数据库558、头寸数据库560和余额数据库562的结算系统556。电子清算所550通过一个或多个API 564连接到银行托管系统556。电子清算所550通过一个或多个API 568连接到数字托管系统570。数字托管系统570还通过API 572与区块链节点系统580通信。交易所系统530还通过一个或多个API 574与区块链590通信。

区块链590包括分布式账本数据库592和共识机制594。当前难度值可以由交易所530的区块链节点系统580通过API 574从分布式账本数据库592中检索。

在操作中，客户505从诸如移动应用511、web浏览器512、交易应用513、PC、服务器等的系统端点向交易所系统530提交用于购买或出售(一个或多个)合约的订单。系统端点然后通过网络520将订单消息传输到交易所交易系统530。交易消息可以包含诸如用户账户、合约标识符、订单类型、数量和价格之类的数据。

交易所交易系统530接收该消息、对它进行验证，并将订单发布到匹配引擎。例如，交易系统可以验证消息的内容，从而核实用户账户、合约、订单类型等。交易系统544可以将订单存储在交易数据库546中。

匹配引擎548基于系统定义的匹配逻辑来尝试对存储在交易数据库546中的一个或多个买入或卖出订单进行匹配。一旦匹配引擎548匹配了两个订单，交易所交易系统530就通过网络将所匹配的订单的细节传送到清算所系统550以进行结算。所匹配的订单的消息中包含的详细信息包括诸如买方/卖方账户、价格、数量、事务时间等信息。

如上所述，参考数据系统被用于建立挂牌合约数据结构，该挂牌合约数据结构然后被存储在参考数据数据库中。此外，如上面所讨论的，调度器系统调度挂牌合约数据结构的状态，包括：挂牌、第一次交易、最后一次交易、到期和摘牌。最后，账户系统被用于在交易所系统530处管理客户的账户，例如通过记录客户的交易、信用和风险限额、账户名称和/或ID号，以及与该账户的系统配置相关的其它账户数据(诸如，账户能够交易的工具、API配置(诸如，账户密码)和风险控制设置(诸如，在通信会话断开时取消未结订单的设置))。

接下来，在清算所系统550处，清算所系统550从交易所系统530处的匹配引擎548接收信息。清算所系统550然后如下在相应的买方和卖方账户中执行结算过程。清算所系统550验证来自匹配引擎548的该信息并将其记录在头寸数据库560中。清算所系统550然后检查买方或卖方账户是否在由合约挂牌数据结构表示的合约中具有现有头寸。当没有找到头寸时，结算系统556在头寸数据库560中创建带有客户头寸的合约挂牌数据结构的新记录。相反，当找到现有头寸时，结算系统556更新头寸数据库560中的头寸数量和头寸价格。清算所系统550然后计算买方和卖方的结算义务并更新余额数据库562中买方和卖方的账户余额。清算所系统550然后将该事务记录在结算数据库558中。

结算细节也被传输到清算所系统550的账户系统552，在那里它们可以被检索并显示给客户505。

图6图示了根据本发明的实施例的盯市系统600。盯市系统600包括电子交易所系统530和图5的电子清算所550。交易所系统530包括交易所调度器系统540、调度器数据数据库542、电子交易系统544、交易数据库546和匹配引擎548。电子清算所550包括结算系统556、结算数据库558、头寸数据库560和余额数据库562。虽然图6中示出了各个API，但每个API都可以是一个或多个API。

在盯市系统600中，未结头寸(open position)可以周期性地，最常见的是每天被盯市，并且变动保证金可以由清算所在账户之间移动，例如清算所更新其内部账册和记录以借记一个或多个账户和贷记(credit)一个或多个账户。现在转向交易所交易系统530，该交易所交易系统基于如下所述的计算方法来计算某一时间点的每日结算价格。定义发生该计算的时间点的数据被存储在调度器系统的调度数据数据库542中。在一个示例中，该计算可以是由存储在交易系统软件中的程序实现的方法。例如，该方法可以是确定在过去24小时内由特定合约挂牌数据结构表示的合约中发生的所有交易的经成交量加权的平均价格(volume weighted average price)。

在交易所调度器系统540处，从调度数据库542检索出结算价格计算调度。交易所调度器系统540然后可以根据此计算过程使用交易系统来发起对结算价格的计算。一个实施例的示例是调度数据数据库542中的合约数据，指示要为双周挂牌的合约(其中到期日期是2019年10月11日星期五，后续的挂牌是2019年10月23日星期五，以此类推)计算盯市价格。在替代实施例中，调度数据数据库542中的合约数据可以指示要为基于比特币的合约(其中到期发生在区块高度598,752、区块高度600,768，以此类推)计算盯市价格。

在一个实施例中，交易所交易系统530计算每个有效合约挂牌的每日盯市价格。该计算可以由交易系统530中的软件执行。如上面所讨论的，盯市价格计算过程可以包括算法，诸如从定义的时间段之间的交易计算的经成交量加权的平均价格(VWAP)。完成该计算所需的数据输入可以被存储和/或从交易所系统530中的一个或多个数据库中检索，包括例如调度数据数据库542、包含事务级别交易历史的交易数据库546、或其它系统数据库。如下文进一步描述的，针对图2中挂牌的合约从这个计算生成的结算价格值的示例为13,000千兆哈希(gigahash)。该值将用作图2中合约公式中的值D。

交易所交易系统530还将每日结算价格数据记录在交易数据库546中、将结算价格数据发布到匹配引擎系统548，并通过网络将每日结算价格数据发布到清算所系统550。

在清算所系统550处，结算系统556接收每日结算价格数据并将其存储在结算数据库558中。结算系统556还发起计算每个客户账户的变动保证金要求。在一个实施例中，结算系统556在它从交易系统530接收结算价格时发起变动保证金计算。在另一个实施例中，结算系统550具有预定义的调度时间点来确定变动保证金，其中该预定时间可以被存储在结算数据库558中。

结算系统556使用每日结算价格数据基于该合约公式来计算新合约市值。参考市值公式的示例可以在图2中找到。如上所述，用于市值公式的值(B、H、S和N)在合约创建时被创建并存储在参考数据数据库538中。作为此价格确定等式中的唯一变量，数据组成部分D在结算时的值会控制在如上所述从交易系统获得的计算中使用的可变结算价格。

每份合约市值计算输出的简化示例如下：

其中，对于13,000的给定价格(例如难度级别(D))，每份合约市值(例如奖励(R))是0.02707999BTC；

12.5是BTC区块奖励(B)；

每秒100太哈希(TH/s)是合约尺寸(H)，并且10

S是1,209,600秒或14天的合约的时间长度；

合约价格以难度(D)的千兆哈希计，并且10

并且用于区块链的随机数的值的范围是4,294,967,296。

如上所述，预期的奖励D的值是唯一变化的项。因此，这使得能够对不利的/增加的难度变化的风险进行对冲(hedging)。区块奖励B最终可能变化，但区块奖励的变化是发生在指定区块高度处的预先确定的经调度的事件。因此，通过将合约结构化为仅在B不变时发生，可以避免作为风险的B的变化。

相反，D由区块链每隔一段时间确定。因此，预期的奖励的值取决于D被更新时发生的情况而变化：D可能上升、下降或保持不变。当合约跨越多次D重置，并且D的值在重置时变化时，那么合约的价值也改变，并且当前系统基于最新近间隔的难度变化来改变变动保证金。最后，在结算时，基于结算前最后一个间隔的难度对合约进行估值以结算。D可以直接从区块链中检索。

结算系统556继续基于账户的头寸(即做多或做空)来计算每个客户账户的变动保证金。在一个实施例中，结算系统556从头寸数据库560检索账户头寸数据。结算系统556然后将变动保证金要求计算为存储在头寸数据库560中的市值与新计算的市值之间的头寸市值变化。

在一个实施例中，变动保证金结算以合约的基础加密货币的形式发生。例如，如下所述，所存储的市值与新确定的市值之间的计算出的差额表示需要被结算的变动保证金。下表图示了示例，其中图2中引用的合约的每个账户的变动保证金已被确定为0.10029628BTC。如上所述，难度级别D在被区块链重置时可能不同。在这个示例中，难度级别已从之前的结算值13,000更改为其当前的结算值13,500。由于难度级别增加，合约的预期回报(并且因此，市值)下降。

在这个示例中，客户账户#1是做多100份合约，并且客户账户#2是做空100份合约。前一天的结算价格是难度13,000GH(其使用图2中所示的计算得出值为2.70799949BTC)，并且当天的结算价格是难度13,500GH(其使用图2中所示的计算得出值2.60770321BTC)。因此，两个账户的头寸值的变化都是0.10029628BTC。因为客户账户#1是做多，客户账户#1由于价格(即，难度)上涨而收到变动保证金，并且由于客户账户#2是做空，因此客户账户#2必须支付变动保证金。因此，客户账户#2被借记0.10029628BTC，并且客户账户#1被贷记0.10029628BTC。然后这些借记和贷记被记录在余额数据库562中，该数据库存储买方和卖方的账户余额。当客户账户没有足够的BTC来满足变动保证金时，本系统可以向客户发出保证金通知。此外，对于特定合约，系统可以被配置为要求以基础加密货币支付追加保证金，或者要求以法币支付追加保证金，或者可以允许支付追加保证金的客户选择是用基础加密货币还是用法币来支付它。

在另一个实施例中，变动保证金结算以合约的法币面额的法币的形式(例如美元等)进行。与上例类似，下表中的难度级别也从先前的结算值13,000变为其当前的结算值13,500。由于难度级别增加，合约的预期的奖励(并且因此，市值)下降。方向、数量、先前结算、当前结算、先前值、当前值和变动保证金的条目因此与上表相同。然而，已添加先前法币(PreviousFiat)、当前法币(CurrentFiat)、先前值法币(PreviousValueFiat)、当前值法币(CurrentValueFiat)和变动保证金法币(VariationMargin Fiat)。先前法币是加密货币的一个单位在最后一个盯市时的法币计价的盯市值，并且当前法币是加密货币的一个单位在当前盯市时的法币计价的盯市值。先前值法币是由先前值乘以先前法币计算出的头寸的法币计价的值。当前值法币是由当前值乘以当前法币计算出的头寸的法币计价的值。变动保证金法币是用法币(诸如，美元)表达的先前值法币和当前值法币之间的差额。

下表图示了示例，其中基于BTC的先前价格7,450.00美元和BTC的当前价格7,500.00美元，对于表2中引用的合约的每个账户，变动保证金已被确定为616.82美元。

为了确定变动保证金结算的法币等价性，结算系统执行到法币的转换，作为其结算计算的一部分。作为结算价格发布过程的一部分，结算系统附加地从参考数据数据库中接收并存储来自交易系统的加密货币到法币价格。然后将这些借记和贷记记录在余额数据库562中，该数据库存储买方和卖方的账户余额。在一个实施例中，由交易系统基于例如在一个或多个参考市场上加密货币对法币的(一个或多个)最近交易(例如BTC对USD)，将加密货币到法币价格(crypto-to-fiat)添加到参考数据数据库中。在一个实施例中，参考市场可以是单一市场，诸如ErisX的现货市场。在另一个实施例中，参考可以是现货市场的指数。交易系统可以通过网络从源、市场或指数提供者接收加密货币到法币价格，并将加密货币到法币价格添加到参考数据数据库。

如上面提到的，变动保证金结算按照结算数据库558中设置的预定义调度发生并且被记录到客户账户。在一个实施例中，客户账户之间的移动在结算系统已经完成了变动保证金计算时被发起。在另一个实施例中，客户账户之间的移动在定义的时间点(例如诸如在午夜)发生。

如上面提到的，对客户账户余额的更新随后被存储在余额数据库563中以反映变动保证金结算。因此，针对客户拥有的每项资产或合约，客户账户可能基于合约的变动保证金结算而增加或减少。此外，当客户账户没有足够的法币来满足变动保证金时，本系统可以向客户发出保证金通知。此外，对于特定合约，系统可以被配置为要求以基础加密货币支付追加保证金，或者要求以法币支付追加保证金，或者可以允许支付追加保证金的客户选择是用基础加密货币还是用法币支付它。

图7图示了根据本发明的实施例的最终结算系统700。最终结算系统700包括图5的电子交易所系统530和电子清算所550。交易所系统530包括交易所调度器系统540、调度器数据数据库542、电子交易系统544、交易数据库546、匹配引擎548、参考数据数据库538、参考数据系统536和区块链节点系统580。电子清算所550包括结算系统556、结算数据库558、头寸数据库560和余额数据库562。图7还示出了包括分布式账本数据库592和共识机制594的区块链590，以及包括区块链数据系统720和区块链数据数据库730的第三方区块链数据提供者710。虽然图7中示出了各个API，但每个API都可以是一个或多个API。

在操作中，在合约的最终结算处，其价格是根据给定合约的基础加密货币的区块链所发布的难度目标级别而确定的。当确定特定合约挂牌数据结构的当前时间与关联于该合约挂牌数据结构的预定到期时间匹配时，最终结算过程在交易所调度器系统540处开始。此时，交易所调度器系统540将合约状态数据的变化传输到交易系统544。换句话说，交易所调度器系统540设置合约以处理最终结算并发起交易系统以更新交易数据库546中的合约状态并检索交易数据库546中的数据用于最终结算。如上所述，发生数据提取的时间点在调度器系统540的调度数据库542中定义。如前所述，到期和/或最后交易事件可以是指定的日期和时间或区块链区块高度。

接下来，交易所交易系统544获得合约时段的难度级别。在一个实施例中，难度级别直接从区块链获得。例如，参考数据系统536可以向区块链节点系统580传输对难度级别的请求。然后区块链节点系统可以接收该请求、从区块链软件中检索难度级别，并返回难度级别。如上所述，当合约只跨越单次难度重置时，难度是静态的。然而，当合约跨越两个或更多次重置并且难度级别被重置时，合约的价值被调整。

在另一个实施例中，难度级别从专门研究区块链数据的第三方区块链数据提供者710获得。在本实施例中，参考数据系统536可以通过一个或多个API向第三方区块链数据提供者710传输请求。第三方区块链数据提供者710可以从与其区块链数据系统720相关联的区块链数据数据库730中检索难度数据，然后将难度数据返回到区块链节点系统580，区块链节点系统580继而可以将难度信息传输到参考数据系统536。区块链数据系统720可能先前已经从分布式账本数据库中检索到难度级别数据，并将其存储在区块链数据数据库中。如上所述，本系统使用最新近的难度级别值来确定合约估值。

接下来，交易所交易系统544将难度级别转换成合约价格格式。例如，对于图2中引用的合约，如果最终结算时的难度级别为13,750,000,000,000，那么交易系统将把最终结算价格转换并存储为13,750(GH)。交易所交易系统544将最终结算价格记录在交易数据库546中，并通过网络将最终结算价格发布到清算所系统550。

清算所系统550接收最终结算价格并将其存储在结算数据库558中。然后清算所系统550发起对于每个账户的最终结算义务要求的计算。在一个实施例中，结算系统556在它从交易系统530接收到结算价格时发起该最终结算计算。在另一个实施例中，结算系统556在预定时间点(例如诸如午夜)发起该最终结算计算。

然后，结算系统556基于图2的合约公式使用最终结算价格来计算最终合约市值，即奖励。继续上面的示例，其中先前的结算价格13,000已经上升到当前的结算价格13,500，考虑最终结算价格现在已确定为13,750的示例。对于这个最终结算价格，使用图2中所示的公式并如下文进一步描述，最终合约市值为0.02560290BTC。

结算系统556基于每个账户的头寸(即做多或做空)计算该账户的最终结算义务。对于每个账户，结算系统556从头寸数据库560检索账户头寸数据。在变动保证金结算为实际加密货币的一个实施例中，最终结算义务基于头寸市值的变化被计算为最终变动保证金结算。

与上述盯市示例类似，图2中引用的合约的最终结算的简化示例计算如下：

在本例中，客户账户#1是做多100份合约，并且客户账户#2是做空100份合约。前一天的结算价格是难度13,500GH(其使用图2中所示的计算得出值2.60770321BTC)，并且当天的结算价格是难度的13,750GH(其使用图2中所示的计算得出值2.56029042BTC)。因此，两个账户的头寸值的变化都是0.04741279BTC。因为客户账户#1是做多，所以客户账户#1由于价格(即，难度)上涨而收到变动保证金，并且由于客户账户#2是做空，所以客户账户#2必须支付变动保证金。因此，客户账户#2被借记0.04741279BTC，并且客户账户#1被贷记0.04741279BTC。然后这些借记和贷记被记录在余额数据库562中，该数据库存储买方和卖方的账户余额。如上所述，当客户账户没有足够的BTC来满足变动保证金时，本系统可以向客户发出保证金通知。此外，对于特定合约，系统可以被配置为要求以基础加密货币支付追加保证金，或者要求以法币支付追加保证金，或者可以允许支付追加保证金的客户选择是用基础加密货币还是用法币支付它。

与上述盯市计算类似，在变动保证金结算采用合约法币面额的法币形式的另一个实施例中，最终结算义务被计算为加密货币的实物交割和法币结算。例如，在上面讨论的示例的基础上，在下表中，添加了交易价格(TradePrice)、交易法币(TradeFiat)、交易值(TradeValue)和交易值法币(TradeValueFiat)。交易价格是合约在双方之间第一次交易的价格，在本例中为13,000。交易法币是加密货币的一个单位在它被第一次交易之日以法币计价的盯市值。交易值是使用图2中所示的计算提供的值。交易值法币是头寸的法币计价值，被计算为交易值乘以交易法币。

在本例中，客户账户#1和#2具有13,000的原始交易价格。在最终结算价格为13,750的情况下，这导致每个账户的头寸的奖励差额为0.14770906BTC。客户账户#2做空，并且在价格增加(即难度增加)的情况下，客户账户#2有义务用实物BTC来交付该奖励差额。

由于先前变动保证金结算是以法币(例如，美元)作为抵押的，因此先前变动保证金现在被偿还给清算所。例如，对于每个账户，先前累积变动保证金结算总计为616.82美元，其中客户账户#1收到了法币收益。作为结果，客户账户#1有义务将616.82美元返还给清算所。

如上所述，结算系统556为每个客户账户和每个合约将最终结算计算输出存储在结算数据库558中。如上所述，客户账户的最终结算调整可以按照存储在结算数据库558中的预定义调度而发生。例如，客户账户的最终结算调整可以在结算系统完成最终结算义务计算时发起。替代地，客户账户的最终结算调整可以在存储在结算系统中的预定时间处(例如诸如在午夜)发生。结算系统通过基于客户账户的最终结算义务而增加或减少每项资产的客户账户余额来更新存储在余额数据库中的客户账户余额以反映最终结算。此外，当客户账户没有足够的法币来满足变动保证金时，本系统可以向客户发出保证金通知。此外，对于特定合约，系统可以被配置为要求以基础加密货币支付追加保证金，或者要求以法币支付追加保证金，或者可以允许支付追加保证金的客户选择是用基础加密货币还是用法币支付它。

因此，通过使用本系统，加密货币矿工有机会以固定价格出售一份或多份合约，这些合约表示其挖矿硬件执行的全部或部分实际数量的TH/s。如上所述，由于加密货币挖矿的概率性而非确定性，因此矿工无法提前确定由于他们的挖矿业务实际将获得多少加密货币，并且加密货币的金额可能大于或小于本系统下他们合约的售价。此外，由于加密货币的市场价格可能变化，因此矿工无法提前确定由于挖矿操作而实际授予他们的任何加密货币的美元价值。然而，一旦加密货币矿工卖出了一份或多份合约，那么对于由该一份或多份合约表示的矿工的挖矿硬件提供的TH/s的部分，矿工的美元价值是已知的，并且被固定为对于该一份或多份合约矿工收到的价格。加密货币矿工通过使用本系统出售合约来实现收入稳定性的能力对于加密货币矿工来说是非常期望的。这是因为矿工通常具有以工资、电力成本和其它运营开销的形式的法币计价的债务。如果矿工完全暴露于其产出价值波动的风险而不能管理价格/市场/难度风险，那么他们将面临其产出收入不足以支付其运营开支的风险和/或使得财务预测和计划更具风险和困难。这些风险类似于更传统的大宗商品生产商(诸如农民、贵金属和贱金属矿工、石油生产商和其它受其产出市场价格波动影响的公司等)所面临的风险。

虽然已经示出和描述了本发明的特定元件、实施例和应用，但是应该理解的是，本发明不限于此，因为本领域技术人员可以具体地鉴于前述教导做出修改。因此，所附权利要求涵盖了这样的修改并结合了落入本发明的精神和范围内的那些特征。