CN113765947A - 用于聚合汽车车内服务的方法和系统 - Google Patents

Abstract

本发明提供了一种用于聚合汽车车内服务的方法和系统，其中系统包括：安装在汽车上的聚合服务客户端，以及与聚合服务客户端和多个服务提供商通信地耦合的聚合器。其中聚合器被配置成：接收来自服务提供商的查询请求，用于请求聚合器确定所述服务提供商待服务的用户是否支持聚合服务；确定用户是否支持聚合服务并将查询结果返回给服务提供商；接收来自服务提供商的服务请求；通知聚合服务客户端，以获得用户对于服务的授权；基于聚合服务客户端返回的消息确定用户是否授权服务；响应于用户授权服务，执行服务权限更新操作并通知服务提供商授权完成，否则通知服务提供商授权未完成。

Description

用于聚合汽车车内服务的方法和系统

技术领域

本发明涉及汽车领域，更具体地，涉及用于聚合汽车车内服务的方法和系统。

背景技术

近年来，对车内服务的需求不断增长，日常生活中的移动支付也越来越流行，尤其是在中国。对于驾驶员来说，存在很多方法来支付各种车辆服务，诸如加油/充电/停车/通行费等。例如，驾驶员可以扫描QR码/二维码或使用信用卡来进行付款以及进行身份验证/识别，例如进入专属停车场(例如，经由员工ID卡或车库门开门器)。如今，许多支付服务已经能够通过车辆自身来提供，例如基于汽车牌照识别的自动支付系统，可以实现无感知付款。

然而，由于存在有各种各样不同的服务提供商来提供各种服务，因此驾驶员不得不面对以下挑战：

1、在许多驾驶场景(例如加油/充电/停车/通行费)中，移动支付并不是无缝的，驾驶员仍然需要使用手机来扫描车机或车机外的QR码，甚至有时需要下车去扫码，而将来的完全自动驾驶(FAD)车辆甚至没有驾驶员来进行这类支付操作；以及

2、为了应对各种场景下的各种支付服务，驾驶员不得不使用大量不同的卡或大量不同的应用程序(APP)来注册每一个提供商已使用其服务，并且需要注册多个账号、密码等，而其中某些服务仅仅是在某些城市/国家的某些特定地点才可用。

因此，希望能够提供一种新的解决方案来实现更简便的车内服务支付。

发明内容

提供本发明内容以便以简化形式介绍将在以下具体实施方式中进一步的描述一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

针对以上问题，根据本发明的一个方面，提供了一种提供聚合汽车车内服务的方法，其中所述方法包括：

接收来自服务提供商的查询请求，所述查询请求用于请求聚合器确定所述服务提供商待服务的用户是否支持聚合服务，其中所述服务提供商所提供的服务是所述聚合服务中集成的多个服务中的一个；

确定所述用户是否支持聚合服务并将查询结果返回给所述服务提供商；

接收来自所述服务提供商的服务请求；

通知安装在汽车上的客户端应用程序，以获得用户对于服务的授权；

基于所述客户端应用程序返回的消息确定用户是否授权服务；

响应于用户授权服务，执行服务权限更新操作并通知所述服务提供商授权完成；以及

响应于用户未授权服务，通知所述服务提供商授权未完成。

根据本发明的一个实施例，所述方法还包括：

在通知安装在汽车上的客户端应用程序之前，检查用户预留的自动服务选项，并确定所述服务是否在用户自动服务的授权范围内；并且

响应于所述服务在用户自动服务的授权范围内，执行服务权限更新操作并通知所述服务提供商授权完成。

根据本发明的另一实施例，所述服务请求是针对所述服务提供商所提供的服务的支付授权请求。

根据本发明的另一实施例，所述方法还包括：

将服务涉及的支付金额从用户的账户以所述服务提供商所所支持的支付渠道划转给所述服务提供商的账户。

根据本发明的另一方面，提供了一种提供聚合汽车车内服务的方法，其中所述方法包括：

接收来自聚合器的包含服务信息的消息，其中所述服务是汽车的聚合服务客户端应用程序中集成的多个服务中的一个；

基于用户预留的自动服务选项确定本次服务是否在授权范围内；

响应于本次服务在授权范围内，向所述聚合器返回授权服务消息；以及

