行程邀约的方法和系统与流程

【技术领域】

本申请涉及一种车辆行程邀约/邀请的方法和系统，特别是一种便利的点对点行程邀约的方法和系统。

背景技术：

随着科技发展，人们选择出行服务的也更为便捷。各种叫车平台都广为使用。而车辆行程共享例如拼车、顺风车也为多数人接受。

目前提供出行服务的平台能够提供较大的便利，一般通过用户发出需求订单，平台接收需求订单并以各种方式分派订单来完成交易。一个或多个用户也可以通过平台完成拼车的交易，例如专利申请cn107169815a一种熟人间拼车的方法和装置批露了一种熟人间拼车的方法和装置，包括：若接收到用户提供的目的地地址及起始地地址信息，则展示当前用户设备上的通讯录联系人窗口；在接收到用户选择的至少一个联系人标识后，向服务器发送拼车请求，所述拼车请求包括：当前用户设备的目的地地址、当前用户设备的起始地地址、至少一个联系人标识，和/或出发时间。

然而，现有技术中所提供的平台难以满足车主主动快速和直接邀约他人分享接送地址以及规划路线行程的需求。

【申请内容】

单独或结合附图阅读下面的具体实施方式，本申请的上述优点和其它优点以及特征将变得显而易见。

根据本申请一个方面，提供一种可用于行程邀约的系统。系统可包括：服务器端，其包括具有可执行指令的计算机可读存储介质，与计算机可读存储介质通信的处理器，可执行指令可配置为当执行时使得处理器执行以下步骤：获取第一客户端针对第二客户端的行程邀请，行程邀请包括第一客户端识别信息以及针对第二客户端的地理位置分享请求；以及将行程邀请发送至第二客户端。与一般的打车软件或者行程共享平台不同的是，通常打车软件或者行程共享的平台都要求双方都使用同一款软件/应用，并通过该特定的软件进行沟通和操作。而本申请所提供的方案并不要求车主乘客双方统一使用同一款软件平台，也能够顺利完成定位和接送。此外，与一般软件中的实时位置分享也不同，本申请所提供的方案也不要求双方都在某一位置分享软件，也可以便利地沟通车辆和乘客双方信息。

在一个实施例中，其中地理位置分享请求包含指向服务器端地图的链接。

在另一实施例中，其中链接为html链接。

在又一个实施例中，其中步骤进一步包括响应于第二客户端接受行程邀请，将第二客户端的地理位置同步至服务器端地图并进一步发送至第一客户端。

在又一个实施例中，其中步骤进一步包括响应于第二客户端接受行程邀请，接收第二客户端的地理位置并将第二客户端的地理位置发送至第一客户端。

在又一个实施例中，其中步骤进一步包括根据第二客户端的地理位置而规划行驶路径。

在又一个实施例中，其中根据第二客户端的地理位置而规划行驶路径的步骤在第一客户端完成。

在又一个实施例中，其中步骤包括当第二客户端拒绝邀请时，向第一客户端发送拒绝提醒。

在又一个实施例中，其中步骤包括在第一客户端显示通讯录联系人相关联的行程邀请选项。

在又一个实施例中，其中步骤包括在第一客户端的通话界面下显示与第一客户端的联系人相关联的行程邀请选项。

在又一个实施例中，其中步骤包括在第一客户端第一应用地图界面的显示行程邀请选项，以及响应于接收用户授权而将通讯录联系人同步到第一应用并在第一应用的地图界面针对特定联系人而发送行程邀请。

在又一个实施例中，其中步骤包括响应于接收用户拒绝通讯录同步的授权而不将通讯录联系人同步到第一应用，并通过用户输入联系人号码来发送针对特定联系人的行程邀请。

在又一个实施例中，其中步骤包括接收第二客户端的输入而接收第二客户端的新乘车位置。

在又一个实施例中，其中步骤包括接收第二客户端的输入而对第二客户端发出是否重新定位第二客户端的乘车位置的问询选项，当第二客户端确认重新定位时，接收第二客户端的新乘车位置。

在又一个实施例中，其中步骤包括将更新乘车位置展示给第一客户端并询问第一客户端是否接受更新乘车位置，以及当第一客户端确认时，将新乘车位置确定为目标位置。

在又一个实施例中，其中步骤包括接收第一客户端的输入而接受第一客户端的建议的新接乘位置。

在又一个实施例中，其中步骤包括接收第一客户端的输入而对第一客户端发出是否想建议新接乘位置的问询选项，当第一客户端确认想建议新接乘位置时，定位第一客户端的新接乘位置。

在又一个实施例中，其中步骤包括将新接乘位置展示给第二客户端并询问第二客户端是否接受新接乘位置，当第二客户端确认时，处理器被配置为将新接乘位置确定为目标位置。

在又一个实施例中，其中步骤包括根据目标位置而进一步规划行驶路径。

在又一个实施例中，其中所述根据目标位置而进一步规划行驶路径的步骤在所述第一客户端完成。

在又一个实施例中，其中第一客户端为车辆人员客户端，步骤包括使得车辆人员客户端所显示的电子地图与服务器端地图实时同步。

在又一个实施例中，针对第二客户端的地理位置分享请求为地理位置共享请求，步骤包括响应于第二客户端接受行程邀请，而将第一客户端和第二客户端的地理位置相互共享。

在又一个实施例中，其中步骤包括响应于第二客户端接受行程邀请，将第二客户端的地理位置以及目的地发送至第一客户端。

在又一个实施例中，其中步骤包括响应于第二客户端接受行程邀请，接收第二客户端发送的地理位置和目的地并基于地理位置和所述目的地规划路径。

根据本申请另一个方面，提供一种行程邀约的系统。其中系统可包括：第一客户端，其包括具有可执行指令的计算机可读存储介质，与计算机可读存储介质通信的处理器，可执行指令可配置为当执行时使得处理器执行以下步骤：获取用户输入而发送针对第二客户端的行程邀请，行程邀请为包括第一客户端识别信息以及针对第二客户端的地理位置分享请求；以及将行程邀请以短消息形式发送至第二客户端；以及响应于第二客户端接受行程邀请，接收第二客户端发送的地理位置。

在一个实施例中，其中地理位置分享请求包括html链接。

在另一个实施例中，其中步骤包括由第一客户端接收来自第二客户端的短消息形式或者其他即时通讯形式发送的地理位置。

在又一个实施例中，其中步骤包括进一步解读地理位置以及将地理位置标记至第一客户端的地图界面并进行路径规划。

根据本申请又一个方面，提供一种行程邀约的装置。其中装置可包括：具有可执行指令的计算机可读存储介质，与计算机可读存储介质通信的处理器。其中可执行指令可配置为当执行时使得处理器执行下述步骤：获取用户输入，根据用户选择特定联系人而向特定联系人发送行程邀请，行程邀请包括用户识别信息以及针对特定联系人的地理位置分享请求。

在一个实施例中，其中地理位置分享请求包括指向到服务器端地图的链接。

在另一个实施例中，步骤包括通过短消息形式发送行程邀请。在另一些示例中，可以任何合适的即时通讯的方式发送行程邀请。

在又一个实施例中，其中步骤包括显示与装置的联系人相关联的行程邀请选项。

在又一个实施例中，其中步骤包括显示在通话界面下与特定联系人相关联的行程邀请选项。

在又一个实施例中，其中步骤包括显示位于第一应用地图界面的行程邀请选项，以及响应于接收用户授权而将通讯录联系人同步到第一应用并在第一应用的地图界面针对特定联系人而发送行程邀请。

在又一个实施例中，其中步骤包括接收用户拒绝通讯录同步的授权而不将通讯录联系人同步到第一应用，并通过用户输入联系人号码来发送针对特定联系人的行程邀请。

在又一个实施例中，其中第一客户端为车辆人员便携式移动终端或者车载计算机终端。

在又一个实施例中，其中行程邀请为针对第二客户端的搭乘邀请或者接人请求。

在又一个实施例中，其中步骤包括在第一应用地图界面显示快捷通话选项。

在又一个实施例中，其中步骤包括接收特定联系人发送的照片并将其显示在第一客户端的地图界面。

