一种定制公交系统及定制公交线路制定方法与流程

本申请涉及定制公交技术领域，更具体地说，涉及一种定制公交系统及定制公交线路制定方法。

背景技术：

定制公交，也称商务班车，是从小区到单位，从单位到小区的一站直达式班车，具有人人有座和快速便捷的特点，从而实现引导乘客选择定制公交集体出行模式，为减缓城市交通拥堵提供了有效解决方案。定制公交班车旨在倡导绿色出行，节能减排，具有社会公共服务的性质。

现有技术中，公交集团主要通过将在普通公交线路的运行过程中发现的具有大规模客流量的站点制定为定制公交线路，或现场核实客流信息及客流规律等相关数据后进行定制公交线路的制定，然后对制定的定制公交线路进行公布。乘客通过公布的定制公交线路选择自己所需的定制公交线路并通过电话预定等方式进行乘车班次的预定，或在自己所需的定制公交线路的发车时间之前在发车地点进行等候。现有技术中的定制公交线路的制定方法的时效性不高、开线周期长，并且不能很好的反映乘客的真实乘车需求，比如有些乘客可能在搭乘定制公交线路之前还需要倒车，降低了这些乘客的用户体验。

技术实现要素：

为解决上述技术问题，本发明提供了一种定制公交系统及定制公交线路制定方法，以解决现有技术中定制公交线路的开线周期长，不能很好的反映乘客的真实乘车需求的问题。

为解决上述技术问题，本发明实施例提供了如下技术方案：

一种定制公交系统，包括：服务器和至少一个客户端；其中，

所述客户端用于向所述服务器发送出行需求指令，所述出行需求指令包括用户乘车时间、起讫地点、出行人数和身份标识；

所述服务器具有通用接口，用于统计所述出行需求指令，根据统计的所述出行需求指令判断某一线路是否满足开线条件，如果是，则将满足开线条件的线路生成为新的定制公交线路并进行公布，以供所述客户端进行查询和/或预定公布的所述定制公交线路，并在所述客户端成功预定所述定制公交线路后生成乘车标识信息发送给所述客户端；

所述通用接口用于过滤所述客户端向所述服务器发送的信息中的敏感词。

可选的，所述身份标识为手机号或公交卡号工牌编号。

可选的，所述乘车标识信息为短信乘车标识或二维码乘车标识或公交卡乘车标识或电子票样。

可选的，所述服务器还用于在将满足开线条件的线路生成为新的定制公交线路并进行公布之后向预设客户端发送开线提醒信息；

所述预设客户端为向所述服务器发送过出行需求指令，且所述出行需求指令的用户乘车时间和起讫地点符合该定制公交线路的运行时间和起讫地点的客户端。

可选的，所述服务器还用于根据所述客户端发送的出行需求指令按照预设原则对所述定制公交线路进行配车；

所述预设原则包括老乘客优先原则、先购买优先原则、多日购买优先原则和出行人数多优先原则中的至少一项。

可选的，所述客户端还用于向所述服务器发送附近班车指令，所述附近班车指令包括客户端所在位置信息；

所述服务器还用于在接收到所述附近班车指令后，根据所述客户端所在位置信息查询已公布的所有定制公交线路，并将起点或终点处于所述客户端所在位置预设范围内的定制公交线路发送给所述客户端，以供所述客户端进行查询和/或预定。

可选的，所述客户端还用于向所述服务器发送余座预订指令，所述余座预订指令包括所需定制公交线路信息和预定座位信息；

所述服务器还用于在接收到所述余座预订指令后锁定所述所需定制公交线路的预定座位，并判断客户端是否在预设时间内完成支付，如果是，则向所述客户端发送乘车标识信息；如果否，则释放锁定的预定座位。

可选的，所述客户端还用于在接收到转赠指令后，根据所述转赠指令判断指定客户端是否满足转赠条件，如果是，则根据所述转赠指令将所述乘车标识信息发送给所述指定客户端；

