Method and apparatus for supporting installation of a contract certificate for an electric vehicle

Abstract

This disclosure provides a method for installing a contract certificate supported by a charging service provider device. As an example, this disclosure may include the steps of: generating a first contract certificate for a first electric vehicle (EV); and transmitting the first contract certificate to a first external charging service provider device (CSP) with which a roaming contract has been established, so that the first contract certificate can be installed in the first EV via the first external CSP in the event of roaming.

Description

Technical Field

[0001] This disclosure relates to charging methods and apparatus for electric vehicles. More specifically, this disclosure relates to methods and apparatus for installing public key certificates in electric vehicles to accommodate roaming environments in PnC-based charging infrastructures. Background Technology

[0002] Electric vehicles (EVs) are powered by electric motors powered by batteries, offering advantages over traditional internal combustion engine vehicles, such as reduced emissions and noise, fewer malfunctions, longer lifespan, and simpler operation. An EV charging system can be defined as a system that charges the batteries installed in an EV using electricity obtained from the commercial power grid or stored in energy storage devices. Such EV charging systems can be implemented in various forms. For example, EV charging systems can include conductive charging systems using cables or contactless wireless power transmission systems.

[0003] Charging stations begin charging EVs after the certification process is completed. However, the certification process varies depending on the EV's charging infrastructure and capabilities. As one of the international standards for EV charging, ISO 15118-1 specifies two certification methods: the PnC mechanism, which allows for automated certification and payment using a contract certificate stored in the EV; and certification using external identification methods (EIM), such as credit cards, debit cards, cash, and smartphone applications. The PnC mechanism refers to a plug-and-charge solution where certification and charging are performed simply by inserting a plug between the EV and the charging station, while the parking charging solution refers to a parking charging solution where certification and charging are performed simply by parking the vehicle at a charging point within the station.

[0004] To use PnC (Point of Charge) services in an EV, the EV owner must enter into a service contract with a mobile operator (MO). Once the contract is signed, a contract certificate is installed in the EV during the first charge. Afterward, the EV can receive PnC-based charging services from charging stations associated with the MO. Roaming may occur if the EV receives PnC-based charging services from a charging station associated with a different MO with whom it has no contractual relationship. As long as a valid contract certificate is installed in the EV, EV owners face minimal difficulties using charging services in roaming environments.

[0005] However, the PnC mechanism may not work if the EV accessing the charging station does not have a valid contract certificate. This could happen, for example, if the first charging station the EV accesses after delivery belongs to an MO network with which the EV has no contractual relationship. Furthermore, the PnC mechanism may fail to function if the contract certificate installed in the EV malfunctions for some reason and needs to be renewed. Therefore, situations may arise where contract certificates need to be installed or renewed in roaming environments, but traditional charging systems may not have a solution to this problem. Consequently, when the PnC mechanism fails to function as described above, the EV driver must pay the charging fee through the EIM (Electronic Instruction Center), which is both inconvenient and troublesome for the EV driver.

[0006] Meanwhile, according to the traditional PnC mechanism, the charging station operator (CSO) or charging service provider (CSP) verifies the contract certificate chain submitted by the EV to the CSO via the charging station. However, because the EV is not equipped with an MO RootCA certificate, which is the highest-level certificate in the contract certificate chain (based on the ISO 15118-20 standard of July 2, 2018), the EV cannot submit an MO RootCA certificate to the interviewed CSO. If neither the interviewed CSO nor the interviewed CSP has this RootCA certificate, verification can only be performed at the home CSP or a separate clearinghouse, which may result in verification delays. Summary of the Invention

[0007] Technical issues

[0008] This disclosure provides methods and apparatus that enable the installation or renewal of contract certificates in EVs in roaming environments and facilitate accurate and rapid certification required for PnC-based charging.

[0009] Technical solutions

[0010] According to one aspect of this disclosure, a method is provided to support the installation of a contract certificate in a charging service provider device. The method includes: generating a first contract certificate for a first electric vehicle (EV); and transmitting the first contract certificate to a first external charging service provider device (CSP) with which a roaming contract has been established, so that the first contract certificate can be installed in the first EV via the first external CSP in roaming situations.

[0011] The first external CSP may include all external CSPs that have corresponding roaming contracts with the charging service provider equipment.

[0012] The first external CSP can include all external CSPs.

[0013] The method may further include sending a request to the first external CSP to release the installation backup when a predetermined time has elapsed after the first contract certificate has been transferred to the first external CSP, or when the first contract certificate is installed in the first EV.

[0014] The operation of transferring the first contract certificate to the first external CSP may include: creating a certificate installation package that includes a contract certificate chain and eMAID information, the contract certificate chain including the first contract certificate; and transferring the certificate installation package to the first CSP.

[0015] The certificate installation package may include a certificate revocation list associated with the first contract certificate and access information to the Online Certificate Status Protocol (OCSP) server.

[0016] The method may further include: receiving a second contract certificate of the second EV from a second external CSP and forwarding the second contract certificate to a certificate provisioning service device (CPS) to enable the CPS to store the second contract certificate; and when a contract certificate installation request is received from the second EV while the second EV is roaming in the service network of the charging service provider device, causing the second contract certificate stored in the CPS to be transferred to the second EV and installed in the second EV.

[0017] The second external CSP can be one of all external CSPs that have a corresponding roaming contract with the charging service provider equipment.

[0018] The operation of transferring and installing the second contract certificate to the second EV may include: after the second contract certificate is installed in the second EV, notifying the second external CSP that the installation is complete.

[0019] According to one aspect of this disclosure, a charging service providing device is provided for use in a PnC-based charging service. The charging service providing device includes: a processor; and a memory storing at least one program instruction to be executed by the processor. When the processor executes the at least one program instruction, it causes the processor to: generate a first contract certificate for a first electric vehicle (EV) and transmit the first contract certificate to a first external charging service providing device (CSP) so that the first contract certificate can be installed in the first EV via the first external CSP; receive a second contract certificate for a second EV from a second external CSP and forward the second contract certificate to a certificate supply service device (CPS) so that the CPS can store the second contract certificate; and when a contract certificate installation request is received from the second EV while the second EV is roaming within the service network of the charging service providing device, it causes the second contract certificate stored in the CPS to be transmitted to the second EV and installed in the second EV.

[0020] The first external CSP may include all external CSPs that have a corresponding roaming contract with the charging service provider device, and the second external CSP may be one of all external CSPs that have a corresponding roaming contract with the charging service provider device.

[0021] The first external CSP can include all external CSPs, and the second external CSP can be one of all external CSPs.

[0022] The program instructions that cause the processor to generate a first contract certificate for the first EV and transmit the first contract certificate to the first external CSP may include causing the processor to execute the following program instructions: after a predetermined time has elapsed after the transmission of the first contract certificate, or when the first contract certificate is installed on the first EV, sending a request to the first external CSP to release the installation backup.

[0023] The program instructions that cause the processor to execute the transfer of the second contract certificate to the second EV and its installation in the second EV may include the following program instructions that cause the processor to execute the following: after the second contract certificate is installed in the second EV, notify the second external CSP that the installation is complete.

[0024] The program instructions that cause the processor to transfer the first contract certificate to the first external CSP may include causing the processor to execute the following program instructions: creating a certificate installation package including a contract certificate chain and eMAID information, the contract certificate chain including the first contract certificate; and transferring the certificate installation package to the first CSP.

[0025] The certificate installation package may include a certificate revocation list associated with the first contract certificate and access information to the Online Certificate Status Protocol (OCSP) server.

[0026] According to another aspect of this disclosure, a method for authorizing charging of an electric vehicle (EV) in a roaming environment based on Certificate of Charge (PnC) authorization is provided. The method includes: generating a first contract certificate for a first electric vehicle (EV) to transmit the first contract certificate to a first external charging service provider (CSP), thereby enabling the first contract certificate to be installed in the first EV via the first external CSP; receiving a second contract certificate for a second EV from a second external CSP to forward the second contract certificate to a Certificate of Charge Provider (CPS), thereby enabling the CPS to store the second contract certificate; and when a contract certificate installation request is received from the second EV while the second EV is roaming within the service network of the charging service provider, transmitting the second contract certificate stored in the CPS to the second EV and installing it in the second EV; and authorizing charging of the second EV based on the condition that the second contract certificate is installed in the second EV when the second EV issues an authorization request.

[0027] The second external CSP can be one of all external CSPs that have a corresponding roaming contract with the charging service provider equipment.

[0028] The process of transferring and installing the second contract certificate to the second EV may include: after the second contract certificate is installed in the second EV, notifying the second external CSP that the installation is complete.

[0029] The operation of receiving a second contract certificate from a second external CSP to store the second contract certificate may include: receiving a certificate installation package including a contract certificate chain and eMAID information, wherein the contract certificate chain includes the second contract certificate.

[0030] Beneficial effects

[0031] According to exemplary embodiments of this disclosure, the home CSP distributes the EV's contract certificate to virtually all CSPs in preparation for certificate installation or renewal requests from the EV. Therefore, even in roaming environments, the visited CSP can respond to certificate installation or renewal requests and immediately provide the contract certificate to the EV, facilitating its installation or renewal within the EV. Thus, exemplary embodiments of this disclosure enable the installation or renewal of contract certificates in EVs within roaming environments, which facilitates PnC-based charging of the EV and improves convenience for EV users.

[0032] On the other hand, since various certificates other than contract certificates can be installed in the surveyed CSPs, surveyed CSOs and their associated charging stations, the responsiveness of each entity can be improved and flexibility can be provided for the EV licensing process. Attached Figure Description

[0033] Figure 1 This is a conceptual diagram illustrating an EV conductive charging system to which exemplary embodiments of the present disclosure can be applied;

[0034] Figure 2 This is a conceptual diagram illustrating a wireless power transfer (WPT) system to which exemplary embodiments of the present disclosure may be applied;

[0035] Figure 3 This is a block diagram of an EV charging infrastructure according to exemplary embodiments of the present disclosure;

[0036] Figure 4 An example of a PKI-based certificate hierarchy applicable to exemplary embodiments of this disclosure is shown;

[0037] Figure 5 An example is shown of a node that constitutes a PnC charging infrastructure that supports roaming services for EVs;

[0038] Figure 6Examples of scenarios where roaming is not required and scenarios where roaming is required are shown;

[0039] Figure 7 This is a sequence diagram illustrating the general service authorization process under a contract when roaming is not required;

[0040] Figure 8 This is a sequence diagram illustrating the general service authorization process under a contract in the event of direct roaming;

[0041] Figure 9 This is a sequence diagram illustrating the general service authorization process under a contract in the event of indirect roaming;

[0042] Figure 10 This is a sequence diagram illustrating the general service authorization process under a contract in the event of immediate direct roaming;

[0043] Figure 11 This is a sequence diagram illustrating the general service authorization process under a contract in the event of immediate indirect roaming;

[0044] Figure 12 The delivery path of a contract certificate from the home CSP to the EV via direct roaming, according to an exemplary embodiment of this disclosure, is shown.

[0045] Figure 13 To show in more detail Figure 12 The sequence diagram shown illustrates the certificate delivery process;

