Excursion support method, device, system, and program, as well as user-side device and program

Abstract

An excursion support method executed by an excursion support device is provided. When a user (U1) who is riding in an own vehicle (V1) reaches a local area that is set with a destination as a reference, a target parking lot (611) that corresponds to a position of the destination, and a target station (621) of a mobility share service that is available for the user to head for the destination after getting off the own vehicle at the target parking lot are proposed to the user through a user-side device operated by the user.

Description

Travel support method, device, system and program, and user device and program

[0001] The present invention relates to a travel assistance method, device, system and program, as well as a user device and program.

[0002] A typical function of a navigation device for a vehicle is to provide guidance to parking lots near a destination (see, for example, Patent Document 1 below). Meanwhile, mobility sharing services are becoming popular as a new transportation service. In mobility sharing services, electric kick scooters, electric bicycles, and the like are provided as shared vehicles that can be shared by multiple people. In mobility sharing services, multiple stations are distributed as locations where each shared vehicle can be rented, returned, and stored.

[0003] WO 2007 / 116650

[0004] Currently, the integration of parking guidance functions and mobility sharing services is insufficient. As a result, for example, at some point on the way to a destination in one's vehicle, the user must search for or specify a suitable parking lot and then separately search for a suitable station nearby the parking lot. This is time-consuming for the user. In addition, the user may find it inconvenient to realize that the nearest station is far from the parking lot only after getting out of their vehicle (hindering a smooth trip to the destination).

[0005] On the other hand, there are cases where a user wants to actually visit a recommended spot (such as a tourist spot) suggested through an information terminal, etc. However, if the recommended spot is simply notified, when the user wants to visit a recommended spot, the user must search for a mobility sharing service to use to get to the recommended spot. This is time-consuming for the user and makes it difficult to visit the recommended spot smoothly.

[0006] The present invention aims to propose a technology that reduces the user's workload or a technology that supports a user in smoothly visiting a place that the user wishes to visit (a destination, a recommended spot).

[0007] A mobility support method according to a first aspect of the present invention is a mobility support method executed by a mobility support device, in which, when a user in a vehicle reaches a local area set based on a destination, information on target parking lots corresponding to the location of the destination and target stations of a mobility sharing service corresponding to the location of the target parking lots is output to a user-side device operated by the user. In other words, the mobility support method according to the first aspect is a mobility support method executed by a mobility support device, in which, when a user in a vehicle reaches a local area set based on a destination, information on target parking lots corresponding to the location of the destination and target stations of a mobility sharing service that can be used to head to the destination after the user gets off the vehicle at the target parking lots is suggested to the user via a user-side device operated by the user.

[0008] A second aspect of the present invention relates to a method for supporting travel that is executed by a travel assistance device, and outputs recommended spots that are recommended to be visited and a route plan for the user to visit the recommended spots to a user-side device operated by the user, the route plan including a plan for using a mobility sharing service when the user travels to the recommended spots. In other words, the second aspect of the present invention relates to a method for supporting travel that is executed by a travel assistance device, and proposes to the user, via a user-side device operated by the user, recommended spots that the user can visit and a route plan for the user to visit the recommended spots, the route plan including a plan for using a mobility sharing service to be used when the user travels from their current location to the recommended spots.

[0009] In a typical method of using parking lots and stations, a user must search for or specify a suitable parking lot at a point along the way to a destination in their vehicle, and then separately search for a suitable station near the parking lot. In contrast, according to the first aspect of the travel assistance method, when the user arrives in a local area based on the destination, appropriate parking lots and appropriate stations are suggested according to the location of the destination. This reduces the user's effort and allows the user to smoothly reach the destination after arriving at the parking lot.

[0010] In a method in which recommended spots are simply notified, if a user wants to go to a recommended spot, the user must search for a mobility sharing service to use on the way to the recommended spot. In contrast, the travel support method according to the second aspect proposes a route plan that includes a plan for using a mobility sharing service, which is highly convenient, saves the user time, and supports smooth travel to the recommended spot.

[0011] FIG. 1 is an overall configuration diagram of a travel assistance system according to an embodiment of the present invention. FIG. 2 is a diagram showing how a user gets into his / her vehicle according to an embodiment of the present invention. FIG. 3 is an internal configuration diagram of a user-side device according to an embodiment of the present invention. (a) and (b) are configuration diagrams of a user-side device according to an embodiment of the present invention. FIG. 4 is an internal configuration diagram of a travel assistance device according to an embodiment of the present invention. FIG. 5 is a configuration diagram of a registrant table according to an embodiment of the present invention. FIG. 6 is a configuration diagram of a management table according to an embodiment of the present invention. FIG. 7 is an operation sequence diagram of a travel assistance system according to a first embodiment of the present invention. FIG. 8 is a diagram for explaining a method of searching for a recommended parking lot from multiple parking lots within a search area according to the first embodiment of the present invention. FIG. 9 is a diagram showing examples of a route plan and a usage plan according to the first embodiment of the present invention. (a) and (b) are diagrams showing how signals related to fee reductions are transmitted and received between devices according to Example EX1_2 belonging to the first embodiment of the present invention. FIG. 10 is a diagram showing how a fee adjustment unit is provided in a server-side controller according to Example EX1_2 belonging to the first embodiment of the present invention. FIG. 11 is a diagram showing how parking fees or rental fees are set depending on variable factors according to Example EX1_3 belonging to the first embodiment of the present invention. 1 is a diagram showing examples of a route plan and a usage plan according to Example EX1_5 belonging to the first embodiment of the present invention; FIG. 2 is an operation flowchart of a server-side controller according to Example EX1_6 belonging to the first embodiment of the present invention; FIG. 3 is an operation flowchart of a user-side controller according to Example EX1_6 belonging to the first embodiment of the present invention; FIG. 4 is a diagram showing an example of display content on a display screen of a user-side device according to Example EX1_7 belonging to the first embodiment of the present invention; FIG. 5 is a functional block diagram of a server-side controller according to Example EX1_8 belonging to the first embodiment of the present invention; FIG. 6 is a functional block diagram of a user-side controller according to Example EX1_8 belonging to the first embodiment of the present invention; FIG. 7 is an operation sequence diagram of a travel support system according to a second embodiment of the present invention; FIG. 8 is a diagram showing examples of a route plan and a usage plan according to Example EX2_1 belonging to the second embodiment of the present invention; FIG. 9 is a diagram showing examples of a route plan and a usage plan according to Example EX2_1 belonging to the second embodiment of the present invention; FIG. 10 is a diagram showing examples of a route plan and a usage plan according to Example EX2_2 belonging to the second embodiment of the present invention.10 is a diagram showing an example of a route plan and a usage plan according to Example EX2_2 belonging to the second embodiment of the present invention. FIG. 11 is a diagram showing how a parking fee or a rental fee is set according to variable factors according to Example EX2_4 belonging to the second embodiment of the present invention. FIG. 12 is an operation flowchart of a server-side controller according to Example EX2_6 belonging to the second embodiment of the present invention. FIG. 13 is an operation flowchart of a user-side controller according to Example EX2_6 belonging to the second embodiment of the present invention. FIG. 14 is a diagram showing an example of the display content of a display screen on a user-side device according to Example EX2_7 belonging to the second embodiment of the present invention. FIG. 15 is a functional block diagram of a server-side controller according to Example EX2_8 belonging to the second embodiment of the present invention. FIG. 16 is a functional block diagram of a user-side controller according to Example EX2_8 belonging to the second embodiment of the present invention.

[0012] FIG. 1 shows the overall configuration of a mobility assistance system according to an embodiment of the present invention. The mobility assistance system shown in FIG. 1 includes a user device 10, a mobility assistance device 20, an MSS management device 30 related to a mobility sharing service, a parking lot server device 40, and databases DB1 and DB2. Hereinafter, mobility sharing service will be abbreviated as MSS. The user device 10 is wirelessly connected to a communication network NET. The mobility assistance device 20, the MSS management device 30, the parking lot server device 40, and the databases DB1 and DB2 are connected to the communication network NET wirelessly or via a wired connection. The communication network NET includes the Internet and an intranet, and may also include a short-range wireless communication line.

[0013] A user of the travel assistance system in FIG. 1 is referred to as a user. FIG. 2 shows one of the users, user U1. A private passenger car associated with user U1 is referred to as the host vehicle V1. The host vehicle V1 is a vehicle occupied by user U1 or a companion of user U1. When user U1 is accompanied by a companion and user U1 rides in the host vehicle V1, user U1 and the companion are occupants of the host vehicle V1. The owner of the host vehicle V1 may be user U1 or a family member of user U1. However, the host vehicle V1 may be a rental car. FIG. 2 shows a state in which user U1 rides in the host vehicle V1. Although FIG. 2 shows only user U1 as a person inside the host vehicle V1, multiple people may ride in the host vehicle V1. When user U1 rides in the host vehicle V1, user U1 may be the driver of the host vehicle V1 or a passenger other than the driver. The user-side device 10 is a device associated with user U1.

[0014] 3 shows the internal configuration of the user device 10. The user device 10 includes a controller 11, a memory 12, a communication unit 13, and an HMI 14.

[0015] The controller 11 includes a processing unit 11a including a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit) as a hardware resource. The controller 11 may execute a program recorded in the memory 12 or any other recording medium to realize any function, operation, and process that should be realized by the controller 11. All or part of the operations performed by the controller 11 described below may be understood to be operations performed by the processing unit 11a.

[0016] The memory 12 is configured to include non-volatile memory such as ROM (Read Only Memory) or flash memory, and volatile memory such as RAM (Random Access Memory). The memory 12 stores various data referenced by the controller 11, as well as various programs to be executed by the controller 11.

[0017] The communication unit 13 is a communication circuit (communication module) that transmits and receives arbitrary signals between the user device 10 and a different counterpart device. The counterpart device for the communication unit 13 includes any device connected to the communication network NET, and in the case of the roaming assistance system of FIG. 1 , it particularly includes the roaming assistance device 20. In other words, the user device 10 is wirelessly connected to the roaming assistance device 20, and two-way communication is possible between the user device 10 and the roaming assistance device 20 via the communication network NET. The controller 11 can transmit and receive arbitrary information to and from the counterpart device using the communication unit 13, but the description of the communication unit 13 may be omitted below.

[0018] The HMI 14 is a human-machine interface, and information is exchanged between the user U1 and the user device 10 through the HMI 14. The HMI 14 is equipped with a display screen 14a, a speaker 14b, a microphone 14c, and an operation input unit 14d. The display screen 14a is composed of a liquid crystal display panel or the like, and displays any video (image) under the control of the controller 11. The speaker 14b outputs any sound under the control of the controller 11. The microphone 14c converts ambient sounds around the user device 10 into electrical signals and outputs them to the controller 11. The ambient sounds around the user device 10 include the voice of the user U1. The operation input unit 14d receives any operation from the user U1. The operation input unit 14d can be composed of operation buttons, a touch panel, or the like. The touch panel is composed of the display screen 14a. The operation input to the operation input unit 14d may be voice operation using the microphone 14c. The user U1 can input any information to the user device 10 by operating the operation input unit 14 d, and the input information from the user U1 to the user device 10 is transmitted to the controller 11 .

[0019] As shown in FIG. 4A, the user device 10 may be an information terminal 10A owned by a user U1. The information terminal 10A is a portable information terminal such as a smartphone or a tablet. When the user device 10 is the information terminal 10A, the controller 11, memory 12, communication unit 13, and HMI 14 shown in FIG. 3 are the controller, memory, communication unit, and HMI provided in the information terminal 10A. The user U1 carries the information terminal 10A with him / her continuously. Therefore, when the user U1 gets off his / her vehicle V1 and moves outside the vehicle V1, the information terminal 10A also moves with the user U1.

[0020] Alternatively, as shown in FIG. 4B, the user device 10 may be a combination of an information terminal 10A and an in-vehicle device 10B. When the user device 10 is a combination of the information terminal 10A and the in-vehicle device 10B, the information terminal 10A and the in-vehicle device 10B are capable of two-way communication with each other via a short-range wireless communication line or the like, and any information handled by the user device 10 can be shared between the information terminal 10A and the in-vehicle device 10B. When the user device 10 is a combination of the information terminal 10A and the in-vehicle device 10B, the operation of the controller 11 when the user U1 is in the vehicle V1 is interpreted as the operation of a controller provided in the information terminal 10A or the in-vehicle device 10B. When the user device 10 is a combination of the information terminal 10A and the in-vehicle device 10B, the operation of the controller 11 when the user U1 is outside the vehicle V1 is interpreted as the operation of a controller provided in the information terminal 10A. When the user device 10 is a combination of an information terminal 10A and an in-vehicle device 10B, the communication unit 13 may be a communication unit provided in either the information terminal 10A or the in-vehicle device 10B. The information terminal 10A or the in-vehicle device 10B may realize connection to the communication network NET using a communication unit provided in either the information terminal 10A or the in-vehicle device 10B. When the in-vehicle device 10B does not have a communication unit, the in-vehicle device 10B can realize connection to the communication network NET via a short-range wireless communication line between the information terminal 10A and the in-vehicle device 10B and the communication unit of the information terminal 10A.

[0021] In the following description of the embodiments of the present invention, unless otherwise specified, the user device 10 is the information terminal 10A itself. The controller 11 in the user device 10 may be referred to as the user controller 11 to clearly distinguish it from other controllers described below.

[0022] 5 shows the internal configuration of the wandering support device 20. The wandering support device 20 is a server device composed of one or more computers connected to a communication network NET. The wandering support device 20 may be formed using cloud computing. The wandering support device 20 includes a controller 21, a memory 22, and a communication unit 23.

[0023] The controller 21 includes a processing unit 21a including a CPU, a GPU, etc. as a hardware resource. The controller 21 may execute a program recorded in the memory 22 or any other recording medium to realize any function, operation, and processing to be realized by the controller 21. All or part of the operations performed by the controller 21 described below may be understood to be operations performed by the processing unit 21a. Hereinafter, the controller 21 in the travel support device 20 may be referred to as the server-side controller 21.

[0024] The memory 22 is configured to include non-volatile memory such as ROM or flash memory, and volatile memory such as RAM. The memory 22 stores various data referenced by the controller 21, as well as various programs to be executed by the controller 21.

[0025] The communication unit 23 is a communication circuit (communication module) that transmits and receives arbitrary signals between the travel assistance device 20 and a different counterpart device. The counterpart device for the communication unit 23 includes any device connected to the communication network NET, and in the travel assistance system of FIG. 1 , it particularly includes the user device 10, the MSS management device 30, and the parking lot server device 40. In other words, the travel assistance device 20 is capable of two-way communication with each of the user device 10, the MSS management device 30, and the parking lot server device 40. The controller 21 can transmit and receive arbitrary information to and from the counterpart device using the communication unit 23, but the description of the communication unit 23 may be omitted below.

[0026] The database DB1 is configured from a large-capacity recording medium such as a cloud server used by the travel assistance device 20. The controller 21 can store any information in the database DB1 and can also read any information stored in the database DB1. The database DB1 may be configured from a recording medium built into the travel assistance device 20.

[0027] The MSS management device 30 and the parking lot server device 40 are each server devices configured with one or more computers connected to the communication network NET. The MSS management device 30 and the parking lot server device 40 may each be formed using cloud computing. Although not individually illustrated, the MSS management device 30 and the parking lot server device 40 each have an internal configuration equivalent to the internal configuration of the mobility support device 20 shown in FIG. 5.

[0028] The travel assistance device 20 cooperates with the user device 10 to assist the user U1 in traveling around town, etc., and particularly assists in traveling around with the user's vehicle V1 parked in a parking lot. A travel assistance application program (user program) for realizing travel assistance is installed in the information terminal 10A. The travel assistance application program is stored in non-volatile memory in the memory 12 of the information terminal 10A. In the following, it is assumed that the travel assistance application program is executed by the controller 11 of the information terminal 10A. Unless otherwise specified, each operation of the controller 11 described below can be understood to be an operation in accordance with the travel assistance application program.

[0029] In the embodiment of the present invention, the user U1 travels around using an MSS (mobility sharing service). A vehicle shared among multiple people in an MSS is called a shared vehicle. The user's own vehicle V1 may also be a vehicle provided by a car sharing service, but the user's own vehicle V1 does not fall under the category of a shared vehicle described in the embodiment of the present invention. A shared vehicle may be, for example, a bicycle, an electric motorcycle, an electric kick scooter, or a small electric car. The bicycle may be an electric bicycle. In the embodiment of the present invention, it is assumed that the user U1 uses a shared vehicle as a means of transportation when moving around town, etc., while parking the user's own vehicle V1 in a parking lot. For the sake of simplicity, in the following description, a shared vehicle will often be referred to as an SR vehicle.

[0030] In an MSS, numerous stations are distributed at various locations. In this specification, a station does not refer to a station where public transportation such as a train or a bus stops, but refers to a location in the MSS where SR vehicles are rented, returned, and stored. To distinguish between a station in an MSS and a station where public transportation stops, the former station may be referred to as a shared mobility station. Each station handles multiple SR vehicles. Each station has one or more ports. A port is a space where SR vehicles are installed and stored, and may be equipped with a charger for charging electric SR vehicles.

[0031] The MSS management device 30 is a server device used, operated, and managed by the operator of the MSS. The MSS management device 30 manages the rental of a group of SR vehicles. The SR vehicle group here refers to a collection of many SR vehicles available for rental at the MSS. The SR vehicles that make up the SR vehicle group are distributed across multiple stations, and multiple SR vehicles are available for rental and storage at each station. The MSS management device 30 manages the rental status of SR vehicles at each station and handles the reception of rental reservations for SR vehicles at each station. A rental reservation for an SR vehicle refers to reserving the rental of an SR vehicle.

[0032] Any person using the MSS must return an SR vehicle after renting it. A system in which the location where the SR vehicle is rented and the location where it is returned are the same is called a round-trip system. A system in which the location where the SR vehicle is rented and the location where it is returned can be different is called a one-way system. In embodiments of the present invention, the one-way system is adopted unless otherwise specified. However, in some specific examples described below in which the location where the SR vehicle is rented and the location where it is returned are the same, the round-trip system may be considered to be adopted.

[0033] Database DB2 is a large-capacity recording medium used by MSS management device 30. MSS management device 30 can store any information in database DB2 and can also read any information stored in database DB2. Database DB2 may be built into MSS management device 30.

[0034] The parking lot server device 40 is a server device used, operated, and managed by a parking service provider. The parking service provides a parking lot that can accommodate a large number of vehicles. To avoid confusion with SR vehicles, vehicles parked in the parking lot will be referred to as automobiles below. The subject vehicle V1 belongs to the automobile category. The parking lot server device 40 manages the parking status of automobiles in the parking lot and accepts and handles parking space reservations. A parking space refers to a location where an automobile is parked, and reserving a parking space refers to reserving the use of a parking space.

[0035] A special wandering support service is provided by the wandering support device 20. Each person who receives the wandering support service is registered in the wandering support device 20 in a user registration step. The server-side controller 21 executes the user registration step.

[0036] FIG. 6 shows the registered user table TBL1 created in the user registration process and stored in the database DB1. Any person of interest who wishes to receive the travel support service provides the necessary registration information to the travel support device 20 through any terminal device. This allows the person of interest to be registered with the travel support device 20. The registration information for the person of interest includes the person's personal information, contact information, payment information, and additional information. The personal information of the person of interest includes the person's name, address, age, and gender. The contact information for the person of interest represents the person's contact information when the travel support device 20 transmits any information to the person of interest. The telephone number or email address assigned to the terminal device owned by the person of interest, or the account information for an instant messenger running on the terminal device, corresponds to the contact information for the person of interest. Information sent to the contact information of the person of interest in the travel support device 20 is transmitted to the person of interest via the terminal device owned by the person of interest.

[0037] While receiving the travel assistance service, the person of interest pays a fee (cost) for receiving some service to the service provider. The payment information of the person of interest indicates the payment method for the payment. For example, the payment information of the person of interest is account information of a financial institution associated with the person of interest, credit card information, or electronic money account information. The payment is made in legal tender or virtual currency, and virtual currency may be classified as electronic money. The additional information includes personal information, contact information, and other information not classified as payment information (such as preference information).

[0038] The wandering support device 20 assigns a unique identification ID to each person registered in the wandering support device 20, and stores each person's personal information, contact information, payment information and additional information in a registered person table TBL1 in association with the corresponding identification ID.

[0039] Assume that user U1 has completed the user registration process and has already been registered with the travel support device 20. Therefore, user U1's personal information (name, address, age, and gender), contact information, payment information, and additional information are stored in the registrant table TBL1 in association with the user U1's identification ID. The contact information for user U1 is, for example, the telephone number or email address assigned to the terminal device 10A, or account information for an instant messenger running on the terminal device 10A.

[0040] After the user registration process, the user device 10 executes the travel assistance application program to transmit the identification ID of user U1 to the travel assistance device 20. As a result, the server-side controller 21 associates and recognizes the user device 10 and user U1 (recognizing that the user of the user device 10 is user U1).

[0041] FIG. 7 shows management table TBL2 created by the MSS management device 30. Management table TBL2 is a management table for the SR vehicle group managed by the MSS management device 30 and is stored in database DB2. While various management methods can be used to manage each SR vehicle, in this embodiment of the present invention, each SR vehicle is managed using management table TBL2 as shown in FIG. 7. For concrete explanation, the multiple stations referred to in this embodiment of the present invention are considered to include stations ST[1] to ST[m]. m is an integer greater than or equal to 2, for example, several tens to several thousand. The SR vehicle group managed by the MSS management device 30 consists of SR vehicles SV[1] to SV[n]. n is an integer greater than or equal to 2, for example, several hundred to several tens of thousands. n is generally much larger than m. Management table TBL2 stores SR vehicle type information, current location information, current status, and reservation information for each SR vehicle.

[0042] The type information of the SR vehicle SV[i] indicates the type of the SR vehicle SV[i] (whether the SR vehicle SV[i] is a bicycle, an electric motorcycle, an electric kick scooter, or a small electric vehicle). Although not shown in FIG. 7 , the type information of the SR vehicle SV[i] indicates the characteristics of the SR vehicle SV[i] (size, color, etc.) in addition to the type of the SR vehicle SV[i]. i represents any integer.

