JP7547543B2 - Vehicle guide device - Google Patents

Description

This disclosure relates to a vehicle guidance device.

There is a known technology that provides information about available taxis from each taxi company to a mobile communication device.

JP 2009-211582 A

However, with conventional technology, it is difficult to provide appropriate in-car guidance to passengers in vehicles that travel or shuttle along a predetermined route that includes multiple boarding and alighting locations and that multiple users can board and alight from (hereinafter referred to as "routed line vehicles").

In recent years, the aging of the population has led to an increase in the importance of route vehicles such as route buses, and efforts are being made to utilize them in areas with high car usage rates. Currently known route vehicles generally only travel on fixed routes, so there is room for improving convenience in areas with a small number of users. On the other hand, if it is possible to change the route, it is useful to prevent route changes without the knowledge of the route vehicle's occupants, thereby making it less likely that occupants will become dissatisfied due to route changes.

Therefore, in one aspect, the present invention aims to provide appropriate in-vehicle guidance in a vehicle that travels around or round trips along a predetermined route and is accessible to multiple users.

In one aspect, the following solution is provided:

(1) A vehicle guidance device applicable to a vehicle that travels or travels back and forth along a predetermined course including a plurality of boarding and alighting positions and that allows a plurality of users to board and alight, the device providing, based on a change in a planned travel course of the vehicle from the predetermined course to another course while the vehicle is traveling along the predetermined course, changed course information representing the other course, timetable information relating to at least one of the plurality of boarding and alighting positions, the timetable information representing a planned arrival time of the vehicle, and guidance specific to a specific user based on identification information of a user currently aboard;
The device is characterized by outputting the above information inside the vehicle.

(2) In the configuration of (1) above, the planned disembarking location of each user on board is stored in association with the user's identification information, and when the vehicle stops at a certain location, a guide encouraging the user to disembark is further output inside the vehicle to the user whose identification information is associated with the planned disembarking location corresponding to the location.

(3) In the configuration of (1) above, when the planned driving course is changed to the other course, an advertisement related to the other course is further output in the vehicle.

(4) In the configuration of (1) above, when the planned travel course is changed to the other course, a change of the planned disembarkation location to a new location where the vehicle can stop due to the change to the other course is accepted.

(blank)

(5) In the configuration of (1) above, the guidance is output via an output device attached to the back of the backrest of the seat in front of the corresponding user.

(6) In the configuration of (1) above, the guidance is output from a movable audio speaker in the vehicle that moves close to the corresponding user, or is output in the direction of the corresponding user via a speaker with variable directionality.

In one aspect, the present invention makes it possible to provide appropriate in-vehicle guidance in a vehicle that travels around or round trips along a predetermined route and is accessible to multiple users.

FIG. 1 is a diagram showing a schematic diagram of a section of an area to which a route bus system is applied. 1 is a diagram illustrating an overall configuration of a route bus system according to an embodiment of the present invention; FIG. 2 is a top view showing a schematic view of the inside of a route bus. FIG. 2 is a schematic diagram showing an example of the configuration of a control system for a route bus. FIG. 2 is a functional block diagram showing an example of functions of the processing device. FIG. 2 is a functional block diagram showing an example of a function of a server. FIG. 11 is an explanatory diagram of an example of reservation status information. FIG. 4 is an explanatory diagram of an example of seat state information. FIG. 2 is an explanatory diagram of an example of rideable section information. FIG. 11 is an explanatory diagram of a course change process performed by a course change processing unit. FIG. 11 is an explanatory diagram of an example of course change determination information. FIG. 11 is an explanatory diagram of another example of course change determination information. FIG. 2 is an explanatory diagram of an example of timetable information. FIG. 4 is an explanatory diagram of an example of advertisement information. FIG. 4 is an explanatory diagram of an example of user information. FIG. 11 is an explanatory diagram of an example of output of operation information. FIG. 13 is an explanatory diagram of an example of output of boarding area information. FIG. 11 is an explanatory diagram of an example of output of operation information suitable for a case where a plurality of route buses are operating simultaneously. FIG. 13 is an explanatory diagram of an example of an output screen for accepting a boarding request. FIG. 13 is an explanatory diagram of another example of output of the boarding request acceptance screen. FIG. 13 is an explanatory diagram of another example of output of the boarding request acceptance screen. 13 is an explanatory diagram of an example of an output of a boarding request acceptance screen when a user is accompanied by a companion. FIG. 13 is an explanatory diagram of an example of an output of a boarding request acceptance screen when a margin of error is included. FIG. 2 is an explanatory diagram showing an example of projector arrangement. FIG. 1 is a diagram illustrating an example of a configuration of a projector. FIG. 13 is a diagram showing an example of a map used to control the projection direction of a projector. FIG. 13 is an explanatory diagram showing an example of mounting a projector according to a modified example. FIG. 2 is a diagram illustrating an example of a hardware configuration of a gesture recognition device. 11 is a timing chart showing an example of information exchange for reservation acceptance realized by a projector, a gesture recognition device, and a server. 10 is a schematic flowchart showing an example of an operation when the server functions as an information output device. 23 is a schematic flowchart showing an example of step S322 (boarding eligibility determination process) of FIG. 22. 23 is a schematic flowchart showing another example of step S322 (boarding eligibility determination process) of FIG. 22. 23 is a schematic flowchart showing an example of step S326 (course change possibility determination process) of FIG. 22. 26 is a schematic flowchart showing an example of step S352 (inter-route bus cooperation processing) of FIG. 25. 26 is a schematic flowchart showing another example of step S352 (inter-route bus cooperation processing) of FIG. 25.

Each embodiment will be described in detail below with reference to the attached drawings.

Figure 1 is a schematic diagram showing an area to which a route bus system 1 (see Figure 2) according to the following embodiment is applied.

In FIG. 1, an area of 6×3+4×3=30 sections is shown. The area is preferably an area with many slopes, but may be a flat area. The number of sections and the shape are arbitrary. Each section may have residents' houses and shops. In FIG. 1, bus stops A1, A2, A3, and A10 of a route bus (one example of a vehicle) 2 (see FIG. 2) described below are shown. The arrangement and number of bus stops are arbitrary. In the following, as an example, the route bus 2 travels from stop A1 to stop A10, then from stop A10 to stop A1, and so on, traveling back and forth along a predetermined course. However, in a modified example, the route bus 2 may travel in a circular manner along a predetermined course.

There may be only one route bus 2 in operation, or multiple routes may be in operation at the same time.

Figure 2 is a diagram showing the overall configuration of a route bus system 1 according to one embodiment.

In this embodiment, as an example, the route bus system 1 can be used by registered users. In the following description, for the sake of explanation, a user refers to a user of the route bus system 1, and a passenger on the route bus 2 refers to a user currently on board. However, the route bus system 1 can also be used by users other than registered users, for example, if the user is a companion of a registered user. In a modified example, the route bus system 1 may be available to unspecified users without requiring registration.

The route bus system 1 includes a route bus 2, a server 4, a user terminal 6, a projector 7, and a gesture recognition device 8. The route bus 2, the server 4, the projector 7, and the user terminal 6 are capable of communicating with each other via a network 9. The network 9 includes a wireless communication network, and may also include the Internet, a VPN (Virtual Private Network), a WAN (Wide Area Network), a wired network, or any combination of these.

[Local bus]
FIG. 3 is a top view showing the interior of the route bus 2 with the roof removed.

In this embodiment, as an example, route bus 2 is a small bus with a capacity of eight people. Specifically, route bus 2 has four rows of two-seater seats. Eight seats S0 to S7 are shown in FIG. 3. Note that the number and arrangement of seats are arbitrary.

The route bus 2 has, for example, a sliding door type to facilitate boarding and disembarking. The route bus 2 has an aisle that allows access to each seat.

Route bus 2 is equipped with a large display D1 at the front of the interior. Route bus 2 also has individual displays D2 to D7 on the back of each seat. For example, display D2 is attached to the seat in front of seat S2, i.e., the back of seat S0, so that it is available to the user sitting in seat S2. Note that in a modified example, other types of display devices (for example, a projector or an aerial display) may be used in place of or in addition to some or all of large display D1 and displays D2 to D7. An aerial display is a device that generates images by focusing light in the air. A head-up display or the like may also be used.

The route bus 2 is equipped with a movable speaker 3a. The speaker 3a is movable on an aisle that allows access to each seat. The speaker 3a may be in the form of a robot, for example, and in the case of a robot, it may be a bipedal or wheeled type. In a modified example, a speaker with variable directionality may be used instead of or in addition to the movable speaker 3a. In a further modified example, the movable speaker 3a may be omitted. In addition to or in addition to the speaker 3a, a speaker may be built into the displays D2 to D7, or a speaker may be provided in another location.

The route bus 2 is equipped with a camera 3b that captures images of the interior of the bus. In Fig. 3, one camera 3b is attached to the front of the interior of the bus facing backward, but a plurality of cameras 3b may be provided.
The camera 3b is provided to obtain images for recognizing an occupant, but the images from the camera 3b may be used for other purposes (e.g., security, etc.).

Figure 4 is a schematic diagram showing an example of the configuration of the control system of route bus 2.

The control system of the route bus 2 includes a processing device 10. The processing device 10 is connected to various electronic devices 30 (speaker 3a, large display D1, displays D2 to D7, camera 3b, etc.) in the vehicle via an appropriate bus such as a controller area network (CAN).

The electronic device 30 includes the speaker 3a, large display D1, displays D2 to D7, and camera 3b described above, as well as an input device 3, an autonomous driving sensor 3c, a braking/driving force control device 3d, a steering control device 3e, and a GPS receiver 3f.

The input device 3 is a device for passengers to input various instructions. The input device 3 may be in the form of a remote controller or the like, and may be provided at each seat. Alternatively, the input device 3 may be realized by a touch panel that may be built into the displays D2 to D7. Alternatively, the input device 3 may be realized by a voice recognition device or a gesture recognition device that may be mounted inside the route bus 2. In this case, the voice recognition device or the gesture recognition device may be realized by a speaker 3a in the form of a robot.

The autonomous driving sensor 3c is a sensor necessary or useful for autonomous driving, such as a radar sensor (e.g., a millimeter wave radar sensor), an image sensor (e.g., a stereo camera), a LiDAR (lidar), a gyro sensor, an acceleration sensor, etc. For autonomous driving, the electronic device 30 may be equipped with a vehicle-to-vehicle communication device, a road-to-vehicle communication device, etc., in addition to the autonomous driving sensor 3c.

The braking/driving force control device 3d includes a brake ECU (Electronic Control Unit) as a braking force control device, an engine ECU as a driving force control device, and the like.
The brake ECU controls the braking force by controlling the master cylinder pressure of the wheels according to the target braking force. The engine ECU controls the driving force by controlling the fuel injection amount of the engine according to the target driving force. If the route bus 2 is an electric or hybrid type, the braking/driving force control device 3d may include an ECU that controls the running motor as a driving force control device.

The steering control device 3e controls the steering device according to the target steering angle.

The GPS receiver 3f receives radio waves from GPS satellites (or GNSS: Global Navigation Satellite System satellites) and calculates the position of the route bus 2.

The processing device 10 is in the form of a computer and may be embodied, for example, as an ECU (Electronic Control Unit). As shown in FIG. 4, the processing device 10 includes a CPU (Central Processing Unit) 11, a RAM (Random Access Memory) 12, a ROM (Read Only Memory) 13, an auxiliary storage device 14, a drive device 15, and a communication interface 17, all connected by a bus 19, as well as a wired transceiver 25 and a wireless transceiver 26 connected to the communication interface 17.

The auxiliary storage device 14 is, for example, a hard disk drive (HDD), an electrically erasable programmable read-only memory (EEPROM), or a solid state drive (SSD), and is a storage device that stores data related to application software, etc.

The wired transceiver 25 includes a transceiver capable of communicating using a wired network. The wired transceiver 25 is connected to the electronic device 30. However, some or all of the electronic device 30 may be connected to the bus 19 or to the wireless transceiver 26.

The wireless transceiver 26 is a transceiver capable of communicating using the network 9 (see FIG. 2). The wireless transceiver 26 may also include a near field communication (NFC) unit, a Bluetooth (registered trademark) communication unit, a Wi-Fi (Wireless-Fidelity) transceiver unit, an infrared transceiver unit, etc.

The processing device 10 may be connectable to a recording medium 16. The recording medium 16 stores a specific program. The program stored in the recording medium 16 is installed in the auxiliary storage device 14 of the processing device 10 via the drive device 15. The installed specific program can be executed by the CPU 11 of the processing device 10. For example, the recording medium 16 may be a recording medium that records information optically, electrically or magnetically, such as a CD (Compact Disc)-ROM, a flexible disk, or a magneto-optical disk, or a semiconductor memory that records information electrically, such as a ROM or a flash memory.

Figure 5 is a functional block diagram showing an example of the functions of the processing device 10.

The processing device 10 includes a planned driving course receiving unit 102, a timetable information receiving unit 103, a sensor information acquiring unit 104, a vehicle position information acquiring unit 106, a target braking/driving force determining unit 108, a target steering angle determining unit 110, an occupant state detecting unit 112, an information output control unit 114, and an occupant request transmitting unit 116. The planned driving course receiving unit 102, the timetable information receiving unit 103, the sensor information acquiring unit 104, the vehicle position information acquiring unit 106, the target braking/driving force determining unit 108, the target steering angle determining unit 110, the occupant state detecting unit 112, the information output control unit 114, and the occupant request transmitting unit 116 can be realized by the CPU 11 executing a program in a storage device (e.g., ROM 13). The processing device 10 also includes a planned driving course memory unit 120. The planned driving course memory unit 120 can be realized, for example, by the auxiliary storage device 14.

