Vehicle charging payment

Abstract

A method of payment for charging of a battery of a vehicle comprises the following. A charging connection is established between a charging station and a vehicle. A first communication channel between a vehicle charging controller and a charging station charging controller and a second communication channel between a payment controller in the vehicle and an access controller in the charging station are both established over the charging connection. After this, a payment transaction is established for authorization over the second communication channel between the payment controller acting as a card-based payment device and the access controller acting as a payment terminal. The access controller then provides the established payment transaction for authorization through a payment network. A suitable charging station and a suitable electric vehicle are also described.

Description

[0001] VEHICLE CHARGING PAYMENT

[0002] CROSS-REFERENCE TO RELATED APPLICATION

[0003] This application claims the benefit of, and priority to, United Kingdom Patent Application No. 2316916.2, filed on November 3, 2023, the entire disclosure of the above-referenced application is incorporated herein by reference.

[0004] TECHNICAL FIELD

[0005] The present disclosure relates to systems and methods for payment for vehicle charging.

[0006] BACKGROUND

[0007] A developing approach to the charging of electric vehicles (EVs) is the use of EV charging stations associated with a smart grid. Use of a smart grid allows for particularly efficient charging, and for vehicle batteries to be used as sources of electricity for the smart grid in particular situations. ISO 15118 is a set of standards developed to support interaction of an EV with a smart grid for charging. ISO 15118 supports communication between an electric vehicle and a charging station (more generally, supply equipment) using power line communication - this operates over the charging interface (which may be wired or wireless). When ISO 15118 is implemented, an electric vehicle communication controller (EVCC) of the vehicle communicates with the supply equipment communication controller (SECC) using Transmission Control Protocol (TCP), the standard transport layer protocol using in internet communication.

[0008] A ’’plug and charge” model has been developed for charging of electric vehicles once the charging connection is established - this is based on there being a pre-existing service contract. After an authorization interaction in which the SECC determines that the EV is associated with a valid contract, charging is carried out and billing takes place offline according to whatever method is established in that contract, in a similar manner to payment for telecoms services, for example.

[0009] A ’’plug and charge” model based on contracts is convenient for users in local environments, but has drawbacks. The lack of interoperability in this approach prevents it from being properly scalable, particularly across national borders. ISO 15118 offers the alternative of external payment, in which payment takes place separately from the charging event, but this requires interactions from the user going significantly beyond those required for “plug and charge”

[0010] The present disclosure has been devised to mitigate or overcome at least some of the above-mentioned problems with existing approaches to payment for vehicle charging.

[0011] SUMMARY OF THE DISCLOSURE

[0012] According to a first aspect of the present disclosure there is provided a method of payment for charging of a battery of a vehicle, the method comprising: establishing a charging connection between a charging station and a vehicle; establishing a first communication channel between a vehicle charging controller and a charging station charging controller over the charging connection; establishing a second communication channel between a payment controller in the vehicle and an access controller in the charging station over the charging connection; establishing a payment transaction for authorization between the payment controller acting as a card-based payment device and the access controller acting as a payment terminal over the second communication channel; and the access controller providing the established payment transaction for authorization through a payment network.

[0013] Using this approach, card-based payment can be performed using a plug and charge model. In embodiments, the first communication channel between the vehicle charging controller and the charging station charging controller is established in accordance with an ISO 15118 standard.

[0014] Advantageously, the first communication channel and the second communication channel may share one or more networking layers of a networking connection. The first and second communication channels may share at least a physical layer and a data link layer.

[0015] In one type of arrangement, the first and second communication channels may share all networking layers other than an application layer. However, in another type of arrangement in which first and second communication channels share at least a physical layer and a data link layer, the first and second communication channels may have separate TLS / TCP channels at the transport layer. This provides for a very effective approach for handling card-based payment effectively without compromising or overburdening ISO 15118 communication. In embodiments, the method may comprise a service discovery process before establishing the second communication channel to determine that card-based payment is supported - this may be for example a DNS service discovery process.

[0016] In embodiments, in establishing a payment transaction for authorization, a first payment authorization flow may be conducted between the vehicle charging controller and the charging station charging controller and a second payment authorization flow may be conducted between the payment controller and the access controller. In such an arrangement, for authorization of the payment transaction, the second payment authorization flow may establish that payment parameters for an authorizable card payment are present, whereupon the first payment authorization flow may be adapted to select card-based payment as an authorization option for payment. Using such a “choke point” allows card-based payment to be integrated effectively with ISO 15118 authorisation processes.

[0017] In embodiments, establishing a payment transaction for authorization between the payment controller and the access controller may use EMV transaction flows or data objects. Here, interaction between the payment controller and the access controller may be according to a client-server model, where the access controller acts as the server and the payment controller acts as the client. Establishing the payment transaction for authorization may use contactless EMV transaction flows or data objects. In such cases, establishing the payment transaction for authorization may comprise the payment controller generating an application cryptogram. Establishing the payment transaction for authorisation may also comprise performing cardholder verification, wherein cardholder verification may comprise performing a process also used to verify the cardholder to the vehicle.

