CN106339763A - 拼车方法、乘客端及服务端 - Google Patents

Abstract

本发明公开了由乘客发起且能自主选择其他拼车乘客的拼车方法、乘客端及服务端。拼车方法，包括：服务端接收第一乘客端发来的拼车发起请求，拼车发起请求中携带有线路信息、时间信息；服务端根据拼车发起请求生成待拼车订单，将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车；若确定加入拼车，服务端接收第二乘客端发来的拼车响应请求；服务端将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；服务端接收第一乘客端发来的反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。通过乘客自主发起拼车路线，自主选择拼车人，把选择权留给乘客，实现安全拼车。

Description

拼车方法、乘客端及服务端

技术领域

本发明涉及一种移动通信和互联网技术领域，尤其涉及一种拼车方法、相应的乘客端以及服务端。

背景技术

随着移动互联网的发展，打车软件的普及，人生的打车习惯已经被深刻地改变。乘客使用专车很多时候会是一个人，这个时候无形中浪费了车辆的资源，同时也增加了乘客的打车成本，一定程度上也造成的交通的拥堵。在比较偏僻和时间比较晚的情况下，专车事件频发，乘客出行得不到可靠地保障，安全令人堪忧。此种情况下，多个乘客拼车的方法应运而生。

现有技术中的顺风车是由车主发起行程，并且不支持乘客自主选择行程中的拼车人员，在一定程度上还是不能解决拼车出行安全方面的不确定性。

发明内容

针对以上技术不足，本发明提供了一种由乘客发起且能自主选择其他拼车乘客的拼车方法及相应的服务端和乘客端。

本发明是这样实现的：一种拼车方法，包括如下步骤：

服务端接收第一乘客端发来的拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户信息、线路信息、时间信息；

当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

服务端将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

服务端接收第一乘客端发来的反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。

进一步地，在服务端将拼车发起请求发送至第二乘客端前，还包括如下步骤：

服务端接收第二乘客端发来的打车请求，所述打车请求中包含有线路信息、时间信息；

服务端确定第二乘客端用户是否接受拼车；

当第二乘客端用户接受拼车时，服务端将与打车请求相匹配的待拼车订单发送至第二乘客端。

进一步地，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

进一步地，在拼车成功后还包括：

服务端将包含有押金信息的费用请求发送至第一乘客端和第二乘客端，并接收第一乘客端和第二乘客端发来的针对费用请求的付款信息。

进一步地，在拼车行程结束后，服务端计算实际费用并将实际费用从押金中扣除，剩余的费用退回第一乘客端和第二乘客端对应的账户。

本发明还公开了一种基于第一乘客端的拼车方法，包括如下步骤：

第一乘客端向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息，使得服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息，当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有用户信息；

第一乘客端接收服务端转发的来自于第二乘客端的拼车响应请求，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

第一乘客端向服务端发送反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。

进一步地，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

进一步地，在拼车成功后还包括：

第一乘客端接收服务端发来的包含有押金信息的费用请求；

第一乘客端向服务端发送针对费用请求的付款信息。

进一步地，在拼车行程结束后，第一乘客端对应的账户接收服务端返回的剩余费用，所述剩余费用为服务端计算实际费用后并将实际费用从押金中扣除后所得。

本发明还公开了一种服务端，包括：

接收单元，用于接收第一乘客端发来的拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

所述接收单元还用于接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

所述接收单元还用于接收第一乘客端发来的反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见；

待拼车订单生成单元，用于根据拼车发起请求生成待拼车订单，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息；

拼车订单生成单元，用于根据第一乘客端发来的反馈信息生成本次拼车的拼车订单，所述拼车订单包括第一乘客端的用户信息、第二乘客端的用户信息、线路信息、时间信息，第二乘客端的用户和第一乘客端的用户拼车成功；

发送单元，用于将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述发送单元还用于将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车。

进一步地，所述接收单元还用于接收第二乘客端发来的打车请求，所述打车请求中包含有线路信息、时间信息；

