Management server and computer programs

Abstract

To implement ride-sharing in the car-sharing business. [Solution] The management server includes a vehicle management database that stores management data related to shared cars managed by car-sharing operators, linked to a vehicle ID for each vehicle; a member database; a means for receiving usage inquiry data that receives usage inquiry data including the desired date and time of use, departure point and destination from a passenger terminal relating to a passenger who wishes to use a ride-sharing service provided by a ride-sharing driver who is able to provide ride-sharing services; a means for receiving reservation inquiry data that includes the desired date and time of use and departure point from a driver terminal; a means for determining whether a reservation is possible based on the reservation inquiry data using the vehicle management database; a means for transmitting the reservation feasibility determination result to a member user terminal; and a matching means that, if the reservation feasibility determination result indicates that a reservation is possible, verifies whether the reservation inquiry data can be implemented based on the content of the usage inquiry data.

Description

Technical Field

[0001] The present invention relates to support technology for a car sharing member that implements a ridesharing service. Background Art

[0002] Since the late 2000s, personal vehicle dispatching services have started in North America, where passenger car drivers seek companions for ridesharing to reduce the cost borne by each person. Apart from the aforementioned "ridesharing type", a "dispatching type" service has also emerged, in which a driver of a private vehicle picks up and transports a co-rider (passenger) and receives a fare for the transportation service. With the respective advancements in the utilization of GPS, the provision of smartphone applications, mobile payment and other technologies, "ride-sharing services" have been established. In countries and regions with less stringent regulations, ride-sharing services have come to compete with public transportation services and taxi businesses in terms of service price and convenience.

[0003] In Japan, securing means of transportation in depopulated areas and local cities has been an issue, and ride-sharing is expected as an efficient means of transportation. With the increase in the number of tourists visiting Japan, it is expected to alleviate the shortage of taxis especially in local cities. In large cities, there is also a demand for a means to compensate for the shortage of taxis during peak hours.

[0004] On the one hand, from the perspective of ensuring the safety of passengers, the necessity of maintaining driver standards and vehicle management has been pointed out; on the other hand, it is necessary to construct the service in consideration of the possibility that predetermined regulations will be enacted. Against this background, the taxi industry in Japan has developed its own "dispatching type" services. For example, the industry provides maintained standby vehicles to ride-sharing drivers and manages the drivers.

[0005] Two crucial information processing functions are supply and demand matching and fare settlement. Figure 1 briefly explains the information processing procedures used by typical ride-sharing applications in other countries.

[0006] Passengers using rideshare (abbreviated as "RS" in the diagram) use their own terminal (passenger terminal) to send desired data such as the desired start date and time of the ride, pickup location, destination, and number of passengers using the rideshare intermediary application. Although the term "intermediation" is used for convenience, the drivers who operate the vehicles are the ones who make ride-sharing a business, so the drivers (or their organizations) are the ones who perform the intermediation or manage the intermediary servers. Alternatively, it is certainly conceivable that the aforementioned intermediary business could be launched as a new venture.

[0007] The rideshare intermediary server (hereinafter referred to as the "rideshare server," abbreviated as "RS server" in the diagram), which mediates the request data, receives the request data via the request data receiving means. Then, using a driver database (abbreviated as "DB" in the diagram) that stores data on pre-registered rideshare drivers, it extracts rideshare drivers that match the conditions of the request data. The request data is then transferred to the terminal (driver terminal) associated with the extracted rideshare driver, and the server inquires whether the driver can provide a rideshare in response to that request.

[0008] The rideshare driver verifies the request data sent from the rideshare server and, if they can accept the rideshare offer, sends an acceptance notification to the rideshare server. Upon receiving the acceptance notification, the rideshare server sends acceptance data to the passenger's terminal, identifying the accepted driver and the vehicle to be used.

[0009] After the passenger boards the vehicle driven by the rideshare driver and completes the use of the service related to their request, they send the settlement data to the intermediary server. The intermediary server completes the settlement process, sends the settlement processing data to the driver's terminal, and ends the series of data processing.

[0010] Regarding ride-sharing services, the following prior technologies were identified: For example, Patent Document 1 discloses a passenger assistance technology that can efficiently generate operation plans while supporting various passenger configurations.

[0011] Patent Document 2 discloses a technology for efficiently deploying electric vehicles in a way that matches the demand in each area, although this technology is not limited to ride-sharing. [Prior art documents] [Patent Documents]

[0012] [Patent Document 1] Patent No. 7584331 [Patent Document 2] Japanese Patent Publication No. 2024-4676 [Overview of the project] [Problems that the invention aims to solve]

[0013] Now, let's consider a scenario where a car-sharing company, rather than the taxi industry, provides ride-sharing services. This is because car-sharing companies can provide vehicles in the same way as the taxi industry, and the drivers who provide ride-sharing services using those vehicles can potentially be offered as users of car-sharing services.

[0014] Figure 2 provides a simple comparison between a car-sharing management server (abbreviated as "car-sharing server" in the figure) managed and operated by a car-sharing business operator, and the ride-sharing server shown in Figure 1.

