Charging control device and program

Abstract

To prevent a charging sequence from being terminated midway due to an erroneous start of a PnC-implemented charging sequence when there is no valid contract.SOLUTION: A controller acquires contract information indicating whether or not there is a contract for receiving, using a certificate, power for charging. Then, when performing charging control: in a case of having acquired the contract information indicating the existence of the contract, the controller performs charging using the certificate; or otherwise, in a case of not having acquired the contract information indicating the existence of the contract, the controller performs charging without using the certificate.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to a charging control device and a program.

Background Art

[0002] As vehicles (also referred to as electric vehicles) that can be charged with an external power source connected to a driving battery, battery electric vehicles (BEV vehicles), plug-in hybrids (PHV) vehicles, etc. are known. Also, as authentication methods for charging the driving battery, mainly an external authentication method (External Identification Means (EIM)) and Plug and Charge (PnC) have been proposed (for example, refer to Patent Document 1 below).

[0003] PnC is a procedure according to ISO15118, which is a standard related to the communication interface between an electric vehicle and a power grid called a grid. Users of electric vehicles, such as users, owners, etc. (hereinafter referred to as users) contract with a service provider (MO (Mobility Operator)) in advance, and certificate data such as a Contract certificate is issued. The issued certificate data such as a Contract certificate is stored in a storage device of the electric vehicle. When the electric vehicle receives charging by PnC, it is authenticated at a charging facility (also referred to as a charging stand) by the Contract certificate stored in the storage device of the electric vehicle. Note that the service provider is also called an eMSP (e-mobility service provider) or an EMP (e-mobility provider).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, it is also assumed that the user may mistakenly attempt to charge by PnC at the charging facility even though there is no contract for issuing a Contract Certificate or the like, or the contract is invalid or has expired. In such a case, since a valid Contract Certificate or the like is not stored in the storage device or the like in the electric vehicle, the user attempts to install a Contract Certificate or the like from the service provider's computer via the charging facility, for example. However, since there is no valid contract in the first place, the service provider's computer cannot provide a valid Contract Certificate or the like either. For this reason, the electric vehicle fails to install a Contract Certificate or the like, and the charging procedure by PnC (hereinafter, charging sequence) stops. An aspect of the disclosed embodiment is to prevent the charging sequence from ending halfway due to the charging sequence by PnC being erroneously activated when there is no valid contract.

Means for Solving the Problems

[0006] One aspect of the disclosed embodiment is exemplified by a charging control device having a controller that performs charging control for receiving charging from a charging facility using a certificate. This controller acquires contract information as to whether there is a contract for receiving charging using a certificate. Then, when performing charging control, if contract information indicating that there is a contract is acquired, the controller performs charging using the certificate, and if contract information indicating that there is a contract is not acquired, the controller performs charging without using the certificate.

Effects of the Invention

[0007] This charging control device has a contract for receiving charging using a certificate by the above-described controller Obtain contract information of whether or not. And, when performing charging, this controller can confirm this contract information. That is, this controller can determine whether there is a valid contract or there is no valid contract in the charging of a vehicle such as an electric vehicle. As a result, for example, when there is no valid contract, this controller performs charging without using a certificate. Therefore, the charging control device provided with this controller can suppress the charging sequence by PnC from being erroneously activated despite the absence of a contract. Accordingly, this charging control device can prevent the charging sequence from ending halfway in the charging facility.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Embodiments for Carrying Out the Invention

[0009] Hereinafter, with reference to FIGS. 1 to 9, a charging control device 10 and a computer program (hereinafter simply referred to as a program) according to an embodiment will be described.

[0010] <Embodiment> (Configuration) FIG. 1 is a diagram illustrating a vehicle 1 equipped with the charging control device 10 of the present embodiment. In FIG. 1, a charging facility (Electric Vehicle Supply Equipment, EVSE) 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, the vehicle 1, and information are also described for the MO server 5 that exchanges data, and the OEM (Original Equipment Manufacturer) server 6. Note that the charging facility 2 also includes a charging point management system (CPMS) that controls and manages the EVSE.

[0011] The vehicle 1 is called an electric vehicle and can be charged with a traveling battery 19. The vehicle 1 has a charging control device 10 and executes a charging process or charging control with the charging facility 2. A user of the vehicle 1 concludes a contract with a service provider in advance in order to charge the battery 19 of the vehicle 1 at the charging facility 2. By this contract, a Contract certificate and the like and an encryption key are issued from the MO server 5 and installed in the vehicle 1 via, for example, the OEM server 6. The Contract certificate and the like and the encryption key can also be referred to as certificate data. Note that the certificate data such as the Contract certificate may be installed in the vehicle 1 via the charging facility 2 in some cases.

[0012] In the charging process, as PnC which is the first authentication procedure, the charging control device 10 of the vehicle 1 creates a signature based on the Contract certificate and the like and the encryption key, and the charging facility 2 verifies this. When the authentication is successful, the vehicle 1 executes charging with the charging facility 2. Such a procedure by PnC is started, for example, when a plug 2B for supplying power from the charging facility 2 is connected to the power receiving unit of the vehicle 1. is connected.

[0013] In addition, in the charging of the vehicle 1, in addition to the procedure by PnC as described above, as a second authentication procedure, a procedure of an external authentication method (EIM) by presenting an RFID card or the like is also possible. For this reason, the charging facility 2 has an EIM reader 2A. The external authentication method is, for example, an authentication method based on user information obtained from a credit card, a QR code (registered trademark), RFID (Radio Frequency Identification), etc. via the EIM reader 2A.