[0043] The current location information of SR vehicle SV[i] indicates the current location of SR vehicle SV[i]. If SR vehicle SV[i] is not currently rented and is stored at station ST[p], the current location information of SR vehicle SV[i] indicates that the current location of SR vehicle SV[i] is station ST[p]. p represents any integer. If SR vehicle SV[i] is currently rented, the current location information of SR vehicle SV[i] does not contain any significant information.

[0044] The current status of SR vehicle SV[i] indicates whether SR vehicle SV[i] is currently being rented out. For any SR vehicle, the state in which the SR vehicle is not currently being rented out is referred to as an available state, and the state in which the SR vehicle is currently being rented out to any person is referred to as a rented state. The current status has a value of "0" or "1". When SR vehicle SV[i] is available, the current status of SR vehicle SV[i] has a value of "0". When SR vehicle SV[i] is in a rented state, the current status of SR vehicle SV[i] has a value of "1".

[0045] The reservation information for SR vehicle SV[i] indicates whether a rental reservation has been made for SR vehicle SV[i] (i.e., whether the rental of SR vehicle SV[i] has been reserved). When the rental of SR vehicle SV[i] has been reserved, details of the reservation are included in the reservation information for SR vehicle SV[i]. The details of the reservation include the scheduled time period for the rental of SR vehicle SV[i], reservation party information for identifying the person who made the rental reservation, etc.

[0046] The following describes first to third embodiments related to the travel support service. The above matters apply to the following first to third embodiments unless otherwise specified and unless there is a contradiction. If there are any matters in the first to third embodiments that contradict the above matters, the descriptions in the first to third embodiments may take precedence.

[0047] The wandering support device 20 (server-side controller 21) can make various suggestions to user U1 through the user-side device 10, and specific examples of the suggestions are shown in the following embodiments. The server-side controller 21 outputs (transmits) information to the user-side device 10 to realize the suggestions, thereby actually realizing the suggestions. Therefore, in the following description, a suggestion made by the wandering support device 20 or the server-side controller 21 to user U1 includes the wandering support device 20 or the server-side controller 21 outputting (transmitting) information to the user-side device 10 to realize the suggestions, or corresponds to the wandering support device 20 or the server-side controller 21 outputting (transmitting) information to the user-side device 10 to realize the suggestions. Furthermore, the transmission of a signal or information from one device to another device and the output of a signal or information from one device to another device are synonymous.

[0048] <<First Embodiment>> A first embodiment of the present invention will be described. In the first embodiment, an operation that functions beneficially while a user U1 is traveling toward a destination in the user's vehicle V1 will be mainly described. Through this operation, the user U1 is assisted in moving around after getting off the user's vehicle V1.

[0049] FIG. 8 is an operational sequence diagram of the excursion support system according to the first embodiment. First, user U1 gets into his / her vehicle V1 and inputs outing content information 1110 into the user device 10. The outing content information 1110 includes information indicating the destination that user U1 wants to visit and information indicating the number of accompanying persons. A companion refers to a person who will be visiting the destination with user U1, and they get into user U1's vehicle V1 together. If there is no accompanying person, the number of accompanying persons is zero. Upon receiving the outing content information 1110, the user controller 11 transmits outing content information 1120 to the excursion support device 20. The excursion support device 20 receives the outing content information 1120, and the server controller 21 recognizes the outing content information 1120. The outing content information 1120 includes information indicating the destination and information indicating the number of passengers. The number of passengers in the outing content information 1120 is the number of people in a group including user U1, and represents the total number of passengers aboard user U1's vehicle V1. Therefore, the number of passengers in the outing details information 1120 has a value obtained by adding 1 to the number of accompanying persons of user U1.

[0050] Here, when user U1 gets into his / her vehicle V1, user U1 is assumed to be the driver of the vehicle V1 (however, user U1 may also be a passenger other than the driver). After user U1 inputs the outing content information 1110 into the user device 10, user U1 starts the vehicle V1 and performs a driving operation to drive the vehicle V1 toward the destination. After receiving the outing content information 1110, the user device 10 starts a navigation operation using the display screen 14a and speaker 14b to guide user U1 along the driving route of the vehicle V1 to the destination. Note that the vehicle V1 may also be driven autonomously toward the destination.

[0051] After starting navigation operation, as the vehicle V1 travels toward the destination, the user controller 11 continuously monitors whether the vehicle position has entered a local area. The vehicle position refers to the position of the vehicle V1. The user controller 11 recognizes the vehicle position based on the output signal of a position detection sensor mounted on the vehicle V1 or the user device 10. The position detection sensor detects the vehicle position by receiving signals from multiple GPS (Global Positioning System) satellites, for example. The local area is an area set by the user controller 11 based on the destination. Here, the local area is defined as an area within a circle centered on the destination. The radius of the local area is, for example, 2 km. However, the size and shape of the local area may be arbitrary. The destination assumed in the first embodiment is a downtown area or a tourist destination, and the local area is defined as having numerous parking lots and numerous stations in the MSS.

[0052] When the user-side controller 11 determines that the user U1 in the user's vehicle V1 has entered the local area from outside the local area, the user-side controller 11 determines that the user U1 in the user's vehicle V1 has arrived in the local area. When the user-side controller 11 determines that the user U1 in the user's vehicle V1 has arrived in the local area, the user-side controller 11 transmits a local area entry signal 1130 indicating this to the travel assistance device 20. The local area entry signal 1130 is received by the travel assistance device 20. In response to receiving the local area entry signal 1130, the server-side controller 21 executes a search process 1140. In the search process 1140, the server-side controller 21 sets a search area that includes the destination, and searches for and extracts one or more recommended parking lots from among multiple parking lots located within the search area. The size and shape of the search area may be predetermined, or may be dynamically set according to the characteristics of the area including the destination.

[0053] A recommended parking lot is a parking lot recommended by the server-side controller 21 as a parking lot for parking the host vehicle V1. The server-side controller 21 recognizes a parking lot that satisfies at least the following first and second recommended conditions as a recommended parking lot. Any parking lot will be referred to as a featured parking lot, and the relationship between the featured parking lot and each recommended condition will be explained below.

[0054] The distance between the parking lot of interest and the destination is the reference distance d ＲＥＦ１ The first recommendation condition is met for the parking lot of interest only if the reference distance d from the parking lot of interest is: ＲＥＦ２ The second recommendation condition is met for the parking lot of interest only when one or more stations exist within the reference distance d. ＲＥＦ１ and d ＲＥＦ２ is a predetermined distance that is smaller than the radius of the local area. The server-side controller 21 can determine whether the first and second recommended conditions for the target parking lot are met based on map information that indicates the locations of each parking lot and each station within an area including the local area. The map information may be stored in a database DB1. The server-side controller 21 may also read out map information from any database connected to the communication network NET.

[0055] The server-side controller 21 can determine whether the first and second recommended conditions are met for each parking lot within the search area based on the map information. In other words, the server-side controller 21 can extract one or more recommended parking lots from among the multiple parking lots based on the relative positions of the destination, the multiple parking lots within the search area, and the multiple stations within the search area. In other words, the server-side controller 21 can extract one or more recommended parking lots from among the multiple parking lots based on the location of the destination, the locations of the multiple parking lots within the search area, and the locations of the multiple stations within the search area. Note that the location of a parking lot can be considered to refer to the center location of the parking lot, and the location of a station can be considered to refer to the center location of the station (the same applies to the second embodiment described below).

[0056] Please refer to Fig. 9. In the example of Fig. 9, the multiple parking lots located within the search area include parking lots 611 to 614, and the multiple stations located within the search area include stations 621 to 625. Stations 621 to 625 are five stations included in the above-mentioned stations ST[1] to ST[m] (see Fig. 7). Parking lots 611 to 613 are located at a reference distance d from the destination. ＲＥＦ１ Parking lot 614 is located within a reference distance d ＲＥＦ１ Therefore, the parking lots 611 to 613 satisfy the first recommended condition, whereas the parking lot 614 does not. ＲＥＦ２ The stations 621 and 622 are located within the parking lot 612 at a reference distance d ＲＥＦ２ Therefore, the parking lots 611 and 612 satisfy the second recommendation condition. On the other hand, the parking lot 613 is located at a reference distance d ＲＥＦ２ 9, of the parking lots 611 to 614, only the parking lots 611 and 612 can be recommended parking lots.

[0057] The server-side controller 21 preferably identifies a parking lot that satisfies the third recommended condition in addition to the first and second recommended conditions as a recommended parking lot. In the first embodiment, parking lots that satisfy the first to third recommended conditions are identified as recommended parking lots. ＲＥＦ２ The third recommendation condition is met for the parking lot of interest only if the parking lot of interest is within the search area. In other words, whether the third recommendation condition is met or not depends on the availability of each SR vehicle handled at each station within the search area.

[0058] The third recommended condition will now be explained. The server-side controller 21 may be authorized to directly read the contents of management table TBL2 (see FIG. 7), and the server-side controller 21 determines whether the third recommended condition is met based on management table TBL2. If the server-side controller 21 is not authorized, the server-side controller 21 may obtain, via the MSS management device 30, the information in management table TBL2 that is necessary for determining whether the third recommended condition is met.

[0059] For convenience, a parking lot that satisfies the first and second recommended conditions is referred to as a verification parking lot, and a reference distance d from the verification parking lot is ＲＥＦ２ A station within the range is called an available verification station. When an available verification station has stored SR vehicles equal to or greater than the number of passengers with a current status of "0", the verification parking lot satisfies the third recommendation condition. When there is no available verification station with stored SR vehicles equal to or greater than the number of passengers with a current status of "0", the verification parking lot does not satisfy the third recommendation condition.

[0060] Consider the example of FIG. 9 . In the example of FIG. 9 , parking lots 611 and 612 are each verification parking lots. Stations 621 and 622 are vacancy verification stations for parking lot 611. Stations 622 and 623 are vacancy verification stations for parking lot 612. Assume that at the time of execution of search process 1140, station 621 stores SR vehicles equal to or greater than the number of passengers with a current status of "0." Assume that at the time of execution of search process 1140, stations 622 and 623 do not store SR vehicles equal to or greater than the number of passengers with a current status of "0" (i.e., there are no vacant spaces for the number of passengers). In this case, parking lot 611 satisfies the third recommendation condition, while parking lot 612 does not. As a result, of parking lots 611 and 612, parking lot 611 is extracted as a recommended parking lot, while parking lot 612 is not extracted as a recommended parking lot. In more detail, the determination of whether the third recommended condition is satisfied may be performed taking into consideration the reservation information in the management table TBL2 (see FIG. 7). In the example of FIG. 9, only parking lot 611 is extracted as a recommended parking lot, but if there are multiple parking lots that satisfy the first to third recommended conditions, multiple recommended parking lots will be extracted. As described above, there are multiple types of SR vehicles, and vehicle type information indicating the type of SR vehicle that user U1 wishes to use may be determined in advance. User U1's vehicle type information may be included in the additional information associated with user U1 in the registrant table TBL1. The vehicle type information may be stored in memory 12 based on operations input by user U1 to the user device 10. When the vehicle type information is specified (when the vehicle type information is stored in the registrant table TBL1 or memory 12), the SR vehicles with a current status of "0" that are sufficient for the number of passengers or more and that are relevant to whether the third recommended condition is met are SR vehicles with a current status of "0" that are sufficient for the number of passengers or more and that are of the type indicated in the vehicle type information. In other words, when user U1 specifies a type of SR vehicle, the fulfillment of the third recommended condition may be determined based on the availability of SR vehicles of the specified type.

[0061] Once one or more recommended parking lots have been searched for and extracted in the search process 1140, the server-side controller 21 transmits recommended parking lot information 1150 to the user-side device 10 (see FIG. 8). At this time, the server-side controller 21 transmits the recommended parking lot information 1150 to the user-side device 10 together with an interrupt command signal that instructs the user-side device 10 to perform an interrupt process. The recommended parking lot information 1150 includes information indicating the location of each recommended parking lot extracted in the search process 1140. When the user-side device 10 receives the recommended parking lot information 1150 together with the interrupt command signal, the user-side controller 11 performs an inquiry process 1160 as the interrupt process.

[0062] In the inquiry process 1160, the user-side controller 11 notifies the user U1 of information about one or more recommended parking lots (such as the locations of the recommended parking lots) using the HMI 14. In the single extraction case in which only one recommended parking lot is extracted in the search process 1140, the user-side controller 11 involved in the inquiry process 1160 inquires of the user U1 whether it is OK to set the one recommended parking lot as the target parking lot. In the multiple extraction case in which multiple recommended parking lots are extracted in the search process 1140, the user-side controller 11 involved in the inquiry process 1160 inquires of the user U1 which of the multiple recommended parking lots to select as the target parking lot. The target parking lot refers to the parking lot where the host vehicle V1 will be parked, and strictly speaking, at the inquiry process 1160, it refers to the parking lot where the host vehicle V1 is planned to be parked.

[0063] The user U1 inputs response information 1164, including a response to the inquiry, into the user device 10 using the HMI 14. There may be cases where the user U1 responds that they will not set any of the recommended parking lots as target parking lots. In such cases, the assistance process shown in FIG. 8 may be terminated or the search conditions for recommended parking lots may be relaxed, depending on the user U1's instructions. However, such cases are not considered here. Therefore, in the single extraction case, the user U1 agrees to setting one of the extracted recommended parking lots as the target parking lot, and this agreement is included in the response information 1164. In the multiple extraction case, the user U1 selects one of the extracted recommended parking lots as the target parking lot, and the selection is included in the response information 1164. Upon receiving the response signal 1164, the user controller 11 performs a setting process 1170. In the setting process 1170, the user controller 11 sets one recommended parking lot as the target parking lot based on the response information 1164 and in accordance with the user U1's response.

[0064] After the setting process 1170, the user controller 11 uses the display screen 14a and speaker 14b to start a navigation operation that guides the user U1 along the driving route of the user's vehicle V1 to the target parking lot. Meanwhile, after or during the setting process 1170, the user controller 11 transmits target parking lot information 1180 to the travel assistance device 20. The travel assistance device 20 receives the target parking lot information 1180. The target parking lot information 1180 indicates that a recommended parking lot has been set as the target parking lot. If multiple recommended parking lots are extracted in the search process 1140, the target parking lot information 1180 indicates which of the multiple recommended parking lots has been set as the target parking lot. When transmitting the target parking lot information 1180, the user controller 11 also transmits a request signal 1182 to the travel assistance device 20, requesting a rental reservation for an SR vehicle to be used when traveling from the target parking lot to the destination.

[0065] In response to receiving the target parking lot information 1180 or the request signal 1182 at the travel support device 20, the server-side controller 21 executes the plan creation process 1200. The server-side controller 21 involved in the plan creation process 1200 calculates the time when the vehicle V1 will arrive at the target parking lot as the estimated arrival time t based on the positional relationship between the vehicle's current position and the target parking lot. Ａ１ In the plan creation process 1200, the server-side controller 21 estimates the estimated arrival time t Ａ１ A route plan P_A is created based on first planning information including the location of the target parking lot and the location of the destination. The first planning information also includes information specifying the location of each station in an area (e.g., a local area) that includes the target parking lot and the destination, and may further include a management table TBL2 (see FIG. 7).

[0066] The target station is identified in the plan creation process 1200. The target station is a station that the user U1 is scheduled and planned to pass through in the route plan P_A. ＲＥＦ２ A station that is within the range and has SR vehicles stored therein equal to or greater than the number of passengers with a current status of "0" corresponds to the target station and has already been identified in the search process 1140.

[0067] The route plan P_A is a user U1's action plan, including a planned route for user U1's travel, and includes a timetable for user U1's actions. After getting off his / her vehicle V1, part of user U1's travel will involve travel using SR vehicles. Therefore, the route plan P_A includes an MSS usage plan P_X. The usage plan P_X indicates the station where user U1 will rent an SR vehicle, the time period during which user U1 will use the SR vehicle (the start and end times of rental), and the planned number of SR vehicles that user U1 will rent. The number of SR vehicles to be rented corresponds to the number of passengers. However, if the number of occupants per SR vehicle to be rented is two or more (if the SR vehicle to be rented is a multi-occupant SR vehicle), the number of SR vehicles to be rented may be determined taking into account the occupant capacity of the SR vehicle. The route plan P_A includes at least user U1's action plan from the target parking lot to the destination. Therefore, the usage plan P_X includes the MSS usage plan (SR vehicle usage plan) of user U1 on the journey from the target parking lot to the destination.

[0068] FIG. 10 shows an example of a route plan 640_A for user U1 to reach the destination from the parking lot 611. The parking lot 611 and station 621 in FIG. 10 are the same as the parking lot 611 and station 621 shown in FIG. 9. The parking lot 611 is assumed to be a recommended parking lot searched for in the search process 1140 and set as the target parking lot. In the example of FIG. 10, the route plan 640_A corresponds to the route plan P_A. Note that in this specification and drawings, any time is assumed to be a time within a day, and time is expressed using a 24-hour notation. Therefore, for example, 12:55 is expressed as 12:55, and 13:00 is expressed as 13:00. In the route plan 640_A, the estimated arrival time t of the vehicle V1 at the parking lot 611 is calculated. Ａ１The route plan 640_A is scheduled for the user U1 to use the station 621 as the target station. In the route plan 640_A, the user U1 is scheduled to depart from the parking lot 611 for the station 621 at 13:00, travel on foot, and arrive at the station 621 at 13:10. The station 621 according to the route plan 640_A is located at a reference distance d from the parking lot 611. ＲＥＦ２ The station 621 related to the route plan 640_A is a station where SR vehicles with a current status of "0" or more than the number of passengers are stored at the time of execution of the plan creation process 1200.

[0069] In route plan 640_A, user U1 is scheduled to depart from station 621 for the destination at 13:15 and arrive at the destination at 13:45. Route plan 640_A also plans for user U1 to travel from station 621 to the destination on an electric scooter, which is an SR vehicle, rented at station 621. It is assumed that the destination has a station or port where the SR vehicle can be returned, and route plan 640_A also plans for user U1 to return the rented SR vehicle (electric scooter) at the destination when he or she arrives at the destination.

[0070] The route plan 640_A includes an action plan for the user U1 in steps 641 and 642. In the route plan 640_A, steps 641 and 642 occur in this order as time progresses. Step 641 is a step in which the user U1 travels from the parking lot 611 to the station 621. In step 641, the user U1 travels by foot. In step 642, the user U1 travels from the station 621 to the destination. In step 642, the user U1 travels by electric kickboard rented at the station 621. In the route plan 640_A, the required time and timetable for each of steps 641 and 642 are specified.

[0071] The usage plan P_X of the MSS in the route plan 640_A is the usage plan 640_X. The usage plan 640_X indicates that the user U1 will rent an SR vehicle for the number of passengers at the station 621. The usage plan 640_X specifies a time period during which the user U1 will rent an SR vehicle at the station 621. The time period during which the user U1 will rent an SR vehicle (target SR vehicle) at the station 621 is set based on the time period from the start time of step 642 to the end time of step 642, and either coincides with the reference time period or includes the reference time period and is slightly wider than the reference time period.

[0072] When the plan creation process 1200 creates a route plan P_A including an MSS usage plan P_X, the server-side controller 21 transmits a reservation inquiry signal 1210 to the MSS management device 30 (see FIG. 8 ). The reservation inquiry signal 1210 inquires whether a rental reservation of an SR vehicle is possible under the conditions of the usage plan P_X. The reservation inquiry signal 1210 is received by the MSS management device 30. The MSS management device 30 then determines whether a rental reservation of an SR vehicle is possible under the conditions of the usage plan P_X based on the management table TBL2 (see FIG. 7 ) and transmits a response signal 1220 indicating the determination result to the travel support device 20. Because the search process 1140 searches for a recommended parking lot that should be the target parking lot while taking into account the availability of SR vehicles, there is a high probability that a rental reservation will be determined to be possible. However, because the rental status of SR vehicles changes from moment to moment, or for some other reason, it may be determined that a rental reservation is not possible. If the MSS management device 30 determines that a rental reservation is not possible, devices 20 and 30 can compare and extract a plan that allows a rental reservation of an SR vehicle under conditions similar to those of the usage plan P_X. Below, we will only consider the case where it is determined that a rental reservation of an SR vehicle is possible under the conditions of the usage plan P_X. Note that the response signal 1220 also indicates the cost required to rent an SR vehicle under the conditions of the usage plan P_X.

[0073] When the travel support device 20 receives the response signal 1220, the server-side controller 21 transmits reservation availability information 1230 based on the response signal 1220 to the user-side device 10, and also transmits the route plan P_A. The route plan P_A is received by the terminal device 10A, and thereafter, the user U1 can refer to the route plan P_A on the terminal device 10A at any time. The reservation availability information 1230 includes information on the locations of stations at which the user U1 can make a rental reservation and information on SR vehicles at which the user U1 can make a rental reservation, as well as cost information. The cost information in the reservation availability information 1230 indicates the cost required for the user U1 to rent an SR vehicle under the conditions of the usage plan P_X. The cost information in the reservation availability information 1230 can be an estimate of the cost required for the user U1 to rent an SR vehicle under the conditions of the usage plan P_X. The stations at which the user U1 can make a rental reservation are target stations whose use is proposed to the user U1 according to the usage plan P_X. An SR vehicle that user U1 can reserve for rental is a target SR vehicle that is proposed for use to user U1. In the route plan P_A and the usage plan P_X, user U1 is scheduled to rent the target SR vehicle at the target station. The total number of candidates available for rental reservation may be one or may be two or more. For example, if an electric kick scooter and an electric bicycle are available as SR vehicles available for rental reservation, the electric kick scooter and the electric bicycle are two candidates available for rental reservation.

[0074] When the user device 10 receives the reservation availability information 1230 and the route plan P_A, the user controller 11 performs an inquiry process 1240. In the inquiry process 1240, the user controller 11 notifies the user U1 of reservation availability information 1242 corresponding to the reservation availability information 1230 using the HMI 14, and then asks the user U1 to select one of the candidates available for rental reservation. In the inquiry process 1240, the user controller 11 also notifies the user U1 of the route plan P_A. The selection made by the user U1 is input to the user device 10 via the HMI 14. When the total number of candidates available for rental reservation is one, the selection made by the user U1 is a selection of whether or not to accept that candidate. When the total number of candidates available for rental reservation is two or more, the user U1 selects one of the multiple candidates. Here, it is assumed that user U1 inputs response information 1246 to the user device 10 indicating consent to the usage plan P_X, which corresponds to one candidate for which a rental reservation is available, and that consent to the usage plan P_X is equivalent to consent to the route plan P_A. The content of the reservation availability information 1242 is the same as the content of the reservation availability information 1230. In other words, the controller 21 or 11 proposes to user U1, through notification of the reservation availability information 1242, that the target SR vehicle be rented at the target station under the conditions specified in the usage plan P_X. The notification of the reservation availability information 1242 also notifies user U1 of the above-mentioned cost information. The response information 1246 indicates user U1's consent to the usage plan P_X. More specifically, the response information 1246 indicates that user U1 agrees to the proposal to rent and use the target SR vehicle at the target station under the conditions specified in the usage plan P_X. This proposal can be considered to be a proposal from the travel support device 20 or the user device 10 to user U1.

