Charge control device, charge control method, and program

Abstract

To provide a charge control device capable of properly managing multiple pieces of certificate information in charging a vehicle.SOLUTION: The charge control device includes a controller that controls vehicle charge by performing authentication with charging equipment using a certificate. The controller stores multiple certificates each identified by its certificate identification information in a memory, and is configured to execute the steps of: when performing a charge, reading a certificate of a vehicle user from the memory based on a piece of priority information specifying the certificate that is used preferentially among multiple certificates; and when there is no valid certificate for the user based on priority information, acquiring a new certificate of the user; and when the newly acquired certificate is not stored in memory, storing the new certificate in the memory.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] The present invention relates to a charge control device, a charge control method, and a program. [Background technology]

[0002] There is a technology in which certificate information regarding charging is installed in a vehicle such as an electric vehicle, and when charging, the vehicle communicates with a charging station (also called charging equipment) and payment processing is performed (see Patent Document 1 below). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2016-93078 A Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the case where multiple pieces of certificate information are handled in a device equipped in a vehicle, the above-mentioned conventional technology does not have a mechanism for identifying which pieces of certificate information should be updated or added when the certificate information is installed. For this reason, for example, there is a risk of confusion occurring in the handling of multiple pieces of certificate information. An aspect of the disclosed embodiment is to enable appropriate management of multiple pieces of certificate information when charging a vehicle. [Means for solving the problem]

[0005] The disclosed embodiment is exemplified by a charging control device. The charging control device includes a controller that performs authentication processing with a charging facility using a certificate and controls charging of a vehicle. The controller executes the following operations: storing a plurality of certificates, each identified by certificate identification information, in a memory; reading a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when charging; acquiring a new certificate for the user when a valid certificate for the user based on the priority information does not exist; and storing the acquired new certificate in the memory when the new certificate is not stored in the memory. Effect of the Invention

[0006] The present charging control device can appropriately manage multiple pieces of certificate information when charging a vehicle. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram illustrating the configuration of a charging system according to the present embodiment. [Diagram 2] FIG. 2 is a diagram illustrating the relationship between user identification information (UID) and each certificate. [Diagram 3] FIG. 3 is a diagram illustrating the first problem in the comparative example. [Figure 4] FIG. 4 is a diagram illustrating the second problem in the comparative example. [Diagram 5] FIG. 5 is a diagram illustrating the third problem in the comparative example. [Figure 6] FIG. 6 is a diagram illustrating the fourth problem in the comparative example. [Figure 7] FIG. 7 is a diagram illustrating an example of a hardware configuration of the charging system. [Figure 8] FIG. 8 is a diagram illustrating components that perform the processing of a charge control device mounted on an electric vehicle. [Figure 9] FIG. 9 is a diagram illustrating a method in which the charging control device handles multiple Contract certificates. [Figure 10] FIG. 10 is a diagram illustrating EMAID priorities stored in the non-volatile memory. [Figure 11] FIG. 11 is a sequence diagram illustrating a procedure for managing a Contract certificate in one embodiment. [Figure 12] FIG. 12 is a sequence diagram illustrating a procedure for managing a Contract certificate in one embodiment. [Figure 13] FIG. 13 is a sequence diagram illustrating a procedure for managing a Contract certificate in one embodiment. [Figure 14] FIG. 14 is a sequence diagram illustrating a procedure for managing a Contract certificate according to the second modification. [Figure 15] FIG. 15 is a sequence diagram illustrating a procedure for managing a Contract certificate according to the third modification. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] A charge control device, a charge control method, and a program according to an embodiment will be described below with reference to the drawings.

[0009] <Embodiment> (Configuration) 1 is a diagram illustrating an example of the configuration of a charging system according to the present embodiment. The charging system includes an electric vehicle 1 as an example of a vehicle, and charging equipment (Electric Vehicle Supply Equipment, EVSE) 2 that supplies power to a battery (also called a secondary battery or a storage battery) of the electric vehicle 1. FIG. 1 also shows the certificate authorities CA1 and CA2, intermediate certificate authorities (SUB-CA11, SUB-CA12, SUB-CA21, and SUB-CA22), and servers 5 and 6. The certificate authority CA1 issues certificates such as a Contract certificate for user authentication. The certificate authority CA2 issues certificates such as a Vehicle to Grid (V2G) ROOT certificate. The server 5 is, for example, The computers in the center managed by the Mobility Operator (MO) (also called e-mobility service provider (eMSP) or e-mobility provider (EMP)) The server 6 is a computer at a center managed by the manufacturer (OEM (Original Equipment Manufacturer)) or distributor of the electric vehicle 1. , 6, etc. issue certificates such as a Contract certificate to the user, or install them in the electric vehicle 1.

[0010] As a premise for processing by this charging system, a V2G ROOT certificate issued by at least one certification authority CA2 is stored in a storage device of the electric vehicle 1 (for example, the external storage unit 13 in FIG. 7 ) in advance, such as when the electric vehicle 1 is shipped from the OEM. Furthermore, the electric vehicle 1 can update the V2G ROOT certificate by accessing the server 6, etc. Furthermore, the electric vehicle 1 can obtain a V2G ROOT certificate issued by a certification authority other than the certification authority CA2 by accessing the server 6, etc. The number of certification authorities is not limited to one.

[0011] On the other hand, the certificate chain includes, for example, Charge Point Operator SUB-Certificate Authorities 11 (CPO SUB-CA11), CPO SUB-CA12, EVSV Leaf certificates, etc.

[0012] In the first authentication procedure, called plug and charge (PnC), when the charging plug 2B of the charging facility 2 is inserted into the connection part (also called the power receiving part) of the electric vehicle 1, authentication is performed between the charging facility 2 and the electric vehicle 1. After the authentication, the electric vehicle 1 is charged and billed for the charging. For PnC, the electric vehicle 1 and the charging facility 2 are each connected to a V2G The ROOT certificate is stored in a storage device. The charging facility 2 may refer to the V2G ROOT certificate stored on a computer accessible from the charging facility 2. PnC can also be called a first billing method.

[0013] In PnC, after the charging equipment 2 and the electric vehicle 1 are connected by the charging plug 2B, The ROOT certificate is notified to the charging facility 2 (arrow P1). Next, a hierarchical certificate chain of the operator associated with the V2G ROOT certificate is responded to the electric vehicle 1 (arrow P2). The communication procedure represented by arrows P1 and P2 is called a Transport Layer Security (TLS) handshake. The V2G ROOT certificate can be said to be the first certificate for ensuring the security of communication between the electric vehicle 1 and the charging facility 2.

[0014] A certificate chain corresponds to the hierarchy of certification authorities. As shown in Figure 1, each certification authority, CA1, CA2, etc., can have intermediate certification authorities (SUB-CA11, SUB-CA12, SUB-CA21, SUB-CA22, etc.) that are lower-level certification authorities. The top-level certification authority, CA2, is called the ROOT certification authority and issues the V2G ROOT certificate. Furthermore, the certification authority certificates of the lower-level intermediate certification authorities (CPO SUB-CA11 certificate, etc.) are signed by the higher-level certification authorities. In the example certificate chain in Figure 1, the CPO SUB-CA11 certificate, CPO SUB-CA12 certificate, and EVSV Leaf certificate are shown as examples.

[0015] The electric vehicle 1 authenticates the certificate chain from top to bottom based on the user's V2G ROOT certificate, and can ultimately authenticate the EVSV Leaf certificate. If the electric vehicle 1 successfully authenticates the EVSV Leaf certificate, it can obtain a private key to be used for communication with the charging equipment 2, and thereafter, communication is encrypted using the private key. This completes the TLS handshake.