[0018] According to a second aspect of the present disclosure there is provided a charging station for charging an electric vehicle, the charging station comprising: a charging means adapted to establish a charging connection with a vehicle; a charging station charging controller adapted to communicate with a vehicle charging controller of the vehicle to control a charging operation; an access controller adapted to act as a payment terminal to establish a payment transaction for authorization with a payment controller of the vehicle using card-based payment’ and wherein the access controller is configured to provide the established transaction to the acquirer for authorization; wherein the charging station charging controller communicates with the vehicle charging controller over a first communication channel and the access controller communicates with the payment controller over a second communication channel, wherein the charging station is adapted to establish both the first communication channel and the second communication channel over the charging connection.

[0019] This charging connection may be wired or wireless.

[0020] In embodiments, the charging station charging controller is adapted to establish the first communication channel to the vehicle charging controller in accordance with an ISO 15118 standard. Such a charging station may be adapted such that the first communication channel and the second communication channel share one or more networking layers of a networking connection. In some cases, the charging station may be adapted such that the first and second communication channels share at least a physical layer and a data link layer. In such a case, the charging station may be adapted such that the first and second communication channels have separate TLS / TCP channels at the transport layer.

[0021] In embodiments, the charging station may be adapted to support a first payment authorization flow between the vehicle charging controller and the charging station charging controller and a second payment authorization flow between the payment controller and the access controller. In such a case, for authorization of the payment transaction, the second payment authorization flow may establish that payment parameters for an authorizable card payment are present, whereupon the first payment authorization flow is adapted to select card-based payment as an authorization option for payment.

[0022] In embodiments, establishing a transaction for authorization between the payment controller and the access controller uses EMV transaction flows or data objects. The access controller may then be adapted for interaction with the payment controller according to a client-server model, where the access controller acts as the server and the payment controller acts as the client.

[0023] According to a third aspect of the present disclosure there is provided an electric vehicle, the electric vehicle comprising: a charging system for a battery of the electric vehicle, wherein the charging system is adapted to establish a charging connection with a charging station; a vehicle charging controller adapted to communicate with a charging station charging controller of the charging station to control a charging operation; a payment controller in the vehicle adapted to act as a card-based payment device to establish a transaction for authorization with the access controller acting as a payment terminal and to provide the established transaction to the access controller for authorization through a payment network; wherein the vehicle charging controller communicates with the charging station charging controller over a first communication channel and the payment controller communicates with the access controller over a second communication channel, wherein the electric vehicle is adapted to establish both the first communication channel and the second communication channel over the charging connection.

[0024] In embodiments, the vehicle charging controller is adapted to establish the first communication channel in accordance with an ISO 15118 standard.

[0025] The electric vehicle may be adapted such that the first communication channel and the second communication channel share one or more networking layers of a networking connection. In such cases, the electric vehicle may be adapted such that the first and second communication channels share at least a physical layer and a data link layer. The electric vehicle may then be adapted such that the first and second communication channels have separate TLS / TCP channels at the transport layer.

[0026] In embodiments, the electric vehicle is adapted to support a first payment authorization flow between the vehicle charging controller and the charging station charging controller and a second payment authorization flow between the payment controller and the access controller. In such a case, for authorization of the payment transaction, the second payment authorization flow may establish that payment parameters for an authorizable card payment are present, whereupon the first payment authorization flow may then be adapted to select card-based payment as an authorization option for payment.

[0027] In embodiments, establishing a transaction for authorization between the payment controller and the access controller may use EMV transaction flows or data objects. The payment controller may then be adapted for interaction with the access controller according to a client-server model, where the access controller acts as the server and the payment controller acts as the client. In such case, the payment controller may be adapted to generate an application cryptogram to establish a transaction for authorization. In some embodiments, the electric vehicle may have a driver verification means, and this driver verification means may also be adapted to perform cardholder verification.

[0028] In embodiments, such an electric vehicle may be a battery electric vehicle or a plug-in hybrid electric vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] One or more embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0030] Figure 1 shows a vehicle charging system in which embodiments of the disclosure can be deployed;

[0031] Figure 2 shows a payment infrastructure supporting embodiments of the disclosure;

[0032] Figure 3 shows main elements of a method of payment for vehicle charging according to an embodiment of the disclosure;

[0033] Figures 4A and 4B show two different approaches to implementing network connections between the vehicle and the charging station using the charging connection in implementing the method of Figure 3;

[0034] Figure 5 shows a design for a system according to an embodiment of the disclosure that implements both ISO 15118 and open payment over the charging connection;

[0035] Figure 6 shows ISO 15118 and open payment flows and their interactions in the system of Figure 5;

[0036] Figure 7 illustrates a service discovery process to determine whether open payment is supported in a system as shown in Figure 5;