根据本申请又一个方面，提供一种可用于行程邀约的系统。其中系统可包括：服务器端，其包括具有可执行指令的计算机可读存储介质，与计算机可读存储介质通信的处理器。其中可执行指令可配置为当执行时使得处理器：获取第一客户端针对第二客户端的行程邀请，行程邀请包括第一客户端识别信息以及针对第二客户端的接人请求；以及将行程邀请发送至第二客户端，其中第一客户端为乘客端，第二客户端为车辆人员端。

在一个实施例中，其中行程邀请还包括指向服务器端地图的链接。

在另一个实施例中，其中行程邀请还包括第一客户端的地理位置。

在又一个实施例中，其中步骤包括响应于第二客户端接受行程邀请，将第一客户端的地理位置同步至服务器端地图并进一步发送至第一客户端。

在又一个实施例中，其中步骤包括响应于第二客户端接受行程邀请，接收第一客户端的地理位置并将第一客户端的地理位置发送至第二客户端。

在又一个实施例中，其中步骤包括根据第一客户端的地理位置而规划行驶路径。

在又一个实施例中，其中步骤包括将第一客户端的地理位置设为目标位置而规划行驶路径。

在又一个实施例中，其中，步骤包括当第二客户端拒绝邀请时，处理器被配置为向第一客户端发送拒绝提醒。

在又一个实施例中，其中步骤包括在第一客户端显示通讯录联系人相关联的行程邀请选项。

在又一个实施例中，其中步骤包括在通话界面下显示与第一客户端的联系人相关联的行程邀请选项。

根据本发明又一个方面，提供一种行程邀约的方法。其中方法可包括：通过第一客户端向第二客户端发送行程邀请，其中行程邀请包括针对第二客户端的地理位置分享请求；通过第一客户端接收第二客户端的反馈，其中当第二客户端接受行程邀请时，第二客户端将其地理位置发送给第一客户端。

在一个实施例中，其中位置分享请求包括指向电子地图的链接，第二客户端的地理位置以地图中标记的形式发送至第一客户端。

在另一个实施例中，其中位置分享请求包括文字请求，地理位置反馈包括图片、经纬度数据中的至少一者。

在又一个实施例中，其中位置分享请求包括指向服务器电子地图的链接，地理位置反馈以地图中标记的形式同步至服务器网络，并进一步发送至第一客户端。在又一个实施例中，其中当第二客户端拒绝行程邀请时，向第一客户端发送拒绝消息。

根据本申请又一个方面，提供一种包含导航应用的设备。该包含导航应用的设备可包括：具有可执行指令的计算机可读存储介质，与计算机可读存储介质通信的处理器。其中可执行指令可配置为当执行时使得该处理器执行以下步骤：获取用户在导航界面下的输入，根据用户选择特定联系人而向该特定联系人发送行程邀请，行程邀请可包括该用户识别信息以及针对所述特定联系人的地理位置分享请求。

在一个实施例中，其中地理位置分享请求包括指向到服务器端地图的链接，而该行程邀请可通过短消息或其他即时通讯的方式发送。

在另一个实施例中，其中步骤可包括在导航界面显示行程邀请选项，以及响应于接收用户授权而将通讯录联系人同步到所述导航应用并在该导航界面针对该特定联系人而发送该行程邀请。

在又一个实施例中，其中步骤包括响应于接收用户拒绝通讯录同步的授权而不将通讯录联系人同步到所述导航应用，并通过用户输入联系人号码来发送针对该特定联系人的行程邀请。

在又一个实施例中，步骤进一步包括在导航应用的导航界面显示快捷通话选项。

在又一个实施例中，其中步骤进一步包括接收特定联系人发送的照片并将其显示在所述导航界面。

在又一个实施例中，其中步骤进一步包括响应于该特定联系人接受行程邀请，接收该特定联系人的地理位置并规划路径。在另一些实施例中，步骤进一步包括响应于该特定联系人接受行程邀请而接收该特定联系人的地理位置以及目的地，并基于特定联系人的地理位置和所述目的地来规划路径。

【附图说明】

为了更加完整地理解本申请的实施例，应参考在附图中更为详细地说明以及下文中通过示例描述的实施例，其中：

图1显示了一个实施例中车辆行程邀请系统的交互示例；

图2显示了用于车辆31的车载计算机系统(vcs)1的示例框式拓朴图；

图3显示了一个实施例中可用于图1所示的车辆行程邀请系统的示例性方法流程图；

图4显示了一个实施例中第一客户端的行程邀请界面示意图；

图5显示了另一个实施例中第一客户端的行程邀请界面示意图；

图6a-6b显示了又一个实施例中第一客户端的行程邀请界面示意图；

图7显示了一个实施例中第一客户端的行程邀请发送失败的界面示意图；

图8显示了一个实施例中第一客户端等待第二客户端反馈的界面示意图；

图9显示了一个实施例中第二客户端接收的行程邀请界面示意图；

图10a显示了一个实施例中第二客户端接受行程邀请的界面示意图；

图10b显示了另一个实施例中第二客户端接受行程邀请的界面以及与第一客户端的交互示意图；

图11显示了一个实施例中第二客户端位置发送失败界面示意图；

图12显示了一个实施例中第一客户端接收位置的界面示意图；

图13显示了一个实施例中第一客户端接收位置后规划路径的界面示意图；

图14显示了一个实施例中路径更新的第一客户端和第二客户端界面示意图；

图15显示了一个实施例中行程邀请完成的第一客户端和第二客户端界面示意图。

【具体实施方式】

对于附图中的标号，相同或类似的标号用于指示相同或类似的部件。在下文的描述中，在多个实施例中描述了多个操作参数和部件。这些具体的参数和部件仅作为示例包括在本文中而并不意味着限定。

根据需要，在此公开本发明的详细实施例；然而，应理解的是，所公开的实施例仅仅是本发明的示例，其中，本发明可以以各种替代形式来实现。附图无需按比例绘制；一些特征可被夸大或最小化以示出特定组件的细节。因此，在此公开的具体结构和功能细节不应被解释为具有限制性，而仅仅作为用于教导本领域技术人员以多种方式利用本发明的代表性基础。

如背景技术部分所提及的，随着科技的发展，目前出行服务的提供平台能够为用户提供更多的便利。一般的操作是通过用户发出需求的订单，平台接收需求订单并以各种方式分派订单来完成交易。一个或多个用户也可以通过平台完成拼车交易并相互分享用车费用，节省成本。然而，本申请的发明人意识到，以上的各种平台都是基于完成交易，而不能为车主提供接送熟人的便利。此外，以上平台的使用要求驾驶员和乘车人都要使用该平台，对于一些未安装同款应用的用户之间不能提供便利。在一些情况下，当车主要接送年长者例如父母、祖父母等情况下，需要搭乘的客人可能并不熟悉新的应用的使用方法，也不知道如何清楚地表达位置，车主需要多次电话等沟通其位置，非常不便，也不利于交通安全。基于现有技术中的一个或多个问题，本申请的发明人在一个或多个实施例中提供了一种行程邀约的装置、系统以及方法，相信其能解决现有技术中的一个或多个问题。行程邀约可以指一方对特定的另一方发起的行程邀请，接乘邀请，接人请求或者邀请。

下面将结合附图说明本申请的一个或多个实施例。流程图说明系统所执行的过程，可以理解的是，流程图的执行并不需要按照顺序进行，可以省略一个或多个步骤，也可以增加一个或多个执行的步骤，以及可以以顺序或者相反的顺序，甚至在一些实施例中可以同时来执行一个或多个步骤。

下面的实施例中可涉及“第一客户端”“第二客户端”“车主”“乘客”，在一个或多个实施例中，其用于说明行程邀约的双方之间的交互，在一些情形下，角色可以交换而不脱离本申请的精神实质。

下面的实施例中所涉及的车辆，可以包括各种类型的载客车辆(诸如，跨界多功能车辆(cuv)、运动型多功能车辆(suv))、巴士、卡车、休旅车(rv)、船、飞机或用于运输人或货物的其他移动机器以及其组合。

本申请所涉及的定位技术可以包括但不限于gps即全球定位系统，全球卫星导航系统，无线保真定位系统、罗盘导航系统等定位技术以及组合。

