CN107767322B - 拼车方法和装置 - Google Patents

Abstract

本发明涉及一种拼车方法，所述方法包括以下步骤：获取多个未配置的乘车请求，每个乘车请求中包含乘车时间和目的地和用户标识；根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度，所述出发地为预先设置的默认出发地；根据所述匹配度对所述未配置的乘车请求进行乘车配置，将所述未配置的乘车请求中的一个或多个合并成一个乘车配置信息；将所述乘车配置信息发送至打车平台；接收打车平台发送的根据所述乘车配置信息配置的发车信息，所述发车信息中包括车辆信息和发车时间；将所述发车信息发送给用户终端。上述拼车方法可提高拼车效率。此外，还对应提供了一种拼车装置。

Description

拼车方法和装置

技术领域

本发明涉及信息处理技术领域，特别是涉及一种拼车方法和装置。

背景技术

随着移动互联网技术的发展，网上叫车或拼车出行变得越来越便利。传统的拼车方法中，用户都是独立地将拼车请求发送到拼车平台上，由拼车平台上的司机来选择是否接单并拼车。而司机通常都是在已经接到了第一位乘客之后，在行驶的过程中来实时查找是否具有合适的拼车乘客。通常情况下，由于乘客的分散性和乘车的随机性，司机往往无法寻找到合适的拼车乘客，从而使得拼车的效率不高。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高拼车效率的拼车方法和装置。

一种拼车方法，所述方法包括以下步骤：

获取多个未配置的乘车请求，每个乘车请求中包含乘车时间、目的地和用户标识；

根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度，所述出发地为预先设置的默认出发地；

根据所述匹配度对所述未配置的乘车请求进行乘车配置，将一个或多个所述未配置的乘车请求合并成一个乘车配置信息，所述乘车配置信息中包含乘车人数、发车时间、出发地、途径地点和被合并的乘车请求中的用户标识；

将所述乘车配置信息发送至打车平台；

接收打车平台发送的根据所述乘车配置信息配置的发车信息，所述发车信息包括车辆信息和发车时间；

将所述发车信息发送给用户终端，所述用户终端为与所述被合并的乘车请求中包含的用户标识对应的用户终端。

在其中一个实施例中，所述方法还包括：

获取每个发车信息对应的乘车费用；

累计未结算的乘车费用，得到第一费用；

当所述第一费用超过结算阈值时，才向所述打车平台进行费用结算，以降低结算频率。

在其中一个实施例中，所述方法还包括：

获取待结算周期内的每个发车信息对应的乘车费用；

累计所述乘车费用，得到第二费用；

向所述打车平台进行费用结算，以降低结算频率。

在其中一个实施例中，所述方法还包括：

接收用户终端发送的乘车信息修改请求；

根据所述乘车信息修改请求修改所述用户终端对应的乘车请求；

检测所述用户终端对应的乘车请求是否被配置；

当所述用户终端对应的乘车请求已被配置时，根据修改后的乘车请求更改对应的乘车配置信息。

在其中一个实施例中，所述根据所述乘车请求更改对应的乘车配置信息的步骤，包括：

检测修改后的乘车请求与所述乘车配置信息之间的匹配度是否达到预设匹配度；

若是，则保持所述乘车配置信息中的用户标识不变，根据所述修改后的乘车请求修改所述乘车配置信息中乘车时间和途径地点；

否则，修改为修改后的乘车请求配置的乘车配置信息，计算所述修改后的乘车请求在其它未配置的乘车请求或未满员的乘车配置信息之间路线的匹配度，为所述修改后的乘车请求生成新的乘车配置信息。

一种拼车装置，所述装置包括：

乘车请求获取模块，用于获取多个未配置的乘车请求，每个乘车请求中包含乘车时间、目的地和用户标识；

匹配度计算模块，用于根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度，所述出发地为预先设置的默认出发地；

乘车配置模块，用于根据所述匹配度对所述未配置的乘车请求进行乘车配置，将一个或多个所述未配置的乘车请求合并成一个乘车配置信息，所述乘车配置信息中包含乘车人数、发车时间、出发地、途径地点和被合并的乘车请求中的用户标识；将所述乘车配置信息发送至打车平台；

发车信息接收模块，用户接收打车平台发送的根据所述乘车配置信息配置的发车信息，所述发车信息包括车辆信息和发车时间；