[0015] One key difference is that car-sharing businesses have a vehicle management database because they manage the vehicles themselves, while ride-sharing servers do not. This is because a driver database suffices. The second difference is that car-sharing businesses do not anticipate ride-sharing passengers who ride along in car-sharing vehicles driven by members. Therefore, the ride-sharing server does not have a configuration for receiving or sending data from ride-sharing passengers. Consequently, there is no configuration for matching members with ride-sharing passengers, nor is there a configuration for distributing payments from ride-sharing passengers to the member who acts as the driver.

[0016] (Matching problem) The aforementioned "matching" will be explained in detail below. Car-sharing operators register users who wish to use their vehicles as members, accept reservations using their member IDs, and then provide the vehicles. Ridesharing services, on the other hand, presuppose the existence of passengers who wish to ride in the vehicle. Currently, car-sharing operators do not have the infrastructure (mechanisms, infrastructure) to receive inquiry data from these passengers and connect them with member drivers for matching.

[0017] (Issues regarding settlement of usage fees) The aforementioned "structure for distributing compensation" will be explained in detail below. In ride-sharing services, the driver receives payment (a usage fee) from the passengers for providing a service that involves transporting them. One could simply accept that the car-sharing member and the passenger using the ride-sharing service provided by that member should determine the service fee and agree on the payment method. By leaving it to the contract between the two parties in this way, the car-sharing operator would not have to deal with the aforementioned problem of settling usage fees. However, the operation method of concluding a contract between the two parties for each use is cumbersome, and furthermore, there is a high possibility that the anxiety caused by unclear market perception cannot be eliminated for both drivers and passengers. If this expectation is correct, expansion as a business cannot be expected. With regard to the settlement of usage fees, it is desirable to be premised on the existence of an intermediary or a mechanism for appropriate public disclosure.

[0018] A car sharing operator pre-registers as members persons who desire to use a driven vehicle, and has established a mechanism (infrastructure) for collecting usage fees according to the use of the service by the members. However, no mechanism (infrastructure) is prepared for collecting consideration from non-member passengers who ride and travel in a vehicle driven by a member, or distributing the consideration to the member who drove the vehicle.

[0019] (Response to Immediate Riding) Ride-sharing services are expected to be a means of resolving taxi shortages. In this case, it is also necessary to respond to the need of wanting to start moving (ride) as soon as possible from now. However, when a ride-sharing service is provided by a car sharing operator, such a mechanism should also be provided.

[0020] Neither in Patent Document 1 and Patent Document 2, nor in the patent search conducted to extract the aforementioned documents, could a service that provides infrastructure that allows a car sharing operator to mediate or operate ride-sharing be found.

[0021] The problem to be solved by the present invention is, among the new problems described above, to provide an information processing technology that can solve the matching problem and implement a ride-sharing service in a car sharing business. Note that the boundaries between the car sharing business and the car rental business have become ambiguous as they have each adopted each other's advantages, so the following description will be given under the term "vehicle sharing operator".

Means for Solving the Problem

[0022] To address the aforementioned challenges, a vehicle-sharing business will provide vehicles to registered member users and match them with passengers who wish to ride with the vehicles.

[0023] (First invention) The first invention relates to a management server (referred to as the "Car Share RS Server" in the diagram) for a vehicle sharing business that lends vehicles to registered member users who have completed prior membership registration, in which case the member users operate the rideshare service. In other words, a vehicle management database that stores management data related to shared vehicles managed by the aforementioned vehicle sharing business operator, linked to a vehicle ID for each vehicle, The aforementioned member database stores the attribute data of member users necessary for member registration, linked to the member ID (if the user registers in advance that they will become an RS driver, this would be the "driver database"), A means for receiving request data for use, which receives request data including the desired date and time of use, departure point, and destination from a terminal (referred to as "passenger terminal" in the diagram) of a passenger who wishes to use a rideshare service provided by a rideshare driver who drives a shared vehicle managed by the aforementioned business operator, A reservation request data receiving means that receives reservation request data, including the desired date and time of use and departure location, from the terminal of the aforementioned member user (referred to as the "driver terminal" in the diagram), A reservation availability determination means that determines whether the shared vehicle can be reserved using the vehicle management database with respect to the reservation inquiry data, A reservation eligibility / determination transmission means that transmits the determination result from the reservation eligibility / determination means to the terminal of the member user, When the result of the reservation feasibility determination means is that a reservation is possible, a matching means verifies whether the reservation inquiry data can be implemented based on the content of the usage inquiry data, A matching-possible transmission means that transmits matching-possible data to the terminal of the member user and the terminal of the passenger if matching is possible based on the verification results by the matching means, It is equipped with (see Figures 3 and 4).

[0024] (Explanation of terms) "Vehicle sharing business" refers to car-sharing businesses or car rental businesses. Therefore, "shared vehicle" refers to a shared car or a rental car.

