JP7805040B2 - Mobile object summoning system, summoning device, program for summoning device, device for mobile object, and program for device for mobile object - Google Patents

Description

This invention relates to a mobile object summoning system, a summoning device, a program for the summoning device, a mobile object device, and a program for the mobile object device.

For example, when you want to use a taxi but there is no taxi stand nearby and no taxis are on the road, dispatch systems have recently emerged that can provide a service to call a taxi as quickly and reliably as possible. Previously, dispatch systems of this type have been proposed that consisted primarily of a dispatch management server, a customer terminal such as a high-function mobile phone terminal (smartphone), and an on-board device installed in a taxi, and some of these systems have already begun to operate (see, for example, Patent Document 1 and Non-Patent Documents 1 and 2).

For example, in the conventional vehicle dispatch systems of the services described in Non-Patent Documents 1 and 2, users must register in advance with the vehicle dispatch management server, and register their credit card details for payment of usage fees. The vehicle dispatch management server then collects current location information sent from the taxis under its control, and constantly manages the current location of each taxi.

When a registered user wants to call a taxi, they access the dispatch management server using a communications terminal such as a high-function mobile phone (smartphone) and request a taxi using a dedicated application. At this time, the dispatch request from the user's communications terminal includes the user's current location information.

When a vehicle dispatch request is received from a user, the vehicle dispatch management server searches for an available taxi (not currently in use by a customer) near the user's current location and determines which taxi to dispatch. The vehicle dispatch management server then notifies the taxi driver of the customer's current location, the customer's smartphone phone number, etc., and instructs them to head to the customer's location. The vehicle dispatch management server also notifies the customer of the characteristics of the taxi to be dispatched, such as the model of the taxi and the characteristics of the driver. When the taxi arrives near the customer's current location, the customer can confirm the taxi and board it.

With a taxi dispatch service using the above-mentioned dispatch system, users can quickly and reliably call a taxi simply by requesting a taxi from the dispatch management server using their smartphone.

JP 2014-29580 A

http://linecorp.com/ja/pr/news/ja/2014/901 http://linecorp.com/en/pr/news/en/2015/904

However, in the conventional vehicle dispatch system described above, the vehicle dispatch management server is configured to perform intermediary control between users and taxis to execute the vehicle dispatch service, which makes the system complex and may require an operator to operate the vehicle dispatch management server. As a result, there is a risk that the fee for the service provided by the vehicle dispatch management server will be higher than if you were to hail a taxi from a taxi stand or on the road.

Another problem with this type of system is that the vehicle dispatch management server generally covers a wide service area, and if there are no available taxis near the customer, it can take a long time to reach the customer's current location.

The object of this invention is to provide a mobile vehicle hailing system that allows users to hail mobile vehicles such as taxis without the need for a vehicle dispatch management server such as the one described above, and that always allows users to efficiently hail only mobile vehicles within a specified range from the user.

In order to solve the above problems, the present invention provides:
a calling device storing first wireless connection information for creating a direct communication path with a partner device;
a mobile unit that stores second wireless connection information for creating a direct communication path with the other device and is provided in the mobile unit to be called;
and
The mobile device is
a connection request means for transmitting a connection request signal including the second wireless connection information;
a first communication path generating means for generating the communication path between the calling device that has transmitted a response signal including the first wireless connection information that matches the second wireless connection information in response to the connection request signal;
Equipped with
The calling device is
a second communication path generating means for transmitting the response signal including the first wireless connection information to the mobile body device when a match between the second wireless connection information included in the received connection request signal and the first wireless connection information is detected, and generating the communication path between the mobile body device and the mobile body device ;
The moving body is a taxi,
the mobile device includes a determination means for detecting whether or not a customer is in the taxi, and for transmitting the connection request signal when the mobile device detects that the customer is not in the taxi and the taxi is vacant;
the taxi is equipped with an expressway driving detection means for detecting whether the taxi is driving on an expressway;
The determining means determines that the vehicle is not empty when the expressway driving detection means detects that the vehicle is driving on an expressway.
The present invention provides a mobile object summoning system.

In the mobile object calling system configured as described above, the mobile object device sends a connection request signal containing second wireless connection information to create a direct communication path with the other device in a so-called order-taking style. When the calling device detects a match between the second wireless connection information contained in the received connection request signal and the stored first wireless connection information, it sends a response signal containing the first wireless connection information to the mobile object device, creating a communication path between the mobile object device and the other device.

Therefore, according to this invention, a connection request signal is sent from the mobile device in a so-called order-taking style. The calling device then sends a response to the connection request signal to the mobile device, thereby creating a communication path between the mobile device and the calling device. This allows the user of the calling device to call a mobile device. Therefore, according to this invention, a vehicle dispatch management server or the like is not required.

This invention eliminates the need for a vehicle dispatch management server such as the one described above to summon a mobile vehicle, and allows users of the summoning device to summon a mobile vehicle efficiently.

This is a configuration diagram for explaining an example of a method for setting connection information for connecting a direct communication path with a mobile body to a smartphone as an example of a calling device that constitutes the mobile body calling system of this invention. 3 is a sequence diagram for explaining an example of the flow of communication between a mobile object and a calling device in the mobile object calling system according to the first embodiment of the present invention. FIG. 1 is a schematic diagram for explaining an example of a calling mode between a mobile object and a calling device in a mobile object calling system according to a first embodiment of the present invention; 1 is a block diagram showing an example of the hardware configuration of a smartphone as an example of a calling device in a mobile object calling system according to a first embodiment of the present invention. FIG. 1 is a block diagram showing an example of the hardware configuration of a dedicated device for taxis as an example of a first wireless communication device possessed by a mobile body in a first embodiment of the mobile body summoning system according to the present invention; 10 is a flowchart illustrating an example of a method for setting connection information to a smartphone as an example of a calling device in the first embodiment of the mobile object calling system according to the present invention. FIG. FIG. 10 is a flowchart illustrating an example of the processing operation when a calling service is started on a smartphone as an example of a calling device in the first embodiment of the mobile object calling system according to the present invention. A figure showing a flowchart for explaining an example of the processing operation when a call service is started in a dedicated device for taxis as an example of a first wireless communication device in the first embodiment of the mobile object call system of this invention. A block diagram showing an example of the hardware configuration of an electronic control circuit section of an autonomously driven vehicle as an example of a first wireless communication device possessed by a mobile body in a second embodiment of the mobile body summoning system according to the present invention. A figure showing a portion of a flowchart for explaining an example of the processing operation when a call service is started in the electronic control circuit section of an autonomous vehicle as an example of a first wireless communication device possessed by a mobile body in the second embodiment of the mobile body call system of this invention. A figure showing a portion of a flowchart for explaining an example of the processing operation when a call service is started in the electronic control circuit section of an autonomous vehicle as an example of a first wireless communication device possessed by a mobile body in the second embodiment of the mobile body call system of this invention. FIG. 10 is another diagram illustrating the third embodiment of the mobile object calling system according to the present invention. FIG. 10 is another diagram illustrating the third embodiment of the mobile object calling system according to the present invention.

[First embodiment]
A first embodiment of a mobile object hailing system according to the present invention will be described below with reference to the drawings. In the first embodiment of the mobile object hailing system described below, the mobile object is a taxi, and the hailing device is a mobile phone terminal carried by the user. The service provided to the user is hereinafter referred to as a taxi hailing service. In this example, the communication method of the specified communication standard is wireless LAN communication using Wi-Fi (registered trademark: Wireless Fidelity) of the IEEE 802.11 standard.

In the mobile object hailing system of this first embodiment, a taxi, as an example of a mobile object, is equipped with a first communication device, and this first communication device is provided with a wireless LAN adapter function that satisfies the above conditions. Furthermore, a mobile phone terminal, as an example of a user's hailing device, in this embodiment a high-function mobile phone terminal (hereinafter referred to as a smartphone), is also provided with a wireless LAN adapter function that satisfies the above conditions as a second communication device.

In this embodiment, the wireless LAN communication mode between the calling device and the mobile unit is ad hoc mode (hereinafter referred to as ad hoc communication), which communicates over a direct communication path without going through an access point. The communication range of ad hoc communication in this embodiment is, for example, 300 m. However, this communication range is just one example, and considering that this type of wireless LAN is evolving rapidly and wireless LAN access points that can cover a radius of 2.4 km are already on the market, it is expected that as technology advances, the communication range of ad hoc communication will be extended to 1 to 2 km.

In order to enable ad hoc communication between the wireless LAN adapter of the first communication device of the mobile object and the wireless LAN adapter of the second communication device of the calling device, the network identifiers set as wireless connection information (hereinafter referred to as connection information) in the wireless LAN adapters must be the same on both wireless LAN adapters. In IEEE 802.11 standard wireless LANs, network identifiers are called SSIDs (Service Set Identifiers) or ESSIDs (Extended Service Set Identifiers). In this embodiment, ESSIDs are used, but the present invention is not limited to this.

In addition, in wireless LAN systems, communication data is encrypted to ensure security, and this encryption key is also set in advance in addition to the ESSID network identifier. In IEEE 802.11-standard wireless LANs, the encryption protocol used is, for example, WEP (Wired Equivalent Privacy). This is a secret key encryption method (also known as a common key encryption method) that uses the same key (encryption key) for encryption and decryption. In the following explanation, the encryption key used in the WEP method is referred to as the WP key. Note that the encryption protocol is not limited to secret key encryption, and may also be public key encryption.

In addition, IEEE 802.11 standard wireless LANs also use the WPA (Wi-Fi® Protected Access) method, which is a method that strengthens the security of the WEP method, and the WPA2 (Wi-Fi® Protected Access 2) method, which is an even stronger version of WPA. The WPA and WPA2 methods use TKIP (Temporary Key Integrity Protocol) and CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) as encryption protocols. CCMP is a 128-bit block cipher called AES (Advanced Encryption Standard). This embodiment uses the WEP method as an example, but it goes without saying that the WPA, WPA2, or other methods may also be used.

In this embodiment, the connection information for ad hoc communication is an ESSID and a WEP key, and mutual authentication of the ESSID and WEP key set on both the mobile unit and the calling device enables secure ad hoc communication between the two.

In this embodiment, connection information for ad hoc communication is provided to the mobile object and the taxi hailing device by an intermediary, either for a fee or free of charge. If the taxi hailing service is provided by a taxi company, for example, the taxi company can also serve as the intermediary. Alternatively, private taxi operators or one or more taxi companies may jointly establish and operate an intermediary as a partnership or company. Furthermore, this intermediary can be a company that specializes in providing connection information for ad hoc communication to execute the taxi hailing service to taxis as mobile objects and to users.

