基于周围乘客司机侦测的叫车软件监管系统以及服务器的制作方法

本发明涉及通信技术领域，特别涉及一种基于周围乘客司机侦测的叫车软件监管系统以及服务器。

背景技术：

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

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

目前的打车软件在应用过程中，由于叫车人员所处位置的不同以及叫车时间的不同，其附近可应答司机的数量也不同，当叫车人员处于人口集中的地点叫车时，或者在出行高峰期叫车时，其周围叫车的乘客可能较多，可应答司机较少，为了更好的解决出行，目前的打车软件具备这样一功能：即当打车软件显示出周围叫车的乘客较多可应答司机较少时，叫车人员可通过增加调度费用使得打车软件通过服务器调度较远距离的车辆。然而，由于针对周围乘客司机数量的侦测是基于打车软件的服务器进行的，这样的缺陷在于：不能够有效的判断其真实性，缺少一种监管的机制。

技术实现要素：

发明目的：针对上述情况，为了克服现有技术的缺点，本发明实施例提供了一种能够针对叫车软件周围叫车乘客多可应答司机少时对应的侦测范围、侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量进行监管的基于周围乘客司机侦测的叫车软件监管系统以及服务器，能够有效解决上述背景技术中涉及的问题。

技术方案：一种基于周围乘客司机侦测的叫车软件监管系统，包括叫车终端、司机终端以及叫车软件服务器，还包括由叫车软件监督机构进行管理且分别与所述叫车终端、司机终端以及叫车软件服务器相互通信监管服务器；所述叫车终端用于在接收到所述叫车软件服务器推送的针对调取费用产生的加价信息时获取当前位置数据并将其包裹在监管请求信息中发送给所述监管服务器；所述监管服务器用于根据监管请求信息向所述叫车软件服务器发送数据获取请求，其中数据获取请求包括范围请求、范围内可用司机终端数量请求以及范围内叫车终端数量请求；所述叫车软件服务器用于根据数据获取请求将判断周围叫车乘客多可应答司机少时对应的侦测范围、侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量发送给所述监管服务器；所述监管服务器还用于判断侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值，若否则确定叫车软件的处罚机制。

作为本发明一种优选方式，所述监管服务器还用于以所述叫车终端当前位置数据为依据获取该侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量，并判断其自身获取的侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值。

作为本发明一种优选方式，所述监管服务器还用于判断其自身获取的侦测范围内的可用司机终端数量是否与所述叫车软件服务器发送的侦测范围内的可用司机终端数量对等，和／或判断其自身获取的侦测范围内的叫车终端数量是否与所述叫车软件服务器发送的侦测范围内的叫车终端数量对等。

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

一种基于周围乘客司机侦测的叫车软件监管服务器，所述监管服务器由叫车软件监督机构进行管理且分别与叫车终端、司机终端以及叫车软件服务器相互通信；所述监管服务器包括监管请求信息接收模块、数据获取模块、第一数据判断模块以及处罚机制确定模块；其中，所述监管请求信息接收模块用于接收叫车终端发送的包裹有当前位置数据的监管请求信息；所述数据获取模块用于根据监管请求信息向所述叫车软件服务器发送数据获取请求，并接收所述叫车软件服务器发送的判断周围叫车乘客多可应答司机少时对应的侦测范围、侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量，其中数据获取请求包括范围请求、范围内可用司机终端数量请求以及范围内叫车终端数量请求；所述第一数据判断模块用于判断侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值；所述处罚机制确定模块用于在所述第一数据判断模块判断侦测范围内的可用司机终端数量没有比侦测范围内的叫车终端数量低于一预设阈值时，确定叫车软件的处罚机制。

作为本发明一种优选方式，还包括数据侦测模块以及第二数据判断模块，所述数据侦测模块用于以所述叫车终端当前位置数据为依据获取该侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量；所述第二数据判断模块用于判断所述数据侦测模块获取的侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值。

作为本发明一种优选方式，还包括第三数据判断模块，用于判断所述数据侦测模块获取的侦测范围内的可用司机终端数量是否与所述叫车软件服务器发送的侦测范围内的可用司机终端数量对等，和／或判断其自身获取的侦测范围内的叫车终端数量是否与所述叫车软件服务器发送的侦测范围内的叫车终端数量对等。

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

本发明实现以下有益效果：利用监管服务器对打车软件进行有效监管，确定打车软件服务器在判断周围叫车的乘客较多可应答司机较少时的真实性，从而遏制打车软件恶意加价，保障乘客的利益。

附图说明

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

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

具体实施方式

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