[0046] Figure 14 The delivery path of a contract certificate from the home CSP to the EV via indirect roaming, according to an exemplary embodiment of this disclosure, is illustrated.

[0047] Figure 15 To show in more detail Figure 14 The diagram shows the sequence of the certificate delivery process.

[0048] Figure 16 This is a sequence diagram illustrating a service authorization process under a contract according to exemplary embodiments of the present disclosure; and

[0049] Figure 17 This is a block diagram of CSP 220 according to an exemplary embodiment of the present disclosure. Detailed Implementation

[0050] To better understand the features and advantages of this disclosure, exemplary embodiments of the disclosure will be described in detail with reference to the accompanying drawings. However, it should be understood that this disclosure is not limited to the specific embodiments and includes all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure. Similar reference numerals are used for similar components in the description of each drawing.

[0051] The terms specified in this specification, including ordinal numbers (e.g., "first" and "second"), used to explain various components are used to distinguish components from other components, but are not intended to imply limitation to any particular component. For example, a second component may be referred to as a first component, and similarly, a first component may be referred to as a second component, without departing from the scope of this disclosure. The expression "and / or" may be used to indicate a combination of multiple list items or any one of multiple list items.

[0052] When a component is described as "connected" or "coupled" to another component, that component may be directly connected or logically or physically coupled to the other component, or indirectly connected or coupled to the other component through an intervening object. Conversely, when a component is described as "directly connected" or "directly coupled" to another component, it should be understood that there is no intervening object between the components.

[0053] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well. It will be further understood that when the terms “comprising” and / or “including” are used in this specification, they specify the presence of a feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0054] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. Terms such as those defined in common dictionaries should be interpreted as having a meaning consistent with their meaning in the relevant technical context, and should not be interpreted as having an ideal or overly formal meaning unless expressly defined in this application.

[0055] The terms used in this disclosure are defined as follows.

[0056] "Electric Vehicle (EV)": As defined in 49 CFR 523.3, an on-road motor driven by an electric motor that draws current from an onboard energy storage device (such as a battery) that can be charged from a non-vehicle power source (such as a residential or public power service or an onboard fuel generator). EVs can be four-wheeled or more vehicles primarily used on public streets or roads. EVs can include electric vehicles, electric motor vehicles, electric road vehicles (ERVs), plug-in electric vehicles (PVs), plug-in electric vehicles (xEVs), etc., and xEVs can be further categorized into plug-in fully electric vehicles (BEVs), battery electric vehicles, plug-in electric vehicles (PEVs), hybrid electric vehicles (HEVs), hybrid plug-in electric vehicles (HPEVs), plug-in hybrid electric vehicles (PHEVs), etc.

[0057] “Plug-in electric vehicle (PEV)”: An electric vehicle that recharges its main battery by connecting to the power grid.

[0058] "Wireless Charging System (WCS)": A system for wireless power transmission and interactive control, including alignment and communication operations between the ground component (GA) and the vehicle component (VA).

[0059] "Wireless Power Transfer (WPT)": Transferring power between power sources (such as power companies and the grid) and EVs via a contactless channel.

[0060] "Power company": A set of systems that provide electrical energy, including a Customer Information System (CIS), Advanced Metering Infrastructure (AMI), rate and revenue systems, etc. The power company can supply energy to EVs based on rate schedules and discrete events. In addition, the power company can provide information related to EV certification, power consumption measurement intervals, and electricity pricing.

[0061] "Smart charging": A system that communicates between the electric vehicle power supply equipment (EVSE) and / or the PEV and the power grid to optimize the charging or discharging rate of the EV by taking into account the grid's allowable capacity or electricity price.

[0062] "Interoperability": The state in which components of a system interact with corresponding components of the system to perform system-target operations. Furthermore, information interoperability can refer to the ability of two or more networks, systems, devices, applications, or components to effectively share and easily use information without causing inconvenience to users.

[0063] "Conductive charging system": A system that transfers energy from a power source to an EV via a two-part gap-core transformer, wherein the two halves of the transformer, namely the primary and secondary coils, are physically separated from each other. In this disclosure, the conductive charging system may correspond to an EV power transmission system.

[0064] "Inductive coupling": Magnetic coupling between two coils. One of the two coils can be called the Ground Component (GA) coil, and the other can be called the Vehicle Component (VA) coil.

[0065] "Original Equipment Manufacturer (OEM)": A server operated by the manufacturer that produces EVs, which may refer to the root certification authority (RootCA) that issues the OEMRootCA certificate.

[0066] "Mobile Operator (MO)": A service provider that enters into a service contract with EV owners related to EV operation (such as charging, licensing and billing) to enable EV drivers to charge their EVs at charging stations.

[0067] “Charging station (CS)”: A facility equipped with one or more EV power supply units (EVSE) and used for the physical charging of EVs.

[0068] "Charging Station Operator (CSO)": A party responsible for supplying and operating charging infrastructure and managing electricity to provide the required energy transmission services. The term "charging station operator" can be synonymous with "charging point operator (CPO)."

[0069] "Charging Service Provider (CSP)": An entity that manages and verifies EV user credentials and provides billing and other value-added services to customers. A CSP can be considered a special type of Mobile Operator (MO) and can be integrated with an MO.

[0070] "Clearing House (CH)": An entity that handles collaborations between MOs, CSPs, and CSOs. In particular, the clearing house can act as an intermediary participant, facilitating the authorization, billing, and clearing procedures for EV charging service roaming between two clearing parties.

[0071] "Roaming": Information changes, plans, and supplies between CSPs allow EV users to access charging services provided by multiple CSPs or CSOs belonging to multiple eMobile networks using a single credential and contract.

[0072] "Certificate": A physical or digital asset that represents the identity of an EV or its owner, which may include a password used to verify identity, a public and private key pair used in a public-key encryption algorithm, a public key certificate issued by a certificate authority, and information related to a trusted root certificate authority.

[0073] "Certificate": An electronic document that binds a public key to an ID using a digital signature.

[0074] "Service Session": A set of services related to EV charging around a charging point, assigned to a specific customer for a specific time period with a unique identifier.

[0075] "Electronic Mobile Account Identifier (eMAID)": A unique identifier for the EV that links the EV's contract certificate to the EV owner's payment account.

[0076] Exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0077] In the electric vehicle charging system used to implement this disclosure, an electric vehicle (EV) can be connected to a charging station via a wired or wireless link to receive energy from the charging station and use the provided energy to charge an energy storage device (e.g., a battery). Figure 1 and Figure 2 Methods for charging electric vehicles by conductive charging and wireless power transmission are shown respectively.

[0078] Figure 1This is a conceptual diagram illustrating a conductive charging system for an electric vehicle to which exemplary embodiments of the present disclosure may be applied. Conductive charging of the electric vehicle can be performed by connecting the electric vehicle (hereinafter referred to as "EV") to the power supply circuit of the charging station via a charging cable 30, for example by connecting the cable connector of the charging station 20 to the socket of the EV 10.

[0079] EV 10 is generally defined as a car driven by an electric motor powered by a rechargeable energy storage device (such as a battery) mounted on the EV 10. EV 10 can also be a hybrid electric vehicle (HEV) with both an electric motor and an internal combustion engine. Furthermore, EV 10 is not limited to cars; it can also be a motorcycle, handcart, scooter, or electric bicycle.

[0080] EV 10 may include a plug or socket that can be coupled to a connector of charging cable 30. The plug provided in EV 10 may support slow charging or fast charging. Here, EV 10 may include a single plug that supports both slow charging and fast charging, or multiple plugs that support both slow charging and fast charging respectively.

[0081] The EV 10 may also include an onboard charger to support slow charging or charging using AC power supplied from the grid. The onboard charger can boost the AC power level from the grid and convert it to DC power to provide DC power to the EV 10's battery during slow charging. Conversely, if DC power is supplied to the EV 10's outlet for fast charging, DC power can be provided to the battery without the need for an onboard charger.

[0082] The EV charging cable 30 may include at least one of a charging plug 31, an on-cable control box (in-cable control box, ICCB) 32, and a wall plug 33. The charging plug 31 may be a connection component that can be electrically connected to a socket of the EV 10. The ICCB 32 may communicate with the EV 10 to receive EV status information or control the charging of the EV 10. Although the ICCB 32 is shown as being included in the EV charging cable 30, the ICCB 32 may be installed in a location other than the EV charging cable 30, for example, installed in the power supply circuit of a charging station, or may be connected to a power supply circuit. The wall plug 33 may include an electrical connection component, such as a universal plug or wire assembly, and allows the charging cable 30 to be connected to a wall socket or a socket of a charging station to receive power.

[0083] Meanwhile, the wall socket 40 can refer to the connection point between the charging pile and the charging connector 31 of the charging station. However, this disclosure is not limited to this; the wall socket 40 can refer to another connection point between the charging equipment installed in another location and the charging connector 31. For example, the wall socket 40 can be installed in commercial dedicated charging station facilities and various other locations, such as the parking lot of an EV owner's home, the parking lot allocated for EV charging at a gas station, or the parking lot of a shopping mall or office building.

[0084] Figure 2 This is a conceptual diagram illustrating a wireless power transfer (WPT) system to which exemplary embodiments of the present disclosure may be applied.

[0085] Wireless power transfer (WPT) of an EV can be defined as the transfer of electrical energy from a supplier device to a consumer device via a magnetic field under magnetic resonance conditions without the flow of current through a current connection. By transferring power from charging station 20 to EV 10, wireless power transfer can be used to charge EV 10.

[0086] like Figure 2 As shown, WPT can be performed by at least one component of EV 10 and charging station 20, and can transfer power to EV 10 without any wires.

[0087] EV 10 may include a power receiving pad 11 having a receiving coil suitable for wirelessly receiving magnetic energy from charging station 20. The receiving coil at power receiving pad 11 receives magnetic energy from the transmitting coil of power transmitting pad 21 at charging station 20, for example, via magnetic resonance. The magnetic energy received by EV 10 is converted into an induced current, which is rectified into a DC current to charge battery 12.

[0088] Charging station 20 can receive power from the power grid 50 or the power backbone and supply energy to EV 10 via power transmission pad 21. Power transmission pad 21 has transmission coils that generate magnetic flux and supply magnetic energy to EV 10 through magnetic resonance amplification. Charging station 20 can be located in various places, such as the parking lot of an EV owner's home, the parking lot of a gas station designated for EV charging, and the parking area of ​​a shopping mall or office building.

[0089] Charging station 20 can communicate with the power infrastructure management system or the infrastructure server managing the power grid 50 via wired or wireless communication. Furthermore, charging station 20 can wirelessly communicate with EV 10. In this document, wireless communication may include wireless LAN (WLAN) based on the IEEE 802.11 protocol (Wi-Fi) or P2PS communication using low-frequency (LF) magnetic field signals and / or low-power excitation (LPE) magnetic field signals. Additionally, wireless communication between charging station 20 and EV 10 may include one or more of various communication schemes, such as Bluetooth, Zigbee, and cellular communication.