所述发送单元还用于将包含是否接受拼车的确认请求发送至第二乘客端；

所述接收单元还用于接收第二乘客端发来的针对确认请求的返回信息；

当第二乘客端的返回信息为接受拼车时，所述发送单元将与打车请求相匹配的待拼车订单发送至第二乘客端。

进一步地，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，待拼车订单生成单元根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

进一步地，所述服务端还包括：

费用处理单元，根据拼车发起请求生成包含有押金信息的费用请求，根据实际行车路线及拼车人数计算拼车费用，在拼车结束时将实际费用从押金中扣除；

所述接收单元还用于接收第一乘客端和第二乘客端发来的押金支付信息；

所述发送单元还用于将费用请求发送至拼车成功的第一乘客端和第二乘客端，用于将押金扣除实际费用后的剩余费用发送至第一乘客端和第二乘客端。

本发明还公开了一种第一乘客端，包括：

发送单元，向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息，使得服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息，当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有用户信息；

所述发送单元还用于向服务端发送反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功；

接收单元，接收服务端发来的拼车响应请求，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车。

进一步地，所述接收单元还用于接收服务端发来的费用请求，所述费用请求由服务端根据拼车发起请求生成，其中包含有押金信息；

所述接收单元还用于接收服务端发来的剩余费用，所述剩余费用为服务端根据实际行车路线及拼车人数计算拼车费用，并在拼车结束时将实际费用从押金中扣除所得；

押金支付信息生成单元，用于根据服务端发来的费用请求生成包含身份标识的押金支付信息，

所述发送单元还用于向服务端发送押金支付信息。

本发明还公开了一种第二乘客端，包括：

接收单元，用于接收服务端发来的待拼车订单，以使得所述乘客端对应的用户确定是否加入拼车，所述待拼车订单由服务端根据拼车发起请求生成，所述拼车发起请求由第一乘客端发送至服务端，所述拼车发起请求中携带有第一乘客端用户制定的线路信息、时间信息；

发送单元，用于向服务端发送拼车响应请求，所述拼车响应请求中包含有所述乘客端的用户信息。

进一步地，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

进一步地，所述接收单元还用于接收服务端发来的费用请求，所述费用请求由服务端根据拼车发起请求生成，其中包含有押金信息；

所述接收单元还用于接收服务端发来的剩余费用，所述剩余费用为服务端根据实际行车路线及拼车人数计算拼车费用，并在拼车结束时将实际费用从押金中扣除所得；

押金支付信息生成单元，用于根据服务端发来的费用请求生成包含身份标识的押金支付信息，所述发送单元还用于向服务端发送押金支付信息。

与现有技术相比，本发明的有益效果如下：本技术方案中由第一乘客端的用户发起拼车请求，其中可以限定路线、时间、拼车人数、其他拼车乘客的条件。当第二乘客端的用户想加入拼车时，可以查看已经存在的拼车请求，结合自身情况，选择是否加入拼车请求。若选择加入拼车请求，则通过第二乘客端将自身的信息返回给服务端，服务端将第二乘客端用户的信息发送给第一乘客端，让第一乘客端的用户决定是否同意第二乘客端的用户加入该拼车。

本发明技术方案通过乘客自主发起拼车请求，自主选择路线、时间、自主选择拼车人，可以把选择权留给乘客，在尊重乘客意愿的前提下，营造良好安全的拼车氛围，既解决了个人拼车导致的资源浪费及道路拥堵问题，又提高了多人拼车的安全问题。

附图说明

图1为本发明实施例提供的一种拼车方法的流程示意图；

图2为本发明实施例提供的另一种拼车方法的流程示意图；

图3为本发明实施例提供的另一种拼车方法的流程示意图；

图4为本发明实施例中第一乘客端创建拼车发起请求时的界面示意图；

图5为本发明实施例中服务端确认第二乘客端用户是否接受拼车的界面示意图；

图6为本发明实施例中第二乘客端接收到服务端发来的待拼车订单的界面示意图；

图7为本发明实施例中第一乘客端接收到服务端发来的拼车响应请求的界面示意图；