所述转赠指令中包括所述指定客户端的身份标识。

一种定制公交线路制定方法，应用于客户端，所述定制公交线路制定方法包括：

向所述服务器发送出行需求指令，所述出行需求指令包括用户乘车时间、起讫地点、出行人数和身份标识。

可选的，还包括：

在接收到转赠指令后，根据所述转赠指令判断指定客户端是否满足转赠条件，如果是，则根据所述转赠指令将所述乘车标识信息发送给所述指定客户端；

所述转赠指令中包括所述指定客户端的身份标识。

一种定制公交线路制定方法，应用于服务器，所述定制公交线路制定方法包括：

接收客户端发送的包括用户乘车时间、起讫地点、出行人数和身份标识的出行需求指令；

过滤所述出行需求指令中的敏感词；

统计所述出行需求指令，根据统计的所述出行需求指令判断某一线路是否满足开线条件，如果是，则将满足开线条件的线路生成为新的定制公交线路并进行公布，以供所述客户端进行查询和/或预定公布的所述定制公交线路；

在所述客户端成功预定所述定制公交线路后生成乘车标识信息发送给所述客户端。

可选的，还包括：

在将满足开线条件的线路生成为新的定制公交线路并进行公布之后向预设客户端发送开线提醒信息；

所述预设客户端为向所述服务器发送过出行需求指令，且所述出行需求指令的用户乘车时间和起讫地点符合该定制公交线路的运行时间和起讫地点的客户端。

可选的，所述将满足开线条件的线路生成为新的定制公交线路并进行公布之后还包括：

根据所述客户端发送的出行需求指令按照预设原则对所述定制公交线路进行配车；

所述预设原则包括老乘客优先原则、先购买先预定原则和订购人数多优先原则中的至少一项。

可选的，还包括：

在接收到客户端发送的附近班车指令后，根据所述客户端所在位置信息查询已公布的所有定制公交线路，并将起点处于所述客户端所在位置预设范围内的定制公交线路发送给所述客户端，以供所述客户端进行查询和/或预定；

所述附近班车指令包括客户端所在位置信息。

可选的，还包括在接收到所述客户端发送的余座预订指令后锁定所述所需定制公交线路的与出行人数相同的余座，并判断客户端是否在预设时间内完成支付，如果是，则向所述客户端发送乘车标识信息；如果否，则释放锁定的余座；

所述余座预订指令包括所需定制公交线路信息和出行人数。

从上述技术方案可以看出，本发明实施例提供了一种定制公交系统及定制公交线路制定方法，其中，所述定制公交系统包括服务器和至少一个客户端；所述客户端用于向所述服务器发送包括用户乘车时间、起讫地点、出行人数和身份标识的出行需求指令；所述服务器通过统计所述出行需求指令，根据统计的出行需求指令判断某一线路是否满足开线条件，当满足时将满足开线条件的线路生成为新的定制公交线路并进行公布，以供所述客户端进行查询和/或预定公布的所述定制公交线路，从而实现了根据用户需求进行定制公交线路的开线的目的，解决了现有技术中定制公交线路的开线周期长，不能很好的反映乘客的真实乘车需求而降低乘客对定制公交的用户体验的问题。

并且所述服务器具有用于过滤所述客户端向所述服务器发送的信息中的敏感词，以避免对所述服务器的恶意攻击，提升所述服务器的安全性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请的一个实施例提供的一种定制公交系统的结构示意图；

图2为本申请的一个实施例提供的一种定制公交系统的工作流程图；

图3为本申请的一个实施例提供的一种应用于客户端的定制公交线路制定方法的流程示意图；

图4为本申请的另一个实施例提供的一种应用于客户端的定制公交线路制定方法的流程示意图；

图5为本申请的一个实施例提供的一种应用于服务器的定制公交线路制定方法的流程示意图；