[0016] After the TLS handshake is completed, V2G communication is executed, encrypted using the private key. In V2G communication, a request (P3) from the electric vehicle 1 and a response (P4) from the charging equipment 2 are transmitted to each other, and charging and billing are carried out. In this V2G communication, a contract for charging supply, for example, a contract certificate that defines details of billing, is referenced between the charging equipment 2 and the electric vehicle 1. For example, the contract certificate (and its private key) is installed in the electric vehicle 1 in advance. PnC is established when the electric vehicle 1 sends the contract certificate to the charging equipment 2 during a charging session, and the charging equipment 2 uses this for authentication.

[0017] The electric vehicle 1 can request that the Contract certificate be installed in advance on the server 6 of the OEM, which is the manufacturer or seller of the electric vehicle 1, or on the server 5 of the MO, which is the mobility service provider that supplies the electricity. However, when the electric vehicle 1 is to be charged, it can also request that the charging equipment 2 install the Contract certificate. In this case, the electric vehicle 1 presents to the charging equipment 2 a certificate issued by the manufacturer or seller of the electric vehicle 1 (OEM provisioning certificate). If the charging equipment 2 has a valid Contract certificate associated with the OEM provisioning certificate notified by the electric vehicle 1 or can obtain it from the server 5, it can provide the Contract certificate to the electric vehicle 1.