响应于本次服务不在授权范围内，请求用户授权该服务，并将用户的选择结果发送给所述聚合器。

根据本发明的一个实施例，所述自动服务选项包括以下中的一项或多项：

用户是否启用自动授权服务；

用户自动授权服务的服务提供商类型；

用户自动授权服务的服务提供商标识；以及

用户自动授权服务的支付限额。

根据本发明的另一方面，提供了一种提供聚合汽车车内服务的系统，其中所述系统包括：

安装在汽车上的聚合服务客户端，所述聚合服务客户端被配置成利用汽车车载交互设备与用户交互，以向用户通知聚合服务信息并获取用户对于聚合服务的授权；以及

与所述聚合服务客户端和多个服务提供商通信地耦合的聚合器，其中所述聚合器被配置成：

接收来自服务提供商的查询请求，所述查询请求用于请求聚合器确定所述服务提供商待服务的用户是否支持聚合服务，其中所述服务提供商所提供的服务是所述聚合服务中集成的多个服务中的一个；

确定所述用户是否支持聚合服务并将查询结果返回给所述服务提供商；

接收来自所述服务提供商的服务请求；

通知所述聚合服务客户端，以获得用户对于服务的授权；

基于所述聚合服务客户端返回的消息确定用户是否授权服务；

响应于用户授权服务，执行服务权限更新操作并通知所述服务提供商授权完成；以及

响应于用户未授权服务，通知所述服务提供商授权未完成。

根据本发明的另一实施例，所述聚合器具有用于接入所述服务提供商的标准化接口，使得所述服务提供商可基于所述标准化接口的标准化格式对其提供的服务的信息进行抽象和对接，并且接入后的服务提供商使用所述标准化格式向所述聚合器发送所述服务请求。

根据本发明的另一实施例，所述聚合器还被配置成：维护支持所述聚合服务的用户列表。

根据本发明的进一步实施例，所述用户列表中至少包括用户的身份信息和与所述用户绑定的车牌号。

根据本发明的进一步实施例，所述用户列表中还包括用户提供的用于支付服务的支付账户信息。

根据本发明的进一步实施例，所述聚合器还被配置成：维护针对至少一个服务提供商的授权用户列表。

根据本发明的又一方面，提供了一种汽车，其中所述汽车包括：

汽车车载交互设备；

通信设备，用于与聚合器通信；以及

聚合服务客户端，所述聚合服务客户端被配置成：

利用汽车车载交互设备与用户交互，以向用户通知聚合服务信息并获取用户对于服务的授权，所述服务是所述聚合服务客户端中集成的多个服务中的一个；以及

经由所述通信设备将用户授权结果发送给所述聚合器。

根据本发明的进一步实施例，所述汽车还包括定位设备，并且所述聚合服务客户端还被配置成：

基于所述定位设备确定的汽车的当前位置，当检测到汽车驶入或接近支持聚合服务的服务提供商场所时，发起所述聚合服务，以在服务开始之前完成完成对该服务的授权。

根据本发明的进一步实施例，所述汽车还包括路径规划导航模块，并且所述聚合服务客户端还被配置成：

基于用户在所述路径规划导航模块中输入的导航目的地信息，当检测到导航目的地是支持聚合服务的服务提供商时，发起所述聚合服务，以在服务开始之前完成完成对该服务的授权。

针对现有技术中存在的问题，本发明提供了用于聚合汽车车内服务的通用解决方案，该解决方案基本上可以为所有类型的服务进行支付，并至少具有以下优点：

1、简化了车辆驾驶员的使用过程，避免了繁琐的注册，也方便了帐户管理；

2、整车厂可以使用一个帐户来方便地获取驾驶员数据，这增加了便利性和客户忠诚度；以及

3、实现了车辆支付功能，为生态系统中的未来用例奠定了基础。

通过阅读下面的详细描述并参考相关联的附图，这些及其他特点和优点将变得显而易见。应该理解，前面的概括说明和下面的详细描述只是说明性的，不会对所要求保护的各方面形成限制。

附图说明

为了能详细地理解本发明的上述特征所用的方式，可以参照各实施例来对以上简要概述的内容进行更具体的描述，其中一些方面在附图中示出。然而应该注意，附图仅示出了本发明的某些典型方面，故不应被认为限定其范围，因为该描述可以允许有其它等同有效的方面。