The planned driving course receiving unit 102 receives information representing the planned driving course (hereinafter also referred to as "course information") from the server 4. In this embodiment, the planned driving course is determined as a basic course, but as described below, it is changed from the basic course in certain cases. Note that the server 4 may transmit the changed course to the route bus 2 only when the planned driving course is changed from the basic course to another course.

The timetable information receiving unit 103 receives information representing a timetable (hereinafter referred to as "timetable information") from the server 4. In this embodiment, the planned travel route may be changed to a route other than the basic route. Such a change in route may change the scheduled arrival time at a bus stop, etc., so a timetable that reflects such a change in the scheduled arrival time is useful for users waiting for arrivals.

The sensor information acquisition unit 104 acquires various information from the autonomous driving sensor 3c.

The vehicle position information acquisition unit 106 acquires vehicle position information from the GPS receiver 3f. The vehicle position information acquisition unit 106 transmits the acquired vehicle position information to the server 4.

The target braking/driving force determination unit 108 determines the target driving force. For example, the target driving force is determined so as to travel at a constant speed at a predetermined cruising speed (e.g., 20 km/h). The target braking/driving force determination unit 108 also determines the target braking force as necessary based on various information from the autonomous driving sensor 3c. For example, if an obstacle is detected, the target braking force is determined so as to stop the vehicle in front of the obstacle. When the target braking/driving force determination unit 108 determines the target driving force and the target braking force, it provides the determined target driving force and target braking force to the braking/driving force control device 3d. Note that the predetermined cruising speed may be variable, in which case the predetermined cruising speed may be instructed from the server 4.

The target steering angle determination unit 110 determines the target steering angle. The target steering angle may be set based on the recognition results of white lines on the road extending along the planned driving course. Alternatively, the target steering angle may be determined based on the relationship between the trajectory of the planned driving course and the current position and orientation of the route bus 2. After determining the target steering angle, the target steering angle determination unit 110 provides the determined target steering angle to the steering control device 3e.

In this way, the target braking/driving force determination unit 108 and the target steering angle determination unit 110 cooperate with the braking/driving force control device 3d and the steering control device 3e to realize autonomous driving of the route bus 2 so that the route bus 2 travels along the planned driving course based on various information from the autonomous driving sensor 3c.

The passenger status detection unit 112 detects the status of passengers in the route bus 2 based on information from the camera 3b. The status of the passengers to be detected includes the passenger's seat (which seat is occupied),
and the user ID of the passenger. The user ID of the passenger may be derived by pattern matching between a preregistered face image of the user and each face image portion in the image from the camera 3b. Alternatively, in the case where a method of waving an ID card when boarding and/or disembarking is adopted, the user ID may be obtained from the ID card. The ID card may be a magnetic card created at the time of user registration. The ID card may be a card electronically stored in the user terminal 6. In this case, the user terminal 6 transmits the user ID to a receiver (not shown) provided on the route bus 2 by short-range communication.

The occupant status detection unit 112 may detect the status of the occupant periodically or for each planned stop location (planned stop location for boarding and disembarking), including a bus stop. The occupant status detection unit 112 transmits information indicating the detected status of the occupant (hereinafter also referred to as "occupant status information") to the server 4.

The information output control unit 114 outputs various information to passengers on the route bus 2 via the speaker 3a, the large display D1, the displays D2 to D7, etc. The various information and the output methods thereof will be described in detail later.

The occupant request transmission unit 116 transmits various requests from the occupant (e.g., a request to change the planned disembarkation location) to the server 4. The various requests from the occupant may be input via the input device 3.

The planned driving course memory unit 120 stores course information. The default course information stored in the planned driving course memory unit 120 represents the basic course, but when the planned driving course receiving unit 102 receives course information representing another course (changed course) as described above, the course information in the planned driving course memory unit 120 is replaced (overwritten) with the received course information. Note that in a situation where multiple route buses 2 are operating simultaneously, course information is stored for each of the multiple route buses 2.

[server]
The server 4 is formed of a server computer. The server 4 may be formed of multiple server computers. For example, the server 4 may be realized by a cloud computer. The server 4 may also be realized by a computer mounted on the route bus 2. The server 4 may also be realized by a computer mounted on one route bus 2, or may be realized by multiple computers mounted on each of the multiple route buses 2 working together. Furthermore, the server 4 may also be realized by a computer mounted on the route bus 2 and a computer not mounted on the route bus 2 working together.

Figure 6 is a functional block diagram showing an example of the functions of server 4.

The server 4 includes a boarding available section derivation unit 400, a boarding request receiving unit 401, a boarding eligibility determination unit 402, a user identification unit 404, a reservation acceptance unit 405, a planned disembarkation location change receiving unit 406, a course change processing unit 407, a timetable generation unit 408, a vehicle status update unit 409, a seat status update unit 410, an output control unit 411, a user registration processing unit 412, and a gesture input processing unit 414. The boarding available section derivation unit 400, boarding request receiving unit 401, boarding availability determination unit 402, user identification unit 404, reservation acceptance unit 405, planned disembarkation location change receiving unit 406, course change processing unit 407, timetable generation unit 408, vehicle status update unit 409, seat status update unit 410, output control unit 411, user registration processing unit 412, and gesture input processing unit 414 can be realized by a CPU such as CPU 11 executing a program in a storage device (e.g., a storage device such as ROM 13).

The processing device 10 also includes a reservation status information storage unit 420, a rideable section storage unit 421, a user information storage unit 422, a course change determination information storage unit 423, a vehicle status information storage unit 424, a seat status information storage unit 425, a planned driving course storage unit 426, a timetable information storage unit 428, and an advertisement information storage unit 430. The reservation status information storage unit 420, the rideable section storage unit 421, the user information storage unit 422, the course change determination information storage unit 423, the vehicle status information storage unit 424, the seat status information storage unit 425, the planned driving course storage unit 426, the timetable information storage unit 428, and the advertisement information storage unit 430 can be realized by an auxiliary storage device such as the auxiliary storage device 14. Any two or more of the reservation status information storage unit 420, the boardable section storage unit 421, the user information storage unit 422, the course change determination information storage unit 423, the vehicle status information storage unit 424, the seat status information storage unit 425, the planned travel course storage unit 426, the timetable information storage unit 428, and the advertisement information storage unit 430 may be integrated into a single storage unit.

In addition, in a configuration in which multiple route buses 2 can operate simultaneously, the boarding available section derivation unit 400, the boarding request receiving unit 401, the boarding availability determination unit 402, the reservation receiving unit 405, the planned disembarking position change receiving unit 406, the course change processing unit 407, the timetable generating unit 408, the vehicle status update unit 409, the seat status update unit 410, the output control unit 411, the reservation status information storage unit 420, the boarding available section storage unit 421, the course change determination information storage unit 423, the vehicle status information storage unit 424, the seat status information storage unit 425, the planned driving course storage unit 426, the timetable information storage unit 428, and the advertisement information storage unit 430 function for each route bus 2. However, as will be described later, the course change processing unit 407 may function commonly for multiple route buses 2 in order to take into account the operating status of the multiple route buses 2.

The boardable section derivation unit 400 derives a boardable section, which is a section where a user can board the route bus 2, based on the reservation status information in the reservation status information storage unit 420 (see FIG. 7A) and the seat status information in the seat status information storage unit 425 (see FIG. 7B). For example, if the route bus 2 is currently full, the boardable section starts from a position where the route bus 2 is no longer full (a planned disembarking position where a passenger will disembark). The boardable section is basically up to the end point, but may be up to a position before the end point in order to adjust the priorities between multiple users. For example, if user A has previously reserved a ride from planned stop position A3, and the route bus 2 becomes full when user A boards at planned stop position A3, the boardable section for user B, who makes a reservation after user A, is up to position A3. Note that if the route bus 2 is not full and there is no user who has made a reservation earlier, the boardable section is the entire section.

When the boarding available section derivation unit 400 derives the boarding available section, it generates information representing the boarding available section (hereinafter referred to as "boarding available section information") (see Figure 7C) and stores it in the boarding available section storage unit 421. In Figure 7C, the number of passengers that can board is stored along with the boarding available section. In this case, the boarding available section derivation unit 400 calculates the number of passengers that can board for each boarding available section along with the boarding available section.

The boarding request receiving unit 401 receives a boarding request transmitted from the user terminal 6 described below. The boarding request represents a request from a user wishing to board, and includes information representing the planned boarding location (desired boarding location) and the planned disembarking location (desired disembarking location), as described below. The user wishing to board generates a boarding request in a manner that specifies the planned boarding location and the planned disembarking location. In addition, as described below, the boarding request can optionally include other information, such as information representing the desired arrival time at the planned disembarking location (e.g., the latest acceptable time) and information representing the number of accompanying persons, if any. In the following, the user related to the boarding request refers to the user who issued the boarding request (the user who is attempting to make a boarding reservation by the boarding request).

When a boarding request is acquired, the boarding possibility determination unit 402 performs a boarding possibility determination process to determine whether or not the user related to the boarding request is able to board (board the route bus 2). For example, the boarding possibility determination unit 402 determines whether or not the user is able to board based on the planned boarding location and planned disembarking location included in the boarding request. In this case, the boarding possibility determination unit 402 can use the boarding possibility section information (see FIG. 7C) in the boarding possibility section storage unit 421. In other words, if the planned boarding location and the planned disembarking location are within the boarding possibility section, the boarding possibility determination unit 402 determines that the user related to the boarding request is able to board.

As described above, the boarding section is derived based on the seat status information (see FIG. 7B) in the seat status information storage unit 425. Therefore, when using the boarding section information in the boarding section storage unit 421, the boarding eligibility determination process is executed based on the upper limit of the number of users who can board the route bus 2 (number of seats), the current number of passengers, and the planned disembarking locations of the passengers. This allows the boarding eligibility determination process to be performed in a manner that takes into account the increase in vacant seats due to passengers disembarking, improving the accuracy of the boarding eligibility determination.

As described above, the boarding availability section is derived based on the reservation status information (see FIG. 7A) in the reservation status information storage unit 420. Therefore, when using the boarding availability section information in the boarding availability section storage unit 421, the boarding availability determination process is executed taking into account the number of users who will be boarding the route bus 2 in the future and the planned disembarking locations of those users. This further improves the accuracy of the boarding availability determination process.

In addition, when the boarding request includes information about a companion, the boarding eligibility determination unit 402 determines whether all passengers, including the companion, can board. In the case of reservation status information in the reservation status information storage unit 420 (see FIG. 7A), the number of passengers that can board is stored, so that information about the number of passengers that can board can be used to determine whether all passengers, including the companion, can board.

In addition, when the boarding request includes information on the desired arrival time and the margin of safety, the boarding availability determination unit 402 may perform boarding availability determination processing in a manner that takes the desired arrival time into consideration, based on the timetable information in the timetable information storage unit 428. Specifically, the boarding availability determination unit 402 determines whether the user can board based on the relationship between the scheduled arrival time and the desired arrival time at the planned disembarking location. In this case, if the scheduled arrival time is earlier than the desired arrival time, it is determined that the user can board. Furthermore, the boarding availability determination unit 402 may determine whether the user can board based on the relationship between the scheduled arrival time and the desired arrival time at the planned disembarking location and the margin of safety. In this case, the boarding availability determination unit 402 may perform boarding availability determination processing in a manner in which the higher the margin of safety, the more likely it is that a delay in the desired arrival time relative to the scheduled arrival time is to be tolerated.

When determining whether or not a passenger can board the vehicle, the priority between multiple users may be taken into consideration. In this case, the priority between multiple users is passenger > user (user with reservation), and among users with reservations, the user who made the reservation first > user who will make the reservation later, but there may be exceptions. For example, the attributes of the user (wheelchair user, crutch user, blindness, etc.) may be taken into consideration, and priority may be given to, for example, elderly people and people with disabilities.

In addition, in a situation where multiple route buses 2 are operating simultaneously, in response to a boarding request that does not specify a specific route bus 2, the boarding availability determination unit 402 may determine which of the multiple route buses 2 the user can board based on the boarding availability section information of the multiple route buses 2.

The user identification unit 404 identifies a user ID (user ID related to the user who transmitted the boarding request) used when updating reservation status information, such as a user ID related to a boarding request. Here, boarding requests include boarding requests transmitted from the user terminal 6, as described below, and boarding requests generated by the gesture input processing unit 414 based on gesture recognition results transmitted from the gesture recognition device 8. In the case of a boarding request transmitted from the user terminal 6, the user identification unit 404 may identify the user ID based on, for example, header information of the transmitted data from the user terminal 6. In addition, in the case of a boarding request generated by the gesture input processing unit 414, the user identification unit 404 may identify the user ID based on an image of the user included in an image of the camera 8b described below and user information in the user information storage unit 422 (see FIG. 11B). In this case, a face image (registered image) of each user may be used as the user information.

When the boarding availability determination unit 402 determines that the user related to the boarding request is able to board, the reservation reception unit 405 accepts a reservation for boarding the route bus 2 by the user. When the reservation reception unit 405 accepts a boarding reservation, it updates the reservation status information (FIG. 7A) in the reservation status information storage unit 420 based on the corresponding boarding reservation. In FIG. 7A, the planned drop-off location, planned boarding location, margin, and desired arrival time are stored in association with the user ID. In this case, the reservation status information is updated based on the planned drop-off location and planned boarding location included in the corresponding boarding request. The margin represents the margin of the passenger (margin of margin for delays) and may be included in the boarding request as described later. If margin information is included in the corresponding boarding request, the margin information is also stored. The user ID used when updating the reservation status information is identified by the user identification unit 404. Note that the margin may be included in the boarding request when it is "low" (i.e., only when in a hurry), or may be specified in multiple stages. The margin may also be specified by the user in the form of an acceptable delay time at the planned disembarkation location, etc.