[0090] Meanwhile, according to the ISO 15118 industry standard, which serves as the communication standard for EV charging, the EV and the charging station can exchange messages to control the entire charging process. In other words, communication for EV charging can be performed between the EV Communication Controller (EVCC) and the Power Supply Equipment Communication Controller (SECC) via a wireless local area network.

[0091] During communication, the EV first authenticates the charging station to ensure its reliability and establishes a secure channel with it to protect communication from unauthorized access. These operations can be implemented according to the standard Transport Layer Security (TLS) protocol defined in RFC 5246, developed by the Internet Engineering Task Force (IETF) TLS Working Group. After establishing an IP-based communication connection, a TLS session can be established using the TLS session establishment process.

[0092] Figure 3 This is a block diagram of an EV charging infrastructure according to exemplary embodiments of the present disclosure.

[0093] The EV charging infrastructure that provides charging services for EV 10 includes Original Equipment Manufacturer (OEM) server 100, Mobile Operator (MO) 110, Certificate Supply Service (CPS) 120, Contract Certificate Pool (CCP) 130, Vehicle-to-Ground (V2G) server 150, Charging Station (CS) 200, Charging Station Operator (CSO) 210, Charging Service Provider (CSP) 220, and Clearing House (CH) 230.

[0094] EV 10 refers to a regular vehicle owned by an EV owner that can be charged via conductive charging at a charging station or wireless power transfer. EV 10s are manufactured with an OEM supply certificate. Contract certificates can be installed in EV 10s after the completion of the procurement contract and the contract with the MO 110 operator. Additionally, a vehicle-to-ground (V2G) RootCA certificate can be installed in EV 10s.

[0095] The Original Equipment Manufacturer (OEM) server (100, hereinafter referred to as "OEM") is the Root Certificate Authority (RootCA), responsible for issuing the OEM RootCA certificate and operating the SubCAs, namely OEM SubCA1 and OEM SubCA2. When the EV 10 is being manufactured, OEM 100 uses the OEM SubCA certificate (i.e., the OEM SubCA 2 certificate) to issue the OEM supply certificate for installation in the EV 10.

[0096] The Mobile Operator (MO) 110 is a service provider with which EV owners enter into service contracts related to EV operation, such as charging, authorization, and billing, to enable EV drivers to charge their EVs at charging stations. For an EV to receive charging services from a charging station, the charging station must belong to an MO, or the charging infrastructure must support roaming scenarios. The MO 110 can be operated by an electricity supplier or electricity retailer. The MO 110 also acts as the RootCA issuing MO RootCA certificates. When issuing contract certificates, an MO certificate chain consisting of the MO RootCA certificate and MO SubCA certificates issued by MO SubCAs can be used. Furthermore, according to this disclosure, the MO certificate chain is also used to authenticate contract certificates installed in the EV 10 in both non-roaming and roaming environments. The MO can also be referred to as an "Electronic Mobility Service Provider (EMSP)".

[0097] The Certificate Provisioning Service (CPS) 120 provides clients such as EVs with a chain of contract certificate credentials and cryptographic keys for transmitting or receiving certificates during the installation or renewal of contract certificates within the EV. The CPS 120 is equipped with leaf certificate provisioning and SubCA certificate provisioning, such as Prov SubCA 1 and Prov SubCA 2 certificates. When a contract certificate is installed or renewed in an EV 10, the CPS 120 provides the provisioning service to the EV, offering the public key for each MO, the Diffie-Hellman (DH) public key, the eMAID, and the contract certificate chain, so that the EV can verify the contract certificate chain and use this data to verify the integrity and authenticity of the contract certificate.

[0098] During the installation or renewal of contract certificates in an EV, the Contract Certificate Pool (CCP) 130 temporarily stores response messages used for the installation or renewal. Given the very short and strict time constraints set for installation or renewal in the ISO 15118 standard, response messages are pre-stored in the CCP 130 and retained until the installation or renewal is complete. Since there may be multiple EVs performing contract certificate installation or renewal, response messages are maintained in a directory after metrics are assigned to each message.

[0099] The vehicle-to-ground (V2G) server 150 (hereinafter referred to as "V2G") acts as the root CA in the public key infrastructure (PKI) of the EV charging infrastructure. Therefore, V2G 150 acts as the highest trust anchor, and Figure 3 All participants shown consider V2GRootCA as a trusted participant.

[0100] Charging station (CS) 200 is actually used to charge EV 10. Charging station 200 may include at least one conductive charger and / or wireless charging point. One or more charging stations 200 may be installed in dedicated commercial charging areas. Furthermore, charging station 200 can be located in various places, such as the parking lot of an EV owner's home, parking lots allocated for EV charging at gas stations, and parking areas in shopping malls or office buildings. Charging station 200 may also be referred to as a "charging point," "EV charging station," "electric charging point," "electronic charging station (ECS)," or "EV power supply equipment (EVSE)."

[0101] A Charge Station Operator (CSO) 210 or Charge Point Operator (CPO) provides and operates charging stations and manages electricity to provide the required energy transfer services. For example, a CSO 210 can be operated by a charging station manufacturer or an electricity supplier. Regarding PKI, a CSO 210 operates a CPO SubCA, such as the CPO SubCA1 and CPOSubCA2 required to issue SECC leaf certificates for each charging station.

[0102] Charging Service Provider (CSP) 220 manages and authenticates EV user credentials and provides billing and other value-added services to customers. CSP 220 can be considered a special type of MO 110 and can be implemented using MO 110. Multiple CSPs 220 can exist. In this case, each CSP 220 can be associated with one or more CSOs 210, such that the CSP 220 and one or more CSOs 210 constitute a charging network. EV 10 can receive charging services from a CSO 210 associated with a CSP 220 using a plug-and-play or park-and-play (PnC) method, which is again associated with an MO 110 in a contractual relationship with EV 10. However, when EV 10 needs to roam from another CSO 210 that is not associated with CSP 220, CSP 220 is again associated with an MO 110 in a contractual relationship with EV 10. Each CSP 220 can exchange information with another CSP or CSO 210 belonging to another charging network, and can also exchange information with the clearinghouse 230 to enable roaming.

[0103] The Clearing House (CH) 230 handles the cooperation between MO 110 and CSP 220. That is, Clearing House 230 can act as an intermediary, facilitating the authorization, billing, and clearing processes for EV charging service roaming between the two clearing parties. When an EV driver wishes to charge their EV at a charging station not belonging to the charging network of MO 110, with which they have a contractual relationship, CH 230 can connect to CSO 210 or CSP 220 to facilitate roaming. In cases requiring roaming, CH 230 enables CSO 210 or CSP 220 to contract with MO 110 and transfer authorization data and Charging Details Record (CDR) to MO 110. CH 230 may also be referred to as a “Contract Clearing House (CCH)”, “Mobile Clearing House (MCH)”, “Roaming Platform”, or “Electronic Mobile Clearing House (e-MOCH)”.

[0104] While terms such as “Cyber ​​Service Operator (CSO),” “Certificate Supply Service (CPS),” “Mobile Operator (MO),” “Contract Clearing House (CCH),” and “V2G” may seem to refer to individuals or organizations, these terms, as used herein including the claims, are merely functional abbreviations for readability and can be implemented in hardware, software, and / or combinations thereof. In exemplary embodiments, these components may be server devices implemented by a combination of hardware and software, allowing access to other devices via a network such as the Internet. Because these components are functionally separate, two or more of these components may be stored and executed in a single physical device or may be integrated into a single program. In particular, one entity may act as both a CSO and a CSP, and another entity may act as both a CPS and a CCP. Furthermore, one or more components may be rearranged to have different appearances and names.

[0105] On the other hand, EV charging services and related infrastructure exist at the intersection of various industrial sectors such as automobiles, power grids, energy, transportation, communications, finance, and electronics. Standardization is being pursued in parallel by multiple entities, including international and national standardization organizations, each with its own perspective. Consequently, many terms containing similar concepts exist. Specifically, charging station operators (CSOs) and charging point operators (CPOs) share common roles and functions, although some functional differences and nuances may exist; they may refer to essentially the same entity. Furthermore, charging service providers (CSPs) are at least partially identical to mobile operators (MOs) in their roles and functions, and these terms are interchangeable. These considerations should be taken into account when interpreting this specification, including the claims.

[0106] exist Figure 3In the EV charging infrastructure shown, Public Key Infrastructure (PKI) serves as the foundation for PnC operations. PKI provides a framework for verifying the identity of individuals and devices, activating confidential communications, and ensuring controlled access to resources. Figure 4 An example of a PKI-based certificate hierarchy applicable to exemplary embodiments of this disclosure is shown. The certificate hierarchy shown in the accompanying drawings is specified in the ISO 15118 standard.

[0107] refer to Figure 4 OEM 100 acts as the RootCA issuing the OEM RootCA certificate and also operates the SubCAs, namely OEMSubCA1 and OEM SubCA2. Therefore, OEM 100 issues the OEM RootCA certificate, as well as the OEM SubCA1 and OEM SubCA2 certificates, by signing with its own private key. During EV manufacturing, OEM SubCA2 uses a private key paired with the public key contained in the OEM SubCA2 certificate to issue the OEM Supply Certificate and installs it in the EV 10. The OEM Supply Certificate can be used to verify the signature in the certificate installation request message during the EV 10's certificate installation process and is able to uniquely identify the vehicle throughout the EV 10's lifespan.

[0108] MO 110 also acts as the RootCA for issuing MO RootCA certificates. MO 110 can issue MO SubCA1 certificates by adding its own signature to the ID and public key of MO SubCA1. MO SubCA1 can issue MO SubCA2 certificates by adding its signature to the ID and public key of MO SubCA2. Based on the contract between the MO 110 operator and the EV owner upon EV delivery, MO SubCA 2 issues a contract certificate using a private key paired with the public key contained in the MO SubCA 2 certificate, and installs the contract certificate at the charging station (CS) 200 upon the EV's first visit. The contract certificate is linked to the EV owner's payment account via a unique identifier called the Electronic Mobility Account Identifier (eMAID).

[0109] As shown in the diagram, the OEM supply certificate and contract certificate are issued based on the OEM RootCA certificate and MO RootCA certificate issued by OEM 100 and MO 110 respectively, and are independent of the certificate issued based on the global RootCA certificate, i.e., the V2G RootCA certificate, and are used by other participants. However, as Figure 3 As shown by the dotted line, OEM supply certificates and contract certificates can be issued by using a V2G RootCA certificate instead of an OEM RootCA certificate and an MO RootCA certificate.

[0110] V2G 150 is capable of issuing at least two certificate chains: a certificate chain of CS 200 and CSO 210 (as mentioned above, CSO210 is a synonym for CPO) and another certificate chain for providing services.

[0111] First, the V2G 150 can issue a CPOSubCA 1 certificate by adding its own signature to the ID and public key of CPO SubCA 1. CPO SubCA 1 (or MO SubCA1) can issue a CPO SubCA 2 certificate by adding its signature to the ID and public key of CPO SubCA 2. CPO SubCA 2 can then issue an SECC leaf certificate using a private key paired with the public key contained in the CPO SubCA 2 certificate, and provide the SECC leaf certificate to the CS 200 for installation. During TLS communication establishment, the EV 10 can use the SECC leaf certificate to verify that it is communicating with a genuine charging station and not a fake one. This certificate is stored in the CS 200 and also in the backend of the CSO 210.

