JP7200315B2 - Management server, display method and program in system promoting matching between user and vehicle - Google Patents

Description

The present invention relates to a system that promotes matching between a user and a vehicle that the user wants to ride.

Conventionally, when looking for transportation means such as buses, taxis, trucks, etc., technology to provide a transportation means call service to users and technology to match vehicle requests and vehicles that users want to use. It has been known.

For example, Patent Literature 1 discloses a transport means call server that provides a transport means call service, a transport means call service system having the transport means call service system, and a transport means call service method using the same.

Further, Patent Literature 2 discloses a method for managing vehicle requests by a server that can access data indicating the current location of each of a plurality of vehicles. A method is disclosed comprising generating one or more clusters each containing a demand, and matching a vehicle with each vehicle demand in the or each cluster.

Japanese Patent Application Publication No. 2016-509287 JP-A-2017-33568

By the way, as the government has presented in the Public-Private ITS Initiative/Roadmap 2016, efforts toward the realization of "unmanned automated driving transport services in limited areas" are accelerating. This is an attempt to provide a service similar to local public transportation within a restricted area (limited area), and basically it is assumed to be a means of transportation that connects the limited area to the local public transportation. There is, but the possibility of boarding and alighting from in front of the entrance of the house is also being considered. Universities and companies are already demonstrating automated driving technology on public roads, and if this trend continues, it is expected that the service will begin to spread in fiscal 2020, according to the government's roadmap. . However, there are still many difficult challenges to be overcome in completely unmanned automation, including general roads, and it is expected that attempts to automate vehicles with humans on board in limited areas will continue in the future.

The inventors are mainly conscious of the following three social issues, and have conducted demonstration experiments with local transportation operators with the aim of early launch of an unmanned automated driving transportation service that will be incorporated into the real world.
1) The arrival of an era of shortages of bus and taxi drivers is a serious social issue. 2) The number of areas where public transportation is unsustainable is increasing at an accelerated pace due to the burden of driver labor costs due to a decrease in the number of users. Without new means of transportation, we will not be able to support the rapidly aging society.

In this context, we came to the realization that one of the specific issues facing automated driving transport services is the importance of technology that promotes matching between users and the vehicles they want to ride. However, even if you try to grasp the position of the vehicle and yourself on a simple two-dimensional Internet map, you cannot grasp where the vehicle is, whether it is coming or going, or where you are. In some cases, it was not possible to confirm appropriate matching between a person and a vehicle. This is regardless of whether the vehicle is unmanned or manned.

Therefore, in the present invention, in view of the above problems, while looking ahead to the realization of unmanned automatic driving services in the future, the present invention is applicable to current manned driving services. To provide a method for easily confirming pairs of matched users and vehicles on a map.

In order to solve the above problems, the present invention provides the following solutions.
(1) Use as a management server in a system that matches a user with a vehicle that the user wants to ride, and searches for a vehicle that matches the boarding request based on the user's boarding request and vehicle location information. Person/vehicle matching means, 3D map generating means for generating a 3D map containing location information of the user and the matched vehicle, and buildings, etc. ( buildings, houses, bridges, stations, and other structures), the user/vehicle matching means removes or sees through and displays a stereoscopic image of the user/vehicle. A management server characterized by displaying, on the 3D map, a line image in which the image of the user and the image of the vehicle are always connected by a single line to represent the relation of connection between the two.

(2) The user/vehicle matching means includes an image of the user for representing the relationship between the user and the vehicle and/or objects other than the vehicle related to the vehicle (hereinafter referred to as vehicles). A line image, which is always connected to the image of the vehicle or the like with a single line, is displayed stepwise on the 3D map depending on how the vehicle or the like or the user sees it.

(3) In the above configuration (1) or (2), the building removal/perspective display means displays objects related to road traffic such as stops, traffic lights, road signs, and road construction installations on the 3D map. is selected, information related to the traffic installation is displayed.