图8为本发明实施例中服务端的结构示意图；

图9为本发明实施例中第一乘客端的结构示意图；

图10为本发明实施例中第二乘客端的结构示意图。

具体实施方式

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

本发明实施例提供的一种拼车方法，如图1所示，包括：

S101、服务端接收第一乘客端发来的拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

S102、服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户信息、线路信息、时间信息；

S103、当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

S104、服务端将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

S105、服务端接收第一乘客端发来的反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。

基于同一发明构思，本发明还提供一种第一乘客端侧的拼车方法，包括：

S201、第一乘客端向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息，使得服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息，当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有用户信息；

S202、第一乘客端接收服务端转发的来自于第二乘客端的拼车响应请求，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

S203、第一乘客端向服务端发送反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。

本发明实施例提供的一种拼车方法，由第一乘客端的用户发起拼车请求，其中可以限定路线、时间、拼车人数、其他拼车乘客的条件。当第二乘客端的用户想加入拼车时，可以查看已经存在的拼车请求，结合自身情况，选择是否加入拼车请求。若选择加入拼车请求，则通过第二乘客端将自身的信息返回给服务端，服务端将第二乘客端用户的信息发送给第一乘客端，让第一乘客端的用户决定是否同意第二乘客端的用户加入该拼车。本发明技术方案通过乘客自主发起拼车请求，自主选择路线、时间、自主选择拼车人，可以把选择权留给乘客，在尊重乘客意愿的前提下，营造良好安全的拼车氛围，既解决了个人拼车导致的资源浪费及道路拥堵问题，又提高了多人拼车的安全问题。

为了使本领域技术人员能更清楚地理解本发明实施例提供的技术方案，下面通过具体的实施例，对本发明提供的一种拼车方法进行详细说明，如图3所示，该方法包括：

S301：第一乘客端向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

示例性地，服务端中注册有若干乘客的用户信息，这些用户均通过移动终端安装有本发明提供的乘客端，该乘客端中集合有两种模式，包括第一乘客端和第二乘客端，其中第一乘客端用来发起或创建拼车请求，第二乘客端用于加入服务端中已有的拼车请求。

在用户还未确定是否接受拼车前，第二乘客端称为乘客端。

示例性地，用户通过第一乘客端发送拼车发起请求，从而创建一条拼车路线，界面如图4所示，该拼车发起请求中携带有自身的身份标识（暗含，图中未示出）以及创建的线路信息（包括上车地点、下车地点）以及与该线路信息相对应的时间信息（包括打车时间、拼车接受时间）、拼车人数。

S302：服务端接收第一乘客端发来的拼车发起请求，根据拼车发起请求生成待拼车订单，所述待拼车订单中包含有第一乘客端的用户信息、线路信息、时间信息；

S303：乘客端向服务端发送打车请求，所述打车请求中包含有线路信息、时间信息；

示例性地，用户通过乘客端向服务端发起打车请求，打车请求中包含有自身的用户信息、线路信息以及相应的时间信息，此时，还未决定使用第一乘客端还是第二乘客端。

S304：服务端确定乘客端用户是否接受拼车；

为了尊重乘客的意愿，服务端接收到乘客的打车请求后，首先询问乘客是否愿意拼车，从而扩展本系统的适应性。

服务端将包含是否接受拼车的确认请求发送至乘客端，界面如图5所示；

当乘客端用户接受拼车时，用户通过乘客端向服务端发送针对确认请求的返回信息，此时，启用第二乘客端模式，进入步骤S305。

若用户不接受拼车，则启动第一乘客端，进入步骤S301。

S305：服务端将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车；

服务端根据打车请求，按照一定的筛选规则选出符合打车请求的待拼车订单，例如路线有重合的或时间有重合的，这个筛选规则可根据实际情况设定，这里不做限定。

示例性地，待拼车订单通过上车地点和下车地点来体现，界面如图6所示。

S306：当第二乘客端用户确定加入拼车时，第二乘客端向服务端发送拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

