On-vehicle device, information processing method and program

Abstract

To improve a security flaw due to execution of a power schedule.SOLUTION: An on-vehicle device is provided with a controller. The controller acquires expiration date information showing an expiration date related to authentication during processing for transmitting and receiving power between a battery mounted on a vehicle and a charging facility, and schedule information of the processing including a completion time when the processing is completed. Then, it updates the expiration date so as to make the expiration date to be after the completion time in the case that the processing is not completed by the expiration date.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to an in-vehicle device, an information processing method, and a program. [Background technology]

[0002] Battery electric vehicles (BEVs) and plug-in hybrid vehicles (PHVs) are well known as vehicles (also called electric vehicles) that can be connected to an external power source to charge the driving battery. There are two main authentication methods for charging the driving battery: External Identification Means (EIM) and Plug & Play. Plug and Charge (PnC) has been proposed (see, for example, Patent Document 1 below). PnC is a procedure based on ISO15118, a standard for the communication interface between electric power networks (also called power grids or power systems) and electric vehicles.

[0003] Regardless of the authentication method, if authentication of the electric vehicle or charging equipment (Electric Vehicle Supply Equipment, EVSE) is required, after the electric vehicle and EVSE connect, a certificate (e.g., a Vehicle certificate) is notified to the EVSE, and the EVSE's certificate (e.g., an SECC certificate) is notified to the electric vehicle. Each certificate is then authenticated by the operator's certificate (e.g., a V2G ROOT certificate or an OEM ROOT certificate) stored on the peer (the electric vehicle for the EVSE, and the EVSE for the electric vehicle). This authentication procedure is called Transport Layer Security (TLS) client and server authentication.

[0004] Furthermore, in PnC, a contract certificate is stored in the electric vehicle in advance, and user authentication is performed using an encryption key paired with the contract certificate.

[0005] Furthermore, ISO15118 takes various considerations into account for Vehicle-to-Grid (V2G). In other words, ISO15118 assumes that the electric power grid provided by electric power companies and the batteries of electric vehicles will be connected and that they will share power. Then, electric vehicles and infrastructure equipment on the power grid side will be able to arbitrate power schedules via communication protocols between electric vehicles and EVSE, and between EVSE and infrastructure equipment.

[0006] Also, in ISO15118, if an electric vehicle does not immediately start charging or discharging between the electric vehicle and the EVSE in terms of power scheduling, it can enter PAUSE. For example, There is also a mechanism in place that allows an electric vehicle to resume a TLS session when it is time to start power transmission. The specification stipulates that the user authentication process is skipped when this session is resumed. It also states that, instead of electric vehicles undergoing user authentication, a procedure called TLS binding can be used to link user authentication to the TLS session when connecting an electric vehicle and EVSE. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Patent Publication No. 2020-195203 Summary of the Invention [Problem to be solved by the invention]

[0008] However, ISO15118 does not describe how to operate the relationship between the execution of a power schedule and user authentication. For example, consider a situation where a process according to a power schedule is resumed after a pause. During the execution of a process in this situation, TLS The following cases are assumed: the session lifetime (for example, in ISO15118, the maximum time allowed for session resumption is set to 24 hours) expires, the Contract certificate expires, or the Vehicle certificate or SECC certificate expires. Alternatively, a combination of these cases may occur. In these cases, there will be a period during which user authentication is not guaranteed. An aspect of the disclosed embodiments is to improve security flaws associated with the execution of power schedules. [Means for solving the problem]

[0009] One aspect of the disclosed embodiment is exemplified by an in-vehicle device. The in-vehicle device includes a controller. The controller acquires expiration date information indicating an expiration date related to authentication during a process of transferring power between a battery mounted on a vehicle and a charging facility, and process schedule information including a completion date for the process. If the process is not completed by the expiration date, the in-vehicle device updates the expiration date so that the expiration date is after the completion date. [Effects of the Invention]

[0010] As described above, if the power transfer process is not completed by the expiration date related to authentication during the power transfer process, the in-vehicle device updates the expiration date so that the expiration date is after the completion date. Therefore, the power transfer process between the battery installed in the vehicle and the charging equipment can be completed before the updated expiration date. As a result, a vehicle equipped with the in-vehicle device can prevent the expiration date related to the user authentication from expiring while the power transfer process is being performed. In other words, the in-vehicle device can reduce the possibility of user authentication expiring during the process. Therefore, the in-vehicle device can improve security flaws associated with the execution of a power schedule. [Brief explanation of the drawings]

[0011] [Figure 1]FIG. 1 is a diagram illustrating a vehicle equipped with a charge / discharge control device according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating modules included in the vehicle charge / discharge control device, the back-end server of the charging facility, the MO server, and the OEM server, and data flows between the modules. [Figure 3] FIG. 3 is a diagram illustrating an example of the hardware configuration of a vehicle, a charging facility, and a back-end server. [Figure 4] FIG. 4 is a flowchart illustrating a charge / discharge process executed by the charge / discharge control device. [Figure 5] FIG. 5 is a flowchart illustrating a process for reserving a TLS full handshake. [Figure 6] FIG. 6 is a flowchart illustrating a process for updating a Contract certificate. [Figure 7] FIG. 7 is a flowchart illustrating a normal process. [Figure 8] FIG. 8 is a flowchart illustrating an example of a process for updating the TLS lifetime, each certificate, and the like. [Figure 9] FIG. 9 is a flowchart illustrating a process during a pause. [Figure 10] FIG. 10 is a flowchart illustrating a process during a pause. [Figure 11] FIG. 11 is a diagram illustrating a sequence of processing between a vehicle and a charging facility when the end date and time of the power schedule passes the expiration date and time of the SECC certificate. [Figure 12] FIG. 12 is a diagram illustrating a sequence of processes between the vehicle, the charging facility, and the OEM server 6 when the end date and time of the power schedule passes the expiration date and time of the Vehicle certificate. [Figure 13] FIG. 13 is a diagram illustrating a sequence of processes between a vehicle, a charging facility, an OEM server, and a certificate pool when the end date and time of a power schedule passes the expiration date and time of a Contract certificate. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, with reference to FIGS. 1 to 13, a charge / discharge control device 10 as an example of an in-vehicle device according to an embodiment, an information processing method executed by the charge / discharge control device 10, and a computer program (hereinafter simply referred to as a program) will be described.

[0013] <Embodiment> (Configuration) FIG. 1 is a diagram illustrating a vehicle 1 equipped with a charge / discharge control device 10 according to this embodiment. Also shown in FIG. 1 are a charging facility 2 that supplies power to a battery 19 (see FIG. 2; also referred to as a secondary battery or a storage battery) of the vehicle 1, a back-end server 3 that supports processing of the charging facility 2, a mobility operator (MO) server 5 that exchanges information with the vehicle 1, an original equipment manufacturer (OEM) server 6, and a commercial power grid provided by a power company or the like. It is also assumed that a home power grid or a power load will be connected to the vehicle 1 instead of a grid. The charge / discharge control device 10 is also referred to as an electric vehicle communication controller (EVCC). The equipment control device 20 is also referred to as a supply equipment communication controller (SECC).

[0014] The vehicle 1 is called an electric vehicle, and can charge a battery 19 for driving. The vehicle 1 has a charge / discharge control device 10 as an example of an on-board device, and performs a charging process from a charging facility 2 to the battery 19, or a discharging process from the battery 19 to a commercial power grid, a domestic load, or the like via the charging facility 2. In this embodiment, the charging process and the discharging process are called power transfer processes.

[0015] The charging facility 2 has an facility control device 20, and when connected to the charge / discharge control device 10 of the vehicle 1, communicates with the charge / discharge control device 10 in accordance with a procedure compliant with ISO15118. More specifically, the facility control device 20 establishes a TLS session with the vehicle 1 and supplies power to or receives power from the vehicle 1. After establishing the TLS session, the charging facility 2 performs authentication processing using PnC or EIM via V2G communication, and performs payment processing after authentication. Note that in this embodiment, the "payment processing" includes both payment (billing) from a user's account or the like to a business operator's account for charging the battery 19 from the charging facility 2, and payment (settlement for selling electricity) from the business operator's account to the user's account for discharging the battery 19 to the charging facility 2.

[0016] At least some of the functions of the facility control device 20 may be provided by the backend server 3. The backend server 3 establishes a TLS session with the vehicle 1, for example, via the charging facility 2. After the TLS session is established, the backend server 3 executes authentication processing by PnC or EIM through V2G communication, and performs payment processing after authentication. Furthermore, the backend server 3 communicates with the MO server 5 and the like via the network N1, and acquires, for example, the SECC certificate of the charging facility 2, the Contract certificate of the vehicle 1, the business operator certificate, and the like. The business operator certificate is, for example, the Vehicle certificate of the vehicle 1, the Contract certificate, and the like. It is used for authentication of the following:

[0017] Charging facility 2 is managed by a company called a CPO (Charge Point Operator) in addition to the MO. The charging equipment 2 may be installed in a parking lot where the vehicle 1 is parked, in a facility managed by a CPO, MO, OEM, or the like, or on the premises of a user's home. The charging equipment 2 is connected to, for example, a commercial power grid, a load in the home, or the like, and serves as an interface for sending and receiving power between the vehicle 1 and the power grid, and between the vehicle 1 and the load in the home, or the like.

[0018] The user of the vehicle 1 enters into a contract with a service provider (MO, etc.) in advance in order to execute the power transfer process via the charging facility 2. By this contract, the MO server 5 sends the A contract certificate and an encryption key are issued and installed in the vehicle 1 via the OEM server 6, for example. The contract certificate and the encryption key can also be called certificate data. Note that the certificate data such as the contract certificate may also be installed in the vehicle 1 via the charging facility 2, for example.