[0037] Figure 8 illustrates an open payment protocol for use in a system as shown in Figure 5;

[0038] Figure 9 shows an integration of open payment and ISO 15118-2 messaging flows; and

[0039] Figure 10 shows an integration of open payment and ISO 15118-20 messaging flows.

[0040] DETAILED DESCRIPTION

[0041] General and specific embodiments of the disclosure will be described below with reference to the Figures.

[0042] Figure 1 shows a vehicle charging system in which embodiments of the disclosure can be deployed. Vehicle 1 is connected to a charging station 2, in this case by a charging cable 3 plugged into a charging connector 8 of the vehicle 1 - in other embodiments, charging may be by induction, in which case there will be no cable and the interfaces at the vehicle and the charging station will comprise induction loops. In either case, there is a charging connection established between the vehicle 1 and the charging station 2, and this charging connection can be used for power line networking. The ISO 15118-3 standard establishes requirements for physical layer and data link layer networking over such a charging connection - this can simply be established here for connecting a vehicle charging controller 4 and a supply charging controller 5. The vehicle charging controller 4 controls charging of the vehicle battery 6, while the supply charging controller 7 controls provision of charge to the charging system of the vehicle 1.

[0043] Figure 2 shows a payment infrastructure supporting embodiments of the disclosure. For the purposes of payment according to embodiments of the disclosure, there are payment entities resident in the vehicle 1 and the charging station 2 respectively that allow card-based payment to take place over the charging connection. “Card-based payment” will be used throughout this specification to refer to this type of payment transaction, though it will be appreciated that (as here) the transaction does not require the presence of a physical payment card - in many cases, as here, the role of a payment card is taken by an appropriate payment device, typically using tokenization so that the device uses tokens to transact with reconciliation with a card account occurring in the payment infrastructure. The transacting entities here are a card data controller 21 which acts as a payment device, and a card access manager 22 which acts as a terminal. The card data controller 21 is situated so that it can make a networking connection over the charging connection - it may be located within the vehicle charging controller or in communication with it, or simply disposed so that it can also perform power line networking over the charging connection. For preference, the card data controller 21 is able to use the same physical layer and data link layer established for ISO 15118-3 networking. The card access manager 22 is in a similar position with respect to the supply charging controller 5.

[0044] Figure 2 shows how this arrangement fits into a typical four-party model or four-party payment transaction scheme. The diagram illustrates the entities present in the model and the interactions occurring between entities operating in a card scheme. Normally, card schemes - payment networks linked to payment cards - are based on one of two models: a three-party model or a four-party model (adopted by the present applicant). For the purposes of this document, the four-party model is described in further detail below. The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder 20, merchant, issuer 23 and acquirer 24. Here, the cardholder 20 is represented by the card data controller 21 and the merchant is represented by the card access manager 22. The customer (through card data controller 21) is purchasing charge from the supply provider (through card access manager 22) associated with the charging station 2. The issuer 23 is the bank or any other financial institution that issued the card used for the payment to the cardholder 20 - a digital version of this card is accessed by the card data controller 21. The acquirer 24 provides services for card processing to the supply provider.

[0045] The model also comprises a central switch 25 - interactions between the issuer 130 and the acquirer 140 are routed via the switch 25. The switch 25 - in practice, a full payment infrastructure associated with a card scheme provider enables a supply provider (or any other merchant) associated with one particular bank acquirer 24 to accept payment transactions from a cardholder associated with a different bank issuer 23.

[0046] A typical transaction between the entities in the four-party model can be divided into two main stages: authorization and clearing-and-settlement. The cardholder 20 initiates a purchase of a good or service from the merchant - here the charging station 2 - using their card, here via the power line connection between the card data controller 21 and the card access manager 22. Details of the card and the transaction are sent in real-time or deferred to the issuer 23 via the acquirer 24 and the switch 25 to authorise the transaction. In general, the cardholder 20 may have provided verification information in the transaction, and in some circumstances may be required to undergo an additional verification process to verify their identity. Once any such additional verification process is complete the transaction is authorised. Specific versions of this general model will be described in further detail below with reference to embodiments of the disclosure, particularly in relation to verification processes.

[0047] On completion of the transaction between the cardholder and the merchant, the transaction details are submitted by the merchant to the acquirer 24 for clearing and settlement. The transaction details are then routed to the relevant issuer 23 by the acquirer 24 via the switch 25. Upon receipt of these transaction details, the issuer 23 provides the settlement funds to the switch 25, which in turn forwards these funds to the merchant via the acquirer 24. Separately, the issuer 23 and the cardholder settle the payment amount between them. In return, a service fee is paid to the acquirer 24 by the merchant for each transaction, and an interchange fee is paid to the issuer 23 by the acquirer 24 in return for the settlement of funds. Settlement is not directly relevant to the present disclosure and will not be described further here.