第二乘客端的用户根据自己的实际情况，选择一个待拼车订单，并将针对该待拼车订单的拼车响应请求发送至服务端，该拼车响应请求中包含第二乘客端的用户信息，例如姓名、性别、电话号码等。

S307：服务端将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

服务端收到第二乘客端发来的拼车响应请求后，根据拼车响应请求和待拼车订单的对应关系，将拼车响应请求发送至对应的第一乘客端，使得第一乘客端的用户可以选择第二乘客端的用户来加入拼车。

示例性地，拼车响应请求通过第二乘客端用户的姓名和性别来体现，界面如图7所示。

S308：第一乘客端的用户确定是否同意第二乘客端的用户加入拼车？若同意，则进入步骤S309，否则，返回至步骤S303。

S309：第一乘客端向服务端发送同意的反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见，第二乘客端用户与第一乘客端用户拼车成功。

第一乘客端的用户（即发起拼车请求的用户）通过第一乘客端查看服务端发来的所有有意愿加入拼车的用户的信息，如图7所示。第一乘客端的用户根据自己的实际情况，选择相应的第二乘客端的用户来加入拼车，例如如果第一乘客端用户为女性的话，她可能倾向选择女性来拼车，每个用户的情况都不一样，本发明不做限定。第一乘客端将被选中的第二乘客端的用户信息作为反馈信息发送至服务端，服务端即将被选中的第二乘客端的用户信息加入拼车订单，该第二乘客端用户与第一乘客端用户拼车成功。

为了提高资源的利用率，尽量让更多的人加入拼车，也降低自身拼车的费用，第一乘客端的用户在发起拼车请求时，所述拼车发起请求中携带有对拼车人数的限制信息，拼车人数可以根据自身的实际情况来设置，例如第一乘客端的用户自身已经有2个人，那根据普通小型汽车的座位数，可供拼车的人数在2-3个人，本发明不做限制。所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

例如第一乘客端的用户只有1个人，在拼车请求中设定的拼车人数是3人，其中一个第二乘客端的拼车响应请求中携带的拼车人数是2个，第一乘客端的用户同意了该拼车响应请求，则服务端接收到第一乘客端的反馈信息后，更改该待拼车订单中的人数为1个，当另一个第二乘客端的拼车响应请求中携带的拼车人数是1个时，若第一乘客端的用户同意该拼车响应请求，则该待拼车订单拼车完成。服务端将该待拼车订单删除。

由于本技术方案涉及到多方拼车，基于每个用户的情况不同，为了约束拼车人的信用，提高拼车效率，减少随意退出拼车的情况，在拼车成功后还包括如下步骤：

S310：服务端将包含有押金信息的费用请求发送至拼车成功的第一乘客端和第二乘客端，并接收第一乘客端和第二乘客端发来的针对费用请求的付款信息。

服务端根据拼车发起请求生成包含有押金信息的费用请求，并将该费用请求发送至拼车订单中的第一乘客端和第二乘客端，接收相应的第一乘客端和第二乘客端发来的针对费用请求的付款信息，至此，收取押金成功。

S311：在拼车行程结束后，服务端计算实际费用并将实际费用从押金中扣除，剩余的费用退回第一乘客端和第二乘客端对应的账户。

在拼车行程结束后，服务端根据实际行车路线以及拼车人数计算每个第一乘客端和第二乘客端用户的实际费用，并将该实际费用从押金中扣除，剩余的费用退回至第一乘客端和第二乘客端对应的账户中。

可见，本发明提供的拼车方法，由第一乘客端的用户发起拼车请求，其中可以限定路线、时间、拼车人数、其他拼车乘客的条件。当第二乘客端的用户想加入拼车时，可以查看已经存在的拼车请求，结合自身情况，选择是否加入拼车请求。若选择加入拼车请求，则通过第二乘客端将自身的信息返回给服务端，服务端将第二乘客端用户的信息发送给第一乘客端，让第一乘客端的用户决定是否同意第二乘客端的用户加入该拼车。本发明技术方案通过乘客自主发起拼车请求，自主选择路线、时间、自主选择拼车人，可以把选择权留给乘客，在尊重乘客意愿的前提下，营造良好安全的拼车氛围，既解决了个人拼车导致的资源浪费及道路拥堵问题，又提高了多人拼车的安全问题。