[0018] 2 is a diagram illustrating an example of the relationship between user identification information (UID) and each certificate. In this embodiment, when charging is performed through a PnC session, the electric vehicle 1, for example, stores the Contract certificate and private key illustrated in FIG. 2, and the user identification information (UID A, UID For example, for a user whose user identification information (UID) is UID A, the electric vehicle 1 stores the Contract certificate identification information (EMAID) A and the private key in association with UIDA. The electric vehicle 1 also stores the OEMProvisioning certificate identification information (PCID) and private key that are unique to the vehicle regardless of the user identification information (UID). As already mentioned, when the charging control device 10 does not have a Contract certificate, it is possible to obtain the Contract certificate by presenting the OEMProvisioning certificate to the center server 5 or the like via the charging equipment 2. The above points are also the same for a user whose user identification information (UID) is UID B. .

[0019] FIG. 2 also illustrates the hierarchy of each certificate. That is, based on the V2G ROOT certificate issued by at least one certification authority CA2, the intermediate certification authorities issue the certificates in the order of MO_SUB1, MO_SUB2, and Contract certificates, which are lower-level certification authorities. The MO and OEM can each have an MO ROOT certificate and an OEM ROOT certificate issued by them instead of the V2G ROOT certificate. As described above, the Contract certificate is issued, for example, by a mobility service provider (MO).

[0020] The Contract Certificate is also known as the E-Mobility Account Identifier (EMAID). The contract certificate is linked to the user's billing account via a unique identifier. The owner of the electric vehicle 1 enters into a contract in advance with a service provider (MO) to create a billing account. The MO provides the electric vehicle 1 with a Contract Certificate through a series of procedures. Charging starts after the electric vehicle 1 presents the Contract Certificate to the charging equipment 2 and the Contract Certificate presented to the charging equipment 2 is further approved by the MO that issued the Contract Certificate. Then, the electric vehicle 1 can start charging the battery 19 (see Figure 7) according to the charging schedule negotiated with the charging equipment 2.

[0021] Similarly, based on the V2G ROOT certificate (or OEM ROOT certificate), the intermediate certificate authority issues the following certificates in the order of OEM_SUB1, OEM_SUB2, and OEMProvisioning certificates, which are lower-level certificate authorities. In Fig. 2, the OEMProvisioning certificate is omitted, and an OEMProv certificate is exemplified. The OEMProvisioning certificate is issued, for example, by a server 6 of the manufacturer (OEM) or seller of the electric vehicle 1.

[0022] (Comparative Example) As described above, the processing of the electric vehicle 501 according to the comparative example is illustrated with reference to Fig. 3 to Fig. 6. Note that in Fig. 3 to Fig. 6, the character string "EV" is attached to the electric vehicle 501. In addition to the electric vehicle 501, Fig. 3 to Fig. 6 also show charging equipment 502 that supplies power for charging the electric vehicle 501, a server 5 of the MO, which is a third party that provides a charging service, and a server 6 of the OEM.

[0023] ISO15118-2 defines PnC, which performs user authentication in communication for charging. As described above, in PnC, it is assumed that a Contract certificate (and its private key) is installed in the electric vehicle 501 before PnC is executed, and that the electric vehicle 501 exchanges the Contract certificate with the charging equipment 502 during the charging session. However, ISO15118-2 assumes that only one Contract certificate is held, and does not necessarily support all use cases. For example, the following problem occurs when one electric vehicle 501 handles multiple Contract certificates.

[0024] FIG. 3 is a diagram illustrating the first problem in the comparative example. In the example of FIG. 3, for example, user A is issued a contract certificate (CONTRACT A) based on a contract with the MO. In FIG. 3, for example, the contract certificate (CONTRACT A) is installed in a slot SL1 of a non-volatile memory of the electric vehicle 501 from the server 5 of the MO via the server 6 of the OEM (S501). Here, the slot SL1 or the like of the non-volatile memory is a storage destination of the contract certificate (CONTRACT A). Similarly, for example, user B is issued a contract certificate (CONTRACT B) based on a contract with the MO. When user B uses the same electric vehicle 501 as user A, user B desires to install the contract certificate (CONTRACT B) in the non-volatile memory of the electric vehicle 501.

[0025] However, in the example of FIG. 3, user A has already installed a duplicate Contract certificate (CONTRACT A) in slot SL1 in slot SL2 of the non-volatile memory. In the example of FIG. 3, it is assumed that user A has installed a second Contract certificate (CONTRACT A) in slot SL2 from charging equipment 502, not from OEM server 6 (S502). Also, in the example of FIG. 3, it is assumed that only two slots, SL1 and SL2, are prepared in the non-volatile memory of electric vehicle 501 for storing Contract certificates. Then, a case may arise where user B cannot install the Contract certificate (CONTRACT B) issued to himself in electric vehicle 501 (S503).

[0026] FIG. 4 is a diagram illustrating the second problem in the comparative example. In the example of FIG. 4 as well, user A is issued a contract certificate (CONTRACT A) based on a contract with the MO. The contract certificate (CONTRACT A) is installed in slot SL1 of the non-volatile memory of electric vehicle 501 via charging equipment 502 (S511). FIG. 4 illustrates a case where the contract certificate (CONTRACT A) installed in slot SL1 subsequently expires. When the contract certificate (CONTRACT A) expires, user A can be issued a new updated contract certificate (CONTRACT A Update) again by the MO.

[0027] However, in the example of Figure 4, the new Contract certificate (CONTRACT A Update) is 02 in slot SL2 of the non-volatile memory of electric vehicle 501 (S512). Then, the expired Contract certificate (CONTRACT A) remains in slot SL1. As a result, slot SL1 of the non-volatile memory becomes occupied by the unnecessary Contract certificate (CONTRACT A). In such a case, as in the case of FIG. 3, it may happen that the next Contract certificate (CONTRACT B) cannot be installed in electric vehicle 501.

[0028] FIG. 5 is a diagram illustrating the third problem in the comparative example. In the example of FIG. 5 as well, user A is issued a contract certificate (CONTRACT A) based on a contract with the MO. The contract certificate (CONTRACT A) is installed in slot SL1 of the non-volatile memory of electric vehicle 501 via charging facility 502 (S521). In the example of FIG. 5 as well as the example of FIG. 3, for example, user B is issued a contract certificate (CONTRACT B) based on a contract with the MO. Also, assume that user B wishes to install the contract certificate (CONTRACT B) in the non-volatile memory of electric vehicle 501.

[0029] However, in the example of FIG. 5, the Contract certificate (CONTRACT B) of user B is installed in slot SL1 of the non-volatile memory of electric vehicle 501 via charging facility 502 (S522). Then, in the example of FIG. 5, the Contract certificate (CONTRACT A) already installed in slot SL1 is overwritten with the Contract certificate (CONTRACT B) issued to user B. Therefore, when user A subsequently attempts to charge electric vehicle 501, the Contract certificate (CONTRACT A) has not been installed in electric vehicle 501, and it may occur that the electric vehicle cannot be charged at charging facility 502.

[0030] FIG. 6 is a diagram illustrating the fourth problem in the comparative example. In the example of FIG. 6 as well, user A is issued a contract certificate (CONTRACT A) based on a contract with the MO. The contract certificate (CONTRACT A) is installed in slot SL1 of the non-volatile memory of electric vehicle 501 via charging facility 502 (S531). In the example of FIG. 6 as well, as in the example of FIG. 3, it is assumed that user B is issued a contract certificate (CONTRACT B) based on a contract with the MO. It is also assumed that user B wishes to install the contract certificate (CONTRACT B) in the non-volatile memory of electric vehicle 1.

[0031] In the example of FIG. 6, the contract certificate (CONTRACT A) of user A has already been registered in the non-volatile The Contract certificate (CONTRACT B) is installed in slot SL1 of the non-volatile memory. That is, when user B installs the Contract certificate (CONTRACT B) in the non-volatile memory of the electric vehicle 1, an existing Contract certificate (CONTRACT A) exists. In this case, it is assumed that the system that manages the Contract certificates in the electric vehicle 1 does not start or interrupts the installation process of the Contract certificate (CONTRACT B) of user B. In such a case, a user other than user A who initially received the installation of the Contract certificate (CONTRACT A) in the electric vehicle 501 may not be able to install the Contract certificate in the electric vehicle 501. The above problem is caused by the fact that ISO15118-2 assumes that each vehicle has only one Contract certificate. Therefore, an embodiment of the electric vehicle 1 for solving the problems shown in Figs. 3 to 6 is exemplified below.

[0032] (Configuration of the embodiment) 7 is a diagram illustrating an example of the hardware configuration of the present charging system. As described above, the present charging system is exemplified by the electric vehicle 1, the charging facility 2 that charges the battery 19 mounted on the electric vehicle 1, and the servers 5 and 6. The electric vehicle 1 has a charging control device 10 and a battery 19 controlled by the charging control device 10.

[0033] The charge control device 10 has a CPU 11, a main memory unit 12, and an external device connected to an external interface (I / F), and executes information processing by a program. Examples of the external device include an external memory unit 13, an external communication unit 16A, and a communication unit 16B. The CPU 11 and the main memory unit 12 can be collectively referred to as a control unit or a controller. When the charge control device 10 is mounted on a vehicle such as an electric vehicle 1, the control unit is an electronic control unit (ECU ) is also called.

[0034] The CPU 11 executes a computer program that is executable and deployed in the main storage unit 12, and provides the functions of the charging control device 10. The main storage unit 12 is also called simply a memory, and stores the computer program executed by the CPU 11, data processed by the CPU 11, etc. The CPU 11 is also called a processor.

[0035] The main memory unit 12 is a Dynamic Random Access Memory (DRAM), a Static Random Access The external storage unit 13 may be a static random access memory (SRAM), a read only memory (ROM), etc. is used, for example, as a storage area that supplements the main storage unit 12, and stores computer programs executed by the CPU 11, data processed by the CPU 11, etc. The external storage unit 13 is a hard disk drive, a solid state drive (SSD), etc.

[0036] The external communication unit 16A transmits and receives data to and from other devices on the public network. For example, the CPU 11 communicates with a computer of a business operator on the public network through the external communication unit 16A. The external communication unit 16A may be a wireless communication device that accesses a mobile phone network. The external communication unit 16A may also be a communication device that accesses a wireless LAN (Local Area Network). The external communication unit 16A may be, for example, a device called a TCU (Telematics Control Unit). The external communication unit 16A may include an internal CPU, a memory, an input / output interface, a communication interface, and the like.

[0037] The communication unit 16B transmits and receives signals to and from the communication unit 26B. Here, the communication unit 16B may execute Power Line Communications (PLC) with the charging facility 2. The communication unit 16B is not limited to a unit that communicates via a power line that receives power from the power circuit 29 of the charging facility 2. In other words, the communication unit 16B may execute a PLC-like communication procedure with the charging facility 2 via a communication line other than a power line. A wireless LAN (Local Area Network) or Ethernet may also be used. The communication unit 16B may have a CPU, memory, an input / output interface, a communication interface, etc. inside. In this manner, in this embodiment, In this embodiment, the charge control device 10 communicates with the charging facility 2 via the external communication unit 16A or the communication unit 16B, and executes a charging request and billing process.

[0038] The charging control device 10 may further include a display unit and an operation unit. The display unit is, for example, a liquid crystal display, an electroluminescence panel, etc. The operation unit is, for example, a keyboard, a pointing device, an operation button, etc. The pointing device includes a touch panel such as a touch sensor provided on the screen of the display unit. The operation unit may also send and receive information to and from the charging control device 10 via a user's mobile terminal or smartphone.

[0039] The configuration of the charging equipment 2 is similar to that of the charging control device 10 of the electric vehicle 1. The charging equipment 2 has a CPU 21, a main memory unit 22, and external devices connected to an external interface (I / F), and executes information processing by a program. Examples of the external devices include an external memory unit 23, an external communication unit 26A, and a communication unit 26B. These configurations of the charging equipment 2 are similar to those of the charging control device 10 of the electric vehicle 1, so a description thereof will be omitted.

[0040] When plug 2B (see FIG. 1) of power supply circuit 29 is connected to a power circuit that charges battery 19, the charging control device 10 of electric vehicle 1 and the charging equipment 2 communicate with each other, for example, via communication units 16B, 26B, and perform TLS authentication and V2G communication. The charging control device 10 of electric vehicle 1 and the charging equipment 2 authenticate each other through TLS authentication and V2G communication, and perform charging of battery 19 of electric vehicle 1 and billing for the charging. However, when plug 2B of power supply circuit 29 is connected to a power circuit that charges battery 19, the charging control device 10 of electric vehicle 1 and the charging equipment 2 may also communicate with each other via external communication units 16A, 26A.

[0041] The servers 5 and 6 are ordinary computers, and have the same configuration as the CPU 11, the main memory unit 12, the external memory unit 13, and the external communication unit 16A. The servers 5 and 6 communicate with the charge control device 10 mounted on the electric vehicle 1 via a network N1. The network N1 is, for example, a public network including a wireless communication network such as a mobile network. The network N1 may be connected to the Internet. The network N1 may also be a Virtual Private Network (VPN). It may also include a private network available to specific parties, such as a VPN (Network). The servers 5 and 6 store user identification information (UID) as well as billing information that enables billing for users.

[0042] FIG. 8 is a diagram illustrating components that perform processing of the charging control device 10 (see FIG. 7) mounted on the electric vehicle 1 when the electric vehicle 1 is used by multiple users, as an example. As described above, the charging control device 10 is, for example, an in-vehicle computer, and executes control of charging from the charging facility 2, management of Contract certificates required for charging, and the like. FIG. 8 also illustrates an OEM server 6 that installs Contract certificates and a charging facility 2 that supplies power to the electric vehicle 1. The charging control device 10 realizes processing of each component in FIG. 8 by a computer program that is executablely deployed in a main storage unit 12 (see FIG. 7). The charging control device 10 has, as its components, a user identification unit 101, a certificate selection unit 102, a communication unit 103, a key management unit 104, and a certificate storage unit 105. In this embodiment, the charging control device 10 holds multiple Contract certificates in the electric vehicle 1 by these components in the following manner. The charging control device 10 in FIG. 8 realizes charging of the electric vehicle 1 in the case where, as an example, a single electric vehicle 1 is used jointly or shared among a plurality of users.

[0043] The user identification unit 101 is an example of an acquisition device, and identifies a user who is using the electric vehicle 1. The user identification unit 101 is, for example, a fingerprint authentication device mounted on the electric vehicle 1, a face authentication device including a camera, or an information input device exemplified by an in-vehicle device or a navigation device. Here, the information input device inputs identification information such as a character string for identifying a user, a password or is a device for inputting both of them. That is, the user identification unit 101 identifies the current user (driver, etc.) when the electric vehicle 1 is charged, and passes user identification information (UID) for identifying the user to the certificate selection unit 102. Here, the user identification information (UID) is, for example, a hash value obtained from an image of a fingerprint acquired from the user, a hash value obtained from an image of the user's face, or a character string identification information and a password itself. However, the user identification information (UID) may also be a hash value obtained from a character string identification information and a password.

[0044] The certificate selection unit 102 searches the certificate storage unit 105 for a corresponding Contract certificate by the user identification information (UID) delivered from the user identification unit 101, and selects the corresponding Contract certificate. The certificate storage unit 105 is, for example, a memory having a protection function called a secure memory. The secure memory operates in cooperation with, for example, a specific microcontroller or microcomputer (hereinafter, microcomputer). In this embodiment, the user identification unit 101 accesses the certificate storage unit 105 as a microcomputer. The secure memory detects, for example, access to a specific address by this microcomputer other than the processing of a specific program as an unauthorized access. When the secure memory detects unauthorized access, it resets the microcomputer and inhibits the access.

[0045] The certificate storage unit 105 stores user identification information (UID) and Contract certificate identification information (e-Mobility Authentication Identifier (EMAID)) in association with each other. The certificate storage unit 105 also stores Contract certificates corresponding to EMAIDs. Furthermore, in this embodiment, when there are multiple types of Contract certificates corresponding to the user identification information (UID), the certificate storage unit 105 stores the priorities (referred to as EMAID priorities) of the multiple types of Contract certificates. Therefore, by inputting the user identification information (UID) to the certificate storage unit 105, the certificate selection unit 102 determines the EMAID with the highest priority in the EMAID priority order, and acquires the Contract certificate corresponding to the EMAID with the highest priority. At this time, the certificate selection unit 102 sends a private key identifier that is consistent with the Contract certificate to the key management unit 104. Through the above procedure, the certificate selection unit 102 acquires the Contract certificate having the highest priority among the multiple Contract certificates corresponding to the user identification information (UID) from the certificate storage unit 105, and stores it in the temporary buffer 12C (see FIG. 9). Then, the certificate selection unit 102 passes the acquired Contract certificate to the communication unit 103. The Contract certificate corresponding to the user identification information (UID) is an example of certificate information corresponding to the identified user. The certificate storage unit 105 may be constructed in a memory, for example, the main storage unit 12 or the external storage unit 13 in FIG. 5.

[0046] The communication unit 103 communicates with the charging facility 2 by wireless communication or wired communication. The communication unit 103 may communicate with the charging facility 2 by an external communication unit 16A. The communication unit 103 may also communicate with the charging facility 2 by a communication unit 16B. The communication unit 103 transmits the Contract certificate delivered from the certificate selection unit 102 to the charging facility 2 in response to an authentication request 1. Communication The unit 103 receives an authentication response 1 from the charging facility 2 as a response to the authentication request 1.

[0047] The key management unit 104 manages the keys used in PnC and executes various certification processes. As described above, the key management unit 104 has a private key that matches the Contract certificate acquired based on the user identification information (UID). The key management unit 104 signs the data received in the authentication response 1 with the private key that matches the Contract certificate. The data signed with the private key is transmitted to the charging facility 2 via the communication unit 103. The charging facility 2 authenticates the user by the data signed with the private key that matches the Contract certificate. Through the above procedure, authentication is performed using the Contract certificate and private key acquired based on the user identification information (UID), and charging is performed by PnC.

[0048] If the certificate selection unit 102 cannot find a Contract certificate corresponding to an EMAID having the highest priority in the EMAID priority order in the certificate storage unit 105, the certificate selection unit 102 attempts to install the Contract certificate by inquiring of the server 5. Then, when the certificate selection unit 102 completes the installation of the Contract certificate, the certificate selection unit 102 associates the user identification information (UID) with the identification information (EMAID) of the Contract certificate, sets the EMAID priority order as the highest priority, and stores the association in the certificate storage unit 105. Therefore, thereafter, the certificate selection unit 102 can specify the identification information (EMAID) of the Contract certificate having the highest priority based on the user identification information (UID) and the EMAID priority order. As a result, the certificate selection unit 102 can acquire the Contract certificate having the highest priority based on the EMAID priority order and the private key (and data signed with the private key) corresponding to the user identification information (UID) from the certificate storage unit 105.

[0049] Furthermore, the certificate selection unit 102 delivers the OEMProvisioning certificate to the charging facility 2 (or the MO server 5) in order to install the Contract certificate from the charging facility 2. Then, the certificate selection unit 102 receives an OEMProvisioning certificate unique to each vehicle and stores it in the certificate storage unit 105.

[0050] As described above, Fig. 8 illustrates components that perform processing of the charging control device 10 mounted on the electric vehicle 1 when the electric vehicle 1 is used by multiple users. However, the user identification unit 101, the certificate selection unit 102, and the certificate storage unit 105 in Fig. 8 may be provided in a device other than the charging control device 10. For example, the user identification unit 101, the certificate selection unit 102, and the certificate storage unit 105 may be provided in the OEM's server 6 illustrated in Figs. 3 to 6. When a user starts a charging process for the electric vehicle 1, the charging control device 10 may access the OEM's server 6, and the server 6 may perform user authentication and identification of an EMAID priority corresponding to the user identification information (UID) in the same procedure as in Fig. 8.

[0051] Also, the server 5 may have equivalent EMAID priority information, and the EMAID priority of the server 5 may be linked to the EMAID priority of the charge control device 10 directly or via the server 5 .

[0052] Furthermore, when the electric vehicle 1 is not used by multiple users, that is, when the electric vehicle 1 is used by a single user, the user identification unit 101 may be omitted. Even when the electric vehicle 1 is used by a single user, the certificate storage unit 105 stores the priorities (referred to as EMAID priorities) of multiple types of Contract certificates. In this case, the certificate selection unit 102 simply reads out the EMAID priority of the user from the certificate storage unit 105, determines the EMAID with the highest priority, and obtains the Contract certificate corresponding to the EMAID with the highest priority. In this way, even when the electric vehicle 1 is used by a single user, the charging control device 10 supports the single user in charging the electric vehicle 1 by using multiple Contract certificates appropriately.

[0053] FIG. 9 is a diagram illustrating a method in which the charging control device 10 handles a plurality of Contract certificates. By the procedure of FIG. 9, the charging control device 10 solves the problem of which certificate should be updated when updating and adding a new Contract certificate. FIG. 9 illustrates the relationship of data stored in the main storage unit 12 processed by the charging control device 10. The main storage unit 12 has, for example, a nonvolatile memory 12A, a volatile memory 12B, and a temporary buffer 12C. The nonvolatile memory 12A may be in the external storage unit 13 of FIG. 7. As already mentioned, the nonvolatile memory 12A may be a part of a secure memory.

[0054] The volatile memory 12B and the temporary buffer 12C are provided outside the non-volatile memory 12A, which is a secure memory. The volatile memory 12B is, for example, in the address space of the CPU 11 of the charging control device 10, and is a memory that can be directly accessed by the charging control device 10. The temporary buffer 12C provides the charging control device 10 with a function as a register or a cache.

[0055] In a system in which the charging control device 10 allows a plurality of users to use the electric vehicle 1, the non-volatile memory 12A stores an EMAID priority associated with user identification information (UID) and a Contract certificate associated with the user identification information (UID). In a charging process with the charging facility 2, the charging control device 10 reads out the EMAID priority and the EMAID of the Contract certificate A from the non-volatile memory 12A to the volatile memory 12B based on the user identification information (UID) (R1, R2). Then, the charging control device 10 compares the EMAID designated by the read EMAID priority with the EMAID that identifies the Contract certificate A, and determines whether the two EMAIDs match. If the two EMAIDs match, the charging control device 10 holds the read Contract certificate A in the temporary buffer 12C (R3). Then, the charging control device 10 uses the read Contract certificate A during the charging session and executes a procedure according to the PnC with the charging facility 2.

[0056] However, in a system in which the charging control device 10 does not allow use of the electric vehicle 1 by multiple users, the non-volatile memory 12A stores the EMAID priority of the user. In such a system, since there is only one user, it is not necessary to store the EMAID priority in association with the user identification information (UID). In this case, in the charging process with the charging equipment 2, the charging control device 10 only needs to read out the EMAID priority of the user and the EMAID of the Contract certificate A from the non-volatile memory 12A into the volatile memory 12B (R1, R2). Then, the charging control device 10 only needs to compare the EMAID specified by the read EMAID priority with the EMAID identifying the Contract certificate A and determine whether the two EMAIDs match.

[0057] In addition, in Figure 9, if a comparison between the EMAID specified by the read EMAID priority and the EMAID that identifies the Contract certificate shows that the two EMAIDs do not match, the charging control device 10 requests the MO's server 5 (or the OEM's server 6, etc.) to install a new Contract certificate via the charging equipment 2.