[0014] Further, the charge control device 10 can be connected to the MO server 5 and the OEM server 6 via the network N1. The network N1 includes, for example, wireless networks such as Long Term Evolution (LTE) , 5th Generation Mobile Communication System (5G), 6th Generation Mobile Communication System (6G), etc., and wired public networks such as the Internet.

[0015] The charging facility 2 may, for example, transfer the signature transmitted from the vehicle 1 to the MO server 5 and request authentication of the user of the vehicle 1. Then, when the authentication at the MO server 5 is successful, the charging facility 2 may charge the battery 19 of the vehicle 1 and charge the user of the vehicle 1. Further, when receiving charging, the vehicle 1 can also request the installation of a Contract certificate or the like from the charging facility 2. In this case, the vehicle 1 presents a certificate (such as an OEM provisioning certificate) issued by the OEM, which is the manufacturer and seller of the vehicle 1, to the charging facility 2. When the charging facility 2 has a valid Contract certificate or the like associated with the OEM provisioning certificate or the like notified from the vehicle 1 and a cryptographic key, it can provide the Contract certificate or the like to the vehicle 1. Further, the charging facility 2 may access the MO server 5 to obtain a valid Contract certificate or the like corresponding to the OEM provisioning certificate and a cryptographic key, and install them in the vehicle 1.

[0016] FIG. 2 is a diagram illustrating the hardware configuration of the vehicle 1 and the charging facility 2. The charging control device 10 of the vehicle 1 and the charging facility 2 that charges the battery 19 mounted on the vehicle 1 constitute a charging system. The vehicle 1 has a charging control device 10 and a battery 19 whose charging is controlled by the charging control device 10.

[0017] The charging control device 10 includes 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 charging communication unit 16B. The CPU 11 and the memory 12 together can be referred to as a control unit. The control unit is also called an Electronic Control Unit (ECU). The control unit is an example of a controller is.

[0018] The CPU 11 executes a computer program developed to be executable in the memory 12 and provides the functions of the charging control device 10. The CPU 11 is also called a processor. The memory 12 stores a computer program executed by the CPU 11, data processed by the CPU 11, and the like.

[0019] The memory 12 is a Dynamic Random Access Memory (DRAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), or the like. The ROM is an example of a non-volatile area of the memory 12. The external storage unit 13 is used, for example, as a storage area that supplements the memory 12, and stores a computer program executed by the CPU 11, data processed by the CPU 11, and the like. The external storage unit 13 is a hard disk drive, a Solid State Drive ( SSD), or the like. The external storage unit 13 can also be said to be an example of a non-volatile area. SSD), etc.

[0020] The display unit 14 is, for example, a liquid crystal display, an electroluminescent panel, or the like. The operation unit 15 is, for example, a keyboard, a pointing device, or the like. In the present embodiment, a touch panel including a touch sensor as a pointing device is exemplified. The display unit 14 and the operation unit 15 act as a user interface available to the user.

[0021] 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 business operator's computer 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. Also, the external communication unit 16A may 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 may execute communication called telematics via the network N1 as well.

[0022] 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 based on, for example, PLC (Power Line Communications) or a communication method similar to PLC. However, the charging communication unit 16B may communicate with the charging communication unit 26B according to CAN (Controller Area Network) or a communication procedure based on CAN as a basis. Also, the charging communication unit 16B may communicate with the charging communication unit 26B according to Ethernet or wireless LAN, or a communication procedure based on Ethernet or wireless LAN. Note that the charging communication unit 16B may have a CPU, a memory, an input / output interface, a communication interface, etc. inside. In the present embodiment, the charging control device 10 communicates with the charging facility 2 through the external communication unit 16A or the charging communication unit 16B and executes charging request and authentication processing.

[0023] The charging device 2 includes a CPU 21, a memory 22, and an external device connected to an external interface (I / F), and executes information processing by a program. Examples of the external device include an external storage unit 23, a display unit 24, an operation unit 25, an external communication unit 26A, a charging communication unit 26B, and an EIM reader 2A. Further, the charging device 2 has a power supply circuit 29. Among the charging device 2, the configurations other than the EIM reader 2A and the power supply circuit 29 are the same as those of the charging control device 10 of the vehicle 1, and thus the description thereof is omitted.

[0024] The EIM reader 2A is a card reader that reads information in contact or non-contact from an IC card such as a credit card, an image reader that reads a QR code (registered trademark), an RFID reader, or the like. The power supply circuit 29 supplies power to the battery 19 and charges the battery 19.

[0025] When the plug 2B of the power supply circuit 29 is connected to the power circuit in the vehicle 1 that charges the battery 19, the charging control device 10 of the vehicle 1 and the charging device 2 communicate with each other. The charging control device 10 of the vehicle 1 and the charging device 2 communicate with each other, for example, through the charging communication units 16B and 26B, and execute PnC by TLS authentication and Vehicle-to-Grid (V2G) communication. The charging control device 10 of the vehicle 1 and the charging device 2 execute charging of the battery 19 of the vehicle 1 and authentication processing for the charging by TLS authentication and V2G communication. However, when the plug 2B of the power supply circuit 29 is connected to the power circuit that charges the battery 19, the charging control device 10 of the vehicle 1 and the charging device 2 may communicate with each other via the external communication units 16A and 26A.