图1是根据本发明的一个实施例的描绘车内服务聚合系统的架构示意图。

图2是根据本发明的一个实施例的聚合支付过程的示意流程图。

图3是根据本发明的另一实施例的聚合支付过程的示意流程图。

图4是根据本发明的另一实施例的由聚合器实现的聚合支付方法的示意流程图。

图5是根据本发明的另一实施例的由汽车实现的聚合支付方法的示意流程图。

图6是根据本发明的另一实施例的聚合支付方法的示意流程图。

图7是根据本发明的一个实施例的汽车的结构示意图。

具体实施方式

下面结合附图详细描述本发明，本发明的特点将在以下的具体描述中得到进一步的显现。

图1是根据本发明的一个实施例的描绘车内服务聚合系统的架构示意图。如图1所示，本发明提供了一种通用的连接器来实现对于各种不同提供商的灵活的整合，该连接器不需要为每一项服务而连接完全不同的方案，而仅仅需要访问经过标准化的第三方后端，无需更改整个逻辑体系结构。另一方面，在用户一侧，用户只需要通过一个帐户登录而无需重复注册。由此，本发明的聚合系统(或称之为超级聚合器)可以将不同的服务集成到统一的云系统中，在统一支付帐户后，所有服务都可以由超级聚合器支付。此外，可以理解的是，虽然本文中许多场景的描绘涉及支付或以支付为例，但本发明的聚合服务系统并不只适用于解决聚合支付问题，例如门禁系统的抬杆可以不涉及支付而只涉及权限的审核，当用户具有访问的权限时，服务就可以被提供(即抬杆)。支付只是基于授权提供服务的诸多实现中的一个示例，例如当用户完成了支付，则相当于用户具有了享受服务的权限，相应的服务就可以被提供。

更具体的，在该集成解决方案中，可以主要由下部分组成：

1、作为车内服务聚合系统的前端的客户端应用程序。作为本发明的一个实施例，可将汽车车内的车机作为前端。目前，汽车普遍配备车机系统供与用户进行人机交互，因而本发明的聚合系统可使用车机作为前端。更具体的，该前端可以作为车机系统中的一个应用程序(APP)来运行。以此方式，本发明的聚合服务可以利用车载交互系统，例如车内的各种视觉(如中控显示屏)、音频(如车内音箱)以及触摸、语音输入方式与用户进行交互。在该前端应用中可提供各种集成服务并关联支付系统。用户可以使用车辆ID进行注册，并且可以绑定用于支付的付款账户。此外，该APP中还提供了自动付款的开关选项，如果用户打开自动付款，就可以在这些服务中享受无感知支付。

2、作为车内服务聚合系统的云后端的聚合器。聚合器可被用于连接所有可以与车辆和第三方通信的车辆服务提供商，同时也与前端的客户端应用程序通信以实现服务提供和支付过程中的交互。该聚合器可由整车厂自己维护或委托给外部的供应商来维护。

3、作为生态系统后端的标准化接口。该标准化接口可以抽象出汽车服务提供商的接口，从而简化了集成过程。作为一个示例，标准化接口可提供诸如包含以下内容的接口：<服务时间>，<服务地点>，<服务类型>，<支付金额>，<支付渠道>，……。由此，汽车服务提供商只需要将其服务内容按此方式进行抽象，上报给聚合器，聚合器就可以通过标准化接口接入该服务，并通过例如软件更新的形式推送给客户端应用程序。由此，聚合器可以提供各种服务，并且可以轻松添加新服务和新提供商。当服务行为发生时，服务提供商可按照标准消息形式发送服务及支付信息给聚合器，聚合器进而与前端的客户端应用程序进行交互以完成支付。