图1显示了一个或多个实施例中的行程邀约系统100中客户端交互示例。如图所示，在一个实施例中，提供一种可用于行程邀约的系统100。系统100可包括服务器端102，与服务器端102相通信的第一客户端104，第一客户端104可包括例如手机104a，例如车辆计算机系统/车机104b，以及与服务器端102相通信的第二客户端106。服务器端102可常规地具有计算机可读存储介质和处理器，以便于存储数据指令以及处理数据。可以理解，本申请在此处或者其他位置处所涉及的“服务器”或者说“服务器端”可以是提供计算机服务的一种设备，响应服务请求并可以进行处理的一种实体的或者虚拟的计算机端。其可以包括实体的真实的物理设备，也可以包括云服务器，在云平台上执行计算。云平台可以包括私有云、公有云、混合云、社区云、行业云、中间云，本申请中的服务器或者服务器端并不特指，可以是以上一个或多个的混合，只要其能够提供所需求的通讯存储和计算服务。而其中上述的第一客户端104、第二客户端106可以为任何形式的移动设备、漫游设备等。在一个实施例中，其中第一客户端104可以是车主端或者说驾驶员端或者车辆一端的同乘人员(在一些实施例中，其可以被统称为车辆人员一端)，第二客户端106可以是乘客端。其中车辆人员端具体可以包括多种形式的终端，例如可以包括手机、车辆计算机系统(vcs)(例如下面参考图2所描述的vcs1)、车载导航设备(例如下面参考图2所描述的车机导航设备60、或者个人导航设备54)等。而乘客端106也可以包括手机等便携式设备的方式。

继续参考图1，如箭头108所显示的信息流向，服务器端102可以通过网络获取第一客户端104(例如图示的104a，可以理解104b或者其他形式的第一客户端104均可以发起行程邀请)的行程邀请。与一般行程共享的软件平台所不同的是，第一客户端104发送的行程邀请是针对或者指向特定的或者具体的第二客户端106发起行程邀请，而不是在一个平台发布不特定人可见的、可选择回应的行程或者路径。而第二客户端106或者说乘客端可以通过手机等移动设备106来接收行程邀请。如箭头110所显示的信息流向，服务器端102可以进一步将行程邀请以例如短消息等即时通信方式的形式发送至图示的第二客户端106。第二客户端106接受行程邀请时，如箭头112所显示的第二客户端106的地理位置可被同步至服务器端102。进一步地，如箭头114所显示的，第一客户端104可以接收到服务器端102的指示第二客户端106的地理位置的地图的同步信息，从而可以确定第二客户端106的位置并在后续规划路径。在图1中示意性地显示了由车机104b接收地理位置，本领域内技术人员可以理解也完全可以采用手机104a或者其他车辆人员的装置接收地理位置并进行导航。或者在一些情形下第一客户端104a与车机104b可以任何可行的方式互联，从而可以任意一者接收第二客户端106的地理位置并进行路径规划与导航。规划路径可以在服务器端102完成，也可以在第一客户端104完成。当然，服务器端102或者第一客户端104可相应地包括存储器以及指令、以及处理器用于完成路径计算和优化。

此外，本领域内技术人员可以理解，在一个或多个实施例中，第一客户端和/或第二客户端，无论手机端或者车机端均可以安装有导航应用，该导航应用可以是独立的应用，也可以包括嵌入在其他应用中的导航功能，本文并无特别限制。在此处或者其他位置处，可穿插使用术语“地图界面”或“导航界面”以表示所进入的可为用户指引路径的地图页面。

在图1所示的实施例中，第一客户端104和第二客户端106通过服务器102完成行程邀请的发送，地理位置的确认，其中行程邀请可以包括指向服务器端地图的链接或者网址，该链接或者网址指向的对象对第一客户端104和第二客户端106都可见。当然在另一些实施例中，该链接或网址所指向的对象可仅对第一客户端104可见。在一个或多个实施例中，第一客户端104可进入在线或者离线的电子地图，电子地图可实时或者选择性地与服务器端102的地图同步。在此处或者其他位置处的术语“发送”可广义地包括通过合适的网络传播消息，在一个或多个实施例中，发送的涵义包括了同步。此外，服务器端地图可以指代以合适的方式存储在如上所提及的服务器设备上的电子地图。在此实施例中，后续路径的计算可以通过第一客户端104本身或者服务器102来完成。

在一些实施例中，第一客户端104和第二客户端106的交互可以均通过网络直接完成。例如第一客户端104可以发送包括网络链接的行程邀请给第二客户端106，而第一客户端104也可以进入该网络链接并实时地查看第二客户端106的接受状态以及向其分享实时位置。换句话说，可以通过网络电子地图来完成相互的定位以及位置的分享，当然在此实施方式中，网络链接所关联的电子地图的后台需要提供相关的权限分配以及管理单元，以确保第一客户端104、第二客户端106能够具有合适的相互可见的权限而不影响他人的使用。

尽管在上面的实施例中，显示了第一客户端104、第二客户端106通过服务器102交互，并通过服务器端102所存储的地图完成位置的定位确认和交互，在另一个实施例中，如虚线116所表示的，第一客户端104与第二客户端106也可以不通过服务器端的地图而相对地、更为直接地交互。在此实施例中，行程邀约系统100也可包括第一客户端104与第二客户端106。第一客户端104类似地可包括具有可执行指令的计算机可读存储介质，以及与该计算机可读存储介质通信的处理器。其中可执行指令可以配置为当执行时使得处理器：获取用户在第一客户端104的输入，发起针对第二客户端106的行程邀请。该行程邀请包括第一客户端识别信息以及针对第二客户端106的地理位置分享请求。该地理位置分享请求可以是文字形式或者链接或者任何其他合适的形式。所谓地理位置分享请求也就是请求第二客户端106以合适的方式反馈其地理位置。在一个或多个实施例中，“地理位置分享请求”可以指一方比如第一客户端104对于另一方第二客户端106，即请求第二客户端106向其分享第二客户端106地理位置的请求，其中在此过程中第一客户端104可以不向第二客户端106公开或者分享第一客户端104自身的地理位置。在另一些实施例中，“地理位置分享请求”可以是“地理位置共享请求”。“地理位置共享请求”可以包括在请求第二客户端106分享其位置的同时，将第一客户端104自身的地理位置大体上同时进行分享。这样即可允许第一客户端104和第二客户端106在位置共享后可见彼此的位置，以及进一步地了解实时位置变化。在此实施例中，行程邀请可以短消息、微信消息、移动终端上所装有的即时通讯app消息等任何合适的形式发送至第二客户端106。其中短消息可以包括邀请人的手机号码以及是否同意分享位置的问询。如双向箭头116所表示的，第二客户端106则可以直接反馈的方式将地理位置反馈或者发送回第一客户端104。

在一个或多个实施例中，地理位置的反馈可以包括多种方式。除了在上述实施例中所提及的，通过网络链接来标记自身地理位置之外，还可以包括其他可行的方式。如上提到的，第一客户端104和第二客户端106的定位技术可以包括但不限于gps即全球定位系统，全球卫星导航系统，无线保真定位系统、罗盘导航系统等定位技术以及组合，在一个实施例中，第二客户端106可以识别自身的地理位置，(如同现有技术中已经能够通过便携式移动设备识别其地理位置一样，其具体原理在此不再赘述)，并将地理位置以经纬度或者其他方式的位置表示的方法通过数据短消息的形式发送给第一客户端104。第一客户端104相应地包括处理器配置用于将接收到的数据信息解读为地理位置以及将地理位置标记至所述第一客户端104的地图界面。

在又一些实施例中，第二客户端106还利用其所包括的硬件软件设备等向第一客户端104发送可识别位置的照片。例如在一个情形下，第二客户端106可以拍摄或者通过网络选择附近具有标志性的建筑或者环境照片，以便于第一客户端104对照片与实景地图场景的比对与匹配并进一步识别第二客户端106所处的位置，或者以其他方式来识别标志性建筑所处的位置。在其他实施例中，还可以通过蓝牙，近距离通讯装置等信号的识别来进一步定位第二客户端106的位置。以上仅仅列举了一些可行的实施方式，本领域内技术人员可以预想到多种的变形，只要能够实现地理位置的分享即可。这样的直接交互的实施例有利于网络覆盖并不好的应用场景，特别是4g，5g网络没有覆盖或者说网络状况差的情形。如此，本方案的应用并不要求第二客户端106安装有与第一客户端104对应的特定软件，也不要求第二客户端106可以如上述实施例中打开网络链接以及将地理位置定位到服务器地图上。此外，对于第一客户端104在使用离线地图的情形下，第一客户端104并不会保持与服务器102的地图同步，由此，第一客户端104和第二客户端106之间直接的信息交换则为上述方案实施提供了便利。第一客户端104的后续路径的计算可以在手机或者车机完成。

