本发明涉及共享车辆领域，特别是一种用于共享车辆的调度方法与服务器。
背景技术：
由于互联网的发展，信息互通资源共享，利益互送已成为之势所趋。目前，基于互联网技术的共享单车、共享汽车已为人们的交通和出行带来了很大的便利，但同时也带来了许多问题。比如共享单车乱停放问题，已经成为现代城市的一大乱象。对于共享车辆运营商而言，为解决车辆乱停乱放问题，需组建专门的运管人员对车辆进行重新摆放，以期整齐统一，不影响市容，这是一笔可观的成本投入，增加了运营成本。
共享车辆使用后，停放地点的不规律和不均衡也导致各种问题：偏僻地段的出行人员因车辆少会导致用车难问题，而某些地段车辆过于富裕又会导致资源利用率很低。对于运营商而言，这就意味着品牌损失和用户流失。为此，运营商还需组建专门的移车队伍，每晚根据统计的车辆使用信息数据，将车辆进行重新布局，将合适数量的车辆运到合适的地点，例如，晚上将大量车辆转移到地铁站、公交站等地点。这种管理成本、人力成本和移运成本也是很高的。
现在的共享车辆的使用方法都是利用个人终端登录运营平台，搜索起点附近的车辆，然后移动去寻找合适的车辆后，扫码开锁使用，达到用车终点位置后，结束用车服务。由于整个共享车辆的规则均以使用者为核心、运营商将车辆投放市场后，车辆在使用过程中的起点和终点均无法有效控制，不仅影响了车辆的使用效率，增加了运营成本，还影响了服务的客户感受。
例如：部分使用者为了方便自己骑乘，在停放时将车座拆卸下来或者加锁，使其他使用者无法使用。又如：急需使用的使用者有时无法就近找到共享单车，或者虽然找到若干个共享单车，却发现由于上述原因，有一些单车无法使用，另一些在扫描后提示车辆故障，因此需要花费大量时间才找到一辆能够骑乘的共享单车。上述情况都极大的损伤了使用者的使用体验。
上述各种问题，究其原因是没有合理调整用车人如何结束用车或用车结束的习惯、地点已经即将用车之人如何开始用车的问题，如果能将即将结束用车之人的终点和即将开始用车之人的起点关联起来，将会给共享车辆的领域带来革命性的变化。
技术实现要素：
本发明的目的是提供一种用于共享车辆的调度方法与服务器，用以解决共享单车利用率低的问题。
为实现上述目的，本发明的方案包括：
一种用于共享车辆的调度方法，步骤如下：用车人向服务器发送用车请求，所述用车请求包含用车起点位置的信息；所述用车起点位置为用车人所在位置或者用车人指定的位置；服务器在接收到上述用车请求后，在抢单人群体中广播该用车请求，邀请抢单；服务器在接收到抢单人的抢单确认信息后，停止广播，并且转发给用车人抢单确认信息；服务器检测到抢单人将车辆转移到所述用车起点位置后，给予抢单人相应的奖励。
进一步的，在所述用车起点位置周围的设定范围内广播所述用车请求。
进一步的，所述用车请求分为立即用车请求和预约用车请求，所述预约用车请求还包括预约用车时间的信息。
进一步的，服务器转发所述抢单人接受请求的信息时，还增加包括抢单人实时位置和预计达到用车起点位置的时间的信息。
进一步的，用车人接收到服务器转发的抢单确认信息后，由用车人进行接受确认，并且向服务器返回接受确认信息；服务器接收到所述返回的接受确认信息后，才停止广播用车请求。
进一步的，在抢单人将车辆转移到所述用车起点位置后，服务器向用车人推送消息以进行提醒。
进一步的，所述奖励包括：红包奖励和积分奖励。
进一步的，服务器接收到超过一个抢单人的抢单确认信息时，由用车人选择或者由服务器进行仲裁以选中其中一个抢单人。
进一步的，所述仲裁的依据包括抢单人请求时刻、抢单人当前位置与用车起点位置距离、以及抢单人的相关历史信息。
本发明还提供用于共享车辆的服务器的方案，包括：包括处理器和存储器，所述存储器用于执行存储于存储器中的指令以实现如下方法：在接收到用车人的用车请求后，在抢单人群体中广播该用车请求，邀请抢单；所述用车请求包含用车起点位置的信息；所述用车起点位置为用车人所在位置或者用车人指定的位置；在接收到抢单人的抢单确认信息后，停止广播，并且转发给用车人抢单确认信息；检测到用车人抢单人将车辆转移到所述用车起点位置后，给予抢单人相应的奖励。
进一步的，在所述用车起点位置周围的设定范围内广播所述用车请求。
进一步的，所述用车请求分为立即用车请求和预约用车请求，所述预约用车请求还包括预约用车时间的信息。
进一步的，服务器转发所述抢单人接受请求的信息时，还增加包括抢单人实时位置和预计达到用车起点位置的时间的信息。
进一步的，用车人接收到服务器转发的抢单确认信息后，由用车人进行接受确认，并且向服务器返回接受确认信息；服务器接收到所述返回的接受确认信息后，才停止广播用车请求。
进一步的，在抢单人将车辆转移到所述用车起点位置后，服务器向用车人推送消息以进行提醒。
进一步的，所述奖励包括：红包奖励和积分奖励。
进一步的，服务器接收到超过一个抢单人的抢单确认信息时，由用车人选择或者由服务器进行仲裁以选中其中一个抢单人。
进一步的，所述仲裁的依据包括抢单人请求时刻、抢单人当前位置与用车起点位置距离、以及抢单人的相关历史信息。
本发明增加了奖励机制，能够激励正在用车（也包括不用车）的用户将车辆行至用车人要求的用车起点位置，从而大大提高的车辆的运转效率，避免了车辆的乱停乱发，进而可以节省共享车辆运营公司大量的车辆维护、转移的管理成本和人力成本。而且从用车人的角度来看，车辆是抢单人送来的，因此其故障的几率极小，用车人就能够及时用到一辆可以使用的车辆，而不需要去寻找车辆，也避免了连续扫描却总是扫描到故障车辆的尴尬情况，提升了用户体验。
附图说明
图1是实施例1的调度过程示意图；
图2是不经过a用户确认方式的调度过程示意图；
图3是实施例2的调度过程示意图。
具体实施方式
下面结合附图对本发明做进一步详细的说明。
下面实施例中，涉及用车人和抢单人，用车人和抢单人并不是指某个自然人，而是指注册用户的终端设备，例如：下面实施例中a用户终端作为用车人，b用户终端、c用户终端和d用户终端作为抢单人群体。
实施例1
a用户终端为用车人，其向服务器发送用车请求。用车请求包含用车起点位置的信息，该用车起点位置可以是a用户所在位置，也可以是a用户所设定的位置。a用户所在位置可以由a用户终端上用于定位的应用/服务获取。a用户所设定的位置可以是具体的位置也可以是某个区域。
服务器在接收到上述用车请求后，开始广播该用车请求，其广播的范围可以是对所有注册用户，也可以是在一定的范围内广播，例如，将上述用车起点位置方圆5公里以内确定为要进行广播的范围，向处于这一范围以内的注册用户的终端发送上述用车请求。如图1所示，向b、c、d用户的终端发送上述用车请求，邀请他们进行抢单，他们可以在各自终端上进行抢单操作。
b、c、d用户接收到上述用车请求后，根据自身的情况进行判断。例如，c用户（c用户可以正在用车中，也可以不在用车）与上述用车起点位置较近，则c用户可以选择接受上述用车请求，进行抢单确认，c用户的终端向服务器返回接受请求。
服务器在接收到c用户抢单确认信息后，向a用户的终端转发该抢单确认信息。转发时，可以直接转发，也可以经过处理后再进行转发，例如，增加一些信息，这些信息包括但不限于：c用户实时位置、预计达到用车起点位置时间等等。
a用户的终端接收到服务器转发的c用户抢单确认信息后，进行接受确认的操作，并且向服务器返回接受确认信息。
服务器接收到上述接受确认信息后，停止广播。通知c用户，向用户终端发送信息，请c用户履行上述用车请求。
例如c用户将所骑单车x骑到用车起点位置，进行还车操作后，可以自行离开（为了安全考虑，c用户自行离开可以避免c用户与a用户见面）。在c用户还车后，服务器检测到单车x达到用车起点位置，则可以向a用户的终端推送消息以进行提醒。
由于单车x刚刚结束了一次行程，因此其发生故障的几率是很低的，因此a用户能够迅速扫码使用。a用户在成功用车后，a用户的终端向服务器发送成功用车的信息。a用户成功用车，是指a用户的终端成功解锁了放在用车起点位置的单车x，且该信息被服务器检测到。
同时，服务器给予c用户一定的奖励，奖励的形式包括但不限于：给予红包奖励或积分奖励，所谓红包和积分奖励也可以是给予c用户当次用车费用一定的减免等。所述积分可以是一个“成就值”，专用于表示进行抢单确认操作的次数，进行抢单确认操作的次数越多，该“成就值”越高。
对c用户奖励的时机除了在a成功用车后，也可以在c用户将车辆转移到用车起点位置后，还可以在c用户抢单确认后提前预支部分奖励，在a用户成功用车后，再给予另一部分奖励，若c用户最终未将车辆转移到用车起点位置则取消上述预支奖励。
一种情况是，c用户抢单确认时，如果b、d用户也进行了抢单确认。这时就需要由a用户进行选择或者启动仲裁机制以选中其中一个用户。
a用户进行选择，即通过接受确认操作进行选择。若c用户最终被选中，则告知b、d用户，他们的抢单确认操作无效（还可以附加无效的理由：已被他人先接受）。
服务器进行仲裁的情况，仲裁的依据可以是：b、c、d用户抢单确认操作的时刻，b、c、d用户当前位置与用车起点位置的距离，b、c、d用户的相关历史信息（比如上述“成就值”）等等，抢单确认操作的时刻越早、与用车起点位置距离越近、“成就值”越高，则越优先被选中。采用这种方式，可以省略图1中a用户进行确认的步骤，如图2所示，直接由服务器通知广播范围内的用户，a用户的用车请求已经被接受。
实施例2
实施例1中，用车人的用车请求是一种立即用车请求，要求立即用车，实施例2提供一种预约用车的例子。相比实施例1，用车人发送的用车请求不是立即用车的请求，而是在预约用车请求，具体的：
a用户终端向服务器发送预约用车请求。预约用车请求包含用车起点位置信息和预约用车时间的信息，该用车起点位置可以是a用户所在位置，也可以是a用户所设定的位置。a用户所在位置可以由a用户的终端上用于定位的应用/服务获取。a用户所设定的位置可以是具体的位置也可以是某个区域。
服务器在接收到上述预约用车请求后，开始广播该预约用车请求。其广播的范围可以是所有注册用户，也可以是在一定的范围内广播。如图3所示，向b、c、d用户的终端发送上述预约用车请求。b、c、d可以是正在用车的用户，也可以是不在用车的用户。
b、c、d用户终端接收到上述预约用车请求后，根据自身的情况进行判断。例如，c用户判断在预约时间之前，自己能够达到上述用车起点位置，则c用户可以选择接受上述预约用车请求，即进行抢单确认操作。c用户的终端则向服务器返回抢单确认的信息。
服务器在接收到c用户抢单确认后，向a用户终端转发该抢单确认信息。转发时，可以直接转发，也可以经过处理后再进行转发，例如，增加一些信息，包括但不限于：c用户实时位置、预计达到用车起点位置时间等等。
a用户终端接收到服务器转发的c用户抢单确认信息后，进行接受确认的操作，并且向服务器返回接受确认信息。
服务器接收到上述接受确认信息后，通知广播范围内的用户，a用户的预约用车请求已经被抢单确认。具体方式可以是：停止广播预约用车请求，并且通知c用户，向c用户终端发送信息，请c用户履行上述预约用车请求。
c用户将所骑单车x骑到用车起点位置后，还车后，可以自行离开。a用户在成功用车后，a用户的终端向服务器发送成功用车的信息。同时，服务器给予c用户一定的奖励。
关于奖励的方式、时机，以及若有多人接受预约请求时的处理方式等，均与实施例1相同，故不再赘述。
以上实施例属于共享单车的实施例。虽然本发明是由共享单车的各种问题提出的，但实际上，由于本发明的方法能够提高资源利用效率，故本发明的方法也可以用于共享汽车和共享电动车，因此，本文所称的共享车辆既包括共享单车，也包括共享汽车或共享电动车。
另外，上述实施例中所涉及的方法，由用车人、抢单人和服务器等三种设备参与，用车人和抢单人一般为手机等移动终端设备。涉及服务器的方法，如信息的接收、广播、转发等，由服务器中运行的软件完成。
以上给出了本发明涉及的具体实施方式，但本发明不局限于所描述的实施方式。在本发明给出的思路下，采用对本领域技术人员而言容易想到的方式对上述实施例中的技术手段进行变换、替换、修改，并且起到的作用与本发明中的相应技术手段基本相同、实现的发明目的也基本相同，这样形成的技术方案是对上述实施例进行微调形成的，这种技术方案仍落入本发明的保护范围内。