作为一个非限制性的使用场景，如图1中所示，有许多提供汽车服务的服务提供商，包括但不限于：加油站/充电站、停车场、道路通行收费站、洗车店等等。每一个提供商可能支持一种或多种第三方支付方式，例如微信支付、支付宝、Apple Pay等等。原先，汽车的用户(例如驾驶员)为了使用这些服务，不得不在其移动设备上安装和注册每一个提供商的应用程序，以及所涉及的每一个第三方的应用程序。以图2中给出的示例而言，如果一个用户需要使用所有这四种服务，可能需要安装和注册多达七个应用程序，即使其中有些提供商可能不强制要求用户必须安装其应用程序，但为了使用第三方支付，也至少需要安装三个第三方支付的应用程序并注册以进行支付。作为对比，通过本发明，用户只需安装和注册汽车制造商提供的客户端应用程序。由于该应用程序的维护方已在该应用程序中集成了上述服务，用户在需要支付时只需要通过这一个应用程序即可完成支付。此外，用户在注册该应用程序时还可以进一步绑定车辆ID和付款帐户(例如一个用于支付的银行账户或任意一个第三方支付账户)，并授权自动支付(或有条件自动支付，例如小额自动支付)。在这种情况下，用户可进一步以无感知支付的方式来享受所有服务。以此方式，完全自动驾驶(FAD)车辆也将能够通过使用到各种移动平台或生态系统的通用连接来独立使用服务付款和自动识别本身，而无需客户交互。

图2是根据本发明的一个实施例的提供聚合汽车车内服务200的示意流程图。

过程200开始于步骤202，服务提供商(以下简称“商户”)检测车辆是否支持聚合服务。检测可在提供服务前(例如车辆刚驶入该商户的服务场所)或提供服务后进行。作为一个示例，检测可通过车牌识别装置读取车辆的车牌号，并向云端的聚合器查询来确定。替代地，商户本地也可以存储有部分支持聚合服务的车辆信息，例如之前已经通过聚合服务进行过服务的车辆，因而查询可以首先在本地的支持聚合服务的车辆数据库中离线地进行，如果本地未查询到，则再进一步进行在线查询。

如果查询的结果是车辆支持聚合服务，则在步骤204，商户发送包含服务信息的消息给聚合器。如之前提到的，聚合器与商户之间已通过标准化接口进行了接入。当需要就服务进行授权时，商户可按照标准化格式将消息发送给聚合器。作为一个示例，消息可包含<商户ID>，<服务对象ID>(例如，车牌号或与车牌号绑定的聚合服务用户ID)，<服务时间>，<服务地点>，<服务类型>(或服务明细)，<支付金额>，<支付渠道>(可以是商户首选或所有支持的支付渠道，包括银行账户或各种第三方支付渠道)。如果查询的结果是车辆不支持聚合服务，则过程结束，商户可按照其他传统方式向用户提供服务。

在步骤206，响应于接收到来自商户的消息，聚合器通知客户端应用程序。例如，聚合器可发送包含类似支付信息的消息给客户端应用程序。

在步骤208，响应于接收到来自聚合器的消息，客户端应用程序可请求用户授权该服务。例如，客户端应用程序可在中控显示屏幕上显示相关的信息，包括当前商户可使用聚合服务来支付，以及相关的支付信息，例如待支付金额，用户可通过触摸屏幕的方式选择授权或不授权该支付。替代地或附加地，客户端应用程序也可经由车内的音响系统以语音的方式通知用户，并允许用户以语音输入的方式来选择授权或不授权该支付。

在步骤210，客户端应用程序将用户的选择结果发送给聚合器。选择结果既包括授权，也可包括不授权。可以理解，如果在一定时间内未接收到用户作出的选择，则可以视为不授权来处理。

在步骤212，聚合器确定用户是否授权服务。

若用户授权服务，则在步骤214，聚合器执行服务权限更新操作。作为一个示例，服务权限更新操作可以是完成支付。例如，聚合器可将该服务涉及的支付金额从用户的账户划转给商户的账户。若用户与聚合服务绑定的支付渠道是商户所支持的支付渠道，则划转可直接进行。若用户绑定的支付渠道是商户不支持的支付渠道，则聚合器可提供中间账户进行划转。作为另一个示例，服务权限更新操作可以是聚合器将用户放入授权服务用户列表中。

随后，在步骤216，聚合器通知商户授权完成。例如，聚合器通知商户用户已完成支付，或者通知商户，该用户是授权用户。随后，流程结束。

若用户未授权服务，则在步骤218，聚合器通知商户用户授权未完成，流程结束。商户可按照其他传统方式向用户提供服务。