此外，本领域内技术人员可以理解，在一个或多个实施例中，第一客户端104所发出的行程邀请也可以进一步包括请求第二客户端106分享其地理位置以及其目的地，当第二客户端106接受行程邀请时，除了将第二客户端106当前所在的地理位置/接乘位置/乘车位置发送到第一客户端104之外，还可以将第二客户端106的期望的目的地发送到第一客户端104，第二客户端106的目的地发送可以与第二客户端106当前所在的地理位置/接乘位置/乘车位置同时发送，或者也可以分步骤进行。例如在一个实施例中，第二客户端106的当前地理位置和目的地以路线形式显示在第一客户端104的地图界面/导航界面上，第一客户端104可以将第二客户端106的地理位置设置为途径点，而将第二客户端106的目的地作为行驶目的地。在另一个实施例中，第一客户端104也可以将第二客户端106的地理位置和目的地均作为导航的途径点。

下面将参考图2为例介绍车辆计算机系统(vcs)，以及与漫游设备、移动设备、网络等的交互示例。

参考图2，说明了用于车辆31的车载计算机系统(vcs)1的示例框式拓朴图。这种基于车辆的计算机系统1的可以为例如由福特汽车公司制造的sync系统，或者任何其他公司开发的其他信息娱乐系统等。可以理解的是，以上的sync系统或者其他信息娱乐系统可设有基于车辆的计算机系统的车辆可包含位于车辆中的可视前端界面4。用户还可通过例如触摸屏与该界面(如果有的话)交互。在另一说明性的实施例中，通过按压按扭、口头对话和语音合成进行交互。本申请一个或多个实施例中的语音交互可通过上述车载计算机系统vcs或者基于云端计算机系统来完成。

在图2中所示的说明性实施例1中，处理器3控制车载计算机系统的运转的至少一部分。设在车辆中的处理器允许车载处理指令和程序。此外，处理器3连接至非持久存储器5和持久存储器7。在这个说明性实施例中，非持久存储器为随机存取存储器(ram)并且持久存储器为硬盘驱动器(hdd)或闪存。

处理器还设有多个不同的输入，允许用户与处理器交互。在此说明性实施例中，设有麦克风29、辅助输入25(用于输入33)、usb输入23、gps输入24、和蓝牙输入15。还设有输入选择器51以允许用户在多种输入之间切换。在对麦克风和辅助连接器的输入传递至处理器之前通过转换器27将其从模拟信号转换为数字信号。尽管未显示，与vcs通信的多个车辆组件和辅助组件可使用车辆网络(例如但不限于can总线)以向vcs(或其组件)传递数据或从其接收数据。

车辆计算机系统可以包括与多种类型的计算器可读的存储装置或媒介通信的微处理器或中央处理单元(cpu)。计算器可读的存储装置或媒介可以包括只读存储器(rom)、随机存储器(ram)和保活存储器(kam)的易失和非易失存储器。可以使用任何数量的已知存储装置(比如能存储数据的可编程只读存储器(prom)、eprom(电可编程只读存储器)、eeprom(电可擦除可编程只读存储器)、闪存或任何其它电子、磁性、光学或者组合式存储装置)实施计算器可读的存储装置或媒介。

对系统的输出可包括但不限于视觉显示器4和扬声器13或立体声系统输出。扬声器连接至放大器11并通过数字-模拟转换器9从处理器3接收其信号。还可分别沿19、21处所示的双向数据流输出至远程蓝牙设备(例如pnd54)或usb设备(例如车辆导航设备60)。

在一个说明性实施例中，系统1使用蓝牙收发器15与用户的漫游设备53(例如蜂窝电话、智能电话、pda等)通信17。漫游设备53可随后用于通过例如与基站57的通信55来与车辆31外部的网络61通信59。在一些实施例中，基站57可为wifi接入点。

信号14代表了漫游设备和蓝牙收发器之间的示例性通信。

可通过按钮52或类似输入指示漫游设备53和蓝牙收发器15的配对，这样，指示cpu车载蓝牙收发器将与漫游设备中的蓝牙收发器配对。

可利用例如与漫游设备53相关联的数据计划(data-plan)、声载数据(dataovervoice)或双音多频(dtmf)音调在cpu3和网络61之间传递数据。可替代地，可能需要包括具有天线18的车载调制解调器63以便通过语音频带(voiceband)在cpu3和网络61之间传递16数据。随后，漫游设备53能够通过例如与基站57的通信55用于与车辆31之外的网络61通信59。在一些实施例中，调制解调器63可与基站建立通信20用于与网络61通信。如非限制性示例，调制解调器63可为usb蜂窝调制解调器并且通信20可为蜂窝通信。

在一个说明性实施例中，处理器可设有包括应用编程接口api的操作系统以与调制解调器应用软件通信。调制解调器应用软件可访问蓝牙收发器上嵌入模块或固件以完成与远程蓝牙收发器(例如在漫游设备中发现的)的无线通信。蓝牙是ieee802pan(个域网)协议的子集。ieee802lan(局域网)协议包括wifi并且与ieee802pan具有相当多的交叉功能。两者都适合于车辆内的无线通信。可在本领域使用的另一通信方式是自由空间光通信(诸如irda)和非标准化消费者ir协议。

在另一实施例中，漫游设备53包括用于语音带或宽带数据通信的调制解调器。在声载数据的实施例中，当正在传输数据期间漫游设备的主人对设备说话时，可执行已知为频分复用的技术。在其它时间，当主人没有使用该设备时，数据传输能够使用整个带宽(在一个示例中为300hz至3.4khz)。

如果用户具有与漫游设备相关联的数据计划，该数据计划可能允许宽带传输且系统可使用更宽的带宽(加速数据传输)。在又一实施例中，漫游设备53被安装至车辆31的蜂窝通信设备(未显示)所代替。在又一实施例中，漫游设备53可为能够通过例如(而非限定)802.11网络(例如wifi)或wimax网络通信的无线局域网(lan)设备。

尽管频分复用对于车辆与互联网之间的模拟蜂窝通信而言会是常见的并且仍在被使用，但其已经很大程度上被用于数字蜂窝通信的码域多址(cdma)、时域多址(tdma)、空域多址(sdma)的混合体所替代。这些都是itumt-3000(3g)兼容标准，并且，为静止或者行走的用户提供高达2mbs的数据速率，并为在移动的车辆中的用户提供高达385kbs的数据速率。3g标准现在正被高级mt(4g)所替代，其中，所述高级mt(4g)为在车辆中的用户提供10mbs的数据速率并为静止的用户提供1gbs的数据速率。而当前逐步采用的5g通讯标准将会相比4g更显著地提高数据传输的速度以及提升网络的容量。本申请在此处或者其他位置处所涉及的通信方式当理解为包括且不限于上述例如3g、4g、5g等标准下的通信。如果用户具有与移动装置关联的数据计划，则所述数据计划可允许宽带传输且系统可使用宽得多的带宽(加速数据传送)。在另一实施例中，移动装置53被安装至车辆31的蜂窝通信装置(未示出)所替代。在另一实施例中，nd53可以是能够通过例如(而非限制)802.1lg网络卿wifi)或wimax网络进行通信的无线局域网(lan)装置。

在一个实施例中，传入数据可经由话上数据(data-over-voice)或数据计划(dataplan)而通过移动装置、通过车载蓝牙收发器来传送并进入车辆的内部处理器3。例如，在某些临时数据的情况下，数据可被存储在hdd或其它存储介质7上，直至不再需要所述数据时为止。