[0112] The V2G 150 can issue a SubCA 1 certificate by adding its signature to the ID and public key of SubCA 1. SubCA 1 can issue a SubCA 2 certificate by adding its signature to the ID and public key of SubCA 2. SubCA 2 can issue a leaf certificate by using a private key paired with the public key contained in the SubCA 2 certificate, and provide the leaf certificate to the CPS 120 for installation in the CPS 120.

[0113] Simultaneously, each RootCA—V2G RootCA, MO RootCA, and OEM RootCA—can issue and provide Online Certificate Status Protocol (OCSP) certificates, allowing clients to access the OCSP server to query the certificate status regarding certificate revocation indicating certificate validity and receive the query results. Although for simplicity, the diagram shows OCSP certificates applicable only to CPO SubCAs (i.e., CPO SubCA 1 and CPO SubCA 2), all RootCAs can issue OCSP certificates to allow querying the validity of certificates in the certificate chain associated with their RootCA certificate.

[0114] In an exemplary embodiment of this disclosure, the certificate is verified or authenticated using one of three common methods. First, the certificate recipient can use the public key in the certificate to decrypt the message signature in the certificate to recover the hash, and compare the recovered hash with the hash contained in the certificate to verify the integrity of the certificate. Second, the certificate recipient can verify the integrity and reliability of each certificate in the certificate chain by comparing the owner information of each certificate with the issuer information of the SubCA certificate sequentially from the RootCA certificate to the leaf certificates in the certificate chain. Third, the certificate recipient can verify the certificate by checking whether the certificate has been revoked using a Certificate Revocation List (CRL) received from the RootCA, or by querying the certificate status from the OCSP server associated with the RootCA.

[0115] Figure 5 An exemplary diagram illustrates nodes constituting a PnC charging infrastructure that supports roaming services for EVs. In the example shown, a first electric vehicle (EV1) has a contractual relationship with a first CSP (CSP1) and can use the charging service at an EVSE connected to a first CS (CS1) belonging to a first CSO (CSO1) network of the first CSP (CSP1). Furthermore, a second EV (EV2) has a contractual relationship with a second CSP (CSP2) and can use the charging service at an EVSE connected to a second CS (CS2) belonging to a second CSO (CSO2) network of the first CSP (CSP2). Therefore, both the first EV (EV1) and the second EV (EV2) can be charged without difficulty by connecting to the CSs of their respective CSOs (i.e., CSO1 and CSO2). However, a roaming environment occurs when the first EV (EV1) accesses the second CS (CS2) managed by the second CSO (CSO2) or the second EV (EV2) accesses the first CS (CS1) managed by the first CSO (CSO1), in which case it may be necessary to install or update the certificate in the EV.

[0116] Figure 6 Examples of scenarios where roaming is not required and scenarios where roaming is required are shown.

[0117] In the PnC certification infrastructure, EV certification, charging, and payment are automatically performed by simply connecting the EV to a CS or EVSE. For PnC certification to be applied, EV owners must sign a service contract with an MO or CSP. After signing the contract, a contract certificate is installed in the EV, and certification, authorization, and payment are completed based on the contract certificate. Therefore, once an EV owner visits a CS managed by a CSO belonging to the MO or CSP network with which the EV has a contractual relationship, and plugs the EV into the CS or parks the EV at a wireless charging point, the EV will automatically present its contract certificate to the CS and obtain certification and charging services.

[0118] In EV charging infrastructure, there may be multiple Motor Originators (MOs) or Consumer Service Providers (CSPs), each establishing an independent network for PnC (Point of Charge) activation. While each EV can freely use PnC services within the network of the MO or CSP with which it has a contractual relationship, PnC services for an EV may be restricted or unavailable in other networks. For example, in a scenario where an EV and... Figure 5 The first CSP (CSP) A In the case of a contractual relationship, EV can be in the first CSP (CSP) A Using PnC charging service within the network to which it belongs, for example, in a network operated by the first CSP (CSP) A Related CSO A On the managed EVSE.

[0119] Conversely, if EV is related to the second CSP (CSP) X ) having a contractual relationship, EV may not be able to be in the first CSP (CSP) A Properly use PnC charging services within the network to which the first CSP (CSP) belongs, for example, in a network with the first CSP (CSP). A Related CSO A On the managed EVSE. However, if the interviewed CSP (e.g., CSP) A ) and attribution to CSP (e.g., CSP) X If a roaming contract exists between the parties, then the surveyed CSO (CSO) A Upon receiving an authorization request from the EV, access can be granted to the home CSP (CSP). A To enable PnC charging service for EVs. Meanwhile, if the visited CSP (e.g., CSP...) A ) and attribution to CSP (e.g., CSP) X If there is an indirect roaming contract through the clearinghouse between the interviewed CSOs (CSOs) and the clearinghouse, then the interviewed CSOs (CSOs) A Upon receiving an authorization request from an EV, the PnC charging service for the EV can be enabled with the support of the clearinghouse.

[0120] Now refer to Figures 7 to 11 Describe the general authorization process in detail.

[0121] Figure 7 This is a sequence diagram illustrating the general service authorization process under a contract when roaming is not required.

[0122] In the example shown in the diagram, the CS's SECC can generate a challenge (GenChallenge) by encrypting a random number using the SECC's private key and send the challenge to the EV's EVCC (Operation 600). The CS holds the challenge at least until it receives a subsequent message from the EV. Upon receiving the challenge, the EV can decrypt the challenge using the CS's public key, encrypt an authorization request message (AuthorizationReq) containing numbers selected according to prescribed rules using its private key, and send the encrypted authorization request message to the CS as a response to the challenge (Operation 602). The authorization request message may include the EV's contract certificate chain.

[0123] The CS uses the EV's public key to decrypt the signature contained in the AuthorizationReq message to recover the hash, and compares the recovered hash with the hash contained in the AuthorizationReq message to verify the signature in the AuthorizationReq message (Operation 604). At this point, the CS can additionally determine whether the response value included in the AuthorizationReq message corresponds to a challenge.

[0124] Subsequently, the CS forwards the contract certificate chain received from the EV to the CSO (Operation 606). The CSO verifies the contract certificate chain (Operation 608). As mentioned above, the verification of the integrity and reliability of the contract certificate chain can be accomplished by sequentially comparing the owner information of each certificate and the issuer information of its SubCA certificate from the Root CA certificate to the leaf certificates in the certificate chain.

[0125] Next, the CSO can forward the contract certificate chain to the CSP (Operation 610). For each certificate in the contract certificate chain, the CSP can check whether the certificate has been revoked by using a Certificate Revocation List (CRL) or by querying the OCSP server (Operation 612). Based on the check result, the CSP can send an authorization message for the authorized contract (i.e., the transaction) to the CS (Operation 614). Upon receiving the authorization message, the CS sends an authorization result message (AuthorizationRes) to the EV (Operation 616).

[0126] However, since the MO RootCA certificate (according to the ISO 15118-20 standard version effective July 2, 2018) is not installed in the EV as the highest certificate in the contract certificate chain, the contract certificate chain sent by the EV to the CS in Operation 602 does not include the MO RootCA certificate, but includes the contract certificate itself (which is a leaf certificate) as well as the MO SubCA 1 certificate and the MO SubCA 2 certificate. Therefore, the CSO receiving the certificate chain from the CS must verify the contract certificate chain without the MO RootCA certificate in Operation 608, and the verification may be incomplete unless the CSO has obtained both the MO RootCA certificate and the CSP RootCA certificate. Of course, the CSP RootCA certificate held by the CSO cannot replace the MO RootCA certificate. Furthermore, since the CSP's access to the CRL or OCSP server associated with the MO RootCA (but not the CRL or OCSP server associated with the CSP RootCA) is uncertain, the check for certificate revocation in Operation 612 may also be incomplete.

[0127] Figure 8 This is a sequence diagram illustrating the general service authorization process under a contract in the event of direct roaming. In the example shown in the diagram, it is assumed that the visited CSO managing the CS does not belong to the network of the home CSP with a contractual relationship with the EV, but a roaming contractual relationship has been established between the visited CSP and the home CSP.

[0128] In this case, it can be with Figure 7 Operations 600 to 604 are performed in the same manner as shown. That is, the CS can send a challenge to the EV (operation 600), and the CS can respond to the challenge by sending an Authorization Request message (AuthorizationReq) to the EV (operation 602). The CS can then verify the signature in the Authorization Request message (operation 604).

[0129] Subsequently, the CS forwards the contract certificate chain received from the EV to the visited CSO (Operation 626). The visited CSO verifies the contract certificate chain (Operation 628). At this point, the visited CSO can refer to the eMAID to identify the path to the home CSP. Therefore, the visited CSO can check the home CSP and forward the contract certificate chain to the home CSP (Operation 630). For each certificate in the contract certificate chain, the home CSP can check whether the certificate has been revoked by using a Certificate Revocation List (CRL) or querying the OCSP server (Operation 632). Based on the check result, the home CSP can transmit the authorization message for the authorized contract (i.e., the transaction) to the CS (Operation 634). Upon receiving the authorization message, the CS sends an authorization result message to the EV (Operation 636).

[0130] In this scenario, the interviewed CSO must also verify the contract certificate chain without an MO RootCA certificate in Operation 628, and this verification may be incomplete unless the CSO obtains an MO RootCA certificate in addition to the CSP RootCA certificate. Furthermore, since it is uncertain whether the home CSP can access the CRL or OCSP server associated with the MO RootCA but not the CRL or OCSP server associated with the CSP RootCA, checking for certificate revocation in Operation 632 may also be incomplete.

[0131] Figure 9 This is a sequence diagram illustrating the general service authorization process under a contract in the event of indirect roaming. In the example shown in the diagram, it is assumed that the visited CSO managing the CS does not belong to the network of the home CSP with a contractual relationship with the EV, but an indirect roaming contractual relationship involving the clearinghouse is established between the visited CSP and the home CSP.

[0132] In this case, operations 600 to 604 can be combined with... Figure 7 and Figure 8 The process is executed in the same manner as shown. That is, the CS can send a challenge to the EV (operation 600), and the CS can respond to the challenge by sending an Authorization Request message (AuthorizationReq) to the EV (operation 602). Then, the CS can verify the signature of the Authorization Request message (operation 604). Next, the CS forwards the contract certificate chain received from the EV to the visited CSO (operation 646).

[0133] Since the interviewed CSO has no contractual relationship with the attributing CSP that has a contract with the EV, the interviewed CSO cannot identify the attributing CSP using information such as the eMAID it possesses. However, since the interviewed CSO has a contractual relationship with the clearinghouse, the interviewed CSO can check whether the clearinghouse can identify the attributing CSP and which clearinghouse can identify the attributing CSP (Operation 648). After checking that the clearinghouse can identify at least one attributing CSO (Operation 650), the interviewed CSO can forward the contract certificate chain to the clearinghouse (Operation 652). The clearinghouse can verify the contract certificate chain (Operation 654) and then forward the contract certificate chain to the attributing CSP (Operation 656). For each certificate in the contract certificate chain, the attributing CSP can check whether the certificate has been revoked by using a Certificate Revocation List (CRL) or querying the OCSP server (Operation 657). Based on the check result, the attributing CSP can transmit the authorization message for the authorized contract (i.e., the transaction) to the CS (Operation 658). Upon receiving the authorization message, the CS sends an authorization result message to the EV (Operation 659).