图6为本申请的另一个实施例提供的一种应用于服务器的定制公交线路制定方法的流程示意图；

图7为本申请的又一个实施例提供的一种应用于服务器的定制公交线路制定方法的流程示意图；

图8为本申请的再一个实施例提供的一种应用于服务器的定制公交线路制定方法的流程示意图；

图9为本申请的一个优选实施例提供的一种应用于服务器的定制公交线路制定方法的流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请实施例提供了一种定制公交系统，如图1和图2所示，包括：服务器200和至少一个客户端100；其中，

所述客户端100用于向所述服务器200发送出行需求指令，所述出行需求指令包括用户乘车时间、起讫地点、出行人数和身份标识；

所述服务器200具有通用接口，用于统计所述出行需求指令，根据统计的所述出行需求指令判断某一线路是否满足开线条件，如果是，则将满足开线条件的线路生成为新的定制公交线路并进行公布，以供所述客户端100进行查询和/或预定公布的所述定制公交线路，并在所述客户端100成功预定所述定制公交线路后生成乘车标识信息发送给所述客户端100；

所述通用接口用于过滤所述客户端100向所述服务器200发送的信息中的敏感词。

图1为所述定制公交系统的结构示意图；图2为所述定制公交系统的工作流程图。

需要说明的是，所述开线条件可以是某一线路不是现有的定制公交线路且根据统计的所述出行需求指令发现这一线路的总出行人数超过开线阈值。所述开线阈值可以是10或15或20，本申请并不对所述开线阈值的具体取值和取值范围进行限定，具体视实际情况而定。

所述客户端100可以是存储于电脑、手机、平板等智能电子设备中的B/S(Browser/Server，浏览器/服务器200)模式系统，也可以是C/S(Client/Server，客户机/服务器200)模式系统。本申请对所述客户端100的具体实现形式和载体并不做限定，具体视实际情况而定。

为了更清楚的对所述定制公交系统的工作流程进行说明，下面以一个具体的例子为例进行说明：

乘客可以随时通过所述客户端100向所述服务器200发送出行需求指令，所述服务器200统计所有的所述客户端100发送的出行需求指令，将能够搭乘同一条线路的出行人数累加，当同一条线路的出行人数超过开线阈值后，所述服务器200则认为该条线路满足开线条件，则将该条线路生成为新的定制公交线路进行公布，以供所述客户端100进行查询和/或预定公布的所述定制公交线路。

具体地，比如在所有的所述客户端100发送的出行需求指令中，需要在上班时间从北京天通苑到中关村，在下班时间从中关村到天通苑的出行人数累加到15人后，所述服务器200认为天通苑到中关村的线路满足开线条件，则将从天通苑到中关村的线路生成为新的定制公交线路进行公布。在从天通苑到中关村的定制公交线路公布后，所述客户端100可以通过向所述服务器200发送请求的方式进行查询和/或预定，当乘客确定需要搭乘这一定制公交线路且该条定制公交线路处于可预订状态时，向所述服务器200发送预定请求进行预定，所述预定请求中包括出现人数的身份标识，并跳转第三方支付平台进行支付，所述客户端100在规定时间内支付成功后所述第三方支付平台向所述服务器200发送支付成功信息；所述服务器200在接收到所述预定请求后，锁定该条定制公交线路的余座，并判断在规定时间内是否接收到所述支付成功信息，如果是，则向支付成功的客户端100发送乘车标识信息；如果否，则释放锁定的余座，关闭订单。所述规定时间可以是45分钟或30分钟或15分钟，本申请对所述规定时间的具体长度并不做限定，具体视实际情况而定。

还需要说明的是，所述通用接口是所述服务器200和所有的所述客户端100的统一接口，它们之间的信息传递都通过所述通用接口完成。所述通用接口用于过滤所述客户端100向所述服务器200发送的信息中的敏感词，所述敏感词包括但不限于：link、select。以避免对所述服务器200的恶意攻击，提升所述服务器200的安全性。