可与车辆以接口互联的另外的源包括:具有例如usb连接56和/或天线58的个人导航装置54、具有usb62或其它连接的车辆导航装置60、车载gps装置24、或与网络61连接的远程导航系统(未示出)。usb是一类串行联网协议中的一种。ieee1394(火线^tm(苹果)、1.link^tm(索尼)以及lynx^tm(德州仪器))、eia(电子工业协会)串行协议、ieee1284(并行端口)、s/h)if(索尼/飞利浦数字互连格式)和usb-1f(usb开发者论坛)形成装置-装置串行标准的骨干。多数协议可针对电通信或光通信来实施。

此外，cpu可与各种其它的辅助装置65进行通信。这些装置可通过无线连接67或有线连接69来连接。辅助装置65可包括但不限于个人媒体播放器、无线保健装置、便携式计算机、移动装置、遥控钥匙(keyfob)等。

此外或可选择地，可使用例如wifi(ieee803.11)收发器71将cpu连接到基于车辆的无线路由器73。这可允许cpu在本地路由器73的范围中连接到远程网络。

在一个或多个实施例中，其中漫游设备53、个人导航设备54、车载导航设备60、车载计算机系统可以安装或者调用有本申请一个或多个实施例中的应用软件，从而可提供本申请一个或多个实施例中行程邀请的功能。车载计算机系统或者其他形式的个人移动终端可以与网络61连接，并与服务器端通信以实时地同步地图。当然，在一个或多个实施例中，上述的车载计算机系统或者其他形式的个人移动终端可以装有离线地图，并可以利用离线地图以及本身所具有的计算功能来完成定位。在一个或多个实施例中，车载导航设备60、车载计算机系统等车载的设备终端的一个或多个可以简略地称为车机。在一个或多个实施例中，也可以在个人导航设备中装有第一应用软件并通过有线或无线(例如蓝牙)等连接至车机上。

除了具有通过位于车内的车辆计算机系统执行的示例程序，在某些实施例中，示例程序可通过和车辆计算机系统通信的计算机系统执行。这种系统可包括但不限于无线装置(例如但不限于移动电话)或者通过无线装置连接的远程计算机系统，例如但不限于上下文中所提到的服务器，云端，云端服务器，云平台等。在某些实施例中，取决于系统的特定实施的特定组件可执行程序的特定部分。通过示例并不限制的方式，如果程序具有与配对的无线装置发送或接收信息的步骤，那么无线装置有可能不执行程序，因为无线装置不能与自己发送和接收信息。所有的解决方案中，可预想至少位于车内的vcs自身能执行示例程序。

在一个或多个示例中，车辆vcs和/或用户的漫游设备均可以被称为“客户端”。术语“客户端”主要用于在本申请的一个或多个实施例中说明适用于发起乘车邀请，接收乘车邀请，发起接人邀请，接收接人邀请的通讯工具。术语“第一客户端”和“第二客户端”主要用于描述实施例中的双方的交互过程，在其他实施例中，“第一客户端”和“第二客户端”的角色可以互换。文中可穿插或替代性地使用术语“行程邀请”“搭乘邀请”，以表示一方对另一方所发送的或者发起的搭乘车辆的邀请。在一些实施例中，行程邀请也可以表示需要搭乘车辆的邀请，或者说需要搭乘车辆的请求。

图3显示了可用于图1所显示的行程邀请系统中客户端之间交互的示意性方法200的流程图。如图3以及如上所述的，第一客户端104可以为多种形式的移动终端。例如其可以是便携式的移动设备形式的移动终端104a，也可以是嵌入车辆的计算机系统或者后续安装的车载移动终端104b(例如上述的vcs、车载导航设备等)。移动终端104a可通过所安装的第一应用(例如但不限于“fordpass”“福特派”)来进入行程邀请的功能。当用户手机上安装有该第一应用时，用户可以进入第一应用，并找到功能入口202。在一个实施例中，该第一应用打开后即展现以地图为背景的搜索页面，并在页面的合适位置设置行为召唤按钮，用户可以在搜索框或者通过行为召唤按钮来进入行程邀请功能。上述以及其他位置处的“按钮”并非特指具体的物理按钮，而本领域内技术人员可以理解其实质，例如其可以为显示在显示器/显示屏上的虚拟的可操作的选项。可以理解，虚拟选项可以通过合适的方式实现。例如以上各种形式的移动终端可包括软件或应用，或者说存储于存储介质的指令，当执行这些指令时，可以使得一个或多个处理器在相关移动终端的对应界面显示以上的预定的虚拟选项。接着用户在步骤204可选择是否将手机通讯录与该第一应用同步。若用户在步骤204选择授权通讯录同步，则在此步骤206，在当前应用界面即可通过输入乘客手机号、输入乘客姓名等方式来发起行程邀请。用户输入可以通过多种方式进行，例如但不限于语音输入、手动文字输入等。若用户选择拒绝授权通讯录的同步，则用户依然可以通过输入手机号进行联络。

在一个实施例中，如果用户通过车载移动终端104b来发起行程邀请或者说搭乘邀请，则可以通过多种方式进入该功能模块。在一个实施例中，车载移动终端104b可以类似地装设上述的第一应用，例如但不限于fordpass，并通过上述类似的方式进入邀请功能。而在另一些实施例中，例如图3所显示的，在一个情形下，也可通过导航界面的地图入口208上设置的行为召唤按钮可以进入行程邀请功能，下面将进一步结合附图描述。在此情形下，也可以询问用户是否授权通讯录与正在进行的应用的同步。在步骤210选择授权通讯录同步，可以上面描述的实施例中类似的方式，在当前所在的地图界面即可通过输入乘客手机号、输入乘客姓名等方式来发起行程邀请，若用户选择拒绝授权通讯录的同步，则用户依然可以通过输入手机号进行联络。如上所述，手机号输入依然可以通过语音或者手动等合适的方式进行，对于用户来说，语音交互能够提供额外的便利。例如，用户可以在界面中通过语音发起行程邀请，可以通过预定义的词语等触发消息的发送，来进入相应的行程邀请功能。在地图界面进入行程邀请的功能能够为车辆驾驶员提供便利，车辆中人员无需退出当前的地图界面而发起联络，可直接在地图界面发起联络并定位需要接人的位置。

在一个实施例中，用户可以将便携式移动设备例如104a或者其他的移动设备与车机104b通过有线、无线等任意合适的方式互联，从而将用户便携式移动设备上的一些应用映射到车机104b的显示模块。在进入行程邀请功能时，用户还可以在通讯录入口212进入该功能。在一个实施例中，在下面附图5显示了系统包括与第一客户端的通讯录联系人(例如但不限于联系人详情界面，车载蓝牙通讯录界面等)相关联的邀请选项按钮或者说邀请选项。该选项可邻近联系人设置，每一个通讯录联系人都对应一个邀请选项，便于用户的操作，就如同拨打电话一样便捷。

通过选择通讯录联系人而点击邀请选项即可触发邀请发送。本领域内技术人员可以理解点击邀请选项只是一个示例，也可以通过其他合适的方式激活邀请选项，例如语音或者手势等方式来激活选项。在又一个示例中，用户也可以在通话界面入口214进入该功能，移动设备104a或者车机104b可以包括在通话界面下与第一客户端的联系人相关联的邀请选项。所谓通话界面，一个示例可以指拨通电话正在通话中的界面，通常此界面可以选择挂断、保持等，通过在此增加邀请选项按钮更进一步便于用户发出邀请。当然本领域内技术人员可以理解，通话界面可以包括多种形式，例如但不限于车载蓝牙电话，手机通话界面，当前通话界面，历史通话界面等。

在一个情形下，乘客通过电话联络驾驶员/车辆人员一端，希望驾驶员能够在x地点接人，在没有提供本申请实施例的通常场景是驾驶员在通话后，往往还是需要耗费很大精力再次沟通，确定精确地点，如果交通状况等发生变化或者乘客位置有所变化则接人的过程变得更加耗费精力。而在本申请的实施例教导的情形下，驾驶员可以在与特定联系人通话中的页面，点击(包括如上所述的其他合适的方式触发)邀请选项按钮可以便利地发出行程邀请，并进一步通过地理位置的确定，省却了更多沟通的麻烦。当然，通过通讯录入口或者通话界面入口进入行程邀请时，不需要额外询问是否授权通讯录的同步，因为本身在步骤已经处于通讯录中。本领域内技术人员可以预想到，以上的车机的入口同样地也可以在用户便携式可移动设备104a上实现。在不同的实施例中上述的一个或多个行程功能或者搭乘功能的进入方式可以单独使用，或者合并使用，也可以根据需要设置更多或者更少的功能入口。

