多模式出行系统的会话式用户体验

相关申请的交叉引用/通过引用并入

本申请要求于2021年11月1日向美国专利局提交的美国专利申请No.17/515839的优先权。上面引用的每个申请通过引用整体并入本文。

技术领域

本公开的各个实施例涉及出行技术和旅行计划服务。更具体而言，本公开的各种实施例涉及为多模式出行系统提供会话式用户体验的系统和方法。

背景技术

出行技术的进步已经为用户提供了计划、预订和支付旅行的各种服务。例如，移动即服务(MaaS)使各种交通服务提供商能够通过公共平台(诸如公共移动应用)向用户提供出行相关的服务。通常，计划旅行可能要求预订多种交通服务，诸如航班、出租车、火车等。旅行计划可能还要求预订宾馆和活动，诸如观光、尝试当地美食或参加活动。常规而言，计划旅行的团体需要彼此沟通以计划共享活动并就旅行计划达成一致。这种团体的成员通常可以使用多个平台或服务彼此通信、策划出行计划、做出出行决定、计划出行计划中的活动以及决定其它细节。例如，用户可以使用消息传递应用来创建旅行团并讨论出行计划。此类用户还可以使用出行网站和出租车预订应用来分别预订航班和宾馆以及出租车。使用不同的平台来讨论、策划、计划或预订旅行可能是一项耗时的活动，并且会导致用户之间的协作减弱。此外，用户跨不同平台管理和跟踪针对出行计划的不同部分的支付可能是麻烦的。

通过将上述系统与本公开的一些方面进行比较，如本申请的其余部分并参考附图所阐述的，常规和传统方法的限制和缺点对于本领域技术人员来说将变得清晰。

发明内容

基本上如至少一个附图所示和/或结合至少一个附图所描述的，提供了用于多模式出行系统的会话式用户体验的系统和方法，如权利要求书中更完整地阐述的。

可以通过阅读以下对本公开的详细描述以及附图来理解本公开的这些和其它特征以及优点，在附图中，相同的参考标记始终表示相同的部分。

附图说明

图1是根据本公开的实施例的用于多模式出行系统的会话式用户体验的示例性网络环境的图。

图2是描绘根据本公开的实施例的多模式出行系统的会话式用户体验的示例性序列图。

图3A和图3B是共同图示根据本公开的实施例的预订细节的生成以及在用户界面上呈现预订细节的图。

图4A是描绘根据本公开的实施例的与联网应用的主屏幕对应的示例性用户界面的图。

图4B是描绘根据本公开的实施例的与联网应用的聊天屏幕对应的示例性用户界面的图。

图4C是描绘根据本公开的实施例的联网应用的示例性聊天用户界面的图。

图4D是描绘根据本公开的实施例的显示预订细节的示例性用户界面的图。

图4E是描绘根据本公开的实施例的与实时地图(live map)用户界面对应的示例性用户界面的图。

图4F是描绘根据本公开的实施例的生成的增强现实(AR)元素的图。

图4G是描绘根据本公开的实施例的覆盖在实时地图用户界面上的多个可点击UI元素的图。

图4H是描绘根据本公开的实施例的示例性基于自定义地图的用户界面的图。

图4I是描绘根据本公开的实施例的一个或多个任务小部件的图。

图4J是描绘根据本公开的实施例的示例性视觉计划器用户界面的图。

图5是根据本公开的实施例的图1的网络环境的示例性软件级体系架构的图。

图6是图示根据本公开的实施例的多模式出行系统的启用增强现实(AR)的会话式用户体验的示例性体系架构的图。

图7图示了根据本公开的实施例的基于兴趣点的集合生成出行计划的示例性方法的流程图。

图8A-8C是共同图示根据本公开的实施例的示例性UI元素的图。

图9是根据本公开的实施例的用于多模式出行系统的会话式用户体验的系统的示例性框图。

图10图示了根据本公开的实施例的用于多模式出行系统的会话式用户体验的方法的示例性流程图。

具体实施方式

以下描述的实施方式可以在所公开的系统和方法中找到，以便为多模式出行系统提供会话式用户体验。本公开的示例性方面可以提供一种可以通信地耦合到与一组运输(transportation)提供商相关联的移动即服务(MaaS)网络的系统。运输提供商可以包括例如公共交通服务提供商、出租车聚合商、私人运输服务提供商(诸如公交车交通提供商)、汽车租赁、共享运输服务提供商等。MaaS网络可以包括发布-订阅模型和分布式分类账数据库。发布-订阅模型可以包括多个发布者节点、代理节点和多个订阅者节点。分布式分类账数据库可以包括多个MaaS数据库。

在任何时刻，系统都可以控制与第一用户相关联的电子设备以呈现第一用户界面(UI)。电子设备可以是例如第一用户的智能电话，并且第一UI可以在电子设备(诸如智能电话)的显示屏上呈现。在实施例中，第一UI可以是聊天UI(例如，消息传递应用的UI)。通过第一UI，系统可以获取可以包括来自第一用户的自然语言输入的一个或多个消息。例如，自然语言输入可以与第一用户与一个或多个消息的一个或多个接收者之间的基于语音的会话、基于视频的会话或基于文本的会话对应。在示例性场景中，第一UI可以被第一用户用来与消息传递应用上的其他用户通信。

系统可以使用一个或多个自然语言处理(NLP)模型来处理所获取的一个或多个消息以确定背景信息。背景信息可以指示第一用户前往第一地点的意图以及与该出行相关联的时间表。例如，背景信息可以包括第一地点的名称和访问第一地点的优选日期。另外，系统可以获取与第一用户相关联的用户数据。所获取的用户数据的示例可以包括但不限于个人信息(诸如第一用户的姓名、第一用户的地点)、第一用户的出行历史和第一用户在消息传递应用上的内容消费信息。在一些实施例中，系统可以将一个或多个消息和所确定的背景信息存储在分散式存储系统的存储节点上，该存储节点可以特定于一组运输服务提供商中的运输服务提供商(诸如交通提供商)。

基于所确定的背景信息和用户数据，系统可以生成旅行计划。系统可以触发MaaS网络以生成用于出行计划中指定的旅行的预订细节。例如，预订细节可以包括前往第一地点的旅行的日期、预订的航班信息、预订的宾馆信息等等。MaaS网络的触发可以与MaaS网络的分布式分类账节点(诸如分布式分类账数据库的节点)上的事务的执行对应。系统可以控制与第一用户相关联的电子设备118将生成的预订细节显示到第一UI或与第一UI不同的第二UI上。

根据实施例，系统可以基于背景信息和用户数据来选择消息传递组。消息传递组可以包括与第一用户具有相同的出行兴趣的一组成员。加入消息传递组的推荐可以显示在与第一用户相关联的电子设备上。基于对第一用户与消息传递组的一个或多个成员之间的会话的分析，系统可以生成出行计划。

根据实施例，系统可以从一个或多个运输服务提供商服务器(或运输提供商服务器)接收跟踪信息。跟踪信息可以与旅行之前和旅行期间可能发生的事件相关联。基于跟踪信息，系统可以检测事件。例如，事件可以与出行计划中指定的旅行的每段的开始、旅行的每段的结束、路线或运输提供商的改变等对应。基于被跟踪的事件，系统可以通过在MaaS网络的分布式分类账节点上执行一个或多个事务来跟踪旅行的进度。

在一些实施例中，系统可以接收用户输入，该用户输入可以与改变或取消旅行的至少一段的路线、时间表或运输提供商的请求对应。系统可以触发MaaS网络以基于用户输入更新预订细节。更新后的预订细节还可以被呈现为电子设备上的通知。

在一些实施例中，系统可以从一个或多个成员(包括消息传递组的第一用户)接收输入的集合。例如，输入的集合可以与查看或突出显示旅行的活动段所采用的路线的偏好、由一个或多个成员进行的旅行的行程、与旅行过程中的第一地点和其它地点相关联的特定于地点的信息或者要由一个或多个成员执行的一个或多个任务相关联。系统还可生成旅行或旅行的活动段的实时地图UI。基于输入的集合，系统可以生成多个可点击UI元素。系统可以呈现所生成的实时地图UI的第一视图并将多个可点击UI元素覆盖在所呈现的实时地图UI的第一视图上的对应位置处。以这种方式，第一用户和一个或多个成员可以点击多个可点击UI元素以执行与输入的集合相关联的特定任务。

根据实施例，系统可以接收与同第一用户相关联的一个或多个被预先安排的任务对应的输入。例如，一个或多个被预先安排的任务可以包括站点的访问、第一用户对站点的检查等。系统可以生成与一个或多个被预先安排的任务对应的一个或多个任务小部件。所生成的一个或多个任务小部件可以与旅行或旅行的活动段的实时地图UI一起被呈现。

根据实施例，系统可以在旅行过程中控制电子设备将内容消费UI呈现到旅行的实时地图UI上。例如，内容消费UI可以包括可以显示媒体内容的媒体播放器UI、指示在旅行过程中包括第一用户在内的一个或多个成员可能已经消费或尚未消费的媒体内容的量的时间线，以及示出一个或多个成员的查看器UI元素。在一些实施例中，系统可以通过在MaaS网络的分布式分类账节点上执行一个或多个事务来跟踪一个或多个成员对媒体内容的消费。

在一些实施例中，系统可以控制电子设备以呈现视觉计划器UI。呈现视觉计划器UI可以包括例如可以以图形方式表示将在旅行过程中被覆盖的一个或多个行程项目的第一组UI元素，以及可以与配置一个或多个行程项目中的每一个的选项对应的第二组UI元素。系统可以接收对第二组UI元素中的一个或多个UI元素的选择。基于该选择，出行计划可以被更新。系统可以触发MaaS网络以进一步基于更新后的出行计划生成预订细节。

常规而言，用户可能要求多个平台或服务来计划旅行，诸如用于预订乘车、用于预订宾馆以及探索旅行过程中的活动。本公开的系统可以使得用户能够完全在单个平台上利用各种服务。例如，旅行的计划，从搜索旅行地点开始、到预订乘车、预订宾馆和运输安排(诸如出租车)，都可以通过使用该系统来完成。因此，系统可以向用户提供无忧的旅行计划体验。在常规系统中，诸如第一用户的个人数据之类的用户数据可以与诸如航空公司之类的各种第三方共享。但是，本公开的系统可以使得能够在分散式存储系统处安全地本地存储一个或多个消息和背景信息。在常规系统中，管理和跟踪各种服务的支付对于用户来说可能是一项艰巨的任务，并且支付服务可能不存在基于语音的命令。本公开的系统可以启用在单个平台上对旅行的所有支付进行用户友好的管理和跟踪。该系统还可以启用基于语音的命令来认证第一用户并促进平台上的支付。此外，系统可以提供不同的UI，诸如可以向用户提供整体体验的聊天UI。

图1是根据本公开的实施例的用于为多模式出行系统提供会话式用户体验的示例性网络环境的图。参考图1，示出了网络环境100的示意图。网络环境100可以包括系统102。系统102可以包括一个或多个NLP模型104。网络环境100还可以包括MaaS网络106。MaaS网络106可以包括发布订阅模型108和分布式分类账数据库110。网络环境100还可以包括一个或多个移动提供商(MP)服务器112，诸如第一MP服务器112A、第二MP服务器112B和第N MP服务器112N。网络环境100还可以包括一组车辆，诸如第一车辆114A、第二车辆114B和第N车辆114N。网络环境100还可以包括分散式存储系统116，分散式存储系统116可以包括第一存储节点116A、第二存储节点116B和第N存储节点116N。另外，网络环境100可以包括与第一用户120相关联的电子设备118、与电子设备118相关联的第一用户界面(UI)122和第二UI 124。网络环境100还可以包括通信网络126。系统102、MaaS网络106、一个或多个MP服务器112、分散式存储系统116、电子设备118和车辆组可以经由通信网络126进行通信。

系统102可以包括合适的逻辑、电路系统、代码和/或接口，这些逻辑、电路系统、代码和/或接口可以被配置为提供让用户聊出行计划和通过各种选项(诸如基于地图的界面)跟踪出行计划中包括的旅行的界面(诸如第一UI 122和第二UI 124)。基于出行计划，系统102可以触发MaaS网络106生成预订细节。系统102可以控制电子设备118将生成的预订细节显示到第一UI 122或第二UI 124上。系统102的示例实施方式可以包括但不限于主机机器上的虚拟机(VM)、主机机器或服务器上的操作系统(OS)的容器或虚拟运行时环境、服务器上容器化的应用、裸机服务器、云服务器(诸如私有云、公共云或混合云)、工作站、媒体服务器，或者具有生成媒体内容并将其流式传输到设备集群的能力的任何设备。在实施例中，系统102可以被实现为一个或多个MP服务器112的服务器或服务器节点上的VM或容器。

一个或多个NLP模型104可以是机器学习或统计模型，其可以被配置为分析来自第一用户120的一个或多个消息以确定背景信息。此类消息可以包括自然语言输入，该自然语言输入可以与第一用户120与一个或多个消息的一个或多个接收者之间的基于语音的会话、基于视频的会话或基于文本的会话中的至少一个对应。一个或多个NLP模型104可以是基于人工智能(AI)的模型。一个或多个NLP模型104可以启用第一用户120与一个或多个接收者之间的省时且用户友好的通信。一个或多个NLP模型104还可以提供第一用户120与一个或多个接收者之间的共享想法。可以由一个或多个NLP模型104用来分析一个或多个消息的NLP技术的示例可以包括但不限于背景提取、自动总结、情感分析、词类分析标记、语义关系提取、词干提取、文本挖掘和机器翻译。例如，在图5中进一步描述一个或多个NLP模型104的示例性体系架构的细节。

