本申请涉及互联网技术领域，尤其涉及一种用于用于资源分配的和用于交通工具调度的方法及其装置。
背景技术：
目前，在诸多场景中，均存在将各类资源进行调度或分配的需求。例如，一台设备内部的资源调度(例如为不同的应用程序分配处理线程、内存调度资源等)，或多台设备之间的任务调度(例如为不同的设备分配带宽资源)，或交通工具资源的调度等。在涉及资源调度的各类场景中，“资源”往往都是有限的，而资源使用方对资源的需求量往往超过资源提供方的资源总量，因此，如何对有限的资源进行合理的调度、使得资源利用率能够尽量提高，一直是研究人员所关注的重要方向。
在相关技术中，某些调度任务是针对一个服务提供端来进行的，而为了提升资源利用率，参与该调度任务的服务请求端可以包括至少两个。在上述服务提供端为至少两个特定的服务请求端提供服务的过程中，往往会出现资源分配不合理的问题。举例而言，若针对服务提供端A的调度任务是由服务请求端B、C共同参与的，其中，假设服务提供端A为服务请求端B开始分配服务资源的时刻早于为服务请求端C开始分配服务资源的时刻，然而，在终止分配服务资源时，服务提供端A对服务请求端B终止分配服务资源的时刻却晚于对服务请求端C终止分配服务资源的时刻，这便会造成服务资源分配不合理的问题，造成服务请求端B的用户体验不佳。
技术实现要素：
为克服相关技术中存在的问题，本申请实施例提供一种用于资源分配的和用于交通工具调度的方法及其装置。
根据本申请实施例的第一方面，提供一种用于资源分配的方法，包括：
确定参与针对服务提供端的交通工具调度事件的至少两个请求端；
当监测到所述服务提供端接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
当所述目标请求端被所述服务提供端送达的第二顺序值大于所述目标请求端被所述服务提供端接到的第一顺序值时，将虚拟资源分配给所述目标请求端。
根据本申请实施例的第二方面，提供一种用于交通工具调度的方法，包括：
确定参与针对目标交通工具的调度事件的至少两个请求端；
当监测到所述目标交通工具接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
当所述第二顺序值大于所述第一顺序值时，向所述目标请求端支付预定数额的费用。
根据本申请实施例的第三方面，提供一种用于资源分配的装置，包括：
第一确定单元，用于确定参与针对服务提供端的调度事件的至少两个请求端；
第二确定单元，用于当监测到所述服务提供端接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
第三确定单元，用于当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
资源分配单元，用于当所述第二顺序值大于所述第一顺序值时，将虚拟资源分配给所述目标请求端。
根据本申请实施例的第四方面，提供一种用于交通工具调度的装置，包括：
第一确定单元，用于确定参与针对目标交通工具的调度事件的至少两个请求端；
第二确定单元，用于当监测到所述目标交通工具接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
第三确定单元，用于当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
费用支付单元，用于当所述第二顺序值大于所述第一顺序值时，向所述目标请求端支付预定数额的费用。
本申请的实施例提供的技术方案可以包括以下有益效果：
本申请实施例在确定参与同一交通工具调度事件的至少两个请求端之后，通过监测服务提供端接到每一请求端的时刻以及送达每一请求端的时刻，分别确定出与目标请求端被所述服务提供端接到的次序对应的第一顺序值以及与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值，并且，当所述第二顺序值大于所述第一顺序值，确定当前交通工具调度事件的服务资源调度过程出现资源分配不合理的情况，通过将一定的虚拟资源分配给所述目标请求端的方式来弥补这一资源分配不合理的情况，提升用户的使用体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
图1是根据一示例性实施例示出的一种用于资源分配的方法的流程图；
图2是根据一示例性实施例示出的一种交通工具调度事件的场景图；
图3A是根据一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程；
图3B是根据另一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程；
图4是根据一示例性实施例示出的另一种用于资源分配的方法的流程图；
图5A是根据一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程；
图5B是根据另一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程；
图6是根据一示例性实施例示出的一种电子设备的结构示意图；
图7是根据一示例性实施例示出的一种用于资源分配的装置的框图；
图8是根据一示例性实施例示出的另一种用于资源分配的装置的框图。
具体实施方式
本申请实施例提供的用于资源分配的方法主要可以应用在对交通工具进行调度的应用场景中。当前，通过对公共交通工具的调度可方便人们的出行，而交通工具作为一种有限的服务“资源”，为提升这一“资源”的利用率，出现了由至少两个请求方共同参与对同一交通工具调度事件的场景。
在至少两个请求方共同参与对同一交通工具调度事件的场景中，司机作为服务提供方，乘客作为请求方，司机需要按照每一乘客的始发地和目的地，逐一在每一始发地将每一乘客接上车，并向每一乘客依次送达到指定的目的地，在此过程中，难免会造成资源调度过程不合理的情况，造成部分乘客的不满意，影响用户体验。本申请实施例正是为解决这一问题而提出。需说明的是，一般而言，上述场景可以由至少两个参与打车事件的乘客进行拼单来实现。其中，定义“拼单”为将多笔订单合并为一个订单的过程，在拼单之后，参与拼单事件的“乘客”可称为“拼友”，每一“拼友”使用的电子设备可被定义为“请求端”，“司机”使用的电子设备可被定义为“服务提供端”。
图1是根据一示例性实施例示出的用于资源分配的方法的流程图，图2是根据一示例性实施例示出的用于资源分配的方法的流程图，图3A是根据一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程，图3B是根据另一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程。首先参照图1所示，上述用于资源分配的方法可应用于服务器端，包括如下步骤101～104，其中：
在步骤101中，确定参与针对服务提供端的交通工具调度事件的至少两个请求端。
结合图2进行说明，在交通工具调度事件中，包括：服务端20，与服务端20通过网络进行互联的服务提供端10，以及与所述服务端20通过网络进行互联的若干请求端20a、20b、20c。其中，服务提供端10可以是服务提供方(司机)使用的电子设备(如：手机、电脑、PDA等)，请求端20a、20b、20c可以是请求方(拼友)使用的电子设备(如：手机、电脑、PDA等)。
在实际应用中，确定参与针对服务提供端的交通工具调度事件的至少两个请求端的过程大致如下：
拼友a、b、c分别在各自的请求端上，输入始发地以及需要前往的目的地，并选择与其他乘客拼单的方式来实现。此后，服务端20可以接收到上述三个拼友a、b、c的请求端20a、20b、20c分别发送的订单请求。随后，服务端20可以根据预设拼单规则，判断上述请求端20a、20b、20c各自发送的订单请求是否满足以上预设拼单规则(如：请求端20a、20b、20c各自的行程路线存在一定的重合或顺路)，若满足，则将这三个订单请求合并为一个订单请求，并按照一定的推送规则推送给一个或多个服务提供端，若某一服务提供端10点击“同意接单”，则确定由上述请求端20a、20b、20c共同参与针对服务提供端10的交通工具调度事件。其中，所述推送规则可以包括：服务提供端在线，或服务提供端愿意接受拼单，或服务提供端当前所处位置处于指定区域内，等等。由于确定拼友的过程属于本领域技术人员所熟知的技术，此处不再予以细述。
在步骤102中，当监测到所述服务提供端接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；其中，所述第一顺序值是根据次序的先后进行从小到大的赋值并采用一定的规则进行编码得到的。
承上所述，在确定由上述请求端20a、20b、20c共同参与针对服务提供端10的交通工具调度事件之后，与服务提供端10对应的交通工具需要逐一驶往各个请求端20a、20b、20c的始发地，以将各个请求端20a、20b、20c接上车。在此过程中，服务器端20可以监测到每一请求端被所述服务提供端接到的时刻。在一种实施例中，服务提供端在接到某一请求端之后，可以由服务提供方(司机)通过服务提供端向服务器端发送通知消息，以告知服务器端接到该请求端的时刻并记录。另一种实施例中，服务器端可以实时分别获取服务提供端和每一请求端的位置，并在某一请求端和服务提供端的位置重合时，确定该请求端被所述服务提供端接到，从而对接到的时刻进行记录。
对于所述两个请求端中的目标请求端，当服务器端监测到该目标请求端被所述服务提供端接到时，则可以结合在此之前被接到的请求端，确定该目标请求端被所述服务提供端接到的顺序值。例如，对于目标请求端20b，在该目标请求端20b被接到时，发现在此之前被接到的请求端包括：请求端20a、20c，则可根据该目标请求端20b被服务提供端接到的次序，进行相应的赋值为“3”，此后，可以按照相应的编码规则得到第一顺序值。其中，举例而言，所述编码规则例如是二进制编码，则得到的与目标请求端20b对应的第一顺序值可以是：“0011”，并记录第一顺序值：“0011”。
在步骤103中，当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值。
与上述步骤102的过程类似，服务端可以采取相同的方式来监测到所述服务提供端将每一请求端送达到各自指定的目的地的时刻，并相应确定所述至少两个请求端中的一目标请求端被所述服务提供端送达的次序，并根据次序的先后进行从小到大的赋值，再采用一定的编码规则进行编码得到所述第二顺序值。如，对于目标请求端20b，在该目标请求端20b被送达时，发现在此之前被接送达的请求端是：请求端20a，则可根据目标请求端20b被服务提供端送达的次序，进行相应的赋值为“2”，此后，可以按照相应的编码规则得到第二顺序值。其中，举例而言，所述编码规则例如是二进制编码，则得到的与目标请求端20b对应的第二顺序值可以是：“0010”，并记录第二顺序值：“0010”。需要说明的是，以上第一顺序值和第二顺序值需要采取相同的编码规则进行编码，此外，本申请并不对编码规则、赋值方式进行限制。
在步骤104中，当所述第二顺序值大于所述第一顺序值时，将虚拟资源分配给所述目标请求端。
本申请实施例中，在目标请求端被送达到其设定的目的地之后，需要根据相应的规则计算行程费用。例如：根据拼友的数量及每一拼友的行程距离来分别确定每一拼友的行程费用。与此同时，还需要根据预先记录的该目标请求端对应的第一顺序值以及第二顺序值，确定针对该服务提供端进行的交通工具调度事件是否存在资源调度不合理的情况。本实施例中，倘若与所述目标请求端对应的第二顺序值大于与所述目标请求端对应的第一顺序值，则表明以上交通工具调度事件存在资源调度不合理的情况，可以通过将一定的虚拟资源分配给所述目标请求端，来弥补这一资源分配不合理的情况，提升用户的使用体验。
以下将结合图3A和图3B来示例性说明以上过程。
如图3A所示，在一种示例性场景中，确定拼友a、b、c共同参与统一交通工具调度事件。其中，拼友a的始发地是地点A，目的地是地点F；拼友b的始发地是地点B，目的地是地点E；拼友c的始发地是地点C，目的地是地点D。其中，假设被调度的交通工具的行驶路线为：A→B→C→D→E→F，其中，该交通工具先在地点A接到拼友a，再在地点B接到拼友b，最后在地点C接到拼友c，则可确定该交通工具接到拼友a的顺序值是1，接到拼友b的顺序值是2，接到拼友c的顺序值是3。相应地，该交通工具先在地点D送达拼友c，再在地点E送达拼友b，最后在地点F送达拼友a，可确定该交通工具送达拼友a的顺序值是3，送达拼友b的顺序值是2，送达拼友c的顺序值是1。基于以上过程，在监测到交通工具在地点D将拼友c送达之后，发现拼友c被送达的顺序值：1小于该拼友c被接到的顺序值：3，此情况不属于“资源调度不合理”的情况，不予以分配虚拟资源。在监测到交通工具在地点E将拼友b送达之后，发现拼友b被送达的顺序值：2等于该拼友b被接到的顺序值：2，此情况同样不属于“资源调度不合理”的情况，不予以分配虚拟资源。在监测到交通工具在地点F将拼友a送达之后，发现拼友a被送达的顺序值：3大于该拼友a被接到的顺序值：1，此情况属于“资源调度不合理”的情况，需向拼友a分配一定的虚拟资源，以作为补偿。需要说明的是，所分配的虚拟资源可包括：资金，抵用券，折扣券等。在一实施例中，在向目标请求端分配上述虚拟资源时，可以向所述目标请求端推送与所述虚拟资源对应的提示内容，该提供内容用于指示该虚拟资源被分配的原因，如：“您好，因您的下车顺序晚于上车顺序，特发红包以表歉意，红包金额为：5元”，以进一步提升用户的使用体验。
如图3B所示，在另一种示例性场景中，假设被交通工具的行驶路线变成：A→B→C→F→E→D，则交通工具接到各拼友的顺序是：拼友a早于拼友b，拼友b早于拼友c，而送达各拼友的顺序是：拼友a早于拼友b，拼友b早于拼友c，此时，便不会出现以上“资源调度不合理”的情况。
图4是根据一示例性实施例示出的另一种用于资源分配的方法的流程图，图5A是根据一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程，图5B是根据另一示例性实施例示出的服务提供方为至少两个请求方提供服务的过程。参照图4所示，上述用于资源分配的方法可应用于服务器端，在上述图1所示的实施例的基础之上，为进一步提高资源分配的合理性，所述步骤104可包括：
步骤1041，当所述第二顺序值大于所述第一顺序值时，判断所述服务提供端为所述目标请求端提供服务的实际时长是否大于预估时长。其中，所述预估时长是根据所述目标请求端的始发地及目的地确定的。
在一实施例中，确定拼友的行程所需耗用的预估时长的过程可具体包括：
获取所述目标请求端的始发地和目的地之间的交通拥堵程度。
根据所述始发地和目的地之间的行程距离、及所述交通拥堵程度，确定所述预估时长。
例如，对于拼友a，预估时长是指该拼友a单独打车时所需耗用的预估时长。拼友a的始发地和目的地之间包括多个路线，若根据实时路况等因素选择最优的行驶路线，确定最优行驶路线的行程距离是10km。结合不同的交通拥堵程度(如：1级、2级、3级)，可以确定10km在不同的交通拥堵程度下所需耗用的预估时长。其中，交通拥堵程度可以通过路况监测来获得，也可根据历史大数据分析获得每天的不同时间段的交通拥堵程度。当然，预估时长也可以是人为根据始发地和目的地，确定出的一个经验值。
步骤1042，当所述实际时长大于所述预估时长时，将虚拟资源分配给所述目标请求端。
以下将结合图5A和图5B来示例性说明以上过程。
如图5A所示，在一种示例性场景中，确定拼友a、b、c共同参与统一交通工具调度事件。其中，拼友a的始发地是地点A，目的地是地点F；拼友b的始发地是地点B，目的地是地点E；拼友c的始发地是地点C，目的地是地点D。其中，假设被调度的交通工具的行驶路线为：A→B→C→D→E→F。其中，对于拼友a而言，当拼友a被送达之后，发现拼友a被服务提供端接到的顺序值：1小于该拼友a被服务提供端送达的顺序值：3。然而，根据该拼友a的始发地A和目的地F，可以确定拼友a单独参与交通工具调度事件时，其最优的行程路线可以是路线51，并可相应地确定出拼友a单独参与交通工具调度事件时所需耗用的预估时长。从图5A可以看出，拼友a单独参与交通工具调度事件时的路线51，相较于与其他拼友共同参与一交通工具调度事件时的路线：A→B→C→D→E→F，要短一些，即实际时长超过预估时长，在此情况下，认定该拼友a的实际行程属于“资源分配不合理”的情况，需给予一定的虚拟资源补偿。
如图5B所示，在另一种示例性场景中，若确定拼友a单独参与交通工具调度事件时的行驶路线是路线52，从图5B可以看出，拼友a单独参与交通工具调度事件时的路线52，相较于与其他拼友共同参与一交通工具调度事件时的路线：A→B→C→D→E→F，其路程距离相差并不大，即实际时长并没有超过预估时长，在此情况下，认定该拼友a的实际行程不属于“资源分配不合理”的情况。通过设定“实际时长与预估时长的比较”的判断逻辑，可以使得判定资源分配不合理情况的过程更加准确，在提升用户使用体验的同时，还可以节约交通工具调度过程的运营成本。
为进一步使得虚拟资源分配过程更加合理，还可以确定待分配的虚拟资源的数额。在本申请一实施例中，确定待分配的虚拟资源的数额的步骤包括但不限于以上方式之一：
①根据所述第一顺序值和所述第二顺序值之间的差值，确定待分配的虚拟资源的数额。
例如，关于“顺序值”的差值和待分配的虚拟资源的数额正相关，则该差值越大，可相应地增加待分配的虚拟资源的数额。
②根据所述服务提供端为所述目标请求端提供服务的实际时长和预估时长之间的差值，确定待分配的虚拟资源的数额。
例如，关于时长的差值和待分配的虚拟资源的数额正相关，则该差值越大，可相应地增加待分配的虚拟资源的数额。
综上，利用本申请实施例提供的上述方法，本申请实施例在确定参与同一交通工具调度事件的至少两个请求端之后，通过监测服务提供端接到每一请求端的时刻以及送达每一请求端的时刻，分别确定出与目标请求端被所述服务提供端接到的次序对应的第一顺序值以及与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值，并且，当所述第二顺序值大于所述第一顺序值，确定当前交通工具调度事件的服务资源调度过程出现资源分配不合理的情况，通过将一定的虚拟资源分配给所述目标请求端的方式来弥补这一资源分配不合理的情况，提升用户的使用体验。
在本申请一实施例中，还提供一种用于交通工具调度的方法，包括如下步骤：
确定参与针对目标交通工具的调度事件的至少两个请求端；
当监测到所述目标交通工具接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
当所述第二顺序值大于所述第一顺序值时，向所述目标请求端支付预定数额的费用。其中，所述费用的形式可包括但不限于：红包、折扣券、现金抵用券等。
通过上述用于交通工具调度的方法，在拼车的过程，当某个拼友的被送达顺序(第二顺序值)晚于该拼友被接驾顺序(第一顺序值)时，可以通过向该拼友一定的补偿费用的方式，来缓和给该用户造成的不公平服务，以及该拼友带来不良的使用体验，减小客户投诉率。
图6是根据一示例性实施例示出的一种电子设备的示意图。请参考图6，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成用于资源分配的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图7，在一种软件实施方式中，该用于资源分配的装置可以包括第一确定单元201、第二确定单元202、第三确定单元203及资源分配单元204。其中：
第一确定单元201，用于确定参与针对服务提供端的调度事件的至少两个请求端；
第二确定单元202，用于用于当监测到所述服务提供端接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
第三确定单元203，用于当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
资源分配单元204，用于当所述第二顺序值大于所述第一顺序值时，将虚拟资源分配给所述目标请求端。
请参考图8，在另一种软件实施方式中，基于以上图7所示的实施例，所述资源分配单元204可具体包括：
判断子单元2041，用于当所述第二顺序值大于所述第一顺序值时，，判断所述服务提供端为所述目标请求端提供服务的实际时长是否大于预估时长；其中所述预估时长是根据所述目标请求端的始发地及目的地确定的。
分配子单元2042，用于在所述实际时长大于所述预估时长时，将虚拟资源分配给所述目标请求端。
在本申请一种实施例中，所述装置还可以包括：
获取单元，用于获取所述目标请求端的始发地和目的地之间的交通拥堵程度；
第四确定单元，用于根据所述始发地和目的地之间的行程距离、及所述交通拥堵程度，确定所述预估时长。
在本申请一种实施例中，所述装置还可以包括：
数额确定单元，用于根据所述第一顺序值和所述第二顺序值之间的差值，确定待分配的虚拟资源的数额；或，
用于根据所述服务提供端为所述目标请求端提供服务的实际时长和预估时长之间的差值，确定待分配的虚拟资源的数额。
在本申请一种实施例中，所述资源分配单元204可以用于：
将虚拟资源分配给所述目标请求端，并向所述目标请求端推送与所述虚拟资源对应的提示内容。
在一种软件实施方式中，还提供一种用于交通工具调度的装置，包括：
第一确定单元，用于确定参与针对目标交通工具的调度事件的至少两个请求端；
第二确定单元，用于当监测到所述目标交通工具接到所述两个请求端中的目标请求端时，确定与所述目标请求端被所述服务提供端接到的次序对应的第一顺序值；
第三确定单元，用于当监测到所述服务提供端送达所述目标请求端时，确定与所述目标请求端被所述服务提供端送达的次序对应的第二顺序值；其中所述第一顺序值和所述第二顺序值是根据次序的先后进行从小到大的赋值并采用相同规则进行编码得到的；
费用支付单元，用于当所述第二顺序值大于所述第一顺序值时，向所述目标请求端支付预定数额的费用。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。