另外，本发明提供的拼车方法，在确定拼车成功后向拼车的各方收取押金，在拼车完成后，实际拼车费用直接在押金中扣除并将剩余的费用退回拼车各方。采用该手段，约束了拼车人的信用，提高了拼车的效率。

基于同一发明构思，本发明还提供一种服务端，如图8所示，包括：

接收单元41，用于接收第一乘客端发来的拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

所述接收单元41还用于接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

所述接收单元41还用于接收第一乘客端发来的反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见；

待拼车订单生成单元42，用于根据拼车发起请求生成待拼车订单，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息；

拼车订单生成单元43，用于根据第一乘客端发来的反馈信息生成本次拼车的拼车订单，所述拼车订单包括第一乘客端的用户信息、第二乘客端的用户信息、线路信息、时间信息，第二乘客端的用户和第一乘客端的用户拼车成功；

发送单元44，用于将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述发送单元44还用于将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车。

为了尊重乘客的意愿，服务端接收到乘客的打车请求后，首先询问乘客是否愿意拼车，从而扩展本系统的适应性。

示例性地，所述接收单元41还用于接收第二乘客端发来的打车请求，所述打车请求中包含有线路信息、时间信息；

所述发送单元44还用于将包含是否接受拼车的确认请求发送至第二乘客端；

所述接收单元41还用于接收第二乘客端发来的针对确认请求的返回信息；

当第二乘客端的返回信息为接受拼车时，所述发送单元44将与打车请求相匹配的待拼车订单发送至第二乘客端。

为了提高资源的利用率，尽量让更多的人加入拼车，也降低自身拼车的费用，第一乘客端的用户在发起拼车请求时，所述拼车发起请求中携带有对拼车人数的限制信息，拼车人数可以根据自身的实际情况来设置，例如第一乘客端的用户自身已经有2个人，那根据普通小型汽车的座位数，可供拼车的人数在2-3个人，本发明不做限制。所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，待拼车订单生成单元42根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

由于本技术方案涉及到多方拼车，基于每个用户的情况不同，为了约束拼车人的信用，提高拼车效率，减少随意退出拼车的情况，服务端还包括：

费用处理单元45，根据拼车发起请求生成包含有押金信息的费用请求，根据实际行车路线及拼车人数计算拼车费用，在拼车结束时将实际费用从押金中扣除；

所述接收单元41还用于接收第一乘客端和第二乘客端发来的押金支付信息；

所述发送单元44还用于将费用请求发送至拼车成功的第一乘客端和第二乘客端，将押金扣除实际费用后的剩余费用发送至第一乘客端和第二乘客端。

基于同一发明构思，本发明还提供一种乘客端，示例性地，该乘客端为第一乘客端，如图9所示，包括：

发送单元51，向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息，使得服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息，当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有用户信息；

所述发送单元51还用于向服务端发送反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功；

接收单元52，接收服务端发来的拼车响应请求，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车。

由于本技术方案涉及到多方拼车，基于每个用户的情况不同，为了约束拼车人的信用，提高拼车效率，减少随意退出拼车的情况，所述接收单元52还用于接收服务端发来的费用请求，所述费用请求由服务端根据拼车发起请求生成，其中包含有押金信息；

所述接收单元52还用于接收服务端发来的剩余费用，所述剩余费用为服务端根据实际行车路线及拼车人数计算拼车费用，并在拼车结束时将实际费用从押金中扣除所得；

押金支付信息生成单元53，用于根据服务端发来的费用请求生成包含身份标识的押金支付信息，所述发送单元51还用于向服务端发送押金支付信息。

基于同一发明构思，本发明还提供另一种乘客端，示例性地，该乘客端为第二乘客端，如图10所示，包括：

