Payment system in a vehicle hardware and software environment

Abstract

The invention relates to a payment system (1) in a hardware and software environment in a vehicle (8) for providing paid updates or paid services to a control device or application in the vehicle (8), characterized in that the 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), that any payment service can be mapped via a static, universal and abstracted interface (2) between the application (3) and the user interface (4), and that the payment process can be handled and all information required for the payment process and the user interaction can be transmitted via a dynamic application-dependent interface (5b) between the application (3), the communication module (6) and the backend (7).

Description

[Technical Field]

[0001] The present invention relates to a payment system in a hardware and software environment in a vehicle, as defined in more detail in the preamble of claim 1. [Background technology]

[0002] Basically, payment systems are known from the prior art which are displayed in the vehicle and which are able to trigger a payment process. For example, Patent Document 1 describes a vehicle payment system that allows payment orders to be received wirelessly from the outside and processed from the vehicle.

[0003] However, known payment systems are limited to a single known application and are customized, so the visualization and operation using the in-vehicle user interface (UI) must be defined prior to implementation, since the communication relationships of all involved control devices must be adapted prior to implementation in order to provide and display the necessary information for the application.

[0004] A possible payment process is, for example, the payment for a charging process when charging an electric vehicle. Furthermore, other services can be paid for using this payment process as well. For example, products such as toll stickers, especially Swiss or Austrian vignettes, can be paid for from the vehicle using this type of payment system. A drawback of known payment systems is that the user interface must determine in advance which payment process is to be performed. For example, it must be determined that the charging process in question is a charging process with a specific number of kilowatt-hours at a specific purchase price, and that this specific purchase price is to be paid in a specific total amount. Furthermore, the user interface must determine in advance whether to pay for a toll sticker with a specific purchase price and valid for a specific period of time, for example, one year. In this case, different data, different visualizations, and different selection options are used for each process. Therefore, known payment systems have the disadvantage that the paid service or paid application must be known in advance in order to design a corresponding user interface. Furthermore, in order to be able to use the service of the payment process, the implementation must also be carried out at the communication partner, where, for example, long-term specified deadlines of the communication layer (NCD) must also be respected. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] WO2015 / 016929A1 Summary of the Invention [Problem to be solved by the invention]

[0006] SUMMARY OF THE INVENTION The object of the present invention is to provide a payment system for vehicles that overcomes the above-mentioned drawbacks. [Means for solving the problem]

[0007] According to the invention, this problem is solved by a payment system having the features set forth in claim 1, and here in particular the features set forth in the characterizing part of claim 1. Advantageous configurations and developments emerge from the claims dependent thereon.

[0008] At the core of the payment system according to the invention, communication takes place in a predefined way via a static, universal and abstracted interface from the backend via a central communication module to the vehicle's user interface; via the static, universal and abstracted interface between the application and the user interface, any payment service can be mapped; via a dynamic, application-dependent interface between the application, the communication module and the backend, the payment process can be handled and all information required for the payment process and user interaction can be transmitted.

[0009] A payment system is provided in the hardware and software environment within the vehicle to provide paid updates or paid services to the control devices or applications within the vehicle.

[0010] Thus, the present invention allows for the integration of a payment system into a vehicle that allows other control devices and applications in a wired vehicle network to process specific paid services. This can be done using a generic predefined interface without any adaptations in vehicle network communication. In other words, the present invention provides an agile and dynamic payment system in a vehicle with a generic interface. The introduction of new paid services and / or applications is possible without the need to adapt the payment system and its interface. Thus, the present invention associates paid services and / or applications with a generically available interface.

[0011] The payment system according to the present invention can achieve efficient configuration of scarce resources in the vehicle network. For example, the separation / encapsulation of service domains significantly accelerates service development and reduces the effort and cost, so that the introduction or modification of new services does not require changes to the vehicle communication (NCD), head unit software / UI software, or payment communication lines. Therefore, the proposed payment system can flexibly introduce new payment services without requiring changes to the interface for each payment service.

