DE102021005678A1 - Payment system in a hardware and software environment in a vehicle - Google Patents

Abstract

The invention relates to a payment system (1) in a hardware and software environment in a vehicle (8) for providing a control device or an application in the vehicle (8) with a paid update or a paid service. The invention is characterized in that communication takes place in a predefined manner via a static, universal and abstracted interface (5a) from a backend (7) via a central communication module (6) to a user interface (4) in the vehicle (8), wherein Any number of payment services can be mapped via a static, universal and abstract interface (2) between the application (3) and the user interface (4), with a dynamic, application-dependent interface (5b) between the application (3) and the communication module ( 6) and the backend (7) a payment process can be processed and all information necessary for the payment process and a user interaction can be transmitted.

Description

The invention relates to a payment system in a hardware and software environment in a vehicle according to the type defined in more detail in the preamble of claim 1.

In principle, payment systems that are displayed in a vehicle and via which payment transactions can be triggered are known from the prior art.

This is how it shows WO 2015/016929 A1 a vehicle payment system that makes it possible to receive a wireless payment order from the outside and process it from the vehicle.

However, known payment systems are limited to exactly one previously known application and are tailor-made. Visualization and operation using a user interface (UI) in the vehicle must therefore be specified in advance of implementation. The reason for this is that the communication relationships between the control units involved have to be adjusted prior to implementation in order to make the necessary information of all the control units involved available and displayed appropriately for the application.

The payment process can be, for example, payment for a charging process when an electric vehicle is being charged. Furthermore, other services can also be paid for with the payment process. For example, products such as stickers for toll fees, in particular a vignette for Switzerland or Austria, can be paid for from the vehicle using such payment systems. The disadvantage of known payment systems is that the user interface has to specify beforehand which type of payment process is to be carried out. For example, it must be specified that it is a charging process with a certain number of kilowatt hours at a certain purchase price, which is to be spent in a certain total value. Furthermore, the user interface must determine beforehand whether, for example, a sticker for tolls with a predetermined validity of, for example, one year, is to be paid for at a specific purchase price. Different data, different visualizations and different selection options are available for each process.

It is therefore disadvantageous that, with known payment systems, the chargeable service or the chargeable application must be known in advance, so that the user interface can be designed accordingly. There must also be an implementation for the present communication partner in order to be able to use the services of the payment process. Here, for example, long-term freeze dates of the communication layers (NCD) must also be observed.

The object of the present invention is to create a payment system for a vehicle that overcomes the aforementioned disadvantages.

According to the invention, this object is achieved by a payment system having the features in claim 1 and here in particular in the characterizing part of claim 1. Advantageous refinements and developments result from the dependent subclaims.

At the core of the payment system according to the invention, communication takes place via a static, universal and abstract interface from a backend via a central communication module to a predefined user interface (UI) in the vehicle, with a static, universal and abstract interface between the application and the user Interface any payment services can be mapped, and with a dynamic, application-dependent interface between the application and the communication module and the backend, a payment process and all the information necessary for the payment process and a user interaction can be transmitted.

The payment system is provided in a hardware and software environment in a vehicle in order to provide a control device or an application in the vehicle with a paid update or a paid service.

Consequently, according to the invention, a payment system can be integrated in a vehicle that allows other control devices and applications in the wired vehicle network to handle their own chargeable services. This can be done using generic and predefined interfaces without any adaptation in the vehicle-network communication. In other words, according to the invention, an agile and dynamic payment system is provided in a vehicle that has generic interfaces. An introduction of new paid services and/or applications is possible without having to adapt the payment system and its interfaces. According to the invention, therefore, the chargeable services and/or applications are linked to generally valid interfaces.

With the payment system according to the invention, an efficient design of the scarce res sources can be achieved within a vehicle network. For example, service development is significantly accelerated and the effort and costs are reduced significantly by decoupling/encapsulating the service domain, so that a new service introduction or service change does not result in a change in the vehicle communication (NCD), in the head unit / UL software or in the payment communication line. The proposed payment system can therefore flexibly introduce new payment services without having to change the interfaces with each payment service.