[0025] The "management server" is a computer. Therefore, it is equipped with a data receiving device as a data input device, random access memory, data storage devices, a processing unit (CPU), and a data transmission device as a data output device.

[0026] "A terminal related to a passenger" is not limited to a communication terminal owned, used, or carried by the passenger; any communication terminal capable of transmitting usage inquiry data is acceptable.

[0027] (action) The vehicle management database stores management data for shared vehicles managed by the aforementioned vehicle sharing operators, linked to each vehicle's vehicle ID. The member database stores attribute data of member users required for member registration, linked to their member IDs. The vehicle sharing service provider offers ride-sharing services by providing ride-sharing services to passengers who wish to use the service. From a passenger's terminal (passenger terminal), the vehicle sharing service provider receives request data for use, including the desired date and time of use, departure point, and destination. The reservation request data receiving means receives a reservation request from a member user's terminal (driver's terminal), including the desired date and time of use and departure point. The reservation eligibility determination means uses the vehicle management database to determine whether a shared vehicle can be reserved based on the reservation inquiry data. The reservation eligibility determination means then transmits the result of its determination to the member user's terminal.

[0028] If the reservation availability determination means determines that a reservation is possible, the matching means verifies, based on the content of the usage inquiry data, whether there is a reservation that can accommodate the usage inquiry, that is, whether there is a reservation that can provide the service by driving from the departure point to the destination at the desired date and time specified in the usage inquiry data. If the matching means verifies that a match is possible, the matching availability transmission means transmits the matching availability data to the terminal of the member user and the terminal of the passenger. At this point, it is confirmed that the service for the reservation inquiry data can be provided, and the matching is completed between the reservation in which the vehicle sharing business operator lends a shared vehicle to the member user who will be the driver and the passenger who wishes to ride in the shared vehicle.

[0029] (Variation 1 of the first invention) The first invention may also be constructed as follows: In other words, the system includes a user database in which passengers who wish to use the rideshare service register their intention to use the rideshare driver, along with attribute data for identifying the passenger. A driver database will be included within the aforementioned member database, in which the member ID and the intention to provide rideshare services are pre-registered by the aforementioned rideshare drivers (see Figures 3 and 4).

[0030] (Variation 2 of the first invention) Variation 1 in the first invention may be configured as follows: In other words, if the matching by the aforementioned matching means is unsuccessful, in order to find a driver who is available to drive based on the content of the aforementioned usage inquiry data, driving inquiry data including the usage inquiry data is transmitted to the terminal of the driver based on the aforementioned driver database (see Figures 8 and 9).

[0031] (action) If matching by the matching method fails, driving inquiry data, including usage inquiry data, is sent to the terminals of other drivers registered in the driver database (drivers other than the driver who failed to be matched). If a driver who receives the usage inquiry data is able to drive according to the contents of the driving inquiry data, they can reply to that effect, and matching will be completed.

[0032] (Second invention) The second invention relates to a computer program for controlling a management server (car share RS server) used by member users to operate a rideshare service in a vehicle sharing business that lends vehicles to member users who have completed member registration in advance. The aforementioned management server includes a vehicle management database that stores management data related to shared vehicles managed by the aforementioned vehicle sharing operator, linked to each vehicle's vehicle ID, and A member database that stores the attribute data of member users necessary for the aforementioned member registration, linked to the member ID, It is equipped with. Computer programs are A procedure for receiving request data for use, which receives request data including the desired date and time of use, departure point and destination from a terminal (passenger terminal) of a passenger who wishes to use a rideshare service provided by a rideshare driver who drives a shared vehicle managed by the aforementioned business operator, A procedure for receiving reservation request data, which includes the desired date and time of use and departure location, from the terminal (driver terminal) of the aforementioned member user, A reservation availability determination procedure that uses the vehicle management database to determine whether the shared vehicle can be reserved based on the reservation inquiry data, A reservation eligibility / determination transmission procedure that transmits the result of the reservation eligibility / determination procedure to the terminal of the aforementioned member user, If the result of the reservation feasibility determination procedure described above is that a reservation is possible, a matching procedure is performed to verify whether the reservation inquiry data can be implemented based on the content of the aforementioned inquiry data, A matching-possible transmission procedure that transmits matching-possible data to the terminal of the member user and the terminal of the passenger if matching is possible based on the verification results of the matching procedure, This is a computer program that causes the aforementioned management server to execute it.

[0033] (Variation 1 of the second invention) The second invention may be configured as follows: In other words, the management server is equipped with a passenger database in which the passenger's expression of intent to use the rideshare driver's transportation service is pre-registered along with attribute data for identifying the passenger. A driver database will be included within the aforementioned member database, in which the member ID and the intention to provide rideshare services are pre-registered by the aforementioned rideshare drivers (see Figures 3 and 4).

[0034] (Variation 2 of the second invention) Variation 1 in the second invention may be configured as follows: In other words, when the matching procedure described above fails, a computer program is created to cause the management server to execute a driving inquiry data transmission procedure, which involves sending driving inquiry data, including the driving inquiry data, to the terminal of the driver based on the driver database, in order to find a driver who is available to drive based on the contents of the driving inquiry data (see Figures 8 and 9).