[0026] The MO server 5 and the OEM server 6 have the same configurations as the CPU 11, 21, the memory 12, 22, the external storage unit 13, 23, the display unit 14, 24, the operation unit 15, 25, the external communication unit 16A, 26A, etc. The MO server 5 and the OEM server 6 are general computers. Note that the MO server 5 and the OEM server 6 may be a set of a plurality of computers called a cloud. It may be a set.

[0027] The MO server 5 can be a computer of an operator (MO) that provides a charging service to the vehicle 1 for the user. Note that the charging facility 2 may be managed and operated by an operator called a CPO (Charge Point Operator) in addition to the MO. Also, the OEM server 6 can be a computer of an operator related to the manufacture or sale of the vehicle 1.

[0028] (Charging sequence of the embodiment) FIG. 3 is a diagram illustrating the procedure of charging control by the charging control device 10 according to the present embodiment. Before charging by the charging control device 10, the user of the vehicle 1 concludes a contract with the MO for using the charging facility 2. By concluding this contract, the MO encrypts and issues a unique Contract certificate for each user and a private key corresponding to the Contract certificate with a common key. The Contract certificate and the private key corresponding to the Contract certificate are installed in the vehicle 1 via the OEM server 6 or via the charging facility 2. In FIG. 3, the procedure when the Contract certificate and the private key corresponding to the Contract certificate are installed in the vehicle 1 via the charging facility 2 is illustrated.

[0029] When the contract conclusion with the MO is completed, the user accesses the OEM server 6 using, for example, a user terminal or the like and registers the contract information in the OEM server 6 (S1). The user terminal is, for example, a device called a mobile phone, a mobile terminal, or a smartphone. The user terminal may be a personal computer, an in-vehicle computer, or the like.

[0030] The contract information includes, for example, something called a charging service account identifier (eMAID (eMobility Account Identity)). Note that the contract information includes the validity period of the contract. This is also acceptable. The validity period is defined by, for example, the start date when the contract becomes effective and the end date when the validity period of the contract expires (also referred to as the expiration date). Along with the eMAID indicating that the contract is valid, the validity period of the contract is stored in the vehicle 1 from the OEM server 6, so that the charge control device 10 of the vehicle 1 can manage the validity period.

[0031] Alternatively, instead of the user registering the contract information with the OEM server 6 using the user terminal, when the MO server 5 recognizes the conclusion of the contract, the MO server 5 may register the contract information with the OEM server 6 (S2). The MO server 5 can recognize the conclusion of the contract, for example, when the contract information is set. At this time, the MO server 5 may register the Contract certificate, the private key, etc., and the validity period of the contract, etc. with the OEM server 6 included in the contract information.

[0032] In addition, when the contract between the user and the MO becomes invalid due to cancellation of the contract, expiration of the validity period, etc., the MO server 5 may notify the OEM server 6 of the invalidation information together with the eMAID. The OEM server 6 may initiate processing for the vehicle 1 according to the notification of the contract information or the notification of the invalidation information from the MO server 5.

[0033] Furthermore, when the conclusion of the contract between the user and the MO is completed, the MO server 5 registers the contract information such as the Contract certificate and the private key corresponding to the Contract certificate together with the eMAID of the user in the certificate pool (S3). The certificate pool is, for example, a database constructed in the memory 22, the external storage unit 23, etc.

[0034] When the OEM server 6 receives the registration of the contract information, based on the contract information, the OEM server 6 creates contract existence information indicating "contract exists". The contract existence information may be contract information indicating the existence of a contract or contract information indicating the non - existence of a contract. Then, the OEM server 6 transmits the contract existence information to the vehicle 1 via telematics communication, etc. (S4). When the charge control device 10 of the vehicle 1 receives the contract existence information, it stores it, for example, in the non - volatile area of the memory 12 or the external storage unit 13. Step (S5). The process of S5 can also be said to be a process of installing contract presence / absence information indicating the presence of a contract in Vehicle 1.

[0035] In addition, when the power supply of Vehicle 1 is off, the OEM server 6 may transmit a wake-up packet for starting only the charging control device 10 in Vehicle 1, and cause the charging control device 10 to store the contract presence / absence information. Also, as described above, the OEM server 6 may transmit information indicating the valid period of the contract to Vehicle 1 together with the contract presence / absence information, and store it in the non-volatile area of the memory 12 or the external storage unit 13.

[0036] With such contract presence / absence information indicating the presence of a contract installed in Vehicle 1, the user connects Vehicle 1 to the charging facility 2. For example, when the plug 2B of the charging facility 2 is attached to the connection part including the power receiving part and the communication terminal of Vehicle 1, the charging control device 10 and the charging facility 2 start communication between the charging communication parts 16B and 26B (S6).

[0037] When starting communication after the connection between Vehicle 1 and the charging facility 2, the charging control device 10 reads out, for example, the contract presence / absence information and the Contract certificate, etc. from the non-volatile area of the memory 12. FIG. 3 illustrates the process when the contract presence / absence information indicates "contract exists" and the Contract certificate, etc. is not stored in the memory 12, etc. When the contract presence / absence information indicates "contract exists" and the Contract certificate is not stored, the charging control device 10 requests the charging facility 2 to install the Contract certificate, etc. from the charging facility 2 (S7). At this time, the charging control device 10 may deliver the eMAID to the MO server 5 via the charging facility 2 together with the OEM provisioning certificate. It may also be delivered directly to the MO server 5 from the user terminal.

