一种确定起息日的方法及系统与流程

本发明涉及报文清算技术领域，尤其涉及一种确定起息日的方法及系统。

背景技术：

起息日是银行交易的重要日期，在实际系统中，全球每个分行的起息日确定参数值是不一样的，而且针对不同的业务场景还有不同的起息日确定方式。如果总行有统一的变动需求，比如修改起息日判断逻辑、增添业务场景等，或是各个分行需要变更起息日基础数据时，需要逐个分行的进行修改测试，同时对于不同的业务场景要编写对应的代码，存在以下的技术缺点：(1)起息日基础数据维护在代码中，查找困难，需要专门技术人员从后台维护，存在业务和技术人员的沟通成本，及时性不高；(2)人工逐个分行维护，错误率高；(3)全球各个分行之间存在时区差异，工作时间不一致，难以统一安排变更，增加人员成本；(4)各分行实现逻辑一致，却各自维护一段实现代码，造成代码冗余，增加后期修改实现逻辑的工作量；(5)针对不同业务场景维护不同的代码，扩展性不好。

技术实现要素：

针对现有技术中存在的上述技术问题，本发明实施例提供了一种确定起息日的方法及系统。

一方面，本发明实施例提供了一种确定起息日的方法，所述方法包括：

接收交易报文并解析，获取所述交易报文的支付渠道、初始起息日及借贷方信息；

根据所述初始起息日判断所述交易报文是否为倒起息交易；

如果所述交易报文不是倒起息交易，判断所述初始起息日是否命中假日；

如果所述初始起息日未命中假日，判断所述初始起息日是否超过所述支付渠道允许的最晚起息日；

如果所述初始起息日未超过所述支付渠道允许的最晚起息日，根据所述借贷方信息和处理日期对应的预设参数确定所述交易报文的处理日期；

根据所述借贷方信息、处理日期及借方起息日预设参数、贷方起息日预设参数，确定所述交易报文的借方起息日及贷方起息日。

另一方面，本发明实施例还提供了一种确定起息日的系统，所述系统包括：

报文解析单元，用于接收交易报文并解析，获取所述交易报文的支付渠道、初始起息日及借贷方信息；

倒起息判断单元，用于根据所述初始起息日判断所述交易报文是否为倒起息交易；

假日校验单元，用于判断所述初始起息日是否命中假日；

起息日校验单元，当所述初始起息日未命中假日时，用于判断所述初始起息日是否超过所述支付渠道允许的最晚起息日；

处理日期计算单元，当所述初始起息日未超过所述支付渠道允许的最晚起息日时，用于根据所述借贷方信息和处理日期对应的预设参数确定所述交易报文的处理日期；

起息日确定单元，用于根据所述借贷方信息、处理日期及借方起息日预设参数、贷方起息日预设参数，确定所述交易报文的借方起息日及贷方起息日。

本发明实施例通过建立规则引擎机制，将不同的业务场景和假日场景条目化为判断条件和相应的动作，形成数据库存储文本，通过对比来报与数据库内容，确定报文落入哪些业务场景，并利用数据库本身的索引机制，建立条件与动作之间的多对一关系，即本发明实施例用可配置的规则去驱动不同的业务场景和假日判断，提高不同场景处理机制的灵活性，提高了开发效率，减少了代码量。同时，通过将参数变更接口留给业务人员，提高了维护效率，降低时间和人工成本，同时可达到各分行共用一套处理逻辑，减少代码冗余，也降低了之后代码修改的工作量。并且，本发明实施例通过确定不同业务场景的规则命中条件和起息日确定办法，当报文命中起息日判定规则的时候，能够快速得到起息日，不需要更改核心代码，节省代码量，提高灵活性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的确定起息日的方法的大体流程示意图；

图2为本发明实施例提供的确定起息日的系统的大致结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例提供的确定起息日的方法的大体流程示意图。如图1所示，该方法主要包括以下步骤：

步骤11，接收交易报文并解析，获取该交易报文中包含的支付渠道、初始起息日及借贷方信息。