[0058] Fig. 10 is a diagram illustrating an example of EMAID priority levels stored in the non-volatile memory 12A. Fig. 10(A) illustrates a case where an electric vehicle 1 is used by a single user, and the single user uses Contract certificates corresponding to multiple EMAIDs. In such a case, the charge control device 10 stores the EMAIDs in the non-volatile memory 12A in order of priority. For example, a Contract certificate with a priority level of No. 1 is a certificate identified by EMAIDA, and a Contract certificate with a priority level of No. 2 is a certificate identified by EMAIDB.

[0059] FIG. 10B illustrates a case where the electric vehicle 1 is used by a plurality of users, and the plurality of users each use a Contract certificate corresponding to one or more EMAIDs. In such a case, the charge control device 10 stores the EMAIDs in the non-volatile memory 12A in order of priority for each user. For example, for a user whose user identification information is UID1, the Contract certificate with the priority No. 1 is a certificate identified by EMAIDA, and the Contract certificate with the priority No. 2 is a certificate identified by EMAIDB. Also, for a user whose user identification information is UID2, the Contract certificate with the priority No. 1 is a certificate identified by EMAIDP, and the Contract certificate with the priority No. 2 is a certificate identified by EMAIDQ. Priority No. 3 and below are omitted in FIG. 10, but EMAIDs with priority No. 3 and above may be stored sequentially in the same manner as up to No. 2. Here, the Contract certificate with priority No. 2 and above may be used, for example, when a Contract certificate with a higher priority cannot be used or when a Contract certificate with a higher priority cannot be installed.

