首页> 中国专利> 鉴于另一设备而向一个设备提供导航指令

鉴于另一设备而向一个设备提供导航指令

摘要

导航服务确定第一用户在第一时间意图从第一位置导航到共享目的地,并且确定第二用户在第一时间的阈值间隔内的第二时间意图从第二位置导航到共享目的地。导航服务使用电子通知来通知第一用户第二用户意图导航到共享目的地,从第一用户接收对于与第二用户协调到共享目的地的导航的电子请求,并响应于接收到该电子请求,鉴于第二用户朝着共享目的地的进度,向与第一用户相关联的设备提供到共享目的地的导航指引。

著录项

  • 公开/公告号CN112384757A

    专利类型发明专利

  • 公开/公告日2021-02-19

    原文格式PDF

  • 申请/专利权人 谷歌有限责任公司;

    申请/专利号CN201880095234.5

  • 发明设计人 T.德斯莱尔斯;S.福兹;

    申请日2018-11-07

  • 分类号G01C21/34(20060101);

  • 代理机构11105 北京市柳沈律师事务所;

  • 代理人金玉洁

  • 地址 美国加利福尼亚州

  • 入库时间 2023-06-19 09:54:18

说明书

技术领域

本公开涉及导航,更具体地,涉及鉴于前往同一位置的其他用户而为用户生成导航方向。

背景技术

如今,许多电子设备(诸如个人计算机、平板电脑、移动电话、作为专用设备提供或嵌入到车辆的头部单元中的导航器等)可以提供地理区域的数字地图以及用于通过开车、步行、骑自行车或使用公共交通工具导航经过地理区域的逐步指引。专用地理应用或“app”以及通用应用(诸如网络浏览器)可以使用本地存储的数据或从网络服务器接收到的数据来提供数字地图和/或导航指引。

这些应用和服务一般试图例如针对单个用户在时间和/或价格方面优化导航指引。当用户将其各自的车辆驾驶到同一目的地时,导航应用和服务向各个驾驶员提供独立的指导。此外,当人们(以“车队(caravan)”或“运输队(convoy)”中)一起驾驶多辆车时,驾驶员常常跟随领头车。

发明内容

当多方前往共同目的地时,本公开的导航服务协调导航。如下面更详细地讨论的,导航服务可以基于来自用户的明确请求或各种隐含信号,识别用户有可能在某个时间段内前往同一地点的情形。用户可以从同一出发位置或不同的位置前往同一目的地。在后一种情况下,导航服务可以识别路线的共享部分。在多车导航会话期间,导航服务可以向参与者提供各种类型的指导,包括对参与者当前位置的指示、由领头车辆确定的关于交通和道路状况的通知、关于沿途的停留的建议等。此外,导航服务可以确定各个用户的导航路线何时合并,并识别导航路线可以合并的潜在位置以及驾驶员可在哪里等待彼此。此外,在一些但不是全部参与者到达共享目的地之后,导航服务可以协调停车和其他相关活动。

这些技术的一个示例实施方式是导航系统用于协调多个用户之间的导航的操作方法。该方法的至少一些步骤可以由一个或更多个处理器执行。该方法包括:确定第一用户在第一时间意图从第一位置导航到共享目的地;确定第二用户在第一时间的阈值间隔内的第二时间意图从第二位置导航到共享目的地;使用电子通知来通知第一用户第二用户意图导航到共享目的地;从第一用户接收对于与第二用户协调到共享目的地的导航的电子请求;以及响应于接收到该电子请求,鉴于第二用户朝着共享目的地的进度,向与第一用户相关联的设备提供到共享目的地的导航指引。

在一些实施方式中,以上方法包括以下特征中的一个或更多个。确定第一用户意图导航到共享目的地包括确定第一用户和第二用户具有引用共享目的地的相应日历条目。确定第一用户意图导航到共享目的地包括确定第一用户与第二用户之间的电子消息收发引用共享目的地。确定第一用户意图导航到共享目的地包括从第一用户接收通过由第一用户操作的设备的用户界面提交的对于与第二用户协调到共享目的地的导航的请求。该方法包括将机器学习模型应用于与第一用户相关的第一数据和与第二用户相关的第二数据,以生成置信度得分,该置信度得分指示第一用户和第二用户将选择协调到共享目的地的导航的概率,第一数据和第二数据包括(i)来自相应用户设备的传感器数据、(ii)第一用户和第二用户的日历条目、或(iii)第一用户与第二用户之间的消息收发中的一项或更多项;其中通知第一用户第二用户意图导航到共享目的地是响应于确定置信度得分高于某个阈值。该方法包括确定第一用户将比第二用户更早到达共享目的地、以及向与第一用户相关联的设备提供第一用户将更早到达共享目的地的指示;在一些情况下,该方法进一步包括确定第一用户领先第二用户至少阈值距离或行驶时间、识别第一用户可等待第二用户的位置、以及通知第一用户识别到的位置;在一些情况下,识别第一用户可等待第二用户的位置包括沿着共享路线识别加油站,第一用户和第二用户都可以在某个时间段内到达该加油站。该方法包括确定从第一位置到目的地的第一路线和从第二位置到共享目的地的第二路线、识别对应于与第二路线共享的至少一部分第一路线的共享路线、以及向与第一用户和第二用户相关联的相应设备提供对共享路线的指示;在一些情况下,该方法还包括响应于确定与第一用户相关联的设备经历了共享路线的一段而与第二用户相关联的设备尚未到达该段,来获得该段的道路质量和/或交通数据、以及向与第二用户相关联的设备提供该道路质量和/或交通数据。该方法包括确定从第一位置到目的地的第一路线和从第二位置到共享目的地的第二路线、识别对应于与第二路线共享的至少一部分第一路线的共享路线、以及向与第一用户和第二用户相关联的相应设备提供对共享路线的指示。该方法包括确定第一用户有可能在前往共享目的地的途中停留、确定第一用户和第二用户可停留的位置、以及向与第一用户相关联的设备和与第二用户相关联的设备提供对该位置的指示。向第一用户提供到共享目的地的导航指引包括确定第一用户领先第二用户至少阈值距离或行驶时间、识别第一用户和第二用户可以在邻近的时间到达的点、以及修改导航指引以生成绕行,该绕行使第一用户相比于沿着第一用户的原始路线晚到达标识到的点。该方法包括响应于接收到电子请求而自动为第一用户和第二用户建立语音聊天。该方法包括确定从第一位置到目的地的第一路线和从第二位置到共享目的地的第二路线、识别对应于与第二路线共享的至少一部分第一路线的共享路线、确定第一用户已偏离共享路线而遵循针对一部分共享路线的绕行、以及基于该绕行修改针对第二用户的导航指引。该方法包括确定第一用户已到达共享目的地、以及向第一用户提供交互式提示以报告停车位。

