基于附近可用车辆侦测的叫车软件监管系统以及服务器的制作方法

本发明涉及通信技术领域，特别涉及一种基于附近可用车辆侦测的叫车软件监管系统以及服务器。

背景技术：

随着智能设备的普及和移动互联网的高速发展，给人们的出行带来了极大便利。当前打车需求已经是社会各阶层人士的普遍需求，诸如由“滴滴打车”之类的打车软件解决了司机和乘客之间的信息不对称问题。

打车软件改变了传统打车方式，建立并培养出大移动互联网时代引领的用户现代 化出行方式。较比传统电话召车与路边扬招来说，打车软件的诞生更是改变了传统打车市场格局，颠覆了路边拦车概念，利用移动互联网特点，将线上与线下相融合，从打车初始阶段到下车使用线上支付车费，画出一个乘客与司机紧密相连的o2o( 线上到线下 )完美闭环，最大限度优化乘客打车体验，改变传统出租司机等客方式，让司机师傅根据乘客目的地按意愿“接单”，节约司机与乘客沟通成本，降低空驶率，最大化节省司乘双方资源与实践。

目前的打车软件在应用过程中，由于叫车人员所处位置的不同，其附近可用的车辆数量也不同，当叫车人员处于较偏僻的地点叫车时，其附近可能会没有可用车辆，为了更好的解决出行，目前的打车软件具备这样一功能：即当打车软件显示出附近无可用车辆时，叫车人员可通过加价使得打车软件通过服务器调度较远距离的车辆。然而，由于针对附近车辆的侦测是基于打车软件的服务器进行的，这样的缺陷在于：不能够有效的判断其真实性，缺少一种监管的机制。

技术实现要素：

发明目的：针对上述情况，为了克服现有技术的缺点，本发明实施例提供了一种能够针对叫车软件附近车辆侦测进行监管的基于附近可用车辆侦测的叫车软件监管系统以及服务器，能够有效解决上述背景技术中涉及的问题。

技术方案：一种基于附近可用车辆侦测的叫车软件监管系统，包括叫车终端、司机终端以及叫车软件服务器，还包括由叫车软件监督机构进行管理且分别与所述叫车终端、司机终端以及叫车软件服务器相互通信监管服务器；所述叫车终端用于在接收到所述叫车软件服务器推送的附近无可用车辆信息时获取当前位置数据并将其包裹在监管请求信息中发送给所述监管服务器；所述监管服务器用于根据监管请求信息向所述叫车软件服务器发送范围获取请求；所述叫车软件服务器用于根据范围获取请求将判断附近无可用车辆时对应的侦测范围发送给所述监管服务器；所述监管服务器还用于以所述叫车终端当前位置数据为依据判断该侦测范围内是否存在司机终端，若存在则获取司机终端的叫车软件运行状态，判断该运行状态是否对应为听单中，若是则确定叫车软件的处罚机制。

作为本发明的一种优选方式，所述监管服务器还用于向所述叫车软件服务器发送调车恢复信息；所述叫车软件服务器还用于根据调车恢复信息取消对所述叫车终端输出的附近无可用车辆信息，并将该侦测范围内的处于听单中的司机终端进行针对所述叫车终端的正常调车。

一种基于附近可用车辆侦测的叫车软件监管服务器，所述监管服务器由叫车软件监督机构进行管理且分别与叫车终端、司机终端以及叫车软件服务器相互通信；所述监管服务器包括监管请求信息接收模块、范围获取模块、司机终端侦测模块、运行状态获取模块、运行状态判断模块以及处罚机制确定模块；其中，所述监管请求信息接收模块用于接收叫车终端发送的包裹有当前位置数据的监管请求信息；所述范围获取模块用于根据监管请求信息向所述叫车软件服务器发送范围获取请求，以及接收所述叫车软件服务器发送的判断附近无可用车辆时对应的侦测范围；所述司机终端侦测模块用于以所述叫车终端当前位置数据为依据判断该侦测范围内是否存在司机终端；所述运行状态判断模块用于在所述司机终端侦测模块判断出该侦测范围内存在司机终端时，获取司机终端的叫车软件运行状态；所述运行状态判断模块用于判断该运行状态是否对应为听单中；所述处罚机制确定模块用于在所述运行状态判断模块判断该运行状态对应为听单中时，确定叫车软件的处罚机制。

作为本发明的一种优选方式，所述监管服务器还包括调车恢复信息发送模块，用于向所述叫车软件服务器发送调车恢复信息，以促使所述叫车软件服务器根据调车恢复信息取消对所述叫车终端输出的附近无可用车辆信息，并将该侦测范围内的处于听单中的司机终端进行针对所述叫车终端的正常调车。

本发明实现以下有益效果：利用监管服务器对打车软件进行有效监管，确定打车软件服务器在判断附近无可用车辆时的真实性，从而遏制打车软件恶意加价，保障乘客的利益。