[0060] (Processing Procedure) Fig. 11 to Fig. 13 are sequence diagrams illustrating a procedure for managing Contract certificates in this embodiment. Fig. 11 to Fig. 13 illustrate processing in the case where multiple users use an electric vehicle 1. Fig. 11 and Fig. 12 are connected by symbols A1, B1, B2, C1, and D1. Fig. 13 also illustrates details of S22 in Fig. 12. The processing in the sequence diagrams of Fig. 11 to Fig. 13 is executed among the OEM's server 6, the charging control device 10 of the electric vehicle 1, the charging facility 2, and the MO's server 5.

[0061] In this process, first, a user uses a user device to register an EMAID priority in an OEM server 6 or the like. The user device is, for example, a mobile terminal such as a smartphone, a personal computer, or a computer mounted on the electric vehicle 1. The user device accepts the registration of the EMAID priority in association with user identification information (UID) in response to a user operation (S1). When the OEM server 6 accepts the registration of the EMAID priority from the user device, it stores the user identification information (UID) and the EMAID priority in its own memory. Furthermore, the OEM server 6 notifies the charging control device 10 of the accepted user identification information (UID) and EMAID priority for confirmation (S2). Furthermore, the OEM server 6 notifies the MO server 5 of the accepted user identification information (UID) and EMAID priority (S3). Then, the charging control device 10 associates the user identification information (UID) and the EMAID priority registered in the OEM server 6 with each other and stores them in the non-volatile memory of the main storage unit 12 (S4). 10(A), in a system in which a single user uses the electric vehicle 1, the charge control device 10 does not need to associate the user identification information (UID) with the EMAID priority. In other words, the charge control device 10 only needs to store the EMAID priority in the non-volatile memory of the main storage unit 12.

[0062] Next, the charging control device 10 executes a connection to the charging facility 2 by a user operation, for example, by attaching the plug 2B in FIG. 1 to the electric vehicle 1 (S5). Alternatively, in the case of wireless communication, a connection to an access point or the like may be used. In the connection in S5, for example, a TLS handshake is executed. In addition, in the connection in S5, the charging control device 10 identifies the user identification information (UID) of the current user of the electric vehicle 1 by the user identification unit 101 (see FIG. 8), which is an acquisition device, and acquires a priority EMAID corresponding to the user identification information (UID). Here, the priority EMAID is an EMAID that has the highest priority in the EMAID priority information exemplified in FIG. 10. The procedure for the charging control device 10 to acquire the user identification information (UID) is as described in FIG. 9. In a system in which a single user uses the electric vehicle 1, the charging control device 10 may acquire the priority EMAID of the user in the process of S5.

[0063] Next, the charging control device 10 reads all the Contract certificates from the non-volatile memory (S6). In addition, the charging control device 10 checks whether or not there is a Contract certificate identified by the preferred EMAID of the current user of the electric vehicle 1 (S7).

[0064] Then, if a Contract certificate identified by the priority EMAID is present among the Contract certificates read in S6, the charging control device 10 copies the Contract certificate identified by the priority EMAID to the temporary buffer 12C (S8). On the other hand, if the confirmation in S7 shows that a Contract certificate identified by the priority EMAID is not present among the Contract certificates, the charging control device 10 proceeds to the Certificate Installation process in S22 of FIG.

