Management method and management system for power storage device, and computer device

Abstract

To accurately notify an owner of a power storage device provided with a vehicle of generation of an accident, at occurrence of a vehicle accident.SOLUTION: A management method of a power storage device includes: acquiring first owner information indicating an owner of a power storage device, from a data management device which manages information about a plurality of vehicles including the vehicle, when information indicating that an accident about the vehicle provided with the power storage device has occurred is acquired (S21); identifying the owner of the power storage device, by using the acquired first owner information (S22); and making notification which notifies a terminal of the identified owner of the power storage device, of accident occurrence of the vehicle provided with the power storage device (S23).SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present disclosure relates to a management method and management system for a power storage device, and a computer device. [Background technology]

[0002] Japanese Patent Publication No. 2022-064527 (Patent Document 1) discloses a technology in which, when an impact detection sensor that detects the magnitude of an impact applied to a vehicle detects an impact of a predetermined value or greater, an electronic control unit that uses an auxiliary battery as its driving power source controls the voltage of only pre-selected battery cells in a battery module to be low. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-064527 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, countries around the world have been moving toward electrification of vehicles, and technologies in the four fields known as "CASE" (connected, automated, sharing, and electrified) have been attracting particular attention. Vehicle leasing services (including vehicle sharing services) that rent vehicles to users are one example of such technologies. However, Patent Document 1 does not fully consider the possibility of an accident occurring in a rented vehicle or in a vehicle equipped with a rented power storage device. In more detail, while the technology described in Patent Document 1 allows the user of the vehicle to know when an accident has occurred, it is difficult for the owner of the power storage device to know when the power storage device has been rented.

[0005] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to accurately notify the owner of a power storage device provided in a vehicle of the occurrence of a vehicle accident when the accident occurs. [Means for solving the problem]

[0006] According to an embodiment of a first aspect of the present disclosure, there is provided a method for managing a power storage device as follows. (Article 1) The method for managing the storage device includes, when information indicating that an accident has occurred in a vehicle equipped with a storage device (hereinafter also referred to as a "target vehicle"), acquiring first owner information indicating the owner of the storage device of the target vehicle from a data management device that manages information regarding a plurality of vehicles including the target vehicle, using the acquired first owner information to identify the owner of the storage device of the target vehicle, and sending a notification to a terminal of the identified owner of the storage device informing them of the occurrence of an accident in the target vehicle equipped with the storage device.

[0007] In the above management method, when an accident occurs in a target vehicle, the owner of the power storage device equipped in the target vehicle is identified. Then, a notification of the occurrence of an accident in the target vehicle equipped with the power storage device is sent to a terminal of the owner of the power storage device. This makes it possible to accurately notify the owner of the power storage device equipped in the target vehicle of the occurrence of an accident in the event of a vehicle accident.

[0008] The target vehicle may be an xEV (exhausted electric vehicle) that uses electricity as all or part of its power source. Examples of xEV include BEV (electric vehicle), HEV (hybrid vehicle), PHEV (plug-in hybrid vehicle), and FCEV (fuel cell vehicle).

[0009] The method described in the above item 1 may have the configuration described in the following item 2. (Item 2) The method for managing an electric storage device according to item 1 further has the following feature: The data management device manages information indicating the owner of each of the on-board electric storage device and the vehicle body part for each of a plurality of vehicles. When information indicating that an accident has occurred between a target vehicle and another vehicle is acquired, the management method includes acquiring, from the data management device, first owner information indicating the owner of the electric storage device of the target vehicle and second owner information indicating the owner of the vehicle body part of the other vehicle, identifying the user of the other vehicle using the acquired second owner information, and sending a notification to a terminal of the user of the identified other vehicle informing the owner of the electric storage device of the target vehicle.

[0010] According to the above method, the owner of the power storage device of the target vehicle can be notified to the other party involved in the accident (the user of the other vehicle). Therefore, if the power storage device of the target vehicle is damaged in an accident, it becomes easier to negotiate compensation for damages between the other party involved in the accident and the owner of the power storage device of the target vehicle.

[0011] A vehicle user may be provided with a vehicle in one of the following three usage patterns (partial lease / full lease / full ownership). Partial lease is a usage pattern in which the vehicle body (excluding the power storage device) is owned by the user, and the power storage device is provided to the user by leasing. Full lease is a usage pattern in which both the vehicle body and the power storage device are provided to the user by leasing. Full ownership is a usage pattern in which both the vehicle body and the power storage device are owned by the user.

[0012] If the other vehicle is partially leased or wholly owned, the user of the other vehicle can be identified directly from the second owner information. If the other vehicle is wholly leased, the user of the other vehicle can be identified, for example, by inquiring with the leasing company (the owner of the body part of the other vehicle) using the second owner information.

[0013] According to one aspect, there is provided a program for causing a computer to execute the power storage device management method according to aspect 1 or 2. In another aspect, there is provided a computer device for distributing the program.

[0014] According to an embodiment of a second aspect of the present disclosure, there is provided a computer device as follows. (Item 3) The computer device includes a processor and a storage device that stores a program that causes the processor to execute the method for managing a power storage device according to item 1 or 2.

[0015] The above-described computer device can suitably execute the above-described method for managing the power storage device. According to an embodiment of a third aspect of the present disclosure, there is provided a management system for a power storage device as described below.

[0016] (Item 4) The management system for the power storage device includes the computer device and a data management device described in item 3. The data management device includes a storage device that stores a distributed ledger, and a control device that registers transaction data including information indicating the owner of the on-board power storage device for each of a plurality of vehicles in the distributed ledger.

[0017] The above system uses distributed ledger technology (DLT) to manage data, thereby preventing data tampering. Currently, vehicle certification information (such as vehicle inspection and registration information) provided by national authorities does not include information indicating the owner of the onboard energy storage device. The above system enables secure data management, making it possible to provide computer devices with highly reliable owner information equivalent to the information provided by the authorities. Such owner information can satisfy third-party assertion requirements. The control device may register only electronically certified information in the distributed ledger.

[0018] The power storage device management system described in the above item 4 may have the configuration described in item 5 or 6 below.

[0019] (Item 5) The management system described in item 4 further has the following features. The computer device is a first server that provides an insurance service related to damage to a vehicle's power storage device. A vehicle in which an accident has occurred is configured to transmit an accident occurrence signal notifying the occurrence of the accident, damage information indicating the degree of damage to the power storage device, and accident data indicating the status of the vehicle at the time the accident occurred. When the accident occurrence signal is received, the first server is configured to determine the degree of fault of the vehicle user in relation to the accident based on the accident data, and to determine the insurance money to be paid by the insurance service based on the damage information and the degree of fault.

[0020] According to the above system, insurance money can be more easily determined appropriately based on the degree of damage to the power storage device and the degree of negligence of the vehicle user in relation to the accident. Also, the vehicle user can more easily receive insurance services.

[0021] The first server may transmit the determined insurance amount to at least one of a second server (described later) and a user terminal of the vehicle where the accident occurred. The user terminal may be an in-vehicle terminal mounted on the vehicle, or a mobile terminal carried by the vehicle user. The user terminal may be linked to the vehicle in advance and registered in at least one of the first server and the second server.

[0022] (Item 6) The management system according to item 4 or 5 further has the following features. The management system further includes a plurality of exchange stations that exchange electric storage devices for vehicles. The terminal of the owner of the electric storage device is a second server that provides a leasing service for lending electric storage devices for vehicles. The second server is configured to permit one or more exchange stations to exchange the electric storage device when it receives a notification that a vehicle accident has occurred.

[0023] According to the above system, when an accident occurs with a target vehicle, the power storage device mounted on the target vehicle can be easily replaced at an exchange station. [Effects of the Invention]

[0024] According to the present disclosure, when a vehicle accident occurs, it is possible to accurately notify the owner of the power storage device provided in the vehicle of the occurrence of the accident. [Brief explanation of the drawings]