In this embodiment, as shown in Figure 1, the intermediary manages and operates a taxi ad hoc communication setting server 1 (hereafter referred to as server 1 for simplicity) connected to a communication network 2 such as the Internet. Server 1 stores a specified ESSID and WKEY as connection information for ad hoc communication with taxis.

A user who wishes to use the taxi hailing service accesses the server 1 via the communication network 2 from a smartphone 3, which serves as an example of a taxi hailing device, and makes a request to use the taxi hailing service.

When server 1 receives a request from smartphone 3 to use the taxi hailing service, it confirms that smartphone 3 is equipped with IEEE 802.11 standard wireless LAN functionality by receiving from the user the name of the telecommunications carrier, manufacturer (manufacturing company) name, model name, or model number of smartphone 3, and then sends to smartphone 3 the application program for the taxi hailing service and connection information for ad hoc communication with a taxi (in this example, a specified ESSID and WKEY) as ad hoc communication information.

Smartphone 3 installs the application program received from server 1 and sets the connection information (in this example, a specific ESSID and WEP key) for ad hoc communication in its own wireless LAN function unit. In this embodiment, this connection information is set by the application program received and installed from server 1, but the user of smartphone 3 may also set the connection information received from server 1 in their own wireless LAN function unit.

In this embodiment, private taxi operators and one or more taxi companies are provided with the necessary number of dedicated taxi devices, each equipped with a wireless LAN adapter configured with a predetermined ESSID and WEP key for the ad hoc communication described above, and storing an application program for providing the taxi call service. The private taxi operators and taxi companies then install the dedicated taxi devices as first communication devices in the taxis that will provide the taxi call service.

Note that while the taxi-dedicated device is configured to have a specific ESSID and Wkey for ad hoc communication set in advance, it is also possible to access server 1 from the taxi-dedicated device after installation in the taxi, obtain the specific ESSID and Wkey for ad hoc communication from server 1, and set them.

The flow of the taxi call service, which is implemented by communication between the smartphone 3 that has received the necessary information from the taxi ad hoc communication setting server 1 as described above and a taxi equipped with a dedicated taxi device, will now be explained with reference to the sequence diagram in Figure 2 and the schematic diagram in Figure 3.

When a user of smartphone 3 wants to call a taxi, they call up the ad hoc communication application for the taxi calling service and instruct it to start the taxi calling service.

As shown in Figure 2, smartphone 3 then switches on ad-hoc communication and sends out an ad-hoc communication connection request, including the aforementioned specified ESSID and WKEY as connection information, to a specified communication range (in this example, a 300m radius) centered on the user carrying smartphone 3, as shown by dotted line 4 in Figure 3.

The taxi-dedicated device 6 of taxi 5A located within the area indicated by dotted line 4 in Figure 3 checks the connection information included in the connection request and confirms that the connection information matches the connection information of its own device. As shown in Figure 2, the taxi-dedicated device 6 returns response information to the smartphone 3 that includes the specified ESSID and WKEY as connection information.

The smartphone 3 checks the connection information included in the response information from the taxi-dedicated device 6 and confirms that it matches the connection information of its own device. Then, through the above mutual confirmation and authentication, a direct ad hoc communication path is created between the smartphone 3 and the taxi-dedicated device 6 of taxi 5A, enabling mutual ad hoc communication. In this case, if multiple taxi-dedicated devices 6 are present within the range indicated by dotted line 4, the smartphone 3 will create an ad hoc communication path with the taxi-dedicated device 6 from which it received response information earliest. Note that, as shown in Figure 3, the taxi-dedicated device 6 installed in taxi 5B, which is located outside the range indicated by dotted line 4, cannot form an ad hoc communication path with the smartphone 3 because the connection request from the smartphone 3 will not reach it.

Once the ad hoc communication path is created as described above, in this embodiment, smartphone 3 sends a taxi request to taxi dedicated device 6 of taxi 5A, which in this example includes current location information as location information for the location where the taxi will be waiting (waiting location). Taxi dedicated device 6 of taxi 5A displays the location of smartphone 3 on a map displayed on the display screen based on the received current location information (location information for the user's waiting location) along with the location of the vehicle. Therefore, in this embodiment, the driver of taxi 5A can confirm the location of the user requesting a taxi on the map on the display screen.

The taxi driver checks the user's (customer's) waiting location (in this example, the user's current location) displayed on this display screen, decides whether to respond to the taxi request, and if they decide to respond, presses the response confirmation button. The taxi-specific device 6 then generates a response message in response to the request from the other party (hereinafter referred to as a taxi request response message) and sends it to the other party's smartphone 3. The smartphone 3 displays the received taxi request response message on its display screen. The user can confirm the taxi's response from the message on the display screen.

In this embodiment, the taxi-dedicated device 6 is configured to allow the driver of taxi 5A to make a hands-free call with the user of smartphone 3 as needed. When the driver determines that a call is necessary, he or she operates the hands-free call button on the taxi-dedicated device 6. As shown in FIG. 2, the taxi-dedicated device 6 then sends a call request to the smartphone 3 via an ad hoc communication path. When the user of the smartphone 3 receives this call request and responds, a call is established between the taxi-dedicated device 6 and the smartphone 3 via the ad hoc communication path.

Of course, the system may also be configured so that a user can make a call request via the ad hoc communication path of the smartphone 3, allowing them to talk to the taxi driver via the ad hoc communication path between the taxi-dedicated device 6 and the smartphone 3.

The call itself may also use a mobile phone network rather than an ad hoc communication channel. In this case, either the mobile phone number of the mobile device such as a smartphone installed in taxi 5A or the mobile device such as a smartphone used by the taxi driver and/or the mobile phone number of smartphone 3 are sent and received over the ad hoc communication channel before the call.

When using a mobile phone network, it is possible to send and receive information not only through phone calls but also through email, LINE, and other communication applications. Calls do not need to be hands-free, but in that case, it would be better to detect that taxi 5A is moving and deter calls while moving by prohibiting calls or sounding an alarm, for example.

After that, when either the user of smartphone 3 or the driver of dedicated taxi device 6 (in the example of Figure 2, the user of smartphone 3) performs a disconnection operation, a request to disconnect the ad hoc communication path is sent to the other party, and the ad hoc communication path is disconnected after waiting for a response from the other party.

The driver of taxi 5A then receives a taxi call request from smartphone 3 via dedicated taxi device 6 and drives taxi 5A to the current location of the user of smartphone 3, which is displayed on the map on the display screen and is the taxi's waiting location. If the taxi driver does not know the route to the waiting location of the user of smartphone 3, he or she will use the car navigation function built into dedicated taxi device 6 to search for a route and follow the guidance provided to drive to the user of smartphone 3.

Next, we will explain example configurations of the smartphone 3 and dedicated taxi device 6 that realize the taxi hailing service described above, as well as their respective operations.

[Configuration example of smartphone 3]
4 is a block diagram showing an example of the hardware configuration of the smartphone 3. That is, the smartphone 3 is configured such that a mobile phone communication unit 302, a call circuit unit 303, a memory 304, a display unit 305, an operation input unit 306, a current location detection unit 307, a wireless LAN communication unit 308, and a transmission/reception processing unit 309 are each connected to a control unit 301 via a system bus 300.

The control unit 301 controls the entire smartphone 3 and is composed of a computer (microprocessor). The mobile phone communication unit 302 wirelessly connects to a mobile phone base station and communicates via the mobile phone network.

A speaker 311 serving as a receiver and a microphone 312 serving as a transmitter are connected to the call circuit unit 303.

Memory 304 stores various application programs for smartphone 3, as well as data for executing these application programs. In this embodiment, memory 304 stores, as ad hoc communication information, an application program for the taxi hailing service obtained from server 1 described above, and connection information for ad hoc communication with taxis (in this example, a specified ESSID and WKEY). Memory 304 also stores phone book data for the mobile phone terminal, URLs (Uniform Resource Locators) for accessing specified websites such as favorites via the Internet, and so on.

Display unit 305 is composed of, for example, an LCD (Liquid Crystal Display). A touch panel is provided superimposed on the LCD that constitutes display unit 305, constituting operation input unit 306. When the user operates an icon button or the like displayed on the display screen of display unit 305, operation input unit 306 transmits the operation information to control unit 301 via system bus 300. Control unit 301 detects which icon button displayed on the display screen has been operated, thereby detecting operation input by the user via operation input unit 306.

The current location detection unit 307 receives radio waves from GPS (Global Positioning System) satellites and information from mobile phone base stations to detect the current location of the smartphone 3 and transfers the detected current location data (latitude, longitude, and altitude data) to the control unit 301. As described below, the control unit 301 transmits the acquired current location data to a specified destination as location information for the waiting location of the mobile object to be called (a taxi in this example), as necessary.

In this example, the wireless LAN communication unit 308 is a communication unit for the wireless LAN function of the IEEE 802.11 standard. In this embodiment, the transmission/reception processing unit 309 has a processing function for transmitting and receiving data other than voice data transmitted and received by the mobile phone communication unit 302, and a processing function for transmitting and receiving data transmitted and received by the wireless LAN communication unit 308. The transmission/reception processing unit 309 performs the function of generating transmission data when transmitting, and the function of analyzing received data and transferring it to various units in accordance with the control of the control unit 301 when receiving.

[Example of hardware configuration of taxi-dedicated device 6]
5 is a block diagram showing an example of the hardware configuration of the taxi-dedicated device 6. That is, the taxi-dedicated device 6 is configured such that a control unit 601 is connected to a wireless LAN communication unit 602, a transmission/reception processing unit 603, a hands-free call processing unit 604, a car navigation (hereinafter abbreviated as "car navigation") function unit 605, a current position detection unit 606, a memory 607, a display unit 608, and an operation input unit 609 via a system bus 600.

The control unit 601 controls the entire taxi-specific device 6 and is composed of a computer (microprocessor).

In this example, the wireless LAN communication unit 602 is a communication unit for the wireless LAN function of the IEEE 802.11 standard. The transmission/reception processing unit 603 has processing functions for transmitting and receiving data sent and received by the wireless LAN communication unit 602, and performs the function of generating transmission data when sending, and the function of analyzing received data and transferring it to various units in accordance with the control of the control unit 601 when receiving.

The hands-free call processing unit 604 is a processing unit that, for safety reasons, allows the driver to make a call without picking up the transmitter or receiver when making a call via an ad hoc communication path created by the wireless LAN communication unit 602 with a destination such as a smartphone 3. It is connected to a speaker 611 that serves as a receiver, and a microphone 612 that serves as a transmitter.

The car navigation function unit 605 is equipped with a car navigation database in which national maps (or world maps) and route guidance data are pre-stored, and is a functional unit that provides guidance to assist the taxi 5 in traveling to a specified location, such as the current location of a customer who has requested a taxi call service, based on the maps and route guidance data stored in this car navigation database.

In other words, the car navigation function unit 605 displays an image on the display screen of the display unit 608 in which the vehicle's position detected and confirmed by the current position detection unit 606 is superimposed on a map that clearly shows the route to the destination. It also moves the vehicle's position (current position) on the map as the vehicle moves, and provides voice guidance at points where route guidance is necessary, such as intersections and branching points on the route. In this embodiment, the location of the waiting place for a customer who has requested a taxi call service as their destination is automatically obtained and set from the customer's smartphone 3 via communication with the smartphone 3 via an ad hoc communication path, as described below.

In addition, in this example, the car navigation function unit 605 has a function to calculate the distance to travel from the vehicle's current location to the waiting location of the customer who requested the taxi service, and the time required to travel (the customer's taxi wait time). The application program for the taxi service stored in the dedicated taxi device 6 in this example is configured to include the customer's taxi wait time calculated by the car navigation function unit 605 in a response message to a taxi request. Of course, it may also be configured to include the travel distance. Note that if a pick-up fee is to be charged, the application program is equipped with a function to calculate the pick-up fee, and is configured to include the pick-up fee in a response message to a taxi request.