发车信息发送模块，用于将所述发车信息发送给用户终端，所述用户终端为与所述被合并的乘车请求中包含的用户标识对应的用户终端。

在其中一个实施例中，所述装置还包括：

第一结算模块，用于获取每个发车信息对应的乘车费用；累计未结算的乘车费用，得到第一费用；当所述第一费用超过结算阈值时，才向所述打车平台进行费用结算，以降低结算频率。

在其中一个实施例中，所述装置还包括：

第二结算模块，用于获取待结算周期内的每个发车信息对应的乘车费用；累计所述乘车费用，得到第二费用；向所述打车平台进行费用结算，以降低结算频率。

在其中一个实施例中，所述乘车请求获取模块还用于接收用户终端发送的乘车信息修改请求；根据所述乘车信息修改请求修改所述用户终端对应的乘车请求；

所述装置还包括：配置检测模块，用于检测所述用户终端对应的乘车请求是否被配置；

所述乘车配置模块还用于当所述用户终端对应的乘车请求已被配置时，根据修改后的乘车请求更改对应的乘车配置信息。

在其中一个实施例中，所述乘车配置模块包括：

匹配度检测单元，用于检测修改后的乘车请求与所述乘车配置信息之间的匹配度是否达到预设匹配度；

第一乘车配置修改单元，用于当修改后的乘车请求与所述乘车配置信息之间的匹配度达到预设匹配度时，保持所述乘车配置信息中的用户标识不变，根据所述修改后的乘车请求修改所述乘车配置信息中乘车时间和途径地点；

第二乘车配置修改单元，用于当修改后的乘车请求与所述乘车配置信息之间的匹配度未达到预设匹配度时，修改为修改后的乘车请求配置的乘车配置信息，计算所述修改后的乘车请求在其它未配置的乘车请求或未满员的乘车配置信息之间路线的匹配度，为所述修改后的乘车请求生成新的乘车配置信息。

上述拼车方法和装置，通过汇总用户所提交的乘车请求，并根据每个乘车请求之间路线的匹配度来对未配置的乘车请求进行乘车配置，将未配置的乘车请求中的一个或多个合并成一个乘车配置信息，发送至打车平台，并将所接收的打车平台返回的发车信息发送给与乘车请求对应的用户终端，从而实现了多个用户之间的拼车。通过预先在汇总的乘车请求中来进行拼车，且该乘车请求中的出发地都为相同的默认出发地，从而可提高拼车的效率。

附图说明

图1为一个实施例中拼车方法的应用环境图；

图2为一个实施例中拼车方法的流程图；

图3为另一个实施例中拼车方法的流程图；

图4为又一个实施例中拼车方法的流程图；

图5为再一个实施例中拼车方法的流程图；

图6为一个实施例中根据修改后的乘车请求更改对应的乘车配置信息的步骤的流程图；

图7为一个实施例中拼车装置的结构框图；

图8为另一个实施例中拼车装置的结构框图；

图9为又一个实施例中拼车装置的结构框图；

图10为再一个实施例中拼车装置的结构框图；

图11为一个实施例中乘车配置模块的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例所提供的资讯包分配方法可应用于如图1所示的应用场景中。参考图1所示，用户终端110可通过预先设置的网络与服务器120进行交互，向服务器120发送乘车请求。其中，与服务器120相连接的用户终端110可包括多个，包括但不限于具有通信功能的智能手机、平板电脑、掌上电脑、智能手表等设备。服务器120上汇总用户终端110所发送的乘车请求，计算每个乘车请求之间路线的匹配度，将其中的一个或多个乘车请求合并成一个乘车配置信息，然后将乘车配置信息发送给打车平台130，打车平台130可根据该乘车配置信息为其配置相应的发车信息，将发车信息发送给服务器120，服务器120再将该发车信息发送给对应乘车请求中包含的用户标识对应的用户终端。

在一个实施例中，如图1所示，提供了一种拼车方法，该方法可应用于图1中的服务器120中，具体包括下述步骤202～212。

步骤202，获取多个未配置的乘车请求，每个乘车请求中包含乘车时间、目的地和用户标识。