接收单元61，用于接收服务端发来的待拼车订单，以使得所述乘客端对应的用户确定是否加入拼车，所述待拼车订单由服务端根据拼车发起请求生成，所述拼车发起请求由第一乘客端发送至服务端，所述拼车发起请求中携带有第一乘客端用户制定的线路信息、时间信息；

发送单元62，用于向服务端发送针对待拼车订单的拼车响应请求，所述拼车响应请求中包含有所述乘客端的用户信息。

为了提高资源的利用率，尽量让更多的人加入拼车，也降低自身拼车的费用，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

由于本技术方案涉及到多方拼车，基于每个用户的情况不同，为了约束拼车人的信用，提高拼车效率，减少随意退出拼车的情况，所述接收单元61还用于接收服务端发来的费用请求，所述费用请求由服务端根据拼车发起请求生成，其中包含有押金信息；

所述接收单元61还用于接收服务端发来的剩余费用，所述剩余费用为服务端根据实际行车路线及拼车人数计算拼车费用，并在拼车结束时将实际费用从押金中扣除所得；

押金支付信息生成单元63，用于根据服务端发来的费用请求生成包含身份标识的押金支付信息，所述发送单元62还用于向服务端发送押金支付信息。

服务端、第一乘客端及第二乘客端的运行方法与拼车方法相同，因此，其具体使用方法可参考拼车方法的流程，此处不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的打车系统服务器中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (18)

1.一种拼车方法，其特征在于，包括：

服务端接收第一乘客端发来的拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户信息、线路信息、时间信息；

当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

服务端将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

服务端接收第一乘客端发来的反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。

2.根据权利要求1所述的拼车方法，其特征在于，在服务端将拼车发起请求发送至第二乘客端前，还包括：

服务端接收第二乘客端发来的打车请求，所述打车请求中包含有线路信息、时间信息；

服务端确定第二乘客端用户是否接受拼车；

当第二乘客端用户接受拼车时，服务端将与打车请求相匹配的待拼车订单发送至第二乘客端。

3.根据权利要求1所述的拼车方法，其特征在于，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

4.根据权利要求1所述的拼车方法，其特征在于，在拼车成功后还包括：

服务端将包含有押金信息的费用请求发送至拼车成功的第一乘客端和第二乘客端，并接收第一乘客端和第二乘客端发来的针对费用请求的付款信息。

5.根据权利要求4所述的拼车方法，其特征在于，在拼车行程结束后，服务端计算实际费用并将实际费用从押金中扣除，剩余的费用退回第一乘客端和第二乘客端对应的账户。

6.一种拼车方法，其特征在于，包括：

第一乘客端向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息，使得服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息，当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有用户信息；

第一乘客端接收服务端转发的来自于第二乘客端的拼车响应请求，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车；

第一乘客端向服务端发送反馈信息，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功。

7.根据权利要求6所述的拼车方法，其特征在于，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

8.根据权利要求6所述的拼车方法，其特征在于，在拼车成功后还包括：

第一乘客端接收服务端发来的包含有押金信息的费用请求；

第一乘客端向服务端发送针对费用请求的付款信息。

9.根据权利要求8所述的拼车方法，其特征在于，在拼车行程结束后，第一乘客端对应的账户接收服务端返回的剩余费用，所述剩余费用为服务端计算实际费用后并将实际费用从押金中扣除后所得。

10.一种服务端，其特征在于，包括：

接收单元，用于接收第一乘客端发来的拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息；

所述接收单元还用于接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有第二乘客端的用户信息；

所述接收单元还用于接收第一乘客端发来的反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见；

待拼车订单生成单元，用于根据拼车发起请求生成待拼车订单，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息；

拼车订单生成单元，用于根据第一乘客端发来的反馈信息生成本次拼车的拼车订单，所述拼车订单包括第一乘客端的用户信息、第二乘客端的用户信息、线路信息、时间信息，第二乘客端的用户和第一乘客端的用户拼车成功；

发送单元，用于将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述发送单元还用于将拼车响应请求发送至第一乘客端，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车。