MaaS网络106可以支持用于通信的标准规范并且可以包括发布-订阅模型108。发布-订阅模型108可以包括发布者节点(例如，票读取器或乘车预订应用)、订阅者节点，以及至少一个代理节点设备以根据发布-订阅网络协议(诸如消息队列遥测传输)将事务消息从发布者节点传送到订阅者节点。在至少一个实施例中，MaaS网络106可以包括分布式分类账数据库110，分布式分类账数据库110可以包括分类账节点以记录与各种移动服务相关联的事务，诸如MaaS运输服务的票务事务、对各种服务的支付以及被跟踪的旅行进度。

与MaaS网络106相关联的所有运输服务提供商的发布者节点可以遵循用于数据交换的标准或常见通信协议。MaaS网络106可以包括可以遵循用于通信的MaaS标准规范的同质发布者节点。在实施例中，MaaS网络106可以包括可以遵循专有通信协议的异构发布者节点。MaaS网络106可以向发布者节点提供基于插件的支持，使得可以支持这样的异构发布者节点，直到相应的运输服务提供商遵守用于通信的MaaS标准规范并提供对其的支持。

MaaS网络106可以使得与不同运输提供商相关联的发布者节点能够加入MaaS网络106。通过节点管理设备，MaaS网络106可以提供发布者节点的批量集群管理。所有发布者节点可以遵循设定的协议以在MaaS网络106上运转。设定的协议可以要求常见的安全体系架构(用于发布者节点认证和授权)、网络协议(例如，HTTP、MQTT、AMQP等)、统一的数据请求或响应格式(例如，JSON、CSV、或XML格式)，以及API/数据方案。这可以确保每个发布者节点遵循集群级配置(诸如包括公司名称、公司ID、门ID、门编号等的设备简档)和设备级证书(即，认证凭据)。集群级配置的模式和设定的协议可以促进交通提供商部署新的发布者节点或用即插即用方法替换现有的发布者节点。这可以促进MaaS网络106用作具有各种运输提供商的资源(诸如发布者节点设备)之间的互操作性的同质运输网络。

一个或多个MP服务器112可以包括合适的逻辑、电路系统、代码和/或接口，这些逻辑、电路系统、代码和/或接口可以被配置为共同管理由个体用户或一组用户计划的针对旅行的交通/移动服务。例如，第一MP服务器112A可以被配置为管理针对第一运输服务提供商的交通/移动服务。第二MP服务器112B可以被配置为管理针对第二运输服务提供商的交通/移动服务。类似地，第N MP服务器112N可以被配置为管理针对第N运输服务提供商的交通/移动服务。一个或多个MP服务器112中的每一个可以被实现为云服务器并且可以通过web应用、云应用、HTTP请求、储存库操作、文件传输等来执行操作。一个或多个MP中的每一个的其它示例实现服务器112可以包括但不限于数据库服务器、文件服务器、网络服务器、媒体服务器、应用服务器、大型机服务器或云计算服务器。在至少一个实施例中，一个或多个MP服务器112中的每一个可以通过使用本领域普通技术人员众所周知的多种技术被实现为多个分布式的基于云的资源。

诸如第一车辆114A、第二车辆114B和第N车辆114N之类的车辆组可以由与MaaS网络106相关联的运输服务提供商拥有、租赁或管理。每个这样的车辆可以作为公共运输服务或私人运输服务的一部分提供。当第一用户120通过MaaS网络106预订旅行时，旅行可以被分成多段，这些段可以通过一种或多种交通模式被覆盖，诸如第一车辆114A、第二车辆114B和第N车辆114N。此类交通模式的示例可以包括但不限于铁路、公共汽车、汽车、飞机、出租车(taxi)或的士(cab)、无轨电车、有轨电车、渡轮、快速公交系统、卡车或自行车。

在图1中，将诸如第一车辆114A、第二车辆114B和第N车辆114N之类的车辆组描绘为汽车、出租车和卡车仅作为示例提供，并且不应当被理解为限制本公开。本公开可以适用于与其它可用的公共或私人交通模式相关联的车辆。

分散式存储系统116可以包括合适的逻辑、电路系统、代码和/或接口，这些逻辑、电路系统、代码和/或接口可以被配置为存储与相应运输服务提供商相关联的事务数据。例如，第一存储节点116A可以存储与第一运输服务提供商相关联的事务数据。事务数据可以包括用户(诸如第一用户120)的过去旅行的记录以及具有出行背景的最近和过去的消息或聊天记录。每个旅行可以与可以由第一运输提供商(例如，与第一MP服务器112A相关联)在旅行的至少一段中提供的MaaS运输服务对应。分散式存储系统116的每个存储节点可以被称为分散式存储系统116的可以存储MaaS网络106的各个运输服务提供商的事务数据的节点。分散存储系统116可以使得不同消息传递客户端的用户能够与系统102连接。分散式存储系统116可以启用与每个用户相关联的数据的安全存储，并且可以允许用户之间的消息的端到端加密。

电子设备118可以是用户设备，其可以包括合适的逻辑、电路系统和接口，这些逻辑、电路系统和接口可以被配置为显示UI，诸如第一UI 122或第二UI 124，这些UI可以使得用户能够聊天、创建旅行团，决定出行计划，接受出行计划建议，触发已接受出行计划的预订，并跟踪出行计划中包括的旅行。电子设备118可以被控制以将与一个或多个出行计划相关联的预订细节显示到第一UI 122或第二UI 124上。在一些实施例中，电子设备118可以包括web应用或移动应用。在这种情况下，第一UI 122或第二UI 124可以被呈现为web应用或移动应用的一部分。电子设备118的示例可以包括但不限于计算设备、智能电话、移动电话、公共显示器(诸如公共信息亭)、扩展现实(XR)设备、游戏设备、大型机、服务器、计算机工作站和/或消费电子(CE)设备。

第一UI 122和第二UI 124可以呈现在显示屏上，诸如电子设备118的显示屏上。在实施例中，第一UI 122可以是聊天UI并且第二UI 124可以包括地图UI元素。

通信网络126可以包括通信介质，系统102、MaaS网络106、一个或多个MP服务器112、车辆组、分散式存储系统116和电子设备118可以通过该通信介质彼此通信。通信网络126可以是有线连接或无线连接之一。通信网络126的示例可以包括但不限于互联网、云网络、蜂窝或无线移动网络(诸如长期演进和5G新无线电)、无线保真(Wi-Fi)网络、个域网(PAN)、局域网(LAN)或城域网(MAN)。网络环境100中的各种设备可以被配置为根据各种有线和无线通信协议连接到通信网络126。此类有线和无线通信协议的示例可以包括但不限于传输控制协议和网际协议(TCP/IP)、用户数据报协议(UDP)、超文本传输协议(HTTP)、文件传输协议(FTP)、Zig Bee、EDGE、IEEE 802.11、光保真(Li-Fi)、802.16、IEEE 802.11s、IEEE 802.11g、多跳通信、无线接入点(AP)、设备到设备通信、蜂窝通信协议和蓝牙(BT)通信协议中的至少一种。

在操作中，可以在电子设备118上访问联网应用。联网应用可以是例如社交联网应用、微博应用、聊天应用、消息传递应用、网络电话语音(VoIP)应用等。系统102可以控制与第一用户120相关联的电子设备118(诸如智能电话)以呈现第一UI 122。第一UI 122可以与联网应用相关联，并且第一用户120可以是联网应用的注册用户。在一些实施例中，第一UI122可以被呈现为聊天UI。例如，在图2中进一步描述与第一UI 122的呈现相关联的细节。

在任何时刻，第一用户120都可以向一个或多个用户发送消息，这些用户可以是家人和朋友组的一部分或者可以是社交组的成员。系统102可以获取可以包括来自第一用户120的自然语言输入的一个或多个消息。此类消息可以通过第一UI 122来获取。在一个或多个实施例中，自然语言输入可以与第一用户120与一个或多个消息的一个或多个接收者之间的基于语音的会话、基于视频的会话或基于文本的会话中的一个对应。例如，第一用户120可以利用第一UI 122与一个或多个用户(其可以是一个或多个消息的接收者)就旅行的地点聊天。例如，在图2中进一步描述获取一个或多个消息的细节。

系统102可以获取与第一用户120相关联的用户数据。根据实施例，用户数据可以包括个人信息(诸如第一用户120的名字、第一用户120的当前地点、第一UI 122的通信地址、第一用户120的电子邮件(e-mail))。用户数据还可以包括用户偏好的集合(诸如优选的出行地点)、出行历史(例如，之前访问过的地点)和内容消费信息(诸如联网应用的使用历史)。用户数据还可以包括在旅行和社交数据中覆盖的地点的背景中用户生成的内容，包括但不限于聊天历史、与一个或多个消息传递组的成员的过去交互的集合、记录在聊天记录中的每次会话的社交背景，以及第一用户120的社交网络中的一组人。例如，在图2中进一步描述获取用户数据的细节。

系统102可以使用一个或多个NLP模型104来处理所获取的一个或多个消息以确定背景信息。在一些实施例中，一个或多个NLP模型104可以是AI或机器学习模型、统计马尔可夫模型(诸如隐马尔可夫模型)或用于NLP的启发式模型。背景信息可以指示第一用户120前往第一地点的意图以及与该出行相关联的时间表。例如，背景信息可以包括第一用户120优选的第一地点的名称以及访问第一地点的优选日期/时间。例如，在图2中进一步描述背景信息的确定的细节。

基于所确定的背景信息和用户数据，系统102可以生成出行计划。在一些实施例中，出行计划可以包括第一用户120和正进行到第一地点的旅行的一个或多个成员中的每个人的旅行的行程。例如，出行计划可以包括关于在第一地点参观的不同地方(例如，著名古迹)的信息以及关于优选活动(例如，蹦极和滑翔伞)的信息。例如，在图2中进一步描述出行计划的生成的细节。

系统102可以触发MaaS网络106生成出行计划中指定的旅行的预订细节。例如，预订细节可以包括前往第一地点的旅行的日期、旅行的每一段的时间表、每一段中要使用的交通服务，以及登上可用于旅行的每一段的预约或预期的车辆的地点和时间。如果旅行要求航班前往第一地点，那么预订细节可以包括预订的航班和预订逗留的宾馆的细节(诸如航班名称、登机地点以及航班出发和到达时间)。MaaS网络106的触发可以与MaaS网络106的分布式分类账节点(诸如分布式分类账数据库110的节点)上的事务的执行对应。可以执行事务以在分布式分类账节点上记录每个用户的旅行细节(作为出行计划的一部分)。基于该执行，MaaS网络106可以被配置为至少跟踪旅行的每一段的开始和结束、旅行持续时间内每个用户在所有时间的地点，以及其它服务的交付(诸如票务、支付或媒体消费)。例如，在图2中进一步描述预订细节的生成的细节。

系统102可以控制与第一用户120相关联的电子设备118以将生成的预订细节显示到第一UI 122或第二UI 124上。第二UI 124可以与第一UI不同122。例如，第一UI 122可以是聊天UI并且第二UI 124可以包括地图UI元素。例如，在图2中进一步描述生成的预订细节的显示的细节。

根据实施例，系统102可以基于背景信息和用户数据来选择消息传递组。作为示例，可以基于用户数据中的第一用户120的用户偏好和行为数据来选择消息传递组。消息传递组还可以基于社交背景(例如，第一用户120的组织(诸如办公室)、第一用户120的居住地点、第一用户120的家庭组以及第一用户的朋友圈120)来选择。而且，可以基于可能已经在联网应用上与第一用户120交互或者可能位于第一用户120的朋友列表中的用户的用户简档来选择消息传递组。消息传递组可以包括与第一用户120具有相同出行兴趣的一组成员。例如，消息传递组可以包括其优选出行地点可能在欧洲的一组成员。在实施例中，消息传递组可以与家庭旅行、与朋友/同事的旅行、工作相关的旅行、住房协会旅行等相关联。加入消息传递组的推荐可以显示在与第一用户120相关联的电子设备118上。基于对第一用户120与消息传递组的一个或多个成员之间的会话的分析，系统102可以生成出行计划。例如，在图3A中进一步描述消息传递组的选择的细节。

根据实施例，系统102可以将交互式UI元素的集合覆盖到第一UI 122或第二UI124上。例如，该交互式UI元素的集合可以与与第一地点的旅行相关联的共享时间表、确定是否计划旅行过程中的活动的意见调查或者与一个或多个地点相关联的共同感兴趣项目对应。在一些实施例中，第二UI 124可以包括地图UI元素，交互式UI元素的集合可以覆盖在该地图UI元素上。例如，在图3A中进一步描述该交互式UI元素的集合的覆盖的细节。

根据实施例，系统102可以从一个或多个MP服务器112接收跟踪信息。跟踪信息可以与旅行之前和旅行过程中可能发生的事件相关联。基于跟踪信息，系统102可以检测事件。例如，事件可以与出行计划中指定的旅行的每一段的开始、旅行的每一段的结束、路线或运输服务提供商的改变等对应。基于被跟踪的事件，系统102可以通过在MaaS网络106的分布式分类账节点上执行一个或多个事务来跟踪旅行的进度。例如，在图3B中进一步描述跟踪信息的接收和事件的检测的细节。