本实施例中，服务器中存储了多个乘车请求，每个乘车请求中均包含了对应的乘车时间、目的地和用户标识。该乘车请求为对应的用户终端向服务器所发送的乘车请求，服务器可将所接收到的乘车请求存储到数据库中。服务器中可预先设置一个时间阈值，当检测到***时间到达该阈值后，则开始对所存储的乘车请求进行乘车配置，为相应的用户提供打车服务。

未配置的乘车请求是指还没有对该乘车请求进行乘车配置，以分配相应的发车信息。服务器对于所接收到的乘车请求，可为其设置对应的配置标记，根据该配置标记可获知对应的乘车请求是否被配置。比如，对于未配置的乘车请求，其对应的配置标记可为0，对于已配置的乘车请求，可更改其对应的配置标记为1。

进一步的，服务器可设置一个配置时间，比如可设置为15：00，当***时间到达该配置时间时，则开始获取未配置的乘车请求，进行乘车配置。

在一个实施例中，乘车时间不小于预设时间。该预设时间可为服务器所设置的可进行安排乘车配置的时间，比如为20：00，则该乘车时间需要在20：00或20：00之后。本实施例中，服务器为用户终端所进行的乘车配置可用于作为员工加班后，免费打车回家的福利，故而可要求该乘车时间不小于预设时间，即超过该预设时间，才为其进行乘车配置。

步骤204，根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度。

本实施例中，针对每个乘车请求，服务器其包含的乘车时间、出发地和目的地生成一条或多条候选行车路径。其中，出发地为预先设置的默认出发地，比如统一为用户的公司附近处的某一指定位置。在为每个乘车请求生成相应的行车路径后，可比较每两个或多个乘车请求的行车路径的乘车时间是否相同或相近。其中，相近是指乘车请求之间的发车时差小于预设时差，该预设时差既可为***设置的时差，也可根据用户提交乘车请求时，所携带的时差。

针对乘车时间相同或相近的乘车请求，服务器可根据对应乘车请求的乘车时间和每个行车路径来计算路线的匹配度。乘车时间越接近，且行车路径的重合度越高，则路线的匹配度也越高。

步骤206，根据匹配度对未配置的乘车请求进行乘车配置，将一个或多个未配置的乘车请求合并成一个乘车配置信息。

本实施例中，对于未配置的乘车请求，服务器可检测该乘车请求和与其乘车时间相同或相近的其它乘车请求之间路线的匹配度进行排名，并选取其中的一个或多个匹配度最高、且匹配度超过预设匹配度的乘车请求，将所选取的乘车请求与该乘车请求进行合并，生成一个乘车配置信息。其中，预设匹配度为服务器中预先设置的一个匹配度阈值，使得当两个乘车请求之间的匹配度达到该预设匹配度时，则判断可将两者进行拼车，生成一个乘车配置信息，若小于该预设匹配度，则判断两者不顺路，不对其进行拼车。

其中，所合并成的乘车配置信息中包含乘车人数、发车时间、出发地、途径地点和被合并的乘车请求中的用户标识。乘车人数可根据用户标识数来确定，一般的，乘车人数与出租车上标配的人数相匹配，比如为3人或4人。发车时间可由每个被合并的乘车请求中所包含的乘车时间来确定，可使得所确定的发车时间与各个乘车时间之间的综合差值最小或最优。出发地为默认的出发地，途径地点为每个乘车请求的目的地。

步骤208，将乘车配置信息发送至打车平台。

本实施例中，打车平台可为出租车打车平台或其它的互联网叫车平台，如滴滴或优步等。使得该打车平台在接收到对应的乘车配置信息后，配置相应的车辆实现对乘车请求的用户的接送。

步骤210，接收打车平台发送的根据乘车配置信息配置的发车信息，发车信息包括车辆信息和发车时间。

本实施例中，打车平台在接收到乘车配置信息后，可将该信息作为一条乘车订单进行公布，并接收该平台上的司机用户对该乘车订单的领取请求，根据该领取请求获取到对应司机的车辆信息，生成发车信息发送给服务器。或者打车平台还可以直接根据该乘车配置信息进行出租车和司机的配置，生成发车信息，发送给服务器。其中，发车信息包含有车辆信息和发车时间，车辆信息可包括车牌号、司机信息和车辆型号等其中的一种或多种，发车时间可为乘车配置信息所要求的发车时间。服务器可接收打车平台所发送的打车信息，并获取其中的车辆信息和发车时间。

