基于特定群体的拼车方法、装置以及计算机设备与流程

本申请涉及互联网信息处理技术领域，特别是涉及一种基于特定群体的拼车方法、装置以及计算机设备。

背景技术：

目前全球汽车保有量为12亿之多，平均6个人当中就有1人拥有1辆汽车，仅中国汽车保有量在2016年底也突破了1.2亿，汽车为我们带来便利的同时也带来了一系列的问题，如：尾气排放致大气污染、噪音污染、交通拥堵、停车难、燃油大量消耗等。

虽然现阶段出现了一些网上叫车或拼车服务，使得上述问题得到了一定的缓解，也极大的方便了人们的出行需求。但是这些服务都是基于盈利的模式存在，且由于乘客的分散性和司机的随机性，导致目前的拼车服务存在极大的安全隐患。

技术实现要素：

基于此，有必要针对上述目前的拼车服务存在的安全问题，提供一种能够最大程度的保证用户安全的基于特定群体的拼车方法、装置、计算机设备和存储介质。

一种基于特定群体的拼车方法，包括：

获取用户端的拼车请求；

根据拼车请求匹配对应的行程；

对行程进行监控并判断该行程是否有效；

若确定该行程有效，则为行程对应的用户分配相应的积分奖励，其中，行程对应的用户具有相同的群体属性。

在其中一个实施例中，用户端的拼车请求包括第一用户端的空座位发布请求，其中，空座位发布请求中包括与第一用户对应的用户标识、出发地、出发时间、目的地以及空座位数量；

则根据拼车请求匹配对应的行程，包括：

获取第二用户端根据第一用户端的空座位发布请求发出的搭乘请求，其中，搭乘请求中包括与第二用户对应的第二用户标识，第一用户和第二用户具有相同的群体属性；

根据搭乘请求生成对应的行程。

在其中一个实施例中，根据拼车请求匹配对应的行程，包括：

获取第二用户端发布的搭乘请求，其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地；

根据第一用户端的空座位发布请求以及第二用户端发布的搭乘请求匹配对应的行程。

在其中一个实施例中，用户端的拼车请求包括第二用户端发布的搭乘请求，其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地；

则根据拼车请求匹配对应的行程，包括：

获取第一用户端根据第二用户端发布的搭乘请求发出的搭乘响应请求，且第一用户和第二用户具有相同的群体属性；

根据搭乘请求和搭乘响应请求生成对应的行程。

在其中一个实施例中，对行程进行监控并判断该行程是否有效，包括：

在行程期间周期性接收第一用户端以及第二用户端上传的定位信息；

若定位信息满足预设条件，则确定行程有效。

在其中一个实施例中，为行程对应的用户分配相应的奖励，包括：

为行程对应的第一用户和第二用户分别分配相应的奖励。

在其中一个实施例中，根据拼车请求匹配对应的行程之后，还包括：

向与行程对应的第一用户端和第二用户端分别返回行程匹配成功的消息。

在其中一个实施例中，还包括：

接收用户端的信息发布请求，其中，信息发布请求中包括用户标识以及待发布的信息；

根据用户标识以及待发布的信息判断信息发布请求是否合法；

若合法，则根据信息发布请求展示待发布的信息。

一种基于特定群体的拼车装置，包括：

拼车请求获取模块，用于获取用户端的拼车请求；

行程匹配模块，用于根据拼车请求匹配对应的行程；

行程有效性判断模块，用于对行程进行监控并判断该行程是否有效；

积分奖励模块，用于若确定该行程有效，则为该行程对应的用户分配相应的积分奖励，且行程对应的用户具有相同的群体属性。

一种计算机设备，包括存储器和处理器，其中，存储器存储有计算机程序，处理器执行该计算机程序时实现如上所述方法的步骤。

上述基于特定群体的拼车方法、装置以及计算机设备，通过获取用户端的拼车请求，根据拼车请求匹配对应的行程，对行程进行监控并判断行程的有效性，当确定行程有效时，则为与该行程对应的用户分配相应的积分奖励，其中，与行程对应的用户具有相同的群体属性，由于其具有一定的熟识度，从而可以最大程度的保证用户(即乘客与车主)的安全。

附图说明

图1为一个实施例中基于特定群体的拼车方法的应用环境图；