这些技术的另一示例是一种系统,其包括一个或更多个计算设备以及存储指令的非暂时性计算机可读介质。当由所述一个或更多个计算设备运行时,所述指令使该系统执行根据以上权利要求中的任一项所述的方法。

这些技术的另一实施例是在计算设备中用于获得导航指引的方法。该方法包括从网络服务器接收加入多车导航组以前往共享目的地的邀请、以及通过用户界面显示加入多车导航组的邀请。如果用户接受加入多车导航组的邀请,则该方法包括向网络服务器发送用户接受了邀请的通知、以及在多车导航会话期间提供与计算设备朝着共享目的地的进度有关的更新并接收与多车导航组中的其他参与者朝着共享目的地的进度有关的更新。

这些技术的又一实施例是在计算设备中用于导航指引的方法。该方法包括:通过用户界面从用户接收对于提供到目的地的导航指引的请求;确定用户是否选择了多车导航选项,如果是,则发送对到目的地的导航指引的请求以及多车导航选项已被选择的指示。该方法进一步包括提供与计算设备朝着共享目的地的进度有关的更新、以及接收与多车导航组中的其他参与者朝着共享目的地的进度有关的更新。

附图说明

图1是其中导航服务在几个客户端设备之间协调多车导航的示例系统的框图;

图2是用于协调多车导航会话的示例方法的流程图,该示例方法可以在图1的系统中实现;

图3是用于识别潜在的多车导航会话的示例方法的流程图,该示例方法可以在图1的系统中实现;

图4是示例用户界面屏幕,当有机会参与多车导航会话时,图1的导航服务可以向用户提供该示例用户界面屏幕;

图5是另一示例用户界面屏幕,当有机会参与多车导航会话时,图1的服务可以向用户提供该另一示例用户界面屏幕;

图6是用于向参与多车导航会话的设备提供指导的示例方法的流程图,该示例方法可以在图1的系统中实现;

图7是示例数字地图,图1的服务可以生成该示例数字地图以示出参与多车导航会话的多方的位置和各自的导航路线;

图8是用于加入多汽车导航组的示例方法的流程图,该示例方法可以在图1的客户端设备中实现;以及

图9是用于请求具有多车导航选项的导航指引的示例方法的流程图,该示例方法可以在图1的客户端设备中实现。

具体实施方式

一般而言,本公开的导航服务可以在一个或更多个网络服务器和/或便携式设备中实现以提供多车导航指引。根据多车导航指引,参与多车导航会话的一个客户端设备的状态影响用于参与该多车导航会话的另一用户设备的导航指引。如下面更详细地讨论的,导航服务可以从用户接收明确的请求以导航到与一个或更多个其他用户共享的目的地,或基于各种隐含信号来检测多车导航的可能性。在多车导航会话期间,与一客户端设备相关并对用于另一个客户端设备的导航指引有潜在影响的信号可以包括该客户端设备的当前位置、客户端设备之间朝着共享目的地的进度差异、计划的和未计划的沿途停留、该客户端设备针对共享路线的特定部分检测到的交通和路况等。导航服务可以在导航期间以及在参与者之一到达共享目的地之后为多车导航会话中的参与者提供指导。

首先参照图1,系统100可以包括通过通信网络106耦合到各种客户端或客户端设备104A、104B、104C等的导航服务器102,通信网络106可以是诸如互联网的广域网(WAN)。

在一个示例实施方式中,客户端设备104A作为车辆的组件进行操作。例如,客户端设备104A可以是嵌入在车辆的头部单元中的导航设备,以提供地图绘制、导航、搜索和其他功能。在该实施方式中,客户端设备104A可以通信地耦合到车辆组件108,该车辆组件108可以包括指示位置、方向、速度、温度、车辆的各种操作参数(诸如轮胎压力或风挡刮水器是否已被激活)等的各种传感器110。