[0048] Main elements of a method of payment for vehicle charging according to an embodiment of the disclosure are shown in Figure 3. First of all, a charging connection is established 300 between the charging station and the vehicle. After this, a networking connection is established 310 between the charging station and the vehicle over the charging connection, using power line networking. As noted above, this can be done by implementing the ISO 15118 standard, with ISO 15118-3 defining the physical layer and the data link layer.

[0049] It may at the point in some embodiments be necessary to establish whether the vehicle and the charging station both support card payment over the charging connection - this can be carried out by service discovery 320. There will also be at some point - it may be at this point or later - a determination at the vehicle of what payment option to use if multiple payment options are available.

[0050] If payment by card over the charging connection is to take place, the transaction can then be established 330 in essentially the same manner as existing transactions. As described below, this may be done effectively by appropriate use of existing transaction protocols, particularly contactless payment protocols under EMV standards. EMV specifications relate to contact and contactless payment protocols and are publicly available at the EMVCo website (EMVCo is the industry body tasked with maintaining these specifications with the support of major transaction scheme providers) - http s : / / www . e vco . conV'document- search / - and would readily be consulted by the person skilled in the art.

[0051] Following this model, the transaction is authorised after the charging station (acting as a terminal) provides the transaction 340 for authorization in the same manner as any EMV transaction (initially to the enquirer, and then to the cardholder issuing bank through the central switch / payment network as described above).

[0052] Figures 4A and 4B show two different approaches to implementing network connections between the vehicle and the charging station using the charging connection. Figure 4A shows an approach in which the payment connection is built on the ISO 15118-3 physical layer and data link layer connection (the current version of this standard is ISO 15118-3:2015), and where there is a common internet layer, but where a separate transport layer and higher networking layers are used for payment than from ISO 15118 messaging (for example for Vehicle-to-Grid - V2G - messaging). The payment connection has its own TCP transport, with a session layer and presentation layer built over that - these layers are not critical in construction to the present disclosure and can be provided in known manner by the person skilled in the art. Payment messaging is handled in the application layer, with the relevant protocol for payment-related activity here being described as “Open Payment”.

[0053] Figure 4B shows an alternative approach in which the Open Payment service is provided over the ISO 15118 stack (which would be defined by ISO 15118- 2 or ISO 15118-20, depending on the networking generation used). This approach only requires an application protocol to be developed as it uses ISO 15118 for the session layer and the presentation layer - though for preference, a separate V2GTP channel would be established for payment to the V2GTP channel handling communication between the vehicle charging controller (EVCC) and the charging station controller (SECC). This approach would require some modification to the ISO 15118-2 and ISO 15118-20 standards (current versions ISO 15118-2:2014 and ISO 15118-20:2022), and may need to rely on wide implementation of an ISO 15118 PKI.

[0054] An embodiment will now be described in detail below - this embodiment follows the approach set out in Figure 4A and diverges from the ISO 15118 stack at the transport layer. A design for such a system that implements both ISO 15118 and “Open Payment” over the charging connection is set out in Figure 5.

[0055] At the top level are the two application environments: the (electric) vehicle application environment and the charging station application environment. There are a plurality of communication channels shown for communication between different corresponding elements in each environment.

[0056] Within each application environment, there is a “Plug&Charge” application. As will be seen below, this application will be able to handle both existing (contract-based) plug and charge and the open payment card-based alternative introduced here. This application enables the plug and charge use case(s) and orchestrates the messaging flow - including the transaction flow. The Plug&Charge applications have different, but complementary, components.

[0057] The EV “Plug&Charge” application has the following components: • EVCC, responsible for contract-based service enablement and functions defined by ISO 15118-2 / -20;

[0058] • Card data controller (CDC), ancillary to EVCC, responsible for card-based payment;

[0059] • A set of APIs defined to perform "Plug&Charge" and open payment related operations;

[0060] • Message handler, responsible for routing messages to the correct destination;

[0061] • SDP client, responsible for service discovery functions defined by ISO 15118-2 / -20;

[0062] • V2GTP handler, responsible for V2GTP functions defined by ISO 15118- 2 / -20;

[0063] • Open payment handler, responsible for functionalities specific to open payment; and

[0064] • Network stack, responsible for communication facilities.

[0065] The charge station "Plug&Charge" application has the following components:

[0066] • SECC, responsible for contract-based service enablement functions defined by ISO 15118-2 / -20;

[0067] • Card access manager (CAM), ancillary to SECC, responsible for card-based payment;

[0068] • A set of APIs defined to perform "Plug&Charge" and open payment related operations;

[0069] • Message handler, responsible for routing messages to the correct destination;

[0070] • SDP server, responsible for providing V2GTP functions defined by ISO 15118-2 / -20;

[0071] • V2GTP handler, responsible for V2GTP functions defined by ISO 15118- 2 / -20;

[0072] • Open payment handler, responsible for functionalities specific to open payment; and

[0073] • Network stack, responsible for communication facilities. There are a plurality of channels showing messaging interactions between different EV and charge station components. Here, the bidirectional arrows indicate the "language" the corresponding components speak, and include the following:

[0074] • CDC and CAM communicating over open payment messages;

[0075] • EVCC and SECC over V2G messages;

[0076] • Message handlers / routers transcode messages to / from EXI or JSON; and

[0077] • SDP client / server over SDP.

[0078] A specific embodiment of the method of Figure 3, using the networking stack of Figure 4A and the computing environment of Figure 5, will now be described in detail with reference to Figures 6 to 10.

[0079] As previously described, ISO 15118 defines interaction between electric vehicles (including both battery electric vehicles - BEV - and plug-in hybrid electric vehicles - PHEV) and a smart grid. The wired case is discussed here, though the model described is equally applicable to wireless charging, though in this case a different standard, ISO 15118-8, is used to define the physical and data link layers (the current version of this standard is ISO 15118-8:2020).

[0080] ISO 15118 expressly provides for a Plug and Charge (PnC) model of payment according to pre-existing contracts and use of certificates with a dedicated public key infrastructure (PKI). Using this approach, the vehicle can automatically identify itself to a charging station and can then be authorised for charging if an appropriate contractual relationship is in place. Authorization under this model is described, for example, in ISO 15118-20:2022 section 8.3.4.3.2, where PnC messaging is described in detail. One other authorization model is provided - external identification means (EIM), which is simply defined as authorization means that are handled outside the standards document (see section 3.17) and are not otherwise discussed. Up to now, this has been used for authorization using an entirely separate channel - such as payment with a physical credit card at a card reader at the charging equipment, or another mechanism such as reading of a QR code to initiate a phone-based transaction - with the standard only dealing with receiving an authorization result (and therefore to allow charging).

[0081] Embodiments of the disclosure provide an alternative to the Plug and Charge approach using card-based payment while still providing plug and charge functionality - there is no need to open a communication channel external to the charging connection. The interaction between ISO 15118 and this alternative to Plug and Charge - here termed open payment - is shown in Figure 6. This indicates which flows take place under ISO 15118 and which flows take place under open payment, including service discovery to determine whether open payment is available. From the perspective of ISO 15118, open payment acts as an EIM - however, payment authorization is not “external” to the charging connection, and instead operates over the charging connection using the physical layer and data link layer established under ISO 15118-3 (wired) or ISO 15118-8 (wireless).

[0082] To support this model, both the vehicle and charging station must be appropriately provisioned and the charging station must be connected to the relevant payment infrastructure. The charging station must be able to accept payment credentials for payment, by virtue of direct or indirect (for example, via a charging station provider) connection to an acquirer. Acceptance of card-based payment may then be done online, through real-time authorization to the issuer, deferred online or offline. For the latter two cases, the charging station would rely on offline data authentication mechanisms (as are described in the EMV specifications). The vehicle must be provisioned for card-based payment. This requires the vehicle to be equipped with a digitized card or cards - managed directly by the vehicle or by a third party, for example through a wallet - with an appropriate prioritization or selection mechanism if multiple cards are available.

[0083] Like the ISO 15118-2 / -20 standards, open payment depends on the same TCP / IP protocol stack - by taking advantage of the same basic building blocks, a charging station provider can easily add the support for open payment as an incremental change to an existing EV charging infrastructure. Open payment is based on existing EMV standards - in particular the EMV contactless payment standards (the contactless kernel specification v2.11 and associated specification are current and available from emvco.com / specifications). Open payment as described here has minimal impact on ISO 15118-2 / -20 standards - it is expected that the new functionality provided here may lead to additional EMV standardization.

[0084] The requirements of the open payment system are readily compatible with those of ISO 15118. The open payment system expects both the vehicle and the charging station to implement a standard TCP / IP protocol stack. The physical and data link layers are as defined under ISO 15118, as is the network layer - the approach described is appropriate for either IPv4 or IPv6.

[0085] A separate stack is provided from the transport layer, as shown in Figure 4A. Both UDP and TCP are used for open payment. The open payment entities at the EV and the charging station - these will be described in greater detail below - establish their own TLS / TCP channel, which is separate from the V2GTP transport layer channel between the EVCC and the SECC according to ISO 15118.

[0086] At the application layer, there will need to be a service discovery process to determine whether open payment is supported by both the vehicle and the charging station. This is described below with reference to Figure 7. An open payment application protocol will then be described with reference to Figure 8.

[0087] For service discovery, the approach proposed here is to use DNS service discovery (DNS-SD) with multicast DNS (mDNS) for peer-to-peer discovery on a local network. DNS-SD and mDNS enables service discovery in a local area network utilizing DNS constructs. Because DNS is a fundamental component of the TCP protocol stack, DNS-SD and mDNS are widely supported in modern networked devices.

[0088] In general terms, the charging station registers its supported external payment services over DNS-SD, which includes information like the network address, and may include other attributes like priority, preference, etc. Services are defined in a hierarchical manner in the form of <sub-type>.<service>.<domain> and the following example illustrates how external payment services could be organized:

[0089] • _ext-payment._tcp. local.

[0090] • _open-payment._ext-payment._tcp. local.

[0091] • _qrc-payment._ext-payment._tcp. local.

[0092] As is shown in Figure 7, this process starts with the registration of available services - in this case, open payment and QR code payment as an external payment and authorization mode - at the charging station (se).

[0093] When the EV has connected to the charging station as per ISO 15118- 3, it performs a DNS-SD lookup on the available external payment services and then determines if a mutually supported external payment method is available - in the case of open payment, this involves a first look-up to determine whether the service is supported, and a second look-up to determine whether this is a usable service provider. Using information from the service record, the EV can then connect to the charging station to continue - a port is set up for open payment connection, and the payment entities in the vehicle and the charging station are brought into communication.

[0094] The result of this service discovery process is an indication of whether open payment is supported by both the EV and the charging station. As shown in Figure 6, this service discovery process is separate and different from the SDP handshake and subsequent service discovery message exchanges defined in ISO 15118-2 / -20. In effect, the UDP / TCP server already present in the charging station (to enable it to operate under ISO 15118) establishes its ISO 15118 connection but also looks for an open payment connection too as a second TCP connection.

[0095] The open payment protocol itself is illustrated in Figure 8. The open payment protocol describes two entities, a card data controller (CDC) residing in the vehicle, and a card access module (CAM) residing in the charging station. Their relation and functions are comparable to an EMV card and an EMV kernel, respectively (as described in EMV specifications as referenced above). An EMV kernel is resident in the terminal - such as a point of sale terminal - representing the merchant. The protocol operates on a client-server model, where the CDC acts as the client and the CAM as the server. Note that this is different from EMV - this also uses a client-server model, but the kernel is the client, and the card is the server. There is no fundamental difference in operation, with adaptations from the original EMV model being made to enable effective interaction between open payment and ISO 15118.

[0096] There are three stages to an open payment transaction - these are application selection, payment authorization and close down. These mirror stages of a typical EMV transaction. The application selection process determines if there is a common and eligible application for the transaction and the payment authorization process provides a token as proof of payment. Finally, the connection is closed (with an option step for adjusting the amount of transaction for authorization purpose). Each of these stages is described below with reference to Figure 8. Figure 8 is sequence diagram illustrating the open payment protocol and processing, with relevant entities being identified as follows:

[0097] • EV: electric vehicle

[0098] • CDC: card data controller; enabling open payment in EV • SE: charging station

[0099] • CAM: card access module; enabling open payment in SE

[0100] The application selection stage follows the general principles used in EMV - the CDC and CAM exchanges information to agree on a common eligible application for subsequent payment. The messages and high-level data exchanged are described below. Table 1 below indicates the messages and high-level data exchanged.

[0101] Figure 1 : Application Selection Messaging These stages are illustrated in Figure 8. After the service discovery process has established that open payment is available, there is a handshake between CDC and CAM, and the CDC provides the CAM with its supported card brands - these are provided as Registered Application Provider Identifiers (RIDs), which is a standard EMV concept. The CDC evaluates the RIDs to provide a list of Application Identifiers (AIDs - another standard EMV concept) that would appear to be supported by both CDC and CAM from the RID list, and will also provide generic transaction data that is AID-independent. This includes basic features of the transaction such as amount, currency code, country code, etc. (though it should be noted that the amount can be varied at the close down stage - see below). At this point, the CDC runs its preferred application from the AID list, indicating this by selected ADF name to the CAM, using the received transaction data, and sends card-specific static data, such as card certificates, to the CAM. The CAM validates any certificates and then provides any payment system specific data needed by the selected AID. The open payment system is now ready to perform the transaction - at this stage, both vehicle and charge point know that card payment should be possible (or alternatively that it will not be possible and should not be selected) pending authorization.

[0102] Performance of the transaction involves payment authorization. This is performed by the CDC and the CAM, with the CDC generating a token for the CAM as proof of payment. Table 2 below indicates the messages and high-level data

[0103] Figure 2: Payment Authorization Messaging This flow is also shown in Figure 8 - CDC generates an application cryptogram and data for transaction authorization purposes (such as a PKI signature over the data for offline dynamic data authorization) in essentially the same way as for an EMV transaction. The authorization response from CAM, following a conventional EMV authorization process, indicates whether the transaction data is acceptable.

[0104] In order to generate an application cryptogram, an appropriate cardholder verification method may be required - for a contactless protocol, a Consumer Device Cardholder Verification Method (CDCVM). This may involve a cardholder authentication to the card by a knowledge factor (PIN, password) or a biometric (face, fingerprint) prior to the authorization. It would be particularly convenient to re-use any mechanism already used by the vehicle to identify the legitimate driver, as this would support a seamless plug and charge use model. Other mechanisms - such as use of a one-time password sent by the issuer to a cardholder mobile phone - are possible, and may take place either before or during authorization.