[0035] The computer program relating to the second invention can also be transmitted from a computer storing the program to other terminal devices via a communication line. It may also be provided via the internet, on a so-called cloud platform. Furthermore, the computer program relating to the second invention can also be provided by storing it on a recording medium. Here, "recording medium" refers to a medium that can carry a program that cannot occupy space on its own. Examples include flexible disks, hard disks, CD-Rs, DVD-Rs, and USB memory sticks. [Effects of the Invention]

[0036] According to the first invention, it was possible to provide a management server for realizing ride-sharing in a vehicle sharing service business. According to the second invention, we were able to provide a computer program that controls a management server for realizing ride-sharing in a vehicle sharing service business. [Brief explanation of the drawing]

[0037] [Figure 1] This is a conceptual diagram illustrating a typical ride-sharing service, focusing on the intermediary server. [Figure 2] This is a conceptual diagram comparing the functions of operating servers for ride-sharing and car-sharing businesses. [Figure 3] This block diagram outlines the procedures required for car-sharing operators to implement ride-sharing services, including driver registration and booking. [Figure 4] This block diagram shows the procedure for matching passengers and drivers to enable ride-sharing. [Figure 5] This block diagram shows the procedure necessary for a car-sharing operator to implement ride-sharing, including the pre-registration of passengers and the process of inquiring about using the service. [Figure 6] This is a diagram outlining how car-sharing operators can implement ride-sharing services. [Figure 7] This block diagram outlines the procedure for a passenger to change their search criteria and re-match if a rideshare driver and passenger are initially unsuitable for the original match. [Figure 8]This block outlines the procedure for contacting a driver if a rideshare driver and passenger matching is unsuccessful. [Figure 9] This block outlines the procedure for contacting a driver if a rideshare driver and passenger matching is unsuccessful. [Figure 10] This block diagram shows the procedure for contacting other drivers when a rideshare driver cancels after being matched with a passenger. [Figure 11] This is a block diagram illustrating data collection and data provision during rideshare driving. [Figure 12] This block diagram shows the procedure for conducting driver evaluations by rideshare passengers. [Figure 13] This flowchart shows an example of an algorithm, including whether or not to use ride-sharing immediately. [Modes for carrying out the invention]

[0038] The present invention will be described below based on the drawings and embodiments. The drawings used herein are Figures 3 to 13. Solid arrows indicate wired communication, dashed arrows indicate wireless communication, and dotted lines indicate dashed lines. Figures 1 and 2 illustrate the prior art and may be referred to as necessary. Car sharing and car rental businesses share many similarities, and in recent years, it has become difficult to distinguish between the two. Therefore, in the following explanation, we will refer to it as car sharing (business), but this will also include car rental (business).

[0039] (Figure 3) Figure 3 illustrates the preparatory steps for implementing ride-sharing, from the point where a driver who wishes to conduct ride-sharing using a shared vehicle (shared car) provided by a car-sharing operator completes driver registration in advance and makes a ride-sharing reservation.

[0040] Among registered car-sharing users, those who wish to perform ride-sharing while driving a shared car must transmit driver registration data from their associated terminal (driver terminal) via the driver registration data transmission method. "Driver registration data" includes the member ID indicating that the user is a member, and a declaration of intent to perform ride-sharing.

[0041] Car-sharing operators have a car-sharing management server for storing and processing data necessary to operate their car-sharing business. This car-sharing management server includes a vehicle management database for managing shared cars and a member database that stores attribute data of members who are users.

[0042] We will now explain Figure 3 and subsequent sections assuming that a car-sharing ride management server (abbreviated as "car-sharing RS server" in the diagrams) for managing ride-sharing services is virtually constructed within a portion of the aforementioned car-sharing management server.

[0043] When driver registration data is transmitted, the driver registration data receiving mechanism on the car-sharing RS server receives it. The received driver registration data is then stored in the driver database built within the member database. To identify the driver as a ride-sharing driver, an RS driver ID linked to the member ID is issued and sent back to the driver's terminal.

[0044] On the driver's terminal, the transmitted RS driver ID is received and stored using the RS driver ID receiving device. Then, when booking a shared car, the RS driver ID is used to reserve the vehicle for ride-sharing available.

[0045] When a driver wants to reserve a shared car for a ride-sharing service from their driver terminal, they send reservation request data via the reservation request data transmission method. The data sent at that time includes the RS driver ID, planned date and time of use, starting station, and vehicle type.

[0046] On the car-sharing RS server, reservation inquiry data is received by the reservation inquiry data receiving means. Then, based on the vehicle management database, the reservation feasibility determination means determines whether a reservation is possible based on the reservation inquiry data. The result of the determination as to whether a reservation is possible or not is sent back to the driver's terminal by the reservation feasibility transmission means.