The current position detection unit 606 receives information from radio waves from GPS satellites to detect the current position of the vehicle (taxi 5) and transfers the detected current position data (latitude, longitude, and altitude data) to the control unit 601. Based on the acquired current position data, the control unit 601 displays the vehicle position on a map displayed on the display screen of the display unit 608.

Memory 607 stores various application programs for the taxi-dedicated device 6, as well as data for executing these application programs. In this embodiment, memory 607 stores application programs for processing on the taxi side in the taxi call service, and connection information (in this example, a specified ESSID and WKEY) for ad hoc communication with a smartphone 3, which is an example of a call device.

The display unit 608 is composed of, for example, an LCD. A touch panel is provided superimposed on the LCD that constitutes the display unit 608, constituting the operation input unit 609. When the user (driver) operates an icon button or the like displayed on the display screen of the display unit 608, the operation input unit 609 transmits the operation information to the control unit 601 via the system bus 600. The control unit 601 detects which icon button displayed on the display screen has been operated, thereby detecting the operation input by the user via the operation input unit 609.

[Registration of smartphone 3 to server 1 for receiving services]
As described above, the smartphone 3, which is an example of a taxi calling device, accesses the server 1 and registers to receive the taxi calling service, thereby acquiring an application program and connection information for taxi ad hoc communication. Fig. 6 is a flowchart illustrating the flow of operations during the registration process for receiving the taxi calling service on the smartphone 3. The processing of each step in this flowchart is executed by the necessary units cooperating with each other under the control of the control unit 301.

First, the control unit 301 accesses the server 1 via the Internet using the mobile phone communication unit 302 or the wireless LAN communication unit 308, and connects to the server 1 (step S101). Next, the control unit 301 sends a request to use the taxi call service to the server 1 (step S102).

In response to this usage request, Server 1 requests personal information for personal authentication of the user making the usage request, such as name, age, date of birth, address, and contact phone number, as membership information. This request for membership information is intended to eliminate malicious service users, such as those who only call a taxi and do not use the service, as much as possible. It is not a required requirement for the service system of this embodiment, and may be omitted.

However, in this embodiment, as will be described later, when a taxi request is sent from smartphone 3 via an ad hoc communication channel, the taxi request includes personal information of the user registered on server 1, such as the user's name, age, and date of birth, in addition to the current location information of smartphone 3. This personal information is displayed on the display screen of dedicated taxi device 6 and can be used by the taxi driver as confirmation information when the user attempts to board taxi 5.

The smartphone 3 notifies the user of the request for membership information from the server 1 via the display screen, and sends the personal information entered by the user to the server 1 as membership information (step S103).

In this example, when the server 1 receives this membership information, it sends an application program for the user of the taxi call service to the smartphone 3 of the user who has requested to use the service. The smartphone 3 receives this application program from the server 1, stores it in memory 304, and installs it on the smartphone 3 (step S104). At this time, an icon for the taxi call service is also created and included in the application menu of the smartphone 3.

Next, server 1 sends connection information (ESSID and WEP key) for generating the ad hoc communication path required for the taxi call service. Control unit 301 receives this connection information and stores it in memory 304 in association with the taxi call service application program (step S105).

The control unit 301 then disconnects from the server 1 (step S106) and terminates this registration process.

In this way, a user can access the server 1 from their smartphone 3 and obtain the application program for the taxi hailing service and the connection information for creating an ad hoc communication path, thereby being able to hail and use a taxi 5 equipped with a dedicated taxi device 6.

[Example of processing flow for taxi hailing service]
The processing operations of the smartphone 3 and the taxi-dedicated device 6 when the taxi calling service described with reference to the sequence example of FIG. 2 is executed will be described below.

<Processing flow when using the taxi calling service on smartphone 3>
7 is a flowchart for explaining an example of a processing flow when a taxi hailing service is provided on the smartphone 3. The processing of this flowchart starts when a user clicks on an icon for the taxi hailing service in an application menu on the smartphone 3 to start the service.

The control unit 301 first reads connection information for ad hoc communication from the memory 304 and sends a connection request to the wireless LAN communication unit 308 to search for a partner with which to perform ad hoc communication (step S111).

As mentioned above, in response to this connection request, if a taxi 5 equipped with a taxi-specific device 6 with the same connection information set as the connection information included in the connection request is present within the communication range of the wireless LAN communication unit 308, connection response information will be sent from that taxi-specific device 6.

The control unit 301 then determines whether connection response information has been received (step S112). If it determines in step S112 that connection response information has not been received, the control unit 301 then determines whether the user has performed an operation to abandon the service (step S113). If it determines that the user has not performed an operation to abandon the service, the control unit 301 returns to step S111 and continues searching for the other party. If it determines that the user has performed an operation to abandon the service, the control unit 301 terminates the application program for the taxi hailing service.

Also, when it is determined in step S112 that connection response information has been received, the control unit 301 checks the connection information included in the received connection response information, confirms that it matches the connection information of its own terminal, and then creates an ad hoc communication path, which is a direct communication path, with the party that sent the connection response information (step S114).

Next, the control unit 301 sends a taxi request to the other party via the created ad hoc communication path, including the current location information of the terminal detected by the current location detection unit 307 as the location information of the waiting location, as well as the personal information registered on the server 1 (step S115). The control unit 301 then determines whether or not it has received a taxi call response message in response to the taxi call request from the other party (step S116).

If it is determined in step S116 that a taxi call response message has not been received, the control unit 301 determines whether the user has performed an operation to abandon the use of the service (step S117). If it is determined that the user has not performed an operation to abandon the use of the service, the control unit 301 returns to step S116 and monitors for the reception of a taxi call response message. If it is determined in step S117 that the user has performed an operation to abandon the use of the service, the control unit 301 terminates the application program for the taxi call service. In this case, the application program may not be terminated, and the process may be returned to step S111 to search for another ad hoc communication partner.

If it is determined in step S116 that a taxi call response message has been received, the control unit 301 displays the taxi call response message on the display screen of the display unit 305 (step S118). As mentioned above, the taxi call response message also includes information about the customer's waiting time, so this display allows the user of the smartphone 3 to know that a taxi is available to come to the current location (waiting place) in response to the taxi call request, and the approximate time until its arrival, without having to talk to the taxi driver. Of course, as mentioned above, the user can also find out the distance the taxi will travel to the current location, whether or not there is a pick-up fee, and if so, what the fee is.

Next, the control unit 301 determines whether a call request has been received from the other party (taxi driver) (step S119). If it determines in step S119 that a call request has been received, the control unit 301 processes the call with the other party (step S120). During this call, the user can obtain from the taxi driver information about the taxi's model and color, year, model (type), mileage, engine displacement, top speed, and other performance characteristics, including whether the taxi is large, medium, or small, the number of passengers it can accommodate, and the license plate display, as well as the driver's nationality, gender, age, whether they wear glasses, and years of experience as a taxi driver. The taxi driver can also obtain information useful for identifying the customer's waiting location, such as surrounding buildings, whether the customer is alone or in a group, and if so, the number and composition of the group, as well as information for visually identifying the customer, such as the customer's gender, body type, hair length, whether they wear glasses, clothing, and belongings. Furthermore, the user can obtain information about whether the customer is disabled and whether they use a wheelchair.

The taxi's characteristics and the taxi driver's characteristics may be included in the taxi request response message. In this case, the user can obtain the taxi's characteristics and the taxi driver's characteristics by receiving the taxi request response message, without having to ask the taxi driver about them in the call processing of step S120. The user may also include their own characteristics in the taxi request. In this case, the taxi driver can obtain the customer's (user's) characteristics by receiving the taxi request, without having to ask the customer about them in the call processing of step S120. The user can include their own characteristics in the taxi request by using the taxi request service application program on the smartphone 3 to input the user's characteristics using a selection icon, text input, voice input, etc.

If the user determines that a taxi ride is unsuitable due to the characteristics of the taxi or the taxi driver, the user can notify the caller that they will not be using the taxi. Alternatively, the user can send a second response message instead of using the call process. The second response message can be configured to allow messages such as "Use," "Do not use," or "X number of passengers" to be entered using a selection icon, text input, or voice input using the taxi call service application program on the smartphone 3. Naturally, the user's characteristics may also be sent in the second response message.

Of course, users can include requests for the taxi they want to call in their taxi request. Requests are not limited to the taxi or driver characteristics described above. For example, users can include whether the taxi is a corporate or privately owned taxi, the name of a preferred corporate taxi company (if they have one), the method of payment for the taxi fare (cash, credit card, electronic money, etc.), and whether to use a taxi ticket. This allows users to request various characteristics, such as their favorite taxi company, a taxi with their preferred model and color, or a veteran privately owned taxi driver with over 20 years of experience. They can then selectively search for a taxi to call based on their request, and can also choose their payment method.

After the call processing of step S120, the control unit 301 determines whether to disconnect the ad hoc communication path based on whether it has detected a disconnection operation input by the user or whether it has received a disconnection request from the other party (step S121). If it determines not to disconnect, the process returns to step S120 and the call continues. If it determines in step S121 that it should be disconnected, the control unit 301 disconnects the ad hoc communication path (step S123) and ends this processing routine.

If users form a group with a large number of members (e.g., seven people) and one taxi is not enough, the process of disconnecting the ad hoc communication path with the taxi is completed, and then the process is repeated from step S111. In other words, a connection request is sent via the wireless LAN communication unit 308 to search for other taxis with which to perform ad hoc communication.