图3是根据本发明的另一实施例的提供聚合汽车车内服务300的示意流程图。图3与图2的许多步骤是类似的，主要区别在于图3的过程300在图2的基础上进一步加入了无感知服务特征。

过程300开始于步骤302，商户检测车辆是否支持聚合服务。如果查询的结果是车辆支持聚合服务，则在步骤304，商户发送包含服务信息的消息给聚合器。否则，过程结束。

与过程200不同，在步骤306，响应于接收到来自商户的消息，聚合器检查用户预留的自动服务选项，并确定本次服务是否在用户自动服务的授权范围内。以自动支付为例，自动服务选项可包括但不限于用户是否启用了自动支付、授权自动支付的限额、授权自动支付的商户类型、授权自动支付的商户ID等等。

在步骤308，响应于确定本次服务在用户自动服务的授权范围内，则聚合器执行服务权限更新操作，并在步骤310，通知商户授权完成。

若本次支付不在用户自动服务的授权范围内，则在步骤312，聚合器通知客户端应用程序。例如，聚合器可发送包含服务信息的消息给客户端应用程序。后续步骤与过程200类似。

在步骤314，响应于接收到来自聚合器的消息，客户端应用程序可请求用户授权该服务。在步骤316，客户端应用程序将用户的选择结果发送给聚合器。在步骤318，聚合器确定用户是否授权服务。若用户授权服务，则过程前进至步骤308和310，聚合器执行服务权限更新操作并通知商户授权完成。

若用户未授权服务，则在步骤320，聚合器通知商户用户授权未完成，流程结束。

作为图2和图3中的步骤202和步骤302的替代，用户(例如车辆的驾驶员)可告诉商户使用聚合服务，这种情形可能发生在一些不具备扫描车牌能力的商户。随后，商户可手动输入车牌号，随后执行图2或图3的后续流程。

图4是根据本发明的另一实施例的由聚合器实现的提供聚合汽车车内服务的方法400的示意流程图。在步骤402，聚合器接收来自商户的查询请求，该查询请求用于请求聚合器确定商户待服务的用户(例如，基于与该用户绑定的汽车的车牌号)是否支持聚合服务。

在步骤404，聚合器确定用户是否支持聚合服务并将查询结果返回给商户。

在步骤406，聚合器接收到来自商户的服务请求。服务请求可包含如之前描述的标准化格式的服务信息。

在步骤408，聚合器检查用户预留的自动服务选项，并确定本次服务是否在用户自动服务的授权范围内。

在步骤410，响应于确定本次服务在用户自动服务的授权范围内，则聚合器执行服务权限更新操作，并在步骤412，通知商户授权完成。

若本次服务不在用户自动服务的授权范围内，则在步骤414，聚合器通知客户端应用程序。

在步骤416，聚合器基于客户端应用程序返回的消息确定用户是否授权服务。若用户授权服务，则过程前进至步骤410和步骤412，聚合器执行服务权限更新操作并通知商户授权完成。

若用户未授权服务，则在步骤418，聚合器通知商户用户未授权服务，流程结束。

如之前提到的，聚合器所执行的与自动服务有关的步骤(例如步骤408)是可选的。作为另一实施例，如以下将结合图5描述的，与自动服务有关的步骤可在客户端应用程序处执行。

图5是根据本发明的另一实施例的由汽车实现的提供聚合汽车车内服务的方法500的示意流程图。在步骤502，汽车(更具体的，可以是汽车的车载系统(即车机)上安装的作为聚合服务前端的客户端应用程序)接收来自聚合器的包含服务信息的消息。

在步骤504，基于用户预留的自动服务选项确定本次服务是否在授权范围内。

如果是，则在步骤506，向聚合器返回授权服务消息。

如果否，则在步骤508，请求用户授权该服务。随后在步骤510，将用户的选择结果发送给聚合器。

图6是根据本发明的另一实施例的提供聚合汽车车内服务的方法600的示意流程图。在步骤602，作为聚合服务前端的客户端应用程序检测到汽车驶入或接近支持聚合服务的服务提供商场所。例如，这样这一检测可以基于汽车的定位设备(例如GPS)所确定的汽车位置与客户端应用程序中所支持的商户的位置列表的比较来确定，或者可以基于类似于车载ETC之类的近距离感测硬件来确定。此外，还可以结合车机上集成的导航服务来确定，比如用户输入的导航目的地是支持聚合服务的商户。