继续参考图3，在一个实施例中，当第一客户端104(104a或者104b)为车辆人员端，而当车辆人员端(包括车主/驾驶员/用户等)通过第一客户端104(104a或者104b)进入了相关的功能入口，例如入口202，208，212，214，可进一步在步骤216处发起行程邀请或者说搭乘邀请。行程邀请的信息将会发送到第二客户端106，通常可以是手机端。当然，本领域内技术人员可以理解，对于第二客户端106同样地并没有具体限制，其可以为手机、可穿戴设备等形式的移动终端。在一个实施例中，行程邀请是通过短消息发送。而短消息中包括了指向电子地图的html链接。当然本领域内技术人员可以预想到任何合适的变形，只要能够包括或者提供进入地图的地址即可。在另一些实施例中，行程邀请可通过微信、微博、qq或其它通用即时联络app等合适的方式发送。在一些实施例中，第一客户端104还会收到行程邀请是否成功发送的提醒。

在步骤218处，第二客户端106的用户可以点击该html/h5链接或者其他方式进入相应的预定的网址等，即可进入网络视图。该html链接可以指向服务器端在线地图，从而可以在该地图上反应第二客户端106的地理位置。可以预想的是，在一些实施方式中，车机可以搭载地图(例如车机可以运作为小型的服务器)，而链接也可以指向车机地图，从而第二客户端106也可直接反馈地理位置到车机地图。

在步骤220处，当第二客户端106的用户点击链接之后，可以进入提示界面，从而客户可选择是否授权同步当前的位置信息到地图(例如但不限于上述服务器端地图)，而在步骤222处，第二客户端106用户可以再次确认其自身所处的位置并确认发送给第一客户端104。在步骤224处，第一客户端104接收到位置信息的确认，可以更新当前的路径规划，既可以将该位置选择为目标位置，也可以选择为途径位置。当然，如果第二客户端106的用户不需要搭乘服务/行程服务，也可以选择拒绝行程邀请，在一个或多个实施例中，当第二客户端106拒绝行程邀请或者超过预定时间不接受邀请时，第一客户端104可接收到相关的提醒。在上述发送行程邀请包含链接的情形下，上述的链接也可以预先设置预定的激活时间期间，也就是说当第二客户端106超过例如3分钟不接受邀请时，上述的链接将失效，本领域内技术人员可以根据实际的需求而选择合适的提醒方式以及链接失效的时间。

在步骤226处，在一个实施例中，第二客户端106的用户还可以提供输入从而要求提供或者设置第二客户端期望的新乘车位置。比如第二客户端106的乘客可能根据身处的环境实际情况，希望找到更为便利的乘车点，因而通过例如拖拽地图上的标记而更新或者说确认新乘车位置。在此实施例中，可以针对第二客户端106发出是否想/希望/期望重新定位所述第二客户端106的乘车位置的问询选项，问询选项可以避免第二客户端106的误操作/误触发。而当第二客户端106确认其想/希望/期望重新定位时，重新定位所述第二客户端106的更新乘客位置，并进一步将第二乘客端106的新乘车位置发送给第一客户端104。当然，可以理解的是，第一客户端104可以接受或者不接受来自第二客户端106所提议/发送的新乘车位置。方法可以进一步包括将更新的新乘车位置展示给所述第一客户端104并询问所述第一客户端104是否接受所述新乘车位置，当第一客户端104确认时，在第一客户端104将所述新乘车位置确定为目标位置或者新的途径点。

在步骤228处，在一个实施例中，第一客户端104也可能发出更新的乘车地点建议，例如基于交通状况，停车难易程度等实际状况和实时的情形，第一客户端104也可请求第二客户端106移步到达更合适的乘车地点。方法可进一步包括接收所述第一客户端104的输入而重新定位所述第一客户端104的新接乘位置。在一个实施例中，方法包括接收第一客户端104的输入而对所述第一客户端104发出是否重新定位第一客户端104的新接乘位置的问询选项，再次问询可以避免用户误触发或者误操作的情形。而当第一客户端104确认重新定位时，重新定位所述第一客户端104的新接乘位置。可以理解的是，方法还可以包括将所述新接乘位置展示给所述第二客户端106并询问所述第二客户端106是否接受所述新接乘位置的步骤，当第二客户端106确认时，将该新接乘位置确定为目标位置或者途径点。

在步骤230处，如上所述，第一客户端104可以依据接收的新接乘位置来进一步更新路径的规划，可以理解在此实施例中，第二客户端106可以实时地观察到第一客户端104的位置，行程进行的状态，预计到达的时间等。

在步骤232处，第一客户端104可接到第二客户端106(乘客)，在此第一客户端104可以依照导航进行后续的行程，而至此行程邀请的方法已经完成。

以上是一个实施例中的示例性的方法的简要步骤的描述，可以理解，在其它实施例中，其中一个或多个步骤可以省略、变化、增加而形成新的实施方案而并不会脱离本发明的精神。下面将结合附图展示上述的一个或多个示例步骤中的第一客户端104和/或第二客户端106的操作界面示意图。

图4显示了一个实施例中第一客户端104a的行程/搭乘邀请发送的界面示例。该界面可以对应如上述参照图3所描述的示例性方法200中的步骤202、204、206以及216。如上所述，第一客户端104a可以是车主的便携式移动设备，而第一客户端104a可以安装有上述实施例中的第一应用，例如fordpass。通过打开fordpass的功能，可以通过一个或多个步骤进入地图界面。在如图所示的示例中，通过打开第一应用，可以进入地图为背景的检索页面，而在左下角或者其他合适的位置设置有行为召唤按钮302。通过点击或者其它合适方式激活按钮302，即可进入搭乘邀请的发送页面304，如页面304所示，用户可以输入手机号来联系特定用户。尽管界面304中显示的是通过“发送短信”的方式联系，本领域内技术人员可以通过任何合适的方式来联系，例如通过微信、qq、微博等用户常用的软件来联络第二客户端106，当然短信的方式是一个更为普及，网络覆盖面广的通信方式。如界面306所提示的，用户当开始进入输入框编辑时，可收到是否同步通讯录的提醒，其对应方法200中的步骤204，用户在此可以选择同意或者不同意通讯录的授权与否。如果用户选择“我同意”，则在此可以使得手机通讯录与当前应用同步，从而如308所显示的，在后续的行程邀请发送的输入框内显示联络人的姓名和联系人号码信息，在后续交互时还可以通过语音来编辑和发送搭乘邀请。如果用户不同意同步通讯录，那后续操作依然可以进行，而需要用户手动或者语音等方式输入搭乘人员的手机号码。在一些实施例中，如果用户已经事先同意同步通讯录，则可以跳过步骤306而直接调用通讯录。

图5显示了一个实施例中第一客户端104b的搭乘邀请发送的界面示例。其可以对应如上述参照图3所描述的示例性方法中的步骤208、212、214以及216。第一客户端104b可以是车载计算机系统，可简称车机。其同样可以安装有上述实施例中的第一应用，例如fordpass，通过打开fordpass的功能，可以相类似的方式进入地图界面或者行程邀请界面，可参考如上针对图4的描述，在此将省略而不赘述。在另一个实施例中，第一客户端104b也可以内置离线地图、或者与服务器端同步的地图应用，并可通过地图界面中置入的功能召唤按钮进入到邀请发送的界面。

在图5所显示的示例中，通过打开车机104b，可以进入地图应用界面，而在左下角或者其他合适的位置设置有行为召唤按钮402。通过点击按钮402即可进入搭乘邀请的发送页面404，如页面404所示，用户可以输入手机号来联系特定用户。尽管界面304中显示的是通过“发送短信”的方式联系，本领域内技术人员可以通过任何合适的方式来联系，例如通过微信、qq、微博等用户常用的即时通讯软件来联络第二客户端106，当然短信的方式是一个更为普及，网络覆盖面广的通信方式。如界面406所提示的，用户当开始进入输入框编辑时，可收到是否同步通讯录的提醒，其对应方法200中的步骤210，用户在此可以选择同意或者不同意通讯录的授权与否。如果用户选择“我同意”，则在此可以使得手机通讯录与当前应用同步，从而如408所显示的，在后续的行程邀请发送的输入框内显示联络人的姓名和联系人号码信息，在后续交互时还可以通过语音来编辑和发送搭乘邀请。如果用户不同意同步通讯录，那后续操作依然可以进行，而需要用户手动或者语音等方式输入搭乘人员的手机号码。