图2为一个实施例中基于特定群体的拼车方法的流程示意图；

图3为另一个实施例中基于特定群体的拼车方法的流程示意图；

图4为又一个实施例中基于特定群体的拼车方法的流程示意图；

图5为再一个实施例中基于特定群体的拼车方法的流程示意图；

图6为一个实施例中对行程进行监控并判断该行程是否有效的步骤的流程示意图；

图7为还一个实施例中基于特定群体的拼车方法的流程示意图；

图8为一个实施例中基于特定群体的拼车装置的结构框图；

图9为一个实施例中计算机设备的内部结构图。

具体实施方式

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

本申请提供的基于特定群体的拼车方法，可以应用于如图1所示的应用环境中。其中，用户端102通过网络与服务器104进行通信。当用户需要拼车时，可通过用户端102向服务器104发送拼车请求，服务器104则接收用户端发送的拼车请求，并根据拼车请求匹配对应的行程进行监控，进而判断行程是否有效，若确定行程有效，则为该行程对应的用户分配相应的积分奖励。其中，用户可以是车主，也可以是乘客，在本实施例中，每个行程对应的车主和乘客都具有相同的群体属性，即同属于某一组织或社区内具有一定关系的人员，例如可以是同一企业的员工，同一社区的居民等。

用户端102则可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑或便携式可穿戴移动设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种基于特定群体的拼车方法，以该方法应用于图1中的服务器为例进行说明，该方法可以包括以下步骤：

步骤202，获取用户端的拼车请求。

在本实施例中，当用户需要拼车时，可通过用户端向服务器发送拼车请求，服务器则接收用户端发送的拼车请求。其中，用户可以是车主，也可以是乘客，当用户是车主时，则拼车请求为空座位发布请求，可以包括与车主对应的用户标识、出发地、出发时间、目的地以及空座位数量等。当用户是乘客时，则拼车请求为搭乘请求，可以包括与乘客对应的用户标识、出发地、出发时间以及目的地等。

其中，特定群体是指同属于某一组织或社区内具有一定关系的人员，在本实施例中，车主和乘客应属于同一特定群体，即都具有相同的群体属性，例如可以是同一企业的员工，或是同一社区的居民等。

步骤204，根据拼车请求匹配对应的行程。

在本实施例中，服务器根据车主和乘客发布的拼车请求匹配对应的行程。具体可以根据拼车请求中车主方的出发地、出发时间、目的地以及乘客方的出发地、出发时间、目的地对路线进行匹配，当匹配成功后，则形成对应的行程。另外，服务器还可以根据车主方或乘客方对拼车请求的应约而形成对应的行程。

步骤206，对行程进行监控并判断该行程是否有效。

在形成对应的行程后，服务器还可以对该行程进行监控，从而判断行程是否有效。具体的，行程是否有效是指该行程是否实际发生，若通过对行程的监控确定该行程实际发生，则确定该行程有效，否则确定该行程无效。本实施例中通过对行程的有效性进行监控，从而避免人为刷单骗取积分的现象，同时，对行程的监控也极大的提高了拼车服务的安全性。

步骤208，若确定该行程有效，则为与该行程对应的用户分配相应的积分奖励。

若通过对行程的监控，确认该行程有效，则服务器为与该行程对应的用户(即车主与乘客)分别分配相应的积分作为奖励。奖励所得积分可用于兑换实物礼品，如就餐券、洗车券或是该特定群体自有品牌的产品。

需要说明的是，本实施例中与行程对应的用户(即车主与乘客)都具有相同的群体属性，例如可以是同一企业的员工，或是同一社区的居民等，由于其具有一定的熟识度，从而可以最大程度的保证乘客与车主的案全。

上述基于特定群体的拼车方法，通过获取用户端的拼车请求，根据拼车请求匹配对应的行程，对行程进行监控并判断行程的有效性，当确定行程有效时，则为与该行程对应的用户分配相应的积分奖励，其中，与行程对应的用户具有相同的群体属性，由于其具有一定的熟识度，从而可以最大程度的保证用户(即乘客与车主)的案全。

在一个实施例中，如图3所示，本实施例中以用户端的拼车请求为车主的空座位发布请求为例进行说明，包括以下步骤：