[0065] Next, the process continues according to FIG. 12. For example, after determining that it is S7, the charge control device 10 determines whether or not there is a valid Contract certificate in the temporary buffer 12C (S21). Here, a valid Contract certificate is, for example, a Contract certificate identified by a priority EMAID corresponding to the user identification information (UID) of the current user of the electric vehicle 1, And it has not expired.

[0066] If there is no valid Contract certificate in the temporary buffer 12C, the charging control device 10 executes a Certificate Installation process (S22). This process is also executed when the result of the check indicates that the contract certificate identified by the priority EMAID does not exist among the contract certificates. On the other hand, when it is determined in S21 that a valid contract certificate exists in the temporary buffer 12C, the charging control device 10 skips the certificate installation process. (S23).

[0067] Then, the charging control device 10 transmits a request for service selection, payment selection, and the like to the charging facility 2, and receives a response thereto from the charging facility 2. Then, the charging control device 10 receives approval of the Contract certificate, etc. in the charging facility 2, and executes, for example, a charging process by PnC (S24).

[0068] FIG. 13 illustrates the details of the Certificate Installation process (S22 in FIG. 12) in FIG. In this process, the charging control device 10 transmits a message CertificateInstallation.Req to the charging facility 2 (S221). Then, the charging facility 2 transmits CertificateInstallation.Req to the MO server 5 (S222). For example, vehicle identification information (PCID) for identifying the vehicle is specified in the CertificateInstallation.Req. Then, The MO server 5 identifies the Contract certificate from the information acquired in S3 of FIG. 11, for example, and returns the Contract certificate together with CertificateInstallation.Res to the charging facility 2 (S223). The charging equipment 2 uses the returned Contract certificate together with CertificateInstallation.Res to charge the vehicle. The CertificateInstallation.Req is returned to the power control device 10 (S224). However, the ISO 15118 standard does not prescribe the specification of a Contract Certificate by specifying an EMAID. Also, the ISO 15118 standard does not prescribe the specification of the MO server 5 returning a Contract Certificate specified by an EMAID.

[0069] Therefore, in this embodiment, the charge control device 10 uses CertificateInstallation.Res The charging control device 10 determines whether the Contract certificate received in S224 is the desired one. First, the charging control device 10 determines whether a Contract certificate having all the data matching with the Contract certificate received in S224 is already stored in the non-volatile memory 12A (S225). Here, "all the data matching" means that the received Contract certificate and the Contract certificate stored in the non-volatile memory 12A match, for example, including the expiration date. That is, the charging control device 10 determines whether the received Contract certificate has already been stored in the non-volatile memory 12A (S225). Note that the method of determination in S225 is not limited to determining whether all the data matches with the Contract certificate received in S224. For example, the charging control device 10 may compare the hash value of the received Contract certificate with the hash value of the Contract certificate stored in the non-volatile memory 12A. That is, the charging control device 10 may perform the determination in S225 depending on whether the hash values ​​match.

[0070] If it is determined in S225 that the received Contract certificate matches all the data of any of the Contract certificates already stored in the nonvolatile memory 12A or if the hash values ​​match, the charging control device 10 does not update the nonvolatile memory (S226). In other words, if a Contract certificate identical to the received Contract certificate has already been stored in the nonvolatile memory 12A, the charging control device 10 does not update the nonvolatile memory.

[0071] On the other hand, if it is determined in S225 that the received Contract certificate has not been stored in the non-volatile memory 12A, the charging control device 10 checks whether the EMAID of the received Contract certificate matches the EMAID of the non-volatile memory 12A. It is determined whether the received Contract certificate has already been stored in the non-volatile memory 12A (S227). If the EMAID of the received Contract certificate matches the EMAID of the stored Contract certificate in S227, it can be said that the received Contract certificate is a revised version of the stored Contract certificate identified by the same EMAID.

[0072] Therefore, if it is determined in S227 that the EMAID of the received Contract certificate matches the EMAID of the stored Contract certificate, the charging control device 10 overwrites the stored Contract certificate with the received Contract certificate (S229). That is, the charging control device 10 overwrites the slot of the stored Contract certificate with the received Contract certificate. In this way, the charging control device 10 updates the Contract certificate identified by the EMAID.

[0073] Furthermore, if it is determined in S227 that the EMAID of the received Contract certificate does not match the EMAID of the stored Contract certificate, the charging control device 10 adds the received Contract certificate to a new slot in the non-volatile memory (S228). This enables the charging control device 10 to newly install a Contract certificate for a contract identified by the user identification information (UID) of the user currently using the electric vehicle 1.

[0074] (Effects of the embodiment) As described above, according to the present embodiment, the charging control device 10 stores a plurality of Contract certificates, each of which is identified by the certificate identification information (EMAID), in the non-volatile memory 12A. The charging control device 10 then stores the EMAID priority of the user who uses the charging facility 2 in the non-volatile memory 12A. When charging, the charging control device 10 identifies the certificate identification information (EMAID) designated to be prioritized according to the EMAID priority of the user. The charging control device 10 then reads out the Contract certificate of the user from the non-volatile memory 12A based on the certificate identification information (EMAID) designated to be prioritized. When there is no valid Contract certificate identified by the certificate identification information (EMAID) designated to be prioritized, the charging control device 10 acquires a new Contract certificate from the corresponding Contract certificate. Furthermore, the charging control device 10 further determines whether or not the acquired new Contract certificate of the user has already been stored in the non-volatile memory 12A. Then, if the acquired new Contract certificate of the user is already stored in the non-volatile memory 12A, the charging control device 10 does not store the acquired Contract certificate in the storage destination (slot) of the non-volatile memory 12A.

[0075] Therefore, when multiple users use a Contract certificate for each user in the same electric vehicle 1, the charging control device 10 can prevent one certificate from being overwritten by another certificate among the multiple Contract certificates. Also, the charging control device 10 can prevent the same Contract certificate identified by the certificate identification information (EMAID) from being stored in multiple storage destinations (slots) of the non-volatile memory 12A by the same user. Also, the charging control device 10 can prevent a similar problem from occurring when a single user uses multiple Contract certificates in the same electric vehicle 1. That is, the charging control device 10 can prevent overwriting among multiple Contract certificates, or prevent the same Contract certificate identified by the certificate identification information (EMAID) from being stored in the non-volatile memory 12A in multiple storage destinations, even for a single user. Therefore, it is possible to prevent the same Contract certificate from occupying multiple slots in the non-volatile memory 12A, which are storage destinations for storing Contract certificates.

[0076] In addition, in this embodiment, when an existing Contract certificate identified by the certificate identification information (EMAID) is stored in the non-volatile memory 12A, the charging control device 10 overwrites a new Contract certificate in the same slot. Here, the same slot is the storage destination of the existing Contract certificate, as described above. For this reason, the charging control device 10, for example, It is possible to prevent expired Contract certificates from remaining in the non-volatile memory 12A among a plurality of Contract certificates identified by the certificate identification information (EMAID).

[0077] Furthermore, in this embodiment, if an existing Contract certificate identified by the same certificate identification information (EMAID) is not stored in the non-volatile memory 12A, the charging control device 10 stores a new Contract certificate in a new storage destination (slot) on the non-volatile memory 12A. Therefore, the charging control device 10 can install a new Contract certificate in the non-volatile memory 12A without multiple Contract certificates identified by the certificate identification information (EMAID) being duplicated.