在本申请的一个优选实施例中，所述通用接口为Interface.php接口。所述服务器200采用同一认证方式，对于通过所述通用接口提交的信息，通过参数按照a-zA-Z的顺序组成验证字符串，再与所述客户端100的用户认证账号加密串进行连接。得到相关的加密字符串，该加密字符串以MD5加密方式进行加密，通过特定的参数sigh传输到所述通用接口。本申请对此并不做限定，在本申请的其他实施例中，所述通用接口还可以为其他种类的接口，所述加密字符串的加密方式也可以为其他方式，具体视实际情况而定。

在上述实施例的基础上，在本申请的一个实施例中，所述身份标识为手机号或公交卡或工牌编号。

需要说明的是，所述身份标识用于确定使用客户端100的乘客的身份。并且当所述手机号或工牌编号在所述服务器200已开放的定制公交线路中对应由企业定制公交线路时，所述服务器200将所述身份表示信息对应的企业定制公交线路增加到该客户端100可预订的定制公交线路中，以实现特定企业的专属公交定制。

在上述实施例的基础上，在本申请的另一个实施例中，所述乘车标识信息为短信乘车标识或二维码乘车标识或公交卡乘车标识或电子票样。

需要说明的是，所述乘车标识信息用于当乘客乘坐定制公交时出示的允许乘车的标识。当所述乘车标识信息为短信乘车标识或电子票样时，乘客需要向搭乘的定制公交的司机或乘务员出示该短信乘车标识或电子票样进行验票。当所述乘车标识信息为二维码乘车标识时，乘客需要利用搭乘的定制公交的车载验码设备对自己持有的二维码乘车标识进行验证，验证通过时表示持有该二维码乘车标识的乘客满足搭乘该定制公交的身份要求。当所述乘车标识信息为公交卡乘车标识时，乘客需要利用搭乘的定制公交的公交卡验票设备对自己载有公交卡乘车标识的公交卡进行验证，验证通过时所述公交卡验票设备发出验证成功提示，否则发出验证失败提示。

另外，当所述乘车标识信息为二维码乘车标识或公交卡乘车标识时，所述服务器200在向客户端100发送乘车标识信息时还会将乘客订单信息通过白名单系统传输至定制公交的车载验码设备和公交卡验票设备中，以实现对所述二维码乘车标识或公交卡乘车标识的验证。

在上述实施例的基础上，在本申请的又一个实施例中，所述服务器200还用于在将满足开线条件的线路生成为新的定制公交线路并进行公布之后向预设客户端100发送开线提醒信息；

所述预设客户端100为向所述服务器200发送过出行需求指令，且所述出行需求指令的用户乘车时间和起讫地点符合该定制公交线路的运行时间和起讫地点的客户端100。

在本实施例中，所述服务器200向预设客户端100发送开线提醒信息的目的是提醒满足使用这些客户端100的乘客的出行需求的定制公交已开通，以便他们及时查询和预定。

在上述实施例的基础上，在本申请的再一个实施例中，所述服务器200还用于根据所述客户端100发送的出行需求指令按照预设原则对所述定制公交线路进行配车；

所述预设原则包括老乘客优先原则、先购买优选原则、多日购买优先原则和出行人数多优先原则中的至少一项。

其中，所述老乘客优先原则是指开行周期第一天配车，所述服务器200查询上一班次的乘客信息，并于本班次乘客信息进行比对，如果存在具有相同身份标识信息的乘客，则该乘客属于老乘客，在配车时优先为其分配座位；所述先购买优选原则是指在本班次的乘客中，在配车时按照预定的先后顺序进行座位的分配；所述多日购买优先原则是指在配车时考虑本班次的乘客的预定天数，按照预定天数从高到低进行排序，优选为预定天数多的乘客分配座位；所述出行人数多优先原则是指在配车时预定本班次的客户端100的出行人数，按照出行人数从高到低进行排序，优先为出行人数多的客户端100对应的乘客进行座位的分配。