[0047] If the driver receives notification via the driver's terminal's reservation availability notification device that a reservation is possible, the driver sends reservation confirmation data via the reservation confirmation data transmission device, which is an indication of their intention to confirm the reservation. Upon receiving the reservation confirmation data via the reservation confirmation data reception device, the car share RS server updates the vehicle management database and the driver database.

[0048] (Figure 4) Figure 4 shows the relationship between the car-sharing RS server and the communication terminal (passenger terminal) for passengers who wish to use the ride-sharing service. The numbers in parentheses attached to the data between the components indicate the order in which data is exchanged between them. As a preparatory step for realizing ride-sharing, it is assumed that driver registration and registration of driving reservation confirmation data (0), as shown in Figure 3, have already been completed.

[0049] A passenger who wishes to use the rideshare service sends a request for use data to the carshare RS server using the request data transmission means on their passenger terminal (1). The request for use data includes the date and time the passenger wishes to ride the rideshare, the departure point and destination of the passenger, and passenger identification data (name, address, etc.) to identify the passenger.

[0050] The usage inquiry data transmitted from the passenger's terminal is received by the usage inquiry data receiving means on the car-sharing RS server. The car-sharing RS server then searches for confirmed driving reservation data that can be matched with that usage inquiry data. This search is performed by the matching means. The matching means performs the matching search as follows. Note that the connection between the vehicle management database and the matching means is shown with a dashed line rather than a solid line to indicate that the matching means may refer to it as needed.

[0051] The driver database stores confirmed driver reservation data according to the procedure shown in Figure 3. First, the system scans this confirmed driver reservation data for reservation dates and times. That is, it searches for confirmed driver reservation data that matches the date and time in the usage inquiry data.

[0052] Next, the system scans through confirmed travel booking data that matches the date and time in the travel inquiry data to determine whether the departure point or destination in the travel inquiry data and the location of the travel start station in the confirmed travel booking data are within a predetermined distance. In other words, it searches for confirmed travel booking data that can be presumed to be accessible to the departure point or destination in the travel inquiry data.

[0053] If the date, time, and location match, the system determines that a match is possible and transmits the matching result to the passenger terminal and the driver terminal via the matching-possible transmission means (2).

[0054] On the passenger terminal, the matching-enabled receiving means receives matching-enabled data. This allows the passenger to recognize that there is confirmed driving reservation data that matches the usage inquiry data. The passenger sends back usage reservation confirmation data, indicating their intention to confirm the reservation, using the usage reservation confirmation data transmission means on the passenger terminal. On the car share RS server, the usage reservation confirmation data receiving means receives this. The reservation completion data, indicating that the reservation has been completed, is then sent to both the passenger terminal and the driver terminal by the reservation completion data transmission means (3).

[0055] (Figure 5) Figure 5 shows an embodiment that incorporates a system for pre-registering the passengers shown in Figure 4 as passengers.

[0056] Passengers who wish to use the rideshare service must register in advance by sending their passenger registration data to the carshare RS server. Passenger registration data includes the passenger's name and address.

[0057] The car-sharing RS server, upon receiving the passenger registration data, registers it in the passenger database and issues a passenger ID. It then sends that passenger ID back to the passenger's terminal.

[0058] From this point onward, the process is almost identical to Figure 4, starting with the passenger sending the usage inquiry data to the car-sharing RS server. Therefore, let's explain the differences. The difference is that the usage inquiry data includes the passenger ID. Consequently, the matching method in Figure 5 includes a step to verify whether the passenger ID is valid or not.

[0059] The transmission of usage inquiry data in Figure 4 and passenger registration in Figure 5 are not limited to the forms described above. The usage inquiry data may not be transmitted from the passenger's terminal to the car-sharing RS server, but rather from other information processing equipment, such as a personal computer, a general-purpose terminal installed in a public place, or other equipment. Furthermore, if the passenger has already registered their information as a member with other services, such as mail-order companies, retailers of goods and services, or other types of sharing services, the system may be configured to link information with those servers where the member registration is held and to retrieve the necessary information from those servers to the car-sharing RS server of the embodiment of the present invention.

[0060] (Figure 6) Figure 6 simplifies the matching and boarding procedures shown in Figures 3 through 5, and includes car-sharing stations and shared cars.

[0061] The car-sharing RS server receives driving reservation data from the driver's terminal and usage inquiry data from the passenger's terminal. The matching system then matches the usage inquiry data with the driving reservation confirmation data. This allows the passenger to recognize that there is a driving reservation confirmation data that matches their usage inquiry data. After this, the passenger sends back usage reservation confirmation data indicating their intention to confirm the reservation, and the reservation is confirmed.

[0062] When the date and time specified in the driving reservation confirmation data arrives, the driver will move to the car-sharing station specified in the driving reservation confirmation data and begin driving the shared car. Then, they will head to the pick-up location requested by the passenger. Meanwhile, the passenger heads to the departure point indicated in the booking confirmation data and waits for the driver to arrive at the departure point in the shared car. Once the driver arrives at the departure point, the driver picks up the passenger in the shared car, drives to the passenger's destination, drops the passenger off, and then returns the shared car to the original car-sharing station.