在另一种实施方式中,客户端设备104A是便携式计算设备(诸如智能电话),其通过有线或无线短距离网络接口(诸如通用串行总线(USB)或

客户端或用户设备104A可以包括一个或更多个处理器120、配置为通过网络106使用任何合适的协议与地图数据服务器102和其他设备进行通信的网络接口142。客户端设备104A还可以包括例如用户界面124,其配置为接收键入的输入、基于手势的输入、语音输入等,并配置为显示图像、输出音频以及生成触觉输出。在示例实施方式中,用户界面124包括触摸屏。此外,客户端设备104A可以包括非暂时性计算机可读存储器126和图形卡128(例如,包括一个或更多个图形处理单元或GPU)。存储器126可以包括持久性组件(例如,硬盘)以及非持久性组件(例如,RAM)。在其他实施方式中,客户端设备104A可以包括附加组件,或相反地,不包括图1所示的一些组件。类似地,客户端设备104B和104C可以是便携式用户设备、嵌入式设备等。

导航服务器102可以是实现为单个设备或设备组的网络服务器。这些设备中的一个或更多个可以包括一个或更多个处理器130和存储可在一个或更多个处理器130上运行的指令的非暂时性计算机可读存储器132。除了其他软件组件之外,这些指令还可以实现多车导航控制器140。更一般地,导航服务器102可以包括实现各种导航和地图绘制功能的任何合适类型的处理硬件。非暂时性计算机可读存储器132还可以存储机器学习(ML)模型142。多车导航控制器140可以利用ML模型142来识别可能需要多车导航的情况,如下面更详细地讨论的。

导航服务器102可以耦合到地图数据库150、兴趣点POI数据库152、用户配置文件数据库154和交通数据库156。数据库150、152、154和156中的每个可以在单个存储设备或多个存储设备中实现。

地理数据库150可以存储地图数据,该地图数据包括对用于各种地图特征(诸如建筑物和其他结构、道路、公园、水体等)的几何图形的描述。除了为车辆设计的道路之外,地图数据还可以描述自行车道、人行道、铁路路径、航运路线、航空公司路线等。地图特征可以以矢量图形格式或其他合适的可缩放格式来定义,图像根据该矢量图形格式以基于数学表达式的几何图元来描述。取决于实施方式,地图特征可以仅以二个维度(2D)定义,以三个维度(3D)定义为要应用栅格纹理的线框,以“两个半”维度(2.5D)定义为“挤出”到三维中的2D多边形,等。在一些情况下,地图数据还可以包括例如位图格式的栅格图像。此外,地图数据还可以包括文本标签和各种形式的元数据,诸如到远程资源的链接。

地理数据库150可以以一般对应于地理空间数据的2D组织的地图图块的格式将地图数据存储为四叉树。处于给定缩放级别的每个图块在下一级别被划分为四个图块,直到最高放大级别。类似地,可以使用八叉树来实现地理空间数据的3D组织,其中立方体容积包含处于某个缩放级别的地图几何图形,并被细分为处于下一缩放级别的八个立方体容积,这八个立方体容积中的每个通常包含更详细的地图几何图形。为了将地球表面映射到平面上以进行2D表现,可以使用墨卡托(Mercator)或另一合适的投影。尽管以下示例涉及组织成2D地图图块的地图数据,但是这些技术也可以扩展到组织成八叉树的3D地图数据。

POI数据库152可以存储各个地方的地理坐标。对于一些地方,POI数据库152可以存储业务数据,诸如营业时间、对所提供的产品和服务的描述、用户评论等。POI不必总是对应于业务,还可以包括地标(例如,纪念碑、喷泉)、著名建筑物和其他结构、活动地点等。此外,POI数据库152可以存储语音识别器模型,其可用来检测本地查询,例如本地POI的名称或其他本地常用短语。

用户配置文件数据库154可以存储针对客户端设备104A、104B、104C的用户的各种偏好和配置文件设置。这些设置之一可以指示用户是否对多车导航感兴趣。此外,在一些实施方式中,当用户已经表达了对多车导航的兴趣时,用户配置文件数据库154存储用户可与之参与多车导航的用户列表。

交通数据库156可以存储与道路的当前状况相关的信息。对于某个路段,交通数据库156可以存储例如对交通(畅通、中度、拥挤)、道路维修、车道封闭、事故等的指示。如下所讨论的,在领头车辆中操作的客户端设备在一些场景下向多车导航组中的其他客户端设备提供交通数据,并且导航系统在一些情况下可以使用该数据更新交通数据库156。

仍然参照图1,客户端设备104A的存储器126可以存储实现诸如地理应用160的各种软件应用的指令。地理应用160可以生成交互式数字地图,获得导航指引,响应于地理查询提供与地理定位的业务相关的数据,检索和显示诸如优惠券和要约的地理商业数据,等。地理应用160可以实现多车导航功能162,诸如请求客户端设备104A加入多车导航组、处理来自客户端设备104B和104C的加入多车导航组的邀请、向多车导航组中的其他参与者提供更新、从多车导航组中的其他参与者接收更新等。取决于实施方式,地理应用160可以例如作为独立应用或作为另一应用(诸如网络浏览器)的组件来操作。

除了实现地理应用160的指令之外,客户端设备的存储器126还可以存储地理数据164,该地理数据164包括用于离线覆盖的一个或更多个地理区域的地图图块、POI数据等。

导航服务器102,以及在一些情况下在相应客户端设备中运行的地理应用160的一个或更多个实例,可以作为本公开的导航服务的部分进行操作。下面讨论的方法中的一些方法可以在导航服务器102中实现,一些方法可以在地理应用160中实现,一些方法可以部分地在导航服务器102中且部分地在地理应用160中实现。

参照图2,本公开的技术的示例实施例中用于协调多车导航会话的方法200在导航服务器102的多车导航控制器140中实现。更一般地,方法200可以被实现为任何合适的设备或设备组中的导航服务的一部分。

方法200起始于块202,其中导航服务在某个时间段内检测多方想要导航到共享目的地的意图。为此,导航服务可以使用明确信号和/或隐含信号。此类信号的示例在下面参照图3进行讨论。在导航服务识别到多车导航会话中的两个或更多潜在参与者之后,在块204中,导航服务可以形成多车导航组,并因此将通知转发给对应的客户端设备,例如图1的客户端设备104A-C。

在块206中,导航服务可以在多车导航会话期间向客户端设备提供支持。如下面参照图4更详细地讨论的,导航服务可以向客户端设备通知其他客户端设备的当前位置、识别导航路线的由客户端设备共享的部分(在客户端设备从不同的出发位置起程的情况下)、监测多车导航组中的车辆之间的距离、识别并建议驾驶员可以见面的位置等。

在块208中,在一些但不是所有的客户端设备到达共享目的地之后,导航服务可以在块208中向一些或所有的参与者提供进一步的支持。例如,多车导航组可以包括客户端设备104A、104B和104C的用户。在客户端设备104A的用户到达目的地之后,导航服务可以自动提示该用户提供停车位的指示。作为更具体的示例,导航服务可以使地理应用160提供交互式地图,客户端设备104A的用户可以在该交互式地图上通过点击、轻击、语音输入等来指示他或她观察到的可用停车位。作为另一示例,导航服务可以自动确定在客户端设备104A的用户到达了共享目的地之后,该用户根据指示缺乏停车位的模式继续驾驶,并向多车导航组中的其他用户提供适当的指示。作为又一示例,在确定难以在共享目的地找到停车位时,导航服务可以自动将多车导航组中的用户指引到共享目的地附近的不同的小巷、停车场或停车库,使得多车导航组中的用户不会争夺相同地点或造成交通拥堵。

在块210中,导航服务可以解散多车导航组。取决于实施方式和/或场景,当组中的每个用户都到达了目的地时、当组中某一数量的用户到达了目的地时、或响应于来自用户之一的明确请求,导航服务可以解散该组。

此外,导航服务可以在不解散整个组的情况下允许各个用户离开多车导航组。例如,地理应用160可以向参与多车导航会话的用户提供用于表明用户希望离开该组的交互式控件。因此,当用户启动该交互式控件时,导航服务继续协调其余多车导航组的导航。否则,当客户偏离路线而未表明他或她正在离开该组时,导航服务可以将用户引导回该组,如下面参照图4所讨论的。此外,在一些情况下,在多车导航组朝共享目的地有所前进之后,导航服务可以允许新用户加入该组。

现在参照图3,用于识别潜在的多车导航会话的示例方法300也可以在导航服务器102的多车导航控制器140中实现。在另一实施方式中,方法300可以在相应客户端设备中操作的地理应用160的几个实例中以分布式方式实现。在任何情况下,方法300可以被实现为导航服务的一部分。

一般而言,导航服务可以从用户接收他们希望加入多车导航会话的明确指示,或者在一些场景中,可以基于隐含信号确定某些用户有可能对多车导航感兴趣。在前一种情况下,用户可以通过地理应用160向另一用户或一组用户表明他或她意图前往某个目的地,并发送加入多车导航的邀请。在后一种情况下,导航服务首先可以确定其是否可以使用某些特定于用户的信息,该信息可以存储在用户配置文件数据154(见图1)中。

例如,在块302中,导航服务可以确定用户是否已表明他或她希望被视为多车导航会话的潜在候选者、以及用户是否希望导航服务在建议多车导航时考虑某些数据,诸如日历数据和消息收发数据。在一些实施方式中,用户可以通过操作某些控件和/或安装某些应用来表明该愿望。在示例实施方式中,用户可以指定用户潜在地想要与之形成多车导航组的特定的人或一组人(例如,家庭)。如果导航服务确定用户不希望导航服务以这种方式利用他或她的数据或者对多车导航不感兴趣,则方法300结束,否则方法300进行至块304。

在块304中,导航服务在某个时间段内检测表明某些用户可能最终到达共享的远程位置的一个或更多个信号。在一个示例场景中,导航服务确定两个或多个用户(其已表明导航服务在识别多车导航机会时可以使用其日历数据)在其日历上共享远程位置的某个事件。导航服务可以确定如果用户从其当前位置起程,他们将共享路线的某一部分。作为更具体的示例,用户爱丽丝和鲍勃可以住在同一个城镇,并在其各自的日历上安排了在另一个城镇举行的音乐会。爱丽丝和鲍勃对多车导航感兴趣,并且在同一社交图谱中。因此,导航服务确定音乐会是在识别可能的多车导航会话时要考虑的相对强烈的信号。

在另一个示例场景中,导航服务确定两个或更多用户(其已经表明导航服务在识别多车导航机会时可以使用其消息收发数据)已经在其消息中向彼此引用了某个地理位置并开始朝引用的地理位置的方向移动。导航服务可以使用对地理位置的引用作为识别潜在的多车导航会话的信号。

当对多车导航感兴趣的两个或更多个用户在某个时间段(例如,一分钟、五分钟、十分钟)内通过地理应用160请求到同一目的地或邻近目的地的导航指引时,导航服务可以将这些请求视为导航服务应向这些用户建议多车导航会话的另一个典型地强烈的信号。导航服务可以取决于目的地离彼此以及离出发位置有多近以及用户提交对应的请求的时间有多相近来为该信号分配权重。例如,与当爱丽丝和鲍勃请求到邻近但不相同的位置的导航指引时相比,当爱丽丝和鲍勃请求到精确位置的导航指引时,导航服务可以为信号分配更大的权重。此外,与当爱丽丝和鲍勃请求从较近的出发位置到邻近位置的导航指引时相比,当爱丽丝和鲍勃请求从较远的出发位置到相同的邻近位置的导航指引时,导航服务可以为信号分配更大的权重。作为更具体的示例,当爱丽丝和鲍勃请求从加利福尼亚州旧金山到加利福尼亚州山景城中相距半英里的相应位置的导航指引时,与爱丽丝和鲍勃请求从加利福尼亚州桑尼维尔到这两个位置的导航指引时相比,导航服务可以为信号分配更大的权重。作为又一示例,当爱丽丝和鲍勃在彼此相隔五分钟之内请求到同一地址的导航指引时,导航服务可以为信号分配第一权重,但当爱丽丝和鲍勃在彼此相隔十分钟之内请求到同一地址的导航指引时,导航服务可以为信号分配更小的第二权重。

在块306中,导航服务可以基于一个或更多个信号来确定置信度得分。一般,导航服务可以考虑任何适当数量的信号并以任何适当的方式对这些信号进行加权。例如,在块306中,导航服务可以使用表明在彼此的社交图谱中的一对用户在彼此相隔一分钟内请求了到同一位置的导航指引的信号、以及表明路线的共享部分对于一个用户将会占总路线的大约60%而对于另一用户将会占总路线的65%的信号来计算置信度得分。

在块308处,导航服务可以确定置信度得分是否超过某个阈值。如果置信度阈值不超过阈值,则方法300结束而不向用户建议多车导航。否则,流程进行至块310,其中导航服务确定存在多方在彼此相隔某一时间内想要前往共享目的地的意图,并确定他们有可能对多车导航感兴趣。因此,导航服务向各方发送形成多车导航组的建议。在另一实施方式中,导航服务仅向一个用户发送该建议,该用户继而又将邀请发送给其他用户。

参照回图1,在一些情况下,导航服务可以开发并应用ML模型142来检测潜在的多车导航会话。导航服务可以使用来自客户端设备104A-C的传感器的数据、来自诸如图1的传感器108的车辆传感器的数据、以上讨论的信号(例如,日历条目)等作为输入数据并使用用户在某个时间间隔内行驶至相同或几乎相同的位置的实例作为标签数据来训练ML模型142。此外,导航服务可以应用接受或拒绝参与多车导航的邀请的用户决定作为标签数据。

因此,在一个示例场景中,训练数据包括几个用户引用了远程地理位置的指示、这些用户在彼此的社交图谱中的指示、以及用户以彼此非常接近的时间、相似的速度(有可能作为“车队”或“运输队”移动)行驶到该位置的指示。作为更具体的示例,后一种指示可以包括对应客户端设备的轨迹(例如,GPS位置固定/时间戳元组)。这些轨迹可以指示用户遵循的路线、用户行驶的速度以及这些用户沿途所做的停留。使用这种类型的训练数据,ML模型142可以生成针对当朋友或家庭成员引用某个位置并开始在邻近时间朝该位置行驶时这些用户意图成组行驶的预测的置信度得分。

此外,对于相对大的距离,训练数据可以包括用户在相对于用户所覆盖的距离较短的时间窗口内到达了目的地(例如,用户在行驶了50英里之后在彼此相隔10分钟内到达、在行驶了400英里之后在彼此相隔1小时内到达)的指示。以这种方式,ML模型142可以解决共同导航到同一位置的驾驶员松散地形成一组而无需在驾驶时努力待在彼此的视线内的情况。

多车导航控制器140可以使用ML模型142来识别某些用户可能对多车导航感兴趣的情况。例如,多车导航控制器140可以接收在彼此的社交图谱中的几个用户请求从不同但邻近的出发位置到同一目的地的导航指引的指示,并应用ML模型142来获得针对这些用户将会接受形成多车导航组的建议的预测的置信度得分。在向用户建议多车导航选项之后,控制器140可以进一步将邀请的答案应用于ML模型142。因此,当用户倾向于拒绝基于信号的某些组合生成的邀请时,ML模型142可以向下调整对应的得分,或相反地,当用户倾向于接受基于信号的某些组合生成的邀请时,ML模型142可以向上调整对应的得分。

图4示出了示例用户界面屏幕400,当导航服务识别形成多车导航组的机会时,图1的地理应用160可以通过用户界面124提供该示例用户界面屏幕400。在此示例场景中,用户发起从用户设备104A的当前位置(由图钉402指示)到输入框404中指定的目的地的导航。地理应用160可以提供用于请求多车导航选项的专用的交互式控件406。因此,用户可以输入目的地并启动控件406,而非通过启动控件408来请求单车导航模式下的导航指引。作为响应,地理应用160可以显示对话屏幕410。在另一场景中,用户启动单车导航控件408(或用于请求单车导航或多车导航的单个控件),并且地理应用160基于某个用户设置或响应于从导航服务器102接收到的建议自动提供对话屏幕410。

对话屏幕410可以包括:交互式控件412,用于针对特定的导航请求选择多车导航选项;控件414和416,用于指定针对到目的地的共同导航的一组用户;以及交互式控件418,用于指定客户端设备104A的用户是否更偏爱作为领头车辆的驾驶员参与多车导航组。在各种实施方式中,对话屏幕410可以包括附加控件,或相反地,可以不包括图4所示的一些控件。一旦用户完成了通过对话屏幕410的输入,地理应用160就可以将对导航指引的请求与对多车导航选项的选择一起发送给导航服务器102。

图5是示例用户界面屏幕500,图1的地理应用160可以响应于加入多车导航组的邀请通过用户界面124提供该示例用户界面屏幕500。在这种场景中,地理应用160从导航服务器102接收某个用户正在邀请客户端设备104A的用户加入多车导航组的指示,并且作为响应,地理应用160可以显示对话屏幕510。如图5所示,对话屏幕510可以包括用于接受或拒绝邀请的交互式控件512、以及用于提议针对开始共同导航的不同时间的交互式控件514。类似于对话屏幕410,在各种实施方式中,对话屏幕510可以包括附加控件,或相反地,可以不包括图5所示的一些控件。

现在参照图6,多车导航控制器140可以进一步实现用于在多车导航会话期间向客户端设备104A-C提供指导的方法600。然而,在一些实施方式中,方法140的一些步骤在客户端设备中执行。一般,方法600可以被实现为任何合适的设备或设备组中的导航服务的一部分。

尽管按某种顺序示出了块602-614,但是可以按任何合适的顺序来执行这些块,包括与另一些块并行地执行。此外,方法600可以包括块602-614的任何合适的子集,使得块602-614中的一些根本不被执行。另一方面,块602-614中的一些可以被执行多次。

在块602中,导航服务向参与多车导航组的客户端设备提供与参与该多车导航组的其他客户端设备的当前位置有关的更新。参照图7,例如,地理应用160可以在多车导航会话期间通过用户界面124显示数字地图700。地理应用160可以显示客户端设备104A的当前位置的指示符702以及参与多车导航组的另一客户端设备(例如,客户端设备104B)的当前位置的指示符704。地理应用160还可以显示在客户端设备104A的当前位置与由图钉710表示的共享目的地之间的导航路线、以及客户端设备104A的当前位置和共享目的地的概况。在该示例实施方式中,地理应用160提供示出用于客户端设备104A的导航路线的叠加层720和示出用于客户端设备104B的导航路线的叠加层722。如图7所示,导航路线在到达图钉710处的目的地之前合并,因此,地理应用160提供示出路线的共享部分的叠加层724。为了清楚起见,地理应用160可以将不同的样式、颜色、线条笔画类型等应用于叠加层720和722以及应用于指示符702和704。

再次参照图6,在块604中,导航服务可以为参与多车导航组的用户设备自动建立聊天会话,例如建立语音广播频道。在一些实施方式中,导航服务指令对应的客户端设备处的地理应用160的每个实例显示提示,该提示带有激活用于语音聊天的应用或服务的邀请。

在块606中,当多车导航组中操作其各自的客户端设备的用户从不同的位置起程时,导航服务可以确定到共享目的地的导航路线的共享部分。上面讨论的图7对应于这样的场景,其中两条导航路线起始于不同的出发位置、结束于共享目的地、并包括由叠加层724示出的共享部分。在一个实施方式中,导航服务生成用于组中的每个客户端设备的独立于组中的每个其他客户端设备的路线,然后通过逐段比较导航路线来确定重叠。在另一实施方式中,导航服务使用组中其他客户端设备的潜在导航路线作为约束来为参与的客户端设备生成导航路线。更具体地,导航服务可以在针对某个参数(例如,时间)优化整个集合的同时一起生成多条导航路线,而非在针对该参数优化每条单独的路线的同时为客户端设备生成单独的导航路线,。

继续参照图6,在块608中,导航服务可以促进与在多车导航组中操作的其他用户设备共享由在领头车辆中操作的客户端设备获得的道路和交通信息。在一些情况下,导航服务器102可能没有实时交通数据,或对于一些路段,完全没有交通信息。多车导航组的领头车辆可以领先该组的其余车辆相对较短的距离,因此,与领头车辆中的客户端设备所获得的与道路有关的信息可能与该组的其余车辆相关。例如,如果客户端设备104A在领头车辆中操作,则客户端设备104A可以使用客户端设备104A的传感器(例如,定位模块、陀螺仪)和/或车辆的传感器110来确定车辆是否由于交通而减速、道路是否似乎有坑洼等。假如用户表明他愿意共享传感器数据,则客户端设备104A可以将传感器数据发送到导航服务器102,并且导航服务器102继而可以基于传感器数据来确定交通状况和道路质量,并将确定的交通状况和道路质量提供给多车导航组中的其他设备。所述其他设备可以在各种的地图上显示这些更新,或者在一些情况下,可以基于这些更新自动生成语音通知。例如,作为领头车辆操作的客户端设备104A可以自动定期向客户端设备104B提供交通更新,并且客户端设备104B处的地理应用可以自动生成语音通知,诸如“领头车辆报告前方延误两英里。”当然,如以上参照块604所讨论的,客户端设备104A的用户还可以通过聊天向其他用户报告当前交通状况和观察到的道路质量。

在块610中,导航服务可以确定多车导航组中的领头车辆领先该组中的第二名车辆超过阈值距离或时间。在一些实施方式中,阈值距离或时间可以取决于导航路线的共享部分的总距离。响应于确定领头车辆领先太远,导航服务可以自动建议参与者减小车辆之间的间隙。为此,导航服务可以通过在领头车辆中操作的客户端设备提供驾驶员降低速度以允许多车导航组中的其他参与者赶上的建议。更一般地,导航服务可以估计领头车辆的驾驶员为使其他参与者赶上可获得的时间量,并生成与该时间的可能用途有关的一个或更多个建议(例如,绕道游览、在历史古迹停留)。备选地,导航服务可以沿着导航路线的共享部分识别适合等待的位置(例如,加油站、休息区),并向组中的所有车辆提供驾驶员在识别到的位置见面的建议。

在块612中,导航服务可以确定多车导航组中的一参与者已经偏离了导航路线的共享部分。在一些情况下,在块612中,导航服务可以将绕行自动合并到每个参与者的导航路线中,或者至少向参与者提供这样做的建议。例如,如果导航服务确定客户端设备104A在领头车辆中操作并相对于导航路线的共享部分绕行,则导航服务可以向组中的每个其他参与者发送通知,并提供计算合并了客户端设备104A的绕行的新路线的建议。

在块614中,导航服务可以从多车导航组中的参与者之一接收找出该组可出于某个目的(例如,为了加油、吃饭、休息)而停留的合适位置的明确请求,或者导航服务可以确定参与者之一有可能由于隐含信号(诸如汽油水平低)而停留。导航服务可以识别合适的位置,类似于以上参照块610所讨论的场景。当识别到合适的位置时,导航服务可以考虑距离、停车位的可获得性、操作各客户端设备的用户的偏好等。

为了进一步清楚起见,图8和图9示出了可在地理应用160中实现的用于加入多车导航组的方法。这些方法一般可以在任何合适的设备中实现。

首先参照图8,方法800起始于块802,其中地理应用160从导航服务器102接收加入多车导航组的邀请。邀请可以指定例如目的地、多车导航组中的实际和预期参与者、提议的起程时间以及到共享目的地的导航路线预计合并的位置。在一些情况下,邀请可以包括引用多车导航组的参与者可见面的位置。

在块804中,地理应用160可以显示加入多车导航组的邀请。例如,图5中示出了地理应用可生成的示例屏幕。如果用户在块806中拒绝邀请,则方法800完成。否则,如果用户接受邀请,则流程进行至块808,其中地理应用160向导航服务器102发送用户已接受邀请的通知。在一些情况下,该通知可以包括新的提议的起程时间(见图5)或对邀请中包含的细节的另一提议的修改。

在块810中,地理应用160可以提供与对应客户端设备朝着共享目的地的进度有关的更新,在一些情况下并且根据用户选择,可以提供导航服务器102可用来评估交通和道路质量的传感器数据。在块812中,地理应用160可以从导航服务器102接收与在多车导航组中操作的其他客户端设备的进度有关的更新。在一些情况下,地理应用160还可以接收导航服务器102使用来自该组中的另一客户端设备的传感器数据所生成的交通和道路质量更新。地理应用160可以在多车导航会话期间以任意顺序和任意次数执行块810和812,直到导航服务器102或客户端设备的用户解散多组导航组为止。

根据图9的方法900,在块902中,地理应用160通过用户界面122从用户接收对导航指引的请求(而非如根据图8的方法那样从导航服务器102接收邀请)。在块904中,地理应用160可以确定用户是明确地还是隐含地选择了多车导航选项(见图4)。如果用户尚未选择多车导航选项,则流程进行至块908,其中地理应用160向导航服务器102发送对单车导航指引的请求,因此在块908中接收这些导航指引。

否则,如果用户在块904中明确地或隐含地选择了多车导航选项,则流程进行至块910。在块910中,地理应用向导航服务器102发送对导航指引的请求,并指定多车导航选项。在一些实施方式中,在块910中发送的请求包括以下指示:应邀请哪个用户或哪组用户,该用户何时提议开始多车导航,以及其他合适的选项(例如,避免通行费,针对速度进行优化)。

在块912中,地理应用160接收所请求的导航指引。地理应用160还可以接收是否形成了多车导航组的指示,如果是,则接收该组中的参与者的列表。如上所讨论的,地理应用160然后可以接收与多车导航会话相关的更新。

尽管以上讨论涉及车辆,但是这些技术中的至少一些可以应用于骑车指引,在一些情况下,可以应用于公共交通指引。更具体地,在一些情况下,用户可以使用公共交通选项来请求到某一目的地的指引,并且导航服务器102可以确定用户何时可以离开以在某个中间位置见面,用户可以一起搭乘例如什么火车或公共汽车去经历导航路线的共享部分,等。

另外的考虑

以下另外的考虑适用于前述讨论。贯穿本说明书,多个实例可以实现被描述为单个实例的组件、操作或结构。尽管一种或更多种方法的各个操作被示出和描述为分离的操作,但是可以同时执行各操作中的一个或更多个,并且不需要按所示顺序执行这些操作。在示例配置中呈现为分离的组件的结构和功能可以被实现为组合结构或组件。类似地,呈现为单个组件的结构和功能可以被实现为分离的组件。这些和其他变型、修改、添加和改善落入本公开的主题的范围内。

另外,某些实施例在这里被描述为包括逻辑或多个组件和模块。模块可以构成软件模块(例如,存储在机器可读介质上的代码)或硬件模块。硬件模块是能够执行某些操作的有形单元,并且可以以某种方式配置或安排。在示例实施例中,一个或更多个计算机系统(例如,独立的客户端或服务器计算机系统)或计算机系统的一个或更多个硬件模块(例如,处理器或一组处理器)可以由软件(例如,应用或应用部分)配置为进行操作以执行如这里所述的某些操作的硬件模块。

在各种实施例中,硬件模块可以包括永久性配置(例如,配置为专用处理器,诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC))以执行某些操作的专用电路或逻辑。硬件模块还可以包括由软件临时配置以执行某些操作的可编程逻辑或电路(例如,如通用处理器或其他可编程处理器中所包含的)。将理解,在专门且永久性配置的电路中或在临时配置的电路(例如,由软件配置)中实现硬件模块的决定可以由成本和时间考虑驱动。

