Method and device for supporting installation of contract certificate for electric vehicle

Abstract

To provide a method and device for enabling installation or update of a contract certificate even when an electric vehicle is in a roaming environment, and performing accurate and speedy authentication for the PnC-based charging.SOLUTION: A method for supporting installation of a contract certificate suitable for execution in a charging service providing device (CSP) comprises the steps of: generating a contract certificate for an EV; and transmitting the contract certificate to a visited CSP with which a roaming contract has been made, so as to enable the contract certificate to be installed in the EV via the visited CSP in a roaming situation. A home CSP distributes the contract certificate for the EV to all CSPs in a roaming contractual relationship in advance in preparation for an EV certificate installation request or update request in a roaming environment, thereby enabling immediate installation when the EV makes the certificate installation request or update request in the roaming environment.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present invention relates to a method and apparatus for charging an electric vehicle, and more particularly, to a method and apparatus for installing a public key certificate in an electric vehicle so as to support a roaming environment in a Plug-and-Charge (PnC) charging infrastructure. [Background technology]

[0002] An electric vehicle (EV) runs by driving a motor with the power of a battery, and has advantages over conventional gasoline engine vehicles, such as less air pollution sources such as exhaust gas and noise, fewer breakdowns, a longer lifespan, and easier operation. An electric vehicle charging system is defined as a system that charges a battery mounted on an electric vehicle using power from a commercial power grid or an energy storage device. Such an electric vehicle charging system can be realized in various forms, and may include, for example, a conductive charging system using a cable or a contactless wireless power transmission system.

[0003] Charging stations begin charging EVs after a certain approval process, which varies depending on the charging infrastructure structure and the EV's functions. ISO 15118-1, one of the international standards for electric vehicle charging, specifies two approval methods: the PnC method, in which approval and payment are completed automatically using a contract certificate stored in the EV, and a method in which identification, approval, and payment are performed using external identification means (EIM) such as credit cards, debit cards, cash, and smartphone apps. The PnC method refers to the plug-and-charge method for wired charging, in which service approval and charging are completed simply by inserting a plug between the EV and the charging station, and the park-and-charge method for wireless charging, in which service approval and charging are completed simply by parking the EV at the charging spot of the charging station.

[0004] For an EV to use the PnC service, the EV owner must enter into a service contract with the MO (Mobility Operator). After the contract is signed, a contract certificate is installed in the EV at the time of the first charging, after which the EV can receive the PnC service at charging stations associated with the MO. If an EV attempts to receive the PnC service at a charging station associated with an MO with which it has no contractual relationship, roaming occurs. If a valid contract certificate is already installed in the EV, EV owners will have no major difficulties using the charging service even in a roaming environment.

[0005] However, if an EV visiting a charging station does not have a valid contract certificate, PnC may not work. This situation may occur, for example, when the first charging station an EV visits after being shipped is one that belongs to the network of an MO with which the EV has no contractual relationship. In addition, if the contract certificate installed in the EV does not work properly for some reason, the contract certificate must be updated, but PnC may not work as described above even in such a situation where an update is required. As such, a situation may arise in which it is necessary to install or update a contract certificate in a roaming environment, but no countermeasures have been established in the past. Therefore, when PnC does not work, the charge must be paid via an external identification means (EIM), which causes inconvenience to the EV driver.

[0006] Meanwhile, in the conventional PnC, the contract certificate chain submitted by an EV to a charging station operator (CSO) via a charging station is verified by the CSO or charging service provider (CSP). However, since the MO root certificate (MO RootCA cert.), which is the top certificate of the contract certificate chain, is not installed in the EV (ISO 15118-20 standard 2018.7.2), the EV cannot submit to a visiting CSO in a roaming situation. In this case, if the visiting CSO or visiting CSP does not have this root certificate, verification can only be done by the home CSP or a separate clearinghouse, which may cause approval delays. Summary of the Invention [Problem to be solved by the invention]

[0007] The present invention provides a method and apparatus for enabling installation and updating of contract certificates even when an electric vehicle is in a roaming environment, and for enabling accurate and rapid authorization for PnC charging. [Means for solving the problem]

[0008] According to one aspect of the present invention, there is provided a method for supporting installation of a contract certificate in a charging service provider (CSP). A method for supporting installation of a contract certificate in a charging service providing device according to one embodiment of the present invention is characterized in that it includes a step of generating a first contract certificate for a first electric vehicle (EV), and a step of transmitting the first contract certificate to a first external charging service providing device (CSP) with which a roaming contract has been formed, so that the first contract certificate can be installed on the first EV via the first external CSP in a roaming situation.

[0009] The first external CSP may include all external CSPs that have a roaming contract with the charging service providing device.

[0010] The first external CSP may include all external CSPs.

[0011] The method for supporting installation of the contract certificate may further include a step of sending an installation standby release request to the first external CSP when a predetermined period of time has elapsed since the first contract certificate was transmitted to the first external CSP or when the first contract certificate is installed in the first EV.

[0012] The step of transmitting the first agreement certificate to the first external CSP may include forming a certificate installation package including an agreement certificate chain including the first agreement certificate and eMAID information, and transmitting the certificate installation package to the first external CSP.

[0013] The certificate installation package may include a certificate revocation list associated with the first contract certificate and connection information for an Online Certificate Status Protocol (OCSP) server.

[0014] The method for supporting installation of a contract certificate may further include a step of accepting a second contract certificate for a second EV from a second external CSP and transmitting it to a certificate provisioning service device (CPS) for storage, and a step of, when a request for installation of a contract certificate is received from the second EV in a roaming situation in which the second EV has entered a service network, transmitting the second contract certificate stored in the CPS to the second EV so as to be installed in the second EV.

[0015] The second external CSP may be any one of all external CSPs with which the roaming contract is established with the charging service providing device.

[0016] The step of sending the second contract certificate to the second EV and installing it in the second EV may further include a step of notifying the second external CSP of completion of installation after the second contract certificate is installed in the second EV.

[0017] According to another aspect of the present invention, there is provided a charging service providing device that can be utilized for a charging service according to a PnC method. According to one embodiment of the present invention, a charging service providing device includes a processor and a memory storing at least one instruction executed by the processor, the at least one instruction including an instruction 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 is installed in the first EV via the first external CSP, an instruction to accept a second contract certificate for a second EV from a second external CSP and transmit it to a certificate provisioning service device (CPS) to store it, and an instruction to transmit the second contract certificate stored in the CPS to the second EV so that it is installed in the second EV, when a request to install a contract certificate is received from the second EV in a roaming situation in which the second EV has entered a service network.

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

[0019] The first external CSP may include all external CSPs, and the second external CSP may be any one of all the external CSPs.

[0020] The command to transmit the first contract certificate to the first external CSP may further include a command to send an installation standby release request to the first external CSP when a predetermined period of time has elapsed since the first contract certificate was transmitted to the first external CSP or when the first contract certificate is installed in the first EV.

[0021] The instruction to send the second contract certificate to the second EV and install it in the second EV may include an instruction to notify the second external CSP of completion of installation after the second contract certificate has been installed in the second EV.

[0022] The step of transmitting the first agreement certificate to the first external CSP may include forming a certificate installation package including an agreement certificate chain including the first agreement certificate and eMAID information, and transmitting the certificate installation package to the first external CSP.

[0023] The certificate installation package may include a certificate revocation list associated with the first contract certificate and connection information for an Online Certificate Status Protocol (OCSP) server.

[0024] According to yet another aspect of the present invention, there is provided an EV charging authorization method in a PnC manner in a roaming environment. According to one aspect of the present invention, a PnC-based EV charging approval method in a roaming environment includes 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 providing device (CSP) so that the first contract certificate can be installed on the first EV via the first external CSP; accepting a second contract certificate for a second EV from a second external CSP and transmitting it to a certificate provisioning service device (CPS) to store it; and in a roaming situation in which the second EV has entered a service network, when a contract certificate installation request is received from the second EV, transmitting the second contract certificate stored in the CPS to the second EV so that it is installed on the second EV, and when the second EV makes a charging approval request, performing approval based on the state in which the second contract certificate is installed on the second EV.

[0025] The second external CSP may be any one of all external CSPs that have a roaming contract with the charging service providing device.

[0026] The step of causing the second contract certificate to be sent to the second EV and installed in the second EV may include an instruction to notify the second external CSP of completion of installation after the second contract certificate has been installed in the second EV.

[0027] Accepting and storing the second agreement certificate from the second external CSP may include accepting and storing a certificate installation package including an agreement certificate chain including the second agreement certificate and eMAID information. Effect of the Invention

[0028] According to the present invention, in preparation for a request to install or update an EV certificate, a home charging service provider (CSP) distributes a contract certificate for an EV to substantially all CSPs in advance, so that even if an EV requests to install or update a certificate in a roaming environment, the visiting CSP can immediately provide the contract certificate to the EV and install it. Therefore, even in a roaming environment, it is possible to install or update a contract certificate chain in an EV, which facilitates charging of the EV using the PnC method and improves the convenience of EV users.

[0029] In addition, various certificates other than contract certificates can be installed at visiting CSPs, visiting CSOs, and their associated CSs, improving the response capabilities of each entity and providing flexibility to the approval process for electric vehicles. [Brief description of the drawings]

[0030] [Figure 1] 1 is a conceptual diagram for explaining a wired charging method for an electric vehicle to which an embodiment of the present invention can be applied. [Diagram 2] 1 is a conceptual diagram for explaining wireless power transmission to an electric vehicle to which an embodiment of the present invention can be applied. [Diagram 3] FIG. 1 is a block diagram of an EV charging infrastructure according to one embodiment of the present invention. [Figure 4] FIG. 2 is a diagram showing an example of a hierarchical structure of a certificate applied to an embodiment of the present invention. [Diagram 5] 1 is a diagram illustrating an example of nodes constituting a PnC charging infrastructure to explain roaming services for EVs. [Figure 6] FIG. 1 illustrates examples of situations in which roaming is not required and is required. [Figure 7] 1 is a flow chart illustrating a typical contractual service authorization process in a situation where roaming is not required. [Figure 8] 1 is a flow chart illustrating a typical contractual service authorization process in a direct roaming situation. [Figure 9]1 is a flowchart showing a typical contractual service authorization process in an indirect roaming situation. [Figure 10] 1 is a flow chart illustrating a typical contractual service authorization process in an on-the-fly direct roaming situation. [Figure 11] 1 is a flowchart showing a typical service authorization process by contract in a situation where on-the-fly indirect roaming is performed. [Figure 12] 13 is a diagram showing a transmission path of a contract certificate that is directly transmitted from a home CSP to an EV through roaming and installed in an embodiment of the present invention. FIG. [Figure 13] 13 is a flowchart showing in more detail the certificate transmission process shown in FIG. 12. [Figure 14] FIG. 13 is a diagram showing a transmission path of a contract certificate transmitted from a home CSP to an EV through indirect roaming and installed in an embodiment of the present invention. [Figure 15] 15 is a flowchart showing in more detail the certificate transmission process shown in FIG. 14. [Figure 16] 10 is a flowchart illustrating a process for approving a contractual service in accordance with another embodiment of the present invention. [Figure 17] FIG. 2 is a block diagram of a CSP according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] Since the present invention can be modified in various ways and can have various embodiments, a specific embodiment will be illustrated in the drawings and described in detail in the detailed description of the invention. However, this does not limit the present invention to the specific embodiment, and it should be understood that the present invention includes all modifications, equivalents, and alternatives within the spirit and technical scope of the present invention. In describing each drawing, similar reference numerals are used for similar components.