[0105] The close down process is performed when the charging session is completed, and a final payment amount can be determined. There are no application protocol messages exchanged in this stage, but the CDC may perform an optional business process to adjust the final payment amount for the transaction before disconnection.

[0106] Figures 9 and 10 shown how this open payment flow can be integrated with ISO 15118 messaging flows. Figure 9 shows this integration for ISO 15118-2, whereas Figure 10 shows it for ISO 15118-20.

[0107] Both figures illustrate this flow with the entities as described above together with the two charging controllers at the vehicle (EVCC) and the charging station (SECC). The start of the process is the same for both and begins with the open payment service discovery, which may be followed by a negotiation step to determine an external payment method - for example, the vehicle may have a stored hierarchy of payment option preferences, and this can be used to determine which option is to be followed if multiple options are available. After this, the application selection process takes place as discussed above.

[0108] Separately, there is an ISO 15118-2 / 20 process with different steps providing the preparation for the session and for payment. It starts with an SECC discovery protocol, to allocate a TCP port, a handshake sequence to establish the version of the charging protocol (ISO 15118-2 or ISO 15118-20), and session establishment.

[0109] If ISO 15118-2 is the selected charging protocol, as indicated in Figure 9, service discovery starts, and “External payment” can be offered (by the SE) and selected (by the EV) as alternative to “Contract”.

[0110] If ISO 15118-20 is the selected charging protocol, as indicated in Figure 10, payment authorization starts, and “External Identification Mode” (EIM) can be offered (by the SE) and selected (by the EV) as alternative to “Plug-and- charge” (PnC).

[0111] Up until this point, the ISO 15118 process and the open payment process run independently of each other, and the relative ordering of ISO 15118 and open payment steps is not significant - this selection step is however the “choke point” at which the ISO 15118 process and the open payment process need to be aligned.

[0112] For ISO 15118-2, as indicated in Figure 9, this selection will be of “External Payment” if open payment is to be used. This is followed by the payment authorization process for open payment as described above, which produces a “payment authorized” result that can be fed into the ISO 15118-2 process to indicate that “External Payment” has been successful. Features relating to conventional Plug and Charge can be ignored, and on session end the open payment close down is followed by an ISO 15118-2 session termination.

[0113] Figure 10 illustrates a similar flow integration between open payment and the ISO 15118-20 messaging flow. Steps are essentially the same in most cases, with some variation at the authorization stage, where the “choke point” involves slightly different messaging. Instead of service discovery and selection, ISO 15118- 20 has a process of determining authorization for payment - which here will involve selection of EIM - once the session has been established. After this, payment authorization takes place for open payment as before, and the steps followed are essentially as for Figure 9 until the end of the messaging flow.

[0114] Further modifications may be made to the above examples without departing from the scope of the present disclosure as defined in the accompanying claims.

Claims

CLAIMS1. A method of payment for charging of a battery of a vehicle, the method comprising: establishing a charging connection between a charging station and a vehicle; establishing a first communication channel between a vehicle charging controller and a charging station charging controller over the charging connection; establishing a second communication channel between a payment controller in the vehicle and an access controller in the charging station over the charging connection; establishing a payment transaction for authorization between the payment controller acting as a card-based payment device and the access controller acting as a payment terminal over the second communication channel; and the access controller providing the established payment transaction for authorization through a payment network.

2. The method of claim 1, wherein the first communication channel between the vehicle charging controller and the charging station charging controller is established in accordance with an ISO 15118 standard.

3. The method of claim 1 or claim 2, wherein the first communication channel and the second communication channel share one or more networking layers of a networking connection.

4. The method of claim 3, wherein the first and second communication channels share at least a physical layer and a data link layer.

5. The method of claim 3, wherein the first and second communication channels share all networking layers other than an application layer.

6. The method of claim 4, wherein the first and second communication channels have separate TLS / TCP channels at the transport layer.

7. The method of claim 4 or claim 6, wherein the method further comprises a service discovery process before establishing the second communication channel to determine that card-based payment is supported.

8. The method of claim 7, wherein the service discovery process is a DNS service discovery process.

9. The method of any preceding claim, wherein in establishing a payment transaction for authorization, a first payment authorization flow is conducted between the vehicle charging controller and the charging station charging controller and a second payment authorization flow is conducted between the payment controller and the access controller.

10. The method of claim 9, wherein for authorization of the payment transaction, the second payment authorization flow establishes that payment parameters for an authorizable card payment are present, whereupon the first payment authorization flow is adapted to select card-based payment as an authorization option for payment.

11. The method of any preceding claim, wherein establishing a payment transaction for authorization between the payment controller and the access controller uses EMV transaction flows or data objects.

12. The method of claim 11, wherein interaction between the payment controller and the access controller is according to a client-server model, where the access controller acts as the server and the payment controller acts as the client.