[0012] The static, universal, and abstracted interface between the application and the user interface can also be referred to as a vehicle payment communication line. Communication along this communication line is predefined and preferably follows a static, universal, and / or abstracted format that is concise and efficient in terms of the content of the communication. In particular, the communication line is configured to map any payment service. Here, a universally unique identifier (UUID), for example, can be used to characterize a specific payment process. This type of UUID, also referred to as a process UUID, is preferably provided by the payment service and required by the payment process. In one alternative embodiment, if multiple payment options exist for a service, option UUIDs for the various payment options can be provided structurally subordinate to the process UUID for the payment process. In either case, the process UUID and / or option UUID can be used to signal the success of the payment process to the payment service in order to activate the service upon completion of the payment process. In one further embodiment, the user interface can advantageously provide at least one feedback to the payment service, for example indicating an error message or information about a temporarily unavailable connection in a dead zone, etc. Likewise, an interruption of the process can be indicated via an error message.

[0013] The dynamic, application-dependent interface between the application, the communication module, and the backend can also be referred to as the service domain communication line. Preferably, this communication line or this communication is entirely within the domain and / or under the control of the service developer. Preferably, all information required for the payment process and user interaction is transmitted to the backend via this interface. In particular, by appropriately designing the interface along this line, the transmitted data content can be flexibly adapted, supplemented, and / or extended to accommodate future services at any time. In other words, this interface is preferably dynamic, so that other, previously unknown services can be transmitted without modifying the NCD. In one embodiment, for example, data containers with non-predefined content can be used. In one preferred embodiment, the content can be associated with a specific payment process for a service using a process UUID and / or, in the backend, additionally using the vehicle identification number (VIN), in particular using the option UUID.

[0014] In one embodiment, the service information can be sent to the backend via the service domain communication line, or can be adapted to the service and provided directly on the backend side of the service. The information can be, for example, an icon and / or an image. Similarly, font, font size, font color, and / or font attributes can be included. Preferably, the service and the specific payment process, i.e., the result achieved, are also represented. Furthermore, the quantity, unit, cost per unit, total cost, currency name, currency abbreviation, appropriately associated text segments, or icons can be indicated. In one embodiment, if multiple options are available, the option UUID can be used as a reference to indicate various icons, images, names of the service and the specific payment process, quantity, unit, cost per unit, total cost, currency name, currency abbreviation, appropriately associated text segments, and / or icons. In the case of multiple options, the data can provide information on whether the options are exclusive, for example, selectable by radio buttons, or whether multiple options should be selectable simultaneously. Furthermore, information on the format and / or display of the content can be included. Optionally, the information can also be terms of use information, which can have an option UUID if confirmation is required. Similarly, information on menu points that require confirmation, for example, information on menu points for "paid orders," may be included.

[0015] If the payment process is processed and all information required for the payment process is transmitted, this can be done in the payment system communication line. This is preferably designed as a generic interface so that a large number of different services with various requirements can be covered in a given fixed structure without the need to implement changes in one of the components involved, in particular the user interface. In one embodiment, JSON objects, YAML structures, and / or web page description languages, in particular HTML, can be used for such data structures. The mapping of content to specific payment processes for services can be done using the process UUID, as already explained with respect to the service domain communication line, and in the backend, in particular additionally using the vehicle identification number (VIN) and / or optional UUID. In this case, it may be done as already explained with respect to the service domain communication line. In particular, the information may be the same.

[0016] Preferably, the data is transmitted to a user interface, where it is interpreted, processed and displayed according to a predefined data structure and in accordance with a predetermined scheme, thereby providing the data to the customer.

[0017] According to a very advantageous development of this idea, terms of use can be provided and, if necessary, confirmed by the customer, which confirmation can for example be recorded and communicated to the service via the payment system communication line, the service domain communication line and / or the vehicle payment communication line using a corresponding optional UUID.

[0018] According to one advantageous configuration, paid services can be displayed based on specific characteristics according to a predefined display structure. Furthermore, the user's confirmation of the purchase and payment process can be performed, recorded, and communicated to the service using the process UUID via the payment system communication line, the service domain communication line, and / or the vehicle payment communication line. In another embodiment, this can only be done after the payment process has been successfully completed.