步骤212，将发车信息发送给用户终端，用户终端为与被合并的乘车请求中包含的用户标识对应的用户终端。

本实施例中，服务器在接收到打车平台对乘车配置请求所安排的发车信息后，可将该发车信息发送给该乘车配置请求中，被合并的一个或多个乘车请求的用户标识对应的用户终端，使用户可获知服务器为其所安排的打车信息。具体的，服务器可采用邮件、短信或即时通信等消息的形式将打车信息发送给用户终端。

本实施例所提供的拼车方法，通过汇总用户所提交的乘车请求，并根据每个乘车请求之间路线的匹配度来对未配置的乘车请求进行乘车配置，将未配置的乘车请求中的一个或多个合并成一个乘车配置信息，发送至打车平台，并将所接收的打车平台返回的发车信息发送给与乘车请求对应的用户终端，从而实现了多个用户之间的拼车。通过预先在汇总的乘车请求中来进行拼车，且该乘车请求中的出发地都为相同的默认出发地，从而可提高拼车的效率。且对于同一发车信息，每个用户的乘车时间和乘车地点均相同，既提高了发车的便利性，又可提高在拼车出行过程中的安全性。

进一步的，相比于传统的企业班车为企业员工进行接送的方法，本实施例可根据汇总的乘车请求中包含的用户标识、乘车时间和目的地，以及默认出发地，进行灵活地配置，使得用户出行更加灵活方便。

在一个实施例中，如图3所示，提供了另一种拼车方法，该方法还包括：

步骤214，获取每个发车信息对应的乘车费用。

在对用户进行出行接送时，会产生乘车费用，即该发车信息对应的乘车费用，该乘车费用可由服务器与打车平台所约定的费用计算规则，根据实际或预计的出行路线得出。具体的，可由服务器自行计算出来，或由打车平台来计算，还可由实际的每个出租车终端来计算，将计算结果发送给打车平台，服务器可从打车平台中获取到对应的乘车费用。

步骤216，累计未结算的乘车费用，得到第一费用。

本实施例中，服务器可针对每个乘车费用设置一个对应的结算标记，使得根据该结算标记可获知该乘车费用是否已经完成结算。具体的，针对未结算的乘车费用，对应的结算标记可为0，对于已结算的乘车费用，可更改其对应的结算标记为1。

服务器可累计每个未结算的乘车费用，得到第一费用。具体的，可实时或按照一定的频率来获取未被纳入统计中的未结算的乘车费用，并与最新统计的第一费用进行累加，将累加的和更新为第一费用。

步骤218，当第一费用超过结算阈值时，才向打车平台进行费用结算，以降低结算频率。

本实施例中，结算阈值为服务器与打车平台所约定的用于是否进行结算乘车费用的阈值。服务器在每次更新第一费用的时候，可将所更新后的第一费用与该结算阈值进行比较，判断该第一费用是否超过结算，若是，则与该打车平台进行第一费用的结算，完成结算后，更改该第一费用所包含的乘车费用的结算标记，使其表示为已结算的乘车费用。若第一费用未超过结算阈值，则继续获取所生成的未结算的乘车费用，累计得到第一费用，直至该第一费用超过结算阈值时，进行第一费用结算，以降低结算频率。

本实施例中，通过设置结算阈值，使得当未结算的乘车费用累计得到的第一费用超过该结算阈值时，再进行乘车费用的结算，从而可降低与打车平台进行结算的频率，减少了结算资源的占用。

在一个实施例中，如图4所示，提供了又一个拼车方法，该方法还包括：

步骤220，获取待结算周期内的每个发车信息对应的乘车费用。

本实施例中，服务器中设置了结算周期，类似的，该结算周期为服务器与打车平台所约定的用于进行结算乘车费用的周期。比如，可设置该结算周期为一周或一个月等任意时长。待结算周期为需要与打车平台进行乘车费用结算的周期，该乘车费用为在该待结算周期内所进行的乘车出行所产生的乘车费用。服务器可根据该结算周期确定相应的待结算周期的起止时间，进而获取位于该起止时间内的发车信息所对应的乘车费用。

步骤222，累计乘车费用，得到第二费用。

本实施例中，服务器对该待结算周期中所生成的每个乘车费用进行累加，得到的累加和即为第二费用。