图6a和6b显示了如上方法200的步骤212，214可对应的界面。在一个或多个实施例中，可以通过通讯录或者在拨通电话界面时进入行程邀请功能入口界面。如图6a显示的，用户可以通过通讯录界面下的行为召唤按钮502(或者说行程邀请选项)进入相关的行程邀请发送功能。图6b所显示的，也可以在与特定用户的通话中页面的行为召唤按钮602进入相关的邀请发送功能。可以理解的是，行为召唤按钮302，402，502，602可以设置在页面任何合适的方便用户使用的位置，也可以以任何合适的形式展现。例如可以在最近通话，拨号页面，通讯录页面，历史通话等页面添加行程邀请选项/功能入口。如图所示的实施例提供了通过短消息发送邀请，如在本申请其他位置所描述的，也可以通过其他合适的社交软件等完成消息的发送。

图7显示了当第一客户端104信息发送失败后的对发起人或者说第一客户端104的用户的失败提醒。在一些情形下，可能由于多种原因而未能成功联络联系人，例如网络问题，例如号码错误等，此时，将反馈至车主联络失败。该提醒可以是文字或者语音形式。提醒上可以包括消除按钮或者图示的知晓按钮，以便于用户确认知晓联络失败，从而决定发起新一轮的邀请。

图8显示了当第一客户端104成功地通过例如短消息发送了行程邀请后所显示的页面的示例。如图所示，当第一客户端104成功发送行程邀请后，当再次点击行程邀请的行为召唤按钮702后，将在例如704的位置显示当前短信息已经发送，在等候乘客反馈接人位置的信息提醒。当然，本领域技术人员可以理解的是，也可以有其他形式的合适的提醒，例如消息发送成功，第一客户端104还可以有其他选项，例如取消行程，联系乘客等合适的选择。也可以显示进度条，例如目前处于行程发起阶段，等候对方反馈阶段等。也可以其他合适的方式提醒第一客户端104，比如第二客户端106未响应，超过3分钟链接失效，行程发起失败等实时通知，并提供给第一客户端104用户打电话联系，再次发送邀请等便捷操作的提示。

图9显示了第二客户端106所收到的信息的一个实施例。在图9所示的实施例中，当第一客户端104成功发送消息后，第二客户端106可收到行程邀请，其中包括第一客户端联系人的号码或者姓名，简单的邀请内容，以及指向一定url的html链接，该链接可指向电子地图。在一个实施例中，该链接指向存储于服务器的地图，在另一个实施例中，该链接指向存储于车机的地图。当然，如上述的实施例所提及的，在其他的实施例中，也可以有其他方式的消息提醒，比如是通过其他即时通讯软件而非通过短消息来发送邀请。在另一些实施例中，比如可以是第一客户端104针对第二客户端106发出请求，以请求第二客户端分享其位置，请求可以文字或者语音或者其他合适的方式而不以链接的形式发。第二客户端106可以通过拍照，录像，发送经纬度等定位的方式来反馈照片、数据、网络连接等给第一客户端104，而通过第一客户端104或者服务器102来计算第二客户端106所处的位置。直接将信息发送给第一客户端104的示例有益于当第一客户端104在使用离线地图，或者网络状况不佳的情形。

图10a显示了在一个实施例中，当第二客户端106收到图9所显示的消息而同意位置分享或者说授权位置分享时第二客户端106所进入的界面示意。当第二客户端106点击上述图9中所显示的链接后，即可以进入是否授权位置分享的问询，而经第二客户端106的确认将进入服务器端地图，并将其位置同步显示在地图上。服务器端地图可表示存储在任何合适形式的服务器上的电子地图。在一个实施例中，可以通过触摸第二客户端106的屏幕或者语音输入等重新定位第二客户端106实际所处的位置，当然，也可以通过拖拽图标来定位，或者通过移动底层的地图来定位第二客户端106的位置。可以经过再次问询确认第二客户端106希望将其位置发送至第一客户端104，将服务器端地图所显示的第二客户端106的相关位置发送到第一客户端104。在第一客户端104邀请第二客户端106单向地分享该第二客户端106的位置的实施例中，第一客户端104的位置对于第二客户端106可以是不可见的。而在本实施例中，第一客户端104的邀约则是位置共享的邀请，从而当第二客户端106同意位置共享后，从进入地图界面开始，第二客户端106即可查看邀请人/行程邀请发送人的车辆位置。当第二客户端106确定好位置后，可以发送位置给第一客户端104。

图10b显示了另一个实施例，其中当第二客户端106收到图9所显示的消息而同意位置分享或者说授权位置分享时第二客户端106与第一客户端104b的交互示意图。在此实施例中，当第二客户端106点击上述图9中所显示的链接后，即可以进入是否授权位置分享的问询，而经第二客户端106的确认将进入电子地图界面。如上文以及本文其他位置处所提到的，电子地图可以是存储于服务器的地图，或者其他合适形式存储的地图。与图10a的实施例不同之处在于，在此实施例中还在第二客户端106提供了位于地图界面的拍照选项802，拍照选项802可以进一步快捷地帮助第二客户端106拍摄街景图，从而辅助第一客户端104b定位第二客户端106所在位置。当用户选择使用拍照选项802后可以将街景照片804发送至第一客户端104b，街景照片804将作为小浮窗显示在第一客户端104b当前界面，第二客户端106的当前界面也可以显示接收到的街景照片804’。优选街景照片804’可以浮窗的形式展现在不妨碍导航的界面位置处。在一个实施例中，通过拍照选项802可以首先将第二客户端106所在地街景图发送到服务器，并经由服务器发送到第一客户端104b。

进一步参考图10b，在如图所示的实施例中，为了进一步便于用户之间的沟通，可以在第一客户端104b的当前页面提供电话拨打快捷键806，以便于第一客户端104b的用户方便地直接联络到第二客户端106的用户。可以理解，上述的拍照选项802、电话拨打快捷键806可以位于界面的任何合适的位置。尽管上面以第一客户端104b作为示例，可以预想到上述的方案可以应用于任何形式的第一客户端104或第二客户端106。在一些实施例中，在车辆用户端发起的乘车邀请中，拍照选项的激活还可以调用车载摄像头来获取期望的接乘点照片。该接乘点照片可以合适的方式发送到乘客端，以便于乘客更快速地发现车辆的位置。同样可以预想到的，接乘点照片可以独立地应用，或者结合地图来辅助乘客找到车辆的位置。

图11显示了第二客户端106位置发送失败的示例，当因为网络或者其他原因未能将位置成功发送给第一客户端104时，将会接收到图11所显示的位置发送失败的提醒。在其他的实施例中，此时可以增加提交数据或者编码形式的位置数据分享的步骤，例如可以询问“是否将经纬度数据通过短消息发送至xxxx”,如果用户同意，则可以通过短消息的形式提交第二客户端106的位置信息，而第一客户端104可以自行计算第二客户端106所在位置。在另一情形下，可以询问“是否将周围环境图片/视频通过app发送至xxxx”，以便于第一客户端104通过接收视频或者图片并通过实景比对来确定第二客户端106的位置。上述参考图10b的示例中提到了使用拍照选项来辅助第一客户端104辨认位置，而在此实施例中，照片、视频、经纬度数据等也可以单独或者以一个或多个的组合来独立地提供给第一客户端104以便于第一客户端104定位第二客户端106的位置。市场上也存在一些社交软件，允许利用无线网络或者蓝牙完成交互，本申请的一个或多个实施例也可以被应用于这样的软件获得优势。例如在网络不佳的情形下，可以询问用户是否通过蓝牙定位，和/或通过蓝牙传输地理位置。在此仅讨论了几个可能的实施例，本领域内技术人员当理解分享地理位置的方式不限于此。