[0019] In the power transfer process, a TLS session is first established. For example, after the charging equipment 2 and the vehicle 1 are connected via the plug 2B, the SECC certificate of the charging equipment 2 is notified to the vehicle 1. The SECC certificate is then authenticated by the V2G ROOT certificate stored on the vehicle 1 side. Next, the Vehicle certificate of the vehicle 1 is notified to the charging equipment 2. The Vehicle certificate is then authenticated by the V2G ROOT certificate or the OEM ROOT certificate stored on the charging equipment 2 side. However, the charging equipment 2 does not need to hold these certificates, and may obtain them from the backend server 3. Here, the SECC certificate includes a hierarchically structured certificate chain of the operator associated with the V2G ROOT certificate, and the Vehicle certificate is associated with the V2G ROOT certificate or the OEM ROOT certificate. The certificate chain includes a hierarchical structure of the certificates of the entities.

[0020] A certificate chain corresponds to a hierarchy of Certificate Authorities (CAs). A higher-level CA can have a lower-level CA called an intermediate CA (also called a sub-CA). The top-level CA is called a ROOT CA and issues V2G ROOT certificates and OEM ROOT certificates for each domain. The CA certificates (sub-certificates) of the lower-level intermediate CAs are signed by the higher-level CA.

[0021] Vehicle 1 authenticates the certificate chain from top to bottom based on the V2G ROOT certificate, and is ultimately able to authenticate the EVSE Leaf certificate. If vehicle 1 successfully authenticates the SECC certificate, it can obtain the private key to use for communication with charging equipment 2, and subsequent communications are encrypted using the private key. This establishes a TLS session.

[0022] After the TLS session is established, V2G communication is performed. In V2G communication, a request from the vehicle 1 and a response from the charging facility 2 are transmitted to each other, and charging or discharging is performed. In this V2G communication, external authentication is performed using, for example, a PnC or an RFID card.

[0023] As the PnC, which is the first authentication procedure after the establishment of a TLS session, the charge / discharge control device 10 of the vehicle 1 creates a signature based on a Contract certificate and an encryption key, and the signature is authenticated by the charging facility 2. If the authentication is successful, the vehicle 1 executes a power transfer process with the charging facility 2 according to the PnC procedure.

[0024] In addition to the PnC procedure described above, the process of transferring power between the vehicle 1 and the charging facility 2 also allows for a second authentication procedure, that is, an external authentication method (EIM) procedure in which an RFID card or the like is presented. For this reason, the charging facility 2 has an EIM reader 2A. The external authentication method is an authentication method using user information acquired from a credit card, a QR code (registered trademark), RFID (Radio Frequency Identification), or the like via the EIM reader 2A. The external authentication method also includes a method in which authentication is performed from a mobile app or the like without using the EIM reader 2A.

[0025] The charge / discharge control device 10 can be connected to an MO server 5, an OEM server 6, and the like via a network N1. The network N1 is, for example, a Long Term Evolution (LTE) This includes wireless networks such as the 5th Generation Mobile Communication System (5G) and the 6th Generation Mobile Communication System (6G), as well as wired public networks such as the Internet.

[0026] For example, the charging facility 2 may transfer the signature sent from the vehicle 1 to the MO server 5 and request user authentication of the vehicle 1. Then, when the user authentication by the MO server 5 is successful, the charging facility 2 may execute a process of sending and receiving power between the charging facility 2 and the battery 19 of the vehicle 1, and may execute a payment process (billing or settlement) between the charging facility 2 and the user of the vehicle 1.

[0027] Furthermore, when performing the power transfer process, the vehicle 1 can request the charging facility 2 to install a contract certificate, etc. In this case, the vehicle 1 presents to the charging facility 2 a certificate (such as an OEM provisioning certificate) issued by the OEM, which is the manufacturer and distributor of the vehicle 1. If the charging facility 2 has a valid contract certificate, etc. and an encryption key associated with the OEM provisioning certificate, etc. notified by the vehicle 1, the charging facility 2 can provide the contract certificate, etc. to the vehicle 1. Furthermore, the charging facility 2 may access the MO server 5 to obtain a valid contract certificate, etc. and an encryption key corresponding to the OEM provisioning certificate, and install them in the vehicle 1. Note that the backend server 3, instead of the charging facility 2 or in cooperation with the charging facility 2, may authenticate the signature sent from the vehicle 1 and install a valid contract certificate, etc. in the vehicle 1.

[0028] FIG. 2 is a diagram illustrating modules and data flows between modules included in the charge / discharge control device 10 of the vehicle 1, the equipment control device 20 of the charging equipment 2, the MO server 5, and the OEM server 6, all of which comply with ISO 15118. In each module of the charge / discharge control device 10 in FIG. 2, the CPU 11 illustrated in FIG. 3 executes processing in accordance with a computer program executablely loaded in the memory 12. The back-end server 3, the MO server 5, and the OEM server 6 each have a configuration similar to the CPU 11 and the memory 12, and execute processing in accordance with a computer program. Note that at least some of the components of the equipment control device 20 may be provided in the back-end server 3. Therefore, in FIG. 2, the reference numeral 3 is enclosed in parentheses along with the reference numeral 20.

[0029] For example, before the vehicle 1 and the charging facility 2 are connected, the OEM communication control unit 113 of the vehicle 1 communicates with the OEM communication control unit 613 of the OEM server 6 to obtain certificates. More specifically, the OEM communication control unit 113 obtains an OEM provisioning certificate, a Vehicle certificate, a Contract certificate, and A certificate acquisition request for acquiring a certificate or the like is sent to the OEM communication control unit 613 (M30).

[0030] Of the certificates, the Vehicle certificate is issued by the certificate issuing unit 601 of the OEM server 6. The vehicle certificate is then transferred by the certificate acquisition unit 602 to the OEM communication control unit 113 via the OEM communication control unit 613 (M32, M35, M36). The leaf certificate is issued to the charge / discharge control device 10 (EVCC) by an OEM or a V2G certification authority (such as a sub-CA) to authenticate the authenticity of the charge / discharge control device 10 (EVCC).

[0031] The Contract certificate is stored in the certificate storage unit 512 in the MO server 5. The Contract certificate is issued to the user of the vehicle 1 by the business that supplies the electric power (referred to as a mobility service provider). The certificate acquisition unit 602 then notifies the certificate storage unit 512 of the MO server 5 of a Contract certificate request (M33) and acquires the Contract certificate (M34). In this way, the Contract certificate is handed over by the certificate acquisition unit 602 to the OEM communication control unit 113 via the OEM communication control unit 613 (M35, M36). The certificates acquired by the OEM communication control unit 113 (Vehicle certificate, Contract certificate) ) are stored in the certificate storage unit 112 (M4). The certificate storage unit 112 has a non-volatile memory area in the memory 12 (see FIG. 3), and stores the Vehicle certificate, Contract certificate, etc. The Contract certificate can also be obtained from the backend server 3 (or the equipment control device 20) via the V2G communication control units 104 and 204 (M5).

[0032] When the plug 2B of the charging equipment 2 is connected to a connection part including a terminal of the power receiving part of the power circuit and the charge communication part 16B (see FIG. 3) in the vehicle 1 that charges the battery 19 (see FIG. 3), the charge / discharge control device 10 and the equipment control device 20 (or the back-end server 3) communicate with each other. That is, the charge / discharge control device 10 and the equipment control device 20 (or the back-end server 3) perform TLS authentication and V2G communication. First, the charge / discharge control device 10 notifies the equipment control device 20 (or the back-end server 3) of, for example, a Client Hello message, and the equipment control device 20 (or the back-end server 3) notifies the charge / discharge control device 10 of a Server Hello message. In the following embodiment, the processing is described as being executed between the charge / discharge control device 10 and the equipment control device 20. However, at least a part of the processing of the equipment control device 20 may be executed in the back-end server 3.

[0033] Here, for example, in a procedure according to ISO15118-20, the TLS communication control unit 103 of the charge / discharge control device 10 transmits the Vehicle certificate to the TLS communication control unit 20 of the equipment control device 20. As described above, the vehicle certificate is stored in the certificate storage unit 112, for example. The TLS communication control unit 103 reads the vehicle certificate from the certificate storage unit 112. and notifies the TLS communication control unit 203.

[0034] The facility control device 20 communicates with the charge / discharge control device 10 in TLS communication using the vehicle certificate. The vehicle certificate verifies the authenticity of the same V2G session by the equipment control device 20. However, vehicle certificates are not used in procedures specified in standards prior to ISO 15118-20.

[0035] Meanwhile, the TLS communication control unit 203 of the equipment control device 20 transmits the SECC certificate to the TLS communication control unit 103 of the charge / discharge control device 10 in both procedures of ISO15118-20 and standards earlier than ISO15118-20 (M2). The SECC certificate is a certificate issued so that the charge / discharge control device 10 can verify the authenticity of the equipment control device 20 (SECC) or the backend server 3. In this embodiment, the SECC certificate is issued to the charging facility 2, the equipment control device 20, or the backend server 3 by either the V2G root CA or the sub-CA.