[0025] [Figure 1] 1 is a diagram illustrating an overview of a management system for a power storage device according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram illustrating the configuration of the data management device shown in FIG. [Figure 3] FIG. 1 is a diagram illustrating an example of DAG (Directed Acyclic Graph) data. [Figure 4] FIG. 1 is a diagram illustrating an example of blockchain data. [Figure 5] FIG. 2 is a diagram for explaining the configuration of the vehicle shown in FIG. [Figure 6] 10 is a flowchart illustrating control when an accident occurs in a method for managing a power storage device according to an embodiment of the present disclosure. [Figure 7] 10 is a flowchart showing a process related to the provision of insurance services in a management method according to an embodiment of the present disclosure. [Figure 8] 10 is a flowchart showing control relating to battery replacement executed by a server of a leasing company in a method for managing a power storage device according to an embodiment of the present disclosure. [Figure 9] 10 is a flowchart showing control relating to battery exchange executed by a target vehicle and an exchange station terminal in a method for managing an electricity storage device according to an embodiment of the present disclosure. [Figure 10] 1A and 1B are diagrams illustrating the configuration and operation of an exchange station according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0026] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure will be described in detail with reference to the accompanying drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals and their description will not be repeated.

[0027] 1 is a diagram for explaining an overview of a management system for a power storage device according to this embodiment. The management system shown in Fig. 1 includes a dealer 100, a battery exchange station (hereinafter referred to as "BSta") 200, a management center 500, and an insurance server 600.

[0028] The management center 500 includes a plurality of nodes 510 and a server 520. In this embodiment, a node 510 is installed in each of the dealer 100 and the BSta 200. Hereinafter, the node 510 installed in the dealer 100 will be referred to as "node 510A," and the node 510 installed in the BSta 200 will be referred to as "node 510B." However, when there is no need to distinguish between them, they will be collectively referred to as "node 510." Both nodes 510A and 510B have the configuration shown in FIG. 2, which will be described later. However, nodes 510A and 510B may be customized separately according to the installation location (dealer 100, BSta 200) and purpose.

[0029] Server 520 is a server that provides a leasing service for renting out power storage devices for vehicles (e.g., for xEVs). Server 520 manages information related to the leasing service. Server 520 belongs to, for example, an automobile manufacturer. In this embodiment, the automobile manufacturer also serves as the leasing business operator. Insurance server 600 is a server that provides an insurance service for damage to power storage devices for vehicles (e.g., for xEVs). This insurance service is a service that compensates for damage to power storage devices mounted on vehicles. Insurance server 600 manages information related to the insurance service. Insurance server 600 belongs to, for example, an insurance provider. Insurance server 600 cooperates with server 520 to provide an insurance service for damage to power storage devices rented out through the leasing service. Insurance server 600 and server 520 respectively correspond to examples of a "first server" and a "second server" according to the present disclosure.

[0030] The above leasing service employs several types of leasing methods, including partial leasing and full leasing. The partial leasing method is a leasing method in which only the power storage device for a vehicle is rented out. A user who rents out a power storage device under the partial leasing method provides the rest of the vehicle (the body portion) excluding the power storage device. The user can install the power storage device rented from the leasing company in a vehicle body that the user owns. An xEV becomes capable of running when the power storage device is installed in the body. When the partial leasing contract expires, the user returns only the power storage device to the leasing company. On the other hand, the full leasing method is a leasing method in which the entire vehicle (i.e., both the body portion and the power storage device) is rented out. When the full leasing contract expires, the user returns not only the power storage device but also the entire vehicle to the leasing company.

[0031] Automobile manufacturers sell or lease vehicles through dealer 100. Dealer 100 not only sells vehicles manufactured by the automobile manufacturer but also provides the leasing service described above. Dealer 100 rents out at least one of a vehicle body and a power storage device provided by the automobile manufacturer. Dealer 100 may, for example, rent out power storage device 12A of vehicle 10A shown in FIG. 1 to a user by a partial leasing system. In this case, vehicle 10A corresponds to a partially leased vehicle (hereinafter may be referred to as "vehicle A"), and vehicle body 11A of vehicle 10A becomes the property of the user. Power storage device 12A of vehicle 10A is provided to the user by lease and becomes the property of the automobile manufacturer. Dealer 100 may also rent out vehicle 10B shown in FIG. 1 to a user by a full leasing system. In this case, vehicle 10B corresponds to a fully leased vehicle (hereinafter may be referred to as "vehicle B"). Then, the entire vehicle 10B (vehicle body 11B and power storage device 12B) is provided to the user by lease and becomes the property of the automobile manufacturer. Alternatively, dealer 100 may sell, for example, vehicle 10C shown in FIG. 1 to the user. In this case, vehicle 10C corresponds to the vehicle for sale (hereinafter, may be referred to as "vehicle C"). Then, the entire vehicle 10C (vehicle body 11C and power storage device 12C) is sold to the user and becomes the property of the user.

[0032] In this embodiment, the insurance premium is included in the lease fee (for example, monthly lease fee) charged to the vehicle user by the dealer 100. That is, vehicles A and B are subscribed to insurance provided by the insurance server 600 (more specifically, insurance for damage to the power storage device). For each of vehicles A and B, insurance is applied when the power storage device mounted on the vehicle is damaged. Compensation for damage to the power storage device is provided by the insurance service. As will be described in detail later, the insurance server 600 determines the insurance amount to be paid by the insurance service and notifies the server 520 of the determined insurance amount. The determined insurance amount is paid by the insurance company to the leasing company. Then, if the amount of loss due to the damage to the power storage device is greater than the insurance amount, the leasing company bills the vehicle user for the difference. Since the above insurance is for leasing, vehicle C is not subscribed to the above insurance. However, vehicle C may subscribe to a different insurance.

[0033] The BSta200 is configured to exchange power storage devices for vehicles (for example, for xEVs). The node 510B of the BSta200 is connected to the communication network NW, for example, by wire. In this embodiment, a battery (more specifically, a secondary battery) is used as the power storage device. However, the power storage device may be any device that can store electric power, and examples of the power storage device include a secondary battery and a large-capacity capacitor.

[0034] The power storage device management system according to this embodiment includes a plurality of dealers 100. These dealers 100 are installed at respective bases within the jurisdiction of the management system so as to build a network of sales / lease bases covering the entire jurisdiction of the management system. Furthermore, the management system includes a plurality of BSta 200. These BSta 200 are installed at respective bases within the jurisdiction of the management system so as to build a network of battery exchange bases covering the entire jurisdiction of the management system. Furthermore, each BSta 200 may function as a vehicle repair shop. Each BSta 200 may be configured to repair vehicle bodies. The dealer 100 and the BSta 200 may be installed in the same location (or nearby).

[0035] The insurance server 600 includes a processor 610, a storage device 620, and a communication module 630. The processor 610 includes, for example, a CPU (Central Processing Unit). The storage device 620 is configured to be able to save stored information. The storage device 620 may include an HD (Hard Disk) drive or an SSD (Solid State Drive). The communication module 630 is connected to the communication network NW, for example, by wire. Each node 510, the server 520, and the insurance server 600 are configured to be able to communicate with each other via the communication network NW. The communication network NW is, for example, a wide area network constructed by the Internet and wireless base stations. The communication network NW may also include a mobile phone network.

[0036] The management center 500 is a data management device that uses distributed ledger technology to manage information about multiple vehicles. The distributed ledger records all information from the start of operation of the distributed ledger to the present. Figure 2 is a diagram illustrating the configuration of the management center 500.

[0037] 2, the management center 500 includes a plurality of nodes 510 that form a distributed ledger network (hereinafter referred to as "DLN"), and a server 520 that can communicate with each of the nodes 510. Each of the nodes 510 is configured to be able to communicate with the certificate authority 800. The server 520 includes a processor 521, a storage device 522, and a communication module 523. Although four nodes 510 are shown in FIG. 2, the number of nodes 510 can be changed as appropriate.

[0038] The node 510 according to this embodiment is a stationary computer (e.g., a server). The node 510 includes a control device 511, a storage device 512, a communication device 515, an input device 516, and a display device 517, which are connected to a bus 518.

[0039] The control device 511 includes, for example, a processor, a ROM (Read Only Memory), and a RAM (Random Access Memory), all of which are not shown, and is configured to be capable of processing information. The storage device 512 includes, for example, a hard disk or flash memory, and is configured to be capable of storing information. The storage device 512 stores programs executed by the processor of the control device 511 as well as information used by the programs. The communication device 515 is connected to the communication network NW (FIG. 1). The control device 511 exchanges information with external devices through the communication device 515. The communication device 515 is configured to be able to communicate with each of the other nodes 510, the server 520, and the certification authority 800. The input device 516 transmits information (e.g., instructions or parameter values) input by a user to the control device 511. The display device 517 displays information to the user in accordance with control commands from the control device 511.