通常地，交易报文中都会包含日期，可以将该日期作为初始起息日，对于swift报文就是32场日期。如果交易报文为通过前端汇出的报文，那么报文中未提供日期，可以采用分行当前的营业日作为初始起息日，若手动修改出报报文的日期，则采用修改后的日期作为初始起息日。

步骤12，根据初始起息日判断所述交易报文是否为倒起息交易。

在一实施例中，如果初始起息日小于当前的分行营业日，即在营业日之前开始起息的交易(例如信用卡还款逾期后从刷卡日起息)为倒起息交易。如果上述交易报文的初始起息日满足：初始起息日＞＝分行营业日，即上述交易报文的起息日在分行的营业日之后，那么该交易为晚起息交易，则进入步骤13处理。

步骤13，判断初始起息日是否命中假日。

目前，银行系统中需要考虑的节假日有6种，包括本行假日、支付渠道假日、收报行国家假日、收报行假日、借记币种假日和贷记币种假日，这是作为静态参数配置在系统中的，由业务人员提供并按照基础数据进行维护。对于每个假日，可以设置一条规则规定哪些业务场景需要考虑它，比如对于所有的业务场景都要考虑本行假日，对于本币转汇的业务还要考虑收报行国家假日等。

对于一笔来报，可能需要考虑一种假日，也可能需要考虑多种假日。如果上述初始起息日未命中假日，则进入步骤14处理。

步骤14，判断上述初始起息日是否超过上述支付渠道允许的最晚起息日。

在一实施例中，通常需要根据不同分行的需求预先配置各分行在不同支付渠道下的以下参数：实际允许倒起息天数(allowedbackdatedvaluedatetoretain，以下简称retain)、最大允许的倒起息天数(allowedbackdatedvaluedatetoadvance，以下简称advance)、最早起息天数(earliestvaluedate，以下简称earliest)、最晚起息天数(latestvaluedate，以下简称latest)及最早起息天数的延伸天数(valuedateextension，以下简称value)，其中，advance通常大于retain，earliest大于等于latest。advance与retain之差指的是最大允许的倒起息天数的缓冲天数。上述参数通常以数据表的形式配置在各分行的数据库中，并且在界面上提供修改接口，接口对应数据表中的参数项，方便用户根据实际情况修改数据表中的参数项，当参数发生改变时，对应的数据库中的数据也会对应改变。

在判断初始起息日是否超过上述支付渠道允许最晚起息日时，通常判断以下不等式是否成立：

初始起息日－分行营业日＜＝earliest+extension

如果上式成立，则说明上述初始起息日未超过所述支付渠道所允许的最晚起息日，进入步骤15进行处理。

步骤15，根据所述借贷方信息以及处理日期对应的预设参数确定所述交易报文的处理日期。

步骤16，根据借贷方信息、处理日期及借方起息日预设参数、贷方起息日预设参数，确定所述交易报文的借方起息日及贷方起息日。

通常的，先根据借贷方信息的借方账户类型及贷方账户类型，分别查询相应的借方起息日预设参数及贷方起息日预设参数，然后，分别根据所述借方起息日预设参数、贷方起息日预设参数以及处理日期，确定所述交易报文的借方起息日及贷方起息日。

本发明实施例利用数据库的存储机制，将涉及各分行起息日计算的数据存储在数据表中，同时在界面上提供修改接口，以方便根据实际情况修改数据；编写统一的计算逻辑，提供数据传输接口，不同分行载入不同的数值，实现代码共用，减少系统冗余。并且，利用本发明实施例，可以根据不同业务场景设置不同判断规则，实现个性化服务。

在一实施例中，当步骤12判断结果为倒起息交易时，还需进一步判断该初始起息日是否在所述支付渠道最大允许的倒起息范围内(步骤17)，即判断上述的初始起息日是否满足下式：

初始起息日＞＝分行营业日－所述支付渠道最大允许的倒起息天数(advance)(3)

如果初始起息日满足上述不等式(3)，说明初始起息日在所述支付渠道允许的倒起息范围内。进一步判断所述初始起息日是否在所述支付渠道实际允许的倒起息范围内(步骤19)，即判断初始起息日是否满足不等式(4)：