在一些实施例中，系统102可以接收用户输入，该用户输入可以与针对旅行的至少一段改变或取消路线的请求、改变或取消时间表的请求或者改变或取消运输提供商的请求对应。例如，第一用户120可能需要跳过对出行计划中包括的特定城市的访问。系统102可以接收可以与取消对出行计划中包括的特定城市的访问的请求对应的用户输入。系统102可以触发MaaS网络106以基于用户输入更新预订细节。更新后的预订细节还可以被呈现为电子设备118上的通知。例如，在图3B中进一步描述预订细节的更新的细节。

在一个或多个实施例中，系统102可以生成交互式增强现实(AR)元素的集合。例如，该交互式AR元素的集合可以基于旅行的被访问地点、当前地点或在旅行过程中要访问的未来地点、旅行过程中第一用户120与一个或多个成员之间的会话、一个或多个广告等。例如，所生成的AR元素的集合可以包括与第一用户120访问的古迹对应的AR元素。所生成的AR元素的集合可以被呈现到第一UI 122或第二UI 124上。例如，在图4F中进一步描述该交互式AR元素的集合的生成的细节。

在一些实施例中，系统102可以从一个或多个成员(包括消息传递组的第一用户120)接收输入的集合。例如，输入的集合可以与查看或突出显示旅行的活动段所采取的路线的偏好、一个或多个成员可以采取的旅行的行程、与第一地点和在旅行过程中被覆盖或将被覆盖的其它地点相关联的特定于地点的信息，以及由一个或多个成员执行的一个或多个任务相关联。系统102可以生成旅行或旅行的活动段的实时地图UI。

基于该输入的集合，系统102可以生成多个可点击UI元素。例如，系统102可以接收与突出显示路线的请求对应的输入的集合中的输入。系统102可以呈现所生成的实时地图UI的第一视图，并且可以将多个可点击UI元素覆盖在所呈现的实时地图UI的第一视图上的对应位置处。可以在突出显示的路线上生成多个可点击UI元素，第一用户120可以将其用于不同的活动。第一用户120和一个或多个成员可以点击多个可点击UI元素以执行与该输入的集合相关联的特定任务。例如，在图4E中进一步描述多个可点击UI元素的生成的细节。

根据实施例，系统102可以接收对被覆盖的多个可点击UI元素中的第一可点击UI元素的选择。基于接收到的选择，系统102可以将实时地图UI的被呈现的第一视图切换到第二视图。例如，第一可点击UI元素可以与餐馆对应。第二视图可以与显示第一用户120的当前地点与餐馆的地点之间的路线的地图的视图对应。在一些实施例中，多个可点击元素可以包括一个或多个AR元素。例如，在图4G中进一步描述被呈现的第一视图到第二视图的切换的细节。

根据实施例，系统102可以接收对被覆盖的多个可点击UI元素中的第二可点击UI元素的选择。基于该选择，系统102可以将聊天窗口UI覆盖到实时地图UI上。聊天窗口UI可以启用第一用户120与消息传递组的成员之间的通信。例如，聊天窗口UI可以由第一用户120或消息传递组的成员用来在查看彼此的实时地点的同时立即彼此通信。例如，在图4G中进一步描述聊天窗口UI的覆盖的细节。

根据实施例，系统102可以接收与与第一用户120相关联的一个或多个被预先安排的任务的输入对应。例如，一个或多个被预先安排的任务可以包括第一用户120对站点的访问、对站点的检查等。系统102可以生成与一个或多个被预先安排的任务对应的一个或多个任务小部件。所生成的一个或多个任务小部件可以与旅行或旅行的活动段的实时地图UI一起被呈现。例如，一个或多个任务小部件可以与第一用户120在一天中要执行的活动(诸如访问站点、完成项目或参加会议)对应。例如，在图4H和4I中进一步描述一个或多个任务小部件的生成的细节。

根据实施例，系统102可以在旅行过程中控制电子设备118以将内容消费UI呈现到旅行的实时地图UI上。例如，内容消费UI可以包括可以显示媒体内容的媒体播放器UI、指示在旅行过程中包括第一用户120在内的一个或多个成员可能已经消费或尚未消费的媒体内容量的时间线，以及示出一个或多个成员的查看器UI元素。在一些实施例中，系统102可以通过在MaaS网络106的分布式分类账节点上执行一个或多个事务来跟踪一个或多个成员对媒体内容的消费。例如，在图4J中进一步描述内容消费UI的呈现的细节。

在一些实施例中，系统102可以控制电子设备118以呈现视觉计划器UI。呈现视觉计划器UI可以包括例如可以以图形方式表示将在旅行过程中被覆盖的一个或多个行程项目的第一组UI元素，以及可以与配置一个或多个行程项目中的每一个的选项对应的第二组UI元素。系统102可以接收对第二组UI元素中的一个或多个UI元素的选择。基于该选择，出行计划可以被更新。系统102可以触发MaaS网络106进一步基于更新后的出行计划生成预订细节。例如，在图4J中进一步描述视觉计划器UI的呈现的细节。

图2是根据本公开的实施例描绘多模式出行系统的会话式用户体验的示例性序列图。图2结合图1中的元素进行解释。参考图2，示出了说明从202到216的操作序列的序列图200。该操作序列可以由图1的系统102、电子设备118、分散式存储系统116或MaaS网络106执行。

在202处，系统102可以控制与第一用户120相关联的电子设备118以呈现第一UI122。第一UI 122可以与联网应用相关联，并且第一用户120可以是联网应用的注册用户。例如，在图4A中进一步描述联网应用的示例性界面。

根据实施例，第一UI 122可以是聊天UI。例如，第一用户120可以利用聊天UI与在联网应用上注册的一个或多个成员(诸如用户)通信。在示例性场景中，联网应用可以包括多个聊天UI。例如，多个聊天UI中的第一聊天UI可以专用于第一用户120的家庭组。多个聊天UI中的第二聊天UI可以专用于第一用户120的一组朋友。多个聊天UI中的第三聊天UI可以专用于特定用户，诸如密友或妻子。

在一些实施例中，聊天UI可以基于对联系人名字的选择或者对来自多个聊天UI的先前呈现的聊天UI(指示最近的聊天)的选择来呈现。例如，在图4B和4C中进一步描述作为聊天UI的第一UI 122的细节。

在204处，系统102可以通过第一UI 122获取一个或多个消息。一个或多个消息可以包括来自第一用户120的自然语言输入。根据实施例，自然语言输入可以与第一用户120与这种消息的一个或多个接收者之间的基于语音的会话、基于视频的会话或基于文本的会话中的一个对应。例如，作为聊天UI，第一UI 122可以被第一用户120用于与一个或多个接收者通信。一个或多个消息可以与关于八月初前往纽约的两天旅行的计划的基于文本的会话对应。第一用户120可以在所呈现的聊天UI上发布文本消息以计划去纽约的旅行。例如，本文消息可以是“嘿，让我们计划去纽约度假”。响应于该文本消息，一个或多个接收者可以在聊天UI上做出响应。例如，响应可以是文本消息、语音消息或视频消息的形式。在一些实施例中，与作为纽约的出行地点相关联的统一资源定位符(URL)可以由第一用户120与聊天UI中的一个或多个接收者共享。例如，在图4C中进一步描述具有一个或多个消息的聊天UI的细节。

在实施例中，系统102可以利用基于语音的会话(或基于语音的命令)来在旅行期间帮助第一用户120。基于语音的命令可以由第一用户120设置。例如，诸如“与我的团队成员共享内容”、“向Donald请求内容”、“支付饮料的费用”和“与经理开始意见调查”之类的基于语音的命令可以被用于在旅行期间提供帮助。在示例中，系统102可以将机器人与MaaS网络106对接以用于MaaS相关的查询和命令。例如，第一用户120可以使用诸如“在我停车前10分钟提醒我”之类的基于语音的命令。基于语音的认证还可以被用于在旅行期间启用支付。基于语音的认证还可以被用于用户识别和支付的授权。作为示例而非限制，系统102可以接收基于语音的命令“汇款”。系统102可以将对事务的请求传输到银行的服务器并且可以从银行的服务器接收认证第一用户120的请求。系统102可以向与第一用户120相关联的电子设备118传输通知。系统102可以从第一用户120接收基于语音的认证并且可以将基于语音的认证传输到银行的服务器。基于接收到基于语音的认证，银行的服务器可以授权事务。

在206处，系统102可以获取与第一用户120相关联的用户数据。根据实施例，用户数据可以包括第一用户120的个人信息。个人信息的示例可以包括但不限于第一用户120的名字、第一用户120的注册电子邮件ID、第一用户120的联系号码、第一用户120的当前地点和第一用户120的地址。用户数据还可以包括用户偏好的集合。用户偏好的集合可以包括例如对出行地点的偏好、对出行地点的宾馆的偏好、对运输方式的偏好、一年中出行的优选时段(诸如特定的月份或周)等。用户数据还可以包括第一用户120的出行历史。例如，出行历史可以包括第一用户120访问过的地方(诸如城市或国家)、第一用户120的过去几次假期的细节以及日常出行信息(诸如到达办公室的路线)。

在实施例中，用户数据可以包括内容偏好的集合，诸如第一用户120偏好的电影或节目类型以及第一用户120偏好的音乐的类型。用户数据可以包括内容消费信息，诸如之前观看的电影和播放的音乐。用户数据还可以包括在旅行中被覆盖的地点的背景中用户生成的内容。例如，用户生成的内容可以包括由第一用户120在出行地点捕获的一个或多个图像以及由第一用户120在出行地点记录的一个或多个视频。用户生成的内容还可以包括第一用户120与联网应用上的其他用户的会话历史(诸如聊天历史)。

用户数据还可以包括社交数据，包括但不限于聊天历史、与一个或多个消息传递组的成员的过去交互的集合、记录在聊天历史中的每个会话的社交背景，以及第一用户120的社交网络中的一组人。例如，社交网络中的这组人可以是第一用户120的家庭成员、第一用户120的朋友、第一用户120的办公室同事等。与这组人中的每一个的每次会话的社交背景可以包括在用户数据中。

在208处，系统102可以使用一个或多个NLP模型104来处理所获取的一个或多个消息以确定背景信息。背景信息可以指示第一用户120前往第一地点的意图以及与该出行相关联的时间表。一个或多个消息可以被输入到一个或多个NLP模型104。一个或多个NLP模型104可以处理该一个或多个消息以输出背景信息。例如，系统102可以向NLP模型输入消息“让我们计划去纽约的旅行”。由NLP模型输出的背景信息可以包括“第一用户120想要与第二用户计划去纽约市的旅行”。

根据实施例，背景信息还可以指示与一个或多个消息相关联的社交背景。社交背景可以指示其中第一用户120可以与一个或多个消息的一个或多个接收者交互的社交设置。背景信息还可以指示与一个或多个消息的一个或多个接收者的社交关系。作为示例，第一用户120可以是消息的一个或多个接收者的同事。社交背景可以指示纽约之行是与同事的商务旅行。作为另一个示例，第一用户120可以是消息的一个或多个接收者的朋友。社交背景可以指示纽约之行是与朋友一起度假。例如，在图5中进一步描述一个或多个NLP模型104的示例性体系架构的细节。

在210处，系统102可以将所获取的一个或多个消息以及所确定的背景信息存储在分散式存储系统116的存储节点(诸如第一存储节点116A)上。分散式存储系统116的每个节点上的存储可以特定于运输服务提供商的组中的运输服务提供商。例如，第一运输服务提供商可以由第一用户120使用。所获取的一个或多个消息和所确定的与第一用户120相关联的背景信息可以本地存储在第一存储节点116A上。这样做可以安全地存储特定于用户的数据并维护第一用户120的隐私。

在实施例中，第一用户120的一个或多个消息、背景信息、状况(诸如在线可联系性)以及用户数据可以存储在第一存储节点116A上。类似地，与一个或多个接收者相关联的消息、与一个或多个接收者相关联的背景信息、一个或多个接收者的状况(诸如在线可联系性)以及一个或多个接收者的用户数据可以存储在分散式存储系统116的相应存储节点上。

在212处，系统102可以基于背景信息和用户数据生成出行计划。根据实施例，出行计划可以包括针对第一用户120和正进行到第一地点的旅行的一个或多个接收者中的每一个的旅行的路线。在示例性场景中，出行计划可以包括在第一地点(诸如纽约)参观的地方。这些地方可以包括著名的古迹、餐馆、游乐园、剧院、博物馆等。出行计划还可以包括与访问每个地方对应的日期和时间。出行计划还可以包括到第一地点的行程的总持续时间、到达第一地点的日期和时间以及离开第一地点的日期和时间。例如，在图4D中进一步描述用于出行计划的示例性第一UI的细节。

在214处，系统102可以触发MaaS网络106以生成所生成的出行计划中指定的旅行的预订细节。系统102可以将与第一用户120相关联的预订数据传输或共享到MaaS网络106。预订数据可以包括例如用户数据，诸如第一用户120的名字和第一用户120的联系号码。预订数据还可以包括用于旅行的每一段的交通服务的支付细节和用于地点的支付细节，诸如用于在旅行期间逗留的宾馆。基于所传输的预订数据，可以在MaaS网络106上创建事务记录。系统102可以基于所创建的事务记录来生成预订细节。