(4) In any one of the above configurations (1) to (3), the user/vehicle matching means predicts a boarding point at which the matched vehicle will be boarded and an arrival time of the vehicle at the boarding point. It is characterized by displaying as

(5) In any one of the configurations (1) to (4) above, the user/vehicle matching means displays that the matched vehicle is moving in response to the user's boarding request. characterized by

(6) In any one of the above configurations (1) to (5), the building removal/perspective display means displays a 3D map from the viewpoint of the user or the viewpoint of the driver of the matched vehicle. characterized by

(7) The user/vehicle matching means displays, at night, the user or the matched vehicle as if illuminated by a spotlight.

(8) A display method in a system for matching a user with a vehicle that the user wants to ride, the step of searching for a vehicle that matches the boarding request based on the user's boarding request and vehicle position information. a step of generating a 3D map containing location information of the user and the matched vehicle; and building, etc. (buildings, houses, bridges, stations, etc.) around the user and the matched vehicle from the 3D map. removing or transparently displaying a stereoscopic image of other buildings), and in the step of searching for the matching vehicle, the image of the user and the image of the user to show the relationship between the user and the vehicle. A display method, comprising the step of displaying on the 3D map a line image that is always connected to the image of the vehicle by a single line.

(9) A program that causes a computer to execute the steps described in (8) above.

According to the present invention, it is possible to provide a method for easily confirming matched pairs of a user and a vehicle on a three-dimensional map containing many buildings.

1 is a diagram showing a basic image of a "user/vehicle matching system" according to an embodiment of the present invention; FIG. It is a continuation diagram showing a basic image of the "user/vehicle matching system" according to the embodiment of the present invention. 1 is a diagram showing the functional configuration of a core management server that controls a "user/vehicle matching system" according to an embodiment of the present invention; FIG. It is a figure which shows the structure of the data stored in the database (DB) of the management server which concerns on embodiment of this invention. It is a figure which shows the processing flow of matching of a user and a vehicle. It is a figure which shows the example of the input screen of a user's boarding request.

EMBODIMENT OF THE INVENTION Hereinafter, with reference to an accompanying drawing, the form (henceforth, embodiment) for implementing this invention is demonstrated in detail. In subsequent figures, the same numbers or symbols are attached to the same elements throughout the description of the embodiments. In the diagram of the functional configuration, arrows between functional blocks indicate the data flow direction or the processing flow direction.

(Basic image of service)
1 and 2 are diagrams showing basic images of services provided by a "user/vehicle matching system" (hereinafter referred to as "this system") according to an embodiment of the present invention. "Matching" as used herein means that the conditions of the user and the vehicle that the user wishes to use are compatible with each other.

1 and 2 are screen images displayed by this system on a terminal possessed by a user 10 (a person who wishes to use a vehicle). What is displayed here is a stereoscopic image of a plurality of vehicles running/stopped/parked in an urban area or a non-urban area, "buildings, etc." (buildings, houses, bridges, stations, and other buildings) are three-dimensional maps (3D maps) containing stereoscopic images. Since it is a three-dimensional map, it is naturally possible to depict images (including moving images) from all angles, front, back, left, right, up and down. Also, the viewpoint of the 3D map can be set not only from the viewpoint of the user 10, but also from the viewpoint from the vehicle 20, or from any other position. If you set the viewpoint from directly above, it becomes a normal two-dimensional map. Various display methods of the 3D map are described below.

In FIG. 1(a), on the 3D map, "buildings, etc." that block the view of the user 10 are not displayed, and vehicles 20 (passenger cars, buses, taxis, trucks, motorcycles, community vehicles, etc.) and stops are displayed. , traffic lights, road signs, road construction installations, and other objects related to road traffic (hereinafter referred to as "traffic installations"). Here, a community vehicle (hereinafter abbreviated as "CV") is a vehicle that is used only in a specific area, and includes a community bus that operates on demand and a general vehicle that is used for transportation. , whether it is a manned vehicle or an unmanned vehicle. 1 and 2, only a bus stop 21 and a taxi stand 22 are shown in a simplified form as "traffic installations".