步骤302，获取第一用户端的空座位发布请求。

需要说明的是，本申请中的第一用户即为车主，第二用户即为乘客，以此定义仅为了便于理解，并不用于限定本申请。在本实施例中，空座位发布请求中包括与第一用户对应的用户标识、出发地、出发时间、目的地以及空座位数量。其中，用户标识可以是用户所在特定群体的唯一标识号，例如可以是用户的工号。

步骤304，获取第二用户端根据第一用户端的空座位发布请求发出的搭乘请求。

其中，搭乘请求中包括与第二用户对应的第二用户标识，在本实施例中，第一用户和第二用户具有相同的群体属性，例如可以是同一企业的员工，或是同一社区的居民等。当第二用户的出行意愿与第一用户的空座位发布请求相吻合时，则第二用户可以直接选择搭乘第一用户的车，即对第一用户端发出的空座位发布请求作出对应的应约，从而通过第二用户端向服务器发出搭乘请求。

步骤306，根据搭乘请求生成对应的行程。

服务器则根据第一用户端的空座位发布请求以及第二用户端对此发出的搭乘请求直接生成对应的行程，该行程包括第一用户对应的用户标识、第二用户对应的用户标识、出发地、出发时间、目的地等信息，从而便于对行程进行监控。

在一个实施例中，如图4所示，本实施例中以用户端的拼车请求为乘客的搭乘请求为例进行说明，包括以下步骤：

步骤402，获取第二用户端发布的搭乘请求。

其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地等信息。

步骤404，获取第一用户端根据第二用户端发布的搭乘请求发出的搭乘响应请求。

其中，搭乘响应请求中包括与第一用户对应的第一用户标识，在本实施例中，第一用户和第二用户具有相同的群体属性，例如可以是同一企业的员工，或是同一社区的居民等。当第一用户的出行意愿与第二用户的搭乘请求相吻合时，则第一用户可以直接选择搭载第二用户，即对第二用户端发出的搭乘请求作出对应的应约，从而通过第一用户端向服务器发出搭乘响应请求。

步骤406，根据搭乘请求和搭乘响应请求生成对应的行程。

服务器则根据第二用户端的搭乘请求以及第一用户端对此发出的搭乘响应请求直接生成对应的行程，该行程包括第一用户对应的用户标识、第二用户对应的用户标识、出发地、出发时间、目的地等信息，从而便于对行程进行监控。

在一个实施例中，如图5所示，本实施例中以用户端的拼车请求为车主的空座位发布请求为例进行说明，包括以下步骤：

步骤502，获取第一用户端的空座位发布请求。

需要说明的是，本申请中的第一用户即为车主，第二用户即为乘客，以此定义仅为了便于理解，并不用于限定本申请。在本实施例中，空座位发布请求中包括与第一用户对应的用户标识、出发地、出发时间、目的地以及空座位数量。其中，用户标识可以是用户所在特定群体的唯一标识号，例如可以是用户的工号。

步骤504，获取第二用户端发布的搭乘请求。

其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地等信息。

步骤506，根据第一用户端的空座位发布请求以及第二用户端发布的搭乘请求匹配对应的行程。

在本实施例中，服务器根据第一用户端和第二用户端分别发布的拼车请求匹配对应的行程。具体可以根据拼车请求中第一用户方的出发地、出发时间、目的地以及第二用户方的出发地、出发时间、目的地对路线进行匹配，当匹配成功后，则形成对应的行程。

在本申请实施例中，该拼车方法仅限于具有同一属性的特定群体，因此，顺路的机率较大，以将顺路的两人或多人的行程进行匹配，从而将两次甚至多次的汽车驾驶行程合并为一次，不仅减少了由于过多私家车出行带来的碳排放，实现了绿色出行的拼车。而且由于参与拼车的双方或多方属于同一特定群体，从而极大的增强了拼车的安全性，且增加了半熟人之间的沟通、交流机会，最大程度的保证了乘客和车主的安全与信任。