[0063] (Figure 7) Figure 7 shows the procedure for a passenger to change their search criteria and attempt to find a match if the initial matching between the rideshare driver and passenger is unsuccessful. The procedure up to the point of performing the matching is the same as in Figure 5, so the explanation is omitted.

[0064] If a match is not possible, the car share RS server sends matching NG data to the passenger's terminal via the matching NG transmission means (2). It is desirable that the matching NG data include information indicating that either the desired date and time of use, departure point, or destination is unsuitable. When a passenger receives matching NG data via the matching NG receiving means on their passenger terminal, they consider changing one of the conditions that resulted in the NG (3). Then, they send the modified usage inquiry data, which is the usage change data, to the car share RS server via the usage inquiry data transmission means (4).

[0065] The car-sharing RS server's data reception means processes the modified data through the matching means to verify whether a match is possible. If a match is possible, the matching data is transmitted to the passenger terminal and the driver terminal via the matching-possible transmission means (5).

[0066] (Figure 8) Figure 8 is a modified version of the embodiment shown in Figure 7. That is, while Figure 7 shows the state after the matching process shown in Figure 5, Figure 8 shows the state after the matching process shown in Figure 4.

[0067] (Figure 9) Figure 9 shows how, if a match is unsuccessful, the possibility of the driver being asked to drive in a way that fulfills the requested usage data is approached. While Figures 7 and 8 were embodiments that pressured the passenger to compromise, Figure 9 is an embodiment that increases the likelihood of a successful match by asking multiple registered drivers to drive in a way that fulfills the requested usage data.

[0068] Suppose that the matching means searches for matching data based on the usage inquiry data (1) received from the passenger terminal, but there is no matching reservation inquiry data or confirmed driver reservation data (2). In this case, the driver inquiry data transmission means extracts the nearest driver (A, B, C) from the driver database based on the departure point and destination in the usage inquiry data. Then, it creates driver inquiry data from the usage inquiry data and sends it to driver terminals A, B, C, and the driver inquiry data transmission means transmits the driver inquiry data (3). In the event of multiple acceptances for operation, the general procedure is to prioritize the acceptance received at the earliest time.

[0069] One of the drivers who receives the driving request data (A in this diagram) sends a message via the driving acceptance transmission means indicating their intention to accept driving based on the driving request data (4). The car share RS server receives this driving acceptance, and the reservation completion registration means registers it in the vehicle management database. Although not shown in the diagram, the reservation completion registration is also performed in the driver database and the passenger database. Then, the driving reservation completion data transmission means sends the driving reservation completion data to the passenger terminal and the driver terminal (5).

[0070] (Figure 10) Figure 10 shows an embodiment of a system for finding a substitute driver when a driver expresses their intention to cancel a driving reservation in which they were scheduled to pick up a passenger.

[0071] First, it is assumed that the matching with the passenger's usage inquiry data has been completed and the usage reservation completion data has been sent to the passenger's terminal and driver's terminal A (1). Subsequently, suppose the driver cancels the shared car driving reservation related to the usage reservation completion data due to the driver's circumstances. That is, cancellation data is sent from driver's terminal A to the car share RS server (2).

[0072] When the car share RS server receives the cancellation data via the cancellation data receiving means, it creates a confirmed driving reservation data based on the driver database and vehicle database data, and sends driving inquiry data to the communication terminals of drivers other than driver A who canceled, such as driver B and driver C (3).

[0073] Driver B, upon receiving the driving request data on their own communication terminal, transmits a driving acceptance, which is an expression of their intention to take on the driving, using the driving acceptance transmission means (4). As a result, the passenger will be able to travel as they wished, although the driver at the time of receiving the usage completion data will be changed.

[0074] On the car-sharing RS server, when a reservation is made, reservation change data is created indicating that the driver has been changed, and this data is sent to the passenger terminal (5). Although not shown in the diagram, the driver terminal B receives confirmation of the details regarding the acceptance of the driver's license. In addition, the vehicle management database is updated with management data for the vehicle rental related to the acceptance of the driver's license.

[0075] (Figure 11) Figure 11 illustrates the data collection and accurate data provision performed during rideshare operations with the driver and passengers on board.

[0076] Since the vehicles used for ride-sharing are the same vehicles used for car-sharing, the driving data is periodically received by the driving data receiving mechanism of the management server (car-sharing RS server). The received driving data is stored in the vehicle management data.

[0077] The received driving data includes current location data based on the GPS device installed in the vehicle. The driving data analysis means analyzes whether the vehicle is following an appropriate route (for example, the route to reach the destination in the shortest time) by comparing this current location data with the departure and destination data stored in the passenger database registered by the passengers.