In addition, as indicated by the dotted line 23 in FIG. 1(a), the vehicle 20 matching the user 10 displays a line image indicating that the two are matched, as if they were connected by a "red thread". may be displayed. A user 10 who sees the display screen of FIG. 1A can easily confirm (discover) not only vehicles within the field of view but also vehicles and stops that are blocked by buildings and the like and are not within the field of view.

In FIG. 1(b), instead of removing all the stereoscopic images such as buildings in the surroundings and displaying them, by using only the data of the boundary lines of roads and buildings (DB without data in the height direction), This is a display that gives depth only to the boundaries of roads and buildings. By doing so, the shapes of buildings and the like become clearer than in the display method of FIG.

In FIG. 1(c), the images of buildings etc. are not completely removed as in FIG. 1(a), but only the three-dimensional contours (frame images) of buildings etc. . That is, the user 10 can see through a building or the like that blocks the view. Completely removing images of buildings, etc. makes it easier to check the conditions of vehicles and roads, but on the other hand, displaying the outlines of surrounding buildings, etc., is often more advantageous for grasping positional relationships. (Especially if there is a height difference). This system can display any of the 3D maps shown in FIGS. Although roadside trees and plants are not included in the concept of buildings and traffic installations, they may become objects that block visibility. It may be included in a traffic facility (the latter is adopted in the figure).

FIG. 2(a) is a 3D map in which the matched user 10 and the vehicle 20 are displayed as if they were illuminated by a spotlight, instead of being connected by a line image. In this processing, the terminal of the user 10 may detect the brightness of the surroundings and automatically switch to this display screen at night.

FIG. 2(b) is a screen displaying that the matched vehicle 20 is moving to a place where the user 10 is waiting in response to a boarding request from the user 10 (boarding request). By doing so, the user 10 can easily grasp where the target vehicle 20 is currently running, whether it is heading towards him, whether it is moving away, whether it is stuck in a traffic jam, etc. Therefore, you can wait at the scheduled boarding point without feeling frustrated and with a sense of security.

In this way, even if the target vehicle is out of sight, the user can approach and board the vehicle 20 regardless of the intended boarding point, for example, during traffic jams. At this time, if the place where the user 10 is waiting is a one-way street, road construction, etc., and it is difficult to enter from the moving direction of the vehicle 20, the nearest accessible place (point P in the figure) ) can be urged to the user 10 .

Also, although illustration is omitted, when a hotel or an inn, or a family member's or acquaintance's vehicle picks you up, the desired boarding place (pick-up point) or the desired alighting place (drop-off point) is displayed on a map from the terminal of the user 10. If you touch on it, the location may be displayed on the vehicle's in-vehicle terminal. Conversely, the driver of the vehicle may touch a place where it is easy to pick up, and the information may be transmitted to the terminal of the user 10 together with the image. Also, at this time, a predetermined image (which will be called a “virtual stop”) may be displayed on the 3D map at the pick-up point or drop-off point.

FIG. 2(c) is a screen displaying information such as the departure time of the bus and the fare of the taxi when the user 10 intends to use a bus or a taxi instead of the vehicle 20. FIG. For example, when a bus stop 21 is touched in FIG. 2(c), the timetable, route map, destination, operation status, etc. of that bus stop may be displayed. Further, when the taxi stand 22 is touched, the fare and required time to the destination may be displayed. That is, when a traffic installation object is touched, information related to the traffic installation object is displayed. At this time, it is desirable to minimize the effort required for the user 10 to input necessary information in consideration of the elderly and physically handicapped.