步骤224，向打车平台进行费用结算，以降低结算频率。

本实施例中，服务器可调用预设接口与打车平台进行待结算周期内的第二费用的费用结算。一般的，在当前周期结束后，还未完成费用结算之前，该当前周期即变成为待结算周期。通过设置结算周期，使得可按照结算周期来进行乘车费用的结算，同样可降低与打车平台进行结算的频率，减少了结算资源的占用。

在一个实施例中，如图5所示，提供了又一种拼车方法，该方法还包括以下步骤：

步骤226，接收用户终端发送的乘车信息修改请求。

本实施例中，用户终端在向服务器发送了乘车请求后，可再次向服务器发送对该乘车请求进行修改的乘车信息修改请求，服务器可接收用户终端发送的乘车信息修改请求。其中，乘车信息修改请求中可包括乘车时间或目的地的修改信息等其中的一项或多项。

步骤228，根据乘车信息修改请求修改用户终端对应的乘车请求。

具体的，服务器可查询出用户终端所发送的乘车请求，并根据乘车信息修改请求中要求修改的乘车时间或目的地的等其中的一项或多项，来对应修改乘车请求。

步骤230，检测用户终端对应的乘车请求是否被配置。

本实施例中，服务器可获取对应乘车请求的配置标记，根据该配置标记检测该乘车请求是否被配置。若未被配置，则根据修改后的乘车请求，按照步骤204～212对该用户安排发车信息。若被配置，则执行步骤232。

步骤232，当用户终端对应的乘车请求已被配置时，根据修改后的乘车请求更改对应的乘车配置信息。

对于已被配置的需要修改的乘车请求，服务器根据修改后的乘车请求对与其对应的乘车配置信息进行适应的调整，包括更改该乘车配置信息中的发车时间或途径地点等，并根据需要可删除该乘车配置信息中与修改后的乘车请求对应的途径地点，取消两者的对应关系，并为修改后的乘车请求重新配置一个新的乘车配置信息。具体配置方法可与上述的步骤204～212相同或相似。

在一个实施例中，如图6所示，根据修改后的乘车请求更改对应的乘车配置信息的步骤，包括：

步骤602，检测修改后的乘车请求与乘车配置信息之间的匹配度是否达到预设匹配度。若是，则执行步骤604，否则，执行步骤606。

具体的，检测该修改后的乘车请求与该乘车配置信息中的其它乘车请求之间路线的匹配度是否均达到预设匹配度。其中，匹配度计算方法与步骤204中的计算方法相同。若是，则执行步骤604，否则，执行步骤606。

步骤604，保持乘车配置信息中的用户标识不变，根据修改后的乘车请求修改乘车配置信息中乘车时间和途径地点。

本实施例中，当检测到修改后的乘车请求与乘车配置信息之间的匹配度达到预设匹配度时，则无需更改乘车配置信息中的用户标识，并根据修改后的乘车请求以及乘车配置信息中的其它乘车请求中的乘车时间和目的地重新确定新的乘车时间和途径地点。

步骤606，修改为该修改后的乘车请求配置的乘车配置信息，并计算修改后的乘车请求在其它未配置的乘车请求或未满员的乘车配置信息之间路线的匹配度，为修改后的乘车请求生成新的乘车配置信息。

当检测到修改后的乘车请求与乘车配置信息之间的匹配度未达到预设匹配度时，则更改为该乘车请求所配置的乘车配置信息，从其中删除该乘车请求。具体的，根据该乘车配置信息中的其它乘车请求的乘车时间更改对应的发车时间和途径地点，并更改乘车人数，删除修改后的乘车请求的用户标识。

进一步的，再根据该修改后的乘车请求计算其与其它未配置的乘车请求之间路线的匹配度，具体计算方式和步骤204中的相同。

和/或计算其与其它未满员的乘车配置信息之间路线的匹配度。未满员是指该乘车配置信息中所包含的乘车人数未使对应的车辆坐满，即该车辆还留有空座可以载人。具体的，可计算其与其它未满员的乘车配置信息所对应的每个乘车请求的匹配度，检测该匹配度是否达到预设匹配度。并从所检测的达到预设匹配度中选取匹配度最高的未满员的乘车配置信息，将该修改后的乘车请求配置到该乘车配置信息中，根据该乘车配置信息中的其它乘车请求的乘车时间更改对应的发车时间和途径地点，并更改乘车人数，生成新的乘车配置信息。

