CN108805660A - 订单处理方法、装置及服务器 - Google Patents

Abstract

本申请提供一种订单处理方法、装置及服务器，该方法包括：接收客户端发送的打车请求消息，生成原始订单并确定接单车辆；若所述原始订单在确定出接单车辆后被取消，通过判责模型确定订单取消责任方；如果确定所述订单取消责任方为接单车辆的司机，则基于所述原始订单生成重发订单；将所述重发订单推送到除所述接单车辆之外的其他满足接单条件的车辆。本申请的技术方案本申请在原始订单被取消时，如果确定订单取消责任方为接单车辆的司机，可将重发订单推送给责任方之外的车辆，进而提高乘客线上成功约车的效率，可以避免订单无效重发导致的资源浪费。

Description

订单处理方法、装置及服务器

技术领域

本申请涉及应用技术领域，尤其涉及一种订单处理方法、装置及服务器。

背景技术

用户可通过各个打车平台进行线上约车服务，进而实现用户无需路边招手即可约车，然而乘客在打车平台上进行约车的订单可能长时间不能被接单，导致乘客不能上车，降低了乘客使用打车平台约车的体验。

现有技术中，可以在乘客的订单长时间没有被接单时，系统再次重新发单，然而即使再次重新发送订单，被接单的概率仍然不会高。因此，现有技术存在乘客不能及时乘到车，以及无效的重发订单导致的资源浪费问题。

发明内容

有鉴于此，本申请提供一种新的技术方案，在保证乘客及时乘上车的同时，避免无效重发订单导致的资源浪费。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种订单处理方法，应用在服务器包括：

接收客户端发送的打车请求消息，生成原始订单并确定接单车辆；

若所述原始订单在确定出接单车辆后被取消，通过判责模型确定订单取消责任方；

如果确定所述订单取消责任方为接单车辆的司机，则基于所述原始订单生成重发订单；

将所述重发订单推送到除所述接单车辆之外的其他满足接单条件的车辆。

在一实施例中，所述通过判责模型确定订单取消责任方，包括：

基于乘客和所述接单车辆的司机之间的通话记录，和/或，乘客和所述接单车辆的司机之间的端内消息记录，和/或，所述接单车辆在接单后的行驶路线数据，和/或，所述乘客在被接单后的移动数据，确定所述订单取消责任方。

根据本申请的第二方面，提出了一种订单处理装置，应用在服务器上，包括：

第一生成模块，用于接收客户端发送的打车请求消息，生成原始订单并确定接单车辆；

判责模块，用于若所述第一生成模块生成的所述原始订单在确定出接单车辆后，通过判责模型确定订单取消责任方；

第二生成模块，用于如果确定所述判责模块确定所述订单取消责任方为接单车辆的司机，则基于所述原始订单生成重发订单；

推送模块，用于将所述第二生成模块生成的所述重发订单推送到除所述接单车辆之外的其他满足接单条件的车辆。

根据本申请的第三方面，提出了一种服务器，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所描述的订单处理方法。

根据本申请的第四方面，提出了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所描述的订单处理方法。

由以上技术方案可见，本申请中可以在原始订单被接单后又被取消时，确定出订单取消的责任方，并在确定订单责任方为接单车辆的司机时，生成重发订单，并将重发订单推送给除接单车辆之外的车辆。由此，本申请在原始订单被取消时，在确定订单取消责任方为接单车辆的司机时，可将重发订单推送给责任方之外的车辆，可以提高乘客线上成功约车的效率，而且可以避免订单无效重发导致的资源浪费。

附图说明

图1示出了根据本发明的一示例性实施例的订单处理方法的流程示意图；

图2示出了根据本发明的又一示例性实施例的订单处理方法的流程示意图；

图3示出了根据本发明的又一示例性实施例的订单处理方法的流程示意图；

图4示出了根据本发明的一示例性实施例的订单处理装置框图；

图5示出了根据本发明的又一示例性实施例的订单处理装置框图；

图6示出了根据本发明的一示例性实施例的服务器的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

为对本申请进行进一步说明，提供下列实施例：

图1示出了根据本发明的一示例性实施例的订单处理方法的流程示意图；订单处理方法可以应用于服务器上，如图1所示，本实施例中订单处理方法可包括如下步骤101～104：

步骤101，接收客户端发送的打车请求消息，生成原始订单并确定接单车辆。