因此,术语硬件应被理解为涵盖有形实体,即在物理上构造、永久性配置(例如,硬接线)或临时配置(例如,编程)以按某种方式操作或执行这里描述的某些操作的实体。如这里所使用的,“硬件实现的模块”是指硬件模块。考虑到硬件模块被临时配置(例如,编程)的实施例,每个硬件模块不需要在任何时刻被配置或实例化。例如,在硬件模块包括使用软件来配置的通用处理器的情况下,该通用处理器可以在不同时间被配置为相应的不同硬件模块。软件可以在处理器上相应地配置,例如,以在一个时刻构成特定的硬件模块,并且在一不同的时刻构成一不同的硬件模块。

硬件模块可以向其他硬件提供信息并从其他硬件接收信息。因此,所描述的硬件模块可以被认为是在通信上耦合的。在同时存在多个这样的硬件模块的情况下,可以通过连接硬件模块的信号传输(例如,通过适当的电路和总线)来实现通信。在多个硬件模块在不同时间被配置或实例化的实施例中,可以例如通过在多个硬件模块可访问的存储器结构中的信息的存储和检索来实现此类硬件模块之间的通信。例如,一个硬件模块可以执行一操作并将该操作的输出存储在其通信耦合到的存储器设备中。然后,另一硬件模块可以稍后访问该存储器设备以检索和处理所存储的输出。硬件模块还可以发起与输入或输出设备的通信,并且可以对资源(例如,信息的集合)进行操作。