在示例性场景中，预订细节可以包括第一用户120到第一地点的出行日期、出发航班信息、到达航班信息、要用于该旅行的几个段的多模式交通服务、宾馆登记细节、宾馆退房细节等。例如，在图3A和图3B中进一步描述预订细节的生成的细节。

分布式分类账数据库110可以存储细节，诸如旅行确认细节(例如，票识别(ID)号)、旅行变更细节(诸如在旅行中请求的变更)、出程计划的确认的细节、第一用户120和一个或多个成员关于参加活动的共识、任务的状况以及支付细节。

在216处，系统102可以控制电子设备118以将生成的预订细节显示到第一UI 122或第二UI 124上。第二UI 124可以与第一UI 122不同。例如，预订细节可以显示在电子设备118的显示屏上呈现的第一UI 122上。显示屏可以集成到电子设备118中或者可以与电子设备118分离。第一用户120可以查看在第一UI 122或第二UI 124上显示的预订细节。例如，在图4D中进一步描述显示预订细节的示例性第一UI的细节。

虽然序列图200被示为离散操作，诸如202、204、206、208、210、212、214和216，但是，在某些实施例中，取决于特定实施方式，此类离散操作可以进一步被划分为附加操作、组合成更少操作或被消除，而不背离所公开的实施例的本质。

图3A和图3B是根据本公开的实施例共同图示预订细节的生成以及在用户界面上呈现预订细节的图。图3A和图3B结合图1和图2中的元素进行解释。参考图3A和3B，示出了说明从302到328的操作序列的序列图300。该操作序列可以由图1的系统102、电子设备118、MaaS网络106或者一个或多个MP服务器112执行。

在302处，系统102可以选择包括具有与第一用户120的出行兴趣相同或相似的出行兴趣的一组成员的消息传递组。系统102可以基于背景信息和用户数据来选择消息传递组(如图1和图2中所描述的)。例如，第一用户120在联网应用上的搜索历史可以表明第一用户120对前往第一地点(例如，纽约)出行的兴趣。在另一个示例中，一个或多个消息可以指示第一用户120对前往第一地点(纽约)出行的兴趣。系统102可以选择与第一用户120对第一地点“纽约”的出行兴趣对应的消息传递组。

消息传递组可以是联网应用上预先存在的组，其中该成员组对前往某些地点(诸如纽约)感兴趣。在一些实施例中，具有相似出行兴趣的多个组可以存在于联网应用上。系统102可以基于用户数据和背景信息从多个组中选择消息传递组。例如，可以基于第一用户120的年龄组、第一用户120偏好的出行日期或者第一用户120的任何其它偏好来选择消息传递组。

在一个或多个实施例中，所选择的消息传递组可以存在于第一用户120可以在其上注册为用户的任何消息传递客户端上。系统102可以基于特定消息传递客户端的用户偏好来选择消息传递组。在一些实施例中，不同的消息传递客户端可以与MaaS网络106相关联。系统102可以从与MaaS网络106相关联的不同消息传递客户端选择消息传递组。

在304处，系统102可以控制电子设备118以显示加入消息传递组的推荐。例如，加入消息传递组的推荐可以包括在第一UI 122上显示的消息传递组的名称。加入消息传递组的推荐还可以包括关于消息传递组和消息传递组的成员的信息。

在一个或多个实施例中，系统102可以基于背景信息和用户数据来提供多个消息传递组的推荐。作为示例，可以基于第一用户120的当前地点推荐第一消息传递组，可以基于第一用户120的年龄组推荐第二消息传递组，可以基于第一用户120与家人、朋友或同事一起出行的兴趣推荐第三消息传递组。例如，在图4A中进一步描述用于显示消息传递组的推荐的示例性UI的细节。

在306处，系统102可以利用一个或多个NLP模型104来分析第一用户120与消息传递组的一个或多个成员之间的会话。例如，可以分析第一用户120与一个或多个成员之间的会话以确定背景信息。示例性会话可以指示第一用户120和一个或多个成员有兴趣在下个月底左右前往第一地点(诸如欧洲的地点)。示例性会话可以由一个或多个NLP模型104分析以确定背景信息。例如，背景信息可以包括第一用户120和一个或多个成员的感兴趣地点(诸如欧洲)、旅行的优选日期(诸如9月24日至9月30日)以及优选活动的信息。

在308处，系统102可以通过使用一个或多个NLP模型104基于对第一用户120与消息传递组的一个或多个成员之间的会话的分析来生成出行计划。出行计划可以包括第一用户120和正进行到第一地点的旅行的一个或多个成员中的每一个的旅行的行程。

在实施例中，对于第一用户120和正进行到欧洲的旅行的一个或多个成员来说，在欧洲访问的优选活动或优选地点可以不同。基于个人偏好，系统102可以为第一用户120和所述一个或多个成员生成个性化行程。例如，第一用户120可能对参观博物馆不感兴趣。因此，对于第一用户120，行程可以不包括参观博物馆。代替地，行程可以包括参观博物馆附近的偏好的地方(诸如餐馆)。系统102可以包括博物馆附近的地方，因为一个或多个成员中的大多数可能在博物馆，并且第一用户120可以能够在旅行中安排好的时间加入该一个或多个成员。类似地，对于一个或多个成员中的每一个，行程中的此类排除可以由系统102进行。

在310处，系统102可以控制电子设备118以将交互式UI元素的集合覆盖到第一UI122或第二UI 124上。该交互式UI元素的集合可以包括与旅行相关联的共享时间表。例如，消息传递组可以被用于在到第一地点的旅行期间发起或继续第一用户120与一个或多个成员之间的会话。与旅行相关联的共享时间表可以被覆盖到聊天UI(诸如第一UI 122)上。共享时间表可以包括例如偏好的活动，诸如在餐馆见面吃午餐。

交互式UI元素的集合还可以包括意见调查以确定是否计划旅行过程中的活动。例如，第一用户120可以创建访问游乐园的意见调查。意见调查可以覆盖在消息传递组中的第一UI 122上。意见调查可以包括选项，诸如选项“是”和选项“否”。一个或多个成员中的每一个可以基于个人偏好对意见调查作出响应，基于此可以由系统102生成行程。

交互式UI元素的集合还可以包括与旅行中覆盖的一个或多个地点相关的新闻。例如，作为到第一地点的旅行的行程的一部分的海滩地点可以被关闭。与海滩相关的新闻可以经由消息传递组中的交互式UI元素来共享。

该交互式UI元素的集合还可以包括与一个或多个地点相关联的共同感兴趣的项目。例如，在去游乐园的路上，可以有餐馆。可以经由消息传递组中的交互式UI元素共享到餐馆的地点和方向。

根据实施例，第二UI 124可以包括地图UI元素，交互式UI元素的集合可以覆盖在该地图UI元素上。地图UI元素可以描绘第一用户120和一个或多个成员行进的实时路线。例如，与餐馆对应的交互式UI元素可以覆盖在与地图UI元素对应的实时路线上的餐馆的确切地点上。类似地，访问游乐园的意见调查可以覆盖在地图UI元素上游乐园的确切地点上。

在312处，系统102可以经由第一UI 122接收可以与出行计划的确认对应的第一用户输入。例如，生成的出行计划可以包括交通模式、优选路线以及路线上的停靠站(在出行计划中)的细节。系统102可以接收可以与出行计划的确认对应的第一用户输入。在一些情况下，所生成的出行计划可能不适合第一用户120。例如，第一用户120执行出行计划的优选定时可以与出行计划中指定的时间不同。在这种情况下，第一用户120可能不接受出行计划。

在314处，系统102可以触发MaaS网络106以基于接收到的第一用户输入生成预订细节。在接收到第一用户输入之后，MaaS网络106可以被触发以生成预订细节，该预订细节可以包括例如对餐馆的预约、参观博物馆、出行/运输服务(诸如对于旅行的一段或多段乘坐出租车、乘坐公共汽车或乘坐火车)的预订等。

在示例性场景中，消息传递组可以与第一用户120的办公室相关联。在这种情况下，消息传递组可以包括第一用户120和该组成员(即，第一用户120的同事)。系统102可以从与第一用户120相关联的电子设备118接收消息“我将在回家的路上从Justin的住所拿上文档”。此后，系统102可以通过使用一个或多个NLP模型104来处理接收到的消息和与第一用户120相关联的用户数据以确定背景信息。背景信息可以包括细节，诸如“Justin的住所的地点”和“从办公室到Justin的住所的路线”。系统102可以控制电子设备118向第一用户120显示基于背景信息生成的出行计划。在一些实施例中，系统102可以控制电子设备118以将交互式UI元素的集合(诸如Justin的住所的地点)覆盖在第一UI 122上。

在实施例中，系统102可以经由第一UI 122接收可以与生成的出行计划的确认对应的第一用户输入。基于接收到的确认，系统102可以触发MaaS网络106以生成预订细节。

在316处，系统102可以控制电子设备118以将生成的预订细节显示到第一UI 122(诸如聊天UI)或第二UI 124(诸如地图UI元素)上。所显示的预订细节可以由第一用户120在与联网应用相关联的第一UI 122或第二UI 124上查看。例如，在图4D中进一步描述显示预订细节的示例性第一UI的细节。

在318处，系统102可以从一个或多个MP服务器112接收与在旅行之前和旅行过程中可能发生的事件相关联的跟踪信息。例如，跟踪信息可以包括与第一用户120相关联的地点信息。跟踪信息可以包括从第一用户120的办公室出发的旅行(诸如到Justin的住所的旅行)的开始时间。一个或多个MP服务器112可以保存与可能在旅行之前和旅行过程中发生的事件相关联的跟踪信息的记录。

在320处，系统102可以检测事件。事件的检测可以基于预订细节和接收到的跟踪信息。这些事件可以与可以在出行计划中指定的旅行的每一段的开始对应。例如，旅行的第一段可以与从办公室到同事的住所(例如，Justin的住所)的出行对应。旅行的第二段可以与从Justin的住所到第一用户120的家的旅行对应。

检测到的事件可以与从第一用户120的办公室起的旅行的第一段的开始对应。这些事件还可以与旅行的每一段的结束对应。例如，检测到的事件可以与旅行的第一段的结束(诸如到Justin的住所)对应。事件还可以与旅行的每一段开始和结束的地点对应。例如，事件可以与第一用户120的开始地点(诸如办公室)和结束地点(诸如Justin的住所)对应。这些事件还可以与旅行的每一段开始和结束的时间戳对应。例如，检测到的事件可以与旅行的段(诸如前往Justin的住所的旅行)的开始时间以及旅行的段的结束时间对应。所述事件还可以与改变旅行的至少一段的路线或运输服务提供商的请求对应。例如，在旅行的第一段的出行计划中指定的第一路线可能不适合第一用户120。系统102可以接收改变旅行的第一段的第一路线的请求。这些事件还可以与路线或运输服务提供商的改变对应。例如，事件可以包括第一用户120代替出行计划中指定的第一路线所采取的替代路线。

在322处，系统102可以通过基于所跟踪的事件在MaaS网络106的分布式分类账节点(诸如分布式分类账数据库110的节点)上执行一个或多个事务来跟踪旅行的进度。例如，系统102可以通过在分布式分类账数据库110的分布式分类账节点上传输所跟踪的事件来执行一个或多个事务。以这样的方式，与第一用户120相关联的事件(可以在旅行之前和旅行过程中发生)可以被安全地存储在分布式分类账数据库110上。基于所执行的事务，可以跟踪第一用户120的旅行的进度。

在324处，系统102可以接收第二用户输入，该第二用户输入可以与改变或取消旅行的至少一段的路线、时间表或运输服务提供商的请求对应。系统102可以经由第一UI 122接收第二用户输入。例如，出行计划可以发生改变。第一用户120可能想要将旅行延长几天并且可能需要访问第二地点。第二用户输入可以由系统102接收以改变出行计划中指定的回程路线。在另一个示例中，第二用户输入可以与出行计划中指定的回程的运输服务提供商的改变对应。

在326处，基于接收到的第二用户输入，系统102可以触发MaaS网络106更新预订细节。MaaS网络106可以通过在MaaS网络106的分布式分类账节点上执行事务来更新预订细节。例如，更新后的预订细节可以包括第二地点的出行信息。更新后的预订细节还可以包括回程航班信息(诸如从第二地点到第一用户120的居住城市)。

在328处，系统102可以控制电子设备118以呈现可以告知更新后的预订细节的通知。与更新后的预订细节对应的通知可以在第一UI 122上被呈现。

在示例性场景中，预订细节可以是第一用户120从办公室到Justin的住所的旅行。系统102可以经由与第一用户120的家相关联的消息传递组来接收第二用户输入。与第一用户120的家相关联的消息传递组可以包括第一用户120和第一用户120的家庭成员。系统102可以从与第一用户120相关联的电子设备118接收第二用户输入，诸如消息“我将在下班后迟到并且赶不上晚餐”。此后，系统102可以通过使用一个或多个NLP模型104来处理接收到的消息和与第一用户120相关联的用户数据以确定背景信息。背景信息可以包括细节，诸如“计划在去Justin的住所的地点的路线上吃晚餐”或“计划在从Justin的住所回家的路线上吃晚餐”，以及“基于用户偏好推荐路线上的餐馆”。系统102可以控制电子设备118显示基于背景信息生成的更新后的出行计划。在实施例中，系统102可以接收更新后的出行计划的确认。基于接收到的确认，系统102可以触发MaaS网络106更新预订细节。