[0040] The storage device 512 further stores a pair of private and public keys generated by the control device 511, and a digital certificate issued by the certification authority 800. Specifically, the control device 511 generates a private key and a public key paired with the private key, and transmits the generated public key to the certification authority 800. The certification authority 800 includes a server belonging to the certification body. The certification authority 800 generates a digital certificate for the public key received from the node 510 (the applicant for the digital certificate), and issues the digital certificate including the public key to the node 510. The node 510 transmits the issued digital certificate to the DLN. The digital certificate is used to verify the validity of the digital signature, which will be described later.

[0041] The data management by the management center 500 may employ a distributed ledger technology using a directed acyclic graph (DAG). In this configuration, the storage device 522 of the server 520 and the storage device 512 of each node 510 store the DAG data described below. Figure 3 is a diagram showing an example of DAG data.

[0042] As shown in Figure 3, DAG data is structured by connecting one transaction data in multiple directions without cyclical circulation. The storage device 512 of each node 510 that forms the DLN stores the DAG data. This prevents data tampering. Even if a user tampers with the DAG data, the tampering can be detected immediately based on the DAG data held by multiple other users.

[0043] In the example shown in Figure 3, each transaction data is connected to transaction data corresponding to two transactions that occurred earlier. That is, each transaction data includes a hash value of data related to past transactions. Below, transaction data TD11 to TD16 in Figure 3 will be simply referred to as "TD11" to "TD16," respectively. In the DAG data shown in Figure 3, the transaction corresponding to TD13 is newer than the transactions corresponding to TD11 and TD12, and the transactions corresponding to TD14 to TD16 are newer than the transaction corresponding to TD13. Below, we will explain the procedure for adding new information (for example, owner information, which will be described later) to DAG data.

[0044] 2 and 3, first, a user of node 510 operates input device 516 to store data relating to newly added information (hereinafter referred to as "target data") in storage device 522 of server 520. In response to this process (transaction relating to data addition), node 510 generates TD13 corresponding to this process (transaction). Control device 511 may generate TD13 including target data with a digital signature, for example, by the following method.

[0045] The control device 511 acquires target data from the server 520 and hashes the target data using a hash function. The control device 511 then reads a private key from the storage device 512 and generates a digital signature using the private key. The control device 511 then encrypts the hashed target data using the private key to generate a TD13 containing the digitally signed target data. The target data indicating the contract details may be affixed with digital signatures of multiple parties entering into the contract. Another node 510 in the DLN may decrypt the encrypted digital signature using a public key (more specifically, a public key paired with the private key) included in the digital certificate and verify the validity of the digital signature based on the decryption results. However, digitally signing the target data is not essential when generating transaction data containing the target data.

[0046] When generating TD13, node 510 selects, for example, TD11 and TD12 from past transaction data and verifies the contents of the selected TD11 and TD12. The selection method may be a method of randomly selecting from past transaction data, or a selection method using a selection algorithm such as the Markov Chain Monte Carlo method. The verification method may be a verification method using a digital signature included in the transaction data or other known verification methods. Node 510 may retroactively verify transaction data that TD11 and TD12 have directly or indirectly approved.

[0047] If the verification results in no fraudulent transaction data, the node 510 hashes the verified TD11 and TD12 and includes these hash values ​​in TD13. The inclusion of these hash values ​​in TD13 means that the node 510 approved TD11 and TD12 when generating TD13. The generated TD13 also includes a hash value of the target data (data related to new information). This hash value is a numerical value obtained as a result of the node 510 hashing the target data (e.g., document data) using a hash function.

[0048] Next, the node 510 sends the generated, verified, and approved TD13 to the DLN, which adds the TD13 to the DAG data. The updated portion of the DAG data is written to a distributed ledger (e.g., a consortium distributed ledger) by each node 510 in the DLN, which registers the new transaction data in the distributed ledger.

[0049] The node 510 may obtain a timestamp token for the generated TD13 (including the target data) from the certificate authority 800. In response to a request from the node 510, the certificate authority 800 may issue a timestamp token that combines time information based on a time source that is traceable to international standard time. The control device 511 may hash the timestamp token using a hash function and register the hashed timestamp token in the distributed ledger (e.g., DAG data). This timestamp token can prove that the target data existed in the distributed ledger at that time.

[0050] TD13 added to the DAG data is later verified and approved by another node 510 as described above. In the example shown in FIG. 3, TD13 is approved by both TD14 and TD16. A cumulative weight may be assigned to each transaction data in the DAG data. The cumulative weight indicates the probability that the transaction data is valid. The cumulative weight may indicate, for example, the number of other transaction data that approve the transaction data.

[0051] Data management by the management center 500 may employ a distributed ledger technology using a blockchain (hereinafter referred to as "BLC"). In this configuration, the storage device 522 of the server 520 and the storage device 512 of each node 510 store the BLC data described below. Figure 4 is a diagram showing an example of BLC data.

[0052] As shown in Figure 4, BLC data is made up of multiple blocks connected together. In Figure 4, blocks BD11 to BD13 are newer as you move to the right. If you arrange these in order from oldest to newest, they become blocks BD11, BD12, and BD13. BLC data indicates a transaction history. The storage device 512 of each node 510 that forms the DLN stores the BLC data. This prevents data tampering. Below, we will explain the procedure for adding new information to BLC data.

[0053] 2 and 4, first, a user of node 510 operates input device 516 to store target data (data related to new information) in storage device 522 of server 520. In response to this process (transaction related to data addition), node 510 generates transaction data corresponding to this process (transaction). Specifically, node 510 hashes the target data using a hash function, and generates transaction data including a numerical value (hash value) obtained as a result of the hashing. Control device 511 may generate transaction data including target data with a digital signature using the procedure described above.

[0054] The node 510 transmits the transaction data generated as described above to the DLN. This transaction data is unauthenticated and is aggregated into a new block BD13. The transaction data is not recognized as valid just because it is sent to the DLN. The transaction data becomes valid only after it is added to the distributed ledger (BLC data) held by each node 510 in the DLN.

[0055] When certain requirements are met, a new block BD13 is added to the existing blocks BD11 and BD12. For example, a mining process called POW (Proof of Work) adds the new block BD13 to the BLC data. This registers new transaction data in the distributed ledger. POW is a mechanism in which multiple nodes compete to add the new block BD13. Nodes that participate in POW are generally called miners. The miner who generates the new block BD13 the fastest is awarded a reward. A consensus algorithm using this mechanism ensures the tamper-resistance of the BLC data.

[0056] As described above, each node 510 included in the management center 500 includes a storage device 512 that stores a distributed ledger using, for example, a DAG or BLC, and a control device 511 that registers transaction data in the distributed ledger. The management center 500 stores information (transaction data) about multiple vehicles sold or leased by dealers 100 at each base, distinguishing them by vehicle identification information (vehicle ID). The vehicle ID may be a VIN (Vehicle Identification Number).

[0057] In this embodiment, when a dealer 100 sells or leases a vehicle, the node 510A of the dealer 100 writes the transaction data described above to the distributed ledger. As a result, the owner information and insurance information according to the sales contract or lease contract are written to the distributed ledger. In addition, a timestamp token for the transaction data is registered in the distributed ledger.

[0058] The transaction data includes a vehicle ID, specification information, owner information, insurance information, a hash value of the target data, time information, registrant information, a hash value of past transaction data, and an electronic signature. The specification information indicates the specifications of each of the vehicle body parts and the power storage device for the vehicle identified by the vehicle ID. The owner information indicates the owner of the power storage device installed in the vehicle and the owner of the vehicle body parts for the vehicle identified by the vehicle ID. The insurance information indicates the insurance subscribed to by the vehicle and the insurance provider. The insurance information for each of vehicles A and B indicates the communication address of the insurance server 600 as the contact information for the insurance provider with which the vehicle user has signed a contract. The electronic signature includes, for example, the electronic signatures of the vehicle user, the leasing company, and the insurance provider. The vehicle ID, specification information, owner information, and insurance information for the sold or leased vehicle are also written to the storage device of the vehicle (for example, storage device 111b shown in FIG. 5, which will be described later).