在一实施例中，服务器在接收到打车请求消息时，即可根据打车请求消息中携带的乘客信息(如用户乘客联系方式、乘客身体特征等)、设备信息、起始位置、终点位置、小费金额，以及发单类型和计费规则，生成原始订单。

在一实施例中，服务器在生成原始订单之后，可向满足接单条件的车辆推送原始订单，并将抢单成功的车辆确定为接单车辆。

在一实施例中，服务器生成原始订单后，可基于打车的起始位置，确定出满足接单条件的车辆，例如，将起始位置周边预设范围内的车载终端确定为满足接单条件的车辆并发送原始订单。例如：如果乘客的移动设备的当前位置为首创澜茵山，则可向周边1公里范围内的所有车载终端发送订单信息。

在一实施例中，车载终端可包括车辆上设置的移动设备和司机的手持移动设备，可以理解为司机用于接单的设备。

在又一实施例中，服务器还可根据订单的起始位置和终点位置，确定出满足接单条件的车辆，例如，如果订单的起始位置和目的位置之间的距离非常远，超过了某些车辆，例如电动出租车、老年司机所驾驶的出租车的行驶范围，则可将起始位置周边预设范围内的除电动出租车、老年司机所驾驶的出租车之外的车辆确定为满足接单条件的车辆并发送原始订单。

步骤102，若原始订单在确定出接单车辆后被取消，通过判责模型确定订单取消责任方。

在一实施例中，确定出接单车辆是指已经有车辆抢单成功，而确定出接单车辆后被取消的操作则可以由乘客触发，或者也可以由接单车辆的司机触发。

在一实施例中，在原始订单被接单车辆接单后，如果接单车辆的司机或者乘客出现了突发事件，则可执行订单取消操作。

在一实施例中，服务器在原始订单被取消时，可进一步确定客户端是否支持订单改派业务。在一实施例中，订单改派业务可以理解为在接单车辆已经接单，但是乘客没有上车之前，可以通过生成新的订单，由其他司机接单的业务。

在一实施例中，判责模型为一个用于确定订单取消责任方的一个模型，判责模型可以通过以下任意一项或者多项信息确定订单取消责任方：

乘客和接单车辆的司机之间的通话记录，乘客和接单车辆的司机之间的端内消息记录，接单车辆在接单后的行驶路线数据，乘客在被接单后的移动数据。

在一实施例中，通过判责模型确定订单取消责任方的具体实现方式可参见图2所示实施，这里先不详述。

步骤103，如果确定订单取消责任方为接单车辆的司机，则基于原始订单生成重发订单。

在一实施例中，基于原始订单生成重发订单可以理解为生成一个与原始订单的基本信息一致的重发订单；其中，原始订单的信息包括以下一种或者多种信息：

乘客信息、设备信息、起点位置、终点位置、计费规则、发单类型、小费金额。

其中，订单的乘客信息可以为乘客的相关信息，如乘客的联系方式、乘客的身体特征、衣着描述；订单的设备信息可以为乘客所持有的客户端设备的标识信息和客户端信息，如设备为型号为###的智能手机；订单的起点位置和终点位置用于指示乘客的上车位置和下车位置；订单的计费规则可以理解为打车的计费方式，例如，计费方式为按照里程计费，或者按照时间计费，或者计费为一个定额等；订单的发单类型可以理解为乘客约车的形式，例如，发单类型为快车，或出租车，或顺风车，或拼车等；订单的小费金额可以为乘客在约车时主动加的小费或者感谢费的金额，例如，乘客在发起顺风车的订单时，主动提出给予10元钱的感谢费。

步骤104，将重发订单推送到除接单车辆之外的其他满足接单条件的车辆。

在一实施例中，如果通过判则模型确定原始订单的订单取消责任方为接单车辆的司机，那么为了避免再次被原始订单的接单车辆(也即，原始订单的订单取消责任方的车辆)再次接单进而再次发生订单取消的事件，服务器可将重发订单推送到除原始订单的接单车辆之外的其他满足接单条件的车辆。例如，服务器生成原始订单后，确定出的满足接单条件的车辆为车辆1、车辆2、车辆3，最后由车辆3抢单，成为接单车辆，并发生订单取消问题，则对于重发订单，如果再次确定出的满足接单条件的车辆为车辆1、车辆2、车辆3、车辆4，则可向车辆1、车辆2、车辆4推送重发订单，而不再向车辆3推送订单。