[0134] In this scenario, the verification in Operation 654 may be incomplete unless the clearinghouse also obtains an MO RootCA certificate in addition to the CSP RootCA certificate. Furthermore, since it is uncertain whether the home CSP can access the CRL or OCSP server associated with the MO RootCA but not the CRL or OCSP server associated with the CSP RootCA, the check for certificate revocation in Operation 657 may also be incomplete.

[0135] Figure 10 This is a sequence diagram illustrating the general service authorization process under a contract in the event of immediate direct roaming. In the example shown in the diagram, it is assumed that the visited CSO managing the CS does not belong to the network of the home CSP with a contractual relationship with the EV, but the visited CSO can enter into an immediate direct roaming contract with the home CSP.

[0136] In this case, the execution method of operations 600 to 604 is the same as... Figure 7 and Figure 8 The process is the same. That is, the CS can send a challenge to the EV (operation 600), and the EV can respond to the challenge by sending an Authorization Request message (AuthorizationReq) to the CS (operation 602). Then, the CS can verify the signature of the Authorization Request message (operation 604). Next, the CS forwards the contract certificate chain received from the EV to the visited CSO (operation 646).

[0137] Subsequently, the interviewed CSO can enter into an instant roaming contract with the home CSP (Operation 668). Then, the interviewed CSO can verify the contract certificate chain (Operation 670). The interviewed CSO can refer to the eMAID to know the path to access the home CSP. Therefore, the interviewed CSO can forward the contract certificate chain to the home CSP (Operation 672). For each certificate in the contract certificate chain, the home CSP can check whether the certificate has been revoked by using a Certificate Revocation List (CRL) or querying the OCSP server (Operation 674). Based on the check result, the home CSP can transmit the authorization message for the authorized contract (i.e., the transaction) to the CS (Operation 676). Upon receiving the authorization message, the CS sends an authorization result message to the EV (Operation 678).

[0138] In this scenario, the verification in Operation 670 may be incomplete unless the visited CSO also possesses an MO RootCA certificate in addition to the CSP RootCA certificate. Furthermore, since it is uncertain whether the home CSP can access the CRL or OCSP server associated with the MO RootCA but not the CRL or OCSP server associated with the CSP RootCA, checking for certificate revocation in Operation 674 may also be incomplete.

[0139] Figure 11 This is a sequence diagram illustrating the general service authorization process under a contract in the event of an immediate indirect roaming incident. In the example shown in the diagram, the visited CSO managing the CS does not belong to the network of the home CSP with a contractual relationship with the EV, and there is no indirect roaming contractual relationship involving the clearinghouse between the visited CSP and the home CSP. Therefore, the visited CSO is unaware of both the home CSP and the clearinghouse with a contractual relationship with the home CSP. However, it is assumed that the visited CSO can request the clearinghouse to enter into an online contract with the home CSP.

[0140] In this case, operations 600 to 604 can be combined with... Figure 7 and Figure 9 The process is executed in the same manner as shown. That is, the CS can send a challenge to the EV (operation 600), and the EV can respond to the challenge by sending an Authorization Request message (AuthorizationReq) to the CS (operation 602). Then, the CS can verify the signature of the Authorization Request message (operation 604). Next, the CS forwards the contract certificate chain received from the EV to the visited CSO (operation 686).

[0141] Since the interviewed CSO has no direct contractual relationship with the home CSP that has already signed a contract with the EV, the interviewed CSO cannot identify the home CSP using information such as the eMAID possessed by the interviewed CSO. Furthermore, the interviewed CSO may attempt to identify the clearinghouse that already has a contractual relationship with the home CSP, but identification fails (Operation 688). In this case, the interviewed CSO can request the clearinghouse to find the home CSP and sign a contract with the home CSP (Operation 690). Here, the contract can be used for one-time EV charging and charging payment clearing. After the contract is established between the clearinghouse and the home CSP (Operation 692), the clearinghouse can verify the contract certificate chain (Operation 694) and then forward the contract certificate chain to the home CSP (Operation 696). For each certificate in the contract certificate chain, the home CSP can check whether the certificate has been revoked by using a Certificate Revocation List (CRL) or querying the OCSP server (Operation 697). Based on the check result, the home CSP can transmit the authorization message for the authorized contract (i.e., the transaction) to the CS (Operation 698). Upon receiving the authorization message, the CS transmits the authorization result message to the EV (Operation 699).

[0142] In this scenario, verification in Operation 694 may also be incomplete unless the clearinghouse obtains an MO RootCA certificate in addition to the CSP RootCA certificate. Furthermore, since it is uncertain whether the home CSP can access the CRL or OCSP server associated with the MO RootCA but not the CRL or OCSP server associated with the CSP RootCA, checking for certificate revocation in Operation 697 may also be incomplete.

[0143] Furthermore, as mentioned above, the CSP can issue the EV's contract certificate as an MO SubCA according to the ISO 15118 standard. That is, when the EV sends the OEM supply certificate already stored therein before delivering the vehicle to the CSO, the CSO creates a contract certificate and provides it to the EV. The contract certificate is stored in the EV and submitted to the CS when the EV receives PnC services, enabling the CS or another secondary participant to identify the EV's contract.

[0144] However, even when the contract certificate is not installed in the EV, there may be situations where the EV accesses the CS and requests PnC services. For example, although the EV must send the OEM supply certificate installed in the EV and obtain the contract certificate during its first charge before delivery to the CSP or MO, the CS accessed by the EV for the first charge may be associated with a CSO that is not part of the home CSP network. In this case, the contract certificate must be installed in the EV under roaming conditions. A similar situation may occur after a change of EV ownership or EV memory failure. Furthermore, the certificate installed in the EV under roaming conditions is not limited to the contract certificate and can be another certificate. The ISO 15118 standard specifies the network layer and application layer of the V2G communication interface, and the IEC 63119-1 standard specifies the information exchange for EV charging roaming services, but neither of these standards describes this specific issue.

[0145] According to exemplary embodiments of this disclosure, any CSP with a contractual relationship with an EV can enable the EV to install or update a contract certificate or another certificate or data in any roaming situation. A method for installing or updating a certificate in an EV according to exemplary embodiments of this disclosure will be described in detail below.

[0146] Figure 12 The delivery path of a contract certificate from the home CSP to the EV via direct roaming, according to an exemplary embodiment of this disclosure, is shown.

[0147] In this embodiment, it is assumed that a contract certificate stored in the home CPS (CPSH) needs to be installed in the EV, or an existing certificate in the EV needs to be updated using this certificate. The EV has already accessed and is currently residing in a CS connected to a visited CSO (CSOV) belonging to a visited CSP (CSPV) network. However, if the home CSP (CSPH) and the visited CSP (CSPV) have a roaming contract relationship, the EV can directly install the contract certificate stored in the home CPS (CPSH) through roaming, or update an existing certificate using the contract certificate stored in the home CPS (CPSH).

[0148] Figure 13 To explain in more detail Figure 12 The diagram shows the sequence of the certificate delivery process.

[0149] First, the EV owner and the home CSP operator can enter into a charging service contract (Operation 700). After the contract is signed, the home CSP can create a contract certificate for the EV (Operation 702). The created certificate includes the EV's public key, a hash of the public key, and a message signature obtained by encrypting the hash using the private key of an MO SubCA (i.e., MO SubCA1 or MO SubCA2). The certificate can be distributed to all visited CSPs that have roaming contracts with the home CSP (Operations 704 to 708).

[0150] In an exemplary embodiment, operations 700 to 708 can be performed in advance before the EV sends a CertificateInstallationReq or CertificateUpdateReq message to the visited CSO via the CS. That is, to support the EV's request to install or update a certificate from a visited CSP, the home CSP can distribute the certificate installation package in advance to all visited CSPs with which it has a contractual relationship. This allows the visited CSPs to store the certificate installation package in their CPS and support the installation or update of the EV's certificate in response to the EV's request. In this case, considering the possibility of instant roaming, the certificate installation package can be distributed to all CSPs in advance regardless of the contractual relationship. The certificate installation package may include a contract certificate chain and eMAID account information, and may also include a Certificate Revocation List (CRL) and access information to the OCSP server. The transfer of the certificate installation package between CSPs can be done directly or through a clearinghouse as described below.

[0151] More specifically, after the home CSP creates the contract certificate in Operation 704, a Certificate Installation Response message (CertificateInstallationRes) or Certificate Update Response message (CertificateUpdates), including the certificate installation package, is distributed via a secure channel to all visited CSPs with a contractual relationship to the home CSP. At this point, each home CSP can verify the contract certificate chain, check its revocation status, check the status of the eMAID account, and check if the contract is authorized for service use. If the verification indicates that the contract certificate chain, eMAID account, and contract are without issues, the home CSP can distribute the certificate package to all visited CSPs with a direct roaming contract with the home CSP, clearinghouses with a certificate distribution contract with the home CSP, or both. For this distribution process, the home CSP may maintain a list of visited CSPs with a direct roaming contract with the home CSP (if any). Additionally, the home CSP may maintain a list of clearinghouses with a certificate installation roaming contract with the home CSP (if any). Communication for distributing the certificate package may occur at the roaming endpoint. On the other hand, upon receiving the certificate installation package, the visited CSP can distribute the package to the visited CSP's CPS through the same process performed when the visited CSP issues certificates for its own users.

[0152] Subsequently, when an EV requests certificate installation or renewal, the visited CSO can retrieve the certificate installation package from the visited CPS and forward it to the EV. The installation or renewal process may be the same in non-roaming and roaming scenarios. Figure 13 Operations 720 to 734 in the diagram illustrate this process.

[0153] Specifically, in operation 720, the EV can transmit a certificate installation or update request message (Cert{Ins / Upd}Req) to the CS. In the case of a certificate installation request message, the EV can send the OEM supply certificate chain to the CS via communication conforming to the ISO 15118 standard. Conversely, a certificate update request message may include a contract certificate chain. Upon receiving the certificate installation or update request message (Cert{Ins / Upd}Req), the CS can verify the signature in the request message (operation 722). The CS can verify the signature by using its public key to decrypt the signature included in the request message to recover the hash, and then comparing the recovered hash with the hash included in the request message.

[0154] Subsequently, the CS verifies the received certificate chain (Operation 724). In the case of an OEM-supplied certificate used for certificate installation, the certificate chain is verified by comparing the owner information of each certificate with the issuer information of its SubCA certificate, sequentially from the OEM RootCA certificate to the OEM-supplied certificate, where the OEM-supplied certificate is the leaf certificate in the supply certificate chain, to verify the integrity and reliability of each certificate in the supply certificate chain. In the case of a contract certificate used for certificate renewal, the certificate chain is verified by comparing the owner information of each certificate with the issuer information of its SubCA certificate, sequentially from the OEM RootCA certificate to the contract certificate, where the contract certificate is the leaf certificate in the contract certificate chain, to verify the integrity and reliability of each certificate in the contract certificate chain. The CS then transmits the certificate installation or renewal request message (Cert{Ins / Upd}Req) to the visited CSO (Operation 726).