在步骤604，询问用户是否使用聚合服务。可以理解，若存在默认用户选项，则该步骤也可自动执行，从而实现无感知服务。

如果用户选择使用聚合服务，则在步骤606，客户端应用程序可发送消息给聚合器，指示用户支持并希望使用聚合服务。聚合器可随后将该信息通知给商户，商户可在适当时候返回服务信息。例如商户可以如常规的在服务实际完成后再生成支付信息，替代地，商户可以预先生成支付信息，从而在实际服务开始之前就完成支付，使得服务过程可实现完全的零感知体验。这种情景对于诸如过路通行场景较为适用，比如汽车将要驶过收费桥梁、轮渡或其他收费路段，支付服务可在汽车驶入道闸之前完成，而在汽车实际驶入道闸时自动抬杆。与支付以及是否自动支付的流程与之前的流程中所描述的类似。

此外，本发明的聚合服务也可以被应用于许多不涉及支付但涉及使用权限的专用服务场所。例如，在一些只允许授权车辆驶入的专用停车场，在接入本发明的聚合服务后，可通过查询聚合器来确定车辆是否在授权列表中，该授权列表可以与支持聚合服务的用户列表相同，也可以是单独维护的列表。

图7是根据本发明的一个实施例的汽车700的结构示意图。如图7中所示，汽车700可至少包括汽车车载交互设备702、通信设备704、以及聚合服务客户端706。汽车车载交互设备702可以是车内的中控显示屏、音响系统、麦克风等任何合适的用于与用户进行人机交互的设备。通信设备704可用于与云端的聚合器进行通信，此外也可用于汽车上的其他软硬件模块与互联网、其他车辆、用户的移动设备等进行通信。聚合服务客户端706可以被实现为车载系统(即车机)上安装的应用程序之一，并被配置成执行如图1-6中提及的聚合服务中的相关操作。例如，聚合服务客户端706可被配置成利用汽车车载交互设备702与用户交互，以向用户通知聚合服务信息并获取用户对于服务的授权，所述服务是所述聚合服务客户端中集成的多个服务中的一个，以及经由通信设备704将用户授权结果发送给所述聚合器。在一个可选示例中，汽车700还可包括定位设备708，从而可以基于定位设备708确定的汽车的当前位置，当检测到汽车700驶入或接近支持聚合服务的服务提供商场所时，发起所述聚合服务，以在服务开始之前完成对该服务的授权。在另一可选示例中，汽车700还包括路径规划导航模块710，从而可以基于用户在所述路径规划导航模块710中输入的导航目的地信息，当检测到导航目的地是支持聚合服务的服务提供商时，发起所述聚合服务，以在服务开始之前完成对该服务的授权。

以上所已经描述的内容包括所要求保护主题的各方面的示例。当然，出于描绘所要求保护主题的目的而描述每一个可以想到的组件或方法的组合是不可能的，但本领域内的普通技术人员应该认识到，所要求保护主题的许多进一步的组合和排列都是可能的。从而，所公开的主题旨在涵盖落入所附权利要求书的精神和范围内的所有这样的变更、修改和变化。

Claims (15)

1.一种提供聚合汽车车内服务的方法，其特征在于，所述方法包括：

接收来自服务提供商的查询请求，所述查询请求用于请求聚合器确定所述服务提供商待服务的用户是否支持聚合服务，其中所述服务提供商所提供的服务是所述聚合服务中集成的多个服务中的一个；

确定所述用户是否支持聚合服务并将查询结果返回给所述服务提供商；

接收来自所述服务提供商的服务请求；

通知安装在汽车上的客户端应用程序，以获得用户对于服务的授权；

基于所述客户端应用程序返回的消息确定用户是否授权服务；

响应于用户授权服务，执行服务权限更新操作并通知所述服务提供商授权完成；以及

响应于用户未授权服务，通知所述服务提供商授权未完成。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

在通知安装在汽车上的客户端应用程序之前，检查用户预留的自动服务选项，并确定所述服务是否在用户自动服务的授权范围内；并且