[0036] The charge / discharge control device 10 and the equipment control device 20 complete a TLS handshake through mutual communication via the TLS communication control units 103 and 203, and a TLS session begins. Here, for example, the charge / discharge control device 10 authenticates the charging equipment 2 or the equipment control device 20 (and the backend server 3) using the SECC certificate received from the equipment control device 20. The TLS communication control unit 103 also notifies the user authentication continuation determination unit 105 of the lifetime of the TLS session (denoted as "TLS expiration date" in FIG. 2) (M18). In this way, the user authentication continuation determination unit 105 acquires the lifetime of the TLS session as an example of expiration date information indicating the expiration date related to authentication during the process of transferring power. Furthermore, the TLS communication control unit 103 passes the received SECC certificate to the certificate validity period acquisition unit 102 (M3).

[0037] Furthermore, the certificate validity period acquisition unit 102 reads out the Contract certificate and the Vehicle certificate from the certificate storage unit 112 (M45). Validity period of C Certificate, Contract Certificate and Vehicle Certificate (Figure 2 shows the period marked "Period"). The user authentication continuation determination unit 105 and the certificate renewal determination unit 106 then notify the user authentication continuation determination unit 105 and the certificate renewal determination unit 106 of the expiration date (M6). In this way, the user authentication continuation determination unit 105 and the certificate renewal determination unit 106 acquire the validity periods of the SECC certificate, the Contract certificate, and the Vehicle certificate as examples of expiration date information indicating the expiration dates related to the authentication during the process of receiving and providing electric power.