[0032] Terms such as first, second, A, B, etc. are used to describe various components, but each component is not limited by these terms. The above terms are used only to distinguish one component from another. For example, a first component can be named as a second component, and similarly, the second component can be named as the first component, without departing from the scope of the present invention. The term "and / or" includes a combination of two or more associated listed items or any items of two or more associated listed items.

[0033] When a component is described as being "coupled" or "connected" to another component, it is directly coupled or connected to the other component, but there may be other components in between. On the other hand, when a component is described as being "directly coupled" or "directly connected" to another component, there are no other components in between.

[0034] The terms used in this specification are merely used to describe certain embodiments and are not intended to limit the present invention. A singular expression includes a plural expression unless the context clearly indicates otherwise. In this specification, the terms "include" or "have" are intended to specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and do not preclude the presence or additional possibility of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0035] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which the present invention belongs. Terms as defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the meaning they have in the context of the relevant art, and are not to be interpreted as idealized or overly formal unless expressly defined herein.

[0036] Some terms used in this specification are defined as follows:

[0037] "Electric vehicle (EV)" refers to an automobile as defined in 49 CFR (code of federal regulations) 523.3 and other regulations. An electric vehicle can be driven on highways and is powered by electricity supplied from an on-board energy storage device such as a battery that can be recharged from a power supply source outside the vehicle. The power supply source may include a residential or shared electric service, or a generator that uses on-board fuel. An electric vehicle (EV) is also called an electric car, an electric automobile, an electric road vehicle (ERV), a plug-in vehicle (PV), an xEV (plug-in vehicle), and other names, and an xEV is also called or classified as a plug-in all-electric vehicle (BEV), a plug-in electric vehicle (PEV), a hybrid electric vehicle (HEV), a hybrid plug-in electric vehicle (HPEV), a plug-in hybrid electric vehicle (PHEV), and other names.

[0038] A "plug-in electric vehicle (PEV)" is an electric vehicle that connects to the power grid to recharge the vehicle's primary battery.

[0039] "Wireless power charging system (WCS)" refers to a system for wireless power transmission and control between a GA and a VA, including alignment and communication.

[0040] "Wireless power transfer (WPT)" refers to the transmission of electrical power from an alternating current (AC) power supply network, such as a utility or grid, to an electric vehicle by non-contact means.

[0041] A "utility" is a provider of electrical energy and is generally referred to as a collection of systems that includes a Customer Information System (CIS), an Advanced Metering Infrastructure (AMI), and a Rates and Revenue system. A utility makes energy available to plug-in electric vehicles through a price schedule or discrete events. A utility also provides information such as tariff rates, intervals for metering electricity consumption, and validation of electric vehicle programs for plug-in electric vehicles.

[0042] "Smart charging" refers to a system in which an EVSE and / or plug-in electric vehicle, in communication with the power grid, optimizes the vehicle's charge or discharge rate over time relative to grid capacity or cost of use.

[0043] "Interoperability" refers to the state in which system components relative to one another can work together to perform the intended functions of the overall system. Information interoperability refers to the ability of two or more networks, systems, devices, applications or components to be easily used by users to share information securely, effectively and with little or no inconvenience.

[0044] An "inductive charging system" refers to a system that electromagnetically transfers energy from an electrical supply network to an electric vehicle through a transformer with two loosely coupled parts. In this embodiment, the inductive charging system corresponds to an electric vehicle charging system.

[0045] "Inductive coupling" refers to the magnetic coupling between two coils: the ground assembly coil and the vehicle assembly coil.

[0046] "OEM (Original Equipment Manufacturer)" refers to a server operated by an electric vehicle manufacturer and the top-level certification authority (CA) that issues OEM root certificates.

[0047] "Mobility operator (MO)" refers to a service provider that has a contractual relationship with EV owners regarding charging, authorization, and payment so that EV drivers can charge their EVs at charging stations.

[0048] A "charging station (CS)" refers to a facility that is equipped with one or more EV power supply devices and actually charges EVs.

[0049] "Charging station operator (CSO)" refers to an entity that manages electricity to provide the requested energy transmission service, and is a term with the same concept as charge point operator (CPO).

[0050] A "Charge service provider (CSP)" refers to an entity that manages and authenticates the credentials of EV users and provides billing and other value-added services to customers. CSP is considered to be a special type of MO and may be embodied in an integrated form with MO.

[0051] A "Clearing house (CH)" is an entity that handles coordination matters between MOs, CSPs, and CSOs, and may act as an intermediary to facilitate approval, billing, and settlement procedures for roaming EV charging services between the two clearing or settlement parties.

[0052] "Roaming" refers to the information exchange and related provisions and schemes that enable EV users to access charging services offered by multiple CSPs or CSOs belonging to multiple mobility networks using one credential and contract.

[0053] A "credential" is a physical or digital asset that represents an EV or the personal information of an EV's owner, and may include cryptographic information used to verify identity such as a password, a public / private key pair used in public key cryptography algorithms, a public key certificate issued by a certification authority, or information about trusted root certification authorities.

[0054] "Certificate" means an electronic document that binds a public key to an identity through a digital signature.

[0055] A "service session" refers to a collection of services related to electric vehicle charging at a charging point assigned to a customer during a certain time frame having a unique identifier.

[0056] “e-Mobility Account Identifier (eMAID)” means a unique identifier for an EV that links the Agreement Certificate to the payment account of the EV owner.

[0057] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings.

[0058] In an electric vehicle charging system for implementing the present invention, an electric vehicle (EV) is connected to a charging station via a wired or wireless link, receives energy from the charging station, and charges an energy storage device, such as a battery, with the supplied energy. Figures 1 and 2 show methods of charging an electric vehicle via a wired or wireless connection, respectively.

[0059] 1 is a conceptual diagram for explaining a wired charging method for an electric vehicle to which an embodiment of the present invention can be applied. Wired charging of an electric vehicle is performed by connecting an electric vehicle (10, hereinafter referred to as "EV") to a power supply circuit of a charging station by a charging cable (30), for example, by connecting a cable connector of the charging station (20) to a jack of the EV (10).

[0060] Here, the EV 10 is defined as an automobile that uses electric power from a rechargeable energy storage device such as a battery as an energy source for an electric motor, which is a power unit. The EV 10 may be a hybrid vehicle that has both an electric motor and a general internal combustion engine, and may be not only an automobile, but also a motorcycle, cart, scooter, or electric bicycle.

[0061] The EV 10 includes a plug connection port or receptacle that is connected to a connector of the charging cable 30. The plug connection port of the EV 10 may support slow charging or fast charging. In this case, the EV 10 may support both slow charging and fast charging through a single plug connection port, or may include multiple plug connections each supporting slow charging and fast charging.

[0062] The EV (10) according to the present invention may include an on-board charger to support slow charging or charging with AC power supplied from a general power grid. The on-board charger boosts AC power supplied via a wire from an external source during slow charging, converts it into DC power, and supplies it to a battery built into the EV (10). Meanwhile, when DC power for fast charging is supplied to a plug connection port, the DC power can be supplied to the battery without passing through the on-board charger to charge the battery.

[0063] Meanwhile, the EV charging cable (30) includes at least one of a charging connector (31), a power outlet socket connection portion (33), and an in-cable control box (ICCB) (32). The charging connector (31) is a connection portion electrically connected to the EV (10), and the in-cable control box (32) communicates with the EV (10) to receive EV status information or control charging of power to the EV (10). Although the in-cable control box (32) is shown as being included in the EV charging cable (10), it may be located at a position other than the EV charging cable (10), for example, connected to a power supply circuit (not shown) that supplies power to the EV (10) at the charging station, or disposed within the power supply circuit. The power outlet socket connection portion (33) is connected to a charging device at the charging station as an electrical connection mechanism such as a general plug or cord set.

[0064] Meanwhile, the power socket 40 refers to a connection point between the charging device of the charging station and the charging connector 31. However, the present invention is not limited thereto, and the power socket 40 may refer to a connection point between the charging device installed at other locations and the charging connector 31. For example, the power socket 40 refers to a wall jack installed in charging facilities such as a parking lot attached to the home of an EV 10 owner, a parking area allocated for EV charging at a gas station, a parking area at a shopping center or workplace, etc., in addition to a commercial specialized charging station facility.

[0065] FIG. 2 is a conceptual diagram for explaining wireless power transmission to an electric vehicle to which one embodiment of the present invention can be applied.

[0066] Wireless power transfer (WPT) for EVs is defined as the transfer of electrical energy from a supply network from a supplier device to a consumer device through a magnetic field in a magnetic resonance state, without the flow of current through a galvanic connection. Wireless power transfer is utilized to transfer power to an EV (10) at a charging station (10) to charge the EV (10).

[0067] Referring to FIG. 2, wireless power transfer is performed by at least one component of the EV (10) and a charging station (20) to wirelessly transfer power to the EV (10).

[0068] The EV (10) includes a receiving pad (11) with a receiving coil for wirelessly receiving magnetic energy from a charging station (20). The receiving coil in the receiving pad (11) receives magnetic energy from a transmitting coil in a transmitting pad (21) in the charging station (20), for example, by magnetic resonance. The magnetic energy received by the EV (10) is converted into an induced current, which is rectified into a direct current and then charges the battery (12).

[0069] The charging station (20) receives power from a commercial power grid (50) or power backbone and supplies energy to the EV (10) through a transmission pad (21). The transmission pad (21) includes a transmission coil. The transmission coil in the transmission pad (21) generates a magnetic flux and supplies the amplified magnetic energy to the EV (10) through magnetic resonance. The charging station (20) may be located in a variety of locations, such as a parking lot attached to the home of the owner of the EV (10), a parking area for EV charging at a gas station, a parking area at a shopping center or a commercial building, and the like.