响应于所述服务在用户自动服务的授权范围内，执行服务权限更新操作并通知所述服务提供商授权完成。

3.如权利要求1所述的方法，其特征在于，所述服务请求是针对所述服务提供商所提供的服务的支付授权请求。

4.如权利要求1所述的方法，其特征在于，所述方法还包括：

将服务涉及的支付金额从用户的账户以所述服务提供商所所支持的支付渠道划转给所述服务提供商的账户。

5.一种提供聚合汽车车内服务的方法，其特征在于，所述方法包括：

接收来自聚合器的包含服务信息的消息，其中所述服务是汽车的聚合服务客户端应用程序中集成的多个服务中的一个；

基于用户预留的自动服务选项确定本次服务是否在授权范围内；

响应于本次服务在授权范围内，向所述聚合器返回授权服务消息；以及

响应于本次服务不在授权范围内，请求用户授权该服务，并将用户的选择结果发送给所述聚合器。

6.如权利要求5所述的方法，其特征在于，所述自动服务选项包括以下中的一项或多项：

用户是否启用自动授权服务；

用户自动授权服务的服务提供商类型；

用户自动授权服务的服务提供商标识；以及

用户自动授权服务的支付限额。

7.一种提供聚合汽车车内服务的系统，其特征在于，所述系统包括：

安装在汽车上的聚合服务客户端，所述聚合服务客户端被配置成利用汽车车载交互设备与用户交互，以向用户通知聚合服务信息并获取用户对于聚合服务的授权；以及

与所述聚合服务客户端和多个服务提供商通信地耦合的聚合器，其中所述聚合器被配置成：

接收来自服务提供商的查询请求，所述查询请求用于请求聚合器确定所述服务提供商待服务的用户是否支持聚合服务，其中所述服务提供商所提供的服务是所述聚合服务中集成的多个服务中的一个；

确定所述用户是否支持聚合服务并将查询结果返回给所述服务提供商；

接收来自所述服务提供商的服务请求；

通知所述聚合服务客户端，以获得用户对于服务的授权；

基于所述聚合服务客户端返回的消息确定用户是否授权服务；

响应于用户授权服务，执行服务权限更新操作并通知所述服务提供商授权完成；以及

响应于用户未授权服务，通知所述服务提供商授权未完成。

8.如权利要求7所述的系统，其特征在于，所述聚合器具有用于接入所述服务提供商的标准化接口，使得所述服务提供商可基于所述标准化接口的标准化格式对其提供的服务的信息进行抽象和对接，并且接入后的服务提供商使用所述标准化格式向所述聚合器发送所述服务请求。

9.如权利要求7所述的系统，其特征在于，所述聚合器还被配置成：维护支持所述聚合服务的用户列表。

10.如权利要求8所述的系统，其特征在于，所述用户列表中至少包括用户的身份信息和与所述用户绑定的车牌号。

11.如权利要求9所述的系统，其特征在于，所述用户列表中还包括用户提供的用于支付服务的支付账户信息。

12.如权利要求7所述的系统，其特征在于，所述聚合器还被配置成：维护针对至少一个服务提供商的授权用户列表。

13.一种汽车，其特征在于，包括：

汽车车载交互设备；

通信设备，用于与聚合器通信；以及

聚合服务客户端，所述聚合服务客户端被配置成：

利用汽车车载交互设备与用户交互，以向用户通知聚合服务信息并获取用户对于服务的授权，所述服务是所述聚合服务客户端中集成的多个服务中的一个；以及

经由所述通信设备将用户授权结果发送给所述聚合器。

14.如权利要求13所述的汽车，其特征在于，所述汽车还包括定位设备，并且所述聚合服务客户端还被配置成：

基于所述定位设备确定的汽车的当前位置，当检测到汽车驶入或接近支持聚合服务的服务提供商场所时，发起所述聚合服务，以在服务开始之前完成完成对该服务的授权。

15.如权利要求14所述的汽车，其特征在于，所述汽车还包括路径规划导航模块，并且所述聚合服务客户端还被配置成：

基于用户在所述路径规划导航模块中输入的导航目的地信息，当检测到导航目的地是支持聚合服务的服务提供商时，发起所述聚合服务，以在服务开始之前完成完成对该服务的授权。

Images