请参考图1，图1为本发明提供的监管系统结构示意图。具体的，本实施例提供一种基于周围乘客司机侦测的叫车软件监管系统，包括叫车终端、司机终端以及叫车软件服务器，还包括由叫车软件监督机构进行管理且分别与所述叫车终端、司机终端以及叫车软件服务器相互通信监管服务器；所述叫车终端用于在接收到所述叫车软件服务器推送的针对调取费用产生的加价信息时获取当前位置数据并将其包裹在监管请求信息中发送给所述监管服务器；所述监管服务器用于根据监管请求信息向所述叫车软件服务器发送数据获取请求，其中数据获取请求包括范围请求、范围内可用司机终端数量请求以及范围内叫车终端数量请求；所述叫车软件服务器用于根据数据获取请求将判断周围叫车乘客多可应答司机少时对应的侦测范围、侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量发送给所述监管服务器；所述监管服务器还用于判断侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值，若否则确定叫车软件的处罚机制。

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

例如，假设所述叫车软件服务器判断周围叫车乘客多可应答司机少时对应的侦测范围为5平方公里、侦测范围内的可用司机终端数量为a，侦测范围内的叫车终端数量为b，则所述叫车软件服务器将判断周围叫车乘客多可应答司机少时对应的侦测范围为5平方公里、侦测范围内的可用司机终端数量为a，侦测范围内的叫车终端数量为b发送给所述监管服务器。

所述监管服务器根据接收到的数据判断侦测范围5平方公里内的可用司机终端数量a是否比侦测范围内的叫车终端数量b低于一预设阈值，其中预设阈值由打车软件服务商与打车软件监管部门进行联合确定，若否则得出在该侦测范围内并没有周围叫车乘客多可应答司机少，如此将确定叫车软件的处罚机制。

例如，假设预设阈值设为1，a为40，b为38，则a比b低-2，由此可得出在该侦测范围内并没有周围叫车乘客多可应答司机少。

作为本实施例的一种实施方式，所述监管服务器还用于以所述叫车终端当前位置数据为依据获取该侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量，并判断其自身获取的侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值。

具体的，设定侦测范围5平方公里时，所述监管服务器以所述叫车终端当前位置数据为中心点向四周扩散5平方公里，判断该5平方公里范围内可用司机终端数量以及叫车终端数量，并判断其自身获取的5平方公里范围内的可用司机终端数量是否比叫车终端数量低于一预设阈值，若否则将确定叫车软件的处罚机制。

作为本实施例的一种实施方式，所述监管服务器还用于判断其自身获取的侦测范围内的可用司机终端数量是否与所述叫车软件服务器发送的侦测范围内的可用司机终端数量对等，和／或判断其自身获取的侦测范围内的叫车终端数量是否与所述叫车软件服务器发送的侦测范围内的叫车终端数量对等。

例如，假设所述叫车软件服务器发送的侦测范围内的可用司机终端数量为40，所述监管服务器自身获取的侦测范围内的可用司机终端数量不是40，则将确定叫车软件的处罚机制；和／或假设所述叫车软件服务器发送的侦测范围内的叫车终端数量为38，所述监管服务器自身获取的侦测范围内的叫车终端数量不是38，则将确定叫车软件的处罚机制。

作为本实施例的一种实施方式，所述监管服务器还用于向所述叫车软件服务器发送调车恢复信息；所述叫车软件服务器还用于根据调车恢复信息取消对所述叫车终端输出的针对调取费用产生的加价信息，并将该侦测范围内的处于听单中的司机终端进行针对所述叫车终端的正常调车。

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

请参考图2，图2为本发明提供的监管服务器结构示意图。具体的，本实施例提供一种基于周围乘客司机侦测的叫车软件监管服务器，所述监管服务器由叫车软件监督机构进行管理且分别与叫车终端、司机终端以及叫车软件服务器相互通信；所述监管服务器包括监管请求信息接收模块、数据获取模块、第一数据判断模块以及处罚机制确定模块；其中，所述监管请求信息接收模块用于接收叫车终端发送的包裹有当前位置数据的监管请求信息；所述数据获取模块用于根据监管请求信息向所述叫车软件服务器发送数据获取请求，并接收所述叫车软件服务器发送的判断周围叫车乘客多可应答司机少时对应的侦测范围、侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量，其中数据获取请求包括范围请求、范围内可用司机终端数量请求以及范围内叫车终端数量请求；所述第一数据判断模块用于判断侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值；所述处罚机制确定模块用于在所述第一数据判断模块判断侦测范围内的可用司机终端数量没有比侦测范围内的叫车终端数量低于一预设阈值时，确定叫车软件的处罚机制。

其中，还包括数据侦测模块以及第二数据判断模块，所述数据侦测模块用于以所述叫车终端当前位置数据为依据获取该侦测范围内的可用司机终端数量以及侦测范围内的叫车终端数量；所述第二数据判断模块用于判断所述数据侦测模块获取的侦测范围内的可用司机终端数量是否比侦测范围内的叫车终端数量低于一预设阈值。

其中，还包括第三数据判断模块，用于判断所述数据侦测模块获取的侦测范围内的可用司机终端数量是否与所述叫车软件服务器发送的侦测范围内的可用司机终端数量对等，和／或判断其自身获取的侦测范围内的叫车终端数量是否与所述叫车软件服务器发送的侦测范围内的叫车终端数量对等。

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

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

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

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