[0070] The charging station 20 communicates with a power infrastructure management system or an infrastructure server that manages the power grid 50 through wired / wireless communication. The charging station 20 also communicates wirelessly with the EV 10. Here, the wireless communication may include a wireless LAN (WLAN) based on WiFi (registered trademark) conforming to the IEEE 802.11 standard, and may further include P2PS communication using a low frequency (LF) magnetic field signal and / or a low power excitation (LPE) magnetic field signal. Furthermore, the wireless communication between the charging station 20 and the EV 10 may include one or more of various communication methods such as Bluetooth (registered trademark), zigbee (registered trademark), and cellular.

[0071] Meanwhile, according to ISO 15118, a communication standard document for charging electric vehicles, an EV and an EV charging station exchange messages to control the entire charging process. That is, communication for charging an electric vehicle is performed between an Electric Vehicle Communication Controller (EVCC) and a Supply Equipment Communication Controller (SECC) via a wireless LAN (WLAN).

[0072] During the communication process, the EV first verifies the identity of the charging station to determine whether the charging station is a trustworthy facility, and then sets up a security channel with the charging station to protect communication from unauthorized access. These goals are achieved by the standardized Transport Layer Security (TLS) defined in IETF RFC 5246. A TLS session is created by the TLS session establishment procedure after the IP-based communication connection establishment procedure.

[0073] FIG. 3 is a block diagram of an EV charging infrastructure according to one embodiment of the present invention.

[0074] The EV charging infrastructure is for providing charging services to EVs (10), and includes an original equipment manufacturer (ORM) server (100), a mobility operator (MO) (110), a certificate provisioning service (CPS) (120), a contract certificate pool (CCP) (130), a vehicle-to-ground (V2G) server (150), a charging station (CS) (200), a charging station operator (CSO) (210), a charge service provider (CSP) (220), and a clearing house (CH) (230).

[0075] The EV (100) refers to a general automobile owned by an EV owner, and can be charged at a charging station by wired or wireless connection. The EV (100) is provided with an OEM provisioning certificate during its unique manufacturing process. In addition, when a vehicle purchase contract and a contract with an operator of the MO (110) are completed, the EV (100) may be provided with a contract certificate. In addition, the EV (100) may be provided with a vehicle-to-ground (V2G) root certificate.

[0076] The server (100) of an electric vehicle manufacturer (original equipment manufacturer) is a top-level certificate authority (CA) that issues OEM root certificates, and also operates and maintains its subordinate certificate authorities (OEM SubCA 1, OEM SubCA 2). When an EV (10) is manufactured, the OEM (100) generates an OEM provisioning certificate using the OEM intermediate CA certificate (OEM SubCA 2 cert.) and installs it in the EV (10).

[0077] A Mobility Operator (MO) (110) is a service provider that has a contractual relationship with an EV owner regarding charging, authorization, and payment so that an EV driver can charge the EV at a charging station. For an EV to receive charging service at a current charging station, the current charging station must belong to the MO or support roaming scenarios. The MO (110) may be operated by an electricity supplier or an electricity wholesaler that sells energy. The MO (110) also functions as a top-level certification authority (CA) that issues an MO root certificate. The MO certificate chain, which is composed of the MO root certificate and the MO intermediate CA certificate generated by the subordinate CA, is used when generating a contract certificate. Furthermore, according to the present invention, the MO certificate chain is also used to verify the contract certificate installed in the EV (10) in a non-roaming environment and a roaming environment. The MO is also referred to as an "E-mobility service provider (EMSP)".

[0078] A certificate provisioning service (CPS) (120) provides clients such as EV with encryption keys used to send and receive certificates along with the contract certificate chain during the process of installing or updating a contract certificate in EV. The CPS (120) is attached with a leaf provisioning certificate (Leaf Prov cert.) and provisioning intermediate CA certificates (Prov SubCA 1 cert., Prov SubCA 2 cert.). When a contract certificate is installed or updated in EV (100), the CPS (130) provides a provisioning service that provides the contract certificate chain along with the public key, Diffie-Hellman (DH) public key, and eMAID of each MO, so that EV can use these to verify the contract certificate chain and confirm the integrity and authenticity of the contract certificate.

[0079] The Contract Certificate Pool (CCP) (130) temporarily stores the response message for the installation or update during the process of installing or updating a contract certificate in an EV. Considering that the installation and update time limit specified in the ISO 15118 standard is very short and strict, the response message is stored in the CCP (140) in advance and is maintained until the installation or update is completely completed. Since there may be multiple EVs where a contract certificate is installed or updated, the response message is assigned a reference number and then maintained in the form of a directory.

[0080] A Vehicle-to-Ground (V2G) server (150, hereinafter abbreviated as "V2G") functions as a top-level certification authority in association with a Public Key Infrastructure (PKI) in the illustrated EV charging infrastructure. Thus, the V2G (150) serves as a top-level trust anchor, and all actors shown in FIG. 3 are considered to be organizations that can trust the V2G Root CA.

[0081] The charging station (CS) (200) actually charges the EV (100). The charging station (200) may include at least one wired charger and / or wireless charging spot. One or more charging stations (200) may be installed in a commercial specialized charging facility. The charging station (200) may be located in various locations such as a parking lot attached to an EV owner's residence, a parking area for EV charging at a gas station, a parking area at a shopping center or workplace, etc. The charging station (200) may be referred to as a "charging point," "EV charging station," "electric charging point," "charging point," "electronic charging station (ECS)," and "EV side power supply equipment (EVSE)."

[0082] Charging station operators (CSOs) (210) and charge point operators (CPOs) operate charging stations and manage electricity to provide the requested energy transmission services. The CSOs (210) are operated, for example, by charging station manufacturers, charging station manufacturers, or electricity suppliers. In relation to PKI, the CSOs (210) operate subordinate certificate authorities (CPO SubCA 1, CPO SubCA 2) required for generating SECC leaf certificates for each charging station.

[0083] A charge service provider (CSP) (220) manages and authenticates the credentials of EV users and provides billing and other value-added services to customers. The CSP (220) is considered to be a special type of MO (110) and may be implemented in a form integrated with the MO (110). There may be multiple CSPs (220), and each CSP (220) is linked to one or more CSOs (210), and the CSP (220) and one or more CSOs (210) constitute one charging network. An EV (110) can receive charging services in a PnC manner at a CSO (210) linked to a CSP (220) associated with an MO (100) with which it has a contractual relationship, but roaming is required if the EV (110) wishes to charge at another CSO (210). Each CSP (200) can exchange information with other CSPs or CSOs (210) in other networks for roaming purposes, and can also exchange information with a clearinghouse (230).

[0084] The Clearing House (CH) (230) handles matters of cooperation between the MO and the CSP (220). That is, the Clearing House (CH) (230) may act as an intermediary to facilitate the approval, billing, and settlement procedures for EV charging service roaming between the two clearing or settlement parties. When an EV driver wishes to charge his / her EV at a charging station that is not part of the network of the MO (110) with which he / she has a contractual relationship, the CH (230) helps the CSO (210) or CSP (220) to connect and roam. In situations where roaming is required, the CH (230) allows the CSO (210) or CSP (220) to enter into a contract with the MO (110) and transmit the approval and billing data (CDR) to the MO (110). The CH (230) may be referred to as a "Contract clearing house (CCH)," a "Mobility clearing house (MCH)," a "roaming platform," an "E-MObility clearing house (E-MOCH)," etc.

[0085] Although the terms "Charging Station Operator (CSO)", "Certificate Provisioning Service (CPS)", "Mobility Operator (MO)", "Contract Clearing House (CCH)", and "V2G" may appear to refer to people or human organizations, these terms herein are embodied in hardware, software, and / or a combination thereof, and are short and functionally named to enhance readability. In one embodiment, these components may be embodied in a combination of hardware and software, and may be a server device that allows access to other devices via a network such as the Internet. Since these components are functionally separate, two or more of them may be stored and executed in one physical device, or may be integrated in one program. In particular, a single entity may serve as both the CSO and the CSP, and another single entity may serve as both the CPS and the CCP. However, one or more of the above components may be reorganized to have a different appearance and name.

[0086] Meanwhile, EV charging services and related infrastructure are fields where various industrial sectors such as automobiles, power grids, energy, transportation, communications, finance, and electronics are integrated, and standardization work has been conducted in parallel from various perspectives, as well as individual national standardization in addition to standardization by multiple international standardization organizations, resulting in many terms with similar concepts. In particular, a charging station operator (CSO) has commonalities in terms of roles and functions with a charging point operator (CPO), and although there may be some functional differences and differences in nuance, they are terms that refer to substantially the same entity. In addition, a charging service operator (CSP) has at least partial commonalities in terms of roles and functions with a mobility operator (MO), and is a term that is used interchangeably or interchangeably. In interpreting this specification, such real circumstances must be taken into consideration.

[0087] In the infrastructure shown in Figure 3, a Public Key Infrastructure (PKI) is used as the foundation for the operation of PnC. PKI provides a framework for verifying the identity of people and devices, activating secure communications, and ensuring controlled access to resources. Figure 4 shows an example of a PKI-based certificate hierarchy applied to an embodiment of the present invention. The illustrated certificate hierarchy conforms to the ISO 15118 standard.

[0088] 4, the OEM (100) functions as a top-level certification authority (CA) that issues the OEM root certificate (OEM RootCA cert.) and also operates its subordinate certificate authorities (OEM SubCA 1, OEM SubCA 2). Thus, the OEM (100) generates OEM intermediate CA certificates (OEM SubCA 1 cert. cert., OEM SubCA 2 cert.) by signing the OEM root certificate (OEM RootCA cert.) with its own private key. When the EV is manufactured, the secondary intermediate CA (OEM SubCA 2) of the OEM (100) generates an OEM provisioning certificate (OEM Prov cert.) using a private key that is paired with the public key included in the OEM secondary intermediate CA certificate (OEM SubCA 2 cert.) and installs it in the EV (10). This OEM provisioning certificate (OEM Prov cert.) is used to verify the signature of the request message during the certificate installation request process for the EV (10), enabling unique identification of the vehicle over the life of the EV (10).

[0089] The MO (110) also functions as a top-level certification authority (CA) that issues the MO root certificate (MO RootCA cert.). The MO (110) generates the first intermediate CA certificate (MO SubCA 1 cert.) by adding its own signature to the ID and public key of the first subordinate CA (MO SubCA 1). The MO's first subordinate CA (MO SubCA 1) generates the second intermediate CA certificate (MO SubCA 2 cert.) by adding its own signature to the ID and public key of the second subordinate CA (MO SubCA 2). Based on the contract concluded between the operator of the MO (110) and the owner of the EV when the EV is shipped, the MO's second intermediate CA (MO SubCA 2) generates a contract certificate using a private key that is paired with the public key included in the MO's second intermediate CA certificate (MO SubCA 2 cert.) and installs it in the EV (10), for example, through the CS (200) that the EV (10) visits first. The contract certificate is linked to the EV owner's payment account through a unique identifier called the e-Mobility Account Identifier (eMAID).