[0075] Upon receiving the response information 1246, the user-side controller 11 transmits a usage request signal 1250 to the travel assistance device 20. The usage request signal 1250 conveys the contents of the response information 1246 to the travel assistance device 20. Therefore, the usage request signal 1250 indicates that the user U1 wishes to use the target station under the conditions defined in the usage plan P_X (to rent and use an SR vehicle at the target station). In the operational flow of FIG. 8 , the usage request signal 1250 corresponds to an agreement signal indicating that the user U1 agrees to the proposal (proposal from the device 20 or 10) based on the route plan P_A and the usage plan P_X. When the usage request signal 1250 is received by the travel assistance device 20, the server-side controller 21 transmits a reservation request signal 1260 to the MSS management device 30 in accordance with the usage request signal 1250. The reservation request signal 1260 is a signal requesting a rental reservation for an SR vehicle (a rental reservation for an SR vehicle to be provided to user U1) under the conditions of usage plan P_X. In other words, by transmitting the reservation request signal 1260, the server-side controller 21 outputs (requests) a rental reservation for an SR vehicle under the conditions of usage plan P_X to the MSS management device 30.

[0076] In response to receiving the reservation request signal 1260, the MSS management device 30 updates the reservation information in the management table TBL2 in accordance with the request content of the reservation request signal 1260, thereby confirming the rental reservation. The MSS management device 30 then transmits a response signal 1270 to the tour support device 20, indicating that the rental reservation in accordance with the request content of the reservation request signal 1260 has been confirmed. When the response signal 1270 is received by the tour support device 20, the server-side controller 21 transmits a reservation confirmation signal 1280 to the user-side device 10. The reservation confirmation signal 1280 indicates that the rental reservation for the SR vehicle has been confirmed as desired by user U1 (as desired in the usage request signal 1250). When the reservation confirmation signal 1280 is received by the user-side device 10, the user-side controller 11 executes notification processing 1290 using the HMI 14 to notify user U1 of the contents of the reservation confirmation signal 1280.

[0077] The user U1 then stops the vehicle V1 at the target parking lot, and then, while the vehicle V1 remains parked in the target parking lot, follows the route plan P_A and heads for the destination via the target station. After the user U1 arrives at the target parking lot, the terminal device 10A may perform a navigation operation to guide the user U1 from the target parking lot to the target station.

[0078] On the other hand, the server-side controller 21 performs a payment process 1300 at any timing after receiving the response signal 1270. In the payment process 1300, the server-side controller 21 performs payment of the parking fee PF and payment of the rental fee RF. The parking fee PF is the cost (compensation) for parking the vehicle V1 in the target parking lot and is the fee that the user U1 must pay to the operator of the target parking lot. The rental fee RF is the cost (compensation) for the user U1 renting an SR vehicle at the target station in accordance with the usage plan P_X and is the fee that the user U1 must pay to the operator of the MSS. In the payment process 1300, the server-side controller 21 completes payment of the parking fee PF by cooperating with the parking lot server device 40 based on the payment information of the user U1 (see FIG. 6). In the payment process 1300, the server-side controller 21 completes payment of the rental fee RF by cooperating with the MSS management device 30 based on the payment information of the user U1 (see FIG. 6). The user U1 can reduce the work required by the travel support device 20 by making all payments on the device side. At least one of the payment of the parking fee PF and the payment of the rental fee RF may be made by a connected service that is separately applied to the vehicle V1.

[0079] The first embodiment includes the following Examples EX1_1 to EX1_11. Unless otherwise specified and unless contradicted, the matters described above in the first embodiment are applied to the following Examples EX1_1 to EX1_11. However, in each Example, for matters that contradict the matters described above in the first embodiment, the description in that Example may take precedence. Furthermore, unless contradicted, matters described in any Example among Examples EX1_1 to EX1_11 can also be applied to any other Example (that is, any two or more Examples among multiple Examples can also be combined).

[0080] [Example EX1_1] Example EX1_1 will be described. In example EX1_1, a case CS11 is assumed in which the route plan 640_A in FIG. 10 is created as the route plan P_A and a rental reservation is made according to the usage plan 640_X in the route plan 640_A. The flow of operations from plan creation process 1200 onwards in case CS11 will be described. In case CS11, station 621 is the target station, and the SR vehicle that user U1 rents at the target station (621) is the target SR vehicle.

[0081] After the plan creation process 1200, the server-side controller 21 transmits a reservation inquiry signal 1210 to the MSS management device 30 to inquire whether a rental reservation of an SR vehicle is possible under the conditions of the usage plan 640_X. The MSS management device 30 then determines whether a rental reservation of an SR vehicle is possible under the conditions of the usage plan 640_X based on the management table TBL2. If it determines that a rental reservation of an SR vehicle is possible under the conditions of the usage plan 640_X, the MSS management device 30 transmits a response signal 1220 indicating the determination result to the excursion support device 20. The response signal 1220 also indicates the cost required to rent an SR vehicle under the conditions of the usage plan 640_X.

[0082] When the travel support device 20 receives the response signal 1220, the server-side controller 21 transmits reservation availability information 1230 based on the response signal 1220 along with the route plan 640_A to the user device 10. The route plan 640_A is received by the terminal device 10A, and the user U1 can subsequently refer to the route plan 640_A on the terminal device 10A at any time. The reservation availability information 1230 in case CS11 includes information on the location of the station 621. In case CS11, it is assumed that an electric kick scooter is available for reservation at the station 621. Then, the user device 10, which has received the reservation availability information 1230 and the route plan 640_A, performs an inquiry process 1240. In the inquiry process 1240, the user controller 11 notifies the user U1 of reservation availability information 1242 corresponding to the reservation availability information 1230 using the HMI 14. In notifying the user U1 of the reservation availability information 1242, the user controller 11 proposes to the user U1 that they rent an electric kickboard (target SR vehicle) at station 621 (target station) in accordance with the conditions of the usage plan 640_X. Furthermore, in the inquiry process 1240, the user controller 11 notifies the user U1 of the route plan 640_A. It is assumed that response information 1246 indicating that the user U1 will reserve an electric kickboard under the conditions of the usage plan 640_X is input to the user device 10. At this time, the response information 1246 indicates that the user U1 agrees to the proposal to rent and use the electric kickboard (target SR vehicle) at station 621 (target station) in accordance with the conditions of the usage plan 640_X. This proposal can be considered to be a proposal from the travel support device 20 or the user device 10 to the user U1.

[0083] Upon receiving the response information 1246, the user-side controller 11 transmits a usage request signal 1250 to the travel assistance device 20. The usage request signal 1250 indicates that user U1 wishes to rent and use an SR vehicle at the target station under the conditions set forth in the usage plan 640_X. When the usage request signal 1250 is received by the travel assistance device 20, the server-side controller 21 transmits a reservation request signal 1260 to the MSS management device 30 in accordance with the usage request signal 1250. The reservation request signal 1260 is a signal requesting a rental reservation for an SR vehicle (a rental reservation for an SR vehicle to be provided to user U1) under the conditions of the usage plan 640_X. In other words, by transmitting the reservation request signal 1260, the server-side controller 21 outputs (requests) a rental reservation for an SR vehicle under the conditions of the usage plan 640_X to the MSS management device 30.

[0084] In response to receiving the reservation request signal 1260, the MSS management device 30 updates the reservation information in the management table TBL2 according to the request content of the reservation request signal 1260, thereby confirming the rental reservation. After that, after transmitting and receiving a response signal 1270 and a reservation confirmation signal 1280, the user controller 11 executes a notification process 1290 to notify the user U1 of the contents of the reservation confirmation signal 1280 using the HMI 14. The vehicle V1 then proceeds toward the parking lot 611 and arrives at the parking lot 611. In case CS11, the user U1 parks the vehicle V1 in the parking lot 611, and then, while leaving the vehicle V1 parked in the parking lot 611, first heads toward the target station 621 according to the route plan 640_A. After the vehicle V1 arrives at the parking lot 611, the terminal device 10A may perform a navigation operation to guide the user U1 from the parking lot 611 to the station 621. User U1 in case CS11 rents the required number of electric scooters from station 621 according to usage plan 640_X and heads to the destination on the rented electric scooters. When user U1 in case CS11 arrives at the destination on the electric scooter, he or she returns the electric scooter to a station or port located at or near the destination according to the one-way system.

[0085] The operation of each device in Case CS11 will be summarized with reference to FIGS. 8 to 10. As described above, the parking lot 611 is a recommended parking lot searched for in the search process 1140 and set as the target parking lot. When the user U1 in his / her vehicle V1 (in other words, the vehicle V1 in which the user U1 is riding) arrives at a local area set based on the destination, the server-side controller 21 receives a local area entry signal 1130 and executes the search process 1140. In the search process 1140, the server-side controller 21 identifies the parking lot 611 as a recommended parking lot based on the location of the destination (see FIG. 9). The server-side controller 21 proposes to the user U1, via the user-side device 10 (using the query process 1160), that the vehicle V1 be parked in the parking lot 611 (this proposal is referred to as a parking lot proposal). The parking lot proposal can be interpreted as a proposal for a recommended parking lot (i.e., a proposal for a candidate target parking lot), but it can also be interpreted as a proposal for the target parking lot, given that the recommended parking lot is set as the target parking lot. In addition, the server-side controller 21 creates a route plan 640_A including a usage plan 640_X of the MSS in the plan creation process 1200. The usage plan 640_X identifies stations 621 (target stations) that can be used by the user U1 to travel to the destination after getting off the vehicle V1 in the parking lot 611. The server-side controller 21 then proposes the use of the station 621 to the user U1 through the user-side device 10 (using the query process 1240) (this proposal is referred to as a station proposal). In other words, when the user U1 in the vehicle V1 (in other words, the vehicle V1 in which the user U1 is riding) arrives in the local area, the server-side controller 21 makes a parking lot proposal and a station proposal through the user-side terminal 10. The server-side controller 21 outputs (transmits) information (1150, 1230, P_A, etc.) for realizing the parking lot proposal and the station proposal to the user-side device 10, thereby actually realizing the parking lot proposal and the station proposal.

[0086] In a reference method that does not use the travel assistance system of the first embodiment, the user U1 or a passenger must search for a suitable parking lot at some point along the way to the destination in the vehicle V1, and must also separately search for a suitable station near the parking lot. When the travel assistance system of the first embodiment is used, the travel assistance device 20 performs a single search for a suitable parking lot and a suitable station according to the location of the destination when the vehicle V1 approaches the destination, and the search results are then suggested to the user U1, which is highly convenient and saves the user U1 or a passenger time. Furthermore, by finding a suitable parking lot and a suitable station according to the location of the destination, the user can smoothly arrive at the destination.

[0087] The reduction in the effort of the user U1 or the passengers promotes the use of the travel assistance system of the first embodiment. The promotion of the use of the travel assistance system of the first embodiment leads to the promotion of the behavior of switching from personal cars to SR vehicles for travel. This is because the CO ２ Emissions and CO2 when parking a private car in crowded conditions ２ This is expected to contribute to reducing emissions. Also, if more people park their cars in parking lots relatively far from the city center and then head to the city center in SR vehicles, it is expected that congestion in parking lots in the city center will be alleviated. In addition, it will lead to the promotion of the use of SR vehicles, which have been gaining popularity in recent years, and will also contribute to the realization of smart cities.

[0088] In the search process 1140, the server-side controller 21 sets a search area based on the location of the destination. The server-side controller 21 can then extract one or more recommended parking lots from the multiple parking lots based on the relative positions of the destination, the multiple parking lots within the search area, and the multiple stations within the search area. In other words, the server-side controller 21 can extract one or more recommended parking lots from the multiple parking lots based on the location of the destination, the locations of the multiple parking lots within the search area, and the locations of the multiple stations within the search area. Information (1150) indicating one or more recommended parking lots is output to the user-side device 10, thereby notifying the user U1 of the one or more recommended parking lots via the user-side device 10. Based on the user U1's response to the notification (based on the target parking lot information 1180), the server-side controller 21 identifies one of the one or more recommended parking lots as the target parking lot.

[0089] By taking the above positional relationship into consideration, it is possible to extract as a recommended parking lot an appropriate parking lot that will allow user U1 to smoothly reach the destination.

[0090] In addition to the above-mentioned locational relationships, the server-side controller 21 extracts one or more recommended parking lots based on the availability of SR vehicles at each of the stations within the search area. The locational relationships affect whether the first and second recommendation conditions are met. The availability of SR vehicles affects whether the third recommendation condition is met. In the example of FIG. 9 , based on the locational relationships between the destination, parking lots 611-614, and stations 621-625, parking lots 611 and 612 respectively meet the first and second recommendation conditions. However, of parking lots 611 and 612, only parking lot 611 meets the third recommendation condition, so parking lot 611 is recommended, while parking lot 612 is not. In the example of FIG. 9 , the availability at station 621 satisfies the third recommendation condition for parking lot 611 (sufficient availability). The availability at station 622 does not meet the third recommendation condition for parking lots 611 and 612. The availability of parking spaces at station 623 does not satisfy the third recommendation condition for parking lot 612. Therefore, only parking lot 611 is extracted as a recommended parking lot.

[0091] Cooperation between the travel assistance device 20 and the MSS management device 30 enables parking lot and station proposals that take into account the availability of SR vehicles, resulting in high convenience. Even if there are SR vehicle vacancies when user U1 is located far from the destination, there is a risk that there will be no SR vehicle vacancies by the time the user's vehicle V1 reaches the destination. In the first embodiment, parking lot and station proposals are made taking into account the availability of SR vehicles when the user's vehicle V1 reaches the local area, thereby reducing such risk. Furthermore, the MSS operator may wish to avoid reservations for use long into the future in order to increase the operational efficiency of SR vehicles. The method of the first embodiment can appropriately address such circumstances.

[0092] After the parking lot proposal and station proposal, when a usage request signal 1250 indicating a desire to use station 621 is received, the server-side controller 21 transmits a reservation request signal 1260 to the MSS management device 30. As a result, a rental reservation of an SR vehicle (target SR vehicle) according to usage plan 640_X is requested (output) from the server-side controller 21 to the MSS management device 30.

[0093] In other words, when the user approaches the destination, the search for an appropriate parking lot and station according to the location of the destination and the reservation for the rental of an SR vehicle are carried out all by the travel support device 20, which greatly reduces the effort required by user U1 or passengers.

[0094] [Example EX1_2] Example EX1_2 will be described. Following the flow shown in FIG. 8 , a case in which user U1 parks his / her vehicle V1 in a target parking lot and rents an SR vehicle (target SR vehicle) at a target station is referred to as case CS12a. In case CS12a, the travel support device 20 requests the MSS management device 30 to make a reservation for renting an SR vehicle under the conditions of the usage plan P_X by sending and receiving a reservation request signal 1260. In contrast, a case in which user U1 parks his / her vehicle V1 in a target parking lot and rents an SR vehicle (target SR vehicle) at a target station under the same conditions as case CS12a, without using the travel support device 20, is referred to as case CS12b. The only difference between case CS12a and case CS12b is whether or not the travel support device 20 is used. In case CS12b, the travel support device 20 does not request the MSS management device 30 to make a reservation for renting an SR vehicle by sending a reservation request signal 1260.

[0095] In case CS12a, the server-side controller 21 grants user U1 a benefit that cannot be obtained in case CS12b. This provides user U1 with an incentive to use the wandering support system. As a result, use of the wandering support system is promoted. The actions and effects of promoting use of the wandering support system are as described in Example EX1_1.

[0096] The benefit according to the embodiment EX1_2 may include a parking fee reduction. The parking fee reduction is a reduction in the cost of parking the user's vehicle V1 in the target parking lot. In the case CS12b, when the user U1 parks the user's vehicle V1 in the target parking lot under certain parking conditions, the fee that the user U1 must pay to the operator of the target parking lot is set as the basic parking fee PF ＲＥＦ In case CS12a, when the parking fee reduction is implemented, the fee that the user U1 must pay to the operator of the target parking lot when the user U1 parks his / her vehicle V1 in the target parking lot under the specific parking conditions is the reduced parking fee PF ＬＯＷ Reduced parking fee PF ＬＯＷ is the basic parking fee PF ＲＥＦ Lower. For example, ＬＯＷ =PF ＲＥＦ-ΔPF" or "PF ＬＯＷ = (1-k ＰＦ ) x PF ＲＥＦ ". ΔPF represents the reduced fee. "ΔPF>0" holds. k ＰＦ represents the discount rate. ＰＦ If the parking fee is reduced, the server-side controller 21 calculates the reduced parking fee PF in the payment process 1300 (see FIG. 8). ＬＯＷ is set to the parking fee PF.