Also, for example, if the destination desired by the user is "Hospital B", when the bus stop is touched, the message "To hospital B is 1250 yen" is displayed as shown in FIG. 2(c). In the conventional boarding guidance system, once the destination is entered, instructions are given from start to finish, such as which bus stop to go to, which bus stop to get off, and to walk this route on foot. It is normal to get an answer. On the other hand, with this system, for example, if you ask a person, "You can go to the bus stop ahead," and if you look closely, there are two bus stops that you can see. I don't go to B hospital." If the other bus stop is touched, it is possible to display "I am going to B hospital. The fare is 1250 yen." In other words, it is possible to cope with such a case because it is easier to understand on site if the operation is interactive rather than instructed by a computer.

By means of the display method for matching people and vehicles as described above, it is possible to provide detailed transportation services closely related to daily life.

(Function configuration)
FIG. 3 is a diagram showing the functional configuration of the management server 100 in the user/vehicle matching system (this system) according to the embodiment of the present invention. This system is a system in which a user terminal 10 and an in-vehicle terminal 20 are connected via a network 30 with a management server 100 as the core.

As shown in the figure, a management server 100 (hereinafter simply referred to as a server) includes, as function execution units, position information acquisition means 101, user request acquisition means 102, vehicle information acquisition means 103, user/vehicle matching means 104, 3D map generation means 105 , building removal/perspective display means 106 , and vehicle operation information acquisition means 107 are provided. The user terminal 10 may be a general mobile terminal such as a smart phone or a tablet terminal, or may be a simple terminal dedicated to this system. Also, the in-vehicle terminal 20 is an arbitrary information terminal device mounted in a vehicle, and may be, for example, a car navigation system.

The positional information obtaining means 101 sequentially obtains the positional information of the user terminal 10 and the vehicle that provides the boarding service. The user request acquisition means 102 acquires a boarding request (boarding request) from the user terminal 10 . Vehicle information acquisition means 103 acquires various information other than vehicle position information (for example, vehicle type, passenger capacity, type, etc.).

The user/vehicle matching means 104 matches the user with the vehicle based on the user request acquired by the user request acquisition means 102 and the vehicle information including the position information of the vehicle.
If there are a plurality of matching vehicles, means for the user to select is provided. In addition, priority items for matching (for example, priority on arrival time, priority on charge, priority on riding comfort, etc.) may be specified.

The 3D map generating means 105 generates the above-described 3D map, and the building removal/perspective display means 106 removes the entire image of the building, etc., partially removes the image while leaving the boundary line, or sees through the building, etc. A frame image for the purpose is generated and displayed on the user terminal 10 . In addition, the building removal/perspective display means 106 displays information related to the traffic installation in response to the selection of the traffic installation on the 3D map (for example, by touching the screen). can be At this time, although illustration is omitted, it is needless to say that a means for acquiring information desired by the user for the traffic installation and a means for acquiring information related to the traffic installation are provided.

The vehicle operation information acquisition means 107 predicts the operation information of the vehicle, the arrival time to the boarding point, and the required time to the destination point. In the case of regular service vehicles, timetables are also acquired. In addition, although illustration is omitted, road information acquisition means and the like may be provided. The acquired information may be combined with a 3D map and displayed on the user terminal 10 .

Although the details will be described later, the server includes a user DB 111 that stores user information, a vehicle DB 112 that stores vehicle information, and a database (DB) that stores various data necessary for processing by the function execution unit. It has a 3D map data DB 113 that stores three-dimensional map data, and a transportation operation information DB 114 that stores operation information of public transportation and the like.

FIG. 4 is a diagram showing the configuration of data stored in the database (DB) of the management server according to the embodiment of the invention. In FIG. 4, each DB is assumed to be on the server side, but part or all of it may be on the user terminal side.