在一实施例中，生成重发订单后还可向客户端发送已生成重发订单的指示信息，由此客户端可以显示等待接单界面，以指示乘客正在重新为乘客寻找司机。

本实施例中，可以在原始订单被接单后又被取消时，确定出订单取消责任方，并在确定订单责任方为接单车辆的司机时，生成与原始订单的基本信息一致的重发订单，并将重发订单推送给除接单车辆之外的车辆。由此，本申请在原始订单被取消时，在确定订单取消责任方为接单车辆的司机时，通过将重发订单推送给责任方之外的车辆，可以避免乘客再次发生订单被取消的事件，提高乘客线上成功约车的效率，而且通过拒绝将重发订单发送给原是订单的接单车辆，可以避免订单无效重发导致的资源浪费。

图2示出了根据本发明的又一示例性实施例的订单处理方法的流程示意图；本实施例在上述实施例的基础上，以如何确定订单取消责任方并且在订单取消责任方为接单车辆的司机时进行订单重发为例进行示例性说明，如图2所示，包括如下步骤：

步骤201，接收客户端发送的打车请求消息，生成原始订单并确定接单车辆。

在一实施例中，服务器在接收到打车请求消息时，即可根据打车请求消息中携带的乘客信息(如用户乘客联系方式、乘客身体特征等)、设备信息、起始位置、终点位置、小费金额，以及发单类型和计费规则，生成原始订单。

在一实施例中，确定接单车辆的实现方式可参见图1所示实施例的步骤101的描述，这里不再详述。

步骤202，若原始订单在确定出接单车辆后被取消，基于乘客和接单车辆的司机之间的通话记录，和/或，乘客和接单车辆的司机之间的端内消息记录，和/或，接单车辆在接单后的行驶路线数据，和/或，乘客在被接单后的移动数据，确定订单取消责任方。

在一实施例中，通常在接单车辆接单后，会向乘客拨打电话，以便进一步确认乘客的上车地点，或者向乘客描述自己的车型、车牌号，或者向乘客说明自己大概还有多长时间到达乘客的上车地点等；乘客也可向接单车辆的司机拨打电话以确认司机可以多久到、车辆的车型、车牌号，或者向接单车辆的司机描述自己具体所在位置等。由此，服务器可基于乘客和司机之间的通话记录确定订单取消责任方，例如，如果电话是接通的，则服务器可获取通话内容关键词，如果乘客和司机的通话内容关键词指示“司机还要十分钟才能到达乘客的上车地点”，导致乘客取消了订单，则可在确定订单取消责任方时判定司机是责任方，这是因为司机要到达乘客上车地点的时间过长才导致了乘客取消订单；如果通话是未接通状态，则可获取是哪一方的电话存在关机、空号、停机、拒接、无应答等状态而导致通话为未接通状态，由此可在确定订单取消责任方时将其作为一个判决因素，例如，如果乘客电话是关机状态，则可在确定订单取消责任方时判定乘客是责任方。

在一实施例中，通常在接单车辆接单后，接单车辆的司机可与乘客在应用端内进行文字消息交互，如，司机可向乘客发送“定位准么，我会按照导航来接您”消息或者“我已经到约定地点，请问您是否已到达”，而乘客迟迟未对消息进行响应，导致接单车辆取消了订单，则可在判决订单取消责任方时判定乘客是责任方。

在一实施例中，通常接单车辆接单后，会向乘客所在位置行驶，如果接单车辆在接单后的行驶路线数据指示车辆在原地不动，或者反向行使，或者已经到上车时间时，车辆依然距离上车地点很远，导致乘客取消订单，则可在判决订单取消责任方时判定接单车辆的司机是责任方。

在一实施例中，通常接单车辆接单后，乘客会向上车位置行走，如果到达上车时间时，乘客依然距离上车地点很远，导致司机取消订单，则可在判决订单取消责任方时判定乘客是责任方。

在一实施例中，可以分别依据上述判决因素确定订单取消责任方，也可综合考虑上述判决因素中的多项判决因素确定订单取消责任方，例如，接单车辆的司机向乘客发送“定位准么，我会按照导航来接您”消息或者“我已经到约定地点，请问您是否已到达”，而乘客迟迟未对消息进行响应，并且通话记录指示乘客的电话为关机状态，由此司机执行了取消订单操作，则可判定订单取消责任方为乘客。