虽然序列图300被示为离散操作，诸如302、304、306、308、310、312、314、316、318、320、322、324、326和328，但是，在某些实施例中，取决于特定实施方式，此类离散操作可以进一步被划分为附加操作、组合成更少操作或被消除，而不背离所公开的实施例的本质。

图4A是描绘根据本公开的实施例的与联网应用的主屏幕对应的示例性用户界面的图。图4A结合图1、图2、图3A和图3B中的元素进行解释。参考图4A，示出了图400A。图400A可以包括电子设备118。系统102可以控制电子设备118以呈现主屏幕402。在实施例中，当在电子设备118上访问联网应用时，主屏幕402可以被称为第一UI 122。主屏幕402可以包括搜索栏404。搜索栏404可以被用于搜索在联网应用上注册的其他用户或者与不同出行地点或其它偏好相关联的不同消息传递组。联网应用可以与一个或多个消息传递客户端相关联。

搜索栏404可以被第一用户120用来搜索旅行的偏好位置，例如“纽约”。搜索栏404可以被第一用户120用来搜索特定用户，诸如朋友或同事。主屏幕402可以显示一个或多个用户(诸如第一用户120的朋友)所行进的位置。主屏幕402还可以基于背景信息和用户数据来显示加入一个或多个消息传递组的推荐。例如，推荐可以包括第一消息传递组“家庭度假”和第二消息组“情侣度假”。

主屏幕402还可以包括图标的集合。该图标的集合可以包括主页图标406A、聊天图标406B、发现图标406C、活动图标406D和简档图标406E。主页图标406A可以被第一用户120用来查看主屏幕402。聊天图标406B可以被第一用户120用来查看聊天UI或查看消息传递组。发现图标406C可以被第一用户120用来搜索其他用户。活动图标406D可以被第一用户120用来查看和跟踪第一用户120在联网应用上的活动。简档图标406E可以被第一用户120用来查看简档信息，诸如第一用户120的用户名、第一用户120的注册的电子邮件以及第一用户120的联系信息。

图4B是描绘根据本公开的实施例的与联网应用的聊天屏幕对应的示例性用户界面的图。图4B结合图1、图2、图3A、图3B和图4A中的元素进行解释。参考图4B，示出了图400B。图400B可以包括电子设备118。

系统102可以控制电子设备118以呈现聊天屏幕408。第一用户120可以通过按下电子设备118上的聊天图标406B来查看聊天屏幕408。聊天屏幕408可以包括第一用户120可以是其成员的多个消息传递组(例如，作为图标)。例如，示出了消息传递组“纽约之行”。在示例中，消息传递组“纽约之行”可以由第一用户120创建，并且可以在消息传递组“纽约之行”中添加与第一用户120具有相同或相似出行兴趣的成员的组。聊天屏幕408可以显示消息传递组“纽约之行”以及描绘消息传递组“纽约之行”中的多个未读消息的通知。

在实施例中，第一用户120可以通过按下发现图标406C来查看发现屏幕410。通过经由搜索栏404搜索偏好位置，第一用户120可以利用发现屏幕410来按姓名搜索用户和搜索消息传递组。

图4C是描绘根据本公开的实施例的联网应用的示例性聊天用户界面的图。图4C结合图1、图2、图3A、图3B、图4A和图4B中的元素进行解释。参考图4C，示出了图400C。图400C可以包括电子设备118。系统102可以控制电子设备118以呈现聊天UI 412。例如，第一用户120可以通过访问消息传递组“纽约之行”来查看聊天UI 412。与消息传递组“纽约之行”对应的聊天UI 412可以包括第一用户120与消息传递组“纽约之行”的一个或多个成员之间的会话。聊天UI 412还可以包括第一用户120与一个或多个成员之间的会话的时间戳。

在一些实施例中，交互式UI元素的集合可以覆盖在聊天UI 412上，聊天UI 412可以是第一UI 122的示例性实施方式。交互式UI元素的示例包括用于确定是否在旅行过程中计划活动的意见调查。例如，访问位置“Magnolia Bakery”的意见调查可以覆盖在聊天UI412上。聊天UI 412还可以包括聊天框414，第一UI 122可以通过聊天框414输入一个或多个消息。

图4D是描绘根据本公开的实施例的显示预订细节的示例性用户界面的图。图4D结合图1、图2、图3A、图3B、图4A、图4B和图4C的元素进行解释。参考图4D，示出了图400D。图400D可以包括电子设备118。系统102可以控制电子设备118以呈现第一UI 418以显示预订细节。预订细节可以包括细节，诸如在出行计划中指定的旅行的开始日期以及与第一用户120一起行进到第一地点的一组成员的细节。预订细节还可以包括可以为旅行的某些部分/段安排或预订的各种交通服务的细节。第一用户120可以通过细节图标420访问诸如宾馆预约信息之类的其它细节。第一UI 418还可以包括用于访问旅行的行程的计划器图标422和用于访问旅行的每一段的路线的地图标424。第一UI 418还可以包括列表图标426以访问旅行中计划的活动的列表。

图4E是描绘根据本公开的实施例的与实时地图用户界面对应的示例性用户界面的图。图4E结合图1、图2、图3A、图3B、图4A、图4B、图4C和图4D的元素进行解释。参考图4E，示出了图400E。图400E可以包括电子设备118。

根据实施例，系统102可以从包括消息传递组的第一用户120在内的一个或多个成员接收输入的集合。该输入的集合可以与查看或突出显示旅行的活动段所采用的路线428的偏好相关联。例如，路线428可以是旅行的活动段。基于该输入的集合中的输入，可以突出显示路线428。另外，该输入的集合可以与一个或多个成员可能进行的旅行的行程相关联。例如，系统102可以基于用户偏好为第一用户120和一个或多个成员中的每一个生成单独的行程。该输入可以与例如包括在旅行的行程中的地标相关联。

输入的集合还可以与特定于位置的信息相关联，该特定于位置的信息与第一地点和旅行过程中的其它地点相关联。例如，系统102可以接收输入以查看到餐馆的路线。输入的集合还可以与将由一个或多个成员执行的一个或多个任务相关联。例如，文档可能需要由第一用户120取上。系统102可以接收输入以突出显示要取上文档的地方的地点。

系统102可以生成旅行或旅行的活动段的实时地图UI 430。而且，系统102可以基于接收到的输入的集合生成多个可点击UI元素。例如，第一可点击UI元素432可以与博物馆的位置对应。第二可点击UI元素434可以与餐馆的地点对应。第三可点击UI元素436可以与公园的地点对应。第四可点击UI元素438可以与教堂的地点对应。系统102可以控制电子设备118以呈现所生成的实时地图UI 430的第一视图。第一视图可以包括突出显示的路线428。系统102可以在所呈现的实时地图UI 430的第一视图上的对应位置处覆盖多个可点击UI元素，诸如第一可点击UI元素432、第二可点击UI元素434、第三可点击UI元素436和第四可点击UI元素438。

根据实施例，系统102还可以接收对可点击UI元素(诸如所覆盖的多个可点击UI元素中的第一可点击UI元素432)的选择。对第一可点击UI元素432的选择可以经由所生成的实时地图UI 430来接收。基于接收到的选择，系统102可以将实时地图UI 430的被呈现的第一视图切换到第二视图。第二视图可以与第一视图不同。例如，第二视图可以是突出显示的从第一用户120的当前地点到与第一可点击UI元素432对应的博物馆的地点的路线。

在一些实施例中，所生成的多个可点击元素可以包括一个或多个增强现实(AR)元素。例如，系统102可以确定电子设备118是启用AR的。基于该确定，所生成的多个可点击元素可以被呈现为一个或多个AR元素。

图4F是描绘根据本公开的实施例的生成的增强现实(AR)元素的图。图4F结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D和图4E的元素进行解释。参考图4F，示出了图400F。图400F可以包括电子设备118和对象440。

系统102可以确定电子设备118是启用AR的，并且可以基于在旅行过程中已经访问过的地点来生成交互式AR元素的集合。例如，交互式AR元素的集合中的AR元素可以与第一用户120访问的游乐园的AR视图对应。交互式AR元素的集合还可以基于当前地点或在旅行过程中将访问的未来地点生成。例如，交互式AR元素的集合中的AR元素可以与第一用户120可能存在的街道的AR视图对应。所生成的交互式AR元素的集合还可以基于旅行中第一用户120与一个或多个成员(即，出行者)之间的会话生成。例如，对象440可以被餐馆中的第一用户120检测到。第一用户120可能需要与一个或多个成员谈论对象440。可以通过使用与电子设备118相关联的成像传感器来扫描对象440。系统102可以生成与对象440对应的AR元素442。

系统102还可以生成关于对象440的信息444。例如，对象440可以是特定品种的番茄。所生成的关于对象440的信息444可以包括对象440的名称(诸如番茄)、对象440的一般重量、对象440具有的卡路里数以及对象440的颜色。所生成的信息444可以呈现在电子设备118的第一UI 122上。

交互式AR元素的集合还可以基于第一用户120与一个或多个成员之间的会话的背景生成。例如，一个或多个消息可以与第一地点处的美食节相关联。系统102可以生成与第一地点处的美食节对应的AR元素。交互式AR元素的集合还可以基于第一用户120与一个或多个成员的共同兴趣(诸如，偏好的菜肴、新闻条目和特定地点)和共享的时间表(诸如同时出发的航班)生成。作为示例，AR元素可以基于第一用户120的头像。在一些实施例中，可以针对特定目标组(诸如但不限于特定年龄段或收入群体中的组、特定品牌的购物者或追随者或者特定地点的居民)生成交互式AR元素的集合。系统102可以控制电子设备118以将生成的AR元素的集合(诸如与对象440对应的AR元素442)呈现到第一UI 122或第二UI 124上。系统102可以允许用户(诸如可以具有启用AR的硬件(诸如电子设备118)的第一用户120)与一个或多个成员中可能没有启用AR的硬件的其他成员共享AR体验。

图4G是描绘根据本公开的实施例的覆盖在实时地图用户界面上的多个可点击UI元素的图。图4G结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D、图4E和图4F的元素进行解释。参考图4G，示出了图400G。图400G可以包括电子设备118。电子设备118可以包括生成的实时地图UI 430和覆盖在路线428上的多个可点击UI元素。

系统102可以接收对被覆盖的多个可点击UI元素中的第二可点击UI元素446的选择。第二可点击UI元素446可以与来自一个或多个成员中的成员的消息对应并且可以被覆盖在路线428上的一个或多个成员中的成员的地点处。

基于接收到的对第二可点击UI元素446的选择，系统102可以将聊天窗口UI覆盖到实时地图UI 430上。聊天窗口UI可以启用第一用户120与消息传递组的一个或多个成员中的成员之间的通信。例如，第二可点击UI元素446可以与成员的消息“你准备好了吗？”对应。第二可点击UI元素446可以被第一用户120点击，基于此，聊天窗口UI可以被覆盖到实时地图UI 430上。

根据实施例，系统102可以在旅行过程中控制电子设备118以将内容消费UI呈现到旅行的实时地图UI 430上。内容消费UI可以包括可以显示媒体内容的媒体播放器UI。媒体内容(诸如歌曲、有声读物、播客和电影)可以由第一用户120和一个或多个成员在旅行时消费。基于内容访问类型，媒体内容可以被分类为公共内容或私有内容。公共内容可以基于共同兴趣可访问。私有内容(诸如部门领导的消息)可以仅特定组可访问。

媒体播放器UI可以将用于第一用户120的媒体内容显示到实时地图UI 430上。内容消费UI还可以包括时间线，该时间线可以指示包括第一用户120在内的一个或多个成员在旅行过程中可能已经消费或者可能尚未消费的媒体内容的量。例如，内容消费UI可以包括带时间戳的时间线。第一用户120和一个或多个成员中的每一个对媒体内容的消费的进度可以用时间线上的不同时间戳来指示。内容消费UI还可以包括可以示出一个或多个成员的查看器UI元素。例如，查看器UI元素可以显示一个或多个成员中的每一个的名字。

根据实施例，系统102可以通过在MaaS网络106的分布式分类账节点上执行一个或多个事务来跟踪一个或多个成员的媒体内容的消费。系统102可以将与媒体内容的消费对应的事务记录传输到MaaS网络106的分布式分类账节点(诸如分布式分类账数据库110的节点)。

系统102可以使得内容提供商能够跟踪目标特定组并且从用户的消费行为中学习。可以利用对特定组的跟踪来管理各种组(诸如青少年、成人、儿童和实习生)的内容流。

图4H是描绘根据本公开的实施例的示例性基于自定义地图的用户界面的图。图4H结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D、图4E、图4F和图4G的元素进行解释。参考图4H，示出了图400H。图400H可以包括基于UI 448的自定义地图。

基于自定义地图的UI 448可以包括与第一用户120和一个或多个成员中的每一个对应的定制实时地图。例如，第一定制实时地图450可以描绘第一用户120偏好的路线。第二定制实时地图452可以描绘一个或多个成员中的成员偏好的路线。例如，第一定制实时地图450可以被第一用户120请求以查看路线图，其中咖啡店的地点在所显示的路线图上被突出显示。

在一个或多个实施例中，基于自定义地图的UI 448可以包括与第一用户120和一个或多个成员的实时地点相关联的合成实时出行地图。基于自定义地图的UI 448还可以包括与第一用户120和一个或多个成员所行进的路线的当前段相关联的路线的段的合成出程地图。基于自定义地图的UI 448还可以包括与第一用户120和一个或多个成员中的每一个相关联的实时出行地图。