[0038] Then, based on the eMAID, the charging facility 2 obtains the user's Contract certificate and the private key corresponding to the Contract certificate from the MO server 5. That is, the charging facility 2 requests the Contract certificate corresponding to the eMAID and the private key etc. corresponding to the Contract certificate from the MO server 5 (S8), and receives them as a response from the MO server 5 (S9). Then, the charging facility 2 responds with the Contract certificate and the private key etc. to the charging control device 10 of the vehicle 1 (S10). The private key corresponding to the Contract certificate is also called the Contract private key.

[0039] When the charging control device 10 receives the Contract certificate and the private key etc. from the charging facility 2, it stores them in the non-volatile area of the memory 12, the external storage unit 13, etc. (S11). Then, the charging control device 10 generates a signature, for example, by encrypting the Contract certificate and a random number called GenChallenge received from the charging facility 2 with the private key (S12). Furthermore, the charging control device 10 transmits the generated signature to the charging facility 2 and requests user authentication (S13). When the authentication is successful in the charging facility 2 or the MO server 5 via the charging facility 2 in response to the request in S13, charging starts between the vehicle 1 and the charging facility 2 (S14).

[0040] FIG. 4 is a diagram illustrating the processing by the charging control device 10 according to the present embodiment (when the Contract certificate is stored). FIG. 4 illustrates the processing when the contract presence / absence information indicates "there is a contract" and the Contract certificate is stored before the connection between the vehicle 1 and the charging facility 2. Therefore, similar to FIG. 3, it is assumed that the processing of storing the contract presence / absence information in the memory 12 (S5) and the processing of storing the Contract certificate and the private key etc. in the memory 12 (S11) have been executed in the same procedure as in FIG. 3.

[0041] However, instead of obtaining the Contract Certificate and the private key, etc. from the charging facility 2, the vehicle 1 may obtain them from the OEM server 6. When the contract information is registered by the user, the OEM server 6 may transmit the Contract Certificate, the private key, etc. to the charging control device 10 of the vehicle 1 together with the contract existence information indicating "contract exists", and register them in the non-volatile area of the memory 12 or the like. Note that the OEM server 6 may cooperate with the MO server 5. In that case, when the conclusion of the contract between the user and the MO is registered in the MO server 5, the MO server 5 may provide the Contract Certificate, the private key, etc. to the OEM server 6. When the conclusion of the contract between the user and the MO is registered in the MO server 5, the MO server 5 may provide the Contract Certificate, the private key, etc. to the OEM server 6.

[0042] As described above, in FIG. 4, with the contract existence information indicating "contract exists", the Contract Certificate, the private key, etc. are installed in the charging control device 10 of the vehicle 1, and the user connects the vehicle 1 to the charging facility 2 (S21). Then, the charging control device 10 generates a signature (S22). Further, the charging control device 10 notifies the charging facility 2 that it selects PnC as the authentication method (S23). Then, the charging control device 10 transmits the generated signature to the charging facility 2 and requests user authentication (S24). In response to the request in S24, the charging facility 2 or the MO server 5 via the charging facility 2 executes signature authentication (S25). When the authentication is successful in the charging facility 2 or the MO server 5 via the charging facility 2, charging starts between the vehicle 1 and the charging facility 2 (S26).

[0043] FIG. 5 is a diagram illustrating the processing when the contract is cancelled, or when the validity period of the contract expires and the contract becomes invalid due to expiration. When the user cancels the contract with the MO, the user accesses the OEM server 6 using a user terminal or the like, and registers the cancellation of the contract in the OEM server 6 by specifying the user's eMAID (S31). However, even when the user recognizes that the validity period of the contract has expired, the user may register the invalidation of the contract in the OEM server 6 (S31).

[0044] Also, when it is registered in the MO server 5 that the user has canceled the contract with the MO, the MO server 5 may register the cancellation of the contract by designating the eMAID to the OEM server 6 (S32). Also, when the MO server 5 recognizes that the expiration date of the user's contract has expired, it may register the expiration of the user's contract with the OEM server 6.

[0045] As already described, together with the eMAID indicating that the contract is valid, the expiration date of the contract may be installed in and stored in the vehicle 1 from the OEM server 6, and the charging control device 10 of the vehicle 1 may manage the expiration date. In this case, the charging control device 10 of the vehicle 1 may store the contract existence information as "no contract" in the non-volatile area of the memory 12 or the like without the intervention of the user, the OEM server 6, the MO server 5, or the like.

[0046] When the OEM server 6 is registered with the cancellation or expiration of the contract from the user terminal or the MO server 5, based on the registered information, the OEM server 6 creates contract existence information indicating "no contract". Then, the OEM server 6 transmits the contract existence information to the vehicle 1 via telematics communication or the like (S34). When the charging control device 10 of the vehicle 1 receives this contract existence information, it stores it, for example, in the non-volatile area of the memory 12 or the external storage unit 13 (S35).

[0047] When the power of the vehicle 1 is off, the OEM server 6 transmits a wake-up packet for starting only the charging control device 10 in the vehicle 1, which is the same as when transmitting the contract existence information indicating "contract exists" to the vehicle 1. Further, the charging control device 10 deletes the Contract certificate and the corresponding private key from the non-volatile area of the memory 12 or the like (S36). The process of S36 can also be called the uninstallation process of the Contract certificate or the like from the vehicle 1. As a result, the vehicle 1 is in a state where the contract existence information indicates "no contract" and the Contract certificate or the like is not installed.