[0097] As shown in Figure 11 (a), the parking fee is reduced only when signals 1410 and 1412 are transmitted and received between the travel assistance device 20 and the parking lot server device 40. The signal 1410 is a signal requesting permission to reduce the parking fee, and is transmitted from the travel assistance device 20 (server-side controller 21) and received by the parking lot server device 40. The signal 1410 includes the reduced parking fee PF ＬＯＷ Information indicating the difference (PF ＲＥＦ -PF ＬＯＷ After receiving signal 1410, parking lot server device 40 can transmit signal 1412 to wandering support device 20. Signal 1412 indicates that the parking fee reduction is permitted. When wandering support device 20 receives signal 1412, server-side controller 21 reduces the parking fee in the subsequent payment process 1300.

[0098] Alternatively, the parking fee reduction may be implemented on the premise that a contract permitting the parking fee reduction has been concluded in advance between the operator of the travel assistance device 20 and the operator of the target parking lot. If such a contract has been concluded in advance, the parking fee reduction may be implemented without the need to send and receive signals 1410 and 1412. When the parking fee reduction is implemented, the server-side controller 21 may notify the user U1 through the user-side device 10 at any timing (for example, in the inquiry process 1160 or 1240) of information indicating that the parking fee reduction will be implemented.

[0099] The benefit according to the embodiment EX1_2 may include a rental fee reduction. The rental fee reduction is a reduction in the cost for the user U1 to rent an SR vehicle at the target station in accordance with the usage plan P_X. In the case CS12b, the cost (compensation) for the user U1 to rent an SR vehicle according to certain rental conditions, which is the fee that the user U1 must pay to the operator of the MSS, is set as the basic rental fee RF. ＲＥＦ When the rental fee reduction is implemented in case CS12a, the cost (compensation) for the user U1 renting the SR vehicle under the specific rental conditions, which is the fee that the user U1 should pay to the operator of the MSS, is the reduced rental fee RF ＬＯＷ Reduced lending fee RF ＬＯＷ is the basic rental fee RF ＲＥＦ Lower. For example, "RF ＬＯＷ = RF ＲＥＦ -ΔRF” or “RF ＬＯＷ = (1-k ＲＦ ) x RF ＲＥＦ ". ΔRF represents the reduced fee. "ΔRF>0" holds. k ＲＦ represents the discount rate. ＲＦ If the rental fee is reduced, the server-side controller 21 executes the payment process 1300 (see FIG. 8) to calculate the reduced rental fee RF ＬＯＷ is set as the rental fee RF.

[0100] 11(b), the rental fee is reduced only when signals 1420 and 1422 are transmitted and received between the travel assistance device 20 and the MSS management device 30. The signal 1420 is a signal requesting permission to reduce the rental fee, and is transmitted from the travel assistance device 20 (server-side controller 21) and received by the MSS management device 30. The signal 1420 includes a reduced rental fee RF ＬＯＷ Information or difference (RF ＲＥＦ -RF ＬＯＷ) is included. After receiving signal 1420, signal 1422 can be sent from MSS management device 30 to migration support device 20. Signal 1422 indicates that the implementation of a rental fee reduction is permitted. When signal 1422 is received by migration support device 20, server-side controller 21 implements the rental fee reduction in the subsequent settlement process 1300. Signal 1420 may be included in reservation inquiry signal 1210 and signal 1422 may be included in response signal 1220 (see FIG. 8). Alternatively, signal 1420 may be included in reservation request signal 1260 and signal 1422 may be included in response signal 1270 (see FIG. 8).

[0101] Alternatively, the rental fee reduction may be implemented on the premise that a contract permitting the rental fee reduction has been concluded in advance between the operator of the travel assistance device 20 and the operator of the MSS. If such a contract has been concluded in advance, the rental fee reduction may be implemented without the need to send and receive signals 1420 and 1422. When the rental fee reduction is implemented, the server-side controller 21 may notify the user U1 through the user-side device 10 at any timing (for example, in the inquiry process 1240) of information indicating that the rental fee reduction will be implemented.

[0102] As shown in FIG. 12, the server-side controller 21 includes a fee adjustment unit 21 as one of its functional blocks. ＦＥＥ The fee adjustment unit 21 ＦＥＥ This performs the processing required to implement the parking fee reduction (including the transmission and reception of signals 1410 and 1412) and the processing required to implement the rental fee reduction (including the transmission and reception of signals 1420 and 1422).

[0103] The reduction in parking fees or rental fees provides an incentive for user U1 to use the mobility support system. As a result, the use of the mobility support system is promoted. The actions and effects of promoting the use of the mobility support system are as described in Example EX1_1.

[0104] The benefit according to embodiment EX1_2 may be either a parking fee reduction or a rental fee reduction, or may include both a parking fee reduction and a rental fee reduction. When the benefit includes both a parking fee reduction and a rental fee reduction, the transmission and reception of the above-mentioned signals 1410 and 1412 and the transmission and reception of signals 1420 and 1422 may be performed. The reduction fee (amount of reduction) for the parking fee reduction may be different when the benefit includes both a parking fee reduction and a rental fee reduction and when the benefit includes only a parking fee reduction. Alternatively, the reduction fee (amount of reduction) for the rental fee reduction may be different when the benefit includes both a parking fee reduction and a rental fee reduction and when the benefit includes only a rental fee reduction. To realize these differences, the fee adjustment unit 21 ＦＥＥ The parking fee reduction and rental fee reduction may be determined based on a previously concluded tripartite contract. A tripartite contract refers to a contract between the operator of the mobility assistance device 20, the operator of the target parking lot, and the operator of the MSS. If the benefit includes both a parking fee reduction and a rental fee reduction, the parking lot server device 40 and the MSS management device 30 may be notified that both the parking fee reduction and the rental fee reduction will be provided by adding information indicating that the benefit includes both a parking fee reduction and a rental fee reduction to signals 1410 and 1420. The benefit is not limited to a parking fee reduction and a rental fee reduction. For example, the benefit may include a coupon that can be used at any market or store. The coupon may be an electronic voucher or discount coupon. Coupons are also sometimes referred to as points.

[0105] [Embodiment EX1_3] Embodiment EX1_3 will be described. In embodiment EX1_3, only case CS13 is assumed in which user U1 parks his / her vehicle V1 in the target parking lot and rents an SR vehicle (target SR vehicle) at the target station, following the flow shown in FIG. 8. Case CS13 is the same as case CS12a described in embodiment EX1_2. As described above, the server-side controller 21 includes a fee adjustment unit 21 as one of its functional blocks. ＦＥＥ In case CS13, the fee adjustment unit 21 ＦＥＥ The parking fee PF or the rental fee RF may be changed depending on the change factor (i.e., may be dynamically set).ＦＥＥ 1 shows how the parking fee PF and rental fee RF are set according to variable factors. The parking fee PF is the cost of parking the user's vehicle V1 in the target parking lot. As described above, the rental fee RF is the cost of the user U1 renting the SR vehicle (target SR vehicle) at the target station in accordance with the usage plan P_X.

[0106] The variable factors according to Example EX1_3 may include demand forecast data D1_3a, which is demand forecast data related to parking lots. The demand forecast data D1_3a is demand forecast data for a target parking lot during a time period when the host vehicle V1 is parked in the target parking lot according to the route plan P_A. The time period when the host vehicle V1 is parked in the target parking lot according to the route plan P_A is referred to as the predicted time period of the demand forecast data D1_3a. The predicted time period of the demand forecast data D1_3a is a time period between the estimated arrival time t Ａ１ A time period including, for example, the estimated arrival time t Ａ１ A certain time period centered on the time t, or the estimated arrival time t Ａ１ It is a period of time starting from a certain time.

[0107] The demand forecast data D1_3a is, for example, generated in the plan creation process 1200 (hence the estimated arrival time t Ａ１ The demand forecast data D1_3a is data predicted (before the demand forecast data D1_3a) and indicates the predicted value of parking demand for the target parking lot during the predicted time period of the demand forecast data D1_3a. The parking lot server device 40 has a predictor that generates the demand forecast data D1_3a by predicting parking demand, and the predictor can be realized, for example, by artificial intelligence formed through machine learning. The parking lot server device 40 can generate the demand forecast data D1_3a based on the characteristics of the area in which the target parking lot is located and the weather during the predicted time period in the area in which the target parking lot is located. In response to a request from the travel assistance device 20, the demand forecast data D1_3a is transmitted from the parking lot server device 40 to the travel assistance device 20. Note that the server-side controller 21 may predict parking demand and generate the demand forecast data D1_3a.

[0108] The variable factors related to Example EX1_3 may include demand forecast data D1_3b, which is demand forecast data related to SR vehicles. The demand forecast data D1_3b is demand forecast data for the time period when user U1 rents the target SR vehicle at the target station in accordance with the usage plan P_X, and is demand forecast data for the SR vehicle in area A1_3b that includes the rental point of the target SR vehicle. The rental point of the target SR vehicle is the target station. Area A1_3b may be an area of ​​a certain size and shape that includes the rental point of the target SR vehicle. In the example of FIG. 10, area A1_3b may be, for example, an area within a circle with a certain radius centered on station 621. The time period when user U1 rents the target SR vehicle at the target station in accordance with the usage plan P_X is treated as the predicted time period of the demand forecast data D1_3b.

[0109] The demand forecast data D1_3b is, for example, generated in the plan creation process 1200 (hence the estimated arrival time t Ａ１ The demand forecast data D1_3b is data predicted (before the demand forecast data D1_3b) and indicates a predicted value of the demand for SR vehicles in the area A1_3b during the predicted time period of the demand forecast data D1_3b. The MSS management device 30 has a predictor that generates the demand forecast data D1_3b by predicting the demand for SR vehicles, and the predictor can be realized, for example, by artificial intelligence formed through machine learning. The MSS management device 30 can generate the demand forecast data D1_3b based on the characteristics of the area A1_3b and the weather in the area A1_3b during the predicted time period of the demand forecast data D1_3b. In response to a request from the travel support device 20, the demand forecast data D1_3b is transmitted from the MSS management device 30 to the travel support device 20. Note that the server-side controller 21 may predict the demand for SR vehicles and generate the demand forecast data D1_3b.

[0110] The variation factors according to the example EX1_3 may include distance data D1_3c indicating the distance between the target parking lot and the target station. In the example of FIG. 10, the distance data D1_3c indicates the distance between the parking lot 611 and the station 621.

[0111] Fee adjustment unit 21 ＦＥＥThe fee adjusting unit 21 may set the parking fee PF or the rental fee RF according to a predetermined algorithm based on the fluctuation factors according to the embodiment EX1_3. ＦＥＥ The fee adjusting unit 21 can increase the parking fee PF (or the rental fee RF) as the predicted value indicated by the demand forecast data D1_3a increases. ＦＥＥ The fee adjusting unit 21 can reduce the parking fee PF (or may reduce the rental fee RF) as the predicted value indicated by the demand forecast data D1_3a decreases. ＦＥＥ The fee adjusting unit 21 can increase the rental fee RF (or the parking fee PF) as the predicted value indicated by the demand forecast data D1_3b increases. ＦＥＥ The fee adjusting unit 21 can reduce the rental fee RF (or may reduce the parking fee PF) as the predicted value indicated by the demand forecast data D1_3b decreases. ＦＥＥ The fee adjusting unit 21 can reduce the rental fee RF (or may reduce the parking fee PF) as the distance indicated by the distance data D1_3c increases. ＦＥＥ can increase the rental fee RF (or the parking fee PF) as the distance indicated by the distance data D1_3c decreases.

[0112] The embodiment EX1_2 and the embodiment EX1_3 may be combined. That is, when the parking fee reduction is implemented, the fee adjustment unit 21 ＦＥＥ is the basic parking fee PF depending on the variable factors according to the embodiment EX1_3. ＲＥＦ and reduced parking fees PF ＬＯＷ In addition, when a reduction in the rental fee is implemented, the fee adjustment unit 21 ＦＥＥ is the basic rental fee RF depending on the variable factors related to Example EX1_3. ＲＥＦ and Reduced Loan Rate RF ＬＯＷ The difference between the

[0113] Fee adjustment unit 21 based on fluctuation factors ＦＥＥ The parking fee PF set by is the reduced parking fee PF ＬＯＷ If it corresponds to the above, the fee adjustment unit 21ＦＥＥ The setting of the parking fee PF by the fee adjustment unit 21 corresponds to the parking fee reduction described in the embodiment EX1_2. ＦＥＥ If the setting of the parking fee PF by the method corresponds to a parking fee reduction, the parking fee can be reduced according to the method described in the embodiment EX1_2 (see FIG. 11(a)). ＦＥＥ The rental fee RF set by is reduced rental fee RF ＬＯＷ If it corresponds to the above, the fee adjustment unit 21 ＦＥＥ The setting of the rental fee RF by the fee adjustment unit 21 corresponds to the rental fee reduction described in the embodiment EX1_2. ＦＥＥ If the setting of the rental fee RF by the above corresponds to a reduction in the rental fee, the rental fee reduction can be implemented according to the method described in the embodiment EX1_2 (see FIG. 11(b)).

[0114] The variable factors related to example EX1_3 may include all or part of data D1_3a, D1_3b, and D1_3c. The variable factors related to example EX1_3 are not limited to data D1_3a, D1_3b, and D1_3c. Various conditions (availability, waiting time until rental, etc.) when user U1 rents an SR vehicle at a target station may be included in the variable factors related to example EX1_3.

[0115] As described above, by varying the parking fee PF or rental fee RF according to the variable factors, it is expected that the use of the mobility assistance system will be promoted and the demand for parking spaces or SR vehicles will be leveled out.

[0116] [Example EX1_4] Example EX1_4 will be described. In the operation shown in Fig. 8, the server-side controller 21 transmits (outputs) SR vehicle usage information to the user-side device 10. The SR vehicle usage information is, in detail, usage information for the SR vehicle to be lent to user U1 at the target station (hence the target SR vehicle).

[0117] For example, when the server-side controller 21 proposes a target station to user U1 through the user-side device 10 (when outputting information for realizing the proposal to the user-side device 10), it may transmit (output) information on how to use the SR vehicle to the user-side device 10. The target station is proposed to user U1 through the user-side device 10 by transmitting the reservation availability information 1230 and the route plan P_A from the travel support device 20 to the user-side device 10. For this reason, the information on how to use the SR vehicle may be transmitted from the travel support device 20 to the user-side device 10 together with the reservation availability information 1230 and the route plan P_A.

[0118] Alternatively, for example, the server-side controller 21 may propose the target station to the user U1 through the user-side device 10 (after outputting information for realizing the proposal to the user-side device 10), and then transmit (output) the SR vehicle usage information to the user-side device 10. That is, for example, the SR vehicle usage information may be transmitted from the travel assistance device 20 to the user-side device 10 together with the reservation confirmation signal 1280, or may be transmitted from the travel assistance device 20 to the user-side device 10 immediately after transmitting the reservation confirmation signal 1280. In either case, the SR vehicle usage information may be transmitted from the travel assistance device 20 to the user-side device 10 well before the host vehicle V1 arrives at the target parking lot.

[0119] The SR vehicle usage information includes text and images showing how to use the SR vehicle (i.e., the target SR vehicle) to be rented to the user U1 at the target station, and the images may be video lessons promoting safe operation of the SR vehicle. After the SR vehicle usage information is received by the user device 10, the user controller 11 displays the SR vehicle usage information on the display screen 14a, either at the request of the user U1 or without the request of the user U1. Typically, it is expected that the user U1 or a passenger will check the SR vehicle usage information in the vehicle V1 before the vehicle V1 arrives at the target parking lot.

[0120] It is expected that the transmission and reception of the SR vehicle usage information as described above will make the use of the SR vehicle smoother after the vehicle V1 arrives at the target parking lot.

[0121] [Example EX1_5] Example EX1_5 will be described. As described above, the route plan P_A includes at least the user U1's action plan from the target parking lot to the destination. The route plan P_A may further include the user U1's action plan after the user U1 arrives at the destination. In this case, the route plan P_A may include the user U1's action plan from the time the user U1 stays at the destination to the time the user U1 returns to the target parking lot. In this case, the MSS usage plan P_X may include the user U1's SR vehicle usage plan for the user U1 in the process of returning from the destination to the target parking lot.

[0122] 14 shows a route plan 660_A, which is an example of the route plan P_A. The parking lot 611 and station 621 in FIG. 14 are the same as the parking lot 611 and station 621 shown in FIG. 9. The parking lot 611 is a recommended parking lot searched for in the search process 1140 and is also set as the target parking lot. In the route plan 660_A, the estimated arrival time t Ａ１ The time is 12:55. In the route plan 660_A, the user U1 is scheduled to use the station 621 as the target station.

[0123] In the route plan 660_A, the user U1 is scheduled to depart from the parking lot 611 for the station 621 at 13:00, travel on foot, and arrive at the station 621 at 13:10. The station 621 according to the route plan 660_A is located at a reference distance d ＲＥＦ２ The station 621 related to the route plan 660_A is a station where SR vehicles with a current status of "0" or more than the number of passengers are stored at the time of execution of the plan creation process 1200.

[0124] In the route plan 660_A, user U1 is scheduled to depart from station 621 for the destination at 1:15 PM and arrive at the destination at 1:45 PM. Route plan 660_A also schedules that user U1 will travel from station 621 to the destination on an electric scooter, which is an SR vehicle, rented from station 621. Route plan 660_A also schedules that user U1 will stay at the destination for two hours after arriving at the destination. The server-side controller 21 estimates user U1's stay time at the destination based on the type of facility at the destination, and reflects the estimated result in the route plan 660_A. For example, if the destination is a museum, the server-side controller 21 acquires the average stay time of visitors to the museum based on information published on the communication network NET, and estimates user U1's stay time at the destination from the acquired result. Alternatively, if the destination is a restaurant, the server-side controller 21 estimates user U1's stay time at the destination based on the average stay time of visitors at the restaurant.

[0125] In the route plan 660_A, the user U1 is scheduled to depart from the destination for the station 621 at 15:45 and arrive at the station 621 at 16:15. The route plan 660_A also plans for the user U1 to travel from the destination to the station 621 on an electric kick scooter, which is an SR vehicle, that the user U1 rented at the station 621. In the route plan 660_A, after the user U1 arrives at the station 621 from the destination, the user U1 is scheduled to return the rented electric kick scooter at the station 621. In the route plan 660_A, the user U1 is scheduled to depart from the station 621 for the parking lot 611 at 16:20, travel on foot, and arrive at the parking lot 611 at 16:30.

[0126] The route plan 660_A includes an action plan for user U1 in steps 661 to 665. In the route plan 660_A, steps 661, 662, 663, 664, and 665 occur in this order as time progresses. Step 661 is a step in which user U1 moves from parking lot 611 to station 621. In step 661, user U1's means of transportation is walking. In step 662, user U1 moves from station 621 to the destination. In step 662, user U1's means of transportation is an electric kick scooter rented at station 621. In step 663, user U1 stays at the destination. In step 664, user U1 moves from the destination to station 621. In step 664, user U1's means of transportation is an electric kick scooter rented at station 621. In step 665, user U1 moves from station 621 to parking lot 611. The means of transportation for the user U1 in step 665 is walking. In the route plan 660_A, the required time and timetable for each of steps 661 to 665 are defined.

[0127] The usage plan P_X of the MSS in the route plan 660_A is the usage plan 660_X. The usage plan 660_X indicates that the user U1 will rent an SR vehicle for the number of passengers at the station 621. The usage plan 660_X specifies a time period during which the user U1 will rent an SR vehicle at the station 621. The time period during which the user U1 will rent an SR vehicle (target SR vehicle) at the station 621 is set based on the time period from the start time of step 662 to the end time of step 664, and either coincides with the reference time period or includes the reference time period and is slightly wider than the reference time period.

[0128] After viewing the route plan 660_A on the display screen 14a of the user device 10, the user U1 can instruct the user device 10 to modify the route plan 660_A as necessary. When the query process 1240 (see FIG. 8 ) is performed, the user U1 can input the modification details into the user device 10. In this case, the modification details are included in the usage request signal 1250, and as a result, a reservation request signal 1260 reflecting the modification details is transmitted to the MSS management device 30. For example, the user U1, referencing the route plan 660_A in FIG. 14 , can instruct the user device 10 to extend the stay time at the destination from two hours to three hours. A rental reservation for an SR vehicle is then made according to the modified usage plan 660_X. When the modification is performed, the end time of step 663 and the times of each subsequent step in the modified route plan 660_A are delayed by one hour from the pre-modification route plan 660_A. The same applies when reducing the stay time at the destination. In addition, the user U1 can instruct the user device 10 to modify the start time, end time, or required time of any step in the route plan 660_A. When a modification instruction is given, the server-side controller 21 can modify the route plan 660_A and the usage plan 660_X in accordance with the modification instruction from the user U1, based on the usage request signal 1250 including the content of the modification instruction.

[0129] There may be another station near the destination where the SR vehicle can be returned. In this case, the route plan 660_A may be modified so that the electric scooter rented at station 621 is returned to the other station after step 662. The route plan 660_A related to this modification is referred to as modified route plan 660_A. In the modified route plan 660_A, it is planned that after user U1 stays at the destination, user U1 will rent another SR vehicle at another station and travel to station 621 in the other SR vehicle. Furthermore, the modified route plan 660_A also plans that user U1 will return the other SR vehicle to station 621 and then travel to the parking lot 611 on foot. When the modified route plan 660_A is route plan P_A, the server-side controller 21 makes two types of rental reservation requests to the MSS management device 30 by transmitting a reservation request signal 1260. The two types of rental reservation requests are a request to reserve a rental of an electric kick scooter at station 621 and a request to reserve a rental of another SR vehicle at another station.

[0130] [Embodiment EX1_6] Embodiment EX1_6 will be described. In embodiment EX1_6, the flow of operation of each controller will be described in accordance with the flow in Fig. 8. Figs. 15 and 16 are operation flowcharts of the server-side controller 21 and the user-side controller 11, respectively, in accordance with the flow in Fig. 8. However, in Figs. 15 and 16, it is assumed that the SR vehicle usage method information is transmitted and received immediately after the transmission and reception of the reservation confirmation signal 1280.

[0131] The flow of operation of the server-side controller 21 will be described with reference to Figure 15. Basically, the travel support device 20 is always operating, and the server-side controller 21 continuously waits to receive the going out information 1120 from the user-side device 10 (S111). When the server-side controller 21 receives the going out information 1120 (Y in step S111), the process proceeds to step S112. When the server-side controller 21 proceeds to step S112, the server-side controller 21 waits to receive a local area entry signal 1130 from the user-side device 10. When the server-side controller 21 receives the local area entry signal 1130 (Y in step S112), the process proceeds to step S113.

[0132] In step S113, the server-side controller 21 executes a search process 1140, thereby searching for and extracting one or more recommended parking lots. After step S113, the process proceeds to step S114. In step S114, the server-side controller 21 transmits the recommended parking lot information 1150 to the user-side device 10, and then in step S115, waits to receive the target parking lot information 1180 and the request signal 1182 from the user-side device 10. When the server-side controller 21 receives the target parking lot information 1180 and the request signal 1182 (Y in step S115), the process proceeds to step S116.

[0133] In step S116, the server-side controller 21 executes the plan creation process 1200. The plan creation process 1200 determines the estimated arrival time t Ａ１ is estimated, and a route plan P_A including the MSS usage plan P_X is created. In step S117 following step S116, the server-side controller 21 transmits a reservation inquiry signal 1210 to the MSS management device 30. In the subsequent step S118, the server-side controller 21 waits to receive a response signal 1220 from the MSS management device 30. When the server-side controller 21 receives the response signal 1220 (Y in step S118), the process proceeds to step S119.

[0134] In step S119, the server-side controller 21 transmits the reservation availability information 1230 and the route plan P_A to the user-side device 10. In subsequent step S120, the server-side controller 21 waits to receive a use request signal 1250 from the user-side device 10. When the server-side controller 21 receives the use request signal 1250 (Y in step S120), the process proceeds to step S121. In step S121, the server-side controller 21 transmits a reservation request signal 1260 to the MSS management device 30. In subsequent step S122, the server-side controller 21 waits to receive a response signal 1270 from the MSS management device 30. When the server-side controller 21 receives the response signal 1270 (Y in step S122), the process proceeds to step S123.

[0135] The server-side controller 21 transmits a reservation confirmation signal 1280 to the user-side device 10 in step S123, and then transmits SR vehicle usage information in step S124. In step S125, the server-side controller 21 executes a payment process 1300. With the execution of the payment process 1300, the series of operations of the server-side controller 21 triggered by the receipt of the outing content information 1120 is completed. When the server-side controller 21 waits for the receipt of information or signals to be transmitted from the user-side device 10 or the MSS management device 30, if the necessary reception is not achieved within a predetermined waiting time, the server-side controller 21 performs appropriate processing, such as a prompting process or a termination process. In the prompting process by the server-side controller 21, a prompting signal is transmitted to the user-side device 10 or the MSS management device 30. The prompting signal requests (prompts) the user-side device 10 or the MSS management device 30 to actually transmit the information or signals to be transmitted to the travel support device 20. In the termination process, the series of operations shown in FIG. 15 is terminated, and at this time, information for informing the user U1 of the reason for termination may be transmitted from the travel support device 20 to the user device 10.

[0136] The flow of operation of the user controller 11 will be described with reference to FIG. 16 . Here, it is assumed that the user controller 11 is provided in an information terminal 10A, which serves as the user device 10. The user controller 11 of the information terminal 10A starts executing a travel assistance application program, leading to step S131. In step S131, the user controller 11 waits for the user U1 to input the outing details information 1110 to the user device 10. When the outing details information 1110 is input to the user device 10 (Y in step S131), the process proceeds to step S132. In step S132, the user controller 11 transmits the outing details information 1120 to the travel assistance device 20. In the following step S133, the user controller 11 starts a navigation operation to guide the user U1 along the route of the user's vehicle V1 to the destination. Then, the process proceeds to step S134.

[0137] In step S134, the user controller 11 continuously monitors whether the vehicle position has entered the local area. When the user controller 11 determines that the vehicle position has entered the local area from outside the local area (Y in step S134), the process transitions from step S134 to step S135. In step S135, the user controller 11 transmits a local area entry signal 1130 to the travel assistance device 20. In the following step S136, the user controller 11 waits to receive recommended parking lot information 1150 from the travel assistance device 20. When the user controller 11 receives the recommended parking lot information 1150 (Y in step S136), the process proceeds to step S137.

[0138] In step S137, the user-side controller 11 executes an inquiry process 1160 to notify the user U1 of information about recommended parking lots and receive response information 1164 from the user U1. In subsequent step S138, the user-side controller 11 sets a target parking lot through a setting process 1170, and in subsequent step S139, starts a navigation operation to guide the user U1 along the route of the user's vehicle V1 to the target parking lot. Then, in step S140, the user-side controller 11 transmits target parking lot information 1180 and a request signal 1182 to the travel assistance device 20. In subsequent step S141, the user-side controller 11 waits to receive reservation availability information 1230 and a route plan P_A from the travel assistance device 20. When the user-side controller 11 receives the reservation availability information 1230 and the route plan P_A (Y in step S141), the process proceeds to step S142.

[0139] In step S142, the user-side controller 11 executes inquiry processing 1240 to notify user U1 of reservation availability information 1242 and route plan P_A, and receives response information 1246 from user U1 in response to the notification. Then, in step S143, the user-side controller 11 transmits a usage request signal 1250 to the travel assistance device 20. In the following step S144, the user-side controller 11 waits to receive a reservation confirmation signal 1280 and SR vehicle usage information from the travel assistance device 20. When the user-side controller 11 receives the reservation confirmation signal 1280 and SR vehicle usage information (Y in step S144), the process proceeds to step S145. In step S145, the user-side controller 11 notifies user U1 of the contents of the reservation confirmation signal 1280 by notification processing 1290. The handling of SR vehicle usage information is as described in embodiment EX1_4. When the user-side controller 11 is waiting to receive information or a signal to be transmitted from the travel assistance device 20, if the necessary information or signal is not received for a predetermined waiting time or longer, the user-side controller 11 performs appropriate processing, such as a prompting process or a termination process. In the prompting process by the user-side controller 11, a prompting signal is sent to the travel assistance device 20. The prompting signal is a signal that requests (prompts) the travel assistance device 20 to actually transmit the information or signal to be transmitted to the user-side device 10. In the termination process, the series of operations shown in FIG. 16 is terminated, and at this time, the user-side controller 11 notifies the user U1 of the reason for termination.

[0140] 16 shows only the operations up to the notification process 1290. Although not specifically shown, after the vehicle V1 has arrived at the target parking lot via the notification process 1290, the terminal device 10A may perform a navigation operation to guide the user U1 from the target parking lot to the target station.

[0141] [Example EX1_7] Example EX1_7 will be described. The user-side controller 11 can display any information received from the travel support device 20 on the display screen 14a. For example, the user-side controller 11 can display the route plan P_A or the usage plan P_X on the display screen 14a. Fig. 17 shows how the route plan 640_A of Fig. 10 is displayed on the display screen of the terminal device 10A. Fig. 17 shows how the route plan 640_A is displayed in the form of a table, but the display form of the route plan 640_A is arbitrary. The same applies to the display of other route plans and usage plans.

[0142] [Embodiment EX1_8] Embodiment EX1_8 will be described. FIG. 18 shows a functional block diagram of the server-side controller 21. The server-side controller 21 is provided with functional blocks F121 to F125. The functions of the functional blocks F121 to F125 may be realized by the server-side controller 21 executing a program recorded in the memory 22 or any other recording medium. The functional block F121 is a transmission / reception unit. The transmission / reception unit F121 is responsible for transmitting and receiving any signals and information between the user-side device 10, the MSS management device 30, the parking lot server device 40, and the tour support device 20. The functional block F122 is a search processing unit that performs search processing 1140. The functional block F123 is a plan creation unit that performs plan creation processing 1200. The functional block F124 is a fee adjustment unit, and is the same as the fee adjustment unit 21 shown in FIG. 12 or FIG. 13. ＦＥＥ The functional block F125 is a payment processing unit that performs the payment processing 1300.

[0143] FIG. 19 shows a functional block diagram of the user controller 11. The user controller 11 is provided with functional blocks F111 to F114. The functions of the functional blocks F111 to F114 may be realized by executing a program recorded in the memory 12 or any other recording medium on the user controller 11. If the user device 10 is considered to be the terminal device 10A, the functions of the functional blocks F111 to F114 may be realized by executing the above-mentioned travel assistance application program on the user controller 11. The functional block F111 is a transmission / reception unit. The transmission / reception unit F111 is responsible for sending and receiving any signals and information between the travel assistance device 20 and the user device 10. The functional block F112 is a user response unit. The user response unit F112 acquires input information from the user U1 to the user device 10 and notifies the user U1 of various information. The user response unit F112 performs inquiry processing 1160 and 1240 and notification processing 1290. The user response unit F112 also displays the route plan P_A or the utilization plan P_X on the display screen 14a. The function block F113 is a setting processing unit that performs the setting process 1170. The function block F114 is a navigation unit that performs the above-mentioned navigation operation.

[0144] [Example EX1_9] Example EX1_9 will be described. There may also be parking lots with stations attached. A parking lot with a station attached is called a special parking lot. A station located within the parking lot premises also falls under the category of a station being attached. That is, a station may be located within the premises of a special parking lot, or a station may be located adjacent to the premises of a special parking lot. A special parking lot can also be a recommended parking lot. The second recommendation condition described above always holds for special parking lots.

[0145] [Example EX1_10] Example EX1_10 will be described. The sending and receiving of the local area entry signal 1130, the execution of the search process 1140, the sending and receiving of the recommended parking lot information 1150, and the execution of the inquiry process 1160 may be omitted. In example EX1_10, a case is considered in which these steps are omitted and the user controller 11 determines that the host vehicle V1 has arrived at or is about to arrive at a special parking lot.

[0146] When the user controller 11 determines that the vehicle V1 has arrived at or is about to arrive at a special parking lot, the special parking lot is set as the target parking lot in the setting process 1170. In this case, the target parking lot information 1180 indicates that the special parking lot has been set as the target parking lot. In addition, the estimated arrival time t Ａ１ The estimation of the arrival time of the vehicle V1 at the special parking lot can be omitted, and the estimated arrival time t Ａ１ Other operations may be the same as those shown in the above-mentioned embodiments, but the station attached to the special parking lot as the target parking lot may always be set as the target station. However, if the station attached to the special parking lot as the target parking lot does not store SR vehicles equal to or greater than the number of passengers with a current status of "0", another station may be set as the target station.

[0147] Existing parking lots may be converted into special parking lots so that all parking lots assumed in the first embodiment are special parking lots. This has the advantage of shortening the travel distance from when the vehicle V1 leaves the parking lot to when the vehicle moves to the station. However, because converting parking lots into special parking lots requires a considerable cost, it can be said that the method shown in Example EX1_1, etc., which does not rely on special parking lots, is more practical.

[0148] [Example EX1_11] Example EX1_11 will be described.

[0149] In response to receiving the target parking information 1180 (see FIG. 8), the server-side controller 21 may request the parking lot server device 40 to make a reservation for the target parking lot. A reservation for the target parking lot is a reservation for a parking space provided in the target parking lot, and refers to reserving the use of a parking space to park the vehicle V1 in a parking space provided in the target parking lot. If the reservation for the target parking lot can be accommodated, the parking lot server device 40 makes a reservation for the target parking lot in accordance with the request from the server-side controller 21, and transmits a notice that the reservation has been made to the travel support device 20. Thereafter, the notice that the reservation has been made is transmitted from the server-side controller 21 to the user U1 via the user-side device 10. The server-side controller 21 transmits the reservation for the target parking lot at the estimated arrival time t Ａ１ In the search process 1140, the server-side controller 21 may search for only parking lots that can be reserved as candidates for recommended parking lots.

[0150] When the user-side controller 11 determines that the user U1 in the vehicle V1 has reached the local area, the user-side controller 11 may send a confirmation inquiry to the user U1 via the HMI 14. The confirmation inquiry may inquire about whether there has been a change in the destination or about where the user U1 wants to head after getting off the vehicle V1. The confirmation inquiry may also inquire about the number of people accompanying the user U1. When the user-side controller 11 receives the user U1's response to the confirmation inquiry, the user-side controller 11 adds the content of the user U1's response to the confirmation inquiry to the local area entry signal 1130 and transmits the signal to the travel support device 20. In this case, the server-side controller 21 takes the content of the user U1's response to the confirmation inquiry into consideration when executing the subsequent search process 1140 and plan creation process 1200.

[0151] The technology described above in the first embodiment basically assumes that user U1 is registered with the travel assistance device 20 through a user registration process, but the user registration process is not required. However, if the user registration process is not performed, user U1 must transmit information for establishing communication, including contact information, to the travel assistance device 20 via the user device 10. Furthermore, to have the server controller 21 perform the payment process 1300, user U1 must transmit payment information to the travel assistance device 20 via the user device 10. Furthermore, depending on the type of SR vehicle, age restrictions may be imposed on the use of the SR vehicle. Therefore, in order to properly create the MSS usage plan P_X, user U1 may transmit the ages or age groups of both user U1 and his / her companions to the travel assistance device 20 via the user device 10.

[0152] <<Second Embodiment>> A second embodiment of the present invention will be described. In the second embodiment, an operation that functions beneficially after the user U1 gets off the vehicle V1 will be mainly described. Through this operation, the user U1 is supported in moving around after getting off the vehicle V1.

[0153] 20 is an operational sequence diagram of the travel assistance system according to the second embodiment. A user U1, who was riding in his / her vehicle V1, parks his / her vehicle V1 in a parking lot and then gets off the vehicle V1. In the second embodiment, the target parking lot refers to the parking lot where the vehicle V1 is parked. The target parking lot may be determined by the method shown in the first embodiment.

[0154] Once the target parking lot is determined, the user-side controller 11 transmits target parking lot information 2110, which identifies which parking lot the target parking lot is, to the travel assistance device 20. The target parking lot information 2110 indicates at least the location of the target parking lot. User U1 may input information indicating the target parking lot information 2110 into the user-side device 10. Furthermore, before or after vehicle V1 arrives at the target parking lot, the user-side controller 11 identifies the number of passengers by using a questionnaire or the like for user U1. The number of passengers is the number of members of a group including user U1, and has a value obtained by adding 1 to the number of accompanying persons of user U1. If there are zero accompanying persons, the number of passengers is 1. After identifying the number of passengers, the user-side controller 11 transmits passenger number information 2120, which indicates the number of passengers, to the travel assistance device 20.

[0155] Furthermore, before or after the arrival of the vehicle V1 at the target parking lot, the user-side controller 11 starts an operation of periodically detecting the current location of the user U1 and transmits current location information 2130 indicating the detection result to the wandering support device 20. While FIG. 20 shows that the current location information 2130 is transmitted to the wandering support device 20 only once, the current location information 2130 indicating the most recent current location of the user U1 is periodically transmitted to the wandering support device 20. In the second embodiment, the user-side device 10 is a terminal device 10A, and the user U1 moves while carrying the terminal device 10A. A position detection sensor provided in the terminal device 10A detects the current location of the terminal device 10A as the current location of the user U1.

[0156] The travel support device 20 receives target parking lot information 2110, passenger count information 2120, and current location information 2130. After receiving the information 2110, 2120, and 2130, the server-side controller 21 performs a spot extraction process 2140 to extract one or more recommended spots based on at least the current location of user U1. A recommended spot is a spot recommended by the travel support device 20 as a tourist spot that user U1 can visit. The server-side controller 21 can extract one or more recommended spots from tourist spots within a certain distance from user U1's current location. The server-side controller 21 may extract recommended spots based on user U1's preference information included in the additional information of the registration table TBL1 (see FIG. 6 ) and the user U1's past search history via the information terminal 10A. The server-side controller 21 may also extract event venues as recommended spots based on information about events taking place near user U1's current location.

[0157] After the spot extraction process 2140, the server-side controller 21 transmits recommended spot information 2150 to the user-side device 10. The recommended spot information 2150 indicates the location and details of each extracted recommended spot. When the user-side device 10 receives the recommended spot information 2150, the user-side controller 11 performs an inquiry process 2160.

[0158] In the inquiry process 2160, the user controller 11 uses the HMI 14 to notify the user U1 of information about one or more recommended spots (such as the location and details of recommended parking lots) and suggests to the user U1 that they visit each recommended spot. The user U1 then inputs response information 2164, which responds to the suggestions made in the inquiry process 2160, into the user device 10 using the HMI 14. Assume that the recommended spot information 2150 includes information about the first through Lth recommended spots (L is an integer greater than or equal to 1). While there may be cases where no consent is given to the suggestions, such cases are not considered here. In this case, the user U1 agrees to visiting one or more of the first through Lth recommended spots and inputs this consent as response information 2164 into the user device 10. Recommended spots that the user U1 agrees to visiting are specifically referred to as "agreed recommended spots." The total number of agreed recommended spots may be two or more.

[0159] In response to the input of the response information 2164, the user-side controller 11 transmits visit desire information 2170 indicating the consent-recommended spot to the excursion support device 20. The visit desire information 2170 indicates that the user U1 wishes to visit the consent-recommended spot.

[0160] In response to receiving the visit request information 2170 at the travel assistance device 20, the server-side controller 21 executes a plan creation process 2200. The server-side controller 21 involved in the plan creation process 2200 creates a route plan P_B based on second plan creation information including the current location of user U1, the locations of one or more consent-recommended spots, and the location of the target parking lot. The second plan creation information also includes information identifying the locations of each station within an area that includes the current location of user U1, the one or more consent-recommended spots, and the target parking lot, and may further include a management table TBL2 (see FIG. 7 ). The plan creation process 2200 identifies a target station. The target station is a station that user U1 is scheduled and planned to pass through in the route plan P_B.

[0161] The route plan P_B is a behavior plan for user U1 that includes a planned route for user U1 to visit one or more consent-recommended spots, and includes a timetable for user U1's actions. Part of user U1's travel after getting off his / her vehicle V1 will involve travel using an SR vehicle. Therefore, the route plan P_B includes an MSS usage plan P_Y. The usage plan P_Y indicates the station where user U1 will rent an SR vehicle, the time period during which user U1 will use the SR vehicle (the start and end times of rental), and the planned number of SR vehicles that user U1 will rent. The number of SR vehicles to be rented corresponds to the number of passengers. However, if the number of occupants per SR vehicle to be rented is two or more (if the SR vehicle to be rented is an SR vehicle for multiple occupants), the number of SR vehicles to be rented may be determined taking into account the occupancy capacity of the SR vehicle. The route plan P_B includes at least the user U1's action plan from the current location to the recommended spot. Therefore, the usage plan P_Y includes the MSS usage plan (SR vehicle usage plan) to be used when the user U1 moves from the current location of the user U1 to the agreed-upon recommended spot.

[0162] If the current location of user U1 is parking lot 611 in Fig. 10 and the consent-recommended spot is the destination in Fig. 10, route plan P_B may include steps 641 and 642 and usage plan P_Y may be the same as usage plan 640_X. If the current location of user U1 is parking lot 611 in Fig. 14 and the consent-recommended spot is the destination in Fig. 14, route plan P_B may include steps 661 to 665 and usage plan P_Y may be the same as usage plan 660_X.

[0163] When the plan creation process 2200 creates a route plan P_B including an MSS usage plan P_Y, the server-side controller 21 transmits a reservation inquiry signal 2210 to the MSS management device 30. The reservation inquiry signal 2210 inquires whether a rental reservation of an SR vehicle is possible under the conditions of the usage plan P_Y. The reservation inquiry signal 2210 is received by the MSS management device 30. The MSS management device 30 then determines whether a rental reservation of an SR vehicle is possible under the conditions of the usage plan P_Y based on the management table TBL2 (see FIG. 7 ) and transmits a response signal 2220 indicating the determination result to the travel support device 20. The server-side controller 21 may extract recommended spots in the spot process 2140, taking into account the availability of SR vehicles based on the management table TBL2. In this case, the likelihood that a rental reservation will be determined to be possible in response to the reservation inquiry signal 2210 is sufficiently high. If the MSS management device 30 determines that a rental reservation is not possible, devices 20 and 30 can compare and extract a plan that allows a rental reservation of an SR vehicle under conditions similar to those of the usage plan P_Y. In the following, we will only consider the case where it is determined that a rental reservation of an SR vehicle is possible under the conditions of the usage plan P_Y. Note that the response signal 2220 also indicates the cost required to rent an SR vehicle under the conditions of the usage plan P_Y.

[0164] When the travel support device 20 receives the response signal 2220, the server-side controller 21 transmits reservation availability information 2230 based on the response signal 2220 to the user-side device 10, and also transmits the route plan P_B. The route plan P_B is received by the terminal device 10A, and thereafter, the user U1 can refer to the route plan P_B on the terminal device 10A at any time. The reservation availability information 2230 includes information on the locations of stations at which the user U1 can make a rental reservation and information on SR vehicles at which the user U1 can make a rental reservation, as well as cost information. The cost information in the reservation availability information 2230 indicates the cost required for the user U1 to rent an SR vehicle under the conditions of the usage plan P_Y. The cost information in the reservation availability information 2230 can be an estimate of the cost required for the user U1 to rent an SR vehicle under the conditions of the usage plan P_Y. The stations at which the user U1 can make a rental reservation are target stations whose use is proposed to the user U1 according to the usage plan P_Y. An SR vehicle that user U1 can reserve for rental is a target SR vehicle that is proposed for use to user U1. The total number of candidates available for rental reservation may be 1 or may be 2 or more. For example, if an electric kick scooter and an electric bicycle are available as SR vehicles available for rental reservation, the electric kick scooter and the electric bicycle are two candidates available for rental reservation.

[0165] When the user device 10 receives the reservation availability information 2230 and the route plan P_B, the user controller 11 performs an inquiry process 2240. In the inquiry process 2240, the user controller 11 notifies the user U1 of reservation availability information 2242 corresponding to the reservation availability information 2230 using the HMI 14, and then requests the user U1 to select one of the candidates available for rental reservation. In the inquiry process 2240, the user controller 11 also notifies the user U1 of the route plan P_B. The selection made by the user U1 is input to the user device 10 via the HMI 14. If the total number of candidates available for rental reservation is one, the selection made by the user U1 is a choice of whether to accept that candidate. If the total number of candidates available for rental reservation is two or more, the user U1 selects one of the multiple candidates. Here, it is assumed that the user U1 inputs response information 2246 to the user device 10 indicating that the user agrees to the usage plan P_Y corresponding to one candidate available for rental reservation. The content of the reservation availability information 2242 is the same as the content of the reservation availability information 2230. In other words, the controller 21 or 11 proposes to the user U1, through the notification of the reservation availability information 2242, that the target SR vehicle be rented at the target station under the conditions set forth in the usage plan P_Y. The notification of the reservation availability information 2242 also notifies the user U1 of the above-mentioned cost information. The response information 2246 indicates that the user U1 agrees to the proposal to rent and use the target SR vehicle at the target station under the conditions set forth in the usage plan P_Y. This proposal can be considered to be a proposal from the travel support device 20 or the user-side device 10 to the user U1.

[0166] Upon receiving the response information 2246, the user-side controller 11 transmits a usage request signal 2250 to the travel assistance device 20. The usage request signal 2250 conveys the contents of the response information 2246 to the travel assistance device 20. Therefore, the usage request signal 2250 indicates that the user U1 wishes to rent and use an SR vehicle at the target station under the conditions specified in the usage plan P_Y. In the operational flow of FIG. 20 , the usage request signal 2250 corresponds to a consent signal indicating that the user U1 agrees to the proposal based on the route plan P_B and the usage plan P_Y (the proposal from the device 20 or 10) (in other words, a consent signal indicating that the user U1 agrees to the route plan P_B and the usage plan P_Y). When the usage request signal 2250 is received by the travel assistance device 20, the server-side controller 21 transmits a reservation request signal 2260 to the MSS management device 30 in accordance with the usage request signal 2250. The reservation request signal 2260 is a signal requesting a rental reservation for an SR vehicle (a rental reservation for an SR vehicle to be provided to user U1) under the conditions of the usage plan P_Y. In other words, by transmitting the reservation request signal 2260, the server-side controller 21 outputs (requests) a rental reservation for an SR vehicle under the conditions of the usage plan P_Y to the MSS management device 30.

[0167] In response to receiving the reservation request signal 2260, the MSS management device 30 updates the reservation information in the management table TBL2 in accordance with the request content of the reservation request signal 2260, thereby confirming the rental reservation. The MSS management device 30 then transmits a response signal 2270 to the tour support device 20, indicating that the rental reservation in accordance with the request content of the reservation request signal 2260 has been confirmed. When the response signal 2270 is received by the tour support device 20, the server-side controller 21 transmits a reservation confirmation signal 2280 to the user-side device 10. The reservation confirmation signal 2280 indicates that the rental reservation of the SR vehicle has been confirmed as desired by user U1 (as desired in the usage request signal 2250). When the reservation confirmation signal 2280 is received by the user-side device 10, the user-side controller 11 executes notification processing 2290 using the HMI 14 to notify user U1 of the contents of the reservation confirmation signal 2280.

[0168] Thereafter, the user U1 acts in accordance with the route plan P_B. If the route plan P_B indicates that the user U1 should first head to a certain station from the current location, the user U1 moves toward that station. The terminal device 10A may then perform a navigation operation to guide the user U1's actions in accordance with the route plan P_B.

[0169] On the other hand, the server-side controller 21 performs a payment process 2300 at any timing after receiving the response signal 2270. In the payment process 2300, the server-side controller 21 performs payment of the rental fee RF. In the second embodiment, the rental fee RF is the cost (compensation) for user U1 renting an SR vehicle at a target station in accordance with the usage plan P_Y, and is the fee that user U1 must pay to the operator of the MSS. In the payment process 2300, the server-side controller 21 completes payment of the rental fee RF by cooperating with the MSS management device 30 based on user U1's payment information (see FIG. 6 ). If payment of the parking fee PF has not been completed before the payment process 2300, the server-side controller 21 can also perform payment of the parking fee PF in the payment process 2300. The parking fee PF is the cost (compensation) for parking the vehicle V1 in the target parking lot and is the fee that user U1 must pay to the operator of the target parking lot. In the second embodiment, it is assumed that the payment of the parking fee PF and the rental fee RF is settled by the server-side controller 21 in the payment process 2300. By making each payment on the side of the travel support device 20, the user U1 can save time and effort. Note that the payment of the parking fee PF and the rental fee RF may be made by a connected service separately applied to the vehicle V1.

[0170] The operation of each device according to the second embodiment will be summarized below. The server-side controller 21 can propose recommended spots that the user U1 can visit and a route plan P_B for visiting the recommended spots to the user U1 via the user-side device 10 (2160, 2242). The route plan P_B is proposed by the server-side controller 21 outputting (transmitting) the route plan P_B to the user-side device 10. At this time, the server-side controller 21 includes in the route plan P_B a usage plan P_Y of the MSS that the user U1 should use when traveling from his / her current location to a recommended spot (agreement recommended spot).

[0171] In the reference method in which recommended spots are simply notified, if the user wants to go to a recommended spot, he or she needs to search for an MSS to use on the way to the recommended spot while traveling. By using the travel support system of the second embodiment, a route plan P_B including an MSS usage plan P_Y is proposed, which is highly convenient, saves the user U1 or a companion time, and supports smooth travel to the recommended spot.

[0172] Reducing the effort required by user U1 or their companions will encourage the use of the travel assistance system. Promoting the use of the travel assistance system will encourage people to switch from their personal car to an SR vehicle. This will reduce CO ２ Emissions and CO2 when parking a private car in crowded conditions ２ This is expected to contribute to reducing emissions. Also, if more people park their cars in parking lots relatively far from the city center and then head to the city center in SR vehicles, it is expected that congestion in parking lots in the city center will be alleviated. In addition, it will lead to the promotion of the use of SR vehicles, which have been gaining popularity in recent years, and will also contribute to the realization of smart cities.

[0173] If user U1 agrees to the proposal (i.e., if user U1 agrees to the proposed route plan P_B), after transmitting and receiving a usage desire signal 2250 (agreement signal), the server-side controller 21 transmits a reservation request signal 2260 to the MSS management device 30. As a result, a rental reservation for an SR vehicle in accordance with the usage plan P_Y (a rental reservation for the target SR vehicle to be provided to user U1) is requested (output) from the server-side controller 21 to the MSS management device 30.

[0174] In other words, by using the second embodiment of the travel assistance system, the route plan P_B including the MSS usage plan P_Y and the rental reservation of the SR vehicle are all done by the travel assistance device 20, thereby reducing the effort required of user U1 or his / her companion.

[0175] The second embodiment includes the following Examples EX2_1 to EX2_9. The matters described above in the second embodiment are applied to the following Examples EX2_1 to EX2_9 unless otherwise specified and unless there is a contradiction. However, for matters in each Example that contradict the matters described above in the second embodiment, the description in that Example may take precedence. Furthermore, unless there is a contradiction, matters described in any Example among Examples EX2_1 to EX2_9 can also be applied to any other Example (i.e., any two or more Examples among multiple Examples can also be combined).

[0176] [Example EX2_1] Example EX2_1 will be described. A specific example of the route plan P_B will be given with reference to Figures 21 and 22. In example EX2_1, it is assumed that the only recommended spot for agreement is spot SPT1, and the target parking lot is parking lot 611. In example EX2_1, station 621 is identified as the station closest to the current location of user U1 at the time of execution of plan creation process 2200, and station 621 is incorporated into the target stations in the usage plan P_Y. The route plan P_B can vary depending on whether a station other than station 621 exists near spot SPT1.

[0177] A case in which there is no station other than station 621 near spot SPT1 is referred to as case CS21a. In case CS21a, route plan 820_B in FIG. 21 is created as route plan P_B. The route plan 820_B related to case CS21a will be described. In route plan 820_B, the target station is composed only of station 621. In route plan 820_B, it is planned that user U1 will move from his current location to spot SPT1 via station 621, stay at spot SPT1, and then move from spot SPT1 to parking lot 611 via station 621. In route plan 820_B, it is planned that user U1 will rent an electric kick scooter as the target SR vehicle at station 621.

[0178] Route plan 820_B includes an action plan for user U1 for steps 821 to 825. In route plan 820_B, steps 821, 822, 823, 824, and 825 occur in this order as time progresses. In route plan 820_B, the required time and timetable for each of steps 821 to 825 are specified. In route plan 820_B, the start times (scheduled start times) of steps 821 to 825 are 13:05, 13:15, 13:45, 15:45, and 16:20, respectively. In route plan 820_B, the end times (scheduled end times) of steps 821 to 825 are 13:10, 13:45, 15:45, 16:15, and 16:30, respectively.

[0179] Step 821 is a step in which user U1 moves from his current location to station 621. User U1's means of transportation in step 821 is walking. The start time of step 821 is the scheduled time when user U1 departs from his current location for station 621. The start time of step 821 may be set to a time that is a predetermined small time later than the time when route plan 820_B is created in plan creation process 2200. Step 822 is a step in which user U1 moves from station 621 to spot SPT1. User U1's means of transportation in step 822 is an electric kickboard rented at station 621.

[0180] Step 823 is a step in which user U1 stays at spot SPT1. In route plan 820_B, after user U1 arrives at spot SPT1, user U1 is scheduled to stay there for two hours. The server-side controller 21 estimates the user U1's stay time at spot SPT1 based on the type of facility at spot SPT1, and reflects the estimation result in route plan 820_B. For example, if spot SPT1 is a museum, the server-side controller 21 obtains the average stay time of people who visit the museum based on information published on the communication network NET, and estimates user U1's stay time at spot SPT1 from the obtained results. Alternatively, for example, if spot SPT1 is a restaurant, the server-side controller 21 estimates user U1's stay time at spot SPT1 taking into account the average stay time of people at restaurants.

[0181] Step 824 is a step in which user U1 moves from spot SPT1 to station 621. User U1's means of transportation in step 824 is the electric kick scooter he rented at station 621. Between steps 824 and 825, user U1 returns the rented electric kick scooter to station 621. Step 825 is a step in which user U1 moves from station 621 to parking lot 611. User U1's means of transportation in step 825 is walking.

[0182] The usage plan P_Y of the MSS in the route plan 820_B is the usage plan 820_Y. The usage plan 820_Y indicates that the user U1 will rent SR vehicles (electric kick scooters in this case) for the number of passengers at the station 621. The usage plan 820_Y specifies the time period during which the user U1 will rent the SR vehicle at the station 621. The time period during which the user U1 will rent the SR vehicle at the station 621 is set based on the time period from the start time of step 822 to the end time of step 824, and either coincides with the reference time period or includes the reference time period and is slightly wider than the reference time period.

[0183] User U1, viewing the route plan 820_B on the display screen 14a of the user device 10, can instruct the user device 10 to modify the route plan 820_B as necessary. When the query process 2240 (see FIG. 20) is performed, user U1 can input the modification details into the user device 10. In this case, the modification details are included in the usage request signal 2250, and as a result, a reservation request signal 2260 reflecting the modification details is transmitted to the MSS management device 30. For example, user U1, referencing the route plan 820_B in FIG. 21, can instruct the user device 10 to extend the stay time at spot SPT1 from two hours to three hours. A rental reservation for an SR vehicle is then made according to the modified usage plan 820_Y. When the modification is performed, the end time of step 823 and the times of each subsequent step in the modified route plan 820_B are delayed by one hour from the pre-modification route plan 820_B. The same applies when reducing the stay time at spot SPT1. In addition, user U1 can instruct the user-side device 10 to modify the start time, end time, or required time of any process in route plan 820_B. When a modification instruction is given, the server-side controller 21 can modify the route plan 820_B and the usage plan 820_Y in accordance with the modification instruction from user U1, based on the usage request signal 2250 including the content of the modification instruction.

[0184] A case in which a station 631 different from station 621 exists near spot SPT1 and route plan 840_B in FIG. 22 is created as route plan P_B is referred to as case CS21b. Route plan 840_B related to case CS21b will be described. In route plan 840_B, target stations are stations 621 and 631. At least, the distance between spot SPT1 and station 631 is shorter than the distance between spot SPT1 and station 621. In route plan 840_B, user U1 is scheduled to travel from his current location to spot SPT1 via stations 621 and 631 in order and stay at spot SPT1. In route plan 840_B, user U1 is then scheduled to travel from spot SPT1 to parking lot 611 via stations 631 and 621 in order. In route plan 840_B, user U1 is scheduled to rent an electric kickboard at station 621 and return the electric kickboard at station 631. In route plan 840_B, after returning the electric kickboard, user U1 is scheduled to rent an electric bicycle at station 631 and return the electric bicycle at station 621.

[0185] Route plan 840_B includes an action plan for user U1 for steps 841 to 847. In route plan 840_B, steps 841, 842, 843, 844, 845, 846, and 847 occur in this order as time progresses. In route plan 840_B, the required time and timetable for each of steps 841 to 847 are specified. In route plan 840_B, the start times (scheduled start times) of steps 841 to 847 are 13:05, 13:15, 13:50, 13:55, 15:55, 16:05, and 16:40, respectively. In the route plan 840_B, the end times (scheduled end times) of steps 841 to 847 are 13:10, 13:45, 13:55, 15:55, 16:00, 16:35, and 16:50, respectively.

[0186] Step 841 is a step in which user U1 moves from his current location to station 621. User U1's means of transportation in step 841 is walking. The start time of step 841 is the scheduled time at which user U1 departs from his current location for station 621. A time that is a predetermined small time later than the time at which the route plan 840_B is created in the plan creation process 2200 may be set as the start time of step 841. Step 842 is a step in which user U1 moves from station 621 to station 631. User U1's means of transportation in step 842 is the electric kick scooter that he rented at station 621. Between steps 842 and 843, user U1 returns the electric kick scooter that he rented at station 621 to station 631. Step 843 is a step in which user U1 moves from station 631 to spot SPT1. User U1's means of transportation in step 843 is walking.

[0187] Step 844 is a step in which user U1 stays at spot SPT1. In route plan 840_B, after user U1 arrives at spot SPT1, user U1 is scheduled to stay at spot SPT1 for two hours. The server-side controller 21 can estimate the stay time of user U1 at spot SPT1, and the estimation method is the same as that described above.

[0188] Step 845 is a step in which user U1 moves from spot SPT1 to station 631. User U1's means of transportation in step 845 is walking. Step 846 is a step in which user U1 moves from station 631 to station 621. User U1's means of transportation in step 846 is the electric bicycle rented at station 631. Between steps 846 and 847, user U1 returns the electric bicycle rented at station 631 to station 621. Step 847 is a step in which user U1 moves from station 621 to parking lot 611. User U1's means of transportation in step 847 is walking.

[0189] The usage plan P_Y of the MSS in the route plan 840_B is composed of a usage plan 840_Y1 and a usage plan 840_Y2. The usage plan 840_Y1 indicates that user U1 will rent SR vehicles (electric kick scooters in this case) for the number of passengers at station 621. The usage plan 840_Y1 specifies the time period during which user U1 will rent the SR vehicle at station 621 (however, the return location is different from station 621). The time period during which user U1 will rent the SR vehicle at station 621 is set based on the time period from the start time of step 842 to the end time of step 842, and either coincides with the reference time period or includes and is slightly longer than the reference time period. The usage plan 840_Y2 indicates that user U1 will rent SR vehicles (electric bicycles in this case) for the number of passengers at station 631. In the usage plan 840_Y2, a time period during which the user U1 rents the SR vehicle at the station 631 is specified (however, the return location is different from the station 631). The time period during which the user U1 rents the SR vehicle at the station 631 is set based on the time period from the start time of the step 846 to the end time of the step 846, and either coincides with the reference time period or includes the reference time period and is slightly wider than the reference time period.

[0190] User U1, viewing the route plan 840_B on the display screen 14a of the user device 10, can instruct the user device 10 to modify the route plan 840_B as necessary. When the query process 2240 (see FIG. 20) is performed, user U1 can input the modification details into the user device 10. In this case, the modification details are included in the usage request signal 2250, and as a result, a reservation request signal 2260 reflecting the modification details is transmitted to the MSS management device 30. For example, user U1, referencing the route plan 840_B in FIG. 22, can instruct the user device 10 to extend the stay time at spot SPT1 from two hours to three hours. A rental reservation for an SR vehicle is then made according to the modified usage plan 840_Y2. When the modification is performed, the end time of step 844 and the times of each subsequent step in the modified route plan 840_B are delayed by one hour from the pre-modification route plan 840_B. The same applies when reducing the stay time at spot SPT1. In addition, user U1 can instruct the user-side device 10 to modify the start time, end time, or required time of any process in route plan 840_B. When a modification instruction is given, the server-side controller 21 can modify the route plan 840_B and usage plans 840_Y1 and 840_Y2 in accordance with the modification instruction from user U1, based on the usage request signal 2250 including the content of the modification instruction.

[0191] Although the route plans 820_B and 840_B have been described separately, if a station 631 is present near the spot SPT1, the plan creation process 2200 may create each of the route plans 820_B and 840_B as candidates for the route plan P_B. In this case, the query process 2240 proposes each of the route plans 820_B and 840_B to the user U1 as candidates for the route plan P_B. Then, response information 2246 of the user U1 selecting either the route plan 820_B or 840_B is input to the user device 10. Taking into consideration time constraints, necessary costs, etc., the user U1 can select either the route plan 820_B or 840_B. If the user U1 selects the route plan 820_B, a reservation request signal 2260 is transmitted and received requesting a reservation for a rental of an SR vehicle under the conditions of the usage plan 820_Y. As a result, the MSS management device 30 confirms the rental reservation under the conditions of the usage plan 820_Y. When the user U1 selects the route plan 840_B, a reservation request signal 2260 is transmitted and received requesting the rental reservation of an SR vehicle under the conditions of the usage plans 840_Y1 and 840_Y2. As a result, the MSS management device 30 confirms the rental reservation under the conditions of the usage plans 840_Y1 and 840_Y2.

[0192] The route plan P_B illustrated in Example EX2_1 will be summarized below. The route plan P_B includes a plan of steps (821, 841) for user U1 to travel from the current location of user U1 to the MSS station (621). The route plan P_B also includes a plan of steps (822, or 842 and 843) from when user U1 rents an SR vehicle at the station (621) until user U1 arrives at the recommended spot (SPT1) in the SR vehicle.

[0193] In the reference method in which recommended spots are simply notified, if the user wants to go to a recommended spot, the user needs to search for an MSS to use while traveling to reach the recommended spot. The excursion support system of the second embodiment is highly convenient because it proposes a route plan P_B including an SR vehicle usage plan P_Y until arriving at the recommended spot, thereby reducing the effort of the user U1 or a companion.

[0194] The route plan P_B may also include a plan for user U1 to use one or more SR vehicles from the current location, passing through one or more stations, to visit the recommended spot (SPT1), and then arrive at the parking lot (611). The one or more stations here are only station 621 in the example of FIG. 21 and stations 621 and 631 in the example of FIG. 22, but may be three or more stations. The one or more SR vehicles here are an electric kick boat rented at station 621 in the example of FIG. 21, and an electric kick boat rented at station 621 and an electric bicycle rented at station 631 in the example of FIG. 22, but may be one or more SR vehicles.

[0195] Since user U1 will eventually return to the parking lot, creating and proposing a route plan P_B that includes the process of returning to the parking lot can significantly reduce the effort required by user U1 or his or her companions.

[0196] [Example EX2_2] Example EX2_2 will be described. The total number of recommended spots may be two or more, and user U1 may agree to a route plan P_B that visits two or more recommended spots in sequence. A specific example of a route plan P_B that visits two recommended spots in sequence will be described with reference to FIGS. 23 and 24. In the examples of FIGS. 23 and 24, the target parking lot is parking lot 611, and spots SPT1 and SPT2 are the two agreed-upon recommended spots. In example EX2_2, station 621 is identified as the station closest to user U1's current location at the time of execution of plan creation process 2200, and station 621 is incorporated into the target station in the usage plan P_Y. The route plan P_B may vary depending on whether a station other than station 621 exists near spots SPT1 and SPT2.

[0197] A case in which there is no station other than station 621 near spots SPT1 and SPT2 is referred to as case CS22a. In case CS22a, route plan 860_B in FIG. 23 is created as route plan P_B. The route plan 860_B related to case CS22a will be described. In route plan 860_B, the target station is composed only of station 621. In route plan 860_B, it is planned that user U1 will visit spots SPT1 and SPT2 in sequence from his current location via station 621, and then move from spot SPT2 to parking lot 611 via station 621. In route plan 860_B, it is planned that user U1 will rent an electric kick scooter as the target SR vehicle at station 621.

[0198] The route plan 860_B includes an action plan for the user U1 in steps 861 to 867. In the route plan 860_B, steps 861, 862, 863, 864, 865, 866, and 867 occur in this order as time progresses. In the route plan 860_B, the required time and timetable for each of the steps 861 to 867 are specified.

[0199] Step 861 is a step in which user U1 moves from his current location to station 621. User U1's means of transportation in step 861 is walking. The start time of step 861 is the scheduled time at which user U1 departs from his current location for station 621. The start time of step 861 may be set to a time that is a predetermined small time later than the time at which route plan 860_B is created in plan creation process 2200. Step 862 is a step in which user U1 moves from station 621 to spot SPT1. User U1's means of transportation in step 862 is an electric kickboard rented at station 621.

[0200] Step 863 is a step in which user U1 stays at spot SPT1. In route plan 860_B, after user U1 arrives at spot SPT1, user U1 is scheduled to stay at spot SPT1 for two hours. The server-side controller 21 can estimate the stay time of user U1 at spot SPT1, and the estimation method is the same as that shown in example EX2_1.

[0201] Step 864 is a step in which user U1 moves from spot SPT1 to spot SPT2. User U1's means of transportation in step 864 is an electric kickboard rented from station 621. Step 865 is a step in which user U1 stays at spot SPT2. In route plan 860_B, after user U1 arrives at spot SPT2, user U1 is scheduled to stay at spot SPT2 for three hours. The server-side controller 21 can estimate the stay time of user U1 at spot SPT2, and the estimation method is the same as that shown in embodiment EX2_1.

[0202] Step 866 is a step in which user U1 moves from spot SPT2 to station 621. User U1's means of transportation in step 866 is the electric kickboard that he rented at station 621. Between steps 866 and 867, user U1 returns the rented electric kickboard to station 621. Step 867 is a step in which user U1 moves from station 621 to parking lot 611. User U1's means of transportation in step 867 is walking.

[0203] The usage plan P_Y of the MSS in the route plan 860_B is the usage plan 860_Y. The usage plan 860_Y ​​indicates that the user U1 will rent SR vehicles (electric kick scooters in this case) for the number of passengers at the station 621. The usage plan 860_Y ​​specifies the time period during which the user U1 will rent the SR vehicles at the station 621. The time period during which the user U1 will rent the SR vehicles at the station 621 is set based on the time period from the start time of step 862 to the end time of step 866, and either coincides with the reference time period or includes the reference time period and is slightly wider than the reference time period.

[0204] User U1, viewing the route plan 860_B on the display screen 14a of the user device 10, can instruct the user device 10 to modify the route plan 860_B as necessary. When the query process 2240 (see FIG. 20) is performed, user U1 can input the modification details into the user device 10. In this case, the modification details are included in the usage request signal 2250, and as a result, a reservation request signal 2260 reflecting the modification details is transmitted to the MSS management device 30. For example, user U1, referencing the route plan 860_B in FIG. 23, can instruct the user device 10 to reduce the stay time at spot SPT2 from 3 hours to 2 hours. A rental reservation for an SR vehicle is then made according to the modified usage plan 860_Y. When the modification is performed, the end time of step 865 and the times of each subsequent step in the modified route plan 860_B are advanced by one hour compared to the route plan 860_B before the modification. The same applies when increasing or decreasing the stay time at spot SPT2, and when increasing or decreasing the stay time at spot SPT1. In addition, user U1 can instruct the user-side device 10 to modify the start time, end time, or required time of any process in the route plan 860_B. When a modification instruction is given, the server-side controller 21 can modify the route plan 860_B and the usage plan 860_Y ​​in accordance with the modification instruction from user U1, based on the usage request signal 2250 including the content of the modification instruction.

[0205] A case in which stations 632 and 633, different from station 621, exist near spot SPT2 and in which route plan 880_B in FIG. 24 is created as route plan P_B, is referred to as case CS22b. In case CS22b, station 634 also exists near parking lot 611. Route plan 880_B related to case CS22b will be described. In route plan 880_B, target stations are stations 621, 632, 633, and 634. In route plan 880_B, user U1 is scheduled to travel from his current location to spot SPT1 via station 621, and then to spot SPT2 via station 632. In route plan 880_B, user U1 is further scheduled to travel from spot SPT2 to parking lot 611 via stations 633 and 634 in order. In route plan 880_B, user U1 is scheduled to rent an electric kickboard at station 621 and return it at station 632. In route plan 840_B, after returning the electric kickboard, user U1 is scheduled to rent an electric bicycle at station 633 and return it at station 634.

[0206] Route plan 880_B includes an action plan for user U1 in steps 881 to 889. In route plan 880_B, steps 881, 882, 883, 884, 885, 886, 887, 889, and 889 occur in this order as time progresses. In route plan 880_B, the required time and timetable for each of steps 881 to 889 are specified.

[0207] Step 881 is a step in which user U1 moves from his current location to station 621. User U1's means of transportation in step 881 is walking. The start time of step 881 is the scheduled time at which user U1 departs from his current location for station 621. The start time of step 881 may be set to a time that is a predetermined small time later than the time at which route plan 880_B is created in plan creation process 2200. Step 882 is a step in which user U1 moves from station 621 to spot SPT1. User U1's means of transportation in step 882 is an electric kickboard rented at station 621.

[0208] Step 883 is a step in which user U1 stays at spot SPT1. In route plan 880_B, after user U1 arrives at spot SPT1, user U1 is scheduled to stay at spot SPT1 for two hours. The server-side controller 21 can estimate the stay time of user U1 at spot SPT1, and the estimation method is the same as that shown in example EX2_1.

[0209] Step 884 is a step in which user U1 moves from spot SPT1 to station 632. User U1's means of transportation in step 884 is the electric kick scooter he rented at station 621. Between steps 884 and 885, user U1 returns the electric kick scooter he rented at station 621 to station 632. Step 885 is a step in which user U1 moves from station 632 to spot SPT2. User U1's means of transportation in step 885 is walking. Step 886 is a step in which user U1 stays at spot SPT2. In route plan 880_B, after user U1 arrives at spot SPT2, user U1 is scheduled to stay at spot SPT2 for three hours. The server-side controller 21 can estimate user U1's stay time at spot SPT2, and the estimation method is the same as that shown in embodiment EX2_1.

[0210] Step 887 is a step in which user U1 moves from spot SPT2 to station 633. User U1's means of transportation in step 887 is walking. Step 888 is a step in which user U1 moves from station 633 to station 634. User U1's means of transportation in step 888 is the electric bicycle rented at station 633. Between steps 888 and 889, user U1 returns the electric bicycle rented at station 633 to station 634. Step 889 is a step in which user U1 moves from station 634 to parking lot 611. User U1's means of transportation in step 889 is walking.

[0211] The usage plan P_Y of the MSS in the route plan 880_B is composed of a usage plan 880_Y1 and a usage plan 880_Y2. The usage plan 880_Y1 indicates that user U1 will rent SR vehicles (electric kick scooters in this case) for the number of passengers at station 621. The usage plan 880_Y1 specifies the time period during which user U1 will rent the SR vehicle at station 621 (however, the return location is different from station 621). The time period during which user U1 will rent the SR vehicle at station 621 is set based on the time period from the start time of step 882 to the end time of step 884, and either coincides with the reference time period or includes and is slightly longer than the reference time period. The usage plan 880_Y2 indicates that user U1 will rent SR vehicles (electric bicycles in this case) for the number of passengers at station 633. In the usage plan 880_Y2, a time period during which the user U1 rents the SR vehicle at the station 633 is specified (however, the return location is different from the station 633). The time period during which the user U1 rents the SR vehicle at the station 633 is set based on the time period from the start time of the step 888 to the end time of the step 888, and either coincides with the reference time period or includes the reference time period and is slightly wider than the reference time period.

[0212] User U1, viewing the route plan 880_B on the display screen 14a of the user device 10, can instruct the user device 10 to modify the route plan 880_B as necessary. When the query process 2240 (see FIG. 20) is performed, user U1 can input the modification details into the user device 10. In this case, the modification details are included in the usage request signal 2250, and as a result, a reservation request signal 2260 reflecting the modification details is transmitted to the MSS management device 30. For example, user U1, referencing the route plan 880_B in FIG. 24, can instruct the user device 10 to reduce the stay time at spot SPT2 from 3 hours to 2 hours. A rental reservation for an SR vehicle is then made according to the modified usage plan 880_Y. When the modification is performed, the end time of step 886 and the times of each subsequent step in the modified route plan 880_B are advanced by one hour compared to the route plan 880_B before the modification. The same applies when increasing or decreasing the stay time at spot SPT2, and when increasing or decreasing the stay time at spot SPT1. In addition, user U1 can instruct the user-side device 10 to modify the start time, end time, or required time of any process in route plan 880_B. When a modification instruction is given, the server-side controller 21 can modify the route plan 880_B and the usage plans 880_Y1 and 880_Y2 in accordance with the modification instruction from user U1, based on the usage request signal 2250 including the content of the modification instruction.

[0213] Although route plans 860_B and 880_B have been described separately, route plans 860_B and 880_B may each be created as a candidate for route plan P_B in plan creation processing 2200 depending on the location of each station. In this case, route plans 860_B and 880_B are each proposed to user U1 as a candidate for route plan P_B in query processing 2240. Then, response information 2246 of user U1 selecting either route plan 860_B or 880_B is input to the user device 10. User U1 can select route plan 860_B or 880_B taking into consideration time constraints, necessary costs, etc. If user U1 selects route plan 860_B, a reservation request signal 2260 is transmitted and received requesting a rental reservation for an SR vehicle under the conditions of usage plan 860_Y. As a result, the MSS management device 30 confirms the rental reservation under the conditions of usage plan 860_Y. When user U1 selects route plan 880_B, a reservation request signal 2260 is transmitted and received to request a rental reservation for an SR vehicle under the conditions of usage plans 880_Y1 and 880_Y2. As a result, the MSS management device 30 confirms the rental reservation under the conditions of usage plans 880_Y1 and 880_Y2.

[0214] The route plans 860_B and 880_B are merely two examples of a route plan P_B that can be created when the user U1 visits the spots SPT1 and SPT2 in sequence. In the plan creation process 2200, various route plans P_B can be created based on the current location of the user U1, the location of the parking lot 611, the locations of the spots SPT1 and SPT2, and the locations of the stations in the area that includes these locations. The route plan P_B may also be a route plan when the user U1 visits three or more spots in sequence.

[0215] The route plan P_B illustrated in Example EX2_2 is summarized below. The route plan P_B according to Example EX2_2 is a behavior plan for user U1 when user U1 visits multiple recommended spots (here, spots SP1 and SPT2) in order. The route plan P_B includes a plan for user U1 to visit multiple recommended spots in order using a target SR vehicle consisting of one or more SR vehicles, passing through one or more stations from the current location. The one or more stations referred to here are only station 621 in the example of FIG. 23 and stations 621 and 632-634 in the example of FIG. 24. The total number of stations that user U1 is scheduled to pass through in the route plan P_B is arbitrary and may be one or more. In the example of FIG. 23, the one or more SR vehicles that make up the target SR vehicle are only an electric kick scooter, while in the example of FIG. 24, they are an electric kick scooter rented at station 621 and an electric bicycle rented at station 633. The total number of SS vehicles that user U1 is scheduled to use in the route plan P_B is arbitrary and may be one or more.

[0216] In the reference method in which multiple recommended spots are simply notified, if the user wants to visit multiple recommended spots, the user needs to search for an MSS to use to visit each recommended spot in sequence while traveling. The excursion support system of the second embodiment is highly convenient because it proposes a route plan P_B that includes an SR vehicle usage plan P_Y for visiting each recommended spot in sequence, thereby reducing the effort of the user U1 or their companions.

[0217] The route plan P_B may also include a plan for user U1 to visit multiple recommended spots in order using a target SR vehicle consisting of one or more SR vehicles, passing through one or more stations from the current location, and then arrive at the parking lot (611).

[0218] Since user U1 will eventually return to the parking lot, creating and proposing a route plan P_B that includes the process of returning to the parking lot can significantly reduce the effort required by user U1 or his or her companions.

[0219] [Example EX2_3] Example EX2_3 will be described. A case in which user U1 rents an SR vehicle at a target station according to the flow shown in FIG. 20 is referred to as case CS23a. In case CS23a, a reservation request signal 2260 is transmitted and received from the travel support device 20 to the MSS management device 30, requesting (outputting) a reservation for rental of an SR vehicle under the conditions of the usage plan P_Y. In contrast, a case in which an SR vehicle is rented at a target station under the same conditions as case CS23a without using the travel support device 20 is referred to as case CS23b. The only difference between case CS23a and case CS23b is whether or not the travel support device 20 is used. In case CS23b, the travel support device 20 does not request the MSS management device 30 to reserve a rental of an SR vehicle by the reservation request signal 2260.

[0220] In case CS23a, the server-side controller 21 grants user U1 a benefit that cannot be obtained in case CS23b. This provides user U1 with an incentive to use the wandering support system. As a result, use of the wandering support system is promoted. The actions and effects of promoting use of the wandering support system are as described in Example EX2_1.

[0221] The benefit according to Example EX2_3 may include a parking fee reduction. The parking fee reduction is a reduction in the cost of parking the user's vehicle V1 in the target parking lot, and is the same as that described in the first embodiment. In Case CS23b, when the user U1 parks the user's vehicle V1 in the target parking lot under certain parking conditions, the fee that the user U1 must pay to the operator of the target parking lot is the basic parking fee PF ＲＥＦ In case CS23a, when the parking fee reduction is implemented, the fee that the user U1 must pay to the operator of the target parking lot when the user U1 parks his / her vehicle V1 in the target parking lot under the specific parking conditions is the reduced parking fee PF ＬＯＷ Basic parking fee PF ＲＥＦ and reduced parking fees PF ＬＯＷ The relationship between the reduced parking fee PF ＬＯＷ is the basic parking fee PF ＲＥＦWhen the parking fee is reduced, the server-side controller 21 calculates the reduced parking fee PF in the payment process 2300 (see FIG. 20). ＬＯＷ is set to the parking fee PF.

[0222] As in the first embodiment, as shown in Figure 11 (a), the parking fee is reduced only when signals 1410 and 1412 are transmitted and received between the travel support device 20 and the parking lot server device 40. The significance of signals 1410 and 1412 is as described in the first embodiment. When signal 1412 is received by the travel support device 20, the server-side controller 21 reduces the parking fee in the subsequent payment process 2300.

[0223] Alternatively, the parking fee reduction may be implemented on the premise that a contract permitting the parking fee reduction has been concluded in advance between the operator of the travel assistance device 20 and the operator of the target parking lot. If such a contract has been concluded in advance, the parking fee reduction may be implemented without the need to send and receive signals 1410 and 1412. When the parking fee reduction is implemented, the server-side controller 21 may notify the user U1 through the user-side device 10 at any timing (for example, in the inquiry process 2160 or 2240) of information indicating that the parking fee reduction will be implemented.

[0224] The benefit according to Example EX2_3 may include a reduction in the rental fee. The reduction in the rental fee is a reduction in the cost for user U1 renting an SR vehicle at a target station in accordance with the usage plan P_Y, and is similar to that described in the first embodiment. In Case CS23b, the cost (compensation) for user U1 renting an SR vehicle under certain rental conditions, which is the fee that user U1 must pay to the operator of the MSS, is the basic rental fee RF ＲＥＦ When the rental fee reduction is implemented in case CS23a, the cost (compensation) for the user U1 renting the SR vehicle under the specific rental conditions, which is the fee that the user U1 should pay to the operator of the MSS, is the reduced rental fee RF ＬＯＷ Basic rental fee RF ＲＥＦ and Reduced Loan Rate RF ＬＯＷ The relationship between the reduced rental fee RFＬＯＷ is the basic rental fee RF ＲＥＦ When the rental fee is reduced, the server-side controller 21 calculates the reduced rental fee RF in the settlement process 2300 (see FIG. 20). ＬＯＷ is set as the rental fee RF.

[0225] As in the first embodiment, as shown in FIG. 11(b), the rental fee is reduced only when signals 1420 and 1422 are transmitted and received between the travel assistance device 20 and the MSS management device 30. The significance of signals 1420 and 1422 is as described in the first embodiment. When signal 1422 is received by the travel assistance device 20, the server-side controller 21 reduces the rental fee in the subsequent payment process 2300. In the second embodiment, signal 1420 may be included in the reservation inquiry signal 2210, and signal 2422 may be included in the response signal 2220 (see FIG. 20). Alternatively, signal 1420 may be included in the reservation request signal 2260, and signal 1422 may be included in the response signal 2270 (see FIG. 20).

[0226] Alternatively, the rental fee reduction may be implemented on the premise that a contract permitting the rental fee reduction has been concluded in advance between the operator of the travel assistance device 20 and the operator of the MSS. If such a contract has been concluded in advance, the rental fee reduction may be implemented without the need to send and receive signals 1420 and 1422. When the rental fee reduction is implemented, the server-side controller 21 may notify the user U1 through the user-side device 10 at any timing (for example, in the inquiry process 2240) of information indicating that the rental fee reduction will be implemented.

[0227] As in the first embodiment, as shown in FIG. 12, the server-side controller 21 according to the second embodiment includes a fee adjustment unit 21. ＦＥＥ The fee adjustment unit 21 ＦＥＥ This performs the processing required to implement the parking fee reduction (including the transmission and reception of signals 1410 and 1412) and the processing required to implement the rental fee reduction (including the transmission and reception of signals 1420 and 1422).

[0228] The reduction in parking fees or rental fees provides an incentive for user U1 to use the mobility support system. As a result, the use of the mobility support system is promoted. The actions and effects of promoting the use of the mobility support system are as described in Example EX2_1.

[0229] The benefit according to Example EX2_3 may be either a parking fee reduction or a rental fee reduction, or may include both a parking fee reduction and a rental fee reduction. When the benefit includes both a parking fee reduction and a rental fee reduction, the transmission and reception of the above-mentioned signals 1410 and 1412 and the transmission and reception of signals 1420 and 1422 may be performed. The reduction fee (amount of reduction) for the parking fee reduction may be different when the benefit includes both a parking fee reduction and a rental fee reduction and when the benefit includes only a parking fee reduction. Alternatively, the reduction fee (amount of reduction) for the rental fee reduction may be different when the benefit includes both a parking fee reduction and a rental fee reduction and when the benefit includes only a rental fee reduction. To realize these differences, the fee adjustment unit 21 ＦＥＥ The parking fee reduction and rental fee reduction may be determined based on a previously concluded tripartite contract. A tripartite contract refers to a contract between the operator of the mobility assistance device 20, the operator of the target parking lot, and the operator of the MSS. If the benefit includes both a parking fee reduction and a rental fee reduction, the parking lot server device 40 and the MSS management device 30 may be notified that both the parking fee reduction and the rental fee reduction will be provided by adding information indicating that the benefit includes both a parking fee reduction and a rental fee reduction to signals 1410 and 1420. The benefit is not limited to a parking fee reduction and a rental fee reduction. For example, the benefit may include a coupon that can be used at any market or store. The coupon may be an electronic voucher or discount coupon. Coupons are also sometimes referred to as points.

[0230] [Example EX2_4] Example EX2_4 will be described. Example EX2_4 assumes only case CS24 in which user U1 parks his / her vehicle V1 in a target parking lot, visits the consent recommended spot according to route plan P_B, and then returns to the target parking lot. Case CS24 corresponds to case CS23a described in example EX2_3. As described above, the server-side controller 21 includes a fee adjustment unit 21 as one of its functional blocks. ＦＥＥ In case CS24, the fee adjustment unit 21 ＦＥＥ The parking fee PF or the rental fee RF may be changed depending on the change factor (i.e., may be dynamically set). ＦＥＥ 1 shows how the parking fee PF and rental fee RF are set according to variable factors. As described above, the parking fee PF is the cost for parking the user's vehicle V1 in the target parking lot. The rental fee RF is the cost for the user U1 to rent an SR vehicle (target SR vehicle) at the target station in accordance with the usage plan P_Y.

[0231] The variable factors according to Example EX2_4 may include demand forecast data D2_4a, which is demand forecast data related to parking lots. The demand forecast data D2_4a is demand forecast data for the target parking lot during the time period when the host vehicle V1 is parked in the target parking lot according to the route plan P_B. The time period when the host vehicle V1 is parked in the target parking lot according to the route plan P_B is referred to as the predicted time period of the demand forecast data D2_4a. The predicted time period of the demand forecast data D2_4a is the time period from the start time t Ｓ , the estimated end time t of parking the vehicle V1 in the target parking lot. Ｅ The user-side controller 11 sets the time when the vehicle V1 arrives at the target parking lot or stops at the target parking lot as the start time t Ｓ can be considered as follows, and the start time t Ｓ is transmitted to the travel support device 20, the server-side controller 21 receives the start time t Ｓ The time indicated in the route plan P_B is the estimated end time t ＥFor example, in the example of FIG. 21, the end time of step 825 (16:30) is the scheduled end time t Ｅ is.

[0232] The demand forecast data D2_4a is data predicted, for example, when the plan creation process 2200 is executed, and indicates a predicted value of parking demand for the target parking lot during the predicted time period of the demand forecast data D2_4a. The parking lot server device 40 has a predictor that generates the demand forecast data D2_4a by predicting parking demand, and the predictor can be realized, for example, by artificial intelligence developed through machine learning. The parking lot server device 40 can generate the demand forecast data D2_4a based on the characteristics of the area in which the target parking lot is located and the weather during the predicted time period in the area in which the target parking lot is located. In response to a request from the mobility assistance device 20, the demand forecast data D2_4a is transmitted from the parking lot server device 40 to the mobility assistance device 20. Note that the server-side controller 21 may predict parking demand and generate the demand forecast data D2_4a.

[0233] The variable factors in Example EX2_4 may include demand forecast data D2_4b, which is demand forecast data related to SR vehicles. The demand forecast data D2_4b is demand forecast data for the time period during which user U1 rents the target SR vehicle at the target station in accordance with the usage plan P_Y, and is demand forecast data for SR vehicles in area A2_4b, which includes the rental point of the target SR vehicle. The rental point of the target SR vehicle is the target station. Area A2_4b may be an area of ​​a certain size and shape that includes the rental point of the target SR vehicle. In the examples of FIG. 21 or FIG. 23, area A2_4b may be, for example, an area within a circle with a certain radius centered on station 621. In the example of FIG. 22, area A2_4b may be, for example, an area within a circle with a certain radius centered at the midpoint between stations 621 and 631 (however, stations 621 and 631 are located within area A2_4b). In the example of FIG. 24 , area A2_4b may be, for example, an area within a circle with a certain radius and centered at the center of gravity between stations 621 and 632-634 (however, stations 621 and 632-634 are located within area A2_4b). The time period during which user U1 rents the target SR vehicle at the target station in accordance with usage plan P_Y is treated as the predicted time period of demand forecast data D2_4b. Therefore, in the example of FIG. 21 , the time period from the start time of step 822 to the end time of step 824 is treated as the predicted time period of demand forecast data D2_4b. In the example of FIG. 22 , the time period from the start time of step 842 to the end time of step 846 is treated as the predicted time period of demand forecast data D2_4b. Alternatively, in the example of FIG. 22 , the predicted time period of demand forecast data D2_4b may be composed of the time period between the start time and end time of step 842 and the time period between the start time and end time of step 846.

[0234] The demand forecast data D2_4b is data predicted, for example, when the plan creation process 2200 is executed, and indicates a predicted value of the demand for SR vehicles in area A2_4b during the predicted time period of the demand forecast data D2_4b. The MSS management device 30 has a predictor that generates the demand forecast data D2_4b by predicting the demand for SR vehicles. The predictor can be realized, for example, by artificial intelligence developed through machine learning. The MSS management device 30 can generate the demand forecast data D2_4b based on the characteristics of area A2_4b and the weather in area A2_4b during the predicted time period of the demand forecast data D2_4b. In response to a request from the travel support device 20, the demand forecast data D2_4b is transmitted from the MSS management device 30 to the travel support device 20. Note that the server-side controller 21 may predict the demand for SR vehicles to generate the demand forecast data D2_4b.

[0235] The variable factors according to the example EX2_4 may include walking distance data D2_4c. The walking distance data D2_4c is a walking distance d of the user U1 when the user U1 moves along the route plan P_B. ＦＯＯＴ The moving distance d ＦＯＯＴ is the total walking distance d of the user U1 when the user U1 moves along the route plan P_B. ＦＯＯＴ１ The total movement distance d ＦＯＯＴ１ is the sum of the movement distance of the user U1 in steps 821 and 825, and the total movement distance d ＦＯＯＴ１ is the total distance traveled by the user U1 in steps 881, 885, 887, and 889. The same applies to the examples in FIGS. 22 and 23. Alternatively, the travel distance d ＦＯＯＴ is the walking distance d of the user U1 along the route plan P_B until the user U1 arrives at the first station. ＦＯＯＴ２ The moving distance d in the example of FIG. ＦＯＯＴ２ is the travel distance of the user U1 in step 821, and the travel distance d ＦＯＯＴ２ is the distance traveled by the user U1 in step 881. The same applies to the examples in FIGS. 22 and 23. Alternatively, the distance traveled d ＦＯＯＴis the walking distance d of the user U1 along the route plan P_B from the last station to the target parking lot. ＦＯＯＴ３ The moving distance d in the example of FIG. ＦＯＯＴ３ is the travel distance of the user U1 in step 825, and the travel distance d ＦＯＯＴ３ is the distance traveled by the user U1 in step 889. The same applies to the examples in FIGS. 22 and 23. Alternatively, the travel distance d ＦＯＯＴ is the travel distance d ＦＯＯＴ２ and d ＦＯＯＴ３ It may also be the sum of

[0236] Fee adjustment unit 21 ＦＥＥ The fee adjusting unit 21 may set the parking fee PF or the rental fee RF according to a predetermined algorithm based on the variable factors according to the embodiment EX2_4. ＦＥＥ The fee adjusting unit 21 can increase the parking fee PF (or the rental fee RF) as the predicted value indicated by the demand forecast data D2_4a increases. ＦＥＥ The fee adjusting unit 21 can reduce the parking fee PF (or may reduce the rental fee RF) as the predicted value indicated by the demand forecast data D2_4a decreases. ＦＥＥ The fee adjusting unit 21 can increase the rental fee RF (or the parking fee PF) as the predicted value indicated by the demand forecast data D2_4b increases. ＦＥＥ The fee adjusting unit 21 can reduce the rental fee RF (or may reduce the parking fee PF) as the predicted value indicated by the demand forecast data D2_4b decreases. ＦＥＥ is the travel distance d indicated by the distance data D2_4c ＦＯＯＴ As the rate of the rental fee RF increases, the rental fee RF can be reduced (or the parking fee PF can be reduced). ＦＥＥ is the travel distance d indicated by the distance data D2_4c ＦＯＯＴ As the value of the parking fee PF decreases, the rental fee RF can be increased (or the parking fee PF can be increased).

[0237] The embodiment EX2_3 and the embodiment EX2_4 may be combined. That is, when the parking fee reduction is implemented, the fee adjustment unit 21 ＦＥＥ is the basic parking fee PF depending on the variable factors related to Example EX2_4. ＲＥＦ and reduced parking fees PF ＬＯＷ In addition, when a reduction in the rental fee is implemented, the fee adjustment unit 21 ＦＥＥ is the basic rental fee RF depending on the variable factors related to Example EX2_4. ＲＥＦ and Reduced Loan Rate RF ＬＯＷ The difference between the

[0238] Fee adjustment unit 21 based on fluctuation factors ＦＥＥ The parking fee PF set by is the reduced parking fee PF ＬＯＷ If it corresponds to the above, the fee adjustment unit 21 ＦＥＥ The setting of the parking fee PF by the fee adjustment unit 21 corresponds to the parking fee reduction described in the embodiment EX2_3. ＦＥＥ If the setting of the parking fee PF by the method corresponds to a parking fee reduction, the parking fee can be reduced according to the method described in the embodiment EX2_3 (see FIG. 11(a)). ＦＥＥ The rental fee RF set by is reduced rental fee RF ＬＯＷ If it corresponds to the above, the fee adjustment unit 21 ＦＥＥ The setting of the rental fee RF by the fee adjustment unit 21 corresponds to the rental fee reduction described in the embodiment EX2_3. ＦＥＥ If the setting of the rental fee RF by the above corresponds to a reduction in the rental fee, the rental fee reduction can be implemented according to the method described in the embodiment EX2_3 (see FIG. 11(b)).

[0239] The variable factors according to the example EX2_4 may include all or part of the data D2_4a, D2_4b, and D2_4c. The variable factors according to the example EX2_4 are not limited to the data D2_4a, D2_4b, and D2_4c. Various conditions (availability, waiting time until rental, etc.) when the user U1 rents an SR vehicle at the target station may be included in the variable factors according to the example EX2_4.

[0240] As described above, by varying the parking fee PF or rental fee RF according to the variable factors, it is expected that the use of the mobility assistance system will be promoted and the demand for parking spaces or SR vehicles will be leveled out.

[0241] [Example EX2_5] Example EX2_5 will be described. In the operation shown in Fig. 20, the server-side controller 21 transmits SR vehicle usage information to the user-side device 10. The SR vehicle usage information is, in detail, usage information for the SR vehicle to be lent to user U1 at the target station (hence the target SR vehicle).

[0242] For example, when the server-side controller 21 proposes the route plan P_B to the user U1 through the user-side device 10 (when outputting the route plan P_B to the user-side device 10), the server-side controller 21 may transmit (output) the SR vehicle usage information to the user-side device 10. In this case, the server-side controller 21 may transmit the SR vehicle usage information to the user-side device 10 together with the route plan P_B.

[0243] Alternatively, for example, the server-side controller 21 may propose the route plan P_B to the user U1 via the user-side device 10 (after outputting the route plan P_B to the user-side device 10) and then transmit (output) the SR vehicle usage information to the user-side device 10. That is, for example, the SR vehicle usage information may be transmitted from the travel assistance device 20 to the user-side device 10 together with the reservation confirmation signal 2280, or may be transmitted from the travel assistance device 20 to the user-side device 10 immediately after transmitting the reservation confirmation signal 2280. In either case, the SR vehicle usage information may be transmitted from the travel assistance device 20 to the user-side device 10 well before the user U1 arrives at the first station along the route plan P_B.

[0244] The SR vehicle usage information includes text and images showing how to use the SR vehicle (i.e., the target SR vehicle) to be rented to the user U1 at the target station, and the images may be lesson videos promoting safe operation of the SR vehicle. After the SR vehicle usage information is received by the user device 10, the user controller 11 displays the SR vehicle usage information on the display screen 14a, either at the request of the user U1 or independently of the request of the user U1.

[0245] It is expected that the transmission and reception of the SR vehicle usage information as described above will enable the user U1 to use the SR vehicle more smoothly.

[0246] [Embodiment EX2_6] Embodiment EX2_6 will be described. In embodiment EX2_6, the flow of operation of each controller will be described in accordance with the flow in Fig. 20. Figs. 26 and 27 are operation flowcharts of the server-side controller 21 and the user-side controller 11, respectively, in accordance with the flow in Fig. 20. However, in Figs. 26 and 27, it is assumed that the SR vehicle usage method information is transmitted and received immediately after the transmission and reception of the reservation confirmation signal 2280.

[0247] 26, the flow of operation of the server-side controller 21 will be described. Basically, the travel assistance device 20 operates at all times, and the server-side controller 21 continuously waits to receive various information from the user-side device 10. The server-side controller 21 receives the target parking lot information 2110 and the passenger count information 2120 (Y in step S211), and then starts receiving the current location information 2130 of user U1 (Y in step S212), and proceeds to step S213.

[0248] After starting to receive the current location information 2130, the server-side controller 21 performs a spot extraction process 2140 in step S213 at an arbitrary timing. The server-side controller 21 extracts one or more recommended spots in the spot extraction process 2140. After step S213, the process proceeds to step S214. In step S214, the server-side controller 21 transmits recommended spot information 2150 to the user-side device 10, and then in step S215, waits to receive visit desire information 2170 from the user-side device 10. When the server-side controller 21 receives the visit desire information 2170 (Y in step S215), the process proceeds to step S216.

[0249] In step S216, the server-side controller 21 executes a plan creation process 2200. The plan creation process 2200 creates a route plan P_B including an MSS usage plan P_Y. In step S217 following step S216, the server-side controller 21 transmits a reservation inquiry signal 2210 to the MSS management device 30. In the subsequent step S218, the server-side controller 21 waits to receive a response signal 2220 from the MSS management device 30. When the server-side controller 21 receives the response signal 2220 (Y in step S218), the process proceeds to step S219.

[0250] In step S219, the server-side controller 21 transmits the reservation availability information 2230 and the route plan P_B to the user-side device 10. In subsequent step S220, the server-side controller 21 waits to receive a use request signal 2250 from the user-side device 10. When the server-side controller 21 receives the use request signal 2250 (Y in step S220), the process proceeds to step S221. In step S221, the server-side controller 21 transmits a reservation request signal 2260 to the MSS management device 30. In subsequent step S222, the server-side controller 21 waits to receive a response signal 2270 from the MSS management device 30. When the server-side controller 21 receives the response signal 2270 (Y in step S222), the process proceeds to step S223.

[0251] The server-side controller 21 transmits a reservation confirmation signal 2280 to the user-side device 10 in step S223, and then transmits SR vehicle usage information in step S224. In subsequent step S225, the server-side controller 21 executes a payment process 2300. Execution of the payment process 2300 marks the end of the series of operations of the server-side controller 21 involving the proposal of the route plan P_B. When the server-side controller 21 waits to receive information or signals to be transmitted from the user-side device 10 or the MSS management device 30, if the necessary reception is not achieved within a predetermined waiting time, the server-side controller 21 performs appropriate processing, such as a prompting process or a termination process. In the prompting process by the server-side controller 21, a prompting signal is transmitted to the user-side device 10 or the MSS management device 30. The prompting signal is a signal requesting (prompting) the user-side device 10 or the MSS management device 30 to actually transmit the information or signals to be transmitted to the travel support device 20. In the termination process, the series of operations shown in FIG. 26 is terminated, and at this time, information for informing the user U1 of the reason for termination may be transmitted from the travel support device 20 to the user device 10.

[0252] The flow of operation of the user-side controller 11 will be described with reference to Figure 27. The operation of Figure 27 begins when the user-side controller 11 of the information terminal 10A starts executing the travel assistance application program, and the process proceeds to step S231. After that, when the target parking lot is determined (Y in step S231), the user-side controller 11 transmits target parking lot information 2110, which identifies which parking lot the target parking lot is, to the travel assistance device 20 in step S232. Meanwhile, before or after the arrival of the vehicle V1 at the target parking lot, the user-side controller 11 identifies the number of passengers by using a questionnaire or the like to the user U1. After identifying the number of passengers, in step S233, the user-side controller 11 transmits passenger number information 2120, which indicates the number of passengers, to the travel assistance device 20.

[0253] Furthermore, before or after the arrival of the vehicle V1 at the target parking lot, the user-side controller 11 starts an operation to periodically detect the current location of the user U1, and transmits current location information 2130 indicating the detection result to the wandering support device 20. After steps S231 to S233, the operation to transmit the current location information 2130 starts in step S234, and then the process proceeds to step S235. In step S235, the user-side controller 11 waits to receive recommended spot information 2150 from the wandering support device 20. When the user-side controller 11 receives the recommended spot information 2150 (Y in step S235), the process proceeds to step S236.

[0254] In step S236, the user-side controller 11 executes inquiry processing 2160 to notify user U1 of information about recommended spots and receives response information 2164 from user U1 in response to the notification. In subsequent step S237, the user-side controller 11 transmits visit request information 2170 corresponding to the response information 2164 to the excursion support device 20. After step S237, the process proceeds to step S241.

[0255] In step S241, the user-side controller 11 waits to receive the reservation availability information 2230 and the route plan P_B from the travel support device 20. When the user-side controller 11 receives the reservation availability information 2230 and the route plan P_B (Y in step S241), the process proceeds to step S242.

[0256] In step S242, the user-side controller 11 executes the inquiry process 2240 to notify the user U1 of the reservation availability information 2242 and the route plan P_B, and receives response information 2246 in response to the notification from the user U1. Then, in step S243, the user-side controller 11 transmits a usage request signal 2250 to the travel support device 20. In the following step S244, the user-side controller 11 waits to receive a reservation confirmation signal 2280 and SR vehicle usage information from the travel support device 20. When the user-side controller 11 receives the reservation confirmation signal 2280 and SR vehicle usage information (Y in step S244), the process proceeds to step S245. In step S245, the user-side controller 11 notifies the user U1 of the contents of the reservation confirmation signal 2280 by the notification process 2290. The handling of the SR vehicle usage information is as described in embodiment EX2_5. When the user-side controller 11 is waiting to receive information or a signal to be transmitted from the travel assistance device 20, if the necessary information or signal is not received for a predetermined waiting time or longer, the user-side controller 11 performs appropriate processing, such as a prompting process or a termination process. In the prompting process by the user-side controller 11, a prompting signal is sent to the travel assistance device 20. The prompting signal is a signal that requests (prompts) the travel assistance device 20 to actually transmit the information or signal to be transmitted to the user-side device 10. In the termination process, the series of operations shown in FIG. 27 is terminated, and at this time, the user-side controller 11 notifies the user U1 of the reason for termination.

[0257] 27 shows only the operations up to the notification process 2290. Although not particularly shown, after the notification process 2290, the terminal device 10A may perform a navigation operation to guide the user U1's actions along the route plan P_B.

[0258] [Example EX2_7] Example EX2_7 will be described. The user-side controller 11 can display any information received from the travel support device 20 on the display screen 14a. For example, the user-side controller 11 can display the route plan P_B or the usage plan P_Y on the display screen 14a. Fig. 28 shows how the route plan 820_B of Fig. 21 is displayed on the display screen of the terminal device 10A. Fig. 28 shows how the route plan 820_B is displayed in the form of a table, but the display form of the route plan 820_B is arbitrary. The same applies to the display of other route plans and usage plans.

[0259] [Embodiment EX2_8] Embodiment EX2_8 will be described. FIG. 29 shows a functional block diagram of the server-side controller 21. The server-side controller 21 is provided with functional blocks F221 to F225. The functions of the functional blocks F221 to F225 may be realized by the server-side controller 21 executing a program recorded in the memory 22 or any other recording medium. The functional block F221 is a transmission / reception unit. The transmission / reception unit F221 is responsible for transmitting and receiving any signals and information between the user-side device 10, the MSS management device 30, the parking lot server device 40, and the tour support device 20. The functional block F222 is an extraction processing unit that performs spot extraction processing 2140. The functional block F223 is a plan creation unit that performs plan creation processing 2200. The functional block F224 is a fee adjustment unit, and is the same as the fee adjustment unit 21 shown in FIG. 12 or FIG. 25. ＦＥＥ The functional block F225 is a payment processing unit that performs the payment process 2300.

[0260] FIG. 30 shows a functional block diagram of the user controller 11. The user controller 11 is provided with functional blocks F211 to F213. The functions of the functional blocks F211 to F213 may be realized by executing a program recorded in the memory 12 or any other recording medium on the user controller 11. If the user device 10 is considered to be the terminal device 10A, the functions of the functional blocks F211 to F213 may be realized by executing the above-mentioned travel assistance application program on the user controller 11. The functional block F211 is a transmission / reception unit. The transmission / reception unit F211 is responsible for sending and receiving any signals and information between the travel assistance device 20 and the user device 10. The functional block F212 is a user response unit. The user response unit F212 acquires input information from the user U1 to the user device 10 and is responsible for notifying the user U1 of various information. The user response unit F212 performs query processing 2160 and 2240 and notification processing 2290. The user response unit F212 also displays the route plan P_B or the utilization plan P_Y on the display screen 14a. The functional block F213 is a navigation unit that performs the above-mentioned navigation operation.

[0261] [Example EX2_9] Example EX2_9 will be described.

[0262] There may also be parking lots with stations attached. Parking lots with stations attached are called special parking lots. When a station is located within the parking lot premises, this also falls under the category of a station being attached. In other words, a station may be located within the premises of a special parking lot, or a station may be located adjacent to the premises of a special parking lot. A special parking lot may also be a target parking lot. When the target parking lot is a special parking lot, a station attached to the target parking lot may be incorporated into the target station.

[0263] The technology described above in the second embodiment basically assumes that user U1 is registered with the travel assistance device 20 through a user registration process, but the user registration process is not required. However, if the user registration process is not performed, user U1 must transmit information for establishing communication, including contact information, to the travel assistance device 20 via the user device 10. Furthermore, when having the server controller 21 perform the payment process 2300, user U1 must transmit payment information to the travel assistance device 20 via the user device 10. Furthermore, depending on the type of SR vehicle, age restrictions may be imposed on the use of the SR vehicle. Therefore, in order to properly create the MSS usage plan P_Y, user U1 may transmit the age or age group of the user and his / her companions to the travel assistance device 20 via the user device 10.

[0264] <<Third Embodiment>> A third embodiment of the present invention will be described. In the third embodiment, modified techniques or supplementary matters to the techniques described above will be described.

[0265] As long as there is no contradiction, the technology described in the first embodiment and the technology described in the second embodiment can be combined. For example, a target parking lot may be set using the method described in the first embodiment, and after the user U1 gets out of his / her vehicle V1 at the target parking lot, the spot extraction process 2140 and subsequent processes may be performed using the method described in the second embodiment. In this case, the destination in the first embodiment may be incorporated into one of the recommended spots, and a route plan P_B may be created that sequentially visits multiple recommended spots including the destination.

[0266] A program that causes a computer device to execute any of the methods described in each embodiment of the present invention, and a non-volatile recording medium on which the program is recorded, are included within the scope of the embodiments of the present invention. A program that causes a computer (computer device) to execute any of the methods described in the embodiments of the present invention may be a subprogram incorporated into or called by any main program. Each of the devices 10, 20, 30, and 40 is equipped with a computer capable of executing any of the programs. The processing units provided in each of the devices 10, 20, 30, and 40 may be considered to be computers. In particular, the method executed by the travel assistance device 20 can be referred to as a travel assistance method, and a program that causes a computer in the travel assistance device 20 to execute the travel assistance method can be referred to as a travel assistance program. Any of the processes in the embodiments of the present invention may be realized by hardware such as a semiconductor integrated circuit, software equivalent to the program, or a combination of hardware and software.

[0267] The embodiments of the present invention can be modified in various ways as appropriate within the scope of the technical ideas set forth in the claims. The above-described embodiments are merely examples of the present invention, and the meanings of the terms of the present invention and each constituent element are not limited to those described in the above-described embodiments. The specific numerical values ​​shown in the above description are merely examples, and as a matter of course, they can be changed to various numerical values.

[0268] REFERENCE SIGNS LIST 10 User-side device 10A Information terminal 10B Vehicle-mounted device 20 Travel assistance device 30 MSS management device 40 Parking lot server device DB1, DB2 Database NET Communication network U1 User V1 Vehicle 11 Controller (user-side controller) 11a Arithmetic processing unit 12 Memory 13 Communication unit 14a Display screen 14b Speaker 14c Microphone 14d Operation input unit 21 Controller (server-side controller) 21a Arithmetic processing unit 22 Memory 23 Communication unit TBL1 Registrant table TBL2 Management table

Claims

1. A mobility assistance method executed by a mobility assistance device, in which, when a user in a vehicle reaches a local area set based on a destination, information on target parking lots corresponding to the location of the destination and target stations of a mobility sharing service corresponding to the location of the target parking lots is output to a user-side device operated by the user.

2. The mobility support method described in claim 1, wherein when a user in the vehicle reaches the local area, a search area that includes the destination is set, one or more recommended parking lots are extracted from the multiple parking lots based on the positional relationship between the destination, multiple parking lots within the search area, and multiple stations of the mobility sharing service that are present within the search area, the one or more recommended parking lots are output to the user-side device as candidates for the target parking lot, and then one of the one or more recommended parking lots is identified as the target parking lot based on the user's response to the output.

3. The mobility support method described in claim 2, wherein when a user in the vehicle arrives at the local area, the one or more recommended parking lots are extracted based on the location relationship and the availability of each shared vehicle handled by the multiple stations.

4. A mobility support method as described in any one of claims 1 to 3, wherein after outputting information on the target parking lot and the target station, if a signal transmitted from the user device indicating a desire to use the target station is received, a rental reservation for the target shared vehicle to be made available to the user is output to a management device that manages the rental of a fleet of shared vehicles.

5. The mobility support method described in claim 4, wherein a benefit is given to the user when the user rents the target shared vehicle at the target station after parking the vehicle at the target parking lot through the output of the rental reservation.

6. The method of supporting mobility described in claim 5, wherein the benefit includes a reduction in the cost of parking the vehicle in the target parking lot or a reduction in the cost of renting the target shared vehicle.

7. The mobility support method described in claim 4, wherein when a user rents the target shared vehicle through the rental reservation, the cost of parking the vehicle in the target parking lot or the cost of renting the target shared vehicle is varied according to variable factors, and the variable factors include at least one of demand forecast data for the target parking lot during the time period when the vehicle is parked in the target parking lot, demand forecast data for the time period when the user rents the target shared vehicle and for shared vehicles in an area that includes the rental point of the target shared vehicle, and the distance between the target parking lot and the target station.

8. A travel support method according to any one of claims 1 to 3, wherein information on how to use the shared vehicle that is available for rental at the target station is output to the user device.

9. A mobility assistance device configured to enable two-way communication with a user-side device operated by a user, which, when a user in a vehicle reaches a local area set based on a destination, outputs to the user-side device information on target parking lots according to the location of the destination and target stations of a mobility sharing service according to the location of the target parking lots.

10. A user-side device that receives information about the target parking lots and the target stations from the travel assistance device described in claim 9 and notifies the received information about the target parking lots and the target stations.

11. A mobility assistance system comprising: a user-side device operated by a user; and a mobility assistance device configured to enable two-way communication with the user-side device, wherein when a user in a vehicle reaches a local area set based on a destination, the mobility assistance device outputs to the user-side device information on target parking lots corresponding to the location of the destination and target stations of a mobility sharing service corresponding to the location of the target parking lots; and the user-side device receives information on the target parking lots and the target stations from the mobility assistance device and notifies the user of the received information on the target parking lots and the target stations.

12. A wandering assistance program that causes a computer in a wandering assistance device configured to be capable of two-way communication with a user-side device operated by a user to execute the wandering assistance method described in any one of claims 1 to 3.

13. A user-side program executed on a computer in a user-side device operated by a user, which causes the computer to perform the following steps: determining whether a user in a vehicle has reached a local area set based on a destination; transmitting a local area entry signal to a mobility assistance device wirelessly connected to the user-side device in response to determining that the user in the vehicle has reached the local area; and, after transmitting the local area entry signal, notifying, based on information received from the mobility assistance device, of target parking lots corresponding to the location of the destination and target stations of a mobility sharing service corresponding to the location of the target parking lots.

14. A mobility support method executed by a mobility support device, which outputs recommended spots that are recommended to be visited and a route plan for the user to visit the recommended spots to a user device operated by the user, and the route plan includes a plan for using a mobility sharing service when the user travels to the recommended spots.

15. A travel assistance method as described in claim 14, wherein when the travel assistance device receives a consent signal transmitted from the user device indicating that the user agrees to the route plan, a rental reservation for the target shared vehicle is output to a management device that manages the rental of a fleet of shared vehicles in accordance with the usage plan.

16. The travel assistance method described in claim 15, wherein the route plan includes a plan for the user to travel from their current location to a station of the mobility sharing service, from when the user rents the target shared vehicle at the station, to when the user arrives at the recommended spot in the target shared vehicle.

17. The mobility support method of claim 15, wherein, when the route plan is output while the user has parked the vehicle in a parking lot, the route plan includes a plan for the user to visit the recommended spot and arrive at the parking lot using the target shared vehicle, which is made up of one or more shared vehicles, from the user's current location, passing through one or more stations of the mobility sharing service.

18. The travel assistance method described in claim 15, wherein the route plan is a user's action plan when the user visits a plurality of recommended spots in order, and includes a plan for the user to visit the plurality of recommended spots in order from the user's current location using the target shared vehicle, which consists of one or more shared vehicles, passing through one or more stations of the mobility sharing service.

19. The mobility support method described in claim 15, wherein the route plan is a user's action plan when the user visits a plurality of recommended spots in order, and when the route plan is output while the user has parked the vehicle in a parking lot, the route plan includes a plan for the user to visit the plurality of recommended spots in order using the target shared vehicle, which is made up of one or more shared vehicles, from the user's current location, passing through one or more stations of the mobility sharing service, and then arrive at the parking lot.

20. A mobility support method as described in any one of claims 15 to 19, wherein when a user rents the target shared vehicle through the rental reservation made by the mobility support device, a benefit is given to the user.

21. The travel assistance method described in claim 20, wherein the benefit includes a reduction in the cost of renting the target shared vehicle.

22. A travel assistance method as described in claim 15, 16 or 18, wherein when the route plan is output while the user has parked the vehicle in a parking lot and the user rents the target shared vehicle through the rental reservation made by the travel assistance device, a benefit is given to the user, the benefit including a reduction in the cost of parking the vehicle in the parking lot or a reduction in the cost of renting the target shared vehicle.

23. A mobility support method as described in any of claims 15 to 19, wherein when a user rents the target shared vehicle through the rental reservation, the cost for the user to rent the target shared vehicle is varied according to variable factors, and the variable factors include at least one of demand forecast data for the time period when the user rents the target shared vehicle and for shared vehicles in an area including the rental point of the target shared vehicle, and the walking distance traveled by the user when traveling in accordance with the usage plan.

24. A method for supporting travel as described in claim 15, 16 or 18, wherein, when the route plan is output with the user parking the vehicle in a parking lot and the user rents the target shared vehicle through the rental reservation, the cost of parking the vehicle in the parking lot or the cost of the user renting the target shared vehicle is varied according to variable factors, and the variable factors include at least one of demand forecast data for the parking lot during the time period when the vehicle is parked in the parking lot, demand forecast data for shared vehicles during the time period when the user rents the target shared vehicle and in an area including the rental point of the target shared vehicle, and the walking distance traveled by the user when traveling in accordance with the usage plan.

25. A travel support method according to any one of claims 15 to 19, wherein information on how to use the target shared vehicle is output to the user device.

26. A travel assistance device configured to enable two-way communication with a user-side device operated by a user, which outputs to the user-side device recommended spots that the user is recommended to visit and a route plan for the user to visit the recommended spots, and the route plan includes a plan for using a mobility sharing service when the user travels to the recommended spots.

27. A user-side device that receives the route plan from the travel assistance device according to claim 26 and notifies the user of the received route plan.

28. A wandering assistance system comprising: a user-side device operated by a user; and a wandering assistance device configured to be capable of two-way communication with the user-side device, wherein the wandering assistance device outputs to the user-side device recommended spots that are recommended to be visited and a route plan for the user to visit the recommended spots, and the route plan includes a plan for using a mobility sharing service when the user travels to the recommended spots.

29. A wandering assistance program that causes a computer in a wandering assistance device configured to be capable of two-way communication with a user-side device operated by a user to execute the wandering assistance method described in any one of claims 14 to 19.

30. A user-side program executed on a computer in a user-side device operated by a user, which causes the computer to execute a step of notifying information received from a travel assistance device configured to enable two-way communication with the user-side device, the information being related to recommended spots that are recommended to be visited and a route plan for the user when visiting the recommended spots, wherein the route plan includes a plan for using a mobility sharing service when the user travels to the recommended spots.

Images