以上讨论的方法可以包括呈有形计算机可运行指令形式的一个或更多个功能块、模块、各个功能或例程,所述一个或更多个功能块、模块、各个功能或例程被存储在非暂时性计算机可读存储介质中并使用计算设备(例如,如本文所述的服务器、个人计算机、智能电话、平板计算机、智能手表、移动计算设备或其他个人计算设备)的处理器来运行。以上讨论的方法可以作为任何后端服务器(例如,如这里所述的地图数据服务器、导航服务器或任何其他类型的服务器计算设备)的部分、例如示例环境的便携式设备模块、或作为此类环境外部的模块的部分被包括。尽管为了便于解释可以参照其他附图来描述这些附图,但是以上讨论的方法可以与其他对象和用户界面一起使用。此外,尽管以上解释描述了上面讨论的方法的步骤由特定设备执行,但这仅是出于说明目的。

这里描述的示例方法的各种操作可以至少部分地由临时配置(例如,由软件配置)或永久性配置以执行相关操作的一个或更多个处理器执行。无论是临时配置还是永久配置,这样的处理器都可以构成处理器实现的模块,所述处理器实现的模块可以进行操作以执行一个或更多个操作或功能。在一些示例实施例中,这里提到的模块可以包括处理器实现的模块。

类似地,这里描述的方法或例程可以至少部分地是处理器实现的。例如,方法的至少一些操作可以由一个或更多个处理器或处理器实现的硬件模块执行。某些操作的性能可以分布在所述一个或更多个处理器之间,不仅驻留在单个计算机内,而且部署在多个计算机中。在一些示例实施例中,一个或多个处理器可以位于单个位置(例如,在家庭环境、办公室环境内或作为服务器场),而在其他实施例中,处理器可以分布在多个位置。

所述一个或更多个处理器还可以在“云计算”环境中或作为SaaS进行操作以支持相关操作的性能。例如,如上所指出的,至少一些操作可以由一组计算机(作为包括处理器的机器的示例)执行,这些操作通过网络(例如,互联网)以及通过一个或更多个适当的接口(例如,API)是可访问的。

此外,这些附图仅出于说明的目的描绘了示例环境的一些实施例。本领域技术人员将从以下讨论中容易地认识到,在不背离这里描述的原理的情况下,可以采用这里说明的结构和方法的备选实施例。

在阅读了本公开之后,本领域技术人员将理解用于通过这里公开的原理来协调多车导航的另外的备选结构和功能设计。因此,虽然已经示出和描述了特定的实施例和应用,但是将理解,所公开的实施例不限于这里公开的精确构造和组件。在不背离所附权利要求中限定的精神和范围的情况下,可以在这里公开的方法和装置的布置、操作和细节中进行对于本领域技术人员将明易的各种修改、改变和变化。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号