CN108701320A - 拼车的系统和方法 - Google Patents

Abstract

一种系统可以包括：至少一个计算机可读存储介质，被配置为存储用于向用户及其联系人提供拼车请求的指令，以及与计算机可读存储介质通信的至少一个处理器，其中，当执行所述指令时，所述至少一个处理器用于：从第一乘客终端获得包括至少一个联系人的拼车请求；识别与所述至少一个联系人相关联的至少一个第二乘客终端；向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；并且获得对来自所述候选第二乘客终端所述邀请的响应，所述响应表明所述候选第二乘客终端是否接受所述拼车请求。

Description

拼车的系统和方法

交叉引用

本申请要求于2016年3月8日提交的中国申请No.201610135580.4的优先权，其内容通过引用全部包含在本文中。

技术领域

本申请涉及按需服务的系统和方法，尤其涉及用于拼车的系统和方法。

背景技术

按需服务，如出租车服务，已变得越来越受欢迎。由于个人交通服务的行程费用很高，公共交通不够方便，因此，拼车服务对司机和乘客都起着重要作用。拼车的问题在于，出于安全考虑，人们可能不希望与陌生人拼车。于是，熟人和朋友之间的拼车受到广泛欢迎并且需求量很大。

发明内容

根据本申请的示例性实施例，一种系统可包括：至少一个计算机可读存储介质、被配置为存储用于向用户及其联系人提供拼车服务的一组指令、以及与该计算机可读存储介质通信的至少一个处理器。其中当执行该组指令时，所述至少一个处理器用于：从第一乘客终端获得包括至少一个联系人的拼车请求；从与所述第一乘客终端的用户相关联的至少一个联系人中，识别至少一个第二乘客终端；向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；且从所述候选第二乘客终端获得所述邀请的响应，所述相应表明所述拼车请求是否被接受。

根据本申请的示例性实施例，一种用于向用户及其联系人提供拼车服务的方法可以包括：由计算机服务器从第一乘客终端获得包括至少一个联系人的拼车请求；由计算机服务器识别与所述至少一个联系人相关联的至少一个第二乘客终端；所述计算机服务器向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；所述计算机服务器从候选第二乘客终端获得所述邀请的响应，所述响应表明所述拼车请求是否被接受。

根据本申请的示例性实施例，一种非暂态性计算机可读介质，包括用于向用户及其联系人提供拼车服务的至少一组指令，其中当由计算机服务器的处理器执行时，至少一组指令指示处理器执行以下动作：从第一乘客终端获得包括至少一个联系人的拼车请求；识别与所述至少一个联系人相关联的至少一个第二乘客终端；向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；并且获得对来自候选第二乘客终端的邀请的响应，该响应指示所述候选第二乘客终端是否接受所述拼车请求。

根据本申请的示例性实施例，一种系统可包括至少一个计算机可读存储介质，其包括用于向用户及其联系人提供拼车服务的一组指令，以及与计算机可读存储介质通信的至少一个处理器，其中当执行该组指令时，所述至少一个处理器用于：从与第一乘客相关联的第一乘客终端获得包括第一匹配信息和第一行程起点的第一拼车请求；从与第二乘客相关的第二乘客终端获得第二拼车请求，所述第二拼车请求包括第二匹配信息和第二行程起点；当第一匹配信息与第二匹配信息匹配时，确定第一乘客和第二乘客有一个事先达成的拼车协议；根据第一拼车请求和第二拼车请求生成拼车订单；并将拼车订单的确认通知发送给第一乘客终端和第二乘客终端。

根据本申请的示例性实施例，一种用于向用户及其联系人提供拼车服务的方法可以包括；由计算机服务器从与第一乘客相关联的第一乘客终端获得包括第一匹配信息和第一行程起点的第一拼车请求；所述计算机服务器从与第二乘客相关联的第二乘客终端获取包括第二匹配信息和第二行程起点的第二拼车请求；当第一匹配信息与第二匹配信息匹配时，由计算机服务器确定第一乘客和第二乘客具有事先达成的拼车协议；由计算机服务器生成基于第一拼车请求和第二拼车请求的拼车订单；所述计算机服务器向所述第一乘客终端和所述第二乘客终端发送拼车订单的确认通知。

根据本申请的示例性实施例，一种包括用于向用户及其联系人提供拼车服务的至少一组指令的非暂态性计算机可读介质，其中，当由计算机服务器的处理器执行时，所述至少一组指令指导处理器执行以下动作；从与第一乘客相关联的第一乘客终端获得包括第一匹配信息和第一行程起点的第一拼车请求；从与第二乘客相关联的第二乘客终端获得包括第二匹配信息和第二行程起点的第二拼车请求；当第一匹配信息与第二匹配信息匹配时，确定第一乘客和第二乘客有一个事先达成的拼车协议；根据第一拼车请求和第二拼车请求生成拼车订单；并向第一乘客终端和第二乘客终端发送拼车订单确认通知。

附图说明

本申请将结合示例性实施例进一步进行描述。与附图一起阅读时，下面的详细描述将更清楚的说明本申请的前述内容和实施例的其他方面。

图1是根据一些实施例的示例性按需服务系统的框图；

图2是根据一些实施例的计算装置的示例性硬件和软件组件的示意图；

图3是根据一些实施例的示例性处理引擎的框图；

图4是根据一些实施例的示例性拼车过程的流程图；

图5是根据一些实施例的示例性拼车过程的流程图；

图6是根据一些实施例的示例性拼车过程的流程图；

图7是根据一些实施例的示例性拼车过程的流程图；以及

图8是根据一些实施例的示例性拼车过程的流程图。

具体实施方式

以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并在特定应用及其要求的上下文中提供。对于本领域的普通技术人员来讲，对本申请披露的实施例进行的各种修改是显而易见的，并且本文中定义的通则在不背离本申请的精神及范围的情况下，可以适用于其他实施例及应用。因此，本申请不限于所示的实施例，而是符合与申请专利范围一致的最广泛范围。

本申请所使用的术语仅为了描述特定范例性实施例，并不限制本申请的范围。如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。应该被理解的是，本申请中所使用的术语“包括”与“包含”仅提示已明确标识的特征、整数、步骤、步、元素、及/或组件，而不排除可以存在和添加其他一个或多个特征、整数、步骤、操作、元素、组件、及/或其组合。