在一个实施例中，在生成新的乘车配置信息后，则将该修改后的乘车配置信息发送给打车平台，使打车平台根据该修改后的乘车配置信息对应修改该打车信息，将修改后的打车信息发送给服务器。服务器在接收到该修改后的打车信息后，则将该修改后的发车信息发送给对应被合并的一个或多个乘车请求的用户标识对应的用户终端。

本实施例中，通过接收乘车信息修改请求，根据该乘车信息修改请求为对应的用户重新配置乘车配置信息，可进一步提高拼车的灵活性和便利性。

在一个实施例中，如图7所示，提供了一种拼车装置，该装置包括：

乘车请求获取模块702，用于获取多个未配置的乘车请求，每个乘车请求中包含乘车时间、目的地和用户标识。

匹配度计算模块704，用于根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度，出发地为预先设置的默认出发地。

乘车配置模块706，用于根据匹配度对未配置的乘车请求进行乘车配置，将一个或多个未配置的乘车请求合并成一个乘车配置信息，乘车配置信息中包含乘车人数、发车时间、出发地、途径地点和被合并的乘车请求中的用户标识；将乘车配置信息发送至打车平台。

发车信息接收模块708，用户接收打车平台发送的根据乘车配置信息配置的发车信息，发车信息包括车辆信息和发车时间。

发车信息发送模块710，用于将发车信息发送给用户终端，用户终端为与被合并的乘车请求中包含的用户标识对应的用户终端。

在一个实施例中，如图8所示，提供了另一种拼车装置，该装置还包括：

第一结算模块712，用于获取每个发车信息对应的乘车费用；累计未结算的乘车费用，得到第一费用；当第一费用超过结算阈值时，向打车平台进行费用结算，以降低结算频率。

在一个实施例中，如图9所示，提供了又一种拼车装置，该装置还包括：

第二结算模块714，用于获取待结算周期中的每个发车信息对应的乘车费用；累计乘车费用，得到第二费用；向打车平台进行费用结算，以降低结算频率。

在一个实施例中，如图10所示，提供了再一种拼车装置，其特征在于，

乘车请求获取模块702还用于接收用户终端发送的乘车信息修改请求；根据乘车信息修改请求修改用户终端对应的乘车请求；

该装置还包括：配置检测模块716，用于检测用户终端对应的乘车请求是否被配置；

乘车配置模块706还用于当用户终端对应的乘车请求已被配置时，根据修改后的乘车请求更改对应的乘车配置信息。

在一个实施例中，如图11所示，乘车配置模块包括：

匹配度检测单元1102，用于检测修改后的乘车请求与乘车配置信息之间的匹配度是否达到预设匹配度；

第一乘车配置修改单元1104，用于当修改后的乘车请求与乘车配置信息之间的匹配度达到预设匹配度时，保持乘车配置信息中的用户标识不变，根据修改后的乘车请求修改乘车配置信息中乘车时间和途径地点；

第二乘车配置修改单元1106，用于当修改后的乘车请求与乘车配置信息之间的匹配度未达到预设匹配度时，修改为修改后的乘车请求配置的乘车配置信息，计算修改后的乘车请求在其它未配置的乘车请求或未满员的乘车配置信息之间路线的匹配度，为修改后的乘车请求生成新的乘车配置信息。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (8)

1.一种拼车方法，其特征在于，所述方法包括以下步骤：

获取多个未配置的乘车请求，每个乘车请求中包含乘车时间、目的地和用户标识；

根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度，所述出发地为预先设置的默认出发地，所述每个乘车请求之间的乘车时间相同或发车时差小于预设时差；

根据所述匹配度对所述未配置的乘车请求进行乘车配置，将一个或多个所述未配置的乘车请求合并成一个乘车配置信息，所述乘车配置信息中包含乘车人数、发车时间、出发地、途径地点和被合并的乘车请求中的用户标识；

将所述乘车配置信息发送至打车平台；

接收打车平台发送的根据所述乘车配置信息配置的发车信息，所述发车信息包括车辆信息和发车时间；

将所述发车信息发送给用户终端，所述用户终端为与所述被合并的乘车请求中包含的用户标识对应的用户终端；

接收用户终端发送的乘车信息修改请求；

