专利名称：一种基于lbs出租车预约系统与方法
技术领域：
本申请涉及信息技术领域，特别涉及一种出租车预约系统与方法。
背景技术：
随着科学技术的迅猛发展，信息技术越来越多地深入到人们的日常工作生活之中，利用信息技术解决各种现实问题成为信息技术发展的ー种重要方向。比如，逐渐兴起的物联网技术、云技术、智能监控识别技术等，便是这种趋势的体现。基于位置的服务(Location Based Service, LBS),它是通过电信移动运营商的无线电通讯网络，夕卜部定位方式(如GPS)获取移动终端用户的位置信息,在GIS (GeographicInformation System,地理信息系统)平台的支持下，为用户提供相应服务的ー种增值业 务。出租车作为城市交通系统中的重要公共工具，为人们提供便捷、舒适的出行服务。在出租车行业，出行人打的有许多问题在高峰期打的难，偏远地方出租车少。有时看着一辆空出租车开过，而自己只有干瞪眼继续等。许多出租车也不愿意跑偏远地方，ー是路线不熟悉，ニ是许多时候要空车回来。这降低了城市出租车利用率，同时出行人的时间也被浪费。人们在需要搭乘出租车时，需要在路边等待，当有空出租车驶过时，才可招车搭乘。为了解决行人电话招车的需求(约租服务)，目前在中国应用最多的集群式出租车电招系统当行人有招车需求时，通过打电话到调度中心。调度员通过系统GPS定位到行人周围的空车，并将需求信息向他们转达，出租车司机收到预约请求后，通过系统抢答的方式来接受预约。预约成功后，调度员再答复客户预约成功及预约出租车信息。对出租车公司而言，需要大量的客户人员和设备投资。而通过调度中心的出租车调度效率低，一般成功预约都要花上几分钟。这套系统在全国推广困难的另一重要原因是“诚信问題”。在很多城市，要么是提供约租服务的出租车司机到达预约地点后发现乘客已不在，要么则是消费者所叫车辆迟迟不能到达。前者的发生，常常是因为消费者在叫车之后的候车时间里遇到了巡游的空车，于是便打车走人；后者则常常是因为被叫车辆在途中遇到拦车乘客，于是便改道拉活Jl.在北京，作为中介机构的北京出租车调度中心，虽然吸纳了近30000辆出租车的加盟，但是目前其日均业务量仅为1000次左右，究其原因，主要也是乘客与司机相互之间的“爽約”。可见，目前约租市场中的诚信问题是行业发展过程中遇到的较为严重的障碍。就目前来看，我国各城市出租车所提供的各类服务中，约租服务的比重还很低，远不及英国、挪威、瑞典等国家。这种方式虽能解决搭乘者的等车之苦，但是，出租车中心通常不会保留大量的空车等待搭乗者的预约，如果搭乘者没有提前几个小时或者几天预约，其调度过程通常仅会在搭乗者所在点附件的空出租车中优化安排。由于出租车的特殊性，这样的调度并不能保证搭乘者即时获得出租车，打的难问题仍然困扰着出行人。此外出租车公司为满足电话预约的需求，需要投入大量客户人员和财力。
发明内容
为解决上述技术问题，本申请实施例提供一种基于LBS出租车预约方法，以解决现有技术不能即时预约出租车的问题，从而提高搭乘者搭乘出租车的效率。本申请实施例提供的出租车预约方法适用于包含移动客户端、设置于出租车上的车载客户端以及中心服务器的系统，该方法包括移动客户端向中心服务器发送请 求信息，以获取预设范围内出租车的出租车信息，所述出租车信息包括车载客状态，所述载客状态由车载客户端在载客状态发生变化后向中心服务器提供；移动客户端选定载客状态为空的出租车，并向该出租车的车载客户端发送搭乘请求信息；移动客户端接收该出租车车载客户端返回的应答信息以实现出租车即时预约；中心服务器为移动客服端和车载客户端提供双方地图坐标信息和时间信息，并判断移动客户端和车载客户端的握手情况。优选地，所述出租车信息还包括出租车与移动客户端的地图坐标信息及移动方向信息，则移动客户端先选定载客状态为空的出租车，再向车其发送搭乘请求信息。优选地，所述出搭乘请求信息包括当前移动客户端的地图坐标信息、预订等待位置和预订等待时间。优选地，车载的应答信息分为车载客户端同意搭乘请求的信息和拒绝搭乘请求，其同意搭乘请求的信息包括预约码、预约出租车车牌号、预订等待地和预订等待时间，其中预约码用于搭乘请求用户搭乘预约出租车时在车载客户端上输入以实现移动客户端和车载客户端的握手。优选地，所述方法还包括移动终端向选定的出租车的车载客户端发送搭乘请求信息后开始计时，则移动客户端在预设时间到来时未收到该出租车车载客户端的应答确认信息，中心服务器向移动客户端反馈搭乘请求失败信息，移动客户端可通过中心服务器向其他载客状态为空的出租车重新发送搭乘请求信息。优选地，所述方法还包括移动终端向选定的出租车的车载客户端发送搭乘请求信息后开始计时，则移动客户端在预设时间到来时未收到该出租车车载客户端的应答信息，移动客户端向中心服务器重新发送请求信息。优选地，所述方法还包括在移动客户端接收到出租车车载客户端的应答确认信息后，出租车车载客户端不接收新的搭乘请求信息，中心服务器向移动客户端和出租车车载客户端实时提供移动客户端和出租车车载客户端地图位置信息与移动方向信息。本申请实施例还提供了一种出租车预约系统。该系统包括移动客户端、设置于出租车上的车载客户端以及中心服务器。出租车预约系统中，所述移动客户端包括第一发送单元、第一接收单元、选定单元、定位单元和显示单元，其中所述第一发送单元，用于向中心服务器发送请求信息，还用于向选定的出租车的车载客户端发送搭乘请求信息；所述选定単元，用于从第一接收单元接收的预设范围内的出租车信息中选定载客状态为空的出租车；所述第一接收单元，用于从中心服务器接收预设范围内出租车的出租车信息，还用于接收选定单元选定的出租车车载客户端的应答信息；所述第一定位単元，用于确定当前移动客户端的地图坐标信息和移动方向；所述第一显示单元，用于显示从第一接收单元送来的预设范围内出租车的出租车信息、出租车的车载客户端的应答信息、载客状态为空的出租车的车载客户端地图位置信息和移动方向、移动客户端自己的地图信息和移动方向、移动客户端与车载客户端到达预订等待地的路线。出租车预约系统中，所述设置于出租车上的车载客户端包括第二发送单元、第二接收单元、应答送単元、第二定位単元和第二显示单元，其中 所述第二发送单元，用于发送当前出租车地图位置信息、行驶方向和载客状态；所述第二接收单元，用于接收中心服务器传来的用户搭乘请求信息；所述应答单元用于应答移动客户端送来的请求信息；所述第二定位単元，用于确定当前车载客户端的地图坐标信息和移动方向；所述第二显示单元，用于显示出租车车载客户端自己的地图位置信息和移动方向、发起搭乘请求的移动客户端地图位置信息和移动方向、移动客户端与车载客户端到达预订等待地的路线。出租车预约系统中，中心服务器包括第三发送单元、第三接收单元、数据存储単元和判断単元，其中所述第三发送单元，用于向移动客户端发送预设范围内载客状态为空的出租车地图位置信息与移动方向、向移动客户端发送车载客户端传来的搭乘应答信息、向出租车的车载客户端发送移动客服端的搭乘请求及其地图位置信息和移动方向；所述第三接收单元，用于接收移动客户端搭乘请求信息、接收移动客户端的地图位置信息和移动方向、接收车载客户端传来的搭乘应答信息、接收收车载客户端的地图位置信息和移动方向、接受车载客户端载客状态及其改变时间；所述数据存储单元，用于存储车载客户端载客状态及其改变时间和地图位置信息、存储车载客户端应答搭乘请求的时间、存储移动客户端的地图位置信息和发起搭乘请求的时间；所述判断単元，用于根据存储单元存储的数据判断移动客户端和车载客户端的握手情况、移动客户端和车载客户端谁先失约。优选地，所述判断单元进行搭乘请求用户和出租车握手的判断方法为搭乘请求用户搭乘预约出租车时在车载客户端上输入了预约码，否则判断单元进行搭乘请求用户和出租车谁先失约的判断方法为出租车先失约的判断在预订等待时间内出租车未到到达预订等待地范围且搭乘请求用户在等待地范围内、或者在预订等待时间内出租车驶离预订等待地比搭乘请求用户先离开预订等待地范围、或者在预订等待时间内出租车状态为载客比搭乘请求用户离开预订等待地范围先出现；搭乘请求用户失约的判断方法为在预订等待时间内搭乘请求用户未到到达预订等待地范围且出租车在等待地范围内、或者在预订等待时间内搭乘请求用户离开预订等待地范围比出租车先离开预订等待地范围、或者在预订等待时间内行人离开等待地比出租车状态为载客先出现。本申请实施例在包含移动客户端、出租车车载客户端以及中心服务器的系统中，由移动终端向中心服务器发送请求信息以获取预设范围内的出租车信息，然后从中心服务器返回的出租车信息中选定出租车，移动终端向该出租车的车载客户端发送搭乘请求信息，在接收到出租车车载客户端的应答信息后实现即时预约。与现有技术相比，本申请实施例的移动客户端可根据自己的需要随时发起出租车预约，由于中心服务器通过车载客户端提供的载客状态信息即时掌握了预设范围内出租车的状态，保证了移动客户端即时获得出租车信息，从中选定出租车实现即时预约，由此避免了长时间的等待，从而提高了预约出租车的效率。
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的ー些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。 图I为本申请实施例的出租车预约方法流程图；图2为图I所述实施例的应用系统场景图；图3为本申请实施例的出租车即时预约系统的结构框图。
具体实施例方式为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式
对本申请作进一步详细的说明。參见图1，该图示出了本申请实施例的出租车预约方法的流程图。本实施例的方法适用于包含移动客户端、设置于出租车上的车载客户端以及中心服务器的系统，其步骤包括步骤SlOl :移动客户端向中心服务器发送请求信息，以获取预设范围内出租车信息，所述出租车信息包括出租车载客状态，所述载客状态由出租车车载客户端在载客状态发生变化时向中心服务器提供；移动客户端是预约出租车的发起端，它可以是人们常用的移动终端，比如手机、IPAD等，也可以是其他嵌入有本申请实施例所述功能的其他硬件设备。移动客户端如果需要预约出租车，可向中心服务器发送请求信息以获取预设范围内出租车信息，该请求信息根据移动客户端的需要可包含不同的内容，比如移动客户端所在地位置、预约出租车所在出租车公司、预约时间等，但通常情况下，应当包含出租车的载客状态。中心服务器是出租车信息的“集合地”，它包含了其可管理控制的出租车的全部信息，该信息可以是出租车车牌号、司机姓名、联系方式等静态信息，也可以是出租车载客状态、出租车当前所在位置等动态信息，该管理中心可根据移动客户端的请求信息的内容返回相应的出租车信息。中心服务器的静态信息可事先进行登记，动态信息可通过设置于出租车上的车载客户端在信息发生变化时实时或周期性的提供。比如，对于出租车的当前位置信息，可设定出租车车载客户端每隔几秒后向中心服务器发送位移状态，对于出租车载客状态，可设定出租车车载客户端在监测到出租车状态发生变化后向中心服务器发送变化后的状态。值得注意的是本步骤中的预设范围内的出租车信息可以是预设地理范围内的出租车的信息，比如预设以移动终端为中心，I千米为半径的圆范围内的出租车信息，也可以是预设公司范围内的出租车信息，比如，某客户长期乘坐某出租车公司的出租车，认为该出租车公司的服务较好，其可指定获取该出租车公司的出租车的信息，或者，将上述两个范围结合起来，设定需要获取的出租车信息为预设出租车公司范围内的在移动终端一定地理距离内的出租车信息。在实际应用中，中心服务器可通过解析移动客户端中的请求信息，了解移动终端的具体需求，然后根据其需求向移动客户端提供出租车信息。 步骤S102 :移动客户端选定载客状态为空的出租车，并向该出租车车载客户端发送搭乘请求信息；移动客户端从中心服务器获得满足自身要求的出租车信息后，可从返回的信息中选定ー个载客状态为空的出租车，作为待搭乘的候选出租车。在实际应用过程中，载客状态是移动客户端选择待搭乘出租车的必要考虑因素之一，除此之外，移动客户端还可以考虑出租车距离移动客户端的远近、行驶方向、出租车的信誉状态、出租车司机的驾龄情况等。比如，在考虑出租车距离移动客户端远近的情况下，移动客户端可选择载客状态为空且距离移动終端最近的出租车作为候选出租车。值得注意的是中心服务器向移动终端返回出租车信息后，其在移动客户端上的具体显示形式，本申请实施例并不做任何限定，在实际应用中，可根据用户的爱好、兴趣或硬件条件选择。比如可以列表的形式显示，且按照一定要求进行排序，这样移动客户端可方便地选定候选出租车，也可以直接显示在移动客户端上的GIS地图上，直观地反映出移动終端与出租车的远近、各出租车的来向和其当前位置等。通过前述方式选定了候选出租车后，并不能确认候选出租车一定可以完成本次搭乘任务，比如，出租车车载客户端未能即时更新其载客状态，导致当前显示在移动客户端上的载客状态非最新状态，还比如，由于网络信号问题，传输到移动客户端的出租车距离信息出现错误等。为了避免这种情况的发生，使得出租车的预约准确有效，在从出租车信息中候选出出租车后，移动客户端向该出租车发送搭乘请求信息，以表明搭乘该出租车的愿望。步骤S103 :移动客户端接收出租车车载客户端的应答确认信息以实现出租车即时预约；出租车车载客户端收到移动终端的搭乘请求信息后，对该请求信息进行应答，该应答信息后可以根据车载客户端实际情况可以是同意搭乘的应答确认信息，也可以是拒绝搭乘(比如在出租车交班时间、司机吃饭时间，或者出租车出现临时坏损等情况下)的应答拒绝信息。移动客户端收到出租车车载客户端的应答确认信息后，即可实现本次出租车预约。在出租车车载客户端返回应答确认信息后，可由中心服务器或者车载客户端生成一条预约信息，发送到移动客户端，该预约信息可以包括本次预约的预约码、出租车车牌号、预约等待位置、预定等待时间以及出租车为主信息(司机姓名、电话号码、エ号、出租车型号、收费情况等)。随后，出租车可按照搭乘请求信息中提供的移动终端的地理位置、搭乘的具体时间等按时准确达到预约地点，用户按时按地搭乘出租车。步骤S104 :中心服务器为移动客服端和车载客户端提供双方地图坐标信息和时间信息，并判断移动客户端和车载客户端的握手情況。为了让出租车公司对出租车行为进行管，降低行人预约后出租车拒载行为；对出行人的行为进行一定的约束，预约后没有搭乘预约出租车的失约。系统对移动客户端和车载客户端的握手情况进行判断。行人和出租车预约的判断方法为搭乘请求用户搭乘预约出租车时在车载客户端上输入了预约码。否则判断搭乘请求用户和出租车谁先失约出租车先失约的判断在预订等待时间内出租车未到到达预订等待地范围且搭乘请求用户在等待地范围内、或者在预订等待时间内出租车驶离预订等待地比搭乘请求用户先离开预订等待地范围、或者在预订等待时间内出租车状态为载客比搭乘请求用户离开预 订等待地范围先出现；搭乘请求用户失约的判断方法为在预订等待时间内搭乘请求用户未到到达预订等待地范围且出租车在等待地范围内、或者在预订等待时间内搭乘请求用户离开预订等待地范围比出租车先离开预订等待地范围、或者在预订等待时间内行人离开等待地比出租车状态为载客先出现。根据这些判断规则，基本上可以判断出谁先失约。对于出租车的失约，其失约信息会上报公司。信誉评价对出租车司机而言，是极为重要的，不仅涉及出租车公司对他们的考核。而且，对于一个信誉评价好的出租车，在预约时都会占有一定的先机。对于出行人失约，可以制定ー些预约规则来约束行人，比如行人失约后，以后行人再次预约出租车时就需要交纳一定的预约金。本申请实施例在包含移动客户端、出租车车载客户端以及中心服务器的系统中，由移动终端向中心服务器发送请求信息，然后从中心服务器返回的出租车信息中选定出租车，移动终端向该出租车发送搭乘请求信息，在接收到出租车车载客户端的应答信息后实现即时预约。与现有技术相比，本申请实施例的移动客户端可根据自己的需要随时发起出租车预约，井能即时地得到预设范围的出租车信息，而不再需要更长时间的无所目的的等待，从而解决了现有技术的问题，提高了即时预约出租车的效率。上述实施例中移动终端向出租车车载客户端发送搭乘请求信息后，即可等待车载客户端的应答信息，但是，在某些情况下，比如网络繁忙信号未能准确达到车载客户端，移动客户端一直等待下去将不能成功实现本次出租车预约。为避免这种情况发生，移动客户端可維持一个定时器，该定时器设定ー个预设时间，在移动客户端发送搭乘请求信息后，启动该定时器进行计时，当未能在预设时间到来时收到车载客户端的应答信息，移动客户端不再等待下去，而是取消本次预约流程，向中心服务器重新发送请求信息，获取新的出租车信息，以便重新选择出租车。这里选择向中心服务器重新发送请求信息，而不是向选定的出租车重新发送搭乘请求信息，其原因是出租车的载客状态是实时变化的。即便由于网络问题导致先前选定的出租车未能正确发送应答确认信息，但当网络正常后再次发送搭乘请求信息，先前选定的出租车的状态可能已经发生了变化，这种情况下仍然可能导致出租车预约失败。前述实施例中出租车车载客户端接收到移动客户端发送的搭乘请求信息后，向移动客户端返回应答确认信息。车载客户端虽然发送了应答确认信息，但出租车的载客状态仍然为空载状态，这时该出租车的信息可能显示在别的移动客户端上供别的移动客户端选择，但实际上，该出租车已在本次预约流程中被成功预约，其必将导致其他移动客户端的预约失败，从而导致出租车预约整体效率降低。为避免这种情况，本申请实施例优选在移动客户端接收到出租车车载客户端的应答确认信息后，出租车车载客户端不接收新的搭乘请求信息。除这种不接收新的搭乘请求信息外，本申请实施例还可以选择为“已被预约单但还未载客”的状态设定ー个特殊的状态，比如“驶向等待地”、“已被预约”，然后将该特殊状态通过车载客户端向中心服务器发送状态变更信息，以便中心服务器即时更新显示在移动客户端上的出租车信息。以上实施例是对本申请方法实施例的描述，本申请还提供了出租车预约系统的实施例。參见图3，该图示出了本申请实施例四的预约系统的结构框图。本定位基站实施例包 括移动客户端301、出租车车载客户端302以及中心服务器303，其中出租车预约系统中，所述移动客户端301包括第一发送单元3011、第一接收单元3012、选定单元3013、第一定位单元3014和第一显示单元3015，其中所述第一发送单元3011，用于向中心服务器303发送请求信息，还用于向选定的出租车的车载客户端302发送搭乘请求信息；所述第一接收单元3012，用于从中心服务器303接收预设范围内出租车的出租车信息，还用于接收选定单元3013选定的出租车车载客户端302的应答信息；所述选定単元3013，用于从第一接收单元3012接收的预设范围内的出租车信息中选定载客状态为空的出租车；所述第一定位単元3014，用于确定当前移动客户端的地图坐标信息和移动方向；所述第一显示单元3015，用于显示从第一接收单元3012送来的预设范围内出租车的出租车信息、出租车的车载客户端302的应答信息、载客状态为空的出租车的车载客户端地图位置信息和移动方向、移动客户端自己的地图信息和移动方向、移动客户端与车载客户端到达预订等待地的路线。出租车预约系统中，所述设置于出租车上的车载客户端302包括第二发送单元3021、第二接收单元3022、应答送单元3023、第二定位单元3024和第二显示单元3025，其中所述第二发送单元3021，用于发送当前出租车地图位置信息、行驶方向和载客状态；所述第二接收单元，用于接收3022中心服务器303传来的用户搭乘请求信息；所述应答単元3023，用于应答移动客户端301送来的请求信息；所述第二定位単元3024，用于确定当前车载客户端302的地图坐标信息和移动方向；所述第二显示单元3025，用于显示出租车车载客户端302自己的地图位置信息和移动方向、发起搭乘请求的移动客户端地图位置信息和移动方向、移动客户端与车载客户端到达预订等待地的路线。
出租车预约系统中，所述中心服务器303包括第三发送单元3031、第三接收单元3032、数据存储单元3033和判断单元3034，其中所述第三发送单元3031，用于向移动客户端301发送预设范围内载客状态为空的出租车地图位置信息与移动方向、向移动客户端301发送车载客户端302传来的搭乘应答信息、向出租车的车载客户端302发送移动客服端301的搭乘请求及其地图位置信息和移动方向；所述第三接收单元3032，用于接收移动客户端301搭乘请求信息、接收移动客户端301的地图位置信息和移动方向、接收车载客户端302传来的搭乘应答信息、接收收车载客户端302的地图位置信息和移动方向、接受车载客户端302载客状态及其改变时间；所述数据存储单元3033，用于存储车载客户端302载客状态及其改变时间和地图位置信息、存储车载客户端302应答搭乘请求的时间、存储移动客户端301的地图位置信息和发起搭乘请求的时间；所述判断单元3034，用于根据存储单元存储3033的数据判断移动客户端301和车载客户端302的握手情况、移动客户端301和车载客户端302谁先失约。本定位基站实施例的工作过程是移动客户端301向中心服务器303发送请求信息，以获取预设范围内出租车信息；移动客户端301在获得出租车信息后从中选定载客状态为空的出租车，并向该出租车车载客户端发送搭乘请求信息；移动客户端301接收出租车车载客户端的应答信息以实现出租车即时预约。本申请系统实施例在包含移动客户端、出租车车载客户端以及中心服务器的系统中，由移动终端向中心服务器发送请求信息，然后从中心服务器返回的出租车信息中选定出租车，移动终端向该出租车发送搭乘请求信息，在接收到出租车车载客户端的应答信息后实现即时预约。与现有技术相比，本申请实施例的移动客户端可根据自己的需要随时发起出租车预约，井能即时地得到预设范围的出租车信息，而不再需要更长时间的无所目的的等待，从而解决了现有技术的问题，提高了即时预约出租车的效率。为了描述的方便，描述以上系统时以功能分为各种単元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如R0M/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相參见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处參见方法实施例的部分说明即可。以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的単元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理単元，即可以位于ー个地方，或者也可以分布到多个网络単元上。可以根据实际的需要 选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。本申请可用于众多通用或专用的计算系统环境或配置中。例如个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。以上所述仅是本申请的具体实施方式
，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。权利要求
1.一种基于LBS出租车预约方法，其特征在于，该方法适用于包含移动客户端、设置于出租车上的车载客户端以及中心服务器的系统，该方法包括 移动客户端向中心服务器发送请求信息，以获取预设范围内出租车的出租车信息，所述出租车信息包括车载客状态，所述载客状态由车载客户端在载客状态发生变化后向中心服务器提供； 移动客户端选定载客状态为空的出租车，并向该出租车的车载客户端发送搭乘请求信息； 移动客户端接收该出租车车载客户端返回的应答确认信息以实现出租车即时预约； 中心服务器为移动客服端和车载客户端提供双方地图坐标信息和时间信息，并判断移动客户端和车载客户端的握手情况。
2.根据权利要求I所述的方法，其特征在于，所述出租车信息还包括出租车与移动客户端的地图坐标信息及移动方向信息，则 移动客户端先选定载客状态为空的出租车，再向其发送搭乘请求信息。
3.根据权利要求2所述的方法，其特征在于，所述出搭乘请求信息包括当前移动客户端的地图坐标信息、预订等待位置和预订等待时间。
4.根据权利要求I所述的方法，其特征在于车载的应答信息分为车载客户端同意搭乘请求的信息和拒绝搭乘请求，其同意搭乘请求的信息包括预约码、预约出租车车牌号、预订等待地和预订等待时间，其中预约码用于搭乘请求用户搭乘预约出租车时在车载客户端上输入以实现移动客户端和车载客户端的握手。
5.根据权利要求I所述的方法，其特征在于，所述方法还包括移动终端向选定的出租车的车载客户端发送搭乘请求信息后开始计时，则 移动客户端在预设时间到来时未收到该出租车车载客户端的应答确认信息，中心服务器向移动客户端反馈搭乘请求失败信息，移动客户端可通过中心服务器向其他载客状态为空的出租车重新发送搭乘请求信息。
6.根据权利要求I所述的方法，其特征在于，所述方法还包括在移动客户端接收到出租车车载客户端的应答确认信息后，出租车车载客户端不接收新的搭乘请求信息，中心服务器向移动客户端和出租车车载客户端实时提供移动客户端和出租车车载客户端地图位置信息与移动方向信息。
7.一种基于LBS出租车预约系统，其特征在于，该系统包括移动客户端、设置于出租车上的车载客户端以及中心服务器，其中 所述移动客户端包括第一发送单元、第一接收单元、选定单元、第一定位单元和第一显示单元，其中 所述第一发送单元，用于向中心服务器发送请求信息，还用于向选定的出租车的车载客户端发送搭乘请求信息； 所述选定单元，用于从第一接收单元接收的预设范围内的出租车信息中选定载客状态为空的出租车； 所述第一接收单元，用于从中心服务器接收预设范围内出租车的出租车信息，还用于接收选定单元选定的出租车车载客户端的应答信息； 所述第一定位单元，用于确定当前移动客户端的地图坐标信息和移动方向；所述第一显示单元，用于显示从第一接收单元送来的预设范围内出租车的出租车信息、出租车的车载客户端的应答信息、载客状态为空的出租车的车载客户端地图位置信息和移动方向、移动客户端自己的地图信息和移动方向、移动客户端与车载客户端到达预订等待地的路线。
8.根据权利要求7所述的系统，其特征在于，所述设置于出租车上的车载客户端包括第二发送单元、第二接收单元、应答送单元、第二定位单元和第二显示单元，其中 所述第二发送单元，用于发送当前出租车地图位置信息、行驶方向和载客状态； 所述第二接收单元，用于接收中心服务器传来的用户搭乘请求信息； 所述应答单元，用于应答移动客户端送来的请求信息； 所述第二定位单元，用于确定当前车载客户端的地图坐标信息和移动方向； 所述第二显示单元，用于显示出租车车载客户端自己的地图位置信息和移动方向、发起搭乘请求的移动客户端地图位置信息和移动方向、移动客户端与车载客户端到达预订等待地的路线。
9.根据权利要求7所述的系统，其特征在于，所述中心服务器包括第三发送单元、第三接收单元、数据存储单元和判断单元，其中 所述第三发送单元，用于向移动客户端发送预设范围内载客状态为空的出租车地图位置信息与移动方向、向移动客户端发送车载客户端传来的搭乘应答信息、向出租车的车载客户端发送移动客服端的搭乘请求及其地图位置信息和移动方向； 所述第三接收单元，用于接收移动客户端搭乘请求信息、接收移动客户端的地图位置信息和移动方向、接收车载客户端传来的搭乘应答信息、接收收车载客户端的地图位置信息和移动方向、接受车载客户端载客状态及其改变时间； 所述数据存储单元，用于存储车载客户端载客状态及其改变时间和地图位置信息、存储车载客户端应答搭乘请求的时间、存储移动客户端的地图位置信息和发起搭乘请求的时间； 所述判断单元，用于根据存储单元存储的数据判断移动客户端和车载客户端的握手情况、移动客户端和车载客户端谁先失约。
10.根据权利要求9所述的系统，其特征在于，所述判断单元进行搭乘请求用户和出租车握手的判断方法为搭乘请求用户搭乘预约出租车时在车载客户端上输入了预约码，否则判断单元进行搭乘请求用户和出租车谁先失约的判断方法为 出租车先失约的判断在预订等待时间内出租车未到到达预订等待地范围且搭乘请求用户在等待地范围内、或者在预订等待时间内出租车驶离预订等待地比搭乘请求用户先离开预订等待地范围、或者在预订等待时间内出租车状态为载客比搭乘请求用户离开预订等待地范围先出现； 搭乘请求用户失约的判断方法为在预订等待时间内搭乘请求用户未到到达预订等待地范围且出租车在等待地范围内、或者在预订等待时间内搭乘请求用户离开预订等待地范围比出租车先离开预订等待地范围、或者在预订等待时间内行人离开等待地比出租车状态为载客先出现。
全文摘要
本申请实施例公开了一种基于LBS出租车预约系统与方法。该系统包含移动客户端、设置于出租车上的车载客户端以及中心服务器端的系统，其中心服务器端负责处理移动客户端和车载客户端的预约信息和地图位置信息。本发明的实施过程为出行人利用移动客户端搜索其周围载客状态的车载客户端；移动客户端选定载客状态为空的出租车，再向车载客户端发送预约请求信息；车载客户端应答预约请求信息；中心服务器为移动客服端和车载客户端提供双方地图坐标信息和时间信息，并判断移动客户端和车载客户端的握手情况。本申请实施例的技术方案解决了出行人打的难的问题，提高了城市出租车利用率。
文档编号G08G1/00GK102682599SQ20121018310
公开日2012年9月19日 申请日期2012年6月6日 优先权日2012年6月6日
发明者方春, 杜恒, 郭晋丞 申请人:方春, 杜恒, 郭晋丞