Also, if it is determined in step S119 that a call request has not been received, the control unit 301 determines whether to disconnect the ad hoc communication path based on whether it has detected a disconnection operation input by the user or whether it has received a disconnection request from the other party (step S122).If it determines not to disconnect, the process returns to step S119 and determines whether a call request has been received.If it is determined in step S122 that a disconnection should be made, the control unit 301 disconnects the ad hoc communication path (step S123) and ends this processing routine.

<Example of processing flow during taxi calling service in taxi-dedicated device 6>
8 is a flowchart for explaining an example of the processing flow during a taxi call service in the taxi dedicated device 6. The processing of this flowchart is always executed when the taxi dedicated device 6 is powered on.

The control unit 601 constantly monitors for the reception of a connection request from a smartphone 3, an example of a calling device, that includes connection information that matches the connection information stored in the device itself (step S131). When it determines that the connection request has been received, it sends connection response information that includes the connection information stored in the device itself to the device that made the connection request (step S132). Then, it creates a direct ad hoc communication path between the device and the other device (smartphone 3) (step S133).

Next, the control unit 601 receives a taxi request from the other device sent through the created ad hoc communication path, extracts the location information of the other party's (customer's) waiting location (in this example, the location information of the user's current location) and personal information contained in the taxi request, and displays the location of the other party's waiting location on a map displayed on the display screen of the display unit 608, as well as the received personal information of the other party, such as name and age, on the display screen (step S134).

The taxi driver checks the location of the other party's (actually the other party's device) waiting location displayed on the display screen of this display unit 608 and decides whether to respond to the taxi call request. If they decide to respond, they operate the response confirmation button (by tapping, etc.); if they decide not to respond, they do not perform any operation, or they operate to disconnect the created ad hoc communication path.

The control unit 601 then determines whether the taxi driver has operated the response confirmation button (step S135). If it determines that the confirmation button has not been operated, it determines whether to disconnect the ad hoc communication path based on whether it has detected a disconnect operation input by the taxi driver or whether it has received a disconnect request from the other party (step S136). If it determines that the communication path should not be disconnected, it returns to step S135 and determines whether the confirmation button has been operated. If it determines in step S136 that the communication path should be disconnected, the control unit 601 disconnects the ad hoc communication path (step S142), returns to step S131, and repeats the processing from step S131 onwards.

If it is determined in step S135 that the taxi driver has pressed the response confirmation button, the control unit 601 generates a taxi call response message and transmits it to the other party via the ad hoc communication path (step S137). At this time, the taxi call response message includes the time required to travel from the current location of taxi 5 to the current location of the other party (customer), as calculated by the car navigation function unit 605, as described above.

Next, the control unit 601 determines whether the call button has been operated by the taxi driver (step S138). If it determines in step S138 that the call button has not been operated, it determines whether to disconnect the ad hoc communication path based on whether it has detected a disconnect operation input by the taxi driver or whether it has received a disconnect request from the other party (step S139). If it determines not to disconnect, it returns to step S138 and determines whether the call button has been operated. If it determines in step S139 that it should be disconnected, the control unit 601 disconnects the ad hoc communication path (step S142), returns to step S131, and repeats the processes from step S131 onwards.

Then, in step S138, if it is determined that the taxi driver has operated the call button, the control unit 601 sends a call request to the other party (customer) via the ad hoc communication path and conducts a hands-free call with the customer (step S140).

In addition, using hands-free calling, the taxi driver can determine whether or not a taxi is available based on the number of users (customers), user characteristics such as whether or not they use a wheelchair, and the waiting location, and notify the user whether or not the taxi is available. If this information is included in the taxi call response message, the driver can respond by pressing the confirmation button in step S135. If this information is included in the second response message, a determination such as OK/NG may be made in response to the second response message, although this is not shown. If the number of users (customers) is large (e.g., seven people), the taxi device 6 can return a second response message stating, for example, "Available for up to four people." Of course, various second response messages can be sent by the taxi device 6, and the taxi driver can select or directly input them from the screen of the taxi device 6, etc. Of course, the taxi driver can also select or directly input the taxi call response message from the screen of the taxi device 6, etc.

After step S140, the control unit 601 determines whether to disconnect the ad hoc communication path based on whether it has detected a disconnection operation input by the taxi driver or whether it has received a disconnection request from the other party (step S141). If it determines not to disconnect, the process returns to step S140 and the hands-free call with the customer continues. If it determines in step S141 that it should be disconnected, the control unit 601 disconnects the ad hoc communication path (step S142), returns to step S131, and repeats the processes from step S131 onwards. Of course, if the ad hoc communication path is disconnected and the taxi 5 is heading to the customer's waiting location, there is no need to receive the connection request of step S131, so the power to the taxi-dedicated device 6 may be turned off, or the power may remain on and the wireless LAN communication function of the wireless LAN communication unit 602 may be turned off.

When taxi 5 heads to the customer's waiting location, the ad hoc communication path is not disconnected but remains connected until the customer boards, allowing the taxi driver and customer to communicate. This allows the user (customer) to notify taxi 5 of the cancellation if the situation suddenly changes after hailing taxi 5 and they are forced to cancel the taxi 5. Also, if taxi 5 encounters an unforeseen incident such as traffic congestion or an accident, it is expected that the arrival time already communicated to the customer will be significantly delayed, so the taxi driver or dedicated taxi device 6 can notify the user (customer) of this. In this case, of course, the power to dedicated taxi device 6 is on, and the wireless LAN communication function of wireless LAN communication unit 602 is also on. As mentioned above, if the arrival time is significantly delayed, the user may be asked whether or not to cancel the trip.

Even if the ad hoc communication path is disconnected, the taxi-dedicated device 6 can store connection information such as the ESSID and WKEY of the smartphone 3, which is the user's calling device, before the disconnection process, and the user's smartphone 3 can store connection information such as the ESSID and WKEY of the taxi-dedicated device 6, so that the ad hoc communication path can be connected between the two even after the ad hoc communication path is disconnected. This makes it possible to deal with the above-mentioned issues such as cancellations, traffic jams, and accidents even if the ad hoc communication path is disconnected, thereby preventing problems between the taxi 5 and the user. This also makes it possible to reconnect and deal with the situation even if the ad hoc communication path is disconnected midway due to radio interference, etc.

Although not shown in the flowchart of Figure 8, when a customer gets into taxi 5, the taxi driver turns off the power or wireless LAN communication function of the taxi-dedicated device 6 so that the above-mentioned processing operations are not performed. This is because the taxi call service should not be available when a customer is in the taxi. Furthermore, although not shown in the figure, a camera that takes pictures of the interior of the vehicle, or a weight sensor or pressure sensor attached to the seat can detect the customer's entry and automatically turn off the power or wireless LAN communication function of the taxi-dedicated device 6 without the taxi driver having to perform any operation.

Furthermore, even if there is no customer in the taxi 5, the power supply or wireless LAN communication function of the taxi-dedicated device 6 may be turned off while the taxi is traveling on a highway, so that the above-mentioned processing operations are not performed. This is because customer boarding on highways is prohibited except at SAs (Service Areas) and PAs (Parking Areas), and if the customer is on a public road, even if the direct distance is short, it takes time to exit the highway and enter a public road, making it difficult to respond to taxi call services while traveling on a highway. Note that the car navigation function unit 605 can automatically detect whether the taxi 5 is traveling on a highway.

The taxi-dedicated device 6 can also be configured to be linked to the taxi meter that taxis are required to install. Taxi meters vary depending on the taxi company or meter provider, but buttons can be operated to select options such as "empty," "actual vehicle (or hire)," "outbound," "pick-up," "reservation," and "expressway." The taxi-call service is only available when the taxi is "empty." When the "actual vehicle (or hire)," "outbound," "pick-up," "reservation," or "expressway" button is pressed, the taxi-dedicated device 6 recognizes this and can stop the taxi-call service, turning off the power or wireless LAN communication function. The taxi-dedicated device 6 may also be configured to recognize that the "empty" button has been pressed and start the taxi-call service.

In this way, by making a connection request using the wireless LAN connection information obtained from the taxi ad hoc communication setting server 1, the user of the smartphone 3 can create an ad hoc communication path with the taxi-dedicated device 6 of a taxi located within the wireless LAN communication range and call that taxi. Therefore, when a user wants to use a taxi, they can quickly call one even if there are no taxis nearby.

Furthermore, according to the above-described embodiment, the taxi hailing system is configured to generate a direct ad hoc communication path between a hailing device such as a smartphone 3 carried by a user and a mobile unit such as a dedicated taxi device 6 mounted on a taxi 5, without going through a server. This has the advantage of making it easy to build the system and reducing the cost of implementing the service.

In addition, since the taxi being called is always located within the wireless LAN communication range centered on the user's current location when the taxi request is made, the distance traveled to the current location (waiting location) of the taxi calling device in response to a call is at most the maximum travel distance within the wireless LAN communication range, which has the added benefit of preventing excessively long waiting times.

In addition, in the above-described embodiment, the display screen of the dedicated taxi device 6 displays personal information such as the name and age of the customer who requested a taxi, which has the effect of allowing the taxi driver to confirm (authenticate) the customer based on that personal information.

In the above explanation, the user is required to register personal information with server 1 when obtaining connection information for wireless LAN ad hoc communication. However, as mentioned above, in the mobile object hailing system of this embodiment, the mobile object hailing service does not require the intervention of a server, so member registration with server 1 is not required. Furthermore, because the server is not involved when the mobile object hailing service is performed, the contractual relationship between the taxi and the user is a direct contractual relationship between each individual taxi and the user, just as in the past, and fare payments can also be made in exactly the same way as in the past.

Second Embodiment
The moving body in the first embodiment described above was a taxi driven by a taxi driver. However, recently, attention has been focused on self-driving cars that do not require a driver to operate the vehicle and can even be driven unmanned, and it is expected that taxis can also be made into this type of self-driving car.

The second embodiment is a case in which the taxi vehicle is configured as an autonomous vehicle. In this second embodiment, the functions of the taxi-dedicated device in the first embodiment described above are installed as part of the electronic control circuit unit of the autonomous vehicle. In other words, in the second embodiment, the first wireless communication device of the mobile body is configured as part of the electronic control circuit unit of the autonomous vehicle.

In the first embodiment, a taxi driver was present, so the taxi driver was able to confirm the identity of the user who requested a taxi. In this second embodiment, a driver may also be on board the self-driving vehicle, but the following explanation assumes unmanned driving. For this reason, in the second embodiment, the electronic control circuit unit of the self-driving vehicle is configured to be able to authenticate the customer.

As in the first embodiment, the user's calling device can be a smartphone 3. The configuration of this smartphone 3, the application program downloaded from the server 1, and the connection information are the same as in the first embodiment. Therefore, in the following explanation, an example configuration and processing operation of the smartphone 3 will not be described.