[0048] Then, for example, when the plug 2B of the charging facility 2 is attached to a connection portion including a power receiving unit and a communication terminal of the vehicle 1, the charging control device 10 and the charging facility 2 start communication between the charging communication units 16B, 26B (S41). As described above, at the time of connection in S41, the contract existence information of the vehicle 1 indicates "no contract" and the Contract certificate, etc. are not installed.

[0049] Therefore, the charging control device 10 notifies the charging equipment 2 that EIM is to be selected as the authentication method. The charging control device 10 notifies the user that the EIM has been read (S43). Then, the charging control device 10 requests the charging equipment 2 to perform authentication using the EIM (S44). Alternatively, the charging control device 10 prompts the user via the display unit 14 or the like to request the charging equipment 2 to perform authentication using the EIM. Then, the charging equipment 2 reads the EIM using, for example, the EIM reader 2A. Then, the charging equipment 2 performs external authentication using the read EIM (S45). If the external authentication is successful, charging starts between the vehicle 1 and the charging equipment 2 (S46).

[0050] (Processing flow) FIG. 6 is a diagram illustrating the process of the OEM server 6. The OEM server 6 executes the process of FIG. 6 at a predetermined cycle (for example, once a month). For example, the OEM server 6 may execute the process of FIG. 6 when it receives contract information from a user terminal or the MO server 5. For example, the OEM server 6 may execute the process of FIG. 6 when it receives a contract expiration from a user terminal or the MO server 5. In FIG. 6, the flow on the left side (S51 to S54) is the process when contract information is received, and the flow on the right side (S55 to S58) is the flow when the contract expires. In FIG. 6, the flow on the right side (S55 to S58) is executed after the flow on the left side (S51 to S54), but the order of execution is not fixed between the process of S51 to S54 and the process of S55 to S58.

[0051] In this process, first, the OEM server 6 determines whether it has received the contract information (S51). When the OEM server 6 receives the contract information, it then determines whether the charging control device 10 of the vehicle 1 is communicable (S52). Whether the charging control device 10 is communicable means, for example, that a message for confirming that the charging control device 10 is operating is sent by the OEM server 6 and its reply can be confirmed within a predetermined time.

[0052] When the charging control device 10 of the vehicle 1 is not communicable, the OEM server 6 transmits a wake-up packet for starting the charging control device 10, turns on the power of the charging control device 10, and starts the charging control device 10 (S53). In this embodiment, it is assumed that the charging control device 10 operates with a weak power source capable of receiving a wake-up packet even when it is stopped, and has a control circuit for turning on the power to the charging control device 10 upon reception of the wake-up packet.

[0053] When the charging control device 10 of the vehicle 1 is communicable (YES in S52), the process of S53 is omitted. Then, when the charging control device 10 starts up and becomes communicable, the OEM server 6 transmits contract presence / absence information indicating "contract exists" to the charging control device 10 and stores it in the non-volatile area (S54).

[0054] Next, the OEM server 6 determines whether it has received the expiration of the contract or detected that the validity period of the contract has expired (S55). Even when it has not received the contract information in the determination of S51 (NO in S51), the OEM server 6 proceeds to the determination of S55.

[0055] Here, receiving the invalidation of the contract means that the user terminal or the MO server 5 receives that the contract has been canceled or the validity period of the contract has expired. Also, detecting that the validity period of the contract has expired means that it is detected that the time information obtained via the clock (OS clock) built into the OEM server 6 or the external communication unit 16A has passed the end date (expiration date) of the user's contract validity period. Note that the OEM server 6 may store information regarding the end date (expiration date) of the validity period in the storage device or periodically monitor the validity period included in the Contract certificate in order to detect that the validity period of the contract has expired. Also, the process of detecting that the validity period of the contract has expired and the notification process to the vehicle 1 accompanying the detection may be executed as an independent process separate from the process of FIG. 6 by the OEM server 6.

[0056] When the determination in S55 is YES (affirmative), next, the OEM server 6 determines whether the charging control device 10 of the vehicle 1 is communicable (S56). If the charging control device 10 of the vehicle 1 is not communicable, the OEM server 6 transmits a wake-up packet for starting the charging control device 10 (S57).

[0057] Since the process of S57 is the same as the process of S53, the description thereof is omitted. Note that when the charging control device 10 of the vehicle 1 is communicable (YES in S56), the process of S57 is omitted. And when the charging control device 10 is activated and becomes communicable, the OEM server 6 transmits contract availability information indicating "no contract" to the vehicle 1 and stores it in the non-volatile area (S58).

[0058] Note that, in order for the charging control device 10 as described above to execute the process of receiving contract information, expiration information, etc. from the OEM server 6 or the like, a control circuit for receiving a wake-up packet is not an essential configuration. For example, the OEM server 6 may transmit contract information, expiration information, etc. to the charging control device 10 and store them in the memory 12 only when it detects that the charging control device 10 is operating and communicable. For example, when the charging control device 10 is not operating, the OEM server 6 may execute a process of retrying until the charging control device 10 is started. Also, the execution of the process in FIG. 6 may be performed when the charging control device 10 is started by turning on the power, when access to the OEM server 6 is instructed by a user's operation on the operation unit 15, during maintenance of the vehicle 1, or at a predetermined cycle (once a month, once a year, etc.). That is, when illustrated here, the charging control device 10 may access the OEM server 6, check for the presence or absence of contract information, expiration information, etc., and request the transmission of contract information, expiration information, etc. if there is such information. The charging control device 10 may store the contract information, expiration information, etc. received upon request from the OEM server 6 in the memory 12.