[0155] The interviewed CSO can check the revocation status of each certificate in the OEM supply certificate chain or contract certificate chain (Operation 728). The revocation status or validity of a certificate can be checked by using a Certificate Revocation List (CRL) received from the OEM RootCA or the MO RootCA, or by querying the certificate status from the OCSP server associated with the MO RootCA.

[0156] Next, the interviewed CPS verifies the new contract certificate chain stored in operation 708 based on the MO RootCA certificate (operation 730). Furthermore, the interviewed CPS checks the revocation status of each certificate in the new contract certificate chain (operation 732). The revocation status or validity of a certificate can be checked using a Certificate Revocation List (CRL) received from MO RootCA or by querying the certificate status from the OCSP server associated with MO RootCA.

[0157] Typically, when an ISO 15118 compliant EV attempts to establish a TLS connection with a CS, the CS needs to prove that all certificates in the CS certificate chain are valid, i.e., not revoked. To this end, according to an exemplary embodiment of this disclosure, the CS can periodically and sufficiently frequently request the CS management system (CSMS) to keep OCSP responses valid and to retrieve OCSP responses from the OCSP responder of the CSO PKI. The CS can store a single OCSP response for each certificate chain.

[0158] For each certificate, the CS can determine to update the OCSP response before the existing OCSP response expires and can request the CSMS to retrieve the OCSP. The OCSP retrieval request can include an OCSP request message, the Certificate Issuer's Distinguished Name (DN), and the certificate's serial number. For each request, the CSMS looks up its certificate database using the issuer's DN and serial number to retrieve the OCSP response URL. If the URL is not found, the CSMS may try to retrieve it using other methods. If no URL is available, the CSMS may indicate an error in its response. After successfully retrieving the OCSP response, the CSMS can send back a list of OCSP response messages to the CS. If any retrieval fails, the CSMS may indicate which OCSP query failed and the reason. The CS can store received OCSP responses and send them to the EV via OCSP binding during the TLS connection. For each error, the CS can determine whether to retry the retrieval or enter a hold state based on the error type.

[0159] CSMS maintains a certificate database storing certificates used by the CS or its own certificates, ensuring the CS's certificate status information remains up-to-date. Simultaneously, the CS can always maintain a valid set of OCSP responses for its certificate chain. The CS needs to request OCSP responses from CSMS frequently enough to keep the OCSP responses valid.

[0160] After verifying the new contract certificate chain in operation 730, if the validity of each certificate in the new contract certificate chain is not problematic in operation 732, the visited CPS sends a certificate installation / update response (i.e., Cert{Ins / Upd}Res) message to the CS (operation 734). The CS can then send a new contract certificate package to the EV so that the EV can install or update the new certificate (step 736).

[0161] In operations 704 through 708, the contract certificates distributed to virtually all CSPs can be removed from each CSP's storage to reduce the burden of storing private information after a certain period following distribution or when the contract certificate installation is completed in the EV. Therefore, it is preferable that, after the contract certificate installation in the EV is complete, the home CSP notifies all CSPs and clearinghouses that received the distributed contract certificates of the completion of the installation.

[0162] First, the EV owner and the home CSP operator can enter into a charging service contract (Operation 700). After the contract is signed, the home CSP can create a contract certificate for the EV (Operation 702). The created certificate includes the EV's public key, a hash of the public key, and a message signature obtained by encrypting the hash using the private key of an MO SubCA (i.e., MO SubCA1 or MO SubCA2). The certificate can be distributed to all visited CSPs that have roaming contracts with the home CSP (Operations 704 to 708).

[0163] Although, as described above, the CS sends data received from the visited CPS in Operation 734, such as contract certificate packets, to the EV in Operation 736, not all certificate data received by the CS is necessarily transmitted to the EV. That is, the CS can receive certificates as needed to install or update previously installed certificates. For example, the CS can retrieve some RootCA certificates and related metadata for authenticating the EV and CSMS, as well as cross-certificates for authenticating itself to the EV, from the CSMS. In other words, the CS may need to store some RootCA certificates issued by the RootCA, but these are not necessarily self-signed along with the metadata for secure operation. The certificate metadata may include a SHA1 hash (for TLS), the issuer's DN, and the certificate's serial number (for certificate installation).