The user DB 111 stores user static information as profile information 111a. Specifically, the information includes user ID, address and name, age, gender, smoking status, hobbies, etc., which are information for more precise matching. These profile information are not essential, but if the age, gender, and smoking status are registered, for example, a more suitable vehicle for the user can be matched. In addition, in the user DB 111, as dynamic information 111b that changes from time to time, the current position (user's position information), points earned by using this service, whether or not to share a ride, whether to share a ride, User information and boarding history may be included.

The vehicle DB 112 stores static vehicle information as profile information 112a. Specifically, starting with the vehicle ID, the vehicle's affiliation (owner), type (bus, passenger car, truck, etc.), attributes (business use, personal use), vehicle type, passenger capacity, fuel consumption, automatic driving type (automatic Information on whether the vehicle can be driven, if it is permitted, whether it is manned or unmanned), and information such as the manager of the vehicle. Not all of this profile information is necessarily required, but the larger the amount of information, the more suitable vehicles can be matched to the user's request. The vehicle DB 112 may include the current position (vehicle position information), travel speed, travel route (travel route), travel history, and the like as the dynamic information 112b. For general cars, other information, such as passenger information, may be included.

The transportation operation information DB 114 stores information about vehicles (mainly public transportation) that operate on a regular basis. buses, taxis, community buses, etc.), the number of owned vehicles, the belonging vehicle ID of each owned vehicle, and the like. The vehicle is not limited to an automobile, and may be a train. For example, it may be a vehicle such as a tram. Not all of this profile information is necessarily required. Further, the transportation operation information DB 114 may include, as the dynamic information 114b, timetables, traveling vehicle IDs, and operation statuses for each route. The information stored in the transportation operation information DB 114 is transmitted to the user terminal 10 at necessary timing by the vehicle operation information acquisition means 107 described above.

The above-described functional configuration of this system is merely an example, and one functional block (database and function execution unit) may be divided, or a plurality of functional blocks may be collectively configured as one functional block. In each functional processing unit, a CPU (Central Processing Unit) built in the device reads a computer program stored in a storage device such as ROM (Read Only Memory), flash memory, SSD (Solid State Drive), hard disk, etc. , implemented by a computer program executed by the CPU. That is, each functional processing unit reads and writes necessary data such as a table from a database (DB; Data Base) stored in a storage device or a storage area on a memory. It is realized by controlling hardware (for example, an input/output device, a display device, a communication interface device). In addition, the database (DB) in the embodiment of the present invention may be a commercial database, but it also means a mere collection of tables and files, and the internal structure of the database itself does not matter. The program here may be a server-side program (management program) or a terminal-side program (application).

(processing flow)
FIG. 5 is a diagram showing a processing flow executed by a server when matching a user and a vehicle. In the subsequent process flow charts (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 impaired. Also, the description of the reference numerals is omitted below.

Step S10: Standby until a boarding request is received from the user terminal.

Step S11: When the boarding request is received, the user information of the user DB is acquired from the user ID included in the boarding request. A boarding request can be accepted without a user ID. Time, desired arrival time, number of passengers) is entered, and if necessary information is not entered, the user is requested to input missing information. At this time, in order to minimize input, the default departure point is the user's current position, the default desired departure time and desired arrival time are "as soon as possible", and the default number of passengers is 1. etc.

Step S12: Search the vehicle DB for a vehicle that matches the boarding request. It should be noted that a request for a passenger may be received from a waiting vehicle waiting for a passenger.

Step S13: Judge whether a matching vehicle is found. Even if a vehicle does not completely match the conditions, if a nearby vehicle is found within a predetermined range, it may also be included in the search result.

Step S14: If no matching vehicle is found, a notification to that effect is sent to the user terminal, and then the process returns to step S10 to request correction of the boarding request. The user may modify the boarding request in some cases, and may give up boarding in other cases.

Step S15: If there is a matching vehicle, the selection of the vehicle that the user wants to board is accepted. After that, tracking of the position information of the selected vehicle is started. The server does not instruct the travel route of the vehicle, but if there is a traffic jam or an accident on the expected travel route, the information may be sent to the vehicle and the user. Also, if necessary, the desired boarding point is changed.