[0059] FIG. 7 is a diagram illustrating a process before the charging control device 10 of the vehicle 1 connects to the charging facility 2. This process is started, for example, when the charging control device 10 receives contract presence / absence information from the OEM server 6 or when it detects an input of contract presence / absence information from a user interface including the operation unit 15 by the user (S71). However, the charging control device 10 may monitor the reception from the OEM server 6 at a predetermined cycle (for example, once a month) and execute the process in FIG. 7.

[0060] When the determination in S71 is YES (affirmative), the charging control device 10 stores the contract presence / absence information in the non-volatile area of the memory 12, storing the received contract presence / absence information or the input contract presence / absence information (S72). When the contract presence / absence information is "no contract", the charging control device 10 further deletes the Contract certificate and the corresponding private key from the non-volatile area of the memory 12 or the like. On the other hand, when the determination in S71 is NO (negative), the charging control device 10 ends the process without doing anything.

[0061] FIG. 8 is a diagram illustrating the process after the connection of the charging control device 10 of the vehicle 1 to the charging facility 2. This process is started, for example, when the plug 2B of the charging facility 2 is attached to the connection part including the power receiving part and the communication terminal of the vehicle 1. In this process, the charging control device 10 attempts to read the Contract certificate from the non-volatile area of the memory 12 (S101). Next, the charging control device 10 attempts to read the contract presence / absence information from this non-volatile area (S102).

[0062] Then, the charging control device 10 determines whether there is a valid Contract certificate in the memory 12 (S103). If a valid Contract certificate is stored in the memory 12 and the charging control device 10 can read the valid Contract certificate in S101 (YES in S103), the charging control device 10 executes charging by PnC (S104).

[0063] On the other hand, when a valid Contract Certificate is not stored in the memory 12 (NO in S103), the charging control device 10 proceeds to the determination in S105. Here, the case where a valid Contract Certificate is not stored in the memory 12 includes the case where there is no Contract Certificate in the memory 12 and the case where the Contract Certificate stored in the memory 12 is not valid. An invalid Contract Certificate refers to, for example, a Contract Certificate whose expiration date has passed or a Contract Certificate whose start date of the validity period has not yet arrived. In order for the charging control device 10 to determine whether it is a valid Contract Certificate, for example, the information on the validity period included in the Contract Certificate may be referred to. However, when the Contract Certificate is installed in the charging control device 10 only for the validity period and the Contract Certificate is deleted from the charging control device 10 when the validity period expires, the charging control device 10 can determine that the Contract Certificate stored in the memory 12 is valid.

[0064] Then, the charging control device 10 determines whether the contract presence / absence information is "contract exists" and whether the current time is within the validity period of the contract (S105). If the determination in S105 is YES (affirmative), the charging control device 10 acquires the Contract Certificate and the private key corresponding to the Contract Certificate from the charging facility 2 (S106). Then, the charging control device 10 stores the acquired Contract Certificate and private key in the non-volatile area of the memory 12 (S107). Then, the charging control device 10 proceeds to S104 and executes charging by PnC.

[0065] On the other hand, if the determination in S105 is NO (negative), the charging control device 10 proceeds to S108. The case where the determination in S105 is NO means that the contract presence / absence information is "no contract" or the current time is not within the valid period of the contract. Note that the case where the contract presence / absence information is "no contract" includes the case where the contract presence / absence information itself is not stored in the memory. That is, the case where the contract presence / absence information is "no contract" and the case where the contract presence / absence information itself is not stored in the memory can be combined and regarded as the case where contract information indicating the existence of a contract has not been acquired. Also, the case where the current time is not within the valid period of the contract means that the current time has not reached the start date of the valid period according to the user's contract or the valid period of the contract has expired.

[0066] In the determination of S105, the charging control device 10 may determine that the current time is not within the valid period of the contract based on information acquired from the OEM server 6 or user input (information acquired in S72 of FIG. 7). Also, the charging control device 10 may acquire information on the valid period of the contract from the OEM server 6 or user input and store it in the memory 12. Then, the charging control device 10 may acquire the current time from the OS clock, the external communication unit 16A, etc., and determine whether the current time is within the valid period of the contract. The process in which the charging control device 10 acquires the current time and determines whether the current time is within the valid period of the contract can be regarded as an example of the process of managing whether the certificate is valid.

[0067] Therefore, the charging control device 10 notifies the user of an error (S108). Here, the notification is, for example, a display on the display unit 14 or the like. The display content is, for example, a message including the cause of the error. The cause of the error is that the contract presence / absence information is "no contract", the current time is not within the valid period of the contract, etc. Then, the charging control device 10 prompts the user to perform charging by EIM (S109). After the processes of S109 and S104, the charging control device 10 ends the process.

[0068] (Effect of the Embodiment) As described above, the charging control device 10 of the present embodiment (and the program executed by the CPU 11 of the charging control device 10) acquires contract presence / absence information indicating whether there is a contract to receive charging for the vehicle 1 using the Contract certificate. Then, when charging is performed at the charging facility 2, if contract presence / absence information indicating that there is a contract is acquired (for example, YES in the determination of S105), charging using the certificate is performed (for example, the processes of S106, S 107, S104). Also, when contract presence / absence information indicating that there is a contract is not acquired (for example, NO in the determination of S105), the charging control device 10 etc. performs charging without using the Contract certificate (the process of S109). Therefore, it is possible to prevent the user of the vehicle 1 from mistakenly attempting to perform PnC charging when they misunderstand that they have a contract for charging at the charging facility 2 when they actually do not. Also, even if there is a contract, it is possible to prevent the charging sequence from being interrupted during charging when the user of the vehicle 1 mistakenly attempts to perform PnC charging when the current time is not within the valid period. Further, the charging control device 10 etc. can reduce the risk of charging stop due to the Contract certificate not being found.