附图说明

图1为本发明提供的叫车软件监管系统结构示意图；

图2为本发明提供的监管服务器结构示意图。

具体实施方式

下面结合附图和具体实施例，进一步阐明本发明。

实施例一

请参考图1，图1为本发明提供的叫车软件监管系统结构示意图。具体的，本实施例提供一种基于附近可用车辆侦测的叫车软件监管系统，包括叫车终端、司机终端以及叫车软件服务器，还包括由叫车软件监督机构进行管理且分别与所述叫车终端、司机终端以及叫车软件服务器相互通信监管服务器；所述叫车终端用于在接收到所述叫车软件服务器推送的附近无可用车辆信息时获取当前位置数据并将其包裹在监管请求信息中发送给所述监管服务器；所述监管服务器用于根据监管请求信息向所述叫车软件服务器发送范围获取请求；所述叫车软件服务器用于根据范围获取请求将判断附近无可用车辆时对应的侦测范围发送给所述监管服务器；所述监管服务器还用于以所述叫车终端当前位置数据为依据判断该侦测范围内是否存在司机终端，若存在则获取司机终端的叫车软件运行状态，判断该运行状态是否对应为听单中，若是则确定叫车软件的处罚机制。

实际应用中，当叫车终端在接收到所述叫车软件服务器推送的附近无可用车辆信息时，有两种执行方式，第一种方式，叫车用户通过操作叫车终端从而使得叫车终端获取当前位置数据并将其包裹在监管请求信息中发送给所述监管服务器；第二种方式，叫车终端自动获取当前位置数据并将其包裹在监管请求信息中发送给所述监管服务器。

例如，假设所述叫车软件服务器判断附近无可用车辆时对应的侦测范围是5平方公里，则所述叫车软件服务器根据范围获取请求将侦测范围5平方公里发送给所述监管服务器。

所述监管服务器以所述叫车终端当前位置数据为中心点向四周扩散5平方公里，判断该5平方公里范围内是否存在司机终端，若存在则获取司机终端的叫车软件运行状态，判断该运行状态是否对应为听单中，若是则得出在侦测范围内有可用车辆，即叫车终端附近有可用车辆，如此将确定叫车软件的处罚机制。相反，当判断该运行状态没有对应为听单中，而是正在接送乘客的行程中，则得出在侦测范围内无可用车辆，即叫车终端附近无可用车辆。

其中，所述监管服务器还包括调车恢复信息发送模块，用于向所述叫车软件服务器发送调车恢复信息，以促使所述叫车软件服务器根据调车恢复信息取消对所述叫车终端输出的附近无可用车辆信息，并将该侦测范围内的处于听单中的司机终端进行针对所述叫车终端的正常调车。

在此情况下，叫车用户将无需加价叫车。

实施例二

请参考图2，图2为本发明提供的叫车软件监管服务器结构示意图。具体的，本实施例提供一种基于附近可用车辆侦测的叫车软件监管服务器，所述监管服务器由叫车软件监督机构进行管理且分别与叫车终端、司机终端以及叫车软件服务器相互通信；所述监管服务器包括监管请求信息接收模块、范围获取模块、司机终端侦测模块、运行状态获取模块、运行状态判断模块以及处罚机制确定模块；其中，所述监管请求信息接收模块用于接收叫车终端发送的包裹有当前位置数据的监管请求信息；所述范围获取模块用于根据监管请求信息向所述叫车软件服务器发送范围获取请求，以及接收所述叫车软件服务器发送的判断附近无可用车辆时对应的侦测范围；所述司机终端侦测模块用于以所述叫车终端当前位置数据为依据判断该侦测范围内是否存在司机终端；所述运行状态判断模块用于在所述司机终端侦测模块判断出该侦测范围内存在司机终端时，获取司机终端的叫车软件运行状态；所述运行状态判断模块用于判断该运行状态是否对应为听单中；所述处罚机制确定模块用于在所述运行状态判断模块判断该运行状态对应为听单中时，确定叫车软件的处罚机制。

其中，所述监管服务器还包括调车恢复信息发送模块，用于向所述叫车软件服务器发送调车恢复信息，以促使所述叫车软件服务器根据调车恢复信息取消对所述叫车终端输出的附近无可用车辆信息，并将该侦测范围内的处于听单中的司机终端进行针对所述叫车终端的正常调车。

应理解，在实施例二中，上述各个模块的具体实现过程可与上述方法实施例（实施例一）的描述相对应，此处不再详细描述。

上述实施例二所提供的监管服务器，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上诉功能分配由不同的功能模块完成，即将监管服务器的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

上述实施例只为说明本发明的技术构思及特点，其目的是让熟悉该技术领域的技术人员能够了解本发明的内容并据以实施，并不能以此来限制本发明的保护范围。凡根据本发明精神实质所作出的等同变换或修饰，都应涵盖在本发明的保护范围之内。