在实施例中，基于自定义地图的UI 448还可以包括一个或多个成员中的每一个的名字和状况(诸如在线状况或离线状况)。例如，基于自定义地图的UI 448可以包括名字“Carly Shannon”并且可以显示最后看到的状况，诸如与用户“Carly Shannon”相关联的“2小时前连接”。

在实施例中，基于自定义地图的UI 448还可以包括用于搜索成员的搜索栏454和用于搜索消息传递组的搜索栏456。基于自定义地图的UI 448还可以包括出行计划的旅行的当前段的时间戳。基于自定义地图的UI 448还可以包括消息窗口458，消息窗口458可以包括第一用户120与一个或多个成员之间公共的消息传递组。基于自定义地图的UI 448还可以包括任务窗口460，任务窗口460可以描绘行程中包括的任务。

在实施例中，基于自定义地图的UI 448可以包括报告窗口462，报告窗口462可以包括第一用户120与一个或多个成员之间的共享文档。基于自定义地图的UI 448还可以包括轨迹窗口464，其可以包括第一用户120和一个或多个成员所覆盖的路线；参与者窗口466，其可以包括旅行中的参与成员的细节；信息窗口468，其可以包括关于事件的各种信息；以及事件列表窗口470，其可以包括所确定的事件的列表。

在实施例中，基于自定义地图的UI 448可以包括地图层以显示用于第一用户120的主要内容(诸如实时路线)和交互式定制内容。基于自定义地图的UI 448还可以包括基于AR的导航，其可以向第一用户120提供地点引导。系统102还可以生成与要探索的地点对应的AR元素。与地点对应的AR元素可以包括隐藏的基础设施，诸如燃气管道、地下铁(metro)和地铁(subway)。

基于自定义地图的UI 448可以被用于基于诸如距离、成本和其它度量之类的参数来搜索第一用户120的附近区域。基于自定义地图的UI 448还可以被用于在第一用户120与一个或多个成员之间共享搜索结果作为地图表示。

图4I是描绘根据本公开的实施例的一个或多个任务小部件的图。图4I结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D、图4E、图4F、图4G和图4H的元素进行解释。参考图4I，示出了图400I。图400I可以包括电子设备118。

系统102可以控制电子设备118以呈现第一UI 472。通过第一UI 472，系统102可以接收可以与与第一用户120相关联的一个或多个被预先安排任务的输入对应。例如，第一被预先安排任务可以与对站点“A”的检查对应。第二被预先安排任务可以与对站点“B”的检查对应。系统102可以生成与这样的被预先安排任务对应的一个或多个任务小部件。例如，系统102可以生成与第一被预先安排任务对应的第一任务小部件474和与第二被预先安排任务对应的第二任务小部件476。

系统102可以控制电子设备118以呈现所生成的一个或多个任务小部件，诸如第一任务小部件474和第二任务小部件476，以及旅行或旅行的活动段的实时地图UI 478。在示例性场景中，可以与一个或多个被预先安排任务对应的输入可以包括一个或多个被预先安排任务的优先级。例如，一个或多个被预先安排任务中的每一个可以具有高优先级或低优先级。所生成的一个或多个任务小部件可以包括所设置的任务的优先级以及完成一个或多个被预先安排任务的日期/时间。

系统102可以控制电子设备118以呈现第二UI 480。第一任务小部件474可以由第一用户120访问以查看可以包括第一被预先安排任务的细节的第二UI 480。例如，第二UI480可以包括检查站点“A”的日期、站点“A”的地点、第一被预先安排任务的描述、第一被预先安排任务的状况、与第一被预先安排任务相关联的注释，以及与第一被预先安排任务相关联的附加文档。

图4J是描绘根据本公开的实施例的示例性视觉计划器用户界面的图。图4J结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D、图4E、图4F、图4G、图4H和图4I的元素进行解释。参考图4J，示出了图400J。图400J可以包括视觉计划器UI 482。

系统102可以控制电子设备118以呈现视觉计划器UI 482。视觉计划器UI 482可以包括第一组UI元素484，其可以以图形方式表示将在旅行过程中覆盖的一个或多个行程项目。视觉计划器UI 482还可以包括第二组UI元素486，其可以与用于配置要在旅行过程中覆盖的一个或多个行程项目中的每一个的选项对应。系统102可以接收对第二组UI元素486中的一个或多个UI元素的选择。例如，可以选择UI元素488。基于接收到的选择，系统102可以更新出行计划。例如，UI元素488可以与对保护区的访问对应。UI元素488可以是可点击UI元素以将行程项目标记为完成。基于对UI元素488的选择，对保护区的访问可以从行程中即将发生的事件中被移除。MaaS网络106可以被触发以基于更新后的出行计划生成预订细节。

系统102可以为第一用户120启用基于消费的计费模型并且可以基于第一UI 122的使用模式提供灵活的定价。系统102可以启用对消息传递组的包括和更高级别的访问的协商。

在计划旅行之前以及在通过MaaS网络106预订旅行的过程中，系统102可以使得能够更好地理解客户(诸如第一用户120)以进行定制的服务交付。MaaS网络106可以利用灵活的服务交付模型来实现收入最大化。对于内容提供商而言，经常性定价和消费定价的灵活组合可以允许内容提供商有效地进行实验、市场测试和重新调整。系统102可以允许内容提供商依赖MaaS网络106来无缝地访问服务。

应当注意的是，图4A-4J中所示的示例性用户界面仅作为示例呈现。此类示例不应当被解释为限制本公开。本公开可以适用于其它类型的用户界面。

图5是根据本公开的实施例的图1的网络环境的示例性软件级体系架构的图。图5结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D、图4E、图4F、图4G、图4H、图4I和图4J的元素进行解释。参考图5，示出了图500。图500可以表示图1的系统102的示例性系统体系架构。

图500可以包括自然语言处理模型502和语音识别模块504。语音识别模块504可以包括声学模型506、语言模型508和去噪模型510。图500还可以包括自然语言理解模型512。自然语言理解模型512可以包括域分类器514、序列标记器516和状态跟踪器518。

图500还可以包括MaaS接口520和地图引擎522。地图引擎522可以包括AR模块524、搜索模块526、编排器(composer)模块528以及通知和动作模块530。图500还可以包括决策模块532。决策模块532可以包括对话管理器534和意图排序器536。图500还可以包括用户简档数据库538、背景感知推荐模块540。背景感知推荐模块540可以包括背景因素模块542。

图500可以包括训练管道544和MaaS网络106。图500还可以包括功能模块546，其包括高级模块548。高级模块548可以包括对象检测模块550、图像分割模块552和低分辨率处置模块554。功能模块546还可以包括低级模块556。低级模块556可以包括视频处理模块558和图像处理模块560。

图500还可以包括控制模块562。控制模块562可以包括基于事件的回放控制模块564。图500还可以包括AR web服务模块566。图500还可以包括文档数据库568、流传输数据库570、地图数据库572和时间序列数据库574。图500还可以包括分散式用户信息服务器576。分散式用户信息服务器576可以包括个人信息模块578、用户状态模块580、背景模块582和虚拟现实过程数据模块584。

图500还可以包括地图引擎586。地图引擎586可以包括地图倾斜和呈现器588以及地图样式生成器590。图500还可以包括动态行程计划器592。动态行程计划器592还可以包括路线集成器594和路线生成器596。路线生成器596还可以包括基于场景的路线生成器596A和基于优化的路线生成器596B。动态行程计划器592还可以包括路线推荐器598。路线推荐器598还可以包括背景推断和过滤模块598A、路线效用计算器598B和聚合器598C。图500还可以包括推荐系统599。

用户数据可以存储在用户简档数据库538中。诸如基于语音的会话之类的一个或多个消息可以由语音识别模块504处理。语音识别模块504可以利用声学模型506、语言模型508和去噪模型510来处理第一用户120与一个或多个成员之间的基于语音的会话。

背景感知推荐模块540和语音识别模块504可以被自然语言处理模型502和自然语言理解模型512用来基于用户数据和一个或多个消息确定背景信息。决策模块532还可以被用于分析第一用户120与一个或多个成员之间的会话，以准确地确定背景信息。

自然语言处理模型502和自然语言理解模型512可以提供基于AI的智能以从第一用户120与一个或多个成员之间共享的一个或多个消息确定出行相关的背景信息。

分散式用户信息服务器576可以被用于安全地存储用户数据，诸如第一用户120的个人信息。这种分散式用户信息服务器576可以提供对用户数据的自我主权。例如，个人信息模块578可以存储第一用户120的个人信息，并且用户状态模块580可以存储第一用户120的状况(诸如在线状况或离线状况)。用户数据可以由自然语言处理模型502和自然语言理解模型512经由接口从分散式用户信息服务器576接收。

可以经由AR web服务模块566来促进第一用户120与一个或多个成员之间基于AR的体验的共享。控制模块562可以被用于控制可以显示媒体内容的媒体播放器UI。功能模块546可以被用于分析自然语言输入，诸如第一用户120与一个或多个消息的一个或多个接收者之间的基于语音的会话、基于视频的会话或基于文本的会话。

地图引擎522可以被用于基于地点和地图的服务，诸如生成实时地图UI和确定地方的地点。MaaS接口520可以被用于与系统102接口以获得诸如路线、订阅、支付、成本、距离和乘车可联系性之类的功能性。文档数据库568可以被用于存储在第一用户120与一个或多个成员之间共享的文档。流传输数据库570可以被用于存储在旅行过程中流传输的媒体内容。地图数据库572可以被用于存储生成的地图UI。时间序列数据库574可以被用于存储与旅行中的任务相关联的时间线。训练管道544可以被用于训练自然语言处理模型502。

地图引擎586可以被用于存储地图UI的不同表示或变化以及诸如地图UI的图块集和样式之类的相关联的数据。路线集成器594可以被用于收集与单模式路线相关联的信息并且聚集所收集的与单模式路线相关联的信息。路线集成器594还可以提供所收集的与单模式路线相关联的信息作为路线生成器596的输入。路线生成器596可以被用于通过使用来自MaaS网络106的移动参与者的数据(诸如与交通相关联的数据，例如，汽车共享数据、自行车共享数据和停车可联系性)来生成优化的路线场景。路线生成器596可以包括工作者线程，其可以被用于特定城市或出行模式的地图应用编程接口(API)。当计划的任务可能需要组成员共享或存放相关信息时，它可以直接访问数据库。路线生成器596的MaaS API和代理节点可以被用于通过任务预先安排器和工作者线程来更新共享和存放数据库。

路线推荐器598可以被用于组合路线场景、将组合的路线与用户或组背景相匹配，以及计算路线的效用。路线的效用可以基于个人或组效用、最优MaaS计划使用效用、环境友好性和模式推广效用来计算。路线效用计算器598B可以被用于通过使用指派给与偏好相关联的参数的权重来对第一用户或一个或多个成员的偏好进行优先级排序。可以通过使用本地和全局排名机制来优化路线。在示例性场景中，第一用户的偏好可以是“照明良好的道路”。由于偏好“照明良好的道路”不会影响所述一个或多个成员，因此具有照明良好的道路的路线可能是优选的。在实施例中，可以针对组(诸如用户的出行组)中的某些成员增加安全性参数的值，并且基于特定阈值，该组可以采取次优路线。不同的基于效用的排名路线列表可以被聚集以创建可以与组共享的最终排名路线列表。推荐系统599可以被用于生成与兴趣点相关联的推荐的集合。例如，在图7中进一步提供推荐系统599的细节。

图6是根据本公开的实施例的用于多模式出行系统的启用增强现实(AR)的会话用户体验的示例性体系架构。图6结合图1、图2、图3A、图3B、图4A、图4B、图4C、图4D、图4E、图4F、图4G、图4H、图4I、图4J和图5的元素进行解释。参考图6，示出了图600。图600可以包括移动客户端602和服务器604。

移动客户端602可以包括视图模块606。视图模块606可以包括地图视图模块608、AR视图模块610、通知视图模块612和视图寻呼机模块614。移动客户端602还可以包括后台服务模块616。后台服务模块616可以包括地点模块618。地点模块618可以包括事件处置器620和地点处置器622。后台服务模块616还可以包括传感器服务模块624。

移动客户端602还可以包括处置模块626。处置模块626可以包括数据管理器628和代表性状态转移(REST)客户端630。移动客户端602还可以包括型号632。型号632可以包括数据库访问层634、本地资产数据库636和本地数据库638。服务器604还可以包括web服务模块640和分散式数据库642。

系统102可以利用客户端-服务器模型来执行与系统102相关联的操作。例如，移动客户端602可以是电子设备118的一部分。服务器604可以是系统102的一部分。移动客户端602可以经由通信网络126通信地耦合到服务器604。

分散式数据库642可以被用于安全地存储用户数据。移动客户端602可以经由服务器604接收用户数据以便为第一用户120启用基于AR的会话用户体验。地图视图模块608可以被用于生成实时地图UI，交互式AR元素的集合可以覆盖在实时地图UI上。AR视图模块610可以被用于生成交互式AR元素的集合。通知查看模块612可以被用于查看通知，诸如第一用户120与一个或多个成员之间的消息。查看寻呼机模块614可以被用于从第一用户120切换到第二UI 124。