初始起息日＜＝分行营业日－所述支付渠道实际允许的倒起息天数(retain)(4)

如果所述初始起息日也满足上述不等式(4)，说明初始起息日在所述支付渠道实际允许的倒起息范围内，再利用步骤13对该初始起息日进行假日校验，判断其是否命中假日。如果所述初始起息日在所述支付渠道最大允许的倒起息范围内但超出实际允许的倒起息范围，即初始起息日满足不等式(3)，但不满足不等式(4)，则将所述初始起息日调整为实际允许的最大倒起息日(步骤20)，再进入步骤13以判断所述调整后起息日是否命中假日。

如果步骤17的判断结果为，所述初始起息日不在所述支付渠道最大允许的倒起息范围内，将所述交易报文送入手工修复队列(步骤18)，以修复所述初始起息日使其在所述支付渠道最大允许的倒起息范围内。然后，利用步骤19进一步判断修复后的起息日是否在所述支付渠道实际允许的倒起息范围内，如果修复后的起息日在所述支付渠道实际允许的倒起息范围内，则利用步骤13判断所述修复后的起息日是否命中假日。

如果步骤19的判断结果为，所述修复后的起息日在所述支付渠道最大允许的倒起息范围内但超出实际允许的倒起息范围，可利用步骤20将所述修复后的起息日调整为实际允许的最大倒起息日，再利用步骤13判断该调整后的起息日是否命中假日。

另外，在将该交易报文送到手工修复队列中后，如果无人处理，那么该交易报文一直落手工，直到工作人员对该交易报文的初始起息日做了手工修复，可以利用步骤19再次对修复后的起息日进行校验，也可以在将该起息日修复后返回到步骤12中再次进行校验，直至修复后的起息日在所述支付渠道实际允许的倒起息范围内时，再对修复后的起息日进行假日校验，判断其是否命中假日。

在一实施例中，假日判断是针对每笔来报的，根据来报确定它属于哪种业务场景，再根据业务场景确定它需要考虑哪些假日。在计算起息日的时候，都要判断一下起息日是否是假日。如果起息日是假日，就需要往后调整到工作日。因此，在利用步骤13对初始起息日或修复后的起息日进行假日校验，判断起息日是否命中假日时，通常先根据借贷方信息中的借方账户类型、贷方账户类型确定交易报文所处的业务场景，然后结合该业务场景所考虑的假日，来判断初始起息日或者修复后的起息日是否命中当前业务场景所对应的假日。

在一实施例中，如果步骤13的判断结果为起息日命中假日，那么将该起息日后的第一个工作日作为新起息日(步骤21)，再利用步骤14判断该新起息日是否超过所述支付渠道允许的最晚起息日，即判断新起息日是否满足以下不等式：

新起息日－分行营业日>earlist+extension(5)

如果新起息日并未超过所述支付渠道允许的最晚起息日，即不等式(5)不成立，进入步骤15处理。如果新起息日超过支付渠道允许的最晚起息日(即不等式(5)成立)，那么将该交易报文送入手工修复队列(步骤18)，以修复起息日使其在所述支付渠道允许的晚起息范围内，再根据步骤15确定所述交易报文的处理日期。

针对不同的业务场景，可定制对应的起息日确定方案，即确定借方起息日及贷方起息日。

通常地，借贷方信息包括但不限于借方账户类型和贷方账户类型，在具体实施时可以根据不同账户类型之间的转账来区分不同的业务场景，这些业务场景包括：借方是nos账户(用户行在对手行开立的账户，以下简称nos)，贷方为vos(对手行开在用户行开立的账户，以下简称vos)、nos、set(用户行行开在清算机构的账户，与nos账户类似，以下简称set)或者dep账户(客户帐户，以下简称dep)；借方为vos账户，贷方为vos、nos、set或dep账户；借方为set账户，贷方为vos、nos、set或dep账户等场景。针对这些不同的业务场景，可以定制对应的处理日期、起息日确定方案。