在本申请实施例中，当行程一旦生成，即刻生效，服务器可以向与该行程对应的车主和乘客(即第一用户端和第二用户端)分别返回行程匹配成功的消息，且车主不可拒绝搭乘。行程结束后，乘客无需支付，服务器会在确定行程有效后给予双方(即车主与乘客)对应的积分奖励，奖励所得积分可用于兑换实物礼品，如就餐券、洗车券或是该特定群体自有品牌的产品。从而将绿色的出行和环保意识带给该群体内的每个人，也将爱与支持的文化氛围得以体现。

在一个实施例中，如图6所示，对行程进行监控并判断该行程是否有效，具体可以包括如下步骤：

步骤602，在行程期间周期性接收第一用户端以及第二用户端上传的定位信息。

在本实施例中，当行程生成并开始时，服务器则对行程进行监控，具体的，服务器周期性接收第一用户端以及第二用户端在行程过程中上传的定位信息，该定位信息中包括了第一用户端或第二用户端的当前经纬度、行程的计时信息、行程的当前里程等。

步骤604，判断定位信息是否满足预设条件，若满足则确定该行程有效，执行步骤606，否则确定该行程无效，执行步骤608。

在本实施例中，服务器可以通过第一用户端以及第二用户端上传的定位信息判断该行程是否有效。具体的，服务器根据接收的定位信息判断其是否满足预设条件，例如，假设预设条件为有效的上传点不少于2个(保证行程有位移发生)、行程的最小速度不能低于10公里/小时(保证行程有真实的速度)、第一用户端与第二用户端之间的距离不能大于1公里(保证第一用户端与第二用户端的行程同时进行)等。则服务器根据接收的定位信息进行相应的判断，如果接收的定位信息满足上述条件，则确定该行程有效，否则确定该行程无效。

步骤606，则为与该行程对应的用户分配相应的积分奖励。

在一个实施例中，如果确定行程有效，则服务器还可以为行程对应的用户分配相应的积分奖励。具体的奖励规则，可以通过行程有效的次数进行调整，或根据实际需要进行设置。例如，假设车主在8：00～8：15，由出发地1至目的地2，搭载一名乘客去上班，当行程结束且有效后，则车主与乘客分别获得1积分。如果车主将一段行程分解成2部分，即8：00～8：10，搭载一名乘客a从出发地1到目的地1；在8：15～8：20，搭载另一名乘客b从目的地1到目的地2，当行程结束且有效后，则该车主可以获得2积分，乘客a和乘客b则分别可以获得1积分。

在一个实施例中，如图7所示，该拼车方法还可以包括如下步骤：

步骤702，接收用户端的信息发布请求。

在本实施例中，由于该拼车方法仅限于具有同一属性的特定群体，因此，若该特定群体有信息发布需求时，如要在群体内部发布通知、公告或自有品牌的产品推广等，则可以向服务器发送信息发布请求，其中，信息发布请求中包括用户标识以及待发布的信息。

步骤704，根据用户标识以及待发布的信息判断信息发布请求是否合法。

当然，为了对信息发布进行有效的管控，从而避免垃圾信息或无效信息的发布，因此，服务器在接收到信息发布请求时，需要审核该信息发布请求的合法性。如该信息发布请求的用户端是否具备信息发布的权限、待发布的信息内容或格式是否符合要求等，如果信息发布请求的用户端具备信息发布的权限、且待发布的信息内容及格式符合要求，则确定该信息发布请求合法，否则认为该信息发布请求不合法。

步骤706，若合法，则根据信息发布请求展示待发布的信息。

当服务器确定该信息发布请求合法时，则根据信息发布请求在客户端的预设界面展示该待发布的信息，从而实现在群体内部进行通知、公告的发布或自有品牌的产品推广等，以充分利用资源、绿色环保。

应该理解的是，虽然图2-7的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-7中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图8所示，提供了一种基于特定群体的拼车装置，包括：拼车请求获取模块801、行程匹配模块802、行程有效性判断模块803以及积分奖励模块804，其中，

拼车请求获取模块801，用于获取用户端的拼车请求；

行程匹配模块802，用于根据拼车请求匹配对应的行程；

行程有效性判断模块803，用于对行程进行监控并判断该行程是否有效；

积分奖励模块804，用于若确定行程有效，则为行程对应的用户分配相应的积分奖励，其中，行程对应的用户具有相同的群体属性。