[0038] Vehicle certificate authentication through the TLS communication control unit 203 (however, ISO15118- If authentication of the SECC certificate via the TLS communication control unit 103 is successful (in the case of the V2G communication control unit 104, 204), the V2G communication control unit 104, 204 executes negotiation of the V2G communication protocol and the authentication method. The V2G communication protocol (ISO15118-20, ISO15118-2, etc.) is determined by the V2G communication protocol negotiation, and the authentication method for payment (PnC, EIM, etc.) is determined by the authentication method negotiation.

[0039] Furthermore, the V2G communication control unit 104 reads the Contract certificate from the certificate storage unit 112 and transmits it together with a signature generated using the corresponding encryption key to the V2G communication control unit 204. When the V2G communication control unit 204 authenticates the Contract certificate by verifying the signature using the public key included in the Contract certificate received from the V2G communication control unit 104, it notifies the V2G communication control unit 104 of the grid power schedule.

[0040] However, if the charge / discharge control device 10 does not store a valid Contract certificate in the certificate storage unit 112, the V2G communication control unit 104 notifies the V2G communication control unit 204 of the equipment control device 20 of a Contract certificate request along with a certificate (OEM provisioning certificate) issued by the manufacturer and distributor of the vehicle 1 (M7).

[0041] If the equipment control device 20 (or the backend server 3) has a valid Contract certificate associated with the OEM provisioning certificate notified by the vehicle 1, the equipment control device 20 (or the backend server 3) can provide the Contract certificate to the vehicle 1.

[0042] However, if the business operator's computer that the equipment control device 20 can access does not hold a valid Contract certificate associated with the OEM provisioning certificate, the valid Contract certificate is acquired from the MO server 5. That is, the V2G communication control unit 204 notifies the certificate storage unit 512 of the MO server 5 of a Contract certificate request together with the OEM provisioning certificate via the certificate acquisition unit 212 (M71, M37).

[0043] Upon receiving the Contract certificate request, the certificate storage unit 512 notifies the certificate acquisition unit 212 of a valid Contract certificate associated with the OEM provisioning certificate (M38). Then, the V2G communication control unit 204 transmits the Contract certificate acquired via the certificate acquisition unit 212 to the V2G communication control unit 104 (M81, M8). The V2G communication control unit 104 transfers the acquired Contract certificate to the certificate storage unit 112 (M5, M4). In this way, the charge / discharge control device 10 can acquire a valid contract certificate from the charging facility 2. Upon transmitting the Contract certificate to the V2G communication control unit 104, the V2G communication control unit 204 performs authentication processing on the Contract certificate and then notifies the V2G communication control unit 104 of the grid power schedule (M9).

[0044] Here, the grid power schedule is the result of calculation by the grid schedule calculation unit 205. More specifically, the grid schedule calculation unit 205 calculates information that defines, on a time axis, the power that can be supplied from the power grid and the power that the power grid can accept from the vehicle 1 for a predetermined future period from the present. The grid schedule calculation unit 205 may obtain, for example, information on the supplyable power and the acceptable power for each time period from a computer on the network N1 that manages the power grid, and create the grid power schedule. The grid power schedule may include a first table that illustrates the power that the power grid can supply for each time period, and a second table that illustrates the power that the power grid can accept for each time period.

[0045] The V2G communication control unit 104 transmits the grid power schedule received from the V2G communication control unit 204 to the grid power schedule acquisition unit 107 (M12). The grid power schedule acquisition unit 107 notifies the grid power schedule to the power schedule calculation unit 101 (M14).

[0046] The power schedule calculation unit 101 calculates the amount of power J1 required to increase the current charge of the battery 19 (see FIG. 3) to the target amount of charge. The power schedule calculation unit 101 then sets a power schedule (hereinafter also referred to as a vehicle power schedule) for supplying the amount of power J1 to the battery 19 (see FIG. 3) within the range that the power grid can supply at each time (time interval) specified in the grid power schedule. Alternatively, the power is supplied from the battery 19 (see FIG. 3) to the power grid (grid) within the range that the power grid can accept and within the range that the battery 19 can supply at each time (time interval) specified in the grid power schedule. In other words, the vehicle power schedule is a time change of the power that the vehicle 1 is scheduled to receive or supply in accordance with the grid power schedule. Note that in this embodiment, the vehicle power schedule is also simply referred to as a power schedule. The power schedule calculation unit 101 notifies the user authentication continuation determination unit 105 and the certificate renewal determination unit 106 of the set power schedule (M12). In this way, the user authentication continuation determination unit 105 and the certificate renewal determination unit 106 acquire the power schedule as an example of a processing schedule.

[0047] The user authentication continuation determination unit 105 determines the validity periods of the SECC certificate, the Contract certificate, and the Vehicle certificate notified by the certificate validity period acquisition unit 102, and the TLS life The user authentication continuation determination unit 105 compares the time limit with the power schedule. For example, the user authentication continuation determination unit 105 checks the validity periods of the SECC certificate, the Contract certificate, and the Vehicle certificate, and the TL The earliest time that the S lifetime expires is identified. This earliest time is hereinafter referred to as the expiration time t1.

[0048] Then, the user authentication continuation determination unit 105 determines whether charging to or discharging from the battery 19 according to the power schedule will be completed by the deadline time t1 (hereinafter referred to as whether user authentication can be continued). Then, the user authentication continuation determination unit 105 notifies the TLS communication control unit 103 and the V2G communication control unit 104 of the determination result of whether user authentication can be continued ("whether authentication can be continued" in FIG. 2) (M19). Note that the scheduled date and time when charging to or discharging from the battery 19 according to the power schedule will be completed can be said to be the end date and time of the power schedule.

[0049] The certificate renewal determination unit 106 determines whether the Vehicle certificate notified by the certificate validity period acquisition unit 102 is valid. The certificate update determination unit 106 then notifies the OEM communication control unit 113, the V2G communication control unit 104, and the authentication method determination unit 114 whether or not the expiring certificate needs to be updated (M20).

[0050] Here, specific examples of the processing of the power schedule calculation unit 101, the user authentication continuation determination unit 105, and the certificate renewal determination unit 106 are shown below. As described above, the power schedule calculation unit 101 calculates the final power schedule by looking at the grid power schedule and the state of the battery 19 of the vehicle 1, etc.

[0051] The user authentication continuation determination unit 105 obtains each "certificate expiration date" from the certificate validity period acquisition unit 102, the "TLS lifetime expiration date" (which is one day in the standard) from the TLS communication control unit 103, and the "power schedule" from the power schedule calculation unit 101 (M6, M18, M12). When the "power schedule" exceeds each "certificate expiration date" or "TLS lifetime expiration date," the user authentication continuation determination unit 105 performs control so as not to erroneously continue the authenticated state. The user authentication continuation determination unit 105 performs, for example, the following process.

[0052] ((Process 1)) If the end date and time of the power schedule is after the "TLS lifetime expiration date" or the "SECC certificate expiration date", the power schedule calculation unit 101 sets a zero power consumption period in the power schedule before the "TLS lifetime expiration date" or the "SECC certificate expiration date" expires. The power schedule calculation unit 101 notifies the V2G communication control unit 204 of the equipment control device 20 (or the charging equipment 2) of the power schedule in which the zero power consumption period is set, via the V2G communication control unit 104. Then, while the charging equipment 2 is supplying power according to the notified power schedule, if the current time point becomes a zero power consumption period, the charging / discharging control device 10 initiates a pause. Then, when returning from the pause, the user authentication continuation determination unit 105 determines that the binding in TLS is invalid, and notifies the TLS communication control unit 103 and the V2G communication control unit 104 of "authentication continuation possible / not possible".

[0053] The TLS communication control unit 103 executes a TLS full handshake, and the V2G communication control unit 104 performs authentication again (AuthorizationReq / Res, see FIGS. 11 to 13). This updates the "TLS lifetime" and the SECC certificate, and then starts the V2G session again.

[0054] ((Process 2)) (1) If the end date and time of the power schedule is after the "Contract certificate expiration date", the charge / discharge control device 10 initiates a pause, as in process 1. When the certificate renewal determination unit 106 notifies that the "certificate renewal necessity" is "necessary", the OEM communication control unit 113 communicates with the OEM server during the pause. Alternatively, the Contract certificate may be installed via remote communication with the OEM communication control unit 613 of 6. After returning from pause, the V2G communication control unit 104 performs authentication again (AuthorizationReq / Res) using the newly installed Contract certificate. At this time, the TLS communication control unit 103 executes a full handshake with the TLS communication control unit 203 (see FIG. 13).

[0055] (2) If the Contract certificate cannot be installed during the pause using the method of (1), the charge / discharge control device 10 notifies the TLS communication control unit 103 and the V2G communication control unit 104 that "Authentication continuation possible" = "Not possible" when returning from the pause. The V2G communication control unit 104 may install the Contract certificate (CertificateInstallationReq / Res) via the charging equipment 2 using V2G communication. If the certificate installation is successful, authentication (AuthorizationReq / Res) is performed again.

[0056] For example, if the "Certificate update required" flag from the certificate update determination unit 106 is the same as the previous time and an update is required, the V2G communication control unit 104 assumes that the certificate installation has failed and switches to a contract certificate via the charging facility 2.

[0057] (3) If installation of the Contract certificate fails in (1) or (2) above, the authentication method determination unit 114 may switch the authentication method to EIM (M13). In this case, since the authentication method is different, information about the previous V2G session is discarded.

[0058] ((Process 3)) If the end date and time of the power schedule is after the "Vehicle certificate expiration date", the following process is performed: is executed.

[0059] (1) The certificate update determination unit 106 notifies the OEM communication control unit 113 that the "certificate update necessity" is "necessary." As in the processes 1 and 2, the charge / discharge control device 10 initiates a pause. While the OEM communication control unit 113 is paused, the charge / discharge control unit 10 performs remote control with the OEM communication control unit 613 of the OEM server 6. Then, the vehicle certificate is installed via the TLS communication control unit 103. After returning from the pause, the V2G communication control unit 104 performs a TLS full handshake again with the TLS communication control unit 203. Since the TLS binding is disabled, the V2G communication control unit 104 also performs V2G re-authentication.

[0060] (2) If you fail to install the Vehicle certificate in (1) above, TLS mutual authentication will not be performed. Since this is not possible, the protocol is limited to ISO15118-2, and the V2G communication control unit 104 may attempt a handshake with only server authentication using TLS1.2, or may perform communication without TLS and switch the authentication method to EIM. Note that in a handshake using TLS1.2, authentication using an SECC certificate (the vehicle 1 authenticates the charging equipment 2, etc.) is performed. In this case, the TLS version or authentication method is different, so the charge / discharge control device 10 discards the information of the previous V2G session.

[0061] Through the above processes 1 to 3, if the process of transferring power between the battery 19 and the charging equipment 2, i.e., the power schedule, is not completed by the expiration date, the charge / discharge control device 10 updates the expiration date so that the expiration date is after the completion time (after the end date and time of the power schedule).

[0062] 3 is a diagram illustrating an example of the hardware configuration of a vehicle 1, a charging facility 2, and a back-end server 3. A charging system is made up of a charge / discharge control device 10 of the vehicle 1, the charging facility 2 that charges a battery 19 mounted on the vehicle 1, and the back-end server 3. The vehicle 1 has the charge / discharge control device 10 and a battery 19 whose charging and discharging is controlled by the charge / discharge control device 10.

[0063] The charge / discharge control device 10 has a CPU 11, a memory 12, 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 storage unit 13, a display unit 14, an operation unit 15, an external communication unit 16A, and a charge communication unit 16B. The CPU 11 and the memory 12 can be collectively referred to as a control unit. The control unit is also called an Electronic Control Unit (ECU). The control unit is one of the controllers. Here is an example.

[0064] The CPU 11 executes a computer program deployed in an executable manner in the memory 12, and provides the functions of the charge / discharge control device 10. The CPU 11 is also called a processor. The CPU 11 is not limited to a single processor. The CPU 11 may be a plurality of processors of the same type operating in parallel. The CPU 11 may also include one or more dedicated processors suitable for calculations according to the processing target, such as a GPU (Graphics Processing Unit) or a DSP (Digital Signal Processor). The CPU 11 may also execute processing in cooperation with other processors of the same type, GPUs, DSPs, etc.

[0065] The memory 12 stores computer programs executed by the CPU 11, data processed by the CPU 11, etc. The memory 12 is a dynamic random access memory (DRAM), a static random access memory (SRAM), a read only memory (ROM), etc. ROM is an example of a nonvolatile area (nonvolatile memory) of the memory 12. The external storage unit 13 is used, for example, as a storage area that supplements the memory 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. The external storage unit 13 is also a nonvolatile This can be said to be an example of a region.

[0066] The display unit 14 is, for example, a liquid crystal display, an electroluminescence panel, etc. The operation unit 15 is, for example, a keyboard, a pointing device, etc. A touch panel having a touch sensor as a pointing device is exemplified as the display unit 14. The display unit 14 and the operation unit 15 function as a user interface that can be used by the user.

[0067] The external communication unit 16A exchanges data with other devices (such as the OEM server 6 in FIG. 1) on a public network such as the network N1 (see FIG. 1). For example, the CPU 11 communicates with a computer of a carrier 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 is called a TCU (Telematics Control Unit), and is used to communicate with the network N1. It may also be a device that performs communication called telematics via the Internet.

[0068] The charging communication unit 16B transmits and receives signals to and from the charging communication unit 26B. That is, the charging communication unit 16B communicates with the charging facility 2 using, for example, a PLC (Power Line Communications)-based However, the charging communication unit 16B may communicate with the charging communication unit 26B via a CAN (Controller Area Network), a wireless LAN, an Ethernet, or the like. The charge / discharge control device 10 may communicate with the charging facility 2 using the external communication unit 16A or the charge communication unit 16B, and executes a request for charging, a payment (authentication) process for charging, a request for discharging, a payment (authentication) process for discharging, etc.

[0069] The charging equipment 2 has a CPU 21, a memory 22, and external devices connected to an external interface (I / F), and executes information processing using a program. Examples of the external devices include an external storage unit 23, an external communication unit 26A, a charging communication unit 26B, and an EIM reader 2A. The charging equipment 2 also has a power supply circuit 29. The configuration of the charging equipment 2 other than the EIM reader 2A and the power supply circuit 29 is the same as that of the charge / discharge control device 10 of the vehicle 1, and therefore a description thereof will be omitted. The CPU 21, the memory 22, and the external storage unit 23 correspond to the equipment control device 20 in FIG. 1.

[0070] The EIM reader 2A is a card reader that reads information from an IC card such as a credit card by contact or contactless means, an image reader that reads a QR code (registered trademark), an RFID reader, or the like.

[0071] As described above, the charge / discharge control device 10 and the equipment control device 20 communicate with each other when the plug 2B of the power supply circuit 29 is connected to a connection portion including the terminals of the power receiving portion of the power circuit in the vehicle 1 that charges the battery 19 and the charge communication portion 16B. The charge / discharge control device 10 and the equipment control device 20 communicate with each other, for example, via the charge communication portions 16B and 26B, and execute PnC using TLS authentication and V2G communication. That is, the charge / discharge control device 10 and the equipment control device 20 authenticate each other using TLS authentication and V2G communication. The charge / discharge control device 10 and the equipment control device 20 then charge the battery 19 of the vehicle 1, perform authentication processing and payment for the charging (charging billing), discharge from the battery 19 via the charging equipment 2, and perform authentication processing and payment for the discharging (setting aside for selling electricity). However, the charge / discharge control device 10 and the equipment control device 20 may also communicate with each other via the external communication portions 16A and 26A when the plug 2B of the power supply circuit 29 is connected to the power circuit that charges the battery 19.

[0072] The power supply circuit 29 is connected to a commercial power grid and charges and discharges the battery 19. The power supply circuit 29, for example, converts AC power to DC power and charges the battery 19. However, if the vehicle 1 has a rectifier circuit, a DC-DC converter, or the like, the power supply circuit 29 may supply AC power to the vehicle 1. Furthermore, the power supply circuit 29, for example, converts DC power of the battery 19 into AC power and transmits it to the power grid. However, If the vehicle 1 has a DC-AC conversion circuit or the like, the power supply circuit 29 may receive AC power from the vehicle 1 and transmit it to the power grid.

[0073] The back-end server 3 includes a CPU 31, a memory 32, and external devices connected to an external interface (I / F), and executes information processing using a program. Examples of the external devices include an external storage unit 33, a display unit 34, an operation unit 35, and an external communication unit 36A. The CPU 31, the memory 32, the external storage unit 33, the display unit 34, the operation unit 35, and the external communication unit 36A are similar to the CPU 11, the memory 12, the external storage unit 13, the display unit 14, the operation unit 15, and the external communication unit 16A. The external communication unit 36A of the back-end server 3 communicates with the external communication unit 26A of the charging facility 2 via the network N2. The back-end server 3 cooperates with the charging facility 2 to manage charging of the battery 19 of the vehicle 1 from the power grid and discharging of the battery 19 to the power grid. The network N2 is, for example, a LAN. The network N2 can be connected to the network N1 of FIG. 1 via, for example, a communication device called a gateway.

[0074] The MO server 5 and the OEM server 6 have the same configuration as the CPUs 11 and 21, memories 12 and 22, external storage units 13 and 23, display unit 14, operation unit 15, external communication units 16A and 26A, etc. The back-end server 3, the MO server 5, and the OEM server 6 are general-purpose computers. Note that the back-end server 3, the MO server 5, and the OEM server 6 may be a collection of multiple computers called a cloud.

[0075] The MO server 5 can be said to be a computer of a business operator (MO) that provides users with charging services for their vehicles 1. Note that the charging facility 2 may be managed and operated by a business operator called a CPO (Charge Point Operator) in addition to the MO. The OEM server 6 also It can be said to be a computer of a business operator involved in the manufacture or sale of vehicle 1.

[0076] (Processing Procedure) 4 to 10 are flowcharts illustrating the charge / discharge process executed by the charge / discharge control device 10. The processes in Fig. 4 to 10 are connected by symbols A3, A5, A7, A9, B1, B2, B3, and B4.

[0077] After the charging facility 2 and the vehicle 1 are connected by the plug 2B, the charge / discharge control device 10 starts the charge / discharge process shown in Fig. 4. In the charge control process, the charge / discharge control device 10 first sets the value of each necessity flag (S0). The necessity flags are a flag indicating whether or not the Vehicle Certificate needs to be updated and a flag indicating whether or not the Contract Certificate needs to be updated. These flags are set in the memory 12, for example.

[0078] More specifically, the charge / discharge control device 10 acquires the validity period of the SECC certificate, the validity period of the Vehicle certificate, and the validity period of the Contract certificate through the processing of the certificate validity period acquisition unit 102 in FIG. The charge / discharge control device 10 also acquires the TLS lifetime expiration date through processing by the TLS communication control unit 103 in Fig. 2. Furthermore, the charge / discharge control device 10 also acquires the end date and time of the power schedule through processing by the power schedule calculation unit 101 in Fig. 2.

[0079] Then, the certificate renewal determination unit 106 (FIG. 2) of the charge / discharge control device 10 sets the flag indicating whether or not the vehicle certificate needs to be renewed to "required" if the validity period of the vehicle certificate expires before the completion of the power schedule. If the validity period of the certificate has not expired, the flag indicating whether or not the vehicle certificate needs to be renewed is set to "no."

[0080] Similarly, if the validity period of the Contract certificate expires before the completion of the power schedule, the certificate renewal determination unit 106 sets the flag indicating whether or not the Contract certificate needs to be renewed to "required." On the other hand, if the validity period of the Contract certificate expires before the completion of the power schedule, the certificate renewal determination unit 106 of the charge / discharge control device 10 If the validity period of the contract certificate has not expired, the contract certificate renewal requirement flag is set to no.

[0081] Next, the charge / discharge control device 10 sets "yes" as the initial value of a flag indicating whether or not the authentication connection is possible (S1). The flag indicating whether or not the authentication connection is possible is set, for example, in the memory 12. In FIG. 4, the symbol "=" indicates an example of substitution. In this embodiment, flags other than the flag indicating whether or not the authentication connection is possible are also set in the memory 12. However, after the pause ends (S120) in FIG. 10, the charge / discharge control device 10 also executes the process of S1 when returning from the processing during the pause (FIGS. 9 and 10) (see "B3: Return from pause").

[0082] Next, the charge / discharge control device 10 determines whether the communication protocol is ISO15118-20 and whether the flag indicating whether the vehicle certificate needs to be updated is set to "necessary" (S2). If the determination in S2 is "YES," the charge / discharge control device 10 proceeds to A3: TLS full handshake execution reservation in FIG. 5.

[0083] 5 is a flowchart illustrating the process of A3: TLS full handshake execution reservation. In this process, the charge / discharge control device 10 first sets the authentication connection permission flag to "prohibited" (S31).

[0084] Next, the charge / discharge control device 10 determines whether the flag for the certificate update failure history during pause has a history (S32). The flag for the certificate update failure history during pause is set to "has a history" if any certificate update has failed during the processing during the pause in FIGS. 9 and 10. That is, the setting value of the flag for the certificate update failure history during pause having a history indicates that the charge / discharge control device 10 attempted to update any certificate but was unable to do so, suggesting that there is a high possibility that future certificate updates will fail. On the other hand, if the certificate update has not failed, the flag for the certificate update failure history during pause is set to "no history."

[0085] If the flag for the certificate update failure history during pause indicates no history, the charge / discharge control device 10 sets the flag for TLS full handshake implementation reservation to reserved (S33). When the flag for TLS full handshake implementation reservation is set to reserved, the determination in S6 of Fig. 4 becomes YES, and the charge / discharge control device 10 proceeds to the process of S9, i.e., A9: update of TLS lifetime, each certificate, etc. Then, the charge / discharge control device 10 proceeds to the process of S4 of Fig. 4, which is connected by symbol B1.

[0086] On the other hand, if it is determined in S32 that the flag for the update failure history of the paused certificate is in the history, the charge / discharge control device 10 may perform a handshake using, for example, TLS1.2 (S34). The handshake using TLS1.2 is performed by authenticating the vehicle 1 without using a vehicle certificate. In the TLS1.2 handshake, the vehicle 1 receives the SECC certificate from the charging facility 2 and authenticates the charging facility 2. However, the process of S34 may be omitted.

[0087] Then, the charge / discharge control device 10 switches the authentication method with the charging facility 2 from ISO15118-20 to ISO15118-2. Then, the charge / discharge control device 10 advances control to the process of S97 in Fig. 8 connected at symbol B2, and starts a new V2G session.

[0088] Returning to Figure 4, the explanation continues. If the flag indicating whether or not the vehicle certificate needs to be renewed is "No", 5, if the flag for TLS full handshake execution reservation is set to reserved, the charge / discharge control device 10 proceeds to the determination of S4. The case where the necessity flag is "No" is when it is determined in S0 that the vehicle certificate renewal is not necessary, or when the initial This includes a case where it is determined that the Vehicle certificate needs to be updated in the first session and the Vehicle certificate is updated during the pause. Next, the charge / discharge control device 10 checks whether the flag indicating whether the Contract certificate needs to be updated is set to "necessary" or "not necessary." It is determined whether or not this is the case (S4).

[0089] If the flag indicating whether or not the Contract certificate needs to be updated is set to "needed," the charge / discharge control device 10 proceeds to the process of A5: Contract certificate update in FIG.

[0090] 6 is a flowchart illustrating the A5: Contract certificate update process. In this process, first, the charge / discharge control device 10 sets the flag for whether or not authentication can be continued to "no" (no). Then, the charge / discharge control device 10 determines whether or not the current V2G session is the initial session (S52). The initial session refers to the first V2G session that is started in the TLS session that is started after the connection between the charging facility 2 and the vehicle 1 via the plug 2B. Furthermore, a session that is not the initial session refers to a V2G session that is resumed after returning from a pause.

[0091] If the current TLS session is the initial session, the charge / discharge control device 10 determines whether the current time is within the zero power period (S53). If the current time is not within the zero power period, the charge / discharge control device 10 returns the control to S53 again. Note that the charge / discharge control device 10 may wait for a specific waiting time before returning to the determination in S53.

[0092] If it is determined in S53 that the current time has entered the zero power period, the charge / discharge control device 10 requests a pause from the charging facility 2 (S54). "Requesting a pause" can also be called "triggering a pause." More specifically, the charge / discharge control device 10 notifies the charging facility 2 of a V2G SessionStopReq message. Then, the charging facility 2 responds to the charge / discharge control device 10 with a SessionStopRes message and executes a pause (see FIGS. 11 to 13). At this time, for example, the power supply from the power grid to the charging facility 2 and the power supply from the charging facility 2 to the vehicle 1 are stopped.

[0093] Thereafter, the charge / discharge control device 10 executes the process during the pause (S55). Here, the charge / discharge control device 10 temporarily suspends the charge / discharge process and waits for the process during the pause to be completed. However, the process must be completed before the zero power period on the power schedule ends, and the charge / discharge control device 10 returns to the process in S1 of FIG. 4, which is connected by symbol B3.

[0094] On the other hand, if it is determined in S52 that the current TLS session is not the initial session, the charge / discharge control device 10 performs a TLS full handshake (S56). The reason for performing the TLS full handshake is to prevent the following process of S58 from being skipped in the V2G session. However, if the data related to the TLS session is valid, the previous TLS session may be resumed instead of the TLS full handshake. Furthermore, if certificate installation via the charging facility 2 is not attempted in S58, the process of S56 may be omitted.

[0095] Then, the charge / discharge control device 10 starts a new V2G session (S57). If the contract certificate has not been updated at this point (it is determined in S4 of FIG. 4 that the contract certificate needs to be updated), the charge / discharge control device 10 attempts to install the contract certificate via the charging facility 2. This corresponds to a case where the contract certificate could not be installed from the OEM server 6 due to processing during the pause. Therefore, the charge / discharge control device 10 requests the charging facility 2 (or the backend server 3) to start Certificate Installation (S58).

[0096] Then, the charge / discharge control device 10 determines whether the Certificate Installation has been successful. If the certificate installation is successful, the charge / discharge control device 10 performs the update. The updated Contract certificate is stored in the nonvolatile memory area of the memory 12 (S61). Then, the charge / discharge control device 10 performs authentication with the charging facility 2 (or the back-end server 3) using the updated Contract certificate (S62).

[0097] On the other hand, if the Certificate Installation is not successful, the charge / discharge control device 10 After the process of S60 or S62, the charge / discharge control device 10 returns to the connection at symbol B4 in FIG. 4 and ends the charge / discharge process.

[0098] The description will be continued by returning to Fig. 4. If the flag indicating whether or not the Contract certificate needs to be updated is negative in the determination at S4 in Fig. 4, the charge / discharge control device 10 determines the following (S6).

[0099] (1) The end date and time of the power schedule exceeds the TLS lifetime; or (2) The end date of the power schedule is beyond the expiration date of the SECC certificate; or (3) The TLS full handshake execution reservation flag indicates whether execution is reserved; or (4) Whether the update history flag of the certificate at the time of pause is set to "has history" If any of the conditions (1) to (4) is not satisfied, the charge / discharge control device 10 executes A7 of FIG. 7: normal processing.

[0100] 7 is a flowchart illustrating A7: normal processing. In this processing, the charge / discharge control device 10 determines whether the current V2G session is the first session or not (S72). If the current V2G session is the first session, the charge / discharge control device 10 continues the V2G session as is (S73). Since a pause has not been executed, the charge / discharge control device 10 continues the first V2G session as is.

[0101] On the other hand, if it is determined in S72 that the current V2G session is not the initial session, the charge / discharge control device 10 resumes the TLS session (S74). Here, "resuming" means restarting the TLS session that was temporarily stopped by a pause using the session ticket distributed in the initial session. Furthermore, the charge / discharge control device 10 resumes the V2G session (S74).

[0102] Here, "restart" means restarting the V2G session that was temporarily stopped due to the pause using the same session ID as the initial session. That is, when the pause is performed and all of the conditions exemplified in (1) to (4) above are not satisfied, the charge / discharge control device 10 can simply restart the session using the same session ID because none of the certificates have expired. After the process of S73 or S75, the charge / discharge control device 10 returns to the process of FIG. 4 connected by symbol B4, completes the charging schedule, and ends the charging / discharging process.

[0103] The explanation will be continued by returning to Fig. 4. If any one of the above conditions (1) to (4) is satisfied in the determination of S6 in Fig. 4, the charge / discharge control device 10 proceeds to the process of A9: TLS lifetime, update of each certificate, etc. in Fig. 8. Fig. 8 is a flowchart illustrating the process of A9: TLS lifetime, update of each certificate, etc. In this process, the charge / discharge control device 10 performs a process to resolve the above conditions (1) to (4).

[0104] In this process, first, the charge / discharge control device 10 sets the authentication connection permission flag to "prohibited" (S91). Next, the charge / discharge control device 10 determines whether the current V2G session is the first session (S92).

[0105] If the current V2G session is the first session, the charge / discharge control device 10 determines that the current time is It is determined whether the current time has entered a zero power period (S93). If the current time has not entered a zero power period, the charge / discharge control device 10 returns the control to S93 again. Note that the charge / discharge control device 10 may wait for a specific waiting time before returning to the determination of S93.

[0106] If it is determined in S93 that the current time has entered the zero power period, the charge / discharge control device 10 requests the charging facility 2 to pause (S94). Thereafter, for example, as in the case of S54, the power supply from the power grid to the charging facility 2 and the power supply from the charging facility 2 to the vehicle 1 are stopped.

[0107] Thereafter, the charge / discharge control device 10 executes the process during the pause (S95). After the process during the pause is completed, that is, after returning from the pause, the charge / discharge control device 10 returns control to the process of S1 in Fig. 4 connected by symbol B3.

[0108] On the other hand, if it is determined in S92 that the current V2G session is not the first session, the charge / discharge control device 10 performs a TLS full handshake (S96). The reason for performing the TLS full handshake is that if any of the data related to the TLS session, i.e., the TLS lifetime, the SECC certificate, or the Vehicle certificate, has expired, the previous session will be terminated. This is because the information of the previous session becomes invalid. Therefore, if the data related to the TLS session is valid, the previous TLS session may be resumed instead of a TLS full handshake. Furthermore, in the determination of S6 in FIG. 4, (1) in the case of the process of S9 in which the process during the pause is executed because the condition that the end date and time of the power schedule will pass the TLS lifetime is met, these certificates used for authentication are not updated. Therefore, when the condition that the end date and time of the power schedule will pass the TLS lifetime is met, it can be said that the charge / discharge control device 10 does not update the certificates used for authentication and performs a TLS full handshake with the charging equipment 2 after returning from pause. The TLS full handshake is an example of authentication using TLS. When the condition that the end date and time of the power schedule will pass the TLS lifetime is met, it can be said that the expiration date is the Transport Layer Security (TLS) expiration date. Furthermore, "after returning from pause" can be said to be "after the power supply suspension is lifted."

[0109] Next, the charge / discharge control device 10 starts a new V2G session (S97). The reason for starting a new V2G session is that the determination process in S6 becomes YES when TLS-related data needs to be updated or when the Contract certificate needs to be updated. In the former case, a full TLS handshake is performed, and the previous V2G session cannot be continued due to TLS binding. In the latter case, when the Contract certificate is updated, authentication (AuthorizationReq) needs to be performed using the updated Contract certificate. That is, the charge / discharge control device 10 starts a new V2G session to avoid skipping authentication (AuthorizationReq). After the process in S97, the charge / discharge control device 10 returns to FIG. 4 connected at symbol B4, performs charging / discharging processing according to the power schedule, and terminates upon completion.

[0110] 9 and 10 are flowcharts illustrating processing during a pause. The processing in FIG. 9 is continued to FIG. 10 by symbol A11. In the processing in FIG. 9, the charge / discharge control device 10 determines whether the contract certificate update necessity flag indicates that update is necessary (S101). If the contract certificate update necessity flag indicates that update is not necessary, the charge / discharge control device 10 advances control to the processing in FIG. 10 connected by symbol A11.

[0111] On the other hand, if the flag indicating whether the Contract certificate needs to be updated indicates that the update is required, the charge / discharge control device 10 determines whether communication with the OEM server 6 is possible (S102). If communication with the OEM server 6 is impossible, the charge / discharge control device 10 sets the update failure history of the paused certificate to "has history" (S109), and the control proceeds to the process in FIG. 10 connected by symbol A11.

[0112] Furthermore, if it is determined in S102 that communication with the OEM server 6 is possible, the charge / discharge control device 10 notifies the OEM server 6 of a Contract Certificate request (S103). Then, the charge / discharge control device 10 waits to receive the Contract Certificate from the OEM server 6. Furthermore, the charge / discharge control device 10 determines whether or not the reception of the Contract Certificate from the OEM server 6 has been successful (S104).

[0113] If the Contract certificate cannot be received from the OEM server 6, the charge / discharge control device 10 determines whether the retry condition is satisfied (S108). The retry condition is, for example, that the number of retries is equal to or less than the upper limit number of times or that a timeout does not occur. If the retry condition is satisfied, the charge / discharge control device 10 returns the process to S103. On the other hand, if the retry condition is not satisfied, the charge / discharge control device 10 sets the flag for the update failure history of the paused certificate to "history present" and proceeds to the process in FIG. 10 connected by symbol A11. However, the charge / discharge control device 10 may omit the retry without making the determination in S108.

[0114] On the other hand, if it is determined in S104 that the Contract certificate has been successfully received from the OEM server 6, the charge / discharge control device 10 stores the updated Contract certificate in the non-volatile memory area of the memory 12 (S105). The charge / discharge control device 10 also sets the update history flag of the paused certificate to "history present" (S106). The charge / discharge control device 10 also sets the flag indicating whether the Contract certificate needs to be updated to "no" (S107). Thereafter, the charge / discharge control device 10 advances control to the processing in FIG. 10 connected by symbol A11.

[0115] Next, the description will be continued according to Fig. 10. In this process, the charge / discharge control device 10 determines whether the flag indicating whether the vehicle certificate needs to be updated is set to whether it needs to be updated (S111). If the flag indicating whether the vehicle certificate needs to be updated is set to whether it does not need to be updated, the charge / discharge control device 10 proceeds to the process of S120.

[0116] On the other hand, if the flag indicating whether the vehicle certificate needs to be updated is set to "update required," the charge / discharge control device 10 It is determined whether communication with the OEM server 6 is possible (S112). If communication with the OEM server 6 is impossible, the charge / discharge control device 10 sets the flag for the update failure history of the paused certificate to "has history" (S119), and proceeds to the process of S120.

[0117] If it is determined in S112 that communication with the OEM server 6 is possible, the charge / discharge control device 10 notifies the OEM server 6 of a vehicle certificate request (S113). The device 10 waits to receive the vehicle certificate from the OEM server 6. The device 10 determines whether or not the Vehicle certificate has been successfully received from the OEM server 6 ( S114).

[0118] If the vehicle certificate cannot be received from the OEM server 6, the charge / discharge control device 10 It is determined whether the retry condition is satisfied (S118). The retry condition is the same as in S108. If the retry condition is satisfied, the charge / discharge control device 10 returns the process to S113. On the other hand, if the retry condition is not satisfied, the charge / discharge control device 10 sets the flag for the update failure history of the paused certificate to "history present" and proceeds to the process of S120. However, the charge / discharge control device 10 may omit the determination and retry in S118.

[0119] On the other hand, if the determination in S114 is that the vehicle certificate has been successfully received from OEM server 6, The charge / discharge control device 10 stores the updated Vehicle certificate in the non-volatile memory area of the memory 12. The charge / discharge control device 10 also sets the update history flag of the paused certificate to indicate that there is a history (S116). The certificate update necessity flag is set to "no" (S117).

[0120] Thereafter, the charge / discharge control device 10 requests the charging equipment 2 to end the pause at the timing when the zero power period ends on the power schedule, and ends the pause when it receives a response from the charging equipment 2 that the pause has ended (S120). Then, the charge / discharge control device 10 ends the processing during the pause. The end of the pause is notified, for example, by a control pilot signal that connects the charge / discharge control device 10 and the charging equipment 2. Note that if the zero power period ends before the certificate is received from the OEM server 6 during the pause, for example, the update failure history flag is set to "history present" and this processing ends. Alternatively, the charging equipment 2 may manage the end of the pause. In that case, the charge / discharge control device 10 may end the processing during the pause when it receives a pause end notification from the charging equipment 2. Note that as described above, when the Contract certificate update necessity flag is set to "no update required" and when the Vehicle certificate update necessity flag is set to "no update required", These certificates used for authentication are not updated. For example, if the determination in S6 of Fig. 4 determines that the condition (1) that the end date and time of the power schedule exceeds the TLS lifetime expiration date is met and processing during pause is executed, these certificates used for authentication are not updated.

[0121] (Processing sequence between vehicle, charging equipment, and server) Fig. 11 is a diagram illustrating a processing sequence between the vehicle 1 and the charging facility 2 when the end date and time of the power schedule passes the expiration date and time of the SECC certificate. The part illustrated by the arrow SS1 in Fig. 11 illustrates the procedure of the first session from connection to WAKEUP (return from pause). Furthermore, the part illustrated by the arrow SS2 in Fig. 11 illustrates the procedure after WAKEUP (return from pause), i.e., the procedure of the second or subsequent sessions.

[0122] In this sequence, after the charging facility 2 and the vehicle 1 are connected by the plug 2B, the vehicle 1 (charge / discharge control device 10) notifies the charging facility 2 of a ClientHello message (Q1). The charging facility 2 (the facility control device 20 or the back-end server 3 connected via the charging facility 2) transmits the SECC certificate by a ServerCertificate message (Q2). The ECC certificate is authenticated by an operator certificate (e.g., a V2G ROOT certificate or an OEM ROOT certificate) stored in the vehicle 1, and a TLS session is established. Note that in Figure 11, the arrow TN illustrates the current time on the time axis.

[0123] Next, the vehicle 1 sends a SessionSetupReq message to the charging facility 2 (Q3). The charging facility 2 then sends a SessionSetupRes message to the vehicle 1. This allows the V2G The session is established.

[0124] Furthermore, the vehicle 1 notifies the charging facility 2 of the ScheduleExchangeReq message (Q5). Then, charging facility 2 notifies vehicle 1 of the grid power schedule (SC1) along with a ScheduleExchangeRes message (Q6).

[0125] Furthermore, vehicle 1 (power schedule calculation unit 101 in FIG. 2) sets a vehicle power schedule (SC2) for charging and discharging within the range of power allowed by the grid power schedule (SC1).

[0126] 11, however, the expiration date and time (LM1) of the SECC certificate expires before the end date and time of the grid power schedule (SC1) and the end date and time of the vehicle power schedule (SC2). That is, an expired authentication period PR1 occurs in the middle of the grid power schedule (SC1) and the vehicle power schedule (SC2). Therefore, vehicle 1 sets the vehicle power schedule SC2 so that the zero power period (PR2) starts in the middle of the vehicle power schedule (SC2) before the expiration date and time of the SECC certificate (LM1).

[0127] Then, vehicle 1 notifies charging facility 2 of a PowerDeliveryReq message along with a vehicle power schedule (SC2) in which a zero power period is set (Q7). In response, charging facility 2 notifies vehicle 1 of a PowerDeliveryRes message including an acknowledgment. This establishes a charging / discharging schedule between vehicle 1 and charging facility 2.

[0128] Then, vehicle 1 sends a ChargeLoopReq message to charging equipment 2 (Q9), and charging equipment By sending a ChargeLoopRes message to vehicle 1 (Q10), the power schedule is Charging or discharging proceeds between the vehicle 1 and the charging facility 2 in accordance with the above.

[0129] Then, when the current time (arrow TN) enters the zero power period, vehicle 1 sends a SessionStopReq(PAUSE) message to charging equipment 2 (Q11), and charging equipment 2 sends a SessionStopRes message. The charging facility 2 notifies the vehicle 1 of the message (Q12), and the charging facility 2 pauses. In this embodiment, during this pause, the charging facility 2 receives a new SEC from a Certificate Authority (CA). C certificate shall be obtained.

[0130] After the zero power period ends and the power grid recovers from the pause (after WAKUEP in Figure 11), the vehicle 1 (charge / discharge control device 10) sends a ClientHello message to the charging equipment 2 (Q13). Then, charging facility 2 sends a ServerCertificate along with the new SECC certificate to vehicle 1. (Q14). The SECC certificate is authenticated by the operator certificate stored in vehicle 1, and a new TLS session is established. In this case, the expiration date (LM2) of the new SECC certificate is later than the end date and time of the vehicle power schedule (SC2).

[0131] Furthermore, vehicle 1 sends a SessionSetupReq message to charging facility 2 (Q15). Then, the charging facility 2 sends a SessionSetupRes message to the vehicle 1 (Q16). Therefore, a V2G session is established. Furthermore, vehicle 1 sends a ScheduleExchangeReq message. Then, charging facility 2 notifies vehicle 1 of the ScheduleExchangeRes message together with the grid power schedule (SC1) (Q18). After that, the normal V2G session procedures will proceed.

[0132] Note that Figure 11 illustrates an example of a processing sequence when the end date and time of the power schedule passes the expiration date of the SECC certificate, but the processing sequence when the end date and time of the power schedule passes the TLS lifetime expiration date is also the same as Figure 11.

[0133] Figure 12 shows the case where the end date and time of the power schedule passes the expiration date of the vehicle certificate. FIG. 1 is a diagram illustrating a processing sequence between a vehicle 1, a charging facility 2, and an OEM server 6. In this sequence, after the charging facility 2 and the vehicle 1 are connected via a plug 2B, the vehicle 1 (charge / discharge control device 10) sends a ClientHello message to the charging facility 2 (Q1). The vehicle 1 then transmits the ClientCertificate together with the Vehicle Certificate to the charging facility 2 (the facility control device 20 or the back-end server 3 connected via the charging facility 2) (Q21).

[0134] The vehicle certificate is stored in the charging facility 2, the back-end server 3, or the MO server 5. 12, similar to FIG. 11, the charging facility 2 transmits a ServerCertificate together with the SECC certificate (omitted in FIG. 12). The ECC certificate is authenticated by the operator certificate stored in vehicle 1, and a TLS session is established. Note that, in Figure 12, arrow TN also illustrates the current time on the time axis. Furthermore, the steps from Q3 to Q6 in Figure 12 are the same as those in Figure 11.

[0135] Furthermore, the vehicle 1 (the power schedule calculation unit 101 in FIG. 2) sets a vehicle power schedule (SC2) for charging and discharging within the range of power allowed by the grid power schedule (SC1). However, in the example of FIG. 12, the expiration date (LM3) of the vehicle certificate is The expiration date and time of the vehicle certificate (SC1) and the vehicle power schedule (SC2) will be reached before the end date and time of the grid power schedule (SC1) and the vehicle power schedule (SC2). That is, an authentication expiration period PR1 occurs during the grid power schedule (SC1) and the vehicle power schedule (SC2). Therefore, the vehicle 1 determines that the expiration date and time of the vehicle certificate (SC1) and the vehicle power schedule (SC2) will be reached before the end date and time of the vehicle power schedule (SC2). The vehicle power schedule SC2 is set so that the zero power period (PR2) begins before the expiration of the vehicle power schedule M3.

[0136] At this time, vehicle 1 creates a pair of its own public key KO and private key KP, and sends a Certificate Signing Request (CSR) containing the public key KO to O. The OEM server 6 then sends the public key KO to the OEM server 6 (Q71). The OEM server 6 then issues a new Vehicle certificate by signing the received public key KO with the private key it has obtained from the certification authority. However, the OEM server 6 transfers the CSR to the MO server 5 and creates a new Vehicle You may request the creation of a certificate and receive a Vehicle certificate from the MO server 5. The OEM server 6 distributes the created Vehicle certificate to the charge / discharge control device 10, and The OEM server 6 or the MO server 5 updates the Vehicle certificate to the new Vehicle certificate by installing the new Vehicle certificate in the control device 10 (Q72). A corresponding business certificate is distributed to the charging facility 2.

[0137] The timing of executing Q71 and Q72 is any timing before returning from pause, and may be before the vehicle 1 and the charging facility 2 are connected for the first time. The timing of executing Q72 depends on the vehicle 1. In other words, the vehicle 1 must wait until the expiration date (LM3) of the vehicle certificate expires before the grid power is charged. If it is determined that the vehicle will expire before the end date and time of the schedule (SC1) and the vehicle power schedule (SC2), a vehicle certificate is received in Q72 and the pause period is entered. When the vehicle enters the pause state, the existing vehicle certificate can be replaced with a new vehicle certificate. However, in the process of FIG. 12 of this embodiment, the new vehicle certificate is installed during the pause state. The process is illustrated in Fig. 12. The steps from Q7 to Q12 in Fig. 12 are the same as those in Fig. 11.

[0138] After the zero power period ends and the power grid returns from the pause state (after WAKUEP in FIG. 12), the vehicle 1 (charge / discharge control device 10) sends a ClientHello message to the charging facility 2 (Q13). Then, the vehicle 1 sends a ClientCertificate message together with the newly installed Vehicle certificate to the charging equipment 2 (Q141). A new TLS session is established, authenticated by the operator certificate stored in the vehicle power schedule (SC). In this case, the expiration date (LM4) of the new Vehicle certificate is The procedure from Q15 onwards in Figure 12 is the same as in Figure 11.

[0139] FIG. 13 is a diagram illustrating a sequence of processes between the vehicle 1, charging facility 2, OEM server 6, and certificate pool 4 when the end date and time of the power schedule passes the expiration date and time of the Contract certificate. In FIG. 13, the steps Q1 to Q3 in FIGS. 11 and 12 are omitted from the diagram, but are assumed to be performed in the same manner. The SessionSetupRes step in Q4 is also omitted from the diagram. Same as 12.

[0140] Then, the vehicle 1 sends an AuthorizationReq message together with the Contract certificate to the charging facility 2 (the facility control device 20 or the backend server 3 connected via the charging facility 2) (Q31). Then, the charging facility 2 sends an AuthorizationRes to the vehicle 1 (Q41). Note that in FIG. 13 as well, the arrow TN illustrates the current time on the time axis. Furthermore, the procedures of Q5 and Q6 in FIG. 13 are the same as those in FIGS. 11 and 12.

[0141] Furthermore, the vehicle 1 (power schedule calculation unit 101 in FIG. 2) sets a vehicle power schedule for charging and discharging within the range of power allowed by the grid power schedule. However, in the example of FIG. 13, the expiration date of the Contract Certificate is set at the end of the grid power schedule. It is assumed that the period will expire before the end date and time of the vehicle power schedule (the expiration dates of the vehicle power schedule and the Contract Certificate are omitted in FIG. 13). Therefore, vehicle 1 sets a zero power period in the middle of the vehicle power schedule and before the expiration date and time of the Contract Certificate.

[0142] At this time, the vehicle 1 notifies the OEM server 6 of a request for a Contract certificate (Q73). In response, the OEM server 6 sends a GET Contract Certificate message to the certificate pool 4, which is a certificate database, via the network N1 (M74), and obtains the newly updated Contract certificate (M75). The OEM server 6 then distributes the newly updated Contract certificate to the vehicle 1. Note that the Contract certificate may be stored in the certificate storage unit 512 of the MO server 5 instead of in the certificate pool 4. In that case, the OEM server 6 may obtain the newly updated Contract certificate from the certificate storage unit 512 via the network N1.

[0143] The timing for executing Q73 may be any timing before returning from pause, and may be before the vehicle 1 and the charging facility 2 are connected for the first time. That is, when the vehicle 1 determines that the Contract certificate will expire before the end date and time of the grid power schedule and the end date and time of the vehicle power schedule, the vehicle 1 can send a request for the Contract certificate to the OEM server 6 and install a new Contract certificate. However, in this embodiment, FIG. 9 illustrates an example of a process in which a new Contract certificate is installed during pause. The procedures from Q7 to Q12 in FIG. 12 are the same as those in FIG. 11.

[0144] After the zero power period ends and the power system recovers from the pause (after WAKUEP in FIG. 13), the procedures of Q13, Q141, Q15, and Q16 are the same as those in FIG. 12.

[0145] Then, vehicle 1 sends an AuthorizationReq message to vehicle 1 together with the newly installed Contract certificate (Q27). The new Contract certificate is authenticated by the provider certificate stored in charging equipment 2. In this case, the expiration date of the new Contract certificate is after the end date and time of the vehicle power schedule. The subsequent procedures are the same as those of normal charging and discharging processes.

[0146] (Effects of the embodiment) As described above, the charge / discharge control device 10, which is an example of an in-vehicle device, acquires expiration date information indicating an expiration date related to authentication during the process of transferring power between the battery 19 mounted on the vehicle 1 and the charging facility 2. The charge / discharge control device 10 also acquires a vehicle power schedule, which is process schedule information including the completion time (end date and time) when the process of transferring power will be completed. If the process is not completed by the expiration date, the charge / discharge control device 10 updates the expiration date so that the expiration date will be after the completion time of the process. Therefore, the process of transferring power between the battery 19 mounted on the vehicle 1 and the charging facility 2 can be completed before the updated expiration date. As a result, the vehicle 1 equipped with the charge / discharge control device 10 can prevent the expiration date related to user authentication from expiring while the process of transferring power is being executed.

[0147] Furthermore, the charge / discharge control device 10 requests the power supplier (power grid) via the charging facility 2 to set schedule information so that a zero power period occurs during the power transfer process in which no power is supplied (Q7.PowerDeliveryReq in FIGS. 11 to 13). Then, when the zero power period arrives, the charge / discharge control device 10 requests the power supplier via the charging facility 2 to stop power supply (S54 in FIG. 6, S94 in FIG. 8, and Q11.SessionStopReq(PAUSE) in FIGS. 11 to 13). Therefore, the charge / discharge control device 10 can correctly pause the power grid in accordance with the ISO 15118 standard. Then, TLS client authentication and server authentication are performed again, and a TLS session can be established. Furthermore, the charge / discharge control device 10 then performs authentication using the Contract certificate again, and a V2G session can be established.

[0148] Furthermore, the charge / discharge control device 10 updates the certificates used for the authentication while the power supply is stopped, thereby reducing waste of power and updating each certificate, allowing the power schedule to proceed smoothly.

[0149] Furthermore, after the suspension of power supply is lifted, i.e., after returning from pause, the charge / discharge control device 10 uses the updated certificate to perform authentication with the charging facility 2 or the power grid that supplies power via the charging facility 2, or the MO server 5. Therefore, after returning from pause, the charge / discharge control device 10 can once again perform TLS client authentication, server authentication, etc., and establish a TLS session. Furthermore, the charge / discharge control device 10 can then once again perform authentication using the Contract certificate and establish a V2G session.

[0150] Furthermore, if the expiration date is the TLS session lifetime expiration date, the charge / discharge control device 10 does not update the certificate used for authentication while the power supply is stopped. However, after the power supply is released from the suspension, i.e., after returning from the pause, the charge / discharge control device 10 performs TLS authentication with the charging facility 2. Therefore, the charge / discharge control device 10 can smoothly update the TLS lifetime expiration date.

[0151] Furthermore, the expiration date information in this embodiment may include, for example, a TLS session lifetime expiration date, a Contract certificate expiration date, a Vehicle certificate expiration date, and a SECC certificate expiration date. Therefore, the charge / discharge control device 10 can update these expiration dates in accordance with the ISO15118 standard, and can improve security flaws associated with the execution of a power supply schedule.

[0152] (Computer-readable recording medium) A program that causes 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 computer-readable recording medium. Then, by having the computer, etc. read and execute the program from this recording medium, the function can be provided.

[0153] Here, a computer-readable recording medium refers to a recording medium that stores information such as data and programs electrically, magnetically, optically, mechanically, or chemically and can be read by a computer. Among such recording media, those that can be removed from a computer include, for example, flexible disks, magneto-optical disks, CD-ROMs, CD-R / Ws, DVDs, Blu-ray disks, and memory cards such as flash memory. Furthermore, recording media that are fixed to a computer include hard disks and ROMs (read-only memories). Furthermore, SSDs (Solid State Drives) are The recording medium can be used as a recording medium that can be removed from a computer or the like, or as a recording medium that is fixed to a computer or the like. [Explanation of symbols]

[0154] 1 vehicle 2 Charging equipment 3 Backend Server 4 Certificate Pool 5 MO Server 6 OEM Servers 10. Charge / discharge control device 11, 21, 31 CPUs 12, 22, 32 memory 13, 23, 33 External memory unit 14, 34 Display section 15, 35 Operation section 16A, 26A, 36A External communication section 16B, 26B Charging communication section 19 Battery 20 Equipment control device 29 Power circuit 2A EIM Reader 2B plug 101 Power Schedule Calculation Unit 102 Certificate validity period acquisition unit 103 TLS communication control section 104 V2G communication control unit 105 User authentication continuation determination unit 106 Certificate Renewal Judgment Unit 112 Certificate Storage 113 OEM communication control unit

Claims

1. Acquire expiration date information indicating an expiration date related to authentication during a process of transferring power between a battery mounted on a vehicle and a charging facility, and schedule information for the process including a completion time for the process; an in-vehicle device including a controller that, if the processing is not completed by the expiration date, updates the expiration date so that the expiration date is after the completion date;

2. 2. The in-vehicle device according to claim 1, wherein the controller requests the power supplier via the charging facility to change the schedule information so that a zero power period occurs during the processing in which no power is supplied, and requests the power supplier via the charging facility to stop power supply when the zero power period arrives.

3. The in-vehicle device according to claim 2 , wherein the controller updates the certificate used for the authentication while the power supply is stopped.

4. 4. The in-vehicle device according to claim 3, wherein after the power supply stop is lifted, the controller performs the authentication with the charging equipment or the power supplier via the charging equipment using the updated certificate.

5. If the expiration date is a Transport Layer Security (TLS) expiration date, 3. The in-vehicle device according to claim 2, wherein the controller does not update the certificate used for the authentication while the power supply is stopped, and performs the authentication using the TLS with the charging facility after the power supply stop is lifted.

6. The expiration date information includes at least one of a TLS session lifetime expiration date, a contract certificate expiration date, a vehicle certificate expiration date, and a SECC certificate expiration date. The in-vehicle device according to claim 1 .

7. The controller Acquire expiration date information indicating an expiration date related to authentication during a process of transferring power between a battery mounted on a vehicle and a charging facility, and schedule information for the process including a completion time for the process; An information processing method, wherein if the processing is not completed by the expiration date, the expiration date is updated so that the expiration date is after the completion date.

8. In the controller, Acquire expiration date information indicating an expiration date related to authentication during a process of transferring power between a battery mounted on a vehicle and a charging facility, and schedule information for the process including a completion time for the process; A program for executing, if the processing is not completed by the expiration date, updating the expiration date so that the expiration date is after the completion date.

Images