根据以下对附图的描述，本申请所述的和其他的特征、特色，以及相关结构元素的功能和操作方法，以及制造的经济性和部件组合更加显而易见，这些都构成说明书的一部分。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是，附图并不是按比例的。

本申请中使用了流程图用于说明根据本申请的实施例的系统所执行的操作。应当理解的是，流程图的操作不一定按照顺序来精确地执行。相反，可以按照倒序执行或同时处理各种步骤。同时，也可以将一个或多个其他操作添加到这些流程图中，或从这些流程图移除一个或多个操作。

此外，尽管主要关于调用车辆描述了本申请中的系统和方法，应该理解的是，这只是一个示例性的实施例。本申请的系统或方法还可应用于其他类型的按需服务。例如，本申请的系统和方法可以应用于不同环境的运输系统，包括陆地、海洋、航空航天等或上述举例的任意组合。所述运输系统涉及的车辆可以包括出租车、专车、顺风车、公交车、火车、动车、高铁、地铁、船舶、飞机、飞船、热气球、无人驾驶的车辆等或上述举例的任意组合。所述运输系统也可以包括应用管理和/或分配的任一运输系统，例如，发送和/或接收快递的系统。本申请的系统和方法的应用场景可以包括网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等或上述举例的任意组合。

在本申请中，术语“乘客”、“请求者”、“服务请求者”和“客户”可以交换使用，是指可以请求或预定服务的个体、实体或工具。同样地，本申请描述的“司机”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。在本申请中，术语“用户”可以表示可以请求服务、预定服务、提供服务或协助提供服务的个体、实体或工具。例如，用户可以是乘客、司机、操作者等或上述举例的任意组合。在本申请中，“乘客”和“乘客终端”可以交换使用，而且“司机”和“司机终端”可以交换使用。

本申请中的术语“拼车”指的是一种行程共享行，使得不止一个人乘坐一辆车。在本申请中，拼车服务可以指的是多于一个乘客请求共享行程并呼叫车辆的服务。拼车服务还可以指在驾驶过程中司机想要与至少一名乘客共享他/她的车辆的服务。拼车服务可能是一次性的。

在本申请中，术语“请求”表示由乘客、请求者、服务请求者、客户、司机、提供者、服务提供者、供应方等或上述举例的任意组合所发起的请求。所述服务请求可以被乘客、请求者、服务请求者、客户、司机、提供者、服务提供者、供应方中的任一个接受。所述服务请求可以是收费的或免费的。本申请中的术语“订单”表示乘客(或请求者、服务请求者、客户等)和司机(或提供者、服务提供者或供应方等)关于所述服务请求达成一致意愿。

本申请中的位置和/或行程起点可以通过嵌入在乘客终端中的定位技术来获取。在本申请中使用的定位技术可包括一全球定位系统(GPS)、全球导航卫星系统(GLONASS)、罗盘导航系统(COMPASS)、伽利略定位系统、准天顶卫星系统(QZSS)、无线保真(WIFI)定位技术等或其任意组合。上述定位技术中的一种或者多种可在本申请中互换使用。

本申请的一个方面涉及用于找到可共享和/或可组合的运输交易的在线系统和方法，例如拼车，尤其是熟人和朋友之间的拼车。根据本申请，该系统和方法可以要求请求者在拼车请求中包括他/她的联系人中的至少一个信息。系统和方法可以将请求传送给至少一个联系人，并选择同意拼车请求者的人。

需要注意的是，在线按需运输服务，例如在线预定出租车，是起源于后互联网时代的一种新的服务请求形式。它为使用者和服务提供者提供了仅在后因特网时代才可能实现的技术请求方案。在互联网时代之前，当使用者在街道上呼叫一辆出租车时，出租车预定请求和接受只能在乘客和一个看见该乘客的出租车司机之间发生。如果乘客通过电话预约一辆出租车，出租车预定请求和接受只能在该乘客和服务提供者(例如，出租车公司或代理机构)之间发生。然而，在线出租车允许一个使用者实时地和自动地向与该使用者相距一段距离的大量的个人服务提供者(例如，出租车)分配服务请求。它同时允许多个服务提供者同时地和实时地对该服务请求进行响应。因此，通过互联网，所述在线按需运输系统可以为用户和服务提供者提供一个更加高效的交易平台，这在传统的互联网时代之前的运输服务系统中是无法达到的。熟人和朋友之间的拼车是一种特殊的在线按需服务，为乘客和司机提供安全、高效的服务。

图1是根据一些实施例所示的一种示例性按需服务系统100的模块图。例如，按需服务系统100可以是一个提供运输服务的在线运输服务平台，如出租车呼叫、代驾服务、快递车辆、拼车、公交车服务、司机招聘和接送服务。按需服务系统100可以是包括服务器110、网络120、请求者终端130、提供者终端140和数据库150的在线平台。服务器110可以包括处理引擎112。