需要说明的是，由于某些定制公交线路具有多辆车，在对多辆车进行配车时，可以采用比例分配和顺序分配两种方式；其中，比例分配指根据某一定制公交线路的多练车的座位情况，按照座位比例进行分配，让乘客均匀的分配到各个车上。顺序分别指按照顺序对某一定制公交线路的多辆车进行座位分配，安排满一辆车后再安排另外一辆车。本申请对所述客户端100具体采取的配车方式并不做限定，具体视实际情况而定。

在上述实施例的基础上，在本申请的一个优选实施例中，所述客户端100还用于向所述服务器200发送附近班车指令，所述附近班车指令包括客户端100所在位置信息；

所述服务器200还用于在接收到所述附近班车指令后，根据所述客户端100所在位置信息查询已公布的所有定制公交线路，并将起点或终点(讫点)处于所述客户端100所在位置预设范围内的定制公交线路发送给所述客户端100，以供所述客户端100进行查询和/或预定。

在本实施例中，乘客还可以通过客户端100查询自己所在位置的附近班车，所述附近班车是指起点或终点处于所述客户端100所在位置预设范围内的定制公交线路。所述预设范围可以是以所述客户端100为中心，半径为预设长度的圆或边长为预设长度的正方形等。本申请对所述预设范围的形状并不做限定，具体视实际情况而定。另外，所述预设长度可以是1.5公里，也可以是1公里或0.5公里。本申请对所述预设长度的具体取值并不做限定，具体视实际情况而定。

在上述实施例的基础上，在本申请的另一个优选实施例中，所述客户端100还用于向所述服务器200发送余座预订指令，所述余座预订指令包括所需定制公交线路信息和预定座位信息；

所述服务器200还用于在接收到所述余座预订指令后锁定所述所需定制公交线路的预定座位，并判断客户端100是否在预设时间内完成支付，如果是，则向所述客户端100发送乘车标识信息；如果否，则释放锁定的预定座位。

在本实施例中，乘客不仅可以通过所述客户端100预定所需定制公交线路，还可以通过所述客户端100选取所述所需定制公交线路的余座中自己喜欢的座位。

同样的，所述预设时间与所述规定时间的作用相同，其取值可以相同也可以不同，所述预设时间可以是45分钟或30分钟或15分钟，本申请对所述预设时间的长度并不做限定，具体视实际情况而定。

在上述实施例的基础上，在本申请的又一个优选实施例中，所述客户端100还用于在接收到转赠指令后，根据所述转赠指令判断指定客户端100是否满足转赠条件，如果是，则根据所述转赠指令将所述乘车标识信息发送给所述指定客户端100；

所述转赠指令中包括所述指定客户端100的身份标识。

需要说明的是，当乘客A预定成功某一定制公交线路后可以对获取的乘车标识信息转赠给乘客B，这样乘客A就失去了乘坐这一定制公交线路的权限，而乘客B则获得了乘坐这一定制公交线路的权限。具体地，乘客A向其客户端100A输入转赠指令，客户端100A根据所述转赠指令判断指定客户端100是否满足转赠条件，如果是，则根据所述转赠指令将所述乘车标识信息发送给所述指定客户端100。在这里，所述指定客户端100为乘客B所持的客户端100B。

所述转赠条件是指所述指定客户端100是否已具备乘车标识信息的接收条件。

在上述实施例的基础上，在本申请的其他实施例中，利用所述定制公交系统还可以实现快速直达专线、高铁快巴和节假日专线的运营方式，具体包括：

快速直达专线：所述客户端100接收用户查询线路、显示乘客位置、车辆位置的信息指令；所述服务器200通过接收用户查询指令，将满足该要求的线路信息，线路位置信息进行封装，快速直达专线根据常规公交多样化出行需求，对高出行率、高下车率的站点信息进行采集，并根据成线条件进行开线。所述服务器200通过接收指挥调度平台的车辆信息，并下发到所述客户端100中显示。解决了乘客一站直达，实时查看位置，快速乘车出行的问题。