[0059] The owner information includes identification information and contact information of the owner. The owner identification information includes information for identifying the owner (for example, name, corporate name, identification number, identification symbol, etc.). The owner contact information includes information for contacting the owner (for example, the communication address of the owner's terminal). Specifically, the owner information for vehicle A (partially leased vehicle) indicates that the owner of the vehicle body part is the vehicle user (contact information is provided on mobile terminal 20 shown in FIG. 5 described below) and that the owner of the power storage device is the leasing company (contact information is provided on server 520). The owner information for vehicle B (fully leased vehicle) indicates that the owner of each of the vehicle body part and the power storage device is the leasing company (contact information is provided on server 520). The owner information for vehicle C (vehicle for sale) indicates that the owner of each of the vehicle body part and the power storage device is the vehicle user (contact information is provided on mobile terminal 20).

[0060] An owner (e.g., a leasing company) of a power storage device mounted on a vehicle can prove his / her ownership to a third party, for example, by using an ownership certificate. The owner can create an ownership certificate to which an electronic certificate issued by the certificate authority 800 is attached using one node 510. The ownership certificate includes, for example, a vehicle ID, owner information (transaction data) linked to the vehicle ID, an electronic signature, and time information (a timestamp token). The owner information included in the ownership certificate may indicate, for a vehicle identified by the vehicle ID, the owner of the power storage device mounted on the vehicle and the owner of the vehicle body. The node 510 that created the ownership certificate transmits the ownership certificate to the DLN. Each node 510 in the DLN can confirm the owner of a power storage device mounted on a certain vehicle by obtaining from the DLN an ownership certificate corresponding to the vehicle's identification information (vehicle ID). Furthermore, each node 510 can verify the validity of the ownership certificate using the electronic certificate (including a public key) attached to the ownership certificate. Furthermore, each node 510 can refer to the distributed ledger to check the history of owner information (transaction data) linked to the vehicle ID. Such owner information can satisfy third-party assertion requirements.

[0061] Hereinafter, the vehicle provided by dealer 100 may be referred to as "vehicle 10." Vehicle 10 according to this embodiment is any one of vehicles A, B, and C shown in FIG. 1. FIG. 5 is a diagram for explaining the configuration of vehicle 10.

[0062] Referring to FIG. 5, vehicle 10 includes a vehicle body 11 and a battery 12 mounted on vehicle body 11. Vehicle 10 is configured to be able to run using the power of battery 12. Vehicle 10 is, for example, a BEV that does not include an internal combustion engine. A known vehicle power storage device (for example, a liquid secondary battery or an all-solid-state secondary battery) can be used as battery 12. Examples of vehicle secondary batteries include lithium-ion batteries and nickel-metal hydride batteries. A plurality of secondary batteries may form a battery pack. Battery 12 corresponds to an example of a "power storage device" according to the present disclosure.

[0063] The vehicle body 11 includes an ECU 111, a battery ECU 112, a BMS (Battery Management System) 112a, a strain sensor 112b, a temperature control system 112c, an inlet 113, a charger 114, an SMR (System Main Relay) 115a, a charging relay 115b, a PCU (Power Control Unit) 116a, an MG (Motor Generator) 116b, an HMI (Human Machine Interface) 117a, a navigation system (hereinafter referred to as "NAVI") 117b, a drive recorder 117c, a position sensor 118a, an impact force sensor 118b, and a communication device 119. Note that ECU stands for Electronic Control Unit. The control system including each ECU mounted on the vehicle body 11 is supplied with power from an auxiliary battery (not shown).

[0064] The ECU 111 is a computer including a processor 111a and a storage device 111b. The storage device 111b stores information used by the programs (for example, maps, mathematical expressions, and various parameters) in addition to the programs executed by the processor 111a. The storage device 111b also stores various types of information related to the vehicle 10. This information is updated according to the status of the vehicle 10. Although the configuration of the battery ECU 112 is not shown in FIG. 5, the battery ECU 112 is also a computer having a hardware configuration similar to that of the ECU 111. The ECU 111 and the battery ECU 112 are configured to be able to communicate with each other. These ECUs are connected by, for example, a CAN (Controller Area Network).

[0065] The BMS (Battery Management System) 112a includes sensors for detecting the state of the battery 12 (for example, temperature, current, and voltage). The strain sensor 112b detects the degree of distortion of the case (battery case) of the battery 12. The greater the impact force applied to the battery 12, the greater the degree of distortion of the battery case. The strain sensor 112b may be a strain gauge or a displacement sensor. The detection results of the BMS 112a and the strain sensor 112b are output to the battery ECU 112.

[0066] The temperature regulation system 112c regulates the temperature of the battery 12. The temperature regulation system 112c may include at least one of a heater and a cooling device. The cooling method may be a water-cooling method. The temperature regulation system 112c is controlled by the battery ECU 112.

[0067] The vehicle 10 is configured to be able to perform external charging (charging the battery 12 with power from outside the vehicle). The inlet 113 is configured to allow a plug (e.g., a connector of a charging cable) of EVSE (Electric Vehicle Supply Equipment) to be attached and detached. The charger 114 includes a power conversion circuit for external charging. The charger 114 may include at least one of a DC / DC conversion circuit and an AC / DC conversion circuit. The charging relay 115b switches between connection and disconnection of a charging line. In the example shown in FIG. 5, a charging line including the inlet 113, the charger 114, and the charging relay 115b is connected between the SMR 115a and the PCU 116a. However, this is not limited thereto, and a charging line may also be connected between the battery 12 and the SMR 115a. The configuration shown in FIG. 5 may also be modified to enable external power supply (power supply from the battery 12 to outside the vehicle). For example, the charger 114 shown in FIG. 5 may be replaced with a charger / discharger.

[0068] The SMR 115a switches between connection and disconnection of an electric path from the battery 12 to the PCU 116a. When the vehicle 10 is running, the SMR 115a is connected and the charging relay 115b is disconnected. When power is exchanged between the battery 12 and the inlet 113, both the SMR 115a and the charging relay 115b are connected. The charger 114, the SMR 115a, and the charging relay 115b are each controlled by the battery ECU 112. The battery ECU 112 receives control commands from the ECU 111.

[0069] The PCU 116a drives the MG 116b using power supplied from the battery 12. The PCU 116a includes, for example, an inverter and a DC / DC converter. The PCU 116a is controlled by the ECU 111. The MG 116b functions as a traction motor for the vehicle 10. The MG 116b is driven by the PCU 116a to rotate the drive wheels of the vehicle 10. The MG 116b also performs regenerative power generation when braking the vehicle 10, and outputs the generated power to the battery 12. The vehicle 10 may be equipped with any number of traction motors.

[0070] The HMI 117a includes an input device and a display device. The HMI 117a may include a touch panel display. The HMI 117a may include a meter panel and / or a head-up display. The HMI 117a may include a smart speaker that accepts voice input.

[0071] The NAVI 117b includes a touch panel display, a GPS (Global Positioning System) sensor, a processor, and a storage device that stores map information. The map information indicates the positions of each dealer 100 and each BSta 200 on a map. The map information may be updated sequentially via OTA (Over The Air). The NAVI 117b detects the position of the vehicle 10 using the GPS sensor and displays the position of the vehicle 10 in real time on a map based on the map information. The NAVI 117b refers to the map information and performs a route search to find an optimal route (e.g., the shortest route) from the current position of the vehicle 10 to the destination.

[0072] The drive recorder 117c includes a camera that captures video of the surroundings of the vehicle 10, a storage device that stores the video captured by the camera, and an acceleration sensor (G sensor) that detects the acceleration of the vehicle 10. The drive recorder 117c constantly records video of the surroundings of the vehicle 10. However, if the amount of information of the video recorded in the storage device exceeds the capacity of the storage device, the newest video is overwritten and the older video is deleted. For this reason, of the video captured by the drive recorder 117c, video that should be stored for a long period of time (for example, accident data, which will be described later) is stored in the ECU 111 (storage device 111b).

[0073] The position sensor 118a detects the position of the vehicle 10. The impact force sensor 118b detects an impact force applied to the vehicle body 11 (for example, a body shell). The impact force sensor 118b may be configured to detect the impact force using at least one of an acceleration sensor, a strain gauge, and a displacement sensor.

[0074] The communication device 119 includes a communication I / F (interface) for accessing the communication network NW via wireless communication. The communication device 119 may include a TCU (Telematics Control Unit) or a DCM (Data Communication Module) for performing wireless communication. The communication device 119 further includes a communication I / F for performing wireless communication with each of the node 510B and the mobile terminal 20. The ECU 111 is configured to communicate with each of the server 520, the node 510B, and the mobile terminal 20 through the communication device 119. The ECU 111 may also communicate with each of the node 510A and the insurance server 600 through the communication device 119.

[0075] The mobile terminal 20 is configured to be portable by the user. The mobile terminal 20 is carried and operated by the user (vehicle manager) of the vehicle 10. In this embodiment, a smartphone equipped with a touch panel display is used as the mobile terminal 20. A smartphone has a built-in computer and a speaker function. However, the mobile terminal 20 is not limited to this, and any terminal that can be carried by the user of the vehicle 10 can be used as the mobile terminal 20. For example, a laptop, a tablet terminal, a portable game console, a wearable device (such as a smart watch, smart glasses, or smart gloves), or an electronic key can also be used as the mobile terminal 20.

[0076] Application software (hereinafter referred to as a "mobile app") for using the services provided by the server 520 is installed on the mobile terminal 20. The mobile app associates the identification information (terminal ID) of the mobile terminal 20 with the identification information (vehicle ID) of the corresponding vehicle 10 and registers the association with the server 520. The mobile terminal 20 can exchange information with the server 520 through the mobile app. The mobile terminal 20 may be configured to be able to communicate with each of the insurance server 600 and the node 510.

[0077] In the vehicle 10, the ECU 111 performs integrated control of the entire vehicle. The ECU 111 acquires detection results from various sensors (including a position sensor 118a and an impact force sensor 118b) mounted on the vehicle 10. The ECU 111 also acquires information from each of the battery ECU 112, the HMI 117a, the NAVI 117b, the drive recorder 117c, and the communication device 119. The battery ECU 112 acquires the state (temperature, current, voltage, etc.) of the battery 12 based on the output of the BMS 112a, and outputs the acquired state of the battery 12 to the ECU 111. The vehicle information acquired by the ECU 111 is stored in the storage device 111b.

[0078] 6 is a flowchart showing control when an accident occurs in the method for managing an electricity storage device according to this embodiment. In the following, each step in the flowchart will be simply represented by "S".

[0079] For example, when the ECU 111 of the vehicle 10 is started, the started ECU 111 starts the process of S11 described below. The ECU 111 is started, for example, in response to the operation of a start switch of the vehicle 10. The start switch is generally called a "power switch" or an "ignition switch." However, the period during which the process of S11 is executed is arbitrary. For example, the ECU 111 may execute the process of S11 only while the vehicle 10 is traveling. In the process shown in FIG. 6, the vehicle 10 executing the process of S11 and subsequent processes is called a "target vehicle."

[0080] 1, 5, and 6, in S11, the ECU 111 of the target vehicle determines whether an accident has occurred for the target vehicle. For example, if the impact force detected by the impact force sensor 118b exceeds a predetermined threshold, the ECU 111 determines that an accident has occurred for the target vehicle. In this case, accident data (e.g., video from the drive recorder 117c) showing the status of the target vehicle before and after the accident is stored in the storage device 111b. On the other hand, if the impact force detected by the impact force sensor 118b is equal to or less than the predetermined threshold, the ECU 111 determines that an accident has not occurred for the target vehicle. If it is determined that an accident has not occurred for the target vehicle (NO in S11), the process does not proceed to S12 or later, and the determination in S11 is repeated. Note that an acceleration sensor of the drive recorder 117c may be used to detect the impact force instead of the impact force sensor 118b.

[0081] If it is determined that an accident has occurred (YES in S11), the ECU 111 of the target vehicle calculates the degree of damage to the battery 12 mounted on the target vehicle in S12. In this embodiment, the ECU 111 calculates the degree of damage to the battery 12 based on at least one of the following: the degree of physical damage to the case of the battery 12 (e.g., the degree of distortion of the battery case detected by the distortion sensor 112b), the communication level related to the system monitoring the battery 12 (e.g., communication instability, communication interruption, etc.), the degree of damage to the electrical components of the battery 12 (e.g., disconnection, bus bar deformation, etc.), and the degree of damage to the environmental system of the battery 12 (e.g., control malfunction, failure, etc.). In this embodiment, the battery ECU 112 and the BMS 112a each function as a system monitoring the battery 12. The temperature adjustment system 112c functions as the environmental system for the battery 12. The ECU 111 may score the degree of damage for each evaluation item related to the degree of damage to the battery 12, and may treat the total score for each evaluation item as the degree of damage (evaluation result) of the battery 12. The evaluation items may be the four items described above (case, communication level, electrical components, and environmental system).

[0082] Any method can be used to calculate the degree of damage to the battery 12, without being limited to the above-described method. For example, the ECU 111 may calculate the degree of damage to the battery 12 caused by the accident based on a change in the characteristics of the battery 12 before and after the accident (for example, the degree of decrease in the capacity maintenance rate or the degree of increase in the internal resistance).

[0083] Next, the ECU 111 of the target vehicle identifies vehicles involved in the accident in S13. Specifically, the ECU 111 determines whether the accident was a single-vehicle accident involving only the target vehicle or an accident involving the target vehicle and another vehicle, based on accident data (for example, video from the drive recorder 117c described above) that indicates the situation of the target vehicle when the accident occurred. If another vehicle (the other vehicle involved in the accident) is present, the ECU 111 acquires identification information (vehicle ID) of the other vehicle involved in the accident. If the ECU 111 of the target vehicle cannot identify the vehicle ID of the other vehicle involved in the accident from the accident data, it may request the user terminal (for example, the mobile terminal 20) of the target vehicle to input information for identifying the vehicle ID of the other vehicle involved in the accident.

[0084] Next, in S14, the ECU 111 of the target vehicle transmits to the insurance server 600 an accident occurrence signal notifying the occurrence of an accident, damage information indicating the degree of damage to the battery 12 acquired in S12, and accident data indicating the condition of the target vehicle at the time the accident occurred. The accident occurrence signal includes, for example, location information of the accident location detected by the target vehicle's location sensor 118a, and identification information (vehicle ID) of each vehicle involved in the accident. In the case of a single-vehicle accident, the accident occurrence signal includes identification information of only the target vehicle. If there is another vehicle involved in the accident, the accident occurrence signal further includes identification information of the other vehicle in addition to the identification information of the target vehicle. When the processing of S14 is executed, the series of processes by the target vehicle ends.

[0085] When the insurance server 600 receives the accident occurrence signal (S14) from the target vehicle, it starts a series of processes from S21 to S27, which will be described below.

[0086] In S21, the insurance server 600 acquires owner information of each vehicle involved in the accident from the management center 500 (more specifically, the distributed ledger held by the management center 500) based on the vehicle ID included in the accident occurrence signal. The vehicle owner information includes first owner information indicating the owner of the power storage device mounted on the vehicle, and second owner information indicating the owner of the body part of the vehicle.

[0087] In the next S22, the insurance server 600 identifies the owner of the battery 12 installed in the target vehicle using the owner information of the target vehicle acquired in S21. Subsequently, in S23, the insurance server 600 notifies the terminal of the owner of the battery 12 identified in S22 that an accident has occurred for the target vehicle and the location of the accident. If the target vehicle is vehicle A or vehicle B, the insurance server 600 identifies the communication address of the server 520 (the terminal of the owner of the battery 12) based on the owner information of the target vehicle, and notifies the server 520 of the occurrence of an accident for the target vehicle. If the target vehicle is vehicle C, the insurance server 600 identifies the communication address of the mobile terminal 20 (the terminal of the owner of the battery 12) corresponding to the target vehicle based on the owner information of the target vehicle, and notifies the mobile terminal 20 of the occurrence of an accident for the target vehicle.

[0088] In this embodiment, when the insurance server 600 acquires the accident occurrence signal (including information indicating that an accident has occurred for the target vehicle), it executes the processes of S22 and S23. In detail, the insurance server 600 acquires first owner information of the target vehicle from the management center 500 (S21), identifies the owner of the power storage device of the target vehicle using the acquired first owner information (S22), and sends a notification to the terminal of the identified owner of the power storage device to notify them of the occurrence of an accident for the target vehicle (S23). This makes it possible, when a vehicle accident occurs, to accurately notify the owner of the power storage device provided in the target vehicle of the occurrence of the accident.

[0089] In the following S24, the insurance server 600 determines whether or not there is a vehicle involved in the accident based on the accident occurrence signal (S14). If the accident occurrence signal indicates a single-vehicle accident, the determination in S24 is NO, and the process proceeds to S27.

[0090] If the accident occurrence signal indicates that the accident is not a single-vehicle accident (i.e., the other vehicle is present) (YES in S24), in S25 the insurance server 600 uses the owner information of the other vehicle acquired in S21 to identify the user of the other vehicle. For example, if the other vehicle is vehicle A or vehicle C, the insurance server 600 directly identifies the user of the other vehicle from information indicating the owner of the body part of the other vehicle (second owner information). On the other hand, if the other vehicle is vehicle B, the insurance server 600 acquires information for identifying the user of the other vehicle (e.g., the communication address of the mobile terminal 20 corresponding to the other vehicle) from the server 520 (the terminal of the owner of the body part).

[0091] Subsequently, in S26, the insurance server 600 notifies the terminal of the user of the other party's vehicle identified in S25 (for example, the mobile terminal 20 corresponding to the other party's vehicle) of the owner of the battery 12 installed in the target vehicle. After that, the process proceeds to S27.