[Example of hardware configuration of electronic control circuitry in an autonomous vehicle]
Fig. 9 is a block diagram showing an example of the hardware configuration of an electronic control circuit unit mounted on a taxi vehicle that is an autonomous driving vehicle according to the second embodiment. Note that the autonomous driving vehicle of this embodiment is an example of an electric vehicle. However, the battery is not shown in Fig. 9.

The self-driving vehicle of this embodiment is configured to be controlled to travel in autonomous driving mode, a driving mode in which the self-driving vehicle automatically changes course while avoiding obstacles, without the driver having to operate the accelerator, brakes, or steering.

As shown in FIG. 9, the electronic control circuit unit 10 has a control unit 201, which is configured by mounting a computer, and is connected via a system bus 200 to a wireless LAN communication unit 202, radar 203, a group of various sensors 204, a group of cameras 205, a GPS (Global Positioning System) receiving unit 206, a current location confirmation unit 207, a surrounding moving object recognition unit 208, a voice input/output unit 209, a motor drive control unit 210, a steering drive control unit 211, a touch panel display unit 212, a car navigation function unit 213, a message generation unit 214, a transmission/reception processing unit 215, and a customer authentication unit 216.

The audio input/output unit 209 is connected to a speaker 221 and a microphone 222. The motor drive control unit 210 is connected to a motor drive unit 223. The steering drive control unit 211 is connected to a steering drive unit 224.

In this example, the wireless LAN communication unit 202 is a communication unit for the wireless LAN function of the IEEE 802.11 standard. The transmission/reception processing unit 215 has processing functions for transmitting and receiving data sent and received by the wireless LAN communication unit 202, and performs the function of generating transmission data when sending, and the function of analyzing received data and transferring it to various units in accordance with the control of the control unit 201 when receiving. This wireless LAN communication unit 202 has previously stored therein connection information that is the same as the connection information for ad hoc communication of the wireless LAN communication unit of the smartphone 3, an example of a device for calling a user from the server 1 described in the first embodiment above.

Radar 203 is used to measure the distance to vehicles, pedestrians, obstacles, etc. around the autonomous vehicle, and consists of laser radar, millimeter-wave radar, etc. Laser radar is embedded, for example, in the ceiling or near the bumper, while millimeter-wave radar is installed, for example, at the front and rear of the vehicle. Both laser radar and millimeter-wave radar may be provided, or only one may be provided. Other radars, such as quasi-millimeter-wave radar or microwave radar, may also be used. Furthermore, sonar (not shown) may be used for the same purposes as radar.

The group of various sensors 204 includes open/close detection sensors that detect whether doors and windows are open or closed, sensors that detect whether seat belts are fastened, and seating sensors that detect whether a passenger is seated in a seat such as the driver's seat or passenger seat, as well as various other sensors for acquiring information that assists autonomous driving. Examples of the various sensors for acquiring information that assists autonomous driving include vibration sensors that detect vibrations of the vehicle and tires, rotation speed sensors that detect tire rotation speeds, geomagnetic sensors that detect direction, acceleration sensors that detect acceleration, and gyro sensors (gyroscopes) that detect angles and angular velocities. The group of various sensors 204 also includes a sound sensor (microphone) that picks up the voices of passengers inside the vehicle and sounds around the autonomous vehicle.

The camera group 205 includes one or more cameras that capture images of the interior of the autonomous vehicle, and multiple cameras that capture images of the area around the autonomous vehicle. The cameras that capture images of the interior of the vehicle include cameras that capture facial images of passengers (customers) sitting in the driver's seat, passenger seat, and rear seats. The cameras that capture images of the area around the autonomous vehicle include, for example, two cameras (stereo cameras) attached to the left and right sides of the rearview mirror that primarily capture images of the area in front of the autonomous vehicle; cameras attached to, for example, door mirrors or fender mirrors of the autonomous vehicle that capture images of the left and right sides; cameras that capture images behind the autonomous vehicle; and omnidirectional cameras (360-degree cameras) and fisheye cameras that are attached to the roof and capture images of the area around the vehicle at a wide angle.

The GPS receiver unit 206 receives radio waves from GPS satellites to detect the current position of the vehicle and provides information on the detected current position to the current location confirmation unit 207.

Since the accuracy of the position detected by radio waves from GPS satellites is poor, the current location confirmation unit 207 uses not only the current location information detected by the GPS receiving unit 206, but also images captured by one or more sensors included in the various sensor group 204, radar 203, and the camera group 205, and performs processing based on Bayes' theorem, for example, to detect and confirm the current location with higher accuracy.

The surrounding moving object recognition unit 208 uses images captured by the radar 203 and the camera group 205 to recognize moving objects around the vehicle. The surrounding moving object recognition unit 208 also recognizes surrounding obstacles and moving objects by performing processing based on Bayes' theorem, for example.

In an autonomous vehicle, the current location confirmation unit 207 and surrounding moving object recognition unit 208 process various information acquired by the radar 203, various sensors 204, cameras 205, and GPS receiver 206, i.e., information corresponding to information obtained by the human eyes and ears, using Bayes' theory and other methods. Based on this, the control unit 201 performs intelligent information processing (artificial intelligence) and control (artificial intelligence), such as changing the vehicle's course and avoiding obstacles.

Although not shown, the audio input/output unit 209 incorporates a memory that stores audio message data to be played externally (to customers), as well as a D-A converter that converts audio message data read from the memory into an analog audio signal and outputs it to the speaker 221. The audio input/output unit 209 then supplies the audio message selected under the control of the control unit 201 to the speaker 221, which then plays the selected audio externally.

The audio input/output unit 209 also has a built-in A/D converter that converts the analog signal of the audio (customer's audio) picked up by the microphone 222 into a digital signal, and the acquired digital audio signal is supplied to, for example, the customer authentication unit 216, as described below, for use in authenticating the customer.

Under the control of the control unit 201, the motor drive control unit 210 controls the supply of drive signals to the motor drive unit 223 of the autonomous vehicle, which is an electric vehicle of this embodiment, to control the start of driving, driving speed control, driving stop, etc. of the autonomous vehicle.

Under the control of the control unit 201, the steering drive control unit 211 controls the supply of drive control signals to the steering drive unit 224 of the autonomous vehicle in this embodiment, thereby controlling the path changes of the autonomous vehicle.

The touch-panel display unit 212 is configured by superimposing a touch panel, which allows touch input with a finger, on a display panel made of, for example, an LCD. Under the control of the control unit 201, a display image including software buttons (including keyboard character input buttons) is displayed on the LCD display screen. When the touch panel of the touch-panel display unit 212 detects a finger touch on a software button displayed on the display screen, it transmits the touch to the control unit 201. In response to this, the control unit 201 is configured to execute a control process corresponding to the software button.

The car navigation function unit 213 is equipped with a car navigation database in which national maps (or world maps) and route guidance data are pre-stored, and is a functional unit that provides guidance to assist the autonomous vehicle in traveling to a specified destination based on the maps and route guidance data stored in this car navigation database.

In autonomous driving mode, when the vehicle's current position is away from the route to the destination, the car navigation function unit 213 notifies the control unit 201 of information on the direction and distance of the departure. Furthermore, when the vehicle's current position is on the route to the destination, the car navigation function unit 213 notifies the control unit 201 of information instructing the vehicle to change its course along the route before intersections, branching points, etc., along the route as the vehicle moves. Based on the information notified from the car navigation function unit 213, the confirmation results of the current location confirmation unit 207, and the recognition results of the surrounding moving object recognition unit 208, the control unit 201 controls the motor drive unit 223 via the motor drive control unit 210 and the steering drive unit 224 via the steering drive control unit 211 so that the vehicle moves along the route as instructed. Therefore, thanks to route guidance to the destination provided by the car navigation function unit 213 and the control unit 201 in autonomous driving mode, the autonomous vehicle can travel to the destination even when there are no passengers.

The message generation unit 214 is a processing unit that generates messages when requesting or responding to information through an ad hoc communication path created with a smartphone 3, which is an example of a calling device.

The customer authentication unit 216 is a processing unit that performs customer authentication when a user who has requested a taxi call service boards a taxi, which is an autonomously driven vehicle. In this example, customer authentication is performed using authentication information exchanged over an ad hoc communication channel generated between the electronic control circuit unit 10 of the autonomously driven vehicle and the user's smartphone 3 in the request and response for the taxi call service.

For example, the authentication information can be a password transmitted from the user's smartphone 3 to the electronic control circuit unit 10 of the autonomous vehicle via the ad hoc communication channel. In this case, the customer authentication unit 216 of the electronic control circuit unit 10 of the autonomous vehicle stores the transmitted password. When the user gets into the autonomous vehicle, the user enters the password via the touch panel display unit 212. The customer authentication unit 216 compares the stored password with the password entered via the touch panel display unit 212, and if the two match, determines that customer authentication is successful. In this case, the password may be the user's name, nickname, date of birth, telephone number, email address, PIN, etc. It may also be a barcode or QR code (registered trademark) generated by an application on the smartphone 3. The password may be deleted or retained when use is terminated. The user may also be able to choose whether to delete or retain the password.

Facial images of the user (customer) can also be used as authentication information. In this case, the customer authentication unit 216 is configured as an image recognition unit and stores and retains facial images of the user (customer) sent from the smartphone 3. When the user gets into the self-driving vehicle, one of the cameras in the camera group 205 captures an image of the user's face. The customer authentication unit 216 then compares the stored facial image with the facial image captured by the camera, and authenticates the customer by confirming that both facial images are of the same person.

The user's (customer's) voice can also be used as authentication information. In this case, the customer authentication unit 216 is configured as a voice recognition unit and stores the user's (customer's) voice data sent from the smartphone 3. When the user gets into the self-driving vehicle, the microphone 222 picks up the user's voice, and the customer authentication unit 216 compares the picked-up voice with the stored voice to confirm that it is the same person's voice, thereby authenticating the customer.

In addition to facial images and voice, biometric information such as the user's (customer's) fingerprint, hand vein pattern, and iris can also be used, or a combination of these can be used.

As mentioned above, the authentication information may be issued by the user or by the taxi 5. It may also be issued by both parties for double-checking, providing even stronger protection against imposters boarding the taxi.

The electronic control circuit unit 10 of an autonomous vehicle is configured as described above, but of the blocks shown in Figure 9, the processing functions of the current location confirmation unit 207, surrounding moving object recognition unit 208, voice input/output unit 209, motor drive control unit 210, steering drive control unit 211, car navigation function unit 213, message generation unit 214, transmission/reception processing unit 215, and customer authentication unit 216 can be realized as software processing by the control unit 201.