步骤203，如果确定订单取消责任方为接单车辆的司机，则基于原始订单生成重发订单，执行步骤204和步骤205。

步骤204，将重发订单推送到除接单车辆之外的其他满足接单条件的车辆，流程结束。

在一实施例中，步骤203和步骤204的描述可参见图1所示实施例的步骤103和步骤104的描述，这里不再详述。

步骤205，向客户端发送已生成重发订单的指示信息，用于客户端显示等待接单界面。

在一实施例中，服务器生成重发订单后向客户端发送已生成重发订单的指示信息，由此客户端可以显示等待接单界面，以指示乘客已经重新为乘客寻找司机。

本实施例中，公开了服务器判定订单取消责任方的具体方式，服务器可综合考虑多个判决因素确定订单取消责任方，由此可以准确确定是否需要生成重发订单，进而避免生成无效的重发订单，而且在确定出订单取消责任方为接单车辆的司机后，通过将重发订单推送给责任方之外的车辆，来提高乘客线上成功约车的效率。

图3示出了根据本发明的又一示例性实施例的订单处理方法的流程示意图；本实施例在上述实施例的基础上，以如何对订单进行处理为例进行示例性说明，如图3所示，包括如下步骤：

步骤301，接收客户端发送的打车请求消息，执行步骤302和步骤303。

步骤302，生成原始订单并确定接单车辆，执行步骤304。

步骤303，基于打车请求消息中携带的客户端信息，确定客户端是否支持订单改派业务，执行步骤304。

在一实施例中，本实施例并不对步骤302和步骤303的执行顺序进行限定。在一实施例中，可以同时执行步骤302和步骤303；在一实施例中，也可以先执行步骤302，再执行步骤303；在一实施例中，还可以先执行步骤303，再执行步骤302。

在一实施例中，打车请求消息中通常可携带客户端的客户端信息，例如，客户端版本信息，服务器可通过客户端信息确定出客户端是否支持订单改派业务。

步骤304，若原始订单在确定出接单车辆后被取消并且客户端支持订单改派业务，通过判责模型确定订单取消责任方，在确定订单取消责任方为接单车辆的司机时，执行步骤305，在确定订单取消责任方为使用客户端的乘客时，执行步骤307。

步骤305，如果确定订单取消责任方为接单车辆的司机，则基于原始订单生成重发订单。

在一实施例中，基于原始订单生成重发订单可以理解为生成一个与原始订单的基本信息一致的重发订单；其中，原始订单的信息包括以下一种或者多种信息：乘客信息、设备信息、起点位置、终点位置、计费规则、发单类型、小费金额。

步骤306，将重发订单推送到除接单车辆之外的其他满足接单条件的车辆。

在一实施例中，步骤304-步骤306的描述可参见图1所示实施例的步骤102-步骤104的描述，这里不再详述。

在一实施例中，在执行完步骤306之后，还可对生成重发订单的次数进行记录；并且在再次发生订单取消操作时，先确定之前已生成的重发订单的次数是否超过设定数值(例如，设定数值为3)，并在已生成的重发订单的次数超过设定数值时，向客户端发送订单取消指示消息，在已生成的重发订单的次数没有超过设定数值时，再次确定订单取消责任方并且在订单取消责任方为司机时，再次生成重发订单。

步骤307，如果确定订单取消责任方为使用客户端的乘客，则向打车客户发送订单取消指示消息。

本实施例中，公开了服务器在订单确定出接单车辆后又被取消时，判定订单取消责任方，以及在确定出订单取消责任方为接单车辆的司机后生成重发订单的实现方式；此外，还公开了对生成重发订单的次数进行记录，并且在重发订单的次数超过设定数值时，可直接取消订单并指示给客户端，由此可避免乘客长时间等待。

与前述订单处理方法的实施例相对应，本申请还提供了订单处理装置的实施例。

图4示出了根据本发明的一示例性实施例的订单处理装置框图，如图4所示，订单处理装置包括：

第一生成模块41，用于接收客户端发送的打车请求消息，生成原始订单并确定接单车辆；

判责模块42，用于若第一生成模块41生成的原始订单在确定出接单车辆后被取消，通过判责模型确定订单取消责任方；