[0069] Also, when contract presence / absence information indicating that there is a contract to receive charging using the Contract certificate is acquired and a valid Contract certificate is stored in the memory 12, the charging control device 10 etc. performs PnC charging. On the other hand, when contract presence / absence information indicating that there is such a contract is acquired and a valid Contract certificate is not stored in the memory 12, the charging control device 10 etc. obtains the Contract certificate etc. via the charging facility 2. Therefore, the charging control device 10 etc. can stably execute the sequence of PnC charging and obtaining the Contract certificate etc. for PnC charging at the charging facility 2. That is, the charging control device 10 can execute the control when receiving charging while avoiding a situation where the charging sequence is interrupted at the charging facility 2 due to user misrecognition etc.

[0070] In addition, before connecting to the charging facility 2, the charging control device 10 etc. obtains contract existence information indicating whether there is a contract for receiving charging using the Contract certificate from the OEM server 6 and stores it in the memory 12. Then, when connecting to the charging facility 2, the charging control device 10 etc. obtains contract existence information indicating whether there is a contract for receiving charging using the Contract certificate from the memory 12. Therefore, when connecting to the charging facility 2, the charging control device 10 etc. can quickly determine whether there is a contract for receiving charging using the Contract certificate.

[0071] In addition, the charging control device 10 etc. may obtain contract existence information indicating whether there is a contract for receiving charging using the Contract certificate according to the user's input via a user interface (display unit 14, operation unit 15, etc.) available to the user using the charging facility 2. By doing so, the charging control device 10 etc. can obtain contract existence information from the user in a simple procedure.

[0072] In addition, when the contract is cancelled or when the Contract certificate becomes invalid due to the expiration of the validity period, the charging control device 10 etc. can obtain invalidation information indicating invalidation from the operation of the OEM server 6 or the user. Then, the charging control device 10 etc. deletes the Contract certificate from the memory 12 and changes the contract existence information to indicate that there is no contract. Therefore, the charging control device 10 etc. can manage the latest contract status in cooperation with the OEM server 6 and store the contract existence information reflecting the latest contract status.

[0073] The charging control device 10 etc. may store deadline information regarding the validity period of the Contract certificate in the memory 12 and manage whether the Contract certificate has become invalid due to the expiration of the validity period. Therefore, the charging control device 10 etc. can automatically determine whether the Contract certificate has become invalid due to the expiration of the validity period without accessing the network N1 etc. or the intervention of the user.

[0074] (Modification example) In the above embodiment, before the charging control device 10 or the like is connected to the charging facility 2 of the vehicle 1, it acquires contract presence / absence information indicating whether there is a contract for receiving charging using a Contract certificate (see S4 and S5 in FIG. 3). However, the charging control device 10 or the like may acquire the contract presence / absence information when the vehicle 1 is connected to the charging facility 2, that is, at the time of connection.

[0075] FIG. 9 is a diagram illustrating a process in which the charging control device 10 or the like acquires contract presence / absence information when the vehicle 1 is connected to the charging facility 2. In FIG. 9, since the processes other than S4A and S4B are the same as those in FIG. 3, the description thereof is omitted.

[0076] In FIG. 9, when the plug 2B of the charging facility 2 is attached to the connection portion including the power receiving portion and the communication terminal of the vehicle 1, the charging control device 10 or the like requests the OEM server 6 for contract presence / absence information via the network N1 (S4A). In response to this, the OEM server 6 responds to the vehicle 1 with the contract presence / absence information based on the current contract status (S4B). Note that the example in FIG. 9 illustrates the case of "contract exists".

[0077] That is, the charging control device 10 or the like acquires contract presence / absence information indicating that there is a contract for receiving charging using a Contract certificate from the OEM server 6 after being connected to the charging facility 2. By such a process, the charging control device 10 or the like can acquire the current contract status from the OEM server 6 without omission. Further, the charging control device 10 or the like does not need to store the contract presence / absence information in the memory 12, and the process becomes simple. Note that in S4B, when the contract presence / absence information indicating that there is a contract for receiving charging using a Contract certificate cannot be acquired, the charging control device 10 does not execute the processes from S7 to S13 and prompts the user to charge by the EIM.

[0078] (Computer-readable recording medium) A program for causing a computer or other machine or device (hereinafter referred to as a computer or the like) to realize any of the above functions can be recorded on a computer-readable recording medium. Then, by causing the computer or the like to read and execute the program on this recording medium, the function can be provided.

[0079] Here, a computer-readable recording medium refers to a recording medium that accumulates information such as data and programs by an electrical, magnetic, optical, mechanical, or chemical action and can be read by a computer or the like. Among such recording media, removable ones from a computer or the like include, for example, flexible disks, magneto-optical disks, CD-ROMs, CD-R / Ws, DVDs, Blu-ray disks, memory cards such as flash memories, etc. Also, recording media fixed to a computer or the like include hard disks, ROMs (read-only memories), etc. Furthermore, an SSD (Solid State Drive) can be used as both a removable recording medium from a computer or the like and a recording medium fixed to a computer or the like. A computer-readable recording medium can be used as both a removable recording medium from a computer or the like and a recording medium fixed to a computer or the like.