The planned alighting position change receiving unit 406 receives a request to change the planned alighting position from the user terminal 6 described below or the processing device 10 (passenger request sending unit 116) of the route bus 2. When the planned alighting position change receiving unit 406 receives a request to change the planned alighting position for a certain passenger, it changes the planned alighting position for that passenger in the seat status information (see FIG. 7B) in the seat status information storage unit 425.

The course change processing unit 407 changes the planned driving course from the basic course to another course based on a boarding request from a user. After changing the planned driving course to another course, the course change processing unit 407 may further change the planned driving course from another course to yet another course (including the basic course) based on a boarding request from another user. In other words, the number of times that the course can be changed may be two or more times, or may be limited to only one time. In the following, unless otherwise specified, the number of times that the course can be changed is considered to be unlimited.

Specifically, the course change processing unit 407 changes the planned driving course when the planned boarding location or planned disembarking location included in the boarding request is outside the planned driving course. Note that, as described below, the course change processing unit 407 may not change the planned driving course even if the planned boarding location or planned disembarking location included in the boarding request is outside the planned driving course.

Figure 8 is an explanatory diagram of the course change processing by the course change processing unit 407. In Figure 8, course R1 is shown as the basic course, and other courses R2 and R3 are shown. For example, assume that a boarding request is generated that specifies position X1 as the planned boarding position. In this case, the course change processing unit 407 may change the planned driving course from course R1 to another course R2 that passes through position X1.

In addition, if there are no passengers who plan to disembark at the planned stop position A2 and there are no users (users who have issued a boarding request) who plan to board at the planned stop position A2, the course change processing unit 407 may change the planned driving course from course R1 to another course R3 that passes through position X1 (course R2 that does not pass through the planned stop position A2). In this case, the delay in the planned arrival time at the next planned stop position A3 caused by the course change processing can be reduced.

In this embodiment, as an example, the course change processing unit 407 includes a change cost calculation unit 4071, a change feasibility determination unit 4072, and a course change reflection unit 4074.

The change cost calculation unit 4071 calculates the cost (hereinafter referred to as the "change cost") of changing the planned driving course from the current course to a planned changed course (the planned driving course if changed). The planned changed course is a course that passes through the planned boarding position and planned disembarking position included in the boarding request. The planned changed course is also a course that passes through the planned boarding positions and planned disembarking positions of users and passengers who have already made a boarding reservation. The change cost is an index value that represents the loss when the planned driving course is changed from the current course to the planned changed course, and in this embodiment, as an example, the change cost becomes higher as the loss becomes larger.

The change cost may be calculated in such a way that, for example, the longer the delay time due to the change, the higher the cost is the more occupants (e.g., the current number of occupants) are affected by the delay due to the change, and the lower the occupant's margin of safety (margin of safety for delays) is. The occupant's margin of safety may be transmitted to the server 4 in a manner that is included in the boarding request.

The change cost calculation unit 4071 may calculate the change cost based on the course change judgment information stored in the course change judgment information storage unit 423, for example. FIG. 9A shows an example of the course change judgment information. In FIG. 9A, the planned drop-off location, the planned boarding location, and the margin (margin of margin for delay) are stored for each occupant's user ID. In this case, the change cost calculation unit 4071 may calculate the sum or average of the delay times related to the planned arrival times at the planned drop-off locations of each occupant as the change cost. In this case, the change cost calculation unit 4071 may calculate the delay times related to occupants with low margins by weighting (e.g., doubling). The change cost may also be calculated in a manner that takes into account the attributes of the user. For example, when calculating the change cost, the change cost for, for example, an elderly person or a physically disabled person may be weighted in a manner that is greater than the change cost for other users under the same conditions except for the user attributes.

The change cost may also be calculated in a manner that takes into account the attributes (characteristics) of the planned boarding position and/or planned disembarking position (not present on the current course). The attributes of the planned boarding position and/or planned disembarking position may be, for example, that it is on a slope (where it is difficult to stop), that it is on a narrow road (where it is difficult to pass), that it is a school route, etc. For example, when calculating the change cost, weighting may be performed in a manner that is greater when the planned boarding position and/or planned disembarking position is located on a slope, narrow road, or school route than when it is not, under the same conditions other than the attributes of the planned boarding position and/or planned disembarking position. In this case, by making the change cost excessive when the planned boarding position and/or planned disembarking position is located on a slope or narrow road, a course change to accommodate the planned boarding position and/or planned disembarking position where it is difficult to stop or pass, such as a slope or narrow road, may be substantially prohibited.

In a modified example, the change cost calculation unit 4071 may calculate a cost (non-change cost) in the case where the planned travel course is not changed instead of or in addition to the change cost. The non-change cost may be calculated in such a manner that, for example, the non-change cost increases as the deviation of the scheduled arrival time at each bus stop (deviation from the scheduled arrival time) due to not changing increases, and the non-change cost increases as the margin of safety (margin of safety for delay) of the user who wishes to board the bus decreases. In addition, in a situation where multiple route buses 2 are operating simultaneously, the non-change cost may be calculated in such a manner that the non-change cost increases as the waiting time until the arrival of the next route bus 2 of the user who wishes to board the bus increases.

The change possibility determination unit 4072 determines whether or not to change the planned driving course from the current course to the planned changed course based on the change cost calculated by the change cost calculation unit 4071. For example, the change possibility determination unit 4072 permits the change when the change cost calculated by the change cost calculation unit 4071 is equal to or less than a predetermined threshold Th1. The predetermined threshold Th1 is a value that is adapted taking into consideration the convenience of the user, etc. The predetermined threshold Th1 may be variable depending on the time of day or the day of the week.

In a modified example in which the change cost calculation unit 4071 calculates the non-change cost, the change possibility determination unit 4072 may determine whether or not to change the planned driving course from the current course to the planned changed course based on the non-change cost calculated by the change cost calculation unit 4071. For example, the change possibility determination unit 4072 permits the change when the non-change cost calculated by the change cost calculation unit 4071 is equal to or greater than a predetermined threshold value Th2. The predetermined threshold value Th2 is a value that is adapted taking into consideration the convenience of the user, etc. The predetermined threshold value Th2 may be variable depending on the time of day or the day of the week.

In a modified example in which the change cost calculation unit 4071 calculates the change cost and the non-change cost, the change possibility determination unit 4072 may determine whether or not to change the planned driving course from the current course to the planned changed course based on the change cost and the non-change cost calculated by the change cost calculation unit 4071. For example, the change possibility determination unit 4072 permits the change if the non-change cost calculated by the change cost calculation unit 4071 is greater than the change cost. In this case, it is desirable to normalize the change cost and the non-change cost before comparing them. For example, the change cost and the non-change cost may be compared in terms of cost per user. Also, the change cost may be weighted so that it is given more importance than the non-change cost. This is because it makes sense to give priority to the current occupant.

In a modified example, the change cost calculation unit 4071 may be omitted, and the course change processing unit 407 may be realized in a simpler manner.

For example, the change possibility determination unit 4072 may calculate a delay time for the expected arrival time at the planned disembarkation location for a passenger with a low margin of safety, and permit the change if the delay time is equal to or less than a predetermined threshold value Th3. Alternatively, if there is a passenger who has specified a desired arrival time, the change possibility determination unit 4072 may permit the change if the route change will still allow the passenger to arrive before the desired arrival time.

Alternatively, the change feasibility determination unit 4072 may determine whether or not to change the planned driving course from the current course to the planned changed course by comprehensively evaluating multiple factors such as the change cost, non-change cost, margin, and desired arrival time as described above.

The course change reflection unit 4074 performs processing to reflect the course change when the change is permitted by the change permission determination unit 4072. Specifically, the course change reflection unit 4074 updates information (course information) representing the planned driving course in the planned driving course storage unit 426. In other words, the course change reflection unit 4074 rewrites the course information in the planned driving course storage unit 426 to information representing the changed course.

In addition, as described above, the route change processing unit 407 may function commonly for multiple route buses 2 in order to take into account the operating status of multiple route buses 2.

For example, in a situation where multiple route buses 2 are operating simultaneously, the route change processing unit 407 may determine whether or not to change the planned driving route of one or more of the multiple route buses 2 based on the positional relationship between the multiple route buses 2. For example, when multiple route buses 2 are in a circular route, the planned driving route of one or more of the multiple route buses 2 may be changed so that the intervals between the scheduled arrival times at a specified bus stop are equalized. Note that such a route change may be executed without being triggered by a boarding request from a user.

In addition, in a situation where multiple route buses 2 are operating simultaneously, the route change processing unit 407 may determine which of the multiple route buses 2 to change the planned route of based on the positional relationship between the multiple route buses 2.

In this case, for example, the course change processing unit 407 may determine whether or not to change the planned running course of the second route bus 2 based on the interval (the distance between the first route bus 2 or the time between the vehicles along the planned running course) between a first route bus 2 and a second route bus 2 following the first route bus 2 among the multiple route buses 2. In this case, the course change processing unit 407 may change the planned running course of the second route bus 2 when the interval is shorter than a predetermined threshold value Th4. The predetermined threshold value Th4 may correspond to the lower limit of a range of appropriate intervals, and is adapted based on the number of vehicles in operation, etc. More specifically, for example, FIG. 9B shows the operation status of each of the first route bus 2 and the second route bus 2 (the estimated arrival time for each scheduled stop location, and the delay relative to the scheduled time). In such an operation status, the interval between the first route bus 2 and the second route bus 2 is within an appropriate interval range, so the scheduled driving course of either the first route bus 2 or the second route bus 2 may not be changed. Alternatively, the course change processing unit 407 may change the scheduled driving course of the second route bus 2 based on the fact that the second route bus 2 is operating earlier than the scheduled time. Also, unlike the situation in FIG. 9B, if the first route bus 2 is operating earlier than the scheduled time, the course change processing unit 407 may change the scheduled driving course of the first route bus 2.

Alternatively, the route change processing unit 407 may determine whether or not to change the planned route of a route bus 2, starting with the route bus 2 with the shortest delay time due to the route change among the multiple route buses 2. Note that if there is a route bus 2 among the multiple route buses 2 that is originally on the planned route and does not need to change its route, the output control unit 411 may notify the user related to the boarding request to prompt them to generate a boarding request for that route bus 2.

Here, the course change processing unit 407 and the boarding possibility determination unit 402 described above may operate in cooperation with each other. For example, if the course change processing unit 407 determines that the planned travel course of a certain route bus 2 is to be changed, the boarding possibility determination unit 402 may determine whether or not boarding is possible for that route bus 2. Also, if the boarding possibility determination unit 402 determines whether or not boarding is possible only based on the upper limit (number of seats) of the number of users who can board the route bus 2, the current number of passengers, and the planned disembarking positions of the passengers, and determines that boarding is possible, the course change processing unit 407 may determine whether or not the course of the route bus 2 can be changed.

When the planned travel course in the planned travel course storage unit 426 is updated, the timetable generation unit 408 updates the timetable information in the timetable information storage unit 428. FIG. 10 shows an example of timetable information in the timetable information storage unit 428. For the purpose of explanation, FIG. 10 shows timetable information D801 before the planned travel course is changed and timetable information D802 after the planned travel course is changed. The timetable information D802 is data when a planned stop position X1 is added. Note that the planned stop position X1 is a position that does not exist on the course R1, which is the basic course, as shown in FIG. 8 above. The timetable information may be derived based on past performance (statistical data) or may be derived by calculation based on the cruising speed and the distance to each stop (known).

The vehicle state update unit 409 updates information representing the vehicle state of the route bus 2. The vehicle state includes the position of the route bus 2 and may include other states of the route bus 2 (e.g., whether the brakes are activated, etc.). For example, when the vehicle state update unit 409 receives vehicle position information from the vehicle position information acquisition unit 106 of the processing device 10 of the route bus 2, it updates the vehicle state information in the vehicle state information storage unit 424.

In addition, the vehicle status update unit 409 transmits vehicle position information to the user terminal 6 or the projector 7 in response to a request from the Machi-Mobi app 5 (an application implemented in the user terminal 6) or the projector 7, which will be described later. The vehicle status update unit 409 may transmit vehicle position information to the user terminal 6 or the projector 7 of the user who has made a reservation in a push-type notification format.

The seat status update unit 410 updates information indicating the status of the seats of the route bus 2. The seat status may include whether each seat is occupied, identification information of the user occupying the seat, and the like. When the seat status update unit 410 receives occupant status information from the occupant status detection unit 112 of the processing device 10 of the route bus 2, it updates the seat status information in the seat status information storage unit 425. FIG. 7B shows an example of the seat status information in the seat status information storage unit 425. In FIG. 7B, the presence or absence of an occupant, and if an occupant is present, the user ID of the occupant, the planned disembarking position, and the degree of leeway (the degree of leeway is acquired only when the degree of leeway is acquired) may be stored in association with the seat for each seat. Note that the planned disembarking position and the degree of leeway are information included in the boarding reservation, and therefore the information can be used in a form linked to the user ID of the occupant when generating the seat status information.

The output control unit 411 outputs various information to the user via the route bus 2, the user terminal 6, and the projector 7.

The output control unit 411 includes a boarding available section notification unit 4110, a timetable notification unit 4112, a course information notification unit 4114, a boarding request change request unit 4116, a gesture input guidance unit 4118, an in-car advertising output unit 4120, and an alighting guidance output unit 4122.