在一实施例中，可将处理日期对应的预设参数设置为以下几种：alap(aslateaspossible，尽可能晚)，asap(assoonaspossible，尽可能早)，onbusinessdate(在分行营业日当天)。

根据借贷方信息确定业务场景后，如果根据该业务场景查询到的相应的处理日期预设参数为alap时，所述交易报文的处理日期取值为：初始起息日－所述支付渠道允许的最晚起息天数(latest)。当查询到的处理日期预设参数设为asap时，所述交易报文的处理日期取值为：初始起息日－(所述支付渠道允许的最早起息天数的延伸天数(extension)+允许的最早起息天数(earliest))。当查询到的处理日期预设参数设为onbusinessdate时，所述交易报文的处理日期置为分行营业日当天。如果初始起息日有调整，计算处理日期时应用调整后的起息日替换初始起息日，下同。

当初始起息日－所述支付渠道允许的最晚起息天数(latest)＜分行营业日时，或者，当初始起息日－(所述支付渠道允许的最早起息天数的延伸天数(extension)+允许的最早起息天数(earliest))<分行营业日时，则将所述处理日期置为分行营业日。

如果起息日满足：起息日－(所述支付渠道允许的最早起息天数的延伸天数((extension))+允许的最早起息天数(earliest))＞分行营业日时，不管预设参数是asap还是alap，所述交易报文均落入人工修复队列。

在一实施例中，当调整后起息日－所述支付渠道允许的最晚起息天数(latest)＜分行营业日时，最终调整后起息日＝原调整后起息日+分行营业日－(原调整后起息日－所述支付渠道允许的最晚起息天数)。举例说明，如果调整后的起息日为12月10日，latest值取10天，当前分行的营业日为12月5日，那么，调整后起息日－所述支付渠道允许的最晚起息天数(latest)＝12月10日－10天＝12月1日，该日期在分行营业日(12月5日)之前，则最终调整后起息日＝12月10日+[12月5日－(12月10日－10天)]＝12月15日。

另外，除了根据支付渠道中配置的值计算处理日期外，还会根据货币中配置的最早起息日天数(soonest值)来确定处理日期，其作用相当于上述的latest值。可以根据需求选择是只有货币兑换的时候考虑，还是总不考虑，或者总是考虑。当默认设置为只有在货币兑换的时候考虑soonest值，那么当查询到的处理日期预设参数为alap时，所述交易报文的处理日期取值为：初始起息日－max[所述支付渠道允许的最晚起息天数(latest)，货币中的soonest值]，即，初始起息日减去latest、soonest中较大的那个值。

在一实施例中，上述的借方起息日预设参数的取值及贷方起息日预设参数的取值是可以进行静态参数配置的，其具体参数值分别参见表1及表2：

表1借方起息日预设参数及参数描述

表2贷方起息日预设参数及参数描述

如果根据借方账户类型查询到的借方起息日预设参数为onvaluedate，则借方起息日以经过倒起息校验、假日校验、最晚起息日校验等步骤后最终计算出的起息日为准。这种预设参数适用于借记非资产账户，包括dep客户账户、vos账户、sus中间账户等。

如果根据借方账户类型查询到的借方起息日预设参数为onoriginalvaluedate，则以交易报文原始自带的日期作为借方起息日，不管这个日期是否命中假日。这种预设参数适用于借记nos账户和清算账户。

如果根据借方账户类型查询到的借方起息日预设参数为onprocessingdate，那么将借方起息日设置为与步骤15计算得到的处理日期相同。

如果根据贷方账户类型查询到的贷方起息日预设参数为onvaluedate，则贷方起息日以经过倒起息校验、假日校验、最晚起息日校验等步骤后最终计算出的起息日为准。

如果根据贷方账户类型查询到的贷方起息日预设参数为onoriginalvaluedate，则以解析交易报文得到的初始起息日作为贷方起息日，如果这个初始起息日为假日，则调整到假日后的第一个工作日。

如果根据贷方账户类型查询到的贷方起息日预设参数为ondebitvaluedate，那么贷方起息日与借方起息日相同。