13. The method of claim 11 or claim 12, wherein establishing the payment transaction for authorization uses contactless EMV transaction flows or data objects.

14. The method of any of claims 11 to 13, wherein establishing the payment transaction for authorization comprises the payment controller generating an application cryptogram.

15. The method of any of claims 11 to 14, wherein establishing the payment transaction for authorisation comprises performing cardholder verification, and wherein cardholder verification comprises performing a process also used to verify the cardholder to the vehicle.

16. A charging station for charging an electric vehicle, the charging station comprising: a charging means adapted to establish a charging connection with a vehicle; a charging station charging controller adapted to communicate with a vehicle charging controller of the vehicle to control a charging operation; an access controller adapted to act as a payment terminal to establish a payment transaction for authorization with a payment controller of the vehicle using card-based payment’ and wherein the access controller is configured to provide the established transaction to the acquirer for authorization; wherein the charging station charging controller communicates with the vehicle charging controller over a first communication channel and the access controller communicates with the payment controller over a second communication channel, wherein the charging station is adapted to establish both the first communication channel and the second communication channel over the charging connection17. The charging station of claim 16, wherein the charging connection is wired or wireless.

18. The charging station of claim 16 or claim 17, wherein the charging station charging controller is adapted to establish the first communication channel to the vehicle charging controller in accordance with an ISO 15118 standard.

19. The charging station of any of claims 16 to 18, wherein the charging station is adapted such that the first communication channel and the second communication channel share one or more networking layers of a networking connection.

20. The charging station of claim 19, wherein the charging station is adapted such that the first and second communication channels share at least a physical layer and a data link layer.

21. The charging station of claim 20, wherein the charging station is adapted such that the first and second communication channels have separate TLS / TCP channels at the transport layer.

22. The charging station of any of claims 16 to 21, wherein the charging station is adapted to support a first payment authorization flow between the vehicle charging controller and the charging station charging controller and a second payment authorization flow between the payment controller and the access controller.

23. The charging station of claim 22, wherein for authorization of the payment transaction, the second payment authorization flow establishes that payment parameters for an authorizable card payment are present, whereupon the first payment authorization flow is adapted to select card-based payment as an authorization option for payment.

24. The charging station of any of claims 16 to 21, wherein establishing a transaction for authorization between the payment controller and the access controller uses EMV transaction flows or data objects.

25. The charging station of claim 24, wherein the access controller is adapted for interaction with the payment controller according to a client-server model, where the access controller acts as the server and the payment controller acts as the client.

26. An electric vehicle, the electric vehicle comprising:a charging system for a battery of the electric vehicle, wherein the charging system is adapted to establish a charging connection with a charging station; a vehicle charging controller adapted to communicate with a charging station charging controller of the charging station to control a charging operation; a payment controller in the vehicle adapted to act as a card-based payment device to establish a transaction for authorization with the access controller acting as a payment terminal and to provide the established transaction to the access controller for authorization through a payment network; wherein the vehicle charging controller communicates with the charging station charging controller over a first communication channel and the payment controller communicates with the access controller over a second communication channel, wherein the electric vehicle is adapted to establish both the first communication channel and the second communication channel over the charging connection.

27. The electric vehicle of claim 26, wherein the vehicle charging controller is adapted to establish the first communication channel in accordance with an ISO 15118 standard.

28. The electric vehicle of claim 26 or claim 27, wherein the electric vehicle is adapted such that the first communication channel and the second communication channel share one or more networking layers of a networking connection.

29. The electric vehicle of claim 28, wherein the electric vehicle is adapted such that the first and second communication channels share at least a physical layer and a data link layer.

30. The electric vehicle of claim 29, wherein the electric vehicle is adapted such that the first and second communication channels have separate TLS / TCP channels at the transport layer.

31. The electric vehicle of any of claims 26 to 30, wherein the electric vehicle is adapted to support a first payment authorization flow between thevehicle charging controller and the charging station charging controller and a second payment authorization flow between the payment controller and the access controller.

32. The electric vehicle of claim 31, wherein for authorization of the payment transaction, the second payment authorization flow establishes that payment parameters for an authorizable card payment are present, whereupon the first payment authorization flow is adapted to select card-based payment as an authorization option for payment.

33. The electric vehicle of any of claims 26 to 32, wherein establishing a transaction for authorization between the payment controller and the access controller uses EMV transaction flows or data objects.

34. The electric vehicle of claim 33, wherein the payment controller is adapted for interaction with the access controller according to a clientserver model, where the access controller acts as the server and the payment controller acts as the client.

35. The electric vehicle of claim 33 or claim 34, wherein the payment controller is adapted to generate an application cryptogram to establish a transaction for authorization.

36. The electric vehicle of claim 35, wherein the electric vehicle has a driver verification means, wherein the driver verification means is also adapted to perform cardholder verification.

37. The electric vehicle of any of claims 26 to 36, wherein the electric vehicle is a battery electric vehicle or a plug-in hybrid electric vehicle.

Images