The boardable section notification unit 4110 may transmit the boardable section information in the boardable section storage unit 421 to the user terminal 6 or projector 7 described below as necessary. For example, the boardable section notification unit 4110 may transmit the boardable section information in the boardable section storage unit 421 to the user terminal 6 or projector 7 in a push-type notification manner. For example, the boardable section notification unit 4110 may transmit the boardable section information in the boardable section storage unit 421 to the user terminal 6 or projector 7 when the boardable section derivation unit 400 updates the boardable section information in the boardable section storage unit 421 as described above (i.e., when there is a change in the boardable section). When the boardable section information is received and output by the user terminal 6 or projector 7, the user can easily know which sections are available for boarding, improving convenience.

When the timetable generation unit 408 updates the timetable information in the timetable information storage unit 428, the timetable notification unit 4112 transmits the updated timetable information to the processing device 10. As described above, the timetable information is received by the timetable information receiving unit 103 of the processing device 10 of the route bus 2. The timetable information received by the timetable information receiving unit 103 is output by the information output control unit 114 of the processing device 10 via the large display D1 and displays D2 to D7 within the route bus 2. This allows passengers on the route bus 2 to be aware of changes in the timetable information as needed, improving convenience.

In addition, the timetable notification unit 4112 transmits the timetable information in the timetable information storage unit 428 to the user terminal 6 or the projector 7 in response to a request from the Machi-Mobi app 5 (an application implemented in the user terminal 6) or the projector 7, which will be described later. The timetable notification unit 4112 may transmit the timetable information in the timetable information storage unit 428 to the user terminal 6 or the projector 7 in a push-type notification format. For example, the timetable notification unit 4112 may transmit the timetable information to the user terminal 6 or the projector 7 when the timetable generation unit 408 updates the timetable information in the timetable information storage unit 428 (i.e., when there is a change in the planned travel course). When the timetable information is received and output by the user terminal 6 or the projector 7, the user can appropriately grasp changes in the timetable information, improving convenience.

The course information notification unit 4114 transmits the course information updated by the course change processing unit 407 as described above to the processing device 10. The course information is received by the planned travel course receiving unit 102 of the processing device 10 of the route bus 2 as described above. The course information received by the planned travel course receiving unit 102 is output to the information output control unit 11 of the processing device 10.
4, the information is output via the large display D1 and displays D2 to D7 in the route bus 2. This allows the occupants of the route bus 2 to appropriately grasp the change in the planned travel course, improving convenience. Here, when the planned travel course has been changed from the basic course, the information output control unit 114 of the processing device 10 may output the planned travel course in a manner that makes it clear that the planned travel course has been changed from the basic course. For example, when the planned travel course has been changed from the basic course, a predetermined mark may be added, the display color may be changed, or text information or audio information such as "changing" may be added, making it easy for the occupants to understand that the planned travel course has been changed from the basic course, improving convenience.

In addition, the course information notification unit 4114 transmits course information representing the changed course to the user terminal 6 or the projector 7 in response to a request from the Town Mobi app 5 (an application implemented in the user terminal 6) or the projector 7, which will be described later. The course information notification unit 4114 may transmit the course information in the planned driving course storage unit 426 to the user terminal 6 or the projector 7 in a push-type notification manner. For example, the course information notification unit 4114 may transmit the course information in the planned driving course storage unit 426 to the user terminal 6 or the projector 7 when the course information is updated (i.e., when the planned driving course is changed). When the course information is received and output by the user terminal 6 or the projector 7, the user can appropriately grasp the change in the planned driving course, thereby improving convenience. Here, when the planned driving course is changed from the basic course, the user terminal 6 or the projector 7 may output the planned driving course in a manner that indicates that the planned driving course has been changed from the basic course. For example, if the planned route has been changed from the basic route, a specified mark can be added, the display color can be changed, or text or audio information such as "changing" can be added, making it easier for the user to understand that the planned route has been changed from the basic route, improving convenience.

When the change permission determination unit 4072 of the above-mentioned course change processing unit 407 does not permit the change, the boarding request change request unit 4116 notifies the corresponding user of this information and requests a new boarding request (a boarding request with a changed planned boarding location and/or planned disembarking location). Note that such notification and request may be realized via the user terminal 6 or projector 7 described below. In this case, the user understands that the planned travel course could not be changed and can make an input for a new boarding request, etc.

In addition, when multiple route buses 2 are operating simultaneously and boarding to another route bus 2 is possible, the boarding request change request unit 4116 may request the user to change the boarding request to another route bus 2. Similarly, such a request may be realized via the user terminal 6 or projector 7 described below.

The gesture input guide unit 4118 cooperates with the gesture input processing unit 414 described below to output various information to the projector 7 and the gesture recognition device 8. This will be described later.

The in-vehicle advertising output unit 4120 cooperates with the information output control unit 114 of the route bus 2 to output various types of advertising information to passengers on the route bus 2. The advertising information to be output is stored in the advertising information storage unit 430. FIG. 11A shows an example of advertising information stored in the advertising information storage unit 430. In FIG. 11A, advertiser information and advertising data are associated with each bus stop or scheduled stop location (temporary stops associated with a change in route). The advertising data may be in the form of audio data or video data.

When the in-vehicle advertising output unit 4120 detects a predetermined advertising output timing based on the vehicle status information in the vehicle status information storage unit 424, it extracts advertising data associated with the next scheduled stop position based on the advertising information in the advertising information storage unit 430. The predetermined advertising output timing is arbitrary, but may be synchronized with the timing when the route bus 2 departs for the next scheduled stop position. The in-vehicle advertising output unit 4120 then instructs the processing device 10 to output the extracted advertising data. When the information output control unit 114 of the processing device 10 receives the instruction, it outputs the advertising data via the large display D1 and the built-in speaker, and/or via the speaker 3a.

In addition, when the course change processing unit 407 described above changes the course, the in-car advertisement output unit 4120 extracts advertisement data associated with the next scheduled stop position (for example, a new scheduled stop position due to the course change that was not a scheduled stop position before the change) and instructs the processing device 10 to output the extracted advertisement data. When the information output control unit 114 of the processing device 10 receives the instruction, it outputs the advertisement data via the large display D1 and the built-in speaker and/or via the speaker 3a. For example, assume that the planned travel course is changed from course R1 to course R2 (or course R3) in the situation shown in FIG. 8 above. In this case, the next scheduled stop position is changed from stop A2 to position X1, and in FIG. 11A, the advertisement data associated with position X1 ("advertisement data 00X0") is output.

The alighting guidance output unit 4122 cooperates with the information output control unit 114 of the route bus 2 to output alighting guidance to the passengers on the route bus 2. Specifically, when the alighting guidance output unit 4122 detects that the route bus 2 is approaching the next planned stop position based on the vehicle status information in the vehicle status information storage unit 424, it searches for passengers who plan to get off at the next planned stop position based on the seat status information in the seat status information storage unit 425. Then, the alighting guidance output unit 4122 instructs the processing device 10 to individually provide alighting guidance to the passengers who plan to get off at the next planned stop position. When the information output control unit 114 of the processing device 10 receives the instruction, it outputs alighting guidance via a display and built-in speaker associated with the passenger among the displays D2 to D7, and/or via the speaker 3a. For example, in the example shown in FIG. 7B, if the next planned stop is bus stop A3, passengers who plan to disembark at bus stop A3 are seated in seats S2 and S3. In this case, disembarking guidance may be provided via displays D4 and D5 associated with seats S2 and S3.

When speaker 3a is used, speaker 3a moves close to the passenger and outputs audible guidance. For example, in the example shown in FIG. 7B, if the next planned stop is bus stop A3, passengers who plan to disembark at bus stop A3 are in seats S2 and S3. In this case, speaker 3a moves close to seats S2 and S3 and outputs audible guidance. When a speaker with variable directivity is used, the directivity may be set so that the directivity is highest near the corresponding passenger, and audible guidance may be output. In this case, the speaker with variable directivity may be provided on the ceiling of route bus 2 so as to correspond to each seat, or multiple speakers may be provided.

While the mode of the alighting guidance is arbitrary, in this embodiment, the name of the passenger based on the seat status information may be used to realize a familiar alighting guidance. For example, "Gen-san, next!" For example, in the example shown in FIG. 7B, if the next scheduled stop location is bus stop A3, the passengers who have bus stop A3 as their planned alighting location have user IDs "0001" and "0002". The passenger user IDs "0001" and "0002" are named "Gen" and "Hana" according to the user information in the user information storage unit 422 (FIG. 11B).
Therefore, in this case, for example, a message such as "Gen-san and Hana-san, the next stop is here!" is output.

In a modified example, a vibrator (or massager) installed in the seat may be used to wake up the occupant if the occupant is asleep. Alternatively, a fragrance or the like may be sprayed to wake up the occupant.

The user registration processing unit 412 executes processing for user registration of the route bus system 1. The user may be registered for each route bus system 1 that may exist in multiple regions, or may be registered in common for all route bus systems 1. FIG. 11B shows an example of user information stored in the user information storage unit 422. In FIG. 11B, the user's name and image data of the user's face are stored for each user ID. As described above, the registration of face image data may be omitted for users who use ID cards. However, in this case, it is impossible to determine which user is sitting in which seat, so that such a determination can be made, for example, a receiver for holding the ID card over each seat may be provided. The user's name may be a nickname or a full name including the surname. In addition, for users who do not need the below-described guide service for getting off at a bus stop, the registration of the user's name may be omitted.

The gesture input processing unit 414, together with a gesture input guiding unit 4118 of the output control unit 411, cooperates with a projector 7 and a gesture recognition device 8 described later to realize a user interface that allows gesture input. Specifically, the gesture input processing unit 414 generates a user's boarding request based on a gesture recognition result acquired from the gesture recognition device 8. Further details of the gesture input processing unit 414 will be described later together with the explanation of the gesture recognition device 8.

As described above, the reservation status information storage unit 420 stores reservation status information (see FIG. 7A). Note that the reservation status information only indicates the user who currently has a reservation, and when that user boards the vehicle, the information related to that user is deleted. FIG. 7A shows that two users, with user IDs "0005" and "0004", have made reservations.

As described above, the boarding section storage unit 421 stores boarding section information (see FIG. 7C). In FIG. 7C, the number of passengers that can board is associated with each boarding section. A boarding section that is associated with a number of passengers that is equal to or greater than "1" is a boarding section. The boarding section information is updated when a new boarding request is received (when a boarding reservation is executed). The boarding section information is updated in such a way that when the route bus 2 passes a certain bus stop or departs from the bus stop, boarding is not possible in the boarding section from the bus stop. In FIG. 7C, the boarding section information is for the route bus 2 after it departs from, for example, bus stop A1. Therefore, boarding is not possible for a boarding section that starts from bus stop A1, such as the boarding section A1-A10 from bus stop A1 to bus stop A10 (the number of passengers that can board is "-" and not equal to or greater than 1).

As described above, the user information storage unit 422 stores user information (see FIG. 11B). In addition to the information shown in FIG. 11B, the user information may also include other information such as age, gender, home address, etc.

As described above, the course change determination information storage unit 423 stores course change determination information (see FIG. 9A). In a situation where multiple route buses 2 are operating simultaneously, information indicating the operating state as shown in FIG. 9B may be stored in the course change determination information storage unit 423 as course change determination information. Since the course change determination information is based on the seat status information in the seat status information storage unit 425 and the timetable information in the timetable information storage unit 428, the seat status information in the seat status information storage unit 425 and the timetable information in the timetable information storage unit 428 may be substituted. In this case, the course change determination information storage unit 423 may be omitted.

As described above, the seat status information storage unit 425 stores seat status information (see FIG. 7B).

As described above, the planned driving course memory unit 426 stores course information representing the current planned driving course. For example, if the current planned driving course is course R1 shown in FIG. 8, course information representing course R1 is stored.

As described above, the timetable information storage unit 428 stores timetable information (see FIG. 9B). As shown in FIG. 9B, the timetable information may include information indicating delays relative to scheduled times. Note that, unlike general timetable information, the timetable information changes dynamically in response to course changes, as described above.

As described above, advertising information (see FIG. 11A) is stored in advertising information storage unit 430 .
The advertisement information may be updated as appropriate in response to changes in the advertisement content, etc.

In this embodiment, some or all of the functions of the server 4 described above may be realized by the processing device 10 of the route bus 2, or conversely, some of the functions of the processing device 10 of the route bus 2 described above may be realized by the server 4. For example, in the former case, the in-vehicle advertising output unit 4120 and the advertising information storage unit 430 of the server 4 may be realized by the processing device 10 of the route bus 2.

[User terminal]
The user terminal 6 may be a smartphone, a mobile phone, a tablet terminal, a wearable terminal, a game terminal, a notebook computer, etc. The user terminal 6 may also be a fixed terminal such as a laptop computer that is installed in a fixed location such as the user's home.

An application (hereinafter also referred to as "City Mobi app 5") that is convenient for using the route bus system 1 is installed on the user terminal 6. Users of the route bus system 1 are encouraged to download the City Mobi app 5. The City Mobi app 5 is stored in a storage device (not shown) in the user terminal 6, and is executed by a CPU (not shown) in the user terminal 6 to realize various functions described below.

The City Mobi app 5 has a function of outputting information (hereinafter referred to as "operation information") that indicates the operation status of the route bus 2. The City Mobi app 5 acquires operation information by communicating with the server 4 (communication via a communication function in the user terminal 6). The operation information includes, for example, course information, timetable information, and vehicle position information. The operation information may also include boarding section information.