本发明实施例通过建立规则引擎机制，将不同的业务场景和假日场景条目化为判断条件和相应的动作，形成数据库存储文本，通过对比来报与数据库内容，确定报文落入哪些业务场景，并利用数据库本身的索引机制，建立条件与动作之间的多对一关系，即本发明实施例用可配置的规则去驱动不同的业务场景和假日判断，提高不同场景处理机制的灵活性，提高了开发效率，减少了代码量。同时，通过将参数变更接口留给业务人员，提高了维护效率，降低时间和人工成本，同时可达到各分行共用一套处理逻辑，减少代码冗余，也降低了之后代码修改的工作量。并且，本发明实施例通过确定不同业务场景的规则命中条件和起息日确定办法，当报文命中起息日判定规则的时候，能够快速得到起息日，不需要更改核心代码，节省代码量，提高灵活性。

基于与图1所示的确定起息日的方法相同的发明构思，本发明实施例还提供了一种系统，如下面实施例所述。由于该系统解决问题的原理与图1中确定起息日的方法相似，因此该系统的实施可以参见图1所示的确定起息日的方法的实施，重复之处不再赘述。

在另一实施例中，本发明还提供了一种确定起息日的系统，其大致结构如图2所示，该系统主要包括以下部分：报文解析单元21、倒起息判断单元22、假日校验单元23、起息日校验单元24、处理日期计算单元25及起息日确定单元26。

其中，报文解析单元21主要用于接收交易报文并解析，获取所述交易报文的支付渠道、初始起息日及借贷方信息。倒起息判断单元22用于根据所述初始起息日判断所述交易报文是否为倒起息交易。假日校验单元23用于判断所述初始起息日是否命中假日。当所述初始起息日未命中假日时，起息日校验单元24用于判断所述初始起息日是否超过所述支付渠道允许的最晚起息日。当所述初始起息日未超过所述支付渠道允许的最晚起息日时，处理日期计算单元25用于根据所述借贷方信息和处理日期对应的预设参数确定所述交易报文的处理日期。起息日确定单元26用于根据所述借贷方信息、处理日期及借方起息日预设参数、贷方起息日预设参数，确定所述交易报文的借方起息日及贷方起息日。

在一实施例中，如果所述交易报文为倒起息交易，倒起息判断单元2还用于判断所述初始起息日是否在所述支付渠道最大允许的倒起息范围内。如果所述初始起息日在所述支付渠道最大允许的倒起息范围内，进一步判断所述初始起息日是否在所述支付渠道实际允许的倒起息范围内；如果所述初始起息日在所述支付渠道实际允许的倒起息范围内，由假日校验单元23判断所述初始起息日是否命中假日。如果所述初始起息日不在所述支付渠道最大允许的倒起息范围内，由倒起息判断单元22将所述交易报文送入手工修复队列，以修复所述初始起息日使其在所述支付渠道最大允许的倒起息范围内；进一步判断修复后的起息日是否在所述支付渠道实际允许的倒起息范围内；如果所述初始起息日或者修复后的起息日在所述支付渠道实际允许的倒起息范围内，再由假日校验单元23判断修复后的起息日是否命中假日。

在一实施例中，如果所述初始起息日在所述支付渠道最大允许的倒起息范围内但超出实际允许的倒起息范围，倒起息判断单元22还用于将所述初始起息日调整为实际允许的最大倒起息日，再由假日校验单元23判断所述调整后起息日是否命中假日。如果所述修复后的起息日在所述支付渠道最大允许的倒起息范围内但超出实际允许的倒起息范围，倒起息判断单元22还用于将所述修复后的起息日调整为实际允许的最大倒起息日，再由假日校验单元23判断所述调整后的起息日是否命中假日。

在一实施例中，假日校验单元23具体用于根据所述借贷方信息中的借方账户类型、贷方账户类型，确定所述交易报文所处的业务场景，然后，判断初始起息日是否命中所述业务场景对应的假日。