节假日专线：所述客户端100主要用来显示节假日专线线路信息情况、线路开行情况，并向所述服务器200发送用户乘车时间、出行人数和身份标识的出行需求指令；所述服务器200通过处理出行需求指令，生成乘车电子票，并下发到所述客户端100中供用户查看并乘车验票。解决了乘客节假日一站式旅游出行问题。

高铁快巴：所述客户端100主要用于显示高铁快巴线路信息情况、用户乘客时间段问题，并向所述服务器200发送用户出行时间、出行人数和身份标识的出行指令，通过车辆信息的实时位置，间歇不停的更新车辆位置信息；所述服务器200通过处理出行需求指令，生成用户出行电子车票，并下发到所述客户端100中以供用户查看并乘车验票，通过接受车辆实时位置信息，下发到所述客户端100中显示，解决了乘客高铁到家的出行需求问题。

相应的，本申请实施例还提供了一种定制公交线路制定方法，应用于客户端，如图3所示，所述定制公交线路制定方法包括：

S101：向所述服务器发送出行需求指令，所述出行需求指令包括用户乘车时间起讫地点、出行人数和身份标识。

需要说明的是，所述客户端可以是存储于电脑、手机、平板等智能电子设备中的B/S(Browser/Server，浏览器/服务器)模式系统，也可以是C/S(Client/Server，客户机/服务器)模式系统。本申请对所述客户端的具体实现形式和载体并不做限定，具体视实际情况而定。

在上述实施例的基础上，在本申请的一个优选实施例中，如图4所示，所述定制公交线路制定方法还包括：

S102：在接收到转赠指令后，根据所述转赠指令判断指定客户端是否满足转赠条件，如果是，则根据所述转赠指令将所述乘车标识信息发送给所述指定客户端；

所述转赠指令中包括所述指定客户端的身份标识。

需要说明的是，当乘客A预定成功某一定制公交线路后可以对获取的乘车标识信息转赠给乘客B，这样乘客A就失去了乘坐这一定制公交线路的权限，而乘客B则获得了乘坐这一定制公交线路的权限。具体地，乘客A向其客户端A输入转赠指令，客户端A根据所述转赠指令判断指定客户端是否满足转赠条件，如果是，则根据所述转赠指令将所述乘车标识信息发送给所述指定客户端。在这里，所述指定客户端为乘客B所持的客户端B。

所述转赠条件是指所述指定客户端是否已具备乘车标识信息的接收条件。

在上述实施例的基础上，在本申请的一个优选实施例中，所述客户端还用于向所述服务器发送附近班车指令，所述附近班车指令包括客户端所在位置信息，和用于接收服务器返回的起点或终点(讫点)处于所述客户端所在位置预设范围内的定制公交线路。

在本实施例中，乘客还可以通过客户端查询自己所在位置的附近班车，所述附近班车是指起点或终点处于所述客户端所在位置预设范围内的定制公交线路。所述预设范围可以是以所述客户端为中心，半径为预设长度的圆或边长为预设长度的正方形等。本申请对所述预设范围的形状并不做限定，具体视实际情况而定。另外，所述预设长度可以是1.5公里，也可以是1公里或0.5公里。本申请对所述预设长度的具体取值并不做限定，具体视实际情况而定。

相应的，本申请实施例还提供了一种定制公交线路制定方法，如图5所示，应用于服务器，所述定制公交线路制定方法包括：

S201：接收客户端发送的包括用户乘车时间、起讫地点、出行人数和身份标识的出行需求指令；

S202：过滤所述出行需求指令中的敏感词；