11.根据权利要求10所述的服务端，其特征在于，所述接收单元还用于接收第二乘客端发来的打车请求，所述打车请求中包含有线路信息、时间信息；

所述发送单元还用于将包含是否接受拼车的确认请求发送至第二乘客端；

所述接收单元还用于接收第二乘客端发来的针对确认请求的返回信息；

当第二乘客端的返回信息为接受拼车时，所述发送单元将与打车请求相匹配的待拼车订单发送至第二乘客端。

12.根据权利要求10所述的服务端，其特征在于，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，待拼车订单生成单元根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

13.根据权利要求10所述的服务端，其特征在于，还包括：

费用处理单元，根据拼车发起请求生成包含有押金信息的费用请求，根据实际行车路线及拼车人数计算拼车费用，在拼车结束时将实际费用从押金中扣除；

所述接收单元还用于接收第一乘客端和第二乘客端发来的押金支付信息；

所述发送单元还用于将费用请求发送至拼车成功的第一乘客端和第二乘客端，将押金扣除实际费用后的剩余费用发送至第一乘客端和第二乘客端。

14.一种乘客端，其特征在于包括：

发送单元，向服务端发送拼车发起请求，所述拼车发起请求中携带有线路信息、时间信息，使得服务端根据拼车发起请求生成待拼车订单，并将待拼车订单发送至第二乘客端，使得第二乘客端用户确定是否加入拼车，所述待拼车订单中包含有第一乘客端的用户的信息、线路信息、时间信息，当第二乘客端用户确定加入拼车时，服务端接收第二乘客端发来的拼车响应请求，所述拼车响应请求中包含有用户信息；

所述发送单元还用于向服务端发送反馈信息，所述反馈信息为第一乘客端用户针对第二乘客端的拼车响应请求的反馈意见，若反馈信息为同意，则第二乘客端用户与第一乘客端用户拼车成功；

接收单元，接收服务端发来的拼车响应请求，以便第一乘客端的用户确定是否同意第二乘客端用户加入拼车。

15.根据权利要求14所述的乘客端，其特征在于，

所述接收单元还用于接收服务端发来的费用请求，所述费用请求由服务端根据拼车发起请求生成，其中包含有押金信息；

所述接收单元还用于接收服务端发来的剩余费用，所述剩余费用为服务端根据实际行车路线及拼车人数计算拼车费用，并在拼车结束时将实际费用从押金中扣除所得；

押金支付信息生成单元，用于根据服务端发来的费用请求生成包含身份标识的押金支付信息，

所述发送单元还用于向服务端发送押金支付信息。

16.一种乘客端，其特征在于包括：

接收单元，用于接收服务端发来的待拼车订单，以使得所述乘客端对应的用户确定是否加入拼车，所述待拼车订单由服务端根据拼车发起请求生成，所述拼车发起请求由第一乘客端发送至服务端，所述拼车发起请求中携带有第一乘客端用户制定的线路信息、时间信息；

发送单元，用于向服务端发送拼车响应请求，所述拼车响应请求中包含有所述乘客端的用户信息。

17.根据权利要求16所述的乘客端，其特征在于，所述拼车发起请求中携带有对拼车人数的限制信息，所述拼车响应请求中携带有实际乘车人信息，所述实际乘车人信息包括乘车人个数、性别信息，服务端根据第一乘客端的反馈信息，更新待拼车订单，当实际拼车人数达到拼车发起请求中的限制个数时，完成拼车。

18.根据权利要求16所述的乘客端，其特征在于，所述接收单元还用于接收服务端发来的费用请求，所述费用请求由服务端根据拼车发起请求生成，其中包含有押金信息；

所述接收单元还用于接收服务端发来的剩余费用，所述剩余费用为服务端根据实际行车路线及拼车人数计算拼车费用，并在拼车结束时将实际费用从押金中扣除所得；

押金支付信息生成单元，用于根据服务端发来的费用请求生成包含身份标识的押金支付信息，

所述发送单元还用于向服务端发送押金支付信息。