[Example of processing flow for taxi hailing service in self-driving cars]
FIG. 10 is a flowchart for explaining an example of the processing flow during a taxi call service in the electronic control circuit unit 10 of a taxi that is an autonomous driving vehicle according to the second embodiment.

The control unit 201 constantly monitors for the reception of a connection request from a smartphone 3, an example of a calling device, that includes connection information that matches the connection information stored in the vehicle's electronic control circuit unit 10 (step S201). When it determines that the connection request has been received, it sends connection response information that includes the connection information stored in the vehicle's electronic control circuit unit 10 to the party that made the connection request (step S202). Then, a direct ad hoc communication path is created between the party (smartphone 3) and the smartphone 3 (step S203).

Next, the control unit 201 receives a taxi request from the other party sent through the created ad hoc communication channel, extracts the location information of the other party's waiting location (in this example, location information of the current location) and customer authentication information (information such as personal information, facial image, and password) included in the taxi request, and stores and retains the location information of the customer's waiting location, as well as the received customer authentication information (for example, personal information such as name and age, facial image, password, etc.) (step S204). It is also possible to have the customer send an image of the area around the customer's waiting location, which can be used for image recognition to confirm the waiting location.

The control unit 201 then instructs the car navigation function unit 213 to calculate the time required to travel from the vehicle's current location confirmed by the current location confirmation unit 207 to the received customer waiting location, i.e., the customer's waiting time (step S205). The control unit 201 then generates a taxi call response message including the customer's waiting time calculated in step S205, and transmits it to the other party via the ad hoc communication path (step S206).

In addition to the customer's waiting time, step S205 can also calculate the travel distance from the vehicle's current location to the received customer's waiting location and, if necessary, the pick-up fee. Furthermore, in step S206, a taxi call response message can be generated that includes the travel distance and pick-up fee, and can be sent to the other party via an ad hoc communication channel.

Next, the control unit 201 determines whether a disconnection request has been received from the other party (step S207), and if it determines that a disconnection request has not been received, it waits for a disconnection request from the other party. If it determines in step S207 that a disconnection request has been received from the other party, the control unit 201 performs processing to disconnect the ad hoc communication path (step S208). Then, the control unit 201 turns off the communication function of the wireless LAN communication unit 202 (step S209).

The control unit 201 then controls each unit of the electronic control circuit unit 10 to start moving toward the customer's waiting location (step S211 in Figure 11). Although not shown in the flowchart, prior to this movement, the control unit 201 instructs the car navigation function unit 213 to search for a route from the vehicle's current location to the customer's waiting location. In response to this instruction, the car navigation function unit 213 searches for the route and, in step S211, begins route guidance.

The control unit 201 then determines whether the vehicle has arrived at the customer's waiting location (step S212), and if it determines that the vehicle has arrived at the customer's waiting location, it stops the vehicle to allow the customer to board and performs authentication processing for the customer who is about to board (step S213).

In other words, as mentioned above, if the authentication information sent when requesting a taxi and stored is a password, the customer is prompted to enter the password using the touch panel display unit 212, and the entered password is compared with the stored password, and authentication is performed based on whether or not a match is confirmed.

Furthermore, if the authentication information sent when requesting a taxi and stored is a customer's facial image, one of the cameras in the camera group 205 captures a photograph of the customer's face, and the captured facial image is compared with the stored facial image to authenticate the customer.

Furthermore, if the authentication information sent when requesting a taxi and stored is the customer's voice, a message encouraging the customer to speak is emitted from speaker 221, and the customer's voice responding to the message is picked up by microphone 222. The picked-up customer voice is then compared with the stored customer voice to authenticate the customer.

In addition, personal information used for customer authentication, such as the customer's name, phone number, facial image, and customer voice, may be deleted when use ends, or may be retained. Users may also be able to choose whether to delete or retain this information.

Next, the control unit 201 determines whether the authentication process in step S213 is successful (step S214). If the authentication is successful, the control unit 201 accepts the customer and accepts the customer's input of the destination (step S215). In this case, the customer can input the destination by touching the map displayed on the touch-panel display unit 212, for example, or can vocally indicate the destination. The destination specified by voice is recognized by a voice recognition unit (not shown) installed in the electronic control circuit unit 10. After specifying the destination by voice, the customer can also specify a driving mode such as "fast," "hurry," or "slow." The driving mode specified by voice is recognized by a voice recognition unit (not shown) installed in the electronic control circuit unit 10, just like the destination, and the voice recognition result is sent to the motor drive control unit 210, etc. Of course, the driving mode described above can also be specified by touch or button instructions.

The control unit 201 instructs the car navigation function unit 213 to search for and provide guidance on a route to the accepted destination, and controls each unit of the electronic control circuit unit 10 to move the vehicle to the destination specified by the customer and stop there (step S216). Then, although not shown in the flowchart of Figure 11, the control unit 201 accepts the customer's payment of the taxi fare, confirms that payment has been completed, and then checks and determines whether the customer has exited the vehicle (step S217).

Here, customers can pay their taxi fare by inserting cash into the cash dispenser, which will return any change. It can also be configured to allow payment by credit card, prepaid card, or electronic money. It can also be configured to allow the use of taxi tickets. It can also be configured to allow customers to pay a tip for the taxi service in addition to the taxi fare.

When it is confirmed in step S217 that the customer has exited the vehicle, the control unit 201 turns on the wireless LAN communication unit 202, which had been turned off (step S218), and controls the electronic control circuit unit 10 to move the vehicle as a taxi (step S219). After step S219, the control unit 201 then returns the process to step S201 and repeats the processes from step S201 onwards.

Also, if authentication is not successful in step S214, the control unit 201 outputs a message from the speaker 221 to the person attempting to board the taxi, saying, "Your authentication has not been obtained, so you cannot use this taxi," and denies boarding (step S220). The control unit 201 then proceeds to step S218 and executes the processes from step S218 onwards.

In this way, in this second embodiment, a taxi, as an example of a moving object, can be converted into an autonomous vehicle. It goes without saying that this second embodiment also achieves exactly the same effects as the first embodiment described above.

The moving body in the second embodiment is not limited to an autonomously driven vehicle, but may also be a ship such as an autonomously navigating motorboat or submarine, an air vehicle such as an autonomously flying aircraft or quadcopter, or other moving body. Furthermore, the moving body in the first embodiment is not limited to an automobile, but may also be a two-wheeled motor vehicle, a three-wheeled motor vehicle, a ship, an air vehicle, or other moving body. If a taxi service is provided by a ship, it becomes a water taxi or underwater taxi, and if a taxi service is provided by an air vehicle, it becomes an air taxi or air taxi.

Note that the self-driving vehicle of the second embodiment is not limited to an electric vehicle, and may of course be a gasoline engine vehicle, a fuel cell vehicle, a hybrid vehicle, or the like. Furthermore, solar power generation can be used as supplemental energy by installing solar panels on the roof, etc. These vehicles, drive systems, and energy types can also be applied to the mobile body of the first embodiment in the same way.

In addition, the user may be able to select between a manually driven taxi in the first embodiment and an autonomously driven taxi in the second embodiment and issue a taxi call request.

In addition, a hire car is included as a form of the manually driven taxi of the first embodiment and the autonomously driven taxi of the second embodiment. A hire car is a type of taxi that is not used for driving around, but rather leaves and returns to a business office. Therefore, it is not in a standby state for ad hoc communication except when it is at the business office.

Furthermore, taxis are not limited to typical four-seater vehicles, but may be one-seater vehicles, two-seater vehicles, or six- or nine-seater vehicles such as wagon taxis.

In the first and second embodiments described above, a user may be able to assign priorities when searching for a taxi via ad hoc communication. For example, a preferred taxi may be searched first based on the characteristics of the taxi or the taxi driver (first priority), and if the preferred taxi cannot be found, all taxis available for ad hoc communication, including non-preferred taxis, may be searched for (second priority). Of course, there may be three or more priorities. This is convenient for the user, as it allows the preferred taxi to be used if it is within communication range, and even if the preferred taxi is not within communication range, the initial goal of traveling by taxi can be achieved.

[Third embodiment]
In the first and second embodiments described above, the mobile object to be called is limited to taxis. However, the present invention can also be applied to rental cars and car sharing. Furthermore, by changing the connection information set in the first wireless communication device of the mobile object to be called for each mobile object, it is possible to call multiple types of mobile objects.

For example, as shown in FIG. 1, the server 1 shown in FIG. 1 has a different ESSID, which is a network identifier as an example of connection information, prepared for each service, as shown in FIG. 12. It goes without saying that a WEP key may also be added to the connection information in addition to the ESSID. In this case, the WEP key may be different for each service, or the same key may be used. The mobile object that executes each service has a first wireless communication device in which the respective connection information is set.

A user can access server 1 using smartphone 3, an example of a calling device, and specify not just one but multiple service names that they wish to use. Server 1 then sends ESSIDs (including WKEYs if the WKEY is included in the connection information) associated with identification information corresponding to each specified service name. Smartphone 3 receives this information and stores the ESSIDs associated with the identification information corresponding to each service name. Therefore, the connection information is stored in memory 304 of smartphone 3 in a state similar to that shown in Figure 12.

In this third embodiment, when the call service is activated on the smartphone 3, a list of service names that can execute the call service is displayed on the display screen 305D of the display unit 305, as shown in FIG. 13. The user selects one or more services from this list for which they wish to execute the call service, and operates the start button (icon button) 3051.

When one service is selected, the smartphone 3 then sends a connection request from the wireless LAN communication unit 308 using the connection information associated with the selected service and stored in the memory 304, in the same manner as described in the first embodiment. Therefore, if a mobile object providing the selected service is within the communication range, the first communication device of the mobile object will respond to the connection request, creating an ad-hoc communication path, and the mobile object can move to the user's waiting location in the same manner as described above.

Furthermore, when multiple services are selected, the smartphone 3 sequentially selects connection information associated with the selected services and stored in memory 304 in a time-division manner, and uses the selected information to send connection requests for each service from the wireless LAN communication unit 308 in a time-division manner. Therefore, if even one mobile object providing a selected service is within communication range, the first communication device of that mobile object responds to the connection request, creating an ad-hoc communication path, and the mobile object can move to the user's waiting location in the same manner as described above. In this case, since only one ad-hoc communication path can be created at a time between the smartphone 3 and the first communication device of the mobile object, the mobile object providing the selected service that responds to the connection first will be called to the user.

The user can then select the name of the service they have called from the menu on display screen 305D and operate the end button (icon button) 3052 to end the service's call operation. Therefore, after that, any mobile object that provides a service that has not been called will become a call target.