FIG. 12A is an explanatory diagram of an example of output of operation information, and is a diagram that shows a screen G11 on a display (not shown) of a user terminal 6. In FIG. 12A, the screen G11 shows an image G110 representing a district of the area, an image G1101 representing a current planned driving course, an image G1102 representing the current position of the route bus 2, and an image G1103 representing an estimated arrival time for each planned stop position (a planned stop position on the planned driving course) of the route bus 2, together with the current date and time. The image G1101 is generated based on the course information included in the operation information, the image G1102 is generated based on the vehicle position information included in the operation information, and the image G1103 is generated based on the timetable information included in the operation information. Note that the screen G11 shown in FIG. 12A is generated by the Town Mobi app 5 based on the operation information transmitted from the server 4, but in a modified example, the server 4 may transmit image data of the screen G11 shown in FIG. 12A to the user terminal 6. In this case, the TownMobi app 5 displays the image data received from the server 4 on the display of the user terminal 6.

The Town Mobi app 5 also has a function to generate a ride request in response to input from the user of the user terminal 6 and transmit it to the server 4. The Town Mobi app 5 also has a function to generate a request to change the planned drop-off location in response to input from the user of the user terminal 6 and transmit it to the server 4. The Town Mobi app 5 may also be used to register user information as described above.

By outputting the operation information to the user terminal 6 in this manner, the user can grasp the latest operating status of the route bus 2, improving convenience. In particular, in this embodiment, as described above, the planned route bus 2 route route may change, so the usefulness of outputting the operation information increases. In this regard, the MachiMobi app 5 may be configured to output operation information every time there is a change in the planned route bus 2 route route.

In addition to or instead of outputting the operation information, the MachiMobi app 5 may obtain the above-mentioned boarding section information from the server 4 and output it on the display (not shown) of the user terminal 6. FIG. 12B shows an example of output of boarding section information (one example of operation information). FIG. 12B shows that the route bus 2 is located between bus stop A1 and bus stop A2, and that the boarding section from bus stop A2 to bus stop A10, the boarding section from bus stop A2 to bus stop A3, and the boarding section from bus stop A3 to bus stop A10 are boardable. This allows the user to easily know which sections are boardable, improving convenience.

In addition, in FIG. 12B, the screen G41 includes, as rideable section information, an image portion G1120 of an arrow representing the section, and an image portion G1121 representing the number of passengers that can ride. This allows the user to easily understand how many people can ride in which section, improving convenience. This is particularly useful when the user is accompanied by a person.

When multiple route buses 2 are operating simultaneously, the screen G41 shown in FIG. 12B may be prepared for each route bus 2. The same applies to the screen G11 shown in FIG. 12A. In these cases, the user selects a desired route bus 2 from among the multiple route buses 2, and the screen G41 etc. relating to that route bus 2 is output.

Figure 12C is an explanatory diagram of an example of operation information output suitable for when multiple route buses 2 are operating simultaneously, and is a diagram that shows a schematic diagram of a screen G51 on the display (not shown) of a user terminal 6.

In FIG. 12C, an example of output of timetable information at a certain bus stop is shown. In FIG. 12C, it can be seen that route buses 2 are scheduled to arrive at the bus stop every 15 minutes from 10:15. In FIG. 12C, information on the planned route is also output for the next route bus 2 scheduled to arrive at 10:30 and the route bus 2 scheduled to arrive after that at 10:45. The expected arrival time of 10:30, etc. may change if a route change occurs as described above. Note that the current time is, for example, 10:20, and the route bus 2 associated with the earlier departure at 10:15 has already departed. In this way, information on the planned route may be displayed only for a limited number of route buses 2 that are arriving soon. In this case, the route information can be displayed together with the timetable information while efficiently utilizing the limited display space, improving user convenience. Note that, although not shown in FIG. 12C, vehicle position information indicating the current position of the route bus 2 may also be displayed.

Figure 13 is an explanatory diagram of an example of the output of a boarding request reception screen (reservation reception information), and is a diagram that shows screens G12 to G14 on the display (not shown) of the user terminal 6.

In the example shown in FIG. 13, the screen on the display of the user terminal 6 transitions between screens G12 to G14 in response to input by the user.

Screen G12 is a screen for inputting the planned boarding location, and may be, for example, a screen to which the user is transitioned by operating the "Go to reservation screen" button on screen G11 shown in FIG. 12A, or may be an initial screen displayed when the MachiMobi app 5 is started. Screen G12 displays three candidates for the planned boarding location: "Stop A2", "Home", and "Other". The candidates for the planned boarding location may be displayed based on boardable section information transmitted from the server 4. In this case, the candidates for the planned boarding location are displayed on screen G12 only when the user can board the route bus 2 at the candidate location. Therefore, for example, when the route bus 2 is full, the candidates for the planned boarding location are determined from a position (a position to be reached in the future if the route bus 2 travels along the planned travel route) beyond the position where the route bus 2 is no longer full (the position where any passenger plans to get off). In a modified example, information indicating the candidates for the planned boarding location may be transmitted from the server 4 to the MachiMobi app 5 instead of the boardable section information.

Each screen section showing the three candidates "Stop A2", "Home" and "Other" may be, for example, a button section in the form of a touch switch. In this case, the user can input the planned boarding location by selecting the desired planned boarding location from the three candidates "Stop A2", "Home" and "Other". Note that, when "Other" is operated, other stops, etc. may be displayed as candidates. In this case, the candidates may be predefined as locations that satisfy a predetermined condition. The predetermined condition may be a condition that prevents the above-mentioned change cost from becoming high. For example, the predetermined condition is a condition that excludes locations where it is difficult for the route bus 2 to stop or pass, such as narrow roads and slopes. Note that, in this case, the candidates may be variable according to changes in road conditions, etc. For example, candidates on roads where it is temporarily impossible or difficult to drive, such as construction or falling rocks, may be temporarily excluded from the candidates. When the planned boarding location is input on the screen G12, the screen G12 transitions to the screen G13.

Screen G13 is a screen for inputting a planned disembarking location, and may be a screen transitioned to by inputting a planned boarding location on screen G12 as described above. Screen G13 shows multiple candidates for the planned boarding location, "Bus Stop A3", ..., and "Other". Bus Stop A3 may be a bus stop along the current planned travel route where the bus is scheduled to stop. Each screen section showing the multiple candidates "Bus Stop A3", ..., and "Other" may be in the form of a touch switch, for example. In this case, the user can input a planned disembarking location by selecting the desired planned disembarking location from the multiple candidates "Bus Stop A3", ..., and "Other". When a planned disembarking location is input on screen G13, screen G13 transitions to screen G14.

Screen G14 is a reservation completion screen, and in the example shown in FIG. 13, it shows that route bus 2 will arrive at the planned boarding location one minute later, at 11:50.

When transitioning from the screen G13 to the screen G14, the City Mobi app 5 transmits to the server 4 a boarding request including information indicating the input planned boarding location and planned disembarking location.

FIG. 14A is an explanatory diagram of another output example of the boarding request acceptance screen, and is a diagram that roughly shows a screen G111 on the display (not shown) of the user terminal 6.

14A shows an example of a simple boarding request reception screen, which may be easy to use for elderly people, for example. Specifically, the screen G111 occupies most of the screen and includes a screen section G151 showing a boarding button in the form of a touch switch. The screen G111 may be a screen to which the user transitions by operating the "To reservation screen" button (in the form of a touch switch) on the screen G11 shown in FIG. 12A, for example, or may be an initial screen displayed when the MachiMobi app 5 is started. The user can easily make a reservation by operating the screen section G151. In this case, when the screen section G151 is operated, the MachiMobi app 5 transmits a boarding request including information indicating a planned boarding position and a planned disembarking position to the server 4. In this case, the bus stop closest to the current user's position (position measured by the GPS receiver of the user terminal 6) may be automatically selected as the planned boarding position included in the boarding request, and the end point may be automatically selected as the planned disembarking position included in the boarding request. In the example shown in FIG. 14A, when screen portion G151 is operated, screen G111 may transition to a reservation completion screen such as screen G14 shown in FIG. 13.

Figure 14B is an explanatory diagram of another example of the output of the boarding request reception screen, and is a diagram that shows a schematic diagram of screen G113 on the display (not shown) of user terminal 6.

The screen G113 shown in FIG. 14B is suitable for situations in which multiple route buses 2 are operating simultaneously. On the screen G113, multiple route buses 2 (only three are shown) can be reserved, and each route bus 2 is associated with a course icon G120, a reservation button G122, a screen section G123 showing estimated arrival timetable information, and a screen section G124 showing the arrival order. The screen G113 may be a screen that is displayed when the user launches the MachiMobi app 5 and inputs a planned boarding location. In this case, the estimated arrival timetable information shown on the screen section G123 is the estimated arrival time at the input planned boarding location.

By operating one of the course icons G120 on the screen G113, the user can display the current planned route of the corresponding route bus 2. In this case, for example, a screen like the screen G11 shown in FIG. 12A may be displayed. This allows the user to easily check the current planned route of each route bus 2.

Here, a mark M1 indicating that a course change has occurred may be added to the course icon G120 relating to the route bus 2 for which the above-mentioned course change has occurred. This allows the user to easily understand that the planned route of the route bus 2 has been changed from the basic course.

In this way, the boarding request reception screen (reservation reception information) can be realized in various forms. For example, the screen G41 shown in FIG. 12B may function as the boarding request reception screen (reservation reception information). In this case, the image section G1120 may be in the form of a touch switch, and by operating the image section G1120, a boarding request for the boarding section associated with the image section G1120 may be generated. In this case, the user does not need to input the planned boarding location, etc., improving convenience.

Figure 15A is an explanatory diagram of another example of the output of the boarding request reception screen that includes information on the number of accompanying persons when the user is accompanied by accompanying persons (companions who are not registered as users), and is a diagram that shows a schematic diagram of screen G130 on the display (not shown) of user terminal 6.

Screen G130 is a separate screen, and may be displayed by operating a companion button (not shown) on the boarding request reception screen. Alternatively, screen G130 may be incorporated into a part of screen G12 shown in FIG. 13, for example. Screen G130 includes a screen section G131 indicating the number of companions, a button section G132 for increasing the number of companions, and a button section G133 for decreasing the number of companions. By using such screen G130, the user can easily specify the number of companions. Note that information indicating the number of companions may be transmitted to server 4 together with the boarding request.

Figure 15B is an explanatory diagram of another example of the output of the boarding request reception screen when including information on margin and desired arrival time, and is a diagram that shows a schematic diagram of screen G140 on the display (not shown) of user terminal 6.

Screen G140 is a standalone screen, and may be displayed by operating a margin button (not shown) on the boarding request reception screen. Alternatively, screen G140 or button section G141 and button section G142 described below may be incorporated into, for example, part of screen G12 shown in FIG. 13. Screen G140 includes button section G141, which indicates that margin is low, and button section G142 for specifying a desired arrival time. When button section G142 is operated, it becomes an interface that allows scrolling of hours and minutes, and is configured so that a time can be specified. By using such screen G140, the user can easily specify the margin of time and the desired arrival time.

In this embodiment, some of the functions of the server 4 described above may be realized by the City Mobi app 5, and conversely, some of the functions of the City Mobi app 5 described above may be realized by the server 4.

In addition, in this embodiment, the user terminal 6 is described as an input/output medium (medium for inputting and outputting various information), but an aerial display or a show window display may also be used as the input/output medium.

[Projector]
Fig. 16 is an explanatory diagram showing an example of the arrangement of the projector 7, and is a diagram showing a typical residential area where the projector 7 is arranged. Fig. 17 is a diagram showing an example of the configuration of the projector 7. Fig. 18 is a diagram showing an example of a map used to control the projection direction of the projector 7.

Projector 7 is a device that projects a projection image. Projector 7 may be, for example, a device that uses projection mapping. Projector 7 projects information (operation information) indicating the operation status of route bus 2 onto at least one of a wall surface and a road surface as a projection surface. Projector 7 is equipped with a communication module 7a, and acquires operation information from server 4 by communicating with server 4 via communication module 7a. The operation information includes, for example, course information, timetable information, and vehicle position information.

Projector 7 is provided at a stop on the basic route or at a potential stop on the basic route or other routes. That is, projector 7 is provided so that a projected image is output near a stop or a potential stop. This allows a user to view a projected image while waiting for route bus 2 at a stop or a potential stop. Note that projector 7 may output entertainment-related projected images in addition to projected images related to operation information, etc. In this case, it is possible to prevent users waiting for route bus 2 from feeling that their wait is long.

In FIG. 16, the projector 7 is installed at a high place such as a utility pole. The projector 7 is preferably equipped with a motor 7b (see FIG. 17) so that the projection direction can be changed. The motor 7b is controlled by, for example, a microcomputer 70 (denoted as "microcomputer" in FIG. 17). Note that other actuators may be used instead of the motor 7b.

The microcomputer 70 changes the projection surface by controlling the motor 7b according to the direction of sunlight. Specifically, the microcomputer 70 changes the projection direction of the projector 7 by controlling the motor 7b so that the area that is shaded by the direction of sunlight (or an area where the amount of sunlight is relatively low) becomes the projection surface. For example, the microcomputer 70 may determine the projection surface using a map such as that shown in FIG. 18. In FIG. 18, the projection surface is associated with each time period. This is because the direction of sunlight changes according to the time period. Note that the wall surface W1 shown in FIG. 18 may be a surface on a fence or road as shown in FIG. 16. In the example shown in FIG. 16, the wall surface W1 is the wall surface of a fence of a certain house, and the wall surface W2 is the wall surface of another house, and the directions are about 90 degrees different. In addition, the road surface W3 is 90 degrees different from the wall surface W1 and the wall surface W2. By using such surfaces with different angles as projection surfaces, it becomes easier to output a clear projection image that is not easily affected by the direction of sunlight. Note that the map shown in FIG. 18 is merely an example, and the projection surface may be associated with each time period in more detail, or may be generated in such a way that the projection surface changes with each season and weather. Also, when the amount of sunlight is low, such as when the weather is rainy or cloudy, the projection surface may be fixed.