后台服务模块616的地点模块618可以被用于处置基于地点的服务和所确定的第一地点处的事件。传感器服务模块624可以被用于扫描对象以便生成交互式AR元素的集合。

处置模块626的REST客户端630可以被用于调用REST服务应用接口(API)以供系统102或运输服务提供商进行通信。例如，REST服务API可以被用于确定实时交通信息。数据库访问层634可以被用于访问存储在本地资产数据库636和本地数据库638中的用户数据。

图7图示了根据本公开的实施例的基于兴趣点的集合生成出行计划的示例性方法的流程图。图7结合图1、图2、图3A-3B、图4A-4J、图5和图6中的元素进行解释。参考图7，示出了700的流程图。流程图700的示例性方法可以由任何计算系统执行，例如，由图1的系统102执行。流程图700的示例性方法可以开始于702并且进行到704。

在704处，可以基于所确定的背景信息生成兴趣点的初始集合，例如，如图2中所描述的。根据实施例，系统102可以被配置为生成兴趣点的初始集合。根据实施例，所获取的一个或多个消息可以包括第一用户120和聊天组的一个或多个其他成员可能感兴趣的一个或多个地点的名称。所获取的用户数据可以包括关于第一用户120和所述成员偏好的地点的信息。背景信息可以包括关于此类地点的信息。

在706处，可以对生成的兴趣点的初始集合应用一种或多种优化技术以确定兴趣点的中间集合。根据实施例，系统102可以被配置为对生成的兴趣点的初始集合应用一种或多种优化技术以确定兴趣点的中间集合。此类技术可以被用于找到一种方式来组合沿着旅行的路线的尽可能多的地点，使得对于第一用户120来说与旅行相关联的价值被最大化。

一种或多种优化技术的应用可以包括基于用户偏好向生成的兴趣点的初始集合中的每一个指派权重。一种或多种优化技术可以利用具有高权重的兴趣点的初始集合来生成兴趣点的中间集合。一种或多种优化技术的示例可以包括但不限于旅行推销员问题、定向运动问题和背包问题。定向运动问题的示例可以包括团队定向运动问题、具有时间窗口的定向运动问题、具有时间窗口的团队定向运动问题、依赖时间的定向运动问题、具有时间窗口的多约束团队定向运动问题、广义定向运动问题、具有递减利润的团队定向运动问题、聚类的定向运动问题、利润随机的定向运动问题、出程和服务时间随机的定向运动问题。背包问题可以是例如Oregon小径背包问题。

在708处，可以生成与兴趣点的中间集合相关联的推荐的集合。根据实施例，系统102可以被配置为生成与兴趣点的中间集合相关联的推荐的集合。推荐的集合可以包括不同粒度的旅行和路线，诸如城市间路线、公路旅行，以及由多个地区组成的旅行。在一些实施例中，每个项目(诸如在不同地点计划的路线或活动)可以基于用户偏好来排名。

推荐的集合可以包括出行项目的集合，诸如多个兴趣点或出行目的地，以及可以组合连贯的旅行项目(诸如目的地、活动、逗留和推荐的集合中的其它服务)的出行计划(称为出行袋或出行包)。推荐的集合还可以包括项目的序列，诸如沿着第一用户120和与第一用户120一起出行的一个或多个成员的单日或多日旅行的愉快路线的兴趣点序列。

在一个或多个实施例中，推荐的集合可以基于用户的年龄(包括在用户数据中)或旅行当天的时间。包括在推荐的集合中的出行包可以在旅行开始之前生成。在实施例中，系统102可以利用出行地区作为输入来生成复合旅行，该复合旅行可以后面被包括在推荐的集合中。在一些情况下，可以基于假期的类型、办公室参观、出行地区和/或预期的运输手段来生成推荐的集合。推荐的集合可以包括行程项目的缓冲时隙，诸如旅行中的午餐和晚餐。

在一些实施例中，推荐的集合可以从其它较低权重项目中排除高权重项目(即，兴趣点)以将多样性纳入出行计划中。系统102可以分析先前的活动模式以生成推荐的集合。系统102可以分析与第一用户120和一个或多个成员相关联的背景信息以生成推荐的集合。

在710处，可以接收与生成的推荐的集合对应的第三用户输入。第三用户输入可以基于第一用户120与一个或多个消息的一个或多个接收者的共识。根据实施例，系统102可以被配置为接收与生成的推荐的集合对应的第三用户输入。例如，可以经由多个UI中的第四UI接收第三用户输入。例如，在图8A中进一步描述第三用户输入的接收的细节。

在712处，可以基于接收到的第三输入生成兴趣点的集合。根据实施例，系统102可以被配置为基于接收到的第三输入生成兴趣点的集合。基于第一用户120与一个或多个成员的共识，生成的兴趣点集合可以包括地点、活动、路线等。

在714处，可以基于生成的兴趣点的集合、背景信息和用户数据生成出行计划。生成的出行计划可以包括第一用户120和正进行到第一地点的旅行的一个或多个成员中的每一个的旅行的行程。

图8A-8C是共同图示根据本公开的实施例的示例性UI元素的图。图8A-8C结合图1、图2、图3A-3B、图4A-4J、图5、图6和图7的元素进行解释。

参考图8A，示出了图800A。图800A可以包括第四UI 802、讨论主题UI元素804和旅行计划序列UI元素806。第四UI 802可以显示推荐的集合808。讨论主题UI元素804可以包括地图810、警报UI元素812以及路线细节和度量UI元素814。旅行计划序列UI元素806可以包括细节UI元素816。

在实施例中，第四UI 802可以是聊天UI，其包括用于与第一用户120和可以是到第一地点的旅行的一部分的一个或多个成员交互的聊天机器人。系统102可以在第四UI 802中呈现所生成的推荐的集合808。例如，生成的推荐的集合808可以包括与兴趣点的中间集合(图7中描述的)、活动、路线等相关的多个选项。

第四UI 802可以被第一用户120和一个或多个成员用来与聊天机器人聊天并且更新出行计划。第四UI 802还可以被第一用户120和一个或多个成员用来提供与所生成的推荐的集合808对应的输入。第四UI 802可以基于接收到的与生成的推荐的集合808对应的输入来呈现意见调查。

基于生成的兴趣点的集合(基于共识)，可以生成讨论主题UI元素804。讨论主题UI元素804可以由第一用户120和一个或多个成员用来讨论旅行。地图810可以包括旅行的当前段和/或过去/即将到来的(一个或多个)段的地图。警报UI元素812可以包括关于警报的细节，诸如偏离路线或与旅行的当前段相关联的其它警报。警报UI元素812可以被配置为链接与地图810上的兴趣点的集合相关联的项目。路线细节和度量UI元素814可以包括旅行的当前段上的每个地点的细节、与路线相关联的度量、交通模式和设施、天气信息以及沿着旅行的当前段的活动的细节。

基于所生成的兴趣点的集合，可以生成旅行计划序列UI元素806。旅行计划序列UI元素806可以包括旅行的当前段中基于序列的地点列表，并且可以针对每个个体(诸如第一用户120或一个或多个成员)进行个性化。在一些实施例中，旅行计划序列UI元素806可以是基于地图的序列UI元素，其可以描绘地图上的地点序列。细节UI元素816可以包括与每个地点相关联的细节，例如，预订细节、宾馆细节、设施等。细节UI元素816可以被配置为链接与地图810上的兴趣点的集合相关联的项目。

基于第四UI 802中的会话，可以在地图810上更新搜索和标绘地点以及关键字和地理编码。此外，自动化的图形过程(诸如图例、自定义符号和覆盖)可以被更新。还可以更新出行时间和路线、缓冲区、具有属性的丰富层(诸如人口统计指示器和交通数据(其可以与所述组相关))。而且，可以在地图810上将特定路线标记为最喜爱的。地图810可以被保存或者地图810的一部分可以被保存为文档或对象以供将来的会话修改。另外，可以生成地图810的可打印地图视图。地图视图可以与后面可以添加到讨论主题UI元素804的其他用户共享。

参考图8B，示出了图800B。图800B可以描绘基于第四UI 802中的会话的旅行计划序列的改变。在示例性场景中，第一用户120可以要求在旅行的当前段期间拜访某人的家。第四UI 802可以被第一用户120用来包括新项目，即，在旅行的当前段或即将到来的段中访问某人的家。聊天机器人可以确认访问的持续时间，并且可以接收来自一个或多个成员的共识，以在旅行的当前段或即将到来的段中包括该人的家的地点。旅行计划序列UI元素806中的元素(诸如地点)可以是可点击的。

参考图8C，示出了图800C。图800C可以描绘基于第四UI 802中的会话将活动的细节包括在细节UI元素816中。在示例性场景中，第一用户120和一个或多个成员可以表现出在旅行的当前段期间添加活动“看电影”的意图。聊天机器人可以在第四UI 802中询问与活动“看电影”相关的信息。基于第一用户120与一个或多个成员的共识，系统102可以生成在旅行的当前段或即将到来的段中完成活动“看电影”的计划。对于该活动，可以通过细节UI元素816提供诸如电影院之类的地点的建议。可以通过使用与MaaS网络106的数据服务提供商的集成来显示细节UI元素816。

在一些实施例中，系统102可以生成活动UI元素，该活动UI元素可以将兴趣点的集合链接到讨论主题UI元素804、细节UI元素816和旅行计划序列UI元素806。系统102还可以生成可以将兴趣点的集合链接到地图810的消息UI元素。在这些或其它实施例中，系统102可以生成超级卡UI元素。超级卡UI元素可以根据关系被链接并且可以被显示为新的UI元素或者可以代替现有UI元素被显示。

图9是根据本公开的实施例的用于多模式出行系统的会话式用户体验的示例性系统的框图。图9结合图1、图2、图3A-3B、图4A-4J、图5、图6、图7和图8A-8C的元素进行解释。参考图9，示出了系统102的框图。系统102可以包括电路系统902和存储器904。存储器904可以包括一个或多个NLP模型104。系统102还可以包括输入/输出(I/O)设备906和网络接口908。

电路系统902可以包括合适的逻辑、电路系统和接口，这些逻辑、电路系统和接口可以被配置为执行与要由系统102执行的不同操作相关联的程序指令。电路系统902可以包括一个或多个处理单元，每个处理单元可以被实现为单独的处理器。在实施例中，一个或多个处理单元可以被实现为共同执行一个或多个处理单元的功能的集成处理器或处理器的集群。电路系统902可以基于本领域已知的多种处理器技术来实现。电路系统902的示例实施方式可以包括但不限于基于x86的处理器、基于x64的处理器、图形处理单元(GPU)、精简指令集计算(RISC)处理器、专用集成电路(ASIC)处理器、协处理器(诸如视觉处理单元(VPU))、复杂指令集计算(CISC)处理器、微控制器、中央处理单元(CPU)，和/或其组合。

存储器904可以包括合适的逻辑、电路系统和接口，这些逻辑、电路系统和接口可以被配置为存储要由电路系统902执行的一个或多个指令。存储器904可以被配置为存储一个或多个消息和用户数据。存储器904还可以被配置为存储所确定的背景信息、生成的出行计划和生成的预订细节。存储器904的实施方式的示例可以包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、硬盘驱动器(HDD)、固态驱动器(SSD)、CPU高速缓存和/或安全数字(SD)卡。

I/O设备906可以包括合适的逻辑、电路系统和接口，这些逻辑、电路系统和接口可以被配置为从第一用户和一个或多个成员接收输入并且基于接收到的输入提供输出。可以包括各种输入和输出设备的I/O设备906可以被配置为与电路系统902通信。I/O设备906的示例可以包括但不限于触摸屏、键盘、鼠标、操纵杆、麦克风、显示设备和扬声器。

网络接口908可以包括合适的逻辑、电路系统和接口，这些逻辑、电路系统和接口可以被配置为促进系统102、MaaS网络106、电子设备118、一个或多个MP服务器112和分散式存储系统116之间经由通信网络126的通信。网络接口908可以通过使用各种已知技术来实现，以支持电子设备118与通信网络126的有线或无线通信。网络接口908可以包括但不限于天线、射频(RF)收发器、一个或多个放大器、调谐器、一个或多个振荡器、数字信号处理器、编码器-解码器(CODEC)芯片组、订户身份模块(SIM)卡或本地缓冲电路系统。网络接口908可以被配置为经由无线通信与诸如互联网、内联网或无线网络(诸如蜂窝电话网络、无线局域网(LAN)和城域网(MAN))之类的网络通信。无线通信可以被配置为使用多种通信标准、协议和技术中的一种或多种，诸如全球移动通信系统(GSM)、增强型数据GSM环境(EDGE)、宽带码分多址(W-CDMA))，长期演进(LTE)、码分多址(CDMA)、时分多址(TDMA)、蓝牙、无线保真(Wi-Fi)(诸如IEEE 802.11a、IEEE 802.11b、IEEE 802.11g或IEEE 802.11n)、互联网协议语音(VoIP)、光保真(Li-Fi)、全球微波接入互操作性(Wi-MAX)、用于电子邮件、即时消息和短消息服务(SMS)的协议。

图10是图示根据本公开的实施例的用于多模式出行系统的会话式用户体验的方法的示例性流程图的图。图10是结合图1、图2、图3A-3B、图4A-4J、图5、图6、图7、图8A-8C和图9的元素来描述的。参考图10，示出了流程图1000。流程图1000的示例性方法可以由任何计算系统执行，例如，由图1的系统102执行。流程图1000的示例性方法可以开始于1002并且进行到1004。