In addition, in the third embodiment, the activation times of one or more services can also be set using a timer. For example, in Figure 13, the collection of home appliances, etc. (2) can be set to 2:00 PM, the collection and delivery of dry cleaning (3) can be set to 3:15 PM, and the taxi call (1) can be set to 5:30 PM, allowing the three services to be enjoyed like an assembly line.

According to the third embodiment, a user can select a mobile object that provides the service he or she desires and have it summoned at a time he or she desires, which is extremely convenient.
In the third embodiment, it is possible to assume that a user requests the call service from their home or workplace, and therefore the call device may be a tablet terminal or a personal computer (preferably one with a calling function) instead of a smartphone.

Note that while the lists in Figures 12 and 13 are displayed as text, they may of course also be displayed as images using icons that evoke the services.

[Other embodiments or modifications]
In the above embodiment, the user of the smartphone 3 performs an operation to receive a mobile vehicle call service such as a taxi when needed. However, an application program can also be created to automatically start receiving the mobile vehicle call service when the smartphone 3 enters a predetermined area. For example, this is suitable for a case where an area where mobile vehicles such as taxis that provide the taxi call service are located is designated as a special area, such as an Olympic village or an event venue, and a user wishes to travel within the area by mobile vehicle such as a taxi. In this case, a special vehicle may be prepared exclusively for travel in the special area.

Furthermore, when entering a theme park or amusement park area, a wireless connection request for automatically requesting the arrival of a mobile object can be automatically sent, thereby summoning vehicles or people selling various products at the theme park or amusement park. In this case, as in the examples of Figures 12 and 13 described above, the user can select the product they wish to purchase and selectively summon the vehicles or people selling that product. In this case, the mobile object is not limited to a car, but can also be a bicycle, motorcycle, or the like, or it can be a salesperson traveling on foot or a salesperson traveling by bicycle, motorcycle, etc.

In all of the first to third embodiments described above, the first communication device of the mobile object waits for a connection request sent by the second communication device of the calling device, and when the second communication device of the calling device issues a connection request, an ad hoc communication path is created between the two.

However, the opposite can also be done: a first communication device carried by the mobile object issues a connection request, and a second communication device of the calling device responds to the connection request from the first communication device, thereby creating an ad hoc communication path between the two. In other words, in a so-called order-taking style, the first communication device carried by the mobile object continuously sends connection requests, and the user of the calling device responds to the connection request from the first communication device by launching a calling service application when necessary.

In this case, after generating the ad hoc communication path, the calling device sends a call request including the user's waiting location (current location information in the above example) to the first communication device of the mobile object via the ad hoc communication path, and the second communication device of the mobile object responds to the call request by returning a response message, allowing for processing operations similar to those in the first embodiment shown in Figure 2.

In addition, rather than the calling device sending a call request including location information of the user's waiting location to the first communication device of the mobile body via an ad hoc communication path, after creating an ad hoc communication path, the first communication device of the mobile body may make a service inquiry request via the ad hoc communication path, and in response to that inquiry request, a call response including location information of the user's waiting location may be returned to the first communication device of the mobile body via the ad hoc communication path.

In this example, for example, a taxi can issue a connection request from its first communication device, advertise its availability, and while driving, receive response information from the user's second communication device, allowing it to respond to the user's request to hail a taxi via an ad hoc communication path.

Furthermore, in the third embodiment of the service for collecting home appliances and dry cleaning, the service travels around the area in a so-called errand-taking style, receiving response information from the user's second communication device, and thereby responding to the user's call request via an ad hoc communication channel. If the service cannot respond immediately but can after a short wait, it may return a response message such as, "We are currently dealing with another matter. We will come back as soon as we are done, so could you please wait for about 10 minutes?" The user can respond with either "OK" or "NG."

In all of the first to third embodiments described above, the calling device sends the user's current location information as the location information of the waiting location along with the call request to the first communication device possessed by the mobile object via an ad hoc communication path. However, the location information sent from the calling device to the first communication device possessed by the mobile object is not limited to the current location at the time of the call request, and does not need to be sent together with the call request.

In other words, if the location where the user wants to summon the mobile body is a specified location that is not the current location at the time of the summons request, the summons device can be configured to send location information of the specified location to the first communication device possessed by the mobile body via an ad hoc communication path after the user moves to the specified location. Of course, location information of the specified location may also be sent to the first communication device possessed by the mobile body via an ad hoc communication path before the user moves to the specified location.

This means that, for example, if a user is outdoors and suddenly caught in a rain shower and wants to call a taxi, the user can use the taxi call device to send a call request, then move from their current location to a sheltered, dry area, notify the taxi of their location as the waiting location via the ad hoc communication channel, and wait for the taxi there. If the user wants to kill time at a nearby store such as a convenience store while waiting for a taxi, they can conveniently notify the taxi of the store's location as the waiting location and wait there. Furthermore, if a user wants to call a taxi from home but wants to keep their home location secret, they can specify a suitable location in the neighborhood as the place where the taxi will arrive and wait.

Also, instead of the user moving from the location where the call request was made, for example, a map could be displayed on the display screen of the call device, and the user could specify a waiting location on the map where the called vehicle will wait, and the call device could recognize the location information of the specified waiting location from the map and notify the taxi or other vehicle via an ad hoc communication channel.

Furthermore, in the third embodiment, when receiving multiple services, location information of a different waiting location for each service may be sent via an ad hoc communication path to the first communication device possessed by the mobile object of each service. This allows the user to conveniently select a waiting location for the mobile object summoned for each service.

Furthermore, the location information may be set by the mobile unit, rather than the user. For example, if there is a location (location) that is suitable for parking or a location (location) that is easy to board the user near the user's current location at the time of the call request, the mobile unit can specify this location, allowing the mobile unit to board the user smoothly. This can also avoid situations where the user specifies a location (location) that is not suitable for boarding, such as a no-entry area, a one-way street, or a narrow alley, which can be inconvenient. In the case of the autonomous vehicle of the second embodiment, if the user can specify a waiting location, it is expected that autonomous driving will be even smoother.

In addition, when the distance between the vehicle and the user is within a predetermined distance (e.g., 100 m) or when the waiting time is within a predetermined time (e.g., 1 minute), the user's mobile device may be notified with an alarm, message, or screen display. This makes it easier for the user to know which vehicle they should board.

The vehicle can also alert the user by flashing a light (lamp) indicating a pickup or by turning on a light (lamp) mounted on the roof. By informing the user in advance of the color of the light that will be turned on, it becomes even easier for the user to identify the vehicle that has been called. The light (lamp) may also be attached to the side mirror or door to improve visibility.

In the above embodiments, the calling device is a smartphone, which is a mobile terminal. However, as mentioned above, it goes without saying that the calling device is not limited to mobile terminals such as smartphones. For example, the calling device may be a mobile terminal such as a pad-type terminal with wireless LAN functionality or a so-called tablet-type terminal, or it may be a notebook PC (personal computer) or a stationary desktop PC. It may also be a wristwatch-type terminal, eyeglass-type terminal, or other terminal. Furthermore, the calling device may be a fixedly installed device such as a parking meter.

Furthermore, the first communication device installed in the mobile object is not limited to the taxi-specific device 6, but can also be a mobile phone terminal such as a smartphone, or a mobile terminal such as the pad-type terminal or tablet-type terminal described above. Furthermore, the first communication device may be built into a car navigation device installed in the mobile object.

Furthermore, in the above-described embodiment, the connection information for the calling device is set by accessing a specified server, but it goes without saying that the user may obtain the connection information and manually set it on the calling device.

Furthermore, in the above-described embodiment, the Wi-Fi (registered trademark) standard wireless LAN was used as the communication standard for this invention, but the communication standards that can be used by the first and second wireless communication devices are not limited to this. It goes without saying that any communication standard or communication method can be applied to this invention as long as it meets the requirements for this invention, such as having a predetermined communication range and being able to generate a direct communication path that does not go through a relay device such as an access point.

1...Taxi ad hoc communication setting server, 2...Communication network, 3...Smartphone, 4...Communication area, 5A, 5B...Taxi, 6...Taxi-specific device, 301...Control unit, 307...Current location detection unit, 308...Wireless LAN communication unit, 601...Control unit, 602...Wireless LAN communication unit, 605...Car navigation function unit, 606...Current location detection unit

Claims (41)