[0078] If the driving data analysis tool determines that the vehicle is not following the appropriate route, warning data is generated and transmitted to the in-vehicle unit of the shared car while it is being driven via the warning data transmission tool. Warning data may include messages such as, "The route you are currently on deviates from the shortest route connecting the passenger's starting point and destination. To select the shortest route, turn right at the second traffic light and drive along National Route 1." This warning data is transmitted to the driver via the speaker of the in-vehicle unit installed in the shared car, or via the speaker and output screen of the multi-function car navigation system connected to the in-vehicle unit.

[0079] The generated caution data will be linked to the driver (each driver is assigned a driver ID) and stored in the driver database. This data will be collected as driver evaluation data and prepared for information provision to the driver and their passengers.

[0080] (Figure 12) Figure 12 shows the procedure for conducting a driver evaluation by a passenger after their use of the vehicle has ended. In addition to the subjective evaluation by the passenger, objective evaluations obtained by analyzing driving data will also be fed back to the driver.

[0081] The car-sharing ride server identifies passengers who used the rideshare service based on the passenger database, identifies drivers who drove the rideshare based on the driver database, and creates evaluation request data. The created evaluation request data is then sent to the passenger terminal associated with that passenger (1). The evaluation request data may also include the date and time the rideshare was used, the departure point, the destination, and the route taken.

[0082] The passenger who receives the evaluation request data via the passenger terminal inputs the evaluation data via the evaluation data input means and sends the evaluation data to the car share RS server via the evaluation data transmission means (2).

[0083] The car-sharing RS server receives evaluation data via the evaluation data receiving means. If the evaluation data needs to be processed, it is processed using the evaluation data processing means and then transmitted to the driver terminal using the evaluation data transmission means (3). An example of the evaluation (processed) data transmitted to the driver terminal is "Driving evaluation: B, Price evaluation: A, Overall evaluation: A".

[0084] The evaluation data transmission means registers the evaluation (processed) data in the vehicle management database in addition to the driver database. The driving data collection means collects the driving data of the driver stored in the vehicle management database, and the driving data processing means processes that data. The processed driving data is then transmitted to the driver terminal (4). An example of processed driving data transmitted to the driver terminal is, "One sudden brake, one sudden steering, overall evaluation is B."

[0085] (Figure 13) Figure 13 is a flowchart showing how to handle immediate use, including cases where the desired date and time of use is approaching, based on data from passengers requesting the service. It is an example of the data processing procedure performed by the matching means shown in Figure 4, etc.

[0086] First, the system receives usage inquiry data (S1). This is the same operation as shown in Figure 4. Next, if the difference between the date and time in the received usage inquiry data and the current time is less than or equal to a predetermined value (e.g., 1 hour), it is determined that the service is "available for immediate use" (S2).

[0087] For immediate use, the system determines from data stored in the vehicle management database whether a vehicle (shared car) driven by a registered driver is currently operating at the departure point specified in the usage request data (S3). If a suitable vehicle exists, RS request data indicating whether ridesharing is possible is sent to the vehicle's onboard unit (S4). If no suitable vehicle exists, matching is not successful (S11).

[0088] The driver, having read the RS inquiry data via the in-vehicle device, decides whether or not to accept the rideshare (S5). If they respond with acceptance, the matching is completed (S6). If they respond with rejection (including cases where no response is received within the specified time), the process returns to S3.

[0089] If immediate use is not required, it is determined whether there is a driver reservation made by a registered driver at the departure location specified in the usage inquiry data (S7). If there is no reservation, matching is not achieved (S11). However, as shown in Figure 9, it is possible to achieve matching by distributing the driver inquiry data. Note that Figure 13 does not mention this.

[0090] If there is a driver reservation made by a registered driver at the departure location specified in the usage inquiry data, RS inquiry data is created to determine whether ridesharing is possible and sent to the communication terminal of the relevant driver (S8).

[0091] Upon receiving RS inquiry data, the driver decides whether or not to accept the rideshare (S9). If they reply that they accept, the matching is successful (S10). If they reply that they do not accept (including cases where no reply is received within the specified time), the matching is not successful (S11). However, since there is time until the date and time related to the usage inquiry data, the process from S7 is executed each time new driving reservation data is registered.

[0092] The embodiments described above do not mention how much the passenger pays for the service, how they pay it, or how the driver receives that payment as a service fee. Basically, this is a matter that should be left to negotiation between the passenger and the driver. However, in the embodiment described above, the data entered by the passenger regarding the use of the service may include, in addition to the departure point and destination, the amount of compensation that the passenger is willing to pay.

[0093] The car-sharing RS server may receive the reward from the passenger first and then pay a certain percentage of that amount to the driver. For example, if a passenger enters a reward of 10,000 yen, the car-sharing RS server may deduct the car usage fee and other expenses (costs incurred in operating the car-sharing RS server) from that amount and pay the remaining amount to the driver as their reward.

[0094] Furthermore, the car-sharing RS server may also present the driver with the calculated compensation amount in advance. For example, the reservation inquiry data could include a statement like, "I'm willing to drive the RS car from point A to point B for 10,000 yen," while the usage inquiry data could also include a statement like, "I'd like someone to drive the RS car from point A to point B for 10,000 yen," and the matching method could take these compensation amounts into consideration when matching.