[0080] (Others) Furthermore, the present embodiment includes the following embodiments (hereinafter referred to as supplementary notes). [Supplementary Note 1] A charging control device having a controller that performs charging control for receiving charging from a charging facility using a certificate, wherein the controller, acquires contract information indicating whether there is a contract for receiving charging using the certificate, and when performing the charging control, if the contract information indicating that there is a contract is acquired, performs charging using the certificate, and if the contract information indicating that there is a contract is not acquired, performs charging without using the certificate. [Supplementary Note 2] The controller, When the contract information indicating the existence of the contract is acquired and a valid certificate is stored, charging is performed based on the certificate. When the contract information indicating the existence of the contract is acquired but a valid certificate is not stored, the charging facility is a charging control device according to Supplementary Note 1 that obtains the certificate via the charging facility and performs charging based on the certificate. [Supplementary Note 3] The charging control device is mounted on an electric vehicle, The controller acquires, from a computer of an operator related to the manufacture or sale of the electric vehicle before connecting to the charging facility, the contract information indicating whether there is a contract for receiving the charging, stores it in a memory, and acquires, from the memory when connecting to the charging facility, the contract information indicating whether there is a contract for receiving the charging. The charging control device according to Supplementary Note 1 or 2. [Supplementary Note 4] The charging control device is mounted on an electric vehicle, The controller acquires, from a computer of an operator related to the manufacture or sale of the electric vehicle after connecting to the charging facility, the contract information indicating whether there is a contract for receiving the charging. The charging control device according to Supplementary Note 1 or 2. [Supplementary Note 5] The controller acquires, via a user interface available to a user using the charging facility, the contract information indicating whether there is a contract for receiving the charging. The charging control device according to any one of Supplementary Notes 1 to 4. [Supplementary Note 6] When the controller acquires invalidation information indicating invalidation of the contract information from a computer of an operator related to the manufacture or sale of the electric vehicle when the contract is canceled or when the certificate becomes invalid due to expiration of the validity period, the controller deletes the certificate from the memory and changes the contract information to indicate that there is no contract. The charging control device according to Supplementary Note 3 or 4. [Supplementary Note 7] The controller stores information regarding the validity period of the certificate in a memory and manages whether the certificate is valid. The charging control device according to any one of Supplementary Notes 1 to 6. [Appendix 8] A program for causing a computer that performs charging control to receive charging from a charging facility using a certificate to acquire contract information on whether there is a contract to receive charging using the certificate, and when performing the charging control, if the contract information indicating that there is the contract is acquired, perform charging using the certificate, and if the contract information indicating that there is the contract is not acquired, perform charging without using the certificate.

Explanation of Signs

[0081] 1 Vehicle 2 Charging Facility 5 MO Server 6 OEM Server 10 Charging Control Device 11, 21 CPU 12, 22 Memory 13, 23 External Storage Unit 14 Display Unit 15 Operation Unit 16A, 26A External Communication Unit 16B, 26B Charging Communication Unit 19 Battery 29 Power Supply Circuit 2A EIM Reader 2B Plug

Claims

1. A charging control device having a controller that performs charging control to receive charging from a charging facility using a certificate, wherein the controller, obtains contract information as to whether there is a contract to receive charging using the certificate, and when performing the charging control, if the contract information indicating that there is the contract is obtained, performs charging using the certificate, and if the contract information indicating that there is the contract is not obtained, performs charging without using the certificate.

2. wherein the controller, when the contract information indicating that there is the contract is obtained and a valid certificate is stored, performs charging based on the certificate, and when the contract information indicating that there is the contract is obtained and a valid certificate is not stored, obtains the certificate via the charging facility and performs charging based on the certificate. The charging control device according to claim 1.

3. The charging control device is mounted on an electric vehicle, wherein the controller obtains, from a computer of an operator related to the manufacture or sale of the electric vehicle, the contract information as to whether there is a contract to receive the charging before connecting to the charging facility, stores it in a memory, and obtains, from the memory when connecting to the charging facility, the contract information as to whether there is a contract to receive the charging. The charging control device according to claim 1.

4. The charging control device is mounted on an electric vehicle, wherein the controller obtains, from a computer of an operator related to the manufacture or sale of the electric vehicle, the contract information as to whether there is a contract to receive the charging after connecting to the charging facility. The charging control device according to claim 1.

5. wherein the controller obtains the contract information as to whether there is a contract to receive the charging via a user interface available to a user who uses the charging facility. The charging control device according to claim 1.

6. wherein when the contract is cancelled or the certificate becomes invalid due to the expiration of the validity period, if the controller obtains invalidation information indicating invalidation of the contract information from a computer of the operator related to the manufacture or sale of the electric vehicle, deletes the certificate from the memory and changes the contract information to indicate that there is no contract. The charging control device according to claim 3.

7. The charging control device according to claim 1, wherein the controller stores information regarding the expiration date of the certificate in a memory and manages whether the certificate is valid or not.

8. In a computer that performs charging control to receive charging from a charging facility using a certificate, acquire contract information as to whether there is a contract to receive charging using the certificate, When performing the charging control, if the contract information indicating that there is the contract has been acquired, perform charging using the certificate, and if the contract information indicating that there is the contract has not been acquired, execute performing charging without using the certificate. A program for that.

Images