在一实施例中，如果所述初始起息日命中假日，假日校验单元23还用于将所述初始起息日后的第一个工作日作为新起息日，然后利用起息日校验单元24判断该新起息日是否超过所述支付渠道允许的最晚起息日，如果该新起息日并未超过所述支付渠道允许的最晚起息日，则由处理日期计算单元25根据所述借贷方信息和处理日期对应的预设参数确定所述交易报文的处理日期。如果新起息日超过所述支付渠道允许的最晚起息日，则由起息日校验单元24将所述交易报文送入手工修复队列，以修改所述新起息日使其在所述支付渠道允许的晚起息范围内，再由处理日期计算单元25根据所述借贷方信息和处理日期对应的预设参数确定所述交易报文的处理日期。

在一实施例中，处理日期计算单元25具体用于：根据所述借贷方信息查询系统中与所述借贷方信息对应的处理日期预设参数，所述预设参数包括：第一预设值，第二预设值，第三预设值。当预设参数为第一预设值时，处理日期计算单元25将交易报文的处理日期取值为：初始起息日－所述支付渠道允许的最晚起息天数；当预设参数为第二预设值时，处理日期计算单元25将交易报文的处理日期取值为：初始起息日－(所述支付渠道允许的最早起息天数的延伸天数+所述支付渠道允许的最早起息天数)；当预设参数为第三预设值时，处理日期计算单元25将所述交易报文的处理日期置为当前的分行营业日。

在一实施例中，当初始起息日－所述支付渠道允许的最晚起息天数＜分行营业日时，或者，当初始起息日－(所述支付渠道允许的最早起息天数的延伸天数+所述支付渠道允许的最早起息天数)＜分行营业日时，处理日期计算单元25将所述处理日期置为分行营业日。

在一实施例中，起息日确定单元26具体用于根据所述借贷方信息中的借方账户类型及贷方账户类型，分别查询相应的借方起息日预设参数及贷方起息日预设参数。然后，起息日确定单元26分别根据所述借方起息日预设参数、贷方起息日预设参数及处理日期确定所述交易报文的借方起息日及贷方起息日。

在一实施例中，所述借方起息日预设参数包括第一借方参数，第二借方参数及第三借方参数，所述贷方起息日预设参数包括第一贷方参数，第二贷方参数及第三贷方参数；分别根据所述借方起息日预设参数、贷方起息日预设参数及处理日期确定所述交易报文的借方起息日及贷方起息日。

当查询到的借方起息日预设参数为第一借方参数时，起息日确定单元26以最终计算出的起息日作为借方起息日；当查询到的借方起息日预设参数为第二借方参数时，起息日确定单元26以交易报文自带的初始起息日作为借方起息日；当查询到的借方起息日预设参数为第三借方参数时，起息日确定单元26以所述处理日期作为借方起息日。

当查询到的贷方起息日预设参数为第一贷方参数时，起息日确定单元26以最终计算出的起息日作为贷方起息日；起息日确定单元26当查询到的贷方起息日预设参数为第二贷方参数时，起息日确定单元26以交易报文自带的初始起息日作为贷方起息日，如果该初始起息日为假日，则以假日后第一个工作日作为贷方起息日；当查询到的贷方起息日预设参数为第三贷方参数时，起息日确定单元26以所述贷方起息日与所述借方起息日相同。

本发明实施例通过建立规则引擎机制，将不同的业务场景和假日场景条目化为判断条件和相应的动作，形成数据库存储文本，通过对比来报与数据库内容，确定报文落入哪些业务场景，并利用数据库本身的索引机制，建立条件与动作之间的多对一关系，即本发明实施例用可配置的规则去驱动不同的业务场景和假日判断，提高不同场景处理机制的灵活性，提高了开发效率，减少了代码量。同时，通过将参数变更接口留给业务人员，提高了维护效率，降低时间和人工成本，同时可达到各分行共用一套处理逻辑，减少代码冗余，也降低了之后代码修改的工作量。并且，本发明实施例通过确定不同业务场景的规则命中条件和起息日确定办法，当报文命中起息日判定规则的时候，能够快速得到起息日，不需要更改核心代码，节省代码量，提高灵活性。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。