图12显示了在一个实施例中第二客户端106成功分享位置后的第一客户端104b、第二客户端106示意性界面。在此实施例中，如图所示，第一客户端104b在此时可以接收到“已经接收到乘客位置”的相关提醒，而此时如果第一客户端104b的用户点击行程邀请按钮将会显示“行程状态为已经接收到位置信息”，“请规划行程”，“接乘客”，或者其他类似的消息提醒，使得第一客户端104b的用户知晓目前行程邀请的进度。当然，系统/第一客户端104b也可以通过进度条或者其他合适的形式来反馈在整个行程邀请功能中，目前所处的阶段。第一客户端104b或者驾驶员可以选择将乘客位置作为目的地，也可以选择作为途径点来完成对于导航的设置。当然第一客户端104b也可以选择取消行程，或者联系乘客，可以在第一客户端104b的当前界面提供联系乘客和取消行程的选项卡，也可以设置快捷拨号的选项以便于第一客户端104的用户更为迅速地联络到特定的联系人。在一个实施例中，同样的，在第一客户端104b操作期间，系统可以在第二客户端106显示车主确认路线的提醒，所以第二客户端106也可以实时地了解第一客户端104b的状态，所处的位置等。尽管上述具体使用第一客户端104b来做示例讨论，可以理解104a或者其他合适的客户终端同样可以进行相类似的设置。

图13显示了在一个实施例中，当第一客户端104选择了将第二客户端106的位置作为途径点或者目的地时的第一客户端104和第二客户端106所处的界面。其中，当第一客户端104选择了将第二客户端106的位置作为途径点或者目的地时，第一客户端104可在当前的导航界面进行导航，而导航信息以及实时位置的变化将反应给第二客户端106，因此第二客户端106可以实时地了解第一客户端104所处的位置。如上所述，在一个或多个实施例中，第一客户端104所发出的行程邀请也可以进一步包括请求第二客户端106分享其地理位置以及第二客户端106的期望的目的地，第一客户端104可以将第二客户端106的地理位置设置为途径点，而将第二客户端106的期望目的地作为行驶目的地。同样，第一客户端104也可以依据行程需要将第二客户端106的地理位置和目的地均作为导航的途径点，而将第一客户端104自身的期望目的地设为最终的目的地。

图14显示了在一个实施例中，第二客户端106发起的搭乘位置更新的实施例。如上结合图3所描述的步骤226，第二客户端106可以通过拖拽地图上的标记而更新位置/提供新乘车位置，也可以通过点击页面中的地点而发起更新位置，或者通过移动底层地图而调节新乘车位置。在此可以如图所显示的，提供行为召唤按钮/选项“更新位置”902，并且对第二客户端106发出是否重新定位所述第二客户端106的乘车位置的确认或者取消选项，问询的步骤可以避免第二客户端106的误操作。而当第二客户端106确认重新定位时，可以重新定位所述第二客户端106的更新乘客位置，并进一步将更新的乘车位置发送给第一客户端104。此时如图14所示，第一客户端104收到乘客更新了位置的提醒，在展示提醒给所述第一客户端104时可询问所述第一客户端104是否接受所述更新乘车位置，当第一客户端104确认时，则可以将新乘车位置确定为目标位置或者新的途径点。如果第一客户端104不确认该新乘车位置，则第二客户端也将收到拒绝提醒。

可以理解的是，尽管没有显示，第一客户端104也可以选择调整接乘的位置，当第一客户端104用户或者说驾驶员判断需要约定更加合适的接人地址，或者可能由于交通规制等原因，特定地点不可停车时，第一客户端104可以通过类似的操作而进行位置的更新，而第二客户端106也可以实时地看到第一客户端的地点建议以及实时的动向，为更便捷的搭车提供了有效的方案。

图15显示了一个实施例中，行程完成，当接到乘客后，第一客户端104b即可按照导航完成行程，同样第二客户端106也就是乘客端也可以点击完成行程，用户可以选择合适的方式退出界面。

以上的一个或者多个实施例涉及车主接载一个特定的联系人的实施方式。可以理解，在行程进行的过程中，车主也可以接载两个以上的特定的联系人。车主可以对两个以上的联系人发起行程邀请，并将两个以上联系人所分享的地理位置设置为途径点和/或目的地，并完成行程规划。

上述一个或多个实施例讨论了邀请对方乘坐车辆的示例，可以理解的是也由特定的需要搭车的用户发起请求，例如可以向对方发起接人的请求。换句话说，第一客户端可以是乘车人，第二客户端可以是车主或者驾驶员。如同上述示例中所描述的，比如在装有第一应用(如fordpass)的用户手机上，邀请选项按钮可嵌入在任意联系人卡片中，如对于一个sms联系人，可在联系人卡片中同时插入“行程邀请”“邀请接我”选项/行为召唤按钮，如果点击相关的按钮“邀请接我”，那可以通过网络或者经由服务器来发送消息给特定的相对应的联系人。类似的，如果联系人是微信联系人，那也可以在其中同时插入“行程邀请”“邀请接我”选项，不论点击任一选项，也可以通过云端来发送微信消息给该联系人，微信消息也可以包括类似的邀请人识别信息和链接，点击链接和接受邀请则可以通过服务器发送反馈给第一客户端。在邀请对方接我的实施例中，一旦邀请发送，车主或者驾驶员可以选择接受与否，并可以同样在地图页面中完成定位和接人的过程。当然，对于需要被接的一方也可以通过电话联系车主从而使得车主可以按照上述实施例中所描述的流程来发起邀请并规划合适的路径。当发起人为需要乘车的乘客一方时，在一个实施例中，当如上示例中进入“邀请接我”或者类似的功能后，可以触发请求信息的发送，该请求信息可以直接包含了发起人一方也就是乘客端的地理位置的消息，以便于更加有效率地完成沟通。该地理位置的消息可以包括如上所述的链接，可解读成地理位置的代码，图片，小视频等，其中一者或多个可单独或者组合应用以提供更便利的位置确认。

尽管上述的实施例主要以手机通讯录联系人为实施例来讨论，可以理解其他形式联系人，qq、微信等即时通讯社交软件也可以利用本发明获得优势。在一个实施例中，如果双方为微信联系人，也可以在微信界面发送行程邀请。其具体的实施方式可类似于上述的实施方式。通过提供行程邀请的行为召唤按钮，第一客户端例如邀请人可以给第二客户端(例如被邀请人)发送行程邀请，该邀请可以包括指向服务器端地图的链接，从而第一客户端也就是邀请人可以通过服务器端地图很容易定位被邀请人的位置。不同于微信中所提供的实时位置分享的功能，这样的行程邀请不要求邀请人或者说第一客户端(车主)从当前的软件或者地图界面退出来查看微信的实时位置分享，不需要驾驶员更多的分神，也不会干扰当前应用的导航软件，从而可以很方便地完成接人的任务。其他的社交软件同样可以利用本申请所提供的实施例获得优势。在社交软件和联络人纷繁复杂的当今社会，本申请的发明人考虑到车主或者驾驶人员与搭乘人员的实际需求，提供了不需要在同一软件平台下就能够完成的接乘和搭乘服务。甚至这样的更私人化的需求并无法使用商业交易软件平台例如优步、滴滴来得到满足，从而一个或多个实施例提供了方案并满足了特别是非商业交易的情形下的特定主体之间的接送服务。

虽然以上描述了示例性实施例，但这些实施例并不意在描述本发明的所有可能形式。更确切地说，说明书中所使用的词语是描述性词语而非限制性词语，并且应理解的是，可在不脱离本发明的精神和范围的情况下做出各种改变。此外，可将各种实现的实施例的特征进行组合以形成本发明的进一步的实施例。本领域中的技术人员可以对这些具体实施例进行多种改变、修改和变化而不脱离本申请权利要求限定的实质和范围。

权利要求中特别指出了被认为是新颖和非显而易见的特定组合和子组合。这些权利要求可涉及“一个”元件或“第一”元件或者类似特征。这样的权利要求应该被理解为包括一个或多个这种元件，既不要求也不排除两个或多个这种元件。描述的特征、功能、元件和/或特性的其它组合和子组合可以通过对当前权利要求的修改或者通过在本申请或相关申请中提出而主张权利。这样的权利要求，与原权利要求相比不论其更宽、更窄、等同或者不同，都应该被认为包括在本申请的主题中。