[0090] As shown in the figure, the OEM provisioning certificate (OEM Prov cert.) and the contract certificate (Contract Certificate) are generated based on the root certificates (OEM RootCA cert., MO RootCA cert.) generated by the OEM (100) and the MO (110), respectively, and are generated based on the global root certificate (V2G RootCA cert.), and are independent of the certificates used by other actors. However, as shown by the dashed lines in Figure 3, it is possible to generate the OEM provisioning certificate (OEM Prov cert.) and the contract certificate (Contract Certificate) using the V2G root certificate (V2G RootCA cert.) instead of the root certificates (OEM RootCA cert., MO RootCA cert.) of the OEM (100) and the MO (110).

[0091] The V2G (150) allows the generation of at least two series of certificates: a series of certificates for the CSO (210, which as mentioned above is a synonym for "CPO") and CS (200), and a series of certificates for the provisioning service.

[0092] First, the V2G (150) generates a first intermediate CA certificate (CPO SubCA 1 cert.) by adding its own signature to the ID and public key of the CPO's first subordinate CA (CPO SubCA 1). The CPO's first subordinate CA (MO SubCA 1) generates a second intermediate CA certificate (CPO SubCA 2 cert.) by adding its own signature to the ID and public key of the CPO's second subordinate (CPO SubCA 2). The CPO's second intermediate CA (CPO SubCA 2) generates a SECC leaf certificate using a private key that is paired with the public key included in the CPO's second intermediate CA certificate (CPO SubCA 2 cert.) and transmits it to the CS (200) for installation. This SECC leaf certificate is used by the EV (10) during TLS communication setup to verify that the EV (10) is communicating with a real charging station and not a fake charging station. This certificate is stored inside the backend of the CSO (210) as well as the CS (200).

[0093] The V2G (150) generates a first intermediate CA certificate (Prov SubCA 1 cert.) by adding its own signature to the ID and public key of the first provisioning subordinate CA (Prov SubCA 1). The first provisioning subordinate CA (Prov SubCA 1) generates a second intermediate CA certificate (Prov SubCA 2 cert.) by adding its own signature to the ID and public key of the second provisioning subordinate (Prov SubCA 2). The second provisioning intermediate CA (CPO SubCA 2) generates a leaf provisioning certificate (Leaf Prov Certificate) using a private key that is paired with the public key included in the second provisioning intermediate CA certificate (Prov SubCA 2 cert.) and transmits it to the certificate provisioning service (CPS, 120) for installation.

[0094] Meanwhile, each root CA (V2G RootCA, MO RootCA, OEM RootCA) issues and provides OCSP certificates so that various clients can connect to an OCSP server via the Online Certificate Status Protocol (OCSP) to request revoked / unrevoked status information on the validity of a certificate and receive the query results. For simplicity, the diagram shows that the OCSP certificate is available only to the subordinate CAs of CPO (CPO SubCA 1, CPO SubCA 2), but all root CAs (V2G RootCA, MO RootCA, OEM RootCA) can issue and provide OCSP certificates to query the validity of certificates in their own root certificate series.

[0095] In the embodiment of the present invention, the certificate is checked and verified by three commonly available methods. First, the certificate recipient checks the integrity of the certificate by decrypting the signature value in the certificate with the public key in the certificate to restore the hash, and comparing whether the restored hash is the same as the hash included in the certificate. Second, the certificate recipient checks the integrity and reliability of each certificate by comparing the owner information of each certificate in the certificate chain from the root certificate to the leaf certificate with the issuer information of its subordinate CA. Third, the certificate recipient checks whether the certificate has been revoked through a Certificate Revocation List (CRL) received from the root CA for the corresponding certificate, or checks the certificate status with an OCSP server linked to the root CA to verify the validity.

[0096] FIG. 5 is a diagram illustrating an example of nodes constituting a PnC charging infrastructure structure to explain a roaming service for EVs. In the illustrated example, a first EV (EV1) is in a contractual relationship with a first CSP (CSP1) and can use a charging service at an electric vehicle power supply equipment (EVSE: EV Supply Equipment) of a first CS (CS1) connected to a first CSO (CSO1) belonging to the network of the first CSP (CSP1). Also, a second EV (EV2) is in a contractual relationship with a second CSP (CSP2) and can use a charging service at an electric vehicle power supply equipment (EVSE: EV Supply Equipment) of a second CS (CS2) connected to a second CSO (CSO2) belonging to the network of the second CSP (CSP2). In other words, the first EV (EV1) and the second EV (EV2) can be charged without any particular problems at the CSs connected to their respective home CSOs (CSO1, CSO2). However, when a first EV (EV1) visits a second CS (CS2) under the jurisdiction of a second CSO (CSO2), or when a second EV (EV2) visits a first CS (CS1) managed by a first CSO (CSO1), a roaming environment is formed, and particularly in such an environment, a situation may arise in which a certificate must be installed or updated in the EV, as described below.

[0097] FIG. 6 is a diagram showing examples of situations in which roaming is not necessary and is necessary.

[0098] In the infrastructure for PnC approval, an EV is automatically approved, charged, and paid for simply by connecting it to a charging station (CS) and electric vehicle power supply equipment (EVSE). In order for such PnC approval to be applied, the EV owner must enter into a service contract with the MO and CSP. After the contract is concluded, a contract certificate is installed in the EV, and identity authentication, charging approval, and payment are performed based on this contract certificate. Therefore, an EV owner simply needs to visit a CS managed by a CSO that belongs to the network of the MO and CSP that has a contractual relationship with the EV and plug in the EV, or park the EV on top of a wireless charging spot, and the EV will automatically present the contract certificate and be approved and able to receive charging services.

[0099] There may be multiple MOs and CSPs in the EV charging infrastructure, and each MO and CSP constitutes an independent network in terms of whether or not PnC is permitted. Each EV can freely use the PnC service in the network to which the MO and CSP it has a contractual relationship with belongs, but the PnC service may be limited or unavailable in other networks. For example, in FIG. 5, an EV is connected to a first CSP (CSP A ), EV has a contractual relationship with the first CSP (CSP A ) belongs to the network, and the first CSP (CSP A ) Related CSOs A The PnC service can be used with EVSE managed by.

[0100] In response to this, EVs are the second CSP (CSP X ), EV has a contractual relationship with the first CSP (CSP A ) belongs to the network, for example, the first CSP (CSP A ) Related CSOs A However, if you visit a CSP (e.g., CSPA ) and the home CSP (e.g., CSP X If a roaming contractual relationship is formed between the visiting CSO (CSO A ) will notify the home CSP (CSP) when an approval request is received from the EV. A ) to perform PnC service for EV. Also, if you visit CSP (CSP A ) and Home CSP (CSO X ) has an indirect roaming contractual relationship with the visiting CSO (CSO A ) may provide PnC services to EVs under the auspices of the clearinghouse when an approval request is received from the EV.

[0101] A general approval process will now be described in detail with reference to FIGS.

[0102] FIG. 7 is a flow chart illustrating a typical contractual service authorization process when roaming is not required.

[0103] In the illustrated example, the supply equipment communication controller (SECC) of the CS encrypts a random number with its own private key to generate a challenge (GenChallenge) and transmits the generated challenge to the electric vehicle communication controller (EVCC) of the EV (step 600). The CS stores the challenge value at least until it receives a subsequent message from the EV. Upon receiving the challenge, the EV decrypts the challenge with the CS public key, encrypts an authorization request message (AuthorizationReq) including a number selected according to a predefined rule with its own private key, and returns the message to the CS as a response to the challenge (step 602). At this time, the authorization request message (AuthorizationReq) includes the contract certificate chain of the EV.

[0104] The CS decrypts the signature value included in the authorization request message (AuthorizationReq) with the EV public key to restore the hash, and compares the restored hash with the hash included in the authorization request message to verify the signature value of the authorization request message (step 604). At this time, the CS may additionally determine whether the response value included in the authorization request message corresponds to the challenge.

[0105] Next, the CS transmits the contract certificate chain received from the EV to the CSO (step 606). The CSO verifies the contract certificate chain (step 608). The contract certificate chain is verified by comparing the owner information of each certificate in the certificate chain in order from the root certificate to the leaf certificate with the issuer information of its subordinate CA, as described above, thereby verifying the integrity and reliability of each certificate.