Step S16: Acquire 3D map data around the final boarding place (predetermined range). Here, the predetermined range varies depending on the driving area, but is usually several hundred meters to several kilometers square.

Step S17: Generate a 3D map to be displayed on the user terminal from the acquired 3D map data. At this time, a 3D map is generated by removing or seeing through images of buildings and the like.

Step S18: Transmit the generated 3D map to the terminal of the user and the vehicle. Since the 3D map is all vector data, it can be arbitrarily enlarged, reduced, rotated, transformed, clipped, etc. on the terminal side.

Step S19: If there is information on the point where the vehicle is traveling (driving point) or the vicinity of the boarding point, it is transmitted to the user terminal. The terminal side sequentially displays the received information on the 3D map.

(Screen example)
FIG. 6 is a diagram showing an example of an input screen for a user's boarding request. In order to match users with vehicles, the problem is how many requests the users can make and how easily they can be input. Various means are conceivable for this purpose, but here, an example of a vehicle request (selection format) screen shown in FIG. 6A will be introduced first. In order to make it as easy as possible for the user to input each item on this screen, the necessary information can be input simply by pressing the selection button for each item on the screen without entering characters. there is The order of the selection buttons is changed so that the more frequently used options by the user are placed higher. In addition, characters and buttons should be as large as possible and visually conspicuous for elderly and visually impaired users.

FIG. 6(b) is a screen for creating a boarding request not in a selection format but in an interactive format. On this screen, a boarding request can be created as if it were a conversation between LINE (registered trademark) friends. Here, characters may be entered by key input, or characters may be entered by voice.

If it is troublesome to answer the questions one by one as shown in the figure, it is possible to simply say, "I want to go to hospital B right now." In this case, by registering basic phrases frequently used by users in the user DB 111, various requests can be synthesized by combining the basic phrases. For example, if "Hospital" is registered as "Hospital B", a boarding request is automatically generated by simply saying "Hospital, now". By doing so, the user and the vehicle can interact with each other as if they were friends, and a boarding request can be generated as if they were talking in a "world between two people."

(Effect of Embodiment)
According to this system, it is possible to provide a method by which the user can easily check the information of the vehicle that the user wants to ride on a three-dimensional map with many buildings. Images of buildings and the like that block the view are removed or seen through and displayed on the 3D map, so the target vehicle, boarding point, etc. can be easily confirmed. In addition, it can be easily confirmed whether the desired vehicle is approaching or going away.

It is also possible to set a virtual meeting place (virtual stop) when getting on the vehicle at an arbitrary point on the 3D map. Also, the relationship between the user and the vehicle can be expressed visually. For example, the vehicles that match the user can be expressed by connecting them with line segments as if they were connected with a "red thread", or expressing them as if they were illuminated by a spotlight at night. can. In addition, the user and the vehicle can interact with each other as if they were friends, and a boarding request can be generated as if they were talking in a "world of two". By doing so, it is possible to make the vehicle service that runs in the area more familiar and close to the users.

In the above embodiment, a matching system between a user and a vehicle has been described, but the matching display method ("red thread") of this system can be used for other purposes, such as matching a user and a restaurant such as a restaurant. matching, person-to-person matching, and object-to-person matching other than cars.

Person-to-person matching is also effective for people you meet for the first time, and people you haven't met for a long time (grandchildren you haven't seen in 10 years, classmates you haven't seen in 20 years, etc.). may have changed). Also, matching between people and things other than cars is, for example, pizza delivery and customers. Also, when getting on a reserved train in an unfamiliar city such as overseas, first the station building and passengers, then after entering the station building, one train and passengers among the trains that stop at multiple platforms, and finally the inside of the train The seat and the passenger may be connected with a "red string", and the connection destination of the "red string" may be changed step by step according to the appearance of the object. Also, in the case of a bus, you can tie it to the bus stop first, and then tie it to the bus with a "red thread" when the bus you should board is approaching.