第二生成模块43，用于如果判责模块42确定订单取消责任方为接单车辆的司机，则基于原始订单生成重发订单；

推送模块44，用于将第二生成模块43生成的重发订单推送到除接单车辆之外的其他满足接单条件的车辆。

图5示出了根据本发明的又一示例性实施例的订单处理装置框图，如图5所示，在上述图4所示实施例的基础上，

在一实施例中，判责模块42具体用于：

基于乘客和接单车辆的司机之间的通话记录，和/或，乘客和接单车辆的司机之间的端内消息记录，和/或，接单车辆在接单后的行驶路线数据，和/或，乘客在被接单后的移动数据，确定订单取消责任方。

在一实施例中，第二生成模块43具体用于：

生成与所述原始订单的基本信息一致的重发订单；

其中，所述原始订单的基本信息包括以下一种或者多种：乘客信息、设备信息、起点位置、终点位置、计费规则、发单类型、小费金额。

在一实施例中，装置还包括：

第一发送模块45，用于向客户端发送已生成重发订单的指示信息，用于客户端显示等待接单界面。

在一实施例中，装置还包括：

第二发送模块46，用于在订单取消责任方为使用客户端的乘客时，向客户端发送订单取消指示消息。

在一实施例中，针对原始订单，所生成的重发订单不超过设定数值。

第二发送模块46，还用于若针对所述原始订单生成的重发订单的个数超过所述设定数值，则向所述客户端发送订单取消指示消息。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

对应于上述的订单处理方法，本申请还提出了图6所示的根据本发明的一示例性实施例的服务器的示意结构图。请参考图6，在硬件层面，该服务器包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成订单处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

在示例性实施例中，还提供了一种计算机可读存储介质，该存储介质存储有计算机程序，该计算机程序用于执行上述订单处理方法，其中，计算机可读存储介质可以是只读存储器(ROM)、随机存取存储器(RAM)、光盘只读存储器(CD-ROM)、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种订单处理方法，其特征在于，应用在服务器上，所述方法包括：

接收客户端发送的打车请求消息，生成原始订单并确定接单车辆；

若所述原始订单在确定出接单车辆后被取消，通过判责模型确定订单取消责任方；

如果确定所述订单取消责任方为接单车辆的司机，则基于所述原始订单生成重发订单；

将所述重发订单推送到除所述接单车辆之外的其他满足接单条件的车辆。

2.根据权利要求1所述的方法，其特征在于，所述通过判责模型确定订单取消责任方，包括：

基于乘客和所述接单车辆的司机之间的通话记录，和/或，乘客和所述接单车辆的司机之间的端内消息记录，和/或，所述接单车辆在接单后的行驶路线数据，和/或，所述乘客在被接单后的移动数据，确定所述订单取消责任方。

3.根据权利要求1所述的方法，其特征在于，所述基于所述原始订单生成重发订单，包括：

生成与所述原始订单的基本信息一致的重发订单；

其中，所述原始订单的基本信息包括以下一种或者多种：乘客信息、设备信息、起点位置、终点位置、计费规则、发单类型、小费金额。

4.根据权利要求1所述的方法，其特征在于，所述基于所述原始订单生成重发订单之后，方法还包括：

向所述客户端发送已生成重发订单的指示信息，用于所述客户端显示等待接单界面。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述订单取消责任方为使用所述客户端的乘客时，向所述客户端发送订单取消指示消息。

6.根据权利要求1所述的方法，其特征在于，针对所述原始订单，所生成的重发订单的次数不超过设定数值。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

若针对所述原始订单生成的重发订单的个数超过所述设定数值，则向所述客户端发送订单取消指示消息。

8.一种订单处理装置，其特征在于，所述装置包括：

第一生成模块，用于接收客户端发送的打车请求消息，生成原始订单并确定接单车辆；

判责模块，用于若所述第一生成模块生成的所述原始订单在确定出接单车辆后，通过判责模型确定订单取消责任方；

第二生成模块，用于如果确定所述判责模块确定所述订单取消责任方为接单车辆的司机，则基于所述原始订单生成重发订单；

推送模块，用于将所述第二生成模块生成的所述重发订单推送到除所述接单车辆之外的其他满足接单条件的车辆。

9.一种服务器，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如上述权利要求1-7任一所述的订单处理方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述权利要求1-7任一所述的订单处理方法的步骤。