在1004处，可以控制与第一用户120相关联的电子设备118以呈现第一UI 122。根据实施例，电路系统702可以被配置为控制与第一用户120相关联的电子设备118以呈现第一UI 122。

在1006处，可以通过第一UI 122从第一用户120获取可以包括自然语言输入的一个或多个消息。根据实施例，电路系统702可以被配置为通过第一UI 122获取可以包括来自第一用户120的自然语言输入的一个或多个消息。在一些实施例中，电路系统902可以被配置为获取可以包括来自消息传递组的一个或多个成员(诸如至少第二用户)的自然语言输入的一个或多个消息。

在1008处，可以获取与第一用户120相关联的用户数据。根据实施例，电路系统702可以被配置为获取与第一用户120相关联的用户数据。根据实施例，电路系统902可以被配置为获取与消息传递组的一个或多个成员(诸如至少第二用户)相关联的用户数据。

在1010处，可以使用一个或多个NLP模型104来处理获取的一个或多个消息以确定可以指示第一用户120前往第一地点的意图以及与出行相关联的时间表的背景信息。根据实施例，电路系统702可以被配置为使用一个或多个NLP模型104处理获取的一个或多个消息以确定可以指示第一用户120前往第一地点的意图以及与出行相关的时间表的背景信息。

在1012处，可以基于背景信息和用户数据来生成出行计划。根据实施例，电路系统702可以被配置为基于背景信息和用户数据生成出行计划。在一些实施例中，电路系统902可以被配置为基于生成的兴趣点的集合(例如，基于第一用户120与一个或多个成员的共识)、背景信息和用户数据生成出行计划。例如，在图7中进一步提供了基于生成的兴趣点的集合、背景信息和用户数据生成出行计划的细节。

在1014处，MaaS网络106可以被触发以生成出行计划中指定的旅行的预订细节。根据实施例，电路系统702可以被配置为触发MaaS网络106生成出行计划中指定的行程的预订细节。

在1016处，可以控制电子设备118以将生成的预订细节显示到第一UI 122或与第一UI不同122的第二UI 124上。根据实施例，电路系统702可以被配置为控制电子设备118以将生成的预订细节显示到第一UI 122或与第一UI 122不同的第二UI 124上。

虽然流程图1000被示为离散操作，诸如1004、1006、1008、1010、1012、1014和1016，但是本公开不限于此。因此，在某些实施例中，取决于特定实施方式，此类离散操作可以进一步被划分为附加操作、组合成更少操作或被消除，而不背离所公开的实施例的本质。

本公开的各种实施例可以提供一种其上存储有可由机器和/或计算机(对于系统，诸如系统102)执行的一个或多个计算机可执行指令的非暂态计算机可读介质和/或存储介质。该系统可以包括通信地耦合到与一组运输服务提供商相关联的移动即服务(MaaS)网络(诸如MaaS网络106)的电路系统(诸如电路系统702)。指令可以使机器和/或计算机执行可以包括控制与第一用户(诸如第一用户120)相关联的电子设备(诸如电子设备118)的操作，以呈现第一用户界面(诸如第一UI 122)。操作还可以包括通过第一UI 122获取可以包括来自第一用户120的自然语言输入的一个或多个消息。操作还可以包括使用一个或多个自然语言处理(NLP)模型(诸如一个或多个NLP模型104)处理获取的一个或多个消息以确定可以指示第一用户120前往第一地点的意图以及与该出行相关联的时间表的背景信息。操作还可以包括基于背景信息和用户数据生成出行计划。操作还可以包括触发MaaS网络106生成出行计划中指定的旅行的预订细节。操作还可以包括控制电子设备118以将生成的预订细节显示到第一UI 122或与第一UI不同122的第二UI(诸如第二UI 124)上。

本公开的示例性方面可以包括系统(诸如系统102)。系统102可以包括通信地耦合到与一组运输服务提供商相关联的移动即服务(MaaS)网络(诸如MaaS网络106)的电路系统(例如，电路系统702)。电路系统702可以被配置为控制与第一用户(诸如第一用户120)相关联的电子设备(诸如电子设备118)以呈现第一用户界面(诸如第一UI 122)。电路系统702还可以被配置为通过第一UI 122获取可以包括来自第一用户120的自然语言输入的一个或多个消息。电路系统702还可以被配置为使用一个或多个自然语言处理(NLP)模型(诸如一个或多个NLP模型104)处理获取的一个或多个消息以确定可以指示第一用户120前往第一地点的意图以及与出行相关联的时间表的背景信息。电路系统702还可以被配置为基于背景信息和用户数据生成出行计划。电路系统702还可以被配置为触发MaaS网络106生成出行计划中指定的旅行的预订细节。电路系统702还可以被配置为控制电子设备118以将生成的预订细节显示到第一UI 122或与第一UI不同122的第二UI(诸如第二UI 124)上。

根据实施例，第一UI 122可以是聊天UI。自然语言输入可以与第一用户120与一个或多个消息的一个或多个接收者之间的基于语音的会话、基于视频的会话或基于文本的会话中的一个对应。

根据实施例，所确定的背景信息还可以指示与一个或多个消息相关联的社交背景以及与一个或多个消息的一个或多个接收者的社交关系。

根据实施例，该方法还可以包括将获取的一个或多个消息以及确定的背景信息存储在分散式存储系统116的存储节点上。分散式存储系统116的每个节点上的存储可以特定于运输服务提供商的组中的运输服务提供商。

根据实施例，该方法还可以包括基于背景信息和用户数据来选择消息传递组，该消息传递组可以包括具有与第一用户120相同的出行兴趣的成员的组。该方法可以包括控制电子设备118以显示加入消息传递组的推荐。可以通过使用一个或多个NLP模型104进一步基于对第一用户120与消息传递组的一个或多个成员之间的会话的分析来生成出行计划。出行计划可以包括针对第一用户120和正进行到第一地点的旅行的一个或多个成员中的每一个的旅行的行程。

根据实施例，该方法还可以包括控制电子设备118以将交互式UI元素的集合覆盖到第一UI 122或第二UI 124上。交互式UI元素的集合可以与与旅行相关联的共享时间表、用于确定是否计划旅行过程中的活动的意见调查、与旅行中覆盖的一个或多个地点相关的新闻以及与一个或多个地点相关联的共同感兴趣的项目中的一个或多个对应。

根据实施例，第二UI 124可以包括地图UI元素，交互式UI元素的集合可以覆盖在该地图UI元素上。

根据实施例，该方法还可以包括经由第一UI 122接收可以与出行计划的确认对应的第一用户输入。MaaS网络接口708可以被触发以基于接收到的第一用户输入来生成预订细节。该方法还可以包括从一个或多个运输服务提供商服务器(诸如一个或多个MP服务器112)接收与可能在旅行之前和旅行过程中发生的事件相关联的跟踪信息。该方法还可以包括基于预订细节和接收到的跟踪信息来检测事件。事件可以与可以在出行计划中指定的旅行的每段的开始、旅行的每段的结束、旅行的每段可以开始和结束的地点、旅行的每段可以开始和结束的时间戳、改变旅行的至少一段的路线或运输服务提供商的请求以及路线或运输服务提供商的改变对应。该方法还可以包括通过基于被跟踪事件在MaaS网络106的分布式分类账节点上执行一个或多个事务来跟踪旅行的进度。

根据实施例，该方法还可以包括经由第一UI 122接收第二用户输入，该第二用户输入可以与针对旅行的至少一段改变或取消路线、时间表或运输服务提供商的请求对应。该方法还可以包括基于接收到的第二用户输入触发MaaS网络106以更新预订细节。MaaS网络106可以通过在MaaS网络106的分布式分类账节点上执行事务来更新预订细节。该方法还可以包括控制电子设备118以呈现可以告知更新后的预订细节的通知。

根据实施例，用户数据可以包括个人信息、用户偏好的集合、出行历史、内容偏好的集合、内容消费信息、用户在旅行中覆盖的地点的背景中生成的内容以及社交数据(包括聊天历史、过去与一个或多个消息传递组的成员的交互的集合、聊天历史中记录的每个会话的社交背景以及第一用户的社交网络120中的人的组)中的至少一个。

根据实施例，该方法还可以包括基于所确定的背景信息来生成兴趣点的初始集合。该方法还可以包括对所生成的兴趣点的初始集合应用一种或多种优化技术以确定兴趣点的中间集合。该方法还可以包括生成与兴趣点的中间集合相关联的推荐的集合。该方法还可以包括接收与生成的推荐的集合对应的第三用户输入。第三用户输入可以基于第一用户120与一个或多个消息的一个或多个接收者的共识。该方法还可以包括基于接收到的第三输入来生成兴趣点的集合。该方法还可以包括基于生成的兴趣点的集合、背景信息和用户数据来生成出行计划。

根据实施例，该方法还可以包括确定电子设备118是启用AR的，以及生成交互式AR元素的集合。交互式AR元素的集合可以基于在旅行过程中已经访问过的地点、当前地点或在旅行过程中将访问的未来地点、在旅行过程中第一用户120与一个或多个成员之间的会话、会话的背景、一个或多个广告以及共享时间表中的一个或多个来生成。该方法还可以包括控制电子设备118以将生成的AR元素的集合呈现到第一UI 122或第二UI 124上。

根据实施例，该方法还可以包括从一个或多个成员(包括消息传递组的第一用户120)接收输入的集合。输入的集合可以与以下各项中的至少一项相关联：查看或突出显示旅行的活动段所采取的路线的偏好、一个或多个成员所采取的旅行的行程、与旅行过程中的第一地点和其它地点相关联的特定于地点的信息，以及一个或多个成员要执行的一个或多个任务。该方法还可以包括生成旅行或旅行的活动段的实时地图UI。该方法还可以包括基于接收到的输入的集合生成多个可点击UI元素。该方法还可以包括控制电子设备118以呈现所生成的实时地图UI的第一视图并将多个可点击UI元素覆盖在所呈现的实时地图UI的第一视图上的对应位置处。

根据实施例，该方法还可以包括接收对被覆盖的多个可点击UI元素中的第一可点击UI元素的选择，以及基于基于接收到的选择将实时地图UI的所呈现的第一视图切换到第二视图。第二视图可以与第一视图不同。

根据一个实施例，所生成的多个可点击元素可以包括一个或多个AR元素。

根据实施例，该方法还可以包括接收对被覆盖的多个可点击UI元素中的第二可点击UI元素的选择，并且基于接收到的对第二可点击元素的选择将聊天窗口UI覆盖到实时地图UI上。聊天窗口UI可以启用第一用户120与消息传递组的成员之间的通信。

根据实施例，该方法还可以包括接收可以与与第一用户120相关联的一个或多个被预先安排任务对应的输入。该方法还可以包括生成可以与一个或多个被预先安排任务对应的一个或多个任务小部件。该方法还可以包括控制电子设备118以将生成的一个或多个任务小部件与旅行或旅行的活动段的实时地图UI一起呈现。

根据实施例，该方法还可以包括在旅行过程中控制电子设备118以将内容消费UI呈现到旅行的实时地图UI上。内容消费UI可以包括显示媒体内容的媒体播放器UI、指示包括第一用户120在内的一个或多个成员在旅行过程中已经消费或尚未消费的媒体内容的量的时间线以及示出一个或多个成员的查看器UI元素中的一个或多个。

根据实施例，该方法还可以包括通过在MaaS网络106的分布式分类账节点上执行一个或多个事务来跟踪一个或多个成员对媒体内容的消费。

根据实施例，该方法还可以包括控制电子设备118以呈现视觉计划器UI，该视觉计划器UI可以包括可以以图形方式表示要在旅行过程中被覆盖的一个或多个行程项目的第一组UI元素以及可以与配置一个或多个行程项目中的每一个的选项对应的第二组UI元素中的一个或多个。该方法还可以包括接收对第二组UI元素中的一个或多个UI元素的选择。该方法还可以包括基于接收到的选择来更新出行计划。MaaS网络106可以被触发以进一步基于更新后的出行计划生成预订细节。

本公开可以用硬件或硬件和软件的组合来实现。本公开可以以集中式方式、以至少一个计算机系统或以分布式的方式来实现，其中不同的元素可以分布在多个互连的计算机系统上。适于执行本文描述的方法的计算机系统或其它装置可能是合适的。硬件和软件的组合可以是具有计算机程序的通用计算机系统，该计算机程序在被加载和执行时可以控制计算机系统，以使其执行本文描述的方法。本公开可以用包括还执行其它功能的集成电路的一部分的硬件来实现。

本公开还可以被嵌入计算机程序产品中，该计算机程序产品包括使得能够实现本文描述的方法的所有特征，并且当其被加载到计算机系统中时，能够执行这些方法。在本文中，计算机程序是指以任何语言、代码或符号表示的指令集的任何表达，这些指令旨在使具有信息处理能力的系统直接执行特定功能，或者在以下中的一个或两者之后执行特定功能：a)转换成另一种语言、代码或符号；b)以不同的物质形式复制。

虽然参考某些实施例描述了本公开，但是本领域技术人员将理解，在不偏离本公开的范围的情况下，可以进行各种改变并且可以替换等同物。另外，在不偏离本公开的范围的情况下，可以做出许多修改以使特定情况或材料适于本公开的教导。因此，意图是本公开不限于所公开的特定实施例，而是本公开将包括落入所附权利要求的范围内的所有实施例。