根据所述乘车信息修改请求修改所述用户终端对应的乘车请求；

检测所述用户终端对应的乘车请求是否被配置；

当所述用户终端对应的乘车请求已被配置时，根据修改后的乘车请求更改对应的乘车配置信息；

所述根据所述乘车请求更改对应的乘车配置信息的步骤，包括：

检测修改后的乘车请求与所述乘车配置信息之间的匹配度是否达到预设匹配度；

若否，则修改为修改后的乘车请求配置的乘车配置信息，计算所述修改后的乘车请求在其它未配置的乘车请求或未满员的乘车配置信息之间路线的匹配度，为所述修改后的乘车请求生成新的乘车配置信息。

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

获取每个发车信息对应的乘车费用；

累计未结算的乘车费用，得到第一费用；

当所述第一费用超过结算阈值时，才向所述打车平台进行费用结算，以降低结算频率。

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

获取待结算周期内的每个发车信息对应的乘车费用；

累计所述乘车费用，得到第二费用；

向所述打车平台进行费用结算，以降低结算频率。

4.根据权利要求1所述的方法，其特征在于，所述根据所述乘车请求更改对应的乘车配置信息的步骤，还包括：

若修改后的乘车请求与所述乘车配置信息之间的匹配度达到预设匹配度，则保持所述乘车配置信息中的用户标识不变，根据所述修改后的乘车请求修改所述乘车配置信息中乘车时间和途径地点。

5.一种拼车装置，其特征在于，所述装置包括：

乘车请求获取模块，用于获取多个未配置的乘车请求，每个乘车请求中包含乘车时间、目的地和用户标识；

匹配度计算模块，用于根据乘车时间、出发地和目的地，计算每个乘车请求之间路线的匹配度，所述出发地为预先设置的默认出发地，所述每个乘车请求之间的乘车时间相同或发车时差小于预设时差；

乘车配置模块，用于根据所述匹配度对所述未配置的乘车请求进行乘车配置，将一个或多个所述未配置的乘车请求合并成一个乘车配置信息，所述乘车配置信息中包含乘车人数、发车时间、出发地、途径地点和被合并的乘车请求中的用户标识；将所述乘车配置信息发送至打车平台；

发车信息接收模块，用户接收打车平台发送的根据所述乘车配置信息配置的发车信息，所述发车信息包括车辆信息和发车时间；

发车信息发送模块，用于将所述发车信息发送给用户终端，所述用户终端为与所述被合并的乘车请求中包含的用户标识对应的用户终端；

所述乘车请求获取模块还用于接收用户终端发送的乘车信息修改请求；根据所述乘车信息修改请求修改所述用户终端对应的乘车请求；

所述装置还包括：配置检测模块，用于检测所述用户终端对应的乘车请求是否被配置；

所述乘车配置模块还用于当所述用户终端对应的乘车请求已被配置时，根据修改后的乘车请求更改对应的乘车配置信息；

所述乘车配置模块包括：

匹配度检测单元，用于检测修改后的乘车请求与所述乘车配置信息之间的匹配度是否达到预设匹配度；

第二乘车配置修改单元，用于当修改后的乘车请求与所述乘车配置信息之间的匹配度未达到预设匹配度时，修改为修改后的乘车请求配置的乘车配置信息，计算所述修改后的乘车请求在其它未配置的乘车请求或未满员的乘车配置信息之间路线的匹配度，为所述修改后的乘车请求生成新的乘车配置信息。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：

第一结算模块，用于获取每个发车信息对应的乘车费用；累计未结算的乘车费用，得到第一费用；当所述第一费用超过结算阈值时，才向所述打车平台进行费用结算，以降低结算频率。

7.根据权利要求5所述的装置，其特征在于，所述装置还包括：

第二结算模块，用于获取待结算周期内的每个发车信息对应的乘车费用；累计所述乘车费用，得到第二费用；向所述打车平台进行费用结算，以降低结算频率。

8.根据权利要求5所述的装置，其特征在于，所述乘车配置模块还包括：

第一乘车配置修改单元，用于当修改后的乘车请求与所述乘车配置信息之间的匹配度达到预设匹配度时，保持所述乘车配置信息中的用户标识不变，根据所述修改后的乘车请求修改所述乘车配置信息中乘车时间和途径地点。

Images