In this embodiment, the microcomputer 70 determines the projection surface, but in a modified example, the server 4 may determine the projection surface. In this case, the projector 7 may receive operation information from the server 4 as well as information indicating the projection direction.

The microcomputer 70 may control the light source 7c of the projector 7 according to the amount of sunlight. In this case, the microcomputer 70 may control the light source 7c so that the light emission intensity of the light source 7c increases as the amount of sunlight increases. The light source 7c is optional, but may be a high-brightness xenon lamp or the like.

An example of the operation information output by the projector 7 may be similar to the example of the operation information output by the user terminal 6 described above (see FIG. 12A), and will not be described in detail here.

In this way, in this embodiment, operation information is output by the projector 7, so the user can easily understand the operation status of the route bus 2 by viewing the projected image. Therefore, the user can understand the operation status of the route bus 2 even if he or she does not have a user terminal 6. Since the operation information can be updated in real time, in this case, the user can always understand the latest operation status. Also, in this embodiment, by using the projector 7, unlike the case where a display or the like is installed, for example, the operation information can be notified to the user without obstructing the streetscape (using the existing streetscape).

In this embodiment, the projector 7 further projects reservation acceptance information onto at least one of the wall surface and the road surface as a projection surface to enable reservations for boarding the route bus 2 (reservations by users on the road). The reservation acceptance information may be output onto a projection surface determined according to the direction of sunlight, similar to the operation information described above.

An example of the reservation acceptance information output by the projector 7 may be similar to the example of the boarding request acceptance screen output by the user terminal 6 described above (see Figures 13 to 15B), and will not be described in detail here. Note that the image projected by the projector 7 is generally larger than the image on the display of the user terminal 6, and may therefore contain more detailed information than the boarding request acceptance screen by the user terminal 6 described above. However, preferably, the image projected by the projector 7 contains only relatively simple information in order to enable gesture input, which will be described later.

In addition, the projector 7 may obtain the boarding zone information described above from the server 4 and output it as a projected image. An example of the boarding zone information output by the projector 7 may be similar to the example of the boarding zone information output by the user terminal 6 described above (see FIG. 12B). Just as the boarding zone information screen on the user terminal 6 can function as a boarding request reception screen as described above, the boarding zone information output by the projector 7 may also function as reservation reception information.

As described later in relation to the gesture recognition device 8, the reservation acceptance information functions as a user interface in conjunction with gesture recognition by the gesture recognition device 8. That is, the user can make a reservation to board the route bus 2 by making a predetermined gesture while looking at the reservation acceptance information.

In this way, in this embodiment, reservation acceptance information is output by the projector 7, so the user can make a reservation for a ride at that location. Therefore, the user can make a reservation for a ride even if he or she does not have a user terminal 6. Also, in this embodiment, by using the projector 7, reservation acceptance information can be output without obstructing the streetscape (using the existing streetscape), unlike when a display or the like is installed, for example.

Here, in this embodiment, the projector 7 is installed on a fixed object such as a utility pole, but is not limited to this. For example, as shown in FIG. 19, the projector 7 may be mounted on an aircraft 60 such as a drone. In this case, the projection direction by the projector 7 can be changed by changing the orientation of the aircraft 60. Therefore, in this case, the motor 7b may be omitted. The aircraft 60 may be located, for example, in a dock (not shown) provided at the top of the utility pole, and may fly only during operation (only when outputting operation information or reservation reception information). Note that a charger is provided in the dock, and the aircraft 60 may be configured to be charged autonomously. In addition, instead of the aircraft 60, the projector 7 may be mounted on a walking robot or a running robot. In addition to an electric pole, the projector 7 may be installed on a wall of a building, etc., borrowed from the owner of the building.

In this embodiment, the projection image is projected onto the wall surface W1 using the luminance of the light source 7c, but the device may also be one that uses sunlight as a backlight to project a shadow onto the wall surface W1. In this case, the shadow represents operation information, reservation reception information, and the like. Such shadow projection can be realized, for example, by using a projection device equipped with a liquid crystal layer. The liquid crystal layer can control the transmission state for each pixel according to the applied voltage. The liquid crystal layer is controlled so that the pixel portion for forming the shadow becomes a shutter. Alternatively, an organic EL (Electro-Luminescence) panel may be used to project a colored image while projecting a shadow corresponding to a black pixel.
Alternatively, operation information and reservation information may be expressed by the shadow of a three-dimensional object. In this case, the operation information and reservation information expressed by the shadow of the three-dimensional object may be changed by changing the shape of the shape-changing three-dimensional object. Also, operation information and reservation information expressed by the shadow of the three-dimensional object may be changed by preparing multiple three-dimensional objects and switching the three-dimensional objects used. In this case, wire or the like may be used as the three-dimensional object. In other words, expressions known in the field of so-called "shadow art" may be used.

In this embodiment, some of the functions of the server 4 described above may be realized by the microcomputer 70 of the projector 7, and conversely, some of the functions of the microcomputer 70 of the projector 7 described above may be realized by the server 4.

In addition, in this embodiment, other types of display devices (e.g., a normal dedicated display, a show window display, an aerial display) may be used instead of or in addition to the projector 7. Alternatively, a display in the house of a nearby resident (collaborator) may be used.

In addition, in this embodiment, the projection surface is changed according to the direction of sunlight by moving the projector 7, but this is not limited to the above. For example, multiple projectors 7 with different projection surfaces may be installed, and one projector 7 selected from the multiple projectors 7 according to the direction of sunlight may be operated.

[Gesture Recognition Device]
FIG. 20 is a diagram showing an example of a hardware configuration of the gesture recognition device 8. As shown in FIG.

The gesture recognition device 8 includes a microcomputer 80 (referred to as "microcomputer" in FIG. 20), and a communication module 8a and a camera 8b are connected to the microcomputer 80.

The communication module 8a performs two-way communication with the server 4.

The camera 8b captures an image of a user located near the projection surface on which the projector 7 projects the reservation reception information as described above. That is, the camera 3b is provided in a position where it can capture an image of a user making a gesture while looking at the projection image (reservation reception information) projected by the projector 7. The camera 3b may be provided on a wall that serves as the projection surface, as shown in FIG. 16, for example, or on a utility pole. In this case, the camera 8b may be installed on a wall of a building borrowed from the owner of the building. The camera 3b may also be mounted on an aircraft 60 as described with reference to FIG. 19, or on a walking robot or a traveling robot. The camera 8b may also be incorporated in a housing in which the microcomputer 80 is mounted, or may be located away from the housing. In this case, the camera 8b has a separate communication module (not shown) to enable communication with the microcomputer 80.

The camera 3b may be any camera capable of acquiring an image for gesture recognition, for example, a general-purpose camera equipped with a CCD (Charge Coupled Device) and a lens. Alternatively, the camera 3b may be a camera capable of acquiring a distance image. That is, the camera 3b may be a three-dimensional image sensor that senses the entire space to measure distances and acquire a distance image having distance information for each pixel like a digital image. In this case, the method of acquiring the distance information may be any method. For example, the method of acquiring the distance information may be an active stereo method in which a specific pattern is projected onto the target, read by an image sensor, and the distance is acquired by a triangulation method from the geometric distortion of the projected pattern. Alternatively, the method may be a time-of-flight (TOF) method in which a laser beam is irradiated, the reflected light is read by an image sensor, and the distance is measured from the phase shift.

The microcomputer 80 recognizes the user's gesture based on the image from the camera 3b. Methods for recognizing gestures based on an image are widely known, and any method (e.g., pattern matching or machine learning) can be used. Note that the method for recognizing gestures based on a distance image may be a mode in which the user's joints are recognized and then the gesture is recognized based on the movement of the joints. The gesture to be recognized is arbitrary, but may be specified in advance or may be indicated within the projected image output by the projector 7. For example, the gesture to be recognized may be a gesture corresponding to an instruction such as "image output," "back," "OK," or "cursor movement (indicating the movement direction)." Alternatively, the gesture to be recognized may be the pointing direction of the user's finger or hand (pointing direction relative to the projected image).

The microcomputer 80 transmits the gesture recognition result to the server 4. The gesture input processing unit 414 of the server 4 performs various processes for accepting reservations from users in cooperation with the projector 7 based on the gesture recognition result from the gesture recognition device 8.