[0092] In this embodiment, when the insurance server 600 receives an accident occurrence signal indicating that an accident has occurred between a target vehicle and another vehicle, in S21, the insurance server 600 receives from the management center 500 first owner information indicating the owner of the power storage device of the target vehicle and second owner information indicating the owner of the body part of the other vehicle, and executes the processes of S25 and S26. In detail, the insurance server 600 identifies the user of the other vehicle using the second owner information received in S21 (S25), and sends a notification to the terminal of the identified user of the other vehicle informing them of the owner of the power storage device of the target vehicle (S26). This facilitates negotiations regarding compensation for damages between the user of the other vehicle (or an insurance company that has a contract with the user) and a leasing company for the power storage device (or an insurance company that cooperates with the leasing company) when the power storage device of the target vehicle is damaged in an accident.

[0093] In S27, the insurance server 600 executes a series of processes from S31 to S36, which will be described below and are shown in Fig. 7. Fig. 7 is a flowchart showing the process executed by the insurance server 600 for providing insurance services.

[0094] 1, 5 and FIG. 7, in S31, the insurance server 600 determines whether or not there is another vehicle involved in the accident, similar to S24 in FIG. 6. In the case of a single-vehicle accident, the determination in S31 is NO, and the process proceeds to S35.

[0095] If the other party's vehicle is present (YES in S31), the insurance server 600 identifies in S32 the server of the insurance provider that provides the insurance to which the other party's vehicle has subscribed (the other party's insurance server), and provides the accident data received from the target vehicle (S14 in FIG. 6) to the other party's insurance server. If the insurance server 600 cannot identify the other party's insurance server from the accident data, it may request information for identifying the other party's insurance server from the user terminal (e.g., mobile terminal 20) of the target vehicle. The insurance server 600 may send a notification to the other party's insurance server to explain the circumstances prior to providing (transmitting) the accident data.

[0096] By the process of S32 above, accident data is shared between the insurance server 600 of the target vehicle and the insurance server of the other party involved in the accident. After that, these insurance servers perform accident analysis based on the accident data (S33, S41), and the fault ratio of the user of the target vehicle is determined based on the results of the accident analysis (S34, S42). The higher the fault ratio, the greater the degree of fault.

[0097] Next, in S35, the insurance server 600 determines the insurance money to be paid by the insurance service based on the damage information received from the target vehicle (S14 in FIG. 6) and the vehicle user's fault ratio for the accident (S34).

[0098] In the case of a single-vehicle accident (self-inflicted accident), the insurance server 600 may determine the amount of insurance money based only on the damage information in S35. However, if it is determined from the accident data that the user intentionally damaged the battery 12, the insurance server 600 may determine that insurance will not be applied (no insurance money will be paid).

[0099] In the following S36, the insurance server 600 transmits to the server 520 a signal (hereinafter also referred to as an "insurance signal") including the vehicle ID of the target vehicle, damage information indicating the degree of damage to the battery 12 of the target vehicle, and information indicating the insurance money determined in S35. The insurance signal may include information indicating the vehicle user's share of fault in the accident. When the processing of S36 is executed, the series of processing steps from S31 to S36 (S27 in FIG. 6) by the insurance server 600 ends, and the series of processing steps from S51 to S53 by the server 520 starts.

[0100] In S51, the server 520 uses the damage information to determine the amount of loss due to the damage to the battery 12. In the following S52, the server 520 determines whether the amount of loss due to the damage to the battery 12 (S51) is greater than the insurance money indicated by the insurance signal. If the amount of loss due to the damage to the battery 12 is greater than the insurance money (YES in S52), the server 520 notifies the user terminal (e.g., mobile terminal 20) of the target vehicle in S53 to claim the difference (= amount of loss - insurance money). On the other hand, if the amount of loss due to the damage to the battery 12 is less than the insurance money (NO in S52), the server 520 does not claim from the vehicle user (S53). Note that if the target vehicle is vehicle B (a fully leased vehicle), the loss of the vehicle body may be fully compensated by insurance money, or the leasing company (automobile manufacturer) may claim at least a portion of the loss from the vehicle user.

[0101] 6 is completed by executing the series of processes shown in FIG. 7, and the series of processes by the insurance server 600 shown in FIG. 6 is terminated. In this embodiment, in S14 of FIG. 6, a target vehicle in which an accident has occurred transmits an accident occurrence signal notifying the occurrence of the accident, damage information indicating the degree of damage to the power storage device mounted on the target vehicle, and accident data indicating the condition of the target vehicle at the time of the accident. Then, when the accident occurrence signal is received, the insurance server 600 executes the series of processes shown in FIGS. 6 and 7. In detail, the insurance server 600 determines the degree of fault of the user of the target vehicle in relation to the accident based on the accident data (S34 of FIG. 7), and determines the insurance money to be paid by the insurance service based on the damage information and the degree of fault (S35 of FIG. 7). This makes it easier to determine the insurance money appropriately. It also makes it easier for the user of the target vehicle to receive insurance services.

[0102] When the server 520 receives a notification of an accident occurrence from the insurance server 600 (S23 in FIG. 6), the server 520 starts a series of processes shown in FIG. 8, which will be described below. In this embodiment, when the server 520 receives the notification of an accident occurrence, it means that an accident has occurred with vehicle A or vehicle B.

[0103] Fig. 8 is a flowchart showing control executed by the server 520 when an accident occurs in the method for managing a power storage device according to this embodiment. With reference to Fig. 8 together with Figs. 1 and 5, in S101, the server 520 identifies one or more BSta 200 that exist in the vicinity of the accident location based on the location of the accident location notified by the insurance server 600 (S23 in Fig. 6). The one or more BSta 200 that exist in the vicinity of the accident location may be one BSta 200 that is closest to the accident location, or may be at least one BSta 200 that exists within a predetermined distance from the location of the accident location.

[0104] In the following S102, the server 520 permits the node 510B of one or more BSta 200 identified in S101 to replace the battery 12 installed in the target vehicle. Specifically, the server 520 transmits an exchange permission signal including identification information (vehicle ID) of the target vehicle to the node 510B. This exchange permission signal permits the BSta 200 to exchange the battery of the target vehicle. The node 510B identifies the vehicle to be exchanged based on the vehicle ID included in the exchange permission signal. The vehicle ID included in the exchange permission signal is registered in the node 510B, and a battery exchange of the target vehicle identified by the vehicle ID is reserved in the node 510B. The node 510B can execute the reserved battery exchange by the process shown in FIG. 9 described later. However, if the battery exchange is not executed even after a predetermined period has elapsed since the battery exchange was reserved, the reservation may be canceled.

[0105] Subsequently, in S103, the server 520 requests the nodes 510B of one or more BSta 200 identified in S101 to secure a power storage device (replacement battery) that can be replaced with the battery 12 mounted on the target vehicle. Specifically, the server 520 extracts specification information about the battery 12 of the target vehicle from the distributed ledger stored in the storage device 522 based on the identification information (vehicle ID) of the target vehicle, and executes the above request to the node 510B by transmitting the extracted specification information to the node 510B. The node 510B that receives this request checks whether or not there is a shortage of the replacement battery requested by the server 520, and if there is a shortage of replacement batteries, secures a replacement battery (power storage device for the target vehicle) from a nearby warehouse or another BSta 200.

[0106] In this embodiment, when the server 520 receives a notification (S23 in FIG. 6) informing the user that an accident has occurred in the target vehicle, the server 520 executes the processes of S101 to S103. Specifically, in S102, the server 520 (the terminal of the owner of the power storage device of the target vehicle) permits one or more BSta200 (exchange stations) to exchange the power storage device of the target vehicle. This makes it easier to exchange the power storage device mounted on the target vehicle at an exchange station when an accident occurs in the target vehicle. Furthermore, the process of S103 makes it easier to exchange the battery early after the accident.

[0107] A target vehicle in which an accident has occurred arrives at a BSta 200 located near the location of the accident (for example, the BSta 200 closest to the location of the accident) by driving under its own power or being transported by a tow truck. Then, the battery 12 installed in the target vehicle is replaced at the BSta 200. Figure 9 is a flowchart showing the processing related to battery replacement executed by the target vehicle and the battery replacement station terminal (node ​​510B).

[0108] 1, 5, and FIG. 9, a series of processes from S110 to S180 are executed by ECU 111 of the target vehicle. A series of processes from S210 to S270 are executed by node 510B. Node 510B is configured to be able to wirelessly communicate with the target vehicle and acquires battery information from the target vehicle. Node 510B and the target vehicle may communicate with each other over a short distance using a wireless LAN (Local Area Network), for example, or may communicate via a communication network NW.

[0109] After arriving at BSta 200, the target vehicle transmits a signal (hereinafter also referred to as a "request signal") requesting battery replacement to node 510B in S110. The request signal includes identification information (vehicle ID) of the target vehicle. Hereinafter, the battery 12 before replacement provided in the target vehicle will be referred to as "battery B1." The target vehicle may execute the battery replacement request (S110) in response to an instruction from the user.

[0110] Upon receiving the request signal, node 510B determines in S210 whether predetermined exchange requirements are met for the target vehicle. Specifically, node 510B determines whether the exchange requirements are met based on whether the vehicle ID included in the request signal matches the vehicle ID included in the exchange permission signal (S102 in FIG. 8). In other words, if the vehicle ID of the target vehicle is registered (reserved), the exchange requirements are met, and if the vehicle ID of the target vehicle is not registered (reserved), the exchange requirements are not met.

[0111] If the replacement requirements are met for the target vehicle (YES in S210), node 510B sends a notification of permission to the target vehicle in S220, and then the process proceeds to S240. On the other hand, if the replacement requirements are not met for the target vehicle (NO in S210), node 510B sends a notification of denial to the target vehicle in S230, and then the series of processes from S210 to S270 ends. In this case, battery replacement is not performed.

[0112] After transmitting a request signal (S110), the target vehicle waits for a reply from node 510B. Then, upon receiving a reply from node 510B, the target vehicle determines in S120 whether or not the battery exchange is permitted. If the target vehicle receives the above-mentioned notification of permission (YES in S120), the process proceeds to S130. On the other hand, if the target vehicle receives the above-mentioned notification of denial (NO in S120), the series of processes from S110 to S180 ends. In this case, the battery exchange is not performed.

[0113] In S130 and S240, the battery exchange is carried out in accordance with the procedure described below (see FIG. 10). The target vehicle and node 510B exchange information for the battery exchange.

[0114] Hereinafter, the battery 12 attached to the target vehicle by the battery replacement will be referred to as "battery B2." When the battery replacement is complete, the target vehicle performs an inspection of battery B2 in S140. Next, the target vehicle transmits the inspection results to node 510B in S150. Next, the target vehicle determines whether the battery replacement was successful or not based on the inspection results in S160. If the inspection does not reveal any abnormalities (e.g., poor connection or abnormal electrical performance), the target vehicle determines that the battery replacement was successful; if the inspection reveals any abnormalities, the target vehicle determines that the battery replacement was not successful. Similarly, node 510B, which has received the inspection results, also determines whether the battery replacement was successful or not based on the inspection results (no abnormality / abnormality) in S250.

[0115] If the battery replacement is successful (YES in S160 and YES in S250), the target vehicle and node 510B each update their own battery information (specification information) in S170 and S260, and then the series of processes shown in FIG. 9 ends. Node 510B may update the distributed ledger managed by management center 500 in S260. On the other hand, if the battery replacement is unsuccessful (NO in S160 and NO in S250), the target vehicle and node 510B each execute predetermined abnormality processing in S180 and S270. The abnormality processing may include processing for notifying the user of the target vehicle that the battery replacement has failed. The abnormality processing may also include processing for notifying server 520 that the battery replacement has failed. The abnormality processing may also include processing for temporarily removing battery B2 installed in the target vehicle from the target vehicle and redoing the battery replacement. After the abnormality processing is executed, the series of processes shown in FIG. 9 ends. The abnormality handling can be set arbitrarily.

[0116] FIG. 10 is a diagram for explaining the configuration and operation of the battery exchange station (BSta200) according to this embodiment.

[0117] Referring to FIG. 10, the BSta 200 includes a storage device 210 and an inspection unit 220. The storage device 210 includes a storage unit (e.g., a storage facility). The inspection unit 220 includes, for example, a charger / discharger, a measuring device, and a sorting device. The BSta 200 further includes a transport device for transporting the power storage devices, and an exchange device for exchanging the power storage devices. The transport method may be a conveyor system or a system using a transport robot. The transport device and the exchange device are each controlled by the node 510B.

[0118] The storage device 512 (FIG. 2) of the node 510B stores information about each battery present in the BSta 200, distinguishing it by battery identification information (battery ID). The battery information held by the node 510B includes, for example, specifications (initial capacity, charging performance, discharging performance, etc.), status (for example, pre-inspection / inspected (reuse / other use / disposal) / ready for supply), SOH (State of Health), and SOC (State of Charge).

[0119] Note that SOC indicates the remaining amount of electricity stored, and corresponds to the ratio of the current amount of electricity stored to the amount of electricity stored in a fully charged state. SOH indicates the state of health or the degree of deterioration. Examples of SOH include capacity maintenance rate and internal resistance. The higher the internal resistance of the electricity storage device, the greater the degree of deterioration of the electricity storage device. The lower the capacity maintenance rate of the electricity storage device, the greater the degree of deterioration of the electricity storage device. The capacity maintenance rate of the electricity storage device corresponds to the ratio of the current capacity of the electricity storage device to the capacity of the electricity storage device in its initial state (undegraded state). The capacity of the electricity storage device corresponds to the amount of electricity stored in a fully charged state.

[0120] The node 510B may write information (such as battery ID, specifications, and SOH) about each battery B3 (supplyable power storage device) accommodated in the accommodation section of the storage device 210, together with location information of the BSta 200, to a distributed ledger managed by the management center 500. Such information is useful for battery inventory management. The batteries present in the BSta 200 are the property of the automobile manufacturer. New batteries may be supplied to the BSta 200 from the automobile manufacturer's warehouse, and second-hand batteries collected from vehicles 10 may be stored in the BSta 200. Batteries may also be transported between multiple BSta 200.

[0121] After parking the target vehicle in a predetermined position within BSta 200, the target vehicle requests node 510B to replace the battery (S110 in FIG. 9). In response to this request, node 510B starts control for battery replacement (S240 in FIG. 9). Node 510B replaces the battery of the target vehicle, for example, in the following procedure.

[0122] Node 510B selects a battery (replacement battery) corresponding to battery B1 from among the multiple batteries B3 stored in the storage unit of storage device 210. The selected battery B3 has the same specifications (e.g., initial capacity, charging performance, and discharging performance) as battery B1. However, the degree of deterioration of battery B3 is less than that of battery B1. In addition, the SOC of battery B3 is equal to or greater than a predetermined SOC value (e.g., 50%).

[0123] Next, the replacement device removes battery B1 from the target vehicle. Hereinafter, the battery removed from the target vehicle will be referred to as "battery B4." Next, the transport device transports (supplies) battery B3 from storage device 210 to the replacement device. Next, the replacement device installs the supplied battery B3 in the target vehicle. This completes the battery replacement of the target vehicle.

[0124] In parallel with the battery replacement process, BSta200 also executes a reuse process for battery B4, which has been removed from the target vehicle. When battery B4 is removed from the target vehicle, node 510B starts control for battery reuse. The reuse process is executed, for example, in the following procedure.

[0125] The transport device transports (collects) battery B4 to inspection unit 220. Subsequently, inspection unit 220 inspects the collected battery B4. The inspection is performed by a charger / discharger and a measuring device of inspection unit 220. Before the inspection, SOH recovery processing may be performed on battery B4.

[0126] In the above test, the charger / discharger discharges battery B4 until it reaches a predetermined first SOC value (e.g., an SOC value indicating a fully charged state) or less, and then charges battery B4 until it reaches a predetermined second SOC value (e.g., an SOC value indicating a fully charged state) or more. The measurement device includes various sensors and measures the state (e.g., temperature, current, and voltage) of battery B4 during charging and / or discharging. The measurement device then detects the SOH of battery B4 from the measured data. The measurement device may further include a camera for visual inspection. The charger / discharger may repeatedly charge and discharge battery B4 until the measurement device acquires the necessary test data.

[0127] Once the above inspection is complete, the sorting device of the inspection unit 220 sorts the battery B4 based on the inspection results into one of the following: reuse as a vehicle battery, use for other purposes (use other than for vehicles), or disposal. Examples of other uses include stationary use. The method of battery disposal is arbitrary. During the disposal process, the battery may be disassembled down to the material level, and recyclable materials (resources) may be recovered and reused (resource recycling). Note that the sorting device may classify batteries B4 with significant external damage as non-reusable (for other uses or disposal).

[0128] Battery B4, which can be reused as a vehicle battery, is treated as the aforementioned battery B3. After the above inspection, a transport device transports battery B3 to storage device 210. The transported battery B3 is loaded into storage device 210. As a result, inspected and charged battery B3 is set in storage device 210 and can be supplied. However, without being limited to this, storage device 210 may be configured to charge inspected battery B3.

[0129] FIG. 10 shows an example in which battery removal and battery installation are performed at different locations. The target vehicle may be transported from the removal position to the installation position by a transport device (e.g., a conveyor-type transport device) not shown. However, this is not limited to this, and battery removal and battery installation may also be performed at the same location. Battery replacement (removal and installation) may be performed while the target vehicle is stationary (e.g., parked). Furthermore, it is not necessary for the battery before replacement and the battery after replacement to have the same specifications. The on-board battery may be replaced with a battery of different specifications. For example, the capacity of the on-board battery may be increased by battery replacement.

[0130] As described above, the method for managing a power storage device according to this embodiment includes the processes shown in FIGS. 6 to 9. In this embodiment, the insurance server 600 corresponds to an example of a "computer device" according to the present disclosure. Each process is performed by one or more processors executing a program stored in one or more memories. However, these processes may also be performed by dedicated hardware (electronic circuits) rather than software.

[0131] In the above embodiment, the insurance money for damage to the power storage device is calculated for vehicle A (partially leased vehicle) and vehicle B (fully leased vehicle) using a common processing flow (see FIG. 7). However, the present invention is not limited to this, and the insurance money may be calculated using different processing flows for vehicle A and vehicle B. For example, the insurance server 600 may execute the processing flow shown in FIG. 7 for vehicle A and a different processing flow (not shown) for vehicle B. For vehicle B, the insurance server 600 may provide an insurance service that not only compensates for damage to the power storage device but also for damage to the vehicle body.

[0132] The processing flows shown in FIGS. 6 to 9 can be modified as appropriate. For example, the order of processing may be changed or unnecessary steps may be omitted depending on the purpose. Furthermore, the content of any of the processing may be changed. In the above embodiment, the insurance server 600 acquires both the first owner information and the second owner information in S21 of FIG. 6, but the insurance server 600 may acquire only the first owner information from the management center 500. Furthermore, in an embodiment in which the first owner information (information indicating the owner of the on-vehicle power storage device) is included in the vehicle authentication information (e.g., vehicle inspection registration information) managed by the data management device of the authority, the insurance server 600 may acquire the first owner information (authentication information) from the data management device of the authority in S21 of FIG. 6.

[0133] The management center 500 may manage the first owner information as battery passport information. Furthermore, when the management center 500 is requested by the insurance server 600 to transmit the owner information, the management center 500 may request permission from the owner indicated in the owner information, and transmit the owner information to the insurance server 600 only if permission is obtained from the owner. In this embodiment, the node 510, the server 520, and the insurance server 600 are all on-premise servers. However, this is not a limitation, and the functions of each server may be implemented on a cloud using cloud computing. That is, these servers may be cloud servers. The location where the leasing service is provided is not limited to the dealer 100. For example, the server 520 may provide the leasing service online (e.g., on a cloud). Furthermore, only one type of leasing method (e.g., a partial leasing method) may be used.

[0134] In the above embodiment, only the battery is replaced, but the battery pack including the battery and its accessories (for example, at least one of the battery ECU, BMS, strain sensor, temperature control system, and SMR) may be replaced together. The vehicle may be an xEV (electric vehicle) other than a BEV. The vehicle may be equipped with an internal combustion engine. The vehicle is not limited to a four-wheeled passenger car, but may be a bus or truck, or an xEV with three or five or more wheels. The vehicle may be equipped with solar panels. The vehicle may be configured to be capable of contactless charging. The vehicle may be configured to be capable of autonomous driving or may have a flight function. The vehicle may be an unmanned vehicle (for example, a robotaxi, an automated guided vehicle, or agricultural machinery).

[0135] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the description of the above embodiments, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0136] 10 vehicles, 11 vehicle bodies, 12 batteries, 20 mobile terminals, 100 dealers, 111 ECUs, 200 battery exchange stations, 500 management centers, 510 nodes, 520 servers, 600 insurance servers.