Although the present invention has been described using the embodiments, it goes without saying that the technical scope of the present invention is not limited to the scope described in the above embodiments. It is obvious to those skilled in the art that various modifications or improvements can be made to the above embodiments. Moreover, it is clear from the description of the scope of the claims that the forms with such modifications or improvements can also be included in the technical scope of the present invention.

In the above-described embodiments, the present invention is the invention of the product, and the management server in the user/vehicle matching system has been mainly described. It can also be regarded as the invention of a program (matching program) that causes a computer to execute each step.

10 User (or User Terminal)
20 vehicle (or in-vehicle terminal)
21 Bus stop 22 Taxi stand 23 Line image (red thread) showing that the user and the vehicle match
30 Network 100 Management Server 101 Location Information Acquisition Means 102 User Request Acquisition Means 103 Vehicle Information Acquisition Means 104 User/Vehicle Matching Means 105 3D Map Generation Means 106 Building Removal/Perspective Display Means 107 Vehicle Operation Information Acquisition Means 111 User database
112 vehicle database
113 3D map data DB
114 Transportation information DB
111a, 112a, 114a profile information 111b, 112b, 114b dynamic information

Claims (9)

A management server in a system that matches a user with a vehicle that the user wants to ride,
user/vehicle matching means for searching for a vehicle that matches the boarding request based on the user's boarding request and vehicle position information;
3D map generating means for generating a 3D map including location information of the user and the matched vehicle;
building removal/perspective display means for removing or transparently displaying stereoscopic images of buildings, etc. (buildings, houses, bridges, stations, and other structures) around the user and the vehicle matched from the 3D map; , and
The user/vehicle matching means generates a line image that always connects the image of the user and the image of the vehicle with a single line to represent the relationship between the user and the vehicle. A management server characterized by displaying on a map. The user/vehicle matching means provides an image of the user and the vehicle, etc., for representing a relationship of connection between the user and the vehicle and/or an object other than the vehicle related to the vehicle (hereinafter referred to as a vehicle, etc.). 2. The management server according to claim 1, wherein a line image that always connects the image of the . The building removal/perspective display means selects, on the 3D map, a traffic installation object that is an object related to road traffic such as a stop, a traffic light, a road sign, or a road construction installation object. 3. The management server according to claim 1, wherein information related to traffic installations is displayed. 4. Any one of claims 1 to 3, wherein said user/vehicle matching means predicts and displays a boarding point for boarding said matched vehicle and an arrival time of said vehicle at said boarding point. Management server described in section. 5. Management according to any one of claims 1 to 4, characterized in that said user/vehicle matching means displays that said matched vehicle is moving in response to said user's boarding request. server. 6. A 3D map according to any one of claims 1 to 5, characterized in that said building removal/perspective display means displays a 3D map from the viewpoint of said user or from the viewpoint of a driver of said matched vehicle. management server. 7. The user/vehicle matching means according to any one of claims 1 to 6, characterized in that, in the event of nighttime, the user or the matched vehicle is displayed as if illuminated by a spotlight. Management server. A display method in a system for matching a user with a vehicle that the user wants to ride, the step of searching for a vehicle that matches the boarding request based on the user's boarding request and vehicle location information;
generating a 3D map including location information for the user and the matched vehicle;
removing or perspectively displaying stereoscopic images of buildings, etc. (buildings, houses, bridges, stations, and other structures) in the vicinity of the vehicle matched with the user from the 3D map;
In the step of searching for the matching vehicle, a line image that always connects the image of the user and the image of the vehicle with a single line to show the relationship between the user and the vehicle is displayed on the 3D map. A display method, comprising the step of displaying on. A program that causes a computer to execute each step according to claim 8.

Images