The static, universal and abstracted interface between the application and the user interface can also be referred to as the vehicle payment communication line. Communication along this communication thread is predefined and preferably follows a format that is concise and efficient, static, universal and/or abstracted with regard to the communication content. In particular, the communication line is designed to map any payment services. For example, a UUID (universally unique identifier) can be used to identify a specific payment transaction. Such a UUID, also called transaction UUID, is preferably provided by the payment service and requested by the payment transaction. In a further embodiment, option UUIDs for different payment options can be provided structurally below the transaction UUID for the payment transaction if there are several payment options for a service. In all cases, a successful payment process for service activation can be signaled to the payment service by means of the process UUID and/or the option UUID when a payment process is completed. Advantageously, in a further embodiment, at least one acknowledgment can be sent from the user interface to the payment service, it being possible, for example, for information regarding error messages or temporarily non-existent connections, for example in a radio dead zone, to be given. Likewise, an abort of the process can be indicated via an error message.

The dynamic, application-dependent interface between the application and the communication module and the backend can also be referred to as a service-domain communication line. This line of communication or this communication is preferably completely in the domain and/or under the control of the service developer. All information required for the payment process and user interaction is preferably transmitted to the backend via this interface. In particular, by suitably designing the interfaces along the strand, the transmitted data content can be flexibly adapted, supplemented and/or expanded in order to be able to act flexibly at any time for future services. In other words, this is preferably a dynamic interface, so that other previously unknown services can also be transmitted without changing the NCD. For example, in one embodiment, a data container with non-predefined content may be used. In a preferred embodiment, content can be assigned to a specific payment process for a service using the process UUID and/or in the backend using the FIN, in particular using option UUIDs.

In one embodiment, information from the service can be sent to the backend in the service domain communication thread or can be provided directly on the service backend side to match the service. The information can be icons and/or images, for example. A font, font size, font color and/or a font attribute can also be included. Preference is also given to the service and the specific payment process, i. H. the performance provided. Furthermore, quantities, units, costs per unit, total costs, currency designations, currency abbreviations, suitable connecting text segments or icons can be specified. In one embodiment, where multiple options are available, using option UUIDs as a reference, various icons, images, a name of the service and the specific payment process, quantities, units, unit cost, total cost, currency names, currency abbreviations, appropriate connecting text segments, and /or icons are specified. In the case of multiple options, the data can provide information as to whether these options are exclusive, for example selectable by a radio button, or whether multiple options should be selectable at the same time. Information on the formatting and/or presentation of the content may also be included. It can also be information from the general terms and conditions, which can optionally have an option UUID if confirmation is required. It can also contain information from menu items that require confirmation, for example in the case of an “order subject to a fee”.

If a payment process has been processed and all information required for the payment process has been transmitted, this can take place in a payment system communication line. This is preferably designed as a generic interface in such a way that a large number of different services with different requirements can be covered in a predetermined fixed structure without any of the components involved, in particular the user interface, having to make any changes. In one embodiment, a JSON object, a YAML structure and/or a website description language, in particular HTML, can be used for such a data structure. Content can be assigned to a specific payment process for a service, as with the service domain communication line, using the process UUID and in the backend, in particular additionally using the FIN and/or the option UUID. The procedure can be as already described with regard to the service domain communication line. In particular, the information can be the same.

Data can preferably be transmitted with the user interface, which are interpreted, rendered and displayed according to a predefined data structure and according to a predetermined manner in order to make them available to a customer.

According to a very advantageous development of the idea, provision can be made for general terms and conditions to be provided and, if necessary, for confirmation to be obtained from a customer. The confirmation can, for example, be documented and communicated to the service using a corresponding option UUID via the payment system communication line, the service domain communication line and/or via the vehicle payment communication line.

According to an advantageous embodiment, it can be provided that the fee-based service is displayed based on specific features according to a predefined display structure. Furthermore, a confirmation of the purchase and payment process can be obtained by the user, documented and communicated to the service using a process UUID via the payment system communication line, the service domain communication line and/or via the vehicle payment communication line. In a further embodiment, this can only take place after the payment process has been successfully completed.