Claims

1. When a computer device acquires information indicating that an accident has occurred between a vehicle equipped with a power storage device and another vehicle, the computer device acquires first owner information indicating the owner of the power storage device and second owner information indicating the owner of the body part of the other vehicle from a data management device that manages information indicating the owner of each of the on-board power storage device and vehicle body part for each of a plurality of vehicles including the vehicle and the other vehicle; the computer device identifies an owner of the power storage device using the acquired first owner information, and notifies a terminal of the identified owner of the power storage device of an occurrence of an accident involving the vehicle equipped with the power storage device; the computer device identifies a user of the other vehicle using the acquired second owner information, and notifies a terminal of the identified user of the other vehicle of the owner of the power storage device; A method for managing an electricity storage device, comprising:

2. A computer device including a processor and a storage device that stores a program that causes the processor to execute a method for managing a power storage device, The method for managing the power storage device includes: When information indicating that an accident has occurred between a vehicle equipped with a power storage device and another vehicle is acquired, first owner information indicating the owner of the power storage device and second owner information indicating the owner of the vehicle body part of the other vehicle is acquired from a data management device that manages information indicating the owners of the in-vehicle power storage device and the vehicle body part for each of a plurality of vehicles including the vehicle and the other vehicle; using the acquired first owner information to identify an owner of the power storage device, and sending a notification to a terminal of the identified owner of the power storage device notifying the occurrence of an accident involving the vehicle equipped with the power storage device; identifying a user of the other vehicle using the acquired second owner information, and sending a notification to a terminal of the user of the identified other vehicle informing the owner of the power storage device; 2. A computer device comprising:

3. A management system for a power storage device, comprising: a server that provides insurance services for damage to a vehicle power storage device; and a data management device that manages information on a plurality of vehicles, including a vehicle equipped with a power storage device, The server When information indicating that an accident has occurred in a vehicle including the power storage device is acquired, first owner information indicating an owner of the power storage device is acquired from the data management device; Identifying an owner of the power storage device using the acquired first owner information; sending a notification to a terminal of an owner of the identified power storage device to notify the owner of the vehicle equipped with the power storage device that an accident has occurred; configured to run The data management device a storage device that stores the distributed ledger; a control device that registers transaction data including information indicating an owner of an on-board power storage device for each of the plurality of vehicles in the distributed ledger; Equipped with the vehicle in which the accident has occurred is configured to transmit an accident occurrence signal notifying the occurrence of the accident, damage information indicating a degree of damage to the power storage device, and accident data indicating a state of the vehicle at the time the accident occurred; When the server receives the accident occurrence signal, determining a degree of fault of a user of the vehicle with respect to the accident based on the accident data; determining an insurance amount to be paid by the insurance service based on the damage information and the degree of negligence; A management system for an electricity storage device configured to execute the above.

4. A management system for a power storage device, comprising: a computer device; and a data management device that manages information relating to a plurality of vehicles including a vehicle equipped with a power storage device, the computer device includes a processor and a storage device; The storage device includes: When information indicating that an accident has occurred in a vehicle including the power storage device is acquired, first owner information indicating an owner of the power storage device is acquired from the data management device; Identifying an owner of the power storage device using the acquired first owner information; sending a notification to a terminal of an owner of the identified power storage device to notify the owner of the vehicle equipped with the power storage device that an accident has occurred; a program for causing the processor to execute the above; The data management device a storage device that stores the distributed ledger; a control device that registers transaction data including information indicating an owner of an on-board power storage device for each of the plurality of vehicles in the distributed ledger; Equipped with the management system further includes a plurality of exchange stations that exchange the vehicle power storage devices; the terminal of the owner of the power storage device is a server that provides a leasing service for renting out a vehicle power storage device, The server is configured to permit one or more of the exchange stations to exchange the power storage device when the server receives the notification that an accident has occurred in the vehicle.

Images