For example, when the microcomputer 80 recognizes a specific gesture for a start instruction based on the image from the camera 3b, it transmits a gesture recognition result indicating that the specific gesture for a start instruction has been recognized to the server 4 so that various projection images for accepting a boarding request from the user can be projected. At this time, the microcomputer 80 may transmit an image from the camera 3b (an image showing the user's face) to the server 4. This allows the user identification unit 404 of the server 4 to identify the user performing the gesture.

FIG. 21 is a timing chart showing an example of information exchange for reservation acceptance realized by the projector 7, gesture recognition device 8, and server 4 (gesture input processing unit 414). Note that the projector 7 and gesture recognition device 8 may be provided in multiple pairs (e.g., multiple bus stops). In this case, the exchange shown in FIG. 21 relates to a certain pair of the projector 7 and gesture recognition device 8. Note that, among the exchanges shown in FIG. 21, the output (transmission) of information (including instructions) from the server 4 to the projector 7 or gesture recognition device 8 is realized by the output control unit 411 of the server 4.

First, the gesture recognition device 8 detects a person, and when it recognizes a predetermined gesture for issuing a start-up instruction by that person (e.g., a gesture of raising a hand), it transmits the start-up instruction (gesture recognition result) together with image data of the person's face to the server 4 (S210).

When the server 4 receives the face image data and the startup instruction (S212), it identifies the user based on the image data and transmits the startup instruction to the projector 7 (S214). At this time, the server 4 may also transmit information representing the identified user (e.g., the name included in the user information, face image data, etc.) to the projector 7. If the user cannot be identified, it may transmit information to that effect to the projector 7. In that case, the projector 7 may output information via the projected image that prompts the user to make the specified gesture for startup instruction again.

When the projector 7 receives the start-up instruction, it outputs reservation acceptance information by a projection image (S216). Note that, when information representing the user is transmitted from the server 4 to the projector 7 as described above, the projection image may include information on the name of the identified user. For example, such information may be in the form of a greeting such as "Hello, Gen-san." Alternatively, an image of a face may be output, or other information (e.g., unique information such as a user ID) may be output. This allows the user to know that they are recognized, which increases their sense of security.

The projected image related to the reservation acceptance information may be, for example, similar to the screens shown in Figures 13 to 15B. The user can proceed with the reservation procedure by performing various gestures while watching the projected image.

Specifically, when the gesture recognition device 8 recognizes any gesture among all gestures to be recognized, it transmits the gesture recognition result to the server 4 (S220).

When the server 4 receives the gesture recognition result (S222), it recognizes the user's instruction based on the relationship between the current projected image and the gesture recognition result, and instructs the projector 7 to transition the projected image according to the instruction (S224). As a result of such exchange, various inputs (for example, the planned disembarking location, accompanying person, etc. as described above) are made, and the server 4 finally instructs the projector 7 to output a projected image for confirming the reservation. Note that when a reservation is accepted via the projector 7, the planned boarding location may be the bus stop related to the installation location of the projector 7, and no instruction from the user may be required. However, if the projector 7 (and the gesture recognition device 8) is installed in a place unrelated to a bus stop, it may be necessary to specify the planned boarding location.

In response to an instruction from the server 4, the projector 7 outputs a projection image for confirming the reservation (S226). The projection image for confirming the reservation may include, for example, information about the reservation details (such as the planned drop-off location) and may also include information requesting a gesture for confirming the reservation.

If the user sees the projected image and there is no problem with the reservation contents, the user makes a gesture to confirm the reservation (for example, a gesture indicating OK). If there is an error in the reservation contents, the user makes a gesture to redo the reservation. Such a gesture is recognized by the gesture recognition device 8 in the same way. In this case, the gesture recognition device 8 transmits the gesture recognition result to the server 4 (S228). When the server 4 receives the gesture recognition result (S230), it recognizes the user's instruction based on the relationship between the current projected image and the gesture recognition result, and instructs the projector 7 to transition the projected image according to the instruction (S232). For example, if the current gesture recognition result is a gesture for confirming the reservation, it instructs the projector 7 to output a projected image to notify the completion of the reservation. In this case, the projector 7 outputs a projected image to notify the completion of the reservation (S234), and the processing of the projector 7 for accepting the current reservation is completed.

When the server 4 receives a gesture recognition result indicating a gesture for confirming a reservation, the server 4 generates a boarding request based on the reservation details (S236). As described above, the boarding request includes the user ID, the planned boarding location, the planned disembarking location, etc. When the boarding request is generated (obtained) in this manner, it is provided to the reservation reception unit 405 of the server 4.

In this embodiment, gesture input is used, but voice input may be used instead of or in addition to this. In this case, a voice recognition device is provided near the projection surface.

In this embodiment, some of the functions of the server 4 described above may be realized by the microcomputer 80 of the gesture recognition device 8, and conversely, some of the functions of the microcomputer 80 of the gesture recognition device 8 described above may be realized by the server 4.

[Example of operation of route bus system]
Next, with reference to flowcharts, we will explain some operation examples of the above-mentioned route bus system 1. In the following process flow diagrams (flowcharts), the processing order of each step may be changed as long as the relationship between the input and output of each step is not lost.

Figure 22 is a schematic flowchart showing an example of the operation of the server 4 when it functions as an information output device. The process shown in Figure 22 is repeatedly executed at predetermined intervals while the route bus 2 is in operation.

In step S320, the server 4 determines whether or not a boarding request has been acquired. As described above, the boarding request may be acquired by being received by the boarding request receiving unit 401, or may be generated (acquired) by the gesture input processing unit 414. If the determination result is "YES", the process proceeds to step S321; otherwise, the process ends.

In step S321, the server 4 determines whether the planned boarding location and the planned disembarking location included in the boarding request obtained in step S320 are on the planned driving course. For example, if the planned boarding location is the home location of the user related to the boarding request and the home location is outside the planned driving course, the determination result is "NO". If the determination result is "YES", the process proceeds to step S322, and otherwise the process proceeds to step S326.

In addition, in a modified example, when the determination result is "NO", instead of proceeding to step S326, in the case where multiple route buses 2 are operating simultaneously, it may be determined whether or not the planned boarding position and the planned disembarking position included in the boarding request obtained in step S320 are located on the planned driving course of the other route buses 2. Here, when multiple route buses 2 are operating simultaneously, the boarding request may be generated in a manner that specifies a specific route bus 2 (see FIG. 14B) or in a manner that does not specify a specific route bus 2 (see FIG. 14A). When the boarding request is generated in a manner that specifies a specific route bus 2, the other route bus 2 is the route bus 2 that arrives next at the planned boarding position among the route buses 2 other than the specific route bus 2. On the other hand, when the boarding request is generated without specifying a specific route bus 2, the other route bus 2 is the route bus 2 that arrives second at the planned boarding position among the multiple route buses 2 (in this case, the route bus 2 that arrives first at the planned boarding position among the multiple route buses 2 is treated as the first candidate route bus 2). If the planned boarding location and planned disembarking location included in the boarding request obtained in step S320 are located on the planned travel course of the other route bus 2, the process proceeds to step S346 in FIG. 23 (see circle 2), and the output control unit 411 of the server 4 may notify the user who made the current boarding request of information encouraging the user to change the boarding request to one for the other route bus 2. On the other hand, if the planned boarding location and planned disembarking location included in the boarding request obtained in step S320 are not located on the planned travel course of the other route bus 2, the process proceeds to step S325.

In step S322, the server 4 performs a boarding availability determination process to determine whether or not the user related to the boarding request obtained in step S320 is able to board. An example of the boarding availability determination process will be described later with reference to Figures 23 and 24. If the result of the boarding availability determination process indicates that the user related to the boarding request obtained in step S320 is able to board ("YES" in S323), the process proceeds to step S324; otherwise, the process proceeds to step S339.

In step S324, the reservation reception unit 405 of the server 4 receives a reservation for boarding the route bus 2 from the user related to the boarding request obtained in step S320. As a result, the reservation status information in the reservation status information storage unit 420 is updated.

In step S325, the course change processing unit 407 of the server 4 determines whether there is room for course change based on boarding section information, etc. For example, if the route bus 2 becomes full by the time the bus reaches the planned boarding location included in the boarding request obtained in step S320, or if a course cannot be established that passes through the planned boarding location and planned disembarking location of the reserved user and the planned disembarking location of the passenger while passing through the planned boarding location and planned disembarking location related to the boarding request, it is determined that there is no room for course change. If there is room for course change, proceed to step S326, and otherwise proceed to step S339. In a modified example, whether there is room for course change may also be determined in the course change possibility determination process described later.

In step S326, the course change processing unit 407 of the server 4 executes a course change feasibility determination process to determine whether or not a course change is possible. An example of the course change feasibility determination process will be described later with reference to FIG. 25. If the result of the course change feasibility determination process indicates that the course change is possible ("YES" in S327), the process proceeds to step S328; otherwise ("NO" in S327), the process proceeds to step S339.

In step S328, the reservation reception unit 405 of the server 4 receives a reservation for boarding the route bus 2 from the user related to the boarding request obtained in step S320. As a result, the reservation status information in the reservation status information storage unit 420 is updated.

In step S330, the course change reflection unit 4074 of the course change processing unit 407 of the server 4 updates the information (course information) representing the planned driving course in the planned driving course memory unit 426.

In step S332, the timetable generation unit 408 of the server 4 updates the timetable information in the timetable information storage unit 428.

In step S334, the output control unit 411 of the server 4 transmits the route information updated in step S330 and the timetable information updated in step S332 to the processing device 10 of the route bus 2, the associated user terminal 6, and the associated projector 7. The associated user terminal 6 includes the user terminal 6 of the user who has made a reservation for the route bus 2 with the route change, the user terminal 6 of the user related to the boarding request obtained in step S320, etc. The associated projector 7 includes the projector 7 installed at a bus stop or the like through which the route bus 2 with the route change will pass in the future, and if the boarding request obtained in step S320 was generated via the gesture recognition device 8, the projector 7 that functions in pairs with the gesture recognition device 8.

In step S336, the output control unit 411 of the server 4 extracts advertising data related to the next planned stop position on the new planned driving course (changed planned driving course) from the advertising information storage unit 430, and transmits the extracted advertising data to the processing device 10. Upon receiving the advertising data, the processing device 10 outputs the advertising data via the large display D1, displays D2 to D7, speaker 3a, etc.

In step S338, the output control unit 411 of the server 4 extracts a new planned stop position (a position that was not a planned stop position before the course change) on the new planned driving course (the planned driving course after the change) and transmits information on the extracted new planned stop position (for example, a name, etc.) to the processing device 10. When the information output control unit 114 of the processing device 10 receives the information on the new planned stop position, it outputs the information on the new planned stop position via the large display D1, displays D2 to D7, speaker 3a, etc. At this time, the information output control unit 114 of the processing device 10 may output a guide to change the planned disembarking position via the large display D1, displays D2 to D7, speaker 3a, etc. In this case, a passenger who finds the new planned stop position more convenient can change the planned disembarking position to the new planned stop position, improving convenience. For example, the passenger may use the user terminal 6 or displays D2 to D7 (if a touch panel type) to transmit a request to change the planned disembarking position to the new planned stop position to the server 4.

In step S339, the output control unit 411 of the server 4 notifies the user who made the current boarding request of information indicating that the current boarding request was not accepted (for example, information encouraging a change to the planned boarding location, etc.). Such notification can be realized via the user terminal 6 of the user related to the boarding request obtained in step S320, or, if the boarding request obtained in step S320 was generated via the gesture recognition device 8, via the projector 7 functioning in conjunction with the gesture recognition device 8.

According to the process shown in FIG. 22, the planned route of route bus 2 can be changed (route change) in response to a boarding request, improving user convenience. In particular, when route bus 2 travels in a relatively small area (e.g., a route of less than 20 km) and the cruising speed is about 20 km, it is expected that many users will use the bus without worrying about time. In such a case, even if the planned route is changed in this way, it is unlikely that passengers will become dissatisfied, and the effect of improving convenience will be significant.

Furthermore, according to the process shown in FIG. 22, when a route change is made, new route information is sent to the processing device 10 of the route bus 2, the user terminal 6, and the projector 7, so that the new route information can be output to passengers and users. This makes it easy to understand that the cause is a route change, even if there is a delay in the operation of the route bus 2, and realizes a configuration that is less likely to cause dissatisfaction with the route change. Furthermore, if the changed route passes near one's home, for example, a user who initially planned to walk may reconsider taking the route bus 2. In this way, it is expected that there will be an effect of attracting users who do not usually use route buses 2.

In addition, according to the process shown in FIG. 22, when a route change is made, the timetable information that may change dynamically in response to the route change is sent to the processing device 10 of the route bus 2, the user terminal 6, and the projector 7, so that the new route information can be output to the passengers and the user. As a result, even if there is a delay in the operation of the route bus 2, the user can check the extent of the delay based on the timetable information, so a configuration can be realized that is less likely to cause dissatisfaction with the route change.

Figure 23 is a schematic flowchart showing an example of step S322 (boarding eligibility determination process) in Figure 22.

In step S340, the boardable section derivation unit 400 of the server 4 derives the boardable section. The method for deriving the boardable section is as described above.

In step S341, the boarding availability determination unit 402 of the server 4 determines whether the planned boarding location and planned disembarking location are within the boarding available section based on the boarding available section derived in step S340 and the planned boarding location and planned disembarking location included in the boarding request. Note that when a boarding request including information indicating the number of accompanying persons is transmitted to the server 4, the boarding availability determination unit 402 may also determine whether the total number including accompanying persons is within the number of people who can board (see FIG. 7C). If the planned boarding location and planned disembarking location are within the boarding available section, proceed to step S342; otherwise, proceed to step S343.

In step S342, the server 4 generates a determination result indicating that boarding is possible. In this case, the determination in step S323 in FIG. 22 above is "YES."

In step S343, the server 4 determines whether multiple route buses 2 are operating simultaneously. If the determination result is "YES", the process proceeds to step S344; otherwise, the process proceeds to step S347.

In step S344, the server 4 acquires boarding section information for the other route buses 2. Note that when multiple route buses 2 are operating simultaneously, the boarding request may be generated in a manner that specifies a specific route bus 2, as described above, or may be generated without specifying a specific route bus 2. When the boarding request is generated in a manner that specifies a specific route bus 2, the other route bus 2 is a route bus 2 other than the specific route bus 2 that is to arrive next at the planned boarding position. On the other hand, when the boarding request is generated without specifying a specific route bus 2, the other route bus 2 is a route bus 2 that is to arrive second at the planned boarding position, among the multiple route buses 2.

In step S345, the server 4 determines whether the planned boarding location and planned disembarking location are within the boarding section based on the boarding section information for the other route bus 2 obtained in step S344 and the planned boarding location and planned disembarking location included in the boarding request. If the determination result is "YES", the process proceeds to step S346, and otherwise the process proceeds to step S347.

In step S346, the output control unit 411 of the server 4 notifies the user who made the current boarding request of information encouraging the user to change the boarding request to one for another route bus 2. Such notification can be realized via the user terminal 6 of the user related to the boarding request obtained in step S320, or, if the boarding request obtained in step S320 was generated via a gesture recognition device 8, via the projector 7 functioning in conjunction with the gesture recognition device 8.

In step S347, the server 4 generates a determination result indicating that boarding is not possible. In this case, the determination in step S323 in FIG. 22 above is "NO."

According to the process shown in FIG. 23, boarding availability can be determined using boarding request available section information derived by taking into account the passenger's planned disembarking location, etc., so that a highly accurate determination can be realized. In other words, it is possible to reduce the possibility of determining that boarding is not possible when in fact boarding is possible, or conversely, determining that boarding is possible when in fact boarding is not possible. As a result, efficient transportation (movement of people) by route bus 2 can be realized.

In addition, according to the process shown in FIG. 23, if it is determined that boarding the first candidate route bus 2 is not possible, and multiple route buses 2 are operating simultaneously, the possibility of boarding another route bus 2 is determined, thereby improving user convenience.

Figure 24 is a schematic flowchart showing another example of step S322 (boarding eligibility determination process) in Figure 22.

The process in FIG. 24 differs from the process in FIG. 23 in that step S341 is replaced with step S341A.

In step S341A, the boarding availability determination unit 402 of the server 4 determines whether the planned boarding location and the planned disembarking location are within the boarding permitted area, and based on the desired arrival time at the planned disembarking location of the user related to the boarding request, whether the delay time of the planned arrival time at the planned disembarking location relative to the desired arrival time is equal to or less than a predetermined threshold Th5. The predetermined threshold Th5 may be variable according to the leeway of the user related to the boarding request. For example, the predetermined threshold Th5 may be variable so that the lower the leeway, the smaller the predetermined threshold Th5. If the determination result is "YES", proceed to step S342, and otherwise proceed to step S343.

The process shown in FIG. 24 not only provides the effect of the process shown in FIG. 23, but also allows the determination of whether or not to board the bus in a manner that takes into account the individual circumstances of the user. In other words, the desired arrival time and the margin of error are taken into consideration, so that the inconvenience of boarding a route bus 2 that does not allow the user to arrive at the planned disembarkation location at the desired time can be prevented.

In addition, in step S345 of FIG. 24, it may also be determined whether the delay time of the scheduled arrival time at the planned disembarking location for another route bus 2 relative to the desired arrival time (the desired arrival time at the planned disembarking location of the user related to the boarding request) is less than or equal to a predetermined threshold value Th5.

Note that the process shown in FIG. 24 has been described as an alternative to the process shown in FIG. 23, but it may be used differently depending on whether the boarding request includes information about the desired arrival time.

Figure 25 is a schematic flowchart showing an example of step S326 (course change possibility determination process) in Figure 22.

In step S350, the server 4 determines whether multiple route buses 2 are operating simultaneously. If the determination result is "YES", the process proceeds to step S352; otherwise, the process proceeds to step S354.

In step S352, the route change processing unit 407 of the server 4 executes a route change possibility determination process (hereinafter referred to as "inter-route bus cooperation process") when multiple route buses 2 are operating simultaneously. An example of the inter-route bus cooperation process will be described later with reference to FIG. 26.

In step S354, the server 4 reads out the course change determination information stored in the course change determination information storage unit 423. In a configuration in which the course change determination information storage unit 423 is omitted, the server 4 may read out the seat status information in the seat status information storage unit 425 or the timetable information in the timetable information storage unit 428 as the course change determination information.

In step S356, the change cost calculation unit 4071 of the server 4 calculates the change cost based on the course change determination information obtained in step S354. The method of calculating the change cost is as described above.

In step S358, the change possibility determination unit 4072 of the server 4 determines whether or not it is possible to change the planned driving course from the current course to the planned changed course, based on the change cost calculated in step S356. For example, the change possibility determination unit 4072 permits the change if the change cost is equal to or less than a predetermined threshold value Th1. If the change is permitted, the process proceeds to step S360, and if the change is not permitted, the process proceeds to step S362.

In step S360, the change possibility determination unit 4072 of the server 4 generates a determination result indicating that a course change is possible. In this case, the determination in step S327 in FIG. 22 above is "YES."

In step S362, the change possibility determination unit 4072 of the server 4 generates a determination result indicating that the course cannot be changed. In this case, the determination in step S327 in FIG. 22 above is "NO."

According to the process shown in FIG. 25, when a boarding request that requires a route change is acquired, the possibility of the route change is determined based on the change cost calculated based on the route change determination information. This takes into account delay times related to the expected arrival times at the planned disembarking locations of each passenger, making it possible to determine whether or not the route change can be made based on highly fair criteria. As a result, a route bus system 1 that is highly convenient and unlikely to cause user dissatisfaction can be realized.

Figure 26 is a schematic flow chart showing an example of step S352 (inter-route bus coordination processing) in Figure 25. Here, as an example, it is assumed that two route buses 2 are operating simultaneously. Note that Figure 26 shows an example of the operation when the server 4 functions as a driving assistance device.

In step S380, the server 4 reads out various information (operation information) related to each route bus 2. The various information to be read out includes vehicle status information (particularly vehicle position information) in the vehicle status information storage unit 424 and course information in the planned travel course storage unit 426.

In step S382, the change possibility determination unit 4072 of the server 4 calculates the distance between the two route buses 2 based on the various information obtained in step S380. The distance between the two route buses 2 may be the distance along the planned travel course. The distance may be calculated as a distance (inter-vehicle distance) or as a time (inter-vehicle time). In the case of time, it may be derived by dividing the inter-vehicle distance by the cruising speed, or it may be calculated as the difference between the planned arrival times.

In step S384, the changeability determination unit 4072 of the server 4 determines whether the interval calculated in step S382 is shorter than the predetermined threshold value Th4. If the determination result is "YES", the process proceeds to step S386; otherwise, the process proceeds to step S392.

In step S386, the change possibility determination unit 4072 of the server 4 reads out the course change determination information stored in the course change determination information storage unit 423 for the rear route bus 2 of the two route buses 2.

In step S388, the change possibility determination unit 4072 of the server 4 determines whether or not it is possible to change the planned route of the route bus 2 based on the route change determination information obtained in step S386. The method of this determination may be as described above (for example, it may be a method that uses the change cost calculated by the change cost calculation unit 4071 as described above). If the determination result is "YES", proceed to step S390, and otherwise proceed to step S392.

In step S390, the change possibility determination unit 4072 of the server 4 generates a determination result indicating that the course of the rear route bus 2 of the two route buses 2 can be changed. In this case, the determination in step S327 in FIG. 22 above is "YES", and the processes from step S328 to step S334 are executed for the rear route bus 2 of the two route buses 2.

In step S392, the change possibility determination unit 4072 of the server 4 generates a determination result indicating that the course cannot be changed. In this case, the determination in step S327 in FIG. 22 above is "NO."

According to the process shown in FIG. 26, when two route buses 2 are operating simultaneously and the distance between the two route buses 2 is shorter than a predetermined threshold value Th4, a determination is made as to whether the route bus 2 behind can change course. As a result, when the course is changed, the distance between the two route buses 2 may increase due to a delay of the route bus 2 behind (due to a delay associated with the course change). Therefore, it is possible to increase the convenience of changing the course while widening the distance between the two route buses 2.

In the process shown in FIG. 26, it is assumed that two route buses 2 are operating at the same time, but this is not limited to the case. The same may be true even when three or more route buses 2 are operating at the same time. In this case, the interval between each route bus 2 may be calculated, and for a pair (which may be one or more pairs) of two route buses 2 whose interval is shorter than a predetermined threshold Th4, it may be determined whether the rear route bus 2 and/or the front route bus 2 can change course. In addition, if there are two or more pairs of two route buses 2 whose interval is shorter than the predetermined threshold Th4, the pair with the smallest interval may be determined first. Alternatively, it may be determined whether a certain route bus 2 is capable of changing course only when the interval between the route bus 2 running in front of the target and the route bus 2 running in front of the target is shorter than the predetermined threshold Th4 and the interval between the route bus 2 running behind the target is longer than the predetermined threshold Th6. The predetermined threshold value Th6 may be set from the viewpoint of ensuring that even if the target route bus 2 is delayed due to a change in route, the distance between the target route bus 2 and the route bus 2 behind it does not become equal to or smaller than the predetermined threshold value Th4.

26, if the determination result in step S384 or step S388 is "NO", the process proceeds to step S392, but before proceeding to step S392, it may be determined whether a change in course is possible for the other route bus 2. In this case, if a change in course is possible for the other route bus 2, the process may proceed to step S390. In this case, the possibility that a change in course is possible increases, and convenience for users who wish to change course can be improved.
Fig. 27 is a schematic flow chart showing another example of step S352 (inter-route bus cooperation process) in Fig. 25. Note that Fig. 27 shows an example of the operation when the server 4 functions as a travel assistance device.

In step S400, the server 4 reads out various information (operation information) related to each route bus 2. The various information to be read out includes vehicle status information (particularly vehicle position information) in the vehicle status information storage unit 424 and course information in the planned travel course storage unit 426.

In step S402, the change cost calculation unit 4071 of the server 4 calculates the change cost for each route bus 2 based on the various information obtained in step S400. The method of calculating the change cost is as described above.

In step S404, the change possibility determination unit 4072 of the server 4 determines whether or not there is a route bus 2 among the multiple route buses 2 whose change cost is equal to or less than the predetermined threshold value Th1. If the determination result is "YES", the process proceeds to step S406, and otherwise the process proceeds to step S412.

In step S406, the change possibility determination unit 4072 of the server 4 calculates the waiting time of the user related to the boarding request (the time to wait before boarding) for each route bus 2 whose change cost is equal to or less than the predetermined threshold value Th1.

In step S408, the change possibility determination unit 4072 of the server 4 determines whether the route bus 2 with the shortest waiting time among the route buses 2 with a change cost equal to or less than the predetermined threshold Th1 is the first candidate route bus 2. As described above, if a specific route bus 2 is specified at the time of the boarding request, the first candidate route bus 2 is the specific route bus 2. If a specific route bus 2 is not specified at the time of the boarding request, the route bus 2 with the shortest waiting time becomes the first candidate route bus 2, and the determination result of step S408 automatically becomes "YES". If the determination result is "YES", proceed to step S410, and otherwise proceed to step S346 in FIG. 23. In the latter case, the output control unit 411 of the server 4 notifies the user who made the current boarding request of information encouraging the user to change the boarding request to another route bus 2 (the route bus 2 with the shortest waiting time among the route buses 2 with a change cost equal to or less than the predetermined threshold Th1).

In step S410, the change possibility determination unit 4072 of the server 4 generates a determination result indicating that a course change is possible. In this case, the determination in step S327 in FIG. 22 above is "YES."

In step S412, the change possibility determination unit 4072 of the server 4 generates a determination result indicating that the course cannot be changed. In this case, the determination in step S327 in FIG. 22 above is "NO."

According to the process shown in FIG. 27, it is possible to identify a route bus 2 from among multiple route buses 2 operating simultaneously, the change cost of which is equal to or less than a predetermined threshold Th1 and the waiting time is the shortest. This increases the possibility of changing the planned route of the route bus 2, thereby achieving both convenience for users who wish to change the route and efficient operation of the route bus system 1.

In FIG. 27, the waiting time is evaluated, but the distance of each route bus 2 to the planned boarding position (the distance along the planned route) may be equivalently evaluated. In other words, any parameter such as time or distance may be used as long as the relationship between each route bus 2 and the user's planned boarding position is evaluated. Also, as described above, the waiting time may be taken into account when calculating the change cost.

As described above, in the modified example, some or all of the processing shown in FIG. 22 (including the processing shown in FIGS. 23 to 27) may be implemented by the processing device 10 of the route bus 2 (or by the processing device 10 of each of the route buses 2 when multiple route buses 2 operate simultaneously). For example, when multiple route buses 2 operate simultaneously, the processing device 10 of each route bus 2 may execute the processing shown in FIG. 22. In this case, acquisition of information from other route buses 2 (for example, step S344 in FIG. 23) may be implemented by one of the multiple route buses 2 that serves as a master, or may be implemented by each of the multiple route buses 2. In the latter case, the determination result may be supplied to the server 4, and the final decision may be made on the server 4 side.

Although each embodiment has been described in detail above, it is not limited to a specific embodiment, and various modifications and changes are possible within the scope of the claims. It is also possible to combine all or some of the components of the above-mentioned embodiments.

For example, in the above-described embodiment, the route bus 2 is configured to be capable of autonomous driving (automatic driving), but this is not limited to this. The route bus 2 may have some or all of its braking, driving, and steering realized by a human driver.

In the above embodiment, when the planned travel course is changed from the basic course to another course based on a certain boarding request, information on the boarding request that caused the change may be output. For example, an announcement may be made in the route bus 2 saying, "Hana-san has requested to board near her home, so this vehicle will change from the specified course." In this case, passengers who are acquainted with Hana-san can expect Hana-san to board. For example, "I see. Hana-san is getting on. I'll leave the seat next to me free. I'm excited." In addition, an announcement may be made in the route bus 2 saying, "Hana-san, who will board at the next stop, wants to get off at the cake shop, so this vehicle will change from the specified course." In this case, passengers who are acquainted with Hana-san can consider changing the planned disembarking location along with Hana-san's boarding. For example, a passenger may say, "I see. Hana-san is getting on. I'll change my plans and get off at the cake shop to go on a date with Hana-san."

In the above embodiment, the course change processing unit 407 changes the planned driving course from the basic course to another course based on a boarding request from the user, but the planned driving course may also be changed from the basic course to another course based on other requests. For example, the course change processing unit 407 may change the planned driving course from the basic course to another course based on a request from the passenger to change the planned disembarkation location. In this case, if the new planned disembarkation location does not exist on the current planned driving course, the course change processing unit 407 may determine whether to change the planned driving course from the basic course to another course (a course that passes through the new planned disembarkation location) in the same manner as described above.

1 Route bus system 2 Route bus 3 Input device 3a Speaker 3b Camera 3c Autonomous driving sensor 3d Braking and driving force control device 3e Steering control device 3f GPS receiver 4 Server 5 Town Mobi app 6 User terminal 7 Projector 7a Communication module 7b Motor 7c Light source 8 Gesture recognition device 8a Communication module 8b Camera 9 Network 10 Processing device 30 Electronic device 60 Air vehicle 70 Microcomputer 80 Microcomputer 102 Planned driving course receiving unit 103 Timetable information receiving unit 104 Sensor information acquisition unit 106 Vehicle position information acquisition unit 108 Target braking and driving force determination unit 110 Target steering angle determination unit 112 Occupant state detection unit 114 Information output control unit 116 Occupant request transmission unit 120 Planned driving course memory unit 400 Boarding possible section derivation unit 401 Boarding request receiving unit 402 Boarding possibility determination unit 404 User identification unit 405 Reservation acceptance unit 406 Planned disembarking position change receiving unit 407 Course change processing unit 4071 Change cost calculation unit 4072 Change possibility determination unit 4074 Course change reflecting unit 408 Timetable generation unit 409 Vehicle state update unit 410 Seat state update unit 411 Output control unit 4110 Boarding available section notification unit 4112 Timetable notification unit 4114 Course information notification unit 4116 Boarding request change request unit 4118 Gesture input guidance unit 4120 In-car advertisement output unit 4122 Disembarking information output unit 412 User registration processing unit 414 Gesture input processing unit 420 Reservation state information storage unit 421 Boarding available section storage unit 422 User information storage unit 423 Course change determination information storage unit 424 Vehicle state information storage unit 425 Seat state information storage unit 426 Planned driving course storage unit 428 Timetable information storage unit 430 Advertisement information storage unit

Claims (6)

A vehicle guidance device applicable to a vehicle that travels or travels back and forth along a predetermined course including a plurality of boarding and alighting positions and in which a plurality of users can get on and off,
based on a change in a planned travel course of the vehicle from the predetermined course to another course while the vehicle is traveling along the predetermined course,
Changed course information representing the other course;
timetable information relating to at least one of the plurality of boarding and alighting locations, the timetable information indicating an estimated arrival time of the vehicle;
When the planned travel course is changed to another course based on a boarding request from the user, information including a proper noun of the user who is the sender of the boarding request that caused the change, the information being a unique guide for the user who is currently riding;
A vehicle information device that outputs information inside the vehicle. A planned disembarking location of each of the users is stored in association with the user's identification information,
The vehicle guidance device according to claim 1 , further outputting, when the vehicle stops at a certain location, guidance inside the vehicle encouraging a user whose identification information is associated with a planned disembarking location corresponding to the location to disembark. The vehicle guidance device according to claim 1, further outputting an advertisement related to the other course inside the vehicle when the planned travel course is changed to the other course. The vehicle guidance device according to claim 1, which accepts a change of the planned disembarkation location to a new location where the vehicle can stop when the planned travel course is changed to another course. The vehicle guidance device according to claim 1, wherein the guidance is output via an output device attached to the back of the seat back of the seat in front of the corresponding user. The vehicle guidance device according to claim 1, wherein the guidance is output from a movable audio speaker in the vehicle that moves to the vicinity of the corresponding user, or is output in the direction of the corresponding user via a speaker with variable directionality.

Images