A further advantageous refinement can provide for a confirmation to be obtained from a customer regarding a purchase or payment process, in which case the confirmation can be obtained via a radio button or displayed as a selection list. This is done as required by the service options. The confirmation can then be documented and communicated to the service using an option UUID via the payment system communication line, the service domain communication line and/or via the vehicle payment communication line. In a further embodiment, this can only take place after the payment process has been successfully completed.

In an advantageous embodiment, after a purchase has been completed, the payment process can be initiated via the payment system.

In a further advantageous embodiment, a paid service that has been purchased can be activated after the payment process has been initiated. In a further embodiment, if no information is provided by the backend within a certain time after signaling a request for a payment process on the vehicle payment communication line or there is no connection, the user interface can respond in a coordinated manner, for example by outputting the information or a A note saying "please be patient" is issued.

Further advantages of the payment system according to the invention result from the remaining dependent subclaims and are clear from the exemplary embodiment, which is described in more detail below with reference to the figure.

• 1 eine mögliche Ausführungsform des Bezahlsystems in einer schematischen Darstellung.

It shows:

• 1 a possible embodiment of the payment system in a schematic representation.

In the representation of 1 a possible embodiment of the payment system 1 is shown in a schematic representation. The illustration shows an overall system consisting of vehicle 8 and backend 7. An external payment service provider 8, for example, can be connected via backend 7 to trigger a payment process. The vehicle 8 includes a communication module 6, which is designed in particular as a control device and can provide a connection to a cloud. A head unit 10 is also included in the vehicle 8 and is designed in particular as a central telematics platform on which the user interface 4 and the operation of the user interface 4 can also take place. Furthermore, another control unit, an application 3 and/or a service that can offer a chargeable service is integrated in the vehicle 8 . An electronic payment system 11 thus includes parts of the payment service provider 9, the backend 7, the communication module 6, the head unit 7 and the user interface 4. Thus, the vehicle 4 is the actual fee-based service on a control unit or an application 3, or also partly in backend 7, running, shown. Thus, at the interface 5a, a payment system communication strand from the backend 7 to head unit 10 can be trained. Another service-domain communication line runs at the interface 5b via the communication module 6 to the backend 7. The overall domain of the service 12 thus runs from the chargeable control device, the chargeable application 3 or from the chargeable service via the communication module 6 and also contains parts of the backend 7.

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• WO 2015/016929 A1 [0003]

Claims (7)

Payment system (1) in a hardware and software environment in a vehicle (8), for providing a control device or an application in the vehicle (8) with a paid update or a paid service, characterized in that communication via a static, universal and abstracted interfaces (5a) from a backend (7) via a central communication module (6) to a user interface (4) in the vehicle (8) in a predefined manner, with a static, universal and abstracted interface (2) between the application ( 3) and the user interface (4) any number of payment services can be mapped, whereby a payment process is processed via a dynamic, application-dependent interface (5b) between the application (3) and the communication module (6) and the backend (7) and all of the Payment process and a user interaction necessary information can be transmitted. Payment system (1) according to claim 1 , characterized in that the user interface (4) data are transmitted, which are interpreted, rendered and displayed according to a predefined data structure and according to a predetermined way. Payment system (1) according to claim 1 or 2 , characterized in that terms and conditions are provided and, if necessary, confirmation is obtained from a customer. Payment system (1) according to one of Claims 1 until 3 , characterized in that the paid service is displayed based on specific features according to a predefined display structure. Payment system (1) according to one of Claims 1 until 4 , characterized in that a confirmation is obtained from a customer about a purchase or payment process, the confirmation being obtained via a radio button or displayed as a selection list. Payment system (1) according to one of Claims 1 until 5 , characterized in that after a purchase is completed, the payment process is initiated via the payment system. Payment system (1) according to one of claim 6 , characterized in that after initiating the payment process, a paid service that has been purchased is activated.

Images