[0164] Examples of certificates that a CS (Contract Certificate Provider) receives, stores, or updates as needed are shown below. The CS requires the RootCA certificate of the CSMS certificate chain (i.e., the CSMS's RootCA certificate) to verify the CSMS and establish a secure channel with it. Typically, this RootCA certificate is the same as the CS's V2G RootCA certificate. Additionally, when an ISO 15118-compliant EV chooses to obtain authorization via the PnC mechanism, and the verification of the contract certificate chain acts as the CS, the CS may need a RootCA certificate from the EMSP. In the case of installing or updating a contract certificate, if the OEM supply certificate chain to be installed or the verification of the contract certificate chain to be updated acts as the CS, the CS may need an OEM RootCA certificate or an EMSP RootCA certificate.

[0165] In addition, when the CSO supports cross-certification to allow EV services that only trust V2G RootCAs other than the CSO's V2G RootCA, the CS may need cross-certificates issued by the V2G RootCAs trusted by the EV. On the other hand, in order to check whether the EV can trust the V2G RootCA (for TLS) certificate of the CSO or the V2G RootCA certificate of the CPS, the CS needs to know the metadata of the available trust anchors. The trust anchors include the V2G RootCA of the CS (including the new RootCA for migration) and the cross-certified V2G RootCAs. On the other hand, the CS may need the RootCA certificate of the component manufacturer of the CS for verifying the integrity of the firmware binary. In addition, for the migration of the V2G RootCA of the CS, if the CSO chooses to use the migration method defined in RFC 4210, the CS may need to hold one of the two cross-certificates during the migration.

[0166] There may be OldWithNew certificates and NewWithOld certificates. The OldWithNew certificate refers to the cross-certificate signed by the new RootCA for the old RootCA. For an EV that trusts the new RootCA, the CS with the old certificate chain needs this type of cross-certificate. The NewWithOld certificate refers to the cross-certificate signed by the old RootCA for the new RootCA. For an EV that trusts the old RootCA, the CS with the new certificate chain needs this type of cross-certificate.

[0167] According to an exemplary embodiment, the process by which the CS receives certificates for storage or update according to its own needs is triggered by the CSMS. That is, when the CSMS updates the CA certificates or metadata that need to be installed in the CS, the CSMS sends an update list to one or more CSs. The format of each update data can be "update = (type, certificate, metadata)". For example, in the case of the V2G RootCA of the CSO, each update data can be in the format of (V2G RootCA, <V2G RootCA Certificate>, -). In the case of the EMSP RootCA certificate, the format of the update data can be (EMSP RootCA, <EMSP RootCA Certificate>, -). For the OEM RootCA certificate, the format of the update data may be (OEM RootCA, <OEM RootCA certificate>, -). In the case of the cross-certificate, the format of the update data may be (CrossCerttificate, <Cross Certificate>, -). In the case of the cross-certified V2G RootCA certificate, the format of the update data can be (CrossRootCA, -, <metadata>In the case of an OldWithNew cross-certificate used for migration, the format of the updated data might be (OldWithNew,<OldWithNew certificate> In the case of a NewWithOld cross-certificate used for migration, the format of the updated data may be (NewWithOld, -). <newwitholdcertificate>,-).

[0168] In the case of the aforementioned certificates, upon receiving an update from CSMS, the CS installer will not experience any undue delay in receiving the received certificate or metadata and will update the update timestamp.

[0169] According to another exemplary embodiment, the process by which the CS receives a certificate to store or update it as needed is triggered by the CS. That is, when the CS determines any changes to update the CA certificate, it periodically, for example, requests the CSMS to update the CA certificate by sending certain information to the CSMS. Examples of information transmitted from the CS to the CSMS may include the timestamp of the last successful update, a list of publisher DNs, and the serial number of the CA certificate currently stored in the CS. Upon receiving an update request, the CSMS may send the CA certificate or metadata updated or added after the indicated timestamp. After receiving a response from the CSMS, the CS securely stores the CA certificate or metadata.

[0170] When the CSMS updates the CA certificate database, it must request the relevant CS to install the update or a set of updates since the last update. Upon receiving the request, the CS installs the received update on the CA certificate and sets the timestamp to the update time. According to the CSO's policy, the CS can periodically request CA certificate updates from the CSMS by providing the timestamp of the most recent update. When requested, the CSMS sends all updates to the CA certificate that have changed since the timestamp in the request. When the CSMS sends the CA certificate update, it also sends a list of certificate types, certificates, and metadata. At this point, only the metadata is sent for cross-certification of the V2G Root CA certificate.

[0171] On the other hand, the CS may need to hold multiple CA certificates and related information for secure operation. For example, when an ISO 15118 compliant EV chooses to be authorized via the PnC method, the CS may need the EMSP's RootCA certificate to verify the contract certificate chain. For the installation of contract certificates, the CS may also need the OEM's or EMPS's RootCA certificate. When establishing a secure channel with the CSMS, the CS needs the CSMS's RootCA certificate, typically the V2G RootCA certificate. Furthermore, to better achieve interoperability between different V2G operators, the CS needs to maintain cross-certificates issued by other V2G operators. Additionally, the CS needs to retain metadata (e.g., hash, DN, and serial number) for each trust anchor to determine if the EV can securely connect to the CSO.

[0172] According to an exemplary embodiment, the process of the CS updating multiple CA certificates and related information for security operations can be triggered by the CS. When the CS decides to update any changes in its list of CA certificates, the CS can request the CSMS to update all CA certificates. This request may include the timestamp of the last successful update request, a list of issuer DNs, and the serial numbers of the CA certificates in the CS. Upon receiving the request, the CSMS can check the timestamp of the CA certificate update and send only the data of the certificates updated since the timestamp in the request to the CS. The certificates to be sent may include: the CSMS's V2G RootCA certificate and related metadata, the CS's V2G RootCA certificate and related metadata, the RootCA certificate of the signed EMSP, including the OEM RootCA certificate if needed, and, if needed, the cross certificate of the V2G RootCA issued to the CS and related metadata, the metadata of the V2G RootCA certificate associated with the cross certificate, and the root migration cross certificate. Upon receiving a response from the CSMS, the CS can securely store the received CA certificate.

[0173] According to another exemplary embodiment, the process of a CS updating multiple CA certificates and related information for security operations can be triggered by a CSMS. When the CSMS updates a CA certificate to be installed in the CS, the CSMS can request the CA certificate update from all or some of the CSs by sending a list of certificate types to be updated and certificate data of the specified types. Examples of certificate types may include the CSMS's V2G RootCA certificate (for root migration), the CS's V2G RootCA certificate (for root migration), the EMSP RootCA certificate, the OEM RootCA certificate, a cross-certificate of the V2G RootCA issued to the CS, a V2G RootCA certificate associated with a cross-certificate, and a root migration cross-certificate. Upon receiving a request from the CSMS, the CS will install the received certificate data without undue delay and update the update timestamp.

[0174] During the certificate renewal process described above, CSMS maintains a database of CA certificate data, including the certificate, DN, serial number, hash, and tag update time. EV and CS can communicate using the PnC identification method according to the ISO 15118 standard. Simultaneously, CPS and CCP can verify the certificate chains (i.e., the OEM supply certificate chain used for installation and the contract certificate chain used for renewal) and check the revocation status of each certificate in both chains.

[0175] Upon receiving the updated certificate, the CS verifies the signatures of the CertificateInstallationReq and CertificateUpdateReq messages. The CS then sends the following data to the CSMS: the CertificateInstallationReq or CertificateUpdateReq message (as is), the PCID (for installation) or eMAID (for updates), the ISO 15118 schema version of the message, the retrieval deadline (due to ISO 15118 timeout), and a list of V2G RootCA certificates trusted by the EV. After receiving the data, the CSMS can request a contract certificate from the secondary participant and forward the received information back to the CS. In the case of receiving multiple contract certificates, the CSMS preferably indicates receipt completion to the CS. If no contract certificate is received, the CSMS may indicate an error message to the CS (e.g., "NO_CONTRACT_CERTIFICATE_FOUND"). When using the ISO 15118-2 standard, the CS can deliver the CertificateInstallationRes or CertificateUpdates message received from the CSMS (populated with a SessionID element) to the EV. On the other hand, when using the ISO 15118-20 standard, CS can modify each received CertificateInstallationRes message or generate a CertificateInstallationRes message for each message received from CSMS so that the message contains the correct values ​​for the SessionID, EVSEProcessing, RemainingCerts, EVSEStatus, and ResponseCode elements.

[0176] Figure 14 The delivery path of a contract certificate from the home CSP to the EV via indirect roaming, according to an exemplary embodiment of this disclosure, is shown.

[0177] In this embodiment, it is assumed that the contract certificate stored in the home CPS will be installed in the EV, or a previously installed certificate in the EV will be updated using the contract certificate. Furthermore, it is assumed that the EV has already accessed the CS connected to the visited CSO belonging to the visited CSP network. However, if the home CSP and the visited CSP have an indirect roaming contract relationship through a clearinghouse, the EV can install the contract certificate stored in the home CPS, or update a previously installed certificate using the contract certificate through indirect roaming via the clearinghouse.

[0178] Figure 15 To show in more detail Figure 14 The diagram shows a sequence of events for the certificate delivery process. According to... Figure 15 In the illustrated embodiment, the visited CSP and the home CSP do not communicate directly, but rather communicate through the clearinghouse during the process of pre-storing the certificate in the CSP.

[0179] First, the EV owner and the home CSP operator can enter into a charging service contract (Operation 800). After the contract is signed, the home CSP can create a contract certificate for the EV (Operation 802). The created certificate includes the EV's public key, a hash of the public key, and a message signature obtained by encrypting the hash using the private key of an MO SubCA (i.e., MO SubCA1 or MO SubCA2). The certificate can be distributed to all visited CSPs that have roaming contracts with the home CSP (Operations 804 to 808).

[0180] In an exemplary embodiment, operations 800 to 808 can be performed in advance before the EV transmits a Certificate Installation Request message (CertificateInstallationReq) or a Certificate Update Request message (CertificateUpdateReq) to the visited CSO via the CS. That is, to support the EV's request to install or obtain a certificate from a visited CSP, the home CSP can distribute the certificate installation package in advance to all visited CSPs with whom it has a contractual relationship. Therefore, the visited CSPs can store the certificate installation package in the CPS and support the installation or renewal of the EV's certificate according to the EV's request. At this time, considering the possibility of instant roaming, the certificate installation package can be distributed to all CSPs in advance regardless of the contractual relationship. The certificate installation package may include the contract certificate chain and eMAID account information, and may also include a Certificate Revocation List (CRL) and access information to the OCSP server. The transmission of the certificate installation package between CSPs can be performed directly or through a clearinghouse as described below.

[0181] More specifically, after the home CSP creates the contract certificate in Operation 804, a Certificate Installation Response message (CertificateInstallationRes) or Certificate Update Response message (CertificateUpdates), including the certificate installation package, is distributed via a secure channel to all visited CSPs with a contractual relationship to the home CSP. At this point, the home CSP or clearinghouse can verify the contract certificate chain, check its revocation status, check the eMAID account status, and check if the contract can be authorized for service use. If the verification indicates that the contract certificate chain, eMAID account, and contract are without issues, the certificate package can be distributed to all visited CSPs. After distribution, the home CSP sends the certificate chain status code, along with the account and authorization result codes, to the clearinghouse. For this distribution process, the home CSP may maintain a list of visited CSPs (if any) with which it has a direct roaming contract. Additionally, the home CSP may maintain a list of clearinghouses (if any) with which it has a certificate installation roaming contract. Communication for distributing the certificate package may occur at the roaming endpoint. On the other hand, after receiving the certificate installation package, the visited CSP can distribute the package to the visited CSP's CPS through the same process that the visited CSP performs when issuing certificates for its own users.

[0182] Subsequently, when an EV requests certificate installation or renewal, the visited CSO can retrieve the certificate installation package from the visited CPS and forward it to the EV. The installation or renewal process may be the same in both non-roaming and roaming scenarios. Figure 15 Operations 820 to 836 in the diagram illustrate this process.

[0183] Specifically, in operation 820, the EV can send a certificate installation or update request message (Cert{Ins / Upd}Req) to the CS. In the case of a certificate installation request message, the EV can send the OEM supply certificate chain to the CS via communication conforming to the ISO 15118 standard. Conversely, a certificate update request message may include a contract certificate chain. Upon receiving a certificate installation or update request message (Cert{Ins / Upd}Req), the CS can verify the signature in the request message (operation 822). The CS can verify the message signature by using its public key to decrypt the signature included in the request message to recover the hash, and then comparing the recovered hash with the hash included in the request message.

[0184] Subsequently, the CS verifies the received certificate chain (Operation 824). In the case of certificate installation, the OEM-supplied certificate is verified as described above. In the case of certificate renewal, the contract certificate chain is verified as described above. Then, the CS transmits the certificate installation or renewal request message (Cert{Ins / Upd}Req) to the visited CSO (Operation 826). The visited CSO can check the revocation status of each certificate in the OEM-supplied certificate chain or the contract certificate chain as described above (Operation 828).

[0185] The interviewed CPS verifies the new contract certificate chain stored in operation 808 based on the MO RootCA certificate (operation 830). The interviewed CPS checks the revocation status of each certificate in the new contract certificate chain (operation 832). The revocation status or validity of a certificate can be checked by using the Certificate Revocation List (CRL) received from MO RootCA or by querying the certificate status from the OCSP server associated with MO RootCA.

[0186] After verifying the new contract certificate chain during operation, if the validity of each certificate in the new contract certificate chain is not problematic, the visited CPS sends a certificate installation / update response (Cert{Ins / Upd}Res) message to the CS (Operation 834). The CS can then send a new contract certificate package to the EV so that the EV can install or update the new certificate (Operation 836).

[0187] Although in operation 836, as described above, the CS will send the data received from the visited CPS in operation 834 to the EV, not all certificate data received by the CS is necessarily transmitted to the EV. That is, the CS can receive certificates as needed to install or update previously installed certificates. Furthermore, the CS needs to maintain multiple CA certificates and related information for implementing security operations, and can update CA certificates and related information. According to this embodiment, the process by which the CS installs or updates CA certificates as needed is similar to the reference... Figure 13 For the sake of simplicity, the detailed description of the process will be omitted.

[0188] It should be noted that the roles of the interviewed CSP and the attributing CSP can be... Figure 13 and Figure 15 Interchangeable. In addition, a CSP can be both a CSP of another CSP and a CSP of another CSP.

[0189] Figure 16 This is a sequence diagram illustrating a contract-based service authorization process according to exemplary embodiments of the present disclosure.

[0190] First, an EV seeking service authorization via the PnC mechanism can send an Authorization Request message (AuthorizationReq) to the CS being visited (Operation 900). At this point, the EV provides the contract certificate chain to the CS via communication conforming to the ISO 15118 standard. The CS can verify the message signature by decrypting the signature in the Authorization Request message using the EV's public key to recover the hash and comparing the recovered hash with the hash included in the Authorization Request message (Operation 902).

[0191] Subsequently, the CS can deliver the contract certificate chain and eMAID, included in the authorization request message, to the visited CSO (Operation 904). The visited CSO determines whether the CSP contracted with the EV is within or outside the visited CSO's network. The visited CSO then determines how to directly contact the home CSP or clearinghouse for roaming assistance. Next, the visited CSO sends an authorization request, including EV-related information, to the home CSP or clearinghouse (Operation 906). The EV-related information includes the eMAID and contract certificate chain, and may further include a service description for authorizing the EV. If the destination of the EV-related information sent by the visited CSO in Operation 906 is the clearinghouse, the clearinghouse forwards the EV-related information to the appropriate home CSP.

[0192] Next, the Attribution CSP checks and verifies the complete contract certificate chain, which includes the acquired MO RootCA certificates (Operation 908). The contract certificate chain is verified by sequentially comparing the owner information of each certificate with the publisher information of the publisher's SubCA certificates, from the MO RootCA certificate to the SubCA certificates (including MO SubCA 1 and MO SubCA 2 certificates) and then to the contract certificate (leaf certificate), to confirm the integrity and reliability of each certificate in the chain. Then, the Attribution CSP checks the revocation status of each certificate in the contract certificate chain (Operation 910). The revocation status or validity of a certificate can be checked using a Certificate Revocation List (CRL) received from MO RootCA or by querying the certificate status from the OCSP server associated with MO RootCA. The Attribution CSP can also check the status of the eMAID account and whether a contract can be authorized for the requested service (Operation 912).

[0193] Based on the inspection results, the attributing CSP can reply to the visited CSO with a status code indicating the status of the contract certificate chain, as well as an account and authorization result code (Operation 914). For example, the status code can be one of "OK", "Expired", "Revoked", "Invalid_chain", and "Unknown_error". Similarly, the result code can be one of "OK", "No Contract", "Contract Terminated", "Contract Suspended", "Not Authorized", and "Unknown_error".

[0194] The interviewed CSO can notify the CS of the authorization result, and the CS can then notify the EV of the authorization result again through communication conforming to ISO 15118 (Operation 916 and Operation 918).

[0195] Therefore, if the CSP that has a contractual relationship with the EV has a direct roaming contractual relationship with the surveyed CSP, or an indirect roaming contractual relationship through the clearinghouse, the surveyed CSP can authorize the EV by exchanging the necessary information with the home CSP directly or indirectly through the clearinghouse.

[0196] Figure 16 Only exemplary embodiments of this disclosure are shown, and various modifications can be made to these embodiments. For example, in an alternative embodiment, the verification of the message signature in operation 902 may be performed by the visited CSO instead of the CS. Furthermore, the verification of the contract certificate chain in operation 908 may be performed by the visited CSO or CS instead of the home CSP. Additionally, depending on roaming conditions, Figure 16 In the embodiments, the entity performing each operation can be similar to Figures 7 to 11 The implementation examples have been modified.

[0197] Figure 17 This is a block diagram of a charging service provider (CSP) 220 according to an exemplary embodiment of the present disclosure. The CSP 220 according to an exemplary embodiment of the present disclosure may include at least one processor 1020, memory 1040, and storage device 1060.

[0198] Processor 1020 can execute program instructions stored in memory 1040 and / or storage device 1060. Processor 1020 can be at least one central processing unit (CPU), graphics processing unit (GPU), or any other type of dedicated processor suitable for performing the processing according to this disclosure.

[0199] Memory 1040 may include, for example, volatile memory (e.g., read-only memory (ROM)) and non-volatile memory (e.g., random access memory (RAM)). Memory 1040 may load program instructions stored in storage device 1060 to provide to processor 1020.

[0200] Storage device 1060 may include an intangible recording medium suitable for storing program instructions and data files. Any device capable of storing data readable by a computer system may be used for storage. Examples of storage media may include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical media such as optical disc read-only memory (CD-ROM) and digital video discs (DVDs); magneto-optical media such as floppy disks; and semiconductor memories such as ROM, RAM, flash memory, and solid-state drives (SDs).

[0201] Storage device 1060 stores program instructions. Specifically, the program instructions may include instructions for supporting the installation of contract certificates according to this disclosure. The program instructions for supporting the installation of contract certificates may include: instructions for generating a first contract certificate for a first EV and transmitting the first contract certificate to a first external CSP so that the first contract certificate can be installed in the first EV via the first external CSP; instructions for receiving a second contract certificate from a second external CSP for a second EV and forwarding the second contract certificate to a CPS so that the CPS can store the second contract certificate; and instructions for transmitting the second contract certificate stored in the CPS to the second EV and installing it in the second EV when a contract certificate installation request is received from the second EV while the second EV is roaming within the service network of the charging service provider. Furthermore, the program instructions may include instructions for implementing… Figure 12 The process shown requires at least some instructions. The program instructions can be loaded into memory 1040 under the control of processor 1020 and executed by processor 1020 to implement the method according to this disclosure.

[0202] According to one aspect of this disclosure, a charging service providing device is provided. The charging service providing device includes: a processor; and a memory storing at least one program instruction to be executed by the processor. When the processor executes the at least one program instruction, it causes the processor to: generate a first contract certificate for a first EV (EV) and transmit the first contract certificate to a first external charging service providing device (CSP) so that the first contract certificate can be installed in the first EV via the first external CSP; receive a second contract certificate for a second EV from a second external CSP and forward the second contract certificate to a certificate providing service device (CPS) so that the CPS can store the second contract certificate; and when a contract certificate installation request is received from the second EV while the second EV is roaming within the service network of the charging service providing device, it causes the second contract certificate stored in the CPS to be transmitted to the second EV and installed in the second EV.

[0203] As described above, the apparatus and methods according to exemplary embodiments of this disclosure can be implemented by computer-readable program code or instructions stored on a computer-readable intangible recording medium. The computer-readable recording medium includes all types of recording devices that store data readable by a computer system. The computer-readable recording medium can be distributed across computer systems connected via a network so that computer-readable programs or code can be stored and executed in a distributed manner.

[0204] Computer-readable recording media can include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Program instructions can include not only machine language code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or similar means.

[0205] The aspects of this disclosure described above in the context of a device may indicate a corresponding description of a method according to this disclosure, and blocks or devices may correspond to operations or features of the method. Similarly, aspects described in the context of a method may be represented by features of corresponding blocks, items, or devices. Some or all of the operations of the method may be performed using hardware devices (e.g., microprocessors, programmable computers, or electronic circuits). In some exemplary embodiments, one or more of the most important operations of the method may be performed by such a device.

[0206] In some exemplary embodiments, a programmable logic device, such as a field-programmable gate array (FPGA), may be used to perform some or all of the functions of the methods described herein. The FPGA may operate in conjunction with a microprocessor to perform one of the methods described herein. Typically, these methods may preferably be performed by a hardware device.

[0207] Although this disclosure has been described above with respect to exemplary embodiments thereof, it will be apparent to those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of this disclosure as defined in the following claims.< / newwitholdcertificate> < / metadata>

Claims

1. A method of supporting installation of contract certificate related information in an electric vehicle, comprising: providing, by a charging service provider device, CSP, having a contract relationship with a first electric vehicle, EV, first contract certificate related information of the first EV; and transmitting, by the CSP, the first contract certificate related information to a first external CSP associated with a first visited charging station operator, CSO, associated with a first visited charging station currently visited by the first EV, wherein a first roaming contract has been established between the CSP and the first external CSP to enable installation of the first contract certificate related information in the first EV via the first visited CSO, providing, by the first visited CSO, the first contract certificate related information to the first EV via the first visited charging station in response to a request for the first contract certificate related information from the first EV; wherein the first visited CSO does not belong to a service network of the CSP, and wherein the first visited CSO has no direct contract relationship with the first EV.

2. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 1, wherein, the first external CSP comprises all external CSPs having respective roaming contracts with the CSP.

3. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 2, wherein, the first external CSP comprises all external CSPs.

4. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 1, further comprising: sending, to the first external CSP, a request to release installation backup when a predetermined time has elapsed after transmitting the first contract certificate related information to the first external CSP or when the first contract certificate related information is installed in the first EV.

5. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 1, wherein, transmitting the first contract certificate related information to the first external CSP comprises: making a certificate installation package comprising a contract certificate chain and an electronic mobile account identifier, eMAID, information, the contract certificate chain comprising the first contract certificate; and transmitting the certificate installation package to the first external CSP.

6. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 5, wherein, the certificate installation package comprises a certificate revocation list associated with the first contract certificate and access information to an online certificate status protocol, OCSP, server.

7. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 1, further comprising: receiving, by the CSP, second contract certificate related information of a second EV from a second external CSP having a second contract relationship with the second EV, forwarding, by the CSP, the second contract certificate related information to a certificate provisioning service device, CPS, to enable the CPS to store the second contract certificate related information; and ​ transmitting the second contract certificate related information stored in the CPS to the second EV and installing in the second EV, when receiving a contract certificate installation request from the second EV via a second visited charging station associated with a second visited CSO in a roaming case where the second EV stays in a service network of the CSP, wherein the second visited CSO belongs to the service network of the CSP and is currently visited by the second EV, and wherein a second roaming contract has been established between the CSP and the second external CSP.

8. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 7, wherein, The second external CSP is one of all external CSPs having a corresponding roaming contract with the CSP.

9. The method of supporting installation of contract certificate related information in an electric vehicle according to claim 7, wherein, Transmitting the second contract certificate related information stored in the CPS to the second EV and installing in the second EV further comprises: After installing the second contract certificate related information in the second EV, informing the second external CSP of the installation completion.

10. A charging service providing device, comprising: a processor; and a memory storing at least one program instruction executed by the processor, wherein, when the processor executes the at least one program instruction, the processor is caused to: provide first contract certificate related information of a first electric vehicle (EV) having a first contract relationship with a charging service providing device (CSP); and transmit the first contract certificate related information to a first external CSP associated with a first visited charging station operator (CSO), wherein a first roaming contract has been established between the CSP and the first external CSP to enable the first contract certificate related information to be installed in the first EV via the first visited CSO; receive second contract certificate related information of a second EV from a second external CSP having a second contract relationship with the second EV, and forward the second contract certificate related information to a certificate provisioning service device (CPS) to enable the CPS to store the second contract certificate related information; and transmit the second contract certificate related information stored in the CPS to the second EV and install in the second EV, when receiving a contract certificate installation request from the second EV via a second visited charging station associated with a second visited CSO in a roaming case where the second EV stays in a service network of the CSP, wherein the second visited CSO belongs to the service network of the CSP and is currently visited by the second EV, wherein a second roaming contract has been established between the CSP and the second external CSP, wherein the first visited CSO associated with the first visited charging station does not belong to the service network of the CSP, wherein the first visited CSO does not have a direct contract relationship with the first EV, wherein the second EV does not have a direct contract relationship with the CSP. The first external CSP comprises all external CSPs having a corresponding roaming contract with the CSP, 11. The charging service providing apparatus according to claim 10, wherein wherein the second external CSP is one of all external CSPs having a corresponding roaming contract with the CSP. ​ 12. The charging service providing apparatus according to claim 11, wherein the first external CSP comprises all external CSPs, wherein the second external CSP is one of all external CSPs.

13. The charging service providing apparatus according to claim 10, wherein The program instructions causing the processor to transmit the first contract certificate related information to the first external CSP associated with the first visited CSO comprise program instructions causing the processor to perform the following: sending a request to release the installation backup to the first external CSP when a predetermined time elapses after the first contract certificate related information is transmitted to the first external CSP, or when the first contract certificate related information is installed in the first EV.

14. The charging service providing apparatus according to claim 13, wherein The program instructions causing the processor to transmit the second contract certificate related information stored in the CPS to the second EV and install in the second EV further comprise program instructions causing the processor to perform the following: notifying the second external CSP of the installation completion after the second contract certificate related information is installed in the second EV.

15. The charging service providing apparatus according to claim 10, wherein The program instructions causing the processor to transmit the first contract certificate related information to the first external CSP comprise program instructions causing the processor to perform the following: making a certificate installation package including a contract certificate chain and an electronic mobile account identifier eMAID information, the contract certificate chain including a first contract certificate; and transmitting the certificate installation package to the first external CSP.

16. The charging service providing apparatus according to claim 15, wherein The certificate installation package includes a certificate revocation list associated with the first contract certificate and access information to an online certificate status protocol OCSP server.

17. A method of authorizing charging of an electric vehicle (EV) in a roaming environment, comprising: providing, by a first charging service provider (CSP) having a first contract relationship with a first EV, first contract certificate related information of the first EV; transmitting, by the first CSP, the first contract certificate related information to a first external CSP associated with a first visited charging station operator (CSO) based on a first roaming contract established between the first CSP and the first external CSP to enable forwarding of the first contract certificate related information to the first visited CSO, receiving, by the first visited CSO, an authorization request including second contract certificate related information stored in the first EV from the first EV in a roaming situation where the first EV visits a first visited charging station (CS) associated with the first visited CSO; and verifying, by the first visited CSO, first visited contract certificate related information based on the first contract certificate related information, wherein the first visited CSO associated with the first visited CS does not belong to a service network of the CSP, wherein the first visited CSO does not have a direct contract relationship with the first EV.

18. The method of claim 17, wherein, The first external CSP is one of all external CSPs having a corresponding roaming contract with the CSP.

19. The method of claim 17, further comprising: identifying, by the first visited CSO, the CSP having a contract relationship with the first EV based on the first visited contract certificate related information.

20. The method of claim 17, wherein, Receiving the authorization request including the second contract certificate related information includes: Receiving a certificate installation package including a contract certificate chain and an electronic mobile account identifier (eMAID) information, the contract certificate chain including the second contract certificate related information.

Images