a calling device storing first wireless connection information for creating a direct communication path with a partner device;
a mobile unit that stores second wireless connection information for creating a direct communication path with the other device and is provided in the mobile unit to be called;
and
The mobile device is
a connection request means for transmitting a connection request signal including the second wireless connection information;
a first communication path generating means for generating the communication path between the calling device that has transmitted a response signal including the first wireless connection information that matches the second wireless connection information in response to the connection request signal;
Equipped with
The calling device is
a second communication path generating means for transmitting the response signal including the first wireless connection information to the mobile body device when a match between the second wireless connection information included in the received connection request signal and the first wireless connection information is detected, and generating the communication path between the mobile body device and the mobile body device ;
The moving body is a taxi,
the mobile device includes a determination means for detecting whether or not a customer is in the taxi, and for transmitting the connection request signal when the mobile device detects that the customer is not in the taxi and the taxi is vacant;
the taxi is equipped with an expressway driving detection means for detecting whether the taxi is driving on an expressway;
The determining means determines that the vehicle is not empty when the expressway driving detection means detects that the vehicle is driving on an expressway.
A mobile object summoning system. The taxi is provided with a camera for photographing the interior of the taxi,
2. The mobile object hailing system according to claim 1 , wherein the determining means detects whether or not a customer is in the taxi based on the image captured by the camera. A sensor is attached to the passenger seat of the taxi to detect when a customer gets in,
3. The mobile object hailing system according to claim 1 , wherein the determining means detects whether or not a customer is in the taxi based on an output from the sensor. The passenger seats of the taxi are equipped with a means for detecting whether a seat belt is fastened,
The mobile object hailing system according to any one of claims 1 to 3 , characterized in that the determination means detects whether a customer is in the taxi based on the detection output of the means for detecting seat belt fastening. The taxi is provided with a taximeter,
The mobile object hailing system according to any one of claims 1 to 4 , characterized in that the determination means determines that the vehicle is vacant by recognizing that the vacant vehicle button on the taxi meter has been operated. the mobile device continuously transmits the connection request signal;
A mobile object summoning system as described in any one of claims 1 to 5, characterized in that the summoning device receives the connection request signal in accordance with the operation of the user of the summoning device, and when it detects a match between the second wireless connection information contained in the received connection request signal and the first wireless connection information, it transmits the response signal to the mobile object device. The mobile object calling system according to claim 6 , wherein the calling device is provided with an application for a service for calling the mobile object, and the user's operation is an operation for launching the application for the service for calling the mobile object. 8. The mobile object calling system according to claim 1 , wherein the calling device stores a plurality of pieces of the first wireless connection information. The calling device is
a first location information transmitting means for transmitting information about a waiting position where a user of the calling device should wait for the mobile object to the mobile object device through the communication path, and/or a first location information receiving means for receiving information about a waiting position where a user of the calling device should wait for the mobile object from the mobile object device through the communication path,
The mobile device is
The mobile object summoning system according to any one of claims 1 to 8, further comprising: a second position information receiving means for receiving information on the standby position from the summoning device through the communication path; and/or a second position information transmitting means for transmitting information on the standby position to the summoning device through the communication path. The mobile object summoning system according to claim 9, characterized in that the summoning device includes means for accepting, by a user, a designation of the waiting position on a map displayed on a display screen, and transmits information of the waiting position designated on the map to the mobile object device. 11. A mobile object calling system as described in claim 9 or claim 10, characterized in that, when the created communication path is disconnected before the mobile object arrives at the waiting position, the mobile object device stores the first wireless connection information of the calling device connected by the communication path before the disconnection process, and the calling device stores the second wireless connection information of the mobile object device connected by the communication path, thereby enabling the communication path to be reconnected. 11. The mobile object hailing system according to claim 9, wherein the hailing device and the mobile object device maintain the created communication path without disconnecting it until the user gets on the vehicle . A mobile object hailing system as described in claim 9 , claim 10 or claim 12, characterized in that when the generated communication path is disconnected before the user boards the vehicle, before the disconnection process, the mobile object device stores the first wireless connection information of the hailing device connected by the communication path, and the hailing device stores the second wireless connection information of the mobile object device connected by the communication path, thereby enabling the communication path to be reconnected. the calling device includes a call request sending means for sending a call request to the mobile object through the created communication path,
The mobile body call system according to any one of claims 1 to 13, characterized in that the mobile body device comprises: a call request response determination means for determining whether or not to respond to the call request received through the communication path based on an instruction input by the driver of the mobile body; and a call response sending means for sending a call response to the call request through the communication path when the call request response determination means determines that the call request should be responded to. The calling device is
a first location information transmitting means for transmitting, to the mobile body device, information on a waiting position where a user of the calling device should wait for the mobile body, after receiving the call response through the communication path, or a first location information receiving means for receiving, from the mobile body device, information on a waiting position where a user of the calling device should wait for the mobile body, through the communication path;
The mobile device is
a second location information receiving means for receiving information about the standby position from the calling device through the communication path after transmitting the call response through the communication path, and/or a second location information transmitting means for transmitting information about the standby position to the calling device through the communication path;
The call device and the mobile device maintain the created communication path without disconnecting it until the user gets on the vehicle .
15. The mobile object calling system according to claim 14 , wherein the calling device can notify the cancellation of the call request through the communication path that is maintained without being disconnected. 16. The mobile object calling system according to claim 15, wherein the mobile object device is capable of inquiring whether or not to cancel the call request through the communication path that is maintained without being disconnected after sending the call response through the communication path . the call request from the call device includes authentication information of the user who made the call request;
17. The mobile object call system according to claim 15 , wherein when the mobile object arrives at the waiting position, the mobile object authenticates the user who made the call request based on the authentication information. The calling device is
a first location information transmitting means for transmitting, to the mobile body device, information on a waiting position where a user of the calling device should wait for the mobile body, after receiving the call response through the communication path, or a first location information receiving means for receiving, from the mobile body device, information on a waiting position where a user of the calling device should wait for the mobile body, through the communication path;
The mobile device is
a second location information receiving means for receiving information about the standby position from the calling device through the communication path after transmitting the call response through the communication path, and/or a second location information transmitting means for transmitting information about the standby position to the calling device through the communication path;
The taxi maintains the created communication path between the call device and the mobile body device without disconnecting it until the user gets in, and
A mobile object calling system according to any one of claims 14 to 17 , characterized in that the calling device is capable of notifying cancellation of the calling request through the communication path that is maintained without being disconnected. the call request from the call device includes authentication information of the user who made the call request;
A mobile object hailing system as described in any one of claims 14 to 18 , characterized in that when the user who made the hailing request gets into the taxi, the taxi authenticates the user who made the hailing request based on the authentication information. The authentication information is personal information of the user who made the call request,
The mobile object hailing system according to claim 17 or 19, characterized in that the taxi is equipped with a display means for displaying the personal information on a display screen, and the taxi driver can authenticate the user who made the hailing request based on the personal information displayed on the display screen . The mobile object hailing system according to claim 17 or 19, characterized in that the taxi includes a customer authentication unit , and the customer authentication unit authenticates the user who made the hailing request by using the authentication information acquired from the hailing device through the communication path. The mobile object summoning system according to claim 21, characterized in that the authentication in the customer authentication unit is performed by any one of facial image authentication of the user who made the summoning request, password verification, authentication of the spoken voice of the user who made the summoning request, authentication of biometric information including fingerprints, vein patterns, and irises of the user who made the summoning request, or a combination thereof . The mobile object hailing system according to any one of claims 14 to 22 , wherein the hailing request includes a request for a taxi to be called. The mobile object hailing system of claim 23, characterized in that the request includes one or a combination of the following: characteristics of the taxi, characteristics of the taxi driver, whether the taxi is a corporate or private taxi, the name of the preferred taxi company, a method of paying for the taxi fare, and the use of a taxi ticket. The mobile object hailing system according to any one of claims 14 to 24 , characterized in that priority is assigned to taxis that are called in response to the call request. The mobile object calling system according to any one of claims 14 to 25 , wherein the call response includes an inquiry message informing the user that an immediate response is difficult but that the user can wait. The mobile object calling system according to any one of claims 1 to 13, characterized in that the mobile object device sends a service inquiry request to the calling device through the created communication path, and the calling device sends a response to the inquiry request received through the communication path to the mobile object device through the communication path. 28. The mobile object calling system according to claim 27 , wherein the call device includes, in the response to the inquiry request, information about a waiting location where a user of the call device should wait for the mobile object. The mobile object hailing system according to any one of claims 1 to 28 , wherein the taxi includes a hire car, a water taxi, an underwater taxi, an air taxi, or an air taxi. A mobile object summoning system as described in any one of claims 1 to 29, characterized in that the summoning device accesses a server device through a communication network to obtain wireless connection information that is the same as the second wireless connection information stored in the second wireless communication unit of the mobile object device as the first wireless connection information, and stores the information in the first wireless communication unit of the summoning device . the server device holds a plurality of pieces of second wireless connection information that differ for each service, presents a list of a plurality of services to a user of the calling device, and provides the calling device with the second wireless connection information corresponding to a service selected from the list by the user of the calling device;
31. The mobile object calling system according to claim 30 , wherein the calling device stores the second wireless connection information acquired from the server device as the first wireless connection information. A mobile object calling system as described in any one of claims 1 to 31, characterized in that communication between the calling device and the mobile object device is wireless LAN communication, the first wireless connection information and the second wireless connection information include a network identifier and a WEP (Wired Equivalent Privacy ) key, and the WEP key is different for each service or is the same regardless of the service. The mobile object summoning system according to any one of claims 1 to 32, characterized in that the summoning device is one of a smartphone, a tablet terminal, a personal computer, a wristwatch terminal, an eyeglass terminal, a pad terminal, and a fixedly installed device. The mobile object calling system according to any one of claims 1 to 33 , characterized in that the calling device is provided with a notification means for notifying a user that the distance to the mobile object has come within a predetermined distance. The mobile object calling system according to any one of claims 1 to 34 , characterized in that the calling device is provided with a notification means for notifying a user that the waiting time for the arrival of the mobile object has reached a predetermined time. 36. The mobile object calling system according to claim 1, wherein the mobile object comprises a notification means for notifying a user of the calling device of the mobile object. 37. The mobile object calling system according to claim 36 , wherein the mobile object uses a light as the notification means, and the color of the light to be turned on is notified to the user of the calling device in advance. 38. The mobile object calling system according to claim 1, wherein the mobile object is provided with a notification means for notifying a user of the calling device of a traffic jam or an accident. a calling device storing first wireless connection information for creating a direct communication path with a partner device;
a mobile unit that stores second wireless connection information for creating a direct communication path with the other device and is provided in the mobile unit to be called;
and
The calling device is
a second communication path generating means for transmitting a response signal including the first wireless connection information to the mobile object device when a match between the second wireless connection information included in the connection request signal received from the mobile object device and the first wireless connection information is detected, and generating the communication path between the mobile object device and the mobile object device;
The mobile object device in a mobile object calling system comprising:
a connection request means for transmitting the connection request signal including the second wireless connection information;
a first communication path generating means for generating the communication path between the calling device that has transmitted the response signal including the first wireless connection information that matches the second wireless connection information in response to the connection request signal;
Equipped with
The moving body is a taxi,
the mobile device includes a determination means for detecting whether or not a customer is in the taxi, and for transmitting the connection request signal when the mobile device detects that the customer is not in the taxi and the taxi is vacant;
the taxi is equipped with an expressway driving detection means for detecting whether the taxi is driving on an expressway;
The determining means determines that the vehicle is not empty when the expressway driving detection means detects that the vehicle is driving on an expressway.
A device for a moving body characterized by: continuously transmitting the connection request signal;
The mobile body device according to claim 39, characterized in that the calling device receives the connection request signal in accordance with an operation by a user of the calling device, and when it detects a match between the second wireless connection information included in the received connection request signal and the first wireless connection information , it transmits the response signal to the mobile body device. a calling device storing first wireless connection information for creating a direct communication path with a partner device;
a mobile unit that stores second wireless connection information for creating a direct communication path with the other device and is provided in the mobile unit to be called;
and
The moving body is a taxi,
The calling device is
a second communication path generating means for transmitting a response signal including the first wireless connection information to the mobile object device when a match between the second wireless connection information included in the connection request signal received from the mobile object device and the first wireless connection information is detected, and generating the communication path between the mobile object device and the mobile object device;
a computer included in the mobile device in a mobile object calling system,
a connection request means for transmitting the connection request signal including the second wireless connection information;
a first communication path generating means for generating the communication path between the calling device that has transmitted the response signal including the first wireless connection information that matches the second wireless connection information in response to the connection request signal;
a determination means for detecting whether or not a customer is in the taxi, and sending the connection request signal when it is detected that the customer is not in the taxi and the taxi is vacant;
A program for a mobile device , characterized in that it functions as
the taxi is equipped with an expressway driving detection means for detecting whether the taxi is driving on an expressway;
The determining means determines that the vehicle is not empty when the expressway driving detection means detects that the vehicle is driving on an expressway.
A program for a mobile device .