需要说明的是，步骤S202通过所述服务器的通用接口完成，所述通用接口是所述服务器和所有的所述客户端的统一接口，它们之间的信息传递都通过所述通用接口完成。所述通用接口用于过滤所述客户端向所述服务器发送的信息中的敏感词，所述敏感词包括但不限于：link、select。以避免对所述服务器的恶意攻击，提升所述服务器的安全性。

在本申请的一个优选实施例中，所述通用接口为Interface.php接口。所述服务器采用同一认证方式，对于通过所述通用接口提交的信息，通过参数按照a-zA-Z的顺序组成验证字符串，再与所述客户端的用户认证账号加密串进行连接。得到相关的加密字符串，该加密字符串以MD5加密方式进行加密，通过特定的参数sign传输到所述通用接口。本申请对此并不做限定，在本申请的其他实施例中，所述通用接口还可以为其他种类的接口，所述加密字符串的加密方式也可以为其他方式，具体视实际情况而定。

S203：统计所述出行需求指令，根据统计的所述出行需求指令判断某一线路是否满足开线条件，如果是，则将满足开线条件的线路生成为新的定制公交线路并进行公布，以供所述客户端进行查询和/或预定公布的所述定制公交线路；

S204：在所述客户端成功预定所述定制公交线路后生成乘车标识信息发送给所述客户端。

需要说明的是，所述身份标识用于确定使用客户端的乘客的身份。并且当所述手机号或工牌编号在所述服务器已开放的定制公交线路中对应由企业定制公交线路时，所述服务器将所述身份表示信息对应的企业定制公交线路增加到该客户端可预订的定制公交线路中，以实现特定企业的专属公交定制。

在上述实施例的基础上，在本申请的另一个实施例中，所述乘车标识信息为短信乘车标识或二维码乘车标识或公交卡乘车标识或电子票样。

需要说明的是，所述乘车标识信息用于当乘客乘坐定制公交时出示的允许乘车的标识。当所述乘车标识信息为短信乘车标识或电子票样时，乘客需要向搭乘的定制公交的司机或乘务员出示该短信乘车标识或电子票样进行验票。当所述乘车标识信息为二维码乘车标识时，乘客需要利用搭乘的定制公交的车载验码设备对自己持有的二维码乘车标识进行验证，验证通过时表示持有该二维码乘车标识的乘客满足搭乘该定制公交的身份要求。当所述乘车标识信息为公交卡乘车标识时，乘客需要利用搭乘的定制公交的公交卡验票设备对自己载有公交卡乘车标识的公交卡进行验证，验证通过时所述公交卡验票设备发出验证成功提示，否则发出验证失败提示。

另外，当所述乘车标识信息为二维码乘车标识或公交卡乘车标识时，所述服务器在向客户端发送乘车标识信息时还会将乘客订单信息通过白名单系统传输至定制公交的车载验码设备和公交卡验票设备中，以实现对所述二维码乘车标识或公交卡乘车标识的验证。

在上述实施例的基础上，在本申请的一个实施例中，如图6所示，所述定制公交线路制定方法还包括：

S205：在将满足开线条件的线路生成为新的定制公交线路并进行公布之后向预设客户端发送开线提醒信息；

所述预设客户端为向所述服务器发送过出行需求指令，且所述出行需求指令的用户乘车时间和起讫地点符合该定制公交线路的运行时间和起讫地点的客户端。

在本实施例中，所述服务器向预设客户端发送开线提醒信息的目的是提醒满足使用这些客户端的乘客的出行需求的定制公交已开通，以便他们及时查询和预定。

在上述实施例的基础上，在本申请的又一个实施例中，如图7所示，所述将满足开线条件的线路生成为新的定制公交线路并进行公布之后还包括：

S206：根据所述客户端发送的出行需求指令按照预设原则对所述定制公交线路进行配车；

所述预设原则包括老乘客优先原则、先购买先预定原则和订购人数多优先原则中的至少一项。

