本发明涉及一种根据权利要求1的前序部分中详细定义的类型的车辆中的软硬件环境中的支付系统。
背景技术：
1、原则上，支付系统在现有技术中是已知的，这些支付系统可在车辆中显示，并且可通过这些支付系统触发支付进程。
2、wo 2015/016929 a1显示了一种车辆支付系统，该支付系统可从外部接收无线支付指令并在车辆上进行处理。
3、然而，已知的支付系统仅限于先前已知的应用情况，并且是定制的。因此，必须在实施前预先确定车辆中用户界面(ui)的可视化和操作方式。这是因为在实施前必须适配相关控制器之间的通信关系，以便提供和显示适合应用情况的所有控制器的必要信息。
4、例如，支付进程可以是为电动车辆充电时的充电过程付费。此外，其他服务也可以通过支付进程进行支付。例如，过路费贴票等产品，特别是瑞士或奥地利的高速公路通行费贴票，都可以通过这种支付系统从车辆上支付。已知的支付系统的缺点是，用户界面必须预先确定要执行哪种类型的支付进程。例如，必须确定充电过程是以一定的价格购买一定量的千瓦时，以及应支付的一定总价。此外，用户界面还必须预先确定，例如，是否以一定购买价格支付具有预先规定有效期(例如，一年)的过路费贴票。每个进程都有不同的数据、不同的可视化效果和不同的选择选项。
5、因此，已知的支付系统的缺点是必须事先知道付费服务或付费应用，以便可以相应地设计用户界面。此外，还必须为现有的通信伙伴提供实施方案，以便能够使用支付进程的服务。例如，还必须遵守通信层(ncd)的长期冻结日期。
技术实现思路
1、本发明的目的在于建立一种能够克服上述缺点的车辆支付系统。
2、根据本发明，该目的通过具有权利要求1中并在此特别是权利要求1的特征部分中的特征的支付系统来实现。有利的设计方案和改进方案在从属权利要求中给出。
3、根据本发明的支付系统的核心是，通过静态的、通用的且抽象的接口，从后端经由中央通信模块与车辆中的用户界面(ui)进行预定义通信，其中，可通过静态的、通用的且抽象的接口在应用程序与用户界面之间映射任意付费服务，其中，可通过应用程序与通信模块和后端之间的动态的、与应用程序相关的接口进行支付进程，并且传输支付进程和用户交互所需的所有信息。
4、支付系统设置在车辆软硬件环境中，用于向车辆中的控制器或应用程序提供付费更新或付费服务。
5、因此，根据本发明，支付系统可集成到车辆中，使车辆有线网络中的其他控制器和应用程序能够处理自己的收费服务。这可以使用通用且预定义的接口来完成，而无需对车辆网络通信进行适配。换句话说，本发明提供了一种具有通用接口的灵活动态的车辆支付系统。在该支付系统中可以引入新的收费服务和/或应用程序，而无需对支付系统及其接口进行适配。因此，根据本发明，收费服务和/或应用程序与通用接口相联接。
6、通过根据本发明的支付系统，可以高效地配置车辆网络内的稀缺资源。例如，通过对服务域进行解耦/封装，可以大大加快服务开发速度，并显著减少工作量和成本，从而使新服务的引入或服务的变更不需要改变车辆通信(ncd)、前端单元/ui软件或支付通信线程。因此，提出的支付系统可以灵活地引入新的支付服务，而无需由于每项支付服务不同而改变接口。
7、应用程序和用户界面之间的静态的、通用且抽象的接口也可称为车辆支付通信线程。沿该通信线程的通信是预定义的，并且考虑到通信内容，优选地采用简洁高效、静态的、通用的和/或抽象的格式。尤其地，该通信线程可用于映射任意支付服务。例如，uuid(通用唯一标识码)可用于识别特定的支付进程。这种uuid也称为进程uuid，优选地由支付服务提供，并且是支付进程的要求。在另一个实施方案中，如果一项服务有多个支付选项，则可为支付进程在进程uuid结构下方设置针对不同支付选项的选项uuid。在任何情况下，当支付进程完成时，都可以通过进程uuid和/或选项uuid向支付服务发出支付进程成功激活服务的信号。更有利地，在另一个实施方案中，至少一条反馈信息可以从用户界面发送到支付服务，其中，例如，可以提供有关错误信息或暂时不存在连接(例如，在盲区)的信息。同样也可以通过错误信息指示过程中断。
8、应用程序与通信模块和后端之间动态的、与应用程序相关的接口也可称为服务域通信线程。优选地，这种通信线程或通信完全在服务开发商的域内和/或处在服务开发商的控制之下。优选地，支付进程和用户交互所需的所有信息都通过该接口传输到后端。尤其地，可以通过适当设计沿线程的界面灵活适配、补充和/或扩展传输的数据内容，以便能够随时灵活地发挥作用于未来的服务。换句话说，界面优选是动态界面，从而在不改变ncd的情况下也能传输其他的、此前未知的服务。例如，在一个实施方式中，可以使用具有非预定义内容的数据容器。在一个优选的实施方式中，可以使用进程uuid和/或在后端额外使用fin、尤其是使用选项uuid为服务的特定支付进程进行内容关联。
9、在一个实施方式中，信息可以在服务域通信线程中由服务发送到后端，也可以直接在服务后端上提供与服务匹配的信息。例如，这些信息可以是图标和/或图像。这些信息还可以包括字体、字体大小、字体颜色和/或字体属性。优选地，还说明服务和具体的支付进程，即所提供的服务。此外，还可以说明数量、单位、单位价格、总价格、货币名称、货币缩写、适当连接的文本段或图标。如果在一个实施方式中有多个选项，则可以使用选项uuid作为参考，说明各种图标、图像、服务和具体支付进程的名称、数量、单位、单位价格、总价格、货币名称、货币缩写、适当的连接文本段和/或图标。在多个选项的情况下，这些数据可以说明这些选项是否是排他性的，例如是否可以通过单选按钮进行选择，或者是否可以同时选择多个选项。此外，还可以包含有关内容格式和/或表现形式的信息。还可以包含有关agb的信息，在需要确认的情况下，信息可以可选地包括选项uuid。还可以包含需要确认的菜单项信息，例如在“订购付费项”的情况下。
10、一旦支付进程展开并且支付进程所需的所有信息都已传输，则支付进程可以在支付系统通信线程中进行。优选地，支付系统通信线程设计为通用界面，其可以在预定的固定结构中涵盖大量具有不同要求的不同服务，而无需更改任何相关组件，特别是用户界面。在一个实施方式中，这种数据结构可以使用json对象、yaml结构和/或网站描述语言，特别是html。如已描述的服务域通信线程，可以使用进程uuid并在后端、特别是额外使用fin和/或选项uuid对内容与服务的具体支付进程进行关联。可以按照关于服务域通信线程的描述进行。尤其地，这些信息也可以是相同的。
11、优选地，通过用户界面传输数据，这些数据根据预定义的数据结构和预定的方式演绎、表达和呈现，以便提供给用户。
12、根据该构想的一个非常有利的改进方案，可以设置如下，提供agb，并且在必要时获得用户的确认。例如，该确认可以被记录，并且通过相应的选项uuid经由支付系统通信线程、服务域通信线程和/或车辆支付通信线程传达给服务。
13、根据一个有利的实施方案，可以设置如下，根据与预定义的显示结构相对应的特定特征来表示付费服务。此外，购买和支付进程的确认还可以从用户处获得、记录，并且通过进程uuid经由支付系统通信线程、服务域通信线程和/或车辆支付通信线程传达给服务。在另一个实施方式中，这只能在支付进程成功完成后才进行。
14、在另一个有利的实施方案中，设置如下，获得客户对购买或支付进程的确认，其中，可通过单选按钮获得该确认或该确认可以选择列表的形式显示。这取决于服务选项的要求。然后，该确认可以被记录，并且通过选项uuid经由支付系统通信线程、服务域通信线程和/或车辆支付通信线程传达给服务。在另一个实施方式中，这只能在支付进程成功完成后才进行。
15、在一个有利的实施方式中，支付进程可以在购买完成后通过支付系统启动。
16、在另一个有利的实施方式中，已购买的收费服务可以在支付进程启动后被激活。在另一个实施方式中，如果在车辆支付通信线程上发出支付进程请求信号之后的一定时间内，后端没有提供任何信息，或者如果没有连接，用户界面可以以协调的方式对此作出反应，例如显示信息或显示“请耐心等待”的提示。
1.一种车辆(8)中的软硬件环境中的支付系统(1)，
2.根据权利要求1所述的支付系统(1)，
3.根据权利要求1或2所述的支付系统(1)，
4.根据权利要求1至3中任一项所述的支付系统(1)，
5.根据权利要求1至4中任一项所述的支付系统(1)，
6.根据权利要求1至5中任一项所述的支付系统(1)，其特征在于，
7.根据权利要求6所述的支付系统(1)，其特征在于，