在一些实施例中，服务器110可以是单个服务器或服务器组。服务器群可以是集中式的或分布式的(例如，服务器110可以是分布式的系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以通过网络120存取储存于请求者终端130、提供者终端140和/或数据库150中的信息和/或数据。又例如，服务器110可以直接连接到请求者终端130、提供者终端140和/或数据库150，以存取储存的信息和/或数据。在一些实施例中，服务器110可以在云端平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、小区云、分布云、跨云、多云等或上述举例的任意组合。在一些实施例中，服务器110可以在图2中描述的包含了一个或者多个组件的计算装置200上执行。

在一些实施例中，服务器110可以包括处理引擎112。处理引擎112可处理与服务请求相关联的信息和/或数据来执行在本申请中披露的至少一个功能。例如，处理引擎112可基于从请求者终端130处获得的服务请求确定一目标车辆。在一些实施例中，所述处理引擎112可包括一个或者多个处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为范例，处理引擎112可以包括中央处理器(CPU)、特定应用集成电路(ASIC)、特定应用指令集处理器(ASIP)、图形处理单元(GPU)、物理处理单元(PPU)、数字信号处理器(DSP)、现场可程序门阵列(FPGA)、可程序逻辑装置(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或其任意组合。

网络120可以促进信息及/或数据的交换。在一些实施例中，按需服务系统100中的至少一个组件(例如，服务器110、请求者终端130、提供者终端140和数据库150)可以通过网络120向按需服务系统100中的其他组件发送信息和/或数据。例如，服务器110可以通过网络120从请求者终端130获得/获取服务请求。在一些实施例中，网络120可以是有线网络或无线网络中的任意一种，或其组合。仅仅作为示例，网络120可以包括电缆网络、有线网络、光纤网络、远程通信网络、内部网络、因特网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网络(MAN)、公共交换电话网络(PSTN)、蓝牙网络、ZigBee网络、近场通讯(NFC)网络等或上述举例的任意组合。在一些实施例中，网络120可以包括一个或多个网络交换点。例如，网络120可能包括有线或无线网络交换点，如基站和/或互联网交换点120-1、120-2、……，通过交换点，按需服务系统100的一个或多个部件可以连接到网络120以交换数据和/或信息。

在一些实施例中，请求者可以是请求者终端130的使用者。在一些实施例中，请求者终端130的使用者可以是请求者之外的其他人。例如，请求请求者终端130的使用者A可以使用请求请求者终端130为使用者B发送一个服务请求，或从服务器110接收服务和/或信息或指示。在一些实施例中，提供者可以是提供者终端140的用户。在一些实施例中，提供者终端130的用户可以为除该提供者之外的其他人。例如，提供者终端140的使用者C可以使用提供者终端140为使用者D接收服务请求和/或从服务器110处接收信息或指令。在一些实施例中，“请求者”和“请求者终端”可以交换使用，“提供者”和“提供者终端”可以交换使用。

在一些实施例中，请求者终端130可以包括行动装置130-1、平板计算机130-2、膝上型计算机130-3、车载装置130-4等或上述举例的任意组合。在一些实施例中，移动装置130-1可以包括智能家居装置、可穿戴装置、行动装置、虚拟现实装置、增强实境装置等或上述举例的任意组合。在一些实施例中，智能家居装置可以包括智能照明装置、智能电器的控制装置、智能监测装置、智能电视、智能摄影机、对讲机等或上述举例的任意组合。在一些实施例中，可穿戴装置可以包括手环、鞋袜、眼镜、头盔、手表、衣物、背包、智慧配饰等或上述举例的任意组合。在一些实施例中，移动装置可以包括移动电话、个人数字助理、游戏设备、导航装置、POS机、膝上型计算机、台式计算机等或上述举例的任意组合。在一些实施例中，虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强型虚拟现实头盔、增强型虚拟现实眼镜、增强型虚拟现实眼罩等或其任意组合。例如，虚拟实境装置和/或增强实境装置可以包括Google Glass、Oculus Rift、Hololens、Gear VR等。在一些实施例中，车载装置130-4包括车载计算机或车载电视等。在一些实施例中，请求请求者终端130可以是带有定位技术的装置，所述定位技术可以用于定位请求请求者和/或请求请求者终端130的位置。

在一些实施例中，提供者终端140可以是一个与请求者终端130类似或者相同的装置。在一些实施例中，提供者终端140可以是一个带有定位技术的装置，以定位提供者终端140的使用者(例如，服务提供者)和/或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可以与一个或多个其他定位装置通讯以确定请求者、请求者终端130、提供者和/或提供者终端140的位置。在一些实施例中，请求者终端130和/或提供者终端140可以将定位信息发送至服务器110。

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从请求者终端130和/或提供者终端140获得的数据。在一些实施例中，数据库150可以存储供服务器110执行或使用的数据和/或指令，服务器110可以通过执行或使用所述数据和/或指令以实现本申请描述的示例性方法。在一些实施例中，数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或上述举例的任意组合。示例性大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括快闪驱动器、软盘、光盘、记忆卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性随机存取存取器可以包括动态随机存取存储器(DRAM)、双倍速率同步动态随机存取存储器(DDR SDRAM)、静态随机存取存取器(SRAM)、晶闸管随机存取存取器(T-RAM)、零电容随机存取存取器(Z-RAM)等。示例性只读存储器可以包括光罩式只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电子可擦除可编程只读存储器(EEPROM)、压缩盘只读存储器(CD-ROM)、数字通用磁盘只读存储器等。在一些实施例中，数据库150可以在云平台上实现。仅仅作为示例，所述云平台可以包括私有云、公共云、混合云、小区云、分布云、跨云、多云等或上述举例的任意组合。

在一些实施例中，数据库150可以与网络120连接以与按需服务系统100中的一个或多个部件(例如，服务器110、请求者终端130、提供者终端140等)通信。按需服务系统100中的一个或多个部件可以通过网络120存取存储于数据库150中的数据或指令。在一些实施例中，数据库150可以直接与按需服务系统100的一个或多个部件(例如，服务器110、请求者终端130、提供者终端140等)连接或通讯。在一些实施例中，数据库150可以是服务器110的一部分。

在一些实施例中，按需服务系统100的一个或多个组件(例如，服务器110、请求者终端130、提供者终端140等)可以被允许访问数据库150。在一些实施例中，当满足一个或多个条件时，按需服务系统100的一个或多个部件可以读取和/或修改与请求者、提供者和/或公众相关的信息。例如，在完成一个服务后，服务器110可以读取和/或修改一个或多个用户的信息。再例如，当从请求请求者终端130接收到一个服务请求时，提供者终端140可以访问与所述请求请求者相关的信息，但提供者终端140无法修改请求请求者的相关信息。

在一些实施例中，按需服务系统100的一个或多个部件的信息交换可以通过请求服务的方式实现。服务请求的对象可以是任何产品。在一些实施例中，产品可以是有形产品或无形产品。有形产品可以包括食品、医药、商品、化学产品、电器、衣物、小汽车、房屋、奢侈品等或上述举例的任意组合。无形产品可以包括服务产品、金融产品、知识产品、互联网产品等或上述举例的任意组合。互联网产品可以包括个人主机产品、网站产品、移动互联网产品、商业主机产品、嵌入式产品等或上述举例的任意组合。移动互联网产品可以用于移动终端的软件、程序、系统等或上述举例的任意组合。移动终端可以包括平板计算机、膝上型计算机、移动电话、掌上计算机(PDA)、智能手表、POS装置、车载计算机、车载电视、可穿戴装置等或其任意组合。例如，产品可以是用于计算机或移动电话中的任一软件及/或应用程序。软件和/或应用程序可以与社交、购物、交通、娱乐、学习、投资等或上述举例的任意组合相关。在一些实施例中，与运输相关的软件和/或应用程序可以包括行程软件和/或应用程序，交通工具调用软件和/或应用程序，地图软件和/或应用程序等。在交通工具调用软件和/或应用程序中，交通工具可以包括马、马车、人力车(例如，手推车、自行车、三轮车等)、汽车(例如，出租车、公共汽车、私家车等)、火车、地铁、船舶、航空器(例如，飞机、直升飞机、航天飞机、火箭、热气球等)等或上述举例的任意组合。

图2是根据申请的一些实施例所示的计算装置200的示例性硬体和软件的框图，其上可以实现本申请所述服务器110、请求者终端130和/或提供者终端140相应的功能。例如，处理引擎112可以在计算装置200上实施并执行本申请所披露的处理引擎112的功能。

计算装置200可以是一些实施例中的专用计算机。计算装置200可用于实施本申请的按需服务系统。计算装置200可以实施所述的请求服务的任何组件。在图1-2中，仅为了方便起见，仅示出了一个这样的计算机设备。本申请中的一个普通技术人员在编写该应用程序时会理解，与所述的请求服务相关的计算机功能可以以分布的方式、由一组相似的平台所实施，以分散系统的处理负荷。

例如，计算装置200可以包括与网络连接的通讯端口250，以促进数据通讯。计算装置200可以包括中央处理器(CPU，或处理器)220，可以以一个或多个处理器的形式执行程序指令。示例性的计算机平台可以包括一个总线210、不同形式的程序储存器和数据储存器，例如，磁盘270和只读存储器(ROM)230或随机存取内存(RAM)240，用于储存由计算机处理和/或传输的各种各样的数据文件。示例性的计算机平台也可以包括储存于只读存储器230、随机存取内存240和/或其他类型的非暂态储存介质中的供处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实施。计算装置200还包括输入/输出260，以支持计算机与此处其他部件例如用户接口280之间的输入/输出。计算装置200也可以通过网络通讯接收程序设计和数据。

仅仅为了说明，在计算装置200中仅描述了一个CPU/处理器220。然而，应该注意的是，本申请中的计算装置200也可以包括多个CPU/处理器，因此本申请中描述的由一个CPU/处理器220实现的操作和/或方法步骤也可以共同地或独立地由多个CPU/处理器执行。例如，如果在本申请中，计算装置200的处理器执行步骤A和步骤B，应当理解的是，步骤A和步骤B也可以由计算装置200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一和第二处理器共同地执行步骤A和步骤B)。

图3是根据本申请的一些实施例的示例性处理设备的示意图。处理引擎112可以包括请求获取单元310、邀请获取/发送单元320、确定单元330和通知发送单元340。

请求获取单元310可以被配置为从第一乘客终端获得第一拼车请求，和/或从第二乘客终端获得第二拼车请求。在一些实施例中，请求获取单元310可以用于从第一乘客终端获得重新拼车请求。

邀请获取/发送单元320可以被配置为从第一乘客终端获得邀请，和/或向至少一个第二乘客终端中的候选第二乘客终端发送邀请。

确定单元330可以被配置为确定第一乘客终端的第一支付金额和/或第二乘客终端的第二支付金额。在一些实施例中，确定单元330可以被配置为确定第一乘客和第二乘客具有事先达成的拼车协议。

通知发送单元340可以用于向第一乘客终端和/或第二乘客终端发送拼车订单的确认通知。在一些实施例中，通知发送单元340可以被配置为向第一乘客终端发送拼车请求的失败通知。

处理引擎112中的模块可以通过有线连接或无线连接以互相连接或互相通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网络(WAN)、蓝牙、ZigBee网络、近场通讯(NFC)等或上述举例的任意组合。两个或多个模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或多个单元。例如，请求获取单元310可以作为单个模块集成在邀请获取/发送单元320中，该单个模块既可以获得订单的特征，又可以确定订单的匹配信息。

图4是根据一些实施例的用于拼车的示例性过程400的流程图。在一些实施例中，过程400可以在图1中所示的系统100中实现。例如，流程400可以以指令的形式储存在数据库150和/或内存(如：ROM 230、RAM 240等)中，并且被服务器110(如：服务器110中的处理引擎112、服务器110中的处理引擎112中的处理器220或者如图3中所示的处理引擎112中的一个或多个组件)调用和/或执行。

在步骤410中，处理器220可以从第一乘客终端获得/获取拼车请求，其中拼车请求包括第一乘客终端的用户(即，第一乘客)的至少一个联系人。

在一些实施例中，联系人可以包括在第一乘客终端的通讯录中保存的第一乘客的联系人，来自嵌入在第一乘客终端中的社交网络服务例如，电子邮件、即时消息服务、在线论坛、购物软件和/或应用程序、行程软件和/或应用程序、车辆调用软件和/或应用程序、地图软件和/或应用程序、支付软件和/或或应用程序等)的第一乘客的联系人(或其任意组合。在一些实施例中，拼车请求还可以包括第一乘客终端的第一行程起点、第一乘客终端的第一开始时间、第一乘客终端的第一行程目的地、第一乘客终端的第一位置、第一乘客终端的标识等或其任意组合。在一些实施例中，第一乘客终端的位置可以与第一乘客终端的行程起点相同。例如，可以通过嵌入在第一乘客终端中的定位技术来获取位置和/或行程起点。在一些实施例中，第一乘客终端的标识可以包括第一乘客终端的媒体访问控制(MAC)地址、第一乘客终端的序列号、第一乘客终端的中央处理器(CPU)序列号、与第一乘客终端相关联的电话号码、与第一乘客终端相关联的名称、与第一乘客终端相关联的用户身份(ID)、与第一乘客终端相关联的头像等或其任意组合。

在一些实施例中，所述至少一个联系人可以由第一乘客选择，例如，来自第一乘客终端的通讯录，来自嵌入在第一乘客终端中的软件/应用的联系人列表等。在一些实施例中，第一乘客可以选择姓名、号码、用户身份(ID)、联系人的头像等或其任意组合。在一些实施例中，可以根据与拼车请求相关联的车辆座位数来确定至少一个联系人的数量。

在一些实施例中，第一乘客可以是想要与他/她的联系人共享他/她的车辆的司机。因此，请求拼车服务的第一乘客终端可以是由司机操作的司机终端。当车辆总共有五个座位时，至少一个联系人的数量最多可以是四个。在一些实施例中，第一乘客可以是与驾驶员一起呼叫车辆的乘客。因此，请求拼车服务的第一乘客终端可以是由想要与他/她的联系人共享行程的乘客操作的乘客终端。当车辆具有五个座位的总数时，至少一个联系人的数量最多可以是三个。

在步骤420中，处理器220可以识别与至少一个联系人相关联的至少一个第二乘客终端。在一些实施例中，联系人可以与乘客终端相关联。

在步骤430中，处理器220可以将与第一乘客终端相关联的拼车请求的邀请发送到至少一个第二乘客终端中的候选第二乘客终端。

在一些实施例中，邀请可以包括第一乘客终端的标识、第一乘客终端的第一行程起点、第一乘客终端的第一目的地、是否接受所述拼车请求的邀请的确认信息，或其任意组合。在一些实施例中，该邀请可以作为手机消息、电子邮件，来自社交网络服务的弹出消息等或其任意组合来发送。

在步骤440，处理器220可以获得/获取对来自候选第二乘客终端的邀请的响应，该响应指示是否接受拼车请求。

在一些实施例中，来自候选第二乘客终端的响应可包括拒绝响应，接受响应等。在一些实施例中，对来自候选第二乘客终端的邀请的响应可以作为回复手机消息，回复电子邮件，对弹出消息的回复等或其任意组合来获得。

图5是根据一些实施例，当响应是拒绝响应时的示例性拼车过程500的流程图。在一些实施例中，过程500可以在图1中所示的系统100中实现。例如，流程500可以以指令的形式储存在数据库150和/或内存(如：ROM 230、RAM 240等)中，并且被服务器110(如：服务器110中的处理引擎112、服务器110中的处理引擎112中的处理器220或者图3中处理引擎112中的一个或多个组件)调用和/或执行。

在步骤510中，处理器220可以获得/获取拒绝响应以拒绝来自候选第二乘客终端的邀请。

在一些实施例中，处理器220可以进一步获得/获取与拒绝响应相关联的附加信息。例如，附加信息可以包括与候选第二乘客终端相关联的标识(例如，候选第二乘客终端的标识、候选第二乘客终端的名称、候选第二乘客终端的数量、候选第二乘客终端的头像等)、拒绝理由、拒绝时间等或其任意组合。

在步骤520中，处理器220可以将拼车请求的失败通知发送给第一乘客终端。

在一些实施例中，失败通知可以包括与候选第二乘客终端相关联的标识(例如，与候选第二乘客终端相对应的联系人的标识、候选第二乘客终端的标识、候选第二乘客终端的名称、候选第二乘客终端的数量、候选第二乘客终端的头像等)、拒绝原因、拒绝时间等或其任意组合。

在步骤530中，处理器220可以向第一乘客终端发送重新拼车请求，以询问第一乘客他/她是否希望向联系人重新发送拼车请求。

在步骤540中，处理器220可以从第一乘客终端获得/获取对重新拼车请求的回复。在一些实施例中，对重新拼车请求的回复可以是“是”。处理器220可以重复图4中的步骤410到步骤440以重新请求拼车服务。在一些实施例中，重新拼车请求可包括与上一个拼车请求不同的至少一个联系人。在一些实施例中，重新拼车请求的回复可以是“否”。处理器220可以停止向第一乘客终端显示重新拼车请求。在一些实施例中，处理器220可以不获得/获取重新拼车请求的回复。处理器220可以继续向第一乘客终端显示重新拼车请求，直到从第一乘客终端获得/获取对重新拼车请求的重新拼车请求的回复。

图6是根据一些实施例，当响应是接受响应时的示例性拼车的过程600的流程图。在一些实施例中，过程600可以在图1中所示的系统100中实现。例如，流程600可以以指令的形式储存在数据库150和/或内存(如：ROM 230、RAM 240等)中，并且被服务器110(如：服务器110中的处理引擎112、服务器110中的处理引擎112中的处理器220或者图3中处理引擎112中的一个或多个组件)调用和/或执行。

在步骤610中，处理器220可以从候选第二乘客终端获得/获取接受响应，以接所述邀请。

在一些实施例中，处理器220还可以获得/获取与接受响应相关联的附加信息。例如，附加信息可以包括与候选第二乘客终端相关联的标识(例如，与候选第二乘客终端相对应的联系人的标识、候选第二乘客终端的标识、候选第二乘客终端的名称、候选第二乘客终端的数量、候选第二乘客终端的头像等)、接收时间、候选第二乘客终端的第二行程起点、候选第二乘客的第二行程目的地终端、候选第二乘客终端的第二位置等或其任意组合。

在一些实施例中，候选第二乘客终端可以是与至少一个联系人相关联的至少一个第二乘客终端，例如，第二乘客终端的数量可以是一个、两个、三个或四个。

在步骤620中，处理器220可以根据拼车请求生成拼车订单。

在一些实施例中，拼车订单可包括第一乘客终端的标识、候选第二乘客终端的标识、第一乘客终端的第一行程起点、候选第二乘客终端的第二行程起点、第一乘客终端的第一行程目的地、候选第二乘客终端的第二行程目的地，第一乘客终端的第一开始时间，候选第二乘客终端的第二开始时间，第一乘客的第一位置终端，候选第二乘客终端的第二位置等或其任意组合。在一些实施例中，第一行程起点可以在距第二行程起点的预定距离内。可以根据拼车服务的场景确定预定距离(例如，两个或更多乘客前往相同或附近的目的地、两个或更多乘客具有相同或附近的起点、两个或更多乘客有至少部分相同的道路等)，交通状况，拼车服务的时间段等或其任意组合。在一些实施例中，预定距离可以由请求拼车服务的乘客或提供拼车服务的司机确定。

在步骤630中，处理器220可以向第一乘客终端和候选第二乘客终端发送确认通知。

在一些实施例中，对第一乘客终端和候选第二乘客终端的确认通知可以包括与拼车订单有关的信息。与拼车订单有关的信息可以包括第一乘客的身份、与候选第二乘客终端对应的联系人、第一乘客终端的标识、候选第二乘客终端的标识、第一行程起点第一乘客终端的第二行程起点、第一乘客终端的第一行驶目的地、候选第二乘客终端的第二行驶目的地、第一乘客终端的第一开始时间、候选第二乘客终端的第二开始时间、第一乘客终端的第一位置、候选第二乘客终端的第二位置、拼车订单的开始时间等或其任意组合。在一些实施例中，对第一乘客终端的确认通知和对候选第二乘客终端的确认通知可以是不同的。例如，对第一乘客终端的确认通知可以包括与候选第二乘客终端有关的信息(例如，候选第二乘客终端的标识、第二行程起点、第二行程起点、第二出发起始时间、第二位置、第二行程目的地等)。对候选第二乘客终端的确认通知可以包括与第一乘客终端有关的信息(例如，第一乘客终端的标识、第一行程起点、第一出发时间、第一位置、第一行程目的地等)。

在一些实施例中，当请求拼车服务的第一乘客终端是由想要与他/她的联系人共享他/她的车辆的司机操作的司机终端时，处理器220可以在拼车开始之前向司机终端和候选第二个乘客终端发送提醒。在一些实施例中，当请求拼车服务的第一乘客终端是由想要与他/她的联系人共享行程并且呼叫车辆的乘客操作的乘客终端时，处理器220可以发送拼车订单到至少一个司机终端。在一些实施例中，当拼车订单结束时，处理器220可以从第一乘客终端和/或候选第二乘客终端获得/获取拼车订单的成功确认。

图7是根据一些实施例的示例性拼车的过程700的流程图。在一些实施例中，过程700可以在图1中所示的系统100中实现。例如，过程700可以作为指令的形式存储在数据库150和/或存储器(例如，ROM 230、RAM 240等)中，并且由服务器110调用和执行(例如，服务器110中的处理引擎112、服务器110中的处理引擎112的处理器220、或图3中所示的处理引擎112中的至少一个组件)。

在步骤710中，处理器220可以获得/获取拼车订单的成功确认。在步骤720中，处理器220可以确定第一乘客终端的第一支付金额。在步骤730中，处理器220可以确定候选第二乘客终端的第二支付金额。

在一些实施例中，可以在行程开始之前预先确定第一支付金额和第二支付金额。例如，处理器220可以在行程开始之前根据每个开始时间、每个行程起点、每个行程目的地、车辆提供的服务类型(例如，私家车、公共汽车、出租车等)或其任意组合来确定每个乘客终端的支付金额。在一些实施例中，可以在行程结束之后确定第一支付金额和第二支付金额。例如，处理器220可以根据行程的每个行程距离、行程的每个行程时长、行程的每个等待时长等或其任意组合来确定每个乘客终端的支付金额。在一些实施例中，可以通过将行程的总金额除以乘客终端的总量来计算第一支付金额和第二支付金额。例如，支付金额总额可能为400元。共有4个乘客终端共用车辆。第一支付金额和第二支付金额可以是100元人民币(400元除以4个乘客终端)。

在一些实施例中，处理器220可以向第一乘客终端和/或候选第二乘客终端生成订单明细。订单明显可以包括支付金额、行程距离、行程时长、等待时长、与司机终端有关的信息(例如，司机终端的标识、司机终端的帐户等)相关信息的车辆(例如，许可证号、颜色、车辆类型等)等或其任意组合。

在一些实施例中，处理器220可以将第一支付金额发送给第一乘客终端，和/或将第二支付金额发送给候选第二乘客终端。

图8是根据一些实施例的示例性拼车过程800的流程图。在一些实施例中，过程800可以在图1中所示的系统100中实现。例如，流程800可以以指令的形式储存在数据库150和/或内存(例如，ROM 230、RAM 240等)中，并且被服务器110(如：服务器110中的处理引擎112、服务器110中的处理引擎112中的处理器220或者图3中处理引擎112中的一个或多个组件)调用和/或执行。

在步骤810中，处理器220可以从第一乘客终端获得/获取包括第一匹配信息和第一行程起点的第一拼车请求。

在一些实施例中，第一拼车请求还可包括第一行程目的地、第一开始时间、第一乘客终端的标识等或其任意组合。在一些实施例中，第一匹配信息可包括数字、字母、符号、字符、图像、声音、代码等或其任意组合。例如，第一个匹配信息可以是“1234”的一串数字。作为另一示例，第一匹配信息可以是QR码。在一些实施例中，第一匹配信息可以是由请求拼车服务的两个或更多个熟人和/或朋友预先确定的信息。该匹配信息可用于确认两个朋友确实有拼车意图。

在步骤820中，处理器220可以从与第二乘客相关联的第二乘客终端获得/获取包括第二匹配信息和第二行程起点的第二拼车请求。在一些实施例中，处理器220可以根据某些标准从第二乘客终端获得/获取第二拼车请求。例如，当第一行程起点在距第二行程起点的预定距离内时，处理器220可以获得/获取第二拼车请求。

在一些实施例中，第二拼车请求还可包括第二行程起点、第二行程目的地、第二起始时间、第二乘客终端的第二标识等或其任意组合。

在一些实施例中，预定距离可以是由第一乘客终端、处理器220、提供的拼车服务的司机终端等或其任意组合确定的任何距离。例如，预定距离可以包括0米(即，第一乘客终端可以与第二乘客终端在相同的起点)、500米、1000米、5000米等或其任意组合。

在一些实施例中，第二匹配信息可包括数字，字母，符号，字符，图像，声音，代码等或其任意组合。例如，第二匹配信息可以是“1243”的一串数字。作为另一示例，第二匹配信息可以是QR码。在一些实施例中，第二匹配信息可以由请求拼车服务的熟人和/或朋友预先确定并且是已知的。

在一些实施例中，在距离第一乘客终端的预定距离内可以存在至少一个第二乘客终端，其向处理器220发送第二拼车请求。在一些实施例中，可以根据与拼车请求相关联的车辆座位来确定第二乘客终端的数量。例如，如果与拼车请求相关联的车辆是普通汽车，则第二乘客终端的数量最多可以是3。

在一些实施例中，如果在距第一乘客终端的预定距离内没有第二乘客终端，则处理器220可以向第一乘客终端发送第一拼车请求失败的通知。

在步骤830中，处理器220可以确定第一匹配信息是否对应于和/或匹配第二匹配信息。

第一匹配信息和第二匹配信息之间的对应关系可以反映第一乘客终端的用户(例如，第一乘客)与第二乘客终端的用户(例如，第二乘客)之间的事先达成的拼车协议。例如，所述实现达成的拼车协议可以是第一乘客和第二乘客之间预先设定的。在一些实施例中，可以根据第一匹配信息和第二匹配信息之间的逻辑关系来确定第一匹配信息是否与第二匹配信息匹配。例如，如果第一匹配信息与第二匹配信息相同(例如，第一匹配信息和第二匹配信息是“拼车”字母)，则处理器220可以确定第一匹配信息与第二匹配信息匹配。

第一匹配信息和第二匹配信息之间的逻辑关系也可以是语义上的。当第一和第二匹配信息在语义上彼此连接时，处理器220可以确定第一乘客和第二乘客有事先达成的拼车协议。例如，如果第二匹配信息是第一匹配信息的答案(例如，第一匹配信息是“我的电话号码是什么？”的问题，第二匹配信息是“123-4567-8900”的答案，答案与问题匹配)，处理器220可以确定第一匹配信息与第二匹配信息匹配。

第一匹配信息和第二匹配信息之间的逻辑关系也可以是任意预定的。只要第一乘客和第二乘客同意并将第一匹配信息和第二匹配信息设置为匹配对，并且只要系统100被预先通知所述匹配对，处理器220就可以确定第一匹配信息和第二匹配信息是匹配的。无论第一和第二匹配信息的读取程度如何不相关，第一匹配信息和第二匹配信息都是匹配的。

第一匹配信息和第二匹配信息可以具有预设的一对一关系。例如，第二匹配信息是对应于第一匹配信息的唯一匹配信息。或者，第一匹配信息可以具有多于一个的相应匹配信息。例如，可以存在与第二匹配信息不同的预设第三匹配信息，其也与第一匹配信息对应。

在一些实施例中，如果第一匹配信息与第二匹配信息匹配，则在步骤840，处理器220可以根据第一匹配信息和第二匹配信息生成拼车订单。在一些实施例中，拼车订单可包括第一乘客终端的标识、第二乘客终端的标识、第一行程起点、第二行程起点、第一行程目的地、第二行程目的地、第一开始时间、第二开始时间等或其任意组合。

在步骤850中，处理器220可以向第一乘客终端和第二乘客终端发送确认通知。在一些实施例中，对第一乘客终端的确认通知可以包括第一乘客终端的标识、第二乘客终端的标识、第一行程起点、第二行程起点、第一行程目的地、第二行程目的地、第一开始时间、第二开始时间、拼车订单的开始时间等或其任意组合。在一些实施例中，对第一乘客终端的确认通知和对第二乘客终端的确认通知可以是不同的。例如，对第一乘客终端的确认通知可以包括与第二乘客终端有关的信息(例如，第二乘客终端的标识、第二行程起点、第二开始时间、第二行程目的地等)。对第二乘客终端的确认通知可以包括与第一乘客终端有关的信息(例如，第一乘客终端的标识、第一行程起点、第一开始时间、第一行程目的地等)。

在一些实施例中，处理器220可以在生成拼车订单后将拼车订单发送到至少一个司机终端。在一些实施例中，当拼车订单结束时，处理器220可以从第一乘客终端和/或候选第二乘客终端获得/获取拼车订单的成功确认。在一些实施例中，处理器220可以实施步骤720至步骤730，如本申请中的图7所示，以确定每个支付金额。

在一些实施例中，如果第一匹配信息与第二匹配信息不匹配(例如，第一匹配信息为“1234”，第二匹配信息为“1324”)，则在步骤860中，处理器220可以向第一个拼车请求到第一乘客终端发送失败通知。在一些实施例中，失败通知可包括第一拼车请求的原因。失败通知可以包括第二乘客终端的不同起始点，来自第二乘客终端的不匹配信息等或其任意组合。

在步骤870中，处理器220可以向第一乘客终端发送重新拼车请求。在步骤880中，处理器220可以从第一乘客终端获得/获取对重新拼车请求的回复。在一些实施例中，对重新拼车请求的回复可以是“是”。处理器220可以重复图8中的步骤810至步骤880以重新请求拼接服务。在一些实施例中，重新拼车请求的回复可以是“否”。处理器220可以停止向第一乘客终端显示重新拼车请求。在一些实施例中，处理器220可以获得/获取重新拼车请求的回复。处理器220可以继续向第一乘客终端显示重新拼车请求，直到从第一乘客终端获得/获取对重新拼车请求的重新拼车请求的回复。

上文已对基本概念做了描述，显然，对于已阅读此详细揭露的本领域的普通技术人员来讲，上述详细揭露仅作为示例，而并不构成对本申请的限制。虽然此处并没有明确说明，本领域技术人员可以对本申请进行各种修改、改进和修正。这类修改、改进和修正在本申请中被建议，所以所述修改、改进、修正仍属本申请示范实施例的精神和范围。

同时，本申请使用了特定术语来描述本申请的实施例。例如，“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特性可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各请求者面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个请求者面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各请求者面可以呈现为位于一个或多个计算机可读媒体中的计算机产品，该产品具有计算机可读程序编码。

计算机可读信号介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可以有多种形式，包括电磁形式、光形式等或任何合适的组合形式。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读讯号媒体上的程序编码可以通过任何合适的媒体进行传播，包括无线电、缆线、光纤电缆、RF、或类似介质、或任何上述介质的组合。

本申请各请求者面操作所需的计算机程序码可以用一种或多种程序语言的任意组合编写，包括面向对象程序设计，如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET，Python或类似的常规程序编程语言，如"C"编程语言，Visual Basic，Fortran2003，Perl，COBOL 2002，PHP，ABAP，动态编程语言如Python，Ruby和Groovy或其它编程语言。程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机上运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非申请专利范围中明确说明，否则所述处理元素或序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决请求者案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (20)

1.一种系统，包括：

至少一个计算机可读存储介质，包括用于向用户及其联系人提供拼车服务的指令；以及

至少一个与所述计算机可读存储介质通信的处理器，其中当执行所述指令时，所述至少一个处理器用于：

从第一乘客终端获得包括至少一名联系人的拼车请求；

识别与所述至少一个联系人相关联的至少一个第二乘客终端；

向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；以及

从所述候选第二乘客终端获得对所述邀请的响应，所述响应表明所述候选第二乘客终端是否接受所述拼车请求。

2.根据权利要求1所述的系统，其特征在于，对所述邀请的响应包括拒绝响应以拒绝所述邀请，以及

所述至少一个处理器还用于：

向所述第一乘客终端发送所述拼车请求的失败通知。

3.根据权利要求2所述的系统，其特征在于，所述至少一个处理器还用于：

向所述第一乘客终端发送重新拼车请求；以及

从所述第一乘客终端获得对所述重新拼车请求的回复。

4.根据权利要求1所述的系统，其特征在于，对所述邀请的所述响应包括接受响应以接受所述邀请；以及

所述至少一个处理器还用于：

根据所述拼车请求生成拼车订单；以及

向所述第一乘客终端和所述候选第二乘客终端发送所述拼车订单的确认通知。

5.根据权利要求4所述的系统，其特征在于，所述至少一个处理器还用于：

获得所述拼车订单的成功确认；

确定所述第一乘客终端的第一支付金额；以及

确定所述第二乘客终端的第二支付金额。

6.一种向用户及其联系人提供拼车服务的方法，包括：

通过计算机服务器从第一乘客终端获取包括至少一个联系人的拼车请求；

通过所述计算机服务器识别与所述至少一个联系人相关联的至少一个第二乘客终端；

通过所述计算机服务器向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；以及

通过所述计算机服务器，从所述候选第二乘客终端获得所述邀请的响应，所述响应表明所述候选第二乘客终端是否接受所述拼车请求。

7.根据权利要求6所述的方法，其特征在于，对所述邀请的响应包括拒绝响应以拒绝所述邀请，以及

所述方法还包括：

通过所述计算机服务器向所述第一乘客终端发送所述拼车请求的失败通知。

8.根据权利要求7所述的方法，其特征在于，还包括：

通过所述计算机服务器向所述第一乘客终端发送重新拼车请求；以及

通过所述计算机服务器从所述第一乘客终端获得对所述重新拼车请求的回复。

9.根据权利要求6所述的方法，其特征在于，对所述邀请的响应包括接受响应以接受所述邀请；以及

所述方法还包括：

由所述计算机服务器生成基于所述拼车请求的拼车订单；以及

所述计算机服务器向所述第一乘客终端和所述候选第二乘客终端发送所述订单的确认通知。

10.根据权利要求9所述的方法，其特征在于，还包括：

通过所述计算机服务器获得所述拼车订单的成功确认；

通过所述计算机服务器确定所述第一乘客终端的第一支付金额；以及

通过所述计算机服务器确定所述第二乘客终端的第二支付金额。

11.一种非暂态性计算机可读介质，包括至少一组用于向用户及其联系人提供拼车服务的指令，当由计算机服务器的处理器执行时，所述至少一组指令指示所述处理器执行的行为：

从第一乘客终端获得包括至少一名联系人的拼车请求；

识别与所述至少一个联系人相关联的至少一个第二乘客终端；

向所述至少一个第二乘客终端中的候选第二乘客终端发送邀请；以及

从所述候选第二乘客终端获得对所述邀请的响应，所述响应表明所述候选第二乘客终端是否接受所述拼车请求。

12.一种系统，包括：

至少一个计算机可读存储介质，包括用于向用户及其联系人提供拼车服务的指令；以及

至少一个与所述计算机可读存储介质通信的处理器，其中当执行所述指令集时，所述至少一个处理器用于：

从与第一乘客相关联的第一乘客终端获得第一拼车请求，所述第一拼车请求包括第一匹配信息和第一行程起点；

从与第二乘客相关联的第二乘客终端获得第二拼车请求，所述第二拼车请求包括第二匹配信息和第二行程起点；

当所述第一匹配信息匹配所述第二匹配信息时，确定所述第一乘客和所述第二乘客之间有事先达成的拼车协议；

基于所述第一拼车请求和所述第二拼车请求生成拼车订单；以及

向所述第一乘客终端和所述第二乘客终端发送所述拼车订单的确认通知。

13.根据权利要求12所述的系统，其特征在于，所述至少一个处理器还用于：

当发生所述以下至少一种情况时，将所述第一个拼车请求的失败通知发送到所述第一乘客终端：

所述第一行程起点在所述第二行程起点的所述预定距离之外，或

所述第一匹配信息不匹配所述第二匹配信息。

14.根据权利要求13所述的系统，其特征在于，所述至少一个处理器还用于：

向所述第一乘客终端发送重新拼车请求；以及

从所述第一乘客终端获得对所述重新拼车请求的回复。

15.根据权利要求12所述的系统，其特征在于，所述至少一个处理器还用于：

获得所述拼车订单的成功确认；

确定所述第一乘客终端的支付金额；以及

确定所述第二乘客终端的第二支付金额。

16.一种向用户提供拼车服务的方法及其联系人，包括：

通过计算机服务器，从与第一乘客相关联的第一乘客终端获得第一拼车请求，所述第一拼车请求包括第一匹配信息和第一行程起点；

通过所述计算机服务器，从与第二乘客相关联的第二乘客终端获得第二拼车请求，所述第二拼车请求包括第二匹配信息和第二行程起点；

通过所述计算机服务器，当所述第一匹配信息匹配所述第二匹配信息时，确定所述第一乘客和所述第二乘客具有事先达成的拼车协议；

通过所述计算机服务器，根据所述第一拼车请求和所述第二拼车请求生成拼车订单；以及

通过所述计算机服务器，向所述第一乘客终端和所述第二乘客终端发送所述拼车订单的确认通知。

17.根据权利要求16所述的方法，其特征在于，还包括：

当发生所述以下至少一种情况时，通过所述计算机服务器向所述第一乘客终端发送所述第一拼车请求失败的通知：

所述第一行程起点在所述第二行程起点的所述预定距离之外，或

所述第一匹配信息不匹配所述第二匹配信息。

18.根据权利要求17所述的方法，其特征在于，还包括：

通过所述计算机服务器向所述第一乘客终端发送重新拼车请求；以及

通过所述计算机服务器从所述第一乘客终端获得对所述重新拼车请求的回复。

19.根据权利要求16所述的方法，其特征在于，还包括：

通过所述计算机服务器获得所述拼车订单的成功确认；

通过所述计算机服务器确定所述第一乘客终端的第一支付金额；以及

通过所述计算机服务器确定所述第二乘客终端的第二支付金额。

20.一种非暂态性计算机可读介质，包括至少一组用于向用户及其联系人提供拼车服务的指令，其中当由计算机服务器的处理器执行时，所述至少一组指令指示所述处理器执行的行为：

从与第一乘客相关联的第一乘客终端获得第一拼车请求，所述第一拼车请求包括第一匹配信息和第一行程起点；

从与第二乘客相关联的第二乘客终端获得第二拼车请求，所述第二拼车请求包括第二匹配信息和第二行程起点；

当所述第一匹配信息匹配所述第二匹配信息时，确定所述第一乘客和所述第二乘客具有事先达成的拼车协议；

根据所述第一拼车请求和所述第二拼车请求生成拼车订单；以及

向所述第一乘客终端和所述第二乘客终端发送所述拼车订单的确认通知。