其中，所述老乘客优先原则是指开行周期第一天配车，所述服务器查询上一班次的乘客信息，并于本班次乘客信息进行比对，如果存在具有相同身份标识信息的乘客，则该乘客属于老乘客，在配车时优先为其分配座位；所述先购买优选原则是指在本班次的乘客中，在配车时按照预定的先后顺序进行座位的分配；所述多日购买优先原则是指在配车时考虑本班次的乘客的预定天数，按照预定天数从高到低进行排序，优选为预定天数多的乘客分配座位；所述出行人数多优先原则是指在配车时预定本班次的客户端的出行人数，按照出行人数从高到低进行排序，优先为出行人数多的客户端对应的乘客进行座位的分配。

需要说明的是，由于某些定制公交线路具有多辆车，在对多辆车进行配车时，可以采用比例分配和顺序分配两种方式；其中，比例分配指根据某一定制公交线路的多练车的座位情况，按照座位比例进行分配，让乘客均匀的分配到各个车上。顺序分别指按照顺序对某一定制公交线路的多辆车进行座位分配，安排满一辆车后再安排另外一辆车。本申请对所述客户端具体采取的配车方式并不做限定，具体视实际情况而定。

在上述实施例的基础上，在本申请的一个优选实施例中，如图8所示，所述定制公交线路制定方法还包括：

S207：在接收到客户端发送的附近班车指令后，根据所述客户端所在位置信息查询已公布的所有定制公交线路，并将起点处于所述客户端所在位置预设范围内的定制公交线路发送给所述客户端，以供所述客户端进行查询和/或预定；

所述附近班车指令包括客户端所在位置信息。

在本实施例中，乘客还可以通过客户端查询自己所在位置的附近班车，所述附近班车是指起点或终点处于所述客户端所在位置预设范围内的定制公交线路。所述预设范围可以是以所述客户端为中心，半径为预设长度的圆或边长为预设长度的正方形等。本申请对所述预设范围的形状并不做限定，具体视实际情况而定。另外，所述预设长度可以是1.5公里，也可以是1公里或0.5公里。本申请对所述预设长度的具体取值并不做限定，具体视实际情况而定。

在上述实施例的基础上，在本申请的另一个优选实施例中，如图9所示，所述定制公交线路制定方法还包括：

S208：在接收到所述客户端发送的余座预订指令后锁定所述所需定制公交线路的与出行人数相同的余座，并判断客户端是否在预设时间内完成支付，如果是，则向所述客户端发送乘车标识信息；如果否，则释放锁定的余座；

所述余座预订指令包括所需定制公交线路信息和出行人数。

在本实施例中，乘客不仅可以通过所述客户端预定所需定制公交线路，还可以通过所述客户端选取所述所需定制公交线路的余座中自己喜欢的座位。

同样的，所述预设时间与所述规定时间的作用相同，其取值可以相同也可以不同，所述预设时间可以是45分钟或30分钟或15分钟，本申请对所述预设时间的长度并不做限定，具体视实际情况而定。

综上所述，本申请实施例提供了一种定制公交系统及定制公交线路制定方法，其中，所述定制公交系统包括服务器和至少一个客户端；其中，所述客户端用于向所述服务器发送包括用户乘车时间、起讫地点、出行人数和身份标识的出行需求指令；所述服务器通过统计所述出行需求指令，根据统计的出行需求指令判断某一线路是否满足开线条件，当满足时将满足开线条件的线路生成为新的定制公交线路并进行公布，以供所述客户端进行查询和/或预定公布的所述定制公交线路，从而实现了根据用户需求进行定制公交线路的开线的目的，解决了现有技术中定制公交线路的开线周期长，不能很好的反映乘客的真实乘车需求而降低乘客对定制公交的用户体验的问题。

并且所述服务器具有用于过滤所述客户端向所述服务器发送的信息中的敏感词，以避免对所述服务器的恶意攻击，提升所述服务器的安全性。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。