[0019] In another advantageous configuration, the purchase or payment process can be confirmed by the customer, and this confirmation can be made via radio buttons or displayed as a selection list, depending on the requirements of the service option. This confirmation can then be recorded and communicated to the service using the option UUID via the payment system communication line, the service domain communication line, and / or the vehicle payment communication line. In another embodiment, this can only occur after the successful completion of the payment process.

[0020] In one advantageous embodiment, after a purchase is completed, a payment process can be initiated via a payment system.

[0021] In another advantageous embodiment, after initiation of the payment process, the purchased paid service can be activated. In another embodiment, if after a request for the payment process is signaled in the vehicle payment communication line, no information is provided from the backend within a predetermined time or if there is no connection, the user interface can react accordingly, for example by outputting information or the instruction "Please wait."

[0022] Further advantages of the payment system according to the invention result from the remaining dependent claims and will become apparent on the basis of the examples described in detail below with reference to the drawings. [Brief explanation of the drawings]

[0023] [Figure 1] 1 shows a schematic diagram of one possible embodiment of a payment system. DETAILED DESCRIPTION OF THE INVENTION

[0024] One possible embodiment of a payment system 1 is shown in a schematic diagram in Figure 1. The figure shows the entire system consisting of a vehicle 8 and a backend 7. Via the backend 7, for example, an external payment service provider can be contacted to trigger the payment process. 9 The vehicle 8 includes a communication module 6, which is particularly configured as a control device and can provide a connection to the cloud. The vehicle 8 also includes a head unit 10, which is particularly configured as a central telematics platform on which the user interface 4 can be displayed and operated. Furthermore, other control devices, applications 3, and / or services that can provide paid services are integrated into the vehicle 8. The electronic payment system 11 thus includes a payment service provider 9, a back end 7, a communication module 6, the head unit 7, and part of the user interface 4. The vehicle 4 is thus mapped with paid services that are executed in the control devices or applications 3 or partially in the back end 7. A payment system communication line can thus be established from the back end 7 to the head unit 10 at interface 5a. A separate service domain communication line extends to the back end 7 via the communication module 6 at interface 5b. A vehicle payment communication line 2 is established in the vehicle 8, extending from the services via the head unit 10 to the user interface 4. Thus, the entire domain of the service 12 extends from the paid controller, paid application 3 or paid service via the communication module 6 and also includes part of the backend.

Claims

1. A payment system (1) in a hardware and software environment in a vehicle (8), comprising: The payment system (1) provides paid updates or paid services to a control device or application in the vehicle (8), communication takes place in a predefined manner through a static, universal and abstracted interface (5a) from a backend (7) that can connect to an external payment service provider (9) for triggering the payment process, via a central communication module (6) to a user interface (4) in the vehicle (8); Through a static, universal and abstracted interface (2), which can also be called a vehicle payment communication line, between the application (3) and the user interface (4), any payment service can be mapped to characterize a specific payment process; The payment system is characterized in that the payment process for validating purchased paid services can be handled and all information required for the payment process and user interaction can be transmitted between the application (3), the communication module (6) and the backend (7) via a dynamic application-dependent interface (5b).

2. 2. A payment system (1) according to claim 1, characterized in that data is transmitted to the user interface (4), said data being interpreted, processed and displayed according to a predefined data structure and in accordance with a predetermined scheme.

3. Payment system (1) according to claim 1 or 2, characterized in that terms and conditions are provided and, if necessary, confirmed by the customer.

4. Payment system (1) according to claim 1 or 2, characterized in that the paid services are displayed based on specific characteristics according to a predefined display structure.

5. 3. A payment system (1) according to claim 1 or 2, characterized in that the purchase or payment process is subject to confirmation by the customer, said confirmation being possible via radio buttons or being displayed as a selection list.

6. Payment system (1) according to claim 1 or 2, characterized in that the payment process is initiated via the payment system after the purchase is completed.

7. Payment system (1) according to claim 6, characterized in that after the initiation of the payment process, the purchased paid service is activated.

Images