[0095] Furthermore, if, for example, the aforementioned driving request data includes a request stating, "We would like you to drive an RS in a shared car from point A to point B for 10,000 yen," the driver who receives the request can decide whether or not to accept the offer, taking the compensation amount into consideration.

[0096] In recent years, there has been an increase in the use of rental cars and car-sharing services, where people only use a car when needed, rather than owning one. Therefore, it is conceivable that drivers who offer ride-sharing services, as described above, will use car-sharing services rather than their own vehicles.

[0097] If ride-sharing according to the embodiments described above is implemented, the following effects can be expected. In other words, a mismatch has been created where the number of drivers is decreasing due to young people's declining interest in cars, while the number of passengers is increasing due to elderly people surrendering their licenses, and this technology is expected to have the effect of resolving this mismatch. [Industrial applicability]

[0098] The present invention has applicability in car-sharing and car-rental service industries, parking lot operations, manufacturing of information and communication equipment necessary for parking lot operations, and software service industries that create application programs used in car-sharing management servers.

Claims

1. In a vehicle sharing business that lends vehicles to registered users who have completed membership registration in advance, the management server for operating the rideshare service is as follows: A vehicle management database that stores management data related to shared vehicles managed by the aforementioned vehicle sharing business operator, linked to a vehicle ID for each vehicle, A member database that stores the attribute data of member users necessary for the aforementioned member registration, linked to the member ID, A means for receiving request data for use, which receives request data including the desired date and time of use, departure point and destination from a terminal of a passenger who wishes to use a rideshare service provided by a rideshare driver who operates a shared vehicle managed by the aforementioned business operator, A reservation request data receiving means that receives reservation request data including the desired date and time of use and departure location from the terminal of the aforementioned member user, A reservation availability determination means that determines whether the shared vehicle can be reserved using the vehicle management database based on the reservation inquiry data, A reservation eligibility / determination transmission means that transmits the determination result from the reservation eligibility / determination means to the terminal of the member user, When the result of the reservation feasibility determination means is that a reservation is possible, a matching means verifies whether the reservation inquiry data can be implemented based on the content of the usage inquiry data, A matching-possible transmission means transmits matching-possible data to the terminal of the member user and the terminal of the passenger if matching is possible based on the verification results by the matching means. A management server equipped with the necessary features.

2. The system includes a passenger database in which passengers who wish to use the aforementioned rideshare service register their intention to use the rideshare driver, along with attribute data for identifying the passenger. A driver database, in which the aforementioned rideshare drivers pre-register their member IDs and their intention to provide rideshare services, will be included within the aforementioned member database. The management server according to claim 1.

3. If the matching by the aforementioned matching means is unsuccessful, in order to find a driver who is available to drive based on the content of the aforementioned user inquiry data, driving inquiry data including the user inquiry data will be transmitted to the terminal of the driver based on the aforementioned driver database. The management server according to claim 2.

4. In a vehicle sharing business that lends vehicles to registered member users, a computer program controls the management server for the aforementioned member users to operate the rideshare service, The aforementioned management server has a vehicle management database that stores management data related to shared vehicles managed by the operator of the aforementioned vehicle sharing business, linked to each vehicle's vehicle ID, and A member database that stores the attribute data of member users necessary for the aforementioned member registration, linked to the member ID, Equipped with, The aforementioned computer program is A procedure for receiving request data for use, which receives request data including the desired date and time of use, departure point and destination from a terminal of a passenger who wishes to use a rideshare service provided by a rideshare driver who drives a shared vehicle managed by the aforementioned business operator, A procedure for receiving reservation request data, which includes the desired date and time of use and departure location for the member user, from the terminal of the aforementioned member user, A reservation availability determination procedure that uses the vehicle management database to determine whether the shared vehicle can be reserved based on the reservation inquiry data, A reservation eligibility / determination transmission procedure that transmits the result of the reservation eligibility / determination procedure to the terminal of the aforementioned member user, If the result of the reservation eligibility determination procedure described above is that a reservation is possible, a matching procedure is performed to verify whether the reservation request data can be implemented based on the content of the aforementioned request data, A matching-possible transmission procedure that transmits matching-possible data to the terminal of the member user and the terminal of the passenger if matching is possible based on the verification results of the matching procedure, A computer program that causes the aforementioned management server to execute it.

5. The aforementioned management server includes a passenger database in which passengers who wish to use the rideshare service register their intention to receive transportation services from the aforementioned rideshare driver, along with attribute data for identifying the passenger. A driver database, in which the aforementioned rideshare drivers pre-register their member IDs and their intention to provide rideshare services, will be included within the aforementioned member database. The computer program according to claim 4.

6. If the matching procedure described above fails, the management server will execute a driving inquiry data transmission procedure to send driving inquiry data, which includes the aforementioned driving inquiry data, to the terminal of the driver based on the driver database, in order to find a driver who is available to drive based on the contents of the aforementioned driving inquiry data. The computer program according to claim 5.

Images