[0078] Furthermore, in this embodiment, the charging control device 10 stores the correspondence between user information (UID) and EMAID priority in the main storage unit 12, and identifies the EMAID priority based on the user information (UID) acquired from the user identification unit 101 that acquires the user information. Therefore, even when multiple users use the electric vehicle 1, the charging control device 10 can manage multiple Contract certificates according to the EMAID priority for each user.

[0079] <Variation 1> In the above embodiment, as illustrated in the processes of S1 to S4 in FIG. 11, the user identification information (UID) and the EMAID priority are managed by the processes of the user device and the OEM server 6. That is, the OEM server 6 accepts registration of the EMAID priority in association with the user identification information (UID) in response to a user operation on the user device. When the OEM server 6 accepts registration of the EMAID priority from the user device, it stores the user identification information (UID) and the EMAID priority in its own memory. Furthermore, the OEM server 6 notifies the charge control device 10 of the accepted user identification information (UID) and EMAID priority for confirmation. Furthermore, the OEM server 6 notifies the MO server 5 of the accepted user identification information (UID) and EMAID priority.

[0080] However, instead of such processing, the charging control device 10 of the electric vehicle 1 may manage the user identification information (UID) and the EMAID priority as a standalone device. That is, instead of performing the processing of S1 by the user device and the processing of S2 and S3 by the OEM's server 6 in FIG. 11, the user may input the user identification information (UID) and the EMAID priority via an in-vehicle operation unit connected to the charging control device 10, and the charging control device 10 may associate the input user identification information (UID) with the EMAID priority and store them in the non-volatile memory of the main storage unit 12 (S4). This allows the charging control device 10 to set and store the EMAID priority without communicating with the OEM's server 6. The same applies when a single user uses multiple Contract certificates in the same electric vehicle 1. That is, the user may input the EMAID priority via an in-vehicle operation unit connected to the charging control device 10, and the charging control device 10 may store the input EMAID priority in the non-volatile memory of the main storage unit 12 in the format of FIG. 10(A).

[0081] <Variation 2> FIG. 14 is a sequence diagram illustrating a procedure for managing a Contract certificate according to the second modification. In the above embodiment, the charging control device 10 executes a connection to the charging facility 2 (S5 above) by a user operation, for example, by attaching the plug 2B in FIG. 1 to the electric vehicle 1. In this connection, the charging control device 10 identifies the user identification information (UID) of the current user of the electric vehicle 1 and acquires a priority EMAID corresponding to the user identification information (UID). The procedure by which the charging control device 10 acquires the user identification information (UID) is as described in FIG. 9. However, in this embodiment, the charging control device 10 is not limited to such a procedure. For example, by attaching the plug 2B in FIG. 1 to the electric vehicle 1, a connection is made from an information processing device mounted on the electric vehicle 1 to the OEM's server 6, and devices external to the electric vehicle 1, such as the OEM's server 6, are connected to the charging control device 10. User authentication may be performed, for example, the server 6 may identify the user identification (UID) of the current user of the electric vehicle 1 and obtain a preferred EMAID corresponding to the user identification (UID).

[0082] 14, first, a user uses a user device to register an EMAID priority in the OEM's server 6 or the like. The user device is, for example, a mobile terminal such as a smartphone, a personal computer, or a computer mounted on the electric vehicle 1. The user device accepts registration of the EMAID priority in association with user identification information (UID) in response to a user operation (S1). When the OEM's server 6 accepts registration of the EMAID priority from the user device, it stores the user identification information (UID) and the EMAID priority in its own memory (S1A).

[0083] Next, the charging control device 10 executes a connection with the charging facility 2 by a user operation, for example, by attaching the plug 2B in FIG. 1 to the electric vehicle 1 (S1B). Then, for example, a TLS handshake is executed. At this time, a connection is further established from an information processing device mounted on the electric vehicle 1 to the OEM server 6, and a user authentication is requested (S1C). However, the processing of S1C may be executed by the charging facility 2 accepting an operation from the user. Then, the OEM server 6 accepts user identification information (UID) and executes authentication processing. Then, when the user authentication is successful, the OEM server 6 can identify the user identification information (UID). Therefore, for example, the OEM server 6 reads out an EMAID priority corresponding to the identified user identification information (UID), and notifies the charging control device 10 (S2). Also, the OEM server 6 notifies the MO server 5 of the identified user identification information (UID) and the EMAID priority (S3).

[0084] Next, the charging control device 10 reads out all Contract certificates from the non-volatile memory (secure memory) (S6). The procedures from S6 onwards are the same as those in Figs. 11 to 13. Note that the specified user identification information (UID) and EMAID priority level in S2 and S3 are notified to the charging control device 10 and the MO server 5, and the information is shared. As a result, even when the Certificate Installation process illustrated in Fig. 13 is performed, the priority EMAID is also notified to the charging control device 10 and the MO server 5. A corresponding Contract Certificate is installed in the electric vehicle 1.

[0085] As described above, the charging control device 10 or the charging facility 2 can flexibly and reliably acquire the latest EMAID priority by connecting to the OEM's server 6. According to the second modification, the EMAID priority is centrally managed by an external server such as the OEM's server 6.

[0086] <Variation 3> FIG. 15 is a sequence diagram illustrating a procedure for managing a Contract certificate according to the third modification. In the above embodiment, as shown in FIG. 13, if it is determined in S227 that the EMAID of the received Contract certificate matches the EMAID of the stored Contract certificate, the charging control device 10 overwrites the stored Contract certificate with the received Contract certificate (S229 in FIG. 13). As a result, the charging control device 10 updates the Contract certificate identified by the EMAID. Also, if it is determined in S227 that the EMAID of the received Contract certificate does not match the EMAID of the stored Contract certificate, the charging control device 10 adds the received Contract certificate to a new slot in the non-volatile memory (S228 in FIG. 13). As a result, the charging control device 10 can newly install a Contract certificate for a contract identified by the user identification information (UID) of the user currently using the electric vehicle 1.

[0087] However, in this embodiment, the process of the charging control device 10 is not limited to such a procedure. For example, if the EMAID of the received Contract certificate matches the EMAID of the stored Contract certificate, even if the expiration date has been updated, the EMAID of the stored Contract certificate may be changed. There are cases where the ract certificate has not expired and is still valid. In the present embodiment, the charging control device 10 waits for the stored Contract certificate to expire, and then deletes the stored Contract certificate.

[0088] That is, when it is determined in S227 of Fig. 15 that the EMAID of the received Contract certificate matches the EMAID of the stored, i.e., existing, Contract certificate, the charging control device 10 determines whether or not the existing Contract certificate is valid (S22A). When the existing Contract certificate has expired and is already invalid, the charging control device 10 overwrites the existing Contract certificate with the received Contract certificate (S22B). That is, the charging control device 10 overwrites the slot of the existing Contract certificate with the received Contract certificate. In this way, the charging control device 10 updates the Contract certificate identified by the EMAID.

[0089] On the other hand, if the existing Contract certificate has not expired and is valid, the charging control device 10 adds the received Contract certificate to a new slot in the non-volatile memory 12A and sets the start of invalidation management processing (S22C). Here, the invalidation management processing is processing for monitoring the expiration date of the existing Contract certificate and deleting the Contract certificate from the non-volatile memory 12A when the existing Contract certificate becomes invalid due to expiration or other reasons. The invalidation management processing may be executed as a background process, for example.