[0106] The CSO then transmits the contract certificate chain to the CSP (step 610). The CSP checks whether each certificate in the contract certificate chain has been revoked by using a certificate revocation list (CRL) or by consulting an OCSP server (step 612). Depending on the check result, the CSP sends an approval message to the CS to approve the contract, i.e., the transaction (step 614). Upon receiving the approval message, the CS sends an approval result message (Authorizat'Res) to the EV (step 616).

[0107] However, in this approval process, since the MO root certificate (MO RootCA cert.), which is the top certificate of the contract certificate chain, is not installed in the EV (ISO 15118-20 standard 2018.7.2.), when the EV sends the contract certificate chain to the CS in step 602, only the contract certificate itself (the leaf certificate) and the intermediate CA certificates (MO SubCA 1 cert., MO SubCA 2 cert.) are included, and the MO root certificate (MO RootCA cert.) is excluded. As a result, the CSO that receives the certificate chain from the CS in step 608 will also verify the contract certificate chain without the MO root certificate (MO RootCA cert.), and unless the CSO has a separate MO root certificate (MO RootCA cert.), the certificate verification may be incomplete. It goes without saying that the CSP root certificate (CSP RootCA cert.) held by the CSO cannot replace the MO root certificate (MO RootCA cert.). In addition, since it cannot be determined whether the CSP has access to the CRL and OCSP servers associated with the MO Root CA in addition to the CRL and OCSP servers associated with the CSP Root CA, the confirmation of whether the certificate has been revoked in step 612 may also be incomplete.

[0108] Figure 8 is a flow chart showing a typical contractual service authorization process in a direct roaming situation. In the illustrated example, it is assumed that the visited CSO managing the CS does not belong to the network of the home CSP that has a contract with the EV, but a roaming contractual relationship has been formed between the visited CSP and the home CSP.

[0109] In this case, steps 600 to 604 can be performed in the same manner as in Fig. 7. That is, the CS transmits a challenge to the EV (step 600), and in response, the EV transmits an authorization request message (AuthorizationReq) to the CS (step 602). The CS also checks the signature value of the authorization request message (AuthorizationReq) (step 606).

[0110] Next, the CS transmits the contract certificate chain received from the EV to the visiting CSO (step 626). The visiting CSO verifies the contract certificate chain (step 628). At this time, the visiting CSO may know a path to access the home CSP through the eMAID. In this way, the visiting CSO verifies the home CSP and transmits the contract certificate chain to the home CSP (step 630). The home CSP verifies whether each certificate in the contract certificate chain has been revoked by using a certificate revocation list (CRL) or by consulting an OCSP server (step 632). Depending on the verification result, the home CSP transmits an approval message to the CS to approve the contract, i.e., the transaction (step 634). Upon receiving the approval message, the CS transmits an approval result message to the EV (step 636).

[0111] However, even in this case, the visiting CSO verifies the contract certificate chain without the MO root certificate in step 628, and unless the visiting CSO secures the MO root certificate (MO RootCA cert.) in addition to the CSP root certificate (CSP RootCA cert.), the certificate verification may be incomplete. Also, since it cannot be determined whether the home CSP can access the CRL and OCSP servers linked to the MO root CA in addition to the CRL and OCSP servers linked to the CSP root CA, the confirmation of revocation status of each certificate in step 632 may also be incomplete.

[0112] Figure 9 is a flow chart showing a typical service authorization process by contract in the indirect roaming situation. In the illustrated example, it is assumed that the visiting CSO that manages the CS does not belong to the network of the home CSP that has a contract with the EV, but an indirect roaming contractual relationship is formed between the visiting CSP and the home CSP via a clearinghouse.

[0113] In this case, steps 600 to 604 may be performed in the same manner as in Figures 7 and 8. That is, the CS transmits a challenge to the EV (step 600), and in response, the EV sends an authorization request message (AuthorizationReq) to the CS (step 602). The CS also checks the signature value included in the authorization request message (AuthorizationReq) (step 606). Then, the CS transmits the contract certificate chain received from the EV to the visiting CSO (step 646).

[0114] Since the visiting CSO does not have a direct contractual relationship with the home CSP that has a contract with EV, the visiting CSO cannot identify the home CSP from information such as eMAID held by the visiting CSO. However, since the visiting CSO has a contractual relationship with the clearinghouse, the visiting CSO checks whether the clearinghouse can identify the home CSP and which clearinghouse can identify the home CSP (step 648). After checking that the clearinghouse knows at least one home CSP (step 650), the visiting CSO transmits the contract certificate chain to the corresponding clearinghouse (step 652). After the clearinghouse verifies the contract certificate chain (step 654), it transmits the contract certificate chain to the home CSP (step 656). For each certificate in the contract certificate chain, the home CSP checks whether the certificate has been revoked by using a certificate revocation list (CRL) or by consulting an OCSP server (step 657). Depending on the result of the check, the home CSP transmits an approval message approving the contract, i.e., the transaction, to the CS (step 658). Upon receiving the approval message, the CS transmits an approval result message to the EV (step 659).

[0115] Even in this case, unless the clearinghouse secures the MO root certificate (MO RootCA cert.) separately from the CSP root certificate (CSP RootCA cert.) in step 654, the validation of the certificates may be incomplete. Also, since it cannot be determined whether the home CSP has access to the CRL and OCSP servers associated with the MO root CA in addition to the CRL and OCSP servers associated with the CSP root CA, the revocation status check for each certificate in step 657 may also be incomplete.

[0116] Figure 10 is a flow chart showing a typical service authorization process by contract in the case of on-the-fly direct roaming. In the illustrated example, it is assumed that the visiting CSO that manages the CS does not belong to the network of the home CSP that has a contract with the EV, but the visiting CSO can enter into an on-the-fly direct roaming contract with the home CSP.

[0117] In this case, steps 600 to 604 may be performed in the same manner as in Figures 7 and 8. That is, the CS transmits a challenge to the EV (step 600), and in response, the EV transmits an authorization request message (AuthorizationReq) to the CS (step 602). The CS also checks the signature value included in the authorization request message (AuthorizationReq) (step 606). The CS delivers the contract certificate received from the EV to the visiting CSO (step 666).

[0118] The visiting CSO then establishes an instant roaming agreement with the home CSP (step 668). The visiting CSO then verifies the agreement certificate chain (step 670). The visiting CSO knows the path to access the home CSP through the eMAID. As a result, the visiting CSO transmits the agreement certificate chain to the home CSP (step 672). The home CSP checks whether each certificate in the agreement certificate chain has been revoked by using a certificate revocation list (CRL) or by consulting an OCSP server (step 674). Depending on the check result, the home CSP sends an approval message to the CS to approve the agreement, i.e., the transaction (step 676). Upon receiving the approval message, the CS sends an approval result message to the EV (step 678).

[0119] Even in this case, unless the visiting CSO secures the MO RootCA cert. separately from the CSP RootCA cert. in step 670, the certificate validation may be incomplete. Also, since it cannot be determined whether the home CSP has access to the CRL and OCSP servers associated with the MO RootCA in addition to the CRL and OCSP servers associated with the CSP RootCA, the revocation status check for each certificate in step 674 may also be incomplete.

[0120] FIG. 11 is a flow chart showing a typical service approval process by contract in a situation where on-the-fly indirect roaming is performed. In the illustrated example, the visiting CSO that manages the CS does not belong to the network of the home CSP that has a contract with the EV, and there is no indirect roaming contractual relationship between the visiting CSP and the home CSP via a clearinghouse. Therefore, the visiting CSO does not know the home CSP, nor does it know the clearinghouse that has a contractual relationship with the home CSP. However, it is assumed that the visiting CSO can request the clearinghouse to establish a contract with the home CSP online.

[0121] In this case, steps 600 to 604 may be performed in the same manner as in Figures 7 and 9. That is, the CS transmits a challenge to the EV (step 600), and in response, the EV transmits an authorization request message (AuthorizationReq) to the CS (step 602). The CS also checks the signature value included in the authorization request message (AuthorizationReq) (step 606). Then, the CS transmits the contract certificate received from the EV to the visiting CSO (step 686).

[0122] As assumed above, the visiting CSO does not have a direct contractual relationship with the home CSP that has a contract with the EV, and therefore cannot identify the home CSP from information such as the eMAID held by the visiting CSO. Furthermore, the visiting CSO attempts to identify a clearinghouse that already has a contractual relationship with the home CSP, but fails (step 688). In this case, the visiting CSO requests the clearinghouse to confirm the home CSP and conclude a contract with the home CSP (step 690). Here, the contract may include one-off power charging and payment agency for the EV. When a contract is concluded between the clearinghouse and the home CSP (step 692), the clearinghouse verifies the contract certificate chain (step 694) and then transmits the contract certificate chain to the home CSP (step 696). The home CSP checks whether each certificate in the contract certificate chain has been revoked by using a certificate revocation list (CRL) or by consulting an OCSP server (step 697). Depending on the result of the check, the home CSP transmits an approval message approving the contract, i.e., the transaction, to the CS (step 698). Upon receiving the approval message, the CS transmits an approval result message to the EV (step 699).

[0123] Even in this case, unless the clearinghouse secures the MO RootCA cert. separately from the CSP RootCA cert. in step 694, the validation of the certificates may be incomplete. In addition, since it cannot be determined whether the home CSP has access to the CRL and OCSP servers associated with the MO RootCA in addition to the CRL and OCSP servers associated with the CSP RootCA, the revocation status check for each certificate in step 697 may also be incomplete.

[0124] Meanwhile, as mentioned above, according to the ISO 15118 standard, the CSP issues a contract certificate to the EV as a subordinate CA of the MO. That is, when the EV presents the OEM provisioning certificate stored in it at the time of shipment to the CSO, the CSO issues a contract certificate and transmits it to the EV. The contract certificate is stored in the EV and presented to the CS for each PnC charging, allowing the CS or other secondary actors to identify the EV's contract.

[0125] However, a situation may occur where an EV visits a charging station (CS) and requests PnC charging without such a contract certificate installed in the EV. For example, an EV user must transmit the OEM provisioning certificate installed in the EV at the time of shipment to a CSP or MO at the time of first charging to be issued a contract certificate. However, a CS visited by an EV for first charging is a charging station related to a visited CSO that does not belong to the home CSP's network. In such a case, a situation occurs where a contract certificate must be installed in the EV under roaming conditions. This situation may also occur immediately after a name change due to the sale or purchase of an EV or immediately after a memory failure of the EV. Furthermore, the certificate that must be installed in the EV in a roaming situation may be other certificates, not limited to a contract certificate. The ISO 15118 standard, which specifies protocol requirements on the network layer and application layer of the V2G communication interface, and the IEC 63119-1 standard, which specifies information exchange items for EV charging roaming services, do not specify anything about this.

[0126] According to an embodiment of the present invention, each CSP having a contractual relationship with each EV allows the EV to receive and install or update a contract certificate and other necessary certificates or data in any roaming situation. Hereinafter, a method for installing or updating a certificate in an EV according to an embodiment of the present invention will be described.

[0127] FIG. 12 illustrates a transmission path of a contract certificate that is directly transmitted from a home CSP to an EV through roaming and installed in the EV in accordance with an embodiment of the present invention.

[0128] In this embodiment, it is assumed that the contract certificate stored in the home CPS (CPSH) must be installed in the EV or the existing certificate in the EV must be updated to this certificate. Currently, the EV is in a state of visiting a CS connected to a visited CSO (CSOV) belonging to a network of a visited CSP (CSPV). However, if the home CSP (CSPH) and the visited CSP (CSPV) have a roaming contract relationship, the EV can install the contract certificate stored in the home CPS (CPSH) or update the existing certificate to this certificate by direct roaming.

[0129] FIG. 13 is a flowchart showing in more detail the certificate transmission process shown in FIG.

[0130] First, an EV owner and an operator of a home CSP conclude a charging service contract (step 700). After concluding the contract, the home CSP generates a contract certificate for the EV (step 702). The generated certificate includes the EV's public key, a hash of the public key, and a signature value obtained by encrypting the hash with the private key of an intermediate CA (MO Sub 1 or MO Sub 2) of the MO root CA. The generated certificate may be distributed to all visited CSPs that have roaming contracts with the home CSP (steps 704 to 708).

[0131] In an exemplary embodiment, steps 700 to 708 may be performed preemptively before the EV transmits a certificate installation request message (CertificateInstallationReq) or a certificate update request message (CertificateUpdateReq) to the visited ESO through the CS. That is, when the EV requests the visited CSP to install or update a certificate, the home CSP distributes a certificate installation package to all visited CSPs with which it has a contract relationship in advance so that the visited CSPs can store the package in their own CPSs in order to support the EV. At this time, the certificate installation package may be distributed in advance to all CSPs regardless of whether they currently have a contract relationship, taking into account the possibility that on-the-fly roaming will be formed later. The certificate installation package includes a contract certificate chain and eMAID account information, and may further include connection information for a certificate revocation list (CRL) and an OCSP server. The certificate package may be transmitted between CSPs directly or via a clearinghouse as described below.

[0132] More specifically, when the home CSP generates the contract certificate in step 704, a certificate installation response message (CertificateInstallationRes) or a certificate update response message (CertificateUpdateRes) including the corresponding certificate package is distributed to all visited CSPs that have a contractual relationship with the home CSP through a secure channel. At this time, each home CSP verifies the contract certificate chain, checks the revocation status of the contract certificate chain, checks the eMAID account status, and checks whether the contract is acceptable for the service. If the check result shows that there is no problem with the contract certificate chain, the eMAID account, and the contract contents, the home CSP may distribute the certificate package to all visited CSPs with which it has a direct roaming contract, or to a clearinghouse with which it has a certificate distribution contract, or may distribute the certificate package to both. For this distribution process, the home CSP may have a list of visited CSPs with which it has a direct roaming contract if there is one or more visited CSPs with which it has a direct roaming contract. Also, the home CSP may have a list of clearinghouses with which it has a roaming contract for certificate installation if there is one or more clearinghouses with which it has a roaming contract for certificate installation. Communications for the distribution of the certificate package may occur across the roaming endpoint. Meanwhile, upon receiving the certificate installation package, the visiting CSP distributes the package to its own CPS through the same procedures as when issuing certificates to its own users.

[0133] Thereafter, when the EV requests to install or update a certificate, the visiting CSO retrieves the certificate installation package from the visiting CPS and transmits it to the EV. The installation or update process at this time may be the same between a non-roaming situation and a roaming situation. Steps 720 to 734 in FIG. 13 show this process.

[0134] Specifically, in step 720, the EV transmits a certificate installation or update request message (Cert{Ins / Upd}Req) to the CS. In the case of the certificate installation request message, the EV transmits an OEM provisioning certificate chain to the charging station (CS) by communication conforming to the ISO 15118 standard. Meanwhile, the certificate renewal request message may include a contract certificate chain. Upon receiving the certificate installation or update request message (Cert{Ins / Upd}Req), the CS checks the message signature value in the request message (step 722). At this time, the CS checks the message signature value by decrypting the signature value included in the request message with the public key to restore the hash, and then comparing the restored hash with the hash included in the request message.

[0135] The CS then verifies the received certificate chain (step 724). In the case of an OEM provisioning certificate for certificate installation, the certificate is verified by comparing the owner information of each certificate in the provisioning certificate chain from the OEM root certificate (OEM RootCA cert.) to the leaf certificate (OEM Prov cert.) with the issuer information of its subordinate CA, thereby verifying the integrity and reliability of each certificate. In the case of a contract certificate for certificate update, the certificate is verified by comparing the owner information of each certificate in the contract certificate chain from the MO root certificate (MO RootCA cert.) to the leaf certificate (Contract cert.) with the issuer information of its subordinate CA, thereby verifying the integrity and reliability of each certificate. The CS then transmits a certificate installation or update request message (Cert{Ins / Upd}Req) to the visiting CSO (step 726).

[0136] The visiting CSO checks whether each certificate in the OEM provisioning certificate chain or the contract certificate chain has been revoked (step 728). The unrevoked status of the certificate, i.e., validity, may be checked through a certificate revocation list (CRL) received from the OEM root CA or a certificate revocation list received from the MO root CA, or may be checked after requesting the certificate status from an OCSP server associated with the OEM root CA or the MO root CA and receiving the query result.

[0137] Next, the visiting CPS verifies the new contract certificate chain stored in step 708 based on the MO root CA certificate (step 730). The visiting CPS also checks whether each certificate in the new contract certificate chain has been revoked (step 732). The unrevoked status of the certificate, i.e., validity, may be checked through a certificate revocation list (CRL) received from the MO root CA, or may be checked by requesting the certificate status from an OCSP server associated with the MO root CA and receiving the query result.

[0138] In general, when an EV conforming to the ISO 15118 standard attempts a TLS association with a CS, the CS needs to prove that all certificates in the CS's certificate chain are valid, i.e., not revoked. To this end, according to one embodiment of the present invention, the CS periodically requests the CSMS to obtain an OCSP response from an OCSP responder in the CSO PKI, and frequently enough to keep the OCSP response valid. The CS stores one OCSP response for one certificate chain.

[0139] For each certificate, the CS decides to update the OCSP response every time the existing OCSP response expires, and requests the CSMS to perform an OCSP retrieval. The OCSP retrieval request may include an OCSP request message, the distinguished name (DN) of the certificate issuer, and the certificate serial number. For each request, the CSMS searches the certificate database for the OCSP response URL by querying the issuer's DN and serial number. If the URL is not found, the CSMS tries to retrieve the URL in other ways. If there is no top URL, the CSMS displays an error in the response. If the OCSP response is retrieved successfully, the CSMS returns an OCSP response message list to the CS. If any of the retrievals fail, the CSMS displays the failed OCSP queries and the reason for it. The CS stores the received OCSP response and sends it to the EV during TLS concatenation through OCSP stapling. For each error, the CS decides whether to retry the retrieval or enter a maintain state depending on the error type.

[0140] In order to keep the information about the certificate status of the CS up to date, the CSMS maintains a certificate database for storing the certificates used by the charging stations and itself. The CS also maintains a set of valid OCSP responses for the certificate chain at all times. It is preferable that the CS requests OCSP responses from the CSMS frequently enough to keep them valid.

[0141] If the new contract certificate chain is verified in step 730, and there is no problem with the validity of each certificate in the new contract certificate chain in step 732, the visiting CPS sends a certificate installation / renewal response (i.e., a Cert{Ins / Upd}Res message) including the new contract certificate package to the CS (step 734). The CS again sends the new contract certificate package to the EV, allowing the EV to install or renew the new certificate (step 736).

[0142] Meanwhile, the contract certificate distributed to practically all CSPs in steps 704 to 708 may be deleted from each CSP to reduce the storage burden of personal information protection data after a certain period of time has passed since distribution or after installation of the contract certificate in the corresponding EV is completed. For this reason, after installation of the contract certificate in the corresponding EV is completed, it is preferable for the home CSP to notify all CSPs and clearinghouses to which the contract certificate has been distributed of the completion of installation of the contract certificate.

[0143] First, an EV owner and an operator of a home CSP conclude a charging service contract (step 700). After concluding the contract, the home CSP generates a contract certificate for the EV (step 702). The generated certificate includes the EV's public key, a hash of the public key, and a signature value obtained by encrypting the hash with the private key of an intermediate CA (MO Sub 1 or MO Sub 2) of the MO root CA. The generated certificate is distributed to all visited CSPs that have roaming contracts with the home CSP (steps 704 to 708).

[0144] In this way, the CS transmits data received from the visited CPS in step 734, for example, the contract certificate package, to the EV in step 736, but not all of the certificate data received by the CS is transmitted to the EV. That is, the CS may accept and install a certificate according to its own needs, or update an existing stored certificate. For example, the CS may obtain a root CA certificate and related metadata used to authenticate the EV and a charging station management system (CSMS), and a cross certificate used to authenticate itself to the EV, from the CSMS. In other words, the CS needs to store by itself some root CA certificates (issued for the root CA, but not necessarily self-signed) and related metadata for security operations. The certificate metadata may include a SHA1 hash (for TLS) and the issuer's DN / serial number (for certificate installation).

[0145] Examples of certificates that the CS receives and stores or updates as needed are as follows: The CS needs the root CA certificate of the CSMS's certificate chain (i.e., the CSMS root CA certificate) to authenticate the CSMS while setting up a security channel with the CSMS, which is generally considered to be the same as the V2G root CA of the CS. In addition, if the CS chooses to be approved for EV in accordance with the ISO 15118 standard using the PnC method and the role of the CS is to verify the contract certificate chain, the CS needs to have the root CA certificate of the EMSP. In addition, in the case of installing or updating a contract certificate, the CS may need the OEM root CA certificate or the EMSP root CA certificate if the role of the CS is to verify the installed OEM provisioning certificate chain or the updated contract certificate chain.

[0146] Furthermore, if the CSO supports cross-certification to allow services to EVs that trust only V2G root CAs other than the CSO's V2G root CA, the CS may need a cross-certificate issued by a V2G root CA trusted by the EV. On the other hand, to confirm whether the EV can trust the CSO's V2G root CA (for TLS) or the CPS's V2G root CA certificate, the CS needs to know the metadata of the available trust anchor. The trust anchor includes the CS's V2G root CA (including the new root CA for migration) and the cross-certified V2G root CA. On the other hand, the CS needs the root CA certificate of the CS component manufacturer that is used to verify the integrity of the firmware binary code. In addition, in the case of CS's V2G root CA migration, 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 period.

[0147] Here, there are OldWithNew certificates and NewWithOld certificates. The OldWithNew certificate refers to a cross-certificate signed by a new root CA for a previous root CA. A CS having a previous certificate chain needs this for an EV that trusts the new root CA. The NewWithOld certificate refers to a cross-certificate signed by a previous root CA for a new root CA. A CS having a new certificate chain needs this for an EV that trusts the previous root CA.

[0148] One embodiment of the process by which a CS receives, stores, or updates certificates according to its own needs is triggered by the CSMS. That is, when there is an update in the CSMS for either the CA certificate or metadata that must be installed in the CS, the CSMS sends an update list to one or more CSs, and each update data is in the format of "Update = (type, certificate, metadata)". For example, in the case of the V2G root CA of the CSO, each update data may be in the format of (V2G root CA, <V2G root CA certificate>). In the case of the EMSP root CA certificate, it may be in the format of (EMSP root CA, <EMSPRooCA certificate>, -). In the case of the OEM root CA certificate, it may be in the format of (OEM root CA, <OEMRooCA certificate>, -). In the case of a cross-certificate, it may be in the format of (CrossCert, <cross-certificate>, -). In the case of a cross-certificate V2G root CA certificate, it may be in the format of (Cross root CA, -, <metadata>). In the case of an OldWithNew cross-certificate for migration, it may be in the format of (OldWithNew, <OldWithNew certificate>, -), and in the case of a NewWithOld cross-certificate for migration, it may be in the format of (NewWithOld, <NewWithOld certificate>, -).

[0149] For such certificates, upon receiving an update from the CSMS, the CS will install the received certificate or metadata without undue delay and update the update timestamp.

[0150] Another embodiment of the process by which the CS receives and stores or updates the certificates as needed is triggered by the CSMS. That is, when the CS decides to update the changes in the CA certificate, for example periodically, the CS requests the update of the CA certificate by sending certain information to the CSMS. Examples of the information sent from the CS to the CSMS include the timestamp of the last successful update, and the DN / serial number list of the issuers of the CA certificates currently in the CS. Upon receiving the update request, the CSMS sends the updated / added CA certificate / metadata after the indicated timestamp. Upon receiving the response at the CSMS, the CS securely stores the CA certificate and metadata.

[0151] When the CSMS updates its CA certificate database, it must request the relevant CS to install the update or update package after the last update. Upon receiving the request, the CS installs the received CA certificate update and sets the timestamp with the update time. Per CSO policy, the CS periodically requests the CSMS to update the CA certificate by providing the timestamp of the last update. Also upon request, the CSMS sends updates of all CA certificates that have changed since the timestamp included in the request. When sending CA certificate updates, the CSMS sends a list of the certificate type, certificate, and metadata, of which only the metadata is sent to cross-certify the cross-certified V2G root CA certificate.

[0152] Meanwhile, the CS needs to hold multiple CA certificates and related information for secure operation. For example, if an EV conforming to the ISO 15118 standard chooses to be approved by the PnC method, the CS may need the root CA certificate of the EMSP to validate the contract certificate chain. Also, the CS may need the root CA certificate of the OEM or EMPS to install the contract certificate. When setting up a security channel with the CSMS, the CS needs the root CA certificate of the CSMS, which is generally the V2G root CA. In addition, for better interoperability between different V2G operators, the CS needs to hold cross certificates issued by other V2G operators. Also, the CS needs to hold metadata (e.g., hash, DN, and sequence number) of each trust anchor to determine whether the EV can securely connect to the CSO.

[0153] An embodiment of a process by which the CS updates multiple CA certificates and related information for secure operation may be triggered by the CS. If the CS decides to update the changes in the CA certificate inventory, the CS requests the CSMS to update all CA certificates. The request may include a timestamp of the last successful update request and a list of DNs / serial numbers of issuers of the CA certificates in the CS. Upon receiving the request, the CSMS checks the timestamps of the CA certificate updates and sends only the data of the certificates that have been updated after the timestamp in the request to the CS. The certificates sent to the CS in this manner may include the CSMS's V2G root CA certificate and metadata, the CS's V2G root CA metadata, the contracted EMSP's root CA certificate (if necessary), the OEM's root CA certificate (if necessary), cross-certificates and metadata issued to the CS's V2G root CA, the cross-certificate's V2G root CA metadata, and the root migration cross-certificate. Upon receiving a response from the CSMS, the CS securely stores the received CA certificates.

[0154] Another embodiment of the process by which the CS updates multiple CA certificates and related information for secure operation may be triggered by the CSMS. If there is an update to any of the CA certificates that must be installed in the CS in the CSMS, the CSMS requests the CA certificates to be updated by sending the types of certificates to be updated and a list of certificate data of a certain type to all or some of the CSs. The types of certificates to be updated include, for example, the V2G root CA (for root migration) of the CSMS, the V2G root CA (for root migration) of the CS, the root CA of the EMSP, the root CA of the OEM, the cross certificate issued to the V2G root CA of the CS, the V2G root CA of the cross certificate, and the root migration cross certificate. Upon receiving the request from the CSMS, the CS installs the received certificate data without undue delay and updates the update timestamp.

[0155] In the certificate update process as described above, the CSMS may maintain a database for update / time tagged CA certificate data (certificate, DN, serial number, hash). Also, the EV and CS communicate through ISO15118 with the PnC identification method. Meanwhile, the CPS / CCP validates the certificate chain (the OEM provisioning certificate chain for installation and the contract certificate chain for update) and checks whether each certificate in the OEM provisioning certificate chain for installation and the contract certificate chain for update has been revoked.

[0156] Meanwhile, when receiving a certificate for update, the CS checks the signature of the CertificateInstallationReq and CertificateUpdateReq messages. Then, the CS sends the following data to the CSMS: the CertificateInstallationReq or CertificateUpdateReq message (as is), the PCID (for installation) or eMAID (for update), the ISO 15118 schema version of the message, the retrieval deadline (according to the ISO 15118 time limit), and the V2G root CA certificate list trusted by EV. Upon receiving the above data, the CSMS requests the contract certificate from the auxiliary participant and conveys the received information back to the CS. When multiple contract certificates are received, the CSMS preferably indicates the completion of reception to the CS. If no contract certificate is received, the CSMS displays an error message (e.g., "NO_CONTRACT_CERTIFICATE_FOUND") to the CS. In accordance with the ISO 15118-2 standard, the CS passes the CertificateInstallationRes or CertificateUpdateRes SessionID received from the CSMS to the EV in a filled state, whereas in accordance with the ISO 15118-20 standard, the CS modifies each received CertificateInstallationRes or generates a CertificateInstallationRes message for each piece of information received by the CSMS so that the message contains the correct values ​​for the SessionID, EVSEProcessing, RemainingCerts, EVSEStatus and ResponseCode elements.

[0157] FIG. 14 is a diagram illustrating a transmission path of a contract certificate transmitted from a home CSP to an EV through indirect roaming and installed in the EV in an embodiment of the present invention.

[0158] In this embodiment, it is assumed that the contract certificate stored in the home CPS must be installed in the EV or the existing certificate in the EV must be updated to this certificate. Currently, the EV is in a state of visiting a CS connected to a visited CSO belonging to the visited CSP's network. However, if the home CSP and the visited CSP have an indirect roaming contract relationship via a clearinghouse, the EV can install the contract certificate stored in the home CPS or update the existing certificate to this certificate by indirect roaming via the clearinghouse.

[0159] Figure 15 is a flowchart showing in more detail the certificate transfer process shown in Figure 14. The embodiment shown in Figure 15 is different in that in the process of preemptively storing the certificate in the CSP, the visited CSP and the home CSP do not communicate directly with each other, but communicate through a clearinghouse.

[0160] First, an EV owner and an operator of a home CSP conclude a charging service contract (step 800). After concluding the contract, the home CSP generates a contract certificate for the EV (step 802). The generated certificate includes the EV's public key, a hash of the public key, and a signature value obtained by encrypting the hash with the private key of an intermediate CA (MO Sub 1 or MO Sub 2) of the MO root CA. The generated certificate may be distributed to all visited CSPs that have roaming contracts with the home CSP (steps 804 to 808).

[0161] In an exemplary embodiment, steps 800 to 808 may be performed preemptively before the EV transmits a certificate installation request message (CertificateInstallationReq) or a certificate update request message (CertificateUpdateReq) to the visited ESO through the CS. That is, when the EV requests the visited CSP to install or update a certificate, the home CSP distributes a certificate installation package to all visited CSPs in a contractual relationship in advance so that the visited CSPs can store the package in their own CPSs in order to support the EV. At this time, the certificate installation package may be distributed in advance to all CSPs regardless of whether they currently have a contractual relationship, taking into account the possibility that on-the-fly roaming will be formed later. The certificate installation package includes a contract certificate chain and eMAID account information, and may further include connection information for a certificate revocation list (CRL) and an OCSP server. The certificate package may be transmitted between CSPs directly or via a clearinghouse as described below.

[0162] More specifically, when the home CSP generates the contract certificate in step 804, a certificate installation response message (CertificateInstallationRes) or a certificate update response message (CertificateUpdateRes) including the corresponding certificate package is distributed to all visited CSPs that have a contractual relationship with the home CSP through a secure channel. At this time, the home CSP or the clearinghouse verifies the contract certificate chain, checks the revocation status of the contract certificate chain, checks the eMAID account status, and checks whether the contract is acceptable for the service. If the check result shows that there are no problems with the contract certificate chain, the eMAID account, and the contract contents, the certificate package is distributed to all visited CSPs. When the distribution is completed, the home CSP transmits a status code of the certificate chain and a result code for the account and privileges to the clearinghouse. For this distribution process, the home CSP has a list of visited CSPs with which it has a direct roaming agreement, if there is one or more such visited CSPs. In addition, the home CSP has a list of clearinghouses with which it has a roaming agreement for certificate installation, if there is one or more such clearinghouses. Communications for distribution of the certificate package may occur across the roaming endpoint. However, upon receiving the certificate installation package, the visiting CSP distributes the package to its CPS through the same procedures used to issue certificates to its users.

[0163] Thereafter, when the EV requests to install or update a certificate, the visiting CSO retrieves a certificate installation package from the visiting CPS and transmits it to the EV. The installation or update process may be the same between a non-roaming situation and a roaming situation. Steps 820 to 836 in FIG. 14 show this process.

[0164] Specifically, in step 820, the EV transmits a certificate installation or update request message (Cert{Ins / Upd}Req) to the CS. In the case of the certificate installation request message, the EV transmits an OEM provisioning certificate chain to the charging station (CS) by communication conforming to the ISO 15118 standard. Meanwhile, the certificate renewal request message may include a contract certificate chain. Upon receiving the certificate installation or update request message (Cert{Ins / Upd}Req), the CS checks the message signature value in the request message (step 822). At this time, the CS checks the message signature value by decrypting the signature value included in the request message with the public key to restore the hash, and then comparing the restored hash with the hash included in the request message.

[0165] The CS then verifies the received certificate chain (step 824). That is, in the case of certificate installation, the OEM provisioning certificate chain is verified in the manner described above, and in the case of certificate update, the contract certificate chain is verified. The CS then transmits a certificate installation or update request message (Cert{Ins / Upd}Req) to the visiting CSO (step 826). In addition, the visiting CSO checks whether each certificate in the OEM provisioning certificate chain or the contract certificate chain has been revoked in the manner described above (step 828).

[0166] The visiting CPS verifies the new contract certificate chain stored in step 808 based on the MO root CA certificate (step 830). The visiting CPS also checks whether each certificate in the new contract certificate chain has been revoked (step 832). The unrevoked status of the certificate, i.e., validity, may be checked through a certificate revocation list (CRL) received from the MO root CA, or may be checked by requesting the certificate status from an OCSP server linked to the MO root CA and receiving the query result.

[0167] As a result of the check, the new contract certificate chain is verified, and if there is no problem with the validity of each certificate in the new contract certificate chain, the visiting CPS sends a certificate installation / renewal response (i.e., a Cert{Ins / Upd}Res message) including the new contract certificate package to the CS (step 834). The CS again sends the new contract certificate package to the EV, and the new certificate is installed or renewed in the EV (step 836).

[0168] In this manner, the CS transmits data received from the visited CPS in step 834, for example, the contract certificate package, to the EV in step 836, but not all of the certificate data received by the CS is transmitted to the EV. That is, the CS may accept and install a certificate according to its own needs, or update an existing stored certificate. In addition, the CS may need to hold multiple CA certificates and related information for secure operation, and may update multiple CA certificates and related information. In this embodiment, the process in which the CS installs or updates the certificates it needs is similar to the description of FIG. 13, and therefore a detailed description thereof will be omitted.

[0169] It should be noted that in Figures 13 and 15, the roles of the Visited CSP and the Home CSP may be interchangeable. Furthermore, it should be considered that a CSP can act as a Visited CSP for other CSPs and as a Home CSP for other CSPs.

[0170] FIG. 16 is a flow chart illustrating a contractual service approval process in one embodiment of the present invention.

[0171] First, an EV that wishes to be authorized for a service through the PnC method transmits an authorization request message (AuthorizationReq) to the visiting CS (step 900). At this time, the EV transmits a contract certificate chain to the charging station (CS) through communication conforming to the ISO 15118 standard. The CS verifies the signature of the EV by decrypting the signature value included in the authorization request message (AuthorizationReq) with the EV's public key to restore the hash, and comparing the restored hash with the hash included in the authorization request message (step 902).

[0172] The CS then transmits the contract certificate chain and eMAID included in the authorization request message (AuthorizationReq) to the visiting CSO (step 904). The visiting CSO determines whether the CSP that has a contractual relationship with the EV is inside or outside the network to which the visiting CSO belongs. The visiting CSO also checks how to directly contact the home CSP or the clearinghouse to receive roaming support. The visiting CSO then transmits an authorization request including information about the EV to the home CSP or the clearinghouse (step 906). The information about the EV includes the eMAID and the contract certificate chain, and may further include a description of the service for the authorization of the EV. If the destination of the information about the EV transmitted by the visiting CSO in step 906 is a clearinghouse, the clearinghouse transmits the information about the EV to the home CSP.

[0173] Next, the home CSP checks the complete contract certificate chain including the MO RootCA cert. secured in advance, and verifies the contract certificate chain (step 708). The contract certificate chain is verified by comparing the owner information of each certificate in order from the root certificate (MO RootCA cert.) through the intermediate CA certificates (MO SubCA 1 cert, MO SubCA 2 cert) to the leaf certificate, the contract certificate, with the issuer information of the subordinate CA, thereby verifying the integrity and reliability of each certificate. The home CSP also checks whether each certificate in the contract certificate chain has been revoked (step 910). The unrevoked status of the certificate, i.e., validity, may be confirmed through the certificate revocation list (CRL) received from the MO RootCA, or by inquiring about the certificate status to an OCSP server linked to the MO RootCA. The home CSP also checks the status of the eMAID account and whether the requested service is acceptable under the contract (step 912).

[0174] Depending on the result of the check, the home CSP returns a status code indicating the status of the contract certificate chain and a result code related to the EV account and authority to the visiting CSO (step 914). The status code may be, for example, one of "OK", "Expired", "Revoked", "Invalid_chain", and "Unknown_error". The result code may be, for example, one of "OK", "NO_CONTRACT", "CONTRACT_TERMINATED", "CONTRACT_SUSPENDED", "NOT_AUTHORIZED", and "Unknown_error".

[0175] The visiting CSO notifies the CS of the authentication result, and the CS again notifies the EV of the authentication result through communication compliant with the ISO 15118 standard (Steps 916 and 918).

[0176] In this way, if a CSP that has a contractual relationship with EV has a direct roaming contract with the visiting CSO or an indirect roaming contract through a clearinghouse, the visiting CSO will carry out the authorization process by either exchanging information necessary for EV authentication directly with the home CSP or exchanging information via the clearinghouse.

[0177] Meanwhile, Fig. 16 illustrates an embodiment of the present invention, and this embodiment may be modified in various ways. For example, in a modified embodiment, the message signing step (step 902) is performed by the visited CSO instead of the CS. Also, the contract certificate chain verification step (step 908) is performed by the visited CSO or CS instead of the home CSP. In addition, the embodiment shown in Fig. 16 may change the execution entity of each step as shown in Figs. 7 to 11 depending on the roaming situation.

[0178] 17 is a block diagram of a charging service provider (CSP) (220) according to an embodiment of the present invention. The CSP (220) according to an embodiment of the present invention includes at least one processor (1020), a memory (1040), and a storage device (1060).

[0179] The processor 1020 executes program instructions stored in the memory 1040 and / or storage device 1060. The processor 1020 may be embodied by at least one central processing unit (CPU) and / or graphics processing unit (GPU), or other processor capable of performing methods according to the present invention.

[0180] The memory (1040) may include, for example, a volatile memory such as a read only memory (ROM) and a non-volatile memory such as a random access memory (RAM). The memory (1040) loads program instructions stored in the storage device (1060) and provides them to the processor (1020).

[0181] The storage device (1060) is a recording medium suitable for storing program instructions and data, and may include, for example, magnetic media such as a hard disk, a floppy disk, and a magnetic tape, optical media such as a compact disk read only memory (CD-ROM) and a digital video disk (DVD), magneto-optical media such as a floptical disk, a flash memory, an erasable programmable ROM (EPROM), or a semiconductor memory such as an SSD manufactured based on these.

[0182] The storage device (1060) stores program instructions. In particular, the program instructions include program instructions for supporting installation of a certificate according to the present invention. The program instructions for supporting installation of a certificate include an instruction to generate a first contract certificate for a first EV, transmit the first contract certificate to a first external CSP, and install the first contract certificate in the first EV via the first external CSP, an instruction to receive a second contract certificate for a second EV from the second external CSP, transmit the second contract certificate to the CPS and store it, and an instruction to transmit the second contract certificate stored in the CPS to the second EV and install it in the second EV when a contract certificate installation request is received from the second EV in a roaming situation in which the second EV has entered the service network. Furthermore, the program instructions for wireless power transmission include at least a part of instructions necessary to implement the process shown in FIG. 12. Such program instructions are loaded into the memory (1040) under the control of the processor (1020) and executed by the processor (1020) to implement the method according to the present invention.

[0183] As described above, the apparatus and method according to the embodiment of the present invention are embodied as a computer readable program or code in a computer readable recording medium. The computer readable recording medium includes any kind of recording device in which data readable by a computer system is stored. The computer readable recording medium may also be distributed among computer systems connected via a network, and the computer readable program or code may be stored and executed in a distributed manner.

[0184] The computer readable recording medium may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. The program instructions may include not only machine code, such as produced by a compiler, but also high-level language code that can be executed by the computer using an interpreter, for example.

[0185] Although some aspects of the invention have been described in the context of an apparatus, it may also be presented as a corresponding method description, where blocks or apparatus correspond to method steps or features of method steps. Similarly, aspects described in the context of a method may also be presented as corresponding blocks or items or features of corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be performed by such an apparatus.

[0186] In embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In embodiments, a field programmable gate array may operate in conjunction with a microprocessor to perform any of the methods described herein. In general, it is preferred that the methods be performed by some hardware apparatus.

[0187] Although the present invention has been described above with reference to preferred embodiments, those skilled in the art will understand that the present invention can be modified and changed in various ways without departing from the spirit and scope of the present invention. [Explanation of symbols]

[0188] 10 Electric Vehicles (EV) 11 Receiving Pad 12 Battery 20 Charging Station 21 Send Pad 30 Charging cable 31 Charging connector 32 In-cable control box 33 Power outlet socket connection 40 Power Socket 50 (Commercial) power grid 1020 Processor 1040 Memory 1060 Storage Unit

Claims

1. A charging service provider (CSP) provides first contract certificate-related information for a first electric vehicle (EV) having a contractual relationship with the CSP; The CSP transmits the first contract certificate-related information to a first external CSP connected to a first visiting charging station operator (CSO) having a roaming contract formed directly or indirectly with the CSP, so that the first contract certificate-related information is transmitted to the first visiting CSO; The first visiting CSO receives a charging approval request including first visiting contract certificate related information from the first EV when the first EV enters a service network; The first visit CSO verifies the first visit contract proof related information; A method for identifying an electric vehicle contract, comprising:

2. The method for identifying an electric vehicle contract as described in claim 1, further comprising a step of the first visit CSO recognizing the CSP that has a contractual relationship with the first EV based on the first visit contract proof related information.

3. 2. The method of claim 1, wherein the first external CSP includes all external CSPs that do not have a contractual relationship with the first EV and have a roaming contractual relationship with the CSP.

4. 2. The method of claim 1, further comprising the step of the first visiting CSO transmitting the first contract certificate included in the first contract certificate related information to the first EV so that the first contract certificate is installed or updated in the first EV when the first EV enters the service network.

5. transmitting the first contract proof related information to the first external CSP, forming a certificate installation package including a contract certificate chain including the first contract certificate included in the first contract certificate-related information and eMAID information; transmitting the certificate installation package to the first external CSP; The method for identifying an electric vehicle contract according to claim 1, further comprising:

6. 6. The method of claim 5, wherein the certificate installation package includes a certificate revocation list associated with the first contract certificate and connection information for an Online Certificate Status Protocol (OCSP) server.

7. A processor; a memory for storing at least one instruction to be executed by the processor; The processor, in accordance with the at least one instruction, providing first contract certificate-related information for a first electric vehicle (EV) having a contractual relationship with the first external charging service provider (CSP) and transmitting the first contract certificate-related information to a first external CSP with which a roaming contract has been formed so that the first contract certificate-related information can be transmitted to a first visiting charging station operator (CSO) on a network into which the first EV has entered; A charging service provider (CSP) device that receives second contract proof related information for a second EV that does not have a contractual relationship with the charging service provider (CSP) device from a second external CSP.

8. The first external CSP includes all external CSPs with which the first external CSP has a roaming agreement; The charging service provider (CSP) device according to claim 7, wherein the second external CSP is any one of all the external CSPs with which the second external CSP has a roaming agreement.

9. The first external CSP has no contractual relationship with the first EV, The charging service provider (CSP) device of claim 7 , wherein the second external CSP has a contractual relationship with the second EV.

10. When transmitting the first contract proof related information to the first external CSP, The charging service provider (CSP) device of claim 7, further comprising: a charging service provider (CSP) device configured to transmit an installation standby release request to the first external CSP when a predetermined period of time has elapsed since the first contract proof-related information was transmitted to the first external CSP or when the first contract proof-related information is installed in the first EV.

11. transmitting the second contract certificate-related information to a certificate provisioning service (CPS) so that the second contract certificate-related information is stored in the CPS; The charging service provider (CSP) device of claim 7, characterized in that after the second contract proof related information is installed in the second EV by the CPS or the charging station (CS), the charging service provider (CSP) device notifies the second external CSP of completion of installation.

12. When transmitting the first contract proof related information to the first external CSP, forming a certificate installation package including an agreement certificate chain including the first agreement certificate and eMAID information; The charging service provider (CSP) device of claim 7, further comprising: transmitting the certificate installation package to the first external CSP.

13. 13. The charging service provider (CSP) device of claim 12, wherein the certificate installation package includes a certificate revocation list associated with the first contract certificate and connection information for an Online Certificate Status Protocol (OCSP) server.

Images