在一个实施例中，用户端的拼车请求包括第一用户端的空座位发布请求，其中，空座位发布请求中包括与第一用户对应的用户标识、出发地、出发时间、目的地以及空座位数量；则根据拼车请求匹配对应的行程，包括：获取第二用户端根据第一用户端的空座位发布请求发出的搭乘请求，其中，搭乘请求中包括与第二用户对应的第二用户标识，第一用户和第二用户具有相同的群体属性；根据搭乘请求生成对应的行程。

在一个实施例中，根据拼车请求匹配对应的行程，包括：获取第二用户端发布的搭乘请求，其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地；根据第一用户端的空座位发布请求以及第二用户端发布的搭乘请求匹配对应的行程。

在一个实施例中，用户端的拼车请求包括第二用户端发布的搭乘请求，其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地；则根据拼车请求匹配对应的行程，包括：获取第一用户端根据第二用户端发布的搭乘请求发出的搭乘响应请求，且第一用户和第二用户具有相同的群体属性；根据搭乘请求和搭乘响应请求生成对应的行程。

在一个实施例中，对行程进行监控并判断该行程是否有效，包括：在行程期间周期性接收第一用户端以及第二用户端上传的定位信息；若定位信息满足预设条件，则确定行程有效。

在一个实施例中，为行程对应的用户分配相应的奖励，包括：为行程对应的第一用户和第二用户分别分配相应的奖励。

在一个实施例中，根据拼车请求匹配对应的行程之后，还包括：向与行程对应的第一用户端和第二用户端分别返回行程匹配成功的消息。

在一个实施例中，还包括：信息发布模块，用于接收用户端的信息发布请求，其中，信息发布请求中包括用户标识以及待发布的信息；根据用户标识以及待发布的信息判断信息发布请求是否合法；若合法，则根据信息发布请求展示待发布的信息。

关于基于特定群体的拼车装置的具体限定可以参见上文中对于基于特定群体的拼车方法的限定，在此不再赘述。上述基于特定群体的拼车装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储用户端数据以及拼车的行程数据等。该计算机设备的网络接口用于与外部的用户端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于特定群体的拼车方法。

本领域技术人员可以理解，图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取用户端的拼车请求；

根据拼车请求匹配对应的行程；

对行程进行监控并判断该行程是否有效；

若确定该行程有效，则为行程对应的用户分配相应的积分奖励，其中，行程对应的用户具有相同的群体属性。

在一个实施例中，用户端的拼车请求包括第一用户端的空座位发布请求，其中，空座位发布请求中包括与第一用户对应的用户标识、出发地、出发时间、目的地以及空座位数量；则根据拼车请求匹配对应的行程，包括：获取第二用户端根据第一用户端的空座位发布请求发出的搭乘请求，其中，搭乘请求中包括与第二用户对应的第二用户标识，第一用户和第二用户具有相同的群体属性；根据搭乘请求生成对应的行程。

在一个实施例中，根据拼车请求匹配对应的行程，包括：获取第二用户端发布的搭乘请求，其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地；根据第一用户端的空座位发布请求以及第二用户端发布的搭乘请求匹配对应的行程。

在一个实施例中，用户端的拼车请求包括第二用户端发布的搭乘请求，其中，搭乘请求中包括与第二用户对应的用户标识、出发地、出发时间以及目的地；则根据拼车请求匹配对应的行程，包括：获取第一用户端根据第二用户端发布的搭乘请求发出的搭乘响应请求，且第一用户和第二用户具有相同的群体属性；根据搭乘请求和搭乘响应请求生成对应的行程。

在一个实施例中，对行程进行监控并判断该行程是否有效，包括：在行程期间周期性接收第一用户端以及第二用户端上传的定位信息；若定位信息满足预设条件，则确定行程有效。

在一个实施例中，为行程对应的用户分配相应的奖励，包括：为行程对应的第一用户和第二用户分别分配相应的奖励。

在一个实施例中，根据拼车请求匹配对应的行程之后，还包括：向与行程对应的第一用户端和第二用户端分别返回行程匹配成功的消息。

在一个实施例中，还包括：接收用户端的信息发布请求，其中，信息发布请求中包括用户标识以及待发布的信息；根据用户标识以及待发布的信息判断信息发布请求是否合法；若合法，则根据信息发布请求展示待发布的信息。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

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

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