[0090] As described above, according to Modification 3, if the stored Contract certificate has not expired and is valid, the received Contract certificate is added to a new slot in the non-volatile memory 12A and invalidation management processing is started. This processing allows the existing valid Contract certificate to be fully utilized until its expiration date without being deleted.

[0091] <Other Modifications> In the above embodiment, the Contract certificate is installed in a slot of the non-volatile memory 12A. However, the processing of the charging control device 10 is not limited to installing the Contract certificate in a slot of the non-volatile memory 12A. In short, it is sufficient for the charging control device 10 to specify the correspondence between the user identification information (UID) that identifies the user who uses the charging facility 2 and the certificate identification information (EMAID) held in the EMAID priority, and install the Contract certificate. Therefore, the Contract certificate may be installed in the volatile memory 12B, etc.

[0092] <Computer-readable recording medium> A program for causing a computer or other machine or device (hereinafter, referred to as a computer, etc.) to realize any of the above functions can be recorded on a recording medium readable by the computer, etc. Then, the computer, etc. can provide the function by reading and executing the program from the recording medium.

[0093] Here, a computer-readable recording medium refers to a recording medium that stores information such as data and programs through electrical, magnetic, optical, mechanical, or chemical action and can be read by a computer. Examples of such recording media that can be removed from a computer include flexible disks, magneto-optical disks, CD-ROMs, CD-R / Ws, DVDs, Blu-ray disks, DATs, 8mm tapes, and memory cards such as flash memory. Examples of recording media that are fixed to a computer include hard disks and ROMs (read-only memories). Furthermore, SSDs (Solid State Drives) are also recording media that can be removed from a computer, and can be read by a computer. The present invention can also be used as a recording medium fixed to a computer.

[0094] <Other> Furthermore, this embodiment includes the following embodiments (hereinafter, referred to as supplementary notes). (Appendix 1) A charging control device including a controller that performs authentication processing with a charging facility using a certificate and controls charging of a vehicle, The controller: storing in memory a plurality of certificates each identified by a certificate identification information; reading out a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when performing the charging; if there is no valid certificate for the user based on the priority information, obtaining a new certificate for the user; if the obtained new certificate is not stored in the memory, storing the new certificate in the memory. Charging control device.

[0095] (Appendix 2) The charging control device according to claim 1, wherein the priority information is associated with user information that identifies a user who uses the charging facility and specifies a certificate that is to be used preferentially for the user identified by the user information.

[0096] (Appendix 3) The charging control device according to claim 1 or 2, wherein when an existing certificate identified by the same certificate identification information as the certificate identification information that identifies the new certificate is stored in the memory, the controller overwrites the new certificate to a storage destination of the existing certificate and stores the new certificate in the memory.

[0097] (Appendix 4) The charging control device according to any one of claims 1 to 3, wherein the controller stores the new certificate in a new storage location on the memory when an existing certificate identified by certificate identification information identical to certificate identification information that identifies the new certificate is not stored in the memory.

[0098] (Appendix 5) 5. The charging control device according to claim 1, wherein, when a valid existing certificate identified by the same certificate identification information as the certificate identification information that identifies the new certificate is stored in the memory, the controller stores the new certificate in a new storage destination in the memory, and further deletes the existing certificate after detecting that the existing certificate has become invalid.

[0099] (Appendix 6) The charging control device described in Appendix 2, wherein the controller stores a correspondence between the user information and the priority information in the memory, and identifies the priority information based on the user information acquired from an acquisition device that acquires the user information.

[0100] (Appendix 7) A correspondence relationship between the user information and the priority information is managed by a management device outside the vehicle, and the priority information is identified based on a user authentication process of the user. 3. The charging control device according to claim 2, wherein the controller acquires the priority information from a result of the user authentication process in the management device.

[0101] (Appendix 8) A charging control method executed by a computer that performs authentication processing with a charging facility using a certificate and controls charging of a vehicle, comprising: The computer includes: storing in memory a plurality of certificates each identified by a certificate identification information; reading out a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when performing the charging; if there is no valid certificate for the user based on the priority information, obtaining a new certificate for the user; if the obtained new certificate is not stored in the memory, storing the new certificate in the memory. Charging control method.

[0102] (Appendix 9) The certificate is used to authenticate the charging equipment and the computer that controls the charging of the vehicle is storing in memory a plurality of certificates each identified by a certificate identification information; reading out a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when performing the charging; if there is no valid certificate for the user based on the priority information, obtaining a new certificate for the user; storing the obtained new certificate in the memory if the new certificate is not stored in the memory. program. [Explanation of symbols]

[0103] 1 electric car 2 Charging equipment 2B plug 5 Server 10. Charging control device 11, 21 CPU 12, 22 Memory 12A non-volatile memory 12B volatile memory 12C Temporary Buffer 13, 23 External memory unit 16A, 26A external communication section 16B, 26B Power line communication section 101 User Identification Unit 102 Certificate Selection Section 103 Communications Department 104 Key Management Department 105 Certificate Storage Department

Claims

1. A charging control device including a controller that performs authentication processing with a charging facility using a certificate and controls charging of a vehicle, The controller: storing in memory a plurality of certificates each identified by a certificate identification information; reading out a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when performing the charging; obtaining a new certificate for the user if there is no valid certificate for the user based on the priority information; if the obtained new certificate is not stored in the memory, storing the new certificate in the memory. Charging control device.

2. The charging control device according to claim 1 , wherein the priority information is associated with user information that identifies the user who uses the charging facility, and specifies a certificate that is preferentially used for the user identified by the user information.

3. 2. The charging control device according to claim 1, wherein when an existing certificate identified by the same certificate identification information as the certificate identification information that identifies the new certificate is stored in the memory, the controller overwrites the new certificate in a storage destination of the existing certificate and stores the new certificate in the memory.

4. 2. The charging control device according to claim 1, wherein the controller stores the new certificate in a new storage location on the memory when an existing certificate identified by the same certificate identification information as the certificate identification information that identifies the new certificate is not stored in the memory.

5. 2. The charging control device according to claim 1, wherein when a valid existing certificate identified by the same certificate identification information as the certificate identification information identifying the new certificate is stored in the memory, the controller stores the new certificate in a new storage destination in the memory, and further deletes the existing certificate after detecting that the existing certificate has become invalid.

6. 3. The charging control device according to claim 2, wherein the controller stores a correspondence between the user information and the priority information in the memory, and identifies the priority information based on the user information acquired from an acquisition device that acquires the user information.

7. A correspondence relationship between the user information and the priority information is managed by a management device outside the vehicle, and the priority information is identified based on a user authentication process of the user. The charging control device according to claim 2 , wherein the controller acquires the priority information from a result of the user authentication process in the management device.

8. A charging control method executed by a computer that performs authentication processing with a charging facility using a certificate and controls charging of a vehicle, comprising: The computer includes: storing in memory a plurality of certificates each identified by a certificate identification information; reading out a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when performing the charging; obtaining a new certificate for the user if there is no valid certificate for the user based on the priority information; If the acquired new certificate is not stored in the memory, the new certificate is Storing the memory in the memory. Charging control method.

9. The certificate is used to authenticate the charging equipment, and the computer that controls the charging of the vehicle is storing in memory a plurality of certificates each identified by a certificate identification information; reading out a certificate of a user of the vehicle from the memory based on priority information that specifies a certificate to be preferentially used among the plurality of certificates when performing the charging; obtaining a new certificate for the user if there is no valid certificate for the user based on the priority information; storing the obtained new certificate in the memory if the obtained new certificate is not stored in the memory. program.

Images